Zero Noichiが10体のエージェントによるAI人狼ゲームを構築した方法

野市 零 / Zero Noichiは、10個のAIエージェントが1つの人狼ゲームを共有すると何が起こるかを示しています。課題はもはや気の利いた返答を生成することではなく、会話を機械的に感じさせずに、声、役割、記憶、タイミング、対立を調整することです。

この記事では、元のAI人狼動画で実験を記録した野市 零 / Zero Noichiに感謝します。この動画はエンターテインメント目的の実験として紹介されていますが、信頼できるマルチエージェントアプリケーションの背後にあるエンジニアリング上の問題も明らかにしています。つまり、エージェントを1つの共有世界の一員として、待機させ、割り込ませ、記憶させ、欺かせ、反応させる方法です。

コラボレーションに関する開示： 元の説明では、ZimaBoard 2、クリエイター向けクーポン、アフィリエイトリンク、そして実験で使用したソフトウェアサービスについて言及しています。クリエイターは自身の実装と意図した使用方法を共有しています。モデルのバージョン、音声サービス、インターフェース、ハードウェアバンドル、互換性は、公開後に変更される可能性があります。

結果： ZimaBoard 2 - ミニホームサーバー は、10個の最先端モデルをフルスピードで実行する大規模な推論クラスターの代替ではありません。より現実的な強みは、AIアプリケーション向けのコンパクトで常時稼働する制御・サービスノードとして機能することです。プロンプト、ゲーム状態、API、オーディオパイプライン、ログ、ネットワークアクセスを調整しながら、より負荷の高いモデル処理を適したサービスまたはコンピュートパスに割り当てられます。

このプロジェクトを理解するには、階層化されたシステムとして捉えるのが有効です。言語モデルが意思決定と対話を担い、オーケストレーション層が誰の番かを決め、状態層が各キャラクターの知識を管理し、音声層がテキストを音声に変換し、プレゼンテーション層がその結果を視聴者に分かりやすく伝えます。これらの層のどれか1つでも取り除けば、「賢い」エージェントが10個あっても、すぐに接続されていない10個のチャットウィンドウになってしまいます。

難しいのはエージェントの数ではなく、共有された現実

会話に2つ目のモデルを追加するのは、同じルールに従わなければならない2つ目のモデルを追加することに比べれば簡単です。人狼ゲームでは、各キャラクターに非公開の役割、公開された履歴、他のプレイヤーに対する信念、そして現在のフェーズで許可された行動の一覧が必要です。そのためアプリケーションには、各モデルがそれぞれ独自の出来事を作り出すのではなく、ゲーム状態を一元的に管理する唯一の信頼できる情報源が必要になります。

堅牢な設計では、公開状態と非公開状態を分離します。公開状態には、現在の日数、発言された主張、投票、脱落したプレイヤーなどを含められます。非公開状態には、人狼の仲間、予言者の結果、キャラクターが隠し持つ疑念などを含められます。オーケストレーターは、すべての秘密を全員に配信するのではなく、エージェントごとに異なるコンテキストを構築します。

この分離によって、デバッグも可能になります。エージェントが疑わしい告発をした場合、開発者は、その発言を生み出した公開トランスクリプト、非公開メモリ、役割プロンプト、モデルの応答を正確に確認できます。こうした境界がなければ、「知性」に見えるものが、実はあるプロンプトから別のプロンプトへ偶然情報が漏れただけかもしれません。

キャラクタープロンプトに必要なのは性格を表す形容詞だけではない

あるエージェントを「自信家」、別のエージェントを「無口」と呼ぶだけでは、キャストは作れません。役立つキャラクター定義には、話し方、リスク許容度、目標、役割に応じた知識の範囲、そして証拠によって信念をどう変えるかというルールが含まれます。キャラクターはそれぞれ異なる話し方をするだけでなく、ターンをまたいで一貫した理由に基づいて意思決定する必要があります。

各エージェントには、名前、役割、公的なペルソナ、非公開の目的、既知の事実、現在の疑念、過去の出来事に関する簡潔なメモリを含む、構造化されたプロフィールが役立ちます。これにより、プロンプトでは内部的な判断と視聴者向けの発言の両方を求めつつ、アプリケーション側では次の状態遷移に必要なフィールドだけを保存できます。ゲームが進行しても、コンテキストを読みやすく保てます。

ここには重要な境界があります。プロンプトを長くしたからといって、より深みのあるキャラクターが自動的に生まれるわけではありません。毎ターン、会話の全文とすべての指示を繰り返せば、レイテンシーとコストは増大しますが、モデルに明確な状態遷移が備わるわけではありません。情報を無選別に詰め込んだ会話ログよりも、厳選して小さくまとめたメモリのほうが、一貫した挙動を生み出すことがよくあります。

モデル選択がゲームのリズムを変える

この動画では、「AI」を交換可能な単一のコンポーネントとして扱うのではなく、実験の一部としてLLMモデルの選択に焦点を当てています。プロジェクトでは、言語モデルのコンポーネントとしてMoonshot Kimi K3が選ばれており、この選択は回答の品質だけでなく、応答の長さ、レイテンシ、拒否の振る舞い、言語スタイル、ターン間で保持できるコンテキスト量にも影響します。

実用的なアーキテクチャでは、異なるモデルに異なる役割を割り当てられます。より高性能なモデルが難しい非公開の推理を担当する一方で、より高速なモデルが短い社会的反応やナレーションを生成できます。重要なルールは、ゲームの契約をモデルの外部に置くことです。モデルは行動を提案できますが、その行動が合法かどうかを状態に適用する前にサーバーが検証すべきです。

リモートモデルAPIは、プライバシーと信頼性の境界も変えます。ゲームが非公開の役職情報を外部サービスに送信するなら、そのサービスは信頼モデルの一部になります。ネットワーク障害、レート制限、APIの変更によって、ローカルデバイスが正常でもゲームが一時停止する可能性があります。プロンプトをキャッシュし、べき等なリクエストを再試行し、リクエストIDを記録しておくと、実験を再開しやすくなり、状況も説明しやすくなります。

自然な会話にはターンテイキングエンジンが必要

10人のエージェントが固定キューで話すだけでは、スプレッドシートに管理された電話会議のように聞こえてしまいます。より説得力のある振る舞いを生むのは、キャラクターが話してよいタイミング、割り込みが許可されるタイミング、そして卓を投票や夜の行動へ進めるべきタイミングを把握する、明示的なターンテイキングエンジンです。

有用なパターンの一つは、導入、自由討論、対象への応答、投票、夜の行動、結果といったフェーズを持つステートマシンです。討論フェーズでは、スケジューラーが公平性、関連性、疑惑、制御されたランダム性を組み合わせて次の発言者を選べます。キャラクターは割り込みを要求できますが、その要求が有効かどうか、またキューにどのような影響を与えるかはエンジンが判断します。

これが、「リアルな音声」が単なる音声合成以上のものである理由です。システムは、いつ音声を開始するか、現在の発話を途中で遮ってよいか、応答をどのようにキューに入れるか、音声リクエストが失敗した場合にどうするかを判断しなければなりません。テキストに関する判断と音声再生を明確に分離しておけば、音声プロバイダーの応答が遅い場合でもゲームを続行できます。

音声は社会的な合図を加える――新たな失敗モード

音声による対話は、視聴者がエージェントを評価する方法を変えます。間、相づち、割り込み、声の個性の違いによって、短い応答でもライブの卓上会話の一部のように感じられます。この動画では、音声レイヤーにFish Audioを使用しています。これは構造的な役割を果たし、状態の遷移を人間がリアルタイムで追えるイベントへと変換します。

音声は、テキストでは隠れてしまうバグを明らかにすることもあります。遅延した音声合成リクエストによって、ゲームがすでに別のフェーズへ進んだ後にキャラクターが話し始める可能性があります。生成された回答が長いとキューを塞ぎ、控えめなエージェントの存在が消えてしまうこともあります。そのためアプリケーションは、すべての音声クリップをゲームイベントとフェーズに関連付け、古いクリップを文脈外で再生する代わりに破棄できるようにすべきです。

音声の同一性にも一貫性のポリシーが必要です。ターンごとにキャラクターの声が変わると、視聴者は技術的な障害を新しいキャラクターの登場だと受け取るかもしれません。音声の割り当てをモデルのプロンプト内ではなく設定に保持することで、プレゼンテーション層の予測可能性が高まり、置き換えも容易になります。

ゲームループにはサーバー側の信頼できる情報源が必要

ライブゲーム中、システムはチャットメッセージ以上のものを調整する必要があります。誰が生存しているか、現在どのフェーズか、どのアクションがまだ合法か、各キャラクターが何を聞いているか、そして結果がいつ確定するかを把握しなければなりません。これらの事実はアプリケーション層に属するものであり、エージェントの自由形式の応答に任せるものではありません。

適切なイベント記録には、フェーズ、発言者、表示テキスト、非公開アクション、使用モデル、リクエストの状態、結果として得られた状態のバージョンなどを含めるとよいでしょう。この構造はリプレイを支援します。同じイベントからプレゼンテーションを再実行できるため、すべてのモデルにゲーム全体を再生成させる必要がありません。また、同じシナリオで2つのモデル構成を比較しやすくなります。

リプレイは、自然発生的に見えるプロジェクトで特に価値を発揮します。キャラクターが説得力のある推理によって勝利した場合、開発者はその結果が役割設計によるものなのか、モデルの偶然の応答によるものなのか、秘密の漏洩によるものなのか、あるいはスケジュールのずれによるものなのかを確認できます。可観測性によって、面白いデモを実際に改善できるシステムへと変えられます。

ZimaBoard 2がアーキテクチャのどこに位置付けられるか

ZimaBoard 2は、このシステムの常時稼働するエッジ部分に配置するのが最も適しています。この位置付けは、より広範なZimaBoard 2のローカルAIアシスタント構成とも一致します。ボードは、コーディネーター、小規模なデータベース、ダッシュボード、Webhookサービス、音声キュー、コンテナ化された補助コンポーネントをホストしながら、外部のモデルAPIや音声APIに安定して接続できます。この役割では、多数のCPUコアよりも、低消費電力、コンパクトな設置面積、ネットワーク接続性のほうが重要です。

ボード上で特定のモデルをローカル実行できるかどうかは、モデルのサイズ、量子化、メモリ、アクセラレーション、そして体験に必要なレイテンシによって決まります。そのため、別記事のZero NoichiのZimaBoard 2およびAMD MI50構成は有用な比較対象です。追加のGPUコンピュートによって推論経路が変わる一方で、ボードは安定したホストおよびサービス層を提供できます。安全な計画の原則は、オーケストレーションと推論を分離することです。つまり、状態エンジンが、モデルのエンドポイントをローカルサービス、別のマシン、ホスト型APIの間で移動させた場合でも役立つようにアプリケーションを設計します。

ダイレクトストレージと拡張機能は、ログ、プロンプトのバージョン、キャッシュされた音声、ゲームのリプレイの保存にも役立ちます。これらのファイルはモデルそのものではありませんが、システムがどのように動作したかを理解するために必要な証拠です。プロジェクトを再現可能な状態で維持できる小型サーバーのほうが、印象的なデモを一度だけ生成する高速なデバイスより価値がある場合があります。

マルチエージェントAIのライブ結果から分かること

この実験の魅力は、エージェントが社会的な意図を持っているように見える点です。エージェントは互いに割り込み、自己弁護し、他者を疑い、不完全な情報をもとに協調します。技術的には、こうした行動はロールプロンプト、非公開コンテキスト、状態遷移、スケジューラーの相互作用から生まれます。1つのモデル応答だけでは、この体験全体を説明できません。

この違いは、ローカルAIアプリケーションを構築する人にとって重要です。エージェントの数を増やせば、必ずしも知能が高まるわけではありません。エージェントが増えると、調整コスト、コンテキスト管理、障害が発生する範囲、可観測性の要件が増大します。状態の境界を明確にした少人数のグループのほうが、ルールを忘れる大人数のグループよりも、説得力のある結果を生み出せることがあります。

このプロジェクトは、レイテンシーが製品上の意思決定でもある理由を示しています。ターン制の推理ゲームでは、遅くても思慮深い回答なら許容されるかもしれませんが、短い確認や割り込みの場面では、同じ遅延が不具合のように感じられます。したがってスケジューラーは、すべてのメッセージを同じように扱うのではなく、イベントの重要度に応じてモデルの処理量と音声の長さを調整するべきです。

制作全体をコピーせずにアイデアを再現する方法

まずは3つのエージェントと、シンプルな1つの秘密役職ルールから始めましょう。音声を追加する前に、イベントログ、ステートマシン、プライベート／パブリックコンテキストの分離を構築します。テキストのみのループで、情報を漏らさずにラウンド全体を再生できるようになったら、音声プロバイダーを1つだけ追加し、インタラクションのどこで実際に遅さを感じるのかを測定します。

次に、設定を明示的にしましょう。キャラクタープロファイル、役割ルール、モデルのルート、音声の割り当て、リトライポリシーをプロンプト本文の外に保存します。これにより、一度きりのデモが、すべてのエージェントを書き直さずに調整できるシステムへと変わります。また、ハードウェアノードの役割も明確になります。推論バックエンドを交換可能なまま、サービス、設定、証拠をまとめて保持するのです。同じ分離は、より広範なローカルAIサーバーの構築にも役立ちます。ランタイムと補助サービスは、それぞれ異なる速度で進化する可能性があるためです。

最後に、正常系だけでなく障害もテストしましょう。1つのモデルリクエストを停止し、1つの音声クリップを遅延させ、プレイヤーを1人削除し、コーディネーターを再起動して、同じイベントログを再生します。説得力のあるマルチエージェントアプリケーションは、最高の会話だけで決まるものではありません。ゲームの途中でルールを変えずに、システムが復旧できるかどうかで決まります。

オーケストレーションと補助サービスをホストできる、コンパクトなホームサーバープラットフォームをお探しなら、ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバーをご覧ください。他のビルダーとアイデアを共有するには、ZimaSpace Discordコミュニティに参加しましょう。