Claude CodeからCodexを呼び出して実装を任せる｜Max 5xとChatGPT Plusでの使い分け設定

はじめに

Claude CodeとCodexの両方を契約しているものの、どう使い分ければいいか迷っていませんか。
私も両方を使っていて、現在はClaude Codeをメインにし、そこからCodex CLIを呼び出して実作業を任せています。
契約しているのはClaude CodeがMax 5xプラン、ChatGPTがPlusプランです。
Claude Code側のモデルであるFableを計画と監査に集中させ、実装はCodexの高品質なモデルに任せることで、トークンと費用の効率を一番よくできると考えたのがこの形です。
この記事では、Claude Code側とCodex側の設定を全文または該当部分の抜粋で示し、実際にcodex execへ仕事を渡して監査するところまで紹介します。
私は自宅のUbuntuサーバーへSSHで入り、この運用を使っています。
Claude Codeをサーバーへ導入するところから始めたい方は、先に自宅サーバーにClaude Codeを入れて、面倒な設定を全部AIに任せるをご覧ください。

結論：Claude Codeが考え、Codexが手を動かす

最初に、私が決めている役割分担をまとめます。

Codexの呼び出しには、非対話モードのcodex execを使います。
非対話モードとは、Codexと画面上で会話を続けるのではなく、最初に渡した依頼を完了まで実行してもらう使い方です。
私がClaude Code側で使っているモデルはClaude Fable 5なので、以降はClaude Code側のモデルを「Fable」と表記します。

なぜこの分担にしたのか

私はClaude CodeをMax 5xプランで、ChatGPTをPlusプランで契約しています。
普通に考えれば、Maxを契約しているならClaudeだけですべて進めればいいと思いますよね。
それでも私がCodexまで使う理由は2つあります。

1つ目は、ChatGPTのPlusプランを有効活用したかったことです。
月3,000円ほどのPlusプランでも、Codexはけっこうな量を使えます（料金や利用枠は変わることがあるので、最新は公式サイトで確認してみてください）。
私はそれまでPlusプランを契約していながら、アプリでチャットをするだけだったので、もったいないと感じていました。

2つ目のほうが大きい理由で、実装をCodexに任せたほうが出力の質が高いからです。
Claude Codeだけで進める場合、実装はFableより下のモデルであるOpusへ委譲することになります。
私の使い方では、それよりもCodex側の高品質なモデル（gpt-5.6-sol）へ委譲したほうが、当然ながら成果物の質が上がります。
Fableの計画・監査と、Codexの高品質な実装を併用することで、トークンと費用の効率を一番よく使えるのがこの形だと考えました。

ただし、CodexはPlusプランなので、5時間ごとの利用制限にすぐ引っかかりますし、上位プランほどの量は使えません。
5時間制限の待ち時間や、週間の利用枠を使い切ったときは、Claude Code側のOpusへ委譲しています（後述）。

数行だけ直せば終わる変更など、委譲するほうが明らかに手間なら、Fableがそのまま実装します。
Codexがエラーやレートリミットで使えない場合は、その旨を私に伝えたうえでFableが実装まで引き受け、ユーザーがモデルや分担を指定した場合はその指示を優先します。

Claude Code側へ役割分担を書く

まず、FableとCodexの分担をClaude Code側の共通設定~/.claude/CLAUDE.mdへ書きます。
私が使っている該当部分は次のとおりです。
そのまま使う場合は、利用しているモデル名や運用に合わせて調整してみてください。

## モデルの分担（Fable 計画・監査 / Codex 実装）

- ユーザーから指示がない限り、以下の分担で進める:
  - **Fable（メインループ）**: 全体の計画・設計・タスク分解・実装後の監査
  - **Codex CLI**: 実装（コードの作成・修正）
- 目的: Fable の高品質な推論を計画と監査に集中させ、実装を Codex に任せることで、品質を維持しながら Fable のトークン消費を抑える
- ただし、数行の修正など Codex へ委譲する方が明らかに非効率な場合は、Fable が直接実装してよい
- Codex が使えない場合（エラー・レートリミット等）は、その旨をユーザーに伝えたうえで Fable が実装まで行う
- ユーザーが明示的にモデルや分担を指定した場合は、その指示を優先する

### Codex の呼び出し方（毎回この手順、再調査不要）

codex CLI の非対話モード `codex exec` を Bash ツールで呼び出す。モデルは `~/.codex/config.toml` のデフォルト設定を使うため `-m` 指定は不要。

基本形（1コマンド単独で実行。パイプや `&&` と組み合わせない）:

codex exec -C <作業ディレクトリ絶対パス> -s workspace-write -o <結果ファイル> "Claude Codeからの実装サブタスクです。CLAUDE.md、Claude Codeプロジェクトメモリ、該当するClaudeスキルを読み、指定範囲だけを実装してください。commit・pushは行わず、変更ファイル、検証結果、未解決事項を報告してください。実装タスク: <詳細指示>"

- 結果ファイル（`-o` = 最終メッセージの出力先）はスクラッチパッドに置き、完了後に Read で読む
- git リポジトリ外で実行する場合は `--skip-git-repo-check` を追加する
- `-C` には `/DATA/dev` のような親ディレクトリではなく、実際の対象リポジトリを指定する
- 実装指示には対象ファイル・要件・制約・完了条件を具体的に書く
- 完了後、Fable が `git diff` で成果物を監査する
- 監査での指摘は `codex exec resume --last "修正指示"` で差し戻す（同一セッション継続なのでコンテキストが維持される）
- 時間がかかりそうな実装タスクは Bash の `run_in_background` で実行する（フォアグラウンドはタイムアウト最大10分）
- 許可ルール `Bash(codex exec *)` は settings.json に登録済み

前半で担当と例外時の動きを決め、後半でCodexの呼び出し方を固定しています。

基本形の-Cは、Codexが作業するディレクトリを絶対パスで指定します。
たとえばブログの作業なら/DATA/dev/blogを指定し、複数のリポジトリが入った/DATA/devは指定しません。

-s workspace-writeは、作業ディレクトリ配下への書き込みだけを許可するサンドボックスの指定です。
-oはCodexの最終メッセージを書き出すファイルを指定し、Fableはここから変更点、検証結果、未解決事項を確認します。

モデル名をコマンドへ毎回書かないのは、~/.codex/config.tomlの既定値を使うためです。
私のCodex CLIはcodex-cli 0.151.0です。

Claude Codeからcodex execを許可する

次に、Claude Codeがcodex execを呼ぶたびに許可待ちにならないよう、~/.claude/settings.jsonのpermissions.allowへ2行を登録します。

{
  "permissions": {
    "allow": [
      "Bash(codex exec *)",
      "Bash(/home/<ユーザー名>/.npm-global/bin/codex exec *)"
    ]
  }
}

1行目は、コマンド名で始まるcodex execを許可します。

2行目は、Codexの実体が/home/<ユーザー名>/.npm-global/bin/codexというフルパスで呼ばれた場合に対応します。
<ユーザー名>はご自身のLinuxユーザー名に置き換え、~ではなく絶対パスで書いてください。
npmのグローバル導入先を~/.npm-globalにしていると、Claude Codeがフルパスでコマンドを組み立てることがあります。
許可ルールはコマンド文字列の前方一致で照合されるため、Bash(codex exec *)だけではフルパス版に一致しません。

なお、settings.jsonへ許可ルールを追加しても、反映されるのは次回のClaude Codeセッションからです。
追加した直後のセッションで確認待ちが続いたら、いったん終了して次のセッションから確認してみてください。

Codex側のconfig.tomlを設定する

Claude Code側の準備ができたら、Codex側の共通設定~/.codex/config.tomlを用意します。
私の環境で使っている抜粋は次のとおりです。

model = "gpt-5.6-sol"
model_reasoning_effort = "high"

# Claude Code を正本とするリポジトリでは、AGENTS.md がない場合に
# CLAUDE.md 本体を Codex のプロジェクト指示として直接読み込む。
project_doc_fallback_filenames = ["CLAUDE.md"]
project_doc_max_bytes = 65536

[projects."/DATA/dev/blog"]
trust_level = "trusted"

[projects."/DATA/dev/mufc-analysis"]
trust_level = "trusted"

[notice]
hide_rate_limit_model_nudge = true

この設定ではモデルをgpt-5.6-sol、推論の強さをhighにしているため、codex execには-mを付けていません。

この記事で最も大事なのが、project_doc_fallback_filenames = ["CLAUDE.md"]です。
これは、リポジトリにAGENTS.mdが無いとき、代わりにCLAUDE.mdをプロジェクト指示として読み込む設定で、Codex単体でも同じ約束を読んでから始められます。

project_doc_max_bytes = 65536は、読み込むプロジェクト文書の上限を65,536バイトにしています。
私のCLAUDE.mdは長いため、既定より大きめの値を設定しています。

[projects."/DATA/dev/blog"]と[projects."/DATA/dev/mufc-analysis"]は作業リポジトリごとの設定で、trust_level = "trusted"によりサンドボックスや承認の扱いを緩めています。

最後のhide_rate_limit_model_nudge = trueは、レートリミット時に別モデルを勧める通知を隠す設定です。

AGENTS.mdでClaude Codeの指示をCodexへ橋渡しする

config.tomlに加え、私の環境では読み込み順を定める~/.codex/AGENTS.mdも置いています。

# Claude Code 互換ブリッジ

このマシンでは Claude Code をメイン、Codex をサブとして使う。
Claude 側の指示・スキル・プロジェクトメモリを正本とし、Codex 用に本文を複製しない。

## 作業開始時の読込順

実ファイルの読込が必要な項目は、調査・回答・編集より先に実行する。

1. `~/.claude/CLAUDE.md` を全文読む。
2. 対象リポジトリを確定する。
   - Git リポジトリ内なら `git rev-parse --show-toplevel` の結果を使う。
   - `/DATA/dev` のような複数リポジトリの親から始まった場合は、依頼内容から対象を確定する。
   - 対象が確定できないまま変更してはいけない。
3. 対象リポジトリ直下の `CLAUDE.md` があれば全文読む。
   `project_doc_fallback_filenames` により既にコンテキストへ入っていても、別リポジトリへ移動した場合は
   移動先の `CLAUDE.md` を明示的に読む。
4. 対象リポジトリの Claude Code プロジェクトメモリを読む。
5. 依頼に合うリポジトリスキルがあれば、その `SKILL.md` を全文読んでから使う。

## Claude Code プロジェクトメモリ

Claude Code のメモリは読み取り専用の補助コンテキストとして使う。Codex から追加・変更・削除しない。
メモリの更新はメイン担当の Claude Code に任せる。

1. 対象リポジトリの絶対パスを、先頭の `/` を含めて `/` から `-` へ置換する。
   例: `/DATA/dev/mufc-analysis` → `-DATA-dev-mufc-analysis`
2. `~/.claude/projects/<変換後の名前>/memory/MEMORY.md` があれば全文読む。
3. `MEMORY.md` は索引として扱い、今回の依頼に関係する個別メモリだけを読む。
4. 移転前パスなどの旧メモリを自動的に混ぜない。`CLAUDE.md` または現在のメモリ索引が
   明示的に参照する場合だけ読む。
5. 現在のユーザー指示、リポジトリ内の正本、`CLAUDE.md` とメモリが矛盾する場合は、
   メモリを古い補助情報として扱い、より新しく具体的な正本を優先する。

`CLAUDE.md` が名前だけでメモリを参照しているのに実体を解決できない場合は、存在を捏造せず、
見つからないことを報告する。

## Codex での読み替え

- `CLAUDE.md` 内の「Claude」は、原則として現在作業しているエージェントに読み替える。
- Claude Code 固有のツール名、`antml` 構文、権限記法、モデル名、呼び出し構文はそのまま実行せず、
  現在の Codex の同等機能へ読み替える。
- Claude 側の「Fable が計画・監査し Codex CLI が実装する」という記述は呼び出し元の役割分担である。
  Codex 自身がさらに Codex を再帰呼び出ししてはいけない。
- Claude Code から実装担当として委譲されたことがプロンプトに明記されている場合、Codex は
  指定範囲の実装と検証を行い、明示的に依頼されない限り commit・push しない。
  変更ファイル、検証結果、未解決事項を Claude Code に返す。
- ユーザーが Codex に直接依頼した場合は主担当として扱い、Claude の共通 Git ルールと
  対象リポジトリの公開・デプロイ規則に従う。リポジトリ固有の停止条件を優先する。

## スキル

- リポジトリスキルの正本は `<repo>/.claude/skills/`。
- Codex の探索先 `<repo>/.agents/skills` は、リモート Linux では原則として
  `../.claude/skills` へのディレクトリシンボリックリンクにする。
- スキル一覧に表示された概要だけで実行せず、選択した正本の `SKILL.md` を全文読む。
- `/DATA/dev/.agents/skills` に全リポジトリのスキルを集約しない。対象外スキルの誤発火と
  同名スキルの衝突を避けるため、実際の対象リポジトリから Codex を開始する。

## パス対応

- Windows の `C:\dev\<repo>` は、この homeserver では `/DATA/dev/<repo>` に対応する。

最初の節では、Claude Codeの共通設定、対象リポジトリ、固有のCLAUDE.md、メモリ、スキルの順番を固定し、別のリポジトリへ移ったときは移動先の文書を読み直します。

プロジェクトメモリは~/.claude/projects/<パス変換名>/memory/配下にあり、MEMORY.mdを索引として関係する個別メモリだけを開きます。
たとえば/DATA/dev/mufc-analysisを変換すると、-DATA-dev-mufc-analysisになります。

メモリは読み取り専用の補助情報であり、現在の指示や正本と食い違う場合は、より新しく具体的な正本を優先します。

「Codexでの読み替え」は、Claude Code専用の構文や権限記法をCodexの同等機能へ読み替え、Codexの再帰呼び出しを防ぐ決まりです。
委譲されたCodexは指定範囲の実装と検証に集中し、変更ファイル、検証結果、未解決事項をFableへ返します。

スキルについては、Claude Code側の<repo>/.claude/skills/を正本にし、Codex側の探索先からシンボリックリンクで参照します。
シンボリックリンクは、同じ実体を別の場所から見えるようにする仕組みです。
.agentsディレクトリを先に作ったうえで、次のコマンドを実行します。

ln -s ../.claude/skills /DATA/dev/mufc-analysis/.agents/skills

このコマンドでClaude Code側のスキルへリンクし、本文を複製せず正本を1か所に保てます。

Codex側の許可ルールを確認する

Codexを対話モードで使う場合は、承認ダイアログで「今後は許可」を選んだコマンドが~/.codex/rules/default.rulesへ追記されます。
私はこのファイルを手で編集したことはなく、対話中に許可した結果として次のような行が入っています。

prefix_rule(pattern=["rg"], decision="allow")
prefix_rule(pattern=["git", "diff"], decision="allow")
prefix_rule(pattern=["git", "status", "--short"], decision="allow")
prefix_rule(pattern=["python3", "ssg/build.py"], decision="allow")
prefix_rule(pattern=["python3", "tools/thumbnails/make_thumb.py"], decision="allow")

prefix_ruleは、patternに並べたコマンドの先頭が一致したとき、decision="allow"として自動許可する形式です。
Claude Codeのsettings.jsonと同じく前方一致なので、どこまで自動許可するかは承認のたびに判断しています。

Codexの利用制限中はFableが計画してOpusが実装する

CodexがPlusプランの5時間制限で待ちになっているときや、週間の利用枠を使い切ったときは、Claude Codeだけで作業します。
ここでいうOpusは、Claude Codeで使えるClaudeのモデル名です。
その場合もFable一本ですべて進めるのではなく、Fableが計画、設計、タスク分解、難所の判断、監査を担当し、Opusが実装、執筆、調査、テスト、検証を担当します。

委譲にはClaude Codeのサブエージェント機能であるAgentツールを使い、modelにopusを指定します。
私が実際に使っているプロンプトは次のとおりです。

Fableは全体の計画・設計・タスク分解・難所の判断・実装後の監査を担当してください。
実際のコード実装・記事執筆・調査・テスト・検証は原則としてOpusにサブエージェントとして委譲してください（Claude Codeのサブエージェント機能でmodelにopusを指定）。

Opusへの委譲時は、以下を必ず渡してください。OpusはFableの文脈を共有していないため、依頼文の質がそのまま成果物の質になります。
- 目的と背景（なぜやるか）
- 完了条件（何をもって完了とするか、具体的に）
- 制約（変更してよい範囲・してはいけない範囲、既存の設計方針、規約）
- 検証方法（実行すべきテスト・lint・型チェック・確認手順）
- 報告形式（変更点の要約、実施した検証と結果、判断に迷った点・置いた仮定・未解決事項）

Opusは設計判断や曖昧さの解消をある程度自律的にこなせるため、手順を逐一指示するのではなく、目的と判断基準を渡して裁量を持たせてください。ただし、設計上の分岐が結果を大きく左右する箇所は、Fableが事前に方針を決めてから委譲してください。不明点があれば勝手に補完せず、仮定として明示して報告するようOpusに指示してください。

FableはOpusの成果物をレビューし、要件との整合性、設計上の問題、不要な変更、エッジケースや見落としを監査してください。Opusの自己報告は参考情報とし、検証結果は可能な限りFable自身でも確認してください。監査で問題が見つかった場合、修正内容が明確ならOpusに差し戻し、設計に密接な難所やOpusでは適切に処理できない問題はFable自身が実装案の提示や直接修正を行って構いません。

目的は、Fableの高品質な推論を設計・難所・監査に集中させ、実作業と反復的な検証をOpusに担当させることで、品質を維持しながらFableのトークン消費を抑えることです。

ただし、単純な数行の修正など、委譲する方が明らかに非効率な作業はFableが直接処理してください。またOpus自身のコストも小さくないため、独立したタスクは一度の委譲にまとめ、細切れの往復は避けてください。

委譲時に渡すのは、目的と背景、完了条件、制約、検証方法、報告形式の5項目で、これはCodex版と同じです。
一方でOpusは設計判断や曖昧さの解消をある程度自律的に進められるため、手順を逐一指定せず、目的と判断基準を渡して裁量を持たせます。
ただし、結果を大きく左右する設計上の分岐は、Fableが事前に方針を決めてから委譲します。

Opus自身のコストも小さくないため、独立したタスクは一度の委譲にまとめ、細切れの往復は避けます。
Codex版は別サービスであるChatGPT Plusの枠を使い、Opus版は同じClaudeの枠内でモデルを使い分ける点が違います。
どちらもFableの出番を計画、設計、難所、監査へ絞る考え方は同じで、Codexが使えるときはCodex、制限中はOpus、という順で使い分けています。

実際にFableからCodexへ依頼する1サイクル

ステップ1：Fableが指示書を組み立てる

まずFableが、Codexへ任せる作業を具体的な指示書へまとめます。
Codexは前回の仕事の文脈を持たない前提なので、毎回の指示に次の5項目を入れます。

1. 目的と背景
2. 完了条件
3. 制約
4. 実行すべき検証
5. 報告形式

制約には変更してよい範囲、完了条件には必要なテストやビルド、報告形式には変更点、検証結果、不明点や仮定を書きます。

さらに、次の3つを定型の約束として添えます。

1. 指示された範囲外は変更しません。
2. テストを通すために要件を緩めません。
3. 不明点は勝手に補完せず、仮定として明示して報告します。

長い指示は/tmpにファイルとして書き、プロンプトでは「このファイルを読んで従ってください」と渡します。
こうすると、Bashの引用符やバッククォートを含む長文が途中で壊れるのを避けられます。

ステップ2：codex execを単独で実行する

指示書ができたら、Claude CodeのBashツールから次の形で呼び出します。

codex exec -C /DATA/dev/blog -s workspace-write -o /tmp/codex_result.md "Claude Codeからの実装サブタスクです。まず /tmp/codex_brief.md を全文読み、その指示書に完全に従ってください。"

この例では作業場所を/DATA/dev/blog、最終報告を/tmp/codex_result.mdにしています。
時間がかかりそうな作業では、Claude Code側のBashをバックグラウンドで実行します。

codex execは、パイプや&&と組み合わせず、1コマンドだけで実行します。
Claude Codeの許可ルールはコマンド文字列の前方一致で照合され、複合コマンドはサブコマンドごとに判定されます。
末尾へ| headを付けても別に判定され、未許可なら全体が確認待ちになります。

Gitリポジトリの外でCodexを動かす場合は、次のように--skip-git-repo-checkを追加します。

codex exec --skip-git-repo-check -C <作業ディレクトリ絶対パス> -s workspace-write -o /tmp/codex_result.md "<具体的な指示>"

このオプションは、Gitリポジトリ外では既定で止まるcodex execを、その場所でも実行するために使います。

ステップ3：結果ファイルと差分をFableが監査する

Codexが完了したら、Fableは-oで指定した結果ファイルとgit diffの両方を読みます。
結果ファイルには変更内容、検証、残った不明点などが入りますが、自己報告だけで完了とは判断しません。
Fableは差分を読み、範囲外の変更や要件漏れがないか確認します。
ビルドやテストもFable側でもう一度実行し、Codexの報告どおりに通ることを確かめます。
この「成果物を見る」と「検証を再実行する」の2段階が、監査の中心です。

ステップ4：必要なら同じセッションへ差し戻す

直す場所があれば、次の形で同じCodexセッションへ修正を依頼します。

codex exec resume --last "監査で見つかった箇所を、元の要件を変えずに修正してください。"

resume --lastは、直前のセッションを続けて使うため、最初の指示や作業内容の文脈を保ったまま差し戻せます。
修正が終わったら、Fableがもう一度差分と検証結果を確認します。

ステップ5：問題がなければFable側でコミットする

監査が終わり、問題がなければFable側でコミットします。
Codexには原則としてcommitやpushを任せず、成果物と検証結果を返すところまでにします。
これで、計画を立てた側が最終差分を確認してから作業を確定できます。

よくあるトラブルと対処

ここまでの設定でつまずきやすい点を、Q&A形式でまとめます。

Q. codex execを呼ぶたびにClaude Codeが許可を求めてきます

A. ~/.claude/settings.jsonのpermissions.allowにBash(codex exec *)が入っているか確認してみてください。
npmの導入先が~/.npm-globalの場合は、Bash(/home/<ユーザー名>/.npm-global/bin/codex exec *)のような絶対パス版も必要です。
ルールを追加した後は、次回のClaude Codeセッションから反映されます。

Q. 許可したはずなのに、複合コマンドが確認待ちになります

A. Claude Codeでは、&&や|でつないだ各サブコマンドが個別に判定されます。
1つでも未許可のコマンドが含まれると全体が確認待ちになるため、codex execは単独で実行してください。
出力を短くするための| headなども付けない形が分かりやすいです。

Q. codexという名前なら許可されるのに、フルパスでは止まります

A. 許可ルールがコマンド文字列の前方一致だからです。
codex execと/home/<ユーザー名>/.npm-global/bin/codex execは別の始まり方なので、短いコマンド名とフルパスの2行を登録します。

Q. Claude Codeの指示をCodexがそのまま実行できません

A. Claude Code固有のツール呼び出し構文、権限記法、モデル名、呼び出し構文はCodexへそのまま通用しません。
~/.codex/AGENTS.mdの「Codexでの読み替え」を入れ、現在のCodexで使える同等機能へ読み替えるようにします。

Q. どのリポジトリを触るのかCodexが迷います

A. /DATA/devのように複数リポジトリを含む親ディレクトリではなく、実際の対象リポジトリを-Cへ指定してください。
対象が曖昧な場所では、関係のないリポジトリの指示やスキルを選ぶ可能性があります。

Q. Gitリポジトリではない場所でcodex execが止まります

A. --skip-git-repo-checkを追加します。
同時に-Cへ実際の作業ディレクトリを絶対パスで指定し、書き込み範囲も確認してみてください。

Q. Codexがレートリミットで止まりました

A. その時点でCodex側の作業を中断します。
Codex側のリセットを待つか、CLAUDE.mdの分担どおりFableが実装まで引き受けます。

Q. Codexの報告に「テスト成功」と書いてあれば、そのままコミットしてよいですか

A. 私はそのまま確定せず、Fable側でも結果ファイル、git diff、実際のビルドやテストを確認しています。
Codexの自己報告は作業内容を追うための参考情報として扱い、成果物と実行結果をもう一度確かめます。

まとめ

いかがでしたか。
今回は、Claude Codeをメインにしてcodex execでCodexへ実装を任せる方法と、Codexの利用制限中にFableからOpusへ委譲する方法を紹介しました。

振り返ると、次のような内容でした。

1. Fableは計画、設計、タスク分解、難所の判断、監査を担当し、Codexは実装、執筆、調査、検証を担当します。
2. ~/.claude/CLAUDE.mdへ分担と呼び出し方を書き、settings.jsonへコマンド名とフルパスの許可ルールを登録します。
3. ~/.codex/config.tomlのproject_doc_fallback_filenamesで、Codex単体でもリポジトリのCLAUDE.mdを読めるようにします。
4. ~/.codex/AGENTS.mdで、共通設定、プロジェクトメモリ、スキルを読む順番とClaude Code固有記法の読み替えを決めます。
5. Codexが5時間制限や週間制限で使えないときは、Fableが計画と監査を担当し、Agentツールでmodelにopusを指定して実作業を委譲します。
6. Fableが具体的な指示書を作り、codex execへ渡し、結果ファイルと差分を監査して、必要ならresume --lastで差し戻します。
7. 最終的なビルドやテストをFable側でも確かめ、問題がなければFable側でコミットします。

同じように両方を使っている方は、ご自身の作業に合わせて役割分担を調整してみてください。

この記事が誰かの役に立てばうれしいです。