セキュリティ運用支援システム開発の完全ガイド

セキュリティ運用支援システムは、監視体制、ログ分析・自動化、対応責任の設計を組み合わせ、検知から復旧・報告まで続ける仕組みです。

発注前に全体像と機能の違いを押さえておくと、導入の進め方や費用、法務・監査の確認事項を社内で具体的に話し合えます。

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

セキュリティ運用支援システムの全体像

判断と記録まで含めて運用のつながりを捉えられます。

セキュリティ運用支援システムは、システムとサービスを含む総称で、特定の製品名を指すものではありません。

ファイアウォールやクラウド、端末などの情報を集めます。さらに、認証基盤、メール、SaaSなども対象とし、危険度を分析して対応を実行・記録します。

ツールだけでなく、監視担当者や対応手順、連絡網も対象に含みます。また、レポートや改善会議も含まれます。製品を導入するだけでなく、誰がアラートを判断し、どの手順で対応するかまで設計して、実効性を高めます。

製品導入だけでなく運用設計まで含む仕組み

一般的なセキュリティ製品は、危険な通信や不審な挙動を検知する機能を提供します。一方で、実効性を確保するには、検知後の判断、対応、責任者を運用手順に定めておく必要があります。

検知後の設計：製品が出したアラートの判断と対応の進め方
一次対応：誤検知か攻撃かの判断、端末の隔離、業務影響の確認と、必要に応じた社外報告
運用の流れ：一次判定、重大度分類、エスカレーション、証跡保存、再発防止
責任分界：CSIRT、情シス、ネットワーク担当、法務、広報、経営層の役割をRACI表などで明文化
対応体制：アラート未確認や夜間の対応者不在、監視会社から連絡があっても封じ込め権限がない状態では、被害を抑えられない

ログ源から対応・報告までの循環による基本構成

基本の流れは、ログ源から収集エージェントやAPIを通じてログ基盤に集め、相関分析と脅威インテリジェンスで分析する形です。分析結果は、監視担当者または自動対応が受け取り、チケット・通知・レポートへつながります。

主なログ源：EDR・XDR、WAF、IDS・IPS、認証基盤、クラウド監査ログ
運用対象：サーバー、ネットワーク、メール、SaaS、脆弱性管理ツール

すべてのログを最初から集めると、費用や運用の負担が増えます。そのため、重要資産、守るデータ、想定攻撃、必要な保存期間を定め、優先度の高いログから連携します。

ログの時刻や識別子をそろえて正規化しておくと、単一製品では見えにくい権限濫用や横展開の兆候を追いやすくなります。

ポイント

全体像は、製品の機能だけでなく、監視から対応・報告までを一続きで設計できているかで判断します。製品名より、誰がどの段階を担うかを見るのが目安です。

主要な種類と機能の違い

名称が似ていても、担う役割の層が異なります。

製品やサービスを比べるときは、監視体制と、分析・自動化の機能を分けて見ると、違いが分かりやすくなります。

SOCやMSSは人による監視・運用の枠組みで、SIEMやSOARはログ分析や対応自動化の技術基盤です。

EDRや脆弱性管理は、監視対象やリスクを具体化する役割を持ちます。呼び名だけでなく、発注側が担当範囲と対応条件も合わせて確認します。

SOC・MSS・MDRによる人の監視と対応支援

SOCはセキュリティログやアラートを監視・分析する専門組織です。また、MSSは監視や運用を外部が提供するサービスで、MDRは主に端末やクラウドの検知・調査・対応を専門家が支援します。

サービスの範囲は、営業時間や通知方法、一次対応の内容に分けて確かめます。端末隔離や原因究明、復旧支援まで含むかも、あわせて確認します。ただし、24時間365日監視でも、重大インシデントの復旧まで代行するとは限りません。

通知のみ：深夜のアラートを電話で知らせる範囲
操作を伴う対応：承認後にアカウントを停止する範囲
社外連絡：顧客・警察・専門機関への連絡担当

重大度別の目標通知時間と休日の連絡先は、契約書や運用設計書に明記しておきます。

SIEM・SOARによる分析と自動化の基盤

SIEMは複数のログを集め、異なる製品のイベントを相関分析します。たとえば、通常と異なる場所からの認証や特権アカウントの変更を調べます。不審な実行や大量通信も、時間の流れに沿って追います。

SIEMの設計では、保管期間や検索速度に加え、ログ量による従量課金やデータの保存場所も重要な項目です。一方、SOARは、アラートからチケット作成、通知、端末隔離やIP遮断までのプレイブックを管理・実行します。

誤検知で重要な端末を隔離すると、業務停止につながります。そのため、まず承認付きで自動化を行い、実績を確認してから完全自動化へ進めます。

EDR・資産管理・脆弱性管理による守る対象の具体化

EDRやXDRは、端末・サーバーのプロセス、通信、ファイル操作を監視して、侵害の兆候を調べます。資産管理は、端末やクラウド、公開サービスを把握する取り組みです。

脆弱性管理は、未適用パッチや設定不備、サポート終了製品を、リスクや期限と結び付けるものです。特に、古い資産台帳のままでは、公開サーバーの重大な脆弱性や退職者アカウントを見落とすおそれがあります。

資産情報：所有者、重要度、設置場所、利用データ
対応管理：対応期限と未対応の理由
評価指標：検知件数に加え、重要資産のカバレッジと期限内対応率

ポイント

SOCやMSSなど人の監視と、SIEMやSOARなどの分析・自動化は役割が別です。比べるときは、監視体制と分析・自動化を分け、担当範囲と対応条件を見て判断します。

セキュリティ運用支援システムが必要な理由

この仕組みが必要なのは、攻撃を検知するだけでなく、限られた人員で判断と対応を続けられる状態をつくるためです。また、複数の管理画面を見て回ると攻撃の全体像をつかみにくく、アラートが多すぎて重要な通知が埋もれてしまいます。

アラート過多と専門人材不足への対策

運用支援システムは、監視対象と対応手順を一つの業務フローに結び付けます。そのうえで、担当者はアラートを次のとおり処理します。

誤検知：該当するアラートの除外
関連イベント：関連する状況をまとめて把握
優先順位：重大度と対応期限の付与

専門家が不足する場合は、監視と一次判定を外部に委託し、社内は業務影響の判断と承認に集中する方法もあります。

2025年公開のSIEM活用支援情報では、導入課題として、ログ取得設定やアラート確認・対処が挙げられています。あわせて、誤検知や未検出へのルール調整、人材不足も課題とされています（出典：SIEM活用支援サービス公式発表、2025年）。そのため、分析ルールと担当体制は継続的な改善が必要です。

被害の拡大防止と事業継続の判断の迅速化

被害の拡大を抑えるには、端末・認証・通信・バックアップへの措置が必要です。数時間の遅れで被害範囲が広がる可能性があるため、運用側は手順と承認者を登録し、夜間や休日の迷いを減らします。

端末：侵害が疑われる端末の隔離
認証・通信：認証情報の無効化と、悪意ある通信の遮断
バックアップ：健全性の確認

個人データを扱う企業は、技術対策と被害を抑える仕組みを適切に運用することが求められます。個人情報保護委員会も、不正アクセス後のネットワーク遮断、端末上の個人データの暗号化やパスワード保護、従業者研修を挙げています（出典：個人情報保護委員会「標的型メール攻撃やその他不正アクセス等による個人データ漏えいの防止」、2025年7月更新）。

システムには、遮断操作の権限と、実行者や承認者、実行時刻を記録する機能が必要です。

セキュリティ運用支援システムの進め方

代表ログで確かめてから本番環境へ進みます。

導入は、守る対象と対応責任を決めたうえで、段階的に実装していくプロジェクトです。全社のログを最初から集めると費用と運用負荷が膨らむため、重要資産と代表的な攻撃シナリオで小さく検証します。

▶ 詳細はこちら：セキュリティ運用支援システム開発の進め方/やり方/流れや方法/手法/工程/手順

企画・要件定義での守る対象と責任分界の決定

まず、重要業務や個人情報、営業秘密、公開サービスを洗い出します。端末やクラウド、認証基盤については、許容停止時間も含めて整理します。そのうえで、検知時間、一次判定者、隔離の承認者、復旧と社外報告の担当を決めます。

RFPには、監視時間やログの種類と量、保存期間を記載します。また、通知手段や重大度別SLA、操作範囲を書き込み、再委託先やデータ所在地、ログ返却、月次レポート項目にも触れます。

MUSTとWANTを分けて、初期に必須の検知と将来の自動化を区別しておくと、見積もりを比べやすくなります。

PoCと設計による検知精度と運用負荷の確認

PoCでは、実環境の代表ログを取り込み、認証異常やマルウェア実行、権限変更などを試します。そのうえで、検知と通知の時間、誤検知率を確かめます。ログ欠損や検索性、一件の処理時間も合わせて見ます。

設計では、収集方式と正規化、相関ルール、脅威情報を決めます。チケット連携や通知先、承認フロー、権限、バックアップ、障害時の代替策も定めます。自動化は、通知とチケット作成から始め、承認付きの隔離や無効化へ進めます。

PoCと本番構築の範囲を分けて契約すると、追加費用が発生する条件も明確になります。

構築・テスト・移行で通常業務への影響を抑える工夫

ログ連携から受け入れ判定まで、通常業務への影響を抑えるための確認点を、工程ごとにまとめます。

構築対象：ログ連携、検知ルール、資産台帳、チケット、通知、レポート
障害テスト：ログ欠損、監視基盤停止、担当者不在、誤検知による隔離
実データの保護：個人情報のマスキング、アクセス権、保存期間
移行方法：重要度の高い環境から段階的に本番移行
受け入れ条件：ログ到着時間、連絡表どおりの重大アラート通知、承認操作の追跡、月次レポートの再現

導入後1か月目には誤検知を調整し、3か月目に対応時間を評価します。その後は、四半期ごとにルールと権限を見直していきます。

ポイント

導入は、守る対象と対応責任を決めてから、重要資産と代表的な攻撃シナリオで小さく検証し、段階的に広げるかどうかで判断します。全社ログを最初から集めると、費用と運用負荷が膨らみます。

費用相場とコストの内訳

費用は、ログ量や監視時間、資産数によって変わります。さらに、連携数や保存期間、一次対応範囲、SLA、個別開発の有無も影響します。

次に示す数字は、2025〜2026年時点の公開料金と、一般的な業務システムの工数をもとにした予算の目安です。全国平均や特定サービスの見積額ではありません。

▶ 詳細はこちら：セキュリティ運用支援システム開発の見積相場や費用/コスト/値段について

公開料金から見るスモールスタートの目安

公開料金は、監視対象や料金条件によって含まれる範囲が変わります。

Webサイト・WAF監視：初期9万9,000円、月額10万8,350円（税込）から。
機器・ソフト監視：基本月額10万円に、1種ごとに月額5万円を加算。基本料金と3種なら月額25万円です。

前者は、WAFやIDS・IPS、ファイアウォールを対象とし、24時間365日監視と月次レポートを含んでいます。料金は、対象サイト数や通信量、専用ポリシーの有無で変動します（出典：クラウドWAFセキュリティオペレーションサービス公式料金ページ、2026年8月確認）。

後者は、対象PC台数などの条件があるため、自社の相場とは断定できません（出典：サイバーセキュリティ監視運用サービス公式料金ページ、2026年8月確認）。そのうえで、公開料金は機能と対応時間を比べる材料として見ます。

規模別の初期費用と月額費用の目安

対象範囲ごとの費用目安は次のとおりです。いずれも、予算を検討するための推定レンジです。

スモールスタート：1〜2製品の監視。初期0〜100万円、月額10〜30万円程度。
中規模MDR・SOC：複数ログ、一次判定、月次報告。初期300万〜1,500万円、月額30万〜150万円程度。
個別連携：SIEM・SOAR等を連携。初期1,500万〜5,000万円、月額100万〜500万円程度。
大規模案件：複数拠点や専用SOC等を含む場合、初期5,000万円〜1.5億円超、月額300万〜1,000万円超の可能性があります。

中規模の費用は、ログ連携やルール設計、手順書、教育に加え、24時間対応の有無で変わります。大規模案件では、海外拠点やフォレンジック、CSIRT支援が含まれる場合もあります。そのうえで、対象資産とログ量を根拠に再計算します。

初期費用以外も含めた予算化

構築作業と継続運用、例外対応にかかる費目と期間を洗い出すと、予算の漏れを防げます。

初期費用：調査、要件定義、設計、ログ連携、ルール作成、PoC、テスト、移行、手順書、教育。
月額費用：ライセンス、ログ保管、監視、分析、問い合わせ、ルール調整、月次報告。
別料金の例：緊急対応、フォレンジック、復旧支援、追加ログ・サイト、長期保管、個別レポート、休日作業。
導入期間：既存クラウド設定は1〜2か月、中規模は3〜6か月、個別開発や複数拠点移行は6〜12か月以上。

監視範囲があいまいなままだと、重要なログが抜けたり、対応責任が分からなくなったりします。そのため、機能を削るより、対象範囲を段階を追って広げるほうが安全です。

ポイント

費用は、ログ量や監視時間、資産数、一次対応範囲などで変わります。初期費用と月額費用、事故時の費用を分けて見ると、予算の判断がしやすくなります。

法務・監査・セキュリティ要件の確認事項

外部のクラウドや監視会社へログを送るときは、機密情報や個人データの扱いを、技術部門だけでなく関係部門と一緒に判断します。

データの種類やマスキング、保存場所を関係部門と確認します。委託先と再委託先、アクセス担当者、保存期間、削除方法、監査証跡も、あわせて確かめます。

ログの保存場所と委託契約

委託するときは、ログの内容と保護策を確かめ、契約上の対応範囲や終了時の扱いも確認します。

ログと収集：ユーザーID、IP、端末、URL、メールメタデータ、操作内容を含む場合があります。個人データに当たるかを確認し、必要最小限にとどめます。
保護策：海外リージョン、暗号化鍵、多要素認証、ロール権限、操作ログ、テナント分離、バックアップ、障害時の復旧目標。
運用条件：監視対象時間、通知目標時間、一次対応の定義。
事故・委託条件：誤検知時の扱い、緊急連絡経路、再委託条件、脆弱性発見時の報告、停止時の代替策。

契約が終わったときに、ログや設定を返却できるか、移行に必要な形式で取り出せるかも確認します。なお、事故時の追加費用と対応範囲が不明なら、月額料金だけでは比較できません。

監査証跡と訓練による「運用できる」ことの証明

監査と訓練では、判断や対応の証跡が残っているか、手順が実際に機能するかを確かめます。

台帳記録：発覚日時、原因、影響範囲、判断者、操作、復旧状況、再発防止策を残し、改ざんを防ぐ。
月次確認：アラート件数や重大アラートの対応時間、未解決件数、ルール調整、資産カバレッジ
訓練・復旧：半年から年1回程度の訓練、バックアップ復旧テスト、夜間連絡網の確認による手順の評価

IPAの中小企業向け情報セキュリティ対策ガイドライン第4.0版は、クラウドの安全利用やインシデント対応の手引きも関連資料として示しています（出典：独立行政法人情報処理推進機構「中小企業の情報セキュリティ対策ガイドライン第4.0版」、2026年確認）。

開発会社・ベンダーの選び方

会社を比べるときは、製品機能だけでなく、設計や監視、一次対応、個別開発、運用移管をどこまで担当するかを見ます。

製品提供、導入支援、SOC・MDR運営、業務システム連携では、得意な領域が異なります。そのため、必要な役割を先に定めてから候補を絞ります。

同規模・同業種の実績と対応範囲

実績は、導入社数や受賞歴だけでなく、自社と近いログ量、端末数、クラウド構成、規制、拠点数の条件で確かめます。可能であれば、匿名化した構成図や導入前後の課題、監視対象、検知ルール、改善方法も聞きます。

公開事例と契約後の範囲が同じとは限りません。そのため、提案書に含まれる作業を項目ごとに確認します。

重大アラート時の連絡例や初動判断、端末隔離の権限を質問します。また、原因究明、復旧支援、社外報告の担当も聞きます。回答が「ケースバイケース」の場合は、追加費用や承認条件を確認し、RFPの責任分界表に反映します。

技術力と運用体制の同一基準での評価

技術面では、ログの正規化やAPI連携、検知ルール、脅威情報に加えて、クラウド・EDR対応、権限、データ保護、バックアップ、障害復旧を確認します。運用面では、監視時間と担当者のスキルを見たうえで、二重化や教育、引き継ぎの体制も確かめます。

ルール調整や月次改善会議、インシデント訓練の支援も確かめます。評価表には、機能の有無や実装方法、標準機能か個別開発かを記録します。さらに、追加ライセンスや対応時間、実績、費用、移行性も書き込みます。

PoCでは、同じ攻撃シナリオで候補を比べ、自社ログでの検知と対応がどこまで再現できるかを見ます。提案資料の見栄えより、この再現性を重く見ます。

初期・月額・事故時に分けた見積もりの比較

見積もりの差が生じやすい費目と対応条件は、同じ範囲にそろえて照合します。

費用項目：初期構築費、月額ライセンス・保管・監視費、追加ログ・資産費、事故時の緊急対応費、終了時の移行費。
数量・条件：ログ量上限、保存期間、監視対象の増加単位、24時間対応料金、ルール変更回数、月次報告範囲。
低価格提案：重要ログが対象外になっていないか、連絡だけで封じ込めを含んでいないか。
障害・開発条件：障害時の手作業による監視の要否と、標準機能か個別開発かの区分。

高機能なSIEMでも、ルールを維持する担当者がいなければ、費用対効果は下がります。また、将来の内製化や乗り換えも比較の項目に含めます。

▶ 詳細はこちら：セキュリティ運用支援システム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：セキュリティ運用支援システム開発の発注/外注/依頼/委託方法について

ポイント

会社は、製品機能だけでなく、設計、監視、一次対応、個別開発、運用移管のどこまでを担当するかで比べます。自社に必要な役割を先に決め、その役割を担える会社に候補を絞るのが目安です。

導入後の運用と改善方法

セキュリティ運用は、本番稼働で終わるものではありません。攻撃手法や利用クラウド、組織、端末、業務アプリの変化に合わせて、監視対象とルールを見直します。

月次・四半期・年次の会議では、アラートの改善や資産と権限の洗い出し、訓練、復旧テストを続けます。

アラート品質と対応時間の指標

運用負荷が集中する箇所を把握し、検知ルールの改善につなげるための指標を確かめます。

時間・件数：重大度別の平均検知・通知時間、一次判定時間、未解決件数。
品質・対象：誤検知率、ルール変更数、重要資産の監視カバレッジ、脆弱性の期限内対応率。
ルール調整：誤検知には業務時間帯や管理端末の条件を加え、未検出の疑いは過去ログや演習結果で検証。

指標は、担当者を責めることなく、運用負荷の集中箇所を見つけるために使います。変更理由、承認者、検証結果、戻し方を記録しておくと、監査とトラブル対応の両方で役立ちます。

よくある失敗の防止策

失敗を防ぐには、導入前に目的を定めることと、運用を始めてから確認することを組み合わせます。

導入目的：「セキュリティを強くする」といった目標で終わらせず、守る対象と成功指標を定めます。
対象範囲：全ログの収集で費用やアラートが増えすぎないよう、重要資産と代表シナリオでPoCを行います。
対応準備：判断者の未定、退職・異動後の連絡網の古さ、バックアップ復旧の未検証を防ぎ、重大度別対応表を受け入れ条件とします。
定期改善：導入後は月次でルールを改善し、四半期ごとに資産と権限を洗い出します。
インシデント訓練：半年から年1回の訓練を予定に組み込みます。

システム管理者のアカウントにも、多要素認証や最小権限、操作監査、バックアップを適用します。

よくある質問

導入前によくある疑問に答えます。費用や対応範囲は環境によって変わるため、判断の軸を中心に示します。

小規模企業でもセキュリティ運用支援システムは必要ですか？

必要です。ただし、最初から全社のSIEMや24時間365日の専用体制を作る必要はありません。重要な端末や公開Webサイト、認証基盤、バックアップに対象を絞れます。

まずは月額サービスや営業時間内の監視から始め、アラート対応の手順と連絡網を決めてから、対象を広げます。

SOCは内製と外部委託のどちらがよいですか？

専任の人材や夜間・休日の交代要員、教育、対応権限、継続予算を確保できるかで判断します。内製は、業務背景に沿った判断がしやすい一方で、24時間体制と人材育成の負荷が大きくなります。

外部委託は、専門知識と監視体制を補えます。ただし、通知後の社内判断や復旧責任まで含むとは限りません。そのため、どこまでを誰が受け持つかを明記します。

費用を見積もるときに最初に伝える情報は何ですか？

まず、監視資産数や拠点数、端末数、クラウドとオンプレミスの構成を伝えます。ログの種類と1日量、保存期間、監視時間、攻撃想定、一次対応範囲も、あわせて示します。

個人データの有無やデータ所在地の制約、既存EDRやITサービス管理との連携、導入希望時期も整理します。そのうえで、初期費用と月額費用を分けた見積もりを依頼すると、比べやすくなります。

AIを使えばセキュリティ運用担当者は不要になりますか？

不要にはなりません。AIは、アラートの要約や関連ログの検索、調査候補の提示、報告書の下書きを支援できます。ただし、業務停止を伴う隔離や、個人データの報告判断までは代替しません。

誤検知時の責任も、AIが自動で引き受けるものではありません。そのため、利用するデータや出力の確認者、記録、誤りがあった場合の戻し方を決め、人の承認を残します。

まとめ

セキュリティ運用支援システムは、SIEMやEDRなどの製品を含みつつ、監視や分析、一次対応を続けて、社内承認や復旧、報告、改善までを担う業務基盤です。

まずは、守る資産とデータ、攻撃想定、許容停止時間、対応責任を定めます。そのうえで、代表的なログとシナリオを使ってPoCを行います。

要件と見積もりの整理と段階的な開始

運用を続けられる形にするには、費用の比較と成果の確認、統制を合わせて進めます。

費用比較：初期・月額・事故時の費用を分けた比較。
運用改善：通知・対応時間、誤検知、重要資産の監視範囲、脆弱性の期限内対応率の定期的な確認。
統制：個人情報保護、監査証跡、訓練、復旧テストの設計と、検知で終わらない運用の実現。

費用は、公開料金の例から中規模の運用、個別のSIEM・SOAR開発まで幅があります。そのため、ログ量や監視時間、対応権限、SLA、データ所在地の条件をそろえて比べることが欠かせません。

安さや高機能さだけでなく、自社が実際に運用を続けられるかを判断基準にします。そのうえで、確認結果に応じてルールと手順を改善します。

次の一歩となる現状のログと対応体制の棚卸し

相談の前に、監視対象、ログの種類と量、重要資産を一枚にまとめておきます。このほか、社内の状況と想定する攻撃に関わる項目も、同じ一枚に書いておきます。

既存のセキュリティ製品
連絡先
攻撃シナリオ
必要な監視時間

未確定の項目も明示しておくと、候補会社から調査、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を創業。