OpenID Connect（OIDC）のシステム開発は、認証方式、会員データ、接続するチャネル、運用体制を整理すると、導入方式と設計を判断できます。
技術担当者は方式と設計を、稟議やRFPを担う事業責任者は製品料金と開発費を分けて見るとよいでしょう。詳しくは関連記事もご覧ください。
▼関連記事一覧
・OpenID Connectのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・OpenID Connectのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・OpenID Connectのシステム開発の見積相場や費用/コスト/値段について
・OpenID Connectのシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
OpenID Connectのシステムの全体像
OpenID Connect（OIDC）は、ログインした人が誰であるかをアプリケーションへ伝える標準仕様です。OpenID Provider（OP）が認証し、Relying Party（RP）がその結果を使うという役割分担によって、複数のサービスに同じ認証基盤を適用できます。
導入の目的は、IDの発行、検証、更新、失効、監査を一貫したルールで運用することにあります。ログイン画面の数を増やすことではありません。
OIDCの認証とOAuth 2.0の認可の役割
OAuth 2.0は、アプリがAPIやデータへアクセスする権限を委任するための枠組みです。OIDCは、このOAuth 2.0の認可フローに認証の仕組みを加え、ユーザーを表すIDトークンを返すようにしたものです。
IDトークンは認証の結果を示し、アクセストークンはAPIへのアクセス権を示します。両者は示す意味が違うため、ログインの確認にアクセストークンを代用するのは避けます。
OP・RP・IDトークンの役割分担
OPは、ユーザーを認証してIDトークンを発行するサーバーです。RPは、EC、アプリ、店舗端末、管理画面などで、OPへ認証を依頼するサービスです。
認可コードフローでは、まずRPが認証要求をOPへ送り、ユーザーがOPで認証します。RPは受け取ったコードをトークンへ交換します。
RPは、署名、issuer、audience、有効期限、nonceなどを検証してログイン状態を作ります。さらに、役割を明文化すると、会員DBや業務データ、権限判定の管理場所も整理できます。
OAuth 2.0やSAMLとの違い
OIDCとOAuth 2.0は、Web、スマートフォン、APIを組み合わせるサービスで扱いやすい仕様です。一方で、SAMLはXML形式のアサーションを使う認証連携です。
SAMLは、企業間のシングルサインオンや既存の業務システムで広く使われています。選ぶときは、接続先の仕様、利用者、既存資産を見ます。スマートフォン対応や運用体制も合わせて判断します。
たとえば、顧客向けのサービスではOIDC、従業員向けの既存業務連携ではSAMLも候補になります。
OIDCシステムの典型構成と必要な機能
典型的な構成では、ブラウザやスマートフォンからRPへアクセスし、RPがOIDC認証基盤へリダイレクトします。認証が済むと、会員情報や業務APIへ接続する流れになります。
認証基盤の導入の先には、顧客データの統合が残ります。会員マスターや注文、ポイントについては、どのシステムを正とするかを先に決めておきます。
予約、問い合わせ、同意情報についても、正となるシステムを定めます。また、認証IDと業務上の顧客IDを安全に対応付ける設計も欠かせません。
CIAMによるEC・店舗・アプリの接続
顧客向けのID基盤は、CIAM（Customer Identity and Access Management）として設計します。そのうえで、次のチャネルを共通の認証基盤へつなぎます。
- EC・アプリ：ECサイトと会員アプリの接続
- 店舗・予約：店舗の会員証と予約サービスの接続
- 顧客対応：コールセンターとキャンペーンサイトの接続
同じ認証基盤を使えば、ユーザーはチャネルごとにパスワードを作らずに済みます。企業側も、重複会員や退会済みアカウントを減らせます。さらに、同意に基づく連絡も行いやすくなります。
メールアドレスだけで同一人物と判定すると、変更、重複、共有アドレスによる誤統合が起きやすいため、注意が必要です。
登録・ログイン以外に必要な機能
運用機能には、登録、メール確認、パスワードリセットがあります。外部IdP連携、MFA、パスキー、アカウント統合も含まれます。退会や同意撤回、トークン失効に加え、監査ログ、レート制限、異常ログイン検知も検討します。
認証に成功しても、管理画面の閲覧権限やポイント操作の権限を自動で付与してはいけません。そのため、認証は本人確認、認可は業務上の操作許可として分けて扱います。さらに、ロールやスコープはサーバー側で検証します。
issとsubの組み合わせによる外部識別子の管理
メールアドレスは変更や共有が起きるため、業務上の主キーにはしません。代わりに、発行者を示すissと、発行者の中で一意なsubを、外部識別子として保存します。
複数のIdPを使う場合は、claimsの名称、型、信頼度を正規化します。そのうえで、同一人物の統合には本人確認や再認証を組み合わせます。
退会・削除やマーケティング利用の同意は、顧客データの業務設計に反映します。国外委託や保存期間についても、業務設計に組み込みます。
OpenID Connectのシステム開発方式の4種類
開発方式は、認証基盤を自社でどこまで持つかによって変わります。方式の選び方は、初期費用に加え、脆弱性対応や鍵更新、障害対応、料金にも影響します。
認証プロトコルは標準仕様の基盤を使い、会員統合や業務認可など自社固有の領域に開発費を配分するのが一般的です。
クラウド型・IDaaSを利用する方式
クラウド認証サービスは、登録、ログイン、MFA、外部IdP連携、監視などを短い期間で導入できるのが特徴です。
導入前には、MAUや認証回数に応じた従量課金とデータ所在地を確認します。さらに、サポート、障害時のSLA、設定のエクスポート可否も見ておきます。
開発の対象は、RP側の画面やセッション、会員連携、claims変換、業務システムへの接続です。料金の上昇やサービス変更に備えるなら、標準OIDCの接続層を自社側に設けておくと、移行がしやすくなります。
OSS・商用製品を自社運用する方式
OSSや商用製品は、自社クラウド、オンプレミス、ハイブリッド環境のいずれでも運用できます。画面や認証ポリシーの自由度が高いため、データの配置やネットワーク要件にも対応できる方式です。
ただし、バージョンアップや脆弱性情報の収集は、自社の責任で行います。冗長化、バックアップ、鍵管理、性能試験も、自社で担う作業です。
導入の判断は、ライセンス費だけでなく、専門人材、監視、夜間対応、障害訓練を含めた総保有コストで行います。
認証認可機能をAPIとして組み込む方式
認証認可サーバーをAPIとして組み込み、独自の会員画面や会員DBを活用する方式です。高度なclaims、複雑な同意、独自の本人確認、金融・決済などの高い安全要件に対応できます。
その分、要件定義と実装の責任範囲は広がります。RPごとの個別実装を避けるため、認証共通部品、標準エラー、ログ仕様、テスト用テナントを整えます。
認証基盤そのもののスクラッチ開発の判断
認証サーバーを一から開発すると、製品にない要件へも対応できそうに見えます。しかし、認可コードやトークン検証、失効を含む一連の処理を、鍵更新や攻撃対策も含めて長期に維持する必要があります。
認証専門のチームがない場合は、リスクが高くなります。そのうえで、自社で作る場合は、適合させる範囲を定めます。対象は、OIDC Core、OAuthのセキュリティベストプラクティス、必要に応じてFAPI 2.0です。
第三者レビューと継続的な脆弱性診断も、予算に含めます。
OpenID Connectのシステム開発の進め方
OIDCの開発は、ログイン画面を作れば終わるものではありません。まず、利用者、チャネル、IDの正、移行対象、障害時の業務継続を決めておきます。
そのうえで、仕様設定と画面を実装します。小さく接続して検証し、会員統合と運用が固まってからチャネルを広げると、全チャネル停止のリスクを抑えられます。
▶ 詳細はこちら：OpenID Connectのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
1. 要件定義で決める利用者とIDの正
要件定義では、利用者、チャネル、認証要件、見積条件、接続仕様、ID管理の順に整理します。
- 利用者：顧客、従業員、取引先、ゲストの区分
- チャネル要件：EC、アプリ、店舗端末、コールセンター、管理画面ごとの認証強度、MFA、セッション時間、ログアウト、権限
- 見積条件：月間アクティブユーザー、ピーク時の認証回数、既存会員数、外部IdP数の把握
- 接続仕様：接続先の仕様の確認と、仕様書への記載
- ID管理：認証IDと顧客マスターIDの対応、重複時の扱い、退会時の削除範囲、同意の保存先の決定
接続仕様書には、Discoveryのwell-known URL、issuer、authorization endpointを記載します。加えて、token endpoint、userinfo、JWKS、scope、claims、redirect URIも記載します。
これらの条件がそろうと、料金と性能を見積もりやすくなります。特に、国内のデジタル認証API仕様には、認可コードとopenidスコープを前提とする例もあります。そのため、接続先の必須条件を確認します。
2. 設計・開発での認証と業務認可の分離
認証基盤と各RPで、どこまでを誰が受け持つかを決めたうえで、次の処理と安全策を実装します。
- コード交換：RPが認可コードを受け取り、code_verifierを使ってトークンへ交換する処理
- トークン検証：署名、issuer、audience、nonce、有効期限の確認
- セッション管理：Cookie属性、トークンの保管、アクセストークンの用途、更新トークンの失効方法の決定
- 公開クライアント：PKCEの利用、stateによる要求と応答の関連付け、nonceによるリプレイやコード差し替えの検知
認証に失敗した場合は、安全なエラー画面へ遷移させます。さらに、ブラウザへ長期間のトークンを露出させない設計が基本です。
IETFのRFC 9700は2025年1月公開で、Implicit Grantを原則として避け、認可コードフローを使う考え方を示しています（出典：IETF RFC 9700、2025年）。
3. テスト・会員移行・リリースの段階化
テストや会員移行、リリースは、段階を追って確認します。
- 認証テスト：署名鍵の更新、issuer・audienceの不一致、期限切れ、nonceの不一致、redirect URIの誤り、認証キャンセル
- 障害・攻撃テスト：IdP障害、ネットワーク遅延、アカウント列挙、トークン漏えいの試験
- 高保証要件：本人確認が重要なサービスや決済APIにおける、FAPI 2.0 Security Profileの適用範囲の検討
- 会員移行：直接移せない場合の、初回再認証、メール確認、段階的な更新、問い合わせ時の本人確認の組み合わせ
- 段階リリース：旧ログインとの並行、ロールバック、窓口、監視の用意と、一つのブランドやアプリでの検証後に広げる進め方
FAPI 2.0 Security Profileは2025年2月にFinalとなりました（出典：OpenID Foundation「FAPI 2.0 Security Profile」、2025年）。
OpenID Connectのシステム開発費用相場と期間
OIDCの受託開発費を横断的に比べられる公的統計は、確認できません。そこで、この目安は、RP数、会員移行、MFA、監視、セキュリティ試験を含む一般的な開発規模から算出したものです。
認証基盤の利用料と受託開発費は、別々に見る必要があります。MAUに応じて利用料が増えるサービスもあるため、初期費用だけで判断しないようにします。
▶ 詳細はこちら：OpenID Connectのシステム開発の見積相場や費用/コスト/値段について
▶ 詳細はこちら：OpenID Connectのシステム開発の発注/外注/依頼/委託方法について
規模別の開発費の幅（100万円から5,000万円以上）
開発費と期間は、PoCから大規模移行まで、対象範囲によって異なります。
- 1アプリのPoC：100万〜300万円、1〜2か月。
- EC単体の本番導入：300万〜800万円、2〜4か月。
- 標準CIAM：800万〜2,000万円、4〜8か月。
- 大規模移行：2,000万〜5,000万円以上、6〜12か月となる場合があります。
PoCでは、認可コードフロー、PKCE、IDトークン検証、簡易監視を確認します。一方で、EC導入には既存会員連携、メール確認、パスワードリセット、基本的な監査ログが含まれます。
EC、スマートフォンアプリ、店舗会員をつなぐ標準CIAMには、会員ID統合、CRMやポイント連携、MFAが含まれます。
さらに、同意管理、負荷試験、運用設計も含みます。費用は、RP数とデータ移行の難しさによって変わります。
大規模移行の場合は、複数ブランドや数百万会員、レガシー認証からの段階移行を含むことがあります。加えて、24時間監視、冗長化、セキュリティ診断が含まれる場合もあります。
全社共通IDや基幹データ統合まで含めると、5,000万円から1億円を超えるケースもあります。
利用料・保守費・周辺費用の分け方
初期開発費、サービス利用料、周辺費用は、分けて見積もります。
- 運用保守：初期開発費の年15〜25％程度の仮置き
- 周辺費用：メール・SMS、WAF、ログ保管、監視、脆弱性対応、証明書・署名鍵運用の別枠計上
- 従量料金の例：直接・ソーシャルログインは月10,000人まで無料、OIDC・SAML連携は月50人超の分が1MAUあたり0.015米ドルです。
- 年契約の例：別サービスのエンタープライズ基盤は月額3,000米ドルからです。
従量料金の例は、認証サービス公式料金表に基づきます（出典：認証サービス公式料金表、2026年8月確認）。
別サービスの価格は年契約の場合です（出典：顧客向け認証サービス公式料金表、2026年8月確認）。料金体系は、ティアや契約条件で変わります。そのため、見積時点の公式料金表で再確認します。
これらはサービス利用料の例で、アプリ改修、会員移行、データクレンジング、診断費は含みません。加えて、為替とMAUの季節変動も考慮し、繁忙期を含む年間利用量で試算します。
公開事例の位置づけ（条件付きの参考値）
公開事例の対象は、14のデジタルサービスと200万人超の利用者を持つ大手ペットケア企業です。
- 導入内容：クラウド認証機能を中核にしたSSO基盤の構築
- 適用期間：一つのアプリへの4か月での適用
- 報告された効果：第三者製品の提案額と比べた80％のコスト削減
これらは、クラウド基盤提供者による報告です（出典：クラウド基盤提供者の公式事例、2026年8月確認）。既存クラウドの知識、対象範囲、内製人材、構成が異なるため、一般的な相場としてそのまま使えません。
自社の見積では、同じ削減率を前提にせず、対象範囲と前提条件を比べます。
OpenID Connectの開発会社/ベンダーの選び方
開発会社を選ぶ際は、OIDCの接続実績に加えて、EC会員、アプリ、店舗、CRMをまたいだID設計を任せられるかを見ます。
製品を提供する会社と、要件定義や連携実装、移行、運用を担う会社では、役割が異なります。そのため、契約の範囲を分けて、要件への適合性を比べます。
類似チャネルと会員移行の実績の確認
OIDCを使った実績は、選定材料として不十分です。そのため、EC、モバイル、店舗端末、コールセンターなど、似たチャネル構成の事例を確認します。
会員数やMAU、外部IdP数について、どこまで担当したかを質問します。さらに、MFA、パスワード移行、同意管理、障害時の代替ログインについても、担当範囲を尋ねます。
可能なら、匿名化された構成図、移行計画、テスト項目、運用引き継ぎ資料も確認します。
技術仕様とセキュリティ試験の範囲
提案書では、認可コードフロー、PKCE、state、nonceが盛り込まれているかを確認します。加えて、JWKS更新、issuer・audience検証が盛り込まれているかも確認します。ログアウト、トークン有効期限、MFA、レート制限については、実装と試験の内容を見ます。
そのほか、redirect URIをワイルドカードで許可していないか、claimsに個人情報を過剰に含めていないか、ログにトークンやパスワードを残していないかも見ます。
特に、高い安全性が必要な場合は、脆弱性診断、第三者レビュー、FAPI 2.0の適用範囲を見積書に明記してもらいます。
運用体制・SLA・引き渡し条件の比較
認証障害は複数のチャネルに影響するため、開発力だけでなく運用体制も確認します。契約やSLAでは、次の条件を定めておきます。
- 障害対応：監視対象、通知先、一次対応時間、復旧目標、障害訓練の取り決め
- 保守責任：鍵・証明書の更新担当と、脆弱性対応の期限の決定
- 引き渡し：設定値、ソースコード、テストデータ、構成図、ログ仕様、移行手順の納品
特定の担当者しか運用できない状態を避けるため、引き渡しの範囲を契約で明確にします。
▶ 詳細はこちら：OpenID Connectのシステム開発でおすすめの開発会社/ベンダー6選と選び方
OIDCシステムのセキュリティと運用の注意点
安全な業務システムにするには、OIDCへの準拠に加えて、認証基盤、RP、API、会員DB、管理者権限、監視を一体で見ることが欠かせません。攻撃や障害が起きる境界も、ここで洗い出します。
あわせて、個人情報保護委員会のガイドラインにある、アクセス者の識別・認証、アクセス制御、不正アクセス防止、通信暗号化、ログ分析に相当する対策も確認します。
トークンと署名鍵の長期運用
署名鍵は、公開鍵を含むJWKSとして配布します。そのうえで、鍵の追加、切り替え、旧鍵の廃止を計画します。RP側で一時的な検証に失敗するのを防ぐため、JWKSのキャッシュと再取得も設計します。
トークンの扱いでは、ID・アクセストークンの保存先とログへの出力禁止を決めます。有効期限は短くし、更新トークンの失効方法や、端末紛失時の再認証も定めます。
ログには、認証イベント、結果、失敗理由、相関IDを残します。一方で、トークンや不要な個人情報は記録しません。
認証障害への代替手段
認証基盤への集約はログイン体験を改善しますが、障害が全チャネルへ広がるおそれもあります。そのため、障害時に既存セッションを維持する範囲、店舗業務の継続方法、問い合わせの受付、復旧後の不整合確認を決めておきます。
可用性は、サーバーの冗長化に加えて、認証基盤、ネットワーク、外部IdP、メール送信、会員DBの依存関係まで評価します。
claimsと同意情報の最小化
名前、メール、生年月日、住所などのclaimsは、RPが必要とする範囲だけ渡します。不要な属性を全チャネルへ配布すると、漏えい時の影響が大きくなるためです。
マーケティング利用の同意と、ログインに必要な規約への同意は、目的を分けて扱います。そのうえで、取得日時、版、撤回日時、連携先を追跡できるようにします。
退会時に、ID無効化と業務データの保存義務が異なるケースでは、削除、匿名化、保持のルールを項目ごとに定めます。
OIDCシステム開発で起きやすい失敗と対策
OIDCを導入しても、安全性が自動的に高まるとは限らず、会員データが一つにまとまるわけでもありません。仕様の検証やID統合のルール、運用責任が不足していると、問題につながります。
失敗パターンを先にRFPとテスト計画へ盛り込めば、開発会社との認識の差を減らせます。
ログインだけを先に統合したことによるデータの分断
ログインを一つにしても、注文、ポイント、予約、問い合わせ履歴は自動では統合されません。メールをキーに急いで統合すると、家族共有、変更前後、重複登録などで誤結合が起きます。
ID統合では、issとsubを保存したうえで、業務上の顧客IDとの対応、統合候補の確認、本人によるアカウント連携、統合解除の手順を設計します。
低コストのPoCのまま本番要件が膨らむリスク
一画面のログインに成功しても、MFA、外部IdP、会員移行、ピーク負荷、ログ保管、障害時の代替まで検証したとは限りません。
PoCを始める時点で、本番への判定条件を決めておきます。そのうえで、次の検証を完了条件に含めます。
- 署名検証：異常系を含めた試験
- 鍵更新：切り替え時の動作の確認
- 会員処理：退会とアカウント統合の確認
- 運用確認：監査ログと復旧訓練を含めた確認
小さく始めることと、要件を小さく見積もることは、別に考える必要があります。
開発後の鍵・設定・障害対応の担当者未定
認証基盤は、一度作れば終わるものではありません。鍵や証明書の更新、IdP仕様の変更、SDKの脆弱性、ログ保存、MAU課金の増加などを、継続して管理していきます。
開発会社が初期構築だけを担う場合は、社内の担当者、一次窓口、緊急時の連絡、月次レビューを決めておきます。運用設計を見積から外すと、障害時に判断できない状態になりやすくなります。
OpenID Connectのシステムに関するよくある質問
導入前によく尋ねられる認証方式、費用、既存会員、セキュリティを、ここでまとめます。利用者体験と業務継続も、あわせて確認します。
OpenID Connectを導入すると何ができますか？
EC、アプリ、店舗会員、予約などを一つの認証基盤へ接続すると、SSOや共通MFAを提供できます。
ただし、ログインを統合しても、注文やポイント、同意情報までは統合されません。IDと業務データの対応関係、権限、退会処理は、別途設計する必要があります。
OIDCシステムの開発費用はいくらですか？
目安は、1アプリのPoCが100万〜300万円、EC単体の本番導入が300万〜800万円、EC・アプリ・店舗を含む標準CIAMが800万〜2,000万円程度です。
複数ブランドや数百万会員を移行する場合は、2,000万〜5,000万円以上になることもあります。利用料、メール・SMS、監視、診断、保守費は、これとは別です。
そのため、MAUとピーク時の利用量を含めた年間見積を取得します。
既存会員のパスワードは移行できますか？
移行できるかどうかは、移行先と移行元の認証方式やパスワードハッシュの互換性によって異なります。直接移行できない場合は、初回ログイン時の再認証、メール確認、更新、本人確認を組み合わせます。
移行期間中は、旧ログインを残しておきます。そのうえで、重複会員、移行失敗、退会済みアカウントの扱いを試験してから、本番へ進みます。
OIDCならセキュリティ対策は不要ですか？
対策は必要です。たとえば、認可コードフロー、PKCE、state、nonceを使います。署名・issuer・audience検証も行います。加えて、JWKS更新、TLS、MFA、レート制限、監査ログも適切に実装します。
認証後の業務認可も、サーバー側で確認します。そのうえで、claimsの最小化、個人情報の保管、障害時の代替、脆弱性診断まで含めて評価します。
まとめ
OIDCは、OAuth 2.0を基盤に認証情報を標準化する仕組みです。EC、アプリ、店舗、管理画面などを、一つのIDで連携できます。
効果を得るには、認証と認可を分けます。そのうえで、issとsubによるID設計、会員移行、同意管理、障害時の運用まで、一体で計画します。
最初に決める利用者・チャネル・IDの正
クラウド型、IDaaS、OSS・商用製品、自社組み込みは、MAU、RP数、既存会員数で比べます。そのうえで、MFA、外部IdP、データ所在地、SLA、保守範囲も含めて確認します。
PoCは小さく始めても構いませんが、PKCE、鍵更新、異常系、移行、監視は完了条件に含めます。製品料金と開発・保守費を分けて年額を見積もると、稟議やRFPで説明しやすくなります。
RFPでの実装・移行・運用の責任分界
提案依頼では、redirect URI、issuer、audience、nonceについて質問します。state、PKCE、JWKS更新の扱いも尋ねます。そのほか、トークン有効期限、会員統合、同意、ログ保持、障害対応も確認します。
設定やソースの引き渡し方法も確認します。そのうえで、OIDCの実装力だけでなく、障害が事業に与える影響を理解し、継続運用まで設計できるパートナーを選びます。
▼関連記事一覧
・OpenID Connectのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・OpenID Connectのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・OpenID Connectのシステム開発の見積相場や費用/コスト/値段について
・OpenID Connectのシステム開発の発注/外注/依頼/委託方法について
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。