リテールメディアシステムは、データ連携、広告配信、購買測定を組み合わせ、小売企業の広告業務と顧客接点をつなぐ基盤です。広告の申込から請求、実績報告までを一つの業務として支えます。発注前に確かめたいのは、導入方式、費用、セキュリティなどです。
▼関連記事一覧
・リテールメディアシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・リテールメディアシステム開発でおすすめの開発会社/ベンダー6選と選び方
・リテールメディアシステム開発の見積相場や費用/コスト/値段について
・リテールメディアシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
リテールメディアシステムの全体像
リテールメディアシステムには、広告を出す画面のほかに、データ収集、利用目的と同意の管理、広告商品の作成、配信結果と購買結果の測定を支える業務基盤も含まれます。
広告接触から購買までを測る仕組み
一般的な広告では、表示後に実店舗や別のECで購買されたかを把握しにくい場合があります。一方で、リテールメディアでは、許諾範囲のデータで表示、クリック、閲覧、クーポン利用、来店、購買をつなぎます。この一連の測定を、クローズドループ測定と呼びます。
- 広告主：売上やROASを確認できます。
- 小売企業：広告枠の価値と、自社商品の売上への影響をつかめます。
購買データは、そのままでは広告目的で使えるとは限りません。そのため、会員規約、プライバシーポリシー、同意画面、オプトアウトを確認し、利用可能なデータを分けておきます。測定精度と本人が納得できるデータ利用を両立させることが、システム設計の出発点です。
広告業務を回す業務システム
案件数が増えると、広告業務を手作業で回す運用は立ち行かなくなります。
- 広告業務：広告枠・料金表の登録から、広告主や代理店の申込、入稿、審査、掲載期間の設定、配信・停止、請求、実績報告までを扱います。
- 業務フロー：広告主の申込画面と社内の審査・承認画面から、配信設定、請求データ、レポート生成までを一つにつなぎます。
- 利用者：小売本部、営業、マーケティング、EC運営、店舗運営、法務、情報システム、経理などが関係します。
- 権限：データ閲覧、広告承認、配信停止の担当者を定義し、誤配信や情報持ち出しを防ぎやすくします。
リテールメディアシステムの定義と範囲
リテールメディアシステムは、小売企業が持つファーストパーティデータで広告を配信し、購買までの成果を測るデータ基盤と業務アプリケーションです。
広告媒体の利用契約だけで済む場合もあります。一方で、自社の顧客接点や基幹システムと深く結び付ける場合は、システム開発として要件定義が必要になります。
活用するデータの範囲
リテールメディアで使うデータは、顧客接点と業務データにまたがります。接点ごとのデータと業務データを、種類ごとに整理します。
- EC：検索、閲覧、カート投入、注文、返品、レビュー
- アプリ：ログイン、プッシュ通知・位置情報の利用許諾、クーポン取得・利用
- 店舗：POS、ID-POS、会員証、来店、サイネージ接触
- 業務データ：商品・店舗マスタ、在庫、価格、キャンペーン期間
部署ごとに会員IDや商品コードが異なると、広告接触と購買を正しく結び付けられません。そのため、データ契約を作り、項目定義、更新頻度、ID変換を決めておきます。欠損時の扱いと保管期限も、同じ契約に書いておきます。
データを一つの大きな箱に集めるより、利用目的、利用者、粒度を明確にするほうが大切です。
接点ごとの広告商品の設計
代表的な広告商品は、接点ごとに形式が分かれます。
- EC：検索結果のスポンサード商品、商品詳細やトップ画面のバナー
- アプリ：アプリ内動画、メールやプッシュ通知
- 店舗・外部：店頭サイネージ、外部メディア配信
すべてを一度に実装せず、まずは購買意向が高く測定しやすいEC内広告から始めます。そのうえで、アプリ、外部配信、店舗へ順に広げるのが現実的です。
商品ごとに、掲載面、対象セグメント、最低出稿額を決めます。課金単位や入稿規格も定めます。審査基準、在庫数、報告項目も決めておきます。
ただし、広告枠を増やしすぎると、探しやすさや信頼性が下がる可能性があります。そのため、広告売上に加えて検索結果の利用率、離脱率、再訪率も確認し、顧客体験を損なわない在庫量にします。
リテールメディアシステムの種類と構成
導入方式は、既存のマネージド基盤、クラウドサービスの組み合わせ、独自開発に大別できます。また、広告配信は既存基盤を使い、会員・商品・購買データや社内業務は自社開発とする方式も選ばれます。
既存基盤やSaaSを使う方式
既存の広告配信基盤やSaaSなら、配信、入稿、レポートなどを短期間で導入できます。配信機能をゼロから作らずに済むため、初期検証に向いています。
導入前には、料金や契約条件に加えて、連携テストで運用上の挙動も確かめます。
- 契約条件：利用料金、広告売上に対する手数料、データ保管場所、API制限、機能追加、契約終了時のデータ返却
- 連携テスト：商品・価格・在庫の更新遅延で誤広告が出ないか、同意撤回後に配信対象から外れるか、障害時に停止できるか
導入の速さと、将来もデータの主権を保てるかどうかを、同じ基準で評価します。
クラウドを組み合わせる方式
データウェアハウス、CDP、API管理を、クラウドのモジュールとして組み合わせます。さらに、広告サーバー、BI、同意管理を加えます。データ量や広告主数に応じて拡張しやすく、日次集計とリアルタイム配信を分けられます。
イベント連携、暗号化、監視を標準化しやすい構成です。バックアップや環境分離も標準化の対象になります。そのため、複数チャネルを段階的に増やす企業に適しています。
一貫した運用には、ID、商品コード、広告キャンペーン、接触・購買イベントの共通定義が欠かせません。あわせて、障害や仕様変更を受け止める部分、APIの版管理、データ品質の監視も設計します。
スクラッチ開発とハイブリッド方式
業務要件への適合性に応じて、スクラッチ開発かハイブリッド方式を検討します。
- 独自開発：独自商品、店舗別ルール、複数ブランド権限、基幹連携
- ハイブリッド：配信は既存基盤、ID統合や社内業務は自社開発
独自開発は業務に合わせやすい一方で、長期にわたって運用する責任が生じます。その対象は、審査、請求、障害対応、仕様変更、広告主サポートです。そのため、配信機能に既存基盤を使うほうが、全機能を独自開発するよりリスクを抑えられます。
将来の移行に備えて、データを標準形式で出力できるAPIと、契約終了時の返却条件を初期契約に含めておきます。
リテールメディアシステム開発の進め方
開発は広告枠を作ることから始めず、事業目的、データと業務の現状、測定可能なMVPの順に整理します。事業部、EC、店舗の担当者が、同じ要件表を初期から見ることで、手戻りを減らせます。営業や法務、情報システム、経理の担当者も、同じ要件表を早い段階から確認します。
▶ 詳細はこちら：リテールメディアシステム開発の進め方/やり方/流れや方法/手法/工程/手順
事業設計と要件定義
広告収益、メーカー販促、自社商品の売上のうち、どれを主目的にするかを決めます。目的によって、広告面、データ、KPI、営業方法も変わります。
- 事業要件：広告主、対象顧客、利用データ、配信面、課金単位、レポート
- 運用要件：審査責任者、障害時の停止権限
- 棚卸し対象：EC、会員、アプリ、POS、商品、在庫、店舗、クーポン、CRM
対象データを洗い出すときは、保有部署と更新頻度、ID、利用目的を記録します。保存期間や外部提供の有無も残します。
会員IDが複数ある場合は、統合できるかどうかと、統合しない場合の測定方法を明記します。曖昧なままにすると、開発後に購買測定ができず、手戻りにつながります。
1チャネル・1カテゴリのMVP開発
MVPは、ECまたはアプリの1チャネル、1カテゴリ、1〜2社程度の広告主に絞ると検証しやすいです。そのうえで、広告接触から購買までデータが一貫して流れることを確かめます。
- 広告運用：広告枠登録、申込、入稿、審査、配信、停止
- 効果測定：接触ログ、購買連携、基本レポート
MVPの検証期間は、機能の完成だけでなく業務の定着まで確保します。具体的には、広告営業が申込を登録できるか、担当者が審査を処理できるか、経理が請求額を確認できるか、EC運営が顧客体験を評価できるかを、実案件で試します。
広告主の満足度と並べて、店舗や社内担当者の作業時間も記録すると、全社展開を判断する材料になります。
効果確認とチャネルの拡張
MVPの効果を確認したうえで、評価項目と拡張先を決めます。
- 評価項目：セグメント精度、表示速度、在庫、購買計測、売上、顧客体験、運用負荷
- 拡張先：アプリ、メール、外部配信、店舗サイネージ
チャネルが増えると、同意管理、配信頻度、クリエイティブ審査、在庫管理、店舗ルールが複雑になります。そのため、拡張のたびに業務フローと権限を見直します。
実際に、2026年7月公開の導入事例でも、EC内のオンサイト広告から始め、API連携で段階的に機能を広げる考え方が示されています（出典: リテールメディアプラットフォーム導入発表、2026年7月）。
市場拡大を理由に多機能化を急がず、購買に近い接点で成果を確認してから広げると、投資と運用リスクを抑えられます。
リテールメディアシステムの費用相場と開発期間
公開見積は少なく、広告出稿費や運用手数料は、システム開発費と分けて考えます。下に示すのは、EC・CRM・データ基盤・ID-POS連携を含む、2025〜2026年時点の企画用の推定レンジです。
店舗数、データ量、既存API、リアルタイム性、広告審査、セキュリティ要件によって変動します。そのため、予算の初期仮説として使ってください。
▶ 詳細はこちら：リテールメディアシステム開発の見積相場や費用/コスト/値段について
導入パターン別の費用目安
導入方式と連携範囲によって、初期費用の目安は異なります。
- 既存基盤接続：広告枠、商品・会員データ、権限、基本レポートをつなぐ構成。初期300万〜1,500万円程度
- MVP：自社EC・アプリに機能追加し、1〜2種類のデータソースで購買測定。1,500万〜4,000万円程度
- 複数チャネル基盤：クラウド構成で5,000万〜1億5,000万円程度
- 大規模統合：基幹・POS・CRMを含むスクラッチで1億5,000万〜5億円超の場合
広告費や営業手数料、制作費は、これらの金額に含まれない場合があります。さらに、データ利用料、店舗端末、設置工事、通信費、クラウド従量課金も、金額に含まれないことがあります。
初年度予算は、要件定義・事業設計に100万〜500万円、運用保守に月額50万〜300万円程度を別に見込んでおくと考えやすくなります。
費用の目安は、いずれも公開価格ではなく、類似の業務システムやデータ基盤から整理した推定値です。
市場規模と投資回収の切り分け
国内のリテールメディア広告市場は、2025年に6,066億円、2029年に1兆3,174億円へ拡大すると予測されています（出典: 国内リテールメディア広告市場調査、2026年1月公表）。
この数字は、広告主が支払う広告市場の予測で、システム開発市場や小売企業の利益を直接示すものではありません。そのため、市場成長率だけで高額な開発を決めるのは危険です。
- 収益効果：広告売上、粗利、自社商品の増分売上、メーカーとの取引拡大
- 投資・費用：初期投資、月額保守、クラウド従量費、営業・審査・レポートの人件費
業務削減効果も分けて試算します。そのうえで、投資と費用を合算し、何年で回収できるかを計算します。
広告売上が伸びても、手作業や値引きがかさむと、利益が残らない場合があります。このため、売上だけでなく、貢献利益と運用負荷も確認します。
MVPの開発期間の目安（4〜8か月）
既存基盤との接続か、自社EC・アプリへのMVP開発かで、公開までの期間は異なります。
- 既存基盤接続：基本広告機能を含めて1〜4か月
- EC・アプリのMVP：4〜8か月程度
- 複数チャネルのクラウド基盤：9〜18か月
- 大規模スクラッチ：12〜24か月以上かかる場合
要件定義、データ整備、法務確認、広告主の受入テストが長引くと、実装期間だけでは収まりません。
短納期を目指す場合は、初回リリースの範囲を固定し、追加機能をバックログで管理します。既存APIがなければ、API開発を先行させることもあります。
納期を短くすることより、購買計測と配信停止が正しく動く状態で公開することを優先してください。
セキュリティ・個人情報保護の確認事項
閲覧や購買の履歴、位置情報、興味・関心、会員IDを扱う可能性があります。そのため、個人情報に当たるかどうかだけでなく、個人関連情報、仮名加工情報、匿名加工情報のどれに当たるかを区分し、利用目的、提供先、同意の要否も整理します。
法務と情報システムの担当者を開発の終盤に加えると、配信設計やデータモデルの大幅な修正につながります。このため、初期の段階から関係者を交えて確認します。
同意・利用目的・データ提供の記録
同意やデータ利用では、記録と処理を整えておきます。
- 同意記録：日時、画面、利用目的、対象データ項目
- 選択の反映：撤回や広告・メール・通知の拒否を除外処理と履歴に連動
- 説明への備え：本人に利用内容と提供先を示せる状態
個人情報保護委員会のガイドラインは、Cookie等の端末識別子による閲覧履歴、購買履歴、位置情報、興味・関心を、個人関連情報の例に挙げています。出典は、個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（2026年確認）です。
安全管理措置は、漏えい、滅失、毀損を防ぐため、事業規模やデータの性質・量に応じて、必要かつ適切に講じるとされています。
認証・権限・ログ・バックアップの設計
管理画面は、誰がどの操作をできるかを絞っておかないと、誤った操作や情報の持ち出しにつながります。そのため、技術面の要件を、認証、データの保護、監視と復旧に分けて決めておきます。
広告の登録や承認、配信条件の変更で担当者を追跡できると、誤配信の原因究明と再発防止が容易になります。
ECサイトの構築・運用では、管理画面へのアクセス制限や不正ログイン対策、ログの保護などが、重要な対策として整理されています。出典は、IPA「ECサイト構築・運用セキュリティガイドライン」（2023年）です。
- アクセス管理：多要素認証、最小権限、広告主と社内データの分離
- データ保護：通信・保存データの暗号化、秘密情報の管理
- 監視と復旧：脆弱性診断、監査ログ、バックアップ、異常検知
リテールメディアでは、既存ECに加えて、配信API、広告主ポータル、レポート出力、委託先の運用端末も確認の対象です。
誤配信・漏えい時の初動と対応
事故が起きた際に備え、手順をすぐ実行できる状態にしておきます。
- 広告配信の停止と、対象データの隔離
- 広告主や社内責任者への連絡と、ログの保全
- 本人や関係機関への対応の判断
停止ボタンが管理画面の奥にあると、初動が遅れます。このため、緊急停止の権限と操作経路を決め、定期的に訓練しておきます。
委託先については、保管場所と再委託、アクセス担当を確認します。加えて、脆弱性対応や監査、事故通知、契約終了時の削除・返却も見ておきます。
配信実績があっても、自社のデータ利用目的や店舗運用に合うとは限りません。したがって、技術、契約、ガバナンスを併せて評価します。
導入後に見るKPIと運用体制
広告後の購買や顧客体験を見るには、クリック率よりも広い指標が必要です。そのため、広告主向けの指標と小売企業の経営指標を分けて、接触から購買までを評価します。
広告主向けのKPI設計
広告主向けには、接触から購買までのKPIを設定し、主要指標は一つか二つに絞ります。
- 接触：表示回数、到達数、クリック率
- 購買行動：商品詳細閲覧、カート投入、購入数・金額
- 施策評価：クーポン利用、ROAS
たとえば、認知施策なら到達や動画視聴、販売促進なら購買率や増分売上が候補になります。ただし、すべてを一つのスコアにまとめると、改善箇所が分かりにくくなります。
購買効果は、広告接触者と非接触者の比較、接触前後の変化、クーポン利用、カテゴリ別売上などを組み合わせて測ります。
接触者がもともと購入意欲の高い人だった可能性もあります。そのため、単純な売上を広告の成果と断定せず、比較方法と集計期間を資料やレポート仕様に記しておきます。
小売企業側のKPI
小売企業は、収益や在庫、継続率、運用、配信品質を示すKPIを確認します。
- 収益・在庫：広告売上・粗利、販売可能在庫、出稿継続率
- 運用：レポート作成・審査時間、配信エラー率、問い合わせ件数
検索利用率や商品ページからの離脱、再訪、購買単価、クーポン利用を見て、顧客体験への影響も追います。ただし、収益が増えても、検索や店舗業務の負担が増えれば、長期的な成果とは言えません。
経営層向けの月次レポートには、広告収益、増分売上、投資回収、主要リスクをまとめます。一方で、運用担当者は、配信エラー、在庫、審査滞留、同意除外、データ欠損を日次で確認します。利用者に応じて情報の粒度を変えると、ダッシュボードの情報過多を防げます。
営業・審査・データ・開発の役割分担
運用では、領域ごとに役割と責任を分けておきます。
- 広告営業・審査：商品と料金、広告表現と法令
- データ・現場：連携と測定、顧客体験と店舗運用
- 開発・保守：システム品質と障害対応
少人数の場合でも、役割と承認者を兼務表にまとめておくと、担当者が増えたときに引き継ぎやすくなります。
運用後は、週次で配信エラーと審査滞留、月次で売上とKPI、四半期でデータ利用目的と権限を見直します。
広告主の要望は、そのまま機能追加にせず、顧客体験、法務、セキュリティ、既存システムへの影響を評価してから優先順位を決めます。
リテールメディアシステムの開発会社・ベンダーの選び方
開発会社を選ぶ際は、広告を売る力だけでなく、既存システムやデータをつなぎ、広告業務を定着させ、購買効果を説明できるかを見ます。また、広告会社、基盤提供者、SIパートナー、分析会社では、得意とする領域が異なります。
開発会社の担当範囲
提案書では、対応範囲、対象外、前提条件を、領域ごとに分けて示してもらいます。
- 事業・要件：事業設計、要件定義
- データ・連携：データ棚卸し、API連携、ID統合
- 広告業務：配信、審査、請求、レポート
- 導入後：セキュリティ、運用教育
導入支援だけなのか、開発後の保守や運用改善まで続けるのかも確認します。特に、売上責任と品質責任が曖昧な提案では、追加費用が生じやすくなります。
実績については、EC、アプリ、POS、会員、店舗のうち何を連携したか、購買まで測ったか、広告主向けの画面があるかを質問します。
可能であれば、匿名化した画面、連携図、障害時の手順、導入後の保守体制も確認します。
RFPで提示する条件
複数社へ、同じ資料で事業規模、技術、導入条件を提示します。
- 事業規模：商品、チャネル、店舗数、会員数、月間イベント数
- 技術要件：既存API、リアルタイム性、KPI、セキュリティ
- 導入条件：希望時期、保守範囲
- 開発工程：要件定義、設計、開発、連携、テスト、移行、教育
- 継続・外部費用：保守、クラウド、外部サービス、予備費
機能一覧に加えて、EC検索から広告接触、購買、レポートまでの業務シナリオを示すと、提案を比べやすくなります。
固定価格の範囲や追加変更の単価、納期遅延の条件、受入基準を確認します。加えて、データ返却、再委託、事故責任も確かめます。少なくとも3社程度に同じ条件で依頼し、金額、前提、リスクを比べます。
選定面談で聞く実装後の運用
面談では、実装後の対応力と体制を確認します。
- 運用対応：欠損時の再集計、同意撤回、誤配信停止、審査、請求、API障害
- 開発体制：連絡、意思決定、課題管理、テスト責任、問い合わせ窓口
- 技術評価：共通ID、品質、権限、監査、可用性、拡張性
事業面では、広告商品の拡大の順番、販売方法、効果レポート、社内負荷も確認します。
機能が多いかどうかより、事業、システム、運用を一体で設計できるかで判断してください。
▶ 詳細はこちら：リテールメディアシステム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：リテールメディアシステム開発の発注/外注/依頼/委託方法について
よくある質問
導入前に質問されやすい内容を取り上げます。答えは規模やデータの状態によって変わるため、一般的な判断基準として捉えるのがよいです。
リテールメディアシステムは広告配信サービスだけで導入できますか？
ECやアプリの広告枠への配信だけであれば、既存サービスを利用できる場合があります。一方で、POSや会員データで購買効果を測り、審査・請求・レポートも自動化する場合は、API連携や業務システム開発が必要になります。
まず必要な業務範囲を分けて判断してください。
小規模な小売企業でもリテールメディアを始められますか？
始められます。店舗全体を対象にするより、会員数や購買データが比較的整理されたECまたはアプリの1面に絞り、1カテゴリの広告商品から試すほうが負担を抑えられます。
まずは、広告枠、申込、配信、購買測定、レポートを最小構成で動かし、成果と運用負荷を見てからチャネルを増やします。
費用を抑えるにはどの機能から開発すべきですか？
購買に近く効果測定しやすいEC内のスポンサード商品やバナーから始める方法が現実的です。
まずは、広告枠登録、入稿・審査、配信を優先し、接触ログや購買連携、基本レポート、停止機能もあわせて入れます。一方で、AI最適化や大量の店頭端末は、後から追加します。
広告費、データ利用料、クラウド費、保守費は、開発費と分けて見積もることが大切です。
購買データを広告に使うときに注意することは何ですか？
まず、利用目的と本人への説明、同意を整理します。そのうえで、提供先や委託先、保存期間、削除・訂正の手順も確認します。会員IDや購買履歴は、そのまま外部へ渡さず、必要な範囲に限ります。
仮名化や集計化、権限の分離も検討します。さらに、法務、情報システム、事業責任者が、対象データと広告目的の適合性を確認してから実装してください。
まとめ
リテールメディアシステムは、EC・アプリ・店舗・会員・ID-POSのデータと業務をつなぎ、広告接触から購買までを安全に測る基盤です。
市場の成長を機会に変えるには、広告枠を増やす前に、正しいID、適切な同意、信頼できるレポート、続けられる運用を整える必要があります。
導入前の確認事項
まず、広告事業の目的と対象チャネル、利用データ、同意と権限を確かめます。続けて、広告商品、KPI、MVP、予算、期間、保守体制を、一枚の計画にまとめます。
方式を比較するときは、初期費用だけでなく、データ移行性、運用負荷、手数料、障害対応、契約終了後の返却まで評価します。
小さく始めて育てる購買測定の仕組み
最初は、1チャネル、1カテゴリ、少数の広告主で、広告枠登録から購買レポートまでを通します。
- 評価：顧客体験、広告収益、増分売上、社内負荷、セキュリティ
- 拡張：結果をもとにアプリや店舗へ段階的に広げる
- 長期運用：広告事業とデータ活用の基盤にし、顧客接点を価値へつなぐ
この仕組みを長期基盤として設計すると、自社の顧客接点を継続的な価値へ変えられます。
▼関連記事一覧
・リテールメディアシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・リテールメディアシステム開発でおすすめの開発会社/ベンダー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を創業。