IETF-W3C

HTTP/2 Rapid Resetは、プロトコルの合法的な動作が、実装の資源管理と運用上の防御の弱点を通じて、複数の組織にまたがるサービス停止リスクへ変わった事例である。問題を見つけ、脆弱性を記録し、標準を見直し、ベンダーが修正を出すことは重要だ。しかし、それぞれは修復の別々の段階にすぎない。実際の露出が閉じたことを示すには、利用中の実装、パッケージ、設定、展開状況を確認しなければならない。

IETFとW3Cを結ぶ公開記録は、標準化とWeb技術をめぐる協力の歴史を示す。しかし、その関係を一つの法人、共通の管理主体、または統一された責任経路として読むことはできない。問題は、協力が存在するかではなく、どの文書がどの権限を示し、異議申立てや責任追及を誰に向けるべきかである。

TLSの再ネゴシエーション問題は、単なる古い暗号方式の欠陥ではなかった。同じ接続上で続けて行われるハンドシェイク同士を暗号学的に結び付ける仕組みがなかったため、攻撃者が先に置いたアプリケーションデータの前に、別の利用者の認証コンテキストを接続できた。RFC 5746はその境界を修復し、TLS 1.3は再ネゴシエーション自体を廃止した。しかし、仕様の公開は、稼働中の全経路が修復済みだという証明ではない。

IETFとW3Cはしばしば一つの標準化インフラとして語られる。しかし、両者の意思決定を同じ制度として扱うと、誰がどの権限を持ち、どの文書がその権限を与え、異議申立てがどこまで届くのかを見誤る。IETFでは標準化プロセス上の役割と、行政・法人上の責任が分かれている。W3Cでは技術的な決定手続きがProcess Documentに定められる一方、参加条件や組織上の義務は会員契約や法的文書にも依存する。

IETFの標準はネットワークを直接運用しない。それでも、QUIC、HTTP/3、DNSSEC、BGP、PIM-SMのような仕様が実装されると、接続の維持、経路の回復、名前解決の検証、マルチキャストの到達性は、標準文書だけでは完結しない複数の運用主体に分散する。問題は、仕様が存在するかではなく、障害時にどの主体が状態を戻せるかである。

匿名のアンケートだからこそ、率直に書けることがある。W3Cが新たに始めた会員向け調査と広いコミュニティ向け調査は、いずれも回答を匿名と説明する一方、後日のインタビューを希望する人にメールアドレスの記入を促している。回答とのひも付けが起きた証拠はない。しかし、ひも付けられない仕組みも公開画面からは分からない。今必要なのは疑いではなく、分離を検証できる短い説明だ。

W3CがRecommendationにしたWebAuthn Level 3には、4種類のブラウザーを並べた固定テスト報告が付いている。移行記録はさらに、Chromeの実装の一部がEdgeと異なると注記した。違いを認識した点は重要だが、「一部」がどの機能、どの層、どの結果を指すのかは公開記録から追えない。

8月11日版の *ARIA in HTML* 勧告は、2026年3月22日を「最終更新」とする実装報告を参照している。しかし公開リポジトリでは、5月20日に大規模な更新が入り、27日にも同じファイルが修正された。3月が実装状況の基準日で、5月が文書の改訂日なら両方とも正しい。問題は、一つの表示が二つの時刻を兼ねていることだ。

人とAIエージェントの電子商取引を扱うW3C・GS1共同ワークショップでは、複数の新しいプロトコルが同じ議題に載る。その公開ページは、すでに小さな来歴問題を映している。ACPという略称が、別々の公開成果物を指しているのだ。発表が結論や今後の作業候補へ移る前に、名称、版、管理主体を結ぶ短い識別情報を残すべきである。

別々の二者が同じ評価を走らせ、同じスコアに到達する。それは自律エージェントの試験を検証可能にする重要な一歩だ。8月30日に発足したW3CのAgent Conformance and Benchmarking Community Groupも、この状態を成功基準に掲げる。ただし、一致した数値が証明するのは手順の再現性であって、測定対象の妥当性や、その値を使って他者を拘束する権限ではない。

新しい技術を扱えることと、その技術を標準として届けることは同じではない。9月1日に発効したWebTransport Working Groupの憲章は、P2Pを検討対象に加えながら、規範的な成果物としては別掲しなかった。この慎重な空白こそ、実験と制度上の決定を見分けるための基準になる。

W3Cの水平レビューでは、中央の憲章案件から各専門グループのリポジトリへ通知用Issueが自動生成される。APAは、その複製が自分たちには二重作業になるとして停止を望んだ。一方、Privacy側はローカルIssueを実際に使っているという。問われているのはレビューの要否ではなく、異なる作業方法を一つの検証可能な状態へどう接続するかである。

TPAC 2026で予定される「Data Governance & Ownership」ミニワークショップは、何が壊れているのか、Web標準は次に何を担うべきかを問いかける。同時に、もう一つの権限を主催者に残している。テーマが重なる場合、提案者に「AI and Society」「Age Assurance」または独立したbreakoutへの再提出を求められるというものだ。重複を避ける合理的な編集である一方、誰が提案を聞き、どの証拠と並べられ、予定されるW3C文書へどう入るかを変える。経路は記録されるべきだが、標準化の決定に格上げしてはならない。

W3Cが現行として示すAccessibility Guidelines Working Group憲章の終了日は2026年8月28日である。その4日後、9月1日の公開議事録案は、WCAG 3の更新を受け入れる決議と、審議した文書を凍結する方針を記録した。ここから「無権限だった」とは言えない。延長がなかったとも言えない。確認できるのは、公開された権限の時計と公開された作業の時計を結ぶ記録が見当たらない、という一点だ。

Linked Web Storage Working Groupの再設置を扱うW3Cの公開Issueには、実質的な変更はないと記されている。しかし同じ記録は、最初の工程表が楽観的すぎたこと、今度は2026年第4四半期または2027年第1四半期のCandidate Recommendation到達後に保守へ移る意向を示す。ところが8月5日の固定版チャーターには、成熟度を選ぶ指示、日付のない五つの成果物、架空の仕様名とFooMLの工程が残る。期限前の作業中ドラフトである以上、違反ではない。問うべきは、範囲の継続という説明がいつ審査可能な文書になるかだ。

金曜日までに異議がなければ5仕様、異議があればWeb Serialだけ――WHATWGのSteering Groupは、新しいPeripheral APIs Workstreamの発足範囲をこの条件で決めた。ところが参照先のW3Cでは、期限内にIntelが5 APIの削除に明確な懸念を表明していた。WHATWGはその懸念を認めた上で「異議なし」の条件を満たしたと記録し、5仕様を登録した。翌週、W3Cは懸念が出たため削除案に合意がなかったと発表した。矛盾を断定する材料ではない。別組織の手続結果を条件に使うなら、懸念を異議として数えるのかという変換規則まで公開すべきだという事例である。

締切は決定を終わらせることができる。しかし、発言しなかった人の賛成まで作り出すことはできない。W3C Math Working Groupの2026年憲章は、会議で採択した決議をいったん暫定扱いとし、1週間の合意形成要請（CfC）にかける。異議がなければ作業部会の合意とみなす一方、上位にあるW3C Processは沈黙を棄権と定義し、合意には相当数の支持も求めている。両方を残す記録が必要だ。

推論エンジンはためらわない。データがあるプロファイルに適合し、そのプロファイルが上位仕様のプロファイルであるなら、データは上位仕様にも適合する――W3Cの新しいProfiles Vocabulary草案は、その結論をRDFの関係として導けるようにする。ところが、人間が「その適合は何を証明するのか」と尋ねると、答えはまだ一つではない。公理はat riskで、適合の定義は各コミュニティーに委ねられ、公開されたTurtleには公理がなく、機能別の実装証拠表も未完成だ。

「10%を無作為に確認した」と聞けば、多くの人は製品全体の10%を想像する。2026年7月23日に公開されたWCAG-EM 2.0で、分母はそこではない。無作為サンプルは、評価者が先に組み立てた構造化サンプルの10%である。この短い数字から分母が落ちれば、見落としを検出するための補助的な統制が、製品全体を10%検査した証拠へと姿を変えてしまう。

同じ「7点」でも、中身は六通りある。人への効果が高く、地球への効果が低く、繁栄への効果は不明で、短期に現れるもの。三つの効果がすべて中程度で、長期に現れるもの。W3Cの新しいWeb Sustainability Guidelines（WSG）影響評価では、どちらも同じ数字になる。計算は明快だが、意思決定に必要な違いは数字の外に残される。

W3Cで公開中のWeb Machine Learning Working Group憲章修正案は、AI関連の成果物を一つ足すだけの変更ではない。JavaScript関数をブラウザー向けツールとして登録する仕組みと、HTMLフォームをエージェントに発見させる宣言的な仕組みを、同グループの作業範囲に置こうとしている。一方、同じ差分は、憲章が実名で挙げる技術調整先を更新していない。Strategyの議題はHTML、ARIA、アーキテクチャー、セキュリティー、プライバシーのレビューを求め、公開討議も進んでいる。欠けているのは参加そのものではなく、各レイヤーの責任者、連絡経路、未解決意見の処理先を結ぶ帰属可能な地図である。

W3Cの次期WebRTC憲章に対する未マージの修正案が、草案で一つにまとめられていた三つの判断を切り分けている。WebRTC Identityは実装者の関心不足を理由に終了できる。SFrameは一部の利用場面と重なる。しかし、対向者の身元、意図した相手への拘束、ブラウザーが強制するメディア隔離まで引き継いだことにはならない。セキュリティレビューに答えた共同議長も、両技術は代替関係になく、当該特性を継ぐ成果物はグループ内にないと認めた。必要なのは旧方式の無条件な存続ではなく、各特性の行き先を公開記録に残すことだ。

W3Cは8月19日、Security Interest Groupの新たな憲章案を公開し、文面を詰める段階に入った。案は外縁を明確にしている。IGは助言、レビュー、範囲内の文書作成を担い、Recommendation Trackに進む機会は権限を持つWorking Groupか、まずインキュベーションを担うグループへ渡す。ところが参加とコミュニケーションの条項には、実装者、仕様編集者、テスト責任者、仕様の公開ドラフトという役割が、どの文書種別に属するのかを示さないまま残る。これは修正可能な草案上の曖昧さであり、権限逸脱がすでに起きた証拠ではない。

W3CはWeb Performance Working Groupの新しい憲章を2028年8月まで承認した。そこで区別された二つの根拠は、ブラウザー標準を読む側にも重要である。複数の実装者が関心を表明することは機能を検討する理由になるが、独立した実装が同じオープンテストを通ることとは違う。前者を後者の実績として流通させない記録が必要だ。

制度文書の鮮度は、理念よりも時制に表れることがある。W3C Advisory Boardが8月4日に公表した人権に関するGroup Noteは、Threats and Harms Community Groupの設置を「適切かもしれない」次の一手として挙げた。しかしW3Cの別の公開記録では、そのグループは7月29日に5人の支持を得て発足済みだった。問うべきは人権の是非ではない。提案が現実のどこまで進んだかを、文書がどう保持するかである。

「未定」は失敗の言い換えではない。W3CのWeb Application Security Working Group憲章案は、17件の規範的成果物のうち16件について完了見込みを未定と明記し、残るFetch MetadataにもWHATWG Fetchへの統合という行き先だけを示している。問題は日付を作ることではなく、各未定を誰がいつ見直し、どの決定や依存関係が状態を変えるのかを公開できていないことだ。

Web Speech APIの次の制度的な受け皿が、W3Cの公開議題に載った。しかし、その権限を実際に与えるはずのAudio Working Group憲章案には、音声認識と音声合成を直接の対象外とする従来の文言が残る。これは採用決定でも拒否でもない。提案から権限へ移る途中の状態であり、その境界を消さずに記録する必要がある。

「WebDriver対応」という表示は、一つの固定した規格を指すように見える。ところがW3Cが審査中のBrowser Testing and Tools作業部会憲章案は、WebDriverとWebDriver BiDiをCandidate Recommendationまで進め、Snapshotを重ねながら継続更新し、Recommendationには進めない方針を明記する。動く仕様を採用すること自体が問題なのではない。問題は、仕様、試験、ブラウザー、ドライバー、クライアントのどの版が同時に動いたのかを残さずに「対応」だけを持ち運ぶことだ。