結論：倉庫料金計算システムの開発は、料金表を画面に置き換えるだけではなく、在庫・入出庫・作業実績と契約条件を正しく結び付け、
請求根拠まで追跡できる仕組みにすることが成功の条件です。
「荷主ごとに料金表が違う」「月末のExcel集計に時間がかかる」「請求金額の根拠を説明できない」
と悩む倉庫会社や3PL事業者は少なくありません。この記事では、倉庫料金計算システムの全体像を整理し、
要件整理から選定、設計開発、テスト、稼働、定着までの6フェーズを、実務で使える判断基準とチェック項目に分けて解説します。
公開料金のあるクラウド型WMSの事例と、個別開発の推定レンジも分けて紹介するため、
見積もりを比較するときの土台として活用できます。
▼全体ガイドの記事
・倉庫料金計算システム開発の完全ガイド
倉庫料金計算システムの全体像
倉庫料金計算システムは、3PLや倉庫会社が荷主ごとの契約条件に基づいて、保管料、
入出庫料、荷役料、ピッキング料、梱包料、流通加工料、配送費の立替などを計算し、締め処理と請求書発行までつなげる業務システムです。
単体の請求システムとして作る場合もありますが、計算の元になる在庫・入出庫・作業実績はWMSに蓄積されるため、
実務では「WMSの請求機能」または「WMSと請求・債権管理の連携」として検討する方が自然です。
料金計算の対象は保管料・荷役料・付帯費用です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
保管料は、月末在庫、日次平均在庫、入庫日からの保管日数、坪数、パレット数、ケース数、重量、容積などを基準に計算します。
月途中の入出庫、最低保証量、冷蔵・冷凍など温度帯別の割増、1期から3期までの期間区分を使う契約もあるため、単に月末の数量へ単価を掛けるだけでは不足します。
荷役料は入荷、検品、棚入れ、出庫、ピッキング、梱包、返品、棚卸、ラベル発行などの実績を、荷姿・数量・重量・作業時間別に集計します。
さらに、資材費、緊急作業、再配達、返品、廃棄、割引、最低請求額といった例外を明細へ反映させます。
WMSの実績と請求根拠を一つの流れで管理します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
システムの価値は、請求書を自動出力することだけではありません。
WMSの在庫・入出庫・作業実績、販売管理や会計、EC・OMS、EDI、配送会社のデータをCSVまたはAPIで取り込み。
料金マスタを適用した結果と元データを残すことが重要です。
荷主から「この金額は何に対する請求か」と尋ねられたとき、請求明細から該当する入荷日、出庫伝票、作業者、数量、単価、計算式までたどれると。
説明と訂正が速くなります。
複数荷主・複数倉庫・複数契約・異なる締め日を一元管理し、荷主向けに在庫や請求明細をWeb照会できるようにすると、問い合わせ削減にもつながります。
倉庫料金計算システム開発の進め方
開発は、いきなり製品を選んだり画面を作ったりせず、要件整理、選定、設計開発、テスト、
稼働、定着の6フェーズに分けて進めます。各フェーズの終了条件を先に決め、次の段階へ進む前に料金計算の正しさ、
データ連携、現場の使いやすさを確認します。特に、代表荷主の過去実績で旧計算と新計算を突合する作業を早い段階に置くことが、
導入後のExcel補正を減らすポイントです。
フェーズ1：要件整理で料金表と実績を棚卸しします
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初に、荷主・倉庫・契約・締め日ごとに、料金単位、単価、適用期間、最低料金、割増・割引、例外、手入力の有無を一覧化します。次に、
計算の元データがどこにあるかを確認します。
在庫は月末残高を使うのか日次平均を使うのか、入出庫はWMSの確定実績を使うのか、作業時間はハンディや勤怠から取れるのかを明確にします。
担当者がExcelで補正しているセルは、個人の工夫として残すのではなく、業務ルール、承認、例外処理のどれに当たるかを分解します。
要件定義の成果物には、業務フロー、料金マスタ項目一覧、料金式のサンプル、入力データの項目定義、請求締め処理、訂正・再請求の手順、権限表、移行対象。
受入基準を含めます。
代表荷主を2〜3社選び、過去3か月分のデータで「保管料」「荷役料」「付帯費用」「請求総額」を再計算します。
計算結果が合わない場合は、製品選定へ進む前に、丸め、税区分、日割り、締め時点、数量の確定条件を見直します。
フェーズ2：選定で標準機能と追加開発を切り分けます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
選択肢は、クラウド型WMS・請求SaaS、物流パッケージへのカスタマイズ、料金計算エンジンを含むスクラッチ開発の三つに整理できます。
小規模な1拠点で料金パターンが少なく、CSV連携で足りる場合はクラウド型が始めやすいです。
複数荷主・複数拠点で標準的な物流業務を広くカバーしたい場合は、パッケージを中心に不足部分だけ追加開発する方法が現実的です。
重量・容積・温度帯・時間課金や複雑な最低保証が競争力に直結する場合は、料金計算部分を独立したサービスとして作る選択肢もあります。
候補製品のデモでは、一般的な入出庫だけでなく、月途中の契約変更、返品、緊急作業、最低請求額、複数の締め日、請求訂正まで実データに近いシナリオで確認します。
「その機能がありますか」と質問するだけではなく、標準設定で可能か、アドオンか、外部連携か、毎月の手作業かを記録します。
合わせて、APIやCSVの再送、エラー行の特定、計算結果の再現、バージョンアップ時の影響、データの保管場所、サポート時間も比較します。
フェーズ3：設計開発で料金エンジンと連携を定義します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
設計では、WMSから実績を受け取り、契約・料金マスタを適用し、計算結果、明細、エラー、承認履歴を返す流れを定義します。
料金式は「対象数量×単価」だけでなく、日割り、荷姿変換、重量帯、温度帯、最低保証、割増、端数処理、税計算をどの順で適用するかを決め。
サンプルケースを設計書へ残します。
料金マスタの変更履歴、適用開始日、登録者、承認者を記録すると、過去請求の再現性が高まります。連携方式は、リアルタイムAPI、定時バッチ、CSV取込から選びます。
APIが利用できない場合でも、ファイル名、文字コード、項目順、必須・任意、重複時の扱い、エラー時の再取込、処理結果の通知を仕様化します。
画面開発では、料金マスタ登録、計算実行、差分確認、承認、請求確定、訂正・再請求、明細照会を一連の操作として設計します。
荷主別の権限分離、MFA、通信・保存時の暗号化、操作ログ、バックアップと復旧訓練も、この段階で要件に含めます。
フェーズ4：テストで計算結果とピーク負荷を検証します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
テストは、画面が動くかだけでなく、料金の正しさ、連携の欠損、権限、監査ログ、性能、障害復旧を確認します。
料金テストでは、通常ケースに加え、月途中の入出庫、在庫ゼロ、最低保証、返品、割引、単価改定、複数税率、うるう年、締め日変更、同じデータの再取込を用意します。
代表荷主の過去請求と新システムの明細を行単位で突合し、差異の理由を説明できる状態を受入条件にします。性能テストでは、月末の締め処理、荷主からの一斉照会、
WMSからの大量取込をピークとして測定します。
平均値だけではなく、処理時間の最大値、エラー率、同時実行数、再実行時間を確認します。
移行テストでは、件数、金額、日付、文字コード、重複キー、削除済みデータを照合し、旧システムへ戻す条件と担当者を決めます。
倉庫現場で使うハンディやラベルプリンターがある場合は、通信断、端末交換、印刷失敗時の復旧も本番に近い環境で試します。
フェーズ5：稼働で並行運用とロールバックを準備します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
稼働方法は、一斉切り替え、拠点単位、荷主単位、請求機能だけの先行稼働を比較します。
初回導入では、影響範囲を抑えやすい荷主や拠点を選び、一定期間は旧Excelや旧システムとの並行運用を行う方法が安全です。
ただし、二重管理を長引かせると入力漏れが増えるため、並行期間、照合項目、終了条件を事前に決めます。
切り替え当日は、データ確定時刻、取込停止、請求確定、利用者告知、監視、判断者、旧環境へ戻す条件を時系列の手順書にします。
稼働判定では、重要な荷主の請求額、未請求件数、エラー件数、在庫残高、権限、操作ログ、バックアップの成否を確認します。
請求に影響する不具合がある場合は、手作業の補正で隠さず、原因、暫定対応、再計算、荷主への説明方法を記録します。
現場教育は操作説明だけでなく、料金マスタを変更できる人、計算結果を承認する人、訂正を行う人を分け、権限と責任を一致させることが大切です。
フェーズ6：定着で請求精度と収益管理を改善します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
稼働後は、請求金額の確定だけでなく、未請求、手動補正、エラー、赤字作業、荷主別粗利、保管効率、作業生産性を月次で確認します。
手動補正が多い料金を抽出すると、料金マスタの不足なのか、WMS実績の欠損なのか、契約そのものが曖昧なのかを特定できます。
新しい荷主や拠点を追加する際は、既存の料金式をコピーするだけでなく、データ連携、権限、請求書レイアウト、テストケースまで標準手順に沿って登録します。
2026年4月以降、一定規模以上の荷主・物流事業者には、物流効率化法に基づく特定事業者の指定、中長期計画。
定期報告などの規定が施行されています（出典：国土交通省「物流効率化法」理解促進ポータル、2026年）。
また、国土交通省は2026年7月7日に物流分野の倉庫向け情報セキュリティ確保に係る安全ガイドライン第2版を改訂しました
（出典：国土交通省「物流分野における情報セキュリティ確保に係る安全ガイドライン」、2026年）。
対象企業かどうかにかかわらず、作業実績や保管量を報告・監査できる形で保存し、テナント分離、最小権限、MFA、復旧訓練。
委託先アクセス管理を運用に組み込むことが重要です。
倉庫料金計算システムの費用相場とコスト内訳
費用は、システムの初期費用だけでなく、月額利用料、拠点・荷主追加、データ移行、ハンディ端末、
API連携、教育、稼働立会い、保守を含めて比較します。公開料金があるクラウド型と、
要件によって大きく変わる個別開発は同じ表で比べられないため、ここでは公開料金の実例と、
リサーチノートに基づく個別開発の推定レンジを分けて示します。
公開料金のあるクラウド型は初期費用と月額を分けて見ます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
クラークの公式料金では、基本機能が初期8万円・月額2万5,000円、請求機能が月額2万円、導入支援が初期30万円。
全機能を使うEnterprise版が初期8万円・月額8万円です。
複数拠点は1拠点ごとに月額1万5,000円が加算され、月間5万行を超える明細は別見積もりとされています（出典：クラーク公式料金、確認日2026年8月）。
税別の公開料金であり、個別連携や端末費用を含む総額ではない点に注意します。
日本倉庫協会が掲載するMPS LOGIの参考料金では、月額利用料が明細数に応じて6万6,000円から22万円、初期導入支援が55万円です。
荷主・拠点の追加、在庫データ移行、マスタ設定、業務運用テスト、操作教育、本稼働立会い。
ハンディ端末にも追加料金が設定されています（出典：一般社団法人日本倉庫協会「MPS LOGI」、確認日2026年8月）。
このように、標準クラウド導入は一例として初期10万〜80万円程度、月額2万5,000〜22万円程度が比較の起点になりますが、明細量、拠点数、荷主数。支援範囲、
連携方式で変動します。
個別開発は規模別の推定レンジで予算を置きます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
倉庫料金計算システム単体について、2025〜2026年の公的な市場平均は確認できません。
以下は、公開SaaS料金、一般的な業務システムの工数、WMS・会計・EDI連携の複雑さから作成した編集部推定であり、確定見積もりではありません。
小規模構成は300万〜800万円程度、期間3〜6か月が目安です。
1拠点、少数荷主、保管料と基本荷役料、CSV入出力、請求書出力を中心にし、既存WMSの実績を取り込む構成を想定します。
標準的な3PL向けは800万〜2,000万円程度、期間6〜12か月が目安です。
複数荷主・複数拠点、契約単価、割増、最低料金、月次締め、荷主向け照会、WMS・会計・EDI連携、権限・監査ログを含む構成です。
大規模・個別最適型は2,000万〜5,000万円超、期間12〜18か月程度となる場合があります。
複雑な従量課金、温度帯・重量・容積、ハンディやマテハン連携、複数会社、リアルタイム基幹連携、原価・収益分析まで含むケースです。
自動倉庫やロボット制御まで同時に開発する場合は、さらに増える可能性があります。
見積書では、要件定義、料金マスタ設計、画面・API開発、データ移行、テスト、教育、稼働立会い、保守を分けて確認します。
月額のクラウド利用料、バックアップ、データ転送、端末、サポート、追加拠点の単価も5年間のTCOへ含めます。
まず標準WMSと標準請求機能で開始し、例外の多い料金計算だけをアドオンにする段階導入は、初期費用と業務リスクのバランスを取りやすい方法です。
見積もりを取る際のポイントとチェックリスト
見積もりの精度は、発注前にどれだけ料金ルールとデータを具体化できるかで決まります。
機能名だけを並べたRFPでは、ベンダーが前提を補い、契約後に追加費用が発生しやすくなります。
候補会社には、同じサンプルデータと同じ受入条件を渡し、標準機能、設定、追加開発、
運用回避策を分けた提案を求めます。
料金式・データ・例外をRFPへ具体的に書きます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
RFPには、拠点数、荷主数、商品数、月間の入出庫行数、ピーク時の取込件数、締め日、請求書の件数、利用者数を記載します。
料金については、保管料の基準、荷役料の単位、日割り、丸め、税区分、最低保証、割引、割増、返品、再請求、単価改定の適用日を例示します。
たとえば「月末在庫が何ケースならいくらか」だけでなく、「月途中に入庫し。翌月に出庫した場合」「同じ実績を再取込した場合」「作業実績を訂正した場合」
の結果も提示します。
連携では、WMS、会計、販売管理、請求書発行、EDI、配送会社、ハンディ、ラベルプリンターの対象と方式を分けます。
過去データの移行期間、移行後も参照する履歴、マスタの名寄せ、文字コード、エラー訂正の担当も明記します。
成果物には、要件定義書、料金マスタ一覧、APIまたはCSV仕様、計算ロジックの説明、テスト結果、操作手順書、障害時のランブックを含めると。
納品後の属人化を抑えられます。
複数社を同じシナリオとTCOで比較します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
相見積もりでは、初期費用の安さだけで判断しません。
5年間のTCO、月額の増加条件、荷主・拠点・明細量の追加単価、保守とバージョンアップ、障害時の復旧目標、データの取り出し。
契約終了時の移行支援を同じ基準で比較します。
デモでは、入庫、在庫、出庫、保管料計算、作業料計算、承認、請求訂正、荷主照会を一つのシナリオで実行し、担当者が何回Excelへ転記するかを数えます。
ベンダーへは、「保管料と荷役料の計算は標準機能ですか」「料金表の変更履歴と承認者を残せますか」「過去の請求明細を同じ式で再現できますか」
「WMS実績の欠損や重複を検知できますか」「複数荷主のデータをどう分離しますか」「月間5万行を超えた場合の費用と性能はどうなりますか」
「障害時に誰がどの順序で復旧しますか」と質問します。
回答を口頭で終わらせず、提案書、仕様書、契約上の責任範囲へ反映させることが重要です。
請求ミス・属人化・セキュリティのリスクを先に潰します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最も大きなリスクは、料金計算が合わないことより、合わない理由を追跡できないことです。
実績の取込件数、未処理、重複、手動補正、料金マスタ変更、承認、請求確定をログに残し、月次締めのチェックリストを標準化します。
担当者だけが知っているExcelの補正式は、計算ロジックとしてシステム化するか、例外申請と承認の画面に置き換えます。
倉庫料金計算システムでは、荷主情報、在庫、商品、作業実績、単価など複数企業に関係するデータを扱います。
テナント分離、最小権限、MFA、暗号化、操作・料金マスタ変更ログ、バックアップ、復旧訓練、委託先のアクセス管理を要件へ含めます。
AIによる需要予測や作業最適化を追加する場合も、AIの提案をそのまま請求や現場指示へ反映せず、人が承認し、根拠データを追跡できる設計にします。
倉庫料金計算システム開発でよくある質問
ここでは、開発前に多く寄せられる質問へ、判断の前提を含めて回答します。自社倉庫、
3PL、メーカー・小売では必要な請求機能の深さが異なるため、回答をそのまま当てはめず、
自社の料金表と実績データへ置き換えて確認します。
倉庫料金計算システムの開発費用はいくらですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
クラウド型の標準導入は、公開料金の一例では初期10万〜80万円程度、月額2万5,000〜22万円程度が比較の起点になります。
個別開発は、1拠点の小規模構成で300万〜800万円程度、標準的な3PL向けで800万〜2,000万円程度。
大規模・個別最適型で2,000万〜5,000万円超という推定レンジです。
いずれも税区分、明細量、連携、移行、教育、保守を含むかで変わるため、料金表とサンプルデータを渡して再見積もりを取ります。
WMSを導入済みでも料金計算システムは必要ですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
WMSに標準の請求機能があり、荷主ごとの保管料・荷役料・付帯費用を十分に設定できるなら、別システムが必須とは限りません。
一方で、WMSに実績はあるものの、料金式が単純、請求訂正が手作業、複数拠点をまたぐ契約や荷主照会に弱い場合は。
請求機能の追加開発または料金計算エンジンとの連携を検討します。
まず過去請求を再現し、標準機能、設定、アドオン、外部システムのどこで不足しているかを切り分けます。
開発は何から始めればよいですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初に、荷主・拠点・契約ごとの料金表と、過去3か月分の在庫・入出庫・作業実績・請求明細を集めます。
次に、現在の計算式、手作業、例外、請求ミス、問い合わせ内容を業務フローへ書き出し、代表荷主2〜3社で新旧計算を突合します。
その結果をRFPへまとめ、同じシナリオで複数社の標準機能、追加開発、連携、TCOを比較すると、製品名から入るよりも自社に合う選択肢を絞りやすくなります。
クラウドとスクラッチ開発はどちらを選ぶべきですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
拠点や荷主が増える見込みがあり、料金パターンが標準的で、運用担当者を増やしにくい場合はクラウド型が候補です。
独自の料金式や既存基幹との深い連携が競争力に直結し、標準設定では請求根拠を表現できない場合は、パッケージへの追加開発やスクラッチが候補になります。
最初から全機能を個別開発するのではなく、標準機能で開始し、差別化に必要な料金計算だけを拡張する段階導入も有効です。
まとめ：請求根拠まで設計してから開発を始めます
倉庫料金計算システムは、料金表を自動計算するだけのツールではなく、在庫・入出庫・作業実績、
契約、請求、収益管理をつなぐ業務基盤です。成功の近道は、要件整理で料金単位と例外を棚卸しし、
代表荷主の過去実績で計算結果を突合してから、クラウド、パッケージ、個別開発を選ぶことです。
6フェーズの終了条件を合意します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
要件整理では料金式と元データを確定し、選定では標準機能と追加開発を分け、設計開発では計算式・連携・権限・ログを定義します。
テストでは通常ケースと例外ケースを行単位で突合し、稼働では並行運用とロールバックを準備し、定着では未請求・手動補正・荷主別粗利を改善指標にします。
各フェーズの成果物と受入条件を契約へ含めることで、担当者の経験だけに依存しない運用へ移行できます。
まず料金表と過去請求を一緒に確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初の一歩は、システム会社へ機能一覧を求めることではなく、現場・営業・経理を交えて、料金表、作業実績、請求明細、手作業の補正を同じ資料へ並べることです。
その資料をもとに、必要な料金単位、例外、連携、セキュリティ、将来の拠点追加を優先順位付けします。
公開料金は予算の起点、個別開発費は要件に基づく推定として扱い、最終的にはサンプルデータを使った提案と検証で判断してください。
▼全体ガイドの記事
・倉庫料金計算システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。