1つのオーケストレーター、3つのCLI: CodexとGeminiへのタスク委譲は本当にClaudeのトークン節約になるのか？

2026年の多くの開発者と同様に、私は結局同じマシンに3つのAIコーディングCLIをインストールすることになり、それぞれが異なる理由でその地位を確立しました:

• Claude Code — オーケストレーターレベルのエージェント。複数ステップの推論、アーキテクチャ、デバッグ、大規模なコードベースでの作業に最適です。また、私が最もトークンを気にするものでもあります。
• OpenAI Codex CLI — 有能なコーディングエージェントで、正確な仕様を持つ、スコープが明確で自己完結型のタスクを任せるのに優れています。
• Google Gemini CLI — マルチモーダルな働き者。画像生成、オーディオとTTS、文字起こし、そして特に地域言語向けの高品質な翻訳が可能です。

ある時点で明白な疑問が浮かびます。3つの中で最も賢いものは、1日中動かすには最も高価でもあります。では、それをこうすることはできるでしょうか マネージャー？ Claudeにタスクを与え、作業を分割し、CodexとGeminiに割り当て、完了したらマークダウンファイルで報告させる — 一方でClaudeは、難しい部分と最終レビューにのみトークンを消費するということは可能でしょうか？

私は現在、このパターンを数週間の実際の作業（マーケティングサイトの全面的な再設計、AI生成のヒーロー画像群、8言語への翻訳、ユーティリティスクリプト、大量のコンテンツ作業）で運用しています。この記事は完全なプレイブックです。パターンがどのように機能するか、私が使用している正確なプロンプトの形、誠実さを保つためのレポートの規約、本当に節約できる場所、そして全体として価値があるかどうかを決定づける2つの隠れたコストについて解説します。

短い答え: はい、このパターンは機能し、節約は本物です — ただし、適切に引き継ぎを設計した場合に限ります。 長い答えは以下のすべてです。

まず、実際に何にお金を払っているのかを理解する

戦略が意味を持つ前に、エージェントCLIセッションでトークンがどこに消費されるのかを明確に把握する必要があります。大まかに言って4つのバケツがあります:

1. 入力トークン — モデルが読み取るすべてのもの: プロンプト、ファイルの内容、ツールの出力、過去の会話。長時間のコーディングセッションでは、エージェントが毎ターンコンテキストを再読み込みするため、これが他のすべてを圧倒します。
2. 出力トークン — モデルが書き出すすべてのもの: コード、文章、ツール呼び出し。通常、入力よりも高いレートで請求されます。
3. 再読み込み — 静かな殺し屋。エージェントが「ちょっと確認するため」に1,000行のファイルを開くたびに、その1,000行に対して再び入力として料金を支払うことになります。
4. 手戻り — 複合的な殺し屋。誤解されたタスクは、最初の試行、それを発見するレビュー、そして2回目の試行のコストをあなたに課します。

委譲はバケツの1と2を攻撃します: サブエージェントの生成は 自身の 請求（別のサブスクリプション、より安価なモデル、または無料枠）で行われ、オーケストレーターはコンパクトな要約だけを読み取ります。しかし、委譲がうまく行われないと、 膨張します バケツの3と4が — そしてそれがこの記事の最大の焦点です。

オーケストレーターパターン、適切な定義

最もシンプルな形でのアーキテクチャは次のとおりです:

            ┌─────────────────────────┐
            │   YOU (one instruction)  │
            └───────────┬─────────────┘
                        ▼
            ┌─────────────────────────┐
            │  CLAUDE (orchestrator)   │
            │  plans · splits · specs  │
            │  reviews · integrates    │
            └─────┬──────────────┬────┘
        spec + exact output path │
              ▼                  ▼
   ┌─────────────────┐  ┌─────────────────┐
   │  CODEX (coder)   │  │ GEMINI (media)   │
   │ scoped modules,  │  │ images, audio,   │
   │ tests, boiler-   │  │ translation      │
   │ plate, scripts   │  │                  │
   └────────┬────────┘  └────────┬────────┘
            │  artifacts → disk   │
            │  report.md (≤40 ln) │
            ▼                     ▼
            ┌─────────────────────────┐
            │  CLAUDE reads reports,   │
            │  verifies, fixes/retries │
            │  or integrates & ships   │
            └─────────────────────────┘

オーケストレーターは4つのものを所有し、 ただ 4つのものだけを所有します: 計画、 仕様、 レビュー、そして 統合です。かさばる機械的なものはすべて下に押しやられ、2つの譲れないルールがあります:

ルール1 — アーティファクトは正確なパスでディスクに保存される。 サブエージェントは出力を会話に貼り付けることは決してありません。ファイルに書き込みます。オーケストレーターのコンテキストはクリーンなままです。

ルール2 — 返信はほとんど何もない。 理想的には1つの単語と短いマークダウンレポートです。レポートは、オーケストレーターが確実に読む 唯一の ものです。

この記事から他に何も覚えていなくても: 委譲プロンプトとレポートこそが、オーケストレーターが委譲されたタスクでトークンを消費する唯一の2つの場所です。 それ以外はすべて他の誰かの請求になります。あなたの最適化の対象全体が、この2つのドキュメントなのです。

ウォークスルー #1: 画像生成をGeminiに委譲する

オーケストレーターは文字通りそれができない（Claude Codeの背後には画像モデルがない）ため、これは私が実行する中で最も価値の高い委譲です。ClaudeがGemini CLIに記述して送信するプロンプトの実際の形は次のとおりです:

Generate a single photorealistic editorial corporate portrait.
Concept: <detailed art direction — subject, pose, wardrobe,
lighting, background, composition>.

CRITICAL: the entire subject must be fully inside the frame with
generous margin on all sides — do not crop arms or held objects.
Plain seamless light-grey studio background for easy cutout.
No text, no watermark, no logos, no props.

Save the image to /tmp/work/hero-cyber.png (overwrite if it exists).
Then reply only DONE.

このプロンプトにおけるエンジニアリングに注目してください:

• 出力パスが正確である。 「どこかに保存して」ではありません — オーケストレーターはどこを見ればよいか正確に知っているため、やり取りの無駄はゼロです。
• "DONEのみ返信してください。" Gemini CLIは喜んで400トークンを費やしてその制作過程を語るでしょう。私たちはそれを望んでいません。一言で十分です。
• 制約は機械的に明記される （「フレーム内に完全に収める」、「透かしなし」）。なぜなら、あなたが書か ない すべての制約が、手戻りルーレットを回すことになるからです。私はこれらの行をそれぞれ失敗から学びました — 詳しくは後述します。

次にオーケストレーターは 品質ゲート を、画像を見る前に実行します — 安価で機械的なチェックです:

# does the file exist and is it non-trivial?
test -s /tmp/work/hero-cyber.png || echo "FAILED: missing/empty"

# entropy gate: catches blank/placeholder images without
# spending any model tokens at all
python3 -c "
from PIL import Image; import sys
img = Image.open('/tmp/work/hero-cyber.png')
# a flat placeholder has near-zero entropy; a real photo is > 4
print(img.entropy())
"

ゲートを通過した後にのみ、オーケストレーターは実際に画像を1回 表示して （単一のビジョン呼び出し）、スクリプトでは確認できないこと（構図、アーティファクト、ブランドセーフティ）をチェックします。これがオーケストレーター側の全トークンコストです: 短いプロンプト1つの送信、1単語の返信、1回の画像表示。

これらをバックグラウンドで実行する。 画像ジョブには1〜5分かかります。ブロックして待つということは、オーケストレーターがコンテキスト全体をメモリに保持したままアイドル状態になることを意味します。ジョブを開始し、他の作業を続け、ファイルが届いたときに戻ってきましょう。今や本格的なエージェントCLIはすべてバックグラウンド実行をサポートしています。それを活用してください。

ウォークスルー #2: コーディングタスクをCodexに委譲する

コーディングの委譲はよりトリッキーです。なぜなら、失敗のモードは一目でわかる悪い画像ではなく、コードベースに合わないもっともらしいコードだからです。解決策は、「完了」が機械的にチェック可能なほど厳密な仕様にすることです:

TASK: Write a standalone Node script at scripts/import-legacy.mjs

SPEC:
- Reads ./data/legacy-export.csv (papaparse is already a dependency)
- Maps columns per the table below … (exact mapping)
- Writes ./data/import-ready.json, an array of objects
- Node 22, ESM, no new dependencies
- Handle: missing fields → skip row + count; duplicate IDs → last wins

ACCEPTANCE (all must pass):
- node scripts/import-legacy.mjs runs clean on the sample file
- node --test tests/import-legacy.test.mjs passes (write these tests)
- npx eslint scripts/import-legacy.mjs → zero errors

REPORT: write REPORT-import.md (max 40 lines) with status, files
created, how to verify, and up to 5 gotchas. Do not paste file
contents into the report.

ほとんどのコーディングタスクが委譲できない中で、これを委譲可能にする3つの特性があります:

1. 自己完結型 — 1つの新しいファイル、既存モジュールへの編集なし、アーキテクチャ上の決定なし。
2. 機械的にチェック可能な受け入れ基準 — オーケストレーターはコードを一行ずつ読むのではなく、3つのコマンドで検証します。
3. 境界のあるインターフェース — 入力ファイル、出力ファイル、それで終わり。サブエージェントはコードベースの他の部分にさまようことはできません。

レポートが届くと、オーケストレーターは受け入れコマンドを実行し（安価）、注意点をざっと読み（安価）、何かが失敗するかおかしいと感じた場合にのみ実際のコードを開きます。クリーンパスの場合、オーケストレーターは本来自分で書いていたであろう300行を決して読むことはありません — それが 節約なのです。

節約が本物である場所 — 大まかな計算とともに

1. 一括生成。 タスクが2,000行の出力（約25,000トークン）を生成するとします。直接行った場合、オーケストレーターは約25,000の出力トークンと、その周辺のすべてのコンテキスト読み込みコストを支払います。委譲した場合、オーケストレーターが支払うのは: 約300トークンの仕様、約400トークンのレポート読み込み、および数百トークンの検証コマンドです。これを 約30kに対して約1kのトークン と呼ぶと — 95%以上の削減になります。 そのタスクにおいて、生成自体はサブエージェントのクォータに請求されます。

2. どうせオーケストレーターにはできない作業。 私が最近出荷したすべての画像、すべてのオーディオファイル、8言語翻訳バッチのすべては、オーケストレーターが書いた仕様に基づいてGemini CLIによって生成されました。比較するClaudeネイティブの代替案はありません — これは純粋な機能の獲得であり、トークンコストは仕様＋レポートだけです。

3. 正確な仕様を伴う長い機械的な出力。 テストの足場作り、データ移行、ボイラープレートモジュール、フォーマット変換、アウトラインからのドキュメント草案。共通点は: 判断が少なく、量が多い。 量とはまさに出力トークンの価格であり、判断とはまさに安価なエージェントに欠けているものです。量を委譲し、判断を保持してください。

節約が消滅する場所 — 2つの税と1つのオーバーヘッド

検証税

これは誰も価格に織り込んでいないコストなので、私のプロジェクト（ウェブサイト用のAI生成ヒーローポートレートのバッチ）からのレシートをお見せしましょう:

• ある画像は 競合他社とわかるノートパソコンのロゴ が焼き付けられて戻ってきました。法的にもブランド的にも出荷不可能です。再生成 — いや待って、実際には パッチを当てて消去し 画像ツールで、それから再検証します。
• 別のセットには、 透明だと主張しているが実際にはそうではない 角がありました — 色付きの背景に対してのみ現れる、不透明な白に近い色です。遅れて発見され、塗りつぶしパスで修正し、再検証されました。
• 3つ目は、製品のタブレットが 半分フレーム外に生成されていました — モデルは、画像が表示するために存在しているまさにそのオブジェクトを切り取ってしまったのです。「すべてを完全にフレーム内に収める」という新しい制約行を追加して完全な再生成を行いました。

これらの画像はすべて 通過しました 安価な機械的ゲートを。それでも、すべてにおいてオーケストレーターが実際に見て、判断し、修正を指示する必要がありました。委譲はレビューステップをなくしたわけではありません — 生成コストを他の場所に移し、レビューコストをそのまま残したのです。

そして、委譲されたタスクがレビューに失敗した場合、あなたは支払うことになります 3倍を: 委譲、それを発見したレビュー、そしてやり直しです。同じタスクでの2回の委譲の失敗は、通常、オーケストレーターが最初から直接行うよりもコストがかかります。だからこそ、私の画像プロンプトのすべての制約行が傷跡のように読めるのです — それぞれが 本当に 傷跡なのです。

予算のルール: 委譲されたクリエイティブタスクの20〜30%に修正サイクルが必要であると想定し、それを決定の際に織り込んでください。 タスクの検証が安価な場合（テストの実行、ファイルの確認）、手戻りがあっても委譲の勝ちです。もし検証が「すべてを注意深く読む」ことを意味するなら、節約は幻想でした。

統合税

もしタスクが多くのファイルに触れる場合、コードベースの規約に一致しなければならない場合、あるいはオーケストレーターの頭の中にあるコンテキスト（アーキテクチャの決定、モジュール間のリファクタリング、競合状態のデバッグ）に依存する場合、それを引き渡すことは見せかけの節約です。サブエージェントはあなたのコンテキストを持っていません。安全に統合するためだけに、オーケストレーターは結局サブエージェントが触れたすべてを再読み込みすることになります。同じ理解のために2回支払ったことになります: サブエージェントが独自の部分的な全体像を構築するために1回、オーケストレーターが完全な全体像を再構築するために1回です。

兆候はシンプルです: 仕様を書くためにアーキテクチャの説明が必要な場合は、タスクを委譲しないでください。 仕様の作成だけでも節約分よりコストがかかり、誤解のリスクも甚大です。

オーバーヘッドの底

良い委譲プロンプトを書くには200〜400トークンかかります。レポートを読むには300〜500かかります。検証にもさらに数百かかります。したがって、底辺が存在します: タスクの直接コストが約1,000〜2,000トークン（約50〜100行の出力）を下回る場合、委譲すると毎回損をします。 ただ自分でやってください。

マークダウンレポートの規約 — 節約が生きるか死ぬかの分かれ目

このパターンが多くの人にとってしっくりくる理由は、レポートファイルというアイデアです。各サブエージェントが完了すると、オーケストレーターにマークダウンの要約を落とすのです。これは正しい直感ですが — そしてそれは同時に、計画全体が静かに失敗するまさにその場所でもあります。 もしCodexが500行のレポートを書き、Claudeがそれをすべて読んだなら、あなたは結局支払ったことになります — 単に書く代わりに読むことで。

ここに 悪い レポートの例があります（制約を与えないとエージェントはこれを作成します）:

340行のエッセイ: タスクを再確認し、すべての決定を時系列に語り、作成した2つのファイルの完全な内容を「参考のため」に貼り付け、完全なテスト出力を含み、3段落の注意事項と将来の改善に向けた提案で締めくくられています。

それを読むのはコードを書くより高くつきます。代わりに私が強制する規約は次のとおりです:

# Task: import-legacy script
Status: DONE
Files created:
  - scripts/import-legacy.mjs
  - tests/import-legacy.test.mjs
How to verify:
  - node --test tests/import-legacy.test.mjs
  - node scripts/import-legacy.mjs && head data/import-ready.json
Gotchas:
  - 14 rows in the sample CSV had no email; skipped, count logged
  - CSV dates are DD/MM/YYYY, not ISO — parser handles both

そして、すべてのレポートをこの形に保つための4つのルール:

1. ハードキャップ: 40行まで。 委譲プロンプトでこれを明記してください。ステータス、パス、検証コマンド、注意点 — それ以外は不要です。
2. パスのみ、内容は決して含めない。 アーティファクトはディスク上に存在し、レポートはそれらを指し示します。オーケストレーターは検証が要求する場合にのみファイルを開きます — 2回読むことは 選択であり、デフォルトではありません。
3. 純粋な生成の場合は「DONEのみ返信」。 アーティファクトがそれ自体を物語る場合（画像やオーディオファイルなど）、レポートすら多すぎます。ファイルが届き、1単語が返され、ゲートが実行されます。
4. すべての仕様に機械的にチェック可能な受け入れ基準を設ける。 「良くして」は手戻りを生みます。「すべてのテストに合格し、lintエラーはゼロ、出力は200KB未満の1200x630のJPEGであること」は、オーケストレーターが1つのコマンドで検証できる合否を生み出します。受け入れ基準の品質 こそが 委譲の品質なのです。

分業: 誰が何を受け取り、それはなぜか

タスク	担当	理由
画像、オーディオ/TTS、文字起こし	Gemini CLI — 常に	Orchestratorはこれらを全く実行できません。純粋な利益です
翻訳（特に地域の言語）	Gemini CLI	高品質、大量、サンプリングによる検証が容易
厳密な仕様を持つ自己完結型のスクリプト/モジュール	Codex CLI	大量、低い判断力、機械によるチェックが可能
テストスキャフォールディング、マイグレーション、ボイラープレート	Codex CLI	機械的な出力。受け入れ ＝ テスト自体
アーキテクチャ & 設計の決定	Claude — 決して委任しない	純粋な判断。仕様作成にはタスク以上のコストがかかる
複数ファイルのリファクタリング、統合タスク	Claude	統合の負担により、委任はかえって高くつく
デバッグ	Claude	蓄積されたコンテキストが必要。サブエージェントはゼロから開始する
委任されたすべての最終レビュー	Claude	これは文字通り、プレミアムモデルに支払っている仕事である

述べておくべき一つのニュアンス：これは「Claudeが良く、他が悪い」というわけではない。それは 量 対 判断。Codexは優れた自己完結型のコードを書く。Geminiの画像と翻訳の品質は、実際のプロダクションワークを担う。この分担は、各シートのコストと各タスクに必要なものに基づいている。

運用プレイブック

節約を複利的に増やすいくつかの習慣：

遅いものはすべてバックグラウンドで実行する。 生成ジョブは1〜5分かかる。それらをデタッチ状態で起動し、Orchestratorには別の作業を続けさせ、ファイルが到着したら結果を処理する。決して高価なエージェントをブロックして待たせてはならない。

積極的にバッチ処理する。 6つの画像を6つの会話で行うと、プロンプト＋レポートのオーバーヘッドが6回発生する。命名規則を用いて6つのファイルを生成する1つのプロンプト（hero-01.png … hero-06.png）、1つのレポート、1回のレビューパス。翻訳でも同様：8つの言語すべてを1回の委任で行う。

知的にレビューする前に、機械的にゲートを設ける。 ファイルが存在する → サイズが妥当 → エントロピー/lint/テストに合格する → それから Orchestratorのトークンを判断に費やす。ゲートが捉えるすべての失敗は、支払わずに済んだモデルレビューである。

早く失敗させ、一度だけエスカレーションする。 委任が間違って戻ってきた場合、Orchestratorは 1回の より明確な制約（「前回の試行ではタブレットが切り取られていた — タブレット全体が見えなければならない」）を伴う修正リトライを行う。リトライも失敗した場合は、そのタスクの委任を中止する。Orchestratorが直接実行するか、それを迂回する。終わりのないリトライループは、委任が何かを行う上で最も高価な方法になる原因である。

Orchestratorのセッションをクリーンに保つ。 長時間実行されるOrchestratorのセッションはコンテキストを蓄積し、コンテキストは毎ターン支払う入力トークンの家賃である。アーティファクトが会話の中ではなくディスクに残るからこそ、委任は役立つ — 以下によってそれを台無しにしないこと。 cat「ちょっと見る」ためにファイルをチャットに -ing すること。

学習した制約をテンプレートに書き込む。 すべてのやり直しが、プロンプトの1行（「透かしなし」、「完全にフレーム内に」、「新しい依存関係なし」など）を教えてくれる。テンプレートは、同じ教訓に対して二度料金を支払うのを止める方法である。

これの実際の1週間がどのようになるか

定性的に、実際のプロジェクトの1週間を通してこのパターンを実行した後：大量の出力が会話に入ることがなかったため、Orchestratorのコンテキストは小さく保たれ、そのターンは速く保たれた。目に見えるトークンの消費は、ほぼ完全に仕様、レポート、レビューに移行した — そしてそれこそが、あなたがプレミアムモデルの注意を費やしてほしいと 望む 場所である。サブエージェントは、量に対して自身のクォータを消費した。そして失敗は現実的であったが、制限可能なものであった：クリエイティブな生成の約4分の1における修正サイクル、厳密に仕様化されたコードタスクでのほぼゼロのやり直し、そして1つのタスク（横断的なリファクタリング）は、仕様のドラフトがアーキテクチャドキュメントに変わり始めた後、私が正しくOrchestratorに保持した。

このパターンは、高価なモデルを安くしたわけではない。私にタイピストとしてそれを使うのをやめさせたのである。

結論とチェックリスト

この戦略は正しいか？ ほとんどの場合、イエスである。 生成を多用する作業では、節約は現実的かつ大きい — それは 出力の委任であり、出力はあなたが料金を支払う対象である。判断を多用する作業では、節約は幻想である — それは 理解の委任であり、理解は常にOrchestratorの請求書に戻ってくる。通常は利子付きで。

高価なCLIを、素晴らしく安価なチームを持つ気難しいテックリードとして扱う：それは仕様を書き、小さなレポートをレビューし、何かおかしいと感じたときだけボンネットを開ける。

タスクを委任する前に、チェックリストを実行する：

• 出力は 大きい （>100行 / >2kトークン）か、あるいはOrchestratorが 全く生成できない?
• 仕様を書けるか アーキテクチャを説明することなく?
• 「完了」は 機械によるチェックが可能か （「すべて注意深く読む」ことよりも、テスト、lint、ファイルのプロパティなど）
• 出力パスは 正確で、そして返信は以下に制限されているか DONE + 40行以下のレポート?
• 予算を立てたか 1回の修正サイクルの — そして、2回失敗した場合どうなるか決めたか？

5つのイエス：それを委任し、バックグラウンドで実行し、ゲートを設け、その計算を楽しむ。1つでもノー：プレミアムモデルがそれを直接行う — なぜなら、あなたが費やす最も高価なトークンは、二度費やされるトークンだからである。