Claude Codeはサブスクプランで使っているので、実はAPI従量課金の請求額は見ていません。気にしているのはサブスクの5時間ウィンドウ制約の中で、どれだけ多くの作業を並列で回せるかの一点です。
この視点に切り替えると、モデル選びの判断軸が「料金単価」ではなく「その処理に判断の賢さが必要か、それとも速さが欲しいか」に変わります。Opusは賢い代わりに遅い。Haikuは安いだけでなく速いので、思考が要らない処理に当てれば枠と時間の両方が浮きます。
104本のskillを運用する中で落ち着いたのは、モデルを3層に分けてskillごとに明示指定するという単純なルールです。判断基準と実データをそのまま公開します。
この記事で分かること
- 104 skillのうち、どのskillをどのモデルに割り当てているか（実データ）
- サブスク枠内のスループットとOpusのレイテンシから導いた3層ルール
- 実行単位を agent 3種から skill に統一した理由（モデル配分の3層とは別の話）
現状：104 skill中、17本にモデル明示指定
まず現状を数字で出します。
| 項目 | 本数 |
|---|---|
| skill総数 | 104 |
model: を明示指定しているskill | 17 |
| デフォルト継承（多くはSonnet相当） | 87 |
明示指定の内訳は次の通りです。
| 層 | モデル | skill数 | 代表例 |
|---|---|---|---|
| 意思決定・レビュー | Opus | 8 | bug-hunt / pr-review / seo-strategy |
| 実装・分析 | Sonnet | 4 | dev-implement / doc-generate |
| 検証・定型処理 | Haiku | 5 | dev-validate / repo-commit |
87本のデフォルト継承分は「指定するほど用途が固まっていないskill」や「ユーザーの会話コンテキストをそのまま使いたいskill」で、意図的に未指定です。
3層ルール — 何で分けているか
判断軸はシンプルで、「そのskillが担うのは意思決定か、実装か、検証か」 の一点だけ。対応して効くモデル特性も、Opusの「賢さ」、Sonnetの「バランス」、Haikuの「速さ」と素直に整理できます。
Opus層：判断の質が成果物の質を決める
設計・レビュー・根本原因分析のように、1回の判断ミスが下流工程を全部壊す種類の作業にだけOpusを割り当てます。ここは遅くてもいいから賢さを取りにいくレイヤーで、Sonnetだとレビューの指摘漏れや計画の抜けが結局あとで数倍の手戻りを生みました。
該当するのは次のような性質のskillです。
- 根本原因を探すskill: 症状から逆算して原因候補を複数立て、検証順序まで設計する必要がある
- レビュー・評価skill: 「気付かないものを気付く」ことが価値で、速さより網羅性が効く
- 計画立案skill: 制約を全部踏まえた上で実行可能な分割を提案する、抽象度の高い作業
たとえばPR差分全体を読み込んで指摘を出すskillで試したところ、Sonnetは粗い提案が多く、最終的にコメント数は多いのに実効的な指摘率は下がりました。Opusに戻すと指摘数は減る代わりにヒット率が上がる、という挙動だったので、ここはレイテンシと引き換えに賢さを買うレイヤーだと割り切っています。
Sonnet層：読み書きの速度と品質のバランスが効く
実装・分析・ドキュメント生成のように、大量のコードや文章を扱うが、判断の抽象度はそこまで高くない作業をSonnetに寄せます。
- コードを書くskill（既に設計が決まっている前提で、規約に沿って書く）
- ファクトチェック・SEO改善（参照先データを突き合わせて差分を出す）
- ドキュメント生成（構造化された入力から定型出力を作る）
ここでOpusを使ってもアウトプットの質はほとんど上がらず、レイテンシだけ伸びてサブスク枠を無駄に食います。逆にHaikuに落とすと、長いコンテキストの保持や複雑な条件分岐で精度が落ちます。
Haiku層：速いことそのものが価値になる定型処理
「入力と出力のフォーマットがほぼ決まっていて、判断の余地がない」作業を全部Haikuに寄せました。
dev-validate：型チェック・テスト実行の結果整形repo-commit/repo-pr/repo-issue/repo-export：GitHubの情報を取得してMarkdownに整形する一連のskill
これらはモデル性能ではなくプロンプトの書き方で品質が決まるタイプで、Haikuで十分に回ります。むしろHaikuに落として得たいのは速度の方で、コミット整形やPR取得のような「本筋のタスク前後の儀礼的処理」を高速に済ませると、空いた時間を本来の設計・実装に回せます。安さと速さが同時に効く、素直に甘いレイヤーです。
設計の試行錯誤：実行単位は skill に統一、モデル配分は3層のまま
ここで一度、軸を分けて整理しておきます。この記事には「3層」と「統一」という言葉が並びますが、指している対象が別です。
- 実行単位の種別（agent / skill）: 当初は agent を役割ごとに3種類 → 現在は skill に統一（1 skill : 1 model、必要に応じて Skill tool で呼び合う）
- モデル配分（Opus / Sonnet / Haiku）: 当初も現在も 3層のまま
モデル配分は skill ごとの frontmatter で個別に固定します。1つの skill が複数モデルを使い分けるのではなく、役割の違う skill を並べて Skill tool でオーケストレーションする形です。
当初はこの2軸を同じものだと思い込み、実行単位もagent 3種で組んでいました。Claude Codeのagents機能でplanner/executor/validatorを別agentとして定義し、それぞれにモデルを割り当てる設計です。
運用を続けるうちに見えてきたのは、skillがカスタムagentに対して機能面で上位互換になっていたという事実でした。Skill tool 経由の呼び出し・journal 連携・状態管理といった、agentsには無くskillにはある機能が、実運用で効いていたのはほぼ全部skill側です。一部のskillがすでにagentの役割を上位互換で引き受けていたので、実行単位を skill に統一し、モデル配分は skill ごとの frontmatter で3層を維持する現在の形に収束しました（Claude Code本体のagents機能自体は引き続き提供されており、撤廃したのはあくまで筆者個人の運用設計です）。
学びとしては、実行単位の種別を分けることと、モデルを分けることは別の話だということ。実行単位は「使える機能がより多い側（skill）」に寄せて統一し、モデル配分は skill ごとの frontmatter で明示する、という切り分けの方が素直でした。
自分のskillを振り分けるためのチェックリスト
新しくskillを作るとき、以下の5問で層を決めています。
- 判断を間違えた場合、下流工程の手戻りは何ステップ分か？ 3ステップ以上 → Opus候補（遅さを許容する価値あり）
- 入出力のフォーマットは事前に決まっているか？ 決まっている → Haiku候補（速さが効く）
- 扱うコンテキストは長い（数千行以上）か？ 長い → Haikuは避ける
- 「気付かないものを気付く」ことが価値のskillか？ Yes → Opus
- 既存Sonnet skillで品質に不満はあったか？ ない → そのままSonnet（デフォルト継承でOK）
迷ったらデフォルト継承のままで出して、実運用で不満が出た時にだけ明示指定する、という順序を推奨します。先に全skillを3層に振り分けようとすると、使われていないskillの最適化に時間を溶かします。
ツール横並び比較ではなく「枠内の配分」で見る
Claude Code自体の料金プランを他ツールと比較したい場合は2026年AIコーディングツール料金完全比較で6ツールを横並びにしています。別プロバイダのモデル移行で請求額を下げた事例はGemini Flash Lite移行でAIコスト40%削減、AIエージェント全体の運用費を人件費と突き合わせる議論はAIエージェントを月3万の新人として雇うにそれぞれ分けてあります。
本記事の立場は、それらとは独立して 「同じサブスクプランの中でskillごとにモデルを割り当てる」運用最適化です。プランを上げず、ツールも切り替えず、配分だけで5時間ウィンドウ内のスループットを動かすレイヤーの話として使ってもらえれば。
まとめ
- 104 skill中、明示モデル指定は17本。残り87本はデフォルト継承で十分運用できている
- Opus 8 / Sonnet 4 / Haiku 5 の配分は「意思決定・実装・検証」の3層で決めている
- 「全部Opus」は判断の質が必要なskill以外では遅くなるだけで、サブスク枠の無駄遣いになる
- 思考が要らない処理はHaikuに落とすと安さ × 速さが両取りできる
- 役割ごとに agent を立てるより、skill に統一して frontmatter で skill ごとにモデルを指定する方が素直だった（モデル3層は維持、実行単位の種別だけ skill に統一）
- 迷ったらデフォルト継承のまま出し、不満が出たskillだけ明示指定する
skillの設計そのものを深掘りしたい場合はSkills設計パターン上級編、設定ファイル全般のカスタマイズはsettings.json × CLAUDE.md 完全ガイドが近い話題です。
