Claude Cowork を社内AXに使っている私の実践ログです。社内固有名・個人名は伏せています。
「同じことを Claude に毎回言い直してる」── これ、めっちゃ詰まる。
私は90日くらい、Skills と CLAUDE.md と Hook の3つを行き来して、結局どれをどこに置くかで何度もリファクタした。正直しんどかった。
ただ、3ヶ月まわした今、迷わなくなった。今日はその選定基準をログる。同じところで詰まってる人の参考になれば。
結論から: 3つは「何に効くか」で完全に役割が違う
| レイヤー | 効くタイミング | 私の主な用途 |
|---|---|---|
| Skills | 「この種類のタスクが来たとき」 | 提案書作成、議事録整形、画像生成 |
| CLAUDE.md | 「このプロジェクトを触るとき毎回」 | コード規約、ディレクトリ構造、ドメイン語彙 |
| Hook | 「特定のイベントが起きた瞬間」 | コミット前lint、保存後テスト、危険コマンド検知 |
これが結論。詳細は下に。
レイヤー1: Skills は「タスクの種類」で発火する
Skills は description に書いた条件にマッチしたとき、自動でロードされる。
たとえば私の場合「提案書つくって」と言うと、社内独自の提案テンプレSkillが自動で呼び出される。これが地味に効く。「提案書フォーマット.pptx を読み込んで…」を毎回タイプしなくていい。
レイヤー2: CLAUDE.md は「プロジェクト全体」の前提
CLAUDE.md はリポジトリのルートに置く。毎回読まれる。
私の使い方:
- ディレクトリ構造の意味
- 命名規則
- 「このDBは触るな」みたいなガードレール
- ドメイン語彙(社内用語の英訳)
うん、これは Skills では絶対に代替できない。プロジェクト固有の文脈は、プロジェクトに住まわせるのが正解。
レイヤー3: Hook は「瞬間」を捉える
Hook は特定のイベントで発火する。私が一番使ってるのは PreToolUse と PostToolUse。
コピペで使える最小例:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command", "command": "scripts/block-dangerous.sh" }
]
}
]
}
}
これで rm -rf / みたいなコマンドを物理的にブロックできる。安心感が違う。
私が固めた4つの選定基準
90日まわして、迷ったときに使ってる基準はこれ。
基準1: トリガーは「タスク種類」か「プロジェクト」か「イベント」か
- タスク種類で発火させたい → Skills
- プロジェクトに紐づく前提 → CLAUDE.md
- イベントで割り込みたい → Hook
これだけで7割の迷いは消える。
基準2: 「常に読まれる」べきか「必要なときだけ」か
CLAUDE.md は毎回ロードされる。だからトークンを食う。私は最初これを知らなくて、CLAUDE.md に何でも詰め込んで、コンテキストがパンパンになった。自分でも何やってんだろうって思った。
「必要なときだけ呼ばれるべき」ものは Skills 側に逃がす。これだけで CLAUDE.md が痩せる。
基準3: 「人間の合意」がいるか、「機械的に止めたい」か
ガードレールには2種類ある。
- 合意ベース: 「触らないでね」と書いて、Claude が読んで守る → CLAUDE.md
- 強制ベース: 物理的にブロック → Hook
機密データに触りそうなコマンドは Hook で殴る。逆に「コード規約」みたいな柔らかいガードは CLAUDE.md でいい。
これは賛否あると思いますが、私は強制ベースを多めに振っています。事故ったときの後悔のほうが重い。
基準4: 「再利用する」か「このプロジェクトだけ」か
複数プロジェクトで使う処理は Skills に切り出す。私のチームでは、議事録整形 / 提案書生成 / 画像生成あたりは全部 Skills 化した。
逆に「このリポジトリのこのレイヤーはこう」みたいなのは CLAUDE.md。流用しない。
コピペで使える、私の判断フローチャート
迷ったら上から順に当てはめる:
1. 特定のイベント(コマンド実行、ファイル保存)を捉えたい? → Hook
2. このプロジェクトの中だけで使う前提? → CLAUDE.md
3. 「この種類のタスクが来たら」発火させたい? → Skills
4. どれにも当てはまらない? → たぶんプロンプトに直接書けばいい
これ、Notion にコピペして貼っておくだけでチームの認識が揃った。
ハマったところ
1. Skills の description が曖昧で発火しなかった
最初「PowerPoint 作るやつ」と書いたら、Excel 関連の依頼でも誤発火した。description は「いつ発火すべきか」を1段落で具体的に書く。私の場合、description を倍くらいの長さに書き直したら誤発火が消えた。
2. CLAUDE.md にゴリゴリ書きすぎてコンテキスト破裂
これ、本当によくやる。私の経験則だと CLAUDE.md は 200行が上限。それ超えたら Skills に逃がす。いや、というか、超える前に Skills 化を考えるほうが正しい。
3. Hook の exit code を間違えて全部ブロックした
PreToolUse Hook が exit 1 を返すとそのツール呼び出しが止まる。最初、デバッグ用 print のせいで exit code が立ってて、全部の Bash が止まった。やっと動いた! と思ったらこれ。1時間溶かした。
4. Hook と Skills が同時に発火して二重処理
両方に「同じ条件で発火するロジック」を入れたら、二重に処理が走った。役割分担を表に書いて整理し直した。一覧化、これは最初にやるべき。
5. CLAUDE.md の更新を Claude 自身に任せて壊れた
「コード規約を最新に保ってね」と Claude に丸投げしたら、無関係なルールを足し続けて肥大化した。CLAUDE.md は人間が手で書く。ここは譲らないほうがいい。
6. Skills の中で別の Skills を呼ぼうとしてループ
Skills A の中で Skills B を発火させる構造を作ったら、相互呼び出しになって挙動が読めなくなった。Skills は階層を1段に保つ。
7. Hook のスクリプトが遅くて体感が悪化
PostToolUse でフル lint を毎回走らせたら、応答が3秒遅くなった。Hook は 100ms 以内 を意識。重い処理は非同期に逃がす。これ、地味に効く。
まとめ
- Skills は「タスク種類」、CLAUDE.md は「プロジェクト前提」、Hook は「イベント」── トリガーで切る
- CLAUDE.md は痩せさせる。200行が私の上限ライン
- 強制したいガードレールは Hook、合意ベースのガードは CLAUDE.md
- 再利用するなら Skills、しないなら CLAUDE.md
- Skills の description は具体的に。曖昧だと誤発火する
- Hook は速さ命。100ms 以内を意識する
正直、ここまで整理するのに90日かかった。
みなさんはこの3つ、どう使い分けてますか? もっと良い分け方があれば、コメントで教えてください。特に「Skills と Plugin の境目」については、まだ私も迷いがある——試している方いますか?
Claude Cowork を社内AXの相棒として毎日使っているエンジニアの実践ログです。
私が日中見ている事業は「N限(Ngen)インターン」── 新卒の実務試験型(ワークサンプル型)インターンを企業に提供しています。AI時代の新卒採用に関心がある方は、下記からどうぞ。
- サービス概要(企業向け): https://ngen-intern.jp/company
- 使い方ガイド: https://ngen-intern.jp/company/guide
- お問い合わせ: https://ngen-intern.jp/contact
シリーズ: Claude Cowork で社内AXを回す