Claude CodeのSkill（サブエージェント）を、このブログの運用リポジトリで11個運用している。今回は、その設計で決めたことを書く。作り方そのものは公式ドキュメントに書かれているので、ここでは実際に運用して分かった分割の基準とモデルの割り当てに絞る。
先に結論を書くと、効いたのは2点だった。SKILL.mdを30行前後に保って本体を別ファイルへ置いたことと、軽いモデルから始めて必要な場合だけ上げるという割り当ての順序を守ったことだ。
運用中の11個とその構成
現在のSkillはこうなっている。
| Skill | モデル | SKILL.mdの行数 |
|---|---|---|
| x-post-generate（投稿案の量産） | sonnet | 29行 |
| x-post-quality-check（品質の採点） | haiku | 31行 |
| x-post-analyze（実績の分析） | sonnet | 29行 |
| threads-post-generate / reply / comment | sonnet | 28〜29行 |
| threads-post-quality-check | haiku | 29行 |
| content-hypothesis（仮説立案） | opus | 29行 |
| loop-review（仕組みの棚卸し） | opus | 31行 |
11個のうち10個が30行前後に収まっている。これは意図的にそうしている。
SKILL.mdは索引にして、本体は別ファイルへ置く
最初はSKILL.mdに手順を全部書いていた。長いものは200行を超え、Skillを呼ぶたびにその全文が読み込まれる。
今は構造を分けている。
.claude/skills/x-post-generate/SKILL.md 29行（索引）
prompts/x-post-generate.md 63行（本体の手順）
prompts/x-post-generate-reference.md 154行（参照資料）SKILL.mdに書くのは、どこに何があるかと、いつ何を読むかだけにした。
まず、同じworktree内の[共有プロンプト](リポジトリ直下のprompts/x-post-generate.md)を読み、
依頼に該当する手順に従う。
## 参照資料
共有プロンプトが求める資料と、依頼に該当する資料を次の直接リンクから読む。
条件に当てはまらない資料を一括で読み込む必要はない。
- 発信者設定・トーン・題材を確認するとき：[投稿作成の詳細資料](...)
- 投稿の役割・配分を決めるとき：[Xの運用方針](...)
- 過去の実績に基づいて方針を変えるとき：[実績評価の基準](...)肝は最後の3行だ。条件と読むべきファイルを対にして並べる。「関連資料」としてリンクだけ並べると全部読まれるが、「〜するとき」を添えると必要なものだけが読まれる。
この分離にはもう1つ効果があった。手順の本体がprompts/にあるので、Skillを経由せず人間が直接読める。Skillの中身を確認するのに、Skillを起動する必要がない。
モデルは3段階、軽い方から割り当てる
11個のSkillにhaiku・sonnet・opusを割り当てている。基準はこう決めた。
| モデル | 割り当てる仕事 |
|---|---|
haiku |
基準が明文化されており判断の幅が無い仕事（配点・文字数・禁止ワードの検査） |
sonnet |
型は決まっているが文章の質・相手への配慮が要る仕事（制作・返信・分析） |
opus |
過去の判断との整合や全体の抜けを見る仕事（仮説立案・棚卸し） |
順序が大事で、まず一番軽いモデルを当ててみて、足りなければ上げる。最初から上位モデルを当てると、そのSkillが本当にその性能を要するのかが分からないままになる。
実際に分かったのは、品質チェックがhaikuで十分だったことだ。文字数・禁止ワード・書き出しの重複といった項目は、基準が数値で書いてあるので判断の幅がない。ここにsonnetを当てても結果は変わらなかった。
逆に、opusでないと務まらなかったのが棚卸しと仮説立案だった。この2つに共通するのは過去の判断を踏まえる必要があること。「前回こう判断したから今回はこう」という連続性の確認は、軽いモデルだと抜ける。
1つのSkillを3つに分けた判断
x関連のSkillは、もともとx-post-generateの1つだった。これを生成・品質チェック・分析の3つに割った。
きっかけは、Threads側が3分割なのにX側が2分割という非対称に気づいたことだった。同じ役割のSkillが、チャネルによって粒度が違う。これは設計の意図ではなく、単に作った時期の違いで生じたズレだった。
分けてよかった点は3つある。
- モデルを個別に割り当てられる: 品質チェックだけhaikuにできる。1つにまとまっていると、一番重い仕事に合わせて全体のモデルを上げるしかない
- 呼ぶ側が必要な工程だけ呼べる: 既存の投稿案を採点し直すとき、生成の手順を読む必要がない
- チャネル間で構造が揃う: ThreadsとXで同じ名前の工程が同じ粒度で存在するので、片方の改善をもう片方へ移しやすい
分ける単位は「工程」にした。生成→チェック→分析は、それぞれ入力と出力がはっきり違う。入出力が同じなら分けない、違うなら分けるというのが結局いちばん迷わない基準だった。
自己評価を避けるために、立案と評価を分ける
もう1つ、Skillを分ける理由がある。立案と評価を同じセッションで完結させないことだ。
仮説を立てたモデルにその仮説の妥当性を評価させると、通ってしまう。これは能力の問題ではなく構造の問題で、立案の過程で作った前提が評価の前提にもなるため、そもそも疑えない。
対処として、判断が要る工程には結論を伏せて一次データだけを渡す別セッションのレビューを挟む運用にしている。Skillの設計側でも、生成と評価を別のSkillに分けておくと、この運用が自然に回る。
ただしこれは全部の工程でやることではない。毎回2倍の手数をかける価値があるのは、後から覆すコストが高い判断（施策の効果判定、方針の転換）に限られる。
作るときに確認している4点
新しくSkillを作るときの確認をまとめておく。
- SKILL.mdは索引に徹しているか: 手順の本体は別ファイルへ。30行前後を目安にする
- 参照資料に「〜するとき」が添えてあるか: リンクを並べるだけだと全部読まれる
- 一番軽いモデルから試したか: haikuで足りるものにsonnetを当てていないか
- 入出力が違う工程を1つにまとめていないか: まとめていると、モデルの割り当ても呼び出しも粗くなる
まとめ
- SKILL.mdは索引にして、手順の本体は
prompts/等の別ファイルへ置く。11個のうち10個が30行前後に収まっている - 参照資料は「〜するとき：リンク」の形で条件と対にする。リンクだけ並べると全部読まれる
- モデルは軽い方から割り当てる。基準が数値化されている検査はhaikuで足り、過去の判断との整合を見る仕事はopusが要る
- 分ける単位は「工程」。入出力が違うなら分ける、同じなら分けない
- 立案と評価を同じSkillに含めない。ただし別セッションレビューは、覆すコストの高い判断に限って使う
