Architect Foundations ドメイン4: プロンプトエンジニアリングと構造化出力（20%）
この章で学ぶこと: 誤検知を減らす明確な基準、few-shot 例、tool_use と JSON スキーマによる構造化出力、検証と再試行のループ、バッチ処理、複数インスタンス・複数パスのレビュー。
本番の60問のうち約12問が出ます。
| タスクステートメント | この章の節 |
|---|---|
| 4.1 明確な基準で精度を上げ、誤検知を減らす | 第1節 |
| 4.2 few-shot で一貫性と質を上げる | 第2節 |
| 4.3 ツール利用と JSON スキーマで構造化出力を強制する | 第3節 |
| 4.4 検証・再試行・フィードバックのループ | 第4節 |
| 4.5 バッチ処理の戦略 | 第5節 |
| 4.6 複数インスタンス・複数パスのレビュー | 第6節 |
Developer Foundations で学んだ基本（ここでは繰り返しません）:
- 明確で直接的なプロンプト、例（few-shot）、system と user の置き分け → Developer D6 第2節
- 構造化出力（
output_config.format）と厳密なツール利用（strict: true） → Developer D2 第3.6節 - 構造化出力のパターン、応答の検証、防御的なパース → Developer D6 第3節
- Message Batches API の基本（50%、24時間、
custom_id、結果の種類） → Developer D2 第3.8〜3.9節 - 新しいモデルでの
tool_choiceとサンプリングのパラメータの制限 → Developer D5 第3.3節
1. 明確な基準で誤検知を減らす（4.1）
1.1 あいまいな指示 と 明確な基準
| あいまい | 明確 |
|---|---|
| 「コメントが正確か確認して」 | 「コメントの主張が、実際のコードの動きと矛盾するときだけ指摘する」 |
| 「重要な問題だけ報告して」 | 「報告する: バグ（誤った結果・例外）、セキュリティ（注入、認可の抜け）。報告しない: 命名の好み、空白、ローカル変数の書き方」 |
| 「控えめに」「確信度の高いものだけ」 | 何を報告し何を飛ばすかを、カテゴリで決める |
「控えめに」「確信度が高いものだけ」のような一般的な指示は、具体的なカテゴリの基準ほど精度を上げません。モデル自身の確信度は、当てになる目盛りではないからです（第5章 5.2）。
1.2 誤検知の多いカテゴリが信頼を壊す
あるカテゴリ（例: 「性能の指摘」）の誤検知が多いと、開発者は正確なカテゴリ（例: 「セキュリティの指摘」）まで読まなくなります。
対策:
- 誤検知の多いカテゴリを一時的に止める（報告しない）
- そのカテゴリのプロンプト（基準と例）を直す
- 精度を確かめてから戻す
1.3 重大度の基準にはコード例を付ける
| 重大度 | 基準 | 例 |
|---|---|---|
| 高 | データの損失、セキュリティの穴 | SQL を文字列の連結で組み立てている |
| 中 | 誤った結果になりうる | 割り算の前にゼロのチェックがない |
| 低 | 保守性 | 同じ処理のコピーが3か所 |
例があると、分類が回ごとにぶれにくくなります。
2. few-shot プロンプト（4.2）
2.1 なぜ few-shot か
詳しい指示を書いても結果がぶれるとき、few-shot 例が、形のそろった、実行できる出力を得る最も効果的な方法です。公式のプロンプトのドキュメントも、例を「出力の形・口調・構造を導く最も確かな方法の1つ」とし、いくつかのよく作った例（関係が深い、多様、<example> タグで囲む）を勧めています。試験ガイドは「あいまいなシナリオ向けに2〜4個」と書きます。数より「的を絞った多様な例」が要点です。
2.2 何を見せるか
| 目的 | 例の作り方 |
|---|---|
| あいまいな場面の判断 | 「この依頼ではツール A を選ぶ。B ではない理由は〜」のように、選んだ理由ともっともらしい代案を退けた理由を示す |
| 出力の形をそろえる | 場所、問題、重大度、修正案を毎回同じ形で書いた例 |
| 誤検知を減らす | 「この書き方は問題ない（理由）」と「これは本当の問題（理由）」の対の例 |
| さまざまな文書構造 | 本文中の引用と巻末の参考文献一覧、方法論の章と本文に埋め込まれた方法の説明、それぞれの正しい扱い |
| 必須の項目が空になる | 形式の違う文書から正しく抜き出した例を足す |
| くだけた表記 | 「2コ」「半ダース」「約3kg」などの単位の扱い |
few-shot 例は、見せたケースだけでなく、新しいパターンにも判断を一般化させます。抽出のハルシネーション（文書にない値を作る）を減らすのにも効きます。
2.3 例の置き方
<example>タグで囲み、指示と区別する（公式の推奨）- 例どうしが似すぎると、モデルが表面のくせまでまねる。多様にする
3. ツール利用と JSON スキーマで構造化出力（4.3）
3.1 試験ガイドの考え方
| 方法 | 構文の正しさ |
|---|---|
| プロンプトで「JSON で答えて」 | 壊れた JSON が出ることがある |
| JSON スキーマを持つツールを定義し、tool_use の入力として受け取る | スキーマに合った構造。JSON の構文エラーがなくなる（strict: true で保証） |
tools = [{
"name": "record_invoice",
"description": "請求書から抜き出した値を記録する。文書にない値は null にする。",
"strict": True,
"input_schema": {
"type": "object",
"properties": {
"invoice_number": {"type": "string"},
"issue_date": {"type": ["string", "null"], "description": "YYYY-MM-DD"},
"total": {"type": "number"},
"currency": {"type": "string", "enum": ["JPY", "USD", "EUR", "other"]},
"currency_detail": {"type": ["string", "null"]},
"category": {"type": "string", "enum": ["goods", "services", "unclear", "other"]},
},
"required": ["invoice_number", "issue_date", "total", "currency", "currency_detail", "category"],
"additionalProperties": False,
},
}]
# 応答の content から type == "tool_use" のブロックを探し、block.input を取り出す
3.2 tool_choice（試験ガイドの書き方）
| 値 | 抽出での使い方 |
|---|---|
"auto" |
テキストだけ返すことがある。抽出には不向き |
"any" |
抽出スキーマが複数あり、文書の種類がわからないとき。必ずどれかのツールを呼ぶ |
{"type": "tool", "name": "extract_metadata"} |
補強（enrichment）の前に、メタデータの抽出を必ず先にやらせる |
今のモデルでの書き方（2026年11月時点）: Claude Opus 5.5・Sonnet 5.5・Fable 5.1・Mythos 5.1 と、手動の extended thinking では、
"any"と{"type": "tool"}が 400 エラーになります。公式ドキュメントが勧める代わりは次のとおりです。
- ツール入力をスキーマに合わせたい:
tool_choice: "auto"とstrict: true。どのツールを使うかはプロンプトで導く- 決まった JSON の形の応答が欲しい: 構造化出力（
output_config.formatにtype: "json_schema"）。ツールを使わずに、応答そのものがスキーマに合う試験では、ガイドの書き方（tool_use + tool_choice の強制）で答えます。
3.3 スキーマが防げるもの・防げないもの
| 防げる（構文） | 防げない（意味） |
|---|---|
| 壊れた JSON、項目の欠け、型の違い | 明細の合計が総額と合わない |
| enum にない値 | 値が別の項目に入る（請求日に支払期日が入る） |
| — | 文書にない値をそれらしく作る |
意味のエラーには、第4節の検証が必要です。
3.4 スキーマ設計のこつ
| こつ | 理由 |
|---|---|
| 文書にないかもしれない項目は nullable（任意）にする | 必須にすると、モデルが値をでっち上げて埋める |
enum に "other" と、詳細を書く文字列の項目を足す |
想定外の分類を受け止められる（拡張できる） |
あいまいなとき用に "unclear" を足す |
無理にどれかへ入れさせない |
| 書式の正規化ルールをプロンプトに書く | 例: 「日付は YYYY-MM-DD に直す」「金額は数字だけ」。元の書式がばらばらでも、スキーマに合う値にそろう |
「任意」の書き方は2つあります。required に入れない（項目ごと省ける）か、required に入れたまま型に null を許す（nullable。値がないと明示できる）かです。上の例は後者で、「文書になかった」ことが null で残るので下流で扱いやすくなります。
厳密な構造化出力（strict: true や output_config.format）の注意（2026年11月時点の公式ドキュメント）:
- オブジェクトには
additionalProperties: falseが要る（SDK のヘルパーは自動で足す） requiredにない任意の項目は、全スキーマで合計24個まで。["string", "null"]のような型の組み合わせは16個まで。複雑すぎると 400 エラー- enum の値の大文字・小文字は保証されない。比べるときは大文字・小文字を無視する
- 断ったとき（
stop_reason: "refusal"）やmax_tokensで切れたときは、スキーマに合わないことがある
4. 検証・再試行・フィードバックのループ（4.4）
4.1 エラーを伝えて再試行
1回目: 抽出する
検証する（Pydantic などで、意味のチェック）
例: 明細の合計 9,800 ≠ 総額 10,800
2回目のリクエストに入れるもの:
- 元の文書
- 失敗した抽出の結果
- 具体的な検証エラー（「明細の合計と総額が 1,000 円ずれている。明細を見落としていないか確認して」）
具体的なエラーを渡すと、モデルは何を直せばよいかわかります。「もう一度やって」だけでは同じ間違いをくり返しがちです。
4.2 再試行が効く場合・効かない場合
| 効く | 効かない |
|---|---|
| 書式の不一致（日付の形が違う） | 必要な情報が元の文書にそもそもない |
| 出力の構造のエラー | 情報が、渡していない別の文書にしかない（例: 請求書の総額が、添付していない注文書にだけある） |
| 明細の見落とし | — |
効かない場合は、再試行をくり返さず、null にする、人のレビューに回す、必要な文書を追加で取ってくる、のどれかにします。
4.3 自己修正の検証フローを組み込む
| 項目 | 役割 |
|---|---|
stated_total |
文書に書かれている総額 |
calculated_total |
明細から計算した総額 |
conflict_detected（真偽値） |
元の文書の中で値が矛盾しているか |
2つの総額を並べて抜き出させると、食い違いが機械で見つけられます。矛盾は「直す」のではなく「印を付けて」下流や人に知らせます。
4.4 フィードバックループ: detected_pattern
コードレビューの指摘に detected_pattern（どのコードの書き方が指摘を生んだか）の項目を足します。
{"file": "api/orders.py", "line": 42, "issue": "例外を握りつぶしている",
"severity": "medium", "detected_pattern": "except Exception: pass"}
開発者が却下した指摘を detected_pattern ごとに集計すると、「どの書き方で誤検知が多いか」がわかり、基準と例を体系的に直せます。
5. バッチ処理の戦略（4.5）
5.1 Message Batches API の要点
| 特徴 | 内容 |
|---|---|
| コスト | 50% 削減 |
| 処理時間 | 最大24時間。多くは1時間以内に終わるが、レイテンシの保証（SLA）はない |
| 対応づけ | custom_id でリクエストと結果を対応づける（結果の順番は送った順とは限らない） |
| 複数ターンのツール呼び出し | 1つのリクエストの途中で、自分のツールを実行して結果を返すことはできない。1リクエスト = 1回の応答 |
| 完了の確認 | ポーリング（processing_status が ended になるまで） |
「複数ターン非対応」の意味: 過去の会話の履歴（複数ターンの messages）を入れて送ることはできますが、バッチの処理の中でエージェントループを回すことはできません。ツールを何度も使う仕事はバッチに向きません。
5.2 どちらを使うか
| ワークフロー | API |
|---|---|
| マージ前のチェック（開発者が待っている） | 同期の Messages API |
| 夜間の技術的負債レポート、週次の監査、夜間のテスト生成 | Message Batches API |
「両方バッチにして、遅ければ同期に切り替える」は複雑すぎる。「両方同期のまま、バッチは結果の順番が合わないから」は誤解（custom_id で対応づけられる）。
5.3 SLA から投入の間隔を計算する
例: 結果を30時間以内に出す約束（SLA）。バッチは最大24時間かかる。
- 文書が届いてから投入まで待てる時間 = 30 − 24 = 6時間
- 届いた文書を最大でも6時間以内に投入すればよい。余裕を見て、たとえば4時間ごとに投入する
試験ガイドの例は「4時間ごと」です。考え方は「SLA − 最大処理時間 = 投入までに使える時間」で、その範囲に入る間隔を選びます。
5.4 失敗の処理
- 結果の種類（
succeeded、errored、canceled、expired）を見る - 失敗したものだけを
custom_idで特定する - 原因に合わせて直す（例: コンテキストの上限を超えた文書は分割する）
- 失敗したものだけを再投入する（全部をやり直さない）
5.5 大量に流す前にサンプルで試す
1万件をいきなり投入しない。まず数十件のサンプルで、プロンプトとスキーマを直し、初回の成功率を上げる。再投入のコストと時間が減ります。バッチの各リクエストの検証は非同期なので、形は先に通常の Messages API で確かめます。
6. 複数インスタンス・複数パスのレビュー（4.6）
6.1 自己レビューの限界
同じセッションでコードを生成し、そのままレビューさせると、モデルは生成のときの推論をコンテキストに持っています。だから自分の判断を疑いにくいです。
| やり方 | 効果 |
|---|---|
| 同じセッションで「自分の出力を見直して」 | 限定的 |
| extended thinking を増やす | 生成の文脈は残ったまま |
| 生成の推論を持たない、独立した2つ目の Claude インスタンスでレビュー | 微妙な問題を見つけやすい |
6.2 複数パスのレビュー
大きな複数ファイルのレビューは、1回にまとめると注意が分散し、深さがばらつき、矛盾する指摘が出ます（同じ書き方を一方では指摘、もう一方では承認）。
- ファイルごとのパス: ローカルな問題
- 統合のパス: ファイルをまたぐデータの流れ、インターフェースの整合
誤答の定番:
| 誤答 | なぜだめか |
|---|---|
| コンテキストの大きいモデルで1回にまとめる | 大きなウィンドウでも注意の質の問題は解けない |
| 3回レビューして2回以上出た指摘だけ | たまにしか見つからない本当のバグを消してしまう |
| 開発者に PR を3〜4ファイルに分けさせる | システムを直さず、負担を人に移すだけ |
6.3 確信度を付ける検証パス
検証のパスで、各指摘に確信度を自己申告させます。それを使って、確信度の高い指摘は自動でコメント、低い指摘は人が確かめる、のように振り分けます。
注意: 自己申告の確信度はそのままでは当てになりません。ラベル付きのデータでしきい値を調整してから使います（第5章 5.5）。
7. 試験に向けたまとめ
| 問われ方 | 答えの考え方 |
|---|---|
| 誤検知が多い | 何を報告し何を飛ばすかを、カテゴリで具体的に決める。「控えめに」ではない |
| 1つのカテゴリの誤検知で全体の信頼が落ちた | そのカテゴリを一時的に止め、プロンプトを直す |
| 指示を詳しくしても形がぶれる | few-shot 例（2〜4個、理由付き、多様に） |
| 壊れた JSON をなくす | JSON スキーマ付きのツール（tool_use）、strict: true |
| 文書の種類がわからない / 特定の抽出を先に | tool_choice: "any" / 特定ツールの強制（新しいモデルでは代わりの方法） |
| モデルが値を作ってしまう | その項目を nullable に |
| 想定外の分類 | enum に "other" と詳細の項目、"unclear" |
| 合計が合わない | スキーマでは防げない。検証して、具体的なエラーを渡して再試行 |
| 情報が文書にない | 再試行は効かない |
| 却下された指摘を分析 | detected_pattern |
| マージ前のチェック / 夜間レポート | 同期 / バッチ |
| SLA 30時間、バッチ24時間 | 6時間以内に投入（例: 4時間ごと） |
| バッチの一部が失敗 | custom_id で特定し、直して失敗分だけ再投入 |
| 自分で書いたコードのレビュー | 独立したインスタンス |
| 14ファイルの PR のレビューがぶれる | ファイルごとのパスと統合のパス |
8. 用語集
| 用語 | 意味 |
|---|---|
| 誤検知（false positive） | 問題でないものを問題として報告すること |
| few-shot | プロンプトにいくつかの例を入れること |
| nullable | 値として null を許すこと |
| 意味のエラー | 形は正しいが、中身が正しくないエラー |
custom_id |
バッチのリクエストと結果を対応づける ID |
| SLA | 処理を終える約束の時間 |
| 複数パス | 1つの仕事を、目的の違う何回かの処理に分けること |
出典
- Claude Certified Architect – Foundations Exam Guide（PDF、Version 1.0、2026年7月）: 第6章 ドメイン4、第9章のサンプル問題
- Prompting best practices（Claude Platform Docs）: 明確な指示、例の使い方（関係が深い、多様、
<example>タグ） - Define tools（Claude Platform Docs）:
tool_choice、強制が使えないモデルと代わりの方法 - Strict tool use（Claude Platform Docs）:
strict: trueとスキーマの条件 - Structured outputs（Claude Platform Docs）:
output_config.format - Batch processing（Claude Platform Docs）: 50%、24時間、
custom_id、結果の種類 - Claude Code best practices（Anthropic Engineering）: 別の Claude にレビューさせる
注意: 第5.3節の「4時間ごと」は試験ガイドの例で、計算の考え方は筆者の説明です。strict: true のスキーマの細かい条件は変わることがあるので、使う前に公式ドキュメントで確かめてください（2026年11月時点）。内容は上の出典を要約・言い換えたものです（ライセンスに配慮して書き直しています）。