共同配送システムは、複数社の配送計画と費用配賦を一つの仕組みで管理するためのシステムです。導入では、対象区間、共有ルール、参加企業を整理し、PoCから段階展開へ進めます。費用は荷主数や拠点数などで変わるため、要件を分けて見積もります。
▼関連記事一覧
・共同配送システム開発の進め方/やり方/流れや方法/手法/工程/手順
・共同配送システム開発でおすすめの開発会社/ベンダー6選と選び方
・共同配送システム開発の見積相場や費用/コスト/値段について
・共同配送システム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
共同配送システムの全体像
共同配送システムは、複数社の出荷情報を集約する企業間連携の基盤です。そのため、荷主、運送会社、共同配送センター、納品先が必要な情報を共有できます。
集荷から配送、実績確認、費用精算までを同じ流れで管理できます。一方で、締め時間や荷姿、納品条件、責任分界は各社で異なるため、それらも同じ仕組みで扱います。
共同配送が成立する仕組み
共同配送は、出荷情報の取込から荷主別の費用配賦までをつなぐことで成り立ちます。計画の段階では、次の条件を照合します。
- 出荷条件：納品先、数量、重量、サイズ、温度帯、納品期限、時間指定、荷姿
- 輸送条件：便・車両・ドライバーの割当、集約と仕分け、配送、納品実績
- 計画条件：混載可否、積載率、走行距離を照合し、対象外の荷物を除く
基本の流れは、まず出荷予定を取り込み、候補を抽出して便を割り当てるところから始まります。
その後、拠点で集約と仕分けを行い、配送して実績を登録したら、最後に費用を配賦します。
荷主ごとに形式の違うCSVは、共通項目に変換してから候補を作ります。
重量が欠けたデータや古い納品先マスタを残したままにすると、積み直しや再配車の原因になります。
入力時のチェック、マスタの更新責任者、連携が失敗したときの再送手順も、要件に含めます。
共同配送の主な種類
共同配送は、輸送区間によって主に三つに分かれます。方式ごとに、まとめる区間と運用上の注意点が異なります。
- 幹線共同化：同じ方面の荷物を中継拠点までまとめ、長距離輸送の車両や便数を見直す
- センター共同化：複数荷主の荷物を集約・仕分けし、納品先別に再構成する
- ラストワンマイル共同化：最終納品先に近い区間をまとめる。時間指定や再配達の扱いが課題
食品や医薬品は温度帯と衛生管理、重量物や長尺物は車格の制約があるため、混載条件を厳しくする必要があります。
そのため、常温の荷物や定期便、同一地域の配送など、条件のそろう範囲から始めます。こうすると、効果と運用負荷を比べやすくなります。
TMS・WMS・配車管理システムとの違い
各システムは、管理する業務の範囲が異なります。一方で、共同配送システムは企業間の連携まで扱います。
- TMS：輸送計画、配車、配送実績など輸送全体を管理する
- WMS：倉庫内の入荷、保管、ピッキング、出荷を管理する
- 配車管理：車両、ドライバー、ルートの割当を中心に管理する
- 共同配送：荷主間の権限、共有範囲、混載条件、費用配賦も扱う
共同配送システムには、TMSやWMSの機能が含まれる場合もあります。また、既存システムを各社に残し、出荷予定と配送実績だけをAPI、EDI、CSVで連携する構成も選べます。
二重入力を防ぐため、どの情報をどのシステムの正とするかを先に決めておきます。
共同配送システムで変わること
複数社の貨物を同じ条件で比べると、車両の空きや積載余力を計画に反映しやすくなります。ただし、導入しただけで荷物が集まるわけではありません。
参加企業が増えるほど、調整する相手も増えます。
そのぶん、品質、責任、情報共有のルールを設計しておく必要があります。
期待できる効果
共同配送で期待できる効果は、輸送効率、作業負荷、実績分析の三つの面にあります。
- 輸送効率：積載率の向上、車両・便数の適正化、空車回送の削減
- 作業負荷：ドライバー拘束時間や、訪問回数・荷待ちを減らせる場合がある
- 実績分析：荷主別の物流単価やCO2排出量を比べ、改善案を検討する
国土交通省が2026年度の物流効率化法対応で示す特定事業者の基準は、荷主の取扱貨物重量9万トン以上です。
貨物自動車運送事業者は保有車両150台以上、特定倉庫業者は保管量70万トン以上です（出典：国土交通省「物流効率化法」理解促進ポータル、2026年）。
該当するかどうかにかかわらず、荷待ち・荷役時間や積載効率を測るデータ基盤は、経営判断に役立ちます。
導入前に知っておきたい課題
導入前に特に把握しておきたいのは、荷量、混載条件、事故時の責任の三つです。
- 参加企業・荷量：参加企業が想定どおり集まらず、荷量が少ないと仕分け費用だけ増える可能性がある
- 混載条件：納期や荷姿が違うと、計画上同じ便でも混載できない
- 責任分界：破損・欠損・遅延時に、顧客へ連絡する企業と費用負担が曖昧になる
対象外の条件と例外処理は、要件定義の段階で決めておきます。
緊急出荷、返品、温度逸脱の扱いを先に整理し、納品先不在、車両故障、連携停止についても、扱いを決めます。
例外の処理は、通常便とは別の承認フローを用意しておくと、電話や個人の表計算へ戻るリスクを下げられます。
共同化に向いている業務の条件
共同化への適性は、配送条件と荷量の実績から判断します。次の条件がそろっていると、計画の組み立てが進みます。
- 配送先・出荷量：配送先が近く、定期的な出荷量がある
- 荷姿・温度帯：荷姿や温度帯がそろっている
- 時間条件：納品時間に幅があり、出荷締め時間を合わせられる
時間指定が個別に多い業務や、荷姿が毎回変わる業務、特殊車両が必要な業務は、共同化の範囲を限定するか、専用便として扱うかの判断が必要です。
荷主数に加えて、曜日・時間帯別の荷量と配送先の重なりを確認します。
車両の空きや返品頻度も、あわせて見ておきます。
平均値に加えて、繁忙期と閑散期を分けて試算し、最低限必要な荷量を定めます。
共同配送システム開発の進め方
機能一覧から始めると失敗しやすいため、共同化の区間、データの閲覧範囲、効果の測定方法を先に決めてから進めます。
工程は、現状調査、ルール定義、PoCの順に進みます。その後は、本番開発、テスト、段階展開へ移ります。どの工程でも、現場と経営の合意を得ながら進めます。
▶ 詳細はこちら：共同配送システム開発の進め方/やり方/流れや方法/手法/工程/手順
現状調査と共同化範囲の決定
荷主ごとの条件と実績の違いを把握しておくと、共同化する範囲を判断しやすくなります。
- 出荷・納品：締め時刻、集荷・納品時刻、商品区分、荷姿、重量、配送先
- 輸送・例外：車格、返品、再配達、既存システム
- 実績データ：直近数か月分を曜日・地域・時間帯別に整理し、通常期と繁忙期を比べる
数字が取れない項目は、開発に入る前に現場で計測しておきます。
共同化の区間は、幹線だけか、センターまでか、店舗配送までかといった範囲から決めます。
温度帯や危険物、時間指定などの対象外条件は、返品や荷役設備と合わせて文書にまとめます。
範囲を広げるほど効果の余地は広がる一方で、企業間の調整や例外処理も増えます。そのため、最初は範囲を狭く始めると、結果を見てから次を判断できます。
共通データと業務ルールの定義
企業間の連携では、データ項目と業務ルールを先にそろえておく必要があります。情報ごとに、定義する内容をそろえることも欠かせません。
- 共通項目：出荷、運送計画、配送実績の項目名・単位・コード
- 更新・エラー：更新時点、必須・任意、エラー発生時の扱い
- 閲覧範囲：全参加者、運送会社、各荷主が見られる情報を分ける
国土交通省は2025年2月、物流情報標準ガイドラインをver3.00に改訂しました。
共同輸配送や物流DXの前提となる標準化を進めています（出典：国土交通省「物流情報標準ガイドラインをver3.00に改訂しました」、2025年）。
基盤には顧客名や個人情報を持たせず、配送先を識別子に置き換える設計も選べます。
破損時の責任と遅延時の連絡、費用配賦を決めておきます。緊急出荷の割増や計画変更の承認者も、あらかじめ定めます。そのうえで、利用規約や業務マニュアルとの整合も確認します。
小規模PoCによる効果と負荷の検証
本番開発の前に、対象を1地域、1配送ルート、1〜2社などに絞ります。そして、実際の出荷データを使って、次の指標を測ります。
- 輸送効果：車両削減台数、混載候補の割合、積載率
- 作業負荷：配車作成時間、荷待ち時間、現場入力時間、再配車回数
- サービス・採算：納品遅延、荷主別単価
画面の使いやすさも検証します。具体的には、通信が不安定な場所での登録、例外便の承認、荷主が自社の実績だけを見る操作を試します。
AIによる需要予測や自動最適化は、正確な実績データがたまった後に段階的に導入します。そうすると、結果の理由を現場に説明できます。
本番開発・テスト・段階展開
本番化では、まず必要な機能を整理し、そのうえで機能と連携方式の優先順位を決めます。
- 業務機能：出荷取込、マスタ、候補抽出、配車、配送状況、実績、費用配賦、KPI
- 連携先：受発注、ERP、WMS、運行管理、GPS、EDI
- 段階連携：APIが難しい場合はCSVを暫定利用し、将来の自動連携に備える
テストでは、欠損や重複のあるデータ、車両故障、納品先の変更を想定します。通信断や急な追加出荷も、テストに含めます。
温度異常、遅延、請求差異の確認も必要です。
リリース後は、地域や荷主を段階的に増やしながら、KPIと問い合わせの状況を追います。
新しい便を増やす基準と、旧運用へ戻す条件は、事前に決めておきます。
共同配送システムの費用相場とコストの内訳
費用は、荷主数や拠点数、車両台数で変わります。既存連携の有無、センターの有無、費用精算の複雑さも影響します。
ここに示す金額は、公開相場に企業間連携などの要件を加えた、編集部の推定です。
特定サービスの定価ではないため、発注時は要件を分けて見積もります。
▶ 詳細はこちら：共同配送システム開発の見積相場や費用/コスト/値段について
方式・規模別の費用目安
費用と期間の目安は、方式と規模によって変わります。金額は、一般的な推定レンジです。
- クラウド型TMS・SaaS：1拠点・少数荷主なら初期0〜100万円程度、月額数万円〜30万円程度
- 小規模な個別開発：100万〜300万円程度
- 中規模導入：400万〜1,000万円程度
- 本格的な基盤：1,000万〜3,000万円以上。多拠点・多荷主では3,000万円から数億円規模の場合もある
クラウド型の想定は、標準CSVの取込と基本配車、配送実績、スマートフォン運用の範囲です。月額は、利用者や車両の数、API回数によって変わります。地図の利用量やサポート範囲でも変わります。
多拠点・多荷主でERPやWMS、EDI、GPSを連携すると、費用は大きくなります。権限や配車最適化まで作り込むと、費用はさらに増えます。請求や監査ログ、BCPも含めると、なお負担が重くなります。
期間の目安は、SaaS導入で2週間〜3か月です。小規模開発は2〜4か月、中規模は4〜8か月、本格基盤は8〜18か月です。
企業間の合意形成やデータクレンジングが長引くと、開発前の準備期間が延びます。
費用を構成する項目
見積は、初期構築と継続費用を分けてもらい、どこに費用がかかるかを確認します。
- 初期構築：要件定義、業務整理、画面・権限、データ基盤、配車ロジック
- 連携・運用準備：地図・GPS、アプリ、既存連携、センター作業、請求・費用配賦、テスト・教育
- 継続費用：クラウド、地図API、SMS、GPS通信、監視、保守・改善
見積が一式にまとめられていると、予算調整でどこを削るかを判断しにくくなります。そのため、項目別の金額を出してもらいます。
荷主ごとの運賃や積替費、保管費は、費用に影響します。作業費と緊急便の割増も、見積に含めて確認します。
重量、容積、パレット数を組み合わせて費用を計算する場合は、計算式に加えて、データの確定日と修正権限が必要です。走行距離や荷役時間を組み合わせるときも、確定日の扱いを決めておきます。
月次請求の差異をたどれるよう、明細と監査ログも要件に含めます。
費用を抑える現実的な方法
対象を絞ったPoCで実績を確認してから本番化すると、開発範囲を段階的に調整できます。
- PoCの範囲：1地域・1ルート・1〜2社に絞る
- PoC費用：100万〜500万円程度の推定レンジ
- 対象機能：出荷取込、候補抽出、配車、配送実績、効果測定
本番では、効果を確認できた機能を優先し、不要な画面や複雑な自動化は後回しにできます。
既存のWMSや受発注システムは置き換えず、必要なデータ連携と実績管理だけを追加する方法もあります。
連携を簡略化しすぎると、二重入力や転記ミスが増えます。そのため、暫定CSVの期限、API移行の条件、担当者を決めておきます。
パッケージ・クラウド・スクラッチの選び方
開発方式は、パッケージやクラウド型サービス、スクラッチ開発から選びます。ハイブリッド方式は、これらを組み合わせる形です。
比べるときは、初期費用に加えて、荷主や拠点、連携先の追加を見ます。データ返却や契約終了、障害時の代替運用も、あわせて比べます。
パッケージ・SaaSを使う場合
標準機能を使う方式では、どこまでが標準範囲で、どこからが追加開発になるかを、契約の前に見極めます。
- 導入のしやすさ：サーバー調達が不要。標準機能を使え、少数荷主や標準化した運用に向く
- 追加開発：荷主別権限、特殊な混載条件、独自配賦、基幹連携は追加開発になる場合がある
- 月額の単位：ユーザー、車両、拠点、配送件数のどれに課金されるか確認する
- 契約条件：API上限、CSV仕様変更、サポート時間、復旧目標、バックアップ、データ返却形式を確認する
- 試用：無料トライアルがあれば、匿名化した実データで候補精度と入力負荷を試す
スクラッチ・ハイブリッドを使う場合
スクラッチ開発では、独自の要件を細かく設計できます。一方で、要件定義が不足すると、作り直しにつながります。
- 個別設計できる要件：企業間権限、配車条件、料金配賦、特殊商材、基幹連携
- 開発後の確認：保守・改善の責任、ソースコード、データの扱い
- ハイブリッド：標準TMS・SaaSに、マッチングやデータ変換、配賦、権限を追加する
ハイブリッド方式は、標準部分の更新を受けながら、独自の要件もシステムに反映できます。そのため、費用、期間、拡張性のバランスをとれます。
スクラッチ開発では、運用後の改善体制も開発会社に確認します。
企業間システムに必要なセキュリティ
企業間で荷主や配送先の情報を扱うため、権限と保護策を要件に含めます。
- アクセス管理：テナント分離、最小権限、多要素認証、API認証
- 情報保護：通信・保存時の暗号化、監査ログ、バックアップ、脆弱性対応
- 閲覧範囲：自社実績、匿名化した共同計画、運営者向け管理情報を分ける
国土交通省は、物流分野の貨物自動車運送・倉庫に関する情報セキュリティ安全ガイドラインを公開しており、2026年7月にも改訂版が示されています（出典：国土交通省「物流分野における情報セキュリティ確保に係る安全ガイドライン」）。
システムの安全性に加えて、委託先の管理とインシデント時の連絡を確認します。復旧目標や代替輸送も、あわせて確認します。
障害が起きたときに備えて、紙や電話を使う手順も用意します。
共同配送システムの開発会社・ベンダーの選び方
開発会社やベンダーは、複数社の業務設計、データ連携、運用定着を支援できるかどうかで比べます。
物流事業者、SaaS提供者、受託開発会社では、契約の形態も責任の範囲も異なります。そのため、同じ質問票を使って対応範囲を確認します。
共同配送の実績と得意領域の確認
実績は、規模や商材、地域と期間を確かめます。あわせて、自社に近い運用経験があるかも質問します。
- 運用規模：何社・何拠点・何台を支援したか
- 輸送領域：幹線、センター、店舗配送、地域配送のどれか
- 商材：食品、日用品、医薬品、重量物などの経験
削減率を示された場合は、比較期間と対象便を確認します。そのうえで、荷量や繁忙期、車両・人員の数え方も見ておきます。
他社の実績と同じ成果が出る保証はありません。そのため、PoCで検証するKPIと合わせて評価します。
連携・権限・障害対応の比較
RFPには、連携の対象と運用時の責任を記載します。そして、各社に確認する項目をそろえます。
- 連携先・頻度：受発注、ERP、WMS、運行管理、GPS、EDI
- 権限管理：テナント分離、閲覧範囲、承認権限、退職者の停止
- 障害対応：ログ保存期間、検知時間、再送方法、代替手順、復旧目標
データの正確性を誰が保証し、連携の失敗を何分以内に検知するかまで、具体的に決めます。
紙の出荷一覧や電話連絡など、配送を止めない代替手順を用意します。
バックアップの頻度、災害時の拠点切替、夜間・休日のサポート範囲は、見積書と契約書に反映します。
クラウドサービスでは、終了時のデータ返却形式と移行支援も確認します。
見積・契約・運用支援の範囲の統一
複数社に依頼するときは、同じRFPで提案の条件をそろえます。対象と納品物も、明記しておきます。
- 対象：荷主、拠点、車両、区間、連携先、必要画面
- 検証条件：KPI、PoC期間、納品物
- 契約範囲：要件定義、設計、開発、テスト、教育、導入支援、保守
追加費用の条件も、明示してもらいます。また、提案の前提が現場に合っているかを、価格とあわせて見ます。
物流業務を委託するか、システム開発だけを発注するかによって、責任の範囲は変わります。
配送品質や荷役も委託する場合は、物流業務委託の条件を確認します。自社で運用する場合は、開発と保守の契約を確認します。
荷主追加の支援や改善会議の担当を決めます。マスタ管理と問い合わせ対応も、担当を分けて定めます。
▶ 詳細はこちら：共同配送システム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：共同配送システム開発の発注/外注/依頼/委託方法について
導入後の運用・KPI・法制度対応
本番稼働後は、計画を作ったかどうかより、現場の配送が改善したかを継続的に確認します。
KPIは車両削減だけに絞らず、輸送と作業の指標を品質や環境の指標と組み合わせます。荷主別の採算と、共同全体の効果も分けて見ます。
削減率だけで判断しないKPI設計
積載率が上がっても、積替えや荷待ちが増えれば生産性が下がる可能性があります。そのため、複数の指標を同じ期間で比べます。
- 費用・輸送：配送1件あたり費用、車両1台あたり荷量
- 時間・品質：拘束時間、納品遵守率、納品遅延、荷役時間、問い合わせ件数、再配車、入力時間
- 運用：積載率、空車走行、走行距離、荷待ち時間、CO2排出量
改善会議では、目標値だけでなく、悪化した理由と例外件数も確認します。
国土交通省は2026年4月から、一定規模以上の特定荷主や特定物流事業者に、中長期計画と定期報告を求めています（出典：国土交通省「物流効率化法について」、2026年）。
法令への対応を急ぐより、荷待ち・荷役・積載効率の実績を日常業務から蓄積できる設計にします。
参加企業間のルールの定期的な見直し
配送量や参加企業が変わると、当初決めた混載条件や費用配賦が合わなくなります。そのため、月次または四半期ごとに、運用実績を確認します。
- 輸送実績：便別の荷量、遅延、再配車
- 品質・費用：破損、費用差異
- 運用変更：対象外条件、料金ルールを更新する
自動化を進めても、担当者が候補便を選び、変更理由を残せるようにしておくと、現場で説明しやすくなります。
荷主を追加するときは、データ項目とマスタコード、納品条件を受入手順に含めます。責任の範囲や請求方法、セキュリティ教育も、同じ手順の中に入れます。
参加する企業の数よりも、品質と採算を保てる範囲で拡大することを基準にします。
共同配送システムに関するよくある質問
導入前によくある疑問に、対象範囲や費用の面から答えます。既存連携や効果測定についても、続けて取り上げます。
回答は、そのまま使うより、自社の前提に置き換えて読んでください。荷量や納期、荷姿、参加企業数が違えば、答えも変わります。
共同配送システムは何社から導入できますか？
明確な最低社数はありません。行き先や出荷時間が重なる企業なら、2社程度から小規模検証できる場合があります。
荷量が少ない場合や納品条件が合わない場合は、効果が出にくくなります。繁忙期にだけ荷量が増える場合も、効果が出にくくなります。
曜日別や地域別の実績で、混載できる割合を確認してから始めます。
既存のTMSやWMSがあっても導入できますか？
導入できます。既存のシステムを各社の業務に残したまま、必要な情報だけを連携する構成が一般的です。
出荷予定や配送計画、納品実績などを、API、EDI、CSVで連携します。
二重入力を避けるため、商品・納品先・車両マスタの管理元と、連携エラーの担当者を決めます。
共同配送システムの費用はどのくらいですか？
標準的なクラウド利用は、初期0〜100万円程度、月額数万円〜30万円程度が目安です。企業間連携や請求の配賦を加える場合は、個別見積もりになります。
個別開発は100万〜300万円程度から、中規模導入は400万〜1,000万円程度、本格基盤は1,000万円以上と推定されます。
対象範囲を絞ったPoCで効果と費用を確かめてから、本番化します。
導入効果は車両削減だけで判断してよいですか？
効果は、車両削減に加えて、輸送効率と配送費用を導入前後で比べて判断します。作業時間や納品品質も、同じ期間で見ます。
細かく見るなら、積載率や空車走行、配送単価を導入前後で比べます。荷待ち・荷役時間や納品遵守率、再配車を追うと、現場の状況が分かります。入力時間やCO2排出量も、併せて比べます。
積替え作業やシステム運用費も含め、荷主別採算と全体効果を分けると、参加企業間で納得しやすくなります。
まとめ
共同配送システムは、複数の荷主や物流事業者の出荷情報を集約します。そのうえで、配送計画と現場の運用を共通化し、実績や費用配賦も同じ仕組みで扱います。
既存のTMSやWMSを生かしたまま、企業間の共有情報と業務ルールを安全にそろえることが、共同配送システムの役割です。
導入前に決めること
最初に決めるのは、幹線、センター、ラストワンマイルのどこを共同化するかです。
対象商材と対象外条件、参加企業を整理します。共有データや責任の範囲、費用配賦も、整理の対象になります。
その後、1地域・少数荷主のPoCで検証します。積載率や車両台数に加えて、納期と荷待ちを確認します。荷役や入力負荷、採算も見ます。
開発・サービス選びで確認すること
開発会社・ベンダーは、次の観点をそろえて確認します。
- 実績・連携：物流実績、データ連携、荷主間権限、料金精算
- 運用・支援：障害時の代替運用、セキュリティ、導入後の改善支援
- 制度・標準：2026年の物流効率化法対応、物流情報標準ガイドライン
配送実績を改善や報告に使える形で蓄積すると、長期的な効果につながります。
▼関連記事一覧
・共同配送システム開発の進め方/やり方/流れや方法/手法/工程/手順
・共同配送システム開発でおすすめの開発会社/ベンダー6選と選び方
・共同配送システム開発の見積相場や費用/コスト/値段について
・共同配送システム開発の発注/外注/依頼/委託方法について
▼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を創業。