3行まとめ
実装、調査、レビュー、リリース前確認の担当を分ける。
編集、Git、MCP、外部APIの許可範囲を設定で分ける。
必須ルールと個人用メモリを混ぜず、置き場所を分ける。
費用、利用量、停止条件を事前に決めてログに残す。
併用の目的は、強いツールを増やすことではなく、責任の所在を見えるようにすることです。
- Claude CodeとCodexの併用は、どちらが強いかを決める話ではなく、実装、調査、レビュー、MCP、メモリ、費用の境界を先に決める運用設計です。
- 2026-06-14時点の公式Docsでは、CodexはCLI、IDE、cloud、MCP、sandbox/approval、pricingを分けて確認する必要があり、Claude Codeはsettings、memory、MCP、hooks、usageを分けて見る必要があります。
- 最初の1週間は、片方を編集役、もう片方をread-onlyレビュー役に寄せ、MCPは片方ずつ開放し、利用上限と停止条件をログに残すのが現実的です。
本稿ではX上で見えたCodexとClaude Codeの併用、費用感、MCP、memoryへの関心を需要シグナルとして扱います。ただし、投稿本文は事実の根拠にしません。機能、料金、利用上限、権限モデルは、OpenAIとAnthropicの公式Docs、Help Center、公式pricingページで確認した範囲に限定して書きます。
この記事でわかること
同じリポジトリで両方を使うか、片方から始めるかを決める。
計画、調査、実装、レビュー、確認のどこを任せるかを決める。
接続先ごとにread-only、限定write、承認付きwriteを分ける。
長い会話、外部tool、再試行、二重レビューの消費を見積もる。
比較表だけでなく、実際にチームで守れる運用ルールまで落とし込みます。
この記事で作れるようにするのは、チーム向けの併用ルールです。
- CodexとClaude Codeを同じリポジトリで使うべきか、片方だけで始めるべきか。
- 計画、調査、実装、レビュー、リリース前確認をどう分担するか。
AGENTS.md、CLAUDE.md、Claude Code memory、Codex側の設定やメモリをどう分けるか。- MCPサーバーをどの順序で開放し、どこでread-onlyに止めるか。
- 利用上限、従量課金、長時間タスク、並列セッションをどうチームの停止条件に落とすか。
すでにAIコーディングの作業ループ自体を整理したい場合は、公開済みのAI Coding Loop Engineering入門から読むと、Plan、Implement、Test、Reviewのどこにエージェントを入れるかが見えやすくなります。この記事では、その次の段階として、Claude CodeとCodexを同じチームに置くときの境界に絞ります。
前提知識
- 1目的を固定する
併用で何を速くし、何を安全にしたいのかを一文にする。
- 2担当を分ける
編集役、調査役、レビュー役、人間の最終責任を分ける。
- 3設定で縛る
自然言語のお願いだけでなく、sandbox、permissions、hooksで制御する。
- 4記録を残す
どちらが何を実行し、どの判断を採用したかを追えるようにする。
指示ファイルやmemoryは便利ですが、強制設定そのものではありません。
CodexとClaude Codeは、どちらもコードを読み、編集し、コマンドを使い、外部ツールとつながれるAIコーディングエージェントです。似ているからこそ、両方を入れた瞬間に「誰が編集したのか」「どちらがレビューしたのか」「どのMCPがどちらに開いているのか」が曖昧になりやすい。
2026-06-14時点で確認したOpenAIのCodex docsでは、CodexはCLIでローカルの選択ディレクトリを扱い、IDE extensionやCodex cloudにも作業面があります。Codex cloudはバックグラウンドや並列のタスクに向きますが、ローカルCLIと同じ権限設計で済むわけではありません。認証もChatGPTアカウントとAPI keyで扱いが変わり、API keyの場合は標準API pricingに従い、一部のcloudやworkspace依存機能は制限される可能性があります。
Claude Code側も、terminal、IDE、desktop、browser、web、Agent SDK、GitHub Actionsなどの面があります。Anthropicのsecurity docsでは、Claude Codeは初期状態でread-only寄りのpermission architectureを取り、編集、テスト実行、Bashコマンドなど追加操作では明示的な許可を求める設計です。settingsにはManaged、User、Project、Localのスコープがあり、チーム共有の設定と個人設定を分けられます。
併用は性能比較ではなく責任分担
チームで困るのは、モデルのベンチマーク差よりも、責任の重なりです。片方が実装し、もう片方がレビューするなら、レビュー役は変更権限を持つべきか。両方にGitHub MCPを渡すなら、同じIssueを二重に更新しないか。両方にmemoryを持たせるなら、古い前提が最新のチームルールより強く見えないか。
この境界を決めずに併用すると、速くなるどころか、レビュー対象、承認者、費用、ログ確認がばらけます。併用の目的は、最初に一文で固定してください。
評価基準
1週間後に見るのは、PR完了時間、レビュー指摘の具体性、未検証報告の数、上限到達の頻度です。モデルの印象ではなく、チームの成果物と運用ログで判断します。
例としては、次のように書けます。
このリポジトリでは、Codexを実装と差分整理に使い、Claude Codeを計画レビューとread-only調査に使う。
MCPのwrite権限は最初の1週間はどちらにも渡さない。指示ファイルと強制設定は別物
AGENTS.mdやCLAUDE.mdに「本番DBを書き換えない」と書くのは大切です。ただ、それだけで技術的な実行境界になるわけではありません。
Claude Code memory docsは、CLAUDE.mdとauto memoryを文脈として扱い、強制設定ではないと説明しています。何かを確実に止めたい場合は、PreToolUse hookなど別の制御を使う必要があります。Codex側も、自然言語の指示とsandbox、permissions、approval policyは分けて見るべきです。
チームルールは、まずレビュー可能なリポジトリ内ファイルへ置きます。個人の好みや繰り返す作業手順はmemory候補にできます。外部API、MCP、Git操作、秘密情報の扱いは、設定と承認フローで止める。ここを混ぜないことが、併用の第一歩です。
結果：最初は「片方が編集、片方がread-onlyレビュー」に閉じる
両方へ同時に編集権限とwrite権限を渡す前に、狭い運用でログを見ます。
最初から両方に編集権限、Git操作、MCP write権限、長時間タスクを渡す必要はありません。むしろ、併用の初期値は狭いほうがいいです。
おすすめは、1週間だけ次のどちらかに寄せることです。
| パターン | Codex | Claude Code | 人間の責任 |
|---|---|---|---|
| 実装をCodexへ寄せる | 実装、差分整理、テスト実行案、cloud task | read-only調査、設計レビュー、PR観点整理 | 最終レビュー、merge判断、権限拡張 |
| 実装をClaude Codeへ寄せる | read-only差分レビュー、追加調査、別観点の検証 | 計画、実装、hooks付き検証 | 最終レビュー、未実行テスト確認、費用管理 |
どちらが正解というより、最初に一方へ強い権限を寄せるのがポイントです。強い権限を持たない側は、レビュー、調査、質問、リスク洗い出しに限定します。これだけで、二重編集、MCP操作の重複、料金消費の見えにくさをかなり減らせます。
Codexを実装、差分整理、Cloudタスクへ寄せる場合
Codex CLIはローカルのterminalで動くコーディングエージェントとして、選択したディレクトリのコードを読み、変更し、コマンドを実行できます。Codex cloudは、OpenAI docs上ではバックグラウンドや並列タスクに使える面として説明されています。長めの修正、複数ファイルの変更、差分整理を任せたいなら、Codexを編集役に寄せる設計は自然です。
このときの初期ルールは、次のようにします。
- Codexには対象worktreeまたは対象ディレクトリを限定する。
- network accessやMCP writeは最初から開かない。
approval_policy、sandbox、permission profileのどれで止めるかを明記する。- Claude Codeには同じファイルを編集させず、PR観点、テスト観点、未確認事項の洗い出しに寄せる。
Codexのsecurity docsでは、デフォルトでnetwork accessがオフで、ローカルではOS-enforced sandboxとapproval policyを組み合わせると説明されています。だからこそ、併用時は「Codexがどこまで自動で進めてよいか」を設定で固定してからClaude Codeへレビューを依頼します。
Claude Codeを計画、調査、レビュー、hooksへ寄せる場合
Claude Codeは、settings、memory、MCP、hooksの設計面が厚いツールです。hooks guideでは、ツール利用前後のチェック、編集後の整形、保護ファイルへの操作ブロックなどを運用に組み込めます。調査、レビュー、計画、作業前後のゲートに寄せると、併用の価値が出やすい。
ただし、レビュー役にしたClaude Codeへ同じ強い編集権限を渡すと、役割がすぐ混ざります。実装した会話の中で「自分の変更をレビューして」と頼むだけでは、独立レビューになりません。別セッション、別観点、read-only制限、レビュー用の出力フォーマットを用意します。
レビュー依頼は、次のような形に寄せます。
このPR差分をread-onlyで確認してください。
観点はセキュリティ、テスト不足、ロールバックしにくい変更の3つです。
修正は行わず、ファイル名、根拠、重大度、追加で人間が確認すべき点だけを返してください。片方だけで十分な作業を残す
併用の失敗は、すべてを二重化するところから始まります。小さな文言修正、既存パターンに沿う型修正、単純なテスト更新、ドキュメントの誤字修正まで両方に読ませる必要はありません。
併用を呼び出す条件を決めましょう。
- 3ファイル以上にまたがる変更。
- セキュリティ、課金、本番データ、認証認可へ触れる変更。
- 既存テストが失敗していて、原因調査と修正が分かれる変更。
- MCPや外部APIを使う変更。
- 人間レビュー前に別観点のチェックがほしい変更。
それ以外は片方で終わらせます。併用は常時オンの贅沢機能ではなく、リスクや複雑さが上がったときに使う作業設計です。
指示ファイルとメモリを混ぜない
Codex向けのリポジトリルール、権限境界、検証方針を置く。
Claude Code向けの作業方針、読み取り範囲、レビュー観点を置く。
許可、確認、禁止、hooksなど、実際に効かせたい制御を置く。
個人の好み、頻出文脈、補助メモを置き、チーム必須ルールは任せない。
同じルールを複数箇所で更新しないと整合しないなら、配置を見直す合図です。
CodexとClaude Codeを同じチームに入れると、まず増えるのが指示ファイルです。AGENTS.md、CLAUDE.md、.claude/settings.json、.mcp.json、Codexの設定、memory、skills、plugins。増えること自体は悪くありません。問題は、何をどこに置いたかをチームが説明できなくなることです。
公開済みのCodex Memoriesをチームで使う前にでも整理した通り、memoryは便利な補助記憶ですが、チームの必須ルールを任せる場所ではありません。併用時はこの線引きがさらに重要になります。
必須ルールはリポジトリ側へ置く
次の情報は、memoryではなくリポジトリ内のレビュー可能なファイルへ置きます。
- 必須テストコマンド。
- 変更前に読むべき設計資料。
- 禁止操作。
- 秘密情報、個人情報、顧客データの扱い。
- Git操作とPR作成ルール。
- MCPや外部APIの承認条件。
- 「Not run」を含む最終報告フォーマット。
CodexにもClaude Codeにも読ませたい共通ルールは、AGENTS.mdなど共通側へ寄せます。Claude Codeだけの設定、hooks、MCP scopeはClaude Code側へ置く。Codexのsandbox、approval、permissionsはCodex側で管理する。これを1枚の表にして、リポジトリに入れておくと運用が崩れにくいです。
メモリには個人の補助情報だけを置く
memoryに向くのは、漏れても事故になりにくく、毎回説明すると手間な情報です。
- よく使う開発サーバーの起動順。
- 個人のレビュー観点。
- そのリポジトリでよく詰まる軽い注意点。
- 何度も説明している作業の好み。
- ただし秘密ではなく、古くなっても破壊的な結果になりにくいもの。
逆に、APIキー、顧客名、社内未公開情報、管理者権限の手順、本番操作、法務やセキュリティ上の必須ルールはmemoryへ置きません。公式Docsにredactionや記憶の扱いが書かれていても、それは保存してよい理由ではなく追加の防御です。
AGENTS.mdとCLAUDE.mdの重複を減らす
同じ禁止事項をAGENTS.mdにもCLAUDE.mdにも書くと、最初は安心に見えます。半年後には片方だけ更新され、もう片方が古いまま残ります。
重複を減らすには、分類を決めます。
| 置き場所 | 置くもの | 置かないもの |
|---|---|---|
| 共通ルール | テスト、禁止操作、レビュー条件、報告形式 | ツール固有のUI操作 |
| Claude Code側 | hooks、settings scope、Claude固有のmemory方針 | Codexだけのsandbox設定 |
| Codex側 | permission profile、approval policy、Codex固有のMCP設定 | Claude Code hooks |
| 個人memory | 繰り返す個人の好み、軽い作業前提 | チーム必須ルール、秘密情報 |
チームで見るべき基準は単純です。同じルールを2箇所以上更新しないと整合しないなら、設計が重くなっています。
MCPは両方に一気に開放しない
- 未接続
まずは通常のファイル読み取りとローカル確認だけで作業する。
- read-only
GitHub、ドキュメント検索、Issue確認などを読み取り中心で試す。
- 限定write
対象リポジトリ、対象操作、対象時間を絞って書き込みを許可する。
- 承認付きwrite
外部API、DB、公開物、秘密情報に近い操作は人間承認を挟む。
- 停止
誤操作、ログ不足、費用急増、prompt injectionの兆候があれば戻す。
MCPは便利さと同時に攻撃面も広げるため、接続先ごとに担当ツールを決めます。
MCPは、AIエージェントへ外部ツールや文脈を渡すための強い接続です。GitHub、ブラウザ、DB、ドキュメント検索、Figma、社内APIなどへつなげば、できることは増えます。同時に、誤操作、権限肥大、prompt injection、ログ不足のリスクも増えます。
特に併用時は、同じMCPサーバーをCodexとClaude Codeの両方に入れる前に、どちらが何をするかを決めてください。
最初はread-onlyから始める
最初の1週間は、MCPの段階を次のように分けます。
| 段階 | 状態 | 進める条件 |
|---|---|---|
| 未接続 | MCPを入れない | まずローカルファイルと既存テストだけで試す |
| read-only | 読み取りだけ許可 | ログ、scope、参照範囲を確認できる |
| 限定write | Issueコメントなど限定された書き込み | 誤操作時の取り消し方がある |
| 承認付きwrite | PR作成や外部API操作 | 人間承認と監査ログがある |
| 停止 | MCPを外す | 失敗時、権限過多、費用超過、ログ不足 |
Codex docsではMCPがCLIとIDE extensionで使えると説明されています。Claude Code docsでもMCP installation scopeとしてLocal、Project、Userなどの範囲が示されています。つまり、どちらにもつなげられるからといって、両方へ同時に入れる必要はありません。
MCP Registryや外部サーバーの選定を先に整理したい場合は、MCP Registryからサーバーを選ぶ前にも合わせて確認してください。この記事では、サーバー選定そのものより、CodexとClaude Codeへどの順で開くかに絞ります。
開放条件
read-onlyからwriteへ進める条件は、認証scope、操作ログ、取り消し手順、承認者がそろっていることです。どれか1つでも説明できない場合は、MCPの権限を広げません。
接続先ごとに担当ツールを決める
MCPは「全部入り」にしないほうが運用しやすいです。
- GitHub IssuesとPR差分はCodexだけに渡す。
- ドキュメント検索はClaude Codeだけに渡す。
- DBはどちらにも渡さず、人間がread-only dumpやschemaだけを渡す。
- ブラウザ操作は片方だけにし、もう片方はスクリーンショットやログだけを読む。
このように接続先ごとに担当を固定すると、事故時の追跡が楽になります。同じMCPを両方で使う必要がある場合でも、認証scope、tool allowlist、ログ、承認者、停止手順を揃えてからにします。
tool poisoningと権限肥大を想定する
MCPの怖さは、外部データがエージェントの文脈に入るところにもあります。Issue本文、PRコメント、Webページ、社内ドキュメント、MCP toolの説明文には、意図しない指示が含まれる可能性があります。
防御側の記事で扱う範囲では、次の確認に留めます。
- 許可するtoolを最小化する。
delete、write、admin系のtoolは初期状態でdenyする。- 秘密情報や個人情報を出力しないルールを設定とレビューで確認する。
- MCPの呼び出しログを残す。
- 異常時にMCP serverや認証トークンを止める手順を持つ。
実在サービスへの攻撃手順や破壊的な操作手順は不要です。実務で必要なのは、何がつながっていて、誰が承認し、どこで止めるかを説明できる状態です。
権限と承認は自然言語ではなく設定で分ける
強い権限は片方へ寄せ、もう片方は確認役として残すと原因追跡がしやすくなります。
「危ないことはしないで」とエージェントに書くのは、最後の補助です。最初の防御ではありません。
併用時は、操作種別ごとに許可、確認、禁止、人間承認を分けます。
| 操作 | 初期方針 | 理由 |
|---|---|---|
| ファイル編集 | 編集役だけ許可 | 二重編集を避ける |
| network access | 原則オフ、必要時だけ承認 | 外部送信と依存取得を分ける |
| Git操作 | diffやstatusは許可、pushは人間承認 | 誤pushを防ぐ |
| MCP | read-onlyから | 認証済み外部接続として扱う |
| 外部API | 原則deny | 課金、データ変更、本番影響がある |
| 秘密情報 | 読み取りも制限 | memoryやログへの混入を避ける |
Codex側はsandbox、permissions、approvalを確認する
Codexは、sandboxとapprovalが別の制御です。sandboxは技術的な境界を決め、approval policyは境界を越えようとしたときに止めるかどうかを決めます。Codex permissions docsでは、local sandboxed command executionの境界としてpermission profilesを扱う説明もあります。
併用時は、Codexの設定を次の観点で確認します。
- どのディレクトリを触れるか。
- network accessを許すか。
- sandbox外のコマンドをどこで止めるか。
- MCP elicitationsやpermission requestをどう扱うか。
- API key認証の場合、ChatGPT plan creditではなくAPI pricingになることを理解しているか。
AGENTS.mdに「ネットワークを使わない」と書くだけでは足りません。sandbox、approval、permissions、レビューを合わせて境界にします。
Claude Code側はsettings、permissions、hooksを確認する
Claude Codeはsettingsのスコープが強い設計ポイントです。Managedは組織や端末に強く効く設定、Projectはリポジトリ共有、Localは個人の実験用というように、誰に効くかを分けられます。
Claude Code security docsでは、read-only permissionsを初期値として扱い、追加操作には明示的なpermissionを求める設計が説明されています。hooks guideでは、PreToolUseやPostToolUseで操作前後のゲートを作れます。公開済みのClaude Code Hooksをチームで使う前にでは、PreToolUse、PostToolUse、Stopをレビューゲートに使う考え方を整理しています。
ただし、hooksで何でも自動判断しようとしないでください。破壊的操作、外部API、本番に近いデータ、課金が絡む操作は、人間へ戻す条件を残します。
併用時は強い権限を片方に寄せる
両方に強い権限を渡すと、短期的には速く見えます。長期的には、原因調査が難しくなります。
例えば、CodexにもClaude CodeにもGitHub write MCPを渡し、どちらもPRコメントを書き、どちらもIssueを更新できる状態にしたとします。コメントが二重になったとき、どちらの判断で更新されたのか、ログはどこにあるのか、次回から何を止めるのかが曖昧になります。
最初は、強い権限を片方へ寄せます。もう片方はread-only、レビュー、計画、質問に留める。広げるときは、1操作ずつ増やしてください。
メモリとコンテキストは費用にも影響する
過去文脈が増えるほど、確認と要約の消費も増えやすい。
広い探索、複数ファイル確認、再読み込みが重なりやすい。
MCP、ブラウザ、GitHub、ドキュメント検索の呼び出しが増える。
並列作業は速さを出せる一方、重複調査とログ確認も増える。
失敗した実装、テスト、レビューのやり直しが消費を押し上げる。
品質確認は強くなるが、同じ差分を二度読むコストが出る。
料金、利用上限、提供条件は変わりやすいため、導入時点の公式情報で再確認します。
料金は、月額プランだけ見ても判断できません。AIコーディングエージェントでは、長い会話、大きいリポジトリ、外部tool、MCP、複数セッション、再試行、レビュー二重化が消費に効きます。
2026-06-14時点で、Codex pricing docsは、CodexがChatGPT Free、Go、Plus、Pro、Business、Edu、Enterpriseの各プランに含まれると説明しています。一方で、利用上限はモデル、作業の大きさ、ローカルかcloudか、credits、planで変わります。OpenAI HelpのCodex plan記事やrate cardも、usage limits、credits、workspace roleによる扱いを確認するページです。
Claude Code側は、costs docsでAPI token consumption、subscription plan pricing、/usage、チームでのcost trackingなどが説明されています。Help Centerでは、ClaudeとClaude Codeの利用がPro/Max planの同じusage limitsにかかると説明されています。
料金プラン名だけで判断しない
「どちらも月額プランで使えるから併用してよい」とは考えないほうがいいです。
見るべきなのは、チームの作業単位です。
- 1Issueあたり、何回エージェントに読ませるか。
- 1PRあたり、何回レビューを回すか。
- 長時間タスクを何本並列に走らせるか。
- cloud taskとlocal sessionをどう分けるか。
- MCPで大きなログやIssue一覧を何度読むか。
- 上限に近づいたとき、誰が止めるか。
CodexのFast modeやmodel選択、Claude Codeのsubagents、hooks、MCP、複数セッションは便利ですが、便利なものほど消費を増やしやすい。導入判断では、金額だけでなく上限到達時の仕事の止まり方を見ます。
確認する公式情報
導入前に確認するのは、月額料金だけではありません。planごとの利用上限、creditsや従量課金の扱い、API key認証時のbilling、workspace管理者が見られるusage、上限到達時の追加購入や停止の扱いを見ます。
併用で消費が増える場面を洗い出す
費用が増える典型例は、同じ情報を両方に読ませることです。
- 同じIssueをCodexとClaude Codeへ全文投入する。
- 同じCIログを両方で解析する。
- 実装後にCodexで自己レビューし、さらにClaude Codeでレビューし、またCodexへ修正させる。
- MCP経由で同じGitHubやドキュメントを何度も検索する。
- 長い会話を閉じず、古い文脈を抱えたまま次のIssueへ進む。
これらは、品質を上げる場合もあります。ただし、軽い作業まで毎回二重化すると、重要なPRに使う余力が減ります。併用対象は、リスクがある変更、複雑な変更、レビュー観点が分かれる変更に絞ります。
料金上限と停止条件を決める
チーム導入では、次のような停止条件を先に決めておきます。
| 条件 | 止めること | 継続してよいこと |
|---|---|---|
| 1日の上限に近い | 軽微な二重レビュー、長時間調査 | セキュリティ修正、リリース前確認 |
| MCPログが追えない | write MCP、外部API操作 | read-only調査 |
| 同じPRで3回以上再試行 | 自動修正ループ | 人間の設計レビュー |
| 未実行テストが多い | merge前の自動完了扱い | Not runの明記と人間判断 |
料金管理は個人の注意に任せないほうがいいです。週次で、上限到達、長時間タスク、MCP利用、レビュー回数を見ます。
1週間パイロットで併用を試す
- 1日目
権限、MCP、秘密情報、料金上限、停止条件を絞って始める。
- 2日目
小さなIssueで編集役とレビュー役の分担を試す。
- 3日目
差分の読みやすさ、テストの妥当性、未確認事項を同じ表で見る。
- 4日目
MCP、外部tool、再試行、レビュー二重化による消費を確認する。
- 5日目
継続、縮小、片方だけに戻す条件を決める。
机上の比較より、同じ評価表で1週間の差分を見たほうが判断しやすくなります。
導入判断は、机上の比較表だけでは決まりません。とはいえ、いきなり全リポジトリに広げるのも危険です。最初は1リポジトリ、1チーム、1週間で試します。
1日目：権限とMCPを絞る
初日は、ツールの機能を試す日ではなく、境界を固定する日です。
- 編集役を片方に決める。
- もう片方はread-onlyレビューにする。
- MCPは未接続またはread-onlyだけにする。
- 本番、課金、顧客データ、秘密情報に触れる作業を対象外にする。
- 最終報告フォーマットを固定する。
報告フォーマットには、最低限これを入れます。
Summary:
Tests:
Not run:
Risks:
Files changed:
Human checks:2日目から4日目：同じ評価表で見る
3日目あたりで、役割を入れ替えた小さなタスクも試します。最初にCodex実装、Claude Codeレビューで試したなら、逆も小さく見る。好みではなく、同じ評価表で比較します。
| 評価軸 | 見る内容 |
|---|---|
| 差分の読みやすさ | PRが人間にレビューしやすいか |
| テストの妥当性 | 必要なテストを走らせたか、未実行を明記したか |
| レビューの具体性 | ファイル、根拠、重大度があるか |
| 権限の逸脱 | 想定外のMCP、network、Git操作がないか |
| 上限消費 | 軽い作業に使いすぎていないか |
| 復旧しやすさ | 失敗時に戻せる差分か |
5日目：継続条件を決める
最終日に決めるのは、勝者ではありません。次の運用条件です。
- このリポジトリでは併用を続けるか。
- 編集役をどちらに寄せるか。
- read-only MCPを増やすか。
- write MCPはまだ開かないか。
- memoryに残してよい情報の基準を変えるか。
- 料金上限、長時間タスク、レビュー回数をどう制限するか。
レビューが浅い、上限消費が早い、MCPログが追えない、指示ファイルが肥大化した場合は、広げる前に戻します。併用をやめる判断も、正常な成果です。
戻す判断
パイロットの結果が曖昧なら、権限を増やさず最小構成へ戻します。編集役を1つに絞り、MCPを未接続またはread-onlyに戻し、memoryへ残す情報を再確認します。
よくある失敗と避け方
同じファイル編集や重複コメントが増えたら、片方をread-onlyレビューに戻す。
必須ルールはリポジトリ側と設定へ置き、memoryは補助に留める。
上限、通知、停止、翌日へ回す作業をチームで決める。
レビュー役は指摘と根拠に寄せ、修正する場合は役割を切り替える。
接続先ごとに担当ツールとwrite可否を決め、ログを残す。
誤操作、費用急増、権限不足、ログ不足の戻し先を決めておく。
失敗の多くはモデル性能ではなく、権限と責任の重なりから起きます。
両方に同じ強い権限を渡す
症状は、同じファイルを両方が編集する、同じPRに重複コメントが付く、どちらが外部APIを呼んだかわからなくなることです。原因は、強い権限を分担せずに配ったことです。
止め方は、片方を編集役、もう片方をread-onlyレビュー役に戻すこと。MCP write、Git push、外部API操作は、最初から両方へ開かない。
メモリにチームルールを任せる
必須ルールをmemoryに任せると、メンバーや端末で差が出ます。古いmemoryが残り、新しいルールと衝突することもあります。
止め方は、必須ルールをリポジトリ内のレビュー可能なファイルへ戻すことです。memoryには、漏れても事故になりにくい補助情報だけを置きます。
料金上限を個人任せにする
軽い作業まで両方に読ませると、上限やcreditsを早く使います。個人の感覚で「今日はまだ大丈夫」と判断すると、重要なPRで使いたいときに止まることがあります。
止め方は、1Issueあたりのエージェント利用回数、長時間タスク数、レビュー回数、MCP利用回数をチームで見ることです。
レビュー役が修正し始める
レビュー役に編集権限があると、指摘ではなく修正へ進みがちです。便利ですが、実装責任とレビュー責任が混ざります。
止め方は、レビュー依頼に「修正しない」「read-only」「ファイル名、根拠、重大度、確認事項だけ返す」と明記し、設定でも編集を止めることです。
実務で使うなら
- 1Issueに条件を書く
編集役、レビュー役、MCP、禁止操作、完了条件をIssueに入れる。
- 2PRに判断を残す
採用した提案、採用しなかった提案、未確認事項を短く残す。
- 3人間レビューを残す
秘密情報、法務、料金、リリース判断は人間が責任を持つ。
- 4導入しないケースを決める
権限境界が作れない作業やログが残らない作業では広げない。
実務では、便利さより先に責任の記録が残る運用へ寄せます。
実務導入では、最初に次の5つを決めてから使います。
- どちらが編集役か。
- どちらがレビュー役か。
- MCPをどちらに、どのscopeで開くか。
- memoryに残してよい情報と残さない情報は何か。
- 料金上限、長時間タスク、停止条件を誰が見るか。
Issueテンプレートに併用条件を入れる
IssueテンプレートやPRテンプレートに、AI併用欄を追加すると運用しやすくなります。
AI agent usage
- Editing agent:
- Review agent:
- MCP used:
- Network access:
- Tests run:
- Not run:
- Human approval required:
- Cost/usage note:これを残すだけで、人間レビューの質が上がります。「AIがやった」ではなく、「どのagentが、どの権限で、何を確認し、何を未確認としたか」を見るためです。
PRレビューでは「採用した判断」を残す
CodexやClaude Codeの出力を、そのままPR説明に貼る必要はありません。大切なのは、人間が採用した判断です。
- どの指摘を直したか。
- どの指摘を見送ったか。
- どのテストを実行したか。
- どのテストを実行していないか。
- どのMCPや外部データを使ったか。
併用すれば証跡は増えます。証跡が増えた分だけ、要約して残す責任も増えます。
導入しないほうがよいケース
次に当てはまるなら、併用はまだ早いです。
- まだ
AGENTS.mdやチームの作業ルールがない。 - 誰がmerge判断をするか決まっていない。
- MCPの認証scopeやログを説明できない。
- 秘密情報や本番データの扱いが分離されていない。
- 料金上限や停止条件を管理者が見ていない。
- エージェントの「完了しました」を人間が検証せず通している。
この状態で併用すると、作業は速く見えても、事故時の説明が難しくなります。まず1つのツール、1つのリポジトリ、read-only、明示したテストから始めてください。
注意点
併用しない判断は後退ではありません。境界を作れない状態で両方を入れるより、片方の運用を固めてから広げるほうが、レビューと費用の説明責任を保ちやすくなります。
セキュリティ・コスト注意
安全性や費用は単純な勝敗ではなく、接続先、権限、ログ、停止条件で変わります。
Claude CodeとCodexを併用すると、攻撃面と費用面は広がります。これは「使わないほうがいい」という意味ではありません。境界を作らずに便利さだけ広げると、後で止めにくいという意味です。
read-only開始を標準にする
MCP、外部API、GitHub、DB、ブラウザ操作は、read-onlyから始めます。書き込みは、承認、ログ、取り消し、担当者が揃ってからです。
prompt injectionを前提にする
外部Issue、PRコメント、Webページ、MCP toolの説明文には、エージェントを誘導する文章が混ざる可能性があります。エージェントへ渡す外部文脈は、信頼済み命令ではなく入力データとして扱います。
料金は公開時点で必ず再確認する
CodexもClaude Codeも、利用上限、plan、credits、rate、提供条件が変わります。この記事では2026-06-14時点で公式DocsとHelp Centerを確認していますが、導入時は必ず現在のpricingとHelp Centerを見てください。X上の費用感や個人の体感は、チームの見積もり根拠にしないでください。
利害関係
この記事にスポンサー、アフィリエイト、無償提供、検証環境提供はありません。下書き作成、構成整理、校正補助にはAIを使っていますが、本文の根拠は公式一次情報と公開済みのサイト内記事に限定しています。
次に読むなら
更新通知をまとめて追いたい場合は、ニュースレターでAIコーディング、MCP、権限設計まわりの更新を案内しています。チーム導入、AGENTS.mdとCLAUDE.md整理、MCP read-only設計、1週間パイロット設計を社内向けに詰めたい場合は、お問い合わせから相談できます。
参照した主な情報源
- OpenAI Codex overview: https://developers.openai.com/codex
- OpenAI Codex CLI: https://developers.openai.com/codex/cli
- OpenAI Codex cloud: https://developers.openai.com/codex/cloud
- OpenAI Codex MCP: https://developers.openai.com/codex/mcp
- OpenAI Codex agent approvals and security: https://developers.openai.com/codex/agent-approvals-security
- OpenAI Codex sandboxing: https://developers.openai.com/codex/concepts/sandboxing
- OpenAI Codex permissions: https://developers.openai.com/codex/permissions
- OpenAI Codex pricing: https://developers.openai.com/codex/pricing
- OpenAI Help, Using Codex with your ChatGPT plan: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan
- OpenAI Help, Codex rate card: https://help.openai.com/en/articles/20001106-codex-rate-card
- Anthropic Claude Code overview: https://docs.anthropic.com/en/docs/claude-code/overview
- Anthropic Claude Code security: https://docs.anthropic.com/en/docs/claude-code/security
- Anthropic Claude Code settings: https://docs.anthropic.com/en/docs/claude-code/settings
- Anthropic Claude Code memory: https://docs.anthropic.com/en/docs/claude-code/memory
- Anthropic Claude Code MCP: https://docs.anthropic.com/en/docs/claude-code/mcp
- Anthropic Claude Code hooks guide: https://docs.anthropic.com/en/docs/claude-code/hooks-guide
- Anthropic Claude Code costs: https://docs.anthropic.com/en/docs/claude-code/costs
- Anthropic Help, Use Claude Code with your Pro or Max plan: https://support.anthropic.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
更新履歴
- 2026年6月14日
OpenAIとAnthropicの公式Docs、Help Center、pricing/rate cardを確認し、初版を作成しました。
- 2026年6月14日
X検索で見えた関心は需要シグナルとしてのみ扱い、本文の事実根拠には使わない方針を明記しました。
- 2026年6月14日
料金、利用上限、提供プラン、MCP、memory、securityは導入時に公式Docsを再確認する注意を追加しました。
AIコーディングエージェントの料金、権限、提供条件は更新されやすい領域です。
- 2026-06-14: OpenAIとAnthropicの公式Docs、Help Center、pricing/rate cardを確認し、Claude CodeとCodexの併用設計として初版を作成しました。
- 2026-06-14: X検索で見えた併用、費用感、MCP、memoryへの関心は需要シグナルとしてのみ扱い、本文の事実根拠には使わない方針を明記しました。
- 2026-06-14: 料金、利用上限、提供プラン、MCP、memory、securityの項目は変わりやすいため、導入時に公式Docsを再確認する注意を追加しました。