人工知能（AI）パイロット操縦の航空機を信用できますか？

著者：Paul Parkinson

先日、ミュンヘンで開催されたAerospace Tech Week Europe 2023カンファレンスに参加しました。このカンファレンスでは、業界の課題、規制、テクノロジートレンドに関する講演やアビオニクスセッションが多数行われました。その中で特に注目されたのは、航空宇宙システムの地上システムと航空電子機器システムにおける人工知能（AI）の役割でした。航空宇宙業界はAIの導入において慎重に歩みを進めていますが、私は次のような疑問をいだきました。人間のパイロットではなく、AIが操縦する旅客機に乗りたいと思うでしょうか？

すぐに多くの人が直面する疑問ではないでしょうが、将来的には可能性がないわけではありません。2022年の国際民間航空機関（ICAO）会議で、カナダと日本が貨物輸送における遠隔操縦システム（RPAS）の利用について研究報告を発表しているように、この分野は真剣に検討されています。

航空業界は、COVID-19の流行による人員削減や退職により、膨大な数のパイロットとその経験を失っています。また、労働者の高齢化に伴い、航空需要の増加に追いつくためにパイロットを迅速に採用し訓練することに苦労しています。

ICAOは、複数のパイロットを必要とする航空機を含む民間航空機の規則を定めています。しかし、現在、一部の航空会社は、2人のパイロットではなく、1人のパイロットだけで飛行を始めたいと考えており、多くの国が規則の変更を求めています（Euronews,2021年11月29日）。

航空宇宙業界と規制当局は、早ければ2027年に開始されるであろうシングル・パイロット・オペレーション（SPO）を可能にし、パイロット不足を緩和する方法について議論しています。しかし、最近頻発している飛行中に人間のパイロットが不能になった場合（Aero News、2023年3月26日）、代わりにAIパイロットが操縦を引き継ぐか、もしくは航空交通管制（ATC）が遠隔操縦するか、どちらを望みますでしょうか？

一般的に、これは長期的に考えるべき問題です。現在、航空宇宙業界では、膨大な量の飛行データを分析し、まとめ、人間のパイロットが情報に基づいた意思決定を行い、その作業負荷を軽減できるようにするAIシステムを開発しています。また、航空機の衝突回避システムの意思決定を改善するためにAIを使用する取り組みも進行中です（Aerospace Tech Weekカンファレンスで発表されました）。

欧州民間航空機器協会（EUROCAE）とSAEインターナショナルは、共同ワーキンググループEUROCAE WG-114 / SAE G34を通じて、AI技術を活用した安全性関連システムの開発と認証を支援するための共通規格とガイダンスを確立するために協業しています。ARP-4754A、ARP-4761、DO-178C、DO-254などの現在の航空電子機器安全認証規格にAIシステムを認証することは、実現不可能ではないにしても、非常に困難であると思われます。しかし、安全性が証明された「従来の」ソフトウェアおよびハードウェアシステムの制御下でAIシステムを使用すること（制約付きAI）で十分な答えになるでしょうか、それとも、AIの分析と関連する行動を確認するために、人間のパイロットが依然として必要となるのでしょうか。

最新世代の旅客機の一部には、すでに自動操縦システムが搭載されており、タキシング、離陸、着陸が可能です（New Atlas、2020 年 8 月）。今後数年間で、航空宇宙業界は、AIベースのアドバイザリーシステム、人間のパイロットの作業負荷を軽減するためのAI副操縦士、さらにはアーバン・エア・モビリティ（UAM）システムで最初に導入されるかもしれないAIベースの自律システムの開発で、多くのAI経験を積むと予想されます。

そう考えると、将来、AIパイロットによる旅客機でのフライトは、それほど難しいことではないのかもしれません。

一度きりの開発で、どこにでもデプロイ

Tomas Holmberg

最新の開発手法は、アジャイル、スクラム、CI/CD、DevOpsなど、進化し続けています。多くの場合、より良い品質でより迅速に開発することを目的としています。スピードは、新しいアプリケーションの開発速度や、バグを発見した後にどれだけ早くアップデート版をリリースできるかなどで測ることができます。品質には安全性が含まれますが、企業によっては別の意味になる場合もあります。「Develop Once, Deploy Anywhere（一度きりの開発で、どこにでもデプロイ）」という考え方は、デプロイされる対象とは無関係に同じアプリケーションを2度書くことを避けることで、無駄を省くことに焦点を当てています。

開発工数を最小限に抑え、ほぼすべての製品で動作するようにするというコンセプトは、新しいものではありません。「Write Once, Run Anywhere（一度〔プログラムを〕書けば、どこでも実行できる）」は1995年にすでに確立されており、クロスプラットフォームのコードを作るために、Javaが使用されていました。

「Build Once、Deploy Anywhere（一度きりのビルドで、どこでもデプロイ）」についての議論もあり、Anywhere（どこでも）が Everywhere（どこにでも）に置き換えられることもありますが、コンセプトは同じです。Build Onceは、しばしば再構築を必要としないものを作ることを指します。その場合、コンテナなどのテクノロジーは、多くのシステムで実行され、外部ライブラリに依存しないマイクロサービスを作成することで役立ちます。コンテナは依然としてカーネルに依存していますが、これは重要なことではありません。

一度きりのビルド

なぜ一度しかビルドしない方がいいのか？開発者は、アプリケーションのリリース候補をターゲット環境にデプロイするために、ビルドボタンを押すわけではありません。その作業を管理する自動ビルドとテストの自動化システムがあります。したがって、もはや「一度きりのビルド」は重要ではありません。

一度きりのビルドには、根本的な問題があります。アプリケーションがアップグレードやバグ修正が必要ないと、どうして分かるのでしょうか？完璧なアプリケーションを作成したとしても、それはビルドに使用されるツールチェーンや、動的または静的にリンクされたライブラリに依存しています。コンパイラにバグがあり、アプリケーションが安全でない場合はどうなるのでしょうか？アプリケーションが依存しているライブラリにバグがあるとどうなるでしょうか？ライブラリは他のライブラリに依存していることが多いため、アプリケーションにバグがないと言い切ることは困難です。完成品はもはや完璧ではなく、最終的にアプリケーションを更新する必要があるかもしれません。

一度きりの開発

Develop Once（一度きりの開発）は、コード、コンフィグレーションスクリプト、宣言的な仕様など、何かを開発することを目的としています。最終的に出来上がるものがコンテナであろうと、アプリケーションであろうと、重要ではありません。ユースケースに応じて、同じ開発アーティファクトを使用して、デプロイされる場所に最適なデリバリーをすることができます。

完成品の再構築は、依存関係にある部品のバグ修正によって引き起こされる可能性があります。設定の小さな変更でも、中間バグを誘発する可能性があります。

LinuxディストリビューションビルダーであるYocto Projectは、デプロイ方法やデプロイ先を定義せずにコードを開発することを可能にした良い例です。開発者は、1つまたは複数のレシピでレイヤーを定義します。レシピには、アプリケーションを構築するために必要なすべての情報が含まれています。開発者は、後でコードを書き直す必要がないように、できるだけ適切なコードを作成しなければなりません。

コードの書き直しを防ぐさまざまな方法があります。重要な要素の1つは、できるだけ短いコードを書くことです。ゼロ行のコードはバグもゼロです。1つの方法は、コードが高度にモジュール化されていることを確認することです。各パーツの目的は1つだけです。コードをその機能に合わせて最適化すれば、コード量も制限されます。

プログラミング言語も書き直しを防ぐのに有効です。高レベルの宣言型プログラミング言語でコードを書くと、最小限のコード量になります。ライブラリやツールは、そのコードを機械語に解析します。バグは、切り取った元のコードには存在しませんが、依存しているものの中にはまだバグが残っている可能性があります。もう一つの方法は、Rustのようなメモリセーフな言語を使用することで、アプリケーションがメモリセーフであることを確認することができます。

どこでもデプロイ

Deploy Anywhere（どこでもデプロイ）は、アプリケーションをどこにでもデプロイできることを意味します。どこでもというのは、見方によってさまざまな意味があります。ある人は、どこでもとはLinuxが動作する古典的なx86システムのことだと思うかもしれません。しかし、より広い意味では、大きなサーバーから小さな組込みデバイスまで、あらゆるハードウェアアーキテクチャとあらゆるサイズのシステムを指します。

アーティファクトを作成するためのツールは多数ありますが、それらは多くの場合、特定の種類のほとんどのハードウェアで動作するように構築されたビルド済みのイメージとライブラリに依存しています。Yoctoとは対照的に、結果は特定のハードウェアの機能に対して最適化されていません。

Yoctoビルドシステムは、アプリケーションのビルドと、パッケージングやデプロイ可能なアーティファクトの作成を区別しています。ビルドシステムは、deb、rpm、またはipmパッケージを作成し、直接デプロイするか、他の伝達手段を介してデプロイすることができます。ビルド システムは、いくつかのイメージタイプ、SDK、システムコンテナー、またはアプリケーションコンテナーを生成することができます。Yoctoには標準的なレシピが含まれており、新しいデプロイメントを実行するための独自のレシピを書くことができます。その結果は、無駄のない Linuxインストールを実行するだけの小さなARM組込みデバイスから、クラウド内の本格的なKubernetesシステムまで、あらゆるものにデプロイされます。

まとめ

ソフトウェアの開発は大変な作業です。高レベルのアプリケーションを構築し、ビルド、パッケージ、デプロイをツールに任せることで、アジリティとスピードを得ることができます。Yoctoは、開発と最終アーティファクトの作成を分離することで、開発者がこの目標を達成することを支援し、アーキテクチャに依存しない特定のデプロイに最適化します。開発者は、最終アーティファクトを気にすることなく、アプリケーションの開発に集中することができます。

米国国立標準技術研究所(NIST)のSSDFコンプライアンスへの準拠達成は難しいか？

著者：プリンシパル・テクノロジスト、Barbara Cosgriff

ウインドリバーのセキュリティアセスメントサービスを活用し、より多くの政府プロジェクトを獲得しませんか？

政府プロジェクトを獲得するためには、実際のコンプライアンス要件に対応するのはもちろんのこと、略語を把握するだけでも大変です。

米国政府機関に重要なソフトウェアを提供しようとする企業は、アメリカ合衆国行政管理予算局（OMB）Memorandum M-に基づき、2022年半ばからサイバーセキュリティー・インフラセキュリティー庁（CISA）のSelf-22-18を提出する必要があります。

M-22-18では、ベンダーがNISTのセキュアソフトウェア開発フレームワーク（SSDF）のタスクを完了していることを証明する必要があり、そのためにはサプライヤーのソフトウェア開発ライフサイクル（SDLC）とSSDFタスクの整合性が求められます。

SSDFタスクの達成は、難しく考える必要はありません。

多くの企業がウインドリバーのセキュリティサービスや製品を活用することで、コンプライアンス管理の簡素化だけでなく、DevSecOpsプロセスの合理化、投資配分の最適化、政府要件を満たすためのコストと期間の短縮を実現しています。

あるお客様が、SSDFギャップ分析サービスとWind River Studio Developerによって、企業がプロセスを合理化し、より多くの政府プロジェクトを獲得できた例をご紹介します。

防衛、国土安全保障、航空などの先進的な電子機器メーカーは、SSDFのタスクを達成するために、SDLCを最適化する必要がありました。資本支出を最小限に抑え、サイバーセキュリティ担当者に過剰な負担をかけることなく、SDLCとSSDFのタスクの間のギャップの特定、優先順位を付け、修復をしなければならない状況でした。

ウインドリバーは、SDLCを厳密かつ専門的な評価を実施し、認証に影響を与えるSSDF関連タスクのギャップを特定し、それらのギャップを修復するための詳細な提案をしました。

主なサービスには、以下のようなDevSecOpsに必要なタスクや事項が含まれました。

・infrastructure-as-code とconfiguration-as-codeの自動化を活用した汎用的なベースパイプラインを構築し、セントラルチームが自動化されたパイプラインの生成を実現

・すべてのパイプラインにおいて自動セキュリティゲート機能を提供

・すべてのパイプラインにおいてアプリケーションセキュリティテストツールを利用できるようにし、使用を義務付ける

・ソフトウェアコンフィギュレーション管理にセキュリティ要件を組み込む

そのお客様は、SDLCに必要な変更に優先順位を付け、それらの変更に関連するリソースのニーズとコストを定量化し、構造化されたコスト効率の高い方法で導入することができました。

VxWorks®とWind River Linux の長年のユーザーである同社は、ウインドリバーと成功を収めてきた歴史があり、ウインドリバーの専門知識と認証実績に深い信頼を寄せていました。 Wind River Studio の機能が、タスクやアクティビティの実装要件に非常によく適合していたことも同様に重要な要素でした。

また、セキュリティアセスメントサービスを利用することで、以下のデータに基づく客観的洞察を得ることができました。
• DevSecOpsチームの技量がNISTのSSDFプラクティスにどの程度適合しているか
• 生産性を最大化するためにリソース配置やその他の投資判断をどのように最適化するか
• SDLCとSSDFタスクのギャップを最小限のコストと許容期間内に修正する方法

最も重要なのは、ビジネスの観点から、NIST SSDF準拠を必要とする新たなビジネスチャンスを追求することができるようになったことです。

その会社の上級管理職は「サービス増加分のコストは、DevSecOpsプロセスとビジネスへの影響と比較してわずかだった」とコメントしています。

ケーススタディの全文はこちらからご確認ください。