Proxmoxのシステム開発の完全ガイド - ブログ

Proxmoxのシステムは、PVEとPBS、構成方式、移行・保守を一体で設計すると、業務に合う可用性と費用のバランスを取りやすい基盤です。

基盤の全体像から、構成の種類、導入の進め方、費用、事業者の選び方、運用まで順に扱います。各テーマの詳細は、関連記事もあわせてご覧ください。

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

Proxmoxのシステムの概要

基盤の各要素がPVEを中心につながります。

Proxmoxのシステムは、PVEを中核にPBS、物理サーバー、ストレージ、ネットワーク、監視、運用手順を組み合わせた業務インフラです。PVEは仮想マシンとコンテナを動かす製品で、業務アプリを自動的に作るものではありません。そのため、基盤の設計・構築と業務アプリの開発・改修は、要件に応じて分けて考えます。

PVEが担う役割

PVEは、仮想マシンやコンテナを動かし、物理サーバーやノードを管理する基盤です。

仮想マシン：KVMを使い、WindowsやLinuxを動かせます。
コンテナ：LXCがホストのLinuxカーネルを共有し、Linuxアプリを軽量に分離する仕組みです。
操作の自動化：Web GUI、CLI、REST APIを使い、VMの作成や設定、バックアップ、監視連携を行えます。
可用性・保護：クラスタ、ライブマイグレーション、HA、ファイアウォールを備えます。
認証連携：LDAP、Active Directory、OpenID Connect、二要素認証との連携に対応します。

機能が揃っていても、要件に合う設計になるとは限りません。特にHAやCephは、障害時の挙動まで検証してから業務に使う必要があります。

PBSが担う役割

PBSは、PVE上の仮想マシンやコンテナをバックアップし、復元するための専用サーバーです。

転送・保存：増分転送、重複排除、Zstandard圧縮の機能を利用できます。
保護：整合性検証、クライアント側のAES-256-GCM暗号化、アクセス権の管理に対応します。
拠点間同期：バックアップを別拠点へ同期できます。

公式機能情報では、SHA-256チェックサムによる検証と遠隔地への同期が説明されています（出典：Proxmox Backup Server公式機能情報、2026年8月確認）。

HAは、稼働中の仮想マシンを別ノードで再起動・引き継ぎする仕組みです。一方、バックアップは、データを別の保存先に保全して復元するための備えです。

HAを構成しても、誤削除やランサムウェア、データ破損は防ぎきれません。サイト全体が被災した場合にも、別拠点バックアップと復元訓練が欠かせません。HAとバックアップの役割の違いを先に整理しておくと、設計で必要な備えを判断しやすくなります。

Proxmoxのシステムを構成する主な種類と特徴

構成は、ノード数、ストレージ方式、可用性、バックアップ先の組み合わせで決まります。

機能の多さだけで選ぶと、業務に合わないことがあります。そこで、停止許容時間、データ量、将来の拡張、運用担当者のスキルを基準にします。代表的な三段階の構成を比べると、必要な投資と障害時の対応の違いが見えてきます。

単一ノード＋ローカルストレージ

対象システムが少なく、障害時に数時間以内の手動復旧を許容できるなら、1台のノードにローカルSSDやZFSを組み合わせます。

導入候補：開発・テスト、小規模な社内業務、段階移行のPoCに適する場合があります。
障害への備え：別サーバーまたは別拠点のPBSを置き、交換部品、復旧用インストールメディア、設定バックアップも揃えます。
ZFSの確認：メモリとディスク構成、RAIDコントローラー、SSDの耐久性を見ます。

単一ノードは物理障害に弱いため、クラスタ機能を増やすより、バックアップと復元を確実に設計するほうが運用しやすいケースがあります。

ZFSやCephには追加のメモリが必要です。公式要件では、その目安を使用ストレージ1TBあたり約1GBとしています（出典：Proxmox VE公式システム要件、2026年8月確認）。

2〜3ノード以上のHAクラスタ

ホスト障害時の停止を短くしたい場合は、複数ノードのクラスタにHAを組み合わせます。

HAで仮想マシンを別ノードへ移すには、共有ストレージか、レプリケーション可能なストレージが必要です。あわせて、管理、クラスタ通信、ストレージ通信用のネットワークを分けておきます。

2ノード：小さく始められる一方、投票や保守時には第三の投票要素や運用ルールが必要になる場合があります。
3ノード以上：基本形として検討しやすい反面、ノードとストレージ、スイッチと電源の費用が増えます。

可用性は、ノード数に加えて、クォーラム、フェンシング、電源、ネットワーク経路を含めた全体の設計で決まります。そのため、これらを確認して単一障害点を洗い出します。

まず、「何分以内に復旧させたいか」を示すRTOを先に定め、その目標を満たす構成を選びます。

Ceph・HCI＋別拠点バックアップ

Ceph・HCIと別拠点バックアップは、容量拡張と災害復旧の要件に応じて検討します。

Ceph・HCI：ノード追加による容量拡張や、共有ストレージ装置の削減を検討できます。
分散ストレージ：障害時の再構成や容量拡張に備え、ネットワークとレプリカ数を設計します。
別拠点保全：PBSを同期し、バックアップ鍵を本番環境から切り離して管理します。

Cephは複数ノードにデータを分散して保存する仕組みです。そのため、10GbE以上のネットワークやディスクの種類を設計する必要があります。復旧時の性能と監視項目も適切に設計しなければ、かえって複雑になります。

本番データを同一拠点だけに置くと、火災や停電、ネットワーク障害などで一度に利用できなくなる可能性があります。ランサムウェアでも、同じ事態が起こりえます。

高可用性、災害復旧、バックアップは、目的が異なります。そこで、RPOとRTOを設計書にまとめます。保管世代と復元順序も書いておくと、判断しやすくなります。

ポイント

構成は、停止許容時間やデータ量、将来の拡張、運用スキルで選びます。手動での復旧で足りるか、HAで引き継ぐ必要があるかを先に決めると、候補を絞りやすくなります。

Proxmoxのシステム開発・導入の進め方

検証を挟んで段階的に本番環境へ移行します。

Proxmoxのシステム開発は、PVEを導入して運用を始めるまでに、いくつもの工程を経ます。まず現行環境を棚卸しし、要件定義と構成設計に進みます。そのうえで検証と移行を行い、最後に運用の引き継ぎをします。

既存基盤から移行する場合は、認証やDNSなど周辺の仕組みも確認します。監視、バックアップ、ライセンスの扱いも、移行前に整理しておきます。業務同士の依存関係も見落とすと、移行後に影響が出るおそれがあります。

現状調査と要件定義

現状調査では、性能と周辺サービスを把握します。台数と容量だけで見積もると、移行後に性能不足や通信不通が起きるおそれがあるためです。

現行資源：物理・仮想サーバーのOS、CPU、メモリ、ディスク、性能を棚卸しします。
依存関係：停止時に影響する周辺サービスを洗い出します。
業務基準：停止許容時間、RTO、RPO、繁忙期、保守可能日を関係者と合意します。
情報・委託要件：情報にアクセスする担当者、ログの保存、委託先の責任範囲を決めます。

性能の把握では、ピーク時のCPU使用率、IOPS、ネットワーク帯域も押さえます。

周辺サービスでは、AD、DNS、DHCP、ファイルサーバーを含めて確認します。データベース、バックアップ、外部APIも対象です。

個人情報や機密情報を扱う場合は、要件の段階で条件を具体的に書き出しておきます。

手動復旧でよい業務と、自動で引き継ぐ必要がある業務を分けておくと、過剰なHAやCephを避けやすくなります。

基本設計・詳細設計と構築

設計では、性能や可用性の目標を先に定めたうえで、各要素の仕様を決めます。その際は、冗長化、ネットワーク、認証、引き継ぎに必要な情報も、性能目標と合わせて決めておきます。

サーバー・ストレージ：ノードの構成、CPU、メモリ、ディスク容量、冗長化方式を決めます。
ネットワーク：管理、クラスタ、ストレージ、VMの通信を分け、接続条件を確定します。
認証・権限：個人アカウント、最小権限、二要素認証、APIトークンの期限を設定します。
納品・運用資料：構成図、IP表、設定一覧、変更履歴を引き継ぎます。

PVEの公式要件は、仮想化に対応したx86-64 CPUや、ゲスト用とは別のPVE用メモリ、高速で冗長なストレージを推奨しています。また、仕様書では「十分な性能」とだけ書かず、平常時と障害時の目標値を数値で示します。

構築時には、VLANとMTUを含むネットワーク設定を確定させます。ボンディングやファイアウォールのルールも、構築の段階で決めておきます。設定資料が残っていれば、担当者が交代しても運用を続けられます。

検証・段階移行・切り戻し

本番移行の前にPoCを行い、動作と復元手順を確かめます。

検証環境で起動やアプリ接続、ディスク性能、認証連携、監視通知を見ます。
バックアップを取得し、ファイル単位で復元して、実際に起動できるかを試します。
ノード障害とネットワーク断も検証し、復元用の鍵や設定ファイルの保管場所を記録します。
低リスクの環境、非中核業務、中核業務の順に移行します。
当日は、事前バックアップ、開始条件、停止時刻を時系列で決め、動作確認と利用部門の承認、切り戻しの条件まで含めます。

海外の公式導入事例には、30台の仮想マシンを1か月未満で移行し、サービス停止なしで完了した例があります。

ただし、これは対象環境と準備が整った個別の事例です。自社の移行期間は、VM数だけでなく、依存関係とリハーサルの回数をもとに考えます（出典：Proxmox公式導入事例、2025年5月公開）。

移行後は、バックアップからの復元や監視通知、権限、性能を確認します。そのうえで、運用担当者へ手順書と構成情報を引き継ぎます。

ポイント

業務ごとに復旧の要件を分け、検証と段階移行を組み立てることが、導入の判断材料になります。切り戻しの条件を移行前に決めておけば、当日の判断で迷いにくくなります。

Proxmoxのシステム開発にかかる費用相場

移行条件が複雑なケースほど、見積もり幅も広がります。

Proxmoxのシステム費用は、サブスクリプション料金のほかに、機器や作業の費用も含めて考えます。機器面では、物理サーバーやSSD、メモリ、ネットワーク、UPS、バックアップが対象です。作業面では、構築、既存環境からの移行、監視、教育、保守を合算します。

次の金額は、公開価格と一般的なインフラ工数をもとにした概算です。機器の仕様、為替、データ量、停止制約によって、実際の金額は変わります。

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

公式サブスクリプションの料金

PVEはAGPLv3で利用できます。サブスクリプションを契約すると、Enterprise Repository、安定した更新、サポートなどを利用できます。

PVEの料金は、物理CPUソケット1個あたりの年額です。Communityは120ユーロ、Basicは370ユーロ、Standardは550ユーロ、Premiumは1,100ユーロです。

Community：PBSはサーバー1台あたり年560ユーロです。
Basic：PBSはサーバー1台あたり年1,120ユーロです。
Standard：PBSはサーバー1台あたり年2,240ユーロです。
Premium：PBSはサーバー1台あたり年4,480ユーロです。

PBSのバックアップ容量とクライアント数は無制限とされています（出典：Proxmox公式料金表、2026年8月確認）。

仮に1ユーロ＝170円で換算すると、PVEは1ソケット・年あたり約2.0万円から18.7万円、PBSは1サーバー・年あたり約9.5万円から76.2万円になります。

2ソケットのサーバー3台の場合、最安プランで年約12.2万円、最上位プランで年約112.2万円です。各ノードのソケット数で計算し、クラスタ内のサブスクリプションレベルをそろえて見積もります。

ここでの換算には為替や税金が含まれておらず、発注時の価格とは異なります。

構築・移行・保守の費用目安

構成規模や移行条件によって、費用と期間の目安は次のように変わります。

小規模PoC・単一ノード：SSD、ネットワーク、初期設定、監視、バックアップを含めて30万〜150万円、期間は1〜2か月です。
中小企業の本番環境：2〜3ノードHA、VM10〜30台、PBS、移行支援を含め300万〜1,000万円、2〜4か月程度です。
Ceph・DR・大規模移行：冗長ネットワーク、別拠点DR、24時間監視を含め1,000万〜3,000万円、4〜9か月に広がります。
複雑な移行条件：多数のVM、複雑な依存関係、厳しい停止制約、複数拠点の試験があれば、1,000万〜5,000万円超、6〜12か月の場合があります。

これらは概算の幅です。比較の出発点となる一般的な工数配分は、要件定義10〜15%、設計25〜35%、構築・テスト45〜60%、移行・導入5〜10%です。

見積もりで分けるべきコスト

初期費用と継続費用を分けて見積もると、導入後の負担も比べられます。

初期費用：現状調査から設計までの作業と、機器、サブスクリプション、構築、移行を分けます。
継続費用：更新、監視、パッチ、障害対応に加え、復元訓練、機器保守、容量追加の有無を確認します。

初期費用が安くても、復旧手順や運用監視が含まれないと、導入後の負担が増える可能性があります。見積もりを比べるときは、RPO・RTOとバックアップ世代をそろえます。そのうえで、復元試験や24時間対応、現地対応、応答時間も比べます。

「保守」とだけ書かれた項目は、対応範囲が見えにくくなります。原因の切り分けや設定変更、OS更新、アプリ対応、部品交換のどこまでを含むかを確認します。

責任分界表を添付し、対象外の作業単価も把握しておくと、追加費用を抑えやすくなります。

ポイント

費用は、初期費用と継続費用に分けて比べます。継続費用には保守や復元訓練が含まれるため、初期費用の安さだけで判断しないことが目安になります。

Proxmoxの開発会社・サービスの選び方

「Proxmoxの開発会社」を探すときは、業務アプリを作るスクラッチ開発会社と、仮想化基盤の設計・構築・移行・運用を担う会社を分けて考えます。

確認したいのは、PVEを操作できるかだけでなく、ストレージやネットワーク、PBS、監視まで設計できるかです。業務アプリとの責任分界を示せるかも、あわせて見ます。

基盤の載せ替えが目的か、アプリ改修を含むシステム開発が目的かを整理してから、候補を比べます。

公式認定と移行実績の確認

候補先には、公式パートナーや認定、対応製品、PVE・PBSの設計経験、既存基盤からの移行実績があるかを確認します。実績は台数だけでなく、停止時間や移行方法、性能試験、切り戻し、移行後の保守まで聞きます。

事例を公開できない場合は、匿名化した構成、課題、成果、運用体制を説明できるかを見ます。ストレージ面では、PBSを含めてZFSやCeph、NFS、iSCSIに対応できるかも確かめます。ネットワークや監視、認証まで設計できるかも、あわせて確認します。

大規模な構成では、複数名でのレビューや障害時のエスカレーション、設計書の品質を見ておく必要があります。障害を想定した質問への回答が具体的かどうかも比べます。

保守・サポート体制の評価

本番環境では、導入時の構築力だけでなく、障害後の対応体制を見る必要があります。

窓口：日本語対応、受付時間、初動目標、重大障害時の連絡方法を確認します。
現地対応：リモート・オンサイトの範囲、代替機、パッチ適用の責任者を定めます。
納品物：構成図、ネットワーク図、バックアップ設計、復旧手順、障害対応フローなどを確認します。
運用資料：設定、アカウント、鍵、監視、パッチ、教育に関する記録を確認します。
自動化：スクリプトやAPI連携のソースコードの所有権、リポジトリ、更新・テスト方法を合意します。

サブスクリプションの窓口と導入会社の保守窓口が異なる場合は、連絡先を手順書に記します。

将来の内製化や担当者交代に備えて、属人化しない納品範囲を選びます。

同じ条件で比較できるRFPの用意

候補先へ同じ条件を渡せるよう、現行構成と業務上の制約をRFPに整理します。

基盤情報：ノード数、VM数、OS、容量をまとめます。ピークCPU、メモリ、IOPS、ネットワーク帯域も添えます。
業務条件：拠点数、個人情報の有無、RPO、RTO、停止可能時間を示します。
関連資料：構成図、バックアップ世代、監視アラート、移行対象と対象外を添えます。
比較項目：初期費用と年間費用、機器、サブスクリプションを比べ、移行や教育、保守、追加作業の単価も含めます。

情報が不足する場合は、調査を独立した作業として見積もります。推測だけで本番構成を決めないためです。

ノード1台の停止やPBSからの復元、管理ネットワークの断、拠点全体の停止に対して、どれだけの時間で、どう対応するかも質問します。回答は、復旧の再現性やドキュメント、責任分界、運用負荷を含めて、総保有コストとして評価します。

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

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

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

ポイント

開発会社は、業務アプリの開発と基盤の設計・構築・運用のどちらを担うかで区別します。同じ条件のRFPで比べ、障害時の対応まで見ると選びやすくなります。

Proxmox導入後に必要なセキュリティと運用

基盤の管理権限を奪われると、複数のシステムとバックアップに同時に影響が及ぶ恐れがあります。そのため、導入後もアクセス制御や認証、ネットワーク分離、ログ監視を続けます。脆弱性の確認やパッチ適用、バックアップ保護、復元訓練も欠かせません。

管理者権限・MFA・ログの管理

管理者アカウントは個人単位で発行し、共有IDは使わないようにします。また、日常作業用と緊急作業用で権限も分けます。

権限：VM、ストレージ、ユーザー、バックアップの削除は、必要な担当者だけに許可します。
認証：LDAPやOpenID Connectの緊急用アカウント、退職者の無効化、APIトークンの期限を管理します。
ネットワーク：二要素認証を適用し、管理網を業務網やインターネットから分離します。
監査ログ：ログイン、権限や設定の変更、VMやバックアップの削除を監視し、時刻を同期します。

個人情報保護委員会のガイドラインは、アクセス制御、識別・認証、不正アクセス防止などの技術的安全管理措置を求めています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。

バックアップとランサムウェア対策の切り分け

PBSの運用では、取得から復元までの手順を決めておきます。あわせて、バックアップを削除されにくくするための権限や接続方法も決めます。

保管設定：取得スケジュール、保管世代、整合性検証、ガベージコレクション、別拠点同期を決めます。
権限・接続：PVEとPBSの管理者を分け、本番と異なる認証やネットワークも検討します。
暗号鍵：鍵を失うと復元できないため、紙やオフライン媒体を含む複数の方法で保管します。

月次または四半期ごとに、バックアップをテスト環境へ復元します。OS、データベース、業務アプリの順に起動を確かめ、復元時間や担当者、設定変更、DNS切り替え、利用部門の確認まで記録します。

IPAの実践資料は、経営層がリスクや対応体制、復旧を継続して管理する考え方を示しています（出典：IPA「サイバーセキュリティ経営ガイドライン Ver 3.0実践のためのプラクティス集」、2025年12月更新）。

パッチ・性能・容量の定期点検

稼働環境の変化を捉えるため、導入後の点検時期も運用計画に含めます。

更新管理：検証環境、保守時間、HA状態、バックアップ、切り戻し方法を確認します。
月次点検：CPU、メモリ、ストレージ、IOPS、遅延、バックアップ、失敗ジョブ、SMART情報を見ます。
四半期点検：復旧、権限、ログ、ネットワーク、連絡網を見直し、社内の判断者を定めます。

PVE 9.2は2026年5月に公開され、Dynamic Load Balancerなどが追加されました。また、WireGuardやBGPを含むSDN拡張、カスタムCPUモデル管理、HAマネージャーの一時停止・再開にも対応しました。

新機能は、自社の手順や監視、バックアップ、サポート範囲と合うかを検証してから採用します（出典：Proxmox VE 9.2公式リリース、2026年5月21日）。

構築を外部に委託した場合でも、社内に判断者を置きます。承認者、実行者、結果の確認者は、それぞれ明確にしておきます。

ポイント

管理者権限と認証、バックアップの保護、復元訓練はまとめて考えます。どれか一つでも欠けると障害時に復旧できないおそれがあるため、定期点検に組み込みます。

Proxmoxのシステムに関するよくある質問

導入時によく課題になるのは、価格、既存OSとの互換性、クラスタ規模、バックアップの考え方です。

Proxmoxは無料で業務利用できますか？

PVEとPBSはオープンソースソフトウェアとして利用できます。

本番では、安定版リポジトリや更新、技術サポートを、契約または自社対応で確保します。無償で利用できても、機器や構築、監視、保守、復旧訓練の費用はかかります。

Windowsや既存の業務システムを移行できますか？

多くの場合は移行の候補になります。PVEのKVM仮想マシンでは、WindowsやLinuxを動かせるからです。

OSドライバーやCPU命令、ディスク形式は、個別に検証します。ライセンスやデータベース、バックアップエージェント、時刻同期も、検証の対象です。

古いOSや特定のハードウェアに依存するアプリは、PoCで性能と周辺連携を確かめたうえで、切り戻しを含めて段階的に移行します。

Proxmoxのクラスタは何台から構成すべきですか？

検証や小規模な運用であれば、単一ノードでも構成できます。一方で、本番のHAクラスタは一般に3ノード以上を基本候補として検討します。

2ノードで始める場合は、クォーラムや保守時の判断を補う仕組みと手順を用意する必要があります。

台数は、障害時の必要容量や保守中の余力、将来の拡張、ネットワークと電源の冗長性を含めて決めます。

開発会社やサービス事業者には何を相談すべきですか？

ノード数やVM数を伝えたうえで、PVEとPBSの設計、既存環境の移行、RPO・RTO、復元試験について相談します。

保守時間や納品物、責任分界も確認します。問い合わせの前に、現行構成や停止可能時間、個人情報の有無を整理しておきます。

アプリ改修が必要な場合は、基盤側とアプリ側の作業範囲を分けて見積もります。

まとめ：要件と運用から逆算するProxmoxのシステム選び

Proxmoxのシステムは、PVEで仮想マシンやコンテナを動かし、PBSでバックアップを保全する基盤です。

単一ノード、HAクラスタ、Ceph・HCI、別拠点バックアップは、RPO・RTO、停止許容時間、データ量、運用スキルをもとに選びます。費用は、この条件を満たした構成同士を比べる材料になります。

導入前に決めること

まず、対象業務と現状のVMや物理サーバー、必要性能を整理します。そのうえで、RPO・RTOと停止可能時間、バックアップ世代は先に数値で決めておきます。残りは、導入後も見据えて範囲を決める項目です。

セキュリティ
将来拡張
社内の運用範囲

サブスクリプションや機器、構築、移行、監視、保守は、分けて予算化します。その際は、同じ条件で複数の候補から提案を受けます。

技術が新しいかどうかだけでなく、障害時に復旧できるか、担当者が手順を実行できるかで判断します。

失敗しないための最初の一歩

最初の一歩では、基盤の検証と移行後の運用判断をつなげて準備します。

本番全体を一度に移す前に、現状調査と小さなPoCで、性能やバックアップ、復元、障害時の挙動を確かめます。
結果をもとに、本番構成、移行計画、切り戻し条件、運用保守の責任分界を決めます。

柔軟な基盤を業務の安定稼働につなげるには、設計書と訓練を続けることが欠かせません。

▼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を創業。