PostgreSQLを使うシステムの構成は、業務の独自性、店舗数、取引量によって変わります。既存のサービスを活用する形から大規模な個別開発まで、連携や運用の要件に応じて方式を選びます。
構成、進め方、費用、開発会社の選び方を順に見ると、発注までの全体の流れがつかめます。
▼関連記事一覧
・PostgreSQLのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・PostgreSQLのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・PostgreSQLのシステム開発の見積相場や費用/コスト/値段について
・PostgreSQLのシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
PostgreSQLのシステムの定義
PostgreSQLのシステムは、DB単体ではなく、業務アプリ、端末、外部サービス、運用基盤まで含めた全体を指します。データの保存先にPostgreSQLを採用し、アプリケーション上で業務ルールを実行する構成です。
データベースと業務アプリケーションの役割
PostgreSQLは、取引や商品などのデータを正しく保存し、条件検索や複数処理の一括確定を担います。
- アプリケーション：レジ・在庫・分析の画面、API、バッチを受け持つ
- 売上登録：取引ヘッダー、明細、支払、在庫減少、ポイント付与をまとめて確定する
- 通信断への備え：一部だけ登録されると売上や在庫がずれるため、トランザクションと再送制御を併用する
PostgreSQLを採用する主な理由
PostgreSQLは、標準SQL、トランザクション、ビュー、トリガーを備えています。さらに、JSON、全文検索、パーティショニング、レプリケーションも備えています。
- 実行環境：特定製品のライセンスに依存しにくく、クラウド・オンプレミス・コンテナを選びやすい
- 利用料以外の費用：無料でも設計、性能試験、監視、バックアップ、更新に費用がかかる
- 採用時の比較：DB料金だけでなく、開発から5年間の総保有コストで比べる
PostgreSQLのシステムの全体像と主な構成
店舗・小売向けの場合、店舗端末、本部アプリ、DB、連携処理、分析基盤に分けて考えると、要件を整理しやすくなります。層ごとの責任があいまいだと、障害時に止まっている箇所が分からず、復旧や再送に時間がかかります。
店舗端末とオフライン時の取引
レジやモバイル端末は、本部のデータベースへいつも接続できるとは限りません。
- 取引の一時保存：回線障害や機器交換のときは、未送信の取引を端末に保存し、復旧後に取引IDを付けて再送する
- 二重登録の防止：取引IDを一意にし、受信済みの取引は再処理せず結果だけを返す仕組み（冪等性）を実装
- 要件定義：オフライン許容時間、端末の保存件数、再送失敗時の店舗操作を決める
商品・取引・在庫を支えるデータ設計
基本テーブルには、商品、店舗、端末、取引、在庫などがあります。ほかに、明細、支払、発注、入出荷、会員、クーポンも含みます。
- コード体系：商品・店舗コードを場当たり的に作ると、ECや倉庫で同一商品が別物になる
- マスタ管理：責任部署、コード体系、変更履歴、適用開始日を決めておく
- 取引記録：返品や取消は元の取引を書き換えず、別の取引として残す
- 在庫管理：現在庫、入荷予定、引当済み、販売可能数を別々に持ち、二重引当に気づけるようにする
API・バッチ・分析基盤との連携
決済、会計、EC、倉庫、会員などと連携するときは、APIとバッチの役割を分けて設計します。
- 処理方式：リアルタイム性が必要な在庫照会はAPI、日次売上集計や大量データ転送はバッチとし、処理の性質に合わせる
- 連携記録：送信済みフラグ、再送回数、エラー、受付番号、処理順序を残す
- 分析処理：複雑な集計を取引DBに集中させるとレジに影響するため、参照用レプリカや分析基盤へデータを分ける
可用性・性能・監視を含む非機能要件
画面が動くだけでは、システムの評価として不十分です。そこで、同時接続数、1分あたりの取引件数、応答時間、障害時の復旧時間を数値で決めておきます。
RTOとRPOでは目標を置きます。たとえば、営業時間中のDB停止を避けること、障害から30分以内の代替運用、データ損失を5分以内に抑えることなどです。
復旧に備えるには、バックアップに加えて、定期的なリストア試験、監視通知、連絡網、手順書の更新も運用設計に含めます。
PostgreSQLのシステムの種類と方式の選び方
主な方式は、業務の標準化の度合いや運用体制に応じて、次の4つに分かれます。
- パッケージ・SaaS：標準的な業務を短期間で導入できる
- マネージドPostgreSQL：基盤運用の一部をサービス側へ委ねる
- オンプレミス：既存設備やデータ配置の制約に合わせる
- スクラッチ開発：独自業務や複雑な連携に対応する
方式の選択は、独自業務の多さや導入期限によって変わります。加えて、店舗数、社内の運用人材、将来の変更頻度も判断材料になります。
パッケージ・SaaSを中心に使う方式
業務が標準化されていて短期間で導入したい場合は、POSや販売管理のパッケージ・SaaSを中心に据え、必要なデータはPostgreSQLへ連携します。
- 利点：画面や基本機能の開発費を抑えやすく、法改正や標準機能の更新を受けやすい
- 注意点：独自の締め処理や複雑な在庫引当を組み合わせると、追加開発や運用上の回避策が増える
- 契約前の確認：API公開範囲、データの所有権、解約時の出力形式、店舗数・端末数による料金の変わり方を確かめる
マネージドPostgreSQLを利用する方式
バックアップやパッチ適用、可用性構成の一部をサービス側へ任せたい場合は、マネージドPostgreSQLが候補になります。
- 導入面：サーバー調達を短縮でき、負荷に応じたサイズ変更や複数ゾーン構成を選びやすい
- 運用設計：DB内部は自動で最適化されず、SQL、索引、接続数、VACUUM、ログ、バックアップ期間の設計は運用側が担う
- 課金確認：利用時間、ストレージ、I/O、バックアップ、監視、データ転送の料金の内訳を確認する
オンプレミスや自社運用の方式
既存設備やネットワーク、データ配置の管理が必要な場合や、特殊機器と低遅延で接続する必要がある場合は、オンプレミスが候補になります。
長期利用では月額の見通しを立てやすい場合もあります。一方で、サーバー更新、予備機、電源・回線は自社の責任になります。さらに、次の作業も自社で担います。
- 監視：自社の責任で継続して行う
- 障害対応：障害時の対応を自社が担う
- 人員確保：運用に必要な人を自社で用意する
店舗と本部の接続が不安定な場合は、本部DBだけでなく、店舗側での一時保存やエッジ処理も検討します。
スクラッチ開発を選ぶ基準
独自の販売ルール、複数ブランドの在庫、特殊な店舗運営、複雑な既存連携が競争力に直結する場合は、スクラッチや共同開発を検討します。
- 要件定義：自由度は高いが、要件の不足は費用や納期の増加につながる
- 業務の仕分け：標準機能で代替できない業務、将来も変わらない業務、差別化業務に分ける
- 方式の再検討：独自性が画面の見た目だけなら、標準サービスとの連携で5年TCOを抑えやすい場合がある
PostgreSQLのシステム開発の進め方
開発の成否は、画面を作る前に業務とデータの境界を定めることに左右されます。特にPOSでは、通信断、返品、締め処理、セール時の集中アクセス、店舗展開時の移行を先に確認します。
▶ 詳細はこちら：PostgreSQLのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
1. 現状調査と要件定義
まず、店舗数、レジ台数、営業時間、1時間あたりの取引数を確認します。そのうえで、商品点数、会員数、保存期間、外部連携先も確かめます。
- 業務要件：売上、返品、取消、値引、クーポンを洗い出す。税・免税、棚卸、発注、入荷、移動、締め処理も対象に含める
- 非機能要件：応答時間、同時利用者数、RTO・RPO、監査ログ期間、個人情報の閲覧権限を決める
- 現場への質問：通常操作のほか、回線断、返品、日付をまたぐ場合の対応を尋ねる
2. データ設計と方式設計
商品、店舗、取引、在庫、会員などのデータごとに、どこを正本とするかを決めます。
- 連携設計：業務DBと分析データを分け、API、再送、エラー処理、認証方法を定める
- 機能の依存関係：拡張機能、全文検索、JSON、パーティションについて、標準機能で足りる部分と拡張に頼る部分を整理
- 継続性：設計段階で、メジャーバージョン更新後も使えるか、新環境へバックアップを戻せるかを確認する
3. 開発・連携・性能試験
売上登録、返品、在庫更新、締め処理などを小さく実装し、実データに近いサンプルで検証します。
- 異常系試験：二重送信、決済タイムアウト、在庫競合、バッチ途中失敗、異常な日付・金額を試す
- 応答時間：平均値に加え、セール開始直後や閉店前の95パーセンタイルを確認する
- 性能指標：ロック待ち、接続プール、ディスク使用量も測定する
4. データ移行・パイロット導入・全店展開
既存システムから移行する場合は、項目対応表、データクレンジングの方針、移行対象期間を決めます。さらに、欠損・重複の扱いと照合方法も決めておきます。
- 移行範囲：過去売上を全件移すか、分析用に別で保管するかによって、費用と期間が変わる
- パイロット：全店展開の前に1〜3店舗で売上、返品、在庫、通信断からの復旧、日次締めを確認
- 段階展開：切り戻し条件、並行稼働期間、スタッフ教育、問い合わせ窓口を明文化する
PostgreSQLのシステム開発費用相場とコストの内訳
開発費用を左右するのは、DBのライセンス料よりも、業務アプリケーション、端末連携、移行、テスト、店舗展開、運用設計の範囲です。
ここに示す金額は、日本の店舗小売向けに、2026年時点の公開情報をもとに一般的なシステム費用とPOSの工程から推定した税別の費用です。ただし、実際の見積もりは、店舗数、取引量、連携数、可用性、既存データの品質によって、改めて計算し直すことになります。
▶ 詳細はこちら：PostgreSQLのシステム開発の見積相場や費用/コスト/値段について
規模別の初期開発費と期間の目安
小規模なPoCや1〜3店舗で、商品・売上・在庫の登録と照会、既存決済との連携を行う場合は、500万〜1,500万円程度、3〜6か月が目安です。
10〜50店舗で、POS、発注、会員、ECまたは会計との連携、クラウドでの高可用性構成を含む場合は、1,500万〜5,000万円程度、6〜12か月が目安です。
多店舗・多ブランドで本部基幹、EC、倉庫、BIを含むと、さらにオフライン会計、移行、並行稼働が加わります。そのぶん、5,000万〜2億円超、12〜24か月以上になることがあります。
見積もりに含めるべき工程
見積もりは、要件定義・業務設計、画面・API開発、DB論理設計、移行に分けて確認します。さらに、性能・セキュリティ・端末試験、教育、展開支援も、工程ごとに分けて見ます。
DB設計・移行・性能試験は200万〜2,000万円程度、店舗展開・端末試験・教育は100万〜3,000万円程度を仮に置いて見積もるケースがあります。
特に商用DBから移す場合は、SQLの互換性、文字コード、日付・金額の丸め、ストアド処理、連携バッチの改修が、費用を押し上げる要因になります。
運用保守とインフラのランニングコスト
運用保守は、初期開発費の年15〜25％を仮置きします。監視、障害対応、バックアップ確認、脆弱性対応、軽微な改修、更新も含めて考えます。
- 小規模基盤：開発・小規模環境では、月額1万〜5万円が推定の目安
- 本番基盤：マネージド環境では、月額5万〜30万円が推定の目安
- 多店舗構成：高可用性、レプリカ、監視、バックアップを含めて、月額30万〜150万円程度と推定
- 料金試算：利用時間、CPU・メモリ、ストレージ、I/O、保持、転送量で変わるため、公式計算ツールで月次の金額と繁忙期の金額を見積もる
5年TCOで比較する考え方
方式を比べるときは、初期費用に月額の60か月分を加えます。そこへ、店舗追加、教育、保守、更新、障害時の代替運用も合算します。
- 人員費：ライセンス料がかからなくても、専任担当者や夜間対応が必要なら総額は増える
- サービスの評価：更新、監視、標準機能の改修まで込みなら、社内工数を含めたTCOで有利になる場合がある
- 見積比較：初期・継続費用を同じ前提にそろえ、店舗数・取引量が2倍の場合の価格も確認
PostgreSQLのシステム開発会社/ベンダーの選び方
会社選びでは、PostgreSQLの知識に加えて、業務理解と障害時の責任範囲も確認します。「PostgreSQLを扱える」という説明からは、店舗の締め、決済端末、通信断、在庫引当の経験は分かりません。
候補ごとに、技術力、業務理解、移行力、運用力を同じ質問票で評価します。
小売・POS業務の経験の確認
類似業態での導入店舗数、レジ台数、ピーク時の取引数、返品・値引のルール、通信断時の運用を尋ねます。
- 実績の中身：社名や件数だけでなく、課題、設計、担当範囲、稼働後の改善を確認
- 業務理解：売上締め、棚卸、返品、在庫移動を図で説明でき、現場教育の計画があるかを見る
- 担当範囲：別製品の導入や運用支援の実績は、自社開発と分けて評価する
PostgreSQLの設計・移行・性能チューニングの評価
論理設計やインデックス設計、トランザクション境界、接続プールを担当する人を確認します。VACUUM、レプリケーション、バックアップ、復元試験を担当する人も、あわせて確かめます。
- 移行作業：互換性調査、クレンジング、リハーサル、切り戻し方法を見積もりで確認
- 性能評価：「高速化」という言葉だけでなく、データ量、同時実行数、応答目標、試験方法まで示せるかを見る
- 測定結果：改善前後の測定項目を提示できるかを評価する
運用体制・SLA・引き継ぎ範囲の確認
稼働後の監視を担う人、一次の切り分けを担う人、連絡手段と時間帯は、契約前に確認します。
- 契約条件：障害の重要度別の応答時間、復旧目標、バックアップ期間、脆弱性対応、更新費用を明記
- 引き継ぎ範囲：ソースやDBスキーマ、IaCなどの成果物を確認し、手順、テストデータ、移行スクリプトも含める
- 継続運用：担当が交代しても運用できるよう、納品物と教育を見積書に含める
相見積もりを比べるためのRFP作成
候補ごとに前提条件が違うと、金額だけを並べても比べられません。そこで、比較条件をそろえておきます。
- 共通条件：RFPには、店舗・端末数、年間取引数、保存期間、連携先を記載します。さらに、性能・可用性目標、移行・教育範囲、保守時間も書き込みます。
- 提案内容：方式の理由、対象外範囲、追加費用の条件、日程前提、利用者側の作業を明記してもらう
- 低価格案：安い見積もりでは、対象外作業や稼働後の追加費用を確認する
▶ 詳細はこちら：PostgreSQLのシステム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：PostgreSQLのシステム開発の発注/外注/依頼/委託方法について
PostgreSQLのシステム開発で失敗しやすいポイントと対策
DBの選定が適切でも、業務や運用の設計が不足していると失敗につながります。特に問題になるのは、機能を先に決めること、通信断や返品の対応を後回しにすること、移行データの品質を確かめないこと、運用担当を決めないことです。
機能の増やしすぎによる業務の複雑化
要望を一度に実装すると、画面やデータ構造が複雑になります。さらに、テストの範囲も広がります。
- 段階導入：売上、在庫、返品、締め処理をMVP（Minimum Viable Product）で先行し、利用状況を見て分析・自動化を追加
- 機能の評価：売上増加、作業時間・ミス削減、法令対応のどれに効くかを整理する
- 導入時期：効果を測れない機能は後ろへ置く
データ移行後の売上・在庫の不一致
移行元に重複した商品、古い店舗コード、単位の違う数量、税率の異なる金額があると、移行後の数字が合わなくなります。
- 突合：移行前の件数、金額、日付範囲、商品数、店舗別合計を保存し、移行後に同じ集計で照合
- 差異対応：原因を分類し、クレンジングルールや例外一覧を残す
- 切替準備：複数回の移行リハーサルで、最終切替に必要な時間を実測する
安全性と運用の初期設計
権限や監視を稼働後に足すと、設計の変更が大きくなります。そのため、初期設計の段階で含めておきます。
- ロール設定：アプリ用と管理者用を分け、最小権限を設定する
- 安全対策：暗号化、TLS、パスワード認証、監査ログ、秘密情報の管理、バックアップの暗号化を設定
- 閲覧・更新権限：店舗スタッフ、店長、本部担当、分析担当、保守担当で範囲を分け、個人情報を含む会員・購買履歴は必要な人だけが扱う
- 運用訓練：障害、情報漏えい、誤操作、バックアップ復旧を事前に訓練する
2026年のPostgreSQL動向とセキュリティの考え方
2026年の採用では、新機能の多さよりも、対応範囲と運用の成熟度を確かめることが重要です。DBの版、拡張機能、ドライバー、監視製品、バックアップ手順を検証環境で試してから、本番へ段階的に反映します。
PostgreSQL 18とメジャーバージョン管理
PostgreSQL 18は2025年9月25日に公開され、非同期I/O、インデックス利用の改善、メジャー更新の負担軽減などが加わりました。
- 追加機能：OAuth 2.0認証、TLS 1.3設定、監視情報の強化
- 性能の公表値：非同期I/Oは条件により読み取り性能が最大3倍との発表がある
- 効果の変動要因：データ量、クエリ、ストレージ、同時実行数で実際の効果が変わる
- 採用前の検証：公表値を自社の性能として見積もらず、実データに近い負荷試験で確認する
最大3倍との発表はPostgreSQL Global Development Groupによるものです（出典: PostgreSQL Global Development Group、2025年）。
サポート期間とアップグレード計画
PostgreSQLのメジャーバージョンは、原則として年1回公開されます。各版は初回公開から5年間サポートされます（出典: PostgreSQL Global Development Group「Versioning Policy」、2026年確認）。
- 本番計画：サポート終了日、拡張機能の対応状況、移行方法、停止可能時間を一覧にする
- 更新リハーサル：ダンプ・リストアや専用ツールが必要な場合もあるため、少なくとも年1回実施
- 費用管理：古い版の延長サポートや脆弱性対応の費用もTCOに含める
購買履歴・決済情報・AI活用の安全性
会員情報や購買履歴は、保存してよいかだけでなく、利用目的、権限、保存期間、委託先、削除方法まで定めておく必要があります。
- 再識別防止：特定の商品や少人数の組み合わせを一般化し、個人が再び特定されないようにする
- 分析データ：元データと分け、加工の状態、鍵の管理者、利用目的を記録する
- 決済情報：カード番号などの保存を最小限にし、決済事業者のトークン化や非保持方式を優先
- AI利用：履歴を外部へそのまま渡さず、匿名化・権限管理・人の確認を前提に、在庫異常検知や需要予測の補助から始めると安全性を確保しやすい
この考え方は、個人情報保護委員会の指針に示されています（出典: 個人情報保護委員会、2025年確認）。
PCI DSS v4.0.1は、対象事業者に対し、適切な自己評価質問票を選び、適格性と提出先の要件を確認するよう案内しています。
この案内の出典はPCI Security Standards Council（2024年）です。
PostgreSQLのシステムに関するよくある質問
導入を検討する際によく寄せられる質問に答えます。PostgreSQLの導入は、技術だけでなく、店舗運用、データ移行、費用、保守をあわせて考えると判断しやすくなります。
PostgreSQLは無料なのでシステム開発費も安くなりますか？
オープンソースなので、商用DBのライセンス料を抑えられる可能性はあります。ただし、開発費が自動的に安くなるわけではありません。
要件定義、アプリ開発、移行には費用がかかります。性能試験、監視、バックアップ、保守の費用も発生します。そのため、ライセンス料だけでなく、5年TCOと障害時の売上への影響まで含めて比べます。
既存のデータベースからPostgreSQLへ移行できますか？
移行はできますが、テーブルをコピーするだけで終わるとは限りません。移行元と移行先では、SQLやストアド処理、日付・金額の型、文字コードが異なります。バッチや帳票、性能特性も異なるため、互換性の調査とリハーサルが必要です。
売上や在庫は移行の前後で集計し、件数と金額を突合します。そのうえで、並行稼働の期間と切り戻しの条件を決めます。
クラウドとオンプレミスはどちらが適していますか？
運用担当を確保しにくく、短期間で基盤を用意したい場合は、マネージドPostgreSQLを含むクラウドが候補になります。一方で、既存設備や閉域網、特殊機器、データ配置の制約が強い場合は、オンプレミスも候補です。
どちらを選ぶ場合も、可用性、バックアップ、監視、障害対応、将来の移行を比べます。月額だけで判断しないことが大切です。
開発会社やベンダーには何を確認すればよいですか？
確認したいのは、設計・移行・性能試験の担当者と、小売やPOSの実績です。さらに、次の項目も尋ねます。
- 障害時の対応：通信断、返品、決済、在庫競合への対応
- 保守体制：24時間保守の範囲
- 復旧：復旧試験を行うかどうか
- 納品と費用：納品物と追加費用の条件
提案を依頼するときは、店舗数、ピーク時の取引数、移行対象、目標応答時間を共通の条件として各候補に示し、回答を比べます。そのうえで、技術力と業務理解は別の軸で評価します。
まとめ
PostgreSQLは、ライセンス料を抑えながら、売上、在庫、会員、受発注、分析のデータを柔軟に扱える選択肢です。
成功させるには、DBを採用するだけでなく、データの正本、端末連携、通信断の再送、返品・取消の整合性を一体で設計する必要があります。さらに、ピーク性能、復旧、権限管理も同じ設計の中で考えます。
導入前の確認事項
自社の業務が標準機能で足りるか、独自開発が必要かを整理します。そのうえで、店舗数・取引量、通信断の許容時間を、数字で書き出します。あわせて、次の項目も書き出します。
- RTO・RPO：障害からの復旧時間とデータの目標
- 移行対象：移すデータの範囲
- 個人情報・決済情報：扱う範囲と取り扱いの決まり
- 保守時間：保守対応を受けられる時間帯
方式は、初期費用だけでなく、基盤の月額、保守、店舗展開、更新、障害対応まで含めた5年TCOで比べます。
小規模な検証と段階的な展開
全店展開の前に、1〜3店舗で売上、返品、在庫、締め処理、オフライン復旧を確かめます。
- 実測で見直す：性能と費用を確かめ、PostgreSQL 18などは拡張機能や周辺ツールとの互換性を見て採用
- パートナーと検証：要件と運用を同じ資料にまとめ、技術と小売業務を理解する開発会社と確認
- 継続利用：この進め方を続けて、システムを長く安全に使える状態に保つ
▼関連記事一覧
・PostgreSQLのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・PostgreSQLのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・PostgreSQLのシステム開発の見積相場や費用/コスト/値段について
・PostgreSQLのシステム開発の発注/外注/依頼/委託方法について
▼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を創業。