社内AIエージェントの管理は、最初に何を許可するかだけでなく、作業中にどこで止めるかも重要です。
2026年10月19日、MicrosoftはAIエージェントを社内の新しい業務主体として捉え、動作中のリスクに応じてアクセスを調整する考え方を示しました。
ポイントは、導入時に与えた権限を固定したまま任せず、作業の状況を見ながら許可を見直すことです。新たに説明された仕組みを整理し、社内でエージェントを使う際に、誰が何を判断する必要があるかを具体例で考えます。
この記事でわかること
- 発表の要点：動的な権限・リスク・アクセス制御の役割
- 業務の判断：読み取り、書き込み、外部送信を分ける例
- 導入の準備：承認する人と、停止後の再開条件を決める
Microsoftが示した3つの動的な制御
Microsoftは、必要な作業に合わせて権限を絞る「Dynamic Permissions」、複数の兆候からリスクを評価する「Dynamic Agent Risk」、評価に応じてアクセスを調整する「Dynamic Conditional Access」を説明しています。
制御の考え方は、作業を全面的に許可するか停止するかの二択に限りません。読み取りを残して書き込みを制限するなど、行動に応じた調整も示されています。AI自身の判断だけを安全確認の最終根拠にしない点も重要です。
今回の発表を「設定画面の手順」と混同しない
この記事は、新しく示された管理の考え方を読み解くものです。すべての機能がどの契約でも直ちに利用できるという案内ではありません。導入する場合は、自社の契約、提供状況、対応するエージェントを個別に確認してください。
接続するツールの統制を先に整理したい場合は、Agent 365とMCP接続の管理を扱った記事も参考になります。接続先の管理と、動作中の判断を分けて読むと理解しやすくなります。
問い合わせ対応のAIなら、どこで判断を分ける？
以下は製品の実測結果や設定例ではなく、編集部が考えた業務設計の例です。社内FAQを読んで回答案を作るエージェントを想定します。最初の依頼は「問い合わせへの回答案を作る」ですが、途中で顧客情報の更新やメール送信が必要になった場合は、同じ仕事の延長として自動的に認めてよいでしょうか。
成果物が同じでも、途中の操作は分けて扱う
| 求められた操作 | 業務側で決める範囲 | 確認するポイント |
|---|---|---|
| 許可済みFAQを読む | 指定された情報源の範囲で進める | 参照先が依頼に関係するか |
| 回答案を下書きにする | 確認用の保存先に限定する | 根拠と未確認事項が残っているか |
| 顧客情報を書き換える | 担当者の確認を挟む | 変更対象、変更理由、戻し方が明確か |
| 顧客へ送信する | 宛先と内容の承認を別に設ける | 社内情報や別の顧客情報が混ざっていないか |
| 依頼と関係のない資料へアクセスする | 該当操作を止め、理由を確認する | 参照が必要になった経緯を説明できるか |
この表の狙いは、あらゆる操作に人の確認を増やすことではありません。任せる作業と、人が判断する境界を先に決めることです。回答案を作る許可と、顧客データを更新する許可を一緒にしないだけでも、担当者が検討すべき点を整理できます。
監視を導入する前に、社内で決めたい3つのこと
1. 何を達成したら作業終了なのか
「問い合わせ対応を任せる」では、回答案までなのか、送信までなのかが曖昧です。「指定FAQを使った回答案を作り、担当者が読める場所へ保存する」までと決めれば、作業に必要な操作を挙げやすくなります。完了条件は、AIが終了と返答したかではなく、成果物と実施した操作で確認します。
2. 誰が例外を承認するのか
確認を求められたとき、業務担当者と管理者のどちらが判断するのかを決めます。内容の正しさを判断できる人と、システムのアクセス権を変えられる人が同じとは限りません。承認画面に何が表示されるかだけでなく、承認する側が変更対象と影響を理解できる運用が必要です。
3. 止めたあと、何を確認して再開するのか
停止できても、理由を確認せず同じ依頼を再実行すれば、問題の切り分けは進みません。参照した情報、止まった操作、既に変更されたものの有無を確認し、依頼内容を狭めるのか、情報源を修正するのかを判断します。途中まで進んだ作業がある場合は、二重送信や重複更新が起きないかも確認します。
運用開始前の打ち合わせでは、正常なケースだけでなく「別の資料を求めた」「書き込みが増えた」「担当者が不在だった」という例を机上で通してみると、判断の抜けを見つけやすくなります。これは社内の準備例であり、Microsoft製品での操作検証を示すものではありません。
実務上の注意
新しい制御の名称だけで導入を決めず、自社で使うエージェントと業務範囲に対応しているかを確認します。機能の提供時期や契約条件を確認できるまでは、それを前提に既存の承認手順を外さないでください。
検討用の例に実在の顧客情報を使う必要はありません。まずは架空の問い合わせと許可した資料で、誰が何を判断するかを整理できます。
まとめ
Microsoftの発表は、AIエージェントの管理を導入時の許可だけで終わらせず、動作中の状況に合わせて考えるものです。業務側でも、読み取り・更新・送信の境界、例外の承認者、停止後の再開条件を整理すると、必要な管理機能を選びやすくなります。
よくある質問
AIに「勝手に変更しないで」と書けば十分ですか？
依頼文を明確にすることは大切ですが、業務設計ではそれだけに依存せず、操作できる範囲や人が承認する境界も検討します。
すべての操作を人が確認する必要がありますか？
一律に決める必要はありません。扱う情報、変更の影響、取り消しやすさに応じて、通常の処理と例外の判断を分ける考え方があります。
発表された機能をすぐに設定できますか？
自社契約での提供状況や対応対象の確認が必要です。本記事では管理画面の設定手順や利用可否を実機確認したとはしていません。
出典・参考情報
運営元について
AXメディアは、株式会社ジーズ AX事業部が運営しています。AX事業部では、AI研修・AIエージェント開発・ローカルLLM開発・補助金／助成金の活用支援を提供しています。
