HN 日本語サマリー

← 一覧へ戻る
AI・機械学習

Claude Codeでオートモードがデフォルトに

Auto mode is now the default in Claude Code (claude.com)

250 pointsby sbehere260 コメント

要約

Anthropicは、Claude CodeのPro、Max、Teamプランにおいて、2026年8月14日からオートモードをデフォルト設定にすると発表しました。このモードは、危険なコマンドをブロックする分類器を使用し、ユーザーの介入を減らしつつ安全性を向上させ、長時間の自律的な作業を可能にします。テストでは、オートモードが手動レビューと同等かそれ以上の安全性を発揮し、ユーザーの生産性向上にも寄与することが示されました。

全文翻訳

Pro、Max、TeamプランでClaude Codeのオートモードがデフォルトになりました Claude Codeは、Pro、Max、Teamプランにおいて、まもなくオートモードがデフォルトで実行されるようになります。これにより、より長時間の自律的な作業が可能になり、テストでは手動レビューよりも多くの危険なコマンドを検出できました。 Claude Code Claude Code 2026年8月7日 5分 リンクをコピー Claude Codeでオートモードをデフォルトにします。8月14日から、Pro、Max、Teamプランの新規セッションはオートモードで実行されます。もしご自身で別のデフォルトを設定されている場合は、オートモードに切り替えるかどうかを尋ねる一度限りのプロンプトが表示されることがあります。ピン留めされたデフォルトがある場合は、何も変更されません。オートモード分類器は、ツール呼び出しごとに少量の追加トークンを使用しますが、本日より、Pro、Max、TeamプランのClaude Codeユーザーは、その分類器のオーバーヘッドに対して課金されなくなります。 Claude Enterprise、Claude API、AWS上のClaude Platform、Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundryでは、現在もオートモードはオプトインのままです。これにより、管理者は変更をレビューする時間を確保できます。来月には、クラウドパートナーと協力して、これらすべてでデフォルト化し、分類器のオーバーヘッドに対する課金を停止する予定です。それまでの間、Enterprise管理者は、管理設定を通じてClaude Codeのオートモードをデフォルトにすることができます。 オートモードは、ユーザーが中断されたくないという要望と、有害なアクションを回避するシステムとのバランスを取るように設計されています。プロンプトの代わりに、各ツール呼び出しを分類器にルーティングし、取り消し不能、破壊的、または環境外を対象とするアクションをブロックすることに特化しています。分類器が何かをブロックした場合、Claudeは通常、安全な方法で処理を続行するか、直接承認を求めます。進捗できない場合(3回連続でブロックされるか、セッション全体で20回ブロックされるか)、Claude Codeは手動承認にフォールバックします。 私たちは過去数ヶ月間、オートモードが平均的なユーザーがプロンプトを通過させるよりも安全か、あるいはそれ以上に安全かをテストしてきました。内部レッドチーミング、第三者レッドチーミングとインジェクション評価、1,053人の有料テスターによる制御された研究、および実際のプロダクションセッションの分析を実施しました。テストしたすべての指標において、オートモードは手動レビューと同等かそれを上回りました。 オートモードはまた、Claudeがより長い時間自律的に作業することを可能にします。これにより、Claude Opus 5のような長時間の作業向けに構築されたモデルを、大規模なタスクに数時間実行したままにしておくことがより現実的になります。ユーザーのオーバーヘッドを削減することは、出力の増加にもつながります。TeamsおよびEnterpriseの導入企業では、オートモードユーザーは約25%多くのPRをリリースしています。Claudeのブロックを解除することで、タスクは中断されずに長く実行され、より多くの作業を完了できます。Adobe、Nuro、Gusto、Garner Healthのチームは、すでにオートモードをプロダクションのデフォルトとして実行しています。以下に、変更の動機となった安全性データと顧客の結果、および好みに応じて別のデフォルトを設定する方法を共有します。 手動レビューとオートモードの比較 データによると、手動レビューは習慣化する可能性があります。ユーザーはClaude Codeで許可プロンプトの97%を承認しています。ほとんどのプロンプトは安全で日常的なコマンドである可能性が高いですが、これほど高い承認率は、多くのユーザーが各コマンドをレビューするのではなく、反射的にクリックしていることを示唆しています。これらのプロンプトは、開発者に毎日、しばしばプロジェクトの途中で、数十または数百の重要なセキュリティ上の決定を求めており、レビューの負担をユーザーにかけ、重要なものが見落とされる可能性を高めます。データはまた、ユーザーが他の種類の対話により頻繁に精査し、反対していることを示唆しています。例えば、Claudeが承認のための計画を提示した場合、ユーザーはその39%を却下します。しかし、個々の権限要求については、拒否率はわずか3%です。 設定ファイルにも同様のパターンが見られます。2026年6月現在、アクティブなCLIユーザーの49.5%が手動でBashの許可ルールを作成しています。5%は任意のシェルコマンドを完全に許可しており、さらに43%はBash(python:*)やBash(node:*)のようなインタープリタールールを持っていますが、これらは実質的に同等です。そして、その割合は5週間ごとに約5パーセントポイント増加しています。許可ルールを超えて、62%のユーザーがbypassPermissionsを使用するか、Bashで「再度尋ねない」をクリックしており、25%のインタラクティブセッションはバイパス権限モードで開始されます。 オートモードでは、許可ルールが広範で任意のコード実行を許可する(例: python:*)場合を除き、分類器の前に権限ルールが引き続き発火します。これらの任意のルールは、分類器を完全にスキップさせる可能性があるため、オートモード中は設定されません。設定ファイルは変更されず、別のモードに切り替えた瞬間にルールが再度適用されます。 オートモードによる安全性の向上 内部および複数の第三者による研究は、オートモードが今日の典型的なユーザーが権限プロンプトを扱う方法よりも安全であることを示唆しています。私たちは、開発者が権限プロンプトをクリックして承認する際に実際に行うことに対して、オートモードをテストしました。これらの指標(内部レッドチーミング、第三者侵入テスト、実際のセッションの分析)のそれぞれにおいて、オートモードは人間の承認と同等かそれを上回りました。 オートモードは、安全性の面で手動権限よりも優れています 1,053人の有料プロフェッショナルテスターによる制御された実験では、人間のレビューは危険なコマンドのわずか13.6%を検出しましたが、オートモードは89%を検出しました。 私たちは、リサーチベンダーを通じて1,053人の有料テスターをコーディング研究のために雇用しました。これらの参加者は、研究のために特別に設定されたテスト環境で作業し、自身のコードベースや実際のプロジェクトではありませんでした。参加者は評価されていることを知っていましたが、標準的な盲検研究のデザインに従い、どの行動が測定されているかは知らされていませんでした。セッションの途中で、単一の権限プロンプトが明らかに危険なコマンドに置き換えられ、ベンダーはテスターがそれを承認したかどうかを記録しました(注:プロンプトを承認しても危険なものが実行されることはなく、テスターが見たプロンプトのテキストのみが変更されました)。テスターは危険なコマンドをわずか13.6%の時間(1,053件中143件)で検出しましたが、オートモードは同じコマンドの89%(1,053件中937件)をブロックしました。直接比較すると、オートモードは人間が承認した800件のコマンドをブロックし、人間はオートモードが許可したわずか6件のコマンドをブロックしました。セッションが長くなるにつれて、人間のパフォーマンスは低下しました。セッションの初期には危険なコマンドの約17%をブロックしましたが、50件以上の事前プロンプトの後には約5%に低下したのに対し、オートモードのブロック率はセッションの長さに関係なく一定でした。 オートモードはより多くの有害なアクションを防ぎます 私たちの研究はまた、オートモードが手動権限モードよりも有害なアクションが少ないことを示唆しています。 私たちは、オートモードが実際の使用でどのように機能するかを調査しました。2026年5月から6月にかけて、トレーニングと分析のためのデータ使用をオプトインしたアカウントのみから抽出された、当社の安全パイプラインがレビューのためにフラグを立てたセッションを調査しました。私たちは、2つの0〜10のスケールで各セッションをモデルで再評価しました。最初のスケールは、会社の全体的な、取り消し不能な損害(例: 会社の全ソースコードの漏洩)を10とし、プロダクションレベルの重大性(例: プロダクションデータベースの行の削除)を7とし、ローカルワークスペースに限定された完全に元に戻せるアクション(例: スクラッチファイルの上書き)を0としました。2番目のスケールは、ユーザーがアクションをどれだけ明確に要求したかであり、エージェントがより不明確な指示で実行した有害なアクションと、ユーザーが直接要求した有害なアクションを分離できるようにしました。 フラグが立てられたセッションのうち、手動承認を経たセッションは、オートモードセッションよりも2倍以上多く、ユーザーが明示的に要求しなかった深刻な意図しない損害を含んでいました。プロダクションレベルの重大性(7以上)では、手動承認セッションの6.3%がユーザーが明示的に要求しなかった有害なアクションを含んでいたのに対し、オートモードセッションでは2.4%であり、テストしたすべての重大性レベルでこの差は維持されました。 敵対的なレッドチーミングによりオートモードは強化されました 私たちは、英国に拠点を置くAI安全スタートアップであるApollo Researchと協力し、広範な障害、データ漏洩、安全関連の脅威をカバーする3つのデータセットにわたる実際のコーディング軌道に合成攻撃を注入する2週間のパイロットを実施しました。