退職・外注終了時のWordPress引き継ぎ｜権限を止め、投稿と業務を残す確認表

WordPressの担当者が退職する、制作会社との契約が終わるというときは、不要な操作権限を残さず、会社の記事と日常の更新を維持する必要があります。「旧担当のユーザーを消す」だけでは、投稿の扱い、外部アプリの接続、サーバーやドメインの管理まで確認したことにはなりません。

この記事は、企業の管理責任者とWordPressを引き継ぐ制作・保守担当向けです。会社として合意する担当と終了時点、WordPressで確認するユーザーと投稿、外部の接続を分けます。特定の退職者の行為や情報漏えいを想定した記事ではなく、通常の担当変更で使う業務の確認表です。

1．終了する仕事と、次の管理責任者を決める

先に、誰のどの業務が、いつ終了するのかを決めます。記事の編集だけを終了するのか、テーマやプラグインの管理も移るのか、サーバーやドメインの契約も移るのか。会社の責任者と旧担当、新担当で範囲を揃えます。契約終了日から、すべてのサービスの権限移行日を自動的に推測しません。

自分たちが管理できる入口を先に確保する

残る担当者が正規の管理権限でログインでき、登録メールや認証・復旧の窓口を管理できるかを確認します。最後の管理者を消したり、個人の携帯電話だけに復旧を依存したまま引き継ぎを終えたりしないようにします。旧担当のパスワードを借り続ける方式より、本人別に操作と責任を追える方式を検討してください。

受け渡し資料にはサイトURL、管理範囲、終了時点、旧担当と新担当の役割、承認者、連絡先、未決定事項を載せます。パスワードや復旧コードそのものは、一般の確認表へ書かず、合意した安全な受け渡し経路で扱います。

2．WordPressのユーザーと、外部の権限を別々に棚卸しする

WordPressのユーザー一覧では、利用者、役割、使用目的、残す理由を確認します。同じ人が複数のサイトに別のアカウントを持っている場合もあります。表示名だけで本人を断定せず、サイトとユーザーを対応付けます。役割は追加機能で変わるため、管理者・編集者といった名前だけで実際の操作範囲を判断しません。（WordPressの役割と権限）

不明なアカウントを即削除せず、機能や外部接続との関係を調べます。使っていないと確認できたものと、用途未確認のものを分けて記録してください。一般的な受け渡し全体はWeb制作会社を変更するときの引き継ぎと併せて整理できます。

3．投稿の保存と、公開する著者の表示を確認する

旧担当のユーザーに紐づく投稿を調べ、会社として残す記事、下書き、添付情報などの扱いを決めます。WordPressのユーザー削除画面には、関連する内容を削除する選択と、別のユーザーへ割り当てる選択があります。操作前に、実際の選択肢と対象を確認してください。（WordPressのユーザー画面）

保存の割り当て先と、著者表示の合意を分ける

投稿を新しい担当へ割り当てることと、その担当が記事を書いたと表示することは同じではありません。公開される著者名、プロフィール、監修表示、記事末尾のクレジットを確認し、保存のための管理と読者へ伝える著者情報が食い違わないようにします。実際に執筆・確認していない人の実績を作る方法は採用しません。

独自の投稿タイプや会員・予約機能、ユーザーと関連した追加データがある場合は、標準の画面だけで全部の扱いを保証しません。WordPressの削除処理には投稿の再割り当てと関連処理があり、追加機能の動作も確認が必要です。（wp_delete_userの公式仕様）コードを実行する指示ではありません。

対象件数、代表的な本文と画像、分類、公開URL、著者表示、残す下書きを操作前に記録します。データを消す選択は、会社として削除する内容を確定した場合だけ検討し、担当変更を理由に必要な公開記事まで失わないようにします。

4．アプリケーションパスワードは、用途ごとに見直す

WordPressのアプリケーションパスワードは、外部アプリなどがAPIを利用するための認証です。通常のブラウザーログイン用パスワードと別に扱われ、個別に取り消せます。利用者、接続元、名称、用途と管理者を確認します。（WordPressのアプリケーションパスワード）

通常ログインのパスワードを変えたことだけで、外部の接続をすべて確認したと扱わないでください。会社が継続利用する投稿・連携処理と、終了する旧担当の接続を分けます。名称や最終利用の表示は調査の手がかりですが、名前だけで必要性や安全性を確定するものではありません。

接続を引き継ぐなら、止める前に次の方式を試す

継続が必要な接続は、正規の担当と必要な権限へ移す方式を実装者と決めます。次の接続を試験し、出力や通知を確認した後、旧接続を終了する順番を合意します。一括で取り消した結果、必要な投稿や連携が止まる状態を避けてください。不要な旧接続は、取り消しと停止後の確認を記録します。

確認表へ秘密の値を写す必要はありません。利用者、識別できる名称、用途、担当、継続/終了/未確認、確認結果を残します。外部サービス側に別の共有や認証があるなら、その担当の確認も必要です。

5．変更前の原本と、戻せる範囲を残す

権限変更やユーザー削除に先立ち、対象ユーザーと投稿の関係、変更前の設定、保存すべきデータ、確認する機能を記録します。個人情報を含む資料やバックアップは、閲覧者と保管期間を決めて管理します。関係者全員へ無制限に共有する確認表にはしません。

バックアップがあることと、必要な投稿や機能を戻せることは別です。WordPressバックアップの復元確認を参考に、対象データと復元方法を技術担当へ確認します。全体DBを戻すと、保存後に発生した別の更新へ影響する場合があるため、単にバックアップがあるから安全とは判断しません。

変更票には、操作する人、終了時点、対象、保持するデータ、差分、影響、確認手順、戻し方、承認者を書きます。不正利用が疑われるなど緊急の状況は通常の引き継ぎと分け、管理責任者と保守担当へ早く連絡します。証拠や必要なデータを無計画に消す操作は避けてください。

6．変更後は、新担当の業務と公開表示を読み直す

実装者の強い権限だけで確認せず、新担当が日常使う権限で必要な作業を試します。ログイン、記事の編集と保存、公開確認、必要な通知や外部接続まで、合意した範囲を通してください。試験データを本番へ出すかどうかは別に決めます。

権限整理の完了と、契約の移管・精算の完了は分けます。実際に確認したサービスとサイトを列挙し、「すべて安全になった」という無条件の報告にしないでください。マルチサイトや独自の認証を使う環境では、その構成に合わせた確認が必要です。

7．次の担当変更に使える権限台帳を残す

台帳には、サイト/サービス、利用者、役割、用途、会社の管理責任者、次回確認のきっかけを残します。追加した日時と終了の理由も記録できれば、用途不明の入口を減らす材料になります。認証の秘密は台帳と分けます。

日常の更新と、管理者の仕事を分けて運用する

原稿担当が通常使う権限と、設定・連携を扱う権限を現在の業務に合わせて考えます。権限を下げただけでログインできなくなったと推測せず、止めたい操作が止まり、必要な作業が残るかを確認します。必要な機能を全部止めてしまう運用も解決ではありません。

整理後は、問い合わせ先が会社に残り、次の担当が正規の方法で更新を続けられるかを確認します。台帳を自動作成した件数より、用途不明が減ったか、変更時の確認負担が減ったか、不要な操作権限を残していないかを見ます。

8．Acquaには、保持したい情報と終了対象を伝える

相談時には、対象サイト、終了する業務、現管理者、次の担当、投稿と連携の種類、期限、未確認の契約や入口を伝えます。機密の認証情報を最初の相談へ添える必要はありません。会社として判断する内容と、技術調査が必要な内容を分けてください。

企業の方はWeb制作・運用の案内、制作会社の方はWordPress実装・保守の案内から、現行構成の確認、必要な権限・投稿の調査、試験と引き継ぎの対応範囲を相談できます。サーバー、外部サービス、契約の移管まで一律に含むとはせず、権限と条件を見て合意します。

支援後の状態は、会社の記事と必要な連携が維持され、新担当が更新でき、終了対象と未確認の入口、管理窓口が明確になっていることです。作業範囲と費用を確認したい場合はお問い合わせへ状況をお知らせください。