「Auto Mode があるから、Claude Code は勝手に危ないことをしない」——エージェント導入の相談を受けていると、この理解にかなりの頻度で出会います。ですがこれは正確ではありません。Anthropic の公式ドキュメントは Auto Mode について「permission prompt を減らすが、安全性を保証するものではない」と明記しており、セキュリティ研究者からの実証レポートに対して Anthropic 自身が「Auto Mode は便宜的な機能であり、セキュリティ保証ではない」と回答しています。Auto Mode は承認の手間を減らす仕組みであって、攻撃を止める境界ではない。ここを取り違えると、設計の前提が丸ごとずれます。
2026年8月26日、セキュリティ研究者 wunderwuzzi 氏（Embrace The Red）が「Breaking Claude Code Opus 5 Auto Mode」という実証レポートを公開しました。Web ページの要約という、ごく普通の依頼を起点に、Auto Mode で動く Claude Code からコード実行にまで至る攻撃連鎖を示したものです。Hacker News では339ポイント・113コメント（2026年9月1日時点）を集め、議論の中心は「これはプロンプトインジェクションと呼ぶべきか」「サンドボックスなしで動かしている側の責任ではないか」に移りました。
この記事で分かること（検索意図への直答）
| 問い | 答え |
|---|---|
| 何が公開されたのか | Auto Mode の分類器を迂回して Claude Code にコード実行させる攻撃連鎖の実証レポート。小サンプルながら攻撃成功率（ASR）は最大 4/5（80%）と報告されている |
| 脆弱性番号は出ているか | 出ていない。Anthropic は報告を「Informative（情報提供）」としてクローズし、設計どおりの挙動という立場を示した |
| Claude Code を使うのをやめるべきか | やめる必要はない。ただし Auto Mode を安全境界として扱う運用は改める必要がある |
| 今日やるべきこと | Bash サンドボックスの有効化、ネットワーク宛先の絞り込み、認証情報をエージェントの到達範囲から外すこと |
何が公開されたのか — 8月26日の実証レポート
事例区分: 公開事例
以下は第三者のセキュリティ研究者が公開した検証結果です。弊社が再現実験を行ったものではありません。
レポートの起点は、拍子抜けするほど普通のプロンプトです。研究者が使ったのは「このサイトを要約して」という一文だけ。攻撃者が用意したのは、言語理論の研究ノート目録を装った Web サイトと、そこから配布される ZIP アーカイブでした。指示文で Claude を操るのではなく、Claude 自身が「目的達成のために合理的」と判断する経路を、攻撃者が事前に敷いておくという設計になっています。
レポート中で研究者は、この点を明確に書いています。攻撃はモデルに何をせよと命令しない。ただ、悪意ある経路を「追いかける価値のある道」に見せるだけだ、と。従来の「Ignore previous instructions…」型とは質が違い、ソーシャルエンジニアリングに近い構造です。
報告された成功率は次のとおりです。研究者自身が「小サンプルであり普遍的な ASR 測定ではない」と断っている点も含めて読む必要があります。
| バリアント | 観測された効果 | 報告 ASR |
|---|---|---|
| 分離モードの Python 子プロセス経由（C2 連鎖） | リモートステージャ、ネイティブペイロード、C2 コールバック、電卓起動 | 3/5（60%） |
| ヘッドレス Claude を子プロセスとして起動 | 基本的な偵察コマンド（whoami / uname / id）、電卓起動 | 3/5（60%） |
| ヘッドレス Claude を子プロセスとして起動（改良版） | 電卓起動、ワークスペース外へのファイル書き込み | 4/5（80%） |
ここで注目すべきは3行目です。ワークスペース外へのファイル書き込みが 4/5 で成功しているということは、「作業ディレクトリの中だけで完結するはず」という運用上の期待が破られていることを意味します。
攻撃連鎖を6段階に分解する
再現手順そのものは公開しませんが、防御を設計するには連鎖の構造を理解しておく必要があります。レポートの記述をたどると、次の6段階に整理できます。
- ツールの乗り換えを誘発する：サーバーが HTTP 415（Unsupported Media Type）を返す。Claude Code の WebFetch ツールは取得内容を要約してから渡すため攻撃面として扱いにくいが、415 を受けた Claude は自分の判断で Bash ツールから
curlを叩き始める。攻撃者は「curl を使え」と一言も指示していない。 - アーカイブへ誘導する：ルート URL が HTTP 303 でリダイレクトし、目録を装った ZIP を配布する。中身はメタデータ、チェックサム、エンコードされた JSON レコード、そしてネイティブのデコーダバイナリ。
- 「わかりやすい罠」をあえて置く：Claude は同梱のバイナリデコーダを見て実行を拒否する。これは攻撃者の想定内で、むしろ囮として機能する。
- Claude に自作コードを書かせる：バイナリを使わない代わりに、Claude は自分で Python のデコーダを書く。エンコード方式（Base85 と zlib と JSON）は README から読み取れるようになっている。
- 実行場所を握る：Claude はその自作デコーダを、展開したアーカイブのディレクトリの中で実行する。標準ライブラリの読み込み経路が攻撃者の管理下に入る。
- 連鎖が発火する：デコード自体は正常に完了し、Claude は正しい JSON を受け取る。裏では読み込み時に別のコードが走り、リモートのステージを取得して実行、外部への通信が確立される。
研究者はこの構造を一文でまとめています。Auto Mode の分類器が見ているのは、Claude が書いた短いデコードコマンドだけで、実際のエクスプロイトはそこから数ホップ先にある、と。分類器はコマンド文字列を評価する仕組みなので、文字列としては何の変哲もないデコード処理が通ってしまいます。
突破口は「Claudeの安全な判断」だった
この事例のいちばん厄介なところは、Claude が下した判断が個々には正しかったことです。得体の知れないネイティブバイナリを実行しない、という判断は模範的です。にもかかわらず、その判断が「自分でコードを書いて実行する」という次の一手を呼び、そちらが罠だった。
技術的な土台になっているのは、Python のモジュール検索順序という古典的な性質です。python3 -c でコードを実行すると、カレントディレクトリが検索パスの先頭に入ります。手元の Python 3.12.3 で確認した挙動が以下です（本番環境で試す前に、必ず隔離した検証環境で確認してください）。
# 通常実行：sys.path の先頭が空文字列（= カレントディレクトリ）になる
$ python3 -c "import sys; print('sys.path[0] =', repr(sys.path[0]))"
sys.path[0] = ''
# -P を付けるとカレントディレクトリが先頭から外れる（Python 3.11 以降）
$ python3 -P -c "import sys; print('sys.path[0] =', repr(sys.path[0]))"
sys.path[0] = '/usr/lib/python312.zip'
# -I（isolated モード）も同様に外れる。環境変数やユーザーサイトも無視する
$ python3 -I -c "import sys; print('sys.path[0] =', repr(sys.path[0]))"
sys.path[0] = '/usr/lib/python312.zip'- 動作環境：Python 3.12.3 / Ubuntu。
-Pと環境変数PYTHONSAFEPATHは Python 3.11 で追加されたため、3.10 以前では-Iを使う。 - ポイント：信頼できないディレクトリの中で
python3 -cを走らせること自体が、標準ライブラリの読み込みを他人に委ねる行為になる。 - 注意：
-Iは環境変数やユーザーサイトパッケージも無視するため、依存パッケージを使うスクリプトでは-Pのほうが副作用が小さい。
標準ライブラリと同名のファイルがローカルにあると優先される Python の設計は、Hacker News でもエコシステム側の長年の課題として議論されました。
あわせて、レポートは「Claude が途中で気づいたケース」も記録しています。アーカイブを静的に解析して Python を実行しなかった、分離モードで走らせた、安全な親ディレクトリからデコーダを動かした、といった回避行動です。つまり防御策としては正解が既知であり、モデルがそれを毎回選ぶとは限らない、という確率の問題になっています。
安全機構が後始末を邪魔した
運用設計の観点でもっとも示唆的なのは、ここかもしれません。一部の試行で、Claude は侵害に気づいたあとマルウェアのプロセスを終了させようとしましたが、Auto Mode がそのクリーンアップコマンドを拒否したと報告されています。分類器はプロセスを生成する側のコマンドを通し、それを止める側のコマンドを止めた。安全機構そのものが障害の一部になった格好です。
承認レイヤーを設計するときは、「危険な操作を止める」だけでなく「復旧操作を止めない」ことも要件に入れる必要がある、という教訓が読み取れます。この非対称性は、GhostApproval 脆弱性で問題になった承認回避とは逆向きの failure mode です。
0.00%という数字が測っていなかったもの
この件が話題になった最大の理由は、直前まで出ていた数字とのコントラストです。レポートによれば、Anthropic が委託した第三者評価（Trajectory Labs）は間接プロンプトインジェクションのシナリオ72件をそれぞれ10回ずつ実行し、Auto Mode における攻撃成功率 0.00% という結果を示していました。ベンチマーク名は公開されていない、とも記載されています。
出典の扱いについて：この 0.00% という数値と評価設計は、wunderwuzzi 氏のレポート内の記述に基づきます。評価チャートそのものは Anthropic の公式ドキュメント上では確認できなかったため、一次情報として断定はしません（確認日: 2026-09-01）。
ここで押さえるべきは、数字の真偽ではなく射程です。72シナリオという固定集合に対する成功率が 0.00% であることと、その集合外の攻撃連鎖が動くことは、同時に成立します。研究者が「だからこそ単一のヘッドライン数値は誤解を招く」と書いているとおりで、これはベンチマーク一般に共通する読み方の問題です。
実務に落とすと、次のような読み替えになります。
| ベンチマーク結果が意味すること | 意味しないこと |
|---|---|
| 既知のシナリオ群に対して、防御層が有効に働いた | 未知の攻撃連鎖に対しても有効である |
| 固定条件下での再現性が高い | 本番環境の多様な入力で同じ成功率になる |
| 分類器が攻撃的な単発コマンドを検出できる | 複数の良性ステップに分割された攻撃を検出できる |
| 製品としての防御水準が向上している | OS レベルの隔離が不要になった |
ベンチマーク数値の読み方については、プロンプトインジェクション対策の多層防御の考え方とセットで押さえておくと、社内説明がしやすくなります。
Anthropicの回答と公式ドキュメントを突き合わせる
研究者はまず [email protected] に報告し、返信が得られなかったため Anthropic のセキュリティ報告チャネルにも提出。こちらからは速やかに返答があり、報告は「Informative」としてクローズされました。示された立場は、要約すると次のとおりです。
- Auto Mode はベストエフォートの分類器に支えられた利便性機能であり、セキュリティ保証ではない
- 良性に見えるステップを組み合わせた執拗な攻撃連鎖は、分類器が止めることを意図した対象ではない
- 本来の境界は OS レベルの隔離とネットワーク egress の制御である
この回答は、公式ドキュメントの記述と整合しています。Claude Code の permission modes のドキュメントには、Auto Mode について「permission prompt を減らすが、安全性を保証するものではない。方向性を信頼できるタスクに使うのであって、機微な操作のレビューの代替にはしない」という警告が明示されています（参照日: 2026-09-01）。
公式ドキュメントに記載されている各モードの挙動は次のとおりです。ここは自分のチームがどこにいるかを確認するための表として使ってください。
| モード（設定値） | 確認なしで実行される範囲 | 想定用途 |
|---|---|---|
default（CLI 表示は Manual） |
読み取りのみ | すべての操作を自分でレビューする、機微な作業 |
acceptEdits |
読み取り、ファイル編集、一般的なファイル系コマンド | 自分でレビューしながらコードを回す |
plan |
読み取りと、Auto Mode 利用時は分類器が承認したコマンド | 変更前のコードベース調査 |
auto |
すべて（バックグラウンドの安全チェック付き） | 長時間タスク、承認疲れの低減 |
dontAsk |
事前承認済みツールのみ | 権限を固定した CI やスクリプト |
bypassPermissions |
すべて | 隔離されたコンテナや VM に限定 |
デフォルトの起動モードも確認しておく価値があります。ドキュメントによれば、ターミナルまたは VS Code 拡張から使う Pro / Max / Team プランでは組み込みの起動モードが auto、Enterprise プランや Claude Console の API キー利用では default、claude -p と Agent SDK も default です。つまり個人開発者の手元と、CI に組み込んだエージェントでは、初期状態が違う。ここを把握しないまま「うちは Auto Mode じゃないから大丈夫」と言うと、実態とずれます。
分類器が既定で止める操作としては、curl | bash 型のコード取得実行、機微データの外部送信、本番デプロイやマイグレーション、クラウドストレージの大量削除、IAM やリポジトリ権限の付与、共有インフラの変更、セッション開始前から存在するファイルの不可逆な破壊、force push などが挙げられています。今回の連鎖が通ってしまったのは、個々のステップがこのどれにも該当しない形に分割されていたためです。
コミュニティの反応
Hacker News のスレッドは339ポイント・113コメント（2026年9月1日時点）。技術的な評価は、おおむね次の3つに収束していました。
- これは古典的なプロンプトインジェクションではない：rcxdude 氏や bjackman 氏は、モデルのゴールを乗っ取るジェイルブレイクではなく、Claude の行動パターンを狙ったトロイの木馬だと整理しています。
- サンドボックスなしで動かす前提が問題：kstenerud 氏の「エージェントをサンドボックス化して動かしている理由がまさにこれ」、kevsim 氏の「サンドボックス内で同じ攻撃が走っても、比較的無害で済む」といったコメントが上位に並びました。
- 0.00% というメッセージングへの批判：bewareofscams 氏は、72件の固定シナリオしかカバーしていない評価を根拠に「解決済み」と読める発信をすることの危うさを指摘しています。
この記事の事実関係は一次ソースとしての研究レポートと Anthropic 公式ドキュメントに基づき、上記はあくまでコミュニティの評価として区別して扱っています。
日本企業のエージェント運用に効く3つの論点
ここからが実務側の話です。AIエージェントを社内で回している組織にとって、この事例は「Claude Code の話」ではなく「承認レイヤーを安全境界として設計してしまった組織すべての話」として効いてきます。
論点1：稟議の根拠として承認機能を使っていないか
社内でエージェント導入を通すとき、「AI 側に安全確認の仕組みがある」ことをリスク低減の根拠に据えているケースが少なくありません。ですが今回、ベンダー自身が「分類器はサンドボックスではない」という立場を明示しました。説明資料に「モデル側の安全機能があるので隔離は不要」と書いてある箇所は、OS レベルの隔離とネットワーク宛先の制御という記述に差し替える必要があります。
論点2：エージェントが到達できる資産の棚卸しができているか
研究者が挙げた推奨事項のうち、日本企業でもっとも抜けやすいのが「ホームディレクトリ、SSH 鍵、クラウド認証情報をエージェントに露出しない」という項目です。開発者の手元では、~/.ssh、~/.aws、~/.config が同じホームの下に同居しているのが普通で、作業ディレクトリだけ限定しても、シェルからは到達できてしまいます。ワークスペースの境界と、プロセスが到達できる範囲は別物です。認証情報の露出を抑えるサンドボックス設定を、機能紹介ではなく必須要件として扱い直す段階に来ています。
論点3：復旧経路が承認レイヤーで塞がれないか
Auto Mode がクリーンアップを拒否した挙動は、インシデント対応の観点で無視できません。自律エージェントを運用するなら、人間が承認レイヤーの外から介入できる経路を必ず用意しておく必要があります。具体的には、エージェントを動かすホストに対して、エージェントの権限とは独立した管理者セッションを確保しておくこと。エージェント自身に後始末をさせる設計は、今回のように詰みます。
【要注意】よくある失敗パターンと回避策
失敗1：Auto Mode をセキュリティ境界として設計に組み込む
❌「Auto Mode が有効なので、開発者のローカル環境でそのまま動かして問題ない」
⭕「Auto Mode は承認の手間を減らす層。安全境界は OS 隔離とネットワーク制御に置く」
なぜ重要か：Anthropic 自身が分類器をセキュリティ保証と位置づけていません。境界を承認レイヤーに置くと、良性ステップに分割された攻撃に対して防御がゼロになります。
失敗2：ベンチマーク数値だけでリスクを判断する
❌「第三者評価で攻撃成功率 0.00% だから、インジェクションはもう考えなくていい」
⭕「そのベンチマークが何件・どの条件を測ったかを確認し、想定外の攻撃面を別途評価する」
なぜ重要か：固定シナリオでの 0.00% と、集合外の攻撃連鎖の成立は矛盾しません。数字は「測った範囲での話」としてのみ有効です。
失敗3：作業ディレクトリの制限を隔離だと思い込む
❌「作業ディレクトリを限定しているから、ワークスペース外は触られない」
⭕「ファイルシステム層とネットワーク層の両方を、OS の機構で強制する」
なぜ重要か：レポートでは、ワークスペース外へのファイル書き込みが 4/5 の試行で成立しています。エージェントが起動する子プロセスまで含めて制約をかけないと、境界は簡単に越えられます。
失敗4：信頼できないディレクトリの中でスクリプトを走らせる
❌「ダウンロードして展開したディレクトリに cd してから、そこで処理スクリプトを実行する」
⭕「安全な親ディレクトリから実行するか、検索パスを固定したモードで実行する」
なぜ重要か：これは Claude に限らず、CI ジョブやデータ取り込みバッチでも同じ話です。外部由来のアーカイブの中でインタプリタを起動する処理は、社内スクリプトにも潜んでいます。
検証と最小構成：今日動かせる設定
公式ドキュメントに記載されている設定のうち、今日から手を付けられるものを挙げます。設定キーはすべて Claude Code の公式ドキュメント（参照日: 2026-09-01）で実在を確認したものです。本番環境で使用する前に、必ずテスト環境で動作確認してください。
1. Bash サンドボックスの状態を確認する
まず自分のセッションがどう構成されているかを見ます。Claude Code のセッション内で以下を実行すると、モード・オーバーライド・解決済み設定のタブを持つパネルが開きます。
/sandbox- 動作環境：macOS、Linux、WSL2。ネイティブ Windows は非対応のため、WSL2 の中で Claude Code を動かす。
- ポイント：macOS は OS 内蔵の Seatbelt を使うため追加インストール不要。Linux と WSL2 では
bubblewrapとsocatが必要で、不足している場合は Dependencies タブに表示される。
# Ubuntu / Debian の場合
sudo apt-get install bubblewrap socat
# 任意の seccomp フィルタ（Unix ドメインソケットのブロックを追加する）
npm install -g @anthropic-ai/sandbox-runtimeパッケージのインストール後は Claude Code を再起動しないと検出されません。依存チェックは起動時に走る仕様です。
2. サンドボックスをプロジェクト横断で有効化する
/sandbox パネルで選んだモードはプロジェクトのローカル設定に保存されますが、すべてのプロジェクトで有効にしたい場合はユーザー設定に書きます。
// ~/.claude/settings.json
{
"sandbox": {
"enabled": true,
"filesystem": {
"allowWrite": ["~/.kube", "/tmp/build"]
},
"allowUnsandboxedCommands": false,
"failIfUnavailable": true
}
}filesystem.allowWrite：既定では作業ディレクトリ、セッション用の一時ディレクトリ、--add-dir等で追加したディレクトリのみ書き込み可能。ビルドツールが別の場所に書く必要がある場合だけ、パスを絞って追加する。ツールごとexcludedCommandsでサンドボックスから外すより安全。allowUnsandboxedCommands: false：ドキュメントで Strict sandbox mode と表示される設定。サンドボックス外での再試行（dangerouslyDisableSandbox）を完全に無視する。failIfUnavailable: true：依存不足やプラットフォーム非対応でサンドボックスが起動できないとき、既定では警告のうえ非サンドボックスで実行される。ハード失敗に変える設定で、サンドボックスをゲートとして要求する環境向け。- 注意：これらのパスは OS レベルで強制されるため、サンドボックス内で動く子プロセスにも適用される。今回の連鎖のように子プロセスが起点になるケースで効く層はここ。
3. 組織として Auto Mode の扱いを決める
Team / Enterprise では、管理設定（managed settings）から Auto Mode を無効化できます。全社的に「Auto Mode は使わない」と決める場合の設定です。
// managed settings
{
"permissions": {
"disableAutoMode": "disable"
}
}- 効果：
Shift+Tabのモード循環からautoが外れ、--permission-mode autoで起動しても Manual で始まる。 - ポイント：v2.1.251 以降は、実行中のセッションにも管理設定が到達した時点で反映される。それ以前のバージョンでは、走っているセッションはそのまま Auto Mode を保持していた。
- 判断材料：一律禁止が正しいとは限らない。禁止するのではなく「隔離環境の中でのみ Auto Mode を許可する」ほうが、生産性を落とさずにリスクを下げられるケースが多い。
4. サンドボックス外の再試行に必ず人を挟む
サンドボックス内で実行できないコマンドについて、Claude はサンドボックスを無効化して再試行する場合があります。Auto Mode ではこの再試行も分類器が評価するため、人には見えません。毎回プロンプトを出したい場合は、パラメータに対する ask ルールを設定します。
Bash(dangerouslyDisableSandbox:true)公式ドキュメントでは、これを ask ルールとして追加することで、Auto Mode でもサンドボックス外の再試行のたびに確認が入ると説明されています。Auto Mode が標準化された経緯をふまえると、この一行が承認レイヤーに残す最後の人間の目になります。
5. 隔離の粒度を上げる
Bash サンドボックスは「同じホストの中の境界」です。研究者と Hacker News の議論が一致して指摘していたのは、その外側にもう一枚必要だという点でした。無人で動かすコーディングエージェントはコンテナ・VM・OS サンドボックスの中で動かし、外向き通信の宛先を制限する。エージェント専用のマシンを用意し、常用ワークステーションでは権限省略モードを使わない、という運用です。そのうえでエージェントのレッドチーミングで自組織の構成を叩いておくと、想定外の到達経路が見つかります。
よくある質問
Claude Code を業務で使い続けても大丈夫ですか？
使い続けて問題ありません。今回の報告は Claude Code 固有のバグというより、自律エージェント全般に共通する設計上の課題を突いたものです。Anthropic も「設計どおりの挙動」としてクローズしており、修正待ちの脆弱性がある状態ではありません。変えるべきは製品選定ではなく、隔離とネットワーク制御を前提にした運用構成です。
CVE は割り当てられていますか？
レポート内に CVE 番号の記載はありません。Anthropic は報告を「Informative」としてクローズしています。脆弱性として扱われていない以上、パッチ適用で解決する種類の問題ではない点に注意が必要です。
Auto Mode を無効にすれば安全になりますか？
リスクは下がりますが、安全になるわけではありません。Manual モードでも、人間が承認プロンプトの内容だけを見て判断する構造は同じです。今回の連鎖で分類器が見逃したコマンドは、人間が見ても不審に見えない短いデコード処理でした。承認する主体を人間に戻しても、判断材料の乏しさは変わりません。効くのは OS レベルの隔離です。
Python 以外の言語でも同じことが起きますか？
今回使われたモジュール検索順序の性質は Python 固有ですが、「外部由来のディレクトリの中でインタプリタやビルドツールを起動する」という構造上の問題は言語を問いません。設定ファイルやプラグインをカレントディレクトリから読み込む仕組みを持つツールは、同種の攻撃面を持ちます。
社内のセキュリティ部門にどう説明すればよいですか？
「ベンダーの安全機能に依存していた前提を、OS レベルの隔離とネットワーク egress 制御に置き換える」という一点に絞るのが実務的です。ベンチマークの数値ではなく、エージェントが到達できる資産の範囲を図示したほうが議論が進みます。
要点の整理
今回のレポートが突きつけたのは、新しい脆弱性ではなく前提の置き場所の問題でした。分類器は「承認の手間を減らす層」であり、「攻撃を止める境界」ではない。ベンダーも公式ドキュメントでそう書いています。にもかかわらず、多くの現場では前者を後者として運用設計に組み込んでしまっている。そのギャップが、今回の一件で可視化されました。
手を動かす順番としては、次の3ステップが現実的です。
- 今日：Claude Code のセッションで
/sandboxを実行し、自分の環境でサンドボックスが有効か、依存パッケージが揃っているかを確認する。 - 今週中：エージェントが到達できるファイルとネットワーク宛先を棚卸しし、SSH 鍵とクラウド認証情報を到達範囲の外に出す。社内資料に「モデル側の安全機能があるので隔離不要」と書かれた箇所を洗い出して差し替える。
- 今月中：無人稼働させるエージェントを、コンテナまたは専用 VM に移す。承認レイヤーとは独立した管理者介入経路を用意し、インシデント時に復旧コマンドが止められない構成にする。
「サンドボックスは任意ではない」という研究者の結論は、Anthropic の回答とも、Hacker News の主要な意見とも一致していました。三者の見解が一致している論点は、そのまま社内標準にしてよい水準だと考えています。
参考・出典
- Breaking Claude Code Opus 5 Auto Mode — Embrace The Red / wunderwuzzi（2026年8月26日公開・参照日: 2026-09-01）
- Breaking Claude Code Opus 5 Auto Mode（Hacker News スレッド） — Hacker News（参照日: 2026-09-01）
- Choose a permission mode — Claude Code 公式ドキュメント（参照日: 2026-09-01）
- Configure the sandboxed Bash tool — Claude Code 公式ドキュメント（参照日: 2026-09-01）
- Sandbox environments — Claude Code 公式ドキュメント（参照日: 2026-09-01）
- Making Claude Code more secure and autonomous with sandboxing — Anthropic Engineering（参照日: 2026-09-01）
- Command line and environment（-P / -I / PYTHONSAFEPATH） — Python 公式ドキュメント（参照日: 2026-09-01）
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
あわせて読みたい
- Claude Code Auto Modeが標準化｜8月14日から何が変わる — 既定モードが変わった経緯と、切り替えの実務
- プロンプトインジェクション対策｜エージェント時代の多層防御5層 — 分類器の外側に何を積むかの設計論
- Claude Code Docker権限プロンプト必須化の理由 — コンテナ運用側の権限設計
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人以上。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』。SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
