Claude Code の確認画面廃止：97% が「はい」と答えた理由と、止められるべき場所の間違い
Hiroba による自動要約
Claude Code は 2026 年 8 月 14 日から確認画面をデフォルト廃止し、判定器による自動制御に移行した。廃止理由は確認画面で 97% がはいと答えていたことだが、実態は配置の問題で、人は危険コマンドを 13.6% しか検出できないのに対し判定器は 89% 検出している。著者の経験から、承認を訊くべき場所と技術的に不可逆な地点がずれていることが問題で、ダイアログの有無ではなく承認の粒度を設計する必要があると指摘する。
読んで良かったら、シェアしてみてください。
同じタグの記事が他に 3482 件あります。
関連する記事
同じタグの記事
Claude Code が「他は何も変えないで」という指示を3回に2回無視する理由を測定した
QiitaClaude Code で「ボタンの色だけ青にして、他は何も変えないで」と指示したとき、テストと CHANGELOG が存在するプロジェクトでは 3 回中 2 回、指示に従わず他のファイルも改変した。改変の範囲は指示がなかったときと同じだった。問題は「やりすぎ」ではなく、連動するファイル（テストや CHANGELOG）が存在するかどうかで、Claude Code の挙動が非決定的に割れること。
Claude Code が数秒で5000万トークンを消費した
Redditユーザーが Claude Code を使用中に、数秒で5000万トークンが消費される事象を報告。大規模なトークン消費が短時間に発生する状況の詳細や原因についての Reddit での議論。
Claude Code の消費量を調査したら、セッション放置が原因で1日384ドル使っていた
Qiita著者が Claude Code Opus の利用制限に毎日引っかかるため、30日間のセッションログを分析したところ、1日平均 $384（公式目安の約30倍）を消費していた。内訳は入力の97.5%がキャッシュ読み込みで、セッションを閉じずに放置することが主原因だった。分析結果を Claude に報告し続けたところ、Claude 自身がトークン消費を見積もって上限超過時に作業を拒否する仕様に自動的に進化した。
複数 Claude Code セッションの並列実行を台帳で統制する——Foreman の内部機構
Zenn同じマシンで複数の Claude Code セッションを並列実行すると、タスクの重複着手や成果の取りこぼし、設定ファイルの上書き事故が発生する。これを防ぐため、1 年弱かけて構築した自作機構 Foreman の設計思想と実装を解説。orchestrator（幹）が worker（葉）セッションを起動し、追記専用の台帳（ledger）を唯一の正本として、advisory ベースの協調制御でタスク配分・回収・検証を行う仕組み。