LLMをコアに持つプロダクトのデータ活用とエージェント設計

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 LLMをコアに持つプロダクトの データ活用とエージェント設計 Tomoki Yoshida (birder) DeNA AI技術開発部AIイノベーショングループ 2025-12-18 Tomoki Yoshida (birder) ️- DeNA

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 自己紹介 吉田 知貴（birder） Tomoki Yoshida (birder) ️- DeNA 学生時代 機械学習凸最適化の高速化 (KDD2018, KDD2019) 2018年 DeNAサマーインターン 社会人 2020年 DeNA新卒入社 社外案件（組み合わせ最適化） ライブ配信Pococha（CS審査効率化、レコメンド） 新規AIプロダクト開発 Qiita: @birdwatcher X: @birdwatcherYT 1 / 27

• https://www.kdd.org/kdd2018/accepted-papers/view/safe-triplet-screening-for-distance-metric-learning
• https://www.kdd.org/kdd2019/accepted-papers/view/learning-interpretable-metric-between-graphs-convex-formulation-and-computa
• https://www.docswell.com/s/DeNA_Tech/K4V978-aiday-specific-1500
• https://qiita.com/birdwatcher
• https://x.com/birdwatcheryt

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 社内の3時間の勉強会から厳選し更に踏み込んだ内容を話します 重複あり ※ Tomoki Yoshida (birder) ️- DeNA

• https://engineering.dena.com/blog/2025/12/llm-study-1201/

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 フィードバックループを持ち成長するプロダクト 作りたいですよね？ Tomoki Yoshida (birder) ️- DeNA

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 LLM時代のデータ活用 プロダクト全体の最適化 ファインチューニング（FT） 強化学習（RL） プロンプト最適化 ユーザー個人への最適化（パーソナライズ） コンテキストエンジニアリング RAG ユーザーごとにモデル保持するのは非現実的なので、基本このパターンになるはず Tomoki Yoshida (birder) ️- DeNA 2 / 27

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 モデル学習の種類とイメージ STEP: 事前学習 → ファインチューニング → 強化学習 手法 例え 学習のさせ方 義務 事前学習 教育 言葉、計算、一般常識を学ぶ。まだ料理はできない ファインチ 料理 「このレシピ通りに作りなさい」と教わる ューニング 学校 → 基礎的な調理スキルと知識を身につける 実地 客に出した料理に対して「美味しい」 「塩辛い」と評価される 強化学習 研修 → 客が喜ぶ味付けや、好まれる接客を身につける LLMを使う多くの企業は、プロンプトチューニングとファインチューニングだけやる Tomoki Yoshida (birder) ️- DeNA 3 / 27

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 ファインチューニングと強化学習の比較 比較項目 ファインチューニング 強化学習 : 特定の形式や知識を教 人間との調和: 安全性、有用性、ニュアンスを 主な目的 指示従順性の獲得 え込む 調整する 回答の「比較」や「採点」 データ形式 「入力」と「正解」のペア 例： Q:首都は? A:東京 例： 回答A > 回答B 、 GOOD/BAD など 学習の仕組 次単語の予測 (Token Level) 報酬スコアの最大化 (Sentence Level) み 正解データと一言一句合わせようとする 文章全体としての良し悪しを評価 ・新しい知識の注入 ・嘘（ハルシネーション）の抑制 得意なこと ・JSONなど特殊形式の出力 ・有害な回答の回避 ・口調（キャラ付け）の固定 ・「もっと丁寧に」など曖昧な指示への対応 プロンプトチューニングで限界ならファインチューニングが候補に入る。強化学習まで必要なケースは稀。 Tomoki Yoshida (birder) ️- DeNA 4 / 27

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 ファインチューニング 事前学習済みモデルを特定タスクに微調整する Full Fine-Tuning ⼊⼒ 層1 (更新) 層2 (更新) 層3 (更新) 出⼒層 (更新) 出⼒ の PEFT LoRA 層1 (固定) ⼊⼒ 層2 (固定) ＋ アダプタA 層3 (固定) ＋ アダプタB ＋ 出⼒層: 固定 出⼒ アダプタC 低ランクの小さな重みを付け加えるPEFT（Parameter-Efficient Fine Tuning）のLoRA （Low-Rank Adaptation）が主流 Tomoki Yoshida (birder) ️- DeNA 5 / 27

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 強化学習（スキップするかも） 評価データの蓄積 評価済みデータ 提供モデル 提供しているLLM 好みを学習 複製・固定（Reference） 回答を出⼒ ⼈間（評価者） ⽅法1: RLHF Step1: 報酬モデルの学習 報酬モデル（審査員） 点数（報酬）を付与 ⽅法2: DPO 好みのペア（A > B） 初期化 強化学習（PPO） PPO（更新処理） 回答を⽣成 参照モデル 基準となる確率 学習対象（Policy） Step2: A>B とランク付け 評価済みデータ 強化学習でもLoRAを使う Tomoki Yoshida (birder) ️- DeNA ⾼得点を⽬指してパラメー タ更新 学習対象モデル 損失計算 DPO 好みの回答確率を上げ 嫌いな回答確率を下げる 現在の確率 学習対象モデル RLHF (Reinforcement Learning from Human Feedback) / DPO (Direct Preference Optimization) 6 / 27

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 プロンプト自動最適化 入出力データセットを与えるとプロンプトを調整してくれるもの: DSPy Vertex AI プロンプト オプティマイザー やる意義 ユーザー提供して集まったデータをアノテーションし、更に良いプロダクトへ プロンプトチューニング地獄からの解放 モデルリプレース時のチューニングの自動化 最近Gemini-2.5系の廃止計画が発表されたり、GPT-4o APIの廃止計画が発表されたり... → LLMをプロダクトに組み込んでいると、一斉にモデルリプレース作業に追われる Tomoki Yoshida (birder) ️- DeNA 7 / 27

• https://dspy.ai/
• https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/prompts/prompt-optimizer?hl=ja
• https://docs.cloud.google.com/vertex-ai/generative-ai/docs/migrate?hl=ja
• https://platform.openai.com/docs/deprecations#2025-11-18-chatgpt-4o-latest-snapshot

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計

DSPyでプロンプト自動最適化

文章から趣味を抽出するtoy-problemで試してみた
モデル: gemma3、初期プロンプト: "趣味は？" （あえてテキトーなものに）
データセット (train: 56件, validation: 14件, test: 28件):
{"sentence": "映画鑑賞が趣味で、毎週1本は必ず観ています", "hobby": "映画鑑賞"},
{"sentence": "休日に散歩して鳥の写真を撮ります", "hobby": "バードウォッチング"}

【結果】 accuracy: 78.6% ← 手動チューニングだとなかなかここまでいけない
optimized prompt:
selected few-shot examples:
Given a sentence describing a person’s activity,
identify and state the hobby being practiced.
Output only the hobby.

Tomoki Yoshida (birder) ️- DeNA

{"sentence": "週末は公園でスケッチをして過ごします", "hobby": "スケッチ"},
{"sentence": "陶芸教室に通って、自分で器を作っています", "hobby": "陶芸"},
{"sentence": "旅行が好きで、日本全国を巡っています", "hobby": "旅行"}

8 / 27

• https://github.com/birdwatcherYT/dspy-test/

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 プロンプト自動最適化の課題 API呼び出し回数が多いのでRateLimitに引っかかりやすい Vertex AI プロンプト オプティマイザーはResource Exhaustedで失敗 プロビジョンド スループットの購入が必要かも DSPyはローカルモデルGemma3で乗り切った 評価指標を定めるのが難しい 先程のtoy-problemのように完全一致や明確に答えがあるものは楽 でも、実際に最適化したい需要って「日本語の自然さ」や「カジュアルさ」「適切 にアドバイスできているか」など言語化しにくい曖昧なケースも多い 評価をLLM as a Judgeにするにしても、そもそも評価モデルを作るのが難しい 推論モデルを作るために評価モデルをチューニングするという鶏卵感... Tomoki Yoshida (birder) ️- DeNA 9 / 27

• https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/prompts/prompt-optimizer?hl=ja
• https://docs.cloud.google.com/vertex-ai/generative-ai/docs/provisioned-throughput/overview?hl=ja

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 参考: Geminiのファインチューニングは簡単にできる jsonl形式で データセット作って 投げるだけ 最適化は モデル側の損失関数 で決まっているため 利用者は決めない （トークン単位の 最適化なので） さらに、強化学習も簡単にできそう（Open AIも同様） Tomoki Yoshida (birder) ️- DeNA 10 / 27

• https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini-use-supervised-tuning?hl=ja
• https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini-preference-tuning?hl=ja
• https://platform.openai.com/docs/guides/direct-preference-optimization

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 本当に重要なのはここからです！！ パーソナライズへ Tomoki Yoshida (birder) ️- DeNA

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 コンテキストエンジニアリングの必要性 LLMの限界 コンテキストウィンドウ（入力上限）がある（小説8冊分とか入る） 詰め込みすぎると指示を無視したり、性能劣化する ↓ LLMに与える情報を管理してあげる必要がある コンテキストエンジニアリング 無数に増えていく（ユーザーの）情報を どう保存するか（そのまま？ラベル付け？集計？圧縮？） どう検索するか（最新N件？関連度？重要度？） Tomoki Yoshida (birder) ️- DeNA 11 / 27

• https://ai.google.dev/gemini-api/docs/long-context?hl=ja

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 プロダクト作りで気にするところ データ取得時 ⼊⼒ LLM 検索クエリ 加⼯処理 USER 検索結果 データ保存時 データ発⽣ 応答 DB データ取得時の検索クエリ / データ保存時の加工処理が案件ごとの設計ポイント！ このあとコンテキストエンジニアリングの一種とみなせるRAGの説明をしますが、一般的なRAGは既にいろ んなクラウドサービスが実装しています。 Tomoki Yoshida (birder) ️- DeNA 12 / 27

• https://docs.cloud.google.com/vertex-ai/generative-ai/docs/rag-engine/rag-overview?hl=ja

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 RAG（Retrieval-Augmented Generation） 外部データを検索して応答する 典型的なRAGシステムの全体像： 最終回答 （根拠付き） 👤 ユーザー 1. クエリ拡張 類義語・表現の多様化 ⼊⼒（クエリ） 拡張された 複数のクエリ 検索・⽣成（RAG） 4. 全⽂検索 + ベクトル検索 （Hybrid Search） キーワードと意味の併⽤ 検索結果 （粗い絞り込み） 検索実⾏ & 候補ドキュメント取得 チャンキング 意味単位での分割 ベクトル化 & インデックス登録 2. 3. リランキング 関連度による再順位付け 精選された ⾼関連度ドキュメント 応答 + グラウンディング 出典に基づく回答⽣成 保存（前処理） 📄 元ドキュメント 等 (PDF/Wiki/Word ) テキスト化 ⾮構造データの読み取り 🗄 データベース （ベクトルストアなど） RAGはコンテキストエンジニアリングの一種と言える LLMは応答インターフェースでしかない（いかにうまく情報取ってこれるか勝負） Tomoki Yoshida (birder) ️- DeNA 13 / 27

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 RAGの構成要素: 1. クエリ拡張 ユーザーの曖昧な入力を、LLM等を使って具体的かつ検索しやすい形に変換する 簡単な文脈補完 言い換えや解答予測 USER: 社内の経費精算の締め切りはいつ？ AI: 月末です USER: それを過ぎたらどうなる？ を検索しても 関連ドキュメントを探せない それを過ぎたらどうなる？ 経費精算の締め切りを過ぎた場合のペナル ティや対応 を検索する Tomoki Yoshida (birder) ️- DeNA USER: PCが重いときの対処法は？ 、 システム パフォー マンス 低下 原因 、 メモリ不足 解消方 法 、 CPU使用率 高い などを並列で検 索して結果を統合する PC 動作 遅い 対処 14 / 27

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 RAGの構成要素: 2. ハイブリッド検索 DBの情報すべてLLMに渡すのは無理なので、LLMに渡す情報の絞り込み 全文検索: 文字列完全一致で検索（インデックスで高速化） ベクトル検索: Embedding: 文字列からベクトル空間へ ベクトル検索: 大量のレコードから近い表 現を高速に検索できる（近似最近傍探索） O モデル性能はembedding leaderboardで検索！ Tomoki Yoshida (birder) ️- DeNA データベース string embedding アニメ [0.15, … , 0.16] ... ... 任意の⽂字列 [0.01, … , 0.81] … “アニメ” “マンガ” [0.13, … , 0.21] [0.15, … , 0.16] “マンガ” string 類似度 漫画 0.95 アニメ 0.82 [0.13, … , 0.21] PostgreSQLのpgvector拡張やFirestore、Vertex AIなど 15 / 27

• https://huggingface.co/spaces/mteb/leaderboard
• https://github.com/pgvector/pgvector
• https://firebase.google.com/docs/firestore/vector-search?hl=ja
• https://docs.cloud.google.com/vertex-ai/docs/vector-search/overview?hl=ja

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 RAGの構成要素: 3. リランキング 4. グラウンディング 3. リランキング: さらなる絞り込み！ 検索でヒットした多数の候補から、本当に関連する文書を高精度なモデルで並び 替え、上位のものだけを抽出 高精度なモデル クロスエンコーダー（入力: 質問と文書のペア, 出力: 関係度スコア） semantic-ranker, Qwen3-Reranker, hotchpotch/japanese-reranker など 多段階にするならLLMが使われることも 4. 応答 + グラウンディング: 抽出した情報をコンテキストに入れて、ユーザーの質問に応答 グラウンディング: 情報ソースとの紐づけ（回答の根拠） Tomoki Yoshida (birder) ️- DeNA 16 / 27

• https://cloud.google.com/blog/ja/products/ai-machine-learning/launching-our-new-state-of-the-art-vertex-ai-ranking-api
• https://huggingface.co/Qwen/Qwen3-Reranker-8B
• https://secon.dev/entry/2024/04/02/080000-japanese-reranker-tech-report/

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 RAGの前処理: ドキュメント保存時の前処理 必要な情報をうまく検索するためには、保存の仕方も重要になる チャンキング: ドキュメントをチャンクに分割してDBに格納 切り方: ファイル単位、文書構造単位（章とか）、文字数、意味のまとまり 切られて文脈が途切れる問題への対策例: チャンクを階層的にして親チャンクをLLMに渡す チャンクに「全体から見たそのチャンクの要約や文脈」を含める Agenticに足りない情報を取りに行く あらかじめ想定質問を生成しておくパターンもある（工夫はいろいろあるようだ） Tomoki Yoshida (birder) ️- DeNA 17 / 27

• https://github.com/NirDiamant/RAG_Techniques

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 エージェントについて知ろう 世の中のすごいプロダクトの中身を推測できるようになる 実はさっきのRAGはNotebookLMの中身の推測でした （OSSでNotebookLMを目指しているレポジトリは先程のような構成） ここからの話は非エンジニアの方は「へーそんなのもあるんだ」くらいで聞いてください。 Tomoki Yoshida (birder) ️- DeNA

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 ReAct（Reasoning + Acting） Agent エージェントの基礎 ReAct: Thought (思考)→Action (行動)→Observation (観察) コンテキスト（現在の記憶） ユーザー の⼊⼒ ReAct 履歴に追加 Prompt / Context ----------------------------1. System Instruction 2. User Input 3. History 追加 思考・⾏動・観測の軌跡) ( ループによる更新 履歴に追加 ⼊⼒ LLM 推論エンジン) ( ⽣成 : Thought & Action ⽣成されたテキスト (思考 + Actionコマンド) 実⾏？ Yes ツール実⾏ Action 出⼒ : Observation 実⾏結果 (Observation) No (Final Answer) 回答出⼒ ツール群: Web検索, コード実行, 画像生成, ファイル検索, コンテキスト取得 → ツール群にコンテキスト取得が入るとAgentic RAGになる Tomoki Yoshida (birder) ️- DeNA 18 / 27

• https://arxiv.org/abs/2210.03629

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 Reflexion（内省） Reflexion: 結果の振り返りを行い次の試行に活かす 成功 / 最終回答 Reflexion ループ 成功/合格 Actor : 実⾏者 推論・コード⽣成 ユーザーからの タスク⼊⼒ Evaluator : 評価者 正誤判定・テスト実⾏ ⽣成された回答/コード Memory ⽂脈 + 過去の反省 記憶に追加 失敗/エラー Self-Reflection : 反省者 エラー分析・改善案作成 ⾔語化された 反省点 先程のReActと組み合わせることもできる Tomoki Yoshida (birder) ️- DeNA 19 / 27

• https://arxiv.org/abs/2303.11366

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 Adaptive Planning AdaPlanner: プランを立てて結果に基づきプランを修正する 適応的プランニング (Adaptive Planning) 計画通り進⾏ ユーザー ⼊⼒ 初期計画の作成 (Initial Plan) 現状確認 予期せぬ結果/失敗 ⾏動実⾏ (Action) 計画の修正・更新 (Plan Refinement) No ( 観察 (Observation) タスク完了？ Yes 最終回答 次のステップへ) CursorやClaude Codeもプラン立てて修正しながら動きますよね 世の中の賢いエージェントはこうした工夫を取り入れて設計されている Tomoki Yoshida (birder) ️- DeNA 20 / 27

• https://arxiv.org/pdf/2305.16653

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計

LangChainのAgentの動きを見てみよう
@tool
def func_add(a: int, b: int) -> int:
# 自作関数
"""足し算をする"""
# Agentは、docstringを読んで判定してくれる
print("called func_add")
return a + b
@tool
def func_mul(a: int, b: int) -> int:
"""掛け算をする"""
print("called func_mul")
return a * b
agent = create_agent( # 関数を渡す
model=ChatVertexAI(model="gemini-2.5-flash-lite"), tools = [func_add, func_mul]
)
result = agent.invoke(
{"messages": [("human", "3と4を足した値に1+3を足した値同士を掛け算するとどうなる？")]}
)

たとえばこんな例だと中身はどうなるでしょうか？

Tomoki Yoshida (birder) ️- DeNA

21 / 27

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 LangSmithでAgentをトレース Tomoki Yoshida (birder) ️- DeNA 内部でループが回り、 3回LLMが呼ばれている 事がわかる 参考：ADKのLlmAgent も同様に内部でReActの ような構造を持っていた 22 / 27

• https://github.com/google/adk-python

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 LLM設計パターン ワークフローかエージェントか エージェント賢そうだし全部エージェントに全部任せればいいのか？ Tomoki Yoshida (birder) ️- DeNA

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 Deep Researchの設計（ワークフロー型） 自然に考えるとこう書けるでしょう： 開始 調査計画の作成 (調査トピック・⽅針策定) ユーザー確認 計画は承認されたか？ 修正依頼 承認 ユーザーフィードバックに 基づき計画修正 追加クエリ⽣成 検索クエリ⽣成 Web 検索実⾏ 検索結果の分析・評価 情報は⼗分か？ 不⼗分 かつ ループ回数 < 上限 ⼗分 または ループ回数 >= 上限 最終回答⽣成 終了 オープンソースでもいくつか出ています gemini-fullstack-langgraph-quickstart open_deep_research Tomoki Yoshida (birder) ️- DeNA 23 / 27

• https://github.com/google-gemini/gemini-fullstack-langgraph-quickstart
• https://github.com/langchain-ai/open_deep_research

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 Deep Researchの設計（エージェント版） 開始 エージェント LLM 観察 実⾏結果) ( ツール群 ユーザーに質問 Web （思考・推論） システムプロンプト ─────────── あなたはリサーチャーです 1. 調査計画を⽴てる 2. ユーザーに計画を確認 3. Web検索で情報収集 4. 不⼗分なら追加検索 5. レポートを作成 のステップで実⾏せよ アクション選択 終了 検索 エージェントがライブラリで提供される場合、 実装箇所は「ツール群」と「システムプロンプト」だけで楽そう Tomoki Yoshida (birder) ️- DeNA 完了判断 24 / 27

• https://docs.langchain.com/oss/javascript/langchain/agents

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 ワークフロー型 vs エージェント 観点 ワークフロー型 エージェント 動作原理 事前定義されたフローに従う 自律的な推論と行動のループ 応答速度 速い（LLM呼び出し回数が予測可能） 遅い（より多くのLLM呼び出し） 柔軟性 低〜中（想定外のタスクに弱い） 高（新しいタスクにも適応） 制御性 高（動作が予測しやすい） 低〜中（予期しない動作の可能性） 実装工数 中〜高（フロー設計とコーディング） 低〜中（ツールとプロンプト設計のみ） プロダクト実装で特定のタスクを実装する場合、 応答速度や制御性の観点からワークフロー型になるケースが多い気がする Tomoki Yoshida (birder) ️- DeNA 25 / 27

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 マルチエージェント設計パターン Supervisor 階層型 型 Top フラット型（P2P） Supervisor B C Mid 1 Mid 2 A D Agent A Agent B Agent C A1 Supervisor：タスク分解、計画 Worker：検索担当、テスト担 当、修正担当など（as Tools） Tomoki Yoshida (birder) ️- DeNA A2 B1 B2 より複雑なタスクで使われる （大規模タスクの分解） 本質はSupervisor型と同じ （多段にしただけ） 上下関係がない 例: ディベート・ブレスト（複 数視点で議論・合意形成） 26 / 27

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計 まとめ モデル最適化: ファインチューニング・強化学習でプロダクト全体を改善 パーソナライズ: コンテキストエンジニアリングでユーザーごとに最適化 エージェント: ツールを使って複雑なタスクを自律的に解決するが速度は遅め 今日の資料 LLM勉強会の資料 Tomoki Yoshida (birder) ️- DeNA 27 / 27

• https://birdwatcheryt.github.io/ai-talks4/
• https://engineering.dena.com/blog/2025/12/llm-study-1201/