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

Amazon Neptuneのシステムを発注・外注するなら、最初に「関係データを使う業務課題」を一つ定め、PoCから本番化までの範囲と費用を分けて契約することが重要です。

Amazon Neptuneは、顧客・企業・商品・契約・担当者などのつながりを検索や分析に生かせるグラフデータベースです。一方で、Neptuneを使えば自動的に顧客管理システムが完成するわけではなく、グラフモデル、既存システム連携、データ移行、権限、画面、運用まで設計して初めて業務で使える仕組みになります。この記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較、発注後の進め方を、外注を検討する企業の視点で整理します。

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

Amazon Neptuneのシステムを発注する前に何を決めますか？

発注前に決めるべきなのは、サービス名やデータベースの種類ではなく、誰がどの判断を速くしたいのかです。顧客と子会社、商品、契約、問い合わせなどの関係を何段階もたどる業務であればNeptuneが候補になりますが、単純な一覧登録や定型集計だけなら既存CRMやRDBのほうが適切な場合があります。

最初の相談では「Neptuneで顧客管理を作りたい」と伝えるより、「商談先の子会社、導入済み商品、過去の接点を一画面で確認し、営業の調査時間を短縮したい」と伝えるほうが、委託先から具体的な提案を受けやすくなります。ほかにも、同一人物や同一企業の重複リードを検出する、代理店から顧客までの紹介経路を可視化する、商品と顧客の関係から推薦候補を返す、といった形に落とし込みます。

成果指標は、検索時間、重複リード率、引き継ぎ漏れ、問い合わせ対応時間、推薦のクリック率などから選びます。「便利になる」という表現だけでは検収条件にならないため、導入前の現状値、目標値、測定方法、測定期間を発注前に仮置きします。

向いているのは、顧客、担当者、企業、製品、契約、行動履歴などの関係が増え続け、多段の探索や経路の説明が業務の中心になるシステムです。Amazon NeptuneはGremlin、openCypher、SPARQLを利用でき、プロパティグラフやRDFを使って複雑な関係を扱えます（出典: Amazon Neptune公式ドキュメント、2026年確認）。

反対に、顧客情報を登録して一覧表示すること、完全一致のマスタ検索、定型帳票だけが目的であれば、既存CRM、SaaS、RDBで足りる可能性があります。発注候補には、Neptuneを採用しない案、既存CRMとNeptuneを併用する案、Neptuneを中心に作る案の3案を比較してもらうと、技術ありきの外注を避けやすくなります。

グラフデータベースの採用に迷いがある場合は、いきなり全社システムを発注せず、1つのユースケースと少量の実データを使うPoCから始めます。PoCでは、代表クエリのレイテンシ、同時接続、書き込み量、データロード時間、結果の正確性、月額AWS利用料を測定します。平均値だけでなく、最悪ケースの多段探索と、データに欠損や重複がある場合も試します。

PoCの合格条件には、技術性能だけでなく現場の利用意向も含めます。営業担当者が検索結果の経路を理解できるか、データ更新の責任者を置けるか、個人情報の利用目的と権限を整理できるかを確認し、合格しなければ本番発注に進まないルールを設けます。

Amazon Neptuneの発注形態はどれを選びますか？

発注形態は、要件の不確実さ、自社にいる技術者、業務側の参加時間、データ移行の難しさで選びます。単に「一括で安く作る」か「人を出してもらう」かではなく、どの工程の責任を委託先に持たせ、どの成果物を自社に残すかを決めることが大切です。

社内にグラフ設計やAWS基盤の経験者が少なく、業務整理から運用設計までまとめて任せたい場合は、一括外注が候補です。委託先が要件定義、グラフモデル、API、画面、AWS環境、テスト、移行、教育まで一つの責任範囲で管理できるため、発注窓口をまとめやすい点が利点です。

ただし、業務の意思決定まで丸投げすると、現場では使われない機能や、データ品質を無視したモデルが残る危険があります。自社側には業務責任者、データの管理者、セキュリティ判断者を置き、委託先と週次で優先順位と課題を確認します。

採用可否や性能が不明な案件では、PoCと本番開発を分けて発注します。最初の契約で、業務課題、サンプルデータ、グラフモデル案、代表クエリ、測定結果、残課題、次工程の見積条件を成果物にします。PoCが不合格なら、別方式へ切り替えるための判断材料が残ります。

段階発注は、最初の費用を抑えるためだけの方法ではありません。データの欠損、識別子の不一致、想定外のアクセス量、現場の操作負担を早く発見し、本番の追加費用を抑えるためのリスク管理です。PoCから本番へ自動的に移行するのではなく、合格条件と再見積のタイミングを契約書に置きます。

AWS基盤はクラウド専門会社、グラフモデルとアプリは業務システム会社、データ整備は自社または別会社という分担も可能です。専門性を補いやすい反面、障害の切り分け、データの受け渡し、仕様変更の責任が複雑になります。特にNeptuneとCRMの境界で不具合が起きたとき、どの会社が一次窓口になるかを決めておきます。

複数社で発注する場合は、全体アーキテクチャ、API仕様、データ項目定義、環境構成、監視項目、受け入れテストを共通の設計書にします。自社がプロジェクト管理を担えない場合は、全体PMを一社に置くほうが、短期的な単価よりも総コストを抑えやすいです。

RFPと要件整理では何を伝えますか？

RFPは、作ってほしい機能を羅列する文書ではなく、業務課題、データ、利用者、性能、セキュリティ、納品物、予算条件を同じ前提で比較するための文書です。候補会社が違う解釈で見積もらないよう、必須要件、希望要件、対象外を分けて記載します。

営業担当者、管理者、マーケティング担当者、データ管理者など、利用者ごとに何を見るのかを整理します。「顧客を検索する」ではなく、「商談前に子会社、担当者、既存契約、過去の問い合わせ、紹介経路を確認する」のように、操作のきっかけと判断内容を記載します。検索結果に経路、出典、更新日時、信頼度を表示するかも要件に含めます。

業務フローは、登録、更新、承認、削除、訂正、権限変更まで書き出します。顧客データの名寄せは、候補の自動提示と担当者の確認を分け、誤った統合を戻せるように履歴を残します。自動化できない判断を無理にシステム化しないことが、現場定着のポイントです。

RFPには、CRM、SFA、MA、ERP、Web行動、問い合わせ、契約、名刺などのデータソース、件数、更新頻度、形式、所有部署、連携方式を記載します。会社ID、個人ID、商品IDなどの識別子が統一されているか、表記揺れや重複がどれくらいあるか、個人情報や営業機密を含むかも明示します。

グラフモデルでは、ノード、エッジ、プロパティ、関係の有効期間、出典、削除・訂正の扱いを提案してもらいます。「担当する」「契約する」「紹介する」といった関係の意味を業務用語で定義し、同じ言葉を会社ごとに別の意味で使わないようにします。将来のデータを想像して作り込み過ぎず、PoCで必要な範囲から始めることが安全です。

性能要件は「高速」ではなく、代表クエリの応答時間、同時利用者数、ピーク時のアクセス数、1日あたりの書き込み量、許容するタイムアウト、データロード時間で表します。Amazon NeptuneはVPC内で利用し、TLS 1.2による接続が必要です。VPC、IAM、KMS暗号化、監査ログ、バックアップ、障害時の復旧手順をRFPに含め、セキュリティを納品直前の確認にしないことが大切です（出典: Amazon Neptune公式ドキュメント、2026年確認）。

最新機能を使う場合は、採用理由と追加の検証項目もRFPに書きます。2025年にはAmazon Bedrock Knowledge BasesのGraphRAGが一般提供され、文書から抽出したエンティティと関係をNeptune Analyticsに保持して、生成AIの回答に周辺文脈を加える構成が示されました（出典: AWS公式ブログ、2025年）。2026年にはNeptune Databaseで点・線・面、距離、包含、交差などの空間データをopenCypherから扱える機能が案内されています（出典: AWS公式What’s New、2026年）。これらを採用するなら、回答の根拠、位置情報の精度、誤回答、利用料、権限、データ保持をPoCの対象に含めます。

運用要件には、監視するメトリクス、アラートの通知先、障害対応時間、バックアップの保持期間、RTOとRPO、エンジン更新、クエリ改善、データ品質の定例作業を記載します。AWS利用料の試算条件も、リージョン、稼働時間、インスタンス数、Reader数、I/O、バックアップ、関連サービスに分けて提示してもらいます。

Amazon Neptuneの外注ではどの契約形態が適していますか？

契約形態は、成果物と完成条件を定義できるか、要件変更がどれくらい起こるか、業務側と技術側の役割をどこまで分けるかで選びます。法的な適用判断は契約内容や取引実態で変わるため、最終的には自社の法務・専門家に確認し、名称だけで判断しないことが重要です。

業務課題の整理、RFP作成支援、グラフモデルの検討、PoC、技術調査のように、作業を進めながら前提を確かめる工程は準委任契約が候補になります。成果物を納める場合でも、探索の結果として「Neptuneを採用しない」という結論になることがあります。作業時間だけでなく、会議体、担当者、報告書、検証環境、測定項目を明確にします。

準委任では、時間単価や月額だけを見ず、月に何時間を誰が担当するのか、未消化時間の扱い、追加作業の承認方法、成果物の利用権、秘密情報の管理を確認します。自社側の判断が遅れると期間だけが延びるため、意思決定者と回答期限も契約または計画書に置きます。

要件、設計書、API、画面、テスト項目、移行結果などの成果物と完成条件を定義できる工程では、請負契約を検討できます。納品物、検収方法、検収期間、瑕疵や不具合への対応、仕様変更の手続き、遅延時の扱いを契約書と仕様書でそろえます。

ただし、グラフモデルやデータ移行の難易度が未確認のまま、本番システム全体を固定価格の請負にすると、想定外のデータ品質や連携仕様をめぐって追加費用の争いが起きやすくなります。要件定義とPoCを準委任で行い、確定した範囲の開発を請負にする段階的な組み合わせが現実的です。

本番稼働後は、AWS利用料と開発会社への保守費用が発生します。保守契約には、問い合わせ対応だけでなく、障害一次対応、ログ調査、クエリチューニング、バックアップ復旧訓練、エンジン更新、脆弱性対応、データ品質改善、利用者追加を含めるかを明記します。

保守の時間帯、連絡方法、重大度ごとの初動時間、復旧目標、月次報告、作業の上限、時間外費用を確認します。納品後に自社運用へ移行するなら、IaC、監視設定、クエリ、データモデル、運用手順、障害訓練の記録を引き継ぐ条件も契約に含めます。

発注から本番リリースまでの進め方はどうなりますか？

発注後は、業務側の判断と技術側の検証を並行させながら、要件を段階的に具体化します。最初に全機能を決め切るより、代表ユースケースでデータと性能を確かめ、結果を次の設計に反映するほうが、Neptune案件ではリスクを管理しやすいです。

候補会社にはRFPとともに、サンプルデータ、代表クエリ、現在の業務フロー、既存システムの構成、利用者数、データ量、求めるRTOとRPOを提示します。機密情報を含む場合は、秘密保持契約を締結してからマスキング済みデータや項目定義を共有します。

提案書では、採用する構成、採用しない構成、前提条件、対象外、体制、スケジュール、成果物、リスク、見積の内訳を分けて記載してもらいます。AWS利用料を開発会社の費用に混ぜず、インスタンス、ストレージ、I/O、バックアップ、Analytics、S3、Lambda、監視、転送などに分けてもらうことがポイントです。

要件定義では、業務シナリオ、データ項目、権限、性能、画面、連携、運用、検収条件を確定します。設計では、Neptune DatabaseとNeptune Analyticsの役割、Gremlin・openCypher・SPARQLの選択、API認証、VPC構成、監視、バックアップ、障害復旧を決めます。AWS公式ドキュメントでは、Neptuneはグラフクエリ言語としてGremlin、openCypher、SPARQLをサポートしているため、委託先に採用理由と将来の保守性を説明してもらいます（出典: Amazon Neptune公式ドキュメント、2026年確認）。

開発では、先にデータロードと代表クエリを動かし、次にAPI、画面、権限、連携を組み合わせます。最初から画面だけを作ると、実データを入れた段階で検索性能や名寄せの問題が見つかります。スプリントごとに動く成果物を確認し、業務担当者が実際の検索と判断を試す場を設けます。

移行では、抽出、変換、名寄せ、重複処理、ロード、件数照合、関係の正しさの確認を行います。移行対象を全量に広げる前に、代表部署や代表期間でリハーサルを行い、誤った統合や欠損があれば戻せる手順を作ります。個人情報を扱う場合は、利用目的、アクセス権、保持期間、訂正・削除の手順を業務と技術の両面で確認します。

受け入れテストは、機能、性能、権限、監査、障害復旧、データ品質、運用手順の観点で行います。検収条件には「画面が表示される」だけでなく、代表クエリが定めた時間内に返ること、権限外の関係を表示しないこと、移行件数が照合できることを含めます。教育では、検索方法だけでなく、誤った名寄せを戻す方法、データ更新の責任者、問い合わせ先を伝えます。

本番化では、段階リリース、切り戻し、障害時の連絡、監視、バックアップ、復旧訓練を確認します。開発環境やステージング環境を常時起動したままにせず、利用時間と本番の可用性要件を分けることでAWS費用を管理しやすくなります。IPv4とIPv6の接続が必要な企業では、2026年6月に発表されたNeptuneのデュアルスタック対応が自社ネットワークに適用できるかも確認します（出典: AWS公式What’s New、2026年）。

リリース後は、検索時間、利用率、誤検索、データ更新の遅延、クエリレイテンシ、I/O、エラー、AWS利用料を定例で確認します。利用者の要望をすべて機能追加に変えるのではなく、データモデル、画面、運用ルールのどこを改善すべきかを判断し、保守契約の範囲で計画的に対応します。

Amazon Neptuneの発注・開発費用の相場はいくらですか？

費用は、AWSに支払う利用料と、開発会社へ支払う要件定義・設計・開発・移行・運用の費用に分けて考えます。次の金額はNeptune案件の一律統計ではなく、AWS公式料金例と、営業・CRMシステムの類似相場にグラフ設計、データ移行、AWS基盤構築の工数を加えた推定レンジです。実際の金額は、データ量、連携数、権限、性能、利用者数、納期、運用要件で変わります。

AWS公式料金ページの例では、米国東部リージョンでdb.r5.largeを1台、データ50GB、バックアップ100GB、月2億I/O、一定のデータ転送を使う構成が月額296.61米ドルです。同じ条件でI/O-Optimizedを使い、I/O課金を含めない例は月額350.56米ドルです（出典: Amazon Neptune公式料金ページ、2026年8月確認）。1米ドルを150円と仮置きした場合は約4.4万〜5.3万円ですが、為替や日本リージョンの料金を含む請求額を示すものではありません。

Writer 1台とReader 3台の計4台を使う本番寄りの公式例では、インスタンス、ストレージ、I/O、Neptune Workbenchなどを含めて月額5,740.10米ドルとされています（出典: Amazon Neptune公式料金ページ、2026年8月確認）。本番・検証・開発の複数環境、監視、S3、Lambda、ECSやEKS、データ転送、AWS Supportまで含めると、月額数十万円から100万円超になる可能性があります。

技術検証PoCは、1ユースケース、少量データ、グラフモデル、代表クエリの検証で300万〜800万円程度、期間は1〜2か月程度が推定の目安です。顧客360度ビューや関係検索に既存CRMとのAPI連携と管理画面を加える小規模本番は、800万〜2,000万円程度、3〜6か月程度が目安になります。

複数部門の名寄せ、権限、監査、データ移行、MAやSFA連携を含む中規模業務基盤は2,000万〜5,000万円程度、6〜12か月程度が推定されます。全社利用、大量データ、複数リージョン、厳格なSLA、複数業務まで含めると5,000万円〜1.5億円超、12〜24か月以上になる可能性があります。いずれも相場を断定する数字ではなく、要件が変われば再見積が必要です。

概算見積では、要件定義、グラフモデル設計、AWS基盤、API、画面、既存システム連携、データクレンジング、移行、テスト、教育、PM、保守を分けます。ノートの類似システム相場では、要件定義10〜15%、設計25〜35%、開発・テスト45〜60%、移行・教育5〜10%程度を仮置きする考え方があります。ただし、Neptune案件では移行とデータ品質の比重が大きくなることがあるため、比率をそのまま固定しないことが大切です。

保守は初期開発費の年10〜20%を仮置きする方法がありますが、問い合わせだけの保守か、クエリ改善、エンジン更新、復旧訓練、セキュリティ対応、データ品質改善まで含むかで金額は変わります。AWS利用料と保守費を一つの月額にまとめず、利用量で増える費用と人が対応する費用を分けると、予算差異を説明しやすくなります。

Amazon Neptuneの委託先はどのように選びますか？

委託先は、AWS認定やパートナーランクだけでなく、グラフデータの設計、データ移行、業務アプリ、セキュリティ、運用をどこまで担えるかで選びます。AWSパートナーであることは基盤の知見を判断する材料ですが、Neptune DatabaseやNeptune Analyticsの実案件、クエリチューニング、Gremlin・openCypher・SPARQLの経験まで自動的に保証するものではありません。

候補会社には、Neptune DatabaseとNeptune Analyticsのどちらを使ったか、property graphかRDFか、どのクエリ言語を採用したか、データ量と関係数、ピーク時のアクセス、代表クエリ、移行方式、性能改善の内容を確認します。顧客情報や営業機密を扱った実績がある場合は、匿名化して説明できる範囲と、権限・監査・削除への対応も質問します。

公開事例では、AWSのケーススタディでWizがAmazon Neptuneを使い、数百億件の関係をセキュリティグラフに保持し、複数のAWSリージョンで大規模運用していることが紹介されています（出典: AWS公式ケーススタディ、2026年確認）。これは大規模事例であり、一般企業のCRMにそのまま適用できる意味ではありません。委託先には、自社の規模に合う構成へ落とし込む考え方を説明してもらいます。

Neptuneの構築経験があっても、既存CRMやSFAのデータを正しく取り込めなければ業務では使えません。候補会社には、データクレンジング、名寄せ、ID設計、差分連携、再移行、件数照合、削除依頼への対応を誰が担うかを確認します。自社がデータ整備を行うなら、必要な人員と作業期間を見積に含めます。

セキュリティでは、VPC、TLS、IAM、KMS、秘密情報の保管、ログ、バックアップ、アクセス元制限、開発環境のデータマスキング、国外リージョンの利用有無を確認します。Neptune側の機能だけで法令や社内規程への適合が完了するわけではないため、利用目的、権限申請、監査、漏えい時の報告手順を自社の責任範囲として整理します。

納品物は、ソースコードだけでは不十分です。グラフモデル定義、ノード・エッジ・プロパティ一覧、API仕様、クエリ、IaC、環境構成、テスト結果、移行手順、バックアップと復旧手順、監視設定、権限一覧、操作マニュアル、教育記録を確認します。第三者が引き継げる粒度で納品されるかを、提案段階でサンプルを見せてもらいます。

運用を委託する場合は、保守会社がAWS利用料の最適化まで見るのか、クエリ遅延の改善まで対応するのか、データ品質の問題をどこまで直すのかを分けます。内製化を目指す場合は、最初から自社担当者を設計会議と障害訓練に参加させ、月次の技術移管計画を契約に含めます。

相見積もりでは、各社に同じRFP、同じサンプルデータ、同じ代表クエリ、同じ検収条件を渡します。そのうえで、見積総額、工数、単価、期間、体制、AWS利用料、対象外、前提、リスク、変更時の単価を比較します。安い提案が、データ移行や運用を対象外にしているだけの場合があるため、内訳のない一式見積はそのまま採用しません。

比較表を作るときは、価格だけでなく、業務理解、Neptune経験、移行方法、セキュリティ、性能検証、納品物、保守、内製化支援、コミュニケーションの項目を並べます。候補会社の提案を同じ条件で採点し、重要項目に重みを付けると、単価の安さに引きずられにくくなります。

よくある質問（FAQ）

Amazon Neptuneの発注では、技術選定だけでなく、費用の変動、既存データの品質、契約の責任範囲、運用の引き継ぎがよく問題になります。ここでは、外注前に確認されやすい質問へ直接回答します。

外注できます。ただし、Neptuneの構築だけでなく、グラフモデル、既存CRMやSFAとの連携、データ移行、画面、権限、監視、運用保守まで対応できるかを確認する必要があります。Neptune固有の実績が少ない会社でも、PoCで代表クエリとデータ移行を検証し、担当範囲を明確にすれば候補になります。

AWS利用料は、小規模な1台構成で数万円程度から検討できますが、公式料金例の条件で月額296.61〜350.56米ドル、WriterとReaderを含む構成で月額5,740.10米ドルという幅があります。開発会社への費用は、PoCで300万〜800万円、小規模本番で800万〜2,000万円、中規模業務基盤で2,000万〜5,000万円程度が推定レンジです。いずれも要件と利用量に基づく目安で、固定額の断定ではありません。

既存CRMの置き換えではなく、関係検索や横断分析のためにNeptuneを併用する価値があります。顧客と子会社、担当者、契約、製品、問い合わせなどを多段に探索し、顧客360度ビュー、名寄せ、推薦、不正検知、GraphRAGへ活用する場合が候補です。単純な登録と一覧表示が中心なら、CRMやRDBを使い続けるほうが合理的な場合があります。

要件や技術の不確実さが大きい要件定義・PoCは準委任、成果物と完成条件を定義できる設計・開発は請負を検討する方法があります。実際には、工程ごとに組み合わせることが多いため、契約名称だけでなく、成果物、責任範囲、検収、変更手続き、追加費用、知的財産、保守、引き継ぎを確認します。最終判断は契約内容を確認できる法務や専門家に相談します。

業務課題と成果指標、利用者、現状の業務フロー、データソースと件数、代表クエリ、既存システム、セキュリティ条件、希望納期、予算の考え方、必要な納品物を準備します。実データを共有できない場合でも、項目定義と匿名化サンプルを用意すると、会社ごとの前提をそろえやすくなります。採用案だけでなく、Neptuneを使わない案も提案に含めてもらいます。

まとめ

Amazon Neptuneのシステムを発注・外注するときは、データベースを先に決めるのではなく、関係データを使って解決したい業務課題を明確にします。PoCで代表クエリ、データ品質、現場の操作性、セキュリティ、AWS利用料を測定し、Neptuneを採用しない選択肢も含めて本番化を判断します。

発注形態は、一括外注、PoCと本番の段階発注、複数社のハイブリッドから、自社の体制と不確実さに合わせて選びます。RFPには業務フロー、データ、グラフモデル、性能、セキュリティ、運用、納品物、検収条件を記載し、準委任と請負を工程ごとに使い分けます。契約では、仕様変更、追加費用、障害対応、データ移行、知的財産、運用移管まで確認します。

AWS公式料金例では、条件により1台構成が月額296.61〜350.56米ドル、複数インスタンスを含む例が月額5,740.10米ドルです。開発費はPoCで300万〜800万円、小規模本番で800万〜2,000万円、中規模業務基盤で2,000万〜5,000万円程度が推定レンジですが、実際にはデータ移行、連携、権限、性能、保守で変わります。委託先は、Neptune固有の経験、データ移行、セキュリティ、納品物、運用支援、内製化支援を同じ条件で比較します。

Neptuneは、関係性を業務の価値に変えられる場合に強い選択肢です。自社だけで要件をまとめにくい場合は、PoCの設計と見積比較から外部の専門会社へ相談し、関係データの効果と総保有コストを確認してから本番発注へ進めます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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