検証系サブエージェントとは、メインエージェントが生成した成果物に対し、明確な規約やスキーマへの適合性を独立した視点で判定する特化型エージェントです。複数の AI モデルを協調させる自律エージェントパイプラインの実用化が進むにつれ、開発現場ではサブエージェント呼び出しの累積による API コストの急激な膨張が深刻な課題になっています。

特にコードレビュー、執筆規約の適合確認、出力スキーマのバリデーションといった「検証工程」にまで、上位のフロンティアモデル（Claude Sonnet 等）を固定で割り当て続ける設計は、パイプライン全体の運用コストを不必要に押し上げる過剰投資になりがちです。一方で、「安価な小型モデルへ差し替えると、指示追従の甘さやハルシネーションで見逃しが頻発するのではないか」という不安から、モデルの切り替えに踏み切れないケースも少なくありません。

しかし、幅広い文脈理解やトレードオフの裁定を要する「創造的生成タスク」には最高性能モデルが不可欠である一方、合否基準が明確に形式化された「ルール適合判定タスク」は、適切なアーキテクチャ設計を行えば小型・安価モデルで十分に実用的な検証ができる、と筆者は考えています。AIエージェントの監視コストと上流品質ゲートに関する考察 でも触れられているように、下流での手戻りを防ぐ検証ゲートの役割は極めて重要ですが、その実行基盤には必ずしもフロンティアモデルを単体で置く必要はありません。

本記事では、執筆規約と引用の対応を確かめる検証工程（R13チェック）の設計を題材に、LLM API のコスト構造の急所（入出力の単価差やプロンプトキャッシュの損益分岐点）を解き明かし、小型モデルへ安全にタスクを委任するための多層防御アーキテクチャとモデル選定の境界線を解説します。

小型モデルの実用化とタスク要求スペックの分離

なぜ今、検証工程において小型モデルの活用が現実的な選択肢となっているのでしょうか。その背景には、軽量トランスフォーマーモデルの推論効率の飛躍的な向上と、実務タスクの性質分解に関する知見の深まりがあります。

Segment の共同創業者である Calvin French-Owen は、自身のエッセイにおいて同社共同創業者の Peter Reinhardt の観察を引き合いに出し、ビジネスにおける日常業務の約 95% は即時の応答と定型的な判定を求める「token spewer」ワークであると述べています1。French-Owen は、従来の Sonnet クラスでは日次約 1 ドルかかっていたパーソナライズニュースの生成処理が、小型モデルである luna クラスを採用することで約 0.10 ドル（10 分の 1）へと劇的に圧縮できた実例を報告しています。

また、AI 研究者の Mithil Vakde による実証実験では、単一の RTX 5090 GPU を用い、わずか約 1.5 時間でスクラッチ学習させた 8 層の極小トランスフォーマーが、難関推論ベンチマークである ARC-AGI-1 の公開評価セットにおいて 44% というスコアを達成しました2。その計算コストはわずか約 0.67 ドルです。巨大なパラメータを持つフロンティアモデルに頼らなくとも、目的とアーキテクチャを絞り込んだ推論は驚くほど低廉に実現できることが示されています。

さらに、フロンティアモデルを提供する主要ベンダー自身も、小型モデルをサブタスク実行基盤として位置づけてきました。Anthropic が Claude Haiku 4.5 を発表した際にも、当時の前世代最先端モデルであった Claude Sonnet 4 と同等水準のコーディング性能を、3 分の 1 のコストと 2 倍以上の速度で提供していました3。同社は公式に、上位モデル（当時の Claude Sonnet 4.5）がシステム全体の複雑な計画立案を担い、複数の Claude Haiku 4.5 に対して並列にサブタスクを委任するマルチエージェントオーケストレーションを推奨アーキテクチャとして提示していました。

ここで重要になるのが、「創造的生成タスク」と「ルール適合判定タスク」の要求スペックの分離です。

  • 創造的生成タスク: 記事の企画立案、コードの全体アーキテクチャ設計、複雑な不具合の根本原因究明など。膨大なコンテキストの統合、曖昧な要求の解釈、複数のトレードオフの裁定が求められるため、フロンティアモデルの推論能力が必須。
  • ルール適合判定タスク: フォーマット準拠、命名規則の照合、引用元と本文の事実一致チェックなど。明確なルールセットと対象テキストが与えられ、両者が合致しているかを判定する作業。文脈の飛躍や独創的な解釈はむしろ有害であり、小型モデルの能力範囲内に収まりやすい。

コンテキスト肥大化とモデルルーティングを論じた過去記事 で指摘したとおり、すべての処理を単一の万能モデルに押し込む設計は経済的にも品質的にも持続可能ではありません。タスクの性質を見極め、要求スペックに見合ったモデルへ作業を切り分けることが最適化の第一歩となります。

コスト構造の急所：入出力の4〜5倍の価格差とキャッシュ損益分岐点

検証系サブエージェントの経済性を評価する際には、単にカタログの基本料金を眺めるだけでは不十分です。LLM API のコスト構造には、見落とされがちな「2つの急所」が存在します。

入力トークンと出力トークンの4〜5倍の価格差

第一の急所は、入力（Prefill）と出力（Decode）における大幅な単価格差です。現代の LLM サービングアーキテクチャにおいて、プロンプトの入力処理は GPU の並列計算能力を活かした計算律速（Compute-bound）で行われます。一方で、テキストの生成出力は過去のトークンを参照しながら 1 トークンずつ自己回帰的に生成するため、メモリ帯域幅に律速（Memory Bandwidth-bound）されます。

この計算機アーキテクチャ上の物理的な制約を反映して、主要な API 提供各社は出力トークンに対して入力トークンの 4〜5 倍の価格を設定しています456。

この格差がエージェント設計に突きつける教訓は明快です。「入力内容をそのまま出力させる処理に LLM を使ってはならない」 という原則です。例えば、ファイルのコピー、データの整形や抽出、Web ページの取得結果をそのままレスポンスとして書き出すような作業に LLM の生成能力を使わせると、入力の 5 倍のコストを支払うことになります。ファイルの複製には cp コマンドを、データ取得には curl や専用スクリプトといった決定論的ツールを直接呼び出させ、エージェントにはその実行結果の判定や最小限の差分のみを出力させる設計を徹底する必要があります。

Prompt Caching の割引と独立サブエージェントの損益分岐点

第二の急所は、Prompt Caching（プロンプトキャッシュ）の割引率と、独立サブエージェントへの委譲に伴う「コールドスタート」のトレードオフです。

Anthropic は 2024 年 8 月に Prompt Caching を導入し、キャッシュヒット時の読み出し単価を基本入力単価の 10%（90% 割引）へと大幅に引き下げました45。公式の料金表にはキャッシュ書込単価として 5 分と 1 時間の 2 種類（5m writes / 1h writes）が載っており4、1 時間以内の反復的なやり取りであれば、同一セッションを維持してコンテキストを使い回す方が安価になると考えられます。

ここで、検証タスクを独立したサブエージェントへ委任する際の損益計算が極めて重要になります。

  • 親セッション内での検証: 親エージェントが保持している会話履歴や参照ファイル群のキャッシュが効くため、読み出し単価は 90% 割引（最新の Claude Sonnet 5.5 なら $0.20 / MTok、前世代の Claude Sonnet 4 なら $0.30 / MTok）で処理できます。しかし、過去のやり取りや試行錯誤がコンテキスト内に大量に蓄積されているため、判定対象以外の無関係な情報に引っ張られ、検証の厳密さが損なわれるリスク（コンテキスト汚染）を抱えます。
  • 独立サブエージェントへの委任: 親セッションの履歴を切り離し、クリーンな状態で検証ルールと対象テキストのみを渡せるため、判定の純度を最高レベルに保てます。しかし、親セッションのキャッシュを引き継げないため、初回読み込み（コールドスタート）として基本入力単価（Claude Haiku 4.5 なら $1.00 / MTok）を支払う必要があります。

主要モデルのトークン単価を比較すると、出力単価はいずれも入力の 4〜5 倍に設定されており、Claude シリーズではキャッシュ読出単価が基本入力の 10%（90%割引）まで、GPT-4o mini でも 50% まで低減されます6。

モデル基本入力 ($/MTok)基本出力 ($/MTok)キャッシュ読出 ($/MTok)出力/入力比
Claude Sonnet 4$3.00$15.00$0.305.0倍
Claude Sonnet 5.5$2.00$10.00$0.205.0倍
Claude Haiku 4.5$1.00$5.00$0.105.0倍
GPT-4o mini$0.15$0.60$0.0754.0倍

ここで注目すべきは、最新世代におけるフロンティアモデルと小型モデルの価格差です。Claude Sonnet 5.5 の基本入力単価（$2.00）は Claude Haiku 4.5（$1.00）の 2 倍にとどまり、前世代の Sonnet 4（$3.00）と Haiku 4.5 の差（3 倍）より縮まっています。

しかし、この単価構造から導かれるもうひとつの重要な事実は、親セッションのキャッシュ読出（Sonnet 5.5: $0.20）に対して、独立サブエージェントの初回入力（Haiku 4.5: $1.00）は単価ベースで依然として 5 倍も高いという点です。基本単価差が 2 倍に縮まったからといって、サブエージェント委譲のコスト計算を単純に考えることはできません。

具体的に計算してみましょう。親エージェントが作業を重ね、セッションコンテキストが 50,000 トークンまで膨らんでいたとします。この状態で親エージェント（Sonnet 5.5）に検証を行わせると、キャッシュヒット時のコストは次のようになります。

50,000 tokens × ($0.20 / 1,000,000 tokens) = $0.010

一方、独立したサブエージェント（Haiku 4.5）へ検証を切り出す際、親のコンテキスト全体（50,000 トークン）をそのまま引き渡してしまうと、コールドスタートにより $1.00 / MTok の満額が課金され、1 回あたり $0.050（親セッション維持の 5 倍）に跳ね上がってしまいます。

独立サブエージェント化を経済的に成立させる鍵は、「コンテキストスライス（局所化）」 です。サブエージェントには親の履歴を一切渡さず、検証に必要な「規約ルール（約 2,000 トークン）」と「検証対象テキスト（約 3,000 トークン）」の計 5,000 トークンのみを切り出して渡します。

5,000 tokens × ($1.00 / 1,000,000 tokens) = $0.005

これにより、キャッシュが効いた親セッション（$0.010）と比較して半額（$0.005）になります。ただしこの差は2つの要因の合成です。同じ 5,000 トークンのスライスを Sonnet 5.5 のコールドスタート（$2.00 / MTok）で処理すると $0.010 で、親セッションのキャッシュ読出と同額です。つまり、スライスだけでは親セッション維持に並ぶのみで、Haiku 4.5 への差し替え（入力単価 2 分の 1）が加わって初めて半額になります。いずれも入力トークンのみの試算で、出力トークンとキャッシュ書込みの割増は含みません。

検証系サブエージェントの委任アーキテクチャ設計

小型モデルへの安全な委任を実現するためには、プロンプトの工夫だけで精度を担保しようとしてはなりません。

Eugene Yan はその論考において、単に LLM-as-a-judge を導入するだけではプロダクトの品質は改善せず、テスト駆動開発と同様に事前の評価基準設計やデータ観察を繰り返す「Eval-Driven Development（EDD）」のプロセスこそが不可欠であると論じています7。さらに Yan が整理した LLM システム構築パターン集にあるように、ガードレールや多層防御（Defense in Depth）をシステムレベルで組み込むことが極めて有効です8。

安価な小型モデルの指示追従性の揺らぎを吸収するため、次の多層防御アーキテクチャを提案します。

  1. 第1層（決定論的フィルタ）: 正規表現、外部スクリプト、スキーマバリデータなどの古典的なコードによる検査。構文エラーや明白なキーワード違反をゼロコストかつ 100% の再現性で即時検出する。
  2. 第2層（小型モデル検証）: 決定論的テストを通過した対象に対し、小型モデル（Claude Haiku 4.5 等）を用いて文脈上の意味論的整合性（セマンティックチェック）を判定する。
  3. 入力の極小化（1ルール1責務）: 複数の複雑な規約を一度に渡して総合判定させるのではなく、独立した単一ルールごとにコンテキストを絞り込んで判定させる。
  4. 出力の構造化（JSON 強制）: 出力トークン数を最小限に抑えるため、合否フラグと簡潔な理由のみを JSON 形式で返却させる。

以下は、この設計思想を具現化した TypeScript による検証モジュールの実装例です。

// ts:src/validators/rule-checker.ts
import Anthropic from "@anthropic-ai/sdk";

export interface ValidationRule {
  id: string;
  name: string;
  description: string;
  regexPattern?: RegExp;
}

export interface ValidationResult {
  ruleId: string;
  passed: boolean;
  reason: string;
  checkedBy: "regex" | "small-model";
}

const anthropic = new Anthropic();

/**
 * 決定論的チェックと小型モデル検証を組み合わせた多層バリデータ
 */
export async function validateContent(
  content: string,
  rule: ValidationRule
): Promise<ValidationResult> {
  // 第1層: 決定論的テスト（正規表現による高速・確実な機械判定）
  if (rule.regexPattern) {
    const isMatched = rule.regexPattern.test(content);
    if (!isMatched) {
      return {
        ruleId: rule.id,
        passed: false,
        reason: `正規表現パターン ${rule.regexPattern} に適合しませんでした。`,
        checkedBy: "regex",
      };
    }
  }

  // 第2層: 小型モデル（Claude Haiku 4.5）によるセマンティック検証
  // コンテキストをスライスし、対象文と単一ルール定義のみを渡す
  const prompt = `あなたは文書の規約準拠を判定する検証エージェントです。
以下のルールに照らして、対象テキストが準拠しているかを判定してください。

## ルール定義
- ID: ${rule.id}
- 名称: ${rule.name}
- 詳細: ${rule.description}

## 対象テキスト
"""
${content}
"""

出力は必ず以下のJSON形式のみで行ってください。余計な前置きや解説は含めないでください。
{"passed": true|false, "reason": "判定理由"}
`;

  const response = await anthropic.messages.create({
    model: "claude-haiku-4-5",
    max_tokens: 300,
    messages: [{ role: "user", content: prompt }],
  });

  const textBlock = response.content.find((block) => block.type === "text");
  if (!textBlock || textBlock.type !== "text") {
    throw new Error("モデルからテキスト応答が得られませんでした。");
  }

  const parsed = JSON.parse(textBlock.text.trim()) as {
    passed: boolean;
    reason: string;
  };

  return {
    ruleId: rule.id,
    passed: parsed.passed,
    reason: parsed.reason,
    checkedBy: "small-model",
  };
}

この実装における設計の急所は以下の3点です。

  • 早期リターンによる API コールの削減: rule.regexPattern による検査を先行させることで、自明な違反は LLM API を呼び出すことなくミリ秒単位・コストゼロで弾かれます。
  • コンテキストの厳密な局所化: プロンプトに渡しているのは対象テキストと単一のルール定義のみです。親エージェントの会話履歴や不要なメタ情報を削ぎ落とすことで、コールドスタートの課金トークン数を最小化しています。
  • 出力トークンの極小化: 出力形式を最小限の JSON に制限し、max_tokens: 300 を設定することで、高価な出力トークンの消費を物理的にブロックしています。

エージェントパイプラインにおけるモデル選定の境界線

多段エージェントパイプラインを設計する際、どのタスクを安価な小型モデルへ委任し、どのタスクをフロンティアモデルに残すべきでしょうか。実務における境界線の判断基準を以下に示します。

小型・安価モデルへ委任できるタスク

  • 規約・構文・フォーマットの検証: 本文の主張と脚注番号の一致照合（R13チェック）、Markdown 記法や見出し階層のバリデーション、命名規約のチェック。
  • データ抽出と分類: 長文ドキュメントからの特定キー・事実関係・日付の抽出、エラーログのカテゴリ分類。
  • 外部ツール実行結果の解釈: CLI ツールやテストスイートのエラーログを読み取り、失敗箇所を要約する作業。
  • 構造化データの変換: 自由形式テキストから JSON や YAML スキーマへの変換。

フロンティアモデルに残すべきタスク

  • システム全体の要件定義と計画立案: 要求仕様の曖昧さを解釈し、全体のタスク依存関係（DAG）を設計するオーケストレーション。
  • トレードオフの判断と優先順位の裁定: パフォーマンスと可読性の衝突、複数のアーキテクチャ案の比較評価など、絶対的な正解が存在しない意思決定。
  • 未知のエラーに対する原因究明: 複数システムにまたがる障害において、仮説を多角的に組み立てて検証を進める高度なデバッグ。
  • 高度な文脈推敲とトーンの調整: 読者の心理や前提知識を汲み取り、記事全体のストーリー構成や論理展開を微調整する文章執筆。

モデル選定の境界線を決める究極のルールは、「合否判定の正解（期待される出力や違反条件）が事前に明確に言語化・形式化できるか否か」 です。正解の基準が明確であれば、どれほど厳格なチェックであっても、コンテキストを絞り込んだ小型モデルと決定論的テストの組み合わせによって、安価に委任できると考えられます。ただし小型モデルの見逃し率は未測定のため、委任後は少数の既知の違反例（ゴールデンセット）を定期的に通して検出率を測り、下回れば上位モデルへ戻す運用を前提にします。

よくある質問（FAQ）

Q. 小型モデルに検証を任せるとハルシネーションや見逃しが増えませんか？

A. 合否判定の基準を単一ルールに絞り込み、決定論的な機械テスト（正規表現やスキーマバリデータ）と組み合わせることで、見逃しや誤判定を抑えやすくなる、というのが筆者の仮説です。小型モデルが苦手とするのは「曖昧な基準での総合評価」と考えられるため、評価対象を 1 つの明確な規約に限定します。上位モデルとの検出率の差は未測定です。導入時に手元の既知違反例で測ることを勧めます。

Q. サブエージェントを呼ぶと親セッションのキャッシュが切れて逆に高くつきませんか？

A. 独立サブエージェントは親セッションのキャッシュを引き継げないためコールドスタートのコストが発生しますが、小型モデルへの差し替えによる単価圧縮（Sonnet 5.5 比で 1/2、Sonnet 4 比で 1/3）に加えて「コンテキストを検証対象だけに絞り込むスライス」を行うことで、入力のみの試算では親セッション維持の半額になります。親の肥大化したコンテキスト全体を渡さず、必要なルールと対象文のみに限定することが損益分岐点を超える鍵です。

まとめ

本記事で解説した検証系サブエージェントの最適化指針を、以下の要点命題としてまとめます。

  • タスクの要求スペックを分離する: 創造的な推論や大局的な意思決定にはフロンティアモデルを使い、明確な合否判定には小型安価モデルを割り当てる。
  • 出力とコールドスタートのコスト構造を意識する: 出力トークンは入力の 4〜5 倍高価であり、ファイルコピーやデータ取得にはシェルコマンド（cp / curl）を徹底する。
  • プロンプト単体に頼らず決定論的テストと多層化する: 小型モデルの指示追従性の揺らぎは、正規表現や外部スクリプトなどの決定論的フィルタとの組み合わせで吸収する。
  • キャッシュと単価の損益分岐点を計算する: 独立サブエージェントのコールドスタートによる割高感は、小型モデルによる単価圧縮とコンテキストスライスの掛け算によって、入力のみの試算では相殺・逆転できる。
  • 次世代小型モデルの進化に備える: Haiku 5.5 のような新世代の小型モデルの登場に期待し、検証モジュールをいつでも低コストモデルへ差し替えられる疎結合な設計を維持する。

マルチエージェントパイプラインのコスト最適化や、用途に応じたモデルルーティングアーキテクチャの設計・PoC 検証について、ぜひ コンタクトフォーム よりお気軽にご相談ください。

Footnotes

  1. Small Models Have Arrived Calvin French-Owen、2026年。日次ニュース生成のコスト1/10化は本文冒頭、日常業務の約95%が定型的な「token spewer」ワークである点はPeter Reinhardtの観察として言及。 ↩

  2. 44% on ARC-AGI-1 in 67 cents Mithil Vakde、2026年。単一GPUによる1.5時間学習、8層トランスフォーマーでの44%達成および計算コスト約 0.67 ドルの実証。 ↩

  3. Introducing Claude Haiku 4.5 Anthropic、2025年10月15日。Sonnet 4同等のコーディング性能と1/3のコスト・2倍以上の速度、上位モデルと組み合わせたマルチエージェント推奨アーキテクチャの公式発表。 ↩

  4. Pricing Anthropic、2026年。Claude Haiku 4.5、Claude Sonnet 5.5、Claude Sonnet 4の入力・出力単価（出力は入力の5倍）とプロンプトキャッシュ読出単価（90%割引）の公式料金仕様。 ↩ ↩2 ↩3

  5. Prompt caching with Claude Anthropic、2024年8月14日（2024年12月17日更新）。Prompt Cachingによる最大90%のコスト削減（入力の10%）および会話エージェント反復利用時の有効性。 ↩ ↩2

  6. OpenAI API Pricing OpenAI、2026年。GPT-4oおよびGPT-4o miniの入力・出力単価（出力は入力の4倍）とキャッシュ入力単価（50%割引）の公式料金仕様。 ↩ ↩2

  7. An LLM-as-Judge Won’t Save The Product—Fixing Your Process Will Eugene Yan、2025年4月20日。評価器単体導入の限界と、データ観察・仮説検証・評価駆動開発（EDD）のプロセス設計の重要性。 ↩

  8. Patterns for Building LLM-based Systems & Products Eugene Yan、2023年7月。ガードレール、多層防御、プロンプトキャッシュ、フォールバックなどのアーキテクチャパターン体系。 ↩