DockerがカスタムMCPカタログとプロファイルを正式提供、企業のAIツール管理が新段階へ
Dockerは2026年5月15日、MCP（Model Context Protocol）サーバーを管理する「カスタムカタログ」と「プロファイル」の一般提供を開始した。組織はこれらを使ってMCPサーバー群を一元的に管理し、開発者は作業内容に応じたツール構成を簡単に切り替えられるようになる。
この発表の背景には、企業へのMCP導入が進むにつれて「誰がどのMCPサーバーを信頼して使うべきか」という調整コストが急増していた現実がある。Dockerの新機能は、プラットフォームチームが推奨するツール群を「カタログ」として配布し、現場の開発者が「プロファイル」で自由に組み替えるという二層構造でこの課題を解決する。
MCP活用の壁とDockerの解決策
MCPはAIエージェントが外部ツールやデータソースと対話するための標準プロトコルだ。ChatGPTのプラグイン機能に相当するが、ベンダーに依存せずオープンな仕様で設計されている。Dockerは2025年後半からMCPサーバーの統合管理機能「MCPカタログ」を提供してきたが、公開サーバーだけでは社内ツールや独自要件に対応しきれないという声が増えていた。
特に大きかったのは「全社で使える信頼済みリストがほしい」というニーズと「開発者個人のワークフローに合わせた構成を使いたい」というニーズのせめぎ合いだ。前者を強めると開発者の自由度が下がり、後者を優先するとセキュリティ基準が守れなくなる。Dockerが今回一般提供を始めたカスタムカタログとプロファイルは、この二つを両立させるインフラにあたる。
カスタムカタログとプロファイルの役割分担
カスタムカタログは「組織が推奨するMCPサーバーの集合」を定義し、OCIアーティファクトとして配布できる仕組みだ。プロファイルは個人がカタログから選んだサーバー群を「コーディング用」「企画用」といった用途別にまとめ、クライアント（Claude Codeなどのエージェント）に切り替えて接続できる。
この二層構造によって「組織が定める信頼の枠組み」と「個人が工夫する効率化」が衝突しなくなる点が最大の価値だ。プラットフォームチームはガードレールを引き、開発者はその中で自由にツールを組み替える。
カスタムMCPカタログの作成と配布手順
Dockerの公式ブログで解説されている手順に沿って、実際にカスタムカタログを作成する流れを見ていこう。ここではDocker Hubをレジストリとして使う例だが、プライベートレジストリにも対応する。
ステップ1 自前のMCPサーバーをイメージ化する
まず、組織内で使いたい独自のMCPサーバーをDockerイメージとしてビルドし、レジストリにプッシュしておく。Dockerの解説では、さいころを振るroll-diceというサンプルサーバーが使われている。stdioで通信する標準的なMCPサーバーであり、Dockerfileからイメージを作成する手順は通常のコンテナ開発と変わらない。
イメージが用意できたら、そのサーバーのメタデータをYAMLファイルに記述する。ファイル名や格納場所は任意だ。
name: roll-dice
title: Roll Dice
type: server
image: roberthouse224/mcp-dice@latest
description: An mcp server that can roll diceこのYAMLにはサーバーの識別名、表示タイトル、Dockerイメージの参照先、説明文が含まれる。実際の運用では、ここにアクセス権限や設定パラメータのメタ情報を追加することも考えられる。
ステップ2 Docker MCPカタログと自前サーバーを束ねる
次に、docker mcp catalog createコマンドを使ってカスタムカタログを作成する。引数にはDocker公式カタログから取り込みたいサーバーと、先ほど用意したYAMLファイルのパスを指定する。
docker mcp catalog create roberthouse224/our-catalog \
--title "Our Catalog" \
--server catalog://mcp/docker-mcp-catalog/playwright \
--server catalog://mcp/docker-mcp-catalog/github-official \
--server catalog://mcp/docker-mcp-catalog/context7 \
--server catalog://mcp/docker-mcp-catalog/atlassian \
--server catalog://mcp/docker-mcp-catalog/notion \
--server catalog://mcp/docker-mcp-catalog/markitdown \
--server file://./mcp-dice.yamlcatalog://スキームでDockerの公式カタログから既存のサーバーを取り込み、file://スキームで自作サーバーのメタデータを追加している。このカタログはローカルマシン上にOCIアーティファクトとして作成され、docker mcp catalog showで内容を確認できる。
ステップ3 カタログをレジストリで共有する
作成したカタログは、docker mcp catalog pushでDocker Hubやプライベートレジストリにプッシュすれば即座に共有可能になる。OCIアーティファクトとしての配布は、組織内のリポジトリアクセス権限をそのまま使えるため、追加のインフラ管理が不要だ。
docker mcp catalog push roberthouse224/our-catalogこれで、組織内の他メンバーはDocker Desktopの「カタログインポート」機能か、docker mcp catalog pullコマンドでこのカタログを取得できる。公式カタログにはない社内ツールが含まれている点、すべてのサーバーが組織としての信頼審査を通過している点が、単なる公開カタログとの決定的な違いだ。
カスタムカタログがエンタープライズにもたらす意味
ここで一歩引いて、この機能が企業のAI活用に何をもたらすかを考えてみたい。単なる「MCPサーバーリストの共有」に見えるが、実際にはもっと大きな変化の起点になる。
第一に、MCPサーバーの発見と評価にかかるコストが大幅に下がる。開発者がインターネット上からMCPサーバーを探して安全性を個別に判断する必要がなくなり、組織が「使ってよいもの」をあらかじめ提示できる。これはソフトウェアサプライチェーン管理の考え方をAIツールに応用したものとも言える。
第二に、プライベートレジストリと組み合わせれば、社内限定のAIツールを企業秘密として保護しながら配布できる。たとえば自社データベースに特化したMCPサーバーを、アクセス権のあるメンバーだけに提供する使い方が想定される。Dockerのブログでも「プライベートカタログ」という方向性が示唆されている。
第三に、OCIアーティファクトという既存の業界標準に乗っていることが地味ながら重要だ。組織はすでにコンテナレジストリの運用ノウハウとアクセス管理の仕組みを持っている。それをそのままMCPに転用できるため、新たに専用の配信インフラを構築する必要がない。
このようにカスタムカタログは「野良ツールの乱立を防ぎつつ、社内イノベーションを促進する」バランサーとして機能する。とはいえ、カタログで提供されるのはあくまで「選択肢の集合」だ。実際の作業でどのツールをどう組み合わせるかは、次のプロファイル機能が受け持つ。
MCPプロファイルで個人ワークフローを最適化する
プロファイルは、カタログから選んだMCPサーバー群を「コーディング」「企画」「調査」などの用途別に束ね、任意のAIクライアントに接続できる仕組みだ。特定のプロファイルには必要なツールだけが含まれるため、エージェントのコンテキストウィンドウを無駄に消費しない利点がある。
作業モードの切り替えを数クリックで実現
Docker Desktop 4.63から利用できるプロファイル機能の基本動作はシンプルだ。カスタムカタログを開き、使いたいサーバーを選択して「新しいプロファイル」を作成する。プロファイルには接続先クライアント（Claude Codeなど）を指定できるが、後から付け替えることも可能だ。
たとえば、Playwright、GitHub、Context7を含む「コーディング」プロファイルと、Atlassian、Markitdown、Notionを含む「企画」プロファイルを別々に作っておけば、作業内容に応じてクライアントの接続先を切り替えるだけでツール環境が丸ごと入れ替わる。これまではツールセットを切り替えるたびに再設定が必要だったが、プロファイルによりワンアクションで済む。
設定の保存と再利用で反復作業を削減
プロファイルのもう一つの利点は、MCPサーバーの設定を永続化できることだ。Markitdownサーバーにアクセス可能なディレクトリパスを指定する場合や、GitHubサーバーのうち使うツールをget_meだけに絞る場合など、一度設定した内容はプロファイルに保存される。これにより、毎回手動で同じ設定を繰り返す手間が省ける。
コンテキストウィンドウの最適化という観点では、大量のツールをエクスポートするMCPサーバーに対して「このタスクではツールAとBだけ有効化する」と制限できる点が実用的だ。エージェントの推論性能を落とさず、必要な機能だけに集中させられる。この仕組みは、社内開発するMCPサーバーにリッチな設定オプションを持たせることで、さらに強力な再利用性を発揮するだろう。
上図のように、同じカタログから異なるプロファイルを複数作成し、用途に応じて切り替える運用が基本スタイルになる。この考え方は、VS Codeのワークスペース設定や、ターミナルのプロファイル管理に近い。AIエージェント時代の「作業環境テンプレート」と捉えるとわかりやすいだろう。
プロファイルの共有と今後の展望
プロファイルもカスタムカタログと同様、OCIアーティファクトとしてレジストリで共有できる。docker mcp profile pushでプッシュすれば、チームメンバーはdocker mcp profile pullで即座に同じツール構成を手に入れられる。うまくいった設定を「テンプレート」として展開できるこの仕組みは、プロジェクト立ち上げ時の環境構築コストを大幅に下げる。
docker mcp profile push coding your-namespace/codingDockerは今後、以下の方向性でカスタムカタログとプロファイルを拡張していくとしている。
- ガバナンスとポリシー制御により、承認されたカスタムカタログ以外からのMCP利用を制限
- カタログとプロファイルのディスカバビリティを向上し、実績のある構成を見つけやすくする
- プロファイルスコープでのシークレット・設定値管理を強化し、セキュアな代替手段として整備
- エージェントスキルとの連携により、プロファイルを依存関係として参照するワークフロー
特に最後の「エージェントスキルがプロファイルを依存関係として参照する」という構想は興味深い。たとえば「データ分析スキル」が起動するときに、必要なMCPサーバー構成をプロファイルから自動で引き込むといった使い方が想定されている。これが実現すれば、AIエージェントが自律的に必要なツールを調達して動く世界がさらに近づく。
この記事のポイント
- DockerがカスタムMCPカタログとプロファイルの一般提供を開始し、企業のAIツール管理に新たな基盤が加わった
- カスタムカタログは組織が信頼するMCPサーバー群をOCIアーティファクトで配布し、発見コストとセキュリティリスクを同時に下げる
- プロファイルは個人が用途別にツール構成を保存・切り替えできる仕組みで、コンテキスト最適化にも有効
- 両方ともOCIアーティファクトで共有可能なため、既存のコンテナレジストリ運用の延長でチーム展開できる
- 今後のポリシー制御やエージェントスキル連携により、エンタープライズMCPのガバナンス基盤として発展が見込まれる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AIコーディングエージェントの信頼が悪用される 開発環境の新たな脅威を解説
AIコーディングエージェントが開発現場に急速に浸透している。VS CodeやCursorなどのIDEに組み込まれた自律型AIは、コード生成だけでなくプロジェクト設定の読み取りやコマンド実行、外部サービスとの連携まで自動で行う。便利さの裏で、攻撃者が悪用できる新たな領域が広がっている。
2026年に入り、悪意ある指示ファイルや設定ファイルがVirusTotalに提出される件数は増加傾向にある。これらのファイルは従来のウイルス対策ソフトでは検出されない。構文的に正しいJSONやMarkdownが、AIエージェントにとっては危険な命令になり得るためだ。
この記事では、AIコーディングエージェントがもたらす開発環境の新たな脅威を整理し、具体的な攻撃事例とともに対策を解説する。
AIコーディングエージェントが変える開発環境の脅威
AIコーディングエージェントはIDEやターミナル、拡張機能のランタイムにまたがって動作する。プロジェクトを開くと自動的に設定ファイルを読み込み、必要なツールを起動し、デバッグ環境を整える。この自動化の流れ自体が、攻撃者にとって格好の侵入経路となる。
従来の開発環境では、人間が「実行」ボタンを押すまでコードは動かなかった。しかしAIエージェントは、プロジェクトを開いた瞬間に指示ファイルを解析し、事前定義されたタスクを自律的に実行する。開発者が内容を確認する前に、攻撃者の仕込んだ設定が動き出す可能性がある。
Google Threat Intelligenceのレポートでは、この状況を「攻撃対象がソースコードを超えて拡大した」と表現している。問題はコードの構文ではなく、ファイルが持つ意図そのものに潜むようになった。
従来のマルウェア検知はなぜ通用しないのか
ウイルス対策ソフトやシグネチャベースのスキャナーは、ファイル内に既知の悪意あるコードパターンが含まれているかを検査する。ところが悪意ある設定ファイルの多くは、純粋なJSON、YAML、Markdownとして文法上の問題がない。セキュリティエンジンは「正常なテキストファイル」と判定し、検出をすり抜ける。
根本的な課題は、セキュリティツールが自然言語の指示内容を評価できない点にある。「APIキーを外部サーバーに送信せよ」「ガードレールを無効化せよ」といった指示が平文で書かれていても、従来のスキャナーにはそれが危険だと判断できない。構文解析では意味を読み取れないからだ。
Google Threat Intelligenceが提唱するアプローチは、セマンティック分析への移行だ。ファイルの実際のロジックと文脈をAIで解析し、振る舞いベースでリスクを判定する。VirusTotal Code Insightがこの手法を実装し、シグネチャ検査では見えない脅威を可視化している。
シグネチャ検出とセマンティック分析の違いは明白だ。構文が正しくても、AIエージェントに与える指示内容が危険であれば検出する。これがAI時代のセキュリティに求められる新しい視点である。
狙われる4つの攻撃対象
Google Threat Intelligenceは、AIコーディングエージェントの攻撃対象を4つのカテゴリに分類している。それぞれが独立した脅威であり、かつ複合的に悪用される可能性がある。
4つの領域はそれぞれ独立しているが、実際の攻撃では複数が組み合わさる。たとえば「指示するもの」でエージェントのガードレールを外し、「接続するもの」で通信先を攻撃者のサーバーに変更する、といった連鎖が考えられる。
実行するもの（What executes）
開発者は普段、package.jsonやMakefile、docker-compose.ymlといった設定ファイルでプロジェクトの自動化を定義する。AIエージェントもこれらを読み取り、タスクの前提条件として自動実行する。攻撃者は一見すると普通の設定ファイルに悪意あるコマンドを仕込み、エージェントの実行権限を借りて攻撃を展開する。
Google Threat Intelligenceのレポートでは、.cursor/tasks.jsonを悪用した事例が紹介されている。ユーザーがIDEでプロジェクトフォルダを開くだけで、GitHub Gistから任意のコードがダウンロードされメモリ上で実行される仕組みだ。実行パラメータは意図的に隠蔽されていた。
指示するもの（What instructs）
AIエージェントに特化した脅威として、永続的な指示ファイルの悪用がある。これらはエージェントがプロジェクト内で何を優先し、何を無視し、どのツールを使うかを定義する。自然言語で書かれているため、悪意ある指示も「通常のガイダンス」を装って紛れ込ませやすい。
危険なのは、これらのファイルが複数リポジトリで再利用される点だ。一つの悪意ある指示ファイルがサプライチェーンを通じて多数のプロジェクトに拡散するリスクがある。しかも開発者が一行もレビューしないまま、エージェントが指示を実行してしまう可能性がある。
接続するもの（What connects）
AIエージェントはsettings.jsonなどのランタイム設定を参照し、外部APIのエンドポイントや認証情報、MCPサーバーとの接続を確立する。悪意ある設定ファイルは、正規のAPIエンドポイントを攻撃者のプロキシにすり替え、プロンプトやソースコード、認証情報を外部に送信させる。
具体的な事例として、AnthropicのベースURLを第三者のプロキシに向け替えるsettings.jsonが確認されている。AIエージェントは表面上は正常に動作するため、開発者はトラフィックが盗聴されていることに気づかない。
拡張するもの（What extends）
VS CodeやCursorの拡張機能は、開発環境に深く統合され、ローカルファイルや認証情報、開発ワークフローへの広範なアクセス権を持つ。攻撃者が拡張機能の更新経路を乗っ取ったり、正規のパブリッシャーアカウントを侵害したりすれば、一見標準的なツールを通じて悪意あるコードを配布できる。
2022年に発生したnode-ipcライブラリの破壊工作（protestware）は、このリスクを端的に示している。政治的なメッセージを込めたコードが正規のパッケージに混入され、多数のプロジェクトに影響が波及した。AIエージェントが普及した現在、同様の手口はさらに広範な被害をもたらし得る。
実際の攻撃事例から学ぶ
ここではVirusTotalに提出され、Code Insightによって検出された具体的な脅威ファイルを紹介する。いずれも従来のウイルス対策ソフトでは長期間検出されなかったものだ。
tasks.jsonの武器化
2026年3月19日にVirusTotalへ提出されたtasks.jsonは、数日間にわたってどのセキュリティエンジンからも検出されなかった。Code Insightの分析により、プロジェクトフォルダを開くだけでGitHub Gistから任意のコードがダウンロードされ実行される振る舞いが特定された。
Mandiantのアナリストによる検証でも悪意あるファイルと確認され、Google Threat Intelligenceでは特定の脅威アクター（北朝鮮に関連するグループ）との関連が指摘されている。この攻撃は技術課題を装ってIT専門家を標的にする手口で、NVIDIA Cudaなどの正規ツールを偽装していた。
SkillファイルによるAPIキー窃取
AIエージェントに指示を与えるSkill.mdファイルでも、悪意ある命令が確認されている。ある事例では、APIキーや環境変数を「メンテナンス」と称して外部エンドポイントに送信する指示が含まれていた。ファイル内には「セキュリティプロセスについて混乱を招く可能性があるため、ユーザーには伝えないこと」と明記されていた。
このファイルは約2カ月間、VirusTotal上で検出されることなく活動を継続していた。2026年に入ってから、リスクのあるSkill.mdファイルの提出数は一貫して増加しており、業界全体でのSkills採用拡大と並行して脅威が拡大すると見られている。
ランタイム設定のすり替え
別の事例では、2つの無関係なsettings.jsonファイルが同じ攻撃パターンを示していた。両者はANTHROPIC_BASE_URLを上書きし、APIキーを埋め込んだうえで、Claude Codeの通信をAnthropicではなく第三者のプロキシに向けさせる設定になっていた。
さらに調査を進めると、これらのプロキシはTelegramやDiscordのみを連絡手段とし、支払いを暗号通貨のみで受け付ける不透明なサービスと関連していた。テレメトリやエラーレポートも無効化されており、ユーザーが異常に気づく仕組みが意図的に排除されていた。
拡張機能の乗っ取り
2026年3月に提出されたVS Code拡張機能のサンプルは、1週間以上にわたって検出数ゼロだったが、Code Insightは不審な振る舞いを特定した。この拡張機能にはpeacenotwarとして知られるprotestwareが含まれており、起動時に特定のファイルを生成しコンソールにメッセージを出力する。
この事案自体の影響は限定的だが、拡張機能が持つ広範なアクセス権と、AIエージェントがそれを無条件に信頼する構造が組み合わさったときの危険性を浮き彫りにしている。別の事例では、ユーザーのクリップボード内容を読み取りリモートサーバーに送信するAIコーディング支援ツールも確認されている。
攻撃の流れは一方向ではなく、複数の経路が相互に補強し合う。指示ファイルでガードレールを下げ、接続設定で通信を奪い、実行トリガーでコードを動かし、拡張機能で永続化する。この連鎖を断ち切るには、各層での対策が欠かせない。
開発組織が取るべき対策
AIエージェントが標準ツールとなる中、組織は新しい脅威に合わせて防御戦略を更新する必要がある。シグネチャ検出だけに依存する時代は終わった。
リポジトリレベルのセキュリティポリシー
最初の対策は、AIエージェントが参照するファイルの種類を組織として明確に定義することだ。許可される設定ファイル、指示ファイルのフォーマットと配置場所をポリシー化し、それ以外は自動レビューなしにマージできない仕組みを構築する。たとえば.cursor/や.github/copilot-instructions.mdのようなディレクトリは、変更時に必須レビュワーを設定する。
最小権限の徹底
AIエージェントに付与する権限は、必要最小限に絞り込む。ローカルファイルへのアクセス範囲、実行可能なコマンド、接続を許可する外部サービスを明示的に制限する。仮に設定ファイルが乗っ取られても、エージェントが機密情報にアクセスできない状態を作ることが重要だ。
セマンティック分析の導入
VirusTotal Code Insightのようなセマンティック分析ツールを開発パイプラインに組み込む。これらのツールはファイルの構文ではなく、AIエージェントに与える指示の意味を評価する。自然言語で書かれた「APIキーを送信せよ」「テレメトリを無効化せよ」といった指示を検出できる。
Google Threat Intelligenceのエージェンティックプラットフォームでは、単一の危険フラグから関連する脅威キャンペーン全体を調査できる。1つの不審なsettings.jsonを起点に、同じインフラを使う別の攻撃ドメインや、過去の類似事案まで追跡可能だ。
対策は段階的に導入できる。まずはポリシー整備から始め、徐々にツールによる自動化を進めるのが現実的だ。重要なのは、AIエージェントを信頼するのと同じ熱量で、その動作を検証する仕組みを育てることだ。
この記事のポイント
- AIコーディングエージェントの普及により、攻撃対象はソースコードから設定ファイルや指示ファイルへと拡大している
- 悪意あるJSONやMarkdownは構文的に正しいため、従来のシグネチャ検出ではほぼ検出されない
- セマンティック分析が新しい防御の鍵であり、VirusTotal Code Insightがこの分野をリードしている
- リポジトリレベルのポリシー整備、最小権限の徹底、セマンティック分析ツールの導入が実践的な対策となる
- 2026年に入り、悪意あるSkill.mdファイルの提出数は増加傾向にあり、脅威は拡大し続けると見られる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress開発の新標準？コミュニティ主導の「WP Packages」へ移行すべき理由
WordPressのプラグインやテーマを管理するエンジニアにとって、デファクトスタンダードだった「WPackagist」に大きな転換期が訪れた。2026年3月12日、大手ホスティング企業のWP EngineがWPackagistの買収を発表したことが発端だ。これを受け、開発者コミュニティからは特定の企業によるインフラ独占を懸念する声が上がっている。
こうした状況下で、完全に独立したコミュニティ主導の代替サービス「WP Packages」が3月16日に正式リリースされた。WP Packagesは、単なる代替品にとどまらず、最新のComposer仕様への対応や劇的なパフォーマンス向上を実現している。10個のプラグインを解決する速度がWPackagistの約17倍にあたる0.7秒まで短縮されるなど、実務上のメリットも極めて大きい。
この記事では、なぜ今WPackagistからの移行が推奨されているのか、技術的な背景と具体的な移行手順を詳しく解説する。企業の意向に左右されない、持続可能な開発インフラを選択することは、長期的なプロジェクト運営において不可欠な視点だ。
WPackagistの買収とWP Packages誕生の背景
WPackagistが抱えていた長年の課題
WPackagist（ダブリューピー・パケジスト）は、2013年から提供されているWordPress専用のComposerリポジトリだ。ComposerとはPHPのライブラリ依存関係を管理するツールで、これを使うことでプラグインのインストールや更新をコマンド一つで自動化できる。しかし、WPackagistは近年、メンテナンスの停滞が指摘されていた。
記事によれば、WPackagistは更新サイクルが遅く、コミュニティからのフィードバックも反映されにくい状態が続いていた。また、古いプロトコルに依存していたため、プロジェクトが大規模になるほどライブラリの依存関係を解決する「名前解決」に時間がかかるというパフォーマンス上のボトルネックも抱えていた。
企業によるインフラ独占への懸念
WP Engineによる買収後、開発者のターミナルには「WPackagistはWP Engineによって維持されています」という通知が表示されるようになった。これは小さな変更だが、オープンソースの公共インフラが特定企業の管理下に置かれたことを象徴する出来事だ。著者のBen Word氏は、こうした企業主導の体制に対し、透明性の高いコミュニティ主導のインフラの必要性を説いている。
WP Packagesは、Rootsチーム（BedrockやSageの開発元）によって構築された。実は買収騒動が起きる前の2025年8月から開発が進められており、買収のニュースを受けてリリースが前倒しされた形だ。特定の企業の利益に左右されず、開発者が開発者のために運営する体制が整えられたのである。
WP Packagesが技術的に優れている4つのポイント
Composer v2最適化による圧倒的な高速化
WP Packagesの最大の技術的特徴は、Composer v2の「metadata-url」プロトコルを全面的に採用している点だ。従来のWPackagistでは、依存関係を解決するために巨大なインデックスファイルをすべてダウンロードする必要があった。これを「provider-includes」方式と呼び、通信量が増大する原因となっていた。
一方、WP Packagesはプロジェクトに必要なパッケージのメタデータのみをピンポイントで取得する。記事が示す検証結果によれば、10個のプラグインを含むプロジェクトでの解決時間は、WPackagistの12.3秒に対し、WP Packagesはわずか0.7秒だ。約17倍の高速化は、CI/CD（継続的インテグレーション/デリバリー）環境でのビルド時間を大幅に短縮する。
更新頻度の向上と命名規則の改善
情報の鮮度も大幅に向上している。WPackagistの更新サイクルが約90分であったのに対し、WP Packagesはわずか5分間隔で同期される。WordPress.orgの公式ディレクトリに新しいプラグインが公開されたり、既存のプラグインがアップデートされたりした際、ほぼリアルタイムでComposer経由の取得が可能になる。
また、パッケージの命名規則も直感的になった。従来は wpackagist-plugin/akismet のように長いプレフィックスが必要だったが、WP Packagesでは wp-plugin/akismet や wp-theme/twentytwentyfive といった、より簡潔な名称が採用されている。メタデータには作者情報や説明文、ホームページURLも含まれており、開発時の視認性が向上している。
WPackagistからWP Packagesへの移行手順
既存のプロジェクトをWPackagistからWP Packagesへ移行するのは非常に簡単だ。手動でコマンドを実行する方法と、公式が提供する移行スクリプトを使用する方法の2通りがある。
手動での移行コマンド
手動で行う場合は、既存のパッケージを一度削除し、リポジトリの設定を書き換えてから再インストールする手順を踏む。以下に主要なコマンドの流れを示す。
# 1. 既存のWPackagistパッケージを削除（例：テーマの場合）
composer remove wpackagist-theme/twentytwentyfive
# 2. WPackagistリポジトリを削除し、WP Packagesを追加
composer config --unset repositories.wpackagist
composer config repositories.wp-composer composer https://repo.wp-packages.org
# 3. 新しい命名規則でパッケージを追加
composer require wp-theme/twentytwentyfive移行スクリプトによる一括処理
プロジェクト内の composer.json に記述された多数のパッケージを一つずつ手動で変更するのは手間がかかる。その場合は、Rootsチームが公開している移行スクリプトを利用するとよい。このスクリプトは、ファイル内の記述を自動で新しい命名規則に置換してくれる。
# 移行スクリプトのダウンロードと実行
curl -sO https://raw.githubusercontent.com/roots/wp-packages/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.shなお、Rootsが提供しているWordPressスターターテーマ「Bedrock」を新規で利用する場合、すでにWP Packagesがデフォルトで設定されている。これから新しいプロジェクトを立ち上げるのであれば、設定の手間なく最新のインフラを利用できる。
オープンソースとしての透明性と持続可能性
完全に公開されたインフラ構成
WP Packagesの特筆すべき点は、アプリケーションのコードだけでなく、サーバーの構築設定（Ansible構成など）まで含めてGitHub上で完全に公開されていることだ。これは「オープンソースのリポジトリであること」と「透明なシステムであること」は別物であるという、Ben Word氏の信念に基づいている。
万が一、WP Packagesの運営に問題が生じたとしても、誰でもリポジトリをフォーク（複製）して自分たちの環境で同じレジストリを立ち上げることができる。特定の企業に依存しない、真の意味での「公共財」としての設計がなされている。インフラの構築プロセス自体が公開されているため、セキュリティ面での検証も容易だ。
広告やマーケティングを排除する姿勢
WP Packagesは、開発者のターミナル（黒い画面）を聖域として扱っている。企業運営のツールでは、コマンド実行時に広告や自社サービスへの誘導メッセージが表示されることがあるが、WP Packagesはこれを一切行わないと公約している。これは、コミュニティの寄付によって運営資金を賄っているからこそ可能な判断だ。
現在、WP PackagesはGitHub Sponsorsを通じて資金を募っており、KinstaやWordPress.comといった主要な企業もスポンサーとして名を連ねている。特定の親会社を持たず、複数の企業や個人が支える「非中央集権」的なモデルは、WordPressエコシステム全体の健全性を保つ上で重要な役割を果たしている。
独自の分析：WordPressエコシステムにおける「非中央集権」の重要性
今回のWP Packagesの誕生は、単なる技術的なアップデート以上の意味を持っている。それは、WordPressという巨大なプラットフォームにおける「インフラの民主化」だ。これまで私たちは、WPackagistのような便利なツールを「当たり前にあるもの」として利用してきたが、それが一晩で企業買収の対象になり得ることを再認識させられた。
技術的な視点で見れば、WP PackagesがComposer v2に最適化されたことは、Web制作の現場におけるDX（デジタルトランスフォーメーション）を加速させるだろう。17倍の高速化は、1日のうちに何度もビルドを繰り返すエンジニアにとって、積み重なれば数時間の節約につながる。しかし、それ以上に重要なのは「自分たちの道具を自分たちでコントロールできる」という安心感だ。
今後、WordPressのコア開発や周辺ツールにおいて、同様の「コミュニティへの回帰」が加速する可能性がある。特定のホスティングベンダーに依存しすぎることのリスクを回避し、オープンな標準技術を選択する動きは、サイトの長期的な保守性を高める。WP Packagesへの移行は、その第一歩として極めて理にかなった選択だと言えるだろう。
この記事のポイント
- WPackagistがWP Engineに買収されたことを受け、独立した代替サービス「WP Packages」が登場した。
- WP PackagesはComposer v2に最適化されており、依存関係の解決速度が従来比で約17倍高速化されている。
- データの更新間隔が5分に短縮され、常に最新のプラグインやテーマを取得できる環境が整った。
- 移行は数行のコマンド、または公式のスクリプトで簡単に行うことができ、既存プロジェクトへの導入障壁は低い。
- GitHub Sponsorsによるコミュニティ支援で運営されており、広告や特定企業の干渉を受けない透明性が確保されている。
出典
- WordPress.org News「WP Packages is Working the Way Open Source Should」（2026年3月25日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WP Rigで始めるWordPressテーマ開発——現代的なワークフローと学習環境
WP Rigは無料のWordPressテーマ開発ツールキットだ。スターターテーマとしての機能に加え、ComposerやNode.jsを統合した現代的な開発環境を提供する。2026年3月時点でバージョン3が公開されており、従来のクラシックテーマからブロックベースのテーマ、ハイブリッドなアプローチまで幅広く対応している。
プロジェクトの現在の管理者はRob Ruiz氏である。氏は2026年3月4日に公開されたWP Tavernのポッドキャストで、WP Rigの現状と将来像について語った。このツールキットは、テーマ開発の学習からプロダクション環境での利用まで、多様なユーザー層をサポートすることを目指している。
WordPressのエコシステムがブロックエディタとフルサイト編集（FSE）へと移行する中で、テーマ開発の在り方も変化している。WP Rigはこうした変化に対応し、開発者が最新のベストプラクティスを学びながら実践できる環境を整備した。
WP Rigとは何か——スターターテーマと開発ツールキット
WP Rigは「スターターテーマ」と「開発ツールキット」の両方の性格を持つ。Underscoresのような最小限のテーマ基盤を提供する一方で、現代的なフロントエンド開発に必要なツール群をあらかじめ統合している点が特徴だ。
コアとなる機能と統合ツール
WP Rigのプロジェクトをクローンすると、Node.jsとComposerの依存関係が自動的に解決される。これにより、開発者はすぐにコーディング作業に取りかかれる。統合されている主なツールは以下の通りだ。
- CSS処理: Lightning CSS（旧PostCSS）による最新CSS機能の先行利用とブラウザ互換コードへの変換
- JavaScript処理: esbuildによるTypeScriptのトランスパイルとバンドル
- コード品質: PHPCS（PHP Coding Standards）とWordPressコーディング標準（WPCS）に基づく自動チェック
- 開発サーバー: ファイル変更の監視と自動ビルド
これらのツールは、開発者が個別に設定する必要がなく、WP Rigの設定ファイルを介して一元的に管理される。これにより、開発環境の構築にかかる時間を大幅に短縮できる。
従来のスターターテーマとの違い
従来のスターターテーマは、主にテンプレートファイルのひな形を提供することに焦点が当てられていた。一方、WP Rigは開発「プロセス」そのものを標準化することを目指している。コードの書き方からビルド、品質チェックまで、一連のワークフローをツールが支援する。
Rob Ruiz氏はポッドキャストで、このアプローチについて次のように説明している。「WP Rigは単なるファイルの集合ではない。ベストプラクティスを学び、適用するためのガードレールを提供するものだ」。特にチーム開発では、この標準化されたワークフローがコードの一貫性を保ち、レビュー工数を削減する効果がある。
誰のためのツールか——学習者からプロフェッショナルまで
WP Rigの対象ユーザーは幅広い。WordPress管理画面でのサイト構築に慣れたユーザーが、次のステップとしてコードベースのカスタマイズに挑戦する場合にも適している。一方、経験豊富な開発者が新規プロジェクトを効率的に立ち上げるためにも利用できる。
ページビルダーユーザーからの移行
ページビルダーやブロックエディタによるビジュアル編集には限界がある。デザインの細かい調整や、最新のCSS機能をすぐに利用したい場合、コードを直接編集する方が柔軟性が高い。WP Rigは、こうしたユーザーがローカル開発環境を整え、段階的にテーマ開発を学ぶための足がかりとなる。
Ruiz氏はポッドキャストで、コードによる制御の利点を強調した。「データベースに保存された設定値を一つずつ変更するのではなく、CSSファイルを一行修正するだけでサイト全体の見た目を変えられる。これがコードの持つ『超能力』だ」。WP Rigは、この「超能力」を安全に習得するための学習環境を提供する。
エージェンシーとチーム開発での活用
カスタムテーマをクライアントに提供するWeb制作会社では、開発プロセスの標準化が重要だ。WP Rigをプロジェクトの基盤とすることで、複数の開発者が同じコーディング規約とビルドプロセスを共有できる。新規メンバーのオンボーディングも容易になる。
また、WP Rigにはテーマの「バンドル」機能が備わっている。開発が完了したテーマを配布用にパッケージ化する際、すべてのソースコード内の「WP Rig」という文字列がテーマ名に置換される。これにより、エンドユーザーが基盤技術を意識することなく、完成したテーマを利用できる。
開発環境の構築とワークフロー
WP Rigを利用するには、ローカルマシンに特定のソフトウェアをインストールする必要がある。リモートサーバーではなく、ローカル環境でテーマ開発を行うのが基本だ。
必要な事前準備
WP Rigを動作させるための最小限の環境は以下の通りだ。
- Node.js: JavaScriptの実行環境。バージョン管理ツール（nvmやfnm）でのインストールが推奨される。
- Composer: PHPの依存関係管理ツール。グローバルにインストールする。
- ローカル開発環境: Local WP、WordPress Studio、Dockerベースのwp-envなど、任意の環境を選択可能。
これらのツールをインストールした後、WP RigのGitHubリポジトリをクローンし、依存関係をインストールする。プロジェクトルートでnpm installとcomposer installを実行すれば、開発環境の準備は完了だ。
開発からバンドルまでの流れ
WP Rigを使った典型的な開発ワークフローは以下のステップで構成される。
- 1. 開発サーバーの起動:
npm startでファイル監視と自動ビルドが開始される。 - 2. コーディング: CSS、JavaScript、PHPファイルを編集する。変更は自動的に反映される。
- 3. コードチェック:
npm run lintでPHPとJavaScriptのコード品質を検証できる。 - 4. ビルド:
npm run buildで本番用の最適化されたアセットを生成する。 - 5. バンドル:
npm run bundleで配布用のテーマパッケージを作成する。
このワークフローの中で、開発者は複雑なビルド設定を意識する必要がない。ツールの更新が必要な場合も、WP Rigのバージョンアップに追随するだけで済む。
ブロックエディタ時代のテーマ開発
WordPressのフルサイト編集（FSE）とブロックベースのテーマが普及する中で、クラシックなテーマ開発の価値が問われている。WP Rigはこの変化を先取りし、複数の開発パラダイムをサポートするように進化した。
3つのテーマパラダイムへの対応
WP Rigは、一つのコードベースから以下の3種類のテーマを生成できる。
- クラシックテーマ: 従来通りのPHPテンプレートファイルを使用する。
- ユニバーサルテーマ: クラシックテーマとブロックテーマの機能を併用する。
- ブロックテーマ: HTMLテンプレートファイルとtheme.jsonで構成される。
プロジェクトの初期化後、コマンドラインからnpm run configureを実行すると、対話形式でテーマの種類を選択できる。選択に応じて、必要なファイルが自動的に生成または変換される。
テーマレベルでのブロック開発
WP Rigの特徴的な機能の一つが、テーマ内でのカスタムブロック開発をサポートしている点だ。通常、カスタムブロックはプラグインとして開発されるが、テーマに密接に関連するブロック（例: 特化したナビゲーションブロック）をテーマ内に実装できる。
ただし、この方法で開発したテーマをWordPress.orgの公式テーマリポジトリに投稿することはできない。リポジトリのガイドラインでは、ブロックの提供はプラグインに限定されているためだ。クライアントワークや自社サイトでの利用が主な用途となる。
Ruiz氏はこの機能について、「境界線を曖昧にすることを厭わない」と表現した。テーマとプラグインの役割分担に縛られず、プロジェクトの要件に最適な技術的選択を可能にする姿勢が反映されている。
教育資源としてのWP Rig
WP Rigの公式サイト（wprig.io）には、ツールの使い方だけでなく、WordPressテーマ開発そのものを学ぶための資源が豊富に用意されている。これはプロジェクトの重要な側面だ。
学習コンテンツの構成
サイトの「Learn」セクションには、以下のような教育資源が整理されている。
- ビデオチュートリアル: YouTubeチャンネルで基礎から応用までを解説
- 技術文書: CSS、JavaScript、PHPの各言語におけるベストプラクティス
- サンプルコード: 実際のユースケースに基づいた実装例
- 開発ガイド: ローカル環境構築からデプロイまでの手順
これらの資源は、単にWP Rigの使い方を教えるだけでなく、現代的なWeb開発の概念そのものを伝えることを目的としている。例えば、CSSのカスケードや詳細度、PHPの名前空間といった基礎概念も丁寧に説明されている。
コミュニティと貢献の機会
WP Rigはオープンソースプロジェクトであり、GitHub上で開発が進められている。バグ報告や機能提案はIssuesを通じて受け付けている。また、Discordサーバーでは開発者同士の交流が行われている。
Ruiz氏はポッドキャストで、コミュニティの重要性を強調した。「WordPress自体がコントリビューターに依存している。テーマ開発を学ぶ人が増え、やがてコアへの貢献者になる——そんな好循環を生み出したい」。WP Rigは、その入り口となることを目指している。
この記事のポイント
- WP Rigはテーマ開発のスターターキットであり、現代的な開発ツールを統合している。
- ローカル環境での開発を前提とし、Node.jsとComposerが必要だ。
- クラシック、ユニバーサル、ブロックテーマの3パラダイムに対応する。
- コード品質チェックや自動ビルドなど、チーム開発での標準化を支援する。
- 教育資源が豊富で、テーマ開発の学習環境としても機能する。
出典
- WP Tavern「#207 – Rob Ruiz on WP Rig and the Future of Theme Development」（2026年3月4日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験