Claude Codeを使っていると、ファイルの書き込みやコマンド実行のたびに「許可しますか」という確認ダイアログが出る。多くの人は、深く考えずに承認を押しているはずだ。実はこの「確認疲れ」は、Anthropic自身が社内データで観測し、公式のエンジニアリングブログで正面から取り上げている話でもある。Claude Code・Claude Cowork・claude.aiという3つの製品をどう「封じ込めて」きたかを詳しく説明した記事（2026年5月25日公開）の内容を、中小企業の権限設計に引き寄せて整理する。

確認ダイアログは思ったより機能しない

Anthropicの計測によると、ユーザーは確認ダイアログのおよそ93%を承認していたという。しかも表示される回数が増えるほど、一つひとつへの注意は下がっていく。「危険な操作は人間が気づいて止める」という設計は理屈のうえでは成立するが、実際には摩耗する——これがAnthropicの最初の教訓だ。

この摩耗を減らす目的で生まれたのが、以前この連載でも取り上げたClaude Codeのauto modeだ。分類器が「明らかに安全な操作」を自動承認し、危険な兆候のある操作だけ人間の判断を仰ぐ。Anthropicの発表では、この仕組みで行き過ぎた操作のおよそ83%を実行前に検知できているという。ただし分類器も確率的な仕組みである以上、100%の検知率にはならない、ともAnthropicは明記している。

「確認」より先に「壁」を作る

だからこそAnthropicが力を入れているのが、モデル側の工夫だけに頼らない設計だ。エージェントが「何をするか」を見張るのではなく、「そもそも何に手が届くか」を制限する——サンドボックス・仮想マシン・ネットワークの出口制御という、環境側の壁を先に作るという考え方になる。

3つの製品で、壁の作り方はそれぞれ異なる。

それでも見落としていた穴

壁を作ったあとも、Anthropicは自ら「見落としたリスク」を複数公表している。いずれも「壁は正しく機能していたのに、想定していなかった経路から抜けた」というパターンだ。ここでは中小企業の現場に引き寄せやすい3つを取り上げる。

1つ目は、信頼確認より先に実行されてしまうパターン。リポジトリをcloneしただけの段階で、「このフォルダを信頼しますか」と聞かれる前に、リポジトリ内の設定ファイルに仕込まれたhookが動いてしまう不具合が複数件見つかった。原因は、信頼確認より先に設定を読み込んでいたことにある。

2つ目は、2026年2月の社内レッドチーム演習で見つかったユーザー自身が攻撃の入り口になるパターンだ。「これ実行しておいて」という一見普通の依頼メールに、認証情報を読み取って外部に送信する指示を混ぜ込んだところ、25回の試行中24回、実際に認証情報の送信まで実行してしまったという。攻撃者の指示がユーザー本人の入力として届くため、モデル側の異常検知では防ぎようがなかった、とAnthropicは説明している。

3つ目は、許可したドメイン経由での情報流出。Coworkのネットワーク許可リストにはAnthropic自身のAPIドメインが含まれていたが、悪意あるファイルに仕込まれた指示が、攻撃者のAPIキーを使ってそのドメイン経由でファイルを送信してしまった。サンドボックス自体は正しく動作していたのに、「許可したドメイン=安全」という前提が崩れた例だ。

公表されている見落としはこの3件だけではない。Coworkの仮想マシン隔離については、「Claudeを閉じ込めていたのと同じ隔離が、ホスト側のエンドポイント検知(EDR)まで締め出していた」という指摘もある。EDRから見ればCoworkは中身の見えないハイパーバイザのプロセスに過ぎない、というわけだ。壁を高くすると、その内側が自社の監視からも見えなくなる——隔離と可視性のトレードオフは、権限設計を詰めるときに一度は通る論点になる。

中小企業の現場に引き寄せると

3つの見落としに共通するのは、「人が気づくはず」「このドメインは安全なはず」という前提が崩れた場面だという点だ。この連載で紹介してきたハーネスの考え方——AIの判断力に安全を委ねず、構造そのもので止める——と、Anthropic自身がたどり着いた結論はほぼ同じ方向を向いている。

自社でAIエージェントを使う際にも、応用できる点は多い。「確認ダイアログを付けたから安全」で終わらせず、認証情報がそもそもエージェントの手が届く場所に置かれていないか、外部通信を許可しているドメインが実際に何をできるドメインなのか——ここまで確認して初めて、確認ダイアログは意味を持つ。この「環境側で何が起こりうるか」の棚卸しは、パイロット・構築のフェーズで詰めておきたいテーマだ。