搭乗管理システムの開発費用は、導入範囲、連携の複雑さ、可用性要件によって、300万円から5億円超まで幅があります。調査やPoCなら数百万円、複数空港へのフル刷新になると億円単位になります。
全体の流れは、搭乗管理システム開発の完全ガイドでも確認できます。
▼全体ガイドの記事
・搭乗管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
搭乗管理システムの概要
搭乗管理システムは、航空業界でDCS（Departure Control System、出発管理システム）と呼ばれる領域を中心とするシステムです。旅客がチェックインしてから搭乗を完了するまでの状態を管理します。そのため、費用を見積もる前に、含める業務とデータを先に決めておく必要があります。
DCSが担う業務範囲
DCSが扱う主な業務は、便の出発計画から搭乗完了までの状態管理です。費用と安全性を判断するには、次の業務範囲を一つずつ確認しておく必要があります。
- 旅客処理：チェックイン、座席割当、搭乗券の読み取りと搭乗可否の判定。
- 出発管理：出発計画の管理に加え、ノーショー、ゲート変更、乗継旅客への対応。
- 手荷物照合：手荷物タグと旅客・便・搭乗券の紐付け。
搭乗しない旅客の手荷物を確認する処理も、見積もりの対象に含めます。実際にIATAの「Hold Baggage Reconciliation（2025）」でも、本人確認済みの旅客と有効な搭乗券、手荷物の照合が示されています。これは安全上の重要な管理事項です（出典: IATA、2025年）。
連携先とシステム境界
連携の見積もりでは、便・旅客・手荷物の状態をどのシステムが確定するかを、先に整理しておく必要があります。費用差を生む連携先は、役割ごとに分けて確認します。
- 旅客・手荷物：PSS、BRS、AODB、CUSS、CUPPSとの連携。
- 空港設備：搭乗ゲート、重量・重心計算、運航管理との連携。
- 周辺基盤：通知基盤などとの、便・旅客・手荷物の情報連携。
システムごとに、便・旅客・手荷物の正本は異なります。そこで、どのシステムが状態を確定し、通信断や再送の際にどのデータを優先するかまで定めておくと、後からの追加開発を抑えやすくなります。
搭乗管理システムの費用相場
搭乗管理システムの費用相場は、導入範囲によって大きく変わります。DCS単体の公開料金表や国内案件の見積書は少ないため、次の数字は、一般的な大規模業務システムの相場と航空業務の要件を組み合わせた概算です。
この数字は実際の契約金額ではなく、予算を組むための初期レンジとして使ってください。規模別の目安は次のとおりです。
規模別の初期費用と開発期間
導入規模が大きくなるほど、対象空港、連携、移行、現地展開が増えます。初期費用と期間は、以下の幅で見積もります。
- 調査・PoC：300万〜800万円、期間は2〜4か月が目安。
- 限定導入：1,500万〜5,000万円、期間は6〜12か月程度。
- 複数空港展開：5,000万〜2億円、期間は12〜24か月程度。
- フル刷新：1億〜5億円超、期間は18〜36か月以上になる可能性があります。
調査・要件定義・小規模PoCでは、1空港・限定便で、現行業務とPSS連携、端末接続を検証します。通信断時の動きも、このとき確かめておきます。パッケージやクラウドDCSを1空港で稼働させる場合は、チェックインや座席、搭乗の処理に加え、基本的な手荷物連携までが対象です。
複数空港・複数キャリア・複数のグランドハンドラーへ展開する場合は、対象が大きく広がります。BRSとAODBとの連携、重量・重心、APIが加わり、バックアップDCS、データ移行、現地展開まで含めて見積もります。さらに、フル刷新では、フルスクラッチでPSS周辺の基幹まで作り直すため、対象が最も広がります。
一般的な2026年のシステム開発相場でも、大規模基幹システムは1,000万円から数千万円以上とされています。また、人月単価は60万〜200万円程度です（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。
見積書に含まれる主な費用の内訳
人件費は、搭乗業務の例外処理まで含めた工数で見積もります。企画から教育まで、担当工程ごとに分けて把握します。
- 企画・設計：企画、業務分析、プロジェクト管理、UI設計。
- 開発・連携：バックエンド、連携、インフラの工数。
- 品質・移行：テスト、移行、教育にかかる工数。
搭乗管理システムでは、通常のWebシステムより業務設計とテストの比重が高くなります。見積もりの精度を左右するのは、状態遷移と例外処理の扱いです。
対象になるのは、便・旅客・手荷物の状態遷移や搭乗締切、ゲート変更です。さらに、ノーショーやオーバーブッキング、再同期の例外処理も含まれます。
人件費以外では、クラウドやサーバー、監視の費用が発生します。バックアップやセキュリティ製品、PSSやBRSなどへの接続費も見ておく必要があります。
端末やバーコードスキャナー、搭乗ゲート機器も、費用の対象です。ネットワーク回線、現地設置、データ移行、教育、マニュアル作成も、これに含まれます。
これらを開発費に含めるか別途費用とするかは、会社によって異なります。端末や現地作業だけで数百万円から数千万円規模になる場合もあるため、扱いは見積もりの段階で確認しておく必要があります。
ランニングコストと3〜5年TCO
搭乗管理システムの継続費用は、利用量と運用体制によって左右されます。そこで、契約後に発生する費用を、運用の場面ごとに分けて確認します。
- 利用・基盤：SaaSやホステッド型の利用料、クラウドの利用料。
- 運用・保守：24時間監視、障害対応、端末保守の費用。
- 更新対応：バージョンアップ、法令や標準の変更への追随。
旅客数や便数に応じて課金される従量課金の有無も、確認しておきます。年間保守費は、初期開発費の10〜15％で仮置きできます。ただし、24時間365日サポートや現地駆け付けを含める場合は、契約条件で金額が変わります。
比較するときは、3〜5年分のTCO（総保有コスト）を並べて見ます。その際は、ライセンスや従量課金、追加空港の展開費を含めます。さらに、端末更新やデータ移管、解約時の返却費用も入れておくと、比較の抜けを防げます。
初期費用が安い方式でも、長期では高くなることがあります。そのため、見積依頼の段階で「初期導入」「1年目運用」「2年目以降」「空港追加」「障害・災害時」の5区分に分けてもらうと、比較しやすくなります。
搭乗管理システムの費用が変動する要因
価格は、空港数や旅客数だけでなく、既存システムや障害時の要求、業務の標準化の度合いによっても変わります。費用を抑えたい場合でも、安全や継続性の要件は削らず、対象範囲と導入順序を調整するのが基本です。
連携本数とデータの複雑さ
連携先が増えるほど、接続だけでなく、データ変換と障害処理の費用も増えていきます。見積もりを依頼する際は、次の条件を伝えておくと話が早く進みます。
- 連携先：PSS、BRS、AODB、CUSS、CUPPS、ゲートなど。
- 処理要件：認証、変換、エラー処理、再送方法、監視、受入テスト。
- 負荷条件：リアルタイム性とデータ量、ピーク時の同時処理の水準。
- 既存環境：既存PSSの形式、空港ごとのコード体系。
既存PSSが古い形式しか扱えない場合や、空港ごとにデータ項目やコード体系が異なる場合は、変換基盤が必要になります。重量・重心、通知、政府システムなどとの接続も、対象に含めます。
オフライン・セキュリティ・SLAの水準
通信断や個人情報を扱う搭乗業務では、止めないための仕組みと保護の水準が、そのまま費用に響きます。そこで、可用性、復旧、情報管理の条件を先に整理しておきます。
- 継続処理：ローカル処理、キャッシュ、バックアップDCSの用意。
- 復旧処理：再接続後の同期、二重処理の防止、切戻しの設計。
- 情報保護：生体認証、顔画像、渡航書類、政府連携の管理。
SITA Maestroの公開情報でも、クラウドまたはオンプレミスでの展開が示されています。また、DCS障害時のオフライン継続や、チェックイン・搭乗のリアルタイム状態管理も、機能として掲げられています（出典: SITA Maestro、2026年確認）。こうした可用性を自社で実装して検証するほど、初期費用もテスト費用も増えていきます。
生体認証を使う場合は、同意の取り方と利用目的をまず定め、保存期間やアクセス権限、委託先も設計します。さらに、代替手段や誤認時の有人対応も用意しておく必要があります。
IATAの2025年調査では、旅客の50％が空港で生体認証を利用しています。また、搭乗券やパスポートの提示を省略できるなら生体情報を共有してもよいと回答したのは74％でした。
一方で、プライバシーが保証されれば再考すると答えた人も42％いました。利便性と信頼性を両立する設計が必要です（出典: IATA Global Passenger Survey 2025、1万件超・200か国超）。
移行方式と現地展開の範囲
全空港を同時に切り替えるか、限定拠点から広げるかで、必要な準備と現地作業が変わります。切替リスクと展開単価を比べながら、方式を選ぶことになります。
- ビッグバン方式：全空港を一度に切り替える方式で、障害時の影響範囲が大きくなります。
- 段階展開：1空港・1路線・限定端末から始め、重大な不具合を早く見つけやすい方式。
- 並行運用：旧新システムの併用期間や切替判断、切戻し時間によって費用が変わります。
段階展開では、限定拠点でのパイロットにかかる費用も、見積もりの中で確認しておく必要があります。
空港ごとに端末やネットワーク、ゲート運用、グランドハンドラーの役割、教育計画が異なる場合は、現地作業が増えます。現地調査や設置、接続試験、立会い、操作訓練、当日サポートが必要になります。
複数空港では、共通設定と空港固有の設定を分けておきます。そのうえで、2空港目以降の展開単価を明記してもらうと、将来の費用を見通しやすくなります。
搭乗管理システム開発の進め方
費用を管理するには、画面数ではなく、出発業務のシナリオとシステム境界から整理します。各段階で成果物と判断基準を決めておくと、追加費用や納期の遅れを抑えやすくなります。
要件定義と現場観察
要件定義では、出発業務の時間の流れと、関係者それぞれの役割を明確にします。正常時から停電時まで、見積もりに影響する場面を洗い出しておく必要があります。
- 業務時系列：チェックイン開始から搭乗締切、出発後メッセージまでの整理。
- 関係者：航空会社、空港運営会社、グランドハンドラー、保安担当、情報システム部門。
- 例外処理：ノーショー、ゲート変更、座席変更、乗継失敗、オーバーブッキング。
- 障害対応：手荷物取り降ろし、通信断、停電のシナリオ化。
要件定義の成果物には、機能一覧や連携一覧、データ項目表を含めます。さらに、便・旅客・手荷物の状態遷移、ピーク時の処理量、権限、監査ログも形にして残します。
RTO・RPO、SLA、保存期間、移行対象、切戻し条件も、この段階で決めておく必要があります。曖昧なまま開発へ進むと、空港ごとの締切時刻などの追加要望で見積もりの前提が崩れてしまいます。
方式選定と設計・開発
標準機能を使う範囲と独自開発する範囲を分けておくと、方式ごとの費用と自由度を比べられます。その際は、ライセンスや障害時の処理も含めて判断します。
- パッケージ・ホステッド型：標準機能と運用知見を使うため、導入期間を短くしやすい方式。
- クラウド・オンプレミス：ライセンス、従量課金、API利用料など費用の種類が変わる方式。
- 部分スクラッチ：日本固有の帳票や承認だけを追加して、自由度とコストを調整する方式。
データの返却条件と国内サポートの範囲も、あわせて確認しておいてください。既存製品に合わせられる業務は標準機能を使うと、費用を抑えられます。
設計では、エッジ側のキャッシュとオフライン時の操作制限を決めておきます。復旧後の再同期や重複イベントの排除、操作ログの改ざん防止も、同じ設計の中で定義します。
API設計書には、タイムアウトや部分成功、再送、手動再処理、相手システム停止時の扱いも書いておきます。後から付け足すと大規模な再テストが必要になるため、要件定義の段階で費用に組み込みます。
テスト・パイロット・段階移行
テストでは、旅客処理から出発確定までがつながって動くかを確かめます。通常時だけでなく、端末や通信の障害が起きた場合の業務経路も確認します。
- 旅客処理：チェックイン、座席変更、搭乗券の再発行。
- 手荷物・搭乗：手荷物タグの発行、搭乗改札、搭乗者名簿の確認。
- 出発処理：重量・重心の確認から出発確定まで。
- 障害再現：通信断、端末再起動、二重スキャン、ゲート変更、ノーショー、手荷物取り降ろし。
本番移行は、1空港・1路線・限定端末でのパイロットから始めます。そのうえで、現場の処理時間やエラー率、問い合わせ件数、再処理件数を確かめます。
繁忙期を避けた切替日を選び、新旧の並行運用と現地サポートを用意します。切戻し用の判断表や障害連絡網、教育済みの代替担当者も、あらかじめ準備しておきます。
導入後は、出発遅延や手荷物照合エラー、搭乗処理時間、オフライン発生回数、再同期失敗を月次で見ていきます。そうすると、改善費用の優先順位を決める材料になります。
搭乗管理システムのコストを最適化するポイント
コストを抑えるとは、安全要件と使いやすさを守ったうえで、不要なカスタマイズや重複投資、将来の移行費を減らすことです。初期見積もりを一時的に下げる工夫とは、区別して考える必要があります。
標準機能に寄せる範囲の線引き
Fit＆Gapでは、標準運用へ寄せる要望と、追加開発が必要な要望を分けて整理します。この分類は、空港を追加するときの共通化にも関わってきます。
- 必須差異：業務上どうしても必要な項目。
- 保安差異：法令や保安上必要なもの。
- 運用差異：現場の好みで変えられるもので、標準運用へ寄せる対象。
- 判断分類：採用・設定変更・追加開発・運用変更・対象外の区分。
共通コアを先に作り、空港固有の設定は後から追加する方法もあります。同じ機能を全空港へ一度に展開せずに済むため、初期の負担を抑えられます。IDや権限、監査ログ、連携エラー処理を共通化しておくと、空港を追加するときの設計工数を抑えやすくなります。
小さな検証と段階導入
本開発の前に、1便・1空港の範囲で連携や負荷、手荷物照合を検証すると、要件の不確実性が減り、本開発の見積もり精度を高められます。
- 費用と範囲：300万〜800万円程度で行う調査・PoC。
- 検証対象：1便・1空港での連携、ピーク負荷、オフライン、再同期。
- 安全確認：実際の端末と匿名化データを使った手荷物照合の検証。
PoCを単なるデモで終わらせないことが大切です。段階導入では、第一段階をチェックイン・座席・搭乗に、第二段階を手荷物・重量重心に、第三段階を生体認証・分析・追加空港に分ける考え方があります。
手荷物照合やオフライン継続のように、安全や継続性に直結する要件は、業務リスクを評価したうえで、最低限の安全基盤を第一段階に含めて設計してください。
3〜5年TCOと契約条件の比較
TCOを比べるときは、導入時だけでなく、利用中と契約終了時の支出も見ておく必要があります。長期の移行の余地まで左右する条件もあるため、契約条件を一つずつ確認します。
- 利用条件：従量課金、追加空港の単価、最低利用料。
- 運用条件：サポート時間、障害対応、バージョンアップの扱い。
- 変更条件：データ移行、端末台数、同時接続数の変更条件。
- 終了条件：データ返却形式、API仕様書、ログ保持、責任の分け方。
第三者委託先や再委託の通知、障害時に誰が何を受け持つかも、TCOに影響します。データを取り出せない場合は、ベンダーを変える際の移行費が高くなります。
RFPでは、3年と5年それぞれの総額を提示してもらうと役立ちます。加えて、障害、空港追加、契約終了のケース別の費用も、別々に示してもらうと有効です。
見積もりを取る際のポイント
見積もりの精度は、機能一覧だけでなく、対象業務や利用規模、連携先、非機能要件、導入方式を同じ前提で示すことで高まります。そのうえで、2〜3社に依頼し、金額だけでなく実施範囲とリスクを比べます。
RFPに記載する項目
RFPの前提がそろうほど、各社の見積もりを同じ条件で比べられます。業務、規模、連携、非機能、導入条件を、まとめて記載しておくことが大切です。
- 利用規模：航空会社や空港、グランドハンドラーの数、対象便数、年間旅客数。
- 処理条件：ピーク時の同時操作数、端末・ゲートの種類、業務フロー。
- 連携要件：PSS・BRS・AODB、API、メッセージ形式。
- 運用要件：オンライン・オフライン、RTO・RPO、監査ログ、権限、保存期間。
- 導入条件：現地展開、教育、保守時間、SLA、切戻し条件。
各社の金額は、内訳がそろって初めて同じ基準で比べられます。そのため、標準機能と追加開発は分けてもらい、初期費用、ライセンス、従量課金は別行にしてもらいます。
端末や現地作業、移行、教育は、一項目ずつ分けて書いてもらいます。保守やクラウド、監視も別行にすると、見落としを減らせます。
未確定の部分は、前提条件や除外項目、想定リスク、追加時の単価を示してもらいます。そうしておくと、提案後に金額が増えたときの説明がしやすくなります。
発注先の評価軸
発注先による違いは、製品機能だけでなく、空港への導入と運用を誰が担うかに表れます。そのため、担当範囲を比べながら、候補となる相手を整理します。
- DCS製品ベンダー：標準機能と製品運用の知見。
- 航空業務に強いSI：個別開発と連携の実績。
- 空港設備会社：端末設置と、空港内の機器との接続。
- 現場運用会社：教育や現地対応、24時間障害対応。
製品会社が、国内の個別開発や端末設置、空港の現地対応まで担うとは限りません。そのため、要件定義から制度変更対応まで、どの工程を誰が担うかを体制図で確認してください。
評価では、同規模の空港や同じ端末、同じPSS構成で稼働した経験があるかを確かめます。
オフラインやバックアップの実演、手荷物照合の受入テストを確認します。さらに、障害時の連絡体制やデータ返却、3〜5年TCOも見ておく必要があります。
通信断から復旧までのデモや、ゲート変更の再処理を依頼すると、資料だけでは分からない実力を比べられます。搭乗しない旅客の手荷物確認も、あわせて依頼しておくとよいでしょう。
安すぎる見積もりと追加費用への備え
安い提案を評価するときは、金額の大小よりも、未計上の工程と契約条件を先に確かめます。どこから追加費用が生じるかの境界も、あらかじめ見極めておきます。
- 除外範囲：要件定義、連携試験、端末、移行、教育のうち、含まれないもの。
- 運用範囲：オフライン対応と保守が含まれているかどうか。
- 追加精算：想定外の費用を、どの契約方式で扱うか。
各工程の準備を誰が担うのかも、確認してください。工程によって契約形態は変わり、たとえば調査・要件定義は準委任、確定した機能の製造や検収可能な成果物は請負とする組み方があります。
責任の範囲、変更の進め方、受入基準を契約書に書き込んでおきます。遅延時の扱いや障害対応、再委託、知的財産、データの所有権も入れておくと、追加費用をめぐる認識違いを減らせます。
よくある質問（FAQ）
搭乗管理システムの費用は、パッケージかスクラッチかの違いに加えて、導入範囲や連携の内容でも決まります。そこで、費用、期間、導入方式について、よくある質問に答える形で整理します。
搭乗管理システムは1,000万円以内で開発できますか？
調査や要件定義、限定的なPoC、既存DCSに接続する小規模な周辺機能であれば、1,000万円以内に収まる可能性があります。
複数空港の展開や、PSS・BRS・AODBとの連携を含めて新規開発する場合は、1,000万円以内は難しい傾向です。オフライン継続や手荷物照合、24時間保守まで含めると、費用はさらに上がります。そのため、対象空港と業務範囲を絞り、後続フェーズを分けて見積もる方法があります。
搭乗管理システムの開発期間はどのくらいですか？
小規模な調査・PoCは2〜4か月、パッケージ・クラウド導入と限定連携は6〜12か月が目安です。複数空港展開は12〜24か月、フル刷新は18〜36か月以上になります。いずれも概算の値です。
期間は、開発工数だけでなく、承認や端末設置、現地訓練、繁忙期を避けた切替、並行運用、受入テストによっても決まります。そのため、要件定義から本番安定化までの工程ごとに、期間を示してもらってください。
パッケージとスクラッチ開発はどちらが安いですか？
一般には、航空業務の標準機能を利用できるパッケージやホステッド型の方が、スクラッチ開発より初期費用と期間を抑えやすいです。
既存業務を大きく変えられない場合や、複数の製品を無理にカスタマイズする場合は、ライセンスや連携、追加開発が積み上がります。そのため、標準化できる業務と独自性が必要な業務を分け、3〜5年TCOで比べてください。
通信障害が起きても搭乗手続きを続けられますか？
通信障害が起きたときに、どこまで業務を続けられるかを決めるには、保持データから有人での代替手順までを一続きで設計する必要があります。安全性と監査性を確かめるため、次の項目を整理しておきます。
- 保持情報：ローカルに保持するデータと、搭乗券の判定方法。
- 手荷物処理：オフラインでの手荷物照合の扱い。
- 復旧処理：操作ログや再同期、二重処理の防止。
- 代替手順：有人対応の安全性と監査性。
業務を続けるのは、安全性と監査性を保てる範囲に限るのが基本です。
まとめ
搭乗管理システムの開発費用は、調査・PoCで300万〜800万円、パッケージ・クラウド導入と限定連携で1,500万〜5,000万円が目安です。複数空港・複数システム連携では5,000万〜2億円、フル刷新では1億〜5億円超が概算の目安です。この金額は、DCSの公開定価ではなく、一般的なシステム開発相場と航空固有の要件から算出した予算レンジです。
費用を左右する要素
費用の差を生むのは、PSS・BRS・AODB・ゲートなどとの連携や、便・旅客・手荷物の状態管理です。そこに、オフライン継続や手荷物照合、重量・重心が加わります。
個人情報や24時間サポート、移行、空港ごとの展開も影響します。初期費用だけでなく、ライセンスや従量課金、端末、保守の費用も見ておく必要があります。クラウドや障害対応、データ返却まで含めた3〜5年TCOで判断してください。
見積もり前の業務と境界の整理
見積もりの前に、業務の流れ、どこまでを誰が受け持つかの線引き、導入段階、発注条件を整理しておきます。
- 現場観察で、正常時と障害時の業務フロー、システム間の受け持ち範囲、対象の空港・便・端末、必要なSLAの整理。
- 段階（調査・PoC、限定導入、複数空港展開）ごとの、同じ前提による複数社の概算見積もり。
- 安さだけでなく、空港で止めない運用力と、将来の拡張・移行に対応できる契約条件。
この確認が、搭乗管理システムのコスト最適化につながります。
▼全体ガイドの記事
・搭乗管理システム開発の完全ガイド
▼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を創業。