運航管理システムは、有人機向けのOCC、空港運用、ドローン向けのUTMSに分けて捉えます。必要な情報を結び付け、安全と定時性を支えるシステムです。
開発工程、費用、選定と発注の要点は、それぞれ次の関連記事で詳しく扱っています。
▼関連記事一覧
・運航管理システム開発の進め方
・運航管理システム開発でおすすめの開発会社6選と選び方
・運航管理システム開発の見積相場・費用
・運航管理システム開発の発注・外注・委託方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
運航管理システムの定義と役割
運航管理システムは、飛行計画と運航状況を中心に、機材や乗務員、空域、気象などをまとめて管理する業務基盤です。遅延や欠航などの異常が起きたときにも、安全な再計画を支えます。
運航管理システムは、計画の作成から、状況の変化の把握、関係部署への共有、承認後の再計画まで、一連の流れを支えます。
対象は航空機、ドローン、空港などで異なります。それでも、安全と定時性のために複数のデータを結び付ける点は共通しています。
「運行」と「運航」の違い
「運行」は一般に、鉄道や車両、配送車などを走らせることを指します。一方、「運航」は、航空機や船舶などを運用することを指します。
航空分野では、飛行計画や航空情報、気象、重量・重心、燃料を扱います。さらに、機材整備や乗務員資格も対象になります。道路上の車両管理で重視される走行ルートや配車とは、対象がそもそも異なります。
検索すると用語を混同しやすいため、発注側は提案依頼書に「有人航空機向け」か「無人航空機向け」かを明記します。
運航管理システムが必要な理由
運航では、天候、機材、空港、乗務員、空域などの条件が同時に変わります。こうした中で、各担当者が表計算や電話で別々に管理すると、情報が食い違い、判断に時間がかかります。
システムでは、変更履歴を残し、共通の状況を画面に表示します。さらに、誰がどの制約を確認して判断したかも追跡できます。
導入の効果は、平常時の事務作業だけでなく、台風、大雪、機材故障、通信断などの例外時にどれだけ復旧できるかにも左右されます。
運航管理システムの種類と主要機能
まず、誰が何を運航するシステムかで分けて考えます。有人機のOCC、空港運用、ドローンのUTMSは互いに連携することもありますが、1つの製品ですべてを置き換えるものではありません。
現実的なのは、既存の予約・搭乗、空港運用、整備、貨物などの基幹システムを活かし、運航判断に必要な情報を連携させる設計です。
有人航空機向けOCCの機能
有人航空機向けOCCが扱う情報は、次のとおりです。計画から異常時の再配置まで、担当者はこれらをまとめて確認します。
- 計画・割当：飛行計画、機材、乗務員の勤務・資格
- 運航条件：燃料、重量・重心（W&B）、気象、NOTAM
- 運航状況：出発・到着時刻、飛行位置、燃料、空港側の制約
- 異常時の候補：代替機、乗務員交代、経路変更
AIや最適化エンジンの案は、そのまま自動で実行せず、担当者が承認するHuman-in-the-loopを基本とします。そのうえで、候補、根拠、影響範囲を示し、判断の材料をそろえます。
また、判断結果と入力データは監査ログに残し、安全性と業務上の妥当性を後から検証できるようにします。
ドローン向けUTMSの機能
UTMSは、UAS Traffic Management Systemの略称で、複数の無人航空機を安全に運航するための空域管理基盤です。計画の段階から記録までを、一つの基盤の中で追える点に役割があります。
- 飛行計画：登録と重複調整
- 機体の監視：位置のリアルタイム表示
- 空域・安全情報：飛行禁止・制限空域、三次元地形、気象、接近アラート
- 記録：運航記録
国土交通省が2026年4月に公開したUSP制度の説明では、UTMSは飛行計画や実際の飛行状況、地図・気象情報を共有し、空域の安全利用を支える仕組みとされています（出典: 国土交通省「USP制度」、2026年）。
DIPS2.0と接続する場合は、登録、飛行許可・承認、飛行計画通報のうち、どこまでを自社の画面に取り込むかを決めます。国土交通省は2026年6月にAPIの整備状況を更新しているため、開発会社と仕様や利用申請の要件を確認します。
将来の仕様変更に備えて連携層を分けておくと、保守の負担を抑えられます（出典: 国土交通省「ドローン情報基盤システム」、2026年6月22日更新）。
共通するシステム構成と連携先
構成要素と連携先を分けて整理すると、必要なデータ基盤や接続範囲を把握しやすくなります。
- システム構成：画面、業務API、外部連携、イベント・時系列データ基盤、通知・監査ログ、認証・権限管理
- 有人機の連携先：予約・搭乗、空港運用、整備、貨物、気象、航空情報
- ドローンの連携先：機体テレメトリ、地図・地形、気象、空域、DIPS2.0、複数事業者のUTMS
位置情報や接近アラートはイベント処理で扱い、分析や帳票は蓄積データから作成します。リアルタイム性が求められるデータと集計データでは、処理方式を分けて設計します。
機体や拠点が増えたときも改修範囲を抑えられるよう、標準API、疎結合のサービス、データ辞書、監査用の時刻同期を初期設計に含めます。
運航管理システム開発の進め方
運航管理システムは、画面から作り始めると失敗しやすい領域です。そのため、欠航、代替機、乗務員不足、空域制限、通信断などの例外を先に洗い出します。
発注側と開発会社は、安全要件と業務要件を分けて合意します。そのうえで、限定した範囲をPoCで検証してから、段階的に本番へ広げます。
企画と要件定義で決める内容
企画では、対象領域と運用条件を決めます。具体的には、次の情報を明確にします。
- 対象：有人機OCC、空港運用、ドローンUTMS
- 規模：対象機体数、便数、拠点数、利用者数
- 運用：24時間運用の有無、既存システム
発注側の現場担当者と一緒に、現場の一日の流れを時系列で描きます。次に、誰がどのデータを見て、どの条件で承認し、どの部署へ通知するかを洗い出します。
要件は「安全・法令」「業務効率」「分析・AI」の3層に分けると、優先順位を付けやすくなります。なかでも安全・法令では、承認、権限分離、フェイルセーフを先に決めます。ログ保存、RTO・RPO、可用性も、早い段階で決めておきます。
業務効率では、画面や通知の設計、再計画、モバイル利用の範囲を決めます。なお、分析・AIは、入力データの品質と人による承認の方法が定まってから追加します。
PoCと設計での検証項目
PoCでは、実データに近い気象・位置・計画データを使って、次の動作を確かめます。
- 表示・通知：地図統合表示、アラートの遅延
- 判断支援：再計画候補、権限別画面
- 障害対応：通信断からの再同期
デモ用に整ったデータだけでは、欠損や時刻のずれ、重複イベントが見えてきません。外部API停止時の挙動も、確かめられないままになります。そのため、正常系と異常系を同じテストシナリオに含めます。
設計では、データ連携図に、どのシステムが正しい値を持つかを書きます。あわせて、更新頻度、単位、識別子を記し、失敗時の再送と手動補正の扱いも明らかにします。
クラウドを採用する場合も、通信断や外部サービスの停止を想定します。端末側のキャッシュと、再接続時の競合解決を設計します。さらに、代替入力の方法と復旧訓練も用意します。
テスト・移行・運用での確認項目
テストから運用まで、一貫して確かめる項目は次のとおりです。受入試験では、気象警報、欠航、機材変更、乗務員交代の場面を想定します。さらに、空域重複、通信途絶、外部APIエラーも扱います。
- 受入試験：想定した例外ごとに、計画、通知、承認、ログ、復旧を確認
- 負荷試験：通常時の同時接続数に加え、通知やイベントの集中状態を再現
- 移行：機体・便・拠点・利用者・過去ログの引継ぎ範囲を決め、旧システムと並行稼働
- 運用：障害の一次対応、24時間監視、規制改定、API仕様変更、権限の見直し、復旧訓練
開発の完了は、リリース日を基準にせず、現場が安全に使える状態で定義します。
▶ 詳細はこちら：運航管理システム開発の進め方
運航管理システムの費用相場とコストの内訳
航空向けには、公開された一律の価格表が少なく、ここで示す金額は確定した定価ではありません。
金額は、類似する運行管理システムの公開情報と、航空特有の工数（リアルタイム連携、安全検証、冗長化、24時間運用）をもとにした、2026年時点の初期開発費の推定です。なお、実際の見積額は、対象範囲と連携数によって大きく変わります。
規模別の初期開発費と期間
規模別の推定額と期間は、機能範囲によって次のとおり異なります。
- 小規模PoC：300万〜800万円、2〜4か月
- 中規模業務システム：800万〜3,000万円、4〜9か月
- 大規模OCC・UTMS：3,000万〜1億円、9〜18か月
- 基盤刷新など：1億〜数億円以上、18〜36か月以上
小規模PoCは、運航情報の参照、気象APIや地図表示、限定ユーザーが対象です。一方で、中規模では、計画やリアルタイム状況の表示、通知と権限の管理、複数APIやモバイル対応を含みます。
大規模では、複数の拠点や部門、機材・乗務員・整備・貨物との連携を含み、再計画や監査も対象になります。基幹移行や24時間運用、冗長化、災害対策、厳格な試験が加わると、さらに高額になる場合があります。また、複数事業者や空域をまたぐ刷新でも、高額になることがあります。
金額は、要件定義、外部連携、テスト、インフラを含めた推定です。概算を比べる際は、機能数だけでなく、機体・便・拠点数、イベント量、可用性、現場訓練の前提をそろえます。
見積を構成する主な費用
見積では、初期開発とランニングの内訳を分けて、費用の抜けがないかを確かめます。
- 初期費用：要件定義・企画、画面設計、業務ロジック、外部API・データ移行、モバイル・エッジ対応、テスト・インフラ・運用設計
- ランニング費用：監視・保守、セキュリティ対応、規制改定、クラウド・バックアップ、地図・気象・通信API、訓練
要件定義と設計は総額の20〜30%、テストは15〜25%程度を予算に置くと、後工程で品質を削りにくくなります。特に、安全に関わる再計画、権限、監査ログは、後から付け足すと影響範囲が広がります。
年間の保守費は、初期開発費の15〜20%を暫定の目安とします。小規模では月額数十万円、大規模では月額数百万円以上になる可能性があります。
見積を比べるときは、初期費用だけでなく、5年TCOや障害時の復旧時間、データの搬出費、契約終了時の引継ぎ費まで含めて見ます。
▶ 詳細はこちら：運航管理システム開発の見積相場・費用
運航管理システムの開発会社・サービスの選び方
相談先を選ぶときは、知名度や営業資料より、自社の対象領域と運用責任に合うかを基準にします。有人機OCC、空港運用、ドローンUTMS、気象・地図の専門モジュールでは、必要な知見がそれぞれ異なります。
発注側は、受託開発、業界パッケージ、クラウドサービス、専門APIを、どう組み合わせるかを開発会社に確かめます。
航空・空域の業務知識の確認
提案の段階では、担当領域と実際の対応経験を確かめます。有人機とドローンでは、確認すべき知識が異なります。
- 有人機：航空安全・SMS、運航規程、気象・NOTAM、重量・重心、乗務員・整備、空港運用
- ドローン：飛行計画、空域共有、USP、DIPS2.0、目視外飛行、有人機との接近リスク
実績の件数だけでなく、担当した役割や、障害・規制変更への対応を質問すると、表面的に似ている案件を見分けやすくなります。
技術と24時間運用の体制
24時間の運用を続けるには、技術の土台に加えて、障害が起きたときの備えや保守の契約、将来の引継ぎまで確かめる必要があります。
- 技術基盤：標準API、イベント処理、時系列データ、モバイル・エッジ、クラウド・認証、監査ログ
- 障害対応：不安定な通信時のキャッシュ・再同期、API停止時の代替経路、通知集中時の性能、バックアップ、災害復旧
- 保守契約：受付時間、一次切り分け、復旧目標、パッチ、規制改定・API変更、バックアップ・訓練支援
- 引継ぎ：ソースコード、設計書、データ形式、アカウント権限、契約終了時の移行方法
デモ画面だけでなく、障害の発生から復旧までの手順を、開発会社に説明してもらいます。
提案の比較基準
候補は、業務から契約終了後まで、一貫した基準で評価します。最安順に並べる前に、必須要件を満たさない提案を除外します。そのうえで、優先度の高い要件をどう実現するかを比べます。
- 評価軸：業務適合性、法令・安全、連携方式、可用性・セキュリティ、導入期間・5年TCO、保守体制・データの出口
- パッケージ：標準業務に合わせられる場合、短期間で導入しやすい
- クラウド：拠点追加や災害対策を設計しやすい傾向
- 拡張・スクラッチ：独自の運航規程や機材構成が競争力に直結する場合に検討
業務を標準化できる範囲と、独自に残す範囲を分けて判断します。
▶ 詳細はこちら：運航管理システム開発でおすすめの開発会社6選と選び方
運航管理システムを発注・外注・委託する方法
発注の成否は、機能名だけでなく、運航上の判断と例外シナリオを伝えられるかで決まります。要件が曖昧な段階では、調査やPoCを小さく委託します。
仕様と受入基準が固まった機能は開発契約に切り替えるなど、工程に合った契約を選びます。
RFPに含めるべき項目
RFPには、運用規模、業務、連携、品質、移行、運用の条件を記載します。ドローンと有人機では、どこまでを誰が受け持つかも明確にします。
- 対象と業務：機体・便・拠点・利用者、平常時と異常時のフロー
- 機能・データ：画面、連携先、項目、更新頻度、想定ユーザー数
- 品質・安全：可用性、RTO・RPO、認証・権限、監査ログ、バックアップ
- 導入・運用：受入試験、移行、教育、保守、SLA
ドローン向けでは、DIPS2.0やUSPとの関係を記載します。一方、有人機向けでは、空港、整備、予約、貨物との境界を示します。
「リアルタイム」「安全」「AIで最適化」といった抽象的な語は、判定できる条件に置き換えます。たとえば、位置情報を何秒以内に画面へ反映するか、接近アラートを何秒以内に通知するかを定めます。
また、通信復旧後に、何分ぶんのデータを再同期するかを決めます。さらに、AIの提案を誰が承認するかも定めます。受入条件を数字で示すと、見積や品質を比べやすくなります。
準委任と請負の使い分け
工程の不確かさや納品条件に応じて、準委任と請負を使い分けます。
- 準委任：業務調査、要件整理、技術検証、PoCなど、成果物や仕様が変わりやすい工程
- 請負：合意した機能を期日・金額を定めて納品し、受入条件で確認する工程
準委任では、変更が出たときに誰が判断するかを契約の段階で決めておきます。請負では、納品物の範囲と検収の基準を、期日や金額と合わせて契約に書きます。どこまでを誰が受け持つかは、この違いに合わせて契約ごとに書き分けます。
規制改定や外部APIの仕様変更に備えて、変更要求の扱いを契約に含めます。そのうえで、追加費用の算定や優先順位、障害時の責任を取り決めます。さらに、第三者サービスの停止、データ所有権、ログ保管、再委託、契約終了時の引継ぎも確認します。
発注側にも、業務責任者と現場代表を置き、意思決定が止まらない体制を用意します。
5年TCOと出口戦略による比較
5年間の総費用と、契約終了時の移行条件を、提案ごとにそろえて比べます。
- 5年TCO：初期開発費、月額利用料、API・クラウド・監視・保守、規制対応、教育・追加拠点、データ移行・障害対応を合算
- 出口条件：標準形式のデータ出力、設計書・API仕様・運用手順の受領、別会社への保守移管、データ消去証明、アカウント引継ぎ・機器返却、移行支援費用
初期提案が安くても、機体数やユーザー数に応じた従量課金が増えることがあります。また、重要な機能が追加オプションになる場合もあります。
出口条件を決めておくと、長期のベンダーロックインを抑えられます。
▶ 詳細はこちら：運航管理システム開発の発注・外注・委託方法
安全・セキュリティと2026年の最新動向
運航管理システムでは、機密性だけでなく、可用性と完全性も安全に直結します。認証を強化しても、障害時に情報を見られなければ、現場の業務は止まってしまいます。
国土交通省の航空分野向け指針は、標的型攻撃やパスワードリスト攻撃などを踏まえた対策を示しています。そのうえで、航空機の運航管理システムも保護の対象に含めています（出典: 国土交通省「航空分野における情報セキュリティ確保に係る安全ガイドライン」、2024年）。
安全設計とサイバーセキュリティ
権限管理や記録、機器保護に加えて、AI利用時の手動復帰まで含めて、安全対策を設計します。
- アクセス制御：利用者・管理者・外部連携先の権限分離、最小権限、多要素認証、端末管理
- 情報保護：通信暗号化、秘密情報保護、脆弱性管理、監査ログ、バックアップ
- 監査：運航判断の変更理由と承認者、ログの改ざん検知、保管期間
- 継続運用：旧式機器のネットワーク分離・監視・代替機・更新計画、AIの手動復帰と停止条件
AIを使う場合は、入力範囲と承認の方法を定めます。そのほか、モデル更新や信頼度、説明の扱いも決めておきます。
AIの精度だけでなく、誤警報の負荷や見逃しの影響、判断の再現性も、テストで確かめます。
AI・気象・空域共有の進展
近年の動きとしては、複数の運航者の間での情報共有と、気象情報を使った乱気流予測が挙げられます。
- UTMS実証：複数運航者の飛行情報共有
- 気象予測：AIによる乱気流予測
2025年のUTMS実証では、飛行計画、フライトステータス、気象・空域情報を共有し、重複する計画や緊急用務空域にも対応しました。
加えて、複数のUSPとの共有や、USPを使わない運航者との共有も検証されています（出典: 2025年5月公表の複数運航者UTMS実証資料）。この検証が示すのは、今後のシステムを一社完結ではなく、標準フォーマットと相互接続で設計する必要性です。
2025年の共同発表では、乱気流予測モデルが日本上空で86%の正答率を示しました（出典: 航空会社・AI事業者共同プレスリリース、2025年8月）。このモデルは、過去10年以上の気象情報と数万件のパイロット報告を使って学習しています。
予測技術は判断支援に組み込めます。ただし、自動操縦や自動承認と同じものとは扱わず、運航担当者が確認する情報として使います。
将来の制度変更に備えた設計
ドローンでは、UTMSやUSP制度、DIPS2.0のAPI整備が進んでいます。また、国土交通省は2026年のUSP制度の案内で、事故防止やDIPS2.0連携に関係する機能を提供する事業者にIDを交付する考え方を示しています（出典: 国土交通省「USP制度」、2026年）。
制度変更に備える設計では、規制対応、API変更、開発範囲を分けて管理します。
- 規制対応：固有処理を業務画面に埋め込まず、連携アダプターと設定で切り替える
- API変更：データ項目に版を持たせ、外部APIの契約・仕様を管理し、変更検知テストを自動化する
- 開発範囲：標準部分は既存サービスを使い、独自性が必要な部分だけ開発する
この分け方によって、制度変更に対応しながら、費用と保守の負担を抑えられます。
運航管理システムに関するよくある質問
導入の前には、有人機とドローンを別々の前提で考え、初期開発費以外の費用も確かめます。AIやクラウドを使う場合は、手動運用と復旧計画も用意します。
運航管理システムは300万円程度で開発できますか？
限定データの表示PoCや周辺機能であれば、300万〜800万円程度が推定の目安です。ただし、複数APIやリアルタイム通知、権限、モバイル、通信断対策、厳格な受入試験まで含めると、中規模以上の費用になります。
全機能をまとめて開発せず、検証したいリスクから段階的に導入すると、予算を管理しやすくなります。
パッケージ・クラウド・スクラッチはどれが良いですか？
標準業務に合わせて短期間で導入したいなら、パッケージやクラウドが候補になります。一方、独自の運航規程や機材構成、空域調整、既存基幹との深い連携が競争力に直結する場合は、拡張開発やスクラッチが候補です。
機能の数で比べるよりも、標準化する業務と独自に残す業務を分けて考えます。そのうえで、5年TCOと契約終了時の移行性も含めて選びます。
AIを導入すれば運航判断を自動化できますか？
AIは、気象予測や遅延の波及分析、機材・乗務員の再配置候補など、判断支援に活用できます。ただし、重要な安全判断を無条件に自動化するものではありません。
入力データの品質や予測の信頼度、承認者の決め方を定めます。あわせて、説明、手動復帰、ログ、モデル更新のルールも決めます。また、AI停止時にも業務を続けられるよう、設計に含めます。
通信断が起きても運航管理システムは使えますか？
通信断の最中に使える範囲は、端末に保持するデータと操作で決まります。そのため、直近の計画や連絡先、地図・空域情報のキャッシュを用意します。さらに、入力の一時保存、復旧後の再同期、競合解決も設計します。
また、通信断を想定した訓練も行います。完全な機能継続を目指すより、安全に停止する機能と、現場で続けられる機能を分けるのが現実的です。
まとめ
運航管理システムは、飛行計画や運航状況、機材、乗務員を結び付けます。さらに、気象、空域、整備、空港などとも結び付けます。そのうえで、平常時と異常時の判断を支えます。
有人機向けOCCとドローン向けUTMSを切り分けたうえで、例外シナリオや法令・安全要件、外部連携、通信断、監査ログを要件定義に含めることが、成功の前提です。
導入判断の3つの要点
パッケージ、クラウド、スクラッチは、機能の数だけで比べず、標準化する範囲と独自性が必要な範囲に分けて考えます。
初期費用だけでなく、5年TCOで比べます。5年TCOには、開発期間・テスト、監視・API・保守の費用を含めます。さらに、規制対応・教育と、契約終了時の移行にかかる費用も合わせて見ます。
AIやリアルタイム連携を導入しても、人による承認と手動復帰は残します。加えて、通信断時の継続と監査ログも確保します。
最初に作るべき資料
最初の資料には、対象と現行業務、安全要件、異常時の判断、判断の承認と連携先を書いておきます。
- 対象範囲：システムの対象と現行業務
- 異常時の対応：台風、大雪、機材故障、乗務員不足、通信断の際に誰が何を確認するか
- 判断と連携：誰が判断を承認し、どの部署へ伝えるか
- 要件：連携先と必須の安全要件
これらを書き出すと、必要な機能と不要な機能を把握できます。
その資料をもとにPoCやRFPを作ると、開発会社やサービスを具体的に比べられます。
▼関連記事一覧
・運航管理システム開発の進め方
・運航管理システム開発でおすすめの開発会社6選と選び方
・運航管理システム開発の見積相場・費用
・運航管理システム開発の発注・外注・委託方法
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。