Makeのシナリオを別のアカウントへ渡したいとき、画面のスクリーンショットだけでは接続や設定を再現しにくくなります。ブループリントなら、モジュールと設定、マッピングをJSONファイルとして書き出し、別のシナリオへ取り込めます。
ただし、ファイルを渡せば相手の環境でもすぐ動くわけではありません。接続の再設定に加え、保存先のIDや通知先、固定入力の見直しが必要です。引き継ぎでは、構成を渡すことと、運用できる状態を確かめることを分けましょう。
ブループリントに含まれるものを知る
Make公式では、ブループリントにシナリオのモジュール、モジュール設定、マッピングされた値が含まれると説明されています。どんな順番で何を処理するかを再利用できるため、一から同じ構成を組み直す手間を減らせます。
一方、取り込んだ人は自分のアカウントで接続を作る必要があります。元の担当者が接続済みだった外部サービスへ、ファイルを取り込んだだけで同じ権限が与えられると考えないでください。シナリオの形と、外部サービスへアクセスする認証は別です。
また、接続を作り直すから機密情報が一切ないとは限りません。入力欄に直接書いたメールアドレス、文面、ファイルID、HTTPの設定などは共有前に見ます。認証情報を接続機能ではなく設定欄へ直接入れていた場合も、無条件に安全なファイルとは扱えません。
変更前の版を残して書き出す
書き出す前にシナリオを保存し、今回渡す版がどれかを決めます。作業中の画面と、引き継ぎたい内容が違わないようにしてください。ファイル名には用途と日付を付けると、後で複数の版から選ぶ際に迷いにくくなります。
シナリオビルダーのメニューからExport blueprintを選ぶと、JSONファイルとしてダウンロードできます。公式ではクリップボードへコピーする方法も案内されていますが、引き継ぎ用なら、説明メモと一緒に版を残せるファイルが扱いやすいでしょう。
共有用に設定を伏せる場合は、編集前の原本と共有用を別に保管します。置き換えた箇所には「利用者側で設定」といった説明をメモへ残してください。必要な値を無言で削ると、受け取った人が設定漏れなのか、仕様上不要なのか判断できなくなります。
取り込みは新しいシナリオで行う
インポートするときは、新しいシナリオを作ってから進めるのが基本です。公式でも、未保存の変更があるシナリオへ取り込むと、その変更が失われると注意されています。運用中の画面を開いたまま、試しに取り込む操作は避けましょう。
Import blueprintからJSONファイルを選び、保存して構成を読み込みます。取り込めたら、モジュールの数や経路、設定欄を確認します。画面に構成が出たことは、外部接続や実行結果まで正しいことを意味しません。
Make公式には取り込むブループリントのサイズ条件もあります。取り込めない場合、ファイルがJSONであることだけでなく、現行の制限に収まるかを確認します。原因を見ずにファイルの中身を大幅に削ると、必要な経路まで失う可能性があります。
接続を作り、宛先を一つずつ見直す
各外部サービスの接続を、引き継ぎ先のアカウントで設定します。同じサービスにログインできても、対象のフォルダーやデータベースへ権限があるとは限りません。接続の作成と、必要なデータへアクセスできるかの確認を分けます。
特に、スプレッドシートID、Notionの対象、通知先チャンネル、メールの宛先を見直します。構成を複製しても、固定で指定された値が元の環境を指していれば、旧担当者のデータへ書き込む原因になります。画面に表示される名前だけでなく、選んだ対象の実体を確かめてください。
Webhookやデータストアなど、シナリオに付随するものも別に確認します。どこへ入力が届き、どこへ状態を残すかを記録します。ブループリントが構成を持っていることと、過去の処理履歴や外部データがすべて移ることを混同しないようにしましょう。
実行前に固定値とマッピングを点検する
AIへ渡す指示文も見直します。元の案件名や商品情報、出力先のルールが固定文として残っていると、別案件の資料を作ることがあります。共通の説明部分と、案件ごとに変更する部分を分け、どこを直すべきかをメモにします。
接続を作り直した後は、後続のマッピングが必要な項目を参照できるか確かめます。入力元の列名やフォーム項目が違う場合、同じ構成でも空欄が渡ることがあります。設定画面にエラーがないだけでなく、実際の入力値から出力まで追ってください。
元のシナリオで使っていたテスト用の値も確認します。本番用の文面へ直したつもりでも、件名だけ旧案件のままという取り違えは起こり得ます。項目名、実際に渡る値、登録先を一件のテストで対応させると見つけやすくなります。
小さな一件を通し、実物で結果を見る
最初はテスト用のデータと出力先で一件だけ動かします。どの経路を通り、どの値がAIへ渡り、最後に何が作られたかを確認します。実行履歴が成功でも、保存先が違う、本文に旧案件が残る、二行作られるといった問題は別に見つける必要があります。
次に、空欄や条件に合わない入力を一つ試します。正常な一件だけでなく、取り込んだ側の環境で例外を受け止められるかを見ます。運用開始前に、失敗したときの連絡先や、再実行してよい条件も決めておきましょう。
自動実行の日時や頻度は最後に確認します。元と新のシナリオが両方動くと、同じ処理が二度走るかもしれません。切り替える時刻と担当者を決め、どちらが本番なのかを一覧で分かるようにしてから運用へ進みます。
ファイルと一緒に渡す説明を絞る
引き継ぎメモには、シナリオの目的、入力元、出力先、利用者側で作る接続、変更する固定値、テスト結果を残します。全設定を文章で重ねるより、「この欄は案件ごとに変える」と判断が必要な場所を示す方が役に立ちます。
確認した版と確認していない版も区別してください。原本を更新したら、以前渡したファイルが自動で更新されるわけではありません。ファイル名と更新日、変更内容を対応させることで、古い構成を再インポートする取り違えを防げます。
確認日：2026年10月16日。書き出し・取り込みと接続の扱いはMake公式 Scenario blueprintsを確認。共有前の点検と移行テストは運用上の提案です。
コメント