# AIエージェントをエンタープライズシステムに組み込む意思決定ポイント # 集中IDブローカー vs 連合認証 🎯 ポイント エージェントがSalesforce、ServiceNow、Workday、Box、Slackと横断的にアクセスするとき、認証をどう設計しますか？「全部Oktaに集約」と「各システムの既存SSOをそのまま使う」では、セキュリティモデルも運用コストもまったく違います。しかも多くの企業では、どちらか一方ではなく「集中ブローカーで統一認証→各SaaS側でスコープを絞る」ハイブリッドに落ち着きます。なぜそうなるかを理解することが、エージェント時代のID設計の出発点です🔑 📋 概要 集中IDブローカーは、OktaやAzure ADのような単一のIdPにエージェントの認証・認可を集約する方式です。OAuth 2.0 Token Exchange（RFC 8693）でユーザートークンからエージェント用のスコープ制限トークンを発行し、「誰が何をエージェントに委任したか」を一元管理できます。一方、連合認証は各SaaSの既存SAML/OIDC連携をそのまま活用する方式で、各事業部門の自律性と既存投資を活かせます。権限の一貫性と統制力を取るか、各システムの自律性と導入速度を取るかの選択です。 🔍 意思決定のポイント 最初の分岐は「全社IdPは統一されているか？」です。 OktaやAzure ADで統一済み → 集中ブローカーが自然な拡張です。エージェント用のOAuth 2.0 Token Exchangeを集約できる基盤がすでにあります。 IdPが事業部門ごとに分散 → 連合認証から始めるのが現実的です。統合コストを過小評価すると痛い目を見ます。 次に「エージェントがアクセスするシステム数」を確認します。5システム以上なら集中管理の効率が個別管理を上回ります。3システム以下なら個別連携でも十分運用可能です。 データ主権・地域規制も重要な軸です。GDPRや中国データ安全法により認証トークンを特定リージョンから出せない場合、連合認証またはリージョン別ブローカーを選ぶ必要があります🌍 💡 要点と詳細 集中IDブローカーの強みは、ゼロトラスト方針との親和性です。全アクセスをOPAやCedarのような単一ポリシーエンジンで検証し、エージェントの権限を「最小権限」で一括管理できます。定期的な権限棚卸も集中的に行え、SOX/ISMAPなどの監査証跡要件にも対応しやすい。新規にエージェント基盤を構築し、認証設計を白紙から始められる場合はこちらが第一選択です。 連合認証の強みは、既存投資の活用と導入速度です。各SaaSネイティブのSAML/OIDC連携が成熟している環境では、エージェント用に再構築する合理性がありません。M&A直後など異なる認証基盤の統合が中長期課題として残っている過渡期にも有効です。各システム固有のきめ細かい権限モデル（Salesforceのプロファイル/権限セット等）を集中化すると粒度が失われるリスクもあります。 ハイブリッドで最も一般的なのは「集中ブローカー＋ローカルスコープダウン」です。Oktaで統一認証した後、各SaaS側でエージェント専用のスコープ制限を適用します。もう一つの現実的なパターンは「フェデレーション＋集中監査」で、認証は各システムに委ねつつ、全認証イベントをSIEM（Splunk、Sentinel等）に集約して監査証跡の一元化だけを実現します🔐 ⚖️ トレードオフ 集中ブローカーの最大のリスクは単一障害点化です。IDブローカーの障害で全エージェントが停止する。冗長構成とサーキットブレーカーの設計を怠ると、全社業務に影響します。また、全権限変更が集中ブローカーのチケット承認を経由するため、事業部門のアジリティが低下するという声もよく聞きます。 連合認証のリスクはトークン管理の複雑化です。各SaaSごとに異なるトークンライフサイクル（Salesforceは2時間、ServiceNowは30分などデフォルト値がバラバラ）を管理し、リフレッシュ失敗やトークン失効の検知漏れが多発します。各SaaSの認証強度（MFA要否、セッション有効期限等）がシステムごとに異なり、最弱のリンクがセキュリティホールになるリスクもあります。 移行期の二重管理も見逃せない落とし穴です。連合から集中への移行途中に両方の仕組みが並存し、どちらがsource of truthか混乱する。カットオーバー基準を明確にした移行計画が不可欠です⚠️ 🛠️ ユースケース 全社統一IdP導入済みの大企業：Oktaで全社統一済み、エージェントが10以上のSaaSにアクセスする場合、集中ブローカーが最適です。Token Exchangeでエージェント用のスコープ制限トークンを発行し、OPAで統一ポリシーを適用。各SaaS側ではエージェント専用のサービスアカウントにローカルスコープダウンを設定します🏢 M&A直後の統合過渡期：異なるIdPを持つ2社が統合途中の場合、連合認証で早期稼働し、全認証イベントをSIEMに集約して監査だけ一元化するのが現実的です。高頻度アクセス先から順に段階的に集中ブローカーへ移行します🔄 地域規制が厳しいグローバル企業：GDPRやデータローカライゼーション要件がある場合、リージョン別のIDブローカーを配置するか、各リージョンの既存IdPを連合的に活用します。認証トークンがリージョンを越えない設計が必須です🌐 実践のコツ：いずれの方式でも、エージェントが保持するトークンの暗号化保存とメモリ上の保持時間最小化は必須要件です。移行に使える期間が3か月以内なら連合認証で早期稼働、中長期なら集中ブローカーへの段階的移行を計画してください💪 #AIエージェント# #エンタープライズアーキテクチャ#