Gradio WorkflowでAUTOMATIC1111を再構築：73ノード・11パイプライン

背景と課題

AUTOMATIC1111のstable-diffusion-webui（通称A1111）は、生成AIによる画像創作において最も広く使われるクライアントの一つです。テキストから画像への生成、画像から画像への変換、高解像度化、プロンプトマトリクス、PNG情報の解析、ControlNet統合など、初心者からプロフェッショナルまでをカバーする豊富な機能が、その人気を支えてきました。しかし、A1111の内部アーキテクチャは本質的に「モノリシックなUI」であり、すべての機能が単一の巨大なGradio Blocksインターフェースにハードコードされています。そのため、特定のサブ機能を修正・拡張しようとすると、コードベース全体への深い理解が求められます。

また、ユーザーが異なるパイプラインを柔軟に組み合わせることは事実上不可能です。例えば、大規模言語モデル（LLM）で生成したプロンプトを直接拡散モデルに渡す、あるいは物体検出モデルが出力したマスクを修復パイプラインにそのまま接続する、といった操作はソースコードの改変なしには実現できません。さらに、再利用性にも課題があります。他の開発者がA1111の「高解像度化」ステップを自身のプロジェクトにドラッグ＆ドロップで取り込むことはできず、同様のロジックを一から実装し直す必要がありました。

この問題は、生成AIの急速な進化とともに深刻化しています。FLUX.1-KontextやQwen3-4B、DETRといった新しいモデルが次々と登場する中、個々のモデルを統合・デバッグするコストは増大の一途をたどっています。コミュニティは、回路図のように読みやすく、変更や共有が容易な「ブロックを組み立てる」ようなアプローチを切望していました。

Hugging Faceチームはこのギャップに着目し、同社が開発したGradio Workflow（gr.Workflow）フレームワーク上で、73個のノードと11本のパイプラインを用いてA1111のコア機能を再構築しました。このプロジェクトは「Workflow1111」と名付けられ、Hugging Face Spaces上でオープンソースとして公開されています。ユーザーは自身のHugging Faceアカウントでログインし、Inference Providersを通じてモデルを呼び出し、クォータは自身で管理します。これは単なるデモ用の玩具ではなく、実際に動作し、自由に「配線を変更」できるプロダクションレベルのリファレンス実装です。

アーキテクチャと実装詳細

Workflow1111の根底にある哲学は驚くほどシンプルです。すべてのメディアパイプラインは、4種類の演算子（Operator）によって構築されます。各演算子はキャンバス上のノードとして表現され、ノードの入出力ポートを線で接続することでワークフローを定義します。

4種類の演算子：

1. **`fn`** – 純粋なPython関数。例えば、テキストのクリーニング、プロンプトスタイルのマージ、PNGメタデータの書き込みなどに使用します。

2. **`model`** – Hugging Face InferenceClientを通じて呼び出すモデル。拡散モデル、LLM、VLM、ViT分類器などが該当します。

3. **`space`** – 別のGradio Spaceをネストして呼び出す演算子。背景除去用のSpaceなどをサブプロセスとして利用できます。

4. **`dataset`** – Hub上のデータセットから一行を読み込み、バッチ処理やテンプレート読み出しに使います。

すべてのノードは同一キャンバス上で対等に扱われ、ComfyUIのようにカスタムノードをPythonクラスとして実装する必要はありません。中核となるテキストから画像への生成パイプラインを例にとると、ユーザーがプロンプトを入力すると、まず`fn`ノード（プロンプトビルダー）がユーザー入力を選択されたスタイルプリセットと結合し、不要な空白を除去します。次に、その出力が`model`ノードに接続され、InferenceClient経由で選択されたチェックポイントが呼び出されます。生成結果はさらに別の`fn`ノードに渡され、サンプリングパラメータ（steps、CFG、seedなど）がPNGメタデータとして書き込まれ、最終的にメタデータ付き画像が出力されます。

高解像度化パイプラインは、このテキストから画像への生成に`model`ノードを一つ追加するだけで実現します。初回出力をFLUX.1-Kontextに渡し、詳細なリファイン指示（「ディテールと微細テクスチャを強化し、構図は変更しない」）を付与することで、より高解像度でシャープな画像を生成します。A1111では二回の完全な生成が必要だった高解像度化ロジックが、わずか二つのノードで再現されています。

さらに注目すべきは、モダリティを横断した組み合わせです。ユーザーは`model`ノードでQwen3-4Bを呼び出し、粗いプロンプト（「嵐の中の灯台」）を構造化されたタグリスト（「荒れた海、濡れた岩、ドラマチックな構図…」）に変換し、その出力を直接拡散モデルのプロンプト入力に接続できます。同様のアプローチで、VLMノード（Qwen2.5-VL）が写真を読み取って説明文を逆生成し、同時にViT分類器ノードが信頼度ラベルを並列出力します。二つのノードが同じ画像入力を共有する場合、gr.Workflowは自動的にそれらを並列実行するため、全体の処理時間は単一ノードとほぼ同等に抑えられます。

実測ベンチマークと実用的価値

Workflow1111は完全なベンチマーク結果を公表していませんが、その設計原理からいくつかの重要な利点が導き出せます。

並列実行による高速化：複数のノードが同一の入力を共有する場合、Gradio Workflowは自動的にそれらを並行してスケジュールします。例えば、VLMによる画像解釈とViTによる分類が同時に実行され、ユーザーは二種類の結果を同時に取得できます。この特性は、A1111では手動でステップを分割するか、外部プラグインに依存する必要がありました。

カスタムノード不要の拡張性：ComfyUIなどの類似ツールでは、新しいノードを追加するたびにPythonクラスを記述して登録する必要があります。一方、Workflow1111の4つの演算子は、関数、モデル、Space、データセットという最も一般的な計算形態をカバーしています。新しいモデルやサービスは、対応する`model`または`space`演算子を一つ追加するだけで統合でき、追加のグルーコードは不要です。この低コードパラダイムは、AIアプリケーション開発の敷居を「Pythonが書けること」から「フローチャートが描けること」へと引き下げます。

高い再利用性とフォーク・アンド・リワイア：Workflow1111のすべてのノードと配線は、他のプロジェクトから直接インポート可能です。ユーザーはSpace全体を自分のアカウントにコピーし、ドラッグ＆ドロップで編集できます。例えば、テキストから画像への生成で使われているチェックポイントを別のオープンソースモデルに差し替えたり、高解像度化ノードを他のパイプラインの末端に接続したりできます。従来のコードベースのコピーと比較して、この「フォーク・アンド・リワイア」の手法は直感的かつ安全です。

リソース管理の柔軟性：すべてのモデル呼び出しはHugging Face Inference Providersを通じて行われ、ユーザー自身のクォータが消費されます。つまり、Workflow1111自体は追加の計算リソースを消費せず、ユーザーは実際に呼び出した分だけ支払います。また、ノードが軽量であるため、ワークフロー全体の起動時間はA1111の完全なWebUI読み込みよりもはるかに高速です。A1111では、新機能を追加するたびにGradioのレイアウト修正、コールバックの調整、状態同期の処理が必要でしたが、Workflow1111ではLLMによるプロンプト最適化機能を追加する場合、`model`ノードをドラッグしてプロンプト入力に接続するだけで完了します。

今後の展望と技術的示唆

Workflow1111の意義は、単なる「A1111の再実装」にとどまりません。このプロジェクトは、「ワークフローそのものがアプリケーションである」というコンセプトが、AIツールチェーンにおいて現実的な選択肢であることを実証しました。

生態系の相互運用性：`space`演算子を使用することで、Workflow1111は既存のあらゆるGradio Spaceアプリケーション（背景除去、超解像、顔修復など）をネストできます。これは、コミュニティに存在する数千ものGradioアプリケーションが、より大きなワークフローの「部品」として再利用可能になることを意味します。プロトタイプの検証や機能統合のスピードは飛躍的に向上するでしょう。

今後の進化の方向性：Workflow1111は現在11本のパイプラインをカバーしていますが、フレームワーク自体にノード数の上限はありません。理論的には、動画生成（AnimateDiffノード）、3D再構成、リアルタイムストリーム処理などを追加できます。Gradio Workflowの今後のアップデートでは、ビジュアルデバッグ（ノードへのブレークポイント設定）、条件分岐、ループ制御といった高度な機能が実装される見込みです。これにより、ワークフローは完全なプログラミング言語と同等の表現力を獲得するでしょう。

A1111コミュニティへの影響：Workflow1111はA1111を置き換えることを目的としておらず、代替的なアーキテクチャパラダイムを提示しています。A1111のスクリプトやプラグインによる深いカスタマイズ能力には依然として価値がありますが、Workflow1111のモジュラーアプローチは、迅速な実験とコンポーネントの再利用に適しています。長期的には、両者が互いに影響を与え合う可能性があります。A1111がワークフローエンジンを導入してプラグイン開発を簡素化する一方で、Workflow1111がA1111のUI磨き込みの経験を取り入れることも考えられます。

総じて、Workflow1111は象徴的なエンジニアリング実践です。73個のノードが示すのは、AIアプリケーションの未来が、ドラッグ可能で共有可能、そして進化し続ける一枚の大きなキャンバスの上にあるかもしれない、という可能性です。A1111時代の「コードを書く」から、Workflow1111の「図を描く」へのシフトは、生成AIの民主化をさらに推し進めるでしょう。