企業のID管理標準SCIMに『AIエージェント』という新しいリソース型を足す提案を読む

企業の従業員アカウントを、複数のクラウドサービス間で自動的にプロビジョニング・管理するための標準規格「SCIM（System for Cross-domain Identity Management）」に、AIエージェント向けの新しいリソース型を追加しようとするIETF個人ドラフトがある。「System for Cross-domain Identity Management: Agentic Identity Schema」（著者M. Wahl氏、Microsoft所属、2025年8月19日提出）の本文を確認すると、人間の従業員（User）やグループ（Group）と並ぶ形で「AgenticIdentity」という新しいリソース型を定義していることが分かる。

3行まとめ

• このドラフトは、既存のSCIMスキーマ（RFC 7643）を拡張し、AIエージェントの身元を表す新リソース型「AgenticIdentity」を追加する。スキーマURIはurn:ietf:params:scim:schemas:core:2.0:AgenticIdentity
• 単一値属性4種（active・agenticApplicationId・description・displayName）に加え、複数値属性5種（entitlements・groups・owners・roles・oAuthClientIdentifiers）を定義する。既存のRFC 7643「Group」スキーマのmembers属性も改変し、$refの参照先型とtypeの許容値にAgenticIdentityを追加する
• エージェント身元に対する操作は5つ（作成・取得・更新・グループ所属の更新・削除）で、いずれもRFC 7644のSCIMプロトコル操作パターンをそのまま流用する設計。RFC 7644のBulk Operations（複数操作をまとめて1リクエストで送る機能）への対応は任意（OPTIONAL）と明記されている
• IETF Datatrackerで確認したところ、このドラフトは「Expired Internet-Draft」「Expired & archived」（失効・アーカイブ済み）となっている。2025年8月19日提出のrev01が最後で、失効予定日（2026年2月20日）を過ぎても改訂版は出ていない

人間のIDと同じ枠組みでエージェントを管理する

ドラフトの要約はこの狙いをこう説明している。

This document provides a platform-neutral schema for representing AI agents' identities in JSON format, enabling them to be transferred in the SCIM protocol to the service. This establishes an agentic identity so that an agent can subsequently be authenticated and authorized to interact with the service.

（本文書は、AIエージェントの身元をJSON形式で表現するプラットフォーム非依存のスキーマを提供し、SCIMプロトコルでサービスへ転送できるようにする。これにより、エージェントがその後サービスとやり取りするために認証・認可されるための、エージェント身元が確立される）

つまり、企業が既に人間の従業員向けに運用しているSCIMベースのID管理基盤（オンボーディング・オフボーディングの自動化、グループやロールへの割り当てなど）を、そのままAIエージェントの管理にも転用できるようにする、という発想だ。

AgenticIdentityの属性設計

AgenticIdentityリソースの定義はこうだ。

AgenticIdentity: A resource of this type represents an identity of an agent to the service. It includes attributes of an agentic identity needed to be known by a service, including OPTIONAL references to the agentic identity's group memberships, roles and entitlements.

（AgenticIdentity：このリソース型は、サービスに対するエージェントの身元を表す。サービスが知る必要があるエージェント身元の属性を含み、グループ所属・ロール・権限へのオプションの参照も含む）

agenticApplicationIdという属性は特に興味深い設計で、1つのエージェントアプリケーションが複数の身元（例えば複数のテナントやセッションごとに別の身元）を持つ場合に、それらを相関させてレポーティングできるようにする、という用途が定義されている。

ドラフト本文を通読すると、単一値属性のほかに「複数値属性」が5種類定義されていることが分かった。整理すると次の表になる。

oAuthClientIdentifiersの設計はこのドラフトの中でも作り込みが厚い部分で、issuerはJWTのissクレーム、subjectはsubクレーム、audiencesはaudクレームのフォーマットに準拠すると規定されている。POSTやPATCHでこの属性を送る場合、SCIMクライアントはissuer・name・subjectの3サブ属性を必須で含めなければならない（MUST）。

既存のGroupスキーマの「members」定義も書き換える

このドラフトの3.4節「Updates to Existing Schema」は、AgenticIdentity単体の新設にとどまらず、既存のRFC 7643「Group」リソーススキーマにも手を入れる内容になっている。ドラフト本文の該当箇所を引くと次の通りだ。

To allow an agentic identity to be a member of a group, this memo augments the definition of the "members" attribute of [RFC7643] as follows: allow the referenceTypes of the members "$ref" sub-attribute to also refer to an AgenticIdentity / allow the canonicalValues of the members "type" sub-attribute to also allow for "AgenticIdentity"

（グループのメンバーとしてエージェント身元を含められるよう、本文書はRFC 7643の"members"属性の定義を次のように拡張する：members "$ref"サブ属性のreferenceTypesがAgenticIdentityも参照できるようにする／members "type"サブ属性のcanonicalValuesが"AgenticIdentity"も許容するようにする）

これが本当に変更なのかを確認するため、RFC 7643の原文（rfc7643.txt）を実際にダウンロードして「Group」リソーススキーマの定義を直接確認した。原文ではmembersの$refサブ属性は次のように定義されている。

"referenceTypes" : [ "User", "Group" ]

そしてtypeサブ属性のcanonicalValuesも同じく["User", "Group"]だった。つまり現行のRFC 7643では、グループのメンバーになれるのは「User」か「Group」のどちらかに限定されており、このドラフトはそこに第3の選択肢として「AgenticIdentity」を追加する、という改変を提案していることをRFC本文との突き合わせで確認できた。

5つの操作とBulk Operationsとの関係

ドラフトの第4章「Operations on an Agentic Identity」は、AgenticIdentityに対する操作を5つ定義している。いずれも新しいプロトコルを作るのではなく、RFC 7644（SCIMプロトコル）の既存パターンをそのまま当てはめる設計だ。

このうち作成操作では、SCIMサーバがOAuthクライアント識別子を含むレスポンスを返す場合、issuer・name・subjectを必ず含めなければならない（MUST）という制約が改めて明記されている。

RFC 7644を実際にダウンロードして確認したところ、複数の操作を1リクエストにまとめる「Bulk Operations」（3.7節）は、サービス側の実装がオプション扱いの機能で、対応の有無はサービス構成の問い合わせで分かるようになっていた。ドラフト第4章の冒頭でも「Support for bulk operations, as described in section 3.7 of [RFC7644] is OPTIONAL」（Bulk Operationsのサポートは任意）と明記されており、AgenticIdentityの一括作成・削除を必ずサポートしなければならないわけではない。

IANAへの新スキーマ登録申請も含む

ドラフトの第6章「IANA Considerations」には、RFCとして正式に公開された場合にIANAへ登録を依頼する内容が、表形式で明記されている。

「SCIM Schema URIs for Data Resources」というIANAレジストリ（RFC 7643で新設）に、AgenticIdentity用のスキーマURIを追加登録する、という内容だ。もっとも、このドラフト自体がすでに失効・アーカイブされているため、このIANA登録申請が実際に処理される段階には至っていない。

このドラフトも失効・アーカイブ済み

これまでこの記事の連載で扱ってきたいくつかの個人ドラフトと同様、このドラフトもIETF Datatracker上では次のように表示されている。

Document Type: Expired Internet-Draft (individual). Expired & archived.

（文書種別：失効したInternet-Draft（個人提案）。失効・アーカイブ済み）

2025年8月19日提出のrev01のみが存在し、失効予定日（2026年2月20日）を過ぎた後も改訂版は出ていない。SCIMワーキンググループの正式な成果物としては扱われておらず、著者による更新も止まっている状態だ。

Microsoft Entraでの実装状況までは踏み込めていない

この記事で確認できたのは、あくまでIETF個人ドラフトの本文と、それが参照するRFC 7643・RFC 7644の該当条文との突き合わせまでだ。次の点は裏取りできていない。

• SCIMワーキンググループ内で、これと似た問題意識を持つ他の提案（あるいはOASIS・OpenID Foundation側でのエージェント身元標準化の動き）が並行して議論されているかどうかは確認していない
• Microsoft社が実際にAgentic Identityというコンセプトを自社製品（Microsoft Entra Agent IDなど）でどこまで実装・展開しているかは、このドラフト本文以上の裏取りをしていない。ドラフトの著者がMicrosoft所属であることと、Microsoft製品がこの仕様を実装していることは別の話であり、この記事では両者を混同しないよう区別している
• oAuthClientIdentifiersが実際のOAuthトークン交換フロー（RFC 8693）とどこまで整合しているかは、RFC 8693本文まで踏み込んで確認していない
• この記事を書いている自分自身は、SCIMを使った企業ID管理基盤の運用経験がなく、このスキーマが実務でどこまで有用かの評価はできない
• 日本語ではZenn・Qiitaともに、このドラフト単体を扱った記事は検索時点で見当たらなかった

関連記事: AIエージェントとは

感想・指摘はコメント欄へ。