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

KVMのシステム開発は、Linux上で仮想サーバーを動かす基盤を作り、業務サーバーの集約や移行に役立てる取り組みです。仮想化方式、管理基盤、運用体制を導入目的と必要な可用性に合わせて組み合わせます。構成要素から費用、発注先の選び方まで、順に見ていきます。

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

KVMのシステムの概要

実行・入出力・管理・運用の機能が組み合わさります。

KVMはKernel-based Virtual Machineの略称で、Linux上で複数の仮想マシンを動かすためのオープンソース技術です。

2006年に発表され、翌年にLinuxカーネルへ統合されました（出典: 公式KVM解説、2026年1月掲載）。

現在は、Linux上でWindowsやLinuxなどのゲストOSを分離して実行する中核技術として使われています（出典: 公式KVM解説、2026年1月掲載）。

KVMとKVMスイッチの違い

見積依頼では、KVMという語が複数の意味で使われるため、先に意味を分けて理解しておく必要があります。

KVMの別の意味：Keyboard・Video・Mouseの切替器を指す場合もあります。
KVMスイッチ：1組のキーボード・ディスプレイ・マウスで複数の物理サーバーを操作する機器です。
仮想化基盤のKVM：1台または複数台の物理サーバー上に仮想サーバーを作る技術です。

見積依頼の件名にKVMだけを書くと、機器の調達と仮想化基盤の構築が混同される可能性があります。

問い合わせや要件定義では、「Kernel-based Virtual Machineを使った仮想化基盤」と明記します。

KVMのシステムを構成する部品

実際のKVMシステムは、KVMだけでは完成しません。実行機能を支える構成要素は、仮想化、入出力、管理、本番運用の役割に分かれます。

KVMとQEMU：KVMが物理CPUやメモリを割り当て、QEMUが仮想ハードウェアを提供します。
Virtio：ディスクやネットワークの入出力を効率化するドライバーです。
libvirtなどの管理API：VMの作成、起動、停止、クローン、スナップショット、リソース変更を自動化しやすくします。
管理・運用機能：本番環境では、GUIやAPI、ストレージ、仮想スイッチを組み合わせます。監視やバックアップ、認証、操作ログも加えます。

KVM本体に高可用性の運用ルールは含まれないため、管理層と運用設計を別途決めます。

複数ホストを使う場合は、ライブマイグレーション、障害時の自動再起動、ストレージの冗長化も検討します。

導入によって得られる効果

仮想化の中心的な効果は、サーバー集約と環境分離です。このほか、既存資産の延命と環境作成の効率化もあり、全体で4つに分けられます。

サーバー集約：業務サーバーを1台または少数のホストへまとめ、設置スペース、電力、保守台数を抑えやすくします。
環境分離：開発・検証環境を本番から分けられます。
既存環境の延命：古いOSや業務アプリをVMで動かし、ハードウェア更新とアプリ改修の時期を分けられます。
環境作成：VMをテンプレート化し、同じ構成を短時間で作成できます。

障害時に別ホストで再起動したり、計画メンテナンスでVMを移したりできる場合もあります。

仮想化しただけで可用性や運用効率が自動的に上がるわけではありません。

効果を得るには、復元試験と監視に加え、容量計画と担当者の習熟が必要です。

KVMの種類と管理方式の選び方

KVMを選ぶ際は、仮想化エンジンだけでなく、ホストやストレージの管理者も決めておきます。

ネットワークとバックアップについても、誰が受け持つかを決める必要があります。

単一ホストと複数ホストのクラスタでは、必要な知識や障害時の動き、費用が異なります。

KVMとQEMU・libvirtを直接組み合わせる方式

直接管理方式は、検証環境や少数の社内サーバーで候補になります。採用する前に、適用条件と運用上の負担を確認します。

適する環境：Linux運用に慣れた担当者がいて、障害対応や更新を自社で行える場合です。
制御性：Linux、KVM、QEMU、libvirt、Cockpitなどを組み合わせ、VM定義やネットワークを細かく制御できます。
ライセンス費用：ソフトウェア費用を抑えやすい方式です。
自社で設計する機能：複数ホストの管理、権限、監査ログ、容量予測、バックアップ、自動復旧が必要です。

管理画面を自作すると、API変更や脆弱性対応、担当者の異動によって、保守費が増える可能性があります。

対象VMが数台を超える場合は、既存製品や運用サービスも比較の対象に入れます。

仮想化管理プラットフォームを使う方式

複数台のホストをまとめて管理する場合は、KVMを内蔵した統合型プラットフォームが現実的です。規模や必要な機能に応じて、製品を使い分けます。

中小規模のオンプレミス：Web画面でVM、クラスタ、ネットワーク、ストレージ、バックアップを管理します。
可用性設定：HAやライブマイグレーションを設定しやすく、運用標準化や導入期間短縮を目指せます。
大規模なIaaS：認証、テナント、API、仮想ネットワーク、分散ストレージを組み合わせます。
統合運用：コンテナ基盤とVMを一つの運用モデルへまとめる方式もあります。

機能が増えるほど、設計や教育、アップグレードの負担も大きくなります。

将来のVM数、利用部門、API自動化の必要性を先に判断します。

課金とテナント分離の必要性も見極めます。

商用サポートやマネージドサービスを使う方式

Linux、ストレージ、ネットワークをまたいで運用できる人が少ない場合は、外部支援を検討します。候補になるのは、商用サポート付きディストリビューションと、設計・監視・障害対応を含むマネージドサービスです。

支援と費用：月額費用は発生しますが、問い合わせ窓口と、障害時にどこまでを誰が受け持つかを明確にしやすくなります。
更新体制：脆弱性情報、更新方針、サポート範囲を確認します。
長期サポート例：2026年3月にKVM向け管理基盤の新版が提供開始されました。

新版には、VM移行支援、ホスト障害時の自動復旧、ネットワーク・ストレージ管理が含まれます。さらに、KVM向けOSと8年間の長期サポートも付いています。

製品発表では、構築工数を約60％削減し、99.999％の可用性を掲げる例もあります。

数値は構成や運用条件によって変わるため、契約書で対象範囲と計算方法を確かめ、サポート時間や追加費用も見ておきます（出典: 仮想化基盤サービス公式発表、2026年2月）。

ポイント

管理方式は、自社でLinuxを運用できるか、複数台をまとめて管理するかで選びます。運用の人員が少ない場合は、商用サポートやマネージドサービスも比べます。

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

代表VMの検証を経て本番移行へ進む構成です。

KVMのシステム開発は、ホストの構築から運用の引き継ぎまでを含みます。

まず現行環境を洗い出し、非機能要件を定めます。次に、代表VMによるPoCを行い、基盤を設計したうえで、移行と運用引き継ぎに進みます。

導入目的は、サーバー集約や停止時間の短縮を中心に、数値で示します。

ライセンス・保守費の見直しやデータ主権なども、数値で定めます。

要件定義とPoCで決める項目

要件定義とPoCでは、設備、復旧、性能の条件を洗い出します。ホスト台数やストレージ方式は、VM数だけでは決められません。

設備と負荷：物理・仮想サーバー数、ゲストOS、CPU・メモリ、容量・IOPS、帯域、同時利用数、ピーク負荷。
復旧と運用：RTO、RPO、バックアップ世代、ログ保存期間、復旧拠点、管理者数、サポート時間。
PoC対象：Linux・Windows VM、I/Oの多いDB、外部連携のある業務アプリなどを選びます。
合格判定：画面の表示だけでなく、数値の基準で判定して記録します。

PoCでは、応答時間や障害復旧、復元を検証します。ライセンス認証と時刻同期も、PoCの中で確認します。

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

設計・構築では、基盤構成、VMの個別設定、自動化の順に内容を決めていきます。

基本設計では、ホスト台数、CPU世代、メモリの予備、ストレージ（ローカル・共有・分散）の役割、仮想・管理ネットワーク、バックアップ先を決めます。
詳細設計では、VMのCPU・メモリ上限、ディスク形式、Virtio、VLAN、ファイアウォール、時刻同期、監視、パッチ、権限、ログ保存先を決めます。
構築では、検証環境で自動化の手順を確立してから、本番環境に反映します。

AnsibleやTerraformを使う場合は、コードと変数を納品物に含めます。また、秘密情報の扱いや、レビュー・承認の方法も対象に含めます。

VM定義やネットワーク、ストレージを手作業だけで作ると、同じ環境を再現できず、障害時の復旧も遅れます。監視設定も、手作業だけで作る場合は同じ問題が起きます。

VM移行・テスト・リリース

VM移行・テスト・リリースでは、事前準備から稼働後の確認までを一連の手順として扱います。

移行前に仮想ディスク形式、ゲストOS、Virtio、MAC・IPアドレス、ライセンス認証、バックアップ・監視エージェントを確認します。
対象VMを重要度と停止可能時間で分類し、開発・検証・低リスクの本番VMから段階的に移行します。
変換前のイメージを保持し、問題時に元環境へ戻す切り戻し手順を用意します。
テストでは機能や負荷、障害、復元を検証します。さらに、通知、権限、脆弱性、パッチ、計画停止、ライブマイグレーションも確認します。
リリース後もCPU・メモリ・ディスク・ネットワーク、VMの死活、復旧時間、バックアップ成功率を確認します。

業務アプリが動いても、DBのI/O待ちや外部接続がボトルネックになる場合があります。

ポイント

移行は、非機能要件を数値で定めたうえで、代表VMのPoCで性能と復元を確かめ、低リスクのVMから段階的に進めるのが目安です。

KVMのシステム開発費用の相場

KVM本体はオープンソースで、無償で使える範囲があります。

システム費用は、機器や設計、構築で決まります。移行とテスト、教育、保守も、費用に含まれます。

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

以下の金額は、2025〜2026年の公開価格や一般的な工数をもとにした企画用の推定です。KVMの定価ではありません。

規模別の初期費用と期間

規模別の概算は、ホスト数やVM数と合わせて、移行範囲や期間も確認します。

学習・検証：単一ホストで5万〜30万円、数日〜3週間。導入キットは5万5,000円からです。
小規模本番：物理サーバー1台、VM5〜20台で50万〜200万円、1〜2か月。
HA構成：ホスト2〜3台の場合、300万〜1,000万円、3〜6か月。
VM移行：数十〜100台程度を移す場合、1,000万〜5,000万円、6〜12か月。
複数拠点：大規模基盤は5,000万円から数億円、9〜24か月以上の場合もあります。

学習・検証の費用は、既存サーバーを使い、担当者がOSやネットワークを設定する前提の金額です。

導入キットの機器、ゲストOS、バックアップ、構築支援は別料金です（出典: 仮想化導入キット公開価格、2026年確認）。

VM移行の概算には、監視、バックアップ、災害対策、教育を含みます。

差額を大きく左右するのは、KVMのライセンスよりも、非機能要件や機器、移行対象、運用時間、テスト範囲です。

初期費用の内訳

初期費用は、工程ごとに仮の比率を置いて考えます。

要件定義・現状調査：10〜15％
設計：15〜25％
機器：30〜50％
構築・テスト：15〜25％
移行・教育・運用設計：10〜20％

実際の比率は、機器の流用や共有ストレージ、ゲストOSのライセンス、移行の難易度によって変わります。

見積書では、機器やサブスクリプション、設計を分けて書きます。

構築、移行、テスト、教育も、別の項目として示します。

費用を抑える場合でも、バックアップや監視、復元試験は残しておきます。加えて、更新や構成図、運用手順書も必要です。

初期費用だけで比べると、障害時に復旧できない状態や、担当者しか操作できない状態が生まれます。さらに、容量不足で機器を追加することにもつながります。

月額・年間保守費用

保守費は、支援時間や対象サービスによって異なります。確認の際は、機器、OSS支援、監視、障害対応、改修を分けて見ます。

小規模本番：監視、バックアップ、問い合わせ、機器保守は月3万〜15万円程度から。
HAなどを含む場合：月10万〜50万円程度になることがあります。
24時間365日対応：パッチ、復旧訓練、災害対策を含む場合は個別見積もりです。
年間保守の目安：初期費用の年10〜20％。初期費用800万円なら80万〜160万円です。

HAや外部監視、容量追加、平日夜間対応を含めると、費用が上がる場合があります。加えて、夜間オンコールやスペア機器も金額に影響します。

月額だけでなく、障害1件ごとの対応費、追加VM、ストレージ増設、移行支援の単価も確認します（出典: 業務システムの一般的な保守費目安、2026年整理）。

ポイント

費用の判断では、初期費用だけでなく、月額の保守費と障害時の対応費を合わせて比べます。見積もりの内訳に、バックアップや監視、復元試験が含まれているかも確かめます。

KVMのシステムにおける性能・可用性・セキュリティの確保

稼働継続と復旧の両面を確認できます。

性能は、VM数だけでなく、CPU・メモリ使用量、ディスク容量とIOPS、ネットワーク帯域、ピーク負荷をもとに検討します。

代表的なVMを使うPoCで、想定負荷時の応答時間を確認します。

複数の業務VMを1台へ集約すると、ホストやストレージの障害が複数の業務へ広がります。

集約率を上げるほど、冗長化と容量の余裕を一緒に設計する必要があります。

可用性を高める場合は、複数ホスト、共有または分散ストレージ、障害時の自動再起動、ライブマイグレーション、監視、バックアップを組み合わせます。

目標RTOを満たすかは、実際の障害試験で確かめます。

管理者権限と認証、操作ログを設計します。さらに、更新手順や脆弱性対応、バックアップの保管先も決めます。KVM本体とは別に、管理層と運用ルールを用意します。

KVMの採用を判断する際は、VMが起動するかだけでなく、ピーク時の性能、ホスト障害時の復旧、管理プレーンの防御、バックアップの復元も確認します。

CPU・メモリ・ストレージの性能設計

性能設計では、割当量と負荷をCPU、メモリ、ストレージごとに確認します。

CPU：割り当てすぎると待ちが増えるため、物理コア、ピーク負荷、VMの優先度を見ます。
メモリ：通常使用量に加え、バックアップ、ウイルススキャン、更新、障害時の余力を見ます。
ストレージ：容量、IOPS、レイテンシ、スナップショット、バックアップ転送量を測ります。
負荷試験：CPU、メモリ、ディスク待ち、帯域を記録し、増設のしきい値を決めます。

CPU使用率が低くても、メモリやストレージが先に限界へ達する場合があります。また、DB、ファイル、ログ、バックアップを同じボリュームに置くと、夜間処理で応答が遅くなることがあります。

HA・バックアップ・災害対策

HAとバックアップは、目標復旧時間や許容データ損失に合わせて設計します。

ホスト冗長化：2台以上、共有・分散ストレージ、冗長網、フェンシング、障害検知、VM再起動を設計。
計画保守：ライブマイグレーションが有効です。ただし、ストレージなどが単一障害点なら、基盤全体が止まります。
バックアップ：アプリ整合性、世代、期間、別媒体・拠点保管、ランサムウェア対策、復元を含めます。
復元試験：RPOが1時間なら、復元試験は1日1回では不足です。月次または四半期ごとに復元し、RTOを確認します。

管理プレーンと仮想ネットワークの防御

管理プレーンとVM間の通信では、アクセス制御や更新、通信経路、仮想化基盤の安全性を確認します。

管理アクセス：管理画面やAPIを業務網・インターネットへ直接公開せず、専用網や踏み台を使います。
権限管理：許可IP、MFA、RBAC、最小権限、操作ログを設定します。
脆弱性対応：ホストOS、管理ツール、ゲストOS、バックアップソフトを確認し、緊急パッチと計画更新を分けます。
仮想ネットワーク：VM間の通信にも対策が要るため、VLAN、仮想スイッチ、ファイアウォール、通信ログを設計します。

ハイパーバイザーの分離やアクセス制御、ライフサイクル管理、仮想ネットワーク、監視も確認の対象です（出典: NIST SP 800-125A Rev.1、2018年）。

KVMのシステム開発会社・ベンダー・サービスの選び方

KVMの発注先は、本番基盤の実績や移行対応を確認して選びます。あわせて、RFPの比較項目もそろえておきます。

実績と移行対応の確認

発注先の経験は、本番基盤の規模や運用条件、既存VMの移行対応で確かめます。

本番実績：同程度のVM数、OS、ストレージ、RPO・RTO、運用時間の経験を確認します。
移行支援：事前診断、ドライバー、停止時間、同期、ライセンス、切り戻しを聞きます。
提案内容：構成図、分担、テスト、納品物、教育、障害時の窓口を確認します。
引き継ぎ：VM定義、自動化コード、監視・バックアップ設定の範囲と再利用形式を決めます。

RFPには、物理・仮想サーバーの一覧、ゲストOS、CPU・メモリ・容量を記載します。そのうえで、負荷や停止・復旧、運用に関する条件も整理します。

負荷：ピーク時の負荷
停止と復旧：停止可能時間、RPO・RTO、バックアップ世代
運用：監視、移行対象

希望稼働日と予算上限もそろえて伝えます。単一ホスト、HAクラスタ、災害対策の3案を依頼し、費用や保守範囲を比べます。

サポート範囲と障害時の担当の確認

サポートでは、問い合わせ時間や重大障害の受付方法、初動時間、復旧目標を確認します。さらに、代替機器、脆弱性通知、更新検証、現地対応の有無も確かめます。なお、OSSであっても、すべての構成が無償で支援されるとは限りません。

サブスクリプション、機器保守、監視、運用代行は分けて、必要な範囲を契約します。基盤、OS、ミドルウェア、業務アプリ、ネットワーク、バックアップのどこまでを誰が調べるかを、SLAや運用設計書に記します。

見積もりの比べ方

複数社へ同じRFPを渡し、初期作業と運用作業の費用を分けて比べます。

初期作業：要件定義と設計、機器やライセンス、構築、移行、テスト、教育を含みます。
運用作業：月額の監視や障害対応、バックアップ、OSサポート、夜間対応、移行後の調整が対象です。

冗長化や復旧訓練は、業務停止のリスクを下げる可能性があります。

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

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

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

ポイント

発注先は、本番基盤の実績と移行対応、障害時の担当範囲で比べます。見積もりは、同じRFPを渡したうえで、初期作業と運用作業の費用を分けて見ます。

KVMのシステム導入で失敗しやすい点と対策

設計を省くと、障害時に復旧できない基盤になるおそれがあります。また、管理や監視、バックアップを後回しにすること、無料だけで方式を決めること、既存VMの移行難易度を調べないことが、失敗につながります。

「無料だから安い」という誤解

KVMのソフトウェアが無償でも、周辺機器や構築・運用の費用はかかります。そのため、見積もりでは、基盤の費用と社内の工数、停止時の影響を分けて見ます。

基盤費：サーバーやSSD、ネットワーク、バックアップ、監視が対象です。設計や移行、教育、保守も含みます。
社内工数：作業時間と障害対応の人件費も含めます。
停止影響：単一ホストで全VMが停止する影響を金額と業務面で評価します。

総保有コストは、3年または5年で比較します。段階導入は、PoC、小規模本番、HAクラスタ、大規模移行の4段階で行います。

PoC：性能と互換性の確認。
小規模本番：運用性の確認。
HAクラスタ：復旧時間の確認。
大規模移行：移行工数と切り戻しの確認。

段階ごとに判断会議を設けると、採用後に想定外の構築費が膨らむリスクを抑えられます。

担当者の知識への依存

Linux、仮想化、ストレージ、ネットワーク、バックアップを扱える担当者が1人だけだと、休暇や異動で運用が止まるおそれがあります。そのため、知識と手順を共有できる体制を作ります。

運用情報の文書化：構成図、VM一覧、変更手順、障害対応、復元手順、連絡先を記録します。
手順の訓練：別の担当者が訓練環境で手順を実行できる状態にします。
外部支援の活用：自社運用が難しければ、管理プラットフォームやマネージドサービスを選びます。
委託範囲の契約：窓口と役割分担を契約し、委託先に任せる範囲と社内に残す判断を分けます。

外部へ委託しても、業務の優先順位、RPO・RTO、停止判断、データ保管場所は自社で決めます。

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

KVMのシステムは、管理方式や移行対象、可用性、保守体制を踏まえて判断します。導入前によく聞かれる質問を、次に挙げます。

KVMのシステムは無料で導入できますか？

KVM本体はオープンソースで、ソフトウェア費用を抑えられる場合があります。ただし、サーバーやストレージ、バックアップ、設計、移行の費用がかかります。さらに、監視やサポート、ゲストOSのライセンスにも費用が必要です。

無料かどうかよりも、必要な可用性と運用体制を含めた総額で比べます。

KVMでWindowsの仮想マシンも動かせますか？

KVMではWindowsを含む複数のゲストOSを動かせます。ゲストOSのバージョンやVirtioドライバー、GPUや特殊デバイス、業務アプリの動作保証も確認します。

OSライセンスとバックアップエージェントについても調べます。そのうえで、代表的なWindows VMをPoCに含め、性能と移行後のライセンス認証を検証します。

既存の仮想マシンをKVMへ移行できますか？

移行できる可能性はありますが、すべてのVMを無条件に移せるとは限りません。

まず、ディスク形式、ゲストOS、ドライバー、アプリのライセンスを調べます。さらに、CPU命令セット、ネットワーク、バックアップ、停止可能時間も調査します。

低リスクのVMで変換と復元を試し、段階移行と切り戻しを確認してから重要なVMへ広げます。

KVMだけで高可用性を実現できますか？

KVMは仮想マシンを動かす中核技術です。ただし、複数ホストの自動復旧やストレージ冗長化までは、KVM単体では担えません。

そのため、管理プラットフォームやクラスタ管理、共有または分散ストレージ、監視、バックアップを組み合わせます。目標RTOを満たすかは、ホスト障害と復元の試験で確かめます。

KVMのシステム開発完全ガイドまとめ

KVMのシステムは、Linux上の仮想化基盤です。KVM、QEMU、Virtio、libvirtを中心に構成されます。

管理基盤、ストレージ、ネットワーク、監視、バックアップも組み合わせます。そのうえで、導入目的を数値で示して構成を選びます。

代表VMのPoCからの開始

全社のVMを一度に移す前に、代表VMで性能、互換性、バックアップ復元、障害復旧、運用手順を検証します。その結果、直接管理、統合型プラットフォーム、商用サポートやマネージドサービスから方式を選びます。

見積もり前の非機能要件の整理

KVM基盤の見積もりでは、構成と運用の条件をそろえて費用を比較します。

構成条件：VM数、CPU・メモリ、ストレージ、ネットワーク、ゲストOS、ピーク負荷を整理します。
運用条件：RPO・RTO、バックアップ、監視、移行対象、サポート時間、希望稼働日を確認します。
費用比較：初期費用、月額・年間保守、移行・復旧の工数を比べ、自社に合う構成を選びます。

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