国家安全保障言語としてのRust｜メモリ安全性がなぜ政策課題になったのか

なぜ「言語の選択」が安全保障の話になったのか

プログラミング言語の選択は、長らく技術者の好みや生産性の問題として扱われてきました。それが 2022年以降、米国の政府機関が公式文書で「メモリ安全な言語を使え」と繰り返し提言する状況に 変わっています。この変化の背景にあるのは、思想でもブームでもなく、10年以上蓄積された 脆弱性の統計です。まずそこから見ていきます。

1. 「約70%」という数字の出どころ

この議論の出発点になっているのが、Microsoftのセキュリティ対応センター(MSRC)に在籍していた Matt Miller氏が2019年2月のBlueHat IL(イスラエルで開催されるMicrosoft主催のセキュリティ カンファレンス)で発表した 「Trends, Challenges, and Strategic Shifts in the Software Vulnerability Mitigation Landscape」 という講演です。ここで示されたのが、Microsoftが毎年CVEを割り当てて修正している脆弱性の およそ70%が、メモリ安全性に起因する問題であるという数字でした。この傾向は2000年代半ばから 十数年にわたってほぼ一定で、年によって多少上下しても70%前後という水準が続いていた、というのが 発表の要点です。

MSRCはこの内容を同年7月のブログ記事 「A proactive approach to more secure code」 でも公開しており、そこでは「CVEが割り当てられて修正された脆弱性の大半は、開発者がC/C++コードに 意図せず混入させたメモリ破壊バグが原因である」と述べられています。ここでいうメモリ安全性の問題とは、 具体的にはヒープ領域の境界外アクセス、解放済みメモリの使用(use-after-free)、型の取り違え (type confusion)、未初期化メモリの使用といった不具合の総称です。いずれもC/C++が プログラマにメモリ管理の責任を委ねている結果として生じるもので、言語仕様上は「正しい」コードが 実行時に破綻する、という性質を持ちます。

重要なのは、これがMicrosoft1社に固有の数字ではなかったことです。Googleの Chromiumプロジェクトのセキュリティ文書 には、2015年以降にStableチャンネルへ影響した912件の重大度High/Criticalの脆弱性を分析した 結果、およそ70%がメモリ安全性の問題だったと明記されています。さらにそのうち約半数が use-after-freeであるとされています。異なる企業の、異なるコードベース(WindowsとChromium)の、 異なる期間の分析が、ほぼ同じ比率に収束した——この一致が、業界全体に「これは個別の品質管理の問題 ではなく、言語レベルの構造的な問題だ」と認識させました。

Chromiumの文書がとくに率直なのは、サンドボックスとサイト分離という既存の緩和策が限界に 近づいていると認めている点です。Chromiumは「バグは存在する」という前提で多層防御を 設計してきましたが、その方式で得られる利得はすでに大部分を回収してしまった、という趣旨の記述が あります。緩和策を積み増すのではなく、バグそのものが生まれない言語に移る——というのが、 ここから導かれた結論でした。

2. 米政府の政策的な後押し: 何が実際に書かれているか

この技術的な認識を、政府文書のかたちで最初に明確に打ち出したのがNSA(米国家安全保障局)です。 2022年11月10日、NSAは Cybersecurity Information Sheet「Software Memory Safety」 を公開し、C/C++のように本質的なメモリ保護をほとんど提供しない言語から、可能な範囲で メモリ安全な言語へ戦略的に移行することを検討するよう組織に勧告しました。同文書がメモリ安全な 言語の例として挙げているのはC#、Go、Java、Ruby、Rust、Swiftです。Rustだけを 名指ししているわけではない点は、押さえておくべきところです。

続いて2023年12月6日、CISA(米サイバーセキュリティ・インフラストラクチャセキュリティ庁)が NSA・FBI、およびオーストラリア(ASD's ACSC)、カナダ(CCCS)、英国(NCSC-UK)、 ニュージーランド(NCSC-NZ / CERT NZ)の各機関と共同で 「The Case for Memory Safe Roadmaps」 を公表しました。これはCISAの「Secure by Design」キャンペーンの一環で、ソフトウェア製造者に対し メモリ安全な言語への移行ロードマップを策定し、公開することを求める内容です。 国際的な共同文書であるという点で、これは米国単独の政策論ではなくなっています。

そして2024年2月26日、ホワイトハウスの国家サイバー長官室(ONCD)が技術報告書 「Back to the Building Blocks: A Path Toward Secure and Measurable Software」 を公表します。報告書の主張は2本柱で、(1)脆弱性のクラスそのものをエコシステムに入れないことで 攻撃面を削減する、(2)ソフトウェアの品質を測定する診断手法を発展させる、というものです。 同時に公開されたファクトシート は「メモリ安全なプログラミング言語を使うことで、メモリ安全性のエラーの大半を排除できる」と述べ、 製造者が取りうる最もレバレッジの高い手段はサイバー空間の構成要素のひとつ、すなわち プログラミング言語そのものを安全にすることだと位置づけています。

この報告書はRustを例として名指ししていますが、その文脈は意外に慎重です。宇宙システムを扱う箇所で 「Rustはメモリ安全な言語の一例であり、必要とされる3つの性質を備えているが、宇宙システムでは まだ実証されていない」という趣旨の記述があります。つまり推奨しつつ、適用領域ごとの成熟度の 差も同時に認めているという書き方です。

さらに2025年6月24日には、CISAとNSAが共同で 「Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development」 を公開し、メモリ安全な言語の採用が「このクラスの脆弱性に対する最も包括的な緩和策」であると 明言したうえで、採用を阻む障壁とその乗り越え方に踏み込んでいます。

3. 実際にRustが入っている場所

政策文書と実際の採用は別の話です。では現実にはどこまで進んでいるのか。検証できる範囲で整理します。

Linuxカーネル。 2022年12月のLinux 6.1で、Rustのツールチェーン統合、 CONFIG_RUSTビルドフック、カーネルAPIに対する基本的な抽象化といった基盤が マージされました。この時点ではまだ「実験」の位置づけで、実際のドライバはありませんでした。 2024年のLinux 6.8でASIX PHYドライバなど最初の実用ドライバがメインラインに入り、6.13では PCI・プラットフォームデバイス・I/O操作のドライババインディングが整備されます。そして 2025年12月、Rust for Linuxを主導するMiguel Ojeda氏が 「rust: conclude the Rust experiment」 というパッチを提出し、カーネルにおけるRustは実験段階を終え、恒久的な構成要素になった ことが宣言されました。Android 16は6.12カーネル上でRust実装のashmemモジュールを出荷しており、 Androidのbinderドライバは6.18でマージされています。

ただしOjeda氏自身が、これは「あらゆるカーネル構成・アーキテクチャ・ツールチェーンで動くことを 意味しない」と明確に留保をつけています。GCCベースのRust実装であるgccrsは未完成であり、 残作業は多い、というのが当事者の評価です。またこの導入過程は、カーネルコミュニティ内で しばしば激しい論争を伴ってきたことも記録しておくべきでしょう。

Windows。 2023年のBlueHat ILで、MicrosoftのOSセキュリティ担当バイス プレジデントDavid Weston氏が、Windowsカーネルの一部をRustで書き直していることを公表しました。 具体的にはwin32kbase_rs.sysにGDIリージョン(矩形・多角形・楕円などの領域演算)の 新実装が含まれており、これはWindows 11 Insider Preview Build 25905(Canaryチャンネル)から 配信が始まっています。Weston氏自身がこの段階を 「crawl, walk, runでいえばcrawlの段階」 と表現しており、Windows全体の書き換えを意味するものではありません。

Android。 定量的な効果がもっともはっきり公開されているのがここです。Googleは 2024年9月のセキュリティブログ 「Eliminating Memory Safety Vulnerabilities at the Source」 で、Androidにおいて発見された脆弱性のうちメモリ安全性に起因するものの割合が、 2019年の76%から2024年には24%まで低下したと報告しました。実数でも2019年の 223件から2024年には50件未満へ減少しています。注目すべきはその理由で、Googleは 既存のC/C++コードを書き換えたからではなく、新規に書くコードをRustやKotlinなどの メモリ安全な言語に切り替えたからだと説明しています。脆弱性は新しいコードに偏って生じる ため、新規コードの言語を変えるだけで全体の比率が大きく動く、という構造です。既存のC/C++コードは 時間の経過とともに「枯れて」いき、そこから新たに見つかる脆弱性は相対的に減っていきます。

米国政府・防衛関連。 ここは慎重に書く必要があります。「どの省庁がどのシステムを いつRustへ移行した」という具体的で検証可能な事例は、公開情報としては乏しいのが実情です。 確実に言えるのは、DARPA(国防高等研究計画局)が TRACTOR(Translating All C to Rust) というプログラムを運営していることです。これはレガシーなCコードのRustへの変換を、静的解析・ 動的解析と大規模言語モデルを組み合わせて自動化しようとする研究プログラムで、評価はMITリンカーン 研究所のチームが担当し、Cの各種機能を網羅する150本のCプログラムからなるベンチマークが公開 されています。プログラムの動機として明示されているのは経済性です——手作業でのC→Rust変換は 年単位の時間と巨額のコストを要するため、それを自動化しない限り大規模なレガシーコードの移行は 現実的でない、という認識がここにはあります。裏を返せば、政府側も「既存コードの全面的な 書き換えは現状では非現実的」と判断しているということです。

4. 難問: COBOL・Java中心の基幹系はRustに移行できるのか

ここが本記事でもっとも慎重に扱いたい論点です。結論から書くと、近い将来において 「COBOL基幹系をRustで書き直す」という筋書きは、ほぼ現実的ではありません。そして その理由は、Rustの能力不足ではありません。

まず規模の問題があります。現役で稼働しているCOBOLコードの総量については、2017年のロイター報道を 起点に広く引用されている推計で約2,200億行、より大きな推計では8,000億行という 数字も流通しています。同じ系統の推計では、米国の基幹銀行システムの43%、ATM取引の95%が COBOLに依存し、1日あたり約3兆ドルの取引がCOBOLシステムを通過するとされます。 これらは出所によって数字が大きく振れる推計値であり、確定した統計として扱うべきではありませんが、 桁感として「数千億行規模」という点はどの推計でも共通しています。

政府側の実態は、より確度の高い一次情報で確認できます。米国会計検査院(GAO)が2025年7月17日に 公表した報告書 GAO-25-107795「Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems」 は、10省庁にまたがる11の最重要レガシーシステムを特定しています。これらは 約23年から60年前に構築されたもので、維持運用に年間約7億5,400万ドルを要して います。11件のうち8件がレガシーなプログラミング言語を使用しており、報告書は 財務省の対象2システムがCOBOLとアセンブリ言語で動いていること、そしてそれらを保守できる 技能を持つ人材が減り続けていることを名指しで指摘しています。

しかし規模と人材の問題以上に本質的なのは、Javaは、Rustが解決しようとしている問題を すでに抱えていないという点です。ここは混同されやすいので明確にしておきます。 Javaはガベージコレクションを備えた、関連する意味でメモリ安全な言語です。 配列の境界はランタイムで検査され、ポインタ演算はなく、解放済みメモリへのアクセスという概念自体が 存在しません。C/C++に特有のバッファオーバーフロー・use-after-free・型の取り違えという 脆弱性クラスは、Javaのアプリケーションコードには原理的に生じません。前述のNSAのCSIが挙げる メモリ安全な言語のリストに、RustだけでなくJavaやC#が並んでいるのはそのためです。

したがって「メモリ安全性のためにJavaの基幹系をRustへ移行する」という議論は、 解決すべき問題が最初から存在しないという意味で成り立ちません。エンタープライズや 行政のバックエンドでJavaが抱えるリスクは、デシリアライゼーションの不備、アクセス制御の設計ミス、 依存ライブラリのサプライチェーン(Log4Shellのような)、JVMやランタイム自体の脆弱性といった、 まったく別のクラスに属します。これらはRustに移っても消えません。

COBOLについても事情は似ています。COBOLは固定長レコードを扱う言語であり、C的なポインタ演算や 手動のヒープ管理を中心に据えた言語ではありません。COBOL基幹系の本当のリスクは、メモリ破壊バグ というより保守できる人間がいないこと、仕様が誰の頭にも完全には残っていないこと、 周辺のミドルウェアやOSがサポート切れになっていくことです。これは言語を替えて解決する 種類の問題ではなく、組織とドキュメントとアーキテクチャの問題です。

加えて、この規模のシステムを一括で書き直す(ビッグバン・リライト)こと自体が、言語の如何を 問わず極めて高リスクな選択です。ソフトウェア業界でこの点について最も長く引用されている論考が、 Joel Spolsky氏が2000年4月6日に公開した 「Things You Should Never Do, Part I」 です。同氏の論点は2つで、(1)一見汚く見えるコードには、長年かけて発見されたコーナーケースや 奇妙なバグへの対処が埋め込まれており、書き直すとその知識が失われる、(2)書き直しには長い時間が かかり、その間は製品を改善できず、競合に差を詰められる、というものです。Netscapeがブラウザ エンジンを書き直し、およそ3年にわたって競争力のあるリリースを出せなかった事例が引き合いに 出されています。26年前の文章ですが、基幹系の刷新を検討するあらゆる場面で今も参照され続けて います。実務上、組織がとる選択はほぼ例外なく、全面書き換えではなく相互運用による 段階的な置き換え、あるいはレガシーシステムをAPIで包んで温存する方向です。

では、Rustの現実的な出番はどこにあるのか。答えははっきりしています。 C/C++が依然としてデフォルトであり続けている、新規のシステムレベル・性能クリティカル・ セキュリティクリティカルなコードです。カーネル、デバイスドライバ、暗号ライブラリ、 メディアコーデック、そして外部からの入力を直接パースするネットワーク対向のパーサ—— 攻撃者が制御するバイト列を最初に触る場所が、まさにメモリ安全性の問題がもっとも高い代償を伴う 領域です。Androidの数字が示したとおり、新規コードの言語を切り替えるだけでも、時間の経過とともに 脆弱性の構成比は大きく変わります。これは「COBOLやJavaを置き換える」話ではなく、 「C/C++を新規に書くのをやめる」話です。

5. 放置されたレガシーという、今そこにある攻撃面

以上は「これから書くコード」の話でした。しかし現実に運用されている古いシステムは、それとは別に 現在進行形のリスクを抱えています。

先のGAO報告書は、11件の重要レガシーシステムのうち4件がサポートの切れたハードウェアまたは ソフトウェアを含み、7件が既知のサイバーセキュリティ脆弱性を抱えたまま運用されていると 報告しています。しかも報告書の整理では、これらの脆弱性はシステムの近代化によってしか 解消できない——つまりパッチでは塞げない——種類のものとされています。

この問題意識は、より拘束力のある形にも現れました。CISAは2026年2月5日、 Binding Operational Directive 26-02「Mitigating Risk From End-of-Support Edge Devices」 を発出しています。これは連邦文民行政機関に対し、サポートが終了した(End-of-Support)エッジ ネットワーク機器を、単にパッチを当てるのではなく更新または撤去することを義務づける 指令です。CISAが公開するEOS機器リストに載っている機器を2026年5月5日までに棚卸しし、 2027年2月5日までに更新・置換、さらに2027年8月5日までにはリスト外のものも含めすべての サポート切れエッジ機器を処理する、という期限が設定されています。言語選択の勧告とは異なり、 こちらは拘束力のある指令です——この対比自体が、政府が何を「今すぐの危機」と見なして いるかをよく示しています。

ここでメモリ安全性の話に戻ります。大規模で、現在の担当者が全体を把握しておらず、安全に変更する ことが難しいC/C++のコードベース——こうした場所こそ、メモリ安全性のバグが最も長く 生き残る場所です。理由は単純で、(1)静的解析やファジングを回しても、コードが大きければ カバーしきれない、(2)修正が他所を壊すリスクが読めないため、既知の問題でも手を入れられない、 (3)元の設計意図を知る人間がいないため、そもそも「これはバグなのか仕様なのか」の判断がつかない、 という条件が重なるからです。産業制御系(OT/ICS)のように、更新のための停止が許されない 連続稼働の現場では、これがさらに悪化します。

重要なのは、この現実が「新規コードをメモリ安全な言語で書くべきか」という問いを 否定するのではなく、むしろ切実にするという点です。今日C/C++で書かれる新しい セキュリティクリティカルなコードは、10年後・20年後に「大きくて、誰も全体を把握しておらず、 安全に触れないレガシー」になります。言語の選択は、そのときになって取り返しがつくものでは ありません。同時に、言語を変えたところですでにデプロイ済みのものが遡って安全になる わけではないことも、同じくらいはっきりさせておく必要があります。この2つは別々に 取り組むべき課題です。

まとめ

• MicrosoftのMatt Miller氏が2019年のBlueHat ILで示した「CVE割り当て済み脆弱性の約70%がメモリ安全性の問題」という数字が、この議論の出発点になっている
• GoogleのChromiumチームも、2015年以降の高深刻度脆弱性912件の分析からほぼ同じ約70%という結果を公表しており、企業やコードベースを超えた一致が見られる
• NSA(2022年11月)、CISA他8機関による国際共同ガイダンス(2023年12月)、ホワイトハウスONCD報告書(2024年2月)、CISA・NSA共同ガイダンス(2025年6月)と、政府側の提言は積み重なっている
• ただしこれらはすべて勧告・ガイダンスであり、C/C++の禁止でも法的義務でもない。ONCD報告書自体、Rustについて「宇宙システムではまだ実証されていない」と留保している
• 実際の採用は進行中で、Linuxカーネルでは2025年12月にRustが実験段階を終えたと宣言され、Windowsカーネルの一部やAndroidにも入っている
• Androidではメモリ安全性関連の脆弱性の比率が2019年の76%から2024年の24%へ低下したが、その要因は既存コードの書き換えではなく新規コードの言語切り替えである
• COBOL/Javaの基幹系をRustへ移行するという筋書きは現実的でない。Javaはすでにメモリ安全であり、COBOLの真のリスクは人材と仕様の喪失であって、いずれも言語の置き換えでは解決しない
• Rustの現実的な適用領域は、C/C++が依然デフォルトである新規のカーネル・ドライバ・暗号ライブラリ・ネットワーク対向パーサである
• GAOが指摘する数十年物のレガシーシステムや、CISAがBOD 26-02で撤去を命じたサポート切れ機器は、言語の議論とは別に今そこにある攻撃面である
• Rustはメモリ安全性のバグを排除するが、ロジックバグ・設計ミス・サプライチェーンリスクは排除しない。書き直しそのもののリスクも過小評価すべきではない