第1章 指示文の設計

学習目標

• 曖昧な業務依頼を、目標・制約・成功基準が明確な検証可能な指示に直す。
• タスクの種類（抽出・変換・生成・判断）に応じ、創作を許す範囲と求める根拠を決める。
• 否定形の指示を、肯定形の指示と短い理由に変える。
• システム（開発者）・ユーザー・アシスタント（assistant）メッセージの役割と優先順位を説明し、ルールと入力を適切な位置に置く。
• 互いにぶつかる指示を見つけ、適用条件と優先順位で整理する。
• 情報が足りないときに、質問すること、仮定して明示すること、保留することを分けた方針を書く。

はじめに

ある出版社のマーケティングチームで、新刊の紹介文をモデルで作り始めました。チーム長が最初に書いた指示は「新刊の紹介文を魅力的に、長すぎないように書いて」でした。初日の結果はもっともらしいものでした。ところが、1週間にわたって担当者5人が同じ指示を使うと、結果はまちまちになりました。2行の紹介文もあれば10行のものもあり、本には記載されていない受賞歴を誇る文案もありました。確認を担当した編集者は、紹介文ごとに異なる基準で手を入れなければならず、ほどなく、モデルを使うほうがかえって面倒だという声まで上がりました。会議では、ある人が「今日はモデルの調子がおかしい」と言いましたが、実際にはモデルは毎回、指示に忠実に従っていました。指示に「魅力的」と「長すぎない」の基準が定められていなかったため、モデルはその都度、最ももっともらしい基準を自分で補っていただけなのです。

この章では、その空白を埋める方法を扱います。モデルをどのような同僚と捉えるかという話から始め、タスクの種類とよい指示の4要素を学びます。そのうえで、判定できない表現を判定可能な条件に変える手順、禁止の代わりに行うことと理由を伝える方法、メッセージの役割、ルールとデータを分けるテンプレート、矛盾する指示の整理、情報が足りないときの方針を順に見ていきます。「さらに深く」では、指示文の適切な高度、指示文を短くする編集、秘密情報の置き場所を扱います。

重要な概念

モデルは有能だが、今日が初出勤の同僚

新しく来た同僚がどれほど優秀でも、チームの慣習や顧客、報告の書式は知りません。「レポートをまとめておいて」とだけ頼めば、自分が知っている一番もっともらしい方法でまとめるだけです。Anthropicのガイドは、モデルを「優秀だが、チームの規範や業務の流れを知らない新入社員」と考えるよう勧め、簡単な確認を黄金律として示しています。文脈をほとんど知らない同僚にプロンプトを見せ、そのとおりに作業できるかを尋ねるのです。同僚が迷うなら、モデルも迷います。

この比喩にも限界があります。人間の新人は、不明点を隣の人に尋ね、先週の会議を覚え、間違いに責任を感じます。モデルは与えられたコンテキストの外を知らず、質問禁止の指示がなくても、聞かずに補ってしまいがちです。そのため結果が間違ったら、原因を2つに分けて考えます。

タスクの種類から決める

指示を書く前にタスクの種類を決めると、多くの判断が自然に定まります。種類によって、モデルに許す創作の幅や求める根拠の水準が違うからです。

抽出タスクに生成タスク向けの指示（「読みやすく整えて」）が混ざると、原文にない表現が入り、判断タスクに基準表がなければ、モデルはもっともらしい基準を作って適用します。1つのプロンプトに複数の種類が混ざっている場合は、段階ごとに種類を明示するか、第4章で扱うように段階を分けるほうが安全です。

よい指示の4要素

よい指示は、4つの問いに答えます。

4要素がすべて必要な理由は、一つずつ取り除くとはっきりします。

成功基準は、4要素の中で最も抜け落ちやすいものです。「簡潔に」「適切な長さで」「高い品質で」といった言葉は、判定できない表現です。「5行以内」「最初の文に結論を置く」「項目ごとに根拠を1つ示す」のように、結果だけを見て守られたかどうかを区別できる形に変えると、人による確認もしやすくなり、第5章で扱う自動評価にもそのままつながります。Anthropicのプロンプトエンジニアリングの概要でも、プロンプトを整える前に、成功基準、その基準を使って実験する方法、最初の草案という3つを、まず用意するよう求めています。

役割は視点を決めるだけで、知識を与えない

システムプロンプトに役割を示す文を1つ入れると、モデルの視点と話し方が、その業務に合う方向に定まります。Anthropicのドキュメントは、1文の役割指定だけでも違いが出ると説明しています。ただし、役割を示す文が果たす働きと、果たせない働きを区別する必要があります。

「経験20年の税務専門家のように答えよ」と書いても、モデルが自社の税務処理基準を知るようになるわけではありません。必要な基準はコンテキストとして与え、モデルが判断してよい範囲と、人に引き継がなければならない条件を指示に書く必要があります。役割は出発点にすぎず、4要素の残り3つの代わりにはなりません。

曖昧な要求を検証可能な指示に変える

現場からの依頼は、たいてい形容表現で届きます。「すっきりと」「説得力を持たせて」「顧客に親しみやすく」といった具合です。こうした依頼を指示文に移す際には、次の手順に従うと抜けを減らせます。

1. 形容表現すべてに印をつける。 依頼文で判定基準のない形容詞や副詞に下線を引く。
2. 依頼者に「何を見たらそう感じるか」と尋ねる。 「すっきり」が「1段落1テーマ」なのか「表がある」なのかは依頼者にしかわからない。
3. 観察可能な指標に変える。 数値（文字数、項目数）、位置（最初の文、最後の行）、形式（表、箇条書き）、有無（価格、期限、問い合わせ先）で書く。
4. 失敗条件も書く。 「根拠のない数値が1つでもあれば不合格」など、即座に不合格とする条件を決める。
5. 判定してみる。 過去の成果物をいくつか、新しい基準で自分で判定してみる。判定が分かれる基準は、さらに具体的に書き直す。

依頼：新規会員向け案内メールを、親しみやすく長すぎないように。

検証可能な指示：
- 読者は登録直後の個人会員である。敬体の平叙文で書き、感嘆文は1回までとする。
- 本文は600文字以内、3段落とする。
- 第1段落に、会員が今すぐできることを1つ書く。
- 特典は提供された一覧にあるものだけを書く。一覧にない特典が1つでもあれば失敗とする。

こうして変えた指示は、確認担当者の基準になると同時に、基準を変更した際の変更内容を記録する根拠になります。

してはいけないことより、すべきことを

「表を使うな」は、禁止することだけを伝え、代わりに何を使うべきかは空白のままにしています。Anthropicのガイドは、望まないことよりも望むことを伝えるよう勧めています。たとえば、「Markdownを使うな」の代わりに、「滑らかにつながる段落で書け」と書く方法です。

あまりよくない指示：箇条書きを使うな。
よりよい指示：回答はキオスク端末の画面上の1つの表示枠に収めるため、2〜3文の平叙文を1段落にして書く。

同じ文脈で、プロンプト自体の書式も出力に影響します。Anthropicのドキュメントは、プロンプトの書式のスタイルが応答の書式のスタイルに影響することがあり、プロンプトからMarkdownを取り除くと、出力のMarkdownも減る場合があると説明しています。見出しと箇条書きで埋め尽くされたプロンプトは、見出しと箇条書きで埋め尽くされた回答を引き寄せます。

肯定形が常に禁止の代わりになるわけではありません。個人情報の漏洩や未確定の約束など、絶対に越えてはいけない線は明示的に禁止するほうが明確です。その場合も、禁止だけでなく代わりの行動を添えます。「未確定の日程は約束しない。日程を聞かれたら、確定日が決まる時期と確認方法を案内する」とすれば、モデルは代わりに何をすべきかわかります。

理由を添えるとモデルは一般化する

指示に理由を添えると、効果が高まります。Anthropicのガイドには、次の例があります。「省略記号を絶対に使うな」よりも、「応答は音声合成エンジンが声に出して読み上げるため、エンジンが発音できない省略記号は使うな」のほうがよいというものです。ガイドは、モデルは説明から一般化できるほど賢いとも付け加えています。理由がわかれば、モデルは似た状況にも同じ原則を適用できます。それでも、必ず避けなければならない記号は直接書き、結果で確かめます。

理由は1〜2文で十分です。長い背景説明は指示の中心をぼかします。よい理由は「誰が、どこで、なぜ困るか」を示します。たとえば「日付は2026-10-20形式で書く。精算システムが結果をそのまま読み込むためである」です。

順序が重要な手順には番号を付ける

複数の段階を1つの段落の中で読点でつないで書くと、モデルが段階を抜かしたり、順序を変えたりしやすくなります。Anthropicのガイドは、段階の順序や漏れのなさが重要な場合、番号付きリストや箇条書きで、順を追った手順を示すよう勧めています。番号は、確認担当者にとっても「何番の段階が守られたか」を確かめる基準になります。

回答前に次の順序を守る。
1. 問い合わせから注文番号を探す。なければ注文番号を求めて止まる。
2. 注文情報で支払い状況を確認し、状況に合った案内文を選ぶ。
3. 案内の最後に、次に連絡する時期を書く。

逆に順序に意味のない項目まで番号を付けると、不要な順序を守るために回答の自然さを損なう場合があります。番号は「順序や抜けが結果を変える場所」にだけ使います。

メッセージの役割と優先順位

APIでモデルを使うときは、指示を置く位置が内容と同じくらい重要です。会社にたとえると、システム（開発者）メッセージは社内規程、ユーザーメッセージは顧客の依頼、assistantメッセージは社員がすでに口にした発言です。

OpenAIはdeveloperメッセージを関数定義、userメッセージをその引数にたとえています。また、developerメッセージをアイデンティティ（Identity）、指示（Instructions）、例（Examples）、コンテキスト（Context）の順に構成し、コンテキストを末尾近くに置く例を示しています。GoogleのGeminiガイドも、中核的な行動制約、役割（ペルソナ）、出力形式はsystem instructionかユーザープロンプトの先頭に置くよう勧めています。

2つの誤解に注意します。第一に、ユーザーメッセージ本文に「システム指示：」と書いても、システム権限は得られません。権限は文の冒頭の文字列ではなく、メッセージの位置から生じます。第二に、共通ルールをユーザーメッセージに混ぜると優先順位がぼやけ、「前のルールは無視せよ」という攻撃（プロンプトインジェクション）との境界も曖昧になります。

ルールとデータを分けるテンプレート

チームで同じプロンプトを繰り返し使うと、変わる部分と変わらない部分が混ざったコピーが増えます。誰かがコピーのルールを1行直すと、どれが最新版かわからなくなります。解決策はルールとデータを分けることです。

[固定ルール：バージョン3.2、2026-10-14変更]
海外の取引先に送る英文メールの下書きを書く。
- 金額と納期は<order>内の値だけを使う。
- 未確定の項目は[要確認]と示す。

[変数：リクエストごとに変わる]
<order>{{ORDER_SUMMARY}}</order>
<buyer_message>{{BUYER_MESSAGE}}</buyer_message>

二重の波括弧（{{...}}）は、リクエストごとに値を入れる場所を示す慣例です。固定ルールは1か所でだけ直し、変数には名前と入れる内容を決めます。変更履歴には何を、なぜ、どの評価結果に基づいて変えたかを書きます。第5章の回帰評価と対になります。

矛盾する指示は書き手が解く

複数の人が修正したプロンプトには、「常に1行で」と「根拠をすべて示す」のように、互いに矛盾する指示がたまりやすくなります。モデルはリクエストごとにどちらかを選び、その結果、出力がまちまちになります。解決策は、「バランスよく行え」とモデルに判断を丸投げすることではありません。書き手が矛盾を見つけ、1つのルールにまとめることです。

衝突は2種類に分けます。

業務条件の衝突は、次の手順で解きます。

1. 条件をすべて取り出す。 指示文の条件を1行ずつ表に移す。
2. 必須と希望を分ける。 破ると事故になる条件（必須）と、守るのが望ましい条件（希望）を示す。
3. 同時に守れない組を探す。 1つの入力で両立できない組み合わせを探す。
4. 適用条件を分ける。 「基本はA、この場合はB」に書き換えられるか検討する。
5. 分けられなければ優先順位を書く。 「衝突したら必須条件を守り、希望条件を守れなかった理由を1行添える」とする。

整理前：常に表でまとめる。／メッセンジャーのプレビューに合うよう短く書く。
整理後：基本は3文以内で書く。比較する項目が3つ以上ある場合だけ表を使い、
        表の前に結論を1文で書く。

情報が足りないときの方針

必要な情報が入力にないとき、モデルには質問する、仮定して進める、判断を保留するという3つの選択があります。方針がなければ、たいていもっともらしい値を補完して処理を進めます。情報の性質に応じて方針を決めます。

「わからなければ、わからないと言ってよい」という許可も方針の一部です。Anthropicのハルシネーション低減ドキュメントは、不確かさを認める権限を明示する簡単な方法で、誤情報を大きく減らせると説明しています。ただし許可だけでは不十分です。「担当部署への確認が必要と伝え、問い合わせ先を案内する」など、不明な場合の行動まで決めて初めて、モデルは推測で空欄を埋めずに立ち止まれるようになります。

実行か提案か、そして強調の落とし穴

ツールを使えるモデルにとって、「提案してほしい」と「直してほしい」は、まったく異なる指示です。Anthropicのガイドによると、最新モデルは指示に精密に従うよう学習されているため、「改善点を提案してもらえますか」と尋ねると、実際には変更してほしかった場合でも、提案だけにとどまることがあります。変更を望むなら、「この関数を直せ」のように、行動を直接指示します。反対に、モデルが尋ねもせず行動することが問題なら、意図が曖昧なときは情報と推奨事項だけを示し、明示的な依頼がある場合だけ実行する、という基本方針をシステムプロンプトに置きます。

元に戻しにくい行動には別のルールが必要です。ファイル削除、外部への送信、決済など、取り消しにくい作業や他の人の目に触れる作業は、実行前に確認を取るよう指示し、確認が必要な作業例も挙げます。

強調も見直します。旧モデル向けの「CRITICAL: 必ずこのツールを使え！」といった指示は、最新モデルの過剰反応を招く場合があります。Anthropicは、以前のツール使用不足を防ぐ強い表現が、今は過剰呼び出しを起こすことがあるため、「このツールはこの場合に使う」と普通に書くよう勧めています。強調は条件の代わりになりません。モデルを変えるときは、旧モデルの弱点を補う強調や「漏れなく」などの表現をまず見直して除き、一方で求める水準（「できるだけ多くの機能を入れよ」）は直接伝えます。変更後は第5章の評価セットで前後を比較します。Anthropicも、特定モデルで測定した手法を別のモデルに適用する前に、自分の評価で再確認するよう求めています。

さらに深く

適切な高度と、最小のプロンプトから始めること

Anthropicのコンテキストエンジニアリングの記事は、システムプロンプトの失敗を2種類に分けています。1つは、すべての例外をif-elseルールでハードコードしたために、壊れやすく保守しにくくなったプロンプトです。もう1つは、具体的な手がかりを示さず、漠然とした高水準の指針だけを与えたり、文脈が共有されていることを当然と考えたりするプロンプトです。その中間にある「適切な高度」とは、原則と理由、いくつかの代表事例によって、判断の枠組みを与える水準です。

高度を合わせる実務上の方法も、同じ記事に記されています。使える中で最もよいモデルを使い、最小限のプロンプトから試し、実際に観察した失敗を根拠として、指示と例を加えるという方法です。想像した例外をあらかじめルールとして積み重ねると、ルール同士がぶつかり、どのルールが効果を上げているのかわからなくなります。実際の入力のサンプルで最小のプロンプトを実行し、失敗を種類別に集め、その後、種類ごとに原則を1行と代表例を1つ加える、という順序が安全です。

指示文を短くする編集と、秘密情報の置き場所

指示文は、修正するほど長くなる傾向があります。失敗が起きるたびに、1行ずつ付け加えるためです。定期的に次の編集を行うとよいでしょう。

• 同じ意味の文を1つにまとめる。
• 「それ」「上の内容」など参照先が曖昧な代名詞を具体的な名称に置き換える。
• 大文字、感嘆符、「絶対」などの強調を除き、条件に変える。
• 文を削除した後、評価セットで結果を比較し、削除した文が実際に役割を果たしていたかを確かめる。

指示文に入れてはいけないものもあります。決済キーや社内の割引承認基準など、外に漏れると被害が生じる情報です。Anthropicのプロンプト漏洩に関するドキュメントは、完全な方法はないという前提で、タスクに必要のない独占的な情報は、そもそも入れないよう勧めています。漏洩を防ぐ文言を複雑に積み重ねる方法は、タスクの性能を下げる場合があるため、本当に必要な場合だけ使い、まずは出力フィルタリングのような監視方法を試すよう求めています。決済キーのような認証情報は、どのような場合もプロンプトに入れず、サーバー側のツールの中に置きます。また、モデルには必要最小限の権限だけを与えます。この最小権限の原則は、第3章のプロンプトインジェクション対策で再び扱います。

実務の場面

マル文化財団：1つの依頼、3つのチャネル

地域の文化財団「マル文化財団」の広報担当クォンさんは、秋の屋外公演の案内を、SMS、ウェブサイトのお知らせ、横断幕の3つにする必要があります。企画チームの依頼は「短く親しみやすく、ただし条件は漏れなく」の1行です。そのまま入力するとSMSは12行になり、横断幕には雨天時の会場変更条件まで入ってしまいました。

クォンさんは、まず依頼を作業仕様に分解しました。タスクの種類は変換です。企画チームから届いた公演概要書が原本であり、意味を保ったまま、チャネルごとの表現だけを変える必要があります。次に、企画チームに「漏れなく」とは何を指すのか尋ねました。答えは、日時、場所、無料かどうか、雨天時の変更、問い合わせ先の5つでした。「短く」の意味は、チャネルごとに異なっていました。

この表を作ると、矛盾が明らかになりました。SMSと横断幕では、5つすべてを守ることはできません。クォンさんは「漏れなく」を必須条件から外さず、適用条件を分けました。5つすべてを守る必要があるのはウェブサイトのお知らせであり、SMSと横断幕は、そのお知らせにつながる入り口だという役割を明示しました。そのため、SMSには詳細リンクを必須にしました。

クォンさんが採用しなかった案もあります。第1に、3つのチャネルを一度に依頼し、「チャネルに合わせて適切に」と書く方法です。判断をモデルに丸投げする方法なので、以前と同じばらつきが生じるはずでした。第2に、「絶対に長く書くな」を太字で繰り返す方法です。何を長いとするかを定義しなければ、強調しても何も変わりません。

最終的な指示文には、共通ルール（口調、事実は概要書にあるものだけ）、チャネルごとの必須情報と分量、そして理由を1行ずつ入れました。たとえば、SMSには「受信者は通知プレビューで最初の行だけを見るため、最初の行に日時と場所を書く」と添えました。過去のイベント概要書5件で試すと、確認担当者2人が、表の基準だけを見て同じ合否判定を下しました。クォンさんが直したのは文章の華やかさではなく、「短く」と「漏れなく」の定義でした。

ハヌル繊維：海外バイヤー向けメール支援をチームの道具にする

生地の輸出企業「ハヌル繊維」の営業チームは、海外バイヤーに送る英文メールの下書きをモデルで作っています。初めのうちは、それぞれがチャット画面に自分だけのプロンプトを貼り付けて使っていました。ところが、ある社員の下書きに、未確定の船積日が確定したかのように記載され、その日付を根拠にバイヤーが予定を組む事態が起きました。チーム長は開発チームとともに、この作業を社内ツールに移すことにしました。

開発担当のユさんは、散在する6つのプロンプトを集め、1行ずつ表にしました。共通ルール（丁寧なビジネス英語、署名形式）と、担当者ごとに異なるルール（価格を常に載せる人、載せない人）が混ざっていました。ユさんは3つの決定をしました。

1. 位置を分ける。 全メールに共通の役割、口調、禁止事項をシステムメッセージに移す。注文概要とバイヤーの原文は毎回変わるため、ユーザーメッセージにタグで囲んで入れる。外部から来たバイヤーの文章は指示ではなく、返信の対象となる入力データであるとシステムメッセージにも書く。
2. 情報不足時の方針。 船積日、数量、単価はバイヤーの判断を変える情報である。注文概要に値がなければ創作せず、[要確認：船積日]と示し、下書きの上に担当者の確認事項を別記させる。挨拶の表現や段落順など、後で直しやすいものは既定値で進める。
3. テンプレートと記録。 ルールは、バージョンとともにコードリポジトリに置き、営業チームが変えたいルールは、変更依頼として受ける。依頼ごとに、何を、なぜ変えるのかと、変更後に過去20件のメールで比較した結果を残す。

価格の掲載は業務条件の衝突でした。ユさんはチーム長と相談し、「バイヤーが価格を尋ねた場合、または注文概要に見積番号がある場合だけ載せる」と適用条件を分けました。

検討の過程で、ある社員が「船積日がわからなければ、おおよその日付でも入れたほうがよいのでは」と尋ねました。ユさんは、その提案を受け入れませんでした。船積日は、推測すると事故につながる情報であり、今回の問題の出発点も、まさにその推測だったからです。代わりに、確認事項の一覧を下書きのいちばん上に置き、担当者が見落とさないようにしました。導入後の1か月間、未確定の値が確定したかのように送られたメールは1通もありませんでした。担当者たちは、確認事項の一覧のおかげで、メール1通あたりの確認時間が短くなったと答えました。

間違えやすいポイント

• 強調すれば守ってくれる。 「必ず」「絶対」を太字で繰り返せば守ってくれそうに見えますが、何をするべきかを定義しなければ、曖昧さはそのままです。最新モデルでは、過度な強調がかえって過剰反応を招きます。
• 役割だけ与えればよい。 役割は視点と口調を定めますが、会社固有の知識や分量・項目などの成功基準は与えません。
• ユーザーメッセージに「システム：」と書けばシステム指示になる。 権限は文の接頭語ではなくメッセージの位置から生じます。
• 「バランスよく」と書けば矛盾が解ける。 判断をモデルに丸投げすると、リクエストごとに異なる側を選びます。適用条件や優先順位は、書き手が決める必要があります。
• 禁止だけを書けば十分だ。 禁止は、代わりに何をするかを空白のままにします。行うことを肯定形で書き、どうしても必要な禁止には代わりの行動を添えます。
• 不明なら自分で尋ねるだろう。 方針がなければ、モデルはたいてい、もっともらしい値を補って先に進みます。質問すること、仮定すること、保留することを指示に書く必要があります。
• 例外をすべてルールとして書くほど安全になる。 想像上の例外を積み重ねると、ルール同士が矛盾し、プロンプトが壊れやすくなります。最小のプロンプトから始め、観察した失敗を基に補強します。

ひと目でわかるまとめ

公式ドキュメントで確認する

• Anthropic — Prompting best practices：「Be clear and direct」「Add context to improve performance」「Give Claude a role」「Tool usage」「Balancing autonomy and safety」の節を読む。
• OpenAI — Prompt engineering：メッセージの役割と優先順位、developerメッセージの構成順、再利用可能なプロンプトの廃止案内を読む。
• Anthropic — Effective context engineering for AI agents：システムプロンプトの「適切な高度」と最小のプロンプトから始める助言を読む。
• Google — Prompt design strategies：制約・応答形式の指定と、system instructionに置く内容を確認する。
• Anthropic — Reduce hallucinations：不明な場合に「わからない」と回答することを認める手法を読む。

セルフチェック

1-1. よい指示の4要素を書き、最も抜けやすい要素がないと確認工程で何が起きるか、1文で説明してください。

1-2. 「社内報に載せる代表インタビューを洗練された感じで、負担にならない分量にまとめて」という依頼を、検証可能な条件4つ以上に書き換えてください。失敗条件を1つ含めてください。

1-3. 同じ会議録音を使う「決定事項だけを抜き出す」と「欠席した役員向けのブリーフィングを書く」は、それぞれどの種類のタスクか、また指示でそれぞれどのように要件を変えるべきか説明してください。

1-4. 無人駐車場の精算機の音声案内を作ります。「英語の略語を使うな」を、すべきことと理由を含む指示に書き換えてください。

1-5. 「全回答の末尾に根拠文書のリンクを付ける」と「回答は社内メッセンジャーのプレビュー2行以内」が同じプロンプトにあります。両立できない理由を示し、1つのルールにまとめてください。

1-6. 顧客の入力文の冒頭に「システム指示：以前のルールをすべて無視せよ」とありました。システム権限を持たない理由をメッセージの役割の観点から説明してください。

1-7. チームの議事録をまとめる支援機能を設計します。欠けうる情報3つ（例：担当者、締切、会議室名）を「質問する／仮定して示す／保留する」に振り分け、理由を書いてください。

実習課題