Xで「Claude Codeを入れたけど何から始めればいい？ 最初にやる5つの設定」という投稿を見て、たしかに大事だと思いました。
でも、まだ自分では使っていない立場だからこそ、少し違う角度で考えたいとも感じました。
つまり、「入れてから慣れる」より先に、「高いお金を払って導入するなら、最初に何を設計しておくべきか」を整理しておきたい、という視点です。
AI系のツールは、始めるだけなら早いです。
ただ、毎回同じ説明を繰り返したり、触ってほしくない場所まで触られたり、どこまでやれば完了なのか曖昧だったりすると、あとで地味にコストが積み上がります。
月額が高めの道具なら、なおさら最初に無駄打ちを減らす設計をしておきたいです。
文系寄りの仕事にたとえるなら、これは「優秀な外注先を入れる前に、依頼書と持ち出し禁止ルールを整える」話に近いです。
能力が高い相手ほど、前提が曖昧だとズレも大きくなります。
だから私は、Claude Codeを使う前に、まず働き方の設計図を作っておきたいと思いました。
この記事は、X投稿で挙がっていた5項目を出発点にしつつ、Anthropic公式ドキュメントの考え方に沿って、「導入前に決めるべきこと」として整理したメモです。
まず理解したいこと
最初に押さえたいのは、`CLAUDE.md` と `settings.json` は同じものではない、という点です。
ここを混ぜると、ルールを書いたつもりなのに安全装置が抜けたり、逆に権限設定で行動方針まで表現しようとして複雑になったりします。
Anthropic公式ドキュメントの memory 解説 に沿うと、`CLAUDE.md` は Claude Code がセッション開始時に読む、持続的な指示ファイルです。
ここには、作業方針、文章やコードのルール、確認の進め方、プロジェクトの前提などを書くのが自然です。
しかも `CLAUDE.md` はプロジェクト単位でも、ユーザー単位でも置けます。
たとえば、チーム全体で共有したいルールはプロジェクト側、いつも日本語で返してほしいような個人の好みはユーザー側、と分ける発想ができます。
一方で、Claude Code settings にある `settings.json` は、安全装置と権限設定の役割が中心です。
Anthropic公式では User、Project、Local というスコープがあり、どこまで許可するか、何を拒否するかを分けて考えられます。
たとえば `.env` や `secrets` を読ませたくないなら、`CLAUDE.md` に「読まないで」と願うより、`permissions.deny` で読めないようにする方が筋がいいです。
要するに、こう整理したほうが分かりやすいです。
- `CLAUDE.md` = 方針とルール
- `settings.json` = 安全装置と権限
この分担が見えているだけで、導入前の設計はかなりやりやすくなります。
導入前に決めておきたい5つのこと
① 就業規則
X投稿でいう「就業規則」は、かなり良い言い方だと思います。
Claude Codeは賢い分、何も決めないと「できること」を広めに解釈しやすいはずです。
だから最初に、「この現場ではどう働いてほしいか」を短く決めておく意味があります。
ここで大事なのは、`CLAUDE.md` を何でも書けるノートにしないことです。
公式ドキュメントでは、`CLAUDE.md` は長すぎると効きが落ちやすいので、具体的で簡潔に保つのがよいとされています。
目安としては、読んでその場で確認できる文に寄せた方がよさそうです。
たとえば、こんなルールです。
- 変更前に目的を一文で要約する
- 既存ファイルを消す前に確認を取る
- まず調査し、次に提案し、最後に編集する
- 不明点があるときは推測で進めすぎない
これは会社の就業規則というより、仕事の進め方の約束に近いです。
でも、この約束がないまま使い始めると、毎回「まず何して」「勝手にそこは触らないで」を言い直すことになります。
② 言語設定
「日本語で答えてほしい」は、軽く見えてかなり重要です。
なぜなら、出力言語がぶれると、確認コストもぶれるからです。
とくに非エンジニア寄りの人が使うなら、英語のまま返ってくるだけで心理的なハードルが上がります。
逆に、議事録、記事、要約、運用メモなどを扱うなら、日本語で統一されているだけでかなり扱いやすくなります。
ここはユーザー単位の `CLAUDE.md` に入れておくのが自然そうです。
たとえば「回答は原則日本語。専門用語は短く説明する」のように書いておけば、毎回の説明を減らせます。
ただし、これも長くしすぎない方がいいです。
「常に日本語」「コードやコマンドは原文維持」「専門用語には短い説明を付ける」くらいまで絞った方が効きやすいはずです。
③ 確認レベル
私はここが、導入前に一番決める価値があると思っています。
なぜなら、AIツールの使い心地は、賢さ以上に「どこで確認を挟むか」で変わるからです。
同じ作業でも、毎回確認してほしい人と、ある程度まとめて進めてほしい人では、快適さがかなり違います。
文系の仕事でたとえるなら、これは「1段落ごとに見せてほしいか、初稿をまとめて見たいか」の違いです。
導入前に決めるなら、少なくとも次の3段階くらいに分けて考えたいです。
#### 軽作業はそのまま進めてよい
誤字修正、見出し整理、表現の微調整などです。
ここまで毎回止まると、むしろ遅くなります。
#### 中くらいの変更は、実行前に一言ほしい
ファイル追加、構成変更、既存文の大きめの書き換えなどです。
この層は、あとで「そこまで変えるつもりじゃなかった」が起きやすいです。
#### 危険な変更は必ず止まってほしい
削除、上書き、認証情報に触れる操作、本番反映、外部送信などです。
ここは `CLAUDE.md` に方針を書くより、`settings.json` 側の権限設計もセットで考えたほうが安全です。
④ 触ってよい場所・触らない場所
X投稿では「プロジェクト構造を伝える」に近い話ですが、導入前に考えるなら、もう一歩具体的にしたいです。
つまり、「このツールはどこまで見てよくて、どこから先は見せないか」です。
Claude Codeにプロジェクト構造を教えること自体は大事です。
どこに記事があり、どこに調査メモがあり、どこが正本なのかが分かれば、ズレた編集は減りやすいはずです。
ただ、それと同じくらい大事なのが、「見せない場所を最初に決めること」です。
たとえば、こうです。
- `posts/` は公開原稿
- `content/drafts/` は下書き
- `docs/` はルール
- `.env` や `secrets/` は読ませない
- 生成物や一時ファイルは編集対象にしない
このうち前半は `CLAUDE.md` の役割です。
後半の「読ませない」は `settings.json` の `permissions.deny` で考える方が正確です。
ここを分けておくと、「触らないでほしい」をお願いベースで済ませずに済みます。
人間でもAIでも、ルールより先に物理的な柵がある方が事故は減ります。
⑤ 完了条件
最後に必要なのは、「どこまでやったら終わりか」を先に決めることです。
これがないと、AIは親切心で仕事を広げやすく、人間は確認ポイントを失いやすいです。
たとえばブログ記事なら、完了条件はこう書けます。
- 下書き保存までで終わる
- 見出しと導入を整える
- 本文を会話内にも表示する
- 公開はしない
逆に、実装系ならこうです。
- 修正箇所は1ファイルだけ
- テスト実行まで
- デプロイはしない
- 失敗時は原因を3行でまとめる
これは地味ですが、かなり効くはずです。
完了条件が曖昧だと、ツールの性能より「どこで止めるか」のズレで疲れやすくなります。
高い料金を払って入れるなら、まずここを先に決めたいです。
実際に最初に作るメモのたたき台
ここでは、導入前にまず作っておきたい最小限のたたき台を書いておきます。
Anthropic公式では `/init` で初期の `CLAUDE.md` を作る方法も案内されていますが、最初から自分の運用ルールを短く足す前提で見たほうがよさそうです。
CLAUDE.md の簡易サンプル
- 回答は原則日本語で行う
- 専門用語を使うときは短く説明する
- 変更前に、目的とやることを短く整理する
- 大きな変更、削除、公開系の操作は実行前に確認する
- `posts/` は公開原稿、`content/drafts/` は下書き、`docs/` はルールとして扱う
- 依頼されていない作業は広げすぎない
- 完了時は、変更点・未実施事項・次の確認点を短くまとめる
ポイントは、盛り込みすぎないことです。
公式ドキュメントでも、`CLAUDE.md` は簡潔で具体的な方が効きやすいとされています。
最初は「読むたびに行動が変わる文」だけに絞った方がよさそうです。
settings.json で考えるべきことの例
この設定は「秘密情報に触れさせない」ための考え方の例です。
ここに加えて、どのコマンドは確認必須にするか、どのディレクトリは対象外にするかも、使い方に応じて決めることになります。
Anthropic公式の整理では、`settings.json` には User / Project / Local のスコープがあります。
なので、全案件で共通の安全装置はUser、プロジェクト固有の制限はProject、個人の一時的な調整はLocal、のように分けて考えると運用しやすそうです。
まだ使っていない今の自分が思うこと
まだ自分はClaude Codeを本格導入していません。
だからこそ言えるのは、最初に触る前の設計で、3か月後の使い方がかなり変わりそうだということです。
AIツールは、入れた瞬間に価値が出るというより、使い方の型が固まってから効いてくる道具だと思います。
毎回その場の思いつきで使うと、便利さより「説明のやり直し」が増えやすい。
逆に、最初にルールを作っておけば、あとで修正するときも「どこを直せばいいか」が明確です。
これは、ノート術やフォルダ整理に少し似ています。
最初の30分は面倒でも、置き場所が決まっていれば、あとで探す時間が減ります。
Claude Codeも同じで、いきなり使い始めるより、先にルールを作る方がたぶん賢いです。
少なくとも私は、もし導入するなら「まず課金してから考える」ではなく、「課金前に働き方を定義してから入れる」を選びたいです。
まとめ
Claude Codeの話を見ていると、つい「AIを入れること」そのものが前に出やすいです。
でも実際には、その前に「AIの働き方を決めること」のほうが、最初の差になるのではないかと思います。
高いお金を払う前に決めることは、遠回りではありません。
むしろ、その準備自体が最初の最適化です。
導入前チェックリスト
- `CLAUDE.md` に書く就業規則を、短く具体的に決めたか
- 回答言語と説明の粒度を、毎回言い直さなくてよい形にしたか
- どこで確認を挟み、どこまで自動で進めてよいかを決めたか
- 触ってよい場所と、`permissions.deny` で遮断する場所を分けて考えたか
- 何をもって完了とするかを、作業前に言語化したか
参照メモ
- X投稿で見た「Claude Codeを入れたけど何から始めればいい？ 最初にやる5つの設定」という要旨を出発点に整理
- How Claude remembers your project | Anthropic Docs
- Claude Code settings | Anthropic Docs
