Claude CodeでAIを賢くするSkill設計、モデル選定より重要な理由

モデルを替えるより設計を替える。HaikuがOpusを超えた日

モデルを替えるより、設計を替える。

最新のベンチマークで衝撃の結果が出た。

小型モデルの Haiku 4.5 に Skill を持たせただけで、最上位の Opus 4.7 を超えた。

正答率は 61.2パーセント から 84.3パーセント へ跳ね上がった。

AIにどんな「補助輪」を履かせるかの設計が結果を左右する。

7,308回の試行が証明した「推論の補助輪」の威力

AIエージェントの性能を測る新しい指標が示された。

84のタスク 、 7つのモデル 、そして 7,308回 に及ぶ膨大な試行データが物語っている。

単にプロンプトを投げるだけでは、モデルの推論能力に限界がある。

世界中の開発者が注目しているのが Skill という概念だ。

これはタスクの手順を構造化し、AIが迷わないようにガイドする装置だ。

製造業や科学分析など、手順が明確な領域での効果が顕著だ。

ある検証では、正答率が最大で 51.9ポイント 向上した。

ソフトウェアエンジニアリング領域では向上幅は 4.5ポイント に留まる。

モデルが既にコードの書き方を学習済みだからだ。

モデルが知らない「プロジェクト固有のルール」を Skill に落とし込むのが効率的だ。

運用の鍵を握るのが Prompt Caching だ。

AIは通常、対話のたびに同じシステムプロンプトやツール定義を読み直す。

これをキャッシュすることで、APIコストは 8分の1 に、初動のレイテンシは 6倍 以上速くなる。

しかし、このキャッシュは繊細だ。

1バイトでも記述が変われば、キャッシュは壊れる。

システムプロンプトの末尾に「今日のタイムスタンプ」を1行入れただけで、数万トークンのキャッシュが毎ターン吹き飛ぶ。

設計の規律が、そのままコストと品質に直結する。

「どのモデルを使うか」という選択肢よりも、「どうキャッシュを効かせ、どう手順を固定するか」という設計判断が求められる。

AIエージェントを実戦的なチームメンバーへと変える道だ。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

しんたろー：
モデルの賢さに丸投げするのは思考停止だった。
手順を固定してキャッシュを効かせる。
泥臭い設計をサボると、API請求書を見て泣くことになる。

開発者目線の解説：発見はOpus、運用はHaikuの二段構え

「発見は Opus 、運用は Haiku 」。

これがこれからの開発における鉄則だ。

新しいタスクをどう解くか、ゼロから手順を考えるのは推論力の高い Opus の仕事だ。

一度手順が決まれば、それを Skill として固定し、低コストな Haiku に任せる。

これが開発者にとっての「AI API設計者」としての新しい役割だ。

具体的には、リポジトリ内に SKILL.md や known-failures.md を配置する運用が広まっている。

known-failures.md には、AIが過去にやらかした「嘘」や「勘違い」を記録する。

これを Claude Code に読み込ませることで、同じミスを二度とさせない。

AIのハルシネーションは「モデルの未熟さ」ではなく「LLMというアーキテクチャの性質」だ。

モデルに「気をつけて」と頼むのは無意味に近い。

検証ツールを工程に組み込み、機械的にチェックする仕組みが必要だ。

terraform validate や ESLint をAIの出力直後に走らせる。

この「検証の自動化」まで含めて Skill の設計だ。

僕の Claude Code 環境でも、この「手順の不動化」を意識している。

ツール定義の順序が変わるだけでキャッシュが外れる仕様はシビアだ。

そこを詰め切れば、AIは自律的なチームメンバーに昇華する。

Skill が小型モデルに効くメカニズムは3つに集約される。

第一に プロンプト圧縮 だ。

固定された手順を呼び出すことで、モデルの推論リソースを節約できる。

第二に 手順の固定 だ。

曖昧な指示から手順を組み立てるパワーを、実行そのものに振り向けられる。

第三に 評価基準の明示 だ。

何をもって完了とするかを Skill に書き込むことで、小型モデルでも自己採点が可能になる。

これは、モデルの推論力を「補助輪」で代替する装置だ。

補助輪があれば、ママチャリである Haiku でも、ロードバイクの Opus と同じ舗装路を走れる。

ただし、補助輪は悪路では外れる。

未知のドメインにおける設計判断や、複雑なトレードオフが絡む意思決定は、依然として Opus の独壇場だ。

この境界線をどこに引くかが、エンジニアの腕の見せ所だ。

しんたろー：
キャッシュを1バイトの狂いもなく守り抜くのは、もはや宗教に近い。
でも、その儀式を完遂した後にレイテンシが0.6秒まで縮む快感は、開発者なら一度は味わっておくべきだ。

実務への影響：キャッシュ経済圏での生き残り戦略

今すぐやるべきは、プロジェクト内の「暗黙知」を Skill 化することだ。

「このディレクトリの構成はこうあるべき」「テストはこのコマンドで叩く」。

これらを CLAUDE.md にダラダラと詰め込むのは古い。

独立した Skill ファイルに分け、必要な時にだけ呼び出す構造にする。

そして、キャッシュの境界線を意識したプロンプト設計を徹底する。

「不動のもの」と「揺れるもの」を明確に分ける。

日付、ユーザー入力、現在のブランチ名など、毎回変わる情報はプロンプトの末尾に配置する。

システムプロンプトの先頭部分は、神聖な領域として絶対に動かさない。

この規律を守るだけで、開発効率は変わる。

また、AIが書いたコードをそのまま信じない仕組みを構築する。

ラッパースクリプトを用意し、必ず検証コマンドを通してから人間が確認するフローを固定する。

「AIが賢くなったから検証は不要」という考えは、最も危険な罠だ。

賢いモデルほど、自信満々に「それっぽくて、かつ致命的に間違っている嘘」をつくからだ。

具体的には、以下の4層で事実検証を実装する。

1層目は プロンプト だ。

「推測と事実を区別せよ」という指示をシステムに組み込む。

2層目は コード検証 だ。

コンパイルや静的解析を自動で走らせる。

3層目は メモリ だ。

known-failures.md で過去の失敗を学習させる。

4層目は 外部参照 だ。

最新のドキュメントを直接読みに行かせる。

設計で嘘を検知し、設計でコストを抑える。

モデル選定の前に、この「土台」を作れるかどうかが、プロジェクトの成否を分ける。

AIエージェントを「ただの便利なチャット」で終わらせるか、「24時間戦える最強のパートナー」にするか。

その鍵は、リポジトリの中にある Skill の設計図にある。

しんたろー：
AIに嘘をつかれた時、モデルを責めるのは時間の無駄だ。
「あ、僕の検証設計が甘かったわ」と即座に切り替えて、チェック用のスクリプトを1行追加する。それが健全な付き合い方だ。

FAQ：Skill設計とキャッシュ運用の核心

Q1: Skillを導入すると、モデルをHaikuに下げても大丈夫ですか？

タスクによります。CRUD操作やテスト生成など「手順が固定可能なタスク」であれば、 Skill によって Haiku は Opus と同等以上のパフォーマンスを発揮します。一方で、未知のドメインにおける設計判断や、長い文脈をまたぐ一貫性が求められるタスクでは、依然として Opus の推論能力が必要です。まずは定型タスクから Skill 化し、 Opus を「手順の発見」に集中させる運用が効率的です。

Q2: Prompt Cachingが効いているか確認する方法はありますか？

APIのレスポンスに含まれる usage 情報（ cache_read_input_tokens 等）を確認するのが確実です。設計上の注意点として、システムプロンプトの末尾にタイムスタンプを入れたり、 MCP ツールの順序が毎回変わるような実装をしていると、キャッシュ境界が破壊され、キャッシュヒット率がゼロになります。キャッシュは「不動のもの」と「揺れるもの」の境界設計が全てです。

Q3: ハルシネーション対策として最も効果的なファイル構成は？

リポジトリのルートに known-failures.md を作成し、そこに「AIが過去に間違えた具体的な事例」と「その正しい対処法」を箇条書きで並べるのが強力です。これを CLAUDE.md から参照させることで、AIは「このプロジェクト特有の落とし穴」を常に意識した状態で作業できるようになります。「気をつけて」という抽象的なプロンプトよりも、具体的な失敗例の方が、モデルの出力分布を強力に補正します。

まとめ：モデルを崇める時代は終わった

モデルの性能差に一喜一憂するフェーズは過ぎた。

これからは Skill を設計し、キャッシュを管理し、検証を自動化するエンジニアが勝つ。

AIを「賢い神様」として扱うのではなく、「手順に忠実な職人」として飼い慣らす。

そのための道具は、もう手元に揃っている。