「言うことを聞かせる」ではなく「本番システムとして信頼できる出力を作る」ためのプロンプト工学。曖昧語の禁止・few-shot・JSONスキーマ強制・検証リトライ・バッチ・多段レビューの6本柱を、「導入レッスン（コードで裏技と型を理解する）」→「タスクステートメント4.1〜4.6」→「演習」→「章末ミニクイズ」の順で、この1ページで学びきる。
第1章の土台レッスン（tool use の往復・エージェントループ）が前提。ことば図鑑のJSON・JSONスキーマの項も随時参照。
第1章で学んだ tool use には有名な副産物がある。「実在しないツール」を定義して無理やり呼ばせると、確実にスキーマ通りのJSONが手に入る。この章の全テーマ（構造化出力）の入口になる技なので、まずコードで見る。
# 「抽出結果を記録する」という体のツールを定義し、
# tool_choice で強制的に呼ばせる → 出力は必ずこのスキーマに従う
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
tools=[{
"name": "record_invoice",
"description": "請求書から抽出した情報を記録する",
"input_schema": {
"type": "object",
"properties": {
"issuer": {"type": "string"},
"total": {"type": "number"},
"due_date": {"type": ["string", "null"]}, # ←無いかもしれない欄はnull許容(捏造防止)
},
"required": ["issuer", "total"],
},
}],
tool_choice={"type": "tool", "name": "record_invoice"}, # ← 必ずこのツールを呼べ
messages=[{"role": "user", "content": f"この請求書から情報を抽出して: {document}"}],
)
# response.content の tool_use ブロックの input が、そのまま検証済みJSONになっている種明かし：record_invoice というツールは実行されない（する必要がない）。欲しいのはClaudeがツールを呼ぼうとして組み立てた引数（input）で、これはツール定義のJSONスキーマ（ことば図鑑参照：記入例つき申込用紙）に必ず従う。「JSONで返して」とプロンプトでお願いする方式だと、返事の前後に「以下が抽出結果です」のような文が混ざったり、JSONが壊れたりする——ツール強制ならそれが起きない。
tool_choice は3段階の強さがある。ここは4.3で試験がそのまま問う：
| 指定 | 意味 | 使いどころ |
|---|---|---|
{"type": "auto"} | ツールを使うかどうかClaudeが判断（テキストで返す可能性が残る） | 通常のエージェント動作 |
{"type": "any"} | どれかのツールを必ず呼ぶ（どれを呼ぶかは選ばせる） | 文書タイプが不明で、複数の抽出スキーマから選ばせたいとき |
{"type": "tool", "name": "…"} | 指定した特定のツールを必ず呼ぶ | 走らせたい抽出が決まっているとき（上のコード） |
ただし重要な限界がある。これは形式の保証であって中身の保証ではない（合計が合わない等の意味エラーは残る）。この区別が4.3の最頻出論点で、意味の検証は導入レッスン3のリトライループが受け持つ。
レッスン1の input_schema をどう設計するかで、抽出の信頼性が大きく変わる。試験ポイントは3つ：
"due_date": {"type": ["string", "null"]}。requiredにすると、モデルが「埋めなきゃ」と値を捏造する。「無いものは無い」と言える設計が捏造防止。人間でも「全欄必須の申込用紙」を渡されると、分からない欄に適当な値を書きたくなる——モデルはその圧力にもっと弱い"category": {"enum": ["請求", "返品", "other"]} ＋ "category_detail": {"type": "string"}。想定外を無理やり既存カテゴリに押し込ませない。曖昧ケース用に "unclear" を足すのも同じ発想補足：日付や金額の表記ゆれ（「2026年8月」vs「2026-08」）をどの形式に正規化するかのルールは、スキーマではなくプロンプト側に書く。スキーマは「型」の担当、プロンプトは「変換ルール」の担当という分業。
スキーマで防げない意味エラーは、抽出の後に検証ロジックで捕まえて、失敗内容を添えて再依頼する。この型を retry-with-error-feedback と呼ぶ。
# retry-with-error-feedback の骨格
def extract_with_retry(document, max_retries=2):
result = extract(document) # tool_choice強制で抽出（レッスン1）
for _ in range(max_retries):
errors = validate(result) # Pydantic等で意味の検証
if not errors:
return result
# ★ 具体的なエラー内容を添えて再依頼するのが肝
result = extract(
document,
feedback=f"前回の抽出はこの検証に失敗した: {errors}。"
f"前回の出力: {result}。エラーを修正して再抽出せよ。"
)
return flag_for_human_review(result) # 直らなければ人間レビュー行きconflict_detected: true を立てる——うちの data-accuracy ルールの合計突合と同じ技detected_pattern（何を根拠に判定したか）を出力に含めると、後で「どのパターンが誤検知源か」を集計できる抽出パイプラインを1000件の文書に回すとき、1件ずつ同期APIを叩く必要はない。Message Batches API に一括で預けて、後で結果を回収する。
# Message Batches API の骨格
batch = client.messages.batches.create(
requests=[
{
"custom_id": f"doc-{i}", # ★ 結果との対応付けに必須
"params": { "model": "claude-haiku-4-5", "max_tokens": 1024,
"messages": [...], "tools": [...], "tool_choice": {...} },
}
for i, doc in enumerate(documents) # 100件まとめて投入
]
)
# → 後でポーリングして結果回収。失敗した custom_id だけ修正して再投入暗記3点セット＋判断1つ：
ここまでの4レッスンが、この章の「型」の全部。ここから先は、その型を試験が問う形（タスクステートメント）で1つずつ整理していく。
身近な例で考える。新人に書類チェックを頼むとき「慎重に確認して」と言うのと、「金額欄と明細合計の不一致・押印漏れ・日付の未来日、この3つだけを見て」と言うのでは、後者の方が明らかに結果が安定する。前者では新人が「慎重」の意味を自分で解釈するしかなく、人によって（AIなら実行のたびに）基準が揺れる。プロンプトも同じで、「be conservative（慎重に）」「check that comments are accurate（コメントが正確か確認して）」のような曖昧語は、モデルに解釈の自由を丸投げしている。効くのは「claimed behavior contradicts actual code behavior の場合のみ報告」のように、該当/非該当を機械的に判定できる基準の列挙。
なぜここまで基準にこだわるのか。誤検知は「その1件が無駄」では済まず、システム全体の信用を壊すからだ。コードレビューBotが的外れな指摘を10件並べると、開発者は11件目の本物のバグ指摘も読み飛ばすようになる——オオカミ少年と同じ構造で、誤検知の多いカテゴリが、正確なカテゴリの信用まで巻き添えにする。だから対処も「もっと慎重にと指示を足す」ではなく構造的に行う：報告する問題（バグ・セキュリティ）とスキップする問題（軽微なスタイル・そのリポジトリのローカル慣習）をカテゴリで定義し、誤検知の多いカテゴリは一時的に無効化して信頼を回復させ、その間にプロンプトを改善する。
重大度（severity）の判定も同じ発想で安定させる。「criticalは深刻なもの」ではなく、各レベルに具体的なコード例を付けて定義する（例：critical＝「認証チェックの欠落。例: このコード」）。基準に実物を添えると分類のブレが減る——これは次の4.2（few-shot）へそのままつながる話でもある。
試験が問うことrules/output-quality.md の抽象表現禁止テーブル（「適切に処理する」→「Try/exceptでログ出力し再raise」）と、feedback-quality-bar「抽象語は具体化しろ」が完全に同じ思想。「AIへの指示も、AIからの出力も、曖昧語を潰す」——組織の品質バーがそのまま答案になる。
few-shot（フューショット）とは、指示文に加えて「入力と正解出力の実例」を数個見せる技法。名前は仰々しいが、やっていることは新人教育の「口で説明するより、良い見本を2〜3件見せる」と同じだ。問い合わせメールの分類エージェントを例にすると——「請求に関する問い合わせは billing に分類」と指示文をいくら詳しく書いても、「解約したいが返金はあるか」のような複数カテゴリにまたがる曖昧ケースで分類がブレる。ここに「入力: 『解約したいが返金はあるか』→ 出力: cancellation（理由: 主目的は解約で、返金はその帰結の確認だから）」という例を1個足すと、モデルは「主目的で分類する」という判断軸を読み取り、見たことのない曖昧ケースにも同じ軸を適用できるようになる。例に「理由」を添えるのが汎化の鍵——答えだけの例は「その1問の暗記」にしかならないが、理由付きの例は「判断のしかた」を教える。
数は2〜4個が推奨。ここは直感に反するので注意する——「例は多いほど良い」ではない。例を8個10個と積むと、トークンコストが膨らむ（毎リクエストに全例文が同封される。第1章の「手紙」の比喩を思い出す：手紙が分厚くなる）割に精度はほぼ伸びず、モデルの注意が薄く分散する。効くのは数ではなく狙いで、「モデルが実際に間違えた曖昧ケース」「境界がまぎらわしいケース」をピンポイントで例にする。指示文の詳細化で直らないブレは、指示をさらに盛るのではなく例を足す——4.1（基準の明示）と4.2（例示）は「曖昧さを潰す」同じ目的の2つの道具で、ルールで書ける境界は4.1、ルール化しにくい判断は4.2と使い分ける。
抽出タスクでも同じことが起きる。論文PDFの参考文献抽出で、インライン引用の文書と巻末文献リストの文書で抽出のされ方がブレる場合、形式ごとの正しい抽出例（この形式ならこう取る、存在しない欄はこうnullにする）を見せると、空欄・null処理が安定してハルシネーションが減る。例には出力フォーマットの実物（場所・問題・重大度・修正案が全部埋まった1件）を含めること——形式まで含めて「見本」になる。
試験が問うことskills/agents のプロンプトに Good/Bad 例を書き込む流儀（editorial系スキルの文例、copywriting系のNG/OK対比）がこれ。empirical-prompt-tuning スキルは「few-shotを足した後に効果を実測する」工程で、試験の一歩先を行く運用。
仕組みは導入レッスン1でコードごと見た通り。試験では「最も信頼できる構造化出力の方法はどれか」の形で問われ、正解は常に「tool_use＋JSONスキーマ」。tool_choice の3段階（auto / any / 特定強制）の使い分けと、スキーマ設計の知恵（導入レッスン2）がセットで出る。
tool_choice の使い分け（第4章 D2と共通）："auto"はテキストで返す可能性が残る／"any"でツール呼び出しを保証／文書タイプ不明で複数の抽出スキーマがあるなら"any"、特定の抽出を先に走らせたいなら強制指定"other"＋詳細文字列のペアで拡張性を持たせる／元文書に無い情報の欄は nullable にする（必須にするとモデルが値を捏造して埋める）"unclear" のようなenum値を用意する／フォーマット正規化ルールはプロンプト側に書くWorkflow ツールの schema オプション（サブエージェントにStructuredOutputを強制）が日常の実物。「必須欄が捏造を誘発する→nullable設計」は rules/data-accuracy.md の捏造防止と同じ問題意識をスキーマ設計で解いたもの。「東京院に実在しないドメインを書いた事故」は、まさに required 欄を埋めたがる性質の現れ。
コードの骨格は導入レッスン3で見た。試験で問われるのは「どの失敗にリトライを使い、どの失敗に使わないか」の判断。合計が合わない・欄がずれた、のような出力の作り方の失敗はエラー内容を伝えれば直る見込みがある。一方「支払期日が文書のどこにも書かれていない」のような入力に情報が無い失敗は、何回リトライしても出てこない——nullを許して先に進むか、人間レビューに回すのが正解になる。
試験が問うことconflict_detected フラグを立てるdetected_pattern 欄で記録→開発者が却下した指摘のパターン分析→プロンプト改善につなげるrules/data-accuracy.md の「合計突合＋書き込み後の計算列検証」は calculated vs stated の照合そのもの。memory/pii-mask-false-positives.md（誤検知を記録して後でルール調整）は detected_pattern によるフィードバックループの運用版。
custom_id でリクエストとレスポンスを対応付ける→失敗した文書だけを特定して修正（例：コンテキスト超過はチャンク分割）して再投入「同期かバッチか」の判断軸は、BQの「5MB超はload job必須」（feedback-bq-batch-vs-loadjob）と同じ「処理特性でAPIを選ぶ」型。週次レポート自動配信（セミナー・rehab）は、まさにバッチ向きワークロードの実例。
ここには独立した2つの問題があり、それぞれに対処が違う。1つ目は自己レビューの限界。自分が書いた文章の誤字は自分では見つけにくい——「こう書いたはず」という記憶が目を曇らせるからだ。モデルも同じで、コードを生成した同じセッションでレビューを指示すると、生成時の推論コンテキスト（「この設計で正しい」と判断した思考の跡）が会話履歴に残っているため、その判断自体を疑えない。「もっと批判的に見て」と指示を足しても、思考時間を延ばしても直らない。効くのは文脈を持たない独立した第2インスタンスに見せること——第1章で学んだ「サブエージェントは親の文脈を継承しない」という性質が、ここでは品質保証の武器になる。
2つ目は注意力の希釈（attention dilution）。14ファイルのPRを1回のプロンプトで全部見せると、最初の数ファイルは深く分析されるのに後半は浅くなり、同じコードパターンにファイルによって矛盾した判定が出る。人間が書類30件を流れ作業で見ると後半が雑になるのと同じ現象。対処は「もっと大きなコンテキストウィンドウのモデルに替える」ではない——窓が広くても注意の総量は増えない。レビューを多段パスに分割する：まずファイル別の局所パスで1ファイルずつ深く見て、最後にクロスファイルの統合パスを1回流して横断的な問題（重複・不整合）を拾う。第1章1.6のプロンプトチェイニングを、レビュー品質のために使う形。
試験が問うこと組織の十八番。rules/audit-independence.md（盲検・独立コンテキスト・Generator-Evaluator分離）と lead-worker の Two-Reviewer Pattern（仕様準拠と品質を別々に独立起動）が、このタスクステートメントの完全な実装。「editorial-checker と geo-auditor を統合しない」円卓会議の結論は、試験の言う self-review threat の回避そのもの。
Anthropic 公式の無料学習サイト Claude Academy（2026-08-20 公開、/ja/ で日本語版）のうち、第3章（ドメイン4: プロンプト設計と構造化出力）に対応するレッスン。ほぼ全部が「Claude APIを使った構築」の「プロンプトエンジニアリング技術」「プロンプト評価」「ツール使用」の3セクションに収まる。使い方は「この章を読み終えてから、同じテーマを公式がどう説明しているかを確かめる」の一方向。先に公式を読む必要はない。レッスン本文の閲覧には無料アカウントでのサインインが必要。
この章で使うコース: Claude APIを使った構築
| この章の項目 | 対応する公式レッスン |
|---|---|
| 導入レッスン1〜3 構造化出力・スキーマ設計・検証リトライ | Claude APIを使った構築 › 構造化データ Claude APIを使った構築 › ツールスキーマ |
| 4.1 明示的基準の設計 | Claude APIを使った構築 › プロンプトエンジニアリング Claude APIを使った構築 › 明確で直接的であること Claude APIを使った構築 › 具体的であること Claude APIを使った構築 › XMLタグで構造化する |
| 4.2 few-shot プロンプティング | Claude APIを使った構築 › 例を提供する |
| 4.3 tool_use と JSONスキーマによる構造化出力 | Claude APIを使った構築 › 構造化データ Claude APIを使った構築 › ツールスキーマ Claude APIを使った構築 › 細粒度のツール呼び出し |
| 4.4 検証・リトライ・フィードバックループ | Claude APIを使った構築 › プロンプト評価 Claude APIを使った構築 › 典型的な評価ワークフロー Claude APIを使った構築 › コードベースの採点 Claude APIを使った構築 › モデルベースの採点 |
| 4.5 バッチ処理（Message Batches API） | Claude Academy に該当レッスンは無い（2026-08-25 時点）。この章の導入レッスン4とタスクステートメント4.5で足りる。 |
| 4.6 多重インスタンス・多段パスのレビュー設計 | Claude APIを使った構築 › モデルベースの採点 Claude APIを使った構築 › 並列化ワークフロー |
| 深掘り（任意） | Claude APIを使った構築 › 拡張思考 Claude APIを使った構築 › プロンプトキャッシング |
対応付けはレッスン題名とコース説明文から行った（2026-08-25 時点）。レッスン本文までは精査していないので、読んでみて「この章の項目とずれている」と感じたら、その節は公式を優先せずこの章の記述で答える（試験ガイドのタスクステートメントに合わせて書いてあるため）。
この試験にコードを書く場面はない。写経（見ながら書き写して動かす）で十分——やり方は第1章の「写経の作法」を参照（「1行写すごとに何をする行か声に出す」🥈方式を推奨）。Claudeに「c3演習やる」と言えば環境準備から伴走してもらえる。
"due_date" の null 許容を外して required に入れる → 日付の無い領収書でそれらしい日付が捏造されるのを実際に見る。「nullable が捏造防止」が一発で腹落ちするtool_choice を "auto" に戻す → たまにJSONではなく「抽出しました。発行者は…」というテキストが返るのを見る「慎重に」ではなく「XがYと矛盾する場合のみ報告」のような、該当/非該当を機械的に判定できる基準。誤検知削減の第一手。
入出力の実例を2〜4個見せて出力の形式と判断基準を教える技法。曖昧ケースの判断理由まで例に含めると新規パターンへ汎化する。
出力スキーマをツールの入力パラメータとして定義し、そのツールを呼ばせることでJSON構文の正しさを保証する方式。「JSONで返して」より確実。
ツールを呼ばせる強さの指定。auto＝呼ぶかどうか任せる（テキストで返る可能性が残る）、any＝どれかを必ず呼ぶ（文書タイプ不明で複数スキーマから選ばせるとき）、{"type":"tool","name":…}＝特定のツールを必ず呼ぶ（走らせたい抽出が決まっているとき）。
構文=JSONとして壊れている（tool_useで解消）。意味=形式は正しいが中身が間違い（合計不一致・欄違い。スキーマでは防げず、検証ロジックで捕まえる）。
元文書に存在しない可能性がある欄を必須にすると、モデルが値をでっち上げて埋める。省略可能（null許容）にして「無いものは無い」と言える設計にする。
検証に落ちたら「元文書＋失敗した出力＋具体的なエラー内容」を付けて再依頼する型。情報がそもそも無い失敗には効かない。
非同期の一括処理API。50%引き・最大24時間・SLAなし・バッチ内での多ターンツール呼び出し不可・custom_idで結果を対応付け。待てる仕事専用。
一度に多くの対象を見せると1つあたりの分析が浅く・不安定になる現象。ファイル別パス＋統合パスへの分割で対処。「大きい窓のモデルに替える」では直らない。
生成時の推論文脈を持たない別セッション/別エージェントにレビューさせる設計。自己レビュー指示・拡張思考より効く。
本番形式の4択。この章で学んだことの思い出す練習（読み直しの3倍効く）。4問がこの章（D4）、1問は第2章（D3）の復習。総合模試とは別シナリオで、4.2・4.4・4.6を厚めに問う。