多要素認証システム開発では、認証方式、アクセス権限、復旧・監査を一体で設計すると、業務上のリスクに応じた本人確認につながります。
認証方式の違いから導入の進め方、費用、開発会社の選び方まで、一通りの論点をたどれます。各テーマの詳細は、関連記事もあわせてご覧ください。
▼関連記事一覧
・多要素認証システム開発の進め方/やり方/流れや方法/手法/工程/手順
・多要素認証システム開発でおすすめの開発会社/ベンダー6選と選び方
・多要素認証システム開発の見積相場や費用/コスト/値段について
・多要素認証システム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
多要素認証システムの定義
多要素認証システムは、利用者が本人であることを複数の異なる種類の証拠で確認し、確認結果に応じて業務システムへのアクセスを許可する基盤です。
二要素認証は多要素認証の一部です。たとえば、パスワードと認証アプリのワンタイムコードを組み合わせる方式などが該当します。
パスワードだけでは不十分になった背景
パスワード単独の弱点と、多要素認証で補える範囲を比べます。
- パスワードの弱点：使い回し、推測、漏えい、フィッシング窃取が起きやすい
- 追加認証の効果：別の要素がなければ侵入の難度を高められる
ID・パスワードが攻撃者の手に渡ると、正規の利用者と同じ入口から侵入されます。そのため、ネットワークの境界だけで防ぐ考え方には限界があります。
IPAの注意喚起では、2025年7月に不正ログインの相談が144件寄せられ、パスキーや多要素認証の設定が推奨されています（出典: IPA「インターネットサービスへの不正ログインによる被害が増加中」、2025年）。
パスワードが漏えいしても、登録済みの端末やセキュリティキーを攻撃者が持っていなければ、侵入を防ぎやすくなります。ただし、方式によってフィッシングへの強さや利用者の負担は異なり、安全性も一律ではありません。
認証・認可・監査の役割分担
多要素認証が確認するのは、基本的に「誰がログインしたか」です。認可と監査は、認証とは別の役割を持ちます。
- 認証：異なる要素でログイン時の本人確認を強める
- 認可：閲覧、承認、削除できる範囲を定める
- 監査：操作の証跡を残す
認証に成功した利用者へすべての権限を与えると、アカウント乗っ取り時の被害が大きくなります。そのため、役割、対象データ、操作の重要度ごとに権限を分けておきます。
たとえば、契約担当者は閲覧できても、削除には管理者による再認証を求める設計が可能です。外部の専門家や取引先のアカウントは、利用期間を限定し、組織を離れた時点で自動的に無効化します。
ログには、誰が、いつ、どの端末や接続元から、どの方式で認証し、どの操作が成功または失敗したかを残します。後から事実関係を確認できるよう、こうした記録を用意しておきます。
多要素認証システムの種類と認証方式の違い
認証方式を選ぶときは、安全性だけでなく、利用者の端末や業務場所に合うかを見ます。通信環境や復旧方法、費用も評価します。
管理者や契約承認者など高リスクの利用者には、入力コードを盗まれにくい方式を優先します。一方で、一般利用者は移行しやすい方式から段階的に強化します。
三つの認証要素と二要素認証の違い
多要素認証では、性質の異なる情報を組み合わせます。
- 知識情報：本人だけが知っている情報
- 所持情報：本人が持っている端末やキー
- 生体情報：本人の身体的特徴
パスワードとPINはどちらも知識情報なので、両方を併用しても多要素にはなりません。多要素にするには、認証アプリのコードやセキュリティキー、端末の生体認証など、異なる種類の情報と組み合わせます。
端末の生体認証は、端末内部で秘密鍵の利用を解除する仕組みとして使われる場合があります。この方式では、生体情報をサーバーへ送らず、端末内の認証器と公開鍵暗号で確認します。安全性は方式名では決まらないため、情報の保存先と成功判定も確認します。
SMS・TOTP・プッシュ通知・パスキーの比較
方式ごとの仕組みを比べ、自社の端末や通信環境に合うものを選びます。
- SMS：携帯電話番号へコードを送る
- TOTP：認証アプリが一定時間ごとにコードを生成する
- プッシュ通知：端末に届く承認要求を操作する
- パスキー・FIDO2：ドメインと公開鍵暗号を結び付ける
SMSには、SIMスワップや電話番号の再利用、メッセージの盗み見といったリスクがあります。また、TOTPは偽サイトへコードを入力すると、そのコードを中継される可能性があります。
プッシュ通知は操作が簡単ですが、大量の承認要求を送るプッシュ疲労攻撃への対策が必要です。対策としては、番号一致、端末情報の表示、異常な回数の検知を組み合わせます。なお、FIDO2は偽サイトに強い方式です。
NISTの2025年版ガイドラインでは、手入力OTPはセッションに結び付かないため、フィッシング耐性方式とは扱われていません（出典: NIST SP 800-63B-4、2025年）。
2026年時点で有力なのは、一般利用者の導入負担を抑えつつ、高リスク操作ではパスキーを優先する設計です。対象には管理者、特権ID、契約承認などがあります。
デジタル庁の2026年資料では、パスキーをドメインに結び付いた公開鍵暗号の認証と説明しています。また、パスワードとワンタイムパスワードは別の手法に整理されています（出典: デジタル庁「本人確認ガイドラインの改定」、2026年）。
多要素認証システムの基本構成と必要な機能
多要素認証システムには、ログイン画面に加えて、利用者と組織のID基盤や業務アプリへの認証結果連携が必要です。さらに、条件付きアクセスやログ監視、登録・紛失・退職時の管理も整えておくと、継続して利用できます。
ID管理と業務システム連携
ID管理と業務システム連携では、IDをいつ作り、いつ止めるかと、アプリごとの連携方式を先にそろえます。
- IDのライフサイクル：発行から停止・削除までを管理する
- アプリ連携：方式と改修範囲をアプリごとに整理する
対象は、社員や派遣スタッフ、取引先、外部専門家、管理者、サービスアカウントなどです。入社、異動、委託開始、契約終了、退職といったイベントを起点に、人事・契約管理の情報と同期する構成を検討します。手作業で登録を続けると、退職者の残存IDや不要な特権が生まれます。
連携方式には、OIDCやSAMLによるシングルサインオン、SCIMによるユーザー・グループ同期、LDAPや既存ディレクトリとの連携があります。
古いWebアプリやVPN、リモートデスクトップ、クライアントサーバー型のシステムは、標準連携だけでは対応できない場合があります。そのため、停止可能な時間とテスト環境の有無も確認します。
条件付きアクセスとログ監視
条件付きアクセスは、利用者や端末、接続環境（場所・時間帯・接続元）、操作内容、リスクスコアに応じて、認証強度を変える機能です。
- 通常業務：社内の管理端末なら追加認証を省く
- 高リスク操作：未知の端末なら契約書取得時にパスキーと再認証を求める
ログには、認証の成功と失敗、登録と削除を残します。さらに、復旧や管理者操作、権限・ポリシーの変更も記録します。
保存期間や改ざん防止、検索性を、あらかじめ決めておきます。監視担当と異常時の通知先も定め、必要に応じてSIEMや監視基盤へ転送します。
異常を見逃さないためには、ログの確認体制も必要です。短時間の失敗の増加、普段と異なる国や端末、深夜の特権操作などを、誰が確認し、どの基準でアカウントを停止するかまで運用設計に含めます。
多要素認証システムの開発・導入の進め方
導入は、製品を契約して一斉に有効化するより、対象とリスクを絞って段階的に進める方が安全です。まず現状把握とリスク分類を行い、方式選定と要件定義へ進みます。
導入では、設計・連携の後にパイロットを行い、段階展開と運用改善へ進めると、認証強化と業務継続を両立しやすくなります。
▶ 詳細はこちら：多要素認証システム開発の進め方/やり方/流れや方法/手法/工程/手順
要件定義で決めるべき項目
要件定義では、利用範囲と運用の前提を、3つの軸で整理します。
- 対象：利用者、アプリ、データ
- 認証と例外：必要な強度、許容範囲、再認証条件
- 運用：ログ保持、復旧方法、可用性、データ保管先
特に、誰にMFAを求めるかに加えて、どの端末を信頼するか、認証器を何個まで登録できるかを具体的に決めます。
MUSTとWANTを分け、初期段階のMUSTには、管理者・リモートアクセス・契約承認者の強化、退職者の自動停止、監査ログ、緊急復旧を置きます。
全アプリの自動プロビジョニングや高度なリスク分析は、第2段階へ回します。要件を広げすぎると、連携先とテストケースが増え、納期と費用も膨らみます。
設計・開発・テストの確認事項
設計と検証で詰める内容は、大きく三つに分けて確認します。
- 設計範囲：画面、API、セッション、失敗時の扱い
- 脅威への備え：認証情報や鍵、リプレイ、CSRF
- テスト範囲：通常時と例外時の復旧・運用
設計時には、トークン、有効期限、レート制限、ロック条件、復旧フローを定義しておきます。独自開発の場合は、秘密情報の保存や鍵のローテーション、セッション固定、アカウント列挙への対策も必要になります。一方、標準機能を使う場合でも、初期登録画面や管理者向け画面の作り込みは残ることがあります。
テストは正常系だけでなく例外系も対象にします。例外系には、端末紛失や機種変更、圏外、認証器の故障、時刻ずれがあります。さらに、退職者や共有ID、サービスアカウント、管理者不在、外部利用者の契約終了も含めます。
復旧できることと、復旧の手続きが攻撃者に悪用されないことは、別々に確認します。また、パイロットでは、利用率、問い合わせ件数、認証失敗率、復旧にかかった時間を測り、本番展開の判断材料にします。
パイロットから段階展開への移行
対象を絞って展開し、利用環境の準備と旧方式の終了条件をそろえます。
- 対象の順序：高リスク利用者から標準連携アプリへ広げる
- 展開準備：登録案内、予備認証器、窓口、緊急管理者を用意する
- 旧方式の終了：期限、例外承認者、解除条件を定める
高リスクの対象には、管理者や特権ID、リモートアクセス、機密情報を扱う部署などがあります。次の段階では、業務への影響が比較的少なく、標準連携できるアプリへ広げます。紛失時の連絡先は、全社展開の前に利用者へ知らせておきます。
古い方式を無期限に残すと、攻撃者に弱い経路を選ばれてしまいます。そこで、移行期間は対象者と監査方法を台帳で管理し、未登録者を追跡します。利用率が低い場合は、方式を強制する前に、登録画面や案内文、サポート体制を確認します。
多要素認証システムの費用相場とコストの内訳
費用は、サービス料金と導入・開発費に分けて考えます。金額は、ユーザー数や月間アクティブユーザー数、連携アプリ数で変わります。さらに、SMS送信数や端末配布数、ログ量、改修範囲、運用時間でも変わるため、月額の料金だけを見ると予算が不足しがちです。
▶ 詳細はこちら：多要素認証システム開発の見積相場や費用/コスト/値段について
初期費用の目安と前提条件
2026年時点で、相見積もりの前に置いておく推定レンジです。費用は、構成と実装範囲によって変わります。
- ID基盤への設定：既存環境の設定で30万〜150万円
- 標準連携：主要アプリ数本とディレクトリ連携で100万〜500万円
- 統合認証：複数拠点・数千ユーザー・レガシーを含み500万〜1,500万円
- 独自開発：顧客向けAPI等を含み1,500万〜4,000万円以上
これらは、一般的な業務システムの工数相場や連携数、セキュリティ要件をもとに整理した推定値で、MFA単独の全国統計ではありません。独自開発の対象には、管理画面、パスキー、監査、高可用性などがあります。
設定中心は2〜8週間、標準連携は1〜3か月、複数拠点統合は3〜6か月、独自開発は6〜12か月以上が想定期間です。対象アプリや例外運用を増やすほど、費用とテスト期間が伸びます。
ライセンス・SMS・保守などの継続費
料金体系と継続費を見積もるときは、課金条件を見比べます。
- 上位プラン：1人あたり月899円相当（出典: 認証基盤サービスの公式価格表、2026年確認）
- 別IDaaS：1人あたり月940〜2,670円のプラン例
- 顧客向け認証：SMS送信ごと、または月間アクティブユーザー数で課金（出典: クラウド型認証サービスの公式料金表、2026年確認）
- 保守：初期開発費の年5〜15％を仮置きする例
1,000ユーザーなら月額約89万9,000円の単純計算ですが、既存契約への内包、年間契約、税、追加機能で実額は変わります。
SAML・OIDC連携のほか、認証器や端末管理、ログ保存、監視も初年度総額の計算に入れます。さらに、脆弱性対応、問い合わせ、年次監査も加えます。
24時間監視、緊急対応、第三者評価、認証器交換、SMS従量費は別途見積もります。初期費用、月額固定費、従量費、追加開発費、運用人件費を分けて提示してもらうと、比較しやすくなります。
多要素認証システムの開発会社/ベンダーの選び方
開発会社・ベンダーを選ぶときは、認証製品の機能数よりも、自社のID、業務アプリ、利用者、運用体制に合わせて、安全に定着させられるかを確認します。
製品を提供する会社と、要件定義や連携開発、移行、教育、保守を担う会社は、役割が異なる場合があります。そのため、契約書と体制図で担当範囲を明らかにします。
技術適合性と実装範囲の確認
提案先の実装力は、連携、復旧、監視の範囲で見ます。
- 既存環境との連携：認証規格、VPN、レガシー、端末管理
- 利用者の復旧：再登録、端末交換、緊急アクセス
- 監視への引き渡し：SIEM用ログの項目、検索、欠損対策
候補先には、OIDCやSAML、SCIM、LDAP、既存ディレクトリ、APIとの連携経験を確認します。あわせて、パスキーやFIDO2への対応も聞いておきます。
ログをSIEMへ送る場合は、時刻の扱いと保持期間を確認します。また、提案書には、標準機能、設定、追加開発、利用者教育、移行支援、保守の区分を明記してもらいます。
特に「対応可能です」と答えられた場合でも、どの方式で、どのアプリを、どの環境で、誰が、何日かけて検証するかまで具体化してもらいます。類似規模の導入で、認証失敗率や問い合わせ件数、切り戻し手順をどう管理したかも、評価の材料になります。
見積もりと契約での失敗の防止
価格と契約条件は、同じ前提と担当範囲で比較します。
- 見積もり条件：利用者数、アプリ、方式、移行、テスト、運用
- 費用内訳：工程別金額と前提外の追加単価
- 契約範囲：成果物、障害対応、データ返却・削除
相見積もりでは、SMS件数や認証器、教育、運用時間も同じ条件で提示してもらいます。要件定義、設計、開発、テスト、移行、保守の金額は工程ごとに比べます。クラウド料金とSI費用を分けることが、初年度総額の比較には欠かせません。
契約では、仕様や設定、テスト結果を明確にします。ログ設計、運用・教育資料、引き渡し条件も含めて決めます。再委託や秘密情報、脆弱性対応についても、取り決めておきます。
要件が固まっていない調査・設計は準委任、仕様が確定した連携開発は請負など、工程に応じて契約形態を分ける方法もあります。
▶ 詳細はこちら：多要素認証システム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：多要素認証システム開発の発注/外注/依頼/委託方法について
導入後の運用・法務・監査の確認事項
多要素認証システムは、導入日に完成するものではありません。利用者の入れ替わりや端末の紛失、認証方式の陳腐化、攻撃手法の変化に合わせて、登録情報や権限、ポリシー、ログ、復旧手順を見直していきます。
運用責任者、システム管理者、ヘルプデスク、セキュリティ担当、法務・監査担当の役割を決めておくことが重要です。
端末紛失・退職・共有ID・緊急時への備え
認証器を失った場合と、例外的なIDを使う場合の手順を、あらかじめ決めておきます。
- 紛失時：本人確認後に認証器を停止し、予備手段で復旧する
- 共有・サービスID：個人IDと分けて利用元や秘密情報を管理する
- 緊急ID：常用せず、利用を承認・通知・記録する
認証器の停止を利用者の自己申告だけで行うか、管理者が本人確認をしてから行うかを決めておきます。バックアップコードについては、保管場所と使用済みコードの無効化を定めます。
復旧の手続きを簡単にしすぎると、窓口が悪用されかねません。そのため、本人確認の強度と記録も設計します。
共有IDでは、操作した人を追跡できません。一方、サービスアカウントでは秘密情報のローテーションと実行ログも管理します。また、緊急用のブレークグラスアカウントは、利用後にパスワードを変更します。
個人情報保護法と監査への対応
法令上の要件は一律ではないため、保有データと監査条件に応じて備えます。
- リスク評価：データの性質、量、漏えい時の影響
- 追加要件：契約、社内規程、監査基準、委託先
- 提出記録：権限台帳、ログ、例外承認、復旧訓練
個人情報保護法が、全企業に同じ多要素認証方式を義務付けているわけではありません。一方、個人情報保護委員会のガイドラインは、事業規模なども踏まえた安全管理措置を示しています。
対策には、アクセス制御、利用者の識別・認証、不正アクセス防止、ログ分析などがあります（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年改正版）。
法務や契約の領域では、扱うデータと操作の影響を踏まえ、誰がどのデータに何をしたかを説明できる状態を作ります。
金融・公共分野などで個別要件がある場合は、対象アカウント、認証強度、ログ保持、委託先管理、海外でのデータ処理を確認します。また、監査では、設定画面のスクリーンショットに加えて、アクセスレビューの記録も提出できるようにしておきます。
多要素認証システムで起こりやすい失敗と対策
認証方式を導入しても、弱い復旧経路、過剰な例外、共有ID、利用者教育の不足が残ると、期待した効果は得られません。
失敗を事前に想定したうえで、例外は無くすより、期限と責任者を付けて管理するのが現実的です。
全員への一律適用による業務停止
全利用者へ同じ方式を同じ日から強制すると、古い端末、現場の共有端末、海外や圏外の利用者、外部専門家などがログインできなくなる場合があります。
高リスクの管理者や重要アプリでは、まずパイロットを行い、例外となる利用環境を洗い出します。
利用者には、目的と登録時間を案内します。紛失時の連絡先と代替手段も、あわせて伝えます。ヘルプデスクが実際に復旧できるかを確認してから、対象を広げます。
安全性の低い方式や復旧経路の残存
認証方式と復旧手段の両方に抜け道を残さないよう確認します。
- 認証方法：高リスク用途にはフィッシング耐性を優先する
- 復旧方法：本人確認、承認、操作記録を強化する
SMSや手入力コードは導入しやすい一方で、フィッシング、SIMスワップ、コード中継などのリスクがあります。
導入初期に使う場合でも、管理者や契約承認などへはパスキーやセキュリティキーを優先し、番号一致、端末確認、異常検知を組み合わせます。
CISAも、広く利用できるフィッシング耐性認証としてFIDO/WebAuthnを挙げ、移行できない場合は番号一致などを検討するよう案内しています（出典: CISA「More than a Password」、2025年確認）。
電話だけで無条件に認証器を再登録することや、共有メールへの復旧コード送付、緊急アカウントのパスワードの長期放置は、抜け道になります。そのため、復旧では本人確認、承認、記録を通常ログイン以上に厳格にします。
導入後の責任者と改善指標の不在
担当者の対応手順と、運用と利用者の両面の指標を決めておきます。
- 対応責任：ログ確認、対応時間、利用停止の判断者
- 運用指標：登録率、失敗率、復旧件数と時間、例外期間
- 利用者の声：登録時間、問い合わせ理由、利用できない端末
異常時にログを確認する担当者や対応時間、利用停止の条件が決まっていないと、検知後に動けません。月次または四半期ごとに、未登録者数と特権IDのレビュー完了率も確認します。
業務が止まった時間も分析し、認証方式、案内、画面、運用手順を改善します。また、セキュリティと、正当な利用者が安全に仕事を続けられることを、同じ成果として扱います。
よくある質問（FAQ）
導入前によく寄せられる質問に、順に答えます。
最適解は、自社の利用者やデータ、既存システム、運用体制によって変わります。判断の軸を先に持っておくと、過剰な機能追加や安易な方式選択を防げます。
多要素認証システムはすべての企業に必要ですか？
すべての企業に同じ方式を一律に導入する必要はありませんが、パスワードだけに依存する状態は見直すべきです。
個人情報、契約情報、管理者権限、外部公開サービスなど、侵害時の影響が大きい領域から対象を決め、リスクに応じて認証強度を上げます。
SMS認証だけで十分ですか？パスキーは必要ですか？
SMSは導入しやすい一方、フィッシングやSIMスワップへの耐性は限定的です。管理者・特権ID・契約承認にはパスキーやFIDO2を優先し、一般利用者は端末・業務環境に合わせて段階的に移行します。
多要素認証システムの導入費用はどのくらいですか？
初期設定中心は30万〜150万円、標準業務アプリ連携は100万〜500万円が推定レンジです。
複数拠点・レガシー統合は500万〜1,500万円、顧客向け独自開発は1,500万〜4,000万円以上が目安です。
金額は、ユーザー数、連携数、方式、移行、教育、ログ監視の範囲で変わります。初期費用と月額・従量費を分けて見積もります。
スマートフォンを紛失したときはどう復旧しますか？
紛失の申告を受けたら、登録済みの認証器を無効化し、必要に応じてセッションを失効させ、新しい認証器を本人確認後に登録します。
予備の認証器やバックアップコード、管理者による復旧を用意しておき、復旧の操作そのものにも承認と記録を求めます。緊急時に業務を止めないことと、攻撃者に悪用されない本人確認を両立させることが重要です。
まとめ
多要素認証システムは、追加認証だけの機能ではありません。認証方式や権限、業務アプリ連携、ログ監視まで含む基盤で、復旧と利用者支援も欠かせません。
管理者、特権ID、リモートアクセス、契約承認など、侵害時の影響が大きい領域から特定し、リスクに合った認証強度を設計します。
導入前に確認する五つのポイント
導入前の確認では、セキュリティ要件と、継続できる運用の両方を見渡します。
- 対象の洗い出し：誰がどのデータへ何をするかを最初に確認する
- 方式比較：SMS、TOTP、プッシュ通知、パスキーを耐性・負担・通信環境・復旧方法で比較
- 総額確認：初期費用と、ライセンス・SMS・端末などの継続費、連携開発、保守、監視を分けて見る
- 実装範囲：標準連携と独自開発の境界を明確にする
- 本番前検証：端末紛失、退職、共有ID、サービスアカウント、緊急管理者を確認
小さく始める導入と運用での強化
最初から全社・全アプリ・全機能を対象にせず、小規模なパイロットを段階展開と継続改善へつなげます。
- 試行：登録率、失敗率、問い合わせ、復旧時間を確認する
- 方式：高リスク操作ではパスキーやFIDO2を優先する
- 委託先：移行から障害対応、契約終了時までの責任範囲
弱い復旧経路や無期限の例外を残さないことが大切です。開発会社・ベンダーを比較するときは、要件定義から移行、教育、障害対応、契約終了時のデータ取り出しまで確認します。
▼関連記事一覧
・多要素認証システム開発の進め方/やり方/流れや方法/手法/工程/手順
・多要素認証システム開発でおすすめの開発会社/ベンダー6選と選び方
・多要素認証システム開発の見積相場や費用/コスト/値段について
・多要素認証システム開発の発注/外注/依頼/委託方法について
▼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を創業。