CodexとClaude Codeを同じリポジトリで併用する前に決めること

3行まとめ

指示

共通ルールとツール固有の補足を分けます。

権限

read-onlyから始め、編集や外部toolを段階的に広げます。

作業場所

worktree、ブランチ、scope指定で差分を分離します。

レビュー

実装役、レビュー役、人間承認の順番を固定します。

併用の焦点は、どちらが賢いかではなく、どこで責任と権限を分けるかです。

• CodexとClaude Codeを同じリポジトリで使うなら、最初に決めるのは「どちらが賢いか」ではなく、指示ファイル、権限、作業場所、レビュー順です。
• 共通ルールはAGENTS.md、Claude固有の補足はCLAUDE.md、実行境界はCodexのpermission profileやClaude Codeのsettingsへ分けます。
• 併用の初期値は、片方が実装、片方がレビュー、MCPや外部toolはread-onlyから、コストと利用上限は作業ログで追う形が安全です。

この記事は、2026年6月1日時点でOpenAI Codex公式docs、OpenAI Help Center、Anthropic Claude Code公式docs、Anthropic Help Centerを確認して書いています。X/Twitterの追跡アカウントは今回の実行環境では公開ページから72時間内の確実な投稿確認ができなかったため、需要シグナルとしても本文根拠には使っていません。

この記事でわかること

指示ファイル

`AGENTS.md`と`CLAUDE.md`の役割を分けられます。

実行境界

Codex permissionsとClaude Code settingsを分けて見られます。

作業分担

調査、実装、レビューを同じagentに寄せすぎない形にできます。

上限

MCP、外部tool、使用量、停止条件を決められます。

読み終えた時点で、併用するか、片方に寄せるかを判断しやすくします。

• CodexとClaude Codeを同じリポジトリで併用する時の役割分担
• AGENTS.mdとCLAUDE.mdを重複させない置き方
• Codex permission profileとClaude Code settingsの分け方
• worktree、ブランチ、複数セッションで作業を分離する考え方
• 実装役、レビュー役、人間承認の順番
• MCPや外部toolをread-onlyから始める理由
• コスト、利用上限、データ利用で確認すること
• 併用しないほうがよい失敗条件

AIコーディングエージェントを増やすと、できることは増えます。ただし、同じリポジトリに複数のエージェントを入れると、指示の衝突、二重編集、未検証の完了報告、権限の広げすぎも起きやすくなります。

この記事では、CodexとClaude Codeを競わせる記事にはしません。主題は「同じチームで両方を使うなら、どこを先に決めるか」です。Codex単体の設定はCodex設定を増やす前に決めることで、チーム向けの指示ファイルはチーム向けAGENTS.mdテンプレートで扱っています。ここでは併用時の境界に絞ります。

前提知識

1. 1プロジェクト文脈

   `AGENTS.md`や`CLAUDE.md`で規約、テスト、報告形式を伝えます。

2. 2実行制御

   permission profile、sandbox、settings、MCP scopeで操作範囲を制御します。

3. 3作業ログ

   実行したこと、未実行、リスク、人間承認を残します。

4. 4運用判断

   性能比較ではなく、役割、権限、レビュー順で設計します。

禁止事項を文書に書くだけでは安全境界にならないため、実行側の制御と合わせて考えます。

CodexとClaude Codeは、どちらもコードベースを読んで、計画し、編集し、テストやレビューを補助できます。だからこそ、同じリポジトリで両方を使う時は「どちらにも全部任せる」より、役割を分けたほうが運用しやすくなります。

指示ファイルと実行境界は別物

根拠

AGENTS.mdやCLAUDE.mdは、エージェントへプロジェクト文脈を伝えるための自然言語の指示です。コーディング規約、テスト手順、レビュー観点、禁止したい作業、報告形式を書く場所として有効です。

一方で、外部通信、ファイル書き込み、秘密情報へのアクセス、MCP server、shell commandの許可は、自然言語の注意書きだけに寄せるべきではありません。Codexではpermission profileやsandbox、Claude Codeではsettings.jsonのpermissions.allow、ask、deny、managed settingsなど、実行時の制御に寄せます。

併用は性能比較ではなく運用設計

同じタスクをCodexとClaude Codeに投げて、速かったほうを採用するだけでは、チーム運用の判断材料として薄いです。実務では、次の観点が効きます。

観点	決めること
指示	共通ルールとツール固有ルールをどこに置くか
権限	read-only、編集、外部通信、MCPをどう段階化するか
作業場所	local、worktree、別ブランチ、別セッションをどう使うか
レビュー	片方が作った差分を誰がどう確認するか
コスト	長時間タスク、複数セッション、subagentの上限をどう見るか
停止条件	未検証、権限不足、衝突、利用上限到達時にどう止めるか

結果: 併用するなら役割を三つに分ける

項目	内容	見方
調査・計画		read-onlyで既存仕様、差分範囲、リスクを確認します。
実装・差分作成		限定権限で対象pathだけを変更します。
レビュー・統合		もう片方のagentと人間がdiff、テスト、未検証を確認します。
片方だけ		小さな修正や緊急対応では、調整コストを増やさない選択もあります。

併用は、複数視点に分けられる作業で効果が出ます。

最初の結論は、三つの役割へ分けることです。

役割	主な担当	理由
調査・計画	Claude CodeまたはCodexのread-only thread	書き込み前に範囲とリスクを見る
実装・差分作成	CodexまたはClaude Codeの限定権限session	変更範囲を絞って作る
レビュー・統合	もう片方のagent + 人間	自分の変更を自分で承認しない

Codexは公式docsで、アプリ内のparallel thread、worktree、Git diff、commit、PR作成、integrated terminalなどを扱えます。Codex appのworktreeは、通常のlocal checkoutを邪魔せずに背景作業を進める用途に向いています。

Claude Codeは、CLAUDE.mdによるプロジェクト記憶、settingsによる権限、subagentのtool制限、plan mode時の調査、カスタムsubagentなどを持ちます。Claude Codeのsubagents docsでは、read-onlyのExploreやPlan subagent、tool allowlist/denylist、MCP serverのscopingが説明されています。

片方を実装役、片方をレビュー役にする

併用の初期パターンは、片方に実装させ、もう片方にレビューさせる形です。

例:

1. Claude Codeで計画を作る。
2. Codex worktreeで限定scopeの実装を進める。
3. Claude Codeにdiff、テスト結果、未検証項目をレビューさせる。
4. 人間が最終判断してmergeする。

逆でも構いません。大事なのは、実装役とレビュー役を同じagentに固定しないことです。AIの自己レビューは便利ですが、最終承認には使いすぎないほうがよいです。

片方だけでよいケース

併用しないほうがよい場合もあります。

片方だけでよい作業	理由
1ファイルの小さな修正	併用の調整コストが上回る
明確なテスト修正	同一agentで実装と検証まで進めやすい
機密性が高い調査	使うツールとログ面を最小化したほうがよい
緊急障害の一次対応	指揮系統を増やすと遅れる

併用は、作業が複数視点に分けられる時にだけ効きます。たとえば、依存関係更新のレビュー、既存仕様の調査、複数実装案の比較、セキュリティ観点の差分確認です。Claude Codeで依存関係更新を任せる時のゲートはClaude Codeで依存関係アップデートを任せる前にも参考になります。

AGENTS.mdとCLAUDE.mdをどう分けるか

1. 1`AGENTS.md`

   ツールを問わず守るscope、禁止操作、テスト、報告形式を書きます。

2. 2`CLAUDE.md`

   Claude Codeのplan mode、subagent、import方針などを薄く補足します。

3. 3settings

   allow、ask、denyなどの実行時制御を置きます。

4. 4衝突確認

   重複、矛盾、承認境界、テスト手順の欠落を最初に見ます。

共通ルールの正本を一つにすると、片方だけ古い指示が残りにくくなります。

同じリポジトリでCodexとClaude Codeを使う時、最初に荒れやすいのが指示ファイルです。AGENTS.md、CLAUDE.md、.claude/settings.json、.mcp.json、各種rulesが増えると、どれが正なのかわからなくなります。

おすすめは、共通ルールをAGENTS.mdへ寄せ、Claude固有の補足だけをCLAUDE.mdへ薄く置くことです。

共通ルールはAGENTS.mdへ寄せる

AGENTS.mdには、ツールを問わず守ってほしいルールを書きます。

# Repository instructions

Scope
- This repository contains a sample web app and API.
- Do not use live credentials or private customer data.

Allowed operations
- Read files in this repository.
- Edit files only for the requested task.
- Run lint, typecheck, and tests listed below.

Human approval required
- Dependency installation or upgrade.
- Database migration.
- External API write operation.
- Git push, deployment, or release operation.

Test commands
- npm run lint
- npm run typecheck
- npm test

Final report
- Summary
- Changed files
- Tests run
- Not run
- Risks

この内容は、Codexだけのためではありません。人間のレビュー、Claude Code、Cursor、Copilot、CI運用にも使える、リポジトリの作業契約です。

Claude固有の補足はCLAUDE.mdへ薄く書く

Claude Codeのmemory docsでは、CLAUDE.mdやCLAUDE.local.md、外部ファイルのimportが扱われています。CLAUDE.mdには、Claude Codeだけに必要な補足を書きます。たとえば、Claude Codeでよく使うslash command、subagent、plan modeの使い方、@AGENTS.md importの方針です。

# Claude Code notes

@AGENTS.md

Claude-specific workflow
- Start with plan mode for multi-file changes.
- Use read-only exploration before editing.
- Use a review-focused pass before final response.
- Do not treat this file as a security boundary.

AGENTS.mdとCLAUDE.mdに同じ禁止事項を長くコピーすると、片方だけ古くなります。共通ルールは一箇所へ、ツール固有の使い方だけ別ファイルへ、という分担にします。

衝突確認を最初のタスクにする

併用を始める初日は、実装ではなく指示の衝突確認から始めます。

Read AGENTS.md, CLAUDE.md, .claude/settings.json, and MCP config.
Report duplicated rules, conflicting permissions, unclear approval boundaries,
and missing test instructions. Do not edit files.

このタスクはread-onlyで十分です。いきなり修正させず、どの指示がどちらのツールに効くのかを確認します。

権限はread-onlyから段階的に広げる

項目	内容	見方
調査		read-onlyでdocs、diff、test構成を読みます。
限定実装		対象pathと実行コマンドを絞って変更します。
外部調査		domain allowlist、送信データ、secret除外を確認します。
危険操作		deploy、secret表示、破壊的git操作は人間承認にします。

セキュリティに関わる章では、広い権限を便利さだけで選ばず、必要性と戻し方を確認します。

併用時の初期値はread-onlyです。両方のagentに編集権限、外部通信、MCP、GitHub write、shell full accessを同時に渡すと、問題が起きた時に原因を切り分けにくくなります。

Codex側の初期値

Codex permissions docsでは、:read-only、:workspace、:danger-full-accessなどのprofileや、profile拡張、filesystem/networkの制御が説明されています。チーム導入では、最初から広い権限にしないほうがよいです。

フェーズ	Codexの扱い
調査	read-onlyでdocs、diff、test構成を読む
限定実装	workspace内の対象pathだけ変更する
外部調査	domain allowlistやweb searchの扱いを決める
危険操作	deploy、secret表示、破壊的git操作は人間承認

danger-full-accessのような広い権限は、便利だから使うものではなく、必要性と戻し方が説明できる時だけ使います。

Claude Code側の初期値

Claude Code settings docsでは、Managed、User、Project、Localのscope、permissions.allow、deny、settings priority、MCPやhooksなどが説明されています。プロジェクト共有の設定は.claude/settings.json、個人の実験は.claude/settings.local.jsonへ分けます。

例:

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run typecheck)",
      "Bash(npm test *)"
    ],
    "ask": [
      "Bash(npm install *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push *)"
    ]
  }
}

公開記事の例なので、実在の社内パスや秘密情報名は入れていません。自社で使う時は、秘密情報、ログ、顧客データ、課金操作、本番接続を必ず洗い出します。

自然言語の禁止事項を過信しない

注意点

AGENTS.mdに「本番DBを触らない」と書くのは大事です。しかし、それだけで安全境界になるわけではありません。接続情報を渡さない、MCP toolをread-onlyにする、DB writeを承認制にする、CI/CDの権限を分ける、ログを残す、という実装側の制御が必要です。

この考え方は、MCPや外部通信でも同じです。外部toolの許可範囲はCodexにインターネットアクセスを許可する前にで扱ったように、allowlist、送信データ、secret除外、承認者をセットで決めます。

worktreeとブランチで並列作業を分離する

1. 1作業scope

   触るファイル、触らないファイル、確認コマンドを決めます。

2. 2worktree

   Codex worktreeや専用ブランチで差分を分けます。

3. 3セッション

   Research、Plan、Implement、Reviewの役割を分けます。

4. 4統合

   diff、未追跡ファイル、テスト結果を確認してから合流します。

worktreeは差分を分ける助けになりますが、依存関係、build cache、未追跡ファイルも確認対象です。

Codex appのfeatures docsでは、Local、Worktree、Cloudのmodeや、worktreeで独立した作業を並べる使い方が説明されています。Worktrees docsでは、CodexがGit worktreeを作り、local checkoutと背景作業を分けられること、handoffでLocalとWorktreeを移動できることも説明されています。

併用時は、同じcheckoutで二つのagentに編集させないほうがよいです。

Codex worktreeを使う場面

Codex worktreeは、次のような作業に向いています。

作業	理由
既存テストの修正	local環境を邪魔しにくい
小さなfeature追加	diffを分離できる
複数案の比較	案ごとにworktreeを分けられる
背景調査から差分作成	foregroundの作業を止めにくい

ただし、worktreeは万能ではありません。依存関係、build cache、dev server、未追跡ファイル、.gitignore対象ファイル、同じブランチのcheckout制限は注意点です。Codex docsでも、同じbranchを複数worktreeでcheckoutできないGit上の制限が説明されています。

Claude Codeの複数セッションを使う場面

Claude Codeを複数セッションで使う場合も、役割を分けます。

セッション	権限	役割
Research	read-only	仕様、既存実装、テスト構成を調べる
Plan	read-only	実装計画とリスクを出す
Implement	scoped edit	指定pathだけ変更する
Review	read-only	diff、テスト、未検証を確認する

Claude Codeのsubagentsでは、toolを制限したread-only agentや、特定MCP serverをsubagentにだけ持たせる構成ができます。便利ですが、最初から複雑なsubagent構成にしないほうがよいです。まずは人間が見える単位で、調査、実装、レビューを分けます。

レビュー順を固定する

1. 1差分作成

   実装役が限定scopeで変更します。

2. 2実行報告

   Tests、Not run、Risksを残します。

3. 3第二レビュー

   レビュー役がbug、security、scope、test不足を見ます。

4. 4人間判断

   採用、修正、保留、追加検証を決めます。

Not runを消さないことが、併用時のレビュー品質を支えます。

AIエージェントを併用する最大の利点は、片方が作った差分をもう片方に違う観点で見せられることです。ただし、レビュー順を決めないと「どちらもそれっぽく完了したが、誰も責任を持っていない」状態になります。

実装役とレビュー役を分ける

おすすめのレビュー順は次です。

1. 実装役が差分を作る。
2. 実装役が実行したテストと未実行を報告する。
3. レビュー役がdiffを読む。
4. レビュー役がbug、security、scope、test不足を指摘する。
5. 人間が採用、修正、保留を決める。

レビュー役には、次の入力を渡します。

Review this diff as a second agent.
Focus on bugs, security, scope creep, missing tests, and unclear assumptions.
Do not rewrite the implementation unless explicitly asked.
Return findings with severity, evidence, and suggested fix.

レビュー役が勝手に全面修正を始めると、差分の責任が混ざります。まずはfindingを出すだけにします。

最終報告の型を固定する

どちらのagentにも、最終報告の型を揃えます。

Summary:
- ...

Changed:
- ...

Tests:
- ...

Not run:
- ...

Risks:
- ...

Needs human approval:
- ...

この型があると、人間レビューで「実行したこと」と「実行していないこと」を分けて読めます。AIエージェントの併用で一番危ないのは、未検証が自然に消えることです。Not runを消さない運用にします。

実装前レビューにも使う

大きめの変更では、実装後だけでなく実装前にも別agentを使います。たとえば、Codexに実装案を出させ、Claude Codeに「この計画のリスクだけをレビューして」と依頼します。実装前レビューの考え方はCodexに実装前レビューを頼むでも扱っています。

MCPと外部toolは片方ずつ開放する

項目	内容	見方
GitHub		issue、PR、diff readから始め、commentやbranch作成は承認対象にします。
Browser		公開ページ確認から始め、ログイン状態での変更操作は分けます。
DB		schemaやread-only sampleから始め、writeやmigrationは承認対象にします。
Internal API		sandbox readから始め、本番writeを渡さない設計にします。

外部toolは、接続先、認証scope、ログ、secret除外、人間承認をセットで確認します。

CodexとClaude Codeの両方にMCP、GitHub、browser、DB、社内APIを渡すと、便利な一方で、問題が起きた時に「どのagentが何を見たか」「どのtoolが外部へ送ったか」を追いにくくなります。

read-only toolから始める

初期段階では、MCPや外部toolをread-onlyにします。

tool種別	初期権限	承認が必要な操作
GitHub	issue/PR/diff read	comment、label、branch、PR作成
Browser	公開ページ確認	ログイン状態での変更操作
DB	schema/read-only sample	write、migration、export
Cloud	billing/config read	create/update/delete
Internal API	sandbox read	本番write

Claude Code subagents docsでは、subagentごとにMCP serverをscopeできることが説明されています。これは便利ですが、tool descriptionsや認証scopeを増やすほど、レビューすべき面も増えます。最初は一つのagent、一つのread-only toolから始めます。

認証scopeとログを残す

確認項目

外部toolを渡す前に、次を確認します。

• 認証情報は誰の権限か
• read/writeのscopeは何か
• 本番とsandboxは分かれているか
• tool実行ログはどこに残るか
• secretや顧客データがpromptに入らないか
• 失敗時に自動リトライや二重実行が起きないか
• 人間承認が必要な操作は何か

MCPそのものの概念やTools/Resources/Promptsの権限設計は、公開済みのMCPとは何かとMCP仕様・SDK更新時の実務影響チェックも合わせて読むと整理しやすいです。

セキュリティ・コスト注意

項目	内容	見方
データ利用		プラン、契約、data controls、保持期間を公式情報で確認します。
使用量		長いcontext、長時間タスク、複数agent、subagentで増えます。
監査ログ		依頼文、権限、外部tool、コマンド、差分、未検証を残します。
人間承認		課金、本番、secret、deploy、破壊的操作の責任者を決めます。

料金、利用上限、データ利用は変わるため、導入前にOpenAIとAnthropicの公式ページを見直します。

併用時のセキュリティとコストは、単体利用より見えにくくなります。二つのagentがそれぞれ長いcontextを持ち、subagentやMCPを使い、別々のログを残すためです。

データ利用と保持はプランで変わる

OpenAI Help CenterのCodex記事では、Codexは複数のChatGPT planに含まれ、usage limitsはplanやtaskの複雑さで変わると説明されています。また、Business、Enterprise、Eduでは既定で入力や出力をモデル改善に使わない一方、Pro/Plusではdata controlsを確認する必要があるとされています。

AnthropicのClaude Code data usage docsでは、Free/Pro/Maxのconsumer userと、Team/Enterprise/APIなどのcommercial userでデータ利用の扱いが分かれています。商用条件では、顧客が選択した場合を除き、Claude Codeに送信されたコードやpromptを生成モデルの訓練に使わないと説明されています。保持期間やtelemetryの扱いも確認対象です。

ここは古くなりやすいので、導入前に必ず公式ページを見直します。特に、個人プランで社内コードを扱う運用は、会社の規程、契約、データ分類と照合してください。

利用上限は複数agentで早く減る

CodexもClaude Codeも、長いコードベース、長時間タスク、大きなcontext、複数セッションで使用量が増えます。Anthropic Help Centerでは、usage limitsはconversation length、features、modelなどに影響され、Claude Codeを含む利用が同じusage limitに数えられると説明されています。OpenAI Help Centerでも、Codex usageはagentic usage limitに数えられ、coding taskの大きさや複雑さで消費が変わると説明されています。

評価基準

併用時は、次の上限を決めます。

上限	例
1タスクのagent数	実装1、レビュー1まで
長時間作業	30分ごとに進捗とNot runを確認
subagent	read-only調査だけから開始
MCP	1種類ずつ開放
再試行	同じ失敗を2回繰り返したら人間へ戻す
コスト	週次でusage画面や請求を確認

監査ログと人間承認を残す

法人やチームで使うなら、次を残します。

• 依頼文
• どのagentを使ったか
• どの権限profile/settingsだったか
• どの外部toolを使ったか
• 実行したコマンド
• 作成した差分
• 未検証項目
• 人間が承認した操作

「AIがやりました」だけではレビューにも監査にも使えません。作業ログの粒度を揃えることが、併用の最低条件です。

失敗点とハマりどころ

指示の重複

複数ファイルに少しずつ違うルールが残ります。

二重編集

同じcheckoutや同じファイルで差分の意図が混ざります。

未検証の完了

Not runが消え、テスト不足のままmergeされます。

MCP過多

外部toolと認証scopeが増え、事故時の切り分けが難しくなります。

小さな変更は片方で終わらせ、大きい変更やレビューが重い変更だけ併用します。

併用の失敗は、モデルの能力不足より、運用の曖昧さから起きることが多いです。

指示ファイルが重複する

AGENTS.md、CLAUDE.md、.claude/settings.json、個人メモ、古いREADMEに同じルールが少しずつ違う形で書かれると、agentごとに違う判断をします。

対策は、共通ルールの正本を一つにすることです。Claude固有のファイルから共通ルールを参照し、コピーを減らします。

二つのagentが同じファイルを編集する

同じcheckoutで二つのagentが同じファイルを触ると、差分の意図が混ざります。worktree、ブランチ、scope指定で分けます。

悪い例:

Codex: src/components/Checkout.tsxを修正
Claude Code: 同じファイルをレビューしながら修正
Human: どちらの変更が必要だったか追えない

よい例:

Codex: worktreeで実装
Claude Code: diffだけをread-onlyレビュー
Human: findingを見て修正方針を決める

両方が未検証のまま完了する

片方が「テストは未実行」と書き、もう片方もそれを見落とすと、未検証のままmergeされます。Not runは必ず最終報告に残し、人間レビューで消さないようにします。

MCP権限を広げすぎる

MCP serverを増やすと、agentが見られるtool説明、接続先、認証scopeも増えます。最初からGitHub write、browser操作、DB、社内APIを全部渡すと、事故時の切り分けが難しくなります。

併用そのものが目的になる

二つのagentを使うこと自体が目的になると、単純な修正にも調整が増えます。小さな変更は片方で終わらせ、大きい変更やレビューが重い変更だけ併用します。

実務で使うなら

1. 1日目

   指示ファイルとsettingsをread-onlyで棚卸しします。

2. 2日目

   `AGENTS.md`と`CLAUDE.md`を整理します。

3. 3-5日目

   read-only調査、小さな実装、第二レビューを試します。

4. 6-7日目

   MCP/toolを一つだけ試し、継続、縮小、停止を判断します。

基礎ルールがない状態でagentだけ増やすと、作業速度よりレビュー負荷が増えます。

最初の1週間は、派手な自動化ではなく、作業ログと境界線を作る期間にします。

1週間パイロット

日	やること	完了条件
1日目	指示ファイルとsettingsをread-only棚卸し	重複、衝突、未定義を一覧化
2日目	AGENTS.mdとCLAUDE.mdを整理	共通ルールと固有補足を分離
3日目	read-only調査タスクを両方で実施	結果の差と根拠を比較
4日目	小さな実装を片方に任せる	diffとtest結果を保存
5日目	もう片方でレビュー	finding、Not run、Riskを記録
6日目	MCP/toolを一つだけ試す	read-onlyでログとscopeを確認
7日目	継続/縮小/停止を判断	失敗条件と上限を更新

Issueテンプレート

併用時の依頼は、Issue形式にします。

Goal

Scope
- Allowed files:
- Do not touch:

Agent roles
- Implementer:
- Reviewer:

Permissions
- File access:
- Network:
- MCP:

Commands
- Required:
- Optional:

Human approval required

Output format
- Summary
- Changed files
- Tests
- Not run
- Risks

このテンプレートがあると、CodexにもClaude Codeにも同じ前提を渡せます。AI Coding Benchmark Kitのように同一条件で測る場合は、AI Coding Benchmark Kitの作り方の評価軸へつなげるとよいです。

導入しないほうがよい条件

停止条件

次の条件に当てはまるなら、併用は後回しにします。

• AGENTS.mdやCLAUDE.mdの正本がない
• テストコマンドが決まっていない
• secretや本番データの扱いが曖昧
• Git branch protectionやCI required checksがない
• 外部toolのログが残らない
• 人間承認の責任者がいない
• 使用量や請求を誰も見ていない

併用は、基礎ルールがあるチームで効果が出ます。基礎がない状態でagentだけ増やすと、作業速度よりレビュー負荷が増えます。

FAQ

実装役

固定せず、作業環境、権限、レビューしやすさで決めます。

`AGENTS.md`だけ

共通ルールは寄せられますが、Claude固有のmemoryやsettingsは補足します。

subagent

最初は増やしすぎず、read-only調査のような独立作業から始めます。

コスト

プラン名だけでなく、agent数、時間、context、再試行を見ます。

迷った時は、誰が何を実行し、誰が最終判断するかを基準にします。

CodexとClaude Codeのどちらを実装役にすべきですか

固定しなくてよいです。Codex worktreeやGit差分管理が合う作業ではCodexを実装役にし、Claude Codeのplan modeやsubagent調査が合う作業ではClaude Codeを調査・レビュー役にする、という始め方が扱いやすいです。チームの環境、権限、料金、レビューしやすさで決めます。

AGENTS.mdだけでClaude Codeも運用できますか

共通ルールはAGENTS.mdへ寄せられますが、Claude Code固有のmemory、settings、subagent、MCP scopeはCLAUDE.mdや.claude/settings.jsonで補うほうが整理しやすいです。CLAUDE.mdから@AGENTS.mdをimportする場合も、承認や読み込み状態を確認します。

Claude Code subagentsとCodex Subagentsを両方使ってよいですか

最初から両方のsubagentを増やすのは避けます。まずはメインagent同士で、調査、実装、レビューの型を固定します。その後、read-only調査のような独立した作業だけsubagent化します。Codex側の分担設計はCodex Subagentsで分担する前に決めることも参考になります。

MCPはCodexとClaude Codeの両方に同じものを渡すべきですか

初期段階では片方だけに渡します。両方に同じwrite権限を渡すと、どちらが何を実行したかを追いにくくなります。まずread-only、次に限定write、最後に人間承認付きwriteという順番にします。

コストはどう見ればよいですか

プラン名だけで判断しません。長時間タスク、巨大なcontext、複数セッション、subagent、MCP、再試行で使用量は増えます。週次でusage画面や請求を確認し、1タスクあたりのagent数、実行時間、再試行回数を決めます。料金や上限は変わるため、OpenAIとAnthropicの公式ページを確認してください。

AIコーディングエージェントの権限設計やチーム導入の更新は、ニュースレターでも追えるようにしています。法人向けに、AGENTS.md/CLAUDE.md整理、MCP read-only設計、評価タスク作成、権限棚卸しを相談したい場合は、お問い合わせから連絡できます。

---

次に読むなら

参照した主な情報源

• OpenAI Codex GitHub README: https://github.com/openai/codex
• Codex app features: https://developers.openai.com/codex/app/features
• Codex worktrees: https://developers.openai.com/codex/app/worktrees
• Codex permissions: https://developers.openai.com/codex/permissions
• Codex AGENTS.md guide: https://developers.openai.com/codex/guides/agents-md
• Using Codex with your ChatGPT plan: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan
• Claude Code memory docs: https://code.claude.com/docs/en/memory
• Claude Code settings docs: https://code.claude.com/docs/ja/settings
• Claude Code subagents docs: https://code.claude.com/docs/en/sub-agents
• Claude Code data usage: https://docs.anthropic.com/ja/docs/claude-code/data-usage
• Understanding usage and length limits: https://support.anthropic.com/en/articles/11647753-understanding-usage-and-length-limits

更新履歴

1. 2026年6月1日

   OpenAI Codex公式docs、OpenAI Help Center、Anthropic Claude Code公式docs、Anthropic Help Centerを確認しました。

2. 2026年6月1日

   X/Twitterの追跡アカウントは、本文根拠に使わない方針にしました。

3. 未実施

   実リポジトリ上での同時実行ベンチマークは行っていません。

導入判断では、公開日時点の設計チェックリストとして扱います。

• 2026年6月1日: OpenAI Codex公式docs、OpenAI Help Center、Anthropic Claude Code公式docs、Anthropic Help Centerを確認して初版を作成しました。
• 2026年6月1日: X/Twitterの追跡アカウント公開ページから72時間内の確実な投稿確認はできなかったため、本文では需要シグナルとしても引用しない方針にしました。
• この記事では、実リポジトリ上でCodexとClaude Codeを同時実行したベンチマークは行っていません。導入判断のための設計チェックリストとして扱ってください。