保守しているホームページ7つを、外から点検してみたら出てきたもの。自社サイトにも1件ありました

10月から、保守を預かっているホームページと自社サイトを、毎月1日に外から点検する仕組みを始めました。初回は12か所（ホームページ7つと、LINEの予約・業務管理の仕組み5つ）を見て、直したほうがよいものが9件、できれば直したいものが22件、見つかりました。

先に結論です。どのサイトも「落ちている」「乗っ取られている」といった大ごとは1件もありませんでした。 出てきたのは、更新の遅れ、設定の抜け、外から見えなくてよい情報が見えている、という地味なものばかりです。ただ、地味なものが積み重なった先に大ごとが起きます。そして、その1件は自社サイトにもありました。

この記事では、何を見たか、何が出たか、どれから直したかを、そのまま書きます。

きっかけ

きっかけは、2026年10月に読んだ、サイバー攻撃についての提言記事です。要点は「AIで攻撃が安く、無差別になった。弱点が公表されてから悪用されるまでの時間も短くなった。年1回の点検では間に合わない」というものでした。

当社が保守しているのは、整骨院、塗装会社、小売店といった中小企業のサイトです。「うちは狙われるほどの会社じゃない」と言われることが多いのですが、無差別に機械で探される時代には、会社の大小は関係ありません。鍵のかかっていない家から順に入られるだけです。

それなら、毎月1回、外から鍵がかかっているかを見て回ろう、と決めました。

最初に：「外から見える範囲」だけを点検する

点検は2種類に分けました。

種類	見るもの	頻度
外からの点検	誰でも見られる情報だけ。ログインしない	毎月1日（自動）
中からの点検	管理画面の中の設定、バックアップの有無など	3か月に1回（手作業）

この記事で書くのは前者です。やっていることは、お客さまのサイトを、ふつうの閲覧者と同じ方法で開いて、応答を読むだけです。ログインを試したり、弱点を突いたりはしません。1サイトあたりの閲覧は十数回、間隔は0.4秒あけています。

用語は3つだけ

• 証明書：ホームページの通信を暗号化するための、期限付きの証明です。切れると、ブラウザに「安全ではありません」と出ます。
• プラグイン：WordPress（ホームページを編集する仕組み）に後から足す追加機能です。問い合わせフォームや画像の圧縮など。これにも更新があります。
• ユーザー一覧API：WordPressが持っている、外からユーザー情報を返す仕組みです。設定によっては、ログイン名が外から見えます。

手順0：何を点検項目にしたか

外から見える範囲で、次の10項目を見ることにしました。

1. サイトが応答するか
2. 証明書の残り日数
3. httpで開いたときに、httpsへ転送されるか
4. ブラウザに渡す安全のための指示（セキュリティヘッダ）があるか
5. 使っているソフトのバージョンが外から見えていないか
6. WordPress本体が最新か
7. プラグインに更新の遅れがないか
8. 出てはいけないファイル（設定ファイルや記録ファイル）が外から読めないか
9. ユーザー一覧APIからログイン名が取れないか
10. 使っていない古い入口（xmlrpc.phpなど）が開いていないか

結果は3段階で分けます。❌は今すぐ直す、⚠️は直したほうがよい、💡はできれば直したい、です。

手順1：初回の結果【12か所・2026年10月13日】

結果	件数
❌ 今すぐ直す	0件
⚠️ 直したほうがよい	9件
💡 できれば直したい	22件
✅ 問題なし	38件

❌が0件だったのは、正直ほっとしました。出てはいけないファイルが読める、証明書が切れている、サイトが落ちている、は1件もありませんでした。

一方で⚠️の9件は、次の内訳でした。

内容	件数	何が起きるか
WordPress本体が古い	2サイト	公表済みの弱点が残ったままになる
プラグインに更新の遅れ	3サイト（合計8個）	同上。フォームや表示系の追加機能に多い
ユーザー一覧APIからログイン名が取れる	3サイト	総当たりでパスワードを試すときの手がかりになる
httpで開くとhttpsに転送されない	1サイト	古いリンクから来た人が、暗号化なしで閲覧する

💡の22件はほとんどが「ブラウザへの安全の指示が未設定」「WordPressのバージョンが外から見える」「使っていない古い入口が開いている」の3種類でした。

手順2：自社サイトも同じ結果だった【当社のサイト】

ここが今回いちばん書いておきたいところです。

自社サイトも、ユーザー一覧APIからログイン名が1件取れる状態でした。 恥ずかしい話です。 お客さまのサイトで「直したほうがよい」と言っている項目が、自分のところで抜けていた。点検の仕組みを作って最初に出た結果が、これです。

言い訳をすると、自社サイトは今年の夏に作り直したばかりで、設定を1つずつ確認していたつもりでした。それでも抜けます。人が目で見る点検は、こういうところを漏らします。だから機械で毎月回す意味があるのだと、自分のサイトで思い知りました。

この1件は、記事を書く前に直しました。ログインしていない人には、ユーザー情報を返さない設定にしています。直した日時と確認結果は、この記事の最後に書きます。

手順3：直す順番を決める【各サイトの管理画面】

9件の⚠️を、次の順番で直すことにしました。

1. ユーザー一覧APIの非公開化（3サイト）：設定だけで済み、表示に影響しない。最初に
2. httpからhttpsへの転送（1サイト）：サーバーの設定1か所。表示への影響なし
3. プラグインの更新（3サイト）：フォームや表示が変わる可能性があるので、更新前にバックアップを取り、更新後に問い合わせフォームの送信テストをする
4. WordPress本体の更新（2サイト）：いちばん影響が大きいので最後。こちらもバックアップ→更新→表示とフォームの確認

順番の理由は「影響が小さいものから」です。更新で表示が崩れると、お客さまにとっては「点検されて壊された」になります。点検は守るためのものなので、直す作業で壊しては本末転倒です。

手順4：お客さまにどう伝えるか【月次レポート】

点検の結果は、毎月お送りしている保守のレポートに「セキュリティ」の欄を足して載せることにしました。料金は据え置きです。

伝え方で決めたのは1つだけです。⚠️はこちらで直してから「対応しました」として書く。 「あなたのサイトにこんな弱点があります」とだけ伝えても、お客さまは不安になるだけで、何もできません。保守を預かっている側が直して、結果を報告する。それが保守料に含まれるべきだと考えました。

つまずき早見表

起きたこと	原因	どうしたか
有料テーマや自作の追加機能が「更新遅れ」と誤って出た	公式の配布サイトにある同名の機能と比べていた	対象ごとに「比較しない機能」を指定できるようにした
保守の範囲外のサイトまで点検していた	台帳に載せる基準を決めていなかった	「有償で保守しているもの」だけに絞り、1件を対象から外した
「バージョンが外から見えない」サイトの更新状況が分からない	外からの点検では判定できない	管理画面の中を見る四半期の点検に回した
自社サイトで⚠️が出た	作り直したときの設定漏れ	記事を書く前に直した

確認方法

ご自身のサイトで、いますぐ確かめられるものを2つだけ挙げます。

1. ブラウザで、サイトのURLの後ろに /wp-json/wp/v2/users を付けて開く。 WordPressのサイトで、ログイン名らしき文字列が表示されたら、外から見えています。何も出ない、またはエラーが出れば大丈夫です。
2. URLの https:// を http:// に変えて開く。 自動で https:// に戻れば大丈夫です。戻らずそのまま開く場合は、転送の設定が抜けています。

どちらも、制作会社か保守会社に「直してほしい」と伝えれば、設定だけで済む作業です。

正直に書いておくこと

• 外からの点検で分かるのは、鍵がかかっているかどうかまでです。中に誰かが入っているか、バックアップが取れているかは分かりません。そちらは3か月に1回、管理画面の中を見ます。
• 💡の項目は、直しても目に見える変化はありません。優先度は低く、⚠️をすべて直してから順に手を付けます。
• この点検で「安全」とは言い切れません。点検していない日に新しい弱点が公表されることもあります。できるのは、放置の期間を1年から1か月に縮めることです。
• 初回の⚠️9件のうち、記事を書いている時点で直せたのは自社の1件です。お客さまのサイトは、更新作業の日程を調整しながら、上の順番で進めています。

要点3行

• 外からの点検は、ログインせずに「鍵がかかっているか」を見るだけ。それでも12か所で⚠️9件・💡22件が出た
• 出てきたのは地味なものばかり。更新の遅れ、転送の抜け、ログイン名の露出。大ごとになる前の段階で見つけるのが目的
• 自社サイトにも1件あった。人の目の点検は漏れる。だから機械で毎月回す

追記：自社サイトの修正記録

• 2026年10月23日、ログインしていない閲覧者にユーザー情報を返さない設定を入れました。
• 確認：ユーザー一覧APIを外から開くと、修正前はログイン名が返っていましたが、修正後は「見つかりません」の応答（404）になりました。記事の一覧を返す仕組みはそのまま動いていて、表示や問い合わせフォームには影響ありません。