Discourse ワークフロー

:discourse2: 概要 Discourse Workflows を使用すると、管理者は視覚的なビルダーを通じて高度な自動化を作成し、コミュニティ内のほぼすべてのことを自動化できます。
:open_book: インストールガイド このプラグインは Discourse コアにバンドルされています。プラグインを別途インストールする必要はありません。

Workflows は視覚的な自動化ビルダーであり、管理者はドラッグアンドドロップのキャンバスを使用して、トリガー、条件、アクション、フロー制御ノードを接続し、Discourse サイト上のほぼすべてのことを自動化できる高度な複数ステップの自動化を作成できます。

:discourse: Discourse Workflows は Business または Enterprise プランで利用可能です。

主要概念

他の自動化ツールに精通している場合、Workflows で使用される語彙のほとんどにすぐ気づくでしょう。

  • Workflow(ワークフロー): 接続されたノードで構成される保存済みの自動化。
  • Node(ノード): ワークフロー内の単一のステップ:トリガー、条件、アクション、およびフロー制御 / ユーティリティ。
  • Trigger(トリガー): ワークフローの開始点。トリガーは手動、または特定のイベント(トピックの作成、スケジュールの発火、受信 Webhook など)によって開始されます。
  • Condition(条件): 規則を評価し、フローをブランチに分割するルーティングノード。例えば、If ノードは true または false の評価に基づいてフローをルーティングします。
  • Action(アクション): 具体的な処理を行うノード — 投稿の作成、バッジの付与、外部 API の呼び出しなど。
  • Item(アイテム): ノード間で流れるデータ。Items は JSON オブジェクトであり、実行ログで確認したり、式を使用して参照したりできます。
  • Expression(式): {{ ... }} として記述された動的な値で、実行時に解決され、以前のノード、変数、またはサイト設定からのデータを参照するために使用されます。

ワークフローの作成

ワークフローを作成するには:

  1. 管理者 > プラグイン > Workflows に移動し、新規ワークフロー をクリックします。

  1. ワークフローに名前を付けます。
  2. 最初のステップを追加 をクリックし、トリガーを選択します。

  1. + ボタンを使用して追加のノードを追加します。

  1. ノードをダブルクリックして設定します。設定パネルでは、左側にノードの入力に関する詳細が、画面の右側にノードの出力に関する詳細が表示されます。すべての詳細を表示するには、ワークフローを一度実行する必要がある場合があります。

  1. 公開する準備ができたら、公開 をクリックします。

:light_bulb: ヒント:

  • ビルダーの右上にある三点メニューにある 付箋 を使用して、ワークフローの動作をドキュメント化してください。付箋はワークフロー自体には影響しませんが、テンプレートや共有ワークフローを理解しやすくします。
  • 開発中は ログノード を使用して、ワークフローの動作に影響を与えずにデバッグ値を実行ログに送信できます。
  • ワークフローを JSON として エクスポートおよびインポート して、チームメイトと共有したり、サイト間で移動したりできます。何が転送され、何が転送されないかは、下記「ワークフローのエクスポートとインポート」を参照してください。

式と動的データ

式を受け入れるフィールドには、エディターに {/} ボタンが表示されます。これをクリックして、トリガーや以前のノードから利用可能なデータを選択し、参照を挿入します。

一般的な式

式 返される内容
{{ $json.topic.title }} 現在のアイテムからのトピックのタイトル
{{ $json.post.url }} 現在のアイテムからの投稿の URL
{{ $json.user.username }} 現在のアイテムに関連付けられたユーザーのユーザー名
{{ $workflow_vars.my_variable }} my_variable という名前のワークフロー変数の値
{{ $vars.my_variable }} my_variable という名前のグローバル変数の値
{{ $site_settings.title }} サイトのタイトル
{{ $execution.id }} 現在の実行の一意の ID
{{ $('Node Name').item.json.property }} キャンバス名で参照される特定のアップストリームノードからの出力

静的値と動的値

= で始まるフィールドは式として扱われます。先頭に = がないフィールドはプレーンテキストとして扱われます。式ピッカーがこれを自動的に処理します。

ワークフローの管理

既存のワークフローを管理するのに役立つ機能が多数あります。

実行(Executions)

ワークフローが実行されるたびに、Discourse は実行を記録します。Workflows → 実行 に移動して履歴を確認してください。

各実行には、完了した日付と時刻、およびステータスが表示されます。

  • 完了: エラーなく完遂されました。
  • エラー: 特定のノードで失敗しました。実行をクリックして、エラーとその原因となったデータを確認してください。
  • 実行中: 現在処理中です。
  • 待機中: Wait ノードにより一時停止中。フォーム、モーダル、チャット承認への応答を待っているか、Call Workflow ノードがサブワークフローの完了を待っています。
  • レート制限: レート制限によりワークフローがスキップされました。
  • スキップ: トリガーは発火しましたが、ワークフローは未公開でした。

表示 ボタンをクリックすると、ワークフローの実行をより詳しく見ることができます。これにより、ワークフローの各ステップ(展開して正確な詳細を表示可能)と、そのステップの期間が示されます。

ページの下部では、ワークフロー全体の期間を確認できます。共有やトラブルシューティングのために必要に応じて、ログを エクスポート することもできます。

設定

Workflows → 設定 タブでは:

  • このワークフローの実行中に失敗が発生した場合にトリガーされる エラーワークフロー を設定できます。ワークフローにエラートリガーがある場合、そのトリガーで定義された方法でエラーを処理します。
  • スケジュールトリガーの タイムゾーン を設定します。未設定の場合、ワークフローはサイトのタイムゾーンをデフォルトで使用します。
  • ワークフローを削除 します。:warning: これは 永続的 です。続行する前に、ワークフローのエクスポート(ワークフロービルダーの右上隅にある三点メニューからアクセス可能)を検討してください。

バージョン

ワークフローを更新するたびに、以前のバージョンが保存されます。これにより、期待通りに動作しなかった変更を revert(元に戻す) することが容易になります。

ワークフローのエクスポートとインポート

ワークフロービルダーの右上隅にある三点メニューを使用して、ワークフローを JSON ファイルとして エクスポート し、ワークフローを読み込むために インポート します。一般的な用途:ワークフローをチームメイトと共有したり、ステージングサイトから本番サイトへ移動したりすること。

インポートすると、ファイルのノードが開いているワークフローに 追加 されます。新しいワークフローは作成されません。ワークフローをコピーするには、まず空のワークフローを作成し、そこにインポートしてください。インポートされた変更は、公開するまでドラフトとして保存されます。

エクスポートに含まれるもの: ノードとその構成、接続、付箋、およびワークフロー変数の定義。

転送されないため、公開する前に宛先サイトでこれらを設定してください:

  • 資格情報(Credentials): 資格情報の参照はインポート時に削除されます。宛先サイトで資格情報を作成し、各ノードで再度選択してください。
  • データテーブル: テーブル、列、行はエクスポートされません。それらを再作成し、Data table ノードで選択してください。
  • 変数の値: ワークフロー変数の定義はインポートされますが、その値はインポートされません。ワークフローの 変数 タブで設定してください。同じキーの変数がすでに存在する場合、インポートは既存の変数を保持し、スキップされたキーを表示します。グローバル変数はエクスポートされません。
  • ワークフロー設定: エラーワークフローとタイムゾーンは適用されません。設定 タブで再設定してください。
  • サイト固有の参照: カテゴリ、グループ、ユーザー、チャットチャンネル、Data Explorer クエリ、呼び出されたワークフローの ID、名前、URL はそのまま保持され、宛先サイトと一致しない場合があります。ワークフロー変数を使用すると、これらを変更しやすくなります。

:light_bulb: インポートしたワークフローを手動で実行し、公開する前に 実行 ログを確認してください。

変数

2種類の variable があります:

  • ワークフロー変数 は単一のワークフローにスコープされます。ワークフローの 変数 タブで定義し、{{ $workflow_vars.key_name }} を使用して参照します。これらはタイプ(文字列、整数、ブール値、列挙、カテゴリ、カテゴリリスト、グループ、グループリスト、タグリスト、リスト)を持っています。そのため、値が検証され、適切なセレクターで選択されます。定義と値への変更は、ワークフローのドラフト/公開フローに従います。
  • グローバル変数 はすべてのワークフローで共有されます。Workflows → 変数 で定義し、{{ $vars.key_name }} を使用して参照します。

サイトや用途によって変化する値(カテゴリ、グループ、受信者など)にはワークフロー変数を使用してください。これにより、ノードを編集せずにワークフローを再利用できます。

資格情報

一部のノード(HTTP リクエストや AI Agent など)は、外部サービスで認証する必要があります。API キーやシークレットをノードフィールドに直接貼り付ける代わりに、Workflows → 資格情報 に保存します。資格情報は保管時に暗号化され、ワークフロー間で再利用できます。

サポートされている資格情報タイプ:

  • Basic Auth(ユーザー名 + パスワード)
  • Bearer token
  • Header auth(カスタムヘッダー名と値)

データテーブル

データテーブルは、Workflows プラグイン内部の永続的な構造化されたテーブルです。Data table ノードを使用して、読み取りまたは書き込みを行います。string、number、boolean、date 列タイプをサポートしています。

データテーブルは以下に役立ちます:

  • 重複排除 — ワークフローがすでに処理したユーザーやトピックを記録
  • 状態管理 — トピックがプロセスの特定の段階にあるかどうかを追跡
  • ルックアップ — ワークフローがクエリできるマッピング(トピック ID → 割り当てられたスタッフメンバーなど)を保存

実行

すべてのワークフローの実行は、実行 タブから確認できます。フォーマットと機能はワークフロー固有の実行と非常に似ていますが、すべてのワークフローにわたって表示されるため、監視が容易になります。

テンプレート

新しいワークフローを作成する際、空白のキャンバスの代わりに テンプレート から開始できます。テンプレートは一般的なユースケース向けの事前構築されたワークフローです。動作を説明する付箋が含まれており、システムを学ぶのに良い方法です。

:megaphone: さらに多くのテンプレートを見てみたいですか? 利用可能なテンプレートのライブラリを時間とともに拡張するために尽力していますが、Workflows の使用を容易にするためにここで見てみたいテンプレートがあれば、お知らせください。

また、任意のワークフローを JSON ファイルとしてエクスポートして他者と共有したり、独自の開始点として使用したりできます。

「いいね!」 24

こんにちは、このプラグインを有効化しようとしたところ、次のようなエラーメッセージが表示されました:「非表示の設定 discourse_workflows_enabled を変更する権限がありません」

「いいね!」 2

現在、/admin/config/upcoming-changes から有効化する必要があり、admin/plugins からはできません

「いいね!」 3

こんにちは。これらのワークフローの目的を正しく理解しているなら、トピックに管理者ボタンを追加し、すぐにトピックを最上部に移動させることを希望しています。可能ですか? :grinning_face:

「いいね!」 1

やあ!

「AIで構築」機能が特定のLLMを使用するようにするには、どのように確認すればよいでしょうか?
システムでデフォルトのLLMとしてGoogle Geminiを使用すると、次のエラーが発生します:
Invalid JSON payload received. Unknown name “additionalProperties” at ‘tools[0].function_declarations[5].parameters’: Cannot find field

ありがとうございます!

「いいね!」 1

どの Gemini モデルを使用していますか?変更するには、ワークフローエージェントを選択し、デフォルトの LLM を交換してください。

「いいね!」 1

サム、こんにちは! Gemini 3 Flash です。

ワークフローの設定を見つけましたが、確かに Gemini Flash 3 になっていました。GPT Nano 5 に変更しましたが、同じエラーが発生します。

さらに、全ユーザーのデフォルトを GPT Nano 5 に変更し、個々のワークフロー設定も確認しました。そちらも GPT Nano 5 で上書きするように設定しました。

しかし、一向に改善しません。:frowning:

「いいね!」 1

Luna、Terra、3.5 Flash、または Sonnet にアクセスできる可能性はありますか?

ワークフロー AI エージェントにはかなり多くのツールが備わっているため、比較的新しい LLM が必要になる傾向があります。

「いいね!」 1

Flash Lite が動作していたと確信していましたが、実際にはそうではありませんでした。GPT Nano 5 は確実に動作しました。これは WordPress でも既知の問題のようです。参考リンクを以下に示します。Gemini プロバイダーを使用する際は、JSON レスポンススキーマから additionalProperties アイテムを削除する必要があります: Remove `additionalProperties` from the JSON response schema - Pull Request #18 - WordPress/ai-provider-for-google - GitHub

うわ、インタラクションAPIへの移行を急ピッチで進めてるから、これでGeminiモデルへの接続がずっと安定するはず。来週には完了できると思う。

「いいね!」 2

すばらしいです!迅速な対応に感謝します! さらにいくつかのコンテンツを見つけましたが、大概のことはご理解いただけていると思います。 :wink:

これはGoogle自身のGeminiによる説明です。意味が通じるでしょうか? 私はすべてを理解しているわけではありませんが、そのプロパティでエラーが発生していることはわかっています。LOL。

要約: エラーが継続しているのは、Googleがスキーマ処理のために2つの全く異なるエンジンを使用しているためです。Geminiは構造化出力(response_json_schema)に対して標準的なJSONスキーマをサポートしていますが、その関数呼び出し/ツール実行エンジンはまだGoogleの厳格なOpenAPI 3.0 Protobufパーサーを使用しており、additionalPropertiesを拒否またはエラーの原因としています。

1. ツール呼び出し vs 構造化出力(エンジンの分岐)

GoogleのGemini APIは、2つの異なる場所でスキーマを検証します:

  • 構造化出力(response_json_schema): モデルの最終レスポンスをフォーマットするために設計されています。標準的なJSONスキーマ解析を使用し、additionalPropertiesを問題なく処理します。

  • ツール/関数呼び出し(tools[0].function_declarations): サイトのツール(Discourse AI検索、ペルソナアクション、またはウェブブラウジングなど)をモデルに渡すために設計されています。このエンドポイントは、スキーマをGoogleの内部Protobufオブジェクト google.ai.generativelanguage.v1beta.Schema に解析します。

ツールエンドポイントがパラメータをレガシーなOpenAPI 3.0サブセットにマッピングするため、関数宣言でadditionalPropertiesを送信すると、APIパーサーは400 Bad RequestまたはMALFORMED_FUNCTION_CALLを返します。

GitHub

2. Discourseなどのフレームワークがこれを注入する理由

オーケストレーションフレームワーク(Discourse AI、Model Context Protocol/MCP、LangChain、Pydantic、Zod)は、カスタムツールのために自動的にJSONスキーマを生成します:

  1. 厳格な強制のデフォルト: ジェネレーターは、厳格なパラメータ型を強制するために自動的に"additionalProperties": falseを追加します。

  2. 動的なマップ/辞書: ツールパラメータがキー値のハッシュ/辞書(例:dict[str, Any]またはRubyのHash)を使用する場合、スキーマジェネレーターは"additionalProperties": { "type": "string" }を出力します。

  3. 未サニタイズされたペイロード: Discourseがこれらの自動生成されたツールスキーマをGoogleの関数宣言エンドポイントに送信すると、GeminiのProtobufパーサーはadditionalPropertiesを無効または未知のフィールドとしてフラグ立てます。

3. Discourseでの解決方法

Discourse AIのツール呼び出しでこのエラーが発生している場合:

  • 動的なハッシュ/辞書パラメータを避ける: カスタムツールのパラメータが、オープンエンドなオブジェクトを使用するのではなく、propertiesの下に期待されるすべてのキーを明示的に定義していることを確認します。

  • 動的データを文字列としてシリアライズする: ツールが任意のキー値ペアを受け入れる必要がある場合は、パラメータをSTRINGとして定義し、ツールにシリアライズされたJSON文字列を受け入れるように指示します。

  • カスタムツールでadditionalPropertiesをフィルタリングする: /admin/plugins/discourse-ai/ai-toolsの下にカスタムAIツールが定義されている場合は、パラメータのJSONスキーマを編集して、"additionalProperties"ブロックをすべて削除します。

インタラクション API のサポートを追加する PR を作成しました。テスト環境があれば、さらにテストしていただけると幸いです。

ワークフローを通じて外部ユーザーIDを取得できるようにする予定はありますか?私は、現在のユーザーに関する情報をアイデンティティプロバイダシステムで確認してから処理を続行するフォームを作成したいのですが、Get Userノードはexternal_idフィールドを出力していないようです。

フィードバックありがとうございます。これで問題が解決するはずです:FIX: supports optional data for workflow user node (#42400) · discourse/discourse@4d0c688 · GitHub

「いいね!」 3

user_id を username に変換する方法はありますか?トピックの作成者に個人メッセージを送信するユースケースを調べていました。しかし、topic オブジェクトからは user_id しか取得できず、個人メッセージを送信するアクションでは代わりに username が必要です。

あるいは、topic_id を使って最初の投稿を取得する方法があれば、それも機能するでしょう。投稿には username フィールドがあるようです。

「いいね!」 1

@thgl はい、データエクスプローラーノードがあるため、あらゆる種類の情報を取得するクエリは可能です(この場合はuser_idをハードコードしていますが、ご理解いただけたかと思います):

workflow-nodes-2026-08-18.json|添付ファイル (2.1 KB)

「いいね!」 2

@patrickemin すでに確認済みかどうかはわかりませんが、このユースケースに必要なすべてのビルディングブロックを追加しました。サポートが必要な場合はお知らせください。

「いいね!」 1

へえ、それは便利ですね、ありがとうございます!

さて、そのユースケースのために管理者トピックに割り当てるアクションが見つかりませんでした: