運航管理システム開発の発注/外注/依頼/委託方法について

運航管理システムの開発を発注・外注するなら、対象を有人航空機のOCC（運航管理センター）かドローンのUTMS（無人航空機運航管理システム）かに分け、平常時だけでなく遅延・欠航・悪天候・通信断まで要件に含めて段階的に委託することが重要です。

本記事では、運航管理システムをどの発注形態で調達するか、RFPや要件整理に何を書くか、準委任・請負などの契約をどう使い分けるかを解説します。費用相場、委託先の選び方、見積比較のポイントまで、発注前に社内で確認したい実務を順番に整理します。

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

運航管理システムの発注で最初に決める全体像

運航管理システムは、航空会社や空港の業務を支える有人航空機向けの仕組みと、ドローンの飛行計画や空域を扱う仕組みで、発注の前提が大きく異なります。最初に利用者、対象機体、運航区域、24時間運用の有無、連携先を決めると、不要な機能を作り込まずに委託範囲を整理できます。

有人航空機向けでは、OCCの担当者が運航状況を把握し、フライトプラン、機材、乗務員、燃料、重量・重心、気象、NOTAM、整備、貨物、予約・搭乗などの情報をもとに判断します。発注時は「ダッシュボードを作る」とだけ書かず、どの担当者がどの情報を見て、誰が承認し、遅延や欠航のときにどのシステムへ変更を反映するかまで業務フローに落とし込むことが大切です。

たとえば、機材故障が発生したときに代替機を検索し、乗務員の勤務制約と空港の発着枠を確認し、便の変更を関係部署へ通知する流れがあります。画面の見栄えよりも、判断に必要なデータが同じ時刻基準でそろうこと、変更履歴を追跡できること、承認前と承認後の状態を分けられることを受入条件に含めます。

ドローン向けUTMSでは、飛行計画の登録・重複調整、機体位置の表示、地図・3次元地形・気象・飛行禁止区域の重ね合わせ、異常時の通知、複数事業者間の情報共有が中心になります。国土交通省は2026年4月にUSP制度の案内を公開し、UTMSを段階的に導入すると説明しています。USPのサービスはDIPS2.0との連携や、運航中の無人航空機の事故防止に関わるため、単なる地図アプリではなく、制度と運用を含めて発注する必要があります。出典は国土交通省「USP制度」（2026年）です。

NTTデータ、KDDI、トラジェクトリー、Terra Droneは2025年2月、複数のUSP間で飛行計画を調整し、DIPS2.0の外部システムインターフェースを模擬した実証を行いました。重複解消、飛行時間の調整、災害時の緊急用務空域への対応まで検証しているため、UTMSを外注する際の業務シナリオ例として参考になります。出典はNTTデータ「複数運航者間での飛行計画調整によるドローン接近回避の実証」（2025年）です。

対象が有人機でもドローンでも、運航者向けWeb画面、業務API、気象・地図・航空情報との連携層、イベントや時系列データ基盤、権限・監査ログ・通知基盤が必要になります。発注書には、データ更新の許容遅延、障害時のRTO（目標復旧時間）とRPO（目標復旧時点）、ログの保持期間、権限分離、通信断からの再同期方法を明記します。

安全に関わる判断をAIだけに委ねるのではなく、AIや数理最適化は候補を提示し、人が承認して実行するHuman-in-the-loopを基本にします。国土交通省の航空分野における情報セキュリティ確保に係る安全ガイドラインは2026年4月に第7版へ改訂されているため、セキュリティ要件は提案依頼時点の最新版を確認し、開発中の改訂対応を契約範囲に含めます。出典は国土交通省「航空分野における情報セキュリティ確保に係る安全ガイドライン」（2026年）です。

発注形態はパッケージ・クラウド・スクラッチをどう選びますか？

結論として、標準化できる業務はパッケージやクラウドを使い、独自の運航規程・機材構成・空域調整・既存基幹連携が競争力に直結する部分だけを個別開発する組み合わせが現実的です。すべてをスクラッチで作るか、すべてをSaaSに合わせるかの二択にせず、業務の差別化箇所と安全上の必須箇所を分けて委託します。

既存パッケージやクラウドサービスは、運航状況の表示、便・機材・乗務員の管理、通知、権限管理などを短期間で導入しやすい点が利点です。導入時は機能数ではなく、標準APIの有無、気象・地図・航空情報のデータ品質、障害時の代替運用、データのエクスポート、バージョンアップ時の検証責任を確認します。

一方で、パッケージの標準業務に現場を合わせる必要があり、独自の承認手順や例外処理を無理にカスタマイズすると、導入後のアップデート費用が膨らみます。現場の要望をそのまま追加するのではなく、安全・法令上必須の機能、業務効率を高める機能、将来検討する機能の3層に分けて、初期契約の範囲を絞ります。

スクラッチ開発は、既存の航空会社基幹システム、DCS、AODB、整備、貨物、気象、地図、DIPS2.0などとの連携を、自社の業務に合わせて設計できます。既存システムのデータモデルや業務ルールが特殊で、標準パッケージを適用すると二重入力や手作業が増える場合に向いています。

ただし、独自機能を増やすほど、法規制やデータ仕様の変更を自社と委託先が継続して吸収しなければなりません。マイクロサービス、標準API、イベント駆動を適切に使い、フライト・機材・乗務員・気象・空域の境界を分けておくと、将来のベンダー変更や機能追加に対応しやすくなります。

要件が固まっていない段階で大規模な請負契約を結ぶと、途中で仕様変更が増え、費用と納期の調整が難しくなります。最初は2〜4か月程度のPoCとして、気象・地図・飛行情報の統合、アラート、通信断からの再同期、再計画候補の提示など、価値と技術リスクが見えやすいテーマを検証します。

PoCの成果物はデモ画面だけにせず、実データに近いテストデータ、評価指標、未解決課題、量産化時の構成案、概算見積まで含めます。PoCで検証した範囲を本開発の請負仕様へ引き継ぐ場合と、別会社にも提案を求める場合の両方を契約前に決めておくと、発注先を固定しすぎずに済みます。

RFP・要件整理は何をどう書けばよいですか？

RFPは機能一覧だけでなく、発注の背景、対象業務、例外時のシナリオ、連携先、非機能要件、納品物、受入基準、保守範囲まで記載します。特に運航管理システムでは、同じ「リアルタイム」という言葉でも、数秒以内の位置表示なのか、数分以内の業務更新なのかで構成と費用が変わるため、測定可能な条件に言い換えます。

まず、平常時の業務を、運航計画の作成、承認、運航中の監視、変更通知、運航後の記録に分けます。そのうえで、台風・大雪・雷・機材故障・乗務員不足・空港閉鎖・通信断・外部API停止が起きたとき、誰がどの情報を使い、どの順で再計画するかを業務フローにします。

画面一覧を先に作ると、担当者ごとに同じ情報を別々に入力する設計になりやすいです。RFPには利用者の役割、判断、承認、通知、記録を一つの流れで書き、手作業の暫定運用や紙・電話への切り替えまで記載します。これにより、委託先が通常画面だけでなく、止めてはいけない業務の復旧手順を提案できます。

機能要件には、飛行計画の登録・変更・承認、機体・便・乗務員の割当、位置表示、気象・NOTAM・地図情報の取得、アラート、再計画、通知、帳票、監査ログを記載します。各機能に「誰が」「いつ」「何を入力し」「何を出力し」「どの状態へ変わるか」を添えると、見積の前提と受入試験がそろいます。

非機能要件には、可用性、応答時間、同時利用者数、データ保持期間、バックアップ、RTO・RPO、認証・認可、暗号化、監視、脆弱性対応、災害対策、サポート時間を含めます。航空分野の安全ガイドラインを参照し、予約、運航計画、貨物、整備など、障害が遅延や欠航へ波及するシステムとの依存関係も書き出します。

連携一覧には、既存システム名、データ項目、送受信方向、更新頻度、形式、認証方式、障害時の再送、データの正とするシステムを記載します。気象・地図・航空情報・通信は外部事業者の仕様変更や停止が起こり得るため、API利用料、契約主体、仕様変更の通知、代替データ、手動入力への切り替えを発注者と受託者のどちらが担うか決めます。

ドローン案件では、DIPS2.0のAPI利用申請、飛行許可・承認、飛行計画通報、機体登録など、システムの外側にある手続きも確認が必要です。国土交通省は2025年3月にカテゴリーII飛行の審査要領改正に伴うDIPS2.0の変更を案内しているため、法令や接続仕様の改訂を無償で含めるのか、保守契約で対応するのかをRFPと契約書の双方に明記します。出典は国土交通省「ドローン情報基盤システム」（2025年）です。

受入試験には、正常系の操作だけでなく、計画が重複した場合、気象警報が発生した場合、機材が使えなくなった場合、通信が切れた場合、外部APIが応答しない場合を含めます。たとえば「通信断が10分続いても現場画面は最後に取得した情報を表示し、復旧後に重複登録なく再同期できる」のように、入力条件、期待結果、ログ、復旧時間を一つの試験項目にします。

AIを使う場合は、正答率だけで合否を決めません。予測の根拠を担当者が確認できること、信頼度が低い場合に手動運用へ戻れること、学習データの更新履歴を保存できること、誤った提案を承認した場合に原因を追跡できることを受入基準に含めます。

契約形態は準委任・請負・ラボ型をどう使い分けますか？

契約形態は、要件の確定度と成果物の定義で選びます。探索や要件整理は準委任、本番機能の仕様と納期が固まった部分は請負、継続的に改善するチームはラボ型や準委任とするなど、プロジェクトを工程・機能単位で分けると、仕様変更と品質責任の衝突を抑えられます。

準委任は、受託者が専門知識や作業を提供し、発注者と一緒に業務を整理していく契約です。運航規程の整理、現行システム調査、データ連携の検証、PoC、アーキテクチャ設計など、開始時点で正解が一つに決まらない業務に適しています。

ただし、作業時間を確保しただけでは成果が曖昧になりやすいため、週次の成果物、意思決定事項、課題一覧、次工程の判断条件を合意します。準委任だから品質責任がないのではなく、設計レビュー、セキュリティレビュー、デモ、議事録など、確認可能な成果を契約書や個別契約に定義します。

請負は、合意した成果物を完成させ、検査・引渡しを行う契約です。画面、API、帳票、移行、テスト、操作マニュアルなどの納品物と、受入期間、瑕疵への対応、遅延時の扱い、追加開発の単価を明記します。

運航管理システムでは、外部APIの仕様変更や法令改訂、現場で判明する例外処理が起こるため、すべてを固定価格の請負に押し込むと、変更管理が不自然になります。仕様変更の判定方法、変更要求の見積期限、優先順位を決め、発注者が追加費用を判断できる仕組みにしておきます。

ラボ型や月額の準委任は、同じチームがバックログを優先順位付けしながら継続開発する方法です。運航部門の声を聞きながら、通知、分析、運用画面を改善する案件や、発注者側にプロダクトオーナーを置いて内製化を進める案件に向いています。

継続契約では、稼働人数だけでなく、月ごとの成果、品質指標、障害対応時間、ドキュメント整備、担当者交代時の引継ぎを確認します。ソースコード、設計書、テストデータ、監視設定、クラウドアカウント、生成したデータの所有権と、契約終了時の返却・移行支援も契約開始時に決めます。

契約前には、障害の重大度、一次受付の時間、暫定復旧と恒久対応の目標、セキュリティインシデントの報告期限、バックアップと復旧テストの頻度を確認します。クラウド、気象API、地図API、通信回線など第三者サービスが止まった場合に、委託先がどこまで代替策を担うかも責任分界表にします。

また、契約終了時のデータ形式、移行期間、移行費、アカウント返却、ライセンス、第三者コンポーネントの扱いを確認します。初期費用が安くても、データ搬出や別会社への引継ぎができなければ、長期的には発注者の選択肢が狭くなります。

運航管理システム開発の費用相場と見積内訳

航空機向けの運航管理システムは、ベンダーが一律の価格表を公開しているケースが少なく、以下は類似する運行管理システムの公開相場に、航空向けのリアルタイム連携、安全検証、24時間運用、実機・現場テストの工数を加味した推定です。したがって、航空向けの確定価格ではなく、RFP前に予算の幅をつかむための目安として利用します。

運航情報の参照、気象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％程度として仮置きし、運航シナリオと安全性の検証を削らないようにします。本記事の航空向け見積計画上の目安（2026年）です。

特に連携費は、APIの本数だけでなく、データの品質、更新頻度、認証、再送、障害時の代替運用で変わります。機材数、便数、ドローン数、拠点数、利用者数、同時接続数、モバイル端末、位置情報の更新間隔を、見積依頼の入力条件としてそろえます。

ランニング費用は、監視・保守、セキュリティ対応、規制改定、クラウド、バックアップ、気象・地図・通信API、訓練、問い合わせ対応を含めて計算します。暫定的には開発費の15〜20％を年間保守の目安に置き、小規模なら月額数十万円、大規模なら月額数百万円以上もあり得るものとして、契約前に実額を確認します。類似システムの運用費目安を基にした推定（2026年）です。

5年TCOでは、初期開発費、月額利用料、API費、追加開発、監視、障害対応、規制改定、教育、データ移行、契約終了時の搬出費を合算します。初期費用が安い提案ほど、従量課金の条件、最低利用期間、ユーザー追加費、保守時間外の単価、バージョンアップ費が別請求になっていないか確認します。

委託先選定と見積比較では何を確認しますか？

委託先は会社の知名度や見積総額だけで決めず、対象領域、実績の再現性、現場展開、24時間保守、セキュリティ、データ移行、契約終了時の出口を採点します。有人機向けOCCの製品に強い会社、UTMSや通信・空域に強い会社、気象AIなど特定モジュールに強い会社では、得意領域と契約の形が異なるため、必要なら複数社の共同提案も検討します。

有人航空機のOCCを検討するなら、フライト計画、乗務員、機材、整備、貨物、混乱時の復旧を扱った実績と、航空データの標準や現場の承認フローを確認します。ドローンUTMSなら、飛行計画、機体位置、空域、気象、DIPS2.0、USP間の調整に加え、有人機との情報連携を検証した経験を確認します。

相談先の例として、航空会社向けパッケージではLufthansa Systems、国内の大規模連携やUTMS実証ではNTTデータ、通信・現場ネットワークではKDDI、ドローン運航・空域ではTerra Droneやトラジェクトリーが候補になります。AI気象モジュールでは、ANAが2025年7月にBlueWXの乱気流予測システムを正式導入し、日本上空モデルで86％の正答率を公表していますが、AI単体の専門会社と総合SIの役割を分けて提案を受けることが大切です。出典はANAグループ「BlueWXのAI乱気流予測システム正式導入」（2025年）です。

各社へ同じRFPを渡し、初期費用、月額費用、追加開発単価、保守、クラウド、API、移行、教育、テスト、障害対応を分けて提示してもらいます。見積の安さだけでなく、前提条件、対象外、再委託、想定人数、稼働期間、リスク予備費、発注者側の作業を横並びにすると、後から増える費用を見つけやすくなります。

比較表を作る場合は、価格、納期、機能適合、航空・ドローン領域の経験、連携力、セキュリティ、運用体制、提案の透明性、データの持ち出しやすさを評価軸にします。価格に点数を付けすぎると、テストや監視を削った提案が有利になるため、安全性と継続性に最低条件を設定してから総合点を計算します。

提案審査では、きれいなデモ画面より、遅延・欠航、機材故障、乗務員変更、気象警報、計画重複、通信断、外部API停止のシナリオを動かしてもらいます。担当者が手動で介入できるか、承認履歴が残るか、通知が過剰にならないか、復旧後にデータが二重登録されないかを、現場の利用者と一緒に確認します。

PoCを有償で依頼する場合は、評価指標と成果物を先に決めます。たとえば、計画作成時間、重複検知の再現率、アラート到達時間、通信復旧後の再同期、操作ミスの防止、ログの追跡性などを測定し、本開発へ進む条件を数値または合意済みの判定基準にします。

導入後に誰が監視し、誰がマスタを更新し、規制やAPI仕様の変更をどう確認し、障害時に誰が意思決定するかを提案書で確認します。24時間運用の場合は、一次受付、二次対応、開発チーム、クラウド事業者の連絡網とエスカレーションを確認し、運用訓練と切替訓練を本番稼働の前提にします。

さらに、担当者の退職や委託先の変更を想定し、設計書・ソースコード・テスト結果・監視設定・データ辞書を更新可能な状態で受け取れるかを見ます。ベンダーが変わっても運航を継続できることは、見積の金額と同じくらい重要な発注条件です。

よくある質問（FAQ）

運航管理システムの外注では、予算、期間、既存システムとの連携、法規制への対応について質問が多く寄せられます。発注前に判断しやすいよう、特に相談の多い内容へ結論から回答します。

限定ユーザー向けの参照画面や気象・地図APIを使った小規模PoCであれば、300万〜800万円程度の推定レンジに入る可能性があります。ただし、複数拠点、リアルタイム位置、既存基幹連携、24時間監視、厳格な安全テストまで含める場合は、数千万円以上を見込む必要があります。

相談できます。要件が曖昧な場合は、いきなり本開発を請負にせず、準委任で現行業務の整理やPoCを依頼し、成果物と評価指標を確認してから本開発のRFPを作成する進め方が適しています。

どちらか一方が安全とは限りません。パッケージは実績のある標準機能や保守体制を活かしやすく、スクラッチは自社の安全手順や既存連携に合わせやすいため、現場の例外処理、データ品質、障害時の継続運用、更新責任を比較して選びます。

連携方式や利用できる機能は、対象となる手続き、APIの利用申請、最新の接続ガイドラインによって確認が必要です。DIPS2.0の仕様を前提にするだけでなく、API停止時の手動運用、データ再送、仕様改訂への保守対応をRFPに書き、委託先へ実現方法と責任分界を提案してもらいます。

まとめ

運航管理システムの発注・外注では、最初に有人航空機向けOCCとドローン向けUTMSを切り分け、対象機体、拠点、利用者、運航時間、既存連携、規制条件を明確にします。そのうえで、標準化できる部分はパッケージ・クラウド、独自業務や連携は個別開発、判断材料が不足する部分はPoCというように、発注形態を組み合わせます。

RFPには、平常時だけでなく遅延・欠航・悪天候・機材故障・計画重複・通信断・外部API停止のシナリオを含め、機能要件と非機能要件、RTO・RPO、監査ログ、セキュリティ、受入基準を記載します。要件整理やPoCは準委任、本番仕様が固まった機能は請負、継続改善はラボ型など、契約の責任と変更の仕組みを合わせて設計します。

費用は小規模PoCの300万〜800万円から、大規模OCC・UTMSの3,000万〜1億円、基幹刷新の1億〜数億円以上まで幅があります。見積比較では初期費用を下げることだけを目的にせず、保守・監視・API・クラウド・規制改定・教育・データ移行・契約終了時の搬出を含めた5年TCOと、ベンダーが変わっても運航を続けられる出口戦略を確認してください。

まずは自社の運航対象と例外シナリオを一枚に整理し、必要な連携と受入条件をRFPのたたき台にします。候補会社には同じ前提で提案と見積を依頼し、デモやPoCで現場の復旧手順まで確かめることが、運航管理システム開発を安全に発注する近道です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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