スマホ 1 台を回して 3〜8 人で遊ぶパーティーゲームのサイト mawashite.com を 1 人で作っていて、執筆時点 (2026-08-04) でゲームを 10 本出しています。人間のテスターは実質 1 人 (自分) しかいないので、お題デッキの面白さ評価・配色の選定・実装後の通しレビューまで、AI に 6 人のペルソナを演じさせたレビューパネルに判断の大半を委任してきました。人間 (僕) が直接判断する場面は、仕様の承認とマージの承認の 2 つだけに絞っています。

この委任がうまく回っているのは、人間のレビュー組織が使う手法──盲検・役割分離・現物主義・あとから覆せる記録──を、AI パネルの運用ルールにそのまま移植したからだと考えています。ただし、委任は、委任先が壊れたことを検出できて初めて委任であり、パネルが合格判定を出したこと自体は品質を保証しません。

対象読者は、レビューや承認のような判断プロセスを AI へ委任することを検討している個人開発者やチームです。

人間の承認ゲートは 2 つだけ

人間 (僕) が直接判断するのは仕様の承認とマージの承認の 2 つだけで、それ以外——お題デッキの出来、テーマカラー、文言、UX、レビュー同士で意見が割れたときの裁定——は、僕に聞く前に必ずパネルに現物を見せて採点させ、AI が根拠つきで決めます。ただし委任と独裁は違うので、決定と根拠は必ず issue / PR に記録して、あとから僕が覆せる形にしてあります。

パネルはターゲット層別の 6 人で固定です: 大学生 (飲み会)、ボードゲーム好き、デザイン感度の高い社会人、中学生 (学校の休み時間)、40 代の幹事、高校生 (放課後の集まり)。それぞれを、指示を渡すと独立して動く AI の実行単位であるサブエージェントとして並列に起動します。プロンプトの骨子はこれだけです。

あなたは <人物設定: 年齢・立場・ゲーム経験>。
<利用シーン: どんな場で、誰と遊ぶ想定か>
評価対象: <現物のパス (HTML / JSON / スクリーンショット)> を必ず読むこと。
評価観点: <楽しさ / 分かりやすさ / シーン適合> を 10 点満点で。
返答形式: 点数、良い点、blocker (出荷を止めるべき問題)、改善案。

運用ルールは 3 つあります。現物を Read させること (要約を渡すと指摘が一般論になります)。再レビューは同じエージェントを再開して前回との差分を言わせること——ただし文脈を引き継ぐのは同一対象の前後比較だけで、別の対象どうしを比べる採点は毎回まっさらな盲検にします (理由は後述します)。そしてスクリーンショットは毎回撮り直すこと。古い画像を渡すと、修正済みの指摘が混ざります。

いまの 6 人に固まるまでには、一度だけ入れ替えがありました。学校シーンの評価では当初教師ペルソナを置いていましたが、管理者視点 (秩序・教育的配慮) が混ざると中高生の楽しさの採点がにごるため、中学生・高校生のペルソナに置き換えています。誰の体験を測りたいのかでパネルを組み、別の関心事は別のレビューに逃がす——コードレビューにセキュリティ観点を混ぜず別ジョブに切り出すのと同じ発想です。学校で使える健全性は、お題 (語彙セット) の内容を対象にした別のレビューが担保しています。

自分の桃色推しは、3 つのゲームで 3 回落ちた

委任の実感がいちばんあったのは配色です。きもちバレ (セリフに秘密の感情を込めて演じ、聞き手がどの感情だったかを当てる演技ゲーム) のテーマ色で、僕は桃色系の案を推していました。パネルに 3 案を見せた結果は 1 位票 A=0 / B=4 / C=2 で、僕の推した桃色案は 0 票。却下理由は「性別コードされたピンク (6 人中 5 人が指摘)」と、コントラスト比の実測不足でした。乗り換えました。

その後も僕は懲りずに桃色系を出し続け、せーのドン (4 択の答えと「みんなの最多はどれか」を同時に当てる多数派予想ゲーム) では「職場の懇親会や男子だけの飲み会で甘く見えて浮く」と 6 人中 4 人が同じ指摘をして 1 位票ゼロ、けたちがい (こっそり入力した数字を、誰の答えか伏せて昇順に並べて当てっこする数字当てゲーム) では「恋バナ系に見える」「男友達とやる時に気恥ずかしい」と指摘され、10 本目にして 3 度目の「場を選ぶ」という却下でした——3 ゲームで 3 回、毎回ほぼ同じ理由で落ちています。

ここから言えるのは「パネルは一貫して桃色案を落とす」ことと、その理由が収束していることまでで、その判断が正しいか (実際の男子グループの卓で本当に気恥ずかしいか) は、人間では未検証です。ただ、自分では気づけない「好みの癖」が自分にあることを教えてくれる装置としては、これで十分に機能しています。

fix-first: 指摘を直してから ship 判定させる

実装後の通しレビューは「fix-first」というやり方で回します。6 人に画面遷移の現物を読ませ、出た指摘を先に直してから、直した現物でもう一度採点させて出荷判定を出す、という順番です。けたちがいの回は 6 人から 10 件の指摘が出て、正解発表の画面で答えの持ち主名を表示する行の名前が途中で切れるという指摘は 6 人全員が挙げ、うち 2 人が出荷停止級と判定しました。1 人のテスターなら「そのうち直す」に入れていた見た目の問題が、6 視点を通すと真っ先に直すべき問題だと分かります。この回は修正後 6/6 で出荷でした。

レビューの一歩先として、エージェントに実際に遊ばせるテストもやっています。ワード系のゲームでは、複数のエージェントがそれぞれ自分のワードだけを知る状態で 1 卓を囲ませ、少数派がとぼけて逃げ切る・下手なヒントを出した無実の人が疑われる、という駆け引きが本当に成立するかを確認しました。記憶系のゲームでは、テストプレイが「いちばん面白い回答をした人に 1 点も入らない」という得点設計の欠陥を検出して、採点ルールを作り直しています。

パネルの壊れ方: 1 つは人間と同じ、1 つは LLM 特有

うまくいった話だけだと嘘になるので、パネルが壊れた 2 つの条件を書きます。

1 つ目はアンカリングで、これは人間そっくりの壊れ方です。お題デッキの採点プロンプトに参考のつもりで過去デッキの実測スコアを書いていたら、同じデッキの採点が渡した数字につられて 5 点台と 7 点台の間で揺れました。人間の面接官が前の候補者の点数に引きずられるのと同じです。対処も人間と同じで、過去の点数をプロンプトから消し、比較対象は名前を伏せた現物だけにする盲検化です。

2 つ目は見ていないものを見たと言うことで、こちらは LLM 特有です。軽量モデル (Haiku) でパネルを回した回で、スクリーンショットの文字を誤読して、画面に存在しない文言への指摘が混ざりました。人間のレビュアーも誤読はしますが、存在しない文言を丸ごと創作して滑らかに指摘することはまずありません。対処は、頻度集計の前に指摘対象が実在するかを画面・データと突き合わせて確認する工程を足すことです (やるのは集計側の AI で、実在確認を通った指摘だけを数えます)。

このパネルが原理的に測れないもの

ここが本当はいちばん書きたかった節です。まず、6 票は独立した 6 票ではありません。6 人は同じ基盤モデルから出ているので、票は相関しています。「6/6 が指摘」は 6 つの独立判断の一致ではなく「6 つの観点で網羅チェックしたら全部に引っかかった」と読むべきで、逆に、全員が同じ理由で同じ穴を見逃す共通モード失敗は、この構成では記録にすら残りません。さらに言えば、デッキも配色も AI が作り、AI が採点しています——実装者が自分でテストして合格判定まで出す構図で、パネルが自分の出力の癖に甘い可能性は未解決です。

測れる欠陥の範囲もはっきりしています。初見・単発・画面内で完結する欠陥は取れます。反復 (2 回目以降の飽き・お題の枯渇)・身体 (声量・端末の回し方・酔い)・実機 (端末サイズ・回線・色覚) の欠陥は取れません。LLM は人間より記憶力が良すぎるので、記憶ゲームの「成立するか」も割り引きが要ります。だから宿題も明確で、(1) 出荷後に人間から出た指摘を「パネルが事前に拾えていたか」で分類するエスケープ欠陥の記録と、(2) 数件に 1 件は僕が独立に判定してパネルと突き合わせるサンプリング監査です。委任は、委任先が壊れたことを検出できて初めて委任です。今のフローには、それがまだ入っていません。

パネル委任の効果は、速度にも出ています。ゲーム 1 本の着手から出荷までは 6 本目で約 4 時間、7 本目で約 3 時間、新テンプレートだった 9 本目で約 4 時間 15 分、10 本目は約 2 時間・マージ承認での差し戻しゼロでした。これは全部プロセスの内側の数字で、品質の主張ではありません。それでも「配色の確認待ちで手が止まらない」「レビューの往復が人間の都合に律速されない」が積むと、個人開発の律速だった「自分しか見る人がいない」は、少なくとも速度の面では外れました。

この記事も、別のペルソナ 3 人にレビューさせて事実誤認 4 件を直してから出しています。その 3 人が OK を出したこと自体は、品質の保証にはなりません。出来上がったゲームは mawashite.com で動いています。