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

手荷物管理システムの開発は、手荷物タグと旅客・便・搬送先を結び付け、受託から搭載、乗り継ぎ、到着後の引き渡しまでを一貫して追跡できる業務基盤を整える取り組みです。成功のポイントは、BRS（手荷物照合システム）とBHS（搬送設備）を分けて考え、DCS・AODB・保安検査設備・現場端末を止めずにつなぐことです。

この記事では、空港・航空会社・グランドハンドリング会社が手荷物管理システムを開発する際の全体像、具体的な進め方、2026年時点の費用相場、見積もりの比較ポイントを解説します。通信断や読み取り失敗、乗り継ぎ、未搭乗手荷物、障害時の手作業まで含めて要件を整理しますので、RFP作成や開発会社との打ち合わせにお役立てください。

▼全体ガイドの記事
・手荷物管理システム開発の完全ガイド

手荷物管理システム開発の全体像

手荷物管理システムは、単にバーコードを読み取って現在地を表示するアプリではありません。搭乗管理、便情報、搬送設備、保安検査、現場作業、旅客への案内を同じ手荷物イベントで結び付け、間違いが起きたときに原因と次の対応を追える仕組みです。発注前にシステムの範囲と関係者の責任分界を決めることが、後戻りを減らす第一歩です。

BRSはBaggage Reconciliation Systemの略で、手荷物番号、旅客、便、搭載先を照合し、未搭乗旅客の手荷物や誤搭載の候補を知らせるシステムです。一方、BHSはBaggage Handling Systemの略で、コンベヤー、ソーター、保管設備、検査設備などを使って手荷物を物理的に搬送・仕分けする設備と制御の仕組みです。BRSが業務データと照合・追跡・例外処理を担い、BHSが物理的な搬送を担うと整理すると、見積もり範囲を誤りにくくなります。

実際の案件では、BRSだけを新しくして既存BHSのイベントを取り込むケース、BHSの制御更新とBRSを同時に行うケースがあります。後者はソフトウェア開発だけでなく、搬送機器、制御盤、ネットワーク、保安検査、現場工事まで含むため、BRS単体の開発費とは分けて予算化してください。

主な機能は、チェックイン時のタグ読み取り、旅客・便・手荷物番号の登録、搭載照合、転送手荷物の追跡、到着後の引き渡し記録、読み取り失敗や未接続便の例外処理です。さらに、端末・担当者・時刻・場所を含む監査ログ、遅延手荷物の捜索画面、航空会社・空港・ハンドラーごとの権限管理、KPIダッシュボードを備えると、運用改善までつなげられます。

関係者は、発注主体である航空会社や空港運営者だけではありません。グランドハンドリング会社、保安検査会社、BHS運用会社、DCSやAODBの管理者、現場のランプ担当者、旅客対応窓口、セキュリティ担当者が関わります。誰が便情報の正本を持ち、誰が搭載可否を確定し、障害時に誰が手作業へ切り替えるのかを、要件定義の段階で決める必要があります。

手荷物管理システム開発の進め方・流れ

開発は、要件定義、設計・開発、テスト・リリースの三つに分けて進めます。ただし空港業務では、完成したソフトを最後に現場へ渡す方法は適しません。現場調査と責任分界を先に行い、早い段階で実機・実データに近い試験を繰り返し、段階展開へつなげる進め方が安全です。

最初に、手荷物がどの地点を通り、どの会社がどのイベントを記録するかを業務フローに落とし込みます。受託、搭載、乗り継ぎエリアへの引き渡し、到着後の返却という四つの追跡ポイントを基準に、スキャン時刻、端末、場所、担当者、便番号、手荷物番号、ステータスを定義します。IATA Resolution 753は、旅客からの受託、航空機への搭載、転送エリアへの引き渡し、到着時の旅客への返却という四地点の追跡を求めています（出典: IATA「Baggage Tracking」、2024年以降の公開情報）。これは法令そのものではなく、航空業界の標準要件としてRFPへ反映する項目です。

次に、DCSから受け取る搭乗ステータス、AODBから受け取る便・ゲート情報、BHSから受け取る搬送・仕分けイベント、保安検査設備から受け取る検査結果を棚卸しします。便番号や運航日だけでなく、空港コード、レッグ、時刻、タイムゾーン、手荷物タグ番号をどのシステムが正とするかを明文化してください。成果物は業務フロー図、イベント定義書、システム関連図、データ項目一覧、責任分界表、障害時運用書、KPI一覧です。

インターフェース設計では、既存のType Bメッセージ、ファイル連携、REST API、メッセージキューなどを一括して比較します。IATAのBaggage Information eXchange（BIX）は、航空業界データモデルを基盤にした標準化・構造化されたメッセージ交換方式で、最新の主要版は2025年にリリースされています（出典: IATA「Baggage Information eXchange」、2025年）。すぐに全面移行できない場合は、Type BとBIXを変換する中間層を用意し、移行対象・並行稼働期間・障害時の再送方法を見積もりに含めます。

地下の搬送エリアやランプでは、無線の遮蔽や一時的な通信断が起こります。端末で手荷物番号とイベントをローカル保存し、復旧後に重複・順序・端末時計のずれを検証して同期する仕組みを必須要件にしてください。DCS停止やBHS停止時に、紙リストや手動照合へ切り替えられるか、復旧後に手入力分を誰が承認するかまで決めると、正常系だけを想定した設計から脱却できます。

最初から全空港・全航空会社へ展開せず、1ターミナル、1〜2便、または特定の搬送ラインを対象にパイロットを実施します。受託から搭載までの正常系だけでなく、乗り継ぎ時間が短い便、タグが読めない手荷物、未搭乗旅客、便変更、RUSH手荷物、通信断、DCSの遅延、夜間のピークを試験シナリオに含めます。ラボのデモで成功しても、実機の読み取り距離や現場動線で失敗することがあるためです。

受入基準は、機能の有無だけでなく、読み取り率、手動エンコード率、重複イベント率、アラート発生から対応完了までの時間、転送手荷物の取りこぼし、障害からの復旧時間で定量化します。リリース前には端末配布、アカウント・権限設定、教育、監視、バックアップ、問い合わせ窓口、ロールバック手順を整え、1拠点ずつ段階的に本番化します。導入後も月次でKPIを確認し、規格改定や便数増加に合わせて改善します。

手荷物管理システムの費用相場とコストの内訳

手荷物管理システムの国内公開見積は限られるため、以下は2026年時点の予算取りに使う編集用試算です。BRS固有の定価ではなく、類似する大規模業務システムの人月相場に、空港固有の端末、現場試験、24時間運用、既存設備連携を加味した目安です。空港数、年間手荷物数、便数、利用会社数、既存設備の状態によって金額は大きく変わります。

小規模なSaaSやパッケージ導入であれば、初期費用は500万〜1,500万円、期間は2〜4か月が目安です。1拠点・限定便・主要な1連携・スキャナー設定・管理画面を対象にする規模です。1空港・1航空会社の連携型BRSは1,500万〜5,000万円、期間は6〜12か月が目安で、DCS・BHS・AODB連携、四地点追跡、端末、例外処理、オフライン同期、総合試験、教育を含む想定です。

複数空港・複数社の共通基盤は5,000万〜1.2億円、期間は12〜18か月を見込みます。マルチテナント、権限・監査、インタラインやハンドラー連携、BIXとType Bの変換、冗長化、データ移行が加わるためです。さらにBHSの搬送・ソーター・保管・検査・ネットワーク・制御系まで刷新する場合は1億〜数億円以上、期間は18〜36か月となることがあります。これはBRSだけの開発費ではなく、設備・工事を含む大規模刷新の金額です。

予算取りでは、要件定義・現場調査を10〜15%、連携・メッセージ変換を25〜35%、BRSの業務機能を20〜30%、端末・ネットワーク・現場対応を10〜20%、試験・訓練・移行を15〜25%として仮置きすると、抜け漏れを見つけやすくなります。正式見積ではこの比率をそのまま採用せず、機能別WBS、連携本数、端末台数、試験ケース数、現地作業日数へ分解して確認してください。

人月単価は、PMが月120万〜200万円、上級SEが月80万〜150万円、プログラマーが月50万〜100万円程度を予算検討の起点にできます。運用費は、初期費用の年10〜20%を仮置きし、クラウド、通信、スキャナーやRFID端末、24時間監視、現地保守、規格改定対応を別項目にします。例えば初期費用3,000万円なら年間保守300万〜600万円、8,000万円なら800万〜1,600万円を枠として置き、5年間の利用料・更新費・端末交換費まで含めたTCOで比較することが重要です。

投資効果は、読み取り率だけでなく、転送手荷物の取りこぼし、手動エンコード率、誤搭載アラートの対応時間、便遅延、1,000旅客あたりのミスハンドリング件数で測ります。SITAの「Baggage IT Insights 2026」によると、2025年の手荷物ミスハンドリングは24百万件、業界コストは年間63億ドル、1件平均コストは260ドルです（出典: SITA「Baggage IT Insights 2026」、2026年）。自社の便数・手荷物数・対応工数に置き換え、削減可能な損失を試算すると、単なるシステム費用ではなく経営投資として説明しやすくなります。

手荷物管理システムの見積もりを取る際のポイント

見積もりの金額だけを比較すると、安い提案に見えた案件が後から高くなることがあります。特に、既存システムとの接続、現場端末、オフライン同期、試験、移行、24時間保守が別料金になっていないかを確認してください。発注前に条件をそろえたRFPを作り、各社に同じ粒度で提案と前提条件を出してもらうことが大切です。

最低限、対象空港・ターミナル数、対象航空会社・ハンドラー数、1日あたりの便数と手荷物数、端末台数、追跡対象地点、既存DCS・BHS・AODB・保安設備の製品と接続方式を書きます。さらに、バーコード・OCR・RFIDの利用範囲、転送・未搭乗・破損タグ・RUSH手荷物の処理、旅客向け表示、権限、監査ログ、データ保管場所、保存期間を定義します。

非機能要件も同じくらい重要です。ピーク時の処理件数、許容応答時間、目標稼働率、復旧時間、バックアップ、ネットワーク分離、端末認証、暗号化、脆弱性対応、パッチ適用、障害時の手動継続、教育時間、国内の現地保守体制を明記してください。国土交通省の「空港分野における情報セキュリティ確保に係る安全ガイドライン」は、BHSを空港分野の重要システム例として扱い、運航やサービスへの影響を踏まえた対策を求めています（出典: 国土交通省「空港分野における情報セキュリティ確保に係る安全ガイドライン」第4版、2026年）。

パッケージやSaaSは、BRSの標準機能、航空業界の規格対応、複数空港展開、保守や規格更新に強い傾向があります。ただし、国内固有の業務、既存BHSの古いインターフェース、通信断、データ所在、端末選定、カスタマイズ費を確認する必要があります。パッケージを導入する場合も、設定費と連携費が大きくなれば、総額は個別開発に近づくことがあります。

スクラッチ開発は、複数社が使う共通イベント基盤や独自の業務フローを作りやすい反面、IATA規格改定、24時間可用性、現場端末、監査、保守要員を自社で背負います。比較では、初期費用だけでなく5年のTCO、機能追加の単価、規格改定時の責任、障害時の応答時間、ソースコードやログの利用権を確認してください。候補会社には「IATA 753対応」とだけ聞かず、四地点ごとの証跡、通信断後の同期、DCS停止時の手動切替を実機に近いシナリオでデモしてもらいます。

開発契約では、請負と準委任の範囲、成果物、変更管理、受入条件、遅延時の扱い、データ・ログの所有権、第三者製品のライセンス、規格改定時の追加費用を確認します。特に、便数の増加や新しいハンドラーの参加、空港設備の更新が発生したとき、どこからが追加開発になるかを先に決めます。責任分界が曖昧なままだと、障害がDCS側かBHS側かで復旧が遅れる可能性があります。

受入テストは、画面確認だけで終えません。受託、搭載、転送、到着の四地点を通したイベントの完全性、未搭乗荷物のアラート、タグ再発行、便変更、重複スキャン、通信断、端末故障、BHS停止、DCSの遅延、権限外アクセスを試験します。現場担当者が実際の動線で操作し、手作業に切り替えた後に復旧データを正しく統合できることまで確認してから本番移行してください。

よくある質問（FAQ）

手荷物管理システムの導入では、BRSとBHSの違い、IATA標準への対応範囲、開発期間、既存設備を止めない方法について質問が多く寄せられます。ここでは、発注前に確認しておきたい代表的な疑問へ直接回答します。

1拠点・限定便のパッケージ導入なら2〜4か月、1空港でDCS・BHS・AODBを連携するBRSなら6〜12か月が目安です。複数空港の共通基盤は12〜18か月、BHS設備や制御系まで刷新する場合は18〜36か月以上を見込みます。現場調査、空港側の承認、夜間試験、教育、段階移行の日程を含めて計画してください。

航空業界標準への対応、複数空港展開、保守体制を重視するなら、パッケージを基盤にしたSIカスタマイズが有力です。独自の業務フローや複数社共通のイベント基盤を長期運用するならスクラッチも候補になりますが、規格改定、可用性、端末、監視、保守の費用と体制まで確保する必要があります。機能の適合率だけでなく、5年TCOと障害時の責任分界で判断してください。

受託、航空機への搭載、転送エリアへの引き渡し、到着時の返却という四地点で、手荷物を追跡できるイベントと監査証跡を整えます。単にスキャン機器を置くだけでなく、DCS・BHS・AODBとのデータ連携、インタラインの情報共有、読み取り失敗時の代替手順、イベントの欠損や重複を検知する仕組みが必要です。IATAの標準要件を自社の業務・契約・システム仕様へ落とし込み、対象航空会社や空港の最新方針も確認してください。

オフライン対応を要件に含めれば、端末側にイベントを一時保存し、通信復旧後に安全に同期できます。重要なのは、保存だけでなく、端末時計のずれ、同じ手荷物の重複スキャン、イベント順序の逆転、同じ手荷物番号の再発行を検証できることです。システム障害中は紙リストや手動照合へ切り替え、復旧後に責任者が手入力データを承認する運用まで訓練しておくと、現場の混乱を抑えられます。

まとめ

手荷物管理システムの開発では、BRSとBHSの役割を分け、受託・搭載・転送・到着のイベントを共通の流れとして設計します。DCS、BHS、AODB、保安検査設備との接続、通信断時のオフライン同期、未搭乗手荷物や読み取り失敗の例外処理を、画面機能と同じ優先度で要件に含めてください。

進め方は、関係者と責任分界の整理、業務イベントとKPIの定義、既存インターフェースの棚卸し、オフラインを含む設計、実機に近いパイロット、総合試験、段階展開の順序が基本です。全体を一度に作り切るのではなく、1ターミナルや限定便で検証し、読み取り率だけでなく手動エンコード率、転送ミス、アラート対応時間、復旧時間で効果を確認します。

費用は、限定的なパッケージ導入で500万〜1,500万円、1空港の連携型BRSで1,500万〜5,000万円、複数空港の共通基盤で5,000万〜1.2億円、BHS設備まで含む大規模刷新で1億〜数億円以上が予算検討の目安です。いずれも公開価格ではなく、対象範囲で変動する推定値です。RFPには対象拠点・便数・手荷物数・端末数・連携本数・非機能要件・保守範囲を明記し、初期費用だけでなく5年TCOと障害時の責任分界まで比較してください。

▼全体ガイドの記事
・手荷物管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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