はじめに
2026年6月30日、Google AI 開発者ブログから AI エージェント開発に関する重要な発表が2件公開されました。
- エージェント品質フライホイール: コーディングエージェントのプロンプト改善が本番環境で本当に効果があるのかを、5段階のプロセスで自動検証する新しい開発者スキル
- ADK for Go 2.0: グラフベースのワークフローエンジンと human-in-the-loop（人間の介入）を標準搭載した Agent Development Kit (ADK) のメジャーアップデート
どちらも「マルチエージェントシステムをいかに壊さずに進化させるか」という共通テーマを持っています。エージェント開発が個人のプロトタイピングから本番運用フェーズに移る中で、Google はこの2つのリリースを通じて「品質評価」と「実行基盤」の両面からエコシステムを強化しようとしています。
📌 影響を受ける人
- Go で AI エージェント・マルチエージェントシステムを構築している開発者
- コーディングエージェント（自動コード修正・自動レビューなど）を継続運用していて、プロンプト変更の影響評価に悩んでいるチーム
- human-in-the-loop が必要な業務フロー（承認・レビュー必須のワークフロー）を AI エージェント化したい開発者
変更の全体像
2つの発表は独立したプロダクトですが、「エージェントを安全に・継続的に進化させる」という目的でつながっています。
フライホイールが「変更が品質を落としていないか」を継続的に検証するフィードバックループを提供し、ADK for Go 2.0 はそのループの中で動くエージェント自体を、より信頼性高く・人間の判断を組み込みながら実行するための基盤を提供する、という関係です。
変更内容
1. エージェント品質フライホイール（severity: medium）
コーディングエージェント運用で起きがちな問題は、「単一のバグを直すためのプロンプト修正が、他のケースで意図しないリグレッションを引き起こす」ことです。これを検出するために、Google は以下の5段階を自動化する開発者スキルを公開しました。
| ステージ | 内容 |
|---|---|
| ① データ準備 | 評価対象となる本番トラフィック or 合成シナリオを収集 |
| ② 推論実行 | 対象のコーディングエージェントに実際にタスクを実行させる |
| ③ グレーディング | 適応型 AutoRaters（自動評価器）が出力を採点 |
| ④ 失敗クラスタ分析 | 失敗パターンをクラスタリングし、根本原因を特定 |
| ⑤ 最適化実行 | 特定された失敗クラスタに対して、対象を絞った改善を適用 |
特徴的なのは、開発者は自然言語でテスト目標を記述するだけでよく、独立した評価サービスが性能改善を客観的にカウント・検証してくれる点です。「直感的には良くなった気がする」という主観評価ではなく、定量的な裏付けを得られるようになります。
2. ADK for Go 2.0（severity: high）
Agent Development Kit (ADK) for Go がメジャーバージョンアップし、以下の機能が追加されました。
| 項目 | ADK for Go 1.x | ADK for Go 2.0 |
|---|---|---|
| ワークフロー定義 | 単一エージェント中心 | グラフベースのワークフローエンジン（ファーストクラス対応） |
| 人間の介入 | 個別実装が必要 | human-in-the-loop (HITL) が組み込みプリミティブとして提供 |
| オーケストレーション | 静的な構成が中心 | プレーンな Go コードによる動的実行が可能 |
| 障害対応 | 個別実装が必要 | 指数バックオフ・リトライなどのレジリエンス機能が組み込み済み |
| 実行モデル | エージェントごとに異なる場合あり | 単一エージェント〜複雑なグラフまで同一ランタイムで統一 |
| テレメトリ／状態管理 | 個別対応 | 統一ランタイムにより簡素化 |
最大のポイントは「実行モデルの統一」です。これまでシンプルな単一エージェントと複雑なマルチエージェントグラフを別の仕組みで扱っていたチームも、ADK for Go 2.0 では同一ランタイム上でどちらも扱えるようになり、コードベースの一貫性が向上します。
影響と対応
💡 Tips
両者とも破壊的変更（Breaking Change）や料金変更は伴わない「新機能の追加」です。既存の実装を即座に変更する必要はありませんが、以下のようなケースでは早めの検討をおすすめします。
- コーディングエージェントを本番運用しているチーム: プロンプト変更のたびに目視や場当たり的なテストでリグレッションを確認している場合、品質フライホイールのスキルを導入することで、改善が定量的に裏付けられるようになります。導入コストは「自然言語でテスト目標を記述する」程度に抑えられている点も採用しやすいポイントです。
- Go で承認フロー・レビューフローを伴うエージェントを構築したいチーム: これまで HITL を自前実装していた場合、ADK for Go 2.0 への移行で実装コストを削減できる可能性があります。
- 複雑なマルチエージェントのオーケストレーションを検討中のチーム: グラフベースのワークフローエンジンにより、条件分岐・並列実行・人間の承認待ちなどを統一的なモデルで表現できるようになるため、新規設計時には ADK for Go 2.0 を前提に検討する価値があります。
コード例
具体的な API シグネチャは公式ブログで今後詳細が公開される見込みですが、設計思想を理解する上でのイメージ例を示します。
Before: 単一エージェント実装に HITL を個別に組み込む場合（イメージ）
// 承認待ちのロジックを自前で実装する必要があった
func handleTask(task Task) (Result, error) {
result, err := agent.Run(task)
if err != nil {
// リトライ処理も自前実装
for i := 0; i < maxRetries; i++ {
result, err = agent.Run(task)
if err == nil {
break
}
time.Sleep(backoff(i))
}
}
if result.RequiresApproval {
// 承認待ちの仕組みを個別に用意する必要があった
approved := waitForHumanApproval(result)
if !approved {
return Result{}, errors.New("rejected by human")
}
}
return result, nil
}
After: ADK for Go 2.0 のグラフベースワークフロー（イメージ）
// HITLとレジリエンスがワークフローエンジンに組み込み済み
workflow := adk.NewGraph().
AddNode("run_agent", agentNode,
adk.WithRetry(adk.ExponentialBackoff(maxRetries))).
AddNode("human_review", adk.HumanInTheLoop()).
AddEdge("run_agent", "human_review",
adk.When(func(r Result) bool { return r.RequiresApproval })).
Build()
result, err := workflow.Execute(ctx, task)
リトライや承認待ちといった「定型処理」がエンジン側に標準搭載されることで、エージェント開発者はビジネスロジックそのものに集中できるようになります。
まとめ
- エージェント品質フライホイールは、コーディングエージェントのプロンプト改善が本当に性能向上につながっているかを、5段階（データ準備 → 推論実行 → AutoRaters によるグレーディング → 失敗クラスタ分析 → 最適化実行）で自動検証する開発者スキル。自然言語でテスト目標を書くだけで導入できる。
- ADK for Go 2.0 は、グラフベースのワークフローエンジン、組み込み HITL、動的オーケストレーション、自動レジリエンス機能を追加したメジャーアップデート。単一エージェントから複雑なマルチエージェントグラフまで統一ランタイムで扱えるようになった。
- 両者とも破壊的変更や料金変更を伴わない新機能追加であり、既存実装への即時対応は不要。ただし、本番運用中のコーディングエージェントや、Go でのマルチエージェント開発を計画しているチームは、早めにキャッチアップしておく価値がある。
- AI エージェント開発が「プロトタイプ」から「本番運用」フェーズへ移行する中で、Google は「品質保証」と「実行基盤」の両輪でエコシステムを強化している、という大きな流れを押さえておくと今後のアップデートも理解しやすくなる。