MicrosoftのCEO、Satya Nadella氏は2026年10月10日、AIモデルが侵害される可能性を前提に設計し、必要に応じて人間が作業途中でも停止できる仕組みを備えるべきだとXに投稿した。The Vergeが同日に報じた内容によると、Nadella氏はAIに「緊急ブレーキ」が必要だと訴えている。AIエージェントが機密情報にアクセスし、外部サービスを操作する機会が増えるほど、不正な指示や誤判断による被害を防ぐ仕組みも重要になる。Microsoftがこれまで公開してきたセキュリティ指針と照らし合わせると、この「緊急ブレーキ」を実効性のあるものにするには、AIの動作を停止するだけでなく、接続先のシステムで使用する権限も確実に取り消せる設計が求められる。

AD

AIは「侵害されることを前提に設計すべき」とSatya Nadella CEOが提言

Nadella氏が求めたのは、AIモデルが外部から侵害された場合でも、被害の拡大を防げるようにすることだ。The Vergeが紹介したXへの投稿では、AIの安全対策について次のように述べている。

権限を持つ人は、モデルが作業の途中であっても、いつでも一時停止または停止できるべきだ。

なお、原投稿の全文は直接確認できておらず、この発言はThe Vergeが掲載した引用に基づいている。また、Nadella氏の発言は、すべてのAIモデルがすでに侵害されているという被害報告ではない。外部から不正な影響を受ける可能性をあらかじめ想定し、実際に問題が発生しても被害を最小限に抑えられるようにするという、セキュリティ設計上の考え方だ。

この方針は、Microsoftが以前から推進してきた「ゼロトラスト」の原則とも一致している。

Microsoftは2026年3月19日に公開した公式記事で、従来のゼロトラストの考え方をAIシステムにも適用する「Zero Trust for AI」を発表した。その基本原則は、アクセスする主体を明示的に検証すること、必要最小限の権限だけを与えること、そして侵害が起こり得ることを前提に対策を講じることだ。

最小権限の原則では、AIエージェントに対して、目的の作業を実行するために必要なデータや操作だけを許可する。例えば、文書の要約を担当するAIに、その文書を外部へ送信したり削除したりする権限まで与える必要があるのかを検討する。

AIが適切な回答を生成できることと、そのAIにどこまで操作を許可してよいかは別の問題だ。接続できるツールやサービスが増えるほど、AIの判断が実際のシステム操作につながる機会も増え、不正な指示による被害が広がる可能性がある。

こうしたリスクについて、Microsoftは自律型AIエージェント向けのセキュリティ指針でも具体的に説明している。同指針では、AIモデルがどのような出力を生成しても、許可されていない操作をシステム側の明確なルールで阻止できるようにすべきだとしている。

AIに「危険な操作をしないように」と指示するだけでは、十分な安全対策にはならない。AIが不適切な操作を要求したとしても、接続先のシステムがその要求を拒否できることが重要になる。

AIの「緊急停止」を実現するには、アクセス権限の無効化が不可欠

Nadella氏が提唱する緊急停止の仕組みについて、Microsoftはすでに具体的な実装方針を示している。

同社が2026年7月16日に公開した最小権限に関する指針では、AIエージェントの導入から運用、廃止までを適切に管理し、必要な場合には資格情報や認証トークンを確実に無効化できる仕組みを組み込むよう推奨している。

資格情報や認証トークンは、AIエージェントが外部のサービスにアクセスする際、自身の身元や操作権限を証明するために使用するものだ。これらが有効なままであれば、AIの処理を停止しても、接続先のシステムで使える権限が残る可能性がある。

そのため、実効性のある緊急停止を実現するには、AIの処理を中断する機能だけでなく、アクセス権限の取り消しや、実際に行われた操作を追跡する仕組みも必要になる。

Microsoftが7月に公開した指針と、Microsoft Learnの推奨事項を基に、AIエージェントの運用に必要な対策を整理すると、次のようになる。

段階 Microsoftが推奨する対策 確認すべき内容
実行前 エージェントごとに専用のIDと責任者を設定し、必要最小限の権限を付与する。リスクの高い操作には承認を必要とする 誰の権限で、どこまで操作できるか
実行中 使用できるツールを制限し、接続先でも呼び出しのたびに権限と操作対象を確認する AIの操作が許可された範囲を超えていないか
停止時 システム側からAIを一時停止・停止できるようにし、資格情報や認証トークンを無効化する 停止後も操作可能な権限が残っていないか
検証・復旧時 エージェントのID、使用した権限、実行した操作を記録し、複数システムにまたがる処理を追跡できるようにする どの権限で何が実行され、どのデータが変更されたか

これらはMicrosoftが推奨するセキュリティ対策を整理したものであり、特定の製品にすべて実装されていることや、導入すれば事故を完全に防げることを示すものではない。

重要なのは、AIを停止できる仕組みを用意するだけでなく、どのAIが何を実行しているのかを正確に把握できるようにすることだ。

例えば、エージェントごとに専用のIDが割り当てられ、利用できるツールや操作権限が明確に管理されていれば、問題が発生した際に対象のエージェントだけを停止し、その権限を取り消しやすくなる。

反対に、複数のエージェントが同じ認証情報を共有している場合、どのエージェントが操作したのかを特定しにくくなる。また、1つのエージェントだけを停止しようとしても、認証情報を共有するほかのエージェントに影響が及ぶ可能性がある。

Microsoftの7月の指針でも、複数のエージェントによる認証情報の共有は、操作の責任を追跡しにくくするだけでなく、権限の取り消しを遅らせ、不完全なものにする恐れがあると指摘している。

さらに、AIエージェントを管理するシステム側で権限を確認したからといって、実際に操作を受け付ける外部サービスが無条件にその要求を信用してよいわけではない。

Microsoftは、接続先のツールやサービスでも、呼び出しのたびに認証情報、役割、アクセス可能な範囲を再確認するよう求めている。

つまり、AIの動作を管理する画面に停止ボタンを設置するだけでなく、実際にデータを読み書きするサービス側でも、許可されていない操作を確実に拒否できるようにする必要がある。

AD

AIを停止しても、実行済みの操作が元に戻るわけではない

もう一つ重要なのは、AIの動作を停止することと、すでに実行された操作を取り消すことは異なるという点だ。

例えば、AIエージェントが誤って大量のチケットを作成したり、データベースに意図しない変更を加えたりした場合、エージェントを停止しても、それまでに作成されたデータや変更内容が自動的に元へ戻るわけではない。

Microsoftは7月のセキュリティ指針で、アクセス権限を取り消す手順とともに、問題発生後の復旧方法についても、通常の機能と同じように事前テストを行うよう推奨している。

同社が挙げている例には、誤ったチケットの大量作成、意図しないデータの書き込み、データの外部送信などがある。こうした操作が実行された場合を想定し、何を停止できるのか、どの変更を元に戻せるのかを事前に確認しておく必要がある。

そのため、緊急停止だけに頼るのではなく、取り消しの難しい操作については、実行前に人間が承認する仕組みを組み合わせることが重要になる。

Microsoft Learnの指針でも、リスクが高い操作や取り消しが困難な操作には、人間による承認を必要とするよう推奨している。

例えば、AIが必要な情報を収集・分析する段階までは自動で進め、データの削除や外部への送信、設定変更などを確定する段階で人間が確認する仕組みが考えられる。ただし、どこに承認を挟むべきかは、操作の影響の大きさや、問題が起きた場合に元へ戻せるかどうかによって判断する必要がある。

また、特定の作業を実行するため、一時的にAIへ高い権限を与える場合も注意が必要だ。

Microsoftは、エージェントのIDを作業のたびに作り直すのではなく、必要な役割や操作権限を一時的に有効化し、作業完了後に元の最小権限へ戻す仕組みを推奨している。

これにより、普段は読み取り専用で動作するAIに、必要な場合だけ書き込み権限を与えるといった運用が可能になる。ただし、担当する業務が変わった場合には、以前に与えた権限が引き続き適切かどうかも見直す必要がある。

例えば、文書を読むだけだったAIに修正作業まで任せるようになれば、必要な権限も、想定すべきリスクも変わるためだ。

AIの操作履歴を追跡できなければ、事故の原因も調べられない

AIエージェントの安全な運用には、実行した操作を正確に記録する仕組みも欠かせない。

AIが最終的に生成した回答だけを保存していても、途中でどのサービスにアクセスし、何を読み書きしたのかまでは分からない場合がある。

Microsoftは7月の指針で、エージェントのIDや使用した権限、アクセス先、実行した操作、時刻などを記録するよう求めている。さらに、複数のサービスにまたがる一連の処理を関連付けるため、相関IDを利用することも推奨している。

こうした記録があれば、問題が発生した際に、どのエージェントが、誰の権限で、どのデータに変更を加えたのかを追跡しやすくなる。

重要なのは、AIが「何をした」と説明した内容と、実際にシステム上で行われた操作を区別することだ。

例えば、AIが「ファイルを確認しただけ」と回答していても、実際には外部サービスへの送信処理が実行されていた可能性がある。最終回答だけではその違いを確認できないため、接続先で実行された操作を独立して追跡できる記録が必要になる。

一方、こうしたセキュリティ対策には追加の開発費用や運用負担が発生する。

Microsoft Learnの指針でも、厳格なルールによる制御や監視、操作履歴の記録には追加の設計と開発が必要になると説明している。また、人間による承認や確認の工程を増やすことで、作業の流れが中断され、自動化の利便性が低下する可能性も認めている。

そのため、すべての操作を人間が確認するのではなく、影響の大きい操作に重点を置いて承認を求め、それ以外の処理は適切な権限制限の下で自動化するといった使い分けが必要になる。

Nadella氏が提唱したAIの「緊急ブレーキ」を実用的な仕組みにするには、停止ボタンを設けるだけでは不十分だ。人間が停止を指示した際、どの処理が中断され、どのアクセス権限が無効化されるのか、さらに実行済みの操作をどこまで追跡・復旧できるのかを確認する必要がある。

AIエージェントが複数のシステムを横断して業務を実行する時代には、AIが正しい判断をすることを期待するだけでなく、誤った判断をしても被害を抑えられる仕組みが重要になる。

こうした安全対策を実際の運用環境で検証できてこそ、企業はAIにどこまで業務を任せられるのかを、具体的なリスクに基づいて判断できるようになる。