自己修正リトライ

このダイヤルは何か

自己修正リトライは、LLMの出力がスキーマに違反したり品質が不十分だったりした場合に、エラー内容をコンテキストに追加して再生成を試みる回数を制御するダイヤルです。ネットワークリトライ（同じリクエストをそのまま再送する）とは本質的に異なります。自己修正リトライでは「何が間違っていたか」をLLMにフィードバックすることで、次の生成で正しい出力を得ることを期待します。

AIエージェントシステムにおいて、LLMの出力は確率的（F3）であり、スキーマに従わないことがある（F10）という本質的な特性を持ちます。JSON Schemaへの違反、ビジネスルールに反する値の生成、不完全な応答などが日常的に発生します。これらのエラーに対して「同じプロンプトをそのまま再送」しても直る保証はありません。エラーの内容を具体的にフィードバックすることで、LLMが自らの出力を修正できる可能性があります。

ただし自己修正リトライには明確な収穫逓減があります。多くの経験則から、3回目以降のリトライでは改善がほとんど見られないことが知られています。同じ種類のエラーを繰り返す場合、プロンプトの設計やスキーマの定義そのものに問題がある可能性が高く、リトライで解決できる範囲を超えています。

効かなすぎる害 ⇔ 効きすぎる害

効かなすぎる害（リトライ回数が少なすぎる/リトライしない）

自己修正リトライを行わないと、修正可能なエラーでも即座に失敗として扱われます。

• JSONの閉じ括弧が1つ足りないだけの出力を捨ててしまい、「スキーマ違反のため処理失敗」とユーザーに返します。フィードバックを与えれば次の生成でほぼ確実に修正されるケースです
• 数値の範囲が微妙に逸脱している出力（例：割合が103%）を即棄却します。エラー内容を伝えれば次回は正しい範囲に収まることが多いです
• 1回の生成で偶発的に低品質な出力が返った場合、再試行すれば高品質な出力が得られる可能性を放棄してしまいます

効きすぎる害（リトライ回数が多すぎる）

自己修正リトライを過剰に行うと、コストとレイテンシが急膨張します。

• 同じ誤りの反復 — LLMが根本的に解けない問題（プロンプトの曖昧さ、スキーマの過剰な制約、知識の欠如）に対して何度も挑戦し、毎回同じ種類のエラーを繰り返します
• レイテンシ爆発 — 1回のLLM呼び出しが30秒かかるとすると、5回リトライすれば2.5分以上待たせることになります
• コンテキスト肥大 — リトライのたびにエラーメッセージをコンテキストに追加するため、トークン消費が累積的に増大します。最悪の場合、コンテキスト長超過（③のエラー）に遷移し、さらに別の問題が発生します
• コスト増幅 — 自己修正リトライでは毎回全コンテキストを再送するため、リトライ1回あたりのコストがネットワークリトライより大きくなります

決め方

このダイヤルは主に [failure_cost] で決めます。出力のエラーが下流にどれだけの損害を与えるかに応じて、何回まで修正を試みるかを調整します。

エラーの種類で判断する

すべてのエラーに同じリトライ回数を適用するのは非効率です。エラーの修正容易度に応じて対応を分けます。

• 構文レベルのエラー（JSON構文不正、型の不一致）— 1回のフィードバックでほぼ直ります。リトライ1回で十分です
• 意味レベルのエラー（値の範囲逸脱、存在しないIDの参照）— フィードバックで改善する可能性がありますが、2回目で直らなければ構造的な問題です
• 品質レベルのエラー（不完全な回答、要求された情報の欠落）— 主観的で改善が読みにくいため、リトライよりもプロンプト改善に投資すべきです

リトライ予算との整合

自己修正リトライはA6のリトライ予算全体の一部として管理します。ネットワークリトライと自己修正リトライの予算は別枠で設定し、合計がセッション全体の予算（A7）を超えないようにします。[cost_sensitivity] が高い場合は、自己修正リトライに充てるトークン予算を総予算の概ね20〜30%に制限します。

目安値（出発点）

シナリオ	リトライ回数	補足
一般的なケース	1〜3回	2回目で改善しなければ構造的問題の可能性が高い
構造化出力（JSONスキーマ）	1〜2回	response_format を使えば初回成功率が高い
高 [failure_cost] 領域	2〜3回	金銭・法務・医療など。ただし品質が上がらなければ人間エスカレーション
低 [failure_cost] 領域	0〜1回	失敗してもフォールバックで対応できるなら即諦める方が効率的

リトライ上限に達した場合の振る舞いとして、安全なフォールバック（デフォルト値の返却、人間へのエスカレーション、部分結果の返却）を事前に設計しておきます。

具体的なシナリオ

シナリオ1：JSON出力のスキーマ違反

LLMに構造化出力（JSON）を要求したが、返された出力にフィールドの欠落や型の不一致がある場合です。

たとえば、注文情報を抽出するプロンプトで product_id フィールドが PRD- プレフィックス付きの文字列であることを期待しているのに、LLMが数値で返してしまうケースです。

推奨される対処：

• エラーメッセージ：「product_id フィールドは PRD- で始まる文字列（例：PRD-001234）である必要がありますが、数値 1234 が返されました。正しい形式で再出力してください」
• リトライ1回でほぼ確実に修正されます
• response_format（Structured Outputs）を使えば初回から構文レベルのエラーは排除できるため、この種のリトライ自体が不要になります

シナリオ2：ビジネスルール違反

フォーマットは正しいが、値がビジネスルールに反している場合です。たとえば「配送日が過去の日付」「存在しない商品ID」「合計金額が負の値」などです。

推奨される対処：

• エラーメッセージ：「delivery_date は未来の日付でなければなりませんが、2024-01-15（過去の日付）が返されました。今日は2026-05-29です。明日以降の日付を指定してください」
• 具体的な制約と現在の状態を含めたフィードバックが重要です
• 2回のリトライで改善しなければ、LLMがこの制約を理解できていない可能性が高いため、プロンプトの改善が必要です

シナリオ3：品質不足（情報の欠落・不完全な回答）

回答がスキーマには適合しているが、要求された情報が不完全な場合です。たとえば「5つの観点から分析してください」に対して3つしか返ってこない場合です。

推奨される対処：

• エラーメッセージ：「5つの観点からの分析を求めましたが、3つしか含まれていません。残りの2つの観点（セキュリティ、パフォーマンス）も含めて再出力してください」
• 品質レベルのエラーは自己修正で改善する確率が低いです。1回リトライして改善しなければ、部分結果を受け入れるか、プロンプトを分割して個別に生成する方が効果的です

シナリオ4：繰り返し同じエラーが出る場合

2回連続で同じ種類のエラー（たとえば同じフィールドのスキーマ違反）が出た場合、3回目を試みても改善する見込みは低いです。この時点で以下の選択肢を検討します。

• 温度を下げて再試行する（構造化出力の従順率が上がる可能性）
• プロンプトを簡素化する（スキーマのフィールド数を減らし、段階的に生成する）
• 別のモデルで試行する（B7 モデル段階化）
• 人間にエスカレーションする

実践的なアドバイス

• エラーメッセージは短く、具体的にしてください。「出力が不正です」ではなく「delivery_dateフィールドが過去の日付です。未来の日付を指定してください」のように、何が間違っていて何が期待されるかを明示します。ただしエラーメッセージ自体がトークンを消費するため、概ね200トークン以内に収めます。

• 2回連続で同じ種類のエラーが出たら、3回目を試すよりプロンプトを疑ってください。同じエラーの反復は、LLMがそのプロンプトとスキーマの組み合わせで正しい出力を生成する能力を持っていない可能性を示しています。リトライ回数を増やすのではなく、プロンプトの改善やスキーマの簡素化に投資すべきです。

• 自己修正リトライとネットワークリトライを混同しないでください。429や5xxは自己修正リトライの対象ではありません。逆に、スキーマ不適合はネットワークリトライで直る問題ではありません。エラー分類を最初に行い、適切なリトライ戦略に振り分けます。

• response_format（構造化出力機能）を活用すると、自己修正リトライの必要性が大幅に減ります。OpenAIのStructured OutputsやAnthropicのtool useなど、APIレベルでスキーマ準拠を強制する機能を使えば、構文レベルのエラーはほぼゼロになります。

• リトライ時のコンテキスト管理に注意してください。毎回のエラーメッセージを全部コンテキストに積み続けると、トークン消費が膨張し、最終的にコンテキスト長超過という別のエラーに遷移します。直前のエラーだけを残すか、エラー要約を使うことを推奨します。

関連パターン

• E4 検証済み構造化出力 — 自己修正リトライの最も一般的な適用先です。スキーマ検証＋ビジネスルール検証の二段構えと、リトライ予算内での収束を詳述しています。
• A6 適応タイムアウト＋予算律速リトライ — エラー分類（一時障害/コンテンツ起因/コンテキスト超過）と、種類に応じた戦略の切り替えを定義しています。
• B6 Critic/Judge サンプリング — 自己修正リトライの代替として、複数候補の生成＋判定（Best-of-N）を検討できます。修正よりも「多数試行して最良を選ぶ」方が効果的な場合があります。
• E3 入出力ガードレール — 出力ガードレールで検出されたエラーが自己修正リトライのトリガーになります。