エディタがないのは負債ではなく設計：AI 時代のゲームアートパイプライン

私たちのゲームプロジェクト——エンジン層は Rust + Bevy、ゲームプレイは Lua、開発は AI エージェント、アートは Floniks が生成——を人に見せるたび、最初の質問はほぼ決まって同じです。

「面白いですね。でも……エディタはどこですか？」

正直に言うと、私たちも迷いました。この二十年、「ゲームエンジン」とは決まった一枚の絵を意味してきました。左にシーンツリー、中央にビューポート、右にインスペクタ、下にアセットブラウザ。Unity もそう、Godot もそう、Unreal も Cocos もそうです。あの絵がなくて、エンジンを名乗れるのか？

エージェントと共に 8 本のミニゲームを実際に作り上げ——AI 生成のスプライトや背景、UI アートが Floniks の MCP サーバーから流れ込んでくる——ようやく答えがはっきりしました。私たちの作り方にとって、エディタは「まだ作っていないインフラ」ではなく、負債です。「エディタがない」ことは借金ではなく、土台なのです。

この記事はその理由を振り返り、さらに重要なこととして、エディタの代わりにアートとビジュアルへ何を装備したのかを棚卸しします。以下の主張はすべてオープンソースリポジトリの実在するファイルに裏付けられています。ロードマップのスライドではありません。

エディタとは結局何なのか

ノスタルジーを剥がせば、ゲームエディタの本質は I/O アダプタ——人間の手（マウス、ドラッグ、スライダー）をシーンデータに接続する装置です。

エディタが最適化しているのは人間の入力帯域です。人は position: (312.5, -87.0) を頭の中で思い描けないから、ドラッグして目で確かめる必要がある。四千個の API を暗記できないから、全プロパティをパネルに並べるインスペクタが要る。感覚では色を合わせられないから、カラーピッカーが要る。エディタのウィジェットひとつひとつが、人間の感覚と筋肉への譲歩です。五十年間、その譲歩は完全に正しかった——操作者が常に人間だったからです。

しかしコストもずっと帳簿に載っていました。私たちが見なくなっていただけです。

1. シーンファイルは機械のためのもので、人間のためのものではない。 バイナリか半可読の .unity / .prefab / .tscn は、読めない diff、祈りに頼るマージ、「エディタを開いて見てくれ」というコードレビューを生みます。
2. ビューポートは嘘をつく。 エディタのライティングやインポート設定は、出荷ビルドと微妙に一致しません。「自分のエディタでは正常だった」は業界共通のオチです。
3. 一貫性は構造ではなく規律に依存する。 スタイルガイドは wiki に眠り、三人のアーティストは三種類の輪郭線を描きます。エディタは座標を制約できても、審美眼は制約できません。

操作者が人間からエージェントに変わると、この帳簿は反転します。エージェントには配慮すべき目も手もなく、ネイティブの I/O はテキストです。エージェントに GUI を与えるのは魚に自転車を与えるようなもの。しかも上記の三つの隠れたコストは、エージェントワークフローの急所に正確に命中します。

だから選択は単純でした。エージェントが使えないインターフェースを作らない。エディタの各職務を、エージェントネイティブな形に置き換える。

エディタの代わりに何を装備したか

エディタには五つの中核職務があります：スタイルを定める、アセットを管理する、コンテンツを配置する、パラメータを調整する、結果をプレビューする。それぞれが何に置き換わったかを見ていきます。

1. スタイルを定める：実行可能なスタイルバイブル

従来のパイプラインでは、アートディレクターのスタイルガイドは PDF です。二週間後、誰かが外注メールでそれを言い換え、パレットが漂流し始めます。私たちはスタイルバイブルをコードとして書きました（tools/style_bible.py）。ファイル冒頭にその哲学が記されています。

「スタイルバイブルの唯一の仕事は、将来のすべてのアセットが同じ手から生まれたように見せることだ。その失敗モードはドリフトである……ロックされたトークンをデータ + 小さなアセンブラとしてエンコードすれば、ドリフトは構造的に消滅する——共有 DNA は毎回文字通り同じ文字列であり、変わるのはアセットごとの主題スロットだけだ。」

パレット、輪郭線のルール、カメラアングル、構図——すべてロックされた定数です。各アセットが埋めるのはただ一つのスロット、その主題だけ（"a cute shiny red apple with a small glossy green leaf"）。ゲーム全体のテーマを変えたい？パレットスイッチを一つ切り替えて全部再生成すればいい。スタイルの一貫性はアーティストの規律であることをやめ、プログラムの保証になります——エディタには原理的に提供できないものです。エディタが制約するのは座標であって、審美ではないからです。

2. アセットを管理する：宣言的マニフェスト

ここではアートにソースコードがあります。tools/floniks_manifest.json の一行が、一つのアセットの全真実です。

{"name": "gem", "w": 16, "h": 16, "bg": "alpha",
 "subject": "a cute glowing teal diamond gem, faceted, glossy"}

名前、正確なピクセルサイズ、背景キーイングモード（透過切り抜き / 青ベタキーイング / 発光を残す黒 / 全面テクスチャ）、主題の記述。アセットは「ある生成実行の産物」ではなく、「いつでもマニフェストから再生できる結果」です。 ファイルを失った？再実行。全セットを 2 倍解像度にしたい？w/h を変えて再実行。これはゲームアートの Infrastructure-as-Code です。

3. アセットを作る：Floniks パイプライン

マニフェストの実行者は、MCP 経由で Floniks に乗った自動パイプラインです。

スタイルバイブルがプロンプトを組み立て → Floniks でテキストから画像生成
  → ダウンロード → 背景をキーイングで除去（モードごとに較正済みの許容値）
  → 目標ピクセルへ正確にリサイズ → assets/textures/ へ配置
  → 人間の抜き取り検査用に 8 倍ニアレストネイバー拡大プレビューも出力

連番フレームはシートスライサーを通ります。スプライトシートを生成し、walk_0.png … walk_7.png に切り分け、Lua の十行のフレームタイマーがアニメーションシステムになります。パイプラインで得た教訓はコードコメントに沈殿しています——どのモデルが実際にどの背景指定を尊重するか、どの API がどんなパラメータ形式を要求するか。傷跡は誰かの記憶ではなく、パイプラインの一部になったのです。

その下にはセーフティネットがあります。標準ライブラリのみの手続き型ジェネレータが、依存ゼロでプレースホルダー一式を生成します。ゲームはどの瞬間も実行可能です。 AI アートはアップグレードであって、依存では決してありません。

4. コンテンツ配置とパラメータ調整：契約とホットリロード

シーンツリーとインスペクタは、二つのものに置き換わりました。

• 契約。 一枚のページ（ART_REQUESTS.md）が宣言します：同じファイル名と同じピクセルサイズで置かれたアセットは、コード変更ゼロで即座に反映される。もう一枚（PACK_SPEC.md）は完全なゲームパックを定義します：ファクトリ関数、自己登録テーブル、使用可能テクスチャの一覧、そしてヘッドレステストが駆動できるよう DEBUG テーブルを公開する義務。メニューは登録テーブルから自動生成されます。どこにも GUI でクリックする工程はありません。
• ホットリロード。 配置も調整もすべて Lua ソース内の数値です——そして Lua、テクスチャ、WGSL シェーダーまでもがエンジンのアセットパイプラインを通るため、デスクトップでは保存した瞬間に反映されます。リンゴをもっと速く落としたい？数値を変えて、保存して、見る。インスペクタのスライダーは「テキスト + 秒単位のフィードバック」になりました——人間にも悪くなく、エージェントには唯一使える形です。

5. プレビュー：実行中のゲームこそがビューポート

私たちにエディタビューポートはありません。プレビューウィンドウは実行中のゲームプロセスそのものだからです——WYSIWYG の最終形。インポート設定のずれも、エディタとビルドのライティング差もなく、あなたが見るすべてのフレームはプレイヤーが見るフレームです。ランタイムのビジュアル API が表現力を支えます：染色可能なグレースケールスプライト（一枚のテクスチャから色のファミリー）、回転、リサイズ、フレーム差し替え、そしてゲームプレイに文字通り反応するフルスクリーン WGSL オーロラシェーダー——各ゲームの画面シェイクのフィードバックが背景のエネルギーも駆動します——さらにトラウマ減衰カメラシェイク、四段階のハプティクス、合成サウンド。

検収も目視に頼りません。677 行のヘッドレス不変条件スイートが各ゲームを数万フレーム駆動し、「ゲームフィール契約」をアサートします——すり抜けなし、テレポートなし、速度上限、ヒット時の必須フィードバック。エディタは人間に見せる。テストはエージェントに見せる。

なぜこれがエディタを超えるのか

五つの部品を組み合わせると、エディタには原理的に提供できない能力が得られます。

1. アートを丸ごと再生成できる。 スタイルトークンを一つ変更 → マニフェストを再生 → 一時間以内に完全に一貫した新アートセット。エディタパイプラインではこれを「三週間の手戻り」と呼びます。
2. アートをコードレビューできる。 アート変更の PR はマニフェストの diff とプレビュー画像です——ロールバックでき、blame でき、輪郭線が太すぎないかコメント欄で議論できます。バイナリのシーンファイルには決してできないことです。
3. 一貫性は要求されるのではなく、構築される。 同じプロンプト DNA、同じ許容値テーブル、同じピクセル化工程。「新人アーティストがルールを知らなかった」は存在しません。
4. ゲームプレイとアートが同じループを共有する。 一つのエージェント、一つのセッション：Lua を調整し、新アセットの必要に気づき、Floniks を呼び、契約に従って配置し、ホットリロードし、テストを走らせ、コミット。従来のパイプラインなら二つの部署とインポート工程と会議が要ります。
5. 会話こそがエディタ。 「リンゴをもっと赤く、ハイライトをもっと艶やかに」——この一文が完全な編集操作です。エージェントがマニフェストの主題を書き換え、パイプラインを再生し、ホットリロードが結果を見せます。エディタは意図をマウスの軌跡に写像し、私たちは意図を自然言語に写像します。後者の上限が高いのは明らかです。

そして正直なコストも記しておきます。このフローは操作者が「一人の人間 + 一つのエージェント」であることを前提にしています。 エージェントを介さずに働く従来型のアーティストやレベルデザイナーには、今日ここに立つ場所がありません。数百のオブジェクトを手作業で配置するタイプのレベルにも、快適なツールはまだありません（おそらくの答え——データとしてのレベル、エージェント生成、不変条件テスト——はロードマップにあり、リポジトリにはまだありません）。五十年のエディタ人間工学は本物です。エディタが間違っていたのではなく、エディタが最適化する対象——人間の手——が、私たちのループのボトルネックではなくなったのです。

今日出力できるもの

形式	パイプライン	状態
透過背景スプライト	Floniks 生成 → キーイング → 正確なピクセルへリサイズ	✅ 本番稼働（リポジトリに約 60 枚）
染色可能グレースケールテクスチャ	同上 + ランタイム染色	✅ 本番稼働
連番フレームアニメーション	スプライトシート → スライサー → フレーム差し替え	✅ パイプライン稼働
フルスクリーン背景 / アリーナ	縦型生成、全面モード	✅ 本番稼働
UI アート（ボタン、装飾）	同じスプライトパイプライン	✅ 本番稼働
手続き型ダイナミック背景	手書き WGSL、ゲームプレイ反応型	✅ 本番稼働、ホットリロード対応
効果音 / ループ音楽	現在は合成 WAV、次は Floniks のテキストから音楽生成	✅ / 🔶
フォント	TTF をそのままバンドルへ	✅
マーケティング素材	スクリーンショットは収録済み、画像から動画でトレーラー	🔶

未対応：スケルタル（Spine 型）アニメーション、パーティクル、タイルマップ。いずれにも具体的な計画があり、その「エディタ」もまたデータ + AIGC です——リグはエージェントが書ける JSON ファイルで、Floniks がレイヤー分けされたパーツを生成し、タイルセットはスタイルバイブルから生まれます。主要エンジンとの完全な比較表と四段階ロードマップはリポジトリの docs にあります。

クロスプラットフォームなのか？

三つの層で、ぼかさずに答えます。

アセット層：100% ポータブル、ロックインゼロ。 すべてが PNG、WAV、TTF、WGSL、Lua、JSON です——独自シーンフォーマットも、エディタプロジェクトファイルも、インポートデータベースもありません。WGSL は Metal / Vulkan / DX12 / WebGPU にコンパイルされます。明日このスタックを捨てると決めても、すべてのアセットは無傷で持ち出せます。 その自由はエディタを持たないことの副産物です。

エンジン層（Bevy）： 三大デスクトップ OS、Android、iOS、Web（WASM/WebGPU）すべてが上流でサポートされています。Lua とエンジンの間のコマンドキューブリッジはプラットフォーム非依存です。

このプロジェクトが今日接続済みのもの： 開発用の macOS（ホットリロード付き）と、シミュレータおよび実機の iOS——Metal、120 Hz ProMotion、自動署名、TestFlight パイプライン。一つの Rust クレートが両方をビルドします。Android と Web はロードマップ上のパッケージング作業であり、アーキテクチャ上のリスクではありません。

よくある質問

自分のゲームがこのスタックでなくても、このアセットパイプラインは使えますか？

はい。このパターン——プロンプトトークンをロックするスタイルバイブル、各アセットの名前・サイズ・キーイングモードを宣言するマニフェスト、Floniks で生成して正確なピクセルへ後処理するスクリプト——は、フォルダから PNG を読み込むあらゆるエンジンで機能します。リポジトリのツールは小さな Python ファイルで、半日もあれば自分用に改造できます。

アセット生成にはクレジットがかかりますか？

はい。Floniks 経由の生成呼び出しは使用モデルに応じてクレジットを消費し、失敗したタスクは自動的に返金されます。エージェントはバッチ実行の前に get_credit_balance を呼んで予算を確認できます。

生成されたアセットがスタイルに合わなかったら？

低コストで振り直せます。すべてのアセットはマニフェストに宣言されているので、一枚——あるいは全セット——の再生成はレシピの再生であって、作業のやり直しではありません。スタイルバイブルがすべての試行を同じロック済みパレットと構図ルールの中に保つため、リトライを重ねてもドリフトは蓄積しません。

プロンプトを手で書く必要はありますか？

いいえ。スタイルバイブルが共有のスタイル DNA を自動で組み立て、各アセットは主題だけを宣言します。エージェントワークフローでは、その主題の一文さえ、たいていはあなたの一言のリクエストからエージェントが書きます。

エディタは死んでいない。形を変えたのだ。

エディタの職務	私たちの形
スタイルガイド PDF	実行可能なスタイルバイブル（ロックされたプロンプト DNA）
アセットブラウザ / インポート設定	宣言的マニフェスト + 再生可能なパイプライン
シーンツリー / ドラッグ&ドロップ	契約 + 自己登録
インスペクタのスライダー	ホットリロードされる Lua ソース
エディタビューポート	実行中のゲーム + ヘッドレステスト
マウス操作	自然言語の会話

五十年間、ゲームツールのあらゆる進歩は同じ問いに答えてきました：創作者の意図はどうすればより速くピクセルになるのか？創作者の隣にエージェントがいる今、最短経路はもう GUI を通りません。私たちはエディタを作りそびれたのではなく、その労力を「一言で言う」ことを最短経路にするために使ったのです。

この賭けが正しいかどうかは、リポジトリの 8 本のゲーム、ツリーの中の 60 枚の AI 生成アセット、そしてそのすべてを 120 Hz で動かす一台の iPhone が、これからも代わりに答え続けてくれます。

---

ここで言及したすべてはオープンソースリポジトリで検証できます：maweis1981/rust_bevy_lua_game——tools/style_bible.py、tools/floniks_manifest.json、tools/floniks_build.py、tools/PACK_SPEC.md、およびエッセイシリーズ全体は docs/ を参照。Floniks を自分のエージェントに接続するには、MCP 開発者ガイドから始めてください。