搭乗管理システムの開発は、現場観察、連携設計、限定検証、段階導入の順に進めると、安全な運用につながります。
発注側の担当者が打ち合わせで確認しやすいよう、全体像、開発の流れ、費用相場、見積もりの確認点の順に説明します。全体像は搭乗管理システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・搭乗管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
搭乗管理システム開発の全体像
搭乗管理システムは、航空業界でいうDCS（Departure Control System、出発管理システム）を中心に構成されます。また、旅客の受付から出発までの状態をまとめて管理し、複数のシステムや空港設備に正しい情報を伝えます。こうした役割を持つ点で、搭乗管理システムは一般的な予約管理システムとは異なります。
DCSの役割
DCSは便ごとの出発計画を作り、チェックイン、座席割り当て、搭乗券の有効性を管理します。搭乗完了、搭乗者名簿、ロードコントロールも扱い、搭乗券の発行は管理範囲の一部です。
- 受付チャネル：オンライン、カウンター、キオスク、モバイル、搭乗ゲートごとに変わる旅客の状態。
- 搭乗判定：搭乗口で重複スキャンが起きても、チェックイン済み旅客の再搭乗を防ぐ判定。
- 手荷物確認：ノーショー旅客の手荷物が積載済みの場合の取り降ろし。
連携するシステムと設備
連携先は、旅客・手荷物・空港運用のシステムに加え、空港設備や運航系の情報にも及びます。
- 業務システム：予約・発券のPSS、手荷物管理のBRS、空港運用情報のAODB。
- 旅客処理設備：共用チェックイン機のCUSS、共用処理基盤のCUPPS、搭乗ゲート。
- 手荷物設備：手荷物タグ、電子タグ。
- 運航・通知：重量・重心計算、運航管理、通知基盤。
- 国際線：渡航書類やビザの確認、政府システムへのAPI／iAPI連携。
要件定義の段階では、データごとの正本（source of truth）を決めておきます。たとえば、予約情報はPSS、搭乗状態はDCS、手荷物の搬送状態はBRSを正本とするかを、あらかじめ明確にします。
連携項目と更新タイミングを決めておきます。そのうえで、再送方法や重複排除、手動での復旧手順も同じ段階で定めます。
連携条件を先に明確にすると、システム間で同じ旅客の状態が食い違う事態を避けられます。後工程での手戻りも、その分減らせます。
搭乗管理システム開発の進め方・やり方・流れ
搭乗管理システムの開発は、現場観察から運用の定着まで、順を追って進めます。早い段階で、便当日の業務シナリオを再現しておくことが重要です。
- 現場観察と要件定義。
- 連携とデータの設計、方式の選定。
- PoCによる実現性の確認と開発。
- テスト後の段階導入と運用の定着。
通信断、欠航、遅延といった運航の乱れは、初期の検討対象に含めます。ゲート変更、乗継失敗、オーバーブッキング、ノーショーについても、同じ段階で洗い出します。
現場観察と要件定義
要件定義では、チェックイン開始から搭乗締切、出発後のメッセージ送信までを時系列で示します。そのうえで、関係者ごとの担当業務も一覧にします。
- 参加者：空港運営、航空会社、グランドハンドリング、旅客サービス担当、手荷物担当、運航担当。
- 利用場面：幼児連れ、車いす利用者、乗継旅客、特別食。
- 例外ケース：渡航書類不備、座席変更、搭乗口変更。
業務フローでは、誰がどの端末で何を判断するかも明らかにします。通常の旅客以外のケースも含めておけば、現場の例外処理を把握できます。
機能要件と同時に、非機能要件も決めておきます。旅客数やピーク時の接続数、応答時間に加えて、復旧目標のRTOと許容データ損失のRPOも定義します。
端末の種類、ログ保存期間、権限分離、データ保管場所も明記します。要件が曖昧なまま見積もると、バックアップや監視が後から加わり、費用と納期が変わります。
連携設計とPoCによる実現性の確認
連携設計では、データ項目だけでなく、状態が変わるときの処理も決めておきます。連携先は、PSSやBRS、AODBといった業務システムから、CUSS、CUPPS、ゲート設備まで広がります。
- 再発行：古い搭乗券のバーコードの扱い。
- 重複イベント：同じ通知を二度処理しないための冪等性の定め。
- 通信復旧：端末とクラウドのどちらを正とするか。
便・旅客・手荷物の状態遷移図と、連携エラー時の運用フローは、開発側に作って渡してもらいます。運用条件まで定めるには、データ項目の対応表だけでは足りず、この2つが要ります。
方式は、パッケージ／ホステッド、クラウドとAPI連携、部分スクラッチ、フルスクラッチを比べて選びます。部分スクラッチは、標準の部分と独自に作る部分のバランスを取りやすい方式です。
たとえば、DCSのコアには航空向けの製品を使い、現場画面や日本固有の帳票、通知、分析を個別に開発します。一方で、既存のPSSを使い続けるなら、周辺機能をAPIで追加する方が移行リスクを抑えられる可能性があります。
PoCでは、1空港、1路線、限定端末と、実データに近い便情報を使います。機能を並べて見せるだけのデモより、実運用に近い条件で試すことが大切です。
ピーク時の負荷や締切直前の連続スキャン、通信断と再接続を確かめます。加えて、座席変更、ノーショー後の手荷物照合、ロードシートの再計算も試します。
テスト・段階導入・運用設計
開発後は、単体テストと連携テストに加えて、空港全体の業務シナリオで受入テストを行います。受入テストでは、現場担当者が実際の手順で操作します。
- 旅客と手荷物：搭乗券の二重利用や不搭乗旅客の手荷物。
- 運航変更：ゲート変更や遅延による振替。
- 障害：外部応答の遅延、端末故障、クラウド障害。
合否は、画面の表示が正しいかどうかよりも、旅客を滞留させず、誤搭乗や手荷物の不整合を防げるかで決めます。
一例として、SITAの公開情報には、DCS障害時に別処理へ切り替えて出発便を継続する機能があります（出典：SITA「SITA Maestro」の公開情報）。さらに、同じ公開情報では、クラウド・オンプレミスの選択肢、APP／iAPIへの対応も示されています（出典：SITA「SITA Maestro」の公開情報）。
自社で開発する場合も、ホストDCS停止時のバックアップ、端末内の安全な一時保存、復旧後の再同期、二重登録の防止を要件に含めます。これらは、空港業務を止めないための設計条件です。
本番移行は、空港単位か機能単位で段階的に行います。その際、新旧の並行期間、切替可能時刻、切戻しの判断者を決めておきます。紙や手動端末による代替手順と、現場教育の完了条件も定めます。
繁忙期の直前に全空港を一斉に切り替える方式は、障害時の影響範囲が広くなります。
稼働後のSLAや監視、インシデント対応、年次訓練、標準変更への追従も、計画に入れておきます。また、ベンダーを変更するときのデータ返却も、運用に含めます。
搭乗管理システムの費用相場とコストの内訳
DCS単体の公開価格は、ほとんどありません。そのため、以下の金額は、2026年時点の大規模業務システムの公開相場に、DCS固有の連携・可用性要件を組み合わせた概算です。
一般的な開発相場を参考にした推定であり、航空会社全体の刷新に当てはまる確定価格ではない点に注意してください。
規模別の初期費用と開発期間の目安
規模が広がるほど、初期費用も期間も増えます。各金額は対象範囲が違うので、対象ごとに分けて見ます。
- 調査・要件定義・小規模PoC：300万〜800万円、2〜4か月。
- 限定的な標準導入：1,500万〜5,000万円、6〜12か月。
- 複数空港・複数キャリア展開：5,000万〜2億円、12〜24か月。
- PSS周辺を含むフル刷新：1億〜5億円超、18〜36か月以上。
小規模PoCは、1空港や1路線で業務フロー、連携、通信断時の処理を確かめる段階です。ただし、本番用の全機能は含みません。
限定的な標準導入は、標準的なパッケージやクラウドを導入し、機能を限定して整備する場合が対象です。この範囲では、チェックイン、座席、搭乗、基本的な手荷物、PSS・端末連携を整備します。
複数空港の展開では、BRSやAODB、重量・重心、APIまで含む可能性があります。さらに、移行、バックアップDCS、現地教育まで入ることもあります。
フル刷新の金額は、公開されたDCSの料金ではなく、要件の複雑さを踏まえた推定値です。そのうえで、一般的な開発相場と個別要件を分けて検討します。
費用を左右するのは、画面数よりも、連携本数、空港やハンドラーごとの業務差、オフライン処理、手荷物・重量重心のテストなどです。さらに、政府連携や生体認証、二重運用、24時間365日のサポートも、費用に影響します。このほか、空港数、旅客数、既存PSSとの接続、手荷物設備、端末、法域、SLA、移行方式によっても、費用は変わります。
同じチェックイン機能でも、固定端末だけを対象にするのか、複数空港の共用端末やモバイルまで含めるのかで、工数は変わります。また、認証や監視、障害対応に必要な工数も、対象端末によって違ってきます。
初期費用以外にかかるコスト
端末、バーコードリーダー、搭乗ゲート、プリンターなどは、初期費用に含まれないことがあります。初期費用と運用費は分けて比べ、見積書の「一式」という表記があれば、数量と保守範囲を示してもらいます。
- 利用・基盤：SaaSやホステッド利用料、便・旅客・トランザクション単位の従量課金、クラウド。
- 運用：監視、保守、現地サポート、セキュリティ対応。
- 設備：端末、バーコードリーダー、搭乗ゲート、プリンター。
- 導入：回線、設置、教育、予備機。
年間保守費は、初期開発費の10〜15％程度で仮置きする方法もあります。ただし、あくまで予算検討の出発点です。
航空業務向けの24時間サポートや空港現地対応、端末交換、障害時の代替運用を含む場合は、金額が上振れすることがあります。
導入を判断するときは、1年目の初期費用だけでなく、3〜5年のTCOや、繁忙期に停止した場合の損失、移行費、将来のベンダー変更費まで並べて比べます。
搭乗管理システムの見積もりを取る際のポイント
見積もりの精度を高めるには、便当日のシナリオ、連携先、障害時の手順、移行範囲、保守条件を整理しておく必要があります。提案会社ごとに対象範囲が異なるため、同じ条件で比べられるRFPを準備します。
要件とRFPに入れる項目
RFPでは、対象範囲と機能をはっきり示します。さらに、処理量や接続条件も提示して、各社が同じ前提で見積もれるようにします。
- 対象と規模：航空会社、空港、ターミナル、便数、旅客数。
- 運用条件：運用時間、ピーク時の処理量。
- 機能：便・出発計画、チェックイン、座席、搭乗券、手荷物受付・照合、ゲート。
- 追加機能：重量・重心、渡航書類、例外処理、通知、帳票、監査ログ。
- 接続条件：PSS、BRS、AODB、CUSS、CUPPS、ゲート、回線、クラウド。
非機能要件には、可用性、応答時間、同時接続数、RTO、RPOを含めます。さらに、暗号化や権限管理、脆弱性対応も盛り込みます。ログ保存、バックアップ、監視、サポート時間も明記します。
生体認証を使う場合は、同意、目的、代替手段、顔画像や顔特徴データの保存期間を定めておきます。加えて、第三者提供や委託先、誤認時の有人確認、利用停止の手順も記載します。
個人情報保護委員会は、顔特徴データ等について、アクセス制御、漏えい防止、アクセスログの取得・分析を示しています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドラインに関するQ&A」、2025年）。
複数社の比較と役割分担
比較の相手には、DCS製品ベンダー、航空業務に強いSI、空港設備会社、現場運用会社が含まれます。製品と個別SIでは契約範囲が分かれることがあるため、比べる際には範囲をそろえて見る必要があります。
提案書には、どの会社が機能、設備、データ、障害対応を担うかを、図で示してもらいます。
- 実績と接続：同規模・同じ機材・同じ空港設備での稼働実績、PSS／BRS／AODB、CUSS／CUPPS対応。
- 継続性：オフライン、バックアップ、API、国内サポート、SLA。
- 契約と費用：セキュリティ認証、移行方法、3〜5年TCO、終了時のデータ返却。
導入社数や知名度だけでなく、自社に似た障害からどう復旧したかを確かめます。
提案の場では、機能一覧だけでなく、実演を依頼します。実演では、現場担当者が操作し、所要時間と判断の迷いも記録します。
特に、通信断中にチェックインや搭乗を続けられるか、復旧後に二重処理を防げるか、ノーショー手荷物を照合できるかを確かめます。加えて、ゲート変更の反映やロードシートの再計算も見ておきます。
見積もりの抜け漏れと契約上のリスク
費用項目は分けて示し、契約方式は、何を納めるかと責任の境界に合わせて選びます。要件が固まる前に全機能を請負契約で固定すると、変更管理に不明点が集中します。
- 見積項目：開発、ライセンス、従量課金、端末、回線。
- 導入項目：移行、教育、現地展開。
- 運用項目：保守、監視、障害対応。
調査や要件定義は準委任、仕様が確定したあとの開発は請負とする方法があります。実際の納品物や責任の境界を踏まえて、契約を検討します。
障害時の責任、復旧目標、連絡体制、第三者サービス停止時の代替策は、契約で確かめておきます。さらに、事故報告の期限や、データの所有権、ログの保管、終了時の返却も対象になります。
クラウドや海外サービスでは、保管場所、委託先、サブプロセッサー、国外移転、窓口の時間帯も確かめます。
生体認証は、導入すれば必ず処理が速くなるとは限りません。なお、IATA調査では空港での利用者が50％、利用者満足度が85％でした（出典：IATA「2025 Global Passenger Survey」、2025年）。
生体情報を共有したくない旅客の42％は、プライバシーが保証されれば考え直す可能性があると回答しています（出典：IATA「2025 Global Passenger Survey」、2025年）。
導入時は、同意しない人に向けて、有人カウンターなどを用意します。利便性と利用者の選択権を両立させるための備えです。
搭乗管理システム開発のよくある質問（FAQ）
企画や発注の場で相談されやすい質問を取り上げます。費用や期間は要件によって変わるため、回答は一般的な考え方として読んでください。
搭乗管理システムはパッケージとスクラッチ開発のどちらがよいですか？
標準業務に合わせて短期間で導入するなら、パッケージやホステッド型が有力です。一方で、独自ルールや日本固有の帳票が多い場合は、コア製品に周辺の部分開発を組み合わせます。
フルスクラッチは自由度が高いものの、航空標準、保安、24時間運用、制度変更への追従を長期的に担う必要があります。
通信障害やクラウド障害が起きても搭乗手続きを続けられますか？
継続できるように設計することは可能ですが、通常時と同じ機能を無制限に使えるとは限りません。そこで、必要なデータを端末や空港側に安全に保持しておきます。
オフライン中のチェックインや搭乗判定、復旧後の再同期、重複排除、手動確認を準備します。何分の停止まで、どの便と端末で継続するかも決めておきます。
受入テストでは通信を切断し、想定どおりに処理できるか確かめます。
手荷物と搭乗者の照合はなぜ重要ですか？
搭乗していない旅客の手荷物が積載されるのを防ぐことが、安全な出発判断につながります。
IATAは、本人確認済みで有効な搭乗券を持つ旅客などから受託した手荷物かを確認する考え方を示しています（出典：IATA「Hold Baggage Reconciliation」、2025年）。
旅客ID、搭乗券、便、手荷物タグ、搭載状態を、厳密に紐付けておきます。そのうえで、不一致が起きた場合の保留、確認、取り降ろし、再登録を、監査ログに残します。
生体認証を搭乗管理システムに入れるときの注意点は何ですか？
基本は、同意した人だけが利用でき、使わない人には有人対応などの代替手段があることです。また、利用目的と保存期間も説明します。
IATA One IDは、旅客がデータを管理し、明確な同意を得て認証情報を共有する考え方です。この考え方に沿って、顔画像を中央DBに長期保存する前提は置かず、必要最小限のデータを扱います。
さらに、アクセス権限、ログ、削除手順、誤認時の有人確認を要件に含めます。
まとめ
開発は、DCSを中心としたシステム境界と、便・旅客・手荷物の状態遷移を先に定めることから始めます。画面や搭乗券の発行は、その後に組み立てます。
まず、PSSやBRS、AODBといった業務システムについて、どこまでを誰が受け持つかを整理します。次に、CUSSやCUPPS、ゲートなどの設備との境界を決めます。さらに、重量・重心の計算と政府システムとの連携も、受け持ちの範囲を決めておきます。通常時と障害時の両方で業務が成り立つかを確かめます。
開発を成功させるための要点
まずは、現場観察、要件定義、連携・データ設計、Fit＆Gapの順に進めます。そのあとで、限定PoC、受入テスト、段階導入、運用定着へと続けます。
- 小規模：調査・要件定義・PoCは300万〜800万円、2〜4か月。
- 小規模：調査・PoCは300万〜800万円。
- 限定導入：1,500万〜5,000万円、6〜12か月。
- 複数空港：5,000万〜2億円、12〜24か月。
- フル刷新：1億〜5億円超、18〜36か月以上。
金額はDCSの公開価格ではなく推定レンジです。実際には、既存システム、接続本数、空港数、端末、SLA、移行方式を前提に、個別見積もりを取ります。
次に行うべきこと
発注候補の開発範囲や運用条件を同じ基準で見比べるため、準備は順に進めます。
- 対象の空港と便、PSS・BRS・AODBなどの連携先、ピーク時の旅客数、移行対象の機能を、一枚の資料にまとめます。
- 通信断時の代替手順と移行対象を、書き出しておきます。
- 候補会社に機能デモを依頼し、手荷物照合、通信断からの復旧、重複処理防止を実演してもらいます。
- ゲート変更と切戻しを確かめ、要件定義、RFP、概算見積もりを早期に進めると、必要範囲と3〜5年の総保有コストを比べやすくなります。
▼全体ガイドの記事
・搭乗管理システム開発の完全ガイド
▼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を創業。