CLAUDE.mdに全部書かない。デザインルール・Skills・ガードレールの分け方

AIにUIを直してもらうたびに、同じ注意を書く。既存のボタンを使うこと。エラー時も確認すること。共通のデザイントークンを勝手に変えないこと。

それなら、と全部をCLAUDE.mdに集める。次の修正では、またどれかが抜ける。

このとき見直したいのは、指示の強さより、指示を届ける場所です。判断の前提はルールへ、繰り返す作業はSkillsへ、止める必要がある操作は権限や実行環境へ。同じ「〜してください」でも、必要な仕組みが違います。

今回は、PD（プロダクトデザイン）チームがAI駆動開発の指示を整理する方法を、Claude Codeの設定を例に考えます。画面や指示は説明用の仮想例です。

三つの注意書きを、一つのルールにしない

設定画面の保存ボタンを改善する場面を想像してください。チームから次の依頼が来ました。

「既存のButtonを使い、成功・失敗・再試行を確認してください。ただし、共通トークンは変更しないでください」

一文としては自然です。でも、仕事として分解すると三つになります。

最初の指示には、「適合する部品がない場合は差分を説明して相談する」という例外も必要でしょう。二つ目には、失敗状態をどう再現するかが要ります。三つ目は、文章に書いただけで書き込みが止まるわけではありません。

公式ドキュメントも、CLAUDE.mdを強制設定ではなく、AIに渡す文脈として区別しています。Claude Code：メモリとルール

図1：同じ依頼文から、判断・手順・制御を取り出す。説明用の仮想例。

HAVUなら、この三つを別々の担当者に説明できる状態にします。「何を良しとするか」はPD、「どう確かめるか」はPDと開発者、「どこまで操作できるか」は環境を管理する人。ファイルを整理する前に、誰が直せる仕組みなのかを決めるためです。

ファイルを分けても、必要なときだけ読まれるとは限らない

CLAUDE.mdが長くなったので、UIルールを別ファイルへ移す。それだけで読み込み量が減る、とは限りません。

Claude Codeでは、適用対象を指定していない.claude/rules/内のルールは起動時に読み込まれます。CLAUDE.mdからインポートしたファイルも、起動時の文脈に入ります。分割は管理には役立ちますが、読み込みを遅らせることとは別です。

対象を絞りたい場合は、ルールのpathsを使います。たとえば、次はsrc/components/直下のTSXファイルを読むときに適用する例です。子ディレクトリはこの指定の対象に含めていません。

---
paths:
  - "src/components/*.tsx"
---
適合する既存のButtonがあれば再利用する。
適合しない場合は、不足する状態・挙動を説明して相談する。

パスに応じたルールは、該当ファイルを読んだときに読み込まれる仕組みです。すべての操作を監視して遮断する設定ではありません。Claude Code：パス別のルール

ここから、配置の基準が一つ決まります。全作業で必要な短い前提はCLAUDE.mdへ。特定の画面やコードを扱うときの前提は、対象を指定したルールへ。「短いか、長いか」より、「いつ必要か」で分けます。

Skillsには、注意事項より「一仕事」を入れる

「エラーを確認する」という一行だけでは、何をもって確認済みなのか分かりません。

画面改善のSkillにするなら、入力から終了条件までをつなぎます。今回なら、対象画面と仕様を受け取り、既存部品を確認し、変更し、成功・失敗・再試行を確かめ、結果を残す一仕事です。Skillsは、こうした作業手順や知識をまとめるために使えます。Claude Code：Skills

たとえば、検証手順には次の一節を入れます。

保存の成功・失敗・再試行を確認する。失敗状態を再現できない場合は、成功時の確認だけで完了としない。確認できた状態と未確認の状態を分け、必要な再現手段を報告する。

この指示なら、確認できなかったことも成果物になります。単なる「チェック済み」より、次の人が動きやすい。

配置の最小例は、次のようになります。これは構成案であり、そのまま実行できる設定一式ではありません。

図2：全作業の前提、対象別の判断、作業手順、操作制御を分けた配置案。

一方で、ルールの全文をSkillにもコピーすると、変更するたびに二か所の整合性を確認する必要が出ます。Skillには「対象UIのルールを参照する」という手順を置き、判断基準の本体はルール側に残す。この分担なら、部品の方針が変わっても修正箇所を見つけやすくなります。

allowed-toolsは「これ以外は禁止」ではない

見落としやすいのが、Skillのallowed-toolsです。

allowed-tools: Readと書けば、そのSkillが読み取り専用になる。名前からはそう見えます。しかし公式仕様では、これは指定ツールの事前承認を与える設定で、ほかのツールを利用不能にするものではありません。ほかのツールは通常の権限ルールに従います。Claude Code：ツールアクセスの制限

つまり、「トークンを書き換えないで」というルールと、「Readだけを事前承認する」という設定を並べても、書き込み禁止が成立したとは言えません。

変更を止めたいなら、権限設定や実行前のHooks、環境側の書き込み制限を検討します。ただし、一つの編集ツールを止めても、シェルなど別の経路から書き換えられるなら、守りたい範囲は守れていません。Claude Code：権限、Hooks

ここでPDが決めるべきなのは、設定の名前より境界です。「この画面の余白調整は進めてよい。共通トークンの変更が必要なら、理由と影響範囲を示して止まる」。その境界を開発者と共有してから、実際の操作経路に合わせて制御を選びます。

制御を入れた後は、二つを対で確かめます。許可した画面修正は通るか。禁止したトークン変更は止まるか。全部止まる環境では、制作が進みません。

AIには「仕分け」まで任せ、効くかどうかは人が確かめる

手元に混ざった指示があるなら、まず三〜五行だけ取り出してAIに渡せます。社内ルールの全文を渡す必要はありません。

次の指示を、判断基準・作業手順・操作制御に分けてください。
1. 適合する既存のButtonを使う。
2. 保存の成功・失敗・再試行を確認する。
3. 共通トークンは変更しない。
4. Skillにallowed-tools: Readを指定している。

各行について、置き場所、効くタイミング、
文章だけでは保証できないこと、人が確認することを表にしてください。
一つの指示に複数の仕組みが必要なら、分けて示してください。
4は設定の事実です。禁止の成立を推測せず、
現在の公式仕様と、確認できない点を区別してください。

欲しい出力は、きれいなフォルダー一覧ではありません。たとえば3なら「変更しない理由はルールに残す／操作は別の制御で止める」という分解。4なら「読み取り専用とは判断できない」という指摘です。これは想定出力で、外部AIで実行した結果ではありません。

人は、対象パスが実際の構成と合うか、Skillの終了条件を検証できるか、禁止を別経路から回避できないかを確かめます。AIの分類表と、動作確認の結果は分けて残してください。

エンジニア・技術書著者のAddy Osmaniは、エージェントの実行環境を扱った記事で、次のように書いています。

“Every line in a good AGENTS.md should be traceable back to a specific thing that went wrong.”

よいAGENTS.mdの各行は、具体的に何がうまくいかなかったのかまでたどれるべきだ、という意味です。訳：HAVU。Agent Harness Engineering（2026年4月19日）

この考えをPDチームに持ち込むなら、ルールを増やす前に、今回抜けたのは「判断の前提」「作業手順」「操作の制御」のどれだったかを残します。同じ失敗でも、直す場所が違うからです。

まずは、いつも書き直している一文から。その一文が何を判断させ、いつ働き、何を止める必要があるのか。ここまで分けると、AIに説明を繰り返す仕事を、チームで直せる仕組みに変えられます。

HAVUでは、UI/UXの判断と実装の進め方をつなぎ、AIワークフローやチーム運用の設計を支援しています。ルールやSkillsが増えて管理しにくくなっている場合は、PDチームのAI駆動開発環境について相談するから、現在の構成と困っている作業をお知らせください。