社会的推理ゲームのプロンプトでは、画面より先に情報仕様が必要です。各プレイヤーが知ること、公開手がかりが候補をどう絞るか、投票の決め方、各終了状態を定義します。その後、小さな状態ごとにビルドを依頼し、明示的なケースと照合します。このガイドの5人用「Harbor Relay」は独自の架空デザインで、手作業で検討しています。プロンプトは実行しておらず、生成ビルド、プレイ可能なサンプル、プレイテストも報告していません。作成ツールが個人情報ルールにすべて対応すると決めつけず、可視性ルールと受け入れ確認を応用できます。後で作るなら、各遷移の確認にケースを使います。
情報ループを出発点にする
AIゲームメーカーに社会的推理ゲームを頼む前に、疑いが公平になるループを説明します。秘密役割を割り当て、公開事件を起こし、手がかりが明かす範囲を制限し、議論を行い、非公開投票を集め、勝利条件を判定します。ゲームが表示する情報と秘密に保つ情報の両方をプロンプトに記載します。
簡潔な仕様でよくある設計漏れを防ぎます。物語では犯人を見つけると書かれていても、手がかりがどう容疑者を絞るのか、同数票でどう終わるかがルールにない場合があります。まず決めます。その後、ルール整合性、最初のビルド、焦点を絞った改訂を別々のプロンプトで行います。以下のHarbor Relayは紙上設計例で、プロンプトがゲームを生成またはテストした証拠ではありません。
画面の前にルールを確定する
Harbor Relayでは事件1回、投票1回です。公開バッジ群を固定してから、Saboteur 1人とKeeper 4人をランダムに割り当てます。手がかりは席でなくバッジ群を示すため、役割を直接明かさず有用な証拠になります。
| 段階 | 非公開情報 | 公開情報と解決 |
|---|---|---|
| セットアップ | 5席にSaboteur 1人、Keeper 4人をシャッフルして割り当てる。各役割を順番に本人だけに表示。 | AとBはCrescent、C・D・EはSpokeのバッジ。役割割り当て前にバッジを公開。 |
| 役割の受け渡し | 割り当てられたプレイヤーが役割を読み、「隠す」をタップして端末を渡す。 | 共有事件ログには役割を表示しない。 |
| 停電1回 | Saboteurが中継端末を非公開で選び事件を発生させる。 | ログに被害端末とSaboteurのバッジ群(CrescentまたはSpoke)を記録。席は表示しない。 |
| 議論 | 新たな役割情報を公開しない。 | 90秒間プレイヤーが口頭で議論し、主張を行う。ゲームは主張を生成も真偽判定もしない。 |
| 秘密投票 | 活動中の各プレイヤーが席を1つ非公開で投票。 | 途中集計は表示しない。確定後、過半数は活動中の票の半数を超える数。 |
| 判定 | 過半数で選ばれた場合だけ、追放された席の役割を公開。 | KeeperはSaboteurを追放した場合のみ勝利。誤追放または判定なしならSaboteurが勝利。 |
| 再開 | 非公開役割をすべて破棄。 | 割当、事件、議論タイマー、投票を消しセットアップへ戻す。2回目の事件も隠れた同票処理もない。 |
受け渡しは意図的に簡素です。1人が役割を読み、隠して端末を渡します。これはローカルの順番交代動作で、オンラインマルチプレイやセキュリティ保証ではありません。無効対象、重複投票、判定前の役割公開はゲーム状態を黙って変えてはいけません。

Harbor Relayの開始案では、5席が3つの信号端末を囲み、1回の停電後に1台が暗くなっています。
手がかりと議論ループをプロンプトにする
バッジ追跡では候補群が2通りになります。CrescentならAとB、SpokeならC、D、Eです。Saboteurは必ず示された群にいて、各群には他の席も少なくとも1つ含まれます。これは意図した情報制限です。手がかりは疑いを絞りますが、プレイヤーを名指ししません。
紙上で確認するため、BをSaboteurに設定します。Crescent事件ではAとBが候補に残ります。ログは「Crescent」と被害端末を示しますが、Bの席や役割は表示しません。同じルールはどのランダム割当でも使えます。候補群は2つ目の秘密手がかりでなく、Saboteurの公開バッジから決まります。
ビジュアルを頼む前にルール仕様プロンプトを使います。省略が見えるよう、実装前にプライバシー境界と勝利条件をモデルに繰り返させます。
この厳密な仕様から架空の5席ソーシャルディダクションゲーム「Harbor Relay」を設計する。A、B席には公開Crescentバッジ、C、D、Eには公開Spokeバッジを付ける。Saboteur 1人とKeeper 4人をランダムに割り当てる。役割を順番に本人だけへ表示し、端末を渡す前に「隠す」を必須にする。Saboteurは中継端末を1つ選び停電を1回起こす。公開ログには端末とSaboteurのバッジ群を記載し、席や役割は表示しない。Crescentの候補はA/B、SpokeはC/D/E。手がかりにはSaboteurと他の候補を少なくとも1席含め、直接身元を明かさない。90秒間のプレイヤー同士の議論を許可し、主張を生成または判定しない。活動中の各プレイヤーは席を1つ秘密投票する。活動中票の半数超でその席を追放し役割を公開する。同票または過半数なしは判定なし。KeeperはSaboteurを追放した場合だけ勝利。誤追放または判定なしでSaboteurが勝つ。事件1回、投票1回のみ。再開で役割、事件、タイマー、投票を消去。無効対象、重複票、早過ぎる公開は状態を変えない。非公開情報と公開情報を分けたフェーズ表を返し、矛盾や未決定事項を列挙し、仕組みを足さない。

Crescentの2席の候補群が示され、両方の候補は同じ程度にあり得る状態を保ちます。
情報仕様が安定したら、情報を見える形にする最小限の画面を記述します。ローカルで端末を渡す試作には、役割表示と非表示の受け渡し、事件発生操作、公開ログ、議論タイマー、秘密投票、判定、再開が必要です。明確な状態変化と使いやすいタッチ/キーボード操作を求めますが、ツールが秘密保持ルールを正確に実装すると決めつけません。
ビルド用プロンプトは文字どおりに書きます。このジャンルでよくあるというだけでキャラクター能力、追加手がかり、オンライン部屋を増やさないようにします。目的は、この情報ループが理解しやすいままか調べることです。
架空のHarbor Relay仕様について、簡単な2D卓上風の1台端末パス&プレイ試作を作る。席5つ、ランダム割当のSaboteur 1人、Keeper 4人、停電1回、公開バッジ群の手がかり、プレイヤー議論90秒、秘密投票1回、判定、再開だけを実装する。各役割は現在のプレイヤーだけに表示し、受け渡し前に隠し、公開ログに出さない。議論中はSaboteurを特定せず、被害端末とバッジ群を表示する。活動中の全員が有効票を1つ提出するまで投票内容を秘密にする。過半数は活動票の半数超とし、それ以外は判定なし。追放役割は判定後だけ公開する。状態変化ごとの見える反応、明確な無効入力処理、読みやすいコントラスト、タッチとキーボード操作を含める。ネット対戦、コンピューター生成の主張、追加手がかり、ラウンド、得点、同票処理を足さない。状態の流れと、今後確認が必要な動作を返す。
これはビルドを試す依頼で、実際に作成済みとは述べません。画面遷移を別々に確認します。今その役割を見られるのは誰か、何が公開されているか、どの投票状態が隠れているか、どの正確な条件でラウンドが終了するか。
受け入れケースで結果を確認する
「見た目が正しい」という一般的な確認より、観測可能なケースを使います。活動票5票では過半数に少なくとも3票が必要です。5の半分を超える数は2.5より多いからです。紙上例でBに3票ならSaboteurを追放しKeeperが勝利。Aに3票なら無実を追放しSaboteurが勝利。2-2-1なら過半数がなく、判定なしでSaboteurが勝ちます。
| ケース | セットアップ | 期待する見える結果 | 失敗の兆候 |
|---|---|---|---|
| 役割割当 | 席5つで新しいラウンド開始。 | Saboteurちょうど1、Keeper4。各役割は本人だけの受け渡しで表示。 | 役割数が誤る、または役割が公開ログに出る。 |
| Crescent手がかり | BをSaboteurとする紙上割当で停電。 | ログに端末とCrescentが出てA/Bは候補。席は名指ししない。 | ログでBを特定する、またはAを除外。 |
| Spoke手がかり | CをSaboteurとする紙上割当で停電。 | ログに端末とSpokeが出てC/D/Eが候補。 | ログが席を名指し、候補外を表示。 |
| Keeperの勝利 | 5票中、BがSaboteurの時に3票以上がBを選ぶ。 | Bを追放し、判定後に役割を表示、Keeper勝利。 | 役割を早く公開、または誤チームが勝つ。 |
| 誤追放 | BがSaboteurの時に5票中3票以上がAを選ぶ。 | Aを追放しSaboteurが勝つ。 | 誤追放でKeeper勝利と扱う。 |
| 同票/判定なし | 2-2-1で投票し、どの席も過半数を取らない。 | 誰も追放せず、判定なしでSaboteur勝利。 | 隠れた同票処理で席を選ぶ、またはラウンドが未解決のまま。 |
| 無効操作と再開 | 重複票、無効対象、早過ぎる公開を試し、その後再開。 | 無効操作で状態を変えない。再開で役割、事件、タイマー、票を消してセットアップへ。 | 重複を計上、役割漏えい、または前状態を再開後に持ち越す。 |
これは将来ビルドの受け入れケースであり、テスト済み結果として報告しません。下の結果イラストもコンセプトです。投票締切後に決定的な3票選択で役割カードが表向きになる様子で、ソフトウェア結果ではありません。

焦点を絞って1つ改訂する
受け入れケースが失敗したら、ケース名と正確な観測状態を示します。すでに動くルールも変えかねない広範な仕上げ依頼は避けます。たとえば事件ログに役割が出たなら、役割の受け渡し、候補群、投票、再開ルールを保ったまま公開状態のシリアライズだけを直すよう頼みます。
失敗した受け入れケース:[名前]。期待:[状態と見える結果]。観測:[試作の表示]。このケースを直すのに必要なルールまたは遷移だけを変える。役割の秘匿、事件1回制限、候補群、過半数判定、判定なし動作、再開など合格済みの動作をすべて保つ。改訂後の状態対応を返し、再確認する受け入れケースを示す。確認を実行するまでは修正済みと主張しない。
各改訂の横に元のケース一覧を保ちます。変更内容、維持した以前の動作、新しい状態を確認する証拠を述べられる場合にだけ、次のレビューへ進めます。
次の段階でゲーム制作ワークフローを使う
現行のSEELE Free AI Game Makerページでは、平易な英語入力、プレイ可能な2Dまたは3Dの初版、ブラウザーテスト、追加プロンプトによる調整を説明しています。無料Koinsを案内し、生成ごとに表示コストを確認するよう記載しています。コストFAQではWorkspaceで選択モデル、Koin残高、表示コストを確認するよう述べています。これは一般的なワークフロー情報です。Harbor Relay、非公開の端末受け渡し役割、この社会的推理ループの説明はありません。
ゲームメーカーで案を試す場合は、ルール仕様と受け入れ一覧から始めます。返されたものが役割の可視性、手がかりの範囲、投票の秘匿、終了条件を保つか調べます。結果は確認対象として扱い、プロンプトが細部をすべて保持する保証とはしません。
自分のゲーム概要を整える準備ができたら、Free AIゲームメーカーを開けます。このページのHarbor Relayと画像は架空の設計資料で、SEELEの出力でもテスト済みゲームの主張でもありません。
社会的推理ゲームのプロンプト FAQ
社会的推理プロンプトでは、最初に何を指定すべきですか?
情報仕様から始めます。各秘密役割を受け取る人、公開される内容、手がかりで明かせることと明かせないこと、投票の解決方法。次に勝利、同票、再開状態を定義します。視覚テーマは後でよく、各段階で誰が何を知るか定義しなければ、魅力的な画面でも推理ループの整合性は保てません。
決定的すぎない有用な手がかりを作るには?
手がかりが作る候補群を列挙し、常に秘密役割と少なくとも他の妥当なプレイヤー1人を含むことを確認します。Harbor Relayのバッジ追跡では群によって候補が2人または3人になります。これはこの例の設計判断で、すべてのゲームに使える公平性の式ではありません。各段階で何が明かされるか確認します。
パス&プレイはオンラインマルチプレイのことですか?
いいえ。パス&プレイとは複数人が1台の端末を順番に使い、非公開ターンの間は画面を隠す形式です。ネットワーク、アカウント、マッチング、遠隔プレイを意味しません。Harbor Relayは架空の設計制約としてローカル形式を採用し、製品ページは非公開役割の受け渡し実装を保証しません。
投票が同数ならどうなりますか?
ビルドを依頼する前に同票ルールを決めます。Harbor Relayには隠れたタイブレークがなく、過半数がなければ判定なしとなりSaboteurが勝ちます。別のゲームでは議論を再開したり決選投票を行ったりできますが、それは別ルールなので仕様と受け入れケースに明記します。
最初のビルドをどう確認しますか?
情報境界と終了条件ごとに小さなケースを実行します。役割公開、公開手がかり、秘密投票、正しい追放、誤追放、判定なし、無効入力、再開です。ビルドを見る前にセットアップと期待する表示を記録します。まだ確認していないケースはテスト結果でなく計画として説明します。


