空港業務システム開発の完全ガイド

空港業務システムとは、便・旅客・設備・人員の情報をつなぎ、空港を止めずに運営するための業務基盤です。中心にAODBを置き、FIDSやRMS、DCS、BHSなどを連携させることで、同じ便情報を関係者が正しく共有できるようになります。

空港業務システムの導入や刷新では、機能の多さだけでなく、どのデータを正本にするか、通信断や停電時にどう業務を続けるか、既存設備とどこまで接続するかを先に決めることが重要です。本記事では、システムの全体像、種類、開発の進め方、技術選択、費用相場、開発会社やサービスの選び方、発注・外注の進め方、FAQまでをまとめて解説します。

▼関連記事一覧
・空港業務システム開発の進め方
・空港業務システム開発でおすすめの開発会社6選と選び方
・空港業務システム開発の見積相場・費用
・空港業務システム開発の発注・外注・委託方法

空港業務システムとは何ですか？

空港業務システムは、空港会社だけが使う単一の製品名ではありません。空港会社、航空会社、グランドハンドリング会社、航空局、テナント、交通事業者などが持つ情報を、業務の流れに合わせて共有する複数システムの総称です。空港の規模や運航形態によって構成は変わりますが、便情報を中心に各業務を結び付ける考え方は共通しています。

AODBはAirport Operational Databaseの略で、空港運用データベースを意味します。便名、運航スケジュール、機材、到着・出発の予定時刻と実績時刻、ゲート、スポット、チェックインカウンター、手荷物搬送、航空会社、ハンドラーなどを管理し、関係システムへ配信する中核です。たとえば出発時刻の変更をAODBで確定し、FIDSの表示、ゲート担当者の指示、資源の再割り当てへ同じ情報を届ける構成です。

重要なのは、AODBを導入すること自体ではなく、更新元と更新権限を決めることです。予定時刻、実績時刻、予測時刻が別々の画面で管理されると、同じ便に複数の「正しい時刻」が生まれます。設計段階でイベントの正本、タイムスタンプ、再送、重複排除、時刻同期までデータ辞書に定義する必要があります。

代表的な周辺システムがFIDS、RMS、DCS、BHSです。FIDSは搭乗口、遅延、到着、手荷物受取などを表示器やWebへ配信します。RMSはスポット、ゲート、カウンター、バゲージベルト、バス、スタッフなどの資源を便の制約に合わせて割り当てます。DCSやチェックイン連携は搭乗手続きや搭乗者情報を扱い、BHS連携は手荷物の受付、照合、仕分け、搬送、異常検知の情報を扱います。

これらは同じシステムにすべて詰め込む必要はありません。制御系と業務系を分離しながら、必要なイベントだけを安全に連携させることが基本です。システムの範囲を決めるときは、対象業務、利用者、入力元、出力先、停止時の代替手段を一枚の構成図に整理すると、個別最適による二重入力を防ぎやすくなります。

空港業務システムの種類と主な機能

空港業務システムの種類は、データを集約する基盤、現場へ情報を届ける業務、設備や人員を動かす業務、分析や請求を支える業務に分けて考えると整理しやすくなります。導入目的が「表示器を更新したい」場合でも、便情報の正本や既存連携を確認しなければ、後のAODB刷新で作り直しになる可能性があります。

運航情報の管理では、便の計画、運休、遅延、到着、出発、ゲート変更などを時系列で扱います。空港資源の管理では、スポット、ゲート、カウンター、ベルト、バス、作業員などを割り当て、変更が発生したときに再計算します。A-CDM（Airport Collaborative Decision Making）は、空港、航空会社、ハンドラー、管制などがターンアラウンド情報を共有し、出発順序や遅延対応を協調する考え方です。

RMSの画面だけを高機能にしても、便の実績時刻や作業完了情報が正しく届かなければ、割り当ての精度は上がりません。業務要件では「誰がいつ何を更新し、その結果をどの画面と機器へ何秒以内に届けるか」を定義し、通常時と異常時の両方で受入条件を設定します。

旅客向けには、FIDS、館内案内、アクセス交通情報、混雑情報、通知配信などがあります。管理向けには、設備点検、入退場、勤務シフト、保安、防災、空港使用料、広告・施設利用料などがあります。さらに旅客流動、待ち時間、遅延要因、資源稼働率を蓄積し、改善のKPIを確認する分析基盤も重要です。

小規模空港であれば、まずはFIDS、作業モバイル、設備台帳、勤怠など単一業務から始める選択肢があります。その場合も、便ID、運航状態、時刻、施設IDなどの共通データを後から拡張できる形で設計します。規模が小さいから個別ファイルで十分と判断すると、将来の便数増加や新しい航空会社の参加時に移行費用が膨らみやすくなります。

空港業務システムの開発はどのように進めますか？

空港業務システム開発は、企画、現行調査、要件定義、設計・開発、現地試験、移行、運用設計の順に段階化することが基本です。特に重要なのは、最初から空港全体を一括刷新するのではなく、業務単位で優先順位を付けながら、将来の連携を壊さないことです。最初の成果物を明確にし、各段階で継続・見直し・中止を判断できるようにします。

最初に、遅延時間の短縮、ゲート変更の伝達漏れ削減、手荷物照合漏れの防止、スタッフの再入力削減、設備停止時間の短縮、請求漏れの防止など、測定できるKPIを置きます。次に、システム名、業務、データ項目、更新元、連携先、通信方式、端末、回線、保守契約、手作業の表計算ファイルを一覧化します。

現場ヒアリングでは、空港会社だけでなく、航空会社、ハンドラー、保安、設備、旅客案内、情報システム、委託先を対象にします。担当者ごとに異なる用語や時刻定義をデータ辞書へ落とし、正本データと責任分界を合意します。この一覧がないまま提案依頼を行うと、見積の前提が各社で異なり、後から追加費用として表面化しやすくなります。

要件は、業界標準や候補サービスの標準業務に合わせる「Fit to Standard」を基本にします。空港固有のルールは、標準設定で対応するもの、追加開発するもの、業務を変更するもの、今回は対象外にするものへ分けます。例外をすべて個別開発すると、テストケース、教育、保守の負担が増え、将来のバージョンアップにも影響します。

デモでは、実際の便ダイヤに近いデータを使い、通信断、重複メッセージ、時刻の逆転、外部システムの遅延、表示器停止、繁忙日の同時更新を再現します。ランプ、搭乗口、地下、屋外など電波条件の悪い場所で、オフライン入力、再送、復旧後の整合性を試験します。机上の機能確認だけでなく、現地で業務が続くかを合否基準にすることが重要です。

本番切替前には、データ移行のリハーサル、並行稼働、読み取り専用期間、切戻し条件を決めます。AODBを切り替えた時点だけでなく、FIDS、現場端末、資源割当、外部連携へ正しい情報が届くところまでを一つの受入テストにします。便数の少ない時間帯に切り替える場合でも、想定外の遅延が起きたときの手作業運用を用意します。

運用設計では、24時間監視、障害一次受付、空港会社・航空会社・ハンドラー・委託先・開発会社の責任分界、パッチ適用、脆弱性対応、ログ保管、復旧目標（RTO・RPO）、訓練を契約と手順書に落とします。開発完了をゴールにせず、障害時に誰が判断し、誰が現場へ指示し、どの手作業で運航をつなぐかまで決めることが定着の条件です。

▶ 詳細はこちら：空港業務システム開発の進め方

パッケージ・クラウド・スクラッチはどれを選びますか？

技術選択は、価格だけでなく、標準連携、可用性、現地の通信条件、保守人材、将来の拡張性を比較して決めます。一般的には、AODBやFIDSなど標準化しやすい領域はパッケージやクラウドを活用し、空港固有の請求、設備、作業アプリだけを追加開発するハイブリッド方式が検討しやすいです。

パッケージやクラウドの利点は、業務標準、外部連携、監視、バックアップ、バージョンアップの仕組みを活用しやすいことです。初期開発を抑えやすく、複数の拠点へ展開する場合にも共通機能を再利用できます。一方で、独自の運用をそのまま再現できない場合があり、業務側がどこまで標準へ合わせられるかを先に確認します。

クラウドを選ぶ場合は、データ保管場所、接続方式、ネットワーク断時の動作、冗長化、SLA、利用空港数、便数、ユーザー数、ログ保存期間、データの持ち出し方法を確認します。オンライン時だけ動けばよいシステムではないため、重要な処理を一時保存できる仕組みと、復旧後に重複なく同期する仕組みが必要です。

ハイブリッド方式は、AODB・FIDS・RMSを標準機能で構築し、既存の設備台帳、請求、作業管理、現場モバイルなどをAPIでつなぐ方法です。すべてを作り直さずに済むため、段階導入と将来の拡張のバランスを取りやすいです。ただし、システム間の責任分界、障害時の問い合わせ先、データの正本を契約に書かなければ、障害原因の切り分けが難しくなります。

スクラッチ開発は、既存製品では対応できない固有の運航ルールや設備連携を実装できる点が強みです。一方で、業界標準への追随、可用性、セキュリティ、24時間保守、担当者の交代、長期の技術更新を自ら維持する必要があります。スクラッチを選ぶときは、独自開発が必要な要件を限定し、標準化できる領域まで作り込まない判断が大切です。

2026年時点では、クラウド型AODB、A-CDMによるリアルタイム協調、旅客流動や遅延の予測、デジタルエプロン、設備や地理情報との連携が注目されています。国際空港では、便・資源・旅客・収益のデータを一つの情報源へ集約し、関係者が同じ状況を見ながら判断する方向が強まっています。ただし、AIや予測モデルを導入しても、元データの時刻や欠損が不正確なら、現場の判断を誤らせる可能性があります。

したがって、最新技術は目的ではなくKPIの改善手段として評価します。遅延予測の的中率、ゲート変更の通知時間、旅客の待ち時間、資源稼働率、手作業の回数などを導入前後で比較し、予測結果を誰が承認するかを決めます。AIを使わない場合の運用も残しておくと、モデル停止やデータ欠損時にも業務を継続しやすくなります。

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

空港業務システムの標準価格表は、対象業務、空港規模、ターミナル数、便数、既存設備、連携数、可用性、現地工事、保安審査、移行、24時間運用の条件で変わるため公開されていません。以下は公開調達の類似案件と一般的な大規模業務システムの工数構成から置く、計画用の推定レンジです。実際の見積を保証する金額ではなく、RFPの予算枠を検討するための目安として利用します。

単一業務の導入は500万〜1,500万円程度、地方空港や単一ターミナルのAODBまたはスポット・RMS刷新は1,500万〜5,000万円程度が初期予算の仮置きです。AODB、FIDS、RMS、DCS・BHSなどを複数部門で統合し、高可用性、外部連携、移行、総合試験まで含めると5,000万円〜3億円程度になります。複数ターミナルや複数拠点、設備・保安・旅客流動・制御系まで統合するハブ級では、3億円〜数十億円以上になる可能性があります。

期間の目安は、単一業務が3〜6カ月、単一ターミナル級が6〜12カ月、複合統合が12〜24カ月、大規模ハブが2〜4年以上です。2025年度の国土交通省航空局の入札結果では、空港使用料算定システムについて開発業務への人材、クラウドサービス、ソフトウェア保守が別案件として掲載されています。システムは一括の箱ではなく、開発・基盤・保守を分けて調達する場合があることを示す資料です（出典：国土交通省「令和7年度入札結果」、2026年確認）。

見積では、要件定義・業務設計、アプリ開発や設定、外部連携・データ移行、クラウド・サーバー・二重化、端末・表示器・ネットワーク・現地工事、総合試験・教育・切替、保守を分けて記載してもらいます。目安として、要件定義・業務設計は10〜15%、アプリ開発・設定は20〜30%、外部連携・移行は25〜40%、基盤・二重化・ネットワークは10〜25%、端末・現地工事は10〜30%、試験・訓練・切替は5〜15%程度で仮置きします。項目は重複し得るため、合計を固定比率として扱わないことが大切です。

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

年間保守は初期開発費の10〜15%を目安に置きますが、監視時間、現地対応、予備機、SLA、セキュリティ更新、ライセンス、データ保持期間によって増減します。クラウド型は初期費用を抑えやすい一方、利用空港数、便数、ユーザー数、メッセージ量、バックアップ、冗長化に応じた月額・従量費が発生します。初期1,000万〜5,000万円、年間500万〜3,000万円程度を仮置きする場合でも、必ず提案条件で内訳を確認します。

比較表には、初期開発、機器・現地工事、移行・教育、月額利用、保守、追加連携、バージョンアップ、障害対応、契約終了時のデータ取り出しを5年分で並べます。安い提案が、表示器や回線、保安審査、夜間切替、現地試験を除外している可能性もあります。見積書の「含む・含まない・前提条件・上限」を確認すると、後からの予算差異を抑えられます。

▶ 詳細はこちら：空港業務システム開発の見積相場・費用

おすすめ開発会社・サービスはどのように選びますか？

開発会社やサービスは、知名度や機能数のランキングではなく、自空港の業務・設備・連携・運用に適合するかで選びます。空港向けの実績があっても、対象業務や空港規模が異なれば、そのまま成功するとは限りません。提案依頼では、通常時だけでなく障害時、夜間、繁忙期、担当者交代後の保守まで確認します。

比較項目には、空港規模、ターミナル数、便数、AODB・FIDS・RMS・DCS・BHSの対応範囲、AIDX・Type B・APIなどの接続方式、既存機器との連携、データ移行、二重化、オフライン、監視、SLA、日本語の運用体制を含めます。ソフトウェアの機能だけでなく、表示器、ネットワーク、現地端末、保安区域での作業まで含む体制を確認します。

候補先には、便数、ターミナル数、表示器台数、現行システム一覧、連携先、通信制約、目標KPI、想定予算帯、希望時期、必要なSLAを同じ資料で渡します。各社に同じ条件で回答してもらうことで、価格の差が機能差なのか、対象範囲や前提の差なのかを見分けやすくなります。

提案書では、標準機能と追加開発の境界、外部システムの前提、データ移行の方法、障害時の代替運用、試験項目、切戻し条件、教育計画、保守窓口を確認します。実データに近い便ダイヤでのPoCや現地試験を提案しているか、通信断・時刻不整合・重複イベントなどを試験対象にしているかも重要です。

また、提案者がすべての領域を自社で担うのか、基盤、端末、ネットワーク、現地工事、既存システム連携を別の事業者へ委託するのかを明らかにします。再委託先の責任、障害時の指揮系統、ログや設計書の所有権、契約終了時のデータ返却まで確認しておくと、特定の担当者や一つの製品だけに依存するリスクを下げられます。

小規模空港では、最初から大規模な統合基盤を導入するより、優先課題を一つ選び、便情報や施設情報の共通IDを先に整備する方法が現実的です。候補先には、単一ターミナルでの導入、少人数運用、繁忙期の増員、将来の便数増加に対応できる料金と体制を確認します。初期費用が安くても、後から別システムへ移行できない構成では、長期のTCOが高くなる可能性があります。

選定会議では、機能適合、連携適合、現場適合、セキュリティ、可用性、導入期間、初期費用、5年TCO、保守体制を分けて採点します。評価理由を記録し、価格だけで逆転しないルールを先に決めると、現場の使いやすさと経営上の投資判断を両立しやすくなります。

▶ 詳細はこちら：空港業務システム開発でおすすめの開発会社6選と選び方

空港業務システムの発注・外注・委託はどう進めますか？

発注・外注では、システムを丸ごと任せる前に、業務範囲、正本データ、連携、SLA、セキュリティ、障害時の運用、移行、教育、保守、責任分界をRFPへ書きます。情報が不足したまま「空港業務を効率化したい」とだけ伝えると、提案会社ごとに解釈が変わり、見積と納期を比較できません。

RFPには、対象空港、ターミナル数、便数、利用者、対象業務、現行システム、データ項目、正本、連携先、メッセージ方式、端末・表示器、ネットワーク制約、繁忙期、想定障害、目標KPIを記載します。さらに可用性、RTO・RPO、監視時間、脆弱性対応、ログ保管、バックアップ、権限、データ保管場所、再委託、契約終了時の返却条件も明記します。

回答様式には、標準対応、設定対応、追加開発、対象外を分ける欄を設けます。価格は初期費用、月額、機器、現地作業、移行、試験、教育、保守、追加連携に分け、前提条件と除外事項を必須にします。これだけで、安価に見えるが現地試験を含まない提案や、保守費を後から追加する提案を見分けやすくなります。

空港業務システムでは、最初から全工程を固定価格で契約すると、現行調査で判明した連携仕様や現場例外が追加費用・納期延長につながりやすくなります。まずは有償の概算調査や要件定義で、業務一覧、データ辞書、連携一覧、PoC計画、RFP、受入基準を作り、その成果を確認して実装契約へ進む段階方式が適しています。

契約では、成果物、検収条件、仕様変更の手続き、遅延時の扱い、障害の重大度、応答・復旧時間、再委託、知的財産、ソースや設計書の引き渡し、契約終了時の移行支援を定義します。業務系、制御系、ネットワーク、端末などを複数の委託先に分ける場合は、全体を束ねる責任者とインターフェースの検収者を決めます。

外注の利点は、航空・空港業務の知識や24時間運用の経験を短期間で補えることです。一方、要件、データモデル、接続仕様、運用手順をすべて委託先だけが持つと、担当者の交代や契約終了時に移行できなくなります。空港側にもプロダクトオーナーを置き、重要な判断、データ定義、受入基準、障害訓練に参加する体制を作ります。

既存ベンダーしか変更できない古い連携や専用機器がある場合は、交換可能なインターフェース、データのエクスポート、ログの閲覧、第三者による監査を要件にします。契約時の安さだけでなく、5年後に別の運用方式へ移れるか、保守要員を確保できるかまで確認することが、長期の発注リスクを下げます。

▶ 詳細はこちら：空港業務システム開発の発注・外注・委託方法

空港業務システムのセキュリティとBCPで確認すること

空港業務システムは、業務情報だけでなく、運航、旅客、設備、保安、現場作業に関わる情報を扱います。セキュリティを暗号化だけで考えず、ITとOTの境界、端末、通信、権限、ログ、バックアップ、サプライチェーン、復旧訓練を含むサービス継続の設計として扱います。

RFPには、資産台帳、ネットワーク分離、最小権限、多要素認証、端末管理、暗号化、監査ログ、脆弱性とパッチ管理、バックアップ、復旧試験、インシデント報告を具体的に書きます。FIDSやBHSのように現場機器と接続する領域では、業務系サーバーの更新が制御系へ影響しない境界を設計し、保守作業の承認と記録を残します。

国土交通省の空港分野における情報セキュリティ確保に係る安全ガイドラインは、2026年4月30日に第4版へ改訂されています。重要インフラのサービス提供継続を前提に、想定事象や対処方針、組織統治、リスク管理などを確認できるため、調達時のチェック項目を作る際の基準として参照します（出典：国土交通省「情報化：情報セキュリティ」、2026年）。

BCPでは、通信断時のオフライン入力、停電時の予備電源、表示器停止時の案内方法、外部システム遅延時の手動確認、データ不整合時の正本復旧、ランサムウェア時の隔離と再開条件を決めます。手作業に戻す場合も、どの帳票を使い、誰が承認し、復旧後にどう突合するかを訓練します。

復旧目標は、システムごとにRTO・RPOを設定します。便情報の参照、ゲート割当、FIDS配信、手荷物連携、請求などは、停止の影響が異なるため同じ目標にする必要はありません。年に一度の文書確認だけでなく、実際の現地端末と関係者を参加させた切替訓練を行い、手順の不足を次の改修へ反映します。

空港業務システムに関するよくある質問

ここでは、導入を検討する際によく寄せられる質問へ、結論から回答します。空港規模や既存設備によって適切な構成は変わるため、回答を自空港の業務一覧・連携一覧・障害時手順に置き換えて確認します。

導入できます。最初はFIDS、設備台帳、作業管理、勤務管理など、効果を測りやすい単一業務から始め、便IDや時刻などの共通データを後から拡張できる形で設計します。将来の便数や航空会社の増加を見込み、API、データ出力、料金体系、保守時間を確認しておくことが重要です。

標準化できるAODB、FIDS、RMSなどはクラウドやパッケージを優先し、固有業務だけを追加開発するハイブリッド方式が第一候補になりやすいです。独自の運航ルールや既存機器との不可分な連携がある場合はスクラッチも選択肢ですが、長期の保守・可用性・セキュリティ・業界標準への追随費用まで比較します。

単一業務なら500万〜1,500万円程度、単一ターミナル級なら1,500万〜5,000万円程度、複数業務の統合なら5,000万円〜3億円程度が計画用の目安です。期間は3カ月から24カ月以上まで幅があり、表示器・ネットワーク・現地工事・移行・24時間試験を含めるほど増えます。公開価格ではなく推定レンジなので、同じ前提のRFPで複数社から見積を取得します。

まず、解決したい業務課題とKPIを決め、現行システム・データ・連携・端末・回線・保守・手作業を棚卸しします。次に、便情報の正本、障害時の代替手段、対象範囲、優先順位を関係者で合意し、その内容を候補先へ同じ資料で渡します。いきなり製品デモを見るより、業務とデータの前提を整理する方が、比較可能な提案と見積を得やすくなります。

まとめ

空港業務システムは、AODBを中心にFIDS、RMS、DCS、BHS、設備、人員、請求、分析などをつなぐ業務基盤です。成功のポイントは、空港全体を一気に作り込むことではなく、便情報の正本と責任分界を定め、優先業務から段階導入することです。

発注前には、対象業務とKPI、AODBを含むデータの正本、連携方式、現地の通信条件、通常時と障害時の業務、RTO・RPO、セキュリティ、移行と切戻し、教育、保守窓口、初期費用と5年TCOを確認します。候補先には同じ前提で提案を求め、標準機能・設定・追加開発・対象外を分けて比較します。

空港業務システムは、画面を増やすだけでは業務改善につながりません。表示誤り、再入力、遅延、手荷物照合、資源稼働率、請求漏れなどのKPIを定め、現地試験と運用訓練で確かめながら拡張します。自空港の課題を業務・データ・障害モードの三つに分けて整理することが、納期と予算を守る第一歩です。

まずは、改善したい業務を一つ選び、関係者と現行の流れを可視化します。そのうえで、便情報の正本、連携先、現地の通信条件、停止時の手作業、導入効果を整理し、概算調査や要件定義の成果物へつなげます。小さく始めても共通データと責任分界を守れば、将来のAODBや周辺業務への拡張がしやすくなります。

▼関連記事一覧
・空港業務システム開発の進め方
・空港業務システム開発でおすすめの開発会社6選と選び方
・空港業務システム開発の見積相場・費用
・空港業務システム開発の発注・外注・委託方法