同じプロンプトを流しているのに、返ってくる形が回ごとに変わる。前置きが付く回と付かない回がある。Anthropic 公式の「Increase output consistency」ガイドは、この揺れをプロンプト側で抑える手法をまとめています。本記事はその内容を日本語で解説します。
先に確認: 構造化出力で足りないか
公式ガイドは冒頭で、順序を明確に示しています。特定のスキーマに必ず従う JSON が欲しいなら、以下のプロンプト手法ではなく構造化出力を使ってください。構造化出力はスキーマ適合を保証する機能であり、まさにその用途のために設計されています。
この記事で扱う手法が効くのは、その先です。厳密な JSON スキーマでは表せない形が欲しいとき（XML、独自テンプレート、自然文と構造の混在）や、形式そのものではなく内容やふるまいの一貫性が欲しいときに使います。順番を逆にすると、機能で保証できるものをプロンプトの工夫で近似することになり、割に合いません。
出力形式を厳密に指定する
望む出力形式を、JSON・XML・独自テンプレートのいずれかで正確に定義します。要求する書式要素をすべて書き出すのがポイントです。
You're a Customer Insights AI. Analyze this feedback and output in JSON format with keys: "sentiment" (positive/negative/neutral), "key_issues" (list), and "action_items" (list of dicts with "team" and "task").この指定が具体的なのは、キー名だけでなく各キーの値の型と取りうる値まで書いている点です。sentiment は 3 値のいずれか、key_issues はリスト、action_items は team と task を持つ辞書のリスト。ここまで書くと、揺れる余地が構造上なくなります。「JSON で出力してください」だけの指示との差は、実際に流してみると大きく出ます。
プリフィル（対応モデルに注意）
プリフィルは、Assistant ターンの冒頭をこちらで書き始めておく手法です。モデルの前置き（「承知しました。以下が……」）を飛ばして、指定した構造から直接書かせられます。
ただし対応モデルに制限があります。公式ガイドの注記によれば、プリフィルは Claude 4.6 以降のモデルおよび Claude Mythos Preview ではサポートされません。これらのモデルでは、対応している場合は構造化出力を、そうでなければシステムプロンプトでの指示を代わりに使うよう案内されています。
使える場合の形は、たとえば XML レポートを出させるときに、ユーザーターンで雛形を示したうえで、アシスタントターンを次のように書き始めておくものです。
<report>
<summary>
<metric name=途中で切ることに意味があります。開きタグの属性値の直前で止めておくと、モデルは構造から外れる書き出しができません。手法としては強力ですが、使う前に対象モデルの対応状況を確認してください。移行の観点では、プリフィルに依存した実装は将来のモデル更新で動かなくなる可能性があるため、新規実装では構造化出力を第一候補にするのが安全です。
例で制約する
望む出力の例を渡します。公式ガイドは、これが抽象的な指示よりも効果的だと明言しています。
Output following this example format:
<competitor>
<name>Rival Inc</name>
<overview>A 50-word summary.</overview>
<swot>
<strengths>- Bullet points</strengths>
<weaknesses>- Bullet points</weaknesses>
<opportunities>- Bullet points</opportunities>
<threats>- Bullet points</threats>
</swot>
<strategy>A 30-word strategic response.</strategy>
</competitor>
Now, analyze AcmeGiant and AcmeDataCo using this format.この例の巧いところは、プレースホルダに分量まで書き込んでいることです。A 50-word summary.、A 30-word strategic response.、- Bullet points。構造だけを見せると、要素の粒度が回ごとに変わります。1 行で済ませる回と 5 段落書く回が混ざるのは、構造の指定ではなく分量の指定が欠けているからです。
検索で文脈を固定する
チャットボットやナレッジベースのように、一貫した文脈が要るタスクでは、検索（retrieval）で応答を固定された情報集合に接地させます。公式ガイドの IT サポート例では、ナレッジベースの項目を <kb> として渡したうえで、応答の形式を次のように指定しています。
<response>
<kb_entry>Knowledge base entry used</kb_entry>
<answer>Your response</answer>
</response>ここでも設計が効いています。使ったナレッジベース項目を出力に含めさせるので、回答が何に基づいているかが応答自体から読めます。同じ質問に別の項目を参照して答えていれば、それは一貫性が崩れた瞬間として検出できる。一貫性を「祈る」のではなく「測れる形にする」構造です。
なお同じ例のプロンプト末尾では、モデル自身にテスト質問を作らせて答えさせ、ナレッジベースの使い方を理解できているか確認させています。運用に乗せる前の動作確認をプロンプト内で済ませる形です。
プロンプトを分割する
複雑なタスクは、小さく一貫したサブタスクに分解します。各サブタスクに Claude の注意が全量向くため、規模の大きいワークフローで起きる不整合が減ります。
言い換えると、1 回の呼び出しに詰め込む工程が増えるほど、後半の工程ほど指示が守られにくくなるということです。出力の揺れが特定の工程に偏って出ている場合、プロンプトの言い回しを磨くより、その工程を別の呼び出しに切り出すほうが早く直ります。
キャラクターを維持する
ロールを持たせるアプリケーションでは、一貫したキャラクターの維持に意図的なプロンプト設計が要ります。公式ガイドは 2 点を挙げています。
- システムプロンプトでロールを設定する — Claude の役割と人格をシステムプロンプトで定義する。一貫した応答の土台になる。キャラクターを設定するときは、性格・背景・特有の癖まで詳しく与えると、モデルがその特徴をよりよく再現・一般化できる。
- 起こりうる場面に備えさせる — よくある場面と、その場合の期待される応答をプロンプト内に列挙しておく。多様な状況でキャラクターを崩さず対応できるようになる。
公式の企業向けチャットボット例では、後者が具体的な条件分岐として書かれています。
As AcmeBot, you should handle situations along these guidelines:
- If asked about AcmeTechCo IP: "I cannot disclose TechCo's proprietary information."
- If questioned on best practices: "Per ISO/IEC 25010, we prioritize..."
- If unclear on a doc: "To ensure accuracy, please clarify section 3.2..."「専門的な口調を保つこと」のような抽象的な指示ではなく、場面と返す文言の対応表になっている点が要点です。とくに、答えてはいけない質問への応答をあらかじめ文言で決めておくと、その場でモデルが言い回しを考える必要がなくなり、回ごとの揺れが構造的に消えます。
次に読むもの
この話題と関係の深いトピックは次のとおりです。
- 構造化出力 — スキーマ適合が要るなら、まずこちら。本記事の手法より上位の選択肢。
- プロンプトのベストプラクティス — ロールの与え方を含む、プロンプト設計の基礎。
- ハルシネーションを減らす — 同じガードレール群のもう一方。形式の一貫性ではなく内容の正確さを扱う。
- 成功基準の定義と評価の構築 — 一貫性が改善したかを測るには、先に基準が要る。
本記事は Anthropic 公式ドキュメントの「Increase output consistency」ページ（2026年9月1日に確認）に基づく非公式の日本語解説です。掲載したプロンプト例は公式ページの原文を引用しています。プリフィルの対応モデルなどの条件は更新される場合があるため、実装前に公式ドキュメントで最新をご確認ください。