#claude-code-config

設定ファイルを1か所にまとめれば楽だと思っていると、だいたいあとで詰まる。Claude Code の settings.json も同じで、全部を個人設定に押し込むと、別プロジェクトで余計な癖が出る。逆にプロジェクト側に何でも書くと、今度は毎回同じ説明を繰り返す羽目になる。 この話の肝は単純だ。自分の作業スタイルに関わるものは個人設定、案件やリポジトリ固有のルールはプロジェクト設定に置く。これだけで、コンテキストの無駄打ちが減るし、指示の取り違えも減る。筆者は最初、案件ごとのルールまで個人側に寄せてしまい、別プロジェクトでも古い前提を引きずって手戻りした。あれは地味にだるい。設定の置き場所を雑にすると、AIの賢さ以前に運用が崩れる。 まず押さえるべきなのは、Claude Code が読む settings.json は大きく「個人」と「プロジェクト」の2系統で考えることだ。個人設定は、その人のマシン全体で効かせたいもの。プロジェクト設定は、そのリポジトリだけで効かせたいものだ。チーム作業ならなおさら、この分け方が効く。自分専用の好みと、みんなで守るルールを混ぜると、あとで誰かが

調べ物を全部ひとつの会話に押し込むと、すぐに文脈が死ぬ。これ、かなりありがちな失敗だ。Claude Code にはサブエージェント、英語で subagent と呼ばれる仕組みがあり、重い調査や周辺確認を分離して、本題の流れをきれいに保てる。うまく使うと、メインの作業は設計や編集に集中できるし、調べ物の途中で話が散らからない。ファイル整理でも、文書作成でも、コード修正でも効く。 筆者は最初、ひとつの会話の中で「このフォルダの重複ファイルも見て、不要キャッシュも見て、ついでに命名ルールも考えて」と全部投げた。結果、会話履歴が調査メモで埋まり、本題の指示がどんどんぼやけた。出てきた差分も読む気が失せる。あれはだるい。サブエージェントに分ければ、そういうムダな汚れをかなり減らせる。 やり方は単純だ。まず本流では「何を決めたいか」だけをはっきり書く。調べ物そのものは、サブエージェントに切り出す。たとえば、Claude Code にこんなふうに頼む。 ```text この案件では、メインの会話は意思決定と最終編集に使いたいです。 調査が必要な作業はサブエージェントに分けてください。 調べたいこと:

保存のたびにフォーマットを走らせたいのに、毎回「あとで Claude Code に整えて」と頼んでいるなら、かなり遠回りだ。フック、つまり hooks を使えば、その面倒な一手を先回りできる。 やりたいことは単純で、ファイルを保存した瞬間に Claude Code がフォーマット用の指示を受け取り、見た目や表記ゆれを整える流れを作ることだ。コードでも文章でも、雑に保存しても最後は同じ型に寄せたい。ファイル整理でも、Markdown の文書整形でも、この発想は効く。人間が毎回「整えて」と言うより、保存後の処理に吸わせたほうが圧倒的にだるくない。 ただし、ここで雑にやると逆に荒れる。保存のたびに全文をいじる、曖昧な指示で毎回違う結果になる、差分がでかくなって見直しづらくなる。この手の手戻りは、筆者も最初にかなり踏んだ。便利そうだからと丸投げすると、保存のたびに余計な修正が増えて、かえって手作業より面倒になる。だから最初から「何を直すか」を狭く決めるのがコツだ。 Claude Code には hooks がある。要するに、あるタイミングで決まった処理を差し込む仕組みだ。保存後にフォーマット、

毎回「これ許可していい？」を踏ませてくるなら、だいたい整理の仕方が悪い。Claude Code は便利だが、むやみに広い権限を渡すより、よく使う場所だけを先に許可リストへ入れておいたほうが、手が止まらない。 ここでいう権限の許可リストは、Claude Code が操作してよいディレクトリやファイルの範囲を、あらかじめ絞っておく考え方だ。リポジトリの中だけ、作業用フォルダだけ、あるいは特定の案件フォルダだけ。こうしておくと、余計な確認ダイアログが減る。結果として、ファイル整理でも文書作成でも、流れが途切れにくくなる。 筆者は最初、作業範囲を広く取りすぎて、ちょっとした編集でも確認が挟まっていた。これが地味にだるい。逆に絞りすぎると、今度は毎回止まる。中途半端な広さがいちばん使いにくい。Claude Code は「どこまで触っていいか」を先に決めてやると、急に扱いやすくなる。 まず押さえるべきなのは、許可リストを「便利設定」だと思わないことだ。これは安全のための境界線であり、同時に作業の段取りでもある。たとえば案件ごとにフォルダを分けているなら、その案件フォルダだけを作業範囲にする。会計資

毎回同じお願いをベタ打ちしているなら、そこがいちばんムダだ。Claude Code は「よく使う頼みごと」をスラッシュコマンドに落としておくと、指示の抜け漏れが減るし、毎回の入力もかなり軽くなる。 たとえば「このフォルダをざっと整理して」「この文章を読みやすく直して」「この差分を短く要約して」といった定番の頼み方は、手で打つほど雑になりやすい。急いでいると条件を書き忘れるし、長い依頼文はコピペのたびに少しずつ崩れる。そうなると、Claude Code 側は毎回あいまいな指示を受けて、手戻りが増える。筆者も最初はここでだいぶ損をした。頼みごとをそのまま繰り返していたせいで、出力の粒度が毎回ぶれて、結局もう一回やり直す羽目になった。 スラッシュコマンドは、その定番依頼を短い呼び出し名にまとめるやり方だ。Claude Code ではカスタムスラッシュコマンドをファイルとして置いておける。公式の扱いに沿って使うなら、まずは `CLAUDE.md` のような指示ファイルに毎回の前提を書き、個別の頼みごとはスラッシュコマンド化しておく、という分け方がしっくりくる。 たとえば、ドキュメントを毎回この

CLAUDE.md を「雑に長文で埋める箱」だと思っていると、だいたい損をする。効くのは、毎回ブレると困る前提だけだ。逆に、巨大な社内規約や操作マニュアルを丸ごと押し込んでも、Claude Code はそこを丁寧に読み上げる執事にはならない。 Claude Code でいう CLAUDE.md は、リポジトリや作業フォルダに置く指示メモだ。Claude Code がその場所で作業するときの癖付けに使う。ここに何を書けば手戻りが減るか、何を書いても効きが鈍いかを分けておくと、コンテキストの無駄食いがかなり減る。 まず効くのは、「この場所では何を優先するか」を短く固定することだ。たとえば、出力の形式、触ってよい範囲、依頼が曖昧なときの確認順、勝手に壊してはいけないもの、よく使うコマンドやディレクトリ構成などだ。逆に効きにくいのは、毎回変わる具体的な作業指示、長すぎる背景説明、抽象的なお作法の羅列である。そこを混ぜると、肝心のルールが埋もれる。 最初に押さえるべきなのは、CLAUDE.md は「長い説明書」ではなく「現場の癖」を書く場所だという点だ。たとえば、こんな書き方はかなり効く。 ``

毎回同じことを口で説明しているなら、その時点でもう負けである。Claude Code に仕事を頼むたびに「このフォルダは何のためのものか」「どのファイルを触っていいか」「何を勝手に変えないでほしいか」を打ち直していると、コンテキストも時間もじわじわ溶ける。そこで使うのが `CLAUDE.md` だ。別名でプロジェクトメモリとも呼べる。要するに、プロジェクト固有の作法を置いておくメモである。 これをちゃんと置いておくと、毎回の依頼が短くなる。しかも短くなるのは言葉だけではない。Claude Code が前提を取り違えにくくなるので、手戻りも減る。筆者は最初、都度の指示だけで回そうとして、同じ注意を書いては消し、また書いては消しを繰り返した。結果、依頼文が肥大化して、肝心の作業指示が埋もれた。あれはだるい。`CLAUDE.md` はその無駄を消すための置き場だ。 やることは単純だ。リポジトリのルートに `CLAUDE.md` を置き、そこに「このプロジェクトでは何を大事にするか」「どう編集するか」を書く。Claude Code は作業中にその内容を参照するので、毎回プロンプトに長文で貼らな