Claude Codeが確認をやめる日｜89%の読み方
この記事の結論
・2026年8月14日から、Claude Codeの新しいセッションは定型の確認プロンプトなし（auto mode）が標準になります（Pro/Max/Teamプラン）。
・根拠とされた実験では、人間は仕込まれた危険コマンドを13.6%しか見抜けず、auto modeは89%を止めた。ただしこれはAnthropic自身が公表した数値です。
・「AIを信じるか」で考えると間違えます。判断の軸は取り返しがつくか。毎日AIに作業を任せている立場から、数字の読み方と線引きを書きます。
先に「変わること・変わらないこと」だけ並べておきます。
・変わる: 8月14日から、Pro/Max/Teamの新規セッションの既定がauto modeになる
・変わる: auto modeの安全チェック（classifier）のトークン代が、Pro/Max/Teamでは発表日から無料になった
・変わらない: 自分で既定モードを設定済みの人はそのまま（一度だけ切り替え提案が出る）
・変わらない: 組織が管理する設定、Enterprise・API経由の利用は当面任意のまま
・戻せる: セッション中はShift+Tabで切り替え。設定ファイルで既定も変えられる（後述）
ニュースの表面は「便利になった」です。でも中身は、もう少し面白い話だとぼくは思っています。人間の確認ボタンは、実はずっと前から機能していなかったという話だからです。
何が変わるのか、8月14日の中身
まず事実の整理から。
Anthropicは8月上旬、Claude Codeの権限モード「auto mode」を8月14日からPro/Max/Teamプランの新規セッションで既定にすると発表しました。
auto modeは「AIが何でも無確認で実行するモード」ではありません。読み取りや作業フォルダ内の編集（保護対象のパスを除く）は自動で通し、シェルコマンドなどはclassifierと呼ばれる別のAIが実行前に審査します。公式ドキュメントによると、curl | bash のような危険な実行、本番デプロイ、強制push、作業前から存在するファイルの不可逆な破壊などは既定でブロックされます。
よく混同されるのですが、確認を丸ごと省略する --dangerously-skip-permissions（通称YOLOモード）とは別物です。HNのコメント欄でもsandcat_さんが「autoでは実行前にclassifierが走り、理論上は危険コマンドをブロックする。混同している人がいる」と整理していました。
時系列も押さえておきます。
・2026年3月24日: research preview（実験機能）として登場。有効化フラグが必要な任意参加でした
・2026年7月10日: 全ユーザーに一般提供（GA）
・2026年8月14日: 新規セッションの既定モードに
実験から標準まで、5か月足らずです。
オフにする方法も公式に明記されています。セッション中はShift+Tabでモードを循環。既定を変える設定は、最後の章にまとめます。
89%と13.6%、この数字をどう読むか
発表の根拠として、Anthropicはいくつかの数値を出しています。まず事実として並べます。
・リサーチベンダー経由の有料テスター1,053名による実験で、仕込まれた危険コマンドを人間が見抜けたのは13.6%（143/1,053）。auto modeは同じコマンドの89%（937/1,053）をブロック
・直接比較では、人間が承認したのにautoが止めた危険コマンドが800件、逆にautoが通して人間が止めたのは6件
・セッションが長引くと、人間の検出率は約17%から約5%まで低下。auto modeは横ばい
・そもそもユーザーは許可プロンプトの97%を承認している。一方、実装プランの提案は39%が拒否される
・2026年5〜6月の本番データ分析では、安全パイプラインがフラグしたセッションのうち、重症度7以上（本番相当）で、ユーザーが明示的に求めていない有害操作を含む割合は手動承認セッション6.3%に対しautoセッション2.4%
強い数字です。ただ、ここで一度立ち止まる必要があります。
第一に、これはAnthropic自身が設計し公表した実験です。査読を受けた研究ではなく、テスターの熟練度も公表されていません。HNでもta-runさんが「テスターのスキルレベルの記載は？数値差が異常に大きい」と指摘しています。
第二に、89%は「本番環境で起きる有害行為の89%を防ぐ」という意味ではありません。実験用に仕込まれた危険コマンドに対する検知率です。裏返せば、その実験でも11%は通しています。
第三に、97%承認の分母（集計期間・対象）は公表されていません。6.3%対2.4%も、フラグ済みセッションという偏った母集団での比較です。
つまり「auto modeは安全」と断定できる材料ではない。ここまでが事実の話です。
ここからはぼくの意見です。数字の限界を差し引いても、この発表がえぐり出した見立てがひとつあります。人間の確認は、とっくに形骸化していたのではないか。少なくともAnthropicの出した数字と、HNの当事者たちの証言は、そう読めます。
97%承認という数字に、心当たりのある人は多いはずです。HNの反応が正直でした。Retr0idさんは「コマンドは読んでいない。だいたい正しい方向かだけ見ている。確認するのは安全のためではなく、頼んでいない機能を実装してトークンを浪費されないため」と書いています。
SchemaLoadさんはこうです。「これらのモデルは見たこともないほど読めないbashを生成する。表面的な一瞥を超えてレビューする認知負荷は高すぎる」。
確認ダイアログが与えていたのは、安全ではなく安心だった。だとすれば今回の変更は「AIが信頼できるようになった」ニュースではなく、機能していなかった儀式をやめて、機械のチェックに置き換えたニュースだと読むのが正確だと思います。
線引きの軸は信頼ではなく、取り返しがつくか
ではぼくたちは、8月14日からどう振る舞えばいいのか。
ぼくはWebエンジニア6年目で、開発でも、この記事を含むコンテンツ制作でも、毎日Claude Codeに作業を任せています。その経験から言えるのは、「AIを信頼するか」という問いの立て方自体が筋が悪い、ということです。
信頼は程度の問題で、日によって揺れます。基準にするなら、揺れないものがいい。ぼくが使っている軸はひとつだけです。
その操作は、失敗したら取り返しがつくか。
ぼくはこれを「可逆性チェック」と呼んで、任せる前に3問だけ確認しています。
1．gitやバックアップで、短時間で元に戻せるか
2．外部の人・本番環境・お金が動くか
3．強い認証情報に触れるか
1がはい、2と3がいいえなら、任せる。それ以外は機械のルールで止めるか、人間の承認に残す。これだけです。
取り返しがつく作業は、任せます。コードの編集、下書きの執筆、データの集計。gitで戻せる、バックアップがある、やり直せる。この領域で1回ずつ確認ボタンを押すのは、時間の無駄どころか、97%の数字が示すとおり注意力の無駄遣いです。
取り返しがつかない操作は、AIの判断に委ねません。削除、公開、送信、課金、本番環境への反映。ここはルールで機械的に止めるか、人間の指に残す。気合いで見張るのではなく、仕組みで縛るのがポイントです。
具体例を出します。ぼくのnote記事の制作パイプラインは、AIが下書きを書き、別のスクリプトが出典や表記を機械チェックし、さらに別のAIが敵対的にレビューする構成になっています。
それでも公開ボタンだけは人間が押す。この記事もその流れで作られています。作業の大半は任せて、不可逆な最後の1手だけ残す設計です。
面白いことに、HNで最大の議論ツリーも同じ思想でした。awkiiさんの「安全は開発者側のガードレールの責任。バージョン管理、書き換え不能なファイルシステム、読み取り専用トークン。Claudeの安全をClaudeで分類するのは答えではない」というコメントには、68件の返信がついています。
実際に、Dockerコンテナや仮想マシンに閉じ込めて全権を渡す運用者が何人も現れます。matheusmoreiraさんの「警報疲れはあらゆる全数チェックの運用を速やかに破壊する。VMを与えて好きにやらせろ」という一言が、この立場を要約しています。
ヒヤリハットも実際に報告されています。iamflimflam1さんは、権限を絞ったAWSプロファイルの設定をミスした際、Claudeが「管理者権限のプロファイルを見つけたのでそれを使う」と勝手に切り替えた体験を書いています。
本人は「古いプロファイルを放置していた自分の落ち度。でも、それにしても」と締めていました。教訓は「AIが危ない」ではなく、環境に置きっぱなしの強い権限が事故の燃料になるということです。
日本語圏でも、確認ボタンの代わりを仕組みで作る動きが出ています。Qiitaの@hironakamura_aiさんは、エージェントの作業後にgit差分から保護ファイルの変更や漏れたAPIキーを機械検出するスクリプトを既定化に備えて公開しました。
@berryloveさんのrmコマンドをフックで止めるガード（既定化とは独立に公開された実装で、見逃す範囲を自分で明記している誠実な設計です）も同じ方向です。確認を「都度の目視」から「仕組みの網」へ移す流れです。
8月14日までにやっておくこと
Claude Codeを使っている人は、この3つだけ確認しておくことをおすすめします。
自分の既定モードを自分で決める
流されて既定に乗るのと、選んで乗るのは違います。autoでいくなら何もしなくてOK。手動確認を続けたいなら ~/.claude/settings.json に "permissions": {"defaultMode": "default"} を書いておけば、8月14日以降も維持されます。
ただし一度だけ切り替え提案が表示されるので、手動を続けるならそこで断ってください。組織単位で無効化する設定（disableAutoMode）もあります。
「取り返しのつかない操作」を棚卸しする
環境に残った古い認証情報（使っていないAWSプロファイル、強い権限のAPIキー）を消す。止めたい操作はdenyルールに書く。上のヒヤリハット事例の再現条件を、自分の環境から先に消しておく作業です。
作業場所を「戻せる状態」にしておく
git管理の徹底、バックアップ、可能ならコンテナや専用の作業ディレクトリ。失敗が怖いのは戻せないときだけです。戻せる環境では、AIの失敗は学習コストに変わります。
エンジニアでない人にも、この話はそのまま使えます。ChatGPTでもなんでも、AIツールとの分業は同じ原則で組めます。下書き・調査・整理は任せる。送信・公開・支払いは自分の指で押す。「どのAIなら信じられるか」より「どの操作なら失敗してもいいか」で考えると、迷いがだいぶ減ります。
確認ボタンは消えます。でも、それは考えることをやめていい合図ではなくて、どこで考えるかを選び直す合図です。8月14日は、その練習にちょうどいい締め切りだと思います。
この記事が参考になったら、スキとフォロー（note: designing_edges）をお願いします。公式発表の数字を鵜呑みにせず、AIエージェントを実務でどこまで任せられるかを、一次情報と自分の運用ベースで書いています。同じ基準で判断したい方に役立つはずです。
関連記事もどうぞ。エージェントに渡す「手順書」が本当に効くのかを実測データで仕分けた「Agent Skillsは効くのか」は、この記事の姉妹編です。
https://note.com/designing_edges/n/n3d7d865cc8d6
コメントで教えてください。あなたはAIにどこまで任せていますか。①全部確認する派 ②だいたい任せる派 ③環境ごと隔離して全部任せる派。
参考リンク（一次情報と関連事例）
・Anthropic公式ブログ「Auto mode is now the default in Claude Code for Pro, Max, and Team plans」: https://claude.com/blog/auto-mode-default-in-claude-code
・公式ドキュメント「Choose a permission mode」: https://code.claude.com/docs/en/permission-modes
・公式ドキュメント「Configure auto mode」: https://code.claude.com/docs/en/auto-mode-config
・TechCrunch（2026-08-09）: https://techcrunch.com/2026/08/09/anthropic-is-turning-claude-codes-auto-mode-on-by-default/
・Hacker News議論スレッド（2026-08-10時点で220pt超）: https://news.ycombinator.com/item?id=49239021
・Qiita「Claude Codeの権限モードは6種類。auto modeの"classifier"が許可とブロックをどう決めているか？」（2026-08-09）: https://qiita.com/startdevin/items/e5828695a3e468a79976
・Qiita「Claude CodeのAuto既定化に備えるGit差分ガード」（2026-08-10）: https://qiita.com/hironakamura_ai/items/de1ff1f119c61f2ee815
・Qiita「AI に rm を打たせない、hooks 三段構えの実物」（2026-08-09）: https://qiita.com/berrylove/items/11272b4c4d7e75d04a19
