# 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エージェント# #ソフトウェアアーキテクチャ#