要約

  • 2026年9月2日公開のdraft-paxton-aicp-00は、個人提出の有効なInternet-Draftである。IETFの承認や正式な地位、RFCストリーム、担当Area Director、テレチャット日はない。
  • AICPの進捗は、完了済み、実行中、全体のステップを列挙し、任意でパーセンテージを添える。正式なのはステップ集合で、数値は参考情報である。
  • 草案は、パーセンテージを成功確率または安全なキャンセル境界と解釈してはならないと明記する。
  • フェーズと作用状態は独立している。失敗・キャンセル後にも部分的な作用が残り得る。キャンセルは独立した冪等のベストエフォート要求であり、「何も起きなかった」という証明ではない。
  • 影響の大きい停止判断には、ステップ、フェーズ、作用、シーケンス、キャンセル要求、未観測事項、照合作業の要否を残す専用レシートが必要だ。

進み具合と安全性は同じ物差しで測れない

Datatrackerの記録によると、*Agent Infrastructure Control Protocol (AICP)*はTihan-Nico Paxtonによる個人Internet-Draftの00版で、2026年9月2日に更新された。ヘッダーのStandards Trackは著者が意図する到達先であって、現在の承認ではない。RFCストリーム、担当Area Director、テレチャットは記録されていない。IETFの説明も、Internet-Draftは誰でも提出でき、それ自体に正式な地位はないとする。

技術的な着眼点は鋭い。一般的な進捗バーは、三つの問いを一つの数値に押し込む。予定した工程のどこまで来たか。最終的に成功しそうか。そして、今止めても安全か。これらは独立して動く。

五段階の処理を二つ考える。一方は最初の段階で外部変更を行い、残り四段階を確認に使う。もう一方は四回の読み取りを終えた後、最後にだけ変更する。前者の20％は既に決定的な作用を伴い、後者の80％はまだ無作用かもしれない。ステップ数の比率から作用の大きさは読めない。

固定された00版はこの混同を避ける。進捗情報は完了済み、実行中、全体のステップを識別し、それらが正式な記録になる。任意のパーセンテージは参考値であり、成功確率でも安全なキャンセル点でもない。

草案は進捗率と作用量の換算式を定めていない。0％だから作用がnone、100％だからcompleteまたは成功、とする根拠もない。そう見せる画面は、草案の情報を表示する以上の政策判断を追加している。

フェーズが終わっても作用の説明は終わらない

AICPのOperationには、待機、承認待ち、実行、検証、一時停止、成功、失敗、キャンセル、不確定といったフェーズがある。一方、作用状態はnone、possible、partial、complete、reversed、unknownとして別に記録される。

両者が独立なのは意図的だ。外部変更の後でOperationが失敗することはある。キャンセルが届く前に部分的な作用が生じることもある。成功しても副作用は残り得る。観測がないだけで「作用なし」にせず、提供者は保守的に状態を更新する。

終端のOutcomeも、期待された変更と観測された変更を分け、副作用、証拠、次の行動、各成功条件の結果を持つ。条件は満足、不満足、不明、未評価になり得る。提供者APIが正常応答したことだけではOperation全体の成功にならない。

つまり進捗バーが示せるのは、せいぜい計画上の位置である。ライフサイクル、実世界の作用、証拠の確かさは別に示さなければならない。一色のバーに統合すれば、画面設計が本来存在しない確信を作ってしまう。

キャンセルは巻き戻しではない

AICPではキャンセル自体が独立した冪等の制御要求である。同じ要求を通信障害後に再送しても、別のキャンセルを新設しない。しかし実行はベストエフォートであり、元の処理が止まる保証ではない。完了と競合した場合は、その時点のOperationが返る。一時停止から再開する際には、権限、制約、前提条件を再評価する。

提供者は最終フェーズと作用状態を報告し、cancelledを「作用はなかった」という意味にしてはならない。したがって「35％ならまだ安全」という閾値は成立しない。実行中ステップが既に外部要求を出したかもしれず、完了済みの一ステップが唯一の変更だったかもしれず、観測が遅れているだけかもしれない。

補償も逆向き再生ではない。作用を戻す処理は、新たな権限と失敗可能性を持つ別の重要操作で、副作用も起こし得る。reversedであっても、補償結果の観測を表すべきであり、過去と完全に同じ状態を保証する言葉ではない。

再試行も同様だ。作用がpossible、partial、unknownなら、同じ変更を機械的に繰り返してはならない。AICPの問題表現は、再試行の安全性と照合の必要性を示せる。タイムアウトや低い進捗率は、その判断の代わりにならない。

停止専用のレシートを残す

実質的な影響があり得る一時停止やキャンセルには、通常の進捗表示とは別の停止レシートを作るべきだ。これは00版の規定ではなく、同版が守った区別を実務判断まで運ぶための私の提案である。

レシートは永続的なOperationと最新シーケンスを特定し、完了・実行中・全体のステップ集合をそのまま掲載する。フェーズと作用状態を並列に示し、キャンセル要求の識別子と状態、まだ届いていない観測、再試行や補償の前に照合が必要かを記録する。

期待と観測も混ぜない。資格情報を失効させる予定だったが独立確認がないなら、「失効を期待、作用は不明」と書くのが正確だ。「35％でキャンセル済み」では足りない。作用がないのか、部分的なのか判断できない場合、unknownは欠欄ではなく正規の回答である。

Heng Luが述べる正確な記録への権利は、ここで有効な編集原則になる。記録は現実を記述し、現実を作り出すものではない。同じくレシートは、観測されていない安全性や成功確率を数値から創作してはならない。これは私の分析であり、Heng Luの論考をAICPやIETFの規則とみなすものではない。

提案の価値と証拠の限界

00版にはHTTP制御ループの例とプロトコル不変条件があるが、確認した本文にImplementation Status節はない。独立実装、本番導入、相互運用結果、IETFによる採用を示す資料も確認できなかった。RFC Editorの解説どおり、Internet-Draftは変更、失効し、RFCにならない場合もある。

だからこそ実装評価では、扱いにくい組合せを試すべきだ。0％かつ作用possible、100％かつ条件不満足、cancelledかつpartial、indeterminateかつ観測待ち。これらを表示できない製品は、提案の有用な慎重さを取り除いている。

情報源

  1. IETF Datatracker：Agent Infrastructure Control Protocol
  2. IETFアーカイブ：draft-paxton-aicp-00
  3. IETF：Internet-Draftについて
  4. RFC Editor：RFCができるまで
  5. Heng Lu：The Bill of Rights of Uniqueness Coordination