要約

  • W3C Teamは8月10日、Immersive Web Working Groupの憲章案のrefinementを開始した。公開討議先としてstrategy issue 564を示す一方、W3C Membersは会員限定のw3c-ac-forumでも討議できるとした。
  • W3C Process 4.2は、憲章案に対して提出されたすべてのissueを正式に扱い、その解決をdisposition of commentsで追跡し、consensusで解決しなかった問題を明示するよう求める。
  • 公開issueには、security reviewerによるblocking comment、それに対応するPR 862、APAの照会とPR 865が残る。8月30日時点で両PRはopenで、mergeされていなかった。
  • Member-only情報の機密性は尊重されなければならない。Process 7.2と7.3は非公開情報の保護を定める一方、必要な情報を合理的に伝える無記名の公開版を、権限を持つTeamが作成できる余地を置く。
  • 共通記録には、問題類型、対象版と条項、応答、公開diffまたは変更しない理由、consensus状態、次の権限行為、訂正・承継履歴を載せればよい。氏名、非公開原文、投稿数、再識別につながる事業情報は不要である。
  • 公開コメントは証拠や専門知を提供するが、AC Reviewの投票でも「市民」の包括的委任でもない。refinement、Team Decision、AC Review、W3C Decisionは別の権限段階である。

二つの窓口が示すもの

8月10日のnoticeは、参加経路を曖昧にしていない。公開のstrategy issueで早期討議を行い、Membersは会員限定リストでも話し合える。Chartering Facilitatorは一人で、refinementの終了見込みも9月7日前後という一つの期間として示された。入口は二つでも、処理される制度上の対象は一つである。

公開経路には、行番号を示し、差分を提案し、後から議論を検証できる利点がある。限定経路には、未公表の実装計画、契約上の制約、取引関係に影響する評価など、公表を前提にすれば提出されにくい情報を扱う役割があり得る。

したがって、限定経路の存在だけで「密室」と評価する根拠にはならない。逆に、公開GitHubを飾りとみなす根拠にもならない。問うべきなのは、同じ憲章本文に接続する二つの入力が、処理後にどのような公共状態を残すかである。

接合すべきなのは原文ではなくdispositionである。非公開通信は非公開のままでよい。それでも、ある安全な問題類型がどの条項に関係し、どの権限主体が応答し、公開本文が変わったか、あるいは変えない理由が示されたかは記録できる。

公開issueは処理単位の違いを見せている

issue 564は最終報告書ではないが、良い処理記録が何を保存すべきかを具体的に示す。

security reviewerは、各仕様がsecurityとprivacyの含意を扱う「sections」を持つという草案の文言と、現行テンプレートの「separate sections」との違いを指摘した。コメントをblockingとし、文言を揃えることを解消条件にした。応答者はPR 862を作り、レビュー側は「PRがmergeされれば解決とみなす」と述べた。

ここには、指摘、応答、提案差分、解消条件という四状態がある。締切時点でPRはopenかつunmergedだった。修正案が存在することと、修正済みであることは同じではない。一方で、未mergeであることをもって無視されたとも言えない。

APAからの照会は別の構造を持つ。plane detectionとmesh detectionの重複、WebGPUへの移行時期とWebGLの扱い、CSS Spatial Layoutやhapticsがdeliverableではなくcoordinationに現れる理由など、複数の確認が一つのコメントに含まれた。応答とPR 865の後、APAは当初の質問には答えが得られたとしたが、さらに「detection」「tracking」「sensing」の命名整合性を問うた。

全体を「APA承認」か「APA反対」の一語に落とすと状態を失う。いくつかの質問は回答済み、差分は未merge、別の命名論点は継続中だった。処理記録はissue全体より細かい単位を持たなければならない。

表示された14 commentsも、支持者14人や論点14件を意味しない。一人が五つの問いを出し、複数人が一つの文言を詰めることもある。活動量を代表性や投票数に置き換えてはならない。

Processが要求するのは人気ではなく処理である

W3C Processでは、Teamが公開草案、参加方法、28日以上の予定期間、Chartering Facilitatorを示してrefinementを始める。期間中にwide reviewを完了し、Facilitatorは参加者の間でconsensusを探る。consensusが得られない場合、Team Decisionを求めることができ、その理由を文書化しなければならない。

そして、草案に提出されたすべてのissueは正式に扱われ、その解決をdisposition of commentsで追跡し、consensusで解決しなかった問題を強調する、と定める。

これは「話し合った」という事実より強い。入力が応答と解決状態につながることを要求するからだ。ただし、「受け取った文章をすべて公開せよ」とは異なる。Processは、処理を求めながら自らの機密区分を消してはいない。

予定期間の終了前に、TeamはAC Reviewを始めるか、提案を断念するか、期間を延長するかを決める。必要な可視性で発表し、AC Reviewに進まないときは理由も示す。これがrefinementの次状態となる。

AC Reviewは別の手続である。各Member organizationはAC representativeを通じて一件のreviewを提出し、その段階のdissentはFormal Objectionとして表現される。refinement中のGitHubコメントはそのreview票ではない。限定リストの発言も、自動的に後のFormal Objectionになるわけではない。

機密性と公開状態は両立する

Process 7.2はpublic、Member-only、Team-onlyを区別し、限定情報へのアクセス権を持つ者に秘密保持を求める。メールを転載し、発言者を名指しし、文脈から企業を推定できる要約を出すことは、透明性ではなく境界違反である。

同時に7.3は、公共性の高いprocessでは意思決定に影響する情報が公開されることの重要性を認める。機密区分を変更できるのはTeamまたはTeamが認めた者だけで、原著者が公開版を用意していない場合でも、必要事項を合理的に伝え、元の機密性を尊重した無記名版を作れる。

この規則から、最小限の共通層を設計できる。たとえば「Member-only issue class M-03：deliverableのscope boundary」とだけ公開し、対象条項、対象commit、公開本文の変更有無、処理状態を示す。誰が述べたか、何社が関与したか、どの製品が背景にあるか、限定リストの言い回しは載せない。

問題類型そのものが発言者を推定させる場合は、さらに抽象度を上げ、公開できるProcess状態だけに戻るべきだ。「集約」と名付ければ再識別リスクが消えるわけではない。

本稿は、この憲章案についてMember-onlyの意見が実際に存在すると主張しない。窓口が案内されたことと、利用されたことは別である。空欄を埋めるために架空の非公開論点を作ってはならない。

参加と権限を同じ語で包まない

公開参加には実質的価値がある。Processは、group participantsだけでなく、他組織や一般公衆が示す正当な見解や反対も考慮するよう求める。アクセシビリティ、security、privacy、internationalization、architectureの専門家は、憲章の欠落や曖昧さを具体的に示せる。

しかし、専門知を提供したことは包括的な委任を生まない。意見の力は「stakeholder」という肩書ではなく、理由と証拠、そして指摘された影響に由来する。

refinementではFacilitatorが参加者間のconsensusを求める。TeamはProcess上の判断を担い、AC Reviewへ進むか、延長か、断念かを決める。ACはMemberごとの正式reviewを行い、その後にW3C Decisionがある。

共通記録は、公開可能な場合に入力元を示しつつ、必ず「誰が応答したか」「どの権限段階で閉じたか」を記すべきだ。そうすれば、投票権がない公開reviewを無意味にせず、同時に公開参加を無限定な人民主権に見立てることもない。

共通のdisposition recordに必要な項目

共通層は、どちらの討議記録よりも薄くあるべきだ。第二の議論庫ではなく、状態索引だからである。

各issueまたは安全なissue classについて、次を記録する。

  1. 表題が変わっても残る識別子。
  2. publicかMember-onlyかという出所区分。ただし限定側の人数や身元は記さない。
  3. 公開可能な問題要旨。
  4. レビュー対象のcharter sectionと固定commit。
  5. 応答した役割と日付。
  6. 公開PR、diff、代替文、または変更しない理由。
  7. accepted、partly accepted、no change、superseded、withdrawn、deferred、unresolvedなどの処理。
  8. consensusで解決したか、Process上明示すべき未解決状態か。
  9. 追加refinement、Team Decision、AC Review、延長、断念のいずれに進むか。
  10. 終了時刻、後継イベント、訂正履歴。

出所区分を重みとして使ってはならない。Member-onlyだから公開の技術reviewより上位とは限らず、publicだから代表性が高いとも限らない。区分はアクセスと保管を示し、決定の説得力は理由と手続から生まれる。

固定commitは不可欠である。PR 862が条件を満たすのは、その文章が実際に前進する憲章版へ入ったときだ。openなpatch、merged text、approved charterは三つの異なる状態である。

この指摘が意味しないこと

8月30日時点でissue 564と二つのPRはopenで、2026年憲章はdraftだった。Working GroupはW3Cページ上、9月25日までの現行憲章の下にあった。

これは遅延、違反、技術的欠陥を証明しない。refinementは未決コメントやpatchを扱うための段階であり、9月7日は概算だった。Processは正式な延長も認める。状態は本稿後に変わり得る。

directoryのprivacyリンクは機密性という本稿の文脈を示すだけで、W3C、Immersive Web Working Group、WebXRそのものを指すものでも、賛同を意味するものでもない。

提案は限定的である。二つの意見窓口を残し、それぞれのアクセス規則を守りながら、一つの憲章の処理系譜を検証できる最小状態を公開する。

情報源

  1. W3C — Immersive Web Working Group憲章案refinement開始、2026年8月10日
  2. W3C — Immersive Web Working Group憲章案
  3. w3c/strategy issue 564 — Immersive Web WG 2026 Group Charter
  4. w3c/charter-drafts PR 831 — 2026年IWWG初期草案
  5. w3c/charter-drafts PR 862 — coordination文言のテンプレート整合
  6. w3c/charter-drafts PR 865 — specification説明のabstract整合
  7. W3C Process Document、2025年8月18日
  8. W3C — Immersive Web Working Group
  9. W3C — 2024年9月の現行Immersive Web Working Group憲章
  10. w3c/charter-drafts — 2026年草案のcommit履歴
  11. w3c/charter-drafts commit 488587ec141b — DRAFT表示
  12. W3C — Horizontal Review
  13. Heng Lu — On the Multi-Stakeholder Mirage
  14. Heng Lu — On the Reality Layers of Internet Governance