運航管理システムの発注は、有人航空機向けのOCCとドローン向けのUTMSを分けて、対象範囲を決めるところから始まります。そのうえで例外業務を整理し、PoCで確かめながら段階的に発注するのが基本の流れです。
発注の前に決めることは、発注形態から委託先の選定まで、流れに沿って並んでいます。
▼全体ガイドの記事
・運航管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
運航管理システムの発注で最初に決める全体像
有人航空機向けは航空会社や空港の業務を、ドローン向けは飛行計画や空域を扱います。両者は対象が異なるため、利用者、対象機体、運航区域、24時間運用の有無、連携先を先に決めておくと、委託する範囲を絞り込めます。
有人航空機向けOCCの業務連携と安全管理
有人航空機向けでは、OCC担当者が複数の情報をもとに運航状況を判断します。
- 判断情報：フライトプラン、機材、乗務員、燃料、重量・重心、気象、NOTAM、整備、貨物、予約・搭乗
- 業務フロー：担当者が見る情報、承認者、遅延・欠航時に変更を反映する先
- 故障時の対応：代替機、乗務員の勤務制約、発着枠の確認と、関係部署への便変更の通知
- 受入条件：時刻基準の統一、変更履歴と承認前後の状態の区別
ドローン向けUTMSの空域共有と計画調整
UTMSでは、飛行計画や機体位置を扱い、事業者どうしで運航情報を共有します。
- 飛行計画：計画の登録と、重複の調整
- 状況把握：機体位置の表示と、異常時の通知
- 空域情報：地図、3次元地形、気象、飛行禁止区域の重ね合わせ
2026年4月、国土交通省はUSP制度とUTMSの段階導入を案内しました（出典：国土交通省「USP制度」、2026年）。USPはDIPS2.0と連携し、無人機の事故防止にもかかわります。そのため、制度や運用も発注の範囲に入れます。
また、NTTデータ、KDDI、トラジェクトリー、Terra Droneは2025年2月に、複数のUSP間で飛行計画を調整する実証を行いました。この実証では、DIPS2.0の外部システムインターフェースを模擬し、重複の解消、飛行時間の調整、災害時の緊急用務空域を検証しました。
出典はNTTデータ「複数運航者間での飛行計画調整によるドローン接近回避の実証」（2025年）です。
共通基盤の評価軸（リアルタイム性・監査性・継続性）
有人機とドローンに共通する基盤は、次の構成と条件を発注書に書いておくと、提案どうしを同じ基準で比べられます。
- システム基盤：Web画面、業務API、気象・地図・航空情報との連携層
- データ・運用基盤：イベント・時系列データ、権限、監査ログ、通知の整備
- 運用条件：更新遅延、ログ保持期間、権限分離、通信断後の再同期
- 復旧目標：RTO（目標復旧時間）とRPO（目標復旧時点）
安全に関わるAIや数理最適化は、候補を示すにとどめ、人が承認してから実行します。
航空分野の情報セキュリティ安全ガイドラインは2026年4月に第7版へ改訂されました（出典：国土交通省「航空分野における情報セキュリティ確保に係る安全ガイドライン」、2026年）。そのため、提案を依頼する時点の最新版を確認し、開発中の改訂への対応も契約範囲に含めます。
発注形態の選び方（パッケージ・クラウド・スクラッチ）
標準業務はパッケージやクラウドで、独自の運航規程や基幹連携は個別開発で対応するのが現実的です。スクラッチかSaaSかを一括で決めるより、差別化の要件と安全上の必須要件を分けて委託するほうが現実に合います。
パッケージ・クラウドで確認する条件
標準業務は短期間で立ち上げやすい一方、導入時には次の条件を確認しておく必要があります。
- 標準機能：運航状況、便・機材・乗務員、通知、権限管理を、そのままの機能で賄えるか
- 連携・運用：標準API、気象・地図・航空情報の品質、障害時の代替策、データ出力
- 更新責任：バージョンアップ時に検証する担当者
- 契約範囲：必須機能、効率化機能、将来機能に分けた、初期契約の絞り込み
独自の承認や例外処理を増やしすぎると、アップデートのたびに費用が膨らむおそれがあります。
スクラッチ開発の連携と変更対応
自社固有の要件に合わせるなら、連携の範囲と変更への対応を先に決めておきます。
- 連携先：航空会社基幹、DCS、AODB、整備、貨物、気象、地図、DIPS2.0との接続設計
- 適する状況：既存データや業務が特殊で、標準品だと二重入力や手作業が増える場合
- 変更対応：独自機能の増加に伴う、法規制やデータ仕様の変更への継続的な対応
- 設計の分割：マイクロサービス、標準API、イベント駆動による業務領域の区切り
業務の境界を分けておくと、ベンダーの変更や機能追加の影響を抑えられます。
PoCと段階導入による発注リスクの軽減
要件が曖昧なまま大規模な請負にすると、仕様変更のたびに費用と納期の調整が難しくなります。そこで、2〜4か月程度のPoCで価値と技術リスクを先に検証します。
- 気象・地図・飛行情報の統合と、アラートの動作
- 通信断からの再同期と、再計画候補の提示
- 評価指標、未解決課題、量産構成案、概算見積の整理
PoCの成果物は、デモ画面に加えて、実データに近いテストデータも含めます。また、検証した範囲を本開発の請負仕様に引き継ぐか、別の会社にも提案を求めるかは、契約前に決めておきます。
RFP・要件整理の書き方
RFPには、現行業務と例外、連携先、受入基準を中心に記し、背景や納品物、保守範囲も含めます。また、「リアルタイム」という言葉は、数秒以内の位置表示なのか、数分以内の業務更新なのかで意味が変わるため、測定できる条件で書きます。
現行業務とイレギュラー対応の時系列整理
RFPは画面の一覧よりも、業務の流れと非常時の切替手順をもとに書き起こします。
- 平常時：運航計画の作成、承認、監視、変更通知、運航後の記録
- 例外時：台風、大雪、雷、機材故障、乗務員不足、空港閉鎖、通信断、API停止時の再計画
- 判断の流れ：担当者、使用する情報、再計画の順序を示した業務フロー
- 切替手順：役割・判断・承認・通知・記録の定めと、紙・電話・手作業による暫定運用
止められない業務の復旧手順は、二重入力が起きない方法も含めて委託先に提案してもらいます。
機能要件と非機能要件の書き分け
機能の要件と運用品質の要件を分けて書くと、見積と受入試験で前提がそろいます。
- 機能：計画の登録・変更・承認、機体・便・乗務員の割当、位置表示
- 情報処理：気象・NOTAM・地図、アラート、再計画、通知、帳票、監査ログ
- 入出力：「誰が」「いつ」「何を入力し」「何を出力し」「どの状態へ変わるか」の記述
- 非機能：可用性、応答時間、同時利用者数、保持期間、バックアップ、RTO・RPO
- 安全・運用：認証・認可、暗号化、監視、脆弱性・災害対策、サポート時間と依存関係
予約や運航計画、貨物、整備との依存関係は、航空分野の安全ガイドラインを参照しながら洗い出します。
連携データと責任分界の明記
外部の仕様が変わったときに対応範囲で迷わないよう、連携の一覧と責任分担をRFPに明記します。
- 連携仕様：システム名、データ項目、送受信方向、更新頻度、形式、認証方式
- 障害対応：再送方法と、データの正とするシステム
- 外部サービス：API利用料、契約主体、変更通知、代替データ、手動切替の担当
- ドローン手続き：DIPS2.0のAPI申請、飛行許可・承認、計画通報、機体登録
気象や地図、航空情報、通信は外部の事業者が提供しており、仕様変更や停止が起こり得ます。たとえば、国土交通省は2025年3月、カテゴリーII飛行の審査要領改正に伴うDIPS2.0の変更を案内しました（出典：国土交通省「ドローン情報基盤システム」、2025年）。
そのため、法令や接続仕様の改訂を無償で対応するか、保守契約で扱うかを、RFPと契約書に記しておきます。
シナリオによる受入基準の定義
受入試験では、通常の操作に加えて、異常時の復旧とAIを使う場合の確認条件も定義します。
- 例外シナリオ：計画重複、気象警報、機材故障、通信断、外部API停止
- 通信復旧：10分の通信断後に最終情報が表示され、重複なく再同期する条件
- 試験項目：入力条件、期待結果、ログ、復旧時間を一つにまとめた項目
- AIの確認：担当者による予測根拠の確認と、低信頼時の手動運用への切替
- 追跡性：学習データの更新履歴と、誤提案を承認した場合の原因の追跡
契約形態の使い分け（準委任・請負・ラボ型）
契約形態は、要件がどこまで確定しているかと、成果物をどう定義できるかで選びます。
たとえば、探索や要件整理は準委任、本番機能は請負、継続改善はラボ型や準委任と、工程ごとに分けられます。工程や機能の単位で分けると、仕様変更と品質責任がぶつかる場面を抑えられます。
準委任の適用場面（要件整理・PoC・伴走支援）
準委任は、受託者が専門知識と作業を提供し、発注者と一緒に業務を整理していく契約です。
- 適する業務：運航規程の整理、現行調査、連携検証、PoC、アーキテクチャ設計
- 成果の確認：週次の成果物、意思決定、課題一覧、次工程に進む判断条件
- 確認可能な成果：設計・セキュリティレビュー、デモ、議事録
準委任は完成責任を負いませんが、専門家としての注意義務は負います。そのため、品質に対する責任は、この注意義務の範囲で残ります。
請負の適用場面（仕様と受入条件が確定した機能）
請負は、合意した成果物を完成させ、検査を経て引き渡す契約です。
- 納品物：画面、API、帳票、移行、テスト、操作マニュアル
- 契約条件：受入期間、瑕疵対応、遅延時の扱い、追加開発の単価
- 変更管理：変更の判定、見積期限、優先順位、追加費用の判断
外部APIの変更や法令の改訂、現場の例外処理があるため、全工程を固定価格で請け負うと変更管理が難しくなります。
ラボ型・ハイブリッドの適用場面（継続改善と内製化）
ラボ型や月額の準委任は、同じチームがバックログの優先順位を付けながら、継続して開発する形です。
- 適する目的：画面の継続改善と、プロダクトオーナーを置く内製化
- 成果管理：月ごとの成果、品質指標、障害対応時間
- 引継ぎ・権利：文書の整備、担当交代、コード・設計書の所有権
- 終了時の扱い：テストデータ、監視設定、クラウド、生成データの権利と移行支援
契約書の確認事項（保守・責任分界・出口）
契約の前に、保守の条件、第三者サービスが止まったときの役割、終了時の引継ぎを確かめておきます。
- 障害対応：重大度、一次受付、暫定復旧と恒久対応それぞれの目標
- 安全管理：事故報告の期限、バックアップ、復旧テストの頻度
- 責任分界：クラウド、気象・地図API、通信停止時の代替策
- 契約終了：データ形式、移行期間と費用、アカウント、ライセンス、第三者部品
データの搬出や他社への引継ぎが難しいと、長く使ううちに発注者の選択肢が狭まります。
運航管理システム開発の費用相場と見積内訳
航空機向けの運航管理システムでは、一律の価格表を公開するベンダーは少数です。そのため、ここで示す金額は、類似する運行管理システムの公開相場に、リアルタイム連携や安全検証、24時間運用、実機・現場テストの工数を加味した推定です。
確定した価格ではなく、RFPの前に予算の幅をつかむ目安として使い、見積で価格を確かめます。
小規模PoCは300万〜800万円、中規模は800万〜3,000万円の目安
開発の規模と連携の範囲が広がるほど、費用と期間は大きくなります。区分ごとの構成と目安を、次に示します。
- 小規模PoC：参照画面、気象API・地図、限定利用者、単一事業者の構成で、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数、品質、頻度、認証、再送、障害時の代替策
- 規模条件：機材・便・ドローン・拠点・利用者・同時接続・端末数、位置更新間隔
費用を抑えたい場合でも、運航シナリオと安全性の検証は削らないようにします。なお、比率は2026年時点の見積計画上の推定です。
初期費用ではなく5年TCOでの判断
5年TCOには、初期の開発費だけでなく、運用から契約終了までの費用を含めます。
- 運用費：監視・保守、セキュリティ、規制改定、クラウド、バックアップ
- 追加費用：気象・地図・通信API、訓練、問い合わせ対応
- 保守目安：開発費の15〜20％を年間の目安とし、小規模は月額数十万円、大規模は月額数百万円以上もあり得る推定
- 5年分：初期費、月額料、API、追加開発、監視、障害、規制改定、教育、移行、搬出の合計
- 契約条件：従量課金、最低期間、追加ユーザー、時間外保守、更新費の別請求
保守費は類似システムをもとにした2026年時点の推定なので、契約前に実額を確かめます。
委託先選定と見積比較の確認事項
委託先を選ぶときは、知名度や総額だけでなく、対象領域の適合と実績の再現性、24時間保守を中心に採点します。そのほか、現場展開とセキュリティも見ます。
データ移行や契約終了時の出口も、同じ基準で採点します。得意領域に応じて、複数社の共同提案も検討します。
委託先の得意領域（航空安全・UTMS・連携）
委託先がどの領域に強いかは、自社の対象領域と、委託先の領域ごとの実績を照らし合わせて確かめます。
- OCC経験：計画、乗務員、機材、整備、貨物、混乱時の復旧、航空データ標準、承認フロー。
- UTMS経験：計画、機体位置、空域、気象、DIPS2.0、USP調整、有人機連携。
- 相談先：Lufthansa Systemsは航空向けパッケージ、NTTデータは国内連携とUTMS実証の経験。
- 相談先：KDDIは通信・現場網、Terra Drone・トラジェクトリーはドローン・空域の分野。
- AI気象：ANAの導入事例も参考になります。
ANAは2025年7月にBlueWXの乱気流予測システムを正式導入しました。さらに、日本上空モデルで正答率86％を公表しています（出典：ANAグループ「BlueWXのAI乱気流予測システム正式導入」、2025年）。
AI専門会社と総合SIには、それぞれの役割を分けて提案してもらいます。
同じ前提・同じ粒度で見る見積比較
見積は、同一のRFPと同じ評価軸にそろえて、費用の前提や安全・継続性を比べます。
- 費用内訳：初期・月額、追加開発、保守、クラウド、API、移行、教育、テスト、障害対応
- 見積前提：対象外、再委託、人数、期間、リスク予備費、発注者側の作業
- 評価軸：価格、納期、機能適合、領域経験、連携力、セキュリティ、運用体制
- 継続性：提案の透明性、データ搬出のしやすさ
価格だけで比べると、テストや監視を削る提案が有利になります。そのため、安全性と継続性には最低条件を設けておきます。
デモやPoCでの例外シナリオの検証
デモやPoCでは、例外シナリオを実際に動かし、現場の利用者と結果を確かめます。
- 試す事象：遅延・欠航、機材故障、乗務員変更、気象警報、計画重複、通信断、API停止
- 操作・復旧：手動介入、承認履歴、通知量、復旧後の二重登録
- 測定指標：計画作成時間、重複検知の再現率、アラート到達時間、再同期
- 進行判定：操作ミス防止とログ追跡性の評価、本開発の条件（数値または合意基準）
有償PoCでは、評価指標と成果物を先に決めておき、画面の見栄えだけで判断しないようにします。
運用移行と契約終了時の評価
運用移行では役割と訓練を、契約終了時には引継ぎ資料を確認します。
- 運用責任：監視、マスタ更新、規制・API変更の確認、障害時の意思決定者
- 24時間体制：一次・二次対応、開発、クラウド事業者との連絡網とエスカレーション
- 稼働前訓練：運用訓練と切替訓練を本番稼働の条件に含める
- 引継ぎ資料：設計書、ソース、テスト結果、監視設定、データ辞書（更新できる状態で受領）
金額だけでなく、ベンダーを変えても運航を続けられることを発注条件に含めます。
よくある質問（FAQ）
外注の相談では、予算、期間、既存連携、法規制についての質問が多く寄せられます。発注前の判断材料として、よくある質問に答えます。
運航管理システムは300万円で発注できますか？
限定ユーザー向けの参照画面と気象・地図APIを使う小規模PoCであれば、300万〜800万円程度の推定レンジに入る可能性があります。
ただし、複数拠点やリアルタイム位置、既存基幹との連携を含む場合は、数千万円以上を見込む必要があります。24時間監視や厳格な安全テストが加わると、さらに増える見込みです。
要件が曖昧でも外注の相談を始められますか？
相談はできます。要件が曖昧な場合は、準委任で業務整理やPoCを依頼し、成果物と評価指標を確かめてから本開発のRFPを作る進め方が適しています。
パッケージとスクラッチ開発はどちらが安全ですか？
どちらが安全かは一概には言えません。パッケージは標準機能や保守体制を活かせる一方、スクラッチは安全手順や既存連携に合わせやすい特徴があります。そのため、例外処理とデータ品質を中心に、継続運用と更新責任も比べて選びます。
ドローンの運航管理システムはDIPS2.0と連携できますか？
連携の方式と利用できる機能は、対象の手続き、API利用申請、最新の接続ガイドラインに沿って決まります。
DIPS2.0の仕様だけでなく、API停止時の手動運用やデータ再送、仕様改訂への対応もRFPに記載します。
委託先には、実現方法と責任分界について提案してもらいます。
まとめ
発注では、有人航空機向けのOCCとドローン向けのUTMSを分けます。そのうえで、対象機体や拠点、利用者、運航時間を明確にします。
既存連携と規制条件を整理したうえで、標準業務はパッケージやクラウド、独自業務は個別開発、未知の部分はPoCで進めます。
RFPと契約で定める安全・品質・変更の条件
RFPには、遅延・欠航、悪天候、機材故障といった例外を含めます。加えて、計画重複や通信断、外部API停止も含めます。
機能要件と非機能要件、RTO・RPOを明記します。監査ログとセキュリティ、受入基準も、RFPに残しておきます。
要件整理やPoCは準委任、確定した機能は請負、継続改善はラボ型のように、業務ごとに責任と変更方法をそろえます。
5年TCOと契約終了時の出口を含めた比較
開発費の幅だけでなく、継続費用や契約終了時の搬出まで含めて見積もります。
- 開発費：小規模PoCは300万〜800万円、大規模OCC・UTMSは3,000万〜1億円が目安です。
- 基幹刷新：1億〜数億円以上の場合があり、航空向け要件を加味した推定です。
- 5年TCO：保守、監視、API、クラウド、規制改定、教育、移行、契約終了時の搬出
- 発注判断：同じ前提の提案の比較と、デモやPoCでの現場の復旧手順の確認
▼全体ガイドの記事
・運航管理システム開発の完全ガイド
▼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を創業。