Claude Fable 5の追加料金なしで使える期間は、当初2026年7月7日までと案内され、その後7月12日、さらに7月19日まで延長された。Claude Codeの週間利用上限が50％増える施策も、同じく7月19日まで継続される。
つまり、Fable 5が今すぐ消えるわけではない。
しかし、Fable 5を月額プランの範囲内で当然のように使い続けられる状況が、恒久的に保証されたわけでもない。元の案内では期間終了後にusage creditsへ移行するとされており、API価格も入力100万トークン当たり10ドル、出力100万トークン当たり50ドルだ。
終わろうとしているのはFable 5そのものではなく、最高性能モデルを月額料金だけで無制限に近い感覚で使える時代なのだ。
では、Claude Codeを捨てて、OpenAIのCodexへ全面移行するべきなのか。
結論から言えば、その必要はない。
Claude Codeのターミナル体験、既存のCLAUDE.md、Hooks、MCP、Skills、権限設定を残したまま、難しい作業だけをGPT-5.6 Solへ渡せばいい。
しかも、怪しいプロキシサービスや非公式なAPI互換レイヤーを使う必要はない。
OpenAI自身が、Claude Codeの中からCodexを呼び出すための公式プラグインを公開している。
ここで作るのは、「ClaudeをGPT-5.6に変身させる仕組み」ではない。
Claude Codeを司令塔として残し、GPT-5.6 Solを第二の思考エンジンとして接続する二脳構成だ。
Claudeはユーザーとの会話、リポジトリ探索、小さな編集、既存パターンへの追従を担当する。
GPT-5.6 Solは、複雑な設計判断、解決しない不具合、敵対的レビュー、複数コンポーネントにまたがる変更、出荷前のセカンドオピニオンを担当する。
さらに、日本語の運用プロンプトをAgent Skillとして置き、どちらのモデルにも同じ完了条件、検証基準、変更範囲を守らせる。
これが、Claude Codeに「ChatGPT 5.6の頭脳」を与える、最も現実的な方法である。
なお、セットアップやガチの活用術はPDFにまとめてます。
欲しい人は、この👇から受け取れるようにしてます！
https://x.com/MakeAI_CEO/status/2027682940847898770?s=20
Claude CodeにGPT-5.6の頭脳を与える3つのレイヤー
最初に区別したいのは、プロンプトをコピーすることと、実際のモデルへ接続することは別だという点だ。
CLAUDE.mdにGPT-5.6向けの指示を書いても、ClaudeのモデルそのものがGPT-5.6へ変わるわけではない。
変わるのは仕事の進め方である。
これを行動レイヤーと呼ぶ。
次に、OpenAI公式の「Codex plugin for Claude Code」を導入する。
このプラグインを使うと、Claude Codeの中から、ローカル環境にインストールされたCodex CLIとCodex app serverを通じて、Codexへコードレビューや実装作業を委譲できる。
これが推論・実行レイヤーだ。
最後に「OpenAI Developers plugin」を導入する。
こちらにはOpenAIの公式ドキュメントを参照するDocs MCPと、OpenAI API、Agents SDK、ChatGPT Apps、APIキー設定、トラブルシューティングなどに対応するSkillsが含まれている。
これが知識レイヤーである。
この3つを重ねる。
行動レイヤー
日本語の運用プロンプトとAgent Skill
推論・実行レイヤー
Codex plugin for Claude Code
知識レイヤー
OpenAI Developers pluginと公式Docs MCP
こうすると、普段の操作はClaude Codeのまま、必要なときだけGPT-5.6 SolとOpenAIの最新ドキュメントを呼び出せる。
まずはOpenAI公式のCodexプラグインを入れる
導入に必要なのは、ChatGPTアカウントまたはOpenAI APIキー、Node.js 18.18以降、そしてCodex CLIだ。
このプラグインは、どこかの非公式サービスへコードを転送するものではない。
自分のマシンにあるCodex CLIを利用し、既存のCodex認証、設定、リポジトリ、ローカル環境を引き継ぐ。すでにCodexへログインしているなら、その認証状態をそのまま利用できる。
最初にCodex CLIをインストール、または更新する。
npm install -g @openai/codex@latest
codex --version
codex login
GPT-5.6をCodexで使うには、Codex CLI 0.144.0以降が必要だ。
codex --version
表示されたバージョンが古ければ、もう一度最新版をインストールする。
次にClaude Codeを起動し、以下を順番に実行する。
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup
/codex:setupは、Codex CLIが利用可能か、認証が完了しているかを確認する。
Codexが未インストールでnpmが使える環境なら、セットアップ中にインストールを提案してくれる場合もある。
導入後、最初に試すなら読み取り専用レビューが安全だ。
/codex:review --background
/codex:status
/codex:result
/codex:reviewは現在の未コミット差分をレビューする。
mainブランチとの差分を確認させたいなら、次のようにする。
/codex:review --base main --background
このコマンドは読み取り専用で、コードを変更しない。
バックグラウンドで開始した仕事は、次のコマンドで確認できる。
/codex:status
/codex:result
進行中の処理を止める場合は、次のようにする。
/codex:cancel
普通のレビューと敵対的レビューを使い分ける
Codexプラグインには、通常レビューとは別にadversarial-reviewがある。
/codex:adversarial-review --base main
通常レビューは、コード上の不具合、テスト不足、エラー処理、型の問題などを探す。
一方、敵対的レビューは、実装方針そのものを疑う。
たとえば、認証処理を実装したあとに、次のように依頼できる。
/codex:adversarial-review --base main 認可境界、権限昇格、セッション固定、トークン漏えい、監査ログ不足の観点から、現在の方針そのものが間違っていないか検討する
課金処理なら、次のようにする。
/codex:adversarial-review --base main 二重請求、重複Webhook、タイムアウト後の再試行、部分失敗、トランザクション境界、ロールバック不能の可能性を重点的に疑う
通常レビューが「この実装にバグがないか」を調べるものだとすれば、敵対的レビューは「そもそも、この実装を選ぶべきだったのか」を調べるものだ。
どちらも読み取り専用で、勝手にコードを書き換えない。
実装を作ったモデルと、実装の前提を疑うモデルを分離できるのが、この構成の強みである。
公式プラグインには、通常レビュー、敵対的レビュー、救援、セッション移管、バックグラウンド処理の確認と停止を行うコマンドが用意されている。
行き詰まった仕事はrescueでCodexへ渡す
Claude Codeで何度か修正してもテストが通らない。
原因が複数コンポーネントにまたがっている。
CIでだけ失敗する。
並行処理やキャッシュが絡み、症状と原因が離れている。
こうしたときは、/codex:rescueを使う。
/codex:rescue 不具合を再現し、根本原因を特定し、最小の安全な修正と回帰テストを作成する
モデルと推論強度を指定することもできる。
/codex:rescue --model gpt-5.6-sol --effort high 不具合を再現し、根本原因を特定し、最小の安全な修正を実装して、関連テストまで実行する
長い処理はバックグラウンドに回す。
/codex:rescue --background --model gpt-5.6-sol --effort high CIでのみ発生するテスト失敗を調査する
結果は次のコマンドで取得する。
/codex:status
/codex:result
前回のCodex作業を継続する場合は、--resumeを使える。
/codex:rescue --resume 前回提案した修正のうち、最も安全な案を実装して検証する
前回とは切り離し、新しい調査として開始したい場合は--freshを使う。
/codex:rescue --fresh 別の仮説から根本原因を調査する
Claude Codeで続けてきた会話全体をCodexへ移す場合は、次のコマンドを使う。
/codex:transfer
実行後、Codex側で再開するためのコマンドが表示される。
codex resume <session-id>
これにより、「Claude Codeで調査を始めたが、途中からCodexを主担当にする」という移管が可能になる。
GPT-5.6 Solを標準モデルにする
プロジェクト単位でCodexのモデルを固定したい場合は、リポジトリのルートに.codex/config.tomlを置く。
model = "gpt-5.6-sol"
model_reasoning_effort = "high"
review_model = "gpt-5.6-sol"
個人のすべてのプロジェクトで共通設定にするなら、次の場所へ置く。
~/.codex/config.toml
プロジェクト固有の設定は次の場所だ。
your-project/.codex/config.toml
プロジェクト設定は、そのリポジトリを信頼済みとして扱った場合に読み込まれる。
日常的な作業では、最初から最大の推論強度を使う必要はない。
目安としては、次のように分ける。
low
文言修正、名前変更、明確な小規模変更
medium
通常の機能追加、既存パターンに沿った実装
high
複数ファイルにまたがる変更、難しいデバッグ、設計判断
xhigh
セキュリティレビュー、大規模移行、複雑な競合状態、長時間調査
CodexではGPT-5.6 Sol、Terra、Lunaを選択できる。
Solは複雑で自由度の高い仕事、Terraは日常的な実装、Lunaは明確で繰り返し可能な仕事に向く。
また、通常の推論強度とは別にMaxやUltraも用意されている。
Maxは単一タスクへより多くの推論時間を与える。
Ultraはサブエージェントを使い、分割可能な仕事を並行処理する。
ただし、大半の作業にMaxやUltraは不要だ。MediumかHighから始め、実際の評価で差が出る場合だけ引き上げる方がよい。
「GPT-5.6 Sol High」と「GPT-5.6 Sol Pro」は同じではない
ここは混同されやすい。
ChatGPTでは、Medium、High、Extra HighにGPT-5.6 Solが使われる。
一方、ProにはGPT-5.6 Sol Proが使われる。
したがって、Codexプラグインで次のように指定しただけでは、
--model gpt-5.6-sol --effort high
「GPT-5.6 Sol Proを使った」とは言えない。
これはGPT-5.6 SolをHighの推論強度で動かしたという意味だ。
OpenAI APIのResponses APIでは、GPT-5.6のreasoning.modeとしてstandardとproを選べる。
Proモードを使う場合は、次のようなリクエストになる。
{
"model": "gpt-5.6",
"reasoning": {
"mode": "pro",
"effort": "high"
},
"input": "このデータベース移行計画をレビューし、失敗パターン、復旧方法、ロールバック不能になる条件を特定してください。"
}
reasoning.modeとreasoning.effortは別の設定だ。
reasoning.mode
standard または pro
reasoning.effort
low、medium、high、xhighなど
Proモードは標準モードより多くのモデル処理を行うため、遅延とトークン使用量が増える。
Claude CodeからこのAPIのProモードを厳密に呼びたい場合は、Responses APIを包むローカルスクリプトやMCPサーバーを用意し、それをClaude CodeのSkillから呼び出す構成になる。
ただし、通常のコーディング作業なら、まず公式CodexプラグインでGPT-5.6 SolのMediumまたはHighを試すべきだ。
そのうえで、実際の評価結果からProモードの効果が確認できた仕事だけを引き上げる。
名前に「Pro」と付いているからという理由だけで、すべての処理をProへ送る必要はない。
ChatGPT 5.6 Sol Proの「システムプロンプト」は公開されていない
ここで注意したい。
OpenAIがChatGPTやGPT-5.6 Sol Proの実運用で使用している、内部システムプロンプトの完全版は公開されていない。
したがって、インターネット上にある「流出したGPT-5.6のシステムプロンプト」「完全再現版」「内部プロンプト全文」といった出典不明の文章を、本物だと信じて導入するべきではない。
使うべきなのは、公式のプロンプトガイドを参考にしながら、自分の開発環境に合うように作った運用プロンプトだ。
GPT-5.6向けの公式ガイドでは、プロンプトに次の要素を明示することが推奨されている。
最終的に達成すべき成果
重要な制約
利用可能な証拠
完了と判断する基準
一方で、検索順序、ツール選択、細かな思考手順まで過剰に固定せず、モデルが効率的な経路を選べる余地を残す。
また、重複した命令、不要な例、意味のないツール説明を削り、システムプロンプトを軽量化する方が、性能とトークン効率の改善につながる場合があると説明されている。
以下は、その考え方をClaude Code、Codex、GPT-5.6 Solで共通利用できるようにした、日本語の運用プロンプトだ。
OpenAI内部プロンプトの転載ではない。
Claude CodeとGPT-5.6 Solで使う日本語運用プロンプト
役割
あなたは、このリポジトリにおける上級実行オーケストレーターです。
あなたの目的は、ユーザーが本当に求めている成果を満たす、
正しく、保守可能で、検証済みの最小変更を提供することです。
文章を多く書くこと、変更するファイルを増やすこと、
ツールを多く使用すること自体は評価対象ではありません。
正確性、証拠、変更範囲の節度、
レビュー可能な成果によって評価されます。
運用契約
1. 成果を明確にする
編集を始める前に、次の項目を特定してください。
- ユーザーから見える最終的な成果
- 関連するリポジトリ領域
- 必ず守る制約
- 今回は行わないこと
- 完了と判断するための基準
- 完了を証明できる検証方法
曖昧な点は、まずリポジトリ内の証拠から解消してください。
不足している判断によって、製品の挙動、セキュリティ、
コスト、データ、または元に戻せない操作が大きく変わる場合にのみ、
ユーザーへ質問してください。
リポジトリを調査せずに済ませるためだけの質問はしないでください。
2. 変更前に調査する
必要十分な最小範囲のファイルを読んでください。
次の項目を調査してください。
- 既存の実装パターン
- テスト
- インターフェース
- マイグレーション
- 命名規則
- 設計上の慣例
- エラー処理
- 認証と認可の境界
推測やフレームワークの一般的な初期値よりも、
リポジトリ内の証拠を優先してください。
不具合対応では、修正案を出す前に、
再現可能な失敗、または原因を裏づける具体的な証拠を確立してください。
既存の仕組みが存在する理由を理解する前に、
その仕組みを書き換えないでください。
3. 適切な深さで計画する
小さく、局所的で、元に戻しやすい変更であれば、
そのまま作業を進めてください。
次のいずれかに該当する場合は、実装前に簡潔な計画を示してください。
- 複数ファイルにまたがる
- アーキテクチャを変更する
- セキュリティに関係する
- データを書き換える
- 公開インターフェースを変更する
- 元に戻すことが難しい
- 課金、認証、権限、個人情報に関係する
- 並行処理や非同期処理に関係する
計画には次を含めてください。
- 実現する予定の挙動
- 変更する可能性が高いファイルまたはコンポーネント
- 維持する必要がある不変条件
- 主なリスク
- 検証手順
- 必要に応じたロールバックまたは復旧方法
リスクを減らさない形式的な手続きを増やさないでください。
4. 最適なエンジンへ作業を振り分ける
現在のClaude Codeセッションは、次の作業に使用してください。
- 迅速なリポジトリ探索
- ユーザーとの対話
- 小規模で範囲が明確な編集
- タスクの分解と進行管理
- 既存パターンに沿った実装
- Codexから返された指摘の確認と統合
次の条件のうち一つ以上に該当する場合は、
Codexへの委譲または独立レビューを検討してください。
- 根拠のある調査や修正を試みても作業が行き詰まっている
- 変更が複数の相互作用するコンポーネントにまたがる
- 独立した第二の実装案に価値がある
- 敵対的な観点からのレビューが有効である
- 正確性、セキュリティ、並行処理、マイグレーション、 またはロールバックに関するリスクが高い
- ユーザーがGPT-5.6 Solの利用を明示的に求めている
- リリース前に現在の実装方針そのものを疑う必要がある
レビューだけで不確実性を解消できる場合は、
書き込み可能な委譲を行う前に、
読み取り専用のCodexレビューを使用してください。
実際のリクエストで文書化されたProモードを使用していない限り、
GPT-5.6 Sol Proを使用したと主張してはいけません。
使用したモデルID、推論強度、推論モードを正確に報告してください。
5. 変更範囲を絞って実装する
明示的に再設計が求められていない限り、
既存のアーキテクチャ、命名規則、
リポジトリの慣例に従ってください。
次のことは避けてください。
- 関係のないリファクタリング
- 将来を予測した過剰な抽象化
- 不要な依存関係の追加
- 意味のないフォーマット変更
- 広範囲な書き換え
- 要求範囲外の公開挙動の変更
- 既存テストを理由なく削除すること
- 問題を隠すためだけの例外握りつぶし
破壊的変更が明示的な要件でない限り、
後方互換性を維持してください。
秘密情報、認証情報、秘密鍵、トークン、
顧客データ、個人情報を公開してはいけません。
次の場所に秘密情報を記載してはいけません。
- CLAUDE.md
- AGENTS.md
- SKILL.md
- ソースファイル
- ログ
- テストフィクスチャ
- 生成されたレポート
- コミットメッセージ
6. 証拠によって検証する
利用可能な範囲で、
変更内容に最も関連する検証を実行してください。
原則として、次の順序を優先してください。
- 対象を絞ったテスト
- 型チェック
- Lintおよびフォーマットチェック
- ビルド
- 統合テスト
- 実行時または視覚的な確認
変更内容に見合った検証だけを実行してください。
ただし、早く終了するためだけに、
本来必要な検証を省略してはいけません。
UI変更では、可能であれば実際に動作している画面を確認してください。
不具合修正では、現実的に可能であれば、
回帰テストを追加または更新してください。
マイグレーションや破壊的操作では、
次の項目を確認してください。
- 正常な前進処理
- 失敗時の処理
- ロールバックまたは復旧
- 部分的に実行された場合の挙動
- 再試行時の挙動
- 二重実行時の挙動
根拠を示さずに、
「修正済み」「動作する」「安全」「完了」と表現してはいけません。
検証を実行できない場合は、その理由と、
未検証のまま残っている内容を正確に示してください。
成功していないテストを成功したと捏造してはいけません。
7. 最終差分をレビューする
作業を終える前に、次の確認を行ってください。
- 最終差分を確認する
- 意図しない変更がないか探す
- エラー処理と境界条件を確認する
- セキュリティ境界と認可処理を確認する
- 必要に応じて並行処理と再試行時の挙動を確認する
- 不足しているテストがないか確認する
- 最終結果を当初の成果目標と比較する
- 今回行わないと決めた内容を誤って実装していないか確認する
高リスクな変更では、独立したCodexレビューを依頼してください。
重要なレビュー指摘はすべて、
次のいずれかで処理してください。
- 修正する
- リポジトリ上の証拠を示して却下する
- 今回の範囲外として明確に文書化する
- 環境不足により未検証であると記録する
Codexが指摘したという理由だけで、
無条件に変更を採用してはいけません。
コード、仕様、テスト、実行結果によって指摘を検証してください。
8. 適切な時点で終了する
完了基準を満たした時点で作業を終了してください。
依頼された範囲を超えて、
不要な磨き込みを続けないでください。
作業を大きく見せるために、
関係のないTODOや再設計案を追加してはいけません。
最終回答には、次の項目を含めてください。
- 提供した成果
- 主な変更内容
- 実行した検証と結果
- 残っているリスク、前提条件、またはブロッカー
- 本当に必要な場合に限り、次に行うべき具体的な操作
このプロンプトの目的は、モデルを「天才エンジニアの人格」にすることではない。
成果、証拠、変更範囲、委譲条件、検証、停止条件を明確にすることだ。
「徹底的に考えろ」「世界最高のエンジニアとして振る舞え」といった抽象的な命令を大量に書くよりも、何をもって完了とするかを定義した方が運用しやすい。
長いプロンプトはCLAUDE.mdではなくSkillへ置く
先ほどのプロンプトを、そのままCLAUDE.mdに書くこともできる。
しかし、毎回必ず必要になるわけではない長文をCLAUDE.mdへ置くと、すべてのセッションでコンテキストを消費する。
より適した置き場所はAgent Skillだ。
Claude CodeのSkillは、名前と説明を先に認識し、必要になったときだけSKILL.md本文を読み込む。
CodexのSkillも同様に、指示、参照資料、スクリプト、テンプレートなどをひとつのディレクトリへまとめ、必要なときだけ読み込む仕組みを採用している。
両方ともAgent Skillsの形式を利用しているため、基本的なプロンプトや手順を共有しやすい。
Claude Codeでは、次の場所へ保存する。
.claude/
└── skills/
└── sol-pro-orchestrator/
└── SKILL.md
SKILL.mdの冒頭は、次のようにする。
name: sol-pro-orchestrator
description: >
複雑な変更、複数ファイルにまたがる変更、高リスクな変更、
作業が行き詰まった場合、またはリリース前の重要な作業で使用する。
明確な計画、検証、独立したCodexレビューまたは委譲が必要な場合に適用する。
Sol Proオーケストレーター
[ここに先ほどの日本語版運用プロンプトを置く]
明示的に呼び出す場合は、次のようにする。
/sol-pro-orchestrator 課金処理を追加する。既存の冪等性設計を維持し、二重請求の回帰テストまで作成する
Skillのdescriptionと依頼内容が一致すれば、Claudeが自動的に読み込むこともある。
自動起動させたくない場合は、frontmatterに次を追加する。
disable-model-invocation: true
その場合、ユーザーが明示的にスラッシュコマンドを実行したときだけSkillが使われる。
常時必要な短いルールだけをCLAUDE.mdに残し、複雑な作業手順をSkillへ分離するのがよい。
たとえばCLAUDE.mdは、次の程度で十分だ。
リポジトリルール
- 既存のアーキテクチャと命名規則に従う。
- 安全性を維持できる最小の変更を優先する。
- 完了前に関連するテストを実行する。
- 関係のないファイルを変更しない。
- 複雑、行き詰まり、高リスク、またはリリース前の重要な作業では、 sol-pro-orchestrator Skillを使用する。
OpenAI公式SkillsをClaude Codeへ追加する
GPT-5.6 Solを呼べるようにするだけでは不十分だ。
モデルがOpenAI APIやAgents SDKについて、学習時点の記憶だけで回答すると、古いAPI、廃止されたパラメーター、現在は推奨されていない実装を使う可能性がある。
そこで導入するのが「OpenAI Developers plugin」だ。
Claude Codeで次を実行する。
/plugin marketplace add openai/openai-developers-for-claude
/plugin install openai-developers@openai-developers
インストール後は、新しいClaude Codeセッションを開始する。
このプラグインには、OpenAI公式Docs MCPと、次のSkillsが含まれている。
openai-docs
OpenAIの製品、API、モデル、SDKに関する質問を、公式ドキュメントへルーティングする。
新しいモデル名、現在のAPIパラメーター、SDKの使い方、Codexの設定など、変更されやすい情報を確認するために使う。
openai-platform-api-key
ローカル環境でのOPENAI_API_KEY設定を案内する。
APIキーをソースコードやプロンプトへ貼り付けるのではなく、環境変数として接続するためのSkillだ。
openai-api-troubleshooting
OpenAI APIのエラーを分類する。
認証、権限、モデル指定、レート制限、ネットワーク、リクエスト形式などを確認し、次に取るべき行動へ導く。
agents-sdk
OpenAI Agents SDKを使ったアプリケーションの設計、実装、実行、評価を支援する。
build-chatgpt-app
ChatGPT Apps SDKを使ったプロジェクトを設計・実装する。
MCPサーバー、ウィジェットUI、ChatGPTとの連携を含むアプリ開発に使う。
chatgpt-app-submission
ChatGPT Appの提出準備、説明情報、テストケースなどを整える。
このプラグインは、Claude Code向けにOpenAIが公開している公式リポジトリだ。
公開OpenAI Docs MCPと、Claude Code用に調整された開発Skillsがセットになっている。
ここで、二つのプラグインを混同してはいけない。
codex-plugin-cc
Codexへレビューや実装を委譲するための実行ブリッジ
openai-developers-for-claude
OpenAIの公式情報と開発手順をClaude Codeへ追加する知識パッケージ
両方を入れることで、Claude Codeは「Codexへ考えさせる」だけでなく、「OpenAIの公式仕様を確認しながら実装する」環境になる。
実戦ではClaudeとCodexをどう分担するか
すべての仕事を二つのモデルへ同時に投げる必要はない。
役割を分ける。
Claude Codeには、次の作業を任せる。
リポジトリ探索
ユーザーとの対話
既存実装の理解
小さな変更
既知パターンに沿った実装
Codexの指摘をコードへ反映する作業
GPT-5.6 Solには、次の作業を任せる。
複雑な設計判断
行き詰まった不具合
複数コンポーネントにまたがる調査
敵対的レビュー
セキュリティ境界の確認
並行処理や競合状態の調査
マイグレーションとロールバックの確認
リリース前の独立レビュー
たとえば、新しい課金処理を追加する場合は、次の流れになる。
- Claude Codeで既存の課金フロー、テスト、冪等性設計を調査する
- sol-pro-orchestrator Skillで計画と完了条件を固定する
- Claudeが最小実装と回帰テストを作る
- Codexの敵対的レビューで設計方針を疑う
- Claudeが指摘をコードとテストで検証する
- 必要な修正だけを反映する
- Codexの通常レビューで最終差分を確認する
最初にSkillを呼ぶ。
/sol-pro-orchestrator 課金処理を追加する。既存設計を調査し、冪等性、重複Webhook、回帰テストを完了条件に含める
実装後、敵対的レビューを行う。
/codex:adversarial-review --base main 二重請求、重複Webhook、タイムアウト後の再試行、部分失敗、トランザクション境界、ロールバック不能の可能性を重点的に疑う
修正後、通常レビューを行う。
/codex:review --base main --background
/codex:status
/codex:result
この方法の狙いは、ClaudeとGPTのどちらが強いかを決めることではない。
実装を作る役割と、実装の前提を壊す役割を分離することだ。
同じモデルへ「実装して、そのあと厳しく自己レビューして」と依頼すると、最初に採用した設計を前提にレビューしやすい。
別系統のモデルを批評者として入れることで、異なる探索経路と失敗仮説を持ち込める。
これはモデル同士の競争ではなく、ソフトウェア開発における職務分離である。
すべてをSol Highへ送ってはいけない
ファイル名の変更、表示文言の修正、単純な型エラーまでGPT-5.6 Sol Highへ送ると、利用枠と時間を浪費する。
モデルの使い分けは、次のように考えるとよい。
Claude Code
対話、探索、小さな修正、統合作業
GPT-5.6 Luna
明確で大量の変換、分類、定型作業
GPT-5.6 Terra
日常的な実装、通常のデバッグ
GPT-5.6 Sol Medium
一定の計画や判断を伴う実装
GPT-5.6 Sol High
難しい設計、複雑な不具合、重要なレビュー
GPT-5.6 Sol xhigh、Max、Pro、Ultra
評価によって追加効果が確認できた最難関タスク
高性能モデルを常に使うのではなく、失敗したときの損失が大きい仕事へ集中させる。
この方が、コストだけでなく結果の確認もしやすい。
レビューゲートは常時オンにしない
公式Codexプラグインには、Claudeが作業を終了しようとしたとき、自動的にCodexレビューを実行するreview gateがある。
有効化するコマンドは次の通りだ。
/codex:setup --enable-review-gate
無効化する場合は次を使う。
/codex:setup --disable-review-gate
レビューで問題が見つかると、Claudeの終了を止め、修正へ戻すことができる。
強力だが、ClaudeとCodexの間で長いループが発生し、利用枠を急速に消費する可能性がある。
そのため、次のような場面に限定した方がよい。
リリース候補
認証・認可の変更
課金処理
大規模データ移行
セキュリティ境界
ロールバックが難しい変更
普段の小さな作業では、必要なタイミングで手動レビューを実行する方が扱いやすい。
公式READMEも、review gateは長時間のClaude／Codexループを作り、利用上限を消費する可能性があるため、監視できるときだけ有効にするよう警告している。
Codexの指摘を無条件で採用しない
GPT-5.6 Solは強力だが、常に正しいわけではない。
存在しない仕様を前提にしたり、リポジトリ固有の事情を見落としたり、過剰な設計変更を提案したりする可能性はある。
レビュー指摘は、次のいずれかで処理する。
採用
根拠を確認し、修正と検証を行った
却下
リポジトリ、仕様、テストの証拠を示して採用しなかった
延期
有効な指摘だが今回のスコープ外として別タスクにした
未検証
環境や権限が不足しており確認できなかった
「Codexが言ったから変更する」のではない。
「Codexが提示した失敗仮説を、コードとテストで確かめる」が正しい。
二脳構成の価値は、回答を無条件に信じることではなく、確認すべき別の可能性を増やすことにある。
セキュリティ上の最低ライン
Claude CodeとCodexは、どちらもリポジトリを読み、コマンドを実行し、設定次第でファイルを書き換える。
二つのエージェントを接続するときは、便利さより先に権限境界を決める必要がある。
最初は読み取り専用レビューから始める。
/codex:review
/codex:adversarial-review
書き込みを伴うrescueは、対象リポジトリと作業内容を確認してから使う。
.env、秘密鍵、顧客データ、アクセストークンをCLAUDE.md、AGENTS.md、SKILL.mdへ貼らない。
OpenAI APIキーは環境変数として設定する。
export OPENAI_API_KEY="..."
実際にはシェルのプロファイル、秘密情報管理サービス、CIのSecret機能などを利用する。
また、Claude Codeの権限設定とCodexのsandbox／approval設定を同一だと決めつけない。
Claude側とCodex側の両方で、ネットワークアクセス、ファイル書き込み、コマンド実行の範囲を確認する。
外部MCPを追加するときも、提供元と権限を確認し、必要なツールだけを許可する。
完成形のディレクトリ構成
最終的なリポジトリは、次のようになる。
your-project/
├── CLAUDE.md
├── AGENTS.md
├── .claude/
│ └── skills/
│ └── sol-pro-orchestrator/
│ └── SKILL.md
├── .codex/
│ └── config.toml
├── src/
├── tests/
└── package.json
それぞれの役割は明確に分ける。
CLAUDE.md
Claude Codeが常に守る、短いリポジトリルールを書く。
- 既存アーキテクチャに従う
- 関係のないファイルを変更しない
- 最小の安全な変更を優先する
- 関連するテストを実行する
AGENTS.md
Codexが必要とするプロジェクト情報を書く。
- リポジトリ構成
- 開発環境の起動方法
- ビルドコマンド
- テストコマンド
- 設計上の制約
- 完了条件
.claude/skills/sol-pro-orchestrator/SKILL.md
複雑な作業でだけ読み込む、日本語の運用プロンプトを書く。
.codex/config.toml
Codexで使用するモデルと推論強度を書く。
model = "gpt-5.6-sol"
model_reasoning_effort = "high"
review_model = "gpt-5.6-sol"
そしてClaude Codeへ、二つの公式プラグインを追加する。
openai/codex-plugin-cc
openai/openai-developers-for-claude
これでClaude Codeは、次の役割を持つ。
Claudeによる日常的な実装と対話
GPT-5.6 Solによる独立レビューと救援
OpenAI公式Docs MCPによる最新仕様の確認
Agent Skillsによる再利用可能な開発プロセス
まとめ：Claude Codeを捨てず、二つ目の脳を足す
Fable 5の追加料金なしの利用期間は、2026年7月19日まで延長された。
そのため、「Fableが今日終わった」という状態ではない。
しかし、最高性能モデルを月額プランの範囲内で使い続けられることが、当然ではなくなりつつあるという流れは変わらない。
だからといって、Claude Codeを捨てる必要はない。
Claude Codeは司令塔として残す。
OpenAI公式のcodex-plugin-ccを使い、GPT-5.6 Solをレビュー、救援、実装へ呼び出す。
OpenAI Developers pluginを追加し、公式Docs MCPとOpenAI開発用Skillsを利用する。
共通の運用プロンプトは、巨大な常駐指示としてCLAUDE.mdへ詰め込まず、必要なときだけ読み込むAgent Skillにする。
そして、「実装したモデル」と「その実装を疑うモデル」を分ける。
この構成なら、Claude Codeの操作感、既存設定、Skills、MCP、プロジェクト資産を捨てずに、GPT-5.6の推論を必要な場所へ差し込める。
ClaudeをGPTへ変えるのではない。
Claude Codeの中に、いつでも相談できる別の上級エンジニアを住まわせる。
すべての仕事を一つのモデルへ依存させるより、作業内容に応じてモデルを使い分ける。
普段はClaude Codeで素早く進める。
難所ではGPT-5.6 Solへ救援を依頼する。
出荷前には別のモデルから敵対的レビューを受ける。
最新のOpenAI API仕様は、公式Docs MCPへ確認させる。
これからのClaude Codeは、一つのモデルで完結するコーディングツールではない。
複数のモデル、Skills、MCP、プラグインを束ねる開発OSとして使うのが正解だ。
