AIエージェントがチームの一員として最大限に働くには、人間と同じツール・ドキュメント・コンテキストにアクセスできる必要がある。1人のユーザーが1つのアシスタントと対話する「シングルプレイヤー」型なら話は単純で、自分のアカウントを繋いでエージェントに代理操作させればいい。しかしClaude Tagのように、Claudeが共有チャンネルで複数の人と同席し、特定個人ではなくワークスペースのツールとコンテキストを使う「マルチプレイヤー」型では、この前提が崩れる。

Anthropicはこの課題への答えとして、エージェントアイデンティティ（agent identity）というアクセスモデルを提示した。管理者がワークスペースに紐づくアカウントをClaude自身に用意し、権限を「ユーザー単位」から「チャンネル単位」へと移す考え方だ。Claude CodeチームのNoah Zwebenによる解説記事をもとに、その仕組みを整理する。

「ユーザーとして振る舞う」モデルが破綻する理由

AIを個人アシスタントとして使うときは、Google Drive・GitHub・カレンダーなどを接続し、自分のアクセス権でモデルに読み書きさせればよかった。だがこのモデルはClaude Tagでは二つの理由で機能しない。

エージェントの自律性の増大

AIが単独で完了できるタスクの長さは約4ヶ月ごとに倍増している。エージェントは自分でタスクを後回しにスケジュールし、依頼者がログオフした後にイベントへ反応して動く。動作は largely autonomous。

マルチプレイヤーなチーム

3人のエンジニアとPMが同じチャンネルでデバッグしている――複数人が舵を取るとき、誰の権限を適用すべきか。常に正しい一人の選択は存在しない。

Claudeは「Claude自身」として動く

Claude Tagが有効なチャンネルでは、Claudeは単一ユーザーの代理ではなく、触れる各システムに自分のアカウントを持つ。SlackにはClaudeアプリとして投稿し、プルリクエストはClaude GitHub Appとして開き、データウェアハウスには管理者が用意したサービスアカウントで問い合わせる。個人の認証情報が一切使われないため、共有チャンネルが誰かの私的ドキュメントへの裏口になることが原理的にあり得ない。

権限の継承とオーバーライド

このモデルでは、管理者がワークスペースレベルで「アイデンティティ」――Claudeがどこでも持つ接続とスキルのベースライン――を定義し、各チャンネルがデフォルトでそれを継承する。そのうえで、理にかなう場所だけチャンネル単位でオーバーライドする。たとえばengineeringチャンネルにのみGitHubとデータウェアハウスを付与したり、CRM接続を特定のプライベートチャンネル1つに閉じ込めたりする。

管理者が認証情報に加えて定義できるのは次の要素だ。

リポジトリアクセス

Claudeが読み書きできるリポジトリの範囲。

コネクタ

Claudeが仕事に使うツールとAPIキー。組織全体で、同じサービスに対し異なる権限レベルのAPIキーを使い分けられる（一般チャンネルでは読み取り専用、データチームのプライベートチャンネルでは書き込み可、など）。

スキルとプラグイン

特化タスクの性能を上げるために動的にロードする、指示・スクリプト・リソースのフォルダ群。

常駐指示（standing instructions）

各チャンネルごとのカスタム指示とコンテキスト。

そして、このモデルが個別のClaudeアイデンティティを軸に動くため、アイデンティティを取り消せばそれが使われていた全ての場所でアクセスが終了する。何十ものユーザーアカウントを横断して個々のエージェント操作を監査するより、はるかに少ない労力で管理できる。

エージェントアイデンティティモデルの仕組み

エージェントアイデンティティは「このユーザーは何ができるか？」という問いを、「このエージェントはこの区画（compartment）で何ができるか？」に置き換える。これは従来のper-user ACL（アクセス制御リスト）からの明確な departure だ。つまり、リポジトリに直接アクセス権を持たないチャンネルメンバーでも、チャンネルのプロファイルがClaudeにその権限を与えていれば、Claudeに頼んでそのリポジトリを読ませることができる。

アイデンティティ境界の働き方

Claude Tagはプライベートチャンネルごとに固有のアイデンティティを作り、ワークスペース内のパブリックチャンネルはワークスペースレベルのアイデンティティを共有する。legalチャンネルのClaudeはそこに付与されていないコードに届かず、engineeringチャンネルのClaudeはそこに付与されていないlegalドキュメントを読めない。メモリとアクセスはこの境界を尊重し、プライベートチャンネルでClaudeが学習した内容が広いワークスペースに現れることはない。

アイデンティティはチャンネルに属するので、デフォルトではそこにいる誰もがClaudeにタグ付けできる。Enterpriseプランではrole-based access control（RBAC）でさらに踏み込み、どのメンバーがそもそもClaudeを呼び出せるかを管理者が決められる。チャンネルが「エージェントが何に届くか」と「誰が頼めるか」の両方を統治する形だ。

ツールとコンテキストへの広いデフォルトアクセス

AnthropicがClaude Tagを社内運用して分かったのは、その価値がツールとコンテキストへのアクセスとともに compound する（相乗的に膨らむ）ことだった。接続された各システムが他の全てをより有用にする。Slackのスレッド、Driveのドキュメント、トラッカーのチケット、ウェアハウスのクエリを1つの答えに束ねられるからだ。

推奨される始め方: いくつかのチャンネルでベースラインプロファイルから始め、監査証跡を読み、仕事が正当化する範囲で1つずつ意図的にアクセスを拡張していく。Claudeから最大の価値を引き出すチームは、最初から寛大にアクセスを与え、組織の管理者の好みに応じて絞り込んでいくチームだという。

ダイレクトメッセージ（DM）は別扱い

Claude TagではDMが共有チャンネルとは異なる動き方をする。DMはユーザー個人のclaude.aiアカウント――本人のコネクタ・認証情報・名前――で動作する。これにより、メール下書きや本人だけがライセンスを持つソフトウェアのように、チャンネルに置くべきでないツールやタスクに取り組む正しい場所がDMになる。

セキュリティと監査

管理者がチャンネルのプロファイルに接続を追加すると、認証情報は独立して保管され、そのチャンネルのアイデンティティにマッピングされ、リクエスト時にネットワーク境界で注入される。管理者が許可していないホストへの外向き通信は即座にブロックされる。監査面では、エージェントの認証情報で行われた全てのルーティン・メモリ書き込み・ネットワーク呼び出しが記録され、Claudeが自分のサービスアカウントで動くため、それらの操作は各接続システム自身のログにも残る。

注意すべき点と今後

運用上おさえておくこと

今後の計画として、Anthropicはjust-in-time credential grants（ユーザーがその場で単一の機微なアクションを承認でき、エージェントのスコープを恒久的に広げない仕組み）と、より複雑なクリアランス構造を持つ組織向けのidentity-aware overlayを挙げている。後者はエージェントのスコープの上にユーザー単位のチェックを重ね、チャンネルのプロファイルとリクエストしたユーザー自身の権限の両方が許す場合にのみClaudeが動くようにする。

まとめ

「act as the user」から「act as itself」へ。エージェントアイデンティティは、AIが長時間・チーム横断で自律的に働く前提に立つと必然的な転換だ。権限の単位がユーザーから「チャンネル（区画）」へ移ることで、誰が舵を取っても破綻しないアクセス制御が成立する。

Claudeが自分のサービスアカウントで動き、認証情報が境界で注入され、全操作が各システムのログに残る――この設計は、広く使えるだけの十分なスコープと、付与されていない場所へアクセスが漏れないだけの堅い境界を両立させる。シングルプレイヤーからマルチプレイヤーへのシフトは、エンタープライズ規模で安全な、長期的なチームベースの仕事を可能にする土台になっている。