AIエージェントを業務に入れるとき、最後に必ず止まるのが「どこまで操作を任せてよいか」です。技術的にできるかどうかではなく、事故が起きたときに誰が責任を負うのかという問いなので、技術部門だけでは決められません。
この判断を、動くものができてから始めると必ず揉めます。設計をやり直すことになり、そこが一番高くつきます。
弊社は受託案件と自社のバックオフィス自動化の両方で、この線を何度も引いてきました。そのたびに使ってきた判断基準を、社内標準としてガイドラインにまとめ、公開します。
ガイドラインの構成
AIエージェント権限設計ガイドライン v1.0（全24ページ）
- 第1章5つの設計原則任せる／残すを分ける判断軸
- 第2章操作の分類と権限マトリクス参照・生成・状態変更・削除の4分類ごとの扱い
- 第3章PoC開始前チェックリスト（7項目）着手前に決めておくこと
- 第4章ヒューマン・イン・ザ・ループの設計スキルをどの単位で切るか
- 第5章行動監査とログ設計「エージェントが何をしたか」を後から追える形にする
- 付録社内説明用の1枚資料テンプレートセキュリティ部門・法務への説明に使う
第1章から：5つの設計原則
ガイドラインの中核です。ここだけでも判断に使えるので、記事に載せます。
1取り消せない操作は渡さない
契約送信・発注・公開・送金など、一度実行すると元に戻せない操作は人間の承認を経る。AIは下書きの作成まで。
2答えが1つに決まるならLLMを使わない
名前・日付・IDの差し込みに生成AIは不要。精度が上がらないまま、間違える余地だけが増える。
3権限は狭い側から始める
「動かすために必要だから広げる」で進めると、後から狭めるのが非常に難しい。例：削除はエージェント自身が作成したファイルのみ。
4確定値はコード側から渡す
金額・相手先・契約期間・ファイルパスは固定値でコードから渡し、LLMには「どのボタンを押すか」だけを任せる。
5スキルは「人が確認する単位」で分割する
10工程を1スキルにまとめると、人は最後の結果しか見られない。途中で間違ったとき、どこから間違ったのかが分からなくなる。止められる設計にしておくことが、任せる範囲を広げるための前提になる。
第2章から：操作の分類と扱い
| # | 分類 | 扱い |
|---|---|---|
| 1 | 参照 | 原則そのまま任せてよい。アクセス範囲のみスコープで制限する |
| 2 | 生成 | 任せてよい。ただし生成物であることの表示と、根拠の保持を必須にする |
| 3 | 状態変更 | 人間の承認を挟む。送信・登録・更新・公開。実行直前で停止し、入力値とスクリーンショットを提示する |
| 4 | 削除 | 原則として渡さない。渡す場合はエージェント自身が作成したリソースに限定する |
3と4を分けているのは、実際に困ったからです。共有ドライブでエージェントが処理をミスしたとき、権限の関係でファイルを削除できないという問題が起きました。ここで安易に削除権限を与えると、誤作動時の被害の質が変わります。狭い側から始めるべき典型例です。
第5章から：行動監査の考え方
「AIが何をしたか」を後から追える形にしておく。これはセキュリティ部門から必ず聞かれる論点ですが、意外と設計から抜けます。
# エージェントの1アクションで残すべき最小項目 timestamp : いつ actor : どのエージェント / どのスキル on_behalf_of : 誰の代理として実行したか ← 抜けやすい action_class : 参照 / 生成 / 状態変更 / 削除 target : 対象リソース input_source : 入力値の出どころ（コード固定値 / LLM生成 / ユーザー入力） approval : 承認者と承認時刻（状態変更・削除の場合は必須） result : 成否とエラー内容
on_behalf_of と input_source が要点です。「AIが勝手にやった」を成立させないために、どの値が誰に由来するかを残します。
なぜ公開するのか
この種の基準は、各社が個別に悩んで、個別に作り直しています。弊社が受託の現場で何度も同じ議論をしてきた実感として、叩き台があるだけで議論の速度がまったく違います。
ご自由にお使いください。社内標準として改変していただいて構いません。「この分類はうちには合わない」というご指摘は、次の版に反映します。
FREE DOWNLOAD
AIエージェント権限設計ガイドライン v1.0
全24ページ／PDF／チェックリストと社内説明用テンプレート付き。先行して第3章のチェックリスト（A4・1枚）を公開しています。