🛠
制作支援ツールはその場で組む時代に — Claude Code で作った AI 生成アセットのレビュー用 4本 (Unity個人ゲーム開発)

2026/05/27に公開
本記事は、個人開発中の HD-2D 探索アドベンチャー Anemora の制作で、本体ではなく AI 生成アセットのレビュー作業 を回すために Claude Code に作らせた制作支援ツール群を紹介します。本体開発では Claude Code と Codex CLI を併用していますが、本記事の制作支援ツール群は主に Claude Code で作ったものです。

 TL;DRAnemora を AI 中心で作っていると、自分の作業の主軸は「生成」よりも「選んで残す」側、つまりレビューに移っていきます
レビューの粒度に合う既存サービスはなく、これまで自作コストが見合わなかった小さいツールが、Claude Code で 思いついた日のうちに動く形まで揃う ようになった、という話を 4本の実例で紹介します
内訳: 画像レビューギャラリー / 音声 (BGM・SFX) レビューギャラリー / フォントプレビュー / 外出中もレビューが続く閲覧ビューア
4本とも開発 branch で運用中。閲覧ビューアは URL も公開しています (https://anemora-viewer.pages.dev/)

 背景 — AI 中心開発でレビューがボトルネックになるAnemora ではコードもキャラクタースプライトも BGM・SFX もダイアログも、最初の叩き台は Claude Code または Codex CLI に作らせています。開発を続けるうちに気付いたのは、生成は AI に任せられる一方、良し悪しを判断するレビュー作業は自分の手元に残るということでした。しかも生成スピードが上がるほど、レビュー側の手数も増えます。
レビュー対象ごとに、手元の既存手段だけでは足りないものがありました (詳細は各ツール紹介で触れます)。

画像: フォトアプリで順送りはできるものの、数百枚規模を比較・選定して採用候補に絞り込んでいくレビュー導線が組めない

音声 (BGM / SFX): メディアプレーヤーで連続再生はできるものの、多数の候補を一覧から効率的に試聴・選定する仕組みが揃っていない

フォント: 実際の会話 UI に乗せた状態でフォント候補を並べて比較する手段が見当たらない

外出中の進捗閲覧: GitHub のスマホアプリではブランチ横断で進捗を眺めるレビュー導線にならない
どれも既存のサービスだと粒度が合わず、ちょうどいい形を作ろうとすると自前実装になります。自作コストが大きければ後回しになるところですが、Claude Code に Plan モードで対話しながら作ってもらえば、開発の流れを止めずにその場で形にできます。現時点で 4本に整理されているので、それぞれ紹介します。

 他のレビュー用途にも転用できる 3 つの設計パターン本記事で紹介する 4本どれも、暗黙の前提として次の 3 つを揃えています。同じ枠を別ジャンルのレビュー (生成画像でも生成コードでも、社内資料の選定でも) に転用するときも、この 3 つを最初から踏まえておくと骨格を流用しやすくなります。

公開できる状態を最初から考える: 生成物 (HTML / JSON) にローカル絶対パスや個人名を埋めない。デフォルトは相対パス、絶対パスが要る私的レビューだけ明示オプトイン (--path-mode absolute)。後で公開リポやチームの共有先にそのまま置いても問題ない状態を最初から保つ

静的 HTML + ブラウザの localStorage で完結: サーバーも認証も付けない。1 ファイル HTML + 生成スクリプト (Python など) だけで動く。マークやフィルタなどの判断結果は localStorage に持ち、サーバー側には何も残さない。共有が要るときだけ JSON でエクスポート

「選ぶ」と「組み込む」を分ける: ツール上の Final や Trash はあくまで選定のメモ。本体側への取り込み (Anemora なら Unity ランタイムへの組み込みやアセット台帳の更新) は、ツールを経由せず従来の経路に通す。レビューツールがアセット管理まで兼ねないようにする
実際 Anemora でも、画像レビュー版を作った後、音声版を派生させるときの追加コストが極小で済み、結果としてジェネレータの共通モジュール化 (後述の media_review_gallery) も自然に進みました。

 ツール紹介
 1. 画像レビューギャラリー
 何を解いたかAI 生成のキャラクタースプライトや背景候補が数百枚単位で出てきたとき、フォトアプリで順送りに見るだけでは「どれを残してどれを切るか」を後から思い出せませんでした。タグで絞り込みつつ、ホバーで拡大確認、マークを付けて後で Final を抜き出す、までを 1 画面で済ませたい、というのが出発点です。

 何ができるか指定ルート配下の画像を再帰スキャンして 1 枚の静的 HTML にカード一覧で並べる
ファイル名やパスから自動でタグ付け (キャラ名 / シーン / バリエーション番号など)。タグでの絞り込みと、自由語の検索も同居
カードにカーソルを当てると、別領域に拡大プレビューが出る (一覧 → カーソル合わせ → 即拡大、の流れで判断が速い)
手動マーク Final / ★ / ✓ / ? / Trash、マーク別フィルタ
Compact / Full のカード密度切替、サムネクリックで lightbox 拡大 + キー操作
Final 選択の Windows パス一括コピー / JSON export

 実装と気付きPython ジェネレータ + 単一 HTML + localStorage。最初は A/B 比較スロットを付けたのですが、タグとマークが比較の役割を兼ねるので削除しました。Trash も「ファイル削除」ではなく「通常ビューから隠す + Trash フィルタで Restore」と意味を絞ったほうが落ち着きました。
python tools/build_review_gallery.py
Start-Process .\docs\review_gallery\index.html


画像レビューギャラリーの実運用。タグで絞り込みつつカーソルで拡大プレビューを出し、マークで Final を抜き出すまでが 1 画面で完結する

 2. 音声 (BGM・SFX) レビューギャラリー
 何を解いたかBGM や SFX は普段は数本しか触りませんが、BGM の方向性を決めるとき / SFX を一斉に発注し直すときには候補が数十〜数百本まとめて出てきます。メディアプレーヤーで順に流すことはできますが、特定の候補にワンクリックで飛んだり、「これは Final」「これは Trash」と気軽にマークを残したりはできません。1 ページに並べて、ワンクリック試聴 + マーク + 絞り込みまで含めて回したい、というのが要求でした。

 何ができるかSuno / AIVA / Studio One 由来の BGM 候補と、採用済みの runtime music を 1 ページに並べて連続試聴
HTML5 <audio> の 共有プレイヤー1個 で、別曲を再生すると前の曲は止まる

Loop selected と Auto next で「全部聴く」運用が成立
マーク: Final / Pick / Keep / review / Trash + Unfinal (Final だけ外して Trash には送らない)
BGM と SFX は同じツールに別 config を食わせる形で運用 (build music / build sfx でターゲット切り替え、出力 HTML が index.html と sfx_review.html に分かれる)。本記事ではこの 1 本として数えています

 実装と気付き画像版の UI をそのまま流用したくなるところですが、音は並べても結局 1 曲ずつ順に聴く形になるので、UI の主役は 一覧 + 共有プレイヤー1個 + Auto next で「順送りで全部当てる」流れに整えました。共通モジュール tools/media_review_gallery/ を切り出して、画像版と音声版はその上に乗る薄いラッパとして再整理しています。
python tools/build_music_review_gallery.py
Start-Process .\docs\music_review_gallery\index.html


BGM レビューギャラリーの基本表示。共有プレイヤーは右側に 1 個だけ。カードから Play すれば前の曲は止まる

 3. フォントプレビュー
 何を解いたか日本語フォントを単体で見比べても、実際のゲーム UI に載ったときの印象は分かりません。OS 標準のフォントビューアは 1 書体ずつしか見られず、Web 上の試着ページもサンプル文字列が固定で、ゲームの会話窓そのものに乗せた状態で複数候補を並べる手段がありませんでした。本文 + 選択肢 + 場所ラベル + 数値表記を同じレイアウトに乗せて、フォントだけを差し替えて side-by-side で見たい、というのが出発点です。

 何ができるか同じダイアログサンプル (本文 / 選択肢 / 場所ラベル / 数値表記) で複数フォントを side-by-side に並べる
現在登録しているのは BIZ UDPGothic / Noto Sans JP / M PLUS 2 / DotGothic16 の 4 種。候補を増やすときは HTML に 1 ブロック追記するだけ

 実装と気付き単一 HTML + Web フォント (@font-face で系統別に読み込み)、生成スクリプトはありません。会話窓のレイアウト枠を CSS で 4 列並べて、それぞれにフォントだけ差し替えたコピーを置く構造です。単体で「読みやすい」と感じたフォントでも、選択肢列で並べると行間や数字の太さの違いが利く / 利かないが一気に分かります。ゲーム本体の TextMeshPro アセットを差し替える前に、HTML 上で 1 段階フィルタを挟むと判断が早いです。


会話窓 + 選択肢 + 場所ラベルを同じレイアウトに乗せて、フォントだけを差し替えて side-by-side で比較する

 4. iPhone / PC から見る開発状況ビューア (anemora-viewer)
 何を解いたか上の 3 本で PC でのレビューは回るようになりましたが、外出中や寝る前にも各 work branch の進捗を眺めるレビュー作業が残っていました。GitHub のスマホアプリでは画像スライドもファイルソートもできずレビュー導線として厳しかったので、専用のビューアを別で建てました。スマホ側で気付いたことは、Claude Code や ChatGPT のスマホアプリから次の指示として流せるので、外出中も同じレビュー導線が走っている状態を作るのが狙いです。

 何ができるか各 work branch の docs/review/<日時>/ 配下の画像を、ブランチ別アルバム + Pin + 検索で iPhone から閲覧
開発ログ (以下 devlog、docs/devlog/ 配下に逐次 commit している作業記録のことです) や設計メモなどの Markdown ドキュメントも Pagefind で全文検索
普通の Web サイトとして開きつつ、iPhone のホーム画面に追加すればアプリのように使える (PWA = Progressive Web App と呼ばれる形態)。PC 幅も同 URL でレスポンシブ対応
Cloudflare Pages デプロイ、認証なし。検索避けとして robots.txt で Disallow を入れている (公開ルールの扱いは「§6 公開ルールを揃える」で詳述)

 実装の要点Astro 5 + React 18 + Tailwind + PhotoSwipe + Pagefind + Workbox。ホーム画面に追加した状態のキャッシュ (Service Worker) は iOS Safari の 50MB 上限に当たるため、precache は shell + assets だけ (420KB)、各ページは NetworkFirst の runtime cache で取る形にしています。


iPhone から見たビューアの Review タブ。1 ブランチに溜まった作業サイクルが新しい順に並ぶ
公開 URL: https://anemora-viewer.pages.dev/

 どのように作ったか (代表ケース: anemora-viewer)「Claude Code で気軽に組み上がる」と書いてきましたが、実際にどんなテンポで作っているのか、代表として直近の anemora-viewer (§4 のビューア) を例に、思いついてから公開まで 1 日で走った流れを書きます。他の 3 本もほぼ同じ手順をなぞっているだけです。

 1. 問題に気付くある朝、移動中に GitHub のスマホアプリで各 work branch の画像を眺めようとして、画像スライドもファイルのソートもできないことに不便を感じました。Working Copy 経由の git 同期も試してはいましたが、Markdown を読むだけならともかく、画像群をブランチごとに眺めるには遠回りです。外出中に進捗をレビューする用の小さい Web アプリを作れないか、まずは方針から相談したい、と Claude Code に持ちかけたのがスタートでした。

 2. Plan モードで 5 案を並べるいきなりコードに入らず、Plan モードで方針候補を 5 案ほど並べてもらいました。


案
UX
必要環境
費用


A. Working Copy + Obsidian チューニング
★★
iPhone のみ
$0

B. 静的 PWA + Cloudflare Pages
★★★★
iPhone + CF
$0

C. 動的 Web (GitHub API + Workers)
★★★★
iPhone + CF + PAT
$0

D. iOS ネイティブ (Swift)
★★★★★
Mac + Xcode
$99/年

E. 自宅 PC + Tailscale
★★★
自宅 PC 24h 稼働
$0

スマホ側の操作の手触りを最優先したかったので D もいったん検討対象に入れましたが、Mac / Apple Developer Program なし + 無料の枠で UX をネイティブの 7〜8 割まで持っていける B 案 (Web サイト + ホーム画面追加で強化) に決定しました。

 3. 選択肢形式の質問で論点を順に確定するPlan モードで詳細プランを一括で書かせる代わりに、Claude Code に論点ごとの選択肢 (1〜3 個) を出してもらい (内部的に AskUserQuestion ツールが使われます)、順に確定していく方式に切り替えました。8 ラウンドに分けて、方式 → ホスティング → リポ構造 → 画面構成 → アルバム単位 → Docs Pin / 検索 → PWA / テーマ → グリッド / ソート、まで詰めて、終わったところで SPEC.md (約 360 行) を書き出し、後で誰が読んでも実装できる粒度に固めました。

 4. 実装で踏んだ罠仕様が決まっても、実装はそれなりに詰まりました。代表的なところ 3 つ。

sparse-checkout が動かない: 必要パスだけ取り込もうとして git clone --shared --no-checkout + sparse-checkout init で進めたらファイル 0 件。--shared clone は refs/remotes/origin/* をコピーしない、sparse-checkout init 後の直接書き換えが効かない、の合わせ技で詰まりました。git archive --format=tar SHA -- <paths> | tar -x に切替えて解決

PWA cache 50MB 上限: @vite-pwa/astro の default で precache が 54MB に達して iOS Safari に弾かれました。globPatterns を shell + assets だけに絞って 420KB に削減、各ページは runtime cache (NetworkFirst) で取る形に

iOS Safari の touch / bfcache: 横スワイプを実装したら 2 回スワイプで詰まる現象が出ました。addEventListener('touchmove', ..., { passive: false }) を useEffect で直接 attach + pageshow で bfcache 復元時に location.reload()、まで 4 コミットかけて解決

 5. デプロイ → iPhone で実機フィードバック → 即修正Cloudflare API token を発行してしまえば、Cloudflare Pages プロジェクト作成・GitHub source 設定・Deploy Hook 発行・anemora 本体への webhook 登録までは Claude Code 側で代行できます。初回ビルドは約 13 分、以降は warm runner で 5〜7 分。
ビューアが動き出してからは、iPhone でアクセスしてフィードバック → Plan モードに戻して仕様変更 → 即修正、のサイクルに入りました。例えば「あるディレクトリで next を押すと別ディレクトリの album に飛んでしまう」という現象から、開いている album のパスが docs/review/* 配下なら review 内で前後、それ以外なら全 album 内で前後、という context-aware prev/next を後から加えました。似たディレクトリ移動のクセは他の画面でも数回踏んで、その都度同じパターンで直しています。

 6. 公開ルールを揃える最後に viewer の公開ルールを揃えました。Cloudflare Pages 上に認証なしの公開サイトとして置きつつ、検索避けとして public/robots.txt で Disallow: / + <meta name="robots" content="noindex, nofollow"> を設定しています。
ただしこれはアクセス制御ではありません。URL が漏れれば誰でも見られますし、noindex を守らないクローラも存在します。よって viewer には「公開されて困らない素材だけ載せる」前提で運用しています (たとえば未公開のストーリー素材は anemora 本体の private branch に閉じてあり、viewer には流れません)。本当に未公開情報も扱いたいなら Cloudflare Access のような認証層を足す必要があります。
anemora 本体の README 冒頭に viewer URL の 1 行案内を載せて、URL を渡した相手から自然に届く範囲を狙っています。
最初のアイデアから、デプロイ済み + 公開ルール明文化までその日のうちに収まりました。他の 3 本もほぼ同じ手順 (① 問題に気付く → ② Plan モードで案比較 → ③ 選択肢形式の質問で論点確定 → ④ 1 セッションで初版 → ⑤ 実運用フィードバックを Plan モードに戻す → ⑥ 公開ルールを後付け) で組んでいて、用途の小ささに対して開発の重さがほぼ見合います。

 おわりにAI に本体実装を任せる開発スタイルでは、自分の手は「生成」よりも「選んで残す」側、つまりレビュー作業に時間が回るようになります。レビューの粒度に合うサービスは存在せず、これまでなら自作コストが見合わずに諦めていた中間サイズのツールも、Claude Code に Plan モードで相談すれば、着手を引き伸ばさずにその場で動く形にできる、というのが今の感触です。本記事の 4本も、改まったプロジェクトとして起こしたものは 1 本もなく、本体開発の合間にレビューの不便を感じたタイミングで都度組んだものです。
同じ感触でレビュー周りの用途は今後も増えそうですし、同じ枠でその都度足していく予定です。本体の進捗もレビュー導線もまとめてビューアから追えるようにしてあるので、よければ https://anemora-viewer.pages.dev/ を眺めにきてください。
なお Anemora そのものを試したい方は 体験ビルド に「時の窓」を触れる小さなスライスを公開しています。AI 中心開発のセッション運用については Codex CLI の同期設計 / Cycle 運用 で書きました。
案	UX	必要環境	費用
A. Working Copy + Obsidian チューニング	★★	iPhone のみ	$0
B. 静的 PWA + Cloudflare Pages	★★★★	iPhone + CF	$0
C. 動的 Web (GitHub API + Workers)	★★★★	iPhone + CF + PAT	$0
D. iOS ネイティブ (Swift)	★★★★★	Mac + Xcode	$99/年
E. 自宅 PC + Tailscale	★★★	自宅 PC 24h 稼働	$0
GitHubで編集を提案
TL;DR

背景 — AI 中心開発でレビューがボトルネックになる

他のレビュー用途にも転用できる 3 つの設計パターン

ツール紹介

1. 画像レビューギャラリー

何を解いたか

何ができるか

実装と気付き

2. 音声 (BGM・SFX) レビューギャラリー

何を解いたか

何ができるか

実装と気付き

3. フォントプレビュー

何を解いたか

何ができるか

実装と気付き

4. iPhone / PC から見る開発状況ビューア (anemora-viewer)

何を解いたか

何ができるか

実装の要点

どのように作ったか (代表ケース: anemora-viewer)

1. 問題に気付く

2. Plan モードで 5 案を並べる

3. 選択肢形式の質問で論点を順に確定する

4. 実装で踏んだ罠

5. デプロイ → iPhone で実機フィードバック → 即修正

6. 公開ルールを揃える

おわりに

Discussion
