AIに外部API連携の設計を相談するチェックリスト

時間切れ（タイムアウト）：

• 接続と読み取りのタイムアウトが、コードに数字として書かれているか
• 使っているクライアントの初期値を、公式ドキュメントで確認したか
• 呼び出しが入れ子になっている場合、内側のほうが短くなっているか
• 利用者が待っている処理か、待っていない処理かで秒数を分けたか
• タイムアウトした事実がログに残るか

やり直し（リトライ）：

• やり直してよい操作か、増えてしまう操作かを仕分けたか
• 増えてしまう操作に、冪等キーなど二重防止の仕組みがあるか確認したか
• 回数の上限が決まっているか（無制限になっていないか）
• 間隔が少しずつ広がる形になっているか（等間隔の連打になっていないか）
• 再送のタイミングをばらけさせる工夫（ジッター）が入っているか
• 429のときに Retry-After の指定に従っているか
• 400番台の「こちらの間違い」を、やり直し対象から外してあるか

遮断：

• 失敗が続いたときに呼ぶのをやめる仕組みがあるか
• 遮断を解除する条件（何秒後に1本試すか）が決まっているか
• 遮断中であることが、ログや監視で分かるか
• この連携が詰まっても、他の機能まで巻き込まれない作りになっているか

代替（フォールバック）：

• 落ちたときに利用者へ見せる内容が決まっているか
• 古いデータを見せる場合、いつ時点かを画面に添えているか
• 受け付けだけ先に済ませる場合、あとで処理する経路があるか
• 「止める」を選んだ場合、その判断を業務側と合意しているか

相手の仕様の確認：

• レート制限の値を仕様書で確認したか
• エラー時に返る形式（本文・コード体系）を確認したか
• 認証情報の有効期限と、切れたときの再取得の流れを確認したか
• サンドボックス（試験環境）で、わざと失敗させて動きを見たか
• 相手の障害情報をどこで知るか（ステータスページ等）を控えたか

AIへの渡し方：

• 相手の制約・こちらの制約・落ちたときの方針を前提として渡したか
• 「選択肢とトレードオフ」の形で出させたか
• AIが出した秒数・回数を、そのまま採用していないか
• 業務判断が必要な箇所を、業務側と話したか