軍事の世界における新興技術の広がりは単に新たな装備品の研究・開発に関わることだけではなさそうである。正に、戦いの現場において、その場において活用できるものをその場に応じたものに誂えていける人間が居ると居ないとでは、部隊の戦う能力に大きな差を生み出すことになる。先般話題になった、「防衛省・自衛隊の人的基盤の強化に関する有識者検討会　報告書」では、先ずは必要な採用者数の確保のための検討が主体となっていたが、軍事組織に必要な専門知識を有した人材の課題は更に困難なものと想像できる。ここで紹介するのは、米海兵隊の予備役に区分される組織、米海兵隊イノベーション・ユニットに所属する米海兵隊少佐の論稿である。活用できる情報を駆使していくためには、必要に応じたアプリケーションが求められ、そのアプリケーション開発や改善を部隊レベルで行える人材、ネットワークを含めたインフラなどの課題や、アプリケーション・ソフトの認証プロセス等についても大胆な見直しが求められるという。戦いの本質は変わらないが、戦いの性質は変化しているというが、この論稿で述べられている内容は、その側面を表しているのだろうか？（軍治）

将来の紛争のための自動化

ソフトウェア開発ライフサイクルを可能にするインフラとプロセスの要件

Automation for Future Conflicts

The requirement for infrastructure and processes to enable the software development lifecycle

by Maj David “Skip” McGee

Marine Corps Gazette • August 2023

マクギー（McGee）米海兵隊少佐は、現在、米海兵隊イノベーション・ユニットのイノベーション・ラボ・ブランチ、マリン・コーダーズ・セクションに配属されている。マクギー（McGee）少佐は以前、展開可能な統合指揮官担当官として、第48海兵航空団通信隊（Det A Fwd）の作戦担当官として、米海兵隊ユマ航空基地のS-6科長として、第8通信大隊の小隊および中隊指揮官として派遣された。

バーガー（Berger）米海兵隊総司令官は「フォース・デザイン2030（Force Design 2030）」の中で、部隊の近代化に不可欠な要件[1]として「将来の米海兵隊員は、急速に変化する21世紀の作戦環境の中で、革新し、適応し、成功するために必要な知的・技術的スキルを持つようになる」と明言している[2]。

技術が支配する作戦環境では、自動化（automation）は作戦の成功に不可欠である[3]。ロシアとウクライナの戦争では、分散化されたターゲティングと自動化された警告を可能にするソフトウェア・アプリケーションが生み出された[4]。自動化による革新（Innovation through automation）は、よりスリムで効率的かつ効果的な戦闘力（fighting force）を提供する。

米海兵隊全体で、現在および将来の問題に対する解決策を効果的に自動化するために必要な技術インフラとソフトウェア・ライフサイクル・プロセスは、現在のところ存在しない。米海兵隊内で自動化の開発を可能にするために、どのようなインフラとプロセスを開発すべきなのだろうか。

アプリケーション開発の成功例：Successful Application Development Example

ヨルダンのテントから衛星回線を使って派遣期間分のフィットネス・レポートを書いていたとき、接続が定期的に失敗することに苛立った。最初の2、3回は、遠くの天候が悪いからトラブルシューティングの意味がない、と知らされた。米海兵隊員は限界の状況に適応することに慣れている。

しばらくして、なぜイタリアのラーゴの天気はこんなに悪いのだろうと思い始めた。この天候の問題は、電源をいじったり、接続のトラブルシューティングを避けるための、衛星管制官の都合のいい答えなのだろうか？ヨルダンは常に乾燥した晴天だったので、衛星ショットの少なくとも半分は天候の影響がなかったようだ。

接続が回復した後、天気をチェックしたところ、管制官が報告する天気問題が天気予報とまったく一致しないことがすぐにわかった。この問題は頻繁に起こるようになったので、私はさまざまな場所で天気専用のブラウザ・タブを使い続けた。

結局、私は海兵隊に天気の話を乗り越えるように頼むのに疲れていた。私は、無料の天気予報アプリケーション・プログラミング・インターフェース（API）のデータを使って、2カ所の天気を同時に表示する短いPythonアプリケーションを書いた。

私はこのアプリケーションをWindowsの実行ファイルに変換し、米海兵隊の1人がPowerShellスクリプトを書いて、ラップトップで使用するためにドメイン証明書でアプリケーションに署名した[5]。共有ネットワーク・ストレージによって、実行ファイルを実行したいすべてのユーザーにアプリケーションを配布することができた。

このアプリケーション開発、テスト、配布のライフサイクルが機能したのは、インフラ（ドメイン、サーバー、ワークステーション）がすべて私の部署で維持・管理されていたからだ。私たちは、必要なインフラとソフトウェア・ライフサイクル・プロセスを開発する能力の両方を有していた。

その後、5回の離脱ローテーションを経て、このアプリケーションは使われなくなったかもしれないが、この経験は、小さな問題は自動化によって解決または削減できることを示している。

外部連邦政府機関のアプリケーション開発例：External Federal Application Development Example

海兵隊の外に目を向けて、別の連邦政府機関における既存のソフトウェア開発ライフサイクルの例を紹介しよう。アプリケーションを開発する開発者は、ローカルでコードをテストして変更し、その変更をGitLab^※1のリポジトリにコミットする。

※1：Git、GitLab、GitHubについて：Gitとは、コーディングの修正や変更履歴を管理する分散型バージョン管理システムのことを言う。GitLabとは、Gitリポジトリ［ファイルとか変更履歴とかを置いておく場所］機能のほか、開発の課題管理やバージョン管理、コードレビュー、CI/CD（継続的インティグレーション/継続的デリバリー）、そしてモニタリングを1つのアプリケーションで行うことができるオープンソースソフトウェアを指す。GitHubとは、Gitを保存するスペース「リポジトリ」をまとめてクラウド上で利用できるようにした、リモート・リポジトリのことを言う。（引用：https://media.ffremo.com/business/1249/）

コードが追加/変更されてコード・リポジトリにコミットされると、リポジトリの継続的インテグレーション・パイプラインはランナー^※2を使用してコードを Red Hat Package Manager パッケージにビルドし、該当する機能テストを実行して、変更がアプリケーションのパフォーマンスに悪影響を与えないことを確認する。

※2：ランナーとは、GitHub Actions ワークフローでジョブを実行するマシン（引用：https://docs.github.com/ja/actions/using-github-hosted-runners/about-github-hosted-runners）

パイプラインは、静的アプリケーション・セキュリティー・テスト・ツールや、潜在的には動的テスト・ツールを使用して、依存関係の脆弱性やセキュリティー上の懸念をチェックするなど、その他のジョブを実行し続ける。問題が検出されなかったと仮定すると、パイプラインの継続的デリバリー部分は Red Hat Package Manager に署名し、開発環境のyumサーバー・リポジトリー^※3にパッケージを配置する。

※3：yumは、Red Hatのパッケージマネージャー。yumを使用すれば、利用可能なパッケージ情報に関するクエリー、リポジトリーからのパッケージのフェッチ、パッケージのインストールおよびアンインストール、さらには利用可能な最新バージョンへのシステム全体の更新が可能

その環境のホストが定期的なアップデートを実行すると、最新のアプリケーション・バージョンに更新される。このプロセスは、機能的な問題やセキュリティ上の問題を解決するために開発者の注意を必要としない限り、手動による介入なしにシームレスに行われる。追加の機能ツールや動的ツールは、開発環境の新バージョンのアプリケーションに対して実行され、ユーザーテストまで実行される。

このレビュー・プロセスのある時点で、開発環境から本番環境のリポジトリにアプリケーションをプッシュするための別のパイプラインが起動し、本番環境のホストが新しいバージョンにアップデートする。米海兵隊エンタープライズ・ネットワーク（MCEN）内で同様のインフラとソフトウェア開発プロセスを構築できない理由はあるのだろうか？

アプリケーション開発の失敗例：Failed Application Development Example

米太平洋海兵隊（MARFORPAC）のG-6ウォッチは、米インド太平洋軍（INDOPACOM）の責任地域（Area Of Responsibility）におけるサイバー脅威と脅威主体に関するインテリジェンスと認識を得るためのプロセスについて説明した。商業的に調達され、誂えられた脅威インテリジェンス・データはあまりにも高価であったため、彼らは30以上の統一されたリソース・インジケータやウェブサイトのリストを維持し、責任地域（Area Of Responsibility）における変化や関連する出来事を特定するために毎日読んでいた。

このタスクは時間がかかり、その徹底性はアナリストに完全に依存しており、ウェブサイトや統一されたリソース指標が追加されてもうまく拡張できなかった。私は自動化の機会を見て、Pythonウェブ・スクレイパーを作成して、ウェブサイト・リスト内で探しているキーワードの出現を特定し、対応する段落を返すので、アナリストはリスト全体を反復するのではなく、ウェブサイトの関連するサブセットを確認するだけで済むようになった。

この解決策によって、監視担当者は、統一されたリソース指標のリストを増やし、責任地域（Area Of Responsibility）の認識を向上させることができる。同時に、リストの閲覧に費やす時間を短縮し、監視担当者間でレビューを標準化することができる。しかし、このスクリプトを米海兵隊エンタープライズ・ネットワーク（MCEN）に統合し、監視官が使用できるようにする方法は見つからなかった。

ホスティング・リソースの不足、プロキシの問題、共有認証の欠如が課題だった。承認プロセスを特定することも、米海兵隊エンタープライズ・ネットワーク（MCEN）へのソフトウェア製品の配布を自動化することもできなかったので、初期のコードはDevForce^※4からGitHubに移行した[6]。

※4：DevForceはリッチ・インターネット・アプリケーション (RIA) を構築、運用するためのフレームワークである。（引用：http://drc.ideablade.com/xwiki/bin/view/Documentation/overview）

しかし、米海兵隊エンタープライズ・ネットワーク（MCEN）の内部からGitHubにアクセスしてコードを変更したり、アプリケーションの作業をしたりすることができないため、すべての作業は米海兵隊エンタープライズ・ネットワーク（MCEN）の外部で行わなければならなかった。アプリケーションの最初のコンセプト・バージョンをテストする準備ができた後、私はそれをホスティングするための効果的なソリューションを見つけることができなかったし、米海兵隊エンタープライズ・ネットワーク（MCEN）でそのようなアプリケーションをホスティングするためのプロセスを特定することもできなかった。

スクリプトに基づいたウェブ・ユーザー・インターフェースを自宅のネットワークでホストするためにラズベリー・パイ^※5を使うことも考えたが、アプリケーションとユーザー・アカウントのライフサイクル・メンテナンスは、自分ひとりで無償でサポートするには負担が大きすぎると判断した。このプロジェクトは、開発、テスト、承認、配信のためのホスティング・インフラとプロセスが不足していたために失敗した。

※5：Raspberry Pi（ラズベリー・パイ）は、ARMプロセッサを搭載したシングル・ボード・コンピュータ。イギリスのRaspberry Pi 財団によって開発されている。日本語では略称としてラズパイとも呼ばれる。教育で利用されることを想定して制作された。IoTが隆盛した2010年代後半以降は、安価に入手できるシングルボードコンピュータとして趣味や業務（試作品の開発）等としても用いられるようになった。その後Raspberry Pi Compute Moduleを商品に組み込む用途まで広がっていった。（引用：https://ja.wikipedia.org/wiki/Raspberry_Pi）

解決策の共有：Sharing Solutions

自動化を可能にするインフラの構築は、共通の統合問題である。他の軍種は、21世紀の作戦環境と自動化の価値を理解している。米海兵隊エンタープライズ・ネットワーク（MCEN）は現在、VSCode、Anaconda、Rguiをソフトウェア・センターのエンド・ワークステーション・ユーザーが利用できるようにしている。

米防衛情報システム局（DISA）のGitLabインスタンスは、統合アプリケーション開発を可能にする SecDevOpsインフラへの重要な一歩である。このリソースは、米国防総省（DOD）情報ネットワーク内部からアクセス可能で、プロジェクトやリポジトリのホストを希望するユーザーが自由に利用でき、コード変更のプッシュ／プルには、一般的なアクセス・カード認証と個人用アクセス・トークンを使用する。

GitLabランナー（よくわからないかもしれないが、継続的インテグレーション・ジョブの計算と処理を考えてほしい）をこのインスタンスに登録することで、継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインを使ってコード・リポジトリからソフトウェアをビルドできるようになり、開発者や開発者チームが米国防総省（DOD）情報ネットワークの中で完全にアプリケーションをビルドできるようになる。

知識と能力の観点からは、予備役部隊（Reserve Component）との統合により、米海兵隊ソフトウェア工場（Marine Corps Software Factory）と海兵隊コーダー（Marine Coders）の既存のイニシアティブを利用した専門知識を提供することができる[7]。06XXコミュニティは0673 MOSを保有しており、米海兵隊員を訓練するパイプラインを開発している[8]。

同時に、高校や大学でのプログラミング・コースの人気が高まるにつれ、平均的な米海兵隊員のコーディングや自動化のスキルも進歩している[9]。この傾向を今後10年から15年先まで予測すると、米海兵隊員の問題を自動化する能力はそれに応じて高くなるだろう。我々は、その能力を武器化するためのインフラとプロセスを開発しなければならない。

問題の分析：Analyzing the Problem

軍種固有のGitLab/GitHubインスタンスのケースも考えられるが、ここでは、米防衛情報システム局（DISA）のインフラはどの軍種の要員も自由に利用できるままであると仮定する。したがって、残された課題は、パイプラインの継続的デリバリーの部分を米海兵隊エンタープライズ・ネットワーク（MCEN）に統合することである。

このプロセスは、米海兵隊エンタープライズ・ネットワーク（MCEN）内にランナーを登録することから始まる。次に、アプリケーションを承認して展開する方法など、今後の方法を決定するために、いくつかの組織的な質問に答える必要がある。

リソース要件と安全な配布プロセスは何ですか?

ウェブ・アプリケーション、米国防総省（DOD）認証局証明書で署名されたアプリケーション、および対応するウェブ・アクセス・ファイアウォールの実装は、システム管理者による緊密な調整とサポートの要件を追加する可能性があり、展開サイクルに手作業が介入する可能性もある。

アプリケーションの開発サイクルを迅速かつ安全に行うにはどうすればいいのか？

これらのアプリケーションには、基本的にテスト／開発環境と本番環境の2つの移行先が考えられる。

この 2 つの潜在的な行き先のインフラストラクチャは（私の知る限り）存在しないが、比較的簡単に作成できる。定義されたネットワーク・ルールを介して、AzureまたはAmazon Web ServicesにFedRAMP認可のRed Hat Enterprise Linux仮想マシンを作成し、ランナーおよびアプリケーション・ホストとして使用できる可能性がある（本番環境に関する追加のセキュリティ統制が必要である）。

オペレーティング・システムのパッケージ・マネージャ別に分けると、Red Hat Enterprise Linuxホスト用のyum/dnfリポジトリ（Aptitudeリポジトリは不要と仮定）、Windows用のSystem Center Configuration Managerへの統合、コンテナ・リポジトリの統合の3種類の配布方法を検討する必要がある。

今のところ、コンテナ配布の方法は無視できる。コンテナ、コンテナ・ランタイム、コンテナ・レジストリの知識ベースやインフラは、現在のところ米海兵隊エンタープライズ・ネットワーク（MCEN）や米艦隊海兵軍（FMF）の中には存在しないし、その知識ベースとインフラの両方を構築することは、私が提案するソリューションよりもはるかに重い負担となる。

アプリケーションがサーバーに展開されるか、ワークステーションに展開されるかを区別して、考慮する必要のある2つの異なるアプリケーションの使用ケースがある。サーバー・アプリケーションは、認証、定義された／制限されたネットワーク・アクセス・ルール、ドメイン・ネーム・システム（DNS）を統合した環境でホストされる可能性がある。一方、ワークステーション・アプリケーションは、ワークステーションにインストールされテストされる必要があり、おそらくワークステーションへのローカル管理者アクセスを必要とする。

アプリケーション開発サイクルのこれらの構成要素は、それぞれ独自の特性と技術的な問題のサブセットを持っているが、海兵隊が解決しなければならない包括的な問題は、インフラの所有権、アプリケーション・ライフサイクル・プロセスの定義、およびサポートするインフラへの資金提供である。

ここで説明するインフラを維持するために必要な全体的なリソースは、フルタイムに相当する従業員や軍人が1人、Amazon Web ServicesやAzureの仮想マシンのライセンスに若干の関連コストがかかる程度で、ごくわずかである。最も重大な問題は、所有権の決定とアプリケーションのライフサイクル・プロセスである。

結論：Conclusion

輸送問題を自動化するためのアプリケーションやスクリプトを開発したロジスティクス担当者がいて、世界中の戦闘作戦センターの複数のユーザーがそれをインストールして使いたいと考えてみよう。

その海兵隊員は今、どうやってそのタスクを達成するのだろうか？情報・指揮・統制・通信・コンピュータや海兵隊サイバースペース・オペレーション・グループの人たちと連絡を取り、開発プロセスやインフラを開発するために坂道を登っていこうとするだろうか？

おそらく、軍事情報技術で最も恐ろしい3文字、ATO（Authority to Operate：運用権限）を口にされた時点で、彼らは苛立ちのあまり諦めてしまうだろう。この問題にどう取り組むべきか？我々は、戦闘員のペースとタイムラインでソフトウェア開発ライフサイクルを完了するための定義されたプロセスとインフラを必要としている。

バーガー（Berger）米海兵隊総司令官は、革新、適応、成功を我々に命じた。海兵隊は、セキュアなコーディングの実践とセキュアなアプリケーション配布の実践とプロセスの開発において、各軍種をリードすることができる。我々は、必要な知識ベースを部隊全体で成長させている。我々は現在、安全な自動化とアプリケーション開発を可能にする軍種レベルのインフラを保有していない。米海兵隊は、ソフトウェア開発、テスト、統合、および配布を可能にするために、リソースのあるテスト/開発環境を開発し、承認プロセスを定義しなければならない。

ノート

[1] David H Berger, Force Design 2030 (Washington, DC: May 2020).

[2] Ibid.

[3] Charlie S. Bahk, “Announcement of the Marine Corps Software Factory Pilot,” Marines. mil, March 30, 2023, https://www.marines.mil/News/Messages/Messages-Display/Article/3325426/announcement-of-the-marine-corps-software-factory-pilot.

[4] Drew Harwell, “Instead of Consumer Software, Ukraine’s Tech Workers Build Apps of War,” Washington Post, March 24, 2022 , https://www.washingtonpost.com/technology/2022/03/24/ukraine-war-apps-russian-invasion.

[5] David McGee, “WeatherScraper,” GitHub, November 29, 2020, https://github.com/skipmcgee/weatherscraper.

[6] This resource https://gitlab.devforce.disa.mil was last accessed in July of 2022 and appears to no longer be accessible, perhaps replaced by https://web.git.mil.

[7] “Announcement of the Marine Corps Software Factory Pilot.”

[8] Ibid.

[9] Additional information is available at https://advocacy.code.org/2022_state_of_cs.pdf.