AIエージェントのアイデンティティ：どの企業も後回しにしてきた問題

簡潔な答え：社内でAIエージェントを動かすなら、従業員にアカウントが必要なのとまったく同じように、エージェントにも独自のアイデンティティが必要です。現在よく見られるやり方、つまりエージェントがシステムにアクセスできるよう静的なAPIキーをエージェント内にハードコードする方法は、最も危険な選択です。そのキーは期限切れにならず、誰が使っているのか誰にも分からず、必要なときにすぐ取り消すこともできないからです。正しいアプローチは、すべてのエージェントに登録済みのアイデンティティ、範囲を限定した権限、そして自動的に失効する短期トークンを与えることです。

まさにそれを、世界最大級のアイデンティティ管理ベンダーであるOktaが2026年8月24日に、Agent SSOという新機能として発表しました。このアイデアは表面的にはシンプルですが、その影響は深いものです。AIエージェントを人間の従業員と並ぶファーストクラスのアイデンティティとして社内ディレクトリに登録し、アクセスの付与、監視、取り消しに同じツールが適用されるようにするのです。

なぜこの問題が今、急を要するのか

この二年間で、企業のAIは「質問に答えるボット」から「仕事をこなすエージェント」へと移行しました。今日のエージェントは、CRMを開き、注文を読み取り、在庫記録を更新し、顧客にメッセージを送り、請求書の作成まで行うこともあります。そのすべてのステップが、実際のデータを持つ実際のシステムへのログインを意味します。

問題は、ほとんどの企業のセキュリティツールが、システムにログインするのは人間であるという一つの前提の上に作られていることです。Oktaが発表の中で引用した印象的な数字が、そのギャップを表しています。人間の従業員と同じセキュリティ管理をAIエージェントに適用している組織は、わずか34%にすぎません。言い換えれば、およそ三分の二の企業が、同じレベルのガバナンスなしに自動化された存在をシステム内で動かしているのです。

エージェントに明確なアイデンティティがないと、問題は積み重なり、しかもそれらはすべて同じ種類のものです。社内で何体のエージェントが動いているのか分からない、それぞれを誰が承認したのか分からない、「この操作を行ったのは誰か？」という監査人の単純な質問に答えられない、そして暴走したエージェントを止めるために押せる一つのボタンもない、ということです。

Agent SSOは実際に何をするのか

このサービスは、Cross App Access（XAA）と呼ばれるオープンなプロトコル上で動作します。これはおなじみのOAuth標準の拡張で、エージェントとシステムの共通言語となったプロトコルであるMCPの、公式なエンタープライズ管理型認可拡張として採用されています。簡単に言えば、このプロトコルに対応したAIエージェントが自社の業務アプリケーションに接続しようとすると、次のことが起こります。

  • 登録：エージェントは匿名のキーではなく、名前を持つアイデンティティとして社内ディレクトリに記録されます。
  • 認可：設定ファイルに置かれた静的キーの代わりに、自動的に失効する短期のアクセストークンを受け取ります。
  • ガバナンス：管理者は、従業員の権限に使うのと同じコンソールからエージェントの権限を管理します。
  • 即時の取り消し：振る舞いがおかしいと見えた瞬間に、一つの操作でエージェントのアクセスを遮断できます。

注目すべきは、OktaがAgent SSOを追加費用なしで中核のシングルサインオン製品の一部にしたことです。これは、このパターンをプレミアム機能として売るのではなく、標準として広めたいというシグナルです。発表では、このアプローチで同社と協力している企業として、Anthropic、Atlassian、Slack、Notion、Datadog、Figmaなどの名前も挙げられました。

新しいルール：社内で動くすべてのAIエージェントには、名前、責任を負う人間のオーナー、範囲を限定した権限、そして有効期限が必要です。従業員とまったく同じように。

サウジアラビアの経営者にとっての意味

王国が「人工知能の年」と定めたこの年、企業は顧客サービス、営業、業務運営にAIエージェントを急速に導入しています。そして試験導入から本格的な本番運用への移行こそ、アイデンティティと権限が技術的な細部ではなく中核的な関心事になる瞬間です。

規制面の側面もあります。個人データ保護法（PDPL）は、組織が誰がどのような目的で個人データにアクセスするかを管理し、監査の際にそれを証明できることを求めています。AIエージェントが特定の誰にも属さない共有キーを通じて顧客データを読み取っている場合、「誰がこのデータにアクセスしたのか？」という質問に事実上答えられません。それは単なる技術的な弱点ではなく、コンプライアンス上の欠陥です。

今日から始められる実践的なステップ

始めるのにグローバルなプラットフォームは必要ありません。同じ原則は、きちんと構築されたあらゆる社内システムに当てはまります。

  • エージェントの棚卸し：現在システムに接続されているすべてのAIツールを一覧にしてください。その数に驚くはずです。
  • エージェントごとに個別のアカウント：従業員のアカウントや汎用キーを複数のツールで共有してはいけません。
  • 最小権限：エージェントが読み取りだけを必要とするなら、変更や削除の権限を与えてはいけません。
  • 短期トークン：永続的なキーを、自動的に失効・更新されるトークンに置き換えてください。
  • 完全な監査証跡：エージェントが行うすべての操作を、その名前、タイムスタンプ、影響を受けたシステムとともに記録します。
  • 人間のオーナー：各エージェントには責任を負う従業員がいて、定期的に権限を見直し、エージェントを停止できるようにします。
  • 機微な操作には人間の承認を：送金、データの削除、顧客への一斉メッセージには、人間によるチェックポイントが必要です。

Origamiでの考え方

クライアント向けにカスタムシステムを構築し、そこにAIエージェントを接続する際、私たちは初日からそのエージェントを、管理者のキーで動くスクリプトとしてではなく、アカウント、権限、ログを持つユーザーとして扱います。このシンプルな設計上の判断により、クライアントは後で作り直す必要がなくなり、監査人からの最初の質問や最初のセキュリティインシデントの時点で継ぎはぎするのではなく、最初から監査に対応できるシステムになります。

Oktaの発表が重要なのは、これまで個々の開発者の判断に委ねられていたことを、大手ツールベンダーが支える業界標準に変えたからです。今日この基盤の上に構築する人は、一、二年後に基本要件となるものに自然と沿っていることになるでしょう。

結論として、社内のAIはもはや使う道具ではなく、あなたに代わって行動する当事者です。そして、あなたに代わって行動するあらゆる当事者には、アイデンティティと明確な境界が必要です。そうでなければ、目に見えないリスクを管理していることになります。

出典