2026年4月、Anthropic は、一般には公開していないAIモデル Claude Mythos Preview を使って、深刻なを数千件見つけたと発表しました。主要なOSとWebブラウザのすべてで弱点が見つかっています。最も古いものは、OpenBSD というOSに27年間残っていた不具合です。同じ報告には、見つけたものの99%超がまだ直っていない、とも書かれています。
この知らせを見て、Linux や WordPress のような無料ので自社のサーバーや開発環境を動かしている会社では、このまま使い続けてよいのかと不安を感じた担当者もいると思います。ソースコードを誰でも読めるということは、AI にも読まれるということだからです。このシリーズは全6本で、その不安に順番に答えていきます。1本目のこの記事は、全体の答えと、残り5本で扱う内容の紹介です。
AI がすぐに弱点を見つける時代に、無料のオープンソースで動かしている自社のサーバーや開発環境を、このまま使い続けてよいのか。答えは、使い続けてかまいません。オープンソースの時代は終わりませんが、守り方は変わります。AI は公開されていないソフトの弱点も見つけるので、コードを隠しても守れません。対策は、動かしている機能が少ないこと、乗っ取られても管理者の権限を渡さないこと、開発用のパソコンを個人のものと分けること、更新しないまま放置しないことの4つです。
この記事の調べ方
AI による脆弱性の発見については、Anthropic の研究報告と Project Glasswing の発表、Google Project Zero のブログ、米国国防高等研究計画局（DARPA）の発表を読み、数値はそれぞれの原文と照らし合わせました。オープンソースの歴史は、Linux Foundation と Apache HTTP Server プロジェクトの公式の説明をもとにしています。はてなベースでは、Mythos Preview をはじめとするAIで脆弱性を探す実験は試していません。
弱点を見つける速さが、直す速さを追い越した
少し前まで、ソフトの弱点を探すのは人の仕事でした。経験を積んだ技術者がソースコードを1行ずつ読み、たとえばの大きさを超えてデータを書き込んでしまう箇所を探していました。見つけた弱点が本当に悪用できるかを確かめる作業にも、さらに時間がかかりました。弱点を探せる人は限られ、見つかる数にも限りがありました。
ところが、2024年から2026年の2年ほどで、この状況が変わりました。下の表は、AI が弱点を見つけた主な出来事を、発表した組織の説明から並べたものです。
| 時期 | 発表した組織 | 起きたこと |
|---|---|---|
| 2024年11月 | Google（Project Zero と DeepMind） | AI の仕組み Big Sleep が、データベースのソフト SQLite に悪用できる不具合を見つけた。正式な配布の前だったため、利用者に影響は出なかった |
| 2025年8月 | DARPA | AI で弱点を探して直す競技会 AIxCC の決勝で、出場したAIが仕込まれた弱点63件のうち54件を見つけ、43件を直した。仕込んだもの以外に、実在する弱点も18件見つけた |
| 2026年4月 | Anthropic | Claude Mythos Preview が深刻な弱点を数千件見つけた。主要なOSとWebブラウザのすべてで見つかり、99%超は報告の時点で未修正 |
表のとおり、2024年は1件の発見がニュースになり、2025年は競技会の中で数十件、2026年には数千件になりました。DARPA の発表では、AI が直す案を出すまでの時間は平均45分、作業1件あたりの費用は平均でおよそ152ドルでした。Anthropic は、セキュリティの専門教育を受けていない社員が夜に Mythos Preview へ依頼し、翌朝には実際に動く攻撃の手順ができあがっていた例も報告しています。
一方で、直す側の速さは変わっていません。オープンソースの弱点を直すのは、そのソフトを作っている開発者です。Apache のように、有志が集まって運営しているプロジェクトも多くあります。Anthropic 自身も、開発者の手に負えない量の仕事を一度に送らないよう報告の出し方を調整していると書いています。見つかる数が数千件に増えても、直せる数は急には増えません。
さらに、直したあとにも別の問題が残ります。Anthropic の報告は、公開された修正を読めば弱点の場所が分かる、と指摘しています。弱点に付けられた識別番号と、修正したコードの変更記録だけを渡しても、AI が攻撃の手順を自動で書けたからです。修正が出たのに更新していないサーバーは、以前よりずっと早く狙われることになります。報告は、ソフトを使う側と管理する側に、安全のための更新を反映するまでの時間を縮めるよう求めています。
オープンソースが広がったのは、人手の足りなさを補えたから
多くの会社がオープンソースを使うようになった経緯を振り返ります。1991年8月25日、Linus Torvalds が、趣味で作り始めた無料のOSのことをネットの掲示板に書き込みました。これが Linux の始まりです。1995年には、Web サーバーのソフトを手直しする有志が集まって Apache を作り、翌1996年には Web で最も多く使われるサーバーのソフトになったと、Apache の公式の説明にあります。
Linux と Apache がそろったことで、会社は高いライセンス料を払わずに Web サーバーを立てられるようになりました。2005年に Tim O'Reilly は「Web 2.0」という言葉で、利用者が書き込み、共有する新しい Web のサービスを整理しました。同じ文章の中で O'Reilly は、多くの Web サーバーを動かしている Linux、Apache、MySQL などがオープンソースの共同開発で作られていると指摘しています。資金の少ない会社でも、アイデアがあれば Web のサービスを始められる時代を支えたのは、オープンソースでした。
オープンソースが選ばれたもう1つの理由は、1社では集められない数の人手を借りられることです。Apache の説明には、世界中の有志がインターネットで連絡を取り合い、計画を立て、開発していると書かれています。世界中の技術者が、自分の使うソフトの不具合を自分で直し、その修正を全員で分け合う仕組みです。多くの人がコードを読めば不具合は早く見つかる、という考え方が、オープンソースの安全を支えてきました。
AI の登場で変わったのは、この「読む人の数」です。これまでは、コードを読む人の多くが守る側にいました。今は、攻撃したい人も AI に読ませれば、熟練した技術者と同じ速さで弱点を探せます。読む目が多いことは、もう守る側だけの強みとは言えません。差が出るのは、見つかった弱点を直して、自社のサーバーに反映するまでの速さです。
コードを隠しても、AI からは守れない
「公開されているから読まれるのなら、公開していないソフトに替えればよい」と考える方もいるはずです。ところが Anthropic の報告では、Mythos Preview は公開されていないWebブラウザやOSでも弱点を見つけています。配布された実行ファイルから、元のソースコードに近いものを組み立て直すこともできたと書かれています。ソースコードを隠しても、AI が弱点を探す手間は大きくは変わりません。
隠すことには、別の不利もあります。オープンソースなら、世界中の開発者や Google、Anthropic のような会社が弱点を探して開発者に知らせ、誰でも修正を提案できます。公開していないソフトでは、弱点を直せるのは作った会社だけです。その会社の対応が遅ければ、使う側は待つしかありません。一方で、オープンソースには実際に直す人が少ないという弱さもあります。両方の点は、シリーズ2本目の「コードを隠せば安全なのか」で詳しく扱います。
そのため、考えるべきなのは、コードを見られるかどうかより、弱点を見つけられたときに何が起きるかです。弱点が見つかっても、そもそも動いていない機能なら悪用できません。悪用されても、そのプログラムに管理者の権限がなければ、サーバー全体は取られません。守りの中心が、隠すことから、余計なものを削ることへ移るのはこのためです。
図の4つの対策は、それぞれ違う場面に備えるものです。修正が出ている弱点を残さないこと、弱点のある機能をそもそも動かさないこと、乗っ取られたときに取られる範囲を狭めること、そして開発者のパソコンから会社の中へ入られないようにすることです。どれか1つで全部を防ぐことはできないので、4つを重ねます。以下、4つを簡単に説明します。詳しくは各記事をご覧ください。
古いまま動いているものを残さない
Web サイトや社内システムは、Web サーバーのソフト、データベース、プログラムを動かすための部品など、多くのソフトを組み合わせて動いています。サイトの見た目は毎月のように直していても、その下で動いている部品は作ったときのまま、という例は珍しくありません。で動かしている場合は、入れ物の中の部品が古いままでも外からは見えにくくなります。
先に触れたとおり、公開された修正を読めば弱点の場所が分かります。修正が出てから何か月も更新していない部品は、AI にとって最も狙いやすい場所です。新しい弱点を探す手間すら要らず、公開された修正を読ませるだけで攻撃の手順を作れるからです。
まず、どの部品がどれだけ古いかを一覧にし、更新の手順を決めておきます。シリーズ3本目の「本当に危ないのは古いまま動いているもの」で、古い部品の見つけ方と、更新を止めないための仕組みを書きます。引き継いだ WordPress がある場合は、引き継いだWordPressで最初に見る10項目も参考になります。
動かす機能を減らす
サーバーで動いているプログラムの1つ1つが、弱点を探される場所です。普通のOSには、文書の編集、ほかのパソコンへの接続、印刷など、Web サーバーには要らない機能が最初からたくさん入っています。使っていなくても、動いていれば弱点を探されます。
AI が弱点を探す速さが上がった今は、探される場所の数そのものを減らすほうが確実です。Web サーバーとして必要なプログラムだけを入れ、それ以外は入れない、という考え方の専用のOSも出てきています。入っていないプログラムの弱点は、どれだけ見つかっても悪用されません。
どの機能を残し、どれを外すかは、サーバーの役割によって変わります。機能を絞ったOSの考え方と、今のサーバーで外せる機能の見分け方は、シリーズ4本目の「Web サーバーに機能は要らない」で説明します。
乗っ取られても、管理者の権限は渡さない
Linux にはと呼ばれる権限があります。Web サイトのプログラムがこの権限で動いていると、そのプログラムの弱点を1つ突かれただけで、サーバー全体を操作されてしまいます。データベースの中身や、同じサーバーにあるほかのサイトのファイルも例外ではありません。
反対に、Web サイトのプログラムを、決められたフォルダしか触れない弱い権限で動かしていれば、乗っ取られても被害はそのプログラムの範囲で止まります。
プログラムごとに権限を決めるときの考え方は、シリーズ5本目の「乗っ取られても全部は取られない設計」で説明します。AI に作らせた社内ツールを公開する前の確認は、AIに作らせた社内ツールを公開前に確かめる7項目も合わせてご覧ください。
開発環境を個人のパソコンから分ける
守る対象はサーバーだけではありません。開発者のパソコンには、本番のサーバーへ入るための鍵、ソースコード、外部のサービスのパスワードが集まっています。そのパソコンで、私用のメールやブラウザ、個人で入れたソフトも動いていると、どれか1つの弱点から会社のサーバーまで入られます。
最近は、AI に開発を任せる道具が、開発者のパソコンの上でコマンドを実行し、ファイルを読み書きするようになりました。便利な反面、AI が読んだ文書の中に悪意のある指示が紛れていた場合、AI はその指示に従って、パソコンにある鍵やファイルを読み出すかもしれません。開発用の環境を、個人のパソコンや私用のアカウントから切り離しておけば、AI が読み出せる範囲を開発に要るものだけに絞れます。
開発用の環境をどこに置き、何を入れないかは、シリーズ6本目の「あなたのパソコンに開発環境が入っていませんか」で書きます。顧客企業に入り込んで開発する社外の技術者（FDE）を迎えるときの、端末とアカウントの用意は、FDE を迎える前に情シスが用意するもので扱っています。
まず自社で数えること
4つの守りを読んで、自社がどこまでできているかが気になった方は、まず数を確認してください。対策を考える前に数を出しておくと、どこから手を付けるかの順番が決めやすくなります。社内の情報システムの担当者か、サーバーを管理している委託先に、次の3つを聞けば答えが出ます。
- サーバーで、最も強い管理者の権限（root）のまま動いているプログラムはいくつあるか
- 1年以上更新していないソフトや部品は、サーバーとコンテナの中にいくつあるか
- 開発の道具や本番のサーバーへ入る鍵が入っている個人のパソコンは何台あるか
3つの数のうち、どれか1つでも「分からない」という答えだった場合は、そこが最初に手を付ける場所です。分からないものは、更新も権限の見直しもできないからです。数がゼロでなくても慌てる必要はありません。多いものから順に減らせば、弱点を見つけられたときの被害を小さくできます。
AI に破られやすくなった守り方の全体像は、AIに破られやすくなったセキュリティ対策ランキングにまとめています。弱点を探す力の強い AI を、Anthropic が防御する側にだけ渡している理由は、Project Glasswing の記事とMythos 5 の記事で扱いました。
オープンソースは、今後も会社のサーバーや開発で使われます。AI が弱点を見つける速さはこの先も上がりますが、4つの対策を続ければ、弱点を見つけられても大きな被害を受けにくくなります。まずは3つの数を出し、シリーズの2本目から順に読み進めてください。
Web サイトや社内ツールの危ない部分を一緒に調べます
管理者の権限のまま動いているプログラム、何年も更新していない部品、使っていないのに動いている機能。はてなベースでは、Web サイトや社内ツールのこうした部分を調べ、直すか作り直すかの判断から、実際の修正までをお手伝いしています。