# AIエージェント開発の意思決定ポイント # 自己修正リトライ｜Self-Correction Retry 🎯 ポイント LLMの出力が壊れた時、「もう一回！」と同じプロンプトを投げ直していませんか？ 自己修正リトライは「何が間違っていたか」をLLMにフィードバックして再生成させる仕組みです。ただし闇雲に回数を増やしても改善しません。3回目以降のリトライで品質が上がることは、ほとんどありません。 📋 概要 自己修正リトライは、LLMの出力がスキーマ違反や品質不足だった場合に、エラー内容をコンテキストに追加して再生成を試みる回数を制御するダイヤルです。ネットワークリトライ（同じリクエストをそのまま再送）とは本質的に異なります。「何が間違っていたか」を具体的にフィードバックすることで、次の生成で正しい出力を得ることを期待します。LLMの出力は確率的であり、JSONの閉じ括弧が足りない、値の範囲が逸脱しているといったエラーは日常的に発生します。こうしたエラーへの対処戦略として、自己修正リトライは非常に実用的です。 🔍 意思決定のポイント 最大の判断基準は「出力のエラーが下流にどれだけの損害を与えるか」（failure_cost）です。すべてのエラーに同じリトライ回数を適用するのは非効率なので、エラーの種類に応じて対応を分けるのが鉄則です。 構文レベルのエラー（JSON構文不正、型の不一致）はフィードバック1回でほぼ直ります。意味レベルのエラー（値の範囲逸脱、存在しないIDの参照）は2回目で直らなければ構造的な問題です。品質レベルのエラー（不完全な回答、情報の欠落）は主観的で改善が読みにくいため、リトライよりプロンプト改善に投資すべきです。 💡 要点と詳細 目安値として覚えておくと便利です 📊 - 一般的なケース → 1〜3回。2回目で改善しなければ構造的問題の可能性大 - 構造化出力（JSONスキーマ） → 1〜2回。response_formatを使えば初回成功率が高い - 高failure_cost領域（金銭・法務・医療） → 2〜3回。品質が上がらなければ人間エスカレーション - 低failure_cost領域 → 0〜1回。フォールバックで対応できるなら即諦める方が効率的 エラーメッセージは短く具体的に 🎯 「出力が不正です」ではなく「delivery_dateフィールドが過去の日付です。未来の日付を指定してください」のように、何が間違っていて何が期待されるかを明示します。ただしエラーメッセージ自体がトークンを消費するため、概ね200トークン以内に収めましょう。 ⚖️ トレードオフ リトライしなさすぎると、修正可能なエラーでも即失敗として扱われます。JSONの閉じ括弧が1つ足りないだけの出力を捨ててしまうのは、もったいないですよね。 一方でリトライしすぎると、コストとレイテンシが急膨張します ⚡ 1回のLLM呼び出しが30秒なら、5回リトライで2.5分以上。リトライのたびにエラーメッセージをコンテキストに追加するためトークン消費が累積的に増大し、最悪の場合コンテキスト長超過という別の問題に遷移します。 2回連続で同じ種類のエラーが出たら、3回目を試すよりプロンプトを疑ってください。同じエラーの反復は、LLMがそのプロンプトとスキーマの組み合わせで正しい出力を生成できないことを示しています。 🛠️ ユースケース JSON出力のスキーマ違反 → エラー内容を具体的にフィードバックし、リトライ1回でほぼ修正可能。response_format（Structured Outputs）を使えばこの種のリトライ自体が不要に。 ビジネスルール違反（配送日が過去の日付など） → 具体的な制約と現在の状態を含めたフィードバックが重要。2回で改善しなければプロンプト改善へ。 品質不足（「5つの観点から分析」に3つしか返らない） → 1回リトライして改善しなければ、部分結果を受け入れるかプロンプト分割の方が効果的。 繰り返し同じエラーが出る場合 → 温度を下げる、プロンプトを簡素化する、別のモデルで試行する、人間にエスカレーションするなどの代替手段を検討 🔄 #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェントをソフトウェアに組み込むプラクティス # Adaptive Timeout & Budget-Bounded Retry｜適応タイムアウト＋予算律速リトライ 🎯 リトライ3回で固定していませんか？LLMリトライ1回で数千トークン消費する世界では、回数でなく予算で律速すべきです。 固定タイムアウト・固定回数リトライは、エージェント時代のエラー処理には力不足です。 🔥 解決する課題 エージェント実行ではツール呼び出し（数秒）とLLM推論（数十秒〜分）でレイテンシ特性が全く異なります。同じタイムアウトで括ると、前者は待ちすぎ・後者は早すぎで切れます。さらに固定3回リトライでも、LLMリトライは1回あたり数千トークンを消費して予算を突き破りえます。429（レート制限）とスキーマ不適合を同じリトライで処理しても、後者は同じプロンプトでは直りません。 💡 提案パターン Adaptive Timeout & Budget-Bounded Retry（適応タイムアウト＋予算律速リトライ）は、操作クラス（ツール呼び出し・LLM推論・セッション全体）ごとにタイムアウトを分けます。リトライは固定回数でなく残りトークン予算で打ち切ります。エラーを一時障害・コンテンツ起因・コンテキスト長超過の3種に分類し、それぞれ指数バックオフ・self-correction・要約分割と対応戦略を切り替えます。予算を一定割合消費したら縮退（軽量モデルへのフォールバック）に移行し、尽きたらfail-fastで停止します。 ✅ 選定条件 使うとき： - LLM・ツール・外部APIなどレイテンシ特性の異なる操作を組み合わせている - リトライ1回あたりのコストが無視できない（LLM推論を含む） - ネットワーク一時障害とコンテンツ起因エラーの両方が発生しうる 使わないとき： - 単発LLM呼び出しのみで固定タイムアウトで十分な場合 - 非冪等な書込のみでリトライ自体が禁止される環境 ⚠️ 落とし穴 - 429応答のRetry-Afterヘッダを無視して自前バックオフだけで攻めると、プロバイダ側でさらに絞られます。必ずRetry-Afterを尊重してください - 非冪等書込のリトライには冪等キーが必須です。冪等キー無しのリトライは二重実行を招きます - self-correctionでエラー文をそのまま詰めすぎるとコンテキストが膨張してコンテキスト長超過に遷移します。エラー要約は200トークン以内に切り詰めましょう 🔧 実装方針 - タイムアウトを操作クラス別に定義します。ツール呼び出しは概ね10〜30秒、LLM推論は全体60〜120秒（ストリーミング時はトークン間5〜15秒）、セッション全体はdeadlineで律速します - エラーを3種に分類し、一時障害（429/5xx/timeout）は指数バックオフ＋ジッタで再送、コンテンツ起因（スキーマ不適合等）はエラー要約をコンテキストに追加してself-correction、コンテキスト長超過は要約・分割で対処します - リトライ上限は固定回数でなく残りトークン予算で判定します。一時障害は予算の90%まで、self-correctionは70%までを上限とします - プロバイダごとに独立したサーキットブレーカ（Closed/Open/Half-Open）を設置し、連続失敗が閾値に達したら遮断して縮退ラダー（軽量モデル→キャッシュ応答→静的フォールバック→fail-fast）を降ります - 全プロバイダが共通インターフェースを実装するプロバイダ抽象化層を設け、フォールバック先の切り替えを呼び出し元に対して透過的にします #AIエージェント# #ソフトウェアアーキテクチャ#