空港業務システム開発の見積相場や費用/コスト/値段について

空港業務システムの開発費用は、単一業務なら500万〜1,500万円、単一ターミナルのAODBやスポット管理なら1,500万〜5,000万円、複数部門を統合する場合は5,000万円〜3億円程度が初期費用の目安です。ただし、表示器・ネットワーク・外部連携・データ移行・24時間運用まで含めるかで大きく変動します。

空港業務システムは、空港会社、航空会社、グランドハンドリング会社、管制、設備担当などが同じ運航情報を使うための重要な業務基盤です。本記事では、AODBを中心としたシステムの範囲、費用相場と内訳、価格が変わる要因、見積もりの見方、コストを抑える方法、失敗しやすい注意点まで、2026年時点の情報を踏まえて解説します。

▼全体ガイドの記事
・空港業務システム開発の完全ガイド

空港業務システムの全体像

空港業務システムは、特定の一製品を指す言葉ではなく、運航、旅客、設備、人員、請求、分析などの複数の業務システムを連携させた総称です。費用を考えるときは「画面を何個つくるか」ではなく、どのデータを誰が更新し、どのシステムへ届けるのかを整理することが重要です。

AODBはAirport Operational Databaseの略で、空港運用データベースを意味します。便名、機材、到着・出発予定時刻、実績時刻、ゲート、スポット、チェックインカウンター、手荷物受取場所など、便に関する共有情報を管理する中心的な仕組みです。FIDSが旅客向け表示を行い、RMSがゲートやカウンターなどの資源を割り当てる場合でも、基礎となる便情報が不正確なら、各システムの結果も不正確になります。

たとえば到着予定時刻の更新元が航空会社なのか空港運用室なのかを決めないまま開発すると、AODB、RMS、FIDSに異なる時刻が登録される可能性があります。見積もり前に、イベントごとの正本、更新権限、時刻の基準、再送や重複排除のルールを決めておくと、後工程での連携追加や手戻りを抑えやすくなります。

FIDSはFlight Information Display Systemの略で、搭乗口、遅延、到着、手荷物受取などを表示器やWebへ配信します。RMSはResource Management Systemの略で、スポット、ゲート、カウンター、バゲージベルト、バス、スタッフなどを便の制約に合わせて割り当てます。DCSやチェックインシステムは搭乗手続きと連携し、BHSは手荷物の受付、照合、仕分け、搬送に関する情報を扱います。

A-CDMはAirport Collaborative Decision Makingの略で、空港、航空会社、ハンドラー、管制などがターンアラウンド情報を共有し、出発や資源配分を協調する考え方です。2025年5月、SITAはボゴタのエルドラド国際空港でラテンアメリカ初のA-CDM導入を発表し、航空会社、グランドハンドラー、管制とのリアルタイムなデータ共有を効果として説明しました（出典：SITA「El Dorado becomes first airport in Latin America to implement A-CDM system」、2025年）。このような連携範囲まで含めると、アプリ開発費だけでなく、関係者調整や運用設計の費用も必要になります。

空港業務システムの費用相場はどのくらいですか？

空港業務システムの初期費用は、対象範囲によって500万円程度から数十億円以上まで幅があります。公開された標準価格表はほとんどないため、以下は公開調達の類似案件、システム規模、機器や移行の有無から作成した計画用の推定です。実際の発注では、同じ条件のRFPを複数社へ渡して個別見積もりを取得する必要があります。

FIDSの一部刷新、設備台帳、作業モバイル、勤怠管理など、単一業務を対象に数本の連携を追加する場合は、初期費用500万〜1,500万円が一つの目安です。期間は要件定義から本稼働まで3〜6カ月程度を想定します。パッケージの設定変更を中心にして、端末や表示器、現地の配線工事を別契約にできれば、ソフトウェア側の費用を抑えられる可能性があります。

ただし、単一業務でも既存AODBや航空会社側のシステムと接続する場合は、データ仕様の確認、接続試験、障害時の再送処理が必要です。画面数が少ないから安いとは限らず、外部接続の本数と受入試験の難しさが見積もりを左右します。機器を含める場合は、台数、設置場所、電源、ネットワーク、保守部品の条件も別途確認します。

地方空港や単一ターミナルを対象に、AODB、スポット管理、ゲート割当、FIDSのいずれかを刷新する場合は、1,500万〜5,000万円程度を仮置きします。期間は6〜12カ月程度です。現行システムの調査、航空会社やハンドラーとの調整、過去データの移行、教育、並行稼働を含めると、開発そのものよりも導入作業の割合が大きくなることがあります。

2025年度の国土交通省航空局の入札結果には、空港使用料算定システムの開発業務への人材派遣、クラウドサービス、ソフトウェア保守が別々の案件として掲載されています（出典：国土交通省「令和7年度入札結果」、2025年）。この例からも、空港業務システムは一括の開発費だけでなく、開発要員、クラウド、保守を分けて予算化することが現実的だと分かります。

AODB、FIDS、RMSに加えてDCS、BHS、設備、保安、請求、分析まで連携し、二重化や24時間365日運用を求める場合は、5,000万円〜3億円程度が計画上の目安です。複数ターミナルや複数空港を対象にし、表示器・現地ネットワーク・制御系との接続、段階的な切替まで含めると、3億円〜数十億円以上になることもあります。期間は12〜24カ月、ハブ級では2〜4年以上を見込む場合があります。

気象庁の2025年の落札情報では、東京国際空港の空港気象ドップラーレーダー業務処理ソフトウェアの設定変更と動作試験が1,782万円（税込）で契約されています（出典：気象庁「落札情報 物品役務調達 随意契約 R7 9月分」、2025年）。これはAODBの新規構築価格ではありませんが、既存の空港システムに安全な変更を加え、機器間の動作試験を行うだけでも1,000万円台になる事例です。規模を小さく見積もるときほど、連携と試験の費用を別枠で確認する必要があります。

空港業務システムの費用・コストの内訳

見積書は、ソフトウェア開発費だけを見ると実態より安く見えます。空港業務システムでは、業務設計、連携、データ移行、クラウドやサーバー、表示器や端末、現地作業、試験、教育、保守を分けて確認することが大切です。以下では、初期費用に含めるべき項目を順番に整理します。

要件定義では、空港会社だけでなく航空会社、ハンドラー、保安、設備、旅客案内、請求担当などから業務を聞き取ります。現行システムの一覧、業務フロー、データ項目、更新元、連携方式、端末、契約、障害時の手作業を整理し、RFPや要件定義書に落とします。初期費用全体に占める割合は10〜15%程度を仮置きできますが、関係者が多い案件では割合が高くなる場合があります。

業務設計を省略すると、後から「この例外も必要です」「この担当者も閲覧します」と要件が膨らみます。特に便の遅延、機材変更、ゲート閉鎖、欠航、通信断、臨時便などの例外を確認し、通常時と異常時の処理を同じ資料にまとめることが、追加開発を減らす有効な方法です。

空港業務システムの費用が大きくなりやすいのは、外部連携と現地試験です。AODB、FIDS、RMS、DCS、BHS、設備監視、ネットワーク、航空会社のシステムなどと接続する場合、相手ごとにデータ形式、通信方式、更新頻度、認証、再送、障害通知の仕様が異なります。AIDX、SITA Type B、API、メッセージング、専用回線などから適切な方式を選び、接続先ごとに試験を行います。

移行費用には、旧システムからのデータ抽出、項目の対応付け、不要データの整理、変換、検証、移行リハーサルが含まれます。現地試験では、繁忙時間帯の同時更新、時刻の逆転、重複メッセージ、表示器停止、地下やランプの通信断、外部システム遅延を再現します。これらの項目を見積書で一式とせず、連携本数、移行対象、試験シナリオ、実施回数に分けると、価格差の理由を比較しやすくなります。

クラウドを利用する場合は、環境構築、データベース、バックアップ、監視、ログ保管、ネットワーク接続、冗長化、セキュリティサービスなどの費用が発生します。オンプレミスならサーバー、ラック、電源、空調、バックアップ装置、保守部品を見積もります。クラウドは初期費用を抑えやすい一方、便数、ユーザー数、データ保持期間、メッセージ量、SLAに応じて月額費用が変動します。

FIDSを刷新する場合は、表示器、筐体、設置金具、配線、電源、現地の施工管理、予備機まで対象になる可能性があります。日立が2024年に公表した成田空港向けFIDS案件では、約600台のディスプレイと最大約3.7m×3.5m×3面の大型表示を含む設計・構築・保守が示されています（出典：日立「空港の情報表示基盤『フライトインフォメーションシステム』事業に本格参入、成田国際空港で初採用」、2024年）。画面の枚数だけでなく、筐体や通信設備まで含むと費用構造が変わります。

本稼働前には、管理者研修、現場担当者向けの操作説明、マニュアル作成、問い合わせ窓口、並行稼働、切替当日の立会いが必要です。業務を止められない空港では、夜間や閑散時間帯に切り替えるためのリハーサルと、問題が起きた場合に旧システムへ戻す切戻し計画も費用に含めます。教育や切替を削ると、本稼働後の問い合わせと手作業が増え、結果として運用コストが高くなります。

年間保守は、初期開発費の10〜15%程度を仮置きすることがあります。実際には、24時間365日の監視、障害一次受付の時間帯、オンサイト対応、脆弱性対応、パッチ適用、予備機、SLA、機器保守、クラウド利用料によって変わります。初期費用だけで判断せず、導入後5年間のライセンス、クラウド、保守、改修、機器更新を合算したTCOで比較することが重要です。

空港業務システムの価格が変動する要因

同じ「空港業務システム」でも、空港の規模、連携先、可用性、機器、導入方式によって見積もりは大きく変わります。価格差を単なるベンダーの高低と考えず、何が見積もり条件に含まれているかを確認することが大切です。

便数が多いほど同時更新やピーク時の処理性能が必要になり、ターミナル数が増えるほど、ゲート、スポット、カウンター、バゲージベルト、表示器、ネットワークの管理対象が増えます。地方空港の単一ターミナルなら、まず一つの業務と少数の連携から始められますが、複数ターミナルでは共通のAODBと拠点ごとの運用差を同時に設計する必要があります。

見積依頼時には、年間便数だけでなく、繁忙日の時間当たり便数、対象ターミナル数、ゲートや表示器の台数、利用者数、ピーク時のメッセージ数を伝えます。規模情報が曖昧なまま「大規模対応」と書くと、過剰な構成で高くなるか、逆に性能不足の安い見積もりになる可能性があります。

空港では、数分の停止でも搭乗案内、ゲート割当、手荷物、現場指示に影響する可能性があります。サーバーの二重化、データベースのバックアップ、複数回線、監視、障害通知、RTOとRPO、復旧訓練を求めるほど、初期構築費と年間保守費は高くなります。どの業務を何分以内に復旧させるのかを決めないまま「高可用性」とだけ書くと、提案の比較ができません。

国土交通省は2026年4月30日改訂の「空港分野における情報セキュリティ確保に係る安全ガイドライン第4版」を公開しています（出典：国土交通省「航空及び空港分野における情報セキュリティ確保に係る安全ガイドライン」、2026年）。RFPには、ITと設備・制御系の境界、資産台帳、最小権限、多要素認証、監査ログ、脆弱性対応、バックアップ、インシデント報告、通信断やランサムウェア時の手作業を記載し、セキュリティを追加オプションにしないことが重要です。

パッケージやクラウドの標準機能を使う方式は、既存機能や業界標準の連携を活用でき、開発期間を短くしやすい一方、空港固有の運用を変更する必要があります。スクラッチ開発は独自業務を再現しやすい反面、要件定義、品質保証、標準連携、可用性、保守人材を長期に確保しなければなりません。

現実的には、AODB、FIDS、RMSのコアはパッケージやクラウドを使い、空港固有の請求、設備台帳、作業モバイル、分析画面だけを追加開発するハイブリッド方式が候補になります。標準機能に合わせられない理由を業務上の必須条件と差別化要素に分けると、カスタマイズ費用をコントロールしやすくなります。

空港業務システム開発・導入の進め方

開発を成功させるには、いきなり機能開発を始めず、現行業務とデータの関係を把握してから小さく導入します。空港全体を対象にする場合でも、最初のリリースをAODBとスポット管理、FIDS、作業管理などの業務単位に分け、段階ごとに効果とリスクを確認します。

最初に、システム一覧、業務一覧、データ項目、連携一覧、端末・表示器一覧、ネットワーク、保守契約、手作業のExcelを棚卸しします。次に、便情報の項目ごとに、作成者、更新者、参照者、更新タイミング、正本、障害時の代替方法をデータ辞書へまとめます。現場ごとに異なる呼び方を放置せず、同じ便やゲートを識別するキーを統一することが重要です。

要件は「必須」「標準機能で対応」「設定変更で対応」「追加開発」「業務変更」の5種類に分類します。すべてを追加開発にすると費用と納期が膨らみますが、すべてを業務変更にすると現場で使われません。現場担当者とシステム担当者が、費用、効果、安全性、将来の拡張性を見ながら優先順位を決めることが必要です。

PoCでは、きれいなサンプルデータだけでなく、実際の便ダイヤに近いデータを使います。遅延、欠航、機材変更、ゲート変更、臨時便、重複メッセージ、時刻逆転、外部システムの応答遅延を発生させ、AODBからRMS、FIDS、現場端末まで正しい状態が伝わるかを確認します。デモ環境で正常に動くことより、ランプや搭乗口、保安区域で通信が不安定なときに復旧できることが重要です。

PoCの結果をもとに、画面、API、データ連携、権限、ログ、性能、監視、切戻しを開発します。現場で使う端末が屋外や手袋着用を前提にするなら、入力方法やオフライン時の保存方法も早い段階で確認します。後から現場条件を追加すると、アプリだけでなくネットワークや機器の変更まで必要になるためです。

受入試験は、機能単体の確認だけでは不十分です。AODBの便情報がFIDSに表示され、RMSのゲート割当が現場端末に届き、DCSやBHSとの連携結果が監視画面に残るところまで、一連の業務シナリオで確認します。繁忙日を想定した性能試験、権限試験、バックアップからの復元、障害通知、切戻しリハーサルも受入条件に含めます。

本稼働では、旧システムとの並行稼働期間、読み取り専用にする日時、データ移行の最終時刻、切替責任者、判断基準、手作業に戻す条件を決めます。運用開始後は、24時間の監視、一次受付、ベンダーへのエスカレーション、パッチ、脆弱性、ログ保管、定期訓練を契約に落とします。システムを納品して終わりにせず、業務を継続できる体制まで含めて導入と考えます。

空港業務システムの見積もりを取る際のポイント

正確な相場を把握するには、同じ前提条件で複数社から見積もりを取ることが欠かせません。会社ごとに「開発費」「導入支援費」「機器費」「クラウド費」「保守費」の範囲が違うため、総額だけを比較すると判断を誤ります。

RFPには、空港・ターミナル・ゲート・スポット・表示器の数、便数、利用者数、対象業務、既存システム、連携先、データ保持期間、希望時期、予算帯を記載します。さらに、AODBなどの正本、標準規格、APIやメッセージ方式、権限、監査ログ、SLA、RTO・RPO、障害時の手作業、教育、移行、保守、責任分界も明示します。

「空港業務を効率化したい」のような抽象的な依頼では、提案会社がそれぞれ異なる範囲を想定します。たとえば、FIDSの表示器をソフトウェアだけと考える会社と、筐体・施工・電源まで含める会社では、初期見積もりに大きな差が出ます。含むもの、含まないもの、別途費用になる条件を必ず書面で確認します。

候補会社は、空港や航空業界での実績だけでなく、AODB、FIDS、RMS、A-CDM、DCS、BHSのどこに強いかを確認します。国内の現地対応、日本語の運用体制、24時間SLA、既存機器との接続、標準規格、データ移行、障害時の責任分界、導入後の保守拠点も評価項目です。知名度や営業資料の印象だけでなく、類似案件の受入条件と障害対応の事例を聞くことが重要です。

提案比較では、初期費用、5年TCO、期間、体制、リスク、前提条件を同じ様式に揃えます。最安の提案が、移行や現地試験を含めていないだけの場合もあります。逆に高額な提案が、二重化、予備機、訓練、24時間監視まで含んでいることもあるため、差額の根拠を項目単位で確認します。

契約前には、要件定義後の変更管理、追加開発の単価、接続先の仕様変更、データ移行の不備、機器の納期遅延、現地作業の時間外対応、障害時の責任分界を確認します。最初からすべてを固定価格にするのではなく、概算、要件定義、実装、移行・切替の段階契約に分ける方法もあります。各段階の成果物と中止・見直しの条件を定めると、想定外の膨張を抑えやすくなります。

特に注意したいのは、既存ベンダーしか変更できないインターフェースや、空港固有の仕様が文書化されていない状態です。発注前に接続先の仕様書、テスト環境、サンプルデータ、ログ、保守窓口を確認し、ベンダーロックインを減らすためのデータ出力やAPIの権利も契約に含めます。

空港業務システムのコストを最適化するポイント

コスト最適化は、機能や試験を単純に削ることではありません。将来の手戻り、障害、二重入力、ベンダー依存、使われない機能を減らし、必要な品質へ予算を振り向けることです。特に空港業務では、現場を守るための可用性と切戻しを維持したまま、段階導入で投資を分ける考え方が適しています。

最初からAODB、FIDS、RMS、DCS、BHS、設備、請求、分析を一度に刷新すると、費用だけでなく関係者調整と切替リスクも増えます。まずは便情報の正本と、現場の効果が測定しやすいスポット管理やFIDS、作業管理から始め、次の段階で設備や分析を追加する方法が候補です。段階を分けても、将来連携できるデータモデルとAPIの設計は最初に行います。

段階導入の効果は、投資を分散できることだけではありません。先行リリースで、データの正本、現場の操作性、通信環境、教育の不足、障害時の運用を検証できます。次期開発へ進む条件を、再入力時間、表示誤り、ゲート変更の反映時間、資源稼働率、問い合わせ件数などのKPIで決めると、機能追加の優先順位も明確になります。

空港固有の手順をすべて画面に再現すると、開発費、テストケース、将来の保守費が増えます。業界標準やパッケージの業務を基準にし、例外を本当に安全上・法令上・運用上必要なものへ絞ります。標準機能に合わせることで、導入後のアップデートや担当者交代にも対応しやすくなります。

連携も、個別の専用処理を増やす前に、共通のデータモデル、API、メッセージング、再送・重複排除、認証方式を整理します。AODBを正本にして周辺システムが参照する構成にすれば、同じ便情報を複数画面へ二重入力する仕組みを減らせます。将来のベンダー変更を考え、データを取り出せる形式とログを残すことも、長期的なコスト最適化につながります。

初期費用を下げるために保守や監視を削ると、障害復旧や改修の負担が空港側へ移ることがあります。初期費用、クラウドやライセンス、保守、機器更新、教育、夜間対応、追加開発、データ移行を5年間で合算し、担当者の手作業や二重入力がどれだけ減るかも評価します。金額だけでなく、運用担当者が毎日何分削減できるかを試算すると、方式の比較がしやすくなります。

AIや高度な分析機能も、目的を決めずに追加すると費用だけが増えます。遅延予測、旅客流動、資源配置、設備異常検知など、KPIとデータの準備状況が明確な領域から始めます。まず正しい運航データを蓄積し、現場が使えるダッシュボードを整えたうえで、予測や自動化へ進む順番が安全です。

よくある質問

最後に、空港業務システムの費用や発注について、相談前によく寄せられる質問に回答します。価格だけでなく、導入範囲、期間、運用体制まで確認することがポイントです。

導入できます。空港全体を一度に刷新せず、FIDS、スポット管理、設備台帳、作業管理など、効果を測りやすい単一業務から始める方法が現実的です。初期費用は500万〜1,500万円程度を仮置きできますが、既存システムとの連携、表示器、現地工事、保守を含むかで変わります。

初期費用だけなら、標準機能を使えるクラウドのほうが抑えやすい傾向があります。ただし、月額利用料、データ保持、冗長化、通信、監視、SLA、追加開発を含めた5年TCOで比較する必要があります。空港固有の業務や既存設備との不可分な連携が多い場合は、ハイブリッド方式を含めて検討すると、費用と使いやすさのバランスを取りやすくなります。

単一業務と数本の連携なら3〜6カ月、単一ターミナルのAODBやスポット管理なら6〜12カ月、複数部門の統合なら12〜24カ月程度が計画上の目安です。複数ターミナル、表示器やネットワーク工事、制御系連携、厳格な移行・切替試験を含める場合は、さらに長期化します。要件定義、現地試験、並行稼働、教育を期間から外さないことが重要です。

対象業務、空港・ターミナルの規模、便数、ゲートや表示器の台数、現行システム、連携先、データ項目、希望時期、予算帯、24時間運用の条件を整理します。加えて、障害時に手作業へ戻せるか、旧システムをどの期間残すか、誰がデータを更新するかも準備します。これらを同じ資料で複数社へ渡すと、見積もりの比較精度が上がります。

まとめ

空港業務システムの費用相場は、単一業務で500万〜1,500万円、単一ターミナルのAODBやRMSで1,500万〜5,000万円、AODB・FIDS・RMSなど複数部門の統合で5,000万円〜3億円程度が目安です。複数ターミナルや大規模ハブで、機器、ネットワーク、制御系、24時間運用まで含める場合は、3億円〜数十億円以上になる可能性があります。これらは公開価格ではなく、規模と公開調達から作成する計画用の推定です。

見積書では、要件定義、アプリ開発、外部連携、データ移行、クラウドやサーバー、端末や表示器、現地工事、試験、教育、切替、保守を分けて確認します。価格の安さだけでなく、通信断、停電、外部システム遅延、表示器停止、ランサムウェアなどの障害時に、どの業務をどの方法で継続できるかを比較します。初期費用だけでなく、クラウド、保守、機器更新、追加開発を含む5年TCOで判断することが重要です。

コストを抑えながら失敗を避けるには、AODBを中心にデータの正本と責任分界を決め、標準機能を優先し、必要な業務から段階的に導入します。RFPへ対象範囲、連携、セキュリティ、SLA、移行、教育、BCPを具体的に書き、複数社の提案を同じ条件で比較してください。空港の現場で止まらないことと、導入後に運用し続けられることが、空港業務システム開発の費用対効果を高めます。

▼全体ガイドの記事
・空港業務システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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