【ITニュース解説】To Retry or Not to Retry? That Is the Question.

システム開発では、複数のプログラムやサービスが互いに情報をやり取りしながら連携して動作することが一般的だ。この情報交換の窓口となるのが「API」であり、例えばオンラインショップでの注文処理では、商品情報システム、決済システム、配送システムなどがAPIを通じて連携している。しかし、これらのシステムは常にスムーズに動くわけではなく、ネットワークの一時的な不安定さや、連携先のサーバーに負荷が集中するといった理由で、一時的に通信エラーが発生することがある。

このような一時的な障害が発生した場合、すぐに処理を諦めてしまうと、ユーザーが不便を感じたり、ビジネスチャンスを失ったりする可能性がある。そこで、「リトライ（再試行）」という仕組みが重要となる。エラーが起きても、少し時間を置いてからもう一度同じ処理を試みることで、一時的な問題が解消されていれば、処理を成功させることができるのだ。しかし、リトライは万能な解決策ではない。例えば、新しい情報をサーバーに送信するリクエスト（決済処理など）を、安易にリトライしてしまうと、意図せず同じ処理が二重に行われ、二重課金といった問題を引き起こす可能性がある。また、システムにさらに負荷をかけてしまうリスクもある。そのため、システムエンジニアは「いつ、どのようにリトライすべきか」という複雑な判断を慎重に行う必要がある。

今回の実験は、AIモデルがこの「リトライすべきか、すべきでないか」という判断を、どれだけ正確にこなせるかを検証したものだ。AIによるコード生成が普及する現代において、AIがAPIのエラーに対して適切なリトライポリシー（再試行の方針）を提案できるかどうかは、非常に重要な意味を持つ。この実験の目的は、AIが単にHTTPステータスコード（サーバーからの応答を示す数字コード）といった表面的な情報だけでなく、リクエストの内容や、その時の状況といった「文脈」全体を理解した上で、適切なリトライの判断ができるかを測定することにあった。

リトライ判断の難しさは、HTTPステータスコードだけでは十分な情報が得られない点にある。例えば、「503 Service Unavailable」（サービス一時停止）というステータスコードは、サーバーが一時的に応答できない状態にあることを示すが、この情報だけでリトライが安全であるとは限らない。もし、このエラーが、新しい支払いを作成する「POST /payments」のようなリクエストで発生し、さらに「冪等性キー（idempotency key）」という、同じリクエストを何度送っても結果が一度しか反映されないことを保証する仕組みが利用されていない場合、リトライは二重決済につながる恐れがある。また、通信のタイムアウトが発生した場合も、サーバーが処理を始める前に接続が切れたのか、それとも処理は完了したが応答が届かなかったのかによって、リトライの安全性が全く変わってくるのだ。

実験では、APIのリクエスト内容、サーバーからのレスポンス、そして「冪等性キーが提供されている」といった追加の状況情報を含む、様々なAPI障害シナリオが用意された。AIモデルには、それぞれのシナリオに対して、「YES（直ちにリトライすべき）」「NO（リトライすべきでない）」「YES_AFTER_DELAY（遅延後にリトライすべき）」のいずれかの判断と、その理由を1文で答えることが求められた。採点では、AIモデルの判断が正しいかどうかが評価され、理由はその判断過程を理解するための参考にされた。例えば、冪等性キーによって重複処理が確実に防げる決済リクエストが「503 Service Unavailable」で失敗した場合、人間であれば「YES_AFTER_DELAY」と判断するだろう。AIモデルが、こうした複雑な情報から適切な判断を導き出せるかが試されたのである。

用意されたシナリオは全部で14種類あり、決済、データの更新、リソースの削除など、現実のシステム運用で遭遇しうる多様な状況を想定していた。具体的なシナリオとしては、冪等性キーがある場合の安全な決済リトライ、冪等性キーがない場合の危険な決済リトライ、処理が集中してリクエストが制限される「レートリミット」のケース、サーバーが一時的に利用できない「503 Service Unavailable」のケースなどが含まれた。

この実験で比較されたAIモデルは、GPT-5.6 Sol、Gemini 3.7 Flash、Claude Sonnet 5など、現在広く利用されている大規模言語モデルの複数種類であった。これらのモデルは、実際の開発現場でAIを活用したコーディング支援ツールとして使われることを想定して選ばれたものだ。

実験の結果、GPT-5.6 Solが最高の成績を収め、ほとんどのシナリオで正しい判断を下した。しかし、多くのAIモデルが共通して間違えたシナリオも存在した。それが「Unsafe Payment Retry（安全でない決済リトライ）」のケースである。このシナリオでは、「503 Service Unavailable」というエラーとともに、「Retry-After」という「指定された時間後にリトライしてください」という指示ヘッダーが返された。しかし、この決済リクエストには冪等性キーがなかったため、リトライすると重複課金が発生するリスクがあった。ほとんどのAIモデルは、「Retry-After」という明確なHTTPヘッダーの指示に従い、「YES_AFTER_DELAY」と判断してしまった。これは、AIがHTTPの指示を優先しすぎ、重複課金というビジネス上のリスクを含むより広い文脈を十分に考慮できなかったことを示唆している。

また、PUTやDELETEのように、何度実行しても結果が変わらない性質を持つ「冪等なHTTPメソッド」に関するシナリオでも、AIモデルの判断が「YES」と「YES_AFTER_DELAY」の間で分かれることがあった。これは、リトライ自体は安全であるとAIが理解しているものの、最適なリトライのタイミングについては、人間とは異なる解釈をする場合があることを示している。この発見は、ベンチマークを今後改善していく上での重要な示唆とされた。

さらに、実験は1回だけでなく、合計3回実行され、AIモデルの判断の安定性も確認された。ほとんどのモデルは同じシナリオに対して一貫した結果を示したが、一部のモデルでは、同じ総合スコアであっても、どのシナリオで間違ったかが実行ごとに異なる場合があった。これは、AIの判断が常に固定されているわけではない可能性を示唆している。

モデルの効率性、すなわち利用コストについても分析が行われた。GPT-5.6 Lunaは、比較的低いコストで高いパフォーマンスを発揮し、最も効率的なモデルと評価された。一方でDeepSeek-R1というモデルは、簡潔な回答が求められていたにもかかわらず、他のモデルよりもはるかに長い文章で回答したため、結果として利用コストが大幅に高くなることが判明した。これは、AIモデルの性能だけでなく、与えられた指示（出力フォーマットなど）をどれだけ正確に守れるかが、実際の運用コストに大きく影響する重要な要素であることを示している。

この実験から得られた最も重要な教訓は、AIモデルがAPIリトライのような複雑な意思決定において非常に有用なツールである一方で、まだ完璧ではないという点だ。特に、HTTPステータスコードのような単一の明確な情報だけでなく、ビジネス上のリスクやシステム全体の挙動といった、より広い文脈を総合的に判断する必要がある場合、AIは間違いを犯す可能性がある。システムエンジニアがAIアシストツールを利用する際には、AIの提案を盲目的に受け入れるのではなく、その背景にあるリスクや文脈を人間が最終的に確認し、適切な判断を下すことの重要性が再確認された。AIは強力なツールだが、それを適切に使いこなすためには、人間の深い理解と判断が不可欠なのである。