1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Stanford論文"Generative Agents"を実装→使えた3つ・捨てた4つ

1
Posted at
  • Stanford の Generative Agents 論文(2023)を「消費者意思決定シミュレーション」に応用して実プロダクトを作った
  • 論文の7要素のうち3つは精度向上に直結4つはオーバーエンジニアリングだった
  • 「反省(Reflection)」と「計画(Planning)」はゲームキャラ向けであり、購買意思決定シミュレーションには不要だった
  • 最も効いたのは論文には薄い「信念体系(Belief System)」の設計だった

はじめに

2023年、Stanfordから衝撃的な論文が出ました。

"Generative Agents: Interactive Simulacra of Human Behavior"(Park et al., 2023)

LLMに記憶・反省・計画を持たせることで「人間のような行動をするエージェント」を作る研究です。The Simsのような仮想タウンで25人のエージェントが自律的に生活し、パーティを企画したり噂を広めたりする。

これを読んだとき直感しました。

「ペルソナに人格を持たせれば、市場調査を自動化できるのでは?」

そこで論文をプロダクトに実装しました。結果:1,001社のB2Cサービスを評価し、実際の市場成功との相関r=0.637が得られました。

ただし論文の全要素を実装したわけではありません。実際には「使えた部分」と「プロダクトには合わなかった部分」が明確に分かれました。本記事はその記録です。

サービス: https://persona.microforge.works


Generative Agentsの論文を3分で理解する

論文が提案するエージェントは以下の要素で構成されます。

1. Memory Stream   — 全経験をタイムスタンプ付きで記録するデータベース
2. Retrieval       — 関連する記憶を状況に応じて引き出す仕組み
3. Reflection      — 記憶から高次の洞察を生成する「内省」プロセス
4. Planning        — 目標から行動計画を立てるプロセス
5. Action          — 計画に基づいて実際に行動する
6. Reaction        — 予期しない出来事への即時対応
7. Dialogue        — エージェント同士の会話と相互影響

論文での活用シーン:「Isabella(キャラクター)は毎朝コーヒーを淹れ、昼に友人と会い、夜はパーティの準備をする」

これをそのまま「市場調査ペルソナ」に移植しようとしたのが最初の失敗でした。


実装してみた全体像

プロダクトのシステム構成:

Frontend: Next.js 16 (App Router)
Backend:  FastAPI on GCP Cloud Run
LLM:      Gemini 2.5 Flash
DB:       Supabase (PostgreSQL)

ペルソナは100人。年齢20〜65歳、全国15都市、年収72万〜1,200万円の分布。

1回のシミュレーションで起きること:

  1. ユーザーがビジネスアイデアを入力
  2. 100人のペルソナが並列でLLMを呼び出し(asyncio.Semaphore(15))
  3. 各ペルソナが interest_level(High/Medium/Low)と decision(Yes/No)を返す
  4. 集計・改善提案を生成して返す

使えた要素 ①:Memory(静的記憶)

論文のMemory Streamは「動的に蓄積される記憶」ですが、私は静的な過去経験として実装しました。

{
  "persona_id": "P042",
  "basic_info": { "name": "田中 誠", "age": 38 },
  "memory": [
    "フリマアプリで偽ブランド品をつかまされてから、個人間取引は一切しない",
    "2019年にジムの年会費を無駄にした経験から、月額サービスの継続には慎重",
    "スマートフォン決済は初期の頃から積極的に使ってきた。失敗した記憶はない"
  ]
}

なぜ動的にしなかったのか

論文の動的Memory Streamは1回のシミュレーション中にエージェントが「新しい経験をして記憶を更新する」ためのものです。しかし購買意思決定シミュレーションは1問1答で完結します。評価中に新しい記憶を形成する必要がない。

静的記憶で十分であり、動的化はコストと複雑さを増やすだけでした。

効果の検証

memory ありとなしで同じビジネスアイデアを評価した比較:

条件 興味率の分散 人格の一貫性(定性)
memory なし 低い(全員似た回答) 低い
memory あり 高い(個人差が出る) 高い

記憶を持たせると「同じサービスでも人によって評価が割れる」ようになりました。これはリアルな市場を模倣するうえで重要です。


使えた要素 ②:Belief System(信念体系)

論文には明示的に登場しませんが、Generative Agentsの「価値観」概念を発展させたBelief Systemが最も効果的でした。

{
  "beliefs": [
    "新しいテクノロジーは早く試した方が得だと思っている",
    "価格より時間節約を優先する。多少高くても便利な方を選ぶ",
    "知らないブランドには懐疑的。口コミや実績を必ず確認する",
    "環境への影響を意識して購買する。エシカル消費に関心がある"
  ]
}

これを「信念が購買行動に与える影響」として明示的にプロンプトに含めることで、単なる属性(年齢・性別)とは異なる**"なぜその判断をするか"**の再現が可能になりました。

論文との差分

Generative Agentsは「行動の動機」をメモリから間接的に導出しますが、本実装では信念を直接宣言的に記述します。これは精度よりも再現性と説明可能性を優先した設計です。

「なぜこのペルソナがNoと言ったのか」をデバッグするとき、信念が明示されていると原因特定が容易です。


使えた要素 ③:Decision Logic(判断ロジックの優先順位)

論文の Planning が「行動の順序」を定義するように、本実装では判断基準の優先順位を明示しました。

{
  "decision_logic": [
    "1. まず価格が予算内かを確認する(月3,000円以上は原則除外)",
    "2. 次に実績・口コミを確認。ユーザー数や評価がなければ見送る",
    "3. 既存サービスとの差別化が明確でなければ乗り換えない",
    "4. 家族や友人が使っていれば+1ポイントとして加点する"
  ]
}

これにより「価格に敏感なペルソナ」と「価格より利便性を重視するペルソナ」が同じサービスを異なる理由で評価するようになります。

プロンプトへの組み込み:

PROMPT = """
[判断プロセス]
以下の優先順位で判断してください:
{decision_logic}

この判断プロセスに従い、以下のビジネスアイデアを評価してください。
{idea}
"""

効果:Decision Logicを追加する前後で、「理由の説得力」が定性的に大きく改善。単に「興味あり」「興味なし」ではなく「〇〇だから興味あり、ただし〇〇が懸念」という構造化された理由が出力されるようになりました。


捨てた要素 ①:Reflection(内省・反省)

論文の目玉機能の一つです。エージェントが定期的に過去の記憶を振り返り「高次の洞察」を生成します。

記憶: 「Isabellaとコーヒーを飲んだ」「Isabellaと一緒に仕事をした」「Isabellaに相談した」
↓ Reflection
洞察: 「Isabellaは私の良い友人である」

なぜ捨てたのか

購買意思決定は一度きりの判断です。エージェントが評価中に過去の回答を振り返って洞察を深める必要がありません。

また実装してみたところ:

  • LLM呼び出しが2倍になる(1ペルソナにつきReflection用に追加1回)
  • 洞察の内容がプロンプトで既に指定している信念と重複する
  • レイテンシが60秒→120秒に増加

コスト2倍・時間2倍で精度向上がほぼゼロ。即刻削除しました。


捨てた要素 ②:Planning(計画立案)

論文ではエージェントが朝起きてから「今日1日の行動計画」を立てます。

計画: 9:00 朝食 → 10:00 仕事 → 12:00 昼食 → 15:00 友人に会う...

なぜ捨てたのか

市場調査の文脈でペルソナが「計画を立てる」必要はありません。「このサービスを使うか」という1問に答えるだけです。

論文のPlanningは「時間軸のある行動シミュレーション」のための機能であり、点での判断には不要です。

実装しようとした際のコード(供養):

# これを実装したが全削除した
async def generate_plan(self, persona: dict, context: dict) -> str:
    prompt = f"""
    {persona['name']}として、{context['date']}の行動計画を立ててください。
    ...
    """
    # このplanをその後のシミュレーションに使おうとしたが
    # 評価の質向上には全くつながらなかった
    plan = await self.llm.generate(prompt)
    return plan

捨てた要素 ③:Dialogue(エージェント間の会話)

論文では複数のエージェントが会話し、互いに影響し合います。「Aさんが話したことをBさんが聞いて行動を変える」という社会的伝播のシミュレーションです。

なぜ捨てたのか

「100人が独立して同じサービスを評価する」という設計では、エージェント間の相互作用はむしろバイアス要因になります。

もし一人の「インフルエンサー的ペルソナ」が強い意見を持つと、他のペルソナが引きずられてしまう。市場調査として見ると、これは「インタビュアーの誘導バイアス」と同じ問題です。

独立性を保つために意図的にDialogueを外しました。

(将来的には「口コミ効果のシミュレーション」として実装したい機能ではあります)


捨てた要素 ④:動的Memory Stream

論文の中心的な仕組みです。エージェントが経験を積むたびにメモリが更新され、後の判断に影響します。

t=0: 「カフェで知らない人に声をかけられた(ネガティブ記憶)」
t=5: 「同じ人に再度声をかけられた」
↓ Retrieval: 過去の記憶を参照
判断: 「この人は少し怖い」

なぜ静的にしたのか

前述のように、購買意思決定は1回の判断で完結します。それ以上に:

  1. 一貫性の担保が難しい:動的記憶は実行のたびに内容が変わり、同じペルソナが別の判断をする可能性がある
  2. デバッグが困難:「なぜこの判断をしたのか」を追跡するのに記憶の全履歴を追う必要がある
  3. コストが増大:記憶の検索・更新のたびにLLM呼び出しが増える

プロダクトとしての再現性と説明可能性を優先した結果、静的な記憶設計を選択しました。


論文にない、独自に追加した要素

逆に論文には薄いが実装したら効果的だったものもあります。

Psychology(心理的トリガー)

{
  "psychology": {
    "fears": ["老後の資金不足", "仕事を失うこと", "時間を無駄にすること"],
    "desires": ["家族との時間を増やしたい", "副収入が欲しい"],
    "purchase_triggers": ["限定感", "専門家の推薦", "友人の口コミ"],
    "purchase_blockers": ["月額課金への不信感", "個人情報の取り扱い"]
  }
}

購買意思決定において「恐れ」と「購買ブロッカー」の明示は特に効果的でした。「このサービスが怖い理由」を持つペルソナの回答が格段にリアルになります。

Personality(MBTI・口癖)

{
  "personality": {
    "mbti": "ISTJ",
    "communication_style": "論理的で慎重。データや実績を重視する",
    "catchphrase": "「まず実績を見せてほしい」"
  }
}

口癖を持たせると、reason(判断理由)の文体が各ペルソナで異なるようになります。全員が似たような文体で回答していたのが、個人の声になりました。


最終的なペルソナ構造

論文からの取捨選択の結果:

persona = {
    # 論文由来(採用)
    "memory": [...],           # ✅ 静的記憶として採用

    # 論文由来(改変)
    "values": {...},           # ✅ 論文の"values"概念を具体化

    # 独自追加
    "beliefs": [...],          # ✅ 信念体系(最も効果的)
    "decision_logic": [...],   # ✅ 判断基準の優先順位
    "psychology": {...},       # ✅ 恐れ・欲望・購買トリガー
    "personality": {...},      # ✅ MBTI・口癖

    # 論文由来(不採用)
    # "reflection": ...        # ❌ 一度きりの判断に不要
    # "planning": ...          # ❌ 時間軸なし
    # "dialogue": ...          # ❌ 独立性を優先
    # "dynamic_memory": ...    # ❌ 再現性・コストの問題
}

定量的な検証結果

この設計で1,001社のB2Cサービスを評価し、実際の市場成功度と照合:

指標 結果
ピアソン相関 r = 0.637
予測正解率 76.5%
F1スコア 0.818
成功サービスの再現率 90.0%

Cohen の基準では r=0.5以上が「大きな効果量」です。

"捨てた4つ"を実装していた場合の推定影響

要素 コスト増加 精度変化(推定)
Reflection +100% ≒ 0(信念と重複)
Planning +50% ≒ 0(1回限りの判断)
Dialogue +200% 場合によりマイナス(バイアス)
動的Memory +150% +2〜3%(誤差範囲)

論文実装から学んだ3つの教訓

1. 論文の目的とプロダクトの目的をすり合わせる

Generative Agentsは**「時間軸のある自律的行動」を目指した研究です。一方、私のプロダクトが必要なのは「一時点での購買判断」**です。

論文の全要素を実装しようとすることは、ゲームエンジンをスプレッドシート代わりに使おうとするようなものでした。

2. 「論文にない要素」が最も効いることがある

最も精度に寄与したBelief SystemとDecision Logicは、論文には明示的に登場しません。論文はあくまで出発点であり、プロダクト要件に合わせた独自設計が重要です。

3. シンプルさは精度を犠牲にしない

動的記憶もReflectionも実装しなかったにもかかわらず、r=0.637という結果が得られました。論文のフル実装よりシンプルな静的設計の方がプロダクトとして優れていたという逆説的な結論です。

複雑な機構は「デモとして動く」ことと「プロダクトとして機能する」ことは別物です。


まとめ

要素 採用 理由
Memory(静的) 個人差の再現に必須
Belief System 最も精度貢献
Decision Logic 判断の一貫性・説明可能性
Reflection 1回判断に不要、コスト2倍
Planning 時間軸なし
Dialogue バイアス要因になる
動的Memory 再現性・コスト問題

Generative Agents論文は優れた研究ですが、ゲームキャラクターと消費者では「人格に求めること」が根本的に異なります。 論文を読んで「全部実装しよう」とするより、「何が自分のユースケースに必要か」を先に定義することで、より少ないコストでより良い結果が出せます。


リンク

実装の詳細(PersonaEngine全コード)はリクエストがあればGitHubに公開します。


本記事を書いた動機:論文を読んで「全部実装してから考えよう」とした過去の自分への警告として。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?