はじめに
「Claude Codeを導入しろ。さもなくば辞める（誇張）」
上司にそう訴えて、3日で招待メールが届いた。あれからはや半年。
Claude Codeを本格的に学び、それまで導入されていなかった社内へ簡単なレクチャーを行い、チームの生産性は飛躍的に向上した。
ただ、現状。以下のような内容を問題視していた。
- 短期間で学習を終えたこと
- 学習から半年以上が経過していること
- Claudeは急速に変化していること
なので、今一度、学習をやり直すことに。
実際にやり直してみると、誤りがいくつも出てきた。
半年前のレクチャー「Commandsってところでmdファイルを作成すれば、スラッシュコマンドで…」
現在の公式リファレンス「Commandsは廃止されました。これからはSkillsを使ってください」
半年前のレクチャー「CLAUDE.mdに.envとか読み込ませないように記述するんだよ？」
現在の公式リファレンス「CLAUDE.mdはお願いです。強制するのはHooksの役割です」
などなど...
この記事はそんな「Claude Codeなんとなくは使っているが」という、
どこかのエンジニアの学び直し記録になります。
CLAUDE.md
セッションが始まったときにClaudeが最初に読む、共通の前提情報。
おそらくClaude Codeを学ぶときに真っ先に出会うやつ。でも結局「何を書けばいいの？」となって、とりあえず書いとけ精神で1000行を超え、Claude Codeがクソ重くなる現象は、誰もが通る道だと思う。
一言でまとめると、新しくチームに加わったエンジニアへ渡す「オンボーディングドキュメント」 という表現がしっくりくると思う。
そう考えると「コーディング規約を書いて」「公式リファレンスに書いてあることは書くな」という、学んだ際に注意された理由もすんなり腑に落ちる。おかしな記述に対しても「これオンボーディングドキュメントに要る？」と突っ込めるようになった。
効果 / 実用例
プロジェクトの方針をあらかじめ書いておくと、Claude Codeの曲解や余計な確認がなくなる。
「じゃあやりますね」「待て待て待て待て」のやり取りがなくなるだけで、体感のテンポが全然違う。
Skills & Commands
コマンドと混同しやすいが、公式によると「Commands」と「Skills」はシステムとして統合された。
本質は再利用可能な手順書だと理解できる。
「この作業、毎回同じ手順でやってるな」と気づいたらSkill化のサインだ。
効果 / 実用例
実務ではかなり使う。特に「報告」系の作業で真価を発揮する。
弊社では開発管理にBacklogを使っているが、執行役員から「リリース判定用課題」の作成を要求されたことがあった。この課題の作成が厄介で、当時は開発の相当なボトルネックになっていた。
それをSkill化することで大幅な時間短縮を実現。書式の統一もできて、一石二鳥だった。
この効率化と自由度こそSkillsの価値で、可能性は無限大。
Agents
メインのClaudeを「忙しいプロジェクトリーダー」と想像したとき、専門の部下として雇う（作成する）のがサブエージェント。
学習当時は「AIは自分の作ったものを正しいと信じている。だから客観性を持たせるために別のエージェントが必要だ」と学んでいたため、コードレビューでしか使っていなかった。
実際には、並列処理・専門分化・相互検証という3つの役割で考えると整理しやすい。
効果 / 実用例
わかりやすい例はコードレビュー。
AIは自分の判断を疑わない部分があるので、レビューで指摘されると「仰る通りです」とあっさり認める。これを自動でやらせるAgentsの効果は大きい。
それ以外にも、例えば「調査担当」「実装担当」「テスト担当」と役割を分けてサブエージェントを走らせると、メインがボトルネックになる作業量を大幅に削減できる。並列で動かせるのが何より強い。
Hooks
実は全く学んでいなかった機能。
CLAUDE.mdで「〜するな」と書いても、Claudeはあくまでお願いベースでしか従わない。「普段はそう動くけど、気が向いたら無視する」ことが起こりうる。
Hooksは、それを強制する仕組み。
Claudeがアクションを起こす前後に任意のスクリプトを割り込ませられる。例えるなら、Claude Codeの行動に対するミドルウェア。
PreToolUse → ツール実行の直前に割り込む
PostToolUse → ツール実行の直後に割り込む
Stop → 応答が終了したタイミングで割り込む
効果 / 実用例
CLAUDE.mdに「.envファイルは絶対に読むな」と書いても、Claudeがうっかり読もうとすることがある。Hooksなら、そのアクション自体を物理的にブロックできる。
「お願い」が「禁止」になるのは大きい。
他にも、
- コード変更後に自動でlintを走らせる
- 特定ファイルへの書き込みが発生したらSlackに通知する
- 危険なコマンドが実行されようとしたらアラートを出す
など、Claude Codeの行動に対して副作用なく処理を挟める。「Claudeが何かやるたびに人間が目を光らせる」状態から脱却できる機能だと思っている。
MCP（Model Context Protocol）
比較的早い段階から使い始めた機能。
一言でいうと、Claudeが外部サービスと直接やりとりできるようにする仕組み。APIやツールをClaude Codeに接続するためのプロトコルだと思えばだいたい合っている。
「ClaudeにSlackを読ませたい」「GitHubのIssueを操作させたい」「社内DBを参照させたい」というときに登場するのがMCP。
効果 / 実用例
弊社での活用例でいうと、さっきのSkillsでも連動して、BacklogのMCPサーバーを繋いでいるため、課題の作成・更新をClaude Codeから直接行える。
開発中に「あ、この修正に紐づく課題を更新しておこう」となったとき、ブラウザを開かずにそのまま指示できる。コンテキストスイッチが減るのはじわじわ効いてくる。
注意点としては、信頼できるMCPサーバーだけを繋ぐこと。MCPは外部との通信経路なので、怪しいサーバーを繋ぐとセキュリティリスクになる。公式やコミュニティの評判を確認してから導入するのが無難。
まとめ
| 機能 | 一言で言うと | 半年前の理解 |
|---|---|---|
| CLAUDE.md | オンボーディングドキュメント | なんでも書けばいいやつ |
| Skills | 再利用可能な手順書 | スラッシュコマンドが使えるやつ |
| Agents | 専門部下の雇用 | コードレビュー専用 |
| Hooks | Claudeへの強制ルール | ノーマーク |
| MCP | 外部サービス接続 | なんとなく使ってた |
半年前と比べると、理解の解像度がかなり上がった気がする。
特にHooksは「CLAUDE.mdでお願いしてたやつ、全部Hooksで強制するのが正解」という発見。SkillsとCommandsの統合も、仕組みを正しく理解してから使うと活用の幅が広がる。
Claude自体が急速に進化しているので、また半年後には「あの理解は間違ってた」が出てくるかもしれない。それも込みで、定期的に公式リファレンスに立ち返るのが大事だなと思った。