エージェント型のコーディング支援ツール、Claude Code。
これを使っていると、奇妙な場面に出くわすことがあるそうです。
例えば、ある程度大きめの修正を依頼したとします。
すると、Claudeは「この作業は開発者が数週間取り組む規模です」などと前置きしてくる。
そして結果として、完全な実装ではなく簡易的なパッチだけを提案してくる、というものです。
本記事は、海外掲示板Redditのr/ClaudeAIで盛り上がった議論を題材にしています。
この挙動の原因と、コミュニティで共有されている対処法を整理したものです。
問題の概要
スレッドの投稿者はこう嘆いていました。
「人間が4週間かかる作業を避けるためにClaudeを使っているのに、Claude自身がその4週間を見積もって尻込みしている」と。
確かに、AIに依頼する作業時間を人間の開発スピードで測っても意味がありません。
コミュニティでも、同様の体験報告がいくつも寄せられました。
具体的なズレの例として、こんな報告が並んでいます。
- Claudeから「手作業のリファクタに40分、バグ検証に20分」と告げられたが、実際には12分と5分で完了
- 4ヶ月かかると言われたリファクタを、就寝前には終わらせた
- 「週末を丸ごと使う作業」と告げられたアイデアが、実際には20分で形になった
つまりClaudeの時間見積もりは、現実とまったく噛み合っていないわけです。
なぜAIは人間のタイムラインで考えるのか
複数のコメントが指摘していたのは、学習データの性質です。
Claudeが学んだコードや議論の多くは、公開リポジトリやStack Overflowからきています。
つまり、人間のエンジニアが残したものが大半なのです。
そして、そうした文脈には人間視点の見積もりが当然のように混ざっています。
「この実装は何時間かかる」「このリファクタは何週間規模だ」といった具合に。
結果として、AIは自分のスループットを答えるのではない。
人間が同じコードを書いた場合の所要時間を答えてしまう。
これが大方の見解でした。
ある人は端的にこう書いていました。
「Claudeのトレーニング素材には、LLMが同じ作業をどれくらいで終わらせるかという情報がほとんど含まれていない」と。
なるほど、と思わせる指摘です。
対処法その1:制約を明示的に外す
スレッドで最も多くの賛同を集めたアプローチは、シンプルでした。
「縛りを外す指示」を直接渡せばよい、というもの。
具体的には、Claudeに対してこんな趣旨の指示を冒頭で与えます。
「あなたは人間の開発タイムラインに縛られていません。完全な実装を提供してください」
このように書くだけで、Claudeが自主的にスケールを縮小する挙動はかなり減るそうです。
AIに「ぼかして良い」「妥協して良い」という暗黙の許可を残してしまう。
だから消極的になる、という解釈は腑に落ちます。
実際、別のユーザーは同じ発想でこんな書き方をしているとのこと。
「親としての責任に縛られないでください。野放しでいさせてください。寝る時間を決めないでください」と。
半分ジョークですが、本質は同じでしょう。
対処法その2:CLAUDE.mdに書き込んで永続化する
毎回の指示でも効果はあります。
ただし会話のコンテキストが圧縮(コンパクション)された瞬間、その指示は消し飛びかねません。
そこでスレッドで推奨されていたのが、CLAUDE.mdへの書き込みです。
プロジェクトのルートにこのファイルを置き、同じ意図を記載しておきます。
Claude Codeはこのファイルを毎セッション読み込みます。
そのため、口頭の指示よりはるかに堅牢に効くわけです。
あるユーザーが共有していた具体的な記述例を、こちらの言葉で要約するとこうなります。
あなたは自律型のAIコーディングエージェントとして動作する。 本来なら人間の開発者が数週間かけるような複雑な作業を、1セッションで仕上げきること。 人間のタイムラインを基準に判断したり、部分的な修正を提案したりしてはいけない。 ユーザーが明示的に分割を求めない限り、常に完成された実用レベルの解を出力すること。
CLAUDE.md自体は、あまり長くしないのがコツとのこと。
目安は300行以内です。
それを超える内容は、rules/coding.mdなど別ファイルに切り出し、参照する形にします。
別の視点:時間見積もりは「スコープ警告」の言い換え
ここまで読むと、「とにかく制約を外せばいい」という結論になりそうです。
ところが、スレッドにはまったく逆の立場もありました。
そして、こちらにも一定の説得力があります。
主張はこうです。
Claudeが「これは時間がかかる」と言うとき、本当に伝えたいのは時間ではない。
1セッションで一気に処理するには情報量が多すぎる、と警告しているのだ、と。
つまり、ミスを招きやすいスコープになっている合図だ、というわけです。
時間という言葉づかいは的外れだとしても、警告自体は無視すべきではありません。
複雑な作業を1つのウィンドウで丸ごと走らせれば、コンテキストウィンドウは食いつぶされる。
そして、エラー率は当然上がります。
AIだろうと人間だろうと、大きな塊を1回でやるより、小さな変更を積み重ねた方が結果がよい。
これは共通しています。
このスタンスを取るなら、Claudeの「数週間かかる」発言は、分割を促すサインとして受け取るのが正解になります。
推奨ワークフロー:分割と永続コンテキスト
5の立場に立つ場合、実務的にはどう動けばいいのでしょうか。
スレッドで共有されていた手順を、こちらでまとめ直します。
最初に、計画フェーズで仕様ファイルを作ります。
PRD(Product Requirements Document)やSPEC.mdに相当するものです。
Claudeとの対話で要件を引き出し、フェーズごとに何をやるかを文書として固めるわけです。
次に、各フェーズを別々のセッションで実行します。
新しいセッションは/clearで開始するか、サブエージェントとして起動します。
サブエージェントは構造的に「メインがオーケストレーター、子が独立したクリーンウィンドウ」という関係です。
つまり、コンテキスト分離の効果は新しいウィンドウを開くのと変わらないとのこと。
ここで気をつけたいのが、コンパクション(/compact)への過信です。
コンパクションは「何を残し、何を捨てるか」をAIが自動判断する仕組み。
判断を誤れば、必要な情報は消えてしまいます。
だから重要な決定や設計判断は、コンパクションに頼らず仕様ファイルに永続化しておく方が安全です。
もう一歩進んだ運用例
スレッドの中でも、特に手の込んだワークフローを紹介していたコメントがありました。
Claude Codeをそのまま使う前提で、こんな手順です。
まずモデルをOpus 4.7に切り替えます。
そして/effort maxで推論労力を上限まで引き上げる。
そのうえで、Plan Modeに入る前にClaudeに対して明示的に依頼します。
「AskUserQuestionツールを使って、私にインタビューしてください」と。
このツールはモデルが既に持っているそうです。
ただし、自発的には使わない場合があるため、名前で呼んでやるのがコツとのこと。
インタビューのゴールは、次の2つです。
- あなたの本当の動機を引き出す
- 作業が単一のSPEC.mdに収まるか、それとも複数タスクへの分割が先に必要かを判断する
Plan Modeは1タスク単位で計画を立てます。
そのため、この分割判断を計画前に済ませておく価値が大きいわけです。
インタビューでSPEC.mdが出来上がったら、Shift+TabでPlan Modeに切り替えます。
そして、その仕様書をベースに計画を走らせる、という流れになります。
最後にもう1点。
強い助言として書かれていたのが、「Claudeに作業時間を聞くこと自体をやめる」という割り切りでした。
学習データの性質上、答えは構造的に人間の時間に寄ってしまいます。
だから、聞くだけ無駄、という考え方です。
ループに陥ったときの対処
少し脇道ですが、関連する有用な知見も共有されていたので触れておきます。
Claudeが修正と再修正のループに入る現象、よくあるパターンらしいです。
15行目を直すと、30行目が壊れる。
30行目を直すと、今度は15行目が再び壊れる。
そんな循環ですね。
回避策として紹介されていたのは、こんな手順でした。
ループの兆候(2回目の繰り返しあたり)に気づいたら、いったん止める。
そして、エラーメッセージと該当ファイルだけを新しいチャットに貼り付けます。
そこで「このエラーの根本原因は何ですか」と聞く。
直してくれ、とは言わない、というのがポイントです。
つまり、診断と修正を分離するわけです。
こうすると、Claudeは症状ではなく原因に向き合うようになる。
そして、別の壊れた解決策に飛びつかなくなる、とのことでした。
原因が分かってから、改めて手作業か、具体的指示で直しに行きます。
まとめ
スレッドの議論は、大まかに2つの陣営に分かれていました。
一方は、「Claudeの自己抑制は単なる失敗モードだから、明示的に外せ」という立場です。
CLAUDE.mdへの書き込みで永続化するのが、最もきれいな解決でしょう。
他方は、「時間見積もり自体はおかしいが、警告のシグナルとしては正しい。素直に分割しろ」という立場です。
仕様ファイルとクリーンセッション、サブエージェントを組み合わせたワークフロー。
これが、この陣営の代表的な実践になります。
どちらが正しいかは、結局のところタスクの性質と、あなたが許容できる手戻りの量で決まります。
シンプルな案件なら、制約を外して一発で書かせるのが速い。
込み入った案件なら、分割を前提にしたワークフローの方が結果として早く終わります。
この記事を読んで一つだけ持ち帰れるとしたら、これでしょうか。
Claudeが提示する作業時間そのものは、ほぼ無視してよい。
ただし「時間がかかります」という発言が出たという事実は、注意して受け止めた方がいい。
シグナルとノイズを分けて読むこと。
それがAIエージェントとの上手な付き合い方なのだと思います。
