はじめに
2026年9月、Google Developers Blogから開発者にとって見逃せない2つの発表がありました。
1つ目は、AIコーディングエージェントを「どう評価し、どう改善し続けるか」という設計論。Claude CodeやGemini CLIのようなコーディングエージェントを自社のワークフローに組み込むエンジニアリングチームにとって、実務に直結する内容です。
2つ目は、Google Agent Development Kit（ADK）のKotlin版が正式に1.0へ到達したという発表。Kotlin/Androidエンジニアが本番品質のマルチエージェントアプリを作れる環境が整ったことを意味します。
📌 影響を受ける人
- AIコーディングエージェント（Claude Code, Gemini CLI等）を業務に導入し、システムプロンプトやハーネスを継続的に改善しているエンジニア
- Kotlin/Androidでエージェント機能を組み込みたいモバイルエンジニア
- マルチエージェントシステムの評価基盤を設計しているMLOps/プラットフォームエンジニア
どちらも既存コードへの破壊的変更はなく、緊急対応は不要ですが、今後のエージェント運用・開発の指針として押さえておく価値があります。
変更の全体像
2つの発表は一見無関係に見えますが、どちらも「AIエージェントを実運用に乗せる」ための土台という共通テーマを持っています。
変更内容
1. ハーネスエンジニアリング：行動評価という考え方（severity: medium）
Googleは、SWE-benchに代表される「エンドツーエンドベンチマーク」だけに頼るエージェント評価には限界があると指摘しています。
| 評価手法 | 特徴 | 弱点 |
|---|---|---|
| エンドツーエンドベンチマーク（SWE-bench等） | 総合的な性能スコアが得られる | 高コスト・低速、失敗の根本原因がわからない |
| 行動評価（behavioral evaluations） | 中間アクション（ツール呼び出し、ファイル変更内容など）を検証するユニットテスト形式 | 個々のチェックは局所的（マクロな性能保証にはならない） |
行動評価は最終出力の文字列一致を見るのではなく、「特定のツールが正しい引数で呼ばれたか」「意図した種類のファイル変更が行われたか」といった離散的な中間ステップをアサートします。これを安価かつ高速にローカル実行できるようにし、マクロなエンドツーエンドベンチマークと併用することで、システムプロンプトの改善やモデルのアップグレードを行うたびに「壊れていないか」を素早く確認できるようになります。
💡 Tips
自前でClaude CodeやGemini CLIをベースにしたエージェントハーネスを組んでいる場合、「最終出力の一致」だけでテストしていないか見直すとよいでしょう。ツール呼び出しの順序・引数・差分内容を検証する軽量テストを先に整備すると、プロンプトチューニングの反復速度が大きく上がります。
2. ADK for Kotlin 1.0 正式リリース（severity: high）
Agent Development Kit（ADK）はGoogleが提供するマルチエージェント開発フレームワークで、これまでPython版・Java版が提供されてきました。今回、Kotlin版が正式に1.0に到達し、他言語版とのフル機能パリティを達成しました。
| 項目 | 内容 |
|---|---|
| 基盤 | Kotlin Multiplatform（KMP） |
| 関数呼び出し | Kotlin Symbol Processing（KSP）によるゼロリフレクション・型安全な実装 |
| 高度な機能 | human-in-the-loopワークフロー、コンテキスト圧縮（context compaction） |
| Android拡張 | LiteRT-LM（ローカルモデル）、Firebase AI（クラウド推論）、Room（セッション永続化）、AppSearch（セマンティックメモリ） |
| 対応言語版 | Python / Java とフル機能パリティ |
影響と対応
- エージェント運用チーム：行動評価の考え方を、既存のCI/評価パイプラインに追加検討する価値があります。特にシステムプロンプトを頻繁に変更する運用では、マクロベンチマークだけに頼るとフィードバックループが遅くなりがちです。
- Kotlin/Androidエンジニア：これまでAndroidアプリにAIエージェント機能を組み込む際はPython/Javaブリッジやサーバーサイド実装に頼るケースが多かったはずですが、ADK for Kotlin 1.0によりネイティブKotlinで完結できるようになりました。ローカル推論（LiteRT-LM）とクラウド推論（Firebase AI）を切り替えられる構成も検討可能です。
- 破壊的変更（Breaking Change）は含まれておらず、既存プロジェクトの緊急対応は不要です。
⚠️ Breaking Change
今回の2件に既存APIへの破壊的変更はありません。既存のADK Python/Javaプロジェクトや既存のコーディングエージェント運用に対する即時対応は不要です。
コード例
行動評価の考え方を簡易的なユニットテストとして表すと、以下のようなイメージになります（概念例）。
Before（最終出力の文字列一致のみを見る評価）
def test_agent_fixes_bug():
output = agent.run("バグを修正して")
assert "fixed" in output.final_message # 曖昧で壊れやすい
After（中間アクションを検証する行動評価）
def test_agent_fixes_bug():
trace = agent.run_with_trace("バグを修正して")
# 1. 正しいファイルを読んだか
assert trace.tool_called("read_file", args={"path": "src/utils.py"})
# 2. 意図した種類の変更が加えられたか
diff = trace.get_file_diff("src/utils.py")
assert "except ZeroDivisionError" in diff.added_lines
# 3. テストツールが実行されたか
assert trace.tool_called("run_tests")
このように中間アクションを検証することで、エージェントの「どこで」判断が誤ったのかを高速に特定できます。
まとめ
- ハーネスエンジニアリング論：SWE-benchのようなエンドツーエンドベンチマークだけでなく、中間アクションを検証する「行動評価」を併用することで、AIコーディングエージェントのプロンプト改善・モデル更新を安全かつ高速に回せる。
- ADK for Kotlin 1.0：Python/Java版とフル機能パリティを達成し、KSPによる型安全な関数呼び出しとAndroid向け拡張（LiteRT-LM、Firebase AI、Room、AppSearch）により、KotlinネイティブでのAIエージェント開発が本番レベルで可能になった。
- どちらも即時の破壊的対応は不要だが、今後のエージェント設計・評価基盤構築の指針として押さえておきたい発表。