自動化の接続情報を安全に更新する｜再認証・切り替え・旧接続の廃止

どの処理が接続を使うか調べる

更新するキーや接続名を使う処理を一覧にし、定期処理、手動処理、失敗後の再試行も含めます。同じ接続を複数のシナリオで共有していると、一か所の変更が別の業務へ影響します。接続先、必要な操作、管理者、更新期限、使っている処理を対応付け、値そのものは一覧へ貼り付けません。個人の接続で動いている場合は、会社として維持できるアカウントへ移す必要があるかを先に判断します。所有者が不明な接続を推測で置き換えないことも大切です。

接続名を変えるときは、新旧の対応を記録してから行います。似た名前の接続を取り違えないよう、用途と管理する組織を表す名前にすると、次回の点検でも対象を絞り込みやすくなります。

必要な権限を新しい接続へそろえる

新しい接続では、使う表やフォルダー、実行する操作に必要な権限を確認します。広い権限を与えてエラーを消すのではなく、読み取り、追加、更新、通知などの操作を分けて確かめます。検証用の範囲では成功しても、本番の保存先へアクセスできないことがあります。逆に、別の顧客や部門の情報まで読める状態になっていないかも確認します。接続先がOAuthを使う場合とAPIキーを使う場合では更新手順が異なるため、利用中の方式の公式資料を読みます。

受付を止める範囲を決める

新しい接続を作ってから切り替えられるか、旧接続の失効と同時に更新が必要かを確認します。両方を併用できる場合も、同じ依頼を二つの処理へ流してはいけません。受付を一時保存して後から処理する案、短時間だけ処理を止める案、業務ごとに順番に切り替える案を比較します。停止中のデータがどこへ残るかを明示し、上限や保存期間を確認します。変更中に誰が受付を監視し、異常があればどの時点へ戻すかも決めておきます。

実際に必要な操作を確認する

再認証に成功した表示だけでは、更新後の業務が動くとは判断できません。架空の受付を使い、検索、登録、更新、通知まで必要な操作を確認します。読み取りだけ成功して書き込みが失敗する場合を見逃さないようにし、接続先の作成者や更新履歴も確認します。ログにキーや認証ヘッダーを出して動作を調べる方法は避け、受付番号と結果で追跡します。担当者が手作業で行う復旧操作にも、新しい接続で必要な権限があるかを確認しましょう。

旧接続は利用がなくなってから廃止する

通常の処理を切り替えても、過去の失敗分が旧接続を参照することがあります。残っている未処理や実行中の処理を確認し、旧接続が最後に使われた記録を調べます。廃止日と承認者を決め、不要になったアクセスを接続先でも取り消します。ただし、障害時に戻すための条件が残っている間は、独断で復旧手段を消さないようにします。廃止後には通常処理と例外処理をもう一度確認し、旧接続を参照する設定が残っていないか点検します。

更新日と復旧方法を記録する

更新記録には接続の名前、対象処理、切り替え時刻、確認項目、旧接続の廃止状況を記載します。秘密の値を共有文書へ残す必要はありません。次回の更新担当と期限を決め、退職や権限変更を契機に点検する運用へつなげます。担当者が変わるときは、接続情報の更新だけでなく請求、未処理、障害時の連絡先も引き継ぎます。この記録を見た別の担当者が、認証エラーと入力不備を区別して対応できる状態を目指しましょう。

• 自動化の担当交代｜接続アカウント・権限・未処理の引き継ぎ
• Webhook自動化の選び方｜重複・順序・再実行をどう扱うか