自動実行が既定になったとき、設定を触らないことは何を選んだことになるか

金曜まで、実行の前に確認が出ていました。月曜の朝、同じ作業を始めると、確認が減っています。画面は止まらない。ログだけが流れます。

「設定は変えていない」。その一言が、一番危ないことがあります。

変えていないのに、進み方が変わっている。これは故障ではありません。既定が、向こうで書き換わっただけです。

2026年8月14日、自動が既定になった

Anthropicは2026年8月7日、Claude Code の auto mode を既定にすると発表しました（Auto mode is now the default in Claude Code）。適用は 8月14日。対象は Pro、Max、Team の新しいセッションです。

公式が書いている範囲は、次のとおりです。

• 自分で既定を決めていない人は、新しいセッションが auto mode で始まる
• 既定を自分で固定している人は、そのまま残る
• Team の管理者が既定を置いている場合は、その設定が優先される
• Enterprise と API、クラウド経由は、当面はオプトインのまま
• auto mode の判定に使う分類のトークンは、対象プランでは課金しない

できることが増えた、という発表ではありません。何もしなかった人の進み方が、変わった発表です。

同じ週には、考える量をスライダーで選べる更新も出ています（OpenAI、2026年8月6日、GPT-5.6 Sol の更新）。深さも、自動も、どちらも「選ばないと、向こうの既定で進む」方向へ寄っています。

承認範囲を決めていても、既定が変わると別の選択になる

承認なしで進めてよい範囲を決めた会社は、少なくありません。決めておくべきだ、という話も、すでに書いてきました（エージェントに任せる前に、承認なしで進めてよい範囲を決める）。

それでも、今回の変化は別の層にあります。

範囲を決めた時点の前提は、「自動にするかどうかを、人が選ぶ」でした。選ばなければ、確認が残る。確認が残るなら、危ないコマンドの前で止まれる。

既定が自動になると、選ばないことが自動を選んだことになります。範囲の紙は残っています。止まる位置が、紙の外へずれます。

止める条件を一つ決めておく、という話も近いです（エージェントが行動できる週に、先に決める止める条件は一つ）。条件は「本番へ出す前」「顧客データを触る前」など、仕事の境界です。今回足りないのは、仕事の境界ではありません。設定の境界です。

誰が既定を見るか。新しいセッションが、確認付きで始まるか、自動で始まるか。そこを見ていないと、止める条件は発動する前に通過します。

「触らない」は、安全側ではない

現場でよく聞く言葉があります。「よく分からない設定は、触らない」。

これは、機械が壊れない時代の知恵です。既定がこちらに有利だった頃は、正しく見えました。

既定が向こうの都合で動くと、触らないことは中立ではなくなります。自動で進む側へ、静かに倒れます。倒れたことに、本人は気づきません。設定画面を開いていないからです。

危険なコマンドを、auto mode のほうがよく止めた、という検証も公式にはあります。自動が乱暴だ、と決めつける話ではありません。問題は性能ではなく、会社が選んだことになっているかです。

選んでいない自動は、後から説明できません。何かが起きたとき、「設定は初期のままです」は、防御になりません。初期のまま進めた、という記録にしかなりません。

先に決めておく三つ

制度は要りません。画面の前で、三つだけ決めます。

1. 新しいセッションは、確認付きで始めるか、自動で始めるか

開発用の個人作業なら、自動でよい会社もあります。顧客データや本番に近い作業なら、確認を残すほうが説明しやすいです。両方を同じ既定にしない。作業の種類で分ける、と一文で足ります。

分けられないなら、確認付きを既定にします。自動のほうが速いのは分かっています。速さより先に、説明できる側を残します。

2. 既定を変える人の名前

Team なら、管理者が既定を置けます。置けても、誰が置くかが無いと、各自の画面が分かれます。分かれたまま一ヶ月経つと、同じ会社なのに進み方が違います。

名前は役職でなく、人の名前です。休みの週に代理を置くなら、それも一行です。エスカレーション先を決める話と、同じ型です（エージェントを本番に載せる前に、エスカレーション先の名前を決める）。

3. 既定が変わった週に、何を見直すか

モデルの更新、プランの更新、自動の既定。向こうは、こちらの会議を待ってくれません。待たない前提で、見直す場所を一つ決めておきます。

毎週全部を点検しなくてよいです。リリースノートを追う係も、作らなくてよいです。「自動に関する既定が変わったら、1番と2番を読み直す」。それだけで、触らないことが放置ではなくなります。

混在する現場ほど、既定の説明が要る

Pro や Team で自動が既定になり、Enterprise は当面オプトインのまま、という状態は、一つの会社の中でも分かれます。個人の有料プランで試している人と、会社契約で止めている人が、同じ案件に入ることがあります。

分かれたまま進むと、レビューのときに「なぜ確認が出ないのか」が個人の設定談義になります。設定談義は、仕事の話ではありません。仕事の話に戻すには、案件の種類ごとに既定を先に言っておく必要があります。

例を一つ置きます。社内の整理作業は自動でよい。顧客リポジトリに触る作業は、確認を残す。この二つを口頭で済ませると、翌週には忘れます。案件の最初のメッセージに、一行置く。それだけで、混在は説明できます。

「うちはまだ Enterprise だから大丈夫」は、今の話です。公式は、来月以降にこちらも既定へ寄せる予定だと書いています。今大丈夫な理由を、来月の設計にしないほうがよいです。今のうちに、1番と2番を書いておく。書いておけば、向こうが寄せてきた週に、読み返す場所があります。

何もしないことを、選択として残す

自動が便利な仕事は、確かにあります。長い修正、テストの繰り返し、ログの整理。人が毎回確認すると、確認そのものが形骸化します。形骸化した確認は、無いほうがましです。

だからこそ、自動にする仕事を先に書きます。書かない自動は、全部が自動に見えます。全部が自動に見えると、止める場所が分かりません。

tugiloが残したいのは、性能比較ではありません。設定を触らないことが、何を選んだことになるかです。

8月14日以降、Pro / Max / Team で新しいセッションを開く人は、すでに選んでいます。選んだつもりがなくても、選んだことになっています。

火曜の朝に残す一行は、短くて足ります。

自動のまま進めてよい仕事は、これだけ。それ以外の新しいセッションは、確認を残す。

この一行があれば、既定がまた変わっても、読み返す場所があります。無いと、次の月曜も「設定は変えていない」で終わります。変えていないのに、仕事の進み方だけが、静かに変わっていきます。

新しいセッションを開く前に、十秒だけ見る場所を決めておくと、この一行は定着します。見るのは、モデル名ではありません。確認が出るか、自動で進むか、その一点です。一点だけなら、毎週の点検にはなりません。点検にしないことが、続く理由です。