404の後にも受信記録は残り得る。AIエージェントの再試行前に確認すること
受信本文を記録したあとにHTTP 404を返す合成実験と、SQLiteへの書き込み後に応答を失う2ケースを比べます。読み戻しの確認と再実行の権限を分ける判断を説明します。
AIエージェントが外部APIを呼び、エラーを受け取りました。もう一度呼べばよいのでしょうか。ARC（Agent Role Contracts）の周辺実験では、答えを急ぐ危険を具体的に確認できました。HTTP 404が返っても、受け手がリクエスト本文を記録済みだったケースがあります。別の実験では、データベースへの書き込み完了後に応答だけを失わせました。同じ「返事が届かなかった」状態でも、結果を読み戻せるかどうかで、次に取れる行動が変わります。
再実行条件の設計経緯はARCで見直した3つの条件で、契約から停止・復旧までの全体像はAIにどこまで任せるかで扱っています。この記事は、二つの合成実験の観測結果と、応答を失った2ケースの比較に絞ります。
HTTP 404の前に、受信側で起きていたこと
2026年10月28日（UTC）に統合したARC PR #92のローカル実験では、受け手が架空データのリクエスト本文を記録したあと、故意にHTTP 404を返しました。観測できたのは受信側で本文が記録されたことです。業務チケットの作成完了や、遠隔システムでの永続的なビジネス処理を立証した実験ではありません。それでも「404だから何も起きていない」という推論への反例にはなります。
この実験のきっかけは、ARC Issue #69に記録した外部の自己申告です。コメント投稿APIが404を返した一方、スレッドを読み直すとコメントが存在した、という内容でした。投稿者名の照合は別の確認であり、不明のまま残っています。私たちはその外部サービスを独立に再現していません。
同じ1件の書き込み、異なる判定
2026年11月7日（UTC）に統合したPR #118のSQLite合成実験は、Python標準ライブラリだけで一時SQLiteデータベースを作ります。公開された6ケースのうち2ケースが、書き込みのコミット後に応答が失われる状況を再現しています。
| ケース | アプリケーションの判定 | 別の読み取り専用接続から見える記録 |
|---|---|---|
response_lost | READBACK_CONFIRMED | コミット済みの操作1件 |
reader_unavailable | HOLD_UNKNOWN | コミット済みの操作1件 |
どちらのケースでも、テスト用の観測者にはコミット済みの1件が見えます。違いは、アプリケーション自身が読み戻しを利用できるかどうかです。後者の UNKNOWN は「書き込みゼロ」という意味を持ちません。
再現するには、リポジトリのルートで次の1コマンドを実行します。
python3 experiments/cross-tool-effects/sqlite-readback/reproduce.py公開された期待結果の最終行は 6/6 matched; network=0; resend=0 です。後ろの二つの値は、ネットワーク操作も再送も実行しないという合成実験の構成を表す固定値です。リモートAPIでの厳密な一度きりの実行を証明した数字ではありません。
再試行の判断を二つに分ける
最初に確かめるのは前回の副作用が起きたかで、次に確かめるのがいま再実行してよいかです。読み戻しに成功したことを、再送の許可として扱うことはできません。エラーの後に別のエージェントへ引き継ぐ場合も、引き継ぎ先のIDや権限が正しいことだけでは、前回の実行結果は確定しません。応答が届かなかったという理由だけで新しい操作IDを発行すると、同じ効果が重なるおそれがあります。
この二つの実験を踏まえて私たちが提案する確認の順番は、次のとおりです。
- 元の論理操作IDと要求を保持する
- 受信側の権威ある記録を照合する
- 不確実な結果は
UNKNOWNと記録する - 再実行する場合は、その時点の権限と受信側の重複防止契約を別に確認する
この順番の背景にある設計条件は、ARCで見直した3つの条件の条件3にまとめています。
適用範囲には限りがあります。今回のSQLite実験は単一プロセス内でアプリケーションと観測者が読み取り関数を共有し、読み戻し不能はフラグで再現しています。クラッシュ復旧、実サービス、認証情報の分離、OSレベルの隔離、重複操作の分岐、ネットワーク越しの再試行は検査していません。ARCのモジュールも呼び出していません。ARCが扱うのは、役割、権限、範囲、レビューの分離、引き継ぎといった宣言どうしの整合性です。APIの副作用の強制や受信側での事実確認は、それを実行するシステムの責任として残ります。
自社のエージェントに当てはめるなら
状態を変更するAPI呼び出しを一つ選び、タイムアウト直後に何が起きるかを確認してください。受信側で操作IDを検索できますか。コマンドを再送せずに、権威ある結果を取得できますか。読み戻しが使えないとき、不確実な状態を保てますか。引き継いだエージェントが新しい操作IDを作り、二重に実行する余地はありませんか。
実際のシステムでは、操作IDの検索と独立したデータの読み戻しのどちらを採用しているでしょうか。ARC Issue #120の議論で、再実行の判断に使う最小の証拠を募集しています。既存の冪等キーや永続ワークフローですでに解決できている例も歓迎します。
出典と開示： PR #92／PR #118・公開手順と制限／Issue #69の外部報告記録。ARCはNetsujoが開発するOSSです。本文の作成にはAIによる編集支援を利用しました。検証範囲は本文に明記しています。