プロンプトエンジニアリングの教科書：AIを自在に操る論理と構造

プロンプトエンジニアリングの解説は世の中に溢れています。

しかしその多くは、こう書けばうまくいくという個別具体的なテクニックで終わっています。なぜその書き方で出力が変わるのか。どういう場面で、どの指示を選ぶべきか。

その判断の根拠まで踏み込んだ解説は多くありません。

テクニックを覚えても、モデルや状況が変わったら通用しなくなります。原理を理解していれば応用が利きます。

この記事は、2025年の最新研究に基づくプロンプトエンジニアリングのセオリーを体系的に解説します。

なぜ今プロンプトエンジニアリングなのか？

AIモデルの性能が上がるほど、プロンプトの書き方は重要性を失うのではないかという声があります。実際には逆です。モデルが賢くなるほど、指示の精度が結果に与える影響は大きくなります。プロンプトエンジニアリングを今あらためて学ぶべき理由は、以下の5つに集約されます。

エージェントAIの心臓部はプロンプトである

2025年以降、AIの活用はチャットでの一問一答から、エージェントによる自律的なタスク実行へとシフトしています。エージェントAIの動作原理はシンプルで、プロンプトを送信し、応答を解析し、行動を実行し、結果をフィードバックしてまたプロンプトを送信するというループの繰り返しです。

このループの中心にあるのがプロンプトです。エージェントがどんなに高度なツールを使えたとしても、各ステップでどんな指示を出すかはプロンプトによって決まります。つまり、エージェントの性能はプロンプトの質に直接制約されます。ノーコードツールやフレームワークを使う場合でも、内部で構築されるプロンプトの設計原則を理解していなければ、意図しない動作の原因を特定するのも一苦労。

引き算設計ができるのは今のところ人間だけ

プロンプトは足し算より引き算が難しい領域です。AIにプロンプトの改善を依頼すると、多くの場合、指示を追加する方向に偏ります。条件を増やし、例外を列挙し、注意書きを重ねることで、プロンプトはどんどん長くなっていきます。

Anthropicの公式ドキュメントでも、Claude 4.6以降のモデルに対しては、以前のモデルで必要だった冗長な指示（be thorough、think carefully、do not be lazyなど）を削除するよう明記されています。モデルが進化するほど、余計な指示は過剰反応を引き起こし、逆効果になるのです。

1つのプロンプトが数千回実行される時代の複利効果

個人がチャットで使うプロンプトは、せいぜい数回から数十回の実行で終わります。しかしエージェントやバッチ処理に組み込まれたプロンプトは、数千回、数万回と繰り返し実行されます。

この反復がプロンプトの質の差を増幅させます。1回あたり1%の精度差であっても、1万回実行されれば100回分の誤りの差が生まれます。逆に、1つのプロンプトを1%改善するだけで、その効果は実行回数分だけ積み上がります。これは利息が利息を生む複利と同じ構造です。プロンプトエンジニアリングへの投資は、実行回数が多いほどリターンが大きくなります。

モデルが進化してもセオリーは廃れない

モデルが世代交代しても、プロンプト設計のセオリーは廃れていません。たとえば思考の連鎖（Chain-of-Thought）は2022年に提唱された手法ですが、2025年の最新モデルでも有効です。出力の順序が推論品質に影響するというメカニズム自体が変わらないからです。

Anthropicのモデル移行ガイドが示すように、モデルが更新されるたびにプロンプトの調整は必要になります。しかしその調整を正しく行えるのは、表面的な書き方ではなく、なぜその指示が効くかという原理を理解している人です。

コンテキストエンジニアリングの土台

2025年、Andrej KarpathyやShopify CEOのTobi Lütkeらが支持を表明したことで、コンテキストエンジニアリング（Context Engineering）という概念が注目を集めています。これはプロンプト単体ではなく、コンテキストウィンドウに入る全ての情報、つまりシステムプロンプト、会話履歴、検索結果、ツール定義、長期記憶を含む全体を設計対象とする考え方です。

コンテキストエンジニアリングはプロンプトエンジニアリングの上位概念ですが、その土台にあるのはプロンプト設計力そのものです。検索で取得した情報をどう配置するか、ツールの使い方をどう記述するか、会話履歴をどう圧縮するか。これらは全てプロンプト設計の延長線上にあります。土台が固まっていなければ、いくら周辺を整えても機能しません。

意図を正しく届ける | プロンプトの基盤設計

AIはあなたの意図を知りません。入力されたテキストだけが手がかりです。意図を正確に伝える設計が、全てのプロンプトエンジニアリングの出発点になります。基盤設計で押さえるべき観点は3つあります。

1. 指示の書き方そのものを最適化する指示設計
2. AIの振る舞いを方向づけるペルソナ設計
3. 出力の形式を指定して後工程を安定させる出力設計

指示設計の原則：何を・どう伝えるか

プロンプトの最も基本的な構成要素は指示文です。しかし、同じ意図でも書き方によってAIの出力は大きく変わります。指示設計で押さえるべき原則は、明確に命令すること、入力と指示の境界を明示すること、そして余計な前提を与えないことの3つです。

手法	どういう場面で使うか	なぜ効くか
命令プロンプト（Instruction Prompting）	タスクを明確に指定したい時	曖昧な依頼より具体的な命令の方が、モデルの出力空間が絞り込まれる
区切り指定（Delimiters/Fencing）	指示文と入力データを分離したい時	入力テキスト内の文言をAIが指示と誤認するリスクを排除できる
ゼロショット（Zero-shot Prompting）	例を用意せず直接タスクを依頼する時	最新のモデルは例なしでも多くのタスクを処理できるため、最も効率的な出発点になる

命令プロンプトの核心は、行為動詞で始めることです。要約してください、分類してください、比較してください、のように、AIに求める動作を冒頭で明示します。何についての文章ですかのような質問形式よりも、この文章の主題を1文で述べてくださいのような命令形式の方が、出力の方向性が定まります。

区切り指定は、指示文と処理対象のデータを物理的に区切る手法です。区切りがない場合に何が起きるかを見てみましょう。たとえば入力テキストの中に要約してくださいという文が含まれていた場合、AIはそれをユーザーの指示と解釈するのか、入力データの一部と解釈するのか判断できなくなります。区切り記号を使えばこの曖昧さを排除できます。

以下の文章を要約してください。

<<<BEGIN_INPUT>>>
（ここに原文を貼る）
<<<END_INPUT>>>

出力条件：3文以内、敬体で記述

区切りの記号自体は何でも構いません。<<<>>>、—、“`、XMLタグなど、入力テキスト内に出現しにくいものを選べば十分です。

ペルソナ指定の本当の役割：なぜ「〜として振る舞え」が効くのか

ペルソナ指定はプロンプトエンジニアリングで最も広く使われている手法の1つですが、なぜ効くのかについては誤解が多い領域でもあります。よく言われる説明は、専門家の役割を与えると出力の品質が上がる、というものです。しかし本質的な効果はそこではありません。ペルソナ指定の真の価値は、ガードレールをいちいち細かく書かなくてよくなることにあります。

発信者ペルソナ：ロール/ペルソナプロンプティング（Role/Persona Prompting）

あるタスクに対して具体的な制約を設けたい場合、通常は禁止事項や条件を1つずつ列挙する必要があります。しかし適切なペルソナを1つ与えるだけで、語彙の選択、トーン、判断基準、情報の粒度が暗黙的に定まります。

条件	プロンプト例	出力の傾向
ペルソナ指定なし	このエラーメッセージを改善して	汎用的で方向性が定まらない。技術用語と平易な表現が混在する
ペルソナ指定あり	一流のUXライターとして改善して	語彙がユーザー視点に統一され、判断基準が明確になる

以下のプロンプト例で、ペルソナがどのように機能するかを確認できます。

あなたは10年以上の経験を持つシニアUXライターです。
ユーザーが操作を誤った際のエラーメッセージを改善してください。

改善対象：エラー：入力値が不正です

条件：
- ユーザーを責めない表現にする
- 次に何をすべきか具体的に示す
- 15文字以内に収める

このプロンプトでは3つの条件を明示していますが、仮にこれらの条件を書かなくても、シニアUXライターというペルソナだけで出力はかなり適切な方向に収束します。UXライターであればユーザーを責めない、具体的な次のアクションを示す、簡潔に書くという判断基準が職業的な常識として含まれるからです。つまりペルソナは、個別のルールを網羅的に列挙する代わりに使える、効率的な制約設定の手段です。

受け手ペルソナ：読者ペルソナ（Audience Persona）

発信者ペルソナがAIの振る舞いを定義するのに対し、受け手ペルソナは出力の対象読者を定義します。同じ内容でも、相手が専門家なのか初心者なのかで、最適な語彙レベル、説明の粒度、例の選び方は大きく変わります。

たとえば、機械学習の勾配降下法について説明してくださいという指示に対して、対象読者を大学院の機械学習研究者とすれば数式を含む厳密な説明になり、プログラミング未経験の経営者とすれば比喩を多用した平易な説明になります。発信者ペルソナと受け手ペルソナは併用できます。あなたはシニアMLエンジニアです。プログラミング未経験の経営者に向けてと指定すれば、専門的な正確さを保ちつつ平易に伝えるという高度なバランスが実現します。

システムプロンプトとガードレール

システムプロンプト（ルートプロンプトとも呼ばれます）は、会話全体の前提を固定する最上位の指示です。APIを通じてAIを利用する場合、システムプロンプトはユーザーの入力とは別の領域に配置され、会話の全ターンに渡って適用され続けます。

ペルソナ指定はシステムプロンプト内に配置するのが最も効果的です。会話の途中でユーザーメッセージとしてペルソナを指定した場合、ターンが進むにつれて効力が薄れていきます。システムプロンプトに配置すれば、常に参照される前提条件として維持されます。

ペルソナ指定が特に有効な場面は以下のとおりです。

• 禁止事項が多く、個別にルールを列挙すると冗長になる場合
• 専門分野の判断基準を暗黙的に適用させたい場合
• 出力のトーンや語彙レベルを一貫させたい場合
• 複数ターンにわたってAIの振る舞いを安定させたい場合

出力の型を決める：後工程を安定させる設計

プロンプト設計では、何を出力させるかだけでなく、どんな形式で出力させるかの指定が重要です。出力形式の指定を怠ると、同じプロンプトでも実行のたびに異なるフォーマットの出力が返り、後続の処理が不安定になります。出力の型を選ぶ基準は、その出力を次に何が処理するかです。

後工程	最適な出力形式	対応する手法
人間が読む	Markdown / 自然文	テンプレート/出力フォーマット（Template/Output Formatting）
プログラムが処理する	JSON / XML	JSON/スキーマ誘導出力（JSON/Schema-Guided Output）
データベースに入れる	CSV / TSV	CSV Pattern
繰り返し指示する	独自の略語・タグ	メタ言語作成（Meta Language Creation）
機械処理で分岐する	固定句	決定的フレーズ（Deterministic Phrases）

人間が読む場合は、見出しや箇条書きの構造を持つMarkdownが適しています。プログラムがパースする場合は、JSONやXMLのような構造化フォーマットが必須です。以下のプロンプト例では、出力スキーマを事前に定義することで、出力の構造を安定させています。

以下のレビュー文を分析し、結果をJSON形式で出力してください。

レビュー文：配送は早かったが、商品に傷があった。返品対応は丁寧だった。

出力スキーマ：
{
  "sentiment": "positive" | "negative" | "mixed",
  "topics": ["配送", "商品品質", "カスタマーサポート", ...],
  "summary": "1文の要約"
}

このようにスキーマを明示しておくと、AIはスキーマに沿った形で出力しようとするため、キー名の揺れや型の不一致が起きにくくなります。バッチ処理で数千件のレビューを分析する場面では、この安定性が不可欠です。

決定的フレーズは、AIの出力を固定的な句に限定する手法です。分類タスクであれば、出力はpositive、negative、mixedのいずれか1語のみとしてくださいのように指定します。自由記述を許さないことで、後続の条件分岐処理が確実に動作します。

メタ言語作成は、プロンプト内で独自の略語やタグを定義し、以後の指示を圧縮する手法です。たとえば長いプロンプトの冒頭で、以降@summaryは200文字以内の要約を意味しますと定義しておけば、本文中では@summaryと書くだけで済みます。これは繰り返し登場する指示のトークン消費を削減するプロンプト圧縮の手段として機能します。

正しい情報を与える | 知識設計の手筋

AIが間違える最大の原因は、推論能力の不足ではなく、正しい情報が与えられていないことです。LLMは学習データに含まれない情報について問われると、もっともらしい回答を生成してしまいます。これがハルシネーションの主要な発生メカニズムです。知識設計とは、AIが推論に必要な情報を必要十分に与え、不要な情報は削り、出力の根拠を可視化する設計を指します。

1. 外部知識を注入して、AIの知識の空白を埋める
2. 情報を整えて、限られたトークン予算の中でノイズを除去する
3. 根拠を示させて、出力の信頼性を可視化する

外部知識を注入する：なぜ「知っているはず」が危険か

LLMには学習データの範囲という明確な限界があります。モデルの学習が完了した時点（知識カットオフ（Knowledge Cutoff））より後の情報は持っていません。また、自社の社内文書、非公開の顧客データ、業界固有の用語定義といった情報は、そもそも学習データに含まれていない可能性が高いです。

問題は、AIがこの限界を自覚しないことです。知らない情報について聞かれた場合でも、分かりませんと答える代わりに、学習データ中のパターンから推測した回答を生成します。これがハルシネーションです。対策は、AIが推論を始める前に、必要な情報をプロンプト内に明示的に注入することです。

手法	仕組み	いつ使うか
検索拡張生成（RAG）	検索→取得→プロンプトに注入→回答	社内文書・最新情報を根拠にしたい時
情報注入（Injecting Information）	外部データを直接プロンプトに埋め込む	非公開情報・専門データを推論させたい時
生成知識付与（Generated Knowledge）	AI自身に背景知識を先に生成させてから回答	検索手段がない・一般知識の補強をしたい時
仮想文書埋め込み（HyDE）	仮説文書を先に生成→それを検索クエリに使う	検索精度を上げたい時（検索拡張生成の前処理）

検索拡張生成

最も広く使われている外部知識注入の手法です。ユーザーの質問に関連する文書をデータベースから検索し、その内容をプロンプトに含めた上でAIに回答させます。AIは自分の学習データではなく、注入された文書を根拠に回答するため、ハルシネーションのリスクが大幅に下がります。

情報注入

検索拡張生成のように検索を自動化するのではなく、プロンプトの作成者が手動で必要な情報を埋め込む手法です。たとえば、以下の製品仕様を前提に質問に回答してくださいと指定し、仕様書の内容をプロンプト内に直接貼り付けます。検索システムを構築する必要がないため、小規模な利用では最も手軽な方法です。

生成知識付与

AIに回答させる前に、まず関連する背景知識を自分自身に生成させる手法です。たとえば、まずこのトピックについて知っている事実を5つ挙げてください。次に、その事実を踏まえて以下の質問に答えてくださいというように、2段階で回答させます。検索手段がない場合でも、AIが持っている知識を一度明示的に引き出すことで、推論の精度が向上します。

仮想文書埋め込み

検索精度を上げるためのメタ的な手法です。ユーザーの質問をそのまま検索クエリにすると、質問文と回答文では表現が異なるため、関連文書がヒットしにくいことがあります。仮想文書埋め込みでは、まずAIに仮の回答文（仮想文書）を生成させ、その文章をクエリとして検索します。回答に近い表現で検索するため、関連文書のヒット率が上がるという仕組みです。

情報を整える：トークン予算とノイズ除去

AIに与えられる情報量には物理的な上限があります。これはコンテキストウィンドウと呼ばれるトークン数の制限です。最新のモデルでは数十万トークンまで受け付けるものもありますが、入力が長くなるほどコストが増え、処理速度が低下し、AIの注意が分散して重要な情報を見落とすリスクも高まります。

この制限を前提にすると、何を入れるかだけでなく、何を入れないかが設計判断になります。必要な情報を必要十分な量だけ注入し、ノイズを除去する技術が、プロンプトの情報設計です。

不要な情報を削る：フィルタリング（Filtering）

フィルタリングとは、条件に合わない情報をプロンプトに入れる前に除去する処理です。たとえば検索拡張生成で取得した文書の中に、質問と無関係な段落が含まれている場合、それを除外してからプロンプトに注入します。AIが持つ注意のリソースは有限なので、無関係な情報が多いほど、関連する情報への注意が薄れます。

プロンプト用要約（Summarization for Prompts）

長い文書を要約してからプロンプトに注入する手法です。フィルタリングが不要な部分を削除するのに対し、Summarizationは必要な部分を圧縮して残します。10ページの報告書をそのままプロンプトに入れる代わりに、要点を500文字に圧縮してから注入すれば、トークン消費を大幅に削減しつつ重要な情報を保持できます。

どちらを使うかの判断基準は、情報の構造です。明確に不要な部分が特定できる場合はフィルタリング、全体から要点を抽出する必要がある場合はSummarizationが適しています。

長文を分割して処理する：マップリデュース（Map-Reduce）とリファイン（Refine）

コンテキストウィンドウの上限を超える長文を処理する場合、文書全体を一度にプロンプトに入れることはできません。この場合の定石が、分割して処理し統合する手法群です。

方式	処理の流れ	向いているケース
マップリデュース	分割→各パート要約→統合	長文を一括処理したい時
リファイン	初回要約→追加情報で逐次改善	情報が順次入ってくる時

マップリデュースは、長文を複数のチャンクに分割し、各チャンクを個別に要約した後、全ての要約を統合して最終的な出力を生成する方式です。各チャンクの処理は並列化できるため、大量のデータを効率よく処理できます。ただし、チャンク間の文脈が失われやすいという弱点があります。

リファインは、最初のチャンクで要約を作り、次のチャンクの情報を加えて要約を更新し、さらに次のチャンクで更新する、という逐次的な方式です。各ステップで前の要約を引き継ぐため、文脈の連続性は保たれやすくなります。一方で、チャンク数が増えるほど処理が直列になり、時間がかかります。

根拠を示させる：信頼性の可視化

AIの出力を業務で使う場合、その内容が正しいかどうかを人間が検証する必要があります。しかしAIの出力は通常、結論だけが述べられており、何を根拠にその結論に至ったかが不透明です。根拠を可視化する手法を組み込むことで、検証のコストを下げ、信頼性を高めることができます。

• 出典併記（Cite-While-Answering）：回答の中で出典を併記させる手法。回答の各段落や主張に対して、参照した情報源を明示させます
• 仮定（Assumptions）明示：AIが回答の前提としている仮定を明示させる手法。前提条件が誤っている場合、そこから発見できます
• 事実チェックリスト（Fact Checklist）：AIの出力に含まれる事実主張をリスト化させ、検証すべき項目を明示させる手法。人間のファクトチェック作業を効率化します

出典併記

注入した外部情報が複数ある場合に特に有効です。検索拡張生成で5つの文書を取得してプロンプトに注入した場合、AIの回答がどの文書に基づいているかが分かれば、人間は該当文書だけを確認すればよくなります。回答してください。各主張の末尾に参照元の文書番号を付与してくださいのように指示します。

仮定明示

AIの回答が暗黙の前提に依存している場合に有効です。たとえば最適なマーケティング施策を提案してくださいという質問に対し、AIは予算規模や対象市場について何らかの仮定を置いて回答しますが、通常その仮定は明示されません。回答の冒頭で前提としている仮定を列挙してくださいと指示することで、前提の妥当性を人間が判断できるようになります。

事実チェックリスト

AIの出力を本番で使う前の検証工程として組み込みます。回答の後に、この回答に含まれる事実主張のうち、検証が必要なものをリスト化してくださいと指示すれば、AIが自分の出力を客観視し、検証ポイントを提示します。全てを鵜呑みにするでもなく、全てを手動で検証するでもない、実用的な品質管理の手段です。

AIの思考を導く | 推論設計の手筋

LLMは放っておくと浅く考えます。質問に対して最もありそうな回答をすぐに出力する傾向があり、複雑な推論が必要な場合でも、途中の論理ステップを飛ばして結論に至ることがあります。推論設計とは、AIの思考プロセスを明示的に制御し、深さと正確さを改善するための手筋群です。

1. なぜ考えさせる必要があるのか（出力順序と推論品質の根本原理）
2. 直線的に深く考えさせる（思考の連鎖系）
3. 多角的に考えさせる（思考の分岐系）
4. 大きな問題を小さくする（分解系）
5. 例で教える（パターン学習の設計）

なぜ「考えさせる」必要があるのか：出力順序と推論品質の関係

LLMは自己回帰的なモデルです。これは、直前までに出力したトークンを入力として次のトークンを生成する、という動作を繰り返して文章を作る仕組みを意味します。この仕組みには重要な帰結があります。一度出力したトークンが、その後の出力全体に影響を与えるということです。

この性質が問題を引き起こすのは、AIが推論の前に答えを出力してしまう場合です。たとえば、この投資案件を評価してくださいという質問に対し、AIが冒頭で有望な投資先ですと出力したとします。すると、その後に続く分析は、有望であるという結論を正当化する方向に偏ります。これは人間の確証バイアスに似た現象ですが、LLMの場合はアーキテクチャに起因する構造的な問題です。

この問題への対策は単純です。結論の前に推論過程を出力させることです。まず条件を整理し、次に長所と短所を列挙し、最後に総合評価を述べてくださいのように、出力の順序を設計します。推論過程が先に出力されていれば、結論はその推論に基づいて生成されるため、論理的な整合性が保たれやすくなります。

この原理は、以降で紹介する全ての推論系手筋の土台です。思考の連鎖、思考の木（Tree-of-Thought）、分解系のいずれも、推論を結論より先に出力させるという設計原則を共有しています。

直線的に深く考えさせる：思考の連鎖系

1本の思考の流れを深く伸ばす手筋群です。最も基本的かつ強力な推論設計であり、多くの場面で最初に試すべき手筋です。

手法	一言で言うと	なぜ効くか
思考の連鎖	手順→答えの順で出力させる	推論過程を明示させることで途中の論理飛躍を防ぐ
ゼロショット思考連鎖（Zero-shot CoT）	一歩ずつ考えようと添えるだけ	学習データ中の丁寧な推論文脈を呼び出すトリガーになる
感情プロンプト（Emotion Prompting）	感情的な言葉を添える	感情が込められた学習データには丁寧な記述が多い
再読（RE2 / Re-reading）	プロンプトを再読させる	重要な詳細の見落としを防ぐ
言い換え回答（RaR / Rephrase and Respond）	質問を言い換えさせてから回答	曖昧さを自己解消させる
ステップバックプロンプティング（Step-Back Prompting）	具体的な問題の前に抽象原理を考えさせる	具体に入る前に原理を確認させることで方向を定める

思考の連鎖

2022年にWeiらが提唱した手法で、推論設計の基本形です。プロンプト内に推論過程を含む例を与え、AIにも同じように推論過程を出力させてから最終回答に至らせます。算術問題や論理推論で劇的な精度向上が報告されており、現在ではほぼ全てのプロンプト設計の前提技術となっています。

ゼロショット思考連鎖

CoTの中でも最もシンプルな形です。例を一切与えず、一歩ずつ考えてくださいの一言を添えるだけで、AIが自発的に推論過程を出力するようになります。

以下の問題に答えてください。一歩ずつ考えてから最終的な答えを出してください。

問題：ある店で定価2,000円の商品を20%引きで購入し、さらに10%のポイント還元を受けた。実質的な支出額はいくらか？

なぜこの一言だけで効果があるのでしょうか。LLMの学習データの中で、step by stepやlet’s think through thisといった表現が使われている文脈は、丁寧で正確な推論が含まれるものが多い傾向にあります。この一言はその文脈を呼び出すトリガーとして機能し、AIの出力を推論的なモードへと切り替えます。

感情プロンプト

Li et al.（2023）の研究で提案された手法で、これは私のキャリアにとって非常に重要な課題ですのような感情的な表現をプロンプトに添えるだけで精度が向上するという知見に基づいています。直感に反しますが、これもゼロショット思考連鎖と同じ原理で説明できます。学習データの中で感情が込められた文章は、丁寧に推敲されたものが多く、その文脈が呼び出されることで出力の質が向上すると考えられています。

再読

プロンプトの最後にもう一度問題文を再掲し、AIに改めて読ませる手法です。長いプロンプトの冒頭にある条件をAIが見落とすことを防ぐ効果があります。言い換え回答は、まずこの質問を自分の言葉で言い換えてから回答してくださいと指示する手法です。曖昧な質問をAI自身に解釈させることで、意図の取り違えを減らします。

ステップバックプロンプティング

具体的な問題に取り組む前に、背景にある一般原則を先に考えさせる手法です。東京からロンドンへの最安航空券を探すという具体的タスクの前に、国際航空券の価格を決める要因にはどのようなものがありますかと問いかけることで、AIがより体系的に回答できるようになります。

多角的に考えさせる：思考の分岐系

連鎖系が1本の思考を深く伸ばすのに対し、分岐系は複数の思考パスを同時に走らせ、比較・統合する手筋群です。連鎖系との根本的な違いは、間違ったルートに入った時に修正できるかどうかにあります。1本の線で深く考えている途中で誤った前提に基づいてしまった場合、連鎖系ではそのまま誤った結論に至ります。分岐系では、別のパスが正しい結論に到達していれば、そちらを選択できます。

手法	一言で言うと	なぜ効くか
思考の木	分岐探索で複数の思考パスを評価	行き止まりに気づいた時にバックトラックできる
思考のグラフ（Graph-of-Thought / GoT）	思考をグラフ構造で表現	非線形な推論（統合・分岐・合流）を可能にする
自己整合性（Self-Consistency）	同じ問題を複数回解かせて多数決	単一の推論パスへの依存を排除する
対比CoT（Contrastive CoT）	正しい推論と間違った推論の両方を例示	何が間違いかを知ることで正解率が上がる

思考の木

推論をツリー構造で展開する手法です。各ステップで複数の候補を生成し、それぞれを評価した上で有望なパスだけを深掘りします。行き止まりに到達した場合は、前のノードまで戻って別のパスを探索できます。将棋やチェスの読みに近い構造で、特に戦略立案や創造的な問題解決に適しています。ただし、1回の問い合わせでは実現しにくく、複数回のAPI呼び出しやエージェント的な実装が必要になる場合が多いです。

思考のグラフ

ToTをさらに一般化し、ツリーだけでなくグラフ構造（合流・分岐・統合）を許容する手法です。たとえば、あるパスで得られた洞察を別のパスに統合するような非線形な推論が可能になります。研究段階の手法であり、実務での活用はまだ限定的ですが、複雑な分析タスクでの可能性が注目されています。

自己整合性

分岐系の中で最も実装が簡単な手法です。同じ問題を複数回（通常5回から10回）解かせ、最も多く出現した答えを最終回答として採用します。各回の推論パスは異なるため、特定のパスに依存した誤りを排除できます。APIのtemperatureパラメータを上げて出力のばらつきを意図的に増やすことで、多様なパスが生成されやすくなります。

対比CoT

正しい推論例だけでなく、間違った推論例も同時に提示する手法です。ここが間違い、なぜなら～だからと明示することで、AIが同じ種類の誤りを避けるようになります。人間の学習でも、正解だけでなく典型的な間違いを知ることで理解が深まるのと同じ原理です。

大きな問題を小さくする：分解系

複雑な問題をそのまま一度に解こうとすると、人間もAIも失敗します。分解系は、大きな問題を扱いやすい小さな部分に分け、それぞれを解いた上で統合する手筋群です。

手法	分解の方向性	いつ使うか
分解/サブクエスチョン（Decomposition/Subquestion）	主要課題を補助質問に分ける	複合的な問いに正確に答えたい時
最小から最大（Least-to-Most）	易→難の順に下位問題を解く	前の答えが次の前提になる時
思考の骨格（Skeleton-of-Thought）	骨子を先に生成→後から肉付け	長い文章や報告書を生成する時
思考のプログラム（Program-of-Thoughts / PoT）	推論をコードとして書かせる	計算ミスを防ぎたい時（外部実行で検証可能）

分解/サブクエスチョン

複合的な質問を補助質問に分解する基本手法です。この新規事業は成功するかという大きな問いに対し、市場規模はどの程度か、競合の参入障壁はあるか、技術的な実現可能性はあるかといった補助質問に分解してから、それぞれを回答させ、最後に統合します。AIが見落としやすい観点を補助質問として事前に設計できる点が強みです。

最小から最大

難易度の低い問題から順に解かせる手法です。前のステップの答えが次のステップの前提として使われるような構造の問題に適しています。たとえば、多段階の計算問題や、因果関係が連鎖する分析タスクで効果を発揮します。

思考の骨格

まず回答の骨子（アウトライン）だけを生成させ、次に各項目の本文を埋めていく手法です。長い文章を一度に生成させると、途中で構成が崩れたり、重要な要素が抜け落ちたりすることがあります。骨子を先に確定させることで、全体の構成を保証した上で詳細を展開できます。

思考のプログラム

推論過程を自然言語ではなくコード（Pythonなど）として出力させる手法です。特に算術を含むタスクで有効です。LLMは自然言語での推論中に計算ミスを起こすことがありますが、コードとして出力させれば、そのコードを実際に実行することで計算結果の正確性を検証できます。

例で教える：パターン学習の設計

ここまで紹介した手筋は、全て指示文によってAIの振る舞いを制御するアプローチでした。しかし、言葉で説明しにくいパターンを伝える場合には、例を示すアプローチが有効です。フューショットプロンプティング（Few-shot Prompting）は、入力と出力のペアを数例示すことで、AIにパターンを学習させる手法です。

指示と例の使い分け

全てのタスクにFew-shotが必要なわけではありません。指示文で十分な場合と、例がなければ伝わらない場合があります。

状況	指示が向いている	例が向いている
ルールが明文化できる	✓
パターンが暗黙的・感覚的		✓
エッジケースが多い		✓
トークンを節約したい	✓
出力形式を厳密に統一したい		✓

指示が向いているのは、ルールを明確に言語化できる場合です。200文字以内で要約してくださいのように、条件を文章で書けるならそれが最も効率的です。一方、企業のブランドトーンに合った文章を書いてくださいのように、言語化が難しい暗黙的なパターンを伝えたい場合は、実際の例を見せる方が正確に伝わります。

Few-shot設計の3原則

例を設計する際に押さえるべき原則は3つあります。

1. 数：通常3〜5個が目安です。1〜2個ではパターンが伝わりにくく、偶然の一致として処理される可能性があります。一方で多すぎるとトークンを圧迫し、処理コストが増大します
2. 多様性：正常なケースだけでなく、エッジケースや境界例を含めます。全ての例がpositive/商品品質だけでは、negativeや配送のケースでの振る舞いが定まりません
3. 一貫性：全ての例で入力と出力のフォーマットを統一します。これはPrefix Designと呼ばれ、フォーマットの一貫性がパターン認識の精度に直結します

以下のプロンプト例では、3原則がどのように実践されているかを確認できます。

以下のルールに従って、カスタマーレビューを分類してください。

レビュー：サイズがぴったりで気に入っています
分類：positive / 商品品質

レビュー：届くまでに2週間もかかった
分類：negative / 配送

レビュー：デザインは好きだけど縫製が雑
分類：mixed / 商品品質

レビュー：カスタマーサポートが親切に対応してくれた
分類：

3例でsentiment軸（positive、negative、mixed）とtopic軸（商品品質、配送）の両方を網羅しています。また、全例がレビュー：→分類：の統一されたフォーマットで記述されているため、AIは入出力のパターンを正確に読み取ります。

Few-shot系の手法バリエーション

基本的なFew-shotにはいくつかのバリエーションがあり、タスクの性質に応じて使い分けます。

手法	特徴	いつ使うか
フューショットプロンプティング	入出力ペアを数例示す	パターン学習の基本形
状況-行動プロンプティング（Situation-Action Prompting）	状況→行動の形式で例示	判断・意思決定タスク
思考-行動パターン（Think-Action Pattern）	思考→行動の中間過程も例示	推論過程も学ばせたい時
理由付け付きフューショット（Rationale-Augmented Few-shot）	例に理由づけを含める	なぜその答えかも教えたい時

状況-行動プロンプティングは、状況：顧客がクレームを申し出た→行動：まず謝罪し、次に具体的な対処案を提示するのように、判断を伴うタスクの例を状況と行動のペアで示す手法です。単純な入出力ペアよりも、意思決定の文脈が明確に伝わります。

思考-行動パターンは、Few-shotの例に推論過程（思考）を含める手法です。入力：〇〇→思考：△△だから□□と判断→出力：××のように、なぜその出力に至ったかの推論も含めて例示します。思考の連鎖とFew-shotの組み合わせであり、推論の精度と出力パターンの安定性を同時に高められます。

理由付け付きフューショットは、例に理由づけを明示的に付与する手法です。正解だけでなく、なぜその正解になるのかを例の中に書き込むことで、AIが表面的なパターンマッチではなく、根底にある判断基準を学習できるようになります。

対話で磨く | フロー設計の手筋

優れたプロンプトエンジニアは、1回のプロンプトで完璧を目指しません。会話全体を1つのプログラムとして設計し、対話の流れの中で精度を高めていきます。1回の入出力で解決できるタスクには限りがあります。複雑なタスクほど、複数のターンを戦略的に使うフロー設計が有効です。

1. 会話全体をプログラムとして捉える視点
2. 対話の主導権を誰が持つかの設計
3. 反復と分岐を使った精度の向上
4. 長い対話で文脈が失われない状態管理

会話全体をプログラムと捉える

AIとの対話を1回の質問と回答ではなく、入力→処理→出力→フィードバックが繰り返されるプログラムとして捉えると、設計の幅が大きく広がります。この視点を会話プロンプト（Conversation as Prompt）と呼びます。会話のログ全体が、そのままAIへの巨大なプロンプトとして機能しているということです。

この考え方を進めると、Prompt as Programという概念に至ります。プロンプトの中に条件分岐や繰り返しに相当する構造を埋め込むことで、AIの動作をプログラムのように制御できます。もし〇〇であれば△△してください、そうでなければ□□してくださいという条件分岐や、以下の項目それぞれについて、同じフォーマットで回答してくださいという繰り返し処理は、いずれもプロンプトをプログラムとして設計している例です。

Seed Instructionは、会話の方向性を決める最初の一手です。会話の冒頭で与える指示が、その後の全てのターンのAIの振る舞いに影響を与えます。たとえばあなたはコードレビュアーです。私がコードを貼るたびに、バグの有無、改善点、セキュリティリスクの3点を評価してくださいという最初の指示があれば、以降はコードを貼るだけで毎回同じ形式のレビューが返ります。Seed Instructionの質が、会話全体の生産性を決めます。

主導権を設計する：誰が質問し誰が答えるか

通常のAI対話は、人間が質問しAIが回答するという一方向の流れです。しかし、この主導権を意図的に反転させることで、対話の質が大きく変わる場面があります。特に、人間が何を伝えればよいか自分でも分かっていない場合、AIに質問させることで必要な情報が効率的に引き出されます。

手法	主導権	どういう場面で使うか
反転インタラクション（Flipped Interaction）	AI→人間	人間が何を伝えるべきか分からない時
質問リファイン（Question Refinement）	AI→人間（提案型）	質問が曖昧で改善の余地がある時
コグニティブ検証（Cognitive Verifier）	AI内部	複雑な質問をサブ質問に分解して統合したい時
ソクラテス式プロンプティング（Socratic Prompting）	AI→人間（教育型）	理解を深めさせたい・答えを与えず考えさせたい時
追加情報要求（Ask-for-Input）	AI→人間（明示型）	AIの暴走を防ぎ、1手ずつ進めたい時

反転インタラクション

主導権をAIに完全に渡す手法です。以下のプロンプト例を見てみましょう。

あなたはプロの採用面接官です。
これから私にバックエンドエンジニアの採用面接を実施してください。

ルール：
- 1回につき1つだけ質問する
- 私の回答に基づいて次の質問を決める
- 5問終了後に総合評価を出す
- 質問の難易度は徐々に上げる

このプロンプトでは、人間は自分の経験やスキルを事前に網羅的に整理する必要がありません。AIが適切な順序で質問を重ねることで、必要な情報が自然に引き出されます。要件定義、ヒアリング、問診、面接など、構造化された情報収集が必要な場面で特に有効です。

質問リファイン

ユーザーの質問をそのまま回答するのではなく、AIにまず質問自体の改善案を提示させる手法です。あなたの質問をより具体的で回答しやすい形に書き直しました。以下の修正版で回答してよろしいですかとAIに提案させることで、曖昧な質問から始まっても精度の高い回答に到達できます。

コグニティブ検証

複雑な質問をAIが内部でサブ質問に分解し、各サブ質問に回答した上で統合する手法です。ユーザーからは1つの質問を投げるだけですが、AIが自律的に分解→個別回答→統合のプロセスを実行します。

ソクラテス式プロンプティング

AIが答えを直接与えるのではなく、質問を返すことで人間の思考を促す手法です。教育や思考訓練の場面で使われます。追加情報要求は、AIが次のステップに進む前に必ず人間の確認を取るよう設計する手法です。AIが自律的に作業を進めすぎて意図しない方向に進むことを防ぐ安全弁として機能します。

反復と分岐で精度を上げる

の対話で完璧な出力を得ようとすることは、多くの場合、非現実的な期待です。代わりに、複数回のやり取りを通じて段階的に出力を洗練するアプローチが有効です。

反復改善（Iterative refinement）

最も基本的なアプローチで、AIの出力に対して修正指示を重ねることで段階的に精度を上げます。最初の出力をドラフトと位置づけ、もう少し具体的に、もっと短く、専門用語を減らしてのように修正を指示します

フィードバックループ（Feedback Loop）

AIの出力をそのまま次のターンの入力として使う循環構造です。たとえば、最初にアイデアを生成させ、次にそのアイデアの批評を生成させ、さらにその批評を踏まえてアイデアを改善させるという循環を回します

分岐探索（Branching Exploration）

1つの方向に行き詰まった時に、別のアプローチを試す分岐的な探索です。新しいチャットを開いて別の角度からやり直すのも立派な分岐探索です

無限生成（Infinite Generation）

停止を指示するまで同じ形式の出力を連続生成させるバッチ量産手法です。以下の形式でキャッチコピーの候補を生成し続けてください。stopと入力するまで停止しないでくださいのように指示します

反復改善で重要なのは、修正指示の具体性です。もっとよくしてのような曖昧な指示では改善の方向が定まりません。第2段落の数値例を製造業のケースに変えてくださいのように、どこを、どう変えるかを明示することで、修正の精度が上がります。

フィードバックループは手動で回すこともできますが、プロンプトの中にループ構造を埋め込むことで自動化もできます。以下の手順を3回繰り返してください：1. 回答を生成 2. 改善点を指摘 3. 改善点を反映して書き直しのように指示すれば、1回のプロンプトで複数回の反復改善が実行されます。

状態と文脈を管理する：会話が長くなっても破綻しない設計

LLMは本質的にステートレスです。毎ターンの入力に対して出力を生成するだけで、前のターンの情報を記憶しているわけではありません。会話が成り立っているように見えるのは、会話履歴がプロンプトの一部として毎回再送されているからです。

この仕組みは、会話が長くなるほど問題を引き起こします。会話履歴がコンテキストウィンドウの上限に近づくと、古い履歴が切り捨てられたり、AIの注意が分散して初期の指示を見落としたりします。以下の手法群は、この問題に対処するための設計パターンです。

手法	一言で言うと	使い方
スクラッチパッド（Scratchpad）	中間計算を書き留めさせる	途中計算を[Scratchpad: …]内に記述させる
状態圧縮（State Compression）	状態を1行に圧縮して毎ターン再注入	複雑な状態を簡潔なテキストに凝縮
要約して想起（Summarize-then-Recall）	会話の要約を作り必要時に再投入	長い会話の節目で要約を作成・保存
末尾追記（Tail Generation / Self-Reminder）	毎ターン末尾にルールや状態を再掲	ロール・ルール・次の入力を末尾に付ける
文脈接木（Context Grafting）	親・兄弟ノードの情報を再注入	大きな文書を部分展開する際に全体との一貫性を維持
意図的忘却（Forget on Purpose）	悪いパターンを断つために文脈を捨てる	会話が悪い方向に偏った時にリセット

スクラッチパッド

スクラッチパッドは、AIに中間計算や作業メモを特定のタグ内に書き留めさせる手法です。複数ステップの計算や分析タスクで、途中結果を明示的に記録させることで、ステップ間の情報が失われることを防ぎます。

状態圧縮

状態圧縮は、長い会話の現在の状態を簡潔なテキストに圧縮し、毎ターンの冒頭で再注入する手法です。

【ターン1：人間】
新規ECサイトのデータベース設計を手伝ってください。

【ターン1：AI】
（テーブル設計の提案 … 長い出力）

【ターン2：人間】
現在の状態を1行で圧縮してください。以降のターンでは毎回この圧縮状態を冒頭に再掲してから回答してください。

【ターン2：AI】
[状態] ECサイトDB設計中。確定：usersテーブル(id,email,name,created_at)、productsテーブル(id,name,price,stock)。未決：注文・決済・配送の3テーブル。次：ordersテーブルのカラム設計。

【ターン3：人間】
（圧縮状態を冒頭に貼り付けて）ordersテーブルを設計して。

圧縮された状態が毎ターン再注入されるため、会話が数十ターンに及んでも、AIは現在の状況を正確に把握できます。手動で貼り付けることもできますし、APIを利用している場合はシステムプロンプトに自動で挿入する実装も可能です。

要約して想起

要約して想起は、状態圧縮の拡張版です。一定のターン数ごとに会話全体の要約を生成し、新しいセッションの冒頭にその要約を注入することで、コンテキストウィンドウの上限を超える長い対話を継続できます。

末尾追記

末尾追記は、AIの出力の末尾に、次のターンで必要なルールや状態を毎回再掲させる手法です。AIはコンテキストの冒頭と末尾の情報に注意を払いやすい傾向があるため、末尾にルールを再掲することで、長い会話の途中でルールが忘れられることを防ぎます。

文脈接木

文脈接木は、大きな文書を章ごとに分割して処理する際に、現在処理中の章だけでなく、全体の目次や前後の章の要約も一緒にプロンプトに注入する手法です。部分だけを見て全体との一貫性が崩れることを防ぎます。

意図的忘却

意図的忘却は、あえて会話履歴を捨ててリセットする手法です。AIが会話の途中で誤った解釈や不適切なパターンに嵌まり込んだ場合、その会話を続けるよりも、新しいチャットを開いて正しい方向から再スタートした方が効率的なことがあります。悪い文脈は引きずるより断ち切る方が有効です。

品質を担保する | 評価・安定化の手筋

AIの出力は常に正しいとは限りません。同じプロンプトでも実行のたびに出力が揺れることがありますし、一見もっともらしい回答の中に事実誤認が紛れていることもあります。品質を担保するとは、これらの不安定さを設計レベルで制御する仕組みを組み込むことです。

1. AI自身に出力を評価・改善させる自己改善ループ
2. 複数の出力を比較・統合して安定させるアンサンブル
3. 出力の暴走を防ぐガードレール設計
4. プロダクトやチームで運用する評価パイプライン

AI自身に評価させる：自己改善ループの設計

AIに一度生成した出力を自分自身で評価させ、弱点を特定し、改善版を生成させる。この自己改善ループは、外部の評価者を必要としない最も手軽な品質向上手段です。

手法	ループの流れ	特徴
自己批評（Self-Critique）	初稿→自己講評→改訂版	最も基本的な自己改善パターン
自己リファイン（Self-Refine）	出力→評価＋弱点→修正を自動反復	反復回数を指定して自動化できる
リフレクション（Reflexion）	失敗経験をメモ→次の試行で方針更新	過去の失敗から学ぶ設計
検証の連鎖（Chain of Verification / CoVe）	出力→検証質問生成→自己回答→修正	事実の正確性に特化した検証パイプライン
憲法型AI（Constitutional AI）	出力→規範に照らして批評→自己修正	安全性・倫理面の品質担保に有効

自己批評

自己批評は最も基本的な形で、3ステップで構成されます。

【ステップ1：初稿生成】
以下のテーマについてブログ記事の導入文を書いてください。
テーマ：リモートワークの生産性

【ステップ2：自己講評】
上記の導入文を以下の観点で講評してください。
- 読者の関心を引けているか
- 主張が明確か
- 具体性があるか
各観点について5点満点で採点し、改善点を箇条書きで挙げてください。

【ステップ3：改訂】
講評の内容を反映して、導入文を書き直してください。

このプロンプト例のポイントは、ステップ2で講評の観点を明示していることです。どの観点で評価するかを指定しなければ、AIは曖昧な講評しか出力しません。観点を具体的に与えることで、評価の質そのものをコントロールできます。この3ステップは1回のプロンプトで全て実行させることも、ターンを分けて段階的に進めることもできます。

自己リファイン

自己リファインは、自己批評のループを自動で複数回繰り返す拡張版です。以下のプロセスを3回繰り返してくださいのように反復回数を指定することで、手動の介入なしに段階的な改善が行われます。

リフレクション

リフレクションは、エージェント的な設計で使われる手法です。タスクの実行に失敗した場合、その失敗の原因と教訓をメモとして保存し、次の試行でそのメモをプロンプトに含めることで、同じ失敗を繰り返さないようにします。自己批評や自己リファインが1つの出力を磨くのに対し、リフレクションは試行全体を通じた学習を実現します。

検証の連鎖

検証の連鎖は、事実の正確性に特化した自己検証パイプラインです。AIの出力に含まれる事実主張を一覧化し、各主張に対して検証質問を生成し、その質問にAI自身が回答し、矛盾があれば元の出力を修正します。ハルシネーションの検出と修正に特化した設計です。

憲法型AI

憲法型AIは、Anthropicが開発した手法で、事前に定義した規範（憲法）に照らして出力を批評・修正させます。安全性・倫理性の担保に有効で、出力に差別的な表現が含まれていないか、偏った情報提供になっていないかといった観点での自動チェックに使われます。

複数の視点で安定させる：アンサンブルと討論

自己改善ループは1つのAIが自分自身を評価するため、盲点が生まれることがあります。この弱点を補うのが、複数の視点を導入する手法群です。

• 自己整合性：同じ問題を複数回解かせ、最も多く出現した答えを最終回答として採用します。各回の推論パスが異なるため、特定のパスに起因する誤りを排除できます。推論設計の節でも触れましたが、品質安定化の観点でも有効です
• マルチエージェント討論（Multi-Agent Debate）：1つのプロンプト内でAIに複数の役割（賛成派、反対派、審判）を演じさせ、議論を通じて結論を導く手法です。1つの視点だけで結論を出す場合よりも、反論を経た結論の方が堅牢になります
• 審判役LLM／クロスモデル評価（LLM-as-Judge / Cross-Model Evaluation）：生成に使ったモデルとは別のモデル（またはより強いモデル）に出力の品質を採点させる手法です。自己評価のバイアスを排除でき、特に自動採点パイプラインの構築で多用されます

自己整合性は実装が最も簡単です。APIのtemperatureを上げて同じプロンプトを5回実行し、多数決を取るだけです。コストは5倍になりますが、精度が重要なタスクでは費用対効果に見合います。

マルチエージェント討論は、1回の対話内で実行できます。以下の3つの立場からそれぞれ意見を述べた後、審判として最終的な結論を出してくださいのように指示します。重要な意思決定や、賛否が分かれるテーマの分析で有効です。

審判役LLMは、プロダクトで大量の出力を評価する際に不可欠な手法です。人間が全ての出力を目視確認することが現実的でない場合、別のLLMに採点基準（ルーブリック）を与えて自動評価させます。評価モデルには生成モデルと同等以上の性能を持つモデルを使うことが推奨されます。

出力を制約する：暴走を防ぐガードレール設計

AIの出力が期待を外れるパターンはいくつかに類型化できます。それぞれのパターンに対して、事前に制約を設計しておくことで暴走を防止できます。

暴走パターン	対策手法	具体的な実装
長すぎる出力	暴走防止ガード／出力制約（Anti-Runaway Guard / Output Constraint）	文字数・段落数の上限を指定
フォーマット違反	形式準拠チェック（Format Compliance Check）	出力形式のチェック工程を追加
禁止事項の出力	ガードレール（Guardrails）	ルートプロンプトで禁止ルールを定義
個人情報の漏洩	PII匿名化／マスキング（PII De-identification / Redaction）	マスキングルールを事前定義
不要情報の混入	意味フィルタ／必要情報のみ保持（Semantic Filter / Keep-only フィルタリング）	意味ベースで必要な情報のみ保持

暴走防止ガード／出力制約

長すぎる出力は、最も頻繁に発生する暴走パターンです。回答は200文字以内で、3段落以内で回答してくださいのように明示的な上限を設定することで対処します。APIを利用している場合はmax_tokensパラメータでもハードリミットを設定できます。

形式準拠チェック

形式準拠チェックは、出力が指定したフォーマットに準拠しているかを検証する後処理です。JSON形式を指定したのに自然文が返ってきた場合や、CSVの列数が一致しない場合に、再生成を要求するロジックを組み込みます。

ガードレール

ガードレールは、AIが出力すべきでない内容を事前に定義するルールです。システムプロンプト内に以下の話題には回答しない、競合他社の製品を推奨しない、投資助言に該当する表現を使わないのような禁止ルールを記述します。

PII匿名化／マスキング

PII匿名化／マスキングは、AIの出力に個人情報（Personal Identifiable Information）が含まれていた場合に、自動でマスキングまたは除去する仕組みです。入力データに個人情報が含まれている場合、AIがそれを出力に含めてしまうリスクがあります。出力に個人名が含まれていた場合は[PERSON]に置き換えてくださいのようなルールを定義します。

マスキングポリシー

Masking Policy（マスキングポリシー）は、特定のカテゴリの情報を一律でマスクするルールセットです。Confidence Tagging（確信度タグ付け）は、AIの回答の各部分に対して、確信度（高・中・低）を自己申告させる手法です。確信度が低い部分を人間が重点的に検証することで、限られたレビュー時間を効率的に配分できます。

運用レベルの品質管理：評価パイプラインの構築

個人が1つのプロンプトを手動で磨く段階を超えて、プロダクトやチームでプロンプトを運用する場合には、仕組みとしての品質管理体制が必要になります。プロンプトの品質管理は、ソフトウェア開発のテスト体制と同じ構造を持っています。

構成要素	役割	対応する手法
生成	プロンプトで出力を生成	（本記事の全手法）
自動採点	AIが出力を評価・スコアリング	審判役LLM／Few-shot採点／ルーブリック（LLM-as-Judge / Few-shot Grader / Rubric）
閾値判定	スコアに基づき合否を分ける	合否閾値（Scoring Threshold）
再生成 or エスカレーション	低スコアは再試行または人手へ	自動評価パイプライン／ヒューマン・イン・ザ・ループ（Auto-Eval Pipeline / Human-in-the-Loop）
回帰テスト	モデル更新時の劣化を検出	プロンプト回帰テスト（Prompt Regression Test）
正解データ	採点器の妥当性を定期確認	キャリブレーション例（Calibration Examples）

自動採点

自動採点は、審判役LLMの仕組みを使って出力の品質をスコアリングする工程です。採点基準（ルーブリック）を事前に定義し、各出力を1〜5点のスケールで評価させます。たとえば、回答の正確性：指定された情報源のみに基づいているか / 網羅性：質問の全ての側面に回答しているか / 簡潔性：冗長な記述がないかといった観点を設定します。

合否閾値

合否閾値は、自動採点の結果に対する合格ラインです。たとえば全項目の平均が3.5点以上であれば自動で通過、2.5点以下であれば人手のレビューに回す、それ以外は再生成するといったルールを設定します。この仕組みにより、人間のレビューが必要な出力だけをフィルタリングでき、レビューコストを大幅に削減できます。

プロンプト回帰テスト

プロンプト回帰テストは、モデルの更新やプロンプトの変更が品質に悪影響を与えていないかを検証するテストです。事前に用意した入力セット（テストケース）に対してプロンプトを実行し、出力の品質スコアが以前のバージョンと比較して劣化していないかを確認します。ソフトウェア開発における回帰テストと同じ発想です。

キャリブレーション例

キャリブレーション例は、採点器そのものの妥当性を定期的に検証するための正解付きデータセットです。審判役LLMが正しく採点できているかを確認するには、人間が正解を付けた少数のサンプル（通常20〜50件）が必要です。この正解データに対して採点器を定期的に実行し、人間の評価との一致度を確認します。一致度が低下した場合は、採点基準の見直しが必要です。

システムとして動かす | エージェント時代のプロンプト設計

プロンプトエンジニアリングの最終到達点は、人間が毎回介入しなくてもAIが自律的に動くシステムの設計です。ここまで紹介してきた全てのセオリー、つまり意図の伝達、知識の注入、推論の設計、対話の制御、品質の担保は、このシステム設計に合流します。

1. エージェントループの構造とプロンプトの位置づけ
2. ツール連携のためのプロンプト設計
3. 個別パターンを組み合わせる複合設計の原則
4. プロンプトからコンテキストエンジニアリングへの発展

エージェントループとプロンプトの関係

エージェントAIの動作は、以下の5ステップを繰り返すループとして理解できます。

1. プロンプト構築（Prompt Construction）：現在の状態、タスクの指示、利用可能なツールの情報を組み立ててプロンプトを生成する
2. LLMに送信・応答取得：構築したプロンプトをLLMに送り、応答を受け取る
3. 応答を解析（Response Parsing）：LLMの出力から、次に取るべき行動（ツール呼び出し、回答生成など）を抽出する
4. 行動を実行（Programmatic Action）：抽出された行動をプログラムとして実行する（API呼び出し、データベース操作、ファイル生成など）
5. 結果をフィードバック（State Accumulation）：行動の結果を状態に追加し、ステップ1に戻る

このループの中で、プロンプトは毎ターン動的に構築されます。固定のプロンプトを繰り返し使うのではなく、前のステップの結果やツールの出力を反映して、毎回新しいプロンプトが組み立てられます。これがプログラマティック・プロンプティング（Programmatic Prompting）と呼ばれる概念です。

ループをいつ終了するかの設計（Loop Termination）もプロンプトの責務です。

AIの出力にFINALという文字列が含まれたら終了する、3回連続で新しい情報が得られなければ終了するといった終了条件をプロンプト内に定義します。終了条件が曖昧だと、エージェントが無限ループに陥るリスクがあります。

ツール連携のためのプロンプト設計

エージェントがAIのチャットと異なるのは、外部のツールを使えることです。

検索、計算、API呼び出し、コード実行、データベース操作など、LLM単体では不可能な処理をツールとして組み込むことで、AIの能力を大幅に拡張できます。ツール連携のプロンプト設計は、どのツールをいつ使うかの判断をAIに委ねるための設計です。

手法	仕組み	得意なタスク
ファンクションコーリング／ツール利用（Function Calling / Tool Use）	構造化引数でAPI/ツールを起動	外部サービスとの連携全般
リアクト（ReAct）	推論（Reason）→行動（Act）を交互に実行	情報収集しながらの意思決定
プログラム支援LM（PAL / Program-Aided LM）	計算やロジックをコードで外部実行	正確な計算が必要なタスク
自己質問＋検索（Self-Ask with Search）	追問を自動生成し都度検索で補強	事実に基づく回答が必要な時
計画-実行（Plan-Execute）	計画→逐次実行→結果で計画更新	複数ステップのプロジェクト型タスク
MRKL／ルーター（MRKL / Router）	問題に応じて専門モジュールへ振り分け	多種多様な質問を1つの窓口で処理
出力自動化（Output Automater）	結果を実行可能なスクリプトで出力	反復作業の自動化

ファンクションコーリング／ツール利用

AIがツールを呼び出すための最も基本的な仕組みです。利用可能なツールの一覧（名前、説明、引数の型）をプロンプトに含め、AIにどのツールをどの引数で呼ぶかを判断・出力させます。主要なLLMプロバイダ（Anthropic、OpenAI、Googleなど）がネイティブにサポートしている機能です。

リアクト

エージェント設計で最も広く使われているパターンです。推論（Thought）→ 行動（Action）→ 観察結果（Observation）を交互に繰り返すことで、AIが中間結果を確認しながら次のステップを決定します。

以下の質問に答えてください。Thought / Action / Observationの形式で推論と行動を交互に繰り返してください。

質問：2024年のノーベル物理学賞の受賞者は、どの大学に所属していたか？

Thought 1: まず2024年のノーベル物理学賞の受賞者が誰かを調べる必要がある。
Action 1: search("2024 Nobel Prize Physics winner")
Observation 1: （検索結果が返る）

Thought 2: 受賞者が分かったので、所属大学を調べる。
Action 2: search("受賞者名 university affiliation")
Observation 2: （検索結果が返る）

Thought 3: 情報が揃ったので回答をまとめる。
Answer: …

リアクトの強みは、AIが行動の前に推論を出力することで、なぜその行動を取るのかが透明になる点です。デバッグが容易で、意図しないツール呼び出しを発見しやすくなります。LangChainやLlamaIndexなどの主要なエージェントフレームワークの内部でも、リアクトの構造が広く採用されています。

プログラム支援LM

計算やロジックをコードとして出力させ、そのコードを外部で実行する手法です。LLMは自然言語での計算を誤ることがありますが、Pythonコードとして出力させれば、実行環境が正確な計算結果を返します。

自己質問＋検索

AIが回答を生成する過程で、自分自身に追加の質問を生成し、その都度検索を実行して情報を補強する手法です。これは私が知らない情報だ → 調べよう → 調べた結果を踏まえて回答を更新するというプロセスが自動化されます。

計画-実行

まずタスク全体の実行計画を立て、その計画に沿って各ステップを逐次実行し、途中結果に応じて計画を更新する手法です。リアクトがステップごとに即興的に判断するのに対し、計画-実行は俯瞰的な計画を持って行動します。複数ステップのプロジェクト型タスクで有効です。

MRKL／ルーター

ユーザーの入力を分析し、適切な専門モジュール（計算モジュール、検索モジュール、データベースクエリモジュールなど）に振り分けるルーター型の設計です。1つのプロンプトで全てを処理するのではなく、タスクの種類に応じて最適な処理経路を選択します。

出力自動化

AIの出力を人間が読むテキストではなく、実行可能なスクリプトやコマンドとして生成させる手法です。分析結果をCSVに保存するPythonスクリプトとして出力してくださいのように指示すれば、結果がそのまま自動化パイプラインに組み込めます。

パターンを組み合わせる：複合設計の原則

ここまで紹介してきた手筋は、個別に使っても効果がありますが、実際の複雑なタスクでは複数のパターンを組み合わせて使うことがほとんどです。パターンの組み合わせ方にもセオリーがあります。

組み合わせの3原則

• パターン合成（Pattern Composition）：複数のパターンに異なる役割を分担させます。たとえば、Personaで方向性を定め、CoTで推論させ、Template Patternで出力を整形するという組み合わせでは、各パターンが互いに干渉せずそれぞれの役割を果たします
• 順序感度（Order Sensitivity）：プロンプト内の指示の配置順序が効果に直結します。LLMはコンテキストの冒頭と末尾に配置された情報に注意を払いやすい傾向があります。最も重要な指示は冒頭に、忘れてほしくないルールは末尾に配置するのが定石です
• 小目標の縫い合わせ（Subgoal Stitching）：大きな目標を小さな目標に分解し、各小目標に適したパターンを当てはめて順に縫い合わせます。レポートの自動生成であれば、骨子作成には思考の骨格、各セクションの執筆にはPersona + CoT、品質チェックには自己批評を適用するというように、工程ごとに最適なパターンを選択します

組み合わせの具体例

以下の表は、実際のタスクでどのようにパターンを組み合わせるかの具体例です。

タスク例	使うパターンの組み合わせ	それぞれの役割
長文レポートの自動生成	Outline Expansion + Context Grafting + Template	骨子作成→部分展開→全体一貫性維持→出力整形
対話型データ収集	反転インタラクション + 追加情報要求 + Menu Actions	AIが質問→1手ずつ進行→コマンドで操作
品質付き自動翻訳	Persona + CoT + Self-Critique + Format Compliance	翻訳者役割→推論過程→自己評価→形式チェック

長文レポートの自動生成では、まずOutline Expansionで全体のアウトラインを生成し、各セクションを個別に展開します。このとき、文脈接木で全体の構成情報を各セクションの生成時に注入することで、セクション間の一貫性を維持します。最後にTemplateパターンで出力フォーマットを統一します。

対話型データ収集では、反転インタラクションで主導権をAIに渡し、必要な情報を1つずつ質問させます。追加情報要求で各ステップの確認を取り、Menu Actionsパターンで人間が特定のコマンド（スキップ、やり直し、完了など）を入力できるようにします。

品質付き自動翻訳では、Personaでプロの翻訳者としての振る舞いを定義し、CoTで翻訳の推論過程（原文の解釈、文化的背景の考慮、表現の選択理由）を出力させ、自己批評で自己評価と改善を行い、形式準拠チェックで出力フォーマットの最終チェックを実施します。

プロンプトからコンテキストエンジニアリングへ

2025年6月、Andrej Karpathy（元Tesla AI部門シニアディレクター、OpenAI共同創設者）が支持を表明し、Tobi Lütke（Shopify CEO）らも賛同したことで注目を集めたコンテキストエンジニアリングは、プロンプトエンジニアリングの発展形として位置づけられています。

従来のプロンプトエンジニアリングが1つのプロンプトの書き方に焦点を当てていたのに対し、コンテキストエンジニアリングはコンテキストウィンドウに入る全ての情報を設計対象とします。コンテキストウィンドウの構成要素は以下のとおりです。

• システムプロンプト：指示、ルール、ペルソナの定義
• ユーザープロンプト：タスクの指示、質問
• 会話履歴：短期的な対話の文脈
• 長期記憶：過去の会話から抽出された情報、ユーザーの設定
• 検索結果：取得補強生成で取得した外部知識
• ツール定義：使用可能なAPIや関数の一覧と引数の型情報

これらの要素をどう選択し、どう配置し、どう圧縮するかの全体設計がコンテキストエンジニアリングです。プロンプトの書き方という技術から、情報アーキテクチャの設計という視座へと拡張されています。

この流れと並行して、プロンプトそのものを自動的に最適化する技術も進歩しています。DSPyは、プロンプトの最適化をプログラム的に行うフレームワークで、評価関数を定義すれば、最適なプロンプトを自動探索します。Automatic Prompt Engineer（APE）の流れを汲む研究が、2025年現在も活発に進んでいます。

しかし、自動化が進んでも人間の設計判断が不要になるわけではありません。DSPyが最適化できるのは、評価関数が定義されたタスクに限られます。何を最適化するか、どの評価関数を使うか、どのデータで検証するかは、依然として人間が設計する領域です。

この記事の冒頭で述べた5つの理由に立ち返りましょう。エージェントの心臓部はプロンプトであること、引き算設計は人間の仕事であること、複利効果、モデルを超えたセオリーの不変性、そしてコンテキストエンジニアリングの土台としてのプロンプト設計力。これらは全て、自動化の時代だからこそ重要性が増す人間のスキルを指しています。

プロンプトエンジニアリングは消えゆく技術ではなく、AIシステム設計の核心です。セオリーを理解し、手筋を身につけた人が、AIの性能を最大限に引き出します。

まとめ

プロンプトエンジニアリングは、AIの性能を引き出すための体系的な設計技術です。

この記事では、以下をセオリーに基づいて解説しました。

• 意図の伝達（指示・ペルソナ・出力形式）
• 知識の注入（検索拡張生成・情報圧縮・根拠の可視化）
• 推論の設計（CoT・分岐・分解・Few-shot）、対話の制御（主導権・反復・状態管理）
• 品質の担保（自己改善・アンサンブル・ガードレール・評価パイプライン）
• エージェント時代のシステム設計

単に名前を覚えるのではなく、なぜ効くかの原理を理解することで、モデルが進化しても通用する応用力が身につきます。