空港業務システム開発の発注/外注/依頼/委託方法について

空港業務システムの発注・外注は、業務範囲とデータの正本、障害時の責任分界を先に決め、段階契約で委託先を比較することが成功の要点です。

空港会社や航空会社の情報システム担当者が外注を検討するとき、悩みやすいのは「何をRFPに書けばよいか」「パッケージとスクラッチのどちらを選ぶか」「見積金額が妥当か」という点です。この記事では、空港業務システムの発注形態、要件整理、契約の分け方、費用相場、委託先の選定方法を、AODBやFIDSなどの空港固有の論点に沿って解説します。

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

空港業務システムの発注で最初に整理すべき全体像

空港業務システムは一つのアプリケーションではなく、運航、旅客、設備、人員、手荷物などの情報を複数の関係者で共有する業務基盤です。発注時にシステム名だけを決めると、既存機器との接続や現場の手作業が見積から抜けやすくなります。まず「どの業務を、誰が、どのデータを使って、どの時間帯に処理するのか」を明確にします。

AODBは便名、運航スケジュール、機材、到着・出発時刻、ゲート、スポット、チェックインカウンターなどを管理する空港運用データベースです。FIDSはその情報を搭乗口や到着案内、手荷物受取案内などへ配信し、RMSはスポット、ゲート、カウンター、バゲージベルト、バスなどの資源を便に割り当てます。空港業務システムを外注するときは、これらを別製品として選ぶ場合でも、同じ便の時刻や状態をどのシステムが正本として持つかを決めます。

周辺にはDCS・チェックイン連携、BHS（手荷物処理システム）連携、設備点検、勤怠、請求、旅客流動分析などが加わります。航空会社、グランドハンドリング会社、航空局、保安担当、テナントなど、組織ごとに更新できる項目が異なるため、単なる画面一覧ではなく、便情報の発生から表示・現場指示・請求までの流れを確認することが大切です。

空港業務では、通信断、停電、外部システムの遅延、繁忙日の同時更新、屋外や地下での電波不良が起こり得ます。デモ環境で便の登録や表示ができても、ランプで端末がオフラインになったときに現場が作業を続けられるとは限りません。RFPには、再送、重複排除、時刻逆転、表示器停止、手作業への切替、復旧後のデータ整合を試験することまで書きます。

また、空港はITだけでなく、表示器、ゲート機器、手荷物搬送設備、専用回線、入退場設備などのOT領域と接続します。国土交通省は空港分野を重要インフラとして扱い、空港分野における情報セキュリティ確保に係る安全ガイドライン第4版を2026年4月30日に改訂しています。RFPでは、ITとOTの境界、権限、ログ、パッチ、バックアップ、インシデント時の連絡を契約前から確認します。出典: 国土交通省「空港分野における情報セキュリティ確保に係る安全ガイドライン」（2026年）です。

空港業務システムの発注形態はどのように選びますか？

発注形態は、パッケージ・クラウドを使うか、既存システムを拡張するか、スクラッチ開発するかで選びます。結論として、空港業務システムではAODBやFIDSなど標準化しやすい中核機能をパッケージまたはクラウドで採用し、空港固有の請求・設備・現場作業だけを追加開発するハイブリッド方式が比較しやすい選択肢です。ただし、既存設備や航空会社側の接続条件によって最適解は変わります。

パッケージ・クラウド型は、空港運用の標準機能や業界連携を利用できるため、ゼロからの開発量を抑えやすい方式です。複数空港への展開、機能更新、可用性の実績を確認しやすい点もメリットです。一方、既存のローカルルールをすべて再現しようとすると追加開発が積み上がり、標準化による短期化効果が薄れます。

クラウド型を選ぶときは、月額料金だけでなく、便数、ユーザー数、データ保持期間、API・メッセージング、バックアップ、冗長化、障害時の代替運用を確認します。データの保存場所、個人情報の分離、空港ネットワークからの接続方法、回線断時のローカル継続可否もRFPに含めます。標準機能のデモでは、実際の便ダイヤと空港固有の例外を使って評価します。

ハイブリッド型では、AODB、FIDS、RMSなどの中核は既存製品やクラウドサービスを使い、空港独自の設備台帳、作業モバイル、請求、分析画面などを周辺開発します。パッケージの標準化と現場の使いやすさを両立しやすく、最初の導入範囲を絞って段階展開できます。発注前に、どこまでが製品標準で、どこからが追加開発かを機能一覧で分けることが重要です。

注意点は、製品会社、SI会社、機器会社、空港側の責任境界が複雑になることです。例えばFIDSに誤った時刻が表示された場合、AODBのデータ更新、連携メッセージ、表示サーバー、表示器のどこに原因があるかを切り分けます。障害受付の窓口、ログの共有方法、原因調査の期限、復旧判断者を契約と運用設計書に定義します。

スクラッチ開発は、空港固有の運用が競争力に直結し、既存製品では業務要件や設備連携を満たせない場合に選択します。複雑な資源割当、特殊な請求ルール、独自の現場ワークフローなどを柔軟に実装できますが、可用性、セキュリティ、標準規格への対応、24時間の保守体制を長期に維持する必要があります。

スクラッチを選ぶ場合でも、AIDX、SITA Type B、API、メッセージングなどの標準的な接続方式を採用し、独自仕様をデータ辞書とインターフェース仕様書に閉じ込めます。将来の委託先変更を可能にするため、ソースコード、設計書、テストデータ、運用手順、ログの所有権と引き渡し条件を発注段階で確認します。

RFPと要件整理では何を決めておきますか？

RFPは「高機能なシステムを作ってください」と依頼する文書ではなく、解決したい業務課題、対象範囲、前提条件、提案してほしい事項を同じ条件で候補会社へ伝える文書です。候補会社から比較可能な提案を受けるには、機能要件だけでなく、データ、外部接続、性能、可用性、セキュリティ、移行、教育、保守まで書く必要があります。

最初に、対象空港、ターミナル数、便数の規模、対象部門、対象時間帯、既存システム、利用者の種類を記載します。次に、遅延時の情報更新時間、表示誤りの削減、再入力の削減、スポットやゲートの稼働率、手荷物照合漏れ、請求漏れなど、導入後に測りたいKPIを置きます。「DXを推進する」だけでは提案の良し悪しを判定できないため、現状値と目標値が分かる範囲で示します。

機能要件は、便情報の登録・変更・取消、資源割当、承認、通知、表示、検索、帳票、監査ログのように業務動作で書きます。例えば「FIDSと連携する」ではなく、「AODBで確定した出発時刻の変更を、指定された表示器へ何秒以内に配信し、通信断から復旧した際に重複表示を起こさない」と記載します。要件を操作と判定条件に変えると、見積と受入テストがつながります。

空港業務システムの見積差が大きくなりやすいのは、既存連携の調査とデータ移行です。現行システムごとに、データ項目、桁・コード、更新元、更新頻度、時刻の定義、連携方式、通信経路、再送方法、障害時の保管場所を一覧化します。特に「出発予定時刻」「出発実績時刻」「搭乗開始時刻」など、似た項目の意味をデータ辞書で定義します。

インターフェース一覧には、接続先、送受信データ、方向、形式、頻度、認証、タイムアウト、再送、重複排除、監視者、試験用データの入手方法を含めます。AODB、DCS、BHS、FIDS、RMSの各責任者を一枚の連携図に配置すると、どの会社に何を見積もらせるべきかが見えます。既存ベンダーから仕様が開示されない場合は、調査費と仕様確認を別工程として発注します。

非機能要件には、稼働時間、性能、可用性、RTO（目標復旧時間）、RPO（目標復旧時点）、バックアップ、監視、ログ、保守時間、脆弱性対応を記載します。24時間365日運用を求めるなら、営業時間内の問い合わせ対応だけでなく、夜間の一次受付、現場到着の条件、代替サーバーへの切替、手作業への移行判断までをSLAの対象にします。

国土交通省の空港分野ガイドラインは、セキュリティ責任者の任命、役割分担、監査、継続的改善などを含む管理策を示しています。空港会社だけでなく、クラウド事業者、開発会社、機器会社、保守会社の役割を整理し、アカウント管理、特権操作、ログ保管、パッチ適用、インシデント報告の期限をRFPへ反映します。出典: 国土交通省「情報化：情報セキュリティ」（2026年）です。

契約形態と発注からリリースまでの進め方

空港業務システムは、最初から全範囲を固定価格で契約するより、調査・要件定義・実装・移行を分けたほうが不確実性を管理しやすい案件です。契約形態は準委任、請負、ライセンス・クラウド利用契約、保守契約を組み合わせます。契約名称だけで判断せず、成果物、検収条件、変更手続、責任範囲を確認します。

現行システムの棚卸し、現場ヒアリング、データ辞書、連携調査、業務フロー、RFP作成支援は、開始時点で作業量が変動しやすいため準委任契約と相性があります。稼働した人員や作業時間に応じて支払う場合でも、月次の作業計画、会議体、成果物、レビュー期限を定めます。単に人を常駐させる契約にせず、次の工程を判断できる状態までを成果として確認します。

調査工程の成果物は、業務一覧、システム構成図、インターフェース一覧、データ辞書、課題・リスク一覧、概算見積、優先順位、移行方針です。これらが揃えば、複数社へ同じ前提で実装提案を依頼できます。調査を一社に任せる場合は、成果物の著作権や再利用、次工程を別会社へ発注する場合の引き渡し条件も確認します。

要件と受入条件を固定できた機能は請負契約で発注し、納品物、検収、瑕疵対応、納期を明確にします。一方、外部仕様の開示待ちや現地試験で変動する部分まで固定価格に含めると、見積に大きな予備費が乗るか、後から変更請求が発生します。固定する範囲と、実績精算・別途協議とする範囲を機能単位で分けます。

変更管理では、要求の背景、影響する画面・連携・試験、費用、納期、セキュリティ、承認者を記録します。空港の運航ルール変更や表示器増設が起きても、口頭依頼で開発を進めないことが大切です。要求管理表を週次で確認し、変更を採用しない場合の代替運用まで合意します。

受入テストは、開発会社のテスト環境だけで完了させません。実際の便ダイヤに近いデータで、AODBからFIDS、RMS、DCS、BHSへ情報が届くことを確認し、搭乗口やランプなど現地の通信条件でも検証します。通信断、停電、外部システム停止、時刻の逆転、同一便の連続変更、繁忙日の同時操作を試験項目に含めます。

リリースは、単一業務や単一ターミナルでのパイロット、並行稼働、段階展開の順に進めます。切替判定には、重大障害ゼロ、データ件数の一致、現場担当者の操作確認、手作業への切戻し手順、問い合わせ窓口の稼働を含めます。リリース後の安定化期間、追加改修の扱い、教育資料の更新責任も契約書と運用引継書に残します。

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

空港業務システムの公開された一律価格はありません。対象業務、空港規模、便数、ターミナル数、外部連携、機器・ネットワーク工事、移行、二重化、保守の範囲で金額が大きく変わるため、以下は2026年時点の初期予算を置くための計画用推定です。正式な予算化では、同じRFPを複数社へ提示し、前提条件をそろえた見積を取得します。

単一業務のパッケージ設定や小規模な追加開発、数本の連携であれば、初期費用は500万〜1,500万円、導入期間は3〜6カ月が一つの目安です。単一ターミナルのAODB、スポット管理、またはRMS刷新では、1,500万〜5,000万円、6〜12カ月程度を仮置きします。データ移行、現場教育、既存設備の調査を含めると上限を超えることがあります。

AODB、FIDS、RMSにDCSやBHSなどを組み合わせ、二重化、総合試験、段階切替まで行う場合は、5,000万円〜3億円程度、12〜24カ月が計画用のレンジです。複数ターミナルや大規模ハブで、設備、保安、旅客流動、制御系まで統合する場合は、3億円から数十億円以上となる可能性があります。これらは公開された相場ではなく、機能数と導入規模からの推定であることを見積書に明記します。

公開調達を比較材料にすることもできます。気象庁の公開資料では、東京国際空港の空港気象ドップラーレーダー業務処理ソフトウェア設定変更と動作試験が、2025年8月18日に1,782万円（税込）で契約されています。AODBの新規構築価格ではありませんが、機器間の相互接続や専門知識を要する既存システム変更でも1,000万円台になる事例です。出典: 気象庁「落札情報 物品役務調達 随意契約 R7 11月分掲載用」（2025年）です。

見積書では、要件定義・業務設計、製品ライセンスまたはクラウド利用、設定・追加開発、外部連携、データ移行、サーバー・ネットワーク、表示器・端末、現地工事、総合試験、教育、切替、保守を分けて記載してもらいます。特に表示器や手荷物設備は、ソフトウェア費用だけを見ていると、端末調達、設置、配線、現地夜間作業が後から増えます。

年間保守は初期開発費の10〜15%程度を仮置きできますが、空港の24時間365日SLA、現地駆け付け、予備機、監視、脆弱性対応を含めると高くなる可能性があります。クラウド型は初期費用が低く見えても、利用空港数、便数、ユーザー数、データ保持、冗長化、外部通信による月額・従量費が発生します。初期費用だけでなく、5年TCO、契約更新時の値上げ条件、データ返却費用まで比較します。

委託先の選定と見積比較で確認するポイント

委託先は、知名度や提示価格だけで選びません。空港業務の実績、現地設備との接続力、データ移行の経験、24時間運用の体制、セキュリティ対応、提案の透明性を同じ評価表で比較します。候補会社には、空港規模、便数、ターミナル数、表示器台数、既存連携、希望SLA、予算帯を最初に伝え、同じ前提で提案してもらいます。

実績確認では、会社名や導入件数だけでなく、どの業務を担当したかを聞きます。AODBの正本管理、FIDSの表示配信、RMSの資源割当、A-CDMの関係者連携、BHSとの接続、現地工事、データ移行、運用保守のどこまでを担当したのかを確認します。公開事例として、三菱電機は関西国際空港の旅客案内情報システムでフライト情報の一元管理や二重化、数百台規模の表示器を紹介し、日立は成田国際空港で約600台規模のフライトインフォメーションシステムを公表しています。

海外製品も候補にする場合は、SITA、Amadeus、VeovoなどのAODB・A-CDM・資源管理の機能を比較できます。SITAは2025年にコロンビアのエルドラド国際空港でA-CDMを導入し、出発順序や空港運用の協調に関わる機能を統合したと公表しています。海外実績をそのまま国内空港へ当てはめず、日本語運用、国内法規、現地保守、既存の航空会社・管制・設備との接続を評価します。出典: SITA「El Dorado becomes first airport in Latin America to implement A-CDM system」（2025年）です。

見積比較では、合計金額の安い順に並べるのではなく、機能、工数、単価、期間、体制、前提、対象外、予備費を横並びにします。特に、連携本数、データ移行件数、テストケース数、現地作業日数、表示器・端末の台数、夜間対応、教育回数が同じかを確認します。安い見積でも、移行や総合試験が対象外なら、発注後に追加費用が生じる可能性があります。

提案評価は、価格30点、業務適合25点、技術・連携20点、運用保守15点、プロジェクト体制10点など、社内で重みを決めて実施します。配点は空港の事情に合わせて変更できますが、価格だけで過半を占めないことが大切です。提案会社には、標準機能で対応する項目、設定変更する項目、追加開発する項目、業務を変える項目を分類してもらいます。

空港業務システムは、長期間使うほど特定ベンダーへの依存が生まれます。データ形式、API仕様、ソースコード、設定情報、ログ、バックアップの取り出し可否、契約終了時のデータ返却、第三者保守の可否を確認します。既存ベンダーしか変更できない設備がある場合も、変更権限、仕様書の入手方法、障害時の協力義務を契約上の条件にします。

運用体制では、開発会社のプロジェクトマネージャーだけでなく、空港側の業務責任者、IT担当、設備担当、航空会社・ハンドラーの代表を置きます。障害の重大度、一次切り分け、エスカレーション、現地駆け付け、復旧後の原因報告、再発防止の期限を運用設計に落とします。24時間運用を担保するには、担当者の経験ではなく、当番表、手順書、訓練記録、監視実績で体制を評価します。

発注後に起こりやすいリスクと対策

発注時のリスクは、開発技術だけでなく、関係者の多さと運用停止の影響から生じます。要件の抜け、既存ベンダーの仕様不明、現地試験不足、移行データの不整合、責任分界の曖昧さが重なると、納期と費用だけでなく、現場の安全な運用にも影響します。リスクを契約前、開発中、切替前に分けて管理します。

現場ヒアリングを重ねるほど、部署ごとの例外処理が増えます。必須要件、法令・安全上必要な要件、業務改善要件、将来要件に分類し、初回リリースへ含める範囲を決めます。すべてを初回に盛り込むのではなく、AODBとスポット管理などデータの正本に関わる部分を先に安定させ、分析や高度な自動化は次段階に分ける方法が現実的です。

AIや予測分析を導入する場合も、目的を機能ではなくKPIで示します。遅延予測の的中率だけでなく、予測を誰が確認し、どの判断に使い、誤った場合に誰が訂正するのかを定義します。入力データの欠損や便数の少ないケースを検証せずにAI機能だけを発注すると、業務に定着しない可能性があります。

本番切替の前には、移行対象の便、ゲート、スポット、時刻、利用者、権限、設備台帳などを洗い出し、件数と値の一致を確認します。過去データをすべて移すのか、参照用に保管するのか、変換できない項目をどう扱うのかを決めます。移行時間が繁忙時間にかからないよう、実測で所要時間を確認します。

切替後に問題が起きた場合は、旧システムへ戻す条件、戻せる期限、手作業で続ける業務、復旧後に再入力するデータを決めます。並行稼働では二重入力が増えるため、正本をどちらに置くか、変更をどちらへ反映するかを明確にします。リハーサルの結果と未解決課題を、切替承認者が確認してから本番へ進みます。

よくある質問（FAQ）

空港業務システムの発注では、費用だけでなく、空港の規模や既存システムとの接続条件によって答えが変わります。ここでは、相談前に特に質問されやすい点を、判断の基準とともに回答します。

外注できます。最初から空港全体を刷新せず、FIDS、スポット管理、作業管理、設備台帳など、効果と範囲が明確な単一業務から始める方法が適しています。便数、ターミナル数、既存機器、必要な稼働時間を伝え、クラウド標準機能や既存製品の設定で対応できる範囲を確認します。

概算見積は依頼できますが、前提が曖昧なままでは会社ごとの想定範囲が異なり、金額を比較できません。対象業務、既存システム、連携本数、端末・表示器、希望時期、24時間運用の要否だけでも整理し、調査・要件定義の見積と実装の概算を分けて提示してもらいます。初回の見積には、対象外と不確実な前提を必ず記載してもらいます。

単一業務なら500万〜1,500万円、単一ターミナル級なら1,500万〜5,000万円、複数部門をまたぐAODB・FIDS・RMS統合なら5,000万円〜3億円程度が、初期予算を置く際の計画用推定です。機器、現地工事、外部連携、移行、二重化、保守を含むかで変わるため、公開相場として断定できません。候補会社へ同じRFPを渡し、初期費用と5年TCOを分けて比較します。

空港の規模と課題によって選びます。複数システムの統合、現地設備、関係者調整、24時間保守まで必要なら、大規模SIerや空港実績のある共同体制が候補です。特定の業務を短期間で導入するなら、AODB、FIDS、RMS、クラウド運用などに強い専門ベンダーも比較します。会社の規模ではなく、実績の担当範囲、現地体制、責任分界、データ返却条件で評価します。

まとめ

発注前は、対象業務、データの正本、既存連携、非機能要件、移行範囲、保守体制、契約終了時のデータ返却を確認します。候補会社の提案書に対象外や不確実な前提が残っていないかを確認し、社内の業務責任者とIT担当者が同じ判断基準を持てる状態にします。

いきなり開発会社へ丸投げするのではなく、現行システムと現場業務の調査を行い、同じ前提でRFPを配布することから始めます。調査・要件定義を準委任、確定した範囲の実装を請負、運用を保守契約として分けると、変更の影響を管理しやすくなります。

空港業務システムの発注・外注では、最初にAODBを中心としたデータの正本、対象業務、関係者、既存連携を整理します。パッケージ・クラウド・スクラッチを比較し、標準機能で対応する範囲と追加開発する範囲を分けると、費用と納期の見通しを立てやすくなります。

RFPには機能だけでなく、通信断や停電時の代替運用、RTO・RPO、セキュリティ、移行、教育、SLA、責任分界を記載します。調査・要件定義、実装、移行・切替、保守を段階的に契約し、複数社から同じ前提の見積を取得してください。価格だけでなく、空港固有の実績、現地試験、24時間運用、ロックイン対策まで比較することが、長く使える空港業務システムにつながります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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