この記事でわかること
- Claude Code をインストールした直後に確認しておくべき設定項目
CLAUDE.mdをどう用意すると、後から読み返しても迷わないか- 権限（permissions）を絞るときの考え方と、絞りすぎたときに起きること
- 日本語環境・日本の業務で使う場合に実際につまずいた点
Claude Code を入れたら最初に見る場所
Claude Code は npm 経由でインストールでき、パッケージの実体は npm の @anthropic-ai/claude-code として公開されている。ソース自体は GitHub の anthropics/claude-code にあり、issue や changelog を追うならこちらを見るのが早い。
インストール直後に触ることになる設定は、大きく分けて3種類ある。ユーザー全体に効く ~/.claude/settings.json、プロジェクトごとに効く .claude/settings.json、そしてリポジトリ固有のふるまいを書く CLAUDE.md だ。この3つを最初に整理しておくかどうかで、その後の使い勝手がかなり変わる。特に複数のプロジェクトを行き来する人ほど、「どの設定がどこで効いているか」を最初に把握しておいた方がいい。すべてをデフォルトのまま使い始めると、後から「なぜこのコマンドだけ確認が出ないのか」「なぜこのディレクトリでは動きが違うのか」を調べ直す羽目になりやすい。
CLAUDE.md を最初に用意する
CLAUDE.md はプロジェクトの文脈をモデルに渡すためのファイルで、リポジトリ直下に置いておくとセッション開始時に自動的に読み込まれる。ゼロから書くのが面倒な場合は /init コマンドを実行すると、既存のコードベースを走査してたたき台を生成してくれる。ここで生成される内容はあくまで出発点であり、そのまま使うより、実際に何度か作業させてみて「毎回説明し直している内容」を追記していく方が結果的に精度が上がる。
書く内容として効果を感じやすいのは、コマンド一覧（テスト・型チェック・lint の実行方法）、ディレクトリ構成の意図、そして「してはいけないこと」の明文化だ。逆に、コード自体を読めば分かること（関数の実装詳細など）をここに書いても効果は薄く、ファイルが肥大化して読み込みコストが増えるだけになりやすい。
権限（permissions）を最初に絞る
初期設定のままだと、ファイル編集や特定のコマンド実行のたびに確認プロンプトが出る一方で、どこまでが自動許可されているかが分かりにくい。settings.json の permissions に allow / deny のリストを明示しておくと、日常的に使うコマンド（npm test や git status など）は確認なしで通し、破壊的な操作（rm -rf や外部への送信を伴うコマンド）は明示的に deny する、という運用にできる。
大事なのは「全部許可する」方向にも「全部確認させる」方向にも寄せないことだ。前者は事故のリスクを上げ、後者は確認疲れを招いて、結局ユーザーが内容を見ずに承認するようになる。どちらも本末転倒になりやすい。
フックと MCP は後回しでよい
Claude Code には PreToolUse / PostToolUse などのフックや、外部ツールと接続する MCP サーバーの仕組みもある。これらは強力だが、最初から手を出す必要はない。フックは「型チェックを自動で走らせる」「特定コマンドをブロックする」といった、実際に困りごとが出てから足す方が設計が安定する。最初からフックを大量に仕込むと、何が自動で起きているのか把握できなくなり、逆にトラブルシューティングの時間が増える。MCP サーバーも同様で、必要な外部連携が明確になってから接続する方が、権限管理の見通しも良い。
実際に試してわかったこと
実際に個人開発のリポジトリと、複数人が触る業務用リポジトリの両方で設定を運用してみると、CLAUDE.md を「仕様」ではなく「引き継ぎメモ」として書いたリポジトリの方が、数週間後に読み返したときの復帰が早かった。仕様をそのまま書き写すと、コードと CLAUDE.md の内容がずれたときにどちらが正しいか分からなくなり、結局読まれなくなっていく。
権限まわりでは、deny リストを先に厚く書いておくより、最初の1〜2週間は確認プロンプトを許容しつつ「よく聞かれるが毎回許可しているコマンド」をメモしておき、それをまとめて allow に昇格させる進め方の方が、リストの過不足が少なかった。最初から完璧なリストを作ろうとすると、実際の使用パターンとずれたリストになりがちだった。
もう一つ気づいたのは、.claude/settings.json と .claude/settings.local.json を分けて、チーム共有分と個人のローカル調整分を分離しておくと、複数人のリポジトリでも設定の衝突が起きにくかった点だ。個人用の一時的な許可設定をチーム共有ファイルに書いてしまうと、他のメンバーの環境で意図しない挙動になることがあった。
日本で使う場合の注意
日本語で CLAUDE.md やコミットメッセージ、コメントを書く運用自体は問題なく動く。ただし、日本語と英語が混在するプロンプトや設定ファイルでは、区切り文字や全角・半角の扱いによって意図しないマッチになることがあり、特に正規表現や文字列一致を使うフック・スクリプトを自前で書くときは、全角スペースや長音記号（ー）を含むテストケースを一つ加えて確認しておいた方がいい。半角の英数字だけで検証して満足すると、日本語混じりの実データで初めて崩れることがある。
また、社内の共有マシンや複数アカウントを使い分ける環境では、認証情報の保存先（キーチェーンや環境変数）がアカウントごとに正しく切り替わっているかを、設定を信じるのではなく実際に1回コマンドを叩いて確認する方が確実だった。設定ファイルの見た目が正しくても、実際にどのアカウントで認証されているかは別問題になることがある。
まとめ
初期設定でまず着手すべきは、CLAUDE.md の整備と、settings.json での権限の明示化の2点で、フックや MCP サーバーは実際に困りごとが出てから足していく順番の方が設計が崩れにくい。権限は「絞りすぎず、緩めすぎず」を、最初の数週間の実際の使用パターンを見ながら調整するのが現実的だ。まずは自分のリポジトリで /init を実行して CLAUDE.md のたたき台を作り、そこから1週間ほど実際に使いながら allow / deny のリストを育てていくところから始めてみてほしい。
