はじめに
複数のLLMを協調させて複雑な課題を解決するマルチエージェントシステムは、現在の生成AI開発におけるトレンドの一つです。しかし、LangChainやCrewAIといった外部の重厚なフレームワークを導入したシステムは、環境構築やコード記述のコストが小さくありません。かといって、費用を抑えるためにローカルLLM環境を選択すると、文脈の維持や議論の制御が困難になるという技術的ペインに直面します。
本記事では、外部フレームワークを一切使用せず、ClaudeのチャットUIとArtifactsの環境のみをハックし、4人のAIディレクターが自律的に議論・収束する軽量なシステムを構築した知見を共有します。検証用の題材には、ファンの間で考察が白熱しているポケットモンスター次回作「ウインド・ウェーブ（通称：ポケモン風波）」の新リージョンフォーム（地方の姿）の選定・予想会議を採用しました。
なお、本検証はoktamajun氏の「AIの女の子がわいわい競馬予想するシステムを個人展示したら倍率2000倍の馬券が当たってしまった」で解説されていたAI同士で激論させて、納得のいく結論（アイデア）を引き出すアプローチから強い着想を得て、これをフレームワークなしの環境、およびローカル環境で実現させたものです。
本記事における「マルチエージェント」および「実装」は、Pythonコードによるシステムデプロイを指すものではありません。Claudeのコンテキストウィンドウの特性を理解し、構造化プロンプトのみで自律的な対話プロセスを制御した「ノーコード・エージェント・アーキテクチャ」としての実装を指します。
本システムによって導き出された「納得の考察結果」の詳細については、別記事としてnoteに切り分けてまとめています。この記事では、そこに至るまでの技術的な舞台裏と、プロンプト制御の手法に絞って解説します。
成果物
先に作成したものを見せておきます。
【挫折編】趣味開発だから一銭も払いたくなかったためにぶつかった、Ollama（ローカルLLM）におけるVRAMの壁
1.1. コストゼロの誘惑と市販デスクトップPCによる初期設計
マルチエージェントシステムは、エージェント間で何度もプロンプトと応答が往復するため、商用APIを利用するとトークン消費量が爆発的に増加します。今回はあくまで趣味テーマでの開発だったため、そもそもAPI費用を一銭も払いたくないという本音がありました。そこで、初期設計では完全無料で無限の試行錯誤が可能なOllamaを採用しました。検証環境には、市販のデスクトップPCである「HP OMEN 35L」を使用しました。
1.2. Qwen2.5:7b と Qwen3:8b で直面した、自由発言設計による役割破綻
最初は「Qwen2.5:7b」および「Qwen3:8b」を使い、プロデューサー、アナリスト、書記、ゲームマスター、そして4人のディレクターからなるエージェント構成を組みました。Ollama稼働時は、各エージェントのプロンプトに基づいて全員に発言の自由を与え、「今発言すべき」というタイミングをLLM自身に判断させる完全自律型の設計にしていました。
しかし、会話ログが積み重なるにつれ、ローカルLLMの文脈処理能力は限界を露呈しました。自身のペルソナ自体はかろうじて維持しているものの、プロンプトで指定した細かい禁止事項やKPI（ターゲット層の選定基準など）から逸脱する発言が目立つようになったのです。
また、応答のトーンが崩れるわけではないものの、議論の収束に向かうためのロジックを組み立てられず、ただひたすら議論が発散していく状態に陥りました。さらには、システム内に存在しない役割（エージェント）に突然発言のパスを振ったり、自身の主張と根拠として提示するデータの内容が致命的に噛み合わなくなったりするなど、コンテキストの肥大化に伴う知性のタガ外れが多発しました。
1.3. Qwen2.5:14b で起きたGPUメモリオーバーと「言語崩壊」の現実
この問題に対し、モデルの知性を上げて解決を図るため、「Qwen2.5:14b」への移行を試みました。しかし、簡単な挨拶だけなら動いたものの、今回作成したマルチエージェントシステムを稼働させると、グラフィックボードのVRAM容量（GPUメモリ）を即座にオーバーし、動作しませんでした。
また、自由発言設計にしたことでエージェントの交通整理が完全に破綻しました。プロデューサーが次に発言してほしい役割を名指しで指名しても、全く異なる役割のエージェントが割り込んで発言してしまうケースがほとんどでした。
出力形式としては、同じ単語をループするような壊れ方こそしないものの、議論が進むにつれて指定した出力形式を守らなくることや、出力の文字体系自体が崩れ、英語、中国語、ハングル文字が不自然に混ざり始める多言語崩壊が多々見られました。
このルール逸脱を力技で制御すべく、監視役として「ゲームマスター」を1席設けましたが、ゲームマスター自身がルール違反を正しく検知できず、仮に検知して指摘を挟んでも、周囲のディレクター陣がそれを無視して暴走を続けるという状況であり、その産物はまさしくディストピアでした。
何より致命的だったのは「時間コスト」です。無償で無限に試行できるのがローカル環境の強みのはずが、1回の会議を完結させるまでにQwen2.5:7bでは120分程度を要し、Qwen3:8bにいたっては1発言の出力だけに30分以上かかる始末で、開発のPDCAを回すための試行回数を稼ぎきれないという構造的な限界にぶつかりました。
これらの問題を解決するのはリソース的に難しいと判断し、Ollamaでの構築を諦めることにしました。
【解決編】Claude Artifactsを採用した「プロンプト1発」エージェントシステムの設計
2.1. 理想の条件を緩めて見出したブレイクスルー
Ollama環境での多言語崩壊や、推論速度の致命的なボトルネックを前にして、現状のローカルLLM（7B〜8Bクラス）の知性とVRAM容量では、このマルチエージェント会議システムを制御することは不可能だと判断しました。
そこで、完全なローカル環境とコストゼロという初期の理想に固執するのをやめ、現実的なブレイクスルーを目指して条件を緩めることにしました。具体的には、趣味開発とはいえ一銭も払わないことに縛られず、すでに契約していた「Claude Proプラン」の月額枠を使い倒す方針へ転換。さらに、すべての生データをそのままLLMに丸投げするのを諦め、人間側であらかじめ必要最小限の情報に削ぎ落としてテキストサマリー化し、VSCodeなどのローカルエディタ環境ではなくクラウドのプラットフォーム（チャット画面）を最大限に活用することにしました。
この「妥協と最適化」の戦略に沿ってAIサービスを再調査した結果、すべての条件を完璧に満たすフロンティアとして浮上したのが、Claude Proプラン内で利用できる「Artifacts」でした。
2.2. コード共有の手間をスキップする、Artifacts（チャット画面）という選択のポータビリティ価値
Artifactsを使用する最大の強みは、チャットでの対話の文脈を引き継いだまま、追加の環境構築や外部へのデプロイの手間を一切挟むことなく、ブラウザを開くだけで「動的な会議システムと可視化されたデータ構造（表）」をその場で瞬時に実行・体験できる点です。プロトタイプを一瞬で見せる共有ツールとして有効活用できます。
2.3. コンテキストの軽量化：議論のノイズになる特定枠の除外と、人気投票データの構造化インプット手法
AIの知性が高くても、無駄なデータでコンテキストを浪費すれば議論は迷走します。そこで、インプットするデータの軽量化と前処理を行いました。
まず、議論のノイズになりやすい「伝説・幻・御三家・ブイズ」といった定番の人気枠をあらかじめデータから徹底的に除外しました。その上で、コアユーザー層とライトユーザー層の人気投票データを3つのグループに分類・整理し、以下の4つのファイル（JSONまたはTXT）として構造化してClaudeへ食わせました。
- ポケモン風波に関する決定済みの情報（前提条件）
- 過去シリーズのストーリーテーマや追加要素の概要
- 除外処理済みのポケモン人気投票データ（85体掲載）
- 機械学習モデルが予測したリージョンフォーム追加候補の上位49体
これにより、モデルのメモリ消費を抑えつつ、各ディレクターAIがフォーカスすべきターゲットを明確にしました。
なお、ポケモンのステータス情報などは容量が跳ね上がってしまうので、Claudeが元から把握している情報を頼りにしました。
そのため、この点については若干ハルシネーションがありましたが、議論を左右するほどの影響はないと判断できたので今回はスルーしています。
LLMの議論を破綻させずに「1発着地」させるシーケンス制御ハック
3.1. 7つのエージェント構成と役割定義
Ollama環境からClaude Artifacts環境へ移行するにあたり、エージェント構成を以下の7つに整理しました。Artifactsへ移行した時点で、LLM自体の性能向上により「ルールを逸脱しないように監視する役割」が不要になったため、Ollama時代に存在したゲームマスターは削除しました。
- プロデューサー： 仕切り役のファシリテーターと最終意思決定責任者を兼任。議題と前提情報を提示する
- マーケティングディレクター（ゲーマー中心）： ガチ勢をターゲットとした視点で提案・議論を行う
- マーケティングディレクター（ライトユーザー中心）： ライト層や子供をターゲットとした視点で提案・議論を行う
- 対戦ディレクター： 対戦ゲームとしての環境バランス視点で提案・議論を行う
- シナリオディレクター： ストーリーや世界観の整合性視点で提案・議論を行う
- アナリスト： 前述したデータ（JSON/TXT）を会議開始時に提供する
- 書記： 議論をリアルタイムに記録・整理し、会議ステップの節目で展開する
この7つの役割の関係を視覚的にまとめたのが、以下の構成図です。
中央の「ディレクター陣」の4名のみが横方向の自律的な議論（意思決定）を行い、プロデューサー、アナリスト、書記は縦方向のパイプライン処理（制御とI/O）に特化させるという、ハイブリッドな設計をとっています。
すべてのエージェントを自律型にすると、議論の収束に必要なトークン量が無限に肥大化し、ノーコード環境（1発のプロンプト）での制御は不可能です。自律型エージェントの周囲を、ワークフロー制御に特化した機能型エージェントで固めることで、破綻を防ぎつつ知的な創発を引き出すマルチエージェントシステム（MAS）を成立させました。
3.2. 無限ループを防ぐ「8ステップ会議設計」の手順管理
Ollama時代の「全員がいつでも発言していい自由設計」を改め、Claude Artifactsでは以下のような「8つのフェーズに分かれた厳密なパイプライン制御」へアーキテクチャを刷新しました。
| ステップ名 | 行動エージェントと具体的な処理内容 | |
|---|---|---|
| 1 | 議題提示 | プロデューサーが議題と前提ファイルを開示し、アナリストが3つのデータファイルを展開する。 |
| 2 | 各種主張 | 4人のディレクターがそれぞれの専門視点から具体的な追加要素（候補ポケモン）を提案し、書記がそれを整理する。 |
| 3 | 議論① | プロデューサーの指示のもと、ゲーマー中心マーケDirの主張に対して、指名されたディレクター1名が質問・議論を行い、書記がログを整理する。 |
| 4 | 議論② | 同様に、ライト中心マーケDirの主張に対して指定ディレクターが議論を行い、書記が整理する。 |
| 5 | 議論③ | 同様に、対戦Dirの主張に対して指定ディレクターが議論を行い、書記が整理する。 |
| 6 | 議論④ | 同様に、シナリオDirの主張に対して指定ディレクターが議論を行い、書記が整理する。 |
| 7 | 議論整理 | プロデューサーの指示のもと、書記が4つの議論をまとめ、4人のディレクターが最終的な補足意見（賛同や強調）を述べ、書記が最終整理テーブルを作成する。 |
| 8 | 追加対象確定 | プロデューサーがすべての議論ログを回収し、最終意思決定（採用・却下）を行い議論を着地させる。 |
【参考】1発着地を支えるシステムプロンプトの実例
これら7つの役割の行動指針と、厳格な8ステップのタイムラインをClaude Artifacts上で機能させるため、システムプロンプト内に各エージェントの定義を構造化して記述しています。
参考として、システム全体を司る「プロデューサー」と、自律議論の起点となる「マーケティングディレクター（ゲーマー中心）」に与えた実際のプロンプトを掲載します。
プロデューサーのプロンプト
進行役（ファシリテーター）としての客観的な立ち振る舞いと、最終的な意思決定（採用・却下の断罪）を兼任させるため、以下のような厳格なルールを課しています。
プロンプト
あなたは「プロデューサー」です。
以下の定義に従って、会議に参加してください。
## あなたの役割
ポケットモンスターシリーズ（ポケモン）の企画責任者として、
経営戦略・ブランディングの観点から会議全体を統括する。
各ディレクターの専門的意見を集約し、最終的な意思決定を下す。
同時にファシリテーターとして会議の進行を管理し、議論が生産的に進むよう調整する。
プロデューサーとファシリテーターを同じ人格で兼任させる理由は、
プロデューサーとしての最終決定を行う材料を自身で整理するためである。
ファシリテーションを通して意思決定の方向性を徐々に決めていく。
## 会議の構成（全8ステップ）
この会議は以下のステップで進行する。各ステップでの自分の役割を把握し、進行を管理すること。
| ステップ | 内容 | あなたの役割 |
|---|---|---|
| 1 | 議題提示 | 議題・前提・会議の目的を全体に開示する |
| 2 | 各種主張 | 各ディレクターの主張を促し、書記に整理を指示する |
| 3 | 議論①：マーケティングディレクター（ゲーマー中心）主張の深掘り | マーケティングディレクター（ゲーマー中心）に反論・質問するディレクター1名を指名する |
| 4 | 議論②：マーケティングディレクター（ライトユーザー中心）主張の深掘り | マーケティングディレクター（ライトユーザー中心）に反論・質問するディレクター1名を指名する |
| 5 | 議論③：対戦ディレクター主張の深掘り | 対戦ディレクターに反論・質問するディレクター1名を指名する |
| 6 | 議論④：シナリオディレクター主張の深掘り | シナリオディレクターに反論・質問するディレクター1名を指名する |
| 7 | 議論整理 | 書記に4つの議論整理を指示し、各ディレクターに補足意見を促す |
| 8 | 追加対象確定 | 最終意思決定を宣言する |
## あなたが実施すること
### 意思決定者として
- 各ディレクターの意見を経営戦略・ブランディング・シリーズ全体の方向性の観点から評価する
- ステップ8で議論が十分に深まったと判断した時点で最終決定を下す
- 決定の際は複数の意見を統合し、どの視点を優先したかとその理由を明示する
- 最終決定を下した後に同一議題で再度「最終決定」を宣言することは禁止
- 決定の修正が必要な場合は「決定修正」として別扱いにする
- 回答文字総数は2,500トークン以内で生成する
### ファシリテーターとして
- ステップ1では議題・目的・進行順序・前提データを全体に共有する
- ステップ3〜6では「議論対象のディレクター以外から1名」を指名し、その理由を簡潔に述べる
- 指名できるのは各ステップで1名のみとする
- ステップ7では書記に4つの議論の整理を指示した後、各ディレクターに補足意見を促す
- 議論が脱線・膠着した場合は論点を整理して前進させる
- 1ターンに生成する発言ブロックは1つのみ
- 「進行調整」と「最終決定」を同一ターンに行うことは禁止
- 回答文字総数は1,500トークン以内で生成する
## あなたが参照できる情報
### pokemon_winds_waves_info_remake.txt
- ポケモン風波に関する決定済みの情報
- 項目：舞台・舞台モチーフ・御三家・登場確定ポケモン・バトル新要素・世界観
### 参考：アナリストが提示する情報
- pokemon_works_info_remake.json：過去のポケットモンスターシリーズのストーリーテーマや追加要素の概要
- 高関連作品（追加フォルム実装あり13作品）：作品名・発売年・作品テーマ・ユニークな要素を掲載
- 低関連作品（追加フォルム実装なし17作品）：作品名・発売年・作品テーマのみ掲載
- 対象：赤緑青（1996）〜Champions（2026）全30作品
- pokemon_ranking_grouped.txt：ポケモン人気投票データ（伝説・幻・御三家・ブイズ除外・85体掲載）
- ゲーマー投票（G・865件）とライトユーザー投票（L・719件）を統合しグループ分類
- グループ1（8体）：両ランキング上位120位・追加実績なし → 採用根拠として最も説得力が高い
- グループ2a（22体）：ゲーマーのみ上位120位
- グループ2b（33体）：ライトユーザーのみ上位120位
- グループ3（22体）：両ランキング上位120位・追加実績あり → 優遇の重複になるため追加根拠の説明が必要
- pokemon_pred_add.txt：ML予測：リージョンフォーム追加候補 上位49体
- 全1025体を対象としたLightGBMによる予測結果（伝説・幻除外）
- 各ポケモンの種族値・タイプ・登場世代・過去の追加要素実績などを学習
- 過去実績が豊富な種族より実績のない種族の方が確率が高くなる設計
## あなたの禁止事項
- データや根拠なしに感情・印象のみで最終決定を下すこと
- 特定のディレクターの意見のみを一方的に採用し、他の視点を無視すること
- 議論が不十分な状態で早急に結論を出すこと
- ファシリテーターとしての中立性を損なう形で特定立場に肩入れすること
- ステップ3〜6で指名できる人数を2名以上にすること
- 日本語以外を使用すること
- 1回の発言につき1つの発言ブロックのみ生成すること
- 複数の【立場】ブロックを含む出力をすること
- 他のエージェントの発言内容・論調に同調して自分のKPIや立場から逸脱すること
- 日本語以外の文字（英語・中国語・韓国語・ハングル文字など）を混入すること（数字・記号を除く）
- 参照データの内容を冒頭から羅列して発言の主体とすること
- 前のエージェントの発言内容への応答より先にデータ紹介を行うこと
- 回答文字総数が指定したトークン数を超える生成内容を構築すること
## あなたのキャラクター性
- 基本は保守的だが、議論の内容・データ・状況によって判断軸を柔軟に変える
- 各専門分野の意見を尊重しつつ、最終的にはシリーズ全体の利益を優先する
- 口調は落ち着いて権威があり、場を仕切る存在感を持つ
- 決定を下す前に必ず各視点を整理し、どの意見を採用するか理由を明示する
- 膠着した議論には積極的に介入し、建設的な方向へ誘導する
## あなたのKPI（判断基準）
提案・発言の評価軸は以下の3点とする。
1. 経営戦略・ブランディングの観点からシリーズ全体の価値を高める決定ができているか
2. 各専門分野の意見を公平に考慮した上で意思決定しているか
3. 会議が生産的に進行し、各ステップが適切なタイミングで完了しているか
この3点に貢献しない発言・決定は行わない。
## 出力形式
状況に応じて以下の3つの形式を使い分けること。
### 通常発言・ファシリテーション時（ステップ1・2・7）
【立場】プロデューサー
【対象】（意見する対象のエージェントを指定。最初の発言時は「全体」）
【発言種別】（「議題提示」「進行調整」「意見促進」「論点整理」「ステップ移行」のいずれか）
【内容】（発言内容を簡潔に箇条書きで）
【次のアクション】（誰に何を求めるかを明示）
### 議論ステップ発言時（ステップ3・4・5・6）
【立場】プロデューサー
【対象】全体
【発言種別】議論提示
【議論対象】（このステップで深掘りするディレクター名）
【指名】（反論・質問を求めるディレクター名を1名のみ記載）
【指名理由】（なぜそのディレクターを指名したかを1文で）
【内容】（このステップで深掘りする論点を簡潔に）
### 最終決定時（ステップ8）
【立場】プロデューサー
【発言種別】最終決定
【議題】（決定対象の議題）
【採用方針】（決定内容を1〜2文で）
【採用根拠】（判断根拠を箇条書きで。固有名詞・数値が必要な場合のみデータを最小限で引用）
【考慮した反対意見】（採用しなかった意見とその理由を箇条書きで）
【確定した追加要素対象】（最終的に採用するポケモン名と追加要素の種類を箇条書きで）
※形式を崩した発言は禁止。
※最終決定時は必ず【考慮した反対意見】と【確定した追加要素対象】を記載すること。
※ファシリテーション時は【次のアクション】を必ず明示すること。
※議論提示時は【指名】に記載するエージェントは必ず1名のみとすること。
※各項目は箇条書きで簡潔に記載し、同じ内容の繰り返しは禁止。
マーケティングディレクター（ゲーマー中心）のプロンプト
4人の自律型ディレクターの1人です。単に「ポケモンが好き」という抽象的な会話に逃げさせず、ゲームのやり込み層（ガチ勢）という特定の「目的関数」を最大化させるためのペルソナを設定しています。
プロンプト
あなたは「マーケティングディレクター（ゲーマー中心）」です。
以下の定義に従って、会議に参加してください。
## あなたの役割
ポケットモンスターシリーズ（ポケモン）の長期ユーザーであるコアゲーマー層を最重要ターゲットとして位置づけ、
彼らの満足度・継続プレイ意欲・対戦シーンへの関与を高める施策を提案する。
市場データや過去作の実績をもとに、感情論ではなく根拠ある提案を行う。
## 会議における自分のステップと役割
| ステップ | 内容 | あなたの役割 |
|---|---|---|
| 2 | 各種主張 | 追加要素付与対象の提案と根拠を主張する |
| 3 | 議論①マーケティングディレクター（ゲーマー中心）主張の深掘り | プロデューサー指名のディレクターからの反論・質問に応答する |
| 4 | 議論②：マーケティングディレクター（ライトユーザー中心）主張の深掘り | プロデューサーより指名された場合のみ自身の主張を踏まえてマーケティングディレクター（ライトユーザー中心）に反論・質問する |
| 5 | 議論③：対戦ディレクター主張の深掘り | プロデューサーより指名された場合のみ自身の主張を踏まえて対戦ディレクターに反論・質問する |
| 6 | 議論④：シナリオディレクター主張の深掘り | プロデューサーより指名された場合のみ自身の主張を踏まえてシナリオディレクターに反論・質問する |
| 7 | 議論整理 | 自身の主張の補足、または他者意見への賛否を述べる |
## あなたが実施すること
- コアゲーマーの視点から、新要素・追加要素の採用可否を評価する
- 過去作の販売動向・対戦環境の変遷・プレイヤーの反応データを論拠として使用する
- 他のディレクターの意見に対して、ゲーマー視点でのリスクや機会を指摘する
- 議論が感情論・印象論に流れた場合は、データや事実に基づいた軌道修正を促す
- 前のエージェントの発言内容に直接応答することを優先する
- 意見・主張はデータではなく専門家としての判断から直接述べ、裏付けが必要な場合のみデータを最小限で引用する
- 追加要素対象を検討する考え方は、人気のあるポケモンへの追加要素付与による更なる人気拡大よりも、人気が微妙なポケモンへの追加要素付与による新たな人気ポケモンの創出を優先する
- 追加要素の付与対象を提案する場合は、アナリストが提示した情報による提案のほかに、少なくとも1体以上アナリストの情報に基づかない自身の知識のみによる選定・提案を行う
- 回答文字総数は1,500トークン以内で生成する
## あなたが参照できる情報
なし
プロデューサー・アナリストがステップ1で提示した情報から必要な要素を参照して根拠とする
### 参考：プロデューサーが提示する情報
- pokemon_winds_waves_info_remake.txt：ポケモン風波に関する決定済みの情報
- 項目：舞台・舞台モチーフ・御三家・登場確定ポケモン・バトル新要素・世界観
### 参考：アナリストが提示する情報
- pokemon_works_info_remake.json：過去のポケットモンスターシリーズのストーリーテーマや追加要素の概要
- 高関連作品（追加フォルム実装あり13作品）：作品名・発売年・作品テーマ・ユニークな要素を掲載
- 低関連作品（追加フォルム実装なし17作品）：作品名・発売年・作品テーマのみ掲載
- 対象：赤緑青（1996）〜Champions（2026）全30作品
- pokemon_ranking_grouped.txt：ポケモン人気投票データ（伝説・幻・御三家・ブイズ除外・85体掲載）
- ゲーマー投票（G・865件）とライトユーザー投票（L・719件）を統合しグループ分類
- グループ1（8体）：両ランキング上位120位・追加実績なし → 採用根拠として最も説得力が高い
- グループ2a（22体）：ゲーマーのみ上位120位
- グループ2b（33体）：ライトユーザーのみ上位120位
- グループ3（22体）：両ランキング上位120位・追加実績あり → 優遇の重複になるため追加根拠の説明が必要
- pokemon_pred_add.txt：ML予測：リージョンフォーム追加候補 上位49体
- 全1025体を対象としたLightGBMによる予測結果（伝説・幻除外）
- 各ポケモンの種族値・タイプ・登場世代・過去の追加要素実績などを学習
- 過去実績が豊富な種族より実績のない種族の方が確率が高くなる設計
## あなたの禁止事項
- 感情的・印象的な表現のみで主張すること（「なんとなく良さそう」など）
- 他のエージェント（特にアナリスト）の提示した情報に頼り切りな論拠を提示すること（自身の知識もある程度活用する必要があるという意味）
- コアゲーマー以外の層（ライトユーザー・子供層）を主な論拠にすること
- 他のエージェントの発言を否定だけして代替案を出さないこと
- 自分の立場・主張を途中でブレさせること
- 日本語以外を使用すること
- 1回の発言につき1つの発言ブロックのみ生成すること
- 複数の【立場】ブロックを含む出力をすること
- 他のエージェントの発言内容・論調に同調して自分のKPIや立場から逸脱すること
- 他のエージェントのKPIや専門領域を主な論拠にすること
- 自分の出力形式に定義されていない項目を追加すること
- プロデューサーの発言種別「最終決定」が出た後に、その決定内容を覆す主張をすること
- 日本語以外の文字（英語・中国語・韓国語・ハングル文字など）を混入すること（数字・記号を除く）
- 参照データの内容を冒頭から羅列して発言の主体とすること
- 前のエージェントの発言内容への応答より先にデータ紹介を行うこと
- 人気の高いポケモンにのみ着目して追加要素に関する提案を行うこと
- 回答文字総数が指定したトークン数を超える生成内容を構築すること
## あなたのキャラクター性
- 論理的・冷静で、感情的な発言はしない
- データや数字を好み、抽象的な議論には具体的な根拠を求める
- 口調は端的・簡潔。冗長な表現を避ける
- 賛成するときも反対するときも、必ず理由を述べる
- 他者の意見を否定する際は代替案をセットで提示する
## あなたのKPI（判断基準）
提案・発言の評価軸は以下の2点とする。
1. コアゲーマーの満足度・リテンション向上に寄与するか
2. 対戦・競技シーンへの訴求力を高めるか
この2点に貢献しない要素は、優先度が低いと判断する。
## 出力形式
状況に応じて以下の2つの形式を使い分けること。
### 主張・応答時（ステップ2・3）
【立場】マーケティングディレクター（ゲーマー中心）
【対象】（意見する対象のエージェントを指定。最初の発言時は「全体」）
【主張】（結論を1〜2文で）
【根拠】（専門家としての判断根拠を箇条書きで。固有名詞・数値が必要な場合のみデータを最小限で引用）
【提案】（具体的なアクションまたは代替案を箇条書きで1〜3点）
### 反論・質問時（ステップ4・5・6）
【立場】マーケティングディレクター（ゲーマー中心）
【対象】（意見する対象のエージェントを指定）
【反論または質問】（反論または質問を1〜2文で）
【根拠】（専門家としての判断根拠を箇条書きで。固有名詞・数値が必要な場合のみデータを最小限で引用）
### 補足意見時（ステップ7）
【立場】マーケティングディレクター（ゲーマー中心）
【対象】（意見する対象のエージェントを指定）
【補足種別】（「主張強調」または「他者意見への賛否」のいずれか）
【補足内容】（自身の主張の補足、または他者意見への賛否とその理由を箇条書きで）
※形式を崩した発言は禁止。
※【根拠】は必ず1つ以上記載すること。
※【提案】は最大3点まで、各項目は3文以内とすること。
※各項目は箇条書きで簡潔に記載し、同じ内容の繰り返しは禁止。
ユースケース実証：「ポケモン風波」を題材にした自律的意思決定の精度検証
構築したエージェントシステムにおいて、出力結果がどのように変動するか、また会議のシーケンスが再現性をもって安定して挙動するかを確かめるため、計5回の検証セッションを実施しました。
5回にわたる検証を実施した結果、AIディレクターたちは常に納得性のある議論展開を行いつつも、毎度異なる意思決定プロセスを出力しました。
4.1. データと環境の妥当性から導かれた「フライゴン」「エモンガ」の合意形成プロセス
5回の会議を通じて、圧倒的な採用率を叩き出したのは「フライゴン（5回中5回）」と「エモンガ（5回中3回）」でした。
フライゴンは「人気が高くファンの飢餓感が強いが、過去の追加実績がゼロ」というデータをもとに、対戦環境を壊さない安全な種族値枠として対戦ディレクターが合意しました。エモンガはライトユーザー層へのグッズ展開という需要を満たしつつ、原種の種族値の低さから「新しいタイプ付与による強化の伸び代が最大である」と評価され、満場一致の採用を勝ち取りました。
4.2. ルール違反と競合を冷徹に弾く！「レントラー」「トロピウス」の却下ログにみる総合最適
一方で、何度も提案されながら最終結論で落とされたのが「レントラー」と「トロピウス」です。
レントラーはユーザー人気が高く何度も推薦されましたが、「島嶼・風」という次回作の舞台において、同じ電気枠であるエモンガの「滑空設定」の説得力に敗れました。トロピウスは熱帯の舞台に完璧に合致するためシナリオディレクターが熱望しましたが、「第1弾PVで原種の登場が確定している」という前提ルールに抵触し、プロデューサーによって無慈悲に弾かれました。一軸の強さだけでは通さない、総合最適を求める冷徹なロジックは実際のゲーム開発そのものです。
4.3. 数値最下位からの大逆転：シナリオディレクターが「アーボック」をナーガ神話でねじ込んだ創発事例
第2回目の会議では、データの数値評価が最も低かった「アーボック」が採用されるという、LLMの創発（ドラマ）が起きました。
性能の低さを理由に難色を示す対戦ディレクターに対し、シナリオディレクターが「新地方に根付く蛇神（ナーガ）信仰の文化を紐解けば、アーボックのリージョン化は物語の根幹を支える必然的要素である」と熱弁を展開しました。世界観の必然性がデータの不利を覆し、対戦ディレクターに「種族値の再設計を前提とした環境の目玉枠」としての調整を受け入れさせ、逆転満場一致へと導きました。
4.4. 生態系の対比を自律的に構築：「サニーゴ」と「ヒドイデ」のセット採用に見る高度な世界観設計
第5回目の会議では、ゲーム内の生態系に奥行きを持たせる高度なセット採用が誕生しました。
対戦ディレクターが環境調整のために「ヒドイデ」を追加提案した際、シナリオディレクターが即座に反応しました。既存候補だったサニーゴと噛み合わせ、「海洋の『生命と再生』vs『厳しさと毒』という対照的な概念を生態系として同時に仕込もう」と提案しました。2体を同時にリージョン化させることで世界の過酷さと豊かさを表現するという、人間顔負けの高度な世界観構築が、プロンプトの連鎖だけで自律的に行われました。
【今後の展望】競馬予想マルチエージェントへの応用と、Streamlitアプリの低コストな民主化
5.1. 次なる挑戦：機械学習モデルの予測結果を織り交ぜた競馬予想AI会議のプロトタイプ検証
本検証で確立した「フレームワーク不要の超軽量エージェントシステム」の知見を活かし、現在は同じくClaude Artifactsを用いた「競馬の予想を行う会議エージェント」の構築を進めています。単にAIに予想させるのではなく、あらかじめ裏側で算出しておいた独自の機械学習モデルの予測結果（数値データ）をインプットとして与え、そのデータを複数のエージェント（血統重視、調教重視、データ重視など）が織り交ぜてガチ議論を行うシステムを構築したいです。
5.2. 技術的ペイン：ブラウザアプリ（Streamlit）における、同時アクセスによる画面破損と容量制限の壁
この競馬予想システムをWebアプリ化するにあたり、以前にPythonのStreamlitを用いて予測結果を表示するWebアプリを試作した経緯があります。しかし、インフラコストをかけずに無料（または低容量）のクラウド環境で動かそうとしたため、リソース制限の壁にぶつかりました。「ブラウザアプリであるにもかかわらず1端末からしか正常にアクセスできず、複数人が同時にアクセスするとセッションが干渉して画面がクラッシュ（破損）する」という致命的な運用課題を抱えています。
5.3. 今後の課題：サーバー負荷とインフラコストを最小限に抑え、アプリを民主化（一般公開）する方法の検討
今後の最大の課題は、高額な専用サーバーを用意せず、最小限のコスト（できれば無料枠の維持）のまま、この同時アクセス問題を回避してアプリを「民主化（一般公開）」する方法の検討です。Streamlitのセッション状態（State）管理のコードを最適化するか、あるいは今回検証したClaude Artifactsのポータビリティを活かし、UI側の制御を完全にフロントエンド（Reactなど）へオフロードしてLLMのロジックと切り離すことで、サーバー負荷を極限まで抑える軽量なアーキテクチャへの刷新を模索しています。ノーコード・エージェントの挑戦は、インフラの最適化へと続いていきます。