手荷物管理システムとは、手荷物タグ・旅客・便・搬送先を結び付け、受託から搭載、乗り継ぎ、到着後の引き渡しまでを追跡する業務基盤です。BRSによる照合とBHSによる搬送を切り分け、既存設備を止めない連携と現場の例外処理まで設計することが、導入成功の条件です。
本記事では、手荷物管理システムの全体像、種類、開発の進め方、2026年時点の費用目安、開発会社・サービスを選ぶ基準、発注・外注の注意点をまとめます。数値の読み取り率だけでなく、通信断や乗り継ぎ遅延、手作業への切り替えまで含めて検討したい空港・航空会社・グランドハンドリング事業者の方に向けた完全ガイドです。
▼関連記事一覧
・手荷物管理システム開発の進め方
・手荷物管理システム開発でおすすめの開発会社6選と選び方
・手荷物管理システム開発の見積相場・費用
・手荷物管理システム開発の発注・外注・委託方法
手荷物管理システムとは何ですか?

手荷物管理システムは、手荷物の所在と状態をイベントとして記録し、関係者が同じ情報を参照できるようにする仕組みです。紛失・遅延・誤搭載の防止だけでなく、問題が起きたときに「どこで、いつ、誰が、どの端末で読み取ったか」を確認できる点に価値があります。
BRSとBHSは役割が異なります
BRSはBaggage Reconciliation Systemの略で、旅客の搭乗状況と手荷物を照合し、搭乗していない旅客の手荷物を搭載しないための業務データ基盤です。一方、BHSはBaggage Handling Systemの略で、コンベヤー、ソーター、保管設備、検査設備など、手荷物を物理的に搬送・仕分けする設備と制御系を指します。両者は連携しますが、BRSだけを導入して搬送設備が自動化されるわけではありません。
なぜ手荷物管理が重要なのですか?
手荷物の取り扱いは、チェックイン、保安検査、搬送、搭載、乗り継ぎ、到着後の返却という複数の現場をまたぎます。担当組織やシステムが変わるたびに記録が分断されると、照合漏れや引き継ぎミスが起きやすくなります。IATAの公開情報では、2024年のミスハンドリングは旅客1,000人あたり6.3個、年間3,340万個とされています(出典:IATA Baggage Tracking、2026年閲覧)。この規模を考えると、追跡情報を後から探すのではなく、最初から一貫して記録することが必要です。
手荷物の流れと主要機能を整理します

システム要件を考えるときは、画面や端末から始めず、手荷物が通過するイベントから整理します。手荷物番号、旅客、便、搬送先、コンテナやULD、読み取り位置、担当者、時刻を同じ履歴で結び付けると、通常運用と例外運用の両方を設計しやすくなります。
最低限押さえる4つの追跡地点
IATA Resolution 753では、手荷物を少なくとも4地点で追跡する考え方が示されています。具体的には、旅客から航空会社へ引き渡された時点、航空機へ搭載した時点、乗り継ぎエリアへ引き渡した時点、旅客へ返却した時点です(出典:IATA Baggage Tracking)。これは日本の法令そのものではありませんが、RFPで追跡範囲を合意する基準になります。各地点で時刻・位置・担当主体・読み取り方法・失敗時の扱いまで定義してください。
連携する周辺システム
代表的な連携先は、搭乗管理を担うDCS、便・ゲート・時刻を管理するAODB、搬送設備を制御するBHS、保安検査設備、チェックイン端末、手荷物問い合わせ窓口です。システムごとに便名、便の一意キー、手荷物番号、時刻の基準が異なると、同じ手荷物が別物として登録されます。要件定義では、どのシステムが各項目の正本を持つのか、更新順序と重複イベントをどう扱うのかを決めます。
例外処理と監査ログ
現場で価値が出るのは、正常系のスキャンよりも例外処理です。タグの破損や読み取り失敗、未接続便、転送手荷物、RUSH手荷物、不搭乗旅客の手荷物、便変更、通信断を個別の状態として管理します。アラートを出すだけでなく、誰がいつ確認し、取り降ろしや再搭載をどう判断したかを記録できる設計が必要です。監査ログには端末ID、担当者、位置、時刻、元データと訂正履歴を残すと、原因分析と説明責任に役立ちます。
手荷物管理システムの種類と選び方

選択肢は、既製のクラウドサービス、航空業務向けパッケージとSIカスタマイズ、独自開発、BHS刷新を含む統合案件の4つに大別できます。最適な方式は、空港の数や手荷物量だけでなく、既存のDCS・BHS・AODB、運用主体、通信環境、規格改定への対応力で決まります。
クラウドサービス・パッケージ
短期間で標準機能を使い始めたい場合は、クラウドサービスやパッケージが候補です。初期開発を抑えやすく、規格更新や共通機能の保守を任せやすい一方、空港固有の業務や古い設備との接続が標準範囲に収まらないことがあります。オフライン時のデータ保存、利用料の課金単位、データの保管場所、障害時のサポート時間を契約前に確認します。
パッケージを基にしたSIカスタマイズ
標準的なBRS機能を使いつつ、既存設備や国内の運用に合わせたい場合は、パッケージとSIカスタマイズの組み合わせが現実的です。業務イベントや連携部分だけを拡張すれば、全面的なスクラッチ開発よりリスクを抑えられます。ただし、標準外の改修が増えると、バージョンアップのたびに追加費用が発生し、製品本体と個別改修の責任分界が複雑になります。
スクラッチ開発
複数の事業者が共通利用するイベント基盤や、既存製品では表現できない独自運用がある場合は、スクラッチ開発を検討します。データモデル、画面、API、監査ログを自社要件に合わせられる反面、IATA規格の理解、24時間稼働、現場端末、障害時の復旧、将来の規格改定まで自分たちで維持する必要があります。初期費用だけで決めず、5年分の保守人員と改修費を含めて比較します。
BHS設備まで含む統合刷新
コンベヤー、ソーター、保管、検査、制御ネットワークまで更新する場合は、BRS単体の開発案件と分けて考えます。ソフトウェアのリリースだけでなく、現場工事、設備停止、夜間切り替え、航空保安、耐障害性の試験が必要になるため、期間も費用も大きくなります。RFPでは、BRSの業務機能、BHSの制御機能、工事・保守の範囲を別々に記載すると、見積を比較しやすくなります。
手荷物管理システム開発の進め方

開発は、現場を見ずに要件定義書を作ると失敗しやすい領域です。空港、航空会社、グランドハンドリング、保安検査、設備運用の担当者を早期に集め、通常便だけでなくピーク時間や乗り継ぎ便、通信断を前提に、業務・データ・責任分界を順番に固めます。
1. 現状把握と責任分界を決めます
最初に、手荷物がどの地点を通り、誰が読み取り、どのシステムへ通知されるかを図にします。便情報・旅客ステータス・手荷物番号・搭載状態の正本を確認し、航空会社とハンドラーのどちらがデータを訂正できるのかも決めます。成果物は現状業務フロー、システム関連図、データ項目一覧、責任分界表、障害時の手動運用案です。
2. イベントとKPIを定義します
「受付済み」「搭載済み」といった画面上の状態だけでなく、イベントの発生条件、発生場所、時刻の基準、送信者、再送方法を定義します。KPIは読み取り率だけでは不十分です。手動エンコード率、転送手荷物の取りこぼし、誤搭載候補への対応時間、アラートの未処理件数、手荷物1,000個あたりのミスハンドリング件数、便遅延への影響を設定すると、導入効果を運用改善へつなげられます。
3. 連携・オフライン要件を設計します
DCS、BHS、AODB、保安検査設備とのインターフェースを棚卸しし、既存のType B電文、ファイル連携、API、メッセージキューなどを比較します。地下やランプで通信が切れる可能性があるなら、端末にイベントを一時保存し、復旧後に順序を保って再送する仕組みを必須にします。重複送信、端末時計のずれ、便変更、同じタグの再読取を想定した冪等性も設計に含めます。
4. パイロット・総合試験・段階展開を行います
いきなり全空港へ展開せず、1ターミナル、1〜2便、または特定の搬送ラインでパイロットを実施します。正常系だけではなく、ピーク時の大量スキャン、乗り継ぎ、読み取り失敗、通信断、DCS停止、便変更、取り降ろし、手動運用への切り替えを試験します。受入条件を事前に数値化し、現場教育、端末配布、データ移行、監視、バックアップ、切り戻し手順を整えたうえで段階展開します。
▶ 詳細はこちら:手荷物管理システム開発の進め方
手荷物管理システムの費用相場とコスト内訳

手荷物管理システムの国内公開見積は限られるため、以下はBRS固有の定価ではなく、連携型の大規模業務システム、現場端末、試験、教育を組み合わせた予算取りの目安です。空港数、年間手荷物数、端末台数、既存設備、通信方式、24時間運用、保安要件で大きく変動するため、金額だけで妥当性を判断しないでください。
導入規模別の費用目安
小規模なSaaS・パッケージ導入で、1拠点、限定便、スキャナー設定、主要1連携、管理画面までなら、初期費用は500万〜1,500万円、期間は2〜4か月が一つの目安です。1空港・1航空会社の連携型BRSで、DCS・BHS・AODB連携、4地点追跡、例外処理、オフライン同期、総合試験、教育まで含めると、1,500万〜5,000万円、6〜12か月程度を見込みます。
複数空港・複数社の共通基盤では、マルチテナント、権限・監査、ハンドラー連携、メッセージ変換、冗長化、移行まで含めて5,000万〜1.2億円、12〜18か月程度が目安です。搬送設備や保安設備、ネットワーク、現場工事まで刷新する大規模案件は1億〜数億円以上になる場合がありますが、これはBRS単体の開発費ではありません。
費用を左右する内訳
予算の仮置きでは、要件定義・現場調査が10〜15%、連携・API・メッセージ変換が25〜35%、BRS業務機能が20〜30%、端末・ネットワーク・現場対応が10〜20%、試験・訓練・移行が15〜25%という配分を使えます。これは正式見積ではなく、何に費用がかかるかを整理するための比率です。実際の見積では、拠点数、便数、端末数、連携本数、ピーク処理量、冗長化レベルをWBSに落とします。
ランニングコストと5年TCO
運用費は、初期費用の年10〜20%を仮置きする方法があります。初期3,000万円なら年間300万〜600万円、初期8,000万円なら800万〜1,600万円が予算枠の例です。クラウド利用料、通信、スキャナーやRFID端末、24時間監視、現地保守、バックアップ、規格改定対応は別建てになることがあります。初期費用だけで安い方式を選ばず、利用料・保守・端末交換・追加連携・障害対応を5年分足して比較します。
▶ 詳細はこちら:手荷物管理システム開発の見積相場・費用
開発会社・サービスを選ぶときのポイント

手荷物管理システムの選定では、知名度や機能数より、現場の責任を最後まで担えるかを確認します。BRSを中心に扱う事業者、BHSの設備・制御に強い事業者、可視化・分析や共通基盤に強い事業者など得意領域が異なるため、案件の範囲を明確にしてから候補を比べます。
航空・空港業務の経験を確認します
「IATA 753に対応しています」という説明だけでは不十分です。4地点ごとの証跡、転送手荷物、未搭乗手荷物、再搭載、手動エンコード、通信断、便変更をどの画面・データ・運用で扱うのか、実演してもらいます。公開できる範囲で、同等規模の空港や航空会社での導入工程、ピーク時の処理量、障害時の復旧実績、国内の保守体制も確認します。
連携・運用・保守の範囲を比較します
見積書では、DCS、BHS、AODB、保安検査、端末管理、認証、監視、バックアップのどこまでが含まれるかを確認します。障害の一次受付、現場への駆け付け、代替機の貸し出し、規格改定、OSやミドルウェアの更新、追加拠点の費用も比較対象です。特に、ソフトウェア事業者と設備事業者が別の場合、障害原因を互いに押し付ける契約になっていないかを確認します。
5年TCOと体制を点数化します
候補を比較するときは、機能、連携、現場試験、可用性、セキュリティ、保守、費用、拡張性を評価項目に分けます。各項目を5段階で採点し、重要度に応じて重み付けすると、安価だがオフラインに弱い候補や、高機能だが既存設備との接続費が大きい候補を見分けられます。提案時の担当者が、導入後もプロジェクト責任者・運用責任者として関わるかも確認します。
▶ 詳細はこちら:手荷物管理システム開発でおすすめの開発会社6選と選び方
発注・外注・委託を成功させる進め方

手荷物管理システムは、発注主体と利用主体が異なりやすい案件です。航空会社が発注しても空港やハンドラーが日常運用する場合があるため、契約前に誰がデータの正本を持ち、誰がアラートに対応し、障害時に誰が手作業へ切り替えるのかを合意します。
RFPに書くべき項目
RFPには、対象空港・ターミナル・便数・年間手荷物数・ピーク時の処理量・端末台数・対象となる4地点・連携先・保管期間・権限・可用性・復旧時間を記載します。さらに、BRSとBHSの範囲、Type BからBIXなど新しいメッセージ方式へ移行する可能性、オフライン時の最大継続時間、手動切替の手順、試験データの準備者を明記します。「標準対応」と書かれた項目は、実際の証跡とデモで確認します。
契約・受入テスト・SLAを固めます
開発方式は、要件が変わりやすい企画・現場調査を準委任、仕様と成果物が固まった開発・移行を請負にするなど、工程ごとに適した契約を検討します。受入テストでは、機能が動くことだけでなく、4地点の証跡、重複イベント、通信断からの再同期、端末故障、DCS停止、便変更、権限外の閲覧を検証します。SLAには稼働率、障害の重要度、一次応答、復旧目標、代替手段、報告期限を入れます。
データ・ログ・追加費用の扱いを決めます
手荷物番号や旅客情報、位置情報、監査ログを誰が所有し、契約終了時にどの形式で返却するかを決めます。ログの保存期間、バックアップの頻度、削除手順、個人情報の閲覧権限も契約対象です。規格改定、OS更新、追加空港、端末の増設、連携仕様の変更が発生したとき、どこまでを保守費に含めるかを明確にすると、稼働後の予算超過を防げます。
▶ 詳細はこちら:手荷物管理システム開発の発注・外注・委託方法
2026年の最新動向と導入効果の測り方

手荷物管理は、バーコードの読み取りから、RFID、OCR、画像、位置情報、リアルタイム分析へ広がっています。ただし、新しい技術を追加するだけでは効果は出ません。どのイベントの精度を上げ、誰の判断を早くし、どの例外を減らすのかを先に決め、必要な場所から段階導入します。
Type BからBIXへの移行を見据えます
航空業界では、従来のType Bメッセージを、構造化され拡張しやすいBIXへ移行する動きがあります。BIXの主要版は2025年に公開され、RP1755に基づき、航空会社・空港・ハンドラー・技術提供者の間でイベントを共有する考え方が示されています(出典:IATA Baggage Information eXchange、2026年閲覧)。新規開発では、既存電文をそのまま固定せず、変換層を設けるか、将来のAPI・メッセージ方式を想定したデータモデルにしておくと、移行時の改修を抑えやすくなります。
導入前後のKPIを同じ定義で比べます
導入前に最低4週間程度の基準値を取り、導入後も同じ期間・同じ分母で比較します。手荷物1,000個あたりのミスハンドリング、読み取り率、手動エンコード率、転送時の未接続件数、アラート対応時間、捜索開始までの時間、便遅延への影響を記録します。読み取り率が上がっても、アラートを処理できなければ旅客への影響は減りません。現場の作業時間と問い合わせ件数も合わせて評価します。
AIや自動化より継続運用を優先します
予測や自動判定を導入する場合も、最終判断を人が確認できる仕組みと、誤判定時の訂正履歴を残します。空港分野では、旅客サービスだけでなく搬送・制御系の可用性が重要です。国土交通省の空港分野向け安全ガイドラインは、重要インフラのサービス継続を目的に、組織・リスク・技術的対策を確認する枠組みを示しています(出典:国土交通省「航空及び空港分野における情報セキュリティ確保に係る安全ガイドライン」)。ネットワーク分離、最小権限、端末認証、暗号化、監査ログ、脆弱性管理、バックアップ、手動継続を要件に入れます。
導入で失敗しやすいポイントと対策

手荷物管理システムでは、機能の多さより現場の境界条件を見落とすことが大きなリスクになります。導入前に失敗パターンを想定し、要件・試験・契約へ反映します。
正常系デモだけで製品を決める
きれいなバーコードを順番に読み取るデモは、実際のピーク運用を表しません。タグが折れた状態、複数便が同時に流れる状態、乗り継ぎ時間が短い状態、ネットワークが切れた状態、端末の電池が切れた状態を再現します。候補サービスには、例外イベントを登録してから復旧し、最終的に4地点の履歴が矛盾なく残るところまで説明してもらいます。
連携責任を曖昧にしたまま進める
便キー、時刻、手荷物番号、旅客ステータスの不一致は、画面開発だけでは解決できません。どのシステムが正本か、誰が訂正できるか、変換層で何を補正するかを決めないと、障害時に原因を特定できなくなります。連携一覧に、送信元・受信先・データ項目・頻度・再送・エラー通知・責任者を記載し、各担当者の合意を取ります。
手作業への切り替えを用意しない
空港業務では、システム停止中も便を運航しなければならない場合があります。紙の記録、予備端末、手動照合、後からの再入力、責任者への連絡方法を決めておかないと、復旧後に履歴が欠落します。手動運用を例外扱いで終わらせず、訓練と復旧試験の対象にし、再入力したイベントには手動登録であることと原票の識別子を残します。
個人情報とOTセキュリティを別々に扱う
手荷物番号だけでなく、旅客名、搭乗情報、問い合わせ履歴を扱う場合は、個人情報の閲覧範囲を設計します。同時に、BHSや端末など現場の制御系は、一般的な業務システムとは異なる可用性と更新制約があります。ネットワークを分離し、不要な権限を与えず、端末の認証・暗号化・ログ監視・パッチ適用・バックアップ・復旧手順を、設備運用者と情報システム担当者が共同で検証します。
よくある質問

ここでは、導入検討の初期段階で特に質問されやすい内容を整理します。費用や期間は構成によって変わるため、回答の条件も合わせて確認してください。
手荷物管理システムの開発費はいくらですか?
小規模なパッケージ導入は500万〜1,500万円、1空港・1航空会社の連携型BRSは1,500万〜5,000万円、複数空港の共通基盤は5,000万〜1.2億円が予算取りの目安です。BHS設備や現場工事を含めると1億〜数億円以上になる場合があります。いずれも公開定価ではなく、拠点数、便数、端末、連携、試験、保守の範囲で変動する試算です。
BRSとBHSは同じシステムですか?
同じではありません。BRSは手荷物と旅客・便を照合し、搭載状態や例外を管理する業務データ基盤です。BHSはコンベヤーやソーターなどの物理搬送と制御を担います。案件によっては両者を統合して発注しますが、RFPと見積では機能範囲を分けて書くと、費用と責任分界を把握しやすくなります。
通信が切れても手荷物を処理できますか?
要件としてオフライン継続を定義すれば可能です。端末や拠点側にイベントを保存し、通信復旧後に順序・重複・時刻を検証して同期します。通信断の最大時間、端末の保存件数、認証の有効期限、復旧後の再送失敗時の対応を決め、実際にネットワークを切断した試験で確認することが重要です。
パッケージとスクラッチ開発はどちらがよいですか?
標準的な業務、短期間の導入、複数拠点への展開、規格更新の保守を重視するなら、パッケージやクラウドが向いています。独自の責任分界やデータモデル、複数事業者の共通基盤を作りたい場合は、SIカスタマイズやスクラッチを検討します。迷う場合は、1拠点のパイロットで標準機能と現場固有要件の差を測り、5年TCOと運用体制で判断します。
まとめ

手荷物管理システムは、手荷物タグを読み取るだけの仕組みではありません。BRSによる照合、BHSとの搬送連携、DCS・AODBとのデータ連携、4地点の追跡、例外処理、オフライン同期、監査ログ、手動継続を一体で設計する業務基盤です。
導入判断で外せない3つの視点
第一に、4地点の追跡を自社の業務イベントと証跡へ落とし込むことです。第二に、初期費用だけでなく、端末・通信・保守・規格改定・障害対応を含む5年TCOで方式を比べることです。第三に、正常系デモではなく、通信断、読み取り失敗、便変更、DCS停止、手作業への切り替えを含む現場試験で選ぶことです。この3点をRFP、契約、受入条件に反映すると、導入後の認識ずれを減らせます。
次に作成する資料
次のステップでは、現状業務フロー、システム関連図、4地点のイベント定義、連携一覧、例外処理一覧、KPI、RFP、パイロット計画を作成します。対象拠点、便数、端末数、既存設備、通信環境を具体化すれば、複数の開発会社・サービスから同じ条件で提案と見積を受けられます。手荷物の安全な搬送と旅客への説明責任を、システムと運用の両面から実現することが最終的なゴールです。
▼関連記事一覧
・手荷物管理システム開発の進め方
・手荷物管理システム開発でおすすめの開発会社6選と選び方
・手荷物管理システム開発の見積相場・費用
・手荷物管理システム開発の発注・外注・委託方法
