AIに読み込ませるコード量はどこまで?コンテキストの節約術
遊びをつくる執筆にClaudeを使用しています。

AIにコードを貼り付けて「直して」と頼んだとき、どこまで渡せばいいのか迷った経験はないでしょうか。全ファイルを丸ごと貼ると返答が遅くなったり、肝心な部分への指摘が薄れたりします。一方で関係ファイルを絞りすぎると「そのコードは見えていません」と言われ、作業が止まります。 この記事では「コンテキスト」——AIが一度に処理できるテキストの範囲——を念頭に置きながら、ゲーム制作の場面でAIに渡すコード量をどう判断し、どう削るかを具体的に説明します。ツールの種類や流行りのプロンプトテクニックではなく、「何を渡して何を省くか」という取捨選択の基準に絞ります。
この記事の目次
コンテキストが「詰まる」と何が起きるか
AIが一度に処理できるテキスト量には上限があります。この上限をコンテキストウィンドウと呼び、モデルや料金プランによって異なります。上限に近づくと次のような問題が起きます。
- 会話の前半で渡したコードをAIが「忘れる」または参照しなくなる
- 長い入力に対して返答が表面的になり、細かいバグを見落とす
- APIを従量課金で使っている場合、トークン消費が増えてコストが上がる
ブラウザゲームの開発では、HTMLとJavaScriptが1ファイルに収まっているうちは問題になりにくいです。しかしCSSを分離したり、ステージデータをJSONで管理したり、ライブラリを自作しはじめると、合計行数が数百〜数千行に達します。そのすべてをチャットに貼り付けるのは避けるべきです。
渡すべきコードを選ぶ3つの判断基準
1. 「今の質問」に直接触れるコードだけ渡す
AIへの質問を先に一文で書き出してみてください。「スコアが正しく加算されない」なら、スコア計算の関数・それを呼び出す箇所・スコア表示のDOM操作の3点だけが対象です。衝突判定や音声管理のコードは無関係なので省きます。
判断に迷ったら「このコードを外しても、今の質問の答えは変わらないか?」と自問してください。変わらないなら省けます。
2. 構造だけ渡す「スケルトン化」
バグの原因を探るより先に「設計を相談したい」「ファイル分割の方針を聞きたい」という場面では、実装の中身を省いたスケルトンで十分です。たとえば次のような形です。
// GameManager.js(概要のみ)
class GameManager {
constructor() { /* 初期化処理 */ }
update(dt) { /* 毎フレーム呼ばれる */ }
checkCollision(a, b) { /* 当たり判定 */ }
// 他20メソッド
}本物のコードの代わりにコメントで中身を要約すると、構造は伝わりながらトークン数を大幅に削れます。AIは「何があるか」を把握できれば、「どう改造するか」を提案できます。
3. エラーメッセージと問題箇所の行番号を優先する
コードを大量に渡すより、ブラウザのコンソールに出たエラーメッセージをそのままコピーし、エラーが出た行の前後30行程度だけを添えるほうが的確な回答が得られます。AIはエラー文から原因の候補を絞り込む能力が高いため、無関係なコードで視野を狭めないことが大切です。
コンテキストを節約する4つの実践手順
手順1:質問を分割する
「このゲームを全体的に改善して」という大きな依頼を一度に出すと、AIは優先順位をつけられずに表面的な提案を並べます。「まずスコアのバグを直す」「次に画面遷移を整える」というように、一回の質問に一つのテーマを割り当てます。質問が小さいほど渡すコードも絞れます。
手順2:会話を区切る
長いチャットが続くと、冒頭の文脈がコンテキストウィンドウから押し出されます。作業フェーズが変わったとき(バグ修正 → 機能追加など)は新しいチャットを始めるか、直前のやり取りを一段落に要約してから貼り直します。「これまでの経緯」を毎回全部引き継ぐ必要はありません。
手順3:コードをモジュールに分ける
1,000行を超えるHTMLファイルを1本持ち歩くより、役割ごとにJavaScriptを分割しておくと、必要なファイルだけをAIに渡しやすくなります。たとえば collision.js・renderer.js・input.js に分けておけば、入力まわりのバグには input.js だけを見せればすみます。モジュール分割はコードの読みやすさだけでなく、AI作業効率にも直結します。
手順4:「まず設計を言語化する」フェーズを入れる
コードを渡す前に、自然言語で設計を説明するフェーズを設けるとコンテキストが節約できます。「プレイヤーが障害物に触れたらHPを1減らし、0になるとゲームオーバー画面を表示します。この処理はどこに書くのが適切ですか?」という質問には、コードは不要です。AIの返答を踏まえてから実装し、できあがったコードだけを次のターンで確認してもらいます。
失敗しやすいパターンと対処
「とりあえず全部貼る」は一見早いが遅い全コードを貼ると安心感がありますが、AIの返答が「〜の可能性があります」という列挙になりやすく、一つひとつの確認に時間がかかります。最初から絞って渡すほうが具体的な修正コードが返ってきます。
外部ライブラリのソースを貼らないPhaser.jsやPixi.jsなどライブラリのソースコードをチャットに貼っても意味がありません。AIはすでにそれらの知識を持っています。「Phaser 3でグループのcolliderを設定したい」と書くだけで十分です。
「前回と同じコードです」は通じない新しいチャットを始めると前回の会話はリセットされています。「前回直してもらったコード」と書いても参照できません。作業の要点を短く書き直して渡す習慣をつけてください。
長いコメントや console.log をそのまま渡さないデバッグ用の console.log や書きかけのコメントは削除してから渡します。AIの注意が本質でない行に向くのを防げますし、トークン削減にもなります。
コンテキスト節約の恩恵は速度とコストだけではない
コードを絞って渡す習慣は、AIとのやり取りだけでなく自分の理解を深める副作用があります。「何が問題の核心か」を自分で考えてから質問するため、AIの回答を受け取ったときに「なぜそう直すのか」が腑に落ちやすくなります。コードを整理する過程で自分でバグに気づくことも珍しくありません。
渡す量を減らすことは情報を隠すことではなく、問いを精密にすることです。AIはその精密な問いに精密な答えを返します。
次の行動
手元のゲームプロジェクトで、直したい箇所を一つ決めてから「この質問に必要なコードは何行か」を数えてみてください。まず絞り込みの感覚をつかむことが出発点です。完成したゲームはHTMLやZIPファイルとしてアソバースに投稿できますので、作業が進んだら公開を目標に置いておくと開発の区切りがつけやすくなります。

