3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@nogataka

Claude Code と Codex の主要機能を比較する｜MCP・Skills・メモリ・Subagents・Hooks・Plugins リファレンス

3
Last updated at Posted at 2026-06-01

はじめに

ターミナルで動くAIコーディングエージェントとして、Anthropic の Claude Code と OpenAI の Codex（Codex CLI）は、いまもっとも比較されることが多い2つだと思います。どちらも「対話しながらコードを書く」だけのツールではなく、外部ツール連携・再利用可能なワークフロー・永続的な指示・ライフサイクル制御まで備えた、拡張可能なエージェント実行基盤へと育ってきました。

この記事では、両者を以下の5つの観点で並べて読み解きます。

  • MCP（Model Context Protocol） — 外部ツール・データソースとの接続
  • Skills — 再利用可能なワークフローのパッケージ化
  • メモリ／指示（CLAUDE.md / AGENTS.md / Rules） — 永続的なコンテキストとルール
  • Subagents — タスク特化のサブエージェントによる並列・分業
  • Hooks — ライフサイクルへのスクリプト注入
  • Plugins — 上記をまとめて配布する単位

それぞれの機能について、設計思想・設定方法・具体例を丁寧に並べていきます。単なる機能の有無ではなく、「なぜその設計になっているのか」「どう使い分けると効くのか」まで踏み込みたいので、長めの記事になっています。気になる章から読んでいただいて構いません。

なお、本記事の設定例に出てくるディレクトリ名やファイル名は説明用に置き換えています。実環境のパスをそのまま公開すると情報漏洩につながることがあるので、ご自身の環境では適宜読み替えてください。また、両ツールとも更新が速い領域なので、細部は公式ドキュメントで最新の挙動を確認していただくのが確実です。記事末尾に参照したドキュメントへのリンクをまとめています。

この記事は「どちらが優れているか」を決める比較ではありません。設計思想の違いを理解して、自分のワークフローに合う使い方を見つけるための地図として読んでいただければと思います。

また、両ツールにはそれぞれ独自の細かな機能も数多くありますが、この記事では Claude Code と Codex が共通して備える主要機能（MCP・Skills・メモリ／指示・Subagents・Hooks・Plugins）に絞って比較しています。機能の有無を網羅するより、両者を同じ土俵で見比べられるようにするためです。

全体像｜設定の思想がそもそも違う

個別機能に入る前に、両者の設定アーキテクチャの違いを押さえておくと理解がスムーズになります。ここが両ツールの性格を決めている部分だと感じます。

観点 Claude Code Codex
設定の中心 複数形式の分散（settings.json / .mcp.json / Markdown） ~/.codex/config.toml（TOML）中心（補助ファイルは分散）
指示ファイル CLAUDE.md（+ .claude/rules/） AGENTS.md（+ Rules / config）
プロジェクト設定の保存先 .claude/ 配下 .codex/ 配下
スキルの配置 .claude/skills/ .agents/skills/
信頼モデル スコープと権限で制御 trusted project かどうかで project-local 設定の読み込みを判定

Claude Code は「機能ごとに最適な形式を選ぶ」スタイルです。MCPサーバーは .mcp.json、フックや権限は settings.json、指示は Markdown と、用途別にファイルが分かれます。一方 Codex は「設定は config.toml に集める」TOML中心の思想で、MCPサーバーもサブエージェントもフックも、原則として同じ設定体系の中で記述できます。

もう一つ、Codex を読むうえで重要なのが信頼（trust）モデルです。Codex はプロジェクト配下の .codex/ レイヤーが trusted になっている場合にのみ、project-local の MCP・Rules・Hooks をロードします。「リポジトリに置いてあるだけの設定を無条件には信用しない」という姿勢が、随所に一貫して現れます。Claude Code 側にも .mcp.json のプロジェクトスコープ承認やワークスペーストラストといった近い仕組みがありますが、Codex はこの trust 概念をより前面に出している印象です。

興味深いのは、Codex のプラグイン機構が CLAUDE_PLUGIN_ROOT / CLAUDE_PLUGIN_DATA という環境変数を互換目的で提供している点です。Agent Skills のオープン標準（agentskills.io）を両者が共有していることもあり、エコシステムとしては緩やかに相互運用を意識した作りになってきていると読み取れます。

1. メモリ／指示｜CLAUDE.md と AGENTS.md + Rules

エージェントに「毎回同じ前提で動いてほしい」と思ったとき、最初に触るのがこの領域です。新しいセッションは基本的に空のコンテキストから始まるので、永続的に効く指示をどこに書くかが作業効率を大きく左右します。

Claude Code のメモリ

Claude Code は2つのメカニズムで知識を保持します。

  • CLAUDE.md — あなたが書く永続的な指示
  • 自動メモリ — Claude が学習やパターンを自分で書き残すメモ（v2.1.59以降、デフォルト有効）

CLAUDE.md には4つのスコープがあり、優先順位（読み込み順）が決まっています。

スコープ 場所 共有対象
管理ポリシー OS別のシステムディレクトリ 組織全員（個別に除外不可）
ユーザー指示 ~/.claude/CLAUDE.md あなただけ（全プロジェクト）
プロジェクト指示 ./CLAUDE.md または ./.claude/CLAUDE.md チーム（バージョン管理経由）
ローカル指示 ./CLAUDE.local.md あなただけ（現プロジェクト）

読み込みの仕組みが少し独特です。Claude Code はカレントディレクトリからファイルシステムのルートに向かって上に辿り、各階層の CLAUDE.md を探してすべて連結します。順序はルート側から起動地点側へと並ぶので、起動地点に近い指示があとに読まれます。サブディレクトリ内のファイルは、Claude がそのディレクトリのファイルを読むタイミングでオンデマンドに読み込まれます。モノレポで階層ごとにルールを変えたいときに効く設計です。

ファイルを分割したいときは @path/to/import 構文でインポートできます。再帰インポートは最大4ホップまでです。

プロジェクト概要は @README を参照してください。

# 追加の指示
- git ワークフローは @docs/git-instructions.md に従ってください

ルールを整理したいときは .claude/rules/ ディレクトリが使えます。配下の .md は再帰的に発見され、paths フロントマターを使うと特定のファイルを読むときだけ適用されるパス固有ルールを書けます。

この paths 指定はブレース展開や複数パターンにも対応し、src/**/*.{ts,tsx} のようにまとめて書けます。paths を付けないルールは .claude/CLAUDE.md と同じ優先度で起動時に読み込まれます。さらに、ユーザーレベルの ~/.claude/rules/ も使えます。ここに置いたルールはプロジェクトのルールより前に読み込まれるため、結果としてプロジェクト側のルールが上書き側（高い優先度）になります。チーム横断で共有したい場合は ln -s ~/shared-rules .claude/rules/shared のようにシンボリックリンクを張る方法もあります。

---
paths:
  - "src/api/**/*.ts"
---
# API 開発ルール
- すべての API エンドポイントは入力検証を含めてください

AGENTS.md を直接は読みませんが、CLAUDE.md からインポートするか、シンボリックリンクを張ることで取り込めます。

@AGENTS.md

## Claude Code 固有の指示
`src/billing/` 配下の変更には Plan Mode を使ってください

ここで設計思想として強調されているのが、「CLAUDE.md はコンテキストであって強制設定ではない」という点です。CLAUDE.md はシステムプロンプトではなく、後続のユーザーメッセージとして配信されるため、厳密な遵守は保証されません。具体的で検証可能な指示（「コミット前に npm test を実行」など）ほど従う確率が上がります。確実にアクションをブロックしたいなら、後述の PreToolUse フックを使うのが公式の一貫した指針です。

自動メモリと MEMORY.md｜Claude が自分で書き残す記憶

CLAUDE.md が「あなたが書く指示」だとすれば、自動メモリは「Claude が自分で書き残す記憶」です。バージョン 2.1.59 以降でデフォルト有効になっています。あなたが修正やフィードバックを与えると、Claude はそこから学んだパターンを自分でメモとして残し、次回以降のセッションで参照します。

保存先はリポジトリごとに用意されるメモリ用ディレクトリで、次のような構成になります（パスは説明用に簡略化しています）。

~/.claude/projects/<project>/memory/
├── MEMORY.md          # 簡潔なインデックス。全セッションで読み込まれる
├── debugging.md       # トピック別の詳細メモ
└── api-conventions.md

ここで中心になるのが MEMORY.md です。これは記憶全体の目次にあたるファイルで、各セッションの開始時に先頭の200行（または25KBのいずれか早い方）が読み込まれます。debugging.md のようなトピック別ファイルは、目次から必要に応じてオンデマンドで読み込まれる仕組みです。これにより、記憶が増えてもセッション開始時のコンテキスト消費を一定に抑えられます。CLAUDE.md が長さに関わらず全文読み込まれるのとは対照的な設計です。

保存場所はリポジトリ単位なので、同じリポジトリの別のワーキングツリーやサブディレクトリでも記憶が共有されます。一方でマシンローカルに保存されるため、マシンをまたいだ共有はされません。

主な操作は次の通りです。

  • /memory コマンドで、読み込まれている CLAUDE.md やルール、自動メモリの状態を確認し、オン・オフを切り替えられます
  • 無効化したい場合は設定で autoMemoryEnabled: false、または環境変数 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 を使います
  • 保存先を変えたい場合は autoMemoryDirectory で指定します

サブエージェントにも独自の自動メモリを持たせることができ、フロントマターで memory: user / project / local のいずれかを指定します。役割が決まったサブエージェントに、その役割固有の学習を蓄積させたいときに役立ちます。

自動メモリはあくまで「Claude が学んだメモ」であり、書かれた時点の状況を反映します。ファイル名や手順が変わると古くなることがあるため、確実に守ってほしい前提は CLAUDE.md 側に明示しておくと安定します。

Codex の AGENTS.md と Rules

Codex は作業開始前に AGENTS.md を読みます。優先順位は次の通りです。

  1. グローバル — Codex ホーム（デフォルト ~/.codex、CODEX_HOME で変更可）。AGENTS.override.md があればそれを、なければ AGENTS.md を使う。このレベルでは最初の非空ファイル1つだけ
  2. プロジェクト — プロジェクトルート（通常 Git ルート）から CWD まで降りながら、各ディレクトリで AGENTS.override.md → AGENTS.md → フォールバック名の順にチェック。1ディレクトリ1ファイルまで
  3. マージ — ルートから下へ連結。CWD に近いファイルほどあとに来るので後勝ち

合計サイズが project_doc_max_bytes（デフォルト 32 KiB）に達すると追加を停止します。上限に達したら値を上げるか、ネストしたディレクトリに分割します。

グローバルガイダンスの例です。

# ~/.codex/AGENTS.md

## Working agreements

- Always run `npm test` after modifying JavaScript files.
- Prefer `pnpm` when installing dependencies.
- Ask for confirmation before adding new production dependencies.

読み込まれているか確認するコマンドも用意されています。

codex --ask-for-approval never "Summarize the current instructions."

既存の別名ファイル（例: TEAM_GUIDE.md）を指示ファイルとして扱いたいときは、フォールバック名を設定できます。

# ~/.codex/config.toml
project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"]
project_doc_max_bytes = 65536

Codex の Rules（experimental）は、Claude Code の CLAUDE.md とは少し性格が違います。これは「サンドボックス外で Codex が実行できるコマンドを制御する」仕組みで、どちらかというと権限・ガードレールの領域です。ルールは Starlark 形式（Python に似た、副作用なしで安全に実行できる構文）で書きます。

# プレフィックスが `gh pr view` のコマンドをサンドボックス外で実行する前に確認する
prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "Viewing PRs is allowed with approval",
    match = [
        "gh pr view 7888",
        "gh pr view --repo openai/codex",
    ],
    not_match = [
        "gh pr --repo openai/codex view 7888",
    ],
)

decision は allow / prompt / forbidden の3種類で、複数マッチした場合は最も制限的なもの（forbidden > prompt > allow）が適用されます。match / not_match はルール読み込み時に検証される「インラインのユニットテスト」で、意図通りにマッチするかをその場で確認できる点が気が利いています。codex execpolicy check コマンドで事前テストもできます。

codex execpolicy check --pretty \
  --rules ~/.codex/rules/default.rules \
  -- gh pr view 7888 --json title,body,comments

Codex の Memories｜Codex 側の自動メモリ

では Codex 側はどうかというと、Codex にも Memories という公式の自動メモリ機能があります。過去のスレッドから有用なコンテキストを次の作業へ引き継ぐ仕組みで、Claude Code の自動メモリに対応すると考えてよいと思います。安定した好み・繰り返すワークフロー・技術スタック・プロジェクト規約・既知の落とし穴などを、Codex が自分で蓄積します。

有効化は設定アプリのトグル、または ~/.codex/config.toml への記述で行います。執筆時点ではデフォルト無効で、地域によっては利用できない場合があります（公式に EEA・UK・スイスは当初未提供と記載があります）。

[features]
memories = true

挙動は [memories] セクションで細かく制御できます。主なキーは次の通りです。

キー 役割
memories.generate_memories 新しいスレッドをメモリ生成の入力にするか
memories.use_memories 既存メモリを以降のセッションへ注入するか
memories.disable_on_external_context MCP・Web検索などを使ったスレッドを生成対象から除外するか
memories.min_rate_limit_remaining_percent 生成を始める前に必要な、レート制限残量の最小割合
memories.extract_model / memories.consolidation_model 抽出・統合に使うモデルの上書き

保存先は ~/.codex/memories/ で、markdown ベースのファイルとして蓄積されます。メモリ生成はターン内ではなくバックグラウンドで行われ、スレッドが十分に落ち着いてから要約される設計です。スレッド単位の制御には /memories コマンドがあり、そのスレッドだけ「既存メモリを使うか」「メモリを生成するか」を切り替えられます。画面コンテキストからメモリを構築する Chronicle という拡張もありますが、こちらは opt-in のリサーチプレビューで、執筆時点では macOS の ChatGPT Pro 向けに限定されています。

一点だけ、Claude の MEMORY.md のような「単一の目次ファイル」が Codex 側にあるかは、公式ドキュメントの記述だけでは明確に確認できませんでした。公式は「要約・永続エントリ・最近の入力・裏付け証拠」といった内容の分類を述べるにとどまります。実際の構成は、お使いの環境で ~/.codex/memories/ を確認するのが確実です。

「rules」という名前には注意

紛らわしいのが「rules」という名前です。Codex にも ~/.codex/rules/ がありますが、これは Claude の .claude/rules/（指示・コンテキストの整理）とは役割が異なります。Codex の Rules は前述の通り Starlark で書く「サンドボックス外コマンドの実行可否制御」で、AIへの指示ではなく実行レイヤーのガードレールです。名前は同じでも対応する機能ではない点に注意してください。

Claude の .claude/rules/ に役割が近いのは、Codex では AGENTS.md のネスト配置です。Claude が paths グロブで「どのファイルを触るか」に応じてルールを出し分けるのに対し、Codex は「どのディレクトリで作業しているか」に応じて、各階層の AGENTS.md / AGENTS.override.md を連結します。前者はファイル単位で動的、後者はディレクトリ単位で静的、という違いがあります。

repo/
├── AGENTS.md                     # リポジトリ全体のルール
└── services/
    └── payments/
        ├── AGENTS.md             # payments 配下のルール
        └── AGENTS.override.md    # payments 配下の一時的な上書き

比較してみると

観点 Claude Code（CLAUDE.md） Codex（AGENTS.md + Rules）
主な役割 永続的な指示・コンテキスト 永続的な指示（AGENTS.md）+ 実行権限制御（Rules）
形式 Markdown Markdown（AGENTS.md）+ Starlark（Rules）
階層探索 ルート→CWD で連結 ルート→CWD で連結
一時上書き CLAUDE.local.md AGENTS.override.md
自動学習（自動メモリ） あり（MEMORY.md を索引に蓄積） あり（Memories。~/.codex/memories/、既定で無効）
ルールの整理 .claude/rules/（Markdown、paths で出し分け） AGENTS.md のネスト（ディレクトリ単位）
「rules」の意味 指示・コンテキストの整理 コマンド実行制御（Starlark、別概念）
強制力 コンテキスト（保証なし）。強制は Hooks へ AGENTS.md はコンテキスト、Rules は実行を制御

両者とも「指示ファイルはあくまでコンテキストであり、確実な強制は別レイヤーで」という考え方は共通しています。違いは、Claude Code が自動メモリという「エージェントが自分で学ぶ」方向に踏み込んでいるのに対し、Codex は Rules でコマンド実行のガードレールを宣言的に書ける点です。どちらが良いというより、欲しい制御の種類で選ぶ場面が多そうです。

2. MCP｜外部ツールとの接続

MCP（Model Context Protocol）は、AIをツール・データソースに接続するためのオープンな標準です。課題追跡システムやデータベース、デザインツールなどに直接つなぎ、コピー&ペーストを介さずにエージェントが読み書きできるようにします。両ツールともこの標準に対応しています。

Claude Code の MCP

Claude Code は HTTP（推奨）・SSE（非推奨）・stdio・WebSocket のトランスポートに対応します。追加はコマンド一発です。

# HTTP（推奨）
claude mcp add --transport http notion https://mcp.notion.com/mcp

# 認証ヘッダー付き
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

# stdio（ローカルプロセス）
claude mcp add --transport stdio --env AIRTABLE_API_KEY=YOUR_KEY airtable \
  -- npx -y airtable-mcp-server

オプションはすべてサーバー名の前に置き、-- でサーバー名とコマンドを分離する点に注意が必要です。

スコープは3種類あり、優先順位が決まっています。

スコープ 適用範囲 チーム共有 保存場所
local（デフォルト） 現在のプロジェクトのみ しない ~/.claude.json
project 現在のプロジェクトのみ する（VCS経由） プロジェクトルートの .mcp.json
user 全プロジェクト しない ~/.claude.json

チームで共有したいサーバーは .mcp.json に project スコープで書きます。

{
  "mcpServers": {
    "shared-server": {
      "command": "/path/to/server",
      "args": [],
      "env": {}
    }
  }
}

.mcp.json 内では ${VAR} や ${VAR:-default} の形式で環境変数を展開できます。認証は /mcp コマンドからの OAuth ブラウザログインに対応し、401/403 応答時に認証が必要なサーバーとして自動検出します。

Claude Code で特徴的なのが**ツール検索（Tool Search）**です。MCPサーバーが多いとツール定義だけでコンテキストを圧迫しますが、ツール定義を遅延ロードすることで消費を抑えます。ENABLE_TOOL_SEARCH 環境変数で挙動を制御できます。

値 動作
未設定 全MCPツールを遅延ロード
true 全ツールを遅延ロード
auto コンテキストの10%以内に収まれば事前ロード、超過分は遅延
auto:N カスタム閾値（例 auto:5 で5%）
false 全ツールを事前ロード

MCPツールの出力が大きすぎる場合への配慮もあり、10,000トークンを超えると警告し、MAX_MCP_OUTPUT_TOKENS で上限を調整できます。リソースを @server:protocol://resource/path 形式で参照したり、MCPプロンプトを /mcp__servername__promptname のスラッシュコマンドとして呼べたりと、会話への統合も細かく作り込まれています。

Codex の MCP

Codex は stdio サーバーと Streamable HTTP サーバーに対応します。追加コマンドはこちらです。

codex mcp add context7 -- npx -y @upstash/context7-mcp

設定は config.toml に [mcp_servers.<server-name>] テーブルで書きます。stdio の例です。

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env_vars = ["LOCAL_TOKEN"]

[mcp_servers.context7.env]
MY_ENV_VAR = "MY_ENV_VALUE"

Streamable HTTP の例です。Bearer token や OAuth に対応します。

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
http_headers = { "X-Figma-Region" = "us-east-1" }

Codex の MCP 設定で目を引くのが、ツール単位の承認制御です。サーバーやツールごとに承認の挙動を細かく決められます。

[mcp_servers.chrome_devtools]
url = "http://localhost:3000/mcp"
enabled_tools = ["open", "screenshot"]
disabled_tools = ["screenshot"]  # enabled_tools の後に適用される
default_tools_approval_mode = "prompt"
startup_timeout_sec = 20
tool_timeout_sec = 45
enabled = true

[mcp_servers.chrome_devtools.tools.open]
approval_mode = "approve"

default_tools_approval_mode で auto / prompt / approve を指定し、特定ツールだけ tools.<tool>.approval_mode で上書きできます。enabled = false で削除せずに無効化、required = true で初期化に失敗したら起動自体を止める、といった運用フラグも揃っています。 タイムアウトは startup_timeout_sec（既定10秒）と tool_timeout_sec（既定60秒）で調整でき、ほかにも作業ディレクトリを指定する cwd、環境変数からヘッダーを与える env_http_headers、OAuth コールバックを固定する mcp_oauth_callback_port / mcp_oauth_callback_url といったキーがあります。CLI からは codex mcp add <name> --env KEY=VALUE -- <command> の形で環境変数を渡せます。

もう一つ Codex らしいのが、MCPサーバーが初期化時に返す instructions フィールドを Codex が読み、サーバー全体のガイダンスとして活用する仕組みです。サーバー作者は最初の512文字を self-contained にするよう推奨されています。ツール選択時に重要なガイダンスが確実に見えるようにするためです。OAuth 対応サーバーへのログインは codex mcp login <server-name> で行います。

比較してみると

観点 Claude Code Codex
トランスポート HTTP / SSE / stdio / WebSocket stdio / Streamable HTTP
設定形式 .mcp.json（JSON） config.toml（TOML）
スコープ local / project / user の3種 user / project（trusted のみ）
コンテキスト最適化 ツール検索による遅延ロード ツール許可/拒否リストで絞る
承認の粒度 サーバー単位の承認 サーバー・ツール単位の承認モード
サーバー側ガイダンス サーバー命令に対応 instructions の前方512文字を重視するよう明文化

Claude Code は「ツールが増えてもコンテキストを食わない」方向（ツール検索）に投資し、Codex は「どのツールをどう承認するか」を宣言的に書ける方向に作り込んでいる、という色の違いを感じます。多数のMCPサーバーを常用するなら Claude Code の遅延ロードが効きますし、ツール単位でガードレールを敷きたいなら Codex の承認モードが向いていそうです。

3. Skills｜再利用可能なワークフロー

同じ手順やチェックリストを毎回貼り付けているなら、それは Skill にする合図です。Skills は指示・リソース・任意のスクリプトをパッケージ化し、エージェントが信頼できる形でワークフローを再現できるようにする仕組みです。両者とも Agent Skills のオープン標準に準拠しています。

両ツールに共通する核心は Progressive disclosure（段階的開示） という設計です。最初は各スキルの名前・説明・パスだけをコンテキストに含め、実際に使うと決めたときにはじめて本体（SKILL.md）を読み込みます。これにより、長いリファレンス資料をスキルに同梱しても、使われるまではほとんどコストがかかりません。「常時読み込まれる指示ファイル」との最大の違いがここです。

Claude Code の Skills

SKILL.md にフロントマターと指示を書きます。

---
name: my-skill
description: What this skill does. Use when ...
disable-model-invocation: true
allowed-tools: Read Grep
---

Your skill instructions here...

配置場所とスコープは次の通りです。

場所 パス 適用対象
Personal ~/.claude/skills/<name>/SKILL.md 全プロジェクト
Project .claude/skills/<name>/SKILL.md このプロジェクトのみ
Plugin <plugin>/skills/<name>/SKILL.md プラグイン有効時

優先順位は enterprise > personal > project です。~/.claude/skills/ などの SKILL.md の変更は再起動なしで反映されるライブ変更検出にも対応しています。

Claude Code のスキルはフロントマターのフィールドが非常に豊富で、呼び出し制御を細かく書けます。代表的なものを挙げます。

フィールド 説明
description 何をするか・いつ使うか。自動起動の判断に使われる
disable-model-invocation true で Claude による自動読み込みを防ぎ、ユーザー呼び出し専用にする
user-invocable false で / メニューから隠す
allowed-tools アクティブ時に許可不要で使えるツール
model / effort 実行モデル・努力レベル
context fork でサブエージェントとして実行
paths アクティブ化を制限する Glob パターン
when_to_use 追加のトリガー文脈。description と合算され1,536文字で短縮される
argument-hint / arguments オートコンプリートのヒントと、$name で参照する名前付き位置引数
disallowed-tools アクティブ時にツールをプールから除外する
shell 動的注入で使うシェル（bash / powershell）

特に面白いのが動的コンテキスト注入です。!`<command>` 構文を書くと、スキルを送る前にシェルコマンドを実行し、その出力でプレースホルダーを置換します。

---
description: Summarizes uncommitted changes. Use when the user asks what changed.
---

## Current changes

!`git diff HEAD`

## Instructions

Summarize the changes above in two or three bullet points...

さらに context: fork を指定すると、スキルの内容がサブエージェント駆動のプロンプトになり、メイン会話のコンテキストを汚さずに実行できます。Skills と Subagents が連動する設計です。

なお、従来のカスタムコマンド（.claude/commands/deploy.md）も Skills に統合され、両者とも /deploy を作ります。既存のコマンドはそのまま動きつつ、Skills はサポートファイルや呼び出し制御といった拡張機能を持つ、という位置づけです。

スキルのライフサイクルとコンテキスト予算

スキルを設計するうえで知っておくと役立つのが、読み込みのライフサイクルです。スキルは呼び出されると「ひとつのメッセージ」として会話に入り、セッション中はそのまま残ります。後のターンで読み直されるわけではないため、SKILL.md は「その場限りの手順」ではなく「セッションを通して効く指示」として書くのが自然です。

会話が長くなって自動コンパクションが走ると、各スキルは最新の呼び出しが要約後に再アタッチされます。このとき先頭の5,000トークンが保持され、再アタッチ全体では25,000トークンの予算を共有します。古いスキルはコンパクション後に落ちることがあるため、繰り返し効かせたい指示は、その都度呼び出す前提で考えると安定します。

スキルの一覧（description）は常にコンテキストに載りますが、数が増えるとモデルのコンテキストウィンドウの1%を目安にした予算に収まるよう短縮されます。skillListingBudgetFraction（例 0.02 で2%）や環境変数で広げられ、/doctor でオーバーフローを確認できます。SKILL.md 自体は500行以下が推奨で、長いリファレンスは別ファイルに分け、SKILL.md から明示的に参照して読み込むタイミングを示します。scripts/ 以下のスクリプトは「読み込まれるのではなく、実行される」ものとして扱われます。

呼び出し時には $ARGUMENTS や $1 のほか、${CLAUDE_SKILL_DIR}（スキルのディレクトリ。同梱スクリプトの参照に便利）、${CLAUDE_SESSION_ID}、${CLAUDE_EFFORT} といったプレースホルダーが使えます。フロントマターを書き換えずに可視性を制御したい場合は、設定側の skillOverrides（on / name-only / user-invocable-only / off の4状態）が用意されています。権限の面では、/permissions で Skill（全拒否）・Skill(commit)（完全一致）・Skill(review-pr *)（プレフィックス一致）のように、スキル単位で許可・拒否を書けます。

Codex の Skills

Codex のスキルも SKILL.md（必須）と任意の scripts / references を持つディレクトリです。

my-skill/
  SKILL.md      必須: 指示 + メタデータ
  scripts/      任意: 実行可能コード
  references/   任意: ドキュメント
  assets/       任意: テンプレート・リソース
  agents/
    openai.yaml 任意: 外観・依存関係

---
name: skill-name
description: Explain exactly when this skill should and should not trigger.
---

Skill instructions for Codex to follow.

配置場所が Claude Code と異なり、.agents/skills を使う点に注意が必要です（設定は .codex/ ですが、スキルのオーサリングは .agents/skills）。

スコープ 場所
Repo $CWD/.agents/skills
Repo $REPO_ROOT/.agents/skills
User $HOME/.agents/skills
Admin /etc/codex/skills
System Codex に組み込み（skill-creator、plan など）

段階的開示のコンテキスト予算は、モデルのコンテキストウィンドウの約2%、不明時は8,000文字にキャップされます。スキルが多いとまず説明文が短縮され、非常に多い場合は一部が初期リストから省略されて警告が出ます。だからこそ、説明文は簡潔に、主要なユースケースとトリガーワードを前方に置くことが推奨されています。

起動は明示（/skills や $ でのメンション）と暗黙（説明にマッチして自動選択）の2モードです。スキル作成には組み込みの $skill-creator が用意され、キュレーション済みスキルは $skill-installer でインストールできます。

$skill-installer linear

無効化は config.toml で行います。

[[skills.config]]
path = "/path/to/skill/SKILL.md"
enabled = false

Codex には agents/openai.yaml という任意のメタデータファイルがあり、Codex app での表示名・アイコン・起動ポリシー・ツール依存を宣言できます。

interface:
  display_name: "Optional user-facing name"
  short_description: "Optional user-facing description"
  brand_color: "#3B82F6"

policy:
  allow_implicit_invocation: false

dependencies:
  tools:
    - type: "mcp"
      value: "openaiDeveloperDocs"
      transport: "streamable_http"
      url: "https://developers.openai.com/mcp"

allow_implicit_invocation: false にすると暗黙起動を禁止し、明示的な $skill 呼び出しのみに限定できます。スキルが「再利用可能なワークフローのオーサリング形式」であるのに対し、配布したくなったらプラグインにまとめる、という二段構えも明示されています。 なお interface には icon_small / icon_large（アイコン画像のパス）や default_prompt（スキルを使うときの定型プロンプト）も指定でき、dependencies.tools の各要素は type / value / description / transport / url で必要な外部ツールを宣言します。

比較してみると

観点 Claude Code Codex
配置 .claude/skills/ .agents/skills/
段階的開示 あり（説明のみ→本体） あり（予算 約2% / 8,000文字）
起動制御 フロントマター多数（disable-model-invocation 等） allow_implicit_invocation（openai.yaml）
動的コンテキスト !`command` でシェル実行を埋め込み スクリプト同梱
サブエージェント連携 context: fork で直接フォーク 直接のfork連携はなし（エージェント側で skills.config 等を上書き可）
配布単位 プラグイン プラグイン

設計の骨格（SKILL.md + 段階的開示 + プラグイン配布）はよく似ています。違いは配置パスと、起動制御の細かさです。Claude Code はフロントマターで呼び出し条件やツール・モデルまで宣言でき、動的コンテキスト注入のような小回りも効きます。Codex は app 連携やメタデータ宣言を含めた配布まわりが整理されている印象です。

4. Subagents｜タスク特化の分業

大きなタスクをこなすとき、探索・実装・レビューを1つのコンテキストに詰め込むと、すぐに文脈が溢れます。Subagents は独立したコンテキストウィンドウを持つ特化エージェントに作業を委譲し、メイン会話を汚さずに分業・並列化する仕組みです。

Claude Code の Subagents

Claude Code には組み込みのサブエージェントがいくつかあります。

エージェント モデル ツール 目的
Explore Haiku 読み取り専用 ファイル検出・コード検索・探索
Plan 継承 読み取り専用 プランモード中のコードベース研究
general-purpose 継承 全ツール 探索 + 変更を伴う複雑なタスク

Explore と Plan は CLAUDE.md と git ステータスの読み込みをスキップして高速・低コストに振っているなど、用途ごとにチューニングされています。

カスタムサブエージェントは .claude/agents/（プロジェクト）や ~/.claude/agents/（全プロジェクト）に Markdown で定義します。

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

フロントマターのフィールドが豊富で、model（sonnet/opus/haiku/inherit）、permissionMode、maxTurns、skills（プリロードするスキル）、mcpServers（スコープするMCP）、memory、isolation: worktree（一時 git worktree で実行）などを細かく指定できます。

呼び出しは自動委譲・自然言語・@agent-<name> メンション・セッション全体での claude --agent <name> と複数の経路があります。/agents コマンドにはタブ付きのUIがあり、実行中のサブエージェントの監視や、Claude による定義生成にも対応します。

他のサブエージェントとの連携も含めて、Claude Code の Subagents は「再利用可能な部品」として作り込む方向に寄っています。例えば skills フィールドでスキルをプリロードしたり、mcpServers でそのサブエージェント専用のMCPをインライン定義してメイン会話のコンテキストを節約したりできます。重要な制約として、サブエージェントは他のサブエージェントを生成できません（無限ネストの防止）。

Codex の Subagents

Codex は専門エージェントを並列に spawn し、結果を1つのレスポンスに集約します。組み込みエージェントは default（汎用）・worker（実装特化）・explorer（読み取り中心の探索）の3つです。

典型的な使い方は、プロンプトで「観点ごとに1エージェントを spawn して、全部待ってからまとめて」と依頼する形です。

Spawn one agent per point, wait for all of them, and summarize the result for each point.
1. Security issue
2. Code quality
3. Bugs
4. Race
5. Test flakiness

カスタムエージェントは ~/.codex/agents/（個人）や .codex/agents/（プロジェクト）にスタンドアロンの TOML ファイル（1ファイル1エージェント）として置きます。

name = "reviewer"
description = "PR reviewer focused on correctness, security, and missing tests."
model = "gpt-5.5"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
Review code like an owner.
Prioritize correctness, security, behavior regressions, and missing test coverage.
"""

必須フィールドは name / description / developer_instructions の3つで、model・model_reasoning_effort・sandbox_mode・mcp_servers・skills.config などは省略すると親セッションを継承します。カスタムエージェントは「スポーンセッションの config レイヤー」としてロードされる、という説明が Codex らしく、通常のセッション設定と同じキーを上書きできます。 任意で nickname_candidates（spawn 時に表示されるニックネーム候補のリスト）も指定できます。

なお、上記の gpt-5.5 や gpt-5.3-codex-spark といったモデル名は公式ドキュメントのサンプルに登場する値です。実際に利用できるモデル名は時期によって変わるので、設定する際はご自身の環境で利用可能なモデルに読み替えてください。sandbox_mode には read-only（読み取り専用）と workspace-write（ワークスペース書き込み可）があり、エージェントごとに権限の広さを宣言できます。これは Claude Code の permissionMode に相当する、Codex の安全性まわりの中核概念です。

全体の挙動は [agents] テーブルで制御します。

[agents]
max_threads = 6                 # 同時オープンスレッド数の上限（デフォルト6）
max_depth = 1                   # spawn のネスト深さ（デフォルト1 = 直接の子のみ）
job_max_runtime_seconds = 1800  # CSVバッチの各ワーカーのタイムアウト（デフォルト1800秒）

max_depth のデフォルトが1で、「直接の子は spawn できるが、それ以上のネストはできない」という制限は、Claude Code の「サブエージェントはサブエージェントを生成できない」という方針と発想が近いです。再帰委譲はトークン・レイテンシ・ローカルリソースを増やすので、本当に必要なときだけ上げる、という注意も添えられています。

Codex で独特なのが、CSV バッチ処理 spawn_agents_on_csv（experimental）です。1行1作業項目のCSVを読み、1行ごとにワーカーサブエージェントを spawn し、全完了を待って結果をCSVにエクスポートします。

Then call spawn_agents_on_csv with:
- csv_path: /tmp/components.csv
- id_column: path
- instruction: "Review {path} owned by {owner}. Return JSON ... via report_agent_job_result."
- output_csv_path: /tmp/components-review.csv

「同種のタスクを大量に並列で回す」という用途に振った機能で、各ワーカーは report_agent_job_result をちょうど1回呼ぶ必要があります。 output_schema で各ワーカーが返す JSON の構造を固定でき、max_concurrency や max_runtime_seconds で並列度・実行時間の上限を制御します。エクスポートされた CSV には、元データに加えて job_id や status などのメタ列が付きます。

比較してみると

観点 Claude Code Codex
組み込み Explore / Plan / general-purpose 他 default / worker / explorer
定義形式 Markdown（.claude/agents/） TOML（.codex/agents/、1ファイル1体）
モデル指定 model: sonnet 等 model = "gpt-5.5" 等
ネスト制限 サブエージェントは生成不可 max_depth（デフォルト1）
並列制御 フォアグラウンド/バックグラウンド max_threads（デフォルト6）
大量バッチ Agent Teams / Dynamic Workflows spawn_agents_on_csv
連携機能 スキルプリロード・専用MCP・worktree分離 config レイヤーとして設定上書き

両者とも「コンテキスト分離」「特化エージェント」「ネスト制限」という骨格は共通です。Claude Code は1体のサブエージェントを再利用可能な部品として作り込む（スキル・MCP・worktree との連携）方向、Codex は複数エージェントの並列オーケストレーション（max_threads・CSVバッチ）を素直に書ける方向、という違いがあるように見えます。PRを観点別に並列レビューするような用途では Codex のスタイルが書きやすく、特定の役割を持つ専用エージェントを育てるなら Claude Code の柔軟さが効きそうです。

5. Hooks｜ライフサイクルへのスクリプト注入

指示ファイルが「コンテキスト（お願い）」だとすれば、Hooks は「決まったタイミングで実行される制御点」です。ただしイベントによってアクションを止められるかは異なり、Codex は PreToolUse が完全なセキュリティ境界ではないと明記しているなど、必ずしも万能の強制レイヤーではない点には注意が必要です。プロンプトへのAPIキー混入をブロックしたり、ターン終了時に検証を走らせたり、会話をログに送ったりと、確実性が必要な処理はここに置きます。

Claude Code の Hooks

Claude Code のフックはイベントの種類が非常に多く、エージェンティックループのほぼ全段階をカバーします。代表的なものを挙げます。

イベント 発火タイミング ブロック可能
SessionStart セッション開始・再開 不可
UserPromptSubmit プロンプト送信前 可
PreToolUse ツール実行前 可
PermissionRequest 権限ダイアログ時 可
PostToolUse ツール成功後 実行後フィードバックのみ（取り消し不可）
Stop 応答完了時 可
SubagentStart / SubagentStop サブエージェント生成・完了時 一部可
PreCompact / PostCompact 圧縮前後 一部可
SessionEnd セッション終了時 不可

このほかにも InstructionsLoaded（CLAUDE.md読み込み時）、FileChanged、WorktreeCreate など、かなり細かいイベントが用意されています。

設定は settings.json に書きます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/script.sh",
            "timeout": 600,
            "if": "Bash(rm *)"
          }
        ]
      }
    ]
  }
}

ハンドラーの type は command のほか http・mcp_tool・prompt・agent（後者2つは実験的）まであり、HTTPエンドポイントやLLMプロンプト、別のMCPツール呼び出しをフックにできます。フックは stdin で JSON を受け取り、終了コードと stdout の JSON で挙動を制御します。

#!/bin/bash
COMMAND=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$COMMAND" | grep -q 'rm -rf'; then
  jq -n '{ hookSpecificOutput: { hookEventName: "PreToolUse",
    permissionDecision: "deny", permissionDecisionReason: "Destructive command blocked" } }'
else
  exit 0
fi

終了コードは 0（成功）・2（ブロッキングエラー）・その他（非ブロッキング）で意味が決まっています。PreToolUse では複数フックの判定が deny > defer > ask > allow の優先度で解決されるなど、制御フローがかなり作り込まれています。設定の優先順位は管理ポリシー > ユーザー > プロジェクト > ローカル > プラグイン > スキル/エージェント、で、フックは上書きでなく加算的にマージされます。スキルやサブエージェントのフロントマター内にもフックを書けるので、特定のスキルがアクティブな間だけ走る検証なども実現できます。

Codex の Hooks

Codex の Hooks も同じく「エージェンティックループに独自スクリプトを注入する」フレームワークです。対応イベントは SessionStart・UserPromptSubmit・PreToolUse・PermissionRequest・PostToolUse・PreCompact・PostCompact・SubagentStart・SubagentStop・Stop です。Claude Code に比べるとイベント数は絞られていますが、要所は押さえています。

Claude Code と並べて見られるよう、対応イベントを表にまとめます。

イベント 発火タイミング ブロック可能
SessionStart セッション開始・再開時 不可（コンテキスト追加）
UserPromptSubmit プロンプト送信時 可
PreToolUse ツール実行前 可（ただし完全な強制境界ではない）
PermissionRequest 承認要求の直前 可（承認可否を判定）
PostToolUse ツール実行後 実行後フィードバックのみ（取り消し不可）
PreCompact 圧縮前 可
PostCompact 圧縮後 一部可
SubagentStart サブエージェント生成時 不可（コンテキスト追加）
SubagentStop サブエージェント完了時 可（継続指示）
Stop 応答完了時 可（継続指示）

スコープの観点では、SessionStart と SubagentStart はスレッド／サブエージェントの開始時に発火し、それ以外はターン単位で発火します。SubagentStart は continue: false を返してもサブエージェントの起動自体は止められない点が、ブロック可能な他イベントとの違いです。

デフォルトで有効で、config.toml で無効化できます（正規キーは hooks、codex_hooks は非推奨エイリアス）。

[features]
hooks = false

設定は hooks.json か config.toml 内のインライン [hooks] テーブルの2形式で書けます。JSON の例です。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/bin/python3 \"$(git rev-parse --show-toplevel)/.codex/hooks/pre_tool_use_policy.py\"",
            "statusMessage": "Checking Bash command"
          }
        ]
      }
    ]
  }
}

同じ内容を TOML のインラインで書くこともできます。

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = '/usr/bin/python3 "$(git rev-parse --show-toplevel)/.codex/hooks/pre_tool_use_policy.py"'
timeout = 30
statusMessage = "Checking Bash command"

Codex のフックで強く意識されているのがレビューと信頼です。managed でない command フックは、実行前にその定義を正確にレビューして信頼する必要があります。Codex はフックのハッシュに対して信頼を記録するため、新規・変更されたフックはレビューするまで skip されます。/hooks コマンドからソース確認・レビュー・信頼・個別無効化ができます。ここでも Codex の trust モデルが一貫しています。

現状では type: "command" のみが実行され、prompt・agent ハンドラーはパースされても skip される点、async が未サポートな点など、実装途上の部分も正直に明記されています。PreToolUse についても「完全な強制境界ではない」と注記されており、Codex は別のツール経路で等価な作業をしうるため、unified_exec 由来のシェルや WebSearch はインターセプトされない、と説明されています。

企業向けには requirements.toml から managed hooks を強制でき、allow_managed_hooks_only = true でユーザー・プロジェクト・プラグインのフックを無視しつつ managed のみロードする、といった統制も可能です。

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"

比較してみると

観点 Claude Code Codex
イベント数 多数（細かい粒度） 主要10種に集約
設定形式 settings.json（JSON） hooks.json または config.toml の [hooks]
ハンドラー種別 command / http / mcp_tool / prompt / agent command のみ実行（他はパースのみ）
信頼モデル スコープ・権限で制御 フックのハッシュ単位でレビュー&信頼
マージ 加算的にマージ 全マッチを加算ロード
企業統制 管理ポリシー優先 requirements.toml の managed hooks
入出力 stdin JSON / 終了コード + stdout JSON stdin JSON / 終了コード + stdout JSON

入出力のプロトコル（stdin で JSON を受け、終了コードと stdout の JSON で制御）はよく似ていて、片方を理解すればもう片方も読みやすいです。違いはイベントの粒度と、ハンドラーの種別の広さです。Claude Code は HTTP や LLM プロンプトまでフックにできて表現力が高く、Codex は command に絞りつつ「レビューして信頼するまで走らせない」というセキュリティ寄りの設計を徹底しています。確実な制御を細かく書きたいなら Claude Code、フックの安全性を担保しながら運用したいなら Codex の trust フロー、という見方ができそうです。

6. Plugins｜すべてをまとめる配布の単位

ここまで見てきた MCP・Skills・メモリ／指示・Subagents・Hooks は、いずれも個別に .claude/ や .codex/ に置いて使えます。ただ、これらを「チームに配りたい」「複数プロジェクトで使い回したい」「バージョンを管理したい」となると、ファイルを手でコピーして回るのは現実的ではありません。そこで登場するのが Plugins です。

Plugins は、スキルやサブエージェント、MCPサーバー、フックといった構成要素を、ひとつのバージョン管理された配布単位にまとめる仕組みです。ただし何を同梱できるかはツールによって幅があり、たとえば CLAUDE.md や AGENTS.md などのメモリ／指示ファイルはプラグインの構成要素ではなく、リポジトリ単位で共有する点には注意が必要です。言い換えると、プラグインはこれまでの章で扱ってきた実行可能な機能の「入れ物」にあたります。両ツールとも、個人の手元設定（スタンドアロン）と、配布を前提としたプラグインを、はっきり別物として位置づけています。

スタンドアロン設定とプラグインの違いを、Claude Code の整理に沿って並べると次のようになります。

観点 スタンドアロン（.claude/ 直置き） プラグイン
呼び出し名 /hello /plugin-name:hello（名前空間付き）
向いている用途 個人のワークフロー、プロジェクト固有の調整、試作 チーム共有、コミュニティ配布、バージョン管理されたリリース、横断的な再利用
競合 同名で衝突しうる 名前空間で衝突を防ぐ

この「名前空間で衝突を防ぐ」という点は地味ですが重要です。スキルやコマンドが増えてくると、/deploy のような汎用的な名前は必ずぶつかります。プラグイン化しておけば /my-team:deploy のように一意になり、別チームのプラグインと同居させても破綻しにくくなります。

Claude Code の Plugins

Claude Code のプラグインは「自己完結型のコンポーネントディレクトリ」です。バンドルできる要素はかなり幅広く、これまでの章の機能をほぼ網羅しています。

要素 既定の置き場所 補足
Skills skills/<name>/SKILL.md scripts/ や reference.md も同梱できる
Commands commands/*.md 旧形式。新規は skills/ が推奨
Agents（サブエージェント） agents/*.md hooks / mcpServers / permissionMode はプラグイン提供エージェントでは非対応
Hooks hooks/hooks.json command / http / mcp_tool などのハンドラー
MCP servers .mcp.json プラグイン有効化で自動起動
LSP servers .lsp.json バイナリ自体は別途インストールが必要
Monitors monitors/monitors.json 実験的。バックグラウンド監視
Themes / Output styles themes/ / output-styles/ 表示まわり
実行可能ファイル bin/ 有効中は Bash の PATH に追加される

ディレクトリ構造の例です（パスは説明用の汎用名にしています）。

sample-plugin/
├── .claude-plugin/
│   └── plugin.json        # マニフェスト（任意）
├── skills/
│   └── code-reviewer/
│       └── SKILL.md
├── agents/
│   └── reviewer.md
├── hooks/
│   └── hooks.json
├── .mcp.json
├── bin/
└── CHANGELOG.md

ここで一つ、つまずきやすい点があります。.claude-plugin/ に入れてよいのは plugin.json だけで、skills/ や hooks/ などはすべてプラグインのルートに置きます。公式でも「よくある間違い」として明示されています。

マニフェスト plugin.json は実は任意で、省略すると既定の場所を自動検出し、ディレクトリ名からプラグイン名を導出します。書く場合の主なフィールドは次の通りです。

{
  "name": "sample-plugin",
  "displayName": "Sample Plugin",
  "version": "1.2.0",
  "description": "Brief plugin description",
  "author": { "name": "Your Team", "email": "team@example.com" },
  "license": "MIT",
  "skills": "./custom/skills/",
  "hooks": "./config/hooks.json",
  "mcpServers": "./mcp-config.json",
  "userConfig": {
    "api_token": { "type": "string", "title": "API token", "sensitive": true }
  }
}

必須フィールドはマニフェストを置く場合の name（kebab-case）だけです。version は任意の semver で、設定するとそのバージョンにピン留めされます。省略時は git のコミット SHA がバージョン代わりに使われます。コンポーネントのパス指定にはクセがあり、skills は既定の場所に追加されるのに対し、commands / agents / outputStyles などは既定を置換します。

userConfig を書いておくと、有効化時にユーザーへ値の入力を促せます。sensitive: true の値はキーチェーンに保存され、設定内に平文で残りません。入力値は ${user_config.KEY} で参照でき、CLAUDE_PLUGIN_OPTION_<KEY> という環境変数としても渡されます。

インストールと配布

開発中はインストールせずに読み込めます。

claude --plugin-dir ./sample-plugin     # ディレクトリや .zip を読み込む

変更を反映するだけなら再起動は不要で、/reload-plugins で読み直せます。配布・運用には専用のCLIコマンド群があります。

claude plugin install <plugin>[@marketplace] -s user|project|local
claude plugin enable <plugin>
claude plugin disable <plugin>
claude plugin update <plugin>
claude plugin list --json --available
claude plugin validate ./sample-plugin [--strict]

対話的に探すときは /plugin メニューを使います。マーケットプレイスは /plugin marketplace add <owner>/<repo> で追加でき、Anthropic は公式（自動で利用可能）とコミュニティ（レビュー後に登録）の2つを運営しています。

有効・無効の状態は、スコープごとの設定ファイルの enabledPlugins に書き込まれます。スコープは user（~/.claude/settings.json）・project（.claude/settings.json、チーム共有）・local（.claude/settings.local.json、gitignore）・managed（管理設定）の4種です。plugin.json の defaultEnabled は、ユーザー設定がないときのフォールバックという位置づけです。

環境変数と信頼

プラグイン内のスクリプトやフックでは、次の環境変数が使えます。

  • ${CLAUDE_PLUGIN_ROOT} — プラグインのインストール先への絶対パス。更新で変わるため、状態の書き込みには使わない
  • ${CLAUDE_PLUGIN_DATA} — 更新後も保持される永続ディレクトリ。node_modules やキャッシュ置き場に使う
  • ${CLAUDE_PROJECT_DIR} — プロジェクトルート

セキュリティ面では、マーケットプレイス由来のプラグインはいったんローカルのキャッシュにコピーしてから使われ、プラグインのルート外を参照できない（パストラバーサル制限）よう作られています。プロジェクトスコープのプラグインはワークスペース信頼を受け入れて初めて読み込まれ、コードを実行するMCPサーバーやLSPサーバーはさらに個別の承認が必要です。プラグイン提供のサブエージェントで hooks / mcpServers / permissionMode が使えないのも、配布物が勝手に強い権限を持たないようにする配慮です。

Codex の Plugins

Codex のプラグインも考え方は同じで、「スキル・アプリ連携・MCPサーバーを、再利用できるワークフローとしてまとめる」単位です。バンドルできる要素は次の4種が中心です。

要素 置き場所 補足
Skills skills/<name>/SKILL.md 再利用可能な指示
Apps .app.json GitHub / Slack / Google Drive などの外部連携。Codex 独自
MCP servers .mcp.json 追加ツールへのアクセス
Hooks hooks/hooks.json ライフサイクルフック

Claude Code との大きな違いが Apps（.app.json） です。Codex は外部サービス連携を「アプリ」として一級の構成要素に持っており、プラグインにアプリ連携を同梱できます。MCP経由で同等のことはできますが、Codex はこれを独立したコンポーネントとして扱う設計です。

ディレクトリ構造とマニフェストの例です。Codex ではマニフェスト .codex-plugin/plugin.json が必須です。

my-plugin/
├── .codex-plugin/
│   └── plugin.json        # 必須
├── skills/
│   └── my-skill/
│       └── SKILL.md
├── hooks/
│   └── hooks.json
├── .app.json
├── .mcp.json
└── assets/
    ├── icon.png
    └── screenshot-1.png

最小のマニフェストはこれだけです。

{
  "name": "my-first-plugin",
  "version": "1.0.0",
  "description": "Reusable greeting workflow",
  "skills": "./skills/"
}

配布画面での見え方まで作り込むなら、interface オブジェクトで表示名・説明・カテゴリ・アイコン・スクリーンショット・既定プロンプトなどを宣言できます。

{
  "name": "my-plugin",
  "version": "0.1.0",
  "description": "Bundle reusable skills and app integrations.",
  "skills": "./skills/",
  "mcpServers": "./.mcp.json",
  "apps": "./.app.json",
  "hooks": "./hooks/hooks.json",
  "interface": {
    "displayName": "My Plugin",
    "shortDescription": "Reusable skills and apps",
    "category": "Productivity",
    "capabilities": ["Read", "Write"],
    "defaultPrompt": ["Use My Plugin to summarize new CRM notes."],
    "brandColor": "#10A37F",
    "composerIcon": "./assets/icon.png",
    "screenshots": ["./assets/screenshot-1.png"]
  }
}

フックの定義は Claude Code とほぼ同形です。${PLUGIN_ROOT} でプラグインのパスを参照します。

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 ${PLUGIN_ROOT}/hooks/session_start.py",
            "statusMessage": "Loading plugin context"
          }
        ]
      }
    ]
  }
}

インストールと配布

Codex はマーケットプレイス単位で管理します。

codex plugin marketplace add owner/repo            # リモートリポジトリ
codex plugin marketplace add owner/repo --ref main
codex plugin marketplace add ./local-marketplace   # ローカル
codex plugin marketplace list
codex plugin marketplace upgrade

インストール済みプラグインは、codex を起動して対話中に /plugins を実行するとタブ分けされたブラウザが開き、Space キーで有効・無効をトグルできます。リポジトリ単位で配るには、リポジトリ直下に .agents/plugins/marketplace.json を置く方法があります。

{
  "name": "local-example-plugins",
  "interface": { "displayName": "Local Example Plugins" },
  "plugins": [
    {
      "name": "my-plugin",
      "source": { "source": "local", "path": "./plugins/my-plugin" },
      "policy": { "installation": "AVAILABLE", "authentication": "ON_INSTALL" },
      "category": "Productivity"
    }
  ]
}

source を git-subdir にすればGitリポジトリの特定パス・ブランチから取得でき、プラグインは ~/.codex/plugins/cache/<marketplace>/<plugin>/<version>/ にキャッシュされます。有効・無効は ~/.codex/config.toml で制御します。識別子は プラグイン名@マーケットプレイス名 の形です。

[plugins."gmail@openai-curated"]
enabled = false

プラグインにMCPサーバーが含まれる場合は、プラグインスコープで承認モードまで指定できます。

[plugins."my-plugin".mcp_servers.docs]
enabled = true
default_tools_approval_mode = "prompt"
enabled_tools = ["search"]

なお、公式の公開ディレクトリへのプラグイン公開・管理は「近日提供（coming soon）」と案内されており、現時点ではワークスペース内での共有が中心です。アプリ内では「Curated by OpenAI」「Shared with you」「Created by you」というカテゴリで整理されています。

環境変数と信頼

Codex のフックコマンドが受け取る環境変数は次の通りです。

  • PLUGIN_ROOT — インストール済みプラグインのルート
  • PLUGIN_DATA — 書き込み可能なデータディレクトリ
  • CLAUDE_PLUGIN_ROOT / CLAUDE_PLUGIN_DATA — 既存フック向けの互換変数

最後の2つが目を引きます。Codex は Claude Code 向けに書かれたフックがそのまま動くよう、CLAUDE_PLUGIN_ROOT / CLAUDE_PLUGIN_DATA を互換変数として提供しています。プラグインのエコシステムを、ツールをまたいで緩やかに相互運用できるようにしようという姿勢がうかがえます。

信頼の扱いも Codex らしく一貫しています。プラグイン同梱のフックは「非管理フック」として扱われ、ユーザーがその定義をレビューして信頼するまでは実行されません。インストールしても既存の承認設定はそのまま効き続けるため、プラグインを入れただけで権限が緩むことはない、という設計です。

比較してみると

観点 Claude Code Codex
マニフェスト .claude-plugin/plugin.json（任意、name のみ必須） .codex-plugin/plugin.json（必須）
主なバンドル要素 Skills / Agents / Hooks / MCP / LSP / Monitors / Themes / bin Skills / Apps / MCP / Hooks
アプリ連携 MCP経由（独立要素なし） apps（.app.json）として一級扱い
環境変数 ${CLAUDE_PLUGIN_ROOT} / ${CLAUDE_PLUGIN_DATA} PLUGIN_ROOT / PLUGIN_DATA + Claude互換変数
有効・無効 settings.json の enabledPlugins config.toml の [plugins."x@mkt"] enabled
CLI claude plugin install/enable/...、/plugin codex plugin marketplace ...、起動後の /plugins
配布 公式／コミュニティのマーケットプレイス Curated／Shared／Created（公開公開は近日提供）
信頼 キャッシュ＋パス制限＋スコープ別の信頼ゲート 同梱フックはレビュー・信頼するまで実行しない

骨格はよく似ています。どちらも「これまでの章の機能を、名前空間付き・バージョン管理された単位にまとめて配る」という発想で、plugin.json のフィールドや hooks.json / .mcp.json の形式も概ね共通です。違いとして目立つのは、Claude Code がLSPサーバーやモニター、テーマまで含めて幅広く取り込んでいる点と、Codex が外部サービス連携を apps として明示的に扱い、CLAUDE_PLUGIN_ROOT 互換変数でツール間の移植性を意識している点です。配布インフラの成熟度では、Claude Code が申請フォームを備えた公開マーケットプレイスをすでに運用しているのに対し、Codex は公開公開を準備中という段階の違いもあります。

プラグインは、この記事で見てきた5つの機能の「総まとめ」にあたります。まず Skills や Hooks を単体で作って手元で試し、チームに配りたくなったらプラグインにまとめる、という流れは両ツールで共通しています。最初からプラグイン化を目指すより、動くものができてから配布を考える、という順序が現実的だと思います。

横断まとめ｜どう使い分けるか

ここまでを一枚にまとめます。

機能 Claude Code Codex
設定の中心 機能別に分散（JSON / Markdown） config.toml 中心（TOML、補助ファイルは分散）
指示 CLAUDE.md + 自動メモリ AGENTS.md + Rules（実行制御）
MCP 4トランスポート + ツール検索 2トランスポート + ツール単位承認
Skills .claude/skills/、動的注入・fork連携 .agents/skills/、app連携・配布整理
Subagents 再利用部品志向（スキル/MCP/worktree） 並列オーケストレーション（CSVバッチ）
Hooks 多イベント・多ハンドラー 主要イベント + trust 徹底
Plugins 幅広い要素＋公開マーケットプレイス Skills/Apps/MCP/Hooks＋Claude互換変数

機能の対応関係を見ると、両者は驚くほど似た骨格を持っています。MCP・Skills・指示ファイル・Subagents・Hooks という5つの軸がほぼ揃っていて、Agent Skills のような共通標準も共有しています。AIコーディングエージェントの拡張ポイントが、業界として一定の形に収束してきているのかもしれません。

そのうえで性格の違いを挙げるなら、次のような傾向が見えます。あくまで現時点のドキュメントから読み取れる範囲の話で、用途によって評価は変わります。

  • Claude Code — 各機能を細かく宣言的に制御でき、機能どうしの連携（Skills × Subagents、Subagents × MCP など）が作り込まれています。ツール検索による大量MCPのコンテキスト最適化や、フックの表現力の高さも特徴です。「部品を丁寧に組み上げて自分のワークフローを設計する」スタイルに向いていると感じます。
  • Codex — config.toml を中心に据えた設定と trust モデルの一貫性が際立ちます。承認モードやフックのレビュー&信頼、Rules によるコマンド制御など、安全性・統制を宣言的に書ける設計です。CSVバッチのような並列処理も素直に書けます。「設定を一元管理しつつ、安全に並列で回す」スタイルに向いていそうです。

どちらか一方に決め切る必要は必ずしもなくて、両方を触ってみて、手になじむ方や、チームの統制要件に合う方を選ぶのが現実的だと思います。私自身、設定思想の違いを知ってから読むと、それぞれのドキュメントがぐっと理解しやすくなりました。この記事がその一助になればうれしいです。

両ツールとも更新が活発な領域です。フラグ名や挙動の細部は変わることがあるので、実際に設定する際は本記事末尾の公式ドキュメントで最新情報を確認してください。

参考リンク

Claude Code 公式ドキュメント

OpenAI Codex 公式ドキュメント

3
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?