本記事は「The product architecture behind trusted AI experiences」を翻訳した記事です。
アイデンティティがAIアーキテクチャの中核である理由と、安全でスケーラブルかつ信頼できるAIエージェントを構築するために非人間アイデンティティを管理する方法を学びます。
現代のアプリケーションは矛盾する要件に直面しており、セキュリティ、プライバシー、ユーザーエクスペリエンスのバランスを取りながら、同時にあらゆる方向へ対応を迫られています。コンバージョンとパーソナライゼーションを最大化すると同時に、ますます高度化する自動化された脅威から防御することが求められます。通常、エンジニアリングチームは別々のワークストリームとして扱います。グロースチームがUIを担当し、セキュリティチームが境界を管理します。
AIを導入すると、分離は機能しなくなります。自律型エージェントがデータと対話し始めると、「境界」は消滅します。システムを管理するために残されるのはアイデンティティだけです。
ほとんどのレガシーアーキテクチャにおいて、アイデンティティは「チェックボックス」機能でした。つまり、ログインページとハッシュ化されたパスワードのデータベースです。しかし、AIエージェントがユーザーの代わりに行動できるプロダクトエコシステムでは、アイデンティティはスタックの端からプロダクトアーキテクチャの中核へと移動する必要があります。
誰が、あるいは何がアクションを実行しているのか、そして許可する具体的なコンテキストを正確に把握していなければ、AIエクスペリエンスを構築しているのではなく、負債を構築していることになります。
本記事では、アイデンティティが機能からプロダクトアーキテクチャの中核部分へとどのように変化したか、そして信頼されるAIエクスペリエンスを構築するための基盤になりつつある理由を見ていきます。
アイデンティティは今やプロダクトアーキテクチャの一部
従来、アイデンティティはラッパーでした。アプリを構築してから「認証を追加」していました。結果として、アイデンティティロジックがさまざまな場所に存在する断片化された現実をもたらしました。一部はゲートウェイに、一部はマイクロサービスに、そして一部はフロントエンドにハードコードされていました。
アイデンティティが断片化されると、プロダクトの速度が低下します。コードが悪いからではなく、「信頼できる情報源」が分散しているからです。ユーザーはウェブアプリでリソースを表示する認可を受けていても、APIの古いポリシーによってブロックされる可能性があります。不整合は「アイデンティティ負債」を生み出し、新機能を迅速に出荷することを不可能にします。
最新のアーキテクチャでは、アイデンティティは共有システムとして機能します。認証（本人が主張する通りの人物か）と認可（現在何を許可されているか）を処理する一貫した方法を提供します。一元化することで、複雑さを個々のサービスから専用レイヤーに移動させます。これにより、開発者はOAuthフローを継ぎ接ぎするのではなく、機能の構築に集中できます。
アイデンティティがセキュリティだけでなく成長に直接影響する理由
成長が鈍化すると、プロダクトやマーケティングの問題として捉えられがちです。コンバージョンが低下したり、エンゲージメントが薄れたり、拡大に予想以上の時間がかかったりします。しかし多くの場合、問題はシステムのより深い部分にあります。ユーザーがプロダクトにどのように入り、移動し、戻ってくるかに現れます。
コンバージョン
最初のやり取りは最も脆弱です。オンボーディングフローで手動入力が多すぎたり、ユーザーがプロダクトの価値を確認する前にパスワードのリセットを強制したりすると、ユーザーは離脱します。
最新のアイデンティティでは、プログレッシブプロファイリングが可能になり、必要なときにのみデータを収集できます。ソーシャルログインやパスキーを使用することで、価値実現までの時間を短縮できます。さらに重要なことに、アイデンティティは最初の「誰」を提供し、ユーザーが最初に見る画面を調整できるようにします。
リテンションとエンゲージメント
ユーザーはセッションやシステムの観点では考えません。継続性を期待しています。モバイルデバイスでワークフローを開始し、デスクトップで終了する場合、2つの異なる企業とやり取りしているように感じるべきではありません。
アイデンティティがアーキテクチャに統合されていないと、コンテキストが失われます。セッションの有効期限が早すぎたり、設定が同期されなかったりします。統合されたアイデンティティレイヤーにより、「ユーザーステート」をすべてのタッチポイントで永続化できます。これは高いリテンションのための実際の要件です。
拡大
B2Bプラットフォームの場合、「拡大」フェーズには通常、単一ユーザーから組織全体への移行が含まれます。これには基本的なログイン以上のものが必要であり、堅牢なマルチテナンシーと洗練されたガバナンスが必要です。
アイデンティティシステムが複雑な組織階層やエンタープライズ顧客向けの「Bring Your Own Identity」(BYOID)を処理できない場合、営業チームは壁にぶつかります。エンタープライズバイヤーとの信頼を拡大するということは、ワークフローを壊すことなく、テナント全体で特定のセキュリティポリシーを適用できることを証明することを意味します。
アイデンティティが中核的なアーキテクチャの柱である場合、マルチテナンシーはデータベースの上に重ねられた「ハック」ではありません。データ分離を可能にしながら、大規模で柔軟な属性ベースのアクセスを許可する強固な境界です。
アイデンティティがマシンを管理する必要があるためAIがルールを変える
テキストを要約するだけでなくアクションを実行できるエージェントAIの台頭は、大規模なセキュリティギャップを生み出します。従来のアイデンティティモデルは、数時間続き、人間がボタンをクリックする人間のセッション向けに構築されていました。
AIエージェントはそのようには機能しません。
アクションはもはやセッションに結びついていない
AIエージェントは、数日間続く一連のイベントをトリガーする可能性があります。単一のタスクを完了するために5つの異なるマイクロサービスを呼び出すかもしれません。セキュリティモデルが一時的なブラウザCookieに依存している場合、機能しません。
元の人間の意図に結びつきつつも、実際に実行できる内容が制限された「スコープ付き」の認証情報をエージェントに発行する方法が必要です。ここで非人間アイデンティティ(NHI)管理がスタックの最も重要な部分になります。
アクセス決定はリアルタイムで行う必要がある
エージェントの世界では、権限を静的にすることはできません。AIに「管理者」権限を与えてうまくいくことを祈るだけでは不十分です。アクセス決定はリクエストの瞬間に評価する必要があります。
従来のロールベースアクセス制御(RBAC)は、これには大雑把すぎます。エージェントに「マネージャー」ロールを割り当てることは大規模な過剰権限です。マネージャーが見ることができるすべてのものに、AIが常にアクセスできるようになります。代わりに、システムはアクター、アクション、特定のリソース間の関係を理解する必要があります。
これには継続的認証への移行が必要です。システムはリクエストの動的コンテキストを確認する必要があります。
- エージェントは特定のサブタスクに必要な量以上のデータを要求しているか
- リクエストは異常な頻度で発生しているか
- 特定のエージェントは、まさにこの瞬間に、特定のテナントの特定のデータ行と証明された関係を持っているか
アイデンティティがアーキテクチャに組み込まれている場合、システムはデータベース内の静的な「ロール」を確認するだけでなく、ライブの関係を評価します。異常が検出されたり、関係の境界を越えたりした瞬間に、システムはセッションを即座に強制終了できます。
帰属は機能ではなく要件になる
AIエージェントが間違いを犯したり、悪意のあるアクターが操作したりした場合、決定論的な監査証跡が必要です。以下の質問に答えられる必要があります。
- どのモデルがリクエストを行ったか
- どのユーザーがエージェントの行動を認可したか
- どの特定のポリシーがデータアクセスを許可したか。一元化されたアイデンティティレイヤーがなければ、質問には答えられません。アイデンティティは、AIが実行するすべてのアクションの「出所」を提供します。
アイデンティティアーキテクチャが特定の業界に与える影響
アーキテクチャの移行は、理論から技術的負債へと急速に変化します。認可ロジックがサービス間で断片化されると、特にシステムがより分散され、AIエージェントが導入されるにつれて、プロダクトの動作に不整合が生じます。
小売
小売業において、アイデンティティはコンバージョンの経路に直接位置しており、「一般的な」店舗とパーソナライズされたコンシェルジュの違いを生み出します。顧客がウェブ、モバイル、店舗全体で認識されれば、小売業者は単一の統合されたカートを提供できます。
しかし、AIショッピングアシスタントが導入された場合、アシスタントはユーザーの支払い情報への制限付きアクセスを必要とします。チェックアウトには十分ですが、配送先住所を変更したり、注文履歴全体を表示したりするには不十分なアクセスです。アイデンティティはスコープ設定を処理します。
金融サービス
金融サービスでは、アイデンティティの決定が絶えず行われ、エラーの許容範囲はより小さくなります。ユーザーは迅速なオンボーディングとスムーズなアクセスを期待しますが、アクションが機密性を帯びた場合には強力な保護も期待します。
フィンテックにおける信頼は「ステップアップ」エクスペリエンスの上に構築されます。残高を確認するのに指紋スキャンは必要ありませんが、10,000ドルを送金するには間違いなく必要です。最新のアイデンティティアーキテクチャでは「リスクベース認証」が可能になり、システムはリスクが正当化する場合にのみ摩擦を追加します。
AIを使用して取引や不正検出を自動化する場合、アイデンティティは自動化されたエージェントが厳格な法的および規制の境界内で動作していることを確認します。
ヘルスケア
ヘルスケアにおいて、アイデンティティは信頼とプライバシーに密接に結びついており、そこでのリスクは最も高くなります。
患者データは「サイロ化」されている必要がありますが、適切なプロバイダーが適切なタイミングでアクセスできなければなりません。AIを使用して検査結果を分析する場合、アイデンティティレイヤーは、AIが分析に必要な特定の記録のみを参照すること（最小特権の原則）、およびデータが復号化される前に患者の同意がリアルタイムで検証されることを確認します。
B2BSaaSプラットフォーム
SaaS環境では、アイデンティティの複雑さが急速に増します。
ユーザーだけでなく、組織、ロール、権限、そしてますますワークフローに直接組み込まれるAI機能を管理します。エージェントはユーザーの代わりに行動したり、システム間でアクションをトリガーしたり、外部サービスと対話したりする可能性があります。
基本的に、B2BSaaSは「マルチテナント」AIに向かっています。つまり、AI機能は数千の異なる企業のデータを同時に処理しています。最大のリスクは「クロステナント」のデータ漏洩です。強力なアイデンティティアーキテクチャは、A社のために働くAIエージェントが、同じ基盤となるLLMを使用している場合でも、いかなる状況下でもB社のデータを「見る」ことができないことを確認します。
アイデンティティを運用する方法
アイデンティティを周辺機能から中核的なアーキテクチャコンポーネントに移行することは、重要なエンジニアリングの転換です。ほとんどのチームは、アイデンティティを継続的な運用規律ではなく、1回限りの統合タスクとして扱うため、ここで失敗します。
ポリシーをコードから分離する
プロダクトアーキテクチャにおける最も一般的な間違いは、認可ロジックをアプリケーションコードに直接埋め込むことです。if (user.role == 'admin')がマイクロサービス全体に散在している場合、メンテナンスの悪夢を作り出しています。アイデンティティを運用するには、ポリシーを基盤となるビジネスロジックから分離する必要があります。
外部化された認可サービス、特にRelationship-Based Access Control(ReBAC)向けに構築されたサービスに移行することで、セキュリティチームとプロダクトチームはアクセスルールをリアルタイムで動的に更新できます。
権限を変更するためにコードを再デプロイする代わりに、関係グラフを更新するだけです。これにより、AIエージェントの進化に伴い、マイクロサービスロジックを1行も変更することなく、セキュリティ体制も共に進化することが確認されます。
トークン交換の問題を解決する
分散システム、特にAIエージェントが関与するシステムでは、アクターの「アイデンティティ」はスタックを移動するにつれて頻繁に変化します。ユーザーがログインし（ユーザーコンテキスト）、AIエージェントをトリガーし（サービスコンテキスト）、エージェントがデータベースを呼び出します（リソースコンテキスト）。
これを運用するには、堅牢なトークン交換パターンが必要です。ユーザーの元のJSON Web Token(JWT)をチェーン全体に単に渡すことはできません。それは大規模なセキュリティリスクであり、広範すぎるアクセスを提供します。代わりに、アーキテクチャはトークンのダウンスコーピングをサポートする必要があります。リクエストチェーンの各ホップは、特定のタスクを実行するために必要な絶対最小限のスコープを持つトークンを受け取ります。
NHIのライフサイクルを自動化する
AIエージェントの計画にサービスアカウントの作成とシークレットマネージャーへのAPIキーの保存が含まれている場合、運用しているのではなく、バックドアを作成しているだけです。
NHIには、人間のユーザーと同じ（またはより厳格な）ガバナンスが必要です。これは以下を意味します。
- 自動ローテーション: キーとシークレットは人間の介入なしに期限切れになり、ローテーションされる必要があります。
- 行動監視: エージェントには「通常の」営業時間がないため、「通常の」行動のベースラインを確立する必要があります。通常は単一行のみをクエリするエージェントが突然データベースの一括エクスポートを要求した場合、アイデンティティレイヤーは自動的に認証情報を失効させる必要があります。
- 帰属マッピング: すべてのNHIは「ヒューマンインザループ」または特定のサービス所有者にマッピングされる必要があります。エージェントが誤動作した場合、誰が作成したかを見つけるためにログを探し回るべきではありません。
「2日目」の運用に向けて構築する
ほとんどのアイデンティティプロジェクトは「1日目」、つまりユーザーをログインさせることに焦点を当てています。卓越した運用とは「2日目」に関するものです。ユーザーが物理的なMFAキーを紛失した場合はどうなるでしょうか。顧客のテナントを異なるデータレジデンシー法を持つ別のリージョンに移行する必要がある場合はどうなるでしょうか。
アイデンティティを運用するということは、エッジケースのための「配管」を早期に構築することを意味します。これには、Security Information and Event Management(SIEM)に供給される一元化されたロギング、手動のヘルプデスクチケットに依存しないセルフサービスリカバリフロー、侵害された組織のすべてのセッションをすべてのサービスにわたって即座に失効させることができる「キルスイッチ」機能が含まれます。
アイデンティティは信頼を拡大する方法
アプリケーションが「使用するツール」から「代わりに行動するエージェント」へと移行するにつれて、エラーの許容範囲はなくなります。関係を認識するアイデンティティレイヤーがなければ、「チームのパフォーマンスを要約して」という単純なプロンプトで、社内のすべての給与や非公開の人事ファイルへのアクセスをエージェントに許可してしまう可能性があります。
単一の誤って構成された権限や過剰なスコープのトークンは、もはや軽微なバグではありません。大規模な脆弱性です。複雑さはセキュリティの敵です。アイデンティティロジックが20の異なるサービスに分散している場合、失敗する場所が20箇所あることになります。
アイデンティティを中核的なアーキテクチャレイヤーとして扱うことで、単にドアに鍵をかける以上のことができます。一貫性があり、追跡可能で、スケーラブルなシステムを作成します。基盤となるアイデンティティフレームワークが機能を境界内に維持することを知っているため、チームに積極的なAI機能を構築する自由を与えます。
人間がリンクをクリックする場合でも、AIエージェントがAPIを呼び出す場合でも、すべてのやり取りは「これは誰で、何を許可されているか」という同じ基本的な質問から始まります。毎回その質問に正しく答えることが、人々が実際に信頼するプロダクトを構築する唯一の方法です。
アイデンティティがAI、成長、信頼をどのようにサポートするかについてさらに詳しく知りたいですか。 Secure every interaction: A leader’s guide to identity in an agentic worldを確認ください。
About the author
Saad Rahman
Staff Product Marketing Manager, Auth0 Solutions