WeatherNext AIがサイクロン予測で1日分の警報リードタイムを実現、オープンソース化へ
Google DeepMindは2026年8月6日、AI気象予測モデル「WeatherNext」がサイクロン（ハリケーン・台風）予測において、警報のリードタイムを1日延長する画期的な精度を達成したと発表した。同モデルはすでに2025年のハリケーンシーズンで実運用され、上陸地点と急速発達の予測に貢献している。さらにコードとモデル加重がオープンソース化され、研究コミュニティ全体での活用が可能になった。
この成果は、過去50年間で70万人以上の死者と1.4兆ドルの経済損失をもたらしてきた熱帯低気圧への対策に、AIが本格的に実用化される転換点となる。本記事ではWeatherNextの技術的ブレークスルーと、それが実際の防災現場にもたらすインパクトを掘り下げる。
サイクロン予測で警報リードタイムを1日延長
WeatherNextは、サイクロンの進路（どこに行くか）・強度（どれだけ強くなるか）・風構造の3要素すべてで最先端の予測精度を達成した。平均すると、3日先の予測が従来の最優秀モデルの2日先予測と同等の正確さを示し、1日分のリードタイム短縮に相当する。気象学分野では、このレベルの改善は約10年分の技術進歩に匹敵するという。
この大幅な改善は、3日後の進路・強度・風構造すべてにわたる。気象庁や米国国立ハリケーンセンター（NHC）のような機関が早期警報を出せる余地が格段に広がることを意味する。
WeatherNextが予測精度を高める仕組み
従来のサイクロン予測には、大きなジレンマがあった。進路は地球規模の大気の流れが支配するため、広域を粗い解像度でモデル化する全球モデルが必要だった。一方、強度や風構造は台風の目の周辺数十キロメートルの局所的な対流活動が決め手となるため、高解像度の局地モデルが不可欠とされてきた。この二つの異なるモデルを併用するアプローチが限界を生んでいた。
WeatherNextは単一のAIモデルでこのギャップを埋める。全球の気象力学と、専門家が蓄積してきた過去約5,000個のサイクロン観測データ（IBTrACS）を同時に学習することで、広域のパターンも局所的な暴風構造も一貫して予測できるようになった。学習に使った大気データは約20テラバイトに及ぶ。
もう一つの鍵は、機能的生成ネットワーク（FGNs）を用いたアンサンブル予測だ。気象には本質的に不確実性が伴うため、1つの予測ではなく多数のシナリオを生成し、その確率分布からリスクを評価する。WeatherNextはTPU上で1度の15日予測を1分未満で実行でき、当初50メンバーだったアンサンブルを現在は1,000メンバーに拡大。ハリケーン・メリッサ（2025年）のような急速発達イベントも、低確率ながら重大なテールリスクとして捉えられるようになった。
驚くべきことに、WeatherNextは従来の局地モデルより100倍粗い28km四方の解像度データだけで高精度な強度予測を実現している。さらに111km四方の解像度で動作する軽量版「WeatherNext 2-mini」でも高い性能を示しており、なぜこれほど粗いデータで正確な予測ができるのかは、まだ科学的に完全には解明されておらず、研究コミュニティとともに探求するテーマだ。
2025年ハリケーンシーズンでの実績とオープンソース化
WeatherNextはすでに実際の防災判断に貢献している。2025年のハリケーンシーズン、NHCはWeatherNextの予測をもとにハリケーン・メリッサの急速発達とジャマイカ上陸を早期に警告した。これにより現地の準備期間が確保され、人命とインフラを守る重要な一手になったと報告されている。
2026年8月のNature掲載論文と並行して、Google DeepMindはWeatherNext 2およびWeatherNext Cyclonesモデルのコードと重みをGitHubで公開した。商用利用を含め自由に利用でき、学術研究から各国の気象機関による現業予報、さらに地域特化のカスタムモデル開発まで幅広く活用できる。また、無料のColabノートブックで動作する軽量版も提供され、個人や小規模組織でも気象AIのプロトタイプを試せる環境が整った。
気象予測の民主化として、このオープンソース化は大きな意味を持つ。途上国や島嶼国の気象機関にとって、高価なスーパーコンピュータがなくてもTPU相当のクラウドリソースがあれば、世界最高水準のサイクロン予測を運用できる可能性が開けたからだ。
今後の展望とコミュニティへの期待
Google DeepMindは、研究者や気象機関に対し、WeatherNextをベースにした共同開発や改良を呼びかけている。最終的な警報や避難指示は各国の気象当局が発出するものであり、AIはあくまでその判断を支えるツールだが、予測精度の向上が地域コミュニティのレジリエンスを高めることは明らかだ。
粗解像度で高精度を達成した理由の解明や、より長期の予測への応用など、学術的にも興味深い課題が残されている。WeatherNextのオープンソース公開により、世界中の研究者がこれらの謎に取り組み、気象学とAIの融合をさらに加速させることが期待される。
この記事のポイント
- WeatherNextはサイクロンの進路・強度・風構造を3日前の時点で高い精度で予測し、警報リードタイムを1日延長
- 単一AIモデルで広域と局所の両方をカバー。28km解像度の粗いデータでも高性能
- 2025年ハリケーンシーズンで実際にNHCの早期警報を支援し、オープンソース化で全世界に利用拡大
- 機能的生成ネットワークにより1,000メンバーのアンサンブル予測を1分未満で実行し、レアシナリオを捕捉
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
npmとGitHub Actionsのサプライチェーン攻撃を遮断する新防御策
npmとGitHub Actionsを舞台にしたサプライチェーン攻撃が、近年組織化された巧妙な手口で猛威を振るっている。2026年前半、GitHubはこの攻撃連鎖を根本から断つため、数多くの防御策を相次いでリリースした。
公式ブログで公開された内容をもとに、初期侵入の防止、認証情報の抜き取り対策、マルウェア拡散の阻止、インシデント対応まで、最新の変更点をまとめて解説する。CI/CDパイプラインやパッケージレジストリを扱う開発者や運用担当にとって、すぐに活用できる情報が揃っている。
サプライチェーン攻撃の実態と攻撃チェーン
オープンソースエコシステムを標的としたサプライチェーン攻撃は、複数の脆弱性を組み合わせて短期間に被害を拡大する。典型的な流れは、メンテナーのアカウント乗っ取りに始まり、CI/CDワークフローの欠陥を突いてプロジェクトへ侵入し、認証情報を窃取したうえで、マルウェアを仕込んだパッケージを一気に配布するというものだ。
GitHubはこうした攻撃チェーンを研究し、最も効果の高い箇所に対策を集中投入している。以下の図は、よく見られる攻撃のステップを簡略化したものだ。
この連鎖を断ち切るため、GitHubは複数の防御層を設けてきた。次節から順に見ていく。
初期侵入を許さない新たな対策
サプライチェーン攻撃の第一段階は、多くの場合フィッシングによるメンテナーアカウントの侵害だ。また、GitHub Actionsのワークフロー設定ミスを突いた手口も頻発している。これらに対抗するため、2026年6月にいくつかの重要な変更が施された。
高影響度npmアカウントの保護
npmでは、影響度の高いアカウントに対して予防的な保護措置が導入された。メールアドレスの変更や二要素認証のリカバリコードを使用した場合、アカウントは72時間にわたって読み取り専用となる。この猶予期間によって、正当なメンテナーがアカウント回復のための時間を確保し、攻撃者が即座に悪用することを防げる。
GitHub Actionsワークフローの安全強化
GitHub Actionsでは、「pwn request」と呼ばれるフォークからのプルリクエストを通じた不正コード実行が長年の課題だった。これに対処するため、actions/checkout のデフォルト動作が変更され、フォークからの信頼できないコードをチェックアウトしないようになった（明示的にオプトアウトすれば従来どおり利用できる）。
さらに、ワークフローのトリガー（実行条件）に対して、誰がどの種類のトリガーを使えるのかをエンタープライズや組織レベルで制御できるポリシーが追加された。これにより、不要な pull_request_target の使用を禁止したり、信頼できないトリガーの範囲を限定したりできる。
加えて、Actionsのキャッシュ操作にも制限がかかった。信頼度の低いワークフローからは、他のワークフローと共有しているキャッシュを変更できないようにし、キャッシュポイズニングによる権限昇格の道を塞いでいる。
認証情報の抜き取りを防ぐ仕組み
初期侵入に成功した攻撃者は、次にCI/CDパイプラインやリポジトリに残る認証情報を狙う。これらを抜き取られないようにすることが、攻撃拡大を防ぐ要となる。
信頼できる公開で長期クレデンシャルを排除
npmの「Trusted Publishing（信頼できる公開）」は、長期にわたって有効なトークンを使わずにパッケージを公開する機能だ。2026年4月より、CI/CDサービスとしてCircleCIが新たにサポートされたことで、より多くのプロジェクトがこの仕組みを利用できるようになった。CI/CD環境に直接シークレットを置く必要がなくなり、たとえ環境が侵害されてもトークンが漏洩するリスクが大きく下がる。
Actionsネットワークファイアウォール（技術プレビュー）
Actionsワークフローの実行中に発生するすべての外向き通信をログに記録する機能が、テクニカルプレビューとして提供開始された。これにより、悪意のあるコードのダウンロードや、未知のドメインへの認証情報の送信といった異常を検知できる下地が整う。将来的には、ネットワークの出口制限（egress restriction）やポリシーによる遮断も視野に入っている。
攻撃の拡散を封じるnpmとGitHub Actionsの強化
認証情報を手にした攻撃者は、次にマルウェアを仕込んだパッケージを大量に公開し、できるだけ多くのプロジェクトに感染させようとする。拡散速度を落とし、悪用の連鎖を食い止める対策がいくつか実装された。
段階的パブリッシュ（Staged Publishing）
2026年5月からnpmで利用可能になったStaged Publishing（段階的公開）は、CI/CDパイプラインのクレデンシャルだけではパッケージを直接公開できなくする仕組みだ。パイプラインからステージングされたバージョンは、別途npm CLIやWebサイト上での手動承認と二要素認証を経て初めて本公開される。これにより、CI/CDが侵害されても自動的にマルウェアが配布されるリスクを断ち切る。
npm v12でインストールスクリプトをデフォルト無効化
攻撃者はパッケージのインストール時に実行されるスクリプト（install scripts）を悪用し、即座に認証情報を抜き取る手法を多用してきた。2026年6月に発表されたnpm v12では、こうしたインストールスクリプトがデフォルトで無効化される。正当な用途でスクリプトが必要な場合は、利用者が明示的に許可を与えることで再び有効にできる。
Dependabotバージョン更新に3日間のクールダウン
攻撃者は新たに公開した悪意あるバージョンが、Dependabotの自動プルリクエストで一気に下流プロジェクトに取り込まれることを狙う。このスピードを抑制するため、2026年7月からDependabotのバージョン更新にはデフォルトで3日間のクールダウンが設けられた。リリース後少なくとも3日が経過するまでプルリクエストは開かれず、その間にコミュニティや自動検知が悪意あるバージョンを発見する猶予が生まれる。なお、セキュリティアップデートは即時に発行されるため、緊急の修正が遅れることはない。
インシデント対応を迅速化する機能
防御策と並行して、万一の侵害発生時に素早く対処できる機能も強化されている。
セルフサービスでのクレデンシャル無効化
2026年6月、エンタープライズ管理者やメンバーが、自身の全クレデンシャルを即座に無効化できるセルフサービスツールが提供された。2月にリリースされたエンタープライズ全体のクレデンシャル管理機能を拡張したもので、サプライチェーン攻撃で認証情報の漏洩が疑われる場合に、数クリックで影響範囲を封じ込められる。
OAuthトークンとAppトークンの即時失効API
2026年3月には、GitHubのOAuthトークンおよびAppトークンをプログラムから即座に失効させるAPIが拡充された。2025年4月に導入されたPersonal Access Token向けの失効APIに続くもので、公開リポジトリにクレデンシャルが漏れてしまった場合でも、開発者が自身で迅速に無効化できる。漏洩したトークンの悪用可能な期間を大幅に短縮する手段となる。
今後の展望
GitHubは製品をデフォルトで安全にする方針を掲げ、npmとGitHub Actionsの両面からサプライチェーン攻撃の遮断に取り組んでいる。今回紹介した変更は数カ月の成果に過ぎず、引き続きchangelogや公式ブログで新たな対策が発表される見込みだ。
オープンソースの持続可能性と企業の安全な利用を支えるこれらの取り組みは、コミュニティ全体にとって大きな前進といえる。
この記事のポイント
- サプライチェーン攻撃は、アカウント乗っ取りからCI/CD経由でマルウェア配布へと連鎖する。GitHubは各段階に多重の防御を適用している
- npmの高影響度アカウントに72時間の読み取り専用期間を設定し、乗っ取り後の即時悪用を防止
- GitHub Actionsの
pull_request_targetやキャッシュ操作を安全なデフォルトに変更し、初期侵入を抑止 - 長期クレデンシャルを使わない「Trusted Publishing」と「Staged Publishing」で認証情報漏洩と自動公開を遮断
- Dependabotのクールダウンとnpm v12のインストールスクリプト無効化で拡散速度を抑制
- クレデンシャルの即時失効機能により、万が一のインシデント対応を迅速に実施可能
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
VercelがBetter Authを買収、TypeScript認証ライブラリとエージェントIDの未来
VercelがBetter Authを買収。TypeScript認証ライブラリとエージェントアイデンティティの取り込み
2026年7月7日、VercelはオープンソースのTypeScript認証ライブラリ「Better Auth」を買収したと発表した。ライブラリの週間npmダウンロード数は470万を超え、すでに850人以上のコントリビューターが開発に参加している。創設者のBereket Engida氏とコアチームはVercelに加わり、Better Authそのものと、関連プロジェクトであるエージェント認証プロトコル「Agent Auth」の開発を続ける。
今回の買収は、認証の仕組みをフレームワークやプラットフォームに依存しない形で提供する動きであり、なかでも「エージェントに独自のアイデンティティを与える」という構想が注目を集めている。背景と具体的な影響を順に整理していく。
Better Authとは何か。週間470万DLの認証ライブラリ
Better Authは、TypeScriptで書かれたオープンソースの認証ライブラリだ。従来の認証ライブラリに比べて設定がシンプルで、Next.jsやNuxtなど特定のフレームワークに依存しない。データベースやセッション管理の選択肢も広く、開発者が自前で認証周りをコントロールできる点が特徴である。
フレームワーク非依存の設計思想
多くの認証ライブラリは特定のフレームワークと密結合だったり、プラットフォームの管理画面を通さなければ設定が完了しなかったりする。Better Authは「どこでも動き、開発者が認証を所有する」という原則で作られている。これにより、プロジェクトの要件が変わっても認証部分の移行が容易になる。
コミュニティ主導の成長
470万ダウンロードと850人以上のコントリビューターという数字は、単なるGitHubスターの数ではない。実際に本番環境で使われ、機能追加やバグ修正が活発に行われている証拠である。Vercelは買収後もMITライセンスを維持し、コミュニティガバナンスを継続すると明言している。
買収の背景。Vercelが描く「オープンウェブ」と認証の位置づけ
Vercelは2025年に公開した「オープンSDK戦略」のなかで、ソフトウェアはデフォルトでオープンであり、疎結合で、どのプラットフォームにも移植可能であるべきだと述べている。Next.jsやAI SDK、Nuxtにもこの方針が適用されており、今回のBetter Auth買収もその延長線上にある。
認証を「所有する」という考え方
クラウドサービスが認証を代行する形は便利だが、ロックインのリスクがある。Better Authのようにライブラリ単位で認証を導入できれば、インフラを移行しても同じ仕組みを使い続けられる。Vercelはこの「所有可能な認証」をエコシステムに取り込むことで、開発者にとっての自由度を高めようとしている。
エージェントアイデンティティが切り開く、新しい認証の形
買収発表のなかで特に強調されたのが、エージェント（自律的に動作するソフトウェア）に「自分自身のID」を持たせるという構想だ。Better Authチームが開発している「Agent Auth」プロトコルは、まさにこれを実現するためのものである。
この概念図で示すように、Agent AuthではエージェントごとにIDを発行し、スコープを絞った権限と失効可能な認証情報を持たせることができる。ユーザーが単一のコントロールポイントから、個々のエージェントの権限を管理できる点が革新的だ。
なぜエージェントに独自IDが必要なのか
現在、AIエージェントがユーザーに代わって予約や購入を行う場合、エージェントはユーザー自身の認証情報を使ってサービスにアクセスする。この方式では、エージェントに渡す権限を細かく制御できない。また、不正が疑われた場合に特定のエージェントだけを停止することが難しく、結局すべての連携を遮断する必要があった。
Agent Authは、エージェントひとつひとつに「ペルソナ」のようなIDを割り当てる。たとえば「カレンダー参照専用エージェント」「メール送信専用エージェント」といった具合に役割を分け、不要になればそのIDだけを無効化できる。これはエージェントが当然のように動く世界において、セキュリティと管理性を両立する基盤技術といえる。
Vercel Connect と eve への統合
Better AuthチームはVercelに加わり、このエージェントアイデンティティをVercel Connectとeveに組み込むと発表されている。Vercel Connectは開発者がさまざまなサービスやAPIを安全に連携させるための仕組みであり、eveはVercelが提供するAIエージェントプラットフォームである。認証レイヤーが標準装備されることで、エージェントを使った機能をより安全かつ手軽に実装できるようになるだろう。
開発者コミュニティとライブラリの今後
買収によってBetter Authのライセンスや開発体制が変わるのではないかと懸念する声もある。しかしVercelは、ライブラリはMITライセンスのまま無料で提供され、名称も変更されず、同じコミュニティガバナンスモデルで開発が続くと明確に述べている。
オープンソースとしての継続
Better AuthのGitHubリポジトリは引き続き公開され、プルリクエストやIssueを通じたコミュニティ参加も歓迎される。Vercelのリソースが投入されることで、ロードマップの進行速度が上がったり、ドキュメントの整備が進んだりするメリットが期待できる。
フレームワークサポートの拡大
Better AuthはすでにNext.js以外にもNuxt、SvelteKit、Remixなど多様なフレームワークで利用できる。Vercelは特定のフレームワークに偏らないサポートを続ける方針を示しており、エコシステム全体への貢献が加速する可能性がある。
Vercelの戦略から見る、認証とエージェントの未来
今回の買収は、単に認証ライブラリを手に入れる以上の意味を持つ。Vercelはすでにホスティング、サーバーレス関数、エッジネットワーク、AI SDKと積み上げてきた。そこに「認証」と「エージェントアイデンティティ」というピースが加わることで、開発者がアプリケーションを作り、デプロイし、AIエージェントを安全に動かすための一気通貫のプラットフォームが姿を現しつつある。
「エージェントインフラ」の基盤として
Vercelは以前から「エージェントインフラストラクチャ（agentic infrastructure）」という概念を掲げている。これは、AIエージェントが動くための実行環境だけでなく、ストレージ、キュー、認証といったバックエンドの一式を提供する考え方だ。Better Authの買収によって、その認証レイヤーが大きく強化されることになる。
競合との差別化要因
他社のクラウドプラットフォームも認証機能を提供しているが、多くはプロプライエタリなサービスである。Better AuthのようにオープンソースでMITライセンスの認証ライブラリを中核に据えるアプローチは、ベンダーロックインを嫌う開発者層に強く支持されるだろう。とくにエージェントの台頭により認証の複雑さが増すなかで、「所有できる認証」の価値はますます高まっていく。
この記事のポイント
- VercelがオープンソースのTypeScript認証ライブラリ「Better Auth」を買収。創設者とコアチームがVercelに参加する。
- Better Authは週間470万ダウンロード、850人以上のコントリビューターを持つ。MITライセンスとコミュニティガバナンスは維持される。
- エージェントに独自のIDと制限付き権限を与える「Agent Auth」プロトコルの開発が加速し、Vercel Connectやeveに統合される予定。
- 従来のエージェント実行における権限制御の課題を解決し、エージェントごとの失効やスコープ管理が可能になる。
- Vercelは「オープンSDK戦略」に沿って認証レイヤーを強化し、エージェントインフラの基盤を固める動きを加速させている。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHubが依存関係のライセンス遵守を自動化する新機能を発表
GitHubは2026年6月30日、オープンソースの依存関係におけるライセンス遵守を自動化する「License Compliance」機能を公開プレビューとして発表した。GitHub Advanced Security（GHAS）のCode Securityライセンスを持つEnterprise Cloudユーザーが対象だ。
この機能はPull Request上で新たに追加される依存関係のライセンスを自動スキャンし、組織のポリシーに反するものがあればアラートを出す。GitHub自身のOpen Source Program Office（OSPO）も数カ月前からこの機能に移行し、社内ツールを置き換えた実績がある。
ソフトウェア開発において依存関係のライセンス管理は、後回しにされがちな領域だ。しかし、ライセンス違反は訴訟リスクやコードの公開義務といった深刻な結果を招く。この記事では、GitHubの新機能の仕組みと、実際に運用する組織がどのようにポリシーを設計すべきかを解説する。
オープンソースライセンスの遵守が企業にとって重大な理由
ほぼすべてのソフトウェアには何らかのライセンスが付与されている。ライセンスはそのプロジェクトを利用する許可を与えるが、同時に遵守すべき義務も課す。義務の内容は、ドキュメントに原著作者のクレジットを記載するだけの緩やかなものから、プログラムを配布する際に自社の全ソースコードを公開しなければならない強力なものまで幅広い。
商用ソフトウェアにおけるリスク
商用のクローズドソース製品を販売する組織であれば、GPL系のライセンスを持つ依存関係をうっかり混入させると、自社のプロプライエタリなコード全体をオープンソース化せざるを得なくなる可能性がある。これはビジネスモデルを根底から覆す致命的な事態だ。
逆に、自社プロジェクトをオープンソースとして公開する予定があるなら、商用ライセンスや互換性のないオープンソースライセンスの依存関係を避ける必要がある。いずれにせよ、ライセンス義務を満たせない依存関係は排除しなければならない。後から該当ライセンスのコードを除去するには大きな工学的コストがかかるし、企業ソフトウェアにとって違反のビジネスリスクは甚大だ。高額な訴訟やレピュテーションの損傷に直結する。
従来のレビュー手法とその限界
これまでライセンスレビューは手作業か、サードパーティ製ツールで行われてきた。しかし、依存関係が増えるたびに人手でライセンスを確認するのは現実的ではない。ツールを使うにしても、開発フローとは別の場所でチェックが走るため、問題が見つかった時点では既にコードがマージされた後、というケースも少なくなかった。
GitHubのLicense Compliance機能はこの課題に直接アプローチする。Pull Requestの段階で新しい依存関係をスキャンし、ポリシーに合致しないライセンスがあれば、マージ前に開発者へフィードバックを返す。開発フローに組み込まれた「シフトレフト」なアプローチだ。
GitHubのLicense Compliance機能の仕組み
この機能は、リポジトリに適用するルールセット（ruleset）を通じて有効化される。カスタムプロパティを使って対象リポジトリを指定し、「Active」モードか「Evaluate」モードかを選択する仕組みだ。
ルールセットの対象となったリポジトリでは、依存関係を変更するPull Requestが作成されると自動スキャンが走る。新しい依存関係それぞれのライセンスを照会し、既に許可済みのライセンスやパッケージ固有の例外に該当すればチェックをパスする。問題がある場合は、直接の依存関係だけでなく推移的依存関係（依存関係がさらに依存しているパッケージ）についても、Pull Requestのコメントとしてアラートが投稿される。
開発者から見たフロー
開発者はアラートを受け取ったら、その依存関係が受け入れ可能かどうかを判断する。受け入れられないと判断すれば、コードを修正するかPull Requestをクローズして依存関係を除去する。一方、そのライセンスやパッケージを許可すべきだと考えた場合は、例外申請を上げることができる。申請は組織内のポリシーチームに通知され、ポリシーを修正するかどうかが判断される。
GitHub OSPOの運用実績
GitHub自身のOSPOは、この機能が社内公開される前からアーリーアダプターとして利用してきた。当初は組織全体のルールセットに「Evaluate」モードを適用し、Pull Requestにアノテーションを表示するだけでマージはブロックしない設定でスタートした。これにより、開発者が新しいワークフローに慣れる時間を確保しつつ、旧来の社内ツールと並行稼働させて挙動の差異を検証したという。
約1カ月の並行稼働を経て、アラートの大半が「通常とは異なるライセンス」「ライセンス情報の欠落」「明示的に禁止されたライセンス」に絞り込まれた段階で、Activeモードへ移行した。大規模で動きの速い企業でも、段階的なロールアウトによって摩擦を最小化できる好例といえる。
ポリシー設計の実践アプローチ
効果的なライセンスコンプライアンスを実現するには、適切なポリシー設計が不可欠だ。GitHub OSPOの経験から、以下の3段階で考えると整理しやすい。
重要なのは、ポリシーを「作って終わり」にしないことだ。新しいライセンスやパッケージ固有の例外は、ポリシーチームが継続的に審査し、必要に応じて追加していく。この運用プロセスが整っていないと、開発者は Pull Request がブロックされたまま放置される「ポリシー渋滞」に巻き込まれる。
ライセンス許可とパッケージ例外の使い分け
ポリシー修正には大きく2つの判断軸がある。「ライセンスそのものを許可する」か「特定のパッケージだけを例外として許可する」かだ。さらに、その許可を「Enterprise全体（組織全体）」に適用するか「特定のリポジトリのみ」に限定するかも決定する。
安全なライセンスで単に初出だっただけなら、Enterpriseレベルでライセンスを追加すれば済む。一方、商用ライセンスのパッケージで、特定のチームだけが購入済みのソフトウェアなら、そのリポジトリだけに例外を設定する。パッケージ例外にはワイルドカードマッチが使えるため、例えば @github-ui/* のような形で名前空間単位の許可も可能だ。
緊急時のオーバーライドと開発者教育
ライセンスポリシーによってPull Requestがブロックされる仕組みは強力だが、クリティカルな修正を緊急でマージしなければならない場面も想定しておく必要がある。GitHub OSPOは「ブレークグラス（緊急時オーバーライド）」の手順を整備している。
仕組みはシンプルだ。ルールセットの条件はカスタムプロパティの値を参照しているため、そのプロパティ値を切り替えるだけで一時的にポリシー適用を無効化できる。GitHub OSPOのこれまでの運用では、このオーバーライドを使ったのは1度だけだったという。頻繁に使うものではないが、いざという時に選択肢があることが重要だ。
開発者へのトレーニングとドキュメント
ツールを導入するだけでは不十分だ。開発者が「なぜライセンス遵守が自分ごとなのか」を理解していなければ、例外申請のプロセスは形骸化する。GitHub OSPOは社内向けのドキュメントとトレーニングを提供し、ライセンスコンプライアンスが全員の責務であるという認識を浸透させている。
開発者が情報に基づいた依存関係の選択をできるようになれば、後からの修正作業や法的トラブルを未然に防げる。ライセンス遵守は「コンプライアンス部門だけの仕事」ではなく、サプライチェーン全体で取り組むべき課題だ。
依存関係管理のこれから
ソフトウェアサプライチェーンのセキュリティとコンプライアンスは、近年急速に注目を集めている領域だ。SBOM（Software Bill of Materials）の普及や、米国大統領令によるソフトウェアサプライチェーンセキュリティの強化など、規制面からの要請も強まっている。
GitHubのLicense Compliance機能は、こうした流れの中で「Pull Request時点でライセンスをチェックする」というプラクティスを標準化しようとする試みだ。開発フローに自然に溶け込む形で提供されるため、導入障壁は従来のサードパーティツールよりも低い。
現時点ではパブリックプレビューであり、対象はGitHub Enterprise CloudでGHAS Code Securityライセンスを保有するユーザーに限られる。しかし、GitHub自身が大規模な組織で実績を積んでいる点は、導入を検討する企業にとって心強い材料だろう。
この記事のポイント
- GitHubが依存関係のライセンス遵守をPull Request上で自動チェックする新機能を公開プレビューとして発表した
- ルールセットを通じてリポジトリ単位で適用し、Evaluateモードから段階的に導入できる
- GitHub自身のOSPOがアーリーアダプターとして社内で運用実績を積んでいる
- ライセンス違反は訴訟リスクやソースコード公開義務といった深刻な結果を招くため、開発フローへの組み込みが重要
- ポリシー設計は「基本ライセンスの登録 → Evaluateモード → Activeモード」の3段階で進めるのが現実的
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GitHubメンテナ必見、今週中に有効化すべき6つのセキュリティ設定
GitHubで公開リポジトリや社内リポジトリを管理している開発者にとって、セキュリティ設定は後回しになりがちだ。コードを書くのに忙しく、設定画面をじっくり見ている余裕はない、という声も多い。だが無料で使える基本設定を有効にするだけで、攻撃のハードルは劇的に上げられる。
GitHub Security Labが2026年7月1日に公開した記事では、30分で完了する6つの設定が紹介されている。どれも無料で即効性がある。2025年には公開GitHub上で2,865万件のシークレット（APIキーやトークン）が新たに漏洩し、前年比34%増という過去最大の増加幅を記録した。AI支援のコミットではこれが約2倍のペースで起きている。
以下、実際に有効にする手順と効果を解説する。
脆弱性報告の受け皿を整える最初の2ステップ
誰かがプロジェクトの脆弱性を見つけたとき、その報告先が用意されていなければ、善意の報告者は公開Issueに投稿するか、個人の連絡先を探すしかない。前者は修正前に攻撃手法を公開することになり、後者は連絡そのものが届かないリスクがある。これを防ぐのがSECURITY.mdとプライベート脆弱性報告（PVR）の2つだ。
SECURITY.mdの役割と書き方
SECURITY.mdはリポジトリのルートに配置するファイルで、脆弱性の報告方法を明示する。記載内容はシンプルでよい。連絡用のメールアドレス、対象とする脆弱性の範囲、報告者が知っておくべき前提事項があれば書く。
GitHub Security Labの記事では、systemdプロジェクトのセキュリティポリシーが参考例として挙げられている。24時間対応の体制を前提とせず、再現手順の期待値を明確にしている点が実務的だ。この構造を借りて連絡先を差し替えれば、10分程度で作成できる。
プライベート脆弱性報告（PVR）の有効化
SECURITY.mdが「どこに報告するか」を示すのに対し、PVRは「報告を非公開で受け付ける場」を提供する。設定はリポジトリの「Settings → Security」にあるチェックボックスを1つオンにするだけだ。
PVRを有効にすると、研究者は公開されない形で脆弱性を報告できる。メンテナはそれを非公開のままトリアージし、修正完了後に情報を公開するタイミングを自分で決められる。この2つをセットで導入すれば、コミュニティに対して「セキュリティに真剣に取り組んでいる」というシグナルを最も早く送れる。
上の図は、SECURITY.mdの有無で脆弱性報告の流れがどう変わるかを整理したものだ。左側（Before）では報告が公開Issueに向かい、修正前に攻撃手法が晒される。右側（After）では非公開チャネルを通じて修正後に公開できる。
シークレット漏洩と依存関係のリスクを自動でブロックする
コードを書いているとき、APIキーやデータベースの接続文字列をうっかりコミットしてしまった経験はないだろうか。GitGuardianの2026年版レポートによれば、2025年に公開GitHubへ流出した新規シークレットは2,865万件で、前年比34%増。IBMの2025年レポートでは、データ侵害の平均コストは世界で444万ドル、米国では1,022万ドルに達している。
シークレットスキャニングとプッシュ保護
シークレットスキャニング（secret scanning）は、リポジトリにコミットされたAPIトークンや秘密鍵を検知する機能だ。さらにプッシュ保護（push protection）を有効にすると、ローカルでのコミット時にシークレットが含まれている場合、リモートリポジトリにプッシュされる前にブロックする。
この機能は公開リポジトリとプライベートリポジトリの両方で使える。シークレットがローカル環境を離れた時点で、リポジトリへのアクセス権を持つ全員がそれを閲覧できる状態になる。プッシュ前に止めることが何より重要だ。
Dependabotと依存関係レビュー
プロジェクトのコードは自分が書いた部分だけで完結しない。数十から数百の外部パッケージに依存している。Dependabotは、依存パッケージに既知の脆弱性（CVE）が見つかった際にアラートを出す。依存関係レビュー（dependency review）は、プルリクエスト内で追加・更新されるパッケージと、それらに関連する勧告の有無を表示する。
この2つを有効にすると、package.jsonの差分をひとつずつ手作業で確認する必要がなくなり、レビュー時間は2分程度に短縮される。
シークレットスキャニングのプッシュ保護が有効だと、誤ってAPIキーを含んだコミットを作成しても、リモートリポジトリへ到達する前にローカルでブロックされる。設定の有無でリスクが大きく変わる。
コードスキャニングで実装レベルの脆弱性を検出する
コードスキャニング（code scanning）は、リポジトリのコードに対して静的解析を実行し、SQLインジェクション、コマンドインジェクション、危険なデシリアライゼーションなど、実際のバグにつながるパターンを検出する。
GitHubが提供するCodeQLはその解析エンジンだ。2019年にオープンソース向けに無料化され、現在はリポジトリの「Security and Quality」タブからワンクリックでデフォルト設定を適用できる。デフォルト設定はプロジェクトの使用言語に応じて適切なクエリパックを自動選択し、全プルリクエストに対して実行される。
コードスキャニングを敬遠する理由として「設定が面倒そう」という印象があるが、デフォルト設定を使う限り、追加の設定作業は不要だ。GitHub Actionsのワークフローを通じて、プルリクエストごとに自動で解析結果が表示される。
ブランチ保護で全対策を実効的にする
ここまで紹介した5つの設定は、いずれも検知や通知を行うものだ。しかし、検知された問題がマージを止められなければ、タブに積まれたアラートを見ないまま本番に反映されてしまう。この「検知だけで終わらせない」役割を担うのがブランチ保護ルール（branch protection）である。
デフォルトブランチに対して「プルリクエスト必須」「最低1件の承認を要求」というルールを設定するだけで、以下のシナリオを防げる。認証情報が漏洩して悪意のあるプッシュが行われるケース、混乱したコントリビューターが意図せずメインブランチに直接プッシュするケース、深夜に疲れた自分が確認なしで本番へプッシュしてしまうケース。これらはいずれも現実に起きうる。
ブランチ保護は、Dependabotのアラートやコードスキャニングの指摘がマージをブロックする仕組みとしても機能する。検知結果が単なる通知で終わらず、実際の開発フローに組み込まれることで初めて、他の5設定が本来の効果を発揮する。
ブランチ保護を有効にすると、プルリクエストとレビューが必須になる。コードスキャニングやDependabotのアラートも、このゲートを通じて初めてマージを止める力を持つ。
この記事のポイント
- SECURITY.mdとPVRで脆弱性報告の非公開チャネルを確保する
- シークレットスキャニングのプッシュ保護でAPIキー流出をローカル段階で防ぐ
- Dependabotと依存関係レビューで外部パッケージの脆弱性を自動監視する
- コードスキャニングのデフォルト設定はワンクリックで即効性がある
- ブランチ保護ルールがなければ他の設定は「通知に留まり」実効力を持たない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GoogleとMicrosoftがAIエージェント共通仕様ARDを公開、11社が賛同
GoogleとMicrosoftを含む11社が、AIエージェントがウェブ上のツールやスキルを自動検出するための共通仕様「ARD（Agentic Resource Discovery）」を2026年6月17日に公開した。
GitHubやHugging Face、NVIDIA、Salesforceも名を連ねるこの仕様は、各社が公開するAIエージェント向け機能を、事前の手動接続なしに実行時に見つけ出せる仕組みだ。Apache 2.0ライセンスで公開され、同日に複数の参照実装もリリースされた。
この仕様が実用化されれば、AIエージェントは必要なツールを自ら探し出して接続できるようになる。開発者やサービス提供者にとっては、自社のAPIやエージェント機能をAIシステムに自動的に見つけてもらうための新たな方法が生まれることになる。
ARDとは何か
ARD（Agentic Resource Discovery）は、AIエージェントがウェブ上で「使えるツールや機能」を自動的に見つけ出すための共通ルールを定めた仕様だ。Linux Foundationのワーキンググループが管理するAI Catalogデータモデルを基盤に構築されている。
現在のAIエージェントは、あらかじめ各ツールやMCPサーバー、APIとの接続を手動で設定する必要がある。企業が公開する機能が増え続けるなか、この「事前配線」方式では拡張性に限界があった。ARDはこの問題に対処するために設計されている。
ARDの仕組みは、企業が自社ドメインに公開するカタログと、それを収集してインデックス化するレジストリの2層構造で成り立っている。人手による接続設定を実行時の検索に置き換えることで、AIエージェントが自律的に機能を発見できる世界を目指している。
ARDの技術的な仕組み
カタログとレジストリの2層構造
ARDの中核は「カタログ」と「レジストリ」という2つの要素だ。まず、ツールやエージェントを提供する企業は、自社ドメインの定められたパスにai-catalog.jsonというファイルを設置する。このファイルには、公開するツール、MCPサーバー、エージェント、APIの一覧が記述される。
次に「レジストリ」がこれらのカタログを巡回（クロール）してインデックス化する。AIエージェントが「この処理に使えるツールはないか」と自然言語で問い合わせると、レジストリが該当するカタログ情報を返す仕組みだ。
ai-catalog.json を設置カタログが公開者の自社ドメインに置かれることで、ドメイン所有権が公開者の検証手段として機能する。本番運用では、暗号化された信頼メタデータを付与し、接続前に公開者の身元を確認することも可能だ。ツールが選定された後は、ARDの役割は終了し、実際の接続は各ツール固有のプロトコルで直接行われる。
誰に向けた仕様なのか
ARDが主に対象とするのは、APIやMCPサーバー、エージェントといった「呼び出し可能な機能」を提供する企業だ。ツールを公開する企業には、AIエージェントに見つけてもらい、信頼してもらうための明確な方法が提供される。
一方、一般的なコンテンツサイトにとっては、現時点で直接的な活用方法は示されていない。Search Engine Journalの記事でも「典型的なコンテンツサイトに今日すぐ取るべきアクションはない」と指摘されている。
公開当日に登場した参照実装
ARDの草案公開と同日に、複数の参加企業が実際に動作するツールをリリースした。
- GitHub Copilot向けに「Agent Finder」を導入。選択したレジストリからMCPサーバー、スキル、ツール、エージェントを検出し、ユーザーが接続対象を制御できる仕組みだ。
- Hugging Face ARDサービス全体からスキルやMCPサーバーを検索する「Discover Tool」を公開した。
- Cisco Linux Foundation傘下のオープンソースプロジェクト「AGNTCY Agent Directory」にARDを統合した。
GitHubのAgent Finderは特に関心を集めている。Copilotのユーザーがレジストリから必要な機能を見つけ出し、自分の判断で接続を許可できる設計は、エージェントの自律性とユーザー制御のバランスを取る試みといえる。
この流れは、ウェブの「機械可読層」を整備する一連のオープン仕様の延長線上にある。GoogleはARD公開の2日前にも、AIシステム間で組織知識を共有するための「Open Knowledge Format」仕様を発表している。いずれも自社ドメインに構造化ファイルを設置するだけで、AIシステムが人手の配線なしに情報を利用できるようにする考え方だ。
Googleの立ち位置と今後の展開
GoogleはARDにおいて、Gemini Enterprise Agent Platformの一部である「Agent Registry」を中心的な役割として位置づけている。これはエージェント向けリソースのホスティングと検索、企業向けのガバナンス管理を担う基盤だ。
Search Engine Journalの記事によれば、Agent RegistryへのネイティブARD対応は数カ月以内に予定されている。これが実現すれば、組織は内部レジストリを広域ネットワークに接続できるようになる。
ただし現時点でこの対応は稼働しておらず、ARDはあくまで「仕様」であってGoogle検索の機能ではない。検索エンジンとしてのGoogleがARDカタログを直接検索結果に反映するわけではない点は、区別して理解しておく必要がある。
コンテンツ制作者が今考えるべきこと
ARDがもたらす影響は、ビジネスの性質によって大きく異なる。ツールやAPIを提供する企業には、AIエージェントに発見されるための具体的な手段が用意された。一方で、一般的なコンテンツサイト運営者にとっての即効性は限定的だ。
この仕様の価値については業界内でも議論がある。GoogleのJohn Mueller氏は、LLMシステムがllms.txtのようなファイルでサイトを区別することはできないと指摘し、将来のエージェント向け戦略よりも現在のニーズに注力するよう助言している。ARDが対象とするのはツールやエージェントであり、コンテンツではないという点は、こうした議論の背景として押さえておきたい。
仕様はまだv0.9草案であり、GitHubリポジトリで変更提案を受け付けている段階だ。実用性を左右するのは、カタログを大規模にクロールしてインデックス化できるレジストリのエコシステムだが、それもまだ初期段階にある。
エコシステムが成熟した場合に最も恩恵を受けるのは、他者が必要とするツールやエージェントを提供する企業だ。GoogleがUlrtaユーザー向けに展開し始めたエージェント主導の検索機能も、この方向性を示唆している。今すぐ取るべき現実的なアクションは、自社が使っているプラットフォームやツールがARDに対応するかどうか、そして対応時にどのような公開情報が求められるかを注視することだ。
この記事のポイント
- ARDはAIエージェントがツールやAPIを実行時に自動発見するためのオープン仕様である
- カタログ（ai-catalog.json）とレジストリの2層構造で、ドメイン所有権が信頼の基盤となる
- GitHubやHugging Faceが公開初日から参照実装を提供しており、実用化に向けた動きは速い
- 一般的なコンテンツサイトよりも、ツールやAPIを公開する企業に直接的な恩恵がある
- v0.9草案段階であり、レジストリのエコシステム構築が今後の鍵を握る
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressコミュニティの魅力と現実。2026年WordCamp Canadaリードが語る
WordPressコミュニティは、技術者が集まるだけの場ではない。2026年のWordCamp Canadaでリードオーガナイザーを務めるCathy Mitchell氏は、WP Tavernのポッドキャスト「Jukebox」でコミュニティがもたらす帰属意識と充足感の重要性を語った。特に子育てが一段落した後の「エンプティネスター（空の巣症候群）」世代にとって、この場は単なる交流を超えた意味を持つ。
オープンで、障壁が少なく、誰でも重要な役割を任される文化。この特異な環境は、従来の企業社会や他のボランティア組織とは一線を画す。Mitchell氏の経験は、経済的な見返りだけでは測れない貢献の価値と、変化する時代の中でWordPressが直面する課題を浮き彫りにした。
「掃除だけ」では終わらない、圧倒的にオープンな門戸
WP TavernのポッドキャストでNathan Wrigley氏との対談に臨んだMitchell氏は、2007年からWordPressに関わるベテランだ。育児休暇中の個人的なプロジェクトから始まった活動は、2008年にWPBaristaとして事業化した。
彼女が強く印象に残っているのは、コミュニティに参加した際の障壁の低さだ。多くの企業組織では、意味のある仕事を任されるまでに長い下積み期間が必要となる。一方で、WordPressコミュニティの文化はまったく異なる。Mitchell氏は昨年、WordCamp Canadaの運営チームに参加した際の驚きをこう表現している。「企業の世界では、何か意味のあることを任されるまで、延々と掃除をさせられるようなものだ。でもここでは違った」。
この「イエスと言う」文化は、参加者の能力を信頼し、失敗しても周囲が支える構造の上に成り立っている。Mitchell氏も、その流れに乗って気づけばWordCamp Canadaのリードオーガナイザーに抜擢されていた。
「見返りゼロ」の貢献が事業の追い風になる仕組み
WordPressは長らく右肩上がりの市場シェア拡大を続けてきた。その間、企業によるイベントスポンサーやコミュニティ貢献は、必ずしも厳密な投資対効果を問われなかった面がある。上昇気流に乗っていれば、自然とビジネスも成長したからだ。
しかしMitchell氏は、現在の状況を「完璧な嵐」と表現する。経済の不透明感から企業の財布のひもは固くなり、代理店やプラグイン開発の競争は激化した。WP Tavernの対談で彼女が指摘したように、かつては広告すら打つ必要のなかったビジネスモデルは、もはや通用しなくなっている。
一方で、オープンソースプロジェクトへの貢献が間接的にビジネスを支える構造にも言及している。具体的なメリットは3つある。
- 採用の容易さ。貢献活動で名前が知られていれば、優秀な人材が応募しやすくなる。
- 人材の見極め。普段のコントリビューション（貢献活動）を通じて、スキルや人柄を事前に評価できる。
- エコシステム全体の健全化。WordPress自体が衰退すれば、自社ビジネスも立ち行かなくなる。
Mitchell氏は、経済的なROIだけでは説明できない利他的な価値と、それに伴う事業上の副次的利益を明確に区別していた。それがコミュニティスポンサーの継続を支える論理となっている。
「孤独の処方箋」としてのコミュニティ
今回のポッドキャストで特に印象的だったのは、Mitchell氏が「奉仕」を孤独への解毒剤と位置づけた点だ。
対談では、米国公衆衛生局長官が2023年に「孤独の流行」を宣言した統計が紹介された。週15箱の喫煙に匹敵する健康被害をもたらすとされ、特に18歳から24歳の若年層の79%が孤独を感じているというデータがある。技術の進化とこの数字の上昇は、無関係ではないというのが両者の共通認識だった。
Mitchell氏は、ボランティア活動がこの問題への強力な回答になり得ると語る。共通の目標に向かって他者と協力し、自分のスキルを誰かのために使う体験は、「役に立っている」という実感と強い連帯感を生む。WordPressコミュニティには、高い専門性を持つ技術者から、コーヒーを淹れるという気軽な貢献まで、あらゆる参加形態が用意されている。
技術者が自発的に集い、支え合う文化は、AIが浸透する時代にこそ希少価値を持つ。人間同士の直接的な交流が幸福感の基礎になるという考え方は、デジタルネイティブ世代にWordPressコミュニティの意義を伝える上で、強力なメッセージとなるだろう。
次世代をオープンソースに引き込むために
対談の終盤、Mitchell氏はWordCamp Canada 2026への意気込みを語る中で、Open Sourceの未来に向けた重要な視点を示した。それは「若者を巻き込まなければならない」という強い危機感だ。
彼女の考えは明快だ。かつてWordPressの成長期に恩恵を受けた世代には、今こそ次世代に扉を開く責任がある。具体的には、大学の単位取得と連携する「Campus Connect」や「WordPress Credits」といったプログラムをカナダ国内で拡大したいとしている。これにより、学生は卒業要件を満たしながら、オープンソースの文化や実務スキルに触れることができる。
Mitchell氏は、オープンソースとAIの組み合わせにこそ未来があると確信している。AIがクローズドな有料APIに囲い込まれれば、テクノロジーの進歩は限定的になる。オープンなコードベースと、それを支える人間のコミュニティがあってこそ、技術は広く社会に還元されるという信念だ。
ただし、この構想が簡単に実現するわけではない。人々の関心を引き、参加の重要性を伝えるのは、依然として難しい課題だ。しかし、今のうちに基礎を固めておかなければ、WordPressを取り巻く楽観的な未来は描けない。Mitchell氏が主導するWordCamp Canadaは、まさにそのための土台作りの場となる。
この記事のポイント
- WordPressコミュニティは「イエス」を基本とするオープンな文化で、未経験者にも門戸が開かれている。
- 企業によるコミュニティ貢献は、短期的なROI以上に採用や業界の健全化に寄与する。
- ボランティアによる共通目標へのコミットメントは、現代の孤独問題に対する有効な解毒剤となり得る。
- 次世代をOpen Sourceに引き込む教育連携が、WordPressエコシステムの長期的な存続には不可欠だ。
- 2026年のWordCamp Canadaは、経済的逆風下でもコミュニティの価値を再定義する試金石となる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Multigres v0.1 α版リリース、Postgres向け水平スケーリングOSの概要
2026年6月4日、SupabaseのチームがオープンソースプロジェクトMultigresの初のパブリックマイルストーンとなるv0.1 Alphaを公開した。このプロジェクトはPostgresにVitess級の水平スケーリング、高可用性、運用のシンプルさをもたらす「オペレーティングシステム」を目指している。
v0.1 Alphaでは高度なコネクションプーリング、自動フェイルオーバー、Kubernetesオペレーターが提供される。シャーディング機能は今後のリリースで追加予定だ。以下の記事ではその設計思想と仕組みを掘り下げる。
Multigresとは
・フェイルオーバーは運用者が判断
・コネクション制限への個別対処
・バックアップは別ツールで管理
・自動フェイルオーバーでダウンタイム最小
・コンテキスト認識型コネクションプーリング
・バックアップとリストアを統合管理
MultigresはPostgresインスタンスを包括的に管理する「スケーラブルなオペレーティングシステム」だ。シャーディング、コネクションプーリング、自動フェイルオーバー、バックアップオーケストレーションを単一のシステムで提供する。
Postgresスケーリングの課題
Postgresを大規模に運用する際、読み取りレプリカの管理、フェイルオーバーの対応、コネクション上限対策、バックアップのスケジューリングなど、運用負荷が高い。これらをバラバラのツールで解決しようとすると、複雑さが増していく。
Multigresが解決すること
Multigresはこれらを一貫したシステムとして自動化する。データベースのスケールが必要になったタイミングでシャーディングも処理し、水平スケーリングを実現する。v0.1 Alphaではまだ単一シャードだが、基盤は整っている。
Kubernetesオペレーター
Kubernetesオペレーターによって、Multigresクラスタのデプロイと管理が抽象化される。必要なのはKubernetesクラスタとバックアップ用のストレージ（共有ファイルシステムやAWS S3バケット）だけだ。ローカルのKindクラスタでも動作検証が可能で、必要なコンテナイメージはすべて公開されている。
高可用性（HA）の仕組み
データの不整合やコミット消失のリスク
耐久性ポリシーをユーザーが自由に定義可能
MultigresはHAを合意形成の問題として扱い、スプリットブレインが起きてもコミット済みデータを失わない。これを一般化合意（generalized consensus）モデルで実現している。これは従来のコンセンサスベースシステムにはない柔軟性をもたらす。
一般化合意モデル
Multigresは無修正のPostgresレプリケーションの上に実装されており、厳密な一貫性要件を満たす。さらに、過半数のクォーラムのような制約に縛られず、ユーザーが任意の耐久性ポリシーを定義できる。例えば「単一のアベイラビリティゾーン（AZ）障害に耐える」を設定すれば、それ以上のゾーンにスタンバイを配置することも可能だ。
レプリカの動的追加と削除
クラスタ稼働中にレプリカを安全に増減できる。パフォーマンスに影響を与えず、設定された耐久性ポリシーと整合性を保ったままスケーリングが可能だ。
コネクションプーリングの革新
Multigresは独自の2サービスアーキテクチャによるコネクションプーリングを採用している。クライアント接続を受け付ける「multigateway」と、バックエンド接続を管理する「multipooler」で構成され、単一プロセスのプーラーにはない利点がある。
トラフィックルーティングとフェイルオーバー
HAシステムとの統合により、multigatewayは常に現在のプライマリに透過的に接続を転送する。フェイルオーバー発生時は新しいプライマリが昇格するまでリクエストを保留し、エラーを最小化する。読み取り負荷は複数レプリカに分散可能で、将来的にはシャード間のルーティングにも対応予定だ。
コンテキストアウェアプーリング
Multigresはトランザクションやセッションといったプーリングモードを明示的に選択する必要がない。組み込みのパーサーが各リクエストの効果を理解し、接続状態を追跡する。ステートフルなトランザクションが必要な場合だけ接続をそのクライアントに固定し、それ以外は再利用する。
ユーザー別プールとプリペアドステートメント
ユーザーごとに独立したコネクションプールを保持し、SET ROLEによるなりすましを使わない。固定の接続予算をフェアシェアアルゴリズムで分配する。さらに、プリペアドステートメントはゲートウェイ間で重複排除され、Postgres側で文の解析、計画、キャッシュが1回だけ行われる。
バックアップ戦略
MultigresはバックアップにpgBackRestを使用し、プライマリに負荷をかけないようレプリカから取得する。バックアップの種類は完全、増分、差分の3つで、通常は定期的な完全バックアップと短い間隔の増分・差分を組み合わせる。
オンデマンドとスケジュール
CLIでバックアップの一覧表示や手動バックアップ、リストアが可能だ。スケジュール機能は今後のクラスタスペックを通じて追加予定となっている。
クラスターブートストラップ
クラスタ起動時にMultigresが自動的にプライマリを特定し、バックアップを取得して他のレプリカを初期化する。これにより人手を介さずに即座に利用可能なクラスタが立ち上がる。
アルファ版の制限と今後の展望
・既知の課題がGitHubイシューにあり
・将来バージョンとの後方互換性は保証されない
・CR APIが安定していない
・パフォーマンスベンチマーク未公開
・スケジュールバックアップのサポート
・APIの安定化とベンチマークの公開
・コミュニティからのフィードバック集約
v0.1 Alphaは実験とフィードバックに十分な安定性を持つが、本番運用にはまだ適さない。シャーディングは今後のリリースで追加予定の主力機能であり、現在はHAとプーリングを備えた単一シャードクラスタの形で提供されている。ベータやv1.0に向けてAPIの安定化とベンチマークの公開が進められる見通しだ。
この記事のポイント
- MultigresはPostgresのスケーリングと運用を自動化するオープンソースOS
- v0.1 AlphaでKubernetesオペレーター、HA、高度なコネクションプーリングを提供
- 一般化合意モデルによりスプリットブレインを安全に解決
- コンテキストアウェアプーリングでモード選択不要、ユーザー別プールも実装
- シャーディングは将来リリース予定、現在はフィードバック収集段階
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WCEU 2026クラクフ開催。CERN基調講演とWordPress 7.0全容
# フロントマター
— title: “WCEU 2026クラクフ開催。CERN基調講演とWordPress 7.0全容” meta_description: “WordCamp Europe 2026がポーランド・クラクフで開催。CERNのWordPress移行基調講演、WordPress 7.0のAI機能、ビジネスセッションなど主要トピックを解説。WCUS 2026は8月フェニックスで。” tags: [“WordPress”, “WordCamp”, “WordCamp Europe”, “WCEU 2026”, “WordPress 7.0”, “CERN”, “AI”, “オープンソース”] slug: “wceu-2026-krakow-recap” scrape_method: “trafilatura” image_prompt: “Upper portion: the CERN logo (a stylized double-ring emblem with intertwining loops) prominently displayed in photorealistic 3D with subtle metallic reflections. Lower portion: the ICE Kraków Congress Centre with a vibrant WordCamp Europe banner outside, attendees networking in the plaza. Composition: split-screen style with key visual elements positioned in the upper and lower portions of the frame, with a natural atmospheric transition in between, no horizontal bands or strips across the frame. 16:9 aspect ratio. If UI screens, dashboards, code editors, or admin panels appear, all text within them must be in English. If laptops or monitors appear, use ultra-thin bezel modern design. No visible year numbers on calendars, screens, or documents.” featured_text: “WCEU 2026 全容\nCERNが語るWP採用理由”
— —
WordCamp Europe 2026が6月4日から6日まで、ポーランド・クラクフのICE Kraków Congress Centreで開催された。81カ国から2,458人のチケット保有者が集まり、うち約4人に1人が初参加という大規模なイベントとなった。
基調講演にはCERN（欧州原子核研究機構）のウェブチームが登壇し、世界初のウェブサイトを公開した研究機関がWordPressを採用した理由と具体的な移行手法を明かした。WordPress 7.0のAI機能も多数のセッションで取り上げられ、コアに組み込まれたAIクライアントやAbilities APIの実用性が議論されている。
ここでは3日間の主要セッションと、今後のWordPressを取り巻く技術潮流を整理する。
基調講演は大手企業や著名開発者が中心。新機能の発表が主目的。
CERNによる研究機関視点の採用根拠、AIとオープンソースの本質的議論、教育プログラムの具体的成果が前面に。
—
Contributor Dayが作り出す協働の場
本編開始前日の6月3日、会場にはContributor Day（コントリビューターデー）が設けられた。これはWordPress本体の改善に直接取り組む実務作業日であり、講演を聞くのではなく実際に手を動かす場だ。午前中に登録と歓迎セッションが行われ、参加者はPolyglots（翻訳）、Documentation（文書）、Support（フォーラム回答）、Core（本体開発）、Performance（パフォーマンス）、Testing（テスト）、Themes（テーマ）、Plugins（プラグイン審査）などの各テーブルに分散した。
経験者が新規参加者を一人ずつ引き受け、初めてのパッチや翻訳文字列、サポートチケット対応を手ほどきする仕組みが整えられていた点が特徴的だ。会場に行けなかった参加者も、Make WordPress Slackの #contributor-day チャンネルを通じてリモート参加できた。
ここで注目すべきは、プラグイン審査チームの存在感だ。同チームはディレクトリに登録される全てのプラグインを審査する役割を担っており、初期参加者にとっては「誰がどのような基準で審査しているのか」を直接知る貴重な機会となった。
—
CERN基調講演。世界初のウェブサイトがWordPressを選んだ理由
開幕基調講演に立ったのはCERNのウェブマネージャー、Joachim Valdemar Yde氏とWordPressインフラ責任者のFrancisco Borges Aurindo Barros氏だ。CERNは30年以上前にティム・バーナーズ＝リーがWorld Wide Webを発明した場所であり、その研究機関がなぜWordPressを次期ウェブ基盤に選定したのかが語られた。
CERNの設計思想は明確だった。研究者やスタッフはコンテンツ制作に集中し、ウェブチームが基盤全体を管理する。セルフサービスポータルから数クリックでサイトを申請でき、共通テーマとセキュリティ審査済みのプラグイン一式が自動適用される。初年度だけですでに数百のサイトが立ち上がったという。
Yde氏は会場にこう告げた。「本日より、CERNの旗艦サイト home.cern はWordPressで稼働している。自動移行を経て、すでに本番公開済みだ」
この発表が持つ象徴的な意味は大きい。Webを発明した機関が、いまWebの40%以上を動かすオープンソースソフトウェアを自ら選び、GPLライセンスの下で運用している。この対称性は、オープンソースコミュニティにとって強力な支持材料となるだろう。
—
WordPress 7.0とAI。コアに組み込まれたネイティブAIの実像
WCEU 2026を通じて最も多くのセッションを横断していたテーマが、WordPress 7.0とAIの融合だった。単なる機能アップデートではなく、WordPressが「どう変わるか」の方向性を示す議論が展開された。
AIクライアントとAbilities APIの設計思想
パネルセッション「Inside WordPress 7.0」には、Juan Manuel Garrido氏、Adam Silverstein氏、Benjamin Zekavica氏、Sarah Norris氏、Milana Cap氏らリリース貢献者が登壇した。ここで明らかにされたのは、WordPress 7.0に実装された3つの中核的変革だ。
- ネイティブAIクライアントのコア実装
- Abilities API。プラグインが自身の機能を宣言し、他のツールから発見可能にする仕組み
- Connectors画面。OpenAI、Anthropic、Google GeminiなどのAIプロバイダーを管理画面から接続できる管理インターフェース
パネルでは単なる機能一覧にとどまらず、大規模なリリースがオープンに進行する過程そのものが解説された。貢献ワークフロー、複数チーム間の調整、公開状態でソフトウェアを出荷する人間的側面までが議題に上った点は、これまでのリリース説明とは一線を画す。
実務者たちが示した具体的ユースケース
Anukasha Singh氏はAbilities APIに焦点を当て、プラグイン権限のチェックを従来のcapability（権限）方式よりクリーンかつ安全にできることを示した。Vito Peleg氏のワークショップでは、単発のAIプロンプトから一歩進み、ライブサイトを監査して構造化チケットを自動生成するツール活用ワークフローが実演された。
WP-CLIメンテナーのAlain Schlesser氏は、AIアシスタントやAI検索がオープンウェブに実トラフィックをもたらしている現状を数字で示した。2025年半ばまでに10億件以上の参照訪問が記録されており、WordPressはその流入を受け止める準備ができていると指摘する。氏のセッションは、サイトがAIに「発見され、読まれ、引用される」ための実践的チェックリストとして構成された。
Tammie Lister氏の「Human in the loop means something」は、AI導入が議論される中で「人間がループにいる」というフレーズを単なるチェックボックスではなく本物の責任として捉え直した。人間とAIは得意分野が異なり、優れたプロダクトはそれぞれの強みを活かす設計になるべきだ、という主張だ。
—
「つくる」現場の開発セッション
開発トラックでは、技術の深掘りが光った。Dennis Snell氏はHTML APIとブロックパーサーの設計に携わった立場から、HTML APIの内部構造と活用方法をワークショップ形式で解説した。Peter Wilson氏はパフォーマンスチームの長期コミッターとして、WP_Queryクラスのキャッシュ改善による高速化と、大規模サイトでの活用法を詳述している。
スケーリングに関するハンズオンセッションでは、12ドルの仮想サーバーでWordPressがどこまで耐えられるかをGrafanaでプロファイリングしながらチューニングする実演が行われ、GitHubリポジトリも公開された。Fellyph Cintra氏はWordPress Playgroundの最新状況を取り上げ、ブラウザベースのツール群とアーキテクチャ変更による高速化の成果を報告した。
Jessica Lyschik氏のセッションは、アクセシビリティ対応の要件が多くのテーマ開発者が想定するよりはるかに達成しやすいことを、ブロックテーマとクラシックテーマの実審査事例をもとに論じた。プラグイン審査チームのDavid Perez氏とFran Torres氏は、25,000件以上のプラグイン審査経験から、よくある回避可能な問題と審査待ち期間を短縮する具体的ノウハウを公開した。
—
ビジネスとオープンウェブをめぐる議論
ビジネストラックでは、感傷を排した実践的な内容が続いた。Debbie Levitt氏は3つのレイヤーで同時にプロダクトマーケットフィットを追求するモデルを提示し、「チームが一つの良い指標を祝った数ヶ月後、なぜユーザーが去ったのかわからなくなる」という問題に切り込んだ。Vassilena Valchanova氏は、仕事ができることと、それを周囲に知られていることは別物だという、スキルと認知のギャップをテーマに据えた。
クラクフを拠点とするフルスタック開発者Irfani Silviana氏は、Business Model Canvasを「開発者が機能出荷から事業価値の創出へ視点を移すための変換レイヤー」と位置づけ、地元での登壇にふさわしい内容を披露した。
—
クロージングセッション。教育、AI、オープンソースの交差点
最終日のクロージングでは、クラクフ工科大学の代表者が登壇し、WordPressエグゼクティブディレクターのMary Hubbard氏に情報数学部からの贈り物を手渡した。同大は2026年10月からWordPress専門コースを開講する。これはポーランド国内だけでなくWordPressコミュニティ全体にとっても先駆的な取り組みだ。
Hubbard氏はGutenbergプロジェクトリードのMatías Ventura氏と、WordPressデザイナー兼開発者のRich Tabor氏をステージに招き、WordPressの将来方向性を議論した。Ventura氏はWordPress 7.0のリリースリードを務めたばかりで、まず全貢献者にスタンディングオベーションを求めた。
- ● クラクフ工科大学のWordPress専門コース開講（2026年10月〜）
- ● WordPress Campus ConnectとWordPress Creditsの教育プログラム成果
- ● AIとWordPressの関係。デザインシステムの長期的投資がAI連携で成果を上げている
- ● WP-CLIをAIモデルが流暢に利用。Studio Codeエージェントベースのコーディングツール開発
- ● USパイロット版AIリテラシーマイクロクレデンシャル。WordPressを学習の場に活用
Hubbard氏はオープンソースとAIの関係について、明確な立場を示した。「オープンソースこそがWordPressの成長を支えてきた。同じ価値観がAIを形作るべきであり、コミュニティはもっと声高に主張すべきだ」
—
この記事のポイント
- WCEU 2026には81カ国から2,458名が参加。CERNがWordPress採用の基調講演を実施
- WordPress 7.0にネイティブAIクライアント、Abilities API、Connectors画面が実装された
- AI関連セッションでは「人間とAIの役割分担」「実務的な監査自動化」が具体的に語られた
- 開発トラックではWP_Queryキャッシュ改善、HTML API、アクセシビリティ対応の実審査事例が共有された
- クラクフ工科大学が2026年10月よりWordPress専門コースを開講。教育分野での広がりが加速している
—
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
VoidZeroがCloudflareに参画、ビルドツールViteはオープンソースを維持
Vite、Vitest、Rolldown、OxcといったJavaScriptエコシステムの中核ツールを開発するVoidZeroが、Cloudflareに参画した。全チームメンバーがCloudflareに合流する大規模な動きだ。
この発表で最も強調されているのは、これらのプロジェクトがこれからもオープンソースであり続けるという点だ。ViteはMITライセンスを維持し、ベンダーに依存せず、コミュニティ主導で開発が進められる。この原則が揺らぐことはないとCloudflareは明言する。
背景には、AI時代のソフトウェア開発の変化と、フルスタック化するモダンアプリケーションの複雑さがある。Viteがエコシステム全体の共有基盤となった今、この参画はツールチェーンの未来を左右する重要な転換点だ。
VoidZeroのCloudflare参画の内容
オープンソースとベンダー中立の堅持
Cloudflareは、Viteや周辺ツールの独立性を何よりも優先するとしている。具体的な約束は以下の通りだ。
- Vite、Vitest、Rolldown、Oxc、Vite+は今後もMITライセンスのオープンソースであり続ける
- 特定のクラウドベンダーに依存しない設計を維持する。Viteで構築したアプリケーションは、どこでも動作し続ける
- ロードマップはViteチームとコミュニティが引き続き主導し、公開の場で開発される
- Evan You氏をはじめとするVoidZeroチームが、プロジェクトのリーダーシップを継続する
- Cloudflareはこれらのプロジェクトにエンジニアリングリソースを投入するが、方向性を自社向けに曲げることはしない
Cloudflareのブログ記事では、このコミットメントを「言葉ではなく、日々の開発支援とプロジェクト運営で証明していく」と表現している。年初にAstroがCloudflareに参画した際と同様の、独立性を尊重するモデルだ。
100万ドルのViteエコシステム基金
この参画に伴い、CloudflareはViteエコシステム基金として100万ドルを拠出する。この基金はViteのコアチームによって管理され、メンテナーやコントリビューターへの支援に充てられる。
「ViteはVoidZeroやCloudflareよりも大きな存在だ」とCloudflareは述べており、エコシステムを支える無数の開発者を巻き込む意図が明確に示された。オープンソースの持続可能性を金銭面から支える、具体的な施策である。
この比較から分かるように、今回の参画はエコシステムの信頼を損なわないための設計が徹底されている。Viteが多くのフレームワークに採用されている共有基盤だからこそ、中立性の維持は絶対条件となる。
AIが変えたビルドツールの役割
エージェントがツールチェーンを回す時代
Cloudflareのブログ記事は、Viteの驚異的な普及の背景にAIの存在があると分析する。現在Viteの週間ダウンロード数は約1億2900万回、Cloudflare Viteプラグイン（@cloudflare/vite-plugin）は約1400万回に達している。これはVite本体のダウンロード数の10%を超える規模だ。
この急成長を牽引しているのが、AIコーディングエージェントだ。開発者だけが使っていた開発サーバーやリンター、フォーマッターを、今やAIエージェントが常時利用している。彼らはプロジェクトのスキャフォールディングから開発サーバーの起動、エラー解析、テスト実行までを自動で行う。
エージェントにとって重要なのは、高速なフィードバックループだ。ビルドが速く、テストが速く、エラーが明確で、CLIの挙動が一貫していること。VoidZeroのツールチェーン（Vitest、Rolldown、Oxc、Oxlint、Oxfmt）は、まさにこの要件に最適化されている。それぞれのカテゴリで最速クラスの性能を持ち、エージェントが何度も繰り返し実行してもストレスが少ない。
この図は、AIエージェントがコード生成からテスト、リント、修正までのサイクルを高速に回す様子を表している。各ツールの応答速度がエージェントの生産性に直結するため、VoidZeroのツールチェーンが選ばれる理由が明確になる。
フルスタック化するViteとVoidの知見
ビルドツールを超えた役割
モダンなアプリケーションは、単なる静的ファイルのバンドルでは完結しない。サーバーサイドレンダリング、API、バックグラウンドジョブ、キュー、データベース、オブジェクトストレージ、リアルタイム通信、認証、そしてAIエージェントの統合までが必要になる。
Viteはこれに対応するため、ビルドツールからフルスタックアプリケーションの基盤へと進化しつつある。Cloudflareはこの流れを加速させるために、Vite本体にプロバイダ非依存の抽象化レイヤーを追加していく方針だ。バックエンド、API、エージェント、デプロイメントのためのフックをVite側に用意し、各クラウドベンダーがそれを実装する形を目指している。
すでにVoidZeroが実験していた「Void」プラットフォームの知見が、この方向性を後押ししている。VoidはVite向けのデプロイメントプラットフォームとして設計され、モダンアプリのライフサイクル全体を一つのツールチェーンで統一する試みだった。Cloudflareは将来的にこのVoidプラットフォームをオープンソース化し、誰でも独自のプラットフォームをVite上に構築できるようにする計画も示している。
Workerd統合による開発体験の向上
CloudflareとViteの協業は2024年のVite Environment APIから始まっている。このAPIによって、Viteの開発サーバーはNode.js以外のランタイムでもサーバーコードを実行できるようになった。
Cloudflare Viteプラグインを使用すると、vite devの実行時にサーバーコードがWorkerd（Cloudflare Workersのオープンソースランタイム）上で動作する。Durable Objects、D1、KV、R2、Workers AI、エージェントなど、本番環境と同じランタイムモデルがローカルで再現される。開発環境が本番の劣化版だった時代は、このAPIによって終わりを迎えつつある。
この図が示すように、Environment APIの導入前後で開発体験は大きく変わった。ローカル環境と本番環境のランタイムが一致することで、デプロイ後の予期せぬエラーが激減する。
CloudflareがVite基盤に移行する意味
CLI統合とcfコマンドの未来
Cloudflareは自社ツールの方向性を「Viteに合わせる」と明確に宣言している。最近テクニカルプレビューが公開された新しい統合CLI「cf」は、Viteを基盤として設計される。
このCLIの目指す姿は、ViteのエルゴノミクスをそのままCloudflareプラットフォーム全体に拡張することだ。cf devはvite devのスーパーセットとして動作し、同じ速度、同じホットモジュールリプレースメント、同じプラグインモデルを持ちながら、必要に応じてCloudflareのランタイムとバインディングを利用できる。cf buildはViteプロジェクトをネイティブに理解し、cf deployはViteアプリのデプロイをシンプルにする。
すでにCloudflareのダッシュボード自体がVite上に構築されており、OxlintはCloudflareのコードベースで「数日分のエンジニアリング時間を節約している」と報告されている。Astroチームのエージェントハーネスフレームワーク「Flue」もVite基盤に移行中だ。Cloudflare自身がViteをドッグフーディングし、その価値を内部で証明している。
短期的な影響と長期的な展望
短期的には、Viteユーザーにとって何も変わらない。Vite、Vitest、Rolldown、Oxc、Vite+は引き続きリリースされ、VoidZeroチームがこれらを主導する。Cloudflare Viteプラグインも改善が続き、Environment APIもCloudflare以外のランタイムを含めて進化していく。
長期的には、CloudflareのCLIがVite上に完全に統合される。Viteにはフルスタックアプリとエージェントのためのプロバイダ非依存のプリミティブが追加され、あらゆるプラットフォームで利用可能になる。そしてVoidプラットフォームがオープンソース化され、誰でもViteとCloudflareの上に独自のプラットフォームを構築できるようになる。
この計画が実現すれば、ViteはJavaScriptエコシステムの単なるビルドツールから、アプリケーション開発全体を支える普遍的な基盤へと進化する。Cloudflareのインフラは、その基盤の上で最も統合された選択肢の一つとして位置づけられることになる。
この記事のポイント
- VoidZeroの全メンバーがCloudflareに参画。ViteやVitestなどのツールはMITライセンスのままでベンダー中立を維持する
- CloudflareはViteエコシステム基金として100万ドルを拠出し、コミュニティ主導の開発を資金面から支援する
- Viteの週間ダウンロード数1億2900万回の背景には、AIエージェントによる高速フィードバックループ需要がある
- Environment APIにより、ローカル開発環境でも本番と同じWorkerdランタイムが使用可能になった
- Cloudflareの新CLI「cf」はViteを基盤に統合され、全プラットフォームで一貫した開発体験を提供する計画だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験