前回、国際的な開発者イベントである今年のArdupilot Developer Conference 2025の内容を紹介したが、最前線の現在のドローンの開発現状を感じ取れたのではないかと思う。
Vol.94今年のArdupilot Developer Conference[春原久徳のドローントレンドウォッチング]
しかし、かなり専門的な内容であり、尖がった部分も多く、今回はもう少し一般的な形での、現時点で求められているドローン関連の技術の話をしたい。
- Advertisement -
機体制御
ドローン技術の中心にある機体制御の技術であるが、基本機体制御に関しては既にかなり安定してきており、この機体制御においては、技術的な課題として、なお残っているのは非GPS環境下での自己位置推定という部分だろう。この部分に関しては以前このコラムでも取り上げているので、それをご覧になっていただきたい。
Vol.69 室内空間でのドローン[春原久徳のドローントレンドウォッチング]
その他の機体制御に関しては、より精緻な衝突回避というところが、まだ課題としては残っている。また、機体制御という部分においては、後述するテーマとも関わってくるが、エラー時の機体制御ということになってくるだろう。
現在求められているドローン関連技術の背景
ドローン現場実装はゆっくりではあるが進んできている。ニュースなどで取り上げられるものは実証実験というフェーズのものが多く、現場実装のケースはニュースになりにくく、外から見た場合にその進捗度合が分かりにくいが、現場でのドローン活用は一部領域においては進んできており、定着している現場もある。（筆者はドローンビジネス調査報告書を執筆しているという立場もあるが、そういった点においても、現場実装になればなるほど取材がしにくくなっている。それはユーザー企業がドローンの現場実装をメディアにオープンするということのメリットが少ないということもある。そのため、取材してもオフレコでというケースも多い）
そういった意味では、実証実験のニュースそのものが、「まだ実証実験フェーズなんだ」というネガティブな印象を与えている場合も段々と出てきている。
以前もこのコラムでも取り上げているが、現場実装に向けては、実証実験・実運用検証・実運用というプロセスを踏んで進んでいくのであるが、多くのプロジェクトが実運用検証というプロセスにおいて、つまずいているケースが多く、場合によっては、そこから先に進めることを止めてしまっているプロジェクトもある。
- Advertisement -
これは日本企業ならではの現場でのコンサーバティブな環境もあるが、やはりドローン関連技術の未熟さもあるだろう。実証実験と実運用検証の大きな違いは、実証実験は「何が出来るか、もしくは、導入したときのメリット・デメリット検証（経済性の検証も含む）」となるが、実運用検証においては、「いかに安定的に使えるか、その現場負荷はどのぐらいか」という目線の違いとなる。
これも多くの企業が抱える経営管理サイドと現場サイドのギャップと同様なものとなっている。そういった意味においては、ドローン技術の中心点がより現場目線に近いものが必要になってきている。それは「安定性（使い勝手を含む）」と「安全性（セキュリティも含む）」ということになる。
安定性
「安定性」というのは、「特別に専門知識や技能がなくても使い勝手がよく、毎回安定的に目的に対する結果が出せる」ということである。まず、こういった部分が実証実験では検証が少なく、現場はこういった目線が強いので、ここに大きなギャップが生まれている。
いわば、そのギャップを埋めるための技術が求められている。このギャップを埋めるための技術の説明の前に、最近、ドローン関連企業とユーザー企業との間での認識ギャップとして大きいのは、ユーザー企業において現場（実運用検証の窓口）から差し戻しを受けた技術企画チーム（実証実験の窓口）が、ドローン・イン・ザ・ボックス（ドローンポート）といった「完全無人全自動」のソリューションに一足飛びに向かうという動きである。
「完全無人全自動」においては、最終ゴールとして「完全無人全自動」をターゲットするのはないわけでなく、その実現のための技術のパーツは揃ってきてはいるものの、これが実現するまでは現場実装出来ないという形にすると、実装が大きく遅れることになる。そういった意味では、現実に即した技術と導入に関して、適切なロードマップを作成して、段階的に導入していくといったプロセスが重要になってくる。
閑話休題
「安定性」の技術に話を戻そう。
まず、その視点として、重要なのはユーザーインターフェイスとなる。
そのために、現在、GCS（Ground Control Station：地上基地局）の改良ということが各機体メーカーやドローンのサービス事業者の間で行われている。それはドローンの専門家としての使い勝手といった目線から、一般ユーザーの使い勝手といった目線のシフトである。そのこと自体はとても重要であるし、有意義な方向性であるのだが、ドローンの運用の難しさは、そういった端末操作や理解の難しさもその一因ではあるが、機体の使用を重ねる中での機体の状態変化や現場環境の変化という流動性とその流動に対しての適正化ということにある。様々な要素が絡むので、逆にインターフェイスを簡略化することにより、その調整が難しくなるというケースをよく見かける。ドローン自体やその活用環境そのものが流動性が高く、それをいかになるべく安定的な状態にもっていくかということが重要だからだ。
ユーザーでの安定性を高めるために重要なのは、その安定的な状態にもっていくための自動化のプロセスにある。
機体の安定運用に関して重要なのは、飛行前の状態確認となる。
機体の安定性に関して重要な要素は、やはり前回の飛行時のログ解析による異常状態の検出と飛行直前の機体の自動診断である。今まで優れたドローンの専門家はこういったことを意識的に行ってきており、そういった経験の中で安定的な運用を実現させている。
少なくとも、機体メーカーはこういった機能をきちんと実装し、GCSと連携を取ることが重要となってくる。特に前回の飛行時のログ解析に関しては、AIとの連動というのも有効な手段になってきている。
- Advertisement -
また、活用環境に関してもその流動的な要素は多い。例えば、地形、障害物、天候（雨、風など）、GPS状態、各種通信状態などがそれにあたる。これも優れたドローンの専門家はこういった要素を意識的に考慮して、安定的な運用をさせてきたのだ。
この活用環境に関しては、生成AIを始めとしたAIとの相性がとてもよいエリアだ。先ほど挙げたような要素をAIに送りこみ、目的に応じて安定的な運航ルートの生成を行うと同時に、まだ、そういった連携は少ないが、今後、重要になってくるのは、環境に応じて、適切なフェイルセーフへの設定変更というものも自動に行えるようになれば、ユーザーの中で、より安定的な運用が増していくだろう。
安全性（セキュリティも含む）
安全性に関しては、やはり重要なのは、安全性向上のためのプロセスというものになる。先日、このコラムでも伝えた米国のPart108の新規定はこの安全性に関しての姿勢も大きく変わっていっている。
Vol.93米国におけるPart108の新規定発表[春原久徳のドローントレンドウォッチング]
今回、Part108の新規定の発表が衝撃をもって迎えられたのは、型式認証と操縦資格を不要にした点であったが、これにより安全性に関して当局（国など）の責任から各ユーザー企業の自己責任に完全にシフトしたことにある。このことは、機体メーカーにとっては、セーフティやセキュリティのホワイトペーパーの準備ということへの急激なシフトにつながっている。これはユーザー企業が機体導入の際に、機体メーカーにそういったペーパーを求めることが必須になると想定されるからだ。また、この動きに損害保険会社のサービスへの連動準備も始まっている。（日本においても、各省庁と会話する機会があり、その行方には注視しているということで、今後、何らかの影響が考えられる）
「安全性（狭義のセーフティ）」と「セキュリティ」の違いに関しては、「セーフティ」が偶発的な要因に対して、「セキュリティ」が故意的な要因となっており、実運用が増えていく状況やウクライナ戦争を発端とするカウンタードローン・アンチドローンの技術向上によるドローンへの攻撃手法が悪意ある第三者の手に渡りやすくなってきているといった状況などにより「セキュリティ」のリスクも高まってきている。海外においては具体的な事例も見かけるようになってきた。
筆者はドローンのコンサルティング業務を行っているが、機体メーカーからこういったホワイトペーパーの作成に向けたコンサルティング依頼が増えてきている。
この「セーフティ」と「セキュリティ」に関するホワイトペーパーの方向性に関しては、一定の枠組みがある。
今回、その詳細は省略するが、大枠は以下の枠組みとなっている。
「セーフティ」に対しては以下となる。
DO-178C（ソフトウェア）とDO-254（ハードウェア）がその中心的な枠組みだ。
＊DO-178C（Software Considerations in Airborne Systems and Equipment Certification）
発行：RTCA（米国）／EUROCAE（欧州）
目的：航空機搭載ソフトウェアの安全性保証（Design Assurance）
対象：フライトコントロール、ナビゲーション、監視、通信などのソフトウェア
目的は単なる「動作テスト」ではなく、ソフトウェアが安全上の要求を満たすことを"証明可能"にすること
＊ DO-254（Design Assurance Guidance for Airborne Electronic Hardware）
発行：RTCA（米国）／EUROCAE（欧州）
目的：航空機搭載電子ハードウェアの安全性保証
対象：FPGA／ASIC／PLD／MCU／センサIF／制御ボードなど、電子設計レベルの安全性
ハードウェアに潜む設計ミス（ロジック、タイミング、ノイズ等）を防止するため、システマティックな設計・検証・構成管理プロセスを要求
| 項目 | DO-178C（ソフトウェア） | DO-254（ハードウェア） |
|---|---|---|
| 対象 | フライト制御ソフト、地上局アプリ、組込RTOS上プログラム | FPGA、マイコン、センサ回路、I/O基板 |
| 中核目的 | ソフトウェアが安全要求を満たすことを保証 | ハードウェアが安全要求を満たすことを保証 |
| 基本単位 | ソースコード、バイナリ、要件、テスト | 回路設計、ロジック設計、配置配線、テスト |
| トレーサビリティ | 要求 → 設計 → コード → テスト | 要求 → 設計 → 論理 → 実装 → 検証 |
| 検証手法 | 静的解析・MC/DC・ユニットテスト | シミュレーション・タイミング解析・製造検査 |
| 最終成果物 | Software Accomplishment Summary（SAS） | Hardware Accomplishment Summary（HAS） |
「セキュリティ」に対しては以下となる。
DO-326BとDO-356A、DO-355Aがその中心的な枠組みだ。
| 分類 | 文書名 | 役割 | 内容概要 |
|---|---|---|---|
| 上位プロセス標準 | DO-326B《Airworthiness Security Process Specification》 | 要求定義書（WHAT） | 航空機システム（UAV含む）のセキュリティプロセス全体の枠組みを定義。脅威分析（TARA）、リスクアセスメント（ASRA/SSRA）、セキュリティ要求の導出、検証、承認の流れを定義。 |
| 補完的手法標準 | DO-356A《Airworthiness Security Methods and Considerations》 | 実装・手法ガイドライン（HOW） | DO-326Bで定義されたプロセスを実施するための詳細手法や例示を示す。脅威分析手法、セキュリティケース構築法、検証例、攻撃パターン例など。 |
| （関連文書） | DO-355A《Information Security Guidance for Continuing Airworthiness》 | 継続運用フェーズ | 飛行後・運用中（maintenance phase）のセキュリティ管理（例：パッチ管理、鍵更新、運航後レビューなど）。 |
「セーフティ」「セキュリティ」ともに、その作成するためのプロセスが重要となっており、それは以下のプロセスを辿る。
- リスクアセスメント
- リスク事象や影響を受ける各部品に至るまで網羅的にリスクアセスメントを実施。
- 対策方針
- 起こりやすさと影響度のメトリックスによって、どこまで対策を行うかの対策方針を決める。
- 対策実施
- 対策に関して、三つの対策フェーズがあり、一つめは起こらない対策、二つめは起こったときの対策（フェイルセーフ）、三つめは運用での対策となる。
- テスト
- ここの対策に関してのテストとなり、第三者が行うケースが多い。
- 残存リスク
- 起こりやすさと影響度のメトリックスによる許容可能な範囲において、対策をしても残ってしまうリスクに関して、特に運用での対策における注意点を明確化する。
こういった「安全性」に関するホワイトペーパーに準じた技術向上が求められているが、それは対策実施の中でも記載したが、起こらないための対策技術と起こったときの対策技術（フェイルセーフ）となる。特に起こらないための対策技術は二重化なども含めたハードウェア中心の技術となるが、起こったときの対策技術はソフトウェア中心の技術となる。特にフェイルセーフに関しては、私自身はインテリジェントフェイルセーフと呼んでいるが、より高度なフェイルセーフに向けた技術向上が高まっている。例えば、GPS妨害やGPSのスプーフィングをされたときのフェイルセーフなど、様々なフェイルセーフ技術が出てきている。機体メーカーはこういったインテリジェントフェイルセーフをきちんと実装していくことも重要になってきている。
現在、ドローンの技術開発をしている方やこれからドローンの技術開発に興味のある方もこれまでの機体制御や機体管理、ペイロード管理といった部分に合わせて、「安定性」や「安全性」といった目線からもその技術向上に取り組んでいただければと思う。
