自動化の担当交代｜接続アカウント・権限・未処理の引き継ぎ

退任日より先に動いている仕事を調べる

例として、外注担当が作った五つの自動化を社内へ引き継ぐ場面を考えます。問い合わせ登録、注文通知、日次集計などを一つずつ並べ、入口、実行予定、出力、業務担当者、最後の完了時点を記録します。フロー一覧だけでは、外部アプリから呼ばれるWebhookや古い埋め込みが抜ける場合があります。対象外の試作と本番を分け、止まると困る仕事から確認してください。退任後に「使われていた」と分かる状態を避けるため、請求先と失敗通知の宛先も同じ棚卸しへ含めます。

引き継ぎ後の最初の定期実行も、次の担当者が結果を確認する日として予定に入れます。

所有者と接続先の本人を区別する

自動化サービスのオーナーを変えても、外部アプリへの接続が退任者個人のまま残る場合があります。契約管理者、フローを直す人、接続した外部アカウントを別々に記録してください。業務用IDやサービスアカウントを使えるかは接続先の規約と機能で確認し、使えない場合は正式な共有・移管方法を調べます。Zapierの接続所有者の移管にも対象のチーム条件があります。個人のパスワードを渡せば済むとは考えず、次の担当者が必要な権限で再承認できる手順を用意します。

設定書き出しを秘密情報の共有にしない

MakeのBlueprintには設定や項目対応が入り、取り込み後には接続を作る必要があります。n8nのJSONには接続の名前やID、cURL由来の認証ヘッダーが含まれる場合があるため、共有前に点検します。設定の保存、秘密情報の管理、業務データの保管は別の仕事です。手順書には接続の用途、必要な権限、更新・失効の担当を書き、秘密値や確認コードを貼りません。自己ホストのn8nでは暗号鍵も復旧に関わるため、安全な保管先と利用できる担当者を決め、文書と一緒に公開しないようにします。

次の担当者が例外を一件処理する

次の担当者へ、通知だけが失敗した試験用の一件を渡します。登録済みか、未処理はどこか、何を再実行してよいかを自分で確認してもらってください。作成者が横で操作を説明するだけでは、引き継ぎ後も判断できる証拠になりません。必要な履歴、保存量、閲覧権限が対象プランへ含まれるかも確かめます。実際の顧客への送信や請求を使わず、試験用の接続と資料で手順を確認します。作成者しか解決できない段階が残るなら、保守依頼の範囲か設計の修正を決めます。

未処理と契約の切り替え時刻を決める

退任日に受付を止めるのか、止めずに接続だけ替えるのかを業務条件から決めます。受付ID、最後に完了した期間、保留中の記録を保存し、新旧の処理が同じ注文を書かないようにします。再承認で一時停止する場合は手作業の窓口も用意してください。請求管理者とカードの変更は、フロー編集権限とは別に確認します。年払いを引き継ぐなら、更新日、含まれる枠、追加購入の設定を残します。特にMake Coreでは年払いでも毎月の枠がリセットされるため、契約更新と利用量の周期を混同しないことが必要です。

失効は確認後に対象を絞って行う

必要な結果と次の担当者の作業を確認してから、退任者の権限、使わなくなった接続、Webhook、外部サービスを対象ごとに整理します。すべてのアカウントを一律に消す前に、他の業務が同じ接続を使っていないか確認してください。Pipedreamを使っている場合はWorkflowsの終了対象と継続するConnectも区別します。移行済みの記録、残る対応、請求の確認日を残し、一定期間後に不要な保存資料を見直します。引き継ぎの完了条件は、秘密値を受け取ったことではなく、必要な業務と復旧を適切な権限で続けられることです。

• 制作会社からWebサイトを引き継ぐ｜契約・編集・復旧の確認表
• Webhook自動化の選び方｜重複・順序・再実行をどう扱うか