7月3日、jsdev.spaceが「10 Claude Code Settings That Made Me a Faster Software Architect」と題した記事を公開した。Claude Codeの設定と運用パターンを見直すことで開発速度と品質を改善する10の方法について詳しく紹介されている。
Claude Codeをデフォルト設定のまま使い続けているエンジニアは多い。しかし本記事の著者は「ミスはランダムではなく繰り返される」という気づきから、Claude Codeをほかのエンジニアリングツールと同様に設定対象として扱い始めた。その結果として得た10の知見が本記事の内容だ。
最重要：CLAUDE.mdは8,000トークン以内に保て
最も大きなインパクトがあったのが、CLAUDE.mdの肥大化を防ぐことだ。
著者はかつてCLAUDE.mdを約40,000トークン規模まで膨らませた。アーキテクチャの決定、コーディング規約、テストルール、デプロイ手順、APIコントラクト——「コンテキストが多いほど回答が良くなるはず」という直感に従った結果だ。
しかし実際には逆効果だった。LLMは長いドキュメントのすべての部分を均等に処理しない。著者が実験として「自分のCLAUDE.mdの300行目あたりにあるルールを繰り返してみて」とClaudeに聞いたところ、見つけられなかった。ドキュメントが長くなるほど、中間部分の情報は無視されやすくなる。
この現象は研究者の間で "Lost in the Middle" として知られており、2023年のスタンフォード大学らによる論文で実証されている。コンテキストウィンドウの先頭と末尾の情報は比較的よく参照される一方、中間に埋もれた情報はモデルが実質的に読み飛ばしやすいという特性だ。CLAUDE.mdが肥大化すると、苦労して書いたルールの大半がこの「無視されやすい中間」に落ちる。
解決策として著者が採用したのは、情報の「遅延ロード」という発想だ。
.claude/
├── CLAUDE.md # 常時ロード（8KB未満）
├── skills/
│ ├── nestjs.md
│ ├── migrations.md
│ ├── review.md
│ └── testing.md
└── specs/
├── domain-model.md
├── api-contracts.md
└── infrastructure.md
CLAUDE.mdには「すべての会話で必要な情報」だけを置く。技術スタック、コーディング原則、アーキテクチャ上の制約、プロジェクト全体のルール、追加ドキュメントへのリンクのみだ。それ以外は関連するときだけ読み込む専用ドキュメントに切り出す。
結果としてCLAUDE.mdは40Kから6Kトークンに縮小し、トークン使用量が約35%削減された（著者自身の計測による実験値）。加えて、長いセッションでのルール「忘れ」がなくなったという。
settings.jsonで無駄な確認を減らす
Claude Codeはデフォルトで多くの操作に確認を求める。著者は.claude/settings.jsonに以下を設定し、読み取り専用・検証系のコマンドは自動許可、破壊的操作は明示的に拒否する構成にした。
{
"permissions": {
"allow": [
"Bash(git log:*)",
"Bash(git diff:*)",
"Bash(npm test:*)",
"Bash(npm run lint:*)",
"Bash(grep:*)",
"Bash(find:*)"
],
"deny": [
"Bash(git push:*)",
"Bash(git reset --hard:*)",
"Bash(rm -rf:*)"
]
}
}
さらにDBの破壊的SQL（DROP TABLE、TRUNCATE、DELETE FROM * WHERE 1=1）もdenyに追加している。この設定はリポジトリ内に置くため、チーム全員が同じ安全基準で動く。
acceptEditsは限定的に使う
ファイル変更前の確認ダイアログを省略するacceptEditsは魅力的な機能だが、著者は使い所を明確に絞っている。
有効にする場面：TypeScript移行、any型の置換、ファイルリネーム、importの更新、ドキュメント編集など機械的な作業。自動テストで結果を素早く検証できるものに限る。
使わない場面：新機能の実装、認証・決済・DBレイヤー、アーキテクチャのリファクタリング。
実際に失敗した例として、「未使用importの削除」という明確なタスクでacceptEditsを有効にしたところ、Claudeが「ついでに」いくつかのサービスまでリファクタリングした。技術的に壊れてはいなかったが、意図的に選んだアーキテクチャとは異なるコードになり、5分の作業が30分のコードレビューになった。
フックでワークフローを自動化する
Hooksは、Claudeがツールを実行する前後に走るシェルスクリプトだ。著者が常用しているのは以下の3つ。
セッション履歴の記録（Stopフック）：完了したセッションをログに残す。著者はこれで自分がClaude Codeに毎日2時間以上使っていることを初めて把握した。「測定しないものは最適化できない」。
危険なコマンドのブロック（PreToolUseフック）：rm -rfやDROP TABLEなどを実行前に遮断する。最初の3ヶ月でこのフックが7回発動し、うち2回は本当に実行しなくて良かった操作だったという。
完了通知：macOSのosascriptやLinuxのnotify-sendでデスクトップ通知を出す。30秒おきにターミナルを確認するコンテキストスイッチがなくなり、体感的な生産性が向上した。
複数モデルをアーキテクチャレビューパネルとして使う
取り返しのつきにくい設計判断（DBスキーマ、サービス間の契約、大規模リファクタリングなど）には、複数モデルに同じ問題を別の観点で解かせる手法を使う。
Opus: 信頼性と明示的な契約を最優先に設計せよ
Sonnet: 開発速度と保守性を優先して同じシステムを設計せよ
Haiku: 最小限の複雑さと抽象化で同じ問題を解け
3つの回答を得た後、4つ目のセッションでそれらを統合させる。このプロセスは約20分。著者によれば、あるイベント駆動リファクタリングでは通常数時間かかるチーム設計議論をこれで代替できたという。
コンテキスト劣化（Context Rot）を見極める
長いセッションの後半では品質が落ちる。著者はこれをContext Rotと呼ぶ。症状は、すでに却下したアイデアの再提案、直前に書いたコードの変更提案、済みのコンテキストを何度も聞いてくる、といったものだ。
著者のルール：3回連続してプロジェクトが前進しなければ、迷わず新しいセッションを始める。その際、会話全体をコピーするのではなく、以下の引き継ぎテンプレートを使う。
## Context
### Goal（1文で目的）
### Completed（完了ファイル）
### Already Rejected（却下したアプローチ）
### Next Step（次の具体的タスク）
この引き継ぎに5分かかるとしても、劣化したセッションを続ける30分より速い。
その他の設定
記事ではほかにも以下が紹介されている。
タスクの重要度に応じた4段階の「努力レベル」：軽微なバグ修正（レベル1）から認証・インフラ変更（レベル4）まで、プランニングの深さを4段階で使い分ける。レベルが高いほど、実装前の設計検討・リスク洗い出しに時間をかけるよう明示的に指示する。
同じ指摘を2回した時点で止まる「2回修正ルール」：同じ問題を2度指摘しても直らない場合は、プロンプトやコンテキストの与え方自体に問題があるとみなし、セッションを仕切り直す判断基準として使う。繰り返しの指示で時間を浪費するより、アプローチを変えた方が速いという考え方だ。
/costコマンドで定期的にコスト確認：トークン使用状況をモニタリングする習慣。CLAUDE.mdの削減効果を数値で把握するためにも有効だ。自然言語コメントによるコンテキスト品質の向上：コードのコメントを日本語などの自然言語で書くことで、Claudeがコードの意図を正確に読み取りやすくなるという。単に「何をしているか」ではなく「なぜそうしているか」を書くことが重要とされている。
詳細は10 Claude Code Settings That Made Me a Faster Software Architectを参照していただきたい。
