generating-flow

目標

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

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

以下が必要な場合に、このスキルを使用します。

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

仕様

Flow メタデータ仕様

概要

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

目的

• 宣言型ロジックと分岐を使って複雑なビジネスプロセスを自動化する
• 画面 Flow を使って、複数ステップにわたるデータ収集や決定ワークフローをユーザーに案内する
• Salesforce レコードに対する CRUD 操作を自動的に実行する
• 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 の場合にのみ、最終的なフローメタデータが含まれます。

必須：完了するまでループします。絶対に一時停止したり、続行するかユーザーに確認したりしないでください。

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

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

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

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 の必須の決定ロジック（データ型: ARRAY）

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

カスタムオブジェクトが関連する場合の 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 は ONE つのフローのみを記述しなければなりません。複数フローのリクエスト全体を単一の userPrompt として渡さないでください。例については、以下の複数フローのセクションを参照してください。
• inflightMetadata: 必須です。常に ARRAY データ型を使用します。
  • カスタムオブジェクトが不要な場合は []（空の配列）を使用しなければなりません
  • カスタムオブジェクトが関連する場合は構造化オブジェクトの配列を使用しなければなりません
  • 文字列 "[]" は使用しないでください - これは不正です
  • テキストの説明は使用しないでください - 構造化オブジェクトのメタデータのみです

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

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

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

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

1. リクエストを個別のフローの説明に分割します。
2. 各フローについて、そのフローだけを記述するuserPromptを使用して、個別の3ステップのパイプラインを実行します。
3. すべてのパイプラインを順次実行します。1つずつ実行し、並列実行は絶対にしないでください。最初のフローが終わった時点で停止しないでください。ユーザーに続行を求められるまで待たないでください。要約して停止しないでください。リクエストされたすべてのフローが完全に生成されるまで続けてください。

誤り — 複数のフローを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個用意し、そのN個すべてを実行しなければなりません。例外はありません。1つのフローだけを生成して停止してはいけません。
• 次のフローのパイプラインを開始する前に、現在のフローの3ステップのパイプラインを完了してください（isCompleteがtrueになるまで、またはエラーが返されるまでステップ3を繰り返すことを含みます）。 フローごとのパイプラインを交互に実行したり、並列化したりしてはいけません。すべて順次実行し、並列実行は絶対にしないでください。
• 1つのフローのパイプラインが完了したら、直ちに次のフローのパイプラインを開始してください。フロー間で中断したり、要約したり、ユーザーの確認を待ったりしてはいけません。
• 各フローについて、ローカルの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"
}

isCompleteがtrueになるか、エラーが返されるまで、同じoperationIdで繰り返し呼び出します。フローに含まれる要素の数に制限はないため、複数回の反復が想定されます。isCompleteがtrueになったら、resultフィールドからフローのメタデータを抽出します。フローのメタデータをXML形式で取得するには、"requestSource": "A4V"を使用します。

例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"
}

isCompleteがtrueになるか、エラーが返されるまで、同じoperationIdで繰り返し呼び出します。フローに含まれる要素の数に制限はないため、複数回の反復が想定されます。isCompleteがtrueになったら、resultフィールドからフローのメタデータを抽出します。フローのメタデータをXML形式で取得するには、"requestSource": "A4V"を使用します。

必須のベストプラクティス

• 必ず次の3ステップのパイプラインに従ってください：fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration。フローメタデータを生成する方法はこれだけです。ほかに方法はありません。
• このパイプライン以外で、フローメタデータのXML、JSON、その他の形式を手動で作成しないでください。
• ユーザーが、生成済みのフローXMLにおける検証エラーまたはデプロイエラーの修正を明示的に依頼した場合は、そのエラーを解決するために、XMLを対象を絞って手動編集してもかまいません。これは「メタデータを手動で作成しない」というルールの唯一の例外です。
• ステップを省略したり、組み合わせたりして「最適化」しないでください。各ステップは独立しており、必須です。
• パイプラインのステップを絶対に省略しないでください。3つのステップすべてが必要です。
• 3つのステップすべてを呼び出さずに、フローメタデータを生成しようと絶対にしないでください。
• フローの構造を把握していると思っていても、いかなる状況でもこのパイプラインから絶対に逸脱しないでください。
• 単一フローのリクエストでは、ユーザープロンプトを userPrompt として使用する必要があります。
• 複数フローのリクエストでは、フローごとに3ステップのパイプラインを個別に順次（1つずつ、並列ではなく）実行し、すべてを完了させる必要があります。最初のフローの後で止めないでください。
• フローの要件は inflightMetadata ではなく、userPrompt に指定する必要があります。
• inflightMetadata はローカルプロジェクトのカスタムオブジェクト／フィールドのメタデータにのみ使用します（上記を参照）。例外はありません。
• ステップ3は、ステップ2と同じ operationId を使用して、isComplete が true になるか、エラーが返されるまでループ内で呼び出す必要があります。フローには任意の数の要素を含められます。何回繰り返す必要があっても、途中で止めたり、続行するかどうかをユーザーに尋ねたりしないでください。
• isComplete が true の場合にのみ、result フィールドからフローメタデータを抽出してください。

重大な検証チェックリスト（フローを生成する前後に必ず確認してください）

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

• パイプライン：3 つのステップすべてを厳密な順序で呼び出します（fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration）。ステップを省略しません。
• メタデータの手動作成禁止：このパイプライン以外の方法で、フローのメタデータを手動で作成、変更、生成しません。
• 逸脱禁止：このパイプラインの代わりに、またはこのパイプラインと併用して、別のツール、API、方法を使用しません。
• userPrompt にはフローのプロンプトを 1 つだけ 含めます。ユーザーが複数のフローをリクエストした場合は、リクエストを分割し、各パイプラインに 1 つのフローのみを説明する個別の userPrompt を渡します。
• userPrompt はステップ 1 とステップ 2 の両方に一貫して渡します（同じ値）。
• inflightMetadata のデータ型は配列です（文字列ではありません）。
• カスタムオブジェクトが不要な場合、inflightMetadata は [] です。
• inflightMetadata には、ローカルの sfdx プロジェクトをスキャンして抽出した、関連するカスタムオブジェクト／フィールドの構造化オブジェクトが含まれます。
• inflightMetadata に "[]"（文字列）を含めません。[]（配列）でなければなりません。
• inflightMetadata にテキストの説明や指示を含めません。
• ステップ 1 の出力に含まれる groundingMetadata を、ステップ 2 の入力に直接渡します（すでに文字列なので、再度シリアライズしないでください）。
• ステップ 2 の出力に含まれる operationId を、ステップ 3 の入力に渡します。
• requestSource は常に "A4V" に設定します。
• ステップ 3 は、ステップ 2 と同じ operationId を使って、isComplete が true になるかエラーが返されるまでループ内で呼び出します。反復回数にかかわらず、一時停止したり、ユーザーに続行を尋ねたりしないでください。
• 複数のフロー：次のフローのパイプラインを開始する前に、各フローのパイプラインを最後まで完了します（交互に処理しません）。
• result フィールドからフローの XML メタデータを抽出するのは、isComplete が true の場合のみです。
• XML への追加禁止：元のパイプライン出力に存在しない要素、属性、プロパティを追加していません。<label>、<description>、その他のノードを挿入していません。最終的な XML はパイプラインが返したものと同一でなければなりません。
• エラー修正の例外：ユーザーが検証／デプロイエラーの修正を明示的にリクエストした場合、対象を絞った XML の手動編集が許可されます。その編集には「XML への追加禁止」および「メタデータの手動作成禁止」の制約は適用されません。