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

DynamoDBのシステムは、アクセスパターン、業務特性、非機能要件に分けて押さえると、構成の判断と設計を進めやすくなります。

データベースの特徴から、向く業務、開発の進め方、設計・運用、費用までを順に見ていきます。各テーマの詳しい内容は、次の関連記事で確認できます。

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

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

DynamoDBのシステムの概要

DynamoDBのシステムでは、業務画面やAPIが読むキーを先に決め、その読み書きに合わせてテーブルを設計するのが基本です。自由検索型のデータベースとは性格が異なります。

DynamoDBはキー・バリュー型とドキュメント型に対応します。また、サーバーレス・フルマネージドで、1桁ミリ秒レベルの性能を提供します（出典: AWS「Amazon DynamoDB Features」、2026年確認）。

サーバーを管理せずに使えるデータ基盤

従来型DBでは、サーバー台数やストレージ、冗長化を利用側が設計します。パッチやバックアップ、障害時の切り替えも、利用側が運用します。

アクセス量の少ない検証環境から大規模な本番環境まで、同じプログラミングモデルを使えます。一方、パーティションキーの偏りやGSI、項目サイズは利用企業が決めます。リトライや権限の設定、バックアップ、監視も、利用企業が決めることです。

• 基盤運用：運用の多くをサービス側に任せられるため、業務ルールやAPI、画面の開発に力を注げます。
• 設計責任：サーバー操作は減る一方で、データモデルとアプリケーションの境界を設計する力が欠かせません。

Amazon DynamoDBは、サーバーの調達やパッチ適用を意識せずに使える分散NoSQLデータベースです。

RDBとの設計思想の違い

PostgreSQLやMySQLなどのRDBは、表を正規化し、条件検索やJOINを行う設計に向いています。一方、DynamoDBにはJOINがないため、情報を複数の項目に持たせる非正規化が基本になります。

画面に必要なデータを1回のQueryで取り出せる形を目指します。後から検索条件を増やす場合はGSIを追加できますが、その分、書き込み量や保存量、更新処理の複雑さが増えることがあります。

スキーマが柔軟でも、何でも入れられるわけではありません。注文一覧や顧客履歴、状態別キューなど必要な取得方法をあらかじめ定めておき、未対応の検索が出てきた場合は、設計やデータの持ち方を見直します。

主要な構成要素

主キーは、パーティションキー単独か、ソートキーを組み合わせた形から選びます。ソートキーを使うと、顧客ID別の日時履歴や注文ID別の明細を範囲検索できます。

• 検索軸と期限：別の検索条件はGSI、同じパーティション内の別の並び順はLSIで検討します。TTLは、一定期間後の項目削除に使えます。
• 更新制御：条件付き書き込みは在庫や状態の競合を防ぎ、トランザクションは複数項目を一括で成功または失敗させます。
• 変更連携：DynamoDB Streamsで項目の変更をほぼリアルタイムに取り出し、Lambdaにつないで通知や集計、検索用インデックスを非同期で更新します。

新規開発・部分利用・移行の3種類

DynamoDBの構成は、導入の起点によって3種類に分けられます。新規開発でAPIやイベント処理の中心にする方法、既存RDBを残して一部機能を分ける方法、既存データを段階的に移行する方法です。

新規開発は設計の自由度が高く、部分利用は影響範囲を抑えやすいのが特徴です。一方、移行は既存資産を活かせる反面、データ変換と並行稼働の工数が増えます。

DynamoDBのシステムに向く業務と向かない業務

DynamoDBへの適性は、データ量よりも読み書きのパターンで決まります。読み書きの型が予測でき、低レイテンシーと水平スケールが重要な業務に向いています。

利用者が自由な条件を組み合わせる帳票や、複雑な集計が中心の場合は、RDBや分析基盤を併用したほうが安定します。

セッション・カート・予約枠のような状態管理

利用者IDをパーティションキー、更新日時や状態をソートキーにすると、利用者ごとの最新状態や履歴を取り出せます。

• 状態管理の対象：ECのカート、ログインセッション、予約枠、通知キュー、IoT機器の最新状態が該当します。
• アクセス変動：キャンペーン時の急増や、多数の機器からの短時間の送信に対応する構成を選べます。
• 更新制御：予約や在庫を同時に更新する場合は、条件付き書き込みやトランザクションを検討します。
• 業務ルール：成功の条件と失敗時の画面を決め、再試行回数と二重送信の扱いも定めます。

単純な上書きだと、同じ在庫を複数の利用者が確保してしまう競合が起きます。そのため、同時更新を制御する仕組みが必要になります。

自由検索や複雑な帳票が中心の場合の判断

顧客名、地域、担当者を利用者が任意に選んで検索する場合は、DynamoDBだけでは難しいことがあります。金額や期間で絞り込む検索も、対応しきれないことがあります。

• 自由検索：条件ごとにGSIを増やすと、更新の負荷と保存コストが膨らみ、すべての条件を網羅できないこともあります。
• 集計・帳票：月次の合算、複数業務の出力、複雑なJOINは、RDB、S3、Athena、検索サービスへ連携します。
• 部分利用：向かない業務でも全面的に見送る必要はなく、取引はRDBに置き、一部だけをDynamoDBで扱えます。

役割を分けると、DynamoDBの速さとRDBの集計のしやすさを両立できます。

業務の主記録と検索・分析の分担

DynamoDBを「すべてのデータを入れる箱」と見なさず、どこまでを担当させるかという責任範囲を定義して使います。たとえば、注文状態を管理しつつ、変更イベントをStreams経由で分析用のS3へ蓄積する構成ができます。

• CQRSに近い構成：利用者向けの高速な検索には専用のインデックスを設け、書き込みと検索を別々に改善します。
• 反映要件：遅延と不整合に備え、数秒の遅れを許せる集計か、画面の最新値が要るかで同期と非同期を選びます。
• 運用設計：正本の場所、更新の経路、再送と重複排除、障害時の再構築の方法を記載します。

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

開発は、テーブルを作る前に業務課題と非機能要件を整理することから始まります。そのうえで、画面やAPIごとのアクセスパターン、ピーク時の読み書き量、許容レイテンシーを確認します。

障害時のRTO・RPO、保存期間、監査要件も決めておきます。次に、データモデルとAWS構成を設計します。

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

要件定義での業務と非機能要件の数値化

誰が、いつ、どの画面やAPIで、どのデータを、どの順に取得・更新するかを書き出します。

• 負荷と応答：1日の平均と1分間のピーク、同時実行数、許容レイテンシーとエラー率を押さえます。
• データ特性：項目の平均サイズと最大サイズ、読み取り整合性を確認します。
• 個人情報と復旧：項目の分類、暗号化キー、アクセス主体を決めます。ログ、リージョン、委託先の権限、RTO・RPOも定めます。

たとえば、月末に処理が集中する業務と、終日一定のIoT通信では、容量モードやアラームが異なります。なお、RTOは復旧までの許容時間、RPOは失っても許容できるデータ量です。

「高可用性」とだけ定めて数値を示さないと、バックアップや多リージョン構成の費用を比べられません。

アクセスパターンに基づく主キーとインデックスの設計

ユースケースごとに、取得対象と検索キーを表にまとめます。並び順や件数、更新条件も、同じ表に書き込みます。たとえば、顧客別の注文一覧では顧客IDと注文日時、機器別の状態では機器IDと更新時刻を使います。

• Query設計：1回のQueryで必要なデータが返る形を目指します。
• 偏りの確認：キーにアクセスが集まりすぎないよう、分散性と検索性を両立させます。
• GSIの管理：投影する属性、更新の頻度、不要になったときの削除方法を決めます。

Scanを前提にした画面や、全件を取り出してから絞り込む作りは、データ量が増えるにつれて性能と費用が悪化しやすいです。

設計の段階では、ホットパーティションが生じていないかを確認します。特定のキーにアクセスが偏ると、全体の容量に余裕があっても一部がボトルネックになります。たとえば、日付や固定の店舗コード、同じ状態値をキーにする場合は注意が必要です。

キーの偏りを避けた設計によって、必要な取得性能とインデックスの運用を両立させやすくなります。

PoCとIaCによる性能・復旧・環境差の検証

本開発の前に、代表的な読み書きとピーク時の負荷を再現するPoCを行います。

• 容量使用量：CloudWatchでConsumedReadCapacityUnitsとConsumedWriteCapacityUnitsを見ておきます。
• 応答・制限：ThrottledRequestsとレイテンシーを見て、キー設計が安定しているかを測ります。
• 負荷・競合：急増、同時更新、タイムアウト後の再試行を試験します。
• 重複処理：同じメッセージが二重に処理されるケースも試します。

テーブルやIAMの設定は、IaCで管理します。LambdaやAPI Gatewayの設定も、IaCの対象です。CDK、CloudFormation、Terraformなどを使います。

アラーム、バックアップ、削除保護も対象です。手作業で環境を構築すると、権限やバックアップ設定に差が生じ、障害につながるためです。

ソースコードや環境構築の手順、変更承認の流れも、納品物として残します。

移行・テスト・リリースの段階的な進め方

既存RDBから移行する場合は、まず項目対応表を作ります。そのうえで、欠損、重複、表記揺れの扱いを決め、変換ルールと移行対象期間も定めます。

1. まずは検証環境で試しに移行します。
2. 差分を同期しながら、並行稼働させます。
3. 最終切り替えを行い、必要に応じてロールバックします。

移行後は、件数の一致だけでなく、代表的な顧客・注文・在庫について、業務画面の結果まで照合します。

リリース前は、機能テストに加えて、負荷試験と障害試験を行います。復元と権限の試験、監査ログの確認も欠かせません。

PITRで復元できても、アプリの接続や再処理まで自動で終わるとは限りません。そのため、復旧手順を実際に実行し、目標時間内に業務を再開できるかを確かめてから、本番へ移行します。

データ設計・セキュリティ・運用で押さえるポイント

性能とセキュリティは、切り離して考える必要があります。キーの選び方は性能を左右し、項目の持ち方は料金や個人情報の露出範囲に影響します。

運用を始めてから変えにくい部分は、設計の段階で確かめておきます。

IAM・暗号化・ネットワークの最小権限設計

DynamoDBは保存データを暗号化できます。ただし、それだけで安全になるわけではありません。

AWSは、予防的な対策として次の項目を示しています（出典: AWS「DynamoDB preventative security best practices」、2026年確認）。

• 保存時の保護：KMSによる暗号化と、必要に応じたクライアント側の暗号化。
• 権限：IAMロールとポリシーで、アプリごとに必要なテーブル・操作・属性へ限定。
• ネットワーク：VPCエンドポイントでアクセス範囲を制御。

個人情報や機密情報をキー名やキー値に入れると、テーブル定義やログに現れるおそれがあります。そのため、利用者は内部IDで識別し、ログはマスキングします。

CloudTrailの操作記録と、KMSキーの管理者の分離も検討します。さらに、アクセスを限定する場合は、エンドポイントポリシーも組み合わせ、インターネット経由を避ける構成を確認します。

バックアップ・監視・障害対応の運用手順

バックアップは、取得するだけでなく、復元できることが欠かせません。

PITRは、テーブル単位で1日から35日まで設定でき、期間内の任意の時点へ戻せます（出典: AWS「Amazon DynamoDB now supports configurable point-in-time-recovery periods」、2025年）。

保持期間、クロスアカウントや別リージョンへの保管、復元後の再処理は、業務のRPO・RTOと照らし合わせて決めます。

• 容量監視：ConsumedReadCapacityUnitsとConsumedWriteCapacityUnitsを見ます。
• 応答監視：ThrottledRequestsとSuccessfulRequestLatencyも対象に入れます。
• 異常対応：システムエラー、Lambdaの失敗、ストリームの遅れを監視の対象にします。
• 連絡と復旧：通知先、調査する範囲、ロールバックを判断する時点を決めておきます。
• 料金管理：月次で料金アラートと未使用のGSIを確かめ、不要な設定は削除します。

これらを運用手順に定めておくと、障害対応とコスト管理に生かせます。

2026年の動向と、互換性・復旧設計の観点

2026年5月には、DynamoDB APIと差し替え可能なストレージを組み合わせる、オープンソースのExtendDBが発表されました。

開発PCやCI、オンプレミスで同じプログラミングモデルを使う方向性を示します。接続が限られるエッジも、対象に含まれます（出典: AWS「AWS announces ExtendDB」、2026年5月20日）。

• ExtendDB：API互換、負荷特性、障害時の挙動、データ移行方法を確かめます。
• 複数アカウントの複製：競合、書き込みのコスト、越境、復旧手順を見ておきます。

API互換であっても、本番のマネージドサービスと同じ性能や可用性、運用負荷になるとは限りません。2026年2月には、グローバルテーブルを複数のAWSアカウント間で複製する機能も発表されました。

この機能により、障害の分離、データの配置、ガバナンスを考えやすくなります（出典: AWS「Amazon DynamoDB global tables now support replication across multiple AWS accounts」、2026年2月3日）。

新機能だという理由だけでは採用しません。業務の可用性とデータ境界に合うかどうかで判断します。

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

DynamoDBの費用は、AWS利用料と開発費に分けて考えます。サーバーレスでも、APIや認証、Lambdaには費用がかかります。

監視やバックアップ、転送、検索にも料金が生じます。設計・テスト・保守も費用に含まれます。

以下は、2026年時点の公開料金体系と、業務システム開発の一般的な工程をもとに算出した初期目安です。実案件の確定見積もりではありません。

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

開発費の規模と、移行・非機能要件による違い

検証用は、小さなAPIや管理画面を作る規模です。小〜中規模は、認証や権限、管理画面に加えて、監視やバックアップ、テスト環境を備える規模です。

• 検証用：100万〜300万円程度、期間は1〜3か月が初期の目安です。
• 小〜中規模：500万〜1,500万円程度、3〜6か月が目安です。
• 移行を含む規模：1,000万〜3,000万円程度で、6〜12か月かかることがあります。
• 高度な要件：3,000万円から1億円以上で、9〜18か月以上になることもあります。

移行では、RDB移行やイベント連携を考慮します。並行稼働や監査対応も含めて考えます。

高度な構成には、多リージョンや高負荷、24時間監視が含まれます。さらに、厳格な審査や複数部門の権限管理も加わります。

この金額は、DynamoDB固有の相場ではなく、要件定義から教育までを含めた推定です。

予算配分の仮説は、要件定義が10〜15%、設計が25〜35%、実装が30〜40%です。テストは15〜20%、移行と教育は5〜10%です。見積もりの抜けを確かめる材料になります。

AWS利用料はリクエスト・保存・追加機能で決まる仕組み

AWS料金は、基本の利用料に、追加機能の費用が重なって決まります（出典: AWS「Amazon DynamoDB pricing」、2026年確認）。

• 基本利用：読み取り、書き込み、データ保存に課金されます。
• 追加機能：PITR、オンデマンドバックアップ、Streams、Kinesis、S3入出力が対象です。
• 拡張機能：グローバルテーブルやDAXも、料金に影響します。
• 容量モード：オンデマンドはリクエストごと、プロビジョンドは確保した容量の時間ごとに課金されます。
• 料金例：月4,217.7万回、平均27GB保存時は3.16米ドルです。

料金例は、AWS公式の米国東部リージョンの例で、1KBの書き込みと強整合読み取りを前提にしています。

バックアップやDAXなどを加えた例では、構成により68.42米ドル、2リージョンでは99.03米ドルになります（出典: AWS「Amazon DynamoDB pricing」料金例、2026年確認）。

日本リージョンや為替の影響に加え、無料利用枠や項目サイズでも料金は変わります。そのため、実際のアクセス量を料金計算ツールで確かめます。

見積もりでの初期費用・月額費用・保守の分け方

見積もりでは、工程ごとの初期費用、月額費用、保守費用を分けて確かめます。

無料利用枠にはリージョンやアカウント単位の条件があります（出典: AWS「Amazon DynamoDB pricing」、2026年確認）。

• 初期工程：要件定義、データ設計、アプリ、インフラ/IaC、移行ごとに金額を分けます。
• 試験・教育：負荷試験、セキュリティレビュー、教育にかかる費用を別に扱います。
• 継続費用：AWS、監視、保守、障害対応、軽微な改修、追加開発に分けて、初年度と2年目以降を比べます。
• 無料利用枠：25GB保存、25 RCU・25 WCUが基準です。

無料枠を前提にした検証費用を、本番予算にそのまま延ばしてはいけません。ピーク時の負荷試験や復元訓練も、見積もりに含めるかどうかを確かめます。

本番では、ログやバックアップ、転送のほか、追加インデックスや他サービスも含めて、月次の上限アラートを設定します。

DynamoDBの開発会社/ベンダーとサービスの選び方

開発会社やサービスは、DynamoDBを使えるかどうかだけでなく、業務要件をデータモデルに変換できるかで選びます。

AWS環境の構築だけを支援する場合と、設計や移行、負荷試験、運用の引き継ぎまで担う場合では、提出物も費用も異なります。

容量モードやバックアップ、監視のほか、検索やイベント連携も、要件と運用体制に合わせて比べます。候補先には同じRFPを渡し、提案内容を同じ観点で見ます。

テーブル設計・移行・運用の実績の確認

実績は、サービス名や認定資格だけで判断せず、具体的な内容で確かめます。アクセスパターンの設計やホットパーティション、GSIについて質問します。さらに、RDB移行時の品質検査についても尋ねます。

• 提出物：匿名化した設計書、負荷試験の結果、復元手順、引き継ぎ資料を見せてもらいます。
• 担当者：営業担当だけでなく、テーブル設計と実装を担当する技術者と話せるかを確かめます。
• 対応体制：障害時の一次対応者や、エスカレーションできる時間帯を聞いておきます。
• 契約条件：契約後の改修、再委託、データアクセス権、秘密保持、ログの扱いを整理します。

提案書と見積書の同じ観点での比較

比べる観点は全部で8項目で、中心はデータ設計、既存データ移行、アプリとAWSの統合です。残りは、IaCやテストのほか、セキュリティ、監視・バックアップ、教育・保守にあたります。

各項目は「提案に含む」「別途費用」「対象外」に分けます。負荷試験や復元試験、データクレンジングに加え、設計レビューの別料金も確かめます。

• RFPの負荷条件：ユーザー数、平均・ピークのリクエスト、項目サイズ、保存期間、リージョンを書いておきます。
• RFPの要件：RTO・RPO、個人情報の扱い、検索条件、必要な納品物を明記します。
• 設計の納品物：テーブル定義やアクセスパターン表、IaC、ソースコードを含めてもらいます。
• 品質・運用の納品物：テスト仕様や負荷試験の結果、バックアップと復元の手順、監視項目を含めます。

条件が明確であれば、会社の規模より案件との適合性で評価できます。

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

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

よくある質問（FAQ）

DynamoDBの導入では、料金だけでなく、データ設計や移行、運用の責任も確かめます。よくある質問に答えていきます。

DynamoDBとRDBはどちらを選べばよいですか？

アクセスパターンが明確で、高頻度の読み書きや大きなスケールが重要なら、DynamoDBが候補になります。一方、複雑なJOINや自由検索、集計帳票が中心なら、RDBが適している可能性が高いです。役割を分けて選ぶこともできます。

判断の基本は、業務要件を先に整理し、データベースの機能から逆算しないことです。

DynamoDBは本当に安いですか？

利用量が少ない場合は、リクエスト単位で支払えるため、常時稼働するサーバーより費用を抑えられることがあります。

一方、総額はGSIやバックアップ、PITR、Streamsなどの機能で増えることがあります。Lambda、API、監視、転送の費用も、総額に影響します。

開発費も別に発生します。AWS利用料と初期開発費、保守費を分け、3年程度の総額で比べます。

既存RDBからDynamoDBへ移行できますか？

移行はできますが、表を機械的にコピーするだけでは足りません。アクセスパターンに合わせたキー設計や非正規化、データクレンジングが必要です。さらに、差分同期や並行稼働、件数と業務結果の照合も欠かせません。

全部を移すのは避け、まずはセッションや高頻度の参照など、効果が明確な領域から段階的に移すと、リスクを抑えやすくなります。

個人情報をDynamoDBに保存しても安全ですか？

保存はできますが、適切な設計と運用が前提になります。具体的には、IAMの最小権限と、保存時・通信時の暗号化を設定します。

KMSキーやVPCエンドポイント、CloudTrailの設定も管理します。バックアップの保管先、ログのマスキング、委託先のアクセスも押さえます。

保存リージョンや国外移転、保管期間は、社内の法務やセキュリティ基準と照らして個別に確認します。削除依頼への対応についても確かめます。

まとめ

DynamoDBは、サーバーレスで高速・高可用な業務システムを作りやすいものの、成否を分けるのはアクセスパターンに基づくデータ設計です。

セッションやカート、予約、IoTの最新状態に向いており、イベント管理にも合います。一方、自由検索や複雑な帳票では、RDBや分析基盤との分担を検討します。

開発費やAWS利用料、保守費、移行費を分けて考えます。そのうえで、RTO・RPOやセキュリティ、復元試験も含めて判断します。

導入前に確認する3つの要点

導入前は、アクセス設計と非機能要件、委託範囲を、設計書と提案書で確かめます。

• アクセス設計：画面・API・バッチのパターンから、主キーやソートキー、GSI、項目サイズを決めます。
• 非機能要件：ピーク負荷、RTO・RPO、個人情報、保存期間、監視・復元手順を数値で示します。
• 委託範囲：提案書と見積書で、設計や移行、試験、IaC、教育、保守の責任をどこまで負うかを比べます。

最初の一歩は小さなPoCと設計レビュー

全社データを一度に移すのは避けて、代表的な業務フローを一つ選びます。PoCでは、アクセスパターンやピーク負荷、競合更新を確かめるほか、復元と料金も確認します。

測定結果と業務要件をもとに、DynamoDB単体、RDBとの併用、段階移行のどれにするかを判断します。判断の基準は、技術の新しさより、業務価値と運用可能性に置きます。そうすれば、長く使える基盤につながります。

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

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