何が1.0になったか
ADKはAgent Development Kitの略です。Googleは、エージェントの動作、ツール利用、複数エージェントの役割分担をコードで定義し、テスト、デバッグ、配備まで扱う枠組みとして公開しています。一般的なチャット用SDKが「モデルへ入力を送り、出力を受け取る」層を主に担うのに対し、ADKは処理を続ける主体の設計を受け持ちます。
| 比較軸 | 一般的なモデルSDK | ADK for Kotlin 1.0 |
|---|---|---|
| 主な対象 | 生成APIの呼び出し | エージェントの実行と連携 |
| 状態 | アプリ側で設計 | セッション、メモリ、成果物を扱う |
| ツール | 呼び出し定義を個別実装 | 注釈とKSPでスキーマを生成できる |
| 長時間処理 | 再開処理を自前で用意 | 停止、直列化、再開を支援 |
| 実行場所 | 主にクラウドAPI | JVM、Android端末内、クラウド |
今回の1.0は、Kotlin版がADK 1.0 Coreの機能と揃ったことを意味します。公式リリースには、階層型マルチエージェント、コンテキスト圧縮、Human-in-the-loop（HITL）、長時間ツール、セッション再開、Java相互運用が並びます。HITLは、送金や削除などの重要操作の前で処理を止め、利用者の確認後に続きから動かす仕組みです。
複数AIの役割分担そのものを確認したい場合は、TechCreateのマルチエージェントシステム入門も参考になります。ADK for Kotlinの新しさは、考え方だけでなく、KotlinやJavaの既存コードへ接続できる実装部品として1.0へ到達した点にあります。
1.0で揃った機能
業務エージェントは、1回の質問へ答えるだけでは終わりません。専門エージェントへ仕事を渡し、途中でツールを呼び、危険な操作では止まり、数時間後や次の起動時に再開する必要があります。ADK for Kotlin 1.0は、これらを別々の独自実装にせず、同じ実行系で扱うことを狙っています。
| 機能 | できること | 読者が確認する点 |
|---|---|---|
| 階層型マルチエージェント | 親から専門の子エージェントへ委譲する | 役割境界と失敗時の戻り先 |
| コンテキスト圧縮 | 過去の会話を要約してトークン量を抑える | 要約で失ってはいけない事実 |
| HITL | 実行を止め、承認後に再開する | 誰が何を承認したかの監査記録 |
| 長時間ツール | 終了を待たず、後から結果を受け取る | 冪等性、タイムアウト、再試行 |
| セッション再開 | 状態を保存し、別の起動で続行する | 保存先、暗号化、保持期間 |
| Java相互運用 | JavaアプリからKotlin版を利用する | 既存DIや非同期処理との接続 |
ツール定義では、Kotlinの関数へ @Tool と @Param を付けます。Kotlin Symbol Processing（KSP）がビルド時に関数呼び出し用の定義を生成するため、実行時のリフレクションへ依存せず、型とスキーマのずれをコンパイル工程で見つけやすくなります。
一方、型があるだけで安全になるわけではありません。ツールが受け取る引数の意味、外部APIの権限、再試行時の二重実行は、アプリ側で設計します。AIエージェントが試作で止まる要因を整理したNEC・ツルハのPoC検証記事が示すように、本番化では回答精度だけでなく、既存業務との接続と運用責任が問われます。
端末内とクラウド
ADK for Kotlin 1.0では、同じ LlmAgent APIの背後に異なるモデル実行環境を置けます。公式READMEは、LiteRT-LM、ML Kit、Firebase AIの3経路を示しています。すべてが同じ能力を持つわけではないため、「オンデバイス対応」という一語だけで選ばないことが重要です。
| 実行経路 | 推論場所 | ツール呼び出し | 主な条件 |
|---|---|---|---|
| LiteRT-LM | 端末内またはJVM | 対応 | モジュールはJDK 21以上。端末性能とモデル配布を確認 |
| ML Kit | Android端末内 | 未対応 | Gemini Nano連携はbeta。現時点は通常の生成向け |
| Firebase AI | クラウド | 対応 | Firebase設定、通信、モデル利用条件が必要 |
端末内推論は、推論時にAPIキーやネットワークを使わず、遅延やプライバシーの要件に対応しやすい利点があります。しかし、端末ごとのメモリ、対応モデル、配布容量、電力消費は残ります。ML Kit経路はツール呼び出しに未対応で、functionCall と functionResponse が扱えないと公式READMEに明記されています。
クラウド側のFirebase AIは、より大きなモデルとツール呼び出しを使えます。端末内の軽い分類や個人情報を含む前処理はLiteRT-LMへ置き、難しい推論だけをクラウドの子エージェントへ渡す構成も可能です。ただし、どのデータを外へ出すか、オフライン時に何を諦めるか、クラウド障害時にどこまで動かすかは、先に決める必要があります。
導入は依存追加から
ADK for Kotlin自体はApache License 2.0で公開されています。フレームワークの利用料は示されていませんが、Gemini API、Firebase、Google Cloudなど外部のモデル・基盤を使えば、それぞれの料金と利用条件が適用されます。「OSSだからAI利用も無料」とは分けて考えます。
最小構成では、Gradleへ次の依存を追加します。
dependencies {
implementation("com.google.adk:google-adk-kotlin-core:1.0.0")
ksp("com.google.adk:google-adk-kotlin-processor:1.0.0")
}
導入順は、次の5段階に分けると境界を確認しやすくなります。
- 1つの読み取り専用ツールだけを持つエージェントを作る
- 入力、ツール呼び出し、最終出力をテストへ固定する
- セッションを終了し、保存後に再開できるか試す
- 書き込み操作へHITLを付け、拒否時の経路も試す
- 端末内とクラウドを分け、通信断と再試行を検証する
公式リポジトリにはJVM、Android、Javaの実行例があります。最初から複数エージェントを組むより、単一エージェントの失敗条件を測ったあとに委譲を増やすほうが、どの層で壊れたかを追いやすくなります。Android側の技術要件や担当範囲を整理するには、Androidエンジニアの仕事内容と必要スキルもあわせて確認できます。
本番前の注意点
「1.0 GA」は重要な節目です。ただし、公式READMEの末尾にはPre-GA条件の注意書きがあり、ML Kitモジュールにも 1.0.0-beta が付いています。コアの安定版と、接続先ごとの提供段階を分けて読む必要があります。
| 確認項目 | 失敗しやすい場面 | 最低限の検証 |
|---|---|---|
| 承認 | UIだけ承認済みに見える | 実行IDと承認者をサーバー側へ記録 |
| 再開 | 同じ処理を二重実行する | 冪等キーと完了済み判定を用意 |
| メモリ | 古い情報や機密を持ち続ける | 保存範囲、削除、保持期間を決める |
| 端末内モデル | 機種差で速度と品質が変わる | 対象端末ごとに時間、メモリ、電池を測る |
| クラウド | 通信断や料金上限で止まる | 失敗時の縮退と予算アラートを試す |
| Webサーバー | 開発UIやAPIを外部公開する | 認証を前段に置き、不要なUIを無効化 |
公式READMEは、内蔵Webサーバーが初期状態でloopbackへbindする理由を、エンドポイントが未認証だからと説明しています。0.0.0.0 へ広げる場合は、自前の認証を前段に置くよう求めています。開発UIは便利ですが、トレースやエージェント構成が見える面を本番へそのまま出さない判断も必要です。
HITLも万能な安全装置ではありません。人が承認画面で判断できる材料、拒否しても処理が壊れない設計、承認後に内容が差し替わらない保証が揃って、はじめて意味を持ちます。フレームワークが提供する「止める機能」と、組織が決める「止める基準」は別物です。
どのチームに向くか
ADK for Kotlin 1.0は、KotlinまたはJava資産があり、Androidとサーバーの処理を同じ型と実行概念でつなぎたいチームに向きます。特に、端末内推論とクラウド推論を要件ごとに分けたい場合は、比較対象へ入れる理由があります。
| チームの条件 | 適合度 | 最初の検証 |
|---|---|---|
| Androidでオフライン処理が必要 | 高い | LiteRT-LMの対象端末実測 |
| Kotlin/JVMの既存サービスがある | 高い | Java相互運用と監視連携 |
| 重要操作に人の承認が必要 | 高い | HITLの監査と拒否経路 |
| Python中心で端末内要件がない | 条件次第 | 既存ADKとの移行価値を比較 |
| ML Kitでツール実行したい | 現時点では低い | betaの制約解消を待つ |
採用判断では、機能数より「失敗した仕事をどこから再開できるか」を見るべきです。AIエージェントの本番運用では、正常系のデモより、通信断、承認拒否、二重実行、古いメモリ、端末差のほうが運用コストを左右します。
1.0は、Kotlin開発者がエージェントを試せる段階から、設計を比較できる段階へ進んだ合図です。次に確かめるべきは、モデルの派手な回答ではありません。自分たちのアプリが止まり、戻り、拒否される場面まで、同じ設計で扱えるかです。
まとめ
- ADK for Kotlin 1.0は、Kotlin、Java、Androidで、複数エージェント、HITL、長時間処理、状態再開を共通の実行系へまとめるOSSです。
- コアがGAでも、ML Kit連携はbetaでツール呼び出しに未対応です。端末内、Firebase、JVMの提供条件を個別に確認する必要があります。
- 導入価値は機能一覧だけでは決まりません。承認拒否、通信断、二重実行、端末差を先に試すことで、本番に進める範囲が見えます。
