Slide 1
Slide 1 text
1
メルカリにおけるデータアナリティクス
AI エージェント「Socrates」と ADK 活⽤事例
Naofumi Yamada (@na0fu3y)
2025-06-10
Slide 2
Slide 2 text
2
注意書き
● この資料は意図的に⼤量の⽂字で構成されています
○ Google NotebookLM を使って探索することを想定しています
■ Mind Map を使って構成を⾒ながら、資料と対話できます
Slide 3
Slide 3 text
3
Agent Engineer / Mercari BI Product
Google Developer Expert (Google Cloud)
Naofumi Yamada @na0fu3y
Slide 4
Slide 4 text
あらゆる価値を循環させ、あらゆる人の可能性を広げる
“Circulate all forms of value to unleash the potential in all people”
4
グループミッション
Slide 5
Slide 5 text
Japan Region
Mercari Group
Fintech
5
会社概要
メルカリグループは、株式会社メルカリと、その連結子会社で構成されています。
Marketplace
株式会社メルカリ
◼設立
◼事業内容
◼所在地
◼拠点
◼代表執行役 CEO
◼執行役 SVP of Japan Region
◼執行役員 CEO Marketplace
2013年2月1日
スマートフォン向けフリマアプリ
「メルカリ」の企画・開発・運営
〒106-6118 東京都港区六本木6-10-1
六本木ヒルズ森タワー
東京、福岡、大阪
山田進太郎
山本真人
迫俊亮
①2017年11月20日
②金融事業
③永沢岳志
株式会社メルペイ
①2014年1月
②US版メルカリの企画・開発・運営
③山田進太郎
④Palo Alto, California
Mercari, Inc.（US）
①1991年10月1日
②フットボールクラブ運営
③小泉文明
④茨城県立カシマサッカースタジアム
指定管理茨城県鹿嶋市 粟生東山2887番地
株式会社鹿島
アントラーズ・エフ・シー
インド開発拠点
①2022年6月
②インターネットサービス開発
③Carlos Donderis（取締役 Managing Director）
④Bangalore, Karnataka, India
Mercari Software Technologies
India Private Limited
①2021年4月28日
②暗号資産･ブロックチェーン
③中村奎太
株式会社メルコイン
①設立 ②事業内容 ③CEO ④所在地
Slide 6
Slide 6 text
2013年2月1日
会社設立日
東京、福岡、大阪
Palo Alto、Bangalore
オフィス
2,190名（連結）
従業員数
6
株式会社メルカリ 概要
Slide 7
Slide 7 text
7
エンタープライズ AI エージェント開発の実践知を共有
本⽇のゴール
Google ADK の可能性を Socrates を例として実感
AI エージェントプロジェクト推進へのヒントと刺激を提供
02
03
01
Slide 8
Slide 8 text
8
アジェンダ 〜Socrates 開発と ADK 活⽤の物語〜
1. 【挑戦】メルカリのデータ活⽤課題と Socrates 誕⽣
2. 【Socrates 詳解】データアナリティクス AI エージェントの全貌
3. 【背景理解】なぜ AI エージェントなのか？ なぜ⾃社開発なのか？
4. 【道具】Google ADK 登場と Socrates アーキテクチャ
5. 【学びの軌跡】技術選定とエコシステム構築の戦略
6. 【実践知】エンタープライズ AI エージェント運⽤のリアル
7. 【未来展望】ADK の進化への期待
8. 【まとめ】成功の鍵と教訓
Slide 9
Slide 9 text
9
1. 【挑戦】メルカリのデータ活⽤課題
と Socrates 誕⽣
メルカリが抱えていた課題と
データアナリティクス AI エージェント「Socrates」開発の背景
Slide 10
Slide 10 text
10
メルカリが直⾯していたデータ活⽤の壁 (1/2)
● 「データの宝庫」メルカリ: 膨⼤なお客様の⾏動、取引、商品データ。ま
さにビジネス成⻑の源泉。
● しかし、活⽤への「壁」:
○ SQL やデータ構造の専⾨知識の必要性: データの発⾒ / 権限申請 / 構
造理解が容易ではない。
○ データアナリストのボトルネック化: 分析依頼への対応に時間がかか
り、意思決定の遅延や機会損失が発⽣。
Slide 11
Slide 11 text
11
メルカリが直⾯していたデータ活⽤の壁 (2/2)
● 直⾯していた具体的な課題:
○ データ分析の属⼈化‧サイロ化: 特定アナリストへの問い合わせ集
中、分析ノウハウ共有の困難さ。
○ 定型業務の負荷: 定型的なデータ抽出‧可視化作業にアナリストの時
間が割かれる。
○ 探索的分析への時間不⾜: 要因深掘り、仮説検証、施策効果測定など
の複雑な分析に⼗分な時間を割けない。
○ ビジネスサイドのデータアクセス障壁: SQL の習熟が必要で、⾮専⾨
家にはハードルが⾼い。結果、データに基づいた迅速な意思決定が阻
害されることも。
● 「誰もが、もっと⼿軽に、データと対話できたら？」
Slide 12
Slide 12 text
12
Socrates 構想：AI による分析⽀援への期待
● Socrates 構想
○ 「優秀なデータアナリストと対話するかのように、誰もが⾃然⾔語で
データと会話し、必要な情報を引き出し、洞察を得られる仕組み」
● AI による分析⽀援への期待と、従来の LLM 単体アプローチの限界認識
○ 単純な Text2SQL + ⼀問⼀答では、実務の複雑なプロセスに対応困難
○ 参考: 1⽇50万件貯まるクエリのログを活かして、SQLの⽣成に挑戦し
ている話 - Speaker Deck
Slide 13
Slide 13 text
13
AI エージェント vs Text2SQL
特徴 AI エージェント Socrates Text2SQL
主⽬的 対話による分析・仮説生成・洞察獲得、タスク自動化 SQL 自動生成
柔軟性 ⭕高 (多様な質問、非定型分析に対応 ) ❌低 (定型クエリ中心)
知識源 ⭕大量のテーブルに関する情報、 RAG、ドキュメント、過
去の対話履歴、コード
❌限られたテーブルに関する情
報
ツール連携 ⭕多様なツールと連携 (BigQuery, Python, API 等) ❌ほぼ無し
構築‧運⽤ ❌プロンプト、ツール、周辺資産整備など多岐に渡る ⭕プロンプト改善が主
AI エージェントは複雑なタスクをこなせる半面、構築や運用が複雑
Slide 14
Slide 14 text
14
2. 【Socrates 詳解】データアナリ
ティクス AI エージェントの全貌
Socrates が何を⽬指し、何ができるのか、その具体的な機能と動作イメージ
Slide 15
Slide 15 text
15
UI イメージ: Streamlit ベースのチャットインターフェース
Socrates の分析ジャーニー（デモ）(1/2)
Slide 16
Slide 16 text
16
Socrates の分析ジャーニー（デモ）(2/2)
● 具体的な対話例:
○ 「先⽉の XX カテゴリの GMV 推移をグラフで教えて。理由も。」
○ 「GMVが急増した要因は？関連する可能性のある指標も教えて。」
○ 「メルカリの全額補償に関するプレスリリースの X（旧 Twitter）での
反応を教えて」
Slide 17
Slide 17 text
17
Socrates が実現する世界：⽬的と提供価値
● Socrates とは: データアナリストやビジネスユーザー（PdM、マーケター
等）向けの社内データアナリティクス AI エージェント。
● ⽬的
○ データ分析の⺠主化: 専⾨知識の有無によらず、誰もがデータにアク
セスし、洞察を得られるように。
○ 意思決定の迅速化: 分析にかかる時間を⼤幅に短縮。
○ データドリブンな⽂化醸成: データに基づく議論と⾏動を促進。
Slide 18
Slide 18 text
18
Socrates の主要機能
⾒出し 実⾏
準備
● 分析要求の理解 / 具体化
● 関連データ / ドキュメント
の提案と探索
● 仮説提案
● BigQuery クエリの⽣成 /
実⾏
● Python コードによる⾼度
な加⼯ / 分析 / 可視化
● 結果の解釈と洞察の提⽰
● レポート⾃動⽣成⽀援
活⽤
Slide 19
Slide 19 text
19
他ツールと協調して、良いとこどりを実現
Socrates との他の社内ツールとの共存関係
社内データプロダクト 分析⾃由度 SQL スキル ドメインデータ知識 環境構築
AI エージェント “Socrates” ⭐⾼い
+ ガードレール
⭕不要 ⭕不要 ⭕不要
BI レポート ❌ ⭕不要 ⭕不要 ⭕不要
Conversational Analytics
/ Looker Explores
/ Gemini in BigQuery
🔺 ⭕不要 🔺 ⭕不要
Cursor + MCPs ⭕⾼い ⭕不要 🔺 ❌
加⼯済みデータ 🔺 🔺 ⭕不要 ⭕不要
⽣データ ⭕⾼い ❌ ❌ ⭕不要
Slide 20
Slide 20 text
20
3. 【背景理解】なぜ AI エージェント
なのか？ なぜ⾃社開発なのか？
Socrates のような AI エージェントが登場した技術的背景と、メルカリの戦略
的判断
Slide 21
Slide 21 text
21
AI エージェントの定義
● AI エージェントとは:⾃ら「推論」し「⾏動」することで⽬標を達成する
システム。近年ではさらに⾼度で多様な特徴を持つように進化。
● AI エージェントの主要な特徴：
○ 推論 (Reasoning): 論理的に結論を導き、推論して、問題を解決する
○ ⾏動 (Acting): 計画や⼊⼒に基づき、環境に⾏動を起こす
○ 観察 (Observing): 環境を認識‧把握し、意思決定に活かす
○ 計画 (Planning): ⽬標達成のための⼿順を⽴案し、⾏動⽅針を決める
○ 協調 (Collaborating): ⼈間や他の AI と連携し、⽬標を達成する
○ ⾃⼰改善 (Self-refining): 経験から学び、継続的に性能を向上させる
What are AI agents? Definition, examples, and types | Google Cloud より要約
Slide 22
Slide 22 text
22
LLM の進化と限界、AI エージェントの必要性
● ⼤規模⾔語モデル（LLM）の⾶躍的進化 (例: Gemini 2.0 Pro)
○ ⾃然⾔語理解‧⽣成が、実⽤的な速度、精度、コストで利⽤可能に。
○ ⾼度な質疑応答、⽂章要約、翻訳、多様なコンテンツ作成、コード⽣
成⽀援など、ビジネス応⽤が急速に拡⼤。
● LLM 単体では実世界の複雑な問題解決には限界:
○ 受動性: プロンプトへの応答のみで、⾃律的なタスク遂⾏は困難。
○ 知識の固定化: 社内 DB 等の最新情報へアクセスできない。
○ ⾏動の制約: 外部システム操作などは実⾏不可。
● ⇒ LLMの「思考」を、現実世界での具体的な「⾏動」に繋げ、より⾼度な
タスクを⾃律的に実⾏させるAIエージェントへの期待が⾼まっている。
Slide 23
Slide 23 text
23
なぜ Socrates を⾃社開発したのか？ (1/2)
● タイミング (2025 年 3 ⽉時点)
○ データ活⽤AIプロジェクトの再燃と経営層の期待。
○ ⾼品質なデータマート (PJ 名: Basic Tables) の完成。
○ ⾼性能な LLM の登場。実⽤的な速度と精度。
○ LangGraph のような AI エージェント構築ライブラリ。
■ 2⽇で LangGraph ベースの初期デモが稼働。「AI エージェント
によるデータ分析⽀援」の有効性を確信。
○ エンタープライズレベルで信頼でき、メルカリの複雑なデータ環境と
要求に応えられる汎⽤的なデータ分析 AI エージェントがなかった。
Slide 24
Slide 24 text
24
なぜ Socrates を⾃社開発したのか？ (2/2)
● 「周辺資産」への早期投資の意図
○ AI エージェントのコア技術は急速にコモディティ化する可能性。
○ 真の競争優位性は、他社が模倣困難な「周辺資産」（構造化データ、
⾮構造化ナレッジ、業務プロセス、評価基盤）にある。
○ Socrates を⾃社開発し運⽤することで、これらの周辺資産の価値を早
期に実証し、全社的な整備‧強化を加速させる「触媒」としての役割
を期待。
○ ⽬指すのは「AI Agent Ready」な組織と環境の確⽴
Slide 25
Slide 25 text
25
Socrates の初期検証：PoC スコープ (1/2)
● PoC スコープ設定の戦略：「広範囲‧浅い」よりも「特定領域‧深い」
○ 理由：
■ 最⼤価値の想起： 限定的でもエンドツーエンドで分析プロセスが
⾃動化される体験で、AI エージェントが将来提供しうる最⼤価値
を具体的にイメージさせる。
■ コア技術の実現性証明： 最も重要な「⾃然⾔語 → SQL → 分析結
果」のフローが、⾼品質データに対して機能することを⽰す。
■ 具体的フィードバックの獲得： 「動くもの」があることで、ユー
ザーからの質の⾼いフィードバックを得やすい。
■ 品質保証期間の最⼩化： 最初は「寿命が短い」プロセスにフォー
カスして、リリースサイクルを⾼速化。
Skip
Slide 26
Slide 26 text
26
Socrates の初期検証：PoC スコープ (2/2)
● Socrates PoC の具体的スコープ：
○ 対象データソースの限定：
■ ⾼品質データマート「Basic Tables」のみを対象
○ 対象分析プロセスの限定：
■ ユーザーの分析ニーズ特定
■ 関連する Basic Tables からのテーブル選択
■ SQL クエリ⾃動⽣成と BigQuery での実⾏
■ 分析結果の表形式での描画
○ 対象外とした機能：
■ 複雑な対話、グラフ描画、⾼度な統計分析、広範なデータソース
への対応など。
● 成果と学び： 「優秀なアナリストと対話するようにデータ分析が進む」⼤
きな期待感と、データ整備の重要性を伝えた。
Skip
Slide 27
Slide 27 text
27
Socrates の全社リリース
⾒出し (Depth) 分析深度
(Breadth) 分析範囲
● BigQuery 全域
● 権限申請案内
● 可視化機能
● 仮説検証の案内
● ハルシネーションの抑制
● 説明性の⾼い UI
● ツール
○ ガードレールの整備
○ 権限最⼩化
(Credibility) 信頼性
PoC から価値を上げるために必要な精度 / 機能に関する追加検証を実施中
Skip
Slide 28
Slide 28 text
28
AI エージェントが真価を発揮する領域 (1/3)
Socrates の価値曲線:
精度増加に対して、ビジネス価
値が急増するタスクを狙う アナリストの代替 ≒ Max Value
‧⼈間 (Lv. 1) ≒ MVA
‧⼈間 (Lv. 2)
‧Socrates (PoC)
Value
Accuracy
Skip
‧Socrates (リリース)
‧⼈間 (Lv. 3)
Slide 29
Slide 29 text
29
AI エージェントが真価を発揮する領域 (2/3)
● 「⾮決定論的」であることが強みになる＆許容できる
○ AI エージェントは同じ⼊⼒に対して、同じ出⼒や⾏動になるとは限ら
ない。
● ⾮決定論性が「強み」となる領域
○ 探索や仮説⽣成: 答えが決まっていない問いに対し、様々な⾓度から
情報を収集し、多様な可能性を探る。
○ 柔軟な対応: 曖昧な指⽰や状況の変化に対して、⽂脈に応じた臨機応
変な判断や⾏動を⾏う。
○ 創造性やブレインストーミング: 新しいアイデアや洞察を⽣み出す。
Skip
Slide 30
Slide 30 text
30
AI エージェントが真価を発揮する領域 (3/3)
● 「AI エージェントの提供できる価値」 ∝−1「成果物の寿命」？
○ （得意）短命な成果物：作成された直後に価値が最⼤となり、時間経
過と共に急速に価値が低下するもの。
■ 例：⽇次分析レポート、リアルタイムな顧客問い合わせへの⼀次
回答、市場の瞬間的なトレンド把握
○ （苦⼿）⻑寿な成果物：⻑期間にわたり正確性や信頼性が求められる
もの。
■ 例：会計監査報告書、製品の安全基準ドキュメント、学術論⽂*
■ （*学術論⽂は書けることも指摘されているが、⾼度な実装が必要）
● ⇒ データ分析は「寿命の短い成果物」として向いているタスクの⼀つ
○ 検証レポートなどは、寿命が⻑いものに適⽤する場合は⼯夫が必要
Skip
Slide 31
Slide 31 text
31
4. 【道具】Google ADK 登場と
Socrates アーキテクチャ
AI エージェント開発を加速する ADK と、Socrates におけるその活⽤⽅法
Slide 32
Slide 32 text
32
ADK の概要
● Agent Development Kit (ADK): AI エージェント開発を⽀援する Python /
Java フレームワーク
● 主な特徴:
○ Google エコシステムとの⾼い親和性: Google Workspace、Google
Cloud 等とシームレスに連携。
○ マルチエージェントアーキテクチャ設計⽀援: 複数の専⾨エージェン
トの協調を容易に実現。
○ 柔軟なオーケストレーション: LLM 駆動の動的処理と、ワークフロー
ベースの静的処理を組み合わせ可能。
○ 豊富なツールエコシステムと拡張性: LangChain 等の外部ライブラリ
との連携もサポート。
○ 双⽅向ストリーミング:リアルタイムな⾳声‧動画対話をサポート。
Slide 33
Slide 33 text
33
ADK のコア構成要素：エージェント開発の基盤
● エージェント (Agents):
○ 特定のタスクを実⾏するために設計された基本的な「働き⼿」。
● ツール (Tools):
○ エージェントに外部 API との連携、情報検索、コード実⾏、他サービ
ス呼び出しなどの機能を提供。
Slide 34
Slide 34 text
34
ADK のコア構成要素：インタラクションと状態の管理
● セッション管理 (Sessions):
○ 単⼀の会話の⽂脈 (Sessions) を処理。
○ 会話履歴 (Events) や、会話中のエージェントのワーキングメモリ
(State) を含む。
● メモリ (Memory):
○ 複数セッションにわたってユーザーに関する情報を記憶。
○ セッション内の短期的な State とは異なり、⻑期的な⽂脈を提供。
● イベント (Events):
○ セッション中に発⽣する出来事 (ユーザーメッセージ、エージェント
の返信、ツールの使⽤など) を表すコミュニケーションの基本単位。
○ 会話履歴を形成。
● アーティファクト管理 (Artifacts):
○ セッションやユーザーに関連するファイルやバイナリデータ (画像、
PDF など) の保存、読み込み、管理。
Skip
Slide 35
Slide 35 text
35
ADK のコア構成要素：⾼度な機能と実⾏の仕組み
● ランナー (Runner):
○ 実⾏フローを管理するエンジン。
○ Event に基づいてエージェント間のインタラクションを調整し、バッ
クエンドサービスと連携。
● コールバック (Callbacks):
○ エージェントの処理プロセス内の特定のポイントで実⾏されるカスタ
ムコード。
○ チェック、ロギング、動作の変更などが可能。
● コード実⾏ (Code Execution):
○ エージェントがコードを実⾏する能⼒。
Skip
Slide 36
Slide 36 text
36
Socrates は、ADK を基盤としたマルチエージェントシステムとして設計。各エー
ジェントが専門タスクを担当し、協調動作。
Socrates との他の社内ツールとの共存関係
⼈ Socrates
BigQuery 権限管理
エージェント
会話
Python
エージェント
ツール
使⽤
依頼
応答
依頼
応答
応答
Slide 37
Slide 37 text
37
Socrates の ADK 活⽤ポイント
● ADK の主要な柱と Socrates への具体的適⽤:
○ モジュール性:⽬的特化型の複数のサブエージェントで構成。開発‧テ
スト‧改修が容易。
■ 狙い: root エージェントの肥⼤化防⽌ / テスト可能性の維持、各
専⾨チームへのエージェント委任による組織全体のエージェント
運⽤促進
○ 豊富なツールエコシステム: 多数の実装済みツールと 3rd party ツール
との互換レイヤー。
Slide 38
Slide 38 text
38
Socrates のワークフローを ADK で設計する
● 主要な分析の進め⽅をステップごとに分類して、ADK で実装
○ LLM Agents - 柔軟 / テキスト / ⾮決定論的なステップ
■ (1.) ユーザー意図の明確化
■ (3.) 分析計画の⽴案とツール選択
■ (5.) SQL ⽣成 / 検証 / 反復実⾏
■ (7.) 結果の統合 / 解釈 / 報告
○ Tools - 厳格 / 決定論的なステップ
■ (2.) 過去事例 / 関連知識の参照
■ (4.) データソース探索と理解
■ (6.) ⾼度な分析処理の実⾏
Slide 39
Slide 39 text
39
Socrates と ADK Agents / Tools 活⽤
Tools
Agents
外部⼊出⼒、決定論的な
データ処理
⾮構造化データの処理、
思考、⾮決定論的なデー
タ処理
Slide 40
Slide 40 text
40
Socrates と ADK Agents 連携：概要
● Socrates における ADK Agents の重要性: 全体の計画とタスクの分割、⾮
構造化データの処理を⾏う。
● Agents の種類:
○ LLM Agent: ⼤規模⾔語モデル(LLM)を活⽤し、複雑な推論を⾏う。
○ Workflow Agents: 実⾏フローを制御する決定論的なエージェント。
■ Sequential Agent: 順次実⾏
■ Loop Agent: 反復実⾏
■ Parallel Agent: 並列実⾏
○ Custom Agents: 任意のロジックの実装。
Slide 41
Slide 41 text
41
Sequential Agent: LLM の成果物をレビューする
Socrates と ADK Agents 実装例：Self-Reflection (1/2)
このクエリは全ユーザ数を示しており、
利用者の期待と違いそう
アクティブユーザ数を調べるぞ
SELECT COUNT(*)
FROM users
Slide 42
Slide 42 text
42
Loop Agent: 腑に落ちるまで、なぜなぜ分析を繰り返す。
Socrates と ADK Agents 実装例：Self-Reflection (2/2)
売上の主な要因である取引量が減少
なぜメルカリの売り上げが落ちている
のか？
ユーザーの利用頻度が低下している
メルカリが相対的に魅力を失った
競合が差別化機能を提供
競争環境の変化や市場トレンドへの適
応が十分でない
exit_loop
Slide 43
Slide 43 text
43
Parallel Agent: temperature の高い LLM Agents を用いたブレスト大会
Socrates と ADK Agents 実装例：Self-Consistency (1/2)
売上増加の原因を調べるぞ
ホビーカテゴリじゃね？
服カテゴリの季節変動かも？
一昨日のリリースのおかげだよ
大型キャンペーンやってなかった？
大型キャンペーンが有力です。
順に検証してみましょう。
Slide 44
Slide 44 text
44
Parallel Agent を使って別な方法で同じ値を求める
Socrates と ADK Agents 実装例：Self-Consistency (2/2)
フェルミ推定
MAU 2,900 万人
ホビーシェア 28%
ホビー MAU ≒ 810 万人
（2,900 万人 × 28%）
BigQuery から計算
SELECT COUNT(DISTINCT user_id)
FROM transactions
WHERE category = “ホビー”
AND month = “2025-05”
-- 0 万人
ホビーカテゴリの MAU を求めるぞ
乖離している、どこか間違えているか
も？
Slide 45
Slide 45 text
45
ツールを LLM Agent で囲って、より柔軟にツールを使用する
Socrates と ADK Agents 実装パータン：Agentic Tools
なぜメルカリの売り上げが落ちている
のか調べて
売上テーブルは見つからなかったけ
ど、transactions テーブルは見つかっ
たよ。BigQuery の構文ドキュメントを
読んでクエリを書くね。
クエリ結果は ~。
BigQuery
Slide 46
Slide 46 text
46
Socrates と ADK Agents / Tools 活⽤
Tools
Agents
外部⼊出⼒、決定論的な
データ処理
⾮構造化データの処理、
思考、⾮決定論的なデー
タ処理
Slide 47
Slide 47 text
47
Socrates と ADK ツール連携：概要
● AI エージェントにおけるツールの重要性: LLM の知識の限界、計算能⼒の
限界、外部システム連携不可を補う。
● ツールの主な種類:
○ 知識アクセス系ツール（Observing）: LLM に外部知識を提供
■ Socrates: Vertex AI RAG Engine による社内ドキュメント検索、
BigQuery テーブル定義検索
○ 計算‧データ処理系ツール: 数値計算、データ加⼯、コード実⾏
■ Socrates: BigQuery 実⾏、Python コード実⾏
○ 外部連携‧API 呼び出し系ツール（Acting）: 他システムとの連携
■ Socrates: Google ドライブ、他 API 連携
Slide 48
Slide 48 text
48
Socrates と ADK ツール連携：知識アクセス系ツール
● BigQuery との対話（ADK BigQueryToolset）:
○ スキーマ参照 bigquery_tables_get を⾏い、テーブルのスキーマや説
明⽂を取得し、LLM のデータ理解を促進。
○ SQL 実⾏ bigquery_jobs_query。ADK の認証の仕組みを通じて、
ユーザー権限のセキュアなデータアクセス。
● Vertex AI RAG Engine による知識拡張（ADK VertexAiRagRetrieval）:
○ 社内ドキュメントや BigQuery テーブルを⾃然⾔語で検索
■ search_internal_documents(query)
■ search_bigquery_tables_semantic(query)
● メモリ保存‧検索（ADK VertexAiRagMemoryService）:
○ 過去の類似分析セッションの記録‧検索‧再利⽤
■ load_memory(query)
■ add_session_to_memory(session)
Slide 49
Slide 49 text
49
Socrates と ADK ツール連携：計算‧データ処理系ツール
● Python Code Executor (ADK VertexAiCodeExecutor):
○ SQLでは困難な⾼度なデータ処理、統計分析を実⾏。サンドボックス
化された安全な実⾏環境が鍵。
○ 現状、外部パッケージの動的インストールは制限あり。
■ matplotlib でグラフを書くと、⽇本語が⾖腐□になる。
Slide 50
Slide 50 text
50
Socrates と ADK ツール連携：外部連携系ツール他
● Google ドライブ系ツール (ADK DocsToolset, SheetsToolset):
○ よりリッチな⼊出⼒を⾏い、⼈間が介⼊しやすくサポートする。
○ チャットインタフェースの情報密度が低くなりやすいのを補う役割。
● 応答エージェントの変更（ADK transfer_to_agent）
○ マルチエージェントシステムにおいて、より詳細な実装を持つエー
ジェントに応答を委任する
● Python ⾃作ツール（ADK FunctionTool / Agents as a tool）
○ 既存の実装では不⾜する機能や、ガードレール付きの振る舞い、別な
Agent へ⼀時的な⼿伝い依頼を実現する
Slide 51
Slide 51 text
51
Socrates と ADK ツール連携：なぜ⾃作ツールが必要か
● AI エージェントにおけるツールの重要性: LLM の知識、計算能⼒、外部シ
ステム連携を補う。
● Socrates では多くのツールを⾃作。ADK の FunctionTool を活⽤。
○ 理由1: きめ細やかなガードレールの実装:
■ Google Cloud の API を⾃作ツール内でラップ。
■ ツール実⾏前後のチェックに加え、実⾏中の監視や介⼊（例:
BigQuery の過剰なコスト予測時の実⾏中断）など、より厳格な
安全対策を組み込むため。
○ 理由2: 品質改善サイクル:
■ RAG の検索クエリごとのヒット率などきめ細やかなログを取得
し、RAG の品質改善サイクルを回せる。
Slide 52
Slide 52 text
52
AI エージェントのためのツール選定戦略：基本⽅針 (1/2)
● ⽬的からツールを選ぶ
○ エージェントに「何をさせたいか？」を明確にし、その⽬的達成に必
要な機能から逆算する。
○ Socrates 例：データアナリストの業務には、BigQuery アクセス、ス
プレッドシート作成、ドキュメント検索が必要。
● LLM に⼿続きをさせる、知識を披露させない
○ エージェントに必要な知識は、ツール、プロンプトで全て与える。
エージェントの知識を信⽤しない。
Skip
Slide 53
Slide 53 text
53
AI エージェントのためのツール選定戦略：基本⽅針 (2/2)
● 実現可能性 / 既存資産を活⽤できないか考える
○ 社内に利⽤可能なAPI、ライブラリ、データソースがないか確認。
○ Socrates 例：Basic Tables、監査ログ
● プロンプトで対応できないか考える
○ 知識アクセス系のツールの場合は、プロンプトに知識を書いて、ツー
ルとして実装しない⽅針も検討する。
● 信頼性と検証可能性を評価する
○ ツールの安定性、エラーハンドリングの容易さ、品質確認のしやすさ
を考慮。
● セキュリティとガバナンスを評価する
○ 権限は必要⼗分か？機密情報の取り扱いは適切か？
○ 場合によっては、ログやガードレールを含めて⾃作する
Skip
Slide 54
Slide 54 text
54
5. 【学びの軌跡】エコシステム構築の
戦略
Socrates 開発を⽀える技術選択の背景と、AIエージェントを育む環境の重要
性
Slide 55
Slide 55 text
55
技術選定の道のり：LangGraph から ADK へ
● LangGraph からの出発（2025 年 3 ⽉）：「⾃律的に思考‧⾏動する
エージェント」に着⽬し、プロトタイピングを実施。⾼品質データマート
「Basic Tables」が成功の鍵。2 ⽇でデモ版リリース。
● LangGraph から ADK への移⾏に期待したこと
○ Google エコシステムとのネイティブ連携
■ Google Drive や BigQuery / Vertex AI Search などの強⼒なツール
との連携
■ Vertex AI Agent Engine / Google Agentspace による運⽤監視へ
の期待
○ LangGraph の若⼲の⼿間の解消
■ LangGraph Runnable#stream が、応答を配列とスカラ値、それ
ぞれで返すことがあり、ハンドリングが煩雑
Slide 56
Slide 56 text
56
Socrates を育むエコシステム：チーム
● チームの連携：部⾨横断的な開発‧運⽤体制とフィードバックループ
○ 利⽤状況モニタリング、ユーザーヒアリング、エラーログ分析、
Agent as a Judge を通じて、プロンプトやツールの迅速な改善を実施
Skip
Socrates チーム
BI
PdM BI チーム
● 分析ドキュメントの改善
● Agent as a Judge の改善
Data チーム
● メタデータの改善
● データ加⼯の改善
● 権限管理プロセスの改善
フィードバック
改善
品質改善
フィードバック
改善された
データ
改善された
データ
Slide 57
Slide 57 text
57
Socrates を育むエコシステム：データ
● データの⼒：整備されたデータ資産
○ ⾼品質データマート「Basic Tables」がSocratesの分析能⼒の源泉。
● カスタムデータカタログの構築と運⽤
○ BigQuery 監査ログから、テーブル定義、⽣成⽅法、利⽤状況を収集
‧解釈し、⽤途とテーブルの対応表を整備。
○ Vertex AI RAG Engine と連携し、⽤途からテーブル検索を可能に。
○ メリット:
■ データカタログでヒットしないマイナーテーブルをカバー
● 精度は semantic layer などでカバー
■ 評価と改善サイクルの実現: 検索クエリや利⽤状況を分析し、カ
タログの記述や構造を継続的に改善。
Skip
Slide 58
Slide 58 text
58
Socrates を育むエコシステム：ドキュメント
● Machine Readable なドキュメントとナレッジベースの重要性
○ テーブル定義書、ビジネス⽤語集、分析⼿順書、過去の Q&A、施策カ
レンダーなどを RAG ⽤に整備。
○ 課題: ⼈間にとって書きやすく、かつ機械にとっても読みやすいド
キュメントをどう増やすか。
■ 対策: ドキュメント作成のインセンティブ設計、ドキュメントテ
ンプレート、LLM による記述⽀援。
○ 将来構想: Socrates が GitHub リポジトリを DeepWiki のような仕組
みを介して検索し、データ⽣成プロセスを理解する。
● 技術だけでなく、AI エージェントを業務に組み込み、共に成⻑していくた
めの運⽤体制と組織⽂化の醸成が重要
Skip
Slide 59
Slide 59 text
59
6. 【実践知】エンタープライズ AI
エージェント運⽤のリアル
AI エージェントを本番環境で安定稼働させるための課題と、Socrates での具
体的な取り組み
Slide 60
Slide 60 text
60
MLOps 同様、AI エージェントシステムは複雑で「運⽤」が重要かつ困難。
(図は Hidden Technical Debt in Machine Learning Systems より引⽤)
AI エージェント運⽤のリアル：課題と対策 (導⼊)
Slide 61
Slide 61 text
61
AI エージェント運⽤のリアル：課題と対策 (1/4)
● LLM エージェント評価の難しさとアプローチ:
○ 課題: ⾮決定論的で「正しさ」の定義が曖昧。評価すべき側⾯も多岐
（ツール連携、⻑期記憶、対話の流れ）に渡る。ロングセッションの
テストは特に困難。
○ 評価:
■ オフライン評価 (ADK Evaluation 活⽤): 事前定義された評価デー
タセットでツール呼び出しや引数の妥当性確認。
■ オンライン評価 (Human-in-the-Loop): ユーザーからの直接
フィードバック。
■ Agent as a Judge: 別のエージェントが、Socrates の応答品質や
セッション全体の妥当性を評価。特にロングセッションの E2E テ
ストに効果を発揮。
■ ダッシュボード: 重要メトリクスをダッシュボードで可視化。
Slide 62
Slide 62 text
62
AI エージェント運⽤のリアル：課題と対策 (2/4)
● LLM エージェント評価の難しさとアプローチ（続き）:
○ 改善:
■ プロンプト更新: 各種評価をもとに、より⼈間のためになる⼿順
に近づくようにプロンプトを更新。
■ ツール更新: LLM が使いづらいと感じているツールは、ドキュメ
ントやメタデータ、ユースケース例を追加したり、ツール⾃体を
分割する。
○ ⇒ 厳密な決定論的テストは困難。セッションレベルの達成度や品質を
多⾓的に検証し、継続的な評価と改善ループを回すことが重要。
Slide 63
Slide 63 text
63
AI エージェント運⽤のリアル：課題と対策 (3/4)
● レイテンシ:
○ 課題: ⾼速とは⾔えない。Gemini 2.5 Pro への問い合わせと同程度。
⼀問⼀答ではないため、⼈間が idle になる時間が⻑くなりつつある。
○ 対策:
■ ストリーミング応答、⾮同期処理による体感速度向上、ユーザー
への進捗表⽰。
■ ⾼速なモデル（Gemini 2.0 Flash）と選択。
Slide 64
Slide 64 text
64
AI エージェント運⽤のリアル：課題と対策 (4/4)
● コスト最適化:
○ 課題: LLM API コール数、トークン消費量などが想定以上に膨らむリ
スク。
○ 対策: ADK の Gemini 呼び出し回数調整、ワークフロー最適化、
BigQuery コストガードレールの策定。
● セキュリティとガバナンス:
○ 課題: プロンプトインジェクション、機密情報漏洩、意図しないエー
ジェントの⾏動（データ破壊、誤ったデータの蓄積‧拡散）。
○ 対策:ツール実⾏スコープの最⼩化。ある程度の社内リスクは受け⼊れ
つつ、⼊⼒サニタイズ‧出⼒フィルタリングなどのガードレールを実
装。
Slide 65
Slide 65 text
65
ADK の評価：実際に使ってみて良かった点
● 良かった点 (Socrates 開発における実感):
○ 全体としてよくできている
○ Google エコシステムとの強⼒なネイティブ連携: Vertex AI, BigQuery
等とのシームレスな統合が開発を加速。
○ サンプルコードの充実: adk-samples リポジトリが充実。
○ デバッグが簡単: コードが⼩さく、問題箇所の特定や修正が容易。
○ 単純な Evaluation が簡単: 単純なテストは ADK Evaluation で完結。
○ 画像 / ⾳声対応も簡単: ファイルを添付して、Agent に送るだけ。
○ Vertex AI Agent Engine への期待: マネージドな本番環境への移⾏パ
スの安⼼感。スケーリングやインフラ管理の負担軽減を期待。
Slide 66
Slide 66 text
66
ADK の評価：苦労した点‧課題
● 苦労した点‧課題（解決済み）
○ バグ: v0.1.0 から⼀部のエラーハンドリングが弱かった。v1.0.0 の今
は⼤部分が改善。
○ 互換切り: v.0.1.0 から⾒ると、DatabaseSessionService のデータス
キーマ変更、async 関数化などの互換性がない変更があった。
● 苦労している点（未解決）
○ Session Service 周りの課題: json.dumps できないオブジェクトが含
まれる Event が応答されると、Database や Agent Engine Sessions
に保存できず、エラーになる。
Slide 67
Slide 67 text
67
ADK の評価：LangGraph の強み
● 既存の応⽤的なオープンソースソフトウェアの参照: Deep Research など
丸ごとコピーして動かしたい時に便利。ADK の実装はまだ少ない。
● 複雑なワークフローの実装: LangGraph は複雑なグラフ構造をワークフ
ローとして定義できる。ADK は「順次」と「反復」の⼿続きのみ。
Slide 68
Slide 68 text
68
7. 【未来展望】ADK の進化への期待
Slide 69
Slide 69 text
69
ADK へのフィードバックと期待
● SessionService と MemoryService の機能拡充と外部連携強化: 多様な永
続化ストア対応（Cloud Spanner, Firestore 等）、複雑なデータ型シリア
ライズ標準化、Secret Manager 連携、⻑期記憶ソリューション。
● ツール呼び出しの堅牢性と柔軟なエラーハンドリング機構: リトライポリ
シー、フォールバックの実装⽀援。ツール実⾏時の権限管理‧監査ログ標
準化。（+ Gemini の malformed_function_call 対策）
● テスト‧評価フレームワークの充実 (ADK Evaluation のさらなる進化):
エージェント振る舞い‧応答品質の体系的 / 効率的な評価フレームワー
ク、マルチエージェント協調 / 全体タスク達成度評価⼿法。
Slide 70
Slide 70 text
70
エコシステムへの展望
● Google Agentspace / Vertex AI Agent Garden への期待
○ エージェントシェアリング: 社内外の専⾨エージェントを共有
● Vertex AI Agent Engine への期待
○ 多様な Artifact Service のサポート
○ MemoryService のサポート
○ 利⽤者 Authorization のサポート
○ SessionService への評価フレームワークの組み込み
Slide 71
Slide 71 text
71
8. 【まとめ】成功の鍵と教訓
本⽇の発表のまとめと、AIエージェント開発とADK活⽤に向けたメッセージ
Slide 72
Slide 72 text
72
ADK 活⽤の勘所と AI エージェント開発成功への教訓
● AI エージェントは LLM をコアとする複雑な「システム」
● AI エージェントは「作って終わり」ではなく、「育て続ける」もの
○ 「構造化 / ⾮構造化データ」などの周辺資産も対象
○ 「組織」や「プロセス」の変⾰も伴う
● AI エージェントのはじめ⽅
○ ユーザー提供価値の確認
○ スモールスタートと反復的改善
○ エージェントの能⼒拡張のためのツール設計
○ 運⽤の覚悟
Slide 73
Slide 73 text
73
2025-06-10 現在、AI エージェントを開発すべきか？
以下の条件を全て満たすなら Yes
● PoC 時点の LLMs の能⼒でも、⼗分に⾼い価値を提供できる
● 代替⼿段が現実的でない（ソフトウェア化、⼈⼒化、省⼒化、廃⽌）
● 保守し続ける覚悟がある
● 時が来たら捨てる覚悟がある
Slide 74
Slide 74 text
74
参考資料‧リソース
● Agent Development Kit
● GitHub - google/adk-python
● GitHub - google/adk-samples
● Speaker Deck - 1⽇50万件貯まるクエリのログを活かして、SQLの⽣成に
挑戦している話
● Hidden Technical Debt in Machine Learning Systems