AIエージェントを業務に入れたい。
問い合わせを整理してほしい。
メールの下書きを作ってほしい。
社内資料を探して、次のアクションまで出してほしい。
できれば、カレンダー、Gmail、Google Drive、Notion、CRM、社内ファイルまでつないで、面倒な仕事を先回りして片づけてほしい。
この流れは、かなり自然です。
生成AIが「質問に答えるもの」から「作業を進めるもの」に変わってきているので、次に気になるのはAIエージェントです。
ただ、ここでいきなりツール連携から始めると危ないです。
AIエージェントは、チャットAIより便利です。
でも便利なぶん、触れる範囲も広くなります。
ファイルを読む。
メールを作る。
フォームに入力する。
CRMを書き換える。
予定を変更する。
もし、そこに会社の大事な情報やお客様の個人情報が含まれていたら、ただの「便利ツール」では済みません。
総務省・経済産業省の AI事業者ガイドライン第1.2版 でも、AIの便益だけでなくリスクやガバナンスを見ながら活用することが整理されています。
OWASPの LLM06:2025 Excessive Agency では、LLMアプリが過剰な機能、過剰な権限、過剰な自律性を持つことがリスクとして扱われています。
難しい言葉で言えば、AIエージェントの権限設計。
でも、小さな会社で最初にやることは、もっと実務的でいいです。
AIエージェントを導入する前に、まず「何を読めるか」「何を作れるか」「何を送れるか」「何を消せるか」を分ける。
今日は、中小企業や小規模事業者がAIエージェントを導入する前に決めておきたい権限設計を、現場で使える形に整理します。
AIエージェントは、チャットより権限の設計が先に必要
ChatGPTに質問するだけなら、主に気をつけるのは入力する情報です。
お客様の名前を入れない。
未公開の売上情報を入れない。
契約書や個人情報をそのまま貼らない。
以前書いた 生成AIの社内ルールは、禁止より入力ルールから考える でも、最初は「何を入れてよいか」を決めることが大事だと書きました。
AIエージェントになると、ここにもう一段増えます。
入力する情報だけではなく、AIが触れる場所を決める必要があります。
たとえば、Google Driveとつなぐ。
これだけでも、かなり範囲が広いです。
営業資料だけ見ていいのか。
見積書も見ていいのか。
契約書フォルダは見ていいのか。
採用候補者の履歴書は見ていいのか。
お客様別のフォルダを横断していいのか。
古いファイルも見ていいのか。
「Driveにつなぐ」と一言で言っても、実際にはいろんな情報が混ざっています。
メールも同じです。
受信メールを読むだけなのか。
下書きまで作っていいのか。
送信していいのか。
アーカイブしていいのか。
ラベルを変えていいのか。
迷惑メール判定まで任せるのか。
ここを分けずに「AIにメール対応を任せたい」と言うと、急に怖くなります。
怖くなるのは、AIが悪いからではありません。
触れる範囲が曖昧だからです。
AIエージェントは、人が毎回クリックしていた作業を肩代わりできる可能性があります。
だからこそ、人が普段どこまで触っているのかを先に見える化しないといけません。
AIに任せる前に、業務側の権限を棚卸しする。
この順番です。
僕は、AIエージェント導入の相談では、まず「何とつなぎたいですか」よりも、「その作業で触っている場所を全部出しましょう」と聞きます。
Gmail。
Drive。
スプレッドシート。
CRM。
請求システム。
予約カレンダー。
公式LINE。
社内チャット。
こうして並べると、便利にしたい作業の裏に、かなり多くの権限が隠れていることが分かります。
ここを見ないまま導入すると、「便利そうだけど怖い」で止まります。
逆に、権限の範囲が見えると、小さく始められます。
まずは読むだけ。
次に下書きだけ。
承認後に送信。
削除はさせない。
このように段階を切れるからです。
最初に分けるのは「読む」「作る」「送る」「消す」権限
AIエージェントの権限設計は、最初からセキュリティ専門用語で考えなくても大丈夫です。
小さな会社でまず使いやすいのは、4つに分ける方法です。
- 読む
- 作る
- 送る
- 消す
この4つです。
「読む」は、ファイルやメールや顧客情報を参照する権限です。
AIが何を見てよいか。
どのフォルダまで見てよいか。
どの期間の情報まで見てよいか。
社外秘や個人情報が含まれる場所はどう扱うか。
ここを決めます。
「作る」は、下書きやメモや提案文を作る権限です。
メール本文を作る。
問い合わせの分類案を作る。
議事録からタスク案を作る。
スプレッドシートへ転記する前の確認メモを作る。
この段階では、まだ外に出ていません。
人が見て直せるので、最初の試行に向いています。
「送る」は、メール送信、チャット投稿、フォーム送信、顧客への通知など、外部や他者に届く行為です。
ここからリスクが上がります。
AIが作った文章をそのまま送ると、宛先間違い、温度感のズレ、誤った条件提示が起きる可能性があります。
だから、送る権限は最初から開けすぎない方がいいです。
OpenAIの Guardrails and human review でも、キャンセル、編集、シェルコマンド、MCPの機微な操作のような副作用がある処理では、人による承認で一時停止する考え方が示されています。
小さな会社の実務でも同じです。
送信、変更、決済、削除。
こういう処理は、最初は人の承認を挟む。
これだけで、かなり事故を減らせます。
最後が「消す」です。
これは一番慎重に扱った方がいいです。
メールを削除する。
ファイルを削除する。
CRMの顧客情報を削除する。
予約をキャンセルする。
請求情報を取り消す。
こうした操作は、便利さより戻しにくさが問題になります。
AIエージェントの最初の導入では、「消す」は基本的に渡さなくていいと思っています。
どうしても必要なら、まずは削除ではなく「削除候補として一覧化」まで。
人が確認してから処理する。
これで十分です。
AIエージェントの権限設計は、「全部できるようにする」ことではありません。
その業務で本当に必要な動作だけを渡すことです。
読み取りだけで済むなら、書き込みは渡さない。
下書きで済むなら、送信は渡さない。
アーカイブで済むなら、削除は渡さない。
これが、最初の現実的な線引きです。
共有アカウントではなく、誰の代わりに動くかを決める
AIエージェント導入で、地味だけどかなり大事なのがアカウントです。
誰のアカウントで動かすのか。
ここを雑にすると、あとから管理が大変になります。
よくあるのは、共有アカウントで全部つないでしまうパターンです。
会社共通のGmail。
共通のGoogleアカウント。
共有の管理者ID。
とりあえず便利だから、そのアカウントにAIをつなぐ。
気持ちは分かります。
でも、これは最初から広くなりがちです。
誰が使ったのか分かりにくい。
どの操作がAIで、どの操作が人なのか分かりにくい。
退職者や外部パートナーが関わったときに、どこまで権限が残っているか分かりにくい。
何か起きたときに追いにくい。
この「追いにくい」が、運用ではかなり痛いです。
OWASPのExcessive Agencyでも、ユーザーの代わりに動く処理は、特定ユーザーの文脈と必要最小限の範囲で実行する考え方が示されています。
つまり、AIエージェントを「万能な社内共有アカウント」にしない。
誰の代わりに、どの範囲で、何をするのか。
この単位で考えます。
たとえば、問い合わせ対応のAIエージェントなら、最初は次のように分けられます。
- 共有受信箱の新着メールを読む
- 問い合わせ種別を分類する
- 担当者向けの返信下書きを作る
- 送信は担当者が行う
- CRM更新は担当者の確認後に行う
この形なら、AIは「社内の下書き補助」として動きます。
まだ、お客様に直接触れていません。
次に進めるとしても、すぐに完全自動返信へ行く必要はありません。
担当者が承認した場合だけ送る。
特定のテンプレートに合う問い合わせだけ送る。
料金や契約条件を含む場合は送らない。
個人情報を含む場合は人に戻す。
こうやって段階を切ります。
以前書いた 中小企業のAI担当者は、詳しい人より業務を聞ける人から育てる ともつながります。
権限設計は、情シスだけの仕事ではありません。
現場で「誰が何を確認しているか」を聞ける人が必要です。
AIエージェントは、会社の仕事を横断します。
だから、技術より先に、役割の整理が必要になります。
社長が承認すること。
担当者が確認すること。
AIが下書きすること。
外部パートナーが設計を手伝うこと。
ここを分けておくと、AIが暴走するというより、そもそも暴走しにくい業務になります。
承認なしで動かしていい範囲を小さくする
AIエージェントの怖さは、考えることではありません。
勝手に動くことです。
もちろん、勝手に動いてくれるから便利でもあります。
でも、最初から自律性を広くしすぎると、確認する側が不安になります。
どこまでやったのか。
何を根拠に判断したのか。
誰に送ったのか。
何を書き換えたのか。
このあたりが見えないと、現場は使い続けられません。
だから最初は、承認なしで動いていい範囲を小さくします。
おすすめは、3段階です。
- 自動でやっていいこと
- 下書きまでやっていいこと
- 必ず承認が必要なこと
自動でやっていいことは、失敗しても戻しやすいものです。
たとえば、社内メモの分類案を作る。
問い合わせの要約を作る。
会議メモからタスク候補を出す。
FAQ候補を並べる。
こういうものは、人に届く前の材料なので、比較的始めやすいです。
下書きまでやっていいことは、外に出る可能性があるけれど、まだ送らないものです。
メール返信案。
提案文のたたき台。
お知らせ文。
契約前の確認事項リスト。
請求前の明細確認メモ。
ここはAIの力を借りる価値が大きいです。
ただし、人が見る前提にします。
必ず承認が必要なことは、外部送信、金額変更、顧客情報更新、削除、キャンセル、契約や法務に近い判断です。
ここをAIだけで進めるのは、最初は避けた方がいいです。
OpenAIの Safety in building agents でも、MCPツール利用時の承認、個人情報の検出、トレースや評価など、複数の対策を組み合わせる考え方が示されています。
小さな会社で全部を完璧に作る必要はありません。
ただ、承認の線は決められます。
AIが作ったものを誰が見るのか。
何を見たら承認してよいのか。
どんな場合は送らずに止めるのか。
送信後に間違いが分かったら、誰に連絡するのか。
これを決めるだけでも、導入の安心感はかなり変わります。
AIエージェントを入れるとき、「どこまで自動化できるか」ばかり考えると、話が大きくなります。
最初に考えるのは逆です。
どこで人が止めるか。
どこで確認するか。
どこから先はまだ自動化しないか。
この線引きがあるから、現場は安心して試せます。
ログと戻し方まで決めてから小さく試す
AIエージェントの権限設計で、もう一つ忘れやすいのがログです。
何をしたかを残す。
何を見たかを残す。
誰が承認したかを残す。
どこで止めたかを残す。
これがないと、改善できません。
便利だったのか。
危なかったのか。
どの作業で迷ったのか。
どの権限が広すぎたのか。
どの確認が毎回必要だったのか。
ログがないと、全部が感覚になります。
「なんか怖い」
「たぶん便利」
「たまに間違える」
これでは、次の設計に進めません。
前に書いた 生成AIの業務自動化は、いきなり連携より社内メモの型化から始める でも、最初は社内メモと運用ログを整える話をしました。
AIエージェントでも同じです。
最初から大きな連携を作るより、まずログが残る小さな業務で試す。
たとえば、問い合わせ対応ならこうです。
- 問い合わせを要約した
- 種別を分類した
- 返信下書きを作った
- 担当者が修正した
- 送信は人が行った
- 修正理由を一言残した
これだけでも十分です。
1週間たつと、かなり見えてきます。
AIの要約は使える。
分類はだいたい合っている。
料金の話は少し危ない。
お客様の温度感は人が見た方がいい。
日程調整URLの貼り忘れがある。
個人情報が含まれるときは入力前に伏せる必要がある。
こういう発見が、次の権限設計になります。
NISTの AI Risk Management Framework は、AIのリスクを設計、開発、利用、評価の中で管理していくための枠組みとして公開されています。
現場の小さな運用に置き換えるなら、「一度作って終わり」ではなく、ログを見て調整するということです。
加えて、戻し方も決めます。
AIが間違った分類をしたら、どこで直すか。
誤った下書きが作られたら、誰が修正するか。
CRMへ間違った情報が入ったら、どの履歴を見て戻すか。
ファイルが移動されたら、どこから戻すか。
この戻し方がない状態で、書き込みや削除を任せるのは怖いです。
AIエージェント導入の最初のゴールは、完全自動化ではありません。
「小さく動かして、ログを見て、権限を調整できる状態」を作ることです。
ここまでできると、次の自動化がかなり現実的になります。
30日で作る権限設計メモの型
では、実際に何から始めればいいのか。
おすすめは、いきなりAIエージェントを本格導入するのではなく、30日で権限設計メモを作ることです。
難しい資料でなくて大丈夫です。
1枚の表でいいです。
項目は、次のくらいで十分です。
- 業務名
- 使いたいAIエージェントの役割
- AIが読んでよい情報
- AIが作ってよい下書き
- AIが書き換えてよい場所
- AIに送信させないもの
- AIに削除させないもの
- 承認者
- ログに残す項目
- 失敗時の戻し方
これを、1つの業務で作ります。
最初から全社分はやりません。
問い合わせ対応。
議事録整理。
提案書の下書き。
FAQ更新。
公式LINEの相談整理。
このうち、1つだけでいいです。
1週目は、業務の流れを書き出します。
誰が受けているのか。
何を見ているのか。
どこに入力しているのか。
誰に送っているのか。
どこで判断しているのか。
2週目は、AIに任せたい作業を分けます。
読むだけでいいもの。
下書きまででいいもの。
承認後に進めたいもの。
まだ任せないもの。
3週目は、実際に人の手で試します。
AIエージェント化する前に、AIに貼るメモを作る。
下書きを出す。
人が直す。
修正理由を残す。
この段階で、権限を広げる必要があるのか、むしろ狭めるべきなのかが見えます。
4週目は、ルールにします。
この業務では、AIはここまで読む。
ここまでは下書きする。
送信は人がする。
削除はしない。
この条件なら次にツール連携を検討する。
ここまで決められたら、AIエージェント導入の土台としてかなり強いです。
逆に、このメモが作れないなら、まだエージェント化しない方がいいです。
業務の流れが見えていない。
AIに見せる情報が決まっていない。
承認者が決まっていない。
戻し方が決まっていない。
この状態でツールだけつないでも、現場は不安になります。
AIエージェントは、魔法の自動化担当ではありません。
会社の仕事の一部を、権限つきで手伝う存在です。
だから、最初に必要なのは「すごいAIを選ぶこと」より、「どこまで任せるかを言葉にすること」です。
ここが、カタチ舎が伴走できるところだと思っています。
AIを入れたいけれど、どの業務から始めるべきか分からない。
AIエージェントに何をつないでよいか不安。
社内ルール、権限、承認、ログまで含めて整理したい。
そんな場合は、まず一つの業務を一緒に棚卸しするところから始められます。
AI内製化や業務整理の相談はこちら から、今の業務と試したいことをそのまま送ってください。
いきなり大きな自動化にしなくて大丈夫です。
まずは、AIに渡す鍵を小さく分けるところからです。
Author
村上龍平
カタチ舎代表。言葉、生成AI活用、資料・Web制作を行き来しながら、事業の考えを届く形へ整理しています。