運航管理システム開発の完全ガイド

運航管理システムとは、飛行計画・機材・乗務員・空域・気象・運航状況を一元管理し、遅延や欠航などの異常時にも安全な再計画を支援する業務基盤です。

ただし、航空会社の運航管理センター（OCC）と、ドローンの空域を管理するUTMSでは、必要な機能も法規制も大きく異なります。本記事では、対象の切り分けから主要機能、開発の進め方、費用相場、開発会社・サービスの選び方、発注時の契約と最新動向まで、導入を検討する担当者が判断に使えるように整理します。

▼関連記事一覧
・運航管理システム開発の進め方
・運航管理システム開発でおすすめの開発会社6選と選び方
・運航管理システム開発の見積相場・費用
・運航管理システム開発の発注・外注・委託方法

運航管理システムとは何ですか？

運航管理システムは、単なる位置情報の表示画面ではありません。計画を作成し、運航中の変化を把握し、関係部署へ情報を伝え、必要に応じて人が承認した再計画を実行するための仕組みです。航空機、ドローン、空港など対象によって呼び方は変わりますが、安全と定時性を両立するために複数のデータを結び付ける点は共通します。

「運行」は一般に鉄道や車両、配送車などを走らせることを指し、「運航」は航空機や船舶などを運用することを指します。航空分野の運航管理システムでは、道路上の車両管理で重視される走行ルートや配車だけでなく、飛行計画、航空情報、気象、重量・重心、燃料、機材整備、乗務員資格などを扱います。検索時に用語を混同しやすいため、提案依頼書にも「有人航空機向け」または「無人航空機向け」と明記することが大切です。

運航は、天候、機材、空港、乗務員、空域などの条件が同時に変わります。各担当者が表計算や電話で別々に管理すると、同じ便の情報が食い違い、判断に時間がかかります。運航管理システムは、変更履歴を残しながら共通の状況を表示し、誰がどの制約を確認して判断したかを追跡できるようにします。結果として、平常時の事務作業だけでなく、台風・大雪・機材故障・通信断といった例外時の復旧力が導入効果を左右します。

運航管理システムの種類と主要機能

最初に、誰が何を運航するシステムなのかを分けて考えます。有人機のOCC、空港の運用管理、ドローンのUTMSは相互に連携する場合がありますが、1つの製品で全てを置き換えるものではありません。既存の予約・搭乗、空港運用、整備、貨物などの基幹システムを活かし、運航判断に必要な情報を連携する設計が現実的です。

有人航空機向けでは、運航管理センターが便ごとの飛行計画、機材割当、乗務員の勤務・資格、燃料、重量・重心（W&B）、気象、NOTAMなどを確認します。運航中は出発・到着時刻、飛行位置、燃料状況、空港側の制約を受け取り、遅延や欠航が発生したときに代替機、乗務員交代、経路変更などの候補を検討します。

ここで重要なのは、AIや最適化エンジンが出した案を、そのまま自動実行しないことです。航空会社の運航規程や承認権限に合わせ、候補、根拠、影響範囲を表示して担当者が承認するHuman-in-the-loopを基本にします。判断結果と入力データを監査ログに残すことで、後から安全性と業務妥当性を検証できます。

ドローン向けのUTMSは、UAS Traffic Management Systemの略称で、複数の無人航空機を安全に運航するための空域管理基盤です。飛行計画の登録・重複調整、機体位置のリアルタイム表示、飛行禁止・制限空域、三次元地形、気象情報、接近アラート、運航記録を扱います。2026年4月に公開された国土交通省のUSP制度の説明では、UTMSは飛行計画や実際の飛行状況、地図・気象情報を関係者間で共有し、空域の安全な利用を支援する仕組みと整理されています（出典: 国土交通省「USP制度」、2026年）。

ドローン情報基盤システム（DIPS2.0）との接続を考える場合は、登録、飛行許可・承認、飛行計画通報のどこまでを自社画面に取り込むかを定義します。国土交通省は2026年6月にDIPS2.0のAPI整備状況を更新しているため、仕様や利用申請の要件を確認し、将来の変更に備えて連携層を分離しておくと保守しやすくなります（出典: 国土交通省「ドローン情報基盤システム」、2026年6月22日更新）。

構成は、運航者・管制担当者向けのWeb画面、業務API、外部連携層、イベント・時系列データ基盤、通知・監査ログ、認証・権限管理に分けると整理しやすくなります。有人機では予約・搭乗、空港運用、整備、貨物、気象、航空情報との連携が中心です。ドローンでは機体テレメトリ、地図・地形、気象、空域、DIPS2.0、複数事業者のUTMS連携が中心になります。

リアルタイム性が必要なデータと、後から集計するデータを同じ処理方式にしないこともポイントです。位置情報や接近アラートはイベント処理で扱い、分析や帳票は蓄積データから作成します。機体や拠点が増えても改修範囲を限定できるよう、標準API、疎結合のサービス、データ辞書、監査用の時刻同期を初期設計に含めます。

運航管理システム開発の進め方

開発は、いきなり画面を作り始めると失敗しやすい領域です。平常時の業務だけでなく、欠航、代替機、乗務員不足、急な空域制限、通信断などの例外を先に洗い出し、安全要件と業務要件を分けて合意します。そのうえで、限定された範囲をPoCで検証し、段階的に本番へ広げます。

まず対象を有人機OCC、空港運用、ドローンUTMSのどれにするか決め、対象機体数、便数、拠点数、利用者、24時間運用の有無、既存システムを明確にします。次に、現場の一日を時系列で描き、誰がどのデータを確認し、どの条件で承認し、どの部署へ通知するかを整理します。

要件は「安全・法令」「業務効率」「分析・AI」の3層に分けると優先順位を付けやすくなります。安全・法令では承認、権限分離、フェイルセーフ、ログ保存、RTO・RPO、可用性を先に決めます。業務効率では画面、通知、再計画、モバイル利用を決め、分析・AIは入力データの品質と人による承認方法が定まってから追加します。

PoCでは、実データに近い気象・位置・計画データを使い、地図上への統合表示、アラートの遅延、再計画候補、権限別の画面、通信断からの再同期を確認します。デモ用のきれいなデータだけで評価すると、欠損、時刻ずれ、重複イベント、外部API停止時の挙動が見えません。正常系と異常系を同じテストシナリオに含めることが重要です。

設計では、データ連携を一枚の図にまとめます。どのシステムが正しい値を持つのか、更新頻度、単位、識別子、失敗時の再送、手動補正の扱いを定義します。クラウドを採用する場合も、通信断や外部サービス停止を前提に、端末側のキャッシュ、再接続時の競合解決、代替入力、復旧訓練を設計します。

受入試験は、画面の操作確認だけでは足りません。気象警報、欠航、機材変更、乗務員交代、空域重複、機体の通信途絶、外部APIのエラーなどをシナリオ化し、計画・通知・承認・ログ・復旧が最後までつながるかを確認します。負荷試験では、通常時の同時接続数だけでなく、異常発生時に通知やイベントが集中する状態を再現します。

移行時は、機体・便・拠点・利用者・過去ログのどこまでを引き継ぐかを決め、旧システムとの並行稼働期間を設けます。運用開始後は、障害の一次対応、24時間監視、規制改定、API仕様変更、権限棚卸し、復旧訓練を継続します。開発完了をリリース日ではなく、現場が安全に使える状態と定義することが大切です。

▶ 詳細はこちら：運航管理システム開発の進め方

運航管理システムの費用相場とコストの内訳

航空向けの運航管理システムは、公開された一律の価格表が少なく、ここで示す金額は航空向けの確定定価ではありません。類似する運行管理システムの公開情報と、航空特有のリアルタイム連携、安全検証、冗長化、24時間運用の工数をもとにした、2026年時点の初期開発費の推定レンジです。実際の見積は対象範囲と連携数によって大きく変わります。

運航情報の参照、気象API・地図表示、限定ユーザーに絞った小規模PoCなら、300万〜800万円、期間は2〜4か月が目安です。フライト計画、リアルタイム状況、通知、権限、複数API、モバイル対応を含む中規模業務システムでは、800万〜3,000万円、4〜9か月程度を見込みます。複数拠点・複数部門、機材・乗務員・整備・貨物連携、再計画、監査を含む大規模OCC・UTMSは、3,000万〜1億円、9〜18か月程度が目安です。

既存基幹の移行、24時間運用、冗長化、災害対策、厳格な試験、複数事業者や空域をまたぐ基盤刷新では、1億〜数億円以上、18〜36か月以上になる場合があります。これらは航空向けの公開定価ではなく、要件定義・外部連携・テスト・インフラを含めた推定です。概算を比較するときは、機能数だけでなく、機体・便・拠点の数、イベント量、可用性、現場訓練まで同じ前提にそろえます。

費用は、要件定義・企画、画面設計、業務ロジック、外部API連携、データ移行、モバイル・エッジ対応、テスト、インフラ構築、運用設計に分けて確認します。要件定義と設計は総額の20〜30%、テストは15〜25%程度を予算として置くと、後工程で品質を削りにくくなります。特に安全に関わる再計画や権限、監査ログは、後付けにすると影響範囲が広がります。

ランニング費用は、監視・保守、セキュリティ対応、規制改定、クラウド、地図・気象・通信API、バックアップ、訓練などで構成されます。初期開発費の15〜20%を年間保守の暫定目安にしつつ、小規模では月額数十万円、大規模では月額数百万円以上になる可能性があります。初期費用だけでなく、5年TCO、障害時の復旧時間、データ搬出費、契約終了時の引継ぎ費を並べて比較します。

▶ 詳細はこちら：運航管理システム開発の見積相場・費用

運航管理システムの開発会社・サービスの選び方

相談先は、知名度や営業資料の印象ではなく、自社の対象領域と運用責任に合うかで選びます。有人機のOCC、空港運用、ドローンUTMS、気象・地図などの専門モジュールでは必要な知見が違うため、総合的な受託開発だけでなく、業界パッケージ、クラウドサービス、専門APIをどう組み合わせるかを確認します。

提案時には、航空安全、SMS、運航規程、気象、NOTAM、重量・重心、乗務員、整備、空港運用など、どの業務を理解しているかを確認します。ドローン向けでは、飛行計画、空域共有、USP、DIPS2.0、目視外飛行、有人機との接近リスクを確認します。実績の件数だけでなく、どの役割を担当し、障害や規制変更にどう対応したかを質問すると、表面的な類似案件を見分けやすくなります。

標準API、イベント処理、時系列データ、モバイル・エッジ、クラウド、認証、監査ログに対応できるかを確認します。通信が不安定な場所でのキャッシュと再同期、外部APIが停止した場合の代替経路、通知が集中した場合の性能、バックアップと災害復旧の実績も重要です。デモ画面だけでなく、障害発生から復旧までの手順を説明してもらいます。

保守契約では、受付時間、一次切り分け、復旧目標、セキュリティパッチ、規制改定、API仕様変更、データバックアップ、訓練支援の範囲を分けて確認します。運用を一社に依存しすぎないよう、ソースコードや設計書、データ形式、アカウント権限、契約終了時の移行方法を明文化すると、長期的なリスクを抑えられます。

候補を比較するときは、業務適合性、法令・安全への対応、連携方式、可用性、セキュリティ、導入期間、5年TCO、保守体制、データの出口を評価項目にします。価格を最安から並べるのではなく、必須要件を満たさない提案を除外し、その後に優先度の高い要件の実現方法を比べます。

パッケージは標準業務に合わせられる場合に導入が速く、クラウドは拠点追加や災害対策を設計しやすい傾向があります。独自の運航規程や機材構成が競争力に直結する場合は、パッケージ拡張やスクラッチ開発を検討します。選択肢の優劣を先に決めず、業務を標準化できる範囲と、独自に残すべき範囲を分けることが判断の出発点です。

▶ 詳細はこちら：運航管理システム開発でおすすめの開発会社6選と選び方

運航管理システムを発注・外注・委託する方法

発注の成否は、RFPに機能名を並べるだけでなく、運航上の判断と例外シナリオを伝えられるかで決まります。要件が曖昧な段階では調査・PoCを小さく委託し、仕様と受入基準が固まった機能は開発契約に切り替えるなど、工程ごとに適した契約を選びます。

RFPには、対象機体・便・拠点・利用者、平常時と異常時の業務フロー、画面一覧、連携システム、データ項目、更新頻度、想定ユーザー数、可用性、RTO・RPO、認証・権限、監査ログ、バックアップ、受入試験、移行範囲、教育、保守、SLAを記載します。ドローン向けならDIPS2.0やUSPとの関係、有人機向けなら空港・整備・予約・貨物との責任分界も明確にします。

「リアルタイム」「安全」「AIで最適化」のような抽象語は、判定できる条件に置き換えます。例えば、位置情報を何秒以内に画面へ反映するか、接近アラートを何秒以内に通知するか、通信復旧後に何分分のデータを再同期するか、AIの提案を誰が承認するかを定義します。受入条件が数字になるほど、見積と品質を比較しやすくなります。

業務調査、要件整理、技術検証、PoCのように成果物や仕様が変わりやすい工程は、専門人材の稼働を確保する準委任が適する場合があります。一方、合意した機能を決めた期日・金額で納品し、受入条件で確認する工程は請負が候補になります。契約形態だけでリスクが決まるのではなく、責任分界、変更手続き、成果物、検収条件を具体化することが必要です。

運航管理では、規制改定や外部APIの仕様変更が起こり得るため、変更要求の扱いを契約に含めます。追加費用の算定方法、優先順位の決め方、障害時の責任、第三者サービスの停止、データの所有権、ログの保管、再委託、契約終了時の引継ぎを確認します。発注側にも、業務責任者と現場代表を置き、意思決定を止めない体制が求められます。

提案を比べるときは、初期開発費、月額利用料、API利用料、クラウド、監視、保守、規制対応、教育、追加拠点、データ移行、障害対応を5年間で合算します。安価な初期提案でも、機体数やユーザー数の増加に応じて従量課金が急増したり、重要な機能が追加オプションになったりするためです。

出口戦略では、データを標準形式で取り出せるか、設計書・API仕様・運用手順を受け取れるか、別の保守会社へ移管できるかを確認します。契約終了時のデータ消去証明、アカウントの引継ぎ、機器返却、移行期間の支援費用まで決めておくと、長期のベンダーロックインを抑えられます。

▶ 詳細はこちら：運航管理システム開発の発注・外注・委託方法

安全・セキュリティと2026年の最新動向

運航管理システムは、機密性だけでなく可用性と完全性が安全に直結します。認証を強化しても、障害時に運航情報が見られなければ現場は止まります。国土交通省の航空分野向け指針は、標的型攻撃やパスワードリスト攻撃などを踏まえた対策を示し、航空機の運航を管理するシステムを保護対象に含めています（出典: 国土交通省「航空分野における情報セキュリティ確保に係る安全ガイドライン」、2024年）。

設計では、利用者・管理者・外部連携先の権限を分離し、最小権限、多要素認証、端末管理、通信暗号化、秘密情報の保護、脆弱性管理、監査ログ、バックアップを組み合わせます。運航判断の変更には理由と承認者を記録し、ログの改ざん検知と保管期間を決めます。パッチ適用が難しい機器や長期利用のソフトウェアがある場合は、ネットワーク分離、監視、代替機、更新計画でリスクを管理します。

安全面では、システムが誤った提案をしたときに、人が手動へ戻せることが重要です。AIによる予測や最適化を導入する場合も、入力データの範囲、モデル更新、信頼度、説明、承認、異常時の停止条件を定義します。AIの精度だけを評価せず、誤警報が現場に与える負荷、見逃し時の影響、判断の再現性までテストします。

2025年には、複数の運航者が同じ空域を使うことを想定し、飛行計画、フライトステータス、気象・空域情報を共有し、重複計画や緊急用務空域に対応するUTMS実証が公表されました。複数のUSPが共存する環境や、USPを使わない運航者との情報共有まで検証されたことは、今後のシステムを一社完結ではなく、標準フォーマットと相互接続で設計する必要性を示しています（出典: 2025年5月公表の複数運航者UTMS実証資料）。

気象分野では、2025年に公表された航空会社・AI事業者の共同発表で、過去10年以上の気象情報と数万件のパイロット報告を学習した乱気流予測モデルが、日本上空で86%の正答率を示した事例があります（出典: 航空会社・AI事業者共同プレスリリース、2025年8月）。このような予測技術は、運航管理システムの判断支援に組み込めますが、予測結果を自動操縦や自動承認と同一視せず、運航担当者が確認できる情報として扱うことが前提です。

ドローンでは、UTMS・USP制度やDIPS2.0のAPI整備が進んでいます。国土交通省は2026年のUSP制度案内で、事故防止やDIPS2.0連携に関係する機能を提供する事業者にIDを交付する考え方を示しています（出典: 国土交通省「USP制度」、2026年）。対象制度が変わる可能性を踏まえ、規制固有の処理を業務画面に埋め込まず、連携アダプターと設定で切り替えられる構造にします。

将来対応のために、データ項目にバージョンを持たせ、外部APIの契約と仕様を管理し、変更を検知するテストを自動化します。標準化が進む部分は既存サービスを活用し、独自性が必要な部分だけを開発することで、費用と保守負担を抑えられます。

運航管理システムに関するよくある質問

ここでは、導入前に特に質問が多いポイントをまとめます。有人機とドローンを同じ前提で考えないこと、費用は初期開発費だけで判断しないこと、AIやクラウドにも手動運用と復旧計画を用意することが共通の答えになります。

限定したデータを表示するPoCや周辺機能であれば、300万〜800万円程度が推定レンジになります。ただし、複数API、リアルタイム通知、権限、モバイル、通信断対策、厳格な受入試験まで含めると、中規模以上の費用になります。最初から全機能を一括開発せず、検証したいリスクを決めて段階導入すると、予算を管理しやすくなります。

標準業務に合わせられ、短期間で導入したいならパッケージやクラウドが候補です。独自の運航規程、機材構成、空域調整、既存基幹との深い連携が競争力に直結するなら、拡張開発やスクラッチが候補になります。判断は製品の機能数ではなく、標準化できる業務と独自に残す業務を分け、5年TCOと契約終了時の移行性まで含めて行います。

AIは気象予測、遅延波及の分析、機材・乗務員の再配置候補など、判断支援に活用できますが、重要な安全判断を無条件に自動化するものではありません。入力データの品質、予測の信頼度、説明、承認者、手動復帰、ログ、モデル更新のルールを定め、異常時にAIを停止しても業務を継続できる設計にします。

通信断時の利用可否は、端末側にどのデータと操作を保持するかで決まります。最低限、直近の計画、必要な連絡先、地図・空域情報のキャッシュ、入力の一時保存、復旧後の再同期、競合解決を設計し、通信断を想定した訓練を行います。完全な機能継続を目指すのではなく、安全に停止する機能と現場で継続する機能を分けることが現実的です。

まとめ

運航管理システムは、飛行計画、運航状況、機材、乗務員、気象、空域、整備、空港などの情報を結び付け、平常時と異常時の判断を支える基盤です。有人機向けOCCとドローン向けUTMSを最初に切り分け、現場の例外シナリオ、法令・安全要件、外部連携、通信断、監査ログを要件定義に含めることが成功の前提になります。

第一に、パッケージ、クラウド、スクラッチを機能数だけで選ばず、標準化できる範囲と独自性が必要な範囲を分けます。第二に、初期費用だけでなく、開発期間、テスト、監視、API、保守、規制対応、教育、契約終了時の移行を含む5年TCOで比較します。第三に、AIやリアルタイム連携を導入しても、人による承認、手動復帰、通信断時の継続、監査ログを残します。

最初の一歩は、対象範囲、現行業務、異常時シナリオ、連携先、必須の安全要件を1枚にまとめることです。特に「台風・大雪・機材故障・乗務員不足・通信断が起きたとき、誰が何を見て、どの判断を承認し、どの部署へ伝えるか」を書き出すと、必要な機能と不要な機能が見えてきます。その資料をもとにPoCやRFPを作成すれば、開発会社・サービスとの比較も具体的になります。

▼関連記事一覧
・運航管理システム開発の進め方
・運航管理システム開発でおすすめの開発会社6選と選び方
・運航管理システム開発の見積相場・費用
・運航管理システム開発の発注・外注・委託方法