【Google Cloud Next Tokyo 26】Agent Development Kit (ADK) と Agent Platformで実現する、次世代の業務効率化

Transcript

1. Agent Development Kit (ADK) と Agent Platformで実現する、 次世代の業務効率化 Proprietary
2. 原 和希 株式会社サイバーエージェント MIU AI戦略本部 / AI/MLエンジニア Google Developer Experts (Cloud/AI) Google Cloud Next Tokyo Proprietary
3. MIU ( Media & IP United ) 管轄とは MIU は、株式会社サイバーエージェントにおいて、 メディア事業と IP 領域を横断的に推進する事業領域です。 多様なメディアサービスやコンテンツ、知的財産を掛け合わせる ことで、新たな価値創出と事業成長の加速を目指しています。 Google Cloud Next Tokyo Proprietary
4. AGENDA Google Cloud Next Tokyo 01 02 03 04 業務改善の方向性 エージェントアーキテクチャ ADK Eval と開発ワークフロー まとめ Proprietary
5. 今日話すこと /話さないこと 話すこと • • 社内エージェントの開発を通して得られた、業務効率化時の考え Google Cloud を使ってどのようにエージェントを開発・運用しているか 話さないこと • 開発しているエージェントの具体的な機能・仕様の詳細 Google Cloud Next Tokyo Proprietary
6. 業務効率化エージェントを開発する際の エッセンス・技術・開発プロセス に焦点を当てる Google Cloud Next Tokyo Proprietary
7. 01. 業務改善の方向性 Google Cloud Next Tokyo Proprietary
8. 解決したかった業務課題 1,000+ ドキュメントの品質を保つ 洗い出しと編集作業による、人的コストが積み上がっていた。 加えて、更新性を向上したかった。 Google Cloud Next Tokyo Proprietary
9. 理想状態 Before After Google Cloud Next Tokyo Proprietary
10. 理想状態 Before After チャット形式だと、人間との対話が多く、 効率化に繋がりにくい Google Cloud Next Tokyo Proprietary
11. 理想状態 Before After 長時間タスクになるため、 エージェントの出力を監視するのは避けたい Google Cloud Next Tokyo Proprietary
12. 理想状態 Before After 最終チェックでのフィードバックは エージェントの品質改善に活用していきたい Google Cloud Next Tokyo Proprietary
13. 人の時間を『作業』から 専門性を活かした『判断』へ Google Cloud Next Tokyo Proprietary
14. 02. エージェント アーキテクチャ Google Cloud Next Tokyo Proprietary
15. 技術構成 • エージェントフレームワーク: 「ADK 2.0」 • 実行基盤: 「Agent Platform Agent Runtime, Cloud Run Jobs」 • Webアプリ: 「Cloud Run Service」 Agents Job Worker Web App Cloud Run Service Cloud Run Jobs Gemini 3.5 Flash/ 2.5 Pro Agent Platform Agent Runtime MCP Google Cloud Next Tokyo API Proprietary
16. Workflow か Agentic か やみくもに LLM にルーティングをさせない Workflow (ADK 2.0 Workflow) Agentic (LlmAgent) • 固定グラフ • LLM がルーティングと Tool 選択を判断 • 決定論的 • 柔軟だが揺らぐ • 定型の業務プロセス向き • カバー範囲が広域、 • デバッグが比較的容易 探索的・非定型なタスク向き • Google Cloud Next Tokyo デバッグが比較的困難 Proprietary
17. 業務プロセスを分解し、 性質を見極めて選択することが重要 エージェントにやらせたいことを考える。 「決定論的な作業なのか？」 「想定するユースケースのスコープはどこまでか？」 Google Cloud Next Tokyo Proprietary
18. 業務を分解できた分だけ、 エージェントは強くなる。 言語化できていない業務をやらせることはできない • グラフに描けないなら、業務をまだ分解しきれていないサインかも • 成果物イメージのすり合わせや、よい出力は何か を議論するところから始める • Workflow からはじめて、柔軟性を上げていく ◦ e.g. Google Cloud Next Tokyo ▪ Workflow をサブエージェントにする ▪ Dynamic agent workflow を使う ▪ Agentic なルーティングに切り替える Proprietary
19. 目的に合わせた UI • 「AI Agent ≠ チャットアプリ」 ◦ • • チャット: 想定する入力の柔軟性・機能のカバー範囲が広いケース フォーム形式の UI ◦ 柔軟な応答を必要としない機能なため ◦ ユーザー応答は逐次、選択形式 (ボタン/ チェックボックス )で取得 利用者が直感的に利用できるようにする Google Cloud Next Tokyo Proprietary
20. ADK 2.0 Workflow での実装 • Workflow と Agentic のハイブリッド（ SubAgent で柔軟性を活かす） • 分岐・合流・再試行・フォールバック • Agent Runtime へのデプロイ (セッション管理 / スケーリング) Parallel tasks 再試行 SubAgent 1 GUARD 品質を判定 Fan-out Preprocess ••• Input 全タスクの 完了を待つ 処理を分岐 SubAgent n Google Cloud Next Tokyo Join Postprocess 結果を統合 Output GUARD 品質を判定 Proprietary
21. 「人間が待つ」をなくす Cloud Run Jobs から Agent Runtime へリクエスト • 一括投入 : スプレッドシートでバッチ処理。1 件ずつの投入をしない • 並列実行 : 1 件 = 1 タスクの並列 index で一斉処理 • バックグラウンド処理 : 画面を閉じて、人間は他の仕事へ Google Cloud Next Tokyo Proprietary
22. 03. ADK Eval と 開発ワークフロー Google Cloud Next Tokyo Proprietary
23. なぜ出力評価を行うのか 使われるエージェントにするために、評価というコンパスを持つ。 • 高速に改善サイクルを回したい • 品質向上・維持を定量的に追いたい • デグレは起こしたくない Google Cloud Next Tokyo Proprietary
24. ADK の組み込み評価機能 AI エージェントの出力品質を自動で評価する仕組みが標準搭載 • 『評価ケース × 評価基準』を定義して評価実行 ◦ • LLM as a Judge, Tool Trajectory, Reference ベースの評価が可能 下記の方法で利用 ◦ adk web（開発者が実行・確認） ◦ adk eval CLI（コーディングエージェント） ◦ 評価ケース 入力・初期状態 Agentを実行 pytest（CI） LLM-as-judge Google Cloud Next Tokyo 評価基準 Tool・rubric 結果＋理由 Reference を元に評価 Proprietary
25. 機能追加で広がる評価の空白 実装が進んでも、評価ケースとルーブリックの更新が放置されがち 評価側 実装側 1 2 3 既存評価の範囲 既存機能 新機能・指示 新しい Tool 以前のケースとルーブリック 新しい要件 未評価のまま Google Cloud Next Tokyo Proprietary
26. 開発ハーネス -コーディングエージェント × ADK Eval 実装・評価の差分を産まない : 実装と評価資産を同じ変更単位 にする仕組み化 開発品質の向上 : 『実装 → EVAL → 失敗した観点を読んで修正』を収束まで自走 STEP 1 STEP 2 STEP 3 専用 Skill Coding Agent 専門家と開発者 変わった出力・ Tool・安全境界を確認 追加すべきケースとルーブリックを提案 評価資産を実装し、 ADK Eval を実行 結果と変更理由を整理 最終判断を持つ 基準の妥当性と境界をレビュー Google Cloud Next Tokyo Proprietary
27. 評価基準・背景を一元管理 - Evalset / ケース ルーブリック どの入力で確かめるか どの基準で評価するか EVAL.md PR 追加背景と対応関係 人間によるレビュー Repository Google Cloud Next Tokyo Proprietary
28. 評価基準・背景を一元管理 利用者 FB・専門家レビュー・本番失敗を再現ケースも加える - Evalset / ケース ルーブリック どの入力で確かめるか どの基準で評価するか EVAL.md PR 追加背景と対応関係 人間によるレビュー Repository Google Cloud Next Tokyo Proprietary
29. 04. まとめ Google Cloud Next Tokyo Proprietary
30. まとめ エージェント設計 実行基盤 業務を分解し、性質に合わせてWorkflow と Agentic を使い分ける・組み合わせる。 Agent Runtime に実行を任せ、 安定性と スケールを確保する。 業務への組み込み 品質と運用 一括・並列・バックグラウンド処理で、 人を待たせない。選択式 UI で、迷わせない。 ADK Eval と Coding Agent で 評価・修正を回し、品質を保つ。 判断は人が持つ。 Google Cloud Next Tokyo Proprietary
31. Thank you Proprietary