Claude Code 29ツール vs Codex 7ツール: 設計思想は真逆だった

毎週追いかけるのに疲れて、Claude Code と Codex それぞれの原点に立ち返ることにしました。入手できる SDK の型定義、システムプロンプト、設定スキーマをすべて開いて調べました。各ツールが何をするかだけでなく、なぜツール数がこれほど大きく異なるのかを理解したかったのです。

Claude Code は 29 のツールを公開しています。Codex は 7 つです。この比率が気になり続けました。単なる機能差では説明がつかないからです。十分な資金と優秀なエンジニアを持つ二つのチームが、偶然 4:1 の比率に落ち着くわけがありません。この差は意図的なものであり、その背景にある思想は、AI が開発環境とどう向き合うかについての根本的に異なる二つの哲学を示しています。

ツールの粒度はセキュリティの意思決定

最も顕著な違いはファイル操作の扱い方です。Claude Code はファイル操作を Read、Write、Edit、MultiEdit という四つの独立したツールに分割しています。検索にも専用ツールがあり、Grep と Glob は Bash から完全に独立しています。つまり settings.json で Read は許可しつつ Write をブロックするといった設定が可能です。ファイルを一切変更する権限を与えることなく、エージェントにコードベースを検索させることができます。権限制御はツールレベルで行われます。

Codex は別のアプローチを取ります。エージェントに shell、apply_patch、file_read をコアのプリミティブとして提供します。それ以外はすべてシェル経由です。ファイルを検索したい? シェルコマンドで行います。ディレクトリを一覧表示したい? やはりシェルです。セキュリティはツールレベルの権限ではなく、シェルコマンドに対してパターンマッチングを行い、allow・prompt・block のカテゴリに分類する execpolicy ルールによって実現されます。

どちらのアプローチも間違いではありません。Claude Code のモデルは細かいロックを提供しますが、より広いツールサーフェスを維持する必要があります。Codex のモデルは把握しやすいシンプルさを持ちますが、セキュリティの強制がシェルコマンドの文字列マッチングに委ねられるため、コマンドが複雑になると脆くなります。工夫されたパイプのチェーンが、単純なコマンドを想定して書かれた execpolicy ルールを回避してしまうケースも見てきました。

詳細な内訳は以下のとおりです。

• Claude Code（29 ツール）: ファイル 4 ツール（Read/Write/Edit/MultiEdit）、検索 3 ツール（Glob/Grep/LS）、Web 2 ツール、cron 3 ツール、MCP 4 ツール、Bash など
• Codex（7 ツール）: shell、apply_patch、file_read、web_search、update_plan、write_stdin、js_repl

スキルの配布がエコシステムを分断する

両ツールともエージェントスキルのオープン標準を採用しており、一つの SKILL.md ファイルがスキルの動作を定義します。構造は同一です。配布モデルは異なります。

Codex は中央集権型の配布システムを構築しました。$skill-installer を実行すると、OpenAI 公式スキルリポジトリからキュレーションされたスキルを取得できます。GitHub の URL を渡せばサードパーティのスキルもインストールできます。会話を通じて新しいスキルをインタラクティブに生成する $skill-creator もあります。npm に似た体験です。一つのコマンド、一つのレジストリ、即座に利用可能になります。

Claude Code は反対方向に進みました。.claude/skills/ に SKILL.md ファイルを手動で作成するか、/plugin marketplace add で git リポジトリからバンドルをインストールします。公式の単一レジストリはありません。スキルはコミュニティリポジトリや共有リンク、口コミで発見されます。

最初は Codex の中央集権型モデルの方が好みでした。発見しやすさが優れているからです。ただ数週間両方を使ってみると、分散型のアプローチには明確な利点があることがわかりました。セッション中にスキルファイルを編集すると、再起動なしで変更が即座に反映されます。Codex のインストール済みスキルは変更のたびに再インストールが必要です。カスタムワークフローを繰り返し調整するとき、この差は思っていた以上に重要でした。

比較まとめ:

• 呼び出し方: Claude Code は /skill-name、Codex は $skill-name
• 保存先: .claude/skills/ vs .agents/skills/
• 組み込みスキル: Claude Code は /simplify、/batch、/loop、/claude-api、Codex は $skill-installer、$skill-creator
• 配布: 分散型マーケットプレイス vs 中央集権型リポジトリ

セッション診断ツールで差が明確になる

基本的な機能は両ツールで共通しています。/model、/plan、/review、/clear、/fast などです。違いが現れるのはセッションの内部把握においてです。

Claude Code はセッション内部で何が起きているかを理解するための機能に力を入れています。/compact でコンテキストの圧縮を手動で実行できます。/context では読み込まれている内容を確認できます。/cost はトークン消費をリアルタイムで追跡します。/doctor は設定の問題を診断します。/rewind で直前の会話状態に戻せます。/insights は一ヶ月の使用パターンを分析して改善提案をします。/usage はセッションをまたいだ累積消費量を表示します。セッション状態の理解と管理のためだけに七つのコマンドが用意されています。

Codex は別の方向に集中しています。/personality でエージェントのコミュニケーションスタイルを調整できます。/theme で視覚的な見た目を変えられます。/apps で接続済みのアプリケーションを管理します。これらは診断ツールではなく、UX のカスタマイズ機能です。

この差はより深い哲学的な分岐を反映しています。Claude Code はセッションを積極的に監視して制御すべきものとして扱います。Codex はセッションを裏で動いているものとして扱い、ユーザーはエクスペリエンスのカスタマイズに集中できるようにしています。数ヶ月使ってみると、両方欲しいと感じます。診断機能はセッションが迷走したときに助けてくれますが、詳細なアーキテクチャ作業と素早いバグ修正を切り替えるときにはパーソナリティを調整できることもありがたいと思います。

• Claude Code（約 35 コマンド＋4 つのバンドルスキル）: /compact、/context、/cost、/doctor、/rewind、/insights、/usage などセッション診断が充実
• Codex（約 19 コマンド）: /personality、/theme、/copy、/apps、/skills、/agent、/tools など UX カスタマイズが強い

チームアーキテクチャは異なる前提から出発している

マルチエージェント連携の扱い方に、おそらく最も深い設計の違いが現れています。

Claude Code のエージェントチームはピアツーピア通信を採用しています。チームメンバーはリードエージェントを経由せずに直接メッセージを送り合います。タスクリストを共有し、自律的に調整します。2 から 16 のエージェントを実行でき、誰が何を担当するかを互いに調整します。リファクタリングのタスクで三つのエージェントを使ってテストしたところ、トークン消費量は同じ作業をする単一セッションの 3 から 7 倍になりました。調整のオーバーヘッドは現実のコストです。ただし、タスクが並列探索から本当に恩恵を受ける場合（たとえば異なる仮説を同時に調べるエージェントを使ってレースコンディションをデバッグするとき）は、P2P モデルの方が速く答えを見つけます。

Codex はハブスポーク型モデルを採用しています。子エージェントは親にのみ報告します。横方向の通信はありません。spawn_agents_on_csv コマンドは CSV ファイルからエージェントを一括生成します。これは各作業単位が独立した、いわゆる並列分解しやすいタスク向けに最適化されています。「このマイグレーションを 200 ファイルに適用する」や「このリスト内のすべてのエンドポイントに対してこのチェックを実行する」といった用途です。

P2P が常に優れているわけではありません。単純なバッチタスクで Claude Code のエージェントが互いに重複作業について話し合い続けたため、大量のトークンを無駄にしたことがあります。そのタスクには Codex のハブスポークが正解でした。

• Claude Code: 共有タスクリストを使った P2P メッセージング、2 から 16 エージェント、tmux スプリットペインサポート
• Codex: ハブスポーク型アーキテクチャ、spawn_agents_on_csv による CSV ベースの一括エージェント生成

フックの粒度が自動化の深さを決める

Claude Code はツール実行のライフサイクルの複数の時点で介入できます。PreToolUse はツールの実行前に発火し、呼び出しの検証や変更が可能です。PostToolUse は実行後に発火するため、ファイル保存のたびにフォーマッターを自動実行するといった処理を追加できます。Notification フックはエージェントの通信をキャプチャします。PreCompact はコンテキスト圧縮の前に発火し、重要な情報を保存する機会を与えます。HTTP Hooks は外部 URL に JSON を POST でき、Claude Code を CI パイプライン、Slack、カスタムダッシュボードと連携させられます。

Codex はシンプルに保っています。シェルコマンドに適用される allow/prompt/block ルールを持つ一つの execpolicy ファイル。エージェントの動作を制御する拡張サーフェスはそれだけです。

PostToolUse フックを設定して、すべての Write 操作の後に Prettier を実行するようにしました。五分でできて、フォーマット関連のフォローアッププロンプトのカテゴリ全体がなくなりました。この種の精密な自動化は Codex のモデルでは実現できません。毎回のプロンプトに「書いた後に Prettier を実行してください」と含めるか、スキルに組み込む必要があります。

ただ Codex のシンプルさにも価値があります。Codex の設定を誤設定されたフックで壊したことは一度もありません。Claude Code では二回やらかしました。一度は PreToolUse フックが正当なファイル読み込みを静かにブロックして、二十分間の混乱したデバッグを引き起こしました。

• Claude Code: PreToolUse、PostToolUse、Notification、PreCompact、HTTP Hooks
• Codex: 三段階（allow/prompt/block）の execpolicy ルールファイル

選ぶべきはアーキテクチャであって、機能リストではない

29 対 7 の比較は、一方が他方より高機能だという話ではありません。同じ設計の問いに対する二つの異なる答えです。AIコーディングエージェントは、その能力を個別に制御可能な単位にどこまで分解すべきか、という問いです。

Claude Code は「すべて」と答えます。あらゆる操作に独自のツール、独自の権限サーフェス、独自のフックポイントがあります。設定の複雑さと引き換えに最大限の制御を得られます。Codex は「本質的なものだけ」と答えます。コア操作に専用ツールを割り当て、それ以外はポリシーベースのガードレールを持つシェル経由で処理します。粒度と引き換えにシンプルさを得られます。

特定のプロジェクトでどちらのツールを使うか選ぶとき、機能リストはほとんど関係ありません。重要なのは、そのプロジェクトに細かい権限制御が必要かどうか（規制された環境にあるコードベース、アクセスレベルの異なる複数のコントリビューター）、あるいは軽量なシンプルさが必要かどうか（個人プロジェクト、高速なイテレーション、最小限のセットアップ）です。その上に構築するアーキテクチャが、その後のすべてのワークフローの意思決定を形作ります。