要約

  • ワークショップ概要はACPをAgent Communication Protocolと明記している。一方、OpenAIの発表欄はACPを展開していない。OpenAI自身の商取引資料からAgentic Commerce Protocolと読む根拠はあるが、これは資料に基づく推定であり、議題表からの引用ではない。
  • 二つは目的、保守主体、ライフサイクルが異なる公開成果物である。同じ略称だけでは永続的な識別にならない。
  • 記録には、正式名、仕様・リポジトリURI、参照版、管理主体と意思決定の場、ライセンスと参加経路、状態、その成果物についての主張、そして支持・同一性・採用を意味しないという限定を一組で残すべきだ。

一方は明記され、もう一方は文脈に委ねられた

W3CとGS1は2026年9月8、9日、チューリヒでハイブリッド形式の E-commerce for Humans and AI Agents ワークショップを開く。参加案内によれば、目的は実装経験の共有、共通課題の抽出、標準化の機会と今後の可能性の検討である。つまり、議題は検討材料の一覧であって、W3Cが承認した技術の一覧ではない。

概要ページにはMCP、UCPと並んで ACP（Agent Communication Protocol） が記され、その名称から当該プロジェクトのサイトへリンクされている。ここでは正式名と行き先が揃い、参照対象を再現できる。

詳細日程には別のACPが現れる。OpenAIのRiley Strongによる「Progressive Enhancement: Evolving the Web for Agents and Commerce」は、「ACPでの経験」を踏まえると説明されている。正式名もリンクもない。ただし、OpenAIの公式な商取引発表と、Stripeと共同で維持するプロジェクトは、ACPを Agentic Commerce Protocol の略として使う。講演テーマ、所属、一次資料を合わせれば、その意味である可能性は高い。それでも、議題表自体がそう定義したわけではない。公開記録では根拠付きの推定として示す必要がある。

主催者や登壇者が二つを取り違えたとする証拠はない。確認できるのは、三文字だけでは参照先を保存できないという点である。

技術の優劣を論じる前から別の成果物である

Agent Communication Protocolは、エージェント、アプリケーション、人の間のやり取りをREST型のインターフェースで扱う。公開文書は、同プロジェクトが現在Linux Foundationの下でA2Aに合流したと説明する。リポジトリにはOpenAPIの記述とApache-2.0ライセンスがある。統治上の要点は、どの成果物を見たかだけでなく、移行後にどの場が変更を受け持つかである。

Agentic Commerce Protocolは、購入者、AIエージェント、事業者の間のプログラム可能な商取引を対象にする。リポジトリはOpenAIとStripeを保守主体として挙げ、仕様をベータとし、日付で版を区切っている。証拠を確認した時点では、最新の安定版は2026-04-17と表示されていた。こちらもApache 2.0だが、ライセンスが同じでも、目的や意思決定主体が一つになるわけではない。

本稿は両者を順位付けせず、互換性や非互換性、代替関係も断定しない。範囲、保守、状態が違うだけで、記録上の論点は成立する。「ACP」からは目的も版も変更窓口も復元できない。正式名さえ、プロジェクトの移行やリポジトリの移転、仕様更新を経れば時間の座標を失う。

会話の省略を公文書に持ち込まない

会場では共通の文脈が略称を補う。後から読む標準化関係者、技術者、調達担当者、規制当局、研究者には、その文脈がない。発表名が議事要旨へ移り、要旨が将来のチャーター議論に引用され、分科会の「ACPを検討した」という一文が制度的な支持の証拠として使われることもある。転記のたびに元の対象へ戻る手掛かりが減る。

これは引用表記だけの問題ではない。片方では日付が安定版を固定し、もう片方では移行告知が作業の帰属先を変える。略称しか残らなければ、主張が別のリポジトリへ結び付けられ、ベータ仕様が確定済みと読まれ、登壇者の実装経験が機関の立場へ膨らむおそれがある。

W3C Process Documentは段階を明確にする。ワークショップは関心を集める場である。関心が十分ならチャーター案が作られ、Membersの審査を経てグループが承認される。したがって、外部プロトコルが議題に載っただけでRecommendation過程に入ることも、作業部会が成立することも、採用が決まることもない。

八項目のプロトコル識別子

中央登録制度を作る必要はない。最終議題、発表索引、分科会記録、総括文書でプロトコルに触れるたび、次の八項目を添えればよい。

  1. プロジェクトが使う正式名
  2. 仕様またはリポジトリの正規URI
  3. 実際に参照した版、公開日、あるいは不変のコミット
  4. 保守主体と変更を決める場
  5. ライセンスと公開参加経路
  6. ベータ、公開済み、移行済み、廃止済みなどの状態
  7. その成果物について述べた正確な内容
  8. その参照からは支持、同一性、採用を結論できないという明示

これは略称を割り当てる「登録簿」ではない。どちらが正統かを裁定せず、中央の許可も求めない。人が読む呼び名を、ある時点の検証可能な成果物へ結ぶだけのプロトコル識別子である。

今回なら、概要ページがAgent Communication Protocolへ明示的にリンクした事実と、OpenAIの議題欄がACPを未解決のまま残した事実を分けて保てる。編集者がAgentic Commerce Protocolを補う場合は、OpenAIの資料を根拠として併記し、推定であることを示す。会合前に議題が更新されたなら、以前の曖昧さを消すのでなく、いつ明確化されたかを残せる。

発言者と制度を分ける

ワークショップ文書には異なる四つの層がある。登壇者が実装経験を報告する。プロジェクトが自らの仕様を説明する。参加者が今後調べる論点を挙げる。後日チャーターされたW3Cグループが承認範囲内で決定する。話者と権限は同じではない。

対象が確認されれば、「OpenAIがAgentic Commerce Protocolの利用経験を発表した」は正確な記録になり得る。「ワークショップが同プロトコルを支持した」は現時点の資料が支えない。概要にAgent Communication Protocolが載ることも、GS1の採用やW3Cの選択を示さない。

識別子があれば、リポジトリを示しても認証とはせず、経験を記録しても合意を捏造せず、標準化の可能性を記しても決定済みとはしない。この小さな区別が、後の統治判断を軽くする。

出典