automation-flow-generate

目標

必要な3ステップのMCPパイプライン（fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration）を実行してSalesforce Flowのメタデータを生成し、フローXMLを返します。

このスキルを使用するタイミング

次のことが必要な場合にこのスキルを使用します。

• あらゆる種類のFlow（Screen、Autolaunched、Record-Triggered、Scheduled）を作成する
• FlowメタデータXMLを生成する
• コードを使わずにビジネスプロセスを自動化する
• ユーザーガイド型ワークフローやバックグラウンド自動化を構築する
• Flowに関連するデプロイエラーをトラブルシューティングする

仕様

Flowメタデータ仕様

概要

Salesforce Flowは、コードを使わずに複雑なビジネスプロセスを自動化できる強力な自動化ツールです。Flowでは、インタラクティブな画面を通じたデータの収集と処理、ロジックや計算の実行、レコードの操作、外部サービスの呼び出し、さまざまなイベントを契機とした処理の実行ができます。Flowの種類には、Screen Flow（ユーザーガイド型）、Autolaunched Flow（バックグラウンド処理）、Record-Triggered Flow（データベースイベント）およびScheduled Flow（時間ベース）があります。

Flow生成パイプライン

必須：必ずこの正確な3ステップのパイプラインに従ってください。例外、近道、ステップの省略は認められません。FlowメタデータXMLを手動で作成したり、このパイプライン以外の方法でFlowメタデータを生成したりしないでください。Flowメタデータの生成に、ほかのツール、API、方法を使用しないでください。Flowを生成するためにサポートされている方法は、このパイプラインのみです。手順を逸脱すると、メタデータが無効になったり、破損したりします。

MCP接続の詳細

パイプラインの3ステップすべてで、必ずこのMCPツールを呼び出してください。

• MCPツール名： execute_metadata_action
• actionパラメーターで実行するパイプラインのステップを選択します。"fetchGroundedObjectMetadata"、"flowElementSelection"、"flowElementGeneration"のいずれかを指定します。

Flowの生成は、厳密な3ステップのパイプラインです。すべてのステップを順番どおりに呼び出す必要があります。すべてのステップが必須です。別の方法はありません。Flowメタデータを生成する唯一の方法です。

ステップ1（必須）：根拠となるオブジェクトメタデータの取得（fetchGroundedObjectMetadata）

Flow生成リクエストに関連する組織のスキーマメタデータを取得します。このステップは必須であり、必ず最初に呼び出す必要があります。

入力（すべて必須）：

• userPrompt（STRING、必須）：ユーザーの自然言語によるリクエスト
• inflightMetadata（ARRAY、必須）：ローカルのsfdxプロジェクトにあるカスタムオブジェクト／項目。不要な場合は空の配列[]を使用します。

出力：

• groundingMetadata（STRING）：リクエストに関連する組織のスキーマの根拠メタデータ。JSON文字列として返されます。これはすでに文字列なので、そのままステップ2に渡してください。再度シリアライズする必要はありません。

ステップ2（必須）：Flow要素の選択（flowElementSelection）

ユーザーのプロンプトと根拠メタデータに基づいて、Flow要素（割り当て、決定、レコード操作など）とその接続を選択します。このステップは必須であり、ステップ1の後に呼び出す必要があります。

入力（すべて必須）：

• userPrompt（STRING、必須）：ユーザーの自然言語によるリクエスト（ステップ1と同じ値でなければなりません）
• groundingMetadata（STRING、必須）：組織のスキーマメタデータ（ステップ1の出力で返された文字列と完全に同じものを指定してください。そのまま渡し、再度シリアライズしないでください）
• operationId（STRING、必須）：操作ID（初回の呼び出しでは空の文字列""を使用します）

出力：

• operationId（STRING）：操作ID。これをステップ3に渡してください。
• userOutput（STRING）：次のステップに向けた推論。ユーザーに表示できます。

ステップ 3（必須）：フロー要素の生成（flowElementGeneration）

フローのメタデータを要素ごとに生成します。このステップは必須であり、ステップ 2 の後に呼び出す必要があります。isComplete が true になるまで、ループで繰り返し呼び出してください。

入力（すべて必須）：

• operationId（STRING、必須）：ステップ 2 の出力に含まれる操作 ID
• requestSource（STRING、必須）：リクエストのソース。XML 形式でフローのメタデータを取得するには、"A4V" を使用します。

出力：

• isComplete（BOOLEAN）：フローの生成が完了したかどうかを示します。この値を必ず確認してください。
• result（STRING）：フロー要素の生成結果。isComplete が true の場合にのみ、最終的なフローのメタデータが含まれます。

必須：完了するまでループしてください。続行の確認をユーザーに求めたり、決して一時停止したりしないでください。

• フローには任意の数の要素を含めることができます。各呼び出しでは一度に 1 つの要素を生成するため、多数の反復が必要になる場合があります。
• ステップ 2 の operationId と requestSource を指定して flowElementGeneration を呼び出します（XML 出力には "A4V" を使用し、JSON 出力には空文字列またはその他の値を使用します）。
• 各呼び出しの後に、isComplete の出力と result フィールドを確認します。
• isComplete が false で、エラーが返されなかった場合は、ステップ 2 と同じ operationId を指定して flowElementGeneration を必ずもう一度呼び出してください。続行するかどうかをユーザーに尋ねてはいけません。ループを一時停止してはいけません。ループの途中で進捗を要約してはいけません。呼び出しを続けてください。反復回数に上限はありません。
• isComplete が true になったら、result フィールドからフローのメタデータを抽出します。
• エラーが返された場合は、ループを停止し、エラーをユーザーに伝えます。

厳格な制約（重要）—以下のルールは、生成パイプラインから返される XML に適用されます。

• いずれのブロック内のコンテンツ、値、子ノードも変更しないでください。
• ノード、タグ、属性、テキストを追加しないでください（不足しているラベルや X/Y 座標などを追加しないでください）。
• 既存のノードを削除しないでください。

キャンバスモード。 新規作成するキャンバスベースのフローには、<processMetadataValues> の CanvasMode=AUTO_LAYOUT_CANVAS エントリが必要です（BuilderType とは無関係）。これがない場合、Free-Form で開きます。厳格な制約により XML の手編集は禁止されているため、この設定は生成パイプラインから取得する必要があります。返された XML に含まれていない場合は、パイプラインの不足として伝えてください。XML を手編集してはいけません（CustomerLifecycle などのキャンバス以外のタイプには含まれません。これらは問題として指摘しないでください）。

inflightMetadata の形式

データ型：配列（文字列ではありません）

厳格な命名規則 — 必ず正確に従ってください：

プロパティ	正しい名前	使用禁止
オブジェクト API 名	apiName	objectApiName、name、objectName
フィールド API 名	apiName	fieldApiName、name、fieldName
フィールド型	type	fieldType、dataType
参照先	referenceTo	relatedTo、lookupTo、reference

カスタムオブジェクトが必要な場合（複数のフィールドデータ型を示すサンプル形式）：

[
  {
    "type": "CustomObject",
    "apiName": "CustomerRequest__c",
    "label": "Customer Request",
    "fields": [
      {
        "apiName": "Status__c",
        "type": "Picklist",
        "label": "Status",
        "values": ["New", "In Progress", "Completed"]
      },
      {
        "apiName": "Priority__c",
        "type": "Number",
        "label": "Priority"
      },
      {
        "apiName": "AssignedTo__c",
        "type": "Lookup",
        "label": "Assigned To",
        "referenceTo": "User"
      },
      {
        "apiName": "Description__c",
        "type": "Textarea",
        "label": "Description"
      },
      {
        "apiName": "Email__c",
        "type": "Email",
        "label": "Contact Email"
      },
      {
        "apiName": "DueDate__c",
        "type": "Date",
        "label": "Due Date"
      },
      {
        "apiName": "IsUrgent__c",
        "type": "Boolean",
        "label": "Is Urgent"
      },
      {
        "apiName": "Amount__c",
        "type": "Currency",
        "label": "Amount"
      }
    ],
    "relationships": []
  }
]

サポートされているフィールド型：Text、Textarea、Number、Picklist、Lookup、Email、Phone、URL、Date、Datetime、Boolean、Checkbox、Currency、Percent

カスタムオブジェクトが不要な場合：

[]

inflightMetadata の必須判断ロジック（データ型：配列）

1. 必須 - 最初に実行：ローカルの sfdx プロジェクトをスキャンし、ユーザーのフローリクエストに関連するカスタムオブジェクトと項目を確認します。
2. 関連するカスタムオブジェクトが見つかった場合：構造化オブジェクトの配列として抽出し、渡す必要があります（形式は上記を参照）。
3. 関連するカスタムオブジェクトが見つからない場合：空の配列 [] を渡す必要があります（文字列 "[]" ではありません）。
4. 禁止：inflightMetadata にテキストの説明、指示、文字列表現を渡してはいけません。
5. 必須：データ型は文字列ではなく配列でなければなりません。

カスタムオブジェクトが関連する場合の Vibes への指示：

• オブジェクトのメタデータを抽出し、JSON プロパティにマッピングします。
  • apiName：オブジェクトの API 名（カスタムオブジェクトの場合は __c サフィックス付き）
  • label：オブジェクトの表示ラベル
  • type："CustomObject" に設定
  • fields：項目オブジェクトの配列。それぞれに次の内容を含めます。
    • apiName：項目の API 名（カスタム項目の場合は __c サフィックス付き）
    • type：項目の型（Text、Number、Picklist、Lookup など）
    • label：項目の表示ラベル
    • values：（Picklist の場合のみ）選択リスト値の配列
    • referenceTo：（Lookup の場合のみ）参照先オブジェクトの API 名
• 生成するフローに関連するオブジェクトと項目のみを含めます。

必須の拡張ルール

• userPrompt：必須です。
  • ユーザーが単一のフローをリクエストした場合：ユーザーのプロンプトをそのまま使用します。
  • ユーザーが複数のフローをリクエストした場合：リクエストを分割し、個々のフローごとに焦点を絞った個別の userPrompt を作成する必要があります。各 userPrompt は 1 つのフローのみを説明する必要があります。複数のフローに関するリクエスト全体を 1 つの userPrompt として渡してはいけません。例については、以下の複数フローのセクションを参照してください。
• inflightMetadata：必須です。常に配列データ型を使用します。
  • カスタムオブジェクトが不要な場合は、必ず []（空の配列）を使用します。
  • カスタムオブジェクトが関連する場合は、必ず構造化オブジェクトの配列を使用します。
  • 文字列 "[]" は絶対に使用しないでください。これは誤りです。
  • テキストの説明は絶対に使用せず、構造化されたオブジェクトのメタデータのみを使用します。

フローパターンのガイダンス

パイプラインは userPrompt からフロー要素を選択します。曖昧なプロンプトでは、パイプラインが誤った構造を選択し、デプロイに失敗するメタデータを生成することがあります。リクエストが以下のパターンに該当する場合は、パイプラインが適切な要素を選択できるように、Step 1 と Step 2 に渡す userPrompt で意図を明確にします。

スケジュール済みフロー（「毎日」、「毎週」、「毎週日曜日」、「毎週 1 回、午後 10 時に実行」）

繰り返し実行される時間ベースのフローは、スケジュール済みフローです。スケジュールは開始要素に定義します。triggerType は Scheduled で、<schedule> ブロックに <frequency>（例：Weekly）、<startDate>、<startTime> を含めます。FlowScheduledPath 要素に startDate／startTime が設定されることを想定してはいけません。スケジュール済みフローの実行間隔はスケジュール済みパスではなく、<start><schedule> に設定します。

スケジュール済みフローでレコードを選択するには、レコード条件を開始要素のフィルター（<start> の <object> と <filters>）に指定します。条件に一致するレコードごとにフローが 1 回実行され、それぞれに $Record がバインドされます。同じオブジェクトを再クエリして反復する Loop を追加するより、こちらを優先してください。開始要素でフィルターを指定したスケジュール済みフローでは、トリガー対象オブジェクトのレコードを走査する Loop は不要です。

プロンプトに「毎週 1 回／毎週日曜日／毎日、特定の時刻に実行」とある場合は、userPrompt で、スケジュール済みトリガー、頻度、開始時刻、トリガー対象オブジェクトのレコードフィルターを明記する必要があります。

「Autolaunched」は文字どおりに解釈します

「autolaunched」／「トリガーなし」のリクエストでは、トリガーなしフローを作成します（開始要素に triggerType、object、<schedule> を指定しません）。「各…に対して」／「X のとき」やタイミングに関する意図は、トリガーではなく本文に記述します。依頼があった場合にのみ、トリガーを追加します。

関連レコードの件数を数える（「関連するすべてのXを数える」「Xの数」）

レコードの件数を保存するには、<operator>AssignCount</operator>を指定した単一の割り当て要素を使い、コレクション（レコード検索の結果）からNumber変数に割り当てます。1つの件数に対して割り当て要素を2つ出力してはいけません。また、2つの割り当て要素に同じnameを指定してはいけません。割り当て名の重複、または1つの論理的な件数カウントに対する割り当てが2つある場合、デプロイに失敗します。1つの検索 → 1つのAssignCount割り当て → 1つのレコード更新です。

プロンプトで要求されていないアクションを作り出さない

プロンプトで要求された要素のみを生成してください。プロンプトでトリガーは指定されていても、アクションが指定されていない場合（例：「レコードが作成されたときのフローを作成する」とだけあり、動作が記載されていない場合）、Chatterへの投稿、メール、その他の要求されていないアクションを追加してはいけません。chatterPostのような要求されていないアクションは、未定義の型を参照するメタデータを生成し、デプロイに失敗します。要求された動作が実際に記載されていない場合は、副作用を作り出さず、最小限の有効なトリガーを生成してください。

必須：複数のフローは個別のパイプラインに分ける

最初に：パイプラインのステップを呼び出す前に、ユーザーのリクエストに複数のフローが含まれているか確認してください。含まれている場合は、必ず個別の単一フローのプロンプトに分割してください。各フローには、そのフローのみを説明する独自のuserPromptを使った、専用の3ステップパイプラインが必要です。

複数のフローを含むリクエストを、単一のuserPromptフィールドに渡してはいけません。複数のフローの説明を1つのuserPromptにまとめてはいけません。

ユーザーが複数のフローをリクエストした場合（例：「アプリ用のフローを作成してください：1）... 2）... 3）...」）、必ず次の手順を実行してください。

1. リクエストを個々のフローの説明に分割します。
2. それぞれのフローのみを説明するuserPromptを使い、フローごとに個別の3ステップパイプラインを実行します。
3. すべてのパイプラインを順番に実行します。並列実行してはいけません。最初のフローだけで止めてはいけません。ユーザーが続行を求めるのを待ってはいけません。要約して終了してはいけません。リクエストされたすべてのフローが完全に生成されるまで続けてください。

誤り - 複数のフローを1つのuserPromptにまとめる：

{
  "userPrompt": "Create flows for the app: 1) Record-Triggered Flow on ResourceAllocation__c to update Resource__c. 2) Screen Flow to allocate resources. 3) Record-Triggered Flow on Supply__c to auto-flag Low_Stock__c.",
  ...
}

正しい - フローごとに個別の呼び出しを行う：

フロー1 - ステップ1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "Create a Screen Flow named Tenant_Onboarding that captures tenant details, selects a Unit__c with Status__c = 'Vacant', creates Lease__c...",
  "inflightMetadata": [...]
}

続いて、ステップ1のgroundingMetadataを使ってステップ2（flowElementSelection）を呼び出し、その後、ステップ2のoperationIdを使ってステップ3（flowElementGeneration）を呼び出します。

フロー2 - ステップ1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "Create an Autolaunched Flow named Generate_Onboarding_Checklist that given a Lease__c Id input, queries OnboardingTask__c...",
  "inflightMetadata": [...]
}

続いて、このフローのステップ2とステップ3を呼び出します。

フロー3 - ステップ1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "Create a Record-Triggered Flow named Sync_Unit_On_Lease_Changes that on insert and update of Lease__c...",
  "inflightMetadata": [...]
}

続いて、このフローのステップ2とステップ3を呼び出します。

必須ルール：

• 生成するフローがN個ある場合、個別の3ステップパイプラインをN個実行しなければなりません。例外はありません。フローを1つだけ生成して終了してはいけません。
• 次のフローのパイプラインを開始する前に、現在のフローの3ステップパイプラインを完全に完了しなければなりません（isCompleteがtrueになるまで、またはエラーが返されるまでステップ3をループすることも含みます）。フロー間のパイプラインを交互に進めたり、並列化したりしてはいけません。すべて順番に実行してください。並列実行は禁止です。
• フローのパイプラインが完了したら、ただちに次のフローのパイプラインを開始してください。フロー間で中断したり、要約したり、ユーザーの確認を待ったりしてはいけません。
• 各フローについて、ローカルのsfdxプロジェクトをスキャンし、そのフローのプロンプトに固有のカスタムオブジェクト／フィールドを使ってinflightMetadataを設定してください。
• 各フローのパイプラインには、そのフローに関連するオブジェクト／フィールドのみを含む、独自のinflightMetadataを指定してください。

ツール呼び出しの例

例 1：標準オブジェクトのみ（カスタムオブジェクトなし）

ステップ 1 - fetchGroundedObjectMetadata：

{
  "userPrompt": "Create a scheduled-triggered Flow named Daily_Good_Morning that runs daily at 6:00 AM and sends an email to the running user saying good morning.",
  "inflightMetadata": []
}

ステップ 2 - flowElementSelection：

{
  "userPrompt": "Create a scheduled-triggered Flow named Daily_Good_Morning that runs daily at 6:00 AM and sends an email to the running user saying good morning.",
  "groundingMetadata": "<groundingMetadata string from Step 1 — pass directly, do not serialize again>",
  "operationId": ""
}

ステップ 3 - flowElementGeneration（ループで呼び出す）：

{
  "operationId": "<operationId from Step 2>",
  "requestSource": "A4V"
}

ステップ 3 と同様に、operationId は同じ値、requestSource: "A4V" として、isComplete が true になるかエラーが返されるまでループします。その後、result から XML を抽出します。

例 2：ローカルの sfdx プロジェクトにあるカスタムオブジェクトを使用

ステップ 1 - fetchGroundedObjectMetadata：

{
  "userPrompt": "Create a flow that updates the status of a Customer Request when it's assigned",
  "inflightMetadata": [
    {
      "type": "CustomObject",
      "apiName": "CustomerRequest__c",
      "label": "Customer Request",
      "fields": [
        {
          "apiName": "Status__c",
          "type": "Picklist",
          "label": "Status",
          "values": ["New", "In Progress", "Completed"]
        },
        {
          "apiName": "AssignedTo__c",
          "type": "Lookup",
          "label": "Assigned To",
          "referenceTo": "User"
        }
      ],
      "relationships": []
    }
  ]
}

ステップ 2 - flowElementSelection：

{
  "userPrompt": "Create a flow that updates the status of a Customer Request when it's assigned",
  "groundingMetadata": "<groundingMetadata string from Step 1 — pass directly, do not serialize again>",
  "operationId": ""
}

ステップ 3 - flowElementGeneration（ループで呼び出す）：

{
  "operationId": "<operationId from Step 2>",
  "requestSource": "A4V"
}

例 1 のステップ 3 とまったく同様にループします。

重要な確認チェックリスト（すべてのフロー生成の前後に必ず確認）

このチェックリストに従わないと、フローメタデータが破損または欠落します。

• パイプライン：3 つのステップすべてを厳密な順序（fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration）で呼び出します。ステップを省略、統合したり、別のツール／API に置き換えたりしてはいけません。このパイプラインがフローメタデータを生成する唯一の方法です。
• メタデータを手動で作成しない：フローメタデータをパイプラインの外部で作成、変更、生成してはいけません。また、返された XML に要素／属性（<label>、<description>、その他のノードなど）を追加してはいけません。最終的な XML はパイプラインから返されたものと同一でなければなりません。**例外：**ユーザーが、すでに生成された XML の検証／デプロイエラーの修正を明示的に依頼した場合は、対象を絞った手動編集が許可されます。
• userPrompt には単一のフロープロンプトを含めます（複数フローのリクエストは分割し、それぞれに userPrompt を 1 つ指定します）。フロー要件を含め（inflightMetadata は含めません）、ステップ 1 とステップ 2 に同一の内容を渡します。
• inflightMetadata は ARRAY データ型（文字列 "[]" ではありません）にします。カスタムオブジェクトが不要な場合は [] とし、必要な場合はローカルの sfdx プロジェクトからスキャンした構造化オブジェクト／フィールドメタデータを格納します。テキストによる説明は決して格納しません。
• groundingMetadata：ステップ 1 の出力から取得した groundingMetadata を、そのままステップ 2 の入力に渡します（すでに文字列なので、再度シリアライズしてはいけません）。
• ステップ 3：ステップ 2 と同じ operationId を使い、常に requestSource を "A4V" として、isComplete が true になるかエラーが返されるまでループで呼び出します。反復回数にかかわらず、途中で止めたり、ユーザーに続行を求めたりしてはいけません。isComplete が true の場合に限り、result から XML を抽出します。
• 複数フロー：次のフローを開始する前に、各フローのパイプライン全体を順次（並列や交互に実行せず）完了させます。依頼されたフローはすべて生成し、最初のフローの後で止めてはいけません。
• キャンバスモード（読み取り専用）：キャンバスベースの新規フローの XML には、<processMetadataValues> の CanvasMode=AUTO_LAYOUT_CANVAS エントリが含まれます。存在しない場合は、パイプラインの不備として報告し、手動で編集してはいけません（厳格な制約により禁止されています）。CustomerLifecycle などのキャンバス以外のタイプには含まれないため、その場合は指摘しないでください。