自動化の権限を引き継ぐ：接続先・管理者・停止方法の台帳

接続で必要な操作を先に書く

「Googleと連携する」という説明だけでは範囲が分かりません。どのファイルを読み、どの一覧へ追加し、何を送信するのかを分けます。利用する業務で必要な操作と、接続画面が求める権限を照らし合わせてください。

Make公式のOAuth接続ガイドは、必要なスコープを接続先APIの資料で確認する考え方を説明しています。そこで示される特定サービスの設定値を、別サービスにもそのまま使えるとは考えません。

作成者と、止める人を台帳に残す

運用の台帳にはパスワードを書かず、接続名、管理者、対象、停止方法の場所を記録します。共通のパスワードを全員へ配ることを、引継ぎの代わりにしないでください。組織のアカウント管理方針に沿って担当を決めます。

閲覧・編集・送信をまとめて許可しない

確認用一覧を読むだけの処理と、顧客へメールを送る処理では影響が異なります。読み取り試験の段階で送信までつながない構成にすると、何を承認する必要があるかも整理しやすくなります。

実際に細かな権限を分けられるかは、サービスや接続方式によって異なります。希望の範囲へ絞れない場合は、その権限を許可できる業務か、標準機能や手作業へ戻すかを判断します。

実行ログにも入力情報が残り得る

Make公式「Scenario settings」では、実行ログに処理データが保存されることと、Keep data confidentialで内容を保持しない設定が説明されています。ただし内容を残さない設定では、エラー調査の手段が限られます。

秘密情報を扱うからすべて記録する、調査が必要だからすべて残す、と一律には決めません。受付IDや判定結果だけで追える記録を設計し、ログを見る人、保存の必要期間、削除方法を確認します。

担当者の交代を、小さな試験で確認する

Google公式「Apps Scriptの承認」は、実行方法で動作するユーザーが変わることを説明しています。Make以外の仕組みでも、ファイルを共有しただけで実行権限まで引き継がれたとは判断できません。

• 旧担当の接続を使う処理を一覧から探す
• 新担当が対象ファイルを開けるか確認する
• 架空入力で読み取りと確認用出力を試す
• 旧担当の権限を外した後の動作を確認する

権限を変えた日は、業務の結果も確認する

接続を作り直す、共有範囲を狭める、担当アカウントを変更する日は、変更前後の処理件数と保留件数を確認します。画面の接続成功だけで、正しい保存先へ書けることまで確かめたとしないでください。

確認用データが正しい場所へ届き、不要な対象へは届かず、代行者が停止できる。この三点を引継ぎの完了条件にします。権限台帳は一度作って終わりにせず、接続先や担当を変える時に更新しましょう。

ここまで確認できたら、次へ

• 接続の管理者と代行者を記録したか
• 必要な権限に対応するか
• 対象外への送信がないか
• 停止方法へたどれるか

確認できない項目は理由と確認先を残します。説明例の結果を、自分の環境で確かめた結果へ置き換えないでください。