設定ファイルを1か所にまとめれば楽だと思っていると、だいたいあとで詰まる。Claude Code の settings.json も同じで、全部を個人設定に押し込むと、別プロジェクトで余計な癖が出る。逆にプロジェクト側に何でも書くと、今度は毎回同じ説明を繰り返す羽目になる。
この話の肝は単純だ。自分の作業スタイルに関わるものは個人設定、案件やリポジトリ固有のルールはプロジェクト設定に置く。これだけで、コンテキストの無駄打ちが減るし、指示の取り違えも減る。筆者は最初、案件ごとのルールまで個人側に寄せてしまい、別プロジェクトでも古い前提を引きずって手戻りした。あれは地味にだるい。設定の置き場所を雑にすると、AIの賢さ以前に運用が崩れる。
まず押さえるべきなのは、Claude Code が読む settings.json は大きく「個人」と「プロジェクト」の2系統で考えることだ。個人設定は、その人のマシン全体で効かせたいもの。プロジェクト設定は、そのリポジトリだけで効かせたいものだ。チーム作業ならなおさら、この分け方が効く。自分専用の好みと、みんなで守るルールを混ぜると、あとで誰かが必ず困る。
置き場所の考え方はこうなる。
たとえば個人設定には、「説明は短く」「差分を先に見せる」「危険な操作は勝手に進めない」といった、自分の作業習慣に近いものを置く。逆にプロジェクト設定には、「このリポジトリでは src/ 配下だけを触る」「日本語の文書を直すときは敬体を維持する」「ファイル名の命名規則はこの表記に合わせる」といった、その案件にだけ効くルールを書く。
実際の置き方は、まず公式ドキュメントで使っている場所を確認するのが安全だ。環境ごとの細かい差分がありうるから、断定しすぎるより一次情報を見たほうが早い。基本は、ホームディレクトリ側の個人設定と、プロジェクトルート側の設定ファイルを分けて持つ、という発想でいい。
たとえばプロジェクト側にはこんな感じで書く。
{
"permissions": {
"allow": [
"Read",
"Edit"
]
},
"instructions": [
"このリポジトリでは docs/ 配下の文書を優先して参照する",
"既存の文体を崩さず、敬体に寄せすぎない",
"ファイル名は半角英数とハイフンを使う"
]
}
個人側は、もっと汎用的でいい。自分の普段の作業に関わる指示だけを残す。
{
"instructions": [
"返答は要点から先に出す",
"曖昧な指示なら、勝手に大規模変更を始める前に確認する",
"変更前に影響範囲を短く説明する"
]
}
ここで大事なのは、個人設定にプロジェクト固有の文言を入れないことだ。これは本当にやりがちだ。筆者も一度、ある案件の書式ルールを個人側に入れたまま別の案件を触って、関係ない文書までその形式で整えそうになった。人間なら気づけるが、Claude Code は設定された前提をそのまま真面目に拾う。だからこそ、前提の置き場所を分ける必要がある。
逆に、プロジェクト設定に個人の好みを詰め込みすぎるのもまずい。たとえば「常に短く」「常に表を出す」「常に安全確認する」といった癖を案件ごとに焼き付けると、他の共同作業者には不要な制約になる。プロジェクト設定は、そのリポジトリで共有しても困らない内容に絞るのが筋だ。
非エンジニアの使い方でも、この分け方はかなり効く。たとえば、フォルダごとに書類を整える、PDFやテキストの重複を洗う、案件単位で資料を要約する、こういう使い方なら、個人設定には「ファイル名を短く見やすくする」「結果は箇条書きでなく文で説明する」といった自分向けの習慣を置く。案件ごとには「このフォルダ内の資料だけを見る」「原文の言い回しは変えすぎない」と入れておく。これで、別の案件に移ったときに前回のクセを引きずらない。
つまずきやすいのは、設定を足したのに効いていない、という勘違いだ。原因はだいたい3つある。1つ目は、置く場所を間違えている。2つ目は、同じ種類の設定が個人とプロジェクトの両方にあり、どちらが勝つのかを確認していない。3つ目は、設定ファイルを書き換えたあとに、Claude Code 側が古い前提をまだ持っていることだ。こういうときは、いったんセッションを切って入り直すだけで直ることがある。地味だが、これで救われる場面は多い。
もう1つ注意したいのは、設定を増やせば増やすほど賢くなるわけではない点だ。むしろ逆で、長すぎる instructions はノイズになる。特にプロジェクト設定に「やってほしいこと」を延々と並べると、何を優先すべきかぼやける。筆者は説明を盛り込みすぎて、肝心の「このフォルダ以外は触るな」という制約が埋もれたことがある。設定は盛る場所ではない。削る場所だ。
実務でちょうどいい分け方を覚えるなら、次の基準で考えると外しにくい。
最後にひとつ、実用上かなり大事な話をする。Claude Code に文書整理やファイル整理をさせるとき、設定の置き場所を分けておくと、作業の「再現性」が上がる。次の案件でも同じやり方を持ち込めるし、逆に案件固有のルールは持ち出されない。これが効くと、毎回の微調整が減る。派手さはないが、こういう地味な差が作業時間を削る。
settings.json は、ただの設定ファイルではない。どこに何を書くかで、Claude Code の振る舞いそのものが変わる。個人設定には自分の癖、プロジェクト設定には現場のルール。この線引きを先に決めておけば、余計な手戻りはかなり減る。公式ドキュメントで実際の配置場所と優先順位を一度確認してから、自分の運用に合わせて整えるのがいちばん堅い。