validation・retry・feedback loop

CCA-F（Claude Certified Architect — Foundations）試験のタスクステートメント4.4 — 「extraction品質のためのvalidation・retry・feedback loopを実装する」 — はDomain 4（Prompt Engineering & Structured Output、20%のウェイト）に位置し、タスク4.3（structured outputを通じたtool use）の運用的な対応物だ。タスク4.3は整形されたJSONオブジェクトを要求する方法を教え、タスク4.4はそのオブジェクトがまだ間違って返ってきた場合に何をするかを教える。CCA-Fの6シナリオプールのStructured Data Extractionシナリオはタスク4.4の問題に支配されている。実際のextractionパイプラインは初期のプロンプトと同じくらいそのretry動作によって定義されるからだ。

この学習ノートでは、CCA-F候補者がアーキテクチャレベルで設計しなければならないvalidation-retryの全体像を説明する。2層のvalidationモデル（スキーマ、次にセマンティック）・レスポンスを「完了」から「retry必要」に昇格させるtrigger条件・修正retryプロンプトの正確な形状・フィールドレベル対全文書の再extractionの区別・prioritizationシグナルとしてのconfidenceキャリブレーション・一時的な失敗に対するbackoff戦略・無限のvalidationループを防ぐハードキャップ・そしてリトライを使い果たしたものを人間のレビュアーにルーティングするescalationパターン。最後の2つのセクション（Common Exam TrapsとPractice Anchors）はすべての概念をStructured Data Extractionシナリオに結び付ける。6つの問いを持つFAQがノートを締め括る。

Validationレイヤーの目的 — Extraction後にスキーマ違反とセマンティックエラーを捕捉する

validationレイヤーはClaudeのextractionレスポンスとダウンストリームのビジネスシステムの間に位置するコードだ。抽出されたすべてのオブジェクトについて、その出力がコミットしても安全かどうか、またはretryを通じて送り返すべきかどうかを決定するのが仕事だ。validationレイヤーなしでは、すべての不正または意味論的に間違ったextractionがデータベース・分析パイプライン・顧客向け製品にサイレントに伝播する。

Validationはclaudeの機能ではなく、アプリケーションの機能だ。Claudeはstrict tool useを通じて構文的に有効なJSONを常に返すよう設定できるが、Claudeは抽出された請求書の合計が明細項目と一貫しているか・日付が現実的な範囲内にあるか・法的条項番号が参照された契約に実際に存在するかを確認できない。validationレイヤーはアプリケーションが、単に解析可能なだけでなく現実世界で正しいextractionを作るルールをエンコードする場所だ。

CCA-F候補者はvalidationレイヤーがすべてのextractionについて生成する3つの結果を内面化すべきだ：

1. Accept — extractionはすべてのチェックを通過してダウンストリームシステムにコミットされる。
2. Retry — extractionは少なくとも1つのチェックに失敗したが、その失敗は回復可能だ。修正プロンプトを構築してClaudeを再呼び出しする。
3. Escalate — extractionが何度も失敗しているか、エラーが構造的に回復不能だ。ドキュメントを人間のレビュアーにルーティングする。

ExtractionパイプラインでValidationが必須な理由

Extractionタスクはサイレント失敗の最悪のケース環境だ。1つのドキュメントで誤動作する分類タスクは通常、ダウンストリームのレビュアーが捕捉できる間違ったラベルを生成するだけだ。誤動作するextractionタスクは、正しく見え、JSONパーシングを通過し、データベースにきれいに入り込む構造化オブジェクトを生成するが、悪い請求書金額・ずれた小数点・間違った税管轄を持つ。サイレントな構造化エラーはうるさいテキストエラーよりはるかにコストが高い。これがStructured Data ExtractionシナリオがvalidationデザインにDisproportionateなウェイトを置く理由だ。

スキーマValidation — 最初のValidationゲートとしてのプログラム的JSON Schemaチェック

最初のvalidationゲートはスキーマvalidationだ。抽出されたオブジェクトがtool definitionで宣言されたJSON Schemaに準拠しているかどうかのプログラム的チェック。スキーマvalidationは必須フィールドの欠如・型の不一致・enumの違反・制約の違反（min/max・パターン・フォーマット）を捕捉する。

Strict Tool UseはスキーマFailureを削減するが排除しない

ツールをstrict: trueで宣言するとClaudeはスキーマに正確に一致する出力を生成するよう制約される。必須フィールドは常に存在し・enumは常に宣言された値の1つを保持し・ネストされたオブジェクトの形状は保持される。Strict tool useはスキーマの失敗を劇的に削減するがスキーマvalidationをオプションにしない：

• 非strictのtool definition（レガシーまたは特定のモデル）は依然として時々スキーマ違反を出力する。
• Strict modeは構造を強制するが内容は強制しない。文字列フィールドは空のままになる可能性があり、数値フィールドはゼロになる可能性があり（すべきでない場合でも）、enum値はまだ間違ったenum memberになる可能性がある。
• プラットフォームレベルの失敗（max_tokensでJSON途中のレスポンスが切断される）はstrict modeでも無効な出力を生成できる。

スキーマValidationがチェックすること

完全なスキーマvalidationステップは以下を検証する：

• 存在 — すべての必須フィールドが存在する。
• 型 — 各フィールドの値が宣言されたJSON型に一致する。
• Enumメンバーシップ — セットに制約された値がセット内にある。
• 数値境界 — min/max制約が満たされている。
• 文字列フォーマット — 宣言されたフォーマット（date・email・uri・uuid）が正しくパースされる。
• 配列長 — minItems/maxItemsが満たされている。
• オブジェクト深度 — ネストされた構造が宣言された形状に一致する。

スキーマValidationは確定的

スキーマvalidationは純粋に確定的だ。同じオブジェクトは常に同じ結果を生成する。これはCCA-Fにとって重要で、試験は確定的なスキーマチェックを非確定的なセマンティックチェックと頻繁に対比させ、どちらを最初に実行すべきかを問う。正しい答えは常にスキーマが最初だ。オブジェクトが構造的に壊れている場合、セマンティックチェックはまったく実行できない。

セマンティックValidation — スキーマ準拠を超えたビジネスルールチェック

スキーマvalidationはオブジェクトが整形されていることを証明する。セマンティックvalidationはオブジェクトが正しいことを証明する。これらは異なる問題であり、異なるマシナリーを必要とする。

セマンティックValidationがカバーすること

セマンティックvalidationはJSON Schema制約として表現できないビジネスルールをエンコードする。典型的なチェック：

• クロスフィールドの一貫性 — 請求書の合計が明細項目と税の合計に等しい。
• ドメイン範囲チェック — 注文日が過去365日以内にある。
• 参照整合性 — 顧客IDが顧客テーブルに実際に存在する。
• 論理的な依存関係 — has_discountがtrueならばdiscount_amountは正でなければならない。
• ドキュメントの一貫性 — 抽出されたフィールドが他のフィールドやソースドキュメントと矛盾しない。
• 数値的な妥当性 — 小包注文での50,000kgの配送重量は疑わしい。

セマンティックValidationはアプリケーションが実装しなければならない

これはCCA-F Domain 4で最も高い頻度のトラップだ。Claudeはセマンティックvalidationを自動的に実行しない。strictなtoolスキーマは「合計が明細項目の合計に等しくなければならない」を表現できない。そのルールはアプリケーションコードの中にある（手書きのアサーション・ルールエンジン・または最初のextractionをチェックすることに専念した2番目のClaude呼び出しとして）。validationレイヤーはアプリケーションのコードであり、Claudeのコードではない。

単一ドキュメント対クロスドキュメントのセマンティックチェック

セマンティックチェックは2つのクラスに分かれる：

• 単一ドキュメント — 抽出されたオブジェクトのみを参照するルール（合計=項目の合計）。
• クロスドキュメント — 外部の状態を参照するルール（顧客IDが存在する・ベンダーが承認されたリストにある）。

クロスドキュメントのチェックはデータベースルックアップやAPI呼び出しを必要とし、通常より遅くコストがかかる。validationレイヤーを設計することは、どのチェックがすべてのextractionで実行されるかとどのチェックがフラグが立ったときのみ実行されるかを決定することだ。

セマンティックValidation自体がClaudeを使用できる

CCA-Fシナリオに現れる本番パターンは、最初のextractionを検証するために2番目のClaude呼び出しを使用することだ。最初の呼び出しがextractし、2番目の呼び出しはextractionとソースドキュメントを与えられてextractionが忠実であるかどうかを尋ねられる。これはLLM-as-judgeパターンと呼ばれることもある。確定的なルールチェックの代替ではなく、ルールが見落としたセマンティックエラーを捕捉する追加層だ。

RetryTrigger条件 — スキーマ失敗・閾値以下のConfidence・必須フィールドの欠如

Retryはvalidationレイヤーが修正可能な失敗（修正プロンプトで修正できる可能性が高いエラー）を生成した場合に引き起こされる。すべての失敗がretryの候補ではない。一部は回復不能で即座にescalateしなければならない。CCA-Fは候補者に3つの標準的なretry triggerを知ることを期待する。

Trigger 1：スキーマValidation失敗

抽出されたJSONが宣言されたスキーマに違反した（必須フィールドの欠如・値の型の誤り・allowedセット外のenum・数値境界の違反）。スキーマの失敗は高信頼度のretry候補だ。エラーは正確に説明できるからだ：どのフィールドがどの制約に違反したかをClaudeに正確に伝えることができる。

Trigger 2：閾値以下のConfidence

extractionスキーマにper-fieldのconfidenceスコア（例：confidence: 0から1の間の数）が含まれており、1つ以上のフィールドが設定された閾値を下回る場合、extractionは技術的に壊れていないが信頼できない。このケースのretryは通常、低confidenceのフィールドリストをClaudeに渡してそれらの特定のフィールドをより注意深く再検査するよう指示する。

Trigger 3：必須フィールドの欠如または空

決して空であるべきでないフィールドが空の文字列・null・プレースホルダー（「N/A」・「unknown」）として返ってきた。スキーマがフィールドをオプションと宣言した場合でも、ビジネスルールによってはそれが設定されることを必要とする場合がある。Retryはnullにフォールバックする前に不足している情報についてソースを再検査するようClaudeに求めることができる。

Retryすべきでない場合

すべての失敗がretryされるわけではない。回復不能なtriggerには：

• ソースドキュメントが判読不能 — どんな再プロンプトもOCRのゴミを修正しない。
• 必要な情報がソースに存在しない — 請求書にベンダーの税IDがない場合、Claudeが20回retryしてもそれを作り出せない。
• Retry予算が使い果たされた — Retry回数が最大制限に達した（以下を参照）。
• スキーマ定義自体が壊れている — これはモデルの欠陥ではなくコードの欠陥だ。

これらのケースでretryを送ることは、トークンを無駄にして2回目も同じ失敗を生成する。

RetryプロンプトDesign — Validationエラーを修正指示としてFeedbackする

Retryはそこに入れる情報と同じくらいしか効果がない。核心的な原則は：validationエラーをClaudeへの自然言語の修正指示として扱うこと。これが壊れたextractionを修正されたものに変換するfeedback loopだ。

3部構成のRetryプロンプト

すべての効果的なretryプロンプトは3つのコンポーネントを組み立てる：

1. 元のextractionターゲット — ソースドキュメントまたはその関連スライス。
2. 以前の（壊れた）extraction — Claudeが前回生成したオブジェクト。
3. Validationエラーの説明 — 何が具体的に間違ったか、自然言語と構造化された詳細で。

Claudeはその後、特定のエラーを修正し（理想的には）すでに正しかったフィールドを乱さない新しいextractionを生成する。

エラー説明のフォーマット

Validationエラーは構造化されていて正確でなければならない。良いエラー説明は：

• どのフィールドが失敗したか — JSONパスを使用する（例：line_items[2].tax_rate）。
• どのルールに違反したか — 「0と1の間の数でなければならない」または「必須だがnullだった」。
• どうすればルールを満たすか — 「税率を小数として抽出してください；請求書には8.25%と表示されています」。

これを悪いエラー説明と比較する：「出力が間違っていた。」Claudeは見つけられないものを修正できない。

is_error: trueでのtool_resultの使用

Agentic-loopアーキテクチャの中で、retry feedbackは通常is_error: trueでcontentフィールドにエラー説明を持つtool_resultブロックとしてパッケージされる。Claudeはis_error: trueに修正されたinputでツール呼び出しを再送することで反応する。このパターンはタスク2.2（structured error responses）がMCPツールに教えるのとまったく同じメカニズムであり、extraction validationに適用される。

可能であれば成功したフィールドを保存する

微妙だが一般的な本番パターン：11の抽出フィールドのうち10が正しければ、retryはゼロから再抽出すべきでない。代わりに、retryプロンプトは10の正しいフィールドを含み、Claudeに失敗しているものだけを修正するよう求める。これはフィールドレベルのfeedback（以下の専用セクションを参照）であり、CCA-Fで代替手段が無駄なフル再抽出の場合に正しい答えであることが多い。

最大Retry回数制限 — 無限のValidationループを防ぐ

すべてのretryアーキテクチャには、ドキュメントごとのretry試行回数にハードな最大値が必要だ。この制限なしでは、解決できない問題を持つ単一のドキュメントが無制限のトークンを消費して上限のないAPIの請求を生成できる。CCA-Fはretryキャップをベースラインの安全期待として扱い、agentic loopのイテレーションキャップの期待を反映する。

典型的なRetryキャップ

• 本番のextractionパイプライン — 2〜3回のretry。
• 開発とデバッグ — 詳細ログで最大5回のretry。
• 高価値・高コストのドキュメント — 最大5回のretryとescalationレビュー。

5回を超えるretryはほぼ常に逆効果だ。差別化されたプロンプトでの3回の試みが失敗した場合、4回目はほとんど成功しない。失敗モードは通常、偶発的なものではなく構造的なもの（ソースドキュメントが曖昧）だ。

Retry回数はセッションではなくドキュメントごと

10,000のドキュメントのバッチは「1つのretry予算」ではない。各ドキュメントは独自のretry回数を持つ。retryカウンターはパイプラインが次のドキュメントに移るときにリセットされる。per-document対per-batchのretry semanticsを混同することはCCA-Fのdistractor パターンだ。

Retry状態の追跡

実装は3つの場所でretry状態を追跡する：

1. Per-documentのretry回数 — そのドキュメントのすべてのretryでインクリメント。
2. Per-pipelineの失敗率 — 多くのドキュメントがretryを使い果たしているなら、何かが体系的に間違っている（プロンプトの退行・ソースデータのシフト・モデルバージョンの変更）。
3. Per-fieldのretry履歴 — 複数のドキュメントにわたって繰り返し失敗している特定のフィールド。

これらのメトリクスは後述のobservabilityサーフェスをフィードする。

一時的な失敗に対するExponential Backoff対プロンプト修正に対する即時Retry

Retryは非常に異なるタイミングルールを持つ2つのカテゴリに分類される。これらを混同することはよくあるCCA-Fのトラップだ。

一時的な失敗 — Exponential Backoff

失敗がプラットフォームまたはネットワークの条件（レートリミット到達・5xxレスポンス・タイムアウト）の場合、正しいレスポンスはexponential backoffのretryだ。典型的なパターン：1秒待機、次に2秒、4秒、8秒、16秒、そしてescalate。レートリミットで即座にretryするとレートリミットをまた引き起こすだけのことが多い。

プロンプト修正のRetry — 即時

失敗がコンテンツの問題（validationエラー・欠けているフィールド・低confidence）の場合、修正されたプロンプトで即時のretryが正しいレスポンスだ。16秒待機しても役立たない。変更したのはプロンプトであってネットワークではないからだ。コンテンツのretryにbackoffするとクロック時間が無駄になるだけだ。

同じカウンターを使用しない

2つのretryカテゴリは別々のカウンターを使用すべきだ。一時的なretryとプロンプト修正のretryは概念的に異なるイベントであり、予算を共有すべきでない。

Agentic loopとの統合

両方のretryカテゴリは、タスク1.1が教えるagentic loopの中に存在する。違いはどのswitch statementのブランチがretryを引き起こすかだ：

• tool_useでis_error: true, errorCategory: transientを返すツール → exponential backoff retry。
• 成功したツールの返却後のvalidation失敗 → 修正プロンプトでの即時retry。

Feedback Loopアーキテクチャ — エラー説明+問題のある出力 → 修正されたExtraction

Feedback loopはvalidation・retry trigger ロジック・retryプロンプト構築を単一の再利用可能なコンポーネントに合成するクローズドループアーキテクチャだ。これはCCA-F候補者がオンデマンドでスケッチできるべきアーキテクチャ図だ。

5ノードのFeedback Loop

1. Extract — Claudeがstrict tool useを通じて構造化出力を生成する。
2. スキーマvalidate — プログラム的なJSON Schemaチェック。失敗時、スキーマエラーでノード5に移動。
3. セマンティックvalidate — アプリケーションレベルのルールチェック。失敗時、セマンティックエラーでノード5に移動。
4. Accept — extractionはすべてのチェックを通過；ダウンストリームにコミット。
5. Retryの決定 — retryキャップ以下か？はいなら、修正プロンプトを構築してノード1に戻る。いいえなら、escalate。

ループのInputとOutput

ループの各パスは定義されたinput（ソースドキュメント+以前のextraction+エラー説明）と定義されたoutput（acceptされたextractionまたはescalationパケット）を持つ。人間のレビュアーに送られるパケットはソースドキュメント・すべてのextraction試行・すべてのvalidationエラーを含むべきだ。レビュアーに完全なコンテキストを与え、将来のプロンプト改良のためのトレーニングデータとしても機能する。

ループの終了条件

ループは3つの方法で終了する：

• 成功 — extractionがスキーマとセマンティックvalidationの両方を通過する。
• Retryキャップの使い果たし — ドキュメントが人間のレビューにescalateされる。
• 回復不能なエラー — ソースドキュメントが判読不能または重要な情報が欠落している；それ以上のretryなしで直接escalate。

ループはシナリオ固有

CCA-Fプールのstructured data extractionシナリオはこのloopを直接押す。retry対escalateを正しく区別するか・構造化対ジェネリックなエラー説明を使用するか・最大retryキャップが合理的かをテストする質問を予期する。

フィールドレベルのFeedback — 特定フィールドへのターゲットを絞った修正 vs フル再Extraction

マルチフィールドのextractionが部分的に成功した場合（11のフィールドのうち10が有効、1つが壊れている）、retryは2つの形状のうちの1つをとることができる。

フル再Extraction

ソースドキュメント全体を送り返してすべてのフィールドの新鮮なextractionを求める。最も実装が簡単だが、トークンを無駄にして以前に正しかったフィールドを劣化させるリスクがある。extractionが体系的にずれていることを示唆する（Claudeがドキュメントの種類を誤認識したなど）場合に使用する。

フィールドレベルの修正

ソースドキュメントと10の正しいフィールドと1つの壊れたフィールドへのターゲットを絞った修正指示を送る。Claudeのレスポンスは新鮮なextractionではなくパッチだ。以前に正しかった出力を保存して収束が早い。

どちらを選ぶか

• 孤立したフィールドの失敗（1つのフィールドが間違い、残りは正しい）→ フィールドレベルの修正。
• クロスフィールドの不一致（フィールドが互いに矛盾している）→ フル再extraction。
• 体系的な失敗（extraction全体がずれているかハルシネーションされているように見える）→ フル再extraction。
• 低confidenceのフィールドバッチ→ フラグが立てられたフィールドのみのフィールドレベルの修正。

実装の形状

フィールドレベルの修正は通常、以前のextractionをユーザーメッセージのコンテキストとして明確な指示と共に追加することで実装される：「以前のextractionはこちらです。フィールドXは理由Yで無効です。フィールドXを修正して他のすべてのフィールドを変更せずに保持した更新されたextractionを生成してください。」

CCA-Fの傾向

コミュニティの合格レポートはCCA-Fシナリオが問題の範囲を「<特定のフィールド>が無効」と表現する場合（「extractionが間違っている」ではなく）、フィールドレベルの修正をフル再extractionより好む傾向があることを示している。

Confidenceキャリブレーション — フィールドレベルのConfidenceスコアを使ってValidationに優先順位をつける

成熟したextractionスキーマにはすべてのフィールドにconfidenceスコアが含まれる。Claudeは値を抽出するだけでなく、extractionにどれだけ自信があるかを評価するよう求められる。Confidenceスコアはvalidationの優先順位とretryのtriggerを駆動する。

スキーマでConfidenceフィールドを宣言する方法

並列フィールド構造またはネストされた{ value, confidence }オブジェクトを追加する：

• フラット並列：invoice_totalとinvoice_total_confidence。
• ネスト：invoice_total: { value: 1234.56, confidence: 0.92 }。

ネストされた形状は通常クリーンでvalidateしやすい。

Retry TriggerとしてのConfidenceの使用

フィールドごと（またはフィールドクラスごと）にconfidence閾値を定義する。confidenceが閾値を下回るとフィールドがretryターゲットリストに追加される。典型的な閾値：

• 重要なフィールド（金額・日付・法的識別子）— 0.90。
• 標準フィールド（名前・説明）— 0.75。
• オプションフィールド（メモ・タグ）— 0.60。

キャリブレーションは不完全

Claudeの自己報告confidenceは較正された確率ではない。「これがどれだけ確かなように感じるか」という評価に近い。Confidenceスコアを相対的な優先順位付けシグナルとして扱う。「どのフィールドがより精査に値するか」であり、頻度主義的な確率としてではない。

セマンティックチェックとConfidenceのクロスリファレンス

セマンティックvalidationを通過しても低confidenceのフィールドは依然としてフラグが立てられるべきだ。セマンティックvalidationに失敗しながら高confidenceを報告するフィールドはClaudeが自信を持って間違っていたことを明らかにする。これはvalidationルールまたはプロンプト基準を引き締めるサインだ。

Retry使い果たしでのEscalation — N回の失敗試行後に人間のレビューにルーティングする

Retryキャップに達してextractionがまだvalidationを通過していない場合、feedback loopはescalationで終了する。Escalationは「失敗」ではなく、ドキュメントを人間のレビュアーに移動させる設計された結果であり、そのレビュアーはextractionを完了させるためのコンテキストを持っている。

Escalationパケットに含める内容

• ソースドキュメント — インラインまたはURIで参照。
• すべてのextraction試行 — ClaudeがPRODUCEDしたN回の試行。
• すべてのvalidationエラー — 試行ごとのスキーマ失敗とセマンティック失敗。
• 任意のツールエラー — 途中で起きた一時的な失敗。
• メタデータ — ドキュメントの種類・retry回数・消費された合計トークン・タイムスタンプ。
• 集中すべきフィールドの提案 — レビュアーはゼロから再validationする必要はない。

Escalationルーティング

Escalationは常に単一の人間キューに行くわけではない。ルーティングルールには通常：

• フィールドの種類別 — 税識別子は財務訓練を受けたレビュアーへ；法的条項は法務チームへ。
• Confidenceパターン別 — 複数の低confidenceフィールドはドキュメント品質の問題を示す；ドキュメント受付チームにルーティング。
• ドキュメントソース別 — 特定のベンダーまたはドキュメントクラスは専用のレビュアーを持つ。

EscalationはプロンプトImprovementをフィードする

Escalatedされたextractionはextractionプロンプトを改善するための最良のトレーニングシグナルだ。Escalationパケットを収集し、共通の失敗パターンを分析し、プロンプトとスキーマを改良する。多くのドキュメントで同じ理由で同じフィールドがescalateするパイプラインは、プロンプトがあるケースのカバレッジを欠いていることを示している。

サイレントに失敗したExtractionをドロップしない

微妙なアンチパターン：retryが使い果たされたとき、パイプラインがドキュメントを「失敗」として処理してどこかにログを記録するが、誰も見ない。これはパイプラインがないよりも悪い。extractionカバレッジの幻想を生み出しながらサイレントにドキュメントを失う。EscalationはSLAを持つ設計された、監視されたキューでなければならず、ドロップフォルダーではない。

Observability — すべてのValidation結果とRetry試行をログに記録する

本番のvalidation-retry loopはテレメトリなしには運用できない。6つのシグナルが重要だ。

計器化するシグナル

1. Per-documentのretry回数 — コーパス全体の分布により、どのドキュメントの種類が最も難しいかがわかる。
2. Per-fieldのvalidation失敗率 — どのフィールドが最もよく失敗するか；プロンプト改良の候補。
3. スキーマ対セマンティックの失敗比率 — セマンティックの失敗が支配的なら、プロンプトが緩すぎる；スキーマの失敗が支配的なら、strict tool useの設定が間違っている。
4. Retryの収束率 — retryの何割が1回目・2回目・3回目で成功するか。
5. Escalation率 — 人間のレビューに到達するドキュメントの全体的な割合。
6. 成功したextractionあたりの消費されたトークン — 成功した出力の単位あたりのコスト。

アラート閾値

上記のいずれかがベースラインから外れたときにアラートを出す。モデルバージョンのバンプ後のスキーマ失敗率の急増は、例えば新しいモデルでextractionプロンプトが退行した早期警告だ。

Feedback loopの品質は時間とともに向上する

よく計器化されたvalidation-retryパイプラインはフライホイールになる。observabilityシグナルがプロンプトの改良を駆動し、改良されたプロンプトがretryレートを下げ、下がったretryレートが追加のextractionまたはより徹底的なセマンティックチェックのための予算を解放する。observabilityなしのパイプラインは初期品質で頭打ちになり、そこにとどまる。

やさしい解説: Validation・Retry・Feedback Loop

抽象的なvalidation-retryのメカニズムは、物理的なシステムに基づいた具体的な比喩で直感的になる。設計の全サーフェスをカバーする3つの異なる比喩を紹介する。

Analogy 1: 寿司レストランの大将のチェック

忙しい回転寿司のカウンターで大将がにぎり終わった寿司を客の前に置く前に一瞬だけ確認する様子を想像してほしい。ネタのバランス・シャリの量・ネタの新鮮さ・盛り付け。その確認がvalidationだ。盛り付けが完璧なら客のもとへ（accept）。修正できる欠陥があれば（シャリが多すぎる・ネタが斜めになっている）、具体的な修正と共に握り直す指示を出す：「12番のお客さんはわさび抜きで注文した、ネタをのせ直して。」これがフィールドレベルのretry — 丸ごと捨てるのではなく1つの問題だけを修正する。根本的に問題がある場合（ネタが間違っている・熱すぎる・提供できない状態）は全部握り直す（フル再extraction）。同じ寿司が3回戻ってきても問題が解決しない場合は、大将が板場のベテランを呼んで直接確認させる（人間のレビューへのescalation）。チェックなしに寿司を出すことは、validationなしにextractionをコミットしてサイレントに壊れた抽出をダウンストリームに送ることに相当する。

Analogy 2: 校正者のマークアップ

作者が原稿を校正者に渡す場面を想像してほしい。校正者は赤ペンで読み進める。文法エラーは機械的で確定的だ（スキーマvalidation）— 主語と動詞が一致しない、コンマが欠けている、見出しのフォーマットが間違っている。内容エラーはセマンティックで判断が必要だ（セマンティックvalidation）— 第3段落の引用された事実が第1段落と矛盾している、引用文が間違った人物に帰属している、結論の議論が証拠から導かれていない。校正者は原稿を最初から書き直さない；具体的な問題にマークをつけてメモと一緒に返す：「4ページ、第2段落 — この引用はアインシュタインではなくボーアが言ったものです。修正してください。」そのマークアップが修正retryプロンプト — エラーの説明+問題のある出力+ソースコンテキスト。作者が修正して再提出する。3回のラウンドを経ても問題がある場合、編集長が原稿を取り上げてより上級の作者に割り当てる（escalation）。「出力が悪かった」とだけ言う校正者は役立たずだ。retryプロンプトが特定のフィールドパスと特定のルール違反を含まなければならない理由がこれだ。

Analogy 3: 空港のセキュリティスクリーニング

Extractionパイプラインを空港のセキュリティを通過する荷物として考えてほしい。最初のチェックポイントはX線スキャナー — 特定の形状を探す確定的で自動化されたチェック（スキーマvalidation）。スキャナーが明らかに制限されたアイテムを検出すると、荷物にフラグが立てられる。2番目のチェックポイントは人間のスクリーナーで、荷物を開けて詳細なルールセットに対して内容を確認する（セマンティックvalidation）— 100mlを超える液体・チェックした荷物内のルーズなバッテリー・許可されているように見えるが特定の規制に失敗するアイテム。X線で失敗した荷物は単に再配置して再スキャンが必要かもしれない（修正での即時retry）。修正可能な問題がある荷物（ラップトップを取り出す必要がある）は荷物全体を解体するのではなくターゲットを絞った修正を引き起こす（フィールドレベルの修正）。複数のチェックで連続して失敗する荷物は監督者のレビューのために脇に寄せられる（escalation）。ラインが長いからといって荷物をただ通過させることはない。パイプラインがスループットの目標を達成するために失敗したextractionをacceptするのと同等だ。アーキテクチャは速度よりも重要だ。

どの比喩がどの試験問題に合うか

• retry loopアーキテクチャとaccept-retry-escalateの三状態についての質問 → 寿司レストランの比喩。
• エラー説明の品質とフィールドレベルの修正についての質問 → 校正者のマークアップの比喩。
• スキーマ対セマンティックvalidationの順序と使い果たし時のescalationについての質問 → 空港のセキュリティの比喩。

よくある試験のトラップ

CCA-F Domain 4はvalidationとretryloopに関する5つの繰り返すトラップパターンを悪用する。コミュニティの合格レポートではすべて5つがもっともらしいdistractor の選択肢に偽装されて現れている。

トラップ1：変更されたプロンプトなしのRetry

「extractionを再試行する」とvalidationエラーをretryに含めることを指定せずに提案する答えは間違いだ。Claudeがすでに失敗したのと同じプロンプトをretryすると、ほぼ常に同じ方法で失敗する。修正retryは以前の試行でClaudeが持っていなかった情報を持てるよう特定のvalidationエラーを埋め込まなければならない。

トラップ2：ClaudeがセマンティックValidationを実行すると仮定する

Claudeを自己validationとして扱う答え（「strict tool useがスキーマを強制するのでClaudeが正しい出力を生成する」）はスキーマ準拠とセマンティックな正確さを混同する。Claudeのstrict tool useはスキーマに一致するJSON有効な出力を保証するが、ビジネスルール（合計=明細項目の合計・日付の範囲・IDの存在）はアプリケーションが実装しなければならない。セマンティックvalidationのみをClaudeに委任する答えは間違いだ。

トラップ3：Retryキャップなし

ハードなretryキャップを指定しないvalidation-retryのデザインはベースラインの安全基準に失敗する。無限にretryするパイプラインは単一の病理的なドキュメントでAPIの予算を消費できる。正しいキャップは通常ドキュメントごとに2〜3だ。

トラップ4：プロンプト修正のretryとTransient Backoffを混合する

Exponential backoffは一時的な失敗（レートリミット・ネットワークタイムアウト・5xxレスポンス）の正しい戦略だ。即時retryはプロンプト修正の失敗（validationエラー）の正しい戦略だ。スキーマ違反の前に16秒待機するとクロック時間が無駄になる。レートリミット到達をbackoffなしでretryすると試行が無駄になる。distractor の答えは2つのカテゴリを混合する。

トラップ5：Escalationパスなし

キャップに達したときにサイレントに終了するretryアーキテクチャ（人間のレビューキューなし・アラートなし・ログフックなし）はサイレントなデータ品質の負債を生成する。正しいデザインには常に、ソースドキュメント・すべてのextraction試行・すべてのvalidationエラー・メタデータから組み立てられ、SLAを持つ監視された人間のレビューキューにルーティングされるescalationパケットが含まれる。

実践アンカー

Validation-retryの内容はCCA-Fの6シナリオプールのstructured data extractionシナリオに大きく現れる。以下をシナリオクラスター問題の骨格として扱う。

Structured-Data-ExtractionシナリオCCA-Fで直接問われるタスク4.4

このシナリオでは、パイプラインがドキュメントのストリーム（請求書・契約書・医療記録・構造化フォーム）を取り込み、ダウンストリームシステムのためにデータベース対応のオブジェクトを生成する。validation-retry loopがパイプラインのバックボーンだ。以下をテストする質問を予期する：

• スキーマ対セマンティックvalidationの順序 — 常にスキーマが最初。
• Retryプロンプトの構築 — ジェネリックな「もう一度試して」ではなく特定のエラーを埋め込む。
• フィールドレベル対フル再extraction — 孤立したフィールドの失敗はフィールドレベルの修正；体系的な失敗はフル再extraction。
• Retryキャップとescalation — 2〜3回のretry、その後完全なコンテキストパケットでescalate。
• Retry triggerとしてのconfidence — 低confidenceフィールドでターゲットを絞った再検査。
• is_error: trueのtool_result形状 — extractionがtool useを通じて配線されている場合のvalidation feedbackの機械的なキャリア。

クロスシナリオの適用可能性

Validation-retryパターンはCustomer Support Resolution Agentシナリオ（ルーティング前にextractionされたチケットメタデータをvalidateしなければならない）とMulti-Agent Research Systemシナリオ（coordinatorが消費する前にsubagentの出力をスキーマに対してvalidateしなければならない）にも現れる。どちらの場合でも、同じ5ノードのfeedback loopアーキテクチャが適用される。

Distractor 認識ドリル

シナリオ問題では、以下の赤フラグを探して各オプションを読む：

• 修正プロンプトを指定せずに「extractionを再試行する」。
• アプリケーションレベルのセマンティックチェックなしに「Claudeが出力をvalidateする」。
• キャップでのescalationパスなしに「N回retryする」。
• Validationの失敗で「16秒待機してからretryする」（間違い — これは一時的なretryロジック）。
• エラーが1つのフィールドに名前を付けているのに「すべてのフィールドを再抽出する」（無駄）。

これらのdistractor を排除すると通常、1つの明らかに正しい答えに絞られる。

FAQ — ValidationとRetry Loop上位6問

ValidatioはClaudeの出力の正確さとどう違うか？

Validationはダウンストリームにコミットしても安全かどうかを確認するアプリケーションレベルのチェックだ。Claudeのstrict tool useはスキーマ準拠（構造）を強制できるが、ビジネスルール・クロスフィールドの一貫性・参照整合性・ドメイン範囲の妥当性は強制できない。これらのチェックはvalidationレイヤーにある。Claudeを自己validationとして扱うことはCCA-F Domain 4のトップ5の失敗の1つだ。セマンティックな正確さは常に呼び出し元のアプリケーションの責任だ。

Retryすべきタイミングと人間のレビュアーへのescalateはいつか？

失敗が実行可能な場合にretryする（特定のフィールドが指摘でき・特定のルールが違反され・ソースドキュメントが正しい情報を含んでいる可能性がある）。Retryキャップ（通常ドキュメントごとに2〜3）に達した場合・ソースドキュメントが判読不能または不完全な場合・失敗が追加のClaude呼び出しが修正できない構造的な特性を持つ場合にescalateする。Escalationパケットはすべてのextraction試行とすべてのvalidationエラーを含むべきで、人間のレビュアーに完全なコンテキストを与える。

フィールドレベルの修正とフル再extractionの違いは何か？

フィールドレベルの修正はソースドキュメント+以前の（ほぼ正しい）extraction+特定のフィールドを修正するターゲットを絞った指示を送る。以前に正しかった出力を保存して収束が早い。フル再extractionは以前の出力を破棄してClaudeにextraction全体を再生成させる。孤立したフィールドの失敗にはフィールドレベルの修正を選ぶ；体系的な失敗（ドキュメントの種類が間違っている・クロスフィールドの不一致・ハルシネーション規模のエラー）にはフル再extractionを選ぶ。

試験がvalidationの失敗でbackoffより即時retryを好む理由は何か？

Backoffはプラットフォームレベルの条件（レートリミット・ネットワークタイムアウト）に対処し、失敗がコンテンツの問題の場合に利益がないからだ。Validationの失敗は待機しても解決しない。変更しなければならない変数はプロンプトだ。Exponential backoffは一時的な失敗のretryパス（transientとカテゴリされたtoolエラー）に属し；変更されたプロンプトでの即時retryはコンテンツのretryパス（スキーマまたはセマンティックの失敗）に属する。

修正retryプロンプトをどう構造化するか？

3つのコンポーネントを組み立てる：(1) 元のextraction対象（ソースドキュメントまたは関連スライス）、(2) 以前の壊れたextraction、(3) JSONパスで失敗したフィールドに名前を付け・自然言語で違反したルールを述べ・期待される修正を示唆する構造化エラーの説明。ExtractionがStrict tool useを通じて配線されている場合、is_error: trueでtool_resultとしてエラーをパッケージする。「出力が間違っていた」のような曖昧なエラーの説明を避ける。Claudeは見つけられないものを修正できない。

ValidationとRetryの決定においてconfidenceスコアはどんな役割を果たすか？

フィールドレベルのconfidenceスコアはClaudeが各抽出された値とともに出力する自己報告シグナルだ。Validationの優先順位付け・低confidenceフィールドでのターゲットを絞ったretryのtrigger・スキーマとセマンティックチェックが通過しても人間のレビューのためのflaggingに使用される。Confidenceスコアは較正された確率ではない。相対的な優先順位付けツールとして扱う。すべてのvalidationを通過しても低confidenceを報告するフィールドは依然として2番目の確認に値する。高confidenceを報告しながらvalidationに失敗するフィールドはClaudeが自信を持って間違っていたことを示す。プロンプト基準またはvalidationルールを引き締めるサインだ。

参考資料

• Handle tool calls — tool_result format and error responses: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Strict tool use — schema-guaranteed output: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/strict-tool-use
• Increase output consistency — structured outputs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Building effective agents — agentic loop reference: https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop
• Tool use with Claude — overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview

関連するExamLabのトピック：Structured Output via Tool Use and JSON Schemas、Explicit Criteria Prompt Design、Iterative Refinement and Progressive Improvement、Error Propagation in Multi-Agent Systems。