何が起きたか、先に数字で見る
SkillsBench という AI エージェントのベンチマーク論文がある。84 タスク × 7 モデル × 5 試行、計 7,308 トラジェクトリで測った実験だ。
そこで出た数字がこれ。
- Haiku 4.5（skill なし）: 61.2%
- Haiku 4.5（skill あり）: 84.3%（+23.1pp）
- Opus 4.7（skill なし）: 80.5%
Haiku + skill が Opus 素の状態を 3.8pt 上回った。全構成中、最大の伸び幅だ。
この結果をもとに、Claude Code で自律 AI システム「brain」を自作・運用しているエンジニアが追試を行い、その知見をまとめた記事が今回の参照元になる。
なぜ今これが重要なのか
「上位モデルを使っておけば間違いない」という空気は、まだ実務の現場に根強い。API コストはかかっても、品質が担保されるなら——そういう判断だ。
ただ、この考え方には前提が隠れている。「上位モデルの強みが、そのタスクで発揮される」という前提だ。
手順が決まっているタスクなら、その前提は成立しない。Opus の強みは「曖昧な指示から最適手順を自分で組み立てる」ことにある。手順が固定されていれば、そのパワーは遊ぶ。skill はその遊びを Haiku で埋める装置として機能する。
skill が小型モデルを伸ばす3つのメカニズム
元記事では、なぜ skill で Haiku が跳ねるかを3点で分解している。
① プロンプト圧縮
毎回「こういう流れで、こういう観点で、こう出力して」と自然言語で渡すのと、skill として固定された手順を呼ぶのでは、モデルが使う「推論の持ち札」の枚数が違う。推論力が限られている Haiku でも、手札を事前に配ってあれば負けない。
② 手順固定
手順が決まっているタスクでは、Opus が「自力で組み立てる」という優位が消える。skill で手順を固定することで、Haiku との差が縮まる。
③ 評価基準の明示
Haiku は自分で評価軸を組み立てるのは苦手だが、渡された軸で採点するのは得意だ。skill に「何を満たしたら完了か」を書くことで、この差が埋まる。
元記事の言葉を借りると「skill はモデルの推論力を補助輪で代替する装置」だ。補助輪があれば、ママチャリ（Haiku）でもロードバイク（Opus）と同じ舗装路を走れる。
ただし、補助輪は悪路では外れる。
SkillsBench のドメイン別の数字がそれを正直に示している。
- Software Engineering: +4.5pp
- Mathematics: +6.0pp
- Manufacturing: +41.9pp
- Healthcare: +51.9pp
モデルの事前学習で埋まっている領域（SE・数学）では skill の効果は薄い。汎用モデルが持っていない専門知識の空白が大きいほど、skill が効く。未知ドメインの設計判断や、長い文脈をまたぐ一貫性維持は今でも Opus の領域だ。
AIおじさんとしての見方
「上位モデルが強い」という観察は正しい。だが「どんな条件でも強い」という解釈は別の話だ。この記事が示しているのは、その条件を丁寧に分解したときに見えてくる構造だ。
一つ面白いと思った視点がある。
Healthcare で +51.9pp という数字は、そのまま「AI が人間の専門知識を補う」という文脈にも読める。SE のようにモデルが学習データをたっぷり持っているドメインでは、skill を挟んでも伸びしろが少ない。逆に、モデルの「空白」が大きい領域ほど、構造化された手順を渡す価値が高い。
これは「skill を書く価値があるドメインはどこか」という問いへの答えにもなる。汎用知識で対応できる領域に skill を書いても、リターンは小さい。
実務への落とし込み——モデルルーティングの考え方
元記事の著者は、実際の運用で以下のようなタスク層分けをしている。
| モデル | 対象タスク |
|---|---|
| Haiku 4.5 | 定型実装、文体固定の文章生成、構造化データ抽出、短命タスク |
| Sonnet 4.6 | 中程度の設計判断、コードレビュー、複数ファイルのリファクタ |
| Opus 4.7 | アーキテクチャ設計、新規ドメインの調査、長文脈での一貫性維持 |
著者自身の追試では「ベンチほどキレイな逆転は出なかった」とも正直に書かれている。タスク A（テスト生成）では Haiku + skill ≒ Opus、タスク C（文脈判断が多い候補抽出）では Opus が上回った。10 回ずつの雑な試行で統計的有意性はないが、傾向は明確だったという。
実務的に重要なのは、ここで出てくる設計の順序だ。
「どのモデルを使うか」より「skill を先に書く」。
モデルは skill が決まった後に、ハマる場所が見える。逆はない——というのが著者の結論だ。
ただし、立ち上げ期はその逆になる。まず Opus で手順を発見し、それを skill に落とす。発見は Opus、運用は Haiku という二段構えで、矛盾は解消される。
まとめ
SkillsBench の数字と追試が示したのは、「モデルの性能はそれ単体では語れない」という当たり前だが見落とされがちな事実だ。
Haiku 4.5 が 61.2% から 84.3% に伸び、Opus 4.7 の 80.5% を超えた。この逆転は skill という設計の一手で起きた。コスト削減は副次効果に過ぎない。本質は「タスクの性質に合った設計があれば、上位モデルに依存しなくていい」という構造の発見だ。
「高いモデルを使えば安心」は条件付きで正しく、条件付きで嘘だ。その条件を自分のタスクで確かめる価値は、今の AI 運用コストを考えれば十分にある。
