メインコンテンツへスキップ
見出し画像

Claude CodeとCodexを往復させると、経営判断はどこまで良くなるのか

    最近、Claude Codeについて「少しアホになったのではないか」という声をよく聞くようになりました。

    表現はかなり雑ですが、感覚としては分かります。
    私自身も、Opus 4.7を使っていて、以前よりもアウトプットの芯が弱くなったように感じる場面がありました。

    しかもこれは、設定を軽くしているからではありません。
    Opus 4.7では、常に `effortLevel` を `high` に設定しています。
    それでも、以前より一発目の出力が浅い。論点の踏み込みが弱い。前提の置き方が甘い。

    画像
    Claude CodeとCodexの往復の様子

    前提として、普段のClaude Code活用スタイルは、以下の通りです。

    • 構成:経営ドキュメントを目的別フォルダに体系化し格納されるルール化し、グローバル設定+永続メモリで文脈を蓄積

    • エージェント編成:領域別の専門参謀とスキル群を組み合わせ、依頼を自動実行。並列アウトプットとマージの自動化。

    • 外部連携:チャット・メール・カレンダー・ドライブ・録音ツール・利用SaaSをMCPで接続し、CLIから一気通貫でオペレーション

    • 常時アップデート:全会議録・人事・財務・KPIを自動取り込み→ダッシュボード用サイト再生成まで日次で回し、最新値で意思決定

    • 運用ルール:対話ファースト・実現可能性先行検証で、AIを経営OSとして運用

    このように定義設定や経営環境全般が把握できる設計にしていても、最近、アウトプットが悪くなったなと言う話しです。

    1つのAIに任せきらない

    今回もClaude CodeのOpus 4.7で、Agent Teamsを使い、6体で組成しているCxOチームをまず走らせる。

    この6つの視点で、原案そのものを並列評価させる。

    COOには、実行可能性を見てもらう。
    CFOには、収益性と投資対効果を見てもらう。
    CTOには、技術的な実現可能性を見てもらう。
    CMOには、市場でどう伝わるかを見てもらう。
    CPOには、プロダクトとして筋が通っているかを見てもらう。
    CHROには、組織・人材・変革負荷を見てもらう。

    つまり、Claude Codeにいきなり完成稿を書かせるのではなく、Claude Codeの中でまず「経営チームによる一次レビュー」を走らせる。
    これだけでも、体感値では品質が2倍くらい上がります。

    Claude Codeで作り、Codexで疑う

    そのうえで出てきた原案を、今度はCodexに渡す。
    Codexには、より冷静に、数字、前提、外部環境、論理の穴を見てもらう。

    この二段構えにすることで、Claude Codeのアウトプット品質に依存しすぎない形になります。

    だから、私はAIに「答え」を出させるよりも、AI同士に「疑わせる」使い方の方が重要だと思っています。

    Claude Codeが物語を作り、Codexが穴を開ける。
    この緊張関係が、かなり効きます。

    AI同士の往復で、論点が立体化する

    一度Codexでレビューしたら、それをまたClaude Codeに戻します。

    するとClaude Codeは、Codexの指摘を受けて、原案を再構成します。

    単なるアイデアだったものが、少しずつ事業案になっていく。

    誰に売るのか。
    最初の顧客セグメントはどこか。
    既存顧客に売るのか、新規顧客に売るのか。
    無料で試すのか、有料で始めるのか。
    プロダクト先行か、業務支援先行か。
    内製するのか、提携するのか。
    最初の90日で何を検証するのか。

    こういう論点が出てきます。

    そして最後に、もう一度Codexで締める。

    ここでは、細かい表現を直すというより、意思決定に必要な論点へ圧縮します。

    今決めること。
    まだ決めないこと。
    検証すべき仮説。
    失敗したと判断する条件。
    社内で巻き込むべき人。
    次の会議までに必要な材料。

    この状態までいくと、新規事業の議論がかなり前に進みます。

    体感値的には、5倍くらい良くなる感覚

    特に改善するのは、次の領域です。

    顧客課題の明確さ。
    収益モデルの現実性。
    実行体制の具体性。
    競合への見立て。
    初期検証の設計。
    撤退条件の明確化。

    逆に、AIだけでは最後まで決めきれない領域もあります。

    本当にやるのか。
    どのリスクを取るのか。
    誰に任せるのか。
    既存事業とどの程度カニバらせるのか。
    短期利益を犠牲にしてでも育てるのか。

    ここは人間が決めるべき領域です。

    3往復以上はやらない

    この使い方には注意点もあります。

    AI同士にレビューさせると、論点はいくらでも増えます。
    新規事業は特にそうです。

    市場の論点。
    顧客の論点。
    技術の論点。
    組織の論点。
    採用の論点。
    ブランドの論点。
    財務の論点。

    全部大事に見えてきます。

    しかし、論点が増えすぎると、仕事をしている感じは出るのに、意思決定からは遠ざかります。

    だから、ルールが必要です。

    通常は1往復。
    重要テーマだけ2往復。
    3往復以上は原則やらない。

    1回目で大きな穴を見つける。
    2回目で補強と反論を整理する。
    最後は人間が決める。

    これくらいがちょうどいい。

    実際のやり方は、かなりシンプル

    やっていること自体は、そこまで複雑ではありません。

    まずClaude Code側で原案を作ります。
    新規事業の構想、戦略メモ、会議後の論点整理、プロダクト案、組織設計案など、テーマは何でもいい。

    そのうえで、Claude Codeにこう言います。

    Codexレビューに回して

    するとClaude Codeは、レビュー対象を整理し、Codexが読むための依頼ファイルを作ります。

    私の場合は、`Inbox/CODEX_REVIEW_REQUEST.md` という固定ファイルを使っています。

    ここに、レビュー対象のファイル、作成意図、見てほしい観点、補足情報を書いてもらう。
    実際の画面では、Claude Codeが「Codexレビュー依頼を `Inbox/CODEX_REVIEW_REQUEST.md` に書きました」と返してきます。

    画像
    Claude CodeがCodexレビュー依頼を作成している画面

    つまり、Claude Code側ではこういう状態を作る。

    「この資料をCodexに見てもらってください」
    「見てほしい観点はこの5つです」
    「次にCodex側で、いつものレビューをお願いします、と言ってください」

    ここまでClaude Codeが整えてくれる。

    次にCodexを開きます。

    そして、こう言うだけです。

    いつものレビューをしてください

    するとCodexは、`Inbox/CODEX_REVIEW_REQUEST.md` を読み、そこに書かれている対象ファイルや関連資料を確認し、経営・事業・実行可能性・リスク・次アクションの観点でレビューします。

    この「いつものレビュー」という短い言葉が効きます。

    毎回、長い依頼文を書かなくていい。
    レビュー観点を毎回説明しなくていい。
    Claude CodeとCodexの間で、固定ファイルを介して文脈を受け渡せる。

    実際の画面では、こちらが「いつものレビューをしてください」と言うだけで、Codexが結論からレビューを返してくれます。

    画像
    Codexにいつものレビューを依頼し、レビュー結果が返っている画面

    これだけで、AI同士の往復がかなり実務的になります。

    逆向きに回すこともできる

    Codexでレビューしたあと、今度はClaude Codeに戻すこともできます。

    Codex側でこう言います。

    Claudeレビューに回して

    するとCodexは、Claude Codeが読むための依頼ファイルを作ります。

    私の場合は、`Inbox/CLAUDE_REVIEW_REQUEST.md` を使っています。

    実際の画面でも、Codexが「Claudeレビューに回せる形にしました」と返し、`CLAUDE_REVIEW_REQUEST.md` とレビュー本文を保存しています。

    画像
    CodexがClaudeレビュー用の依頼ファイルを作成している画面


    Claude Code側では、またこう言うだけです。

    いつものレビューをしてください

    するとClaude Codeは、`Inbox/CLAUDE_REVIEW_REQUEST.md` を読み、Codexの指摘に対して再レビューします。

    この往復で、次のような流れができます。

    1. Claude Codeで原案を作る

    2. Claude Codeに「Codexレビューに回して」と言う

    3. Codexで「いつものレビューをしてください」と言う

    4. Codexがレビューする

    5. Codexに「Claudeレビューに回して」と言う

    6. Claude Codeで「いつものレビューをしてください」と言う

    7. Claude Codeが再レビューする

    8. 必要なら最後にCodexでもう一度締める

    こう書くと長く見えますが、実際の操作はかなり軽いです。

    こちらが打つ言葉は、ほぼこれだけです。

    Codexレビューに回して
    いつものレビューをしてください
    Claudeレビューに回して
    いつものレビューをしてください

    この4つの短い指示で、AI同士の相互レビューが回ります。

    固定ファイルを使うのがポイント

    この運用で大事なのは、チャットだけで受け渡ししないことです。

    チャットの文脈だけに頼ると、どのファイルを見ればいいのか、何をレビューすればいいのかが曖昧になります。
    前回のやりとりが長くなると、AI側も焦点を外しやすい。

    そこで、固定ファイルを使う。

    Claude CodeからCodexに渡すときは、

    `Inbox/CODEX_REVIEW_REQUEST.md`

    CodexからClaude Codeに戻すときは、

    `Inbox/CLAUDE_REVIEW_REQUEST.md`

    この2つを使う。

    このファイルに、レビュー対象、レビュー観点、補足、次に実行してほしい依頼文を書いておく。
    そうすると、AI同士が直接つながっていなくても、共有メモを介してレビューを回せます。

    これはかなり重要です。

    AI同士をなんとなく会話させるのではなく、業務フローにする。
    依頼書を作り、レビュー対象を明示し、観点を固定する。
    そのうえで、別のAIに読ませる。

    人間同士のレビュー依頼と同じです。

    むしろ、AI相手だからこそ、依頼ファイルを固定した方が安定します。

    最後は、人間が決める

    ただし、この仕組みはAIに決めさせるためのものではありません。

    むしろ逆です。

    AI同士に往復させることで、最後に人間が決めるべき論点をはっきりさせるためのものです。

    やるべきか、やらないべきか。
    どのリスクを取るのか。
    どの顧客から始めるのか。
    どの言葉を使うのか。
    どこまで社内で進め、どこから外に出すのか。

    ここは人間が決める。

    Claude Codeで広げる。
    Agent Teamsで経営会議化する。
    Codexで疑う。
    Claude Codeで再構成する。
    Codexで意思決定論点に圧縮する。

    この流れは、単なるAI活用テクニックではありません。
    曖昧な構想を、判断できる形に変えていくための作法です。

    AIで業務効率化を図るのではなく、AI前提で経営の再定義をしているのです。

     
     
    メイクショップ社創業後、GMOインターネットグループへジョイン。 makeshopは法人12,000店舗、流通総額3,300億円で日本No.1のネットショップ構築SaaSに成長。 専門はEコマース。韓国語が得意。エンジェル投資数社。ドライブ/グルメ/旅行/子育て/B型次男