はじめに：使い比べじゃなく「主利用」を決める 🧭

CLIコーディングエージェント、便利すぎて増えがちですよね。
でも実務では「3つを器用に使い分ける」より、**主利用を1つ決めて、残りは“必要なときだけ借りる”**ほうが運用が安定します（設定・習慣・事故対応が1本化できる）🧹✨

この記事はそのための比較メモです。

※価格・無料枠・上限は変わりやすいので、本文の数字は参照先の記載ベースで、最後にリンクをまとめます（通貨/税/地域で差が出ます）。

先に“財布”の話：無償/有償でどこまで回る？ 💸

主利用を決めるとき、性能より先に 継続コストで詰むことがあるので、ここを最優先で整理します。

Codex CLI（OpenAI）

ChatGPTプランで使う
Codexは ChatGPT Plus / Pro / Business / Edu / Enterprise に含まれる、という建て付け。
ざっくり価格感は以下（参照先の表そのまま）👇
- Plus $20/月
- Pro $200/月
- Business $30/ユーザー/月
  さらに、上限到達後は ChatGPT credits で延長できる（= 定額＋上限＋追加クレジット）1
APIキーで使う（CIなど）
API Key運用は トークン従量課金（標準APIレート）。モデル単価は API Pricing を参照 1

Claude Code（Anthropic）

Claudeのサブスクで使う
Claudeの有償プラン（例：Pro $20/月、Max $100/月 / $200/月 など）でClaude Codeを利用、という整理が明示されています 7
さらにCLIとしての公式Docsがあり、「設定して運用する」前提の情報が揃っている 6
上限超えの継続
上限を超えた分は **Extra usage（追加利用）**として **標準APIレート（トークン従量）**で継続できる、という案内 9

Gemini CLI（Google）

まず試す（無料枠が太く書かれてる）
個人ログインで 60 req/min・1,000 req/day が「無料枠」として明記されていて、とにかく着手しやすい 10
追加の整理はGemini CLI側の “Quota and pricing” も参照 11
組織利用・増枠の入口（席課金）
組織での導入や強い枠が欲しい場合は、Gemini Code Assist の席課金（例：Standard $22.80/ユーザー/月、Enterprise $54/ユーザー/月）が分かりやすい入口 14
参考：Developer Program
Google Developer Programにも有料階層があるので、必要ならBenefits側を確認（※価格は改定されやすいので本文では固定値にしません）15

結論を先に：意思決定の近道（※最終結論は出しません）🧠

最初に“雑な結論”だけ置きます。本文はこの結論の根拠を確認するパートです。

まず無料で触って感触を掴む → Gemini CLI（無料枠が明記されてる）10
「上限＋追加課金」の運用を明確にしたい → Codex（credits が前提として整理されてる）1
「設定して運用する」方向に寄せたい → Claude Code（公式Docs/機構が整理されてる）6
“割り込み制御（Hooks）”が要る → Claude / Gemini（Codexは notify が得意）2 13

機能比較：決定打 → 方言（好み）の順 🧩

決定打①：割り込み（Hooks）と事後連携（notify）🪝🔔

ここは「方言」じゃなくて できる/できないの壁になりやすいです。

Hooks：フローに“割り込める”（止められる）

例：危険コマンドをブロック、生成物がテスト通るまで止める、など
Claude Codeは フックを含む拡張要素をプラグインとして扱える、と整理されている 12
Gemini CLIも Hooks を持つ（公式Docsに章がある）13

notify：終わってから“連携をキック”する（止めない）

Codex CLIは notify で イベント発火（現状 agent-turn-complete）に対し外部プログラムを起動できる
→ Slack通知、CIキック、デスクトップ通知など「事後連携」が得意 2

ポイント

Hooksは「止められる（割り込める）」
notifyは「終わってから繋ぐ」
→ ここが最初の分岐です 🧭

方言①：プロジェクト指示の置き方（似てるけど“公式の分割機構”が違う）📌

実務で落ち着く粒度はだいたい共通です。

User Global（自分の基本ポリシー）
Project Root（リポジトリ共通のルール）
Subdir（領域/役割別の追加ルール）

Codex：AGENTS.md が中核

AGENTS.md を軸にプロジェクト指示を読み込む前提で設計されている 3
さらに、リポジトリ内で AGENTS.md をネストして分割運用できる（公式に言及あり）1

Claude：CLAUDE.md ＋ @import ＋ rules/

CLAUDE.md は 階層的に読み込む（cwdから上に辿る/サブツリーも発見）13
さらに @path/to/import で追加ファイルをimportできる（これが“分割の契約”）13
大きくなったら .claude/rules/ に トピック別に分割できる 13

Gemini：GEMINI.md ＋ memport（@file.md）

GEMINI.md を @./file.md で分割できる（Memory Import Processorとしてドキュメント化）16

方言②：Extensions / Plugins / Subagents（拡張の方言）🧰

Geminiには Extensions の導線があり、インストール/作成の入口が用意されている 17
Claudeはプラグインの中に スラッシュコマンド/エージェント/フック/スキル/MCP をまとめて扱う、という整理 12

ここは「決定打」になりにくく、最後に味見する項目です（モデルの癖やチーム運用で逆転しがち）🍵

方言③：接続（MCP）🔌

外部連携の“契約”を硬くしたいなら、最終的にはMCPが安定しやすいです。

Codexは MCPを公式Docsとして整理していて、設定導線も明確 4
Claude/Gemini側もMCPや拡張の設計が進んでいる（ただし運用の好みが出る）

私的考察（あとがき）📝

結論として、設定が未成熟すぎた時期はCodexがお気に入り、今はClaudeに転向している感じです。だから、他人に薦めるのはCodexで、Codexについて愚痴られたらClaudeかな

思想差：拾って補完するCodex／最短で到達するClaude 🧠

同じ“指示ファイル運用”でも体験が変わる理由を、雑に言うとここです。

Codex：AGENTS.md を軸に、リポジトリ内の情報を拾って補完しやすい（探索して前に進む）
Claude：CLAUDE.md のインポートなど「契約」を明示できる一方で、価値が見えない/辿れない情報はスキップして自走しやすい（最短で到達する）

ここでありがちなdisりが「Claudeは契約を全部読まない」なんですが、正確には “最短で価値に到達できない契約は読み切らない” に近い印象です。
（= 書き方次第で挙動が変わる）

だから「ドキュメントを太らせない」仕組みがあると勝ち 🔁

指示ファイル運用は放っておくと必ず太るので、劣化を仕組みで止めると楽です。
自分はこれ👇を作ったので使っています。試行錯誤段階なので品質イマイチかも。

agent-document-reviewer：AGENTS.md / 指示ドキュメントの典型的劣化（肥大化・重要ルール埋没・冗長化）を検知して、メトリクスと改善案を返すツール 18

claude

/plugin marketplace add https://github.com/unagi/agent-document-reviewer
/plugin install agent-document-reviewer

Claude Code以外の人はリポジトリREADMEからとってください！