Claude Codeおすすめ設定5選｜承認9割減の実例

Q: 設定はチームで共有すべき？

はい、チーム共通のルールはGitに含めるのが正解です。.claude/settings.jsonとCLAUDE.mdはコミットし、個人の好みやAPIキーはsettings.local.json（gitignore対象）に分けます。

Q: Auto-accept / bypass permissions モードは安全に使える？

denyルールをきちんと整備した上であれば実用範囲です。何も塞がずに有効化するのは危険で、破壊的コマンドを全てdenyで塞いでから使い始めることを推奨します。

Q: 設定をリセットしたい時はどうする？

該当するsettings.jsonを削除またはリネームすればデフォルトに戻ります。まずバックアップしてから消すのが安全で、/configコマンドで現状を確認できます。

Claude Codeを使い始めた頃の私は、毎回の権限承認ダイアログに辟易していました。

「ls 実行していい？」「grep していい？」と聞かれるたびに作業が止まり、正直「これ本当に効率化ツール？」と疑った時期すらあります。

結論から言うと、Claude Codeのおすすめ設定は「settings.json」「CLAUDE.md」「Hooks」「Skills」「MCP」の5要素を整えるだけです。

特にsettings.jsonのpermissionsを正しく組むと、承認ダイアログが体感9割減って作業速度が3倍に変わります。

デフォルトのまま使うのは、ガチャで引いたばかりの初期キャラを丸腰で出撃させるようなものです。

この記事では、私が1年ほど業務と個人開発で使い倒してきた中で「これは入れたほうがいい」と確信している【2026年10月時点】のおすすめ設定を、コピペで使える実例つきでまとめました。

設定迷子になっている人や、これから本格運用を始める人がそのままコピペで時短できる構成にしました。

この記事でわかること

Claude Codeのおすすめ設定が体系的にわかる
settings.jsonのpermissions・hooksの実例がコピペで使える
CLAUDE.md・Skills・MCPの使い分けが整理できる

PARTS LIST ／目次

最初の5分で済ませる Claude Code おすすめ設定3つ
Claude Codeのおすすめ設定はなぜ"効率を3倍変える"のか
まず最初にやるべき settings.json のおすすめ設定
CLAUDE.md で"プロジェクトの記憶"を作る3つのコツ
作業効率が跳ね上がる Hooks のおすすめ活用法
Skills とカスタムコマンドのおすすめ設定｜定型作業を1コマンド化
- Skills とは何か（slash command との違い）
- 私が実際に使っているおすすめ Skill 3つ
MCP サーバーで外部ツールと接続する
- GitHub・Slack・Notion を繋ぐ手順
- MCP導入で気をつけたい権限の落とし穴
statusline・model・output style のおすすめ追加設定
/config コマンドで触っておきたいおすすめ設定
Claude Codeのおすすめ設定に関するよくある質問（FAQ）
まとめ｜設定を"育てる"ことで Claude Code は別物になる

最初の5分で済ませる Claude Code おすすめ設定3つ

細かい話の前に、まず5分で終わる最低限のおすすめ設定だけ先に出します。

Claude Codeを入れたばかりの人は、ここだけコピペすれば最低限「快適に動く状態」になります。

~/.claude/settings.json に permissions.allow で読み取り系コマンド（ls / rg / git status 等）を許可 → 承認ダイアログ9割減
~/.claude/settings.json に permissions.deny で rm -rf / git push --force を禁止 → 事故防止
プロジェクトルートに CLAUDE.md を10〜20行で作成（言語・主要ディレクトリ・禁止事項のみ） → 毎回の前提共有が不要に

この3つだけで体感の作業速度がガラッと変わります。

以降のセクションでは、この基本設定を踏まえてsettings.json・CLAUDE.md・Hooks・Skills・MCPの5要素を順に説明していきます。インストールや基本操作がまだの場合は、先にClaude Code使い方｜導入から実践活用までで動かしておくとスムーズです。

Claude Codeのおすすめ設定はなぜ"効率を3倍変える"のか

Claude Codeは設定の積み重ねでパフォーマンスが大きく変わるツールです。

理由はシンプルで、AIが扱う前提情報と権限スコープを設定で渡してあげないと、毎回ゼロから状況確認させることになるから。

逆に言うと、settings.jsonとCLAUDE.mdに正しい情報を書き込んでおけば、確認の往復が一気に減り、初手から本題に入れます。

デフォルトのまま使うと何が起きるのか

素のClaude Codeは、ファイル編集やコマンド実行のたびに承認を求めてきます。

安全側に倒した設計なので当然なのですが、毎回承認していると集中が切れます。私は最初の1週間で承認ボタンを数百回以上押しました。

もう1つの落とし穴が、プロジェクト固有のルールをAIが知らないこと。

命名規則・テストの書き方・避けるべきライブラリ、これらを毎回プロンプトで伝えるのは現実的ではありません。設定で先に渡しておくのが正解です。

設定ファイルの3階層（global/project/local）を理解する

Claude Codeの設定は3階層に分かれています。役割を覚えると迷子になりません。

階層	パス	用途
グローバル	~/.claude/settings.json	全プロジェクト共通の好み
プロジェクト	.claude/settings.json	チームで共有する設定（Git管理）
ローカル	.claude/settings.local.json	個人専用・Git管理外

共有したい設定はプロジェクト、APIキーや個人の好みはローカル、という分け方が安全です。

なお、2026年10月時点の公式ドキュメントでは、この3つの上に組織が配布する管理設定（managed settings）があり、優先順位は「管理設定 > コマンドライン引数 > ローカル > プロジェクト > グローバル」です。permissionsのallow／denyのようなリストは上書きではなく各階層の内容が合算され、どこかの階層にdenyがあれば、別の階層のallowより優先されます。

Claude Codeを日本語化する｜language設定で応答言語を固定する

Claude Codeは日本語で聞けば日本語で返してくれますが、英語での質問や会話の流れによっては応答が英語に戻ることがあります。

毎回「日本語で」と付け加えるのが面倒な人は、settings.jsonにlanguageキーを追加しておけば応答言語を日本語に固定できます。

{
  "language": "japanese"
}

設定後は/statusで読み込まれた設定ファイルを、claude doctorで無効として読み飛ばされた設定項目を確認できます。

なお、CLAUDE.mdに「常に日本語で応答する」と書く方法もありますが、こちらは構造化された恒久設定、CLAUDE.mdはプロジェクトごとの指示文という役割の違いがあるので、個人の好みを固定したいだけならlanguageキーのほうがシンプルです。

プライバシーを守るオプトアウト設定｜学習データ利用とテレメトリを止める

Free/Pro/Maxプランでは、Claude Codeに入力した内容がモデル改善（学習）に利用される場合があります。

業務のコードやデータを扱う人は、claude.aiのプライバシー設定（claude.ai/settings/data-privacy-controls）で、モデル改善へのデータ利用をオフにすることでオプトアウトできます。

Team/Enterpriseプランはデフォルトで学習に利用されないため、この設定は不要です。

もう1つ、コードやファイル内容は含まれないものの、使用パターンやエラーログなどのテレメトリも収集されています。気になる場合は環境変数で無効化できます。

# 利用状況メトリクスとエラーレポートだけを止める
export DISABLE_TELEMETRY=1
export DISABLE_ERROR_REPORTING=1

自動アップデートなども含めて必須ではない通信をまとめて止めるCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1もあります。ただし2026年10月時点の公式ドキュメントでは、自動アップデートやリリースノート、Remote Controlなども使えなくなると説明されているので、テレメトリだけ止めたいなら上の2つで足ります。ただしDISABLE_TELEMETRYも機能フラグの取得を止めるため、Remote Controlが使えなくなる場合があります（2026年10月時点の公式ドキュメント）。

会社のコードを扱うプロジェクトでは、この2つを最初に確認しておくと安心です。

まず最初にやるべき settings.json のおすすめ設定

最優先で触るべきは permissions です。

安全なコマンドはallow、危険な操作はdeny、それ以外はaskで確認、という3層構造で組むのが鉄則。

判定は「deny → ask → allow」の順で行われ、最初に一致したルールで結果が決まります（2026年10月時点の公式ドキュメント）。allowに広く書いても、denyに入れた操作は必ずブロックされるということです。

これだけで承認ダイアログの数が9割近く減ります。

permissions の判定順（最初に一致したルールで決まる）

DENY ／危険な操作deny に一致 → 実行をブロックallow に広く書いていても、ここで必ず止まる

一致しなければ次へ

ASK ／確認したい操作ask に一致 → 確認を出す

一致しなければ次へ

ALLOW ／安全なコマンドallow に一致 → 承認なしで自動実行

どれにも一致しない

OTHER ／それ以外その都度確認

NOTE危険な操作は deny、安全なコマンドは allow に入れておくと、承認の手間と事故を同時に減らせる。

permissions で安全コマンドを allow する

読み取り系コマンドは原則allowで問題ありません。私が常用しているのは以下の組み合わせです。

{
  "permissions": {
    "allow": [
      "Bash(ls:*)",
      "Bash(rg:*)",
      "Bash(grep:*)",
      "Bash(find:*)",
      "Bash(cat:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ]
  }
}

git statusやgit diffは破壊性ゼロなのでallow推奨。承認1つでテンポが変わります。

記法はBash(ls:*)のほかにBash(ls *)（スペース＋*）とも書けます。2026年10月時点の公式ドキュメントでは2つは同じ意味として扱われ、承認ダイアログで「今後は確認しない」を選んだときに書き込まれるのはスペース区切りの形式です。

危険操作は deny で完全ブロックする

事故を避けたい操作はdenyで塞ぎます。私は rm -rf・git push --force・本番DBへの接続をdenyに入れています。

askより強く、AIが提案すらできなくなるので安心感が違います。

"deny": [
  "Bash(rm -rf:*)",
  "Bash(git push --force:*)",
  "Bash(git reset --hard:*)"
]

環境変数・APIキーの読み取りを禁止する

意外と忘れがちなのが秘密情報の保護。

.envやcredentials.jsonを読まれてログに残ると地味に怖いので、Read自体をdenyしておきます。

"deny": [
  "Read(./.env)",
  "Read(./.env.*)",
  "Read(**/credentials.json)"
]

本文の設定例で判定すると、各操作はこうなる

OPERATION ／操作

一致するリスト

結果

Bash(git status)

allow

承認なしで実行

Bash(rg …)検索系

allow

承認なしで実行

Bash(rm -rf …)

deny

ブロック戻せない操作を塞ぐ

Bash(git push --force …)

deny

ブロック

Read(./.env)

deny

ブロック秘密情報を読ませない

Bash(git commit …)説明用の例

どれにも一致しない

その都度確認

NOTE本文の allow / deny の設定例で判定した場合の例。git commit の行は説明用の例です。

私が実運用している settings.json 完全版（2026年5月時点）

参考までに、私がグローバル（~/.claude/settings.json）で実際に使っている設定の骨子を貼っておきます。

個別allowを積み上げる方式ではなく、「Bash(*)で広く許可して、危険操作だけdenyで完全に塞ぐ」という割り切り方です。

承認回数を最小化したい人向けの構成なので、慎重派の人は前述の個別allow方式から始めるのをおすすめします。

{
  "permissions": {
    "allow": [
      "Bash(*)",
      "Read(*)", "Edit(*)", "Write(*)",
      "WebFetch(*)", "WebSearch"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(sudo:*)",
      "Bash(git push --force:*)",
      "Bash(git push -f:*)",
      "Bash(git reset --hard:*)",
      "Bash(chmod 777:*)",
      "Read(.env)"
    ]
  },
  "hooks": {
    "Stop": [{
      "hooks": [{ "type": "command",
        "command": "~/.claude/hooks/notify.sh stop", "timeout": 5 }]
    }],
    "PermissionRequest": [{
      "hooks": [{ "type": "command",
        "command": "~/.claude/hooks/notify.sh permission", "timeout": 5 }]
    }]
  }
}

ポイントは2つ。

1つ目はBash(*)で全許可した上で、rm -rf・sudo・git push --force・chmod 777などの「事故ったら戻せない操作」だけをdenyで完全ブロックしていること。

2つ目は通知をHooksのnotify.shに集約して、StopとPermissionRequestで別の通知音を鳴らし分けていることです。

これを入れる前は1日に承認ボタンを100回以上押していましたが、入れてからは10回前後まで減りました。

CLAUDE.md で"プロジェクトの記憶"を作る3つのコツ

CLAUDE.mdはプロジェクトの記憶領域です。AIが起動時に必ず読み込むので、ここに書くべきは「毎回伝えたい前提」だけ。

長文マニュアルを丸投げすると逆効果で、ノイズが増えてAIの精度が落ちます。要点を絞って書くのがコツです。

最初は手書きで小さく始める

/initコマンドで自動生成もできますが、私はおすすめしません。生成物は冗長で、自分でも読み返さなくなるからです。最初は10〜20行の手書きで十分。

「言語」「主要ディレクトリ」「禁止事項」だけ書いて運用を始めると、必要な情報だけが残ります。

階層構造（ルート→サブ）で責務を分ける

モノレポや大規模プロジェクトでは、ルートのCLAUDE.mdに全体方針を書き、サブディレクトリにそれぞれのCLAUDE.mdを置きます。

フロントとバックで規約が違うようなケースで効きます。

起動時に読み込まれるのは作業ディレクトリから上の階層のCLAUDE.mdで、サブディレクトリのCLAUDE.mdはClaudeがそのディレクトリのファイルを読んだときに追加で読み込まれます（2026年10月時点の公式ドキュメント）。そのため、作業対象に応じて自然とコンテキストが切り替わります。

コーディング規約とNG行動を明示する

「テストは必ず書く」「console.logを残さない」「未使用importは削除」のようなNGルールは、肯定形より否定形のほうが守られやすい印象です。

曖昧な「丁寧に書く」より、具体的に「やってほしくないこと」を列挙するのが効きます。

私が使っている CLAUDE.md の実例（17行版）

「短く始める」と言われても具体例が無いとイメージしづらいので、私が個人開発リポジトリで実際に使っている17行のCLAUDE.mdを公開しておきます。

# プロジェクト概要
個人用の自動化スクリプト集。Python + シェル + macOS launchd。

## アーキテクチャ
- python/common/ — 共通モジュール（ロギング、HTTP、Slack通知）
- python/browser_automation/ — Playwright自動化群（共有venv）
- python/wp_manager/ — WordPress管理・SEO分析

## 行動原則
- 新規スクリプトは python/common/ の共通モジュールを使う
- .env / config.json / credentials.json はコミットしない
- 依存管理は uv（pyproject.toml + uv.lock）

## NG
- console.log や print を本番コードに残さない
- TODO コメントを放置しない
- 関数1つ100行を超えない

この17行で「使い回せる土台」になります。最初からこれ以上書こうとすると挫折するので、運用しながら必要なものだけ追記する方針が長持ちします。

作業効率が跳ね上がる Hooks のおすすめ活用法

HooksはClaude Codeの動作に「割り込み」を仕掛ける機能です。

ツール実行の前後にシェルコマンドを差し込めるので、自動lint・通知・ログ取得など"地味だけど効く"自動化が組めます。

私はこれを入れてからAIの作業を放置できるようになりました。

PostToolUse で自動 lint / format を走らせる

ファイル編集後に自動でlintを走らせると、AIが書いたコードのスタイル崩れを次のターンで本人に直させられます。

フィードバックループが短くなり、結果的にコードがどんどん綺麗になります。

Hookコマンドは標準入力でJSONを受け取るので、編集対象パスはtool_input.file_pathから取り出します。

"hooks": {
  "PostToolUse": [{
    "matcher": "Edit|Write",
    "hooks": [{
      "type": "command",
      "command": "jq -r '.tool_input.file_path' | xargs -I{} npx prettier --write {} 2>/dev/null || true"
    }]
  }]
}

Stop フックで完了通知音を鳴らす

長時間タスクを投げて別作業をしていると、終わったことに気づかないんですよね。Stopフックで通知音を鳴らせば一発解決。

macOSならafplay /System/Library/Sounds/Glass.aiffを叩くだけで済みます。

Notification フックで承認待ちを見逃さない

Notification フックを使うと、AIが承認待ちで止まっているのに気づかないパターンも防げます。

Notificationフックで別の音を鳴らすか、Slack DMに飛ばすのが個人的なベスト。Stop音と区別できる音にするのがポイントです。

"Notification": [{
  "hooks": [{
    "type": "command",
    "command": "curl -X POST -H 'Content-type: application/json' --data \"{\\\"text\\\":\\\"Claude Codeが承認待ちです\\\"}\" $SLACK_WEBHOOK_URL"
  }]
}]

私はSlack Webhookを$SLACK_WEBHOOK_URL環境変数に入れておいて、別作業中でもスマホ通知で気づけるようにしています。

10分以上放置していた承認待ちが、長くて1分で気づけるようになりました。

Skills とカスタムコマンドのおすすめ設定｜定型作業を1コマンド化

同じ作業を3回以上繰り返したら、Skillsかカスタムコマンドに切り出すべきです。

プロンプトをファイル化しておけば、次回からは1コマンドで呼べる上に、内容の改善も差分管理できます。

Skills とは何か（slash command との違い）

Skillsは「条件に応じて自動的に発動する専門知識パック」、slash commandは「ユーザーが明示的に呼び出すレシピ」です。

Skillsは説明文をAIが読んで適切なタイミングで自分から起動するので、毎回呼ばなくていい強みがあります。

Skillsは~/.claude/skills/<name>/SKILL.md（個人用）や.claude/skills/<name>/SKILL.md（プロジェクト用）のディレクトリ構造で配布・共有でき、メタ情報をfrontmatterに書くことでAIが自動選択します。

なお2026年10月時点の公式ドキュメントでは、カスタムコマンドはSkillsに統合されています。.claude/skills/deploy/SKILL.mdも.claude/commands/deploy.mdも同じ/deployとして呼び出せ、既存の.claude/commands/のファイルもそのまま動きます。

私が実際に使っているおすすめ Skill 3つ

code-reviewer：PR前のレビュー観点チェック。可読性・セキュリティ・パフォーマンスを自動で見てくれる
bug-fixer：エラーメッセージを貼ると原因と修正案を出すまで自動進行する
handoff-memo：会話を次のチャットで再開できる引き継ぎメモに整形する

この3つを導入してから、PRレビューの自前チェックに使っていた時間が週2〜3時間ほど減りました。

bug-fixerはエラー文を貼るだけで原因切り分けが進むので、特にデバッグ時間が顕著に短縮されています。

MCP サーバーで外部ツールと接続する

MCP（Model Context Protocol）はClaude Codeと外部サービスを繋ぐ橋です。

GitHub・Slack・Notion・Google Drive・Gmail・Google Calendarなどに繋げば、AIがチケット起票やドキュメント更新、メール下書き、予定確認まで一気通貫でやってくれます。2026年10月時点では、Anthropic Directory（claude.ai/directory）に掲載されたリモートMCPサーバーもclaude mcp addで追加できます。

コーディング以外の雑務が減るのが本当の価値です。

GitHub・Slack・Notion を繋ぐ手順

導入はclaude mcp addコマンド1発で済みます。GitHubならIssue一覧取得・PR作成までAIから直接実行可能。

Slackは通知ボット、Notionはドキュメント検索の窓口として使うと便利です。

MCP導入で気をつけたい権限の落とし穴

ただしMCPは外部APIにトークンを渡すので、権限スコープは必ず最小化します。

GitHubのfine-grained tokenでリポジトリを限定する、Slackは投稿先チャンネルを絞る、など読み書き範囲を制限するのが鉄則。

「全権付きトークン」は事故のもとです。

statusline・model・output style のおすすめ追加設定

前述の5要素に加えて、知っておくと体験が一段階上がる細かい設定があります。必須ではありませんが、長く使うなら入れておくと差が出ます。

statusline でコンテキスト残量を可視化する

settings.jsonのstatusLineにシェルコマンドを設定すると、ターミナル下部に常時情報を出せます。

私はGitブランチとコンテキスト消費率を出していて、長いセッションで「そろそろ /compact しよう」の判断が早くなりました。

model 設定で Opus / Sonnet / Haiku を使い分ける

難易度の高い設計タスクはOpus、ルーチン作業はSonnet、軽い検索はHaikuと、settings.jsonのmodelキーで既定モデルを切り替えられます。

プロジェクト単位で.claude/settings.jsonに書き分けると、コスト対効果のバランスが取りやすくなります。

output style で口調・出力フォーマットを揃える

output styleはAIの返答スタイルを定義するレシピです。「コードのみ返す」「日本語で簡潔に」など、プロジェクトごとの好みを固定化できます。

チームで使うなら統一しておくと、誰が動かしても出力が揃って便利です。

/config コマンドで触っておきたいおすすめ設定

settings.jsonを直接いじるのが正攻法ですが、テーマや通知などの体験まわりは/configコマンドの対話メニューで設定するほうが早いです。

Claude Codeを起動した状態で/configと打てば、現在の設定一覧と変更可能な項目がその場で表示されます。

Theme｜ターミナル背景に合わせて視認性を上げる

最初に変えるべきはThemeです。デフォルトのままだと差分の追加/削除色がターミナル背景と喧嘩してコードが読みづらいことがあります。

dark／lightに加えて、色覚多様性に配慮したテーマも用意されています（具体的な選択肢は/configのメニューで確認できます）。

長時間見ても疲れにくいものを選んでおくとレビュー速度が上がります。

Notifications｜承認待ちと完了通知を必ずONに

通知系（2026年10月時点の/config上の表示名はLocal notifications、設定キーはpreferredNotifChannel）は必ず有効にします。

Hooksで自前の通知音を鳴らしていない人は、ここの設定だけでも「承認待ち放置」を大幅に減らせます。

既定のautoでデスクトップ通知が出るのはiTerm2・Ghostty・Kittyです。それ以外のターミナルを使っている人はterminal_bell（ベル音）を、iTerm2なら通知とベルの両方を鳴らすiterm2_with_bellを選んでおくのがおすすめ。

バックグラウンドで他作業中でも気付けます。

Default Model｜プロジェクト規模で Opus / Sonnet を切替

既定モデルは/modelで切り替えるのが一番手軽です。2026年10月時点では、/modelのピッカーでEnterを押すとユーザー設定のmodelに保存されて次のセッションからの既定になり、sキーならそのセッションだけ切り替わります。

設計タスクが多い日はOpus、定型作業中心の日はSonnetに変えるだけで、月額コスト体感が変わります。

プロジェクトごとに固定したい場合は前述の.claude/settings.jsonのmodelキーで上書きできるので、グローバルは「普段使い」の設定にしておくのが楽です。

Editor mode｜Vim派は迷わず vim に

プロンプト入力欄のキーバインドはEditor modeでnormal／vimを選べます。

Vim慣れしている人はvimに切り替えるだけで長文プロンプトの編集効率が体感2倍になります。ノーマルモードでddやciwが使えるのは地味に効きます。

Verbose output｜デバッグ時だけ一時的にON

VerboseはデフォルトOFFのままで構いませんが、Hooksやpermissionsの挙動が怪しい時に一時的にONにすると、内部のツール呼び出しが全部見えるようになります。

設定が効いていない原因切り分けが一気に早くなるので、トラブルシュート時の隠し玉として覚えておくと便利です。

ここで設定した内容は最終的に~/.claude/settings.jsonに保存されるので、/configでざっと整えてからJSONを開いて細かく追記する流れが、私の中での王道セットアップ手順です。

Claude Codeのおすすめ設定に関するよくある質問（FAQ）

最後に、設定まわりで読者からよく受ける質問をまとめます。

Q1. settings.json と CLAUDE.md はどう使い分ける？

A1. settings.jsonは「ハーネスの動作制御」、CLAUDE.mdは「AIへの指示・前提情報」です。permissionsやhooksのような構造化データはJSON、コーディング規約や思想はMarkdownに書く、と覚えればOKです。役割が違うので両方を併用します。

Q2. 設定はチームで共有すべき？

A2. はい、チーム共通のルールはGitに含めるのが正解です。.claude/settings.jsonとCLAUDE.mdはコミット、個人の好みやAPIキーはsettings.local.json（gitignore対象）に分けると、新メンバーのオンボーディングが一気に楽になります。

Q3. Auto-accept / bypass permissions モードは安全に使える？

A3. denyルールをきちんと整備した上であれば実用範囲です。Claude Codeでは --permission-mode acceptEdits や auto、bypassPermissions など複数の自動承認モードがあり、何も塞がずに有効化するのは危険です。

私は破壊的コマンドを全てdenyで塞いでから、サンドボックス的に使い始めるのを推奨しています【2026年10月時点】。

2026年10月時点の公式ドキュメントでは、bypassPermissionsはコンテナやVMのような隔離環境でだけ使うよう案内されています。また、/sandboxコマンドで有効にできる組み込みのサンドボックスもあり、macOSなら追加のインストールなしで使えます。

Q4. 設定をリセットしたい時はどうする？

A4. 該当するsettings.jsonを削除またはリネームすればデフォルトに戻ります。慎重に進めたい場合は、まず~/.claude/settings.json.bakのようにバックアップしてから消すのが安全。

グローバル・プロジェクト・ローカルどれが効いているか分からなくなったら、/configコマンドで現状を確認できます。

まとめ｜設定を"育てる"ことで Claude Code は別物になる

Claude CodeによるAI駆動開発入門 [ 平川知秀 ]

posted with カエレバ

楽天市場

Amazon

Yahooショッピング

Claude Codeのおすすめ設定を、2026年5月時点の私の実運用をベースに、2026年10月時点の公式ドキュメントで仕様を確認し直して紹介してきました。

最初から完璧に整える必要はなく、使いながら少しずつ育てていけば十分です。

Claude Code自体もアップデートが速いツールなので、半年に一度は本記事のような設定棚卸しをおすすめします。

permissions の allow / deny で承認ダイアログを9割減らす
CLAUDE.mdは手書きで小さく、階層構造で責務を分ける
Hooks で lint・通知を自動化して放置運用を可能にする
SkillsとMCPで雑務まで含めた一気通貫を作る

設定を整えた瞬間から、Claude Codeは"承認待ちアシスタント"から"自走する開発パートナー"に変わります。

まずはpermissionsだけでもいいので、今日触ってみてください。明日の作業速度がはっきり変わります。

REVISIONS ／ 改訂履歴

REV.	DATE	内容
4	2026-10-16	図解を描き直し（図面のデザインにそろえた）
3	2026-10-06	記載内容の事実確認と修正
2	2026-09-04	2026年9月時点の情報で全体を見直し
1	2026-05-03	初版