要約

  • IESGは2026年10月8日、Agentprotoの活動範囲を承認した。最初の目標は、12月にユースケースを扱う草案を採択することだ。
  • 10月15日更新の関連草案は、確認した記録では個人提出のまま。著者による改訂とワーキンググループによる採択は、別の出来事である。

接続が切れても、頼んだ仕事まで終わったとは限らない。AIエージェントが途中から別のサービスに仕事を渡す場合もある。再び届いたメッセージが新しい依頼なのか、それまでの作業の続きなのか。複数のシステムが動くには、まずそこを見分ける必要がある。

IETFのAgentprotoが取り組むのは、この会話の連続性だ。承認済みのチャーターは、共通の対話管理プロトコルと、関連する部品を組み合わせるための参照アーキテクチャを作るとしている。AIの回答を上手にする仕事ではない。利用者、エージェント、ツールの間にまたがるやり取りを、同じ対話として結び付ける仕事である。

ここでいう「コンテキスト」は、モデルが覚えている会話の全内容ではない。検索した文書やプロンプトも含めない。対話を識別するためのIDと、その開始や終了などの状態を扱う。やり取りのつながりを共有することと、アプリケーションが交換する内容を共通化することは分けられている。

何を作らないかも決まっている

Agentprotoは新しい転送用プロトコルを作らず、アプリケーション層のエージェント通信プロトコルも置き換えない。対話の情報は、既存のIETFプロトコルに載せる。モデルの実装、判断や計画の意味、利用者向け画面、監査データの構造は担当範囲の外だ。

ただし、会話にIDを付ければすべて片付くわけではない。長い仕事では、途中で権限を取り消す必要が生じ得る。利用者の代理で動くエージェントは、その利用者とは別に身元を確かめる必要もある。チャーターは権限の限定や独立したアクセス取り消しに触れ、仲介者や信頼の境界を越えて続く対話を想定する。同じ会話の一部だと分かっても、その中のあらゆる操作を許可してよいとは限らない。

記録上の承認日は10月8日である。IESGが認めたのは、この範囲で作業するという任務だ。履歴には、後のプロトコル段階で複数の文書を扱えるように表現を改めた経緯もある。特定のユースケース草案を承認したという記録ではない。

10月の文書と12月の目標

公開日程では、最初の目標は2026年12月、ユースケースに関する情報提供目的の草案を採択することになっている。ところが関連文書の一覧には、すでに Agentic AI Use Cases and Requirements がある。最新版の -04 は10月15日付だ。

予定より早くできた、と読みたくなる。だが、日程に書かれた動作は「公開」ではなく「採択」である。草案自身のページには、現在も個人提出のInternet-Draftと表示されている。RFCの系列も割り当てられていない。ページは、個人が提出した草案をIETFの支持と受け取らないよう説明している。

著者が文章を用意して改訂することと、グループが共同作業の文書として選ぶことの間には、一つの決定が必要だ。一覧に載ったというだけでは、その決定が済んだとはいえない。

表示にはもう一つ注意点がある。Datatrackerの予定RFC区分は空欄だが、草案の冒頭には、情報提供を目的とする旨が明記されている。著者が方向性を示していないわけではない。ただ、その意思表示もグループの採択を意味しない。二つの表示は別々に読む必要がある。

草案が挙げるのは、複数エージェントの協働、権限確認を伴う長時間の委任作業、仲介者を通したツールやデータの利用といった場面だ。検討すべき要求を提案しているのであって、すべてがワーキンググループに認められたとも、実際の運用で実証されたとも書けない。

日程はその先にも続く。2027年2月に情報提供目的のアーキテクチャ草案、3月に標準化を目指す一つ以上のプロトコル草案を採択する予定だ。IESGに提案標準として提出する目標は2028年3月となっている。いずれも今後の目標であり、承認済みの成果ではない。

10月の文書は、議論を具体的な文章に移せる点で意味がある。12月の目標は、それを含めどの文書をグループ自身の仕事として選ぶかにある。AI同士が会話の続きを見失わない仕組みを作るにも、まず人間側が「誰が何を決めたか」を見失わないことが必要だ。

2026年10月24日補足： Datatrackerの空欄と、草案本文で示された情報提供目的を区別した。記載した日付は作業目標であり、確認時点の10月版は個人提出の草案である。