Claude Code の Auto Mode を1週間連続で実運用した結果、見えてきたのは「楽になる機能」というより「人間の役割が変わる機能」という側面だった。Anthropic は Auto Mode を「自律的な開発を可能にする中間モード」と位置付けており、--dangerously-skip-permissions よりは安全で、通常モードよりは確認の手間が少ない、という説明をしている。妥当な紹介ではあるが、現場で1週間回した実体感としては「中間」という表現よりも「人間の介入ポイントが事前確認から事後レビューへ移動する」と言った方が正確だ。本稿では Auto Mode の構造、計測値、向き不向き、チーム導入時の論点を実機ベースで整理する。
分類器の挟まる位置と実際のブロック率
Auto Mode は、ツール呼び出しの前段に分類器を置く構造になっている。実行直前のリクエストを評価し、破壊的な行為(大規模ファイル削除、機密データの送出、悪意あるコード実行など)を弾く。問題なさそうな操作はそのまま通り、リスキーと判定されたものはブロックされて Claude に「別の経路で」と促す挙動になる。
この分類器の精度がどの程度実用に耐えるかは、現場で叩いてみないと感覚がつかめない。筆者の手元では1週間で3,170回のツール呼び出しが発生し、そのうちブロックされたのは8回だった。誤検知っぽい挙動は1回のみ。具体的には CI 設定の見直し中に既存の .github/workflows ファイルを update→delete の2段階で書き換えようとして、delete の段階で止まった。安全側に倒した判断としては妥当な範囲で、ブロック後に別経路で書き換える誘導も自然だった。
人間の操作回数は27.3回から4.1回へ
通常モードでは、ターンごとに「これ実行していいですか」という確認プロンプトが入る。1時間に20回ほど挟まると、思考のリズムが切れる感覚は誰しも経験があるはずだ。Auto Mode に切り替えてから、自分が席を立ってもタスクが進む時間が増えた。具体的な計測値としては、平均1セッション(40〜90分)中の人間の操作回数が、計測したぶんで27.3回から4.1回に減った。
ただし、これを「楽になった」と単純化すべきではない。減ったのは中断回数で、確認すべき総量は減っていない。Auto Mode の真の使いこなしは、「終わってからまとめてレビュー」する能力にある。これはコードレビュー文化の発展形に近い構造で、PR に対する責任の取り方が、より事後レビュー寄りにシフトする。
安全に運用するための3つの設定
1週間で得た運用ノウハウを3点に整理する。
1点目は、必ず分離環境で動かすこと。Anthropic 公式も繰り返し書いている通り、Auto Mode はコンテナや専用マシンでの実行を推奨している。筆者は Git worktree を切って、専用ディレクトリで動かす運用にしている。失敗しても main には影響しない構造を、人間側の責任で先に作っておくのがポイントだ。
2点目は、--max-turns の設定。Auto Mode は黙々と動き続けるので、無限ループ的な挙動に陥らない上限を設けておきたい。筆者は20ターンで切っている。経験上、20を超えるタスクは、たいてい設計が悪い。タスクの粒度を見直すきっかけとしても、ターン上限は機能する。
3点目は、ログを後で grep できる構造にしておくこと。Auto Mode 中の挙動を読み返さないと、何が起きたか把握できなくなる。筆者は標準の transcript に加え、シェル側で tee してプロジェクト直下に保存している。少し冗長だが、レビュー時に圧倒的に助かる。
Auto Mode に向かないタスク3種
個人的な見解として、Auto Mode に向かないタスクが3つある。
ひとつ目は、要件が曖昧な探索的タスク。「このコードベース、どう改善すべきか」のような問いを Auto Mode に任せると、「とりあえず動く改善」を量産してくる傾向がある。ここは人間が要件を狭めるべき場所で、Auto Mode の射程外と考えた方が事故が少ない。
ふたつ目は、データベース変更を含む作業。リバート不能な操作はブロックされる場合とされない場合があり、運用上ヒヤッとする頻度がそれなりにある。筆者は DB 変更だけは手動モードに戻している。
3つ目は、外部 API のレート制限を消費する作業。Auto Mode は試行回数を増やすことで賢く動く構造なので、API コールも比例して増える。月の予算が決まっているチームは要注意で、利用枠の消費パターンが従来モードと別物になる前提で予算設計を組み直したい。
チーム導入で揉めた2つの論点
筆者のチームで Auto Mode を導入したとき、揉めた点が2つあった。
1つは「コードレビューの責任」。Auto Mode が書いたコードのレビューを誰が、どのタイミングで、どこまで深くやるか。これは事前にルールを決めておかないと、後から「A さんが見たと思っていた」のような事故が起きる。筆者のチームでは「Auto Mode 生成の PR はレビュー者を必ず1名指定、コミットメッセージに [auto-mode] プレフィックス必須」というルールにした。これで責任が曖昧にならない。
もう1つはコスト按分の議論。Auto Mode はターン数が多くなりがちで、API 消費が個人差で大きく開く。たとえば筆者の1週間の消費は同僚平均の約1.7倍だった。チームトータルでの予算管理を入れるか、個人別に上限を設けるか、運用設計の論点が増える。
Git worktree と Pre-commit フックとの相性
Auto Mode は Claude Code の機能だが、相性のいい外部ツールがいくつかある。試した範囲だと、Git worktree との相性が圧倒的に良い。worktree で分離環境を作り、Auto Mode を叩き、完了したら main に merge するか破棄するかを選ぶ流れが、シンプルかつ事故が少ない。
加えて、Pre-commit フックを併用すると安心感が増す。Auto Mode が暴走してフォーマットを崩しても、コミット直前に弾かれる。これは Vim 時代の「保存直前に formatter を走らせる」のと同じ発想で、安全網は重ねるほど効く。
1週間後の総括
過大評価されているとも、過小評価されているとも思わない。「人間が消える境界線」がクリアになる機能、と表現するのが一番近い。確認待ちが減ったぶん、レビューに集中する時間が増えた。これは Vim 時代の mapping で「打鍵数を減らした分、思考に回せた」のと構造が似ている。
ただし、すべての作業を任せる対象ではない。Auto Mode は「人間が並走する開発」の効率を上げる道具であって、「人間がいない開発」を実現する道具ではない。この境界感覚を持ったまま運用すれば、長く付き合える機能になるはずだ。
