搭乗管理システムの発注・外注では、便・旅客・手荷物の状態を安全に一致させるDCS（出発管理システム）を、既存の予約・発券や空港設備と一体で設計します。
業務範囲と発注形態を決め、RFPで要件を示し、契約形態と見積を比べて委託先を選ぶ流れで進みます。
▼全体ガイドの記事
・搭乗管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
搭乗管理システムの概要と発注前に決める範囲
搭乗管理システムは、航空業界でいうDCS（Departure Control System）を中心に、出発業務を支える基盤です。予約・発券を担うPSS、手荷物管理のBRS、空港運用データベースのAODBなどと接続します。
共用端末のCUSS・CUPPS、搭乗ゲート、重量・重心管理とも連携し、チェックインから出発までの状態を更新します。そのため、発注時は機能だけでなく、各システムがどのデータの正本を持つかも決めておく必要があります。
機能一覧より先に決める業務の境界
発注対象に含める業務は、次のとおりです。画面数だけで範囲を決めると、各判定を担うシステムが抜けやすいため、判定を担うシステムも併せて定義します。
- 出発準備：便の出発計画
- 搭乗手続き：オンライン・カウンター・キオスクでのチェックイン、座席変更、搭乗券発行、搭乗改札、ノーショー判定
- 手荷物と重量：手荷物タグの紐付け、搭乗者名簿、重量・重心計算
- 例外と国際線：遅延・ゲート変更などへの対応、国際線でのAPP・iAPIや渡航書類の確認
業務の境界が曖昧だと、どこまでを誰が受け持つかが不明確になり、追加費用が発生しやすくなります。たとえば、手荷物の搭載可否を誰が確定するかは、発注資料に明記しておきます。
便・旅客・手荷物の状態遷移は、簡単な時系列にして示します。チェックイン済み、手荷物受付済み、搭乗口到着、搭乗済み、搭乗締切後といった状態を、その時系列の上で定義します。
座席変更、乗継失敗、搭乗拒否、手荷物の取り降ろしの場面で、どのシステムがイベントを発行するかも書いておきます。そのうえで、連携と例外処理を含む見積もりを依頼します。
「止まらない・間違えない・戻せる」を求める非機能要件
機能要件と合わせて、運用と復旧に関する条件もRFPに記載します。ピーク時の同時接続数や、スキャンから判定までの許容時間も、数値で定めておきます。
- 継続性：障害時のRTO・RPO、ネットワーク断でも続ける業務、復旧後の再同期
- 運用管理：操作ログ、権限、監視、バックアップ、24時間365日のサポート時間
- 生体認証：データの保存・削除、利用目的の通知、使わない旅客の代替手段
オフライン時の二重搭乗や二重手荷物登録が起きないことは、実データに近い試験で確かめます。安全性は、デモの見栄えではなく、この試験の結果で判断します。
個人情報保護委員会の2025年7月更新Q&Aは、本人を判別できる写真画像や顔特徴データについて、利用目的、安全管理、保有期間などの検討を求めています。IATA One IDも、旅客の同意と必要最小限の情報の選択的な開示を重視しています。そのため、生体認証を導入する場合は、こうした扱いを含めて要件を整理します。
搭乗管理システムの発注形態の選び方
標準業務が多い企業には、DCS製品を中心に据え、独自業務や既存システムとの間を個別開発で補う方式が現実的です。方式は、標準に合わせられる範囲と、譲れない差別化部分の大きさで選びます。
すべてを新規開発すれば、自由度は上がります。一方で、航空標準や端末、保安への対応も発注者の負担になります。さらに、24時間運用や制度変更への対応も、発注者が担うことになります。
標準業務に合わせやすい企業向けのパッケージ・ホステッド型
パッケージやホステッド型は、航空業務の標準機能を短期間で組み込みたい場合の候補です。製品例にはAmadeus Altéa DCSやSITA Maestroがあります。
- 業務機能：チェックイン、搭乗、旅客情報の送信への対応
- 運用機能：セルフサービスや障害時の継続運用への対応
- 提供形態：SITA公式情報では、クラウドとオンプレミスの展開、APP・iAPI、障害時のオフライン継続性が説明されています。
製品ページの処理速度や教育時間の改善値は、ベンダーが示した値です。自社の空港や便種で再現できるかは、PoCで確かめる必要があります。
標準機能とカスタマイズの線引き、API公開度、従量課金の単位は、見積の前に委託先へ確かめます。端末や現地設置の責任、データ返却、契約終了後の移行支援も、聞いておきます。
複数の航空会社を扱う空港やグランドハンドラーでは、共用端末や複数キャリアの切替を実演してもらいます。
国内帳票や手動承認は、別システムで補う場合もあります。そのため、製品ベンダーと導入支援会社の役割を分けて見積もり、製品導入後に必要となる周辺業務の費用も把握します。
既存資産を活かすクラウド連携・部分スクラッチ方式
既存のPSSやBRSを使い、現場ポータルや運航状況を見える化する画面を開発すれば、全面刷新のリスクを抑えやすくなります。対象は、通知、モバイル、管理者画面にも広げられます。APIがあれば連携できると判断する前に、連携項目や再送規則も確かめます。
- 識別情報：旅客ID、便ID、手荷物タグ、座席、時刻
- イベント処理：再送規則、エラー時の手動復旧
- 技術資料：API仕様に加えて、サンプルデータと異常系レスポンスを開示できるかどうか
フルスクラッチが向くのは、既存製品で表現できない業務が競争力に直結し、長期の開発・保守体制を持てる企業です。ただし、航空標準への追従や空港設備との接続も、継続して必要になります。
全面刷新を最初から決めず、1空港・1路線・限定端末でPoCを行います。運用上の差分を確かめてから対象範囲を広げれば、発注の失敗を減らせます。
RFPと要件整理の進め方
RFPは、発注者の業務課題を示し、委託先から比較可能な提案を求めるための文書です。機能一覧を並べた依頼書とは、目的が異なります。
通常日の流れに加えて、遅延、欠航、ノーショーの場面を押さえます。さらに、乗継失敗、ゲート変更、手荷物不一致も対象にします。また、通信断、停電、DCS切替の場面も含めます。
RFPに記載する現状・範囲・数値・例外
RFPの冒頭には、対象や現状、導入条件を記載します。範囲と実現方法も示しておくと、各社の提案を同じ条件で比べられます。
- 対象と目的：航空会社、空港、路線、便数、現行システム、利用者、導入目的
- 導入条件：希望時期と予算の考え方
- 業務範囲：チェックイン、座席、手荷物、搭乗、重量・重心、政府連携、通知、監査、管理画面
- 実現方法：「必須」「できれば」「対象外」の区分を付けたうえで、標準機能・設定・追加開発・別製品のどれかを回答してもらう
数値には、1便あたりの旅客数、ピーク時の同時操作数、端末台数を含めます。さらに、1日の便数と許容応答時間も示します。
稼働率、保守時間、データ保持期間は、運用の前提となる数値です。また、復旧目標と切替対象空港数も、数値で示します。
実数が未確定の場合は、最小・標準・最大の3ケースで提示します。数値がないRFPでは、各社が異なる前提で見積もるため、価格と納期を比べられません。
RFPに含める受入条件と障害時の手順
納品物には、ソースコードや画面のほか、設計、移行、端末に関する成果物が含まれます。運用、教育、テストの成果物も、RFPに明記します。
- 設計と移行：業務フロー、基本・詳細設計、API仕様、データ移行計画
- 運用と教育：端末設定、運用手順、監視設計、教育資料、障害連絡網
- 試験と復旧：テスト計画、切戻し手順、データ辞書
- 手荷物照合：未搭乗旅客の手荷物を検知し、取り降ろし判断につなげるシナリオ
IATAの2025年資料では、本人確認済みの旅客と有効な搭乗券による手荷物受付が、確認項目になっています。さらに、手荷物と搭乗者の追跡・照合も対象に入っています。
受入テストには、正常系だけでなく、通信断でのチェックイン、搭乗券の二重読取、座席変更直後の読取も含めます。手荷物登録後のノーショーや、復旧後のイベント再送も試します。合否は、期待する状態、ログ、再処理の結果で判定します。
契約形態と開発プロセスの使い分け
要件が固まった部分は請負に、現場調査や要件定義のように検討中の部分は準委任に分けます。全工程を一括請負にすると、未確定の連携条件や業務差分が後から変更費用になりやすいため、この分け方が使いやすくなります。契約方式は、価格の安さよりも、要件の確定度と変更の起こりやすさで決めます。
準委任・請負・ライセンス契約の役割の違い
業務の性質によって、何を任せ、何を受け取るかが契約ごとに異なります。
- 準委任：専門家の知見や作業時間を得ながら、発注者と要件を固める段階を担います。
- 請負：合意した仕様と成果物を、期限内に完成させる開発・テストが対象です。
- 製品利用：DCS製品のライセンス、クラウド利用、保守、端末、現地作業の契約が関わります。
契約書では、成果物の検査方法、未達時の扱い、知的財産権を確認します。再委託や秘密情報、個人データの委託も、確かめておく項目です。契約が終わるときのデータ返却は、契約書に書いておきます。
外部サービスや端末会社を手配する場合は、一次窓口を決めておきます。一次窓口が定まらないと、PSS、DCS、空港ネットワークのどこに原因があるか切り分けられず、便の出発時に連絡がたらい回しになります。
SLAには稼働率に加えて、重大障害の受付時間、初動時間、暫定復旧を記載します。恒久対応や現地派遣の扱いも、SLAに含めます。月次報告と訓練の頻度も、同じ文書に入れます。
PoCから段階導入までの流れと切戻し条件
導入は、PoCで確かめた範囲から段階的に広げていきます。どの順で広げ、どの条件で手作業へ戻すかは、あらかじめ決めておきます。
- 現場観察、要件定義、製品のFit&Gap、連携設計の順で進めます。
- PoC、基本設計、開発・設定、総合テスト、現場訓練、限定運用を経て、段階展開します。
- PoCは1空港・1路線・限られた端末で行い、ピーク時の処理速度、座席変更、手荷物照合を見ます。
- 通信断と復旧後の再同期も試し、画面確認にとどまらず、実運用のリスクと追加費用を早期に洗い出します。
- 複数空港では空港単位か機能単位で切り替え、新旧システムの並行期間と手作業へ戻す条件を決めます。
- 旧システムへ戻す時刻と未送信イベントの扱い、現場責任者の判断権限を、事前に定めておきます。
- 切戻し条件は、搭乗判定の遅延、未照合手荷物、再同期失敗、重大ログ欠落などを、数値や状態で定義します。
搭乗管理システムの費用相場と見積内訳
DCS単体の公開価格は少ないため、次の金額は発注前の概算です。一般的な大規模業務システムの2026年公開相場に、航空業務固有の連携と可用性の要件を加えて示しています。
- 調査・小規模PoC：300万〜800万円が目安です。
- 限定連携を含む導入：パッケージまたはクラウドで1,500万〜5,000万円が目安です。
- 複数空港・複数キャリア：5,000万〜2億円が目安です。
- 基幹の全面刷新：フルスクラッチで1億〜5億円超が目安です。
いずれも目安の数字です。対象範囲と前提条件をそろえて、個別見積を取ります。
画面数より連携と運用条件で決まる費用
見積額に効いてくるのは、次の点です。
- 連携先：PSS、BRS、AODB、W&B、CUSS・CUPPS、ゲート設備、政府システムとの接続本数
- 導入環境：空港ごとの業務差、現地設置、端末・スキャナー、ネットワーク、移行データの品質、二重運用
- 運用と障害対応：オフライン継続性や24時間365日の監視・サポートの影響
2026年公開の一般的な開発費の解説では、大規模業務システムは800万円から数千万円規模とされています。この記事の金額は、その公開相場にDCS要件を加えた推定です。
ただし、航空会社向けDCSには、端末、手荷物、重量・重心が含まれます。国際線連携や現場展開もあるため、この相場をそのまま適用できません。通信断時のローカル処理と復旧後の重複排除は、画面開発だけでなく、状態管理と運用設計の工数になります。
開発費と製品利用料を分けて、同じ前提で比べます。
初期費用だけでなく3〜5年のTCOでの比較
初期費用だけでなく、年間費用と契約終了時の負担まで含めた3〜5年の総額で、各社を比べます。
- 利用・基盤費：ライセンス、SaaS、旅客・便・トランザクション単位の従量料金、クラウド
- 運用・継続費：監視、保守、ヘルプデスク、端末保守、現地対応
- サポート条件：航空向けの24時間サポートや端末保守を含むと保守費が上振れするため、契約条件の確かめが欠かせません。
- 見積内訳：初期、移行、導入支援、現地展開、端末、外部サービス、月額、従量、保守、追加改修の別で分けて提示
- 出口費用：障害時の現地派遣、データ返却、契約終了時の移行が別料金かどうか。1年目に加えて、3年目・5年目の累計とベンダー変更費も比べます。
年間費用には、制度変更への改修や教育、訓練を含めます。バックアップ環境も含めて考えます。初期開発費の10〜15％を、保守費の仮置きとする方法もあります。
委託先の選定と見積比較で確認するポイント
委託先は、知名度や機能数よりも、自社に近い運用条件で安定稼働させた経験をもとに選びます。各社の役割と再委託の範囲も確かめます。
DCS製品ベンダーと航空業務に強いSI会社では、役割が異なります。空港設備会社やグランドハンドリング会社との分担も、考える必要があります。1社にまとめる場合も、どこまでを自社が担当し、どこからを再委託するかを、提案書と契約書に明記します。
同規模・同設備・障害対応まで見る実績の確認
運用との適合性は、「航空業界の導入実績」の有無より、対象規模や設備、障害時の対応で判断します。提案の場では、それぞれを具体的に聞いておきます。
- 対象規模：空港数、便数、旅客数、国際線の有無
- 接続と継続性：PSS・BRS・AODB、CUSS・CUPPS、ゲート設備、オフライン運用
- 移行体制：バックアップDCSや段階移行の有無
- 障害対応：直近の障害件数、初動時間、復旧方法、教育、リリース時の影響を利用者に尋ねる
守秘義務で詳細を聞けない場合は、匿名化した運用指標を提示できるかを確かめます。デモでは、通常のチェックインよりも座席変更、手荷物登録後のノーショー、搭乗券の二重読取を見ます。
ゲート変更や通信断からの復旧を、実際に操作してもらいます。手作業での再処理と監査ログの検索も見ておきます。提示したシナリオの再現力から、要件理解と現場対応力を評価できます。
同じ前提・同じ成果物にそろえた見積の比較
比較表では、工程ごとの金額と成果物を並べます。標準機能と追加開発、APIの前提、発注者が用意するデータは、分けて書いてもらいます。
- 費用と成果物：要件定義、設計、開発・設定、連携、端末、移行、テスト、教育、現地展開、保守の各工程
- 前提と追加費用：APIの有無、発注者が用意するデータ、別途費用の扱い
- 納期と変更：納期のクリティカルパス、未確定項目、変更時の単価・見積ルール
評価は、価格と要件適合、連携・技術の観点で分けます。航空実績や非機能も、観点に加えます。移行・教育、サポート、契約・出口条件も、並べて見ます。
航空業務では、手荷物照合やオフライン継続、ピーク時性能を重く評価します。切戻しと、障害時の受け持ち範囲も、評価の中心に置きます。画面開発の安さだけで判断すると、航空業務の要件を外しやすくなります。
IATAの2025年グローバル・バゲージ・ロードマップでは、旅行者の81％が追跡改善を望み、74％がモバイルのリアルタイム更新を期待すると紹介されています。同資料では、67％が電子手荷物タグに前向きとされています。将来の追跡や通知を見据えたデータ設計も、評価の材料になります。
搭乗管理システムの発注でよくある質問
発注前によくある疑問を、順に取り上げます。一般的な業務システムと同じ考え方で進めると、連携や障害時の条件が抜けやすくなります。
回答を自社の状況に置き換え、RFPや社内稟議の確認項目にしてください。
搭乗管理システムの開発費用はいくらですか？
概算の目安は、調査・PoCが300万〜800万円、限定的なパッケージ・クラウド導入が1,500万〜5,000万円です。複数空港への拡張では5,000万〜2億円、フル刷新では1億〜5億円超が目安になります。
DCS固有の公開価格がないため、この金額は、一般的な大規模業務システムの公開相場に要件を加えた推定です。加えた要件には、PSS連携や手荷物、端末が含まれます。さらに、オフラインや移行も対象です。
費用は、旅客数や便数、空港数で変わります。既存システムやSLAの条件でも変わるため、RFPの条件をそろえて個別見積を取ります。
パッケージ導入とスクラッチ開発はどちらがよいですか？
標準的なチェックインや搭乗、手荷物を短期間で安定させたい場合は、DCSパッケージやホステッド型が向きます。政府連携も、この対象に含まれます。
独自業務が競争力に直結する場合は、コア機能は製品を使い、独自業務の画面やワークフローを部分開発で補います。
フルスクラッチは自由度が高い一方で、航空標準や24時間運用、設備への対応が必要です。さらに、制度変更や保守人材への継続対応も求められます。
生体認証を搭載する場合に何を確認すべきですか？
利用目的と同意、代替手段を確認します。顔画像・顔特徴データの保存期間も、確認項目に入れます。委託先・再委託先、アクセス権限、暗号化の扱いも見ます。
誤認時の有人確認と、利用停止や削除の手順も定めます。IATA One IDは、旅客がデータを管理し、必要な情報だけ選択して共有する考え方を示しています。
利便性を優先して顔画像を中央に集めるのではなく、業務上必要なデータを最小限にします。非生体の搭乗方法も、選べる形で残します。
通信障害が起きても搭乗業務は続けられますか？
製品や構成によりますが、オフライン端末、ローカル処理、バックアップDCSを用意し、復旧後に安全に再同期する設計は可能です。
継続できる業務、端末へ事前配布する情報、重複イベントの排除方法を決めます。RFPと受入テストで、通信断の時間や許容する手作業を具体化します。
再同期の合否の基準も定めたうえで、委託先の説明を実機で確かめてください。
まとめ：業務・連携・出口まで含めた発注の設計
発注前にDCSの範囲を定め、PSS、BRS、AODBとの役割分担を決めます。さらに、共用端末、ゲート、重量・重心との分担も決めておきます。
方式は、標準適合度や独自性から選びます。運用体制と出口条件も、判断の材料にします。
RFPには、通常業務だけでなく、通信断やノーショー、手荷物不一致のシナリオも含めます。復旧や切戻しの場面も、RFPに盛り込みます。
費用は、初期開発費だけでなく、3〜5年のTCOで比べます。ライセンスや従量課金、端末を含め、現地展開まで見ます。
移行や教育、保守の費用も、同じ総額に入れます。加えて、24時間サポートも対象に含めます。
委託先には、同規模・同設備での実績と、障害時の初動を確認します。オフライン運用やデータ返却、ベンダー変更時の支援も、見ておきます。
要件定義やRFP作成時から航空業務とシステム連携を理解するパートナーを加えると、見積の抜けや導入後の手戻りを抑えやすくなります。
▼全体ガイドの記事
・搭乗管理システム開発の完全ガイド
▼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を創業。