要約

  • W3C Processは、覆された決定がすでに結果を生んでいれば、十分な緩和を適時に実施し、それまでは異議の認容部分を完全に処理したとみなさない。ところが、責任者、権限、受入基準、証拠、完了宣言を載せる統一記録は定めていない。
  • Vibration APIでは実際のフォローアップがあり、実装報告も後に完了した。問題は不作為ではなく、Council Report、仕様issue、憲章issue、pull request、戦略審査を横断しても、Process上の完了を示す権威ある一点が見つからないことだ。
  • Councilの拘束力のない提案と、正当な決定主体が採用した緩和策を区別し、認容理由ごとに担当、既存権限、期限、証拠、日付入り完了を結ぶ「Council緩和管理記録」を設けるべきである。

裁定は決定を止めても、現実を巻き戻さない

W3C Councilは、通常の合意形成とTeamによる調整で解消できなかったFormal Objectionを扱う。Councilの中心的な仕事は明快だ。異議の対象となった決定を維持するか、覆すかを判断する。決定を覆す根拠になった異議の部分は認容されたものとなる。

しかし、制度上もっと難しい作業はその後に残る。

覆された決定がすでに公開文書、仕様の段階、憲章上の作業、その他の制度行為に結果を残していれば、Councilは緩和方法を提案すべきだとProcessはいう。Teamは、責任主体が十分な緩和を適時に実施するよう確保する。認容部分は、それが済むまで完全に処理されたとはみなされない。

つまりCouncil Reportが出ても、未完了の制度状態が続く。決定の根拠が消えても、公開済みの文言や作業の依存関係は自動では消えない。

同時にProcessは、権力の拡張を厳しく制限する。Councilの具体的提案は技術命令ではない。Teamには文書を「未公開に戻す」ような新しい権限は生じない。ワーキンググループは通常の合意手続で解決策を決め、議長やTeamも従来の権限の範囲で動く。Councilが恒常的な仕様編集者になるわけではない。

この分業は妥当である。だが、欠陥を認定する者、修正内容を決める者、放置を防ぐ者が異なる。引継ぎを共通記録にしなければ、どの行為が何を終わらせたのかが見えなくなる。

「十分」「適時」「完全」には判定の痕跡が要る

十分な緩和とは、単にissueが動いたことではない。Councilが認容した各論点に対して、どの既存結果が問題で、どの措置がそれを変え、何が効果を示すのかを対応付ける必要がある。

適時性も、一律の締切を意味しない。文書の表現修正と、複数実装を含む技術的再設計には異なる時間が要る。それでも、個別の目標日、次回レビュー日、遅延理由は示せる。

「完全に処理」は終端状態である。引用されたProcess条項は、その判断者、公開場所、異議申立人への通知、後日の訂正方法を定めない。終端を定義しながら、その状態遷移を証明する手続がない。

判断を機械化する必要はない。むしろ文脈依存の判断だからこそ、誰がどの権限と証拠で判断したのかを残さなければならない。

Vibration APIでは作業の多さが記録の不足を際立たせた

2024年後半、Advisory Committee ReviewはVibration API（Second Edition）RecommendationをObsolete Recommendationにする提案を扱った。二つのFormal Objectionが提出された。Devices and Sensors Working GroupはTPAC 2024で文書を後退させ、新しいCandidate Recommendation Snapshotとして作業を続ける方針を採った。一件は解決し、残る一件がCouncilに送られた。

2025年8月10日、Councilは残った異議を認容した。報告書は、対象文書がすでにCandidate Recommendation Draftであり、引用されたProcessの下ではその状態をObsoleteにできないと説明した。Working Groupは懸念に対応しながら作業を継続するため、すでにCandidate Recommendation Snapshotへ後退させていた。

Councilは最終的な技術解を命じなかった。通常の出版手続を続け、issue 33で現在の実装経験を文書化し、次の再憲章時に具体的な計画と説得的な理由を提示するよう勧告した。その計画は複数の主要ブラウザーエンジンでの出荷を含んでも含まなくてもよいが、審査者が妥当性を判断できる必要があるとした。

その後の作業は確認できる。issue 33は実装報告の作業を経て、2026年5月1日にcompletedとして閉じた。2026年Devices and Sensors憲章の記録はCouncil勧告を参照した。charter-drafts issue 781は公開計画と実装報告を追跡した。pull request 809は、単一エンジン仕様について憲章末までの明示的な進路を提案し、Vibrationについて第二実装がなければ状態を変える案を含んだが、マージされずに閉じた。憲章全体は別の修正やAC審査へ進んだ。

何も起きなかったわけではない。むしろ多数の行為のうち、どれがProcess上の完了を構成したのかが分からない。

先行する仕様の後退は緩和そのものだったのか、それとも暫定的な封じ込めだったのか。issue 33の完了は一つの認容論点を閉じたのか、次の判断材料を整えただけなのか。再憲章の計画は別の文言で満たされたのか、より良い合意案に置き換わったのか、まだ権威ある結論がないのか。

Council Reportは裁定と勧告を示す。Team reportは経緯を示す。仕様issueは一つの作業を、憲章issueは審査上の要求を、pull requestは提案文を、strategy issueは広い憲章過程を示す。どれも重要だが、どれも「完全に処理」の正式な台帳とは指定されていない。

したがって、開いているissueを違反の証拠にしてはならない。閉じたissueも制度的完了の証明にはならない。テキスト変更は行為の証拠であって、認容理由との対応付けがなければ十分性の証拠ではない。

issue 751が示した二つの誤り

W3C Processのissue 751では、Councilの勧告が拘束力を持つのか、他の合意に副作用を与えるのか、Teamに無限定な力を与えるのかが議論された。

公開コメントからは、二つの誤りを避けるべきことが分かる。第一は、Councilの提案を命令とみなすことだ。提案は拘束しない。責任主体は別の合意解を採用できる。第二は、提案が非拘束だから、覆された決定の結果も放置できるとみなすことだ。決定が無効になった以上、その結果を戻す、打ち消す、または緩和する必要があり、Teamは忘却を防ぐ。

Teamの役割は代筆ではなく追跡である。議論では、議長への督促、既存の議長任命権、移行要件を満たさない出版の停止、既定の後退・中止手続が例示された。Teamが仕様を書くことも、出版履歴を消すこともできない。

それでも読解上の摩擦は残った。ある参加者は、元の決定主体が再検討する流れをもっと明示すべきだと述べた。別の参加者は、Teamに渡った後に「魔法が起こる」ように読めると評した。現行文を擁護する側は、内容は正しく、あらゆる決定類型に適用するため一般化が必要だと答えた。issueは編集上の改善として延期された。

議論中の重要な原則は、異議申立人に数か月、数年の監視を強いてはならないという点だ。申立人に完了の拒否権を与えなくても、W3C自身が完了状態を公開すればこの負担は解消できる。

現行方式への最善の反論

一つの固定的な救済策をProcessに書くべきではない。Formal Objectionの対象はWorking Groupだけではなく、議長、Team、TAG、AB、憲章提案者の決定でもあり得る。常にWorking Groupへ戻す規則は誤配になる。

Councilを上位技術委員会にするのも危険だ。実装、特許、相互運用性を扱う責任主体が、Council案より良い解を合意できる余地は必要である。

またW3Cの公開リポジトリは相当に多くの証拠を残している。Councilの非公開審議、会員限定資料、個人投票、人事、法的助言には正当な秘密性もある。

これらは柔軟で薄い記録を支持する。状態を推測させる理由にはならない。公的証拠と非公開項目の境界を示せば、機密性と追跡可能性は両立する。

Council緩和管理記録の設計

既存結果を持つ決定をCouncilが覆した時、Council Reportと同時に版管理された緩和管理記録を開くべきだ。Teamが状態を管理し、各責任主体が自らの決定と証拠を追加する。

必要な項目は次の通りである。

  • Council Report、裁定日、適用Process版
  • 覆された決定と、認容された各論点
  • すでに生じた結果と影響対象
  • 緩和項目ごとの責任主体の制度上の役割
  • その主体が使える既存権限
  • 非拘束であることを明示したCouncil提案
  • 責任主体が採用、修正、または代替した対応
  • 依存関係、目標日または次回レビュー、現在状態、遅延理由
  • 緩和待ちで止められている出版、昇格、憲章行為
  • 認容論点ごとの受入基準と証拠
  • 守秘範囲内での申立人と元の決定主体への通知・協議
  • 十分性を判断できる権限者
  • 日付入りの完全処理宣言、または未宣言の明記
  • 訂正、後続決定、appeal、新たなFormal Objection
  • 公開情報と制限情報の境界と理由

この記録はCouncil案を強制しない。Working Groupが別案を採った場合、その案が同じ論点をどう解決したかを示せばよい。新しいappeal制度も作らない。実施のための新決定に異議があれば、通常の手続を使う。

記録がもたらす最大の変化は、進行と完了を分けることだ。会合、issue、patchは進行の証拠である。受入基準に照らした証拠と権限ある宣言が、完了の証拠になる。

証拠の限界

公開資料から、W3CがVibration案件で内部期限に違反した、緩和が現在も不十分だ、または特定の人物がCouncilを回避したとは言えない。issue 33の完了も、issue 781が開いていることも事実だが、いずれも単独ではProcess上の終端を決めない。

pull request 809が未マージで閉じたことは、内容上の否決や代替計画の不存在を意味しない。2026年憲章の後続論争にはVibration以外の論点もあり、2025年の対応を非難する証拠へ遡及的に変換すべきではない。

確認できる欠落は制度設計上のものだ。W3CはCouncil後に続く状態を定義しているが、その状態を公的に完了まで運ぶ単一記録を義務づけていない。

出典

  1. W3C Process 2025年8月18日版 — Council後の緩和
  2. 現行W3C Process Editor’s Draft — 緩和
  3. W3C Process issue 751 — Council decision side effects
  4. W3C Guide — Formal Objections & W3C Council
  5. Vibration API Formal Objection第2回Council Report
  6. Vibration API Formal ObjectionのTeam report
  7. Vibration issue 33 — 実装報告の更新
  8. charter-drafts issue 781 — Councilが勧告した計画
  9. strategy issue 530 — Devices and Sensors Working Group 2026 Charter
  10. charter-drafts pull request 809 — 仕様別計画案
  11. W3C Guide issue 173 — deciderとは誰か
  12. W3C Process issue 1029 — Council Reportの公開時期
  13. Heng Lu — The Multi-Stakeholder Mirage
  14. Heng Lu — On the Agency Problem at the Core of Internet Governance