この記事の対象読者と得られること
| 対象読者 | この記事で得られること |
|---|---|
| Claude Code を日常運用している方 | もう一段品質を上げるセカンドオピニオン運用 |
| AI コード生成の見落としに悩む方 | sycophancy bias を構造で断つ仕組み |
| 認証・権限系の設計をする方 | adversarial-review の具体活用例 |
はじめに
AI が書いたコードを、同じ AI にレビューさせたことはないでしょうか。
筆者は正直なところ、しばらくそのやり方を続けていました。Claude Code に実装させて、そのまま同じセッションで「レビューして」と頼む運用です。パッと見は問題なく回りますし、指摘も返ってきます。ただ、あるときから「この AI、自分が書いたコードに甘くないか」という疑念が拭えなくなりました。
そうした中で 2026 年 3 月 31 日に、OpenAI が Anthropic の Claude Code 向けに公式プラグイン codex-plugin-cc を発表しました。これは Claude Code のセッションから Codex を呼び出し、第三者視点のレビューを得るための公式経路です。ライバル関係にある両社が手を組んだ形で、AI コード生成界隈ではかなり話題になりました。
本記事では、この codex-plugin-cc を使って「sycophancy bias（追従バイアス）」を構造的に断ち切るセカンドオピニオン駆動開発を紹介します。筆者が実際に運用してみて感じた効能と、やらかしかけた事故の話も添えていきます。
本記事の検証環境は Claude Code v2.1.x、codex-plugin-cc の 2026 年 4 月時点のバージョンです。将来のアップデートで挙動やコマンド名が変わるケースもありますので、最新のリポジトリも併せてご確認ください。
背景: なぜこのプラグインが生まれたのか
なぜ OpenAI が競合向けプラグインを出したのか
codex-plugin-cc の公開は 2026 年 3 月 31 日です。OpenAI の公式ブログに短いアナウンスが載り、同日中に GitHub リポジトリが公開される形で展開されました。Anthropic 側からも Claude Code 公式アカウントがリポジトリへの参照を添えて歓迎する投稿をしており、発表は両社の協調的なトーンで行われています。
競合関係にある 2 社の公式連携には違和感を覚える方もいると思います。筆者も第一報を見たときは「マーケティング的なジョークでは」と疑いました。ただ、背景を追っていくと、これは単発の友好イベントではなく、2024 年以降の連続的な相互乗り入れの延長線上にある動きだと捉えられそうです。時系列を雑に並べると、2024 年の Claude Code 登場、2025 年の Codex CLI のオープンソース化、同年の Claude SDK の外部公開、そして OpenAI Agents SDK が Claude Code 互換レイヤを取り込む流れ、と段階的に橋が架かってきた経緯があります。
技術面の背景としては、マルチモデルレビューの有効性を示す研究群があります。self-consistency（Wang et al., 2022）が単一モデル内の多数サンプリングで精度を押し上げる話を扱ったのに対し、近年は異なるモデル同士をアンサンブルする検証も広がっており、コード生成・コードレビューの文脈でも「別モデルの指摘は重複が少ない」という報告が繰り返されています。筆者の実測値（後述）でも、重複は 1 割程度という印象で、研究側の主張と齟齬がありません。
もう一つ無視できないのが sycophancy bias（追従バイアス）研究の蓄積です。Anthropic の Constitutional AI 系の論文群や、OpenAI の instruction tuning 研究で、RLHF を経たモデルはユーザーの意図を過剰に肯定しやすい性質が一貫して報告されています。同一モデル・同一セッションでのセルフレビューが甘くなる実感は、このバイアスの帰結として説明しやすいです。つまり codex-plugin-cc は「研究領域で指摘されてきた構造的な弱点を、運用側で断ち切る道具」として理解できる、というのが筆者の位置づけです。
業界構造の観点では、2026 年春の状況は「呉越同舟」と形容されます。モデル開発競争は依然激しいのですが、エージェント基盤やプラグインの相互運用は協調しないとユーザーが離れる、という合意が形成されつつあるように見えます。Codex CLI は Claude Code のプラグインとしても呼べるし、逆に Claude Code Action は OpenAI Agents SDK からも叩ける。下位レイヤで繋がっていれば、上位の UX 競争は健全化するという読みだと筆者は受け止めています。
マルチ AI レビュー市場の広がり
codex-plugin-cc はゼロから生まれた発想ではありません。コミュニティ発のプラグインやスキルが先行して存在しており、そこに公式版が重なった、と捉えるのが実情に近いです。
先行例としてよく参照されるのが hamelsmu/claude-review-loop です。Claude Code のセッション内で別プロバイダのモデルにレビュー往復をさせるループを構築する試みで、sycophancy 対策としての着眼点は codex-plugin-cc と共通しています。また cathrynlavery/codex-skill は Claude Code のスキル機構から Codex を呼ぶシンプルな実装で、公式化前から多くの運用者が類似パターンを踏んでいました。こうした草の根の蓄積がベースラインを作り、公式プラグインはその上にプロンプト規約やメンテナンスの保証を載せた、という構図に筆者は見えています。
公式プラグイン化の意味は、機能面より信頼面が大きいと考えています。非公式ラッパーだと「Codex の仕様変更で壊れる」「プロンプトの質がメンテナ依存」というリスクが残りますが、OpenAI 側がプロンプトと CLI 呼び出しを継続メンテするなら、業務運用に載せやすくなります。逆に言うと、公式化以前は「個人の検証用」に留まっていた構成が、チームの標準運用に持ち込みやすくなった、という段差を感じます。
単一モデル運用との対比も押さえておきたいところです。Cursor や Aider といった支援ツールは、単一モデル（またはユーザーが選んだ単一モデル）で完結する UX を追求しており、完成度の高い体験を提供しています。ただし sycophancy の構造問題はそのままで、「書き手と採点者が同じ」状態の解決はユーザー側に委ねられています。codex-plugin-cc のような公式マルチモデル経路は、この構造問題に正面から答える選択肢の一つだと整理できます。
2026 年春には、この潮流を指して「指揮者 AI」と呼ぶ論が Addy Osmani の "Code Agent Orchestra" で提示されています。複数のエージェントがそれぞれの得意領域を担当し、開発者は指揮者のように役割を割り振る、という比喩です。実装・レビュー・テスト・デプロイをそれぞれ別モデルに任せるような発想の延長で、codex-plugin-cc は「書き手と採点者を分ける」という最小単位の指揮者モデルに相当します。もっとも、指揮者モデルが常に優れているとは限らず、単一モデルでの一貫性を重視する場面もあるので、チームの性質で使い分けるのが現実的です。
なぜ「同じ AI に採点させる」は危ういのか
sycophancy bias という構造問題
LLM には、ユーザーの意図や文脈に過剰に同調しやすい傾向があります。これは sycophancy（お世辞、追従）と呼ばれ、近年の評価研究でも一貫して報告されています。
同じモデル・同じセッション内で「書いたコードをレビューして」と頼むと、レビュワー役のモデルは直前の実装意図を強く引きずります。結果として、実装時点では見えていなかった前提の歪みや、設計判断そのものへの疑念が出てきにくいのです。
筆者の体感では、特に次のような領域で見落としが増える印象があります。
- 認証・認可のフロー設計
- 権限境界（テナント分離、RLS、スコープ）
- 例外パスのセキュリティ
- 入力バリデーションの網羅性
これらは「実装者の頭の中の地図」に依存しやすく、同じ地図を持つレビュワーからは死角になりがちな領域です。
「別の地図」を持ち込む
この構造を崩す素直な方法は、別の訓練データ・別の設計思想のモデルに見せることです。Claude が書いたコードを Codex に見せれば、少なくとも訓練データとアライメント戦略が異なる視点が入ります。
ただ従来は、これを手動でやるのが面倒でした。コードをコピペして別ツールに貼り、結果をまた戻す。そこを公式に橋渡しするのが codex-plugin-cc です。
codex-plugin-cc とは何か
2026 年 3 月 31 日の公式発表
codex-plugin-cc は、OpenAI が Claude Code 向けに公開した公式プラグインです。2026 年 3 月 31 日にリポジトリが公開され、Claude Code のプラグイン機構に載る形で配布されています。
ポイントは、これが非公式のラッパーではなく OpenAI 公式のプラグインである点です。Codex CLI の呼び出しやプロンプト規約は OpenAI 側でメンテされるため、Codex のバージョンアップに追随しやすい設計になっています。
中核となる 2 つのコマンド
codex-plugin-cc は複数のスラッシュコマンドを提供していますが、レビュー用途で中核となるのは次の 2 つです。
| コマンド | 役割 | 主な用途 |
|---|---|---|
/codex:review |
通常レビュー。実装の品質・保守性・バグを指摘 | 一般的な PR レビュー、リファクタ後の確認 |
/codex:adversarial-review |
対立レビュー。実装に疑念を投げる役割を Codex に与える | 認証・権限・セキュリティ・破壊的変更 |
adversarial-review は「実装が正しい前提」を崩すよう指示されたプロンプト設計になっており、Codex が積極的に抜け穴を探します。通常のレビューよりも攻めた指摘が返ってくる一方、誤検知も増えるトレードオフがあります。
上記 2 つ以外にも、/codex:rescue（行き詰まり時の脱出支援）、/codex:status（実行中タスクの状況確認）、/codex:result（直近の結果再表示）、/codex:cancel（実行中タスクのキャンセル）、/codex:setup（初期セットアップ補助）などのコマンドが用意されており、状況に応じて使い分けます。本記事ではレビュー運用に絞って扱いますが、実運用では status や cancel のような補助系コマンドも地味に効いてきます。
インストール
インストールは Claude Code のプラグインマーケットプレイス経由で 1 行です。
/plugin marketplace add openai/codex-plugin-cc
追加後は /plugin install codex-plugin-cc のような手順で有効化します。環境によっては Codex CLI 本体と API キーの設定が前提になりますので、リポジトリの README を先に確認してください。
API キーはシェル環境変数や .env に平文で置かれるケースが多いので、後述の事故談のとおり、キーのスコープと有効期限には注意してください。最小権限・短期限のキーに分けておくと安全です。
/codex:review と /codex:adversarial-review の違い
両コマンドの違いを、筆者が認証周りの実装を流したときの感触で整理します。
review の返し方
/codex:review は、実装が「おおむね正しい」前提で、改善提案を出してくる印象です。命名、重複、テストカバレッジの不足、ロギングの粒度など、読み手として気になる点が中心になります。
- `validateToken` の早期 return が冗長です。`!token` で統合できます。
- リフレッシュトークンのローテーション後のログが INFO レベルですが、監査用途なら監査ログ経路にも出すべきです。
- テストで期限切れトークンのケースが欠けています。
このあたりは「品質を底上げする」タイプの指摘です。
adversarial-review の返し方
一方 /codex:adversarial-review は、実装の前提を崩しにかかります。
- `iss` と `aud` の検証が署名検証の後に行われています。
別テナントの鍵でも、同じ鍵 ID を名乗られると攻撃面が残る可能性があります。
- トークン失効リストの参照が best-effort になっており、ストア障害時に fail-open しています。
認証系の fail-open はポリシー違反のケースが多いです。
- リフレッシュトークンの再利用検知がありません。
盗難時に元のユーザーと攻撃者の両方が使えてしまう状態を許します。
指摘の粒度が一段深く、「正しく動いていても、敵対的な入力で壊れないか」という視点に寄っています。もちろん、全部が正鵠を射ているわけではなく、誤検知や過剰な懸念も混ざります。採用するかどうかは実装者が判断する前提です。
ExitPlanMode と連動させる settings.json 例
Claude Code には Plan モードの承認前後にフックを差し込む仕組みがあります。筆者の環境では、Plan 承認の直前に /codex:adversarial-review を自動で走らせる運用を試しています。
{
"hooks": {
"PreToolUse": [
{
"matcher": "ExitPlanMode",
"hooks": [
{
"type": "command",
"command": "echo 'Plan 承認前に /codex:adversarial-review を推奨します'"
}
]
}
]
}
}
これは実質的にリマインダですが、設計レベルの判断ミスを実装前に捕まえる狙いです。プランを文章として書き出した段階で対立レビューを挟むと、実装してから剥がすより手戻りが小さくなります。
フックの具体的な条件やコマンド名は Claude Code のバージョンで差があります。PreToolUse の matcher や PostToolUse の扱いはリリースノートを確認のうえ調整してください。
筆者環境での実測ケース
仮想プロジェクト example-auth-api で、JWT ベースの認証設計を Claude Opus に実装させ、同じコードに対して Opus 自身と Codex にレビューを依頼した結果を並べます。数字はあくまで筆者の 1 ケースの観測で、網羅的なベンチマークではありません。
| レビュワー | 指摘件数 | うち重大（認証・権限） | 重複 |
|---|---|---|---|
| Claude Opus（同一セッション） | 8 | 2 | - |
Codex /codex:adversarial-review
|
4 | 3 | 1（Opus と重複） |
Opus 側は品質系の指摘が多く、Codex 側は件数こそ少ないものの、認証フローの fail-open と iss/aud 検証順序という、運用上インパクトの大きい指摘が入りました。重複は 1 件で、残り 3 件は Opus からは出ていない指摘でした。
このケースだけで「Codex のほうが優秀」と断じるつもりはありません。逆のパターンも普通にありますし、題材によって得意・不得意はあります。ただ「別モデルを通すと、別の層の指摘が拾える」という主張は、筆者の手元では繰り返し再現しています。
事故談: API キーのシェル継承で月額が跳ねた話
便利さと引き換えに、きちんと触れておきたい失敗談があります。
Codex を呼ぶ以上、OpenAI の API キーが必要です。筆者は当初、常用シェルに OPENAI_API_KEY をエクスポートしっぱなしにしていました。Claude Code から codex-plugin-cc 経由で走る Codex も、そのキーをそのまま継承します。
問題は、別の自作スクリプトが開発中のループでそのキーを参照し、想定外の頻度で高価なモデルを叩いていたことです。気づいたときには想定の数十倍の課金が発生していて、筆者の環境では月額換算で約 $1,800 分に達してから停止しました。
原因は筆者のスクリプト側にありましたが、キーのスコープを切っていれば被害は限定できました。再発防止として以下に変えています。
- Codex 用 API キーを
codex-plugin-cc専用で発行し、利用枠と有効期限を絞る - 常用シェルでは
OPENAI_API_KEYを export しない。direnv などでディレクトリ単位に閉じる - OpenAI 側の課金アラートを「想定値の 1.5 倍」で設定する
- Claude Code 側の環境変数を
.mcp.jsonや設定ファイル経由に寄せ、シェルからの継承を減らす
# 常用シェルには置かず、作業ディレクトリの .envrc に閉じる例
# .envrc
export OPENAI_API_KEY="sk-proj-..." # codex-plugin-cc 専用キー
export OPENAI_ORG_ID="org-..."
API キーの扱いは、便利さより安全側に倒してください。特に Claude Code のようにサブプロセスを多段で呼び出すツールでは、どの層までキーが継承されるかを把握しておくことが大事です。
使い分けガイド
運用していて落ち着いてきた使い分けは、だいたい以下のような感じです。絶対解ではないので、プロジェクトの性質に合わせて調整してください。
通常レビュー (/codex:review) を使う場面
- リファクタ後の品質確認
- 命名・責務分離・重複の指摘が欲しいとき
- テストカバレッジの穴を見つけたいとき
- 一般的な PR レビューのサブオピニオン
対立レビュー (/codex:adversarial-review) を使う場面
- 認証・認可・セッション管理の設計
- 権限境界（マルチテナント、RLS、スコープ）
- 入力バリデーションと例外パスのセキュリティ
- 金銭・課金・決済のロジック
- 破壊的マイグレーションの事前確認
対立レビューは精神的コストも計算コストもやや高いので、全 PR に効かせるより「ここは外したくない」という領域に絞るのが筆者のおすすめです。
チェックリスト
- 実装前に Plan を文章化している
- Plan 承認前に対立レビューを一度通している
- 認証・権限・課金のコードは対立レビューを必須にしている
- API キーは専用発行・スコープ分離されている
- 月額アラートを設定している
他のレビュー手段との比較
codex-plugin-cc は便利な選択肢ですが、唯一解ではありません。手元で実際に試したり、チームで議論したりする中で「どの場面でどれを選ぶか」が少しずつ整理できてきたので、その現時点での理解をまとめておきます。
レビュー手段 4 種の比較
比較対象は、筆者が現場で触れている 4 種類です。公式プラグインの codex-plugin-cc、Claude Code 向けのコミュニティ資産 superpowers review、プロジェクト固有で書く自作 hook、そして古典的な人手レビューです。
| 軸 | codex-plugin-cc | superpowers review | 自作 hook | 人手レビュー |
|---|---|---|---|---|
| 導入コスト | 1 コマンド | 中（設定多め） | 高 | ゼロ |
| モデル独立性 | 高（Codex 使用） | 低（同 Claude） | 設定依存 | 最高 |
| 対立レビュー | ○ adversarial | × | 設計次第 | 人による |
| コスト/PR | $0.3〜1 | $0.1〜0.5 | $0.1〜 | 人件費 |
| 検出精度（認証系） | 実測 4 件 | 実測 2 件 | 実装次第 | 実測 8 件 |
数字は筆者の 1 ケースの観測で、題材とプロンプト次第で大きく動きます。モデル独立性の欄は「書き手モデルと異なる視点が入るか」という意味で、superpowers review は Claude 系の連携が中心になるため低めの評価にしています。人手レビューは正味の時間コストが乗る代わりに、仕様解釈やビジネスロジックの妥当性まで踏み込める強みがあります。
codex-plugin-cc と superpowers review は排他ではありません。筆者は「型安全性や命名の底上げは superpowers」「境界条件の殴り合いは codex-plugin-cc」という棲み分けで併用しています。自作 hook は万能に見えて、メンテ負荷が馬鹿にならないので、独自 DSL や社内ルールに特化する場合に絞るのが無難そうです。
どのレビュー手段を使うか
判断基準をマトリクス化すると、以下のような目安に落ち着きます。絶対解ではなく、プロジェクトの性質で入れ替わる前提のものです。
- codex-plugin-cc: 認証・権限・セキュリティ系の PR。fail-open のような運用事故に直結する領域では、異モデルでもう一枚ふるいをかける効果が大きいと感じます。
- superpowers review: 型安全性・lint レベルの指摘、命名や構造のリファクタ提案。同モデル内で一貫した文体の指摘が得やすく、量で攻めるのに向きます。
- 自作 hook: 特定 DSL、社内命名規約、マイグレーション禁止ルールなど、汎用モデルではルールを再現しづらい検証。LLM を噛ませずに決定的にチェックできる場面で特に効きます。
- 人手に戻すべき領域: ビジネスロジックの妥当性、仕様解釈、顧客影響の評価。ここを AI に丸投げするのは、現時点では筋が悪いと筆者は考えています。
並行運用も普通に成立します。筆者の環境では、軽い PR は superpowers review だけ、認証や課金が絡む PR は codex-plugin-cc の /codex:adversarial-review を追加、最終ゲートで人手、という三段構えを試しています。全 PR に全手段を当てるのは過剰なので、リスクに応じて配分を変える運用が現実的です。
異モデルレビューが効く理由
異モデルレビューの効きどころは、指摘の「層」が重ならないことにあります。筆者の観測では、Opus と Codex で指摘内容が重複するのは 1 割程度で、残り 9 割は互いに補完的でした。これは研究側のアンサンブル手法の報告とも整合的で、「同じ訓練データ・同じアライメント戦略を共有しないこと」そのものが補完性の源泉になっている、という見立てが自然です。
コスト面の話も見ておきます。codex-plugin-cc の実測単価は PR あたり $0.3〜1 程度で、小さな機能なら $0.3 未満、認証周りの長文 PR でも $1 を超えることは稀でした。本番で認証系の事故を 1 件起こせば、ポストモーテム・顧客対応・開発停止を合算して数十万円オーダーのコストが飛びます。確率論的に見ても、異モデルレビューの導入コストは十分回収可能な水準だと筆者は判断しています。ただしチームや事業規模で損益分岐は動くので、断定はしません。
一方で、adversarial モードには過剰検出のリスクがあります。「攻撃者視点」を前面に出すため、実運用ではオーバースペックな指摘が混ざります。たとえば公開予定の静的サイト向けコードに対して、マルチテナント分離のような指摘が入るケースもあり、そのまま受け入れると無駄な実装コストになります。Codex の指摘を「採否の最終判断は人間」に置いておくのが安全で、筆者はレビュー結果を 3 段階（Must / Should / Nice to have）にラベルし直す運用で折り合いをつけています。
異モデルレビューを過信しない姿勢も大事です。Codex が見逃す領域は当然あり、特にドメイン知識や顧客仕様の解釈は弱いです。異モデルレビューはバグ検出の一層であって、仕様・要件の妥当性検証ではない、と切り分けておくと使いやすくなります。
まとめ
codex-plugin-cc の本質は、「同じ AI に書かせて同じ AI に採点させる」構造を、仕組みとして崩せるようになったことだと筆者は捉えています。
sycophancy bias をプロンプト工夫で個別に回避するのは骨が折れますが、別モデルを公式経路で呼び込めるなら、日常運用に組み込める現実味が出てきます。特に /codex:adversarial-review は、認証や権限のように「実装者の地図」から漏れがちな領域で効いてきました。
もちろん、Codex の指摘がいつも正しいわけではありませんし、Claude 側のほうが文脈を深く拾えるケースも普通にあります。両者を併用しつつ、最後に判断するのは実装者自身、というスタンスが扱いやすいと感じています。
「AI にレビューさせる」ではなく、「別の AI に対立視点を持たせる」。この一手間を挟めるかどうかで、見えるバグの層が変わる、というのが筆者の現時点の実感です。気になった方は、まずは小さな機能から /codex:adversarial-review を挟んでみてください。
参考リンク
- openai/codex-plugin-cc リポジトリ（GitHub）
- MindStudio: OpenAI Codex Plugin for Claude Code — Cross-Provider Review の解説記事
- Mejba.me: codex-plugin-cc の adversarial-review を深掘りした記事
- LittleMight: Claude Code のセカンドオピニオンとして Codex Skill を使う実践記事
- Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models"（arXiv:2203.11171）
- Anthropic: "Towards Understanding Sycophancy in Language Models"（追従バイアスの分析）
- hamelsmu/claude-review-loop（コミュニティ発のマルチモデルレビュー実装）
- Addy Osmani: "Code Agent Orchestra"（指揮者 AI 論の整理）