要約

  • W3Cは2026年8月20日にWebAssembly Working Group憲章を承認した。期間は2028年8月27日までで、既存仕様の改訂に加え、Code Metadataと三つのLegacy Extensions仕様を扱う。
  • Component Modelは条件付き成果物である。WebAssembly Community Groupの提案がPhase 4に達してから、Working Groupが規範仕様としての提供を目指す。
  • 8月10日付の固定された公開提案表では、Component ModelはまだPhase 1にある。この数字は制度上の現在地であり、技術の有用性を採点したものではない。
  • Component ModelのリポジトリはWASI Developer Preview 0.2.0、0.3.0、0.3.1を記録し、対象機能をツールが安定させ、ブラウザー外の本番環境で使いながらフィードバックを得る方針を示す。
  • Phase 4には複数実装、テスト、完全な仕様、参照インタープリター、Community Groupの合意が必要だ。その後もWorking Group自身の合意とW3Cの標準化手続きが残る。
  • 必要なのは「二つの鍵」を追える昇格台帳だ。提案の固定版と要件別証拠をCommunity Groupの判断に結び、Working Groupによる受領とW3C公開状態を別の判断として残すべきである。

新憲章は到着ではなく経路を承認した

承認通知は一段落ほどだが、実際の権限を定義するのは憲章である。開始日は2026年8月20日、終了日は2028年8月27日。議長、Team Contact、活動範囲、成果物、意思決定方法が記されている。

WebAssembly Core Specification、JavaScript Interface、Web APIの改訂は、最初から成果物に含まれる。Code Metadata Specificationも加わった。さらに、非推奨ではあるものの利用が残る拡張を切り分けるため、Core、JavaScript Interface、Web APIそれぞれのLegacy Extensions仕様を作る。

Component Modelだけは動詞に条件が付く。Working Groupは提供を「目指す」が、その前にCommunity Groupのフェーズ手続きでPhase 4へ到達しなければならない。候補から外されたわけでも、受け入れが済んだわけでもない。将来、入口条件が満たされたとき、誰が次の判断を担えるかを定めた条項だ。

この仕組みは2023年憲章にもあった。2026年の再認可はその経路を延長したのであって、三年間の活動量を暗黙の昇格に変えたのではない。憲章に名前があることは、W3C Recommendationになったことの省略表現ではない。

再現できる公開状態はPhase 1

WebAssemblyのproposalsリポジトリは、各提案の段階を一覧にする。この記事では8月10日のコミットに固定した。後で表が変わっても、判断時点の記録を再現できるからだ。Phase 5からPhase 1まで提案が分かれ、Component ModelはPhase 1欄に置かれている。

公開表は、議論の多さや製品発表から段階を推測するより強い証拠だ。ただし結論の幅は狭い。利用者がいない、開発が止まった、本番に耐えない、重要でない、という意味はない。公開されたこの手続きの下で、より高い段階として登録されていないという意味に限られる。

8月10日以降に会話や未反映の判断がないとも断定できない。新しい決定が公開されれば、日付と対象を明示して状態を更新すればよい。将来の昇格を理由に、当時のPhase 1を無意味だったことにしてはならない。

フェーズ番号は成績表でも開発進捗率でもない。Phase 1は、対象範囲に入り、筋のよい提案として、提案者が設計と合意を深める段階に入ったことを示す。ダウンロード数、投資額、仕様のページ数、実運用件数は測っていない。

Phase 4では証拠と権限が受け渡される

フェーズ手続きでは、次段階への移行をCommunity Group会合の議題に載せ、入口要件を満たしたかを同Groupが判断する。Phase 2では精密で完全な概要と相当高い合意、Phase 3ではテストスイートと実装作業が求められる。Phase 4のハードルはさらに高い。

適用可能な場合、二つ以上のWeb VMが機能を実装してテストに合格し、少なくとも一つのツールチェーンも実装する。仕様と参照インタープリターが完成し、インタープリターはテストに合格する必要がある。Community Groupは機能そのものと仕様の完全性の双方に合意しなければならない。

そこで初めてWorking Groupへ全面的に引き渡される。しかしWorking Groupは単なる承認印ではない。エッジケースを検討し、自らの合意を確認し、W3Cの標準化手続きを完了する。大きな変更が必要ならCommunity Groupへ戻す。Phase 5はWorking Groupが完成について合意した後であり、W3Cのスナップショットに取り込まれる。

この設計は二種類の近道を防ぐ。Working Groupは、憲章に候補があるというだけで初期案を成熟済みと呼べない。Community Groupも、自らの昇格判断だけでW3C標準を作れない。実装者は両者へ不可欠な証拠を供給するが、コードを出荷する行為自体はどちらの鍵も代行しない。

Phase 1と本番向けプレビューは両立する

単純な読み方に抗う材料はComponent Model自身のリポジトリにある。設計文書、バイナリー形式とテキスト形式、リンク、ABI、拡充中のテストに加え、WASI Developer Preview 0.2.0、0.3.0、0.3.1が里程標として列挙されている。

0.2.0はComponent Modelを基盤にした最初のプレビュー、0.3.0はネイティブな並行処理を追加し、0.3.1はさらに型とアノテーションを増やした。リポジトリは、有効にした機能をproducerとconsumerのツールが安定させ、ブラウザー外の本番用途で使いながら実地のフィードバックを集める、と説明する。

従って、Phase 1を「何もない」と読むのは誤りである。正式標準化より前に、限定されたプロファイルへ互換性の約束を与え、システムを動かし、運用から学ぶことはできる。

同じREADMEは、正式仕様と参照インタープリターを今後追加するとしている。工学的な進展が大きくても、Phase 4が要求する成果物と合意の全部が未完成であり得ることを自ら示す。選択した表面を安定させることと、提案全体を制度的に昇格させることは同じ仕事ではない。

逆方向の取り違えはもっと高くつく。本番採用はCommunity Groupの投票を行わず、参照インタープリターを完成させず、Working Groupへの移管やW3C Recommendationの公開も自動化しない。running codeは強い証拠だが、憲法上の委任状ではない。

Community Groupは小型Working Groupではない

W3CのCommunity Groupは、無償で参加できる初期協働の場である。W3Cアカウントを持ち、Community Contributor License Agreementを受け入れればWebAssembly Community Groupへ参加できる。公開ページには、Groupはコミュニティ自身が運営し、成果がW3C会員やスタッフの見解を必ずしも表さないとも明記される。

文書の地位も区別されている。Community Group Reportは標準化トラックの文書でもW3C標準でもないが、Working Groupへの入力にはなり得る。法的な合意と、対象範囲を持つ既存Working Groupは移行を容易にする。それでも「移しやすい」と「移った」は別だ。

この境界は両方の制度を守る。Community Groupは非会員も交えて素早く試し、重いRecommendation Trackの前に設計を洗える。Working Groupは成熟した成果を利用しながら、自らの合意、horizontal review、特許方針、公開の責任を果たせる。参加の広さは判断の質を上げるが、出席をそのまま委任へ変えてはならない。

一語の短縮が別の意思決定を誘う

状態表現は会議室の外で使われる。ベンダーが「Component Model対応」とだけ書けば、どのDeveloper Previewとコミットなのか不明になる。購入者は「W3C憲章にある」と聞いてRecommendation級の審査済みだと考えるかもしれない。エンジニアはPhase 1を見て、すでにツールが安定性を約束する限定プロファイルまで実験扱いするかもしれない。

これは言葉遣いだけの問題ではない。ABIやリンク動作を広く導入すれば、後の変更には移行コストが付く。新しい証拠が別設計を支持しても、既存配備を守る圧力が正式判断を狭める。その圧力は合理的な場合があるが、実装者から制度への見えない権限移転にしてはならない。証拠と切替費用として記録すべきだ。

一方、公開フェーズが既存証拠を表現できないままなら、利用者は何が未達かを確認できない。評判や非公開調整だけが「実際はもっと進んでいる」ことを説明する。よい記録は、現実の採用と未完了の制度昇格を同時に表示する。

二つの鍵を一枚の台帳で追う

新しい上部機関を作る必要はない。既存の状態をつなぐ薄い昇格台帳で足りる。

Community Group側では、変更不能な提案リビジョン、現在のフェーズ、直近決定の日時と記録、申請先フェーズの入口要件を置く。各要件は、具体的なWeb VM、テストスイートの版と結果、ツールチェーン、正式仕様、参照インタープリター、未解決例外へリンクする。「適用外」とするなら判断者と理由も残す。

意思決定欄には公開議題、方法、結果、記録された異議を含める。出席者数を全利害関係者の同意に読み替えてはならない。昇格対象がDeveloper Previewの一部だけなら、その境界を明記し、同じ名称の他機能を一括移管しない。

次にWorking Groupが受領したリビジョン、CfCなどの判断、孵化へ戻した論点、horizontal review、特許方針、実装報告、W3C公開状態を別欄で記す。大幅変更による差し戻しは新しい状態とし、過去の引き渡しを上書きしない。

私的な法的助言、製品計画、会議の全発言を公開する必要はない。二つの鍵がなぜ回ったかを説明できる最小限の制度事実と証拠があればよい。

8月31日時点で言えること

W3Cは現行のWebAssembly Working Group憲章を承認した。Working Groupは無条件の成果物に取り組め、条件が満たされればComponent Modelを受け取れる。公開提案表はComponent ModelをPhase 1に置き、リポジトリは実質的なDeveloper Previewとブラウザー外の限定的な本番利用を記録する。

確認資料から、Community GroupがPhase 4申請を拒否した、W3Cが遅延させた、実装者が手続きを迂回した、とは言えない。互換性欠如、安全上の欠陥、ベンダー支配、特許問題も立証しない。Component ModelがW3C Recommendationだとも言えない。

現在地は簡潔だ。技術は現実に動いている。正式な昇格は完了していない。新憲章は両者を結ぶ経路を保った。次に鍵が回るとき、追跡できる受領証が必要である。

出典

  1. W3C：WebAssembly Working Group憲章の承認通知
  2. W3C：2026年8月20日発効のWebAssembly Working Group憲章
  3. WebAssembly：2026年8月10日に固定した提案一覧
  4. WebAssembly：フェーズ昇格手続き
  5. WebAssembly：Component Modelリポジトリの里程標
  6. W3C：WebAssembly Community Group
  7. W3C：Community GroupとBusiness GroupのFAQ
  8. W3C：W3Cが公開する文書の種類
  9. Lu Heng：The Multi-Stakeholder Mirage