空港業務システムの開発は、対象範囲の決定、現行環境の棚卸し、標準機能の確認、実証と現地試験の順に進めます。この順で進めると、予算や納期を増やす要因を早い段階で見つけられます。
全体像から確認したい方は、空港業務システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・空港業務システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
空港業務システムの全体像
空港業務システムは、複数のサブシステムで関係者の情報を連携させ、24時間365日の空港業務を止めずに改善する基盤です。一つの製品の名前ではなく、こうした仕組み全体を指します。
関係者には、空港会社、航空会社、グランドハンドリング会社が含まれます。航空局やテナント、交通事業者なども関係者です。そのため、同じ便の情報を共通の前提で参照できる構造をつくっておく必要があります。
AODBを中心とした情報の正本の決定
AODBはAirport Operational Databaseの略で、空港運用データベースを意味します。便名や運航スケジュールなど、空港内で共有する基本データを管理します。
管理対象には、機材や到着・出発の予定時刻と実績時刻、ゲートやスポットがあります。チェックインカウンターや手荷物搬送、航空会社やハンドラーの情報も対象です。
AODBでは、出発時刻の更新元を航空会社と空港のどちらにするかを、関係者で決めておく必要があります。あわせて、実績時刻を誰が確定し、訂正の履歴をどう残すかも定めます。
周辺システムとは役割を分けて連携させます。個人情報や制御系データをどこまで取り込むかは、機能要件とセキュリティ要件から判断します。
- FIDS：搭乗口、遅延、到着便、手荷物受取などを表示します。
- RMS：ゲート、スポット、カウンター、ベルト、バス、スタッフを割り当てます。
- DCS・チェックイン：搭乗手続と搭乗者情報を連携します。
- BHS：手荷物の受付、照合、仕分け、搬送情報を連携します。
設備点検や保安、勤怠などの業務も、連携の対象になり得ます。請求や広告、混雑分析も、連携の対象として考えられます。
FIDS・RMS・A-CDMそれぞれの役割
役割は、表示、資源配分、関係者の意思決定に分かれます。各システムの連携方式に加えて、更新権限や異常時の訂正方法もそろえる必要があります。
- FIDS：AODBなどのフライト情報を、表示器、Web、アプリ、館内放送へ配信します。
- RMS：限られた空港資源を、便の制約と現場状況に合わせて割り当てる仕組みです。
- A-CDM：Airport Collaborative Decision Makingの略です。
A-CDMでは、空港や航空会社、ハンドラー、管制がターンアラウンドの状況を共有します。そのうえで、出発順序や遅延対応を関係者どうしで協調します。
データ連携の方式には、AIDXやSITA Type B、APIがあります。メッセージングや専用回線などの方式もあります。
NECは2026年時点で、AIDXを含む業界標準フォーマットに対応した空港向けの基盤を案内しています（出典: NEC「空港を見える化するデータマネジメント」、2026年確認）。
情報の食い違いを防ぐには、標準規格を採用するだけでなく、要件の中身も固める必要があります。要件には、イベントの正本や更新権限、時刻同期を盛り込みます。再送や重複排除、異常時の手動訂正も含めます。
これらが曖昧なままだと、ゲートの割当てや表示、請求、現場への指示に、食い違う情報が流れるおそれがあります。
空港業務システムの開発の進め方
空港業務システムの開発では、画面の作り込みだけでなく、便ダイヤや通信環境、他社システムの更新時期まで含めて設計します。表示器や手荷物設備の停止条件も、あわせて設計の対象になります。そのうえで、企画、実証、試験・切替の順に成果物を残していくと、予算や納期を増やす要因を早く見つけられます。
企画と要件定義による対象範囲の絞り込み
発注側は、経営課題と現場課題をKPIに落とし込み、導入前に測れる指標を決めておきます。「空港DXを進める」のような目標のままでは、優先順位を付けるのが難しくなります。
- 運航・設備：遅延時間、スポット稼働率、表示誤りの件数。
- 作業・手荷物：再入力の回数、手荷物の照合漏れ、スタッフの移動時間。
- 会計：請求漏れの件数など。
「便変更が現場画面に反映されるまでの時間を半分にする」のように表すと、必要な連携と受入基準が見えてきます。
業務一覧は、航空会社や空港運用、グランドハンドリングを含めて作ります。設備や保安、情報システム、経理、現行ベンダーも対象です。
現行システムは、システム名や担当部署、データ項目を洗い出します。あわせて、更新元や連携方式、時刻の定義も確認します。端末や回線、保守契約と契約満了日、Excelなどの手作業も、現状を把握しておきます。
この段階では、業務一覧やシステム関連図、連携一覧、データ辞書を作ります。課題一覧とKPI案も残します。
初回リリースを一つの業務単位に絞れば、リスクを抑えられます。候補には、AODBやスポット管理、FIDS、作業管理などがあります。空港全体を対象にする場合でも、初回から全業務を一括で導入する必要はありません。
Fit to StandardとPoCによる例外の見極め
要件は、標準機能で足りるものと空港固有の例外に分けて整理します。業界標準や候補製品の業務フローを基準に、独自ルールが本当に必要かを発注側と開発会社で確かめます。
- 必須：業務に欠かせない要件。
- 標準設定：標準機能の設定での対応。
- 追加開発：標準機能では満たせない要件を開発します。
- 業務変更：過去の手順などを、業務側を変えて対応します。
AODBやFIDS、RMSの標準機能と、固有の請求・設備・現場アプリを同じ基準で作り込むと、後の更新や他空港への展開が難しくなります。
IATAなどの業界標準も参照しながら、空港固有のルールが差別化の要因か、単なる過去の手順かを関係者で見極めます。
技術の選択は、パッケージ・クラウド、ハイブリッド、スクラッチに分けて考えられます。一般には、ハイブリッドを第一候補にします。
- パッケージ・クラウド：標準機能を活用する方式。
- ハイブリッド：AODBやFIDSに標準製品を使い、固有アプリを追加します。
- スクラッチ：独自要件を一から開発する方式。対象は既存資産と不可分の要件や競争力に直結する機能に限ります。
クラウドでは、回線が断たれたときのキャッシュやデータの保持場所、リージョン障害への備えを確認します。SLA、ログ取得、外部メッセージングの料金も確かめます。
候補製品やクラウドを選んだら、実データに近い便ダイヤを使って小規模な実証を行います。通常運航以外の例外も、あわせて試します。
- 便の変更：同じ便に短時間で複数の変更が起きるケースを試します。
- 時刻・メッセージ：到着時刻の逆転や重複メッセージを試します。
- 障害：外部システムの遅延や表示器の一部停止、通信断からの復旧。
デモ室で画面が動くかを見るだけでなく、ランプや搭乗口、地下、屋外など電波条件の悪い場所で作業を完了できるかも確認します。
総合試験・切替・運用の工程
設計と開発の段階で、障害時の動き方と復旧手順も実装します。AODBから各システムへ情報が届く経路ごとに、送受信と復旧時の動きを確認します。
- 連携試験：AODBからFIDS、RMS、DCS、BHSへの送信と受信。
- データ管理：再送、重複排除、時刻同期、権限、監査ログを確認します。
- 現地試験：端末の設置、ネットワークの切替、電源断、予備系への切替。
機器や表示器がある場合は、ソフトウェアの試験に加えて、現地工事も総合試験に含めます。
本番移行の前には、並行稼働と読み取り専用期間を定めます。あわせて、データ移行リハーサルや切戻し条件、手作業で続けるBCPも決めておきます。
AODBの切替後も、FIDSの表示や現場端末への通知、請求データの生成まで確かめなければ、受入完了とはいえません。
運用が始まったら、24時間監視と障害の一次受付を定めます。あわせて、責任分界やパッチ適用、脆弱性対応を契約と手順に落とし込み、ログ保管やRTO・RPO、定期訓練も含めます。
空港業務システムの費用相場とコストの内訳
空港全体のAODB・RMS・FIDS統合には、公開された標準の価格表がありません。そのため、ここに示す金額は、NotebookLMでのリサーチや2025年度の公開調達、大規模業務システムの工数構成をもとにした推定です。
金額は2026年時点の計画用で、見積もりの保証ではありません。機器や表示器、ネットワーク工事、ライセンスを含むかどうかで、金額は変わります。データ移行や保安審査、24時間運用の扱いも、金額を左右します。
スコープ別の初期費用と期間
対象業務と連携数をそろえて見ると、規模ごとの費用と期間を比べられます。各金額は計画時の目安です。
- 単一業務：FIDS、作業モバイル、勤怠、設備台帳などに数本の連携を加える場合、初期費用500万〜1,500万円、3〜6カ月。
- 地方空港または単一ターミナル：AODBまたはスポット・RMS刷新で1,500万〜5,000万円、6〜12カ月。
- 複数部門の統合：AODB・FIDS・RMSにDCSやBHS連携、高可用性を加え、5,000万円〜3億円程度、12〜24カ月。
- 大規模ハブ：複数ターミナル・拠点と設備、保安、旅客流動、制御系を統合する場合、3億円〜数十億円以上、2〜4年以上になることがあります。
単一業務では、パッケージの設定や小規模な追加開発が中心になります。表示器や端末、現地工事は、別に計上されることがあります。
地方空港で外部連携やデータ移行、教育、現地試験が増えると、1,500万〜5,000万円の上限を超える可能性があります。
大規模案件では、機器調達や表示設備、ネットワークに加えて、移行や教育、運用体制も費用に含まれます。そのため、見積もりでは空港の規模以外の前提も記載します。
規模以外の前提では、便数と同時更新数、連携本数を押さえます。関係者数や、停止できない時間帯も含めます。
公開調達の事例の扱い方
公開調達の事例は、契約範囲を読んだうえで、費用を比べる材料として使います。統合システムの価格そのものを示すものではありません。
- 改修費：機能追加では接続試験や現地作業も確認します。
- 契約単位：要員、クラウド、保守が別案件になる例。
- 比較範囲：機能、拠点、機器、クラウド、保守の条件をそろえます。
気象庁は2025年8月、東京国際空港の空港気象ドップラーレーダー業務処理ソフトウェアの設定変更と動作試験を、1,782万円（税込）で契約しました（出典: 気象庁「落札情報 物品役務調達 随意契約 R7」、2025年）。
これはAODBの新規構築の価格ではなく、既存システムの安全な変更と機器間の接続試験でも1,000万円台になる事例です。機能追加を画面数だけで見積もると、接続試験や現地作業の費用が抜けてしまいます。
国土交通省の2025年度入札結果では、空港使用料算定システムの開発要員派遣、クラウドサービス、ソフトウェア保守が、別案件として掲載されています（出典: 国土交通省「令和7年度入札結果」、2026年確認）。
東京国際空港の統合スポット管理システム保守も、別の調達単位です。機能や拠点、機器、クラウド、保守を分けて発注することもあります。
初期費用だけでなく5年TCOでの比較
初期費用は工程ごとに確認し、同じ費用を二重に計上しないようにします。下の構成比は仮置きなので、実際の見積書で範囲を確かめます。
- 要件定義・開発：要件定義・業務設計は10〜15%、アプリ開発・設定は20〜30%。
- 外部連携・データ移行：25〜40%。
- 基盤・ネットワーク：10〜25%。
- 端末・表示器・現地工事：10〜30%。
- 試験・訓練・切替：5〜15%。
年間の保守費は、初期開発費の10〜15%が目安です。クラウド型は初期費用を抑えやすい一方で、月額費用や従量費が発生します。
クラウド費用は、空港数や便数、ユーザー数によって変わります。データ保持期間や冗長化、SLA、外部メッセージングの条件でも変わります。
企画の段階では、初期は1,000万〜5,000万円、年間は500万〜3,000万円程度を仮置きします。これらは公開された定価ではなく、要件から算出した推定値です。
5年間の費用を合算すると、初期見積もりの安さだけで判断せずに済みます。ライセンスやクラウド、保守、機器更新、現地対応、教育も含めて比べます。
見積もりを取る際のポイント
見積もりを取るときは、画面の数より、データの入出力先と障害時の対応を明らかにします。前提条件をそろえたうえで、複数社に依頼します。
各社が異なる範囲で見積もると、金額を比べられません。そのため、RFPに業務範囲や連携条件を記載してください。
RFPに書く業務範囲とデータの正本
RFPには、規模や業務、既存環境、稼働条件を記載します。項目ごとに、正本や更新権限も定めておきます。
- 規模・利用：空港・ターミナル・スポット数、年間便数、繁忙日の同時更新数、対象部門、利用者数。
- 対象範囲：対象機能、既存システム、外部連携先、端末・表示器の台数。
- 運用条件：稼働時間、保守時間、機能要件、可用性や応答時間。
- データ管理：項目別の正本、更新権限、変更履歴、反映期限。
対象データには、便の予定時刻や実績時刻、ゲート、スポット、手荷物の状態があります。データ辞書と連携一覧を用意すると、後工程での追加見積もりを抑えやすくなります。
機能要件には、フライト登録やゲート割当、表示配信を記載します。作業指示や請求データの出力も含めます。
非機能要件では、同時接続数やRTO、RPO、バックアップを記載します。監査ログや権限、通信断時の動作、復旧訓練も盛り込みます。
個人情報や航空会社の機密情報、設備・制御系情報の扱いと、IT/OTの境界も明記します。
価格と実績の同条件での比較
機能の範囲や連携、保守体制、障害対応は、同じ条件で比べます。ソフトウェアだけの提案と、現地工事を含む提案は分けて見ます。
- 対応範囲：AODB、FIDS、RMS、A-CDM、DCS、BHSの対応範囲。
- 連携方式：AIDX、Type B、APIへの接続可否。
- 運用・復旧：24時間SLA、国内保守拠点、二重化、オフライン復旧の実績。
判断では、国内SIの調整力と海外製品の機能数を、両方そろえて見ます。表示器や現地工事を含むかどうかも、比べる前に確かめておきます。
三菱電機は、関西国際空港の事例として、旅客案内情報の一元管理や関連システムへの配信、二重化を公開しています。24時間365日の稼働や数百台規模の表示器も示しています（出典: 三菱電機「関西国際空港株式会社様 旅客案内情報システム」、2026年確認）。
日立は、成田国際空港向けに、約600台の表示器を含むフライトインフォメーションシステムを公表しています（出典: 日立「空港の情報表示基盤」、2024年）。
事例を見るときは、会社名の知名度より、自社の規模との近さや、表示設備、保守、稼働開始までの体制を確認します。
見積もりに含める障害・セキュリティ・責任分界
障害は起きる前提で考え、見積もりの段階から含めます。
- 想定障害：通信断、停電、サーバー障害、外部システム遅延、ランサムウェア。
- 現場・データ障害：表示器の一部停止、誤った時刻情報の配信。
- 対応：検知、切り離し、代替運用、復旧、事後確認。
予備系を用意するだけでなく、誰が切替を判断し、どのデータを正とし、どの時点まで戻すかも定めます。
国土交通省は2026年4月30日、空港分野の情報セキュリティ安全ガイドライン第4版を改訂しました。責任者・権限、資産管理、監査、継続的改善などを示しています（出典: 国土交通省「航空及び空港分野における情報セキュリティ確保に係る安全ガイドライン」、2026年）。
ガイドラインの内容は、法令の条文をそのまま要件にするものではなく、RFPに落とす基準として使えます。資産台帳や最小権限、多要素認証、監査ログは、RFPに書き込む項目の例です。脆弱性・パッチ管理やバックアップ、インシデント報告、復旧訓練も、RFPに落とす項目になります。
空港会社と航空会社、グランドハンドリング会社のほか、既存ベンダーや新しい開発会社の責任分界を、契約に明記します。
一次受付や回線・機器保守、データ訂正については、担当と対応時間を決めます。外部API変更やパッチ、現地駆け付け、教育、契約終了時のデータ返却も、対象に含めます。
責任分界が曖昧な提案は、たとえ最安値でも、稼働後の追加費用や復旧の遅れにつながります。
よくある質問（FAQ）
空港業務システムの最適な形は、導入規模と関係者数によって変わります。ここでは、規模や関係者数に応じて発注の判断に使えるよう回答します。
小規模空港でも空港業務システムを導入できますか？
導入できます。始めるのは、FIDSやスポット管理、設備台帳、作業モバイルなど、効果を測りやすい単一業務からです。
将来AODBと接続できるように、便IDや時刻、ゲート、スポットなどの共通データ項目とAPIの方針を、最初から決めておきます。
クラウドとスクラッチ開発はどちらがよいですか？
標準化しやすいAODBやFIDS、RMSは、クラウドやパッケージを使い、固有アプリは追加開発します。この組み合わせのハイブリッドが第一候補です。
クラウドは初期構築や更新を効率化しやすい一方で、回線断時の継続、データ保管場所、SLA、月額・従量費、外部接続の責任分界を確認します。
スクラッチは独自の運用を再現しやすい反面、航空業界の標準連携や24時間運用を長期保守できる体制が必要です。
空港業務システムの費用と開発期間はどれくらいですか？
単一業務は500万〜1,500万円、3〜6カ月、単一ターミナルのAODBやRMS刷新は1,500万〜5,000万円、6〜12カ月が目安です。
AODB・FIDS・RMSにDCSやBHS連携、高可用性を加えると、5,000万円〜3億円程度、12〜24カ月が一つのレンジです。
機器や表示器、現地工事、移行、教育、保守の範囲で変わります。そのため、見積もりの範囲と5年TCOを比べます。
開発会社には何を伝えて相談すればよいですか？
空港の規模やターミナル数、便数、対象業務を伝えます。既存システムや連携先、表示器・端末の台数、稼働時間も示します。予算帯や希望時期、障害時の代替運用も、あわせて共有します。
仕様書がなくても、業務フロー、再入力や表示遅延、データ項目、保守契約の状況があれば、要件定義を相談できます。
複数社に同じ前提を渡し、概算、要件定義、実装、移行、保守を分けた提案を求めると、比べやすくなります。
まとめ
空港業務システムでは、AODBを中心に、FIDSやRMS、A-CDM、DCS、BHSなどの役割とデータの流れを整理します。
個別の業務を急いで効率化すると、同じ便の情報を複数の画面へ二重に入力する状態になりがちです。そのため、正本や更新権限、連携方式、時刻の定義を先に決めておきます。
段階導入による開発工程
工程は、KPIと範囲の決定、現行環境の棚卸し、Fit to Standard、PoCの順に進めます。そのあとに、障害試験や総合試験、並行稼働、切戻しの設計、運用訓練が続きます。
ランプや搭乗口では、通信断や重複メッセージ、外部システム遅延を試します。AODBの情報が現場の表示や指示まで届くことを、受入基準とします。
発注前のデータ辞書と障害時運用の準備
発注前にデータ辞書を用意し、障害時の代替運用も決めて、RFPに載せておきます。費用は、単一業務の500万〜1,500万円から、大規模ハブの3億円〜数十億円以上まで幅があります。公開調達の1,782万円は、既存設定の変更と試験の事例です。
- 費用比較：外部連携や移行、教育を、同じ条件で比べます。機器や現地工事、保守、クラウドも対象です。
- 長期費用：初期費用だけで決めず、5年TCOで比較します。
- RFPの範囲：業務範囲、データの正本、標準規格、可用性、RTO・RPOの記載。
- RFPの運用：セキュリティ、障害時の継続、移行、教育、保守、責任分界の記載。
国土交通省の2026年改訂ガイドラインも参照しながら、技術と運用を一体で設計します。こうして整理しておくと、製品や開発会社を比べやすくなり、追加費用や現場の混乱も抑えられます。
▼全体ガイドの記事
・空港業務システム開発の完全ガイド
▼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を創業。