make-scenario-building

シナリオの作成と編集

各ツールの説明にはそのルールが記載されています。このスキルでは、操作の順序と、ツールだけでは判断できない事項を扱います。直線的なシナリオであれば、以下のワークフローだけで十分です。参照資料は、該当する条件がある場合にのみ読み込んでください。

基本ルール。 403 が発生した場合は、一部のツールだけでなく、すべての権限を含めて接続全体を再認証する必要があります。結果に含まれる content の注記は装飾ではなく、指示です。scenario_create／scenario_patch は呼び出しごとに1回保存するため、1つの変更に必要な内容はすべて1回の呼び出しにまとめてください。また、書き込みが拒否された場合は、errors を無料のドライラン結果として確認してください。曖昧な値をどう解釈したか（「Sales チャネル」「次の月曜日」など）は、それに基づいて操作する呼び出しの前に伝えてください。詳細と拒否時の動作については、何かが拒否されたときに make-scenario-reference を参照してください。

新しいシナリオを作成する

1. ユーザーが合意するよう、設計を言葉で明確にします。すべてのアプリを名前で確認し（「メール」「フォーム」「AI」などカテゴリだけが指定された場合は確認してください）、何が起動のきっかけとなり、何がどこへ移動し、条件に一致しない項目がどう扱われるかを定めます。
2. environment_get → organizationId／teamId。
3. ユーザーの言葉を使って、目的ごとに1回ずつ app_find を呼び出します。同じソースに対して即時トリガーとポーリングトリガーの両方がある場合は、どちらを選んだか、またその理由を伝えてください。
4. 予定しているすべてのモジュールについて、1回の呼び出しで module_spec を実行し、schemas: true を指定します。これにより、各モジュールの正確な config 構造と dynamic パスがわかります。
5. 接続：connection.existing にある ID を再利用します。それ以外の場合は、アプリごとに1回 connection_create を実行してリンクを渡し、ユーザーが完了したと言ったら connection_get を呼び出します。
6. dependsOn の順序に従って、dynamic パスごとに module_field_resolve を実行し、value を config にコピーします。ポーリングトリガーの開始位置は /data パスです。解決する前に「既存の項目からですか、それとも今からですか？」と確認してください。 （module_options_get は、module_spec の dynamicFields と connectionId をキーとする同じ参照です。各フィールドには、どちらか一方だけを使い、両方は使わないでください。）
7. フラットなリストを組み立てます。自分で ID を付け、root: "main" は1つだけにし、それ以外はすべて follows または parent を指定し、モジュールごとに config を1つ設定します。単純な続行／停止ゲートには filter を使います。Google Sheets、Gmail、Make AI Tools、または日付の計算が関係する場合は、まず アプリ固有の注意点 を参照してください。
8. scenario_create を実行します。依頼がない限り、autoActivate はオフにします。errors をすべて修正して再送信し、warnings を伝えてください。
9. 検証後、scenario_activate を実行します。オンデマンドの場合は、inputs を指定して scenario_run を実行します。ポーリング／スケジュールの場合は、有効化してから scenario_run、scenario_execution_get の順に実行します。Webhook の場合は、ユーザー に実際のリクエストを1回送信してもらいます。scenario_run では Webhook を実行できません。その後、https://<zone>.make.com/<teamId>/scenarios/<scenarioId> を提示します。

既存のシナリオを編集する

1. 構造と lastEdit を確認するため scenario_get を実行します。変更するモジュールについてのみ scenario_module_get を実行します。
2. モジュールを追加する場合は、上記と同様に app_find と module_spec(schemas: true) を実行し、モジュールの現在の config に対して dynamic パスを解決します。
3. expectedLastEdit と、変更に必要なすべての操作を指定して、scenario_patch を1回実行します。変更した config のドメインのみを送信してください。削除または移動したモジュールによって宙に浮いた {{<id>.field}} 参照は、同じ呼び出し内ですべて修正してください。
4. 呼び出しで追加したモジュールの ID は保存時に決まるため、そのモジュールへの接続は、返された lastEdit を使って2回目の呼び出しで行います。応答の modules エコーを確認して検証してください。

ペイロードが不明な Webhook

module_spec で payloadShape: "learned" を指定するか、単独の gateway:CustomWebHook を使用します。トリガーだけで作成 → ユーザーに実際のリクエストを1回送信してもらう（または先に scenario_trigger_learn を実行）→ scenario_trigger_inspect → 残りを scenario_patch します。フィールドを誰も確認していない Webhook シナリオは有効化しないでください。

ツールに委ねる判断

• フィルターと if-else とルーターのどれを使うか。 条件に一致しない項目を除外するだけなら → filter。条件に一致しない項目に個別のアクションが必要なら → builtin:BasicIfElse（再結合するには builtin:BasicMerge も使用）。複数の分岐がすべて実行される可能性があるなら → builtin:BasicRouter。
• 作り込みすぎないでください。 設計上必要でない限り、エラーハンドラー、アグリゲーター、変数は追加しません。

参考資料 — 該当する場合にのみ読み込む

条件	参考資料
トリガーやオンデマンド入力、バンドル全体、または配列要素のマッピングを行う場合。マッピングしたフィールドが空で返された場合	マッピング
値の変換（日付、テキスト、配列、条件分岐）が必要な場合	IML 関数
単純な直線的フローではない場合：ルーター、if-else とマージ、複数条件のフィルター、反復処理、集計	フロー制御
シナリオがオンデマンドの場合、別のシナリオを呼び出す場合、または別のシナリオやエージェントから呼び出される場合	サブシナリオ
ツールを使う Make AI Agent モジュールを配置する場合	AI エージェント
実行間で前回の状態を保持する必要がある場合（重複排除、カウンター）、またはペイロードに固定スキーマが必要な場合	データストア
ユーザーがリトライやフォールバックを求める場合、または失敗やデータ損失を許容できない場合 — ほとんどのシナリオでは不要です	エラー処理
Google Sheets、Gmail、Make AI Tools の設定を仕上げる場合、または日付式を作成する場合	アプリ固有の注意点
ひな形として使う scenario_create の完全な呼び出し例	例