Agent開発でトークンが枯渇する問題を、工程ごとにLLMを使い分けることで回避した。Codexで構造を組み上げ、Claude Codeで対話しながら仕上げる。この分業が機能した理由を、プロンプト設計と各LLMの特性から整理する。

マルチLLM戦略が必要になった背景

「Agent が動かなくなった」。Slackに通知が来たのは、金曜日の夕方でした。

原因はトークン上限。Claude Code で書いていた Notion 更新 Agent に、新しい条件分岐を追加した際、プロンプト全体が制限を超えた。会話履歴を消せば一時的には動く。ただ、それでは文脈が失われ、前回の設計意図が反映されなくなる。

問題は、1つの LLM で全工程を処理しようとしていたことでした。要件整理、コード生成、エラー対応、リファクタリング。全てを Claude Code の会話スレッド内で完結させようとした結果、履歴が肥大化した。

そこで方針を変えた。工程を「構造の組み上げ」と「対話による仕上げ」に分割し、前者を Codex、後者を Claude Code に割り当てる。これが、私たちのマルチLLM戦略の起点です。

Codexで骨格を作る理由

Codex を選んだのは、エディタ統合とコンテキスト効率が理由でした。

Cursor に Codex を組み込むと、いま開いているファイルとプロジェクト構造から補完候補が生成される。新しい関数を定義する際、既存の型定義や命名規則を参照し、一貫性のあるコードが返ってくる。会話履歴を持たないため、トークン消費は最小限。

先週、Slack から特定キーワードを検知して Notion にタスク登録する Agent を作った。まず Codex で API クライアント、メッセージパーサー、エラーハンドリングの骨格を書いた。コメントで処理の意図を残しておけば、次の関数を書き始めた瞬間に文脈を拾って補完してくれる。

この段階では対話は不要です。やるべきことが明確で、構造が決まっている場合、指示を最小化できる Codex のほうが速い。10分で300行のベースコードができた。

Claude Codeで詰める工程

骨格ができたら、Claude Code に切り替える。

理由は、判断が必要な箇所を対話で詰められるからです。エラー時のリトライ回数をどうするか、ログをどこまで詳細に残すか、通知対象をどう絞るか。こうした設計判断を、コードを見せながら選択肢を並べてもらう。

先ほどの Slack Agent では、「キーワード検知の精度を上げたい」という要望があった。正規表現で厳密にマッチさせるか、部分一致で広く拾うか。Claude Code に現在のコードと過去の誤検知ログを渡し、「どちらの方針が運用上リスクが低いか」と聞いた。

返答は、部分一致で拾った後にスコアリング層を挟む提案でした。キーワードの出現頻度と文脈を評価し、閾値以上のものだけ通知する。実装例も一緒に出してくれたため、そのまま組み込んだ。

対話形式の利点は、判断根拠を残せることです。なぜこの設計にしたのか、どの選択肢を捨てたのか。後から見返したときに、意図が追える。

プロンプト軽量化の要件定義

マルチLLM戦略を機能させるには、各工程で渡す情報を絞る必要がある。

Codex には、型定義と関数シグネチャだけ渡す。実装の背景や要件の経緯は含めない。いま書いている関数の役割が明確なら、周辺コードから文脈を読み取ってくれる。

一方、Claude Code には、判断に必要な情報だけ渡す。全コードを貼るのではなく、該当箇所の前後20行と、関連する型定義のみ。会話履歴も、直近3往復以上は参照しない前提で指示を書く。

先月、API レスポンスのパース処理を Claude Code で書き直した際、最初は全スキーマ定義を貼り付けていた。トークンが300以上消費された。次に、今回触る箇所のスキーマだけに絞ったところ、80トークンで済んだ。出力精度は変わらなかった。

プロンプトは、渡す情報の取捨選択が8割です。どの LLM を使うかより、何を渡さないかのほうが重要だった。

分業が成立する条件

CodexとClaude併用で機能する条件は、工程の境界が明確なことです。

「構造を作る」と「判断を詰める」が分離できないタスクでは、この分業は向かない。たとえば、要件が曖昧なまま実装に入る場合、Codex で骨格を作っても手戻りが発生する。その場合は最初から Claude Code で対話しながら進めたほうが速い。

逆に、やるべきことが明確で、判断箇所が限定されているなら、この分業は有効です。トークン管理の観点でも、会話履歴を最小化できるため、長期運用しても制限に引っかかりにくい。

現在、私たちは5つの Agent を Codex と Claude Code の併用で運用している。週次で1回、プロンプトの見直しをしているが、トークン起因のエラーは3週間出ていない。

工程を分ける。情報を絞る。それだけで、LLM は長く使える道具になる。