搭乗管理システム開発の発注/外注/依頼/委託方法について

搭乗管理システムの発注・外注は、チェックイン画面だけを作る依頼ではなく、便・旅客・手荷物の状態を安全に一致させるDCS（出発管理システム）を、既存の予約・発券や空港設備と一体で設計する取り組みです。発注形態、RFP、契約、費用、委託先の評価軸を先に整理すると、価格だけに引っ張られず、止まりにくく現場で使えるシステムを選びやすくなります。

この記事では、航空会社、空港運営会社、グランドハンドリング会社の情報システム担当者に向けて、搭乗管理システムを外注する具体的な進め方を解説します。パッケージ・クラウド・部分開発・フルスクラッチの選び方、RFPに書く内容、準委任と請負の使い分け、2026年時点での概算費用、見積比較と受入テストのポイントまで、発注前に確認したい事項を順番にまとめます。

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

搭乗管理システムとは何ですか？発注前に決める範囲

搭乗管理システムは、航空業界でいうDCS（Departure Control System）を中心とした出発業務の基盤です。予約・発券を担うPSS、手荷物管理のBRS、空港運用データベースのAODB、共用端末のCUSS・CUPPS、搭乗ゲート、重量・重心管理などを接続し、チェックインから出発までの状態を更新します。したがって、発注の最初に「どの機能を作るか」だけでなく、「どのシステムがどのデータの正本を持つか」を決める必要があります。

最低限、便の出発計画、オンライン・カウンター・キオスクでのチェックイン、座席変更、搭乗券発行、搭乗改札、ノーショー判定、手荷物タグとの紐付け、搭乗者名簿、重量・重心計算、遅延やゲート変更などのイレギュラー対応を対象にします。国際線ではAPP・iAPIや渡航書類確認も関係します。画面数だけを要件にすると、後から「この判定はPSSかDCSか」「手荷物の搭載可否は誰が確定するか」といった責任分界が曖昧になり、追加費用が発生しやすくなります。

発注資料には、便・旅客・手荷物の状態遷移を簡単な時系列で示します。たとえば、チェックイン済み、手荷物受付済み、搭乗口到着、搭乗済み、搭乗締切後という状態を定義し、座席変更、乗継失敗、搭乗拒否、手荷物の取り降ろしが起きたとき、どのシステムがどのイベントを発行するかを書きます。ここが決まると、開発会社は画面ではなく連携と例外処理を含めて見積もれます。

搭乗管理システムでは、機能要件と同じくらい非機能要件が重要です。ピーク時の同時接続数、スキャンから判定までの許容時間、障害時のRTO・RPO、空港ネットワーク断でも続ける業務、復旧後の再同期、操作ログ、権限、監視、バックアップ、24時間365日のサポート時間をRFPに入れます。特にオフライン時に二重搭乗や二重手荷物登録が起きないことは、デモではなく実データに近い試験で確認する必要があります。

生体認証を使う場合は、顔画像や顔特徴データを保存するか、照合後に削除するか、利用目的をどう通知するか、利用しない旅客の代替手段をどう用意するかまで決めます。個人情報保護委員会の2025年7月更新Q&Aでは、本人を判別できる写真画像や顔特徴データについて、利用目的、安全管理、保有期間などの検討が求められています。航空業界のIATA One IDも、旅客の同意と必要最小限の情報の選択的な開示を重視しています。

搭乗管理システムの発注形態はどれを選ぶべきですか？

発注形態の結論は、搭乗業務の標準部分が多い企業はDCS製品の導入を軸にし、独自業務や既存システムとの間を個別開発で補う方式が現実的です。すべてを新規開発すると自由度は上がりますが、航空標準、端末、保安、24時間運用、制度変更まで発注者が引き受けることになります。まず標準に寄せられる範囲と、譲れない差別化部分を分けてください。

Amadeus Altéa DCSやSITA Maestroのような製品・ホステッド型は、チェックイン、搭乗、旅客情報の送信、セルフサービス、障害時の継続運用など、航空業務で必要になる機能を短期間で組み込みやすい選択肢です。SITAの公式製品情報では、クラウドとオンプレミスの展開、APP・iAPI、DCS障害時のオフライン継続性が説明されています。なお、製品ページにある処理速度や教育時間の改善値はベンダー提示値ですので、自社の空港・便種別で再現できるかをPoCで確認します。

確認する項目は、標準機能の範囲、カスタマイズの可否、APIの公開度、従量課金の単位、端末や現地設置の責任、データの返却条件、契約終了後の移行支援です。空港やグランドハンドラーが複数の航空会社を扱う場合は、共用端末や複数キャリアの切替を現場で実演してもらいます。製品を導入しても、国内の帳票や手動承認を別システムで補うことが多いため、製品ベンダーと導入支援会社の役割を分けて見積もることが大切です。

既存PSSやBRSを使いながら、現場ポータル、運航状況の可視化、通知、モバイル、管理者向け画面だけを開発する方式は、全刷新のリスクを抑えやすくなります。発注時は「APIがあるから連携できる」と判断せず、旅客ID、便ID、手荷物タグ、座席、時刻、イベントの再送規則、エラー時の手動復旧まで確認します。API仕様書だけでなく、サンプルデータと異常系のレスポンスを開示できる会社を選んでください。

フルスクラッチが向くのは、複数の既存製品では表現できない業務が競争力に直結し、長期の開発・保守体制を持てる企業です。ただし、航空標準への追従や空港設備との接続を自社だけで担うのは負担が大きくなります。最初から全面刷新を決めず、1空港・1路線・限定端末でPoCを行い、運用上の差分を確認してから対象範囲を広げる方が、発注の失敗を減らせます。

RFPと要件整理はどのように進めますか？

RFPは機能一覧の依頼書ではなく、発注者が解決したい業務課題と、委託先に比較可能な提案を求める文書です。搭乗管理システムでは、通常日の流れだけでなく、遅延、欠航、ノーショー、乗継失敗、ゲート変更、手荷物の不一致、通信断、停電、DCS切替といった失敗シナリオを最初から含めます。

RFPの冒頭には、対象となる航空会社・空港・路線・便数、現行システム、利用者、導入目的、希望時期、予算の考え方を記載します。次に、チェックイン、座席、手荷物、搭乗、重量・重心、政府連携、通知、監査、管理画面などの業務範囲を示します。各項目には「必須」「できれば」「対象外」を付け、標準機能、設定、追加開発、別製品のどれで実現する提案なのかを回答してもらいます。

数値もできる限り入れます。1便あたりの旅客数、ピーク時の同時操作数、端末台数、1日の便数、許容応答時間、稼働率、保守時間、データ保持期間、復旧目標、切替対象空港数などです。実数が未確定なら、最小・標準・最大の3ケースで提示します。数字がないRFPでは、会社ごとに異なる前提で見積もるため、価格と納期を比較できません。

納品物は、ソースコードや画面だけではありません。業務フロー、基本設計・詳細設計、API仕様、データ移行計画、端末設定手順、運用手順、監視設計、教育資料、テスト計画、障害連絡網、切戻し手順、データ辞書まで明示します。手荷物と旅客の照合を扱う場合は、搭乗しなかった旅客の手荷物を検知し、取り降ろし判断につなげるシナリオも受入条件にします。IATAが2025年の資料で、本人確認済みの旅客と有効な搭乗券による手荷物受付や、手荷物と搭乗者の追跡・照合を確認項目として示しているためです。

受入テストは、正常系だけで合格にしません。通信を切った状態でチェックインを続ける、同じ搭乗券を2回読み取る、座席変更直後にゲートで読み取る、手荷物を登録した旅客がノーショーになる、復旧後に同じイベントを再送する、といったケースを用意します。テストの合否判定を「担当者の感覚」ではなく、期待する状態とログ、再処理の結果で確認できる形にします。

契約形態と開発プロセスはどう使い分けますか？

要件が固まっている部分は請負、現場調査や要件定義のように検討しながら進める部分は準委任に分ける方法が使いやすくなります。搭乗管理システムを最初から全工程の一括請負にすると、未確定の連携条件や業務差分が後から変更費用になりやすいためです。契約方式は価格の安さではなく、要件の確定度と変更の起こりやすさで決めます。

準委任は、専門家の知見や作業時間を提供してもらい、発注者と委託先が一緒に要件を固める段階に向きます。請負は、合意した仕様と成果物を期限内に完成させる開発・テストに向きます。DCS製品を使う場合は、これらに加えてライセンス、クラウド利用、保守、端末、現地作業の契約が重なります。契約書では、成果物の検査方法、未達時の扱い、知的財産権、再委託、秘密情報、個人データの委託、契約終了時のデータ返却を確認します。

開発会社が手配する外部サービスや端末会社がある場合は、誰が一次窓口になるかを決めます。PSSの障害なのか、DCSの処理なのか、空港ネットワークの問題なのかを切り分けられないと、便の出発時に連絡がたらい回しになります。SLAには稼働率だけでなく、重大障害の受付時間、初動時間、暫定復旧、恒久対応、現地派遣、月次報告、訓練の頻度を記載します。

おすすめの工程は、現場観察、要件定義、製品のFit&Gap、連携設計、PoC、基本設計、開発・設定、総合テスト、現場訓練、限定運用、段階展開です。最初のPoCでは、1空港・1路線・限られた端末を使い、ピーク時の処理速度、座席変更、手荷物照合、通信断、復旧後の再同期を確認します。PoCの目的は画面が動くことではなく、実運用のリスクと追加費用を早い段階で見つけることです。

複数空港へ展開する場合は、空港単位または機能単位で切り替えます。新旧システムの並行期間、手作業に戻す条件、旧システムへ戻す時刻、未送信イベントの扱い、現場責任者の判断権限を決めておきます。切戻しを「何か問題があれば戻す」とだけ書くのではなく、搭乗判定の遅延、未照合手荷物、再同期失敗、重大ログ欠落など、数値または状態で定義してください。

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

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固有の要件を加えた推定です。発注時は、開発費と製品利用料を混ぜず、同じ前提で比較してください。

年間費用には、ライセンスやSaaS利用料、旅客・便・トランザクション単位の従量料金、クラウド、監視、保守、ヘルプデスク、端末保守、現地対応、制度変更への改修、教育、訓練、バックアップ環境を入れます。初期開発費の10〜15％を保守費の仮置きにする方法もありますが、航空向けの24時間サポートや端末保守を含む場合は上振れするため、契約条件を確認してください。

見積書では、初期費用、移行費、導入支援、現地展開、端末費、外部サービス費、月額費、従量費、保守費、追加改修費を分けます。安い見積でも、障害時の現地派遣やデータ返却、契約終了時の移行が別料金なら、将来の負担が大きくなります。1年目の合計だけでなく、3年目と5年目の累計、ベンダーを変更する場合の出口費用まで並べると、価格の妥当性を判断しやすくなります。

委託先の選定と見積比較で確認するポイント

委託先は、知名度や機能数のランキングではなく、自社と近い運用条件で安定稼働させた経験を軸に選びます。DCS製品ベンダー、航空業務に強いSI会社、空港設備会社、グランドハンドリングの運用会社は役割が異なります。1社にまとめる場合も、どこまでを自社が担当し、どこからを再委託するのかを提案書と契約書で明らかにしてください。

実績確認では、「航空業界の導入実績があります」という説明だけで終わらせません。対象空港数、便数、旅客数、国際線の有無、PSS・BRS・AODBとの接続、CUSS・CUPPSやゲート設備、オフライン運用、バックアップDCS、段階移行の有無を聞きます。可能であれば、同規模の利用者に、直近の障害件数、初動時間、復旧方法、現場教育、リリース時の影響を確認します。守秘義務で詳細が出せない場合も、匿名化された運用指標を提示できるかを見ます。

デモでは、通常のチェックイン画面よりも例外処理を見せてもらいます。旅客の座席変更、手荷物登録後のノーショー、同じ搭乗券の二重読取、便のゲート変更、通信断からの復旧、手作業による再処理、監査ログの検索を実際に操作します。発注者が提示したシナリオを短時間で再現できる会社は、要件の理解と現場対応力を評価しやすくなります。

比較表には、要件定義、設計、開発・設定、連携、端末、移行、テスト、教育、現地展開、保守を列に並べ、会社ごとの金額と含まれる成果物を記載します。標準機能で対応する項目と追加開発の項目、前提となる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には通常業務だけでなく通信断、ノーショー、手荷物不一致、復旧、切戻しのシナリオまで含めます。

費用は、初期開発費だけで判断せず、ライセンス、従量課金、端末、現地展開、移行、教育、保守、24時間サポートを含む3〜5年TCOで比較します。委託先には、同規模・同設備での稼働実績、障害時の初動、オフライン運用、データ返却、ベンダー変更時の支援を確認してください。要件定義やRFP作成の段階から航空業務とシステム連携の両方を理解するパートナーを加えると、見積の抜けと導入後の手戻りを抑えやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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