耐障害性ドローン群設計：セキュア通信を備えたリーダーレス・トレラント・メッシュネットワーク

はじめに

ドローンはもはや単独の存在ではありません。捜索救助、精密農業、インフラ点検、安全保障といった現代のミッションは、スウォーム（群れ）への依存度を高めています。スウォームとは、タスクを分担し、状況認識を共有し、単機では達成できない目標を協調して実現するUAV群です。

しかしこの協調は、困難なエンジニアリング課題を生み出します。地上管制局（GCS）も中央サーバーも存在せず、どのドローンもミッション全体を通じて生存が保証されない状況で、何が起こるのでしょうか？

本記事では、ピアツーピアのメッシュネットワーク上で完全自律動作し、コマンダーが故障した際に動的にリーダーを選出し、スウォームの結束を脅かす最大の危険要素であるシグナルジャミングと通信ハイジャックから自らを守るドローン群ソフトウェアの設計を解説します。

日本の規制背景： ドローン群システムが個人の映像・位置情報・個人情報を収集・送信する場合、個人情報保護法（APPI） の適用を受ける可能性があります。重要インフラへの活用（電力・通信・交通等）は、NISC（内閣サイバーセキュリティセンター） のサイバーセキュリティ戦略および 経済安全保障推進法 における特定重要物資・基幹インフラ制度の対象となりうるため、設計段階からのセキュリティ評価が求められます。また、防衛・安全保障用途への転用を検討する場合は、経済産業省 の安全保障貿易管理（外為法）に基づく該非判定が必要です。

コア設計課題

従来のドローンシステムはGCSを権威として前提とします。GCSがコマンドを送り、ドローンが従う。GCSを取り除いた場合 — 設計上（長距離自律ミッション）であれ、状況上（ジャミング、オペレーター喪失）であれ — スウォームは自律的に統治しなければなりません。

そこから三つの要件が導かれます：

1. 分散型協調 — どのドローンも必要に応じてスウォームを指揮できなければならない。単一障害点を持たないこと。

2. 永続的なミッション状態 — 個々の機体が失われてもミッションが継続できるよう、すべてのドローンがミッションプランの完全なコピーを保持していなければならない。

3. 認証済み通信 — 中央権威のないメッシュネットワークでは、すべてのメッセージが暗号学的に検証可能でなければならない。到着したからといってパケットを信頼することはできない。

Layer 1: メッシュネットワーク

中央ルーターなしに、ドローンはワイヤレスメッシュを介してピアツーピアで通信します。各ドローンはネイバーテーブル — 受信できるピアのリスト、信号強度、最後のハートビートのタイムスタンプ — を管理します。

メッシュレイヤーに適したプロトコルの選択肢：

MAVLink over 802.11s Wi-Fi mesh — 研究・民間用途に適しており、既存のMAVLinkツールを活用できる
FHSS無線上のカスタムUDPブロードキャスト — 競争的環境に優れている（セキュリティセクションで詳述）
DDS（Data Distribution Service） — リアルタイム分散pub/sub専用設計。ROS 2で使用されており、スウォーム協調に適している

メッシュの各ノードは定期的に、自身のID・位置・バッテリー残量・現在の役割を含む HELLO パケットをブロードキャストします。これがハートビートであり、障害検出システムの基盤です。

図1 — ピアツーピアメッシュトポロジー（中央権威なし）

flowchart TD
  D1["Drone 1\n(Commander)"]
  D2["Drone 2\n(Follower)"]
  D3["Drone 3\n(Follower)"]
  D4["Drone 4\n(Follower)"]
  D5["Drone 5\n(Follower)"]

  D1 -- "HELLO + tasks" --> D2
  D1 -- "HELLO + tasks" --> D3
  D1 -- "HELLO + tasks" --> D4
  D2 -- "HELLO + status" --> D1
  D3 -- "HELLO + status" --> D1
  D4 -- "HELLO + status" --> D1
  D2 -- "P2P position" --> D3
  D3 -- "P2P position" --> D4
  D4 -- "P2P position" --> D5
  D5 -- "P2P position" --> D2

各ドローンのソフトウェアスタック

図2 — ドローン1機あたりのソフトウェアレイヤー構造

flowchart TD
  ME["Mission Execution\nTask state machine, waypoints"]
  CE["Consensus / Election\nHeartbeat timer, role FSM, vote logic"]
  MN["Mesh Network\nUDP socket pool, neighbor discovery, routing"]
  HL["Hardware Abstraction (HAL)\nGPS, IMU, MAVLink to flight controller"]
  SW["Safety Watchdog\nIndependent timer thread — hover or RTH on timeout"]

  ME --> CE
  CE --> MN
  MN --> HL
  SW -. "monitors all layers" .-> ME
  SW -. "monitors all layers" .-> CE
  SW -. "monitors all layers" .-> MN

Safety Watchdogはすべてのレイヤーから独立して動作します。有効なコマンドやハートビートが T_safe 秒以内に届かない場合 — ドローン自身のコマンダー役割からのものも含めて — 安全なホバリングまたはリターン・トゥー・ホーム（RTH）をトリガーします。これがソフトウェアデッドロックに対する最後の防衛線です。

Layer 2: 役割ステートマシン

すべてのドローンは3状態の有限状態機械（FSM）を実行します。

図3 — ドローン役割ステートマシン

flowchart TD
  F["FOLLOWER\nDefault state\nExecute tasks, listen for heartbeat"]
  C["CANDIDATE\nElection triggered\nBroadcast ELECTION + priority score"]
  CM["COMMANDER\nQuorum achieved\nIssue tasks, broadcast LEADER"]

  F -- "Heartbeat timeout > 1.5s" --> C
  C -- "Wins quorum vote" --> CM
  C -- "Loses vote" --> F
  CM -- "New commander elected" --> F

FOLLOWER — デフォルト状態。コマンダーのハートビートを監視し、ローカルのミッションプランコピーから割り当てられたタスクを実行し、自身の位置とステータスをピアへ継続的にブロードキャストします。

CANDIDATE — コマンダーのハートビートが N × heartbeat_interval（通常 3 × 500ms = 1.5秒）以上受信されないとき移行します。自身のIDとプライオリティスコアを含む ELECTION メッセージをブロードキャストし、ピアから票を収集します。

COMMANDER — ピアの過半数が投票した際に移行します。LEADER アナウンスをブロードキャストし、ピアのブロードキャストからスウォーム状態テーブルを再構築し、タスク配分を再開します。

選出のプライオリティスコア

複数のドローンが同時に選出をトリガーした場合、最も高いプライオリティスコアを持つものが勝ちます。実用的なスコアリング関数：

def priority_score(drone) -> float:
    battery_weight   = 0.5
    reach_weight     = 0.3
    role_weight      = 0.2

    battery_score = drone.battery_pct / 100.0
    reach_score   = len(drone.visible_peers) / MAX_SWARM_SIZE
    role_score    = 1.0 if drone.mission_role == "SCOUT" else 0.5

    score = (battery_weight * battery_score +
             reach_weight   * reach_score   +
             role_weight    * role_score)

    # Drone UUIDをタイブレーカーとして使用 — 決定論的、真の同点なし
    return (score, drone.uuid)

スプリットブレイン解決

スウォームが2つの切断されたグループに分割した場合、それぞれが独自のコマンダーを選出します。再接続時、両コマンダーは (election_term, timestamp) タプルを比較します。より高いタームが勝利。同じタームの場合はより新しいタイムスタンプが勝利。敗者はFOLLOWERに降格し、勝者から完全なミッション状態同期を要求します。

Layer 3: ミッション状態同期

ミッションプランへのすべての変更は単調増加するバージョン番号を持ちます。新しいコマンダーが引き継ぐ際：

最後に知っているバージョン番号と共に SYNC_REQUEST をブロードキャストする
フォロワーが自身のバージョンとミッション状態のハッシュで応答する
コマンダーが最高バージョンの権威ある状態を特定し、正規プランとして再ブロードキャストする
すべてのドローンが受領をACK — コマンダーはタスク配分を再開する前にスウォームが同期済みとマークする

タスクは べき等ステートマシン として設計されます。ドローンがタスク途中で通信を失った場合、タスクに定義された最も近い安全なチェックポイントまで実行し、ホバリングして再接続を待ちます。中断もせず、最初からやり直しもしません。

図4 — コマンダーフェイルオーバー後のミッション状態同期

flowchart TD
  A["Commander fails\nHeartbeat timeout detected by followers"]
  B["Election completes\nNew commander elected"]
  C["New commander broadcasts\nSYNC_REQUEST + last known version"]
  D["All followers respond\nversion number + state hash"]
  E["New commander identifies\nhighest-version authoritative state"]
  F["Rebroadcast canonical\nmission plan to all drones"]
  G["All drones ACK\nMission resumes"]

  A --> B
  B --> C
  C --> D
  D --> E
  E --> F
  F --> G

Layer 4: アンチジャミング（物理レイヤーセキュリティ）

シグナルジャミングはドローン運用において最も一般的な物理レイヤー攻撃です。攻撃者は動作周波数をノイズで溢れさせ、ドローンを聾唖状態にします。

基本的な防御は周波数を予測不可能にすることです。

周波数ホッピング拡散スペクトラム（FHSS）

スウォームのすべてのドローンは事前に合意した疑似乱数ホップシーケンスを共有します — 通常、900 MHzまたは2.4 GHz帯域で毎秒50〜100ホップ。ジャマーが効果を発揮するには帯域全体を同時にカバーする必要があり、狭帯域ジャマーよりも桁違いに多くの電力を必要とします。

Time:  T0        T1        T2        T3        T4
Freq:  920 MHz → 2412 MHz → 915 MHz → 2437 MHz → 922 MHz ...
         ↑ ミッションロード時にスウォーム全員が共有するシーケンス

直接拡散スペクトラム（DSSS）

DSSSSはチッピングコードを使用して広帯域幅に信号を拡散します。外部の観察者 — ジャマーにとっても — 信号はノイズのように見えます。復号には正しいコードが必要です。これはGPS信号で使用されている原理と同じです。

デュアルバンド運用

長距離メッシュバックボーン用に900 MHz（障害物透過性が高く、広帯域ジャミングが困難）、高帯域幅の短距離協調用に2.4/5.8 GHzを使用します。一方のバンドを標的にしたジャマーはすべての通信を遮断できません。

ジャミング検出と自律フォールバック

SNR_THRESHOLD = -85  # dBm
JAM_DETECTION_WINDOW_MS = 300

if rolling_avg_snr(window=JAM_DETECTION_WINDOW_MS) < SNR_THRESHOLD:
    switch_to_backup_hop_sequence()
    reduce_coordination_to_position_broadcast_only()
    execute_last_valid_mission_segment()

図5 — アンチジャミング検出とグレースフルデグラデーションフロー

flowchart TD
  A["Normal operation\nFHSS primary hop sequence\nFull mesh coordination"]
  B{"SNR below\nthreshold\n> 300ms?"}
  C["Jam detected\nSwitch to backup hop sequence"]
  D["Reduce comms\nPosition broadcast only"]
  E["Execute last valid\nmission segment autonomously"]
  F{"SNR\nrecovered?"}
  G["Restore full\nmesh coordination"]
  H["Safe hover or RTH\nif T_safe exceeded with no signal"]

  A --> B
  B -- "No" --> A
  B -- "Yes" --> C
  C --> D
  D --> E
  E --> F
  F -- "Yes" --> G
  G --> A
  F -- "No, timeout" --> H

Layer 5: 暗号認証

ジャミングは通信を拒否します。スプーフィングは通信を汚染します。メッシュにパケットをインジェクトできる攻撃者は、偽のタスクコマンドを発行したり、偽のリーダー選出をトリガーしたり、偽の位置を報告したりすることができます。

ドローンごとの非対称署名（Ed25519）

各ドローンは製造時に生成され、ATECC608Aなどのハードウェアセキュリティ要素（HSE）に格納されたEd25519キーペアを持ちます。秘密鍵は物理的に抽出不可能です。

ミッションロード時にすべての公開鍵がすべてのドローンに配布されます。すべてのパケットは送信者の秘密鍵で署名されます。不明なIDまたは無効な署名のパケットは静かに破棄されます。

つまり、捕捉・再プログラムされたドローンでも正規のスウォームメンバーになりすますことができません。

リプレイ攻撃防止

すべてのパケットには単調増加するシーケンス番号とランダムなノンスが含まれます。受信側は送信者ごとに受け入れ可能なシーケンス番号のスライディングウィンドウを維持します。

パケット形式:
[ Drone ID (4B) | Seq+Nonce (12B) | Encrypted Payload | HMAC Tag (16B) | Ed25519 Sig (64B) | Hop TTL (2B) ]

ペイロード暗号化（AES-256-GCM）

すべてのペイロードデータはAES-256-GCMで暗号化されます。GCMモードはAEAD暗号 — 1回のパスで機密性と認証の両方を提供します。AESハードウェアアクセラレーションのないARM Cortex-Mプラットフォームでは、ChaCha20-Poly1305が軽量な代替手段です。

図6 — パケット受信認証パイプライン

flowchart TD
  A["Packet received\nover mesh"]
  B{"Drone ID\nin known list?"}
  C["Drop silently\nLog unknown sender"]
  D{"Sequence number\nin valid window?"}
  E["Drop silently\nReplay or out-of-order"]
  F{"Ed25519 signature\nvalid?"}
  G["Drop silently\nFlag sender as suspect"]
  H{"AES-GCM auth\ntag valid?"}
  I["Drop silently\nDecryption failure"]
  J["Decrypt payload\nPass to mission layer"]

  A --> B
  B -- "No" --> C
  B -- "Yes" --> D
  D -- "No" --> E
  D -- "Yes" --> F
  F -- "No" --> G
  F -- "Yes" --> H
  H -- "No" --> I
  H -- "Yes" --> J

Layer 6: GPSスプーフィング対策

偽のGPS信号をブロードキャストする攻撃者は、メッシュ通信に一切触れることなく、ドローンのナビゲーションを完全にリダイレクトできます。

マルチコンステレーションGNSS — GPS（米国）、GLONASS（ロシア）、Galileo（EU）を同時にトラッキングする受信機を使用します。3つすべてを独立してスプーフィングするには、はるかに高度な機器が必要です。

拡張カルマンフィルター（EKF）によるIMUクロスバリデーション — GPSをアクセロメーター・ジャイロスコープ・気圧計データと融合します。GPSが100ms以内に50mの位置ジャンプを報告し、IMUが対応する加速を報告しない場合、GPSアップデートは拒否されます。

信号品質モニタリング — 正規のGPS信号は複数の衛星から期待されるSNRとドップラーシフト値で届きます。スプーファーは通常、単一の異常に強い信号源を生成します。

図7 — GPSスプーフィング検出とEKFフォールバック

flowchart TD
  A["GNSS fix received\nGPS + GLONASS + Galileo"]
  B{"Multi-constellation\nconsistent?"}
  C["Flag spoofing\nDiscard GNSS fix"]
  D{"Position delta vs\nIMU prediction\nwithin threshold?"}
  E["Reject GPS update\nLog anomaly"]
  F{"Signal SNR and\nDoppler normal?"}
  G["Flag strong single\nsource spoofing"]
  H["Accept GPS fix\nFuse into EKF\nwith accelerometer + baro"]
  I["Dead reckoning\nIMU-only navigation\nuntil GNSS recovers"]

  A --> B
  B -- "No" --> C
  C --> I
  B -- "Yes" --> D
  D -- "No (jump detected)" --> E
  E --> I
  D -- "Yes" --> F
  F -- "No (anomalous)" --> G
  G --> I
  F -- "Yes" --> H

鍵管理

暗号は鍵管理と同程度の強度しか持ちません。実際のシステムで最も弱い点はアルゴリズムではなく、鍵の配布と保管の方法です。

製造時： ドローンごとにEd25519キーペアを生成。秘密鍵をHSEに格納。FHSSホップシーケンスとメッシュネットワークパラメータをロックされたプロビジョニングBlobとしてフラッシュ。

ミッションロード時： ミッションスコープのAES-256-GCMセッション鍵を生成。すべての公開鍵をセキュアUSBまたはエアギャップされた信頼できるプロビジョニングステーションを介してすべてのドローンに配布。推測を防ぐためにシーケンス番号をランダムオフセットで開始。

ミッション終了 / 捕捉リスク時： コマンドに応じてRAMからセッション鍵をゼロ化、または設定可能な T_timeout の無効コマンド後（デッドマンスイッチ）。

ドローン侵害時： 侵害されたドローンの公開鍵を、コマンダー自身の鍵で署名されたブロードキャストを通じて失効。すべてのピアがIDをブロックリストに追加。

図8 — 暗号鍵ライフサイクル

flowchart TD
  MFG["Manufacturing\nGenerate Ed25519 keypair\nStore private key in ATECC608A HSE\nFlash FHSS hop sequence"]
  LOAD["Mission load\nGenerate AES-256-GCM session key\nDistribute all public keys to all drones\nSet random sequence number offset"]
  FLY["In-flight\nSign every outgoing packet\nVerify every incoming packet\nRotate nonces per packet"]
  END{"Mission end\nor capture risk?"}
  ZERO["Zeroize session keys from RAM\nDead man switch if T_timeout exceeded"]
  COMP{"Drone\ncompromised?"}
  REV["Commander broadcasts\nsigned key revocation\nAll peers add to blocklist"]
  DONE["Keys invalidated\nDrone excluded from swarm"]

  MFG --> LOAD
  LOAD --> FLY
  FLY --> END
  END -- "Yes" --> ZERO
  END -- "No" --> COMP
  COMP -- "Yes" --> REV
  REV --> DONE
  COMP -- "No" --> FLY

実装の出発点

レイヤー	推奨スタック
フライトコントローラー	MAVLink経由のPX4またはArduPilot
メッシュ無線ハードウェア	Doodle Labs RM-915-XTまたは同等のFHSS対応SDR
メッシュルーティング	OLSRまたはBATMAN-adv（Linux）
選出/コンセンサス	C++またはRustによるカスタムRaft-inspired実装
Pub/sub協調	DDS（FastDDS/Cyclone）またはカスタムUDPマルチキャスト
暗号プリミティブ	libsodium（Ed25519、ChaCha20-Poly1305、AES-GCM）
鍵保管用HSE	Microchip ATECC608A
GPS受信機	u-blox F9P（マルチコンステレーション、アンチスプーフィングフラグ）

まとめ

通信競争環境における自律型ドローン群ソフトウェアの設計は、レイヤーで考えることを要求します。

メッシュレイヤーはピアツーピア接続を中央依存なしに提供します。選出レイヤーは常に正確に1台のコマンダーを保証し、障害発生後数秒以内に代替を昇格させます。ミッション状態レイヤーは他の機体に何が起きても各ドローンがミッションを引き継げることを保証します。物理セキュリティレイヤー（FHSS/DSSS）は通信をジャミングに耐えられるほど予測不可能にします。暗号レイヤー（Ed25519 + AES-GCM + シーケンス番号）は正規のスウォームメンバーのみがコマンドを発行・受信できることを保証します。そしてGPS保護（マルチGNSS + IMU融合）はナビゲーション攻撃面を閉じます。

日本の文脈では、重要インフラへのドローン群導入にあたり、NISCのサイバーセキュリティガイドラインに沿った設計レビューと、経済安全保障推進法に基づく基幹インフラ事業者への該当可否確認が推奨されます。また、日本の現行踏襲文化を考慮すると、既存の運用手順との統合設計を段階的に進めるアプローチが実装成功の鍵となります。

すべてのプリミティブは実績のあるオープンソースコンポーネントとして利用可能です。エンジニアリングの課題は、実際のドローンハードウェアの重量・電力・計算リソースの制約下で正しく統合することにあります — そこにこそ最も興味深い作業があります。

Simplicoは分散型組込みシステム、AIインフラ、セキュアIoTプラットフォームを構築しています。自律システムやスウォームロボティクスに取り組んでおり、技術パートナーをお探しの場合は simplico.net までお問い合わせください。UTC+7/JSTオーバーラップによるリモート協業も対応しています。