Claude Code の記事24本を集めて数えた「とりあえずこれやっとけ」

Claude Code のおすすめ設定記事は、もう「保存版」「完全ガイド」「決定版」だらけだ。どれも力作なのだけれど、数が多すぎて、結局どれから手を付ければいいのかが分からない。同じことで困っている人は多いと思う。そこで一本を選んで従うのはやめて、たくさんの記事を集めて「何本が同じ設定を薦めているか」を数えてみた。大勢の書き手が別々にたどり着いた設定なら、まず手を付ける価値が高いはずだからだ。

数え方

調査は Claude Code 自身のマルチエージェント機能（Dynamic Workflows）で回した。Qiita・Zenn・英語圏ブログ・Reddit / Hacker News・GitHub・公式の6方向から52本を集め、有力な24本（Qiita と Zenn が各10本、公式 Best practices、builder.io 3本）を精読して、227個の推奨を39項目に統合した。以下の「◯本」はこの24本での登場数だ（公式ドキュメントも1本と数える）。

さらに上位16項目と頻出の Tips を、公式ドキュメントで「2026年7月時点でも有効か」検証した。更新が速く、去年の「保存版」に今は動かない設定が混ざっているからだ（5つ見つかった。後述）。

ただ、この数え方には弱点がある。日本語圏の記事は互いに参照し合い、多くが公式 Best practices を上流に持つので、票が「独立」とは限らない。だから票は当たりを付けるのに使い、確度は後半の一次検証に負わせる二段構えにした。

集計結果

推奨事項	登場数
PostToolUse フックで編集後に自動フォーマット・lint	10/24
CLAUDE.md は短く保つ	9/24
permissions.allow で頻出コマンドを事前許可	8/24
調査タスクはサブエージェントに委譲	8/24
CLAUDE.md の階層配置（ユーザー / プロジェクト / ローカル）	8/24
CLAUDE.md の中身は「コマンド・規約・罠」	8/24
たまに使う知識・手順は Skills に切り出す	7/24
肥大化した CLAUDE.md は .claude/rules/ に分割	7/24
CLAUDE.md を育てる（ミスしたら追記・定期棚卸し）	7/24
Stop / Notification フックで完了・承認待ちを通知	6/24
@import で詳細ドキュメントを別ファイルへ	6/24
定型タスクのスラッシュコマンド化	6/24
「この行を消したら Claude が間違えるか」で取捨選択	5/24
ルールは測定可能に書き、禁止には代替案を併記	5/24
設定のスコープ管理（チーム共有は git、個人は gitignore）	5/24
Plan Mode で計画してから実装	5/24

登場数が同じものは横並びで、1票差に順位の意味は持たせていない。

上位16のうち8つが CLAUDE.md まわりの話で、hooks が2つ、権限・設定まわりが2つ。つまり世間の「とりあえずこれやっとけ」の実体は、派手な MCP やプラグインではなく、CLAUDE.md の書き方と、確認プロンプトを減らす設定に集中している。

CLAUDE.md まわり（7項目）

最大派閥なのでまとめて扱う。表では CLAUDE.md 系が8項目あるが、うち @import は後半の「今は動かない」で扱うので、ここは残り7つ。軸は「短く保つ」「中身を人間しか知らないことに絞る」「階層に置いて育てる」の三つで、残りはこの三つの手段だ。

短さの目安

CLAUDE.md は毎セッション読み込まれるため、肥大化するとコンテキストを圧迫するうえ、指示が埋もれて守られなくなる。この一点を9本が挙げている（CLAUDE.md 系では最多、全体では PostToolUse に次ぐ2番手だ）。記事間で目安は60行から500行までばらついていたが、検証すると公式が数字を出していた。公式 memory ドキュメントが「1ファイル200行未満」を目安として挙げている。長いほどコンテキストを食い、指示の遵守率も下がる、というのがその理由だ。

中身の絞り方

ここは表の3項目（8本・5本・5本）が重なる。定番の構成は、プロジェクトの一行説明、ビルドやテスト、lint の正確なコマンド、デフォルトと異なる規約、そしてプロジェクト固有の罠だ（8本）。取捨選択の基準として5本が挙げていたのが「この行を消したら Claude が間違えるか。間違えないなら消せ」で、これは公式 Best practices の原文にもそのまま載っている。コードから読み取れる情報、標準的な言語慣習、「きれいなコードを書け」の類いは書かない。逆に「packages/shared/src/legacy/ は旧 API 互換層。顧客3社が依存中なのでリファクタ禁止」のような、コードに書いていない事情こそ書く価値がある。書き方は測定可能に、というのも5本の一致だ。「ちゃんとテストして」ではなく「commit 前に npm test を実行」。禁止で終わらせず「any 型禁止。代わりに unknown + type guard」と代替案まで書く。

置き場所と育て方

階層配置を8本、育てる運用を7本が挙げた。全プロジェクト共通の前提（日本語で回答、コミット規約）は ~/.claude/CLAUDE.md、プロジェクト固有は ./CLAUDE.md として git 共有、個人だけの事情は CLAUDE.local.md を .gitignore に入れる。そして書いて終わりにせず、Claude がミスした直後に「CLAUDE.md を更新して再発を防いで」と Claude 自身に追記させ、数週間ごとに /memory で棚卸しして古い指示を消す。公式も「同じミスが再発するなら CLAUDE.md に書け」という趣旨を書いており、ここまで含めて一つの運用だと考えている。

200行を超えたらどうするか。7本が挙げていた答えが .claude/rules/ への分割で、testing.md code-style.md のように1ファイル1トピックで置き、frontmatter の paths にファイルパターンを指定すると、Claude がそのパターンに一致するファイルを読んだときだけルールが注入される。常時ロードの CLAUDE.md と違って、必要なときしか読まれない。

自分が新しいプロジェクトで CLAUDE.md を書き出すときの骨格はこれくらいだ。埋めるのは3ブロックで、空欄は消す。

# <プロジェクト名>：<一行で何をするものか>

## コマンド
- ビルド: pnpm build
- テスト: pnpm test
- lint: pnpm lint

## 規約
- （デフォルトと違う点だけ。例: import は ES modules、CommonJS は使わない）

## 罠
- （コードから読めない事情だけ。例: schema.prisma を変えたら pnpm build:schema を実行）

permissions:確認プロンプトとの戦い

自分が Claude Code を使い始めて最初にうんざりしたのが、コマンド実行のたびに出る確認プロンプトだった。8本が挙げた対策が permissions.allow で、安全と分かっている操作をパターンで事前許可する。自分のユーザー設定（~/.claude/settings.json）で allow に置いているのは、全プロジェクトで効かせたい WebSearch・WebFetch と、どこでも使う npm run・gh pr くらい（調べ物や PR 作成のたびに出る確認が消える。URL を絞りたいなら WebFetch(domain:...)）。あとは deny で底を固めている。

{
  "permissions": {
    "allow": [
      "WebSearch",
      "WebFetch",
      "Bash(npm run:*)",
      "Bash(gh pr:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(sudo:*)",
      "Bash(git push --force:*)",
      "Bash(git reset --hard:*)",
      "Read(.env)",
      "Read(**/.env.*)"
    ]
  }
}

4本が挙げていたのがこの deny による安全網で、rm -rf・force push・reset --hard・sudo・.env の読み取りを明示的に塞ぐ（~/.ssh や鍵を足すのも定番だ）。評価順は deny → ask → allow なので、allow をどれだけ広く取っても deny が必ず勝つ。allow は「どのプロジェクトでも安全に使うもの」だけに絞り、底はこの deny で守る、という分担だ。

allow がこれだけで済むのにも理由がある。git status や ls のような読み取り系は、現行版では組み込みで確認なし実行されるようになった。昔の設定に並べていた "Bash(git status)" の類いは、もう要らない。

設定ファイルのスコープも5本が触れていた。チームで共有すべきもの（CLAUDE.md、.claude/settings.json、.mcp.json、rules、skills）は git にチェックインし、個人の実験用 settings.local.json と CLAUDE.local.md は .gitignore に入れる。ここを雑にすると、同僚のリポジトリに個人の allow 設定が混入する。

hooks で「毎回やる」を自動化する

集計1位は PostToolUse 自動フォーマット（10/24）。Edit / Write のたびに Prettier や lint を機械的に実行するので、「フォーマットしてって言ったのにしてない」が構造的に起きなくなる。CLAUDE.md に「必ずフォーマットして」と書くのとの違いは確実性で、公式の整理を借りれば CLAUDE.md は advisory（助言）、hooks は deterministic（決定論的）。毎回・例外なく起きてほしいことは LLM の判断に任せず hooks に落とす、というのが3本が明文化していた設計原則で、個人的にはこれが hooks 系の推奨全部の親玉だと思う。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs -I{} npx prettier --write {} 2>/dev/null || true",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

prettier は JS 系の一例で、自分の言語に読み替える（Python なら ruff format、Go なら gofmt）。エラーを Claude に返して自己修正させたいなら、フォーマッタでなく lint や型チェックを exit code 2 で返す形にする。

2番手（6本）が Stop / Notification フックによる通知だ。応答完了や承認待ちで音を鳴らすかデスクトップ通知を出す。Claude Code は1タスクに数分かかることがあり、画面を見張り続けると人間のほうがボトルネックになる。macOS なら afplay でシステム音を鳴らすだけでいい。自分は Stop（応答完了）と Notification（入力待ち）に別々の音を当てている。

{
  "hooks": {
    "Stop": [
      { "hooks": [{ "type": "command", "command": "afplay /System/Library/Sounds/Hero.aiff" }] }
    ],
    "Notification": [
      { "hooks": [{ "type": "command", "command": "afplay /System/Library/Sounds/Glass.aiff" }] }
    ]
  }
}

こうすると、画面を見なくても「終わった（Hero）」のか「こっちの入力を待っている（Glass）」のかが耳で分かる。通知系はプロジェクトを問わないので ~/.claude/settings.json に置けば全プロジェクトで効く。地味だが、体感効果が一番大きい部類のフックだ。

3番手（4本）が PreToolUse による危険コマンドの実行前ブロック。stdin で渡ってくる JSON からコマンド文字列を取り出し、rm -rf や secret を含むコマンドなら exit 2 で止める。permissions.deny より柔軟な判定が書ける。

hooks の JSON を手で書くのが面倒なら、「ファイル編集後に prettier を自動実行する hook を追加して」と Claude 本人に頼むのが早い。公式もこの方法を案内している。

実際に入れているブランチガード

整形フックは、上の Prettier 一本ではなく Laravel 向けに振り分けている（PHP は Pint、Blade は Prettier）。ただコピーする価値が一番あると思っているのは整形ではなく、PreToolUse に入れたこのブランチガードだ。main か release にいる状態で git commit しようとすると、一度だけ止まって「作業ブランチを切り忘れていないか」と訊いてくる。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "input=$(cat); cmd=$(printf '%s' \"$input\" | jq -r '.tool_input.command // \"\"'); if printf '%s' \"$cmd\" | grep -qE 'git[^;|&]*[[:space:]]commit([[:space:]]|$)' && ! printf '%s' \"$cmd\" | grep -q -- '--no-verify'; then branch=$(git branch --show-current 2>/dev/null); if [ \"$branch\" = 'main' ] || [ \"$branch\" = 'release' ]; then printf '{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"permissionDecision\":\"ask\",\"permissionDecisionReason\":\"いま %s ブランチです。作業ブランチを切り忘れていませんか？\"}}' \"$branch\"; fi; fi",
            "timeout": 10
          }
        ]
      }
    ]
  }
}

設計で効いているのは2点。permissionDecision を deny ではなく ask にしていること。完全に禁止すると意図的な直コミットまで潰れるので、「止めて確認だけ求める」に留めてある。もう一つは、--no-verify の付いたコミットを判定から除外していること。意図してやるときは --no-verify を付ければ素通しになる、という抜け道を自分で用意している。整形の入れ忘れは後から直せるが、保護ブランチへの直コミットは戻すのが面倒で、CLAUDE.md に「main に直接コミットしない」と書いても人もモデルもたまに忘れる。だから助言ではなくフックで止める側に寄せた。この節の頭で書いた「毎回・例外なくやることは hooks に落とす」が、一番効いた場所だ。

Skills とスラッシュコマンド:統合後の注意点

7本が「たまにしか使わない知識・複数ステップの手順は Skills に切り出せ」を挙げた。API 規約、DB スキーマ、リリース手順のような資料を .claude/skills/<名前>/SKILL.md に置くと、関連するタスクのときだけ読み込まれる。常時ロードの CLAUDE.md を太らせないための受け皿で、「CLAUDE.md は短く」とセットで機能する。

一方で6本が挙げていた「定型タスクは .claude/commands/*.md でスラッシュコマンド化」は、読むときに注意がいる。カスタムスラッシュコマンドは Skills に統合済みで、.claude/commands/ は今も動くが、新規に作るなら skills が公式推奨になっている。統合の副作用として、かつてコマンドだったワークフローも Claude が「関連しそう」と判断すると自動起動し得る。デプロイのような副作用のあるスキルには frontmatter に disable-model-invocation: true を付けて手動起動専用にする。これは3本しか触れていなかったが、事故の種なので登場数以上に重要だと判断している。

調査はサブエージェントに外出しする

8本が挙げたのが「調査・探索タスクはサブエージェントに委譲しろ」。コードベース調査やログ解析のような大量のファイル読みをメインの会話でやると、途中経過でウィンドウが埋まり、肝心の実装に使う分が残らない。サブエージェントは別枠で動いて要約だけ返すので、メイン側は結論だけ受け取れる。公式 Best practices はこの「コンテキストウィンドウが最重要リソースで、埋まると性能が劣化する」を全推奨事項の根底に置いている。

使い方は「サブエージェントを使って認証まわりの実装を調査して」と明示するだけでいいし、現行版では読み取り専用の調査は Explore という組み込みエージェントに自動委譲されるようになった。つまりこの推奨は半分くらい製品側に取り込まれつつある。委譲するかの判断基準としては「過程は忘れていいから結果だけ欲しいタスクか」が一番しっくりくる。

この記事自体がその例で、24本を精読した中身はサブエージェントのコンテキストに消え、手元には要約された集計だけが返ってきた。一本ずつ読んだのはエージェントたちで、自分は集めて数えただけだ。タイトルを「精読して」でなく「集めて」にしたのは、そのためでもある。

運用習慣:設定ファイルの外にあるもの

設定ではないが登場数が多かったものを3つ。

Plan Mode

5本が挙げた。いきなり書かせると間違った問題を解く。Shift+Tab で Plan Mode に入り、探索→計画→実装→コミットの順でやる。公式が「探索してから計画、計画してからコード」として同じ4段階を載せている。ただし公式は「diff を一文で説明できる小さな変更に計画は不要」とも書いていて、何でも Plan Mode に通すとかえって遅くなる。

/clear

4本が挙げた。無関係な新タスクの前は毎回 /clear する。そして同じ問題への修正指示が2回失敗したら、粘らずに /clear して、学びを織り込んだ初期プロンプトで仕切り直す。失敗したアプローチの履歴がコンテキストに残っていると、それに引きずられて同じ穴に落ち続けるからだ。

自己検証の手段

4本が挙げた。プロンプトに「テストを実行して、失敗したら直して」を足すだけで、Claude は pass / fail を自分で読んで反復するようになり、人間が検証ループの一部にならずに済む。Claude Code 作者の Boris Cherny が「検証手段を与えるのが一番効く、品質が何倍にもなる」と述べたと複数の記事が引用していた。倍率そのものは眉に唾をつけて読むにしても、方向性は自分の経験とも一致する。

記事どおりに書くと、今は動かない5つ

検証パスで見つかった「かつて正しかったが今は違う」が5つあった。古い保存版をコピペするとき、ここが引っかかりやすい。

1. $CLAUDE_FILE_PATH は存在しない。 hooks の記事で最も広まっている書き方だが、この環境変数は公式には存在しない。現行仕様ではファイルパスは stdin の JSON で渡され、jq -r '.tool_input.file_path' で取り出す（上のコード例は修正済みのもの）。→ 公式 hooks
2. 行頭 # でのメモリ追記は当てにしない。 昔の記事にある「行頭に # を付けると CLAUDE.md に追記される」は、現行の公式ドキュメントには入力プレフィックスとして載っていない。追記は「これを CLAUDE.md に書いて」と頼むか、/memory で開いて編集するのが確実だ。→ 公式 memory
3. think / think hard はもう思考キーワードではない。 現在キーワードとして効くのは ultrathink だけで、恒常的に推論の深さを変えたいなら /effort コマンドを使う。→ 公式 model-config
4. @import はコンテキスト削減にならない。 「詳細は @docs/api.md に逃がして段階的開示」と多くの記事が書いているが、公式ドキュメントははっきり逆を書いている。import されたファイルは起動時に全部展開ロードされるので、整理にはなってもコンテキスト削減にはならない。削減が目的なら .claude/rules/ の paths 指定か Skills を使う。→ 公式 memory
5. スラッシュコマンドの位置引数は $0 始まり。 旧記事の「$1 が第1引数」は現行仕様と食い違う。$0 が第1引数。→ 公式 skills

Claude Code は今もこのペースで変わり続けているので、この記事も1年後には同じ扱いを受けるだろう。設定をコピペする前に一次情報（code.claude.com/docs）を引く癖のほうが、どの個別 Tips より長持ちする。

保存版がまだ追いついていない、直近の変化

ここまでは日付を問わず数えた合意だ。ただ Claude Code は数週間で変わるので、直近3ヶ月の記事と公式の週次 What's new・CHANGELOG を別に84件あたって30件を読んだ。基本項目（CLAUDE.md を短く、permissions、hooks、検証ループ）は数え直しても揺らがない。ただ、これまで手作業でやってきたことの半分が、2026年に製品側へ吸収されつつある。

手でやっていたこと	2026年の代替
permissions を手で育てる／YOLO で飛ばす	Auto mode（分類器が実行前に一件ずつ裁定）と /sandbox（Bash を OS レベルで隔離。auto-allow で許可プロンプト84%減）。ともに --dangerously-skip-permissions の安全な後継
CLAUDE.md をミスのたびに追記する	Auto memory（Claude が学びを自分で MEMORY.md に貯める。v2.1.59〜、既定オン）
/clear で仕切り直す（戻せない）	/rewind（各プロンプトから会話・コードを巻き戻せる。ただし git の代わりではない）
サブエージェントに委譲して待つ	既定でバックグラウンド実行（v2.1.198〜）＋ Dynamic Workflows で数十〜数百を一気に編成

表の右が、手作業を肩代わりし始めた製品側だ。ただ権限まわりだけは自分もまだ手で allow/deny を書いていて、Auto mode は research preview のうちは本番リポジトリに入れていない。表に入れなかった小粒では、消費の内訳を skill / plugin / MCP 別に出す /usage（MCP の入れすぎ検出に効く）、実装者に自分のコードを採点させない敵対レビューを1コマンドにした /code-review（旧 /simplify から分離）、難タスク用のエフォート xhigh（自分は普段のプロジェクトを上げている）、過負荷時の fallbackModel、編集を逐次レビューする security-guidance プラグインあたりも同じ時期に来ている。

ただしこの層はまだ動きが速く、Auto mode のように research preview のまま止まっているものもあるし、バックグラウンド実行が増えるほど"今 Claude が何をしているか"は見えにくくなる。手作業が減るのはありがたいが、丸ごと預けてよくなったわけではない。今から始めるなら、保存版を全部写経する前に、この層が自分のバージョンに来ているかを確かめるところからだと思う。

意見が割れていた論点

数えると、合意だけでなく割れている場所も見えた。二つ紹介する。

GitHub 連携は、gh CLI 派と GitHub MCP 派で真っ二つだった。公式と builder.io は「CLI ツールのほうがコンテキスト効率がいい」と gh CLI を推し、日本語圏の MCP まとめ系記事は GitHub MCP を推す。MCP はツール定義だけで常時コンテキストを消費するので、自分は公式側につく。brew install gh して gh auth login すれば動くので、MCP まで足す必要は感じていない。

もう一つが --dangerously-skip-permissions（いわゆる YOLO モード）の常用で、builder.io の1本は alias 登録まで薦めるが、24本中これを推したのはそこだけだった。日本語圏のコンセンサスはむしろ逆方向で、allow ＋ deny の構成に、必要なら sandbox や auto mode を重ねる。自分も後者を選ぶ。エージェントの誤操作は確率の問題なので、頻度が上がれば必ず引く。引いたときに deny の底があるかないかは大きい。

何から足すか

MCP やカスタムエージェントは後回しでいい。上で数えたとおり、効果の中心は地味な側にある。この作業で一番腑に落ちたのは、公式 Best practices の「ルールなしで正しくできるなら、そのルールは削除するか hook に変換しろ」という一文だった。書いて祈るのではなく、書かなくて済む仕組みに寄せていく。あなたの settings.json に足す1行を選ぶときも、この基準で選ぶのが一番外れがないと思う。

数えた24本

集計の母集団。個々の主張の食い違いや、上で触れた「今は動かない」記述の出どころも、ここから辿れる。

Qiita

• Claude Codeライトユーザー目線で、万人受けする便利設定を紹介（minorun365）
• 【保存版】Claude Code完全設定ガイド2026 - Hooks/Skills/MCP/権限を全部入りで本番運用する（emi_ndk）
• 【決定版】Claude Code 全設定リファレンス 2026（LemonCake）
• Claude Code作者が全公開！9種のカスタマイズ手段と設定の全貌（dai_chi）
• 【完全ガイド】Claude Code の CLAUDE.md を使いこなす（syeimee）
• Claude Code Hooks完全ガイド：18イベントの活用法（kai_kou）
• Claude Code の settings.json コピペですぐ使えるおすすめ設定まとめ（sarap422）
• 【2026年版】Claude Codeを最強にするプラグイン・MCP・ツール総まとめ（shatolin）
• CLAUDE.md / サブエージェント / スラッシュコマンド / エージェントスキルをまとめてみた（fujisho1216）
• Claude Code、その使い方はもったいない ― 実践TIPS集（homhom44）

Zenn

• Claude Code ベストプラクティス（farstep）
• 効果的なCLAUDE.mdの書き方（farstep）
• Claude Code設定の全体設計、個人的ベストプラクティス（2026年4月版）（soichiyo）
• 濫立するClaude Codeの機能の使い分け（notahotel）
• CLAUDE.md / Rules / Skills / Subagentsの役割と使い分け（helloiamktn）
• Anthropic社員のClaude Code活用術8選（happy_elements）
• Claude Codeを"使いこなす"ための個人ルール設定（dotdtech_blog）
• CLAUDE.md運用のベストプラクティス：失敗しないための7つの原則（imohuke）
• Claude CodeでMCPの設定を分けて運用する（lclco）
• Claude Code 完全ガイド（Zenn Book）（tmasuyama1114）

英語圏・公式

• Best practices for Claude Code（Anthropic 公式）
• 50 Claude Code Tips and Best Practices For Daily Use（builder.io）
• How I use Claude Code (+ my best tips)（builder.io）
• How to Write a Good CLAUDE.md File（builder.io）

「直近の変化」の裏取りに当たった一次情報:

• Claude Code CHANGELOG / What's new（週次）
• Choose a permission mode（auto / sandbox 等） / Configure the sandboxed Bash tool
• How Claude remembers your project（auto memory）
• Orchestrate subagents with dynamic workflows / Introducing dynamic workflows
• Making Claude Code more secure and autonomous with sandboxing