Web担当者の退職・異動時に引き継ぐもの｜サイト・メール・計測・外部サービス

Web担当者が退職・異動するとき、引き継ぐものは「ログインIDとパスワードの一覧」だけではありません。会社側の担当者が、必要な権限でログインでき、認証をやり直せて、更新通知や請求を受け取り、日常作業と緊急時の復旧を自分で進められる状態まで移す必要があります。

最終出社日にIDを受け取っても、2段階認証が退職者のスマートフォンに残っていたり、ドメイン更新の連絡先が個人メールだったり、管理者ではなく閲覧権限しかなかったりすれば、実務は止まります。サービスによっては新しい所有者を追加した直後に一部の管理操作が制限されます。たとえばGoogle ビジネス プロフィールでは、新しい所有者・管理者に最初の7日間の制限があるため、最終日に着手するのは遅すぎます。

安全な順序は、資産を一覧化し、会社側の権限を追加し、認証・復旧先を移し、実機で操作を確かめてから、旧担当者のアクセスを止めることです。以下では、サイト、メール、計測、検索、地図、広告、SNS、外部サービス、素材、契約、請求、更新予定までを一つの引き継ぎとして整理します。

最初に決めるのは「何を渡したか」ではなく、引き継ぎの完了条件

引き継ぎ表の行を埋めただけでは、完了とは言えません。必要なのは、後任者または会社側の管理者が、旧担当者に連絡しなくても通常運用と復旧を進められることです。サービスごとに次の状態を確かめると、単なる情報共有と実際の移管を区別できます。

• 権限：会社が管理するアカウントに、業務に必要な所有者・管理者・編集者などの権限が付いている
• 認証：2段階認証、復旧用メール、復旧用電話、バックアップコードの管理先が会社側へ移っている
• 操作：後任者の端末とブラウザーでログインし、更新、公開、ユーザー管理、レポート閲覧など必要な操作を試している
• 契約：契約名義、更新日、支払方法、請求書、解約条件、ベンダー窓口が分かる
• 通知：障害、更新、決済失敗、フォーム受信、広告審査などの通知が会社で受け取れる
• 終了処理：移管確認後に旧担当者のアカウント、セッション、連携アプリ、APIトークンを必要な範囲で無効化している

ここでいう「会社管理アカウント」は、一つのIDを複数人で使い回すことではありません。サービスがユーザー招待に対応しているなら、各担当者が会社メールの個別アカウントを使い、組織が追加・削除できる形が基本です。共有が避けられない契約者アカウントや緊急用アカウントは、社内で承認したパスワード管理ツールに保管し、閲覧者と利用履歴を限定します。

退職・異動日だけを期限にせず、「会社側アカウントでの操作確認日」と「旧アカウント停止日」を別に置くのも有効です。権限追加から移管までに待機時間があるサービス、請求日の直前に変更を避けたいサービス、外部制作会社の承認が必要なサービスを先に見つけられます。

一覧表はサービス名ではなく「管理できる状態」を記録する

漏れを防ぐには、担当者が覚えているツール名を並べるだけでなく、事業上の役割から洗い出します。サイトを表示する仕組み、問い合わせを届ける仕組み、成果を測る仕組み、集客・予約・決済を行う仕組み、制作物と契約を支える仕組みに分けると、名前の知られていない連携サービスも見つけやすくなります。

区分	主な対象	引き継ぎ表に記録すること
サイト基盤	ドメイン、DNS、サーバー、CDN、SSL、バックアップ	契約者、管理URL、更新日、支払方法、通知先、復旧方法、保守会社
更新・開発	CMS、テーマ、プラグイン、FTP・SSH、リポジトリ、公開手順	管理者、権限、接続元制限、作業手順、最終更新、戻し方、開発窓口
メール・問い合わせ	メール管理、共有アドレス、転送、フォーム、SMTP、迷惑メール対策	受信者、送信元、通知先、認証情報の保管先、テスト方法、障害時の代替手段
計測・検索・地図・広告	GA4、タグ管理、Search Console、ビジネス プロフィール、広告	アカウント・プロパティ・コンテナ、所有者、請求、連携先、主要設定、確認日
外部サービス	SNS、予約、CRM、チャット、決済、ストレージ、動画、API	管理者、契約、Webhook・OAuth・APIキー、更新日、停止時の影響、問い合わせ先
素材・契約・予定	画像、原稿、デザインデータ、ライセンス、見積・契約・請求、更新計画	保存場所、利用範囲、原本、承認履歴、期限、次の担当者、未完了事項

表には、サービス名、管理画面URL、用途、契約名義、現在の管理者、必要な権限、復旧先、2段階認証の方式、請求先、更新日、ベンダー、最終確認日を記録します。一方、パスワード、バックアップコード、秘密鍵、APIシークレットを平文の表へ貼り付けてはいけません。引き継ぎ表は資産の所在と責任者を示す台帳、秘密情報はアクセス制御された保管庫、と役割を分けます。

依存関係も一緒に書くと、緊急時の順序が分かります。たとえば、会社メールの復旧にドメインのDNS変更が必要で、その会社メールがCMSや計測ツールの復旧先になっているなら、ドメインとDNSが最上流です。フォームからCRMへ送るWebhook、サイトに埋め込むタグ管理、広告のコンバージョン計測など、片方を変更すると別の仕組みが止まる関係も記録します。

権限は「追加して試す」まで終えてから、旧担当を外す

もっとも事故が起きやすいのは、旧担当者を先に削除し、後から会社側の権限不足に気づく流れです。削除前に、次の5段階を同じ順序で進めます。

1. 資産と契約を一覧化する。 管理画面だけでなく、請求書、カード明細、契約書、社内メール、ブラウザーのブックマーク、サイトのソース、DNSレコードから利用中のサービスを確認します。
2. 会社側の権限を追加する。 既存の所有者・管理者から会社メールの個別アカウントを招待し、役割を選びます。管理者権限を全員へ配るのではなく、日常作業に必要な最小範囲と、復旧を担う管理者を分けます。
3. 認証・復旧先を移す。 2段階認証アプリ、セキュリティキー、復旧用メール・電話、バックアップコード、本人確認に使う契約情報を会社側へ移します。変更直後は旧手段を消す前に新手段で再認証します。
4. 実機でログインし、仕事を一つ完了させる。 後任者の端末で、記事の下書き保存、フォームの試験送信、レポート閲覧、ユーザー一覧確認など、そのサービスで実際に行う操作を試します。ログインできるだけでは、必要な権限があるか分かりません。
5. 旧アカウントを停止する。 新しい権限と復旧手段を確認してから、旧ユーザー、ログイン中セッション、アプリ連携、不要なAPIトークンを無効化します。共用パスワードが残る場合は、影響範囲を確認して変更します。

サービスごとに「所有者」「管理者」「編集者」「閲覧者」の意味は異なります。WordPressでは役割ごとに実行できる操作が分かれているため、日常更新をする人とユーザー・テーマ・プラグインまで管理する人を分けられます。公式のWordPressの権限グループと権限を確認し、退職者の代わりに全員を管理者へするのではなく、必要な役割を割り当てます。

所有権の移管があるサービスは、ユーザー追加より早く着手します。Google ビジネス プロフィールでは、パスワードを共有せず、各ユーザーを所有者または管理者として追加できます。主たる所有者を移す場合は待機制限もあるため、所有者と管理者の管理手順を確認し、退職日より前に招待と承認を終えます。

サイト・メール・計測・外部サービスを止めずに引き継ぐ

サイトはドメインから公開作業までを一本の経路として確認する

ホームページの管理画面へ入れるだけでは不十分です。ドメインの契約先と登録者、DNSを変更できる場所、サーバー契約、SSL証明書、CDN、CMS、バックアップ、公開手順が別々の会社やアカウントに分かれていることがあります。ドメイン更新が切れればサイトとメールの両方が止まり、DNSを誤ればフォームや認証にも影響します。

まず、ドメインの契約名義、登録メール、更新期限、自動更新、支払方法を確認します。次に、DNSをどこで管理しているか、サーバーとメールが同じ契約か、制作会社が代理管理しているかを記録します。代理管理であれば、会社が直接触れる必要がある範囲と、委託先が作業する範囲を分け、障害時の連絡先と本人確認に必要な情報を残します。

CMSでは、公開サイトURL、管理画面URL、管理者、編集者、保守用アカウント、更新対象、バックアップ先、復元手順、テスト環境の有無を確認します。FTP・SSH、ソースコード管理、デプロイサービス、ジョブ実行、環境変数などが使われている場合は、接続情報の保管場所と変更時の影響も対象です。新しい担当者が本番へ変更を加える前に、下書き保存やテスト環境での更新、バックアップ取得など安全な操作から試します。

メールと問い合わせは、受信・送信・通知の三方向で試す

メールは、個人の受信箱を渡すのではなく、会社のメール管理、共有アドレス、メーリングリスト、転送、エイリアス、退職者アドレスの扱いを整理します。メールサービスの管理者、ドメイン認証、容量、アーカイブ、迷惑メール判定、障害通知も確認対象です。退職者の受信箱を誰がどの期間扱うかは、社内の情報管理・労務方針に従い、個人アカウントを無期限に共用する運用は避けます。

問い合わせフォームは、画面上で送信できるだけでは完了しません。送信先、CC・BCC、差出人、返信先、自動返信、SMTPまたはメール送信API、迷惑メール対策、保存先、CRM連携を確認します。外部のメールアドレスからテスト送信し、担当者が受信できるか、自動返信が届くか、返信時に正しい宛先へ戻るかまで見ます。フォームの障害通知が退職者だけに届く設定も見落としやすい点です。

メールの復旧先がドメイン契約やサーバーの本人確認に使われている場合、メール停止前に変更します。逆に、会社メールを復旧するために同じ会社メールへ確認コードが送られる循環がないかも確認します。復旧用の共有アドレスは、複数の現職者が管理でき、退職者の端末や個人電話に依存しない形にします。

GA4・Search Console・地図・広告は、対象と権限をセットで記録する

Googleの各サービスは、同じGoogleアカウントで表示されても管理対象が異なります。GA4はアカウントとプロパティ、タグ管理はアカウントとコンテナ、Search Consoleはプロパティ、Google ビジネス プロフィールは店舗・事業プロフィール、広告は広告アカウントやマネージャー アカウントという単位で権限を持ちます。「Googleには入れる」とだけ記録すると、対象のプロパティに必要な権限がないことを見落とします。

GA4では、会社側のユーザーが対象アカウント・プロパティに追加され、必要な役割とデータ制限になっているかをアクセス管理の公式手順で確認します。レポート閲覧だけでなく、ユーザー管理、連携、設定変更を誰が担うかを決めます。タグ管理を使っている場合は、GA4の権限だけでなく、対象コンテナの公開権限と変更履歴も引き継ぎます。

Search Consoleでは、URLプレフィックスかドメインかというプロパティの種類、確認済み所有者、委任された所有者、フルユーザーなどを確認します。所有者の確認方法がHTMLファイル、HTMLタグ、DNS、GA4などのどれかによって、旧所有者を外す方法も変わります。所有者、ユーザー、権限の管理を参照し、新しい所有者の確認が済む前に古い確認トークンを消さないようにします。

広告は、閲覧・変更・請求・ユーザー管理の権限、支払方法、請求書の受取先、コンバージョン計測、リンクしているGA4やタグ管理を確認します。Google 広告の公式セキュリティ案内は、退職者のアクセスを確認して削除し、認証情報を共有しないことを勧めています。Google 広告アカウントを保護する方法に沿って、会社側の個別ユーザーを追加した後に旧ユーザーを外します。

外部サービスは、画面に見えない連携までたどる

SNS、予約、CRM、チャット、決済、クラウドストレージ、動画配信、メール配信、オンライン会議、フォーム、地図API、reCAPTCHA、画像・フォント・プラグインのライセンスなどもWeb運用の一部です。契約や管理者を引き継いでも、サイトと結ぶAPIキー、Webhook、OAuth認可、埋め込みコードが退職者のアカウントにひも付いている場合があります。

連携情報を見つけたら、何がどこへデータを送り、停止するとどの画面や業務へ影響するかを一行で書きます。トークンやキーは所有者変更を機にローテーションする方が安全ですが、先に無効化するとフォーム、予約、決済、計測が止まることがあります。新しい認証情報を発行し、テスト環境または影響の小さい時間帯で差し替え、送受信を確認してから古いものを失効させます。

有料サービスでは、契約者名、契約プラン、更新周期、支払いカード、請求書宛名、解約期限、利用数の上限も確認します。退職者の法人カードが停止した後に更新失敗へ気づく例を防ぐには、次回更新日と通知先を台帳に入れ、経理・管理部門も確認できる状態にします。

操作方法だけでなく、判断の履歴と更新予定を渡す

手順書があっても、「なぜこの設定なのか」が分からなければ、後任者は安全に変更できません。引き継ぎ資料は、定常運用、進行中の仕事、判断履歴の三層に分けると使いやすくなります。

• 定常運用：更新頻度、公開前確認、問い合わせ対応、レポート作成、バックアップ確認、請求処理など、繰り返す作業
• 進行中の仕事：未公開ページ、修正依頼、広告キャンペーン、計測変更、契約更新、素材待ちなど、期限と次の一手がある作業
• 判断履歴：採用しなかった案、例外設定、関係者の合意、障害対応、法務・ブランド上の制約など、変更時に必要な背景

各項目には、目的、担当者、承認者、期限、作業場所、関連資料、完了条件を付けます。「毎月レポートを出す」だけでなく、どのプロパティを見て、どの期間と指標を使い、誰へ共有し、異常時に誰へ連絡するかまで書くと、後任者が同じ成果物を作れます。

素材は、公開済み画像だけでなく、編集可能な原本、撮影データ、ロゴ、文章、図版、動画、ライセンス証明、利用許諾、クレジット条件を含みます。制作会社や広告代理店へ依頼中のものは、契約範囲、納品形式、修正回数、窓口、検収状況を残します。ファイル名だけでなく、正式版の保存場所と、公開中のページとの対応が分かるようにします。

画面録画は操作の流れを見せるのに便利ですが、URL、アカウント単位、権限、期限、例外を検索しにくいため、台帳や手順書の代わりにはなりません。短い動画と、更新できるテキストの手順を組み合わせ、最終更新日と確認者を明記します。

退職者アカウントは、移管確認後に無効化する

退職者のアクセスを残し続けるのは避けるべきですが、停止の順序を誤ると復旧不能になります。最初に会社側の所有者・管理者を追加し、認証と操作を確認します。その後、サービスのユーザー一覧から旧担当者を削除し、ログイン中セッション、アプリパスワード、OAuth連携、APIトークン、SSH鍵、VPN、共有フォルダー、メーリングリストも対象にします。

共有IDを使っていた場合は、パスワード変更だけで終わらせません。復旧用メール・電話、2段階認証、バックアップコード、信頼済み端末、ログインセッション、外部アプリの認可を更新します。変更後は、定期処理、フォーム、連携、請求、通知が動いているかを確認します。

退職者のメールアドレスをすぐ削除すると、契約更新、障害通知、本人確認、問い合わせ返信の履歴が失われることがあります。先に各サービスの登録先を会社の共有アドレスや後任者へ変更し、必要なメールの保存と引き継ぎを社内方針に沿って行ってから、アカウント停止へ進みます。

最後に、停止日、停止した権限、残したアクセス、確認者、未解決事項を記録します。権限変更の監査ログや通知メールも、社内ルールに従って保存します。これにより、「消したはず」「引き継いだはず」という認識差を減らせます。

突然の退職で情報が足りないときは、変更より証拠集めを先にする

担当者がすでに連絡できない場合、焦ってすべてのパスワードやDNSを変更すると、かえって復旧経路を失うことがあります。まず会社が正当に管理できる範囲で、契約・アクセス・依存関係の証拠を集めます。個人アカウントや私物端末へ権限なくアクセスするのではなく、会社のメール、契約書、請求書、経費明細、社給端末、パスワード管理ツール、制作会社との連絡履歴を確認します。

• 最上流を確保する：ドメイン、DNS、会社メール、契約者情報を確認し、復旧用メールを受け取れる状態にする
• 公開と問い合わせを守る：サーバー、CMS、バックアップ、フォーム、SMTPの現状を保存し、不要な変更を止める
• 所有権を取り戻す：各サービスの公式な所有権確認・管理者追加・サポート手続きを使う
• 計測と集客を復旧する：GA4、タグ管理、Search Console、地図、広告、SNSを対象単位ごとに確認する
• 連携を整理する：API、Webhook、OAuth、共有鍵を洗い出し、新しい認証情報へ段階的に切り替える

サポートへ連絡するときは、会社名、ドメイン、契約番号、請求書、支払記録、登録住所、代表者情報など、正当な管理者であることを示す資料が求められる場合があります。サービスごとに必要書類が異なるため、推測で手続きを繰り返さず、公式窓口の案内に沿います。復旧中に行った変更は時刻と担当者を記録し、後から原因と影響を追えるようにします。

Search Consoleなど、確認済み所有者が不明でも新しい所有者確認ができるサービスがあります。ただし、古い確認トークンを削除する順序や、DNS変更の影響はサイト構成によって異なります。分からない場合は、現状の証拠を保存し、ドメイン・サーバー・制作会社の関係を整理してから変更します。

交代後30日以内に、次の引き継ぎを軽くする

今回の引き継ぎを一度きりの資料作成で終わらせず、日常運用へ組み込みます。重要サービスは、一人の個人アカウントだけが唯一の所有者にならないよう、会社が管理できる所有者・管理者を複数置きます。ただし、権限を広く配るのではなく、緊急時に復旧できる管理者と日常作業の担当者を分けます。

• 資産台帳の責任者と四半期ごとの確認日を決め、管理者・復旧先・更新日・請求先を見直す
• 重要サービスは会社側の管理者を少なくとも二系統用意し、片方の不在でも復旧できるようにする
• 個別アカウント、パスワード管理、緊急用アカウント、2段階認証の保管ルールを統一する
• 入社・異動・退職のチェックリストを人事・総務の手続きとつなぎ、Web資産の追加・削除を同じ日に確認する
• 契約更新と障害通知を共有アドレスへ寄せ、担当者だけでなく経理・管理者も期限を把握できるようにする
• 変更理由、承認、公開日、戻し方をチケットや更新履歴へ残し、次の担当者が判断を再現できるようにする

担当者交代の前から、ドメインやサーバーの契約名義、制作会社との役割分担そのものが不明な場合は、先にホームページの名義と管理を分ける5項目を確認すると、誰が契約者で、誰が実務を担うかを整理しやすくなります。今回の記事は、その前提をもとに、退職・異動時の実際の移管手順へ焦点を当てています。

まとめ｜引き継ぎは、会社側で再現できて初めて完了する

Web担当者の退職・異動時は、サーバー、ドメイン、CMS、メール、GA4、タグ管理、Search Console、Google ビジネス プロフィール、広告、SNS、外部連携、素材、契約、請求、2段階認証、更新予定を一覧化します。ただし、一覧を渡すことが目的ではありません。会社側の個別アカウントへ必要な権限を追加し、復旧先と認証を移し、実際の端末で業務を一つ完了させるところまでが引き継ぎです。

旧担当者のアカウントは、その確認後に停止します。最終出社日から逆算し、所有権移管に待機期間があるサービス、ドメインとメールのように他の復旧を支えるサービスから着手すると、サイトや問い合わせ、計測、集客を止めずに交代しやすくなります。