Haikuサブエージェントを常駐させる：Claude Codeを1/10のコストで回す

Claude Codeを本気で使い始めて1〜2ヶ月経った人は、ほぼ全員が**「月額がやけに重い」**に到達します。そして多くの人はここで「課金額に見合う成果が出ているか？」を疑い始めます。

しかし疑うべきは成果ではなくモデル選択の粗さです。Anthropic側は社員が使い放題でコスト感覚が薄いため、公式ドキュメントでは「コスト最適化のためにこうしろ」という節がほぼありません。一方で個人開発者や中小チームは、このあたりをケチらないと継続できません。

この記事では、Claude Codeのコストを桁で下げるためのHaikuサブエージェント常駐パターンを紹介します。

コストは能力ではなくモデル選択で決まる

Claude Codeのデフォルトは Sonnet もしくは Opus です。これは「能力が一番高いモデルを最初に使わせる」という設計思想ですが、実際のタスクの大半は Haiku で十分です。

公式のmodel configに書いてある通り、モデルごとの価格差はざっくり次のとおりです（2026-04時点の比率感、実価格は公式参照）。

Opus 4.6    : 1x （最上位）
Sonnet 4.6  : 1/5 程度
Haiku 4.5   : 1/15〜1/20 程度

つまり、Haikuで代替できるタスクをSonnetで処理しているだけで、そのタスクのコストは3〜4倍になっています。1日100タスク走らせる人なら、月1万円の差が当たり前に出ます。

Haikuで足りるタスクの3類型

経験上、Haikuで劣化を感じないタスクは次の3種類です。

1. 探索系: ファイル検索、grep、関数定義の特定、依存関係の洗い出し
2. 要約系: 長いログ・差分・ドキュメントの要点抽出
3. 構造化系: テキストを表・JSON・YAMLにフォーマット変換する

逆にHaikuだと怪しくなるのは：

• 複雑な推論が必要な設計判断
• 複数ファイル間の整合性を考えた変更実装
• 型の細かい仕様に依存した実装

境目は「答えを出すのに根拠の重ね合わせが必要かどうか」です。ソースコードから事実を抽出するのはHaikuで足ります。事実から推論して設計するのはSonnet/Opusが必要です。

専用subagentを .claude/agents/ に常備する

Subagents ドキュメントで明記されている通り、subagentはモデルを個別指定できます。これを使って「Haiku固定の探索エージェント」を常備品として作ります。

---
name: research-haiku
description: コードベース内の調査・grep・ファイル構造把握に使う。Haiku固定で軽量に動く。
model: haiku
tools: Read, Grep, Glob
---

あなたは調査専門エージェントです。次の原則で動いてください:

- 指定されたファイル群を読んで、問われたことに**事実ベースで**答える
- 推論や設計判断は行わない。見つけた場所と内容だけを報告する
- 出力は markdown の箇条書きで簡潔に

もう1つ「ログダイジェスト専用」も用意します。

---
name: log-digester-haiku
description: 長いログ・エラー出力・差分から要点を抽出する。Haiku固定。
model: haiku
tools: Read
---

与えられたテキストの要点を3〜5行で要約してください。
固有名詞・エラーコード・ファイル名は必ず残し、タイムスタンプや
繰り返し行は省略してください。

この2つを ~/.claude/agents/ に置いておけば、全プロジェクトで使えます。メインセッションから /agents で呼び出すか、Claude自身が「これは調査タスクだ」と判断して delegate するようになります。

普段使いのリズム

Claude Code を起動してすぐ、調査系のタスクは必ず research-haiku に投げる癖をつけます。

ユーザー: 認証関連のミドルウェアを全部洗い出して

Claude: research-haiku に delegate します。
  → subagent が Grep / Read で調査
  → 結果を Claude に返却
  → Claudeが要約して回答

この流れだと、重いモデルは「最終回答の整形」しかやらないので、1タスクあたりのトークン消費が大幅に下がります。個人開発だと月額が1/3〜1/5 に落ちるのが体感です。

Sonnetに戻すべき瞬間の見分け方

Haikuに任せた結果が薄い・ズレていると感じたら、それは境界線のサインです。

• 「見つけられませんでした」が来たが、実際にはあるはず → 検索精度不足。Sonnetに切り替え
• 「結論：〜ということです」が根拠なく書かれている → 推論部分。Sonnetに切り替え
• 複数の解釈ができる仕様を聞いた → 判断が必要。Sonnetに切り替え

Haikuに無理をさせるより、境界を見極めてサッと切り替える方が結果として安く済みます。「Haikuで足りる時だけHaikuを使う」——この引き際が運用の肝です。

落とし穴

• 全部Haikuにしようとする: 特に複雑な設計判断まで Haiku に投げると、結果が薄くなり再実行コストで相殺される
• subagentの結果を信じすぎる: 探索系でもたまに見落としがある。重要な変更の前には Sonnet/Opus で再確認するのが安全
• コンテキストの肥大化: 大量のファイルをHaiku subagentに渡すと、結局トークンが積み上がる。「聞く範囲を狭める」設計が大事
• モデル設定の忘却: frontmatterの model: haiku を書き忘れると、親と同じモデル（通常Sonnet/Opus）が使われる。無言でコスト増の原因になる

まとめ

Claude Codeのコストを語るとき、多くの人が「総使用量」を減らそうとします。しかし本当に効くのは**「モデル選択の粗さ」を解消する**ことです。Haikuで足りる仕事はHaikuに寄せる——この運用だけで、同じ成果を半分以下のコストで維持できます。

常備するsubagentは2つで始めて問題ありません。research-haiku と log-digester-haiku。この2つを使うだけで、コスト感覚は確実に変わります。

---

参考:

• Claude Code Docs — Sub-agents
• Claude Code Docs — Model config