Claude Codeを使い始めた頃の私は、毎回の権限承認ダイアログに辟易していました。「ls 実行していい？」「grep していい？」と聞かれるたびに作業が止まり、正直「これ本当に効率化ツール？」と疑った時期すらあります。
結論から言うと、Claude Codeのおすすめ設定は「settings.json」「CLAUDE.md」「Hooks」「Skills」「MCP」の5要素を整えるだけです。特にsettings.jsonのpermissionsを正しく組むと、承認ダイアログが体感9割減って作業速度が3倍に変わります。
デフォルトのまま使うのは、ガチャで引いたばかりの初期キャラを丸腰で出撃させるようなものです。
この記事では、私が1年ほど業務と個人開発で使い倒してきた中で「これは入れたほうがいい」と確信している【2026年5月時点】のおすすめ設定を、コピペで使える実例つきでまとめました。設定迷子になっている人や、これから本格運用を始める人がそのままコピペで時短できる構成にしました。
最初の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のおすすめ設定はなぜ"効率を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キーや個人の好みはローカル、という分け方が安全です。
まず最初にやるべき settings.json のおすすめ設定
最優先で触るべきは permissions です。安全なコマンドはallow、危険な操作はdeny、それ以外はaskで確認、という3層構造で組むのが鉄則。これだけで承認ダイアログの数が9割近く減ります。
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つでテンポが変わります。
危険操作は 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)"
]私が実運用している 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を置きます。フロントとバックで規約が違うようなケースで効きます。
AIは作業対象に近いCLAUDE.mdを優先的に参照するので、自然とコンテキストが切り替わります。
コーディング規約と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が読んで適切なタイミングで自分から起動するので、毎回呼ばなくていい強みがあります。
2026年現在は~/.claude/skills/<name>/SKILL.md形式の標準ディレクトリ構造で配布・共有でき、メタ情報をfrontmatterに書くことでAIが自動選択します。
私が実際に使っているおすすめ 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年5月時点でMCP対応サービスは公式・サードパーティ含め急増中】。
コーディング以外の雑務が減るのが本当の価値です。
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に
通知系（Notification preferences）は必ずONにします。Hooksで自前の通知音を鳴らしていない人は、ここの設定だけでも「承認待ち放置」を大幅に減らせます。macOSならターミナルベルとシステム通知の両方を有効化しておくのがおすすめ。
バックグラウンドで他作業中でも気付けます。
Default Model｜プロジェクト規模で Opus / Sonnet を切替
Default modelは/configから切り替えるのが一番手軽です。設計タスクが多い日は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）
最後に、設定まわりで読者からよく受ける質問をまとめます。
settings.json と CLAUDE.md はどう使い分ける？
settings.jsonは「ハーネスの動作制御」、CLAUDE.mdは「AIへの指示・前提情報」です。permissionsやhooksのような構造化データはJSON、コーディング規約や思想はMarkdownに書く、と覚えればOKです。役割が違うので両方を併用します。
設定はチームで共有すべき？
はい、チーム共通のルールはGitに含めるのが正解です。.claude/settings.jsonとCLAUDE.mdはコミット、個人の好みやAPIキーはsettings.local.json（gitignore対象）に分けると、新メンバーのオンボーディングが一気に楽になります。
Auto-accept / bypass permissions モードは安全に使える？
denyルールをきちんと整備した上であれば実用範囲です。Claude Codeでは --permission-mode acceptEdits や bypassPermissions など複数の自動承認モードがあり、何も塞がずに有効化するのは危険です。
私は破壊的コマンドを全てdenyで塞いでから、サンドボックス的に使い始めるのを推奨しています【2026年5月時点】。
設定をリセットしたい時はどうする？
該当するsettings.jsonを削除またはリネームすればデフォルトに戻ります。慎重に進めたい場合は、まず~/.claude/settings.json.bakのようにバックアップしてから消すのが安全。
グローバル・プロジェクト・ローカルどれが効いているか分からなくなったら、/configコマンドで現状を確認できます。
まとめ｜設定を"育てる"ことで Claude Code は別物になる
Claude Codeのおすすめ設定を、2026年5月時点の私の実運用ベースで紹介してきました。最初から完璧に整える必要はなく、使いながら少しずつ育てていけば十分です。Claude Code自体もアップデートが速いツールなので、半年に一度は本記事のような設定棚卸しをおすすめします。
- permissions の allow / deny で承認ダイアログを9割減らす
- CLAUDE.mdは手書きで小さく、階層構造で責務を分ける
- Hooks で lint・通知を自動化して放置運用を可能にする
- SkillsとMCPで雑務まで含めた一気通貫を作る
設定を整えた瞬間から、Claude Codeは"承認待ちアシスタント"から"自走する開発パートナー"に変わります。まずはpermissionsだけでもいいので、今日触ってみてください。明日の作業速度がはっきり変わります。
