この内容は「なごあずの集い#8」で発表した内容の考察部分になります。
https://75az.connpass.com/event/383389/
MicrosoftがオープンソースでリリースしているマルチエージェントシミュレーションライブラリTinyTroupeをご存じでしょうか。LLMを使って人格や興味、目標を持つエージェント（TinyPerson）を作り、仮想環境（TinyWorld）の中でエージェント同士を対話させるPythonライブラリです。
公式のユースケースとしては、顧客インタビューのシミュレーション、フォーカスグループ、広告評価などが挙げられています。要するに「架空のペルソナ同士を議論させて、そこから知見を得る」というフレームワークです。
これを見て思ったのが、「人狼ゲームをAIエージェントにやらせたら面白いのでは？」 ということ。各エージェントに村人や人狼といった役職を与え、議論と投票をシミュレートすると面白い結果がでるに違いない🤩
結論から言うと、クラウド上のLLMサービスではレート制限の壁にぶつかりまくり、さらにローカルGPUで動かしても人狼ゲームとして成立する議論にはならなかった、というなかなかの「とほほ」な結果になりました。でも、この「うまくいかなかった」という結果自体が、マルチエージェントシミュレーションの現実を知る上で非常に意味のあるものだったと感じています。
💡 環境構築の詳細な手順（コード全文、config.iniの解説、トラブルシューティング等）は以下の記事にまとめています。本記事では実験を通じて感じたことと考察にフォーカスします。
そもそも何がやりたかったのか？
人狼ゲームって、AIエージェントのシミュレーション題材としてはすごく魅力的なんですよね。嘘をつく側と見破る側がいて、限られた情報の中で推理と説得を繰り返す。エージェントに「性格」を与えるTinyTroupeの仕組みとも相性が良さそうに見えました。
TinyTroupeには TinyPerson（エージェント）と TinyWorld（対話環境）という概念があり、これをそのまま人狼ゲームのプレイヤーと村の広場に対応させられます。役職ごとに性格と秘密の目標を設定し、昼は全員で議論、投票は発言から意思を抽出、夜は個別にアクションを実行。ゲームマスターはPythonスクリプトで制御する。
設計としては綺麗にまとまるんです。「いけるんじゃない？」という手応えがありました。
第1の壁➡️トークン消費の現実
WSL2上に環境を構築し、Ollama Cloud（gpt-oss:20b-cloud）とOpenAI API（gpt-4.1-mini）の2つのバックエンドを切り替えられる構成を用意しました。単体のエージェントに話しかける分には問題なく動きます。ここまでは順調。
でも、3人のエージェントで議論を始めた途端、429エラー（レート制限超過）の嵐。
Ollama CloudのFreeプランは時間あたり・日あたりの利用上限があり、TinyTroupeのようにガンガンAPIを叩くユースケースにはまったく耐えられませんでした。「じゃあOpenAI APIなら」とgpt-4.1-miniに切り替えても、Tier 1（200,000 TPM）ですら429が出る。
原因を調べてみて衝撃を受けました。
TinyTroupeは1エージェント1回のAPIコールで約5,000〜7,000トークンを消費する。
※あくまでも情報なので、今回は詳細については調べていません🙇
そうなると、内訳としては、汎用的なエージェント仕様（行動ルール、入出力フォーマット定義）だけで3,000〜4,000トークン。さらにペルソナ定義と認知状態（目標、文脈、注意、感情、エピソード記憶）が加わる。これが毎回のAPIコールで丸ごと送信されるんですよね。
人狼ゲームの規模で考えると、3人で1日分のシミュレーション（議論2ステップ＋投票）だけで約54,000トークン。5人で3日間フルに回すと約46万トークン。Tier 1の200K TPMでは1分あたりの制限に引っかかるのも当然です。
この数字を見たとき、「これはクラウドLLMで気軽に回せるものではないな」と実感しました。マルチエージェントシミュレーションのコストは「エージェント数 × ターン数 × 1回あたりのトークン数」で乗算的に増加する。ドキュメントを読んだだけでは分からない、動かして初めて分かるスケール感でした。
第2の壁➡️人狼ゲームとして成立しない
「じゃあローカルGPUなら解決するのでは？」と思いますよね。RTX 4090（VRAM 24GB）を借りることができたので、gpt-oss:20bをローカルで実行してみました。先のレート制限の問題は解消されました🤗
が、もっと根本的な問題が待っていました。
3人構成（田中: 人狼、佐藤: 占い師、鈴木: 村人）で3回試行した結果を見て、正直「これは厳しいな」と思いました。
人狼ゲームの文脈が完全に失われている … 「誰が人狼だと思いますか？」という問いに対して、エージェントがよくわからない解釈から、風や雨の観察、身体の反応速度の測定…という方向に話題を脱線。人狼ゲームのルール自体を理解できていません。
投票が完全に破綻する … 「最も怪しいと思う人物」を聞いているのに、宮崎駿や宮本武蔵、山田太郎といったゲーム参加者以外の名前を挙げ始める。佐藤が自分自身に投票するケースすらありました。
全員が同調して対立が生まれない … 最初のエージェントが「観察しましょう」と発言すると、全員が「そうですね、観察は大事ですね」と繰り返す。疑惑の提起も反論もなく、ただ協調的に同じ話題を掘り下げるだけ。人狼役の田中も、他のエージェントと全く同じトーンで発言しており、3人の発言を入れ替えても違和感がないレベルでした。
設計思想の不適合？
この結果を受けて色々と考えてみて、これは単なるモデル能力の問題ではなく、TinyTroupeの設計思想と人狼ゲームの本質が根本的に噛み合っていないのだという推測に至りました。
TinyTroupeが想定しているのは「善意の対話者による自由な対話」です。公式のユースケースを見れば一目瞭然で、顧客インタビューやフォーカスグループのシミュレーションでは、全員が素直に意見を述べればいい。嘘をつく必要もなく、他者と対立する動機もなく、構造化されたルールに従う必要もありません。
一方、人狼ゲームの本質は欺瞞と対立です。非対称な情報を持つプレイヤー同士が、嘘をつき、嘘を見破り、限られた情報の中で推理と説得を戦わせる。TinyTroupeの設計思想とは真逆のコミュニケーションが求められます。
| 要素 | TinyTroupeの想定 | 人狼ゲームの要求 |
|---|---|---|
| エージェントの動機 | 素直に意見を述べる | 嘘をつく / 嘘を見破る |
| 情報構造 | 全員が同じ情報を共有 | 非対称情報（役職の秘匿） |
| 進行ルール | 自由な対話 | 厳密なフェーズ制御 |
| 対話の目的 | 意見の共有・発散 | 論理的推理と欺瞞 |
| エージェント間の関係 | 協調的 | 対立的 |
これはフレームワークの欠陥ではなく、設計思想の違いかなと。そんな中でTinyTroupeに「人狼ゲームに向いてない」と文句を言うのは、スプーンに「フォークの仕事ができない」と言うようなものかもしれません。
さらにプロンプト構造の問題もあります。TinyTroupeは毎回のAPIコールで約3,000〜4,000トークンの汎用的な「エージェント仕様」を送信しており、人狼ゲームの指示は personality_traits の数行に押し込められるだけ。システムプロンプト全体の中でゲームの文脈が埋もれてしまい、モデルから見ると「なんか色々言われてるけど、とりあえず協調的に対話すればいいのかな」という状態になるのかもしれないなと感じました。
TinyTroupeに限らない構造的な課題
この問題を考えていくうちに、TinyTroupeに限らず、LLMベースのマルチエージェントフレームワーク全般に当てはまる課題が見えてきました。
コストの乗算的増加 … 「各エージェントが独立してLLMにフルコンテキストを送信する」というアーキテクチャは、エージェント数 × ターン数に比例してコストが膨らみます。今回はアプローチとして効率が悪い。
LLMの本質的な限界 … LLMは「次のトークンを予測する」モデルであり、「戦略的に嘘をつく」「他者の発言の裏を読む」「長期的な計画に基づいて行動する」といった能力は、モデルサイズとプロンプト設計に大きく依存します。トークン消費の問題はさらに深刻化するというジレンマがあります。
同一モデルの協調的バイアス … 全エージェントが同じLLMで動いているため、モデル固有のバイアス（この場合は「協調的に対話する」傾向）が全員に均一になってしまうようです。
「うまくいかない」の価値
こう書くと失敗談に見えるかもしれませんが、個人的にはとても良い実験だったと思っています。 今回の失敗は以下につながるかなと感じます。
- フレームワークの「得意領域」が見えた
- トークン消費のスケール感を体感できた
- 次のアプローチが見えた
今後…？
もし人狼ゲームのAIシミュレーションを実現するなら、いくつかの方向性が考えられます。いずれも未検証ですが、今回の実験で得られた知見を踏まえた仮説です。
専用ゲームエンジンの自作することで、ゲーム状態管理をコードで厳密に制御し、LLMの役割を「エージェントの思考・発言生成」だけに絞る。人狼ゲーム特化のコンパクトなプロンプトにすれば、トークン消費も大幅に減らせるはずです。
また、AIWolf（人狼知能）プロジェクトなど、人狼ゲームに特化した研究はすでに蓄積があります。車輪の再発明をせず、先人の知見を取り入れるのが賢明かもしれません。
いずれにせよ、「汎用フレームワークにゲームを載せる」のではなく、「ゲームの要件に合わせて仕組みを設計する」方向に発想を切り替える必要がありそうです。
おわりに
TinyTroupeで人狼ゲームのシミュレーションに挑戦した結果は、「動くけど使えない」でした。クラウドLLMではレート制限の壁にぶつかり、ローカルGPUでレート制限を解消しても、人狼ゲームとして議論が成立しない。根本原因は、TinyTroupeの設計思想（協調的な自由対話）と人狼ゲームの要求（欺瞞・対立・構造化ルール）がマッチしていないことではないかと推測します。
でも、この実験を通じてTinyTroupeのアーキテクチャ特性、LLMのトークン消費の現実、マルチエージェントフレームワークの限界と可能性が実感として理解できました。ドキュメントを読むだけでは得られない体験だったかなと思います。
