第2章 企画の立て方/5 本目 / 全 6/約20分

AIに企画を壁打ちさせる

こより

自分の企画は、頭のなかで足しながら読んでしまうよ。紙の上でもらう指摘が、いちばん安いね。

案内役 こより
この術でできるようになること

企画が1回以上更新されている

画像は押すと原寸で開きます。

これから作る三つの的

これからこのゲームを事例に、一緒にゲームを創っていきます。見本ゲーム「三つの的」です。下にあるのは6章まで進めた完成形。そのまま遊べます。まず1回遊んで、目的地を体で知ってから読み進めてください。

別の画面でこのゲームを開く

結論から言うと、書き終えた企画は、そのままAIに読ませて穴を突かせてください。 紙の上での指摘は、いちばん安いんです。

なぜ要るか

企画は書き終わりました。でも自分では穴が見えません。

壁打ちとは、自分の考えを誰かへ投げて、返ってきたものを受けて考え直すことです。テニスの壁打ちと同じで、相手に勝つのが目的ではありません。その相手役を、AIにやらせるわけです。

自分の企画は、頭の中で補完しながら読んでしまいます。書いていない部分も「まあ分かるだろう」で読み飛ばしてしまいがちです。その読み飛ばした場所が、あとで手戻りになります。

ここでAIに読ませます。AIは補完しません。書いていないことは、書いていないと言ってきます。 しかも文句を言わず、何度でも読み直してくれるんですね。

これは人に見せるより先にやるべき作業です。理由は単純で、指摘は早いほど安く済みます。 紙の上なら書き直しは1分、コードを書いた後なら数時間です。

使う道具: Claude Code

AIプロンプト

この術の作業をAIへ任せるときは、これをそのまま貼ってください。

1) docs/plan.md を読んで、この企画の弱いところを3つだけ指摘して。ファイルは変更しないで、指摘だけ返して。初心者が最初の1本を完成させられるかという観点で。
2) docs/plan.md を読んで、これで作り始められるか。足りない情報があれば教えて。
  1. は、指摘を読んで企画を直したあとに使ってください。

やってみる

  1. 企画を読ませて、弱いところだけ聞く

    コツは3つあります。指摘の数を決める、観点を渡す、ファイルを変更させない。最後のひとつが特に大事です。何も言わないとAIは気を利かせて企画メモを書き換えてしまい、自分がどう直したのか分からなくなるんです。

    cd my-first-game
    claude -p "docs/plan.md を読んで、この企画の弱いところを3つだけ指摘して。ファイルは変更しないで、指摘だけ返して。初心者が最初の1本を完成させられるかという観点で。"
    

    数を決めないと10個返ってきて、心が折れますよ。3つがちょうどいい量なんです。

  2. 返ってきた指摘を読む

    実際に返ってきたものを、そのまま載せます。文中の「先手」は先に操作する人、「後手」はあとに操作する人という意味です。

    ## 1. 「同時に出す」が1台のパソコンでは実装できない
    
    面白さの1行は「どの的を捨てて、どの的を取るか」ですが、交代で操作すると
    後手は先手がどの的に置いたかを見てから選べます。捨てる判断の
    読み合いが消えて、後手が必ず有利なゲームになります。
    
    ## 2. 合計が同じ的を、どちらが取るのか決まっていない
    
    「合計が大きい方がその的を取る」としか書かれていません。
    同じ合計になった的は誰が取るのか、そもそも誰も札を
    置かなかった的はどうなるのかが未定義です。
    
    ## 3. 引き分けで終わったときの表示が決まっていない
    
    的は3つですが、2の指摘のとおり誰のものでもない的が出ると、
    取った的が1対1のような決着が普通に起こります。
    「勝敗の表示」しか項目がなく、引き分けの扱いが未定義です。
    

    最後にこう付いてきました。

    いちばん先に決めるべきは 1 です。2 と 3 は決めるだけなら数分で済みます。
    

    1つ目は致命的でした。 「同時に出す」と書いたのに、1台のパソコンで交代して遊ぶ設計だったので、後の人が必ず有利になります。読み合いという面白さの芯が、そもそも成立していませんでした。読み合いとは、相手が何を出すか分からないまま、お互いに予想して手を決めることです。相手の手が見えてしまうと、予想する必要がなくなるんですね。

    これ、コードを書いてから気づいていたら作り直しでした。

  3. 直す。全部でなくてよい

    指摘を全部飲む必要はありません。自分の企画なので、選びます。 今回はこう直しました。

    指摘 どう直したか
    同時に出せない 相手をコンピュータに変えた。人対人は次回に回す
    同点の的が未定義 合計が同じ的と、誰も置かなかった的は、どちらのものでもないと決めた
    引き分け未定義 取った的の数が同じなら「ひきわけ」と表示して終わると決めた

    面白いのは指摘2への対応です。「どちらのものでもない」と決めた瞬間、わざと同点に追いついて、相手の的を潰すという手が生まれました。穴を埋めただけなのに、遊び方が1つ増えているんですね。指摘に答えているうちに、企画そのものが良くなりました。

    ちなみにこの「同点はどちらのものでもない」は、いまのルールではありません。6-6で実測したら引き分けが多すぎたので、「あとに置いた方が取る」へ変えています。 企画の1行は、後から測って直せます。

  4. 直した理由も一緒に残す

    何を直したかだけでなく、なぜ直したかを書きます。あとで「なんでこうしたんだっけ」に答えられるんですね。

    ## AIの指摘で直したこと(2026-07-29)
    - 1台で「同時に出す」は成立しないと指摘された。相手をコンピュータに変えた
    - 同点の的の扱いが未定義と指摘された。どちらのものでもない、と決めた
    - 引き分けの表示が未定義と指摘された。ひきわけと出して終わると決めた
    
  5. 保存して送り返す

    git add .
    git commit -m "AIの指摘を反映して企画を直した"
    git push
    
  6. どう変わったか見る

    GitHubでコミットを開くと、企画がどう変わったか一目で分かります。赤が消した行、緑が足した行です。

    コミットの差分。plan.md のルールに足された3行が緑で並んでいる

    企画が1回更新されました。 これでこの術は達成です。

実例: 僕も同じ指摘を受けています

今回AIが出した「相手をコンピュータにしなさい」という指摘。これは、僕が身をもって知っていることと同じです。

https://tcg.kenty.app

このカードゲームは実物のカードゲームが元にあったので、最初から人と人が対戦する形で作り始めました。そのぶん、動作確認のたびに2台のブラウザを開いて自分で自分と対戦する必要がありました。 ゼロから作るなら、ここは避けられます。

つまりAIの指摘は、正しかったわけです。経験して分かることを、企画段階で先に教えてくれたということになります。

もう1つ、このアプリで大事にしているのがフィードバックの受け口です。画面の左側に「フィードバック」とDiscordへのリンクが常に出ています。

AIの壁打ちは早くて安いですが、人の反応には代えられません。 順番はこうです。

  1. AIに壁打ちさせる(今この術)→ 穴を潰す
  2. 作って出す → 人に遊んでもらう
  3. 感想を受ける口を用意しておく → 次を作る

AIで潰せるのは「書いていない」「成立していない」という穴です。「面白いかどうか」は、人に遊んでもらうまで分からないんです。だからAIで済ませようとせず、早く出して人に触ってもらうところまで持っていきます。

もう1つの使い方

指摘させるだけでなく、遊んでもらうこともできます。

claude -p "docs/plan.md のルールで、僕と1試合やってみて。置き先は「一の的」のように言うよ。"

AIが対戦相手になり、こちらの手を待ってくれます。画面はなく、文字のやり取りだけで1試合できます。紙で遊ぶより速く、ルールの穴が見つかるはずです。「そのルールだと決着がつきません」と言われたら、その場で直せます。

つまずきどころ

指摘が厳しくて心が折れた

数を絞ってください。「3つだけ」と言うのが大事なんです。それでもきつければ「よくできている点も1つ挙げて」と足すと、読める分量になります。

指摘が的外れに感じる

無視して構いませんよ。 決めるのはあなたです。ただし「なぜ無視したか」を1行だけ書いておくと、あとで自分を助けます。

AIが勝手にファイルを直した

指示に「ファイルは変更しないで」を入れてください。それでも触られたら git diff で確認し、git checkout . で戻せます。1-4でやったとおりです。

指摘どおりに直したら企画が別物になった

それは指摘の飲み方が多すぎます。面白さの1行に効かない指摘は捨ててください。 芯だけは守ります。

Windows の場合

claude -p の使い方は同じです。コマンド内の引用符は半角にしてください。

Codex で進める場合

同じことができます。

codex exec "docs/plan.md を読んで、弱いところを3つだけ指摘して。ファイルは変更しないで。"

こういう「読んで指摘するだけ」の作業は、コスパに優れる Codex 向きです。僕も企画の壁打ちは、Codex に振ることが多いんです。

次の一歩

直した企画を、もう1回読ませてみてください。

claude -p "docs/plan.md を読んで、これで作り始められるか。足りない情報があれば教えて。"

「作り始められます」と返ってきたら、企画は完成です。次の章から、いよいよ動くものを作ります!

術の一覧へ戻る

メルマガ(無料)忖度なしのAI事情を、メールでお届けします。ご登録の方に、プレゼントをお渡ししています