Claudeおすすめ設定9選｜Web版とCode両対応の最強カスタマイズ
Claude を入れたまま「素のまま」で使い続けている方は非常に多いですが、初期設定を整えるだけで体感品質と安全性が一段上がるのがこのツールの特徴です。本記事では Web 版 claude.ai と Claude Code(CLI 版)それぞれで、入れた直後に必ずやっておきたいおすすめ設定を 9 項目に絞って解説します。
Web 版 claude.ai でまず触るべきは「プライバシー」と「メモリ」の 2 か所です。データプライバシーコントロールで学習提供をオフにし、保持期間を 30 日へ縮めるだけで情報露出リスクを大きく下げられます。メモリは会話履歴とは別管理で残り続けるため、定期的な棚卸しが前提になります。
Claude Code 側は CLAUDE.md と settings.json の二段構えで運用するのが定石です。プロジェクト直下の指示書で前提・禁止事項・依頼の粒度を明示し、settings.json で許可するコマンドと環境変数を絞り込みます。これだけで「想定外の rm」「想定外の git push」がほぼ消えます。
Hooks と権限設計は Opt-in 原則を貫くと事故が起きにくくなります。マーカーファイルがあるリポだけで発火させる設計に統一し、危険コマンドは Auto Mode を有効化する前にブロックリストへ入れておくのが安全です。本文では具体的な設定手順と検証方法まで踏み込みます。
目次 (12)
- ステップ 1: Claudeおすすめ設定の全体像｜Web版とClaude Codeで触る場所が違う
- ステップ 2: Web版のデータプライバシー｜モデル学習オフで保持期間を30日に短縮
- ステップ 3: Web版のメモリ機能｜会話履歴とは別レイヤーで残るので定期棚卸しが必須
- ステップ 4: 返答スタイルとプリファレンス｜トーンと言語を固定して安定感を出す
- ステップ 5: Claude Code の CLAUDE.md｜起動時に自動読み込みされる指示書を整える
- ステップ 6: settings.json の階層設計｜グローバルとプロジェクトを役割で分ける
- グローバル(~/.claude/settings.json)に書くもの
- プロジェクト直下(.claude/settings.json)に書くもの
- ステップ 7: permissions の許可リスト｜Auto Mode 解禁前に危険コマンドを必ず潰す
- ステップ 8: Hooks のおすすめ活用｜Opt-in パターンで暴発を防ぐ
- ステップ 9: 設定変更後の検証と運用Tips｜実機テストと月次見直しをセットに
- まとめ｜Claudeおすすめ設定の優先順位は「プライバシー → 規約 → 権限」
ステップ 1: Claudeおすすめ設定の全体像｜Web版とClaude Codeで触る場所が違う
Claude には大きく分けて、ブラウザで使う Web 版 claude.ai と、ターミナルから呼び出す Claude Code(CLI) の 2 系統があります。設定画面と設定ファイルが完全に独立しているため、まず自分がどちらをメインで使うかを意識して優先順位を決めます。
ライトユーザーは Web 版のプライバシー・メモリ・スタイルの 3 点だけ整えれば十分です。一方、開発で日常的にコードを触る人は Claude Code 側の CLAUDE.md と settings.json を真っ先にチューニングすべきで、ここを放置すると本来のポテンシャルの半分も発揮できません。両方使う人は 「Web 版 → Code 側」の順に設定すると迷いません出典。
ステップ 2: Web版のデータプライバシー｜モデル学習オフで保持期間を30日に短縮
Web 版 claude.ai の初期状態では、入力した内容が Anthropic のモデル改善に使われる可能性があり、学習提供をオンにするとデータが最大 5 年間保持される設計になっています。仕事の会話や顧客情報を扱う人は、まずこの設定をオフにしておきたいところです。
設定手順は次の通りです。
- claude.ai 右下のアカウントアイコンから「設定」を開く
- 「プライバシー」タブの 「データプライバシーコントロール」 を選ぶ
- 「Claudeの改善にご協力ください」を オフ に切り替える
これだけで保持期間が 30 日まで短縮されます。Team / Enterprise プランではデフォルトでオフになっていますが、Free / Pro / Max ユーザーは手動で切る必要があります出典。
ステップ 3: Web版のメモリ機能｜会話履歴とは別レイヤーで残るので定期棚卸しが必須
Claude のメモリは 会話履歴とは独立したレイヤーで動いており、過去の会話を削除してもメモリそのものは消えません。これを知らずに会話だけ消して安心している人が非常に多く、注意が必要です。
おすすめの運用は以下の 3 点です。
- 月 1 回「設定 → メモリ」を開き、不要なメモリを手動削除する
- 機密寄りの相談をする際は、事前にメモリ自動生成を一時オフにする
- プロジェクトを切り替えるタイミングで、前プロジェクトのメモリを棚卸しする
メモリは便利な反面、想定外の場面で引用されることがあるため、「学習オフ」と「メモリ棚卸し」はセット運用と覚えておくと安全です。
ステップ 4: 返答スタイルとプリファレンス｜トーンと言語を固定して安定感を出す
Claude は「スタイル設定」で、すべての会話に対する既定のトーンや出力ルールを宣言できます。毎回プロンプトに前置きを書く手間が消えるため、業務利用の人ほど効果が大きい設定です。
おすすめは次の 3 行をプリファレンスに登録しておく構成です。
- 「日本語で簡潔に答える。冗長な前置きを省略する」
- 「コードを出す時は実行可能な最小例に絞る」
- 「断定できない箇所は推測である旨を明記する」
これだけでハルシネーションの体感頻度が下がり、毎回同じ指示を打つストレスからも解放されます。チームで共有するなら、スタイルを Notion などにテキスト保存しておくと再利用が利きます。
ステップ 5: Claude Code の CLAUDE.md｜起動時に自動読み込みされる指示書を整える
Claude Code は起動時にカレントディレクトリの CLAUDE.md を自動で読み込み、その内容を全会話の前提として扱います。プロジェクトのコーディング規約・禁止事項・依頼の粒度をここに集約することで、毎回の指示量が劇的に減ります出典。
最初に書くべき要素は次の通りです。
- プロジェクト概要(技術スタック・主要ディレクトリ構成)
- 守ってほしい規約(命名・テスト・コミットメッセージ)
- やってはいけないこと(直 push 禁止、特定ディレクトリ触り禁止 など)
- 困ったときの問い合わせ先 / 参考リンク
肥大化しがちな点に注意し、「簡潔・具体・必要最小限」 を基本姿勢にすると、長期運用しても破綻しません。
ステップ 6: settings.json の階層設計｜グローバルとプロジェクトを役割で分ける
Claude Code の挙動は ~/.claude/settings.json(グローバル)とプロジェクト直下の .claude/settings.json(プロジェクト固有)の 2 階層で制御します。親ディレクトリから設定は継承されず、起動ディレクトリ直下のみが有効になる点が落とし穴です。
おすすめの分担は以下の通りです。
グローバル(~/.claude/settings.json)に書くもの
- 全プロジェクト共通の通知(完了音・Slack 通知 など)
- 機密ファイル(
.env/ 鍵 /secrets.*)の読み取りブロック - 危険コマンド(
rm -rf */git push --force)のグローバル禁止
プロジェクト直下(.claude/settings.json)に書くもの
- そのリポジトリ専用の権限許可(特定 Bash 許可リスト)
- リポジトリ内ファイルだけに発火する Hooks
- そのプロジェクトでのみ使う環境変数
この役割分担を最初に決めておくと、後から設定が雪だるま式に増えても破綻しません。
ステップ 7: permissions の許可リスト｜Auto Mode 解禁前に危険コマンドを必ず潰す
Claude Code には毎回の確認をスキップする Auto Mode がありますが、これをオンにする前に 危険コマンドをブロックリスト化しておくことが事故防止の最低条件です。一度走らせると取り返しがつかない操作は、確認ダイアログでも判断ミスが起きやすいため、根元から塞ぐのが正解です。
最低限ブロックしておきたい代表例:
rm -rf系の再帰削除git push --force/git reset --hardcurl ... | sh形式の外部スクリプト実行aws/gcloud等のクラウド破壊系コマンド- データベースの
DROP TABLE/TRUNCATE
許可リスト側は「読み取り系」「テスト実行系」「ローカル build」など、最悪戻せる操作だけを Allow にしておくのが運用上ラクです出典。
ステップ 8: Hooks のおすすめ活用｜Opt-in パターンで暴発を防ぐ
Hooks は Claude Code のイベント(SessionStart / PreToolUse / Stop など)に合わせて自前スクリプトを発火させる仕組みで、運用ルールの自動化に強力です。一方で、全リポで無条件に動く Hooks は事故の温床になるため、Opt-in 原則で設計するのが鉄則です。
おすすめのパターンは以下です。
- マーカーファイル方式: リポ直下に
.claude-hooks-enabledがある時だけ Hooks 発火 - PreToolUse で git status 確認: 別 session の変更を上書きしないようにする
- SessionStart で重要ドキュメントを Read: 構成ファイル・SOP を毎回最初に読ませる
- Stop hook で通知: 完了時に Slack / 通知センターへ知らせて待ち時間ゼロ
「全部入り」を避け、まずマーカー方式の 1 本から始めると暴発リスクを最小化できます。
ステップ 9: 設定変更後の検証と運用Tips｜実機テストと月次見直しをセットに
設定を入れたら必ず実機で動作確認します。CLAUDE.md は 新規の小さな依頼を 1 件投げて、規約通りに動くかを確認します。permissions は意図的に禁止コマンドを叩いてブロックされるかを試し、Hooks は SessionStart のログがちゃんと残るかを目視で確認します。
長期運用のおすすめは次の 3 点です。
- 月 1 回のレビュー: メモリ・CLAUDE.md・settings.json を 15 分で棚卸し
- 設定変更は PR 化: チーム運用なら
.claude/settings.jsonを git 管理し、レビューを通す - 失敗事例をメモる: 暴発・誤動作が起きたら CLAUDE.md に「やってはいけないこと」として追記
設定は一度で完成させるものではなく、「育てる対象」として捉えるのが Claude を長く使い倒すコツです。
まとめ｜Claudeおすすめ設定の優先順位は「プライバシー → 規約 → 権限」
Claude の設定は数が多く一見ハードルが高そうに見えますが、本記事で挙げた Web 版 4 項目 + Claude Code 5 項目の合計 9 つを押さえれば、安全性と生産性の両方を一気に底上げできます。特に「データプライバシー → CLAUDE.md → permissions」の順に整えるだけで、想定外の事故はほぼ起きなくなります。
ライトユーザーは Web 版だけ、開発者は Claude Code 側まで踏み込み、チームで使う場合は settings.json と CLAUDE.md を git 管理する、というのが現時点のベストプラクティスです。まずは今日 15 分、自分のプロファイル設定を開いて 1 つだけ変えるところから始めてみてください。
