Claude Codeの設定、何が効いているのか分からないまま増えていないか。うちは増えた。91日で1,434セッション回して、ルールも フックもスキルも積み上がって、先週ログ415MBを全部集計して「実際に仕事をした設定」を数えた。
この記事は、次に設定を触る日に開く用の置き場として書く。91日走らせて生き残った設定だけを、コピペできる実物で並べる。やめた設定と理由も最後にある。
[toc]
全体像。設定は下から積む
設定レイヤーは下からこの順で積んでいる。上に行くほど壊れたときの被害がでかいので、下が安定してから上に乗せる。
| レイヤー | 場所 | 役割 |
|---|---|---|
| 1. ルール | ~/.claude/rules/*.md |
全セッション常時ロードの行動規範 |
| 2. フック | ~/.claude/settings.json |
決定論的な強制(AIの判断より上) |
| 3. スキル | ~/.claude/skills/ |
定型ワークフローのパッケージ |
| 4. エージェント | ~/.claude/agents/ |
役割分担する子AI |
| 5. 自動化 | launchd + JSONL台帳 | 人間不在で回る部分 |
| 6. メモリ | memory/ |
セッションを跨ぐ記憶 |
効いたルールは、射程を書いたものだけ
~/.claude/rules/ に9ファイル・計12,670字。ログ203万字をgrepした遵守率は98.1%だった。数字は高いが、内訳を見ると書き方で明暗が割れている。「全テキストに適用」と書いたルールは文脈で上書きされる。記事ではほぼ100%守られるのに、社外メールの下書きでは敬語ルールが破られていた(そしてそれはAIの判断の方が正しかった)。
生き残ったのは、どの成果物で効かせたいかの射程を先頭に書いたルールだけ。
# 死んだ書き方: 射程なしの禁止列挙
- 「させていただきます」を使わない
# 生き残った書き方: 射程 → ルール
## 記事・README・コミットメッセージに適用(会話とメール下書きは対象外)
- 「させていただきます」を使わない
- 結論を最初の3行に書く
この層は、文体や作法に譲れない線がある人向けだと思う。無ければ飛ばしてフックから入っていい。ちなみに「ルールは何個まで守られるのか」は別記事で実測した。3個なら完全遵守、30個でも83%。死んだルールには共通点があって、埋もれた位置よりも、モデルの出力習慣とぶつかっているかどうかで決まっていた。
フックは確率で破られない
ルールは98.1%、フックは100%。機械で止めるので破られようがない。91日生き残ったのは9イベント18本で、系統は4つ。
| 系統 | 実物 |
|---|---|
| 事故防止(PreToolUse) | 危険コマンド遮断 / 公開系操作の検問 / 機密ファイル読み取り検知 |
| 品質ゲート(Stop/PostToolUse) | 応答内URLの死活チェック / デザインのクリシェ検知 |
| 文脈維持(SessionStart/PreCompact) | 起動時にgit状態を注入 / 圧縮前に作業状態を退避 |
| 完了通知(Stop) | 音を鳴らすだけ |
一番単純で一番使うのは完了音で、これだけでターミナル監視をやめられる。危険コマンド遮断の骨子はこれ。exit 2で返すとツール実行自体がブロックされる。
#!/bin/bash
input=$(cat)
cmd=$(echo "$input" | python3 -c "import sys,json; print(json.load(sys.stdin)['tool_input'].get('command',''))")
if echo "$cmd" | grep -qE 'rm -rf (/|~)|force push|--force.*origin (main|master)'; then
echo "危険コマンドをブロックした: $cmd" >&2
exit 2
fi
落とし穴を1つ。正規表現の検問は無害なコマンドを誤爆する。うちでは「qiita」と「publish」が同居しただけの読み取り系コマンドが、公開操作の検問に引っかかり続けた。検問フックには意図的な実行を通すための合言葉(環境変数フラグ)を最初から用意しておくこと。
完了音だけでも入れる価値がある。うちはこれでターミナルを見張る時間が消えた。危険コマンド遮断も同じ日に入れていい。副作用は誤爆くらいだ。
スキル26個のうち、動いているのは数個
スキルは26個あるが、よく発火するのは数個。よく発火するスキルは、descriptionに「いつ呼ぶか」が書いてある。それだけだった。
放置されてた頃のdescriptionは「記事を生成するスキル」の一行だけ。今はうちの記事パイプラインはこうなっている。
description: Qiita記事を自動生成・投稿するスキル。ネタ選定→調査→執筆→品質ゲート→投稿までの一気通貫パイプライン。「/qiita」「今日の記事」「ネタ提案」で起動
モデルはスキル本文を読む前にdescriptionだけで起動判断するので、「〜で起動」のトリガー列挙が効く。これを足しただけで放置スキルが現役に戻った例が複数ある。
作る基準は、同じ手順を3回打ったら。トリガーがdescriptionに書けないなら、その時点で用途が曖昧なので作らない。うちで捨てたスキルはほぼこのパターンだった。
エージェントには禁止事項を先に書く
サブエージェントは7体。設計で効いたのは、禁止事項を最初に書くことだった。調査係はコードを書けない。書く係は1体だけ。校閲係は採点基準を持つ。
---
name: researcher
description: 技術調査エージェント。ライブラリ選定・API仕様・競合調査を行う。コードの編集は絶対にしない
tools: Read, Grep, Glob, Bash, WebSearch, WebFetch
---
本体はtoolsの行だ。編集ツールを渡さなければ、調査係は物理的にコードを壊せない。
1体で困っていないなら7体は要らない。うちも最初の1ヶ月は0体だった。
自動化は、今週4日間サイレント死していた
セッション長の中央値は0分。半分以上は1往復で終わる自動実行で、毎朝の実測集計・深夜の下書き生成・失敗検知がlaunchdで回っている。
<key>ProgramArguments</key>
<array>
<string>/opt/homebrew/bin/python3</string>
<!-- launchdは~を展開しないので絶対パスで書く -->
<string>/Users/あなたのユーザー名/projects/ops/check_stats.py</string>
</array>
<key>StartCalendarInterval</key>
<dict><key>Hour</key><integer>6</integer><key>Minute</key><integer>40</integer></dict>
偉そうに書いているが、この毎朝の集計ジョブは今週、4日間止まっていた。原因は170件のAPI取得の途中で1回タイムアウトすると全体が落ちる作りで、リトライを書いていなかった。気づいたのは4日後、レポートの日付が古いのを人間が見たとき。
直したのはリトライで、3回・待ち10秒。あわせて、ジョブの成否ログを当てにするのをやめて、検証はデータの日付を見ることにした(レポートが3日古ければ故障)。失敗を検知する別ジョブも要ると思っているが、正直まだ書いていない。
自動化に手を出すのは「同じコマンドを毎日手で打っている」ものが2つ以上できてからでいいと思う。1つ目から自動化すると監視なしでサイレント死する。うちがそうだった。
メモリは索引だけ読ませる
セッションを跨ぐ記憶はメモリディレクトリに「1ファイル=1事実」で貯める。今140ファイル超。全文はロードせず、常時読むのは1行サマリーの索引だけ、中身は必要時にReadさせる。
- [記事の勝ちパターン](feedback_winning_lane.md) — 刺さる型・タイトル・NG構成
- [PDCA計測ループ](project_pdca_ops.md) — 毎朝6:40実測。仮説なしの記事は書かない
巨大な1枚CLAUDE.mdに全部書く方式は、うちでは真っ先に死んだ。
91日で捨てたもの
生き残りより参考になるかもしれない。
- 巨大CLAUDE.md: 全部盛りの1枚は読まれ方が薄まる。ルートは薄く、詳細はrules/とmemory/へ分割
- 会話まで縛る文体ルール: 実測したら記事ではゼロ違反、会話では守られない。会話を縛る分は丸ごと空振りだった
- フックの大量監視: イベントを手当たり次第に張った時期があるが、発火ログを見て未使用を削除。検問は増やすほど誤爆も増える
- トリガーの無いスキル: descriptionに起動条件を書けないスキルは、書けない時点で用途が曖昧だった
- テンプレでの記事量産: 設定ではないが、同じ骨格で量産した記事は25本でいいね合計6。量産をやめて実測1本に寄せた方が数字が出た
今日入れるなら、この最小セット
全部は要らない。うちの91日から逆算して、最初の15分で入れる価値があるのはこの1ファイルだけ。
{
"hooks": {
"Stop": [
{ "hooks": [
{ "type": "command", "command": "afplay /System/Library/Sounds/Glass.aiff" }
]}
],
"PreToolUse": [
{ "matcher": "Bash",
"hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/check-dangerous-cmd.sh" }] }
]
}
}
check-dangerous-cmd.shの中身は上の骨子をそのまま保存すればいい。その次の1週間でルールを1ファイル(射程つき)、その次の1ヶ月で棚卸し。91日分の発火ログを見た結論は、足すより引く方が効いた、これに尽きる。
自分の宿題も残っている。ルール9ファイルのうちどれを消すかは、30個実験の結果を見てもまだ決めきれていない。棚卸しの結果は数字が出たらまた書く。
参考: