一件の注文にどの実行が属するか

架空の卸売業務で、担当者が「承認済みの発注書37番を仕入先に送ってください」と依頼します。仕入先は注文を作成しますが、応答が社内サーバーに届きません。担当者は再度依頼し、処理ワーカーも再試行します。モデルのログにはツール呼び出しが三件残っても、承認された結果は発注書37番に基づく仕入先注文一件です。

ツール呼び出しIDは試行を追うための情報です。会話IDは依頼時のやり取りを示します。別のセッションや計画ではどちらも変わり得ます。サーバーにはテナント、発注書、仕入先アカウントと承認された実行単位を結ぶ業務作業IDを保存します。注文作成と確認メールにもそれぞれIDを付けます。メール応答の喪失時には、確定した仕入先注文を保ったまま処理を進めます。

原文をキーにすると、依頼の言い換えが別作業になります。JSONが同じという理由でまとめると、同じ商品・数量・住所で別々に承認した注文を消す恐れがあります。担当者が新しい注文を明示的に承認した場合には、別の作業IDを発行します。仕入先アカウントや納品先の変更は元の承認と衝突する可能性があります。AWSは、呼び出し元が指定した識別子と初回のパラメーターを記録し、同じキーで異なる条件を送った場合は拒否する設計を紹介しています。AWSの冪等APIと再試行の解説[1]

キーを信頼できるサーバーが発行すれば、モデルの再計画で重複防止の判断が変わることを防げます。冪等性とは、同じ論理上の作業を繰り返し依頼しても、業務に新しい効果を加えない性質です。既存の結果を閲覧する際にも認可が必要です。別部門の発注番号が偶然一致した場合や過去の応答でIDを取得した場合にも、自分のテナントと権限の範囲内でのみ結果を表示します。

承認を再利用できる条件

承認には仕入先アカウント、納品先、数量、価格、通貨、ツール、承認者、ポリシーの版、有効期限を記録します。実行時にサーバーで正規化した値を照合します。改行やJSONキーの順序と、納品先や金額の変更を区別できます。正規化規則を変更する場合は、過去の承認を再検証する方法も決めます。

同じ作業IDでも引数が異なれば、元の結果を返す前に衝突として扱い、変更は別の承認経路へ送ります。元の作業の結果が不明なら、外部での状態を先に確認します。注文が存在する場合は、新規作成と変更のどちらが必要かを担当者が判断します。有効期限が切れた承認や取り消された承認で書き込みを再送できないようにします。照合に必要な読み取り権限は別に設定できます。OWASPの影響が大きい操作に関する指針[2]

承認履歴と実行履歴を保存します。実行承認の記録があって仕入先の注文IDがなければ、別途調査します。複数のワーカーが同時に作業を読める場合は、実行サービスやデータベースで制御を強制します。会話中の指示だけでは、現在の権限やデータの一意性を確認できません。

社内記録と外部での結果が分かれる時点

一意性制約と条件付き状態更新で、作業を取得できるワーカーを一つにします。業務レコードと送信待ちレコードを一つのデータベーストランザクションで記録すると、受け付けた作業の送信情報が失われる区間を減らせます。送信待ちレコードを復旧できる仕組みでは再配信が起こり得るため、外部呼び出しにも初回と同じ識別子を使います。

ワーカーのリース期限が切れても、外部での呼び出しが止まったかは分かりません。送信後に応答を失った可能性があります。次のワーカーは、作業の所有権を回収する手続きと結果の照合を分けます。更新バージョンや実行者を確認して古い応答による上書きを防ぎつつ、遅れて届いた実際の成功証拠は照合用に保存します。

社内では「送信中」でも、仕入先にはすでに注文が存在する場合があります。検索結果が空なら、反映の遅延や参照したアカウント・環境を確認します。どの時点で空の検索結果を未作成の証拠にできるかは、仕入先との契約や運用資料で確認します。問い合わせや照合で使う業務参照値と、当時の仕入先アカウント、試験・本番の区分を記録します。

作業状態による再試行の判断

以下は状態設計の例です。最後に確認した事実を起点に、次の操作に必要な事実を選びます。

作業状態外部書き込みの判断次の操作と証拠
承認待ち・期限切れ実行を保留承認履歴、期限、元の依頼を確認
準備完了・未送信作業を取得したワーカーが実行現在の承認、権限、入力と取得条件を照合
送信中・外部で処理中並行送信を制限外部参照値と照合期限を記録
成功を確認既存の結果を返す仕入先注文と社内作業を照合
失敗確定・外部効果なし契約と承認が許す場合は再試行拒否の証明と当初の入力・参照値を維持
結果不明先に照合し、契約の保証範囲内でのみ再送検索、Webhook、仕入先資料を調べ、必要に応じて担当者へ
取り消し・訂正が必要元の作業の再試行を終了別IDで訂正を承認し、結果を照合

HTTP 500や接続エラーは、実行の段階と外部サービスの契約に沿って解釈します。Stripeの公式資料では、API v1は実行開始後の最初の応答を保存し、同じキーに500を再度返す場合があります。保存対象から外れたキーの再利用は新しい依頼になり得ます。API v2の動作は別に記載されています。連携先ごとにキーの有効期間、対象API、引数衝突、処理中の再呼び出しとエラーの意味を定義します。Stripeの冪等リクエスト資料[3]

外部サービスが冪等キーを提供しない場合、社内での重複防止だけでは応答喪失を解決できません。外部参照値で結果を検索できるかと、その値の一意性を外部でも守るかを個別に確認します。検索も照合もできない場合は、結果不明での自動再送を見送ります。担当者が仕入先で確認する経路を設けるか、自動化の範囲を下書きと確認依頼までに絞ります。

サービスの仕組み

注文から承認・返金まで状態を接続 — 決済手段を注文フローにつなぎ、応答遅延、再試行、取消し、返金の例外を検証します。

六つの障害注入シナリオ

仕入先の模擬サーバーか承認された試験環境を使います。利用者の画面、作業データベース、外部台帳を確認します。エージェントが「注文しました」と答えたことだけを成功の証拠にすると、実際には注文がない場合を見落とします。Anthropicの実行記録と実際の結果を分ける評価方法[4]

試験障害を入れる位置合格の証拠
1. 応答喪失仕入先が注文を保存した直後に応答を切る外部注文は一件で、結果不明から成功に更新
2. 新しい会話と再計画モデルの再試行中に同じ発注書を再依頼試行は一つの作業IDに紐付き、注文は一件
3. 同時実行と復旧初回ワーカーを送信後に止め、期限切れ後に別ワーカーで取得二番目は照合を行い、外部注文の追加なし
4. 入力変更同じIDで数量や納品先を変更衝突の記録があり、外部呼び出しなし
5. 承認期限切れと遅延応答結果不明の間に承認を切らし、初回成功を遅れて配信追加書き込みは拒否し、確認した結果を照合に反映
6. キー期限切れ・非対応検索の反映を遅らせ、有効な冪等契約を除く空の検索直後には再送せず、担当者へ参照値と期限を渡す

外部注文数、引数の一致、表示状態、引き継ぎ件数、権限違反を試験ごとに記録します。成功後に同じ作業を開き直した場合も確認します。応答が途切れるたびに新しい承認を求めると、元の結果が不明なままになります。キーの範囲が広すぎて正規の注文を取りこぼさないよう、同一の入力で別々に承認した二件も比較対象に入れます。

照合してもすぐに結論が出ない場合

作業と仕入先の記録を、各ID、アカウント、注文時刻の範囲、数量、金額で突き合わせます。外部注文が二件一致する場合や別の発注書にも該当する場合は、例外として担当者へ渡し、仕入先に確認します。担当者が読める時刻と、システム間で比較する基準時刻を残すと、引き継ぎ中に検索範囲を見落としにくくなります。

運用画面には結果不明の経過時間、担当者、確定事項、信頼できる検索時点、再試行可否を表示します。復旧に必要な識別子を保護し、機微な応答をログに広く複製することは避けます。重複注文が分かった場合は、取消期限、発送状況、仕入先の状態を確認して補償操作を承認します。補償にも別のIDと照合条件を設けます。

注文・決済・提供の記録は決済と注文の状態整合性、一部変更の台帳照合は一部取消と返金額の検証で扱っています。エージェント側では、システムを改めて呼び出す際に作業IDと承認範囲が維持されるかを試験します。