チーム開発で「Claude Code」を使い倒す 5つの勘所：「AIはただのコード補完」はもう古い 速習・実践「Claude Code」（2）（2/4 ページ）

生成AIによる開発支援が個人から組織全体へ広める取り組みにおいては、チーム全体の開発を効率化するための運用設計が求められます。「Claude Code」を使い倒し、組織の開発力を最大化するための5つの勘所を解説していきます。

[高江 賢（著）／監修：山田祥寛（WINGSプロジェクト），＠IT]

2．「人によってAIの使い方がバラバラ」　口頭ルールをやめ、Skills・Hooks・Pluginsで縛る

　AIコーディングでも、個人の差は出ます。同じチームでも、人によって使い方も成果もバラバラ。誰かのプロンプトは丁寧で、別の誰かは雑。レビューの観点一つとっても、人によって見るところが違えば、PRごとに品質が上下します。

　Claudeを活用するなら、その差を、口頭の申し送りやチャットの慣習で埋めようとしないでください。チームの使い方は、リポジトリに置ける仕組みで縛るべきです。

　Claude Codeには、それを実現するための道具が一通りそろっています。まずは登場する要素を次の表で押さえてから、一つずつ見ていきましょう。

仕組み	役割	適用タイミングと強制力	置き場所
CLAUDE.md	プロジェクトの基本方針	常に読まれる参考情報	リポジトリ直下
.claude/rules/	トピック別ルール（対象パスを絞れる）	常に読まれる参考情報。対象パス指定時は該当時のみ	.claude/rules/
Hooks	編集・実行の前後に必ず走る処理	条件に合えば強制的に実行	設定ファイル
Skills	再利用できる定型ワークフロー	必要時に明示または自動で読み込まれる	.claude/skills/
Plugins	SkillsやHooksなどをまとめた配布単位	タイミングと強さは中身のしくみに従う	配布元（Gitリポジトリなど）
チーム標準化を支える仕組みと、それぞれの役割

　こうした仕組みは他のエージェント型ツールにもありますが、Claude Codeは役割で粒度を分けているのが特徴です。同じAIへの指示でも、効くタイミングと強さが違うのです。

ルールファイルには、AIに守らせる方針だけを書く

　「API実装はこう」「フロントエンドのスタイルはこう」といったトピック別の規約は、wikiやスタイルガイド、lintの設定として、すでにチームのどこかにあるはずです。ただ、人向けの文書のままでは、Claudeへの指示にはなりません。

　かといって、規約の正本をAI用のファイルへ移すのではなく、本来の置き場で管理したまま、AIに守らせたい方針だけを.claude/rules/配下のルールファイルに書きます。CLAUDE.mdやルールファイルは、既存の規約の上に乗せる運用レイヤーと捉えてください。

　規約の全文を書き写すと、正本と食い違っていく劣化コピーになってしまいかねません。

　リポジトリ内に正本があるなら、書くのは「エラーメッセージは利用者向けの日本語で書く」「日付処理は共通ユーティリティーを経由する」といった1行の方針と、「詳細はdocs/style-guide.mdを読む」という参照先だけでOKです。Claudeは必要になったとき、自ら正本を読み込んでくれます。

　正本が外部のwikiにあってClaudeから読めないなら、守らせたい要点だけ書き出します。整形や命名のように機械的に検査できる規約は、そもそもルールファイルに書かず、lintやフォーマッターに任せる。それをAIに確実に通させる方法が、「Hooks」です（詳細は後述）。

　チーム共通の方針と個人の好みは、置き場所で分けます。リポジトリの.claude/rules/に入れるのは、チームで合意した方針のみ。自分だけの取り決めや好みは、ユーザーフォルダの~/.claude/rules/に置けば、全てのプロジェクトで有効になります。この分け方はルールファイルに限らず、これから見るHooksやSkillsも同じです。

仕組み	チーム共有（リポジトリ内）	個人用（ユーザーフォルダ）
CLAUDE.md	リポジトリ直下	~/.claude/CLAUDE.md
ルールファイル	.claude/rules/	~/.claude/rules/
Hooks（設定ファイル）	.claude/settings.json	~/.claude/settings.json
Skills	.claude/skills/	~/.claude/skills/
チーム共有と個人用の主な保存場所

　上記の表のように置き場所を分けておくと、方針の追加や変更をPRでレビューする運用も容易です。

絶対に順守させたいルールは、CLAUDE.mdではなくHooksでシステム的に強制する

　ここまでのCLAUDE.mdやルールファイルは、呼び出さなくても読まれるものの、あくまで参考情報です。第1回でも触れた通り、やりとりが積み重なると、「削除前に確認」と書いてあっても従われない場面が現実に起きます。絶対に順守させたいルールを、守られるかどうか「運任せ」にしてはいけません。そこで利用できるのが、Hooks（フック）と呼ばれる仕組みです。

　フックは、ファイル編集やコマンド実行の前後に、自身が決めた処理を確実に差し込む仕組みです。どのタイミングで差し込むかは、フックイベントで指定します。主なイベントと使いどころは、次の表の通りです。

フックイベント	動くタイミング	使いどころの例
PreToolUse	ツール実行の直前	危険なコマンドを実行前に止める
PostToolUse	ツール実行の直後	編集のたびにフォーマッターを通す
UserPromptSubmit	依頼の送信時	定型の注意書きを毎回差し込む
Stop	応答の完了時	作業の完了をチャットなどへ通知する
主なフックイベントと使いどころ

　絶対に順守させたいルールや指示を参考情報ではなく、仕組みとして固定化できます。フックの設定の保存先や設定自体、Claudeに任せることもできます。危険なコマンドを拒否するなら、止めたいコマンドを示しておく。生成したフックが動作するかどうかの確認も、Claudeに指示するのがコツです。

> rm -rfとgit push --forceを実行前にブロックするフックを追加したい。
  設定に書き込む前に検査処理を単体で試し、書き込んだらフックが発火する
  ことも確認すること。実際に削除やpushが起きない形で確かめること。

［リスト2］フックの作成プロンプト例（※編注：危険なコマンドを記載していますので、十分ご注意ください）

　人が見るのはフック実行後の結果です。止めたいコマンドが確かに止まったか、普段の作業まで止めていないか。そこを確かめてから、チームに広げていきます。

　参考までに、こうして生成されるフック設定のイメージを次に示します。検査処理の中身は生成のたびに変わるので、正解例ではなく骨組みとして参考程度に見てください。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.command' | grep -qE 'rm -rf|git push --force' 〜中略〜"
          }
        ]
      }
    ]
  }
}

［リスト3］生成されるフック設定のイメージ（.claude/settings.jsonの抜粋）

　PreToolUseのイベントでコマンド実行（Bashツール）に割り込み、条件に合えば拒否する。この骨組みさえつかめれば、細部の書き方はClaudeに任せて問題ありません。

　ただし何でもフックで縛ると、逆に煩わしくなります。検査が誤作動すれば作業そのものが止まってしまうためです。強制するのは、破られると困る最小限のルールだけにとどめるのが重要です。

再利用ワークフローはSkillにして全員に配る

　Skills（スキル）は、再利用可能なワークフローを定義する仕組みです。次のような定型作業はスキルにまとめておけば、誰でも同じ手順を再利用できます。

• PRレビューの観点出し
• デプロイ前のチェック手順
• リリースノートの下書き
• 定型的なリファクタリングの段取り
• 新規コンポーネントのひな型生成

　スキルは、.claude/skills/の下にスキル名のディレクトリを作り、その中のSKILL.mdへ手順を書きます。ディレクトリ名がそのまま呼び出し名になります。

　中身の下書きもまたClaudeの仕事です。レビュー観点を生成させ、チームの規約に合わせて対話で整えると、こんな形に落ち着きます。

---
name: pr-review
description: PRレビューの観点をチーム共通にそろえる
---
# PRレビュー手順
1. 変更の意図がPR説明と一致しているか確認する
2. テストが追加・更新されているか確認する
3. 例外処理とログの粒度をチェックする
4. 命名が既存コードと一貫しているか見る

［リスト4］PRレビュー用Skillの例

　このスキルを全員で共有すれば、誰がClaudeを使っても同じレビューの観点を呼び出せます。ベテランの暗黙知だったノウハウを、入ったばかりの新人でも呼び出せる。使うときは、チームの誰かが「pr-reviewのスキルで見て」と頼むだけです。

　スキルは自作の他にも、Anthropic公式のスキル集や、コミュニティーが公開するものが数多くあります。

• Anthropic公式のスキル集：https://github.com/anthropics/skills
• コミュニティーによるスキル検索サイト「Claude Skills Hub」：（https://claudeskills.info/ja/）

　ただ、スキルを入れることが目的になると逆効果です。何百と入れて、結局使うのは一部のスキルということも起こり得ます。チームでそろえるなら「まずこの2つ」「このリポジトリではこれを使う」と共有セットを決めておきます。目指すべきは、誰がどのスキルを使うか、迷わない状態です。

まとめて配り、コードと同じようにレビューする

　SkillsやHooks、MCPサーバの設定などをまとめて配れるパッケージがPlugins（プラグイン）、その配布の場がMarketplace（マーケットプレース）です。といっても専用のストアではなく、実体はGitリポジトリなどで公開するプラグイン一覧のカタログです。

　Anthropicが用意するカタログの他、チーム専用に自分たちで立てることもできます。主なカタログは次の通りです。

• Anthropic公式のマーケットプレース：https://github.com/anthropics/claude-plugins-official
• コミュニティー製プラグインのマーケットプレース：https://github.com/anthropics/claude-plugins-community

　設定一式をチーム外にも届けたいなら、このマーケットプレースを利用します。

　またマーケットプレースからスキルを探して導入する場合、プラグインに含まれるHooksがユーザーの権限で任意の処理を実行できるため、信頼できる配布元のものに限って導入するなど注意が必要です。

　ここまで紹介してきたCLAUDE.md、ルールファイル、Hooks設定、Skillsは、チームで共有するものをいずれもリポジトリ内のファイルとして持てます。つまり、コードと同じように扱えるということです。

　新しい方針を追加する際は、いきなり全員へ反映するのではなくPRとして出し、「このレビュー観点まで必須にするのは厳し過ぎないか」と議論し、気になればブランチで試してから取り込む。

　これにより、個人のチャット履歴に閉じ込めるしかなかったプロンプトが、コードと並ぶレビュー対象になります。結果として、チームのAI活用手法を継続的に精査・改善できる体制が整います。まずはSkillを1つ、リポジトリに置くところから始めてみてください。