AIに長時間ゲームを目隠し試遊させて分かった、減らしてよい手間と残すべき品質

AIに長時間ゲームを初見で遊ばせる試みで、開発者が最初にぶつかったのは、プレイヤーの性能より周りの運用の重さだった。ブラウザゲームならAIがChromeを操作して遊べるはずだが、数時間かかる作品を動かすと、親エージェントの進捗確認、同じ画面の取り直し、途中での環境切り替え、文脈の肥大化が重なり、CodexやClaude Codeの使用量が一気に削られていった。そこで筆者は、プレイヤーには凍結ビルドのURLと画面上で使える操作だけを渡し、ソースや設計書、正解データは見せない「目隠し試遊」という形に絞った。環境の検査はプレイヤーを起動する前に別工程として済ませ、検査に使ったプロファイルは本番に流用しない。 この記事が面白いのは、「AIにどこまで賢く遊ばせるか」ではなく「どこを減らしてよいか」を問い直している点だ。E2Eテストなら内部状態を直接いじって目的の画面へ飛ばすのが定石だが、初見の試遊では「説明を読んで操作に気づけるか」こそが測りたいものになる。ショートカットを使った瞬間に、測るべき品質が消える。つまり手間を減らしてよいのは観察の外側だけで、プレイヤーが読んで考える部分は一行も削ってはいけない。この線引きを誤り、AIのテストを効率化したつもりで検証力を失う人は多いはずだ。 社内の業務システムや社内向けWebツールを、AIに実際の画面操作で試させる場面にも、この考え方はそのまま使える。まず、動作確認の環境チェックは本番の試験の前に別工程として済ませること。次に、試験に使うプロファイルは検査で使ったものを流用せず、毎回まっさらな状態で始めること。そして、一度見た画面は差分だけ追うこと。試験は一つのAIに任せきりで回し、途中で口を挟まないほうが、結果は信頼できる。