Claude Code を導入してしばらく経つと、多くの人が同じ壁にぶつかります。「対話で使う分には便利なんだけど、毎回同じことを聞き直したり、編集後に手動でコミットしたり、結局アシスタント感覚で終わっているな」という感覚です。私自身、最初の数ヶ月はまさにこの状態でした。チャット欄で会話して、コードを生成してもらって、自分で `git add` する——その繰り返し。
実は Claude Code には、対話 UI の裏側に hooks / skills / MCP という三つの「自動化レイヤー」が用意されています。これを使い始めた瞬間に、Claude Code は「便利なチャットボット」から「自分専用に組み上げた開発基盤」に変わります。本記事では、中小企業の情シス・開発者向けに、私が実運用している `~/.claude/settings.json` をベースに、ハマりポイントも含めて解説していきます。
この記事で解決する悩み
まず、想定している読者像を明確にしておきます。以下のいずれかに心当たりがあれば、本記事は刺さるはずです。
- セッション開始のたびに「前回どこまでやったか」を Claude に説明し直すのが面倒
- Write / Edit してもらうたびに、自分で `git add` → `commit` → `push` を打つのが地味にストレス
- Agent にタスクを投げたら、Skill 確認を忘れて似たような失敗を繰り返す
- `settings.json` をいじったら壊れた経験があり、戻し方が分からず怖い
- 「hooks」「skills」「MCP」という単語は耳にするが、結局どう使い分ければいいのか整理できていない
私もすべて経験済みです。特に「settings.json を直編集して JSON が壊れ、Claude Code が無言で起動しなくなった」事件は、いまでもトラウマとして残っています。本記事では、そういう失敗を避けつつ、最小コストで自動化レイヤーを使い始める道筋を共有します。
結論：先に答えだけ示します
長い前置きが苦手な方のために、要点を先に置きます。
- hooks は「Claude が動く前後に、自分の書いたスクリプトを差し込める」仕組み。SessionStart で git pull、PostToolUse で auto-commit の2つを入れるだけで、体感は激変します。
- skills は「特定タスクの手順書」を Claude に読み込ませる仕組み。Agent 呼び出し時に PreToolUse hook で Skill 利用宣言を強制すると、属人化やヌケモレが目に見えて減ります。
- MCP は外部ツール接続層（Slack / Notion / Drive / Gmail など）。hooks と組み合わせれば「編集が終わったら Slack に通知」「会議メモを Notion に自動投入」など外部連携が一気に広がります。
- 運用上の最重要ポイントは 「settings.json を SSoT（Single Source of Truth）として扱い、必ず .bak を取ってから編集する」 こと。これだけで事故率が一桁減ります。
では、ここから具体的な手順に入ります。
1. hooks の基本構造を理解する
hooks は、Claude Code が「あるイベント」を起こした瞬間に、自分が用意したスクリプトを呼び出してくれる仕組みです。設定ファイルは `~/.claude/settings.json` 一本だけ。これを SSoT として扱うのが運用上のコツです。複数箇所に設定が分散すると、後から「あれ、この挙動どこで定義されてたっけ？」と必ず迷子になります。
必ず最初にバックアップを取る
これは絶対に省略しないでください。私が最初にやらかしたのは、何も考えずに `settings.json` を VSCode で開いて、末尾のカンマを一つ消し忘れたまま保存したことです。Claude Code は JSON パースに失敗すると静かに起動しないので、「あれ、フックが効いてない？」とデバッグに30分溶かしました。
# 設定変更前に必ずバックアップを取る
cp ~/.claude/settings.json ~/.claude/settings.json.bak
# 差分を後から確認できるようタイムスタンプ付きで残すのもおすすめ
cp ~/.claude/settings.json ~/.claude/settings.json.$(date +%Y%m%d_%H%M%S).bak「なぜそうするのか」を一言で言うと、「壊れた瞬間に戻せる安心感」が、攻めた設定を試す勇気を生むからです。バックアップさえあれば、`cp` 一発で元に戻せます。これを習慣化してから、私は hooks の追加・削除を躊躇しなくなりました。
hooks の発火タイミング
主要な発火タイミングは次のとおりです。実運用ではこの中から必要なものだけを使えば十分です。
- SessionStart：Claude Code セッション開始時。最新化や前回コンテキストの想起に使う
- PreToolUse：ツール実行直前。ガードレール（バリデーション）に使う
- PostToolUse：ツール実行直後。自動コミットや通知に使う
- Stop：セッション終了時。クリーンアップや作業ログ保存に使う
2. 実運用している4つの hook を晒します
ここからは、私が実際に `~/.claude/settings.json` に登録している hook を紹介します。どれも一度入れたら手放せなくなったものばかりです。
2-1. SessionStart：作業ディレクトリの自動 git pull
複数マシン（自宅 Mac とオフィスの Linux）で同じ作業フォルダを使っていると、必ず「あれ、こっちのマシンに最新のコミットが反映されてない」が発生します。これを毎セッション開始時に自動で解消するのが、この hook です。
{
"hooks": {
"SessionStart": [
{
"type": "command",
"command": "git -C ~/claude-workspace pull --ff-only",
"async": true
}
]
}
}ポイントは `–ff-only` と `async: true` です。`–ff-only` を付けない設定にしていた頃、自動マージコミットが勝手に積まれて履歴がぐちゃぐちゃになり、後でレビューに地獄を見ました。「自動で勝手にマージはしない、ぶつかったら止まる」のが安全な振る舞いです。`async: true` は Claude Code の起動を git pull で待たせないための指定で、これがないとネットワークが遅い日に「Claude Code が固まった！」と勘違いします。
2-2. SessionStart：作業台帳リマインダー
「前回どこまでやったか」を Claude に毎回説明し直すのが面倒だったので、作業ログの直近10行を起動時に通知表示する hook を入れています。
{
"hooks": {
"SessionStart": [
{
"type": "command",
"command": "node ~/slack-bridge/hooks/session-start-resource-reminder.js"
}
]
}
}スクリプト側では、CSV や Markdown で運用している作業台帳の末尾10行を読み取り、`stdout` に出力するだけです。これだけで「あ、昨日 PostToolUse のデバッグ途中だったな」と即座に思い出せます。実際に使ってみて、セッション冒頭の「前提共有プロンプト」を打つ時間が体感で半分以下になりました。
2-3. PostToolUse：Write/Edit 後の自動コミット＆プッシュ
これがおそらく一番のヒットです。Claude が Write または Edit ツールでファイルを書き換えた瞬間に、自動で `git add → commit → push` まで走らせます。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"type": "command",
"command": "node ~/slack-bridge/hooks/post-tool-git-auto-commit.js"
}
]
}
}スクリプトの中身は単純で、対象ファイルのパスを受け取り、以下を順に実行するだけです。
# post-tool-git-auto-commit.js が内部でやっていること（擬似コード）
cd "$REPO_ROOT"
git add "$CHANGED_FILE"
git commit -m "chore(auto): edit by Claude Code ($(basename $CHANGED_FILE))"
git push origin HEAD導入してから一番嬉しかったのは、「あの編集どこいった？」がゼロになったことです。Claude に試行錯誤させていると、人間側は「3回前の状態に戻したい」と頻繁に思います。自動コミットが積まれていれば、いつでも `git log` と `git checkout` で戻れる安心感があります。
一方で、デメリットも正直に書いておきます。一つは、小さな編集ごとにコミットが大量に積まれること。GitHub の Contribution グラフが緑一色になるのは気持ちいいのですが、後で `git log –oneline` するとノイズが多いです。私は週に一度 `git rebase -i` で squash する運用で割り切っていますが、これが嫌な人はコミットメッセージ規約を厳格にして、後でフィルタしやすくしておくと良いでしょう。
もう一つは、sync 実行なのでファイル保存が一瞬重くなること。リポジトリが GB 級になると、git add のフックや pre-commit hook と合わせて1〜2秒待たされます。中小規模のリポジトリなら無視できるレベルですが、モノレポ運用の方は注意してください。
2-4. PreToolUse：Agent 呼び出し時の Skill ゲート
Agent にタスクを投げるとき、つい「適切な Skill を確認してから動いて」と書き忘れて、似たような失敗を繰り返したことはありませんか？私は何度もありました。その対策として、Agent プロンプト内に Skill 確認の記載がない場合に警告を出す hook を入れています。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Agent",
"type": "command",
"command": "node ~/slack-bridge/hooks/pre-tool-agent-skill-gate.js"
}
]
}
}スクリプトでは、Agent に渡されるプロンプト文字列を標準入力から受け取り、「skill」「Skill」「スキル」「手順書」などのキーワードが含まれているかチェックします。含まれていなければ警告を返し、Claude にプロンプト見直しを促す——というシンプルな仕組みです。
これを入れる前と後で、Agent 出力の品質が明らかに安定しました。特に複数人のチームで使うときに効きます。属人的な「俺はいつも Skill 指示してるから大丈夫」という暗黙知が、hook によって明文化される効果が大きいです。
3. ディレクトリ構成のベストプラクティス
hook を増やしていくと、スクリプトの置き場がだんだん散らかってきます。私が落ち着いた構成は以下です。
~/.claude/settings.json # SSoT：すべての hook 登録
~/.claude/settings.json.bak # 一括復旧用バックアップ
~/slack-bridge/hooks/ # 全 hook スクリプトの置き場
~/slack-bridge/hooks/watch-paths.js # 監視対象パスの SSoT
~/claude-workspace/CLAUDE.md # 設定変更ルール・影響マップ
~/claude-workspace/shared/flows/ # フロー定義
~/claude-workspace/shared/output/docs/ # ロールバックガイド等のドキュメントキモは 「監視対象パスを `watch-paths.js` という1ファイルに集約する」 ことです。これをやらないと、各 hook スクリプトに `~/projects/foo` などのパスがハードコードされ、フォルダ名を変えるたびに grep して書き換える羽目になります。私はこれで2回ほど痛い目を見ました。1ファイルに集約してからは、`watch-paths.js` を直すだけで全 hook が追従します。
4. hook の確認・無効化・復元コマンド
運用中によく使うコマンドをまとめておきます。
# 現在の hook 設定を確認
cat ~/.claude/settings.json
# JSON が壊れていないかバリデート（jq があれば便利）
jq . ~/.claude/settings.json
# 特定 hook の無効化 → settings.json から該当エントリを削除
# （JSON にはコメント構文がないので、削除 or 別キーへリネームで対応）
# バックアップから一括復元（壊れたとき用の最終手段）
cp ~/.claude/settings.json.bak ~/.claude/settings.json「JSON が壊れていないかのバリデート」は地味ですが超重要です。私は `jq .` を `.zshrc` に alias `cv=’jq . ~/.claude/settings.json’` として登録しており、編集後に必ず `cv` を叩くようにしています。これで「保存したのにフックが効かない、なぜだ」というデバッグ時間が大幅に減りました。
5. MCP との組み合わせで世界が広がる
hooks 単体でも十分強力ですが、これに MCP（Model Context Protocol） を組み合わせると本当のラスボス感が出てきます。MCP は Slack、Notion、Gmail、Google Drive、Canva、Gamma など外部サービスと Claude Code を接続する規格です。
私が実装している構成の一例：
- Claude が Edit 完了 → PostToolUse hook で auto-commit → さらに hook 内から MCP 経由で Slack の特定チャンネルに「ファイル X を更新しました」と自動投稿
- Notion の特定データベースに毎朝「今日の AI タスク」が並ぶようにし、SessionStart 時に Claude が読み取って ToDo として認識
- 長文のドキュメントは Google Drive に PDF 化して保存、リンクを Slack に投げる
「Edit 完了 → 自動 commit → Slack 通知」のワンストップ化を体感すると、もう手作業には戻れません。チームメンバーが Slack の通知を見て「あ、今このファイルいじってるんだな」と把握できるようになり、非同期コラボレーションのコストが大幅に下がりました。
注意点として、MCP 接続には認証情報が必要になるケースが多いです。トークンや API キーは絶対に `settings.json` 本体や hook スクリプトに直書きせず、`~/.config/claude/secrets.env` のような外部ファイル＋環境変数経由で渡してください。私は最初、誤って API キーをスクリプトに直書きしたまま GitHub の public リポジトリに push してしまい、慌てて revoke した経験があります。`.gitignore` で守るのも当然として、「秘密情報はソース管理に乗らない場所に置く」を徹底してください。
6. 実際に使ってみたメリット・デメリット
メリット
- auto-commit が最強：差分が必ず履歴に残る安心感は、一度味わうと戻れません。試行錯誤の心理的ハードルが激減します。
- git pull の自動化で複数マシン運用が楽：自宅・オフィスの行き来でコンフリクトが起きなくなりました。
- 作業台帳リマインダーで起動が速い：前提共有プロンプトをほぼ書かなくて済むようになり、セッション最初の体感が変わりました。
- Skill ゲートで Agent 品質が安定：属人化が減り、チームに展開しやすくなります。
- MCP 連携で外部通知が自動化：Slack や Notion が「Claude の動きをチームに翻訳する場」になります。
デメリット・注意点
- PostToolUse の sync 実行は、保存が一瞬重くなります。大規模リポジトリでは pre-commit hook と合わせて検討してください。
- hook が増えるとデバッグが難しくなります。SSoT 運用と命名規則の徹底が必須です。
- Claude Code 起動中に `settings.json` を変更しても即時反映されません。次セッションで反映です。これを知らずに「あれ、効いてない」と悩む人が非常に多い印象。
- auto-commit でコミットが大量に積まれます。週次の squash 運用 or commit メッセージ規約での後処理を前提に。
7. ありがちな失敗と対処法（実体験ベース）
失敗 1：settings.json を直接編集して JSON が壊れた
カンマ忘れ、引用符の閉じ忘れ、最後の要素にカンマを残した——どれもやらかしました。対処：`cp ~/.claude/settings.json.bak ~/.claude/settings.json` で一括復元。バックアップを取らずに触らないことを鉄則にしてください。私は今、`settings.json` を開く前に必ず `cp` する習慣を体に染み込ませました。
失敗 2：hook スクリプトを削除したのに動作が残っている
これは盲点です。スクリプトファイルを `rm` しても、`settings.json` に登録が残っていれば Claude Code は呼び出そうとし、「コマンドが見つかりません」というエラーが裏で発生し続けます。対処：「ファイル存在」と「settings.json への登録」は別物だと理解し、両方をセットで操作してください。たとえば私の環境では、`stop.js` は「ファイル削除済み＋登録なし」で完全に無効化、`notification-hook.js` は「ファイルは残しているが登録から外す」という状態管理をしています。
失敗 3：軽量フローで設定変更しようとして弾かれる
hook やフロー定義の変更は影響範囲が大きいので、私の運用ルールでは「STANDARD 以上のフロー宣言が必要」と決めています。LIGHTWEIGHT で雑にいじろうとすると、`CLAUDE.md` に書いた影響マップに沿って自動でガードがかかります。対処：設定変更系は必ず STANDARD フローで宣言してから着手。これは個人運用でも有効です。「軽い気持ちで触る」を防げます。
失敗 4：watch 対象パスがあちこちに散らばって管理不能
初期は各 hook スクリプトに `~/projects/foo/bar` のようにパスを直書きしていました。プロジェクト名が変わるたびに全 hook を grep して書き換える地獄が待っています。対処：監視対象パスは `~/slack-bridge/hooks/watch-paths.js` に SSoT 化し、各 hook はこのファイルから読み込む構成にしてください。これは早ければ早いほど報われる投資です。
失敗 5：ロールバック手順がわからずパニック
本番運用で hook が暴走して大量に空コミットを積み始めたことがありました。慌てて Claude Code を Ctrl+C で殺し、git で全 commit を revert する羽目に。対処：平時にロールバックガイドをドキュメント化しておきます。私は `~/claude-workspace/shared/output/docs/` 配下に `hook-rollback-guide.md` を置いており、「壊れた時にどこを見るか」を事前に決めています。慌てる場面で初見のドキュメントを書くのは無理です。
8. まとめ：今日から始める3ステップ
長々と書いてきましたが、最初の一歩は驚くほど小さくて構いません。完璧な設計を最初からやろうとすると、ほぼ100%途中で挫折します。私自身、いまの構成にたどり着くまで半年かかりました。
- まず `~/.claude/settings.json` のバックアップを取る。これだけで今日のタスクは完了でも OK。
- SessionStart の git pull hook を1つだけ追加して動作確認。失敗しても影響範囲が小さく、効果が体感しやすいので最初の hook として最適。
- 慣れたら PostToolUse の auto-commit を導入。ここまで来れば、もう Claude Code が単なるチャットボットには見えなくなります。
その先、Agent を多用するなら PreToolUse の Skill ゲートでガードレールを敷き、最終的に MCP（Slack / Notion / Gmail / Drive など）と接続して、チーム全体の作業可視化へ展開していく——というのが私のおすすめロードマップです。
補足 FAQ
- Q. hook スクリプトを書く言語は？
A. Node.js（`.js`）が運用しやすいです。JSON のパースや子プロセス起動が標準で書けますし、Claude 自身に修正させやすい言語でもあります。Bash でも書けますが、複雑なロジックになると Node の方が保守性が高いです。 - Q. Claude Code を再起動せずに hook を反映できる？
A. 現状はできません。`settings.json` は次セッションで読み込まれます。これを忘れて「効いてない！」とハマるのが新規ユーザーあるあるです。 - Q. チーム展開する時の注意は？
A. `~/.claude/settings.json` は個人設定なので、そのままチームに配布するのは難しいです。チーム共通のスクリプトは `~/claude-workspace/` のような共有リポジトリに置き、各メンバーの `settings.json` からそこを参照する構成が現実的です。秘密情報を直書きしない原則を、チーム規約として明文化することもセットで進めてください。 - Q. hook が無限ループに陥らないか？
A. PostToolUse hook 内で Write/Edit ツールを再度呼ぶような実装をすると、理論上は無限ループの可能性があります。私は「hook 内では git や curl のような外部コマンドのみを使う」というルールを徹底することで、これを回避しています。
Claude Code は対話 UI だけでも便利ですが、hooks / skills / MCP を使い始めると 「自分専用の開発自動化基盤」 に化けます。最初の hook を書く30分が、その後の数百時間を救う投資になります。ぜひ今日、まずバックアップを取るところから始めてみてください。
IT・SaaS専門の比較メディア。中小企業の導入担当者向けに独自調査・中立的な比較情報を提供