AIエージェントを業務で使いたい、という相談が増えています。以前のAI活用は、文章を作る、資料を要約する、質問に答えるといった使い方が中心でした。ところが最近は、AIが複数のツールを呼び出し、画面を読み、入力候補を作り、業務手順の一部を進めるところまで視野に入ってきています。
ここで大切なのは、AIエージェントを「賢い担当者」として扱わないことです。AIは作業を助けることはできますが、会社の責任を引き受けることはできません。メールを送る、顧客情報を更新する、申請を通す、公開ページを書き換える、発注する。こうした行為には、権限と責任が伴います。
そのため、AIエージェント導入では、どのモデルを使うかより先に、どの権限を渡すのか、どこで人間が承認するのか、ログをどう残すのか、失敗したときにどう止めるのかを決める必要があります。
AIエージェントは「回答するAI」から「作業するAI」へ
チャット型AIは、質問に答える、文章を作る、アイデアを出すといった用途で広がりました。これは主に「回答するAI」です。人間が内容を読み、必要に応じてコピーし、別のシステムに入力します。
一方、AIエージェントは、そこから一歩進みます。目的を受け取り、作業を分解し、必要な情報を探し、ツールを呼び出し、結果をまとめる。場合によっては、ブラウザ、メール、表計算、社内システム、チケット管理ツールなどを横断します。
便利に見える反面、リスクも変わります。AIが読むだけなら誤回答の問題で済むことがあります。しかし、AIが書き込む、送信する、削除する、公開する段階に入ると、業務上の損失や情報漏えいにつながる可能性があります。
まず分けるべき三つの権限
導入前に、AIエージェントへ渡す権限を三段階に分けると考えやすくなります。
| 権限 | できること | 導入時の考え方 |
|---|---|---|
| 読む権限 | 資料、FAQ、公開情報、社内マニュアルを参照する | 最初に試しやすい。ただし機密情報の範囲を決める |
| 下書きする権限 | メール案、回答案、申請文、レポート案を作る | 人間が確認して使う前提にする |
| 実行する権限 | 送信、登録、更新、削除、公開、発注などを行う | 最初から渡さない。高リスク操作は人間承認を必須にする |
多くの会社では、最初から実行権限を渡す必要はありません。まずは「読む」「下書きする」までに絞る方が安全です。問い合わせ返信案を作る、会議メモを整理する、申請内容の不足を指摘する、FAQの候補回答を出す。この段階でも十分に業務負担は減らせます。
実行権限を渡す場合は、対象システム、操作内容、金額、顧客情報、公開範囲ごとに上限を決める必要があります。「AIなら速いから全部任せる」ではなく、「AIに任せてもよい操作だけを明示する」ことが重要です。
承認フローは作業の重要度で変える
すべての作業に同じ承認を入れると、現場では使われません。反対に、すべてを自動実行にすると、事故が起きたときに止められません。そこで、作業をリスク別に分けます。
| リスク | 作業例 | 承認設計 |
|---|---|---|
| 低 | 公開情報の要約、社内FAQ検索、議事録整理 | AI実行後に人間が確認する |
| 中 | 顧客返信案、社内申請案、CRM更新案、見積補助 | 担当者確認後に実行する |
| 高 | 外部送信、契約、金銭、個人情報、権限変更、公開ページ更新 | 人間承認を必須にし、必要に応じて二重確認にする |
たとえば、AIが問い合わせメールの返信案を作ることは有効です。しかし、顧客へ直接送信する前には担当者の確認が必要です。AIが経費申請の内容をチェックすることは有効ですが、承認ボタンを押すのは権限を持つ人間に残すべきです。
この線引きは、会社ごとに違います。重要なのは、AI導入後に現場任せで決めるのではなく、導入前に「AIができること」「人間が確認すること」「AIにさせないこと」を一覧化しておくことです。
ログがないAI自動化は、あとで説明できない
AIエージェントを業務に入れるなら、ログは欠かせません。便利だったかどうかだけでなく、問題が起きたときに説明できるかが重要です。
最低限、次の情報は残したいところです。
- 誰がAIに依頼したか
- AIがどの資料や画面を参照したか
- AIがどの操作を提案したか
- 誰が承認したか
- いつ実行したか
- 失敗時に誰が止めたか、どう戻したか
ログがないと、「AIが勝手にやったのか」「人間が承認したのか」「どの情報を見て判断したのか」がわからなくなります。これは社内管理だけでなく、顧客説明、監査、セキュリティ対応にも関わります。
AIエージェントは、作業を速くする道具です。だからこそ、速く間違える可能性もあります。ログは、AIを疑うためではなく、業務として扱える状態にするための土台です。
Prompt Injection と過度な権限に注意する
AIエージェントの安全設計では、プロンプトインジェクションへの注意が必要です。AIがWebページ、メール、添付ファイル、社内文書を読むとき、その中に人間向けではない命令が紛れ込む可能性があります。AIがそれを本来の作業指示と誤解すると、意図しない行動につながります。
OWASPの Top 10 for LLM Applications では、Prompt Injection、Sensitive Information Disclosure、Excessive Agency、Overreliance などがLLMアプリケーションの代表的なリスクとして整理されています。AIエージェントは外部情報を読み、ツールを使い、行動できるため、これらのリスクが業務操作に直結しやすくなります。
NISTの AI Risk Management Framework も、AIの設計、開発、利用、評価の中でリスクを管理する考え方を示しています。生成AI向けには NIST AI 600-1 も公開され、生成AI固有のリスクを組織がどう扱うかが整理されています。
実務上は、外部Webやメールを読むAIに、強い実行権限を渡さないことが基本です。読ませるものと実行できる操作を分ける。重要操作には人間確認を入れる。想定外の画面や指示が出たら停止する。こうした地味な設計が、事故を減らします。
中小企業が最初に作るべき小さなルール
大きなAIガバナンス規程を最初から作る必要はありません。中小企業では、まず現場が使える小さなルールから始める方が現実的です。
- AIに読ませてよい資料を決める
- AIが触ってよいシステムを決める
- AIが下書きしてよい作業を決める
- 人間確認が必要な作業を決める
- AIにさせない作業を決める
- 失敗時の連絡先と停止手順を決める
たとえば、最初のPoCでは「AIは社内FAQと公開情報だけを読む」「顧客への返信は下書きまで」「送信は担当者が行う」「個人情報を含む画面は対象外」「ログを残す」といったルールで十分です。
この程度のルールでも、現場の安心感は大きく変わります。AIを使ってよい範囲が明確になると、担当者は迷わず試せます。反対に、何も決まっていないと、積極的な人だけが自己判断で使い、慎重な人は使わないという状態になりがちです。
小さく始めるなら、実行より「提案」から
AIエージェント導入で最初に狙うべきなのは、完全自動化ではありません。まずは提案です。
メール返信案を作る。FAQ回答候補を出す。申請内容の不足を指摘する。議事録からタスク候補を作る。社内資料の参照先を示す。こうした用途なら、AIが間違えても人間が確認できます。成果も測りやすく、現場にも受け入れられやすいです。
慣れてきたら、低リスクな実行から試します。たとえば、担当者確認後にチケットを作成する、承認済みの文章を所定の場所へ登録する、公開情報を表にまとめるといった範囲です。段階的に進めることで、権限、承認、ログ、停止条件を運用しながら改善できます。
SMARTWAYが支援できること
SMARTWAYでは、AIエージェント導入前の業務フロー整理、権限設計、承認フロー設計、PoC作成、社内ルール整備、担当者向け研修までを一体で支援します。
AIエージェントは、業務の負担を減らす可能性があります。しかし、企業に必要なのは「AIに全部任せること」ではありません。AIに任せる部分、人間が確認する部分、AIにさせない部分を分けることです。
AIエージェントを安全に業務へ取り入れたい場合は、お問い合わせページよりご相談ください。関連する内容として、ブラウザ操作型AIエージェントの実務利用、社内FAQとナレッジAI化の準備、AI時代の開発・運用ガバナンスもあわせてご覧ください。
公開日：2026年7月13日
