ルールがあってこそ物事は整う
本題に入る前に、小学生の頃、先生から「李明」宛ての手紙を書くようによく言われたことを覚えていますか？
冒頭にはたいてい「こんにちは」と書き、最後には「敬具」に相当する定型表現を加えることもありました。特に試験では、一つでも抜けると減点されました。
当時は、なぜこんなに面倒なのだろうと思っていました。小さなメモのように、伝えたいことを書くだけではいけないのでしょうか？
仕事を始めてから、私はメールをよく書くようになりました。最初は決まった形式を使っていませんでしたが、急いでいると簡単に書き漏らすことに気づきました。
自分の名前を忘れたり、日付を書き忘れたり、相手が次に何をすべきか伝え忘れたりします。
そのうち、子どもの頃のように、決まった順序でメールを確認するようになりました。どれだけ忙しくても、重要な内容を見落としにくくなります。
同じことは、多くの業界にも見られます。看護師、客室乗務員、設備のオペレーターは、チェックリストに沿って何度も確認します。一見とても簡単な作業なのに、なぜそのようにするのでしょうか？
人は必ず見落とすことがあるからです。決まった手順があっても絶対に間違わないとは限りませんが、抜けを減らせます。
Prompt を書く場合も同じです。
複雑なタスクで順番に確認できる、参照用のテンプレートを用意できないでしょうか？
用意できます。
ただし、それは見落としを減らすための道具にすぎず、あらゆるモデルやタスクに最適な「公式」ではありません。
良い Prompt には何を含めるべきか？
すべての情報を詰め込み、詳しくするほどよいのでしょうか？
もちろん違います。
中国ドラマ『武林外伝』で、燕小六はよくこう畳みかけます。「姓は？名は？どこから来た？どこへ行く？家族は何人？一人あたり畑は何畝？畑に牛は何頭？」
とても具体的に聞こえますが、その場の用件とは関係のない情報もたくさんあります。情報が多すぎると、かえって邪魔になることがあります。
情報が少なすぎれば、モデルは推測するしかありません。関係のない情報が多すぎても、ノイズになります。
まず、現実にありそうな場面を見てみましょう。張三に牛肉パイを二つ買ってきてもらう場面です。
牛肉パイを二つ買う
完全な依頼が次の内容だったとします。
張三に、今すぐ下の階にあるローソンへ行き、1 個 7 元の牛肉パイを 2 個買ってきてもらってください。
牛肉パイは温め、別々の紙袋に入れ、20 分以内に持ち帰ってください。
ここには、どのような重要情報があるでしょうか？
まず、誰が買いに行くのか。はっきりした人が必要です。人混みの中で「牛肉パイを二つ買ってきて」とだけ言っても、張三は自分に言われたのか分かりません。これは役割または対象です。
どこへ、いつ行くのか。伝えなければ、張三は明日買いに行ったり、別の店へ行ったりするかもしれません。これは行動の時間と場所です。
何を、いくつ、いくらで買うのか。これはタスクと制約です。
温める必要があるか。これは具体的な操作です。
どのように包むか。これは受け渡し形式です。
いつまでに持ち帰るか。これも制約条件です。
張三に「何か買ってきて」としか言わなかったとします。
頭の中で考えていた牛肉パイ二つを、ちょうど買ってきてくれるでしょうか？
その可能性がまったくないとは言えません。本当に一つも違わなければ、張三は私たちをよく理解しているのでしょう。
しかし多くの場合、張三は質問を続けるか、自分で推測するしかありません。
人間でもそうなのです。では AI はどうでしょうか？
モデルに小説を書かせたいのに「小説を書いて」としか伝えなければ、頭の中の構想にぴったり合う内容には、まずならないでしょう。
参照できる一つの構造
複雑な Prompt では、次の項目から必要なものを選べます。
Role（役割）
モデルにどのような視点で作業してほしいか、または結果を誰に向けるかを説明します。
役割を書いても、モデルが実際の職業資格を得るわけではなく、ほかの分野の知識を「遮断」するわけでもありません。本当に役立つのは、「コードレビュアーのようにリスクを探す」といった役割の背後にある具体的な基準です。「あなたは世界一優秀なエンジニアです」という表現ではありません。
Skills（必要な能力）
要約、分類、翻訳、コードの説明など、タスクで必要な能力を列挙します。
モデルに新しいスキルをインストールするものではありません。タスクで必要となる処理方法へ注意を向ける助けになるだけです。簡単なタスクでは、この項目を省略できます。
Action（行動）
何を完了すべきか、モデルに直接伝えます。
たとえば、会議記録からアクション項目を抽出する、コードのエラーを確認する、テーマに基づいて物語の構成案を書く、といった内容です。
Constraints（制約）
してはいけないこと、情報が不足している場合の処理方法、長さ、言語、安全性、事実の境界を説明します。
たとえば、元の文章にない情報を追加しない、不明な場合は「情報なし」と書く、中国語で回答する、といった指定です。
Format（形式）
Markdown、表、JSON、固定フィールドのどれで出力してほしいかを説明します。
Example（例）
ルールが抽象的な場合は、入力と出力の例を示し、対応関係の理解を助けます。
構造を一つの Prompt にまとめる
# Role
SF 物語の編集者
## Action
ユーザーが示したテーマに基づき、登場人物の設定、物語の対立、三部構成のあらすじを作成する。
## Constraints
- 既存作品の著名な登場人物や筋書きを使用しない。
- 情報が足りない場合は、独自に補完せず、先に確認が必要な質問を列挙する。
- 世界観は架空でもよいが、内部のルールに一貫性を持たせる。
## Format
Markdown を使い、「登場人物、対立、あらすじ、確認が必要な質問」の四部構成で出力する。
## Example
登場人物：星間航路の修復を担当するエンジニア。
対立：修理任務を通じて、二つの文明の間に隠されていた歴史が明らかになる。
このテンプレートは、そのまま写さなければならない正解ではありません。
一文を読みやすく直すだけなら、六つの項目をすべて書く必要はありません。長い資料、複数人での共同作業、プログラムによる後続処理が関係するほど、構造の価値は高くなります。
簡単なタスクは、簡単に書きます。
複雑なタスクでは、テンプレートを使って抜けがないか確認します。
前の章： 良い出力を得るための六つのコツ
次の章： モデルに JSON データを出力させる
Independent product builder · AI, agents and real workflows.