複雑なAgentの有効デリバリー効率を96.3倍に高めるまで

生成AIにおけるプロトタイプ設計Agentは、典型的な複雑タスクシステムの一つだ。自然言語の要件を、操作可能で実行できる完全なプロダクトプロトタイプへ変換することを目的とする。

その過程には、要件理解、方式設計、ページ分割、並列実装、統合検証、反復修復が含まれ、全体として動的なタスクグラフを形成する。プロトタイプが複雑になるほどノード間の依存は増える。局所的なコンポーネントの不整合、視覚ルールからの逸脱、インタラクションの断絶が連鎖的な修復を引き起こし、全体設計の誤りはタスクグラフ全体を無効にすることさえある。

この種のシステムを最適化するには、三つの境界を定義する必要がある。

1. 最終結果の境界： 何をもって本当に「完了」とするのか。
2. 推論の境界： どの状態遷移に大規模モデルの非決定的推論を使うべきか。
3. 制御の境界： 決定済みの計算やルールベースの処理を、どう効率よく実行するか。

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

1. 失敗した最適化：事後Reviewがコストと遅延のブラックホールになる

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

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

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

この構成は低品質な成果物を納品前に止めたが、事後Reviewへの依存は大きな副作用を生んだ。

• 計算経路の肥大化： Reviewのたびにコンテキストを読み込み、モデルを呼び出し、ツールを実行する。修復が正しいモジュールまで書き換え、新たなReviewを誘発することもある。
• 長いテールレイテンシ： 複雑なタスクではモデルコストが20ドルを超え、エンドツーエンド時間が60分を超えることが珍しくなかった。
• 結果の予測可能性低下： 単純なタスクでも評価の揺らぎからReviewを繰り返し、サービス時間を約束しにくくなった。

複雑度を揃えた代表サンプルでは、Review中心のバージョンに明確なロングテールが現れた。

数字が示すのは直感に反する結果だ。Reviewを増やすと品質の下限は上がるが、有効なデリバリー能力は上がらない。システムはより多くのコストを払いながら、完了時間をより予測しにくくしていた。

そこで最適化の目標は、成功率だけを高めることから、制御可能なコストと遅延の範囲内で実用的な成果を届けることへ変わった。

2. 指標の再定義：「有効デリバリー効率」

アーキテクチャ改善の効果を測るため、システムは有効デリバリー効率を中心指標として導入した。

一般的なスループットは処理したリクエスト数を数える。有効スループットはサービス品質を満たしたリクエストだけを数える。Agentでは一つのユーザー要求に数十回のモデル呼び出しと複数回の内部修復が含まれるため、評価単位は完成した納品物でなければならない。

定義は次の通りだ。

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

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

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

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

以下の比較では、同じ構造のタスクを使って各段階を正規化した。各段階40件、合計200サンプルで、2〜6ページのタスクを含み、納品SLAは8分に統一した。コストには失敗、中止前の消費、再試行を含む。旧版は過去の挙動と同一タスクの再生から推定し、現行版はstaging traceの水準で校正している。これはアーキテクチャの傾向を示す値であり、財務監査用の数値ではない。

転換点は安いモデルへの変更ではない。不要な推論を先に削り、残った推論を高い並列度とキャッシュヒット率で実行したことにある。Reviewを重ねた5月はむしろ効率の最低点となった。品質の下限だけを上げても、システム全体が有効になるわけではない。

3. 第1段階：Planを前に置き、不確実性を集中させる

新しい指標は、実装前に不確実性を圧縮する設計を促した。

実装の前に明示的なPlanノードを置き、三種類のシステム契約を定義した。

1. タスク分割契約： ページツリーと各ページの境界。
2. 共有制約契約： 全体の視覚ルール、共通コンポーネント、データフロー。
3. 受け入れ契約： タスク完了を判定する客観的条件。

graph TD
    subgraph OLD[旧アーキテクチャ]
        O1[ページAが要求全体を解釈] --> O2[実装] --> O3[全体Reviewでずれを発見] --> O4[再構築]
    end

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

旧構成では、各ページ生成ノードがプロダクト全体を独自に解釈し、判断の重複と方向のずれを生んでいた。Planノードが全体設計の判断を前に移すことで、下流タスクは明確な境界内の局所実装に集中できる。

事後Reviewは決定的ゲートと局所修復へ置き換えられた。成果物を事前定義した納品契約と照合し、区別のない長いモデルReviewを減らした。

4. 第2段階：安全な並列化とコンテキストトポロジー

全体契約が安定すると、ページ単位の並列実行と共有コンテキストのキャッシュが可能になる。

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が末端Reviewの担っていた品質下限を実行前へ移せたことが分かる。

4.2 ツリー状コンテキストとPrefix Cache

並列ページは、全体要件、プロダクト構造、視覚制約など大量のコンテキストを共有する。

新構成では入力を全体静的Prefixと局所動的タスクに分離した。

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

推論エンジンは全体PrefixをKV Cacheとして保持し、各並列ブランチが再利用する。

プロトタイプが複雑でページ数が多いほど相対効果は大きい。最初の書き込みコストを複数ブランチで分担すると、複雑なタスクでは重複コンテキストの取得コストが80%以上減少した。

「80%以上」は複雑タスクにおける重複コンテキスト取得の削減率であり、タスク全体のコストではない。各ページ固有の実装生成、ツール、ゲートは残る。それでもコンテキストトポロジーの変更だけで、5〜6ページのタスク全体コストは56%下がった。

5. 第3段階：オープンなReActから有界Workflowへ

タスク境界とコンテキストコストを整理した後、システムはReActループが生む不確定な実行時間に対処した。

ReActは未知空間の探索に向く。しかし目標と受け入れ条件が明確になった段階で、Reviewを続けるかどうかまでモデルに委ねると、実行のエントロピーが増える。

新構成は決定的な処理をReActから取り出し、状態機械のWorkflowへ戻した。

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

この制御フローでは、

• Workflow が並列数、タイムアウト、再試行予算を管理する。
• ゲート が客観的な検証シグナルを提供する。
• Agent はPlan時の開かれた判断と、ゲート失敗後の有界な局所修復に集中する。

ゲートを通過すればWorkflowは即座に終了し、意味のない最適化ループを止める。失敗した場合も修復コンテキストを該当モジュールに限定し、全体の再実行を避ける。

この制御によってレイテンシのロングテールは縮小した。現行の標準化された成功サンプルでは、エンドツーエンド時間の最小値は2.1分、P50は4.1分、P95は7.6分、最大値は8.0分である。単純なタスクは約2分、複雑なタスクも8分のSLA内に収まる。

コストのロングテールも同時に縮小した。単純なプロトタイプは0.6ドルまで下がる。ページ数やインタラクションが増えればコストは上がるが、無限Reviewによって際限なく増幅されることはない。

重要なのは、8分が偶然得られた良い観測値ではなく、制御フローが設計した境界だという点だ。ブランチ並列、再試行予算、局所修復の範囲、終了条件が、システムを再び無限Reviewへ滑り込ませない。

6. アーキテクチャ上の示唆：タスクグラフ自体を最適化する

Agent効率化の代表的なアプローチは、与えられたタスクグラフ上でモデルの割り当てを最適化する。

• Anthropic は最小構成から始め、必要なときだけ複雑さを増やすことを勧める。
• OpenAI は品質ベースラインを作った後で小型モデルを試すことを勧める。
• EvoRoute などの研究は、ステップごとに適切なモデルを選ぶ動的ルーティングを使う。
• AI21 Maestro は複数Agentの構成空間から協調設定を探索する。

このシステムの進化は、タスクグラフそのものの再構成に重点を置く。

flowchart LR
    subgraph ROUTE["モデルルーティングの最適化"]
        R1["与えられたタスクグラフ"] --> R2["モデルを選択"] --> R3["ルーティングを最適化"]
    end
    subgraph SYSTEM["本システムの最適化"]
        S1["タスクグラフを再構成"] --> S2["Planを前置"] --> S3["契約で分離"] --> S4["制御フローを収束"]
    end

モデルルーティングは実行主体を決める。一方、Planの制約、決定的Workflow、受け入れゲート、Prefix Cacheのトポロジーは、不要な推論そのものを減らす。

7. 結論

アーキテクチャは三段階で変化した。

1. 粗い探索期： Reviewによって品質の下限を守る。
2. 構造分離期： Planへ不確実性を集め、契約、並列化、Prefix Cacheで計算トポロジーを最適化する。
3. 制御収束期： オープンなReActを決定的Workflowへ置き換え、コストと遅延の境界を作る。

5月の安定版を基準とし、品質基準とSLAを同じにすると、100ドル当たりの合格プロトタイプ数は約1.03件から99.43件へ増え、有効デリバリー効率は約96.3倍になった。より具体的には、Review中心の構成で20ドルを超えることが多かったタスクを、単純なケースなら約0.6ドルで完了できる。

複雑なAgentの最適化には三つの原則がある。

アーキテクチャの中心的な責務は、モデルを呼び出す前に、その推論が本当に必要かを判断することにある。