https://lutra.icu/ja/notes/Recent content in ノート on LUTRA.ICUHugoja© LUTRA.ICUTue, 04 Aug 2026 19:00:00 +0800https://lutra.icu/ja/notes/agent-effective-delivery-efficiency/Tue, 04 Aug 2026 19:00:00 +0800https://lutra.icu/ja/notes/agent-effective-delivery-efficiency/<p>生成AIにおけるプロトタイプ設計Agentは、典型的な複雑タスクシステムの一つだ。自然言語の要件を、操作可能で実行できる完全なプロダクトプロトタイプへ変換することを目的とする。</p> <p>その過程には、要件理解、方式設計、ページ分割、並列実装、統合検証、反復修復が含まれ、全体として動的なタスクグラフを形成する。プロトタイプが複雑になるほどノード間の依存は増える。局所的なコンポーネントの不整合、視覚ルールからの逸脱、インタラクションの断絶が連鎖的な修復を引き起こし、全体設計の誤りはタスクグラフ全体を無効にすることさえある。</p> <p>この種のシステムを最適化するには、三つの境界を定義する必要がある。</p> <ol> <li><strong>最終結果の境界：</strong> 何をもって本当に「完了」とするのか。</li> <li><strong>推論の境界：</strong> どの状態遷移に大規模モデルの非決定的推論を使うべきか。</li> <li><strong>制御の境界：</strong> 決定済みの計算やルールベースの処理を、どう効率よく実行するか。</li> </ol> <p>本稿は、数か月にわたるアーキテクチャの変遷を整理する。システムは、モデルの自由探索に依存するReActから、契約による分離、決定的Workflow、コンテキストトポロジーの最適化を中心とする高効率な構成へ収束した。</p> <hr> <h2 id="1-失敗した最適化事後reviewがコストと遅延のブラックホールになる">1. 失敗した最適化：事後Reviewがコストと遅延のブラックホールになる</h2> <p>初期アーキテクチャでは、ReActが生成ライフサイクル全体を駆動していた。Agentは現在の状態から次の行動を推論し、ツールでコードの作成や検証を行い、その結果を見て生成、修復、終了のいずれかを選んでいた。</p> <p>品質の下限を守るため、ReActループには複数のReviewが追加された。ページ生成後には必ずReviewへ入り、欠陥があれば修復し、再び検証する。</p> <figure class="mermaid-figure"> <pre class="mermaid">graph LR A[ページ実装] --&gt; B[Review] B -- 問題あり --&gt; C[修復] C --&gt; B B -- 合格 --&gt; D[納品]</pre> </figure> <p>この構成は低品質な成果物を納品前に止めたが、事後Reviewへの依存は大きな副作用を生んだ。</p> <ul> <li><strong>計算経路の肥大化：</strong> Reviewのたびにコンテキストを読み込み、モデルを呼び出し、ツールを実行する。修復が正しいモジュールまで書き換え、新たなReviewを誘発することもある。</li> <li><strong>長いテールレイテンシ：</strong> 複雑なタスクではモデルコストが20ドルを超え、エンドツーエンド時間が60分を超えることが珍しくなかった。</li> <li><strong>結果の予測可能性低下：</strong> 単純なタスクでも評価の揺らぎからReviewを繰り返し、サービス時間を約束しにくくなった。</li> </ul> <p>複雑度を揃えた代表サンプルでは、Review中心のバージョンに明確なロングテールが現れた。</p>