企業のWebサイト運用において、担当者の退職や人事異動、制作会社・外部パートナーとの契約終了に伴う「WordPress管理者の引き継ぎ」は、セキュリティ上きわめて重要な局面です。
しかし、現場では以下のような悩みや不安が多く見受けられます。
– 「前任者が退職したが、誰にどの権限が渡っているのか把握できていない」
– 「元外注先が制作時に作った管理者アカウントが残ったままになっている」
– 「退職者のアカウントを削除したいが、過去に執筆した記事が消えてしまわないか不安」
– 「パスワードを変更したが、前任者の私用PCやスマホでログイン状態が続いていないか心配」
WordPressは世界中で広く普及しているCMSであるため、アカウント管理の不備を狙った不正アクセスの標的になりやすい側面があります。特にサイト全体の設定を変更できる「管理者（Administrator）」権限のアカウントが1つでも放置されていると、サイト改ざんや機密情報の漏洩といった致命的な事故に直結します。
さらにWordPress特有の仕様として、 ユーザー削除時のコンテンツ紐付け設定を誤ると、過去の記事が一瞬で完全削除される という取り返しのつかないリスクも存在します。
本記事では、企業のWeb担当者や情報システム部門の方に向けて、過去コンテンツを安全に保護しながらセキュリティリスクを排除する「WordPress管理者引き継ぎ・退職時の安全手順」を解説します。最後には実務ですぐに使えるコピペ可能なチェックシートも掲載していますので、ぜひご活用ください。
—
## なぜ退職者・異動者のWordPressアカウント放置が重大なリスクになるのか？
「これまで信頼して一緒に働いてきた仲間だから悪用などしない」と、性善説に基づいてアカウントの削除やパスワード変更を後回しにしてしまうケースは少なくありません。
しかし、セキュリティ事故は前任者の悪意のみで起こるわけではありません。放置されたアカウントが意図しない経路で第三者に乗っ取られるケースが大半を占めています。
### 放置された管理者権限が招く不正ログイン・サイト改ざん・情報漏洩事例
退職者や異動者の管理者アカウントを放置しておくことには、主に以下のような深刻なリスクがあります。
1. パスワード使い回しによる不正ログイン（リスト型攻撃）
退職者が社内用WordPressで使っていたパスワードを私的なWebサービスでも使い回していた場合、外部サービスで情報流出が起きた際に、その漏洩データをもとにWordPressへ不正ログインされてしまいます。本人の意図にかかわらず、放置アカウントが攻撃者の侵入口となります。
2. 端末紛失やマルウェア感染に伴うセッション侵害
前任者の私用PCやスマートフォンにブラウザのログインセッションや保存されたパスワードが残っている場合、端末の紛失・盗難や情報窃取型マルウェア（インフォスティーラー）への感染によって、第三者に管理画面へ侵入される恐れがあります。
3. 非公開情報や顧客データの閲覧・漏洩
管理者権限を持つユーザーは、公開記事だけでなく、未公開のプレスリリース、下書き記事、さらには問い合わせフォームプラグインに蓄積された顧客の個人情報まで自由に閲覧・エクスポート可能です。競合他社への転職や独立に際し、機密情報が持ち出されるリスクを否定できません。
4. 労務トラブルや怨恨によるコンテンツ改ざん・データ消去
万が一、退職時に労務上の摩擦やトラブルがあった場合、残された特権アカウントを悪用してサイト表示を改ざんされたり、データベースを破壊されたりする直接的な報復リスクもゼロではありません。
これらが発生した場合、企業の社会的信用の失墜や復旧費用の発生など、甚大な損害につながります。
### 外注制作会社・フリーランスとの契約終了後に潜むシャドーアカウントの脅威
自社の従業員だけでなく、Web制作会社、保守運用会社、フリーランスなど、外部パートナーとの契約終了時にも注意が必要です。
開発やサイトリニューアルの現場では、動作確認や緊急対応の便宜上、以下のような一時的なアカウントが作成されがちです。
– `test_admin` や `dev_user` などの検証用管理者アカウント
– 個々のコーダーやデザイナーが各自の名前で作成した複数の管理者アカウント
– プラグインやテーマの動作テスト用に発行された共通アカウント
これらのアカウントは、プロジェクト完了後に削除されず、誰も管理していない シャドーアカウント（幽霊アカウント） として放置される傾向があります。
外部委託先のスタッフは流動性が高く、退職や転職も頻繁に起こります。自社の管理が及ばない外部組織のアカウントを残しておくことは、大きなセキュリティホールを放置しているのと同義です。契約満了時には、外部関係者のアカウントを完全に棚卸しし、権限を剥奪しなければなりません。
組織におけるアクセスコントロールの基本は 「最小権限の原則（Least Privilege）」 です。これは「業務に必要な最小限の権限のみを、必要な期間だけ付与する」という鉄則です。日常的な記事投稿であれば「編集者」や「投稿者」で十分であり、サイト全体を制御できる「管理者」権限は常に最小人数に限定すべきです。
WordPressにおける各権限グループの具体的な違いや安全な運用設計については、以下の記事で詳しく解説しています。
参考リンク：[WordPressユーザー権限グループ完全セキュリティガイド](https://blog.mozcheck.jp/2026/10/15/wordpress-user-roles-security-guide/)
—
## WordPressユーザー削除で絶対にやってはいけないこと：記事消失事故の防止
退職者や不要になったアカウントを管理画面から削除する際、最も注意しなければならないのが 「過去記事の消失事故」 です。
WordPressの仕様を理解しないまま操作すると、その担当者が過去に執筆した大切なコンテンツが一瞬で失われてしまいます。
### ユーザー削除確認画面の「すべてのコンテンツを消去」の致命的リスク
WordPress管理画面の `ユーザー` ＞ `ユーザー一覧` で対象ユーザーの「削除」をクリックすると、以下の確認画面が表示されます。
“`text
ユーザーの削除
以下のユーザーを削除しようとしています:
ユーザー名: sample_user (担当者名)
このユーザーが投稿したコンテンツをどうしますか？
○ すべてのコンテンツを消去します。
○ すべてのコンテンツを以下のユーザーのものにする: [ ユーザーを選択 ▼ ]
“`
ここで誤って 「すべてのコンテンツを消去します」を選んだまま削除を実行すると、そのユーザーが過去に作成した投稿、固定ページ、カスタム投稿がデータベースから完全に物理削除 されます。
ゴミ箱に入るのではなく、データベースから直接消去されるため、「ゴミ箱から復元する」という操作は一切行えません。過去に数百本の記事を執筆していた場合、それらのURLがすべて404エラー（Not Found）となり、検索順位の急落やアクセス数の激減を招きます。
### 【必須手順】「すべてのコンテンツを以下のユーザーに紐付ける」の正しい選択方法
過去記事を保護しながらアカウントを安全に削除するため、以下の手順を必ず遵守してください。
“`mermaid
flowchart TD
Step0[“手順0: サイト全体のフルバックアップ取得（絶対厳守）”] –> Step1[“手順1: 引き継ぎ先アカウント（新任管理者または編集部）を準備”]
Step1 –> Step2[“手順2: ユーザー一覧から該当ユーザーの「削除」をクリック”]
Step2 –> Step3[“手順3: 「すべてのコンテンツを以下のユーザーのものにする」を選択”]
Step3 –> Step4[“手順4: ドロップダウンから引き継ぎ先ユーザーを指定して実行”]
“`
#### 手順0：作業前のフルバックアップ取得（絶対厳守）
ユーザー削除や権限変更に着手する前に、 必ずサイト全体の完全バックアップ（データベースおよびファイル一式）を取得 してください。
「1つのアカウントを操作するだけだから」と油断してはいけません。万が一誤操作が発生しても、バックアップがあれば元の状態に復旧できます。All-in-One WP Migration、UpdraftPlusなどのバックアッププラグインや、サーバーの自動バックアップ機能を活用して直前の状態を保存しましょう。
#### 手順1：コンテンツ引き継ぎ先アカウントの選定・作成
退職者のコンテンツを引き継ぐ「受け皿」となるユーザーを用意します。
後任の担当者が決まっている場合は「新任の管理者アカウント」を指定します。もし属人化を防ぎたい場合や担当者が流動的な場合は、「編集部（editorial_team）」や「広報担当」といった 組織共通のアーカイブ用アカウント を作成して指定するのが実務上おすすめです。
#### 手順2：ラジオボタンの切り替えと安全な削除実行
1. 管理画面の `ユーザー` ＞ `ユーザー一覧` を開きます。
2. 削除対象のユーザーにカーソルを合わせ、「削除」をクリックします。
3. 確認画面で、必ず 「すべてのコンテンツを以下のユーザーのものにする」 を選択します。
4. ドロップダウンから、手順1で用意した引き継ぎ先アカウントを選択します。
5. 「削除を実行」をクリックします。
これで、退職者のアカウントのみが削除され、過去の記事はすべて指定したアカウントの所有として引き継がれます。本文、画像、SEO設定などはすべて維持されます。
### 過去記事の著者表示（byline）を崩さずに退職者のアカウントのみ無効化する工夫
オウンドメディアや専門家ブログでは、Googleの検索評価基準である E-E-A-T（経験・専門性・権威性・信頼性） の観点から、記事末尾の「著者情報（byline）」がSEO上重要なシグナルとなっている場合があります。
ユーザーを削除してコンテンツを別のユーザーに紐付けると、過去記事の著者表示がすべて新任者や編集部名義に書き換わってしまいます。
「過去の著者名表示はそのまま残したいが、前任者がログインすることは防ぎたい」という場合は、 アカウントを削除せず、ログイン不能な状態に無効化（凍結）する のが賢明です。
具体的には以下の手順で対応します。
1. 権限を「購読者（Subscriber）」に降格する
管理画面へのアクセスや記事編集の権限を完全に遮断します。記事の著者情報としては名前が維持されます。
2. 登録メールアドレスを自社管理用のアドレスに変更する
ユーザープロフィールのメールアドレスを、前任者のものから社内管理用アドレス（例: `archive-user@example.com`）に変更します。前任者が「パスワードの再設定」機能を使ってアカウントを取り戻すことを防止できます。
3. パスワードを強力なランダム文字列で再生成する
管理者が無作為な長いパスワードを設定し、前任者には伝えないことでログインを完全に遮断します。
—
## 【実務テンプレート】管理者引き継ぎ・退職時のセキュリティ総点検7つのステップ
WordPressの管理者引き継ぎは、単に管理画面のアカウントを入れ替えるだけでは完了しません。WordPressはWebサーバー、データベース、外部APIなど複数のインフラと連動しているためです。
抜け漏れなく安全に引き継ぎを完了するための 「7つのセキュリティ総点検ステップ」 を順に解説します。
“`mermaid
flowchart TD
S1[“ステップ1: ユーザー棚卸し・不要アカウント削除”] –> S2[“ステップ2: パスワード刷新・強力なフレーズ化”]
S2 –> S3[“ステップ3: 2要素認証(2FA)再設定・端末解除”]
S3 –> S4[“ステップ4: サーバー・SFTPアクセス情報変更”]
S4 –> S5[“ステップ5: データベース接続パスワード変更・同期”]
S5 –> S6[“ステップ6: wp-config.phpソルト再生成・全セッション強制切断”]
S6 –> S7[“ステップ7: 外部APIキー・SMTP・連携権限再発行”]
“`
—
### ステップ1：全登録ユーザーの棚卸しと休眠アカウントの即時削除・権限降格
まず、サイト内に存在する全アカウントを可視化します。
WordPress管理画面の `ユーザー` ＞ `ユーザー一覧` を確認し、以下の点を精査します。
– 退職者、異動者、契約終了した外部制作会社のアカウントが残っていないか
– 開発時のテストアカウント（`test`、`admin`、`staging` 等）が放置されていないか
– 1つの管理者アカウントを複数人で共有して使い回していないか
複数人での管理者アカウント共有は、 「誰がいつ変更を加えたのかログを追えない」「退職者が出るたびに全員のパスワードを変更する必要が生じる」 という重大なリスクを招きます。アカウントは必ず「1人1アカウント」を徹底してください。
不要なアカウントは、前述の「すべてのコンテンツを以下のユーザーのものにする」を選択して削除するか、権限を「購読者」へ降格させます。サイト全体の設定変更が可能な「管理者」権限は、原則として社内の1〜2名に限定しましょう。
参考リンク：[WordPressユーザー権限グループ完全セキュリティガイド](https://blog.mozcheck.jp/2026/10/15/wordpress-user-roles-security-guide/)
—
### ステップ2：現役管理者アカウントのパスワード再設定と強力なフレーズへの刷新
引き継ぎ後も運用を続ける管理者・編集者アカウントのパスワードを直ちに刷新します。
短く単純なパスワードは、ブルートフォース攻撃（総当たり攻撃）や辞書攻撃によって突破される危険があります。現代のセキュリティ基準では、 「推測されにくく十分な長さ（16文字以上）を持つパスフレーズ」 の運用が推奨されています。
– 脆弱なパスワード例 : 単純な単語やサイト名、数字のみ（例: `TokyoSitePass123`）
– 強力なパスフレーズ例 : 無作為な英単語をハイフン等で連結したもの（例: `Green-Morning-Planet-Jumps-Over-Cloud-47`）
パスワードマネージャー（1Password、Bitwarden等）を活用して無作為な長い文字列を自動生成し、ブラウザの簡易保存機能だけに頼らない運用を推奨します。
—
### ステップ3：2要素認証（2FA）の再設定と退職者デバイスの登録解除
パスワードのみの認証は、フィッシングやマルウェア感染に対して脆弱です。管理者権限のアカウントには 2要素認証（2FA: Two-Factor Authentication） の導入が不可欠です。
引き継ぎ時には、以下の2点を確実に実行してください。
1. 退職者端末の認証連携解除
前任者の私用スマートフォン等に設定された認証アプリ（Google Authenticator等）の登録を管理画面から解除・リセットします。前任者の端末情報が残っていると、後任者がログインできなくなる恐れがあります。
2. 新任管理者の2FA設定とバックアップコードの保管
新任管理者の端末で新たにQRコードを読み取り、2FAを再有効化します。端末の紛失や故障時にログインできなくなる事態を防ぐため、発行される「緊急用バックアップコード」を安全な社内管理場所に保管してください。
2FAの導入手順や推奨プラグインの設定方法については、以下の記事で詳しく解説しています。
参考リンク：[WordPress 2要素認証（2FA）完全導入ガイド](https://blog.mozcheck.jp/2026/09/11/wordpress-two-factor-authentication-guide/)
—
### ステップ4：サーバーアクセス情報（SSH / SFTP / サーバーパネル）のパスワード変更
WordPress管理画面のパスワードを変更しても、ホスティングサーバーへのアクセス権限（SSH、SFTP、サーバー管理パネル）が前任者に握られていれば、サーバー上の全ファイルを直接改ざん・閲覧されてしまいます。
前任者や制作会社がサーバー情報を取り扱っていた場合は、以下の項目を必ず見直してください。
– サーバー管理パネル（cPanel、Xserver等）の管理者パスワード変更 : 登録されている管理者メールアドレスも新任者のアドレスに変更します。
– SSH公開鍵の削除 : サーバー内の `~/.ssh/authorized_keys` を確認し、前任者や旧制作会社の公開鍵を削除します。
– SFTP / FTPアカウントの棚卸し : 不要なアカウントを削除し、必要な場合は新担当者専用の接続アカウントを再発行します。
—
### ステップ5：データベース（MySQL / phpMyAdmin）接続パスワードの変更と同期
データベース（MySQL / MariaDB）への直接アクセス権やphpMyAdminのログイン情報も点検が必要です。
#### 変更時の重要注意点
データベースのパスワードをサーバーパネル側で変更した場合、 WordPressの構成ファイルである `wp-config.php` 内のパスワード設定も同時に更新しないと、サイトが「データベース接続確立エラー（Error establishing a database connection）」となって完全停止 します。
作業は以下の手順で行ってください。
1. サイトのフルバックアップを取得する。
2. SFTP等で `wp-config.php` を手元にダウンロードして控えを保存する。
3. サーバーパネル側でMySQLの接続パスワードを変更する。
4. `wp-config.php` 内の `DB_PASSWORD` の記述を新しいパスワードに書き換えてサーバーへ上書きする。
“`php
/** MySQL データベースのパスワード */
define( ‘DB_PASSWORD’, ‘NewStrongDatabasePasswordHere!’ );
“`
5. サイトのトップページおよび管理画面が正常に表示されるか確認する。
—
### ステップ6：wp-config.php 内のソルト（秘密鍵：AUTH_KEY等）再生成による全既存セッション強制切断
「パスワードを変更したからもう安全」と考えるのは早計です。
WordPressはログイン時にCookie（クッキー）を発行してセッションを管理しています。 通常のパスワード変更だけでは、前任者のブラウザに保存された既存のCookieが無効化されず、ブラウザを開いた瞬間にログイン状態が維持されてしまうケース があります。
全端末・全ユーザーのログインセッションをサーバー側から一瞬で強制切断する最も確実な方法が、 `wp-config.php` 内の「認証用ユニークキー（ソルト / Salt）」の再生成 です。
#### ソルト再生成の手順
1. 公式ソルト自動生成ページへアクセス
ブラウザで以下の公式ジェネレーターを開きます。アクセスするたびにランダムな暗号化文字列が生成されます。
`https://api.wordpress.org/secret-key/1.1/salt/`
2. 生成されたコードをコピー
画面に表示された8行の定義コードをコピーします。
“`php
define(‘AUTH_KEY’, ‘p$#D?A=X~z9&K…[ランダム文字列]’);
define(‘SECURE_AUTH_KEY’, ‘T8!vM4#q*Z2@L…[ランダム文字列]’);
define(‘LOGGED_IN_KEY’, ‘m%3W(vP8^yB#Q…[ランダム文字列]’);
define(‘NONCE_KEY’, ‘k9$R!zT&wX2@N…[ランダム文字列]’);
define(‘AUTH_SALT’, ‘A*7d#E2!vP9^Q…[ランダム文字列]’);
define(‘SECURE_AUTH_SALT’, ‘Z#1x@V8%tB4&M…[ランダム文字列]’);
define(‘LOGGED_IN_SALT’, ‘P@4w$Q9&zK2!X…[ランダム文字列]’);
define(‘NONCE_SALT’, ‘D#8y!R3*vN7^P…[ランダム文字列]’);
“`
3. wp-config.php を上書き保存
サーバー上の `wp-config.php` を開き、既存の8行のキー定義部分を新しいコードで丸ごと置き換えて保存します。
4. 全セッションの即時切断
保存した瞬間、 自分自身を含め、現在ログインしているすべてのユーザーのCookieが無効化され、全端末が一斉に強制ログアウト されます。
これにより、前任者や外部委託先のブラウザに残っていた古いログインセッションは完全に遮断されます。
`wp-config.php` の具体的な編集手順やファイルの保護設定については、以下の記事をご参照ください。
参考リンク：[WordPress wp-config.php設定・セキュリティ・トラブルシューティング完全ガイド](https://blog.mozcheck.jp/2026/09/02/wordpress-wp-config-php-setup-security-troubleshooting-guide/)
—
### ステップ7：外部連携（Google Cloud / SMTP / AWS / 決済Webhook）のAPIキー再発行
WordPressは多くの外部サービスとAPI経由で接続しています。前任者個人が発行したAPIキーが残存していると、前任者のアカウント削除に伴い連携機能が停止したり、不正アクセスの温床となったりします。
以下の外部連携について、登録情報やAPIキーの再発行・付け替えを行ってください。
| サービス種別 | 主なプラグイン・用途 | 引き継ぎ時の対応手順 |
| :— | :— | :— |
| GA4 / Search Console | Site Kit、SEOプラグイン | プロパティの管理者権限を新担当者に移譲し、前任者の権限を削除 |
| SMTP メール配信 | WP Mail SMTP、SendGrid | メール送信用APIキーまたはSMTPパスワードの再発行、契約名義変更 |
| Google Cloud API | 店舗地図（Maps API）、住所自動入力 | GCPコンソールでIAM権限を見直し、APIキーのリファラー制限を再設定 |
| クラウドストレージ / CDN | AWS S3、Cloudflare | IAMアクセスキーの再発行、不要なAPIトークンの無効化 |
| 決済サービス | Stripe、PayPal等 | 開発者コンソールでWebhookシークレットおよびAPIキーの再生成 |
—
## 削除できない・ログイン中のアカウントを安全に無効化する方法
実務では、社内規程によるログ保存義務や、将来的な業務再開の可能性などにより、「今すぐにはアカウントを完全削除できない」という場面もあります。
そのような場合に、 アカウントを削除せずにログインのみを完全に遮断する安全な無効化手順 を解説します。
—
### プラグインや functions.php を用いた特定ユーザーの一時停止（凍結）設定
WordPress標準機能には「アカウントの一時凍結ボタン」がありませんが、以下の手法で安全に凍結できます。
1. 無効化プラグインの活用
– Disable Users : プラグインを有効化すると、ユーザー一覧に「Disable」リンクが表示され、ワンクリックでアカウントを凍結できます。凍結されたユーザーはログイン画面で拒絶されます。
– User Activation & Account Deactivation : ユーザーの有効・無効を柔軟に切り替えられるため、一定期間後に復帰予定のアカウント管理に適しています。
2. 管理画面からの「他のすべてのセッションからログアウト」実行
対象ユーザーのプロフィール編集画面（`ユーザー` ＞ `ユーザー一覧` ＞ 該当ユーザー）の下部にある 「他のすべてのセッションからログアウト」 をクリックすることで、そのユーザーが別端末で保持しているセッションCookieを破棄させることができます。
3. メールアドレスとパスワードの強制上書き
プラグインを追加できない環境では、管理者がユーザープロフィールを開き、メールアドレスを自社管理用のアドレスに変更したうえで、長大なランダムパスワードを再設定します。前任者にパスワードを通知しなければ、ログインは完全に遮断されます。
—
### 「購読者」または「寄稿者」への権限ダウングレードによる最小権限の原則
アカウントを保持する場合、 権限グループを「購読者（Subscriber）」へ即座にダウングレードする のが確実な安全策です。
「購読者」権限には以下の制約があります。
– 管理画面にアクセスしても、サイト設定、テーマ、プラグイン、投稿一覧などの業務データは一切表示されない
– 記事の新規執筆、既存コンテンツの変更、画像のアップロードは一切行えない
– 自身のプロフィール情報の確認・変更のみ可能
万が一パスワード変更に不備があり前任者がログインできたとしても、権限が購読者になっていれば、サイトの改ざんや情報閲覧は不可能です。
退職や契約終了の連絡を受け取った際は、まず第一歩として「権限を購読者に落とす」初動対応を習慣化しましょう。
参考リンク：[WordPressユーザー権限グループ完全セキュリティガイド](https://blog.mozcheck.jp/2026/10/15/wordpress-user-roles-security-guide/)
—
## 引き継ぎ完了後に実施すべきサイトヘルス監査とセキュリティスキャン
アカウントの整理と権限変更が完了したら、最後にサイト全体のセキュリティ健全性を監査します。過去の開発段階で仕込まれた不要なファイルや、潜在的な脆弱性が残っていないかを確認するためです。
—
### バックドアや不審な新規PHPファイルが混入していないかの検証
外部の開発会社やフリーランスが携わっていたサイトでは、稀に検証用として認証を迂回できるスクリプト（バックドアやWebシェル）がサーバー内に残存しているケースがあります。
以下のチェックを行ってください。
1. `wp-content/uploads/` ディレクトリ内のPHPファイル検査
画像ファイル用である `uploads` ディレクトリ内に、拡張子が `.php` のファイルが存在していないか確認します。このディレクトリにPHPファイルが存在する場合、不正アクセスの痕跡である可能性が極めて高いため、即時隔離・削除が必要です。
2. セキュリティスキャン・プラグインの実行
Wordfence Security や Sucuri Security などのセキュリティプラグインを使い、整合性スキャンを実行します。公式リポジトリのオリジナルファイルとサーバー上のファイルが自動比較され、改ざんや未知のファイルが検出されます。
3. WordPress「サイトヘルス」の確認
管理画面の `ツール` ＞ `サイトヘルス` を開き、致命的なセキュリティ警告や非アクティブな古いテーマ・プラグインが放置されていないか確認します。
—
### MozCheckなどの無料脆弱性診断ツールによる設定チェック
サーバー内部の点検に加え、 「第三者の攻撃者からサイトがどう見えているか」という外部視点でのセキュリティ監査 も欠かせません。
Webサイトのセキュリティ状態を客観的に確認できる無料ツールとして、 MozCheck（モズチェック） の利用をおすすめします。
MozCheckでは、サイトURLを入力するだけで以下の重要項目を瞬時に診断できます。
– WordPress本体やプラグインのバージョン露出の有無 （バージョン情報が外部から見える状態だと、既知の脆弱性を狙われやすくなります）
– セキュリティHTTPレスポンスヘッダーの設定状況 （HSTS、X-Frame-Options、Content-Security-Policyなどの適切な設定有無）
– SSL/TLS暗号化の健全性と証明書の有効期限
– ログイン画面（`/wp-admin`等）の保護状態
引き継ぎ直後にMozCheckで診断を実行し、現状のセキュリティスコアを記録しておくことで、新任管理者が安全な状態でサイトを引き継いだという客観的なエビデンスを残すことができます。
社内報告や今後の改善計画を立てる際にも大いに役立ちますので、ぜひ定期的に診断を実施してください。
—
## まとめ：チェックリストを活用した属人化解消と定期棚卸しの定着
WordPress管理者の引き継ぎは、これまでのセキュリティ上のリスクを洗い出し、堅牢な運用体制を再構築するための重要な機会です。
属人化した管理体制を放置していると、将来のトラブル時に対応できなくなるリスクが高まります。Webマスターや情シス部門は、今回の手順をもとに 「定期的なアカウント棚卸し（四半期または半期に1度）」を組織の運用ルールとして定着 させましょう。
最後に、社内ドキュメント（Notion、Confluence等）やタスク管理ツールにそのまま貼り付けて利用できる 「実務用セキュリティチェックシート」 を掲載します。引き継ぎや定期監査の実務にぜひお役立てください。
—
### 【コピペで使える】WordPress管理者引き継ぎ・退職時セキュリティチェックシート
以下のMarkdownテキストをコピーしてご活用ください。
“`markdown
### WordPress管理者引き継ぎ・退職時セキュリティチェックシート
#### 1. 事前準備・バックアップ（作業前必須）
– [ ] サイト全体のフルバックアップ（ファイル一式およびMySQLデータベース）を取得したか
– [ ] バックアップデータが正常にダウンロードできているか確認したか
– [ ] 記事引き継ぎ用の受け皿アカウント（新任管理者または「編集部」等のアーカイブアカウント）を用意したか
#### 2. アカウント棚卸しと権限移譲
– [ ] 「ユーザー一覧」を開き、全登録アカウントの稼働状況を確認したか
– [ ] 不要なテストアカウント、元制作会社のアカウントを洗い出したか
– [ ] 1つの管理者アカウントの複数人共有を廃止し、1人1アカウントにしたか
– [ ] 退職者アカウント削除時、必ず「すべてのコンテンツを以下のユーザーのものにする」を選択して記事消失を防いだか
– [ ] アカウントを残す場合は、権限グループを「購読者」へダウングレードしたか
– [ ] 前任者アカウントの登録メールアドレスとパスワードを管理者側で変更したか
#### 3. 認証・ログインセキュリティの強化
– [ ] 継続利用する全管理者アカウントのパスワードを16文字以上の強力なパスフレーズへ刷新したか
– [ ] 前任者の端末に設定されていた2要素認証（2FA）の登録を解除したか
– [ ] 新任管理者のデバイスで2要素認証（2FA）を設定し、緊急用バックアップコードを安全に保管したか
– [ ] wp-config.php の認証用ソルト（AUTH_KEY等）を再生成し、全ユーザーのログインセッションを強制切断したか
#### 4. サーバー・インフラ・外部連携の権限変更
– [ ] サーバー管理パネル（cPanel、Xserver等）の管理者パスワードと通知先メールアドレスを変更したか
– [ ] SSHの `authorized_keys` から前任者・元制作会社の公開鍵を削除したか
– [ ] 不要なSFTP / FTP接続アカウントを削除し、新規アカウントを発行したか
– [ ] データベース（MySQL）の接続パスワードを変更し、wp-config.php の記述と正常に同期させたか
– [ ] Google アナリティクス（GA4）、Search Consoleの管理者権限を移譲し、前任者を削除したか
– [ ] 外部API（Google Maps、SMTPメール配信、AWS、決済Webhook等）のキーを再発行したか
#### 5. 引き継ぎ完了後の健全性チェック
– [ ] WordPressの「サイトヘルス」で致命的なセキュリティ警告が出ていないか確認したか
– [ ] wp-content/uploads/ 等に不審なPHPファイルが存在しないかスキャンしたか
– [ ] MozCheck（無料脆弱性診断ツール）を実行し、外部からのセキュリティ設定に不備がないか確認したか
“`
—
#### WordPressセキュリティをさらに強化するための関連記事
Webサイトの防衛には、日常的な権限管理や多層防御の継続的な実施が不可欠です。さらにセキュリティを強化したい場合は、以下の解説記事もあわせてご参照ください。
– ユーザー権限グループの安全な役割分担 :
[WordPressユーザー権限グループ完全セキュリティガイド](https://blog.mozcheck.jp/2026/10/15/wordpress-user-roles-security-guide/)
– 不正ログインを根本から遮断する二要素認証 :
[WordPress 2要素認証（2FA）完全導入ガイド](https://blog.mozcheck.jp/2026/09/11/wordpress-two-factor-authentication-guide/)
– wp-config.phpの保護とファイル編集の無効化 :
[WordPress wp-config.php設定・セキュリティ・トラブルシューティング完全ガイド](https://blog.mozcheck.jp/2026/09/02/wordpress-wp-config-php-setup-security-troubleshooting-guide/)
コメントを残す