Google Agent Development Kit (ADK)とは: AIエージェント開発フレームワークの概要

Google Agent Development Kit (ADK)とは: AIエージェント開発フレームワークの概要

Google Agent Development Kit（ADK）は、対話型AIエージェントを効率的に開発・展開するためのオープンソースのフレームワークです。開発者はPythonベースのコードファーストアプローチでエージェントの思考ロジックやツール連携を定義でき、複雑なマルチエージェントシステムも比較的簡単に構築できます。ADKはGoogle Cloudが提供するVertex AIエコシステムと統合されており、最新の大規模言語モデル（例えばGeminiモデル）や各種クラウドサービスとシームレスに連携可能です。

ADKの設計思想には、エージェント開発を通常のソフトウェア開発に近い体験にする狙いがあります。つまり、エージェントの動作をプログラムコードで明示的に制御・テスト・バージョン管理できるようにすることで、ブラックボックスになりがちなAIの振る舞いに対して開発者が高い透明性とコントロール性を持てるようにしています。また、ADKはモデルや実行環境に依存しないモジュール構造を採用しており、AnthropicやMetaといった他社のLLMモデルやオンプレミス環境にも適応できる柔軟性を備えています。

ADKの目的と特徴: AIエージェント開発を容易にする設計思想と基本機能の解説

ADKの主目的は、AIエージェントの開発プロセスを簡素化し、開発者が高度なエージェント機能を迅速に実装できるようにすることです。その特徴としてまず挙げられるのが、エージェントの思考ルーチンやツール使用フローをコード上で定義できる点です。例えば、LLMへのプロンプトやツールの使い方、応答の制御方法などをPythonコードとして記述できるため、対話AIの挙動を細かくデザインできます。また、イベントログやコールバックといった仕組みによりエージェント内部の動きを追跡・デバッグできるのも特徴です。こうした設計思想により、AIエージェント開発における試行錯誤をソフトウェア開発と同じ感覚で行えるようになっています。

ADKが提供する主要機能: ツール連携やストリーミング対話など豊富な機能セット

ADKはエージェント開発に必要な多彩な機能をオールインワンで提供します。その一つが豊富なツール連携です。ウェブ検索やデータベース問合せ、計算ツールなど事前に構築された各種ツールプラグインを簡単に組み込め、エージェントが外部システムとやり取りできるようになります。また双方向ストリーミング対話も特徴的な機能です。音声・動画ストリーミングによる対話機能が組み込まれており、テキストチャットに留まらないリッチなインタラクションを実現できます。この他にもエージェント評価ツール（出力の質を評価する指標やログ分析）やAgent2Agentプロトコル（複数エージェント間の通信規約）への対応など、エージェントを実運用するための機能セットが揃っています。

GeminiモデルなどGoogle AIエコシステムとの連携: Vertex AI統合による高度なAI活用

ADKはGoogleのAIサービス群と緊密に統合されており、その中心にあるのがVertex AIとの連携です。ADK上で開発したエージェントは、Google CloudのVertex AI Agent Engineにデプロイすることでエンタープライズ規模で運用できます。特に、ADKはGoogleの最新LLMであるGeminiシリーズとの相性が良く、Gemini 2.5など高度な推論能力を持つモデルをエージェントの頭脳として活用可能です。また、MCP（Model Context Protocol）への対応によって企業内のデータや検索エンジン（Google検索やVertex AI Searchなど）をエージェントに組み込むことも容易です。これにより、社内データに基づいた回答やGoogleマップのデータを用いた推論など、実用性の高い現実世界志向のAIエージェントを構築できます。

オープンソースと他モデル対応: マルチモデル・マルチプラットフォームに対応した柔軟性

ADKはオープンソースで開発が進められており、コミュニティからの貢献や拡張も活発に行われています。オープンソースである利点は、内部の挙動を把握しやすく自社要件に合わせたカスタマイズが可能な点にあります。また、ADKはGoogle製のモデルだけでなく他社製LLMにも対応しています。例えば、OpenAIのGPTシリーズやAnthropicのClaude、MetaのLLaMAなど、合計200以上にも及ぶモデルをプラグイン経由で利用できます[1][2]。さらに、クラウド環境だけでなくローカル環境やコンテナ（Cloud RunやKubernetesなど）へのデプロイも柔軟に行えるため、オンプレミスからクラウドまでマルチプラットフォームで一貫したエージェント開発・運用が可能です。

ADKがもたらす開発効率向上: コードファーストアプローチで迅速かつ制御可能な開発体験

従来、エージェントの作成には試行錯誤が多く伴い、プロンプトエンジニアリングや設定調整に時間がかかることもありました。ADKはコードファーストのアプローチにより、そのような作業を効率化します。開発者はGit等でコード管理をしながらエージェントを開発できるため、バージョン管理やレビューもしやすくなります。加えて、ADKにはサンプル集であるAgent Gardenが用意されており、すぐに使えるエージェントの雛形やツール集成例を参考にしながら開発を進められます[3][4]。これらにより開発の初期ハードルを下げ、かつ開発サイクルを短縮できるため、エンジニアは本質的なエージェントのロジックやユーザ体験の向上に注力できるようになります。

Agent Development Kit (ADK) 1.16.0リリース概要と追加された新機能一覧

2025年10月、ADKの最新バージョンであるADK 1.16.0がリリースされました[5]。ADKは約2週間に一度のペースで継続的にアップデートが行われており[6]、今回のリリースもその一環です。1.16.0では飛躍的な性能向上こそありませんが、開発者目線で興味深い機能追加と改善がいくつかなされています。以下に、このバージョンの背景と新機能の概要をまとめます。

ADK 1.16.0リリースの背景: 約2週間ごとの更新サイクルと今回のアップデートの位置付け

ADKはリリースサイクルが比較的短く、頻繁に機能追加・改善が行われています[6]。1.16.0も10月初旬にリリースされましたが、これは前バージョン1.15.xから数週間程度でのアップデートとなります。短いサイクルの中で、大規模な変更よりも着実な機能拡充が図られているのが特徴です。今回のリリースでは、直前のバージョンで検討されていたプレフィックスキャッシュやセマンティックキャッシュといった大掛かりな性能最適化機能の導入は見送られました[7]。その代わりに、開発者の利便性やエージェント実行の柔軟性、運用のモニタリング性に関するアップデートが中心となっています。

大きな性能改善は無し: プレフィックスキャッシュ導入見送りと今回フォーカスされた機能

1.16.0では、モデル推論自体の速度や大量トラフィック処理などの性能面での大幅な改善は含まれていません。前述の通り、過去バージョンで検討されていたコンテキストキャッシュ系の機能強化は今回見送りとなりました。そのため、LLMのコアな推論性能自体は1.15.xと大きく変わらないと考えられます。しかし、本リリースでは性能以外の重要な点、すなわちエージェントの文脈管理や対話フロー制御、可観測性にフォーカスした機能追加が行われています。これらは直接のスループット向上ではないものの、長時間対話や複雑なタスクを扱う際の安定性・開発効率に寄与する「縁の下の力持ち」的な改善と言えるでしょう。

LLMコンテキスト圧縮や停止・再開など注目の新機能追加ポイント

1.16.0で特に注目すべきなのは、エージェントの対話履歴管理と実行制御に関する新機能です。具体的には、「LLMコンテキスト圧縮の実装」と「呼び出しの停止・再開サポート」という2つの大きな新機能が追加されました[8][9]。LLMコンテキスト圧縮は、長い対話履歴を効率良く圧縮してモデルに渡す文脈サイズを抑える仕組みです。一方、呼び出しの停止・再開サポートは、エージェントの実行を一時停止し後から再開できるようにするものです。これらはいずれも、エージェントがより長時間・複雑なタスクを扱う際に出力の質や対話の柔軟性を維持するための機能強化と言えます。この他にも、GeminiモデルのAPI経由サポートやBigQueryツールの拡充など、細かな新機能が含まれていますが、詳細は後述する主要項目に譲ります。

Observability強化: Cloud Trace出力改善など運用・モニタリング面での更新

もう一つ見逃せないポイントが可観測性（Observability）の強化です。1.16.0では、エージェントの動作を監視・分析するためのログやトレース機能にも改良が加えられました。その代表例がCloud Trace出力の改善で、従来はGoogle Cloud Traceに送信されるトレースデータのサイズ制限により一部情報が欠落する課題がありました[10]。今回、Cloud Traceへの出力がOpenTelemetry標準のエンドポイント（OTLP）に切り替わったことで、この制限が緩和されています[11][12]。これにより、大規模モデルの大量出力でもトレース情報を漏らさず送信でき、エージェントの挙動をより詳細に追えるようになりました。運用担当者にとって、デバッグや性能チューニングがしやすくなる嬉しい改善です。

その他のアップデート: BigQueryツール追加や評価指標拡充など細かな改善点

上記以外にも、1.16.0には多くの細かな改善が含まれています。例えば、BigQuery関連ではSQL実行ツールにドライラン機能が追加されたほか、新たにクエリ結果の寄与度を分析するツールが追加されています[13]。また、OAuth2認証におけるクライアント資格情報フローのサポートや、ツールエラー発生時に自動でパラメータを変えて再試行するReflectRetryToolPluginの追加も行われました[14]。評価指標の面では、エージェントの幻覚（誤情報）発生を評価するHallucinationsV1メトリクスや、ルーブリックに基づきツール使用を評価する指標が新設されています[15]。これらの改善は一見地味ですが、エージェントの信頼性向上や外部サービスとの統合強化につながる重要なアップデートです。

LLMコンテキスト圧縮の実装: 長大な履歴を要約・圧縮してコンテキスト効率化と高品質な応答の維持を実現

AIエージェントがユーザーと長時間対話を続けると、会話の履歴（コンテキスト）がどんどん蓄積されていきます。通常、LLMに与えるプロンプトにはこの履歴全体を含めますが、履歴が長くなるほどプロンプトも大きく膨らみ、モデル応答の速度低下や不安定化を招く恐れがあります。ADK 1.16.0では、この問題に対処するため「LLMコンテキスト圧縮」機能が実装されました[16]。これは対話履歴を単に削除するのではなく、重要な情報を残しつつ要約・圧縮することで、文脈のサイズを削減する仕組みです。コンテキスト圧縮により、エージェントは長い対話でも過去の情報を保持しながら、モデルに渡す入力サイズを抑えられるようになります。

長大なコンテキストの問題: 会話履歴の肥大化によるモデル応答性能低下への課題

従来、ユーザーとエージェントの会話が長引くと、それまでのやり取り全てをLLMに渡す際にプロンプトが極端に長文化する問題がありました。LLMにはトークン長の上限があるため、履歴が長いと一部を切り捨てざるを得なかったり、無理に含めると今度は処理に時間がかかったり応答品質が低下したりします。特に過去の重要な発言がコンテキストから外れてしまうと、エージェントが突然筋違いな返答をする（いわゆる文脈の逸脱）リスクも高まります。こうした「長大すぎるコンテキスト」の課題は、多くの対話AIで共通して認識されている問題でした。

この問題に対処するため、以前のバージョンADK 1.15.0ではContextFilterPluginという機能が導入され、一定以上古い履歴を機械的に除去する方法が提供されました[17]。しかし、単に古い履歴を削るだけでは重要な情報まで失われる可能性があります。特に、長い対話の中で一度出た指示や前提条件が消えてしまうと、エージェントの応答が一貫しなくなる恐れがあります。

EventsCompactionConfigの導入: 圧縮実行タイミングや範囲を制御する新設定

ADK 1.16.0では、EventsCompactionConfigという新たな設定項目が追加されました[18]。これはADKのエージェント実行管理クラスであるAppに対して設定できるもので、対話履歴の圧縮（コンパクション）に関する動作を細かく指定します。たとえば、compaction_intervalというパラメータで「何回ユーザーからの呼び出し（入力）があるごとに圧縮を実行するか」といった圧縮トリガー間隔を決められます[19][12]。また、overlap_sizeというパラメータでは、連続する圧縮の間で履歴の一部を重複保持する件数（オーバーラップ）を指定できます[20]。これにより、圧縮前後で完全に履歴を断ち切るのではなく、一部重複させることで文脈の連続性を保つことが可能です。これらの設定を調整することで、開発者はどのタイミングでどの程度履歴を圧縮するかを状況に応じて制御できます。

EventsSummarizerによる履歴要約: 古い対話内容を要約し情報を保持する仕組み

実際の圧縮処理はEventsSummarizerと呼ばれる要約機能によって行われます[21]。ADK内部では、設定されたコンパクション間隔に達したタイミングで、過去の対話イベントの一部がこのEventsSummarizerによって要約されます。要約された履歴は元の詳しい内容より短いテキストに圧縮されますが、対話の重要なポイントは失われません。例えば、5ラウンド分の長いやり取りがあった場合、それらを2ラウンド分程度の短い要約に凝縮するといったイメージです。要約にはエージェントが利用しているLLM自体を用いて要約文を生成する仕組みになっており、単純なキーワード抽出ではなく文脈を考慮した賢い要約が行われます。これにより、エージェントは過去のディスカッション内容を圧縮形式で保持しつつ、トークン数を大幅に節約できます。

なお、1.16.0リリース直前で圧縮処理を担うクラス名が変更されるという出来事もありました。以前はEventCompactorという名前でしたが、正式リリース時にはEventsSummarizerという名称に変更されています[22]。ドキュメントやサンプルコードを見る際には、この変更を踏まえて参照する必要があります。

ContextFilterPluginとの違い: 従来の履歴フィルタ方式との比較と圧縮アプローチの利点

ADK 1.15.0で導入されたContextFilterPluginは、対話履歴が長くなりすぎる前に古い発話を一定数カットオフする仕組みでした[17]。これは実装がシンプルで高速に動作しますが、前述のように重要な情報まで削除されてしまう可能性がありました。一方、1.16.0のコンテキスト圧縮は「削除」ではなく「要約」によるアプローチを取ります。具体的には、ContextFilterPluginが単純に古いイベントを捨てていたのに対し、EventsCompactionConfig/EventsSummarizerでは古いイベントを短い要約イベントに置き換えます。これによって、会話の大筋や決定事項など重要な内容は保持したまま、無駄な詳細だけを省くことができます。結果として、エージェントの応答は過去のコンテキストを踏まえた一貫性を保ちつつ、モデルへの入力サイズだけが削減されるという理想的な効果が得られます。

要約による圧縮は処理自体に若干のコストがかかりますが、ADKでは開発者がそれを許容するかどうかを設定で選択できる柔軟性があります。圧縮頻度を低くすればコスト増を抑えつつより多くの履歴を保持できますし、頻度を上げれば応答性能を優先できます。このように、ContextFilterPluginにはなかった細かな調整が可能になった点も、大きな利点と言えます。

開発者へのメリット: 応答品質を維持しつつトークン削減でパフォーマンス向上を実現

LLMコンテキスト圧縮の実装により、開発者とエンドユーザー双方にメリットが生まれます。開発者にとっては、エージェントが長時間の対話を行っても過去の重要情報を失いにくくなるため、ユーザー体験の一貫性が向上します。ユーザー側から見ると、セッションが長引いても「以前伝えたはずの前提をエージェントが忘れてしまう」といった不満が減るでしょう。また、トークン数削減によりモデル応答のレイテンシー（応答時間）が短縮される可能性もあります。プロンプトが短いほどモデルの処理時間も短くなる傾向があるため、圧縮のおかげで結果的に対話のテンポが良くなることが期待できます。

さらに、コンテキスト圧縮はクラウドリソースの節約にもつながります。長大なプロンプトを送信し続けるとAPIコールごとの消費が大きくなりますが、圧縮によってその分コスト削減効果も見込めます。総じて、LLMコンテキスト圧縮機能はエージェントの応答品質とパフォーマンス、そしてリソース効率をバランス良く最適化するための有用なアップデートといえるでしょう。

エージェント呼び出しの停止・再開サポート: 対話フローを一時停止し外部入力を挟める柔軟な中断・再開機能

ADK 1.16.0では、エージェント実行を途中で止めたり再開したりできるResumabilityConfigという仕組みが導入されました[23]。この機能により、エージェントが長いタスクを実行している途中で一旦処理を中断し、後から続きを再開する、といった柔軟なフロー制御が可能になります。従来のエージェント実行は開始したら終了するまで走り切るのが基本でしたが、この停止・再開サポートにより、人間の介入や他のプロセスの完了を待ってから再開するといった高度な制御が実現されます。

ResumabilityConfigの追加: App設定に再開可能フラグを設けエージェント実行を制御

ADKにおけるエージェント実行アプリケーションを管理するAppクラスに、新たにResumabilityConfigという設定項目が追加されました[23]。ResumabilityConfigにはis_resumableというフラグが含まれており、これをTrueに設定することで当該アプリのエージェント呼び出しが再開可能であることを示します。具体的な使用法としては、Appを初期化する際に以下のように設定します。

app = App( name="resumable_app", root_agent=root_agent, resumability_config=ResumabilityConfig(is_resumable=True) ) 

上記のように設定されたAppでは、エージェント実行中に外部から再開操作を受け付けるためのフックが有効になります。このフラグをFalse（デフォルト）にしておけば従来通り再開不可、Trueにすると再開可能という単純なスイッチですが、エージェントの実行モデルに大きな柔軟性をもたらすオプションです。

再開機能の狙い: 対話途中でのHuman-in-the-Loop実現による柔軟なユーザー介入

エージェント実行の一時停止・再開機能の背景には、Human-in-the-Loop（HITL）的なユースケースが考えられます[24]。例えばエージェントがユーザーの問い合わせに回答する過程で、一度ユーザーの確認を取ってから続きを進めたいケースがあるでしょう。従来はエージェントが回答を出し終えるまで流れを制御できませんでしたが、再開機能を使えば特定のタイミングで処理を中断し、ユーザーからの追加入力や承認を待って再開するといった対話フローが可能になります。

具体的なシナリオとしては、チャットボットが一連の質問に答える中で「この回答で満足ですか？ 続けますか？」とユーザーに尋ね、ユーザーが「はい」と応えたら続きを実行する、といったインタラクティブなやり取りが挙げられます。また、外部のデータ取得に時間がかかる処理をエージェントが行う際、一旦停止してバックグラウンドジョブを待ち、完了したら再開する、といった非同期的なフローにも応用できるでしょう。要するに、再開機能はエージェントの実行シーケンスに柔軟な待機ポイントを差し込めるようにすることで、人間や他システムとのインタラクションを容易にする狙いがあります。

サンプルコードで見る使い方: ResumabilityConfig有効時におけるエージェント挙動の例

ADKの公式リポジトリには、ResumabilityConfigを使ったサンプルコードも用意されています[25]。その一例として、ユーザーの入力を待つようなHuman タスク確認のサンプルがあります。このサンプルでは、エージェントがあるツールを実行する前に、人間に対して「このツールを実行してもよいか？」という確認を求め、ユーザーが許可すると実行を続行するといった動作を示しています。再開可能フラグが有効な場合、エージェントは内部的に処理を一時中断し、外部からの「続行してよし」というシグナル（ユーザーの許可入力）を待機します。そして許可が与えられると中断箇所から処理を再開し、ツール実行に移るわけです。

この挙動は、一種のフロー制御プラグポイントを提供するものと言えます。従来であればエージェント内でif文等を書いてユーザー入力を待つロジックを実現しなければなりませんでしたが、ResumabilityConfigによりADKランタイムがその待機・再開を管理してくれるため、開発者はシンプルにシナリオを書くだけでHITLを組み込めます。

注意点と現時点の制限: 再開機能を利用する際の前提条件と留意すべき点

便利な再開機能ですが、現時点（v1.16.0）では開発者が注意すべき点もあります。まず、再開ポイントは開発者が明示的に設定する必要があることです。どこでも自由に中断再開できるわけではなく、設計上「ここで一旦停止する」という箇所を決め、その地点でエージェントが待機状態に入るよう実装します。また、再開にあたってはエージェントの状態を適切に保持・復元できなければいけません。一度停止した後に再開する際、前の処理内容やコンテキストをエージェントが忘れていては意味がないため、内部状態のシリアライズやセッション管理が鍵となります。

さらに、この機能はまだ登場したばかりであり、想定外の使い方には十分なテストが行われていない可能性があります。Zennの記事の著者も「具体的にどのような挙動になるのか完全には把握できていない」と述べています[24]。したがって現時点では、本番環境でいきなり使うというより、PoC（概念実証）的に試しながら動きを確認していくことが推奨されます。ADKコミュニティからのフィードバックや、今後のドキュメント整備を注視しつつ慎重に導入すると良いでしょう。

今後の展望: HILシナリオでの活用可能性と機能拡張の方向性

ResumabilityConfigによる停止・再開サポートは、HITLシナリオや対話型UIでのエージェント活用に道を開く機能です。今後の展望として、この仕組みがさらに強化される可能性があります。例えば、将来的にエージェントが自律的に「次にユーザーからの入力を待つ」ことを判断し、中断ポイントを動的に作るといった高度な応用も考えられます。また、再開時にコンテキストをより的確に復元するための状態管理APIの拡充や、中断したセッションを一覧・管理するためのツールなど、周辺機能の整備も見込まれます。

コミュニティからは、「特定の条件下でエージェントを自動停止させたい」「再開時に別のブランチ処理に飛ばしたい」といった要望も出てくるでしょう。ADKの開発チームはこうしたニーズに応える形で、より柔軟でパワフルなフロー制御機能を進化させていくと予想されます。エージェントが単に質問に答えるだけでなく、対話の文脈に応じて一時停止し、人間との協調を行える未来像は、ADKが目指す「高度なマルチエージェントシステム」の重要な一部となるでしょう。

Cloud Trace出力の改善: OTLP採用でより詳細なトレース取得と大容量データ可視化が可能に

ADK 1.16.0では、エージェントの実行履歴を分析・監視するためのトレース出力機能が改善されました。その中心となる変更が、Google CloudのTraceサービスへの出力方法を従来の方式からOTLP（OpenTelemetry Protocol）方式へ切り替えたことです[26]。これにより、LLMエージェントが生成する大量のテキストデータや複雑なワークフローの詳細も、欠損なくクラウドに記録できるようになりました。以下、この改善の詳細と意義を解説します。

従来のCloud Traceエクスポータの課題: スパンサイズ制限によるトレース情報欠落問題

ADKでは、エージェントの動作を可視化するためにCloud Traceへのデータ送信機能が提供されてきました。開発者がADKアプリをデプロイする際、adk deploy –trace_to_cloudオプションを指定すると、エージェントの各アクションやツール実行がトレース情報としてGoogle Cloud Traceに送信されます[27]。しかし、従来使われていたCloud Trace APIには1スパン当たりのデータサイズ上限が存在し、これが問題となるケースがありました[28]。

具体的には、大量のテキストを扱うLLMエージェントでは、1回の応答に数千文字を生成することがあります。こうした長文の応答内容や、内部で保持する大きなコンテキストをそのままトレースに載せようとすると、Cloud Trace APIの制限に引っかかり、スパン（トレースの1単位）のデータが途中で切り捨てられてしまうのです[28]。結果として、Cloud Trace上でエージェントの動きを確認しようとしても、肝心の入出力内容が欠落して不十分なログになってしまうという課題が指摘されていました。

OTLPエンドポイントへの変更: Cloud Trace APIからOpenTelemetry準拠のエンドポイントへ移行

この課題を解決するため、ADK 1.16.0ではトレースデータの送信先が従来のCloud Trace APIではなく、OpenTelemetryのプロトコルに準拠したエンドポイント（telemetry.googleapis.com）に変更されました[26]。OTLPはクラウドネイティブな監視の標準仕様であり、Google Cloudのモニタリングサービスとも統合されています。ADK内で用いられるCloudTraceSpanExporterというコンポーネントが、このOTLPエンドポイント向けに動作するよう改良された形です。

OTLPエンドポイントでは、従来のAPIよりも大きなサイズのスパンデータ送信が許容されているため、LLMの長大な出力でも丸ごとトレース情報として扱えます。またOpenTelemetry標準に乗ったことで、他のOTLP対応の監視ツールやトレーサとも互換性が生まれました。これにより、ADKから出力されたトレースデータをサードパーティ製の可観測性プラットフォームで分析するといったことも可能になります。要するに、トレース出力基盤をクラウド標準に合わせることで、スケーラビリティと相互運用性が大きく向上したと言えます。

大容量データの送信対応: LLM出力など長大なトレースも完全に記録可能に

OTLPへの移行によって得られる直接的なメリットは、前述の大容量データ送信への対応です。例えば、エージェントが長文の回答を生成した場合でも、トレース上にその全文を保持できる可能性が高まりました。これまではログの途中で「…（省略）」となっていた部分も、OTLPでは最後まで記録されるケースが増えるでしょう。開発者や運用者はエージェントがどのようなアウトプットを生成したのか、細部に至るまでクラウド上で確認できるようになります。

さらに、エージェント内部でのツール呼び出しや分岐ロジックなど、複雑なワークフローの流れも粒度細かくトレースに残せます。複数のエージェントが連携するシナリオでは、各エージェントの入出力を統合的に見渡す必要がありますが、大容量のデータでも一貫したタイムラインに載せられるため、全体像の把握が容易になります。問題発生時の原因究明やボトルネックの特定にも、この詳細なトレース情報が力を発揮するでしょう。

Observabilityの向上: 詳細なトレース分析によるデバッグ・パフォーマンスチューニング改善

トレース情報が充実したことで、ADKを用いたエージェントのObservability（可観測性）は飛躍的に向上します。具体的には、エージェントがどのような推論過程を経て回答を生成したのか、あるいはどのツールをどの順序で使ったのかといった点を、時系列に沿って正確に追跡できるようになります。これらは開発段階ではデバッグに役立ち、意図しない挙動を発見したり、期待通りに動いているかを検証する材料となります。また運用段階では、エージェントの処理時間の内訳や待ち時間などを分析することでパフォーマンスチューニングの手がかりが得られます。

加えて、詳細なトレースはチーム内での知見共有にも有用です。開発者があるエージェントのログを見て「ここでもう少し最適化できそうだ」や「このフローなら別の実装も試せる」といった発見を共有しやすくなります。トレースデータを活用したエージェント開発のベストプラクティスが蓄積されれば、より洗練されたAIエージェントの設計・運用が可能になるでしょう。

将来性と統合効果: OpenTelemetry標準採用によるモニタリングエコシステムとの親和性

今回のCloud Trace出力改善は、単に現在の課題を解決しただけでなく、将来的な拡張性にも寄与しています。OTLPという標準プロトコルを採用したことで、将来Google Cloud以外の環境やツールともトレースデータを共有しやすくなりました。例えば、オンプレミス環境で動くエージェントからクラウド上の集中監視システムにデータを送る場合でも、OTLPに対応していればスムーズに連携できます。

OpenTelemetryは今やクラウドネイティブアプリケーションの監視標準となりつつあります。ADKがそれに準拠したことで、APM（アプリケーション性能管理）製品やログ分析基盤との親和性も高まりました。エージェント以外のシステムログと統合して分析することで、AIエージェントを含むシステム全体の最適化が図りやすくなるでしょう。今回の改善は、ADKをエンタープライズ環境で本格導入する上でも重要なステップであり、今後のモニタリングエコシステムとの深い統合が期待されます。

ADKにおけるエージェントの種類: LLMエージェント、ワークフローエージェント、カスタムエージェント

ADKでは開発者の目的やシナリオに応じて選べるよう、いくつかの異なるタイプのエージェントが用意されています[29]。大きく分けると、自然言語で柔軟に動くLLMエージェント、決められた手順に従うワークフローエージェント、そして開発者が自由に拡張できるカスタムエージェントの3種類があります。それぞれ特徴が異なり、得意とする役割も異なります。ここではADKにおけるエージェントの種類について、その概要と特徴を説明します。

LLMエージェント: 大規模言語モデルを思考エンジンとする柔軟な対話型エージェントの特徴

LLMエージェントは、その名の通り大規模言語モデル（LLM）を中核として動作するエージェントです[30]。ADKではLlmAgentあるいは単にAgentといったクラスがこれに該当し、人間のような柔軟な応答生成や推論を行います。LLMエージェントは自然言語の理解と生成を得意としており、ユーザーの曖昧な質問にも文脈を踏まえた回答を導き出すことができます。また、必要に応じてツールを動的に選択・実行する機能も持ち、例えば「ウェブ検索ツールで情報収集し、その結果を分析して回答する」といった自律的なタスク選択も行えます。

LLMエージェントの特徴は非決定性で柔軟な挙動にあります。同じ質問でも、内部のLLMの状態やランダム性によって微妙に異なる答え方をすることがあり、創造性の高い応答や人間らしい言い回しを生成することが可能です[31]。その反面、出力の内容が予測しづらく、実行フローも内在するLLMの「判断」による部分が大きいため、完全に結果をコントロールしたい場合には不向きな側面もあります。

まとめると、LLMエージェントは自由度と知性を持った頭脳として振る舞うエージェントであり、対話や推論といった柔軟性が求められるタスクに適しています。一方で後述するワークフローエージェントと組み合わせ、LLMエージェントを部分的に利用して応答生成しつつ、全体の流れはワークフローで制御するといった使い方もよく行われます。

ワークフローエージェント: 定型フローでサブエージェントを制御する決定論的エージェントの役割

ワークフローエージェントは、あらかじめ決められたパターン（フロー）で動作するエージェントです[32]。代表的なものにSequentialAgent（シーケンシャルエージェント）やParallelAgent、LoopAgentがあります[33]。これらはそれ自体はLLMのような言語生成能力を持たず、むしろ他のエージェントを内部で呼び出して統制するための「オーケストレーター」の役割を果たします。

例えばSequentialAgentは内部にリスト化された複数のエージェント（またはタスク）を決められた順序で次々に実行します[34]。ParallelAgentは並列に複数エージェントを走らせ、すべての完了を待ち合わせたり結果をマージしたりします。LoopAgentは特定のエージェントを条件が満たされるまで繰り返し実行するようなフローを記述できます。これらワークフローエージェントはいずれも、内部のフローがコード上で明示されているため動作が決定論的で予測可能という利点があります[35]。

ワークフローエージェントは、LLMエージェントのような高度な推論は行えない代わりに、エージェント同士の協調やタスク分割を実現する上で重要な役割を果たします。例えば、大きな問題を複数の下位エージェントに分担させ、SequentialAgentで順番に処理することで一連の複雑なタスクを完了させるといった使い方が可能です。こうしたマルチエージェントシステムでは、ワークフローエージェントがリーダーシップを取り、LLMエージェントたちが実際の作業をこなすという分業体制になることも多いです。

SequentialAgentとParallelAgent: ワークフロー型エージェントの種類と典型的な活用シナリオ

ワークフローエージェントの中でも特に利用頻度が高いのがSequentialAgentとParallelAgentです。SequentialAgentは手順が決まっているプロセス、例えば「データ取得→分析→レポート生成」のような段階的処理に適しています[36]。実行結果が次のステップに引き継がれるシナリオでは、SequentialAgentによる直列実行がわかりやすく、処理の追跡もしやすいです。

一方、ParallelAgentは互いに独立した処理を同時に行いたい場合に有用です。例えば「複数のデータソースから同時に情報収集する」場面ではParallelAgentで並列化することで全体の所要時間を短縮できます。ParallelAgentは内部の各エージェントの完了を待ってから次に進むため、レースコンディションを避けつつ並行性を活用できます。典型的な活用シナリオとしては、WebスクレイピングやAPI複数呼び出しの同時実行などが考えられます。

これらSequentialAgentやParallelAgentは、LLMエージェントと組み合わせて使われることが多いです。例えばParallelAgentが複数のLLMエージェントに同じ質問を投げて回答を集約することで安定した結論を得たり、SequentialAgentがLLMエージェントで生成した結果を別のLLMエージェントに渡して追加加工する、といった高度なフローも実現可能です。ADKでは、こうしたワークフロー型とLLM型の組み合わせにより、個々のエージェントの強みを活かした協調動作が実現しやすくなっています。

カスタムエージェント: BaseAgentを継承して独自ロジックを実装する拡張エージェント

ADKには、LLMエージェントやワークフローエージェントで賄えない特殊なニーズに対応するために、カスタムエージェントを実装する道も用意されています[37]。これはADKの抽象基底クラスであるBaseAgentを開発者自身が継承し、必要なメソッドをオーバーライドして作るエージェントです。カスタムエージェントでは、エージェントの内部処理を完全に自由にプログラミングできます。そのため、標準提供のエージェントタイプにはない振る舞いや、特定の外部システムとの特殊な連携ロジックを組み込むことが可能です。

例えば、「特定の業務ルールに基づいて動くエージェント」を作りたい場合、あえてLLMに頼らずルールベースAIのようなロジックを実装したカスタムエージェントを用意することもできます。また、ワークフローエージェントのカスタム版を作り、標準のSequential/Parallelよりも複雑な制御フロー（例: 条件分岐を多用したもの）を実現することも可能でしょう。カスタムエージェントは開発者の発想次第で無限の拡張性をもたらす機能ですが、その分高度なプログラミング知識とADKの深い理解が要求されます。

ADKではこれら多様なエージェントタイプを組み合わせることで、一つのシステム内にマルチエージェントのアーキテクチャを構築できます[38]。LLMエージェントが知的作業を担い、ワークフローエージェントが手続き管理を行い、必要ならカスタムエージェントが特殊処理を補完する、といった役割分担が可能です。開発者はアプリケーションの要件に応じて適切な種類のエージェントを選択・設計することで、効率的かつ制御性の高いAIシステムを実現できるでしょう。

適材適所の選択指針: 柔軟性が必要な場合と予測可能性重視の場合のエージェント選択

最後に、どのタイプのエージェントを選ぶべきかという指針について触れておきます。もしユーザーとの対話や曖昧な質問への対応など、柔軟な推論能力が求められるならLLMエージェントが第一候補になります。一方、処理手順が明確に決まっており、外乱なく確実に実行したい場合はワークフローエージェントでフローを制御すると安心です。例えば定型業務の自動化など、結果が予測可能であることが重視されるケースではワークフロー型が適しています。

また、既存のエージェントでは対応できない非常に固有な要件がある場合には、カスタムエージェントを検討します。例えば特殊なAPIとの通信プロトコルや、リアルタイム性が求められる処理（ミリ秒単位の制御など）を含む場合は、カスタムで実装する方が早いかもしれません。ただしカスタムエージェントは開発コストも上がるため、まずはLLM＋ワークフローの組み合わせで実現できないか検討し、それでも難しい場合に最終手段として使う、といった判断が望ましいでしょう。

このようにADKはエージェント開発において「どんなタイプで作れば良いか」を選べる柔軟な枠組みを提供しています。プロジェクトの目的に照らし合わせて適材適所のエージェントを採用することで、強力かつ安定したAIソリューションを構築できるはずです。

Sequential Agentの活用: 手順型エージェントで順序制御するワークフロー構築手法と利点

ここではワークフローエージェントの一種であるSequential Agent（シーケンシャルエージェント）に焦点を当て、その活用方法と利点を詳しく見てみましょう。Sequential Agentは複数の処理をあらかじめ決められた順番で実行するエージェントです。その挙動はちょうどレシピ通りに料理を進めるように、一歩一歩着実にタスクをこなしていくイメージです。複雑なタスクをいくつかのステップに分解して順次処理させたい場合、このSequential Agentが非常に有効です。

Sequential Agentの役割: 一連のタスクを所定の順序で実行するワークフロー制御

Sequential Agentの基本的な役割は、内部に持つ複数のエージェントやタスクを所定の順序で一つずつ実行することです[34]。これは例えば、ToDoリストに従って仕事を片付けるようなものです。具体的には、Sequential Agentは初期化時にリストとして渡された子エージェント（あるいは処理関数）を先頭から順番に呼び出します。一つ目の処理が終わったら次へ、という形で最後の処理まで実行し終えればSequential Agentのタスク完了となります。

この順序制御は、ADK内では決定論的シーケンス実行として実装されています。つまり与えられたシーケンスが常に同じ順で実行されるため、流れが予測可能で安定しています。複雑なシナリオではLLMエージェントのような動的判断に任せず、開発者が定めた手順に沿って処理を進めることで、誤りや抜け漏れのないワークフローを実現できるという利点があります。

典型的なユースケース: ステップごとに処理を行う必要があるタスクの具体例

Sequential Agentが威力を発揮する典型例として、複数段階に分かれるタスクが挙げられます。例えば、旅行プラン作成をエージェントに行わせる場合を考えてみましょう。第一にユーザーから旅行の希望を聞き出し（質問応答エージェント）、次に希望に合った観光地を検索し（検索エージェント）、その後見つかった情報をまとめて日程案を作成し（スケジューリングエージェント）、最後にユーザーへ提案するといった流れです。これは「聞く→探す→まとめる→提案する」という4つのステップから成ります。

このようなケースでSequential Agentを使えば、各ステップを担うエージェントを順に呼び出すことで、一連の処理を自動化できます。もしユーザーからの希望聞き取りにLLMエージェント、検索に外部APIツール、スケジューリングにカスタムロジックのエージェント…といったように異なる手法が混在していても、Sequential Agentで順序さえ決めれば滑らかに連携させることができます。その他、データ収集→データ分析→レポート生成のようなETL的処理や、フォーム入力→検証→データベース保存のような業務プロセスなど、順序が決まった一連の流れがあるタスクには軒並み応用可能です。

実装方法: 複数エージェントをリスト化し順次実行するシーケンス定義の手法

ADKでSequential Agentを使う場合の実装は比較的シンプルです。まず、シーケンシャルに実行したいエージェント（もしくはTask）を順番通りにリスト構造で用意します。そして、そのリストを引数にしてSequentialAgentを初期化するだけです。疑似コードで表すと以下のようになります。

from google.adk.agents import SequentialAgent
それぞれのサブエージェント（またはタスク）を定義
agent1 = ... # ステップ1 agent2 = ... # ステップ2 agent3 = ... # ステップ3
リストにまとめてSequentialAgentを作成
workflow_agent = SequentialAgent(agents=[agent1, agent2, agent3])
workflow_agentを実行すると、agent1→agent2→agent3の順で実行

このように、記述自体は非常に明快です。各エージェント間でデータを受け渡したい場合は、戻り値を次のエージェントの入力に渡すような設定も行えます。また、SequentialAgentの内部では各エージェントの実行結果（イベント）がログとして蓄積されるため、後でどの段階で何が行われたかをモニタリングすることも可能です。

利用時のメリット: 処理順序の明確化による管理容易性と不具合切り分けのしやすさ

Sequential Agentを用いる大きなメリットの一つは、処理の流れが明確になることです。開発者にとって、コード上にステップ順がはっきり記述されているため、エージェントの振る舞いを理解しやすくなります。これはチーム開発においても有用で、どの部分で何をしているのかが読み取りやすいワークフローはコードレビューやメンテナンスを容易にします。

また、順序が決まっていることで不具合の切り分けもしやすくなります。例えば、全体の結果がおかしい場合でも、「ステップ2までは期待通りだけどステップ3で問題が発生している」といった具合に原因箇所を特定しやすいです。各ステップが独立していれば個別にテストすることも可能ですし、順次実行ゆえにログの追跡もしやすいためデバッグ効率も上がります。ParallelAgentのように並列だとログが錯綜する可能性がありますが、SequentialAgentではログが時系列順に並ぶので見通しが良いという利点もあります。

さらに、SequentialAgentはワークフロー途中でのエラーハンドリングもシンプルです。例えば、あるステップでエラーが発生した場合、以降のステップを実行せずに停止する、といった処理を一括で管理できます。これにより、途中で問題が起きた場合でも不完全な結果をユーザーに返さないように制御する、といった信頼性の高い実装が容易になります。

ParallelAgentやLoopAgentとの比較: 並列実行・ループ実行との使い分けと併用シナリオ

SequentialAgentに対し、ParallelAgentやLoopAgentは異なる実行パターンを提供します。それぞれ適材適所で使い分けることが重要です。ParallelAgentは前述したように複数処理の同時実行が必要な場合に有用ですが、その結果を待ち合わせたり結合する処理が必要になるため、設計が少し複雑になります。また、同時に実行するエージェント間に依存関係がないことが前提となるため、依存関係があるならSequentialAgentの方が自然です。

LoopAgentは繰り返し実行が必要なケース、例えば「ユーザーが満足する回答を得るまで何度も試行する」といった場合に使います。ただし無限ループに陥らないよう終了条件を慎重に設計する必要があります。SequentialAgentとLoopAgentを組み合わせて、決められたシーケンスを複数回繰り返すような複合フローを構築することもできます。

さらに高度なシナリオでは、SequentialAgentの中にParallelAgentを組み込む、あるいはその逆など、入れ子で併用することも可能です。例えば、ステップ2で2つの処理を並行実行し、両方終わってからステップ3に進む、といったケースではSequentialAgent内部の一部にParallelAgentを配置すれば実現できます。このようにADKのワークフローエージェントは柔軟に組み合わせ可能であり、シーケンシャルとパラレル、ループを適切に使い分けることで、現実の複雑な業務フローにも対応できる強力なエージェントシステムをデザインできます。

出力の安定性と一貫性: エージェント応答のばらつきを抑えるADKの工夫と品質維持のベストプラクティス

AIエージェントの運用において、大きな課題となるのが出力の安定性と一貫性です。対話AIは時として予想外の回答をしたり、同じ質問に対して異なる答えを返したりすることがあります。ここでは、ADKが備える各種機能や開発手法を活用してエージェントの応答品質を安定・一貫させるためのポイントを解説します。LLMの特性による不安定さへの対策から、ワークフロー設計による制御、コンテキスト管理や評価指標の活用、さらにはツール確認フローやHITLといったガードレールまで、総合的なベストプラクティスを見ていきます。

LLM出力の不安定さ: 長い対話で起こりがちな文脈の逸脱や回答品質のばらつき

大規模言語モデルを用いたエージェントは、高度な推論能力を持つ反面、出力内容が揺らぎやすい一面もあります。特に長時間にわたる対話では、前の質問内容を忘れたり、途中で関係のない話題に脱線したりする文脈の逸脱が起こることがあります。また、同じ問いに対してもセッションや文脈によって微妙に異なる回答をするなど、回答品質に一貫性がない場合もあります。

この原因はLLMが確率的なテキスト生成を行うためで、わずかなコンテキストの違いやランダムシードの違いで生成結果が変化するからです。さらに、モデルが自身の出力した誤情報を元に次の応答を構築してしまう誤謬の蓄積（ハルシネーションの連鎖）も、長い対話で品質が劣化する一因です。こうしたLLM出力の不安定さに対し、ADKでは様々な角度から対策が講じられています。

決定性の確保: ワークフローエージェントで処理手順を固定化することの利点

出力の安定性を高める基本原則の一つは、エージェントの挙動に決定性を持たせることです。ADKではワークフローエージェント（SequentialAgent等）を活用することで、エージェントが辿る処理手順をあらかじめ固定することができます[35]。これによって、毎回同じ順序・方法でタスクを実行するため、応答のばらつき要因を減らすことができます。

例えば、ある質問に答える際に「まずWeb検索して、その結果を要約し、最後にユーザー向けに整形する」という流れを決め打ちしておけば、余計な寄り道をせず安定した応答パターンが得られます。LLMエージェント単体に全て任せてしまうと、時には検索を省略したりいきなり推測で答えたりとブレが生じるかもしれません。しかしワークフローでガイドすれば、常に所定のプロセスを踏ませることができるため、結果として出力内容のゆらぎを抑えることができます。

決定論的なフローを組むことは、デバッグやテストの面でも有効です。特定の手順で常に実行されることで、問題の再現性が高まり不具合の原因追及がしやすくなります。安定性確保のためには、まずワークフローエージェントを活用してエージェントの行動パターンを制御することが重要と言えるでしょう。

コンテキスト管理の重要性: 圧縮・要約による履歴維持でエージェント応答の一貫性を向上

エージェントの応答が一貫しない原因として、会話が進むうちに過去の文脈が抜け落ちてしまう問題がありました。これに対して有効なのが前述したLLMコンテキスト圧縮などの文脈管理機能です。ADK 1.16.0で導入されたEventsCompactionConfigとEventsSummarizerによる履歴圧縮は、長い対話履歴を要約して残すことで、過去の重要事項を忘れずに保持し続けます。これにより、会話が長引いてもエージェントが以前の発言を踏まえた一貫した回答を返しやすくなります。

また、コンテキスト管理には適切なプロンプト設計も含まれます。ADKではエージェントに与えるシステムメッセージ（コンテキストの一部）の工夫や、Pluginを使ったプロンプト前処理なども可能です。例えば、過去のやり取りから重要な事実だけを抜き出して要約するコンテキストフィルタや、ユーザーの口調や設定を保持するシステムプロンプトを冒頭に固定する、といったテクニックがあります。こうした方法でコンテキストを管理することにより、エージェントが常に同じ前提に立って応答を生成するよう導くことができます。

要するに、安定した一貫性ある応答を得るためには「エージェントに正しい文脈を持たせ続ける」ことが鍵となります。そのためのADKの機能群（コンテキスト圧縮やプロンプト管理）は積極的に活用すべきでしょう。

出力品質の評価指標: ハルシネーション検知などADK提供の評価機能による品質モニタリング

エージェントの出力品質を維持・向上するには、そもそもどの程度安定しているかを定量的に測定することも重要です。ADKにはエージェントの性能や応答内容を評価する仕組みが組み込まれており、1.16.0では新たにHallucinationsV1という評価メトリクスが追加されました[15]。これはエージェントの回答に虚偽や不正確な情報（ハルシネーション）が含まれていないかをチェックする指標です。例えば、エージェントに事実に基づく回答をさせるテストを行い、誤った内容が出力されなかった割合をスコア化するといった使い方ができます。

この他にも、ツール使用の適切さを測るルーブリックベースの指標や、ユーザー評価（Human評価）を取り込む仕組みもADK評価フレームワークに含まれています。これらを活用することで、エージェントの出力品質をモニタリングし、ばらつきや誤りが一定以上発生していないかを常にチェックできます。もし評価指標が悪化してきた場合には、コンテキスト圧縮の頻度を調整したり、プロンプトを改良したりといったフィードバックループを回すことができます。

重要なのは、評価指標によって「安定していない」「一貫性に欠ける」兆候を見逃さないことです。ADKの評価機能は、その兆候を早期に発見して対策を講じる助けとなります。エージェント開発においては、単に動けば良いではなく、出力品質を維持するPDCAサイクルを回すことが重要であり、ADKはそのためのツールセットも提供しているのです。

ガードレールとHITL: ツール実行確認フローや人間の介入で誤答や暴走を防ぐ手法

最後に、エージェントの出力を制御するガードレール的アプローチについて触れます。ADKはエージェントが不適切な動作をしないよう、あらかじめ安全装置を組み込む仕組みも用意しています。その一つがツール確認フロー（Tool Confirmation Flow）です。これはエージェントが特定のツールを実行しようとした際に、一旦人間もしくは定義済みのルールで許可を求めるプロセスです[39]。例えば、データ削除のような危険な操作をエージェントが行おうとした場合に「本当に実行しますか？」と確認させ、許可が得られなければ中止するといった挙動をさせられます。これによって、エージェントの暴走を未然に防止できます。

また、前述したHuman-in-the-Loopもガードレールの一種と言えます。エージェント任せにせず、要所要所で人間が介入できる仕組みを作ることで、出力内容の最終チェックや調整を行えます。例えば、重要な回答をユーザーに提示する前にオペレーターが一度確認・編集できるようにする、といったワークフローも考えられます。

さらに、ADKではエージェントのプロンプトに安全に関する指示（例えば「差別的な発言をしない」等）を組み込んだり、出力内容を検閲するフィルタを適用したりすることも可能です[40][41]。これらは直接「安定性」とは異なる文脈ですが、一貫して安全で信頼できる応答を得るためには不可欠な要素です。安定性と一貫性は品質の一部であり、品質には安全性・信頼性も含まれるため、包括的なガードレール戦略が結果的に安定した出力につながります。

まとめると、ADKを用いたエージェント開発では、ワークフロー設計やコンテキスト圧縮によって出力の揺らぎを抑え、評価指標で品質を監視し、必要に応じて人間の目やルールベースの確認を挟むことが肝要です。これら複数の観点からアプローチすることで、エージェントの応答は安定性・一貫性が高まり、ユーザーにとって信頼できるものとなるでしょう。