プロジェクトの企画書はたった一文でした:「ミステリー・インタビューものにしよう」。そこからエージェントは、ミステリー×ライトホラーの尋問型ビジュアルノベルを出荷しました——3 人の証人はそれぞれ 3 種類の表情で顔が完全に一致、キャラクターごとに固有の合成ボイス、アンビエントな BGM、分岐ダイアログ、そしてブラウザで遊べるビルド。Floniks の 5 つの能力——text-to-image、image-to-image、背景除去、TTS、text-to-music——が 1 本のパイプラインで動き、エージェントがエンドツーエンドで統括。人間が書いたプロンプトはゼロです。
本稿は全 2 回の後編です。前編《スクリーンショット 1 枚から、パズルゲームを作る》はこの手法の土台を扱っています。
一文が入り、ゲームデザインが出てくる
「ミステリー・インタビューものにしよう」は次のように展開されました。明示的に要求されたものは 1 つもありません:
| 人間が言ったこと | エージェントが分解した内容 |
|---|---|
| 「ミステリー・インタビュー」 | 設定:名画《The Gazer(凝視者)》が深夜のギャラリーから盗まれる;3 人の証人を尋問し、表情を読み、犯人を告発する |
| (何も言っていない) | 職業・性格・秘密を持つ 3 人のキャラクター:テニスコーチ、経理、美術史講師 |
| (何も言っていない) | 素材仕様:3 キャラ × 3 表情、通常/不気味の 2 シーン、オープニングボイス 3 本、アンビエントループ 1 曲 |
| (何も言っていない) | タイプライター字幕と表情切り替えを備えた分岐ダイアログエンジン |
| (何も言っていない) | Lua の予約語の地雷(分岐フィールド名 goto)をリネームで回避 |
立ち絵パイプライン:同じ顔、4 つの段階
ビジュアルノベル最大の難所はキャラクターの一貫性——同じ顔が平静・緊張・恐怖の 3 状態を、透過背景で担わなければなりません。パイプラインは全行程 Floniks、MCP 経由です:
text-to-image のベース 1 枚が顔・衣装・佇まいを固定。image-to-image がそのベースから緊張と恐怖のバリエーションを派生——同じ顔のまま、表情だけが動く。背景除去が最終的な透過スプライトを産出。不気味なシーンも同じ方法:クリーンなギャラリー背景を image-to-image で「壁の絵がこちらを見ている」バリアントへ。
ボイス:キャラごとに固定の声色、計測器で検証
人間の要求は一行:キャラクターごとに性別に合った固有の声を固定すること。最初の「修正済み」はそれらしく聞こえました——追いの一言が音響分析を引き起こすまでは:3 つの声の基本周波数は実測 128、122、131 Hz。実質同じ声。まったく直っていなかったのです。
根本原因はパラメータのフィールド名ミス;プラットフォームは別の形の voiceId を期待していました。修正後の再計測:291、202、158 Hz——本当に異なる 3 つの声。キャラクターデータに声 ID を固定したので、再生成しても常に一貫します。
この教訓はあらゆる AI ワークフローに一般化できます:「直った」には計測器の読みが要る。印象では足りない。
スクリーンショット 1 枚の報告、3 つの根本原因
公開後、人間がスクショを 1 枚送ってきました:「声は出るが、誰も切り抜かれていない——3 人とも背景付きのままだ」。エージェントの処理チェーン:立ち絵 9 枚をすべて Floniks の背景除去へ;ついでに Web 版の無音を修正(ブラウザは初回操作まで AudioContext をサスペンドする);直した絵がまだ表示されないとき、第 3 の犯人——ブラウザキャッシュを特定し、テクスチャをリネームして突破。
症状の一文、エンジンのリファクタリング
開発終盤、人間が報告したのは解決策ではなく症状でした:「オーディオトラックの管理が混乱している——重なって積み上がる;体系的に解決して」。エージェントはエンジンのオーディオを3 チャンネルに再構築:効果音は重ねられるがフレーム内で重複排除;同じ曲の再リクエストで音楽は再スタートしない;ボイスチャンネルは新しいセリフの前に前のセリフを止め、会話が被ることは二度とない。パッチはバグを 1 つ直し、モデルはバグの類型ごと直す。コレクションの全ゲームがこれを継承しました。
5 つの能力、1 本のパイプライン
Floniks の各能力は、すでに待ち構えていたエンジン側の契約に着地します:
| 能力 | Floniks 側(MCP 経由のツール) | エンジン側(データが契約) |
|---|---|---|
| 立ち絵 | text-to-image ベース + image-to-image 表情 | テクスチャはファイル名でロード;呼び出し 1 回で表情切り替え |
| 切り抜き | 背景除去 | 透過 PNG がそのまま合成、エンジン改変ゼロ |
| ボイス | キャラごとに固定した TTS | 専用ボイスチャンネル:新しいセリフが古いのを止める、重なりなし |
| アンビエント | text-to-music | 二重再生しないミュージックチャンネル |
| ストーリー | ——(エージェントが分岐ツリーを直接書く;LLM がエディタ) | ホットリロードされる Lua;分岐データはプレーンテキストで diff 可能 |
前編と同じ結論が、ここではより鋭く:エージェントが速いのではない——道に関所がないのだ。 脚本、立ち絵、切り抜き、ボイス、スコア、テスト、デプロイ:1 セッション、手作業のファイル運搬ゼロ。
完全クロスプラットフォーム:同じスクリプトがネイティブでもブラウザでも
これはコレクションで最も要求の厳しいゲームです——立ち絵、ボイス、音楽、分岐ストーリー——そのすべてが、ネイティブ macOS、ネイティブ iOS の 120Hz、ブラウザの WebAssembly 上で、バイト単位で同一の 1 本の Lua スクリプトで駆動されます。ブラウザのオーディオアンロックのようなプラットフォームの癖はエンジン層が吸収し、スクリプトは何も知りません。本稿の 2 枚のスクリーンショットは、いずれもヘッドレスブラウザ内の WASM 版をライブ撮影したものです。
質問と回答
表情をまたいだキャラクターの一貫性はどう実現していますか?
キャラクターごとに text-to-image のベース 1 枚がアイデンティティを固定;緊張と恐怖のバリエーションは image-to-image でベースから派生させるため、変わるのは表情だけです。その後の背景除去で透過スプライトになります。
各キャラクターの声が変わらないことはどう保証しますか?
声 ID をキャラクターデータに固定し、TTS 生成のたびに同じ声色を再利用します——さらに修正は耳ではなく基本周波数の計測(291 / 202 / 158 Hz)で検証しました。
最初の一文の後、人間は何を提供しましたか?
一行の要求とバグ報告のスクリーンショットだけです。調査、分解、生成、デバッグ、オーディオエンジンのリファクタリングはエージェントの仕事でした。
ブラウザ版は本当に同じゲームを動かしていますか?
はい——同一の Lua スクリプトがバイト単位でネイティブと WASM ビルドを駆動し、エンジンが同一 API の背後でプラットフォームごとに Lua VM を切り替えます。
自分のパイプラインは Floniks MCP サーバーで接続を。この手法の出発点は前編でどうぞ。