GoogleとNICT・デジタル庁がAIサイバー防御を始動。日本の重要インフラはどう変わるか

Googleが2026年4月13日、NICTとデジタル庁に対する技術支援を通じて、日本向けのAIサイバーセキュリティ施策を進めると発表した。今回の軸は2つある。1つは、NICTのAIセキュリティ研究センター（CREATE）を通じて、AIで脆弱性を見つけるエージェント開発を支援すること。もう1つは、デジタル庁のガバメントクラウド開発サービスに、ソフトウェア供給網の完全性を高めるSLSAを導入することだ。

一見すると、Googleの社会貢献やセキュリティ啓発の話に見えるかもしれない。でも実際にはもっと重い。これは、AIを便利なチャットや検索のためだけでなく、日本の重要インフラ、行政システム、ソフトウェア供給網を守る実務へ入れていく具体的な動きだからだ。しかも対象は、自動車、医療機器、IoT機器のような日本の産業基盤と、13省庁・約1700自治体に関わるガバメントクラウドの文脈である。日本でAI導入が本番に入るとき、本当に問われるのは「どれだけ賢いか」だけではない。安全に使えるか、証跡を残せるか、供給網を守れるかが問われる。今回の発表は、そこへGoogleが踏み込んだ。

何が発表されたのか

Google Japanの公式ブログによると、今回の発表は単独の機能公開ではなく、日本のデジタル基盤を設計段階から守るための2本立てとして整理されている。

1つ目は、NICTのAIセキュリティ研究センター CREATE が主導する、AIを使った脆弱性検知エージェント開発への技術支援だ。Googleはその支援手段として、Gemini、OSS-Fuzz、Agent Development Kit、Secure AI Framework（SAIF）を挙げている。Googleの説明では、このシステムは自動車、医療機器、IoT機器などを主な対象とし、AIエージェントがソフトウェアの内部構造を解析し、プログラムコードのバグを特定し、脆弱性発見率の向上に寄与するという。

2つ目は、デジタル庁のガバメントクラウド開発サービスへのSLSA導入である。GoogleはSLSAを、正しい手順と環境でソフトウェアが作られたことを証明する、Googleの技術を基盤としたオープンソースのセキュリティフレームワークだと説明している。Googleブログでは、これが13省庁と1700の地方公共団体を対象にしたガバメントクラウドの開発サービスへ採用されたと述べている。

加えてGoogleは、有識者会議の議論をまとめたレポート「日本社会におけるサイバーセキュリティの課題と方策」も公開した。つまり今回は、単なる実証やPoCではない。研究開発、政府システム、政策提言をまとめて動かした発表になっている。

NICT向け脆弱性検知エージェントの意味

今回のニュースで特に大きいのは、AIの使い道が「文章生成」や「問い合わせ対応」ではなく、ソフトウェアの中身を解析して脆弱性を探す側へ向いていることだ。

NICTのCREATEは公式ページで、研究の三本柱を「AIを守る」「AIで守る」「AIを信頼する」と整理している。ここで今回のGoogle支援が入るのは、明らかにAIで守るの領域だ。日本の重要産業で使われるソフトウェアは、Webサービスだけではない。組み込み、制御、長期運用、サプライヤー分業、既存資産の継承など、複雑な条件が絡む。そのため、脆弱性を見つける難易度も高い。

Googleが挙げたOSS-FuzzやAgent Development Kitという組み合わせは示唆的だ。OSS-Fuzzは本来、継続的なファジングによってオープンソースソフトウェアの欠陥を見つける仕組みとして知られている。一方、Agent Development Kit はAIエージェントの開発枠組みであり、Geminiと組み合わせれば、単に静的にコードを読むだけでなく、複数の観点から仮説を立て、ツールを呼び、再検証する流れを組みやすくなる。Googleは今回、これらをバラバラの製品紹介としてではなく、脆弱性検知エージェントの構成要素として提示した。

ここから先は筆者の分析だが、この方向は日本にかなり合っている。日本の製造業、医療、交通、IoT分野では、セキュリティ人材不足とレガシー資産の多さが同時に存在する。コードレビューや検証を全部人手で回すのは限界がある。もしAIエージェントが「怪しい箇所を広く見つける」「既知の弱点を繰り返し洗う」「解析の初動を短縮する」役を担えるなら、防御側の生産性はかなり変わる。

重要なのは、Googleがここで日本の重要業界を明示したことだ。一般論ではなく、自動車、医療機器、IoT機器という、脆弱性の影響が現実世界へ波及しやすい分野を対象にしている。この一点だけでも、検索やオフィスAIとは別の重みがある。

デジタル庁のSLSA導入は何を変えるのか

もう一つの柱であるSLSA導入も、かなり実務的に重要だ。SLSAの公式サイトでは、SLSAをソフトウェア供給網での改ざん防止、完全性向上、パッケージやインフラの安全性確保のためのフレームワークと説明している。つまり、完成した後で脆弱性を探すだけでなく、そもそも安全な手順で作られたかを証明する方向の仕組みだ。

デジタル庁のガバメントクラウドは、政府共通のクラウド利用環境として、最新のクラウド技術を活用しつつ、セキュアでコスト効率の高いシステムを構築することを目指している。公式ページでも、政府全体の管理レベル向上、ベストプラクティスに基づく標準化、セキュリティやネットワーク設定の自動化支援が重視されている。そこへSLSAが入る意味は大きい。

理由は単純で、行政システムでは「アプリが動いた」だけでは足りないからだ。どのソースから、どの手順で、どのビルド環境を通って出来上がった成果物なのか。後から検証できることが重要になる。Googleブログでは、SLSA導入によってソフトウェアの真正性を確認できる証明書の作成や検証が可能になると述べている。これは、生成AI時代にさらに重要になる。AIがコード生成や修正支援へ広がるほど、誰が書いたか以上に、どの経路で本番に入ったかの説明責任が重くなるからだ。

ここでも日本固有の意味がある。ガバメントクラウドは13省庁と1700自治体に関わる巨大な運用基盤であり、個別最適より共通ルールが効きやすい。もしこの層で供給網の完全性要件が強まれば、政府案件だけでなく、その周辺ベンダーや受託開発の現場にも影響が及ぶ可能性が高い。

日本企業と自治体は何を見るべきか

このニュースを、日本企業や自治体の情報システム部門がどう読むべきか。ポイントは4つある。

1つ目は、AIは防御側の実務へ入る段階に来たということ。PoCでチャットボットを試す段階から、脆弱性検知、供給網証跡、開発プロセスの統制へ論点が移っている。

2つ目は、安全な開発を後付けではなく設計段階に組み込む流れが強まること。Googleブログでも、問題が起きてから対処するのではなく、初期段階にセキュリティ対策やテストを組み込む重要性を強調している。SLSAはまさにその象徴だ。

3つ目は、公共分野の要件が民間にも波及しうること。日本では公共調達や大企業の標準要件が、そのままサプライヤー側の開発慣行へ広がることが多い。したがって今回の動きは、政府だけの話で終わらない可能性がある。

4つ目は、Googleが日本市場で「AIを使う側」だけでなく「AIで守る側」のポジションも取りにきたことだ。最近の日本向けAIニュースでは、検索やGeminiアプリの利便性が注目されがちだったが、今回はもっと深い。重要インフラ、防御、自動化、供給網の完全性という、導入の根幹に近いレイヤーへ入っている。

もちろん、まだ過信は禁物だ。Googleの発表は方向性として強いが、実際にNICTの支援がどこまで成果を出すのか、SLSA導入が現場の開発プロセスをどう変えるのかは、これからの運用と制度設計次第である。AI脆弱性検知も、誤検知や過検知、ブラックボックス化、既存ツールとの統合など現実的な課題が多い。それでも今回の発表が重要なのは、AI活用の主戦場が、ついに日本の公共サイバー防御へ降りてきたことを示したからだ。

まとめ

Google、NICT、デジタル庁の今回の動きは、「日本でAIをどう便利に使うか」という話ではなく、日本の重要産業と行政システムをどう安全に保つかという話である。脆弱性検知エージェント支援は、防御側の生産性を上げる方向の一手であり、SLSA導入は、供給網の完全性を前提にした開発統制を強める一手だ。

日本市場では、AIの導入判断は性能だけで決まらない。信頼、証跡、運用、責任分界まで含めて初めて本番化できる。今回の発表は、その現実に合わせてGoogleが日本の公共・産業基盤へ深く入り込み始めたニュースとして見るべきだろう。

出典

• AI を活用して日本のデジタル基盤を守る Google のサイバーセキュリティの取り組み — Google Japan, 2026-04-13
• AIセキュリティ研究センター（CREATE） — NICT
• ガバメントクラウド — デジタル庁, 最終更新 2026-03-27
• SLSA • Supply-chain Levels for Software Artifacts — OpenSSF / Linux Foundation