搭乗管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

搭乗管理システムの開発は、チェックイン画面を作ることではなく、予約・発券から手荷物、搭乗改札、重量・重心計算、出発後の情報連携までを止めずにつなぐ業務基盤を設計することです。

航空会社、空港運営会社、グランドハンドリング会社、情報システム部門が開発を進める際は、機能数や画面数だけでなく、便・旅客・手荷物の状態を正しく同期できるか、通信障害時にも現場を継続できるか、段階的に安全な移行ができるかを先に決める必要があります。本記事では、搭乗管理システムの全体像から具体的な進め方、2026年時点の費用相場、見積もりの確認ポイント、よくある質問までを解説します。

▼全体ガイドの記事
・搭乗管理システム開発の完全ガイド

搭乗管理システム開発の全体像

搭乗管理システムは、航空業界でいうDCS（Departure Control System、出発管理システム）を中心に構成されます。旅客の受付から出発までの状態を一元的に扱い、複数のシステムと空港設備へ正しい情報を伝える点が一般的な予約管理システムとの違いです。

DCSとは、便ごとの出発計画を作成し、チェックイン、座席割り当て、搭乗券の有効性、搭乗完了、搭乗者名簿、ロードコントロールなどを管理する仕組みです。搭乗管理システムという言葉から搭乗券の発行機能だけを想像すると、開発範囲を小さく見積もってしまいます。実際には、オンラインチェックイン、カウンター、キオスク、モバイル、搭乗ゲートのすべてで旅客の状態が変わります。

たとえば、旅客がチェックイン済みであっても、搭乗口で重複スキャンが発生した場合は再搭乗を許可してはいけません。ノーショーになった旅客の手荷物が積み込まれている場合は、手荷物の取り降ろし確認が必要です。こうした例外処理まで含めて、便・旅客・手荷物をひとつの業務状態として設計することが重要です。

主要な連携先は、予約・発券を担うPSS、手荷物管理のBRS、空港運用情報を扱うAODB、共用自動チェックイン機のCUSS、共用旅客処理基盤のCUPPS、搭乗ゲート、手荷物タグ、電子タグ、重量・重心計算、運航管理、通知基盤です。国際線では、渡航書類やビザの確認、政府システムへのAPI／iAPI連携も対象になります。

要件定義では画面一覧から始めるのではなく、各データの正本（source of truth）を決めます。予約情報はPSSが正本なのか、搭乗状態はDCSが正本なのか、手荷物の搬送状態はBRSが正本なのかを明確にし、同じ旅客の状態がシステムごとに異なる事態を避けます。連携項目、更新タイミング、再送方法、重複排除、手動で復旧する手順まで決めておくことが、後工程の手戻りを減らします。

搭乗管理システム開発の進め方・やり方・流れ

搭乗管理システムの開発は、現場観察、要件定義、連携・データ設計、方式選定、PoC、開発、テスト、段階導入、運用定着の順で進めると安全です。特に重要なのは、早い段階で便当日の業務シナリオを再現することです。通常時だけでなく、通信断、欠航、遅延、ゲート変更、乗継失敗、オーバーブッキング、ノーショーを最初から対象にします。

最初に、チェックイン開始から搭乗締切、出発後のメッセージ送信までを時系列で可視化します。空港運営会社、航空会社、グランドハンドリング会社、旅客サービス担当、手荷物担当、運航担当を交えて、誰がどの端末で何を判断するのかを整理します。業務フローには、通常の旅客だけでなく、幼児連れ、車いす利用者、乗継旅客、特別食、渡航書類不備、座席変更、搭乗口変更のケースも含めます。

要件定義では、機能要件と同時に非機能要件を決めます。たとえば、1便あたりの旅客数、ピーク時の同時接続数、チェックインや搭乗判定の許容応答時間、障害時の復旧目標であるRTO、許容できるデータ損失を示すRPO、端末の種類、操作ログの保存期間、権限分離、データの保管場所を定義します。ここが曖昧なまま見積もりを取ると、後からバックアップや監視が追加され、費用と納期が大きく変わります。

次に、PSS、BRS、AODB、CUSS、CUPPS、ゲート設備とのデータ連携を設計します。データ項目の対応表だけでは不十分で、たとえば搭乗券が再発行された場合に古いバーコードをどう扱うか、同じイベントが2回届いた場合にどう冪等処理するか、通信復旧後に端末とクラウドのどちらを正しい状態とするかまで決めます。便・旅客・手荷物の状態遷移図と、連携エラー時の運用フローを成果物に含めることが有効です。

方式選定では、パッケージ／ホステッド、クラウドとAPI連携、部分スクラッチ、フルスクラッチを比較します。DCSのコア機能を航空向け製品で持ち、現場画面や日本固有の帳票、通知、分析だけを個別開発する部分スクラッチは、標準化と独自性のバランスを取りやすい方式です。既存PSSを置き換えない場合は、すべてを作り直すよりも、周辺機能をAPIで追加する方が移行リスクを抑えられる可能性があります。

PoCは、機能を一通り見せるデモではなく、1空港、1路線、限定端末、実データに近い便情報を使って行います。ピーク時の負荷、搭乗締切直前の連続スキャン、通信断、再接続、座席変更、ノーショー後の手荷物照合、ロードシートの再計算まで試すことで、提案書だけでは分からない課題を発見できます。

開発後は、単体テストや連携テストだけでなく、空港全体の業務シナリオを使った受入テストを実施します。搭乗券の二重利用、不搭乗旅客の手荷物、ゲート変更、遅延による振替、外部システムの応答遅延、端末故障、クラウド障害を含め、現場担当者が実際の手順で操作します。テストの合否は「画面が表示できたか」ではなく、「旅客を止めず、誤搭乗や手荷物の不整合を防げたか」で判断します。

SITAの公開情報でも、DCSの障害時に別の処理へ切り替えて出発便の運用を継続する機能や、クラウド・オンプレミスの選択肢、APP／iAPIへの対応が示されています。自社開発でも、ホストDCS停止時のバックアップ運用、端末内の安全な一時保存、復旧後の再同期、二重登録を防ぐ仕組みを要件に含める必要があります。これは「あると便利な機能」ではなく、空港業務を止めないための設計条件です。出典はSITA「SITA Maestro」の公開情報です。

本番移行は、空港単位または機能単位で段階的に行います。新旧システムの並行運用期間、切替可能な時刻、切戻し判断者、紙や手動端末を使う代替手順、現場教育の完了条件を決めておきます。繁忙期の直前に全空港を一斉切替するビッグバン方式は、障害時の影響範囲が広くなります。稼働後も、SLA、監視、インシデント対応、年次訓練、標準変更への追従、ベンダー変更時のデータ返却まで運用計画に含めます。

搭乗管理システムの費用相場とコストの内訳

搭乗管理システムの費用は、DCS単体の公開価格がほとんどないため、対象空港数、旅客数、既存PSS、手荷物設備、端末、法域、SLA、移行方式によって個別に決まります。以下の金額は2026年時点での一般的な大規模業務システムの公開相場と、DCS固有の連携・可用性要件を組み合わせた概算です。航空会社全体のフル刷新にそのまま適用できる確定価格ではありません。一般的なシステム開発相場の参考情報と、DCS固有要件からの推定である点に注意してください。

調査・要件定義・小規模PoCであれば、300万〜800万円、期間は2〜4か月がひとつの目安です。1空港や1路線で業務フロー、連携方式、通信断時の処理を検証する段階であり、本番用の全機能を含む価格ではありません。標準的なパッケージやクラウドを導入し、チェックイン、座席、搭乗、基本的な手荷物、PSS・端末連携までを限定的に整備する場合は、1,500万〜5,000万円、6〜12か月程度が目安になります。

複数空港・複数キャリアに展開し、BRS、AODB、重量・重心、API、移行、バックアップDCS、現地教育まで含める場合は、5,000万〜2億円、12〜24か月程度になる可能性があります。PSS周辺を含むフルスクラッチの基幹刷新では、1億〜5億円超、18〜36か月以上を見込むことがあります。これらは公開されたDCS料金表ではなく、要件の複雑さを踏まえた推定値です。出典の異なる一般的なシステム開発相場とDCSの個別要件を混同しないようにしてください。

費用を左右するのは画面数よりも、連携本数、空港やハンドラーごとの業務差、オフライン処理、手荷物・重量重心のテスト、政府システム連携、生体認証、二重運用、24時間365日のサポートです。たとえば、同じチェックイン機能でも、1空港の固定端末だけを対象にするのか、複数空港の共用端末とモバイルを含めるのかで、認証、監視、障害対応の工数が変わります。

ランニングコストは、SaaSやホステッド型の利用料、便・旅客・トランザクション単位の従量課金、クラウド利用料、監視、保守、端末保守、現地サポート、セキュリティ対応に分けて確認します。端末、バーコードリーダー、搭乗ゲート、プリンター、ネットワーク回線、現地設置、教育、予備機は初期費用に含まれないこともあります。見積書で「一式」とされている項目は、数量と保守範囲を分解してもらうことが大切です。

年間保守費を初期開発費の10〜15％程度で仮置きする方法はありますが、これはあくまで予算検討の出発点です。航空業務向けの24時間サポート、空港現地対応、端末交換、障害時の代替運用を含む場合は上振れすることがあります。導入判断では1年目の初期費用だけでなく、3〜5年TCO、繁忙期に停止した場合の損失、移行費、将来のベンダー変更費まで並べて比較します。

搭乗管理システムの見積もりを取る際のポイント

見積もりの精度を高めるには、必要な機能を並べるだけでなく、便当日の業務シナリオ、連携先、障害時の代替手順、移行範囲、保守条件を発注者側で整理します。提案会社によって「搭乗管理システムに含む範囲」が異なるため、同じ前提条件で比較できるRFPを準備することが重要です。

RFPには、対象となる航空会社・空港・ターミナル・便数・旅客数・運用時間・ピーク時の処理量を記載します。機能面では、便・出発計画、チェックイン、座席、搭乗券、手荷物受付・照合、ゲート、重量・重心、渡航書類、イレギュラー対応、通知、帳票、監査ログを分けて書きます。さらに、PSS、BRS、AODB、CUSS、CUPPS、ゲート設備、ネットワーク、クラウドとの接続条件を示します。

非機能要件には、可用性、応答時間、同時接続数、RTO、RPO、暗号化、権限管理、脆弱性対応、ログの保存期間、バックアップ、監視、サポート時間を入れます。生体認証を使う場合は、同意取得、利用目的、代替手段、顔画像や顔特徴データの保存期間、第三者提供、委託先、誤認時の有人確認、利用停止の手順も明記します。個人情報保護委員会は、顔特徴データ等について、アクセス制御、漏えい防止、アクセスログの取得・分析などの安全管理措置を示しています。出典は個人情報保護委員会「個人情報の保護に関する法律についてのガイドラインに関するQ&A」（2025年）です。

比較先は、DCS製品ベンダー、航空業務に強いSI、空港設備会社、現場運用会社に分かれます。製品ベンダーが提供する標準DCSと、個別SIが担当する現場画面・連携・移行・教育・端末設置は、契約範囲が別になることがあります。提案書には、どの会社がどの機能、設備、データ、障害対応を担当するのかを図で示してもらいます。

評価項目には、同規模・同じ機材・同じ空港設備での稼働実績、PSS／BRS／AODB連携、CUSS／CUPPS対応、オフラインやバックアップ、API公開度、国内サポート、セキュリティ認証、SLA、移行方法、3〜5年TCO、契約終了時のデータ返却を含めます。導入社数や知名度だけではなく、自社と似た障害事例をどう復旧したかを確認することが大切です。

提案時には、機能一覧の説明だけでなく、実演を依頼します。通信を切断してもチェックインや搭乗を継続できるか、復旧後に二重処理が発生しないか、ノーショー旅客の手荷物を確認できるか、ゲート変更を複数端末へ反映できるか、ロードシートを再計算できるかを確認します。現場担当者が操作し、操作時間と判断の迷いを記録すると、画面の見栄えだけでは分からない差が見えます。

見積書では、初期開発費、ライセンス、従量課金、端末、ネットワーク、移行、教育、現地展開、保守、監視、障害対応を分けます。要件定義が終わる前に請負契約で全機能を固定すると、外部仕様の不明点や現場ごとの差異が変更管理に集中します。調査・要件定義は準委任、仕様が固まった開発は請負など、成果物と責任の境界に合わせて契約方式を検討します。

特に確認したいのは、障害時の責任分界、復旧目標、損害発生時の連絡体制、第三者サービス停止時の代替手順、セキュリティ事故の報告期限、データ所有権、ログの保管、契約終了時のデータ返却です。クラウドや海外サービスを利用する場合は、データの保管場所、委託先、サブプロセッサー、国外移転、サポート窓口の時間帯も確認します。

生体認証は、導入すれば必ず処理が速くなるわけではありません。IATAの2025年Global Passenger Surveyでは、空港で生体認証を利用した旅客は50％で、利用者の満足度は85％でした。一方、生体情報を共有したくない旅客の42％は、プライバシーが保証されれば考え直す可能性があると回答しています。出典はIATA「2025 Global Passenger Survey」（2025年）です。導入時は、同意しない人の有人カウンターなどの代替手段を用意し、利便性と選択権を両立させます。

搭乗管理システム開発のよくある質問（FAQ）

ここでは、搭乗管理システムの企画や発注で特に相談されやすい質問に回答します。費用や期間は要件によって変わりますが、判断の起点になる考え方を示します。

標準的な航空業務に寄せられ、短期間で導入したい場合は、パッケージやホステッド型が有力です。独自の運航ルールや日本固有の帳票が多い場合は、DCSのコアを製品で持ち、周辺画面や連携を部分スクラッチで補う方式が現実的です。フルスクラッチは自由度が高い一方、航空標準、保安要件、24時間運用、制度変更への追従を自社で長期的に担う必要があります。

続けられるように設計できますが、通常時と同じ機能を無制限に使えるとは限りません。端末や空港側に必要最小限のデータを安全に保持し、チェックインや搭乗判定を継続できるオフラインモード、通信復旧後の再同期、イベントの重複排除、手動確認の手順を準備します。設計段階で「何分の停止まで、どの便を、どの端末で継続するか」を決め、受入テストで実際に通信を切断して確認します。

搭乗していない旅客の手荷物を誤って積み込むことを防ぎ、安全な出発判断につなげるためです。IATAの「Hold Baggage Reconciliation（2025）」では、本人確認済みで有効な搭乗券を持つ旅客などから受託した手荷物であるかを確認する考え方が示されています。出典はIATA「Hold Baggage Reconciliation」（2025年）です。システムでは、旅客ID、搭乗券、便、手荷物タグ、搭載状態を厳密に紐付け、不一致時の保留・確認・取り降ろし・再登録を監査ログに残します。

同意を取得した人だけが利用できること、利用しない人にも有人対応などの代替手段があること、利用目的と保存期間を説明できることが基本です。IATA One IDは、旅客がデータを管理し、明確な同意を得て認証情報を共有する考え方を示しています。顔画像を中央データベースへ長期保存する設計に固定せず、必要最小限のデータ、アクセス権限、ログ、削除手順、誤認時の有人確認を要件に含めます。

まとめ

搭乗管理システムの開発では、チェックイン画面や搭乗券発行機能から着手するのではなく、DCSを中心としたシステム境界と便・旅客・手荷物の状態遷移を先に定義します。PSS、BRS、AODB、CUSS、CUPPS、ゲート設備、重量・重心、政府システムとの責任分界を整理し、通常時と障害時の両方で業務が成立するかを確認します。

進め方の要点は、現場観察と要件定義、連携・データ設計、Fit＆Gap、限定的なPoC、障害を含む受入テスト、段階導入、運用定着の順で検証することです。費用は、調査・PoCの300万〜800万円、限定導入の1,500万〜5,000万円、複数空港展開の5,000万〜2億円、フル刷新の1億〜5億円超をひとつの推定レンジとして考えます。ただし、DCSの公開価格ではないため、既存システム、接続本数、空港数、端末、SLA、移行方式を前提に個別見積もりを取得してください。

まずは対象空港と便の範囲、現在利用しているPSS・BRS・AODBなどの連携先、ピーク時の旅客数、通信断時の代替手順、移行したい機能を一枚に整理します。そのうえで、発注候補には機能デモだけでなく、手荷物照合、通信断からの復旧、重複処理防止、ゲート変更、切戻しの実演を依頼します。要件定義、RFP作成、概算見積もりを早い段階で行うと、自社に必要な開発範囲と3〜5年の総保有コストを比較しやすくなります。

▼全体ガイドの記事
・搭乗管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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