--- title: "SaaSにおけるAIエージェントのアイデンティティ:何が異なりどう対処すべきか" description: "この記事でAIエージェントのアイデンティティが従来のアプリケーションクライアントのアイデンティティとどのように異なるか、既存のアイデンティティパターンがSaaSで破綻する理由、そして対策について学ぶことができます。 " authors: - name: "Carla Urrea Stabile" url: "https://auth0.com/blog/authors/carla-stabile/" date: "May 12, 2026" category: "AI" tags: ["ai", "ai agent", "identity"] url: "https://auth0.com/blog/jp-ai-agent-identity-saas/" --- # SaaSにおけるAIエージェントのアイデンティティ:何が異なりどう対処すべきか >本記事は「[AI Agent Authentication for SaaS: What's Different and What to Do About It](https://auth0.com/blog/ai-agent-identity-saas/)」を翻訳した記事です。今日、多くのSaaSプラットフォームではAIエージェントがAPIを使用しています。社内で構築されたものもあれば、顧客が作成したものや、誰も十分にレビューしていない統合を通じて導入されたものもあります。 APIを呼び出し、データを取得し、ユーザーの代わりにアクションを実行するエージェントを構築するツールは広く普及しており、簡単に使用できます。難しいのは、アクティブなエージェント、使用中の資格情報、アクセス可能な対象、責任の所在を把握することです。エージェントの出現とチームがアイデンティティ戦略を持つことのギャップが、本記事のテーマです。「AIエージェントを心配すべきか」ではなく、「エージェントはすでに存在しており、クライアントがLLMを利用したアプリケーションである場合のアイデンティティ管理はどのようになるか」について説明します。そして、ギャップは広がっています。SaaSのAPIを呼び出すエージェントの数は、多くのチームが追跡できる速度を超えて増加しています。アイデンティティ戦略がないまま1週間が経過するごとに、レビューも有効期限も所有者もない資格情報が発行され続けます。 ## AIエージェントのアイデンティティがカバーする範囲「エージェント認証」という言葉は通常、認証単体よりも広い意味を持ちます。実際に何が含まれるかを分解するとわかりやすくなります。 - **エージェントは誰か** 認証を指します。エージェントは認可サーバーに対して自身のアイデンティティを証明します。 - **何ができるか** 認可を指します。エージェントは特定のAPIやアクションに対するスコープ付きの権限を受け取ります。 - **シークレットはどのように管理されるか** 資格情報のライフサイクルです。プロビジョニング、ローテーション、有効期限、失効が含まれます。 - **何をしたか** 監査です。アクションを実行した特定のエージェントまで遡って追跡します。関連する資格情報は異なる目的を持ち、管理には異なる戦略が必要になるため、重要です。 ### 資格情報の種類クライアントを認証する方法は多数ありますが、最も一般的な資格情報の種類は以下の通りです。 **APIキー**は最もシンプルな資格情報です。エージェントはAPIに直接キーを提示し、APIは呼び出し元を特定して単一のステップでアクセスを許可します。設定は簡単ですが、制御力は最も低くなります。APIキーは通常、有効期限が長く、スコープがなく、アイデンティティとアクセスを分離しません。 [APIキーからOAuth2アクセストークンへの移行](https://auth0.com/blog/why-migrate-from-api-keys-to-oauth2-access-tokens/)により、**クライアントシークレット**と**アクセストークン**を使用して認証と認可を分離する、より動的なモデルを導入できます。 **クライアントシークレット**は、**認可サーバー**(Auth0やOktaなど)に対してエージェントを認証します。クライアントシークレットは、エージェントが主張する通りの存在であることを証明する手段です。認可サーバーはシークレットを検証し、有効であればトークンを発行します。 **アクセストークン**は、リソースにアクセスする目的でエージェントが**API**に提示するものです。アクセストークンはAPIに対してエージェントを認証するものではありません。認可サーバーがすでにエージェントのアイデンティティを検証し、特定の権限を付与したことを証明します。アクセストークンにはスコープ(エージェントに許可された操作)と有効期限が含まれます。エージェントがアクセストークンを取得する方法は、自身として機能するか、ユーザーの代わりに機能するかによって異なります。**クライアント資格情報グラント**は前者のケースをカバーします。エージェントはクライアントシークレットで認証し、自身の権限にスコープされたトークンを取得します。ユーザーは関与しません。認可コードグラントやデバイスコードグラントなどの**委譲フロー**は後者をカバーします。ユーザーは特定のスコープで機能するようエージェントを認可し、結果として得られるトークンはエージェントではなくユーザーの権限を表します。 ## エージェントのアイデンティティ管理が難しい理由フローに聞き覚えがあるのは当然です。バックエンドサービスが使用するものと同じです。以下のアイデンティティ課題もエージェント特有ではありません。あらゆるマシンクライアントに起こり得ます。違いはリスクプロファイルにあります。従来のクライアントアプリケーションでは、同じ入力に対して同じAPIを呼び出し、ソースコードを読んで動作を監査できます。エージェントはLLMの推論に基づいて呼び出すAPIを実行時に決定し、利用可能なものからツールを動的に選択し、プロンプトに応じてまったく異なるアクションを実行します。非決定性により、スコープ設定、監査、資格情報管理が難しくなります。さらに、エージェントは従来のサービスより早くデプロイされ、インフラストラクチャやセキュリティレビューなしに個人の開発者によって展開されがちです。アイデンティティの問題は新しくありませんが、エージェントは各問題を増幅させます。 - **APIキーとクライアントシークレットのスプロール化** 1つのエージェントが10になり、10が100になります。それぞれが独自のAPIキーやクライアントシークレットを持ちます。完全なリストを持つ人はおらず、定期的なサイクルでレビューする人もいません。エージェントは従来のサービスより監視が少なく迅速にデプロイされるため、状況を悪化させます。 - **デフォルトとしての長寿命なAPIキー** アクセストークンは設計上有効期限がありますが、APIキーには通常ありません。チームはシンプルであるという理由でAPIキーをデフォルトとし、キーは必要以上に長く残り続けます。実行時に呼び出すAPIを決定するエージェントにとって、長寿命でスコープのないAPIキーは無限のリスクとなります。 - **過剰な権限を持つアクセストークン** トークンのスコープを正しく設定するには時間がかかります。広いスコープを要求して次のタスクに移る方が簡単です。従来のサービスでは、常に同じエンドポイントを呼び出すため、過剰な権限を持つトークンは既知の限定的なリスクです。エージェントの場合、どのツールを使用するか予測できないため、広いスコープはより広く予測不可能な攻撃対象領域を意味します。 - **エージェントとユーザーを区別する監査証跡の欠如** エージェントがユーザーの代わりに機能する場合、ほとんどのシステムはトークンからクライアントIDまたはユーザーのアイデンティティを記録します。しかし、どのエージェントが決定を下したかを示す方法で両方を記録しません。アクションが発生したことは確認できても、ユーザーが直接行ったのか、エージェントが代わりに行ったのかを簡単に追跡できません。それぞれ単独では管理可能ですが、組み合わさると悪化します。広いスコープ、長寿命のAPIキー、ログに属性がないエージェントは、3つの問題が積み重なった状態です。 ## SaaSプラットフォームがよりリスクにさらされる理由 SaaS製品を構築している場合、エージェントはすでにAPIを呼び出しています。そして次の四半期にはさらに増えるでしょう。顧客のセールスエージェントはCRMのAPIからリードを取得します。サポート自動化はヘルプデスクAPIを通じてチケットを読み取り、応答します。ワークフローエージェントは、単一の実行でプロジェクト管理APIをSlackやGoogleカレンダーと連携させます。 Salesforce、Zendesk、Jira、Stripe、Slack(公開APIを持つあらゆるSaaS)などのプラットフォームでは、人間のトラフィックと並んでエージェントのトラフィックが見られます。違いは、SaaSプラットフォームがマルチテナントであり、APIファーストであり、サードパーティの統合向けに設計されていることです。マルチテナント、APIファースト、サードパーティ統合向けという組み合わせにより、上記のエージェントのアイデンティティ問題は管理が難しくなります。理由を分析します。 **APIを呼び出すエージェントを制御できない** 顧客は独自のエージェントを構築し、マーケットプレイスの統合をインストールし、サードパーティのツールをAPIに連携させます。OAuthスコープを定義して資格情報を発行しますが、各資格情報を使用するエージェントの数、顧客がシークレットを保存する方法、またはローテーションするかどうかは制御できません。顧客が1つのOAuthクライアントを作成し、異なるチームが構築した5つの異なるエージェント間でクライアントシークレットを共有する可能性があります。 **マルチテナントがリスクを高める** シングルテナントアプリにおけるスコープ設定の不適切なアクセストークンは、限定的な問題です。マルチテナントSaaSでは、影響範囲が広がります。顧客のエージェント資格情報が侵害されたり、過剰な権限を持っていたりする場合、認可レイヤーがすべてのリクエストで分離を強制しなければ、被害がテナントの境界を越える可能性があります。 **APIが攻撃対象領域となる** SaaS製品はAPI自体が製品であるため、幅広いAPIを公開します。開発者はAPIを統合し、API上に自動化を構築し、現在はエージェントをAPIに接続します。Stripeのようなプラットフォームは、支払い、顧客、サブスクリプション、レポートのエンドポイントを公開するかもしれません。しかし、請求書のステータスを読み取るだけでよいエージェントがAPI全体にスコープされたトークンを持っている場合、意図した以上の多くの操作を実行できます。 **顧客ごとにエージェント数が増加する** 3つのエージェントを持つ10人の顧客は、追跡してスコープを設定する30セットの資格情報になります。発行した資格情報は確認できますが、それぞれの背後にいくつのエージェントがいるか、またはエージェントが何をしているかは確認できません。可視性のギャップは顧客ベースとともに拡大します。 ## 対策 1. **現状を監査する** APIを呼び出している、自身の代わりに機能するエージェントに発行されたすべての資格情報をリストアップします。Auth0では、アプリケーションページのM2Mクライアントを確認し、それぞれの認可されたAPIとスコープを確認します。APIゲートウェイでは、有効期限のないアクティブなAPIキーや一般的な名前を探します。どの資格情報がエージェントのもので、どれが他の統合のものか区別できない場合、最初に修正すべき点です。 2. **APIキーからOAuthへ移行する** 長寿命のAPIキーを、認可サーバーを通じて発行される短寿命のアクセストークンに置き換えます。これにより、デフォルトで有効期限、スコープ設定、失効が可能になります。ユーザーの代わりに機能するエージェントの場合、[Token Vault](https://auth0.com/ai/docs/intro/token-vault)が認可コードまたはデバイスコードフローからの委譲されたトークンを管理し、更新とローテーションを処理するため、エージェントがユーザーの資格情報を直接保存することはありません。 3. **タスクへのアクセスをスコープする** 事前に広いスコープを要求するのではなく、エージェントが実行している特定のタスクに権限をスコープします。エージェントはタスクに必要なツールを呼び出す権限を取得し、タスクが完了すると権限は消滅します。[きめ細かな認可](https://auth0.com/fine-grained-authorization)と[OpenFGA](https://openfga.dev)を使用すると、カスタムの認可レイヤーを構築せずに実現できます。 4. **監査のギャップを埋める** エージェントがユーザーの代わりに機能する場合、監査証跡はどのエージェントが決定を下したかと、どのユーザーの権限を使用していたかの両方をキャプチャする必要があります。`client_id`(どのエージェントか)と`sub`クレーム(どのユーザーか)は両方ともアクセストークンに含まれています。APIレイヤーは、どちらか一方ではなく、すべてのリクエストで両方を抽出して一緒に記録する必要があります。 5. **SaaSプラットフォームの場合:自社側からアイデンティティを強制する** 顧客がエージェントを適切に管理することに依存しないでください。個別にスコープを設定して失効できるように、エージェントごとのクライアント登録を要求します。不適切に構築されたエージェントでも有効期限のあるトークンを取得できるように、認可サーバーで最大トークン寿命を設定します。クライアントIDごとにAPI呼び出しパターンを監視します。予期しない組み合わせの呼び出しを実行するエージェントは、スコープ設定だけでは捉えきれないシグナルです。 6. **人間の承認で機密アクションを制限する** リスクの高いアクション(購入、データ削除、権限変更)には、信頼できるデバイス上の人間からの明示的な認可を要求する必要があります。[Asynchronous Authorization](https://auth0.com/ai/docs/intro/asynchronous-authorization)は、エージェントのワークフローを中断することなく可能にします。エージェントを構築している場合や、エージェントが接続するSaaSを運営している場合、アイデンティティレイヤーはもはやオプションではありません。エージェントが資産になるか負債になるかを決定する要素です。[Auth0 for AI Agents](https://auth0.com/ai)は、トークン管理、きめ細かな認可、委譲されたアクセス、およびヒューマンインザループの承認を1つのプラットフォームで処理します。最後まで読んでいただきありがとうございます。 AIエージェントのアイデンティティとは何ですか AIエージェントのアイデンティティは、自律型ソフトウェアエージェントが認可サーバーに対してどのように認証するか、どのような権限を受け取るか、シークレットがどのように管理されるか、そしてアクションがどのように監査されるかをカバーします。認証用のクライアントシークレット、APIアクセス用のアクセストークン、APIキーなど、それぞれ独自の管理要件を持つさまざまな資格情報の種類が含まれます。 AIエージェントのアイデンティティは他のマシンクライアントのアイデンティティとどう違いますかアイデンティティのメカニズム(OAuth、クライアント資格情報、委譲フロー)は同じです。違いはリスクプロファイルにあります。エージェントはLLMの推論に基づいて呼び出すAPIを実行時に決定するため、動作が非決定的なものになります。ソースコードを読んでエージェントの動作を監査できないため、従来のサービスよりもスコープ設定、資格情報管理、属性の特定が難しくなります。 SaaSでAIエージェントのアイデンティティを管理する最良の方法は何ですか APIキーからOAuthに移行し、デフォルトで有効期限とスコープを持つ短寿命のトークンを取得します。エージェントが実行している特定のタスクにアクセスをスコープします。発行したすべてのエージェント資格情報のインベントリを維持し、Asynchronous Authorizationを使用してリスクの高いアクションには人間の承認を要求します。 SaaSプラットフォームがAIエージェントのアイデンティティリスクにさらされやすいのはなぜですか SaaSプラットフォームはマルチテナントであり、APIファーストであり、サードパーティの統合向けに設計されています。資格情報を発行しても、その背後にあるエージェントは制御できません。顧客ごとにエージェント数が増加し、認可レイヤーが分離を強制しない場合、侵害されたり過剰な権限を持ったりした資格情報がテナントの境界を越える可能性があります。 SaaSでAIエージェントを保護する方法エージェントのアイデンティティは、認証、認可、資格情報のライフサイクル、監査の4つの懸念事項をカバーします。それぞれに異なる管理ニーズを持つ異なる資格情報の種類が含まれます。アイデンティティのメカニズムは他のマシンクライアントと同じです。異なるのはリスクプロファイルです。非決定的な動作、動的なツール選択、監視のない迅速なデプロイメントが挙げられます。APIを呼び出すエージェントを制御できず、マルチテナントが影響範囲を広げ、顧客ごとに資格情報数が増加するため、SaaSプラットフォームはよりリスクにさらされます。発行した資格情報の監査から始め、APIキーからOAuthに移行し、スコープを最小限に抑え、Auth0 for AI Agentsのような専用ソリューションを使用します。