運航管理システム開発は、対象業務を決め、異常時の要件を固めたうえで、PoCから段階的に導入へ進めるのが基本の流れです。この進め方をとると、安全な運航判断を支えるシステムにつながります。
全体像については、運航管理システム開発の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・運航管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
運航管理システム開発の全体像
運航管理システムは、運航に必要な情報を集め、計画の立案から監視、変更、記録までを支援するシステム群です。
航空会社、空港、ドローン事業者では、対象とする業務と規制が異なります。そのため、利用者と運航対象を最初に分けておくことが、成功の前提になります。「運行管理システム」で車両や配送向けの情報を探す場合は、航空分野の「運航」と要件が違う点にも注意が必要です。
有人航空のOCCとドローンのUTMSの違い
有人航空のOCC（オペレーション・コントロール・センター）は、便や機材、乗務員などを横断して、当日の運航を統制します。一方、ドローンのUTMSは複数機の飛行計画や機体の位置を追うため、両者では管理する情報が大きく異なります。
- 有人航空：便・機材・乗務員、燃料、重量と重心、整備、空港、旅客
- ドローン：複数機の飛行計画、機体の位置、制限空域、気象情報
遅延や欠航が起きたときは、代替機や乗務員を割り当てます。その対応は、運航規程と安全基準に沿った担当者の判断が中心です。
OCCでは、フライトプランや気象、NOTAMとの連携が欠かせません。さらに、DCSやAODB、貨物、予約などとの連携も重要です。
UTMS（無人航空機の運航管理システム）は、複数のドローンや有人機が利用する空域で、飛行計画の登録・調整や機体位置の表示を支援します。また、制限空域や気象情報の共有、機体接近時の通知も、UTMSの役割に含まれます。
国土交通省は2026年に、USP制度の案内を公開しました。その案内では、UTMSは無人航空機の運航を管理するシステム、USPはサービス提供者と整理されています（出典：国土交通省「USP制度」、2026年）。DIPS2.0との連携も、制度上の重要な論点です。
主な機能とデータ連携
基本機能は、計画作成とリアルタイム状況の把握が中心です。そのほか、アラートや権限管理、監査履歴、帳票・分析があります。
- 有人航空：機材、乗務員、整備、燃料、重量と重心
- ドローン：飛行経路、機体、操縦者、空域、遠隔識別、飛行許可
機能の数を増やすより、データの更新時刻と信頼度、責任者、訂正方法を決めることが大切です。
構成要素には、運航者向けWeb画面や業務API、外部連携層があります。さらに、イベント・時系列基盤、通知基盤、監査ログも含まれます。また、認証・権限とバックアップも構成要素です。
空港や遠隔地で通信が不安定になる場合に備えて、モバイル・エッジ側に情報をキャッシュしておきます。そのうえで、通信が復旧したあとに再同期する設計も必要です。
AIは運航判断を全面的に任せず、候補の提示にとどめて、有資格者が承認する形にします。判断理由と変更履歴を残すHuman-in-the-loopの仕組みが、安全性と説明可能性を支えます。
運航管理システム開発の進め方・流れ
開発では、現場の担当者が異常時のシナリオを確認しながら、工程ごとに段階的な合意を重ねていきます。安全・法令の要件を後から加えると、設計とテストのやり直しが大きくなります。そのため、これらの要件は早い段階で固めておきます。
- 対象範囲を決め、現行業務を一覧にします。
- 要件定義とPoCで、業務と技術の不確実性を確かめます。
- 設計・実装から、テスト、教育・移行まで進めます。
- 運用状況を見ながら、改善を続けます。
企画・要件定義で決める内容
まず発注側が、有人航空のOCC、空港運用、ドローンUTMSのうち、どこを対象にするかを決めます。
- 対象範囲：機体数、便数、拠点数、利用者、対応時間
- 既存要件：システム、法令・社内規程、将来の拡張範囲
- 業務要望：「誰が、何分以内に、何を見て判断するか」まで具体化した要望
対象を1枚のスコープ表にまとめると、発注側と開発会社の認識がそろいます。
業務フローには、台風、大雪、滑走路閉鎖を入れます。さらに、機材故障や乗務員不足、空域重複を加えます。通信断や外部API停止も、同じフローで扱います。
各シナリオでは、検知、判断、承認、通知の流れを時系列で整理します。そのうえで、再計画や記録、復旧後の再同期までつなげます。
要件を「安全・法令」「業務効率」「分析・AI」に分けると、必須機能と将来機能の優先順位を決めやすくなります。
ドローン事業者では、DIPS2.0との連携や飛行計画の通報の扱いを確かめます。機体や操縦者の情報、飛行禁止・制限空域も対象です。
複数USP間の調整も、確認しておく対象です。国土交通省によると、DIPS2.0では機体登録や飛行許可・承認などの手続きを行います（出典：国土交通省「無人航空機の飛行許可・承認手続」、2026年）。自社で保持する情報と、公的基盤へ送る情報の境目も、はっきりさせておきます。
PoCとシステム方式の決め方
不確実性の高い部分は、大規模開発に入る前に、小さなPoCで検証します。
- 表示：気象、地図、飛行情報を同じ画面で扱えるか
- 現場判断：アラートが実務に役立つか
- 通信断：停止中も最低限の操作を続けられるか、復旧後に重複や欠落なく同期できるか
実データに近い匿名化データを使い、成功条件を数値で決めておきます。そうすれば、PoCを単なるデモで終わらせずに済みます。
標準業務に合わせられる範囲が広ければ、航空業界向けパッケージやクラウドサービスが候補になります。独自規程、機材構成、空域調整、基幹連携が競争力に直結する場合は、パッケージ拡張やスクラッチ開発を検討します。
パッケージは導入を早めやすい一方で、業務を標準に寄せる必要があります。スクラッチは自由度が高いものの、法規制や外部仕様の変更を継続的に吸収する負担が生じます。
方式を決める際は、フライトや機体、乗務員、気象、空域などを、標準APIとイベント連携でつなぐ構成にします。そうすれば、互いに影響しにくくなります。
リアルタイム処理が必要なイベントと、日次集計で足りるデータは、分けて扱います。外部API停止時は、取得時刻と信頼度を画面に示します。
クラウドを採用する場合も、通信断やデータの所在、バックアップについて設計します。さらに、災害復旧と契約終了時のデータ搬出も対象です。
テスト・リリース・運用移行での確認事項
運航シナリオを使い、連携や異常時の復旧まで検証します。画面の動作確認は、その一部にとどまります。
- システム試験：API、時刻ずれ、異常値、重複通知、権限
- 継続性：監査ログ、負荷、障害復旧、バックアップ復元
- 再同期：通信断からの復帰後のデータ
試験では、台風や大雪のような天候の場面に加えて、欠航や代替機、乗務員交代も想定します。
運航管理者や整備、空港、乗務員、システム監視担当が、同じ状況を見て適切に判断できるかを確かめます。
受入基準では、承認者や通知までの時間を定め、手動運用に切り替えられるかどうかも決めておきます。
国土交通省の航空分野向け情報セキュリティ安全ガイドラインは、2026年4月30日に第7版へ改訂されました（出典：国土交通省「航空分野における情報セキュリティ確保に係る安全ガイドライン」、2026年）。権限分離や資産管理、監査、インシデント対応、継続的な見直しは、RFPと受入試験に含めます。
導入は、全拠点を一斉に切り替えるのではなく、対象の便・機体・拠点を限定して段階的に進めます。そのうえで、旧システムとの並行稼働や、手動帳票への切り戻し条件も準備します。また、教育計画や24時間の問い合わせ窓口、障害時の連絡網も用意します。
稼働後は、通知件数や再計画時間、手戻り、欠測データを計測します。さらに、復旧時間や利用率も測り、その結果を次の開発につなげます。
運航管理システムの費用相場とコストの内訳
航空向けの運航管理システムは、案件ごとに機能や連携先が違い、価格表を公開しているベンダーも限られます。そのため、ここで示すのは確定価格ではなく、類似する車両向け運行管理システムの公開情報をもとにした、2026年時点の推定レンジです。
推定には、リアルタイム連携や安全設計、外部データの品質管理、24時間運用、試験工数を加味しています。最終予算は、要件定義とPoCの結果をもとに、個別見積もりで確認します。
規模別の初期開発費と期間の目安
小規模PoCの目安は、単一事業者が運航情報を参照する用途です。
- 小規模PoC：300万〜800万円、期間は2〜4か月
- 中規模業務システム：800万〜3,000万円、期間は4〜9か月
- 大規模OCC・UTMS：3,000万〜1億円、期間は9〜18か月
- 基幹刷新：1億〜数億円以上、期間は18〜36か月以上
小規模PoCは、気象APIや地図表示を限定ユーザーで使う範囲が対象です。中規模では、計画やリアルタイム状況の表示、通知、権限のほか、複数APIとモバイル対応を含みます。
大規模では、複数拠点・部門に加えて、乗務員や機材、整備と連携します。さらに、貨物、再計画、監査ログまで連携範囲に入ります。
基幹刷新では、既存システムの移行や24時間運用、冗長化を含みます。そこに災害復旧や複数社・空域連携、厳格な試験まで加わると、上記の期間と費用になり得ます。
いずれも公開価格ではなく、案件条件によって変わる概算です。対象が小さくても、外部連携や通信断への対応があれば、費用の下限だけで判断するのは難しくなります。
連携仕様の確認や現場テスト、教育、並行稼働を削ると、期間は短く見えますが、その分のリスクを見落とすことになります。
安全関連の変更では、設計後に追加試験が生じやすいため、要件定義・基本設計に総額の20〜30%、テストに15〜25%程度を暫定的に配分します。PoCと予備費は、この配分とは別枠で確保するのが現実的です。
費用を左右する項目とランニングコスト
初期費用は、画面数よりも、対象数や連携範囲、運用条件によって変わります。
- 対象と連携：機体・便・拠点・利用者の数、API本数
- 処理と運用：更新頻度、再計画、オフライン対応、可用性
- 品質と移行：監査、データ移行、端末、受入試験の範囲
気象・地図表示だけの場合と、気象変化から代替案を出して複数の基幹に反映する場合では、必要な品質管理や試験が異なります。
運用費には、クラウドや気象・地図・航空情報、通信の費用が含まれます。さらに、監視・保守、バックアップ、脆弱性対応も含まれます。
規制改定への対応、訓練、端末の更新も、ランニングコストに入ります。年間保守は、開発費の15〜20%を暫定の目安として考えられます。
24時間監視や厳しいSLA、複数拠点の冗長化、外部APIの従量課金があると、費用は上振れします。金額で見ると、小規模でも月額数十万円、大規模な運航基盤では月額数百万円以上になる可能性があります。
比較は、初期費用だけでなく5年TCO（総所有コスト）で行います。その際は、初期開発、導入・教育、年間保守、クラウド・データ料金を並べます。そのうえで、追加開発や障害対応、移行、契約終了時の搬出費も加えます。
障害時の復旧目標であるRTOと、復元するデータ範囲を示すRPOも確認します。監視や規制対応が、初期見積もりから抜けていないかを見極めます。
運航管理システムの見積もりを取る際のポイント
同じ機能名でも前提条件が違うと、見積額は比べにくくなります。そこでRFPには、現行業務や例外シナリオ、連携先、利用者、可用性を書きます。さらに、セキュリティやデータ権利、受入基準、保守範囲も記載します。
同じ条件で、各社に提案を依頼します。一方、要件が曖昧な段階では、完成形の固定価格をすぐに求めず、調査・PoC・要件定義と本開発を分けて依頼する方法もあります。
RFPと要件一覧に含める項目
RFPは、対象や業務、連携、機能、非機能を分けて示します。
- 対象情報：機体、便・飛行数、拠点、役割、稼働時間
- 現状と移行：既存システム、移行データ、外部連携
- 機能要件：計画、表示、通知、承認、帳票・検索・監査
- 非機能要件：可用性、性能、拡張、復旧、認証・暗号化、保存期間
バックアップやRTO・RPOも、非機能要件に含めておきます。そうすれば、各社の見積もりの前提をそろえられます。
受入基準は、具体的なシナリオと測定値で決めます。「リアルタイム表示」とだけ書いても、合否は判定できません。そのため、機体位置の受信から表示までの平均時間や通知の重複率、通信復旧後の同期時間を測定対象にします。
異常時にシステムが候補を出せなくても、手動運用に切り替えられることを、合格条件に含めます。
開発会社・ベンダーの比較基準
知名度や初期価格だけでなく、自社の対象領域に近い経験を見ます。
- 領域経験：OCC、空港運用、UTMS、気象AIなどの経験
- 提供・保守：製品か個別開発か、保守範囲はどこまでか
- 障害責任：外部APIやデータ障害時の責任者
提案時には、平常時だけでなく、台風や機材故障、通信断からの復旧を示すデモも依頼します。
NTTデータは2025年5月、KDDI、トラジェクトリー、Terra Droneと実証を発表しました。福島ロボットテストフィールドでは、複数USP間の計画調整とDIPS2.0の外部インターフェースが模擬されました。
2025年2月19日から20日の実証では、複数運航者間で飛行・気象・空域情報の共有を検証しました。さらに、計画調整によるドローン接近回避にも成功しました（出典：NTTデータ「ドローン運航管理システム（UTMS）を活用した複数運航者間での飛行計画調整によるドローン接近回避の実証に成功」、2025年）。
実証の経験は、UTMS案件を比べる際の材料になります。ただし、自社の運航条件に適用できるかは、別途確認が必要です。
Lufthansa SystemsはOCC向けに、運航、ロード、ハブ、クルー、フライトプランニングの製品群を提供しています。NetLine/Ops ++では、リアルタイム分析や異常時の意思決定支援を掲げています。同社は2025年9月、Thai Airwaysが計画領域から運航領域へNetLine製品群の利用を拡張した事例を紹介しました。
出典は、Lufthansa Systems「Operations Control Center」（2025年）です。同社の「THAI speeds up decision-making processes」（2025年）も出典です。
製品を導入する場合も、既存DCSや整備・予約系との連携費、データ移行費を確かめます。
AIとセキュリティのリスク評価
AIは、まず担当者の判断を支援する用途から使い始めます。そのためには、提案内容と承認者を追跡できる設計が必要です。
- 予測・検知：遅延リスクや気象変化の予測と検知
- 計画支援：代替計画の候補づくり
- 問い合わせ：問い合わせ対応の支援
入力データの出典や時刻、欠測を示し、提案を誰が承認したかを記録します。加えて、不採用の理由や手動復帰、モデル更新の承認、性能劣化の監視も要件に含めます。
ANAは2025年7月28日、BlueWXが開発した深層学習による乱気流予測システムを正式導入しました。ANAによると、過去10年以上に蓄積した数万件のパイロット報告などを学習し、日本上空のモデルで正答率86%を実現しました。
出典はANAグループ「ANA、世界初『日本発AIスタートアップのBlueWXが開発したAIによる乱気流予測システム』を正式導入」（2025年）です。この事例のようにAIを活かすには、気象データや現場報告、表示と運航判断をつなぐ業務設計が必要です。
管理者権限や多要素認証、端末とAPIの認証、暗号化を確かめます。脆弱性管理や監査ログ、バックアップ、インシデント対応、サプライチェーン管理も対象になります。
リスク評価や監視、障害時にどこまでを誰が受け持つか、契約終了時の出口を、提案書と契約書に記載します。
運航管理システム開発でよくある質問
対象領域によって、必要な機能や法令、費用、開発体制は変わります。開発前によく寄せられる疑問に、答えていきます。
運航管理システムは300万円程度で開発できますか？
限定的なPoCであれば、300万〜800万円程度が目安です。対象は、単一事業者の情報参照や地図・気象表示、限定ユーザー、簡易通知です。
フライト計画の自動生成や複数システム連携、機材や乗務員を最適に割り振る機能、24時間監視、厳格な受入試験まで含むと、数千万円以上になる可能性があります。
300万円で何を実現するかは、機能と受入条件を限定して決めることが欠かせません。
パッケージ・クラウド・スクラッチ開発はどれを選ぶべきですか？
標準的な運航業務が多く、短期導入や業界向けの機能を優先する場合は、パッケージやクラウドが候補になります。
独自の運航規程や機材構成、空域調整、社内基幹との連携が競争力に直結するなら、パッケージ拡張やスクラッチ開発が適しています。
迷う場合は、PoCで差別化につながる要件と標準化できる要件を分けたうえで、段階導入の方式を比べます。
通信断が起きても運航管理システムは使えますか？
必要な情報を端末や拠点側にキャッシュしておけば、参照や手動記録を続けられる可能性があります。
保存するのは、計画や連絡先、最低限の地図・制限情報です。通信断中は最新性を保証できない情報もあるため、その情報には取得時刻と「要確認」を示します。復旧後は、変更の競合や重複登録、順序の逆転を解消し、同期結果を監査ログに残します。
開発期間はどのくらいかかりますか？
期間は規模と対象範囲によって変わります。見積もりでは、要件定義から教育、切り戻し計画までを含めて考えます。
- 限定したPoC：2〜4か月の推定目安
- 中規模の業務システム：4〜9か月の推定目安
- 大規模なOCC・UTMS：9〜18か月程度の推定目安
- 基幹刷新：18〜36か月以上になる場合があります
データ移行や複数拠点の並行稼働、冗長化、安全試験を含む基幹刷新は、期間が長くなります。また、外部仕様の確定や現場の受入試験、教育、切り戻し計画も工程に含めます。
運航管理システム開発の進め方・やり方・流れのまとめ
開発の成否は、画面数よりも、対象業務と例外を切り分けて、現場判断を安全に支えられるかで決まります。有人航空のOCCとドローンUTMSを分けたうえで、機体や拠点、利用者、規制、既存システムをはっきりさせます。
状況の一覧と通知から始め、計画や連携、最適化、AIへと段階的に広げるのが現実的です。
最初に取り組む対象範囲と異常シナリオの整理
開発会社に相談する前に、平常時と異常時の対応を書き出しておきます。
- 異常シナリオ：遅延、欠航、悪天候、機材故障、乗務員不足、空域重複、通信断、API停止
- 要件の区分：安全・法令、標準業務、将来のAI機能
この整理によって、PoCの範囲と本開発の優先順位がはっきりします。見積もりは、初期費用だけでなく、保守やデータ利用、監視、規制改定、教育、契約終了時の出口まで含めた5年TCOで比べます。
次の一歩はPoCとRFPの準備
PoCの検証から発注先の選定までは、次の順で進めます。
- 大規模なスクラッチ開発を今すぐ発注せず、担当者が困るシナリオを一つ選びます。
- 気象、地図、機体、便などをつないだPoCで、価値とリスクを確かめます。
- PoCの成果を、機能・非機能要件や受入基準、障害時の手動運用、保守範囲に反映して、RFPを作ります。
- OCC、UTMS、クラウド、気象AIなど、得意領域の異なる候補に、同じ条件で相談します。
- 安全性と現場への定着を重視して開発会社を選び、長く使える運航管理基盤につなげます。
▼全体ガイドの記事
・運航管理システム開発の完全ガイド
▼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を創業。