何が起きたか
Simon Willisonが、Web標準のブラウザ対応状況をまとめたmdn/browser-compat-dataを約66MBのSQLiteデータベースに変換し、simonw/browser-compat-dbとして公開しました。きっかけはMozillaが新たに提供を始めたMDN MCPサービスです。
変換スクリプトはClaude Code for web（Opus 4.8）で生成し、sqlite-utilsを利用。さらにCodex Desktop（GPT-5.5）でGitHub Actionsワークフローを組み、ビルドしたDBファイルをdbというorphanブランチへforce-pushする構成にしています。
なぜGitHubリポジトリに置くのか
通常、巨大な生成物はGitHub Releasesに置くのが定石ですが、ReleasesはCORSヘッダを開放していません。一方、リポジトリ内のファイルはGitHub CDN経由で開いたCORSで配信されます。この差を突いて、ブラウザから直接フェッチ可能なSQLiteを成立させているのが今回の肝です。
結果として、ブラウザ内で動くSQLランタイムであるDatasette Liteからそのままダウンロード・クエリでき、サーバを一切立てずに「対話的に探索できるデータセット」が完成しています。
LLM時代のデータ配布パターン
注目すべきは、MCPサービスの登場が「ドキュメント＋API」ではなく、「機械が直接読めるDBファイルそのもの」をCDNから配るアプローチを刺激している点です。LLMやエージェントが自律的に参照するデータは、JSON APIよりも構造化された静的アセットの方が扱いやすい場面が増えています。
💼 事業会社視点：これは自社にどう効くか
経営者・事業責任者が読み取るべき含意
本件は単なる個人プロジェクトではなく、「LLMエージェントに食わせるデータをどう配るか」という設計問題の答えを示しています。日本のSaaS・受託開発企業にとって、論点は3つです。
第一に、自社の業務マスタや仕様データをSQLite等の静的アセットとして配布する選択肢が現実的になりました。APIゲートウェイ・認証基盤・レート制御を厚く積まなくても、CDN＋CORSだけで顧客のブラウザやエージェントから直接参照できます。インフラ運用費を圧縮しつつ、エージェント連携の窓口になれます。
第二に、ビルドパイプラインをGitHub Actionsと生成AIで完結させた点です。SIerや受託開発の現場では、「データ更新ジョブを書くだけのために人月を積む」案件が消えていきます。経営層は工数前提の見積を組み替える必要があります。
第三に、ECや業務SaaSのCTOは、Releases配布／API配布／リポジトリ直接配布のCORS挙動の差を即座に棚卸ししてください。ここを誤ると、自社データがエージェント経済から締め出されます。