自社サイトのアクセスログ（サイトへの訪問記録）を開いたら、身に覚えのない大量のアクセス——「/.env」「/.git」といった見慣れないURLへの要求や、GooglebotやClaudeBotを名乗る記録——が並んでいて不安になった、というご相談をよくいただきます。
こうしたアクセスの多くは、世界中のサイトを無差別に狙う自動スキャンだったりします。
基本的な備えができていれば過度に恐れる必要はないですが、「本物の検索エンジン／AIのボット」と「それになりすました攻撃」を見分ける目は持っておくべきです。
私はMintSparkで情報処理安全確保支援士として、中小企業のセキュリティ支援を行っています。本記事は、私たちが運営するサイトのアクセスログを実際に分析した一次記録をもとに、「どこを見れば、次の対応を決めやすくなるか」を、実際の流れに沿って、専門用語を噛み砕いて解説します。
この記事の要点
- ログに並ぶ“不審なアクセス”の多くは、世界中を無差別に走査する自動スキャン。特定企業の狙い撃ちとは限りません。
- 攻撃者はGooglebot・ClaudeBotなど正規ボットの名前（User-Agent）を平気で詐称します。「名乗り」は信用できません。
- 見分けの決め手は「逆引きDNS」と「1つのIPが複数の正規ボットを名乗っていないか」。そして秘密ファイルを公開領域に置かないことです。
まず、ログを開いたら“変なアクセス”が並んでいた
最初の一歩は、サーバーの「アクセスログ」（どのIPが・いつ・どのURLに・どう応答したかの記録）を開くことです。実際に見ると、次のような行がずらりと並んでいました。
気づく点は2つあります。ひとつは、.env や .git/config、/wp-config.php.bak といった、普段は誰もアクセスしない“秘密ファイル”への要求が大量にあること。もうひとつは、それらが Googlebot・ClaudeBot・Amazonbotなど大手ボットの名前を名乗っていること。ここで「乗っ取られたのでは？」と不安になるのは自然です。ですが、慌てて対処する前に、まず“事実”を確認しましょう。
落ち着いて“3つ”を確認したら、問題なかった
不安なときは、まず次の3点から状況を整理します。そのうえで、同じ時間帯のログイン履歴やファイル変更も見比べると、対応の必要な箇所を絞りやすくなります。
- 応答を集計する——200が返っていたら、設定ファイルの内容か、通常の案内ページかを確かめます。500が続く場合は、アプリのエラーログも確認します。
- 発信元IPを逆引きする——正体（どこから来たか）を確かめます。
- 秘密ファイルが実在するか確認する——そもそも公開領域に置いていなければ、探されても取られようがありません。
当社サイトで調べた約3週間分のログには、この手の「秘密探し」が2,944件、発信元は84個のIPアドレスありました。応答は主に403（アクセス拒否）、404（対象が見つからない）、500（サーバー内部のエラー）で、200の記録は実質ゼロでした。発信元にはクラウドの仮想サーバーやスキャン業者が含まれていました。狙われた.envやバックアップを公開領域に置かない運用も、ここで確かめています。こうした記録を、ログイン履歴やファイル変更などと合わせて読むのが、被害の状況をつかむ手順です。
参考までに、①「応答の集計」を自分のサーバーで試すときのコマンド例です（Apache系のアクセスログを想定。ファイル名やログの形式は環境により異なります）。
# ① 応答コード別に件数を集計（ログの形式に依存しにくい方法）
grep -oE '" [0-9]{3} ' access_log | sort | uniq -c | sort -rn
# 秘密ファイル探索（.env / .git / .aws / wp-config.php.bak 等）への応答だけを見る
# → 200 は返却内容を確認。500 はエラーログも照合。403・404 は同じ時間帯のログイン履歴・ファイル変更と合わせて読む
grep -aiE '/.env|/.git|/.aws|wp-config.php.' access_log
| grep -oE '" [0-9]{3} ' | sort | uniq -c | sort -rn
# ② 気になる発信元IPを逆引き → 出たホスト名を正引きして元IPに戻るか確認（FCrDNS）
host 203.0.113.45
host <逆引きで出たホスト名>403・404は、拒否された要求や、対象が見つからなかった要求を整理する手がかりです。同じ時間帯に身に覚えのないログインやファイル変更がなかったかまで見ておくと、状況をつかみやすくなります。500はサーバー内部のエラーなので、原因をエラーログで追います。200が混じっていたら、まず返された内容を確かめてください。通常の案内ページが返るサイトもあります。
設定ファイルの内容が外部へ返っていたら（初動対処）
- そのファイルを今すぐ公開領域から外す：.env やバックアップ等を、Webから見えない場所へ移動、または削除します。
- 公開されていた認証情報を変更する：設定ファイルの内容が外部へ返っていた、または公開状態だったと分かったら、そのファイルに含まれるパスワード・APIキー・データベース接続情報を速やかに切り替えます。公開を止める作業と、ログなどの調査資料の保全も並行して進めます。
- 同じパスをサーバー設定で遮断する：以後アクセスできないよう、.htaccess 等で拒否します。
- 影響範囲を確認し、迷えば専門家へ：何が読めたか・悪用の痕跡がないかを確認します。範囲が広い、または不安な場合は早めにご相談ください。
正体は“無差別スキャン”——なぜ大手ボットを名乗るのか
この手のアクセスは、特定の会社を狙った標的型攻撃とは限りません。実態は、クラウド上の仮想サーバーやスキャン業者が、世界中のサイトに同じ“定番リスト”を機械的に投げているものです。約3週間、毎日数百件のペースで続いていたことからも、狙い撃ちではなく“背景ノイズ”だと分かります。
やっかいなのは、彼らがGooglebotやClaudeBotの名前（User-Agent）を平気で詐称することです。検知や遮断をすり抜け、正規のアクセスに紛れるための偽装です。だからこそ、次の「見分け方」が要になります。
「本物のボット」と「なりすまし」を見分ける4つの視点
ログにClaudeBotやGooglebotの名前が並んでいても、鵜呑みにしてはいけません。User-Agent（ユーザーエージェント＝ブラウザやボットの“名乗り”）は、誰でも自由に書き換えられるからです。本物かどうかは、次の4点で確かめます。
① 公式の確認手順で、名乗りと発信元を照合する。 IPアドレスを逆引きし、得られたホスト名を正引きして元のIPに戻るかを確かめます。Googleはクローラー・取得処理の種類ごとにホスト名の形式とIP範囲を公開しています。Googlebotを名乗る通信なら、その種類に対応する一覧と照合すると判断しやすくなります。googleusercontent.comという末尾だけでなく、公式に示されたホスト名の形式まで見るのがポイントです（Google公式の確認手順）。ほかのボットも、それぞれの運営元が公開する情報を基準に調べます。
② 同じIPから名乗りが次々に変わっていないか。 当社のログでは、1つのIPがGooglebot、ClaudeBot、Amazonbot、GPTBotと名乗りを変える記録がありました。こうした動きは、発信元を詳しく調べるきっかけになります。公式のIP範囲やアクセス先、要求の間隔も並べて見ると、実態に近づけます。
③ アクセス先の“性質”を見る。 本物の検索エンジンやAIのボットは、公開されている記事やページを辿ります。一方、.env や credentials、.git を探し回るのは、コンテンツ収集ではなく“秘密探し”であり、スキャナ特有の振る舞いです。
④ 名乗り（User-Agent）だけを信用しない。 繰り返しますが、名乗りは詐称できます。「ClaudeBotだから安心」ではなく、①〜③で裏を取ります。実際、公式には存在しない名前（例：Claude-Web）を騙るケースもありました。
①の逆引きDNSと、各社が公開しているIPレンジ一覧を使った具体的な確認手順は、Googlebotを名乗る偽装アクセスの見分け方｜逆引きDNSと公開IPレンジで確認するに分けてまとめました。コマンドの打ち方まで追いたい場合はそちらをご覧ください。
あなたのサイトを“空振り”にさせる守り方
同じスキャンは、あなたのサイトにも日々来ています。被害の分かれ目は「探されたファイルが、そこに“無い／読めない／届かない”か」。次の基本を押さえれば、大半は空振りに終わります。中小企業でも、多くはサーバーやCMSの設定で対応できます。
スキャンを“空振り”にさせる基本の守り
- 秘密ファイルを公開領域に置かない：.env・データベースのバックアップ・鍵ファイルは、Webから見える場所に置かない。バックアップは公開フォルダの外へ。
- 設定ファイルの権限を絞る：WordPress等をお使いなら、設定ファイル（wp-config.php 等）は「本人だけが読める」権限にする。
- 隠しファイル・危険パスをサーバー側で遮断：.env や .git への直接アクセスは、サーバー設定（Apacheなら.htaccess等）で拒否する。
- アップロード領域でのプログラム実行を禁止：画像置き場に紛れ込んだプログラムファイルが動かないようにする。
- WAFを有効化（WAF＝不正なアクセスのパターンを検知して遮断する仕組み）。多くのレンタルサーバーで設定するだけで使えます。
- PHPなどのソフトを最新に保つ：古いバージョンには既知の弱点がある。
最後の「最新に保つ」が効いた例を挙げます。今回のスキャンには、古いPHPの設定を悪用してコードを実行しようとする攻撃（CVE-2012-1823）も含まれていました。これはPHPを「CGI」という古い方式で動かしている場合の弱点で、当社は現行方式（PHP-FPM）で運用しているため成立しませんでした。米CERT/CCも、この弱点はApacheのmod_phpやnginx＋php-fpm構成では影響しないとしています（出典：CERT/CC VU#520827）。ここでも「古い構成を避け、最新に保つ」ことがそのまま守りになります。
「WordPressだから狙われる」の誤解
- 使っているCMS（WordPress等）の種類は、URLの作りなどから自動で判別されます。種類を隠しても守りにはなりません。
- ただし「バージョン情報」は別で、隠すべき：WordPress本体やPHPのバージョンが分かると、そのバージョン固有の既知の弱点を狙われやすくなります。
readme.html・license.txtの公開停止や、ページに埋め込まれる generatorメタタグ（例：WordPress 6.x）の除去で、バージョンを露見させないようにしましょう。あわせてログインID露出（REST API）や xmlrpc.php も塞ぎます。これらは当社の無料診断でも「WordPressの攻撃面」として確認している項目です。 - 狙われるのは「露出した秘密ファイルや設定の不備」であって、WordPress自体ではありません。世界で最も使われているCMSなので、スキャナの“定番リスト”に含まれるだけです。
- やるべきは「隠す」ことではなく、秘密を公開領域に置かない・危険パスを遮断する・最新に保つという中身の対策です。
過信は禁物
- ここで挙げた対策は「被害の入口を大きく減らす」ものですが、あらゆる攻撃を防ぐ“万能薬”ではありません。ログの定期確認と、ソフトの更新を続けることが前提です。
- 逆に言えば、基本を押さえておけば、日々飛んでくる無差別スキャンの大半は空振りに終わります。まずは足元の“置き場所・権限・遮断設定”から見直しましょう。
まとめ
ログに見慣れない要求があったら、①応答コードと返却内容、②発信元と公式情報の一致、③設定ファイルの置き場所から確認を始めます。同じ時間帯のログイン履歴やファイル変更も合わせて見れば、次に調べる範囲が見えてきます。日頃の備えは、秘密情報を公開領域に置かないことと、ソフトウェアを更新すること。気になる記録があれば、ログを残したうえでご相談ください。
「自社サイトに、外から見える弱点（なりすましメール対策・HTTPS・WordPressの設定漏れなど）がないか」は、URLを入れるだけ・登録不要で無料診断できます。ログの見方や具体的な遮断設定まで相談したい方は、情報処理安全確保支援士が30分の無料相談でご案内します。あわせて、中小企業のセキュリティ診断とは？無料でできるチェック項目と進め方もご覧ください。
参考・出典: Google「Verify Google crawlers and fetchers（Googleのクローラー確認方法。User-Agentは詐称され得るため逆引き＋正引き、または公式IP範囲で確認）」（Google 公式ドキュメント）／CERT/CC「PHP-CGI query string parameter vulnerability（VU#520827・CVE-2012-1823。Apache mod_php／nginx＋php-fpm構成は非該当）」（CERT Coordination Center）
※本文中の件数・発信元IP数・応答内訳は、当社運営サイトのアクセスログ（約3週間分）を実測・集計した一次データです。ログ画面の図はダミーデータによるイメージです（実在のIP・ホスト名ではありません）。
参考：httpwg.org（2026年10月12日確認）