マガジン

AIが勝手に機能を増やすのを止める指示の出し方

遊びをつくる

執筆にClaudeを使用しています。

一枚の紙の四つの欄に、画面、操作、目的、終わり方を絵で整理する机。
記事のテーマをもとに制作したAI生成の写真風イメージ。

AIにゲームのコードを書いてもらうとき、頼んでいないのにスコア表示が増えていた、サウンド切り替えボタンが追加されていた、レベル選択画面まで生えていた――そんな経験をした方は多いはずです。AIは「より良いものを出力しようとする」性質があるため、指示の曖昧な隙間を「改善の余地」と解釈し、自発的に機能を足しがちです。 これは悪意ではなく、AIが「完成度の高いゲーム」のパターンを学習しているからこそ起きる現象です。つまり、止めるには「余地を与えない」指示設計が必要になります。完成したコードを直す手間よりも、プロンプトを5分整える方がトータルで速いのは間違いありません。 この記事では、機能の勝手追加が起きるメカニズムを整理したうえで、具体的な指示の書き方と、会話を重ねる中での管理方法を説明します。

この記事の目次
  1. なぜAIは頼んでいない機能を追加するのか
  2. 機能追加を防ぐ指示の四つの柱
  3. 会話を重ねるときの管理方法
  4. 追加されてしまったときの対処
  5. 失敗しやすいパターンと対策
  6. 次の行動

なぜAIは頼んでいない機能を追加するのか

AIが機能を増やす原因は、大きく三つに分けられます。

一つ目はスコープの未定義です。「シンプルなパズルゲームを作って」という依頼は、AIにとって「シンプル」の基準が不明です。AIが学習したパズルゲームの多くにはハイスコア表示やリトライボタンがあるため、それが「普通」として出力に混入します。

二つ目は「改善提案」モードへの自動移行です。コードが一段落すると、AIは「次に足すと良いもの」を提示したがります。提案だけならよいのですが、コードの中に先回りして実装してしまうことがあります。

三つ目は会話履歴の文脈ドリフトです。複数回のやりとりを経ると、前のターンで出た案がそのまま次のコードに取り込まれることがあります。「こういう機能もあると面白いかも」と一度でも書くと、その後のコードにそれが実装されていたりします。

機能追加を防ぐ指示の四つの柱

1. 「含めないもの」を明示する

何を作るかと同じ重みで、何を作らないかを書きます。

「今回のスコープに含めないもの:ハイスコア保存、サウンド、アニメーション演出、レベル選択、チュートリアル」

このリストは長ければ長いほど効果があります。「シンプルに」という副詞は機能しませんが、除外リストは機能します。

2. 完成の定義を書く

「どうなったら完成か」を具体的に一文で書きます。

「3×3のグリッドをクリックで塗り替えられ、全マス同色になったら『クリア』と表示されれば完成です。それ以上の機能は不要です。」

「それ以上の機能は不要です」という一文は、AIが「もっと良くしようとする」余地を明確に閉じます。

3. 出力形式を固定する

「HTMLとJavaScriptのみ、CSSは最小限、外部ライブラリなし」のように出力の制約を書くと、構造が大きくなりにくくなります。外部ライブラリの導入は機能追加と連動しやすいため、使う場合は名前を指定します。

4. 「提案を求めていない」と宣言する

「コードの後に改善提案や追加機能のアイデアを書かないでください。コードだけを出力してください。」

これは一見失礼に見えますが、AIは命令として受け取るだけです。提案を書かないと指示することで、AIが「次に何を足すか」を考えながらコードを書くモードに入ることを防げます。

会話を重ねるときの管理方法

一度のやりとりで完成しないゲームを作るときは、会話の流れ自体がスコープを広げるリスクになります。以下の習慣で防げます。

ターンの冒頭でスコープを再確認する。「前のコードをベースに、〇〇だけを変えてください。他の部分は変更しないでください」と毎回書きます。「他の部分は変更しない」は重要で、これがないとAIがリファクタリングや機能追加を兼ねて書き直すことがあります。

「提案モード」と「実装モード」を分ける。アイデアを検討したいターンと、コードを出力させるターンを分けます。「まず言葉で設計を確認したいので、このターンはコードを書かないでください」と明示すると、設計の議論がそのまま実装に流れ込みません。

コードが長くなったら「差分だけ」を要求する。「ファイル全体を書き直さず、変更する関数だけ出してください」と指定すると、AIが書き直しの際に機能を追加する機会が減ります。

追加されてしまったときの対処

それでも機能が増えていた場合、削除を依頼するより「特定の関数を消す」と具体的に指示する方が確実です。「シンプルにして」は再び曖昧な指示になるため、「scoreDisplay要素とそれを参照しているすべての記述を削除してください。他は変えないでください」のように対象を絞ります。

また、コードが大きく増えた時点で一度立ち止まり、不要な部分を取り除いた版を「このコードをベースに使います」と宣言して貼り直すと、以降のやりとりがリセットされます。長い会話の文脈に引きずられているときは、新しい会話を始めてコードと制約を再掲する方が早いこともあります。

失敗しやすいパターンと対策

  • 「シンプルに」と書いたのに増えた、なぜ起きるか:「シンプル」の基準がAIと違う、対策:除外リストで具体化する
  • 一部修正を頼んだら全体が書き変わった、なぜ起きるか:「変更しない」の明示がなかった、対策:「他は変えないでください」を毎回付ける
  • 雑談でアイデアを出したら実装された、なぜ起きるか:提案と実装の区別がなかった、対策:ターンの役割を宣言する
  • 削除を頼んだら別の機能に置き換えられた、なぜ起きるか:「削除」が「改善」と解釈された、対策:消す対象を関数名・要素名で指定する

次の行動

今作っているゲームのプロンプトに「含めないもの」のリストと「それ以上は不要です」の一文を追加してみてください。これだけでも、次回の出力が変わるのが体感できるはずです。作ったゲームはHTMLファイルやZIPとしてアソバース(https://aso-verse.com)に投稿できますので、小さく完成したものをそのまま公開する流れを試してみてください。