このブログでは以前、Claude Codeがterraform destroyを実行し本番インフラを消してしまった事例と、確認ダイアログが無告知で自動継続していた件を取り上げた。どちらも「対策はhooksなどで自分で作るしかない」という話で締めていたが、その後Anthropic自身が公式のアップデートで手当てを進めていることが、公式ドキュメントで確認できたので紹介したい。

auto modeとは何か

Claude Codeには2026年3月下旬に研究プレビューとして追加された「auto mode」という実行モードがある。ファイル操作やコマンド実行のたびに人間の承認を求める代わりに、破壊的・不審な操作かどうかを分類器（classifier）が都度判定し、安全と判断されたものは確認なしに実行、危険と判断されたものはブロックして提示する仕組みだ。「毎回確認する」運用と「--dangerously-skip-permissionsで確認を全部飛ばす」運用の中間に位置づけられている（公式ドキュメント）。

6月：terraform destroyと破壊的なgitコマンドをブロック

2026年6月15〜19日（Week 25）の公式アップデートによると、auto modeの分類器は次のような操作を「ユーザーが明示的に指示していない限り」ブロックするようになった。

過去記事で扱った事故は、まさにこの「terraform destroyが意図せず実行される」パターンだった。公式ドキュメントの文言をそのまま訳すと、「ユーザーが対象スタックを名指しで依頼していない限りterraform destroyをブロックする」とあり、あの事例のような「重複整理を頼んだらインフラごと消えた」というケースは、この仕様変更以降なら分類器が一度止める設計になっている。

7月：なりすまし承認の防止にも対応

2026年7月6〜10日（Week 28）のアップデートでは、さらに次の変更が加わった。

最後の項目は、以前取り上げた「60秒無応答で自動継続してしまう」問題とは別の切り口だが、根っこは同じ「AIが“承認された”と誤認しないようにする」という方向性だ。公式ドキュメントの原文は”Background task notifications now explicitly state that no human input has occurred, preventing fabricated in-transcript approvals from being acted on”となっている。

「勝手に安全になる」わけではない

ここで注意したいのは、これらはauto modeという特定の実行モードを使った場合の挙動であり、何もしなくても自動的に効くわけではないという点だ。公式の設定リファレンスを見ると、分類器が「何を信頼するか」はautoMode.environmentという設定に依存する。既定では作業ディレクトリと現在のリポジトリのリモートしか信頼されておらず、自社のクラウドバケットや内部ドメイン、社内サービスは、明示的に登録しない限り「外部」として扱われる。

設定は正規表現やツール名のパターンマッチではなく、自然文で「自社のインフラをどう説明するか」という形になっている点も特徴的だ。たとえば次のように、会社名・信頼するソース管理・クラウドバケット・社内ドメインを自然文で列挙する。

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts",
      "Trusted internal domains: *.corp.example.com"
    ]
  }
}

さらに、「絶対に人間の確認を挟みたい操作」（例：git pushやgh pr create）は、分類器の判断に任せずpermissions.askで明示的に固定できる。分類器より前に評価されるため、auto modeが有効でも必ず確認プロンプトが出る。

中小企業が実務で押さえるべきこと

  1. auto modeの既定ブロックは「土台」であって「自社仕様」ではない：terraform destroyや破壊的gitコマンドの既定ブロックはありがたいが、自社特有の「絶対に自動実行させたくない操作」（例：特定の顧客データベースへの書き込み、特定の本番ドメインへのデプロイ）はautoModeのhard_deny・soft_denyやpermissions.askで自分たちの言葉で明示しておく必要がある
  2. 「人間の確認が必須」な操作は分類器任せにしない：push・PR作成・本番デプロイなど、会社としてハンズオフにしたくない操作はpermissions.askで固定し、分類器のさじ加減に委ねない
  3. アップデート内容を追う運用を仕組み化する：今回のように、既存の不安（terraform destroy事故、なりすまし承認）に対する手当てが数か月かけて段階的に入ってくることがある。公式の変更履歴を定期的に確認し、自社の設定を見直すタイミングを運用に組み込む

ベンダー任せにしない、が結局効いてくる

Anthropicが数か月かけてこうした手当てを積み重ねてきたこと自体は評価できる材料だ。ただし、以前の記事でも触れた通り、ベンダーの既定値は変わり得るし、既定のブロックルールが自社の業務にそのまま当てはまるとも限らない。「terraform destroyが自動でブロックされるようになったから、もう権限設計は考えなくていい」ではなく、ベンダーが用意した土台の上に、自社の言葉で信頼境界と絶対確認ポイントを明示しておく——これもハーネスの考え方の一部だ。

どの操作を分類器に委ね、どこを自社のルールで固定するか。この線引きはパイロット・構築のフェーズで詰めるテーマの一つになる。自社の運用でどう設計すべきか整理したい場合は、30分の無料診断で相談できる。