make-scenario-operations

シナリオの作成 — 実行とデバッグ

シナリオの作成後に必要となるすべての操作を扱います。実行、有効化と無効化、そして失敗時の実行 → 検査 → 詳細確認の流れです。scenario_runを呼び出す前に、scenario_getでtrigger.kindを確認してください。挙動はこれによって全面的に決まります。

基本ルール。 403が返された場合は、個別のツールではなく、すべての権限を付与して接続全体を再認証する必要があります。結果に含まれるcontentの注記は飾りではなく、指示です。曖昧な値をどのように解釈したか、実行に移す呼び出しの前に伝えてください。拒否時の対応とその他の情報については、操作が拒否された場合や適切なツールが見つからない場合にmake-scenario-referenceを参照してください。

実行：scenario_run

• オンデマンド — 宣言された入力名をキーとするinputsを渡して実行し、宣言された出力を返します。
• ポーリング／スケジュール — 今すぐ1回実行します。inputsは拒否され、何も返されません。実行結果は履歴に記録されます。
• Webhook — 何も実行されません。レスポンスにはWebhook URLが返るか、アプリのイベント名が示されます。シナリオを「実行した」と報告してはいけません。ユーザーに実際のリクエストを送信してもらい、scenario_execution_listで確認してください。

無効なシナリオはscenario_activateへの案内とともに実行を拒否します。新しいシナリオは無効な状態で作成されます。"pending"ステータスは、実行が待機時間を超えたことを意味します。失敗と決めつけず、executionIdを指定してscenario_execution_getを確認してください。拒否されたinputsキーに対しては、宣言されたインターフェースを示すメッセージが返されます。もう一度推測するのではなく、その内容を確認してください。インターフェースのないシナリオに渡された入力は、黙って無視されます。その旨の注記が返されるので、ユーザーに伝えてください。

有効化と無効化

それぞれ別のツールを使います。すでに要求どおりの状態であれば、エラーではなく成功です。有効化が拒否される場合、ほとんどはモジュールに設定エラーが残っています。どのモジュールかは、scenario_getのモジュールごとのissuesで確認できます。

履歴：scenario_execution_list → scenario_execution_get

失敗した実行では、一覧にerrorMessageがそのまま含まれます。2回目の呼び出しをしなくても、「動作したか、なぜ動作しなかったか」を確認できることがよくあります。開始直後の実行は、一覧に反映されるまで数秒かかることがあります（注記に示されます。データが失われたわけではありません）。scenario_execution_getでは、1回の実行の結果、出力、消費量（クレジットとバイト数 — 金額ではなく使用量の単位）を確認できます。モジュールごとの内訳はないため、「完了したか」には答えられますが、「どのモジュールが壊れたか」には答えられません。_showの2つのツールは、ユーザーがレンダリングされたタイムラインやカードを求めている場合に限って使います。

失敗した実行のデバッグ：scenario_execution_inspect → scenario_execution_module_get

1. scenario_execution_inspect — 全体のステータスとエラーに加え、実行されたすべてのモジュールの呼び出し回数とエラー回数を確認できます。Makeでは、1回の実行につきエラーを1つ（実行を終了させたエラー）記録します。それ以外の失敗はerrorCyclesの件数としてのみ表示されます。警告ステータスの実行には、トップレベルのerrorがありません。唯一の手がかりはmodules[].errorsです。そのため、「エラーは見つかりませんでした」と「問題はありませんでした」を同じ意味で報告してはいけません。
2. scenario_execution_module_get — 問題が疑われるモジュールと、inspectが報告したcycle（通常は1）を指定します。そのモジュールが実際に受け取った入力と出力を確認できます。サイクルを独自に選んではいけません。誤ったサイクルを指定すると、警告なしに無関係なデータが返されます。
3. 現在のconfigをscenario_module_getで照合します。ただし、まずscenario_getのlastEditと実行のstartedAtを比較してください。実行後にシナリオが編集されている場合、確認した設定が実行時の設定とは限りません。バグの原因を特定する前に、その旨を伝えてください。

…[truncated]は、ペイロードが切り詰められていることを示します。これはテキストであり、解析するJSONではありません。下流のコンシューマー（ReturnData、WebhookRespond、throw）がないモジュールは、正常な場合でもここでは常に空の出力を報告します。シナリオ自体の出力はscenario_execution_getのoutputsにあります。

「データを受信していない」Webhook

• まず scenario_trigger_inspect を使います。シナリオが非アクティブ、一時停止中、またはレート制限中のため、リクエストが保存されて待機している queued 配信を報告します。queued.count がゼロ以外であれば、「データを送ったのに何も起きない」という問題の原因は、マッピングの不具合ではなく、たいていこれです。また、検出された構造と最近の配信も表示され、deliveryId を指定すると未加工のリクエストを確認できます。
• scenario_trigger_learn を使うと、Webhook が学習モードになります。次のリクエストがシナリオを実行せずに構造として取り込まれます（アクティブなシナリオでも安全です）。ユーザーに URL を渡し、実際のリクエストを 1 件送信してもらいます。

保留されたペイロード（機密性の高い Webhook や共有 Webhook、1 MB を超える本文、バイナリ）はプレースホルダーに置き換えられ、その旨が注記に説明されます。「何も届かなかった」わけではありません。

ここでは扱わない内容

• 見つかった問題を修正するためのシナリオ編集 — make-scenario-building。
• シナリオを実行せずに説明する方法 — make-scenario-explore。