搭乗管理システム開発の完全ガイド

搭乗管理システムとは、チェックインから搭乗、手荷物照合、重量・重心計算、出発後の記録までをリアルタイムでつなぐ航空業務の基幹システムです。単なる搭乗券発行アプリではなく、便・旅客・手荷物の状態を正確に管理し、空港業務を止めないことが役割です。

本記事では、搭乗管理システムの全体像、DCS・PSS・BRSなどの関係、パッケージ・クラウド・スクラッチの選び方、開発手順、2026年時点の費用目安、発注時の確認事項、障害対応や生体認証の注意点までをまとめます。システム導入を検討する担当者が、要件整理やRFP作成に進めるよう、現場の失敗シナリオを軸に解説します。

▼関連記事一覧
・搭乗管理システム開発の進め方
・搭乗管理システム開発でおすすめの開発会社6選と選び方
・搭乗管理システム開発の見積相場・費用
・搭乗管理システム開発の発注・外注・委託方法

搭乗管理システムとは何ですか？

搭乗管理システムは、航空業界でDCS（Departure Control System、出発管理システム）と呼ばれる領域を中心に構成されます。予約情報を受け取って受付を行うだけでなく、搭乗可否、座席、手荷物、搭乗完了、重量・重心、政府機関への旅客情報送信までを、便単位で連続的に処理します。

DCSの中心的な役割は、便の出発に必要な旅客情報を一つの業務フローで確定させることです。チェックイン済みか、座席が確定しているか、渡航書類の確認が済んでいるか、搭乗ゲートを通過したかを更新し、最終的には搭乗者名簿やロードコントロールへ引き渡します。旅客がカウンター、キオスク、モバイル、ゲートのどこから操作しても、同じ便・同じ旅客の状態として扱えることが重要です。

一般的な業務システムでは、数分単位の遅延が許容される場面もあります。一方で搭乗管理では、搭乗締切直前の座席変更やノーショー処理が数秒の差で結果を変えるため、応答性能、同時接続数、再送時の重複排除、操作ログが要件になります。停止時に紙や別端末へ切り替え、復旧後に正しく同期できることも、機能数と同じくらい重要です。

予約・発券を担うPSS（Passenger Service System）は、予約、運賃、発券、在庫などを管理するシステムです。AODB（空港運用データベース）は空港全体の便、ゲート、時刻、設備情報を管理し、BRS（Baggage Reconciliation System）は手荷物と旅客・便の照合を担います。CUSSは共用セルフチェックイン機、CUPPSは共用旅客処理基盤を指します。搭乗管理システムは、これらの境界をまたいで出発処理を成立させる調整役になります。

要件定義で「どのシステムが正本か」を決めないまま画面を作ると、座席変更は反映されたのに手荷物側が古いまま、搭乗済みなのに別端末では未搭乗に見える、といった不整合が起きます。便ID、旅客ID、手荷物タグ、搭乗券番号をどのタイミングで発行し、どのシステムが確定値を持つのかを先に決めることが、開発範囲と費用を正確にする第一歩です。

搭乗管理システムの全体像と業務フロー

搭乗管理は、旅客が空港に着いてからゲートを通過するまでの短い時間に、多数のシステムと現場担当者が連携する業務です。便の準備、旅客受付、手荷物受託、保安・渡航確認、搭乗改札、出発確定という流れで見ると、単体の画面ではなく状態遷移の設計が中心になることが分かります。

まず便名、運航日、機材、座席構成、搭乗口、受付開始・締切、搭乗締切を確定します。運航変更や機材変更が起きた場合は、PSSや空港運用情報と同期し、座席構成や搭乗口を更新します。ここで「予定」と「確定」を区別しないと、古い搭乗口や誤った座席を旅客へ案内する原因になります。

チェックインでは、オンライン、モバイル、カウンター、キオスクなど複数の入口を用意します。予約照合、本人確認、渡航書類の確認、座席割当、アップグレード、特別旅客や乗継旅客の扱いを行い、搭乗券を発行します。国際線では出発前旅客情報処理の結果を受け、搭乗可否を再判定する仕組みも必要です。

手荷物を受託する際は、手荷物タグ、旅客、便、搭乗券を厳密に紐付けます。2025年の航空業界団体による「Hold Baggage Reconciliation」資料でも、本人確認済みで有効な搭乗券を持つ旅客の手荷物を受け入れ、旅客の変更を手荷物側へ反映する考え方が示されています。したがって、手荷物だけを別管理するのではなく、搭乗ステータスと照合できるイベントを残す設計が必要です。

搭乗改札では、バーコード、QRコード、IC、将来的にはデジタルIDや生体認証などを使い、搭乗券の有効性、便、座席、搭乗済みかどうかをリアルタイムで判定します。重複スキャン、別便の搭乗券、座席変更後の古い券、乗継旅客の例外を扱い、異常時には有人確認へ切り替えます。搭乗後は、搭乗者名簿、ノーショー、手荷物照合、重量・重心計算へ確定情報を渡し、出発処理を完了させます。

搭乗管理システムの主な機能と必要な連携

必要な機能は航空会社の規模、空港数、国際線の有無、グランドハンドリングの分担で変わります。画面一覧を先に作るのではなく、便当日の業務シナリオと例外処理から機能を洗い出すと、現場で使われる範囲と開発対象を整理しやすくなります。

コア機能は、便・旅客・手荷物を別々に登録することではなく、相互の状態を矛盾なく更新することです。便管理では機材、座席構成、搭乗口、締切時刻、運航変更を扱います。旅客管理ではチェックイン、座席変更、搭乗券再発行、特別対応、乗継、ノーショーを扱います。手荷物管理ではタグ発行、受託、搬送、照合、取り降ろし、再搭載を扱います。

重量・重心管理を行う場合は、搭乗者数、手荷物重量、貨物、機材情報を用いてロードシートを作成し、変更履歴と承認者を記録します。計算結果を表示するだけでなく、入力値の出所、再計算の条件、確定後の変更権限を定義する必要があります。監査ログは「誰が、いつ、どの端末で、何を変更したか」を追える粒度にします。

連携設計では、接続先の数よりもデータの責任分界を確認します。PSSから予約・発券・旅客情報を受け、搭乗管理側でチェックインや搭乗状態を更新し、BRSへ手荷物照合情報を渡し、AODBから便やゲートの運用情報を受ける構成が一般的です。CUSSやCUPPS、搭乗ゲート、スキャナー、電子タグ、重量計、通知基盤も対象になります。

連携方式はAPIだけとは限りません。標準メッセージ、ファイル連携、既存のレガシー接続を併用する場合は、項目変換、タイムゾーン、文字コード、再送、タイムアウト、重複排除を決めます。通信断から復旧したときに、同じ搭乗イベントを二重に適用しない冪等性が特に重要です。インターフェース仕様書には、正常系だけでなく、遅延、欠損、順序逆転、手動訂正のルールも記載します。

搭乗管理システムの種類と選択肢

方式選定では、初期費用だけでなく、航空標準への追従、障害時の継続性、データ移行、空港ごとの展開、将来のベンダー変更まで比較します。標準機能に業務を合わせる範囲と、独自開発する範囲を分けることが、費用と納期を安定させるポイントです。

パッケージやホステッド型は、チェックイン、搭乗、手荷物、重量・重心、政府向け旅客情報など、航空業務で繰り返し使われる機能を活用しやすい方式です。航空標準や複数空港の運用知見を取り込みやすく、ゼロからの基盤開発を減らせます。標準機能に合わせられる業務が多く、短期間で段階導入したい場合に向いています。

一方で、独自の例外処理や帳票、既存システムのデータ構造をそのまま再現できるとは限りません。カスタマイズ費、利用料、旅客・便・処理件数に応じた課金、データ返却、障害時の責任範囲、サービス終了時の移行条件を契約前に確認します。

クラウド・API連携型は、基幹のPSSや手荷物サービスを活用しながら、現場ポータル、モバイル、通知、分析、運用管理画面を追加する方式です。機能を分割して展開しやすく、空港や業務が増えたときの拡張性を確保しやすい点が特徴です。APIゲートウェイやイベント連携を用いると、変更の影響範囲を管理しやすくなります。

ただし、空港ネットワークや外部サービスが常に利用できるとは限りません。端末側の一時保存、ローカルでの最低限の処理、再接続後の同期、認証トークンの失効、データ暗号化を設計します。クラウドを採用しても、現場の通信断を解決したことにはならないため、オフライン時の業務手順を必ず実機で確認します。

部分スクラッチは、搭乗業務のコアを標準製品や既存サービスに任せ、現場画面、日本固有の帳票、社内ワークフロー、分析機能などを個別開発する方式です。独自性を確保しつつ、保安・航空標準に関わる部分を自社だけで抱え込まずに済むため、現実的な選択肢になりやすいです。

フルスクラッチは、業務ルールを細部まで反映できる一方、24時間運用、端末、標準メッセージ、手荷物照合、重量・重心、制度変更、セキュリティ、障害時のバックアップを継続的に自社で担います。開発費だけで判断せず、5年程度の保守人材、訓練、監視、移行、将来改修まで含めた総保有コストで比較することが大切です。

搭乗管理システム開発の進め方

搭乗管理システムは、最初から全空港・全機能を切り替えるより、現場の状態遷移と例外を確認しながら段階的に進める方が安全です。要件定義、連携設計、Fit＆Gap、PoC、開発、試験、パイロット、展開、運用改善を一つの移行計画として扱います。

まずチェックイン開始から搭乗締切、ノーショー、ゲート変更、手荷物取り降ろし、通信断、再開までを時系列で観察します。担当者へのヒアリングだけでは、繁忙時間の順番待ちや端末の持ち替え、口頭確認、紙の控えといった暗黙の運用が抜けるため、実際の便を観察し、業務イベントと判断条件を記録します。

要件には、1便あたりの旅客数、ピーク時の同時接続、許容応答時間、稼働時間、RTO・RPO、端末の種類、権限、操作ログ、データ保持期間、監査帳票、通知、言語、タイムゾーンを含めます。機能要件に加えて、「通信が30分途切れた場合」「搭乗券を再発行した場合」「座席を変更した直後にゲートで読み取った場合」のようなシナリオを非機能要件へ落とし込みます。

次に、PSS、BRS、AODB、ゲート、端末、重量計、通知基盤とのデータ連携を設計します。便・旅客・手荷物のID体系、状態遷移、正本、再送、エラー時の手動復旧を定義し、インターフェースごとに責任者を決めます。API仕様だけでなく、運航変更や通信遅延が発生したときの業務判断まで合意します。

PoCは、画面の見た目を確認するだけでは不十分です。1空港、1路線、限定端末などの範囲で、実データに近い予約、座席変更、手荷物タグ、搭乗改札、ノーショー、通信断、復旧後の同期を検証します。ピーク負荷を再現し、二重スキャンや同じイベントの再送があっても、搭乗者名簿と手荷物状態が一貫するかを確かめます。

稼働開始は、機能単位または空港単位で区切ります。新旧並行運用の期間、切替日時、切戻し条件、問い合わせ窓口、現場教育、訓練便、障害時の紙運用を準備します。ビッグバン切替を選ぶ場合でも、切戻しが実行可能か、旧システムのデータをどの時点まで保持するかを事前に決めます。

運用開始後は、チェックイン時間、搭乗処理時間、手荷物照合エラー、再発行件数、通信断からの復旧時間、手動処理率、問い合わせ件数をKPIとして確認します。現場の声を受けて画面を変えるだけでなく、状態遷移や連携ルールを変更する場合は、再試験と監査ログの確認まで行います。標準変更や制度変更に追従できるリリース管理も、運用契約に含めます。

▶ 詳細はこちら：搭乗管理システム開発の進め方

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

搭乗管理システムのDCS単体には、公開された一律の料金表がほとんどありません。以下の金額は、2026年時点で公開されている一般的な大規模業務システムの相場と、航空業務特有の連携・可用性・現地展開の要件を組み合わせた概算です。対象空港数、旅客数、既存PSS、国際線、手荷物設備、SLAによって大きく変わるため、確定価格ではありません。

調査、要件定義、データ連携の確認、1便・1空港のPoCであれば、300万〜800万円、期間は2〜4か月が一つの目安になります。パッケージやクラウドを導入し、チェックイン、座席、搭乗、基本的な手荷物連携、既存PSS・端末連携まで行う場合は、1,500万〜5,000万円、6〜12か月程度が概算レンジになります。

複数空港、複数事業者、BRS・AODB・重量・重心、API、移行、バックアップDCS、現場展開まで含めると、5,000万〜2億円、12〜24か月程度になる可能性があります。PSS周辺を含むフル刷新や、複数拠点の24時間運用を独自構築する場合は、1億〜5億円超、18〜36か月以上も想定します。これらはDCSの公開価格ではなく、要件から逆算した推定なので、RFPでは前提条件を必ず併記します。

費用を押し上げるのは画面数だけではありません。PSS、BRS、AODB、CUSS、CUPPS、搭乗ゲート、政府システムなどの接続本数、データ項目の差異、外部仕様への追従、ピーク時の負荷、オフライン・バックアップ要件、二重運用期間、空港ごとの現地作業が大きく影響します。手荷物照合や重量・重心の試験を省くと、後から重大な追加費用になりやすいです。

見積書では、要件定義、設計、開発、テスト、データ移行、端末設定、現地設置、教育、監視、保守、クラウド、ライセンス、従量課金を分けます。端末、スキャナー、搭乗ゲート、ネットワーク、停電対策、現地サポートは別途になることが多いため、初期費用だけで比較しないことが重要です。

ランニング費は、利用料、旅客・便・処理件数に応じた従量課金、クラウド、監視、24時間サポート、端末保守、教育、制度変更対応に分けて考えます。年間保守費を初期開発費の10〜15％程度で仮置きする方法もありますが、航空向けの高い可用性、現地対応、バックアップ環境を含む場合は上振れするため、契約条件による個別確認が必要です。

比較表には、初年度だけでなく3〜5年のTCOを置きます。障害時の遅延や手動処理の損失、データ移行費、空港追加費、解約時のデータ返却費、ベンダー変更費も含めます。安価な方式が必ずしも有利とは限らず、停止や誤照合のリスクを金額に置き換えると、必要な投資範囲を社内で説明しやすくなります。

▶ 詳細はこちら：搭乗管理システム開発の見積相場・費用

搭乗管理システムの開発会社・サービスの選び方

選定では、知名度や機能数だけでなく、航空会社、空港運営、グランドハンドリングのどの業務に強いかを確認します。製品を提供する事業者、導入支援を担う事業者、個別開発や端末設置を担う事業者が分かれることもあるため、契約範囲と障害時の責任分界を最初に整理します。

実績を確認するときは、導入社数の多さより、自社と近い条件で稼働しているかを見ます。空港数、便数、国際線の有無、機材、ピーク時の旅客数、手荷物設備、共用端末、グランドハンドラーとの分担、国内外の法域を質問します。可能であれば、提案資料だけでなく、障害時の対応記録、切替計画、現場教育の方法まで説明してもらいます。

導入支援の範囲も重要です。要件定義だけなのか、PSSやBRSとの連携、データ移行、端末設置、現地リハーサル、運用引継ぎまで担うのかを分けます。製品の標準機能と個別開発の境界、変更依頼の単価、リリース頻度、緊急修正の手順が曖昧なままだと、契約後に費用と納期が膨らみやすくなります。

比較項目には、PSS・BRS・AODBとの連携、CUSS・CUPPS対応、API公開度、オフライン・バックアップ、ピーク負荷、認証・暗号化、監査ログ、国内サポート、SLA、データの保管場所、障害時の復旧目標を含めます。サービスをクラウドで利用する場合も、空港側のネットワークが止まったときに、どこまで現場処理を続けられるかを確認します。

RFPへの回答では、機能の有無を丸印で示すだけでなく、実際の便シナリオを実演してもらいます。座席変更直後の搭乗、搭乗券再発行、手荷物タグの再発行、ノーショー、ゲート変更、通信断、復旧後の再同期、手荷物取り降ろしを確認し、操作回数と有人介入の有無を記録します。

契約書では、稼働率だけでなく、障害の検知時間、一次回答、復旧目標、代替運用、重大障害の連絡網、保守時間、計画停止、セキュリティ事故の報告期限を定義します。便の出発に影響する障害と、管理画面だけの障害で優先度を分けると、実際の運用に合ったSLAになります。

将来のベンダー変更を考え、データの所有権、標準形式でのエクスポート、API仕様書の利用権、カスタム部分のソースコードや設計書、移行支援、契約終了後の保存期間を確認します。導入時に出口を決めることは、相手を疑うためではなく、事業継続性と交渉力を守るための基本設計になります。

▶ 詳細はこちら：搭乗管理システム開発でおすすめの開発会社6選と選び方

搭乗管理システムの発注・外注・委託方法

発注では、システムを作る範囲だけでなく、現場を切り替える責任まで明確にします。製品導入、個別開発、端末やネットワーク、データ移行、教育、運用監視を一社へまとめるのか、複数の専門事業者に分けるのかで、管理負荷と責任分界が変わります。

RFPには、対象空港・便・旅客数、既存システム、対象機能、端末、ネットワーク、外部連携、ピーク性能、稼働時間、RTO・RPO、セキュリティ、監査、移行、教育、保守、納期、予算、評価方法を記載します。特に、対象外の機能と、提案側に確認してほしい前提を明示すると、会社ごとの見積範囲をそろえやすくなります。

デモの依頼には、正常系のチェックインだけでなく、通信断、ゲート変更、ノーショー、手荷物取り降ろし、搭乗券の再発行、復旧後の再同期を含めます。テストデータの提供方法、個人情報のマスキング、現場担当者の参加条件も決めます。提案書の文章より、実際の操作と障害対応の再現性を評価できる形にすることが大切です。

要件が固まって成果物と受入条件を定義できる部分は請負、現場調査や要件整理、調査しながら進めるPoCは準委任が適する場合があります。契約形態を混ぜる場合は、どの工程が成果物の完成責任を持ち、どの工程が作業時間に基づくかを分けて記載します。

複数事業者へ委託する場合は、全体アーキテクチャ、インターフェース、障害時の指揮系統、変更承認、個人情報の委託先管理を発注者側で統括します。システム障害が「ネットワークなのか、DCSなのか、手荷物側なのか」を切り分けられる監視とログの責任を、契約書と運用手順書の両方に書きます。

典型的な失敗は、画面開発を先に始め、連携仕様や例外処理が後から増えることです。これを防ぐには、便・旅客・手荷物の状態遷移図、システム境界図、データ項目一覧、エラー処理一覧、受入テスト項目を先に合意します。仕様変更は、納期だけでなく、保安、手荷物、監査、切戻しへの影響を評価して承認します。

もう一つのリスクは、稼働日に現場が使えないことです。操作研修は説明会だけにせず、繁忙時間の模擬運用、通信断、端末交換、手動処理、復旧後の照合まで実施します。受入条件には、処理時間、エラー率、二重処理がないこと、ログが残ること、切戻し手順が実行できることを含めます。

▶ 詳細はこちら：搭乗管理システム開発の発注・外注・委託方法

セキュリティ・障害対応・2026年の動向

搭乗管理システムは、旅客の個人情報、渡航書類、顔画像や顔特徴データ、手荷物情報、運航情報を扱います。便利な機能を追加するほど、利用目的、アクセス権限、委託先、保存期間、ログ、障害時の代替手段を一体で設計する必要があります。安全性は後から設定する項目ではなく、業務フローの前提条件です。

障害時の設計では、何を止められないかを決めます。チェックインを継続するのか、搭乗改札を継続するのか、手荷物受付を一時停止するのかを業務ごとに分け、代替端末、ローカルキャッシュ、紙帳票、電話連絡、復旧後の再入力を定義します。オフライン処理は便利ですが、古い座席情報や失効した搭乗券を受け付ける危険もあるため、許可する操作と有効期限を限定します。

復旧後は、ローカルで処理されたイベントを時系列と一意なIDで同期し、二重搭乗や二重手荷物登録を防ぎます。同期できないデータを自動で上書きせず、差分を一覧化して有人確認へ回す仕組みも必要です。年に一度の文書確認だけではなく、訓練便や定期的な障害演習で手順を検証します。

2026年時点では、顔を使った非接触のチェックインや搭乗が注目されています。ただし、顔画像や顔特徴データは変更が難しく、漏えい時の影響が大きい情報です。個人情報保護委員会の令和7年7月1日更新Q&Aでも、顔特徴データ等について、利用者の限定、責任者、教育、物理・技術的なアクセス制御、アクセスログの監視などが安全管理措置の例として示されています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドラインに関するQ&A」、2025年）。

生体認証を導入する場合は、利用目的、本人への説明、同意の取得、利用しない人の代替手段、保存期間、削除方法、第三者提供や委託先を要件化します。航空業界団体のOne IDの考え方でも、旅客がデータを管理し、必要な情報だけを選択的に共有することが重視されています（出典：IATA「One ID」、2026年確認）。顔認証を追加すること自体を目的にせず、本人確認の失敗時に有人対応できる設計を優先します。

モバイル搭乗券、セルフ手荷物預け、電子手荷物タグ、デジタルIDなどが広がると、搭乗管理システムはカウンター内の業務から、旅客が空港へ向かう前の判定まで広がります。出発前旅客情報処理では、公開情報上、年間8億件を超えるメッセージを処理し、700社を超える航空会社と接続する基盤もあります（出典：航空IT事業者の「Advance Passenger Processing」公開情報、2026年確認）。これは自社システムにも同規模の処理を要求するという意味ではなく、外部基盤との接続、再送、監査、規制変更への追従が重要になることを示しています。

公開されているDCS導入効果の事例では、チェックイン処理が最大21％速くなり、新人担当者の研修時間が最大62％減ったという報告もあります（出典：DCS製品の公開ページ、2026年確認）。この数値は特定の運用環境における効果であり、すべての導入で再現されるものではありません。自社で評価するときは、処理速度だけでなく、手動介入率、教育時間、障害時の復旧時間を導入前後で比較します。

セルフ化を進める場合も、すべての旅客が同じ状態で処理できるとは限りません。書類確認が必要な旅客、乗継や特別対応が必要な旅客、認証に失敗した旅客を有人窓口へ引き継ぐ設計が必要です。自動化率だけでなく、例外処理の完了時間、有人介入のしやすさ、旅客への説明責任をKPIに含めます。

よくある質問（FAQ）

搭乗管理システムの検討では、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選と選び方
・搭乗管理システム開発の見積相場・費用
・搭乗管理システム開発の発注・外注・委託方法