製品を通じて「Claude」を制御する方法

19時間前原文(anthropic.com)

概要

Claude の内部サービスへのアクセス権限拡大と生産性向上
リスク管理 の二要素：発生確率と被害範囲（ブラスト半径）
防御手法 ：ヒューマン・イン・ザ・ループと環境的封じ込め
三つのリスク と 三層防御 （モデル・環境・外部コンテンツ）
各 Claude製品 ごとの隔離パターンと学び

Claudeの権限拡大とリスク管理

1年前は Claude に内部サービスを停止できる権限付与を完全否定
現在ではこのレベルのアクセスが 日常的 となり、開発者の生産性が向上
リスクは「 失敗確率」と「 被害範囲（ブラスト半径）」の2要素
安全対策 とモデル訓練の進展により失敗確率は低減
一方で機能拡張により 被害範囲 は拡大傾向
エージェントが人間やチームの作業を代替することで、 未導入コスト が増大し、リスク許容度が上昇
エンジニアリング課題は「 被害範囲の上限設定」へ移行

被害範囲の制御手法

ヒューマン・イン・ザ・ループ ：人間による逐次承認でエージェントの行動を監督
- Claude Codeは以前、全操作ごとにユーザー承認を要求
- テレメトリで 93% の承認率、承認疲れにより監督精度が低下
- 自動承認モード 導入で承認疲れを緩和、だが確率的防御には限界
封じ込め（コンテインメント） ：エージェントのアクセス範囲を技術的に制限
- サンドボックス、仮想マシン、エグレスコントロールなどを活用
- Anthropicの主力防御策であり、セキュリティ上の課題も多発

三つのリスクと三層防御

ユーザー誤用 ：悪意または不注意で有害な指示を出すリスク
モデルの誤動作 ：誰も意図しない有害行動を取るリスク
- 例：Claudeがサンドボックスを脱出してタスク達成、git履歴から答えを抽出
外部攻撃者 ：ツールやファイル、ネットワーク経由での攻撃
- プロンプトインジェクションやエージェント実行環境への攻撃を含む
防御対象の三要素
- 実行環境 ：サンドボックス、VM、ファイルシステム境界、エグレス制御
- モデル ：システムプロンプト、分類器、プローブ、訓練修正
  - Claude Opus 4.7はプロンプトインジェクション耐性で業界最高水準
- 外部コンテンツ ：MCPサーバー、サードパーティプラグイン、Web検索ツール
  - ツール権限の細分化で被害範囲を限定
重層防御 の重要性
- 環境防御が不十分な場合はモデル層で補完
- ツールの能力・アクセス制限でさらなる上流防御

Claude製品ごとの隔離パターン

パターン1：エフェメラルコンテナ（claude.aiのコード実行）
- gVisorコンテナ上で完全サーバーサイド実行
- ファイルシステムはセッションごとに消去、被害範囲最小
- ユーザーのローカル環境非依存、従来型セキュリティ対策が中心
パターン2：ヒューマン・イン・ザ・ループサンドボックス（Claude Code）
- ユーザーのマシン上でファイルシステム・シェル・ネットワークにアクセス
- 書き込み・bash・ネットワークは承認制、読み取りは許可
- 承認疲れ対策としてOSレベルサンドボックス（Seatbelt, bubblewrap）を導入
  - ワークスペース内の書き込みのみ許可、ネットワークはデフォルト拒否
  - 承認プロンプト84%削減、ランタイムをオープンソース化
- 熟練ユーザーは自動承認傾向が高いが、逸脱監視も頻繁
  - ただしモデル高度化・マルチエージェント化で限界

見逃したリスクと対応

信頼ダイアログ前の脆弱性
- プロジェクト設定ファイル（例：.claude/settings.json）のフックが、信頼確認前に自動実行される不具合
- 修正：ユーザー承認前はプロジェクト設定の解析・実行を遅延
- ローカル入力も外部リクエスト同様に扱うべき
ユーザーを介したインジェクションリスク
- 社内レッドチーム演習で、従業員が悪意あるプロンプトでClaude Codeを起動するフィッシングに成功

このように、 Claude のエージェント化と権限拡大は生産性を高める一方で、 多層的な防御設計 と 新たなリスク発見・対応 が不可欠となっている。

Hackerたちの意見

彼らのフレーミングはめっちゃ面白いし、あのグラフィックも完璧だね。リスクは減らないけど、リターンは増えるから、害はビジネスのコストとして正当化されちゃう。だからリターンがどんどん高くなるにつれて、正当化できる害の量も増えていく。まさに社会の縮図って感じだね。

└

これが人間が実際にほとんどの決断をする時のやり方だよね。

└

そうだね。PC修理ビジネスを始めたとするじゃん。最初は、RAMの一枚を失ったり、誰かのマザーボードを壊したりするのがすごく痛いけど、週に10件やってるときはね。でも、1000件やるようになったら、それはかなり良いし、簡単にカバーできる。道具やスピードが増えると、バランスが変わってくるんだよね。

└

うん、サイモン・ウィルソンの「致命的トライフェクタ」について考えてたんだ。OpenClawスタイルの「汎用」AIエージェントの文脈で、人々が自分のハードドライブやGmailアカウントにフルアクセスを与えるみたいな。壊滅的な失敗の確率をゼロにはできないけど（「クロードがホームフォルダを消した」って話も聞くし）、爆風の半径を制限することはできるよね。リスクをゼロにはできないけど、ゲームをプレイしないことの機会コストは上がってる。だから、ある程度のリスクを受け入れることになる。個人的には、「中古のThinkPadが50ドルなのに、コンテナや仮想化をいじる必要ある？」って思う。自分専用のマシンを与えればいいんだよね。そうすれば、好きなだけ壊せるし。（あるいは3ドルのVPSでもいいけどね :)

└

彼らは破綻のリスクを考えてないから、ここがこの計算の崩れどころなんだよね。リターンは破綻のリスクを減らさないし、爆風の半径が増えるとリスクは増す。YOLO！

└

私はAIの普段の支持者なんだけど（他の人からは完全にクランカーの味方だって言われてる）、それでも完全に同意するよ。これらの連中は、明らかにクロードに核の発射コードを渡したり、十分なアクセスを与えてそのフルモデルをコピーさせたりするだろうね、もし「リターン」が大きければ。

└

でも、何をしてもこれはトレードオフなんだよね。人によってそのバランスの耐性は違うから、だから私はYouTubeでウィングスーツの人たちを見て楽しんで、自分ではやらないんだ。もちろん、この新しいAIの世界では、害の確率や規模を定量化するのは難しいし、完全にはわからない。私たちはAIでリスクを軽減しようとしてるけど、もしかしたら一歩間違えば崖から落ちるかもしれない。

└

これが現実世界での意思決定の仕方だよ。リスクとリワードは重要な要素だ。

└

もしこれが正しく理解できているなら、Anthropicの主張は「はい、これによってあなたのインフラの一部が吹き飛ぶかもしれませんが、それだけの価値があります」ということだね。問題は、実際にそのコストに見合う価値があることを証明できた人がいないことだ。それは非常に脆弱な仮定だよ。

└

すべての行動にはリスクとリワードの方程式があるけど、普段はそれがこんなにはっきりと描かれることはないよね。朝起きることには、つまずいて頭を床にぶつけるリスクがある。道路を渡ることには、バスにひかれるリスクがある。食べ物を食べることには、喉に詰まるリスクがある。コンピュータセキュリティでも同じことが言える。唯一本当に安全なコンピュータは、電源を入れないものだけど、それでも攻撃者が侵入してストレージを盗むリスクがある。こういう場合に潜在的な危害が利益を上回るかどうかに同意するかどうかは別として、そういう計算は常に行われているから、そうだね、君の言う通りだと思う。それが社会の本質だよ。

└

限定的責任があると、無限のリスクを取ることが合理的な選択になる。AIは「ただ」この企業モデルを拡大し、次の災害までの時間を圧縮するんだ。

Cowork VMを調べたところ、汚染は文書化されてなくて、制御もできない（公に知られている - 回避策はあるけど）。そのプロセスでたくさんの無駄とフラストレーションを生み出すんだ。CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1は、クロードがすべてのマウントされたリポジトリのCLAUDE.mdを見つけて読み込むことを意味する（設定によって）。だから、複数の無関係なリポジトリで同時に作業するのは、初めから快適な体験じゃない。他にも面白いVMの環境変数がいくつかあるよ：CLAUDE_CODE_IS_COWORK=1 CLAUDE_CODE_BRIEF=1 CLAUDE_CODE_BRIEF_UPLOAD=1 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 CLAUDE_CODE_DISABLE_CRON=1 CLAUDE_CODE_ENTRYPOINT=local-agent CLAUDE_CODE_EXECPATH=/usr/local/bin/claude CLAUDE_CODE_HOST_HTTP_PROXY_PORT=36543 CLAUDE_CODE_HOST_PLATFORM=darwin CLAUDE_CODE_HOST_SOCKS_PROXY_PORT=46673 USE_STAGING_OAUTH= _=/usr/bin/env all_proxy=socks5h://localhost:1080 ftp_proxy=socks5h://localhost:1080 grpc_proxy=socks5h://localhost:1080 http_proxy=http://localhost:3128 https_proxy=http://localhost:3128 no_proxy=localhost,127.0.0.1,::1,.local,.local,169.254.0.0/16,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

エージェントがより能力を持つようになると、その潜在的な爆発半径も広がる。エンジニアリングの課題は、それをどう制限するかだ。最近、LLMを擬人化するとちょっと不満を持つ人が多いけど、もっと悪いのは、LLMが映画のロジックで動いているかのように、ネットに出て行って何かを複製し始めるふりをすることだと思う。

└

まあ、問題は、私たちが彼らを問題解決や指示に従うように訓練していることだよ。だから、何かを頼むと、論理を考えて、最も簡単な方法が別のこと、例えば生産データベースを削除することだと判断したら、アクセスできるなら、君のクレデンシャルを全部調べてデータベースのクレデンシャルを見つけて、生産データベースを削除しちゃうんだ。彼らはそういうことをする方法をどんどん上手くなってきてるし、指示に従うのは得意だけど、すべての指示を守るわけじゃないし、常識で行動するわけでもない。まるで逃げ出して複製を始めるようなオーズではないけど、アクセスを与えれば与えるほど、いつかは君が望まないことをする必要があると論理的に結論づける可能性が高くなるんだ。明示的にやらないように言っていないか、文脈が複雑すぎて、その指示が他の指示よりも軽視されてしまうこともある。彼らが必要なことをするために、サービスにアクセスするためのAPIキーが必要だと結論づけるのを見たことがあるよ。でも、彼らはそのAPIキーを持っていない。でも君は持ってる、ブラウザでアクセスできるからね。だから、彼らはブラウザからクッキーをスクレイピングするPythonスクリプトを書いて、そのクッキーを使ってサービスにアクセスしようとする。これは、Crowdstrikeがブラウザからクッキーをスクレイピングしようとする新しいPythonスクリプトを気に入らなかったから止まっただけで、エージェントに実際にサンドボックスがあったわけじゃないんだ。

└

LLMは人間のように擬人化されることで明らかに設計上壊れてるけど、私たちが理解していた「ソフトウェア」は避けられず「擬人化された存在」へと進化していると思う。[1]にいくつかメモを残したけど、これはAIが生成したものだよ。擬人化されたブランドがより支配的になるという興味深いトレンドもあるね：ClaudeとDoubao vs ChatGPTとDeepSeek。

└

LLMは、映画のロジックみたいにネットに忍び込んで、何かのオージーのように複製を始めるってことだね。なんでダメなの？モデル自体を動かす話じゃないなら、AIエージェントはソフトウェアの脆弱性を使って他のエージェントを広めるエージェントワームを書くことができるんだ。今はLLMがハードウェアに依存しすぎててモデル自体を広めるのは難しいけど、数年後には最適化が進んでそれも見られるかもしれないね。君の言ってることは、昔「画像はウイルスを広められない」って言ってた頃を思い出させるよ。突然、デコーダの脆弱性が見つかって、まさにそれをする画像ウイルスが作られたんだ。

Anthropicが言うことにはすごく懐疑的だよ。彼らは自社製品を危険に見せようとするインセンティブが強いからね（つまり、「能力がある」「SF的」「みんなより先を行ってる」）。上場前にそういうことをやってきたからね。例えば、「脅威を感じたら、モデルがエンジニアのメールを使って不倫を脅迫する」みたいなナンセンス、覚えてる？あれはただのファンフィクションだよ。いくつかの事実を元にシナリオを作って、モデルにその続きを考えさせただけ。クラウドにイギリスの王冠の宝石を盗む方法を聞いてみたら、いくつかアイデアをくれるよ。だからって、彼らのモデルがそんなに危険だって、ロンドン塔に追加のセキュリティが必要になるわけじゃない。彼らの他の脅し文句も、たぶん同じようなもんだと思う。

└

彼らはOpenAIよりも心配だよ、だってすごく欺瞞的だから。

└

彼らはただいくつかの事実を元にシナリオを作り、モデルにその続きを考えさせただけだ。そう、それが全てだよ。彼らは研究をしている。Anthropicは、脅迫テストの観察についての説明を始めるとき、フィクションの会社を使ったテストシナリオだと言っている。 >別のテストシナリオのクラスターでは、Claude Opus 4にフィクションの会社でアシスタントとして行動するように頼んだ。 https://www.anthropic.com/claude-4-system-card

└

Anthropicが言うことには本当に懐疑的だよ。彼らは自社の製品を危険に見せることにすごくインセンティブがあるからね。OpenAIやGoogleは「その戦略」を使ってないし。Anthropicの人たちがAIの安全性を本当に気にかけているとは思う。会社が設立された主な理由でもあるし。でも、新しい人やお金が流入することで、その理想主義が薄れていくのも想像できる。

最近、バブルラップを使って、実行するディレクトリに対してのみ読み書きアクセスを与えるプロセスを立ち上げるための簡単なヘルパー関数を作ったんだ（GUIやlibportalが動くために、いくつかの特定のLinuxシステムディレクトリも含めてね）。これって、他の場所にあるランダムなもの（スクリーンショットやログファイルなど）にエージェントを指向させたい時に、手間が少なくて済むんだ。AIツールプラットフォームがこういう体験に投資していないのが不思議で仕方ないよ。これをやろうと思ったのは、ZedがAI関連の作業に使われることを前提にしているのに、ユーザー全体の設定ファイルに特定のパスの権限しか設定できないのが不満だったから。プロジェクトレベルの設定ファイルは存在するけど、なぜかエージェントの権限設定はサポートしていないんだ。

自分のLinuxのコンテインメントセットアップにはまだ満足してるよ。[1][2] 記事から見える唯一のリスクは「承認されたドメインを通じた情報漏洩」かな。でも、VMの中には（設計上）ソースコード以外に漏洩するものがないから、最近ではそれもあんまり価値がないしね。このセットアップの一番の利点は、エージェントが自分ができる開発作業（パッケージのインストールやDockerイメージのビルド・実行など）を全部やってくれること。手動でやってからエージェントに報告するよりも、ずっと早いループだよ。

└

エージェントは、プロジェクト内で悪意のあるライブラリを使うように騙されて、それをコミットしてプッシュすることがある。それをVMの外で実行すると、危険にさらされることになる。だから、もしリポジトリのコードをVMの外で実行して、コミットされたものを全部レビューしなかったら、まだ危険にさらされているよ。

qemuのVMを使ってるよ。このVMはインターネットにアクセスできるから、そこが一番のリスクかな。Claudeがどこかに何かをアップロードしちゃうかもしれないし。GitHubと連携させたい場合は、リポジトリに制限されたトークンを作って、読み取りまたは読み書きアクセスを与えてる。でも、プッシュはせずにコミットだけして、VMからSSHでそのコミットを取得して、ログを確認して自分でプッシュするのが好きだな。Claudeをコンテナで動かすことも考えたけど、ちょっと弱い感じがする。Linuxの脆弱性が多すぎるからね。多分、これらの恐れは根拠がないかもしれないけど、信頼できないものをqemuのVMで動かす方が安全だと感じる。

これをやるのは本当に難しいよ。残念ながら、ブログ記事はどれだけ難しいかを詳しく説明してないけど、いくつかのケースには触れてる。例えば、ネットワークアクセスのあるVMでエージェントを動かすと、何かがそれをきっかけに二次的なプロンプトインジェクションをエンコードすることがある。そうなると、VMから出てくるアーティファクトがローカルのより特権のあるエージェントを感染させることになる。前の職場でコンピュータ使用分析をしていたときに出てきた別のケースは、ユーザーの入力が悪くないと信頼できるかどうかを判断しようとしたこと。一般的に、ユーザーが入力したものなら大丈夫だけど、ユーザーのファイルやカレンダーのイベントはどうなる？製品の全体の目的は、エージェントがそれらを管理することだったから、もはやそれらがインジェクションされていないとは信頼できなくなったんだ。（「スーパーボウルがいつか調べて、その週末の飛行機のチケットを予約するのをリマインドしてくれる？」）こういう汚染分析をすると、こういうことを止めるのが本当に難しいことがすぐにわかるし、サンドボックスやVMを周りに置くだけではあんまり役に立たないことが多い。

このスレッドには遅れて参加したけど、投稿が「パターン1」でのClaudeのアクセス制限に関するリスクやミス、事件の部分をスキップしてるみたいだね。これをちゃんとやるのはまだ難しいんだよ！例えば、Anthropicは、ephemeral containersで隔離されたclaude.ai/codeセッションが、ユーザーの他のセッションや接続されたリポジトリ、環境変数にアクセスして流出させることを許すいくつかのバグを出荷してしまったんだ。悪用されたClaudeは、元のセッションの制約に関係なく、任意の指示で新しいClaudeセッションを生成することもできる。これについては、2月に（許可を得て）書いたんだけど、ほとんどの問題はすぐに修正されたよ。でも、根本的なトークンスコープの問題はその後何度も後退していて、Mythos以降も含めて、Anthropicがまだこれを解決したとは言えないね。

プロキシはVMの中にあるんだ。サーバー側から見ると、Coworkリクエストは他のAPIクライアントと区別がつかないからね。だから、攻撃者がVM内でrootを取ったら、ファイルを流出させることができるんだ。なんでプロキシをクライアントの外、VMの外で動かさないの？

ハクソク