Nginxのシステム開発の完全ガイド

Nginxのシステムは、Web配信、プロキシ、負荷分散、キャッシュを役割に応じて組み合わせ、通信を安定させ、安全に運用するために使われます。

全体像、構成の選び方、開発と運用の進め方、費用、開発会社への依頼を順に取り上げます。各テーマの詳細は関連記事で確認できます。

▼関連記事一覧
・Nginxのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Nginxのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Nginxのシステム開発の見積相場や費用/コスト/値段について
・Nginxのシステム開発の発注/外注/依頼/委託方法について

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Nginxのシステムの全体像

Nginxは、フロントのミドルウェアです。静的ファイルを返すほか、複数のアプリサーバーへ処理を振り分けます。

TLSを終端して暗号化通信を処理するため、Webサイトから業務アプリまで幅広く使われています。

Nginxが担う役割

利用者とアプリケーションの間で通信を受け付け、必要な処理を担うのがNginxです。

• 通信経路：DNSやCDN・WAFの後段で通信を受け、アプリサーバーを経由してDBや外部APIへつなぎます。
• TLS終端：証明書や暗号化の設定を、通信の入口にまとめて置けます。
• 入口の制御：URL・ホスト名による振り分けに加え、送信元の制限、レート制限、ログの整形を担います。

公式ドキュメントは、NginxおよびNginx PlusのHTTP負荷分散が、資源利用、スループット、遅延、障害耐性の改善に役立つと説明しています（出典: NGINX公式ドキュメント、2026年）。

ただし、性能や可用性を高めるには、Nginxの導入に加えて、バックエンドの処理時間やDB負荷、帯域、ログ保存先も含めて設計する必要があります。

代表的な機能と活用場面

Nginxは、通信の種類と目的によって使う機能が変わります。主な機能は、次の4つです。

• Webサーバー：企業サイトの画像やCSSなどを配信します。
• リバースプロキシ：業務システムのログイン画面やAPIへの通信を転送します。
• キャッシュ：動画や大容量ファイルの配信で、アプリ側の負担を抑えます。
• 各種プロキシ：HTTP・TCP・UDPやメールの通信を中継します。

WebSocket、gRPC、長時間接続、ファイルアップロードは、通常のWebページとは異なる確認が必要です。そのため、接続の維持、バッファ、アップロードの上限を、通信の種類に合わせて設定します。

たとえば、proxy_read_timeoutなどが不適切だと、Nginxが正常でも利用者側でタイムアウトする場合があります。まず、通信先と条件を具体化してから、採用の目的を決めます。

「速くしたい」という要望を、通信の種類や条件、転送先のバックエンドまで定義して、設計の材料にします。

Nginxの種類と周辺サービスの使い分け

Nginxを選ぶときは、OSS版、商用版、マネージドサービスのどれにするかと、Nginxに担わせる範囲を決めます。ロードバランサー、CDN、WAF、KubernetesのIngressは、役割が重なることがあります。

同じ機能を複数の層で重ねると、障害が起きたときに原因を追いにくくなります。そのため、各層の役割と、どこまでを誰が受け持つかを先に整理します。

OSS版と商用版の違い

OSS版と商用版は、必要な機能と運用体制をもとに比べます。

• OSS版：低コストと自由度が魅力です。単一のWebサーバーやプロキシ、基本的な負荷分散やキャッシュなら、多くのシステムで検討できます。
• OSS版の運用：担当者が更新や脆弱性確認を行い、設定レビューや障害対応も受け持ちます。
• 商用機能：リアルタイムメトリクスやアクティブヘルスチェック、セッション永続化などの機能と、商用サポートです。
• 商用版の適用：常時稼働の業務システムや、短時間で障害を切り分けたい場面で役立ちます。
• 選定条件：OSS版の設定や監視で不足する要件を明文化し、それを基準に選びます。

公開された大規模動画配信サービスでは、Nginxをキャッシュに使い、商用版を汎用サーバー上のロードバランサーとして使っています。専用機器に頼らない構成です。

高価な製品に置き換える前に、キャッシュ、負荷分散、冗長化を要件に合わせて分け、性能試験で妥当性を確かめます。

自社で同じ構成を採る場合は、ピーク時の通信量と障害時の切り替え時間を、先に定義しておきます。

ApacheやマネージドLBとの使い分け

Apache、Nginx、マネージドLBやCDNは、既存の環境と必要な制御の範囲をもとに使い分けます。

• Apache：アプリとの互換性や既存の設定を重視する場合に候補になります。
• Nginx：静的配信、多数の同時接続、前段のプロキシ処理を重視する場合に候補になります。
• マネージドLB・CDN：冗長化や保守を任せる場合に選びます。独自の認証やヘッダー制御が必要なら、Nginxを残せます。
• Nginxを残す範囲：独自のURLルーティングや、アプリに近い変換が必要な箇所です。

既存のモジュールや認証、書き換え規則、運用スキルを確かめたうえで、どの方式が合うかを判断します。停止リスクや検証費用も含めて考えます。

Nginxを採用すること自体は目的にせず、自社で制御する機能と、サービスに任せる機能を分けます。境界を決めておくと、必要以上に機能を重ねた構成を避けられます。

KubernetesのIngress NGINXとNGINX Ingressの違い

移行を始める前に、利用中のコントローラーがどちらかを特定しておきます。

• Ingress NGINX：Kubernetesコミュニティで広く使われてきたコントローラーです。
• NGINX Ingress：別の提供主体が開発するコントローラーです。

名前が似ているため、移行前に対象を確かめる必要があります。Pod名やHelmチャートに加え、マニフェストと設定アノテーションも確認の対象です。確認を怠ると、対象を取り違えるおそれがあります。

公式発表では、保守の停止と退役が案内されており、退役は2026年3月とされています（出典: Kubernetes Steering Committee・Security Response Committee、2026年）。退役後は、バグ修正やセキュリティ修正が提供されなくなります。

一方で、稼働中の環境はただちには止まりません。まず対象かどうかを確かめ、Gateway APIや保守の主体が明確なコントローラーへの移行を計画します。

Nginxのシステム開発の進め方

Nginxの構築は、設定ファイルを書くだけでは終わりません。業務の要件を通信の要件に置き換えるところから始まり、設計から実装、検証、リリースを経て、運用の引き継ぎまで続きます。

既存の環境を移行する場合は、現行の構成を把握してから段階的に切り替えると、停止のリスクを抑えられます。

▶ 詳細はこちら：Nginxのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

要件定義で決める項目

要件定義では、通信量、利用環境、可用性を、測定や判断ができる形にそろえます。

• 通信量・稼働：利用者数、ピーク時のリクエスト、同時接続、許容応答時間、稼働時間、停止可能時間。
• 利用条件：公開・社内の別、個人情報や決済情報、外部APIやファイル連携の有無。
• 測定基準：応答や復旧などを、数値で測れる運用基準として定めます。

たとえば、通常時の応答時間を何秒以内にするかを、要件定義書に書いておきます。さらに、障害から何分以内に復旧するか、ログを何日保管するかも、測定できる形で示します。

可用性の要件では、Nginxを1台で構成するか、2台以上で冗長化するかを決めます。1台構成は安価で簡単な一方、OSの更新や障害の際に入口が止まります。

冗長化するなら、切り替えの仕組みも要件に含めます。ヘルスチェックやセッション共有、証明書の同期、設定の反映方法が、その対象です。

設計・実装で確認するポイント

設計と実装では、通信の設定と、アプリケーションとの境界をはっきりさせます。

• 基本設計：構成図、通信経路、ポート、名前解決、証明書の配置、ログ送信先。
• 詳細設計：server・location、upstream、タイムアウト、バッファ、キャッシュ、制御、エラーページ。
• 設定管理：設定値は担当者の記憶に頼らず、Gitなどで履歴を残してレビューし、本番へ反映します。
• アプリ連携：WebSocketやgRPCの接続要件を確認して、必要な設定を決めます。

セッションをCookieで保持するか共有ストレージを使うか、アップロードをNginxで受けるか専用ストレージへ送るかによって、必要な設定が変わります。

WebSocketやgRPCでは、Upgradeヘッダー、接続の維持、再接続時の挙動を検証します。通常のHTTPプロキシの設定を流用すると、要件を満たせない場合があります。

テスト・リリース・運用引き継ぎ

試験から引き継ぎまでの流れは、障害時の挙動と切り戻しを確かめられるように組みます。

• 障害試験：正常系の動作に加えて、バックエンド停止、過負荷、証明書切れを確認します。さらに、大容量要求、DNS切替、片系停止も確かめます。
• 負荷試験：平均値とピーク時の95パーセンタイル、エラー率、CPU・メモリ・接続数を確かめます。
• リリース：DNSのTTLを調整し、ステージングの後に時間帯を選んで段階的に反映します。
• 引き継ぎ資料：設定ファイル、構成図、ポート一覧、証明書更新、監視、バックアップの内容を含めます。
• 運用手順：ロールバックの手順と脆弱性対応の方針も渡し、引き継ぎ後に特定の担当者しか分からない状態を避けます。

アクセスログとアプリログを同じ時刻基準で追えるようにしておくと、障害の原因を特定しやすくなります。

切り戻しの条件は、エラー率が何分間、何％を超えたら戻すかというかたちで定めます。そのうえで、旧環境もすぐ戻せる状態で待機させます。

▶ 詳細はこちら：Nginxのシステム開発でおすすめの開発会社/ベンダー6選と選び方

Nginxのシステム開発の費用相場と内訳

OSS版のNginxは基本的に無料です。一方で、システム全体には、設計・構築・テストの人件費がかかります。

費用には、サーバーやストレージ、通信が含まれます。さらに、監視、バックアップ、商用サポート、移行、保守の費用もかかります。金額は、トラフィックや可用性、既存システムの複雑さによって変わります。以下は企画段階の目安です。

▶ 詳細はこちら：Nginxのシステム開発の見積相場や費用/コスト/値段について

構成別の初期費用の目安

初期費用は、導入する構成の規模と、作業に含める範囲で変わります。構成ごとの目安は、次の4つです。

• VPS・単一クラウドVM：OS、仮想ホスト、TLS、ログ、疎通確認を含めて、10万〜30万円程度です。
• 運用機能の追加：転送、CI/CD、監視、バックアップ、障害手順、簡易負荷試験を含めて、50万〜150万円程度です。
• 冗長構成：2台以上、LB、WAF、マルチゾーン、切替試験、ログ分析を含めて、200万〜800万円程度です。
• 業務システム刷新：アプリ、データ移行、外部連携、教育を含めると、500万〜2,000万円以上になる場合があります。

Web・業務システムの公開相場は、50万〜2,000万円超まで幅があります。そのため、総額はNginxの設定費に加えて、作業範囲全体で見ることになります（出典: リサーチノート内の公開相場調査、2025〜2026年）。

月額費用と保守費用の考え方

月額費用と保守費用は、構成と委託する作業の範囲によって変わります。

• 小規模構成：VM、ディスク、固定IP、バックアップ、監視を含め、月数千円〜数万円程度からかかります。
• 機能追加後：冗長化、WAF、CDN、ログ保管、データ転送、商用版を加えると、月5万〜30万円以上になる場合があります。
• 保守の仮置き：初期開発費を基準にし、作業範囲に応じて調整します。

クラウドでは、ディスクやロードバランサーなどが、それぞれ別に課金されます。監視、ログ、データ転送も、同じように課金の対象になります。見積書では、サービスごとの月額を確認します。

保守費用の目安は、初期開発費の年10〜20％程度です（出典: 業務システムの保守費用に関するドメインQ&A、2026年）。

OSやNginxの更新だけなら、費用を小さくできます。一方で、24時間監視や障害一次対応、月次報告を含めると、費用は高くなります。さらに、脆弱性対応、負荷試験、設定変更も加わるほど増えます。

契約前には、作業時間の上限と休日対応の単価、緊急時の連絡方法を確かめます。

Nginxのセキュリティと運用保守

Nginxはシステムの入口にあるため、設定ミスや更新の遅れが全体に影響します。そのため、運用設計には、TLS、アクセス制御、レート制限、監視、脆弱性対応を含めておきます。

通信の暗号化に加えて、どこで復号し、内部通信をどう再暗号化するか、クライアントIPを正しく記録できるかも確かめます。

TLS・アクセス制御・脆弱性対応

入口の安全を保つには、暗号化、アクセス制御、脆弱性対応を、それぞれ運用に組み込みます。

• TLS：証明書の発行・更新・失効、秘密鍵、対応バージョン（1.2・1.3）、暗号スイートを確かめます。
• 更新手順：自動更新と安全な反映を用意し、失敗時に切り戻せるようにします。
• アクセス制御：管理画面や内部APIは公開範囲を絞り、送信元IP、認証、レート制限を組み合わせます。

証明書の更新を手作業に頼ると、担当者が不在のときに期限切れが起きかねません。

異常な接続や大容量の要求を制限なく受けると、アプリに届く前に資源が消費されてしまいます。

NGINX公式アドバイザリには、2026年のバッファオーバーフローやHTTP/3関連の脆弱性と、その修正版が掲載されています（出典: NGINX公式セキュリティアドバイザリ、2026年）。そのため、利用中の機能とバージョンを定期的に照合し、修正版を適用するかを判断します。

監視・障害対策・キャッシュ設計

監視やログ、キャッシュ、障害時の切り替えは、一体で設計します。

• 監視：死活や5xx率、4xx急増、応答時間を見ます。接続数、ワーカー、CPU・メモリ、ディスク、バックエンド失敗率も対象です。
• ログ：操作を追跡できるように残し、個人情報や認証情報はマスキングします。
• キャッシュ：対象、保存期間、更新と削除の条件を決めて、古い情報や個人向けの情報が誤って配信されないようにします。

ログインした利用者の扱いと障害時の迂回方法は、決めてから有効化します。そのうえで、障害時に静的画面を返すか、別系統へ切り替えるかを試験します。

Nginxのシステムに対応できる開発会社/ベンダーの選び方

開発会社やベンダーは、Nginxの設定経験に加えて、要件定義や保守まで見られるかで選びます。対象には、クラウド・ネットワーク、セキュリティ、監視、アプリも含まれます。

設定担当とアプリ担当の連携が弱いと、タイムアウトやセッションの不整合が起きたときに、どちらが対応するのかが曖昧になります。

実績で確認する構成と成果

実績を確かめるには、案件の規模や構成、移行の条件、対応したリスクを尋ねます。

• 規模と構成：匿名化された範囲で、利用者数、ピーク負荷、役割、バックエンド、冗長化を確かめます。
• 移行経験：Apacheや専用機器との互換性調査、切り戻し、停止時間を聞きます。
• Kubernetes：コントローラーの区別、Gateway APIへの移行、アノテーションに頼る設定の置換経験があるかを確かめます。

静的配信と業務APIの負荷分散では、必要な設計力が異なります。そのため、実績の件数よりも、自社に似た制約でリスクをどう解消したかを説明できるかを見ます。

対応範囲と保守体制

見積もりの前に、開発と保守の対応範囲を整理し、含まれる作業と契約条件を確かめます。

• 開発範囲：要件、設計、設定、アプリ改修が範囲に入るかを見ます。ネットワーク、証明書、WAFも対象かを確かめます。
• 付帯作業：監視、負荷試験、移行、リリース、教育、ドキュメントの有無を見ます。
• 保守契約：平日・夜間休日の対応、一次切り分け、脆弱性評価期限、月次作業時間の取り決め。
• 契約条件：再委託、担当が交代するときの引き継ぎ、設定や設計書の権利関係の扱いを確かめます。

Nginx設定だけの見積もりが安くても、監視や切り替え試験が別料金であれば、必要な総額は変わります。

相見積もりの金額以外の比較項目

相見積もりでは、構成と作業範囲をそろえたうえで、金額差の理由や提案内容を比べます。

• 工数と構成：要件、設計、実装、試験、移行、教育ごとの見積もりを示してもらいます。1台か冗長か、OSSか商用かの条件もそろえます。
• 評価軸：技術適合性、可用性、セキュリティ、納期を評価表に入れます。加えて、体制、保守、拡張性も項目にします。
• 運用確認：障害時の連絡経路と切り戻し手順を質問し、テストや文書の有無も確かめます。

配点の例は、技術適合性が30点、運用保守と費用が各20点、セキュリティと移行計画が各15点です。なお、重みは事前に決めておきます。

▶ 詳細はこちら：Nginxのシステム開発でおすすめの開発会社/ベンダー6選と選び方

Nginxのシステムを依頼するときのチェックリスト

発注前に要件を整理すると、見積もりを比べやすくなり、プロジェクトの管理もしやすくなります。後から変えると費用がかさむ項目は、先に合意しておきます。

特に、通信量や可用性、セキュリティ、移行条件、運用体制を、早い段階で確かめておきます。すべてを完璧に決めなくても、発注の準備は進められます。

▶ 詳細はこちら：Nginxのシステム開発の発注/外注/依頼/委託方法について

見積依頼書に入れる情報

見積依頼書には、現行環境やアクセス、連携、移行条件を書き、提案の前提をそろえます。

• 現行環境：構成図やユーザー数、ピークアクセスを示します。URL・API、バックエンド、データ、外部連携、証明書、障害履歴も含めます。
• 移行条件：停止可能時間、DNS管理者、旧環境の保持期間、切り戻し期限。
• 非機能要件：可用性、性能、セキュリティを数値で示します。バックアップ、監視、ログ、RTO・RPO、保守時間も数値にします。

条件の例は、月間稼働率99.9％以上、重要APIの95パーセンタイル応答時間1秒以内、障害検知から30分以内の一次連絡です。

数字が未確定の場合は、複数の案を出してもらい、要件を確定するための調査費用は別の項目にします。

納品物と受け入れ条件

納品物には、運用と再現に必要な資料を含めます。受け入れ条件は、試験で確認できる形にそろえます。

• 設計・設定：構成図、設計書、パラメータ表、ポート一覧、設定ファイル、変更履歴。
• 運用手順：証明書更新、監視、ログ、バックアップ・復元、障害対応、切り戻し。
• Infrastructure as Code：設定をコードで管理する場合は、リポジトリと実行方法も納品します。
• 安全な引き継ぎ：秘密情報の保管方法、レビュー・承認の流れ、テスト結果を共有します。
• 受け入れ：疎通、負荷、停止、証明書、アクセス制御を確認します。ログ、切り替え、復旧時間も確かめます。

試験の結果を証拠として残し、未解決の課題には重要度と期限を付けておきます。そうすれば、納品後に運用できない状態を避けられます。

失敗しやすいポイントと予防策

失敗を防ぐには、どこまでを誰が受け持つかを決め、変更の管理や性能の調査、移行の手順を明確にします。

• 責任分界：同じ機能を複数の層に置くと、障害時の原因特定が難しくなります。
• 設定変更：本番で直接変えると、再現性やロールバックの手段を失います。
• 性能・移行：遅いSQLや外部APIなどが原因の場合、プロキシを変えても、遅さの原因には届きにくいです。

CDN、WAF、LB、Nginx、アプリについて、どこまでを担うかを図にします。Nginxの設定はコードにまとめ、ステージングで確かめてから承認の手順を経て反映します。

遅いSQLや外部API、画像の容量、DB接続数を調べます。そのうえで、Nginx、アプリ、DB、ネットワークに分けて計測し、仮説と結果を残します。

移行するときは、旧環境の保持、DNSの切り戻し、担当者の待機を決めておきます。さらに、段階的なリリースと切り戻しの条件も、事前に定めておきます。

よくある質問（FAQ）

Nginxの費用や必要性、Kubernetes移行の判断は、現在の構成と将来の運用体制によって変わります。

Nginxは無料で使えますか？

OSS版Nginxは基本的に無料です。ただし、サーバーやストレージ、通信には費用がかかります。監視、バックアップ、構築、保守も、費用の対象です。

商用サポートや追加機能を選ぶ場合は、ライセンスとサポート料金も含めて総額を比べます。

小規模なシステムにもNginxは必要ですか？

小規模なシステムでは、Nginxを置かなくても済む場合があります。たとえば、小規模サイトでホスティングやマネージドサービスが配信、TLS、監視を提供してくれるなら、個別の管理を避けて負担を抑えられます。

複数のアプリを一つの入口で振り分けたい場合や、独自の制御・キャッシュが必要な場合は、候補になります。将来、冗長化を自社で設計する場合にも、検討できます。

Ingress NGINXを使い続けても問題ありませんか？

2026年3月の退役後は、新しい脆弱性修正やバグ修正が提供されないため、長く使い続ける前提は推奨できません。

まず対象コントローラーがあるかを確認します。そのうえで、通信経路やアノテーション、TLS、認証、レート制限を一覧にします。

移行は、Gateway APIや保守が続く別のコントローラーへ、テスト環境、並行稼働、段階的な切り替えの順で進めます。

Nginxの構築は開発会社に依頼した方がよいですか？

可用性、セキュリティ、移行、アプリ連携まで求める場合は、専門の会社やベンダーへの依頼を検討できます。

単純な検証環境であれば、自社で構築できる場合もあります。一方で本番では、障害対応、脆弱性の更新、監視、切り戻しまで体制を整える必要があります。

依頼するときは、設定の経験に加えて、構成設計や負荷試験、文書、保守の範囲を確かめます。

まとめ

Nginxのシステムは、利用者からアプリやDBまでの通信経路を設計する取り組みです。Nginxの役割と、周辺サービスとの担当範囲をはっきりさせます。

Webサーバーやプロキシ、ロードバランサーは、目的に応じて使い分けます。キャッシュやTLS終端は、必要に応じて組み合わせます。

成功のために押さえる3つの要点

要件定義では、通信量や可用性、RTO・RPOを数値にします。ログ保持やセキュリティ、保守時間も、数値で定めます。

OSS版や商用版、マネージドサービスは、必要な制御の範囲と運用の負担で比べます。受け入れ条件には、試験や文書も含めます。

負荷試験や障害切り替え、証明書更新、脆弱性対応、ロールバック、ドキュメントを、納品条件として確かめます。

まず整理すべき情報

最初に、現行の通信経路と、Nginxに担わせたい役割を構成図にまとめます。そのうえで、単一か冗長か、Ingress NGINXの退役を踏まえて移行するかを整理します。

条件がそろっていると、開発会社やベンダーに相談しやすくなります。費用だけでなく、性能や可用性、セキュリティ、運用性も合わせて判断します。

▼関連記事一覧
・Nginxのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Nginxのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Nginxのシステム開発の見積相場や費用/コスト/値段について
・Nginxのシステム開発の発注/外注/依頼/委託方法について

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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