経路で共有する停止方針を決める

画面の表示だけで送信や返金が止まったとは判断できません。ワーカーがすでにキューから処理を取り出していたり、次の試行が予約済みだったりするためです。対象範囲の新たな実行が止まり、停止前に境界を越えた案件を担当者が台帳で最後まで追えることを完了条件にします。

送信を止めるときに顧客対応のすべてを閉じる必要はありません。どのテナント、機能、ツールが対象かを決めます。特定の顧客企業のSMS自動送信に問題があれば、当該テナントの自動送信を止めながら照会や下書きを開けておけます。同じAPIキーを使うため送信を分離できない場合や、影響経路が不明な場合には、広い範囲を止める手順を用意します。許可する手動経路も実行側で判定します。

停止要求に対象環境、テナント・ユーザー・ツール・機能などの範囲、発令者、有効時刻、方針の版、理由とインシデント番号を記録します。複数の停止条件が重なる設計では、適用される停止がすべて解除されてから実行を許可できます。全テナントの送信が停止中なら、個別テナントの一時停止が期限切れでも送信を開けません。解除権限とその記録も発令と合わせて決めます。

方針の変更と全ワーカーへの反映には時間差があります。影響が大きい操作では、正本の方針を取得できなければ実行を保留します。画面、モデル、キャッシュは状態を表示できますが、最終確認は外部へ送信できるコンポーネントで行います。OWASPは高影響の操作について、承認と実行を分け、実行側が権限と承認を照合し、方針を確認できない場合には拒否するよう勧めています。OWASP AI Agent Security Cheat Sheet[1]

実行権限がある場所で最終判定する

受付サービスが停止状態を見てからキューへ登録するとします。ワーカーは受付済みでも外部呼び出し直前に現在の状態を再確認します。作業IDに方針の版と承認IDを関連づけ、古い判定での実行を拒否できるようにします。古い権限や一時キャッシュのままツールを直接呼べると、方針変更が反映されません。本番の認証情報は実行サービスに限定し、管理者の手動操作、バッチ、補助エージェントの経路にも同じ判定を適用します。

最終判定と外部サービスの受理の間には短い競合区間があり得ます。停止方針と内部の実行許可を整合的に更新すれば、有効時刻以降の新規許可を抑えられます。すでに始まった外部呼び出しには個別の対応が必要です。内部許可、送信試行、外部受理の時刻を残して、この区間に境界を越えた案件を調べます。取り消し機能を持つ提供元では、対象範囲と結果照会を事前に試験します。

作業の状態ごとに停止の証拠を確認する

表を自社の処理台帳に当てはめ、止める操作と残る作業を対応づけます。キューの指標だけを見ると、取り出されて実行中の処理を見逃すことがあります。

作業状態停止時の措置残る作業確認の証拠
受付前APIと作業生成経路で新規自動処理を拒否手動受付や安全な参照経路発令後の拒否応答、新しい作業IDの未発行
承認待ち・承認済み自動進行を止め、実行時に停止・承認・期限を照合下書き、履歴、再確認する案件承認ID、方針の版、期限、実行拒否
キュー待機台帳で保留または取消扱いにし、受信しても実行を拒否メッセージ本体、再配信、保留案件の分類キューIDに対応する状態と再受信時の拒否
実行中、外部操作前ワーカーに協調停止を通知し、実行段階で拒否一時ファイルや内部変更の片付けワーカーの段階、外部要求が作られていない証拠
送信試行済み、結果不明再試行を保留し、提供元へ状態を照会受理・送信の有無、次の対応内部試行ID、外部照合キー、照会結果
外部サービスが受理済み可能なら取り消しを依頼し、後続処理を止める取消待ち、または確定した結果外部の受理記録、取消結果、最終状態
予約・遅延再試行新規登録を止め、起動時に方針を再確認保留中の予定、遅れて届くメッセージ予約ID、再試行時刻、再配信や手動再開の拒否
完了済み外部結果と影響を調べ、補正処理は別途承認訂正通知、台帳の照合など完了状態、業務への影響、承認済み対応

キュー全体を消すと、他のテナントの正常処理や調査に必要なIDも失われます。別に管理できる台帳に状態を残し、メッセージと照合します。Amazon SQSの可視性タイムアウトは受信済みメッセージを他の受信者から一時的に隠す仕組みで、重複配信の可能性があります。この方式を使うなら、件数がゼロに見えても取り出し済みの作業や再配信されるメッセージを試験します。実際のキューの受信・再配信規則を使って判定します。Amazon SQSの可視性タイムアウト[2]

タイムアウトと外部受理を照合する

取消通知によりワーカーが応答待ちをやめる時点で、提供元が要求を受理している場合があります。結果不明として記録し、同じ照合キーで状態を調べるか通知を待ちます。照会機能がない場合は、運用担当者が提供元と突き合わせるアカウント、受付時刻、業務の参照値を決め、自動再試行から除外することを検討します。

冪等性は同じ意図の要求を再送した際の重複動作を減らす契約です。適用は提供元のキー、引数、範囲、有効期間に依存します。キーがあっても停止中の実行は許可されません。有効期間を過ぎた場合やツールを切り替えた場合に、同じIDで同じ扱いになると決めつけないようにします。AWS Builders' Libraryの冪等API解説[3]

内部の作業ID、送信時刻、承認の版、提供元ID、受理・取消状態とその確認時刻を照合資料に含めます。実行時の方針と実際の操作を関連づける方法はAIエージェントの可観測性、引継ぎ時の記録は障害対応Runbookを参照できます。

サービスの仕組み

監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。

仮想のSMS停止訓練で確認する六件

仮想の顧客対応サービスで、特定のテナントの自動SMSのみを止めます。宛先をサンドボックスに向け、作業IDと外部受付IDを確認できるよう準備します。待機、実行、承認、予約の各状態に試験用作業を置きます。停止指示の受付と、実際に拒否した経路を分けて記録します。

試験作った状況期待結果失敗の証拠
発令後の新規受付対象テナントのSMS送信を要求新規自動送信は拒否、下書きの参照は可能送信作業が生成される、または下書きも閉じる
取得済みの作業古い方針を読んだワーカーが呼び出し直前まで進む最新の停止方針を適用し、外部呼び出しなし古いキャッシュで送信
取消が間に合わない提供元の受理直後に停止し、受理応答を遅延結果不明を記録し、受理IDと最終状態を照合キューが空なので成功扱い、または重複送信
再配信・予約メッセージを再配信、予約を起動、失敗キューから手動再送どの経路も送信ツールを拒否予約や手動再送による迂回
承認の期限停止中に承認が失効し、再開後に処理が到着自動再開を保留し、現在の要求・権限・宛先を承認古い承認や異なる送信内容で動く
対象範囲の比較対象外テナントで承認済み送信を要求対象外の許可された送信は完了対象外も停止、または対象テナントに影響

方針の更新とツール要求の順序を繰り返せるよう、試験に一時停止点を置きます。ワーカーを確認の直前で止める、またはサンドボックスが要求を受理して応答だけを遅らせる方法があります。何を故意に失敗させたかと実際の外部要求数を分けて記録します。模擬ツールで取消に成功した場合も、本番提供元の取消が意味する内容を調べます。

外部が受理済みの案件は同じ下書きから再送しません。担当者が受理時刻、宛先、内容、次の対応を確認します。送信済みなら、ツールを再開するかと顧客に訂正を送るかを別に決めます。古い案件の照合と並行して新規送信を開けるときは範囲を絞り、結果不明案件の再実行を引き続き止めます。

再開前に過去の承認を見直す

新規の受付、保留中の作業の再登録、外部結果の照合にはそれぞれ判断条件を設けます。サンドボックスで方針と実行境界を確認し、安全に試験できる新規経路から限定的に開けます。復旧対象、観察中の処理、現在の版、担当者を関連づけます。NISTのインシデント対応指針[4]は対応と復旧をリスク管理に取り込みます。OWASP Securing Agentic Applications V2[5]も実行時の制御と試験の資料になります。

古いキューを再開する前に、実行済みか、意図が現時点でも有効か、宛先や操作が変わっていないか、最新の権限と制限を満たすかを確認します。期限切れや内容変更は再承認します。結果が二つのシステムで異なる場合は人に引き継ぎ、実態が確定するまで再実行を保留します。原因がコード変更なら、ロールバック可能なデプロイの版の復旧と、ここで扱う保留作業の再開を各証拠に沿って進めます。

最終記録には発令と再開の権限者、対象範囲と有効時刻、通過と拒否を確認した経路、照合済みと対応中の外部案件を含めます。補正処理が必要なら、元の結果、理由、承認者、実行結果を結びつけます。停止の証拠は発令したクリックから、最後に確認した業務上の結果までつながっていることが重要です。