この1年間のほとんどにおいて、「AI クリエイション」とは、人がキャンバスの前に座り、プロンプトを入力して生成をクリックすることを意味していました。それは優れた体験であり、私たちは Floniks をそこで卓越させるために多くの時間を費やしてきました。しかし、世界が向かっている先はそこではありません。画像を求めるものは、ますます人ではなく——エージェントになりつつあります。ローンチを計画している Claude のセッション。ブログ記事をソーシャル素材へと変えるスクリプト。シーンの絵コンテを描き、すべてのショットをレンダリングする多段階のパイプライン。こうした呼び出し元が欲しがっているのは UI ではありません。ツールです。
そこで私たちはそれを作りました。Floniks は今、Model Context Protocol（MCP）サーバーを同梱しており、Claude Desktop——あるいは MCP 互換のあらゆるクライアント——が私たちのクリエイション機能を直接呼び出せるようになりました。ラップされた単一のモデルではなく、プラットフォーム全体です。単一ステップ生成、多段階ワークフロー、保存したキャラクター、クレジット確認、そして結果の取得。Floniks の紹介をお読みになったなら、これはそのビジョンのうち、クリエイションがクリックして進めるものではなくなり、委任できるものになる部分です。
MCP が実際にもたらすもの
Model Context Protocol は、構造化されたツールを通じて AI エージェントを外部システムに接続するための、小さくオープンな標準です。エージェントに Web UI をスクレイピングさせたり HTTP 呼び出しを手作りさせたりする代わりに、型付けされた入力と出力を持つ名前付きツールの一式を公開し、いつ呼び出すかはエージェントが判断します。エージェントにはメニューが渡され、厨房はあなたが掌握し続けます。
Floniks にとって、そのメニューはクリエイションプラットフォームそのものです。私たちの MCP サーバーに接続されたエージェントは、どんなモデルが存在するかを発見し、静止画やクリップを生成し、保存したパイプラインを実行し、結果をポーリングし、自分にクレジットがいくつ残っているかを確認できます——すべて、人がステップをつなぎ合わせることなく。あなたがワークフローエディターで手作業で構築するのと同じノードグラフが、エージェントが自ら作成し実行できるものになるのです。
私たちが公開するツール
製品が既に動作している方法に近いかたちでツール表面を保ったので、UI で行うことと、エージェントがプログラム的に行えることの間にインピーダンスのミスマッチはありません。代表的なツールはいくつかのグループに分かれます。
単一ステップ生成。 single_task は AI Image および AI Video ページのエージェント呼び出し可能版です——ワンショットの text_to_image、image_to_image、image_to_video、または text_to_video。get_task は実行中のジョブをポーリングし、完了時にそのステータスと出力 URL を返します。
ワークフロー。 list_workflows、get_workflow、create_workflow、update_workflow は、Pro モードを支えるノードベースの DAG をエージェントが検査・編集できるようにします。execute_workflow はそれを1つ実行します。そして generate_workflow が興味深いものです。自然言語の記述を渡すと、それはワークフローグラフを返します——エージェントは事実上、1つの文からパイプラインを設計し、それを実行できるのです。
発見とメタデータ。 list_models、list_model_aliases、get_model_params は、何が利用可能か、各モデルがどんなパラメーターを受け付けるかをエージェントに伝え、推測する代わりに有効なリクエストを構築できるようにします。list_templates は私たちのプリセットパイプラインを出発点として提示します。
アセットとアカウント。 list_creations は以前の出力を取り戻します。list_characters は、生成をまたいで再利用するために保存されたキャラクターを公開します——これはFloniks ワークフローエディターの内側で書いたのと同じ一貫性のプリミティブです。そして get_credit_balance は、ジョブを開始する前にそれを賄えるかをエージェントが確認できるようにします。
ここでの重要な設計上の選択はこうです。これらは並行する、薄められた API ではありません。製品が動作する基盤と同じ機能を、構造化された出力を持つ機械呼び出し可能なツールとして公開したものなのです。
現実的なエージェントのループ
このサーバーを理解する最もすっきりした方法は、エージェントが実際に何をするかをたどることです。ある Claude セッションが、機能発表のためのヒーロー画像を制作するよう求められたとします。概念的には、ループは次のようになります。
- 発見。
list_model_aliasesを呼び出してどのモデルが利用可能かを確認し、タスクに適したものを選びます——たとえば強力なtext_to_imageモデルです。任意でget_model_paramsを呼び出し、どのアスペクト比やサイズを受け付けるかを知ります。 - 生成。
task_type: text_to_image、選んだモデル、そして発表用コピーからエージェントが構成したプロンプトを添えてsingle_taskを呼び出します。これはタスク ID を返します。 - ポーリング。 その ID で
get_taskを呼び出し、ステータスが終端状態に達するまで続けます。生成は非同期なので、エージェントはリクエストを開いたままブロックするのではなく、ジョブを待ちます。 - 結果を使う。 成功すると、
get_taskは出力 URL を返します。エージェントはその URL をユーザーに返し、ドキュメントに落とし込み、あるいは次のステップに送り込みます。
何が欠けているかに注目してください。ブラウザの自動化も、画面のスクレイピングも、脆弱なセレクターもありません。エージェントは型付けされたツールの結果に対して推論します。そしてここでは偽の認証情報をでっち上げないため——認証はあなたの Floniks アカウントによって、MCP と開発者ドキュメントに記載されたセットアップを通じて処理されます——人が起動してもエージェントが起動しても、同じループがまったく同じように動作します。
これらをいくつか連鎖させると、例はより野心的になります。ブログ記事を一組のソーシャル画像へと変えるエージェント。記事を読み、プラットフォームごとにサイズ調整したプロンプトで single_task を一度ずつ呼び出し、URL を収集します。あるいはスクリプトの絵コンテを描く Claude ワークフロー——generate_workflow でショットのパイプラインを設計し、execute_workflow でそれをレンダリングし、get_task ですべてのショットを集めます。オーケストレーションはエージェントが担い、生成は Floniks が担います。
入口は1つではなく3つ
MCP サーバーはエージェント開発者にとっての目玉ですが、それは3つの統合経路のうちの1つであり、それらは組み合わせて使うことを意図しています。
- MCP サーバーはエージェント向けです。Claude や任意の MCP クライアント上で構築しているなら、これがエージェントにクリエイション能力を与えるネイティブな方法です。
- REST API はそれ以外のすべて向けです——スクリプト、バックエンド、cron ジョブ、あなた自身の製品。同じ機能を、素のままの HTTP で。エージェントからよりもサービスから Floniks を呼びたいなら、これがその経路です。
- 公開 Skills は、生のツール呼び出しより高レベルの構成要素を求める開発者のために、よくあるフローを再利用可能な単位としてパッケージ化します。
3つすべてがMCP と開発者ドキュメントという一箇所にまとめられています。どれか1つに固定する必要はありません。よくある形は、インタラクティブな作業には MCP サーバーを使うエージェントと、スケジュールされたバッチジョブには REST API を使うバックエンドが、どちらも同じワークフローにアクセスする、というものです。
なぜワークフローが重要な単位なのか
単一の generate_image ツールを出して終わりにする方が簡単だったでしょう。私たちはそうしませんでした。なぜなら、Floniks が持つ最も価値あるものは、どれか1つのモデルではなく——構成可能なパイプラインだからです。その完全な論証はなぜワークフローは使い捨てのプロンプトに勝るのかで述べましたが、要約するとこうです。使い捨てのプロンプトは結果であり、ワークフローは新しい入力で永遠に再実行できる能力です。
ワークフローを MCP 上で公開するということは、エージェントがそのレバレッジを継承するということです。あなたがエディターで一度構築したトーキングアバターのパイプライン——キャラクター画像を画像から動画へ、さらにリップシンクへ——は、エージェントが異なるスクリプトで千回呼び出せる単一の execute_workflow 呼び出しになります。あなたが視覚的に作成する DAG と、エージェントが呼び出すツールは、同じオブジェクトです。これこそ、別個の薄い API を構築するのではなく、エージェント表面を製品表面と整合させ続けることの見返りです。
エージェントが信頼できる信頼性
自律的な呼び出し元は失敗のリスクを高めます。なぜなら、決して届かなかった結果に対する課金を捕まえる人が見ていないからです。私たちの答えは、プラットフォームの残りの部分が動作している答えと同じです。生成が失敗した場合、あなたのクレジットはあらゆる失敗経路にわたって自動的に返金されます。エージェントは開始前に get_credit_balance を呼び出して予算を立てられ、失敗したジョブへの支払いを防御的に見越して計上する必要はありません——それは処理済みです。get_task からの構造化されたステータスは、エージェントが文章を解析するのではなく、成功・失敗・処理中のあいだできれいに分岐できることを意味します。
エージェント時代のために作られた
ここにはより大きな賭けがあります。AI エージェントと回答エンジンがインターネットのより多くの玄関口になるにつれ、勝つのは機械呼び出し可能で、構造化された出力を返すシステムです——コンテンツに適用される生成エンジン最適化（GEO）と同じロジックが、能力にも適用されます。エージェントが駆動でき、型付けされたツールと予測可能な結果を備えたクリエイションプラットフォームは、この行き先にまさに合致します。私たちは、エージェントが使えない UI であるより、エージェントが手を伸ばすツールでありたいのです。
エージェントを構築している方、パイプラインを配線する AI エンジニア、あるいは生成をクリックするより script で動かしたい技術志向のクリエイターなら、MCP サーバーは準備ができています。MCP クライアントを Floniks に向け、MCP と開発者ドキュメントを開き、あなたのエージェントに何かを作らせてみてください。
よくある質問
Model Context Protocol（MCP）とは何ですか？
MCP は、構造化され型付けされたツールを通じて AI エージェントを外部システムに接続するためのオープンな標準です。エージェントが UI をスクレイピングしたり API 呼び出しを手作りしたりする代わりに、システムはエージェントが呼び出して推論できる名前付きツールを公開します。Floniks は MCP サーバーを同梱しており、MCP 互換のあらゆるクライアントがそのクリエイション機能を直接利用できます。
Claude は Floniks で画像を生成できますか？
はい。Floniks MCP サーバーを Claude Desktop（または任意の MCP クライアント）に接続すると、Claude は text_to_image や image_to_image のために single_task を呼び出し、get_task でポーリングし、出力 URL を返すことができます——より大きなタスクの一部として、自律的に画像を生成します。
エージェントは MCP サーバーを通じて実際に何ができますか？
エージェントはモデルを発見し（list_models、list_model_aliases、get_model_params）、単一ステップ生成を実行し（single_task）、多段階パイプラインを構築・実行し（generate_workflow、create_workflow、execute_workflow）、保存したキャラクターを再利用し（list_characters）、結果を取得し（get_task、list_creations）、自身のクレジット残高を確認できます（get_credit_balance）。
MCP 以外の選択肢はありますか？
はい。Floniks は3つの統合経路を提供します。エージェント向けの MCP サーバー、スクリプトとバックエンド向けの REST API、そしてより高レベルの再利用可能なフロー向けの公開 Skills です。3つすべては同じ機能を共有し、MCP と開発者ドキュメントに記載されています。