アイデンティティプロバイダの選び方：エンジニアリングチームの評価フレームワーク

ほとんどのアイデンティティプロバイダの比較記事は、アイデンティティプロバイダ自身が執筆しています。驚きでしょう？自社製品が持つ機能だけをリストし、持っていない部分は飛ばして、「客観的ガイド」と称するのです。

これは、そうではありません。

私たちは実際のエンタープライズ評価依頼—調達チームがベンダーに送る実際のスプレッドシートやRFPドキュメント—を何十件もレビューしてきました。パターンは明らかで、エンジニアリングチームは本当に重要な基準を常に軽視し、重要でない基準を重視し過ぎています。

その結果？チームはデモに基づいて IdP を選び、6 ヶ月後には移行の難しさに気づき、再評価を始めることになります。

これは、私たちが本当は誰かから教えて欲しかった評価フレームワークです。B2B SaaS 企業のエンジニアリングチーム向け—社員向けのワークフォース SSO ではなく、実際にプロダクトを構築している人たちのためのものです。

短縮版：IdP 選択を左右するポイント#

斜め読みする方へ、要点だけ：

1. プロトコルの深さが機能数より重要。 「OAuth2 対応」だけなら意味がありません。どのグラントタイプ？トークンクレームをカスタマイズできるか？自分自身を OIDC プロバイダーにできるか？
2. 移行性が最も過小評価されている基準。 既存ユーザーをパスワードリセットなしで移行できなければ、その IdP は使えません— 他がどんなに良くても。
3. マルチテナンシーはネイティブである必要がある、後付ではダメ。 組織モデルやテナントごとの設定にワークアラウンドが必要なら、永遠にシステムと戦う羽目になるでしょう。
4. AI対応は将来の話ではなく、12 ヶ月以内の要件。 トークン交換、エージェントアイデンティティ、委譲スコープ。IdP がこれらをサポートしていなければ、来年また評価し直すことになります。

このガイドの残り部分では、各評価軸を詳細に解説し、質問すべきポイントや警戒点を紹介します。

このガイドの対象者（対象外も含む）#

以下の方におすすめ：

• 50～300 人程度の B2B SaaS 企業で CTO／VP エンジニアリング／プラットフォームアーキテクトを担当している
• 既存ユーザーが 10 万人以上いて、移行で混乱を起こす余裕がない
• エンタープライズ顧客向けに SSO・組織モデル・監査ログが必要
• 技術的な評価レポートを書く必要があり、ベンダー発ではないフレームワークを探している

以下の方には対象外です：

• 社員向け IAM（社内ツール用の SSO）を探している方 — 別の意思決定です
• 500 ユーザー未満のスタートアップかつエンタープライズ顧客がいない方 — 最も良い SDK を持つものを選んで進みましょう
• 本人確認（KYC／KYB）が必要な方 — 別カテゴリです

評価軸１：プロトコル機能 — 単なる「OAuth2 対応」以上を求める#

市場にあるすべての IdP は「OAuth2 や OIDC をサポートします」と言うでしょう。それは大前提。本当に重要なのは、その深さです。

グラントタイプ：どれに対応しているか、なぜ重要か#

必須：

• Authorization Code + PKCE — ブラウザ・モバイルアプリの唯一の推奨フロー。インプリシットフローを推奨するベンダーは即座に除外しましょう。PKCE は必須— セキュリティ要件です。
• Client Credentials — サービス間通信用。ユーザーがいなくてもバックエンドサービス同士が認証し合うために必要です。
• Refresh Token — 基本機能のようですが、実装の違いは大きいです。ローテーションや有効期限の設定は？特定のリフレッシュトークンだけを失効できますか？全セッションを一度に無効化するしかない？

ますます重要になっているもの：

• Token Exchange (RFC 8693) — AI エージェント認証、なりすましフロー、委譲のために不可欠。現時点で未対応ならロードマップを確認。ロードマップすらなければ、要注意です。

OIDC Provider 機能#

多くのチームが意識しない質問：この IdP を OIDC プロバイダーとして使えるか（消費者としてだけでなく）？

なぜ重要か：SaaS が成長すると、パートナーや顧客があなたのアイデンティティシステムで自分のツールへのログインを求めてくるかもしれません。トークンの発行、同意管理、サードパーティアプリ登録管理が必要です。外部 IdP しか利用できずプロバイダーにはなれないなら、外部連携で詰まります。

質問例：

• OpenID Discovery エンドポイントをホワイトラベルで提供できますか？
• ファーストパーティ・サードパーティアプリを異なる信頼レベルで登録できますか？
• ファーストパーティは同意画面をスキップ、サードパーティは必須など、使い分け可能ですか？

JWT カスタマイズ#

トークンは IdP とサービス間の契約です。カスタマイズできなければ、下流サービスが追加 API コールをする必要があり、ユーザーの許可を逐次確認することになります。

質問例：

• アクセストークン・IDトークンにカスタムクレームを追加できますか？
• ユーザーが操作中のテナント情報など、組織コンテキストをトークン内に埋め込めますか？
• アプリ固有の権限モデルにマッピングしたカスタムスコープを定義できますか？
• クレームはトークン発行時に計算されますか？Webhook やスクリプトを通じて動的に設定できますか？

{"org_id": "org_123", "role": "admin", "auth_level": 2 } のようなトークンがあれば、API ミドルウェアでワンライナーで認可判断が可能です。{"sub": "user_456"} だけでは、都度 IdP や DB に確認が必要。大規模運用では、この差がリクエスト毎 2ms と 200ms の違いになります。

評価軸２：認証フロー — 細かい仕様が命取り#

どの IdP もメール／パスワード・SNS ログインは対応しています。つまり、ここまでで全候補が残ります。

違いはデモでスルーされがちな細部です。

サインアップフロー#

• 登録後自動ログイン：新規登録したら自動でログイン状態になるか？再度ログイン画面が出ないか？登録直後に再ログインを要求すると、コンバージョン激減。意外と多いミスです。
• カスタム登録フィールド：登録時に役職や会社名、用途などを収集できますか？後から別途オンボーディングしないといけませんか？
• 段階的プロファイリング：一度に全情報を要求せず、複数回に分けて追加情報を収集できますか？

ログインフロー#

• login_hint 対応：マーケティングメールからのリンク時、メールアドレスを事前入力できますか？小さなことですが、メール施策のコンバージョンが大きく変わります。
• 組織別認証ポリシー：Org A は SAML SSO 必須、Org B はメール・パスワードなど、認証方式をテナント単位で切り替えられますか？エンタープライズテナントだけ MFA を必須にできますか？これがコード変更になると、毎回エンタープライズ顧客の度に開発コストがかかります。
• ブランドカスタマイズ：テナントごとにログイン画面の見た目を完全カスタマイズできますか？ロゴや色だけでなく、CSS、カスタムドメイン、ホワイトラベルのメールも含めて。「ホステッドUI vs 自前UI」の選択ができ、制約であるべきではありません。

一般的なチェックリストが見落とす点#

• サイレント認証：トークン有効期限切れ時、ユーザーをリダイレクトすることなくサイレントに再認証できますか？リフレッシュトークンも期限切れの場合は？iframe などでスライディングセッション対応できますか？
• アカウントリンク：Google で登録後、メールでログインし直す場合、同一アカウントとして統合されますか？IdP がどのように統合を扱うかは重要。失敗すると重複アカウントが無限に残ります。
• パスワードレス対応：マジックリンク、パスキー、WebAuthn。今すぐ必須ではなくとも、半年以内にエンタープライズ顧客が必ず要求してきます。

評価軸３：セッション・トークン管理 — 本当の難所#

多くの評価はデモの段階で止まりますが、セッション・トークン管理は壊れた時に初めて本質的な問題が顕在化します— そして壊れるとユーザー全員が一斉ログアウトします。

クッキーセキュリティ#

地味ですが絶対に重要。

• HttpOnly・Secure・SameSite 属性：すべて正しく設定されていますか？セッションクッキーに HttpOnly がない IdP は本番環境向けではありません。
• サブドメイン間対応：app.yourproduct.comとapi.yourproduct.com のように、複数サブドメインをまたいでセッション共有可能ですか？どうやるかも確認。
• サードパーティクッキー廃止：Chrome などで廃止が進んでいます。IdP はサードパーティクッキー無しでクロスオリジン認証フローをどう実装しますか？「対応予定」では不十分です。

「ログイン状態を維持（Remember me）」と永続セッション#

ユーザーは数分ではなく数週間ログイン状態を求めています。しかし180日間の永続セッションと30分セッションではセキュリティも全く異なります。

質問例：

• セッションとトークンの有効期限を個別に設定できますか？
• 「ログイン状態を維持」オプションでセッションだけを延長し、トークン有効期限は短く保てますか？
• 機密操作時のみ再認証させ、セッションは維持できますか？

リフレッシュトークンのセキュリティ#

• トークンローテーション：リフレッシュトークンの都度ローテーションに対応していますか？（必須）
• 暗号化保存：リフレッシュトークンは保存時に暗号化されていますか？
• 失効の粒度：特定デバイスのみのセッション失効が可能ですか？全セッション一括失効しかできない？
• 有効期限の設定自由度：アプリごとに異なるリフレッシュトークン有効期限が設定できますか？グローバルな固定値しか指定できませんか？

評価軸４：認可モデル — 単なる RBAC を超えて#

RBAC（ロールベースアクセス制御）は最低限。RBAC がないなら候補から除外ですが、B2B SaaS において RBAC だけでは不十分です。

組織単位の権限#

ユーザーは組織に所属し、組織内での権限はプラットフォーム全体の権限と別に管理される必要があります。

同一ユーザーが Org A では管理者、Org B では閲覧者ということも。IdP がこれを素直に表現できなければ、アプリ側で独自権限システムを構築する羽目になり、二重管理です。

質問例：

• ユーザーレベルだけでなく、組織レベルでロールを定義できますか？
• 1人のユーザーが複数組織で異なるロールを持てますか？
• 現在操作中の組織情報はトークン内に入っていますか？API 側で即認可判断できますか？

多段階認証（auth_level）#

金融・医療・高リスク操作のあるプロダクトでは、「認証済み」にもレベルがあります。

ダッシュボード閲覧だけならセッションクッキーで十分。送金など高リスク操作時は、追加の MFA（多要素認証）を要求したい。

これはステップアップ認証と呼ばれ、トークンシステムに**認証レベル（auth_level）**を一級市民として持つことが必要です。

質問例：

• トークンに auth_level クレームが入り、バックエンドで確認できますか？
• アプリ側からフル再ログインなしのステップアップ認証も可能ですか？
• auth_level の有効期限はセッション本体とは独立して管理できますか？

IdP がネイティブに対応していなければ、自分達で作るしかありません— そしてそれはまさに IdP に頼りたかった部分そのものです。

トークンベースの認可判断#

理想は：API ミドルウェアがトークンを読み取り、ユーザーの org・role・auth_level から即座に認可判断できること。

現実は多くの IdP で：トークンからユーザー情報しか分からず、許可範囲を都度追加 API で確認しなければならない。

この追加確認コールは遅延や外部依存、失敗ケースを増やします。1秒間に 1,000 リクエストなら、認可のためのネットワークホップは避けるべきです。

評価軸５：移行 — すべてを決める基準#

誰も語りたがらない統計ですが、IdP 評価は「新 IdP の品質」より「既存ユーザーをどう移行するか」によって頓挫することが多いです。

10 万人以上のユーザーがいれば、移行は「Nice to have」ではなく「プロジェクト全体の成功要件」です。

3 つの移行戦略（IdP が必ず対応すべきもの）#

1. 既存パスワードハッシュの一括インポート

既存システムで暗号化されたパスワード（bcrypt、argon2 他）がある場合、それを IdP へ直接インポートし、検証できますか？

可能なら、ユーザー体験は一切変わらず、最善です。

不可能なら「パスワードリセットメール配布」となり、全ユーザーの30-50%を失うリスクが現実になります。

2. 漸進的（レイジー）マイグレーション

一括移行せず、ユーザーが初回ログイン時ごとに旧システムに問い合わせ、新 IdP にユーザーを作る。その後は新 IdP のみ使用。

大規模ユーザー基盤では最も安全ですが、以下要件が必要：

• 旧システムにカスタム認証フックで問い合わせができること
• ログイン時にユーザーを動的作成できること
• 移行済み／未移行ユーザー管理ができること

3. 並行運用（デュアルライト）

新旧 IdP 両方を同時稼働。書き込みは両方、読み込みは徐々に新側へ移行。ロールバック可能ですが、運用が複雑化します。

移行の警戒サイン#

• 「CSV インポートに対応」 — これはユーザープロファイルの一括取込であって、パスワードではありません。結局リセットメールが必要になります。
• 「移行ガイドあり」 — 内容をよく確認。「全ユーザーにパスワード再設定を依頼」とあれば、先述の30-50%喪失リスクです。
• ハッシュ互換性への言及なし — パスワードハッシュ移行を考慮していないベンダーは、規模の大きいプロジェクト経験が浅い証拠です。

質問例#

• どのパスワードハッシュアルゴリズム（bcrypt、argon2、scrypt、PBKDF2、独自など）に対応していますか？
• ユーザー初回ログイン時に漸進的移行は可能ですか？
• 移行進捗（何%が完了か）をトラッキングできますか？
• 移行失敗時のロールバック戦略は？
• セッションの連続性を保てますか？移行期間中にユーザーが強制ログアウトされませんか？

ベンダーが即答できなければ、実績がないので次を検討しましょう。

評価軸６：マルチテナンシー — ネイティブ or 後付か#

B2B SaaS ＝マルチテナンシー。顧客は組織単位で複数ユーザー・ロール・アクセスポリシーを求めます。IdP がこれを本質的に理解し実装していることが大前提です。

「ネイティブなマルチテナンシー」とは#

• 組織が一級市民：ユーザープロファイルのカスタム項目としてでなく、独立したデータモデル（ID, 設定, メンバーリスト）として実装
• 組織ごとの認証ポリシー：Org A はSAML SSO、Org Bはメール+MFA、Org CはGoogleログインなど、UIやAPIで設定完結（コード変更不要）
• 組織招待やメンバー管理：各組織管理者がユーザー招待・ロール割当・削除が可能。IdPが招待フローやメール確認・ロール管理を担う
• 組織スコープのトークン：ユーザーがどの組織で操作中かをトークンに含め、APIがどのデータを返すか即座に判断可能

「カスタムメタデータ」ワークアラウンドの弊害#

組織モデルがネイティブでない IdP は、user.app_metadata.org_id = "123" のようなカスタムメタデータに格納することを提案します。

すぐ破綻します：

• 複数組織対応の場合、メタデータに配列管理しないといけない
• 招待やメンバー管理フローがそもそもない
• 組織ごとの認証ポリシーが組み込めない
• 組織スコープのトークンも使えず、毎回コンテキスト推論が必要
• 監査ログにも組織が現れない

ベンダーが「メタデータで組織をモデリングできます」と言ったら、それはリレーショナルデータを JSON カラムで持つのと同等です。「動くうちは良いが、限界がすぐ来る」。

質問例#

• 組織モデルはネイティブ実装ですか？ユーザーメタデータ上ですか？
• 1ユーザーが複数組織に同時所属可能ですか？
• 組織ごとの認証要件を個別設定できますか？
• 組織単位のロールや権限はネイティブ対応ですか？
• 組織管理者がセルフサービス UI でメンバー管理できますか？
• トークンに組織コンテキストが含まれますか？

評価軸７：AI 対応 — まだ誰も問わない基準#

12 ヶ月前には「AI エージェント認証」はどの評価リストにもありませんでした。今は、コラボレータやエージェント、AIワークフローを組み込むなら新しい「エージェント」型アイデンティティを管理できる IdP が不可欠です。

なぜエージェントが従来モデルを壊すのか#

これまでは「ユーザー」と「アプリケーション」の二者のみが認証主体。OAuth2 はこの前提に設計されています。

AI エージェントは第３の存在：非人間エンティティが特定ユーザーの代理で、限定された権限・監査証跡付きで操作する必要が出てきました。

• エージェントはユーザーではなく、パスワードやブラウザーセッションを持ちません
• エージェントはマシン=マシンサービスでもなく、「特定ユーザーの代理」として行動します
• エージェントにはユーザーの全権限でなく、限定・期間制限つきの権限発行が求められます

IdP に求められる要件#

Token Exchange (RFC 8693)： エージェントが自分のクレデンシャル + ユーザーの認可情報を提示し、限定されたトークンを受け取る。トークンには「誰が（ユーザー）、誰が代理（エージェント）、範囲（スコープ）、有効期間」全て含める必要あり。

エージェントをクライアント型としてモデリング: エージェントは固有の client_id を持つ正規の OAuth2 クライアント型として表現できるべきで、API キーや共有ユーザートークンの使い回しでは不十分。

委譲スコープ管理: ユーザーがエージェントに権限を明示的に付与でき、アクセス可能リソースや許可範囲を限定可能か。

監査の明確化: ログで「ユーザー本人の操作」と「エージェントが代理で操作」の区別ができるか。これができないと次回 SOC2 監査で「誰がこの変更を？」と聞かれて困ることになります。

MCP（Model Context Protocol）対応#

MCP は AI エージェントがツールやサービスと連携する標準プロトコルになりつつあります。IdP が OAuth ベース認証で MCP サーバーと連携できれば、API キーや共有シークレットでなく正式なプロトコルレイヤーでエージェント認証が可能です。

質問例#

• OAuth2 トークン交換に対応していますか？
• エージェントを独立したクライアント型としてモデリングできますか？
• トークンに委譲者情報（誰が権限を、どの範囲で委譲したか）を含められますか？
• 監査ログでエージェントによる操作と人間による操作を区別できますか？
• MCP サーバー統合やエージェント→ツール認証での OAuth 対応は？

ベンダーがこの領域を考えていないなら、それは 2020 年向けの製品です。あなたは 2026 年に備えているはずです。

評価軸８：非機能要件 — 夜も眠れなくなる重要事項#

機能が売れても、運用でリピートするかが決まります。

パフォーマンス#

• 認証スループット：ピークタイム 100リクエスト／秒、できれば 1,000／秒以上に耐えられるか？
• トークン検証遅延：JWT をローカル検証（＝理想）なら1ms未満。IdP へのイントロスペクション必須なら P99 遅延は？
• スケール限界：最大月間アクティブユーザー（MAU）はどれくらいまで対応？自社規模実績ありますか？

コンプライアンス#

• SOC2 Type II：Type I では信用しない。Type II＝一定期間継続的に監査を受けた証拠。Type I のみなら、Type II の時期を確認しましょう。
• 監査ログ：すべての認証・権限変更・管理操作が記録＆エクスポート可能ですか？不変性は？SIEM 連携は？
• データレジデンシー：EU 顧客向けなど、データ保存リージョンを指定可能ですか？義務事項です。

信頼性#

• 稼働 SLA：99.9% ＝年 8.7 時間ダウン、99.99%＝52 分。認証＝アプリの玄関であり、この差は致命的。
• フェイルオーバー：ベンダーダウン時のバックアップ策は？複数リージョンデプロイ対応？
• インシデント履歴：ステータスページ等で「実際に起こった事」も確認。

データポータビリティ#

• ユーザーエクスポート：すべてのユーザーデータ、メタデータ、組織情報、ロール含め一括エクスポート可能か？フォーマットは？
• 標準準拠：OIDC・SCIM など標準プロトコル採用で他ベンダー移行容易か？
• ロックイン回避サイン：独自API・トークンフォーマット・非標準の利用はロックイン要因。標準プロトコル採用を優先するといずれ恩恵があります。

評価マトリクス：実践的なスコアリングフレームワーク#

全ての評価軸で比較した後、判断基準となる優先度フレームワークは次の通りです：

P1 — 採用NG基準（必須クリア・一つでもNGなら却下）#

P2 — 強く推奨（欠けた場合かなりの開発コスト）#

P3 — 重要（12ヶ月以内に必須レベル）#

P4 — あれば嬉しい（無くても選定阻害しない）#

使い方：まずP1全クリア必須。いずれかNGなら評価中止。P2・P3を加点式で比較。一番合計得点の高いベンダーが最適です。

よくある評価ミス#

私たちは現場で同じミスが繰り返されるのを見てきました。主なものと対策：

ミス1：機能で比べ、本質（構造）を見ない#

機能比較表は「何があるか」は教えますが、「どう実装されているか」は分かりません。IdP が「組織対応」と言っても、ユーザーメタデータ内のID管理だけなら本番運用では確実に難航します。

対策：「これを実際にはどう実装していますか？」を常に質問しましょう。

ミス2：移行検討を後回しにする#

最適と思った IdP を選んだ後で、ユーザー全員パスワードリセットが必要と判明—すでに実装を始めた後で気づくと手詰まりです。

対策：最初のフィルターに「移行性」を設定しましょう。

ミス3：デモに過大評価しがち#

どのベンダーのデモも美しく作り込まれています。クリーンなDB・例外ゼロのハッピーパスだけ。「本番」には結合アカウント・プロファイルの変なユニコード・不良セッションも山ほどあります。

対策：実データ1,000件を使ったPoCの提供を依頼しましょう。

ミス4：関係者の巻き込み不足#

プラットフォームチームだけで決めれば「技術的にキレイ」な案を選びます。プロダクトだけなら「統合しやすい」方に。セキュリティだけなら「コンプライアンス最優先」案に。

対策：プラットフォームエンジニア・プロダクト・セキュリティの横断チームで評価しましょう。それぞれP1/P2を担当する項目が異なります。

ミス5：将来の「離脱」を忘れる#

ベンダーロックインは現実です。独自SDKやAPI、非標準トークン— これらは将来の移行を困難にします。

対策：標準プロトコル（OIDC, OAuth2, SCIM）を採用する IdP を優先しましょう。将来必ず役に立ちます。

FAQ#

IdP の評価期間は通常どれくらいかかる？#

PoC テスト含む本格評価なら4～8週間見込み。急ぐと特に移行性で失敗します。要件定義2週間、ベンダー評価／PoC 2-3週間、関係者調整1-2週間を目安に。

自前で認証基盤を作るべきか？#

1万人未満＆エンタープライズ顧客なしなら、軽量認証ライブラリで十分。ただし、SSO・マルチテナンシー・MFA・コンプラ書類等が必要になると自作の保守コストは専門ベンダー利用を超えます。エンジニア2-3人分の工数（年間 300-500 万ドル以上）が掛かることも。

CIAM とワークフォース IAM の違いは？#

CIAM（Customer Identity and Access Management）はプロダクトのエンドユーザー側。ワークフォース IAM は自社社員が社内ツールを使うためのもの（Okta、Google Workspace など）。要件が異なり、選定軸も変わります。このガイドはCIAM向けです。

OSS版とプロプライエタリ（商用）どちらが重要？#

オープンソース IdP は透明性（コード監査可能）、ポータビリティ（自社ホスト可能）、コミュニティ貢献などの利点。商用 IdP はUIやマネージドサービスが強み。重要なのは「オープンかクローズか」でなく「必要なら抜けられるか」。データモデルとAPI公開済みの OSS は将来の移行も容易です。

AIエージェント認証はP1かP3か？#

既にAIと連携しユーザーデータ代理利用する（コパイロット、自動化フロー、AIアシスタント等）なら今すぐP1に。6~12ヶ月のロードマップにAIがあるならP3だけど重視。全く予定なしでも6ヶ月ごとに見直しましょう。

ベンダーごとに価格モデルが違う時、比較は？#

多くの IdP は月間アクティブユーザー（MAU）課金モデルですが、MAU の定義（ログイン件数・一意ユーザー・M2Mトークンを分離するか等）が異なります。必ず自社の前提（ユーザー数、組織数、M2M接続数、認証ボリューム）で各社見積りを取り、単価でなく総額で比較しましょう。

まとめ#

アイデンティティプロバイダの選定は「機能」より「インフラ」決定事項です。全ユーザーが最初に触れる窓口、API のすべての認可判定、コンプライアンス部門がチェックする監査ログもこの基盤に依存します。

上記フレームワークは本当に重要な基準のみを網羅し、マーケティングの箇条書きにはない落とし穴を防げます。すべての候補を素早く（P1）、深く（P2/P3＋PoC）検証し、「何年も運用できる答え」へと導きます。

正しくこの選定ができたチームに共通するのは、「アイデンティティをインフラの一部」と見なし、「出荷して忘れる機能」として扱わなかった点です。