← 記事一覧に戻る
AI全般·9分·2026年4月8日

Project Glasswing: Securing critical software for the AI era

Project Glasswing: Securing critical software for the AI era 【関連情報】公開ニュースやディスカッションの要点を補足して解説します。

SPECTRAL BLOG

Project Glasswing: Securing critical software for the AI era

Spectralの視点で整理したインサイトを、静かに読めるかたちでまとめています。

Project Glasswing:AIの時代に、重要なソフトウェアをどう守るか




1. イントロダクション


AIを使ったサービスや製品が、私たちの日常に静かに溶け込んでいます。医療の診断補助、金融の不正検知、交通インフラの制御——こうした場面では、AIが動くための「土台となるソフトウェア」が正確かつ安全に機能していることが前提です。


しかし最近、その土台そのものが攻撃対象になっているという事実が、セキュリティの専門家たちの間で注目を集めています。


Googleが主導する「Project Glasswing(プロジェクト・グラスウィング)」は、まさにこの問題に正面から向き合うための取り組みです。AIの時代において、重要なソフトウェアをどのように守るか——その問いに対する、一つの丁寧な答えを示そうとしています。


この記事では、専門的な背景知識がなくても理解できるよう、基礎から順を追って解説していきます。




2. 基礎知識・用語解説


まず、この話題を理解するために必要な言葉をいくつか整理しておきましょう。


「クリティカルソフトウェア」とは?


「クリティカル(critical)」とは、「重大な」「欠かせない」という意味です。クリティカルソフトウェアとは、社会や組織が正常に動くために不可欠なソフトウェアのことを指します。電力網の管理システム、病院の電子カルテ、銀行の決済システムなどが代表例です。これらが止まったり、誤作動したりすると、多くの人の生活や安全に直接影響が出ます。


「オープンソースソフトウェア(OSS)」とは?


ソフトウェアの設計図にあたる「ソースコード」が公開されており、誰でも自由に使ったり改良したりできるソフトウェアのことです。LinuxやPythonなどが有名です。世界中の開発者が協力して作るため品質が高い一方、「誰でも中身を見られる」ということは、悪意のある人も構造を把握しやすいという側面もあります。


「サプライチェーン攻撃」とは?


製品を作るための「部品の調達ルート(サプライチェーン)」に侵入する攻撃です。ソフトウェアの世界では、多くのアプリが他のソフトウェアの部品(ライブラリ)を組み合わせて作られています。その部品の一つに悪意のあるコードが混入されると、それを使っているすべてのアプリが影響を受けます。2020年に発覚した「SolarWinds事件」が代表的な例です。


「AIモデルのセキュリティ」とは?


AIそのものも、ソフトウェアの一種です。AIを学習させるためのデータや、学習済みのモデルファイルが改ざんされると、AIが意図しない動作をする可能性があります。これはAI特有の新しいセキュリティ課題として、近年急速に重要性が増しています。


「Project Glasswing」の名前の由来


グラスウィング(Glasswing)とは、翅(はね)が透明な蝶の一種です。「透明性(transparency)」と「脆さの中にある美しさ」を象徴するとも言われており、このプロジェクトが目指す「見える化」と「繊細な守り方」を表しているとも解釈できます。




3. トレンド分析


なぜ今、この取り組みが注目されているのか


Hacker NewsやRedditのセキュリティコミュニティでは、ここ数日、Project Glasswingに関連する議論が静かに広がっています。その背景には、いくつかの重なり合うトレンドがあります。


#### ① AIの普及がソフトウェアの「複雑さ」を急増させた


AIを活用したアプリケーションは、従来のソフトウェアと比べて、使用する外部部品(ライブラリ)の数が格段に多くなります。機械学習フレームワーク、データ処理ツール、モデル管理ツール——これらが複雑に絡み合うことで、「どこに脆弱性があるか」を把握すること自体が難しくなっています。


Hugging Faceのフォーラムでも、「モデルのダウンロード時に悪意のあるコードが埋め込まれていた」という報告が複数上がっており、AIモデルの配布経路そのものが攻撃対象になりつつあることが示されています。


#### ② オープンソースへの依存度が高まる一方、メンテナンスは追いついていない


世界中のソフトウェアの約96%が、何らかのオープンソースコンポーネントを含んでいるという調査結果があります(Synopsys, 2023年)。しかし、その多くは少数のボランティア開発者によって維持されており、セキュリティ上の問題が発見されても修正が遅れるケースが少なくありません。


2024年に発覚した「XZ Utils事件」は、この問題を鮮明に示しました。広く使われている圧縮ツールのメンテナーに、長期間かけて信頼を築いた上で悪意のあるコードを混入させるという、非常に手の込んだ攻撃でした。この事件はセキュリティコミュニティに大きな衝撃を与え、「信頼できると思っていたものが実は危険だった」という問題の深刻さを改めて認識させました。


#### ③ 政府・規制機関の動きも加速している


米国では、2021年に大統領令(EO 14028)が発令され、政府調達ソフトウェアに対してSBOM(Software Bill of Materials:ソフトウェアの部品表)の提出が求められるようになりました。EUでも「サイバーレジリエンス法」が2024年に成立し、デジタル製品のセキュリティ基準が法的に義務化される方向に進んでいます。


こうした規制の流れは、企業にとって「セキュリティは任意ではなく必須」という現実を突きつけています。


#### ④ Project Glasswingが提示するアプローチ


このような状況の中、Project Glasswingは「重要なオープンソースソフトウェアのセキュリティを、組織的・継続的に改善する」という方針を掲げています。単発の脆弱性修正ではなく、ソフトウェアが作られ、配布され、使われるまでの全過程(サプライチェーン全体)を対象にした、長期的な取り組みです。


コミュニティでは「これは正しい方向性だが、スケールできるかどうかが課題」という冷静な声も上がっており、理想と現実のギャップをどう埋めるかが今後の焦点になっています。




4. Spectralの見解


「守る」ということの意味が変わってきた


私たちSpectralがAI導入支援の現場で感じていることは、「セキュリティの問題は、AIを導入してから考えればいい」という認識がまだ根強く残っているということです。しかし、Project Glasswingが示すように、問題はAIを動かすための土台——つまりソフトウェアの構造そのものにあります。


AIシステムを安全に運用するためには、「AIモデルが正確かどうか」だけでなく、「そのAIを動かすソフトウェアが信頼できるかどうか」を同時に問う必要があります。


透明性こそが最初の一歩


Project Glasswingが重視しているのは、まず「何が使われているかを把握する」という透明性です。前述のSBOM(ソフトウェアの部品表)の概念がここに重なります。


自社のシステムにどのようなオープンソース部品が含まれているかを把握していない企業は、想像以上に多いのが現実です。「使っているとは知らなかった部品に脆弱性があった」という事態は、把握していなければ対処のしようがありません。


Spectralでは、AI導入プロジェクトの初期段階で必ず「ソフトウェア構成の棚卸し」を行うことを推奨しています。これは特別な技術が必要な作業ではなく、「今使っているものを一覧にする」という、地道ですが確実な作業です。


「完璧なセキュリティ」を目指さない


もう一つ重要な視点は、「完璧に守ることを目指すのではなく、問題が起きたときに素早く気づき、対処できる体制を作る」という考え方です。


攻撃の手口は日々進化しており、すべての脅威を事前に防ぐことは現実的ではありません。Project Glasswingも、この「検知と対応の速度を上げる」という方向性を重視しています。


これは企業にとって、セキュリティへの向き合い方を「壁を作る」から「センサーを張り巡らせる」へと転換することを意味します。


中小企業にとっての現実的な意味


大企業や政府機関だけの話ではありません。AIツールを業務に取り入れ始めた中小企業にとっても、使用しているクラウドサービスやAIプラットフォームのセキュリティ状況を把握しておくことは、リスク管理の基本です。「大きな会社が使っているから安全」という前提は、もはや成立しません。




5. 実践的アプローチ


今日から始められる、具体的な5つのステップ


Project Glasswingの考え方を、実際の業務にどう落とし込むか。ここでは、技術的な専門知識がなくても取り組めることから順に紹介します。




#### ステップ1:使っているソフトウェアの「部品表」を作る


まず、自社のシステムやAIツールに何が含まれているかを把握しましょう。開発チームがいる場合は、「SBOM(ソフトウェア部品表)を出力できますか?」と確認するだけで構いません。


SBOMを自動生成できるツールとして、「Syft」や「CycloneDX」などが無料で公開されています。技術担当者に依頼する際の参考にしてください。


把握できていない部品は、守ることができません。まず「見える化」することが出発点です。




#### ステップ2:使用しているオープンソースの「更新状況」を確認する


オープンソースのライブラリは、脆弱性が発見されると修正版がリリースされます。しかし、更新を適用していなければ意味がありません。


「依存関係の更新を自動で提案してくれるツール」として、GitHubの「Dependabot」が広く使われています。これを有効にするだけで、古くなった部品を自動的に検知・通知してくれます。




#### ステップ3:AIモデルのダウンロード元を確認する


Hugging FaceなどのプラットフォームからAIモデルをダウンロードして使用している場合、そのモデルが信頼できる提供元からのものか

森島拓生のプロフィール写真

森島拓生

Spectral 代表 / AI導入・エージェント設計

Spectral代表。AI Development & Consultingを軸に、非エンジニアとの対話から要件定義を構造化する「上流工程AI」や、AIエージェントによる業務自動化の設計・検証に取り組む。技術を導入して終わらせず、現場で継続して使える運用設計までを重視している。

AI導入支援要件定義AIAIエージェント構築

AI導入について、もっと詳しく知りたい方へ

お問い合わせ