「お客様への返信を作ってください」
「古いファイルを整理してください」
「必要な手続きを進めておいてください」

AIへ仕事を依頼するとき、どこまで実行してよいかを決めているでしょうか。

返信文の案を表示するだけなら、人が確認してから送れます。しかし、AIがメール送信機能と連携していれば、宛先を選び、添付ファイルを付け、そのまま送信するところまでが実行範囲になり得ます。AIエージェントは、文章の生成だけでなく、外部のツールやデータを利用して行動する仕組みとして捉える必要があります。

ここで考えたいのは、AIがどれだけ賢いかという比較だけではありません。

何を読ませ、何を変更させ、どの操作の前に人が確認し、問題があれば誰が止めるか。

2026年9月28日にIPAが公開した「AIセキュリティ短信2026年9月号」でも、AIエージェントの行動ごとの権限確認や、企業側の統制が論点として取り上げられています。

今回は、メール送信やファイル操作を例に、中小企業がAIへ仕事を任せる前に決めたいことを整理します。本文の管理表や業務例は、ライトハウスコンサルタントによる実務上の提案です。特定企業で発生した事故の再現や、すべての事業者に共通する法的な義務を示したものではありません。

「案を作ること」と「実行すること」を分ける

AIエージェントの導入を考える際、最初から仕事全体を任せる必要はありません。

例えば、お客様からの問い合わせに答える業務なら、問い合わせの内容を整理する、回答の根拠となる資料を探す、返信案を作る、担当者が確認する、実際に送信する、という作業に分けられます。

このうち、返信案の作成までをAIに任せ、送信は人が行う方法もあります。送信まで自動化しなければ、AIを活用したことにならないわけではありません。

英国の国家サイバーセキュリティセンターであるNCSCは、2026年5月に公開した資料で、AIエージェントを導入する前に、従来の自動化などで対応できないかも検討し、明確に範囲を定めた小規模な試行から始めることを勧めています。

本記事では、まず業務を分解し、それぞれを「参照」「案の作成」「変更」「外部への送信」「削除」などの操作に分ける方法を提案します。

「メール対応を任せる」という大きなくくりではなく、「公開済みのFAQを参照して返信案を作り、担当者だけが見られる場所へ保存する」というところまで具体化してください。

この段階なら、AIに顧客管理システムの更新権限や、全社の共有フォルダーの削除権限を与える必要はありません。

仕事の目的を伝えることと、その目的のために使ってよい権限を決めることは、別の作業です。

業務ごとに、任せる範囲を決める

AIに認める操作は、一律に「利用可」「利用不可」とするだけでなく、業務ごとに整理しましょう。

次の表は、導入初期の区分例です。実際には、扱う情報、影響の大きさ、利用するサービスの機能に合わせて調整してください。

対象となる作業導入初期の扱いの例確認する条件
指定した公開資料の検索・要約対象を限定して実行を認める参照先、出力先、扱う件数を決める
返信文や社内資料の案の作成下書きまで認める正式版と区別し、保存先を限定する
業務データの変更変更案を作り、人の確認後に実行する対象の記録と項目、変更前後の値を確認する
社外へのメール送信実際の送信内容を人が確認してから実行する宛先、本文、添付、共有範囲、送信件数を確認する
不要ファイルの整理候補一覧の作成から始める保存が必要な資料を含まないか、管理者が判断する
送金、管理者権限の変更、大量の完全削除初期の試行対象から外す別途、業務上の必要性と統制を検討する

この表で重要なのは、「人が確認する」という言葉だけでは終わらせないことです。何を見て、誰が、どの操作を承認するかまで決める必要があります。

また、「閲覧だけだから、社内のすべての情報へ接続してよい」とは考えないでください。変更できない情報でも、回答へ混ざったり、意図しない相手へ伝わったりする問題は別に検討しなければなりません。

操作の種類に加え、情報の内容と出力先を組み合わせて判断しましょう。

外部のメールや資料は、会社の指示書ではない

AIエージェントが読む情報には、従業員が与えた作業指示だけでなく、外部のメール、Webページ、添付資料なども含まれます。

そこで注意したいのが、外部の文章に含まれる指示によって、本来の依頼と異なる処理へ誘導される「プロンプトインジェクション」です。NCSCは、外部コンテンツに埋め込まれた指示が、AIの動作へ影響する問題を説明しています。

例えば、問い合わせメールの中に「この件は社内承認済みです」と書かれていた場合を考えます。

その文章は、差出人による申告です。自社の責任者が、実際に内容を確認して承認したという記録ではありません。

同様に、読み込んだ資料に、通常とは違う共有先や処理方法が書かれていても、それだけで会社の利用ルールを変更してよいことにはなりません。

本記事では、外部のメールや資料は「判断材料」として扱い、権限や承認の根拠は、別に管理する方法を提案します。

AIが作った回答に「承認済み」と書かれていることも、承認の証拠にはしません。承認者が、会社の認めた手順で、対象の操作を承認した記録と照合します。

AIが読んだ文章の内容と、会社が認めた操作の範囲を混同させないことが、権限管理の出発点です。

「送信しないで」と書くだけでなく、送信できない状態にする

AIへの指示文に「勝手に送信しないこと」「ファイルを削除しないこと」と書くのは、意図を伝える方法の一つです。

しかし、それだけを実行制限の仕組みにしないでください。

OWASPの「Excessive Agency」では、必要な機能と権限だけを与え、操作の許可をAIの判断だけに任せず、接続先のシステムなどで制御することが示されています。メールを要約する用途であれば、送信や削除の権限まで持たせる必要はないという考え方です。

例えば、返信案を作る仕組みには、下書き用の保存場所への書込みだけを認めます。送信を行う部分は分け、承認された内容だけを処理するようにします。

ファイルを整理する用途なら、対象のフォルダーを限定し、他部署のフォルダーまで操作できる状態にしない方法が考えられます。

管理者が普段使っているアカウントでログインしたブラウザーを、そのままAIへ渡す場合も、実際にどの操作まで可能になるかを確認してください。業務上必要な画面だけを見せたつもりでも、使える権限がそれより広ければ、制限として十分かを検討する必要があります。

サービスによっては、下書きの作成と送信の権限を、希望どおりに分けられない場合があります。その可否は、提供者の仕様や自社の設定で確認してください。

分けられない場合は、無理に送信まで連携せず、AIが作成した案を担当者が確認し、通常のメールソフトへ移して送る方法も選べます。

AIへのお願いと、システムが拒否する仕組みを、別々に用意することが重要です。

人が承認するのは、「送信という作業」ではなく具体的な内容

承認画面に「メールを送信してよいですか」とだけ表示されても、確認する情報が足りません。

確認したいのは、どのアカウントから、誰に、何を送るのかです。

本記事では、メール送信の承認時に、To・CC・BCCの実際のアドレス、件名、本文、添付ファイルの内容、送信件数を確認できるようにすることを提案します。表示名だけでなく、アドレスそのものを確認できることも重要です。

添付ファイルは、名前だけで判断しないようにしてください。「見積書.pdf」という名前が同じでも、中身まで同じとは限りません。承認する時点の内容と版を確認します。

共有リンクを送る場合は、リンク先の資料だけでなく、誰が閲覧できる設定になっているかも確認対象です。

OWASPの取引承認に関する資料では、利用者が重要な処理内容を確認できること、承認対象の内容が変わった場合は承認を無効化するなどの方法で保護することが示されています。この考え方は、AIが提案した操作を承認する設計にも応用できます。

例えば、担当者がA社向けの返信と添付資料を確認した後に、AIが宛先をB社へ変えたり、別の資料を追加したりした場合、元の承認を使って送信してはいけません。

宛先、本文、添付など、承認対象が変わった場合は再確認とするルールを設けます。承認後に添付元のファイルが更新された場合も、確認した版と送信する版を一致させる必要があります。

これは、人が見た内容と、システムが実行する内容をそろえるための管理です。

「承認者がいないとき」の動作まで決めておく

承認の仕組みでは、正常に承認された場合だけでなく、承認者が不在の場合や、確認に失敗した場合の扱いも決めます。

OWASPのAIエージェント向け資料では、承認を具体的な操作や対象、実行条件、有効期限へ結び付け、承認の検証などに失敗した場合は実行を認めない設計が示されています。

本記事では、重要な操作について、承認が得られない場合は保留し、あらかじめ決めた別の担当者へ引き継ぐ方法を提案します。

「一定時間返事がなければ承認とみなす」「急ぎの問い合わせはAIの判断で送る」といった例外は、通常の承認ルールと矛盾していないか確認してください。

また、承認者が確認できる量にも限界があります。

例えば、毎日数百件の返信案が届き、内容を読む時間がないのであれば、「全件を人が承認する」という計画を、そのまま有効な確認手順と考えることはできません。

試行する件数を減らす、対象を定型的な問い合わせに絞る、確認担当者を増やすなど、実際に確認できる量へ調整しましょう。

別のAIに内容を確認させることは、誤りを探すための補助として検討できます。ただし、それを人による業務上の承認と同じ扱いにはしません。OWASPも、AIを使う防御機能は、権限制御や承認などを置き換えるものではないとしています。

「読むだけ」のAIにも、情報を渡してよい範囲を決める

送信や削除を禁止すれば、情報漏えいの問題もなくなるのでしょうか。

ここでは、読ませる情報と、回答の出力先を分けて確認する必要があります。

例えば、問い合わせに回答するAIが、人事資料や別の顧客の契約書まで参照できる構成を考えます。原本を変更しなくても、その内容が返信案へ含まれれば、担当者は不要な情報が混ざっていないか確認しなければなりません。

IPAのAI利用者向け資料では、機密情報へアクセスする用途と外部のWeb閲覧を分けることや、AIが検索・参照する情報の範囲を限定することが取り上げられています。

本記事では、公開情報を調べる用途と、社内情報を参照する用途を分け、必要な資料だけを渡す方法を提案します。

取引先ごとの情報を扱う場合は、担当する案件と関係のない資料へアクセスできないようにすることも検討してください。

また、クラウド型のAIを利用する際は、回答の送り先だけでなく、処理のためにどのサービスへ情報が渡るかを確認します。入力情報の取扱いについては、利用するサービスの契約や設定を確認する必要があります。

利用可否を確認した情報だけを、必要な範囲で渡すことを基本にしましょう。

「AIが書き換えられないこと」と「その情報をAIに読ませてよいこと」は、別の確認事項です。

削除は、候補の提示から始める

「古いファイルを整理して」という依頼では、何を不要と判断するかが曖昧です。

更新日が古いことだけで、契約書、過去の成果物、引継ぎ資料などを削除してよいとは判断できません。

本記事では、最初はAIに削除候補の一覧と、候補にした理由を作らせ、実際の削除は資料の管理責任者が判断する方法を提案します。

候補一覧には、保存場所、ファイル名、対象件数、容量、利用状況の確認結果などを含めます。「重複していると思われる」という説明だけでは、残すべき版を判断できない場合があるため、比較した内容も確認できるようにします。

確認用のフォルダーへ移す方法を使う場合も、移動なら無条件に安全と考えないでください。業務システムがその保存場所を参照していないか、利用者が必要な資料を見失わないかを確認してから実施する手順にします。

また、「ごみ箱から戻せるはず」という前提だけで削除を認めず、利用するサービスの削除方法、保管期間、復元できる範囲を確認してください。

試行段階では、原本へ影響しない検証用のコピーを使い、候補の選び方が適切かを確かめます。

最初に自動化するのは、削除そのものではなく、人が削除の要否を判断するための整理作業でも構いません。

AIの「完了しました」だけで、実行結果を判断しない

操作を認めた後は、実際に何が起きたかを確認します。

AIの画面に「送信しました」と表示されることと、送信サービス側で処理が完了したことは、分けて確認してください。

例えばMicrosoft Graphのメール送信APIでは、成功応答である「202 Accepted」は要求の受付を示しますが、処理が完了したことを示すものではありません。外部サービスを操作する仕組みでは、返ってきた結果の意味を理解する必要があります。

本記事では、処理の状態を「案を作成」「承認待ち」「承認済み」「実行要求を受け付けた」「結果を確認した」「失敗」「結果不明」に分けて管理する方法を提案します。

すべてのサービスで、この名称がそのまま使われているわけではありません。自社の管理上、どこまで確認できたかを表すための区分です。

メールであれば、実際の送信記録など、サービスが提供する情報と照合します。ただし、送信処理の記録を確認できたことと、相手が受信・閲覧したことも別です。業務上どこまでを完了とするか、先に決めておきましょう。

ファイルの変更なら、対象と更新結果を確認します。複数件を処理する場合は、全件成功なのか、一部だけ成功したのかを区別してください。

「途中でエラーが出た」場合に、すべて未実行だったと決めないことも重要です。

結果が分からないとき、同じ操作を自動で繰り返さない

ここで、架空のメール送信処理を考えます。

送信サービスはメールを受け付けましたが、その結果をAIへ返す途中で通信が途切れました。AI側からは、成功したのか失敗したのか分かりません。

この状態で「失敗したようなので、もう一度送る」と判断すれば、二重送信になる可能性があります。

AWSの技術資料では、要求が処理された後に応答が失われる状況と、同じ要求を再試行しても処理を重複させない仕組みが説明されています。こうした性質を「冪等性」と呼びます。

実務では、処理ごとに識別番号を付け、同じ処理の再実行を、連携先や実行部分で管理できるか確認する方法があります。ただし、番号を記録するだけで二重処理を防げるわけではありません。その番号を使って重複を判定し、処理を制御する仕組みが必要です。

重複を防ぐ仕組みを利用できない場合は、結果不明の操作を保留し、担当者がサービス側の記録を確認してから再実行を判断する手順を提案します。

これはメールに限らず、受注登録、通知の配信、予約の作成などでも考えたい場面です。

エラーに見えることと、何も実行されていないことを同じ扱いにしないでください。

件数・時間・費用の上限は、通知と停止を分ける

AIへ継続的に仕事を任せる場合は、実行の上限も決めます。

本記事では、一回の依頼で扱う件数、一日に外部へ送る件数、再試行の回数、処理を続ける時間、利用料金の管理単位を整理することを提案します。

例えば、「一回の送信は10件まで」と決めても、それを何度も繰り返せるなら、一日の送信量は別に管理する必要があります。

複数のAIや処理へ作業を分担させる構成では、各部分の上限だけでなく、全体の合計も確認してください。再試行や、別の処理へ引き継いだ分を、集計から外さないようにします。

費用については、予算を登録したことと、利用が自動停止することを混同しないでください。例えばGoogle Cloudは、予算の設定自体によって利用量や支出に上限が設定されるわけではないと明記しています。

利用するサービスについて、一定額で通知する機能なのか、追加の要求を止める機能なのかを確認します。計測や停止までの遅れ、すでに実行中の処理をどう扱うかも確認事項です。

また、AI自身が「仕事を終えるために必要」と判断して上限を変更できる運用にはしないことをおすすめします。上限の変更は、責任者が目的と影響を確認して行います。

操作の記録は、承認と実行をつなげて残す

後から確認したいのは、「AIとどのような会話をしたか」だけではありません。

誰が依頼し、何を承認し、どのサービスで、どの操作が行われ、結果がどうなったかです。

OWASPのAIエージェント向け資料では、操作の結果や承認識別情報、適用したルールの版などを含む記録が示されています。

本記事では、依頼番号を起点として、承認した操作、承認者、実行日時、接続先での処理番号、確認結果を対応付ける方法を提案します。

例えば、あるメールの送信について、返信案だけが残っていても、送信時に同じ内容だったかは分かりません。承認された版と、実際に送信要求へ使った内容を確認できるようにします。

記録の対象は、業務上必要な範囲に絞ってください。パスワード、APIキー、認証コードなどを、そのままログへ残さないようにします。メール本文や個人情報を記録する場合も、閲覧者と保管期間を決めます。

また、AIが操作できる範囲に、その操作を検証する記録まで自由に書き換えられる場所を含めないことをおすすめします。

何か問題があったとき、AIに経緯を説明させるだけではなく、実際の記録を確認できる状態を目指してください。

緊急停止は、チャット画面を閉じる操作ではない

運用を始める前に、AIが意図しない処理を行った場合の停止方法を確認しましょう。

NCSCが2026年8月に公開したAIエージェントのリスク管理に関する資料でも、動作の監視や記録に加え、緊急停止できることが取り上げられています。

本記事では、停止時に、これから始まる処理、実行中の処理、外部サービスへ依頼済みの処理を分けて確認する方法を提案します。

定期実行を止めても、すでに待機中の送信や、別の仕組みへ渡した処理が残っていないか確認してください。チャット画面を閉じる操作を、連携先まで含む停止手段とみなさず、実際に何が止まるかを試します。

必要に応じて、AI側の実行停止に加え、連携用のアクセス権限を外すなど、接続先での操作も行えるようにします。

ただし、権限を外せば、すでに完了した送信や削除まで取り消せるという意味ではありません。停止後には、何が実行済みなのかを記録から確認し、訂正連絡や復元などの対応を判断します。

停止する権限を誰が持ち、その担当者が不在の場合は誰が代行するかも決めてください。

安全確認が終わるまで自動的に再開しないこと、再開の判断者と条件を定めることまでを、一つの手順にします。

「AI業務委任表」で、任せる条件を一枚にまとめる

ここまでの内容を、業務ごとの管理表にまとめましょう。

次は、「公開済みFAQを参照し、問い合わせへの回答案を作る」という業務の記入例です。導入初期は送信まで任せず、限定した下書き作成から始める想定です。

管理項目記入例
任せる業務公開済みFAQをもとに、問い合わせへの回答案を作成する
参照できる情報指定したFAQと、担当者が利用可否を確認して渡した問い合わせ文
実行できる操作指定資料の参照と、専用の確認用フォルダーへの下書き保存
任せない操作メール送信、顧客情報の更新、共有範囲の変更、ファイル削除
人が判断する事項回答の正確性、個別条件への対応、宛先、添付、実際の送信
対象外の依頼FAQで確認できない契約条件の変更や、個別の返金判断など
処理の上限試行で確認した件数と実行時間を別途設定。超過時は保留する
結果の確認参照資料、作成した下書き、担当者による確認結果を記録する
異常時の対応作成を停止し、運用担当者へ連絡。必要に応じて連携を解除する
管理責任者業務の範囲を決める責任者と、設定・停止を担当する管理者を記載する
見直す時期参照資料、モデル、連携機能、権限、対象業務を変更するとき

この表は、実際の設定と一致している必要があります。

表に「送信不可」と書いていても、AIが送信機能を使える状態なら、どの仕組みで止めているかを確認してください。

また、送信まで任せる段階へ進む場合は、表を書き換えるだけでなく、承認の仕組み、結果確認、二重送信防止、緊急停止を追加して試験します。

業務委任表は、AIに読ませる指示文である前に、人が設定と運用を確認するための管理資料です。

試験では、「できること」だけでなく「止まること」を確認する

導入前の試験で、期待した返信案が一度できたことだけを確認していないでしょうか。

本記事では、正常な処理に加え、認めていない操作を止められるかも確認することを提案します。

次の表は、試験項目の例です。実際のお客様へ送信したり、本番の資料を削除したりしない検証環境で行ってください。

試験する状況確認したい結果
許可した資料を使って回答案を作る指定の保存先に下書きが作られ、参照資料を確認できる
外部資料に、権限や処理方法を変える指示が含まれる会社が定めた操作範囲を越えず、重要操作には正規の承認が必要となる
承認後に宛先や添付を変更する元の承認では実行できず、再確認になる
承認者が不在、または承認の確認に失敗する自動承認せず、保留と連絡を行う
送信結果を受け取れず、成功・失敗が不明になる無条件に再送せず、記録確認または重複防止の仕組みへ進む
件数や実行時間の上限へ達する追加処理を止め、超過を担当者へ知らせる
緊急停止を実施する新規・待機中・連携先の処理を確認でき、勝手に再開しない

一つの試験でうまく止まったことを、あらゆる入力への安全保証と考えないことも重要です。

NCSCは、AIへの指示だけに依存せず、技術的・運用上の対策を組み合わせる必要性を示しています。試験は、その組合せが意図どおりに働くかを確認するために行います。

試験結果には、利用した構成と設定、実施した入力、確認できた結果、残る問題を記録します。

問題が見つかった場合は、指示文を修正するだけで済ませず、権限が広すぎないか、承認確認を回避できないか、結果不明時の手順が欠けていないかを調べてください。

自動化の範囲を広げる前に、人の確認と停止が機能しているかを見る

試行で一定の成果が出ても、すぐにすべての業務へ広げる必要はありません。

本記事では、下書き作成の品質だけでなく、人が確認する時間、修正にかかった作業、例外の件数、処理結果を追える割合などを確認してから、次の範囲を検討することを提案します。

例えば、下書きの作成時間が短くなっていても、参照資料の確認や修正に多くの時間がかかっているなら、その理由を調べます。参照資料が整理されていないのか、対象に個別判断の多い問い合わせを含めすぎているのかによって、改善方法は変わります。

モデルや連携機能を変更する場合も、以前の試験結果だけで判断せず、承認と権限制限が維持されているかを再確認してください。

提供者や構築会社へ確認する際は、「安全対策はありますか」ではなく、「承認していないメール送信を、どの部分で拒否しますか」「結果不明の処理をどう扱いますか」と、実際の動作を質問すると整理しやすくなります。

必要な制御を確認できない操作は、下書きや候補提示までにとどめる判断もあります。

自動化率を上げることより、確認できる範囲で業務を安定させることを優先しましょう。

まとめ――AIの判断だけに、実行の許可まで任せない

AIエージェントへ仕事を任せる際は、「便利そうだから接続する」という順番ではなく、どこまで任せるかを先に決めてください。

参照する情報を限定し、下書きと実行を分ける。影響の大きい操作は、対象と内容を人が確認する。承認後に内容が変われば、改めて確認する。実行後は、AIの説明だけでなく、接続先の記録で結果を確かめる。

さらに、結果が分からない場合の扱い、処理量の上限、緊急停止と再開の条件を整えます。

最初の一歩は、自社で任せたい業務を一つ選び、「AI業務委任表」を作ることです。送信や削除まで任せなくても、調査、整理、下書きの作成から始められます。

「AIに何ができるか」だけでなく、「自社は何を認め、その実行をどう確認するか」。

この二つをそろえることが、AIを業務へ組み込む際の基本になります。

ライトハウスコンサルタントでは、クラウドやアカウント、社内ルールの現状確認と、対策の優先順位の整理を支援しています。AIに任せる業務の範囲や、社内で使える承認・確認手順を整理したい場合は、ご相談ください。

投稿タグ
, , , , , , , , , , , ,