nikkie-ftnextの日記

イベントレポートや読書メモを発信

Agent2Agent サーバとして使う Agent Development Kit 製エージェントの session service を考える

はじめに

七尾百合子さん、お誕生日 333日目 おめでとうございます! nikkieです。

ここ最近マインドシェアを取られていた技術的問題に自分の中で答えが出たので書き記します。

目次

ADK の session service

Agent Development Kit (ADK) は、人間とエージェントの会話スレッドを session として扱います。
https://google.github.io/adk-docs/sessions/#core-concepts
人間 -> エージェント -> 人間 -> エージェント と1つの session に蓄積していきます。
ChatGPT や Claude、Gemini、他にコーディングエージェントたちとのやり取りの扱いと同じ感じですね。

Agent2Agent Protocol (A2A) でも同様に、エージェントAとBの会話が session に蓄積していきます

さて、session を管理するのがSessionServiceです。
https://google.github.io/adk-docs/sessions/session/#managing-sessions-with-a-sessionservice
提供されている実装は以下です。

  • VertexAiSessionService
  • DatabaseSessionService
  • InMemorySessionService
  • SqliteSessionService

A2A サーバにするエージェントの session service としてどれを選択するかを検討していきます。
慣れ親しんでいるのが Kubernetes 環境なので、そのバイアスは入っていると思います

VertexAiSessionService:A2A では動かない😫

https://google.github.io/adk-docs/sessions/session/#vertexaisessionservice

Vertex AI Agent Engine を session service に使うという選択肢は、現時点ではありません。
なぜならバグがあって A2A サーバでは動かないからです。

挙げた issue は約半年経過しても放置されているので、しびれを切らしてプルリクエストを送りました。
Google 内部で実装して無言クローズでもかまわないので、とにかく直してほしいです。

(Agent Engine はマネージドサービスなので、後述するテーブル定義の変更にも追従できると期待しています)

DatabaseSessionService:動くが、マイナーバージョンアップで壊れる😩

https://google.github.io/adk-docs/sessions/session/#databasesessionservice

PostgreSQLMySQL のデータベースを session service に使います1
これは A2A サーバと問題なく動きます。
しかし、ADK のマイナーバージョンアップで壊れます。

バージョンアップしただけで壊れて、テーブル定義の更新に対応するための余計な作業を強いられます
運用を経験しましたが、テーブル定義の変更に追従するための十分なサポートは提供されているとは言えず、ほとほと嫌気が差します(他の選択肢を探すために、この記事を書いています)。
sqldefでの抵抗を自作しました。

私は絶望していますが、希望的な動きも出てきていました。

A2A の session は再利用されることがないぞ💡

ADK で実装した A2A サーバの session service としては Agent Engine もデータベースも満足できず、行き詰まっていました。
その中で、私の関わるユースケースでは、ADK で A2A を使う分には session の再利用がない2ことに気づきました。
A2A サーバを呼び出す session は一度きりで済んでいます。
エージェントAとBのやり取りは1往復ごとに1 sessionです。
session service で session を永続化する必要って実はないのかもしれないぞ...

InMemorySessionService

https://google.github.io/adk-docs/sessions/session/#inmemorysessionservice

session をメモリに保持します。
再起動したら session は消えます。

ADK のバージョンを上げたときに壊れる」はなくなりますね。
一方、メモリに保持するので長期間運用したら、メモリが溢れてしまう懸念があります。
ただ私はそれでもいいんじゃないかと思いました(これを嫌うなら SQLite でしょうか)。
データベースに保存する場合もちょこちょこ接続エラーになるのを観測しており、out of memory で落ちても(Kubernetes で)再起動して次から復活するからどっこいどっこいに映ります。

SqliteSessionService

(他と違ってドキュメントにありませんが)ADK でデフォルトの session service です(v1.20.0 から)。
.adk/session.dbに session を保存します。

session.dbの容量は増加していくので、リソースを食いつぶす懸念はあります。
ですが、A2A サーバが動き、テーブル定義の更新への追従も PostgreSQLMySQL と同規模以下3
こちらも選択肢としてあると思います。

終わりに

A2A サーバとなる ADK エージェントの session service を考えました。

  • Vertex AI Agent Engine は、バグがあって動かない
  • データベース(PostgreSQL, MySQL)は、ADK のマイナーバージョンアップで壊れることがたびたび発生し、運用が辛い
  • 今の私が選ぶなら(やや消去法的に)InMemorySessionServiceSqliteSessionService
    • A2A での session は実は永続化しなくてよいのでは

発想の転換で突破口が見えました!

P.S. RedisSessionService

google-adk-communityパッケージには、Redis という選択肢もあります。
https://github.com/google/adk-python-community/blob/v0.3.1/src/google/adk_community/sessions/redis_session_service.py
A2A サーバと動くかや運用の手間については未検証です


  1. SQLAlchemy に extra を指定します
  2. A2A の仕様からは反論があるかもしれません(ADK が実験的サポートのためこうなっている)
  3. 1ファイルなので扱いやすい気がします