Sonnet 5でもスキルの品質を落とさない — Claude Codeスキル最適化パイロットの記録

統括役は上位モデルに任せておけばいい。でも、実際に手を動かすサブエージェント側に Sonnet 5 を差し込んだとき、出てくる成果物が一段落ちるんじゃないか——この不安を、今日は勘で片付けず、欠陥を仕込んだテキストを Sonnet 5 に校正させて検出率で採点するところまでやってもらった。結論から言うと、「スキルを見直せば必ず良くなる」という思い込みは、今日はっきり否定された。

なぜ気になったか

Claude Code の作業は、統括役のモデルが計画を立てて、細かい実装や校正はサブエージェントに投げる形が多い。統括役はコストの都合で上位モデルにするとして、大量に走らせるサブエージェント側を Sonnet 5 にすると、単価は下がるが品質も一緒に下がるんじゃないか、というのがずっと引っかかっていた。

しかもうちのスキル（Skills）は、文章校正や図解の判断を AI 側の裁量に委ねているものが多い。手順が決まっている作業なら誰がやっても同じだが、「この修飾語の順序はおかしい」「この読点は不要」みたいな判断は、モデルの地力に直結する。ここが Sonnet 5 で崩れると、校正記事の品質が静かに落ちる。

そこで「Sonnet 5 でも品質が落ちないようにスキルを最適化する」パイロットを走らせることにした。まずはユーザーレベルのスキルだけに絞って、ざっと調査させるところから始めた。

調査：スキルは3タイプに分かれ、リスクは偏っていた

ユーザーレベルの29本を Claude Code に調べさせた。結果、スキルは大きく3タイプに分かれていて、品質が落ちるリスクはきれいに偏っていた。

• 手順型（DBに保存する、メールを検索する等）：やることが決まっているので、Sonnet 5 でもほぼ崩れない。すでに耐性が高い
• 知識型（原則やチェックリストを読ませるだけ）：判断を伴わないので、これも崩れにくい
• 判断依存型（文章校正・図解）：ここが本丸。「良い／悪い」を AI が自分で決めるので、地力が落ちると成果物が落ちる

つまり手を入れるべきは判断依存型に集中している、と分かった。全部を触る必要はない。

最適化の型：指示を増やすのではなく、判断を検証可能にする

ここで一つ縛りがあった。上位モデル（Fable 5 系）は、手順を細かく指示しすぎると逆に品質が落ちる性質がある。だから「Sonnet のために指示を増やす」と、上位モデルで走らせたときに足を引っ張る。両方のモデルで共存できる方向として置いたのが、指示を増やすのではなく、判断を検証可能な形に変えるという型だった。

具体的にはこの5つ：

1. 判断→検証ゲート化：原則は残したまま、「出力後にチェックリストを回して、不合格は直してから完了報告する」自己検証ループを足す
2. 参照の必読化：「必要なら読む」を「着手前に必ず Read する」に格上げする
3. 1パス1観点の推敲：全観点を一度の通読でまとめて見ず、観点ごとに通読を分ける
4. 機械チェック：禁止表現や内部用語の漏れは grep コマンドをスキルに同梱する。これはモデルの地力に一切依存しないので最強
5. 完了前チェック（DoD）+報告テンプレ：「コマンドを打った＝完了」の早すぎる宣言を防ぐ

パイロット：欠陥を仕込んで検出率で採点

いいね、と思って進めさせた。対象は判断依存型の3本（honda-sakubun / japanese-tech-writing / doc-communication）。

検証は勘に頼らず、採点できる形にした。校正スキルには、わざと欠陥を仕込んだテキストを食わせる。honda-sakubun 用には8つの欠陥（修飾語の順序ミス、不要な読点など）と、わざと直させない罠の1文（変更してはいけない正しい文）を1つ混ぜた。japanese-tech-writing 用には欠陥11個と罠を1つ。これを Sonnet 5 のサブエージェントに校正させ、実際に書き換わったファイルの diff を突き合わせて「いくつ拾えたか」を n=3 で採点した。

before のスナップショットを先に保存してから、旧版と新版で同じタスクを走らせて比較する。実ファイルの diff で数えるので、「拾えたはず」ではなく「実際に拾った数」で採点できる。校正させるサブエージェントは、本番のスキルファイルを読んでいる間は編集できないので、走らせては待ち、集計しては次を走らせる、の繰り返しになった。

もう一つ効いたのが「1パス1観点」の推敲だ。修飾語の順序、読点、助詞……といった観点を1回の通読でまとめて見ようとすると、Sonnet はどれかを取りこぼす。観点ごとに通読を分ける（同じテキストを何度も頭から読み直す）ように書き換えたら、拾い漏れが減った。人間がやると面倒な多重読みも、AI なら淡々と繰り返す。

つまづき：善意の追加ルールが検出率を下げた

ここで事故が起きた。これが今日いちばんの収穫だった。

新版v1に「過剰修正の禁止（正しい文を念のため書き換えていないか）」というゲートを足したところ、honda-sakubun の欠陥検出率が 22/24 → 17/24 に落ちた。追試のログを diff で突き合わせると、Sonnet が「過剰修正を避けて原文を維持する」と自分で明言して、優先順位が下（修正推奨・任意）の欠陥をまとめて見送っていた。品質を守るつもりで足した1項目が、Sonnet を保守側に倒して、拾えていたはずの欠陥まで取りこぼさせていた。

原因が見えたので、抑制ルールを単独で置くのをやめて、必ず「見送り禁止」とペアにするように直した。「優先順位1・2の問題はすべて修正する（見送り禁止）」と「違反原則を1つも挙げられない文は書き換えない」を両輪にする。これを入れた新版v2で、honda は 23/24 まで戻り、旧版を上回った。ランごとに見ると、旧版は 8/8・7/8・7/8、v2 は 7/8・8/8・8/8。取りこぼしが1回減っただけの差だが、少なくとも「悪化はしていない」ことを diff で確認できた。罠として仕込んだ「変更してはいけない正しい文」は、全ランを通して正しく温存されていた。

japanese-tech-writing と doc-communication は、旧版の時点で Sonnet 5 が既に高品質だった。スキルの中に「NG例／OK例」が豊富に入っているからだと思う。新版の価値は品質そのものより、機械チェックの結果やパスごとの修正数が報告に載るようになった監査可能性のほうにあった。

結論：「見直せば必ず良くなる」は否定された

途中で「これは結局、見直した方が良かったってことなのか？」と自分でも聞き直した。正直な答えは「見直しは残す価値があるが、劇的な品質向上ではない」だった。

数値ではっきり品質が上がったのは honda の1点だけ（22/24→23/24、しかも n=3 なので誤差の範囲）。それより今日はっきりしたのは逆のことで、善意の追加ルールが Sonnet の品質を実際に落とすことがある、という事実だった。v1で足した「過剰修正の禁止」1項目だけで 17/24 まで悪化したのが動かぬ証拠だ。「スキルは丁寧に手を入れるほど良くなる」は幻想で、NG/OK例が既に豊富なスキルは、下手にいじらないほうが安全だと分かった。

手順型には別の薬：DoD だけを足す

判断依存型とは別に、手順型のスキルには違う処方をした。ここで効くのは校正の精度ではなく、「やり切ったか」の担保だ。Sonnet は「コマンドを打った＝完了」と早めに宣言しがちなので、各スキルの末尾に「完了前チェック」を1個だけ足させた。中身は3つ——①実物を確認する完了条件（「実行した」ではなく「結果を確認した」を完了の定義にする）、②件数を明示する報告テンプレ、③0件だったときのフォールバック。パイロットの教訓に従って、抑制系のルールは入れず実行義務だけで組んだ。

対象は手順型10本の候補。うち6本（add-task / codex-image-gen / note-title-generator / tax-doc-rename / turso / x-search）に DoD を足した。agent-browser と find-skills は外部管理のシンボリックリンクだったので、勝手に編集すると更新で消える恐れがあり見送り。残り2本は判断を伴わない知識型なので対象から外した。ここも「全部に一律で足す」をやらず、実態を見て外すものは外した。

最後にコミットまでさせた。変更は2リポジトリに分けて入れた。ユーザーレベル側は判断依存型3本の検証ゲート化と手順型6本のDoD追加で9ファイル・139行の追加、mdx-playground 側は今日の検証記録の memo を1本。理科の Vue コンポーネントの既存変更は関係ないので、このコミットには混ぜなかった。

今日の学び

• 保守化ゲートは単独で入れない。 「過剰修正の禁止」のような抑制ルールを裸で置くと、Sonnet は安全側に倒れて拾えるものまで見送る。必ず「見送り禁止」とペアで入れる
• NG/OK例が豊富なスキルは下手に触らない。 検証したら旧版で既に高品質だった。手を入れる価値があったのは、判断が言語化されていないスキルだけ
• 勘で「見直そう」と言わない。 欠陥を仕込んで diff で採点する形にしたから、v1の退行に気づけた。採点できる形にしていなかったら、悪化させたまま「最適化した」と満足していた
• 自分は「どこを疑うか」を決める係、実際に29本を読んで欠陥テキストを校正して diff を数えるのは AI の係。この分担は今日も崩れなかった

残タスクは、判断依存型の横展開（ただし NG/OK例が豊富なものは触らない方針を再確認してから）と、プロジェクトレベルのスキルへの同じ型の適用。横展開のときも「保守化ゲート単独禁止」だけは、今日の memo を読み返してから守る。