Claude Code スキル設計でルールが衝突したら。優先順位を先に1行で交通整理する

AIに渡すルールを増やしていくと、ある時点からルール同士が矛盾し始めます。「太字は使うな」と書いたスキルと、「見出しで構造を作れ」と書いたスタイルガイドが、同じ記事を生成するときに正面からぶつかる。こういう瞬間です。

厄介なのは、人間なら「どっちを優先すべきか」と聞き返すところを、AIは聞き返さないことです。Claude Codeに複数のルールを渡すと、矛盾したまま走り、片方を黙って無視した結果を返してきます。どちらを無視したかは出力を見るまでわからない。再現性もない。今日は文体ルールが勝ち、明日は構造ルールが勝つ、ということが起きます。

この記事は、Claude Code のスキル設計で「ルール同士が衝突する場所を、衝突する前に交通整理しておく」やり方を、ある案件のSEOブログ運用で実際にやった例で書きます。情報をどこに置くかという置き場所の設計ではなく、置いたルールが互いにぶつかったときどちらを勝たせるか、という一点に絞ります。

結論：2層に分けて、衝突の優先順位を先に1行書く

やることは2つだけです。

1. ルールを「汎用レイヤー」と「プロジェクト固有レイヤー」の2層に分ける
2. 2層が矛盾しうる軸について、どちらが勝つかを先に1行で決めておく

最小構成にすると、こうなります。

2層に分けるところまでは、よくある情報設計の話です。差がつくのは3つ目です。「文体は汎用、構造はプロジェクト」のように、ぶつかる軸ごとにどちらが勝つかを先に書いておく。これがあると、矛盾が起きてもAIが迷わず、出力が安定します。逆にこの1行が無いと、2層に分けても衝突地点でAIがサイコロを振り始めます。

以下、なぜ2層に分けたのか、なぜ優先順位を「先に」書く必要があったのかを、実際に起きた順番で書きます。

実話：同じルールが3か所にあった

最初の問題は衝突ではなく、重複でした。

ブログ記事の執筆スキルを作ったとき、「AIっぽい文章を消すルール」を3つの場所に書いていました。全社共通の出力品質ルール、脱AI専用の変換スキル、そしてプロジェクト固有のスタイルガイド。書いた直後はどれも同じ内容で整合していました。

乖離が始まったのは、脱AI変換スキルに禁止表現を追加した日です。変換スキル側だけを直して、スタイルガイド側は古いまま放置になりました。2週間もすると、どのファイルが正しいのかわからなくなる。AIに渡すと、古いルールと新しいルールが混ざった出力が返ってきて、なぜそうなるのか追うのに時間を取られました。

直し方そのものはシンプルです。コピーをやめて、参照に変える。3か所に同じことを書くのではなく、1か所に書いて他から参照する。ここまでは置き場所の整理で済みます。情報全体をどこに置くかという設計は複数クライアントを1つのClaude Code環境で管理する情報設計で書いたので、そちらに譲ります。

問題は、参照に変えて1か所に統合しようとした瞬間に、別の壁にぶつかったことです。すべてを汎用に寄せると、プロジェクト固有の事情が押し潰される。逆にプロジェクト側に寄せると、また重複が始まる。どこかで線を引く必要がありました。

2層の分け方（線は1本だけ）

線の引き方は1本だけ決めればよく、判定基準は「案件をまたいで同じか、そうでないか」です。

汎用レイヤーに置くのは、プロジェクトに関係なく使えるルールだけです。脱AI文体の変換ルール、事実性チェック、トピッククラスター設計の手法。これらは案件をまたいで同じものを呼ぶので、コピーせず参照します。

プロジェクト固有レイヤーに残すのは、その案件でしか通用しないものだけ。読者像、トーン、具体的なクラスタの割り当て表、CTA先のURL、クライアント名の伏せ方。使い回しが利かないので、プロジェクトのスタイルガイドに直接書きます。

スタイルガイドの冒頭に「汎用レイヤーのスキルを土台とし、以下はプロジェクト固有の追加と上書き」と一文入れる。これで依存の方向がはっきりして、重複が消えました。

ここまでで重複は解決します。けれど、まだ衝突は解決していません。「土台にする汎用」と「上書きするプロジェクト」が、同じ軸で正反対のことを言っていたらどうなるか。それが次に起きた問題でした。

実話：ルールが衝突した日

衝突は、脱AI変換スキルとブログのスタイルガイドの間で起きました。

脱AI変換スキルには「Markdown記法を全面禁止」と書いてありました。AIが生成する文章は、頼んでもいないのに太字や箇条書きを乱用しがちで、それを消すためのルールです。一方、ブログのスタイルガイドには「H2やH3で見出し構造を作れ」と書いてありました。SEOの観点で、見出し階層は記事に必須だからです。

見出しもMarkdown記法です。つまり、汎用スキルは「Markdownを使うな」と言い、プロジェクト固有設定は「見出し（＝Markdown）を使え」と言っていた。同じ記事を生成するときに、この2つが正面からぶつかりました。

このときAIが返してきたのは、見出しの無いベタ書きの記事でした。汎用スキルの「Markdown禁止」を優先して、スタイルガイドの「見出し要求」を黙って無視したわけです。けれど別のタイミングでは逆に、見出しは付いたが太字も大量に付いた記事が返ってきたこともありました。どちらを勝たせるかをこちらが決めていなかったので、AIがそのつど勝手に裁いていたのです。

矛盾を検出してエラーで止まってくれるなら、まだ気づけます。黙ってどちらかを無視されると、出力を1本ずつ目視するまで気づけません。これが、ルールを増やすほど効いてくる隠れコストです。

優先順位の交通整理（具体的にどう書くか）

解決は、汎用スキルの冒頭に優先順位を1行書くことでした。実際に書いたのは、こういう趣旨の文です。

文体のルールは汎用が常に適用される。構造と記号のルール（見出し・箇条書き・コードブロック）はプロジェクト側が上書きできる。

これで衝突が裁けます。「Markdown禁止」は記号のルールなので、プロジェクト側の「見出しを使え」が上書きする。一方で「太字の乱用を消す」は文体のルールなので、プロジェクト側が何を言おうと汎用が勝つ。同じMarkdownでも、見出しは通って太字の乱用は弾かれる、という挙動になりました。

ポイントは、矛盾が起きてからAIに判断させるのではなく、起きる前に交通整理しておくことです。ルールを書く順番を整理すると、こうなります。

1. ぶつかりうる軸を洗い出す（文体／構造／記号／事実性 など）
2. 軸ごとに「汎用が勝つ／プロジェクトが上書き可」を決める
3. その判定を汎用スキルの冒頭、つまりAIが最初に読む位置に書く

3つ目の「最初に読む位置に書く」が地味に効きます。優先順位のルールが末尾に埋もれていると、AIがそこに辿り着く前に矛盾を裁いてしまうからです。裁定ルールは、裁かれる対象より前に置く。

軸の数は最初から多くしなくてよく、衝突が実際に起きた軸から1つずつ足していけば十分です。実際、最初に決めたのは「文体は汎用、構造と記号はプロジェクト」の1軸だけでした。

Before / After

優先順位を1行書く前と後で、何が変わったか。

汎用スキルを1回直すと全プロジェクトに反映される、という2層分離の効果はそのまま残ります。脱AI変換スキルに禁止表現を足すと、ブログの執筆にも別クライアントの記事制作にも同時に効く。それまでは「あっちのファイルも直さなきゃ」を毎回繰り返していました。スタイルガイドの分量も、汎用に委譲した分がごっそり消えて半分以下になりました。

アンチパターン：やってはいけないこと

設計の途中でやりかけて、戻したものを残しておきます。

汎用のルールをプロジェクトのフォルダにコピーする。 直した瞬間に2か所の乖離が始まります。最初に詰まった「3か所に散らばる」の再発です。参照にする。コピーしない。

プロジェクト固有の読者像を汎用スキルに書く。 逆方向の混入です。特定案件の読者像を汎用側に書くと、別の案件で生成するときにノイズになります。分離のラインは「案件をまたいで同じか、そうでないか」だけ。それ以外の基準で切らない。

組み合わせるスキルの数を最初から増やす。 スキルは最初3〜4個に絞って動かし、不足を感じてから足すほうが安全です。5個を超えると、スキル間で矛盾しうる組み合わせが急に増えます。衝突の交通整理は、組み合わせが少ないうちに型を作っておくほうが楽です。

衝突の優先順位を末尾に書く。 裁定ルールが本文の後ろにあると、AIが矛盾に出くわした時点でまだ読んでいない、ということが起きます。優先順位は汎用スキルの冒頭、AIが最初に通る位置に置く。

導入チェックリスト

自分のClaude Code環境に当てはめるなら、次の順で確認してください。

• 同じ趣旨のルールが2か所以上にコピーされていないか（あれば1か所に寄せて参照に変える）
• 2層の線は「案件をまたいで同じか」で引けているか（読者像・CTA先などは固有側へ）
• 過去にAIが「指示の片方を無視した」出力を返したことがないか（あれば、その軸が衝突地点）
• 衝突しうる軸ごとに勝ち負けを1行で決めたか（文体／構造／記号／事実性など）
• その優先順位を汎用スキルの冒頭に書いたか（末尾NG）
• 組み合わせるスキルは3〜4個から始めているか（最初から増やさない）

この6つが埋まれば、ルールを後から足しても衝突が予測可能になります。

関連する記事

• Claude Skillsガイド
• Claude Codeの使い方

まとめ

Claude Code のスキル設計で増えていくのは、ルールの数だけではありません。ルール同士が矛盾しうる組み合わせの数も、掛け算で増えます。AIは矛盾を聞き返さず、黙って片方を無視するので、衝突は出力を見るまで表に出てこない。

対策は、2層に分けたうえで、ぶつかる軸ごとに「どちらが勝つか」を先に1行書いておくこと。今回の案件では「文体は汎用が常に勝ち、構造と記号はプロジェクトが上書き可」の1軸から始めて、出力が安定しました。裁定ルールは、裁かれる対象より前に、AIが最初に読む位置へ。これだけで、ルールを足すたびに増えていた不安が、設計で抑えられるようになります。

Claude Codeのルール整理でお困りなら

スキルやルールが増えて、どれが正しいのか・どこを直せば全体に効くのか分からなくなってきた。AIに渡した指示が、なぜか時々無視される。そう感じたら、ルールの重複と衝突が原因のことが多いです。f2t.jpでは、Claude Codeの組織設計（汎用と固有の分離・衝突の優先順位設計・スキルの整理）をお手伝いしています。お問い合わせフォームから、現状のルール構成をご相談ください。

ここで紹介した仕組みを自社にどう当てはめるか、迷ったらまず現在地を把握するところから。

自動化の現在地を診断する（無料・6問・約1分） →