前任者が作った会社のWordPressは大丈夫? 引き継いだら最初に見る10項目

標準の点検画面だけでは、大丈夫かは判断できません。更新が止まったサイトを再現すると、契約名義・管理者・メールの宛先・バックアップには警告が出ませんでした。この4つを今週中に見て、PHP と本体、プラグインの順に更新します。

サイトを作った社員がすでに辞めていたり、知人のフリーランスに頼んだきりで管理画面に一度も入ったことがなかったりする会社は、珍しくありません。パスワードは引き継ぎのメモに1行あるだけ、という場合もあるでしょう。そんな状態で会社の WordPress のサイトを任されると、まず「詳しい人がいないまま作られたうちのサイトは大丈夫か、どこから見ればいいか」が気になります。

ここでは、その問いに10項目で答えます。項目ごとに、管理画面やサーバーのどこで確かめるかと、×だったときに誰に何が起きるかを書き、優先度を3段階に分けました。順番を決めるために、手元のパソコンに「数年前に作られて更新が止まったサイト」を再現し、WordPress に標準で入っている点検画面(サイトヘルス)がどこまで拾うかも確かめています。その結果、警告が出たのは PHP や本体の更新まわりだけで、管理者の数やメールの宛先、バックアップについては何も表示されませんでした。

標準の点検画面を見るだけでは、大丈夫かどうかは判断できません。最初の1週間で、会社が自分で管理できる状態かどうかを4項目で確かめます。ドメインとサーバーの契約名義、管理者のアカウント、通知とお問い合わせフォームの宛先、バックアップです。次の1か月で PHP と WordPress 本体を新しいバージョンに更新し、そのあとでプラグインを更新します。SSL 証明書が自動で更新されるかもこの時期に確かめ、最後に二要素認証とログで入口と記録を固めます。

この記事の要約

先に見るのは「会社で管理できるか」、次に「更新できるか」

基準は、×だったときに後から元に戻せるかどうかです。PHP のバージョンが古いのは、計画を立てて直せます。ところが、ドメインが前任者の名義のまま期限切れになったり、バックアップが無いまま改ざんされたりすると、元に戻すのに長い時間がかかるか、戻せなくなります。そこで、契約と鍵にあたる項目を先に置きました。

優先度項目どこで確かめるか×のとき起きること
A1. とサーバーの契約名義請求書やカードの明細、ドメインを登録した会社とサーバー会社の管理画面更新の連絡が前任者に届き、払われないまま期限が切れるとサイトとメールが止まる
A2. 管理者のアカウントと、使っていないユーザー管理画面の「ユーザー」で「管理者」に絞る退職した人や外部の人がいつでもログインでき、誰の操作か区別できない
A3. 管理者メールアドレスと、フォームの送信先「設定」の「一般」と、フォームのメール設定お客様からの問い合わせが前任者に届き、会社に届かない
A4. バックアップと、実際に戻せるかサーバー会社の管理画面、バックアップ用のプラグイン改ざんや操作ミスのあと、元の状態に戻せない
B5. のバージョン「ツール」の「サイトヘルス」の「情報」タブPHP の欠陥の修正が届かず、プラグインの新しいバージョンも入らない
B6. WordPress 本体のバージョンと自動更新「ダッシュボード」の「更新」本体の欠陥を直す更新が当たらないまま残る
B7. 更新が止まったと「プラグイン」の一覧と、各プラグインの「詳細を表示」直した新しいバージョンが出ていても、更新のお知らせすら出ないことがある
B8. の自動更新ブラウザの鍵のマーク、サーバー会社の管理画面期限が切れると閲覧者に警告画面が出て、フォームも使われなくなる
C9. 各ユーザーの「プロフィール」、入っているプラグインパスワードが漏れると、それだけで管理画面に入られる
C10. ログサーバー会社の管理画面のアクセスログと保存期間何か起きたときに、いつ何をされたかを追えない

表の3列目を見ると、A の4項目は WordPress の外(契約書類やサーバー会社の管理画面)か、管理画面の中でも警告が出ない場所にあります。見に行かない限り、誰も気づきません。C の2項目は×のままだと被害の入口になりますが、A で管理者を減らしたあとのほうが設定する人数が少なく済むので、最後に回しました。次の節で、標準の点検画面が実際にどこまで拾うかを確かめた結果を示します。

標準の点検画面は、優先度 A の4項目に何も警告しなかった

確かめるために、で練習用の WordPress を立て、引き継ぎで起きがちな状態をわざと作りました。インターネットには公開していない、手元だけのサイトです。

項目検証で用意した状態
WordPress 本体6.8.3 のまま、自動更新を止めてある
PHP8.1(公式の修正の提供は2025年12月31日で終わった)
プラグインお問い合わせフォームの Contact Form 7 を古いバージョンの 5.9.8 で使い、ほかに停止中のプラグインが2つある
ユーザー管理者が4人(前任者にあたる外部の制作担当、総務、2023年に退職した人、名前の無いテスト用)と、編集者が1人いる
メールの宛先管理者メールアドレスとフォームの送信先が、どちらも前任者のアドレスになっている

表のように更新が止まった状態のまま、2026年10月11日に「ツール」の「サイトヘルス」を開きました。サイトヘルスは WordPress に標準で入っている点検画面で、見つけた問題を「致命的な問題」と「おすすめの改善」に分けて表示します。

WordPress の管理画面のサイトヘルス。改善が必要の表示の下に、致命的な問題1件(バックグラウンド更新が想定通りに動作していません)と、おすすめの改善6件(WordPress の更新が可能、停止中のプラグインを削除、停止中のテーマを削除、最新ではないバージョンの PHP 8.1.33、HTTPS を使用していません、ページキャッシュ)が並ぶ。
検証用のサイトで開いたサイトヘルス(2026年10月11日撮影)。致命的な問題は自動更新が止まっていることの1件だけだった。

画像の「致命的な問題」1件は、自動更新が止まっていることを指しています。「おすすめの改善」の6件は、本体の新しいバージョン、停止中のプラグイン、停止中のテーマ、PHP 8.1、HTTPS を使っていないこと、表示を速くする仕組みの有無でした。10項目に当てはめると、警告が出たのは PHP、本体、プラグイン、SSL に関係する箇所だけです。しかもプラグインは停止中のものだけ、SSL は HTTPS かどうかだけで、項目で見たい中身の一部にとどまります。検証用のサイトは HTTPS を使っていないので警告が出ましたが、すでに HTTPS で動いている実際のサイトなら、この行も出ません。

一方で、管理者が4人いて、そのうち1人は退職者、1人はテスト用という状態には何も表示されませんでした。管理者メールアドレスとフォームの送信先が前任者のままであることにも、バックアップが1つも無いことにも、警告は出ていません。PHP 8.1 は公式の修正の提供が終わったバージョンですが、入っていたのは「おすすめの改善」のほうでした。サイトヘルスの分類をそのまま優先順位に使うと、優先度 A の4項目がまるごと抜け落ちます。

使っているプラグインには、更新のお知らせが出なかった

予想と違ったのはプラグインの画面です。古いバージョンのお問い合わせフォームを入れたので、一覧には新しいバージョンのお知らせが出るだろうと考えていました。結果は空振りです。停止中のプラグインにはお知らせが付いたのに、使っているお問い合わせフォームの行は空白のままです。

管理画面のプラグイン一覧。停止中の Akismet には新バージョンが利用できますという黄色の帯が出ているが、使用中の Contact Form 7(バージョン 5.9.8)の行には更新の表示がない。
プラグインの一覧(2026年10月11日撮影)。使用中の Contact Form 7 5.9.8 の行には、更新のお知らせが何も出ていない。

お知らせが出ない理由は、Contact Form 7 の行の「詳細を表示」で配布元の情報を開くと分かりました。最新の 6.2.1 は WordPress 7.1 以上と PHP 8.3 以上を必要としていて、画面の上には赤い枠で「新しいバージョンの PHP が必要です」「新しいバージョンの WordPress が必要です」と出ています。

Contact Form 7 の詳細画面。このプラグインには新しいバージョンの PHP が必要です、新しいバージョンの WordPress が必要です、という2つのエラーが表示され、右の欄にバージョン 6.2.1、WordPress の必須バージョン 7.1以上、必須 PHP バージョン 8.3以上と書かれている。
同じプラグインの「詳細を表示」の画面。最新の 6.2.1 には PHP 8.3 以上と WordPress 7.1 以上が要る。

PHP と本体が古いサイトでは、プラグインの新しいバージョンが「入れられないもの」として扱われ、一覧のお知らせから外れていたことになります。WordPress の作りとしては理屈が通っていても、引き継いだ人の目には、更新が必要なこと自体が映りません。お知らせが出ていなくても、最新とは限らないのです。主なプラグインは「詳細を表示」で1つずつ開き、そこに出るバージョンと手元のバージョンを比べてください。もう1つ分かったのは、PHP と本体を新しくしない限り、プラグインも新しくできないという順番です。

優先度 A 今週中に、会社で管理できる状態かを見る

A の4項目は、作業としては難しくありません。要るのは書類探しと、前任者への連絡です。前任者と連絡が取れるうちに済ませておくと、あとの作業がずっと楽になります。

1. ドメインとサーバーの契約名義

ドメインとサーバーの契約は、WordPress の管理画面には出てきません。書類の側で確かめます。場所は、毎年の請求書やクレジットカードの明細、ドメインを登録した会社とサーバー会社の管理画面です。見るのは、契約者が会社の名義になっているか、管理画面のログイン情報を会社が持っているか、更新の連絡がどのメールアドレスに届くかの3点です。

×のときに起きやすいのは、更新の連絡が前任者や制作会社のアドレスに届き、誰も気づかないまま期限が切れることです。ドメインが切れるとサイトが表示されなくなり、同じドメインのメールも届かなくなります。契約者が前任者のままだと、会社から名義の変更や解約を申し込めない場合もあります。

前任者からは、ログイン情報と契約者の情報を受け取り、名義を会社に移してもらうのが近道です。名義を移す手続きはドメインを登録した会社ごとに違うので、管理画面のヘルプか窓口で「登録者の変更」の方法を確かめます。

2. 管理者のアカウントと、使っていないユーザー

管理画面の「ユーザー」を開き、一覧の上にある「管理者」を押すと、管理者だけに絞り込めます。検証用のサイトでは4人です。

管理画面のユーザー一覧を管理者で絞り込んだ画面。seisaku(制作担当、外部)、soumu(佐藤、総務)、tanaka(田中、2023年退職)、test01(名前なし)の4人がすべて権限グループ管理者になっている。
管理者で絞り込んだユーザー一覧(検証用のサイト)。退職者とテスト用のアカウントも管理者のまま残っている。

画像の4人のうち、いま会社に必要なのは総務の1人です。退職した人とテスト用のアカウントは削除し、前任者のアカウントは権限を「編集者」などに下げるか、作業を頼むときだけパスワードを伝えて使ってもらいます。削除の画面では、その人が書いた投稿をどうするかを聞かれるので、「すべてのコンテンツを以下のユーザーのものにする」を選べば記事は消えません。

×のままだと、退職した人や外部の人がいつでもログインでき、誰が操作したのかを区別できません。WordPress の一覧には最後にログインした日時の列が無く、使われていないアカウントかどうかを画面だけでは判断できないことも、検証で分かりました。IPA の「安全なウェブサイトの運用管理に向けての20ヶ条」も、不要なアカウントが登録されていないかを点検項目に挙げています。人が抜けるときのアカウントの止め方は、FDE を迎える前に情シスが用意するものの記事の退場手順も参考になります。

3. 管理者メールアドレスと、フォームの送信先

「設定」の「一般」にある「管理者メールアドレス」は、WordPress がサイトの管理の連絡を送る宛先です。自動更新の結果や、サイトに不具合が起きたときの知らせがここに届きます。検証用のサイトでは、前任者のアドレスのままにしておきました。

設定の一般の画面。管理者メールアドレスの欄に seisaku@example.com と入っており、変更すると確認のため新しいアドレスにメールを送信するという説明が出ている。
「設定」の「一般」の管理者メールアドレス(検証用のサイト)。

お問い合わせフォームの送信先は、これとは別の場所にあります。今回のプラグインでは「お問い合わせ」からフォームを開き、「メール」のタブにある「送信先」です。ここも前任者のアドレスでした。

Contact Form 7 のフォーム編集画面のメールタブ。送信先の欄が seisaku@example.com になっている。
フォームの「メール」のタブの送信先(検証用のサイト)。管理者メールアドレスを直しても、ここは別に直す必要がある。

2つの画像のとおり、宛先は管理画面の2か所に分かれています。片方を直しても、もう片方には古い宛先が残ります。そのままでは、お客様からの問い合わせが前任者に届き、会社には届きません。管理者メールアドレスは、変えると新しいアドレスに確認のメールが届き、確認が済むまで切り替わらない仕組みです。直したら、自分でフォームから1通送ってみてください。会社のアドレスに届けば完了です。

4. バックアップと、実際に戻せるか

WordPress 本体には、サイトを丸ごと保存して戻す機能が入っていないので、確かめる場所はサーバー会社の管理画面(自動のバックアップがあるか、何日分残るか)と、バックアップ用のプラグインが入っているかです。

見るべきは、あるかどうかより、戻せるかどうかです。WordPress の公式ドキュメントは、データベースを定期的に、更新の前には必ずバックアップし、少なくとも3つを別々の場所に置くよう勧めています。サーバー会社のバックアップしか無い場合、契約が前任者の名義だと戻す操作ができないので、項目1と一緒に確かめます。サーバー会社と前任者に聞くことは次の3つです。

  • サーバー会社の自動バックアップは何日分残り、誰の操作で戻せるか
  • バックアップ用のプラグインがある場合、保存先はサーバーの中か外か
  • 最後に戻す練習をしたのはいつか

×のときは、改ざんや更新の失敗、操作ミスのあとに元へ戻せません。このあとの優先度 B の作業(PHP や本体の更新)も、戻せる状態を作ってからでないと始められないので、A の最後に置きました。

優先度 B 今月中に、古くなった部分を更新する

B の4項目のうち、PHP、本体、プラグインの3つはつながっています。検証で見たとおり、PHP と本体が古いとプラグインの新しいバージョンが入らないので、PHP と本体を更新してからプラグインを更新します。検証のサイトでは本体の更新が PHP 8.1 のままでも案内されましたが、PHP と本体のどちらを先にするかは、使っているテーマとプラグインが新しい PHP で動くかをサイトの複製で試してから決めます。どの段階でも、項目4のバックアップを取ってから進めてください。

5. PHP のバージョン

PHP のバージョンは、「ツール」の「サイトヘルス」で「情報」タブを開き、「サーバー」の欄にある「PHP バージョン」の行で分かります。

サイトヘルスの情報タブのサーバー欄。PHP バージョンの行に 8.1.33 と表示されている。
サイトヘルスの「情報」タブの「サーバー」(検証用のサイト)。PHP バージョンは 8.1.33。

画像の 8.1 は、PHP の公式サイトによると2025年12月31日で修正の提供が終わりました。8.2 も残りわずかで、2026年12月31日までです。WordPress の公式サイトは PHP 8.3 以上を勧めていて、7.4 以上でも動くものの、公式のサポートが終わったバージョンはサイトを脆弱性にさらす可能性があると書いています。バージョンごとの期限は次の表のとおりです。

PHP のバージョン公式の修正の提供
8.12025年12月31日に終了
8.22026年12月31日まで
8.32027年12月31日まで
8.42028年12月31日まで
8.52029年12月31日まで

表の上の2行に当てはまるなら、サーバー会社の管理画面で PHP のバージョンを切り替えることになります。ただ、いきなり本番で切り替えると、古いテーマやプラグインが動かなくなるかもしれません。サーバー会社が用意する検証用の環境やサイトの複製で先に試すのが安全です。自分で進めにくいと感じたら、ここは制作の経験がある人に頼む部分です。

6. WordPress 本体のバージョンと自動更新

「ダッシュボード」の「更新」を開くと、一番上にいまのバージョンと、自動更新を受け取るかどうかが出ます。検証用のサイトでは、現在のバージョンが 6.8.3 で、「このサイトは新しいバージョンの WordPress の自動更新を受け取りません」と表示されました。

WordPress の更新画面。現在のバージョン 6.8.3、このサイトは新しいバージョンの WordPress の自動更新を受け取りません、という表示の下に、バージョン 7.1.3-ja に更新するボタンが出ている。
「ダッシュボード」の「更新」(2026年10月11日撮影)。案内されるのは 7.1.3 への更新だけ。

画像では 7.1.3 への更新が案内されています。ただし、画面に出ない差もあります。WordPress のリリース一覧を見ると、6.8 の系列だけでも 2026年10月6日の 6.8.11 まで欠陥を直す更新が出ていて、自動更新を止めたこのサイトは 6.8.4 からの8回分を受け取っていません。同じ一覧には「7.1 シリーズの中で最新のもののみが安全に使用でき」るとあります。6.8 の系列の更新だけでは足りません。目指すのは 7.1 の最新です。

自動更新を止めた理由が、テーマの改造を守るためだった、というように説明のつく場合もあります。理由が分からないまま元に戻すと表示が崩れることがあるので、項目4で戻せる状態を作り、複製で試してから本体を更新します。

7. 更新が止まったプラグインとテーマ

プラグインは、前の節で見たとおり一覧のお知らせだけでは判断できません。主なものを「詳細を表示」で開き、最新のバージョン、最終更新、必要な PHP と WordPress のバージョンを、手元と比べます。最終更新が何年も前のものは作者が更新をやめている可能性があり、別のプラグインへ移るかを考えます。

停止中のプラグインとテーマも、ファイルが残っている限り、欠陥を抱えたままサーバーに置かれています。検証のサイトヘルスも、停止中のプラグインとテーマの削除を勧めていました。使っていないと確かめたものは削除し、テーマは使っているもののほかに標準のテーマを1つ残しておくと、表示が壊れたときに切り替える先になります。

×のままだと、直した新しいバージョンが出ている欠陥が、自社のサイトには残ったままになります。WordPress で見つかる欠陥の大半がプラグインから出ていることは、WordPress のセキュリティを見直す記事に数字とともにまとめました。

8. SSL 証明書の自動更新

サイトのアドレスが https で始まるのは、SSL 証明書が入っているためです。確かめる場所は、ブラウザでアドレスの横の鍵のマークから見られる証明書の有効期限と、サーバー会社の管理画面で証明書が自動で更新される設定になっているかです。

自動で更新されるかどうかは、これから重みが増します。証明書の業界団体である CA/Browser Forum は2025年4月、証明書の最長の有効期間を398日から段階的に短くし、2029年3月には47日にする決定をしました。短縮はすでに2026年3月から始まりました。年に1回、手作業で入れ替える運用では追いつきません。

×のときは、期限が切れた時点で閲覧者のブラウザに警告の画面が出て、多くの人はそこで閲覧をやめてしまいます。フォームからの問い合わせも、その日から届かなくなるでしょう。検証のサイトヘルスが見ていたのは HTTPS かどうかだけで、期限や自動更新の設定は表示に出ませんでした。期限の確認は人の目で行います。

優先度 C 管理者を減らしてから、入口と記録を固める

C の2項目は、A で管理者を減らしたあとのほうが手間が少なく済みます。管理者が1人になれば、二要素認証の設定も1回で終わります。

9. 二要素認証

二要素認証の機能は、WordPress 本体には入っていません。検証用のサイトのプロフィール画面にも、名前や連絡先、アカウント管理などの欄しかありませんでした。確かめるのは、二要素認証のプラグインが入っているか、管理者全員が設定を済ませているかの2点です。プラグインには、WordPress.org が公開している Two Factor などがあります。

×のときは、パスワードが漏れたり推測されたりした時点で、それだけで管理画面に入られます。IPA の20ヶ条も、不正ログインの対策を点検項目に入れています。パスワードや秘密の質問が以前より破られやすくなった事情は、AIに破られやすくなったセキュリティ対策の記事にまとめました。

10. ログ

WordPress の管理画面には、誰がいつログインしたかの履歴がありません。項目2で見たユーザー一覧にも、最後のログインの列はありませんでした。記録は主にサーバーの側に残ります。サーバー会社に確かめるのは次の3点です。

  • アクセスログを管理画面から見られるか
  • 何日分残るか
  • ログをダウンロードして、社内に保存できるか

WordPress の公式ドキュメントは、ログからはログインしたユーザー名までは分からないものの、通信元と時刻、行われた操作を追えると説明しています。IPA の20ヶ条も、ウェブサーバのログを保管し、定期的に確認することを挙げています。

×のときは、改ざんに気づいても、いつから、どこから入られたのかを追えず、どの時点まで戻せばよいかも決められません。何か起きたときに誰が何をするかを先に決めておく考え方は、本番のAIが誤った請求書や回答を出したときの手順の記事が参考になります。題材は AI ですが、気づいてから影響の範囲を確かめ、記録を残す流れは同じです。

×が多かったら、自分でやることと頼むことを分ける

10項目を見て×が多くても、一度に全部を直す必要はありません。急ぐのは優先度 A だけです。自分で進められるのも、契約書類の確認、前任者への連絡、使っていないアカウントの削除、宛先の変更といった A の大部分です。前任者には、経緯を問いただすより、次のものを受け取ることを先にお願いしてください。

  • ドメイン、サーバー、WordPress のログイン情報
  • 契約者の名義と、次の更新日
  • 入れたプラグインと、テーマを改造した箇所
  • バックアップの場所と戻し方
  • 自動更新を止めていた場合は、その理由

一方で、PHP の切り替え、更新で崩れた表示の修正、改造されたテーマの改修、更新が止まったプラグインの入れ替えは、作業そのものより「壊れたときに戻す」準備に手間がかかります。ここで手が止まったら、無理に進めず、制作の経験がある人に任せたほうが早く終わります。

覚えのない管理者やページなど、改ざんの跡らしきものを見つけても、慌てて消さないでください。先に画面を記録し、それからサーバー会社や制作の経験がある人に相談します。消してしまうと、いつ何が起きたのかを追う手がかりも一緒に消えます。

見つかった箇所の修正と、サイトの作り直しをお受けしています

はてなベースは、点検で×が付いた箇所の修正や、古くなったサイトの作り直しをお受けしています。PHP や WordPress を更新すると表示が崩れる、改造されたテーマが古いバージョンでしか動かない、といった場合もご相談ください。

修正・作り直しについて詳しく見る