AIエージェント3層運用でコスト40%削減した実例

はじめに：AIエージェント運用で「気づいたら月額が膨らんでいた」問題

Claude Codeを業務に組み込んで半年ほど経った頃、ふとAPI利用料のダッシュボードを見て凍りつきました。当初想定していた予算の約2.3倍。「とりあえずOpusを使っておけば品質は保証される」という安易な運用をしていたツケが、月末の請求書として返ってきた瞬間です。

私が運営している小さなチームでは、Claude Codeのサブエージェント機能を使って「複数の専門家AI」を擬似的に立ち上げ、役割分担させながら開発を進めています。エージェントの数は徐々に増え、最終的に17名体制になりました。ところが、全員をOpusで動かしていたため、定型的なログ整形やリファクタリングまで最上位モデルを叩く構造になっており、これがコスト爆発の主因でした。

そこで本記事では、実際に運用しているチームの設定ファイルを基に、「判断層・検証層・実行層」の3層構造でモデルを使い分ける運用設計を解説します。結論から言うと、この設計に切り替えてから月額コストは約40%削減され、それでいて判断品質は落ちていません。むしろレビュー精度は上がりました。

「Opus、Sonnet、Haikuって結局どう使い分けるのが正解なの？」と悩んでいる方、「チームで運用しているけどモデル選択が属人化している」と感じている方に向けて、再現可能なレベルで設定例とハマりポイントを共有します。

この記事で解決する課題

• Claude Codeを使い始めたが、毎月のAPI料金が想定の2〜3倍に膨らんでいる
• とりあえず最上位モデル（Opus）を使っているが、本当に全タスクで必要なのか分からない
• 複数のAIエージェントを組織的に運用したいが、どのモデルをどの役割に割り当てればいいか判断基準がない
• Sonnetへの切り替えタイミングがチームでバラバラで、属人化している
• Haikuの存在は知っているが、どこで使えば効果的なのか想像がつかない

これらは、私自身が半年前にぶつかった悩みそのものです。順番に解いていきましょう。

結論：役割を3層に分解し、モデルを固定割り当てする

先に答えを示します。私のチームでは、以下のような3層構造でモデルを固定割り当てしています。

層	役割	採用モデル	理由
判断層（COO 5名）	戦略判断・最終意思決定	Opus	失敗コストが大きい、推論深度が必要
検証層（4名）	レビュー・整合性チェック	Opus	見落としが致命傷になるため
実行層（10名）	コード生成・定型処理	Sonnet	速度とコストのバランスが最適

そして、ここが重要なのですが、「迷ったら手動でモデル切替できる逃げ道を作る」こと。Claude Code内で /model sonnet や /model opus を打てば即時切替できるので、原則は自動運用に寄せつつ、例外時は人間が介入できる構造にしています。

なぜこの3層が機能するのか。それは「失敗コストの非対称性」を設計に反映できるからです。判断ミスは数日〜数週間の手戻りを生みますが、実行段階のミスはレビューで拾えます。失敗コストが大きい層にだけ高性能モデルを割り当てるのが、合理的な投資判断になります。

具体的な手順・設定方法

手順1：メインセッションの方針を CLAUDE.md に明記する

Claude Codeには、リポジトリルートに CLAUDE.md を置いておくと、セッション開始時に自動で読み込んでくれる仕組みがあります。ここに「どのモデルをどの役割に割り当てるか」を文書化しておくのが、運用ブレを防ぐ第一歩です。

私のチームで使っている記述例はこちら。

# AI Agent運用方針

- メインセッション = COO: 各社セッションのメインセッションはCOOとして振る舞う
- メインセッション: Opus 4.x（settings.json準拠）
- Agent（subagent_type）: 各エージェント定義ファイルのmodel指定に従う
- 判断層（COO 5名）+ 検証層（レビュアー・アナリスト・コードレビュアー・ファクトチェッカー）: opus
- 実行層 10名: sonnet（frontmatter `model: sonnet` で自動適用）
- Sonnet切替が必要な場合: オーナーが `/model sonnet` で手動切替
- Opus復帰: `/model opus` で戻せる

たかが数行ですが、これを書くか書かないかで運用品質が劇的に変わります。書いておかないと、人によってモデル選択がブレるからです。新メンバーが入ってきても、CLAUDE.mdを読めば「あ、ログ整形はSonnetでいいんだな」と即座に理解できます。

実際にやってみて分かったのですが、こうしたガイドラインは「迷った時に立ち戻る場所」として機能します。私自身、深夜に作業していて「これOpusでやるべきか？」と迷う場面が何度もあったのですが、CLAUDE.mdを見れば「あ、これは検証系だからOpusだ」と即決できる。判断疲労を減らすという副次効果が想像以上に大きい。

手順2：エージェント定義ファイル（frontmatter）でモデルを固定

Claude Codeのサブエージェント定義ファイル（.claude/agents/ 配下の .md ファイル）には、frontmatterで model を指定できます。これを使うと、サブエージェント呼び出し時に自動的に該当モデルが選択されます。

実行層エージェント（Sonnet固定）の例：

---
name: engineer
model: sonnet
description: フロントエンド実装担当。React/TypeScriptのコンポーネント設計と実装を行う。
---

# あなたの役割

あなたはフロントエンド実装の専門家です。
コンポーネントの責務分離、再利用性、型安全性を重視してください。
...

判断層エージェント（Opus固定）の例：

---
name: coo-strategy
model: opus
description: 戦略判断・COO。プロジェクト全体の方針決定、リソース配分、優先順位判断を担当。
---

# あなたの役割

あなたはCOO（最高執行責任者）です。
戦略レベルの意思決定と、サブエージェントへのタスク分配を行います。
失敗コストが大きい判断には、必ず検証層のレビューを経由させてください。
...

frontmatterでモデルを固定する最大のメリットは、呼び出し側がモデルを意識しなくて済むことです。メインセッションから「engineer-agentにこのコンポーネント作らせて」と指示するだけで、自動的にSonnetが走ります。逆に「COOに戦略判断してもらおう」と呼べば、自動的にOpusで動く。

ここで一度ハマったのが、frontmatterの model 指定をしていなかった初期のエージェントです。デフォルトでメインセッションのモデル（Opus）を継承するため、「実行層のつもりだったのに全部Opusで走ってた」という事故が起きました。frontmatterで明示的に指定しないと、暗黙にOpusで走るのは要注意ポイントです。

手順3：インデックスファイル（_index.md）で全体像を可視化

.claude/agents/_index.md のような形で、全エージェントの一覧表を作っておくとオンボーディングが劇的に楽になります。

# Agent Index

| 層 | モデル | 担当エージェント |
|----|--------|------------------|
| 判断層 | opus | 各事業部COO（5名） |
| 検証層 | opus | レビュアー / アナリスト / コードレビュアー / ファクトチェッカー |
| 実行層 | sonnet | エンジニア / テスター / ライター / マーケター / デザイナー / 財務 / 法務 / HR / 網羅性チェッカー / 数値検証 |

## 呼び出し例

- 戦略判断が必要 → COO（Opus）
- レビュー依頼 → レビュアー (Opus)
- フロント実装 → エンジニア (Sonnet)
- バックエンド実装 → テスター (Sonnet)
- ログ整形・要約 → （将来的にHaiku層を検討中）

これがあると、新メンバーが「誰がOpusで誰がSonnetか」を一目で理解できます。私のチームでは、メンバーが増えるたびに必ずこのインデックスを更新するルールにしていて、エージェント追加プルリクのレビュー時にも「_index.md 更新した？」が必須チェック項目です。

手順4：COOがメインセッションでPhase 1プランを直接作成する設計

メインセッション（つまり人間が直接対話している層）はOpusで動作させているので、Phase 1の計画立案はCOOロールとしてメインセッション自身に行わせるのが効率的です。

具体的には、CLAUDE.md にこう書いています：

# プラン作成フロー

メインセッション（COO）はOpusで動作するため、Phase 1プランをCOO自身が作成してよい。
COOサブAgent委譲も引き続き可能（コンテキスト分離が必要な場合等）。

判断基準:
- 短時間タスク・現在のコンテキストで完結 → メインセッションで直接作成
- 長期タスク・別領域の調査が必要 → サブエージェントへ委譲
- レビューが必要 → 検証層（レビュアー等）を経由

これにより、サブエージェント呼び出しのオーバーヘッドを省略できます。コンテキスト分離が必要な時だけ委譲するのがコツです。なんでもかんでもサブエージェントに渡していると、Tool callのオーバーヘッドとコンテキスト引き継ぎコストが地味に効いてきます。

手順5：手動切替コマンドをチーム内で共通言語にする

自動運用を基本としつつも、Claude Codeのスラッシュコマンドで手動切替できる仕組みを残しておきます。チーム内で共通言語化したのは以下の3つです。

# コスト最適化したい時（軽量タスク・大量処理）
/model sonnet

# 重要判断・複雑推論が必要な時
/model opus

# 現在のモデル確認
/model

運用ルールとしては、「30分以上かかる長期タスク」「失敗時の手戻りが大きいタスク」だけOpusと決めています。それ以外は原則Sonnet。この基準があるだけで、「いまOpusで動かす必要ある？」という自問自答が成立します。

実際に使ってみた結果

得られたメリット

• コスト約40%削減：実行層10名分のトークン消費がSonnet単価になり、月額が大幅減。具体的には、リファクタリングや単純なファイル操作などの定型タスクが全体トークンの約7割を占めていたため、その層がSonnet化した効果は絶大でした
• 判断品質は維持：判断層・検証層をOpusで固めたので意思決定の質は落ちない。むしろ「判断はOpus、実行はSonnet」と明確に分けたことで、各層がそれぞれの役割に集中するようになりました
• レビュー精度の向上：検証層の4名体制が機能し、見逃しが減少。「実装はSonnetが速く出して、レビューはOpusがじっくり見る」という流れが、結果的にチェック&バランス構造になっています
• 新メンバーの立ち上がりが早い：_index.md があるので役割と責任範囲が明確。「誰に何を頼めばいいか」のオンボーディングが半日で終わるようになりました
• 応答速度の改善：Sonnetは応答が速いので、実行層のタスクは体感で1.5倍くらい早く返ってきます。これは見落とされがちですが、開発体験への影響は大きい

気をつけたいデメリット

• 実行層がSonnetなので、たまに「あと一歩踏み込んだ提案」が出ない場面があります。特にアーキテクチャ寄りの判断を実行層がやろうとすると、表面的な解で止まりがち
• /model sonnet 手動切替の判断が、結局は属人的になりがち。社内ルール化していても、深夜疲れた時に「とりあえずOpusでいいや」となる人がいる
• エージェントが17名もいると、誰に振るべきかメインセッションのCOOが迷うことがある。これは結局、_index.md を引きながら「この役割なら誰だっけ」と都度確認する運用でカバーしています
• frontmatterで model を書き忘れた場合、デフォルトでメインセッションのモデルを継承するため、意図せずOpusで走ることがある（後述の失敗談で詳しく）

よくある失敗とその対処法

失敗1：全エージェントをOpusで動かしてしまう

症状：定型的なリファクタリングや単純なファイル操作までOpusで実行してしまい、月額請求が想定の2倍以上に膨張。私自身、最初の3ヶ月はこの状態でした。

原因：frontmatterで model を指定していないと、サブエージェントはメインセッションのモデル（Opus）を継承します。「特に何も書かなければデフォルトはSonnet」という思い込みが、痛い目を見るパターン。

対処：実行層エージェントの定義ファイルすべてに model: sonnet をfrontmatterに明記する。一度だけスクリプトで一括確認しました：

# エージェント定義ファイルのmodel指定をチェック
# (.claude/agents/ 配下のmdファイル一覧)
ls .claude/agents/*.md

# 各ファイルのfrontmatterを目視確認
# model: の行が存在しないファイルは要修正

実行層10名分のfrontmatterを修正したところ、翌月の請求が一気に下がりました。やってみて初めて分かったのは「暗黙のデフォルトは常に高い方に倒れる」という事実。サービス提供側の合理的な仕様ですが、コスト管理側からすると爆弾です。

失敗2：実行層なのに重要判断を任せてしまう

症状：SonnetエージェントにアーキテクチャやDB設計の選定を依頼したところ、表面的な比較表は出てくるものの、長期的な保守性まで踏み込んだ判断が出ず、後で手戻りが発生。

原因：Sonnetは実装タスクには十分な性能ですが、「複雑な選択肢の中から本質的なトレードオフを抽出する」という抽象思考はOpusに分があります。役割の境界を曖昧にしたまま運用すると、Sonnetに不向きなタスクが流れ込んでしまう。

対処：判断系タスクは必ず判断層（COO）か検証層に通すルールを徹底。CLAUDE.mdの末尾に以下を追記しました：

# タスク振り分けルール

- アーキテクチャ選定 → 判断層（COO）必須
- DB設計・スキーマ変更 → 判断層 → 検証層レビュー
- セキュリティ関連 → 判断層 + 検証層
- 実装・コード生成 → 実行層（Sonnet）
- リファクタリング（仕様変更なし） → 実行層
- ログ整形・要約 → 実行層（将来的にHaiku化検討）

ここまで明示的に書くと、メインセッション側で「あ、これは実行層に丸投げじゃダメだ」と判断できるようになります。

失敗3：手動 /model 切替の判断基準が曖昧

症状：人によってOpus/Sonnetの切替タイミングがバラバラで、月次コストの見通しが立たない。誰がいつ /model opus したのかも追跡できない。

対処：判断基準を3つに絞って明文化しました。

1. 30分以上かかる長期タスクはOpus
2. 失敗時の手戻りが半日以上のタスクはOpus
3. 本番環境に直接影響するタスクはOpus

それ以外は原則Sonnet。この3条件のいずれかに該当しない限りはSonnetで動かす、というシンプルなフローにしました。実際にやってみて感じたのは、「ルールがシンプルすぎるくらいでちょうどいい」ということ。複雑なフローチャートを作っても、結局は誰も覚えていない。

失敗4：Haikuを検討せず2モデル運用に固定化

症状：ログ整形・要約・通知文の生成など、明らかにオーバースペックなタスクまでSonnetで処理。コスト最適化の余地を見落としていた。

対処：Haiku層の追加を検討中です。具体的には以下のタスクをHaiku化する想定でPoCを進めています。

• Slack/メール通知の文面整形
• 大量ログからの異常検知（パターンマッチ＋自然言語要約）
• ファイル名のサニタイズや命名規則チェック
• 定型的なコミットメッセージ生成

frontmatterの記述例はこうなる予定です：

---
name: log-summarizer
model: haiku
description: ログ集計・要約専用。大量の構造化ログから異常パターンを抽出して要約する。
---

Haikuは応答速度が圧倒的に速く、単価も低いため、軽量タスクの大量処理には最適。ただし、ニュアンスを汲んだ判断は苦手なので、「形式が決まっているタスク」「正解パターンが明確なタスク」に限定する必要があります。やってみて分かったのは、Haiku/Sonnet/Opusの3層体制は、コストカーブが対数的に下がる構造を作れるということ。軽量タスクの量が多い組織ほど、Haiku層の追加効果は大きくなります。

失敗5：モデル切替後に「戻す」のを忘れる

症状：軽量タスクのために /model sonnet したまま、次の重要判断もSonnetで進めてしまい、品質が落ちる。

対処：セッション開始時にメインモデルを確認する習慣を作る。具体的には、新しい作業を始める時に必ず以下を実行：

# 現在のモデルを確認
/model

# 想定と異なれば切替
/model opus

地味ですが、「セッションのデフォルト状態を確認する」という小さな儀式を入れるだけで、事故が減ります。

運用を始めて気づいた、設計の本質

3層構造を運用していく中で、当初想定していなかった効果がいくつかありました。

ひとつは、「組織設計とAI設計が相似形になる」という発見です。人間の組織でも、意思決定者・レビュアー・実行者が分かれているのが普通です。AIエージェントも同じように設計したら、結果的に人間が理解しやすく、運用も自然になりました。これは偶然ではなく、複雑なタスクを扱うシステムは構造的に似た形に収束するのだと思います。

もうひとつは、「コスト削減と品質向上は両立する」という体験。当初は「コストを下げると品質も下がるのでは」と心配していたのですが、実際は逆でした。役割を明確にしたことで、各層が自分の責務に集中できるようになり、判断層は判断に専念、実行層は実装に専念できる。結果として、判断ミスが減り、実装スピードが上がり、しかもコストは40%下がる。これは設計の力です。

まとめ・次のステップ

まとめ

• 役割を3層に分けてモデルを固定するのが最もシンプルかつ効果的な設計
• 設定ファイル（CLAUDE.md / frontmatter / _index.md）で「自動適用」と「可視化」を両立させる
• 手動切替（/model sonnet / /model opus）は逃げ道として残しつつ、原則は自動運用に寄せる
• 判断基準は3つ程度のシンプルなルールに絞る。複雑なフローは形骸化する
• Haiku層の追加でさらにコスト最適化の余地がある

次のステップ

1. 自社の業務を3層に分類してみる：判断・検証・実行の棚卸しから始める。ホワイトボード1枚で書き出してみると意外と整理できます
2. frontmatter運用を試す：1エージェントだけでも model: 指定を導入してみる。効果を体感してから全体展開がオススメ
3. Haiku層の追加検討：通知整形・ログ要約などの軽量タスクを切り出してさらにコスト削減
4. 月次でモデル別トークン消費をレビュー：割り当てが妥当か3ヶ月単位で見直す。最初の数ヶ月は配分が動きやすいので頻度高めで
5. CLAUDE.mdをチームで読み合わせる：書いただけで満足しないこと。週次のチームミーティングで「先週運用ルールに違反したケースあった？」と振り返る場を作る

読者への問いかけ：あなたの組織では、AIエージェントを「肩書き」ではなく「役割」で設計できていますか？まずはCLAUDE.mdに3層モデルを書き出すところから始めてみましょう。1行書くだけで、半年後のコスト構造が変わります。

tech-picks.netでは、中小企業向けに実践的なAI活用ノウハウを継続的に発信しています。Claude Codeの運用設計、サブエージェント活用、コスト最適化などのトピックを今後も掘り下げていく予定なので、ぜひ他の記事も覗いてみてください。