AIエージェントは、動けば終わりではありません。実運用では、失敗時の切り分け、出力の安定性、コスト管理まで含めて設計する必要があります。
GoogleのAgent Development Kit（ADK）は、その課題に対して「単体の巨大プロンプトを、役割分担した複数エージェントへ分解する」という答えを示しました。Sales Researchの試作を本番向けに作り直した事例では、モノリシックなPythonスクリプトをやめ、SequentialAgentで処理を分割し、構造化出力、動的RAG、OpenTelemetry観測を組み合わせています。
この記事でわかること
– ADKがなぜ「本番向けのエージェント基盤」として扱われるのか
– モノリス型エージェントが壊れやすい理由
– 複数エージェント分割、構造化出力、RAG、観測基盤の役割
– 実運用でコストと障害を抑える設計の考え方
https://developers.googleblog.com/production-ready-ai-agents-5-lessons-from-refactoring-a-monolith/
モノリスを分割する意味
試作段階のAIエージェントは、1本の長い処理でまとめた方が早く見えます。しかし、APIタイムアウトや幻覚、途中の失敗が起きた瞬間に全体が止まります。Googleの事例では、ここが最初の問題でした。単純な for ループの中に検索、要約、選別、メール作成まで押し込むと、どこで壊れたか分からなくなります。
ADKが強いのは、この構造を前提から変えられる点です。処理を Company Researcher、Search Planner、Case Study Researcher、Selector、Email Drafter のように役割ごとへ分けると、失敗範囲が狭くなります。エージェント設計では「賢い1体」より「狭い役割を持つ複数体」の方が保守しやすい、という基本がはっきり見えます。
構造化出力で壊れやすいJSONをやめる
AIアプリが壊れる典型例は、生成結果のパースです。プロンプトの中で「この形式で出してください」と長く指示しても、出力が崩れた瞬間に処理が止まります。Googleの事例では、ここをPydanticで置き換えています。
重要なのは、自然文でのお願いに検証を任せないことです。スキーマをコード側で持ち、ランタイムで検証する方が確実です。これにより、プロンプト内にJSON例を何度も書く必要がなくなり、トークンの無駄も減ります。AIエージェントを業務に載せるなら、出力の自由度より契約の厳密さを優先すべきです。
動的RAGで知識を固定しない
RAGは Retrieval-Augmented Generation の略で、外部データを検索してから生成に使う仕組みです。ここで問題になるのは、検索元をハードコードしてしまうことです。試作では12件の事例だけを埋め込んでいたため、追加学習も更新もできませんでした。
ADKの事例では、バックグラウンドのクローラでデータを集め、Vector Search に流し込み、Hybrid Search で意味検索とキーワード検索を両立させています。これが重要なのは、エージェントが「知っていること」ではなく「今引けること」で成果が決まるからです。固定データのままでは、AIはすぐ陳腐化します。
観測できないAIは本番に置けない
AIエージェントは、ブラックボックス化しやすいです。失敗したことは分かっても、どの工程で壊れたかが見えません。そこでADKはOpenTelemetryと組み合わせて、トレースを取れるようにしています。
これは単なるデバッグ機能ではありません。モデル呼び出し、ツール実行、遅延、再試行回数まで追えるなら、障害対応だけでなくコスト管理にも効きます。特にエージェントは、失敗時に再試行を重ねて料金が膨らみやすいので、観測基盤は機能の一部です。見えないものは改善できません。
料金ではなく運用コストを見る
AIサービスは、月額料金だけでは判断できません。本当に見るべきなのは、失敗したときの再実行コスト、不要なトークン消費、障害時の人件費です。Googleの事例が示すのは、ADKのような枠組みを使うと、タイムアウト、バックオフ、リトライ境界を標準化しやすいという点です。
つまり、安いモデルを選ぶだけでは足りません。壊れにくい分割、厳密な出力、更新可能な知識源、観測可能な実行系をそろえて初めて、運用コストが下がります。AIエージェントの価値は「何ができるか」だけでなく「どれだけ安定して続けられるか」で決まります。
どんなチームに向くか
ADKの考え方は、実験用のチャットボットより、業務フローを持つチームに向いています。営業調査、情報収集、文書生成、承認付きワークフローのように、工程が複数ある仕事ほど相性がいいです。
逆に、1回の応答で終わる単純な用途なら、ここまでの構造化は過剰です。導入判断は「何を自動化したいか」ではなく、「失敗時にどこまで責任を切り分けたいか」で決めるべきです。責任境界を引けるなら、AIエージェントは試作から運用品質へ上げやすくなります。
Google ADKの価値は、派手な新機能そのものより、AIエージェントをソフトウェアとして扱う設計にあります。モノリスを分け、出力を縛り、知識を更新し、実行を監視する。この4点を押さえると、エージェントは「動くデモ」から「使える仕組み」に変わります。