tool use と JSON Schema による構造化出力

tool use と JSON Schema による構造化出力は、Claude Certified Architect — Foundations（CCA-F）試験のタスクステートメント4.3「tool use と JSON Schema を使った構造化出力の強制」に直接対応する。このタスクステートメントはドメイン4（Prompt Engineering & Structured Output、配点比率20%）に位置し、試験が1回の試験につき4問引く6つのシナリオクラスターのうちの1つである構造化データ抽出シナリオクラスター全体の支柱だ。抽出パイプラインが不正な JSON を返せば、下流のすべてのシステムが壊れる。スキーマが厳密でもセマンティクスが空なら、システムは静かに間違った答えを出し続ける。tool use と JSON Schema による構造化出力は、機械が読める出力を求めるシナリオで試験が期待するアーキテクチャパターンだ。

本章では、アーキテクトが内面化すべき全体像を説明する。Claude における tool_use と JSON Schema が最も信頼できる強制メカニズムである理由、三つの tool_choice モード（"auto"・"any"・強制ツール選択）がモデルの振る舞いをどう変えるか、ハルシネーションを防ぐスキーマ設計パターン（nullable フィールド・enum + other・required vs optional）、構文エラーとセマンティックエラーの決定的な違い（厳密なスキーマは前者を防ぐが後者は防げない）、そしてバリデーターにかかる前に形式を正規化するプロンプト＋スキーマパターン。すべてのセクションは、試験が請求書パーサー・医療記録抽出器・契約条項分類器の設計を厳格な信頼性制約の下で問う構造化データ抽出シナリオクラスターに向けてチューニングされている。

構造化出力が CCA-F 構造化データ抽出シナリオにとって重要な理由

構造化データ抽出は公式試験ガイドに記載された6つの CCA-F シナリオクラスターの一つであり、このクラスター内のすべての問いは黙示的にtool use と JSON Schema による構造化出力をデフォルトパターンとして選択することを前提とする。シナリオでは、請求書・医療記録・法律契約・研究論文を受け取り、下流のサービスが人手を介したバリデーターなしに消費できる JSON を出力しなければならない本番システムが描かれる。自由形式のテキスト出力は許容されない。markdown コードフェンスに包まれた JSON も・末尾のカンマを持つ JSON も・ハルシネーションされたフィールドを持つ JSON も・間違ったキーにフィールド値がある JSON も許容されない。

試験が問うのは、tool use と JSON Schema による構造化出力が「JSON で答えてください」とシステムプロンプトで尋ねるよりも根本的に信頼できるということを理解しているかどうかだ。プロンプトベースの JSON 強制はスキーマ準拠をモデルのベストエフォート生成に委ねる。ツールベースの強制は Claude に契約を渡す。このスキーマに一致する引数を出力することが、このターンからの唯一の出口だ。アーキテクチャ上の違いは大きい。プロンプトベースの強制は助言的で、ツールベースの強制はプログラム的だ。

CCA-F ブループリントにおける構造化出力の位置付け

• ドメイン4・タスク4.3 — tool use と JSON Schema を使った構造化出力の強制（本章）。
• ドメイン4・タスク4.4 — 抽出品質のためのバリデーション・リトライ・フィードバックループの実装（本章と対になる）。
• ドメイン2・タスク2.1 — 明確な説明と境界を持つ有効なツールインターフェースの設計（同じツール定義の規律が抽出スキーマを動かす）。
• ドメイン2・タスク2.3 — エージェント間でのツールの適切な配布と tool_choice の設定（直接重なるサブスキル）。

ツール使用の概念はドメイン2とドメイン4にまたがって繰り返されるため、試験は構造化データ抽出の問いとツール設計の問いを同じクラスター内で組み合わせることが多く、どちらか一方を誤って学ぶともう一方に影響する。

最も信頼できる構造化出力強制メカニズムとしての tool use

tool use と JSON Schema による構造化出力の根本的な洞察は、Anthropic がツール定義をファーストクラスの型付きコントラクトとして扱うという点だ。input_schema を持つツールを定義して Claude にそのツールを強制的に呼び出させると、API は結果の tool_use ブロックの input ペイロードがスキーマに一致することを構文レベルで保証する——キーが存在し・値の型が正しく・必須フィールドが入力されている。

抽出ツールパターンのエンドツーエンドの動作

1. ツールを定義する — タスクを説明する名前と説明（例：record_invoice、説明「ドキュメントから抽出した構造化請求書フィールドを記録する」）。
2. input_schema を入力する — 下流サービスが期待する JSON スキーマ——必須フィールド・型・enum・nullable マーカー・ネストされたオブジェクト。
3. ドキュメントを送る — ドキュメントをユーザーメッセージとして送り、ツールを tools 配列に含める。
4. tool_choice を設定する — このツールの呼び出しを強制するようにモデルを設定する（次のセクションを参照）。
5. レスポンスを受け取る — Claude の出力は tool_use コンテンツブロックを含み、その input オブジェクトが抽出されたデータだ。stop_reason は tool_use になる。
6. input オブジェクトを直接消費する — ツールを実際に実行する必要はない。下流のアクションが不要なら tool_result のラウンドトリップを完全にスキップできる。

プロンプトベースの JSON リクエストより優れている理由

プロンプトベースの JSON 強制（「請求書番号・合計・明細項目のフィールドを持つ JSON オブジェクトを返してください…」）はモデルのトレーニングに基づいて整形式の JSON を生成することに依存する。観察された失敗モード：JSON を包む markdown コードフェンス・末尾のカンマ・一致しない引用符・JSON の前後の説明テキスト・ハルシネーションされたキー。ツールベースの強制はこれらの失敗モードをすべて排除する。API はクライアントが解析しなければならないテキストブロブではなく型付きの input オブジェクトを返すからだ。

tool_choice パラメーター：auto vs any vs 強制ツール選択

tool_choice はtool use と JSON Schema による構造化出力の中で最もテストされるパラメーターだ。モデルが自由形式のテキストで返信できるか・何らかのツールを呼び出さなければならないか・特定の名前付きツールを呼び出さなければならないかを制御する。三つのモードは三つの全く異なる抽出アーキテクチャに対応し、混同することは最も頻繁な試験ワナの一つだ。

モード1："auto" — モデルはテキストまたはツールを選択できる

tool_choice: "auto"（デフォルト）では、モデルはユーザー入力を検査して、ツール呼び出しが不要と判断してプレーンテキストで返信することがある。CCA-F 試験では、シナリオがすべての入力に対して保証された構造化出力を要求している場合、"auto" は誤りの選択肢だ——モデルがツールを呼び出す保証がなく、テキストレスポンスが下流の JSON コンシューマーを壊す。"auto" が適切なのは、テキストレスポンスが正当な結果である場合だけだ（例：アクションを実行するか確認のための質問をするか選択できるカスタマーサポートエージェント）。

モード2："any" — モデルは何らかのツールを呼び出さなければならない

tool_choice: "any" はツール呼び出しを保証するが、どのツールを選ぶかはモデルに委ねる。これは複数の抽出スキーマがある場合の正しい選択だ——例えば record_invoice・record_receipt・record_purchase_order という3つのツールがあり、Claude に各ドキュメントを適切なスキーマにルーティングさせたい場合。レスポンスは常に tool_use ブロックになる。アプリケーションはどのツールが呼ばれたかを処理する。"any" が誤りなのは、一つの抽出スキーマしか存在しない場合だ。余分なルーティングの自由は価値を加えず、曖昧さをもたらす可能性がある。

モード3：強制ツール選択 — モデルは特定のツールを呼び出さなければならない

tool_choice: {"type": "tool", "name": "record_invoice"} はモデルに record_invoice を呼び出すことを強制し、他のツールは呼び出せない。これは最も決定論的なモードであり、単一スキーマの抽出パイプラインにとってのデフォルト推奨だ。適切に設計された input_schema と組み合わせると、強制ツール選択は Claude の出力に対して最も厳格な束縛を与える。

知っておく価値のある4番目のモード："none"

tool_choice: "none" はツールが提供されていても tool calling を完全に無効化する。同じメッセージ履歴をターン間で再利用しつつ一時的にテキストレスポンスを強制したい場合に便利だ。試験が "none" を直接テストすることはまれだが、引っかけ選択肢として現れた場合の混乱を防ぐため認識しておく価値がある。

構文エラーとセマンティックエラー：厳密なスキーマが修正しないもの

これはtool use と JSON Schema による構造化出力トピック全体で最も負荷の高い区別であり、試験は容赦なくこれを利用する。厳密な JSON スキーマは構文への準拠を保証する——キーが存在し・型が一致し・enum 値が許可リストにあり・必須フィールドが入力されている。以下のことは何も保証しない。

• line_items 配列の合計が total フィールドと一致する。
• invoice_date が due_date より時系列的に前である。
• 抽出された customer_name が実際の顧客であり請求担当者ではない。
• ソースドキュメントの通貨記号が正しく currency enum に正規化された。
• shipping_address に属する値が billing_address に入ってしまっていない。

これらはすべてセマンティックエラーだ——JSON は整形式で、スキーマバリデーションに合格しているが、依然として誤っている。スキーマ機能でセマンティックエラーを防ぐことはできない。スキーマはソースドキュメントへのアクセス手段を持たないからだ。

試験がこの区別を重視する理由

構造化データ抽出シナリオはしばしば失敗報告を提示する。「抽出パイプラインはスキーマに対してバリデーションに合格した JSON を生成したが、total フィールドが line_items[].amount の合計と一致しなかった。アーキテクトはパイプラインにどの変更を加えるべきか？」厳密なスキーマがすべてのエラーを修正すると信じる受験者は「ツール定義に strict: true を追加する」を選ぶ。その答えは誤り——JSON はすでにスキーマ準拠だった。正しい修正はタスク4.4にある。セマンティック不変条件をチェックするバリデーションステップを追加し、違反をフォローアップのターンとしてフィードバックして Claude が自己修正できるようにする。

セマンティックエラーの軽減戦略

• バリデーション＋リトライループ（タスク4.4）：アプリケーションコードで不変条件を計算し、is_error: true と説明的なメッセージを含む tool_result を返し、Claude に再試みさせる。
• プロンプト内のフォーマット正規化ルール（下記を参照）：派生フィールドの計算方法を Claude に正確に伝えることで、セマンティックエラーを減らす（ただし排除はしない）。
• マルチパスレビュー（タスク4.6）：二番目の Claude 呼び出しが最初の Claude 呼び出しの出力を検証する。スキーマバリデーションとは独立している。
• 信頼度校正と人手によるレビュー（タスク5.5）：低信頼度の抽出を人間にルーティングする。

Required vs Optional フィールド：ハルシネーションを防ぐスキーマ設計の選択

JSON スキーマの中で、すべてのフィールドが Claude の振る舞いに微妙な影響を持つ。required vs optional の区別は単に下流コンシューマーの懸念ではなく、Claude がハルシネーションするかどうかに直接影響する。

Required フィールド

スキーマの required 配列に列挙されたフィールドは出力に存在しなければならない。Claude がソースドキュメントで情報を見つけられない場合、値をハルシネーションするかスキーマに完全に失敗するかのどちらかになる。フィールドを required にすることはコミットメントだ。「この情報はすべてのソースに常に存在する。確実に抽出せよ」と Claude に伝えている。

Optional フィールド

required 配列にないフィールドは省略されることがある。Claude はソースドキュメントが情報を提供するときにのみそれらを含める。これはドメインで真にオプショナルなフィールドに対してより安全なデフォルトだ——例えば請求書の discount_percentage。

アンチパターン：Required + nullable なし

フィールドがソースに現れないかもしれないのに required にすることは、tool use と JSON Schema による構造化出力で最も頻繁なハルシネーションのレシピだ。Claude はスキーマが要求する値を見つけられない場合、もっともらしく見えるが捏造された値を生成する。修正はフィールドをオプションにするか——よりよい方法として——required かつ nullable にすることだ。

Nullable フィールド：ハルシネーション防止パターン

nullable フィールドパターンは二つのスキーマ機能を組み合わせる。フィールドは required にあり、かつフィールドの型は null を含むユニオン（通常 ["string", "null"] や ["number", "null"]）だ。

既知のスキーマには nullable が optional より優れる理由

オプションフィールド（required にない）は下流コンシューマーに二つの曖昧なケースを残す。フィールドがないのはソースに情報がなかったからか、Claude が含め忘れたからか。nullable かつ required フィールドはこの二つのケースを一つに折りたたむ。null は常に「ソースにそれがなかった」を意味し、キーの欠如は拒否できるスキーマ違反だ。この明確さが、成熟した抽出パイプラインがすべての既知のフィールドに対してオプションよりも nullable-required を好む理由だ。

各パターンをいつ使うか

• Required・nullable なし — フィールドがドメインのすべてのソースドキュメントに必ず現れることが保証されている（例：すべての請求書の invoice_number）。
• Required・nullable — フィールドがスキーマのドメインにあるが、任意のソースに存在するかどうかわからない（例：discount_code や shipping_tracking_number）。
• Optional — フィールドが特定のドキュメントサブタイプにのみ意味があり、他のものには存在しないべき（例：B2B 請求書のみの tax_exempt_certificate_id）。

Enum + Other パターン：拡張可能な制御された語彙

多くの抽出スキーマには分類フィールドが含まれる——ドキュメントタイプ・顧客セグメント・インシデントカテゴリー——許容値のセットがほぼわかっているが、時々新しいものに遭遇する。素朴な enum は未知の値を拒否し、自由形式の文字列は制御された語彙のメリットを失う。enum + other パターンは両方を解決する。

パターンの仕組み

リテラル値 "other" を含む enum フィールドを定義し、"other" が選択された場合にのみ必須となるコンパニオン文字列フィールドを追加する。JSON スキーマの用語では：

• category — ["refund", "shipping", "billing", "technical", "other"] の enum 値。
• category_other_detail — 文字列。category == "other" の場合に required。

Claude が refund に明確に当てはまるインシデントに遭遇したとき、refund を選択して category_other_detail は null のままにする。Claude が enum の外のものに遭遇したとき、"other" を選択して category_other_detail に短い説明を入力する。

このパターンが試験で好まれる理由

構造化データ抽出シナリオはしばしば「チームが元のリストにないカテゴリーを含む3%のドキュメントがあり、パイプラインが拒否していると報告している」という一文を含む。正しいアーキテクチャ上の修正は enum + other パターンだ。enum を無制限に拡張すること（暗黙のうちに無制限に成長する）でも、enum を完全に削除すること（制御された語彙の保証を失う）でもない。

フォーマット正規化ルール：厳密なスキーマと並行してプロンプトを使う

厳密なスキーマは型と構造を保証するが、生の日付文字列をどう解析するか・通貨記号をどう扱うか・パーセンテージをどう変換するかを Claude に伝えることはできない。これらのフォーマット正規化の判断はプロンプトに存在し、スキーマにはない。最も信頼できるtool use と JSON Schema による構造化出力パイプラインは、厳密なスキーマとシステムプロンプト内の短い明示的な正規化ルールのリストを組み合わせる。

指定する価値のある一般的な正規化ルール

• 日付 — ISO 8601（YYYY-MM-DD）を指定する。03/04/2026 のような曖昧なソースフォーマットの処理方法を伝える（3月4日か4月3日か）。
• 通貨 — シンボルを含めるか・ISO 4217 コードか・数値のみか、そして多通貨ソースの処理方法を指定する。
• 数値 — 小数点区切り文字・千の区切り文字・パーセント記号を取り除くかどうかを指定する。
• Enum — ソースが同義語を使う場合（"shipping" vs "delivery" vs "logistics"）、各同義語がマッピングする正規の enum 値を伝える。
• 空白とケーシング — 文字列フィールドのトリムとケース正規化を指定する。

これらのルールが存在する場所

スキーマではなく、システムプロンプトまたはツールの説明に入れる。スキーマは型を強制する。プロンプトはセマンティクスを強制する。数例のサンプルブロック（タスク4.2）と組み合わせると、正規化ルールはスキーマを変えずにセマンティックエラーを劇的に減らす。

やさしい解説: tool use と JSON Schema による構造化出力

抽象的なスキーマとモードパラメーターは物理的なシステムに置き換えると直感的になる。三つの類比がtool use と JSON Schema による構造化出力の全体像を覆う。

類比1：確定申告書 — Required フィールド・Nullable フィールド・厳密なスキーマ

政府の確定申告書を想像する。申告書には固定された番号付きの欄がある——必須のもの（氏名・納税者番号・総収入）と条件付きのもの（扶養家族・寄付金・海外所得の申告）。適用されるかどうかにかかわらず値を要求する必須欄はスキーマのアンチパターンだ。海外所得がないのに「海外所得」欄が必須の場合、申告者は欄を空白にする（スキーマ違反）か、値を発明する（ハルシネーション）かのどちらかを迫られる。修正は nullable-required パターンだ。欄はフォームに現れなければならないが、フォームはそこに「N/A」と書くことを明示的に許可する。

JSON スキーマを持つ tool use は同じ規律だ。Claude に構造化されたフォームを渡し、どの欄を埋めなければならないかをマークし、適用されないかもしれない欄には捏造値を強制するのではなく明示的な「null」を許可する。強制ツール選択は Claude にこのフォームだけを渡して白紙を与えないようなものだ——代わりに自由な文章を提出する方法がない。

類比2：レストランの注文パッド — tool_choice モードとしての注文規律

注文を受けるウェイターには三つの規律がある。"auto" モードでは、ウェイターは注文パッドに書くこともできるし、何も書かずに客と単に会話することもできる——客がまだ決めていない場合に便利だ。"any" モードでは、ウェイターは何らかのパッドに書かなければならないが、料理パッドと飲み物パッドのどちらを選ぶかは自由だ——客が料理か飲み物のどちらかを注文する可能性がある場合に便利だ。強制モード（{"type": "tool", "name": "food_order"}）では、ウェイターは料理パッドに書かなければならない——テーブルがすでに飲み物を注文済みで料理だけが残っている場合に便利だ。

テーブルごとに完全な料理注文を受け取ることを期待する厨房は、"auto" モードを許容できない。ウェイターが手ぶらで来る可能性があるからだ。同様に、構造化データ抽出パイプラインは tool_choice: "auto" を許容できない。すべてのドキュメントから JSON が保証されなければならない場合。モードの選択は注文パッドの規律を厨房の信頼性のニーズに合わせることだ。

類比3：工場の品質検査員 — 構文エラーとセマンティックエラー

シリアルの密封箱を製造する工場を想像する。ライン末端の構文検査員は、すべての箱が正しい形状・正しい重量範囲・正しいバーコード・正しい賞味期限フォーマットを持つかどうかをチェックする。この検査員は不正な箱を発見するが、中の小麦フレークが実はコーンフレークであること、または表示された正味重量が10%ずれていることは検出できない。その深いチェックは箱を開けて内容物を量り、成分を検証するセマンティック検査員が必要だ。

厳密な JSON スキーマは構文検査員だ。箱が外から見て正しいことを保証する。セマンティックな正しさ——明細項目と一致する合計・正しく帰属された顧客名・内部的に一貫した日付——はアプリケーションコードでの別個のバリデーションパスまたは二番目の Claude によるレビューが必要だ。構文検査員のバッジで出荷にサインオフできると思うと試験のワナにはまる。

試験当日にどの類比を使うか

• required・optional・nullable フィールドに関する問い → 確定申告書の類比。
• tool_choice モードに関する問い → レストランの注文パッドの類比。
• 合計/クロスフィールド不変条件が修正されない厳密なスキーマに関する問い → 工場検査員の類比。

エンドツーエンドの構造化データ抽出パイプラインアーキテクチャ

tool use と JSON Schema による構造化出力のすべての部品を組み合わせると信頼できるエンドツーエンドのパイプラインが生まれる。CCA-F 試験は壊れたパイプラインからどのコンポーネントが欠けているかを特定するよう頻繁に問う。参照アーキテクチャを知っておけばこれらの問いはパターンマッチになる。

参照アーキテクチャ

1. インジェスト — ソースドキュメントが届く（PDF・OCR 経由の画像・HTML・メール）。
2. 前処理 — テキストの正規化・長いドキュメントのチャンク分割・ドキュメントメタデータの添付。
3. プロンプト構築 — フォーマット正規化ルールとサンプル例を含むシステムプロンプト・ドキュメントを含むユーザーメッセージ。
4. ツール定義 — 厳密な input_schema を持つ record_<document_type> ツール。分類フィールドには enum + other。ソースに存在するかどうかわからないフィールドには nullable-required。
5. API 呼び出し — tools 配列と tool_choice: {"type": "tool", "name": "record_<document_type>"} を持つ Messages API。
6. レスポンス処理 — Claude のレスポンスから tool_use.input オブジェクトを取り出す。
7. セマンティックバリデーション — アプリケーションコードがクロスフィールド不変条件（合計・日付の順序など）を検証する。
8. リトライループ（タスク4.4）— セマンティックバリデーション失敗時に、is_error: true と説明的なメッセージを持つ tool_result を構築し、Claude に再試みさせる。
9. 信頼度ルーティング（タスク5.5）— 低信頼度または繰り返し失敗するケースは人手によるレビューに送る。
10. 下流消費 — バリデーション済みの JSON がコンシューマーシステムに渡される。

各試験タスクのマッピング先

• タスク4.3 — ステップ4・5・6（本章）。
• タスク4.4 — ステップ7・8。
• タスク4.2 — ステップ3（サンプル例）。
• タスク4.1 — ステップ3（明示的な基準・精度）。
• タスク4.5 — レイテンシが重要でない場合、Message Batches API でパイプライン全体をバッチ処理。
• タスク4.6 — ステップ7の代替またはステップ7の拡張としてのマルチパスレビュー。
• タスク5.5 — ステップ9。

バッチ処理 vs 同期処理のトレードオフ

構造化データ抽出はしばしばボリュームで実行される——毎晩の請求書バッチ・毎週の契約書レビュー・毎月のコンプライアンス調査。CCA-F 試験はtool use と JSON Schema による構造化出力の問いとタスク4.5（バッチ処理）を定期的に組み合わせる。

同期処理

Messages API 経由でドキュメントごとに1回 API を呼び出す。レイテンシは低い（秒単位）が、リクエストあたりのコストは標準的でレート制限に同時実行が制約される。ユーザー向けフロー内で抽出が行われなければならない場合、またはすぐ消費するシステムに結果が流れる場合に適している。

Message Batches API によるバッチ処理

単一のバッチに最大100,000リクエストを提出する。結果は24時間以内に利用可能（しばしばはるかに早い）。コストは50%削減され、バッチエンドポイントには別個のレート制限ヘッドルームがある。抽出がオフライン・夜間・またはその他レイテンシ許容できる場合に適している。スキーマとツール定義は同期と同一——提出パスだけが変わる。

試験のワナ：常にバッチを選ぶ

試験はバッチが正しいシナリオ（大ボリューム・夜間）とバッチが誤りのシナリオ（リアルタイムのユーザー向け抽出）の両方を提示する。コストを節約するために常にバッチを選ぶことは既知の失敗パターンだ。シナリオのレイテンシ要件にモードを合わせること。

構造化出力の試験頻出ワナ

CCA-F はtool use と JSON Schema による構造化出力に関連した少数のワナパターンを積極的に狙う。各パターンを練習すること。

ワナ1：厳密なスキーマがすべてのエラーを修正する

典型的なワナ：シナリオがセマンティックエラー（合計が一致しない・日付が順不同）を説明し、答えが「ツール定義に strict: true を追加する」と言う。誤り——厳密なスキーマは構文エラーを防ぎ、セマンティックエラーは防げない。正しい答えはバリデーション＋リトライループにある。

ワナ2：tool_choice: "auto" は JSON を保証する

シナリオで「パイプラインは常に構造化 JSON を受け取らなければならない」と述べており、選択肢が "auto" を使う。誤り——"auto" はテキストレスポンスを許可する。強制ツール選択が単一スキーマパイプラインの正しい選択だ。

ワナ3：単一スキーマに対して強制選択の代わりに "any"

シナリオにはまったく一つの抽出スキーマがあり、選択肢が "any" を使う。厳密には壊れていないが、強制ツール選択の方が厳格であり、抽出ターゲットが既知の特定のツールである場合は常に CCA-F で好まれる答えだ。

ワナ4：tool use の代わりにシステムプロンプトが JSON を要求する

選択肢はツールが定義されず「この構造に一致した JSON だけで返信してください」と言うシステムプロンプトを使う。誤り——プロンプトベースの強制は助言的でありツールベースの強制はプログラム的だ。試験は一貫してプログラム的強制を好む。

ワナ5：時々ないフィールドに対して Required ＋ nullable なし

すべてのソースに現れないかもしれないフィールドが nullable 型なしで required とマークされている。このレシピはハルシネーションを誘発する。修正は required ＋ nullable にして、ソースに情報がない場合に Claude が明示的に null を出力できるようにすることだ。

ワナ6：enum + other の代わりに enum を無制限に拡張する

分類フィールドに時折新しい値が現れ、選択肢は新しい値が現れるたびに enum を拡張することを提案する。誤り——enum + other パターンが正しい拡張可能な設計だ。

練習アンカー：構造化データ抽出シナリオのテンプレート

tool use と JSON Schema による構造化出力に関連した CCA-F の練習問題は五つの形状にまとまる。各テンプレートはコミュニティの合格報告コーパス全体で複数回現れる。

テンプレートA：スキーマ強制メカニズム

「チームが特定のスキーマに常に一致する JSON を生成しなければならない請求書抽出パイプラインを構築している。最も信頼できるアプローチはどれか？」正答：スキーマを input_schema として持つ抽出ツールを定義し、強制 tool_choice を使う。引っかけ：JSON を要求するシステムプロンプト・自由形式出力の正規表現後処理・ファインチューニング（CCA-F のスコープ外）。

テンプレートB：tool_choice モード選択

「抽出パイプラインには三つのツール——record_invoice・record_receipt・record_purchase_order——があり、ドキュメントごとにちょうど一つを呼び出さなければならない。正しい tool_choice 設定はどれか？」正答："any"（モデルは何らかのツールを呼び出さなければならないが、どのツールを選ぶかはモデルが決める）。引っかけ："auto"（保証なし）・特定のツールへの強制選択（ルーティング能力を失う）・"none"（ツールを完全に無効化）。

テンプレートC：セマンティックエラー vs 構文エラーの診断

「抽出パイプラインは厳密なスキーマに対してすべての出力のバリデーションに成功しているが、2%の請求書で明細項目の合計が合計と一致しない。最も効果的な修正は何か？」正答：合計を計算して is_error: true を持つ tool_result 経由で違反をフィードバックするバリデーションステップを追加する。引っかけ：strict: true を追加（すでに厳密）・より多くの制約でスキーマを拡張（セマンティックエラーはスキーマ違反でない）・"auto" に切り替える（無関係で有害）。

テンプレートD：オプションフィールドのハルシネーション防止

「ソースの請求書が時々 shipping_tracking_number フィールドを省略し、Claude がこれが起きたときに値を捏造している。スキーマをどのように更新すべきか？」正答：フィールドを required かつ nullable にする。引っかけ：optional にする（「Claude はそれに対処しなければならない」という振る舞いを失い、キー不在の曖昧さをもたらす）・フィールドを完全に削除（下流の情報を失う）・システムプロンプトルールを追加（プロンプトベースでスキーマベースの強制より弱い）。

テンプレートE：拡張可能な分類

「サポートチケット分類スキーマには五つのカテゴリーの enum があり、新しいチケットタイプが時々現れる。チームは enum を拡張し続けたくない。どのパターンを採用すべきか？」正答：コンパニオンの自由形式詳細フィールドを持つ enum + other。引っかけ：enum を完全に削除（制御された語彙を失う）・新しいタイプごとに enum を拡張（無制限の成長）・別個の分類器を訓練（スコープ外）。

tool use と JSON Schema による構造化出力 よくある質問（FAQ）

なぜ tool use はプロンプトベースの JSON 強制より信頼できるのか？

Messages API がツール定義を型付きコントラクトとして扱うからだ。Claude が tool_use コンテンツブロックを出力するとき、API レベルで input オブジェクトがツールの input_schema に構文レベルで準拠することが保証される——キーが存在し・型が正しく・必須フィールドが入力され・enum 値が有効。プロンプトベースの JSON 強制はモデルのトレーニングに基づいて整形式の JSON を生成することに依存し、markdown フェンス・末尾のカンマ・ハルシネーションされたキー・JSON の前後の文章で一般的に失敗する。試験は一貫してプログラム的強制（tool use）をプロンプトベースの強制（JSON を要求するシステムプロンプト）より好む。

tool_choice: "auto" と "any" と強制選択の違いは？

"auto" はモデルがツールを呼び出すかテキストを返すかを決定できるようにする——モデルはツールを呼び出す代わりにテキストを返す可能性がある。"any" はモデルに何らかのツールを呼び出すことを強制するが、利用可能なツールの中からどれを選ぶかはモデルに委ねる。強制選択（{"type": "tool", "name": "..."}）はモデルに特定の名前付きツールを呼び出すことを強制する。単一スキーマの構造化データ抽出には強制選択がデフォルトの推奨だ。マルチスキーマルーティングパイプラインには "any" が正しい。"auto" はテキストレスポンスが正当な結果である場合にのみ適している。ほとんどの構造化データ抽出シナリオではそうでない。

厳密な JSON スキーマは Claude のフィールド値のハルシネーションを防ぐか？

いいえ。厳密なスキーマは構文エラー（必須フィールドの欠如・型の誤り・無効な enum 値）を防ぐが、セマンティックエラーを検出できない——スキーマに準拠しているが現実では誤っている値。明細項目と一致しない合計・順番が逆の日付・間違ったフィールドに帰属した顧客名はすべて厳密なスキーマバリデーションに合格する。フィールド値のハルシネーションを防ぐには別個のメカニズムが必要だ。nullable-required フィールド（Claude が「わからない」と明示的に言えるように）・プロンプト内のフォーマット正規化ルール・バリデーション＋リトライループ・マルチパスレビュー。

optional フィールドの代わりに nullable-required フィールドをいつ使うか？

スキーマのドメインにあるが任意のソースドキュメントに現れるかどうかわからないフィールドには nullable-required を使う——例えば請求書の discount_code。nullable-required は Claude に常にフィールドに対処させ・ソースに情報がない場合に null を出力するスキーマ合法な方法を与える。これはハルシネーションを防ぎ、オプションフィールドがもたらすキー不在 vs 忘れたの曖昧さを排除する。特定のドキュメントサブタイプにのみ意味があり他には存在しないべきフィールドには真にオプション（required にない）を使う。

enum + other パターンとは何で、いつ使うべきか？

enum + other パターンは enum にリテラル値 "other" を追加し、"other" が選択された場合にのみ required となるコンパニオンの自由形式文字列フィールドと組み合わせる。分類フィールドが値のセットがほぼわかっているが時々新しいものに遭遇するときに使う。このパターンは一般的なケースの厳密なスキーマバリデーションを保持し・既知のカテゴリーでの下流分析を保持し・無制限の enum 成長なしに新しいカテゴリーのためのきれいな逃げ道を提供する。拡張可能な制御された語彙のための CCA-F 推奨アーキテクチャだ。

構造化抽出におけるセマンティックエラーと構文エラーの違いは？

構文エラーは JSON スキーマに違反する出力だ——必須フィールドの欠如・型の誤り・無効な enum 値・不正な JSON。強制 tool_choice を持つ厳密な tool use スキーマが API レベルで構文エラーを排除する。セマンティックエラーはスキーマに一致するが現実では誤っている値を持つ出力だ——明細項目と一致しない合計・順番が逆の日付・間違ったフィールドにある値。セマンティックエラーはスキーマバリデーションに合格し、スキーマメカニズムには見えない。修正にはアプリケーションコードのバリデーション・フィードバック付きリトライループ・マルチパスレビュー・人手によるレビューワークフローが必要だ。この区別は CCA-F 構造化データ抽出問いで最も多く悪用されるワナだ。

フォーマット正規化ルールはスキーマとプロンプトのどちらに入れるか？

プロンプトに入れる。スキーマではない。JSON スキーマは型と構造を強制する。生の日付文字列をどう解析するか・どの通貨記号を除去するか・ソースの同義語を正規の enum 値にどうマッピングするかを Claude に伝えることはできない。フォーマット正規化ルール（ISO 8601 日付・ISO 4217 通貨コード・小数点区切り文字の処理・同義語から enum へのマッピング）はシステムプロンプトまたはツールの説明に属する。サンプル例（タスク4.2）と組み合わせると、明示的な正規化ルールはスキーマ自体を変えずにセマンティックエラーを劇的に減らす。パターンはスキーマで構造・プロンプトでセマンティクスだ。

参考資料

• Claude Certified Architect — Foundations Exam Guide：https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Increase output consistency — Anthropic Docs：https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Strict tool use — schema-guaranteed output：https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/strict-tool-use
• Define tools — tool descriptions and tool_choice：https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/implement-tool-use
• Tool use with Claude — overview and agentic loop：https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Handle tool calls — tool_result format and error responses：https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Message Batches API — high-volume extraction：https://docs.anthropic.com/en/docs/build-with-claude/batch-processing

関連 ExamLab 章：Few-Shot プロンプティングと出力の一貫性、抽出品質のためのバリデーションとリトライループ、ツール定義と説明、大量抽出のためのバッチ処理、プロンプト精度のための明示的な基準。