要約

  • 公開議事録は八つの挙手結果を、メーリングリストで確認すべき拘束力のない会場の感触と明記している。作業部会やチャーターの承認記録ではない。
  • 初期スコープは賛成38、反対124、意見なし40。初期成果物は92–58–49。「このチャーターでWGを設置」は154–51–5だった。
  • 設問ごとの回答総数は一定でなく、個人別の組み合わせも公開されていない。スコープに反対した124人と設置に賛成した154人の重なりを断定することはできない。
  • 会合時の文面は不変コミットa9405f3d5d0a4e8c67342d7945137c8230b9cd05に固定できる。その後のメールと未マージの範囲縮小pull requestは、重要な境界が未決着だったことを示す。
  • 調査時点のDatatrackerはAgentprotoをBOF、チャーターを(None)としていた。会場、リスト、Area Director、IAB、IESGの行為はそれぞれ別である。
  • 「設問・文面対応表」を公開すれば、氏名付き投票を作らずに、設問、版、回答母数、異論、修正、リスト確認、最終権限状態を追跡できる。

数字が正しくても、要約は誤り得る

Agentproto BoFの公開議事録は、2026年7月23日の会合をWG-forming BoFと記録する。同時に、文書自体を「chair review用のDRAFT」と表示している。人間の記録係によるノート、Zulip、発表資料からAI agent harnessを使って編集され、発言者名と所属は暫定、出席者数は未確定で、最終的な訂正責任はchairsにあるという。

この来歴は弱点を隠していない。むしろ、記録をどう扱うべきかを明確にする。現時点で重要な一次記録だが、確定した逐語録として引用してはならない。

挙手の位置づけも明記されている。Meetechoで会場の感触を測ったもので、拘束力はなく、コンセンサスはリストで確認される。この限定を落とした記事は、数字が一致していても権限状態を誤って伝える。

議題の第01版では、動機、関連作業、セッション、マルチモーダル、フレームワークの説明と公開討論の後にコンセンサス確認が置かれた。IETF 126のBoF紹介も、WG形成型BoFは十分な合意、作業する力、十分に絞られたスコープを確かめるものだと説明していた。別の軸が別の答えを出したこと自体は、診断機能が働いた結果である。

八つの問いが測ったもの

問題が理解され、解決可能で有用かは124–72–14。相互運用性の必要性が明確かは155–30–8。IETFが適切な場かは158–30–14。初期スコープが正しいかは38–124–40。初期成果物が正しいかは92–58–49。このチャーターでWGを設置するかは154–51–5。文書執筆・レビューへの参加意思は137–17–40。実装意思は42–28–40だった。

議事録のまとめは単純な賛成宣言ではない。問題を解く価値、相互運用性、IETFという場、WG形成には強い支持があった一方、書かれたままの初期スコープは支持されず、成果物については割れたとする。終盤にLaurent Ciavagliaは、「正しいか」という問いを「完全か」と混同すべきでないと述べ、スコープとチャーターはリストで続けて議論されることになった。

回答総数も順に210、193、202、202、199、210、194、110と変わる。固定された選挙人団が同じ手続で八回投票したのではない。回答しなかった理由や参加形態を、公開表から推測してはならない。

さらに、個人別のクロス集計がない。第四問で反対した124人のうち何人が第六問で賛成したのかは分からない。「同じ124人がスコープを拒否してWGを支持した」という表現は作り話になる。逆に、二つが完全に別の集団だったとも言えない。

氏名付き回答を公開する必要はない。chairsは、反対理由を「広過ぎる」「不足している」「用語が曖昧」「特定成果物に反対」など個人を識別しない類型にまとめられる。また、第六問の賛成が具体的な修正を条件としていたかを説明できる。必要なのは派閥表ではなく判断の接続である。

両立するからこそ、条件を書き残す

正式な作業場所を求めながら、現在の境界を拒むことに矛盾はない。Agentprotoの課題をIETFで扱うべきだと考えつつ、セッション・ライフサイクルを外したい人もいる。用語を直せば賛成という人も、フレームワークには賛成だが成果物には反対という人もいる。「correct」を「不足が一つもない」と読めば、改善可能な案にもnoと答え得る。

それでも第六問の文言は重い。単に「この話題に場が必要か」ではなく、「このチャーターでWGを形成するか」と尋ねたからだ。

RFC 5434は、合意点と不足点を見つけるため、問いを部分に分けることを勧める。この考え方なら、全体を進めたいという答えと一部への反対は共存する。同RFCは同時に、「以下のチャーターでWGを作る支持があるか」という統合設問を、具体的チャーターが準備できたかを測る例としている。

したがって、結果を無効と宣言する必要はないが、肯定を成立させた条件は必要である。「スコープ修正後なら設置」という意味なら、修正対象を示す。「正しい」と「完全」の違いが効いたなら、不足項目を示す。後日の最終文面が大きく変わった場合、ウィーンの154人がその新文面を承認したとは書けない。新文面は後日のリストと正式手続から権限を得る。

この接続は154を白紙委任から守り、124をAgentproto全体への拒否に変えることも防ぐ。

「このチャーター」を動くリンクにしない

議事録は提案チャーターをリンクし、会場で現行文面を表示したと記す。公式ART areaリポジトリには、会合二日前の7月21日に作成された不変コミットa9405f3…のチャーターがある。調査時点で、このファイルの履歴はその一コミットだけだった。

文面はagent-to-agentとagent-to-toolの通信に加え、定められた人間・エージェント間の仕組みを含む。独立したエージェントID、委任認可、機密性、完全性、監査可能性を考慮事項に置き、Standards Trackのセッション・プロトコルとInformationalのフレームワークを成果物にしていた。短期・長期セッション、コンテキスト、障害回復、異なる時間特性のデータ、point-to-multipointも対象だった。

コミット固定は、全員が全文を読んだ証明ではない。過去の「この」がmainブランチの将来文面を指すのを防ぐ。後の文面が優れていても、それは別の審査対象である。

会合後の議論が示す未決着

8月12日、Suresh Krishnanは“Sussing out points of disagreement on the charter”で、コメントを受けた二つの全面書き直し案に触れた。整理した争点は、成果物がsubstrateかsemanticsか、セッション・ライフサイクルを含むか、correlationだけかbindingの証明まで行うか、point-to-multipointかbilateralか、成果物の数・状態・順序、用語をどこまで定義するか、の六つだった。

これは表現の磨き上げではなく、作業部会が何を作るかという境界である。

会合時コミットをbaseにした公式リポジトリのpull request 77は、minimum viable primitiveへの縮小を提案した。セッション・ライフサイクルをスコープ外に移し、セッション・プロトコルをinteraction referenceとbinding envelopeに置き換える。調査時点ではopenで未マージだった。説明はAI支援のチャット分析を用いたとも明かす。出所を判断する有用な情報だが、承認済み代替案にはならない。

8月26日の証拠要件に関する文面提案は、より小さい接続問題を示す。Nancy Sahuは、運用証拠が何を立証し、何を立証しないかを書き、証拠を扱う成果物を削るなら考慮事項のauditabilityも同時に扱うよう求めた。これは個人提案であり、採否を示さない。それでも、上位の約束と実際の成果物が別々に変わる危険は分かる。

9月1日のIETF 126回顧は、Agentprotoがチャーター化のコンセンサスを試し、議論がリストで続くと述べる。Datatrackerの現行ページはBOF、Charter (None)、「Not chartered yet」と表示していた。このnullこそ、将来予測を混ぜない現在の権限状態である。

会場から正式権限まで

RFC 2418 / BCP 25では、チャーターは関係Area Directorと調整され、IABの助言を受けてIESGが最終承認する。IESGは原案承認、修正要求、設置拒否のいずれも選べる。承認後に初めて記録・公告される。

同文書は51%がラフコンセンサスではないと明記し、対面会合の結論をリストで検証する場面も扱う。数を捨てる制度ではない。数は支持、反対、作業意欲を可視化する。chairsは反論の質を判断する。リストは不在者を含める。Area DirectorとIESGは与えられた責任を果たす。どの層も他の代用品ではない。

Heng Luの出席をマンデートに変えることへの批判は、ここでは用語上の歯止めとしてのみ使える。参加は証拠、専門知、警告、異論をもたらすが、自動的に最終権限にはならない。会場を証拠として正確に尊重すれば、スコープ反対も、相互運用性への期待も、後の公式判断に消されず残る。

設問・文面対応表

第一欄は安定した設問番号と全文、その設問が知らせる制度判断。次に、表示されたチャーターのcommitとblob、時刻、収集方法、yes/no/no opinion、総回答数、非拘束性を置く。

解釈欄には、曖昧だった語、個人を特定しない反対理由の類型、「正しい」と「完全」の区別、修正対象条項、支持に付いた条件を置く。安全な集計が作れなければ、個人別クロス表はunknownのままにする。

権限欄には、リスト確認期間、関連スレッド、chairsの理由付き判断、異論処理、Area Directorの措置、IAB助言、IESG決定、最終チャーターの不変コミットを置く。決定前は明示的nullにする。訂正は以前の状態を消さず、日付付きで追加する。

現在のAgentproto行は、問題価値・相互運用性・IETFという場に強い支持、初期スコープに支持なし、成果物に分裂、執筆意欲あり、リスト調整中、最終チャーターなし、と示すだろう。単純な緑信号よりはるかに役立つ。

反論と証拠の限界

表が多数決を誘う危険はある。対策は割合を判定欄にせず、chairsの理由、未解決異論、権限状態を同じ重さで示すことだ。不変版が議論を凍結するという反論には、版を残すからこそ変更を正直に説明できると答えられる。

個人回答の公開は不要であり、プライバシーと率直な参加を損なう。運用負担も最小にすべきで、既存の議事録、commit、リスト、Datatrackerイベントから表を作るべきだ。後から手作業で歴史を復元しなければならないなら、現在の記録が既に分散し過ぎている。

本稿はAgentprotoを設置すべきか判断せず、session protocol、interaction reference、frameworkなどの技術選択もしない。MCPやA2A等の実装評価でもない。計数誤り、悪意、操作、手続無効を示す証拠はない。誰がどう答えたかも分からない。議事録は草案、メールとPRは提案、Datatrackerは将来変わり得る。

確認できることは狭い。「このチャーターで」という統合設問が支持され、その明示的構成要素である初期スコープは支持されず、その後も実質的な境界論争が続いた。設問、文面、後の権限を一緒に残せば、プロセスは矛盾を隠さず前へ進める。

情報源

  1. Heng Lu — The Multi-Stakeholder Mirage
  2. IETF 126 — Agentproto BoF議事録
  3. IETF 126 — Agentproto議題 第01版
  4. IETF — IETF 126 Highlights
  5. IETF — Birds of a Feather at IETF 126
  6. コミットa9405f3…のAgentproto提案チャーター
  7. IETF Datatracker — Agentproto現行ページ
  8. RFC 5434 — Considerations for Having a Successful BOF Session
  9. RFC 2418 / BCP 25 — IETF Working Group Guidelines and Procedures
  10. Agentprotoリスト — Sussing out points of disagreement on the charter
  11. Agentprotoリスト — Proposed charter text: evidence requirements
  12. IETF ART area charters — Pull request 77