AIエージェントの権限・承認設計

生成AIは、文章を返すだけの道具ではなくなっています。メールを送り、カレンダーを更新し、ファイルを作り、社内システムの画面を操作するところまで任せられます。

ここで必要なのは、「AIに操作させない」というルールではありません。人がパソコンで繰り返していた作業を減らしながら、事故につながる操作だけを止められる仕組みです。

結論は、AIを止めるのではなく操作を4段階に分ける

AIに任せる範囲は、利用する製品名ではなく、操作が会社へ与える影響で分けます。

全部の操作に承認を求めると、人は確認ボタンを押すだけになります。逆に、全部を自動にすると、誤った宛先への送信や本番データの変更まで止められません。

人が判断する場所を増やすのではなく、取り返しのつかない境界にだけ残す。 これが最初に決める線です。

まず「読める」と「変更できる」を分ける

AIがGoogle DriveやMicrosoft 365、社内データベースへ接続できても、同じ権限で更新まで許可する必要はありません。

たとえば問い合わせ対応なら、次の3つは別の権限です。

• 過去の問い合わせと商品情報を読む
• 返信文を下書きする
• 顧客へ返信を送る

最初は、読み取りと下書きまでを自動化します。回答の精度が安定し、参照してよい情報も整理できてから、送信前の承認を付けて実行までつなげます。

ClaudeのGoogle Workspace接続は、接続した利用者が元から持つ権限を引き継ぎます。Gmailの送信などは既定で都度承認となり、TeamとEnterpriseでは管理者が承認方法を管理できます。ClaudeのGoogle Workspace接続

Google WorkspaceのGeminiも、利用者本人が閲覧できるファイルや予定の範囲を引き継ぎます。管理者はGemini自体の利用や、Workspaceデータへのアクセスを制限できます。GeminiがWorkspaceデータへアクセスする条件

製品側に権限管理があっても、共有フォルダが全社員へ開かれていれば、AIからも同じ範囲が見えます。AIの設定だけを見るのではなく、接続先の権限から直す必要があります。

人の承認は、外部に影響する直前へ置く

承認が必要かどうかは、「AIが作ったか」ではなく「実行後に何が起きるか」で決めます。

次の操作には、原則として実行直前の承認を置きます。

• 顧客や取引先へのメール・チャット送信
• ホームページ、SNS、広告の公開
• 本番データの削除や上書き
• 発注、契約、支払い、解約
• 権限の追加や変更

一方で、社内用の下書き作成、決められた場所への一時保存、検証環境での更新まで毎回止める必要はありません。

OpenAIのWorkspace Agentsでは、接続先への書き込み操作は既定で「毎回確認」に設定され、操作ごとに制約を加えることもできます。公式案内でも、送信・編集・投稿・削除につながる操作では承認設定を慎重に扱うよう示されています。ChatGPT Workspace Agentsの書き込み管理

承認画面には「実行しますか」だけを出すのではなく、宛先、変更前後、公開先、金額など、判断に必要な差分を表示します。内容を別画面で探さなければ承認できない仕組みは、そのうち確認されなくなります。

AIには個人の管理者権限を渡さない

経営者やシステム管理者のアカウントは、多くの情報を閲覧し、設定を変更できます。その権限をそのままAIに与えると、一つの作業に必要な範囲を大きく超えます。

実行用のアカウントや接続設定は、用途ごとに分けます。

Claudeの組織管理では、接続先や役割ごとに許可する範囲を設定できます。組織の認証基盤を使う場合も、AIが使える情報は接続先と認証基盤の権限に依存します。Claudeの組織向けコネクター認証

共通の管理者アカウントをAIと人で使い回すと、記録を見ても誰の操作か分かりません。AIの実行主体、人の承認者、設定を変更できる管理者を分けておくと、原因を追える状態になります。

操作記録だけでなく、戻し方まで先に決める

記録は、監視のためだけに残すものではありません。誤った操作が起きたときに、影響範囲を特定して戻すために使います。

最低限、次の情報を残します。

• 実行した日時と実行主体
• 参照したデータと実行した操作
• 変更前と変更後の内容
• 承認した人と承認時刻
• 成功・失敗の結果

さらに、ファイルなら版を戻せるか、公開なら一つ前の状態へ戻せるか、送信なら取り消せないことを前提に承認を置いているかを確認します。

監査ログは契約プランによって使える範囲が異なります。たとえばClaudeの監査ログはEnterprise向けで、組織の操作やシステムイベントなどを確認できます。Claudeの監査ログ

製品の監査ログが足りない場合は、AIから社内システムを直接操作させず、操作を受け付ける自社側の仕組みで履歴を残します。そこで対象、差分、承認、結果を一つの案件として保存すれば、AI製品を変更しても運用を引き継げます。

小さく試すなら、1つの業務を最後まで通す

「まずは全社員に使ってもらう」では、どこまで自動化できたかを判断できません。問い合わせ返信、記事公開、日報集計など、終点が分かる業務を一つ選びます。

その業務について、次の順番でつなげます。

1. 必要な情報をAIが集める
2. AIが下書きや変更案を作る
3. 機械で確認できる項目を自動検査する
4. 外部や本番、権限へ影響する直前だけ人が承認する
5. 実行結果と修正内容を次回へ残す

見るべきなのは、AIとの会話回数ではありません。人が転記した回数、確認にかかった時間、差し戻し、公開や送信までに必要だった操作が減ったかです。

途中までAIに作らせて、最後は人が別のシステムへ打ち直しているなら、まだ業務は変わっていません。精度を上げることと同時に、成果物が次の工程へ渡るところまで設計します。

製品の機能より、会社側の線引きが先

AIエージェントの機能は今後も変わります。製品ごとに承認画面や権限名が変わっても、会社が決めることは同じです。

• 何を読ませるか
• 何を変更させるか
• どこで人が承認するか
• 誰の権限で実行するか
• 何を記録し、どう戻すか

この5点を業務単位で決めれば、AIを止めずに実行範囲を広げられます。社内ルールを文章だけで終わらせず、権限と承認の仕組みに反映するところまでが導入です。

権限設計に関する各製品の仕様は、2026年9月11日に公式情報で確認しました。