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

手荷物管理システムの発注では、手荷物を追跡する機能だけでなく、DCS・BHS・AODBとの連携、通信断時の業務継続、空港・航空会社・グランドハンドリング会社の責任分界まで決めることが重要です。

本記事では、手荷物管理システムを外注・委託する際の発注形態の選び方、RFPと要件の整理方法、契約形態、費用相場、委託先の選定基準、見積比較の進め方を、航空現場の運用を止めない観点から解説します。

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

手荷物管理システムとは何ですか？発注前に押さえる全体像

手荷物管理システムは、手荷物タグの番号、旅客、便、搬送先、搭載状況を結び付け、受託から搭載、乗り継ぎ、到着時の引き渡しまでを記録する業務基盤です。発注時は、航空保安のための照合と、旅客向けの追跡・問い合わせ対応を同じシステムで扱うのか、役割を分けるのかを最初に決める必要があります。

BRSはBaggage Reconciliation Systemの略で、旅客の搭乗状況と手荷物を照合し、不搭乗旅客の手荷物や誤搭載候補を検知する仕組みです。一方、BHSはBaggage Handling Systemの略で、コンベヤー、ソーター、早期手荷物保管設備、検査設備など、手荷物を物理的に搬送・仕分けする設備と制御を指します。BRSだけを開発する案件と、BHSの制御・設備更新まで含む案件では、費用も責任分界もまったく違います。

IATA Resolution 753では、手荷物の受託、航空機への搭載、乗り継ぎエリアへの引き渡し、到着時の旅客への返却という4つの主要地点で追跡する考え方が示されています。IATAの2025年報告では、対象となった256社のうち、2025年末までに80.1%が手荷物追跡の実施計画を提出しています（出典：IATA「Resolution 753 Implementation Executive Report 2025」）。そのため、RFPには「IATA対応」とだけ書かず、4地点それぞれで何を読み取り、どの時刻・便キー・担当者・位置情報を証跡として保存するかまで記載します。

連携先は、搭乗・旅客情報を持つDCS、便・ゲート情報を管理するAODB、搬送イベントを持つBHS、保安検査設備、航空会社やハンドラーの業務システムです。誰が旅客ステータスと手荷物番号の正本を持つのかを決めないまま開発会社へ委託すると、同じ手荷物に複数の便キーが付く、イベント時刻がずれる、転送手荷物の判定が遅れるといった問題が起きやすくなります。

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

発注形態は、パッケージやSaaSの導入、パッケージをSI会社がカスタマイズする方式、スクラッチ開発、BHS刷新を含む統合案件の4つに分けて比較すると判断しやすくなります。最安の方式を選ぶのではなく、既存設備との接続、複数社間の責任分界、24時間運用、規格改定への追随を含めた5年TCOで選ぶことが大切です。

既にBRSの標準機能が整ったパッケージやSaaSを使う方式は、導入期間と初期開発量を抑えやすい選択肢です。IATAの追跡要件、搭載照合、イベント履歴、ダッシュボードなどを標準で利用できる場合は、業務を製品に合わせることで短期間のパイロットを進められます。複数空港へ展開する予定がある場合は、拠点追加、利用者追加、スキャン数課金、データ保管場所、サポート時間を契約前に確認します。

一方で、地下やランプで通信が切れる、古い端末を使い続ける、独自の転送ルールがあるといった現場条件は、標準機能だけでは足りない場合があります。オフラインで読み取ったイベントを端末に保存し、再接続後に順序を保って同期できるか、重複イベントをどう排除するかをデモで確認してから採用します。

パッケージを基礎に、SI会社がDCS・BHS・AODBとの連携や国内空港固有の業務を追加する方式は、標準機能と個別要件のバランスを取りやすいです。発注者は、標準でできる範囲、設定で対応できる範囲、追加開発になる範囲を一覧化してもらいます。この境界が曖昧なまま契約すると、要件定義後に追加費用が発生し、納期や受入条件もずれやすくなります。

この方式では、システム会社だけでなく、既存BHSやDCSの保守会社との協力体制が重要です。インターフェース仕様書を誰が提供し、テスト環境を誰が用意し、障害発生時にどの会社が一次切り分けをするのかをRFPと見積書の両方に記載します。

複数の航空会社やハンドラーが共通利用するデータ基盤、独自の空港運用、将来の他空港展開を重視する場合は、スクラッチ開発が候補になります。ただし、IATA規格への追随、24時間の可用性、端末更新、監視、脆弱性対応を自社または委託先が長期に担う必要があります。初期開発費だけでスクラッチを選ぶのではなく、5年間の保守・規格改定・教育費まで見積もります。

コンベヤーやソーター、検査装置、ネットワーク、制御系まで変更する場合は、BRSのソフト開発とBHS刷新を別の費目としてRFPに分けます。国土交通省の「空港分野における情報セキュリティ確保に係る安全ガイドライン」では、バゲージハンドリングシステムが重要システムの例として扱われています（出典：国土交通省、2026年4月改訂版）。停止時に手作業へ切り替えられても、繁忙時間帯は遅延につながるため、制御系の可用性と復旧手順を発注条件に含めます。

発注前の要件整理とRFPはどのように作りますか？

RFPは、開発会社に希望機能を伝えるだけの資料ではありません。現場の業務、データの流れ、接続先、導入範囲、制約、検収方法を同じ前提で比較するための発注書です。最低限、対象空港・ターミナル数、年間便数とピーク時の手荷物数、スキャン端末台数、利用者区分、稼働時間、既存システム、移行対象、希望時期を記載します。

要件整理では、受託、保安検査通過、搬送ライン投入、搭載、転送エリア引き渡し、到着、返却というイベントを時系列に並べます。転送手荷物、未接続便、RUSH手荷物、読み取り失敗、タグ破損、端末の電池切れ、通信断を例外イベントとして加え、誰が判断し、どの画面で処理し、どのログを残すのかを決めます。

さらに、空港運営者、航空会社、グランドハンドラー、保安検査会社、BHS運用会社の責任を分けます。手荷物番号の誤りは航空会社、搬送イベントの欠落はBHS側、端末紛失はハンドラー側というように、原因と一次対応を想定しておくと、導入後の押し付け合いを防げます。

DCS、BHS、AODB、保安設備との接続方式は、REST API、メッセージキュー、ファイル、Type B電文、BIXなどを現状調査して整理します。IATAのBIXは、従来の断片的な手荷物メッセージを、構造化され拡張可能なデータ交換へ移行するための標準です。IATAの公式情報では、BIXの最新メジャーバージョンは2025年に公開されています（出典：IATA「Baggage Information eXchange」）。将来移行する場合は、Type BをBIXへ変換する範囲、変換失敗時の再送、相手先が旧方式のままの場合の中継方法を見積条件にします。

データ正本については、便番号、運航日、旅客ステータス、手荷物タグ番号、ULD番号、位置、イベント時刻の項目ごとに、登録元と更新権限を表にします。サーバー時刻と端末時刻がずれた場合の扱い、重複通知の排除、遅れて届いたイベントの再計算、監査ログの保存期間まで決めておくと、後工程の追加開発を抑えられます。

RFPでは、デモではなく実データに近い環境で検証するPoCの条件を定めます。1ターミナル、1〜2便、特定の搬送ラインなど小さな範囲から始め、通常時だけでなく、ピーク時、乗り継ぎ時間が短い便、通信断、DCS停止、バーコードの読み取り失敗、誤搭載候補の取り降ろしまで試験対象にします。

合格基準は「画面が表示されること」ではなく、手動エンコード率、読み取り率、イベント反映時間、アラート対応時間、オフラインからの同期成功率、重複イベント数、障害復旧時間で定義します。現場作業員が手袋をした状態で端末を操作できるか、雨天や暗所でも読めるか、紙の代替運用へ何分で切り替えられるかも確認します。

契約形態は請負と準委任をどう使い分けますか？

手荷物管理システムの発注では、企画・要件整理と開発・導入を同じ契約に詰め込まず、成果物の確定度に合わせて契約を分ける方法が実務的です。要件が固まっていない段階で完成物と固定価格だけを約束すると、現場調査で判明した例外処理や連携仕様が追加変更になり、双方に無理が生じます。

現状調査、業務整理、RFP作成支援、プロトタイプ、連携仕様の調査など、作業を通じて成果物を具体化する工程は準委任契約が適しています。発注者と受託者が協力して現場情報を集め、作業時間や体制に対して対価を支払う考え方です。責任者を置き、週次の成果確認と意思決定期限を設定することが重要です。

要件、仕様、納期、受入条件が確定した後の機能開発やインターフェース実装は、請負契約で成果物を明確にする方法が候補になります。ただし、外部設備の仕様変更、相手先テスト環境の遅延、規格改定など受託者だけでは制御できない条件を、納期・追加費用・責任の扱いとして契約書に分けて記載します。

契約書には、稼働率だけでなく、障害の検知時間、一次回答時間、復旧目標時間、現地駆け付けの条件、保守窓口の時間帯、バックアップと復旧テストの頻度を記載します。空港の運用時間に合わせた24時間365日の対応が必要か、ピーク便だけ特別体制を組むかによって、保守費用とSLAの水準が変わります。

また、手荷物イベント、旅客・便情報、スキャン画像、監査ログの所有権と利用権限、契約終了時のデータ返却、個人情報の委託管理、再委託先の開示を確認します。BIXや関連規格の改定に伴う調査・バージョンアップを保守費に含めるのか、別途見積にするのかも、発注時に決めておくと予算の不確実性を抑えられます。

手荷物管理システムの費用相場はいくらですか？

手荷物管理システムの国内公開見積は限られるため、以下は大規模な業務システムの相場、連携型BRSの工数、空港現場の端末・試験・教育を組み合わせた予算取り用の試算です。BRS固有の一律価格ではなく、空港数、便数、既存設備、通信方式、24時間運用、保安要件で変動することを前提にしてください。

1拠点で限定便を対象にし、スキャナー設定、主要な1連携、管理画面を整えるSaaS・パッケージ導入は、初期費用500万〜1,500万円、期間2〜4か月が目安です。1空港・1航空会社でDCS、BHS、AODBを接続し、4地点追跡、例外処理、オフライン同期、総合試験、教育まで行う連携型BRSは、1,500万〜5,000万円、6〜12か月を見込むと比較しやすくなります。

複数空港・複数社の共通基盤で、マルチテナント、権限・監査、インタライン連携、Type BとBIXの変換、冗長化、データ移行まで含める場合は、5,000万〜1.2億円、12〜18か月が一つの予算レンジです。搬送設備、ソーター、検査設備、ネットワーク、現地工事や制御系まで刷新する場合は、1億〜数億円以上になり、18〜36か月の大規模案件としてBRS単体と分けて見積もります。

費用の内訳は、要件定義・現場調査10〜15%、連携/API・メッセージ変換25〜35%、BRS業務機能20〜30%、端末・ネットワーク・現場対応10〜20%、試験・訓練・移行15〜25%を仮置きすると全体像をつかめます。これは正式見積ではなく、RFP前の予算枠を作るための配分です。正式見積では、機能別WBS、連携先別の工数、端末台数、試験ケース数に分解してもらいます。

特に見落とされやすいのが、既存システムの調査、相手先との接続試験、夜間の切り替え、手荷物の実機を使った現場リハーサル、端末の予備機、データ移行、教育、紙運用の訓練です。見積書に「調整費」「一式」としか書かれていない場合は、含まれる成果物と含まれない作業を確認します。

運用費は、初期費用の年10〜20%を仮置きし、クラウド、通信、スキャナーやRFID端末、24時間監視、現地保守、規格改定対応を別建てにします。例えば初期3,000万円なら年間保守300万〜600万円、初期8,000万円なら800万〜1,600万円を予算枠として置けますが、SaaSは利用料、スキャン数、拠点数、サポート時間によって継続費用が変わります。

投資効果を説明するときは、読み取り率だけで判断しません。手荷物1,000個あたりのミスハンドリング件数、転送手荷物の取りこぼし、手動エンコード率、誤搭載アラートへの対応時間、便遅延時間、問い合わせ処理時間を導入前後で比較します。SITAの2026年「Baggage IT Insights」では、2025年にミスハンドリングが23%改善した一方、業界全体の年間コストは63億ドル、1件あたり平均260ドルと報告されています（出典：SITA「Baggage IT Insights 2026」）。このような指標を自社の便数と手荷物数に置き換えると、保守費を含むTCOの妥当性を説明しやすくなります。

委託先の選定と見積比較では何を確認しますか？

委託先は、提案書の見栄えや単価だけでなく、航空・空港業務への理解、連携の実績、現場に入る体制、障害時の責任、導入後の保守を一体で評価します。BRS製品を持つ海外ベンダー、BHSや設備に強い会社、国内の業務システムに強いSI会社では得意領域が異なるため、候補を同じランキングで比べるより、自社の課題に合う役割を確認します。

ベンダーには、どの空港で、何拠点・何便規模を、BRS単体で導入したのか、BHSやDCSとの統合まで担ったのかを確認します。可能であれば、候補会社から導入後のKPI、障害事例、現場教育の方法、切り替え期間、保守体制を匿名化した形で示してもらいます。「IATA Resolution 753対応」という説明だけでなく、4地点ごとの画面、監査ログ、アラート、再送、オフライン同期を実際に見せてもらうことが大切です。

国内拠点での保守が必要な場合は、一次窓口の所在地、夜間・休日の対応、現地駆け付けの条件、部品や予備端末の保有場所を確認します。海外製品を採用する場合も、国内のDCS・BHS・航空会社との調整を誰が担うかが明確であれば、導入時のコミュニケーションリスクを抑えられます。

相見積もりでは、A社は開発だけ、B社は端末・教育込み、C社はBHS側の調整を除外というように、前提条件が異なりがちです。見積依頼時に、要件定義、基本設計、詳細設計、開発、連携、端末設定、試験、移行、教育、保守、現地対応を共通のWBSで指定します。各項目に人月、単価、期間、成果物、除外事項を記載してもらうと、金額の差が工数差なのか、対象範囲の差なのかを判断できます。

比較表には、IATA 753とBIXへの対応範囲、DCS・AODB・BHSとの接続数、オフライン継続性、冗長化、監査ログ、データ保管場所、国内保守、規格改定、5年TCOを入れます。価格が安くても、通信断時の同期、現場リハーサル、予備端末、24時間監視が別途なら、運用開始後の支出が大きくなる可能性があります。

「既存パッケージで対応できるため短納期・低価格」と提案された場合は、現場固有の例外処理、端末の操作性、既存設備との接続、障害時の手作業まで確認します。反対に、最初から大規模なスクラッチ開発を前提にし、標準機能との比較や段階導入を説明しない提案も慎重に評価します。

質問への回答が「要件定義で確認します」ばかりで、仮説となる構成、確認事項、リスク、追加費用の条件が示されない場合も注意が必要です。優れた提案は、分からない点を隠さず、未確定事項を一覧化し、現場調査・PoC・本番展開の判断ゲートを示します。発注者側も、回答期限、意思決定者、現地調査の参加者を明確にして、提案の比較条件をそろえます。

発注後の開発・導入はどのように進めますか？

契約後は、要件定義、設計・開発、総合試験、パイロット、本番展開、運用改善を段階的に進めます。航空現場では、システムだけでなく、人、端末、ネットワーク、搬送設備、便運用が同時に動くため、開発会社任せにせず、発注者側の業務責任者が各判断ゲートに参加します。

基本設計では、手荷物の状態遷移、イベントの重複・欠落、便変更、再接続、取り降ろし、転送失敗を定義します。画面設計では、現場作業員向けのスキャン画面、監督者向けのアラート画面、航空会社向けの検索画面、保守担当者向けのログ画面を利用者ごとに分けます。

端末は、バーコードだけでなくOCR、RFID、画像、位置情報を将来追加する可能性も考慮します。カメラの読み取り率、スキャン音、再読取、手動入力、権限切り替え、バッテリー交換を現場で確認し、実装の完成度を画面だけで判断しないことが大切です。

試験は、単体試験、連携試験、業務シナリオ試験、性能試験、セキュリティ試験、障害復旧試験、現場受入試験の順に計画します。通信を切断して端末にイベントを蓄積し、復旧後に正しい順序で反映されるか、サーバーを切り替えて処理が継続するか、DCSから遅れて届いた搭乗ステータスで判定が壊れないかを確認します。

本番展開は、1ターミナルや限定便でパイロットを行い、KPIと現場の声を確認してから対象を広げます。切り替え当日は、旧システムとの並行運用、ロールバック条件、紙・電話・無線を使った代替手順、責任者の連絡網を準備します。航空便を止められない以上、システムの切り替え成功だけでなく、失敗時に安全に戻せることが受入条件になります。

運用開始後は、読み取り率、手動エンコード率、4地点のイベント記録率、転送手荷物の取りこぼし、誤搭載アラートの対応時間、未解決アラート数、便遅延、システム障害時間を月次で確認します。KPIは改善のために使うものであり、現場が数字を隠す原因にならないよう、端末故障や通信環境など原因別に分けて表示します。

保守契約では、規格改定、空港や航空会社の追加、端末更新、新しい連携先の追加をどのような変更管理で扱うかを定めます。IATAは2026年5月に、旧来のType BとBIXを移行期間中に併用できるBaggage Community Systemを発表し、2026年第3四半期の本稼働を予定しています（出典：IATA「Baggage Community System」）。このような業界標準の変化を、追加費用の相談材料として定期的に見直せる体制を作ります。

よくある質問（FAQ）

ここでは、手荷物管理システムの発注・外注を検討する担当者から寄せられやすい質問に回答します。費用や契約だけでなく、BRSとBHSの範囲、標準対応、導入の始め方も整理します。

1拠点・限定便でパッケージ導入を行うだけなら、初期費用500万〜1,500万円が予算の入口になる可能性があります。ただし、DCS・BHS・AODBとの複数連携、4地点追跡、オフライン同期、現場試験、24時間保守まで含めると、1,500万〜5,000万円以上になることがあります。対象範囲と除外事項をそろえた見積で判断します。

十分ではありません。受託、搭載、転送、返却の4地点で何を読み取り、どのシステムからデータを受け、どの証跡を保存し、欠落時にどう補正するのかを確認します。RFPでは、4地点のデモ、イベントログ、アラート、再送、オフライン同期、相手先への共有方法を具体的な受入条件に落とし込みます。

現状調査や要件定義など、発注者と受託者が協力して成果物を固める工程は準委任契約、仕様と受入条件が確定した開発・導入工程は請負契約が候補になります。ただし、契約形態は案件ごとの法務・調達方針にも関わるため、成果物、責任、変更管理、外部要因による遅延の扱いを契約書で確認します。

最初に作る資料は、現状業務フロー、関係者と責任分界、対象空港・便・端末の一覧、連携先一覧、課題・KPI、障害時の代替運用、希望スケジュールをまとめた現状整理書です。そのうえで、4地点追跡と例外処理を含む業務イベント表、インターフェース一覧、RFP、評価基準へ展開します。情報が不足していても、未確定事項を明記した資料を作ることで、ベンダーから調査方法と前提条件を引き出せます。

まとめ

手荷物管理システムの発注では、まずBRSとBHSの範囲を切り分け、DCS・BHS・AODBなどの正本と責任分界を整理します。そのうえで、4地点追跡、転送・未搭乗・読み取り失敗、通信断、DCS停止、手動切り替えをRFPの要件と受入条件に落とし込みます。

パッケージ・SaaSは標準化と短期導入、パッケージ＋SIは既存環境との調整、スクラッチは独自の共通基盤に向きます。BHSや保安設備まで含める場合は、BRSのソフト開発と設備・制御系の費用を分け、保守・規格改定・端末・教育まで含む5年TCOで比較します。

委託先の候補には、製品名や価格だけでなく、4地点の証跡、連携仕様、オフライン同期、現場試験、障害対応、国内保守を説明してもらいます。1ターミナルや限定便でPoCを行い、KPIと切り戻し手順を確認してから段階展開すると、運航への影響と追加費用のリスクを抑えやすくなります。

手荷物管理システムの発注を検討している場合は、現場の関係者を集め、業務イベント・責任分界・連携先・障害時の代替運用を整理するところから始めます。要件と見積の前提をそろえれば、複数社の提案を比較しやすくなり、導入後も改善を続けられるシステムを選びやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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