作品を知らない AI に、窓口の 4 つの道具だけを渡して遊ばせる。結果は版と一緒に記録する
Letting an AI that doesn't know the game play it with only four tools, and recording the result with the version
D24-4-T48-ai-blind-playtest・技術・日本語入力でプレイする仕組み
人が遊ぶ前に、AI のプレイヤー 3 人に初見で全三章を遊ばせ、全員がクリアできるかを確かめています。
プレイヤー役は作品を知らない別のプロセスで、ゲームにつながる 4 つの道具しか持たず、作り手のリポジトリにも会話にも届きません。
T47 で書いた「探索的テストは版に縛る」の、その探索的テストの中身の回です。
遊ばせる AI は、ゲームの返事を作りません。ゲームの返事は書き下ろしの台本から選ばれるだけで（T18）、AI は遊ぶ側に座るだけです。
採点の話は明日の T49 に回します。
この回の位置と、前後の回#
区切り: T34〜T49 確かめ方（16 回のうち 15 回目）
先に読むとよい回: T47（合格の証拠を測った版に縛る）・T18（返事は選ぶだけ）
次に読む回: T49（AI に採点させる距離）
名前 — playtesting by LLM agents#
- いちばん近い名前
- playtesting by LLM agents（LLM エージェントによるプレイテスト）・automated playtesting（自動プレイテスト）
- 日本語での呼び名
- AI に初見で遊ばせる、AI 初見プレイ（うちの呼び名）
- 初出
- この呼び名の初出は確かめられませんでした。近年の例として、
- Chang Xiao, Brenda Z. Yang, "LLMs May Not Be Human-Level Players, But They Can Be Testers: Measuring Game Difficulty with LLM Agents"（arXiv:2410.02829, 2024）。Wordle と Slay the Spire で、LLM の成績が人の感じる難しさと強く相関した、と報告しています
- Yan Zhao, Chiawei Tang, "Towards LLM-Based Automatic Playtest"（FSE Companion '25）
があります（どちらも書誌と要旨だけを確かめ、本文は読んでいません）。
回し方の語彙: session-based test management（SBTM）。charter（その回の任務）・session（時間を区切った 1 回の探索）・debrief（終わった後の報告）。Jonathan Bach と James Bach（2000）に帰されますが、掲載先は確かめられませんでした。
窓口の作り: Model Context Protocol（MCP）の stdio の server。
一般の解説 — playtesting by LLM agents#
playtesting by LLM agents（LLM エージェントによるプレイテスト）とは、LLM のエージェントにプレイヤーの代わりをさせて、詰まる所・分からない所・壊れた所を見つけるプレイテストです。
プレイテストは、遊んでもらって、詰まる所・分からない所・壊れた所を見つけることです。人を集めるのは高く、遅く、同じ人は二度と初見になれません。
自動のプレイテストは、昔からスクリプトや探索、強化学習のエージェントで行われてきました。ただ、それらは決まった操作の空間を探るのが得意で、「何をすればよいか」を文章から読み取るゲームは苦手でした。
LLM のエージェントは、文章を読んで、次に何をするかを文章で決められます。
テキストのゲームや、言葉で指示を出すゲームでは、プレイヤーの代わりにしやすい相手です。
よく使われる測り方:
- クリアできたか・何手かかったか（難しさの代わり）
- どこで止まったか（詰まりの場所）
- 何を試したか（プレイヤーが思いつく言い方の分布）
よく知られた弱点:
- AI は人ではない。粘り方・諦め方・読む速さ・思いつく言い方が違う。AI の難しさは人の難しさの代わりでしかない
- 同じ AI を同じ依頼文で回しても、同じ手は出ない（生成は再現しない）
- 作り手の文脈が入ると、初見でなくなる（答えを知っている）
- AI に「感想」を書かせると、それらしい文が出るが、遊んだ内容と結びついているかは別
うちの回し方: 遊ぶ側と作る側を分ける#
規約の第一は、作っているセッションは遊ばない、です。手順書にこうあります。
このセッション自身は遊ばない。実装や設計文書を読んだ文脈が残っていると「ひらめきが自分のもの」は原理的に測れない。
最初は、作り手のセッションから文脈を持たないサブエージェントを起こして遊ばせていました。
それでも漏れました。汎用のエージェントにはスキルの一覧が見えていて、比較の試しでは 3 人中 2 人が、遊び方の手順書（このスキル）を読み、1 人はテストのサマリのスクリプトまで実行しました（2026-09-30 の記録）。そこで、使える道具を絞った専用のエージェントに替えました。
いまの正式な経路は、作り手の会話の外に、独立したプロセスを 3 つ起こす形です（2026-10-07 から）。
pwsh Scripts/adv-blind-playtest.ps1 -Work Game/adv -Id 第N回 [-Model sonnet|haiku]
依頼文の組み立て・3 本の同時起動・記録・質問票の回収までを、この 1 コマンドで行います。
窓口: 4 つの道具だけ#
プレイヤー役が使えるのは、窓口（Tools/adv-player-gateway/）の道具 4 つだけです。窓口は MCP の stdio の server で、運営が起動するときに作品・セッション・ゲームの核を固定します。
// adv-player-gateway — 初見プレイヤー役（独立した Claude Code プロセス）に渡す唯一の窓口（MCP stdio）。
// 運営が起動時に作品・セッション・バックエンドを固定する。プレイヤーに見せるのは 4 つのツールだけ:
// action … 1 手（say / move / talk）。requestId と expectedRevision が必須（冪等・直列）
// state … いまの公開状態（場所・相手・行ける場所・会える人・直近の本文）
// notebook … 手帳と推理記録（公開の見出しだけ）
// report … 感想・迷った箇所の記録（運営のファイルへ。進行・判定は変えない）
//
// **プレイヤーへ渡すのは BuildPublicPlayerView（コアの許可リスト）の結果だけ。** save・eval・内部ログ・
// 意図 id・フラグ・スコア・パス・スタックはゲートウェイが保持し、ツールの応答にも誤りの文にも出さない。
// resources / prompts は空。汎用のファイル取得・URL・git・debug・任意セッション指定は無い。
1 手の道具の定義はこうです（写す。説明の文は省きます）。
{
name: 'action',
inputSchema: {
type: 'object', additionalProperties: false,
required: ['requestId', 'expectedRevision', 'kind'],
properties: {
requestId: { type: 'string', minLength: 1, maxLength: 80 },
expectedRevision: { type: 'integer', minimum: 0 },
kind: { type: 'string', enum: ['say', 'move', 'talk'] },
text: { type: 'string', maxLength: 400 },
target: { type: 'string', maxLength: 16 },
},
},
},
- say は、自分の言葉で話す文。人が入力欄に入れる日本語と同じものです
- move は行き先、talk は話し相手。どちらも state が返した id から選ぶ
- requestId は手ごとに新しい文字列。同じ requestId を送り直すと、同じ結果が返り、二重には進まない（idempotency key）
- expectedRevision は直前の応答の revision。古い状態のつもりで送った手は通らない（楽観的な排他）
プレイヤーに返るのは、人の画面と同じ公開の応答だけです。意図の id もフラグも点数も見えません。
説明の文にも作品の語を入れない決まりで、道具の定義は全部の作品で共通です。
窓口の側は、運営だけが見る場所に、手ごとの記録（入力・公開の応答・運営用の解釈・時刻・前の行のハッシュ）を書きます。
チャーター: 依頼文は機械で組む#
プレイヤーは 3 人で、話し方の違う型を割り当てます。
| 型 | 何を測るか |
|---|---|
| 総当たり派 | 物量の不足・繰り返しの仕組み・僅差の取り違え |
| せっかち | 詰まりの理不尽さ・救済の質・推理の決定の受け皿 |
| 慎重派 | 材料の条件・突きつけの成立 |
依頼文は、人が組みません。スクリプト（Scripts/adv-playtest-prompt.ps1）が型ごとのファイルを作り、それを一字も変えずに渡します。
頭の注記に理由があります。2026-08-24 の第16回で、親のセッションが慎重派のぶんを手で言い換えて渡し、ロシア語の単語が混ざりました。規約を書いた当日に、書いた本人が破っています。それで、規約で守るのをやめて、機械で守ることにしました。
依頼文の共通の部分は、こう始まります。
あなたはアドベンチャーゲームを初めて遊ぶプレイヤーです。開発には関わっていません。
使える道具は、ゲームにつながる 4 つのツールだけです。
遊び方の説明は、画面の操作説明と同じことだけを書きます。選択肢がないこと、聞きたいこと・調べたいこと・推理を日本語の文で送ること、決まった言い回しがないこと、聞き返されたら「はい」か「違う」で答えてよいこと。
見せる手がかりの条件は、二つの引数で決めます。焦点（いま何が分かっていないか）と助言です。既定はどちらも見せない、つまり人の画面と同じです。合格を測るのは、この既定の条件（none）の回だけです。手帳の表示をヒントつきで始めた回は、条件の名前に +notes が付き、合否には数えません。
依頼文を途中で変えたときは、手順書にその回の番号と理由を書き残します（例: 第79回から、否定の言い方を使わない・聞き返しには一言で答える、という約束の節を足した）。回どうしの手数を比べるときに、条件が違うことが分かるようにするためです。
記録: 版と一緒に#
回を始めるとき、セッションごとに開始記録（*.start.json）を書きます（T47）。commit・テスト対象の中身の指紋・シミュレータの実行ファイルの指紋・合格基準の指紋・焼いたベクトルと読んだ全ファイルの指紋、そして見せる条件です。
終わったら、記録のコマンドがこれを照合します。
.\Scripts\adv-exploratory-test.ps1 -Record -Id 第N回 -Sessions <a>,<b>,<c> -PersonaNames 総当たり派,慎重派,せっかち
- 3 本が同じ版で始まっていること
- 始めたときにテスト対象が汚れていない（未コミットの変更が無い）こと
- 今の版と、シミュレータと合格基準が同じであること
どれかが違えば、記録を拒否します。版は開始記録のもので、記録したときの HEAD ではありません。
ログを日付のフォルダへ移し、回の記録（cycle.json）を書き、判定のコーパスを同じフォルダへ向けます。JSON を手で編集しない決まりです。
利用の上限などで途中で止まったプレイは、「クリアできなかった」と数えません。実行未完了（INCOMPLETE）として理由ごと記録し、同じ版のまま続きから遊ばせます。窓口は、記録した手を頭から流し直して、記録した公開の応答と一字でも違えば起動しません。別の版で続けないためです。
再現できるもの、できないもの#
記録の仕様書は、再現を二つに分けています。
保存した操作列を同じゲーム版で流し、ゲームの判定と表示を比較することはできる。一方、生成AIにもう一度考えさせて同じ発話を生成する保証はできない。
ゲームの側は決定論なので（T23）、記録した入力の列を同じ版に流せば、同じ応答が返ります。翌日の採点（T49）は、これを使っています。
AI の側は再現しません。同じ依頼文・同じモデルでも、次の回は別の手を出します。なので、1 回の結果ではなく、3 人そろってのクリアを、回を重ねて見ます。
仕様書は、記録の確かさを 3 段で表示します。replayable（開始・生・終了の記録と、版の実体がそろい、流し直しが一致した）・recorded（生ログは完結しているが、開始の版が欠ける）・incomplete（途中で止まった）。
今日の数（記録から）#
今日は回していません。回すと時間と費用がかかるからです。数はどれも記録の値です。
最後に記録した回は、第84回（2026-10-10・条件 none・プレイヤー役は Sonnet）です。記録のフォルダのログに、今日の adv-sim の集計を掛けました。
| 型 | 結果 | 発話 | 移動 | 話しかけ | 通じなかった手 |
|---|---|---|---|---|---|
| 総当たり派 | クリア | 230 | 91 | 7 | 4（1.7%） |
| 慎重派 | クリア | 220 | 83 | 7 | 6（2.7%） |
| せっかち | クリア | 202 | 91 | 9 | 7（3.5%） |
3 本とも、独立の経路の点検が通った印（isolation: verified）が付いています。
通じなかった手は、シミュレータの集計の定義のままで、判定が受け流し（F4。T17）になった発話の数です。聞き返し（F1）や誘導（F2）は、ここには数えていません。
回の履歴は、この設定ファイルに 47 回あります（第38回〜第84回）。最後の 8 回は、第77回 PASS・第78回 FAIL・第79〜84回 PASS で、条件はどれも none です。2026-10-10 の引継ぎの記録にも「第79〜84回の 6 回続けて、3 人全員がクリアして合格」とあります。
合否は条件だけで決める#
合格の条件は、設定ファイルの criteria にあります。今は「3 ペルソナ全員がクリアする」です（打ち切りの目安は作品の前口上の設定）。
手順書は、ペルソナにも親のセッションにも、等級を付けさせないと決めています。
合否は criteria だけ。ペルソナにも親にも等級を付けさせない。質問票・事実確認は観察の入力であって判定ではない。
緑と出たものを感想で赤にしない。ログを手で grep して判定しない。
プレイヤーの最後の報告（何が起きたか・進めなかった所・JSON の質問票）は、欠陥を見つける材料です。合否には入りません。
名前どおりでない所 — playtesting by LLM agents#
目的が違います。ふつうのプレイテストは、遊びの感想を集めて設計を直すためのものです。うちの AI 初見プレイは、テスト計画の探索的テスト（L1）の一部で、合否は「全員がクリアしたか」だけです。面白さ・印象・好悪は、測りはしても合否から外しています。
プレイヤーも違います。人ではなく、話し方の型を割り当てた AI です。難しさは「この AI が、この条件でクリアできるか」で、人の難しさの代わりでしかありません。人のスモーク（L3）と体験版（L4）は、別の行として台帳に残っています（T47）。
弱点と、採らなかった案 — playtesting by LLM agents#
- AI の粘り方は、モデルで変わります。Haiku に替えた回では、目安の手数より前に自分でやめることが多く、依頼文の言い方を変えても効かなかったので戻した、という記録があります
- 依頼文の一字が結果を変えます。なので変えたら回の番号と理由を残しますが、変える前後の回は、厳密には比べられません
- AI が人より正確に読むと、人が詰まる所を素通りします。逆に、人なら流す所で詰まることもあります
- 3 人は少ない数です。1 人の偶然で FAIL になり、1 回の PASS は偶然かもしれない。回を重ねて見るしかありません
採らなかった案:
- 作り手のセッションに遊ばせる。早くて安いが、答えを知っている
- 決まった手順のボットや状態の全探索で代える。全部の状態を歩く仕事は reach（T36）がしています。「日本語の文を自分で考えて送る」のは、生成のできる相手でないと代われません
- AI に面白さを採点させて合否に入れる。それが明日の話です
検索語#
LLM agents playtesting game difficulty
automated playtesting large language model
session-based test management charter debrief
Model Context Protocol tools idempotency key
AI の 3 人が解いた『霧走町 流氷に眠る』の第一章を、人の言葉で解いてみてください。ブラウザで無料で遊べます。プロフィールのリンクから。