この記事は playpark Blog からの転載です。
この記事で分かること
- Claude Code skill のモデル配分を「3層」に設計した背景と理由
- Opus / Sonnet / Haiku をどの基準で使い分けるか
- 104 本の実運用で分かった「指定すべき skill と指定不要な skill」の判断軸
背景: こういう疑問があった
Claude Code のサブスクプランで skill を大量に運用していると、こんな疑問にぶつかる。
「全部 Opus にすれば品質が上がるのでは？」
直感的にはそう思える。しかし Claude Code のサブスクプランでは API 従量課金の請求額は直接の問題ではなく、5 時間ウィンドウ内でどれだけ多くの処理を並列で回せるかがボトルネックになる。Opus は賢い代わりに遅い。思考が要らない定型処理で Opus を使うと、枠と待ち時間の両方が無駄になる。
「モデルの賢さよりも、処理の性質に合った速さを選ぶべきではないか」——この仮説から設計を始めた。
仮説
- 仮説1: skill が担う処理を「判断の質が必要か」で分類すると、使うべきモデルが決まる
- 仮説2: 判断不要な定型処理を Haiku に落とすと、スループットを落とさずウィンドウ枠を節約できる
検証設計
| 項目 | 内容 |
|---|---|
| 検証対象 | 104 本の skill（Claude Code Skills） |
| 測定方法 | 各 skill の役割を「意思決定・実装・検証」に分類し、モデルを変えたときの品質変化と処理速度を比較 |
| 成功基準 | 品質を落とさずに Haiku 適用範囲を広げられるか |
各 skill の frontmatter にモデルを明示指定する形で運用した。
# skill frontmatter の例（Haiku 層）
model: haiku
# skill frontmatter の例（Opus 層）
model: opus
結果
| 仮説 | 結果 | 判定 |
|---|---|---|
| 処理の性質でモデルが決まる | 「判断の賢さが必要か / 速さが必要か」の軸で 3 層に整理できた | ○ |
| Haiku で定型処理は十分回る | 入出力フォーマットが固定された処理は品質変化なし | ○ |
実際に落ち着いた配分:
| 層 | モデル | skill数 |
|---|---|---|
| 意思決定・レビュー | Opus | 8 |
| 実装・分析 | Sonnet | 4 |
| 検証・定型処理 | Haiku | 5 |
| デフォルト継承（未指定） | Sonnet 相当 | 87 |
104 本中、明示指定は 17 本。残り 87 本はデフォルト継承のままで品質上の問題は出ていない。
各層の判断基準は次の通り。
Opus 層（8本）: 設計・レビュー・根本原因分析のように、1 回の判断ミスが下流工程を壊す処理。「気付かないものを気付く」ことが価値になる skill。
Sonnet 層（4本）: 大量のコードや文章を扱うが、判断の抽象度はそこまで高くない実装・分析系。Opus を使ってもアウトプットの質はほとんど変わらず、レイテンシだけ増える。
Haiku 層（5本）: 入出力フォーマットが決まっていて、判断の余地がない定型処理。コミット整形・PR 情報取得など、本筋のタスク前後の儀礼的処理を高速に終わらせる。
結論: どう判断すべきか
新しい skill のモデルを決めるとき、次の問いが効く。
- 判断ミスで下流の手戻りが 3 ステップ以上発生するか → Yes なら Opus 候補
- 入出力のフォーマットは事前に決まっているか → Yes なら Haiku 候補
- 扱うコンテキストは数千行以上か → Yes なら Haiku を避ける
迷ったらデフォルト継承のままで出し、実運用で不満が出た skill だけ明示指定する順序が効率的だ。先に全 skill を振り分けようとすると、使われない skill の最適化に時間を溶かす。
さらに深掘りしたい方へ
この記事では skill のモデル配分を 3 層に設計した背景と判断基準を解説しました。
skill 104本のモデル配分を公開 — Opus/Sonnet/Haikuを3層に振り分けた判断基準 ではさらに：
- agent 3 種から skill 統一へ移行した経緯（モデル配分とは別軸の設計変更）
- 実行フローの Before/After 図解（mermaid）
- Opus 8 本 / Sonnet 4 本 / Haiku 5 本の全リストと個別の判断理由
playpark について
playpark LLC - 業務自動化・AI活用・Web開発
