ワークフローの公開 (Publishing a workflow)

公開 (Publishing) は、保存されたワークフローを自己完結型のバンドル（ワークフロー本体に加え、必要なライブラリ、Python 依存関係、設定、関連ファイル一式）へとパッケージングし、実行可能な配布先（ディスク上のローカルフォルダ、Griptape Cloud 上の Structure、または Foundry Nuke 内の gizmo など）へ配信する機能です。このパッケージングと配信を担うコンポーネントをパブリッシャー (publisher) と呼び、配布先ごとに固有のパブリッシャーが存在します。

すべてのパブリッシャーは同一のライフサイクルに従い、同じ方法で依存関係を自動検出します。このページでは、共通の動作仕様と各パブリッシャーの違いについて解説します。公開したワークフローでメディアファイル（画像、音声、動画、テキストなど）が見つからないエラーが発生する場合は、静的ファイル: バンドルに確実に含める方法へお進みください。

パブリッシャー (Publishers)

公開機能自体はエンジンに組み込まれていますが、具体的なパブリッシャーはノードライブラリから提供されます。任意のライブラリがパブリッシャーを登録できるため、一覧に表示される選択肢はインストールされているライブラリによって異なります。Griptape 公式から以下のパブリッシャーが提供されています：

パブリッシャー	提供ライブラリ	ワークフローの配布先
Publish To Folder	Griptape Nodes Library	ヘッドレステストや実行が可能な、ディスク上の自己完結型フォルダ。
Griptape Cloud	Griptape Cloud Library	リモートから実行・統合可能な、Griptape Cloud 上のデプロイ済み Structure。
Publish To Nuke	Foundry Nuke Library	Foundry Nuke にインストールされ、Nuke UI から直接実行可能なバージョン管理された `.gizmo`。

公開を実行する際、どのパブリッシャーを使用するかを選択します。各パブリッシャーは必要な設定入力を要求します（Publish To Folder は出力ディレクトリの指定、Griptape Cloud は設定済みクラウドアカウントのバケットと Griptape Cloud Start Flow ノードの参照、Publish To Nuke はインストール先 Nuke 環境や gizmo ディレクトリ、既存バージョンの上書きか新規バージョンの作成かなどを確認します）。

公開前の準備

Publish Workflow ボタンは上部ツールバーの右端、サイドバーパネルの上（エンジン状態インジケーターの隣）に配置されています。これはエディタのグローバルアクションであり、ダイアログでどのパブリッシャーを選択する場合でも、ボタンの位置や操作は同一です。

ワークフローが一度以上ディスクに保存されている必要があります。 未保存の変更がある場合は公開時に自動的に保存されるため、直前に手動で保存し直す必要はありません。ただし、一度も保存されたことがない新規ワークフローはファイルパスを持たないため、公開前に一度保存を完了しておく必要があります。
パブリッシャーを選択します。 ワークフローの配信先に応じたパブリッシャーを選択します（上記テーブル参照）。パブリッシャーを提供するライブラリが 1 つだけの場合は、自動的に選択されます。
パブリッシャーのオプションを入力します。 選択したパブリッシャーが必要とする設定フィールド（例: Publish To Folder の出力先ディレクトリなど）が表示されます。可能な限り前回の公開時の値が事前入力されます。

公開処理の流れ

どのパブリッシャーを選択した場合でも、ライフサイクルの基本設計は共通です。エンジンは未保存の変更をワークフローファイルに保存し、選択されたパブリッシャーに処理を引き渡します。パブリッシャーはワークフロー内の全ノードを走査して依存関係を収集・バンドルし、最終的な宛先へ配信します：

flowchart TD
    A[Publish をクリック] --> B[エンジンが未保存の変更をワークフローファイルに保存]
    B --> C[エンジンが選択されたパブリッシャーに処理を引き渡す]
    C --> D[パブリッシャーがワークフロー内の全ノードを走査]
    D --> E[依存関係を検出:<br/>ライブラリ、pip パッケージ、静的ファイル]
    E --> F[ワークフロー + 依存関係 + 設定をバンドル化]
    F --> G{配信先}
    G -->|Publish To Folder| H[ディスク上の自己完結型フォルダ]
    G -->|Griptape Cloud| I[クラウド上のデプロイ済み Structure]
    G -->|Publish To Nuke| J[Nuke 内のバージョン管理された gizmo]

処理の進行中、パブリッシャーは Copying libraries... や Deploying workflow to Griptape Cloud... などの進行状況メッセージを報告するため、バンドルが組み立てられる過程を確認できます。

バンドルに含まれる内容

どの環境でも確実にワークフローを実行できるようにするため、すべてのパブリッシャーは共通の中核コンポーネントをアセンブルします：

ワークフローファイル 本体。
ワークフローが参照している ノードライブラリ 一式（間接的に依存している推移的ライブラリを含む）。
読み込むべきライブラリをエンジンに指示する 設定情報。
ワークスペースの環境全体、Secrets Manager で設定された すべての シークレット、および公開元のシェルの環境変数からエクスポートされたシークレットを含む、プレーンテキスト形式の .env ファイル（後述のセキュリティ警告を参照）。
実行時にディレクトリマクロやシチュエーションを解決するための プロジェクトテンプレート。
ワークフロー構築時に使用されていたエンジンおよびライブラリバージョンに固定された Python 依存関係。
ワークフローがモデルを使用する場合の Hugging Face モデルダウンロード手順。

バンドルにはすべてのシークレットが平文（プレーンテキスト）で含まれます

パッケージ化される .env は、そのワークフローが実際に使用するシークレットのみに絞り込まれるわけではありません。Secrets Manager で設定されたすべてのシークレットやワークスペース全体の .env（そのワークフローが一切使用しないサービスの API キーを含む）が、プレーンテキストのまま統合されます。また、公開を実行したシェル環境で設定されていた環境変数のシークレットも取得され、エンジン自身の解決ルールと同様にエクスポートされた値がファイルより優先されます（エンジンが認識しているシークレット名のみが対象です）。公開フォルダを渡された相手（または gizmo がインストールされたマシン上の全ユーザー）は、それらの認証情報をすべて閲覧できてしまいます。公開バンドルを他者と共有する前に、必ず同梱された .env を確認し、そのワークフローに不要なシークレットを手動で削除してください。

配信される成果物の形式はパブリッシャーごとに異なります：

Publish To Folder は、これらをディスク上のフォルダに書き出し、run.py エントリポイントと README.md を生成します。README には依存関係のインストール方法（uv sync）と実行方法（uv run python run.py --help）が記載されます。
Griptape Cloud は、これらを Structure パッケージとして zip 圧縮してアップロードし、クラウドアカウント内に Structure を作成または更新します。Webhook 連携の作成も可能であり、デプロイされた Structure を呼び出すための独立した executor ワークフローも自動生成されます。完了時には Griptape Cloud コンソール内のリンクが返されます。
Publish To Nuke は、選択された Nuke の gizmo ディレクトリにバージョン管理された .gizmo（およびランナースクリプト）をインストールし、Nuke のツールバーに Griptape サブメニューを追加して Nuke 内から実行できるようにします。再公開時は既存バージョンの更新か新バージョンの追加を選択でき、出力ファイルは Nuke スクリプトの隣に配置されるようルーティングされます。

依存関係の検出方法

パブリッシャーはワークフロー内のすべてのノードを巡回し、それぞれが何に依存しているかを問い合わせます。ワークフロー全体から以下の 3 種類の依存関係を集約します：

ライブラリ — 使用されているノードライブラリの名前とバージョン。それらのライブラリが依存する他のライブラリも含め、常に自動収集されます。
Python (pip) 依存関係 — 各ライブラリのマニフェストで宣言されている Python パッケージ。ワークフロー構築時と同一の環境を再現できるようバージョン固定されます。
静的ファイル — ノードがプロジェクトから読み込むメディアやデータファイル（画像、音声、動画、テキストなど）。これらはノードが依存関係として明示的に宣言している場合のみバンドルに含まれます。

この最後の項目は注意が必要な点であり、すべてのパブリッシャーに共通する仕様です。

静的ファイル: バンドルに確実に含める方法

参照されている外部ファイルがバンドルから欠落するリスク

静的ファイルは、それを使用するノードが明示的に依存関係として宣言している場合にのみバンドルに含まれます。すべてのノードが宣言を実装しているわけではありません。ノードがファイルを読み込むものの依存関係として宣言していない場合、そのファイルはバンドルから除外され、公開先でファイルが見つからずワークフローがエラーになります。これはどのパブリッシャーを使用する場合でも共通です。

ファイルを確実にバンドルに含めるための最も安全な方法は、Griptape Nodes Library に同梱されている SelectFromProject ノードを経由させることです：

SelectFromProject ノードを追加し、その selected_path 入力に含めたいファイル（またはディレクトリ）を指定します。
その project_path 出力を、実際にファイルを利用するノードへ接続します。

SelectFromProject は自身の selected_path を静的ファイル依存関係として明示的に宣言しているため、パブリッシャーは常にそのファイルをバンドルに対象として含めます。

プロジェクト内部のファイルはポータブルに保たれます

選択されたファイルがプロジェクト内部にある場合、SelectFromProject は絶対パスではなくプロジェクト相対のマクロパスとして解決します。これにより、バンドルを別のマシンへ移動したりクラウドへデプロイしたりした後でも、参照先が壊れません。

プロジェクトフォルダ外のファイルは持ち運ばれません

バンドルとともに持ち運ばれるフォルダの外側にあるファイル（外部ドライブやネットワーク共有上のファイル。直接参照している場合も、そこを指すディレクトリを経由している場合も同様）は、バンドル内に含める場所が存在しないため、元の場所にそのまま残されます。公開されたワークフローは同じ絶対パスを参照し続けるため、そのパスが存在するマシン上でのみ動作し、それ以外の場所では失敗します。

レンダリングファームなどがすでに同一マウントしている共有ストレージであれば問題ありません。持ち運びたいファイルの場合は、プロジェクトフォルダ内にコピーした上で、そのコピーを参照するようにしてください。

バンドルから除外されたファイルは、エンジンログに理由とともに will not be bundled because ... と記録されます。公開されたワークフローで必要なファイルが見つからない場合は、まずこのログ行を確認してください。エンジンログのエクスポートを参照してください。

どのような場合に使用すべきか？ 画像、音声、動画、テキストファイルなど、プロジェクトから読み込んだファイルが公開後のバンドルに見当たらない場合は、すべて SelectFromProject を使用してください。

自身でカスタムノードを開発している場合は、ノード自身が使用するファイルを正しく宣言するように実装することで、この回避策をユーザーに強いる必要がなくなります。後述のライブラリ開発者向け情報を参照してください。

ライブラリ開発者向け情報

公開システムは拡張可能です：ノードライブラリは任意の配布先をターゲットとする独自のパブリッシャーを提供でき、ノード自身が必要とするファイルを正確に宣言できます。

パブリッシャーの登録: ライブラリは AdvancedNodeLibrary を継承し、after_library_nodes_loaded 内で LibraryManager.on_register_event_handler(...) を通じて PublishWorkflowRequest のハンドラーを登録します。登録時には、ライブラリ自身の start/end flow ノード型（および任意でダイアログフィールドを定義する get_publish_options コールバック）も指定します。ハンドラーは公開ダイアログの選択可能なパブリッシャーとして表示されるようになります。いくつかのリファレンス実装が存在します：

Publish To Folder — Griptape Nodes Library (griptape_nodes_library_advanced.py)。出力先ディレクトリのオプションを提供し、ローカルフォルダへパッケージ化します。
Griptape Cloud — Griptape Cloud Library (griptape_cloud_library_advanced.py)。独自の GriptapeCloudStartFlow/GriptapeCloudEndFlow ノード型を登録し、ローカルディスクではなくクラウドへデプロイします。
Publish To Nuke — Foundry Nuke Library (nuke_library_advanced.py)。NukeStartFlow/NukeEndFlow ノード型を登録し、複数フィールドを持つダイアログを提供し、共通コンポーネントには共有パッケージャーを再利用した上で、独自の Nuke 専用インストール処理を行います。

パブリッシャーは自由にバンドルを配信できます。エンジンは PublishWorkflowRequest を処理して結果を返すことのみを要求します。共通コンポーネントのパッケージ化が必要な場合は、エンジンの WorkflowPackager を再利用できます。

バンドル内でのワークフローの検索: package_to_folder は、配置場所を示す PackagedBundle を返します。すべてのパスはパッケージ先フォルダからの相対パスです。ワークフローファイルを指し示す必要がある場合（エントリポイントスクリプト、バージョンフォルダへのコピー、README など）は、必ず entrypoint_workflow_path を使用してください。ファイル名から自前でパスを再構築しないでください：

packaged = self._packager.package_to_folder(destination, workflow)
workflow_in_bundle = destination / packaged.entrypoint_workflow_path

packaged.library_paths には、コピーされた各ライブラリの定義ファイルへのパスが格納されます。

パブリッシャー独自のファイル名の予約: パブリッシャー自身がバンドル内にファイルを書き込む場合は、エンジン独自の保護と同様の衝突防止を受けられるよう、パッケージャーにそれらを通知してください。package_to_folder にバンドル相対パスとして渡します：

self._packager.package_to_folder(
    destination,
    workflow,
    additional_reserved_paths=[Path("run.py"), Path("README.md")],
)

ノードの依存関係の宣言: 静的ファイルが除外されてしまう問題の恒久的な解決策は、各ノードが使用するファイルを自ら宣言することです。get_node_dependencies() をオーバーライドし、ファイルを NodeDependencies.static_files に追加します：

def get_node_dependencies(self) -> NodeDependencies | None:
    deps = super().get_node_dependencies()
    if deps is None:
        deps = NodeDependencies()
    value = self.get_parameter_value("path")
    if value and isinstance(value, str):
        deps.static_files.add(value)
    return deps

ライブラリやウィジェットの依存関係を維持するために、必ず最初に super().get_node_dependencies() を呼び出してください。

これを正しく実装している例として、Griptape Nodes Library の SelectFromProject (griptape_nodes_library/files/select_from_project.py) を参照してください。ノード開発全般についてはカスタムノード開発ガイドで詳しく解説されています。