放置した自社サイト、大丈夫？ 不正アクセスを防ぐWebサイト点検30項目【無料PDF】

会社のホームページを引き継いで開いてみると、最後のお知らせは3年前。ページは表示され、問い合わせフォームもあります。ただ、前任者は退職済み。制作会社が今も更新しているのか、バックアップがあるのかは分かりません。

こんなとき、どこから確認すればよいのでしょうか。

最初に調べるのは、自社が管理するサイトの一覧、保守の担当、ソフトウェアの更新状況です。 お知らせが古いことだけでは、不正アクセスの危険度は判断できません。反対に、画面が普段どおりに表示されても、管理用アカウントや更新の状態まで確認できたことにはなりません。

この記事では、会社サイトの点検を30項目に分け、「どこを見るか」「何を記録するか」「分からないときは誰に聞くか」を説明します。WordPressを使う場合の画面も紹介しますが、静的サイトや外部サービスで作ったサイトにも使える確認項目を含めています。

新人社員：お知らせが3年前で止まっています。もう危ないサイトですか？

R.A.I：お知らせの日付だけでは判断できません。サイトを動かすソフトウェアの更新と、保守の担当・記録を確かめましょう。

冒頭は架空の引き継ぎ例です。R.A.Iは株式会社レイズの公式AIキャラクターで、記事では新人社員の疑問に答える案内役として登場します。

管理状況を先につかみたい方は、最初に確認する8項目へ進んでください。

点検の前に、確認先と記録の付け方を決める

公開画面、管理画面、保守会社を使い分ける

Web担当になったからといって、すべての設定を自分で変更する必要はありません。自分が見られる範囲を確認し、管理権限が必要な項目は担当者へ依頼します。

例えば、フォームを正常に送れたことは動作確認の結果です。入力内容をサーバーでどう処理しているかまで確認した結果ではありません。IPAも「ウェブ健康診断仕様」の説明で、検査パターンを絞った診断では、脆弱性が検出されなくても安全を宣言できないとしています。IPA：安全なウェブサイトの作り方・ウェブ健康診断仕様

新人社員：見た目が普通なら、ひとまず確認済みでいいですか？

R.A.I：表示の確認は一つの材料です。管理者や更新、復元の状態は、管理画面や保守担当の記録でも確かめます。

「不明」を残せる四つの状態で記録する

PDFと点検票では、次の状態を使います。確認した人、日時、画面・資料の参照先も一緒に残してください。

一つの項目に複数の確認点がある場合は、必要な根拠がそろうまで確認済みにしません。既知の不備と不明点が両方あれば「要対応」とし、不明点も併記します。「制作会社しか分からない」は該当なしではなく、不明です。

選び方に迷ったら、次の例を参考にしてください。いずれも記入方法を説明するための架空例です。

後から資料が見つかり「不明→確認済み」になった場合は、確認した資料と日付を残します。設定を直した場合は、変更内容と再確認の結果も残してください。点検で分かったことと、実際に行った作業の両方を追える記録にします。

最初は8項目で管理状況をつかむ

いきなり30項目を調べきれないときは、01 対象URL、02 担当と保守範囲、06 CMS本体、07 プラグイン、11 管理用アカウント、13 多要素認証、18 非公開ファイル、26 バックアップから確認してください。サイトが何で動き、誰が操作でき、どこまで戻せるかを把握する入口になります。

これは、どのサイトでも同じ危険度順になるという意味ではありません。例えば、顧客情報が公開されていると分かった場合は、その対応を優先します。

この表で状況をつかんだら、各章のチェックリストで残る確認点を埋めます。WordPress以外のサイトでは、利用サービスの管理画面や保守担当への質問に読み替えてください。

管理画面に入れないときは、契約と引き継ぎ先を探す

ログイン情報が分からなくても、点検は始められます。契約書、請求書、制作時の納品資料、社内の保管記録から、サーバーやドメインの契約先と管理担当を探してください。

会社の所有・管理権限を確認できる担当者が、事業者の正式な窓口へ回復や引き継ぎを依頼します。点検票には、確認できていない項目、問い合わせ先、依頼日、回答期限を残します。IDやパスワードを推測して繰り返し試す必要はありません。

侵入を疑う事実があれば、初動対応へ切り替える

見覚えのない管理者、書き換えられたページ、身に覚えのない転送、顧客情報の公開が見つかったら、対象・時刻・見えた事実を責任者へ伝えます。保守のつもりでログを削除したり、バックアップで上書きしたりせず、管理者が拡大防止と記録保全を進めてください。

対応の進め方は、不正アクセス・情報漏えいが疑われたときの初動対応マニュアルで説明しています。

STEP1 自社サイトの範囲と管理者を洗い出す

本体以外のサイトも、URLと用途を並べる

会社のトップページだけでなく、採用、キャンペーン、旧サイト、検証用サイト、外部の問い合わせフォームも確認します。まず、ドメインやDNSの管理画面、サーバー契約、制作資料を集め、社内の利用担当と照合してください。DNSは、ドメイン名と接続先などを対応付ける設定です。

検索結果に出るURLだけでは、管理対象の一覧は完成しません。検索に出ない検証用サイトや、他部署が契約した外部サービスが残っている場合もあります。「このURLは何のためにあるか」「誰が使っているか」を一つずつ確認します。

台帳には、URL、用途、構成、社内担当、保守先、扱う情報の種類を書きます。問い合わせ内容がメールと管理画面の両方に保存される場合は、双方の管理担当を確認してください。顧客の実データやパスワードを台帳へ書く必要はありません。

保守費を払っている場合も、作業範囲を見る

契約書や見積書を開き、CMS・部品・サーバーの更新、バックアップ、緊急対応の分担を確認します。「月額保守」の名前だけで、すべて含まれるとは判断しません。

制作会社へは「何を、いつ、誰が更新していますか。直近の記録はありますか」と質問します。担当が決まっていない作業は、社内責任者が分担と依頼先を決めてください。IPA：安全なウェブサイトの運用管理に向けての20ヶ条

冒頭の新人なら、まず本体と旧キャンペーンサイトを台帳に追加し、それぞれの保守先を調べます。本体の保守契約に、別のサイトや外部フォームまで含まれるとは限らないためです。「担当に聞く」という作業にも、対象URLを付けて渡します。

古いサイトは、停止とドメインの解約を分ける

使っていないサイトが見つかったら、利用中のメール、別サイト、認証情報の回復先などへの影響を調べます。ドメインを手放すと、第三者が再び登録する可能性があります。以前のメールアドレス等が残っていれば、悪用につながるおそれもあります。JPRS：ドメイン名の廃止に関する注意

外部サービスを終了するときは、そのサービスを指すDNS設定も確認します。接続先だけ廃止し、DNSを残したままにすると、構成によっては第三者に悪用される可能性があります。管理者が依存関係と変更順を確認し、終了後の状態まで記録します。Microsoft：サブドメイン乗っ取りの防止

新人社員：使っていないサイトは、ドメインごと解約してよさそうですね。

R.A.I：同じドメインのメールや、アカウントを回復する宛先に使っていないか先に調べましょう。サイトを閉じることと、ドメインを手放すことは分けて判断します。

対象と管理体制のチェックリスト 01〜05

STEP2 CMSと部品の更新状況を確認する

本体、プラグイン、テーマを別々に見る

CMSは、管理画面からページなどを更新する仕組みです。WordPressを使っている場合は、管理者が次の画面を開き、現在の版と更新情報を記録します。

更新画面で本体・プラグイン・テーマの更新を確認できます。名称や表示は権限・構成によって異なるため、見当たらなければ保守担当へ確認してください。WordPress：更新画面

「更新なし」の表示だけで、その部品が今も保守されているとは限りません。提供終了、更新経路の不具合、ライセンスの状態も確認します。不要な部品は、依存関係と戻す方法を確認して削除します。無効化したプラグインや未使用テーマも、一覧から省かないでください。WordPress：セキュリティ強化

サーバー側の版と、修正を受けられる期限を調べる

WordPress本体を更新していても、動作に使うPHPやサーバー側のソフトウェアは別の確認が必要です。管理者へ、製品名、動作中の版、修正を提供する事業者、サポート期限を尋ねます。

例えば、2026年10月24日確認時点では、PHP公式の一覧にPHP 8.2のセキュリティサポート期限が2026年12月31日と記載されています。ホスティング事業者等が独自に修正を提供する場合は、その条件も確認します。「PHP 8」という大きな版だけで判断せず、提供元と期限を記録してください。PHP：サポート対象の版

表示されるバージョンと、修正が適用されているかは分けて確認します。 提供元が元の版番号を維持したまま修正を取り込む場合もあります。保守担当へ、利用中の環境が対象か、提供元の修正告知や作業記録があるか、実際にサイトを動かす環境へ反映されたかを尋ねてください。Red Hat：修正のバックポート

コマンドラインとWebサイトで、異なるPHPが動いている場合もあります。管理者には、コマンドラインで確認した版だけでなく、実際にWebサイトを処理しているPHPの版と修正の反映を確認してもらいます。PHP：コマンドラインでの利用と実行方式

PHPについて保守担当へ聞く質問は、PHPの脆弱性、うちの会社は大丈夫？ホームページ・ネットショップの確認10項目にまとめています。

更新前の準備と、更新後の確認を一組にする

更新が必要なら、保守担当と次の順番で進めます。

1. 対象製品と修正内容、互換性、業務への影響を確認する。
2. 必要なデータを保存し、戻す方法と作業担当を決める。
3. 検証環境などで影響を確かめ、実施手順に沿って更新する。
4. 現在の版、ページ表示、フォーム、ログイン等の必要な機能を確認する。
5. 日時・実施者・結果・残る問題を記録する。

重要な脆弱性の情報が出たときは、定期作業日を待つ前提にせず、対象かどうかと対応の緊急性を確認します。製品の公式情報やJVN iPediaを確認先にしてください。JVN iPedia：脆弱性対策の活用ガイド

新人社員：更新が出ています。全部まとめて押してもいいですか？

R.A.I：保守担当と対象・互換性を確認し、バックアップと戻す方法を用意しましょう。更新後はフォームなど必要な機能も確かめます。

自動更新は、オンになっていることに加え、成功・失敗の通知と実際の版を確認します。WordPressのプラグイン・テーマの自動更新は、実行条件によって動かない場合もあります。通知先と失敗時の担当まで決めてください。WordPress：プラグイン・テーマの自動更新

新人社員：自動更新はオンでした。ここは終わりですね？

R.A.I：実際に成功したかと、現在の版も確認しましょう。失敗通知と更新後の動作まで追える状態にします。

更新と構成のチェックリスト 06〜10

STEP3 管理画面と作業用アカウントを守る

誰が何を操作できるか、一覧で確認する

CMS、サーバー、ドメイン、DNS、外部フォーム等の利用者一覧を開きます。各アカウントに、現在の利用者、用途、必要な権限を対応付けてください。

退職者や契約終了先のID、用途不明の共用ID、不要な管理者権限が残っていないかを確認します。削除や権限変更をするときは、投稿の所有者や自動連携などへの影響も調べます。身に覚えのない管理者がいる場合は、通常の整理だけで終えず、責任者へ報告してください。

アカウントを停止しても、ログイン中の状態や個別に発行した鍵・トークンが使える場合があります。管理者は、不要な認証手段と既存セッションを失効させ、停止した利用者が引き続き操作できないことを確認します。現在の担当者や必要な連携が動くことも一緒に確かめてください。OWASP：セッションの失効

認証と回復先を、会社で管理する

管理用パスワードの使い回しをやめ、作業用の鍵やトークンも利用先・保管先・失効方法を把握します。秘密値は点検票に書かず、会社で利用を認めた安全な保管先で管理します。

対応するサービスでは、多要素認証を適用します。多要素認証は、パスワードだけに依存せず、別の要素も使って本人を確認する仕組みです。登録画面だけで終えず、必要な管理者に適用されているかと、通常のログインを確認してください。

担当者が端末をなくしたり退職したりした場合に備え、回復方法と管理先も決めます。回復コードの内容を記事用の画面写真や点検PDFへ載せてはいけません。OWASP：多要素認証

新人社員：退職した人の管理者IDは、誰も使っていないから残してよいですか？

R.A.I：用途と関連する処理を確認して、不要な権限を整理しましょう。現在の担当者の認証と、会社で管理する回復先も確認します。

管理の入口と、書き換えられる範囲を絞る

保守担当に、管理画面のアクセス制限、ログイン試行の制御、暗号化されたファイル転送、不要な接続経路を確認してもらいます。ログインURLの変更だけで確認を終えないでください。

ファイルやデータベースへの権限も、業務に必要な範囲かを確認します。「動かないから全員が書き込める設定にする」という修正は避け、どの処理にどの権限が必要かを調べます。設定値は環境で異なるため、管理者が変更し、更新・投稿・フォーム等の動作まで確かめます。WordPress：権限と管理経路の保護

管理用アカウントと権限のチェックリスト 11〜15

STEP4 通信と公開している情報を確認する

HTTPSは、主要ページと送信先まで確認する

会社のトップページだけでなく、問い合わせ、ログイン、主要な下層ページを確認します。管理者は証明書の対象・期限、HTTPからの転送、フォームの送信先、読み込む画像やスクリプトの通信も調べてください。

HTTPSは通信を保護します。誰が資料を読めるか、入力処理に問題がないかは、それぞれ別の確認が必要です。OWASP：セッションと通信の保護

新人社員：HTTPSなら、会員資料も外から読まれませんか？

R.A.I：HTTPSは通信を保護します。資料を誰が読めるかは、認証と権限の設定を別に確かめる必要があります。

検索に出ないことと、閲覧できないことを分ける

非公開にしたい資料には、認証と適切な閲覧権限が必要です。管理者が設定を確認したうえで、架空のテスト資料と、未ログイン・権限の異なるテスト利用者を使い、許可していない閲覧が制限されることを確かめます。

noindexは検索結果への掲載を制御する指示、robots.txtはクローラーのアクセスを制御するための仕組みです。URLを知る人の閲覧を制限する代わりにはなりません。Google：robots.txtの概要

新人社員：検索に出ない設定にしたので、資料は非公開ですよね？

R.A.I：検索表示の設定だけでは、URLを知る人の閲覧を制限できません。管理者に公開範囲と閲覧権限を確認してもらいましょう。

設定ファイルやバックアップの置き場所を確認する

サーバー管理者に、インターネットへ公開するディレクトリと、設定ファイル・DBのコピー・鍵・Git等の保管場所を照合してもらいます。外部検査で見つからなかったことだけでは、配置の確認は完了しません。

不要な詳細エラーやファイル一覧が公開されない設定も確認します。通常の404画面や許可された検証環境を使い、利用者向けの表示と管理用ログを分けてください。機密ファイルの公開を発見した場合は、内容を広く転送せず、責任者に連絡して公開制限と初動判断へ進みます。IPA：Webサイトの運用管理

外部タグの提供元と用途を説明できる状態にする

解析、広告、チャット、予約などの外部JavaScriptも管理対象です。制作担当がページのソース、タグ管理画面、ブラウザの通信記録を照合し、読み込み元・用途・管理担当を記録します。

タグ管理サービスを利用している場合は、設定を公開できる人と変更履歴も確認します。サイトのファイルを直接編集しなくても、タグ側の操作で読み込むコードや情報の送信先が変わるためです。広告運用を終了した会社に公開権限が残っていないか、どの変更を誰が確認するかまで、11のアカウント台帳と対応付けてください。

使わなくなったサービスのタグは、必要性と影響を確認して整理します。外部のスクリプトは変更される可能性があり、HTTPSで読み込んでいることだけでは内容の安全性を確認できません。取得内容の整合性を検証するSRI等の対策は、配信方法に合わせて開発担当が検討します。OWASP：外部JavaScriptの管理

通信と公開範囲のチェックリスト 16〜20

STEP5 フォームと防御設定を保守会社へ確認する

送信後の処理を、開発担当へ尋ねる

入力欄の必須設定や、正常な送信だけでは、フォームの確認は終わりません。開発担当へ、対象フォームを示して次の点を確認します。

• 入力内容をサーバー側でも検証しているか。
• データベースの呼び出しで、入力値を命令文として扱わせない実装になっているか。
• 入力内容を画面へ表示する際、その表示場所に合った処理をしているか。

例えばSQLのパラメーター化は、データベースへ渡す命令と入力値を分ける方法です。点検担当者が攻撃文字列を本番へ送るのではなく、開発担当から実装の説明と、許可された環境での確認結果を受け取ります。IPA：安全なウェブサイトの作り方

添付機能がある場合は、必要性、受け付ける種類・容量、内容の確認、保存場所、実行・閲覧権限も確認します。拡張子を制限しただけで完了とはしません。OWASP：ファイルアップロード

ログイン状態と、重要操作の保護を確認する

会員機能などがあれば、ログイン状態を維持するセッションの発行・更新・失効を開発担当に確認します。ログアウトや権限変更後の扱いと、認証用Cookieの保護設定も対象です。Cookieはブラウザが保持する情報で、用途に応じた設定が必要です。OWASP：セッション管理

登録情報の変更や管理操作では、操作権限に加え、第三者のページ等から意図しない操作をさせるCSRFへの対策も確認します。CookieのSameSite属性は対策の一部ですが、その設定だけで全ての確認を終えません。OWASP：CSRF対策

WAFは、適用範囲と動作まで調べる

WAFは、Web向けの不正な要求を検知・制限する仕組みです。利用している場合は、対象サイト、適用ルール、記録のみか遮断するか、除外設定、更新・確認の担当を記録します。機能は製品や契約プランによって異なります。Cloudflare：WAFのルール管理

「導入済み」の回答を受けたら、「どのURLに、何が適用され、いつ確認しましたか」と質問します。通常のフォームや外部連携を止めていないかも確認してください。未導入の場合は、サイトの構成と必要性から対策を検討します。

新人社員：WAFがあると聞きました。フォームの確認も終わりでいいですか？

R.A.I：どのサイトにどのルールが適用され、除外があるかまで確認しましょう。フォーム自体の処理と、通常の送信が動くことも別に確かめます。

保護ヘッダーは、サイトの用途に合わせる

HTTPヘッダーは、サーバーからブラウザへ応答とともに渡す情報です。次のような設定がありますが、存在だけで安全性は決まりません。必要性・値・対象・正常動作を開発担当が確認します。

CSPは入力・出力処理等の対策を補うもので、単独で全ての問題を防ぐものではありません。HSTSは設定の影響が継続するため、子ドメインも含めた条件を確認して適用します。OWASP：HTTPヘッダー、OWASP：CSP、MDN：HSTS

フォームと防御設定のチェックリスト 21〜25

STEP6 戻せることと、異変に気づく体制を確認する

バックアップの成功と、復元の成功を別々に残す

バックアップの管理画面や保守記録で、対象、最後の成功日時、保存世代、保管先、アクセス権を確認します。WordPressなどでは、ファイルだけでなくデータベースも必要です。WordPress：バックアップ

同じサーバーや管理権限の侵害でバックアップまで失われないかも確認します。サーバー会社の自動保存を利用している場合は、何を、何日前まで、どの条件で戻せるかを尋ねてください。

復元確認は、管理者が本番から分けた環境で行います。表示、管理ログイン、フォームなど必要な機能を、架空データで確かめます。実メール、決済、外部サービスへの送信が起きないよう、テスト用へ切り替えてから実施します。復元元、条件、所要時間、結果、戻せなかった範囲を記録してください。

新人社員：バックアップの成功通知が来ています。復旧の準備はできていますか？

R.A.I：何を保存しているかと、別環境で必要な機能まで戻せるかを確認しましょう。保存の成功と復元の成功は別の記録です。

ログと通知は、受け取る人まで決める

ログイン、管理操作、アクセス、エラー等の必要な記録について、取得対象、保管期間、表示時刻・タイムゾーン、閲覧権限、確認担当を調べます。設定上は有効でも記録が取れていないことがあるため、取得例を確認してください。パスワードやトークン、不要な個人情報をログへ残さない設計も必要です。IPA：Webサイトの運用管理

ホスティング会社や監視サービス、Google Search Console等の通知先も現在の担当者へそろえます。Search Consoleの「セキュリティの問題」では検出された問題を確認できますが、通知がないことを被害なしの証明にはしません。提示されるURLも、影響範囲の全件一覧とは限りません。Google：セキュリティの問題レポート

定期日と、予定を待たずに確認する条件を決める

月1回の一覧確認など、サイトの更新頻度や契約に合う点検日を決めます。それとは別に、重要な脆弱性情報、担当交代、制作変更、外部サービスの終了があれば、関連する項目をその時点で確認します。

冒頭の新人なら、点検結果を責任者へ渡し、更新通知を誰が受けるか、保守会社へ誰が連絡するか、次にいつ確認するかまで決めるところが一区切りです。

復旧と継続点検のチェックリスト 26〜30

点検結果から、最初に対応することを決める

件数だけでなく、内容と影響を見る

「要対応が多いから全部同じ優先度」「あと一つチェックできれば安全」とは考えません。実際の状況と、扱う情報・業務への影響で判断します。

着手を整理するなら、まず3件を選び、担当と期限を付けます。緊急事項が4件以上あれば、3件で打ち切る必要はありません。

「不明」を後回しにしないための三つの質問

不明な項目が残ったら、次の順で確認の優先度を決めます。

1. どこから利用できるか。 公開中の旧サイト、管理画面、フォームなど、対象と公開範囲を確かめます。
2. 何に影響するか。 扱う情報の種類、停止すると困る業務、他サイトやメールとのつながりを記録します。
3. 誰が、いつまでに事実を確かめるか。 必要な画面・記録を指定して依頼し、回答期限を付けます。

例えば、個人情報を受け取る公開フォームの実行環境が不明なら、情報の保存先と保守担当を先に確かめます。担当者に製品名・版・修正状況を確認してもらい、関係する脆弱性情報があれば、攻撃への悪用状況や自社への影響も踏まえて対応を決めます。JVN iPediaの活用ガイドも、攻撃状況と自組織が利用するソフトウェアを踏まえた対策を案内しています。JVN iPedia：活用ガイド

「不明」は、判断に必要な事実がまだそろっていない状態です。確認先と期限を決めて調べ、侵入や漏えいを疑う事実が出た場合は初動対応へ切り替えてください。

保守会社への確認依頼を、対象と質問で書く

次の文面をコピーし、対象の番号と質問を絞って使ってください。

件名：当社Webサイトの保守状況・点検項目の確認依頼
対象サイト・範囲：
当社担当・連絡先：
回答希望日：

対象の点検番号：
当社で確認できた事実：
現在不明なこと・確認したい質問：

現在の状態、確認した日、根拠となる画面・作業記録、
貴社の保守範囲に含まれるかを教えてください。

対応が必要な場合は、対象、業務への影響、作業内容、
費用・保守範囲、実施時期、変更前の保全と戻す方法、
変更後の確認方法を提示してください。
未確認・保守範囲外の事項は、その旨と確認先を教えてください。
作業の実施は、内容を確認してから調整します。

質問の例は「No.26について、ファイルとDBの両方が保存対象か、最後の成功日時と復旧できる期間を教えてください」です。「セキュリティは大丈夫ですか」よりも、回答に必要な範囲が明確になります。

回答が「対応済み」だけなら、対象・実施日・結果・残る範囲を追加で確認します。変更後は、設定が反映されたことに加え、必要な業務機能も確かめます。

冒頭の新人も、最初からサイトの安全性を一人で判定する必要はありません。台帳と確認票を基に、「誰に何を尋ねるか」「回答を誰が確認するか」「必要な作業をいつまでに行うか」を決めれば、管理を引き継ぐための具体的な仕事になります。

対象番号・判明した問題：
対応順を決めた理由・業務への影響：
判断する人／作業する人／確認する人：
行う変更・実施予定：
変更前の保全・検証場所・戻す方法：
完了条件：
実施内容・日時：
再確認の条件・結果・根拠：
残る問題・不明点・次の担当・期限：
作業進捗：未着手／対応中／完了

自社検証：正常に開く架空サイトを、内部まで点検してみた

新人社員：無料検査で、管理者やバックアップまで分かりますか？

R.A.I：外部から取得できる情報には限りがあります。検査結果を入口にして、内部の権限や復元は管理画面と保守担当で補いましょう。

会社案内も問い合わせフォームも開く。それでも、非公開資料・退職者の権限・バックアップには問題が残る。 この違いを確かめるため、レイズでは架空の会社サイトを作り、公開ページの確認、内部の点検、修正後の再確認を行いました。

実験の条件：架空サイトに、確認したい問題を用意した

2026年10月21日、Mac内だけで動く「サンプル商事」という実験用サイトを使いました。会社・利用者・価格・問い合わせはすべて架空です。検索除外だけの社内資料、公開領域のバックアップ、退職者として扱う利用者、DBを含まないバックアップを意図的に用意しました。実際の企業を調べて見つけた問題の発生率を示すものではありません。

公開側の確認範囲は、会社案内・お知らせ・問い合わせの同じ3ページです。HTTP応答を手元で取得し、Web AI Securityの公開HTMLを分析する処理に渡しました。公開中の無料検査サービスへ送信した結果ではありません。 ローカルアドレスを制限する本番の通信処理は変更していません。

次に、作成した利用者台帳、ファイル配置、バックアップの中身を確認し、既知の資料・ファイルのURLへ限定してアクセスしました。修正と復元は、この実験用サイトだけで実施しています。今回対応付けたのはNo.11・17・18・26・27の5項目です。30項目全体の完了件数や安全度は算出しません。

検索除外だけでは、社内資料を読めた：No.17

社内用価格表に、検索結果への掲載を避けるnoindexをHTMLとHTTPヘッダーの両方で設定し、robots.txtにも内部フォルダを巡回しない指定を置きました。その状態で、ログインしていないブラウザから資料のURLを直接開くと、HTTP 200で架空の価格表が表示されました。 今回は検索エンジンへの登録有無を調べたのではなく、検索向けの指定と閲覧制限が別の仕組みであることを確認しています。

なお、robots.txtで巡回を止めると、検索エンジンがページのnoindexを読み取れない場合もあります。検索設定自体の組合せも確認が必要です。Google：noindexによる除外とクロールの条件

修正では、サーバー側で利用者と閲覧権限を確認する処理を追加しました。同じURLに再度アクセスした結果は次のとおりです。HTTPの数字はサーバーの応答で、200は表示、401は認証が必要、403は権限による拒否を表します。

No.17の確認では、設定を見ただけで終えず、未ログイン・権限のない利用者・許可した利用者を分けて試してください。今回の実験では、認証済みの状態を架空のテスト用セッションで作成しました。パスワード認証や多要素認証の強度は試していません。権限の判定は要求ごとに行う、という考え方はOWASPの認可の解説でも確認できます。

HTMLにリンクがなくても、公開領域のファイルは読めた：No.18

次は、架空の問い合わせ2件が入ったCSVを、公開領域の既知の場所に置きました。3ページのHTMLには、そのファイルへのリンクを載せていません。

HTMLの分析では、修正前後とも「バックアップ・設定ファイルに似たリンクは見つかりませんでした」という結果になりました。一方、配置場所を知る管理者としてCSVのURLを直接取得すると、修正前はHTTP 200で内容を読めました。 HTMLにリンクがないことと、ファイルが公開されていないことは別でした。

CSVを公開領域の外へ移した後、同じURLへの匿名アクセスはHTTP 404になりました。404は、そのURLに対象がないという応答です。移動先には元のCSVが残り、内容も一致しています。ここで確認したのは既知の1ファイルだけで、サイト内の機密ファイルをすべて探したわけではありません。

No.18には、公開ディレクトリとバックアップの実際の保存先を記録します。 HTMLの検査結果だけで「公開ファイルなし」と記入しないでください。今回のURL取得は管理者側の追加確認であり、無料検査が隠しファイルを推測して取得する機能ではありません。

退職者の管理画面アクセスは、内部で確認した：No.11

利用者台帳には、現担当者A、退職者として扱うB、閲覧用のCを登録しました。修正前はBの管理者権限とテスト用セッションが残り、Bのセッションで管理画面を開くとHTTP 200で利用者一覧が表示されました。

Bを無効にして既存セッションを削除した後、同じセッションでのアクセスはHTTP 401になりました。現担当者Aは引き続きHTTP 200で管理画面を開けました。権限を整理した後は、不要な利用者を止めたことと、担当者の必要な作業を続けられることを両方確かめます。

公開3ページの分析では、管理者の権限とバックアップ体制は修正前後とも「不明」でした。内部の変更が、公開HTMLの結果に現れるとは限りません。

トップが開いても、復元できたとは限らなかった：No.26・27

最後に、修正後の同じサイトから二つのZIPを作り、それぞれ新しい復元先へ展開しました。一方は表示用HTMLとロゴだけ、もう一方はその2ファイルとDBを含めました。アプリを動かすプログラムは同じものを使っています。WordPressやサーバー全体の復旧試験ではありません。

復元前の参照データは、お知らせ3件と架空の問い合わせ4件です。問い合わせは初期データ2件に、修正前後のブラウザ動作確認で保存した各1件を加えたものです。

503は、この実験用アプリで必要なDBがなく機能を提供できない応答です。201は新しいデータを保存した応答です。DBを含めた復元では、追加送信の前にファイルのハッシュとDB全行の内容を参照値と照合し、一致を確認しました。その後、新しい架空の問い合わせをブラウザから保存しました。外部へのメール送信はありません。

No.26には「何を保存しているか」、No.27には「戻したデータと、実際に動いた機能」を残します。今回、ファイルだけのZIPも正常に作成・展開できましたが、お知らせと問い合わせ保存にはDBが必要でした。WordPress公式のバックアップ解説も、ファイルとDBを保存対象として区別しています。

点検票には、見た目ではなく確認条件と結果を残す

修正前後の会社案内・お知らせ・問い合わせは、いずれもHTTP 200でした。トップページの本文もハッシュが一致しました。それでも、社内資料への匿名アクセス、公開領域のCSV、退職者のアクセスは、修正前後で変わりました。復元でも、トップが開くことと、データを戻して問い合わせを保存できることは別でした。

この結果から、点検票には「表示できた」だけでなく、誰の権限で、どのURL・保存先・機能を、どう確認したかを残すことを勧めます。今回の5項目なら、No.11は停止対象と既存セッション、No.17は利用者ごとの応答、No.18は公開範囲と移動後の応答、No.26・27は保存対象・復元データ・操作結果を記入します。

今回の測定は、小さな架空サイトを同じMac内で動かした各条件1回の結果です。HTTPS・証明書、実際のCMS、認証製品、クラウドの保存、別装置からの復旧、侵入や漏洩の有無は検証していません。本番サイトの安全性を保証する結果としては扱いません。

無料PDFを、自社サイトの点検台帳として使う

無料PDFには、30項目の確認票と、サイト台帳、保守会社への確認依頼、改善・再確認記録、次回点検表をまとめています。印刷して書き込む形式です。

1. 対象URL、構成、担当を記入する。
2. 各項目を四つの状態で記録し、根拠の参照先を残す。
3. 不明点には質問と回答期限、要対応には担当と完了条件を付ける。
4. 回答・修正の後に再確認し、残る課題と次回日を決める。

共通して残すのは、対象、確認日・確認者、確認条件、根拠の所在、状態、次の担当と期限です。機能がない場合は該当なしの理由も書きます。点検票には内部情報が集まるため、社内で保管先と閲覧者を決めてください。

新人社員：30項目にチェックできたら、次は何もしなくてよいですか？

R.A.I：確認日と根拠を残して、次の点検日を決めましょう。重要な脆弱性情報や担当交代があれば、その時にも確認します。

点検項目を社内で編集したい場合は、30項目のCSVも使えます。この点検票の30項目と、無料AIセキュリティ検査の40項目は別の整理です。外部の検査結果を手がかりに、管理画面と保守記録で確認を補ってください。

放置サイトの点検でよくある質問

何年更新していないと危険ですか

年数だけでは判断できません。お知らせの更新日とは別に、CMS・部品・サーバーの版、修正の提供状況、権限、公開範囲を確認してください。重要な問題が判明した場合は、放置した年数にかかわらず対応を判断します。

WordPressでなくても30項目を使えますか

使えます。静的サイトでCMS・プラグイン・テーマがなければ、その項目は理由を付けて該当なしにします。一方、生成・配備に使う部品、ドメイン、管理権限、外部タグ、フォーム、公開範囲は確認します。SaaS型では、事業者が管理する部分と自社の設定を分け、案内・契約・回答を記録してください。

ホームページ制作会社に任せていれば十分ですか

契約範囲と実施記録を確認してください。制作、サーバー運用、更新、バックアップ、緊急対応で担当が分かれることがあります。対象と作業を示して質問し、回答と根拠を残します。

自動更新をすべて有効にすればよいですか

各部品の対応状況、互換性、復元準備、通知先を確認して決めます。有効化した後も、実際の版、成功・失敗、必要な機能の動作を追ってください。

HTTPSやWAFがあれば、不正アクセスは防げますか

それぞれが対策する範囲は異なります。通信や要求の制御に加え、ソフトウェア更新、認証・権限、フォーム処理、公開範囲を確認します。

30項目が全部確認済みなら安全ですか

確認した範囲と時点の記録です。チェック数を安全度に換算せず、根拠、残る範囲、次の確認日を管理してください。サイト変更や新しい脆弱性情報があれば再点検します。

無料AI検査で管理画面やバックアップも分かりますか

公開情報の検査では、内部の利用者・権限、バックアップの実体、フォーム内部の処理まで確認できません。検査結果と、管理画面・保守担当の確認を組み合わせてください。

不審な管理者や改ざんを発見したら、更新を続けますか

通常の保守作業として進めず、責任者へ連絡します。管理者が拡大防止と記録保全を進め、調査と復旧を判断します。操作で記録を消す前に、初動対応マニュアルを確認してください。

出典と参考資料

確認日：2026年10月24日（資料7は2026年10月18日の確認記録を参照）。30項目の選定・分類と記録書式は、以下の資料を参考に株式会社レイズが編集しました。各機関による本サービスの認定を示すものではありません。

1. IPA：安全なウェブサイトの運用管理に向けての20ヶ条
2. IPA：安全なウェブサイトの作り方
3. WordPress：Hardening WordPress
4. WordPress：Dashboard Updates Screen
5. WordPress：Plugins and themes auto-updates
6. PHP：Supported Versions
7. JVN iPedia：活用ガイド・攻撃状況や組織の環境を踏まえた脆弱性対策について
8. JPRS：ドメイン名の廃止に関する注意
9. Microsoft：Prevent dangling DNS entries and avoid subdomain takeover
10. OWASP：Multifactor Authentication Cheat Sheet
11. Google Search Central：robots.txtの概要
12. OWASP：Third Party JavaScript Management Cheat Sheet
13. OWASP：File Upload Cheat Sheet
14. OWASP：Session Management Cheat Sheet
15. OWASP：Cross-Site Request Forgery Prevention Cheat Sheet
16. OWASP：HTTP Headers Cheat Sheet
17. OWASP：Content Security Policy Cheat Sheet
18. MDN：Strict-Transport-Security
19. Cloudflare：WAF managed rules
20. WordPress：Backups
21. Google Search Console：セキュリティの問題レポート
22. OWASP：Authorization Cheat Sheet（実験の認可確認）
23. Google Search Central：noindexを使用してコンテンツをインデックスから除外する（実験の検索設定の補足）
24. Red Hat：Backporting Security Fixes
25. PHP：Command line usage

関連記事

• 顧客情報が漏れたかもしれない——情報漏洩の兆候と、最初に確認するチェックリスト
• ランサムウェア対策50項目｜自社で点検できるチェックリスト【無料PDF】
• 不正アクセス・情報漏えいが疑われたら？企業のための初動対応マニュアル
• PHPの脆弱性、うちの会社は大丈夫？ホームページ・ネットショップの確認10項目

まずは公開Webサイトの状態を無料で確認する

自社サイトの公開設定から確認したい方は、Web AI Securityの無料AIセキュリティ検査をご利用ください。通信・証明書や、取得したページの公開設定を確認できます。

最大10ページ・40項目、所要時間は約3分が目安です。公開情報から分かる範囲を調べる検査で、ログイン後の内部設定や、サイト全体の安全性を保証するものではありません。

結果を手がかりに、この30項目で更新・管理権限・バックアップも点検してください。分からない項目は、確認先と質問が決まれば次の作業を始められます。