AI時代のOSSサプライチェーン防衛「Akrites」とは｜Linux Foundation主導・主要20社連携でAI脆弱性発見の高速化に立ち向かう

「自社で使っているソフトの中身なんて、ほとんど見たことがない」。そう感じた方こそ、今回の話は落ち着いて読んでほしい内容です。私たちが日々使うシステムの土台には、無数のオープンソースソフトウェア（OSS＝誰でも中身を見られ、無償で使える共有の部品）が組み込まれています。そのOSSが、AIによって脆弱性を一気に見つけられる時代に入り、守り方の前提が変わり始めています。

2026年6月25日、Linux Foundation（世界中のOSS開発を支える非営利団体）が、業界をリードする企業・組織とともに「Akrites（アクリテス）」という取り組みを発足しました。AIを使ったサイバー脅威から、社会の基盤となる重要なOSSを守るための連携の枠組みです。AWS・Google・Microsoft・OpenAI・Anthropic・NVIDIAをはじめとする主要20の企業・組織が名を連ねており、業界横断の防衛網として注目を集めています。

この記事では、Akritesが何を解決しようとしているのかを一次情報から整理し、なぜ「AIによる脆弱性発見」が攻撃側を有利にしてしまうのかを攻撃者視点で分解します。そのうえで、OSSを使う側の中小企業や情シスが、自社のサプライチェーン（部品の供給網）をどう守ればよいのかを、明日から着手できる手順に落とし込みます。攻撃の流れを取り上げるのは、あくまで防御のためです。敵がどこから来るかを知らなければ、塞ぐべき穴も見えてきません。正しく知れば、過度に恐れる必要はありません。

Akritesとは何か｜AI時代のOSS防衛イニシアチブ

まず事実関係を一次情報ベースで整理します。Akritesは、Linux Foundationが2026年6月25日に発足を発表した、OSSの脆弱性を「悪用される前に」見つけ、修正し、責任を持って開示するための業界連携イニシアチブです。特定の製品や単一の脆弱性ではなく、業界全体で脆弱性に対応するための「仕組み」そのものを指します。

発足メンバーには、Amazon Web Services、Anthropic、Chainguard、Cisco、Citi、Endor Labs、Ericsson、Google、IBM、JPMorganChase、Microsoftと傘下のGitHub、NVIDIA、OpenAI、RapidFort、Red Hat、Rust Foundation、Sonatype、Vodafone、Zscalerといった、クラウド・AI・金融・通信・半導体にまたがる主要20の企業・組織が参加しています。AIの開発をリードする企業と、社会インフラを担う企業が同じテーブルに着いた点に、この取り組みの本気度が表れています。

名前の「Akrites（アクリテス）」は、かつて辺境を守った国境警備隊に由来するとされ、「重要な境界線を守る」という役割を象徴しています。守るべき対象は、世界中のシステムが当たり前のように依存している、けれど少人数のボランティアが支えていることも多い、重要OSSです。

では、Akritesは具体的に何を変えようとしているのでしょうか。これまでOSSの脆弱性対応は、プロジェクトごとに窓口も手順もバラバラでした。発見者がどこへ報告すればよいか分からなかったり、同じ脆弱性に重複した報告が殺到してメンテナーが疲弊したり、修正が出る前に詳細が漏れて悪用されたり――こうした「調整の不在」が、対応の遅れを生んできました。Akritesは、この調整役を業界が共同で引き受けることで、報告から修正、公表までを一本の流れに整える狙いを持っています。攻撃側がAIで速くなったぶん、守る側も「速く、漏らさず、確実に」直せる体制を作ろう、という発想です。

なぜ今なのか｜AIが「脆弱性発見の速さ」を攻撃側に与えた

では、なぜこのタイミングで業界横断の防衛網が必要になったのでしょうか。背景には、AIが脆弱性発見のスピードを劇的に引き上げたという構造変化があります。ここを攻撃者視点で見ると、危機感の正体がはっきりします。

1. フロンティアAIは主要OSSを「数分」でスキャンできる

Linux Foundationは発足にあたり、最先端のAIモデルが主要なOSSプロジェクトをスキャンし、未知の脆弱性を短時間で表面化できるようになった、という現状認識を示しています。これは防御側にとっては監査の効率化という恩恵ですが、同じ能力が攻撃側の手にも渡る、という意味でもあります。一部報道では、こうしたAIによる脆弱性発見を象徴する存在として「Mythos」のような名称も挙げられていますが、ここで重要なのは個別のツール名より、「発見が自動化され、高速化した」という事実そのものです。

2. 攻撃者から見た「マイナス7日」という優位

攻撃者の立場で考えてみます。これまでは、脆弱性が公表され、修正が出てから、攻撃コードが作られるまでにタイムラグがありました。守る側には、その間に対応する猶予があったわけです。ところがAIが発見と攻撃コード作成を高速化すると、この順番が逆転しかねません。一部報道では、脆弱性が公表される前に悪用が始まってしまう状況を「マイナス7日」と表現しています。修正が公開された瞬間ではなく、その手前から攻撃が始まる――つまり「パッチが出てから動く」では間に合わない局面が現実味を帯びてきた、ということです。

3. なぜOSSサプライチェーンが狙われるのか

攻撃者は、もっとも効率の良い場所を狙います。一つの重要OSSに脆弱性があれば、それを部品として使う何千、何万ものシステムが一度に影響を受けます。守る側からすれば、自社が直接書いたコードは管理できても、その下にある無数のOSS部品まで把握できているケースは多くありません。この「見えていない依存」こそが、攻撃者にとっての近道です。守りの観点では、まず「自分が何に依存しているか」を可視化することが出発点になります。

もう一つ、攻撃者にとって都合がよいのが「メンテナーの手薄さ」です。社会の基盤を支える重要なOSSでも、実際に維持しているのは少人数のボランティアであることが珍しくありません。報告された脆弱性に手が回らず、修正が遅れれば、その間は無防備な状態が続きます。攻撃者はこの「修正までの空白」を狙ってきます。Akritesが「持ち主のいない重要部品」への対応を掲げているのは、まさにこの空白を業界全体で埋めようとしているからです。

Akritesはどう守るのか｜共有SIRTと調整型開示の仕組み

Akritesは、バラバラだった脆弱性対応を「一つの信頼できる窓口」に束ねることで、攻撃側のスピードに対抗しようとしています。発表された仕組みを、防御の観点から整理します。

・共有SIRT: 参加組織が共同で運営するセキュリティインシデント対応チーム（SIRT＝Security Incident Response Team）が、脆弱性の調整役を担う
・調整型の脆弱性開示（CVD）: 報告から修正、公表までの手順を標準化し、修正が整う前に情報が漏れて悪用される事態を防ぐ
・機密保持を最優先: 修正が行き渡るまで詳細を絞り、攻撃者に先回りされないようにする
・業界標準ツールの活用: CVE・CVSS・EPSS・VEXなど、脆弱性の識別・深刻度評価・悪用可能性評価の標準的な指標を用いて、対応の優先順位を共通言語で扱う
・メンテナーの負担軽減: 同じ脆弱性に重複報告が殺到してメンテナーが疲弊する事態を避け、検証済みの修正提案に集中できるようにする

とりわけ大きいのが、メンテナー不在の重要パッケージへの対応です。社会基盤を支えるOSSの中には、もはや活発な維持管理者がいないものもあります。そうした「持ち主のいない重要部品」について、Akrites自身が修正の主体となって動く方針が示されています。攻撃者から見れば、誰も守っていない部品は格好の的です。その的を、業界が肩代わりして守る――ここがこの取り組みの核心と言えます。

OSSを使う企業側の防御策｜攻撃者の近道を塞ぐ

Akritesは業界全体の防衛網ですが、それで自社の守りが自動的に固まるわけではありません。OSSを使う側にも、やるべきことがあります。攻撃者の近道を一つずつ塞いでいきましょう。

1. 自社のOSS依存を可視化する（SBOM）

最初の一歩は、「自社のシステムが何に依存しているか」を一覧にすることです。これを支えるのがSBOM（エスボム＝Software Bill of Materials、ソフトウェアの部品表）です。どのOSSを、どのバージョンで使っているかが分かって初めて、「あの脆弱性は自社に影響するのか」を判断できます。逆に言えば、部品表がなければ、脆弱性が公表されても自社が該当するかどうかすら分かりません。攻撃者は、その「分からない」状態を突いてきます。

2. 脆弱性情報を追える状態にする

次に、脆弱性情報が自社に届く経路を整えます。利用しているOSSの公式アナウンスや、JVN（日本の脆弱性情報ポータル）、各ディストリビューションのセキュリティ情報を定期的に確認できるようにしておきます。Akritesのような枠組みが整うことで、今後は「検証済みで信頼できる脆弱性情報」が届きやすくなることが期待されます。情報が来てから慌てるのではなく、来る前に受け皿を用意しておくことが大切です。

3. 検知と対応の手順を先に決めておく

「マイナス7日」の時代には、脆弱性が判明してから対応手順を考えていては遅れます。あらかじめ、誰が情報を受け、誰がパッチ適用を判断し、誰が業務影響を確認するのか――その役割と順番を決めておきます。攻撃者は、組織の意思決定の遅さを突いてきます。手順が決まっていれば、いざという時の初動が大きく変わります。

4. 「もう入られている前提」で痕跡も確認する

重要な脆弱性は、対応に動く前にすでに突かれている可能性があります。とくにAIによる発見が高速化した今は、「公表前から狙われていたかもしれない」という前提で構えるのが安全側の判断です。パッチを当てて終わりにせず、該当するシステムのログに不審なアクセスや想定外の通信が残っていないかを、あわせて確認してください。判断に迷う場合は、保守委託先やインシデント対応の専門事業者へ早めに相談するのが現実的です。守りは、塞ぐことと、すでに入られていないかを確かめることの両方でワンセットになります。

中小企業でも今日からできること

専任のセキュリティ担当がいなくても、優先度の高い順に着手できます。次のチェックリストから始めてください。

・依存の棚卸し: 自社の主要システムが、どのOSSにどれだけ依存しているかをまず書き出す（簡易なSBOMで充分）
・更新の習慣化: 利用OSSのバージョンを定期的に確認し、修正版が出たら適用する流れを作る
・情報経路の確保: JVNや利用OSSの公式情報を、担当者が定期的に確認できるようにする
・役割の明確化: 脆弱性が判明したとき、誰が判断し誰が動くのかを事前に決めておく
・相談先の確保: 自前で判断が難しい場合に相談できる保守委託先・専門事業者の連絡先を、平時のうちに押さえておく

Akritesは、いわば「上流」を守る取り組みです。けれど、その守りを自社の安全につなげるには、「下流」である自分たちの側で受け皿を整えておく必要があります。上流と下流の両方がそろって、はじめてサプライチェーンの守りは機能します。

よくある疑問（FAQ）

Q1. Akritesは特定の脆弱性やパッチのことですか？

いいえ、特定の脆弱性や製品ではありません。OSSの脆弱性を業界横断で見つけ、修正し、責任を持って開示するための「連携の枠組み（イニシアチブ）」です。2026年6月25日にLinux Foundationが主要20の企業・組織とともに発足を発表しました。何か一つを適用すれば終わり、という性質のものではない点に注意してください。

Q2. 自社はOSSを使っている自覚がないのですが、関係ありますか？

関係がある可能性は高いです。市販のソフトやクラウドサービスの多くは、内部に多数のOSSを部品として組み込んでいます。「直接ダウンロードした覚えがない」だけで、間接的に依存しているのが一般的です。まずは利用システムの依存関係を棚卸しし、自社が何に依存しているかを把握することをおすすめします。

Q3. AIで脆弱性が見つかるなら、攻撃側が一方的に有利になりませんか？

AIの能力は攻撃側にも防御側にも等しく使えます。攻撃側に発見の速さを与える一方で、防御側も監査や検知を効率化できます。問題は「速さの勝負」になったときに、個別対応では追いつきにくい点です。Akritesのような業界連携は、まさにその速さに集団で対抗するための取り組みだと理解すると分かりやすいです。

Q4. 「マイナス7日」とは何を意味するのですか？

一部報道で使われている表現で、脆弱性が公に発表される「前」から悪用が始まってしまう状況を指します。従来は公表・修正のあとに攻撃が来る前提で対応できましたが、AIによる発見と攻撃コード作成の高速化により、その猶予が削られつつあるという危機感を表した言い回しです。「パッチが出てから動く」だけでは間に合わない場面が増える、という警鐘と捉えてください。

Q5. 中小企業がまず取り組むべきことは何ですか？

第一に、自社が使っているOSSの棚卸し（簡易なSBOMの作成）です。何に依存しているかが分かれば、脆弱性情報が出たときに自社が該当するかを素早く判断できます。次に、修正版が出たら適用する習慣づくりと、脆弱性が判明したときの役割分担を事前に決めておくことです。大がかりな投資より、まず可視化と手順の整備から始めるのが現実的です。

Q6. Akritesができたら、もう自社で対策しなくてよいのですか？

そうではありません。Akritesはあくまでも「OSSの上流」を守る取り組みです。その守りを自社の安全につなげるには、利用する側が脆弱性情報を受け取り、適用し、運用する受け皿を整えておく必要があります。上流の整備と自社の運用は、どちらか一方では完結しません。両輪で考えてください。

Q7. なぜAIやクラウドの大手と金融・通信の会社が一緒に参加しているのですか？

OSSへの依存が、業種を問わず社会全体に広がっているからです。AIを開発する企業は自社サービスの土台としてOSSを使い、金融や通信のように社会インフラを担う企業は止められないシステムの中でOSSに依存しています。脆弱性の影響が一社にとどまらず連鎖する以上、立場の違う企業が同じ枠組みで守るほうが合理的だ、という判断です。発見の速さでリードするAI企業と、守るべき基盤を持つインフラ企業が同席している点に、この取り組みの意味が表れています。

本記事のまとめ

Akritesは、AIが脆弱性発見を高速化した時代に、重要OSSを「悪用される前に」守るための業界横断イニシアチブです。Linux Foundationが2026年6月25日に、主要20の企業・組織とともに発足しました。共有SIRTによる一元化された窓口、調整型の脆弱性開示、機密保持の徹底、そして持ち主のいない重要OSSへの対応――これらを束ねることで、攻撃側の速さに集団で対抗しようとしています。

攻撃者から見れば、誰も守っていない部品や、可視化されていない依存関係は「壊す必要すらない、開いたままの扉」です。上流ではAkritesがその扉を閉じにかかり、下流である私たちは、自社の依存を可視化し、情報経路と対応手順を整えることで足元の扉を閉じる。両方がそろって、はじめてサプライチェーンの守りは機能します。AIの発見スピードを過度に恐れる必要はありません。落ち着いて、可視化・情報経路・手順の順で、できるところから守りを固めていきましょう。