← 概念解説に戻る

Concept Fable

ロールベースのアクセス制御

先に結論:Role-Based Access Control (RBAC) は、個々のユーザーやエージェントではなく役割に権限を割り当てる。Agent システムでは、RBAC はエージェント、ツール、オペレーターをサポート、財務、管理、監査、開発者といった職務機能に結び付けるのに役立つ。オンボーディング、オフボーディング、レビュー、最小権限設計を簡素化するが、細かいケースでは ABAC やポリシーエンジンが必要になることがある。

Role-Based Access Control, RBAC · Security

まず物語を読む。ここでは急いで定義を示さず、まず問題そのものを立ち上がらせる。

寓話

職位ごとに鍵を配る帳楼

座長は鍵を役割ごとに帳方、衣装師、武師に渡し、各自が自分の担当する箱だけに触れるようにした;隊はまだ小さく、この分業は明確だった。

新人が次々と加わり、一時的に鍵を借りる依頼が座長の机に押し寄せ、忙しくなると誰かが権限を間違えて取る。認可は記憶の伝達に頼り始めた。

座長は信頼する者にマスターキーを一本渡し、バックステージでは問い合わせが何度か減ったが、職責の境界まで一緒に消し去り、隠れた権限逸脱がかえって積み重なった。

老匠人は職位と箱籠の関係を描き、申請・承認・使用・回収を逐一記録し、各職責がいつどの権限を得るのかを確認した。

その後、彼は役割ごとに鍵を配るようにしました。会計は銀箱を管理し、衣装師は衣装を管理し、武師は道具を取り、臨時の代役はその日必要な分だけを受け取ります。このステップは面倒で、当初は工期を遅らせもしました。しかし数ラウンド後、手戻りが減り、師匠も気まぐれで規則を変えなくなりました。皆はついに理解しました。したがって、権限は役割と一時的な職務の変化に応じて付与、監査、適時回収されるべきです。

役割札は職務の変化に応じて変わり、権限のレビューと回収にも明確な根拠ができた。

人が変わっても、その役割札を替えるだけで、鍵は自然にそれに従う。それ以来、多くの権限はまず職責ごとにグループ化され、管理は各人の一時的な要求に振り回されなくなった。

概念の落としどころ

この物語が語るのは:ロールベースのアクセス制御

Role-Based Access Control (RBAC) は、個々のユーザーやエージェントではなく役割に権限を割り当てる。Agent システムでは、RBAC はエージェント、ツール、オペレーターをサポート、財務、管理、監査、開発者といった職務機能に結び付けるのに役立つ。オンボーディング、オフボーディング、レビュー、最小権限設計を簡素化するが、細かいケースでは ABAC やポリシーエンジンが必要になることがある。

重要なのは、それが単なる用語ではなく、実際のAI/Agentシステムで繰り返し現れる構造的な問題だという点だ。これを理解して初めて、いつモデルを足すべきか、いつプロセスを変えるべきか、いつガバナンスを補うべきかを判断できる。

物語の対応

  • 帳楼:企業バックエンドと Agent コンソール
  • 職務バスケット:役割集合
  • 客服木偶が底値表を誤って開く:Agent が過度に広い人またはツール権限を継承
  • 期限付きロール:一時権限と自動回収
  • 監査は読み取り専用:役割は読み書きと管理操作を区別できる
  • 最終洞察:RBAC は権限を個人の例外から職務設計へ変え、企業 Agent の権限ガバナンスの基礎層となる

Andy(任旭)判断

この概念の実戦的価値は、「賢く見えるAI機能」を納品可能、検収可能、ガバナンス可能な作業単位に分解する手助けをすることです。

IAMABACpermissions

関連する識別

この概念は隣接概念と混用されやすいので、対比ページを続けて見ることをおすすめする。

京ICP备2026014272号