AIに操作まで任せる前に、人が承認する場所を決める手順：取り消せない操作の手前に1つだけ置く(2026)

操作そのものをAIに任せる設定が、業務向けのサービスに現れています。Microsoft Copilot Studio がエージェントに追加できるツールの一覧には「コンピューター操作」があり、「エージェントは、Web サイトやデスクトップ アプリ、ボタンの選択、メニューの選択、画面上のフィールドへのテキスト入力など、グラフィカル ユーザー インターフェイスを備えた任意のシステムと対話できます。」と説明されています。中小〜中堅企業の情シス・業務部門のリーダーに向けて、どこまで自動で走らせてよいか分からない、という理由で止まっている状態のほどき方をまとめます。

文書のひな形が要るときは生成AIの社内利用ルールを作る手順、出力が正しいかを確かめたいときはAIの答えを業務で使う前の検証手順が別にあります。この記事は送信・削除・更新のボタンが押される直前だけを扱います。

最終更新: 2026年9月24日／各社の公式ページは同日に原文を確認。「(編集部)」はjisalab編集部の判断で、出典の記載ではありません。

任せてよいかは、賢さではなく「取り消せるか」で決める

AIエージェントの検討が止まるとき、引っかかっているのはAIの賢さよりも、失敗したときに何が起きるか分からないことのほうです。そして失敗の重さは、AIの性能ではなく操作の性質で決まります。読み取りを100回間違えても読み直せますが、外部への送信は1回で終わります。

この区分は素直に見えて、自分の挙げた例を当て直すと必ずズレが出ます。実際に3つ当ててみます。

• メールの送信。Gmailには送信取り消しがあり、ヘルプは「[ 送信取り消し ] の横で、送信を取り消せる時間（送信からの経過時間）を 5、10、20、30 秒から選択します。」としています。上限は30秒で、しかも取り消しボタンを押すのは画面を見ている人です。AIが送った瞬間に誰も画面を見ていなければ、この30秒は使えません。だから取り消せない側に置きます(編集部)。
• ドライブのファイル削除。Google ドライブのヘルプは「ゴミ箱に移動したファイルは、30 日後に完全に削除されます。」としており、取り消せる側です。ただし期限つきで、30日を過ぎれば戻せません。なお同じページは「自分がファイルのオーナーでない場合は、ファイルを削除できません。できるのは、ドライブから削除することのみです。」ともしており、他人のファイルでは操作そのものが変わります。
• 権限の付与・共有範囲の変更。取り消せない側です。設定を元に戻すことはできても、その間に見られたという事実は戻せません。

つまり取り消しに使える時間と、その時間に人がいるかどうかまで見ないと、どちら側かは決まりません。

人が承認する場所を決める4つの手順

手順① 任せる予定の操作を書き出し、2つに分ける

まず、任せる予定の動きを動詞で書き出します。請求書処理を任せる、という粒度ではなく、PDFを読む、表に転記する、担当者にメールで送る、基幹システムに登録する、のように分解します。分解しないと、取り消せる作業と取り消せない作業がひとかたまりのまま残ります。

書き出したら、1行ずつ次の質問に答えます。失敗したとき、同じ画面から自分で元に戻せますか。 戻せるなら取り消せる側、戻せない・時間制限がある・社外の相手に届くなら取り消せない側です。判断が割れた行は、取り消せない側に寄せます。最初の設計で止めすぎておくほうが、あとから緩めるのは簡単です。

手順② 使う製品が何を確認してくるかを設定画面で確かめる

次に、使う製品に確認を出す仕組みがあるか、その既定値はどうかを見ます。想像せず、公式ページと自社の管理画面の両方を開いてください。

出典: Microsoft Learn「カスタム エージェントにツールを追加する」「Power Automate の承認を始めましょう」「Microsoft 365 管理センターでエージェントを管理する」。いずれも2026年9月24日に原文を確認。この表は3製品で確認できた範囲です(Anthropic の Claude Code は手順③で引用)。ここに出ていない製品の既定値は、同じとは限りません。

この表で一番効くのは、確認を出す仕組みがある＝既定で確認が出る、ではないという点です。Copilot Studio の項目は既定が［いいえ］、Power Automate の承認は自分で置いて初めて挟まります。実行時に止まるのか導入時に止まるのかも別の層で、両方を見ないと片方が素通りします。

確認が誰に出るかも層で変わります。Copilot Studio の確認が出るのはチャットの利用者本人で、このあとの承認者を2人以上にという話はこの確認のことではありません(編集部)。導入時のほうは管理者ですが、表のとおり送信と承認のプロセスが書かれているのはストアから追加するエージェントについてです。現場が作って共有したエージェントを事前の承認で止められるかは、原文と自社の管理センターで確かめてください。

手順③ 取り消せない側にだけ承認を置き、プロンプトに頼らない

手順①で分けた取り消せない側の行を、手順②で見つけた設定に割り当てます。このとき一番やりがちなのが、プロンプトに メールを送る前に必ず私に確認して と書いて済ませてしまうことです。これは承認を置いたことになりません。

この点をはっきり書いている公式ドキュメントがあります。Anthropic の Claude Code(開発者がコマンドラインから使うAIツール)の権限ページです。業務部門が直接使うものではありませんが、承認の設計としては同じ話です。「Permission rules are enforced by Claude Code, not by the model. Instructions in your prompt or CLAUDE.md shape what Claude tries to do, but they don’t change what Claude Code allows.」——権限のルールを強制するのはモデルではなくツール側で、プロンプトや設定ファイルの指示はツールが何を許すかを変えない、という趣旨です(編集部訳)。承認は、お願いではなく設定に置きます。

置き方の順番も同じページが参考になります。ルールを allow・ask・deny の3種に分け、「Rules are evaluated in order: deny, then ask, then allow.」「An allow rule can’t carve an exception out of a deny rule.」——評価は deny→ask→allow の順で、allow で deny に例外は作れない、としています(編集部訳)。つまり止める指定が勝つ設計です。自社でも、まず禁止する操作、次に確認を挟む操作、残りを自動、という順に決めると迷いません。

承認の当て先も決めます。Power Automate の承認者は Outlook のメールと Microsoft Teams のアダプティブ カードから応答でき、Power Automate のアクションから直接応答できるのは「彼らが Power Automate ライセンスや Office 365、または Power Automate に内蔵されている Dynamics 365 ライセンスの各種機能を持っている場合」だと説明されています。承認者を増やすときは、その人がどの経路で応答できるかまで確かめてください。同ページには、全員の応答を待つ型、誰か1人の応答で進む型、順次承認といった型があり、どれを選ぶかで止まり方が変わります。

既存の業務自動化ツールにAIを足す形でも設計は同じです。料金や課金単位から選びたい場合はMake・n8n・Zapier比較：料金・課金単位・日本語対応で選ぶ業務自動化を先にご覧ください。

手順④ 管理者側で渡す範囲そのものを絞る

手順③までは、AIを作る人・使う人の側の設計です。最後に管理者側で、そもそも権限を渡さない線を引きます。承認画面を出すより確実だからです。

Google Workspace では、管理コンソールの［セキュリティ］→［アクセスとデータ管理］→［API の制御］で設定します。ここは2階建てで、探す場所が別です。

• アプリ側：［アプリのアクセスを管理］で、アプリごとに「信頼できる」「限定」「特定の Google データ」「ブロック中」のいずれかを設定します。
• サービス側：［Google サービスを管理］でサービスを選び、［アクセス権を変更］から「制限なし」か「制限付き」を選びます。

効くのは2つの組み合わせです。同ヘルプは「制限付き – [信頼できる] または [特定の Google データ] のデータアクセスが設定されている社内用アプリとサードパーティ製アプリのみがデータにアクセスできます。」とし、変更すると「インストール済みアプリのうち信頼していないアプリが動作しなくなり、トークンが取り消されます。」としています。［制限付き］はサービス側の設定なので、アプリの詳細画面ではなく［Google サービスを管理］から開きます。

さらに細かい指定もあります。同ヘルプは「注 : Gmail、Google ドライブ、Google Chat では、リスクの高いサービス（メールの送信やドライブでのファイルの削除など）へのアクセスを詳細に制限できます。」とし、別の節では対象に Google ドキュメントも加えて「事前定義されたリスクの高い OAuth スコープのリストへのアクセスを制限することもできます。」としています。2文で挙がるサービスはそろっていないので、自社で使うものは画面で確かめてください。

ここで1つ注意があります。その「リスクの高い OAuth スコープ」の一覧には、gmail.readonly や drive.readonly といった読み取り専用のスコープも含まれています。この記事の区分でいえば読み取りは取り消せる側ですが、Googleの一覧はそう分けていません。使い分けはこうです。承認を置く位置は編集部の区分で決め、管理者側で渡す範囲を絞るときはGoogleの一覧を正として使ってください。2つは用途の違う道具です。読み取られたという事実は、あとから取り消せません。

Microsoft 側では、Power Platform のデータ ポリシーで管理者がコネクタ全体や特定のアクションへのアクセスを制限できます。同ページは、違反したリソースを「中断 状態または 検疫 状態にして、操作できないようにします。」と説明しています。

効き始めるまでの時間は、2種類を混ぜないことが大事です。Power Platform のデータ ポリシーについて同ページは「最も極端なケースでは、完全な施行までの待ち時間は 24 時間です。 ほとんどの場合、1 時間以内です。」としています。これは施行そのものの遅れです。一方 Google 側は、［制限付き］への変更でトークンが取り消されるとしたうえで「注 : アクセスしたアプリの一覧は、トークンが付与または取り消されてから 48 時間後に更新されます。」としています。こちらは一覧の表示が追いつく時間で、設定が効くまでの時間として書かれたものではありません。運用開始日に足すのは前者、当日の画面では確認しきれないと見込むのが後者です。

次に取る行動

よくある質問