created_at
updated_at
tags
toc

Web 標準の議論を LLM-Wiki で追う

Intro

Web 標準の議論を長いこと追ってきたが、追えば追うほど、追うべきものは増えていく。

また、最新の情報を追うこと自体は比較的簡単でも、なぜそうなったのかといった経緯を過去にさかのぼって調べるのは、なかなか難しい。

これを LLM-Wiki を使うことで大幅に改善することができた。

標準化の議論

Web 標準はある日突然降って湧くわけではない。

然るべきところで誰かがアイデアを出し、それを長い時間かけて議論し、実装しながら仕様を詰め、フィールドトライアルし、完成品が開発者の手元に届く。

最初に誰かが出すアイデアにも、「こういう問題がある」といったきっかけがある。それが今までできなかった理由も、標準化していける理由も、それ以前の議論と線形に流れる文脈の上にある。その文脈の中で、否定され消えていったものもたくさんある。

追うだけなら完成品と API だけを見ればよい。しかし、「なぜこうなったのか」「アレは今どうなったのか」「なぜアレはダメでコレは良かったのか」などを含め高い解像度で理解するには、議論の経緯を追う以外の方法はない。

議論は、Mailing List や Chat で行われることもあれば、GitHub で行われることもある。オフラインやオンラインのミーティングで行われ、議事録が公開されることもある。

全部を追うのは無理なので、筆者は IETF, W3C, ECMA などを中心に、興味のある WG の議論を追うことで、なんとかキャッチアップしてきた。

細かい議論は追っているときは把握できても、どんどん忘れていってしまう。そこで「忘れるため」にまとめているのがこのブログだ。それも、興味の範囲のほんの一握りしかできていない。

常に触れていれば、ざっくりしたトピックへのフックは自分の中にある。しかし、改めて「で、今どうなってたっけ」を調べ直すのは、それなりのコストがかかる。

TC39 の追い方

JS 関連の仕様は、完成品であれば MDN などで API を把握し叩くだけで十分だ。書いてある通りに動くだろう。多くの人はそれで足りる。

しかし、「どうしてこういう API になったのか」などを知りたい場合は、ECMAScript の策定を担う TC39 の議論を追う必要がある。

各 API のリポジトリでも Issue の議論などはあるが、基本的には定期的に開催されている F2F のミーティングに議論が集約される。

その議事録は以下で公開されている。

かなりきちんと「文字起こし」に近い markdown の議事録が、2012-05 から積まれている。

ミーティングは 2 ヶ月ごとに実施され、1 ヶ月遅れくらいで議事録の PR が出される。

筆者は、この PR のタイミングで「TC39 の minutes を読む」という会を有志と X の Spaces で行い、議論を把握するように努めてきた。

TC39_minutes

最初のころは原文を読みながら、手で要約を書き、それに基づいて議論してきた。最近では NotebookLM などで要約を生成し、それを基に議論するなど運用はかなり変わっている。

同じトピックの継続議論の場合、「これって今どうなってたっけ?」は、この Docs やリポジトリを検索し、過去の該当する議論を振り返るといった形で振り返ってきていた。

本来話すのが 3 回目のはずのトピックを全く覚えていなかったり、前回とまったく同じことをもう一度調べることも少なくない。

本来、ミーティングに参加している Champion は、自分が担当している範囲に集中すれば良い。それを全部追おうとすること自体が無茶なのは、10 年以上前からわかっている。

それでも、知りたいと思ってしまったのだ。

LLM-Wiki

コストが高いまま続けると、疲れて辞めてしまう。

一度やめれば、そのまま引き離され、もう二度と追いつくことはできないだろうということは、ひしひしと感じている。

なんとか精度を維持したまま負荷を下げ、「(本来の意味での)さわり」だけでも抑えておきたい。

そこで LLM-Wiki を用いて AI の力を借りることにした。

LLM-Wiki は、Andrej Karpathy が提案した手法だ。

RAG などと同じく、既存の知識を整理し、活用するためのナレッジベースを作るフレームワークだ。

Obsidian の構築を AI に依頼するのに近いイメージで、雑に突っ込んだ論文やドキュメントを整理するといったユースケースがある。

今回は、これを TC39 の議事録に応用する。

といっても、この Gist の llm-wiki.md を Repo Root に置き、「これを実現して」と言うだけで AGENT.md などができる。

オリジナルの LLM-Wiki の前提と少し変わるため、コマンドはかなりカスタマイズして使っている。

TC39 LLM-Wiki

LLM-Wiki は、基本的に /raw に情報ソースを追加し、それを解析させることで既存の知識と結合させ、育てていく。

今回は、この /raw の中に、以下の関連リポジトリをまるっと投入した。

2012-05 以降全ての議論が残っている。議事録は、トピックごとに節立てて整理され、重要な決定事項があれば記録されている。非常に質の良いソースだ。

仕様ごとの細かい Issue/PR が個別のリポジトリで運用されていても、それを定期的にここでまとめており、特に重要な点のみが議論されるため、非常に高品質に圧縮されている。

これが残っている時点で、もう勝ったも同然だ。AI があっても、これがなければ苦労することになる。

「古い議論を残しておいたって、誰も見やしない」などと切り捨てず、すべての議論をきちんと残してきた TC39 のメンバーには、本当に感謝したい。

/raw に入れたら、あとは AI に LLM-Wiki のコンセプトに則って構築を依頼するだけだ。口頭でも頼めばやってくれるが、一応ショートハンドとしてコマンドが定義されている。

Ingest: 知識の取り込みと更新

本来 /raw 以下のソースは少しずつ増やし、追加するたびに既存の知識と繋いで Wiki 全体を更新していく。これが Ingest だ。

しかし、今回は初手で 14 年分の議事録があるため、いきなり全部の Proposal を解析するとトークンが枯渇する。

そこで、最初は「構造の把握と土台の構築」のみを依頼した。

以降、この Wiki における Ingest は、「Temporal についてまとめて」などと Proposal 単位で依頼し、過去の議論から "Temporal" を軸に議論をまとめてもらう。その結果を保存(File back)するという意味にした。

少しカスタマイズし、この出力には以下のような情報を含めてもらっている。

  • 誰の発言かという名前へのリンク
  • ステージ移動の mermaid グラフ
  • 議論が行われた議事録へのリンク

サンプルとして Temporal についてのまとめは以下だ。

proposals/temporal.md

TC39 の議事録は、発言者に対して 3 文字の短縮名を決め、それを議事録で使っている。

この短縮名ごとに /people ページにエントリを作らせ、「この人はどこの誰で、どんな仕様の Champion か」なども整理した。

Temporal の Champion である Igalia の Philip Chimento (PFC) のまとめは以下だ。

people/PFC.md

これも Ingest 時に作られ、誰が何をしているのかがわかりやすくなった。

以降、自分が調べたいときに Ingest を発行すれば、新たにまとめができ、Wiki が育っていく。

使えば使うほど、充実していく構成だ。

Lint: 既存知識の整合性チェックと更新

Lint では、すでにある知識の矛盾などを更新することができる。

もし /raw 以下を submodule update してから Lint を実行すれば、最新の議論を踏まえたうえで既存の /proposals や /people を更新できる。

更新の差分を見れば、何が変わったのかがわかりやすい。

Summarise: ミーティング議事録の要約

新しいミーティングの議事録が出たら、それを要約し、「トピックごとの議論」や意思決定のまとめを作成していた。

フォーマットとしてはこうだ。

  • ミーティングの各日ごとに
  • トピックごとの要約を
  • 3 ~ 5 行でまとめ
  • スライドがあればそのリンクを

以前は、都度ファイルを NotebookLM などにソースとして渡していたが、これを Summarise コマンドにまとめた。

raw/notes の PR を pull してからコマンドを実行すれば、以下のように議事録のまとめができる。

meetings/2026-05

これが、「TC39 minutes を読む会」で使っていたフォーマットにまとめてくれるため、読む会の準備が非常に捗る。

読んだ結果の感想などをメモとして追加し Ingest する仕組みができれば、より自分色の Wiki にできるだろう。

Families: 関連仕様のグルーピング

非公式な概念だが、仕様には "Family" がある。

例えば最近では、Iterator 関連の仕様が多くあり、Champion が同じで議論がつながることも多い。

逆に、Module 関連の異なる仕様をまとめて、Module Harmony として議論をまとめることもある。

これを「Iterator Family についてまとめて」といった粒度で集計するコマンドを Families として定義した。

以下のような結果だ。

families/iterator.md

今まで、「なんか最近 Iterator 周り多いね」くらいで終わっていたところから、一歩踏み込むことが容易になった。

Query: 既存 Wiki からの知識抽出

知識が十分にあるため、雑に聞いても色々答えが得られる。

雑な質問は Query として解釈され、既存の wiki の中から結果を抽出してくれる。

例えば「Decorator ってずっと Stage フラフラしてるけど、結局誰が欲しいの?」といった質問でも、議論を踏まえて答えを得られるのだ。

自分で調べるのも難しく、TC39 の特定のメンバーに会って直接聞くのも微妙で、たとえ聞いたとしてもその人の主観での答えになりがちだ。

議論を追っているため「仕様策定者は頑張っているが、ブラウザが実装したがらず、全然話が進まないまま数年経った」くらいの解像度で理解している。

しかし、この Wiki があれば「誰が欲しいのか」「どのブラウザが否定的なのか」「いつからこの議論をやっているのか」「ステージの変遷はどうか」などが、議事録をベースに細かく把握できる。

そして、Query の結果が有用なものであれば、File back して追記することで、さらに Wiki を育てることができるのだ。

この Wiki を Claude Remote で開いておいて、出先で「あれどうなったっけ?」と思ったらスマホで質問するだけで、自分の知識も Wiki も育つ。

既存手法との違い

RAG はあらかじめ情報を分析し、ベクトルとして保存する。そこから毎回知識をつなぎ合わせて、回答を出力している。もし今回のソースであれば、全てを一旦解析する必要があり、トークンコストは大きかっただろう。

そして、筆者の興味が及ばない 9 割以上のデータには、触れずに終わっていたと思う。

LLM-Wiki は本来、Ingest するたびに知識を繋いでいき、そこから回答を得る。知識を追加するたびに Wiki を育て、そこを検索するという複利効果が生まれる。

今回はソースが先にありながら、Query / Ingest で擬似的に知識が追加されたようなイメージになる。今後は、議事録が出るたびに Summarise をしてから読む会をするため、最新の知識はかなり網羅され、必要に応じて過去のことも調べられるという、この用途に最適なフレームワークと言える。

何より、AI Agent 以外何もいらないし、トークンコストもそこまでではないという点が、非常に扱いやすい。

Outro

「この中のどこかにある」を検索だけで探し、繋ぐのには限界があり、何より時間がかかっていた。

詳しい人を知っていても、何度も聞くのははばかられる。誰かに聞けば、その人のバイアスもある。

だから自分で調べるしかない、そこには価値がある。が、一度それを「面倒くさい」と感じてしまったら最後、疑問を持つことを諦めてしまうだろう。その怖さとの戦いがあったように思う。

AI を用いた要約作成も色々試したが、どれも精度や手間など、しっくりくるところまでいけなかった。

しかし、「全議事録」という宝の山に、LLM-Wiki という少しのコンセプトを振りかけただけで、かなり良いレベルでやりたいことを実現できた。

調べるコストが下がったことで、各提案や議論を読むこと、そしてその背景を感じることに、より時間を割けるようになる。Ship されてから出す解説ブログにも、かなり精度の高いソースを載せることができる。

今は扱いやすい TC39 でやっているが、同じことは CSSWG や HTTPBis などの WG でもできる。

それらを集め、mozaic.fm でスコープにしているような、「プラットフォームの変化全体」まで広げることも不可能ではないだろう。

しかし、今くらいのスコープの狭さの方が、精度的にはちょうどよいようにも思う。

先人が残してくれた遺産をありがたく使わせて頂きながら、Query を繰り返してどんどん育て、より高い解像度で Web を理解できるよう活用していきたい。