Anthropic、Claude CodeのAuto Modeをデフォルトに

Anthropicは、同社の安全性分類器が開発者の意図をどこまで確実に理解できるかという未解決の疑問を抱えたまま、8月14日にClaude Codeをデフォルトでauto modeへ切り替える。対象はPro、Max、Teamアカウントの新規セッションだ。ユーザーはいつでも別の権限モードを選択できる。

この変更により、Claude Codeは日常的なコマンドやファイル操作のたびに人間の承認を求めなくなる。代わりに、独立した分類器がツール呼び出しを確認し、実行を許可できるか判断する。Anthropicによれば、リスクのある操作はブロックされるか、ユーザーへエスカレーションされる。

設定変更のようにも見えるが、これは重要な責任の移管だ。これまで開発者は多くの実行判断を自ら行ってきた。今後は、ユーザー、管理者、またはポリシールールが介入しない限り、Claude Codeがそれらの判断を行う。

TechCrunchが報じたように、この変更は利便性だけの問題ではない。重要な判断を見えにくくすることなく、長時間にわたる作業に十分な自律性を自動権限システムが提供できるかを試すものだ。OpenAI Codexや他のコーディングエージェントも、常時の監督なしにタスクを完了することをユーザーが期待する中で、同じ圧力に直面している。

Claude Codeは日常的な操作の前に毎回確認しなくなる

Anthropicは、頻繁な承認プロンプトを、操作ごとの自動化された権限判断に置き換える。

Claude Codeは、ファイルの読み取り、コードの編集、シェルコマンドの実行、外部サービスへのアクセス、開発インフラとの連携が可能なツールを通じて動作する。こうした機能により、単にコードを提案するのではなく、実際に作業を完了できる。

従来の権限モードでは、機密性の高いツール利用の前に人間によるチェックポイントが置かれる。この方式は想定外の挙動を抑える一方、多くの関連ステップを伴うタスクを中断させる。Claudeが次の確認を待つ状況では、開発者は大きな仕事を任せてその場を離れることが容易ではない。

auto modeは、ツール実行の前に分類器を挿入する。分類器とは、提案された操作を安全性と認可の文脈に基づいて分類するモデルだ。安全な操作は進められ、危険または不確実なものはブロックされるか、ユーザーに委ねられる。

Anthropicは3月24日、この機能を研究プレビューとして初めて導入した。当初のauto modeのリリースでは、保守的なプロンプトと--dangerously-skip-permissionsの中間に位置する仕組みとして説明されていた。後者は権限チェックを取り除くもので、隔離環境での利用のみを想定している。

この機能は7月に一般提供となった。Anthropicは現在、提供段階からデフォルト採用へ移行している。現在の設定ドキュメントによれば、新規セッションのデフォルトは8月14日に変更される。

この変更は、既存のすべての判断を上書きするものではない。ユーザーが一度限りの切り替えプロンプトを受け入れない限り、個人のデフォルト設定は維持される。組織管理下のデフォルトも変わらず、展開済み環境に対する管理者の統制が保たれる。

ユーザーはいつでもモードを変更できる。チームは、特定の操作を常に拒否したり、人間の承認を求めたりする明示的なルールも作成できる。これらのルールは分類器より先に実行されるため、auto modeがそれらを密かに回避することはできない。

デフォルトでは、分類器はアクティブなリポジトリの作業ディレクトリと設定済みリモートを信頼する。未知のリポジトリ、クラウドリソース、外部ドメインを含む操作は、より厳格に精査される可能性がある。組織は管理設定を通じて、信頼できるインフラを記述できる。

Claude Codeは、デフォルトポリシーの下でもリポジトリに変更をpushできる。ただし分類器は、force push、露出したシークレット、本番デプロイ経路といった文脈上の危険を評価する。

この違いは重要だ。自動化は二者択一ではない。エージェントにはテストやローカル編集で広い自律性を与えつつ、リリースや外部システムに関しては厳格なチェックポイントを維持できる。安全境界は、モデルの挙動と同じくらい設定に左右される。

Anthropicはまた、ツール呼び出しに追加の分類が必要になるため、auto modeがレイテンシーとトークン使用量に影響する可能性があると警告している。開発者の中断は減るが、サービスは承認された各操作の背後でより多くの自動推論を実行する。

当面の利点は明確だ。Claude Codeは、テストスイートを実行し、失敗を調査し、ファイルを変更し、そのサイクルを各コマンドの後で止まることなく繰り返せる。これにより、無人での作業がより実用的になる。

より深い変化は見えにくい。開発者は、すべての中間判断を目にすることなく、エージェントが完了した結果を見る場面が多くなる。そのためレビューは、継続的な認可からポリシー設計と成果物の検査へと移る。

AnthropicとTechCrunchの記事が一つの設定変更を超えて重要な理由

デフォルト設定は、とくに権限を一度もカスタマイズしないユーザーにとって、通常の挙動を決める。

オプション機能は製品が何をできるかを示す。デフォルト設定は、そのメーカーが大半の人にどのように使ってほしいと考えているかを示す。Anthropicは、監督付きでプロンプトごとに進めるコーディングを、もはや望ましい標準とは見なしていないことを示している。

同社には中断をなくす強い動機がある。コーディングエージェントは、応答品質だけでなく完了した作業で競争している。正確なコードを書くが承認待ちを繰り返すシステムは、開発者がそばにいなければ長いタスクを処理できない。

承認疲れも別の問題を生む。過剰なプロンプトに遭遇するユーザーは、機械的に承認したり、安全策を完全に無効化したりする可能性がある。どちらの反応も、慎重な人間の監督にはつながらない。

auto modeは、こうした弱いチェックポイントを一貫した自動レビューに置き換えようとする。分類器は会話と提案された操作を受け取り、実行がユーザーの依頼に沿っているかを問う。疲労や焦りに左右されず、各操作を評価できる。

Anthropicは、この手法が権限を完全にスキップするよりもリスクが低いとしている。同時に、分類器がリスクをなくすことはできないとも認めている。曖昧な意図や不完全な環境コンテキストは、依然として誤った判断を招き得る。

anthropic techcrunchの論点は人間の監督が減ることにあるが、その根底にある賭けはより具体的だ。Anthropicは、習慣的な人間のクリックより安全でありながら、手動承認より制約が少ない自動監督が可能だと考えている。

この主張は、責任あるエージェントに関する一般的な前提に異議を唱える。人間の関与が、必ずしも意味のある統制を生むわけではない。予測可能なコマンドを何十件も承認する人は、実質的な判断をほとんど加えていないかもしれない。

有用な監督は、適切なタイミングで行われなければならない。開発者は実行前に境界を定義し、本当に不確実な操作についてプロンプトを受け取り、重要なデプロイ手順の前に変更を検査すべきだ。絶え間ない中断は、これら三つの慣行すべてを弱めかねない。

この新しいデフォルトは、競合するコーディングエージェントに対し、自律性と統制をより説得力のある形で両立させるよう圧力をかける。OpenAI Codex、GitHub Copilot、ターミナルベースのエージェントはいずれも、一度のコード補完を超えるワークフローをめぐって競争している。

ユーザーはますます、エージェントにバグの調査、依存関係の更新、テストの実行、pull requestの準備を求めている。これらの仕事には多くのツール呼び出しが必要だ。すべての段階で承認を要求する製品は、モデルに能力があっても遅く感じられる可能性がある。

一方で、あらゆる摩擦を取り除く製品は、ローカルファイル、認証情報、ソースリポジトリ、接続済みサービスを危険にさらす可能性がある。競争上の問いは、どのエージェントが最も独立して行動するかではない。独立して行動しながら、どのエージェントが理解可能な境界を強制できるかだ。

エンタープライズの購入者は、この変更の別の層を精査する。必要なのは、中央管理されたポリシー、監査証跡、予測可能なプロバイダーサポート、明確な障害時の挙動だ。便利な個人向けデフォルトが、これらの要件を自動的に満たすわけではない。

Anthropicのドキュメントでは、管理者がgit pushやpull request作成などのコマンドに承認を必須とすることができる。チームは、自律的なローカル作業を許可しつつ、これらのチェックポイントを維持できる。

このポリシー優先のアプローチは、確立されたインフラ統制に似ている。組織は、日常的な操作を一つひとつ承認するのではなく、ソフトウェアIDに定義済みの権限を与える。コーディングエージェントの場合、意図する操作が動的に生成されるため、このモデルは複雑になる。

固定されたデプロイスクリプトとは異なり、エージェントはコマンドが失敗した際に即興で対応できる。ツールを切り替えたり、状態ファイルを編集したり、要求された結果に向けた別の経路を見つけたりするかもしれない。この柔軟性はエージェントを有用にするが、強制も複雑にする。

デフォルト変更により、分類器はより多くの通常ワークロードにさらされる。採用が広がれば、誤検知、見逃された危険、分かりにくいプロンプトに関する証拠がAnthropicに多く集まる。同時に、体系的な弱点がもたらす影響も大きくなる。

自動権限チェックが継続的な人間の承認に代わる

中心となるトレードオフは、意味のないプロンプトが減る一方で、モデルベースの安全ゲートへの依存が強まることだ。

Claude Codeの権限システムは、操作を異なる経路に分ける。読み取り専用の操作は、事前定義されたルールに従って実行できる。プロジェクト内の一部の編集も完全な分類器を回避する一方、よりリスクの高いツールにはモデルベースの評価が適用される。

分類器が考慮するのはコマンドテキストだけではない。会話、要求されたタスク、現在の環境、提案された操作を利用できる。このコンテキストは、依頼されたファイル変更と、説明のない破壊的コマンドを区別するのに役立つ。

Anthropicは二段階設計を説明している。高速な第一段階では、潜在的にリスクのある挙動を特定することを目指す。第二の推論段階では、フラグが付いた操作をレビューし、不必要なブロックを減らす。

この設計は、競合する二種類のエラーを制御しようとする。偽陽性は安全な操作をブロックし、有用な作業を中断させる。偽陰性は、本来止めるべき操作を許可する。

一方のエラーを減らすと、もう一方が増える可能性がある。極めて慎重なゲートは煩わしくなり、寛容なゲートはより多くのリスクを受け入れることで速度を維持する。単一のしきい値で、すべての環境のニーズを解決することはできない。

そのため、安全性の負担の多くは設定にかかっている。Anthropicは組織に対し、信頼できるリポジトリ、ストレージリソース、ドメインを定義させる。チームは明示的な許可、拒否、確認ルールも設定できる。

明示的な確認ルールは、選択した操作に人間のチェックポイントを維持する。たとえばチームは、ローカルのテストと編集を許可しながら、リポジトリへのすべてのpushの前に承認を求められる。別のチームは、エージェントセッションからの本番デプロイをすべてブロックするかもしれない。

分類器は、明示的な拒否を上書きできない。これにより、管理者はモデルの判断より上位にある決定論的な層を得られる。また、ユーザーが無人セッションに依存し始める前に、セキュアな展開には意図的なポリシー作業が必要であることも意味する。

Claude Codeのドキュメントは、狭いシェルルールに関する微妙な懸念を指摘している。一部の許可ルールは、その形式と設定によっては、分類より先に解決される可能性がある。承認されたコマンド接頭辞が、ポリシー作成者の想定しなかった引数を受け入れることがあり得る。

組織は代わりに、すべてのシェルコマンドを分類に通すことができる。これによりカバレッジは広がるが、レイテンシーと分類器の呼び出しが増える。チームは、決定論的なルールをどこで終え、文脈に基づくレビューをどこから始めるかを選ばなければならない。

この選択は、auto modeが単なるオンの切り替えではない理由を示している。静的ポリシー、信頼済み環境の定義、ツールカテゴリー、モデルの判断を組み合わせるものだ。どの層の弱点も、予期しない経路を生み出し得る。

開発者にとって、実務上のワークフローは各ステップを承認することから、安全なワークスペースを設計することへと変わる。エージェントの稼働時間が長くなるほど、分離されたブランチ、限定された認証情報、スコープを絞ったトークン、保護されたデプロイシステムの重要性は増す。

リポジトリのレビューは引き続き不可欠だ。Auto modeが判断するのは、提案された操作が承認済みと見なせるかどうかであり、生成されたすべての行が正しいかどうかではない。許可された変更でも、バグの混入、パフォーマンス低下、要件の誤解につながる可能性がある。

同じ区別はテストにも当てはまる。テストの通過は定義済みの動作に関する証拠を示すが、意図の正しさを保証するものではない。自律型エージェントは、不完全なテストスイートを満たしながら、テストされていないパスを損なうことがある。

開発者は、分類器を絶対的な監督者ではなく、一つの制御手段として扱うべきだ。バージョン管理、保護ブランチ、サンドボックス実行、シークレット管理、継続的インテグレーション、人間によるレビューは、依然として異なる障害モードに対処する。

こうした制御が相互に補強し合うとき、システムは最も有用になる。Auto modeは、制約されたワークスペース内で繰り返し発生するプロンプトを減らせる。その後、既存のエンジニアリング上の制御が、ミスが顧客に届く前に検出できる。

このパターンは、チームがAIコーディング製品を評価する方法も変える。モデルのベンチマークはコード生成を測定するが、安全な実行についてはほとんど明らかにしない。エージェントの評価には、権限、復旧時の挙動、ポリシーの明確さ、監査可能性を含める必要がある。

安全性の証拠だけでは議論は決着しない

独立したテストは、認可が意図的に曖昧な場合、性能が大きく変動し得ることを示している。

Anthropicは、過剰に行動しようとする操作に関わる特定の本番ケースについて、0.4パーセントの偽陽性率と17パーセントの偽陰性率を報告している。これらの測定値は、エージェントが支援しようとして誤って認可を超えたインシデントを示すものだ。

4月に発表された独立した論文は、別の問題を検証した。著者らは曖昧なDevOps要求を扱う128件のプロンプトを作成し、状態を変更する253件の操作を評価した。彼らのpermission-gate studyは、不明確なスコープ、対象選択、運用リスクに意図的に負荷をかけた。

研究者らは、このストレステスト設計においてエンドツーエンドの偽陰性率が81パーセントだったと報告した。分類器が直接評価した操作のうち、報告された偽陰性率は70.3パーセントだった。また、そのサブセットでは31.9パーセントの偽陽性率も確認された。

これらの数値を、Anthropicの本番環境における測定値への直接的な反論として提示すべきではない。この論文は意図的に敵対的な曖昧さを用いた一方、Anthropicは本番トラフィックにおけるより限定的なパターンを測定した。異なるワークロードでは、結果が大幅に異なる可能性がある。

それでもこの研究は、重要な境界を示している。プロジェクト内の一部のファイル編集は、主要な分類器を通過しなかったことが分かった。エージェントは、想定されたシェルコマンドを使う代わりに状態ファイルを編集することで、場合によっては運用上の効果を達成できた。

アーティファクトのクリーンアップ作業では、研究者らは92.9パーセントの偽陰性率を報告した。この結果は、セキュリティ分析では危険そうに見えるコマンド文字列だけでなく、ツールをまたいだ同等の結果も検証する必要があることを示唆している。

このベンチマークも、制御されたツールを備えた分離コンテナ内で実行された。実際の開発環境には、より多様なリポジトリ、認証情報、サービス、組織ポリシーが存在する。その複雑さは、防御策にも追加の障害経路にもなり得る。

別のセキュリティ上の懸念として、信頼できないテキストがエージェントの行動を逸らそうとするプロンプトインジェクションがある。コーディングエージェントは、ドキュメント、依存関係ファイル、Issueの説明、ログ、ソースコメントを日常的に読む。こうした接点のいずれにも、敵対的な指示が含まれる可能性がある。

7月の概念実証では、悪意ある指示がオープンソースプロジェクトのファイル内に埋め込まれたと報じられた。Friendly Fire attackの報道によれば、テスト対象のエージェントは自動化されたセキュリティ作業中に、攻撃者が制御するバイナリを実行できた。

この実証は、Claude CodeとOpenAI Codexを含む構成に影響したと報じられている。その重要性は単純なベンダー比較ではなく、共通する仕組みにある。エージェントは信頼できない素材を読み、同時にホスト上で操作できるツールも持つ。

Anthropicの分類器は、悪意ある実行とデータ流出を検出することを目的としている。しかし、プロンプトインジェクションにより、有害な操作が割り当てられたタスクに関連しているように見えることがある。システムは、実際のユーザー意図と実行中に見つかった指示を区別しなければならない。

エージェントがより多くのコンテキストとツールを得るほど、この問題は難しくなる。長時間のタスクでは、数百件の観察や中間的な選択が伴う可能性がある。権限ゲートは、その一連の流れを通じて元の認可境界を維持する必要がある。

偽陽性も重要だ。分類器が安全な操作を過度にブロックすると、開発者はauto modeへの信頼を失う可能性がある。生産性を回復するために、手動プロンプトへ戻ったり、ポリシーを弱めたりするかもしれない。

サービスの可用性も別の運用上の懸念だ。Auto modeは分類器へのアクセスに依存している。そのコンポーネントが利用不能または低速になった場合、組織には暗黙のポリシー変更ではなく、予測可能なフォールバック動作が必要になる。

Anthropicのドキュメントによれば、操作の安全性を判断できない場合、システムは特定のエラーを出すことがある。不確実なときにブロックする方が、操作を黙って承認するより安全だが、無人の作業は停止する可能性がある。

したがって、Anthropicを扱うTechCrunchの記事は、auto modeが安全な開発から人間を排除すると主張すべきではない。人間の関与は、ワークスペース設計、明示的なポリシー、レビュー手順、例外処理へと移る。

また、すべての独立ベンチマークの結果を普遍的なものとして扱うべきでもない。意図的に曖昧なテストは、境界上の脆弱性を明らかにする。それらは、通常のすべてのコーディングセッションのエラー率を測定するものではない。

責任ある結論には条件が付く。Auto modeは低価値な中断を減らせるが、その安全性は分類器のカバレッジと環境上の制約に依存する。ユーザーには、自身のリポジトリとワークフローから得た証拠が必要だ。

Anthropicのデフォルト設定はエンジニアリングチームに判断を迫る

製品のデフォルトによってその判断が日常的に感じられる前に、チームはどの操作を自動化に委ねるべきか決めなければならない。

個々の開発者は素早くモードを切り替えられる。組織はより広範なガバナンス課題に直面する。なぜなら、1つのエージェントセッションが共有リポジトリ、社内パッケージ、クラウドサービス、デプロイシステムに触れる可能性があるからだ。

最初の判断は境界に関するものだ。チームは、本番リリース、認証情報の変更、破壊的なデータベース操作、保護されたインフラへの変更など、常に人間の承認を必要とすべき操作を特定すべきだ。

二つ目は環境の信頼性に関するものだ。Claude Codeには有用な作業を完了するのに十分なアクセスが必要だが、開発者のマシンで利用可能なすべての認証情報を継承すべきではない。スコープを絞った認証情報は、誤った判断の影響を限定する。

三つ目はレビューに関するものだ。チームは、自律的な実行と自律的な受け入れを区別する必要がある。エージェントは変更を独立して準備できるが、ブランチ保護とコードレビューは引き続き統合を制御できる。

これらの制御により、auto modeによる生産性向上の大部分を維持できる。Claude Codeは障害を調査し、コードを修正し、テストを実行し、プルリクエストを下書きできる。その後、人間は意味のある境界で生じた変更をレビューできる。

ただし、エージェントがより大きな変更をより速く生成すると、レビューの質は低下する可能性がある。開発者はコードを書く時間を減らし、不慣れな出力を検証する時間を増やすかもしれない。この作業には、コンテキスト、注意力、信頼できる証拠が必要だ。

生成されたプルリクエストには、意図、変更後の挙動、テスト、未解決のリスクを説明させるべきだ。チームには、エージェントが使用したコマンドとツールを示すログも必要になる。最終的なdiffだけでは、重要な中間操作が隠れる可能性がある。

組織は、広範に展開する前に代表的なリポジトリでauto modeをテストすべきだ。単純なアプリケーションと本番インフラのリポジトリでは、結果の重大さが異なる。単一のグローバルポリシーが両方に適合する可能性は低い。

段階的な展開は、ローカル開発、使い捨てブランチ、非本番の認証情報から始められる。チームは、拒否された操作、予想外の承認、タスク完了率、レビューでの発見事項を記録できる。

こうした観察は、AI安全性に対する一般的な信頼よりも強固な根拠となる。権限システムが成功するのは、特定の組織の認可モデルに適合したときだ。モデル品質だけで、そのモデルを定義することはできない。

セキュリティチームは、敵対的なリポジトリコンテンツについてもテストすべきだ。現実的な演習では、ドキュメントや依存関係アーティファクトに矛盾する指示を配置できる。目的は、既存の制御がエージェントの応答を封じ込められるかを知ることだ。

開発者には明確な退避経路が必要だ。権限モードの切り替え方法、現在有効な構成の確認方法、組織が管理するルールの識別方法を把握しておくべきだ。意図が健全であっても、隠れたデフォルトは信頼を損なう。

Anthropicは、有効なauto-mode構成を表示するコマンドを提供している。この可視性は、チームが組み込みの挙動と自らのポリシーを比較する助けになる。また、ある操作が予期せずブロックまたは許可された際のインシデント分析も支援する。

競合他社も同様の要求に直面する。OpenAI、GitHub、Google、独立系コーディングエージェントの開発者は、自社システムが認可をどう解釈するか説明しなければならない。ユーザーに必要なのは、危険な行動が監視されているという一般的な約束だけではない。

意味のある比較では、いくつかの問いを検討すべきだ。どの操作が文脈的な分類を迂回するのか。管理者はプロンプトを強制できるのか。分類器の障害時には何が起きるのか。外部ドメインとリポジトリのリモートはどう扱われるのか。

その答えによって、エージェントが隔離されたワークスペースだけで使うべきなのか、エンタープライズの開発プロセス内で運用できるのかが決まる。また、ユーザーが実際にどれほどの監督権を手放すかも決まる。

開発チームを支援するナレッジワーカーにとって、この変化は検索可能な意思決定記録の価値を高める。要件、レビューコメント、インシデントの知見は、生成された変更と結び付いた状態を保たなければならない。searchable engineering baseは、そのコンテキストの維持に役立つ。

ここでauto modeが変えるのは、入力速度だけではない。人間によるチェックポイントの間に完了する操作の量を増やす。チームはそれに追いつくため、チェックポイントの質を高めなければならない。

Auto Modeがデフォルトになった後に注目すべきこと

Anthropicが認可の失敗を検出しにくくせずに承認の摩擦を減らしたかどうかは、3つのシグナルで分かる。

最初のシグナルは、8月14日以降のデフォルトモードの採用状況だ。Anthropicは、対象となるユーザーのうち何人がこの切り替えを受け入れるかを公表していない。継続的な利用は、開発者が通常の作業において分類器を信頼できると感じているかを示す。

採用だけで安全性の証明にはならない。設定を変えるには手間がかかるため、ユーザーはデフォルトを維持しがちだ。しかし、頻繁な手動切り替え、管理者による無効化、繰り返される不満は、Anthropicの自動監督に関する主張を弱めるだろう。

二つ目のシグナルは、より幅広い評価における分類器の性能だ。研究者は、現実的なリポジトリ、混在するツール経路、プロンプトインジェクション、曖昧な運用リクエストをテストすべきだ。読者が責任を持って比較できるよう、結果には明確なワークロードの説明が必要になる。

Anthropicは、誤った承認と不要なブロックに関する最新の測定値を公開することで信頼を強められる。また、どのツールカテゴリーが分類の対象となり、どのカテゴリーが決定論的ルールに依存するのかも説明すべきだ。

独立した再現検証が重要なのは、研究室での測定と本番環境での測定が異なる問いに答えるためだ。本番データは一般的な挙動を捉える。ストレステストは、通常のトラフィックでは深刻な結果を招くまでほとんど表面化しない可能性がある障害をあぶり出す。

3つ目のシグナルは、競合他社が自社の権限システムをどのように再設計するかだ。コンテキストに応じたポリシー認識型の実行へ向かう動きは、Anthropicの方向性を裏付ける。一方、より強力なサンドボックス化や必須チェックポイントへの移行は、そのバランスに疑問を投げかけるだろう。

マーケティング上の呼称ではなく、製品の詳細に注目すべきだ。「自律的」という言葉は、多様な権限設定を指し得る。重要なのは、ツールの対象範囲、管理者による制御、監査記録、外部アクセス、安全に失敗する挙動に関する問いである。

競合の一社は、環境をより積極的に制限することで、確認プロンプトを減らすかもしれない。別の企業は、より広範な操作を認めつつ、デプロイ時の承認を求める可能性がある。こうした設計は、同じ自律性の問題に対する異なる回答を示している。

ユーザーがセキュリティインシデントやポリシー上の混乱を増やすことなく、より長いタスクを完了できれば、最新のanthropic techcrunchイベントはより説得力を増すだろう。説明のない承認、拒否、あるいは分類器の障害を受けて、チームが日常的に自動モードを無効化するようなら、その評価は弱まる。

開発者は、普遍的な結論を待つべきではない。使い捨ての環境内でシステムを評価し、保護された統合ポイントを維持し、実際のタスクに対する挙動を測定できる。

まずは1つのリポジトリと、慎重に範囲を定めた1つのワークフローから始めよう。どの操作が進み、どの操作が停止したか、そして最終的な変更が当初の依頼に一致しているかを記録する。その上で、より広い自律性が正当化されるかを判断すればよい。

有用な問いは、Claude Codeが完全な信頼に値するかどうかではない。成熟したシステムでは、開発者、スクリプト、エージェントのいずれにも無制限の信頼は与えられない。問うべきなのは、その自動ゲートが明確かつ限定的な権限付与を強制できるかどうかだ。

Anthropicは、その答えが今後ますます「はい」になると賭けている。デフォルトのスイッチは、開発者の定常的な監督作業を減らす一方で、ポリシー設計の重要性を高める。全員が席を離れた後もエージェントの作業継続を認める前に、あなたのチームはどのような境界を求めるだろうか。