Copilot Studioとは｜権限を引き継がないと、営業に給与テーブルが見えた

権限を引き継がないと、営業に給与テーブルが見えた

文書10件と利用者4人で数えました。権限を引き継がない構成では、延べ22件が見てはいけない相手に見えます。

Copilot Studioのように社内データにつなぐ基盤で、利用者ごとの権限を引き継ぐかどうかがどれだけ効くのかを数えました。用意したのは閲覧範囲の違う文書10件です。

判定は実際に実行しています。文書ごとの閲覧範囲と利用者の所属はコードに書いてあり、そこを変えれば結果も変わります。

const DOCS = [
  { name: '就業規則',           visibleTo: ['営業', '経理', '人事', '技術'] },
  { name: '来期の組織案',       visibleTo: ['人事'] },
  { name: '個人の評価シート',   visibleTo: ['人事'] },
  { name: '給与テーブル',       visibleTo: ['人事', '経理'] },
  { name: '取引先ごとの原価',   visibleTo: ['経理'] },
  { name: '未発表の新製品仕様', visibleTo: ['技術'] },
  /* ... 全10件 ... */
];

// 権限を引き継ぐ: その利用者が見てよい文書だけを対象にする
const withPermission = (u) => DOCS.filter((d) => d.visibleTo.includes(u.dept));
// 引き継がない: 取り込んだ文書を全部対象にする
const withoutPermission = () => DOCS;

利用者        本来見てよい  権限を引き継ぐ  引き継がない  見えてはいけない件数
営業のAさん             4件             4件          10件                   6件
経理のBさん             5件             5件          10件                   5件
人事のCさん             5件             5件          10件                   5件
技術のDさん             4件             4件          10件                   6件

見えてはいけない文書の延べ件数: 22件（4人合計）

営業のAさんに見えてしまう文書（6件）
  来期の組織案（閲覧できるのは 人事）
  個人の評価シート（閲覧できるのは 人事）
  給与テーブル（閲覧できるのは 人事・経理）
  取引先ごとの原価（閲覧できるのは 経理）
  未発表の新製品仕様（閲覧できるのは 技術）
  障害の詳細レポート（閲覧できるのは 技術）

内訳が具体的です。営業の利用者に給与テーブルも個人の評価シートも未発表の新製品仕様も見えています。

漏れたことが表に出ない

この種の問題は静かに進みます。エラーは出ません。聞かれれば答えるだけです。

ですから気づくのは、誰かが知らないはずの内容を口にしたときになります。それまでの期間、何件どう答えていたかは記録がなければ追えません。

部署が増えると広がる

1人あたり平均5.5件です。この数字は部署が増えても変わりませんが、延べ件数は人数に比例して増えます。100部署なら550件です。

しかも文書を追加するたび、その文書が全員に対して見える状態で足されます。取り込む文書が増えるほど、確かめる範囲も広がります。

確かめ方は単純

権限が効いているかどうかは、簡単に確かめられます。部署の違う利用者を2人立てて、同じ質問をして答えを比べるだけです。

答えが同じなら、権限は効いていません。この確認は導入前に1度やっておけば済みます。

Copilot Studioとは何ができる基盤なのか

画面上でエージェントを組み立て、社内のデータにつないで、利用者が使っている場所に公開できる基盤です。

Copilot Studioは、画面上でAIのエージェントや処理の流れを組み立てて管理する基盤です。コードを多く書かずに使える形になっています。

組んで、つないで、出す

できることは3つに整理されています。エージェントと処理の流れを組み立て、組織のデータや仕組みにつなぎ、利用者がすでに使っている場所に公開するという流れです。

3番目が特徴です。新しい画面を用意しなくても、普段使っている場所から呼べる形にできます。

どう動くか

動きについても説明があります。与えた指示に従い、つないだ知識の源から情報を引き、道具を使って行動する。依頼を読み解いて次の一手を決める、という形です。

つまり指示と、つないだ範囲と、渡した道具の3つが動作を決めます。前の節の問題は、このうち「つないだ範囲」の話にあたります。

人の確認を挟める

処理の流れには、人が確認する段を含められるとされています。指示を実行したり、エージェントを呼んだりする段と並べて置けます。

承認の設計はHITLの記事で扱っています。件数が多いと読まずに押すようになる点も、そちらで数字とともに触れています。

社内に広げる前に確かめること

権限が効いているかを、部署の違う2人で確かめます。組みやすさが、確かめる工程を飛ばす理由になりがちです。

Copilot Studioは組みやすい基盤です。ただし組みやすさは、確かめる工程を飛ばす理由にもなります。

誰でも組めることの裏側

説明でも、深い技術の背景がなくても実用的なものを作れる点が利点として挙げられています。これは事実で、実際に早く形になります。

ところが、つなぐ範囲を決めるのは技術の話ではありません。誰がどの文書を見てよいかという、組織の話です。ここは早く終わりません。

広げる前の手順

1. つなぐ文書を並べて、閲覧範囲を書き出す。ここがいちばん時間がかかる
2. 部署の違う2人で同じ質問をする。答えが同じなら権限が効いていない
3. 何を答えたかを記録する。後から範囲を確かめられる
4. とりあえず全社に公開する。戻せない

4番目を避けてください。公開してから範囲を絞っても、それまでに答えた内容は取り消せません。

記録がないと範囲も分からない

問題が見つかったとき、まず知りたいのは影響範囲です。誰が何を聞いて、何が返ったか。これが残っていなければ、影響を確定できません。

記録の設計はエージェント可観測性の記事で扱っています。社内文書を読ませる構成に固有の危険はプロンプトインジェクション対策の記事でも扱っており、社内の保管場所に外部由来の文書が混ざる点に触れています。