Claude Code の自作スキルが、気づけば 29 個になっていました。これで個人ブログの企画から WordPress 公開までを自動化しています。正直、ここまで増えたら管理が破綻すると思っていました。でも、いまのところ壊れていません。効いたのは、たぶん「どこで分けるか」と「どこで止めるか」を先に決めたこと。この記事では、その設計判断と、うまくいかなかった3つを、リポジトリの実コードのまま書きます。
結論：29 個に増えても壊れないのは「分け方」と「止め方」を決めたから
結論から言うと、スキルは増やすほど良いわけではありません。増やせば、呼び出し回数もトークンも管理コストも一緒に増えていきます。それでも 29 個を回せているのは、次の3つのルールを最初に決めておいたからです。
- 分けるのは「自分で自分を採点する利益相反がある所」と「失敗モードが全く違う所」だけ
- 自律で回すスキルには、必ず止める仕掛けを3層で付ける
- 新しい抽象化（MCP など）を使うこと自体を目的にしない
この記事は、以前書いたClaude Code の便利な使い方の裏側にあたります。あちらが「何ができるか」なら、こちらは「どう設計したか」。29 個すべてを自分の手で書いて、毎日実際に使ったうえでの話です。SE を5年やって、いまは AI 開発に振り切っている立場から、きれいごと抜きで書きます。
何を作ったか：5 レイヤー・29 スキルの全体像
まずは全体像から。スキルは学習・試行・補強・販売・改善の5レイヤーに分けて設計しました。内訳は自作の koma-* が 26 個、WordPress 公式から取り込んだものが3個で、合計 29 個です（リポジトリの .claude/skills/ 直下の実数）。
記事制作の中核だけ取り出すと、こういう流れになります。
- ネタ出し → 調査 → SEO 設計 → 執筆 → 品質チェック → WP 投稿 → アイキャッチ生成
- この一連を、司令塔スキル（orchestrator）が品質基準を満たすまで自律で回す
1スキル1ファイル（SKILL.md）で、先頭に名前と説明（description）を書きます。この description が、どんなときにそのスキルを起動するかの判定材料になる。ここからが本題の設計判断です。
設計判断1：1スキル1責務（writer と gate を分けた理由）
ここはわたしが一番こだわった分け方です。「書く」と「採点する」を、なぜ同じスキルに持たせてはいけないのか。
記事の下書きを書くスキル（article-writer）と、その合否を出すスキル（quality-gate）は、わざと別々にしています。一つにまとめると、自分の文章を自分で甘く採点する利益相反が起きるからです。これは人間でも同じで、書いた本人がレビューすると、どうしても甘くなりますよね。
分けたことで、関係が非対称になりました。quality-gate のルールには「自動で修正を加えない（提案のみ・適用は writer が行う）」と明記してあります。採点役は指摘だけして、直すのは書き手に戻す。この非対称があるから、差し戻しループがちゃんと成立します。
さらに quality-gate は、合否を構造化した JSON（status と失敗理由の配列）で返します。司令塔はその JSON を見て、PASS なら次へ、FAIL なら書き手へ、と機械的に分岐できる。文章で「だいたい良さそう」と返されたら、自動では判断のしようがありません。
とはいえ、何でも分ければいいわけではありません。分けるほど呼び出しは増えていきます。だからこそ「合否の利益相反がある所」だけを切りました。
設計判断2：暴走を止める3層（最大ループ・同一エラー検知・STOP ファイル）
自律ループを安全に回すには、結局どこで止めるかが勝負です。具体的な止め方を順に見ていきます。
自律ループで一番こわいのは、同じ失敗を延々と繰り返してトークンを溶かすことです。これを防ぐために、司令塔スキルには3層の安全装置を入れました。
- 最大ループ回数：調査は2周、執筆と品質チェックは3周、投稿は1周で打ち切る
- 同一エラー検知：前回と品質チェックの失敗理由が完全一致したら、即その場で止める
- STOP ファイル：作業フォルダに
STOPという空ファイルがあれば、次の工程へ進まない
1層目は回数の上限。2層目は「進歩していない」ことの検知です。回数が残っていても、同じ理由で2回落ちたなら、それ以上回しても直りません。だから即止めます。3層目は人間用の非常停止で、STOP ファイルを置くだけで、わたしがいつでも割り込める仕組みにしてあります。
この設計、実際に効きました。最初に公開したテスト記事は、執筆と品質チェックのループが2周で収束しています（1周目は軽微な指摘で FAIL、2周目で全ゲート通過）。3周の上限内に収まりました。上限を何周にすべきかは、正直、実際に回してみるまで分かりませんでした。
あわせて、1記事あたりの検索回数や推定トークン量にも上限を置いています。情報を集めすぎると、かえって記事が散らかってしまうんですよね。
設計判断3：MCP を捨てて WP-CLI 直叩きにした理由
新しい仕組みを「採用しない」という判断も、立派な設計です。それがよく分かったのが、ここでした。
WordPress への投稿は、最初 MCP サーバー経由を検討しました。でも結局やめて、WP-CLI を直接呼ぶ形に戻しています。理由は3つです。
- npm パッケージの相性問題に時間を取られた
- 認証情報を設定ファイルに書く必要があり、管理が増える
- サーバーを常駐させる起動コストが、得られる便利さに見合わない
「ローカルの WordPress に下書きを1本作る」くらいの決まりきった作業に、サーバー常駐と認証管理はさすがに重すぎました。投稿スキルの実体は、PowerShell から wp post create を呼ぶだけ。依存も認証も起動コストも、ぐっと減りました。
もっとも、これは条件付きの判断です。リモートの本番に REST 越しで触りたい、複数サイトを横断したい、という要件なら、MCP の抽象化はちゃんと効きます。わたしの場合はローカル単一サイトだったので、CLI 直叩きが一番軽かった、というだけの話。新しいから使う、ではなく、要件に合うかで選びました。
本番への誤爆を防ぐ仕掛けも、ここに入れています。環境の判定は、設定フラグではなく WordPress 自身が持つ siteurl を見る方式です。ローカル（.local）なら公開、それ以外（本番ドメイン）なら必ず下書き止まり。設定の書き間違いで本番に出てしまう事故を、判定の作りそのもので防いでいます。これが地味に効きます。
設計判断4：アイキャッチを別スキルに切り出した理由
外部 API に依存する処理は、本体から切り離す。これがこのセクションで言いたい基準です。
アイキャッチ画像の生成は、投稿スキルに混ぜず、専用スキルに切り出しました。WP 投稿とは性質が3つ違うからです。
- 外部 API（OpenAI の画像生成）に依存し、失敗の種類が投稿とまったく別
- 1枚ごとにお金がかかる（推定で1枚 0.05 ドル前後）
- 「気に入らなければ作り直す」という独自の流れを持つ
これを投稿ロジックに混ぜると、投稿スキルが太って、失敗したときの切り分けが一気に難しくなります。認証エラーなのか、サイズ指定の問題なのか、それともレート制限なのか。画像特有の失敗は、画像スキルの中だけで完結させたほうが、ずっと追いやすい。だから「外部 API 依存 × コスト発生 × 独自の作り直し」がそろう部分を、まるごと外に出しました。
29 個あっても重くない理由（progressive disclosure）
「そんなに作ったら起動が重いのでは」とよく聞かれます。これが、重くならないんです。Claude Code のスキルは progressive disclosure（段階的開示）という仕組みで動くからです。
起動時に読まれるのは、各スキルの名前と説明だけ。Anthropic の公式ドキュメントでは、これが1スキルあたり約 100 トークンと説明されています。本文がまるごと読み込まれるのは、その説明がいまのタスクに一致したときだけです。
だから 29 個あっても、起動時のコストは説明文ぶんだけで済みます。公式は SKILL.md の本文を500 行未満に保つことも勧めています。わたしが規約を本文に詰め込まず、文体ルールや品質基準を別ファイルに分けているのも、この考え方に沿ったものです。
向かない場面・うまくいかなかった3つ
うまくいった話だけ書くのはフェアではないので、失敗と限界もちゃんと残しておきます。
1つめ：マルチエージェント化はあえてやめました。スキルどうしを自由に会話させる構成も考えたのですが、採用していません。Anthropic 自身が、複数エージェント構成は単一エージェントに比べてトークンを3〜10倍消費し、調整コストも増えると書いています。逐次的で決まりきった工程なら、単一のほうが速くて安くて、原因も追いやすい。だから司令塔は、決まった順番で進む決定論的なパイプラインにしました。会話で協調はさせていません。
2つめ：MCP に寄せようとして時間を溶かしました。前述のとおり、新しい抽象化を使うこと自体が目的になりかけたんです。相性問題と認証管理で詰まって、CLI 直叩きに戻すまでにかかった時間は、正直もったいなかった。「便利そうだから」で技術を選ぶと、こうなります。
3つめ：この構成は汎用フレームワークではありません。1人が1サイトをローカルで運営する前提に、徹底的に寄せて作っています。複数人で編集権限を分けたい、複数サイトを回したい、本番に直接書き込みたい、となったら、CLI 直叩きもローカル前提も siteurl 判定も、前提ごと作り直しです。誰にでも合う形ではありません。
まとめ：分けるのは「利益相反」と「失敗モードが違う所」だけ
- スキルは増やすほど良いものではない。呼び出しも管理コストも増える
- 分ける基準は2つだけ。自分で自分を採点する利益相反がある所と、失敗の種類が全く違う所
- 自律で回すなら、回数上限・同一エラー即停止・STOP ファイルの3層で必ず止められるようにする
- 新しい仕組みは「便利そう」ではなく「要件に合うか」で選ぶ。合わなければ捨てる勇気を持つ
- progressive disclosure のおかげで、数が増えても起動は重くならない
Claude Code の自作スキルは、数を競うものではなく、分け方と止め方を設計するものだと思います。わたしも最初は3個から試しました。まずは2〜3個を、利益相反のある所で割ってみる。それで十分なスタートになります。
もっと他の開発実践も読みたい方は、開発実践記録のカテゴリものぞいてみてください。
同じ仕組みを自分の業務に組みたい方へ
自分の会社の作業も、こういう自動パイプラインに乗せられないか。そう感じた方へ向けて、業務に合わせた AI ワークフローの設計と構築支援もしています。30 分の無料相談から始められます。 → サービス詳細はこちら
