// エージェント比較 · 2026年9月
Claude Code と Codex ― 併用したとき、設定は何回書くのか
結論から。日々のコーディングと設計は Claude Code、非同期の実行と PR レビューは Codex ― この使い分けは日本語で読める比較記事がほぼ一致して出している答えで、実際たいていの人は最終的に両方を入れる。問題はその先です。両方入れると設定は二重になります。skill は Claude Code が ~/.claude/skills/、Codex は公開標準の ~/.agents/skills/ を読むので置き場所が 2 か所。MCP サーバーの登録も、それぞれの設定ファイルに 2 回。同じ内容を二度書き、片方だけ更新して静かにずれる ― これが「併用が最適」の請求書です。この記事では、その二重ぶんを実測した数字で示し、1 コマンドで両方に書いてずれを消す方法と、両者に共通する空白 ― サンドボックスの外側にあるメール・ドメイン・公開・決済 ― の埋め方まで扱います。
比較表 ― 併用する人が実際に触る場所
機能の総覧はすでに良い日本語記事があります(Qiita の 3,500 語級の対照記事が MCP / Skills / メモリ / Subagents / Hooks / Plugins を一つずつ並べていて、あれ以上の網羅は要りません)。ここでは総覧ではなく、併用したときに二度触ることになる場所だけを並べます。すべて 2026 年 9 月 4 日に同じ Mac 上で実際に叩いて確認したものです。
| Claude Code | Codex | |
|---|---|---|
| 提供元 | Anthropic | OpenAI |
| 動く場所 | ターミナル / IDE 拡張 | ターミナル / IDE 拡張 / クラウド実行 |
| 指示ファイル | CLAUDE.md | AGENTS.md |
| 設定の置き場所 | ~/.claude/ | ~/.codex/config.toml |
| skill の置き場所 | ~/.claude/skills/ | ~/.agents/skills/(公開標準。Pi・OpenClaw と同じ一枚を共有) |
| MCP の登録 | claude mcp add <名前> -- <コマンド> | codex mcp add <名前> -- <コマンド> |
| サンドボックス | 実行前の許可のしくみ | 同上。加えて sandbox_permissions を設定で明示できる |
| 料金 | どちらもサブスクリプションと API 従量課金の両方で使えます。金額は改定が頻繁なので、各社の料金ページで確認してください ― この記事では数字を凍結しません | |
表の下 3 行が、この記事の残り全部の理由です。コマンドの形はほとんど同じなのに、書き込まれる先が別。だから「同じことを 2 回」が発生します。
速度と品質については、すでに実測がある
どちらが速いかは、日本語圏にすでに手を動かした比較があります。受託開発会社の技術ブログが自社の Next.js プロジェクトで同じタスク群を両方に投げ、開発速度・コード品質・コスト・拡張性の 4 軸で採点している ― ここで繰り返す価値はありません。読んで残る共通見解はこうです。
- 対話しながら設計を詰める作業は Claude Code。手元で回す前提の設計・リファクタリング・読み解きで評価が高い。
- 投げて放っておく作業は Codex。非同期の実行と PR レビューのように、席を外している間に進んでほしい仕事で強い。
- 差はモデルの賢さより仕事の渡し方(同期か非同期か)で出る。
だから結論は毎回「併用が最適」になります。それは正しい。ただしそこで記事が終わるので、併用した人が翌日ぶつかることが誰にも引き継がれていません。
拡張の入口:MCP と Skills はどう違うのか
拡張の入口は 2 種類あります。MCP サーバーは構造化されたツール一覧を渡すプロセスで、登録するとセッションのたびに定義がコンテキストに載ります。Skill は Markdown の手順書(SKILL.md)を所定のディレクトリに置くだけで、必要になったときだけ読まれます。
その置き場所が食い違っています。Claude Code は ~/.claude/skills/、Codex は ~/.agents/skills/ という公開標準のディレクトリ ― 後者は Pi や OpenClaw も同じ一枚を読むので、その三者の間ではファイルは 1 つで済みます。
この非対称が二重化の正体です。Codex・Pi・OpenClaw を何台入れても skill は 1 枚。しかし Claude Code を足した瞬間、2 枚になります。「共通ディレクトリがあるから一枚で済む」という説明は、Claude Code を数に入れていません。
どちらを選ぶか(1 つだけ入れるなら)
片方だけにするなら、判断はほぼ 1 問です。あなたはその作業のあいだ、画面の前にいますか。
いる ― 設計を相談しながら書き進める、既存コードを読み解く。この形なら Claude Code。いない ― タスクを投げて別の仕事に移る、PR にレビューを付けさせる、クラウド側で走らせて結果だけ受け取る。この形なら Codex。
そして、たいていの人はどちらの日もあるので両方入れます。ここからが本題です。
併用するとき、設定は何回書くのか
実測です。同じ Mac で clize install --dry-run(何も書かずに、書く予定だけを出すモード)を走らせると、出力はこう 2 ブロックに割れます。
$ clize install --dry-run
clize install · dry run (--dry-run, no files written)
▸ Claude Code
skill · up to date · clize → ~/.claude/skills/clize/SKILL.md
…
▸ Codex / Pi / OpenClaw (shares ~/.agents/skills)
skill · up to date · clize → ~/.agents/skills/clize/SKILL.md
…
つまり手で入れるなら、skill のファイルは 2 か所にコピーすることになります。Pi と OpenClaw を足しても 2 か所のままですが(下のブロックを共有するため)、Claude Code がある限り 1 か所にはなりません。
MCP も同じです。コマンドの形はほぼ同じでも、書き込まれる先が別なので 2 回打ちます。
# Claude Code 側
$ claude mcp add clize -- clize-mcp
# Codex 側(設定は ~/.codex/config.toml に入る)
$ codex mcp add clize -- clize-mcp
ここで本当に効いてくるのは打鍵の回数ではなく、ずれです。手順書を更新して片方のディレクトリだけ直すと、同じ名前の skill が 2 つあって中身が違う、という状態になります。どちらのエージェントがどちらを読んだかは、動かしてみるまで分かりません ― お金を使うコマンドや外部にメールを出すコマンドの安全弁が入っている手順書なら、これは笑えない話です。
この二重ぶんを畳むのが clize install の役目です。1 コマンドで両方のディレクトリに同じ版を書き、MCP を使いたければ --mcp を足すと両方の宿主に登録まで行きます(--claude / --codex で片方だけにもできます)。
$ npm i -g @clize/clize
$ clize login
$ clize install # 検出した宿主すべてに skill を配置
$ clize install --mcp # MCP サーバーも両方に登録したい場合
更新も 1 回です。clize update を叩けば両方の skill が同じ版に揃い、clize doctor が「CLI の版と skill の版がずれていないか」を見て、ずれていればその場で直せと言います。要するに 置き場所が 2 か所であることは変わらないが、書く回数は 1 回に戻る。これが併用者にとっての実質的な差です。
サンドボックスの外側:メール・ドメイン・公開・決済
もう一つ、両方に共通していてどちらも埋めない空白があります。Claude Code も Codex も、リポジトリの中では驚くほど有能ですが、サンドボックスの外側には手が届きません。自分のメールアドレスを持てない、認証コードを読めない、ドメインを取れない、書いたサイトを公開できない。人間が 4 つのダッシュボードを行き来する係として残ります。
Clize はその層だけを担当する CLI と MCP サーバーです(モデルの API キーは不要 ― 既に払っているエージェントの下に敷く道具)。上の clize install がこの能力を両方の宿主に同時に渡します。
$ clize claim mystudio --email
✓ mystudio.clize.app is yours; the site and support@mystudio.clize.app are in place.
無料の handle を 1 つ取ると、サイトの住所と support@ の受信箱が同時に立ちます(--email なしなら受信は既定でオフ ― 共有ゾーンの DNS レコードを節約するため)。公開は 1 行です。
$ clize deploy ./site --domain mystudio.clize.app
Live at https://mystudio.clize.app (14 files: 14 KV + 0 R2; uploaded 14, skipped 0; TLS automatic)
自分のドメインに載せたい場合は、探して買って、そのまま公開先にできます。お金が動くコマンドには必ず関門があります ― 素で打つと見積もりだけを返して止まり、--confirm を足したときだけ登録されます。外向きのメールも既定は下書きだけ。エージェントに握らせても事故にならないのは、この 2 つの関門が製品側にあるからです。
$ clize domain search mystudio
$ clize domain buy mystudio.com # 見積もりのみ。登録はされない
$ clize domain buy mystudio.com --confirm
$ clize email setup mystudio.com # support@mystudio.com(MX / SPF / DKIM / DMARC まで)
線引きも書いておきます。ホスティングは静的サイトのみ。フォームや順番待ちの受け付け、決済つきの販売ページは載りますが、バックエンド・データベース・ログイン状態を持つアプリは動きません。無料枠は handle 3 つ、受信箱 5 つ、デプロイ 1 日 20 回、1 サイト 500 MB。
受信箱の話は エージェント専用のメールアドレスがなぜ要るのか、MCP の設定は MCP サーバーとは何か にあります。
// よくある質問
Claude Code と Codex はどちらを選ぶべきですか?
画面の前にいる作業(設計を相談しながら書く、既存コードを読み解く)なら Claude Code、席を外している間に進んでほしい作業(非同期の実行、PR レビュー、クラウドでの実行)なら Codex です。日本語で読める実測比較もおおむねこの結論で、実際には両方入れて仕事の形で使い分ける人が多数派です。
両方入れると、skill は 1 か所で済みますか?
済みません。2 か所になります。Codex は公開標準の ~/.agents/skills/ を読み、Pi と OpenClaw も同じ一枚を共有しますが、Claude Code は ~/.claude/skills/ を読むためです。2026 年 9 月 4 日に同じ Mac で clize install --dry-run を実行すると、出力が二つのブロックに分かれることで確認できます。
MCP サーバーの登録は両方に必要ですか?
必要です。コマンドの形はほぼ同じで claude mcp add <名前> -- <コマンド> と codex mcp add <名前> -- <コマンド> ですが、書き込まれる設定が別なので 2 回打ちます(Codex 側は ~/.codex/config.toml)。clize install --mcp を使うと、この登録を 1 コマンドで両方に対して行います。
設定が片方だけ古くなるのを防ぐには?
更新を 1 コマンドにまとめるのが確実です。clize update で両方のディレクトリの skill が同じ版に揃い、clize doctor が CLI の版と配置済み skill の版のずれを検出します。同じ名前で中身の違う手順書が 2 つある状態は、どちらのエージェントがどちらを読んだか動かすまで分からないため、いちばん避けたい形です。
clize の CLI は日本語で表示されますか?
いいえ。2026 年 9 月時点で、出力とヘルプの表示は英語のみです(内部の辞書は英語と中国語だけで、日本語の辞書はありません)。エージェントとの会話は日本語のままで問題ありませんが、CLI が返すメッセージは英語で読むことになります。
Clize は Claude Code や Codex の代わりになりますか?
なりません。役割が別です。Claude Code と Codex はコードを書く側で、Clize はそのエージェントがサンドボックスの外に手を伸ばすための層 ― 自分のメールアドレス、ドメインの取得、静的サイトの公開、決済 ― を提供します。モデルの API キーは不要で、ホスティングは静的サイトのみです。
二重ぶんを、1 回に戻す。
Claude Code と Codex の両方に同じ版の skill を書き込み、必要なら MCP の登録までまとめて行います。そのうえで、エージェントに自分のメールアドレス・ドメイン・公開の手段を渡します。
$ npm i -g @clize/clize && clize login $ clize install $ clize claim mystudio --email $ clize deploy ./site --domain mystudio.clize.app[ Clize とは → ]