# 04 プロンプトの組み立て方

`01_生成プロンプト.md` は、今日の題材にだけ使えるものです。このファイルは、それを自分の業務の別のアプリに置き換えるための考え方をまとめています。研修後、顧客の前で「その場で作ってみせる」ところまで持っていくための材料です。

---

## 最初に押さえること

生成AIはアプリの中にいません。アプリを作る側にいます。

この区別を外すと、顧客との会話がすぐに噛み合わなくなります。「AIで議事録を要約するツールを作りたい」と言われたとき、実際に必要なものは2通りあります。動作するたびにAIを呼ぶツールか、AIに1回書かせただけで以後は自分で動くツールか。この2つは、月額のコストも、預けるデータの範囲も、動作の安定性も、承認に必要な手続きもまったく違います。

今日作るアプリは後者です。AIは作るときに1回だけ登場し、できあがったものはブラウザの中だけで動きます。APIキーもサーバーも要りません。だから「試しに作って見せる」ことができます。顧客が本当に前者を必要としているのかを確かめる前に、後者で1枚作って見せてしまうのが速い、という話です。

---

## 3要素で組み立てる

プロンプトは、次の3つで組み立てます。順番もこのとおりです。

| 要素 | 書くこと | 書かないとどうなるか |
| --- | --- | --- |
| 何を作るか | 使う人、入れるもの、出るもの | 汎用のサンプルアプリが返ってきます |
| 何を禁止するか | 使ってほしくない技術と、その代わりに使うもの | 動く環境が限定され、渡した相手の手元で開けません |
| どう出させるか | 出力の形と、途中で切れたときの扱い | コピーして保存する段階で失敗します |

`01_生成プロンプト.md` を、この3要素で分解してみます。

### 何を作るか

第1ブロックの1文です。

> 打ち合わせの議事録を貼り付けると、決定事項・課題・ToDo に整理し、タスクボードとBPMN図を表示する、単一HTMLのブラウザアプリを作ってください。

この1文に、入力（議事録を貼る）、処理（3分類に整理する）、出力（タスクボードとBPMN図）が入っています。第4ブロック以降の長い仕様は、すべてこの1文の詳細です。

自分の業務に置き換えるときは、この1文を先に書いてください。書けなければ、仕様をいくら足しても方向が定まりません。埋める枠は3つです。

```
（誰が）（何を入れると）、（何が出る）（どこで動く）ツールを作ってください。
```

SES営業の手元業務なら、たとえばこうなります。

- 技術者の経歴書を貼ると、案件の必須スキルと突き合わせて過不足の一覧が出る、単一HTMLのブラウザツール
- 複数案件の稼働開始日と終了日を貼ると、月ごとの稼働の重なりを横棒で描く、単一HTMLのブラウザツール
- 面談のメモを貼ると、確認できた項目と聞き漏らした項目に仕分ける、単一HTMLのブラウザツール

いずれも、AIを呼ばずに作れます。判定のルールを自分で書けるからです。判定のルールを自分で説明できないものは、この作り方には向きません。そこが、AIに投げる版が必要になる境目です。

### 何を禁止するか

第2ブロックです。禁止だけを並べると、モデルは別の外部依存を探します。CDNを止めれば画像URLを埋め、フォントを止めれば絵文字を使います。禁止には必ず代わりを添えてください。

```
（使ってほしくないもの）を使わないでください。代わりに（使ってほしいもの）を使ってください。
```

今日のプロンプトで禁止しているのは、外部CDN、Webフォント、外部API、外部画像、ネットワークアクセスの5つです。理由は1つで、開く場所のネットワークを当てにしないためです。顧客先の会議室で開いて動かない試作は、動かないのと同じです。

顧客先で見せる前提なら、この5つはそのまま流用してください。社内の検証環境で使うだけなら、外部CDNの禁止は外してもかまいません。判断の基準は、「どこで誰が開くか」の1点です。

配色と絵文字の禁止も、ここに含めています。生成AIに任せると、原色のバッジと絵文字が並んだ画面が返ってきます。それを顧客の前で開いた瞬間、中身の話に入る前に「AIが作ったもの」として見られます。色を2系統に限定し、絵文字を止めるだけで、その印象はほぼ消えます。

### どう出させるか

第13ブロックです。

> HTMLコードだけを1つのコードブロックで出力してください。前置きと後書きは不要です。
> 出力が途中で切れた場合は、続きを最初から出し直さず、切れたところから続けてください。

この2行がないと、コードの前後に解説文が付き、コピーしたときに巻き込みます。長い生成は途中で止まることがあるため、止まったときの扱いも先に書いておきます。

---

## 顧客の前で使う形にする

その場で作って見せる場面では、時間が限られます。次の3点を用意しておいてください。

**1. 自分用の雛形を1つ持つ**

`01_生成プロンプト.md` の第2ブロック（動作環境の制約）と第3ブロック（配色）と第13ブロック（出力形式）は、題材が変わってもそのまま使えます。この3ブロックだけを抜き出して、自分のメモに置いておいてください。あとは第1ブロックの1文と、処理のルールを書き足すだけになります。

**2. 判定のルールを先に決める**

その場で仕様を考えると止まります。事前に「何をどう仕分けるか」を紙に書いておいてください。今日のアプリでいえば、分類キーワードの一覧がそれにあたります。ここが顧客との会話の中身になります。「御社ではこの単語が出たらToDo扱いでよいですか」という聞き方ができると、要件の確認そのものが進みます。

**3. うまくいかなかったときの逃げ道を決めておく**

生成は毎回同じようには終わりません。途中で切れる、外部URLが混ざる、コードが2つに分かれる、のどれかは起きると思っておいてください。その場で直すのか、事前に作っておいたものに切り替えるのかを先に決めておきます。今日の研修では `answer/` がその役割です。顧客の前でやるなら、前日に1回同じプロンプトを通して、できあがったHTMLを手元に持っておいてください。

---

## 避けたい書き方

**曖昧語を残す**

「見やすく」「いい感じに」「モダンなデザインで」と書くと、生成のたびに違うものが出ます。2回目に同じものを出せないと、顧客に見せる道具として使えません。数値と要素名で書いてください。

**1文に2つ以上の要求を入れる**

「タスクボードを担当者ごとに並べて、状態でも絞り込めるようにして、完了は薄くしてください」と書くと、3つのうち1つが落ちます。1文1指示です。文の数が増えるのは構いません。

**禁止を後ろにまとめて書く**

禁止事項をプロンプトの末尾にまとめると、前半の仕様を先に組み立てられてしまい、後から辻褄を合わせる形になります。制約は仕様より先、第2ブロックに置いてください。

**networkやAPIの話を省略する**

「外部と通信しない」は、書かなければ守られません。書いていない制約は存在しないものとして扱われます。当たり前だと思っていることほど、明示的に書いてください。

---

## この考え方が効かない場面

判定のルールを人が説明できない仕事には向きません。「この文章の書きぶりが失礼かどうか」「この経歴書が案件に合いそうかどうか」のような、基準を言語化しづらい判断です。こういう仕事は、ルールで書くのではなくAIに投げる版が必要になります。そのときは、APIキーの管理と、入力してよい情報の線引きが要件に入ってきます。S03 で扱った内容がそのまま前提になります。

顧客の相談を聞いたとき、まずこの線で切ってみてください。ルールで書けるならブラウザで完結する試作を1枚、書けないならAIを呼ぶ設計の話。この2つを分けて話せるだけで、会話の解像度が変わります。

ちなみに、ルールで書けるかどうかは、その場で判断しなくてかまいません。「どういう場合にToDo扱いになりますか」と3回聞いて、3回とも例外が出てくるなら後者です。
