AI駆動開発とセキュリティ|PHP脆弱性「PHP2Shell」が示したAI時代の守り方

「AI駆動開発」とは、設計・プログラムの実装・レビュー・テストといったシステム開発の工程全体にAIを組み込み、人が要所で判断しながら品質を確かめていく開発の進め方です。

情報漏えいのニュースが連日のように報じられるなか、2026年10月にはプログラミング言語「PHP」の重大な脆弱性(PHP2Shell)が公表され、首相が異例の呼びかけを行い、銀行や航空会社、緊急速報メールまでが一時停止する事態になりました。この脆弱性を見つけたのはAIです。「AIが書いたコードは危ないのでは?」という声も耳にします。たしかにAIは、攻撃する側に大きな力を与えています。しかし同じAIは、守る側にとっても欠かせない存在になりつつあります。

この記事のポイント

  • 大規模な情報漏えいが過去に例のないペースで起きており、AIは攻撃の力を大きく押し上げている
  • 2026年10月のPHP脆弱性(PHP2Shell)は、10年以上前のコードに潜んでいた穴をAIが見つけた象徴的な出来事
  • 「AIのコードが危ない」と言われる主な理由は、設計やレビューを省いた作り方にある
  • 昔からある品質管理の手法をAIで徹底すれば、人の手だけでは難しかった量の確認ができる
  • システムの守りに加え、アカウント管理や権限設計など「人と仕組み」の対策も欠かせない

この記事では、公的機関や調査会社の公表データをもとにAI時代のセキュリティの現状を整理し、そのうえでエレファンキューブがAI駆動開発で何を大切にしているのかをお伝えします。

目次

いま、情報漏えいはどれくらい起きているのか

結論から言うと、件数よりも「1回あたりの規模」が急速に大きくなっています。

東京商工リサーチの調査によると、2025年に上場企業とその子会社が公表した個人情報の漏えい・紛失事故は180件で、漏えいした個人情報は3,063万6,910人分でした。件数は前年より4.7%減ったものの、人数は前年比93.1%増と約2倍になっています。原因でもっとも多かったのは「ウイルス感染・不正アクセス」の116件で、全体の6割以上を占めました。

2026年に入ると、状況はさらに深刻になっています。同社によると、100万件以上の漏えいは10月5日の時点で10件に達し、2025年通年の6件をすでに上回りました。主な事例は次のとおりです。

公表した企業内容件数
佐川急便「お荷物問い合わせサービス」への不正アクセス最大約5,323万件(重複を含む・流出の可能性)
KDDIプロバイダー向けメールシステムへの不正アクセスメールアドレス1,223万1,954件
物語コーポレーション「焼肉きんぐ」公式アプリの会員情報1,078万8,963件
タイムズモビリティ運転免許証の画像を含む本人確認書類情報が漏えいした可能性約660万件(アカウント数)
出典:東京商工リサーチ「TSRデータインサイト」(2026年10月7日・10月23日公表)をもとに作成

佐川急便の件数は、同社の集計でそれまで最大だった2014年の約3,504万件を上回り、過去最多となりました。また1,000万件以上の漏えいは、2025年までの14年間で3件だったのに対し、2026年は10月23日までに8件(速報値)確認されています。

注目したいのはKDDIの事例です。報道によると、原因はシステムの一部として導入していた他社製ソフトウェアの、まだ知られていなかった弱点(脆弱性)を突かれたことでした。自社で作った部分をどれだけ固めても、組み込んだ部品に穴があれば攻撃は成立してしまいます。

こうした流れは、公的機関の評価にも表れています。情報処理推進機構(IPA)が毎年発表している「情報セキュリティ10大脅威 2026」の組織編では、「AIの利用をめぐるサイバーリスク」が初めて選ばれ、いきなり3位に入りました。IPAはその中身として、AIの悪用によって攻撃がしやすくなり、手口が巧妙になっていることなどを挙げています。

なぜ「AIがセキュリティを脅かしている」と言われるのか

漏えい事故のうち、AIがどれだけ関わっていたかを示す統計はまだありません。ただ、AIが攻撃する側の力を大きく押し上げていることは、複数の事実から読み取れます。理由は大きく2つあります。

1. 人間が何十年も見つけられなかった「穴」をAIが見つける

2026年4月、AI開発企業のAnthropic社は、まだ一般公開していないAIモデル「Claude Mythos Preview」についての発表を行いました。同社によると、このモデルは主要なOSやWebブラウザすべてで深刻度の高い脆弱性を見つけており、そのなかには次のようなものが含まれていました。

  • 安全性の高さで知られるOS「OpenBSD」に、27年間気づかれずに残っていた脆弱性
  • 動画処理ソフト「FFmpeg」に16年間残っていた脆弱性。自動テストが該当の行を500万回通っても見つけられなかったもの
  • Linuxの中核部分にある複数の弱点を組み合わせ、一般ユーザーの権限からマシン全体を乗っ取れる経路

同社は、AIが脆弱性を見つけて悪用する能力において、ごく一部の熟練者を除けば人間を上回る段階に達したと説明しています。なお、これらの脆弱性はすでに修正済みと公表されています。

2. 専門知識がなくても「攻撃する環境」をつくれてしまう

2024年5月、警視庁は生成AIを使ってランサムウェア(データを暗号化して身代金を要求する不正プログラム)を作成したとして、川崎市の男性を逮捕しました。生成AIを使ったマルウェア作成での逮捕は国内初の事例です。トレンドマイクロ社の解説によると、この男性にはIT企業での勤務経験など、専門性を身につけやすい経歴は特にありませんでした。同年10月には有罪判決が出ています。

海外でも同じような動きが報告されています。Anthropic社が2025年8月に公表した脅威レポートでは、ある犯罪者がAIのコーディングツールを使い、偵察から侵入、データの持ち出しまでを自動化して、少なくとも17の組織を恐喝しようとした事例が紹介されました。同じレポートには、AIの助けがなければ自分ではコードを書けないとみられる人物が、ランサムウェアをつくって販売していた事例も載っています。

これまで高度な攻撃には、長い経験と専門知識が必要でした。AIはその壁を一気に低くしてしまったのです。

2026年10月のPHP脆弱性「PHP2Shell」では何が起きたのか

PHP2Shellは、Webサイトづくりに広く使われているプログラミング言語「PHP」で見つかった2件の重大な脆弱性(CVE-2026-109618、CVE-2026-109619)の通称です。悪用されると、外部から認証なしで不正なプログラムを実行されるおそれがあり、2026年10月21日に開発元が修正版を公開しました。

見つけたのはAIだった

この脆弱性は、米OpenAIとセキュリティ企業のWiz、Califの3社が公表しました。発見者のひとりであるCalif社の解説によると、調査にはAIを相棒として使い、最初の発見は2026年8月1日でした。影響を受ける箇所は、十数年前の「PHP 5.4.0」の時代のコードまでさかのぼるとされています。

CNNの報道によると、Wiz社は「研究者1人が1週間で完了できた」と説明する一方、悪用を実証するには、人間の研究者が現実的にたどり着ける限界に近い複雑な手順が必要だったと述べています。長年使われてきたコードの奥に眠っていた穴を、AIが短期間で掘り当てた。まさにこの記事の前半でお伝えした流れを、日本中が体感した出来事でした。

首相の呼びかけと、相次いだ「予防的なサービス停止」

修正版の公開に合わせて、IPAは10月21日に事前準備を呼びかけ、国家サイバー統括室もPHPを使っているかの確認と速やかな修正を求めました。同日夜には高市早苗首相がXで迅速な対応を呼びかけ、サイトの一時停止もリスクを減らす方法のひとつだと発信しました。首相自身の公式サイトも、対応のため一時的に閲覧できない状態にされています。

これを受けて、多くの企業や団体が、被害が出る前にサービスを止めて修正する「予防的な停止」に踏み切りました。

  • ANAはグループ会社の情報サイトを、JALは一部のWebページや周辺サービスを一時停止(運航や予約システムには影響なしと説明)
  • 国内の銀行や証券会社、ゲーム会社などでも一時停止の動き
  • ソフトバンクは、国や自治体の災害・避難情報を届ける緊急速報メールの配信をメンテナンスのため停止し、10月26日夜にすべて再開

情報漏えいの被害は出たのか

公表の時点で、IPAはこの脆弱性を悪用した攻撃を確認していないとし、情報発信は予防的なものだと説明していました。その後、米国のサイバーセキュリティ・社会基盤安全保障庁(CISA)は10月26日、実際に悪用された証拠がある脆弱性のリストにPHP2Shellを追加しています。一方、国内でこの脆弱性が原因の情報漏えいが公式に確認されたという発表は、筆者が確認した範囲ではまだありません。

つまり、被害が広がる前に「見つける → 直す」が間に合った面がある一方で、修正が公開されると攻撃する側もすぐに動き出すことがはっきりしました。IPAも、攻撃者が極めて短い時間で攻撃してくる可能性があるとして、修正版の早期適用を求めています。

今回いちばん問われたこと

PHP2Shellで多くの組織が直面したのは、「そもそも自社のどのサイトやシステムでPHPが使われているのか、すぐに答えられない」という問題でした。IPAも最初の対策として、PHPを使っているものの棚卸しを挙げています。使っている部品を把握できていなければ、修正どころか影響の判断もできません。私たちのAI駆動開発では、設計書や構成の記録を丁寧に残すことを重視しています。どの部品のどのバージョンを使っているかがわかっていれば、今回のような緊急時にも、止めるべきものと止めなくてよいものをすばやく見きわめられます。

「AIに対抗できるのもAI」とはどういうことか

攻撃にAIが使われる以上、守る側も人の手作業だけでは追いつけません。脆弱性を見つける力は、悪用する人の手にあれば脅威になり、守る人の手にあれば強力な道具になります。

先ほどのAnthropic社は、Claude Mythos Previewの能力を守りに使うため、「Project Glasswing」という取り組みを立ち上げました。Amazon Web Services、Apple、Google、Microsoft、Linux Foundationなどが参加し、世界中で使われている重要なソフトウェアの脆弱性を、攻撃者より先に見つけて直すことを目指しています。2026年10月には、審査を通ったセキュリティ専門家が高度なAIを利用できる制度も拡充されました。

先ほどのPHP2Shellも、AIを使った守る側の調査で見つかり、開発元と連携して修正版の準備が整ってから公表されたものです。つまり、世界の大手IT企業はすでに「AIで攻めてくる相手には、AIで守る」という方向に舵を切っています。これはシステムを発注する企業にとっても、他人事ではありません。

「AIが書いたコードは危ない」は本当か

この噂には、根拠になっている調査があります。ただし、条件をよく見ることが大切です。

セキュリティ企業のVeracode社が2025年に発表した調査では、100種類以上のAIモデルに80個のプログラミング課題を解かせたところ、45%のケースでセキュリティ上の欠陥を含むコードが書かれました。これは、安全な書き方と危険な書き方のどちらも選べる課題で、AIが危険なほうを選んだ割合です。同社の技術責任者は、開発者がセキュリティの条件をはっきり伝えずにAIにコードを書かせる傾向を問題として指摘しています。

ここで関わってくるのが「バイブコーディング」という言葉です。2025年2月にAI研究者のアンドレイ・カーパシー氏が名づけたもので、AIに「こんなものを作って」と伝え、生成されたコードの中身を細かく確かめずに受け入れながら作っていくスタイルを指します。

バイブコーディングは、アイデアをすぐ形にして確かめたいとき、たとえば試作品(プロトタイプ)づくりには、とても役に立つ方法です。一方で、設計やレビューを省くぶん、安全面の確認は甘くなりがちです。「AIのコードが危ない」と言われる原因の多くは、AIそのものではなく、確認の工程を飛ばした作り方にあると私たちは考えています。

バイブコーディングとAI駆動開発の違い

エレファンキューブでは、バイブコーディングと区別して、自分たちの開発を「AI駆動開発」と呼んでいます。違いは、AIを使うかどうかではなく、品質を確かめる工程をどれだけ踏むかにあります。

比べる点バイブコーディングエレファンキューブのAI駆動開発
進め方思いついた順に、対話しながら作る設計書をつくり、計画にそって作る
設計のチェック省かれることが多い複数のAIが別々の観点でレビューし、最後は人が承認する
コードのチェック動けばOKとなりやすい書き換えるたびに、決められた数百〜千を超える項目を確認する
テスト動作を目で見て確かめる程度になりがち数千通り規模のパターンを検証し、人が必ず確認する項目も設ける
セキュリティ後回しになりやすいAIの知見を使い、さまざまな角度から攻撃を想定して確かめる
向いている用途試作品・個人の小さなツール企業の業務システムなど、安全性が求められるもの

じつは、AI駆動開発でやっていることは、まったく新しい手法ではありません。システム開発の世界で長年培われてきた「設計→レビュー→実装→何段階ものレビュー→大量のテスト」という品質管理の流れを、そのままAIで実行しているのです。

エレファンキューブのAI駆動開発では何をしているのか

AIが登場する前、品質の高いシステムをつくるには、エンジニアの力を惜しみなく注ぐ必要がありました。複数人で設計書を読み合わせ、コードを書いたら別の人が何段階もチェックし、何百通りものテストを行う。どれも欠かせない工程ですが、人の時間には限りがあり、確認できる量にはどうしても上限がありました。

AI駆動開発では、この「手間」をAIで再現し、さらに量を大きく増やしています。

従来の開発とAI駆動開発の手間のかけ方の比較 設計レビュー、コードチェック、テストの3工程について、従来の人中心の開発とエレファンキューブのAI駆動開発を比べた図。設計は複数人のレビューから複数のAIによる別観点のレビューと人の承認へ、コードチェックは人による数段階のレビューから変更ごとの数百〜千を超える項目の確認へ、テストは数百通りが限界だった検証から数千通り規模の検証と人による必須確認へ広がる。 同じ工程でも、かけられる「手間」がちがう 従来(人が中心) AI駆動開発 設計 レビュー 複数人で 設計書を読み合わせ 複数のAIが別々の観点でレビュー + 人が最終承認 コード チェック 別の人が 何段階もレビュー 書き換えるたびに 数百〜千を超える項目を確認 テスト 数百通りが 現実的な限界 数千通り規模のパターンを検証 + 人が必ず確認する項目 ※項目数・パターン数は案件の規模や内容によって変わります
図:従来の開発とAI駆動開発の「手間のかけ方」の比較(エレファンキューブ作成)

設計:複数のAIが別々の観点でレビューし、人が承認する

設計書ができたら、役割の異なる複数のAIが、それぞれ別の観点から内容を確かめます。使いやすさ、データの扱い方、セキュリティ上の弱点になりそうな箇所など、1人のレビュアーでは見落としやすい点も、観点を分けることで拾いやすくなります。そのうえで、設計を承認するのは必ず人です。何をつくるか、どこまでを守るかという判断は、お客さまの業務を理解した人間が責任をもって行います。

実装:コードを書き換えるたびに、決められた項目をすべて確認する

人によるレビューでは、変更のたびにすべてを見直すのは現実的ではありませんでした。AI駆動開発では、コードを1か所書き換えるたびに、あらかじめ決めておいた数百〜千を超えるチェック項目を確認します。小さな修正が別の場所に思わぬ影響を与えていないかも、毎回確かめられます。

テスト:数千通り規模の検証と、人が必ず確認する項目

人の手によるテストは、どれだけエンジニアを割り当てられるかによって現実的な限界値がありました。AIを使うことで、数千通り規模のパターンを1日かからず検証できます。セキュリティの面でも、AIが持つ攻撃手法の知見を活かし、「攻撃する側ならどこを狙うか」という角度からも確かめます。なお、テスト工程には、人が必ずチェックする項目を設けています。AIに任せきりにせず、最後の確認は人の目で行うのが私たちのルールです。

ひとことで言えば、AI駆動開発は「人が開発するよりも、はるかに多くの手間をかけられる開発」です。その手間こそが、品質と安全性を支えています。

システムを固めても防げない「人」と「仕組み」のリスク

ここまでシステムやプログラムの守りについて説明してきましたが、それだけで安心はできません。サーバーやプログラムをどれだけ強固にしても、AIを使った攻撃はそれを突破しようとしてきます。そして、たった1人のミスや1つのアカウントの管理漏れから、全顧客の情報が流出することもあります。

先ほどの東京商工リサーチの2025年の調査でも、「誤表示・誤送信」(20.5%)と「紛失・誤廃棄」(10.0%)を合わせて、約3割が人のミスに起因するものでした。従業員による「不正持ち出し・盗難」も3.8%あります。IPAの10大脅威 2026でも、「内部不正による情報漏えい等」が7位に入っています。

そのため、システムの開発とあわせて、次のような「人と仕組み」の対策が欠かせません。

対策具体的にやること
アカウントの後始末退会した利用者や退職した社員のアカウントを、決まったルールで確実に削除する
管理者への教育管理用アカウントを持つ人に、定期的にセキュリティ教育を行う
権限の絞り込み仕事に必要な範囲を超えて、情報を見たり操作したりできないよう権限を設定する
持たない設計そもそも必要以上の個人情報を集めない・保存しないサービス設計にする

とくに最後の「持たない設計」は見落とされがちです。持っていない情報は、漏れようがありません。どの情報を本当に保存する必要があるのかを設計の段階で見直すことは、もっとも確実な対策のひとつです。AI駆動開発では設計書を丁寧につくるため、こうした検討を開発の初期にしっかり行えます。

なお、管理者向けのセキュリティ教育は、eラーニングを3,000件以上制作してきたエレファンキューブが本来得意とする分野でもあります。システムと教育の両面から守りを固めることが、私たちの考えるセキュリティ対策です。

まとめ:AIを使わないことのほうがリスクになる時代

AIは、人間が長年見つけられなかった穴を見つけ、専門知識のない人にも攻撃の手段を与えてしまいました。2026年10月のPHP2Shellは、その現実を社会全体に突きつけた出来事でした。すでに攻撃する側がAIを使っている以上、守る側が人の手だけで立ち向かうのは、ますます難しくなっています。

「AIが書いたコードは危ない」という声の背景には、確認の工程を省いた作り方があります。逆に言えば、設計・レビュー・テストという昔ながらの品質管理をAIで徹底すれば、人だけで開発するよりも多くの確認を積み重ねられます。

だからこそ私たちは、AIを使わないことのほうがリスクであると考えています。セキュリティを高めるためにも、エレファンキューブはAI駆動開発をおすすめしています。

よくある質問

Q. AIが書いたコードは、そのまま使っても大丈夫ですか?

A. 確認をしないまま使うのはおすすめできません。調査では、安全な書き方と危険な書き方を選べる場面で、AIが危険なほうを選んだケースが45%あったと報告されています。大切なのは、設計・レビュー・テストの工程を踏んで確かめることです。

Q. PHPの脆弱性「PHP2Shell」とは何ですか?

A. 2026年10月21日に公表された、プログラミング言語PHPの2件の重大な脆弱性(CVE-2026-109618、CVE-2026-109619)です。悪用されると外部から不正なプログラムを実行されるおそれがあります。AIを使った調査で見つかり、首相の呼びかけや多くのサービスの一時停止につながりました。PHPを使っている場合は、修正版への更新が必要です。

Q. バイブコーディングとAI駆動開発の違いは何ですか?

A. バイブコーディングは、AIと対話しながら思いついた順に作っていく方法で、試作品づくりに向いています。エレファンキューブのAI駆動開発は、設計書をもとに計画的に進め、複数のAIによるレビューや大量のテスト、人による承認と確認を組み込んだ開発の進め方です。

Q. AI駆動開発では、人はチェックしないのですか?

A. いいえ。設計の承認は必ず人が行い、テスト工程にも人が必ずチェックする項目を設けています。AIには量の多い確認を任せ、判断と最終確認は人が担います。

Q. 中小企業でも、AIを使った攻撃の対象になりますか?

A. なり得ます。AIによって攻撃の手間とコストが下がったため、規模を問わず狙われるリスクがあります。また、取引先や委託先を経由した攻撃は、IPAの10大脅威 2026でも2位に挙げられています。

Q. システム以外に、まず取り組むべき対策はありますか?

A. 退会者・退職者のアカウント削除、管理者へのセキュリティ教育、必要最小限の権限設定、必要以上の情報を持たない設計の4つから見直すことをおすすめします。どれも新しいシステムを入れなくても、社内のルールや設定の見直しから始められます。

安全な業務システムを、AI駆動開発で。

教材制作3,000件超のエレファンキューブが提供する「elephanAI」では、設計段階のご相談から開発・テスト・運用保守まで、品質とセキュリティを重視したAI駆動開発をご提供しています。「いまのシステムの守りが心配」「AIで開発したいが安全性が気になる」といったご相談も歓迎です。

まずは相談する elephanAIを見る

参考資料

最終更新日: 2026-11-06