Claude Code などの対話型コーディングエージェントを日々の開発業務に導入すると、セッションの長期化や反復的なタスク実行に伴って消費トークンが急増し、API コストの増大という現実的な壁に直面します。この課題に対して、「重い検証処理やサブエージェントを安価な外部モデルへオフロードしてコストを抑えたい」「Claude 単体では見落としがちな盲点を、別系統のモデルに第二意見として突かせてレビュー品質を上げたい」と考えるのは自然な発想です。

異種LLMルーティング（Heterogeneous LLM Routing） とは、タスクの規模や難度に応じて異なる系統の AI モデルへ処理を振り分け、コスト削減と多角的な視点を両立するアーキテクチャパターンです 12。しかし、事前の実測や挙動の検証を行わずに推測だけでモデルルーティングを組むと、「委譲した外部モデルが途中で止まって結果が返らない」「指示した数値を勝手に丸めたり、存在しない体験談を創作したりする」といった破綻に見舞われます。本検証でも、その両方が実際に起きました。

さらに重要なのは、モデルを切り替える前に「そもそもサブエージェントや検証処理が、セッション全体のトークン消費のうち何割を占めているのか」という構造を把握しているかどうかです。実際にセッション全体のトークン内訳を測ってみると、サブエージェントが占めていたのは全体のわずか 9% に過ぎず、強力なプロンプトキャッシュ（読出率 96% 超）の恩恵も加味すると、安易な外部オフロードによるコスト削減は極めて限定的であることがわかりました。

つまり、異種モデルへの委譲が真に価値を発揮するのは、コスト削減目的ではなく「Claude 単体では拾えない死角を突く第二意見（品質向上）」です。

本記事では、自社のブログ執筆・検証パイプラインにおける実機検証ログ（Gemini 3.8 Flash High と Kimi-K2.6 の挙動比較）と、リポジトリ全セッション 7.3 億トークンの実測内訳から、別モデル委譲における「完走と破綻の境界線」および「第二意見を安全に得るためのアーキテクチャ設計」を解明します。

検証環境と調査スコープ

本調査では、複数のエージェントを並列実行して観点別にコードレビューを自動化する実践事例 34 を背景としつつ、実際に運用している業務自動化パイプラインにおいて異種モデルを連携させた際の実機ログを分析対象としました。

検証環境の仕様および調査スコープは以下の通りです。

項目検証環境のスペック・条件
対象システム自社ブログ執筆・検証パイプライン（検証工程 blog-verify）
実行環境macOS Sequoia (Darwin arm64)
ランタイムNode.js v24.15.0
計測実施時期2026年10月19日（追加検算: 2026年10月28日）
メインエージェントClaude Code（Anthropic claude-opus-5, claude-opus-5-5, claude-sonnet-5-5）
第二意見レビュアー Aagy CLI v1.4.8（Google gemini-3.8-flash-high）※親プロセスから呼び出す外部 CLI ラッパー
第二意見レビュアー Bpi CLI（Moonshot AI Kimi-K2.6 / sakura-ai、CLI拡張スクリプト sakura.ts）※親プロセスから呼び出す外部 CLI ラッパー
トークン集計環境Node.js 製集計スクリプト（scripts/token-usage.mjs）

調査の対象として、以下の 4 つのタスク規模におけるモデルの挙動とトークン消費を追跡しました。

  1. 検証規模タスク: 詳細設計書（約 100KB）と複数の関連ドキュメント・ログファイルを横断照合し、事実関係の矛盾や規則違反を洗い出す長文レビュータスク
  2. 単一ファイルレビュータスク: 単一の設計書ファイルのみを対象とし、1 文の簡潔なプロンプトで記述の粗さを指摘させる軽量タスク
  3. 短文生成タスク: 記事の SNS 共有用文案（280 重み以内）の作成タスク（「記事に無い事実や数値を足さない」制約付き）
  4. 全セッショントークン集計: リポジトリ内の全 139 トランスクリプト（メイン会話 41 件、サブエージェント 98 件）の消費比率およびキャッシュ読出率の計測

評価基準と前提となるアーキテクチャ概念

異種モデルへのタスク委譲やサブエージェントの経済性を評価するにあたっては、近年の LLM アーキテクチャが持つ 2 つの基礎的な仕様を理解しておく必要があります。

1. プロンプトキャッシュとコールドスタートの損益分岐点

Anthropic の Prompt Caching 仕様では、512 トークン以上のプロンプトプレフィックス（ツール定義、システムプロンプト、会話履歴）が一致する場合、キャッシュからの読み出し（cache_read_input_tokens）は通常入力単価の 0.1×（90% 割引）となります。さらに Claude Opus 5.5 や Claude Sonnet 5.5 などの主力モデルでは 0.05×（95% 割引）という極めて強力な割引率が適用されます 5。

対話型の開発セッションでは、コンテキスト長が数万から十数万トークンに達しても、その 9 割以上がキャッシュから読み出されるため、1 ターンあたりの実質的な入力コストは大幅に低減されます。

一方、Claude Code のサブエージェントは、親セッションのコンテキスト肥大化やツール汚染を防ぐ目的で、メイン会話とは完全に独立した専用のコンテキストウィンドウで起動されます 67。

この独立性は、メインセッションに蓄積されたプロンプトキャッシュの恩恵をリセットすることを意味します。外部モデルやサブエージェントへタスクを切り出す際、前提ドキュメントやルール定義を改めて送る必要があるため、コールドスタートとしてのキャッシュ書き込みコストが起動のたびに発生すると考えられます。別モデルへの切り出しは、見かけのモデル単価差に加えて「キャッシュ恩恵の喪失」というペナルティを背負う、というのが筆者の見立てです（このペナルティの大きさ自体は今回計測していません）。

<!-- ファイル: subagent-definition.md -->
---
name: second-opinion-reviewer
description: 設計書の技術的妥当性を独立した視点で検証するサブエージェント
tools:
  - Read
  - Grep
---

あなたは独立した技術レビュアーです。
メインセッションの会話履歴を前提とせず、渡されたファイル群の記述のみに基づいて
事実関係の矛盾や設計上のリスクを客観的に指摘してください。

上記は Claude Code におけるカスタムサブエージェント定義の最小構成例です。独立したプロンプトで起動することにより安全な作業空間が確保される反面、前提知識の再注入が必要となるアーキテクチャ上のトレードオフが存在します。

2. 最大生成トークン枠（maxTokens）と思考（Thinking）の共有

近年の推論モデル（Extended Thinking 対応モデル）では、モデルが内部で行う推論・思考トークンと、最終的にユーザーへ返される可視出力トークンが、同一の最大生成トークン枠（max_tokens）を共有します 8。

推論モデルを CLI やカスタムハーネスから呼び出す際、ツール側の既定値（例えば 8,192 トークンなど）が小さく設定されていると、難度の高いタスクに対してモデルが深く思考しただけで上限枠を使い果たしてしまい、可視出力（本文テキスト）が完全に空のまま終了コード 1 で異常終了する現象が発生します。また、API の停止理由パラメータが最大トークン超過なのか、モデル自身が自律的にターンを終了したのか（自然終了等）を正しく区別してハンドリングしなければ、原因究明が困難になります 9。

各モデルの個別挙動と特徴

同一の検証タスクおよび短文生成タスクを投入した際、agy（Gemini 3.8 Flash High）と pi（Kimi-K2.6）が示した対照的な挙動を実測ログに基づいて見ていきます。

agy（Gemini 3.8 Flash High）の挙動: 262秒で完走し4件中3件が妥当

自社パイプラインの検証タスクにおいて、約 100KB の設計書および複数ファイルを agy CLI 経由で Gemini 3.8 Flash High に投入しました。

# agy による並列検証実行コマンド
agy --model gemini-3.8-flash-high --output-format json \
  --add-dir .company/cache --add-dir specs/blog-posts/issue-example \
  -p "Read specs/blog-posts/issue-example/verify-prompt.md and follow the instructions in it exactly. Reply in Japanese."

Gemini 3.8 Flash High は、多ファイル横断の長大な指示に対しても自律的な読み込みループを維持し、261.73 秒（約 262 秒）で最後まで完走して正常終了（exit=0）しました 10。

SUCCESS 261.734784 {'input_tokens': 113168, 'output_tokens': 27273, 'thinking_tokens': 22424, 'cache_read_tokens': 1625510, 'total_tokens': 140441}

上は agy の JSON 出力から所要秒数と usage を抜き出して表示した実行ログです。total_tokens（140,441）は input_tokens と output_tokens の和で、キャッシュからの読み出し（cache_read_tokens）は含みません。

出力された指摘 4 件の内容を一次資料と突き合わせて検証した結果、4 件中 3 件が妥当な指摘でした。同じ設計書を Claude だけで検証した工程は指摘 0 件で通しており、そこで見落とされていた欠陥を agy が拾った形です。

  1. 逐語記録と矛盾する数値主張の検出（重要度: 高）: 設計書が「希望・依頼形は base 条件で 0 件」と誇張して書いていたのに対し、逐語記録上は A 題材で平均 2.0 回、C 題材で平均 7.3 回出現していた事実を引き当てて数値の誤りを指摘。
  2. 規則数の取り違え検出（重要度: 中）: 条件 C の規則数が「2」ではなく「3」である整合性違反を検出。
  3. 脚注 URL の指定不備検出（重要度: 中）: 論文の本文キャッシュには数値が存在するものの、引用 URL が概要ページ（abs）のままになっていた不備を指摘。

残る 1 件は、脚注の採番順に関する社内ルールの適用対象を取り違えた誤検出でした。それでも長文コンテキストに耐えて検証を完走できたため、社内の検証パイプラインに並列レビュアーとして組み込みました。

pi（Kimi-K2.6）の検証規模タスク: 4回中4回ともターン未完（完走率 0/4）

同じ検証規模タスク（約 100KB）を、pi CLI を介して Kimi-K2.6（sakura-ai）に実行させました。

# pi による検証規模タスクの試行の形（実際の指示は約 25KB のプロンプトで渡した）
timeout 900 pi --mode json --tools read \
  -p "specs/blog-posts/issue-example/design.md を検証して"

結果は、4 回の試行すべてにおいて検証結果を出力することなく途中でターンを閉じてしまい、完走率は 0/4（0%）に終わりました 11。

試行ごとに条件と終わり方は異なります。テキストモードの 1 回目は結論を出さずに終了し、JSON モードの 2 回目は 500 秒以上無出力のまま止まったため強制終了しました。タイムアウトを 900 秒に延ばした 3 回目は、思考ブロックに「次は○○を確認します」と書いたまま、本文（text）が空の状態で stopReason=stop を返して終了しました。ファイルパスを個別に渡した 4 回目も、関連ファイルを読み込む途中でターンを終えています。なお、単一の package.json を読ませるだけの軽量タスクでは 3.7 秒で正常終了してツール呼び出しも機能したため、ツール連携機能自体の不具合ではなく、多ファイル横断・長文プロンプトの規模に対する自律ループ維持の限界と考えられます。

pi（Kimi-K2.6）の maxTokens 設定と単一ファイルでの完走

検証規模タスクから切り離し、単一ファイル（設計書 1 ファイルのみ）に対する 1 文の簡潔なレビュー依頼を pi（Kimi-K2.6）に投入しました。

ところが、初期設定のままでは 2 回連続で本文が空のまま異常終了（exit 1）しました 12。

原因を調査した結果、CLI 拡張スクリプト（sakura.ts）内の設定で maxTokens: 8192 とハードコードされていたことが判明しました。推論モデルである Kimi-K2.6 が思考プロセスでトークンを消費し、上限の 8,192 トークンに達したことで本文を生成できず切断されていたのです。

// sakura.ts L17 の設定変更差分
- maxTokens: 8192
+ maxTokens: 32768

maxTokens を 32,768 へ引き上げたうえで再実行したところ、約 128 秒で完走し、単一ファイル内の表現の不一致（「半減した」の表現の揺れや実験本数の内訳の齟齬など）に関する 5 件の指摘を出力できました。

モデルを切り替える際は、モデル自体の性能だけでなく、呼び出し側のハーネスや CLI 拡張の既定値（maxTokens など）がタスク規模に見合っているかを点検する必要があります。

pi（Kimi-K2.6）の短文生成における数値丸めと体験談創作

続いて、SNS 共有用の短文作成（280 重み以内）を「記事に無い事実や数値を足さないこと」という強い制約を設けて pi（Kimi-K2.6）に依頼しました 13。

テキストモードでは 38.9 秒で 3 案が出力されました。

エージェントに複数確認を一括で投げさせていたら、選択肢番号がぶつかってユーザーが「1問目は1です」と補正入力するハメになっていた。3回中2回も発生して、打鍵コストは15倍に膨れ上がる。自分のエージェントの問いかけ方、見直したほうがいいかもしれない。
---
AIエージェントの確認ダイアログで、画面をロックして待たされるのが地味にストレスだった。さらに番号が重複して「1問目はA、2問目は2」みたいに補正入力させられると、本来2打鍵で済むものが30〜40打鍵に膨れる。自分の対話設計、こっそり確認したくなる話。
---
エージェントに一括で3つ確認を任せていたら、選択肢の番号が全部「1,2,3」で被っていて、回答が通じない事故が3回中2回も起きていた。モーダル画面で待たされる上に、打鍵コストが20倍に膨れ上がる。自分のプロンプト設計、実はこんな落とし穴が潜んでいるかも。

出力された文案を元記事ドキュメントと突き合わせると、以下のような事実の変形が確認されました。

  • 案1: 「打鍵コストは15倍に膨れ上がる」と記述。元記事本文は「打鍵コストは約 15〜20 倍」であり、数値幅の下限のみを抜き出して断定表現に丸めています。
  • 案2: 「画面をロックして待たされるのが地味にストレスだった」と記述。元記事本文にはそのような一人称の感情・体験談の記述はなく、架空の体験談を創作しています（ハルシネーション）。
  • 案3: 「打鍵コストが20倍」と記述。元記事本文の数値幅の上限のみを抜き出して断定表現に丸めています。

「事実を足さない」とプロンプトで厳格に命じても、モデルが要約の過程で数値幅を勝手に単一の数値へ丸めたり、文脈を補うために架空の体験談を創作したりするリスクを完全に防ぐことはできません。安価なモデルに短文生成を任せる場合でも、人間または親エージェントによる事実照合ゲートが不可欠です。

共通点と相違点の比較

外部モデルへのタスク委譲においては、モデル単体のカタログスペック以上に「タスクの入力規模（コンテキスト長とファイル数）」および「思考トークン枠の割り当て」が完走可否を分ける決定的な境界となります。

各モデルおよびタスク規模ごとの挙動の差異を以下のマトリクス表に整理しました。

モデル・実行環境タスク規模入力・コンテキスト長参照ファイル数完走可否検出力・出力品質主なリスク・課題実測所要時間
Claude Code（メイン会話）検証規模長文（約 100KB）複数ファイル横断完走可基準（単体では数値誇張等の見落としあり）セッション長期化時のコスト増大-
agy（Gemini 3.8 Flash High）検証規模長文（約 100KB）複数ファイル横断完走可（1/1）高い（数値誇張・規則数の誤りを検出）親プロセスでの結果集約が必要約 262 秒
pi（Kimi-K2.6）検証規模検証規模長文（約 100KB）複数ファイル横断未完（0/4）判定不能（結論出力前に停止）長文でのターン途中終了（stopReason=stop）タイムアウト（900秒等）
pi（Kimi-K2.6）単一ファイル小規模短文（1文指示）単一ファイル完走可（32k時）限定的（単一ファイル内の表現点検）maxTokens 不足による空出力（8k時）1〜2分強（約128秒）
pi（Kimi-K2.6）短文生成極小短文指示なし（元記事渡し）完走可要検収（事実変形あり）数値の丸め・架空体験談の創作38.9 秒

以上の比較から明らかなように、多ファイル横断の重厚な検証タスクに耐えられるのは長文追従性と安定した自律ループを持つモデル（Gemini 3.8 Flash High 等）に限られます。外部モデルへの委譲は、コスト削減目的ではなく、Claude 単体では見落とす盲点を突く「第二意見としての品質向上」を狙う場合にこそ真価を発揮します。しかし、多ファイルでの停止や数値丸めのリスクを抱えたままでは、第二意見を安定して得ることはできません。これらを防ぎ、品質向上の果実を安全に手に入れるための推奨実装が以下の設計です。

ベストプラクティスと推奨実装

実機検証から導き出された、異種モデルを自社エージェント運用に安全に組み込むための「安全境界ルール」は以下の 3 点です。

1. タスク規模に応じたモデルルーティング

  • 多ファイル横断・長文指示の検証タスク: 長文耐性と自律ループの完走実績があるモデル（Gemini 3.8 Flash High 等）のみを起用し、完走が確認できないモデルへの丸投げは避ける。
  • 単一ファイルレビュー・短文生成: 入力コンテキストを 1〜2 ファイル以内に限定して渡す。単発タスクにおける複数エージェント間の調整コスト増大を避けるためにも、対象スコープを明確に閉じることが重要です 14。

2. ハーネス側の maxTokens と思考枠の事前確認

推論モデルを CLI やスクリプトから呼び出す際は、maxTokens が思考トークンと可視出力トークンの合算枠であることを前提に、最低でも 16,384〜32,768 トークンを確保する設定にします。

3. サンドイッチ型検証（親エージェントによる事実照合ゲート）

本記事では、親エージェントがコンテキストを絞り込んで外部モデルへ渡し、その出力を親エージェントや検証スクリプトが機械照合する防壁パターンを「サンドイッチ型検証」と呼びます。

安価なモデルに出力させたテキストや指摘は、そのまま公開やコミットに進めず、元資料との差分を突き合わせる事実照合ゲートを通します。「事実を足さない」「数値を丸めない」という指示はモデル側で破綻しやすいため、機械的な照合ルールを挟むことが安全運用の鍵となります。

// ファイル: verify-wrapper.mjs
// 親プロセスから外部モデルを呼び出し、出力を機械検証するラッパーの最小サンプル
import { execSync } from 'node:child_process';
import fs from 'node:fs';

export function runSecondOpinion(inputFile, prompt) {
  // 1. コンテキストを単一ファイルに絞り込んで呼び出す
  const cmd = `timeout 300 pi --mode json --tools read -p "${prompt} ${inputFile}"`;
  let rawOutput = '';
  try {
    rawOutput = execSync(cmd, { encoding: 'utf8' });
  } catch (err) {
    return { status: 'FAILED', reason: 'Execution timeout or process error' };
  }

  // 2. 空出力およびターン未完の判定
  if (!rawOutput || rawOutput.trim() === '') {
    return { status: 'FAILED', reason: 'Empty output (maxTokens exhaustion suspected)' };
  }

  const result = JSON.parse(rawOutput);
  if (!result.text || result.text.trim() === '') {
    return { status: 'INCOMPLETE', reason: 'Turn ended without conclusion text' };
  }

  // 3. 事実照合ゲート（元資料との数値・表現突き合わせの最小スケルトン）
  // ※本コードは単語境界による数値存在チェックを行う最小例です。
  // 実務では「約15〜20倍」から「15倍」への丸めや文脈改変を防ぐため、
  // 構文解析（AST/正規表現）やセマンティック差分照合を組み合わせて検知します。
  const originalText = fs.readFileSync(inputFile, 'utf8');
  const numbersInOutput = result.text.match(/\b\d+(?:\.\d+)?\b/g) || [];
  const suspiciousNumbers = numbersInOutput.filter(
    (n) => !new RegExp(`(?:^|[^0-9.])${n}(?:[^0-9.]|$)`).test(originalText)
  );

  return {
    status: 'SUCCESS',
    data: result.text,
    suspiciousNumbers, // 元資料に存在しない数値があればフラグを立てる
  };
}

上記のように、親プロセス側でタイムアウト制御、空出力チェック、および元ドキュメントとの単語境界・数値突き合わせを行うことで、外部モデルの不完全終了やハルシネーションが下流工程へ流出するのを防ぐことができます（本サンプルは最小実装であり、実際のパイプラインでは数値幅の単一化や架空体験談の検知に向けたルールベースの機械照合スクリプトを多層に配置しています）。

実機ベンチマークと検証ログ

ここまでの検証で、モデルごとの完走境界や安全対策が明らかになりました。では、なぜここまで防壁を設けて外部モデルの完走性や安全枠を管理する必要があるのでしょうか。「サブエージェントを安価なモデルに移せば大幅なコスト削減になるはずだ」という当初の目論見と、実際のトークン消費構造はどう乖離していたのでしょうか。

全139セッションのトークン内訳実測

2026年10月19日時点における、リポジトリ内の全セッショントランスクリプト（メイン会話 41 件、サブエージェント 98 件、計 139 件）からトークン消費量を実測しました 15。

# トークン内訳の集計コマンド
node scripts/token-usage.mjs --all

--- トークン消費実測 ---
対象トランスクリプト: メイン 41 件 / サブエージェント 98 件

■ 合計
  総トークン: 731,505,813
  メイン: 664,384,012 (3004 req) / サブエージェント: 67,121,801 (793 req)

■ モデル別
  claude-opus-5
    合計 137,102,611 = 入力 1,312 + 出力 561,817 + キャッシュ書込 4,569,574 + キャッシュ読出 131,969,908  (656 req)
  claude-opus-5-5
    合計 543,027,124 = 入力 5,644 + 出力 1,902,671 + キャッシュ書込 16,824,687 + キャッシュ読出 524,294,122  (2745 req)
  claude-sonnet-5-5
    合計 51,376,078 = 入力 820 + 出力 272,539 + キャッシュ書込 2,152,217 + キャッシュ読出 48,950,502  (393 req)

集計の結果、全体のトークン消費の実に 90.82%（約 91%） をメイン会話が占めており、サブエージェントが消費していたのは全体の 9.18%（約 9%） に過ぎないことが判明しました。また、入力トークンの 96.41% はプロンプトキャッシュから高速かつ安価に読み出されていました。

なお、2026年10月28日時点の再集計においても、総トークン数は 878,291,903 トークンに増加したものの、メイン会話 90.5%、サブエージェント 9.5%、キャッシュ読出率 96.4% と、その構造比率は極めて安定していました。

パイプラインの中で最もトークンを消費するレビュー工程（合計 154.2M トークン、全体の 21.1%）に着目しても、サブエージェントによる消費は 10.4M トークンであり、レビュー工程全体の 6.7% に留まります。

コスト削減効果の冷静な試算

並列エージェントや外部レビューの導入によって処理時間やトークン消費が数倍に膨れ上がるという実務上の課題が報告されています 16。

今回の実測データから試算すると、「サブエージェントが行っている作業をすべてゼロコストの外部モデルに置き換えた」という極端な仮定を置いたとしても、リポジトリ全体で削減できるトークン消費量は理論上最大でも 約 9%（レビュー工程に限れば約 7%）に過ぎません。

さらに、メイン会話のトークンは 96% 以上がキャッシュから読み出されており、Anthropic の 90% 割引（Claude Opus 5.5 / Sonnet 5.5 では 95% 割引）の恩恵を最大級に受けています 5。外部モデルへの安易な切り出しは、メイン会話の強力なキャッシュコンテキストを捨てて外部でコールドスタートを発生させるため、見かけの API 単価差ほどコストは下がらず、むしろ連携ハーネスの管理コストや完走失敗のリスクが増大する懸念があります（モデル単価差とキャッシュ読出率を考慮した精緻な試算が必要です）。

別モデルへのタスク分散を検討する際は、向いている作業を推測で並べる前に、まず会話全体のトークン内訳（メインセッションとサブエージェントの比率）を計測すべきです。外部モデルへの委譲は、「コスト削減」を主目的にするのではなく、Claude 単体では拾えない死角を突く「第二意見（品質向上）」としてこそ投資価値があります。そしてその品質向上を安全に手に入れるための武器が、前節で示したサンドイッチ型の安全境界設計なのです。

よくある質問（FAQ）

Q1: サブエージェントを安価なオープンモデルや外部APIに置き換えれば、開発全体のコストは大幅に下がりますか？

結論として、対話型のコーディング開発においては、推測ほど大幅な削減効果は得られません。

自社パイプラインの全 139 セッション（7.3 億トークン）の実測では、消費トークンの約 91% をメイン会話が占めており、サブエージェントの消費は全体の約 9% に過ぎませんでした。仮にサブエージェントをすべて無料のモデルに置き換えても、削減できるのは理論上最大で 9% です。

さらにメイン会話は 96% 以上のプロンプトキャッシュ読出（90〜95% 割引）が効いているため、外部委譲に伴うコンテキスト再送信のコストも考慮する必要があります。

Q2: 別系統のLLMをコードレビューや検証の第二意見として安全に組み込むための必須条件は何ですか？

結論として、「タスク規模に見合ったモデルの選定」と「親エージェントまたは人間による事実照合ゲートの設置」の 2 点が必須条件です。

実機検証の結果、Gemini 3.8 Flash High のように多ファイル横断の長文検証（約 100KB）を完走できるモデルがある一方で、Kimi-K2.6 のように多ファイル検証では途中でターンを終了してしまうモデルも存在します。

また、短文生成であっても数値幅の端折りや架空体験談の創作が発生するため、委譲先モデルの出力を無条件に信用せず、元資料との照合ルールを必ず挟む必要があります。

まとめ

本調査を通じて得られた、異種モデル連携とトークン最適化に関する主要な命題は以下の 4 点です。

  1. モデル分散の前にまず内訳を測る: サブエージェントや外部委譲の経済効果を推測する前に、セッション全体のトークン内訳を計測してください。メイン会話が 9 割以上を占める環境では、サブエージェントの置き換えによる削減効果は最大でも 1 割弱に留まります。
  2. 第二意見はタスク規模でモデルを選ぶ: 長文指示・多ファイル横断の重厚な検証には完走実績のあるモデル（Gemini 3.8 Flash High 等）を起用し、軽量モデルは 1〜2 ファイル・短文指示の閉じたタスクに限定してください。
  3. 推論モデルの maxTokens 枠を確認する: 思考機能を備えたモデルを呼び出す際は、思考トークンで出力枠が枯渇しないよう十分な maxTokens（16k〜32k 以上）を確保してください。
  4. 外部生成物には必ず事実照合ゲートを挟む: 「事実を足さない」指示を与えても数値丸めや体験談創作は発生するため、親エージェントや検証スクリプトによる機械的な検収を省略してはなりません。

AI エージェント運用のトークンコスト最適化や、複数モデルを組み合わせた安全な検証・レビューパイプラインの設計支援について、ぜひ コンタクトフォーム よりお気軽にご相談ください。

Footnotes

  1. Cut Agent Fleet Costs by 90% with Heterogeneous LLM Architecture Jangwook、2026年3月9日。導入部およびコスト試算モデル。 ↩

  2. Route AI Agent Workloads Across Models with NVIDIA NeMo Switchyard Michelle Horton（NVIDIA Technical Blog）、2026年8月11日。“System of Models” セクション。 ↩

  3. ズボラ運用術コードレビュー編！Claude Codeに丸投げできるマルチエージェントレビューを作った shota_web305、2026年2月22日。アーキテクチャ構成図。 ↩

  4. コードレビューにClaude Code subagentsを導入したら、レビューレベルが改善した話 mgdx_blog、2026年3月5日。導入効果セクション。 ↩

  5. Prompt Caching (beta) Anthropic Documentation、2024年（2026年参照）。Pricing, How prompt caching works。キャッシュ読出単価が基本入力の 0.1×（90%割引、Claude Opus 5.5 / Sonnet 5.5 では 0.05× / 95%割引）であること、最小対象トークン数が 512 トークンであること。 ↩ ↩2

  6. Create custom subagents Claude Code Documentation、2025年（2026年参照）。Overview, Configuration。サブエージェントがメイン会話と独立したコンテキストウィンドウで起動し、履歴を直接共有しないこと。 ↩

  7. Claude Code のサブエージェント機能の基本的な使い方 ino_h、2026年9月10日。サブエージェントの特徴セクション。 ↩

  8. Extended Thinking Anthropic Documentation、2025年（2026年参照）。Token considerations。max_tokens が思考トークンと可視出力の合計枠であり、budget_tokens は max_tokens 未満でなければならないこと。 ↩

  9. Messages API: Response Stop Reasons Anthropic API Reference、2024年（2026年参照）。Response body: 停止理由ステータス。最大トークン到達や自然終了等のステータス定義。 ↩

  10. Meetsource 一次計測ログ、2026年10月19日。261.73 秒で完走、指摘4件中3件妥当（baseで0件の誇張検出、規則数3の検出、誤検出1件）。 ↩

  11. Meetsource 一次計測ログ、2026年10月19日。長文・多ファイル検証で4回中4回とも stopReason=stop でターン未完。 ↩

  12. Meetsource 一次計測ログ、2026年10月19日。sakura.ts の maxTokens: 8192 により本文空、32768 へ引き上げて単一ファイル完走。 ↩

  13. Meetsource 一次計測ログ、2026年10月19日。「約15〜20倍」→「15倍」「20倍」への丸め、架空感情体験談の創作。 ↩

  14. 70%削減の裏側。マルチAIエージェントを『遅く』せずに『速く』する設計パターン5選 株式会社ヘキサベース、2026年。単発タスクとマルチエージェント。単発タスクにおける複数エージェント調整コストの増大と使い分けの必要性。 ↩

  15. Meetsource 一次計測ログ、2026年10月19日（2026年10月28日検算）。全139セッションでメイン 90.8%、サブ 9.2%、キャッシュ読出 96.4%（2026-10-28 再集計でもメイン 90.5%、サブ 9.5%、キャッシュ読出 96.4%）。 ↩

  16. 実務において敵対的レビューはどの程度有効なのか e-dash Tech Blog、2026年10月1日。課題セクション: トークンコスト。複数モデル・並列エージェントによるレビューで時間とトークン消費が数倍に膨らむ実務課題。 ↩