手荷物管理システム開発の完全ガイド

手荷物管理システムは、BRSとBHSの役割分担、4地点の追跡、導入方式の3点を整理して設計すると、紛失や誤搭載の防止と原因の確認に役立ちます。

システムの役割、開発方式、費用、導入手順、選定と発注の要点を順に一覧で確認できます。各テーマの詳細は、関連記事もご覧ください。

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

手荷物管理システムの定義

記録された情報が、現場をまたぐ確認の共通基盤になります。

手荷物管理システムは、手荷物の所在と状態をイベントとして記録する仕組みです。さらに、関係者が同じ情報を参照できます。

この仕組みの価値は、紛失・遅延・誤搭載を防ぐことと、問題が起きたときに読み取り場所や時刻、担当者、端末を確認できることにあります。

BRSとBHSの役割の違い

手荷物管理の要件を整理するときは、情報を照合する役割と、手荷物を物理的に運ぶ役割を分けて考えます。

BRS：Baggage Reconciliation Systemの略で、手荷物の照合を担う業務データ基盤です。
BHS：Baggage Handling Systemの略で、コンベヤー、ソーター、保管・検査設備と制御系が手荷物の搬送と仕分けを担います。

BRSは、旅客の搭乗状況と手荷物を照合し、未搭乗旅客の手荷物を搭載しないために使われます。BRSとBHSは連携して動きます。ただし、搬送設備を自動化する役割はBRSには含まれません。

手荷物管理が重要な理由

手荷物管理が重要になる理由は、現場をまたぐ手荷物の流れと、記録の連続性にあります。

現場をまたぐ流れ：チェックインから保安検査、搬送、搭載、乗り継ぎ、到着後の返却まで、複数の現場を通ります。
記録の分断：担当の組織やシステムが切り替わる場面では、照合漏れや引き継ぎミスが起きやすくなります。

IATAによると、2024年のミスハンドリングは旅客1,000人あたり6.3個で、年間では3,340万個にのぼります（出典：IATA Baggage Tracking、2026年閲覧）。

この規模を踏まえ、開発では追跡情報を初めから一貫して記録する設計にします。

手荷物の流れと主要機能

節目ごとに時刻・位置・担当主体を定める構成です。

要件は、手荷物が通過するイベントを起点にして整理します。

手荷物番号と旅客、便を同じ履歴で結びます。さらに、搬送先やコンテナ、ULDの情報も加えます。読み取り位置、担当者、時刻まで含めると、通常運用と例外運用の両方を設計しやすくなります。

最低限押さえる4つの追跡地点

IATA Resolution 753は、少なくとも次の4地点で追跡する考え方を示しています。

航空会社への引き渡し：旅客から手荷物を受け取った時点
航空機への搭載：機体に手荷物を載せた時点
乗り継ぎエリアへの引き渡し：乗り継ぎ場所へ渡した時点
旅客への返却：到着後に手荷物を返した時点

これは日本の法令そのものではありませんが、RFPで追跡範囲を合意するための基準になります（出典：IATA Baggage Tracking）。

各地点について、時刻と位置、担当主体を定めます。さらに、読み取り方法と失敗時の扱いも決めておきます。

連携する周辺システム

連携先ごとに役割とデータの正本を整理しておくと、項目の食い違いを防げます。

DCS：搭乗管理を担います。
AODB：便、ゲート、時刻の管理です。
BHS：搬送設備の制御を担当します。
その他：保安検査設備、チェックイン端末、問い合わせ窓口です。

便名と便の一意キーが異なると、同じ荷物が別物として登録されます。手荷物番号や時刻の基準がずれた場合も、同じ問題が起きます。

要件定義の段階で、各項目の正本、更新の順序、重複イベントの扱いを決めておきます。

例外処理と監査ログ

現場では、正常時のスキャンに加えて、例外の状態を個別に管理する設計が欠かせません。

読み取り・通信：タグ破損、読み取り失敗、通信断が該当します。
便・手荷物：未接続便、転送、RUSH、不搭乗、便変更の状態です。

アラートの後には、誰が確認し、取り降ろしや再搭載をどう判断したかを記録します。

監査ログには、端末IDや担当者、位置、時刻に加えて、元データと訂正履歴を残します。これらの記録は、原因の分析と説明責任に役立ちます。

手荷物管理システムの種類と選び方

方式の選択肢は4つあります。クラウド、航空業務向けパッケージとSIカスタマイズ、独自開発、BHS刷新を含む統合案件です。

適した方式は、空港数や手荷物量に加え、既存のDCS・BHS・AODBや運用主体によって決まります。通信環境や規格改定への対応力も関わります。

クラウドサービス・パッケージ

短期間で標準機能を使いたい場合は、クラウドサービスやパッケージが候補になります。

導入・保守：初期開発を抑えやすく、規格更新や共通機能の保守を任せやすい方式です。
標準範囲：空港固有の業務や古い設備との接続が難しい場合があります。
契約前の確認：オフライン保存、課金単位、データ保管場所、障害時のサポート時間を見ておきます。

パッケージを基にしたSIカスタマイズ

標準的なBRS機能を使いつつ、既存設備や国内運用に合わせたい場合に現実的な方法です。

拡張範囲：業務イベントと連携部分を拡張すれば、全面開発よりリスクを抑えられます。
追加費用：標準外の改修が増えると、バージョンアップのたびに費用が発生する場合があります。
責任分界：製品本体と個別改修の担当範囲は、事前に決めます。

スクラッチ開発

複数の事業者が共通で使うイベント基盤や、既存製品では表現しきれない独自の運用が、検討の対象になります。

要件への適合：データモデル、画面、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時間運用：終日稼働させる運用の有無
保安要件：保安面で求められる条件

金額だけで妥当性を判断しないでください。

導入規模別の費用目安

構成ごとの初期費用と期間は、対象範囲をそろえて比べます。

小規模導入：1拠点、限定便、スキャナー設定、主要1連携、管理画面
連携型BRS：1空港・1航空会社で、周辺システムと4地点を連携
共通基盤：複数空港・複数社向けに権限、監査、冗長化、移行を実施
設備を含む刷新：搬送・保安設備、ネットワーク、現場工事まで更新

小規模なSaaS・パッケージ導入の初期費用は500万〜1,500万円が目安で、期間は2〜4か月程度です。

連携型BRSは1,500万〜5,000万円、期間は6〜12か月程度を見込みます。この費用には、DCS・BHS・AODBとの連携、4地点追跡、例外処理、オフライン同期、総合試験、教育を含みます。

複数空港・複数社の共通基盤は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万円です。
別建ての可能性：クラウド利用料、通信、端末、24時間監視、現地保守、バックアップ、規格改定対応が、別途かかる場合があります。
5年TCO：利用料、保守、端末交換、追加連携、障害対応を合計し、初期費用だけでは選ばずに比べます。

▶ 詳細はこちら：手荷物管理システム開発の見積相場・費用

ポイント

費用は構成と対象範囲をそろえて比べます。初期費用に加えて、運用費や追加費用を含めた5年TCOで比べると、金額の差の理由が見えてきます。

開発会社・サービスを選ぶときのポイント

知名度や機能数よりも、現場の責任を最後まで担えるかを確かめます。

BRS、BHS設備・制御、可視化・分析、共通基盤など、得意な領域は事業者ごとに異なります。そのため、案件の範囲を明確にしてから比べます。

航空・空港業務の経験の確認

「IATA 753に対応」と説明されたときは、例外時の運用を実演してもらい、中身を確かめます。

追跡・照合：4地点の証跡、転送、未搭乗、再搭載
現場対応：手動エンコード、通信断、便変更

公開できる範囲で、同規模空港などでの導入工程、ピーク時の処理量、障害復旧の実績、国内の保守体制も確かめます。

連携・運用・保守の範囲の比較

見積書を比べる際は、連携・運用基盤の対象範囲をそろえて見ます。

連携・基盤：DCS、BHS、AODB、保安検査、端末、認証
運用・保守：監視、バックアップ、一次受付、駆け付け、代替機
変更対応：規格改定、OS更新、追加拠点、追加費用

ソフトウェアと設備の事業者が別々の場合は、障害の原因を互いに押し付け合わない契約になっているかを確かめます。

5年TCOと体制の点数化

候補の差を公平に見比べるため、評価軸と重要度をそろえて採点します。

評価項目：機能、連携、現場試験、可用性、セキュリティ、保守、費用、拡張性を見ます。
採点方法：各項目を5段階で採点し、重要度に応じて重み付けします。
候補の違い：安価でもオフラインに弱い候補や、高機能でも既存設備との接続費が大きい候補を見分けます。

提案担当者が、導入後も責任者として関わるかを確かめます。対象は、プロジェクトと運用の両方です。

▶ 詳細はこちら：手荷物管理システム開発でおすすめの開発会社6選と選び方

ポイント

開発会社は、航空・空港業務の経験があるか、連携と運用保守の範囲を同じ条件で比べられるかで見ます。費用は5年TCOと体制を点数化して、候補の差を公平に比べます。

発注・外注・委託を成功させる進め方

手荷物管理では、発注する主体と利用する主体が異なることがあります。たとえば、航空会社が発注し、空港やハンドラーが運用する場合もあります。

発注側と開発会社は、契約の前に、データの正本を持つ人、アラートへの対応者、障害時の手動切替の担当者を決めて、合意しておきます。

RFPに書くべき項目

提案の条件をそろえるため、対象範囲と運用条件をRFPに記載します。

規模・処理量：空港、ターミナル、便数、年間・ピーク時の手荷物数
設備・追跡：端末台数、4地点、連携先、BRSとBHSの範囲
運用・品質：保管期間、権限、可用性、復旧時間
移行・継続：メッセージ移行、オフライン時間、手動切替、試験データ準備者

Type BからBIXなど、新しいメッセージ方式へ移行する可能性も、RFPに明記します。

「標準対応」と書かれた項目は、証跡とデモで実際にできるかを確かめます。

契約・受入テスト・SLAの取り決め

契約方式、受入基準、障害時のサービス条件を、あわせて決めます。

契約形態：企画・現場調査は準委任、仕様確定後の開発・移行は請負にするなど工程別に検討します。
受入テスト：4地点の証跡、重複イベント、通信断後の再同期、端末故障、DCS停止、便変更、権限外閲覧を検証します。
SLA：稼働率、障害の重要度、一次応答、復旧目標、代替手段、報告期限を定めます。

データ・ログ・追加費用の扱い

運用中や契約の終了時に備えて、データ管理と変更費用の条件を整理しておきます。

所有・返却：手荷物番号、旅客・位置情報、監査ログの所有者と、契約終了時の返却形式を決めます。
保管・閲覧：ログの保存期間、バックアップ頻度、削除手順、個人情報の閲覧権限を定めます。
保守費の範囲：規格改定、OS更新、追加空港、端末増設、連携変更をどこまで含むかを明確にし、予算超過を防ぎます。

▶ 詳細はこちら：手荷物管理システム開発の発注・外注・委託方法

ポイント

発注先を決める前に、データの正本、訂正の担当、障害時の手動切替の担当を、契約の範囲と合わせて決めているかが判断の目安です。ソフトと設備の事業者が別々なら、責任の境界も確かめます。

2026年の最新動向と導入効果の測り方

手荷物管理は、バーコードからRFID、OCR、画像、位置情報、リアルタイム分析へと広がっています。

効果を得るには、技術を増やすことより先に目的を決めることが大切です。精度を上げたいイベント、早めたい判断、減らしたい例外を決めたうえで、必要な場所から段階的に導入します。

Type BからBIXへの移行

航空業界では、従来のType BメッセージからBIXへ移行する動きがあります。

BIXの仕様：構造化され拡張しやすく、主要版は2025年に公開され、RP1755に基づくイベント共有の方法を示しています。
共有する関係者：航空会社、空港、ハンドラー、技術提供者です（出典：IATA Baggage Information eXchange、2026年閲覧）。
新規開発：既存電文を固定しない、変換層や将来方式を想定したデータモデルにすると、移行時の改修を抑えやすくなります。

導入前後の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は、別々の役割を持つシステムです。BRSは手荷物と旅客、便を照合し、搭載状態や例外を管理します。一方、BHSはコンベヤーやソーターなどで手荷物を物理的に搬送し、その制御も担います。

両者を統合して発注する案件もあります。ただし、RFPと見積で機能範囲を分けておくと、費用と責任分界を把握しやすくなります。

通信が切れても手荷物を処理できますか？

オフライン運用は、イベントの保存から復旧後の同期まで要件として定め、確かめておきます。

オフラインでの継続を要件として定め、端末や拠点側にイベントを保存します。
通信が復旧したら、順序、重複、時刻を検証してから同期します。
通信断の最大時間、端末の保存件数、認証の有効期限、再送失敗時の対応を決めます。
実際にネットワークを切断し、動作を確かめます。

パッケージとスクラッチ開発はどちらがよいですか？

標準業務、短期導入、複数拠点への展開、規格更新の保守を重視するなら、パッケージやクラウドが向いています。

独自の責任分界やデータモデルが必要な場合や、複数の事業者で使う共通基盤では、SIカスタマイズやスクラッチを検討します。

迷う場合は、1拠点のパイロットで標準機能との差を測ってから、5年TCOと運用体制で判断します。

まとめ

手荷物管理システムは、BRS照合、BHS搬送、4地点追跡を中心に、次の機能も一体で設計する業務基盤です。

DCS・AODB連携：周辺システムとのデータ連携
例外処理：読み取り失敗や便変更などの扱い
オフライン同期：通信断後の記録の同期
監査ログ：担当者や時刻などの記録
手動継続：システム停止時の手作業による運用

タグの読み取りは、その一部です。

導入判断で外せない3つの視点

導入後の認識ずれを防ぐため、次の視点を判断条件に反映します。

4地点の追跡を、業務イベントと証跡に落とし込みます。
端末・通信・保守・規格改定・障害対応を含む5年TCOで方式を比べます。
通信断、読み取り失敗、便変更、DCS停止、手動切替を現場試験します。

この3点をRFP、契約、受入条件に反映しておくと、導入後の認識ずれを減らせます。

次に作成する資料

提案や見積を同じ条件で受けるため、事前にそろえておく資料を整理します。

資料：業務フロー、システム関連図、4地点のイベント定義、連携・例外処理一覧、KPI、RFP、パイロット計画を用意します。
見積条件：対象拠点、便数、端末数、既存設備、通信環境を具体的に決め、同じ条件で提案と見積を受けます。
目標：システムと運用の両面から、安全な搬送と旅客への説明責任を果たすことを目指します。

▼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を創業。