run-workflow

run-workflow MCP

run-workflow MCP サーバーを通じて、Adobe Firefly ワークフローを見つけ、構成、実行、公開、保存できます。機能に関する質問には、トレーニングデータの知識で決して回答せず、必ずライブのツール呼び出しに基づいて回答してください。アクション／ノードカタログの検索に関する質問（例：「利用可能なアクションは何ですか」）では、list_actions を必ず最初に呼び出します。ツールに関する質問（例：「ツールを見せて」「どの MCP ツールがありますか」）は別の語彙に関する質問です。自分に表示されているツール定義（名前＋一行の説明）から直接回答し、list_actions は呼び出さないでください。

このファイルは常に読み込まれるコアです。詳細な手順は references/ にあり、現在のターンで必要な場合に限り読み込んでください。

次の場合にこのリファレンスを読み込む…	ファイル
ユーザーが、単なる ID でも名前付きワークフローでもない、クリエイティブ／マーケティングブリーフのような文書をアップロード／貼り付けた場合	references/intake.md
ユーザーが注目ワークフローを指定した場合、または再配線するためのカスタム .indd／.psd テンプレートを提供した場合	references/featured-and-templates.md
複雑なグラフを構成する場合、複数バリエーションの出力を求められた場合、または必須入力が不足している場合	references/compose.md
実行を調査する場合、履歴を一覧表示する場合、またはワークフローが失敗した場合（エラーテーブル、inspect_run のルーティング）	references/diagnostics.md
ファイルのアップロード、インライン貼り付けの解決、macOS の権限エラー、出力の保存を行う場合	references/asset-input.md
ユーザーがアラートのトリアージ／RCA を求めた場合（開発専用：login --dev、Splunk ＋ Slack）	references/alert-rca.md

単独 ID のルール — 何よりも先にお読みください

スキル引数が ID（UUID、workflowId、batchId、executionId）のみで、ほかにコンテキストがない場合、意図は必ず調査であり、実行ではありません。

1. ただちに inspect_run(id) を呼び出します。
2. 結果（実行、出力、診断情報）を提示します。
3. 停止します。 その後に run_workflow_submit を呼び出してはいけません。

「run-workflow」は製品名であり、何かを実行する指示ではありません。 run_workflow_submit を実行する根拠となる必須キーワードは、「run」「execute」「process」「generate」「rerun」「redo」です。ユーザーのメッセージにこれらが一つもない場合は、inspect_run を呼び出してください。

禁止事項： 貼り付けられた単独 ID に対して run_workflow_submit を呼び出すこと、または最初に run_workflow_submit を試し、404 の後で inspect_run に切り替えること。調査後の再実行処理（canRerun ではなく、rerun オブジェクトに基づいてルーティングする）については、references/diagnostics.md を参照してください。

**「このゴールデンワークフローまたはインターフェースには、どのアセット／入力が必要ですか（また、それらはまだ利用可能ですか）？」**という質問も、inspect_run(workflowId) で対応します。これはインターフェースの正式な組み込み定義を解決し、各アセットの rerunAssets[].resolvedVia（warm-url / durable-storage / unavailable）を報告します。get_featured_workflow で回答してはいけません（別のカタログです）。references/diagnostics.md →「このゴールデン／インターフェースに必要なアセット」を参照してください。

ワークフローの種類（ユーザー向けの用語）

ユーザーに表示されるワークフローは、すべて次のいずれかの種類に当てはまります。ユーザーと話すときは、次の平易なラベルを使ってください。内部フィールドの値をそのまま表示してはいけません。

• 公開済み — ユーザーが再利用可能な API エンドポイントとして公開したワークフローです（安定した workflowId ＋ curl）。
• プリセット — Firefly UI から実行された公開済みワークフローです。「プリセット」と「インターフェース」は同じものです。ユーザーが「インターフェース」または「プリセット」について尋ねた場合、どちらもこれを指します。（別個の保存済み定義ではなく、インターフェースから起動された公開済みワークフローです。）
• インライン — 保存済み／公開済みの定義を持たず、MCP を通じてその場で構成・実行されたワークフローです。
• ドラフト — Workflow Builder に保存されていますが、まだ公開されていません。ドラフトは実行後もドラフトのままです（実行したことがあるかどうかにかかわらず、source は draft です）。これはビルダー UI と一致します。実行済みかどうかは firstExecutionAt で判断します。値が設定されている場合は実行済みドラフト、null／未設定の場合は未実行ドラフトです。
• プレビュー — 1 回限りのプレビュー実行です。一時的なものです。
• 共有済み — 別の組織からこの組織に共有されたワークフローです（作成者が共有を開始）。読み取り専用です。

ワークフロー一覧表示のリクエスト（「自分のワークフローを見せて」「自分が作成したものは？」など）では、呼び出し元自身のドラフトと公開済みの行に加えて、他の組織メンバーの公開済みの行、および共有済みの行を表示します（プリセットは、ラベル付けされた公開済みの一部です）。インラインとプレビューは保存済み定義のない実行成果物のため、この意図では対象外です。他のユーザーが作成したワークフローを実行または編集したと主張してはいけません。また、共有済みの行の編集や再公開を提案してはいけません。

この意図では、デフォルトで未実行ドラフトを非表示にしてください（workflowSource === "draft" && !firstExecutionAt）。実行済みドラフトは公開済みと並べて表示します。未実行ドラフトは未完成の作業途中のため、ユーザーが求めることはほとんどありません。未実行／未完成／すべてのドラフトを明示的に求められた場合のみ、未実行ドラフトを含めてください。

一覧表示では、以下のラベルに変換してください。フィールドの完全な対応表については、references/diagnostics.md を参照してください。

ツールの振り分け

ユーザーの意図	ツール
「ツールを表示して」／「MCP ツールを表示して」／「どんなツールがありますか」／「利用できるツールは何ですか」	表示されている自身のツール一覧（名前＋各ツールの1行説明）から直接回答します。list_actions やその他のツールは呼び出さないでください
「利用できるアクションは何ですか」／「使えるノード／アクションを表示して」／「ワークフローを作るには何が使えますか」／「カタログを表示して」／「何ができますか」（ワークフロー機能についての質問）	list_actions
「アクション X が受け付けるパラメーターは何ですか」	get_action_schema
「ワークフローを作成／構成して…」	compose_workflow
URL を取得するためにローカルファイルをアップロードする	upload_asset
ワークフローを実行する — 明示的な実行キーワードがある場合のみ。すぐに batchId を返します（非同期）。どのサイズでも安全です	run_workflow_submit
実行中の処理が完了したか確認する — ポーリングのたびに必ず includeOutputs: true を渡してください	run_workflow_get_status
batchId を指定して実行中のバッチを中止する	cancel_workflow
「自分のワークフローを教えて」／「自分のすべてのワークフローを表示して」／「最近のワークフロー」／「自分が作成／定義／保存したものは何ですか」（「すべて」という語の有無を問わない、通常のワークフロー一覧の意図。日付フィルターや「実行／実行履歴」への言及はありません）	list_all_workflows — 1回だけ呼び出します。renderedTable には、8件のゴールデンデモ行、typeSummary の種類別件数ブロック、呼び出し元自身のワークフロー表が、この順で単一の結合文字列としてすでに含まれています。別途 list_golden_workflows を呼び出さないでください。また、独立した typeSummary フィールドも別途貼り付けないでください（すでに埋め込まれています）。この意図では list_workflow_history／list_batches／inspect_run は決して使用しないでください。正確な列と事前計算済みフィールドについては references/diagnostics.md を参照してください
自分のワークフローをフィルター指定／日付範囲指定して検索する場合（例：「先週公開したワークフロー」）— 上記の通常の一覧表示の意図とは異なります	list_workflow_history（日付フィルターを使い、自分のドラフト／公開済みのみ）
「自分のインターフェースを一覧表示して」／「自分のプリセット」／「公開済みのプリセット／インターフェースは何がありますか」（定義 — 通常の公開済みワークフローや実行とは異なるエンティティです）	list_interfaces — 1回だけ呼び出します。すでに書式設定されています。renderedTable をそのまま表示してください
「自分のジョブを一覧表示して」／「自分のインターフェースの実行」／「プリセットの実行」／「インターフェースの実行履歴」（実行のみ。bulk-workflow-service のトラフィックやプレビュー／ヘッドレス実行は含みません）	list_interface_runs — 1回だけ呼び出します。すでにフィルター処理と書式設定が済んでいます。renderedTable をそのまま表示してください。1件の実行の出力／エラーを確認するには、その batchId を指定して inspect_run を使用します
「自分のワークフローの実行を一覧表示して」／「保存したワークフローの実行」／「自分が実行したものは何ですか」（インターフェース／プリセット／ジョブを明示的に尋ねていない場合）— 通常のインターフェース外の実行です。UI による前例はないため、列と書式はこのツール独自のものです	list_workflow_runs — 1回だけ呼び出します。すでにフィルター処理されています（チャネルを問わず、インターフェース／プリセットの実行をすべて除外）。書式設定も済んでいます。renderedTable をそのまま表示してください。1件の実行の出力／エラーを確認するには、その batchId を指定して inspect_run を使用します
「最近の実行を表示して」／「自分が実行したものをすべて」／「今実行したインターフェース」／「特定の UI からの実行」（上記の意図には該当しない、batchSource／invocationSource／hostId でフィルターする実行検索）	list_batches（インターフェースの実行には batchSource:"preset"、特定の UI には hostId でフィルターします）
「最後に実行したワークフロー」／「最も新しい実行」（最新のものを1件だけ）	list_workflow_history（limit=1）→ inspect_run — 1件のみ。広範な一覧には決して使用しないでください
実行のアクションごとの出力／ログ／エラー。「なぜ失敗したのですか」。貼り付けられた ID の検索	inspect_run
compose の失敗をデバッグするために、既知の正常な例を検索する	get_workflow_examples
ディスク上の JSON ファイルを編集した後、例を再読み込みする	reload_examples
ワークフローを curl で呼び出せる再利用可能な API エンドポイントとして公開する	publish_workflow
Workflow Builder で編集可能なドラフトとしてワークフローを保存する（ACP と、バックエンドが読み取る統合ストアの両方に書き込みます）	save_workflow
公開済みの workflowId 用に curl コマンドを生成する	generate_curl
出力画像をチャット内にインライン表示する（Claude Desktop では不可 — 上限は 1MB。出力の提示手順に従って URL を提示した後に限ります）	display_asset
新しく登録されたアクションを確認する（カタログが古い場合）	refresh_catalog
名前付き／特集ワークフローを実行する（リターゲティング、製品バナーの大規模生成、ローカライズ、パッケージングなど）— ゴールデンデモとは異なる、ユースケース別のテンプレートです（下記の注を参照）	get_featured_workflow → references/featured-and-templates.md を参照してください
「ゴールデンワークフローを一覧表示して」／「ゴールデンデモには何がありますか」（FFCPE のホームページにあるショーケースカード — Banners at Scale、Product Assets、Social Video Adaptation。ユースケース別テンプレートでショーケースデモではない特集ワークフローとは異なります）	list_golden_workflows — 1回だけ呼び出します。すでに書式設定されています。renderedTable をそのまま表示してください
「<golden demo name> を実行して」（例：「banners at scale を実行して」、「social video adaptation のデモを実行して」）— 単なる一覧表示ではなく、ゴールデンデモを指定した実行の意図	まず list_golden_workflows を呼び出して名前を workflowId に解決します。「Banners at Scale」のようなユースケース名は複数の行に一致するため、候補を一覧表示して、先にどれを実行するか確認してください。決して推測してはいけません。その後、run_workflow_submit({ workflowId, inputs: [] }) を直接送信します（既定値が組み込まれているため、確認は不要です — Key rules の ASK-FIRST (assets) ルールを参照してください）。ただし、プロンプトですでにユーザー自身のアセットを求めている場合は、アセットを収集して inputs に渡してください。単独の「<use case> を実行して」を get_featured_workflow に送ってはいけません。これはエージェント向けのテンプレート経路であり、ユーザーが実行する経路ではありません。
単一か複数か： 1 つの ID／「最後のもの」／「そのワークフロー」→ inspect_run（詳細情報）。
対象を指定せず、「run」／「ran」／「execution」という表現も含まない、広範な「ワークフローを一覧表示して」というリクエスト →
list_all_workflows。ワークフローの代わりに（またはワークフローに加えて）runs／executions に言及するリクエスト
—具体的に「my workflow runs」を含む—→ list_workflow_runs（list_all_workflows や
list_workflow_history は使用しない）。より広範な、または絞り込みを含む run のクエリ（任意のソース、特定の hostId など）
→ 代わりに list_batches。

ワークフローの一覧表示の意図 — 1 回の呼び出し、renderedTable に含まれる 3 つのセクション

単純な「自分のワークフローを表示して」という意図（上の表の行を参照）には、list_all_workflows をちょうど 1 回呼び出して応答します。その renderedTable には、1 つに結合された文字列の中に、以下の 3 つのセクションがこの順序で含まれており、それぞれの間には空行があります。その文字列を変更せずに返信として貼り付けてください。workflows 配列からテーブルを再構成したり、ゴールデンデモの行や Workflow ID 列を削除したり、いずれかのセクションを文章による要約に置き換えたりしないでください。貼り付けたブロックの後に、絞り込みや範囲の限定を提案する簡単な一言を添えるのは構いません。ただし、最初にブロックを貼り付けることの代わりにはなりません。

3 つのセクション：

1. **「ゴールデンデモ：」**のラベルと、それに続く FFCPE のホームページに掲載された 8 件のゴールデンデモの行（list_golden_workflows 自体のテーブルとバイト単位で同一）。
2. typeSummary のタイプ別件数ブロック（件数だけを必要とする呼び出し元向けに、独立したフィールドとしても返されます。ただし、renderedTable に出力するときは、すでにこの位置に含まれています。独立した typeSummary フィールドを renderedTable の前に別途貼り付けないでください。ブロックが二重に表示されます）。
3. **「自分のワークフロー：」**のラベルと、それに続く呼び出し元自身のワークフローテーブル（5 列。［references/diagnostics.md](references/diagnostics.md) を参照）。

ページ分割された呼び出し（offset > 0）では、セクション 1 は完全に省略されます。ゴールデンデモは毎回同じ静的な 8 行なので、最初のページでのみ取得・表示されます。

文字列全体を、最初から最後まで、1 つにまとめてそのまま表示してください。この意図では list_golden_workflows を別途呼び出さないでください。renderedTable を複数のテーブルやフィールドに分割し直したり、セクションが「主要な」内容ではないという理由だけで要約または削除したりしないでください。

ゴールデンデモのセクションについては、3 つの設計を順に試しました。最初の 2 つは採用を中止しました。（1）ツールを 2 回続けて別々に呼び出す（list_golden_workflows の後に list_all_workflows）—明示的に指示しても、実際には確実に要約時に省略されました。余分なツール呼び出し全体を省くことも、1 つのフィールドを削除するのと同じくらい簡単にモデルが行えてしまうと分かったためです。（2）list_all_workflows 自体のレスポンスに、別個のフィールドとして goldenRenderedTable を追加する —こちらも同じ理由で確実に省略されました。根本的な理由は、2 つ目のフィールドも 2 つ目の呼び出しと同じように省略できてしまうことです。（3、現在）この機能で行った他の同様のテストすべてで確実に残った 1 つの文字列（renderedTable 自体）に、ゴールデンデモの行を直接組み込む —選択的に省略できるものが残らなくなりました。その後、ゴールデンデモの順序に関して 2 つ目の問題（別個の typeSummary フィールドが renderedTable に対して誤った順序で表示されること）が明らかになったため、同じ考え方を typeSummary の位置にも適用しました。これを同じ文字列の正しい位置に組み込むことで、順序の曖昧さも解消されます。goldenUnavailable: true は、ゴールデンデモのセクションで問題が発生して完全に省略された（空のプレースホルダーとして残されたわけではない）ことを意味します。ゴールデンデモが存在しないかのようにテーブルを表示するのではなく、その旨をユーザーに伝えてください。 インターフェース／プリセットとその実行：「インターフェース」／「プリセット」（同じものです。「プリセット」は古いバックエンド内部の名称です）は定義を指します（通常の公開ワークフローとは実際に別のエンドポイント／名前空間を通じて公開されます）→ list_interfaces。「ジョブ」はその実行を指します → list_interface_runs。一括ワークフローサービスのトラフィックは決して使わないでください（これは別の製品であり、run-workflow のバッチデータにはまったく表現されません）。この2つの意図を互いに混同したり、list_all_workflows／list_batches と混同したりしないでください。

通常のワークフロー実行とインターフェース実行： list_workflow_runs はインターフェース／プリセットの実行を一切含みません（誰が／何が起動したかにかかわらず）。これは list_interface_runs の補集合であり、上位集合ではありません。これに対応する既存の UI はありません（インターフェースは一括作成の UI と完全に同じですが）。その列／形式はこのツール独自の設計です。画面と一致すると主張しないでください。

「banners」におけるゴールデンデモと注目のワークフロー： どちらのカタログにも偶然「banners」という単語が使われていますが、互いに無関係です。「Banners at Scale」（単独）はゴールデンデモのユースケースです。サブデモが2つあるホームページのショーケースカードで、list_golden_workflows を通じて解決されます。「Product Banners At Scale」は注目のワークフローテンプレート（エージェント向け）で、get_featured_workflow を通じて解決されます。ユーザーが単独で「run banners at scale」（または任意の単独の「run <use case>」）と言った場合は、ゴールデンのリクエストです。list_golden_workflows を通じて解決し、get_featured_workflow は決して使わないでください。get_featured_workflow を使うのは、ユーザーが注目の／事前定義済みテンプレートを明示的に求めた場合、または compose_workflow の前段階として使う場合に限ります。

Type／チャンネルの分類（batchSource と invocationSource）と、実行を中心としたルーティングの詳細については、references/diagnostics.md を参照してください。

ワークフローパターン

1. upload_asset        — upload local files; get back URLs for use as inputs
1b. get_action_schema  — SKIP when: you already have a session_id, OR the workflow is a clear
                         single-action keyword (remove-background, upscale, crop, expand, generate,
                         etc.). CALL when: composing a multi-step custom workflow where at least one
                         action's parameters are uncertain. See references/compose.md.
2. compose_workflow    — describe the desired processing in natural language; the AI graph agent
                         designs the graph. DO NOT manually specify actions or connections.
3. run_workflow_submit — execute with inputs; pass session_id from step 2. Pass ALL images in ONE
                         call. Returns a batchId immediately (async); does NOT block on completion.
                         → For featured workflow runs (session_id from get_featured_workflow OR from
                           a compose_workflow rewire): inputs[] = one entry per asset type using node
                           IDs from prepared.inputNodes — preserved through rewires. See table in
                           references/featured-and-templates.md. No deliberation needed.
4. run_workflow_get_status — poll the batchId; ALWAYS pass includeOutputs: true. On completion,
                         present ALL output URLs verbatim and STOP (see post-completion sequence).
5. download_output     — ONLY after the user asks; saveTo a folder they choose.
6. publish_workflow    — publish for API reuse   OR   save_workflow — save for UI editing.

非同期ポーリング

run_workflow_submit の後、段階的な間隔で includeOutputs: true を指定して run_workflow_get_status をポーリングします。次の待機時間を決めるには、各レスポンスから elapsedSeconds を読み取ってください。

ここまでの elapsedSeconds	次のポーリングまでの待機時間
< 60	15s — すぐに完了する可能性があります
60 – 180	30s
> 180	60s — 大規模なバッチです。ツール呼び出しを半分に減らしてください

レスポンスの elapsedSeconds と percentage をそのまま使って進捗を報告してください。経過時間を自分で推定しないでください。

実行中 — 3/10 個のアセットが完了（30%） · 経過時間 45s

完了までポーリングしてください。途中で止めないでください。 出力を提示する前に、必ず終端状態（completed／failed）までポーリングしてください。

実行タイプ	メール送信？	対応方法
batchSource: "preset"（インターフェース／プリセット — 出力先は Adobe Files）	はい	「ここでポーリングを続けるか、完了メールを待つか」を提案してもかまいません。ユーザーがポーリングを続けることを選んだ場合は、完了まで続けてください
その他すべての実行（インライン／公開済み／プレビュー — ステータスに署名付きの outputUrls を含む）	いいえ	必ず完了までポーリングしてください。メールの選択肢は提示しないでください

• ポーリング結果に downloadedPreviewOutputs が含まれている場合は、ポーリングを続けながら、それらをすぐに（処理中と明記して）表示してください。
• status === "completed" の場合、出力はすでにレスポンスに含まれています。2回目の呼び出しは不要です。大規模なバッチでは完了レスポンスがクライアントの予算を超え、一時ファイルに保存されることがありますが、これは想定内です。再ポーリングするのではなく、「出力の提示」手順と references/asset-input.md に従って、OUTPUT URLS: ブロックを一度だけ抽出してください。
• status === "failed" の場合は、失敗した実行に対して inspect_run を呼び出して要約し、そこで停止してください。自動で再試行したり、配線をやり直したりしないでください。references/diagnostics.md を参照してください。

出力を提示する — 出力を投稿してから、まとめて1つだけ提案する

run_workflow_get_status が（完全または部分的に）completed を報告したら、記載順にちょうど2つのことを行います。まず出力を投稿し、その後、まとめて1つだけ提案します。提案を別々の質問に分けないでください。

1. すべての出力をすぐに投稿する。検討は不要です。 ステータスが completed になったら：
   • まず、OUTPUT URLS: ブロックの上に VIEW YOUR ASSETS: ブロックがあるか確認します。これは、Adobe Files、AEM Assets、または Frame.io に保存する write-files ノードがワークフローに1つ以上あった場合に表示されます。各エントリは、その保存先に納品されたすべての出力を閲覧するためのフォルダーリンクです。存在する場合は、すべてのエントリを先に表示してください。目立つラベルを付けます（例： 「Adobe Files ですべてのアセットを表示： [リンク]」）。ワークフローには write-files ノードが複数ある場合（例：ACP 用と Frame.io 用がそれぞれ1つずつ）もあるため、リンクが複数存在することがあります。
   • 次に、OUTPUT URLS: テキストブロックにあるすべての URL を、一字一句そのままフラットな Markdown リストとして列挙します。末尾の JSON outputUrls[] ブロブではなく、そのブロックから読み取ってください。参照ファイルを再読み込みしないでください。URL は省略せず完全なものを使用してください。プレースホルダーに置き換えてはいけません（[presigned URL] は禁止です）。応答が一時ファイルにあふれた場合（大量のバッチ）、対象を絞って grep を2回実行します。最初に VIEW YOUR ASSETS: を検索し、見つかったフォルダーリンクの行を表示します。次に OUTPUT URLS: を検索し、その後に続く - name — url の行を提示します。JSON ブロブを複数回に分けて検索してはいけません（references/asset-input.md を参照）。
   • 署名付き URL の有効期限は約1時間です。このメッセージには出力以外の内容を含めないでください。
2. 1つのメッセージで、選択肢をまとめて1つだけ提案する — 「ダウンロードしますか？」と「次のステップは？」というやり取りに分けないでください。
   • お使いのマシンにダウンロードする — 相手が選んだ saveTo フォルダーを指定して download_output を呼び出し、保存された正確なパスを報告します。または、
   • 上記のリンクで十分 — ダウンロードは不要です。または、
   • 次に行うこと — Workflow Builder に保存（save_workflow）、API として公開（publish_workflow）、または新しいワークフローを開始します。

主要なルール

• 署名付き URL — すべてのレスポンスの url フィールドをそのままコピーしてください。HMAC 署名付きのため、1 文字でも変更すると asset_download_failed になります。
• 先に確認（アセット）— 下書き／公開済みワークフローのみ。ゴールデンデモ／インターフェースは対象外 — 下書きまたは公開済みワークフローを実行する前に、既存／前回のアセットで実行するか、独自のアセットを提供するかをユーザーに確認してください。ただし、ユーザーのプロンプトですでに明確になっている場合（ファイルを添付した、または「デフォルトを使って」と伝えた場合）は除きます。実行前に、可能であれば前回のアセットを引き続き取得できるか（有効な署名付き URL があるか）確認してください。アセットを取得できない場合は、確認せずに送信するのではなく、新しいアセットを提供するよう依頼してください。ゴールデンデモ／インターフェース／プリセットの場合は、これとは逆に、確認も事前検証もせず inputs: [] を直接送信します。組み込みアセットは厳選され、長期利用できるものであり、前回実行時の古い残存物ではありません。ユーザー自身のプロンプトから、独自のアセットを使いたいかどうか判然としない場合に限り、確認してください。
• 高速な再実行 — 同じアセットでワークフローを再実行する場合は、workflowId だけを送信してください（actions／connections は指定せず、inputs: [] を指定）。これによりクライアントは何もアップロード／再署名せず、送信は即座に完了します。インラインソースまたは公開済みの workflowId がないプリセットソースの場合に限り、インライングラフを渡してください。その場合は、workflowJson の署名付き入力 URL をそのまま再利用し、再アップロードするのは [URL expired …] となっている入力だけにしてください。by_id による再実行でインライングラフを渡すと、すべてのアセットが再解決され、run_workflow_submit が完了するまで数分かかります。初回の実行には適用されません（inspect_run → executionCount === 0、ソースは問いません。未実行の下書き、新たにインポートしたワークフロー、未実行のプリセットなど）。再現する前回の実行がないため、組み込みアセットは「前回と同じアセット」ではありません。すべて引き続き解決可能（rerunAssets.status: "all_resolvable"）であれば、そのまま実行できることをユーザーに伝え、確認を待ってください。一部が見つからない（some_missing）場合は、ID だけを送信するのではなく、初回実行に必要な実際の入力を集めてください。 インターフェース／プリセットは、初回だけでなく、すべての実行回数で上記の特例となります。インターフェースには常に独自の組み込みデフォルトが含まれているため、実行回数や、前回の実行で送信された内容にかかわらず、workflowId + inputs: [] を使うとそのデフォルトが使われます（前回の実行で一時的に使われた独自アセットは、失敗した実行の場合も含め、暗黙に再利用されることはありません）。上記の 先に確認（アセット） ルールに従い、通常のワークフローとは逆に、確認も事前検証もせず inputs: [] を直接送信してください。inputs を渡すのは、ユーザー自身のプロンプトでアセットの差し替えが求められている場合に限ります。references/diagnostics.md を参照してください。
• session_id — compose_workflow と get_featured_workflow は、どちらもこれを返します。会話全体を通して保持し、actions／connections を再シリアル化する代わりに、run_workflow_submit、publish_workflow、save_workflow に渡してください。サーバーはこれを 2 時間保持します。
• 一括入力 — すべての画像／アセットを 1 回の run_workflow_submit 呼び出しで渡してください（入力ノードの content 配列を使います）。画像ごとに別々の呼び出しを行わないでください。
• 公開と保存の使い分け — publish_workflow は再利用可能な API エンドポイント（workflowId + curl）を作成します。「公開する」「呼び出し可能にする」「API を作成する」場合に使ってください。save_workflow（以前の save_workflow_to_acp）は、ユーザーの Adobe クラウドに保存し、Workflow Builder で使えるようにします。「保存する」「編集を続ける」「UI で開く」場合に使ってください。意図が曖昧な場合は、先に確認してください。
• 履歴 — 単一の項目には inspect_run を使ってください。「自分のワークフローを一覧表示して」という広範な意図には list_all_workflows を使い、フィルターや日付範囲を指定した自分のワークフローの検索に限り list_workflow_history を使ってください。ローカルの workflow.json／inputs.json は絶対に読み込まないでください。詳細は references/diagnostics.md を参照してください。
• 必須入力がない場合 — 黙って解決しないでください（より簡単なアクションへの置き換え、プレースホルダー／マスクの自動生成、スクリプトによる回避策は禁止です）。停止して選択肢を提示してください。references/compose.md を参照してください。

アンチパターン

これらの落とし穴は見落とされやすく、上記のセクションでも明確に説明されていません。

• 「ツール」と「アクション／ノード」を混同する — これらは異なる用語です。「ツールを見せて」／「どんな MCP ツールがありますか」は、MCP ツールの一覧（list_actions、compose_workflow、run_workflow_submit など）について尋ねています。ツールを呼び出さず、表示されている自分のツール一覧から直接回答してください。「利用できるアクションは何ですか」／「ノードを見せて」は、ワークフローのアクション／ノードのカタログについて尋ねています。list_actions を呼び出してください。一方の質問に対して、もう一方の情報で回答してはいけません。

• アセットについて先に尋ねずに、ドラフト／公開済みのワークフローを実行する — 実行してはいけません。実行前に、既存／以前のアセットを使うか、ユーザー自身のアセットを使うかを尋ねてください。ただし、プロンプトですでに選択が明らかな場合（ファイルを添付している、または「デフォルトを使って」と言っている場合）は除きます。実行前に、以前のアセットを引き続き取得できること（有効な署名付き URL）を確認してください。取得できないアセットがあれば、確認せずに送信するのではなく、新しいアセットを求めてください。Key rules の ASK-FIRST（assets） ルールを参照してください。 ゴールデンデモ／インターフェースは逆のケースです — 尋ねてはいけません。また、埋め込み済みアセットを「確認」するために先に inspect_run を呼び出してもいけません。run_workflow_submit({workflowId, inputs: []}) を直接送信してください。埋め込み済みのデフォルトは厳選されており、長期間利用できます。inspect_run が調べるのは以前の実行であり、一度も実行されていないインターフェースには何も見つかりません。また、先に呼び出すと無関係な 404 が発生するリスクがあるだけです。実際に問題がある場合は、送信時の事前チェックで needs_reattach によって検出されます。

• 新しい一覧表示の意図に対して、ツールを新たに呼び出さず、以前の一覧結果を使って回答する — そうしてはいけません。上記のツールルーティング表の各行は、それぞれ異なるデータソースを対象とする別個のツールです。別のエンティティを指定するフォローアップの質問は、たとえば、先週の通常のワークフローを一覧表示した直後にゴールデンデモについて尋ねる場合や、list_workflow_history で検索した直後にインターフェースについて尋ねる場合など、新しい意図であり、すでにコンテキストにある一覧へのフィルターではありません。表に従って再度ルーティングし、対応するツールを新たに呼び出してください。似たようなリクエストが直前にあったという理由だけで、以前返された一覧を検索、フィルタリングしたり、そこから回答したりしてはいけません。list_golden_workflows／list_interfaces などのカタログはそれぞれ独立しており、以前の呼び出しでは取得されていません。

• ユーザーが CSV を持っているときに、決定的な compose_workflow の再配線で csvData を省略する — csvData は解析データのルーティングを制御する唯一の入力です。これがないと、すべての画像ポートが直接配線され、 実行時に項目数が一致しなくなります（"image" has 4, "Headline" has 16）。message パラメーターではルーティングを上書きできません。references/featured-and-templates.md を参照してください。

• カスタムテンプレート（.indd／.psd）を message／LLM 経由、または単なる「swap」で再配線する — フィーチャーベースグラフの小文字のマージポート（例：headline）が残るため、大文字と小文字を区別する InDesign のデータ マージで、長いマージ処理の後に Headline プレースホルダーに対して 107013 エラーが発生します。必ず compose_workflow(customTemplateUrl=…) を使用してください。各ポートがテンプレートタグの正確な大文字・小文字表記に再バインドされます。 CSV ヘッダーの大文字・小文字を変更しても解決しません（CSV ヘッダーは破棄され、データソースのヘッダーはマージポート名から取得されます）。 カスタムテンプレートと CSV を使って実行する場合は、大文字・小文字を区別しないタグ ↔ CSV の 網羅性チェックも実行してください（すべてのタグに列があり、画像列には @ が付いていること）。 references/featured-and-templates.md を参照してください。

• マージデータテンプレートを入力ノードの content[] に配置する — merge-data／data-merge-psd ワークフローでは、.indd または .psd テンプレートは、 input-files やその他の入力ノードの content[] 項目ではなく、マージノード自体の inputs[].template.presignedUrl から指定する必要があります。content[] に配置すると誤った経路に割り当てられ、 "merge-data requires at least one template file"（および write-files の連鎖エラー）で実行が失敗します。 run_workflow_submit は、この誤りを検出すると misplacedOnNodeId を含む status:"missing_template" を返すようになりました。 inspect_run は、必須なのに空のテンプレートスロットを reattachVia:"template" のリーフとして表示するため、 送信前にどのノード ID を指定すべきか確認できます。

• テンプレートを workflowTemplateUrl／templateUrl／indesignTemplateUrl パラメーターとして渡す — これらはグラフのノードデータ作成用フィールド（多くの場合、署名付きでない CloudFront 参照）であり、バックエンドは 実行時に読み取りません。フラット化処理によって、実行用の parameters から取り除かれます。唯一の「テンプレート」が *TemplateUrl であるマージノードは、引き続き "requires at least one template file" で失敗します。 実行時の唯一の参照元は parameters.templates[] です（inputs[].template.presignedUrl から、または再配線された セッション上の合成テンプレートから取得されます）。references/featured-and-templates.md を参照してください。

• name を指定せずに画像入力を渡す — name がないと、行ごとの @image のベース名照合が失敗します。（再配線された session_id には合成テンプレートが自動的に 挿入されるようになったため、テンプレートを取得するためだけに useSessionDefaults: true を指定する必要はなくなりました。 このフラグは現在、テキストの入力など、テンプレート以外のより広範なセッション既定値のみを制御します。） references/featured-and-templates.md を参照してください。

• 未変更の再実行で別のテンプレートに差し替えて、そのまま実行できると思い込む — merge-data／data-merge-psd ノードの入力ポートは元のテンプレートのタグであるため、プレースホルダーが異なる新しいテンプレートでは コンテンツが誤った経路に割り当てられ、最終的に InDesign 107013 エラーで失敗します。未変更の inputs[].template 差し替え（合成された session_id なし）の場合、run_workflow_submit は新しいテンプレートを解析し、 そのタグとノードの現在のポートを比較します。差分が空ならそのまま実行されます。差分が空でなければ needs_rewire を返し （具体的な diff を含みます）、compose_workflow 経由で再配線します。Matrix グラフのないソースで不一致がある場合は no_editable_graph を返すため、Builder で編集してください。needs_rewire／no_editable_graph が返された後に、無理に再送信しないでください。 ノードが想定するタグは、事前に inspect_run の mergeTemplatePorts で確認できます。 references/diagnostics.md を参照してください。

• 配線ミスのあるグラフを送信する — run_workflow_submit は、ローカルで解決できたグラフをバックエンド呼び出しの前に構造的に検証するようになりました （validate_workflow と同じチェック）。実行できない問題があれば、errors[] リストを含む status:"invalid_workflow" を返します。 問題には、受信接続のない必須入力ポート、1 つのポートへの 2 本の接続、循環、存在しないノードへの接続があります。 配線を修正する（または compose_workflow／validate_workflow を再実行する）まで再送信しないでください。 孤立したノードや到達不能なノードは致命的ではなく、submitted 結果に warnings[] 配列として含まれます。 references/diagnostics.md を参照してください。

• 再配線した実行後に、永続化の提案を忘れる — 送信によって再配線済みの session_id が実行された場合、submitted 結果に postRun ブロックが含まれます。 完了したら、postRun.sessionId をキーとして save_workflow／publish_workflow／create_preset を提案し、 新しい配線が失われないようにしてください。通常の入力差し替えによる再実行には postRun はありません。その場合は提案しないでください。 references/featured-and-templates.md を参照してください。

• マージ CSV の @image ファイル名セルを署名付き URL に書き換える — CSV はそのまま送信してください。実行時にファイル名からベース名で配線済みアセットが解決されます。 CSV を編集するのは、診断によってファイル名とアセットの不一致が判明した場合に限り、かつユーザーに伝えてからにしてください。

• 通常の公開済み／インライン再実行で interfaceRerun: true を設定する — プリセット／インターフェースの実行を再現する場合（rerun.method: "inline_exact" かつ isInterface: true）にのみ使用してください。 references/diagnostics.md を参照してください。

• Claude Desktop で display_asset を呼び出す — 1MB の応答上限により、インライン表示は失敗します。テキスト URL のみを提示し、ローカル保存には saveTo を指定した download_output を提案してください。

• 大量の list_all_workflows 結果を grep／jq で処理する際に createdBy／workflowId を削除する、 または renderedTable の前に単独の typeSummary フィールドを別途貼り付ける — 個々の行のフィールドから一部を再構成するのではなく、応答の renderedTable フィールドを選択し、そのまま表示してください （このフィールドには、順に、ゴールデンデモ、種類別件数のブロック、必須の 5 列をすべて含む、そのまま貼り付けられる Markdown テーブルがすでに含まれています）。単独の typeSummary フィールドを別途貼り付けるのも避けてください （正しい位置にある renderedTable の中にすでに含まれており、両方貼ると重複します）。 nameDisplay／lastModifiedDisplay／statusDisplay のみを取り出し、createdBy を「すべてあなたが作成」といった文章にまとめるのは、 renderedTable が防ぐために存在する、繰り返し発生している誤りです。

• 単に「自分のワークフローを見せて」という意図に対して、list_all_workflows の前に list_golden_workflows を別途呼び出す、または list_all_workflows の renderedTable 冒頭にあるゴールデンデモの行を 1 行の「ゴールデンデモも利用できます」といった説明に縮めたり要約したりする — 上記の Tool routing にある「ワークフロー一覧を求める意図 — 1 回の呼び出し、3 つのセクション」を参照してください。 必要な呼び出しは list_all_workflows のみです。その renderedTable には、ゴールデンデモの行、typeSummary、 自分のワークフローのテーブルがすでにこの順序で含まれています。文字列全体を先頭から末尾までそのまま提示してください。 分割したり、list_golden_workflows も呼び出したり、いずれかのセクションを文章にまとめたりしないでください。

• 公開済みワークフローが実行できないときに compose_workflow に切り替える — 「この公開済みワークフローを実行して」という依頼が、どの送信形式でも Workflow has no input actions／Workflow with actions and connections is required／ invalid_input_target と空の validInputNodeIds: []／Circular dependency … action: undefined で失敗する場合、公開済みの定義が破損しています（実行可能な契約ではなく、生の React-Flow グラフから公開されています）。 1 行で原因を説明し、そこで停止してください。再構築のために再び compose してはいけません。ユーザーの依頼は既存のワークフローの実行であり、 新しいワークフローの作成ではありません。修正するには、正しく再公開する必要があります（compose_workflow の session_id または Workflow Builder）。 正しく公開されたワークフローの初回実行では、入力ノード ID を送信前チェックから取得してください （workflowId と inputs: [] → needs_reattach.rerunAssets.inputs[].nodeId）。 inspect_run から取得してはいけません（まだ実行されていない公開済みワークフローでは rerunAssets: none と報告されます）。 references/diagnostics.md を参照してください。

• inputs[] で 3D シーンノード（input-3d）を上書きする — MCP 経由の経路ではこの上書きは配線されておらず、取り込みレイヤーは以前、これをエラーなく破棄していました。 run_workflow_submit は代わりに nodeId／actionType を含む status:"unsupported_override" を返すようになりました。 再送信するのではなく、3D シーンの配線には Workflow Builder を使うようユーザーに案内してください。 references/diagnostics.md を参照してください。

• durabilityCoverage を確認せずに resolvedVia を信頼する — すべての rerunAssets／needs_reattach エンベロープには、durabilityCoverage: "authoritative" | "warmth-guessed" が含まれるようになりました。 authoritative（CAS／プリセット — 実際の永続性マップ）の場合、warm-url／durable-storage／unavailable の判定はバックエンドによるものです。 warmth-guessed（ドラフト／レガシー／ネイティブ — 設計上、永続ストアなし）の場合、URL の有効期限のみから推測されるため、 その場合の warm-url は警告なしに利用できなくなることがあります。再添付を促す ASK-FIRST の提案は、これに応じて調整してください。 references/diagnostics.md を参照してください。

• run_workflow_submit が、保存済みアセットの再利用前に必ず確認を求めると思い込む — 自動の needs_confirmation ガードが作動するのは、特定の実行の固定済みアセットを再利用する、実行履歴に基づく未変更の再実行に限られます。 一度も実行されていない公開済みワークフローでも自動確認は行われないため、ここでは引き続き ASK-FIRST の質問が必要です。 getPresetDefinition で解決されたインターフェースでも自動確認は行われませんが、理由は逆です。 その保存済みの既定値は信頼できるため、ASK-FIRST の確認は不要です。inputs: [] をそのまま送信してください。 references/diagnostics.md を参照してください。

参考資料

• ワークフロービルダー API ドキュメント — Firefly REST API を直接呼び出す場合は、firefly-api-specs を参照してください
• 必要に応じて：references/ — featured-and-templates、compose、diagnostics、asset-input、alert-rca