結果を確認できるタスクを AI アシスタントにどう書けばいいですか？

変更は一つだけ頼み、場所と変えてはいけないものを伝え、合否が出る確認を渡し、何をしたかの報告を求めます。

頼む変更は一つだけ、数分で試せる大きさにします。どこに入れるのか、何をそのままにするのか、動くことをどう確認するのか、そして何を返してほしいのかを伝えます。こう書いたタスクは、判断できる形で返ってきます。変更したファイルの短い一覧、合格か不合格かが出た確認、そして自分で遊んで確かめられるゲームです。あいまいなタスクは「できたように見える」大きな変更として返ってきて、確認はすべてあなたの仕事になります。

確認できるタスクには何が必要ですか？

五つの部分です。ほとんどのタスクに五つすべてが必要で、どれも一、二文で書けます。

どれも新しい助言ではありません。GitHub のCopilot 向けプロンプトの書き方ガイドは、手順に分けたシンプルで具体的な依頼と、期待する結果の例を一つか二つ求めています。Claude Code のベストプラクティスは、アシスタント自身が実行できる確認を最初に挙げています。それがないと「できたように見える」ことが唯一の手がかりになるからです。2026 年 10 月 25 日時点で、どちらのページもそう書かれていました。以下では、これを小さなゲームに当てはめます。

一つのタスクはどのくらい小さくすべきですか？

変更を一文で説明でき、数分で試せる大きさです。「ポーズ画面を追加して」は一つのタスクです。「ポーズ画面と設定メニューとサウンドを追加して」は三つで、何かが壊れたとき、どれが原因か分かりません。

説明が長くなるタスクなら、まず計画を頼み、コードは後にします。Claude Code のページもまさにそれを勧めています。アシスタントにコードを読ませ、どのファイルが変わるかを提案させ、その計画を自分で読んでから書かせるのです。プロジェクトの半分に手が入る計画は、タスクを分けるべきだという合図です。

これは最初のゲームを小さく保つのと同じルールです。どの機能もほかのすべての機能と一緒に動かなければならないので、三つを一度に足すタスクは確認を何倍にもします。

あいまいなタスクと確認できるタスクを並べるとどう違いますか？

小さなシューティングゲームへの同じ依頼を、二通りに書いてみます。

右の列のほうが長いですが、どの行も確認できます。三つ目は、私たちがKittenGalaxy にタッチ操作を追加したときのやり方に近いものです。ボタンはキーボードが送るはずのキーイベントを送るので、ゲーム本体を変える必要はありませんでした。

作業の確かめ方をアシスタントにどう伝えますか？

「はい」か「いいえ」で答えが出るものを渡します。

• テスト：アシスタントが実行でき、ケースが書き出されているもの。「リスタートでスコアが 0 になる」。
• コマンド：結果を読めるもの。ビルドが終わる、コンソールにエラーなしでページが読み込まれる。
• 自分で遊ぶ手順：変更の前に書いておくもの。「スタート、ライフをすべて失う、リスタートを押す、スコアが 0 と表示される」。

確認を実行して出力を見せるようアシスタントに頼みます。合格したと言わせるだけにはしません。貼り付けられたテスト結果やエラーのないコンソールログは数秒で読めますが、「すべて動きます」という一文は何も証明しません。

人にしか判断できないこともあります。ジャンプの感触がいいか、レベルが公平か、などです。そうしたものは、何を見るかを書いておき、自分で遊びます。アシスタントの報告をその代わりにしてはいけません。

終わったとき、アシスタントは何を伝えるべきですか？

同じタスクの中で、次の順の短い報告を頼みます。

1. どのファイルが変わったか、それぞれ一行で理由も；
2. どの確認を実行し、何が返ってきたか；
3. 何をテストしていないか、その理由；
4. 頼んでいないのに変えたもの。

いちばん大事なのは最後の項目です。頼んだ範囲を超えた変更がいつも間違いとは限りませんが、それは常に確認する予定のなかったものです。ファイルの一覧をタスクの部分 3 と見比べてください。変わるはずのなかったファイルが、最初に見るべき場所です。

毎回のタスクではなく、プロジェクトのファイルに書いておくべきことは？

そうしなければ繰り返すことになるものすべてです。ゲームとテストの動かし方、触ってはいけないフォルダー、コードのルールなど。ほとんどのアシスタントは、セッションの初めにこうしたファイルを読みます（Claude Code では CLAUDE.md と呼びます）。短く保ちましょう。Claude Code のページは、長いファイルでは大事なルールが埋もれてしまうと注意しています。

ルールがそこに置く価値を持つのは、忘れるとゲームが壊れるときです。私たちが KittenGalaxy のために付けているメモには、キー、画面、ゲームの状態を追加するときは、そのタッチ操作も同じ変更で追加する、そうしないとスマートフォンのプレイヤーがそこに行けない、と書いてあります。そうすればタスクには新しいことだけを書けば済みます。

結果が間違っていたらどうしますか？

元に戻してから、よりよいタスクでもう一度頼みます。

各タスクの前に、動くバージョンをバージョン管理のコミットとして保存しておけば、悪い変更を一歩で取り消せます。確認に落ちたら、修正を一、二度頼むことはできます。二度直させてもうまくいかなければ、Claude Code のページは、何度も直させるのではなく、よりよい最初の依頼で新しいセッションを始めるよう勧めています。失敗した試みが会話に残るからです。変更を取り消し、分かったことをタスクに書き足して、もう一度送ります。

よくある質問

こういうタスクを書くのにプログラマーである必要がありますか？いいえ。部分 1、3、5 はゲームが何をするかについてで、普通の言葉で書けます。部分 2 については、変更を頼む前に、それがどこに入るべきかをアシスタントに聞きましょう。

長いタスクは短いタスクよりよいですか？それ自体では違います。たくさんの変更を求める長いタスクは、一つを求める短いタスクより確認しにくくなります。長さが役に立つのは、確認や制限を加えるときです。

小さなゲームでもテストを頼むべきですか？正確に言えるルール（スコア、ライフ、タイマー、セーブ）なら、はい。その後の変更のたびに安く実行できます。感触や面白さは、やはり遊んで確かめます。

アシスタントに質問されたら？書き始める前に、タスクの中で答えます。早めの質問は、間違った変更より安く済みます。

ゲームを人に見せられるのはいつですか？知らない人がリンクから始めて、あなたの助けなしに最後まで遊べるようになったときです。そうしたらHeapPlay に登録を申請できます。認証済みの開発者は、新しいバージョンごとに何が変わったかを記録できます。