5分タスクと数日タスクは別物 — Claude Code をタスク粒度で使い分ける

同じツール、違う使い方

Claude Code を使い始めて最初に気づくのは、「うまくいくとき」と「なんかもたつくとき」の差が大きいことだ。

同じ Claude Code なのに、TypeScript のエラーメッセージを聞いたらすぐ答えが返ってくる。でも、「この API モジュールをリファクタして」と頼んだら途中で脈絡がなくなってきて、最終的に手直しが増えた——という経験をしたことがある人は多いと思う。

この差の多くは、機能の使い方や Claude の限界ではなく、タスクの粒度に対してアプローチが合っていないことが原因だ。5分で終わる作業と数日かかる作業では、プロンプトの設計も、コンテキストの管理も、中断戦略も、まるで変わる。同じ「Claude Code を使う」という行為に見えて、実態は別の仕事をしている。

本記事では、タスクを「〜5分 / 〜30分 / 〜半日 / 〜数日」の4段階に分けて、それぞれの最適なアプローチとハマりやすいパターンを整理する。

5分タスク — one-shot で完結

5分以内で終わるタスクの典型は、エラーメッセージの読解、コマンドのオプション確認、短いスニペットの抽出といったものだ。

このレベルでは、Plan Mode は不要どころか邪魔になる。Shift+Tab で計画を立てさせようとすると、Claude はまず「現在のコードベースを確認します」と言ってファイルを開き始め、5分のはずが15分になる。one-shot で質問を投げて、返ってきた答えを受け取る。それで十分だ。

コンテキストの追加も最小限でいい。--add-dir で外部ディレクトリを読み込ませるような操作は、このスケールでは確実にオーバーヘッドになる。「なんで遅いんだろう」と感じたとき、不要なコンテキストを渡していないか確認してほしい。

Usage の上限という観点では、5分タスク単体はほぼ影響しない。気にしなくていい。ただし、1日に同じことを100回繰り返していたら話が変わってくる。それはもはや「5分タスクを繰り返している」ではなく、自動化か30分タスクへの統合を検討すべきサインだ。

30分タスク — Default mode の作法

1〜2ファイルにまたがるバグ修正、簡単なテストケースの追加、設定ファイルの構造変更。このあたりが30分タスクの射程だ。

Default モードで会話を進めながら、変更が複数ファイルにまたがる場合は acceptEdits（編集の自動承認）を有効にすると、承認確認のやり取りが減って集中しやすい。

私がこのスケールで最も意識しているのは、スコープクリープの検知だ。「30分のつもりが2時間になっている」という状況は、タスクが半日スケールに膨らんでいるサインで、アプローチを切り替えるタイミングを逃していることが多い。30分を過ぎたら /usage で進捗を確認して、「このまま続けるか、Plan Mode に切り替えるか」を判断する習慣をつけると、後半のぐだつきが減る。

コンテキストが散らかったまま進めることも避けたい。あとで「何をどうしたんだっけ」とセッション履歴を追うより、節目で自分の中の整理を言語化して Claude に渡す方が、最終的な品質が上がる。

半日タスク — Plan Mode + Auto Mode の本領

API の追加とテストとドキュメントをまとめて仕上げる。数十ファイルにまたがる中規模リファクタ。レガシーコードを読み解いて設計を提案する。こういった作業が2〜4時間のスケールに収まる。

このスケールでは、Plan Mode への先行投資が必ず回収される。Shift+Tab で計画を立てずに実装に入ると、途中で「あの部分どうするんだっけ」という迷いが生まれて、手戻りが大きくなる。面倒に感じても、先に計画を確認・修正してから動かした方がトータルの時間は短い。体感として、最初の5分が後半の1時間を決める。

もう一つ半日タスクで効くのが Auto Mode だ。Claude が提案するたびに承認を求めてくる通常の動作を、ある程度自動で進む設定に切り替える。承認疲れが軽減されて、作業の流れが途切れにくくなる。詳細はAuto Mode の記事を参照してほしい。

コンテキスト管理では、使用率が70%を超えたら /compact で圧縮するのが目安だ。放置すると品質が落ち始める。また、git add でこまめに変更をステージして「戻れる地点」を作っておくことも忘れずに。失敗したときに「あの時点まで戻れる」という安心感が、思い切った試行を可能にする。

コスト面では、Opus 4.7 を使った半日タスク1セッションで $5〜10 程度かかることがある（あくまで目安で、ファイル規模や操作の複雑さによって変動する）。Pro プランで2セッション続けると上限に近づく可能性があるため、このスケールを頻繁に使う場合は Max プランの検討が現実的だ。

数日タスク — /goal・worktree・knowledge/

レガシースタックからモダンスタックへの大規模移行、新機能の探索から実装まで、複数リポジトリにまたがる横断変更。このスケールになると、1セッションで完結させようとすること自体が間違いになる。

数日タスクに必要なのは、セッションをまたいでも状態が引き継がれる仕組みだ。

/goal コマンドは完了条件を明示して Claude に継続させる機能で、セッションをまたいだ作業の一貫性を保つのに役立つ。詳細は/goal コマンドの記事で書いた。

並列で複数のタスクを進めるなら git worktree の分割が効く。worktree なしで並列作業をするとファイルが衝突する。ブランチごとに worktree を切り、それぞれを独立した作業空間として扱う。複数の Subagent を同時に走らせているときは Agent View で進捗を一覧管理できる。

数日タスクで最も見落とされがちなのが knowledge/ の活用だ。試行のたびに発見したパターン、ハマりどころ、判断の経緯を knowledge/ に書き起こしておくと、次のセッションで Claude がそれを参照して判断の質が上がる。/compact だけに頼っていると、重要な決定の文脈が失われる。詳細はknowledge/ の詳解記事を参照してほしい。

コスト効率の観点では、Prompt Caching の設定が効いてくる。tool 定義とシステムプロンプトを固定して、メッセージで状態を更新する設計にするとキャッシュヒット率が上がり、複数セッションにわたるコストを抑えられる。モデルを Opus と Sonnet の間で頻繁に切り替えるとキャッシュがリセットされるため、モデルは一貫して使うことをすすめる。

粒度を誤ったときの症状

タスクに対してアプローチが合っていないとき、いくつかの症状が出る。

「短いタスクなのに重い」と感じるときは、Plan Mode を使いすぎているか、不要な外部ディレクトリを追加していることが多い。5分で終わるはずの質問が15分かかっているなら、ツールの使い方を疑う前にコンテキストの重さを確認してみてほしい。

「半日のはずが終わらない」ときは、5分タスクの感覚でスタートしてスコープが膨らんでいる状態だ。Plan Mode を使わずに走り続けて、気づいたら泥沼というパターン。途中で「このタスクは本来何時間のものか」と問い直すだけで、アプローチの切り替えタイミングが見えやすくなる。

「数日タスクが途中で詰まる」のは、たいてい knowledge/ や git checkpoint なしで進めて状態を失うことが原因だ。「あのとき何で A を選んだんだっけ」という文脈が次のセッションで取り出せなくなる。圧縮に頼るのではなく、明示的に状態をマークダウンで書き起こすことで防げる。

まとめ — タスク粒度別マトリックスと「何分タスクか」を見積もる癖

4段階のアプローチを整理すると、以下のようになる。

共通して身につけてほしい習慣が一つある。Claude Code にタスクを渡す前に「これは何分タスクか？」を自分に問うことだ。

最初は外れる。30分のつもりが半日になる。半日のつもりが2日になる。でも、見積もりを立てる癖がつくと、外れたときに「あ、粒度が上がった」と気づいてアプローチを切り替えられる。Plan Mode を起動するか、knowledge/ に状態を書き出すか、worktree を分割するか。その判断ができるかどうかが、「なんかうまくいかない Claude Code」と「頼りになる Claude Code」の差だ。

今日、次に Claude Code を開いたとき、タスクを渡す前に一秒だけ「これは何分タスクか？」と考えてみてほしい。