AIエージェント時代の権限管理が、いまアツい
LayerX は、AI エージェントの普及に伴い、組織内での権限管理が設計上の最大の課題となっている現状と、過去・現在・未来の視点からの整理を提言している。
キーポイント
権限管理がエージェント運用の肝となる理由
AI エージェントに適切な権限を渡さないと安全な同僚になれず、逆に縛りすぎると柔軟性を失うため、設計上の核心課題となっている。
議論が分岐する要因：ユースケースと立場の違い
個人の生産性ツールか組織のリソース自動化かという文脈の違い、および業務設計者とリソース設計者という立場の違いにより、最適な権限モデルは人によって異なる。
時間軸による課題の整理アプローチ
従来の人間中心の権限管理から始まり、各社の動向や現場の論点を経て、未来の向かうべき方向性へと時系列で分析する枠組みを提示している。
従来の権限管理は人間中心設計
RBACやABACなど、これまでのアクセス制御システムは「行為者が人間」または「人間の意図を転送するプログラム」という前提で設計されてきた。
AIエージェント時代への前提の崩壊
AIエージェントが自律的に行動し始めることで、従来の「ボタンを押したのは人」という単純なモデルでは監査や管理が困難になる。
エージェントの自律化による権限管理の課題
人間から意図を転送するのではなく文脈からアクションを生成するようになったことで、監査ログ上の主体不明確さやブラックボックス化、責任所在の曖昧さが新たな課題として浮上している。
権限継承型とエージェント固有ID型の設計アプローチ
各社は大きく2つの方向性で対応しており、ユーザー権限を継承して実行するタイプ（Salesforce）と、エージェント自体に独立したアイデンティティと権限を持たせるタイプ（Google, Microsoft）が存在する。
影響分析・編集コメントを表示
影響分析
この記事は、AI エージェントの実装フェーズにおいて、単なる機能実装ではなく「誰に何をさせるか」というガバナンス設計がいかに重要かを浮き彫りにしています。業界全体が AI の能力拡大から、いかに安全かつ効率的に組織リソースを統合する段階へ移行していることを示唆しており、開発者やアーキテクトにとって権限管理の基準策定を急務とするメッセージとなります。
編集コメント
AI エージェントが実社会で本格的に稼働し始める中、技術的な能力以上に「信頼できる運用基盤」の構築が成否を分けるという視点を提供しています。特に権限管理の難解さを「過去・現在・未来」のフレームワークで整理した点は、現場の議論を深めるための有用なアプローチです。
こんにちは。LayerX で「Ai Workforce」というプロダクトのプロダクトマネージャーをしている ina です。
Ai Workforce は、組織の中で AI Agent を活用するためのプラットフォームです。
おかげさまで、我々の組織もお客様もユースケースも拡大を続けていて、AI Agent とその周辺機能を日々企画・開発しています。そのなかで、最近とくに議論が長引くテーマがあります。
権限管理です。
社内 Slack で権限の話を始めると、毎回スレッドが伸びます。私もさまざまな方と意見交換するたびに新しい視点が得られ、とても面白い領域だと感じています。（そういう意味で、社内的にいまアツい、です）
視点が増え、論点が分岐し、さらにスレッドが伸びる。なぜこんなに難しいのか。そして、なぜ「いま」これを考える意味があるのか。この記事では、権限管理を 過去（これまでの前提）／現在（各社の動向と現場の論点）／未来（向かう先） の時間軸で整理してみたいと思います。
最初にお断りしておくと、Ai Workforce は「さまざまな業務を支援・遂行するための AI Agent プラットフォーム」という位置づけです。そのため本稿も、特定の理想形に絞らず、「さまざま」を扱うための権限管理について、雑多に考えを広げています。その前提で読んでいただけると幸いです。
なぜ権限管理がエージェントの肝になるのか
個人の AI と組織の AI
組織の中に AI を配置し、安全かつ効率的に運用する。人と AI がコラボレーションする。そう考えたとき、設計の肝になるのは「どの権限を、誰に、どこまで、どうやって渡すか」です。
ここが決まらないと、エージェントは安心して仕事を任せられる同僚にはなれません。逆に縛りすぎれば、できることが少なく、柔軟性の低いものになってしまいます。
面白いのは、議論すると人によって意見が様々であることです。理由はおそらく 2 つあります。
- 想定しているユースケースは人によって違う。
個人の生産性ツールとして AI を使う文脈と、組織の共通リソースとして業務を自動化する文脈とでは、最適な権限のかたちはまるで変わります。
- 個人利用の Claude や ChatGPT に求められることと、組織の中の Agent に求められることも違ってきます。
- 権限への立ち位置が違う。
業務を設計する人と、業務で扱うリソースを設計する人とでは、「⚪︎⚪︎権限」に対するスタンスが異なります。
しかも、いまだ世の中に存在しないもので、人間にはとてもわかりづらい権限について想像しながら話しているため、人によって思い描く理想像もずれていきます。この課題を完全に解消できるかは怪しいですが、整理することで、議論の足場くらいは作れるはずです。
過去：主に人間を中心に設計されてきた権限管理
これまでのソフトウェアの権限管理は、システム間の連携のようなアクセス制御やルールもありますが、概ね一貫して「人間」を中心に設計されてきました。代表的なものを並べてみます。
- RBAC（ロールベースアクセス制御）：アクセスの主体は人間のユーザーであり、権限をロールやグループに束ねる。
- ABAC（属性ベースアクセス制御）：主体（ユーザー／システム）に加えて、対象リソースの属性とポリシーに基づいてアクセス可否を決める。
- ACL（アクセスコントロールリスト）：「誰が見られる／編集できる」をフォルダ・ファイル単位で管理する（Google Drive、SharePoint、Box など）。
- 認可（OAuth など）：アプリがユーザーの代わりに何かを実行する際、フローを通じて「ユーザーの許可」を得てアクセストークンを取得する。リソース側からは、ユーザー本人の行動かアプリの行動かをほぼ区別できない。
これらの世界には、共通する暗黙の前提がありました。
- 行為者は人間か、または人間の意図を忠実に転送するだけのプログラムである。
- ボタンを押したのは人であり、アプリはその意図を運んでいるに過ぎない。だから「誰がやったか」は実質的にユーザー本人と等しく、監査ログにユーザー情報が紐づけば十分である。
つまり、意図の出どころは常に人間という点です。
現在：エージェントは「自律的な行為者」になった
エージェントによって、何が変わったのでしょうか。
一言でいえば、意図を「転送」するのではなく、文脈から意図やアクションを「生成」するようになったことだと考えています。
人間が「この資料をまとめて」と頼むと、エージェントはどの情報を参照し、どう判断し、どんな成果物を作り、どのアクションを実行するかを、自分で決めていきます。たった一回のクリックの後ろで、数十の判断とアクションが連鎖する。ここで、従来の前提が静かに崩れ始めます。
- 課題1：主体をユーザーのままにすると、「誰がやったか」区別がつかない
リソース側（内部データや外部システム）は、「ユーザー本人が操作したのか」「エージェントが自律的に動いたのか」を見分けられません。監査ログ上は同じに見えるため、事故が起きたときに「誰が」やったのかを後から辿れなくなります。
- また、ユーザーの権限を継承してエージェントが情報にアクセスしてしまうと、情報セキュリティ上の観点で外部に送ってはいけない情報が、外部システムとしてのエージェントに渡されてしまったり、エージェントを通してさらに外に送信されてしまうおそれがあります。
- 課題2：エージェント固有の権限で動かすと、「できること」がブラックボックス化する
エージェントにサービスアカウントを与えてその権限で動かすと、ユーザーの権限とエージェントの権限が乖離します。それで良い場面もありますが、ユーザー本人には許されないことを、エージェント経由で実行できてしまう、ということも起こりえます。
- エージェントからアクセスできる範囲やできることがユーザーから見て分かりづらくなってしまったり、ガバナンスが適切に効かせられているかどうか分かりづらくなってしまうかもしれません。
- 課題3：人への依頼と、エージェントへの依頼は「責任の所在」が違う
「A さんが B さんに作業を依頼する」のと、「A さんがエージェント A′に依頼する」のは違います。B さんには本人の判断と責任がありますが、エージェント A′が何をどこまでできるのかを、A さんが正確に把握しているとは限りません。把握できていないことが、トラブルや業務の停滞につながりかねません。
各社のプロダクトはどう設計しているか
エンタープライズ向けに AI エージェントを提供する各社も、同じ課題に向き合っているはずです。公開情報をもとにざっくり調べたところ（※すぐ触れる環境がなかったため厳密さは欠きます）、大きく 2 つに分かれそうでした。
- 実行ユーザーの権限を継承するタイプ
例：Salesforce の Agentforce の Employee Agent。
エージェント自体に独立した権限モデルを持たず、実行ユーザーの権限をベースに動く。基本的にはユーザーに許可を求める仕組み。
- エージェントを第一級のアイデンティティとして扱うタイプ
例：Google Cloud の「Agent Identity」、Microsoft の「Entra Agent ID」「Agent 365」。
エージェントそのものに身元と権限を持たせる。
どちらが良いではなく、それぞれの体験、汎用性を踏まえて設計されているように見えます。
また、各社のプロダクト以外にも、OAuth や MCP（Model Context Protocol）を中心に標準化の動向や議論もあるようです。（ここは話が広がりすぎるので、また別の機会に）
いま現場で起きている論点
世の中の動きと同じことが、社内でも論点として立ち上がってきます。
（以下はあくまで社内で出ている論点の一例で、権限管理の一般的な論点を網羅したものではないのでご注意ください）
1. 代行か、依頼か
1 つ目は、エージェントが「誰の権限で」「どこまで自分で判断して」動くかという軸です。業務の任せ方には 2 種類あります。
- 業務の代行：自分の仕事をそのまま肩代わりしてもらう。エージェントは裁量を持たず、ユーザーの権限の範囲で動く。例：「自分の提案書を仕上げてほしい」
- 業務の依頼：任された側にも裁量がある。エージェント自身の権限と判断で動く。例：「組織内の情報整理を定期的に行ってほしい」
例えば、「エージェントは自分の権限で動いてくれた方がアクセス範囲やできることが明確」である、という意見もありますし、一方で「誰が実行しても同じ結果が得られるようにエージェントごとに権限が管理が理想」という意見もあります。
ユースケースによってどちらも妥当そうに見えます。どちらをやるにしても一つのプロダクトの中でどう表現し、どう実現できるのか、はまだぼんやりしています。
なお、代行だからといって「ユーザーの全権限をそのままエージェントに渡してよい」わけではありません。本人なら許される操作でも、エージェント経由だと意図しない結果になることがあります（機密情報や受領資料を外部に送信してしまったら、目も当てられません）。代行であっても「どの権限を、どの操作に限って貸すか」の絞り込みは必要です。
2. そのエージェントは「誰のもの」か
2 つ目は、論点 1 とは別の軸で、そのエージェントが「誰に紐づくアイデンティティなのか」という話です。
- 個人に紐づくエージェント：自分の業務のために使うエージェント。誰に許可を取ればよいかが明確で、説明責任もその人に集約されるため、シンプルで安心しやすい。一方で、異動や退職のたびに引き継ぎが発生します。
- 組織に紐づくエージェント（脱属人化）：チーム全体に向けて働く、共通リソースとしてのエージェント。特定個人がいなくなっても残せますが、「誰が責任を持ち、誰が許可を出すのか」を明確にする必要がある。
1 つ目の代行・依頼と、この 2 つ目の誰のものか、は 2 軸として独立しているかもしれないと考えています。「代行か依頼か（権限の出どころ）」と「個人か組織か（アイデンティティの所在）」は、同じ話に見えますが、たとえば組織に属するエージェントが、実行時には指示者の権限を借りて代行*する*といった組み合わせも成り立ちます。混同せず別々の話として設計したほうが、選べる形が広がりそうです。
3. リソースをどう安全に分けて扱うか
3 つ目は、エージェントが触れるリソースの範囲をどう引くかです。
- エージェントを特定のプロジェクト資料やアクションに限定すると、安全性は高まりますが、その範囲でしか動けず、汎用性や、応用力は下がります。
- 一方で、プロジェクトを横断・俯瞰したい場面も当然あります。
- 目的によってエージェントが触れる範囲を限定したくなります。
リソース範囲ごとにエージェントをそれぞれ用意する形になるかもしれませんし、用途に応じたスコープ（scope: 対象範囲）を柔軟に構成できると良いのかもしれません。また、用途に応じたエージェントを実行できる主体も異なる形にする必要があるかもしれません。
これらはどれも「最終的には全部必要」という話に着地するかもしれません。
さまざまなユースケースをカバーしたい我々のようなプロダクトでは、汎用性とカスタマイズ性を両立しながら、作り手もユーザーも安心・安全に使いこなせる権限モデルを確立する必要があると考えています。
未来？：権限管理はどこへ向かうのか
足元の課題を解くのはもちろんですが、もう少し先を妄想してみたいと思います。
権限は「リソースの列挙」から「意図・条件の記述」へ
「どのファイル」「どのフォルダ」と一つずつ指定するのではなく、「機密区分が高くないもの」「この案件に関するもの」のように、条件や意味で権限を切り分ける方向に進むかもしれません。エージェントは大量かつ多様なリソースを必要とするため、人間が一つずつ ACL（Access Control List: アクセス制御リスト）を設定する運用はいずれ破綻してしまいそうです。クエリのようなスコープや、属性ベースのポリシー（attribute-based policy）が中心になっていくのではないでしょうか。
権限は連鎖し、その連鎖は検証可能になる
人→エージェント→別のエージェント→外部 API、というように多段の依頼や権限委譲が当たり前になりつつあります。各ホップでトークンが渡され、最終的に「誰の意図で、どのエージェントが、何をしたか」を正確に辿れる状態が求められます。複雑な流れであってもアカウンタビリティ（accountability: 説明責任・追跡可能性）が保てること自体が、権限設計の要件になっていくはずです。
エージェントは「管理されるアイデンティティ」になる
人が会社に入社・退社する際、アカウント発行、PC セットアップ、アカウント削除、PC リセットといった手続きがあります。同じように、エージェントにも作成・更新・廃棄のライフサイクルが必要になりそうです。「いま組織にどんなエージェントがいて、何ができ、最後にいつ何をしたか」を把握できる状態が、ガバナンス（governance: 統制・管理）の前提になっていくでしょう。
組織の中で働くエージェントが本当の意味で安心・安全になるには、さまざまな工夫が必要であると思います。
さいごに
ここまで、権限管理を「過去／現在／未来」の時間軸で整理してきました。
いまこの論点を考える意味は、エージェントが便利な新機能ではなく、組織の中で意思決定とアクションを連続的に生み出す「新しい行為者」になりつつあるからだと思っています。だからこそ、単に強い／弱い権限を付けるのではなく、次の 3 つをプロダクトと運用の両面で設計していく必要があります。
- 誰のために動いたのか
- どの範囲まで委ねたのか
- 何をしたのかを、後から説明できるのか
完璧な解はまだ見えていません。それでも、Ai Workforce なりの、「さまざま」な業務に耐える権限モデルを探っていきたいと思います。
さいごのさいごに
Ai Workforce では、プロダクトマネージャーやエンジニアを募集しています。
ご興味のある方は、ぜひカジュアル面談からお気軽にご応募ください！
原文を表示
こんにちは。LayerXで「Ai Workforce」というプロダクトのプロダクトマネージャーをしているinaoです。
Ai Workforceは、組織の中でAI Agentを活用するためのプラットフォームです。
おかげさまで、我々の組織もお客様もユースケースも拡大を続けていて、AI Agentとその周辺機能を日々企画・開発しています。そのなかで、最近とくに議論が長引くテーマがあります。
権限管理です。
社内Slackで権限の話を始めると、毎回スレッドが伸びます。私もさまざまな方と意見交換するたびに新しい視点が得られ、とても面白い領域だと感じています。（そういう意味で、社内的にいまアツい、です）
視点が増え、論点が分岐し、さらにスレッドが伸びる。なぜこんなに難しいのか。そして、なぜ「いま」これを考える意味があるのか。この記事では、権限管理を 過去（これまでの前提）／現在（各社の動向と現場の論点）／未来（向かう先） の時間軸で整理してみたいと思います。
最初にお断りしておくと、Ai Workforceは「さまざまな業務を支援・遂行するためのAI Agentプラットフォーム」という位置づけです。そのため本稿も、特定の理想形に絞らず、「さまざま」を扱うための権限管理について、雑多に考えを広げています。その前提で読んでいただけると幸いです。
なぜ権限管理がエージェントの肝になるのか
組織の中にAIを配置し、安全かつ効率的に運用する。人とAIがコラボレーションする。そう考えたとき、設計の肝になるのは「どの権限を、誰に、どこまで、どうやって渡すか」です。
ここが決まらないと、エージェントは安心して仕事を任せられる同僚にはなれません。逆に縛りすぎれば、できることが少なく、柔軟性の低いものになってしまいます。
面白いのは、議論すると人によって意見が様々であることです。理由はおそらく2つあります。
- 想定しているユースケースは人によって違う。
個人の生産性ツールとしてAIを使う文脈と、組織の共通リソースとして業務を自動化する文脈とでは、最適な権限のかたちはまるで変わります。
- 個人利用のClaudeやChatGPTに求められることと、組織の中のAgentに求められることも違ってきます。
- 権限への立ち位置が違う。
業務を設計する人と、業務で扱うリソースを設計する人とでは、「⚪︎⚪︎権限」に対するスタンスが異なります。
しかも、いまだ世の中に存在しないもので、人間にはとてもわかりづらい権限について想像しながら話しているため、人によって思い描く理想像もずれていきます。この課題を完全に解消できるかは怪しいですが、整理することで、議論の足場くらいは作れるはずです。
過去：主に人間を中心に設計されてきた権限管理
これまでのソフトウェアの権限管理は、システム間の連携のようなアクセス制御やルールもありますが、概ね一貫して「人間」を中心に設計されてきました。代表的なものを並べてみます。
- RBAC（Role-Based Access Control）：アクセスの主体は人間のユーザーで、権限をロールやグループに束ねる。
- ABAC（Attribute-Based Access Control）：主体（ユーザー／システム）に加えて、対象リソースの属性とポリシーでアクセス可否を決める。
- ACL（アクセスコントロールリスト）：「誰が見られる／編集できる」をフォルダ・ファイル単位で管理する（Google Drive、SharePoint、Boxなど）。
- 認可（OAuthなど）：アプリがユーザーの代わりに何かするとき、フローを通じて「ユーザーの許可」をもらいアクセストークンを取得する。リソース側からは、ユーザー本人の行動かアプリの行動かをほぼ区別できない。
これらの世界には、共通する暗黙の前提がありました。
- 行為者は人間か、または人間の意図を忠実に転送するだけのプログラムである。
- ボタンを押したのは人であり、アプリはその意図を運んでいるに過ぎない。だから「誰がやったか」は実質的にユーザー本人と等しく、監査ログにユーザー情報が紐づけば十分。
つまり、意図の出どころは常に人間という点です。
現在：エージェントは「自律的な行為者」になった
エージェントによって、何が変わったのでしょうか。
一言でいえば、意図を「転送」するのではなく、文脈から意図やアクションを「生成」するようになったことだと考えています。
人間が「この資料をまとめて」と頼むと、エージェントはどの情報を参照し、どう判断し、どんな成果物を作り、どのアクションを実行するかを、自分で決めていきます。たった一回のクリックの後ろで、数十の判断とアクションが連鎖する。ここで、従来の前提が静かに崩れ始めます。
- 課題1：主体をユーザーのままにすると、「誰がやったか」区別がつかない
リソース側（内部データや外部システム）は、「ユーザー本人が操作したのか」「エージェントが自律的に動いたのか」を見分けられません。監査ログ上は同じに見えるため、事故が起きたときに「誰が」やったのかを後から辿れなくなります。
- また、ユーザーの権限を継承してエージェントが情報にアクセスしてしまうと、情報セキュリティ上に外部に送ってはいけない情報が外部システムとしてのエージェントに渡されてしまったり、エージェントを通してさらに外に送信されてしまうおそれがあります。
- 課題2：エージェント固有の権限で動かすと、「できること」がブラックボックス化する
エージェントにサービスアカウントを与えてその権限で動かすと、ユーザーの権限とエージェントの権限が乖離します。それで良い場面もありますが、ユーザー本人には許されないことを、エージェント経由で実行できてしまう、ということも起こりえます。
- エージェントからアクセスできる範囲やできることがユーザーから見て分かりづらくなってしまったり、ガバナンスが適切に効かせられているかどうか分かりづらくなってしまうかもしれません。
- 課題3：人への依頼と、エージェントへの依頼は「責任の所在」が違う
「AさんがBさんに作業を依頼する」のと、「AさんがエージェントA′に依頼する」のは違います。Bさんには本人の判断と責任がありますが、エージェントA′が何をどこまでできるのかを、Aさんが正確に把握しているとは限りません。把握できていないことが、トラブルや業務の停滞につながりかねません。
各社のプロダクトはどう設計しているか
エンタープライズ向けにAIエージェントを提供する各社も、同じ課題に向き合っているはずです。公開情報をもとにざっくり調べたところ（※すぐ触れる環境がなかったため厳密さは欠きます）、大きく2つに分かれそうでした。
- 実行ユーザーの権限を継承するタイプ
例：SalesforceのAgentforceのEmployee Agent。
エージェント自体に独立した権限モデルを持たず、実行ユーザーの権限をベースに動く。基本的にはユーザーに許可を求める仕組み。
- エージェントを第一級のアイデンティティとして扱うタイプ
例：Google Cloudの「Agent Identity」、Microsoftの「Entra Agent ID」「Agent 365」。
エージェントそのものに身元と権限を持たせる。
どちらが良いではなく、それぞれの体験、汎用性を踏まえて設計されているように見えます。
また、各社のプロダクト以外にも、OAuthやMCPを中心に標準化の動向や議論もあるようです。（ここは話が広がりすぎるので、また別の機会に）
いま現場で起きている論点
世の中の動きと同じことが、社内でも論点として立ち上がってきます。
（以下はあくまで社内で出ている論点の一例で、権限管理の一般的な論点を網羅したものではないのでご注意ください）
1. 代行か、依頼か
1つ目は、エージェントが「誰の権限で」「どこまで自分で判断して」動くかという軸です。業務の任せ方には2種類あります。
- 業務の代行：自分の仕事をそのまま肩代わりしてもらう。エージェントは裁量を持たず、ユーザーの権限の範囲で動く。例：「自分の提案書を仕上げてほしい」
- 業務の依頼：任された側にも裁量がある。エージェント自身の権限と判断で動く。例：「組織内の情報整理を定期的に行ってほしい」
例えば、「エージェントは自分の権限で動いてくれた方がアクセス範囲やできることが明確」である、という意見もありますし、一方で「誰が実行しても同じ結果が得られるようにエージェントごとに権限が管理が理想」という意見もあります。
ユースケースによってどちらも妥当そうに見えます。どちらをやるにしても一つのプロダクトの中でどう表現し、どう実現できるのか、はまだぼんやりしています。
なお、代行だからといって「ユーザーの全権限をそのままエージェントに渡してよい」わけではありません。本人なら許される操作でも、エージェント経由だと意図しない結果になることがあります（機密情報や受領資料を外部に送信してしまったら、目も当てられません）。代行であっても「どの権限を、どの操作に限って貸すか」の絞り込みは必要です。
2. そのエージェントは「誰のもの」か
2つ目は、論点1とは別の軸で、そのエージェントが「誰に紐づくアイデンティティなのか」という話です。
- 個人に紐づくエージェント：自分の業務のために使うエージェント。誰に許可を取ればよいかが明確で、説明責任もその人に集約されるため、シンプルで安心しやすい。一方で、異動や退職のたびに引き継ぎが発生します。
- 組織に紐づくエージェント（脱属人化）：チーム全体に向けて働く、共通リソースとしてのエージェント。特定個人がいなくなっても残せますが、「誰が責任を持ち、誰が許可を出すのか」を明確にする必要がある。
1つ目の代行・依頼と、この2つ目の誰のものか、は2軸として独立しているかもしれないと考えています。「代行か依頼か（権限の出どころ）」と「個人か組織か（アイデンティティの所在）」は、同じ話に見えますが、たとえば組織に属するエージェントが、実行時には指示者の権限を借りて代行*する*といった組み合わせも成り立ちます。混同せず別々の話として設計したほうが、選べる形が広がりそうです。
3. リソースをどう安全に分けて扱うか
3つ目は、エージェントが触れるリソースの範囲をどう引くかです。
- エージェントを特定のプロジェクト資料やアクションに限定すると、安全性は高まりますが、その範囲でしか動けず、汎用性や、応用力は下がります。
- 一方で、プロジェクトを横断・俯瞰したい場面も当然あります。
- 目的によってエージェントが触れる範囲を限定したくなります。
リソース範囲ごとにエージェントをそれぞれ用意する形になるかもしれませんし、用途に応じたスコープを柔軟に構成できると良いのかもしれません。また、用途に応じたエージェントを実行できる主体も異なる形にする必要があるかもしれません。
これらはどれも「最終的には全部必要」という話に着地するかもしれません。
さまざまなユースケースをカバーしたい我々のようなプロダクトでは、汎用性とカスタマイズ性を両立しながら、作り手もユーザーも安心・安全に使いこなせる権限モデルを確立する必要があると考えています。
未来？：権限管理はどこへ向かうのか
足元の課題を解くのはもちろんですが、もう少し先を妄想してみたいと思います。
権限は「リソースの列挙」から「意図・条件の記述」へ
「どのファイル」「どのフォルダ」と一つずつ指定するのではなく、「機密区分が高くないもの」「この案件に関するもの」のように、条件や意味で権限を切り分ける 方向に進むかもしれません。エージェントは大量かつ多様なリソースを必要とするため、人間が一つずつACLを設定する運用はいずれ破綻してしまいそうです。クエリのようなスコープや、属性ベースのポリシーが中心になっていくのではないでしょうか。
権限は連鎖し、その連鎖は検証可能になる
人→エージェント→別のエージェント→外部API、というように多段の依頼や権限委譲が当たり前になりつつあります。各ホップでトークンが渡され、最終的に「誰の意図で、どのエージェントが、何をしたか」を正確に辿れる状態が求められます。複雑な流れであってもアカウンタビリティが保てること自体が、権限設計の要件になっていくはずです。
エージェントは「管理されるアイデンティティ」になる
人が会社に入社・退社する際、アカウント発行、PCセットアップ、アカウント削除、PCリセットといった手続きがあります。同じように、エージェントにも作成・更新・廃棄のライフサイクルが必要になりそうです。「いま組織にどんなエージェントがいて、何ができ、最後にいつ何をしたか」を把握できる状態が、ガバナンスの前提になっていくでしょう。
組織の中で働くエージェントが本当の意味で安心・安全になるには、さまざまな工夫が必要であると思います。
さいごに
ここまで、権限管理を「過去／現在／未来」の時間軸で整理してきました。
いまこの論点を考える意味は、エージェントが便利な新機能ではなく、組織の中で意思決定とアクションを連続的に生み出す「新しい行為者」になりつつあるからだと思っています。だからこそ、単に強い／弱い権限を付けるのではなく、次の3つをプロダクトと運用の両面で設計していく必要があります。
- 誰のために動いたのか
- どの範囲まで委ねたのか
- 何をしたのかを、後から説明できるのか
完璧な解はまだ見えていません。それでも、Ai Workforceなりの、「さまざま」な業務に耐える権限モデルを探っていきたいと思います。
さいごのさいごに
Ai Workforceでは、プロダクトマネージャーやエンジニアを募集しています。
ご興味のある方は、ぜひカジュアル面談からお気軽にご応募ください！
関連記事
Jedify が企業向け AI エージェントにビジネス文脈を提供するサービスへ 2400 万ドルを調達
スタートアップの Jedify は、企業が AI エージェントに自社の業務文脈を付与できるプラットフォームの開発を進めるため、2400 万ドルの資金調達を実施した。
計画と覚書を伴う三つの実験室
Anthropic は安全に配布可能な Claude の新バージョン「Claude Fable 5」をリリースした。しかし、本ブログは新モデルの機能を十分に検証するまで数日間の猶予を設け、詳細なレビューは金曜または月曜から開始すると明言している。
Apple の AI 約束がいよいよ、ほぼ、あるいは少しだけ実現した
Apple は開発者会議で AI に関する大胆な約束を表明したが、CEO ティム・クックが述べた新技術の導入よりも、むしろ「Siri AI」を中心とした発表は他社に追いつくためのものだった。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み