FlowTune Media

Grok Buildが「プラグインストア」を開いた — Claude CodeのMCPエコシステムに真正面から挑む6つのプラグイン

AIコーディングCLIの拡張性をめぐる競争が、新しい局面に入った。

xAIが6月11日、Grok Buildにプラグインマーケットプレイスをベータ公開した。スキル、スラッシュコマンド、エージェント、フック、MCPサーバー、LSP——これらを1つのパッケージにまとめて「プラグイン」としてインストールできる仕組みだ。

ターミナルの中で/marketplaceと打てばカタログが開き、iキーで即インストール。アンインストールも同じ画面から。Claude Codeが1年かけて築いてきたMCPエコシステムに、Grok Buildが「互換性+独自プラグイン」という合わせ技で対抗している。

ローンチ時の6プラグイン

初日にリリースされたプラグインは以下の6つ。

MongoDB — ターミナルからコレクションのブラウズ、クエリの実行と最適化ができる。データベース操作をエディタに切り替えずに完結させたい場面で使う。

Vercel — デプロイ状況の確認、ビルドステータスのチェック、ドメイン設定をCLI内で操作する。vercel deployの代わりにGrok Buildの文脈で管理できるようになる。

Sentry — スタックトレースの解析とプロダクションエラーのデバッグ。エラー監視画面を別タブで開く必要がなくなる。

Chrome DevTools — ライブブラウザの操作、パフォーマンストレースの記録、ネットワークリクエストの検証。フロントエンド開発者にとっては地味に嬉しい。

Cloudflare — Workers、Durable Objects、その他Cloudflareサービスの操作スキル。

Superpowers — GitHubで22万スター超のオープンソースプロジェクトから取り込んだエージェント駆動のワークフロー集。これはxAI独自のものではなく、コミュニティプロジェクトの統合だ。

セキュリティ設計は悪くない

プラグインの中身がリモートから取得される以上、サプライチェーン攻撃のリスクは避けられない。Grok Buildはこの点を意識した設計になっている。

カタログに登録されるリモートプラグインは、特定のコミットSHAにピン留めされる。インストール時にGrok Buildがそのハッシュを検証するため、プラグインが後から差し替えられてもインストール済みの環境には影響しない。

オープンカタログ形式を採用しているため、誰でもGitHub上のxai-org/plugin-marketplaceにPRを出してプラグインを提案できる。審査プロセスの詳細は公開されていないが、少なくとも「野良プラグインを直接実行する」よりは安全だろう。

Claude Codeとの互換性が最大の武器

正直、6つのプラグインだけで勝負するなら厳しい。Claude CodeのMCPエコシステムには、1年分のコミュニティ貢献で蓄積されたサーバーが山ほどある。

だがGrok Buildの戦略は「ゼロから積み上げる」ではない。AGENTS.md、スキル、フック、MCP サーバー——Claude Codeのプロジェクト規約をそのまま読み取れる互換性を持っている。つまり、Claude Code用に構築した開発環境をGrok Buildにほぼそのまま持ち込める。

この互換性は偶然ではなく、明確な設計判断だ。後発のツールが既存のエコシステムに乗っかる戦略は、Android がLinuxカーネルを採用したのと構造的に同じ。エコシステムの「広さ」では追いつけなくても、「互換性」で実質的なカバレッジを確保する。

気になる点

利用にはSuperGrokまたはX Premium Plus(月額$30前後、約4,500円)が必要だ。Grok Buildそのものの利用料と別にプラグインに追加料金が発生するかは不明だが、現時点では無料のようだ。

プラグインの数がまだ少ないのは明らかな弱点。VercelやSentryは開発者にとって定番だが、JetBrains連携やAWS操作のような「次に欲しい」プラグインが揃うまでには時間がかかるだろう。

もう一つ。Grok Buildの8並列エージェント実行とプラグインの組み合わせがどう動くのか、具体的な情報がまだ少ない。8エージェントがそれぞれMongoDBとSentryを同時に叩くシナリオで、レートリミットやトークン消費がどうなるかは実際に使ってみないと分からない。

MCPサーバーを自分で建てるか、プラグインを入れるか

Grok Buildのプラグインマーケットプレイスが示しているのは、AIコーディングツールの競争軸が「モデルの賢さ」から「周辺ツールとの接続力」に移りつつあるということだ。

Claude CodeはMCPという汎用プロトコルで拡張性を確保した。CursorはVS Codeの拡張エコシステムとSDKで独自路線を走っている。そこにGrok Buildが「両方の資産を使える」プラグインシステムを持ち込んだ。

開発者にとっての実質的な選択肢は、Claude Codeの成熟したMCPエコシステムを直接使うか、Grok Buildの互換レイヤー経由で同じ資産にアクセスしつつ8並列実行の恩恵も得るか、だ。後者が安定して動くなら、かなり魅力的な選択肢になる。

関連記事