手荷物管理システムの発注は、現場業務の整理、連携と責任分界の明確化、段階的な試験・導入の順に進めると、運航への影響を抑えられます。
発注形態、要件とRFP、契約と費用、委託先の選び方、導入工程の順に確認していきます。全体像は手荷物管理システム開発の完全ガイドにまとめています。
▼全体ガイドの記事
・手荷物管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
手荷物管理システムの全体像と発注前の確認点
手荷物管理システムは、手荷物タグ番号、旅客、便、搬送先、搭載状況を結び付ける業務基盤で、受託から搭載、乗り継ぎ、到着時の引き渡しまでを記録します。
発注の時点では、航空保安の照合と旅客向けの追跡・問い合わせ対応を一つのシステムで扱うか、役割を分けるかを決めておきます。
BRSとBHSの違いと発注範囲
BRSはBaggage Reconciliation Systemの略で、旅客の搭乗状況と手荷物を照合し、不搭乗旅客の手荷物や誤搭載候補を検知する仕組みです。
BHSはBaggage Handling Systemの略で、手荷物を物理的に搬送・仕分けする設備と制御を指します。代表例はコンベヤーやソーターで、早期手荷物保管設備や検査設備も含みます。
BRSだけの開発とBHSの制御・設備更新を含む案件では、費用も責任分界も大きく異なります。
4地点追跡と周辺システム連携の要件
IATA Resolution 753は、手荷物を4つの主要地点で追跡する考え方を示しています。
IATAの2025年報告では、対象256社のうち、2025年末までに80.1%が手荷物追跡の実施計画を提出しています。
RFPで記載する4地点は、次の4つです。出典は、IATA「Resolution 753 Implementation Executive Report 2025」です。
- 受託：手荷物を預かった地点
- 搭載：航空機へ積み込む地点
- 乗り継ぎ：乗り継ぎエリアへの引き渡し地点
- 返却：到着時に旅客へ返す地点
RFPには「IATA対応」と書くだけでなく、4地点ごとに読み取る項目を具体的に記します。時刻、便キー、担当者、位置情報のうち、何を証跡として保存するかも明記します。
連携先には、旅客情報を持つDCS、便・ゲート情報を管理するAODB、搬送イベントを持つBHSがあります。
保安検査設備や航空会社・ハンドラーの業務システムも対象になります。
旅客ステータスと手荷物番号の正本を決めないまま委託すると、同じ手荷物に複数の便キーが付くおそれがあります。
イベント時刻のずれや転送手荷物の判定遅れも起きることがあります。
手荷物管理システムの発注形態の選び方
発注形態は、パッケージやSaaSを使う方式から、スクラッチ開発、BHS刷新を含む統合案件まで分けて比べます。
形態は、初期費用の安さではなく5年TCOで比べます。既存設備との接続や複数社間の責任分界、24時間運用、規格改定への追随も、その比較に含めます。
パッケージ・SaaSが向く案件
BRSの標準機能が整ったパッケージやSaaSは、導入期間と初期の開発量を抑えやすい選択肢です。
IATA追跡要件や搭載照合は、イベント履歴やダッシュボードと合わせて標準で使える場合もあります。
業務を製品に合わせられると、短期間のパイロットを進めやすくなります。
- 複数空港への展開：拠点・利用者の追加、スキャン数課金の扱い
- 契約条件：データ保管場所、サポート時間
地下やランプで通信が切れる場合や、古い端末、独自の転送ルールがある場合は、標準機能に追加の調整が要ることがあります。
たとえば、オフライン中のイベントを端末に保存し、再接続後に順序を保って同期できるかを確かめます。さらに、重複排除の方法もデモで確かめてから採用します。
パッケージ＋SIカスタマイズと既存環境との調整
パッケージを基礎に、SI会社がDCS・BHS・AODB連携や国内空港固有の業務を追加する方式です。そのため、標準機能と個別要件の両方を組み合わせて使えます。
境界が曖昧なまま契約すると、要件定義の後に追加費用が生じ、納期や受入条件もずれやすくなります。
そのため、契約の前に次の範囲と役割を整理しておきます。
- 標準と追加の線引き：標準機能、設定対応、追加開発の範囲を、開発会社に一覧にしてもらう
- 保守会社との連携：システム会社に加えて、既存のBHSやDCSの保守会社も含めた協力体制
- 役割の割り当て：インターフェース仕様書の提供者、テスト環境の準備者、障害時の一次切り分け担当を、RFPと見積書に書く
スクラッチ開発とBHS刷新を選ぶ理由
複数航空会社・ハンドラー共通のデータ基盤、独自運用、他空港展開を重視する場合はスクラッチ開発が候補です。
スクラッチ開発では、IATA規格への追随や24時間の可用性を長期に保つ必要があります。端末の更新や監視、脆弱性への対応も、同じ期間続きます。
これらは、自社と委託先のどちらが長期に担うのかを、発注の時点で明確にしておく必要があります。
初期開発費だけで比べると、保守や規格改定の負担が見えないまま選んでしまいます。
- 長期費用：5年間の保守・規格改定・教育費
- BHS刷新：BRS開発と設備更新を別々の費目に分ける
国土交通省の安全ガイドラインでは、バゲージハンドリングシステムが重要システムの例として挙げられています。
出典は、国土交通省「空港分野における情報セキュリティ確保に係る安全ガイドライン」（2026年4月改訂版）です。
対象設備は、コンベヤーやソーター、検査装置です。
ネットワークと制御系も含まれます。
停止時に手作業へ切り替えられても、繁忙時間帯の遅延につながるため、制御系の可用性と復旧手順を発注条件に含めます。
発注前の要件整理とRFPの作り方
RFPは、各社が同じ前提で比べられるように、現場業務やデータの流れ、接続先を示す発注書です。
導入範囲や制約、検収方法も同じ資料に含めます。
規模は、対象空港・ターミナル数と年間便数、ピーク時の手荷物数で示します。端末台数、利用者区分、稼働時間も記載します。既存システム、移行対象、希望時期も加えます。
業務イベントと責任分界の整理
要件整理では、まず手荷物の処理イベントを時系列に並べます。
- 通常イベント：受託、保安検査通過、搬送投入、搭載、転送、到着、返却
- 例外イベント：未接続便、RUSH、読取失敗、タグ破損、電池切れ、通信断
通常イベントは、搬送ライン投入や転送エリアへの引き渡しまで整理します。転送手荷物は通常イベントとして扱います。ただし、例外ごとに、誰が判断し、どの画面で処理し、どのログを残すかは決めておきます。
空港運営者、航空会社、グランドハンドラーの責任を分けます。また、保安検査会社とBHS運用会社の責任も分けます。
原因と一次対応を想定しておくと、導入後の責任の押し付け合いを防げます。
たとえば、手荷物番号の誤りは航空会社、搬送イベントの欠落はBHS側、端末紛失はハンドラー側が一次対応します。
インターフェースとデータ正本のRFP記載
まず、既存システムとの接続方式を現状調査します。対象には、DCS、BHS、AODBがあります。さらに、保安設備との接続方式も対象です。
IATAのBIXは、断片的な手荷物メッセージを、構造化され拡張可能なデータ交換へ移行するための標準です。
その最新メジャーバージョンは、2025年に公開されています。
出典：IATA「Baggage Information eXchange」
- 接続方式：REST API、メッセージキュー、ファイル
- メッセージ：Type B電文、BIX
- BIX移行：変換範囲、失敗時の再送、旧方式の中継方法を見積の条件に含める
便番号や運航日、旅客ステータスなど、項目ごとに登録元と更新権限を表にします。手荷物タグ番号とULD番号も対象です。位置とイベント時刻も、同じ表に入れます。
サーバー時刻と端末時刻のずれに備え、重複通知の排除方法を決めておきます。そのうえで、遅延イベントの再計算と監査ログの保存期間を定めると、後工程の追加開発を抑えられます。
PoCと現場試験の範囲
RFPでは、実データに近い環境で検証するPoCの条件を定めます。最初は小さな範囲から始める方法が適しています。
試験は、範囲と運航条件を決めたうえで、障害や例外の扱いを試します。
合格基準は、画面表示だけでなく、現場運用と障害時の動作で定めます。
- 試験範囲：1ターミナル、1〜2便、特定の搬送ライン
- 運航条件：通常・ピーク時、短い乗り継ぎ
- 障害・例外：通信断、DCS停止、読取失敗、誤搭載候補の取り降ろし
- 合格指標：手動エンコード率、読取率、反映・対応時間、同期成功率、重複数、復旧時間
現場の条件として、手袋をした操作、雨天や暗所での読取、紙の代替運用への切り替え時間も確かめます。
請負と準委任の使い分け
企画・要件整理と開発・導入は、同じ契約に詰め込まず、成果物の確定度に応じて分けるのが実務的です。
要件が固まる前に完成物と固定価格だけを約束すると、現場調査で分かった例外処理や連携仕様が後から追加変更になり、双方に無理が生じます。
要件定義は準委任、確定した開発は請負
作業を通じて成果物を具体化する工程には、準委任契約が適しています。
まだ要件が固まりきらない段階では、作業内容を見ながら進められる準委任が合います。
要件と仕様が確定し、納期や受入条件も決まった開発工程では、成果物を明確にする請負契約が候補になります。
- 準委任：現状調査、業務整理、RFP支援、試作、連携仕様調査
- 請負：条件確定後の機能開発、インターフェース実装
準委任では、発注者と受託者が現場情報を集めながら作業を進め、作業時間や体制に対して対価を支払います。そのため、責任者、週次の成果確認、意思決定期限を決めておく必要があります。
外部設備の仕様変更や相手先テスト環境の遅延、規格改定は、受託者が単独では制御しきれない要因です。そのため、納期、追加費用、責任の扱いを契約書に記載しておきます。
SLA・データ・規格改定の条項
契約書には、稼働率に加えて、障害対応とデータ管理の条件も記載します。
障害対応の条件は、時間と体制の両面で決めておきます。障害の検知時間、一次回答時間、復旧目標時間を定めるとともに、24時間365日対応か、ピーク便だけ特別体制にするかも選びます。その違いで、保守費用とSLA水準が変わります。
- 障害対応：検知、一次回答、復旧目標、現地駆け付け、窓口時間
- 復旧準備：バックアップと復旧テストの頻度
- データ・規格：所有権、返却、委託管理、再委託、BIX等の調査・更新費
対象データは、手荷物イベントや旅客・便情報などです。スキャン画像と監査ログも対象に含まれます。
規格改定費の扱いを決めておくと、予算の不確実性を減らせます。さらに、データの利用権限、個人情報の委託管理、再委託先の開示は、契約前に確かめておきます。
手荷物管理システムの費用相場
国内の手荷物管理システムは、公開された見積が限られています。そのため、本記事の金額は、大規模業務システムの相場や連携型BRSの工数、空港現場の端末・試験・教育を組み合わせた予算試算をもとにしています。
費用は一律ではなく、空港数や便数、既存設備で変わります。通信方式や24時間運用、保安要件によっても変動します。
導入パターン別の初期費用
導入パターンごとに、初期費用と期間を見積もります。SaaS・パッケージの場合、対象は1拠点の限定便です。
この範囲が、予算の入口の目安になります。
連携型BRSは、1空港・1航空会社の範囲で、周辺システムとの接続、4地点追跡、例外処理、オフライン同期、総合試験、教育まで含めて見積もります。
含む範囲が広がるぶん、初期費用の見込みも上がります。
搬送設備、ソーター、検査設備を刷新する場合は、1億〜数億円以上になります。その際は、ネットワーク、現地工事、制御系も対象になります。期間は18〜36か月を見込み、BRS単体と分けて見積もります。
- SaaS・パッケージ：限定便、スキャナー設定、主要連携、管理画面を整備
- 初期費用・期間：SaaS等は500万〜1,500万円、2〜4か月
- 連携型BRS：DCS・BHS・AODB、4地点追跡、例外、オフライン、試験、教育
- 初期費用・期間：連携型BRSは1,500万〜5,000万円、6〜12か月
- 共通基盤：複数空港・複数社で5,000万〜1.2億円、12〜18か月
共通基盤は、複数空港・複数社を対象にする仕組みです。その中身には、マルチテナントや権限・監査、インタライン連携があります。さらに、Type BとBIXの変換、冗長化、データ移行も加わります。
この規模の費用と期間は、一つの予算レンジとして捉えます。
費用を左右する連携・現場試験・移行
RFPの前に予算枠を作る際は、費目ごとの配分を仮置きします。次の割合は、正式な見積ではありません。
- 要件定義・現場調査：10〜15%
- 連携/API・メッセージ変換：25〜35%
- BRS業務機能：20〜30%
- 端末・ネットワーク・現場対応：10〜20%
- 試験・訓練・移行：15〜25%
正式見積は、機能別WBSと連携先別の工数に分けてもらいます。さらに、端末台数と試験ケース数も示してもらいます。
見積には、既存システム調査や接続試験、夜間切替が含まれているかを確認します。また、実機リハーサルや予備端末の扱いも、各社の見積で比べます。
データ移行や教育、紙運用訓練は、見積の項目に入っているかを見ます。「調整費」や「一式」と書かれた項目は、成果物と対象外作業を尋ねます。
運用費と5年TCOの比較
運用費は、初期費用の年10〜20%を仮置きし、初期費用と合わせて5年TCOで比べます。
運用費は、初期費用の見積とは別建てで扱います。
たとえば、初期3,000万円なら年間保守は300万〜600万円、初期8,000万円なら800万〜1,600万円を予算枠にできます。
- 運用費の対象：クラウド、通信、端末、24時間監視、現地保守、規格改定
- SaaS費用：利用料、スキャン数、拠点数、サポート時間で変動
- 効果指標：1,000個あたりのミスハンドリング、転送漏れ、手動入力、アラート対応、遅延、問い合わせ時間
投資効果は、読み取り率だけでなく、これらの指標を導入前後で比べて判断します。
SITAの2026年報告では、2025年のミスハンドリングは23%改善しました。また、業界全体の年間コストは63億ドルで、1件あたりの平均は260ドルです。
出典：SITA「Baggage IT Insights 2026」
指標は、自社の便数・手荷物数に置き換えて使います。そうすると、保守費込みのTCOを説明しやすくなります。
委託先の選定と見積比較の確認点
委託先は、提案書や単価だけでなく、航空・空港業務への理解と連携実績で評価します。さらに、現場体制、障害時の責任、導入後の保守も見ます。
BRS製品を持つ海外ベンダー、BHS・設備に強い会社、国内業務システムに強いSI会社では、得意領域が異なります。そのため、自社課題に合う役割を確認します。
担当範囲と証跡で見る実績
候補会社には、担当範囲と導入実績を確認します。
製品名より、その会社が何を担ったかを聞くほうが実態に近づけます。
可能であれば、匿名化した形で導入後の数値や障害事例を示してもらいます。さらに、現場教育や切替期間、保守体制の内容も聞いておきます。
- 担当範囲：空港、拠点・便規模、BRS単体か周辺設備との統合か
- 実績の証跡：4地点の画面、監査ログ、アラート、再送、オフライン同期
- 国内保守：窓口、夜間休日対応、駆け付け、部品・予備端末の保管場所
海外製品であっても、国内のDCS・BHS・航空会社との調整担当が明確であれば、導入時の連絡リスクを抑えられます。
同じWBSと前提条件での見積比較
相見積もりでは、会社ごとに前提が異なりがちです。たとえば、開発のみの見積や端末・教育込みの見積、BHS調整を除外した見積が混じります。
そこで、各社に共通WBSを指定し、項目ごとの人月と単価を記載してもらいます。さらに、期間と成果物、除外事項も書いてもらいます。
工程の区切りを揃えておくと、金額差の理由を追いやすくなります。
- 共通WBS：要件定義、基本設計、詳細設計、開発、連携、端末、試験、移行、教育、保守、現地対応
- 比較項目：IATA 753・BIX、DCS・AODB・BHS接続数、オフライン、冗長化、監査ログ
- 運用条件：データ保管、国内保守、規格改定、5年TCO
金額差が工数によるのか、対象範囲によるのかを判断できます。
通信断の同期や現場リハーサルが別途扱いなら、導入後に支出が増える可能性があります。予備端末や24時間監視も、別途扱いかどうかを確かめます。
安すぎる見積と曖昧な提案
見積額だけでなく、提案の前提、確認事項、費用条件まで評価します。
- 低価格のパッケージ案：例外処理、端末操作、設備接続、障害時の手作業の扱い
- 大規模スクラッチ案：標準機能との比較と、段階導入の説明の有無
- 曖昧な回答：「要件定義で確認します」の一言か、仮説構成・リスク・追加費用条件の提示の有無
特に、現場の操作と障害時の動きまで読むと、前提の違いが見えてきます。
優れた提案は、未確定事項を一覧にし、現場調査、PoC、本番展開の判断ゲートを示します。一方で、発注者側も回答期限、意思決定者、現地調査の参加者を明確にし、提案条件をそろえます。
発注後の開発・導入の進め方
契約後は、次の工程を段階的に進めます。
- 要件定義
- 設計・開発
- 総合試験
- パイロット
- 本番展開
- 運用改善
この順序で進めると、航空現場の業務責任者が各判断ゲートに参加できます。
導入中は、人と端末、ネットワークが同時に動きます。さらに、搬送設備や便運用も重なって動きます。そのため、開発会社任せにせず、発注者側の業務責任者も各判断に参加します。
設計で先に決める例外系
基本設計では、状態の遷移と、イベントの重複や欠落を扱います。
画面設計では、利用者ごとに業務を分けて考えます。
- 状態・例外：便変更、再接続、取り降ろし、転送失敗を定義
- 画面：作業員のスキャン、監督者のアラート、航空会社の検索、保守担当のログ
- 端末確認：OCR・RFID・画像・位置情報の将来追加、カメラ読取率、スキャン音、再読取、手入力、権限、電池交換
実装が完成したかは、端末を使った現場確認で見ます。
総合試験と段階展開
試験は、単体と連携の順に進めます。そのうえで、業務シナリオや性能、セキュリティを確かめます。最後に、障害復旧と現場受入を試します。
航空便を止められない現場では、障害時に安全に戻せることも受入条件になります。
- 通信・サーバー障害：イベントの順序反映と、切替後の処理継続
- DCS連携：遅延した搭乗ステータスでも判定が崩れないこと
- 段階展開：1ターミナルや限定便での試行、KPIと現場の声
- 切替準備：並行運用、ロールバック、紙・電話・無線、責任者連絡網
とくに、端末に蓄積したイベントの扱いは、通信断の試験で確かめます。
導入後の運用KPIと改善契約
運用後は、読取や記録の品質、手荷物処理への影響を月次で確かめます。
KPIは、端末故障や通信環境など原因別に表示します。そうすると、現場が数字を隠す状況を避けやすくなります。
- 処理品質：読取率、手動入力率、4地点記録率、転送手荷物の取りこぼし
- 運航・障害：誤搭載アラート対応、未解決数、便遅延、障害時間
- 変更管理：規格改定、空港・航空会社、端末、連携先の追加
IATAは2026年5月、旧Type BとBIXを移行期間中に併用できる仕組みを発表しました。また、Baggage Community Systemは、2026年第3四半期の本稼働を予定しています。
出典：IATA「Baggage Community System」
保守契約では、標準の変化を、追加費用の相談材料として定期的に見直せる体制を作ります。
よくある質問（FAQ）
発注や外注を検討する担当者から寄せられやすい質問に、費用と契約、BRSとBHSの範囲、標準対応と導入の始め方の順に答えます。
手荷物管理システムの開発費用は500万円で足りますか？
1拠点・限定便のパッケージ導入なら、初期費用500万〜1,500万円が予算の入口になる可能性があります。
DCS・BHS・AODB連携や4地点追跡を含む場合、初期費用は1,500万〜5,000万円以上になることがあります。
オフライン同期や現場試験、24時間保守を加えると、対象範囲はより広がります。そのため、対象範囲と除外事項をそろえた見積で判断します。
IATA Resolution 753対応と書いてあれば十分ですか？
表記の確認に加えて、受託、搭載、転送、返却の4地点で、それぞれ何を読み取るかまで見ておく必要があります。
どのシステムからデータを受け、どの証跡を保存し、欠落時にどう補正するかも見ます。受入条件には、4地点のデモやイベントログ、アラートを含めます。さらに、再送、オフライン同期、相手先への共有方法も条件にします。
請負契約と準委任契約はどちらを選べばよいですか？
現状調査や要件定義など、協力して成果物を固める工程には、準委任契約が候補です。一方で、仕様と受入条件が確定した開発・導入には、請負契約が候補になります。
契約形態は、案件ごとの法務や調達方針にも関わります。そのため、契約書では成果物と責任の範囲を確認します。変更管理や外部要因による遅延の扱いも、契約書で確かめます。
発注前に最初に作る資料は何ですか？
最初に作るのは、現状整理書です。現状業務フローや関係者と責任分界を、この中にまとめます。対象の空港・便・端末も書き、連携先や課題・KPIも含めます。
障害時の代替運用と希望スケジュールも記載します。その後は、4地点追跡と例外処理を含む業務イベント表へ展開します。さらに、インターフェース一覧、RFP、評価基準へと進めます。
情報が不足していても、未確定事項を明記した資料を作れば、ベンダーから調査方法と前提条件を引き出せます。
まとめ
発注時は、まずBRSとBHSの範囲を分けます。そのうえで、DCS・BHS・AODBなどの正本と責任分界を整理します。4地点追跡と例外処理はRFPの要件に入れ、通信断やDCS停止、手動切替も受入条件に含めます。
標準機能と現場固有要件による発注形態の選び方
パッケージ・SaaSは標準化と短期導入に、パッケージ＋SIは既存環境との調整に、スクラッチは独自の共通基盤に向きます。
BHSや保安設備を含む場合は、BRS開発と設備・制御系を分けます。保守と規格改定、端末や教育を含めた5年TCOで比べます。
最初の一歩は現場調査と小規模PoC
委託先の選定では、製品名や価格だけでなく、実証内容と運用体制を確かめます。
小規模な段階展開を取り入れると、運航への影響と追加費用のリスクを抑えられます。
- 実証内容：4地点の証跡、連携仕様、オフライン同期、現場試験
- 運用体制：障害対応と国内保守
- PoC判断：限定範囲でのKPIと切り戻し手順
発注を検討する段階では、現場の関係者を集め、業務イベントと責任分界を整理します。さらに、連携先と障害時の代替運用も確かめます。
発注者は、複数社の提案を比べ、導入後も改善を続けられるシステムを選びます。
▼全体ガイドの記事
・手荷物管理システム開発の完全ガイド
▼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を創業。