- 公開日
エージェントへ停止を伝えたのに処理が続くときは、要求がどこまで届き、どの処理が止まり、どの変更がすでに反映されたかを分けて調べます。「キャンセルしました」という回答だけでは、外部操作の停止も変更の取消も確認できません。新しい操作の開始を止め、実行中の要求を接続先まで追います。
「無視された」に見える原因を分ける
AIが停止の意図を読み違えた場合と、実行基盤が停止を伝えられなかった場合では、修正する場所が異なります。たとえば会話画面が生成を止めても、別の担当エージェントや待機列に入った更新処理は動き続けるかもしれません。外部サービスへ要求を渡した後なら、モデルが返答をやめても、その要求の状態は別に確かめる必要があります。
原因を調べるときは、画面で停止を受けた記録、全体を管理する実行基盤の記録、担当処理とツールの記録、接続先の処理状態を順に照合します。記録がない箇所は「停止を拒んだ」と断定せず、伝達または記録の有無が未確認だとします。
| 確認する境界 | 起こり得る問題 | 次に確認するもの |
|---|---|---|
| 利用者から実行基盤へ | 別の実行を停止対象にしている | 対象の実行IDと停止対象の範囲 |
| 実行基盤から子の処理へ | 親の会話だけ終了している | 子の一覧、停止信号の送達と現在状態 |
| 担当処理からツールへ | 待機中の処理が停止後に動き出す | 取り出し時・実行直前の停止判定 |
| ツールから外部サービスへ | 取消を受けない操作や遅着がある | 取消仕様、要求ID、接続先の確定状態 |
この表は原因調査のための設計例です。停止文の強調だけでは待機列や外部サービスを制御できないため、実装で遮断できる段階と、確認が必要な区間を利用者へ示します。
受け付けたことと、止まったことを別に返す
停止要求には対象の実行ID、停止する範囲、要求元とその権限、受付時刻を対応付けます。親から子へ委任するときも、全体の停止状態と期限を引き継ぎます。子がさらに別の処理を作る場合は、その関係を追えるようにします。機密の依頼本文や認証情報を、追跡のために丸ごと複製する必要はありません。
副作用とは、データ更新や送信など、回答の外側に残る変更です。本稿で提案する実行基盤では、停止受付後に新しい副作用操作を始めないようにし、担当ごとに「停止要求を受領」「処理の終了を確認」「接続先は照会中」を返します。停止の受付を理由に、すべての担当を一括して「停止済み」に変えてはいけません。
停止が届いた時点と、新しい要求を外へ渡す時点が競合することもあります。実行基盤が停止状態の更新と操作開始の可否を一貫して判断する仕組みを置き、判定前に外へ出た要求は実行中として残します。この仕組みがなければ、実行直前に一度フラグを見るだけで競合を解消したとはいえません。
製品の終了機構にも確認範囲があります。AutoGenのstable文書では、Terminationが、チームの終了条件を各エージェントの応答後に評価すると説明しています。Teamsには、発言中のエージェントの番が終わってから止める外部停止と、CancellationTokenという中断を伝えるオブジェクトで実行を直ちに打ち切る例があり、両者は区別されています。これらは会話や実行の区切りを作る機構であり、下流サービスで完了した変更まで戻った証拠にはなりません。応答が返らない間の期限監視や、外部処理の取消は別に設計します。
通信方式も固定して確認します。MCP（Model Context Protocol、AIとツール等をつなぐ通信規約）のCancellationの2026-07-28仕様では、Streamable HTTPは応答ストリームの閉鎖、stdioは通知というように取消信号の扱いが異なります。また、完了後に通知が届く場合や、取消できない場合があります。同じ「cancel」という名前でも、別の版や通信方式の手順をそのまま使えるとは限りません。
架空の一括更新を途中で止める
ここからは未実行の架空例です。利用者が「対象の六件について、通知設定をオンからオフへ変更して」と依頼し、その六件への変更だけを承認したとします。全体の実行を管理する担当が、更新担当と照会担当へ仕事を渡します。更新担当には指定された六件だけの更新権限があり、照会担当は結果の読取りだけを行える設定です。
この架空サービスは、要求IDによる状態照会と、処理中の取消要求を受け付けるものと仮定します。ただし、確定後の変更を戻す機能は今回の許可に含めません。通常時は六件の設定が承認どおり変わったことを照会して完了を返します。対象IDや更新権限が欠けている場合は更新を始めず、不足を依頼元へ返します。
比較では入力・権限・六件の対象を固定し、停止が入る時点だけを変えます。最初の更新要求を出す前に停止を受ければ、六件とも未着手のまま終了することを期待します。一方、途中で停止を受けた時点の状態を、次のように仮定します。
| 対象 | 受付時点での記録 | 期待する処理と確認 |
|---|---|---|
| 一、二件目 | 更新済みと確認済み | 変更済みとして残す。停止によって元に戻ったとは案内しない |
| 三件目 | 外部で処理中 | 取消要求を伝え、元の更新と取消要求の状態を照会する |
| 四件目 | 要求を送ったが応答なし | 成功・失敗を決めず、要求IDと対象状態を照合する |
| 五、六件目 | 待機列内で未着手 | 取り出しと更新開始を止め、開始していない記録を確保する |
停止後の照会で、三件目は「変更前に取消が確定」、四件目は「更新確定」と分かったと仮定します。その場合の報告は、「更新済み三件、変更前に取消一件、未着手二件。実行中として残っていた要求の終了を確認しました」です。停止の前後で、更新済みの件数が増えること自体は矛盾ではありません。受付時点で外部へ渡っていた四件目の結果を、後から確認したためです。
四件目を照会できなければ、報告は変わります。「更新済み二件、変更前に取消一件、未着手二件、結果未確認一件。新規更新は止めています」とします。分からない一件を失敗へ含めず、担当者へ要求IDと最後に確認できた状態を渡します。これらは期待する記録と案内の例であり、実際に六件の更新を試した結果ではありません。
残った変更を戻す前に確かめること
更新済みの項目を元に戻す操作は、別の副作用です。利用者の「止めて」が、今後の更新の中止なのか、すでに終わった変更の復元も含むのかを区別します。復元が必要でも、その間に別の利用者が設定を変えていれば、開始前の値で上書きすることが正しいとは限りません。復元対象、現在の版、許可範囲、戻せない結果を確認してから扱います。
取消要求の応答が来ない場合も、元の更新を再送して状態を確かめる方法は避けます。AWSのMaking retries safe with idempotent APIsは、応答を受け取れなくても副作用が生じている可能性と、再試行を安全にするための契約を説明しています。同じ要求の重複適用を防ぐ冪等性には、サービス側が識別する主体・意図・内容や保持期間などの条件があります。追跡用のIDを付けるだけでは、その契約を代替できません。
停止確認のための照会まで一律に止めると、残った影響を確認できなくなります。新しい更新は遮断しつつ、承認された読取り、記録の保全、管理者への引継ぎは別の経路で続けられるようにします。実行基盤が中断しても確認を担当できる人と、対応を求める期限を決めておきます。
停止不能を人へ引き継ぐ条件
運用では、受付から所定の期限までに担当処理の終了を確認できない、取消手段がない、結果照会ができないといった条件を、管理者へ引き継ぐ基準にします。期限は業務の影響と接続先の仕様から定めます。待機を延長し続けるのでなく、期限を超えたら未確認の処理を担当者へ渡し、誰が照会を続けるかを明確にします。
管理者が実行権限の失効や接続の遮断を検討する場合も、すでに外へ渡った処理への効力と、照会経路が残るかを確かめます。強制的に実行基盤を終了させても、外部側の終了確認やデータの復元が同時に完了するわけではありません。
導入前には、外部へ変更が出ない許可済みの模擬環境で、停止直前の要求、遅れた応答、取消不能を確認対象にします。見るのは停止メッセージの有無だけでなく、停止後の新規開始、担当の取り残し、実際の変更、結果不明の表示です。必要な記録には実装・保守の負担が伴いますが、その負担を避けて停止済みと推測すると、再開時に残存処理と二重実行を区別できなくなります。
目標逸脱・反復・過剰実行を止める条件は「AIエージェントの目標逸脱・反復・過剰実行を止める条件」、ツール連鎖のチェックポイントを保存し、条件を再検証して再開する方法は「ツール連鎖のチェックポイントを保存し、条件を再検証して再開する」で解説しています。
