コーディング エージェントが記述したエラー処理を確認する方法

コーディング エージェントによると、再試行機能とレート制限の処理が追加され、テストも合格しています。 それを信頼する前に、テストが何を対象に実行されたか確認してください。

3 つのコーディング エージェントを対象に実施したテスト (210 回の実行) では、API のエラーに対処するアプリを作成し、それが正常に動作することを実証するよう依頼しました。 動作するコードが求められた 140 回の実行のうち、76％ において、エージェントは fetch スタブ httpx.MockTransport や使い捨ての HTTP サーバーを使用して、手動で失敗を再現しました。 実際の API が利用可能であり、プロンプトでもその使用が除外されていなかった 75 回の実行のうち、実際の API URL でアプリをテストしたのは 0 回でした。 このようなテストに合格することは、エージェントのコードが、エージェントが想定したエラーに対処できることを証明できます。 これは、API が返すエラーとは別のエラーです。

Checklist

  1. どのような基準でテストされたのか尋ねてください。 エージェントに「テスト中にアプリはどの URL を呼び出し、何がエラーを返したのですか？」と尋ねてください。答えがスタブや、エージェントが作成したローカル サーバーである場合は、そのテストを、エージェントが追加したブランチの単体テストとして扱ってください。
  2. テスト用に追加されたスイッチを探します。 差分内で新しい環境変数、ベース URL 設定、またはフラグを検索します。 私たちのテストでは、GitHub、OpenAI、または天気 API を呼び出すアプリの実行 105 回中、61 回で 1 が加算されました。 運用環境にするかどうかを決定します。
  3. API の文書化された動作に照らしてコードを確認します。 各 API は、それぞれ異なる形で失敗します:
    • GitHub: プライマリ レート制限を超えると、x-ratelimit-remaining が返され、0 が に設定されます。その後、x-ratelimit-reset の時刻 (UTC エポック秒) まで待機します。 セカンダリ レート制限については、retry-after が存在する場合はそれを待機し、存在しない場合は x-ratelimit-remaining が 0 である場合に限り x-ratelimit-reset まで待機し、それ以外の場合は少なくとも 1 分間待機します。 429 のみをチェックするコードでは、403 が見落とされます。
    • OpenAI: 429 エラーの中には、credit_balance_exhaustedのように、請求や使用限度に関するものもあります。 それらを再試行しても役に立ちません。 429 エラーが発生するたびに再試行するコードは、その問題をユーザーから隠してしまいます。
    • Anthropic: 支出上限 (429) には retry-after ヘッダーがなく、オーバーロードでは 529 が返されます。標準の状態コードしか知らないコードでは、これを予期しない可能性があります。
  4. Retry-After がどう読めるか確認します。 ヘッダーは、秒数または HTTP 日付 (RFC 9110) を保持します。 コードが、API から送信されるフォーマットに対応していること、試行回数と合計待機時間に上限を設けていること、そしてすでに再試行機能を持つ SDK の上で再試行を行わないことを確認します。
  5. 再試行が実行されたときにユーザーに表示される内容を確認します。 スタック トレースや無限のスピナーではなく、明確なメッセージを探し、ユーザーが作業を失っていないことを確認します。
  6. 実際の URL でアプリを実行し、エラーをシミュレートします。 これは、実行中のアプリ、SDK、および再試行ポリシーがどのように動作するかを示す唯一の手順です。

エージェントが記述したエラー処理を確認する方法

Approach 見つけたもの 欠落しているもの
差分を読む コードが正しく見えるかどうか API の実際の応答に対して正しく動作するかどうか
エージェントのテストを実行する 書き込んだブランチが実行されること スタブが再現しなかったもの (実際の状態コード、ヘッダー、エラー本文、SDK の再試行)
失敗するまで実際の API を呼び出す 実際の挙動 必要に応じてエラーを発生させることはできず、実際のクオータを消費することになります
実際の URL でアプリを実行し、エラーをシミュレートします 実行中のアプリ、SDK、および再試行ポリシーが API 独自のエラーを処理する方法 お使いのコードは孤立しています。 その点については、エージェントのユニット テストを保持します。

アプリで試す

Dev Proxy は、アプリが実際の API に送信する要求を傍受し、アプリのコードを変更することなく、指定したエラーを返します。 よく使われる API の場合は、プリセットから始めます。 エージェントが実装した GitHub のレート制限処理を確認する方法:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

アプリを実行し、Dev Proxy の出力を確認します。 プリセットは、アプリが制限を超えると、GitHubのレート制限ヘッダーを含む 429 を返します。 プリセットに含まれる RetryAfterPlugin は、待機時間が経過する前にアプリが API を再度呼び出した場合に、そのことを通知します。 openai-throttling と anthropic-throttling のプリセットは、プロバイダ独自のレート制限エラーに対しても同様の処理を行い、openai-throttling はさらに、再試行すべきではない credit_balance_exhausted 429 エラーも返します。

その他の API の場合:

また、開発プロキシ構成を記述するようにコーディング エージェントに依頼することもできます。 Dev Proxy MCP サーバー をエージェントに追加して、Dev Proxy のドキュメントとベスト プラクティスを調べて、インストールしたバージョンを確認できるようにします。 その構成については、エージェントが記述する他のコードと同様にレビューが必要です。

開発プロキシをインストールするには、「 開発プロキシの設定」を参照してください。

次のステップ

ランダム エラーでアプリをテストする

参照

  • 最終更新: