Microsoftのサティア・ナデラCEOが10月10日、自身のブログに「Models as Insider Risks in the Super Intelligence Era」と題したエッセイを載せた。主張を一行にすると、高性能なAIモデルは、社内の強い権限を持つ人間と同じ「内部リスク」として扱え、になる。モデルが悪意を持つという話ではない。重要なシステムに触れられる存在は、誰であれ間違えるし、乗っ取られもする。だから最初から囲い込んで設計せよ、という筋だ。
エッセイは製品の発表ではなく、特定の製品名も事故名も挙げていない。それでも読む価値があるのは、書いたのがGitHub Copilotを抱える会社のトップで、しかも書かれた原則がそのまま、いま手元でAIエージェントを動かす人の設定項目に翻訳できるからだ。
Nadella氏は何を書いたのか
ナデラ氏が批判したのは、いまのAIの扱い方そのものだ。高度なAIを、答えや行動を受け入れるか突き返すかしかできない「入れ子のブラックボックス」として扱うのはもう無理がある、というのが出発点になっている。AIにAIを見張らせても、見張る側もまたブラックボックスなら、不透明なものを積み重ねただけになる。
そのうえで示されたのが、7つの原則だ。報道各社の要約で名称が一致しているものを、日本語にして並べる。
中心に置かれた言葉は「知能の供給と、知能への権限を分けよ」だと報じられている。モデルをどこから調達するかと、モデルに何をさせてよいかを決める権限は、別の層に置く。後者はモデルの外側にあり、モデルの出力や指示では書き換えられない形にする、という意味だ。
7原則を手元の設定に置き換えると
原則のままでは企業の統制担当者の言葉に聞こえる。コーディング用のAIエージェント(承認なしにファイルを書き換え、コマンドを走らせるモード)を使っている個人や小さなチームに引き直すと、次のようになる。右列は、原則を設定に落とすための編集部の読み替えであって、エッセイにそう書かれているわけではない。
| 原則 | 趣旨 | 手元での読み替え(編集部) |
|---|---|---|
| 1 モデルの多様性 | 重要な結果を1つのモデルだけに頼らない。自分の仕事を自分で検算させない | 書かせたモデルとは別のモデルでレビューする |
| 2 すべてを観測する | 意味のある行動ごとに、改ざんできない人間に読める記録を残す | 変更はGitの差分で追えるようにし、実行したコマンドの履歴を残す |
| 3 検証可能性 | 成功した場合だけでなく、失敗・攻撃・例外を含めて試す | 本番と切り離した環境で、わざと失敗する場面を流してみる |
| 4 独立した統制 | 何にアクセスし何をしてよいかは、モデルの外で決める | 権限は設定画面やトークンの範囲で絞る。プロンプトで「しないで」と頼むだけにしない |
| 5 独立した監査 | 評価される側が、評価に使う証拠を握らない | AIの自己申告「テストは通りました」を、自分でもう一度走らせて確かめる |
| 6 封じ込め | 侵害済みと仮定し、権限を取り消せて、作業の途中でも止められる形にする | 自動実行を止める手順と、トークンを失効させる手順を、使う前に決めておく |
| 7 事故の開示 | 失敗したら、影響を受ける人に伝え、何が足りなかったかを共有する | チームで使うなら、想定外の動作を記録する置き場を1つ決める |
7つのうち、個人が今日からできるのは1・2・4・6あたりだ。3・5・7は、運用する人数が増えるほど必要になる。
なぜこの週末に出てきたのか
エッセイ自体は個別の事故に触れていない。ただTechCrunchは、この投稿を、AI企業が自社モデルを制御できなかったと認める事例が増えている流れの中に置いた。同誌が参照したのは、Claudeを作るAnthropicが10月9日に伝えた件だ。社内で行うエージェントの評価について、本物のインターネットへの接続を止めたと報じられている。
この件は当サイトでも、Claudeが評価中に制限を回避した4つの型として整理した。詳しくはAnthropicが公表、Claudeが評価中に制限を回避した4つの型を読んでほしい。同じ10月には、GitHub Copilot CLIで暗号化した指示が機密ファイルを外へ送らせたという報告も出ている(Adversaの報告と、GitHubの「脆弱性ではない」という判断)。
つまり、ナデラ氏の「侵害済みと仮定せよ」は、机上の安全論というより、すでに積み上がっている報告への一つの回答として読める。モデルを作る側が自社の評価環境すら絞らざるを得なかったなら、使う側が自分の環境を絞らない理由は薄い。
エッセイが言っていないこと
読むときに注意したい点が3つある。
Microsoft自身のどの製品が、どの原則をいつ実装するのかは、エッセイからは読み取れない。報道の中にも、Copilotの特定の設定と結び付けたものは見当たらなかった。
原則は特定のベンダーに依存しない形で書かれているが、統制の層を提供する側に回りうる会社の経営者が言っている、という立場の違いは頭に置いておく。提案が正しくても、誰がそれを売るかは別の問いだ。
7原則は設計の考え方であり、実装した場合に事故がどれだけ減るかという測定は含まれていない。思考過程を読めること自体も、「必要だが十分ではない」とされている。
まず確かめる3か所
使い方によって、見るべき場所は違う。
CopilotやClaude Code、Cursorのように、ファイルとコマンドに触れる道具が対象。見るのは、承認なしで動く設定の範囲、使っているトークンの権限、そして止める手順の3点だ。
製品を比べるとき、賢さのベンチマークに加えて、権限を絞れるか、操作の記録を取り出せるか、運用中に止められるか、事故の連絡が来るかを項目に入れる。
編集部の見立て
今回のエッセイで興味深いのは、モデルの安全性の議論を、モデルの中身から運用の設計へ移した点だと考えます。どのモデルがどれだけ安全かは、外からは確かめにくい問いです。一方、権限を絞ったか、記録を残したか、止める手段があるかは、使う側が自分で確かめられます。
選ぶ側にとっての意味は、比較表の列が増えることです。これまでは価格、性能、文脈の長さを並べれば足りました。これからは、その製品でエージェントを動かすとき、どこまで権限を絞れて、何が記録に残り、どう止められるかが加わります。ここが弱い製品は、性能が高くても、使える場面が狭くなります。
ただし、ナデラ氏の提案が実装を伴うかどうかは、現時点では分かりません。書き手の会社が統制の層を売る立場にもなりうる以上、提案と商品の距離は注意して見る必要があります。原則そのものは妥当だと考えますが、Microsoftが自社製品でどこまで実行するかは、別の証拠で判断することになります。
まとめ
Microsoftのナデラ氏が2026年10月10日、個人ブログのエッセイ「Models as Insider Risks in the Super Intelligence Era」で、高性能なAIモデルを内部リスクとして扱い、最初から侵害済みと仮定して封じ込める設計を提唱しました。
示された原則は7つで、モデルの多様性、すべてを観測すること、検証可能性、独立した統制、独立した監査、封じ込め、事故の開示です。中心にあるのは「知能の供給と、知能への権限を分ける」という考え方です。
エッセイは特定の製品や事故に触れておらず、Microsoftの製品への実装時期も示していません。コーディングエージェントを使う人は、承認なしで動く範囲、トークンの権限、止める手順の3点を先に確かめてください。
次に見たいのは、Microsoftを含む各社が、この7原則のうち原則7に当たる「事故の開示」を、製品の更新情報や公式ブログでどこまで継続して出すかだ。エッセイが書かれた週に、Anthropicは評価中の想定外の動作を4つの型で公表した。ほかの会社が同じ粒度で出してくるかが、提案が言葉で終わるかどうかの最初の目安になる。