🤖

ADK 1.14.0 で追加された Agent、Runnerに続く新たな概念 App

に公開

こんにちは、サントリーこと大橋です。

本日(2025/09/11)、Agent Development Kit(以降ADK)のバージョン 1.14.0がリリースされました。

https://github.com/google/adk-python/releases/tag/v1.14.0

READMEにも記載がありますが、今回のリリースから、リリースサイクルが毎週からほぼ隔週に変更されました。
今回のリリースで追加された主な機能は以下です。

[Core] Upgrade ADK runner to use App in addition to root_agent (4df79dd)
[Tools] Add a tool confirmation flow that can guard tool execution with explicit confirmation and custom input (a17bcbb)
[Tools] Add GkeCodeExecutor for sandboxed code execution on GKE (72ff9c6)
[Tools] Add BigQuery forecast tool (0935a40)
[A2A] Allow users to pass their own agent card to to_a2a method (a1679da)

  • Appの概念の導入
  • ツールの実行前に確認と入力のカスタマイズを行えるフローの追加(別の記事で紹介します)
  • GKE上でのサンドボックス化されたコード実行のためのGkeCodeExecutorの追加
  • BigQuery forecast toolの追加
  • A2A(Agent-to-Agent)連携の強化(カスタムAgent Cardやカスタムコンバーターのサポート)

他にも多くの機能追加、バグフィックス、改善が行われています。
今回はこの中で、ADKの構造に大きな変化をもたらす可能性のある「App」という新しい概念について深掘りしていきたいと思います。

対象読者

  • ADKユーザー
  • ADKをこれから使いたいPythonユーザー
  • ADKをこれから使いたいAI エージェント開発者

※本文中ではADKのAgentを「Agent」とアルファベット表記、ADKだけではなく一般的なAIエージェントを「AIエージェント」とカタカナ表記しています。

課題: AgentとPluginの分離とデプロイの複雑さ

これまでADKでAgentを開発する際、Agentのコアロジックと、それに付随する横断的な機能(例えばロギングや認証)は別々に管理する必要がありました。

Agentのコアロジックは Agent クラス(LlmAgentなど)で定義します。一方、複数のAgentに共通する横断的な機能は Plugin として実装し、Runner の初期化時に渡すのが一般的でした。

私の過去の記事でも紹介しましたが、PluginはRunnerレベルで設定するため、すべてのAgentに共通の処理を差し込める便利な機能です。

https://zenn.dev/suntory/articles/9f33442e37ac5d

以前のPlugin設定方法
# Runnerの初期化時にPluginを渡す
runner = InMemoryRunner(
    app_name="test",
    agent=root_agent,
    plugins=[
        MyLoggingPlugin(),
        MyAuthPlugin(),
    ]
)

しかし、このアプローチにはいくつかの課題がありました。

  1. AgentとPluginの疎結合性: Agentの定義と、そのAgentが依存するPluginの定義がコード上で離れてしまい、アプリケーション全体の見通しが悪くなりがちでした。Agentを再利用しようとすると、どのPluginとセットで使うべきなのかを別途管理する必要がありました。
  2. デプロイの複雑化: adk web のようなRunnerが定義済みの環境では、Pluginを動的に設定する標準的な方法が提供されていませんでした。そのため、Pluginを利用したい場合は自前でRunnerを実装する必要があり、手軽に試したりデプロイしたりすることが困難でした。

要するに、Agentとそれに必要なPlugin群を一つの「アプリケーション」としてカプセル化し、簡単に配布・実行する仕組みが不足していたのです。

新概念「App」の登場

この課題を解決するために、ADK 1.14.0で導入されたのが App という新しい概念です。
App は、Agent とそのAgentが必要とする Plugin 群を一つにまとめるためのコンテナクラスです。

コミットログには以下のように記されています。

feat: Upgrade ADK stack to use App instead in addition to root_agent
The convention:

  • If some fields(like plugin) are defined both at root_agent and app, then a error will be raised.
  • app code should be located within agent.py.
  • an instance named app should be created

和訳:

  • appとroot_agentの両方でpluginのようなフィールドが定義された場合はエラーを発生させる
  • appのコードはagent.py内に配置する
  • appという名前のインスタンスを作成する

これにより、Agentとその周辺機能を一つのユニットとして扱えるようになり、アプリケーションのポータビリティと再利用性が大幅に向上します。

Appの使い方

App を利用するには、agent.py(またはAgentを定義しているファイル)内で、google.adk.runners.App クラスのインスタンスを作成します。インスタンス名は app とすることが規約となっています。

agent.py
from google.adk.agents import Agent
from google.adk.apps import App
from my_plugins import MyLoggingPlugin, MyAuthPlugin # 自作のPlugin

# これまで通りAgentを定義
root_agent = Agent(
    model='gemini-2.5-flash',
    name='root_agent',
    description='A helpful assistant.',
    instruction='Answer user questions.',
)

# Appインスタンスを作成し、agentとpluginsを渡す
app = App(
    name='helpful_agent',
    root_agent=root_agent,
    plugins=[
        MyLoggingPlugin(),
        MyAuthPlugin(),
    ]
)

このように agent.py 内に app インスタンスを定義しておけば、adk web などのRunnerは root_agent の代わりに app を自動的に認識し、指定されたAgentとPluginを読み込んでくれます。
これにより、adk web を使う場合でも、わざわざカスタムRunnerを実装することなく、Pluginを利用したAgentを手軽に実行できるようになりました。

またRunnerを扱う場合でも、agentの代わりにappを渡すことで、Appを利用することができます。

main.py
runner = InMemoryRunner(app=agent.app)

Appの規約

App を利用する上での規約がいくつかあります。

  • フィールドの重複定義の禁止: AppRunner の両方でpluginsが定義されている場合、エラーが発生します。機能はどちらか一方に寄せる必要があります。
    • これは意図しない設定の上書きを防ぎ、設定の所在を明確にするためです。
  • agent.py への配置: app インスタンスのコードは agent.py 内に配置することが推奨されています。
  • app というインスタンス名: Runnerが自動検出するために、インスタンス名は app にする必要があります。

注意点: Agent Engineでの利用

一点注意が必要なのは、2025年9月11日現在、この App の仕組みは Agent Engine へのデプロイではまだサポートされていないという点です。
今後のアップデートでAgent Engineでも App がサポートされることで、より一貫性のある開発・デプロイ体験が実現されることを期待したいですね。

まとめ

今回はADK 1.14.0で導入された App という新しい概念について解説しました。

App は、AgentとPluginを一つのパッケージとしてまとめることで、ADKアプリケーションのモジュール性とポータビリティを大きく向上させる重要な機能です。特に、これまで adk web でPluginを使いづらかった問題が解消されたのは、開発効率の観点から非常に大きな進歩と言えるでしょう。

まだAgent Engineで使えないなどの制約はありますが、今後のADK開発のスタンダードになっていく可能性を秘めた機能だと思います。

なお、今回のリリースでは、ツールの実行前にユーザーの確認を挟むことができる「Tool Confirmation Flow」も追加されています。こちらも非常に興味深い機能なので、近いうちに別の記事で詳しく解説したいと思います。


お知らせ/宣伝

ADKUGはADK開発者が集う日本語のDiscordコミュニティです。ADKに関する情報交換や議論に興味がある方は、ぜひご参加ください!

https://discord.gg/BKpGRzjtqZ

また、ADKの最新のコミットログやリリースノートを分かりやすく解説するPodcastを、月・水・金に配信しています。ADKの動向を追いかけたい方は、ぜひ聴いてみてください。

https://www.youtube.com/playlist?list=PL0Zc2RFDZsM_MkHOzWNJpaT4EH5fQxA8n

Discussion