AI START CLUB 参加する
← ブログ一覧へ戻る
お知らせ

【山梨AI解説】PHP重大脆弱性「PHP2Shell」とは？

【山梨AI解説】PHP重大脆弱性「PHP2Shell」とは？世界のWebの7割が震えた夜の全貌と対応策

山梨県でAI活用・DX・Web制作を支援するAI企業、株式会社Localabilities（ローカルアビリティーズ）です。今回は世界中を騒がせたPHPの重大脆弱性について、国内外の一次情報をもとに、できるだけわかりやすく解説します。

あの夜、ネットのあちこちが「メンテナンス中」になった

2026年10月21日（水）の夜、日本中のWebサービスが次々と止まりました。pixiv、DMM.com、niconico、さくらインターネットの一部サービスが緊急メンテナンスに入り、「グランブルーファンタジー」や「ウマ娘 プリティーダービー」といった人気ゲームも一時停止。ネットショップの「BASE」や保育施設向けの「コドモン」も午後からメンテナンスに入っていました。

21時55分には高市総理がXで「今夜対応してほしい大至急のお願い」として、PHPを使っているサイトの確認と、修正パッチをすぐ当てられない場合はサイトの一時停止も有効な手段だと呼びかけました。一国の総理大臣が、特定のプログラミング言語の脆弱性について深夜に直接呼びかける。これは前代未聞の事態です。

海外でも同じことが起きていました。オランダでは行政ポータルや電子認証「DigiD」、議会のサイトまでがオフラインに。米国の人事SaaS「BambooHR」は給与処理の中断を告知してサービスを止めました。

原因は、世界のWebサイトの約7割が使うプログラミング言語「PHP」そのものに見つかった、2件の重大な脆弱性。通称「PHP2Shell」です。

この記事では、世界中の公式発表・研究者のレポート・報道をもとに、何が起きたのか、なぜここまでの騒ぎになったのか、そして私たちは何をすべきなのかを順を追って解説します。最後には、山梨でAI活用やDXに取り組む事業者の方に向けたお知らせもありますので、ぜひ最後までお読みください。

2年前の「兆候」から緊急リリースまで

一言でまとめると、2024年に兆候が見つかっていた欠陥を、2026年夏にAIを使った研究者たちが「実際に乗っ取れる」と証明し、10月22日の公表予定が情報漏れで1日前倒しになった、という流れです。

  • 2024年：PHP初の本格的な外部セキュリティ監査中に、コア開発者がメモリ不足（OOM）処理の問題の兆候を発見。ただし攻撃経路は理論上のものにとどまり、修正方針が決まらず停滞
  • 2026年7月30日：セキュリティ企業Calif（カリフ）が、OpenAIの支援プログラムの一環としてPHPの監査を開始
  • 8月11日：CalifとOpenAIが、同じ根本原因による遠隔コード実行（RCE）をそれぞれ独立に報告
  • 8月19〜24日：Wiz ResearchがAIを使って脆弱性を発見し、WordPress・Drupalでの乗っ取りを確認してPHPに報告
  • 10月21日 0時ごろ：2件のCVE番号がネット掲示板やSNSで出回る（誤ったCVSS 10.0と誤った日程つき）
  • 10月21日 4時30分：PHPが公式に事前告知。リリースを22日から21日へ1日前倒し
  • 10月21日 5時ごろ：報告者の一社Califが、攻撃の実証（PoC）動画を誤って公開
  • 10月21日 16時41分：配布業者Chainguardが、約束の時刻より6時間以上早く修正入りイメージを公開
  • 10月21日 午後〜夜：国内サービスの予防停止が相次ぐ。21時55分に高市総理が注意喚起
  • 10月21日 23時：PHP 8.5.12／8.4.27／8.3.36／8.2.35 を公開。米CISA・英NCSCなどが即時更新を要請
  • 10月21日 23時19分：監視企業watchTowrが、実際の攻撃の試みを観測と発表
  • 10月22日：一部の研究者が、初期設定のままのPHPには公開済みの攻撃コードが通用しないと分析し、大規模悪用の見立てを下方修正

時刻は各社発表のUTC表記を日本時間（+9時間）に換算しています。出典：PHP財団、Wiz、The Hacker News、Sansec

そもそもPHPとは？なぜ1つの言語でここまで大騒ぎになるのか

PHPは、Webサイトの「裏側」で動くプログラミング言語です。ページを表示するとき、ログイン情報を確認したり、データベースから記事や商品を取り出したりする処理をサーバー上で担当しています。1994年に生まれ、30年以上Webを支えてきました。

一般の利用者がPHPに直接触れることはほとんどありません。しかし、次のような身近な仕組みの多くがPHPの上で動いています。

  • WordPress：ブログや企業サイトで最も使われているCMS
  • Drupal・Joomla：行政・大学・大規模サイトで使われるCMS
  • MediaWiki：Wikipediaを動かしているソフトウェア
  • Laravel・Symfony：業務システムやWebサービス開発で人気のフレームワーク

調査会社W3Techsの2026年10月の集計では、サーバー側の言語が判別できたWebサイトの69.3％がPHPを使っています。

「アプリ」ではなく「エンジン」が壊れていた

今回のポイントは、問題がWordPressなどのアプリ側ではなく、PHPという実行環境そのものにあったことです。車にたとえると、ボディや内装（アプリ）ではなく、エンジン（PHP）に欠陥が見つかったようなもの。どんなに丁寧に作られたサイトでも、古いPHPの上で動いていれば影響を受けます。研究者によれば、「Hello World」と表示するだけの最小のページでも攻撃対象になりえました。

さらに、PHPには「古いバージョンを使い続けている現場が多い」という構造的な弱点があります。2026年の業界調査では、PHPチームの40％がサポート切れ（EOL）のバージョンを運用中と報告されていました（Zend 2026 PHP Landscape Report）。この「裾野の広さ」と「更新の遅さ」の掛け算が、今回の騒ぎを大きくしました。

PHP2Shellの正体：2つの脆弱性をやさしく解説

2件とも、ログイン不要で、外部からサーバー上の任意のプログラムを実行できる（RCE）可能性がある脆弱性です。深刻度はCVSS v4.0で両方とも9.2（緊急）。根っこにあるのは、PHPが「メモリ不足」や「致命的エラー」で処理を途中で打ち切られたときの後片付けの不備でした。

ホテルの客室にたとえると

PHPのサーバーは、同じ作業員（ワーカー）が次々とやってくるリクエストを順番に処理する、ホテルの客室係のような仕組みです。

本来は、お客さん（リクエスト）が帰るたびに部屋を完全に片付けます。ところが、お客さんが「緊急退去」（メモリ不足やエラーで強制終了）すると、片付けが中途半端なまま次のお客さんを通してしまうことがありました。前の客の荷物や鍵が残った部屋を、悪意ある次の客が利用できてしまう。これが今回の問題の本質です。

CVE-2026-109618：OOM（メモリ不足）による破損でのRCE

  • 何が起きるか：メモリ上限にちょうど悪いタイミングで達すると、作りかけの内部データが残り、後で「正常なデータ」として扱われる
  • 実証された被害：WordPress・Drupal・Joomlaでの認証なしRCE。サーバーのメモリ内容（他人のパスワードやAPIキーなど）の読み出し

CVE-2026-109619：古いグローバル状態によるRCE

  • 何が起きるか：致命的エラーの後、すでに解放された前回リクエストのメモリを次のリクエストが使ってしまう（Use-After-Free）
  • 実証された被害：Drupal・WordPressでの認証なしRCE。OPcache（高速化機能）の共有データ破壊

特に怖いのは「メモリ覗き見」

CVE-2026-109618では、コードを実行するまでもなく、サーバーのメモリの中身をCookie経由で盗み見られる手口も実証されました。2014年に世界を震撼させた「Heartbleed」と同じタイプの被害です。メモリには、他の利用者のパスワード、ログイン用トークン、APIキー、証明書などが残っている可能性があります。しかもアプリ側でセッション機能を使っていなくても成立しました。

影響を受けるバージョンと修正版

Wizによると、過去10年以上のほぼすべてのPHP（PHP 5.4以降）が少なくとも一方の影響を受けます。PHP公式は、修正版より前のすべてのリリースを影響範囲としています。

  • PHP 8.5：8.5.12 で修正（サポート中）
  • PHP 8.4：8.4.27 で修正（サポート中）
  • PHP 8.3：8.3.36 で修正（サポート中）
  • PHP 8.2：8.2.35 で修正（2026年12月31日でサポート終了）
  • PHP 8.1以前：公式の修正版なし（サポート終了済み。7.4／8.0／8.1はソース向けの修正パッチのみ公開）

動かし方による危険度の違いもあります。最も危険なのはApacheのmod_phpで、アプリのコードが動く前に、1回のリクエストで攻撃が成立することが示されました。PHP-FPMは失敗したワーカーを終了させるため挙動が異なりますが、アプリの処理内容によってはRCEに到達することが確認されています。php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するすべての形態が対象です（The Hacker News、PHP財団）。

世界と日本の反応：政府も企業も「先に止める」を選んだ

今回の対応で目立ったのは、パッチ公開前から「サービスを止めて守る」判断が世界中で同時に下されたことです。

各国のセキュリティ当局

  • 米国：CISAが即時パッチ適用を強く要請。NSAも、攻撃者がサーバーのファイルやデータベースに直接アクセスできる恐れがあるとして準備を呼びかけ
  • 欧州：CERT-EUがPHP 5以降に影響の可能性があるとして注意喚起。英国NCSCは、すぐ直せない場合はシステムのオフライン化も検討するよう要請
  • その他：シンガポール、オーストラリア、カナダの当局も同様の警告を発出
  • 日本：IPAが「事前準備のお願い」を公表。国家サイバー統括室も、すぐにパッチを当てられない場合はサイトの一時停止がリスク低減策になると発信し、高市総理がこれを引用する形でXに投稿

企業・インフラ側の動き

国内では先に触れたpixiv、DMM.com、niconico、さくらインターネット、Cygamesのゲーム群などが予防的に停止。一部の自治体もシステム停止を予告しました。海外ではオランダの行政・教育システムや米BambooHRが止まっています。

一方、インフラ企業は「すぐ更新できない人を守る」準備を進めていました。Cloudflare、AWS、Google Cloud、Microsoft、Fastly、Akamai、Vercelなどが、公開前から研究者と連携して防御ルールや手順書を用意。Cloudflareは日本時間21日昼にWAFルールを全顧客で既定有効にしています。

実際に攻撃はあったのか（10月23日時点）

結論から言うと、攻撃の「試み」は観測されているが、特定のサーバーが侵害されたという確定報告はまだない、というのが主要な情報源の大勢です（Patchstackのように悪用事例を確認したとする企業もありますが、被害の詳細はまだ明らかになっていません）。

  • Cloudflareはパッチ公開前から初期の攻撃を確認し、攻撃者がWAFを回避しようと手口を変えてくる様子も観測
  • watchTowrは、自社のハニーポット網で両CVEへの攻撃の試みを観測
  • Amazonも、修正公開日に複数の攻撃コードによる試行を検知
  • 一方、CISAは警告発表時点で悪用を確認しておらず、既知の悪用脆弱性カタログ（KEV）にも未掲載
  • 10月22日にはSansecが、攻撃には標的サーバーの具体的な知識や条件が必要で、公開済みの攻撃コードは初期設定のPHPには効かないとして、大規模悪用の可能性を下方修正

ただし「大規模悪用が起きにくい」ことは「放置してよい」ことを意味しません。条件を満たすサーバーは確実に存在し、AIの力で攻撃の調整が容易になっている点が、今回の最大の特徴だからです。

発見の裏側：AIが「10年以上眠っていた欠陥」を掘り起こした

今回の事件が「AI時代の転換点」と呼ばれる理由は、欠陥そのものは昔からあったのに、それを実際の攻撃に変える難しさをAIが一気に下げた点にあります。

人間だけでは手が届かなかった

メモリの不具合を実際の乗っ取りにつなげるには、複数のバグを組み合わせ、標的ごとに異なるメモリ配置に合わせて何度も試行錯誤する必要があります。Wizはこれを「人間の研究者が実用的に到達できる限界ぎりぎり」の作業だったと説明しています。

そこを変えたのが最先端のAIモデルです。Wizは自社のAI研究基盤「Wiz Atlas」に加え、Googleの「Gemini 4 Argon」とOpenAIの「GPT-5.6 Sol」を使用。研究者1人が約1週間で、従来なら世界トップクラスのチームが数カ月かけていた作業を終えたとしています。特にGemini 4 Argonが、発見から攻撃コードの開発、検知、修正の検証まで大きく貢献したと述べています（Wiz）。

3つのチームが同じ穴にたどり着いた

発見者はWizだけではありません。

  • Calif：OpenAIの支援プログラム「Patch the Planet」の一環でPHPを監査し、8月11日に無条件のRCEを報告
  • OpenAI（Codex Securityチーム）：同じ日に、同じ根本原因を独立に報告。9月にも追加の攻撃経路を報告
  • Wiz Research：8月24日に別の攻撃経路を報告

PHP財団側も、これ以前にAnthropicの「Claude Mythos」によるコードスキャンを実施し、現在はOpenAIのツールなども報告や攻撃コードの検証に使っています。

それでも「人間の知見」は必要だった

興味深いのは、Califが、現在のAIモデルは20年前の無名な手法から確実に出発できるわけではない、と指摘している点です。Califはこのバグの系譜を2004年のPHP研究までさかのぼっており、対象の歴史を知る人間の知識と、AIの試行錯誤の速さが組み合わさって初めて成果につながった、という見方です（The Hacker News）。

守る側にも「報告の洪水」が押し寄せている

AIは守る側の負担も変えています。PHPのセキュリティチームは2026年7月1日以降に15件のCVEを公開する一方、無効・重複・再現不能だった報告を100件以上処理してきました。AIは報告の検証や同じ原因の報告のグループ化を助けていますが、最終判断と修正はすべて人間が行っています。見つける速度が上がるほど、直す人の数が問題になる。これが次の章のテーマにつながります。

混乱を広げた「リーク」と、PHP財団が認めた「構造的な失敗」

10月21日に公開されたPHP財団のブログは、異例の率直さでした。修正が遅れたのは自分たちの意思決定の仕組みと人手不足による「構造的な失敗」だったと認めたうえで、公表直前の混乱についても経緯を明かしています（PHP財団）。

2年間、修正が止まっていた理由

2024年、PHPはドイツ政府系のSovereign Tech Agencyの資金で、久しぶりの外部セキュリティ監査を受けました。その修正作業中に、コア開発者が今回のメモリ不足問題の兆候に気づきます。しかし当時は具体的な攻撃経路が見つからず、他の明確な問題が優先されました。

修正案はいくつも作られましたが、どれも「後方互換性が壊れる」「新たなサービス妨害の穴が開く」「無数の拡張機能に変更を強いる」といった副作用を抱えていました。全会一致を原則とする少人数のセキュリティチームは決めきれず、作業は数カ月にわたって止まっては再開を繰り返したといいます。

財団は現在、多数決で決められ、妥協を促す仕組みへ手順を改め、深刻な問題が膠着した場合は早い段階で財団の指導部に上がるようにしています。2026年5月には「エコシステム・セキュリティチーム」を新設し、7月と9月にはトリアージや堅牢化を担う人員も加わりました。

公表2日前に崩れた「協調開示」

通常、重大な脆弱性は「修正版が全員に行き渡る準備ができた時点で一斉に公表する」協調開示という手順で扱われます。今回はそれが直前で崩れました。

  1. CVE番号の流出：技術的な中身は漏れなかったものの、CVE番号が誤った深刻度（10.0）と誤った日程とともにネットに出回った
  2. PoC動画の誤公開：報告者の一社Califが、攻撃が成功する様子を映した動画を誤って公開。すぐ削除されたが、複製がSNSで拡散し、各地で攻撃コードの開発を加速させた
  3. 修正版の先行公開：配布業者Chainguardが、約束の時刻より6時間以上早く修正入りのイメージを公開。攻撃者が修正内容を解析できる状態を、他の利用者より先に作ってしまった

財団は特にChainguardについて、数週間にわたる多くの関係者の努力を無視したと名指しで批判しています。一方で、各ディストリビューションには事前にパッチが渡されていたため、多くの利用者が公表と同時に更新できる状態にはなっていました。

背景にある「担い手不足」

PHP財団は、2021年に中心的な開発者が離脱したことをきっかけに、JetBrainsやAutomatticなど10社が設立した組織です。当時から「エンジンの深部を理解している人が数人しかいない」ことが課題とされてきました。

財団は今回のブログを、PHPに依存する企業・ホスティング事業者・政府機関への資金支援の呼びかけで締めくくっています。ツールがバグを見つける速度は上がり続けますが、互換性の判断を下し、修正をレビューできる熟練エンジニアは依然として少ないからです。

今すぐやるべき対応策：立場別チェックリスト

対策の結論はシンプルです。PHP本体を修正版（8.5.12／8.4.27／8.3.36／8.2.35）以上に更新し、PHPを再起動すること。完全な対策はこれしかありません。 PHPのコア開発者も、公開前の段階から「唯一の対策は更新だ」と繰り返し強調していました。

よくある勘違い：WordPressの更新では直らない

WordPressやLaravelなどのアプリを最新にしても、その下で動くPHP本体は更新されません。PHPはサーバーのパッケージ、レンタルサーバー事業者、またはコンテナイメージから提供されるものです。「サイトは最新だから大丈夫」は通用しない点に注意してください。

全員共通

  • 自分のサイトやサービスがPHPで動いているか確認する（WordPress、EC-CUBE、Drupalなどを使っていればほぼ該当）
  • 動いているPHPのバージョンを確認する（管理画面、php -v、レンタルサーバーのコントロールパネルなど）
  • バージョンが修正版より古ければ、以下の立場別の手順で更新する

レンタルサーバー・マネージドサービスを使っている人

  • 事業者のお知らせページで、PHP2Shell（CVE-2026-109618／109619）への対応状況を確認する
  • コントロールパネルでPHPのバージョンを選べる場合、サポート中のブランチ（8.3以上が望ましい）に切り替える
  • 8.1以前を選んでいる場合は、サイトの動作確認をしたうえで新しいバージョンへ移行する

自分でサーバーを管理している人

  • OSのパッケージ（apt、dnfなど）でPHPを更新する。ディストリビューションは古いバージョン番号のまま修正を取り込むことがあるため、番号ではなく変更履歴にCVE番号があるかで判断する
  • Apache、PHP-FPM、常駐型のPHPワーカーをすべて再起動する（再起動しないと古いコードがメモリに残る）
  • Dockerなどのコンテナは、修正版のベースイメージで作り直して再デプロイする
  • 更新後、memory_limitとpost_max_sizeの設定を見直す（修正で新しい厳格なメモリ上限が加わり、上限到達時はプロセスが終了して終了処理が走らなくなるため）

サポート切れ（PHP 8.1以前）を使っている人

  • 公式の修正版は出ないことを前提に、移行計画を最優先で立てる
  • 7.4／8.0／8.1はソースコード向けの修正パッチが公開されているため、自前ビルドや長期サポート業者の提供を待つ場合の当座しのぎに使う
  • PHP 8.2も2026年12月31日でサポート終了のため、今のうちに8.3以上への移行も計画する

すぐに更新できない場合の暫定策と、侵入されたかもしれない時のサイン

以下はあくまで特定の攻撃経路を狭める「時間稼ぎ」で、サーバーを安全にするものではありません。PHPの公式アドバイザリもその点を明言しています。更新までのつなぎとして使い、できるだけ早く本対策に移ってください。

PHPの設定でできる暫定策

CVE-2026-109619への暫定策

  • 設定：session.upload_progress.enabled=0 にして、すべてのワーカーを再起動。PHP 8.5は fatal_error_backtraces=0 も設定
  • 注意点：確認済みの経路は塞げるが、他の変種は防げない。CVE-2026-109618には効果なし

CVE-2026-109618への暫定策

  • 設定：アプリ側で上書きできないよう memory_limit=-1 に固定し、post_max_size を小さく保つ。Webサーバーやプロキシ側でリクエストサイズを制限する
  • 注意点：RLIMIT_AS／RLIMIT_DATA での代用は、同じ脆弱な経路を引き起こしうるため使わない

公開前に「session.upload_progress.enabled を切れば大丈夫」という情報が広く出回りましたが、リリース時の公式情報で、これが完全な対策ではなかったことが確認されています。

設定以外の暫定策

  • WAF（Webアプリケーションファイアウォール）を有効にする：Cloudflare、AWS、Fastly、Akamaiなどが専用ルールを提供済み。ただしCloudflareは、攻撃者がルールの回避を試みていることを確認しており、あくまで一時しのぎと位置づけています
  • サイトを一時停止する：国家サイバー統括室や英NCSCが示したとおり、すぐ更新できない重要なサイトは、更新できるまで止めることも有効な選択肢です

侵入されたかもしれない時のサイン

この攻撃はアプリより下の層で起きるため、アプリのログにはほとんど痕跡が残りません。サーバー側の唯一の手がかりが、エラーログに1行だけ出るメモリ上限エラーで、ノイズとして見過ごされがちだと指摘する研究者もいます。研究者たちは、次のような兆候に注意するよう呼びかけています。

  • 不自然なマルチパート（ファイル送信形式）のリクエストの直後に、メモリ上限エラーやHTTP 500エラーが繰り返し出ている
  • レスポンスの PHPSESSID Cookieが、異常に大きい、または形が崩れている
  • 原因不明のPHPワーカーの再起動が頻発している

自分のサーバーが影響を受けるかの確認には、Searchlight Cyberが公開したオープンソースのスキャナーや、OpenAIが公開したCodex用のチェック機能なども使えます。

もし侵入の疑いがある場合は、更新だけでは不十分です。今回の脆弱性はメモリ内のパスワードやAPIキーを盗み見られる可能性があるため、データベースのパスワード、APIキー、各種トークンの再発行（ローテーション）も検討してください。

これからPHPとどう付き合っていくか

PHP2Shellは、2014年のHeartbleed、2021年のLog4Shellに続く「インターネットの土台が揺らいだ事件」として記憶されることになるでしょう。ただし、今回の教訓は「PHPは危ないから使うのをやめよう」ではありません。PHPチームは根本原因から修正し、すべての変種をまとめて塞ぐ修正版を、サポート中の全ブランチに同時に届けました。問題は言語ではなく、私たちの「更新の習慣」と「オープンソースの支え方」にあります。

今後に向けて、押さえておきたいポイントは4つです。

  1. 「難しいから大丈夫」は通用しなくなった AIによって、複雑すぎて現実的ではないとされてきた脆弱性も、短期間で攻撃に転用できる時代になりました。これからは「パッチが出たら数時間〜数日で当てる」ことを前提に、更新の手順と体制を整えておく必要があります。
  2. バージョン管理を「年中行事」にする 今回、公式の修正が届いたのはPHP 8.2以降だけでした。8.2も年末でサポートが終わります。サポート期限をカレンダーに入れ、期限の半年前には移行を始める。自動更新やコンテナの定期再ビルドを仕組みに組み込む。地味ですが、これが最も効く対策です。セキュリティ対策もDX（デジタルトランスフォーメーション）の一部として仕組み化することが、これからの企業には欠かせません。
  3. 「止める判断」と「多層防御」を準備しておく 政府や大手サービスが「先に止める」を選んだように、すぐに直せない時に止められる体制も防御の一部です。WAF、ログ監視、秘密情報のローテーション手順など、更新以外の層も平時から用意しておきましょう。
  4. 使っているオープンソースを支える 世界のWebの約7割を支えるPHPのセキュリティは、ごく少数の開発者に依存しています。PHPで事業をしている企業や自治体にとって、PHP財団への支援は寄付ではなく「自社の安全への投資」と考えるべき段階に来ています。

AIは攻撃者の武器であると同時に、守る側にとって10年以上見逃されてきた欠陥を見つけ出す強力な味方にもなりました。今回の事件は、その両面を世界に示した最初の大事件です。企業のAI活用も同じで、正しく使えば大きな武器になり、知らずに使えばリスクにもなります。見つかる速度が上がった今、問われているのは「直す速度」と「直す人を支える仕組み」。まずは今日、あなたのサイトのPHPのバージョンを確認するところから始めてみてください。

山梨の企業にとって今回の事件が意味すること

ここからは、山梨県でAI活用・DX・Web制作の支援を行い、山梨AIコミュニティ「AIスタートクラブ」を運営するAI企業、株式会社Localabilities（ローカルアビリティーズ）としての考えをお伝えします。

私たちは普段から県内の企業の現場に入り込み、最新のAIを実際に触りながら仕事をしています。その立場から見ると、今回の事件には山梨の企業や事業者にとって3つの大きなメッセージがあると考えています。

考察1：一番危ないのは「作ったきり」の地方のWebサイト

今回、大手サービスはパッチ公開の数時間前に、自らサービスを止める判断ができました。専任の技術者と監視の体制があるからです。

一方で、地方の中小企業や個人事業主のホームページは、制作会社に作ってもらったまま「サーバーやPHPを誰が管理しているのか分からない」というケースが少なくありません。私たちが現場で感じている課題です。業界調査では全体の4割がサポート切れのPHPを使っていましたが、地方ではこの割合がさらに高いのではないかと危惧しています。

Webサイトは「作って終わり」ではなく、「保守して育てていくもの」です。今回の事件は、そのことを全国規模で突きつけたと私たちは受け止めています。

考察2：AIは攻撃者だけの武器ではない。使う側に回ることが最大の防御

研究者1人がAIを使って、1週間でトップチームの数カ月分の仕事を終えた。これは裏を返せば、悪意のある側も同じ道具を使えるということです。

だからこそ、企業はAIを「よく分からないから怖い」と遠ざけるのではなく、使いこなす側に回るべきだと考えます。実際、今回の欠陥を見つけて修正につなげたのも、AIを使った「守る側」の研究者たちでした。

中小企業でも、AIを使えば最新のセキュリティ情報の要約、自社の環境に当てはめた確認ポイントの整理、更新手順の下調べなど、これまで専門家に頼むしかなかった作業の入り口に立てます。私たちがAI活用をおすすめしているのは、業務効率化のためだけではありません。「変化の速さについていく力」を会社として身につけるためでもあります。

考察3：情報の速さと「気軽に聞ける相手」が明暗を分ける

今回は、情報が漏れてから修正版が出るまで1日足らずでした。多くの企業が、夜のうちに「止めるか、待つか」の判断を迫られました。英語の一次情報をすぐに読み、自社に当てはめて判断できたかどうかで、対応に大きな差が出たはずです。

PHP財団は、エンジンの深部を理解する人が少ないことを「構造的な弱点」として認めました。実は同じ構図が、地域の企業の中にもあります。「ITに詳しいのは社内で1人だけ」「その人が休むと誰も分からない」。地方の企業にとって最大のリスクは、技術そのものより「誰に聞けばいいか分からない」ことかもしれません。

だからこそ私たちは、地域で知見を持ち寄り、気軽に聞き合える場が必要だと考え、山梨AIコミュニティ「AIスタートクラブ」を運営しています。

私たちがこれから取り組むこと

  • 今回のような重大なAI・Webのニュースを、山梨の事業者向けにかみ砕いて発信し続けます
  • 企業の現場に入り、AI活用とDXを「導入して終わり」にせず、運用・保守まで伴走します
  • AIスタートクラブを通じて、山梨でAIやWebについて気軽に聞ける場を広げていきます

山梨でAI活用・DXに取り組む企業・事業者の皆さまへ

たとえば、こんなお悩みはありませんか？

  • 自社のホームページがPHPやWordPressで動いているのか分からない、更新を誰に頼めばいいか分からない
  • AIを業務に取り入れたいが、何から始めればいいか分からない
  • DXと言われても、自社に合った進め方が見えない
  • 社内にAIやWebに詳しい人がいない

山梨県内でお困りの企業・事業者・事業主の方は、どんな小さなことでもお気軽にご相談ください。山梨AIの「身近な相談窓口」として、現場目線で一緒に考えます。

📩 ご相談・お問い合わせ：【ここに問い合わせ先（フォームURL・SNSなど）を記載】

「まずは気軽に話してみたい」という方は、毎週水曜日に開いているもくもく会にもぜひお越しください。詳しくは下のお知らせをご覧ください。

CINOVAでAIもくもく会を開催中！

山梨AIコミュニティ「AIスタートクラブ」では、毎週水曜日に山梨スタートアップ支援センター「CINOVA」で、ゆる〜くAIのもくもく会をやっています！

  • 📅 日時：毎週水曜日 12:00〜18:00
  • 📍 場所：山梨スタートアップ支援センター CINOVA 2階 カフェスペース「CAFE LAPEX」
  • 💰 参加費・予約：どちらも不要です

💻 こんなことをしています（10月14日の例）

  • AIを使った副業についての壁打ち
  • AIブログの作成、Discord
  • VS Code × Obsidianの連携
  • その他、AIに関する情報交換や雑談

セミナーではなく、自由に作業したり交流したりする気軽なもくもく会です！

こんな方にぴったりです

AIに興味はあるけど、

  • 「何から始めたらいいかわからない」
  • 「聞きたいことがあるけど、聞ける人がいない」
  • 「ネットの情報は色々あるけど、結局何がいいの？」

そんな方も多いと思います。

僕たちは普段から最新のAI情報を調べたり、実際に触って試したりしています。せっかくなので、普段の作業やミーティングのついでに、気軽に交流できる場所があったらいいなと思って始めました😊

AIの専門家とちょっと雑談してみたい方、作業しながら質問してみたい方、AIの経営や副業にお悩みの方、大歓迎です！AIやWebについての質問も、もちろんOK。今回の記事のような「うちのサイトは大丈夫？」といったWebやセキュリティの相談、AI活用やDXの進め方の相談も、作業の合間に気軽にどうぞ。

12:00〜18:00の間、CAFE LAPEXにいますので、お時間がある方はぜひ気軽にお声がけください☕️

ふらっと立ち寄って、PC作業だけでも大歓迎です！

参考情報