複雑な Agent の Goodput を 96.3 倍に高める設計

同じ品質基準と 8 分の SLA 制約の下で、プロトタイプ設計 Agent の平均タスクコストを 21.80 ドルから 0.88 ドルへ削り、P95 端点間遅延を 55.4 分から 7.6 分へ収縮させ、100 ドル当たりの合格納品数（Agent Goodput）を 96.3 倍向上させた。

この取り組みは、本番環境で頻発していたある痛点から始まった。ユーザーが単一ページのコンポーネントスタイルやボタンのラベルを少し修正しただけで、制約のない Agent が自由探索の中でコードベース全体の再構築を引き起こしてしまう問題だ。数分で終わるはずの微修正が、60 分以上の時間と 30 ドルを超えるモデル API 費用を費やす計算のブラックホールへと化していた。

この局所的な再構築トラブルは、複雑な Agent システムを本番運用する際の根本的な課題を映し出している。タスクグラフの依存度がシステムの複雑さとともに増加すると、境界のない非決定的な推論がシステム全体を振動とエントロピーの渦へ巻き込んでしまう。

このような複雑な Agent システムを最適化するには、三つのコア境界を定義する必要がある。

1. 終端境界： どのような条件でタスクを真の「完了」と定義するか。
2. 推論境界： どの状態遷移に大規模モデルの非決定的な推論が必要か。
3. 制御境界： 確定した計算とルールフローをいかに高速に実行するか。

本稿は、数か月にわたるアーキテクチャの変遷を整理する。システムは、モデルの自由探索に依存する ReAct から、契約による分離、決定的 Workflow、コンテキストトポロジーの最適化を中心とする高効率な構成へ収束した。

1. 事後 Review パターンの遅延とコストの罠

初期アーキテクチャでは、ReAct が生成ライフサイクル全体を駆動していた。Agent は現在の状態から次の行動を推論し、ツールでコードの作成や検証を行い、その結果を見て生成、修復、終了のいずれかを選んでいた。

品質の下限を守るため、ReAct ループには複数の Review チェックポイントが追加された。ページ生成後には必ず Review へ入り、欠陥があれば修復し、再び検証する。

flowchart LR
    A["ページ実装"] --> B["Review"]
    B -->|"問題あり"| C["修復"]
    C --> B
    B -->|"合格"| D["納品"]

この構成は低品質な成果物を納品前に止めたが、システム工程の観点からは事後 Review への依存が深刻なボトルネックとなった。

• 計算経路の膨張： Review のたびにコンテキストを再読み込みし、モデルを呼び出し、ツールを実行する。修復が正しいモジュールまで書き換え、二次的な Review を誘発する。
• 長いテール遅延： 複雑なタスクではモデルコストが 20 ドルを超え、エンドツーエンド時間が 60 分を超えることが珍しくなかった。
• SLA の予測不能： 単純なタスクでも評価の揺らぎから Review を繰り返し、サービス時間の約束を維持しにくくなった。

品質の穴を埋める一方で、Review 重視の構成は非常に典型的なテールコストを示した。

このデータは直感に反する実態を示している。事後 Review は品質の下限を引き上げるが、有効なデリバリー能力を高めるわけではない。 むしろ、より多くのコストを支払いながら、完了時間をより不確実なものにしていた。

最適化の方向性は、成功率だけを追い求めることから、制御可能なコストと遅延の制約下で実用的なパフォーマンスを提供することへと転換した。

2. 定量ベースライン：Agent Goodput の工学定義

アーキテクチャ改善の成果を厳密に測定するため、ネットワーク工学や分散システムの考え方を準用し、Agent Goodput を中心指標として導入した。

ネットワーク工学において、Throughput は物理回線上に送信された全パケットの総量を指す。一方、Goodput はオーバーヘッドやエラーを除去し、アプリケーション層に正常に到達した有効データのみをカウントする。

これを Agent システムに適用すると：

• Token や Request の Throughput は、単なるモデル呼び出しの計算消費量や交互回数を示す。
• Agent Goodput は、無効な探索、冗長な Review、タイムアウト再試行を排除し、システム単位コスト（100 ドル）当たりに SLA 内で正常納品できた合格プロトタイプ数を示す。

定義式は以下の通りだ。

つまり、100 ドルのモデル計算費で、約束した時間内に合格品質のプロトタイプを何件届けられるかを測る。

分子と分母には明確な条件がある。

• 分子： プロダクト完成度の基準を満たし、かつエンドツーエンド SLA 内に完了したタスクだけを含める。
• 分母： Token、ツール実行、中間 Review、失敗タスクの再試行、中止までに消費したリソースをすべて含める。

Agent Goodput は最適化の順序も決める。まず品質を納品基準まで引き上げ、次に遅延を妥当な範囲へ収束させ、その条件の中で計算コストを最小化する。

3. アーキテクチャ分離：契約駆動と Plan 先行

旧構成の非効率さの根本原因は、判断密度の分散にあった。オープンな ReAct ループにおいて、各ページ生成ノードが独自にプロダクト全体を解釈しようとしたため、設計上の判断が散在し、スタイルのブレや繰り返しの修復を引き起こしていた。

解決策は、非決定的な設計推論を実行前に集約し、明示的な Plan ノード を導入することだ。コード実装に入る前に、三つのシステム級契約を確定させる。

1. タスク分割契約： ページツリー構造、ルーティング、各ページの境界を固定する。
2. 共有制約契約： 全体の視覚 Token、共通 UI コンポーネント、データフロー規約を集約する。
3. 受け入れ契約： タスク完了を客観的に判定するルールとゲートを定義する。

flowchart TD
    subgraph NEW["契約分離と Plan 先行アーキテクチャ"]
        N1["Plan ノードが全体契約を生成"] --> N2["境界内でページ A を実装"]
        N1 --> N3["境界内でページ B を実装"]
        N1 --> N4["境界内でページ C を実装"]
        N2 --> N5["決定的な受け入れゲート"]
        N3 --> N5
        N4 --> N5
    end

契約の先行定義により、全体設計と局所実装が分離された。Plan ノードが高不確実な推論を引き受け、下流タスクは確定した契約の内部に制限される。事後 Review も契約に対する決定的な検証へ単純化され、不必要なモデル呼び出しが大幅に削減された。

4. トポロジー再構成：並列実行と Prefix Cache 共有

全体契約の確立により、サブタスクを独立して並列に推進する道が開かれた。しかし、そのまま並列化しただけでは、コンテキスト膨張と分岐遅延の蓄積という新たな壁に突き当たる。

これに対し、二つの面から再構成を行った。

4.1 クリティカルパス分離と分岐並列化

Plan 後のページタスクは同じプロダクト事実を共有するため、エンドツーエンド時間は直列の合計ではなく、最も遅いクリティカルパスによって決まる。

• 直列時間： \( T_{\text{serial}} \approx T_{\text{plan}} + \sum T_{\text{page}} + T_{\text{gate}} \)
• 並列時間： \( T_{\text{parallel}} \approx T_{\text{plan}} + \max(T_{\text{page}}) + T_{\text{gate}} \)

ページ数別の評価データから、並列化の成果は一目瞭然だ。

旧構成ではページ数に比例して時間が増加していたが、新構成では並列幅の増加で吸収でき、クリティカルパスは伸びない。納品率も安定しており、Plan が品質の下限を実行前へ移動できたことを証明している。

4.2 ツリー状 Prompt トポロジーと KV Cache 再利用

単に並列実行するだけでは、各分岐が全体要件やコンポーネント定義を重複して読み込み、Token コストが急増する。

このボトルネックを解消するため、入力コンテキストのトポロジーを再構成した。Prompt を全体静的 Prefix（全体要件、規約、ライブラリ）と局所動的タスク（現在の分岐命令）に分離する。

flowchart TB
    P["全体静的 Prefix<br/>要件 · 構造 · 視覚制約 · 規約"]
    P -->|"Prefix Cache を共有"| A["ページ A 局所タスク"]
    P -->|"Prefix Cache を共有"| B["ページ B 局所タスク"]
    P -->|"Prefix Cache を共有"| C["ページ C 局所タスク"]

推論エンジンの Prefix Cache 機能を使い、全体 Prefix を KV キャッシュとして保持することで、並列分岐がこれを共有する。初期書き込みコストが分散され、複雑な入力の読み込みコストが大幅に抑えられた。

この構造により、並列コストの増加曲線は加算（\(O(N)\)）から一度書き込んで何度も再利用する形（\(O(1)\)）へ変化した。コンテキストトポロジーの最適化だけで、5〜6 ページのタスク全体コストは 56% 低減した。

5. 制御収束：有界状態機械と決定性ゲート

判断の境界とコンテキストコストを解決した後、最後のボトルネックである ReAct ループによる実行エントロピー に対処した。

ReAct は未知空間の探索には適している。しかし、目標と受け入れ契約が定義された後で、モデル自身に Review を反復させるのは、無限ループとテールの遅延を引き起こす原因となる。

制御権をモデルから取り戻し、決定的な状態機械 による Workflow を構築した。

flowchart LR
    P["Plan<br/>Agent による探索"] --> E["ブランチ並列<br/>Workflow 制御"]
    E --> G["契約ゲート<br/>ルール検証"]
    G -->|"合格"| D["納品"]
    G -->|"失敗"| R["例外修復<br/>局所 Agent"]
    R --> G

有界な制御フローにおける役割：

• 状態機械 Workflow： 並列数、タイムアウト、リトライ上限を管理する。
• ルールゲート： 客観的で低遅延な Pass/Fail シグナルを出す。
• Agent 範囲： 初期 Plan の判断と、ゲート失敗時の 局所的な修復 に限定する。

検証に合格すれば即座に終了し、失敗時には該当モジュール内だけにコンテキストを絞って修復する。

状態機械による制御は、時間の遅延とコストに対して極めて明確な収束境界を設けることに成功した。

8 分という上限は偶然の良データではなく、制御フローの設計によって約束された境界だ。並列制限、局所修復、終了条件が、システムが再び無限 Review に落ち込むのを確実に防いでいる。

6. Throughput 全体像とタスクグラフ再構成パターン

200 サンプルの標準評価セット（2〜6 ページ、8 分 SLA）において、これら三つの変換により Agent Goodput は飛躍的に高まった。

業界における Agent の効率化のアプローチを振り返ると、多様な視点が存在する。

• OpenAI は評価基線（Evals）の確立と、軽量タスクを小型モデルへ回すモデルカスケード（Model Cascading）を推奨する。
• Anthropic は制御経路を最小限に保ち、非決定的な分岐でのみ推論を使うべきだと主張する。
• EvoRoute や AI21 Maestro は、動的ルーティングやマルチ Agent の構成探索に注力している。

これらの優れた視点を取り入れつつ、我々は根本的な違いを見出した。モデルルーティングの最適化が「与えられたノードを誰が推論するか」を解くのに対し、我々の再構成は「その推論ノード自体が必要かどうか」を解く。

Plan で契約を固めることで、無制限な探索を確定的なフローとゲートに収束させる。ルーティングは実行モデルを決定するが、タスクグラフ自体の再構成は冗長な推論そのものを元から消し去る。

7. 結語：オンライン阻断からオフライン品質フライホイールへ

複雑な Agent システムの進化は、事後 Review に頼る粗放探索期、契約で不確定性を削る構造分離期、そして状態機械で境界を作る有界制御期という三つの段階を通過した。

このプロセスは三つの基本原則に従っている。

この有界 Workflow により、オンライン上の同期 Review は決定的なルールゲートに置き換わり、エンドツーエンドの遅延は SLA 内に固定された。しかし、Review の過程で収集されたエラー分類、連携の不具合、修復 Trace は、それ自体が極めて貴重なデータ資産である。

Review をオンラインのクリティカルパスから完全に分離した今、これらの診断シグナルをバックグラウンドの非同期ループへ送り込み、専用小モデルのファインチューニング、RLHF/DPO の偏好学習、ルールゲートの動的進化に活用していくことが、Agent システム工学の次なる探求領域となる。

参考・関連資料

1. Anthropic, Building Effective Agents: https://www.anthropic.com/research/building-effective-agents
2. OpenAI, OpenAI Evals Framework: https://github.com/openai/evals
3. EvoRoute Research, Dynamic Model Routing for LLM Agent Workflows
4. AI21 Labs, Maestro: Multi-Agent Orchestration Engine