MCP サーバー経由で AI エージェントに Floniks を渡し、テンプレートライブラリの穴を埋めるよう依頼しました。その後の一時間で、エージェントはノードカタログを調べ、三本のマルチステップ・パイプラインを設計し、実行し、実際のバグを二つ踏み、両方とも原因を突き止め、設計を組み直して回避し、成果を公開テンプレートとして公開しました。エディタは一度も開かれていません。以下はその記録です。
これを書いているのは、面白いのが「エージェントが画像を生成した」ことではないからです。それができるツールは今や珍しくありません。面白いのはデバッグの過程です。
依頼内容、そしてそれが本物だった理由
テンプレートライブラリには穴がありました。絵コンテ、TVC プレビズ、ショートドラマの企画といった商用のプリプロダクション業務を狙ったランディングページはあるのに、約 400 本のワークフローテンプレートのうち、それらに実際に応えるものはゼロでした。検索から来た人は、クリックする先がなかったのです。
そこで依頼は具体的でした。穴を見つけ、それを埋めるパイプラインを設計し、動くことを証明し、公開する。
ステップ 1：まず状況を把握する
エージェントの最初の一手は、何かを生成することではありませんでした。list_node_types を呼び、カタログを読み返したのです——入力・処理・AI モデル・出力の四分類にまたがる 33 種類のノード。続いて list_model_aliases を呼び、どのモデルが有効で、一回の実行にいくらかかるかを確認しました。
そして予想外のことをしました。get_workflow で既存の動作するテンプレートを取得し、そのノードとエッジの JSON を研究してから、自分のものを書き始めたのです。推測するのではなく、すでに成立している形を写す。
ステップ 2：最初に壊れたもの
最初のパイプラインは storyboardSplit ノード——脚本をショットリストに変換する LLM ステップ——を使いました。エージェントは配線し、実行し、ジョブはステップ 1、6 パーセントで止まったまま、二度と動きませんでした。
エラーなし。失敗ステータスもなし。ただ永遠に終わらないタスクです。
エージェントは自分が保存したグラフに get_workflow を呼び、送ったものと保存されたものを突き合わせました。差異は一行だけ。storyboardSplit ノードが "model": [] を伴って返ってきていた——モデルを必須とするノードに、空のモデル配列。これは我々側のバグであり、しかも厄介な種類のものです。自分を表に出さないからです。型チェックは通る。保存も成功する。実行だけが終わらない。
エージェントは修正を待たず、設計をやり直しました。LLM 分割器を外し、代わりに四つの明示的で編集可能なショットプロンプトを使ったのです——結果として、こちらの方が良いテンプレートになりました。ユーザーは不透明な分割に委ねるのではなく、各ショットを直接見て編集できます。
ステップ 3：二番目に壊れたもの、そして製品を良くした修正
作り直したパイプラインは動きました。ただし返ってきた画像は四枚ではなく、きっかり一枚でした。
真っ先に思いつくのは「ノードが不安定だった」です。エージェントはその読みを鵜呑みにせず、検証しました。同じグラフをもう一度実行したのです。二回目も一枚だけ——しかし別の一枚でした。一回目はフレーム 2、二回目はフレーム 1。
これでノードの故障は否定され、疑いは実行エンジンに向かいます。エージェントのグラフは互いに独立した四本の鎖でした——プロンプト四つ、生成ノード四つ、出力四つ、どれも接触していない。つまり四つの非連結な部分グラフです。先に研究した動作するテンプレートは、すべての分岐が単一の共有ルートから伸びていました。結論：複数出力の実行には、グラフ全体が単一の連結成分である必要がある。
修正の仕方がここからが本題です。エージェントはダミーの共有ルートを継ぎ足すのではなく、フレームを鎖状につなぎました——各フレームが直前のフレームを視覚リファレンスとして生成されるように：
プロンプト 1 → フレーム 1 ─┬→ 出力 1
└→ フレーム 2 ─┬→ 出力 2
└→ フレーム 3 → …
単一の連結成分になったので、実行エンジンはすべての出力を返します。そして各フレームが直前を参照するため、同じ人物が四つのショットを貫きます——このテンプレートが解こうとしていた問題そのものです。ランタイムの制約が機能に変わりました。
ステップ 4：成果物を見て初めて分かる細部
最初に成功した実行は 2048×2048——正方形——で返ってきました。プロンプトには平易な言葉で 16:9 の画角を指定していたにもかかわらず。
アスペクト比はモデルのパラメータであり、文章の中で述べる提案ではありません。エージェントは get_model_params を呼び、aspect_ratio の既定値が 1:1 で、許容値に 16:9 が含まれることを確認し、ノード設定に書き込んで再実行しました。二回目は 2560×1440。
小さなことですが、重みがあります。自分のプロンプトしか読まないエージェントなら、正方形の絵コンテを公開して、そのことに永遠に気づかなかったでしょう。このエージェントは成果物を確認しました。
何が公開されたか
三つのテンプレート。それぞれ実際に生成された四枚をプレビューとして持っています：
- Script → 4-Shot Cinematic Storyboard——16:9。TVC プレビズと広告企画向け。
- Short Drama: Script → 4 Vertical Key Scenes——9:16。物語の展開に合わせてカラーグレードが冷たい青から暖かい金へ意図的に移動します。
- Character Sheet: One Description → 4 Consistent Views——正面、四分の三、全身、そしてロケーション撮影の一枚。
三つともテンプレートライブラリで公開中です。そして三つとも、エディタを一度も開くことなく、MCP サーバー経由で作成・実行・検証・公開されました。
本当に効いてくるところ：プロンプトではなくアセット
先の三つのテンプレートはパイプラインです。その下にあるより大きな発想は、被写体を毎回記述し直す対象として扱うのをやめたときに何が起きるか、という点にあります。
Floniks は二種類の永続アセットを保持します。create_character は参考シート——正面・側面・背面のビュー——を作り、そのキャラクターの正典となる見た目として保存します。create_location は二つを生成します。映画的な設定ショットと、同じ場所を異なるカメラアングルから捉えた六分割グリッドです。ロケーションはさらに persistent_props——そこで撮るたびに必ず登場すべき物——と time_of_day を持ちます。
この最後の細部こそが要点です。小道具リストがプロンプトではなく場所に紐づいているからこそ、同じひび割れた鏡が第一話でも第四十話でも同じ角に置かれ続けます。
被写体がアセットになった瞬間、経済性が反転します。人物をプロンプトで描写するのは、毎回サイコロを振り直すことです。アセットを参照するコストはほぼゼロで、素材が積み上がるほどより安定していきます。
そこから開くものの一部：
- 専属モデル。 一人を鋳造し、日々のコーディネート、ヘアチェンジ、季節のルックブック、旅先の背景を通していく。月曜と金曜で顔がぶれないので、フィード全体が素材集ではなく一人の人物として読めます。
- 常設セット。 カフェ、ショールーム、アパート——
persistent_propsで連続性を固定し、time_of_dayで夜明け・昼・夕暮れ・夜の同一空間を出し分けます。 - 連続ドラマ。 キャラクターとロケーションの併用。第十二話は第一話のキャストとセットをそのまま再利用でき、どちらも誰かが記述し直す必要はありません。
- ブランドマスコット / バーチャルホスト。 一つのキャラクターアセットから、キャンペーン・季節・告知のバリエーションを無限に——すべて紛れもなく同一の姿で。
- デジタル代弁者。 キャラクターをアバターと音声の機能に接続すれば、同じ司会者があらゆる解説動画に、任意の声で登場します。カメラは不要です。
- 一度の撮影の多言語版。 同じキャラクター、同じセットで、市場ごとに音声と焼き込み字幕を差し替える。
- 音楽と MV。 リリースを跨いで一貫したアーティスト像を保ち、同一グラフ内で
textToMusic、audioBeatDetect、tempoMatchedCutが映像をトラックに合わせて刻みます。 - 制作バイブル。 漫画・ゲーム・アニメでは、キャラクターシートそのものが納品物です。正面・側面・背面のグリッドは、まさに美術チームが手元に置くものです。
正直に言うべき欠落が一つ。現時点で商品／SKU のアセット型はありません。 キャラクターとロケーションは一級市民ですが、商品はそうではありません。EC の仕事では、商品画像をワークフロー内の参照画像として渡します——それで機能しますし、当社の商品撮影テンプレートはそう動いています——が、保存され参照可能な SKU とは別物です。次に来るべきアセット型として明白であり、我々もそう認識しています。
三つを組み合わせたとき——保存されたアセット、保存されたパイプライン、その両方を呼べるエージェント——日常的な産出に人が介在する必要がなくなります。エージェントがキャラクターを一覧し、選び、パイプラインを回し、公開する。このループこそが、これら全てを作る価値の理由です。
「画像を作るエージェント」との違い
多くのクリエイティブ系 MCP サーバーが公開しているのは生成エンドポイントです。モデルを指定して画像を頼めば、URL が返ってくる。エージェントはリモコンです。
今回エージェントがしたことは、質的に違います。利用可能な部品を読み、マルチステップのグラフを組み立て、実行し、実行ステータスではなく成果物を検査し、欠陥を二つ見つけ、それぞれに仮説を立て、片方は制御された二回目の実行で検証し、それに応じて設計を組み直しました。そして成果を、他人が再利用できる資産として公開しました。
それはリモコンではありません。「モデルを呼ぶ」と「パイプラインを所有する」の違いです——そしてそれが可能なのは、レンダリング結果だけでなく、ワークフローグラフそのものが API から到達可能だからです。
ついでに言えば、この二つのバグは有り難くいただきます。この形で見つかる方が、見つからないよりずっと良い。
よくある質問
MCP サーバーを使うのにコードは必要ですか？ 不要です。Claude Desktop などの対応クライアントで Floniks を MCP サーバーとして接続し、あとは普通の言葉で頼むだけです。ツール呼び出しは代行されます。
エージェントの実行はクレジットを消費しますか？
します。エージェント発の実行も自分で始めた実行と同じ残高を使い、モデルごとの一回あたりのコストは実行前に list_model_aliases で確認できます。エージェントは先に get_credit_balance を呼ぶこともできます。クレジットに有効期限はありません——アカウントに入ったら、使い切るまでそのまま残ります。
ワークフローが途中で失敗したらどうなりますか？
失敗した実行のクレジットは自動的に返還され、get_task が失敗ステータスとともにエラーを返すので、エージェントは再試行するか、パラメータを変えるか、設計し直すかを判断できます。上記の実行では、停止したジョブは使える出力を出さず、エージェントは盲目的に再試行せず方針を変えました。
エージェントは他人が使えるテンプレートを公開できますか？
できます。create_template がワークフローをプレビュー画像付きの公開テンプレートとして公開します。この記事の三つのテンプレートはそうやって世に出ました。
なぜ並列生成ではなく鎖状につなぐのですか？ 鎖にすると各フレームが直前を視覚リファレンスとして使えます。それが同じ人物をショット間で保つ仕組みです。並列の方が速いのですが、人物がぶれます——顔が変わり、服が変わる——そしてそれこそ、これらのテンプレートが防ぐために存在する失敗です。
試してみる
三本のパイプラインはテンプレートライブラリにあります——ひとつ開いて、ショットプロンプトを自分の物語に置き換えて実行してみてください。エージェントから動かしたい場合は、MCP サーバーが同じグラフを呼び出し可能なツールとして公開しており、ワークフローエディタではエージェントが実際に何を組んだのかを見られます。