記事のサマリー（TL;DR）
- Hugging Faceは、AUTOMATIC1111（stable-diffusion-webui）の機能の大部分を単一のワークフローキャンバスとして再現した「Workflow1111」を公開しました。73個のノードから成る11の媒体パイプライン（テキストから画像生成、高解像度補正、画像から画像生成、プロンプトマトリクス、VLMによる画像解析、検出結果からのインペイントマスク生成、ControlNet風のアノテーター、背景除去、PNG情報の保存、画像から動画生成）で構成されています。
- Hugging Faceアカウントでサインインするか、アクセストークンを提供することで各パイプラインを実行でき、サインイン後はユーザー自身のクォータでモデル呼び出しが行われます。キャンバス上のすべての出力ノードはREST APIエンドポイントとして公開され、
mcp_server=Trueで起動すればMCPツールとしても利用できます。 - gr.Workflowは、Python関数（fn）、InferenceClient経由で呼び出すモデル（model）、別のGradio Space（space）、Hubデータセットの行（dataset）という4種類の演算子から構成されており、ハードウェアを自前で用意しなくても実行可能で、ComfyUIと比較される存在だと説明されています。
利用条件
Workflow1111の各パイプラインを実行するには、Hugging Faceアカウントでサインインするか、アクセストークンを提供する必要があります。サインインすると、モデル呼び出しはユーザー自身のクォータを使用します。Space自体は各利用者のトークンを保持せず、MCP経由の利用時も呼び出し元がそれぞれX-HF-Tokenヘッダーで自分のトークンを送信する形になっています。
詳細
キャンバスの構成
すべての媒体パイプラインは、前回の投稿および公式ガイドで説明された4種類の演算子（fn、model、space、dataset）から構築されています。キャンバス上の各ノードは1つの演算子をラップしており、演算子の入力と出力がエッジで接続するポートになります。4種類の演算子の概要は次の通りです。fnはPython関数、modelはInferenceClientを通じて呼び出されるモデル、spaceは別のGradio Space、datasetはHubデータセットの1行です。以下、各パイプラインを順に見ていきます。
テキストから画像生成（Text-to-image）
これが中核となるパイプラインです。A1111のtxt2imgタブで期待されるコントロール（ネガティブプロンプト、ステップ数、CFG、シード、幅・高さ）に加え、チェックポイントを選択するmodel_idフィールドがあります。プロンプトはまずprompt-builder役のfnノードを通過し、選択されたスタイルプリセットを付加してテキストを整形した後、Inference Providers経由でチェックポイントを呼び出すmodelノードに渡されます。後処理を行うfnノードが、生成パラメータをPNGのメタデータに書き込んで出力し、これは後述のPNG Infoパイプラインが読み戻す情報になります。
高解像度補正（Hi-resolution fix）
AUTOMATIC1111では、高解像度補正はtxt2imgの出力をまずアップスケールし、その後2回目のデノイズパスを実行します。ここでは代わりに2ノードの迂回処理として実装されています。テキストから画像生成の結果は、リファイン指示（「細部と微細なテクスチャを強調し、構図は同一に保つ」）を伴うFLUX.1-Kontextのmodelノードに渡され、よりシャープで大きな画像として返ってきます。
画像から画像生成（Image-to-image）
同じKontextノードが、image-to-imageタブとしても機能します。画像をアップロードし、望む変更を記述すると、編集済みの画像が返されます。
LLMにプロンプトを書かせる
「嵐の中の灯台」のような粗いプロンプトから始めます。このパイプラインはそれをQwen3-4Bのmodelノードに送り、小さなfnノードが応答を最大40個までのタグの整ったリストに変換します（例：「stormy sea, wet rocks, dramatic composition, low angle shot, volumetric lighting, ominous tone」）。この出力には任意の拡散モデルのノードを接続して画像をレンダリングできます。ComfyUIとは異なり、ここではカスタムノードは関与していません。Gradioのワークフローでは、LLMと拡散モデルはどちらも同じキャンバス上の通常のmodel演算子です。
画像をプロンプトとして読み込む
これはAUTOMATIC1111のInterrogateボタンに相当しますが、CLIPの代わりにVLMが解析を行います。Qwen2.5-VLが夜市の写真を見て、その画像を生成し得るプロンプトを書きます。ViT分類器のノードは同じ画像を読み取り、ラベル（restaurant 51.9%、tobacco shop 15.6%、toyshop 9.1%）を返します。両ノードは同じ画像入力を使うため、gr.Workflowはこれらを並列実行し、1つを実行するのとほぼ同じ時間で両方の回答が得られます。
検出結果からインペイントマスクを生成
AUTOMATIC1111ではインペイントマスクを手描きする必要がありますが、このパイプラインでは検出器からマスクを生成します。DETRが街頭写真から6つの物体（人物3人、犬1匹、自転車1台、車1台）を検出し、そこからワークフローは2つの分岐に分かれます。一方は検出されたボックスを元画像に描画し、もう一方はそれらをインペイントパイプラインに渡せるマスクに変換します。描画とマスク作成はどちらもローカルでPillowとNumPyを使って行われ、検出呼び出しのみがマシン外に出ます。
プロンプトマトリクス（Prompt matrix）
AUTOMATIC1111のプロンプトマトリクスに相当する機能です。ベースプロンプト「a lone oak tree」が、fnノードによって4つの接尾語（at sunrise、in a thunderstorm、under the Milky Way、in autumn fog）と組み合わされ、それぞれのバリエーションが独自のtext-to-imageノードに送られます。最後のノードが4つの結果を1枚のコンタクトシートにまとめます。gr.Workflowにはループ演算子がないため、4つのtext-to-imageノードはキャンバス上に並べて配置されています。これらは同じ依存深度にあるため並列実行され、4枚の画像はすべて同時に生成が始まります。
アップスケールと背景除去
AUTOMATIC1111のExtrasタブに相当する機能です。アップスケーラーのノードは2つあり、それぞれ異なる経路をたどります。1つ目はfnノード内でのローカルなLanczosリサンプルで、ネットワーク呼び出しを必要とせず、Pillowがリサイズできる速さで完了します。2つ目はAuraSR ×4で、キャンバス上で最初に登場するspaceノードです。これはHub上のSpaceを呼び出し、その結果を他のノード出力と同様に扱います。背景除去も同様の仕組みで、BRIA RMBG-2.0も別のspaceノードであり、モデル全体が独自のSpace内で稼働し、このキャンバスはそれを呼び出すだけです。
アノテーター
Canny、線画（line art）、スケッチ、輝度深度（luma-depth）、ポスタリゼーションは、AUTOMATIC1111ではControlNet拡張から通常得られる前処理です。ここでは、それぞれがモデルを伴わない、素のNumPyで書かれたfnノードになっています。あらかじめ用意された建物ファサードの例の写真では、各アノテーターはCPU上で約0.5秒かかります。アプリ内には36個の演算子ノードがあり、そのうち32個がfnノードで、さらにそのうち22個はネットワーク呼び出しなしで完全にプロセス内で実行されます。キャンバスのおよそ3分の2は、接続を失っても動作し続けます。これらは通常のPython関数であるため、キャンバス・サーバー・GPUを一切介さずに直接テストすることもできます。
PNG情報（PNG Info）
AUTOMATIC1111は生成の詳細をPNGのparametersテキストチャンクに保存し、PNG Infoタブがそれを読み戻します。Workflow1111も同様の仕組みです。text-to-imageパイプラインの後処理ノードがメタデータを書き込み、このパイプラインがそれを読み戻し、プロンプト、ネガティブプロンプト、ステップ数、CFG、シード、画像サイズ、モデルを含む情報を取得します。
画像から動画生成（Image-to-video）
PNG Infoが読み取る対象の画像ノードは、それをアニメーション化するWan 2.2 I2V A14Bのノードにも供給されます。デモの例では、眠っているキツネが目を覚まして動き出します。1つの参照ノードが必要な数だけ下流のパイプラインに供給できるため、2つ目のアップロード欄は不要で、1回のアップロードで、メタデータの読み取りとアニメーション化が同じキャンバス上で行われます。
自分のGPUでモデルを実行する
ここまでのすべてのモデル呼び出しは、Inference ProvidersまたはSpaceを通じて他者のハードウェア上で行われてきました。これが、Workflow1111のようなものを自前のGPUなしで構築・実行できる理由です。しかし、fnノードは単なるPythonであるため、同様にモデルをローカルに読み込んで自分のGPU上で実行することもできます。FastVideo/fastvideo-fasth3-previewは、まさにそれを行うgr.Workflowアプリです。MiniMax-H3の4ステップ蒸留版であるFastH3を実行し、ZeroGPU上でサウンドトラック付きの動画を生成します。アプリ全体は次の1つのバインド関数に集約されます。
@spaces.GPU(duration=get_duration, size=GPU_SIZE)
def _generate(prompt_embeds, text_token_tags, height, width, num_frames, seed):
...
gr.Workflow(bind={"generate": generate, "status": status}).launch()
ZeroGPUは関数が必要な時にGPUを与え、呼び出しが終わると解放します。gr.Workflowはこの仕組みについて関知する必要はなく、単にfnノードを呼び出すだけです。これはSpacesに限った話でもありません。bind=をローカルのチェックポイントを読み込む関数に向け、自分のマシンで.launch()を実行すれば、Workflow1111のキャンバスが自分のGPUを駆動できます。
すべての出力がAPIになる
キャンバス上のすべての出力ノードは、手作業でルートを書くことなくRESTエンドポイントになります。Workflow1111は次の9個のエンドポイントを公開しています：/image、/edited_image、/generated_prompt、/recovered_prompt、/detected_objects、/x_y_grid、/upscaled_local、/annotator_map、/png_info。
from gradio_client import Client
client = Client("ysharma/Workflow1111", oauth_token="hf_...")
image, params, hires = client.predict(
"a red fox in a snowy pine forest", # Prompt
"", # Negative prompt
"Cinematic", # Style preset
"enhance fine detail", # Hires refine instruction
api_name="/image",
)
同じエンドポイントはMCPツールとしても利用できます。mcp_server=True（ガイド参照）を指定して起動すると、すべての出力ノードがAIアシスタントから呼び出せるツールとして表示されます。Claude Code、Cursor、またはその他のMCPクライアントをサーバーURLに向けることができます。
{
"mcpServers": {
"workflow1111": {
"url": "https://ysharma-workflow1111.hf.space/gradio_api/mcp/",
"headers": {
"X-HF-Token": "hf_..."
}
}
}
}
これにより、エージェントは画像を生成したり、プロンプトを読み戻したり、検出処理をより大きなタスクの中の一手順として実行したりでき、つなぎ用のコードは不要です。各呼び出し元は自分自身のトークンをX-HF-Tokenヘッダーで送信するため、Space自体は自分自身のトークンを保持しません。
ComfyUIとの位置づけ
AUTOMATIC1111は機能一覧の出発点を与えてくれましたが、Gradio Workflowが実際によく比較されるツールはComfyUIです。どちらもノードグラフだからです。多くの人が構築・提供したいものについて、gr.Workflowは同じ範囲をカバーします。ノードは自分が所有していないハードウェアであってもかまいません。Inference Providers経由で実行したり、Hub上の任意のSpaceや任意のAPIを呼び出したり、データセットから取得したりできます。これが、Workflow1111が自前のGPUなしで動作する理由です。
すべての出力は型付きのRESTエンドポイントになり、これらのエンドポイントはグラフから自動生成されます。訪問者は自分自身のアイデンティティでワークフローを実行できます。OAuthを有効にして公開URLを共有すれば、誰でもサインインしてインストール不要でアプリを使用できます。同じキャンバス上でモデルとモダリティを混在させることも可能で、拡散モデル、LLM、VLM、検出器、動画モデルはすべて同じワークフローの一部になれます。カスタムの処理が必要な場合は関数を書けばよく、カスタムノードはPython関数であるため、Pythonでできることは何でも実行できます。この結果として、ブラウザで開いてサインインしてすぐに使え、コードからも呼び出せるマルチモデルパイプラインが得られます。
自分で構築する
Workflow1111には73個のノードがありますが、始まりは次のようなシンプルなコードでした。
import gradio as gr
def your_function(text: str) -> str:
pass
gr.Workflow(bind=[your_function]).launch()
bind=は関数をノードに変換し、edges=はそれらを接続し、.launch()はブラウザでキャンバスを開いて編集を続けられるようにします。準備ができたら、gradio deployでアプリ全体をSpaceに配置できます。gr.Workflowガイドには、JSONスキーマや各演算子タイプを含む詳細が記載されています。既に動作するものから始めたい場合は、Workflow1111を開いてDuplicateを押し、11個のパイプラインのいずれかを選んで変更（ノードの削除、モデルの入れ替え、フローの再配線）できます。もっと小規模なものから始めたい場合は、前回の投稿に、それぞれ約1分で動かせる5つのワークフローが掲載されています。何を作った場合でも、Xに投稿して@gradioをタグ付けするよう呼びかけられており、そうしたワークフローを拡散したいと述べられています。