実行中のエージェントの方針を変える：指示のリビジョン管理と副作用の照合

目的

2026年10月25日時点の情報である。すでに実際の影響が生じた作業を保持しながら、ユーザーによる修正、一時停止、目的の差し替えを適用する。ランタイムの中断時の動作と、リモートサービスのキャンセルおよび重複検出に関する保証を再確認する。この提案が扱うのは、実行中に意図を変更することである。定期的な進捗チェックポイントだけでは、この移行が行われたことにはならない。

前提条件

永続的なタスク識別子、順序付けされた指示のリビジョン、試みた外部操作の台帳を保持する。各試行には、対象、入力への参照、操作識別子、観測された結果が必要である。すでに置き換えられたリビジョンに属する操作を拒否できる受付地点を設ける。それがない場合は、影響を受けるワーカーの停止を待ってから差し替え後の作業を開始するオーケストレーターを使う。

手順

1. 更新を分類して記録する。 進捗に関する質問と、修正、一時停止、キャンセル、新しい目的を区別する。影響を受けない要件は保持する。直列化された制御経路を通じて更新とそのリビジョンを永続化し、どの解釈を採用したかを伝える。意図された変更を安全に判断できない場合は、確認を求める。
2. 影響を受ける旧作業の受付を止める。 差し替え後の作業を送出する前に、置き換え済みのリビジョンで新たな副作用が発生するのを防ぐ。影響を受ける子エージェントと待機中の操作に、照合が必要であると記録する。境界の確認は操作の受付と連動させなければならず、ワーカーが推論の早い段階で一度確認するだけでは不十分である。すでに受け付けた操作は、結果が判明するまで台帳に残す。
3. 中断を要求し、その結果を観測する。 A2A仕様は、キャンセルを失敗し得る試みとして説明しており、すでに作業が完了している場合などが含まれる。「停止要求済み」は、確認済みの終端状態と別に記録する。インターフェースが閉じたことをキャンセルの証拠と解釈せず、追跡中のタスクと操作の受領記録を確認する。
4. 再試行する前に不明確な影響を解消する。 各試行を、成功確認済み、失敗確認済み、不明のいずれかに分類する。可能であれば、正とするリモート側の状態を照会する。操作の冪等性キーを再利用できるのは、そのサービスが文書で定めた契約と保持期間の範囲内で、意図する操作が同じ場合だけである。A2Aではメッセージ送信の重複検出は任意であり、メッセージ識別子だけでは重複排除の証拠にならない。不明な影響を照合できない場合は、その再試行を止め、不確かな点を報告する。
5. 移行時点の状態を保存する。 新しい目的のリビジョン、すでに生じた影響、再利用可能な成果物、保留中の操作識別子、残りの予算を保存する。旧リビジョンの記録も保持する。置き換え済みの計画は有効な指示から取り除き、その証拠は監査に利用できる状態に保つ。影響を相殺する変更は、自動的な取り消しと呼ぶのではなく、別途認可された操作として扱う。
6. 引き継ぎ関係を明示して再開する。 影響を受ける各子エージェントに、採用したリビジョンを渡し、結果にもそのリビジョンを含めるよう求める。A2Aのタスクライフサイクルでは、終端状態のタスクは再開できず、関連する後続作業には新しいタスクが必要である。有効な成果物は参照によって再利用し、後継タスクを明示し、その範囲に合わない遅延結果は拒否する。

期待される結果

ユーザーは、何が変わったか、変更前に何が完了したか、何が未解決かを確認できる。差し替え後の作業は、照合済みの状態から始まる。キャンセル要求が外部への影響の消滅を示す証拠として扱われることはなく、遅れて届いた応答が、確認を経ずに現在の目的を上書きすることもない。

限界と検証の根拠

これは未検証の調整手順である。操作を記録した後に応答を遅らせる模擬サービスと、方針変更後に結果を返す子エージェントを使って試す。提案する受け入れ条件は、無確認の重複操作がないこと、置き換え済みの指示を採用しないこと、照合できない場合は未解決の状態を明示することである。