【CNDW2025】なぜCloudNative DevSecOpsを推進するのか？ 米軍の事例が示す「速度と安全性」の必然

CloudNative Days Winter 2025のセッションでは、GitLabの吉瀬淳一氏が米軍のDevSecOps実践を紹介した。軍事というと特殊領域に見えるテーマだが、更新速度と安全性を同時に求められる点は、日本の金融・医療・行政・製造などの規制産業と共通している。ウクライナやイスラエルで示された「ソフトウェア更新が戦力を左右する現実」を背景に、米軍はF-35を含む膨大なシステムでCloudNativeとDevSecOpsを急速に取り入れてきたという。

なぜ米軍はDevSecOpsに踏み切ったのか

現場の変化に遅れないための設計思想とは何か？ その問いに触れながら吉瀬氏は「GitLabはDevSecOpsの会社です」と語り、まずはDevSecOpsがどのような場面で求められているのかを理解する重要性を示した。

その一例として紹介されたのが、米軍がDevSecOpsへ本格的に舵を切る契機となった背景である。2019年のKubeConで話題となった「F-16にKubernetes」という取り組みは、その動きをよく表している。実際には戦闘機ではなく、複数ベンダーの関連システムを司令塔側に集約し、標準化した環境で高速に更新できる基盤を整えた取り組みだった。吉瀬氏は「F-16にマウスとキーボードはありません」と笑わせつつ、狙いは「環境差の排除」にあると語っている。

その背景には、戦場そのものが「更新速度」を武器にする時代に入ったという現実がある。ウクライナではドローン用ソフトウェアが三ヶ月単位で更新され、イスラエルではAI迎撃が従来の数十倍の速度で動くなど、ソフトウェアの改修・検証・展開のスピードが戦力を左右する状況が生まれてきている。

一方、当時の米軍はウォーターフォールと重い認可手続きを前提としており、変更が一年以上止まることも珍しくなかった。加えて、前線や艦船では通信が不安定で、セキュリティ要件も極めて高い。従来のやり方では、変化し続ける現場に追いつくことができなかった。

ソフトウェア開発の速度が安全保障環境における優位性を決定する時代

こうした限界を受け、米国防総省（Department of Defense、以下DoD）はDevSecOpsへの全面転換を決断した。吉瀬氏は「状況が刻々と変化するので、ソフトウェアは止まっていてはならないのです」と語り、Shift Left、CI/CD、自動化、継続的認可（cATO：Continuous Authority To Operate）といった仕組みを制度に組み込む必要性を強調した。

DoDのDevSecOpsガバナンス 制度としてのスピードと透明性

DoDは、安全保障環境の急速な変化に対応するため「Enterprise DevSecOps Fundamentals」を公開し、DevSecOpsを制度として導入する方針を明確にした。兵器システムから業務アプリケーションまで共通して適用できる「速度と安全性を両立するための基盤」を定義したものだ。

そこで示されるShift Left、Software Supply Chain、Software Factoryといった考え方はいずれも、後付けの対処では複雑化した軍のシステムを守りきれないという問題意識に基づく。特に重要なのが継続的認可（cATO）であり、従来一年以上を要した認可プロセスを、変更を細かく許可する運用へ転換することで、30日規模へと短縮可能にした点が大きな転換となった。

吉瀬氏はガバナンスについて、「プロセスが公開され、理解でき、検証可能である状態です」と説明し、「透明性があるからこそ守れるのです」と強調した。DoDのDevSecOpsは、この「透明なプロセスの継続運用」を技術と制度の両面から実現しようとする取り組みである。

==Platform One：透明性を前提にした大規模DevSecOps基盤

米空軍・宇宙軍が運用する「Platform One」は、3万5,943人・156チームが利用するDoD共通のDevSecOps基盤だ。中心となるBig Bangは、Kubernetesを土台に一般的なOSSで構築されており、吉瀬氏は「特別な軍用技術ではありません」と語る。標準技術を大規模・高信頼で運用する点に価値があると強調した。

もう一つの柱であるIron Bankでは、1200超の強化コンテナがセキュアなパイプラインで継続的にビルドされ、ビルド内容やスキャン結果まで公開されている。吉瀬氏は「公開することで逆にセキュリティを高めるのです」と語り、透明性と再現性を前提に安全性を確保する思想を示した。

Iron Bank：強化コンテナレジストリ

さらにPlatform Oneは、前線基地や艦船など通信制約の大きい環境でも稼働するよう設計されている。署名済みコンテナのオフライン展開や段階的同期といった仕組みにより、エアギャップや衛星通信下でも更新が止まらないDevSecOpsを実現している。

F-35が直面する巨大コードベースとDevSecOpsによる近代化

F-35のソフトウェアは、機体搭載分で約800万行、地上システムを含めると2,200万行を超える巨大なコードベースである。1990年代のアーキテクチャが現在も残り、レガシー化と複雑性が重なって開発・更新の負荷は極めて大きい。吉瀬氏は「古いPowerPCベースのCPUで動き続けています」と言い、最新の開発手法を取り込む難しさを示した。

この巨大システムを継続的に改善するため、Joint Program Office（JPO）はPlatform Oneをそのまま採用し、JPO Cloudとして運用している。OSSを前提とした統一基盤に移行することで、更新の再現性と安全性を確保しながら改善サイクルを高速化している。

開発効率を支える仕組みが、デジタルツイン×Kubernetesである。実機を使わずにクラウド側で構成を再現し、ミッションソフトウェアの検証を高速に繰り返すことで、実験の制約を受けずに改善を続けられる。

さらに長期運用を見据えて、モジュラーオープンシステムアーキテクチャ（MOSA）を進め、密結合だった機能群を分割し、将来更新性を確保する取り組みも進められている。

Black Pearl：船上に構築された統合Software Factory

米海軍の「Black Pearl」は、Platform Oneの思想を艦船向けに最適化したDevSecOps基盤だ。背景には海軍内で複数のソフトウェアが乱立し、同様の機能を重複して構築する非効率があった。そこで海軍はSigma Defenseと協力し、単一の標準基盤へ統合する方針を採った。

海軍の標準Software Factory：Black Pearl

Black Pearlはイージス艦近代化プロジェクト「Forge」にも採用され、その効果は大きいという。従来6ヶ月かかった環境構築は3～5日に短縮され、配備コストも400万ドルから40万ドルへ圧縮された。脆弱性対応も「数ヶ月→数日」となり、継続的な更新を前提とした運用が初めて現実的なものになった。

こうした設計が必要なのは、艦船特有の通信制約にある。航海中はクラウド接続が不安定で、頼れるのは衛星通信などの低帯域回線である。吉瀬氏は「船は海に浮かぶデータセンターです」と言い、オフラインでも動くDevSecOpsの重要性を指摘した。

Black Pearlには署名済みコンテナによるオフラインデプロイ、段階的構成同期、ローカルビルド環境など、通信が途切れても改善を継続できる仕組みが揃う。このため暗号プロトコル更新のような作業も帰港を待たずに船上で実施できるようになった。

なぜ今、Cloud Native DevSecOpsなのか

米軍のDevSecOpsは軍事特有の話ではなく、日本の金融・医療・行政・製造など、規制産業が抱える課題そのものに重なる。重い認可プロセス、閉域網・エアギャップ、レガシーシステム、人手作業への依存…… いずれも更新速度と安全性を両立しづらい構造を抱えている。

外部環境の変化は速く、ゼロデイやサプライチェーン攻撃は待ってくれない。後付けのセキュリティでは防ぎきれず、手作業主体の運用にも限界がある。だからこそ透明性と再現性を備えたソフトウェアサプライチェーン、標準化と自動化を核にしたDevSecOpsが必須になっていくのだ。

吉瀬氏は「結局、私たちも同じ課題に向き合っているのです」と語った。極限環境の実践はこれからの日本の重要インフラや基幹システムにとって「普通の姿」になる。

結論としては、吉瀬氏の言葉を借りれば「だからこそCloudNativeとDevSecOpsをやっていきましょう」ということになる。状況の変化に対して、止まらず、改善を続けられる組織かどうかが、これからの競争力を左右する。