コーディングエージェントの6つの失敗、Claude Codeの設定で防げるのはどこまでか

夜にClaude Codeを放置して、朝見たら確認待ちで止まっていた。そういう失敗は、設定でどこまで減らせるんでしょうか？ Michael Lynchさんが挙げたコーディングエージェントの6つの不満をClaude Codeの公式ドキュメントに1つずつ当てると、設定で防げるのが2つ、人が手を足して一部防げるのが2つ、設定の外か未確認なのが2つでした。

Why Are Coding Agents So Dumb?

Models are getting better and better, while the agents that drive them languish.

mtlynch.io

Overview - Claude Code Docs

Claude Code is an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools. Available in your terminal, IDE, desktop app, and browser.

code.claude.com

コーディングエージェントの6つの失敗を、Claude Codeに当てると？

原文は2026年10月9日の公開で、Claude Codeの失敗集ではありません。著者が試したのはClaude、Codex、OpenCode、Cline、Piの5つで、製品名が書かれていない項目も3つあります。取り違えないよう、原文で名指しされた製品も並べます。

鍵の件も、サンドボックスを破られた話とは違います。読めるファイルを制限する設定が見つからず、ドキュメントの勧めどおり「読まないで」と頼んだら即座に無視され、秘密鍵がOpenAIとAnthropicに送られた、という話でした。

著者は「設定を足せば済む」という反論を先回りして退けていて、最初から使えるべきだという立場です。なのでここでは、設定で埋まる穴と、設定を足す手間の両方を数えます。

1. 確認待ちで一晩止まる失敗は、ほぼ防げる

原文では、寝る前に長いタスクを渡したら、エージェントがgitのブランチ名を聞いたまま朝まで待っていました。僕が一番減らしたいのはこれですね。

Claude Codeでは、askUserQuestionTimeout を 60s、5m、10m のどれかにすると、答えていない質問が時間切れで閉じます。そのとき選択済みの選択肢を送り、「ユーザーは席を外しているかも」とClaudeに伝えて、Claudeが自分の判断で進めます。書く場所はユーザーの settings.json か、/config の「Question auto-continue timeout」の行です。

{
  "askUserQuestionTimeout": "10m"
}

穴は2つあります。バックグラウンドセッションと、Remote Controlに接続している間は、タイマーが始まりません。もう1つ、効くのは選択式の質問だけで、プランの承認を含む権限プロンプトは放置しても解決しないと公式は書いています。

スマホからRemote Controlで様子を見ながら寝ていませんか？ その間に出た質問は、朝まで待ちます。権限プロンプトのほうは、確認が要る操作をすべて拒否する dontAsk モードにすれば止まりません。代わりに、許可していない操作はできないまま進みます。待ちに早く気づきたいなら、Notification フックの permission_prompt（承認待ちが約6秒続いたとき）と idle_prompt（応答から約60秒入力がないとき）で通知を出せます。

2. 鍵の読み取りは、お願いでなくサンドボックスと権限で止める

ここは公式に仕組みがそろっています。ただ既定のままだと開いているので、書かないと何も変わりません。

permissions.deny に Read(./.env) を書くと、Claudeの組み込みのファイルツールに加えて、Bashの cat、head、tail、sed、tee やリダイレクト先にも効きます。一方で、grep -r pattern . のように名前を出さずに読むコマンドや、PythonやNodeのスクリプトが自分で開くファイルは対象外です。.claudeignore は効かないと公式が明記しています。

サンドボックスも、有効にしただけでは足りません。既定の読み取り範囲は「マシンの大半」で、~/.ssh や ~/.aws/credentials も含みます。しかも denyRead は組み込みのReadツールを止めないので、両方書く必要があります。下の例は、プロジェクトの .env を権限ルールで、ホームの鍵をサンドボックスで閉じる形です。

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./secrets/**)"]
  },
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws"]
    }
  }
}

サンドボックスの外で再試行する口は閉じられるのか？

原文は「エージェントはベンダーのサンドボックスを日常的に回避する」と書いていますが、手口までは書いていません。Claude Codeには、サンドボックス内で失敗したコマンドを、Claudeが dangerouslyDisableSandbox 付きで外で再試行できる口が公式に用意されています。一致する許可ルールがあると、この再試行は確認なしで通ります。

閉じるなら sandbox.allowUnsandboxedCommands を false にします。サンドボックスが起動できないときに素通しで動くのを防ぐ sandbox.failIfUnavailable も true にしておくと安心かも。ただ、サンドボックスの中で動かないコマンドはそこで行き止まりになるので、夜に止まる理由が1つ増えるのと引き換えです。

3. モデルの割り振りは、Claude Codeでも人が決める

原文の不満は、高いモデルで5万行のパターン検査をしていても、エージェントが「これは安いモデルで足りる」と言い出さないことでした。夜に回すタスクのうち、検索や集計だけの作業はどのくらいありますか？

Claude Codeのモデル指定は、/model、claude --model、環境変数 ANTHROPIC_MODEL、settingsの model など、どれも人が選ぶ形です。自動で切り替わる例としては、計画をOpus、実行をSonnetで回す opusplan があります。公式のコスト管理のページは、単純なサブエージェントの作業には model: haiku を指定するよう勧めています。

---
name: pattern-checker
description: 大量のファイルから決まったパターンを探す作業に使う
model: haiku
---

一度定義しておけば毎晩使えます。ただ、エージェントが自分から気づくようにはならないので、判定は「一部」です。

4. 並列化はClaude Codeに仕組みがあり、使うかはClaude次第

原文の例はOpenCodeで、約1,500行の機能を10個のサブタスクに分けたのに、1つずつ実行したという話です。Claude Codeについては、少しは並列にするものの、全部が終わるまで待ってから次へ進む、という書かれ方でした。

公式のサブエージェントは、既定で同時に20個、入れ子は3階層まで動かせます。定義に background: true や isolation: worktree も書けます。ただ、委譲するかどうかは各サブエージェントの description を見てClaudeが決めるので、並列を強制する設定はありません。

夜間放置で気をつけたいのは、バックグラウンドのサブエージェントの権限プロンプトがメインのセッションに出ることです。並列にしたぶん、止まる場所も増えます。

5. 自分の機能を聞くとWeb検索する問題は、Claude Codeでは確かめきれない

原文がClaude Codeを名指ししているのはここだけです。Claudeの機能を聞くとネットで調べ始める、13GBもダウンロードさせるのに50KBの説明書は同梱しないのか、という皮肉付きでした。

公式には claude-code-guide という組み込みのサブエージェントがあり、Haikuで動いてClaude Codeの機能についての質問に答える、とされています。ただ、これがWeb検索なしで答えるのかは、公式ページからは読み取れませんでした。ここは【要確認】です。

6. 計画の読みにくさは、Claude Codeの設定では防げない

原文の例はCodexとGPT-6 Astraの組み合わせで、計画が細かい設計判断の寄せ集めになっていた、という話です。plan modeや opusplan は計画を作らせる機能で、大枠から細部へという書き方を決める設定は見当たりませんでした。朝に止まっているかどうかとは別の話なので、夜間放置で先に手を付ける場所ではないですね。

夜間放置の前に、Claude Codeの設定で確かめる3つ

1. askUserQuestionTimeout を決める。Remote Controlとバックグラウンドセッションでは効かないと覚えておく
2. Read deny とサンドボックスの denyRead を両方書く
3. allowUnsandboxedCommands を false にするか、Bash(dangerouslyDisableSandbox:true) の確認ルールを足す。後者は確認が出るので、夜はそこで止まります

あなたの settings.json には、このうちいくつ入っていますか？

止まる失敗と漏れる失敗は設定で埋まりますが、どちらも既定では開いています。原文の「最初から使えるべき」はもっともで、それでも今夜の分は数行の設定で減らせます。

設定のキー名と挙動は、2026年10月12日時点の公式ドキュメント（ツール、権限、サンドボックス、サブエージェント）の記述によります。