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

空港業務システムの発注は、業務範囲とデータの正本を整理し、要件定義、実装、移行・切替の順に進めると、費用と納期を見通しやすくなります。

全体像は空港業務システム開発の完全ガイドにまとめています。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

空港業務システムは、運航や旅客の情報を関係者で共有する業務基盤です。設備や人員、手荷物の情報も、この基盤で扱います。

システム名だけを決めると、既存機器との接続や現場の手作業が見積から抜けやすくなります。そこで、どの業務を誰がどのデータで、どの時間帯に処理するかを先に明確にします。

AODB・FIDS・RMSが担う役割

AODB、FIDS、RMSは、空港内の便情報と資源を扱う中核システムです。

• AODB：便名、運航予定、機材、時刻、ゲート、スポット、カウンターを管理
• FIDS：便情報を搭乗口、到着案内、手荷物受取案内へ配信
• RMS：スポット、ゲート、カウンター、ベルト、バスを便に割当

これらを別製品にする場合も、同じ便の時刻や状態をどのシステムが正本として持つかは決めておきます。周辺にはDCS・チェックインやBHS（手荷物処理システム）が加わり、設備点検や勤怠、請求、旅客流動分析などとも関わります。

航空会社やグランドハンドリング会社、航空局などでは、更新できる項目が異なります。保安担当やテナントも含めて、便情報の発生から表示、現場指示、請求までの流れを、関係者ごとに確認します。

空港特有の要件を発注範囲に含める理由

空港特有の障害や接続環境を踏まえ、RFPには、障害時も現場を止めずに運用を続けられるか、復旧後にデータが合っているかの確認方法を書きます。

• 想定する障害：通信断、停電、外部遅延、繁忙日の同時更新
• 確認する環境：屋外や地下の電波不良、ランプ端末のオフライン
• 試験項目：再送、重複排除、時刻逆転、表示器停止、手作業への切替
• 復旧確認：復旧後のデータが正しく揃っているか

空港は、表示器やゲート機器、手荷物搬送設備など、OT領域の設備とも接続します。専用回線や入退場設備も含まれます。そのため、RFPではITとOTの境界と権限の範囲を契約前に確認します。

国土交通省は空港分野を重要インフラとして扱っています。安全ガイドライン第4版は2026年4月30日に改訂されています（出典：国土交通省「空港分野における情報セキュリティ確保に係る安全ガイドライン」、2026年）。

ログやパッチ、バックアップ、インシデント時の連絡についても、契約前から取り決めておきます。

空港業務システムの発注形態の選び方

発注形態は、パッケージ・クラウド、ハイブリッド（中核製品＋追加開発）、スクラッチ開発から選びます。AODBやFIDSなどの中核機能は製品を使い、空港固有の部分を追加開発する方法が比較しやすい選択肢です。

ただし、既存設備や航空会社側の接続条件によって最適な形態は変わります。まず、標準機能と個別開発の境界を整理します。

パッケージ・クラウド型の発注

パッケージ・クラウド型では、標準機能の適合性と、空港固有の条件への対応力を分けて評価します。

• 標準機能：業界連携を使い、ゼロからの開発量を抑えやすい
• 導入実績：複数空港への展開、機能更新、可用性の裏付け
• 個別ルール：再現する追加開発が増えると短期化効果が薄れる

クラウド型は、月額料金に加えて、料金の前提条件まで確かめます。

便ダイヤと空港固有の例外を使ったデモで、標準機能が現場に合うかも評価します。回線が断たれたときに現場で運用を続けられるかどうかも、空港ネットワークの条件に沿って確認します。

• 料金条件：便数、ユーザー数、データ保持期間、API・メッセージングの扱い
• 運用条件：バックアップ、冗長化、障害時の代替運用
• 接続条件：保存場所、個人情報の分離、ネットワーク接続

ハイブリッド型の役割分担

ハイブリッド型は、中核製品と空港固有の周辺機能を組み合わせる方式です。標準化と現場への適合を両立しやすい一方で、製品会社やSI会社、機器会社、空港側の責任境界が複雑になる点には注意が必要です。

• 中核機能：AODB、FIDS、RMSは既存製品やクラウドを活用
• 周辺機能：設備台帳、作業モバイル、請求、分析画面を開発
• 導入範囲：標準機能と追加開発を分け、初期範囲を絞って段階展開する

たとえば、FIDSに誤った時刻が出た場合は、AODBの更新を起点に、連携メッセージ、表示サーバー、表示器の順で原因を切り分けます。そのうえで、障害窓口とログ共有の方法、調査期限、復旧判断者を、契約と運用設計書に定めます。

スクラッチ開発を選ぶべきケース

空港固有の運用が競争力に直結し、既存製品で要件や設備連携を満たせない場合に検討します。

• 適用する業務：複雑な資源割当、特殊な請求、独自の現場手順
• 接続方式：AIDX、SITA Type B、API、メッセージングなどを採用
• 独自仕様：データ辞書とインターフェース仕様書に記録
• 引き渡し：コード、設計書、テストデータ、手順、ログの所有権と引き渡し条件

柔軟に実装できる一方で、可用性やセキュリティを長期にわたって維持する必要があります。標準規格への対応や24時間保守も、長く続く作業になります。引き渡し条件は、将来委託先を変える場合に備えて、発注の段階で確認しておきます。

RFPと要件整理で決めておく事項

RFPは、候補会社へ同じ条件で提案してもらうための文書です。そこには、解決したい業務課題や対象範囲、前提条件、提案事項を書きます。

比較できる提案を受けるには、機能に加えて、データや外部接続、性能の条件を書く必要があります。可用性やセキュリティも欠かせません。移行、教育、保守の条件も、RFPに記載します。

RFPの業務範囲と成果指標

提案会社ごとに想定する範囲がずれると、見積を比べられなくなります。そこで、前提と成果判定の条件を具体的に書きます。

• 対象範囲：空港、ターミナル、便数、部門、時間帯、既存システム、利用者
• 成果指標：更新時間、表示誤り、再入力、稼働率、照合漏れ、請求漏れ
• 目標設定：「DX推進」だけでなく、現状値と目標値を分かる範囲で示す
• 機能要件：登録・変更・取消、資源割当、承認、通知、表示、検索、帳票、監査ログ

たとえば、AODBで確定した出発時刻の変更を、指定の表示器へ何秒以内に配信するかまで書きます。「FIDSと連携する」とだけ書いた場合は、どこまでを作るのか判断できません。さらに、通信が復旧したときの重複表示も防ぐ条件にします。

操作と判定条件まで要件に書けば、見積と受入テストを対応させられます。

データ正本とインターフェースの明文化

見積の差が出やすいのは既存連携とデータ移行です。差を抑えるため、項目の定義と連携仕様を分けて明文化します。

• データ定義：項目、桁・コード、更新元、頻度、時刻定義を一覧化
• 似た時刻項目：予定、実績、搭乗開始の意味をデータ辞書で定義
• 連携仕様：方式、通信経路、再送方法、障害時の保管場所
• 接続一覧：接続先、送受信データ、方向、形式、頻度、認証を記録
• 制御・試験：タイムアウト、再送、重複排除、監視者、試験データ

連携図には、AODBとDCSの責任者を書きます。BHS、FIDS、RMSの責任者も書き入れ、会社ごとの見積範囲を明確にします。

仕様が開示されない場合は、調査費と仕様確認を別工程に分けて発注します。

セキュリティとBCPの非機能要件

非機能要件には、稼働と復旧の目標に加えて、セキュリティ管理の担当も明記します。

• 稼働・性能：稼働時間、性能、可用性、保守時間
• 復旧・保護：RTO（目標復旧時間）、RPO（目標復旧時点）、バックアップの方針
• 監視・対策：監視、ログ、脆弱性への対応
• 24時間SLA：夜間受付、現場到着、代替サーバー、手作業への移行が対象

国土交通省の空港分野ガイドラインは、責任者の任命や役割分担、監査、継続的な改善を示しています。空港会社から保守会社まで、関係者の役割を整理します。

そのうえで、アカウントや特権操作、ログ保管の取り決めをRFPに反映します。パッチや報告期限も、RFPに書き込みます（出典：国土交通省「情報化：情報セキュリティ」、2026年）。

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

全範囲を最初から固定価格にするより、工程を分けたほうが、不確実な部分を管理しやすくなります。調査と要件定義、実装、移行を分けて考えます。

準委任、請負、ライセンスやクラウド利用、保守を組み合わせて契約します。契約名だけでなく、作るものの内容と検収条件、変更手続、責任範囲も確認します。

調査・要件定義の準委任契約

調査・要件定義は作業量が変わりやすいため、準委任では作業計画と、できあがったものを確かめる方法を決めます。

• 対象作業：現行業務の洗い出し、ヒアリング、データ辞書、連携調査、業務フロー、RFP支援
• 契約管理：月次計画、会議体、納入物、レビュー期限を定める
• 成果確認：人員・時間に応じた支払いでも、次工程の判断に使える状態を保つ

調査では、まず業務一覧と構成図、連携一覧をそろえます。データ辞書と課題・リスクをまとめ、概算見積や優先順位、移行方針も、調査の成果として残します。

これらがそろえば、複数の会社に同じ条件で実装の提案を頼めます。一社だけに任せる場合は、著作権や再利用、他社への引き渡し条件も確認します。

実装・移行の請負と変更管理

変更の手順が曖昧なままだと、追加作業が出たときに、納期への影響を判断しにくくなります。

• 請負範囲：要件と受入条件が固まった機能の納品物、検収、瑕疵対応、納期
• 変動範囲：仕様開示待ちや現地試験で変わる部分は、実績精算や別途協議に分ける
• 変更記録：背景、画面・連携・試験への影響、費用、納期、セキュリティ、承認者

変動する要素を固定価格に含めると、大きな予備費が上乗せされるか、後から変更請求が発生します。そのため、固定する範囲と実績精算・別途協議の範囲を、機能単位で分けます。

運航ルールの変更や表示器の増設は、口頭で進めず、要求管理表で週に一度確認します。採用されなかった変更については、代替の運用もあらかじめ合意します。

現地試験と段階リリースの契約条件

受入テストを開発会社の環境だけで終わらせず、実際の便ダイヤに近いデータを使います。AODBの情報がFIDSやRMSに届くか、DCSやBHSにも届くかを確かめます。

搭乗口やランプの通信条件も試します。試験では、通信断や停電、外部停止を再現します。時刻逆転や同一便の連続変更、繁忙日の同時操作も含めます。

段階リリースは、次の順で進めます。

1. 単一業務または単一ターミナルで試験導入する
2. 新旧システムを並行稼働させ、データと運用を確かめる
3. 判定条件を満たした後、対象範囲を段階的に広げる

切替の判定には、重大障害がないことやデータ件数の一致を含めます。現場担当者の操作確認や、手作業への切戻し、問い合わせ窓口の稼働も、判定の条件に入れます。安定化期間や追加改修の扱い、教育資料の更新責任は、契約書と運用引継書に残します。

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

空港業務システムには、公開された一律の価格がありません。ここで示すのは、2026年時点の初期予算向けの推定です。

金額は、対象業務や空港規模、便数、ターミナル数で大きく変わります。外部連携や移行、二重化も、金額を左右します。機器・ネットワーク工事や保守範囲も、見積に影響します。

正式な予算では、同じRFPを複数社に示し、前提をそろえます。

スコープ別の初期費用目安

導入規模ごとの費用の幅を押さえておくと、初期予算を置くときの目安が立てやすくなります。

• 単一業務：パッケージ設定や小規模追加開発、数本の連携で500万〜1,500万円、3〜6カ月
• 単一ターミナル：AODB等の刷新は1,500万〜5,000万円、6〜12カ月
• 複数システム統合：二重化・総合試験・段階切替込みで5,000万円〜3億円程度、12〜24カ月
• 大規模統合：複数ターミナル等では3億円から数十億円以上の可能性

単一ターミナルでは、AODBやスポット管理、RMS刷新などを想定します。複数ターミナルでは、設備や保安、旅客流動、制御系の統合で、複数システム統合の目安（3億円）を超える可能性があります。

複数システム統合以上の目安は、AODBやFIDS、RMSにDCSやBHSなどを組み合わせる場合を想定したものです。データ移行や現場教育、既存設備の調査を含めると、各レンジの上限を超える場合があります。

これらは、機能数と導入規模に基づく計画用の推定です。公開された相場とは違う点に注意します。見積書にも、その旨を書いてもらいます。

公開されている調達情報も、比較の材料になります。たとえば、気象庁の資料では、東京国際空港の空港気象ドップラーレーダー業務処理ソフトの設定変更と動作試験が、2025年8月18日に1,782万円（税込）で契約されています。

ただし、これはAODBの新規構築の価格ではありません。機器間接続や専門知識を要する既存システム変更でも、1,000万円台となる事例です（出典：気象庁「落札情報 物品役務調達 随意契約 R7 11月分掲載用」、2025年）。

ソフトウェア以外の費用

運用開始後の費用まで含めた内訳にしておくと、初期見積には現れにくい負担も比べられます。

• 開発・利用：要件定義、業務設計、ライセンス・クラウド、設定、追加開発、連携、移行
• 設備・導入：サーバー、ネットワーク、表示器、端末、現地工事、総合試験、教育、切替
• 運用・保守：年間保守、SLA、駆け付け、予備機、監視、脆弱性対応

表示器や手荷物設備では、端末の調達や設置、配線、現地での夜間作業が、後から加わることがあります。

年間保守は、初期開発費の10〜15%程度を仮置きの目安として見込みます。24時間365日の対応を含めると、さらに高くなる可能性があります。

クラウドは初期費用が低くても、月額や従量の費用が発生します。その額は、空港数や便数、ユーザー数で変わります。データ保持や冗長化、外部通信も、費用に影響します。

初期費用だけでなく、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仕様、コード、設定、ログ、バックアップの取り出し可否
• 契約終了：データ返却、第三者保守、設備変更権限、仕様書、障害協力の条件
• 運用担当：開発PM、空港の業務・IT・設備担当、航空会社・ハンドラー代表
• 障害対応：重大度、切り分け、連絡、駆け付け、原因報告、再発防止の期限

24時間運用の体制は、担当者の経験に加えて、当番表や手順書、訓練記録、監視実績で評価します。

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

発注後のリスクは、技術面だけでなく、関係者の多さと運用停止の影響からも生じます。

要件の抜けや既存仕様の不明、現地試験の不足は、納期や費用に影響します。移行データの不整合や、責任の範囲があいまいなことも、納期と費用に響きます。これらは安全な現場運用にも関わるため、契約前、開発中、切替前に分けて管理します。

要件の膨張と優先順位・変更管理

ヒアリングが進むほど例外処理が増えるため、すべてを初回に含めると範囲が膨らみます。

• 要件分類：必須、法令・安全、業務改善、将来要件
• 初回範囲：AODBやスポット管理など、データの正本に関わる部分を安定させる
• 次段階：分析や高度な自動化は後続の導入範囲に分ける

AIや予測分析を導入する場合は、目的を機能名ではなくKPIで示します。遅延予測の的中率に加えて、誰が結果を確認し、どの判断に使うか、誤りを誰が直すかも決めます。

入力データの欠損や便数が少ない場合を試さずに導入すると、業務に定着しない可能性があります。

移行と切戻しのリハーサル

本番切替後の混乱を防ぐため、移行結果と障害時の判断基準を事前に決めます。

• 対象データ：便、ゲート、スポット、時刻、利用者、権限、設備台帳
• データ照合：移行後の件数と値が一致しているか
• 履歴の扱い：過去データの移行や参照保管、変換できない項目
• 切戻し：旧環境へ戻す条件と期限、手作業、再入力するデータ

繁忙時間を避けるため、移行にかかる時間を実測しておきます。並行稼働の場合は、二重入力を考慮し、正本と変更の反映先を決めます。

本番へ進む前に、切替承認者がリハーサルの結果と未解決の課題を確認します。

よくある質問（FAQ）

答えは、費用だけでなく、空港規模や既存システムとの接続条件によっても変わります。相談の前によく出る質問を、判断の基準とあわせて紹介します。

小規模空港でも空港業務システムを外注できますか？

外注できます。空港全体を一度に刷新せず、効果と範囲が明確な業務から始めます。たとえば、FIDSやスポット管理、作業管理、設備台帳などです。

便数やターミナル数、既存機器、必要な稼働時間を伝えます。そのうえで、クラウド標準機能や既存製品の設定で対応できる範囲を確認します。

RFPが不十分な状態でも見積を依頼できますか？

概算見積は依頼できます。ただし、前提が曖昧なままだと、会社ごとの想定がずれて比較できません。

対象業務や既存システム、連携本数を整理します。端末・表示器、希望時期、24時間運用の要否も伝えます。調査・要件定義と実装の概算は、分けて提示してもらいます。

初回見積には、対象外と不確実な前提を必ず記載してもらいます。

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

単一業務は500万〜1,500万円、単一ターミナル級は1,500万〜5,000万円が計画用の推定です。

AODB・FIDS・RMSを複数部門で統合する場合は、5,000万円〜3億円程度です。公開された相場ではないため、候補の会社すべてに同じRFPを渡します。

金額は、機器や現地工事、外部連携の範囲で変わります。移行や二重化、保守も、金額を左右します。そのため、初期費用と5年TCOを分けて比べます。

委託先は大手SIerと専門ベンダーのどちらがよいですか？

空港の規模と課題によって選びます。複数システムの統合や現地設備、関係者調整が大きい場合、あるいは24時間保守が必要な場合は、大規模SIerや空港実績のある共同体制が候補になります。

特定の業務を短期間で導入するなら、AODBやFIDS、RMS、クラウド運用に強い専門ベンダーも比べます。

会社の規模よりも、担当の実績や現地体制、責任の範囲、データ返却の条件で評価します。

まとめ

発注前に確認する項目

発注前には、対象業務とデータの正本を確認します。既存連携や非機能要件、移行範囲は、しっかり確かめておきます。さらに、保守体制と終了時のデータ返却も見ておきます。

提案書に、対象外や不確実な前提が残っていないかを確認します。業務責任者とIT担当者が、同じ判断基準を持てるようにします。

最初に行う調査とRFP作成

現状が分からないままだと、依頼先ごとに対象範囲や見積の前提がずれてしまいます。

• 調査：現行システムと現場業務を調べ、AODBを中心に正本、対象業務、関係者、連携を整理
• 要件整理：RFPに代替運用、RTO・RPO、セキュリティ、移行、教育、SLA、責任の範囲を記載
• 方式比較：パッケージ・クラウド・ハイブリッド・スクラッチを比べ、標準機能と追加開発を分ける
• 段階契約：調査・要件定義を準委任、確定範囲の実装を請負、運用を保守契約にする

契約を工程ごとに分けると、不確実な作業や仕様変更の影響を管理しやすくなります。

さらに、複数の会社に同じ条件で見積を取り、価格や空港実績、現地試験を比べます。24時間運用とロックイン対策も、比較します。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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