はじめに
ゲーム開発で「モンスターのスプライトシートが14種類必要」という状況になった。
普通なら1枚ずつ手作業でプロンプトを考えて画像生成AIに投げるところだが、Claude Codeと連携すると以下のようなパイプラインが組める。
設計書（ゲーム仕様）
↓ Claude Code がプロンプト生成
テキストファイル（14体分の画像生成プロンプト）
↓ Gemini で画像生成
ダウンロードフォルダに14枚のPNG
↓ Claude Code が画像を目視判定＆リネーム
Assets/Resources/Monsters/mon_golem.png 等に自動配置
この記事では、このパイプラインの具体的な作り方と、うまくいった点・ハマった点を書く。
私は建設会社の総務で、本職のプログラマーではない。開発はすべてClaude Codeとの対話で行っている。
Step 1：Claude Codeにプロンプトを一括生成させる
仕様を伝えるだけでプロンプトが出てくる
Claude Codeとの会話で、まずゲーム内でのモンスターの役割を決めた。
自分：異世界って設定なんで、著作権に問題ない有名モンスターを障害物的な感じで出したい
自分：ドラゴン、ゴブリン、スケルトン、ゴーレム、スライム、トロール…（14体のリスト）
自分：固定障害物/巡回/突進の3タイプで
自分：プロンプトを作成してtextに書き出して
これだけで、Claude Codeは14体分のプロンプトをprompts.txtに書き出してくれた。
生成されたプロンプトの構造
各プロンプトは以下の要素を含む、150〜200単語の英語テキストだ。
pixel art sprite sheet of a [モンスター名] monster as a racing game obstacle,
4 frames in a single horizontal row on a 512x128 pixel canvas,
each frame is 128x128 pixels,
[外見の詳細な描写],
frame 1 [ポーズ1の説明],
frame 2 [ポーズ2の説明],
frame 3 [ポーズ3の説明],
frame 4 [ポーズ4の説明],
viewed from a front three-quarter angle,
clean black pixel outlines,
white background,
retro SNES 16-bit pixel art style
ポイントは以下の3つ。
1. キャンバスサイズの明示
4 frames in a single horizontal row on a 512x128 pixel canvas,
each frame is 128x128 pixels
Geminiに「4コマ横並びのスプライトシート」を正確に出させるには、ピクセル単位でキャンバスサイズを指示する必要がある。これがないと1枚絵や縦並びが出てくる。
2. フレームごとの具体的なポーズ指示
frame 1 standing still in a wide sturdy stance arms at sides
frame 2 same pose but the orange glow intensifies and small pebbles float
frame 3 the golem shifts its weight slightly raising one fist
frame 4 returns to the original pose with the glow dimming back down
「アニメーション」とだけ書くと4フレームが同じ絵になることがある。各フレームで何が変わるかを具体的に書く。
3. 行動タイプに合ったアニメーション
| タイプ | アニメーション | 例 |
|---|---|---|
| 固定（idle） | 微動・呼吸・発光の変化 | ゴーレム：溶岩の発光が明滅 |
| 巡回（walk） | 歩行サイクル4フレーム | ゴブリン：左右の足を交互に |
| 突進（charge） | 走り→跳躍→着地 | ドラゴン：四足疾走+火炎 |
Claude Codeはゲーム仕様（固定/巡回/突進の3タイプ）を理解した上で、それぞれに適したアニメーションパターンを設計してプロンプトに落とし込んだ。
コピペ用フォーマットも用意
Geminiに1体ずつ手動で貼る場合に備えて、番号付き・区切り線付きのファイルも出力させた。
============================================================
1/14 mon_golem.png（ゴーレム / 固定タイプ）
============================================================
pixel art sprite sheet of a stone golem monster...（プロンプト本文）
============================================================
2/14 mon_basilisk.png（バジリスク / 固定タイプ）
============================================================
pixel art sprite sheet of a basilisk serpent monster...（プロンプト本文）
「何番目の何を作っているか」が一目でわかるので、手動作業でも迷わない。
Step 2：Geminiで画像生成
ブラウザ自動化を試みた（が不安定だった）
Claude CodeにはClaude-in-Chromeというブラウザ操作拡張がある。これを使ってGeminiへのプロンプト投入→画像生成→ダウンロードを自動化しようとした。
自動化の手順：
1. gemini.google.com に移動
2. 入力欄にプロンプトを貼り付け
3. 送信ボタンをクリック
4. 10〜20秒待つ（画像生成中）
5. 生成された画像をクリック（ビューア表示）
6. ダウンロードボタンをクリック
7. 新規チャットに戻る
8. 1に戻って次のプロンプト
結果：1〜2枚なら成功するが、連続実行すると不安定になる。
Geminiの画像ビューアが重く、3枚目あたりでChromeのタブがフリーズした。Geminiのページ自体がリッチなSPAで、画像ビューアを開閉するたびにメモリ使用量が増えていく。ブラウザ自動化ツールはページが応答しなくなると操作を続けられないため、「1〜2枚やって固まる→タブを閉じて再開→また1〜2枚」というサイクルになった。
結論：手動が一番速い
14枚程度なら手動でコピペして生成するのが最も確実で速い。prompts.txtのコピペ用フォーマットが活きた。
作業時間の比較：
| 方法 | 14枚にかかった時間 | 安定性 |
|---|---|---|
| 完全自動化（理想） | 推定15分 | 3枚目で破綻 |
| 手動コピペ | 約20分 | 確実 |
| 自動化リトライ込み | 40分以上 | 不安定 |
ブラウザ自動化は「ページ構造が安定していて、重いビューアを開かない」タイプのサイトでは有効だが、Geminiのようなリッチ UIでは現時点では厳しい。
Step 3：Claude Codeに画像を判定・リネームさせる
ここが一番面白いパートだ。
Geminiでダウンロードした画像のファイル名はGemini_Generated_Image_myvvt5myvvt5myvv.pngのようなランダム文字列で、どれがどのモンスターか分からない。14枚を1枚ずつ開いて確認してリネームするのは面倒だ。
Claude Codeは画像を「見て」判定できる
Claude Codeにダウンロードフォルダのファイルパスを渡すと、画像を直接読み取って中身を判定してくれる。
自分：（14枚のファイルパスを貼り付けて）適用して。
Claude Codeは14枚すべてを読み込み、以下のように判定した。
1. myvvt5... → バジリスク（緑の蛇、赤い冠）
2. s77nl3... → ゴーレム（石の体、オレンジの亀裂）
3. 1g87rv... → サイクロプス（灰青の肌、棍棒）
4. x400r... → ゴブリン（緑肌、兜、剣と盾）
5. h66w00... → スケルトン（骸骨、赤いタバード）
6. v6hytq... → スライム（青いブロブ）
7. rdript... → トロール（緑の疣肌、前かがみ）
...（以下7体続く）
Claude Codeはマルチモーダルモデルなので、画像を渡せばピクセルアートの内容を理解して「これはドラゴン」「これはキョンシー」と特定できる。
自動リネーム＆配置
判定後、Claude CodeがPowerShellスクリプトを生成・実行して、14枚すべてを正しいファイル名でゲームのリソースフォルダにコピーした。
$map = @{
"Gemini_Generated_Image_s77nl3s77nl3s77n.png" = "mon_golem.png"
"Gemini_Generated_Image_myvvt5myvvt5myvv.png" = "mon_basilisk.png"
"Gemini_Generated_Image_1g87rv1g87rv1g87.png" = "mon_cyclops.png"
# ...全14体のマッピング
}
foreach ($entry in $map.GetEnumerator()) {
Copy-Item -Path (Join-Path $src $entry.Key) -Destination (Join-Path $dst $entry.Value)
}
ランダムなファイル名の画像14枚が、数秒で正しい名前のリソースファイルになった。
Step 4：ゲームコードへの組み込みまで自動
画像の配置が終わると、Claude Codeはそのまま以下のコードも生成した。
- MonsterObstacle.cs — モンスターの行動AI（固定/巡回/突進の3タイプ）
- TrackBuilder.cs への追加 — コース上にモンスターを自動配置するロジック
- Mode7ObjectRenderer.cs への追加 — スプライトシートを読み込んでアニメーション描画
つまり「モンスター14体を障害物として出したい」という1つの要望から、プロンプト生成→画像生成→リネーム配置→ゲームコード実装まで一気通貫で完了した。
全体のパイプラインまとめ
| ステップ | 担当 | 所要時間 | 成果物 |
|---|---|---|---|
| ゲーム仕様の決定 | 人間 | 会話5分 | 14体のモンスターリスト＋行動タイプ |
| プロンプト生成 | Claude Code | 自動（約1分） | prompts.txt（14体分） |
| 画像生成 | 人間（Gemini手動） | 約20分 | 14枚のPNG |
| 画像判定＋リネーム | Claude Code | 自動（約30秒） | mon_xxx.png × 14 |
| ゲームコード実装 | Claude Code | 自動（約5分） | 3ファイル追加・4ファイル修正 |
人間が手を動かしたのは「仕様を話す」と「Geminiにプロンプトをコピペする」の2つだけ。残りはすべてClaude Codeが処理した。
ハマりポイントと対策
1. Geminiが4フレーム並びを無視する
プロンプトに4 frames in a single horizontal rowと書いても、たまに1枚絵や3フレームが出てくる。対策としてon a 512x128 pixel canvas, each frame is 128x128 pixelsとキャンバスサイズを数値で明示すると精度が上がった。それでもダメな場合はリトライ。
2. 白背景指定が効かない
white backgroundと書いても背景に地面や空が描かれることがある。ゲームでは白ピクセルを透明として扱うので、背景にグレーや茶色が混ざると透過処理がおかしくなる。
対策：スプライトシート読み込み時に「白に近いピクセル（RGB全て240以上かつalpha>20のもの）をコンテンツとして扱わない」フィルタをコード側に入れた。
// 白背景を自動判定で除外
if (c.a > 20 && (c.r < 240 || c.g < 240 || c.b < 240))
{
hasContent[x] = true;
}
3. ブラウザ自動化の限界
Claude-in-Chrome経由でGeminiを操作する方法は、ページが軽い作業（テキスト入力・ボタンクリック）なら動くが、画像ビューアのような重いUIを繰り返し開閉すると破綻する。
対策：100枚以上の大量生成が必要なら、Gemini APIを直接叩くスクリプトをClaude Codeに書かせるほうが安定する。 14枚程度の小規模なら手動コピペが最速。
この手法が使える場面
ゲーム開発以外でも、以下のような場面で同じパイプラインが使える。
- ブログ用のアイキャッチ画像を大量生成 — 記事タイトルからプロンプトを自動生成
- プレゼン資料の図解 — スライドの内容から図解プロンプトを生成
- UIモックアップ — 画面仕様からモックアップ用のプロンプトを生成
- 教材の挿絵 — 教科書の単元ごとにイラストプロンプトを生成
共通するのは「大量の類似画像を、統一されたスタイルで生成したい」というケースだ。人間がプロンプトを1個ずつ書くと表現がブレるが、Claude Codeに一括生成させると14体すべてが同じフォーマット・同じ画風指定になる。
まとめ
- Claude Codeは画像生成プロンプトの一括生成が得意 — ゲーム仕様を会話で伝えるだけで、統一フォーマットのプロンプトが出てくる
- ブラウザ自動化は小規模なら有効、大量生成にはAPI直叩きを推奨 — Geminiの画像ビューアが重くて連続処理が不安定
- Claude Codeの画像判定が地味に便利 — ランダムファイル名の画像を渡すと中身を見て正しくリネームしてくれる
- プロンプト生成→画像生成→リネーム配置→コード実装まで一気通貫 — 人間は仕様を話すのとコピペだけ
AIにコードを書かせるのはもう当たり前になりつつあるが、画像生成のプロンプトをAIに書かせて、生成された画像をAIに判定させるという「AI×AI」のパイプラインは、これからもっと一般的になると思う。