運航管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

運航管理システム開発は、飛行計画を作る画面だけを開発するのではなく、機体・乗務員・気象・空域・整備などの情報を一つにつなぎ、平常時と異常時の判断を安全に支える業務基盤を段階的に整えることが重要です。

本記事では、有人航空会社のOCC（オペレーション・コントロール・センター）と、ドローン向けUTMS（無人航空機の運航管理システム）を分けて整理し、企画から要件定義、PoC、開発、テスト、運用移行までの進め方を解説します。費用相場、見積もりで確認すべき項目、2026年時点の法制度・AI活用の動向も紹介しますので、開発会社への相談前にご活用ください。

▼全体ガイドの記事
・運航管理システム開発の完全ガイド

運航管理システム開発の全体像

運航管理システムとは、運航に必要な情報を集め、計画、監視、変更、記録を支援するシステム群です。航空会社、空港、ドローン事業者では対象業務と規制が異なるため、最初に利用者と運航対象を切り分けることが成功の前提になります。特に「運行管理システム」と検索して車両・配送向けの情報を参照している場合は、航空分野の「運航」とは要件が異なる点に注意が必要です。

有人航空のOCCは、便、機材、乗務員、燃料、重量・重心、整備、空港、旅客などを横断して、当日の運航を統制する仕組みです。遅延や欠航が起きたときに代替機や乗務員を割り当て、運航規程と安全基準に沿って担当者が判断できることが中心になります。フライトプラン、気象、NOTAM、DCS、AODB、貨物、予約などとの連携も重要です。

一方、UTMSは複数のドローンや有人機が利用する空域で、飛行計画の登録・調整、機体位置の表示、制限空域や気象情報の共有、接近時の通知などを支援します。国土交通省は2026年にUSP制度の案内を公開し、UTMSを無人航空機の運航を管理するシステム、USPをそのサービスを提供する者と整理しています。DIPS2.0との連携も制度上の重要な論点です（出典: 国土交通省「USP制度」、2026年）。

共通する基本機能は、運航計画の作成、リアルタイム状況の把握、アラート通知、権限管理、操作履歴の監査、帳票・分析です。これに加えて有人航空では機材・乗務員・整備・燃料・重量と重心を扱い、ドローンでは飛行経路、機体、操縦者、空域、遠隔識別、飛行許可の情報を扱います。機能数を増やすことより、各データの更新時刻、信頼度、責任者、訂正方法を決めることが大切です。

システム構成は、運航者向けWeb画面、業務API、外部連携層、イベント・時系列データ基盤、通知基盤、監査ログ、認証・権限、バックアップで構成するのが一般的です。通信が不安定な空港現場や遠隔地では、モバイル・エッジ側に必要な情報をキャッシュし、通信復旧後に再同期する設計も必要です。運航判断をAIに丸ごと委ねるのではなく、候補を提示して有資格者が承認し、判断理由と変更履歴を残すHuman-in-the-loopを基本にすると安全性と説明可能性を両立しやすくなります。

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

開発は、対象範囲の確定、現行業務の可視化、要件定義、PoC、設計・実装、テスト、教育・移行、運用改善の順に進めます。各工程を一度きりの納品作業にせず、現場の運航担当者が実際の異常シナリオを確認しながら段階的に合意することが重要です。特に安全・法令要件は、後から追加すると設計とテストのやり直しが大きくなります。

最初に、有人航空のOCC、空港運用、ドローンUTMSのどこを対象にするかを決めます。対象機体数、便数、拠点数、利用者、対応時間、既存システム、法令・社内規程、将来の拡張範囲を一枚のスコープ表にまとめると、開発会社との認識がそろいます。「運航情報を見える化したい」という要望も、誰が、何分以内に、どの情報を見て、どの判断をするのかまで具体化します。

平常時だけでなく、台風や大雪、滑走路閉鎖、機材故障、乗務員不足、空域の重複、通信断、外部API停止を業務フローに入れます。各シナリオについて、検知、判断、承認、通知、再計画、記録、復旧後の再同期までを時系列で整理します。要件は「安全・法令」「業務効率」「分析・AI」の三つに分けると、必須機能と将来機能の優先順位を決めやすくなります。

ドローン事業者の場合は、DIPS2.0との連携、飛行計画の通報、機体・操縦者情報、飛行禁止・制限空域、複数USP間の調整を確認します。国土交通省の案内では、DIPS2.0で機体登録や飛行許可・承認などの手続きが行われるため、自社システムで保持する情報と公的基盤へ送る情報の境界を明確にする必要があります（出典: 国土交通省「無人航空機の飛行許可・承認手続」、2026年）。

要件をすべて固めてから大規模開発へ進むのではなく、技術と業務の不確実性が高い部分を小さなPoCで検証します。気象・地図・飛行情報を同じ画面に表示できるか、アラートが現場の判断に役立つか、通信を切っても最低限の操作を継続できるか、再接続時に重複や欠落なく同期できるかを確認します。実際のデータに近い匿名化データを使い、成功条件を数値で決めるとPoCが単なるデモで終わりません。

標準業務に合わせられる範囲が広ければ、航空業界向けパッケージやクラウドサービスの導入が候補です。独自の運航規程、機材構成、空域調整、既存基幹との連携が競争力に直結するなら、パッケージ拡張やスクラッチ開発を検討します。パッケージは導入を早めやすい一方で業務を標準に寄せる必要があり、スクラッチは自由度が高い一方で法規制や外部仕様の変更を継続的に吸収する負担が生じます。

実装方式は、フライト、機体、乗務員、気象、空域などを標準APIとイベント連携で疎結合にする考え方が適しています。リアルタイム性が必要なイベントと、日次集計でよいデータを分け、外部APIの停止時には最後に取得した情報の時刻と信頼度を画面に示します。クラウドを採用する場合でも、可用性だけでなく、通信断、データ所在、バックアップ、災害時の復旧、契約終了時のデータ搬出まで設計します。

テストは画面の動作確認だけでは不十分です。API連携、時刻のずれ、異常値、重複通知、権限分離、監査ログ、負荷、障害復旧、バックアップ復元、通信断からの再同期を検証します。台風・大雪・欠航・代替機・乗務員交代などのシナリオを使い、運航管理者、整備、空港、乗務員、システム監視担当が同じ状況を見て適切に判断できるかを確認します。

安全に関わるシステムでは、受入基準を「機能が動く」だけでなく、「誰が承認し、何分以内に通知され、手動運用へ戻せるか」と定義します。国土交通省の航空分野における情報セキュリティ確保に係る安全ガイドラインは、2026年4月30日に第7版へ改訂されているため、権限分離、資産管理、監査、インシデント対応、継続的な見直しをRFPと受入試験に含めることが重要です（出典: 国土交通省「航空分野における情報セキュリティ確保に係る安全ガイドライン」、2026年）。

リリースは全拠点同時ではなく、対象便・対象機体・対象拠点を限定した段階導入が安全です。旧システムとの並行稼働期間、手動帳票への切り戻し条件、教育計画、24時間の問い合わせ窓口、障害時の連絡網を準備します。稼働後は、通知件数、再計画に要した時間、手戻り、欠測データ、障害復旧時間、現場の利用率を計測し、次の開発へつなげます。

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

航空向け運航管理システムは、機能や連携先が案件ごとに異なり、ベンダーが価格表を公開している例も限られます。そのため、以下の金額は航空向けの確定価格ではなく、類似する車両向け運行管理システムの公開情報を基礎に、リアルタイム連携、安全設計、外部データ品質管理、24時間運用、試験工数を加味した2026年時点の推定レンジです。最終的な予算は、要件定義とPoCの結果をもとに個別見積もりで確認する必要があります。

運航情報の参照、気象API・地図表示、限定ユーザー、単一事業者に絞った小規模PoCなら、初期開発費は300万〜800万円、期間は2〜4か月が一つの目安です。フライト計画、リアルタイム状況、通知、権限管理、複数API、モバイル対応を含む中規模の業務システムでは、800万〜3,000万円、4〜9か月程度を見込みます。対象が限定されていても、外部連携や通信断対応を含めると下限だけで判断できません。

複数拠点・複数部門で、乗務員、機材、整備、貨物、再計画、監査ログまで連携する大規模OCCやUTMSでは、3,000万〜1億円、9〜18か月程度が推定レンジです。既存基幹の移行、24時間運用、冗長化、災害復旧、複数航空会社や空域との連携、厳格な受入試験まで含む基幹刷新では、1億〜数億円以上、18〜36か月以上になる可能性があります。これらは公開価格ではなく、案件条件によって大きく変動する概算です。

開発期間を短く見積もりすぎると、連携仕様の確認、現場テスト、教育、並行稼働の期間が削られます。特に安全関連の変更では、設計後に追加テストが発生しやすいため、要件定義・基本設計に総額の20〜30%、テストに15〜25%程度を暫定配分し、PoCと予備費を別枠で確保する考え方が現実的です。

初期費用を左右するのは、画面数よりも、機体・便・拠点・利用者の数、連携APIの本数、リアルタイム更新の頻度、再計画ロジック、オフライン対応、可用性、監査ログ、データ移行、現場端末、受入試験の範囲です。たとえば気象と地図を表示するだけの機能と、気象変化を起点に代替案を提示し、承認後に複数の基幹システムへ反映する機能では、データ品質管理、権限、例外処理、テスト工数が大きく異なります。

ランニングコストには、クラウド利用料、気象・地図・航空情報のデータ利用料、通信費、監視・保守、バックアップ、脆弱性対応、規制改定対応、訓練、端末更新が含まれます。暫定的には開発費の15〜20%を年間保守の出発点にできますが、24時間監視、厳しいSLA、複数拠点の冗長化、外部APIの従量課金があると上振れします。小規模でも月額数十万円、大規模な運航基盤では月額数百万円以上になる可能性があります。

見積もりは初期費用だけでなく、5年TCOで比較します。初期開発費、導入・教育費、年間保守、クラウド・データ料金、追加開発、障害対応、データ移行、契約終了時の搬出費を並べ、障害時の復旧目標であるRTOと、どこまでデータを戻すかを示すRPOも確認します。安い初期見積もりが、運用監視や規制対応を除外した結果でないかを見極めることが大切です。

運航管理システムの見積もりを取る際のポイント

運航管理システムの見積もりでは、同じ機能名でも前提条件が違うと金額を比較できません。RFPには現行業務、例外シナリオ、連携先、利用者、可用性、セキュリティ、データ権利、受入基準、保守範囲を記載し、各社に同じ条件で提案してもらいます。要件が曖昧な段階では、いきなり完成形の固定価格を求めず、調査・PoC・要件定義と本開発を分けることも有効です。

RFPには、対象となる航空機・ドローン、便数・飛行数、拠点、利用者の役割、稼働時間、現行システム、移行対象データ、外部連携一覧を含めます。機能要件では、計画作成、状況表示、アラート、再計画、承認、通知、帳票、検索、監査ログを、非機能要件では可用性、性能、拡張性、バックアップ、RTO・RPO、認証、権限、暗号化、ログ保存期間を記載します。

受入基準は、具体的なシナリオと測定値で書きます。「リアルタイムに表示する」ではなく、「機体位置を受信してから画面へ反映するまで平均何秒以内か」「通知の重複率を何パーセント以下にするか」「通信断から復旧した後、何分以内に同期を完了するか」と定義します。異常時には、システムが候補を出せなくても手動運用へ切り替えられることを合格条件に含めます。

会社の知名度や初期価格だけでなく、有人航空のOCC、空港運用、ドローンUTMS、気象AIなど、自社の対象領域に近い経験を確認します。製品導入なのか個別開発なのか、どこまで自社で保守するのか、外部APIやデータの障害時に誰が責任を持つのかも比較対象です。提案時には、平常時の画面だけでなく、台風、機材故障、通信断の復旧デモを依頼すると実力を見極めやすくなります。

2025年5月のNTTデータの発表では、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」「THAI speeds up decision-making processes」、2025年）。ただし、製品導入を選ぶ場合も、既存のDCSや整備・予約系システムとの連携費用とデータ移行費を別途確認する必要があります。

AIは、遅延リスクの予測、気象変化の検知、代替計画の候補生成、問い合わせ対応など、担当者の判断を支援する用途から始めます。入力データの出典・時刻・欠測を表示し、AIの提案を誰が承認したか、採用しなかった理由は何かを記録します。誤った提案が出た場合の手動復帰、モデル更新の承認、性能劣化の監視を要件に含めることが重要です。

AI活用の具体例として、ANAは2025年7月28日からBlueWXが開発した深層学習による乱気流予測システムを正式導入しました。ANAの発表では、過去10年以上に蓄積した数万件のパイロット報告などを学習し、日本上空の予測モデルで86%の正答率を実現したと説明されています（出典: ANAグループ「ANA、世界初『日本発AIスタートアップのBlueWXが開発したAIによる乱気流予測システム』を正式導入」、2025年）。この事例からも、AI単体ではなく、気象データ、現場報告、表示、運航判断をつなぐ業務設計が必要だと分かります。

セキュリティでは、管理者権限の分離、多要素認証、端末・APIの認証、通信と保存データの暗号化、脆弱性管理、監査ログ、バックアップ、インシデント対応、サプライチェーン管理を確認します。「クラウドだから安全」「AIを導入すれば効率化できる」という説明だけで判断せず、リスク評価、監視体制、障害時の責任分界、契約終了時の出口まで提案書と契約書に落とし込みます。

運航管理システム開発でよくある質問

運航管理システムは対象領域によって必要な機能、法令、費用、開発体制が変わります。ここでは、開発を始める前によく寄せられる質問に直接回答します。

単一事業者向けに運航情報の参照、地図・気象表示、限定ユーザー、簡易通知だけを検証する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へ落とし込み、OCC、UTMS、クラウド、気象AIなどの得意領域が異なる候補へ同じ条件で相談します。安全性と現場定着を中心に開発会社を選ぶことが、長期的に使える運航管理基盤につながります。

▼全体ガイドの記事
・運航管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。