---
title: LLMをコアに持つプロダクトのデータ活用とエージェント設計
tags:  #dena ai talks  
author: [DeNA_Tech](https://convert.docswell.com/user/DeNA_Tech)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4JQV35N97P.jpg?width=480
description: DeNA × AI Talks #4 2025-12-18 Tomoki Yoshida『LLMをコアに持つプロダクトのデータ活用とエージェント設計』  Web版: https://birdwatcheryt.github.io/ai-talks4/ LLM勉強会: https://engineering.dena.com/blog/2025/12/llm-study-1201/  イベントURL：https://dena.connpass.com/event/377040/
published: December 19, 25
canonical: https://convert.docswell.com/s/DeNA_Tech/5LVMLD-2025-12-19-190215
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4JQV35N97P.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/K74M193RJ1.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/LJ18GK1VEG.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/GJWZKD83J2.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/4EZ1ZG8G73.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/Y76LZYPQJV.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/G751WGK2E4.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/9J21QYW17R.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/DEYZWGL47M.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/VJN39G46J8.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/YE992WQRE3.jpg)

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計
DSPyでプロンプト自動最適化
文章から趣味を抽出するtoy-problemで試してみた
モデル: gemma3、初期プロンプト: &quot;趣味は？&quot; （あえてテキトーなものに）
データセット (train: 56件, validation: 14件, test: 28件):
{&quot;sentence&quot;: &quot;映画鑑賞が趣味で、毎週1本は必ず観ています&quot;, &quot;hobby&quot;: &quot;映画鑑賞&quot;},
{&quot;sentence&quot;: &quot;休日に散歩して鳥の写真を撮ります&quot;, &quot;hobby&quot;: &quot;バードウォッチング&quot;}
【結果】 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
{&quot;sentence&quot;: &quot;週末は公園でスケッチをして過ごします&quot;, &quot;hobby&quot;: &quot;スケッチ&quot;},
{&quot;sentence&quot;: &quot;陶芸教室に通って、自分で器を作っています&quot;, &quot;hobby&quot;: &quot;陶芸&quot;},
{&quot;sentence&quot;: &quot;旅行が好きで、日本全国を巡っています&quot;, &quot;hobby&quot;: &quot;旅行&quot;}
8 / 27


# Page. 12

![Page Image](https://bcdn.docswell.com/page/GE895NGG7D.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/LELWYPGXJR.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/4JM9N4Q3EW.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/PJRGDW8RE9.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/PEXX1P8YEX.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/3EKW2DK4ED.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/L7314RZDJ5.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/87DXQYR2EG.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/VJPPL6WLJ8.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/2EV2Q386EQ.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/57GRW352EL.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/4EQV35Z9JP.jpg)

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 &amp; Action
⽣成されたテキスト
(思考 + Actionコマンド)
実⾏？
Yes
ツール実⾏
Action
出⼒
:
Observation
実⾏結果
(Observation)
No (Final Answer)
回答出⼒
ツール群: Web検索, コード実行, 画像生成, ファイル検索, コンテキスト取得
→ ツール群にコンテキスト取得が入るとAgentic RAGになる
Tomoki Yoshida (birder) ️- DeNA
18 / 27


# Page. 24

![Page Image](https://bcdn.docswell.com/page/KJ4M19DRE1.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/LE18GKZV7G.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/GEWZKD93E2.jpg)

AI Talks #4 - LLMをコアに持つプロダクトのデータ活用とエージェント設計
LangChainのAgentの動きを見てみよう
@tool
def func_add(a: int, b: int) -&gt; int:
# 自作関数
&quot;&quot;&quot;足し算をする&quot;&quot;&quot;
# Agentは、docstringを読んで判定してくれる
print(&quot;called func_add&quot;)
return a + b
@tool
def func_mul(a: int, b: int) -&gt; int:
&quot;&quot;&quot;掛け算をする&quot;&quot;&quot;
print(&quot;called func_mul&quot;)
return a * b
agent = create_agent( # 関数を渡す
model=ChatVertexAI(model=&quot;gemini-2.5-flash-lite&quot;), tools = [func_add, func_mul]
)
result = agent.invoke(
{&quot;messages&quot;: [(&quot;human&quot;, &quot;3と4を足した値に1+3を足した値同士を掛け算するとどうなる？&quot;)]}
)
たとえばこんな例だと中身はどうなるでしょうか？
Tomoki Yoshida (birder) ️- DeNA
21 / 27


# Page. 27

![Page Image](https://bcdn.docswell.com/page/47Z1ZG9GJ3.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/YJ6LZYKQEV.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/GJ51WGP274.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/LE314R3175.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/8EDXQY4KJG.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/V7PPL6M378.jpg)

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


# Page. 33

![Page Image](https://bcdn.docswell.com/page/2JV2Q39NJQ.jpg)

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


