pipefy-automations

自動化

現在使用しているインターフェースのリファレンスのみを確認してください：MCP または CLI。以下のワークフローでは、共通の操作名と引数を使用します。

従来型の自動化（if/then ルール）、AI 自動化（プロンプト駆動型）、タスク自動化、シミュレーション。

振る舞いを備えた会話型エージェントについては、pipefy-ai-agents を参照してください。

---

従来型の自動化（ルールエンジン）

操作	目的
get_automations	event_id、event_params、condition、actionEnabled、disabledReason を含むルールを一覧表示します。空の条件式は API のプレースホルダーであり、有効なフィルターではありません。1 ページに含まれるルールは最大 50 件です。ルールやフィルターが存在しないと判断する前に、after を使って続きのページを取得してください。
get_automation	ルール設定全体を含む単一の自動化を取得します。event_params と action_params（AI ルールの場合は aiParams を含む）を返します。
create_automation	if/then ルールを作成します。active のデフォルト値は true です。型付きの第一級 condition（条件 を参照）を使用し、その他のフィールドには extra_input を使用します。
update_automation	ルールにパッチを適用します。型付きの第一級 condition（条件 を参照）および／または extra_input を使用します。
delete_automation	取り消しできない削除を行います。
simulate_automation	AI 専用のドライラン（generate_with_ai アクション）です。
get_automation_events	利用可能なトリガーイベントを取得します。
get_automation_event_attributes	公式の field_map.value イベント属性トークンを取得します。
get_automation_actions	パイプで利用可能なアクションタイプを取得します。
create_send_task_automation	タスク送信ルールを作成するためのショートカットです。

自動化のログ、使用状況、ジョブのエクスポートは pipefy-observability にあります（get_automation_logs、get_automation_logs_by_repo、get_automations_usage、export_automation_jobs および関連ツール）。

---

AI 自動化（プロンプト駆動型）

同意： AI 自動化の作成または提案は、ユーザーが明示的に AI を求めた場合に限ります。有用と思われても依頼されていない場合は、まず確認してください。依頼なしに AI 自動化を導入してはいけません。

操作	目的
get_ai_automations	パイプの混在リストから generate_with_ai ルールを一覧表示します。1 ページに含まれる混在ルールは最大 50 件です。AI ルールが存在しないと判断する前に、after を使って続きのページを取得してください。
get_ai_automation	プロンプト、フィールド、条件を含む設定全体を取得します。
create_ai_automation	プロンプト駆動型の自動化を作成します（パイプで AI が有効になっている必要があります）。
update_ai_automation	名前、active、プロンプト、field_ids、または condition を変更します。
delete_ai_automation	取り消しできない削除を行います。
validate_ai_automation_prompt	事前チェックです。 {valid, problems, warnings, field_map} を返し、プロンプト内の %{id} と field_ids の重複も検出します。

---

手順 — AI 自動化を作成する

1. プロンプト内で参照するすべてのフィールドについて、フィールドの internal_id を確認します。

   get_phase_fields phase_id="<phase_id>"
   

2. %{<internal_id>} 参照を使ってプロンプトを作成します。フィールド参照のないプロンプトは Pipefy によって通知なく拒否されます（"Input parameters are required." が返されます）。

   重要： %{...} のラッパーと、自身のパイプから取得した数値のフィールド internal_id が必要です。以下の例にある正確な数字（例：900000101）は架空のプレースホルダーです。get_phase_fields／get_start_form_fields で実際の ID を確認してください。ドキュメントの例にある数字をコピーしないでください。

3. プロンプトを検証します。

   validate_ai_automation_prompt pipe_id=67890 prompt="Summarize %{900000102} into the summary field." field_ids=["900000101"]
   

   valid:true|false、problems、warnings、field_map が返されます。読み取り専用の 1 回の呼び出しでミスを検出でき、変更操作を 2～3 回失敗させる必要がありません。

4. 自動化を作成します（valid:true の場合のみ）。選択したイベント ID、パイプ ID、プロンプト、出力フィールド ID、名前を使用します。MCP ではこれらを event_id、pipe_id、prompt、field_ids、name として指定します。SDK では、これらを含む CreateAiAutomationInput を使用します。呼び出し方法については、現在使用しているインターフェースのリファレンスを参照してください。

手順 — 従来型の自動化を作成する

1. パイプのイベントを確認します：get_automation_events pipe_id=67890。
2. パイプのアクションを確認します：get_automation_actions pipe_id=67890。（必ず最初に確認してください。trigger_id／action_idを推測してはいけません。）
3. イベントとアクションの互換性を確認します：選択したevent_idが、そのアクションのeventsBlacklist（get_automation_actionsから取得）に含まれている場合、その組み合わせは無効です。別のものを示すtriggerEventsを判定に使ってはいけません。イベントとアクションの互換性を参照してください。
4. 確認したIDを使ってルールを作成し、create_automationを呼び出します。
5. get_automationで読み戻して検証します。

---

条件 — フィールドのテストでルールを適用する

create_automationとupdate_automationでは、第一級のconditionを指定できます。GraphQLイントロスペクションから形状を推測してはいけません。実際の形状は次のとおりです。

{
  "expressions": [
    {"field_address": "900000101", "operation": "equals", "value": "Done", "structure_id": 0}
  ],
  "expressions_structure": [[0]]
}

• field_addressはフィールドの**internal_id**（get_start_form_fields／get_phase_fieldsから取得する数値）であり、スラッグではありません。接続されたカードのフィールドには、<connectorFieldId>.<targetFieldId>を使います。
• operation（ソフト列挙型。任意の値がそのまま渡され、APIで検証されます）：equals、not_equals、present、blank、string_contains、string_not_contains、number_greater_than、number_less_than、date_is_today、date_is_yesterday、date_in_current_week、date_in_last_week、date_in_current_month、date_in_last_month、date_in_current_year、date_in_last_year、date_is、date_is_after、date_is_before。present／blankではvalueを省略します。
• expressions_structureは、位置ではなくstructure_idで式をグループ化します。1つの内側の配列にある式はANDで結合され、内側の配列どうしはORで結合されます。[[0, 1], [2]]は(expr0 AND expr1) OR expr2、[[0, 1]]はexpr0 AND expr1、[[0], [1]]はexpr0 OR expr1です。各式にはそれぞれ独自のstructure_idを指定してください。同じstructure_idを共有する2つの式を[[0], [0]]として送信すると、expressionsは空で保存され、expressions_structureは[[0], [0]]のままになります。このルールはカードに一致しません。
• APIは、使用できないものをエラーを返さずに削除します。該当するstructure_idがない数値、空の内側の配列、一覧にないstructure_idを持つ式、field_addressまたはoperationがない式が対象です。ANDグループから式が1つ削除されると、そのグループの条件を満たしやすくなるため、より多くのカードに一致する可能性があります（[[0, 1]]で式が1つ削除された場合は[[0]]として保存されます）。ORグループ内の唯一の式が削除されると、そのグループがなくなるため、一致するカードは少なくなります（[[0], [1]]で式が1つ削除された場合は[[0]]として保存されます）。書き込み後はget_automationでルールを読み戻してください。空のexpressions_structureはすべてのカードに一致します。同じ数値を2回指定すると、is invalidで失敗します。

従来型のルールを無条件にするには、conditionを省略します（デフォルトは注入されません）。condition引数は、extra_input内のconditionより優先されます。

---

手順 — 動的な値でカードのフィールドを更新する

ユーザーが、トリガーとなったカードに値を設定またはコピーする if/then ルールを求めている場合に使用します（たとえば、card_created が発火したときに日時を設定する場合など）。これは action_id: update_card_field と extra_input.action_params.field_map を指定した create_automation です。単発の update_card_field 操作ではありません（このツールは、カードを単発で編集する際にフィールドの slug を使用します）。

1. フィールドの internal_id を確認します（数字のみ — fieldId に slug は使用しないでください）。

   get_start_form_fields pipe_id=67890
   get_phase_fields phase_id="<phase_id>"
   

2. トリガー、アクション、イベント属性のトークンを確認します。

   get_automation_events pipe_id=67890
   get_automation_actions pipe_id=67890
   get_automation_event_attributes
   

   update_card_field の場合、acceptedParameters には field_map が含まれません。以下のペイロード形式を使用してください（docs/mcp/tools/automations-and-ai.md を参照）。実行時刻を設定する場合は、get_automation_event_attributes の value_token を優先してください。

3. 検証中にルールが発火しないよう、無効状態（active=false）で作成します。

   create_automation pipe_id=67890 name="Stamp execution time on new cards" trigger_id=card_created action_id=update_card_field active=false extra_input={"action_params":{"card_id":"%{id}","field_map":[{"fieldId":"<destination_internal_id>","inputMode":"copy_from","value":"%{automation_event_execution_datetime}"}],"fields_map_order":["<destination_internal_id>"]}}
   

   inputMode が copy_from の場合によく使う value トークン：%{id}（card_id にも使用）、%{created_at}、%{automation_event_execution_datetime}、別のフィールドからコピーする場合は %{<other_internal_id>}。

4. 保存された設定を確認します。

   get_automation automation_id=<id>
   

   action_params.field_map が往復して保持されていることを確認します。

5. 正しければ有効にします。

   update_automation automation_id=<id> extra_input={"active":true}
   

---

手順 — 従来型のオートメーションをシミュレートする

現在、simulate_automation はAI 専用です（generate_with_ai の action_id のみ受け付けます）。AI 以外のルールでは、トリガーの発火後に get_automation_logs を確認してください。

1. まず動作するルールを読み込みます：get_automation automation_id=<id> — event_params と action_params をそのままコピーします。

2. 実際のサンプルカードを使ってシミュレートします。

   simulate_automation pipe_id=67890 action_id=generate_with_ai sample_card_id=456
   

3. 直後の結果を読み込みます。simulation_id と status:"processing" が含まれ、simulationResult が null の場合があります。ID を控え、execute_graphql でシミュレーションを再度読み込みます。simulate_automation を再度呼び出すと、新しいシミュレーションが開始されます。

   query { automationSimulation(simulationId: "<simulation_id>") { status simulationResult details { errorType message } } }
   

   status が processing 以外になるまで、少し待ってから再度読み込みます。何度か読み込んでも処理中のままの場合は、ID とともに結果が保留中であることを報告してください。

---

従来型オートメーションの事前確認

イベント×アクションの互換性

この制約は拒否リストです。get_automation_actions の該当アクションの eventsBlacklist に event_id が含まれている場合、その組み合わせは無効です。これは、get_automation_events の該当イベントの actionsBlacklist に action_id が含まれている場合と同じです。カタログ内のすべての項目で2つのリストは一致しているため、どちらで確認しても構いません。

triggerEvents はそのリストではないため、判定条件として使用してはいけません。これはビルダーが最初に提示する組み合わせを示しているため、含まれているかどうかで判定すると、拒否リストでは許可されている組み合わせまで拒否してしまいます。field_updated + move_single_card は triggerEvents にありませんが、そのルールはカードを作成して移動します。カタログには、このような判定を無効にする3つのパターンがあります。send_a_task と send_email_template は triggerEvents: [] を返しますが、拒否リストでは10個のイベントのうちそれぞれ7個と9個で許可されています。schedule_create_card と move_multiple_cards は、自身の eventsBlacklist の項目を triggerEvents 内に列挙しています。また、triggerEvents が空でないアクションはすべて、そのリストにないイベントでも拒否リストでは許可されています。

create_automation は拒否リストを適用します。拒否リストにある組み合わせを指定すると、翻訳されていないエラーが返されます。その判読可能な部分はキー event_action_blacklist で、何も書き込まれません。このキーは「このイベントではこのアクションを実行できない」という意味として解釈し、別の組み合わせを選んでください。

update_automation は拒否リストを適用しません。保存済みルールの event_id を、そのアクションの eventsBlacklist にあるイベントに変更すると、更新は成功して保存されます。たとえば、card_created + move_single_card として作成したルールは、scheduler + move_single_card への更新を受け付けますが、この組み合わせは作成時には拒否されます。そのため、更新によって拒否リストにある組み合わせのルールが存在することがあります。更新前に拒否リストを確認する責任は API ではなく呼び出し元にあります。

カタログの表記と入力時の表記は異なります

get_automation_events は acceptedParameters を snake_case で返しますが、AutomationEventParamsInput では、そのうち1つを除いてすべて camelCase で定義されています。カタログの表記を送信すると、Field is not defined on AutomationEventParamsInput というエラーになります。対応関係は次のとおりです。

パラメーター	カタログの表記	送信する event_params のキー
トリガーのフィールド	trigger_field_ids	triggerFieldIds
SLA の種類	kind_of_sla	kindOfSla、値は大文字始まり：Expired、Late、Overdue
元のフェーズ	from_phase_id	fromPhaseId
現在のフェーズ	in_phase_id	inPhaseId
上流ルール	trigger_automation_id	triggerAutomationId
移動先のフェーズ	to_phase_id	to_phase_id。snake_case のままなのはこのキーだけです

繰り返しルールでは、スケジュールを event_params の外側に指定します。scheduler_frequency（hourly、daily、weekly、monthly）と、5つの文字列（minute、hour、dayOfMonth、month、dayOfWeek）が必須のオブジェクト schedulerCron を指定します。cron 文字列ではありません。

ラベルを適用するオートメーションアクションはありません

ここで作業を止めてください。 カタログには、カードにラベルを適用するアクションがありません。不足しているのはトリガーではなくアクションです。sla_based はイベントカタログに含まれているため、「カードの期限が過ぎたとき」は、紐づけるアクションがないだけで、有効なトリガーです。特定のパイプで利用できるアクションの動的な情報源は get_automation_actions(pipe_id) です。ルールを計画する前にこれを確認し、ラベルアクションがあると決めつけないでください。

この意図に対してできること：

1. スクリプトではなく、製品側で設定する方法を案内してください。 ラベルルールは顧客のプロセスに組み込むもので、誰かが操作しなくても実行され続けます。API では作成できないため、Pipefy でルールを設定し、そのトリガーでインターフェースにどのような選択肢が表示されるか確認してもらうよう、手動での手順を案内してください。メールテンプレートの場合と同じように、その手順を計画またはユーザーに渡す概要に記載します。

2. 適合する場合は、実際に作成できるルールを提案してください。 update_card_field は sla_based を受け付けるため、「カードの期限が過ぎたときに、カードのフィールドに値を記録する」というルールは、現在 create_automation で作成できます。ステータスまたはフラグ用フィールドがあれば、ラベルと同じシグナルを伝えながら、プロセス内にルールを維持できます。まず get_start_form_fields / get_phase_fields で適切な移動先フィールドを見つけてください。Status という名前のフィールドがないパイプも多く、オートメーションには実際の internal_id が必要です。押しつけずに提案してください。ユーザーはラベルそのものを希望しているかもしれません。

   sla_based のパラメーターは event_params.kindOfSla（camelCase）で指定します。get_automation_events では kind_of_sla と報告されますが、値は大文字始まりの Expired、Late、Overdue です。カタログの表記を送信すると、"Field is not defined on AutomationEventParamsInput" というエラーになります。以下の field_map の手順に従い、inputMode も含めてアクションを組み立ててください。

3. update_card(label_ids=[...]) は一度限りの修正であり、オートメーションではありません。 カードのラベル一覧全体を置き換えるため、追加するラベルだけでなく、残すラベルの ID もすべて含めてください。この呼び出しは毎回実行する必要があります。セッション終了後、プロセスの動作としては残りません。ユーザーが指定した特定のカードを修正するために使い、その旨をはっきり伝えてください。ルールの代わりに複数のカードに対して呼び出してはいけません。また、スケジュールに沿って繰り返し実行してもいけません。その場合、プロセスではなくエージェントが実行主体になってしまいます。

4. ラベルの CRUD は別の機能です。 create_label、update_label、delete_label は、パイプ上のラベル定義（名前、色）を管理します。いずれもカードにラベルを適用する機能でも、オートメーションアクションでもありません。

5. 代替案として、AI オートメーションやエージェントの動作を提案してはいけません。 AI の使用をプロセスで禁止している組織もあります。また、同意に関するルールはここにも適用されます。ユーザーが明示的に依頼した場合に限り、AI を提案してください。

field_map の宛先 fieldId

create_automation で extra_input.action_params.field_map が指定されている場合、SDK は各 fieldId を、アクションパイプ（action_repo_id。デフォルトは pipe_id）の数値の internal_id と照合します。スラッグ形式の fieldId と不明な数値 ID は、GraphQL の呼び出し前に、該当する ID を示してエラーになります。対処方法：get_start_form_fields／get_phase_fields を使い、スラッグではなく internal_id を使用してください。

フェーズ遷移（move_single_card）

トリガーが card_moved の move_single_card アクションでは、create_automation のみ、遷移先フェーズに移動できることを、cards_can_be_moved_to_phases（move_card_to_phase と同じ読み取り専用データ）を使って検証します。update_automation ではこのチェックは実行されません。

無効な場合は、許可されている遷移先フェーズの一覧と、UI 専用の遷移設定に関するヒントを含むエラーメッセージを確認してください。

対処方法：error.message に記載された許可済みフェーズを確認するか、event_params.to_phase_id にあるソースフェーズに対して get_phase_allowed_move_targets(phase_id=<source_phase_id>) を呼び出し、許可された遷移先フェーズ ID を指定して create_automation を再実行してください。

---

通知の使い分け

「通知」に関する意図に合ったツールを選択してください。

ユーザーの意図を示す語句	ツール	理由
「notificação」、「tarefa」、「lembrete para alguém validar」	create_send_task_automation	標準機能で、event_id、task_title、recipients、任意の event_params と condition に対応します。
「enviar e-mail」、「responder ao cliente」	send_email_with_template / send_inbox_email (pipefy-members-email-webhooks)	メール機能であり、オートメーションではありません。
「webhook」、「chamar serviço externo」	create_webhook (pipefy-members-email-webhooks)	カードイベント発生時の HTTP コールバックです。
「automação」、「regra if/then」	create_automation	汎用ルールエンジンです。

create_send_task_automation が適切な場合、create_automation を使って action_params.taskParams を手動で組み立てないでください。

メールを送信するオートメーションには、既存のテンプレートが必要です。テンプレートの作成、編集、削除は API からは行えず、Pipefy の UI でのみ操作できます。新しいテンプレートまたは変更済みのテンプレートが必要な場合は、ユーザーに提示する計画または概要に、その UI での手動操作を明記してください。

---

エージェントと人間による確認を組み合わせたパターン

AI オートメーションとタスクオートメーションを組み合わせ、AI が定型作業を処理し、人間が重要な判断を確認できるようにします。カタログの中でも、特に効果の高いパターンです。

フローの例：

1. create_ai_automation：カードが「分析」に入ると、AI が分類フィールドとリスクフィールドを自動入力します。
2. create_send_task_automation：AI が入力したフィールドが更新されると、マネージャーに「カード [title] の分類を確認してください」というタスクを送信します。
3. create_automation または create_field_condition：マネージャーが「承認済み」とマークすると、カードを次のフェーズに移動します。

承認、財務上の判断、コンテンツの公開など、エラーが現実世界に影響を及ぼす可能性のあるあらゆる段階で、このパターンを使用してください。pipefy-process-design のオーケストレーションパターンも参照してください。

---

成功基準

• get_automation が、新しいルールと正しいトリガーおよびアクションを返します。
• AI オートメーションを作成する前に、validate_ai_automation_prompt が valid:true を返します。
• simulate_automation（AI ルール）がシミュレーション ID を返し、その後の automationSimulation の読み取りで最終的な simulationResult が返されるか、ID を添えて結果が保留中であると報告されます。

失敗モード

自動化が実行されない／ログが空

1. get_automation — ルールとその condition を再読み込みします。
2. ペアの組み合わせが拒否リストに該当しないか確認します（イベントとアクションの互換性を参照）。create はブラックリストに登録された組み合わせを拒否しますが、update は拒否しないため、作成後にパッチされたルールに該当する組み合わせが含まれることがあります。その後、カードでイベントが実際に発生したことを確認します。
3. ログが空でも、プラットフォームの障害が証明されたわけではありません。ルールが無効（active: false）になっている、アクションがオフ（actionEnabled: false、disabledReason が設定されている）になっている、または単にまだトリガーされていない可能性があります。
4. field_map の fieldId が無効な場合、カードが更新されずに失敗することがあります（下記を参照）。
5. 「サービスが利用できない」と結論付けたり、プラットフォームのせいにしたりする前に、ツールのエラーペイロードと必須フィールド／フェーズ遷移に関するヒントを確認します。

その他の失敗モード

• simulate_automation は AI 専用です。 generate_with_ai の action_id のみ受け付けます。従来型のルールでは、ルールの実行後に get_automation_logs を使用してください。
• シミュレーション結果は非同期で返されます。 processing レスポンスには、まだ最終結果が含まれていません。simulation_id を保存し、execute_graphql 経由で automationSimulation クエリを使って結果を取得してください（手順 — シミュレーションを参照）。get_automation_logs には実際のオートメーション ID が必要です。また、simulate_automation を再度呼び出すと、新しいシミュレーションが開始されます。
• validate_ai_automation_prompt が valid:false を返します。 problems（フィールドごと）と warnings を確認してください。よくある原因は、プロンプトに %{internal_id} の参照がないこと、または field_ids がプロンプト内の %{id} トークンと重複していることです。
• create_automation の循環検出。 同じパイプで card_created と create_card を組み合わせると、"This automation can't be created! It would result in an endless card creation cycle." というエラーで拒否されます。別のトリガーを使う、別のパイプを対象にする、または update_card を使ってください。
• create_automation が不明なイベント／アクションで失敗します。 必ず最初に get_automation_events と get_automation_actions を実行してください。ID を推測しないでください。
• ラベルを適用するルールを予定している場合。 カタログに該当するアクションはありません。トリガーはあります。sla_based を利用できるため、ないのはラベルアクションのみです。他の方法を案内する前に、ラベルを適用するオートメーションアクションはありませんを参照してください。
• move_single_card でフェーズ遷移エラーが発生します。 遷移を事前検証するのは create_automation のみです。エラーテキストで許可されているフェーズ ID を確認するか、get_phase_allowed_move_targets を呼び出してから、許可された移動先を指定して再実行してください。遷移ルールを編集できるのは UI のみです。
• パイプ間で PERMISSION_DENIED が発生します。 create_connected_card／パイプ間の create_card を実行するには、SA が移動元と移動先の両方のパイプのメンバーである必要があります。解決するには、get_pipe_members と invite_members を使用してください。
• get_automation_logs_by_repo が空の結果を返します。 パイプに従来型オートメーションの実行履歴がありません。これはエラーではありません。AI エージェントの実行履歴は別に管理されています（get_ai_agent_logs を参照）。
• create_send_task_automation は active=true の場合、すぐに実行されます。 ルールの実行開始前に設定したい場合は、最初に active=false を渡してください。2026-04-16 に発生した孤立タスクのインシデントを教訓にしてください。
• update_automation の API は非対称です。 create_automation はトップレベルの active パラメーターを受け取りますが、update_automation では extra_input={"active": false} が必要です。既存のルールを有効／無効に切り替える場合は、active を extra_input 経由で渡してください。
• action_repo_id の意味。 パイプ間のアクション（create_connected_card、別のパイプへの create_card）では、移動元ではなく移動先のパイプを指定します。
• シミュレーションでは、実際のルールパラメーターが再利用されます。 シミュレーションの前に get_automation を呼び出して、動作するルールの event_params と action_params を取得し、そのまま渡してください。パラメーターを手作業で作成しないでください。
• field_map の fieldId にはスラッグを指定します。 事前検証により、GraphQL の実行前に数値以外の fieldId は拒否されます。due_date などのスラッグを使うと、以前は INTERNAL_SERVER_ERROR が発生していました。解決するには、get_start_form_fields／get_phase_fields を実行し、internal_id を使用してください。
• field_map の fieldId が不明です。 移動先フィールドがアクション対象のパイプにない場合、create_automation の事前検証で該当する ID が表示されて失敗します。action_repo_id のパイプで ID を再取得してください（パイプ間のアクションでは、トリガー側のパイプだけで取得しないでください）。
• ルールに update_card_field 操作を使用しました。 このツールはスラッグで指定した 1 枚のカードを更新します。オートメーションには、create_automation と数値の fieldId を指定した field_map が必要です。
• card_id がないか、正しくありません。 トリガーとなったカードを指定するには、action_params.card_id に "%{id}" を設定してください。値が空または誤っていると、意図した更新が行われません。
• field_map.value のトークンに誤りがあります。 %{…} テンプレートに誤記があると、実行時にフィールドが変更されません。オートメーションイベント属性と、get_automation から取得した動作するルールを照合してください。
• ルールは実行されるものの、フィールドが変更されません。 get_automation_logs／get_automation_logs_by_repo で実行エラーを確認してください。fieldId が無効な場合、エラーが表示されず（カードも更新されず）に失敗することがあります。

関連項目

• pipefy-building — 構築に関する依頼を振り分ける、インテント → ドメインスキルのルーターです。
• pipefy-ai-agents — 振る舞いを備えた会話型エージェントです（AI オートメーションとは異なります）。
• pipefy-observability — 実行ログと使用状況の統計情報です。
• pipefy-introspection — 生のスキーマを使ってトリガーとアクションの種類を検出します。
• pipefy-process-design — オーケストレーションのパターン（エージェント型 + 人による検証）です。
• docs/mcp/tools/identifiers.md#field-references-slug-vs-internal_id — 各ツール／引数で slug、internal_id、UUID、数値 ID のどれを使うかを示す正式な対応表です（field_address と field_map[].fieldId には internal_id が必要です）。