搭乗管理システムは、チェックインから出発確定までを、複数のシステムと現場の担当者がつないで進める仕組みです。DCSの役割、空港業務の流れ、周辺システムとの連携に分けて押さえると、出発業務を止めない要件を整理しやすくなります。
▼関連記事一覧
・搭乗管理システム開発の進め方
・搭乗管理システム開発でおすすめの開発会社6選と選び方
・搭乗管理システム開発の見積相場・費用
・搭乗管理システム開発の発注・外注・委託方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
搭乗管理システムの概要
搭乗管理システムは、航空業界でDCS（Departure Control System、出発管理システム）と呼ばれる領域を中心に構成されるシステムです。
予約情報を受け取って受付を行うだけでなく、搭乗可否や座席、手荷物の処理から、搭乗完了、重量・重心、政府機関への旅客情報送信までを、便単位で連続して扱います。
DCSが担う役割
出発時刻までに旅客情報を確定させるため、DCSは次の状態をまとめて管理します。
- 旅客の状態更新：チェックイン、座席、渡航書類、搭乗ゲートそれぞれの状態を、旅客ごとに管理します。
- 便・旅客情報の一元化：受付の手段がどれであっても、同じ便・旅客の状態として扱います。
確定した情報は、搭乗者名簿やロードコントロールへ引き渡されます。
一般的な業務システムでは、数分単位の遅延が許される場面もあります。一方、搭乗管理では、搭乗締切直前の座席変更やノーショー処理が数秒の差で結果を変えるため、応答性能や同時接続数、再送時の重複排除が要件になります。
停止時に紙や別端末へ切り替え、復旧後に正しく同期できるかどうかも、機能数と同じくらい大切です。
予約・空港運用・手荷物管理との違い
出発処理を成り立たせるには、予約・空港運用・手荷物の管理範囲を区別して、互いに連携させる必要があります。
- PSS（Passenger Service System）：予約、運賃、発券、在庫を担当します。
- AODB（空港運用データベース）：空港全体の便、ゲート、時刻、設備情報を管理する基盤です。
- BRS（Baggage Reconciliation System）：手荷物を旅客と便に照らし合わせる役割です。
- CUSS・CUPPS：共用のセルフチェックイン機と、共用の旅客処理基盤のことです。
搭乗管理システムは、これらの境界をまたいで出発処理を成り立たせる調整役です。
要件定義で「どのシステムが正本か」を決めないまま画面を作ると、座席変更が手荷物側に反映されず、搭乗済みの旅客が別端末では未搭乗に見えるといった不整合が起きることがあります。
便IDや旅客IDは、発行時点と確定値を持つシステムを先に決めておきます。手荷物タグと搭乗券番号についても同じように決めておくと、開発範囲と費用を整理しやすくなります。
搭乗管理システムの全体像と業務フロー
搭乗管理は、旅客が空港に着いてからゲートを通過するまでの短い時間に、多数のシステムと現場の担当者が連携して進める業務です。
業務は、便の準備、旅客受付、手荷物受託の順に進み、保安・渡航確認、搭乗改札、出発確定へと続きます。この流れで見ると、単体の画面よりも状態遷移の設計が中心になることが分かります。
便の準備からチェックインまで
便情報を確定してから受付を始め、本人確認や座席割当を経て搭乗券を発行します。
- 便情報の確定：便と機材の運航情報を固める工程です。
- チェックイン：受付から搭乗券発行までの処理を一続きで行います。
まず便名、運航日、機材を確定します。そのうえで、座席構成と搭乗口、受付と搭乗の締切時刻を決めておきます。運航や機材が変わった場合は、PSSや空港運用情報と同期させ、予定と確定を区別して座席や搭乗口を更新する必要があります。
チェックインは、オンラインとモバイルで受け付けるほか、カウンターとキオスクでも扱います。受付では、予約照合と本人確認、渡航書類の確認を行います。そのうえで、座席の割当やアップグレードも進めます。
特別旅客や乗継旅客も扱います。また、国際線では、出発前旅客情報処理の結果を受けて搭乗可否を再判定します。
予定と確定を区別しないままだと、古い搭乗口や誤った座席を旅客に案内してしまうおそれがあります。
手荷物受託から搭乗完了まで
手荷物を受け付けるときは、手荷物タグを旅客、便、搭乗券と厳密に結び付けます。
- 手荷物の受託：旅客と手荷物の情報を正しく結び付ける段階です。
- 搭乗の判定：有効な搭乗券かどうかを、搭乗状態と突き合わせて判断します。
- 例外処理と出発確定：例外の有無を確認したうえで、出発情報を確定する工程です。
2025年の航空業界団体による「Hold Baggage Reconciliation」資料は、有効な搭乗券を持つ旅客の手荷物を受け入れる考え方を示しています。
その対象は本人確認済みの旅客で、旅客の変更を手荷物側に反映する内容になっています（出典：航空業界団体「Hold Baggage Reconciliation」、2025年）。
搭乗改札では、バーコードやQRコード、ICなどで読み取った内容を使い、搭乗券の有効性と搭乗済みかどうかをリアルタイムに判定します。便と座席も、同じタイミングで照合します。前述の資料では、将来の手段としてデジタルIDや生体認証も挙げられています。
重複スキャンや別便の搭乗券、座席変更後の古い券といった例外に対応します。また、乗継旅客の例外も扱い、異常時には有人確認へ切り替えます。
搭乗後は、確定した情報を搭乗者名簿やノーショー、手荷物照合へ渡します。重量・重心の計算にも渡し、出発処理を完了させます。
手荷物の情報も搭乗ステータスと照合できる形でイベントを残し、両者を一体で扱える設計が必要です。
搭乗管理システムの主な機能と必要な連携
必要な機能は、航空会社の規模や空港数によって変わります。国際線の有無やグランドハンドリングの分担によっても変わります。
画面一覧から始めるより、便当日の業務シナリオと例外処理から機能を洗い出すほうが、現場で使われる範囲と開発対象を整理しやすくなります。
コア機能は便・旅客・手荷物の状態管理
コア機能は、便・旅客・手荷物の状態を矛盾なく更新できることです。管理対象は次の3領域に分かれます。
- 便管理：機材、座席構成、搭乗口、締切時刻、運航変更
- 旅客管理：チェックイン、座席変更、搭乗券再発行、特別対応、乗継、ノーショー
- 手荷物管理：タグ発行、受託、搬送、照合、取り降ろし、再搭載
重量・重心管理を行う場合は、搭乗者数と手荷物重量を基にロードシートを作成します。貨物や機材情報もその計算に用い、変更履歴と承認者を記録します。
計算結果を表示するだけでなく、入力値の出所や再計算の条件、確定後の変更権限まで定めておく必要があります。また、監査ログは「誰が、いつ、どの端末で、何を変更したか」を追える粒度で残します。
PSS・BRS・AODB・端末との連携
予約、搭乗、手荷物の状態をつなぐには、連携先ごとの役割をはっきりさせておく必要があります。
- 基幹情報：PSSから予約・発券・旅客情報を受け取り、搭乗管理側でチェックインや搭乗状態を更新します。
- 手荷物・運航情報：BRSへ照合に必要な情報を渡し、AODBからは便やゲートの運用情報を受け取ります。
- 端末・周辺基盤：CUSSやCUPPS、搭乗ゲートと連携します。スキャナーや電子タグ、重量計、通知基盤も含みます。
連携方式は、APIのほか、標準メッセージやファイル連携、既存のレガシー接続を組み合わせることもあります。その場合は、項目の変換やタイムゾーン、文字コードの扱いを決めます。さらに、再送とタイムアウト、重複排除の決め方も定めます。
通信断から復旧したときは、同じ搭乗イベントを二重に適用しない仕組み、つまり冪等性が特に重要になります。インターフェース仕様書には、正常系だけでなく、遅延や欠損、順序の逆転への対応を書きます。手動訂正のルールも、同じ仕様書に含めます。
搭乗管理システムの種類と選択肢
方式を選ぶときは、初期費用だけでなく、航空標準への追従や障害時の継続性を比べます。加えて、データ移行、空港ごとの展開、将来のベンダー変更まで見ておく必要があります。
費用と納期を安定させるには、標準機能に業務を合わせる範囲と、独自開発する範囲を分けることが大切です。
パッケージ・ホステッド型
パッケージ・ホステッド型は、航空業務の標準機能を活用する方式です。業務を標準機能に合わせられるかどうかで、この方式が候補になるかが決まります。
- 活用できる機能：チェックイン、搭乗、手荷物、重量・重心、政府向け旅客情報など。
- 導入しやすい条件：航空標準や複数空港の知見を使い、標準機能に業務を合わせて段階導入できる場合。
標準機能を使えば、ゼロからの基盤開発を減らせます。一方で、独自の例外処理や帳票、既存システムのデータ構造は、そのまま再現できないことがあります。
契約前には、カスタマイズ費や利用料、旅客・便・処理件数に応じた課金を確認します。さらに、データ返却、障害時の責任範囲、サービス終了時の移行条件も確かめておきます。
クラウド・API連携型
クラウド・API連携型は、既存の基幹サービスに現場向けの機能を追加する方式です。導入時の特徴は、次の2点に分けて見ておきます。
- 追加する機能：現場ポータル、モバイル、通知、分析、運用管理画面。
- 拡張と変更：機能を分けて展開できるほか、APIゲートウェイやイベント連携を使えば、変更の影響がどこまで及ぶかを把握しやすくなります。
基幹のPSSや手荷物サービスを使いながら、空港や業務の広がりに備えられます。
ただし、空港ネットワークや外部サービスは、常に使えるとは限りません。そのため、端末側での一時保存や最低限のローカル処理、再接続後の同期を設計します。認証トークンの失効やデータ暗号化も、あわせて決めておきます。
クラウドを採用しても、現場の通信断が解決したことにはなりません。そのため、オフライン時の業務手順は、必ず実機で確かめます。
部分スクラッチとフルスクラッチ
部分スクラッチとフルスクラッチでは、独自開発する範囲と、自社で担う運用の負担が異なります。
- 部分スクラッチ：コアは標準製品などを使い、現場画面や国内帳票、社内業務、分析機能を個別に開発します。
- フルスクラッチ：業務ルールを細部までシステムに反映できる一方、航空業務基盤の継続運用も自社で担うことになります。
部分スクラッチは、独自性を保ちながら、保安や航空標準の領域を自社だけで抱えずに済みます。そのため、現実的な選択肢になりやすいといえます。
フルスクラッチでは、24時間運用や端末、標準メッセージの処理を継続して担います。手荷物照合も、自社が受け持つ範囲に入ります。重量・重心や制度変更への対応、セキュリティ、障害時のバックアップも自社で行います。
開発費だけでなく、5年程度の保守人材や訓練を含めた総保有コストで比べます。監視や移行、将来の改修も、この中に含めて考えます。
搭乗管理システム開発の進め方
搭乗管理システムは、最初から全空港・全機能を切り替えるより、現場の状態遷移と例外を確かめながら段階的に進めるほうが安全です。
工程は要件定義から始まり、連携設計、Fit＆Gap、PoCを経て、開発と試験に進みます。パイロット、展開、運用改善までを、一つの移行計画として扱います。
現場観察と要件定義
要件定義では、通常運航から障害復旧までの実際の業務を現場で観察し、暗黙の運用も記録します。
- 観察する業務：チェックイン開始から搭乗締切、ノーショー、ゲート変更までの処理です。手荷物取り降ろしと、通信断からの再開も対象です。
- 性能要件：1便あたりの旅客数、ピーク時の同時接続、許容応答時間、稼働時間、RTO・RPO。
- 運用要件：端末の種類、権限、操作ログを決めておきます。データ保持期間、監査帳票、通知、言語、タイムゾーンも含みます。
- 確かめるシナリオ：30分の通信断、搭乗券の再発行、座席変更直後のゲート読取など。
担当者への聞き取りでは、繁忙時の待ち行列や端末の持ち替えが抜けやすくなります。口頭での確認や紙の控えも、見落とされがちです。
実際の便を見て業務イベントと判断条件を記録し、そのシナリオを非機能要件に反映させます。
連携設計とPoC
PoCでは、IDや状態の整合性に加えて、障害時の判断と復旧手順も確かめます。
- 連携の定義：PSSやBRS、AODB、ゲート、端末、重量計、通知基盤のID・状態遷移・正本・再送・手動復旧を決めます。
- 業務判断と責任者：インターフェースごとの担当者を決め、運航変更や通信遅延時の判断も合意します。
- PoCの検証：予約、座席変更、手荷物、搭乗の流れを試します。ノーショーや通信断、復旧同期、ピーク負荷や重複イベント時の整合性も確かめます。
PoCは、1空港や1路線、限定した端末などの範囲で行い、実データに近い予約や手荷物タグを使います。画面の見た目よりも、障害時の振る舞いを優先して確かめる必要があります。
段階移行と運用定着
移行では、切替方法と運用開始後の確認を一つの計画にまとめます。実施事項は、切替、運用、変更管理の3つに分けて整理します。
- 切替準備：機能や空港ごとの稼働、新旧の並行期間、切替日時と切戻し条件を決めます。窓口、教育、訓練便、障害時の紙運用も準備します。
- 運用確認：チェックイン・搭乗時間、照合エラー、再発行、復旧時間、手動処理、問い合わせを、KPIで見ていきます。
- 変更管理：状態遷移や連携ルールを変えるときは、再試験とログ確認を行います。標準や制度の変更に追従するリリース管理も、契約に含めておきます。
ビッグバン切替でも、切戻しの実行可否と旧システムのデータ保持時点は、事前に決めておきます。
現場の声は画面変更で終わらせず、業務ルールを変えるときは、再試験と監査ログの確認まで行います。
▶ 詳細はこちら：搭乗管理システム開発の進め方
搭乗管理システムの費用相場とコスト内訳
搭乗管理システムのDCS単体では、公開された一律の料金表がほとんど見当たりません。
次に示す金額は、2026年時点で公開されている一般的な大規模業務システムの相場を基に、航空業務特有の連携や可用性、現地展開の要件を組み合わせた概算です。
対象空港数や旅客数、既存PSSの条件によって大きく変わります。国際線や手荷物設備、SLAの条件も費用に響くため、確定価格ではありません。
規模別の初期費用と期間の目安
費用と期間は対象範囲や導入規模で変わるため、次の金額は要件から逆算した概算として見てください。
- 調査・PoC：1便・1空港で連携確認まで行う場合、300万〜800万円、2〜4か月が目安です。
- 限定導入：1,500万〜5,000万円、6〜12か月程度が概算レンジです。
- 複数空港展開：5,000万〜2億円、12〜24か月程度になる可能性があります。
- フル刷新：PSS周辺や複数拠点の24時間運用を独自構築する場合、1億〜5億円超、18〜36か月以上も想定します。
限定導入の金額は、パッケージやクラウドを使う場合の目安です。含まれるのは、チェックインや座席、搭乗のほか、基本的な手荷物連携、既存PSSや端末との連携までです。
複数空港展開では、複数事業者との連携やBRS・AODBとの接続、重量・重心が対象です。APIや移行、バックアップDCSも含みます。現場展開まで含めると、この費用・期間になる可能性があります。
RFPには、推定金額の前提条件も併記します。
費用を左右する項目
費用は、画面数よりも接続本数やデータ差異によって左右されます。性能や継続運用、現地展開も影響します。
接続の対象には、PSSやBRS、AODBのほか、CUSSやCUPPSも含まれます。搭乗ゲートや政府システムとの接続も必要になります。
- 連携の複雑さ：接続先の数、データ差異、外部仕様への追従。
- 性能・継続性：ピーク負荷、オフライン・バックアップ、二重運用の要件。
- 現地展開と試験：空港ごとの作業に加え、手荷物照合や重量・重心の試験も費用に影響します。
見積書では、工程の費用と運用の費用を分けて示してもらうと、比べる際の前提がそろいます。工程には、要件定義や設計、開発、テストがあります。移行や端末設定、現地設置も、工程の費用に含めます。運用には、教育、監視、保守、クラウド、ライセンス、従量課金があります。
スキャナーや搭乗ゲート、ネットワークは別途になる場合が多いです。停電対策や現地サポートも別途になることがあるため、初期費用だけで比べないことが重要です。
3〜5年TCOによる比較
比べるときは、初期費用に加えて、運用費と終了時の費用まで含めた3〜5年TCOで見ていきます。確認項目は、次の2つに分けて整理します。
- 継続費用：利用料、従量課金（旅客・便・処理件数）、クラウド、監視が続きます。24時間サポートや端末保守、教育、制度変更対応も含みます。
- 移行・停止リスク：障害時の損失、データ移行、空港追加、解約時のデータ返却費、ベンダー変更費を見込みます。
年間保守費は、初期開発費の10〜15％程度で仮置きする方法もあります。高可用性や現地対応、バックアップを含む場合は上振れするため、契約条件を個別に確認します。
安価な方式が必ず有利とは限りません。停止や誤照合のリスクも金額に置き換えて比べます。
▶ 詳細はこちら：搭乗管理システム開発の見積相場・費用
搭乗管理システムの開発会社・サービスの選び方
選ぶときは、知名度や機能数だけでなく、航空会社や空港運営、グランドハンドリングのどの業務に強いかを確かめます。
製品を提供する事業者と、導入支援を担う事業者、個別開発や端末設置を担う事業者が別々になることもあります。そのため、契約範囲と障害時の責任分界を最初に整理しておきます。
航空業務と同規模の実績の確認
実績は導入社数よりも、自社に近い運用条件と支援範囲で評価します。空港や便数の規模が近いか、障害時にどこまで支えてくれるかが、判断の分かれ目になります。
- 運用実績：空港・便数、国際線、機材、ピーク旅客数を確かめます。手荷物設備、共用端末、役割分担、法域も見ます。
- 障害対応と導入支援：対応記録、切替計画、教育を確認します。連携、移行、端末設置、現地リハーサル、運用引継ぎまで含めます。
- 変更時の条件：標準機能と個別開発の境界、変更単価、リリース頻度、緊急修正の手順。
可能であれば、提案資料に加えて障害対応の記録も確認しておきます。支援範囲や変更条件が曖昧なままだと、契約後に費用と納期が膨らみやすくなります。
提案比較で確認する項目
提案を比べるときは、接続や運用継続、安全性、支援体制に分けて見ると、比べる観点がそろいます。
- 接続性：PSS・BRS・AODB、CUSS・CUPPS、API公開度。
- 継続運用と安全性：オフライン、バックアップ、ピーク負荷、認証、暗号化、監査ログ。
- 支援・復旧条件：国内サポート、SLA、データ保管場所、障害時の復旧目標。
クラウドを使う場合も、空港側のネットワークが止まった間に続けられる現場の処理を確認します。
RFPでは、座席変更直後の搭乗、搭乗券や手荷物タグの再発行を実演してもらいます。ノーショーやゲート変更、通信断、復旧同期、手荷物取り降ろしも対象です。
操作回数と有人介入の有無を記録し、機能があるかどうかだけでなく、実際の対応を比べます。
SLA・データ返却・出口戦略
契約では、障害対応の基準と、契約終了後の移行条件を決めておきます。
- SLA：稼働率や検知、一次回答、復旧を取り決めます。代替運用、重大障害の連絡、保守時間、計画停止、事故報告の期限も含みます。
- 出口条件：データ所有権・標準形式の出力、API仕様書の利用権、独自部分のソース・設計書、移行支援、保存期間。
便の出発に影響する障害と、管理画面だけの障害とで優先度を分けると、運用に合ったSLAになります。導入時に出口を決めておくことは、事業継続性と交渉力を守る基本設計といえます。
▶ 詳細はこちら：搭乗管理システム開発でおすすめの開発会社6選と選び方
搭乗管理システムの発注・外注・委託方法
発注では、システムを作る範囲だけでなく、現場を切り替える責任まで決めておきます。
発注先を一社にまとめるか、複数の専門事業者に分けるかで、管理の負荷と責任分界が変わります。対象には、製品導入や個別開発、端末とネットワークがあります。さらに、データ移行や教育、運用監視も加わります。
RFPに入れるべき項目
RFPでは、提案の範囲と評価の前提をそろえておきます。記載項目は、3つの分類に分けて整理します。
- 対象範囲：空港・便・旅客数、既存システム、機能、端末、ネットワーク、外部連携。
- 性能・運用条件：ピーク性能や稼働時間、RTO・RPOを示します。セキュリティ、監査、移行、教育、保守も含めます。
- 提案・評価条件：納期、予算、評価方法、対象外機能、確認してほしい前提。
デモには、通信断やゲート変更、ノーショー、手荷物取り降ろしを含めます。搭乗券の再発行と復旧後の再同期も入れます。テストデータの提供方法や個人情報のマスキング、現場担当者の参加条件も決めます。
提案書の説明だけでなく、実際の操作と障害対応の再現性を評価します。
請負・準委任と責任分界
契約形態は、成果物と受入条件を定められるか、調査と並行して進めるかで選びます。
- 請負：要件と受入条件を定義できる成果物に適する場合があります。
- 準委任：現場調査や要件整理、調査と並行して進めるPoCが候補になります。
- 複数社委託：発注者が全体設計、接続、障害指揮、変更承認、個人情報管理を統括します。
契約を組み合わせる場合は、工程ごとの完成責任と作業時間の扱いを分けておきます。さらに、障害原因を切り分ける監視・ログの責任は、契約書と運用手順書の両方に記載します。
発注後に起きやすいリスクと対策
発注後のリスクは、仕様の後出しと稼働時の現場混乱に分けて備えます。
- 仕様追加を防ぐ：状態遷移図、境界図、データ項目、エラー処理、受入テストを先に合意します。
- 変更影響を評価する：納期だけでなく、保安、手荷物、監査、切戻しへの影響を確認して承認します。
- 現場訓練と受入確認：繁忙時の模擬運用や通信断、端末交換、手動処理、復旧後照合を行います。性能、エラー、重複、ログ、切戻しも確認の対象です。
説明会で済ませず、稼働日に現場が使えるかを訓練で確かめます。
▶ 詳細はこちら：搭乗管理システム開発の発注・外注・委託方法
セキュリティ・障害対応・2026年の動向
搭乗管理システムは、旅客の個人情報や渡航書類を扱います。そのほか、顔画像や顔特徴データ、手荷物情報、運航情報も対象になります。
便利な機能を追加するほど、利用目的やアクセス権限、委託先、保存期間を一体で設計する必要があります。ログや障害時の代替手段も、同じ設計に含めます。安全性は、業務フローの前提条件として最初から組み込みます。
通信断・停電・DCS障害への備え
障害時は、業務ごとに継続・停止する操作を決め、代替手段と制限を設けます。
- 代替運用：チェックイン・搭乗改札の継続や手荷物受付の停止を業務別に決め、端末、キャッシュ、紙、電話、再入力を用意します。
- オフライン制限：古い座席情報や失効券を受け付けないよう、許可操作と有効期限を限定します。
- 復旧と訓練：イベントを時系列・一意IDで同期し、差分は有人確認へ回します。訓練便や定期演習で手順を検証します。
復旧時にローカル処理を正しく同期できれば、二重搭乗や二重の手荷物登録を防げます。同期できないデータは、自動で上書きしない扱いにします。
生体認証とデジタルIDの考え方
2026年時点では、顔認証は非接触のチェックインや搭乗手段として注目されています。一方、顔画像や顔特徴データは変更が難しく、漏えい時の影響が大きい情報です。
- 安全管理：顔特徴データなどを、アクセス制御や暗号化で保護します。
- 利用者への配慮：目的説明、同意、非利用者の代替手段、保存期間、削除、第三者提供・委託先を定めます。
- データ共有と例外対応：必要な情報だけを選んで共有し、認証に失敗した場合は有人で対応します。
個人情報保護委員会の令和7年7月1日更新Q&Aは、顔特徴データの安全管理措置を示しています。
例として、利用者と責任者の限定や教育が挙げられています。物理・技術的なアクセス制御、アクセスログの監視も含まれます（出典：同委員会「個人情報の保護に関する法律についてのガイドラインに関するQ&A」、2025年）。
IATAのOne IDは、旅客自身によるデータ管理と、必要な情報だけを選んで共有することを重視しています（出典：IATA「One ID」、2026年確認）。
顔認証を入れること自体よりも、本人確認に失敗した場合でも有人対応できる設計を優先します。
モバイル・API・出発前判定の進展
セルフ化が進むほど、空港到着前の判定に加えて、例外旅客を有人窓口へつなぐ運用も必要になります。
- 出発前処理：外部基盤との接続や規制変更に備えます。
- 効果測定：導入前後の業務指標を自社環境で比べます。
- 例外旅客：有人窓口へ引き継ぎ、対応状況も評価します。
公開情報では、出発前旅客情報処理基盤が年間8億件を超えるメッセージを処理します（出典：航空IT事業者「Advance Passenger Processing」公開情報、2026年確認）。
同基盤は、700社を超える航空会社と接続しています（出典：同公開情報、2026年確認）。ただし、自社に同規模の処理が必要とは限りません。
公開事例では、チェックイン処理が最大21％速くなったとの報告があります（出典：DCS製品の公開ページ、2026年確認）。
新人担当者の研修時間も、最大62％減ったという報告があります（出典：同公開ページ、2026年確認）。ただし、この数値は特定の環境での効果で、すべての導入で再現されるとは限りません。
処理速度や手動介入率、教育時間を、導入前後で比べます。障害時の復旧時間も含めて見ておきます。
書類確認や乗継・特別対応が必要な旅客、認証に失敗した人は、有人窓口での対応に切り替えます。例外処理の完了時間、有人介入のしやすさ、旅客への説明責任も、KPIに含めます。
よくある質問（FAQ）
検討の初期には、DCSの範囲や開発期間、クラウドの可否についての質問が多く寄せられます。費用や既存システムとの接続についても、よく質問されます。企画段階で特に確かめたい内容を、簡潔に答えます。
搭乗管理システムとDCSは同じものですか？
完全に同じ意味ではありませんが、搭乗管理システムの中心にDCSが位置付けられることが多いです。
搭乗管理という言葉は、チェックインや搭乗、手荷物、端末、通知などの周辺機能まで含む広い呼び方です。一方、DCSは出発管理の業務基盤を指す専門用語です。
提案依頼では、どこまでを対象にするかを機能一覧と連携図で示します。
搭乗管理システムの開発費用はいくらですか？
調査・PoCは300万〜800万円、限定的な導入は1,500万〜5,000万円が目安です。複数空港への拡張は5,000万〜2億円、フル刷新は1億〜5億円超です。
これらは、連携や端末、移行、オフライン、保守を含む要件から推定したレンジで、DCS固有の公開価格ではありません。旅客数や空港数、既存PSS、SLAをそろえ、複数の見積を比べます。
搭乗管理システムはクラウド化できますか？
クラウド化は可能です。ただし、クラウドを採用しただけで空港業務が止まらなくなるわけではありません。
端末側の一時保存やオフライン時の許可操作、再接続後の同期を設計します。認証や監査ログ、ネットワーク障害時の代替手順も組み込み、実機で検証します。保管場所や委託先、データ返却、障害時の復旧責任も契約で確認します。
開発期間はどのくらいかかりますか？
調査・PoCで2〜4か月、限定的な導入で6〜12か月、複数空港の拡張で12〜24か月、フル刷新で18〜36か月以上が一つの目安です。
要件が固まっているか、既存連携が標準化されているか、並行運用や現地展開が必要かで変わります。開発期間だけでなく、訓練やパイロット、切戻し準備を含む稼働計画で判断します。
まとめ
搭乗管理システムは、チェックイン画面を作る取り組みというより、便・旅客・手荷物の状態を正確につなぎ、出発業務を止めないための基幹整備です。
DCSを中心に、PSS、BRS、AODB、CUSS、CUPPSとの間で、どこまでを誰が受け持つかを決めます。ゲートや重量・重心、政府向け旅客情報との境界も含めて決めておくと、要件と費用の見通しが立てやすくなります。
導入で押さえるポイント
方式は、標準化できる範囲と独自業務の量を比べて選びます。既存資産やオフライン要件、将来の拡張性も含めて見ます。費用の推定レンジは、調査・PoCで300万〜800万円、限定導入で1,500万〜5,000万円です。
複数空港の拡張は5,000万〜2億円、フル刷新は1億〜5億円超です。端末、連携、移行、保守を含む3〜5年TCOで判断します。
失敗を防ぐ最後の確認
導入前の最終確認では、障害・例外試験と個人情報の扱いを受入条件に含めます。
- 受入テスト：通信断、ノーショー、ゲート変更、手荷物取り降ろし、搭乗券再発行、復旧後の再同期。
- 生体認証・デジタルID：同意、代替手段、データ最小化、保存期間、アクセスログ、有人確認。
機能の多さよりも、現場が使いやすく、障害から復旧でき、将来の移行にも耐えられることを優先します。
▼関連記事一覧
・搭乗管理システム開発の進め方
・搭乗管理システム開発でおすすめの開発会社6選と選び方
・搭乗管理システム開発の見積相場・費用
・搭乗管理システム開発の発注・外注・委託方法
▼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を創業。