Netlifyのシステム開発の発注/外注/依頼/委託方法について

Netlifyのシステム開発を発注するときは、要件を整理し、委託形態と契約を決めたうえで、開発・移行・運用移管の順に進めます。この流れに沿うと、責任の範囲と費用を明確にできます。

全体像は、Netlifyのシステム開発の完全ガイドもあわせてご覧ください。

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

Netlifyのシステムを発注する前に知っておきたい全体像

Netlifyシステムの発注範囲を3枚のパネルで示した図解。
「Netlify構築一式」の内訳を確認する視点がそろいます。

Netlifyは、Gitリポジトリのコードをビルドし、WebサイトやWebアプリをエッジやCDNから配信するクラウド基盤です。ERPやCRMのような業務パッケージではないため、業務の機能は別途用意する必要があります。そのため、発注時は「Netlifyを導入する」だけで終わらせず、どの機能をどのサービスで実現するかを分けて考えます。

Netlifyとフロントエンドの発注範囲

Netlifyが担う範囲と、別途設計や見積もりが必要な作業を分けて確認します。

  • ビルド・配信:Astro、Next.js、Gatsby、Eleventyなどのフロントエンド
  • 別途見積もる作業:デザイン、レスポンシブ、SEO、アクセシビリティ、画像、フォーム、リダイレクト
  • 適した画面:企業サイト、メディア、製品、ドキュメント、キャンペーン、ヘッドレスEC

見積書に「Netlify構築一式」とある場合は、上の内訳に照らして成果物の範囲を確認します。

複雑なトランザクションや常時のサーバー側セッションを使う業務システムでは、バックエンドをAWS、Azure、GCPなどに置く構成が現実的です。その場合、Netlifyは公開フロントに限定します。

CMS・API・データベースとの責任分界

編集者やデータ管理の要件を洗い出し、CMSや障害対応をどこまで誰が受け持つかを決めます。

  • CMS候補:Contentful、Sanity、Contentstack、microCMS、WordPress、Shopify
  • 比較項目:権限、承認、多言語、プレビュー、API制限、Webhook再ビルド
  • データ管理:顧客、注文、在庫、会員情報の保管場所
  • 障害対応:監視、ログ、連絡先、一次対応者、認証の境界

Netlifyは、コンテンツの正本データを必ず保管するわけではありません。監視とログの担当を決めておかないと、各社が障害を自社の範囲外だと説明する恐れがあります。

構成図では、サービス名とデータの流れ、認証の境界を示し、障害時の一次対応者も書き込みます。

Netlifyの発注形態の選び方

要件が固まっていない企業は、企画・要件定義から支援する会社に一括で委託する形が適しています。一方で、社内にプロジェクト責任者と技術責任者がいる企業は、部分委託や伴走型が合います。

納期と責任の所在を重視するなら請負契約、仕様変更が多いなら準委任契約を中心に検討します。

責任の一本化を優先する場合の一括委託

一括委託では、複数社との調整の負担を減らせます。さらに、窓口とシステム全体の品質責任を明確にできます。

  • 委託範囲:要件定義、デザイン、開発、CMS連携、テスト、移行、保守
  • 向く条件:社内のWeb開発経験が少ない、または移行期限がある
  • 所有権の確認:Netlify、CMS、リポジトリ、ドメイン、DNS、分析データ

ただし、一括で委託しても、すべてのサービスを同じ会社が運営するとは限りません。そのため、サービスごとの所有者を契約書と引き継ぎ資料に残しておきます。所有権が委託先に集中すると、乗り換えの際に費用や停止のリスクが生じます。

社内に責任者がいる場合の部分委託・伴走型

社内で要件やコンテンツを決められる場合は、必要な作業だけを選んで外注できます。

  • 部分委託:初期構築、CI/CD、CMS連携、移行、セキュリティレビュー
  • 伴走型:月単位または稼働時間単位で専門家を確保し、優先順位を調整
  • 向く作業:技術PoC、CMS移行検証、運用チームへのCI/CD移管

部分委託は費用を抑えやすい一方で、仕様書や承認が遅れると、開発会社の稼働だけが延びます。素材やテスト、公開判断が遅れる場合も、開発会社の稼働が延びる原因になります。

契約の前に、月間の稼働時間と対応曜日を決め、緊急対応の条件と成果物の定義も書面にしておきます。

作業段階ごとの請負・準委任・保守契約の使い分け

作業がどこまで確定しているかに合わせて、請負、準委任、保守契約を使い分けます。

  • 請負:ページ数、機能、対応ブラウザ、CMS項目、テスト、納品物、検収条件を定義できる作業
  • 準委任:専門知識を持つ担当者が、調査、要件定義、PoC、運用改善などを遂行
  • 保守:障害対応時間、一次切り分け、復旧目標、定例会、改善枠を定める

要件が固まらないまま「Netlifyで新サイトを作る」と契約すると、追加要件をめぐって対立が生じるおそれがあります。契約を分けると、初期費用と運用費の境界が明確になります。

ポイント

発注形態は、社内に責任者がいるか、要件がどこまで決まっているかで見当をつけます。契約は、作業がどこまで確定しているかに応じて、請負、準委任、保守を使い分けます。

発注前のRFPと要件整理の範囲

RFPに整理する3項目をチェックカードで示した図解。
決まっていない要件はPoCの検収条件に位置づけられます。

RFPは完成した設計書ではなく、複数社が同じ前提で提案と見積を出すために、発注者側が用意する資料です。要件がすべて決まっていなくても作成できます。

RFPでは、目的と現状の課題、対象範囲、期限を先に書きます。そのうえで、予算の考え方と期待する成果を書き、候補サービスや委託先への提案依頼も、項目を分けて書きます。

RFPの目的と業務成果

要望は、測れる成果の形に言い換えて、現状資料と移行条件とあわせてRFPに記載します。

  • 成果指標:記事公開時間、URL移行率、フォーム処理時間、想定アクセス時間帯
  • 現状資料:サイトマップ、ページ数、月間PV、ピークアクセス、URL、CMS、API、ファイル容量
  • 移行情報:利用者・権限、担当人数、残す・統合・廃止するURL

売上や問い合わせ数を目標にする場合でも、結果はNetlifyだけで決まるわけではありません。そのため、サイト改善、広告、コンテンツ運用の前提も書き添えます。また、301リダイレクトと検索計測の扱いも、RFPに含めます。

非機能要件と責任分界の数値・表

費用が膨らむのを防ぐため、非機能要件と担当を数値や表にまとめます。

  • 性能・稼働:公開反映時間、ビルド時間、同時アクセス、稼働時間
  • 復旧・安全:RTO・RPO、ログ保存期間、バックアップ、脆弱性対応、個人情報の保存先
  • 利用条件:対応ブラウザ、アクセシビリティ

「Netlify」「開発会社」「発注者」「外部サービス契約者」の責任分界表を作ると、提案を比べやすくなります。たとえば、Netlifyの障害はNetlifyへ、認証エラーは開発会社へ連絡します。CMS入力は発注者が、個人情報は法務と発注者が確認するように、担当と期限を割り当てます。

PoCと検収条件の決め方

技術選定に迷う場合は、本番構築の前に、代表的なコンテンツ種別を一つだけ移すPoCを依頼します。

  • 動作検証:CMS更新、プレビュー、Webhook再ビルド、主要API、失敗時のロールバック
  • 検収条件:表示速度、編集のしやすさ、プレビューと本番の権限分離
  • 安全性:環境変数を露出させず、主要エラーをログで追えること

PoCでは運用の負荷を確認します。あわせて、Netlifyの経験のほか、CMS設計の実行力と、テスト・移行・引き継ぎの進め方も確かめます。

ポイント

RFPは、複数社が同じ前提で見積を出せる程度に、目的や対象範囲、期限を書けば足ります。要件が決まらない部分は、PoCの検収条件として先に決めておくと、提案の質がそろいます。

Netlifyのシステム開発を外注する進め方

企画・要件定義から移行・公開・運用移管までをつないだ図解。
公開後の運用移管までを、開発工程に含めて考えられます。

外注は、発注先を決めたところで終わりません。各段階で、発注者が判断することと委託先が作業することを分けます。そのうえで、工程ごとの終了条件を合意しておくと、公開直前に未決定の事項が集中するのを防げます。

企画・要件定義でのシステムの境界

配信する範囲、必要な機能、現場の業務フローを確認し、そのうえで構成を決めます。

  • 境界:Netlifyの配信と外部バックエンド・SaaSの分担
  • 機能・連携:頻度、編集者・承認者、会員、検索、予約、決済、CRM・基幹
  • 業務フロー:編集者、紙・Excel・メールでの承認やマスタ更新

実際に編集を担う人も、この段階から参加します。画面が現場の更新フローに合わなければ、定着しません。あわせて、システムへ移す作業と、人が判断する作業を分けます。

設計・開発の環境分離とレビュー

環境を分けること、変更を管理する方法、フレームワークの比べ方を決めます。変更は、目的、影響、工数、納期、運用負荷を記録したうえで、発注者が承認して進めます。

  • 公開フロー:環境、Git、プルリクエスト、Deploy Preview、レビュー、承認、公開、ロールバック
  • 機密情報:環境変数を分離し、DNS変更の権限と時期を決める
  • 候補技術:静的中心はAstro・Eleventy、Reactの動的画面や処理はNext.jsなど

フレームワークは、SEOや再ビルド時間、SSRやISRの必要性で比べます。加えて、開発者を採用しやすいかや将来の保守費も見ます。そのうえで、選んだ理由を設計書に残します。

移行・公開・運用移管の工程

移行の対象、公開前のテスト、運用の引き継ぎを、開発工程の中に含めます。

  • 移行確認:コンテンツ、URL、タイトル、メタ情報、見出し、構造化データ、画像、内部参照
  • 公開テスト:更新、フォーム、認証、権限、404、リダイレクト、検索、負荷、アクセシビリティ、ブラウザ
  • 引き継ぎ:手順書、構成図、環境、連絡先、バックアップ、復旧手順、ソース

一度に大量に移すより、代表的なページで変換ルールを決め、件数とエラーを記録しながら段階的に移すほうが安全です。また、サイトマップやリダイレクト、計測タグも確認します。そのうえで、発注者だけで運用できるよう、運用資料とソースコードを引き渡します。

ポイント

各工程で、発注者が判断する事項と委託先の作業を分けて考えます。工程ごとの終了条件を先に合意しておけば、公開直前に未決定の事項が残る事態を避けられます。

Netlifyのシステム発注費用と料金相場

費用は、Netlifyの利用料と外部サービスの料金、設計・開発・移行の初期費用、公開後の保守改善費に分けて考えます。Netlifyの月額だけを見て安いと判断すると、後からCMSや検索、画像配信の利用料が加算されます。さらに、認証や監視、翻訳、決済、APIの利用料も加わります。

最新のクレジット制での利用料の試算

利用料は、プラン料金、クレジットの消費量、上限に達したときの扱いを順に確認して試算します。

  • Free・Personal:月額0ドル・月300クレジット、月額9ドル・月1,000クレジット
  • Pro・Enterprise:月額20ドルから・月3,000クレジットから、Enterpriseは月額500ドルからのカスタム契約
  • Pro追加階層:月5,000、10,000、15,000、20,000クレジット。上位は未使用分を翌月繰り越し
  • 消費量:デプロイ1回15、コンピュート1GB時間10、帯域1GB20、Webリクエスト1万件2クレジット

これらは2026年8月時点の料金です(出典: Netlify料金ページ・公式Changelog、2026年確認)。Freeは上限に達すると停止し、有料プランでも自動追加を使わない場合は停止する可能性があります。そのため、アクセスが急増したときの予算上限と通知方法も、発注条件に含めます(出典: Netlify料金ページ、2026年8月確認)。

規模ごとの開発費のレンジ

次の金額は企画段階の推定で、Netlifyが公表する一律の価格ではありません。一般的な相場と、Netlifyの構成や事例を照らし合わせて作っています。

  • 小規模サイト:企業サイト、LP、数十ページは150万〜500万円
  • コンテンツサイト:CMS・多言語・検索を含むメディアや製品は400万〜1,200万円
  • 業務系費用:会員・予約・業務ポータル800万〜2,000万円、ヘッドレスEC・基幹連携は1,500万〜5,000万円以上
  • 期間目安:小規模1.5〜4か月、コンテンツ3〜8か月、会員系5〜12か月、大規模連携6〜18か月

Netlifyの公式事例では、Sennheiserのコンポーザブルコマースで、MVPを11週間で構築したと紹介されています。ただし、既存の資産、チーム、対象範囲が異なるため、他社案件の納期を約束する根拠にはなりません(出典: Netlify公式事例、2022年公開・2026年確認)。

初期費用と継続費用の内訳

初期費用と継続費用は分けて、それぞれの作業範囲と配分を確認します。

  • 初期作業:企画、要件定義、設計、デザイン、実装、CMS、API、インフラ、テスト、移行、SEO、教育、文書
  • 初期配分の仮説:要件定義10〜15%、設計25〜35%、実装・単体テスト30〜40%
  • 継続費用:Netlify、CMS・検索・監視・認証・翻訳・決済、ドメイン・証明書、保守、障害・脆弱性対応、改善、追加開発
  • 保守改善の目安:初期開発費の年10〜20%程度

結合・総合テストの15〜20%、移行・教育の5〜10%も目安です。ただし、実際の比率は案件の難易度によって変わります。

保守改善の目安は、SLA、対応時間、月間の改善枠を含むかどうかで大きく変わります。そのため、金額だけでなく、作業の対象と対象外を比べます。

ポイント

費用は、Netlifyの利用料だけで判断せず、外部サービス料金と初期費用、保守改善費を合わせて見ます。金額の大小だけでなく、作業の対象と対象外がそろっているかを比べます。

Netlifyの委託先選定と見積比較のポイント

委託先は、Netlifyの経験だけでなく、業務を理解しているか、CMSの運用や移行を扱えるかで選びます。さらに、API・DB・認証やテストから、セキュリティ、公開後の保守まで扱えるかも見ます。

Netlify公式のAgency Directoryでは、地域や開発、ECといった条件で候補を絞れます。さらに、フレームワークやCMS、予算帯なども条件にできます。ただし、掲載情報を見るだけでなく、自社の要件に合う実績と体制を面談で確かめます。

構成と担当範囲で見る実績

Netlifyの経験の有無だけでなく、どの構成で、どこまでを担当したかを確認します。

  • 構成・得意領域:フレームワーク、CMS、API、認証、検索、決済、移行、多言語、EC
  • 事例の条件:課題、人数、期間、移行件数、運用、障害・変更対応
  • 工程の現実性:自社の承認や素材準備の期間も含む計画

公式事例には、Matter Supply Co.が2名の開発者でNikeのキャンペーンを数週間で進めた例があります。なお、この短い納期は、既存の部品、熟練度、意思決定の速さがそろった結果です。

工程・工数・前提条件を横並びにした見積比較

同じRFPと質問票を渡して前提をそろえ、見積の範囲と追加条件を比べます。

  • 見積範囲:要件定義、ページ、CMS、移行、API、テスト、教育、修正、権限、保守
  • 追加条件:ページ・API本数増の単価、変更締切、納期遅延、外部サービス値上げ
  • 契約条件:休日、時差、通貨・税、キャンセル時の成果物、コード利用権

極端に安い見積では、要件定義や移行、テストやドキュメント、保守が別料金になっている可能性があります。一方で、提案の段階でリスクと未確定事項を示す会社は、発注後の費用も管理しやすい傾向があります。

納品物と引き継ぎによるベンダーロックインの防止

契約書に、納品物と権限、外部サービスの乗り換え条件を書き込みます。

  • コードと権限:ソース、Git、Netlify所有権、CMS管理者、環境変数一覧
  • 運用資料:構成図、API、データモデル、テスト仕様書・結果、移行ログ、リダイレクト、手順、連絡網
  • サービス移行:データ出力可否と契約者変更後の稼働
  • 海外事業者:所在地、委託先、保存先、再委託、削除、事故時通知を法務と確認

秘密情報は、文書に不用意に書かず、安全な方法で引き渡します。

Netlifyは、SOC 2 Type 2、ISO 27001、PCI DSSの情報を公開しています(出典: Netlify Security Overview、2026年確認)。GDPRやCCPAの情報も公開されています(出典: Netlify Security Overview、2026年確認)。

ただし、これらがあっても、日本の個人情報保護法に適合すると自動的に保証されるわけではありません(出典: 個人情報保護委員会ガイドライン、2026年確認)。そのため、法務の確認も発注条件に含めます。

ポイント

委託先は、Netlifyの経験より、自社の要件に近い構成と担当範囲の実績で選びます。見積は前提をそろえて範囲と追加条件を比べ、極端に安い場合は別料金の項目がないかを確かめます。

Netlify案件で起こりやすい失敗と対策

Netlifyは静的配信を中心に組めるため、常時稼働するWebサーバーの運用を減らしやすい基盤です。

ただし、静的ファイルの配信そのものが安全でも、CMSや外部APIには、なおリスクが残ります。さらに、認証や決済、管理画面、Functionsにも、同じように注意が要ります。そのため、「高速で安全」という説明は、範囲ごとに評価します。

過剰カスタマイズと移行遅延の防止

移行では、必要な機能を選んだうえで、要件の変更を管理します。すべてを完全に再現しようとすると、カスタム開発の負担が増える場合があります。

  • 移行機能:入力項目、承認、プレビュー、公開予約から必要な機能を選ぶ
  • 段階移行:不要機能を外し、重要ページから公開する
  • 変更管理:目的、影響、工数、納期、運用負荷を記録し、発注者が承認
  • 準委任:月次報告と次月の優先順位を合意する

段階移行は、全件の移行が遅れて公開が延びるのを抑えます。一方で、要件を追加すると、画面やCMSの作業に続いて、APIやテスト、文書の作業も増えることがあります。また、優先順位を合意しておけば、予算の消化だけが進む状態を防げます。

シークレット・権限・監視の運用設計

秘密情報や権限、監視、復旧手順を、運用設計に含めます。

  • 秘密情報:環境変数やAPIキーをコード、チャット、チケット、画像へ貼らない
  • 権限:最小化し、退職者や契約終了者のアカウントを削除する
  • 監視:ビルド、Webhook、フォーム、認証、API、クレジット、帯域、検索、決済
  • 復旧:前のデプロイ、CMS停止、API迂回、問い合わせ経路の切り替え

公式のチェックリストでは、情報のマスキング、TLS、Content Security Policyなどが案内されています。また、未信頼のプルリクエストで秘密情報を使わない設定も示されています(出典: Netlify Security Checklist、2026年確認)。

復旧手順は、担当者が実際に実行できる内容にしておきます。

導入効果の公開後の測定

導入前の基準値と、公開後の確認時期を決めておくと、効果を測れます。

  • 導入前指標:速度、反映時間、更新工数、問い合わせ率、検索流入、CV、障害件数
  • 公開後確認:1か月、3か月、6か月の時点で、自走、エラー減、利用料の想定内、問い合わせ減を見る
  • 改善契約:データを基に優先順位を決める

事例では、Sennheiserのコンバージョンが136%増え、カート追加操作が74.8%増えました(出典: Netlify公式事例、2022年公開・2026年確認)。ただし、これは同社固有の施策と条件による成果です。

納品日に表示できたかだけでは、発注先を評価できません。データに基づく改善は、必要のない機能追加を避ける助けになります。

Netlifyのシステム発注に関するよくある質問

Netlifyの発注では、料金や技術選定、既存サイトの移行、運用体制について質問が多く寄せられます。無料枠の範囲だけで判断せず、本番運用の責任者と予算上限を決めて確かめます。

Netlifyの無料プランだけで本番サイトを運用できますか?

低トラフィックのサイトや検証環境であれば、無料で始められる場合があります。ただし、本番では利用量と必要な機能を確認します。

  • 利用量:月300クレジットを上限にアクセス、公開、ビルド、Functions、帯域を試算
  • 必要機能:チーム権限、分析履歴、同時ビルド、サポート、SSO、SLA
  • 予算管理:外部サービス込みの月次上限、通知、停止時の連絡先

無料プランは、上限に達すると停止します。そのうえで、必要な機能に応じて、有料プランやEnterpriseを比べます。

WordPressからNetlifyへ移行するときに何を確認すべきですか?

CMSの移行範囲とSEO情報を洗い出し、検証の方法と切り戻しの条件を決めます。

  • CMSと機能:WordPressを残すか別CMSへ移すか。各機能の移行可否
  • 運用検証:正本、権限、プレビュー、Webhook、公開反映をPoCで確認
  • SEO情報:URL、タイトル、メタ、構造化データ、サイトマップ、canonical、リダイレクト、計測
  • 移行後:404・順位変化を監視し、旧サイトへ戻す期間・条件を決める

移行の対象には、記事や画像のほか、フォームや検索、予約、会員機能も含まれます。すべて移せるとは限らないため、移す対象を確定してから、発注範囲を決めます。

Netlifyの開発会社を選ぶときに最初に聞く質問は何ですか?

最初に、似た構成での担当実績、見積範囲、引き継ぎ内容を質問します。

  • 実績:要件定義から運用までの担当、技術、移行件数、保守
  • 対応・納品:障害時の一次対応、成果物、契約終了時の引き継ぎ
  • 見積範囲:ページ、テンプレート、API、CMS、移行、テスト、教育・修正、保守、外部費

回答が曖昧だと、技術力だけでなく、管理と説明責任にも不安が残ります。そのため、契約の前に見積の前提を文書にしておきます。

Netlifyだけで会員機能や基幹システム連携まで実現できますか?

Netlifyだけで完結させず、データと認証は外部に置く構成を基本にします。

  • Netlifyの役割:フロントエンド配信やFunctions
  • 外部に置く情報:会員、注文、在庫、決済、基幹データをAPI・DB等で管理
  • 確認事項:保存先、権限、暗号化、ログ、バックアップ、復旧、海外提供

個人情報や決済情報は、法務とセキュリティの担当者と確認します。また、認証を経て使える画面も、責任分界表に記載します。

まとめ

発注時は、Netlifyの利用料だけでなく、フロントエンドやCMS、API、データベースまで含めて、一つのシステムとして整理します。認証や移行、テストから保守までも、同じ全体の中で扱います。

要件が固まった範囲は請負に、変わりやすい調査や要件定義は準委任に、公開後の改善や障害対応は保守契約に分けると、比較しやすくなります。

発注前のRFPと責任分界の確認

RFPには、目的と業務成果、現状のページやデータ、連携を書きます。さらに、非機能要件と責任分界、移行範囲を記し、検収条件と納品物も書きます。

見積は総額だけでなく、工程や工数、前提条件を横並びにします。外部サービス費や保守、追加変更の条件も比べます。実績は、サービス名でなく構成と担当範囲で確かめます。

2026年時点のNetlify料金や利用量課金は、変わる可能性があります。そのため、契約前に公式料金と自社の利用量を再確認し、停止時の対応と月次の予算上限も決めます。

公開後の運用と引き継ぎの契約範囲

まず、大規模な再構築をすぐに確定せず、代表コンテンツのPoCと編集者の更新テストから始めます。そのうえで、移行リハーサルと公開後の効果測定を段階的に行います。現場で運用でき、担当会社が変わっても引き継げるシステムを目指すことが、発注の失敗を防ぐ最も確実な方法です。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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