認証基盤とは？仕組み・選び方・費用を専門家が解説

認証基盤という言葉を知り、導入や構築を検討し始めたとき、理解の最初のフェーズでつまずきやすいのは、認証基盤の意味するところが文脈によって異なることです。 CIAM や EIAM、IDaaS を指すこともあれば、単に外部化された認証機能を指すことも、ID統合や共通化までを含むこともあります。

この記事では、累計300万ID以上・20システム超の認証基盤を構築してきたスタジオメッシュが、これらの言葉の関係を整理しながら、認証基盤の定義、主要機能、実現方式の比較、構築の進め方、費用感までを一気通貫で解説します。 この記事を読み終えたときに、自社の文脈では何をどう作るべきかを判断できる状態になることを目指します。

認証基盤とは

認証基盤とは、アプリケーションから認証機能を独立させて、専用のシステムとして外部化したものです。 ログイン・ユーザー登録・パスワード管理といった「ユーザーが誰であるかを確認する機能」をアプリ本体から切り出し、認証専門の基盤に任せます。

もともと認証機能は単一のアプリケーションの内部に作り込まれるものであり、現在でも世の中のシステムの大多数は認証機能をアプリ内部に持っています。 その認証部分だけを取り出して独立させたものが「認証基盤」であり、次の3段階で捉えると正確に理解できます。

1. 内蔵：アプリの内部に認証機能がある状態。最も一般的な形です
2. 外部化：認証機能だけを独立したシステムに切り出した状態。単一のアプリのためであっても、外部化されていればそれは認証基盤です
3. 共通化：外部化した認証基盤を複数のシステムで共有する状態。「共通認証基盤」「統合認証基盤」と呼ばれるのはこの段階です

「認証基盤」は「複数システムのIDを一元管理する仕組み」と説明されることが多いのですが、その説明が指しているのは第3段階の共通化です。 実際には、1つのサービスのために Auth0 や Ory（Kratos + Hydra）を導入するケースも第2段階の外部化に該当する「認証基盤」であり、導入の件数としてはこの形が多数を占めます。

「認証基盤」が指しうるもの：3つの軸で整理する

冒頭で触れた「認証基盤の意味が文脈によって異なる」という問題は、この言葉が3つの異なる軸のどこを指しているのかが曖昧なまま使われることから生まれます。 会話や記事に「認証基盤」が出てきたら、次の3軸のどこの話なのかを特定すると誤解がなくなります。

軸	選択肢	解説する章
段階	内蔵 ／ 外部化 ／ 共通化（ID統合）	この章で説明した3段階
対象	社内向け（EIAM）／ 顧客向け（CIAM）	「認証基盤は社内向けと顧客向けで志向が異なる」
実現方式	IDaaS ／ OSS ／ スクラッチ内製	「認証基盤の実現方式の比較」

たとえば「IDaaS を使って顧客向けの共通認証基盤を作る」という文は、実現方式＝IDaaS、対象＝CIAM、段階＝共通化、と3軸すべてが特定された曖昧さのない表現です。 本記事の以降の章は、この3つの軸をそれぞれ掘り下げる構成になっています。

なぜ OIDC が生まれたのか

認証機能を外部化すると、「認証する側（認証基盤）」と「認証結果を使う側（アプリ）」が別々のシステムになります。そのため、認証結果を安全にシステム間で受け渡す方法が必要になりました。この課題に応える標準仕様が OpenID Connect（OIDC）です。

認証基盤は社内向けと顧客向けで志向が異なる

「認証基盤」という同じ言葉が、実務では2つの異なる文脈で使われます。 社内システムに従業員がログインするための基盤（EIAM：Enterprise IAM）と、自社サービスに会員・顧客がログインするための基盤（CIAM：Customer IAM）です。 この2つは求められるものが異なるため、製品にも志向の違いがあり、特徴的な機能に違いが出ます。

	社内向け（EIAM）	顧客向け（CIAM）
利用者	従業員	サービスの会員・顧客
ユースケース	社内システムのSSO、入退社管理	新規会員登録、マイページ、セキュリティ
ユーザー数の規模	数百〜数万	数万〜1000万以上
重視されること	管理統制・セキュリティポリシー	UX・スケール・同意・データ活用
代表的な製品	Microsoft Entra ID、Okta WIC	Auth0、Ory、Cognito、SAP CDC

社内向けに志向する製品は管理統制を重視しており、入退社に伴うアカウント管理、業務SaaSとの連携カタログ、セキュリティポリシーの全社適用といった機能が特徴的です。 顧客向けに志向する製品は事業への貢献を重視しており、大規模スケール、離脱を生まないログインUX、登録フローや取得データのカスタマイズ性といった機能が特徴的です。 この志向の違いは製品ラインにも表れていて、Okta は社内向け（Workforce Identity Cloud）と顧客向け（Auth0）を別製品として提供し、Microsoft も Entra ID と Entra External ID を分けています。 ただし境界は厳密ではなく、たとえば Auth0 を社内向けに使うケースも実際にあります。

製品選定や情報収集は、自社が求めている用途を得意とする製品・ベンダーを起点に進めるのが効率的です。 なお、検索で見つかる「認証基盤」の解説記事の多くは社内SSOの文脈で書かれています。 本記事は両方をカバーしつつ、私たちが多く手がけている CIAM（顧客向け）の観点を厚めに扱います。

認証基盤のメリット：なぜ認証機能を外部化するのか

認証機能の実装・運用のハードルの高さ、セキュリティリスク、データ活用。 認証基盤の必要性はこうした背景から語られることが多いです。 外部化すると何が得られるのかを以下で整理します。

外部化そのもののメリット（非共通でも成立）

アプリケーションが本来の関心事に集中できる。 認証はどんなサービスにも必要である一方で、サービスの価値そのものではありません。 認証を外部化することで、開発チームは事業価値を生む機能の開発に集中できます。

セキュリティリスクを低減できる。 認証は攻撃者に最も狙われる入口であり、パスワードの安全な保管、ブルートフォース攻撃やリスト型攻撃への対策、セッション管理には専門的な知識が必要です。 認証専門の基盤にはこれらの対策が設計段階から組み込まれているため、本来やりたい開発の片手間に自前実装した場合に起きがちな不備（情報漏えいに直結し、サービス全体の信頼を損なう種類の不備）を構造的に減らせます。

開発・運用の負担を軽減できる。 多要素認証やアカウント復旧のような機能群をゼロから作る必要がなくなることに加えて、新しい攻撃手法への対応や標準仕様（OIDC・FIDO など）の更新への追従といった「作った後も続く仕事」を認証基盤側に寄せられます。 認証を内製した場合、この追従コストはサービスが続く限り発生し続けます。

さらに共通化した場合のメリット

外部化した認証基盤は、複数のアプリケーションから利用できます。 この状態が共通認証基盤・統合認証基盤です。

SSO（シングルサインオン）が実現する。 ユーザーは1回のログインで複数のサービスを使えるようになり、サービスごとにIDとパスワードを使い回す必要もなくなります。

顧客データを個人軸で統合できる。 複数のサービスでIDが共通になると、同じユーザーをサービス横断で同一人物として識別できるようになります。 この土台があって初めて、個人軸でのデータ分析や、行動に応じた1to1マーケティングといったデータ活用が可能になります。 CIAM の文脈では、セキュリティよりもこのデータ活用こそが認証基盤投資の事業側の目的になることも少なくありません。

セキュリティガバナンスを統制できる。 パスワードポリシー、多要素認証の要求レベル、監査ログの取得といったセキュリティの方針を、接続するすべてのサービスに一元的に適用できます。 サービスごとに認証の実装がばらばらの状態では、最も対策の弱いサービスが全体の弱点になります。

これらのメリットに共通するのは、認証基盤への投資が接続しているすべてのサービスに一度に波及するという構造です。 たとえばパスキー対応を基盤側で実装すれば、全サービスが同時にパスキー対応になります。 サービスごとに認証を作っていた場合には同じ投資をサービスの数だけ繰り返すことになるため、共通化が進むほど認証への投資対効果は高まっていきます。

用語の整理

認証基盤のプロジェクトでは、用語の定義が曖昧なまま進むと、関係者ごとに違う意味で言葉を使い始め、設計の方針が定まらなくなります。 私たちが言葉の定義にこだわるのはこのためです。 機能の話に入る前に、最低限の用語を整理しておきます。

用語	英語	意味
認証	Authentication（AuthN）	相手が「誰であるか」を確認すること。例: ID・パスワードの照合
認可	Authorization（AuthZ）	確認済みの相手に「何を許可するか」を決めること。例: 管理者だけが設定画面を開ける
IdP	Identity Provider	認証を提供する側。認証基盤はここに該当する
SP / RP	Service Provider / Relying Party	認証結果を受け取って利用する側。一般のアプリケーション
OP	OpenID Provider	OIDC の文脈での IdP の呼び名

実務でよく起きるのは、認可を含めた全体をまとめて「認証」と呼んでしまうことです。 認証基盤という文脈では、この広い用法をあまり気にする必要はありません。 実際、「認証基盤」と呼ばれるものの多くは認可やID管理まで含んでいます。 一方で、システム設計の場面では認証と認可を厳密に区別することが重要です。

日本語の「認証」には2つの意味がある

日本語の「認証」は、英語では別の単語になる2つの意味を持っています。「ユーザー認証」の認証は authentication（相手が誰であるかの確認）であり、「ISO認証」の認証は certification（第三者による証明）です。本記事で扱うのは前者です。

認証基盤の主要機能

認証基盤の機能は「コア機能」と「周辺機能」の2層で捉えると全体像をつかみやすくなります。

コア機能：認証・認可・ID管理

最もわかりやすい機能はIDとパスワードを照合して結果を返すことですが、これを起点に整理すると、コア機能は次の3つに分類できます。

• 認証：ログイン処理そのもの。ユーザー固有の情報によって、「対象者が誰なのか」を判別する。パスワード認証、ソーシャルログイン、多要素認証、パスキーなど
• 認可：認証済みユーザーへの権限判定と付与。OAuth 2.0 によるアクセス権の委譲、ロールベースのアクセス制御など
• ID管理：IDの登録・変更・削除のライフサイクル全体に関する機能全般。ユーザー情報（プロフィール・属性・認証情報）の保管と管理。

セキュリティの周辺機能

コア機能の周辺には、信頼できるログインを成立させるための機能が数多く存在します。

• メールアドレスや電話番号の実在・所有確認（verification）
• bot 対策（reCAPTCHA など）
• レートリミット（試行回数の制限）
• アカウントロック
• ログインできないユーザーの復旧
• 漏えいパスワードのチェック
• アカウント削除（退会）

これらの機能を自前で漏れなく実装し、維持し続けるコストを考えると、メリットの章で述べた「認証は本来の開発の片手間に作るには難しすぎる」という指摘に納得感があるのではないでしょうか。

共通化が進むと「会員管理基盤」の性格が強くなる

共通認証基盤（3段階の共通化）になると、連携アプリが必要とするユーザー属性の共通部分を認証基盤側で管理して提供する構成が多くなり、認証基盤が会員情報の重要な部分を保有する、実質的な会員管理基盤としての性格を帯びていきます。 この段階では会員情報の管理画面・監査ログ・データ連携といった周辺機能も要件に含まれてくるため、製品選定での確認範囲も広がります。 共通認証基盤の設計論点は、別記事で詳しく扱う予定です。

同意管理：2種類の同意と認証の3段階

CIAM で特に重要なのが同意管理です。 同意管理には性質の異なる2種類があります。

1. 同意文書への同意：利用規約・プライバシーポリシーへの同意の取得と管理。共通化の段階ではIDサービス自身が発行する文書と連携サービスの文書が別々に発生し、文書のバージョン管理や改定時の再同意が論点になります
2. 連携サービスへの属性提供の同意：「このアプリにあなたのメールアドレスを提供します。よろしいですか？」という、ID連携時の同意。OAuth がカバーするのはこちらです

この2種類は、冒頭で示した認証の3段階と対応させると理解しやすくなります。 外部化の段階（単一アプリ）では、ユーザーが同意する文書はそのアプリの利用規約とプライバシーポリシーが唯一であり、同意管理は1つ目の種類だけを考えれば成立します。 共通化の段階に進むと、共通認証基盤そのものの規約への同意と連携する各サービスの文書への同意が分離し、さらにサービス間で属性を受け渡すための提供同意（2つ目の種類）が初めて実質的な論点になります。 メリットの章で述べた「個人軸でのデータ統合」を行うのであれば、誰がどの文書のどのバージョンにいつ同意したかを正確に管理することが、データ活用の前提条件です。

この2つの同意を区別せずに「同意管理」と一括りにすると混乱を生んでしまいます。

認証基盤の実現方式の比較：IDaaS・OSS・内製

認証基盤を実現する方式は大きく3つあり、それぞれの特性を理解したうえで自社の要件に合わせて選びます。

観点	IDaaS	OSSセルフホスト	スクラッチ内製
代表例	Auth0、Cognito	Ory、Keycloak	—
初期コスト	◯	△	✗
ランニングコスト	✗	◯	△
カスタマイズ性	✗	◯	◯
運用負荷	◯	△	✗
ロックイン	製品依存が強い	なし	なし
向くケース	全てを外部に任せたい	大規模利用、自社コントロール	独自機能の作り込みが必須

IDaaS（Identity as a Service）は、認証基盤をクラウドサービスとして利用する方式です。 最も速く立ち上げられ、セキュリティアップデートも事業者から自動的に提供されます。 一方で料金は MAU（月間アクティブユーザー数）に比例する体系が多く、サービスの成長に伴って費用も増加します。

OSS は、オープンソースの認証基盤ソフトウェアを自社でホスティングする方式です。 カスタマイズ性とコストのコントロール性に優れる一方、自社に運用体制が必要になります。 OSS の代表格である Ory については別記事で詳しく解説しています。

スクラッチ内製は、認証基盤をゼロから自前で開発する方式です。 ここまで述べてきたとおり認証は専門性が高く失敗時の影響も大きいため、認証技術自体が事業の核であるような場合を除けば、現在あえて内製を選ぶ理由はほとんどありません。 既存の内製認証を抱えるシステムが IDaaS や OSS へ移行していくのが現在の大きな流れです。

各方式とも国内外の事業者・公共機関に採用実績があり、IDaaS・OSS・内製のどれを選ぶかは、ユーザー規模・運用体制・カスタマイズ要件によって分かれます。 実際の採用事例にもとづく方式選択の解説と、製品同士の詳細な比較は、別記事で扱う予定です。

なお私たちは特定の製品に依存せず、Auth0・Ory・Cognito などを案件の要件に応じて使い分ける立場です。

認証基盤の選定基準

方式・製品を選定するときに確認すべき観点を、実務での優先度が高い順に挙げます。

1. ユーザー規模と料金体系の相性。 MAU 課金の IDaaS は、小規模では低コストで、大規模になるほど費用が増えます。 ここで確認すべき問いは、「自社のビジネスは、ユーザー数の成長とともに利益も大きくなるか」です。 ユーザー数と利益が比例するビジネスであれば、MAU 課金は収益に連動する合理的な費用として受け入れられます。 一方、無料ユーザーが大半を占めるサービスのように、ユーザー数と利益が比例しないビジネスでは、成長とともに必ずコストが問題になります。 現在のユーザー数だけでなく、3〜5年後の規模を想定して総コストを試算してください。 最も避けるべきなのは、ユーザー数の成長によって料金が大幅に増えているにもかかわらず、他製品への移行手段がないという状態です。

2. インターオペラビリティ（移行可能性）。 パスワードハッシュをエクスポートできない製品は、その一点だけで採用を見送ってもよいと言っても過言ではありません。 認証基盤は一度導入すると長期間使い続けるものですが、製品の価格改定・サービス終了・自社要件の変化は自社ではコントロールできません。 他製品へ移行する手段が確保されているかどうかを、導入を決める時点で確認しておくべきです。

3. 標準技術（OIDC・OAuth 2.0・SAML）への対応。 認証基盤と既存システムの連携は、これらの標準技術で行うのが原則です。 もっとも、近年の主要な製品はほぼ例外なく標準技術に対応しているため、製品側の対応が選定の障害になることは多くありません。 実際に確認すべきは連携したい既存システムの側の対応状況であり、対応していないシステムとの間で標準に準拠しない独自方式の連携を作ってしまうと、将来の移行や拡張を妨げる負債になります。

4. カスタマイズ要件。 ログイン画面のUI、登録フロー、本人確認の組み込みなど、自社の要件が製品の機能の範囲内で実現できるかを確認します。 CIAM ではログイン体験がブランドの一部になるため、この確認の比重が大きくなります。

5. デプロイ先の制約。 公共系のガバメントクラウド要件や金融の監査要件など、データの置き場所やインフラに制約がある場合は、セルフホストできる OSS が実質的な選択肢になります。

認証基盤の構築・導入の進め方

実際のプロジェクトは、おおむね次の6ステップで進みます。

1. 事前検討：課題の整理を行い、自社がどのような認証基盤を必要としているのか整理する
2. 製品選定・PoC：事前検討の結果から候補を絞り、重要な要件は PoC で実現性を担保
3. 要件定義：認証方式、データモデル、画面遷移、ブランディング、移行方式、非機能要件などの確定
4. 設計・開発：認証基盤の構築、ログイン画面・連携部分の実装、ガイドの整備
5. 既存ID移行：既存のユーザーがいる場合、既存IDの移行を実施
6. 運用保守：監視・サポート体制の整備、継続的なアップデート

スタジオメッシュは、事前検討・製品選定から設計・構築・ID移行・運用まで、どのフェーズからでも支援できます。 認証基盤の構築を検討している場合は、サービス紹介をご覧のうえ、まずお気軽にご相談ください。

認証基盤のコスト・料金

まず費用の全体構造を把握する

認証基盤の費用は「イニシャル費用」と「ランニング費用」に大別され、それぞれ次の項目で構成されます。

区分	費用項目	内容
イニシャル	製品選定・PoC	候補製品の検証、要件適合の確認
イニシャル	設計・構築	基盤本体のセットアップ、環境構築
イニシャル	カスタマイズ開発	ログイン画面・登録フロー・独自要件の実装
イニシャル	連携開発	既存システムとの OIDC / SAML 連携
イニシャル	ID移行	移行方式の設計、移行処理の開発、リハーサル
ランニング	ライセンス費	IDaaS の MAU 課金、OSS の商用ライセンス
ランニング	インフラ費	セルフホストの場合のクラウド利用料
ランニング	監視・運用	死活監視、障害対応、問い合わせ対応
ランニング	カスタマイズ部分の保守	自前開発した画面・連携の改修、製品アップデートへの追従
ランニング	セキュリティ・監査対応	脆弱性情報への対応、監査ログの管理・提出

注意すべきはカスタマイズで、IDaaS でも画面のカスタマイズや不足機能の自前開発が必要であるため、IDaaS だからといってランニングがライセンス費だけで済むことは基本的にありません。

ランニング費用のうちライセンス・インフラ費：1万MAUのモデルケース

費用構造の中で方式による差が最も大きいのがライセンス費・インフラ費です。 顧客向けサービスで月間1万人がログインする規模を想定し、方式別に試算します。

方式・製品	課金単位	1万MAU時の概算（年額）	備考
Auth0	MAU従量	¥3,072,000	B2C Professional（Enterpriseは個別見積）
Cognito	MAU従量	¥384,000	Plus
OSS(OryやKeycloak)	インフラ	¥0	別途有償サポートの提供あり

※ 2026年6月時点の各製品の公開料金をもとに、1USD=160円で換算した概算です。料金体系は改定されることがあるため、最新の料金は各製品の公式情報をご確認ください。

MAU 課金の IDaaS はユーザー数と費用が比例し、セルフホストはユーザー数が増えても費用が比例しにくいです。 この構造のため、ユーザー数の少ない立ち上げ期は IDaaS が有利になり、規模が大きくなるほどセルフホストのコストが優位になります。 なお正確な費用が知りたい場合は、お問い合わせください。 当社は、各認証製品とパートナーシップを結んでおり、個別見積が必要なライセンスも費用のご提示が可能です。

初期費用の相場と、費用が膨らむ要因

初期費用は要件による振れ幅が大きいため一概には言えませんが、費用を押し上げる主な要因は次のとおりです。

• ログイン画面・登録フローのカスタマイズ量
• 既存IDの移行（データ量そのものよりも、移行方式の制約が費用に影響する）
• 連携するシステムの数と、各システムの標準プロトコル対応状況
• 会員管理などの不足機能の開発

正確な費用は要件に依存しますが、コストの規模感を知りたい方はお問い合わせいただければ、類似案件をもとにお答えできます。

認証基盤の最新動向

パスキー認証

パスワードに代わる認証方式として、フィッシング耐性をもつパスキーへの対応が、証券会社をはじめとして進んでいます。 メジャーな認証製品は殆どがパスキーに対応しているため、パスキー要件がネックになることはありません。 一方で、パスキー提供の難しさはエンドユーザーへのご案内やサポートにあるため、提供する際には綿密な計画が必要です。

公的個人認証（マイナンバーカード）

日本においては国民IDであるマイナンバーカードが85%程度（2026年6月時点）も普及しており、これを使ったログインや身元確認をサービスに組み込む動きが広がっています。 マイナンバーカード連携が具備されている製品はありませんが、活用する際には特有の技術実装を行う必要があります。

認証基盤のよくある質問

Q. Active Directory とは何が違うのですか？

Active Directory やその後継のクラウドサービスである Entra ID（旧 Azure AD）は、社内向け（EIAM）の代表的な認証基盤です。「認証基盤」という大きな枠組みの中の、従業員向けの一形態と捉えてください。大規模な会員管理やログインUXの作り込みが求められる顧客向け（CIAM）の用途には、CIAM 向けの製品を使います。

Q. IDaaS と認証基盤は同じものですか？

IDaaS は認証基盤の実現方式の1つです。認証基盤という機能の枠組みをクラウドサービスとして提供するのが IDaaS であり、同じ枠組みを自社ホスティングで実現するのが OSS やスクラッチ内製です。

Q. 導入にはどれくらいの期間がかかりますか？

要件によりますが、目安として、単一サービスへの IDaaS 導入で1、2ヶ月、既存IDの移行や複数システム連携を含む場合は3か月から1年程度を見込みます。期間を左右する最大の要因は連携サービス側の対応期間です。

Q. 小規模なサービスでも認証基盤は必要ですか？

専任チームを組んで認証基盤を構築する必要は、多くの場合ありません。ただし、認証を自前で実装することも推奨しません。Better Authなどライブラリもありますが、小規模なサービスであれば IDaaS の無料枠や低価格帯から始められるため、規模を問わず「認証機能はアプリの外に出す」ことをおすすめします。

Q. 既存システムからの移行はできますか？

できます。ただし移行方式（一括移行か、ログイン時の段階移行か）の検討が必要であり、旧システムからパスワードハッシュをエクスポートできるかどうかが難易度の分かれ目になります。移行を見据えた製品選定と移行設計は、綿密に検討すべきです。

まとめ

• 認証基盤とは、アプリから認証機能を独立させて外部化したもの。共通化（複数システムでの共有）はその先の段階であり、単一システムのための外部化も認証基盤に該当する
• 社内向け（EIAM）と顧客向け（CIAM）では製品の志向が異なり、特徴的な機能に違いが出る。自社の用途を得意とする製品・ベンダーを起点に情報を集める
• 機能はコア（認証・認可・ID管理）に加え、セキュリティ周辺機能・会員管理・同意管理まで広がる。この広さが「認証は片手間に作るには難しすぎる」理由でもある
• 実現方式は IDaaS・OSS・内製の3択。ユーザー規模と料金体系の相性、そして**パスワードハッシュをエクスポートできるか（移行可能性）**が選定の最重要観点
• 費用構造は、ユーザー数に比例する IDaaS と、規模の影響を受けにくいセルフホストで異なる。成長の見込みを含めた総コストで判断する
• 構築は事前検討・製品選定・要件定義・設計開発・ID移行・運用開始の6ステップで進む。規模が大きいほど事前検討（課題整理・対象システムの棚卸し）に時間をかけることが、後工程の手戻りを防ぐ

スタジオメッシュは、累計300万ID以上・20システム超の構築実績をもとに、製品選定から構築・ID移行・運用まで、認証基盤のすべての工程を支援しています。 検討中の段階でも、お気軽にご相談ください。