Azure Synapse Analyticsのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Azure Synapse Analyticsのシステム開発は、データを集めて終わりにせず、業務KPIを定義し、品質・権限・費用・運用までを要件に含めて6フェーズで進めることが成功の近道です。

SQL ServerやERP、CRM、Excel、IoTログなどに分散したデータを、分析や意思決定に使える状態へ整えたい企業は少なくありません。一方で、専用SQLプールとサーバーレスSQLの使い分け、Sparkの要否、Azure利用料、データ品質、Microsoft Fabricとの将来関係まで考えると、どこから着手すべきか迷いやすくなります。この記事では、Azure Synapse Analyticsのシステム開発について、全体像、要件整理から定着までの進め方、費用相場、見積もりの確認ポイント、よくある質問を実務の判断基準に落とし込んで解説します。

▼全体ガイドの記事
・Azure Synapse Analyticsのシステム開発の完全ガイド

Azure Synapse Analyticsのシステム開発の全体像

Azure Synapse Analyticsは、エンタープライズDWH向けのSQL、ビッグデータ処理向けのApache Spark、データ統合用のPipelines、Synapse Studioなどをまとめて扱うAzureの分析サービスです（出典: Microsoft Learn「Azure Synapse Analyticsとは」、2026年8月確認）。したがって、開発対象はワークスペースだけではなく、データの入口、蓄積場所、変換ルール、提供先、セキュリティ、監視までを含むデータ活用基盤になります。

Azure Synapse Analyticsは、受発注や在庫を登録する業務アプリケーションそのものではありません。複数の業務システムからデータを取り込み、ADLS Gen2などに蓄積し、名寄せやクレンジングを行い、分析しやすいデータモデルへ整えて、Power BIやAPIなどへ提供する役割を担います。たとえば営業部門と経理部門で売上の定義が異なる場合、単にデータをコピーするだけでは数字の不一致は解消されません。売上計上日、返品の扱い、顧客コード、組織コードといった業務ルールを先に決める必要があります。

開発の最初に「Synapseを導入する」という目的を置くと、機能を増やすことがゴールになりがちです。「月次の経営会議で手作業の集計をなくす」「在庫差異を翌日までに把握する」「製造ラインの異常を担当者へ通知する」のように、改善する意思決定と期限を定めます。目的、利用者、データ鮮度、正確性、提供方法をセットで決めると、必要な構成と費用を比較しやすくなります。

定型的な集計を多数の利用者へ安定して提供し、性能を予測したい場合は専用SQLプールが候補になります。データレイク上のParquetやCSVなどを、まずコピーせずに探索したい場合はサーバーレスSQLが向いています。サーバーレスSQLは予約したクラスターを持たず、実行したクエリが処理したデータ量に応じて課金される仕組みです（出典: Microsoft Learn「Azure Synapse AnalyticsのサーバーレスSQLプール」、2026年8月確認）。大量データの加工、ノートブック、機械学習、複雑なデータエンジニアリングにはSparkを組み合わせます。

実際には、専用SQLかサーバーレスSQLかの二者択一ではありません。PoCではADLS Gen2とサーバーレスSQLでデータ構造と処理量を確認し、利用頻度と性能が固まったら専用SQLや集計テーブルを追加する方法があります。Pipelinesで基幹DBやSaaSからデータを取り込み、Synapseでモデル化し、Power BIで可視化する構成が基本形です。Microsoft Learnでは、SynapseのPipelinesが90以上のデータソースへの取り込みや、ノートブック、Sparkジョブ、SQLスクリプトの調整に対応すると説明されています（出典: Microsoft Learn「Azure Synapse Analyticsとは」、2026年8月確認）。

Azure Synapse Analyticsのシステム開発はどのように進めますか？

Azure Synapse Analyticsのシステム開発は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズで進めます。各段階で「何を決めるか」と「次へ進む終了条件」を設定すると、後工程での作り直しを抑えられます。特に分析基盤では、アプリケーションの画面仕様より先に、データの意味、更新頻度、品質責任者、利用権限を決めることが重要です。

要件整理では、最初に業務上の目的とKPIを1〜2個へ絞ります。経営ダッシュボードを作る場合でも、売上、粗利、在庫回転、受注残をすべて同時に完成させようとせず、最初に意思決定を変える指標を選びます。KPIごとに定義、計算式、基準日時、更新頻度、目標値、責任部門を決め、同じ用語が部署によって違う場合は用語集へ記録します。

次にデータソースを棚卸しします。対象システム、データ所有者、接続方法、主キー、更新頻度、保存期間、欠損や重複の状況、個人情報の有無、過去データの移行範囲を一覧にします。「基幹DBから毎日取り込む」と書くだけでは不十分で、抽出可能な時間帯、差分抽出のキー、失敗時の再実行、削除や訂正をどう反映するかまで確認します。終了条件は、対象範囲、成功KPI、利用者、データ分類、概算予算、PoCの合否基準が合意されていることです。

この段階で、分析基盤を使う部門と、データ品質を直す部門を分けないことも大切です。IT部門だけが要件を書いても、顧客コードの統合や返品処理の判断はできません。業務部門、データ管理者、セキュリティ担当、運用担当を含む会議体を設け、判断を議事録とデータ辞書に残します。

選定では、Synapseの機能一覧を比較するのではなく、要件に対してどの構成が過不足ないかを評価します。定型レポートを毎朝更新し、応答時間を安定させるなら専用SQL、利用頻度が読めない探索や小規模PoCならサーバーレスSQL、複雑な加工や機械学習ならSparkを候補にします。リアルタイム性が高いログ分析、業務トランザクション、機械学習の運用などは、Azure Data Explorer、Azure SQL、Databricks、Microsoft Fabricを含めて比較します。

既存のAzure Data Factory、Power BI、Dataverse、Azure Machine Learning、Entra IDを利用している企業は、既存資産を残した段階導入が可能です。新規のDWH構築では、Microsoft Fabricも比較対象に入れます。MicrosoftのFabric移行ガイドには、専用SQLプールからFabric Data Warehouseへの移行アシスタント、Sparkやパイプラインの移行方法が整理されています（出典: Microsoft Learn「Microsoft Fabric migration overview」、最終更新2026年4月、2026年8月確認）。これはSynapseを直ちに採用してはいけないという意味ではなく、SQL、データモデル、パイプライン、ノートブックを将来再利用できる設計にするという判断材料です。

選定時のチェック項目は、データ所在地、個人情報の扱い、ネットワーク接続、必要なSLA、データ鮮度、同時利用者数、ピーク時の処理量、予算上限、監視と問い合わせの担当です。候補構成ごとに、同じ実データで処理時間、処理量、費用、権限、障害時の再実行を測定します。パンフレット上の性能値だけでなく、自社の代表的なクエリが基準を満たすかをPoCで確認します。

設計では、データレイクのRaw、Cleansed、Curatedなどの層を決め、元データを残すのか、加工済みデータをどの粒度で提供するのかを定義します。取り込み日時、元システム、ファイル名、処理件数、エラー理由、再処理番号などの監査項目を持たせると、数字が変わったときに原因を追いやすくなります。顧客や商品の名寄せルール、履歴の持ち方、論理削除、遅れて届いたデータの処理も、SQLを書く前に設計します。

開発環境、検証環境、本番環境を分け、Git連携とCI/CDを使ってSQL、パイプライン、ノートブック、設定を管理します。BicepやTerraformなどのInfrastructure as Codeを採用すると、構成を再現しやすくなります。秘密情報をソースコードやノートブックに直接書かず、Managed IdentityやKey Vaultを使い、環境ごとの接続先は安全な変数で切り替えます。開発会社へ依頼する場合は、SQL、ノートブック、パイプライン定義、IaC、データ辞書、テスト結果、運用手順を納品物に明記します。

権限設計では、Microsoft Entra IDのグループを軸に、管理者、データエンジニア、開発者、分析者、閲覧者などの役割を分けます。Synapse RBAC、SQL権限、ADLSのアクセス制御を重ねるときは、誰がどの層を読めるかを一覧化し、過剰権限をなくします。個人情報を含む場合は、列や行の制御、マスキング、監査ログ、保存期間、削除手順を非機能要件へ含めます。機密性が高い場合は、Private LinkやManaged Virtual Networkを検討します。公式ドキュメントでは、ワークスペース作成時に専用SQLとサーバーレスSQL向けのマネージドプライベートエンドポイントが作成され、これら自体には課金されないと説明されています（出典: Microsoft Learn「マネージドプライベートエンドポイント」、2026年8月確認）。

テストは、パイプラインが正常終了することだけを確認する工程ではありません。件数、合計金額、キーの重複、欠損、日付、文字コード、タイムゾーン、更新遅延を確認し、業務部門が正しいと判断できる基準を設定します。元システムの集計値とCurated層の集計値を比較し、差異がある場合は、仕様上の差なのか、取り込み漏れなのか、名寄せの誤りなのかを切り分けます。

性能テストでは、通常時と月末・締め日などのピーク時を分けて測定します。利用者数、同時実行クエリ、データ量、処理時間、失敗率、処理したデータ量を記録し、専用SQLのサイズやファイル形式、パーティション、クエリの書き方を見直します。サーバーレスSQLは必要な列とパーティションだけを読む設計にしないと処理量が増えるため、費用テストも性能テストと同時に行います。

セキュリティテストでは、役割ごとに見えるデータが異なること、退職者や異動者の権限が適切に外れること、Private Link経由で接続できること、監査ログが取得できることを確認します。移行を伴う場合は、全量移行の前にサンプル移行とリハーサルを行い、失敗時に元へ戻せる手順を実行します。リリース判定は、重大なデータ欠陥が残っていないこと、復旧手順を担当者が実行できること、利用部門が受入条件へ合意していることを条件にします。

稼働前には、カットオーバー計画を作成します。データ抽出、最終取り込み、件数照合、権限反映、Power BIの接続先変更、利用者への告知、監視開始、判定会議を時系列に並べ、担当者と所要時間を割り当てます。業務停止を許容できない場合は、段階稼働や並行稼働を検討し、旧基盤をいつまで参照可能にするかを決めます。

本番環境では、Pipelinesの失敗、取り込み遅延、処理件数の異常、データ品質エラー、専用SQLの稼働状態、Sparkジョブ、ストレージ増加、予算超過を監視します。アラートは設定するだけでなく、誰が何分以内に確認し、再実行、原因調査、利用者通知、エスカレーションを行うかを決めます。障害対応の記録を残し、同じ失敗を防ぐためにパイプラインやデータ品質ルールへ反映します。

Azure利用料は稼働後に想定を超えることがあります。専用SQLプールを夜間や休日に停止できるか、サーバーレスSQLのクエリ処理量に上限や予算アラートを置くか、Sparkの自動停止を設定するかを運用手順へ入れます。Microsoftの価格情報では、予約容量を1年または3年契約で購入すると、データウェアハウスのコンピューティング料金を従量課金と比べて最大65%節約できる場合があるとされていますが、利用状況と契約条件で変わり、ストレージやネットワーク費用がすべて消えるわけではありません（出典: Microsoft Azure「Azure Synapse Analyticsの価格」、2026年8月確認）。

稼働しただけでは、分析基盤は定着しません。利用者がダッシュボードを見て意思決定を変えたか、手作業の集計時間が減ったか、データ品質エラーが減ったか、レポートの更新遅延が改善したかを月次で測定します。利用ログの閲覧回数だけでなく、会議で使われた指標、業務改善の件数、問い合わせ内容を確認すると、役に立つデータと使われないデータを区別できます。

利用者向けには、ダッシュボードの操作説明だけでなく、指標の定義、データの更新時刻、問い合わせ先、誤りを見つけた場合の連絡方法を伝えます。データエンジニアを社内で育成する場合は、SQL、データモデル、パイプライン再実行、権限申請、コスト確認を扱う演習を用意します。外部ベンダーへ依頼する場合も、毎月のレビューと設計書の更新を契約へ含め、担当者が変わっても運用できる状態を作ります。

導入事例として、Microsoftが公開するクラレのケースでは、Azure Data FactoryでデータをADLS Gen2へ集約し、名寄せ後にSynapseのデータモデルへまとめ、Power BIで約700名が利用しています。PoCでは開発リードタイム、アクセス制御、多様なデータソース、データカタログの4点を評価し、段階的な展開と内製化につなげています（出典: Microsoft Customer Stories「Azure Synapse AnalyticsとPower BIでデータ活用基盤を確立」、2024年3月、2026年8月確認）。自社でも、最初から全社展開を目指すより、一つのKPIを使える状態にしてから対象部門を広げる方が、利用定着と費用対効果を確認しやすくなります。

Azure Synapse Analyticsのシステム開発費用相場

Azure Synapse Analyticsの受託開発費について、国内案件を横断した公的な相場統計は確認できません。そのため、以下はリサーチノートにある業務システムの一般的な費用情報と、Synapse、ADLS Gen2、Pipelines、Power BIなどを組み合わせる構成から作った2025〜2026年時点の企画用レンジです。確定金額ではなく、データ量、接続先、性能、移行、権限、運用時間によって変動する前提で使用します。

小規模PoCは、100万〜500万円程度が企画段階の目安です。1〜3個のデータソース、ADLS Gen2、サーバーレスSQL、少数のPower BIレポートを対象にし、処理時間、データ品質、権限、月間のAzure利用量を測定します。全社のネットワーク設計、個人情報の匿名化、既存DWHの全量移行、複雑な名寄せまで含める場合は、PoCの範囲を超えるため、このレンジだけで判断しません。

部門横断の実用基盤は500万〜2,000万円程度、複数の基幹システムやERP、CRM、生産データをつなぐ全社DWHは2,000万〜1億円以上が企画用の目安です。高度なリアルタイム処理、複数リージョン、厳格なSLA、機械学習、既存DWHからの大規模移行を組み合わせると、1億円を超える可能性もあります。これらは類似案件の一般的なレンジから推定したもので、Synapseだけのライセンス価格を示すものではありません（出典: NotebookLM Q&A「業務システム全般_17」から抽出した業務システム費用の整理、2026年）。

Azure利用料には、専用SQLプールの計算資源と稼働時間、サーバーレスSQLの処理データ量、Sparkのノード稼働時間、ADLS Gen2の保存量、Pipelinesのアクティビティやデータ移動、Power BI、Private Link、バックアップ、ネットワーク転送などが含まれます。開発会社へ払う初期費用とAzureへ払うクラウド費用を一つの月額に混ぜると、利用量が増えたときの原因を追えません。見積書では、初期開発費、Azure利用料、保守運用費、ライセンス費を分けます。

小規模PoCのAzure利用料は月1万〜30万円程度、部門横断の基盤は月10万〜100万円程度、全社基盤は月50万〜500万円程度を仮置きできます。ただし、これはリサーチノートの構成別推定レンジであり、特定の契約やリージョンの料金を保証するものではありません。実際には、データ量、実行回数、稼働時間、同時利用、為替、契約割引で変わります。Azure Pricing Calculatorへ前提を入力し、少なくとも通常月、繁忙月、データ増加後の3ケースで確認します。

保守運用には、パイプラインの失敗対応、データ品質エラーの調査、権限追加、SQLやデータモデルの軽微な変更、監視、コスト確認、Azure仕様変更への対応が含まれます。リサーチノートにある業務システムの一般的な目安では、保守費は初期開発費の年15〜25％程度です。ただし、24時間365日の監視、SLA、月次のデータソース追加、Power BIのレポート改修、Azure請求代行、セキュリティ監査を含めるかで変わります。定額範囲と追加見積もりになる作業を契約前に分けておきます。

費用を抑えるには、最初から大きな専用SQLプールや複雑なSpark基盤を用意するのではなく、目的を絞ったPoCで実データとクエリを測定します。サーバーレスSQLで探索し、Parquet化やパーティションを施し、それでも安定性能が必要な処理だけを専用SQLへ移す流れが候補になります。安さだけでなく、将来の利用者増加、データ量の増加、再処理のしやすさ、運用担当者の負担まで含めて比較します。

Azure Synapse Analyticsの見積もりを取る際のポイント

Azure Synapse Analyticsの見積もりは、ワークスペース構築費だけを比べると判断を誤ります。データソースの数、データの品質、更新頻度、保持期間、利用者、権限、移行、BI、ネットワーク、監視、教育、成果物を同じ前提でそろえ、初期費用と運用費を分けて比較します。金額の安さより、後から追加費用になりやすい作業が明示されているかを確認することが重要です。

RFPには、対象データの種類と件数、1日または1か月あたりの増加量、過去何年分を保持するか、ソースごとの更新頻度、許容される遅延、利用者数、同時利用者数、必要なレポート数を記載します。接続先は「基幹システム数」だけでなく、SQL Server、SAP、Salesforce、ファイル、API、IoTなど方式も示します。差分抽出が可能か、削除や訂正を受け取れるか、テスト用データを提供できるかも明記します。

非機能要件では、目標復旧時間と目標復旧時点、稼働時間、障害通知時間、監査ログの保存期間、ネットワーク経路、データ所在地、個人情報のマスキング、権限申請の承認者、コスト上限を指定します。受入条件は「使えること」ではなく、「毎日午前8時までに前日データが反映され、売上合計が元システムと許容差の範囲で一致する」のように測定可能な表現へ変えます。

候補会社には、Azureの構築実績だけでなく、データモデリング、名寄せ、Power BI、権限、監視、FinOps、内製化支援の経験を確認します。類似案件について、データソース数、データ量、利用者数、更新頻度、PoCの期間、運用体制、障害対応、納品物を質問します。Microsoftの公式パートナー掲載は候補を探す材料になりますが、掲載だけで品質や価格が保証されるわけではないため、担当者と実績の範囲を個別に確認します。

提案書では、専用SQL、サーバーレスSQL、Sparkをなぜ選ぶのか、FabricやDatabricksをなぜ採用しないのか、または併用するのかを説明してもらいます。PoCで検証する項目、実データの持ち出し方法、性能測定の条件、Azure利用料の試算根拠、将来のデータ量増加への対応も比較します。自社の要件に対して一つの製品だけを勧める会社より、複数案の差分と採用理由を説明できる会社の方が、長期の判断をしやすくなります。

受託開発では、開発費を支払えばすべてのソースコードや設計資産を自由に改修できるとは限りません。SQL、Sparkノートブック、Pipelines、IaC、データモデル、テストデータ、運用手順、監視設定、ダッシュボード、API仕様を納品物として列挙し、利用許諾、改修、再委託、契約終了時の引き渡し条件を確認します。既存のテンプレートや第三者ライブラリが含まれる場合の権利関係も、法務と確認します。

責任分界では、開発会社が管理する範囲、Azureのサービス提供元が担う範囲、自社が担うデータ品質と権限申請を分けます。Azure利用料を誰が契約し、予算超過時に誰が通知し、障害時にどの窓口へ連絡するかを決めます。データ仕様の追加、レポートの追加、過去データの再加工、法改正やセキュリティ要件の変更は、定額保守に含むか追加見積もりにするかを契約へ書きます。

見積もりの比較では、金額を同じ期間と範囲へそろえます。初期開発費だけが安い場合、要件定義、移行、テスト、教育、監視、コスト最適化が別料金になっている可能性があります。月額費用も、Azure利用料を含むのか、保守人件費だけなのかを確認し、通常月と繁忙月の想定を分けます。前提条件が書かれていない見積もりは、金額が低くても比較材料として不十分です。

よくある質問（FAQ）

ここでは、Azure Synapse Analyticsの導入前に多く寄せられる疑問へ、費用と進め方の前提を含めて回答します。製品の選択は、データ量だけでなく、利用頻度、性能、データ品質、権限、運用体制を合わせて判断します。

小規模PoCは1〜3か月、部門横断の実用基盤は3〜6か月、複数の基幹システムを含む全社DWHは6〜18か月程度が企画上の目安です。データ品質の修正、名寄せ、既存DWH移行、ネットワークや個人情報の要件が増えると期間は延びます。最初に一つのKPIでPoCを行い、検証結果を使って本番範囲を決めると、全社要件を先に固定するより計画を立てやすくなります。

予測可能な性能で定型集計を継続的に提供したい場合は専用SQLプール、データレイクの探索や不定期のクエリ、PoCを始めたい場合はサーバーレスSQLが候補です。サーバーレスSQLは処理したデータ量に応じて課金されるため、利用頻度が高い処理や全量スキャンが多い処理では、専用SQL、集計テーブル、ファイル最適化と比較します。実データで処理時間と費用を測定してから決めることが安全です。

Azure Synapse Analyticsは既存のAzure環境やSQL、Spark、Pipelines、Power BIを組み合わせられる分析基盤として利用できます。ただし、MicrosoftはFabric Data WarehouseやSynapseからFabricへの移行方法も案内しているため、新規案件ではFabricと比較し、将来の移行可能性を設計へ含めます。特定のプレビュー機能へ本番を依存せず、データモデル、SQL、パイプライン、ノートブックを管理可能な資産として残すことが重要です。

技術的な品質チェックやパイプラインの実装は開発会社へ依頼できますが、売上や顧客の定義、名寄せルール、例外処理の業務判断まで丸ごと任せることは難しいです。各データの所有者と品質責任者を社内で決め、開発会社とデータ辞書、受入基準、エラー時の対応を合意します。契約には品質確認の作業、検証用データの提供、修正回数、追加データの扱いを記載します。

Azureの環境構築だけでなく、業務要件、データモデル、名寄せ、Power BI、セキュリティ、運用、FinOps、内製化まで対応できる会社を選びます。類似案件のデータソース数と利用者数、PoCで測る項目、担当者の経験、成果物、保守範囲、Azure利用料の試算根拠を確認します。Synapse、Fabric、Databricksなどの選択肢を要件に沿って説明し、都合の悪い前提や追加費用も明示できる会社が望ましいです。

まとめ

Azure Synapse Analyticsのシステム開発は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズで進めます。最初に業務KPIとデータの意味を決め、専用SQL、サーバーレスSQL、Sparkを目的に合わせて選び、ADLS Gen2、Pipelines、Power BI、Entra ID、監視までを一つの基盤として設計します。Synapseを導入すること自体ではなく、正しいデータを必要な人へ安全に届け、業務の意思決定を改善することが目的です。

費用の目安は、小規模PoCで100万〜500万円程度、部門横断の実用基盤で500万〜2,000万円程度、全社DWHで2,000万〜1億円以上です。Azure利用料は専用SQL、サーバーレスSQL、Spark、ストレージ、Pipelines、ネットワークなどの利用量で変わるため、初期開発費、クラウド費用、保守費を分けて試算します。金額の根拠として、データ量、更新頻度、稼働時間、利用者、セキュリティ、移行範囲、運用時間を見積もりへ記載します。

最初の一歩は、改善したい業務判断、対象データ、更新期限、利用者、品質基準を決めることです。そのうえで、実データを使って処理時間、データ品質、権限、費用を測定し、採用構成を決めます。開発会社を比較するときは、技術名称だけでなく、業務理解、データモデリング、運用、内製化、成果物の引き渡しまで確認します。Fabricなど将来の選択肢があることも踏まえ、データモデルやSQL、パイプラインを再利用できる形で管理すると、長期的な変更に対応しやすくなります。

▼全体ガイドの記事
・Azure Synapse Analyticsのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。