Claude Code開発でコストを3割減らす階層型エージェント設計の理由

Claude Codeで開発を回すと、毎月のAPI請求額が跳ね上がる。最上位モデルにファイルの検索や単純なコード実装まで任せると、コストは4倍に達する。

解決策はタスクの重さでモデルを使い分ける階層型エージェント設計と、文脈を繋ぐ外部記憶システムの組み合わせだ。開発の質を維持したまま全体のコストを3割削減する。僕のThreadPost開発でも実践している、トークン破産を防ぐアーキテクチャを解説する。

AI開発における「モデル高額化」と「記憶の断絶」

最新AIモデルの性能向上に伴い、開発コストが高騰している。最上位モデルはコード生成能力が高い一方、API単価も高い。新世代のトークナイザ採用により、従来モデルと同じテキスト量でも最大35%多くのトークンを消費する。

中間モデルの利用費用は最上位モデルの30%程度、最軽量モデルなら10%で済む。ファイル探索や大規模なコード読み込みをすべて最上位モデルに処理させると、トークン消費量は激増する。開発コストは簡単に4倍まで膨らむ。

しんたろー：
最上位モデルにエラーログの全件検索を任せていた時は、月の請求書を見て青ざめた。最強のAIに雑用を任せるのは、年俸数千万円のエンジニアにひたすら文字起こしをさせるようなものだ。

もう一つの課題が、モデルのインスタンスの断絶だ。セッション終了とともにAIのコンテキストはリセットされる。過去のバグ経緯やプロジェクトのルールも失われる。開発者は毎回同じ前提条件をプロンプトに詰め込み、さらなるトークン浪費を引き起こす。

この二重苦を解決するのが、階層型エージェントと外部記憶システムの融合だ。高次元の設計や複雑なデバッグは最上位モデルに担当させる。仕様が固まった実装やコード検索は.claude/agents/機能で安価なモデルへ委譲する。ローカル環境のSQLite等に過去の知見を蓄積し、ツール経由で動的に参照させる構成をとる。

「タスクの委譲」と「外部記憶」によるアーキテクチャ設計

AI開発の最前線では、2つのアプローチが重要だ。1つはモデルの性能によるタスクの階層化。もう1つは外部記憶による文脈の補完だ。

最新の最上位モデルは推論能力が向上した反面、トークナイザの変更で消費トークン数が増える。同じ処理内容でも消費トークン数が最大35%増加する。すべての作業を最上位モデルにやらせる力押しのアプローチは破綻する。

Claude Codeのカスタムエージェント機能を活用する。プロジェクト内の設定フォルダ（.claude/agents/）に役割別のエージェントを定義する。ファイル内で委譲先のモデル（SonnetやHaiku）を直接指定し、構造的にタスクを振り分ける。

仕様が固まったコード実装は中堅モデルへ委譲する。大規模なファイル検索やテストの自動実行は、最も低単価なモデルに任せる。思考の深さを制御するeffortパラメータを適切に設定すれば、無駄な推論トークンの生成を抑えられる。単価の差とトークナイザの特性を掛け合わせると、処理全体にかかるトークン費用は実質4分の1近くまで圧縮できる。

しんたろー：
ちょっとした修正で最上位モデルが走り出した瞬間に青ざめる。カスタムエージェントでテスト実行と検索を安価なモデルに逃がす設定にしてから、トークンの減り方が明らかに遅くなった。ThreadPostでも、バグ調査だけ最上位モデルに任せ、実装はすべて下位エージェントに投げている。

一方、タスクを委譲してもインスタンスの断絶は残る。LLMはセッションが終われば記憶を失う。同じ前提条件を毎回プロンプトに流し込めば、コンテキストウィンドウが圧迫され、コストが跳ね上がる。

この課題を突破するのが、ローカル環境での外部記憶データベースだ。SQLiteなどのデータベースに過去のエピソードや設計判断を保存する。会話の開始時やタスク受領時に、関連記憶を自動検索（Recall）する仕組みを組み込む。モデルは「過去の自分が書いたメモ」を読むことで、過去の文脈を瞬時に理解する。

外部記憶の運用には環境の選定も重要だ。機密情報や開発ログを扱う場合、クラウド依存の記憶機能にはリスクが伴う。DockerやColimaを活用したローカルでのインフラ構築が有効だ。ローカルLLMの実行基盤（Ollamaなど）とローカルデータベースを組み合わせれば、データを外部に送信しない閉じられた記憶エコシステムが完成する。

実践すべき3つの設計アプローチ

実務における具体的な変化は、3つの設計手法に集約される。

1つ目は、タスクの複雑性に応じたモデルの委譲ルールの明文化だ。Claude Codeの設定ディレクトリ（.claude/agents/）に役割ごとのエージェントを定義する。設計やデバッグは最上位モデル、実装は中位モデル、テスト実行は最安モデルに任せる。最安モデルの単価は最上位モデルの10%程度であり、高頻度な単純作業を逃がすだけで開発費用の急増を防げる。

しんたろー：
すべての作業を一番賢いモデルに投げっぱなしにできたら楽だが、毎月の請求額を見ると速攻で正気に戻る。Claude Codeでコードを書くときも、テスト実行専用のサブエージェントを作っておかないと一瞬で利用上限に達する。

2つ目は、セッションを跨ぐ記憶のシステム化だ。過去のデバッグ手順や設計思想をSQLiteなどのローカルデータベースに記録する。会話の冒頭で記憶の検索を自動実行させれば、AIは過去の決定事項を踏まえた上でコードを生成できる。やり取りの往復が減り、トークン消費量の節約に直結する。

3つ目は、ローカル実行環境を活用した機密データの保護だ。DockerやColimaをベースにしたローカルLLMの実行基盤を用いる。Ollamaなどを活用してローカル側でデータの要約や記憶DBの処理を行えば、セキュリティの確保と通信コストの削減を両立できる。

よくある質問

モデルの委譲ルールを構築する際、最も注意すべき点は？

「委譲の往復コスト」によるトークンの無駄遣いだ。単純な作業を細かくサブエージェントに投げすぎると、ツールコールのオーバーヘッドや文脈の再ロードでコストが増える。テスト実行や仕様確定済みの実装など、入力と出力が明確なタスクだけを切り出すのが鉄則だ。

ローカルLLMで記憶システムを構築するメリットは？

「機密データの保護」と「記憶資産の完全な所有権」だ。クラウド側の記憶機能に依存すると、APIの仕様変更で蓄積した文脈が消えるリスクがある。SQLiteなどでローカルに記憶データベースを保持しておけば、モデルを変更しても開発ログの知見を資産として継承できる。

Claude Codeでeffortパラメータを調整する基準は？

基本はデフォルト設定の「high」を維持する。仕様が固まった機械的なリファクタリングなら「low」や「medium」へ下げるのが有効だ。思考プロセス（Thinking）の深さを抑えることで出力トークン数を削減できる。

まとめ

モデルを買い替えるのではなく、タスクの委譲と記憶の保持を設計する。これだけでAPIコストを3割削減しながら、文脈が切れない開発環境が作れる。アーキテクチャの工夫こそが最高のコスト削減策だ。

👉 ThreadPostでSNS運用を自動化する