2026年秋、日本では企業の情報漏えいの公表が相次ぎ、10月にはAIが見つけた重大な欠陥（通称PHP2Shell）で世界中のWebサイトが攻撃を受けました。インドでは目立った騒ぎになっていませんが、攻撃を受けた組織の割合は世界平均を上回っています。そして2027年5月からは、インドでも漏えいを本人に知らせる義務が始まります。
この記事は、インドに拠点を持つ日系企業の海外事業部門とインド子会社の責任者に向けて、何が起きていて、何が本当に危なく、経営として何を決めておくべきかを整理したものです。70社以上の日印・中東のデジタル発信を支援してきたSTORYTELLINGの立場からまとめています。
おさらい：日本で何が起きたのか
2026年9〜10月にかけて、業種や規模を問わず漏えいの公表が続いています。IPAやJPCERT/CCも、10月に相次いで注意喚起を出しました。
| 公表時期（2026年） | 事例 | 何が起きたか |
|---|---|---|
| 10月21日 | PHP2Shell | 世界のサイトの約7割が使うPHPに、AIが見つけた重大な欠陥。公表直後から世界中で攻撃が始まる |
| 10月19日 | 日本企業約20社への攻撃 | GMOサイバーセキュリティが、AIによる自律型の攻撃ツールが使われたことを確認。うち8社が漏えいを公表済み |
| 10月上旬 | IDCフロンティア | クラウド事業者へのランサムウェア攻撃で、利用する495の企業・自治体に影響 |
| 7月 | アフラック | 問い合わせの仕組みに回数制限がなく、約440万人分の情報が取得された |
これは、大企業だけの話ではなく、決めた業種のサイトを、規模に関係なくまとめて狙う攻撃が確認されています。
PHPを使っていることが問題なのか
正確には、PHPだけの問題ではありません。PHPが狙われたのは、世界のサイトの約7割で使われ、攻撃者にとって最も「当たりが多い」からです。PHPをやめても、別の仕組みで同じことが起きます。実際、今秋日本で漏えいした事例の多くはPHPとは関係なく、自社アプリの設定ミスや、クラウド事業者・委託先への攻撃が原因でした。
今回、PHPの脆弱性に焦点が当たりましたが、実際に狙われやすいのは、大きく分けて次の3つの状況です。
- メンテナンスされていないサイトがある。制作会社との契約が切れたサイトや、放置されたキャンペーンLPです。インドの日系企業では、駐在員の交代で管理者が分からなくなるケースも少なくありません
- 公開サイトに大事な情報を置いている。詳しくは次の章で説明します
- 何が外から見えているかを把握していない。管理画面、開発用のサイト、共有リンクなど、忘れられた入り口が狙われます
同じWordPressでも、更新や防御を専門事業者が担う大手のサービスは、PHP2Shellの公表から数時間で対応を終えました。差を生んだのは言語ではなく、保守の体制です。
国によって「大ごと」になった国、ならなかった国
大ごとになったかどうかは、攻撃の多さでは決まりませんでした。分けたのは、政府の対応と、その前提にある法制度でした。(各国におけるCheck Pointの観測対象組織のうち、PHP2Shellの脆弱性を悪用した攻撃試行が検知された組織の割合。国内の全Webサイトに対する割合ではなく、攻撃の成功を示すものでもない。国別の調査対象数は非公開）
上位20か国は、タイとインドを除いてヨーロッパとその周辺で、日本は入っていません。ヨーロッパではオランダやフィンランド、ドイツなどで政府が自らサイトを止め、止めたこと自体がニュースになりました。一方インドは11位と上位にいながら、ニュースではほぼトピック化されませんでした。
インドではなぜ大きな問題にならなかったのか
被害が少なかったのではなく、表に出ていないだけです。セキュリティ企業Check Pointによると、PHP2Shellの攻撃を受けた組織の割合はインドが14%で、世界平均の10%を上回りました。上位20か国の中で11位です。
弊社でも、最初に気づいたのは日本人スタッフで、日本および海外のニュースから事態を知りました。一方で、インドの開発者コミュニティはいたって静かな状況でした。「大ごと」かどうかを分けたのは攻撃の多さではなく、政府の動き方と被害を公表する仕組み、法規制です。
- 報告先は政府で、世間ではない：インドでは、サイバー攻撃を検知から6時間以内にCERT-Inへ報告する義務があります。ただしこれは政府への報告で、一般への公表ではありません
- 本人への通知義務はまだ始まっていない：DPDP法（デジタル個人情報保護法）では、漏えいに気づいてから72時間以内に、影響を受けた本人とデータ保護委員会へ知らせる必要があります。この義務が本格的に適用されるのは2027年5月13日からです
つまり2027年5月以降は、インドでも漏えいが「顧客に知られる問題」になります。来年度は、日本で起きていることがインドでも表に出始める年だと考えておくべきです。
それではこれは「AIハッカー問題」なのか
答えは「はい、ただしAIが作った穴ではない」です。AIは攻撃の速さと規模を大きく変えました。しかし破られているのは、以前からあった基本的な穴です。
AIが変えたこと
- 穴探しが一瞬になった：PHP2Shellの欠陥は14年間誰にも気づかれずにいましたが、AIは数週間で見つけました。攻撃者側も同じ能力を使えます
- 小さな会社も「狙う価値」が出た：下調べをAIが自動で行うため、業種ごとに網羅的に当ててくる「じゅうたん爆撃」型の攻撃が増えています
- 言語の壁がなくなった：自然な日本語やローカル言語の詐欺メールが簡単に作れるようになりました
変わっていないこと
大規模な不正アクセス30件のうち、侵入口が分かった21件を見ると、半分の11件は自社のアプリや管理画面の欠陥、設定ミスでした。次いで委託先・クラウドサービス経由が4件です。また、多くの事例でAIが使われた証拠はまだ公表されていません。
AIハッカーは、新しい穴を開ける存在ではありません。放置されていた穴を、人間より速く、広く見つける存在です。だからこそ、「自社は小さいから狙われない」という前提はもう通用しません。
情報漏えいはなぜ起きたのか
漏えいの原因はWordPressそのものではなく、「どこに、どんな形でデータを置いていたか」です。サイトに侵入されても、そこに個人情報がなければ漏れません。
例えば10月9〜11日には、日本の不動産関連サイト約20社が恐喝被害を受け、中心となったサイトからは年収や貯蓄額を含む約1万6,000件の会員情報が盗まれました。原因は、公開サイトと同じサーバーに会員データを丸ごと置き、必要以上の情報を集めていたことです。
日系企業でも、問い合わせフォームの内容や展示会の来場者リストが、サイトのサーバーや担当者のメールに何年分も溜まっている例は珍しくありません。方針はシンプルで、顧客データはサイトにもメールにも溜めず、HubSpotなどのCRMに一本化することです。
自社サーバーとクラウド、どちらが安全なのか
顧客データを自社のサーバーに置く場合でも、きちんと保守していれば安全な状態を保てます。保守を自社で担えないなら、個人情報のデータは名刺管理システム、顧客管理システム（HubSpot）などのクラウド型サービスに預ける方法があります。
クラウド型の方が安全といえる理由は2つあります。1つは、サービス会社の専門チームが常にシステムの脆弱性を監視しています。問題が見つかればすぐに直されます。もう1つは、データがWebサイトとは別の場所に保管されるため、サイトが乗っ取られてもデータまでは届かないことです。
ただし「入れたら安心」ではありません。HubSpotでも次の2件がありました。
- 2022年3月：攻撃者がHubSpotの社員をだましてログイン情報を手に入れ、二段階認証の承認までさせました。そのまま社内のサポート用ツールに入り、暗号資産業界の一部の顧客から、コンタクト情報を持ち出しています。二段階認証があっても、人がだまされれば破られるという例です
- 2024年6月：50件未満の顧客アカウントへの不正アクセスが見つかりました。手口は公表されていませんが、HubSpotは「顧客アカウントへの侵入の試みを止めている」と説明しています。システム全体ではなく、個別の利用企業のアカウントが狙われた形です
どちらも被害は21万社以上ある利用企業のごく一部でした。ただ、入り口はどちらも「人」と「アカウント」です。サーバーの守りは事業者が担いますが、誰がログインでき、どのツールとつながっているかは利用企業の責任です。身に覚えのない二段階認証の承認依頼には応じないよう、社内でも伝えておく必要があります。
インドの日系企業でよくある3つの穴
私たちが日系企業のSNSやWebを引き継ぐとき、ほぼ必ず出会うのが次の3つです。どれも、高度な技術がなくても破られる穴です。
- SNSやサイト編集者に退職者が管理者として残っている。FacebookやLinkedInの会社ページに、辞めた社員、帰任した駐在員、契約が終わった代理店の個人アカウントが管理者のまま残っています。その個人アカウントが乗っ取られれば、会社のページも乗っ取られます
- 二段階認証が抜けている。管理画面のパスワードを複数人で共有し、二段階認証は設定していない。あるいは認証コードが特定の個人の携帯に届き、その人が辞めると誰もログインできなくなります
- 社員が個人でデータを持っている。名刺、展示会のリード、問い合わせリストが、営業担当の個人のPCに保存したExcel、WhatsApp、個人のGmailに散らばっています。PCはなくしたり盗まれたりしやすく、ウイルスに感染すれば中のファイルはまとめて持ち出されます。退職と一緒にデータも出ていき、漏れても会社は気づけません。DPDP法では、それでも会社の責任です
3つに共通するのは、会社の資産が「人」に紐づいていることです。人の入れ替わりが多いインドでは、アカウントもデータも「会社名義で持ち、人に権限を貸す」形、これらを選任の担当者が管理していることが、最も効果の高い対策です。
漏えいしたときに会社が負うもの
インドでは2027年5月を境に、漏えいは「社内で処理する問題」から「顧客と当局に説明する問題」に変わります。
- 報告と通知の義務：検知から6時間以内にCERT-Inへ報告。2027年5月13日からは、気づいてから72時間以内に本人とデータ保護委員会へ通知
- 制裁金：DPDP法で最大25億ルピー（250クロール）
- 顧客と取引先の信用：本人への通知で、漏えいは顧客に直接知られます。日本の本社やグループ全体の評判にも及びます
- 営業機会：サイトを止めれば、その間の問い合わせと検索からの流入を失います
2027年5月までに決めておくこと
必要なのは高度な技術ではなく、「誰が責任を持ち、何を定期的に監視するのか」を決めることです。
- インド支社のデジタルアカウントの責任者を決める。Web、SNS、顧客データの全体像を理解している人です。駐在員が担う場合は、交代時の引き継ぎを必ず決めておきます
- 社内での点検項目を決める。半年に一度、次の5点をチェックしましょう
- サイト・LP・SNS・CRMの一覧と、だれがアクセスできるか
- 顧客データの置き場所（サイト、メール、個人のPCに溜まっていないか）
- 管理者アカウントの棚卸し結果（退職者・帰任者・代理店が残っていないか）
- 二段階認証の設定状況
- 保守契約の有無と、緊急時の連絡先、体制
- アカウントとデータを会社名義にする。個人に紐づけず、会社が持ち、人に権限を貸す形に切り替えます
- トラブルが起きた場合のワークフローを決めておく。社内でどのように情報をエスカレーションするのか、対外、本人への通知を誰が行うか。本社への第一報も含めます
- 保守・運用に予算をつける。詳しくは次の章です
現場で確認する具体的な項目は、記事の最後の「付録：Web担当者向けチェックリスト」にまとめています。社内用チェックリストとしてご活用ください。
来年度予算への反映（詳しくは別記事で）
来年度のWeb予算では、制作費だけでなく、Webサイトと個人情報を守るための全体設計の見直し（棚卸し）と、保守・運用費を確保することをおすすめします。
押さえたいのは次の4つです。
- 月額の保守契約（サーバーおよびサイトの定期更新と監視）
- 緊急対応の枠（重大な脆弱性の公表時に即日動ける工数）
- 攻撃を手前で防ぐ仕組みと、バックアップの自動化
- データの置き場所の見直し（フォームデータをCRMへ移す、不要なデータを消す）
項目ごとの優先度や、本社への説明の仕方は、別記事「2027年度 インド日系企業のWeb予算の組み方」で詳しく解説します。
まとめ：守りの5つの基本
経営が決めた方針を、現場で確認・実行するための項目です。インド支社のWeb・SNS担当者と、制作会社・代理店にそのまま渡せる形にしています。
| 守り方 | 具体的にやること | 防げること |
|---|---|---|
| 入口を減らす | 自社のサイト、LP、フォーム、管理画面、共有リンクを一覧にし、使っていないものは閉じる | 忘れられた入口からの侵入 |
| 置く情報を減らす | フォームで集める項目を絞る。送信内容をサイトのサーバーに溜めず、CRMへ直接送る。不要なデータは定期的に消す | 侵入されても盗まれるものがない状態にする |
| 鍵を守る | 管理画面・SNS・広告・CRMの全アカウントに二段階認証。退職者・帰任者のアカウントを削除。パスワードの使い回しをやめる | なりすまし、乗っ取り、被害の連鎖 |
| 任せる先を決める | サイトの保守契約を結び、緊急時に誰が対応するかを決める。委託先と利用中のクラウドサービスを一覧にする | 「誰も気づかない、誰も直さない」状態 |
| 気づいて戻せるようにする | バックアップを取り、実際に戻せるか試す。Google Search Consoleの警告を受け取れるようにする | 改ざん後の長期停止、検索評価の低下 |
日本で相次ぐ漏えいは、AIによって攻撃が速く、広くなったという意味では「AIハッカー問題」です。しかし破られているのは、放置されたサイト、公開サーバーに溜めた個人情報、使い回しのパスワードといった誰にでも対処できたはずの、昔からの穴です。PHPをやめることだけに論点をおくのではなく、「誰がサイトを安全な状況に保ち、取得したデータをどこに置くか」を決めることが、自社と顧客を守る近道でもあります。
インドでは、2027年5月にDPDP法の通知義務が始まれば、被害は顧客に知られる形で表に出るようになります。その前にインド支社でも仕組みを整え、いざという時に大穴が見つかって大ごとにならないよう、体制と保守の予算を確保しておくことをおすすめします。
参照元：