すべてのサービスは Claude Code プラグインを作るべきか — codex-plugin-cc の体験から考えるディストリビューションチャネル論
OpenAI Codex を Claude Code から呼び出せる公式プラグイン codex-plugin-cc を試したところ、想像以上に体験が良かったです。/codex:review を打てば Codex のレビューが走り、/codex:rescue で重い調査や修正をバックグラウンドに投げられて、/codex:status で進捗を見て /codex:result で結果を回収する。Claude Code から一歩も外に出ずに、もう 1 つの AI コーディング CLI に仕事を分担できる感覚は、これまでの「複数 CLI を並べて使い分ける」運用とは明確に違いました。
これを触りながら強く感じたのが、「サービスを世に出すなら、もう Claude Code プラグインを最初から作るのが正解では?」という仮説です。プラグインは単なる連携機能ではなく、「ユーザーが既にいる場所」にサービスを届けるディストリビューションチャネルとして機能していました。
本記事では、codex-plugin-cc の何が良かったのかを掘り下げたうえで、プラグイン化が刺さるサービス類型と、採用前に考えるべきトレードオフを整理します。
codex-plugin-cc が提供しているもの
codex-plugin-cc の README によると、ユーザーから見える表面は次のとおりです。
/codex:review: 現在の作業に対する読み取り専用 Codex レビュー/codex:adversarial-review: 設計判断や前提を揺さぶる Adversarial レビュー/codex:rescue: 調査や修正の委譲(codex:codex-rescueサブエージェント経由)/codex:status、/codex:result、/codex:cancel: バックグラウンドジョブの管理/codex:setup: 環境チェックとオプションの review gate(Stopフック)の有効化
インストールは Claude Code 内で次の 2 行を打つだけです。
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex裏側では、以前 Claude Code、Codex、Gemini のマルチプラットフォーム戦略を比較する で取り上げた Codex App Server を JSON-RPC でラップしています。ローカルに既にインストールされた codex バイナリを利用するため、認証 (codex login) も設定 (~/.codex/config.toml) もそのまま再利用されます。Codex 側のコンテキストを再構築する必要がありません。
flowchart LR
User[開発者] --> CC[Claude Code セッション]
CC -- "/codex:review<br/>サブエージェント<br/>Stop フック" --> Plugin[codex-plugin-cc]
Plugin -- "JSON-RPC over stdio" --> AppServer[Codex App Server]
AppServer --> CodexAuth[ローカル Codex 認証]
AppServer --> Repo[現在のリポジトリ]
AppServer --> OpenAI[OpenAI / ChatGPT]
Codex App Server はもともと「同じ Codex ハーネスを複数のサーフェスに届ける」ために作られたプロトコルなので、Claude Code を新しいサーフェスとして追加するのは自然な拡張になっています。
体験が良いと感じる 3 つの理由
1. 既にいる作業環境から離れずに済む
Codex を直接使うときに発生していた「ターミナルをもう 1 枚開いて、別の CLI を起動して、コンテキストを口頭で説明し直す」という小さな摩擦が、ゼロになります。Claude Code でコードを書きながら、必要な瞬間に /codex:adversarial-review を打つだけで、別エージェントの視点でレビューを受けられる。「複数 AI に同時に意見を聞く」という、 3 つの AI を MAGI システムのように使う で書いたような構成も、配線がほぼ不要になります。
2. プラグインが「重いタスクを横に流す」UX を内包している
/codex:rescue --background でバックグラウンドジョブとして委譲し、/codex:status でポーリングして、/codex:result で結果を取りに行く。このパターンは、AI エージェントが分単位〜十分単位のタスクを抱えるようになった現代において、既に標準形になりつつあるワークフローです。Claude Code 自身もバックグラウンドエージェントの仕組みを持っていますが、codex-plugin-cc はそれと並列で「Codex 側のバックグラウンドジョブ」を管理する UX を提供してくれます。Claude Code が止まっている間に Codex を走らせ続ける、という二段並走が自然にできます。
3. 既存の認証・設定を再利用している
プラグイン側に独自の API キーや設定ファイルを持たせていないのが、運用上は地味に効きます。Codex を既に使っているユーザーは追加設定がほぼ不要で、/codex:setup を 1 度叩けばすぐ動きます。「同じ機能を別チャネルから提供する」のではなく、「同じ実体を別ファサードから操作する」設計になっているので、認証ローテーションや config 変更が自動で反映されます。
プラグインが束ねる 4 つの拡張ポイント
Claude Code のプラグイン仕様は、複数の拡張ポイントを 1 つのバンドルにまとめて配布できるところがポイントです。codex-plugin-cc は、その 4 つを綺麗に組み合わせています。
| 拡張ポイント | codex-plugin-cc での例 | 何ができるか |
|---|---|---|
| スラッシュコマンド | /codex:review、/codex:rescue ほか | サービス機能を Claude Code の入力欄から直接呼び出す |
| サブエージェント | codex:codex-rescue | Claude Code のエージェントループから委譲できる別エージェントを定義 |
| フック | --enable-review-gate 時の Stop フック | Claude が応答を返す前後で自動的にサービスを走らせる |
| MCP サーバー | (codex-plugin-cc は内部 JSON-RPC を使用) | 外部システムへのツール接続を標準化する |
スラッシュコマンドだけなら CLI のラッパーで足りますが、サブエージェント・フック・MCP まで含めると、「ユーザーが明示的に呼ぶ」「Claude が自律的に呼ぶ」「特定のタイミングで自動的に走る」の 3 つを同じパッケージで提供できます。これは、単なる API 提供や CLI 配布では届かないレイヤーの UX です。
プラグイン化が刺さるサービス類型
「すべてのサービスをプラグインに」と言うと過剰に聞こえますが、開発者向けプロダクトに限って言えば、次の類型ではプラグインを「最初から」作る価値が高そうです。
AI / コーディングエージェント
Codex がそうであるように、別のエージェント(Gemini、Cursor、Devin など)を Claude Code から呼べると、エージェント間の役割分担が一気に楽になります。「メインエージェントは Claude Code、特定タスクで別 AI を呼ぶ」という構成が、プラグインで自然に書けます。
開発インフラ・PaaS
Vercel はすでに AI コーディングエージェント向けの公式プラグイン を出しています。/vercel-plugin:deploy、/vercel-plugin:env、/vercel-plugin:status など、CLI でやっていたことが Claude Code 内のスラッシュコマンドで完結します。同種のサービス(Netlify、Cloudflare、Fly.io など)も、似た形でプラグインを出さないとサーフェスパリティの面で出遅れる流れになりつつあります。
データベース・ストレージ
Supabase、Neon、Turso のような開発者向け DB は、「マイグレーションを書いて」「ブランチデータベースを作って」「ロールバックして」というやりとりが Claude Code 内で完結すると、認知負荷が大きく下がります。スキーマ生成や型出力の自動化と相性が良いところも追い風です。
コードレビュー・品質ゲート
Sentry、Datadog、Codecov のような観測・品質系は、PR を出す前に「直近のエラーを踏んでいないか」「カバレッジが落ちていないか」をエージェントに自動チェックさせる用途で、フックと相性が良いです。codex-plugin-cc の review gate と同じ発想で、「Claude が応答する前に観測サービスに問い合わせる」フックを 1 つ仕込むだけで、品質チェックがパイプラインに組み込まれます。
課題管理・コミュニケーション
Linear、GitHub Issues、Slack のようなチームツールは、サブエージェントで「課題を読み込み、関連コードを調べ、PR を作る」という複合タスクを担当させやすいです。プラグインがあると、/linear:triage のような単一コマンドで Claude Code に作業を流し込めるようになります。
採用前に考えるべきトレードオフ
一方で、「とりあえず Claude Code プラグインを出せばいい」と決め打ちすると痛い目を見そうな論点もあります。
1. ディストリビューションが Claude Code 利用者に偏る
プラグインは Claude Code を入れている開発者にしか届きません。Claude Code、Codex CLI、Cursor、Cline のいずれも CLI / IDE エージェント市場で存在感がある現状では、「どれか 1 つ」に賭ける形になります。codex-plugin-cc が成立しているのは、OpenAI 自身が Codex を提供していて、Codex App Server という公開プロトコルでマルチサーフェス展開する戦略を持っているからで、外部ベンダーが同じ前提を置けるとは限りません。
2. メンテナンス負荷が増える
Claude Code 向けプラグイン、Codex 向け統合、Cursor 向け拡張、MCP サーバー、CLI、SDK、と全部を真面目に維持しようとすると、「どこに UX の重心を置くか」を決めない限りメンテナンスが破綻します。プラグインは「初期投資が小さく見えるが、長期コストはそうでもない」レイヤーです。
3. プロトコルの安定性に依存する
Claude Code のプラグイン仕様、サブエージェント、フック は活発に進化中です。仕様変更で挙動が壊れるリスクはあり、サポートする Claude Code バージョンの幅を絞るかどうかは設計判断になります。
4. セキュリティ境界が変わる
サブエージェントやフックは、ユーザー環境内でコードを実行する権限を持ちます。プラグインを配布する以上、ユーザーのシェルで好き勝手なコマンドを叩ける位置に座ることになるので、権限・パーミッション・監査ログの設計を雑にすると、セキュリティインシデントの温床になります。codex-plugin-cc が --enable-review-gate を「明示的なオプトイン」にしているのは、この境界を意識した設計です。
5. CLI / API / MCP / プラグイン、どれを「正」とするか
プラグインは「サービスへの 1 つの入り口」にすぎません。サーバーレスや CI から呼ぶには CLI / API / MCP のほうが向いています。「プラグインは UX レイヤー、CLI と API は実体、MCP は他エージェント連携」と棲み分けを設計しないと、機能ごとの整合性が崩れます。codex-plugin-cc が薄いラッパーに留まっているのは、「Codex CLI と App Server が実体」「プラグインは Claude Code 向け UX ファサード」という分担が明確だからです。
既に動き始めているエコシステム
Claude Code Plugin Marketplace には、OpenAI(codex-plugin-cc)、Vercel、コミュニティ製まで複数のプラグインが並び始めています。プラットフォームが配布フォーマットを公式に整備し、ベンダーが乗ってくる構図が、IDE 拡張機能ストアや Slack App Directory の初期と似た様相になりつつあります。
「すべてのサービスがプラグインを作るべき」とまで言い切るのは早計ですが、開発者ツール/エージェント連携系のサービスに限れば、プラグインを「ローンチ時の必須チャネル」として最初から計画する価値は十分にあると感じます。少なくとも、CLI と API しか出さずに様子見、というスタンスは、Claude Code を主要サーフェスにしている開発者層を確実に取り逃します。
まとめ
codex-plugin-cc が示しているのは、「同じサービスでも、ユーザーが既にいる場所に届けるかどうかで体験はまったく変わる」という単純な事実です。Claude Code プラグインの強みは次の 3 つに集約できます。
- スラッシュコマンド・サブエージェント・フック・MCP を 1 つのバンドルで配布できる
- 既存の認証・設定を再利用しやすく、ユーザーの追加コストが小さい
- 「重いタスクを横に流して結果を回収する」UX を、ユーザーの作業文脈の中に置ける
採用判断のチェックリストとしては、次のあたりが起点になります。
- ターゲットユーザーは Claude Code を主要サーフェスにしているか
- プラグインに乗せるべき機能と、CLI / API / MCP に残すべき機能の棲み分けを描けているか
- ユーザー環境でコードを実行することのセキュリティ設計が用意されているか
- 仕様の進化に追随し続けるメンテナンス体制があるか
そのうえで、開発者ツール系のサービスを今ローンチするなら、Claude Code プラグインは「あれば嬉しい」ではなく「最初から計画する」レイヤーになりつつある、というのが codex-plugin-cc を触って得た結論です。
以上、Claude Code プラグインをディストリビューションチャネルとして考察した現場からお送りしました。