共有AIエージェントのメンバーとグループの権限を割り当てる方法
人、アプリ接続、データ、アクションを軸にLeinaのチーム権限を計画します。アクセス権限マトリクスの例を使い、出力の宛先を確認し、責任の変更時にアクセスを見直しましょう。

概念図:組織がエージェントを共有しつつ、参加者はそれぞれ異なるアクセス境界を保つ。
個人向けのAIエージェントは、通常は1人のアカウントとドキュメントを扱います。組織では、異なる責任を持つ同僚がチャットグループを共有し、別のグループには顧客やパートナーが含まれることがあります。
問題は、エージェントがどのアプリに接続できるかにとどまりません。各接続を誰が使用できるか、どのデータにアクセスできるか、どのアクションが許可されるか、そして誰が結果を受け取れるかです。
Leinaは、メンバーとグループに割り当てられた権限によって組織利用を支援し、OpenConnector認可ゲートウェイを通じて業務アプリにアクセスします。利用を拡大する前に、責任を検証可能なアクセススコープに変換しましょう。
権限を4つの具体的な問いに変える
次の次元から始めます。
| 次元 | 確立する内容 | 例 |
|---|---|---|
| 参加者 | アクセスを必要とするメンバーまたはグループ | プロジェクトAのワークグループ |
| ソース | 接続と業務レコード | 認可されたプロジェクトAのドキュメント |
| 操作 | 読み取り、作成、更新、削除 | このタスクのための検索と読み取り |
| 宛先 | 出力を送ってよい場所 | プロジェクトAの内部グループ |
これは計画用のチェックリストであり、コンソールのフィールド名の説明ではありません。利用可能な粒度は、コネクタ、業務アカウント、チーム設定によって異なります。現在のサポート状況を確認してください。
接続が意図した狭いスコープを適用できない場合は、アカウントを再検討するか、タスクのスコープを縮小してください。他の資料を無視するよう指示しても、アクセス制御の代わりにはなりません。
アクセス権限マトリクスの例を作成する
営業メンバー、プロジェクトメンバー、外部参加者を含むグループがあるチームを想像してください。このマトリクスはアクセス計画の例であり、これらはLeinaの定義済みロールではありません。
| ワークフロー | 提供するアクセス | 初期段階で除外するスコープ |
|---|---|---|
| 営業メンバーがフォローアップを要約する | 関連する顧客レコードと必要なクエリ | 無関係なプロジェクトおよび部門のレコード |
| プロジェクトグループが会議のアクションを要約する | プロジェクトのドキュメント、検索、読み取りアクセス | 他のプロジェクトと未確認の書き込み |
| 外部コラボレーショングループが進捗を確認する | その宛先向けに承認されたプロジェクト資料 | 内部の議論と未公開の顧客情報 |
各ワークフローの実際の要件に基づいて進めてください。ドキュメントを要約するグループは、読み取りアクセスを確認することから始められます。後で業務レコードを変更する必要が生じた場合は、関連する操作と宛先を別途確認してください。
得られたアクセスを、想定されるメンバーとグループとしてテストしてください。管理者が実行して成功したタスクは、通常のメンバーが正しいアクセススコープを持っていることを証明するものではありません。
責任からアクセススコープへ
flowchart TB
accTitle: 責任からアクセススコープへ
accDescr: メンバーとグループのタスク要件および既存の業務アカウント権限が、設定されるスコープに反映される。OpenConnectorが業務アプリの呼び出しを認可する。
T("メンバーとグループ
タスクのニーズ"):::channel
A("業務アカウント
既存のアクセス"):::channel
T --> P("構成する
適切なスコープ"):::agent
A --> P
P --> G("OpenConnector
認可を呼び出す"):::gateway
G --> R("許可済み
データとアクション"):::resourceソースと出力の宛先を別々に確認する
メンバーが内部ドキュメントを読み取る権限を持っていても、その要約が外部参加者を含むグループに適しているとは限りません。
たとえば、顧客フォローアップの要約には、内部メモ、連絡先情報、顧客への約束が含まれることがあります。タスクの前に許可されるソースを指定し、その後で出力フィールドと宛先グループを確認してください。
より precise な依頼は次のようになります。
外部共有が承認されたプロジェクト進捗レコードのみを使用してください。今週完了した作業と次のステップの要約を作成してください。オーナーがパートナーグループに送るかどうかを判断する前に確認できるよう、ソースリンク付きの下書きを返してください。
指示は期待を設定しますが、実際のアクセス制限は依然として接続と権限の設定に属します。Leinaは、グループチャットとダイレクトチャットが別々の作業コンテキストを持つと説明しています。その会話の境界は、誰が業務接続を使用し、その結果を受け取れるかを定義するものではなく、長期的なメモリ分離の保証として読むべきではありません。接続アクセスと出力の宛先を別々に確認してください。アカウントとアクションの確認については、権限とデータアクセスを参照してください。
アクセスが計画と一致することを検証する
実際のワークロードを追加する前に、機密情報を含まないテストレコードを使用してください。
- 許可されたアクセスをテストする。 想定されるメンバーに、想定されるグループで明確に認可されたテストレコードを読ませます。ソースと結果を確認します。
- スコープ外のアクセスをテストする。 そのメンバーまたはグループに認可されていないテストレコードを使用し、アクセスが意図した境界を超えないことを確認します。
- 操作タイプを確認する。 読み取り専用ワークフローで利用可能なアクションを確認し、書き込み、送信、削除が含まれていないことを確かめます。
- 宛先を確認する。 特に外部参加者が関与する場合、出力が意図した会話または業務上の場所にのみ送られることを確認します。
観察された結果が計画と異なる場合は、拡大する前に接続、アカウント、または権限を調整してください。メンバー、グループ、接続、期待される動作、結果を記録して、後の見直しを容易にします。
これらは推奨される組織的な確認であり、製品が自動権限テストや監査レポートを提供するという主張ではありません。
人とグループが変わったときにアクセスを見直す
アクセスは仕事上の関係の変化に従うべきです。メンバーが役割を変更したりプロジェクトを離れたり、外部参加者がグループに加わったり、業務アカウントの権限が変更されたりします。これらのいずれも、既存のワークフローの前提を変える可能性があります。
メンバーまたはグループを追加するとき、責任が変わるとき、および書き込みなどの操作を導入する前に、アクセスを見直してください。古い接続がまだ必要か、資料が現在の宛先に依然として適切か、不要になったアクセスがないかを確認します。
メンバーとグループの設定は、基盤となるアプリアカウントの権限と併せて見直してください。どちらかの層を変更した後は、設定の保存が成功しただけに頼らず、完全なタスクを再度検証してください。
1つのグループと1つのタスクから始める
組織利用は、1つのグループと読み取り専用タスクから始めてください。その参加者、データ、操作、宛先を特定します。対応するスコープを設定し、テストレコードで検証してから、メンバー、グループ、タスクタイプを徐々に追加します。
アプリの設定については、OpenConnectorと安全な業務アプリ接続をお読みください。追加のチャット入口については、複数のチャットプラットフォームで1つのエージェントをお読みください。Leinaの概要では、これらの機能がどのように連携するかを説明しています。