Claude Codeを育てる - Part 6：運用編

ここまでの5回でClaude Codeを育てる仕組みを書いた：

• Part 1：概念（説得 vs 強制）
• Part 2：強制（permissions.deny で禁止 + Hooks で自動化）
• Part 3：説得（CLAUDE.md の書き方）
• Part 4：拡張（Skills と Subagents の使い分け）
• Part 5：Subagent 実装（具体的な書き方、ロール定義、複数連携）

今回は最終回 — 運用編。仕組みを使い続けるための改善ループとアンチパターン。

■ インシデントドリブンが最強

最初から完璧な設定を作ろうとすると、ほぼ確実に失敗する。

理由：

• 想像で書いたルールは現実とズレる
• 使ってないルールが溜まる
• 矛盾するルールが混入する

代わりに：

👉 インシデントが起きたタイミングで、その都度ルールを足す

これがClaude Code運用の鉄則。

■ インシデント時の改善ループ

ミスが起きたら、その場で：

1. Claudeに分類を聞く — 例：「このミスを再発防止するには、CLAUDE.md / Skills / Hooks / Subagents / settings.json のどこに書くべき？」
2. 下記の判断軸で「説得 or 強制」を選ぶ
3. Claude にドラフトを書かせ、ユーザーがレビュー＆採用（採用判断は必ずユーザー、Subagent と同じ原則）
4. 再現テスト — これが一番抜けやすい

判断軸：

• 一発アウト → settings.json deny で物理ブロック
• 守れなくても大事故にならない → CLAUDE.md
• 毎回チェックすべき機械的処理 → Hooks
• 同じ手順の再利用 → Skills
• 別ロール / 別 context が必要（メインの役割で無理がある）→ Subagent

■ 再現テストを必ずやる

書いただけで満足しない。

新ルールを書いたら：

• 同じセッションで同じ操作を再現させる → 効くか確認
• 別セッション（/clear 後） で同じ操作を再現させる → セッション跨いでも効くか確認

特に CLAUDE.md は注入されているのに守られないことがある。 書いた瞬間にチェックしておかないと、「効いてるつもり」で運用が腐る。

■ 補足：auto memory の使いどころ

Claude Code には auto memory 機能があり、会話から勝手に学んだことをファイルに溜めていく。 ユーザーの好み、過去の指摘、プロジェクト固有の事実などが自動で残る。

memory / Skills / Hooks / CLAUDE.md / settings.json は「トリガー」「強制力」「コスト」が違うだけで、同じ情報でも置き場所で性質が変わる。auto memory が最適なのは：

• 流動的な情報 — pending tasks、進行中の状況
• 忘れても致命傷にならない規約 — 命名やフォーマット
• 個人ローカルな文脈 — 自分の好み、過去のやり取り

逆に向かない：

• 何が記録されたかが見えにくい → 事故防止は Hooks
• チームで共有できない（個人ローカル） → 共有ルールは CLAUDE.md / settings.json
• Git 管理に乗らない → バージョン管理したい規約は CLAUDE.md

👉 「memory で動く」と「memory が最適」は別物。事故損害が大きいものは Hooks、再利用する手順は Skills、不変の前提は CLAUDE.md。memory はその隙間で「忘れても許容できる流動情報」を支える役割。

■ やってはいけないアンチパターン

実環境で詰まる代表例：

• ❌ 過剰な遵守ルール — 「全関数にdocstring記載」等の過剰なルール → 1行修正でもドキュメント変更になりgitが荒れる
• ❌ Hooks に重い処理 — テスト全件、ビルド全体 → 編集ごとに数分待機、開発体験が崩壊
• ❌ permissions.allow: Bash(*) — 全許可で確認が消える。スコープを絞る
• ❌ 「禁止」だけ書いて代替を書かない — Claudeが手詰まりで止まる
• ❌ CLAUDE.md に禁止事項を大量に書く — settings.jsonで強制すべきものまで説得で済ませて、漏れる
• ❌ インシデントが出てないのに先回りでルールを増やす — 使われないルールが溜まる

■ 適用の優先順位（再掲）

これから開発環境に導入する場合、この順番：

1. .claude/settings.json の permissions.deny を書く（事故防止が最優先）
2. CLAUDE.md は50行以下から開始。ロールと判断軸だけ
3. Hooks は lint / format だけから。テスト全件は入れない
4. 同じ長文プロンプトを3回書いたら Skill 化
5. CLAUDE.md だけでロールが破綻し始めたら Subagent に分離

最初から全部揃えようとすると、メンテできない設定群が残る。

■ 定期的な見直し

3ヶ月に1回くらい、以下をやる：

• 使われていないルール / Skills を削除
• 矛盾しているルールを整理
• CLAUDE.md の行数チェック（200行超えたら分離）
• インシデントログを見て、ルール化漏れがないかチェック

ルールは増えるだけだと腐る。 増やすだけでなく、減らすことも仕組みに入れる。

■ シリーズ全体のまとめ

6回かけて Claude Code を「育てる」枠組みと運用を書いた。

核は3つ：

1. 「説得」と「強制」を混同しない — 事故防止は permissions.deny（禁止）、編集後のチェックは Hooks（自動化）。どちらも settings.json で完結
2. インシデントドリブンで増やす — 想像で書かない
3. 再現テストで効果を確認する — 書いて終わりにしない

Claude Code は魔法ではなく、新人エンジニアでもなく、毎朝入れ替わりでやってくる MIT の学生アルバイト。

だから外部に書き出して、強制で止めて、繰り返しを自動化する。 これが「育てる」の中身。

色々と書いたが、人間は忘れる、Claude Code も忘れる。 もし困ったら、このシリーズのブログを Claude Code に読ませてから相談すれば、正しい回答をくれるだろう。