空港業務システム開発の進め方/やり方/流れや方法/手法/工程/手順

空港業務システムは、AODBを中心に運航・旅客・設備・人員の情報をつなぎ、24時間365日の空港業務を止めずに改善するための業務基盤です。

ただし、空港全体のシステムを一度に作り直せばよいわけではありません。現場のデータがどこで更新されるのか、通信断や停電時にどう業務を続けるのか、既存の航空会社・手荷物・表示器・設備システムとどう接続するのかを先に決め、段階的に開発することが重要です。本記事では、空港業務システムの全体像から進め方、費用相場、見積もりの確認項目まで、発注前に整理すべき内容を解説します。

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

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

空港業務システムは、特定の一製品を指す言葉ではありません。空港会社、航空会社、グランドハンドリング会社、航空局、テナント、交通事業者などが扱う情報を、複数のサブシステムで連携させる総称です。開発では個別機能の多さよりも、同じ便の情報を関係者が同じ前提で参照できる構造を優先します。

AODBはAirport Operational Databaseの略で、空港運用データベースを意味します。便名、運航スケジュール、機材、到着・出発予定時刻と実績時刻、ゲート、スポット、チェックインカウンター、手荷物搬送、航空会社やハンドラーの情報などを管理し、空港内の共通データを作ります。ここで重要なのは、データを一か所に集めることだけではありません。たとえば出発時刻の更新元を航空会社と空港のどちらにするのか、実績時刻の確定者は誰か、訂正の履歴をどう残すのかまで定義する必要があります。

周辺システムには、搭乗口や遅延、到着便、手荷物受取を表示するFIDS、ゲートやスポット、カウンター、ベルト、バス、スタッフを割り当てるRMSがあります。DCSやチェックインシステムとは搭乗手続・搭乗者情報を連携し、BHSとは手荷物の受付・照合・仕分け・搬送情報を連携します。設備点検、保安、勤怠、請求、広告、混雑分析なども対象になりますが、旅客の個人情報や制御系のデータをどこまで業務基盤に取り込むかは、機能要件とセキュリティ要件を分けて判断します。

FIDSは、AODBなどから受け取ったフライト情報を表示器、Web、アプリ、館内放送などへ配信する仕組みです。RMSは限られたゲートやスポット、カウンター、バゲージベルトなどの資源を、便の制約と現場の状況に合わせて割り当てます。A-CDMはAirport Collaborative Decision Makingの略で、空港、航空会社、ハンドラー、管制などがターンアラウンドの状況を共有し、出発順序や遅延対応を協調する考え方です。似た用語でも、表示、資源配分、関係者間の意思決定という目的が異なります。

データ連携では、AIDX、SITA Type B、API、メッセージング、専用回線などを候補にします。NECは2026年時点の公開情報で、AIDXを含む業界標準フォーマットに対応する空港向けデータ連携基盤を案内しています（出典: NEC「空港を見える化するデータマネジメント」、2026年確認）。ただし標準規格を採用するだけでは不十分です。イベントの正本、更新権限、時刻同期、再送、重複排除、異常時の手動訂正を要件にしなければ、ゲート割当・表示・請求・現場指示に異なる情報が流れてしまいます。

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

空港業務システムの開発は、要件を聞いて画面を作るだけでは完了しません。便ダイヤ、現場の通信環境、他社システムの更新タイミング、表示器や手荷物設備の停止条件まで含めた業務設計が必要です。次の三段階で、成果物を残しながら進めると、予算と納期の増加要因を早く見つけられます。

最初に、解決したい経営課題と現場課題をKPIに置きます。遅延時間、スポット稼働率、表示誤り件数、手作業の再入力回数、手荷物照合漏れ、スタッフの移動時間、請求漏れなど、導入前に測れる指標を決めます。「空港DXを進める」だけでは優先順位を付けられませんが、「便変更が現場画面に反映されるまでの時間を半分にする」のように表せば、必要な連携と受入基準が見えてきます。

次に、航空会社、空港運用、グランドハンドリング、設備、保安、情報システム、経理、現行ベンダーなどを含む業務一覧を作ります。システム名、担当部署、データ項目、更新元、連携方式、時刻の定義、端末、回線、保守契約、契約満了日、Excelなどの手作業を棚卸しします。成果物は業務一覧、システム関連図、連携一覧、データ辞書、課題一覧、KPI案です。空港全体を対象にしても、最初のリリースはAODBとスポット管理、FIDS、作業管理など一つの業務単位に絞ると、リスクを制御しやすくなります。

要件は「必須」「標準設定で対応」「追加開発」「業務を変えて対応」に分類します。AODBやFIDS、RMSの標準機能と、空港固有の請求・設備・現場アプリを同じ基準で作り込むと、将来のアップデートや他空港への展開が難しくなります。IATAなどの業界標準や候補製品の業務フローを基準に、空港固有のルールが本当に差別化要因なのか、単なる過去の手順なのかを関係者で確認します。

候補製品やクラウドを選んだら、実データに近い便ダイヤで小さな実証を行います。通常運航だけでなく、同じ便に複数の変更が短時間で発生するケース、到着時刻が逆転するケース、重複メッセージ、外部システムの遅延、表示器の一部停止、通信断からの復旧を試します。デモ室で画面が動くことより、ランプ、搭乗口、地下、屋外など電波条件の悪い場所で、現場担当者が作業を完了できることを確認する方が重要です。

設計・開発では、画面やAPIだけでなく、障害モードと復旧手順を実装します。AODBからFIDS、RMS、DCS、BHSへ情報が届く経路ごとに、送信、受信、再送、重複排除、時刻同期、権限、監査ログをテストします。機器や表示器が関係する場合は、ソフトウェア試験だけでなく、現地工事、端末設置、ネットワーク切替、電源断、予備系への切替までを総合試験に含めます。

本番移行は、並行稼働、読み取り専用期間、データ移行リハーサル、切戻し条件、手作業で業務を続けるBCPを定めてから実施します。AODBの切替が成功しても、FIDSの表示、現場端末への通知、請求データの生成まで確認できなければ受入完了とはいえません。運用開始後は、24時間監視、障害一次受付、空港会社・航空会社・ベンダーの責任分界、パッチ適用、脆弱性対応、ログ保管、RTOとRPO、定期訓練を契約と運用手順に落とします。

技術選択は、標準機能を使うパッケージ・クラウド、AODBやFIDSは標準製品で固有の請求・設備・現場アプリを追加するハイブリッド、独自要件を一から作るスクラッチの三つに整理できます。一般にはハイブリッドを第一候補にし、スクラッチは既存資産と不可分の要件や、空港の競争力に直結する機能に限定します。クラウドを選ぶ場合も、回線断時のキャッシュ、データ保持場所、リージョン障害、SLA、ログ取得、外部メッセージングの料金を確認する必要があります。

空港業務システムの費用相場とコストの内訳

空港全体の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年以上になることがあります。スクラッチ開発だけでなく、機器調達、表示設備、ネットワーク、移行、教育、運用体制が含まれるためです。空港の規模だけでなく、便数、同時更新数、ステークホルダー数、連携本数、停止できない時間帯を前提条件として明記してください。

気象庁の2025年8月契約では、東京国際空港の空港気象ドップラーレーダー業務処理ソフトウェア設定変更と動作試験が、契約金額1,782万円（税込）でした（出典: 気象庁「落札情報 物品役務調達 随意契約 R7」、2025年）。これはAODBの新規構築価格ではありませんが、既存の空港システムを安全に変更し、機器間の相互接続を試験するだけでも1,000万円台になる公開事例です。機能追加の費用をソフトウェアの画面数だけで見積もると、接続試験と現地作業の費用を見落とします。

国土交通省の2025年度入札結果にも、空港使用料算定システムの開発要員派遣、クラウドサービス、ソフトウェア保守が別案件として掲載されています（出典: 国土交通省「令和7年度入札結果」、2026年確認）。東京国際空港の統合スポット管理システム保守なども別の調達単位です。このように、空港業務システムは一括の定額商品ではなく、機能・拠点・機器・クラウド・保守を分けて発注することが多いと理解してください。

費用の内訳は、要件定義・業務設計、アプリ開発または設定、外部連携・データ移行、クラウド・サーバー・二重化・ネットワーク、端末・表示器・現地工事、総合試験・訓練・切替に分けて確認します。目安として、要件定義・業務設計10〜15%、アプリ開発・設定20〜30%、外部連携・データ移行25〜40%、基盤・ネットワーク10〜25%、端末・表示器・現地工事10〜30%、試験・訓練・切替5〜15%程度の構成を仮置きできますが、重複計上を避けるため、実際の見積書で範囲を確認してください。

年間保守は初期開発費の10〜15%を目安に置きます。クラウド型は初期費用を抑えやすい一方、空港数、便数、ユーザー数、データ保持期間、冗長化、SLA、外部メッセージングに応じて月額費用や従量費が発生します。初期1,000万〜5,000万円、年間500万〜3,000万円程度を企画時の仮置きとし、5年間のライセンス、クラウド、保守、機器更新、現地対応、教育を合算して比較すると、安い初期見積もりに引っ張られにくくなります。これらのレンジは公開定価ではなく、要件から算出するための推定値です。

見積もりを取る際のポイント

空港業務システムの見積もりでは、「画面を何個作るか」よりも、データをどこから受け、どこへ送り、止まったときに誰が何をするかを明らかにします。提案依頼書に前提条件がないと、各社が違う範囲で見積もるため、金額の比較ができません。次の観点をそろえてから複数社へ依頼してください。

RFPには、空港・ターミナル・スポット数、年間便数、繁忙日の同時更新数、対象部門、対象機能、既存システム、外部連携先、端末や表示器の台数、利用者数、稼働時間、保守時間を記載します。特に、便の予定時刻、実績時刻、ゲート、スポット、手荷物状態などの項目ごとに、正本となるシステム、更新権限、変更履歴、反映期限を決めます。データ辞書と連携一覧があるだけで、後工程の追加見積もりを抑えやすくなります。

機能要件と非機能要件も分けます。機能要件にはフライト登録、ゲート割当、表示配信、作業指示、請求データ出力などを記載し、非機能要件には可用性、応答時間、同時接続数、RTO、RPO、バックアップ、監査ログ、権限、通信断時の動作、復旧訓練を記載します。個人情報、航空会社の機密情報、設備や制御系の情報を扱う範囲と、IT/OTの境界もRFPで明確にします。

提案を比較するときは、国内SIの調整力だけ、海外製品の機能数だけという見方を避けます。AODB、FIDS、RMS、A-CDM、DCS、BHSのどこまで対応できるか、AIDXやType B、APIに接続できるか、24時間SLAと国内の保守拠点があるか、二重化やオフライン復旧に実績があるかを確認します。表示器や現地工事を含む提案とソフトウェアだけの提案は、同じ金額でも比較できません。

公開事例も、会社名の知名度ではなく自社の課題に置き換えて確認します。三菱電機は関西国際空港の旅客案内情報システムで、フライト情報の一元管理、関連システムへの配信、二重化、24時間365日稼働、数百台規模の表示器を公開しています（出典: 三菱電機「関西国際空港株式会社様 旅客案内情報システム」、2026年確認）。日立は成田国際空港向けに約600台の表示器を含むフライトインフォメーションシステムを公表しています（出典: 日立「空港の情報表示基盤」、2024年）。このような事例から、規模、表示設備、保守、稼働開始までの体制を質問します。

空港では、障害が起きない前提の見積もりは現実的ではありません。通信断、停電、サーバー障害、外部システムの遅延、ランサムウェア、表示器の一部停止、誤った時刻情報の配信を想定し、検知、切り離し、代替運用、復旧、事後確認を見積もりに含めます。予備系を用意するだけでなく、誰が切替を判断し、どのデータを正として、どの時点まで戻すかを決めることが必要です。

国土交通省は2026年4月30日に空港分野における情報セキュリティ確保に係る安全ガイドライン第4版を改訂し、責任者・権限、資産管理、監査、継続的改善などを示しています（出典: 国土交通省「航空及び空港分野における情報セキュリティ確保に係る安全ガイドライン」、2026年）。法令の条文をそのまま要件にするものではありませんが、資産台帳、最小権限、多要素認証、監査ログ、脆弱性・パッチ管理、バックアップ、インシデント報告、復旧訓練を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から現場の表示や指示まで正しく届くことを受入基準にしてください。

費用は、単一業務の500万〜1,500万円から大規模ハブの3億円〜数十億円以上まで幅があります。公開調達の1,782万円という事例も、AODB新規構築ではなく、既存システムの設定変更と動作試験の金額です。初期費用だけで判断せず、外部連携、移行、機器、現地工事、保守、クラウド、教育、5年TCOを同じ条件で比較してください。

RFPには、業務範囲、データの正本、標準規格、可用性、RTO・RPO、セキュリティ、通信断・停電・サイバー攻撃時の業務継続、移行、教育、保守、責任分界を記載します。国土交通省の2026年改訂ガイドラインも参照しながら、空港を止めないための技術と運用を一体で設計してください。これらを整理できれば、製品や開発会社の比較がしやすくなり、導入後の追加費用と現場の混乱を抑えられます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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