Agent Development Kit は、たぶんいい

Author:

2025-04-10

はじめに

本ブログでは、2025-04-09 に Google Cloud NEXT 2025 で発表された Agent Development Kit (ADK) について、 2025-04-10 までにドキュメントを読んだ所感をまとめます。ひとことで言うと、「これは良い気がする」と感じています。

私はこれまでに社内の AI エージェントワークフローを組むのに LangChain を用いてきました。 AI Hackathon with Google Cloud の実装も LangChain を用いてマルチエージェントワークフローで実現しました。 LangChain の利用感については Findy Tools にも書いてあるので、こちらを参照するとなんとなくイメージがつくと思います。
本記事は AI エージェントを組む勘所がなんとなくわかっている人間が ADK のドキュメントを読んで受けた印象として読んでください。

注意書き: ここからの文章は Cloud Next にまだ参加中で ADK を一切触っていない状態で書いています。なんとなく良い気がしていますが、利用後に手のひらが反る可能性があります。

Agent Development Kit (ADK) とは

Agent Development Kit (ADK) は、Google が 2025-04-09 に Google Cloud NEXT 2025 のキーノートで発表した、新しいオープンソースの Python フレームワークです(参考: Vertex AI、マルチエージェントシステムの構築と管理の新機能を提供)。このフレームワークは、特にマルチエージェントシステムと呼ばれる、複数の AI エージェントが連携してより大きな目標を達成するような、複雑な AI アプリケーションの開発を簡略化することを目的としています。
Google の Agentspace や Google Customer Engagement Suite (CES) といった製品で使われているフレームワークがベースになっており、 Google の社内でも既に利用しているという話をセッションでしていました。

ADK は、「コードファースト」のアプローチを採用しています。 Python コードでエージェントの振る舞いやツール、オーケストレーションロジックを直接定義することで、デバッグや、テストのしやすさを向上します。特に、マルチエージェントアーキテクチャを前提に設計されており、複数のエージェントを階層的に組み合わせることで、モジュール性が高く、スケーラブルなアプリケーションを構築できます。

ADK の主な構成要素は以下の通りです。

エージェント (Agent)
- 特定の目標を達成するために自律的に動作する実行単位
  - LlmAgent は次のタスクの決定に LLM を活用する
  - WorkflowAgent は定義済みの順序で他のエージェントの実行フローを制御する。逐次、並列、ループの事前定義のクラスがある
ツール (Tool)
- エージェントが外部の世界と対話したり、特定のタスクを実行したりするための機能
  - API 呼び出し
  - データベース検索
  - Python 関数による計算
  - MCP (Model Context Protocol) の利用
オーケストレータ (Orchestrator)
- エージェント、ツール、コールバックを管理し、ユーザー入力に対する応答の実行フローを調整する実行環境
メモリ (Memory)
- エージェントが過去の会話や状態を保持し、次のアクションを決定するために利用する情報
  - 短期的な会話のコンテキスト (Session State) 管理
  - データストレージを連携した、複数のセッションをまたいで情報を保持することも可能な長期的な記憶領域

ADK が解決しようとしているのは、従来の AI エージェント構築における複雑さです。特に複数のエージェントが絡むシステムでは、その連携や管理が難しくなりがちでした。

Belong における LangChain の利用

これまで Belong では、AI エージェントを用いたワークフローの開発に LangChain を活用してきました。 LangChain は、大規模言語モデル (LLM) を活用したアプリケーション開発のためのフレームワークであり、特に LCEL (LangChain Expression Language) という仕組みが特徴的です。

LCEL は、Runnable というインターフェースを基本単位として、様々なコンポーネント (LLM、プロンプト、パーサー、ツール、他のチェーンなど) をパイプラインのように繋ぎ合わせることで、複雑な処理フローを宣言的に定義できます。これにより、例えば「ユーザーの質問を受け取り、関連情報をデータベースで検索し、その情報をもとに LLM が回答を生成し、整形して返す」といった一連の流れを構築します。

LangChain は豊富なサードパーティツールとのインテグレーションや、活発なコミュニティがあるなどの利点があります。一方で、LangChain を利用する上での課題もあり、LCEL を用いた Runnable によるワークフロー定義は、抽象度が高く、独自の概念を理解するための学習コストが高いと感じることがあります。
特に、複雑な分岐やループを含むワークフローを LCEL で表現しようとすると、コードが読みにくくなったり、デバッグが困難になったりするケースがあり、他の人の定義した chain を理解し、レビューするのが難しいと感じることがありました。状態管理やエージェント間の連携をきめ細かく制御しようとすると、LangChain の提供する抽象化レイヤーの中で工夫が必要になります。

ADK を推せるポイント

ADK のドキュメントを読み進める中で、次の点で良いのではないかと感じました。

タスクのステップごとの扱いやすさ

ADK はエージェントを Python クラスとして定義し、それらを組み合わせてシステムを構築します。これは、複雑なタスクをより小さな、管理可能なステップ（エージェント）に分解し、それぞれの責務を明確にする上で有効だと感じました。
LLM とのインタラクション部分も独立したクラス (例: LlmAgent) として定義できるため、コードの見通しが良くなり、このフレームワークの経験がなくても、ソフトウェアエンジニアであれば直感的に理解しやすい形になっていると思います。

実行ワークフローツリーの定義による柔軟性

エージェント間の親子関係や依存関係によって実行ワークフローのツリー構造を定義するアプローチは、いわゆるワークフロータイプと呼ばれる静的なフロー制御 (WorkflowAgent) とエージェントタイプと呼ばれる LLM による動的な処理 (LlmAgent) を組み合わせることで、高い柔軟性を実現しているように見えます。 LangChain の Runnable Chain のような単一のパイプライン構造よりも、複雑な条件分岐や並列処理、タスクの委譲といったマルチエージェント特有のパターンを自然に表現できる可能性があります。

Google Cloud との統合

ADK は、Gemini モデルや Vertex AI Search and Conversation、Vertex AI Agent Engine といった Google Cloud のサービスとシームレスに連携できるように最適化されています。特に、Vertex AI Agent Engine は、ADK で構築したエージェントを本番環境にデプロイするためのフルマネージドランタイムであり、スケーリングやセキュリティ、モニタリングなどを容易にします。

ここで、LangChain と ADK の並列処理の定義を比較してみます。

LangChain において並列実行をする chain の例

chain = RunnableParallel(
  {"query": RunnablePassthrough(),
   "data": RunnableParallel(
     {"input": RunnablePassthrough(), "docs": doc_retriever}
    )
  // do something...
  | ({"input": itemgetter("input"), "context": itemgetter("context")}
      | prompt
      | model
      | SimpleJsonOutputParser()
  )
)

ADK で並列処理をする例 (参考)

# --- Create the ParallelAgent ---
# This agent orchestrates the concurrent execution of the researchers.
parallel_research_agent = ParallelAgent(
    name="ParallelWebResearchAgent",
    sub_agents=[researcher_agent_1, researcher_agent_2, researcher_agent_3]
)

LangChain の方は実際にはモジュール化しており、即興で共有可能にしたので多少おかしな点はご容赦して欲しいですが、見ただけでもなんとなく見通しが悪そうな感じがすると思います。モジュール化したら見た目は綺麗にできますが、処理全体を追うこと自体は結構苦労します。
ADK の方は、ParallelAgent というクラスを用いて、事前に定義した Agent クラスのオブジェクトを登録することで並列処理を行うエージェントを定義できます。なんとなく眺めただけでも ADK の方が処理の全体感がわかりやすくなりそうではないでしょうか。

以上より、ADK は特に複雑で階層的な構造を持つマルチエージェントシステムを、保守性高く、かつ Google Cloud のエコシステムを最大限に活用しながら構築したい場合に、有力な選択肢になるのではないかと期待しています。

まとめ

今回は、Google Cloud NEXT 2025 で発表された Agent Development Kit (ADK) について、ドキュメントを読んだ範囲での第一印象をまとめました。

ADK は、コードファーストなアプローチとクラスベースのエージェント定義により、特にマルチエージェントシステムの構築において、モジュール性、再利用性、保守性を向上させる設計になっており、LangChain を利用する時に感じていた難しさを解決する可能性を秘めていると感じています。タスクの各ステップを独立したエージェントクラスとして定義し、それらの依存関係によってワークフローツリーを構築する考え方は、開発者にとって直感的で扱いやすいものです。

Belong では、これまで LangChain を用いて AI エージェント開発を進めてきましたが、ADK の登場により、より複雑な社内ワークフローを自動化するエージェントや、より高度な連携を行うマルチエージェントシステムの開発において、新たな選択肢が得られたと考えています。特に、Google Cloud との親和性が高く、LangGraph などの既存ツールとも連携が可能であるため、導入のハードルを下げ、既存資産を活用しつつ新しいフレームワークの利点を享受できる可能性を示唆しています。

もちろん、これはあくまでドキュメントを読んだ上での「良い気がする」という所感であり、実際の使用感はこれから検証していく必要があります。注意書きにもある通り、実際に触ってみた結果、評価が変わり、LangChain/LangGraph がやっぱり良かったと言っている可能性は十分にあります。

これらの検証結果や得られた知見については、今後の Belong 技術ブログなどを通じて、改めて情報発信していきたいと考えています。 ADK が Google Cloud における AI エージェント開発の新たなスタンダードとなるのか、今後の動向に注目していきます。

最後に、Belong は生成 AI を活用した業務効率化を実現するメンバーを募集しています。本記事で Belong に興味を持っていただけたらぜひエンジニアリングチーム紹介ページを確認していただき、カジュアル面談等お声がけいただけたら嬉しく思います。