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

手荷物管理システムの開発は、関係者と責任分界の整理、業務イベントと接続の定義、実機に近い試験と段階展開の順に進めると、安全に導入できます。

全体の流れは、要件定義・企画、設計・開発、テスト・リリースの3段階です。各段階で何を決めるか、また費用と見積もりの比べ方を、順に見ていきます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

手荷物管理システムは、タグ番号と旅客、便、搬送先を結び、受託から搭載、乗り継ぎ、到着後の引き渡しまで追跡する業務基盤です。搭乗管理・便情報・搬送設備・保安検査・現場作業・旅客案内を、共通のイベントで結びます。

そのため、バーコードを読んで現在地を表示するだけのアプリとは異なり、誤りの原因と次の対応も追えます。また、発注前に対象範囲と関係者の責任分界を決めておくと、後戻りを減らせます。

BRSとBHSの違い

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一覧も作成します。

設計・開発フェーズの連携とオフライン対応

接続方式は既存環境を踏まえて比較し、BIXへすぐ全面移行できない場合は変換層も検討します。

• 接続候補：Type Bメッセージ・ファイル連携・REST API・メッセージキュー。
• BIX：航空業界データモデルを基盤にした、標準化・構造化メッセージ交換の方式。
• 移行設計：変換対象、並行稼働期間、障害時の再送方法の見積もり。

BIXの最新主要版は2025年にリリースされています（出典：IATA「Baggage Information eXchange」、2025年）。

地下の搬送エリアやランプでは、無線が遮られたり、通信が一時的に切れたりします。そこで端末は、番号とイベントを端末内に保存し、復旧後に重複、順序、端末時計のずれを検証して同期します。

DCSやBHSが停止したときに備えて、紙リストや手動照合へ切り替えられるかを決めておきます。加えて、復旧後に手入力分を誰が承認するかも定め、正常時以外の運用まで設計します。

テスト・リリースの段階展開

いきなり全空港・全航空会社へ広げず、まずは1ターミナル、1〜2便、または特定の搬送ラインで試します。

• 通常・乗継：受託から搭載までと、短い乗り継ぎ時間の確認。
• 手荷物例外：読めないタグ・未搭乗旅客・便変更・RUSH手荷物。
• 障害条件：通信断・DCS遅延・夜間ピークを含む条件。

ラボのデモに成功しても、実機の読み取り距離や現場の動線で失敗することがあります。そのため、受入基準は読み取り率、手動エンコード率、重複イベント率のように数値で測れる形にします。また、アラート対応時間、転送荷物の取りこぼし、障害復旧時間も基準に含めます。

本番前には、端末の配布と教育を整えます。さらに、アカウントと権限の設定、監視、バックアップを準備します。そのうえで、問い合わせ窓口とロールバック手順を用意し、1拠点ずつ本番化します。

導入後は、月次でKPIを確認し、規格改定や便数増加に合わせて改善を重ねます。

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

国内で公開されている見積もりは限られています。そのため、ここに示すのは2026年時点で予算を組むための編集用の試算です。これは大規模業務システムの人月相場を土台にした目安で、BRSの定価ではありません。

試算には、空港固有の端末・現場試験・24時間運用・既存設備との連携を加味しています。ただし、金額は空港数・年間手荷物数・便数・利用会社数・既存設備の状態によって変わります。

導入パターン別の初期費用

手荷物管理システムは、導入範囲ごとに初期費用と期間を見積もります。

• 小規模SaaS・パッケージ：500万〜1,500万円、2〜4か月。
• 1空港・1社の連携型BRS：1,500万〜5,000万円、6〜12か月。
• 複数空港・複数社の共通基盤：5,000万〜1.2億円、12〜18か月。
• BHS設備まで刷新：1億〜数億円以上、18〜36か月となる場合があります。

小規模案は、1拠点、限定便、主要な1連携を前提とし、スキャナー設定と管理画面も想定しています。

連携型BRSは、DCS・BHS・AODBへの接続と、四地点の追跡・端末・例外処理・オフライン同期に加え、総合試験と教育も含む想定です。

さらに、共通基盤ではマルチテナントや権限・監査も加わります。インタライン・ハンドラー連携、BIX・Type B変換、冗長化、データ移行も含みます。

BHS刷新の金額は、BRSだけの開発費ではありません。対象は、搬送・ソーター・保管・検査の設備です。ネットワーク・制御系の工事も含めた、大規模刷新の目安です。

人件費・端末費・運用費の内訳

予算を組むときは、費目ごとに仮の比率を置きます。比率はそのまま使わず、機能別WBS、連携本数、端末台数に分けて見積もります。

• 要件定義・現場調査：10〜15%。
• 連携・メッセージ変換：25〜35%。
• BRS業務機能：20〜30%。
• 端末・ネットワーク・現場対応：10〜20%。
• 試験・訓練・移行：15〜25%。

試験ケース数と現地作業日数も確認します。人月単価の予算の起点は、職種によって異なります。

• PM：月120万〜200万円。
• 上級SE：月80万〜150万円。
• プログラマー：月50万〜100万円程度。

保守・運用費は、初期費用の年10〜20%を仮に置きます。クラウド、通信、端末費は、別の項目として分けます。

24時間監視・現地保守・規格改定対応も分けて扱います。たとえば、初期費用が3,000万円なら保守・運用費は年300万〜600万円です。

初期費用が8,000万円の場合は、年800万〜1,600万円を保守・運用費の枠として置きます。そのうえで、5年間の利用料、更新費、端末交換費をTCO（総所有コスト）で比べます。

効果は、読み取り率だけでなく、転送の取りこぼし、手動エンコード率、誤搭載対応時間で測ります。また、便遅延と、1,000旅客あたりのミスハンドリング件数も指標になります。

SITAによると、2025年のミスハンドリングは24百万件、業界コストは年63億ドルです（出典：SITA「Baggage IT Insights 2026」、2026年）。1件あたりの平均コストは260ドルで、この数値を自社の便数、手荷物数、対応工数に置き換えて使えます。

自社で削減できる損失を試算しておくと、システム導入を経営投資として説明しやすくなります。

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

金額だけを見ると、後から追加費用が発生する提案を見分けにくくなります。そこで、接続・端末・オフライン同期・試験・移行・24時間保守が別料金になっていないかを確認します。また、条件をそろえたRFPを作り、各社から同じ粒度で提案と前提条件を受け取ります。

RFPに記載する条件

対象範囲、接続先、運用条件を具体的に書いておくと、各社の見積もりを比べやすくなります。

• 対象規模：空港・ターミナル、航空会社・ハンドラー、便数と手荷物数（1日あたり）、端末数。
• 設備・追跡：追跡地点、DCS・BHS・AODB・保安設備の製品と接続方式。
• 業務機能：バーコード・OCR・RFID、転送・未搭乗・破損タグ・RUSH荷物。
• データ管理：旅客表示・権限・監査ログ・保管場所・保存期間。

非機能要件には、ピーク処理件数と応答時間、目標稼働率、復旧時間を明記します。また、バックアップ・ネットワーク分離・端末認証・暗号化・脆弱性対応も指定します。さらに、パッチ適用・手動継続・教育時間・国内の現地保守体制も記載します。

国土交通省の安全ガイドラインは、BHSを空港の重要システム例として扱います（出典：国土交通省「空港分野における情報セキュリティ確保に係る安全ガイドライン」第4版、2026年）。同ガイドラインは、運航やサービスへの影響を踏まえた対策も求めています。

パッケージとスクラッチの比較

標準機能や保守を重視するか、独自業務への適合を重視するかで候補を絞ります。

• パッケージ・SaaS：標準機能・航空規格・複数空港展開・保守の面で強い傾向です。
• スクラッチ：共通イベント基盤や独自業務フローを作りやすい方式。

パッケージは規格更新にも強い傾向があります。一方、パッケージでも国内業務・古いBHS接続・通信断・データ所在・端末の選定への対応は確認します。

カスタマイズ費も確認してください。設定費と連携費が膨らむと、総額が個別開発に近づきます。

スクラッチでは、IATA規格改定・24時間可用性・端末・監査・保守要員を自社で担うことになります。そのうえで、初期費用だけでなく5年TCO、追加機能単価、規格改定の責任を比べます。

障害時の応答時間、ソースコードとログの利用権も確認します。候補会社には「IATA 753対応」の範囲を具体的に尋ねます。四地点の証跡、通信断後の同期、DCS停止時の手動切替を、実機に近い条件でデモしてもらいます。

契約・受入で確認するリスク

契約時に変更条件と責任分界を定めておくと、追加費用や復旧の遅れを抑えられます。

• 契約範囲：請負・準委任、成果物・変更管理・受入条件、遅延時の扱い。
• 権利・費用：データ・ログの所有権、第三者ライセンス、規格改定費。
• 追加開発：便数増加、新ハンドラー参加、空港設備更新時の境界。

DCS側かBHS側かの責任が曖昧だと、障害からの復旧が遅れるおそれがあります。

受入では、四地点のイベント完全性・未搭乗アラート・タグ再発行・便変更を試験します。さらに、重複スキャン・通信断・端末故障・BHS停止・DCS遅延・権限外アクセスも確認します。現場担当者が実際の動線に沿って操作し、手作業後の復旧データの統合まで確かめたうえで、本番へ移行します。

よくある質問（FAQ）

開発期間、パッケージとスクラッチの選び方、IATA Resolution 753への対応、通信障害時の運用について、発注前によくある質問を取り上げます。

手荷物管理システムの開発期間はどのくらいですか？

1拠点・限定便のパッケージは2〜4か月、1空港の連携型BRSは6〜12か月が目安です。また、複数空港の共通基盤は12〜18か月、BHS設備・制御刷新は18〜36か月以上を見込みます。さらに、現場調査・空港側の承認・夜間試験・教育・段階移行も日程に含めます。

手荷物管理システムはパッケージとスクラッチのどちらがよいですか？

標準対応、複数空港展開、保守を重視するなら、パッケージを基盤にしたSIカスタマイズが有力です。

独自業務や複数社共通基盤にはスクラッチも候補ですが、規格改定や保守体制が必要です。機能適合率に加え、5年TCOと障害時の責任分界で判断してください。

IATA Resolution 753に対応するには何が必要ですか？

対応範囲は、追跡地点、データ連携、例外時の処理、標準要件の反映に分けて確認します。

• 四地点の追跡：受託・搭載・転送エリアへの引き渡し・到着時の返却を記録し、監査証跡を残します。
• データ連携：スキャン機器に加え、DCS・BHS・AODBとの接続、インタライン情報の共有。
• 例外処理：読み取り失敗の代替手順の設定と、イベントの欠損・重複の検知。
• 要件への反映：業務、契約、システム仕様に標準要件を反映し、航空会社や空港の最新方針を確認します。

通信障害が起きたときも手荷物を処理できますか？

オフライン対応を要件に含めれば、通信障害の間も処理を続けられます。さらに、手作業への切替も含めて設計しておきます。

• 保存・同期：端末にイベントを一時保存し、通信復旧後に同期します。
• 同期時の検証：時計ずれ・重複スキャン・順序逆転・タグ番号の再発行の確認。
• 手作業への切替：障害中は紙リストや手動照合を使い、復旧後に責任者が手入力データを承認します。
• 運用訓練：一連の切替と復旧を訓練し、現場の混乱を抑えます。

まとめ

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と障害時の責任分界を比べます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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