Claude Code作者が全公開！9種のカスタマイズ手段と設定の全貌

163

Last updated at 2026-02-25Posted at 2026-02-16

はじめに

Claude Codeをインストールして、そのまま使っていないだろうか。

本記事は2026年2月13日時点の情報に基づいています。

作者のBoris Cherny氏は、カスタマイズ性がClaude Codeの成長を加速させた要因の一つだと述べた。エンジニアは一人ひとり異なる開発スタイルを持っている。Claude Codeはその多様性に応えるために、9種類のカスタマイズ手段と37+の設定項目（Boris氏の投稿時点）をゼロから設計した。デフォルトのまま使っても十分に機能するが、自分のワークフローに合わせて育てると、日常の操作が目に見えて変わる。

Boris氏は、前回のスレッドで「Claude Codeチームの使い方」を公開した。そして今回、2本目のスレッドで公開されたのが「カスタマイズ機能の全貌」だ。前回が「使い方」なら、今回は「育て方」の話になる。

対象読者

Claude Codeを使い始めたが、デフォルト設定のまま使っている人
カスタマイズの存在は知っているが、何から手をつけるべきかわからない人
チームへのClaude Code導入を検討している人

1. カスタマイズの全体像：9つの軸

Claude Codeのカスタマイズは「設定を1つ変える」レベルではない。9つの独立した軸で、開発体験の全レイヤーを制御できる。

Boris氏はスレッドの冒頭で、Claude Codeが提供するカスタマイズ手段を以下のように列挙した。

#	カスタマイズ手段	概要	対象レイヤー
1	Effort	Low/Medium/Highの思考深度制御	応答品質
2	Plugins	マーケットプレイス経由の拡張パッケージ管理	機能拡張
3	LSPs	主要言語のLanguage Server Protocol連携	コード解析
4	MCPs	Model Context Protocolによる外部ツール接続	外部連携
5	Skills	タスク自動化のためのスキル定義	自動化
6	Custom Agents	専門特化AIエージェントの定義	エージェント
7	Hooks	ライフサイクルイベントへの決定論的介入	ワークフロー
8	Status Lines	コンポーザー下の情報バー	UI表示
9	Output Styles	応答のトーン・フォーマット調整	出力形式

※ Plugins（#2）はLSP・MCP・Skills等を含む配布・管理の仕組みであり、#3〜#5はPluginsを通じてインストールすることもできるが、それぞれ独立したカスタマイズ手段としても機能する。

これらは互いに独立しており、必要なものだけを段階的に導入できる。すべてを一度に設定する必要はない。Boris氏のスレッドも、簡単なものから高度なものへと順に紹介する構成になっていた。

2. 設定の基盤：4スコープと37+設定項目

カスタマイズを始める前に押さえておくべきなのが、Claude Codeの設定システムだ。ここを理解していないと、「設定したのに反映されない」「チームメンバーと設定が違う」といった問題に悩まされることになる。

4つの設定スコープ

Claude Codeの設定には4つのスコープがある。Boris氏は「コードベース全体、サブフォルダ、個人、エンタープライズポリシー」と概念的に説明したが、公式ドキュメントでは以下の名称が使われている。

スコープ	配置場所	用途	git管理
Managed	システムディレクトリ	エンタープライズポリシー	IT/DevOps管理
User	`~/.claude/settings.json`	個人の全プロジェクト共通設定	対象外
Project	`.claude/settings.json`	チーム共有のプロジェクト設定	チェックイン推奨
Local	`.claude/settings.local.json`	個人のプロジェクト固有設定	gitignore

設定の優先順位は以下の通りだ。

Managed > CLI引数 > Local > Project > User

Managed（エンタープライズ）が最高優先度で上書き不可。個人開発であればUserとProjectの2つを使い分けることになる。Localは「チームの標準設定（Project）を個人的に上書きしたい」ときに使う。

37+設定項目と84環境変数

Boris氏はスレッドのまとめで「37の設定項目と84の環境変数をサポートしている」と述べた（※いずれもBoris氏の投稿時点での数値。公式ドキュメントでは環境変数は80+と記載されており、設定項目数も更新に伴い増減する）。さらに「Pick a behavior, and it is likely that you can configure it（挙動を選べ。おそらくそれは設定可能だ）」とも言っている。最新の正確な数値は公式ドキュメントを参照してほしい。

settings.jsonのgit管理

Boris氏が強く推奨しているのが、.claude/settings.jsonをgitにチェックインすることだ。これにより、チームメンバーがリポジトリをクローンした時点で、パーミッション設定、プラグイン構成、エフォートレベルなどが自動的に適用される。「新メンバーが入ってきたら設定を手動で共有する」という手間がなくなる。

さらに、settings.jsonのenvフィールドを使えば、ラッパースクリプトなしで環境変数を設定できる。CI/CDパイプラインとの連携もスムーズになる。

3. ターミナル環境を整える

カスタマイズの最初の一歩は、ターミナル環境の調整だ。毎日何時間も向き合う画面だからこそ、小さな設定の違いが大きなストレス軽減につながる。

Boris氏はターミナル設定を4つのカテゴリに分けて紹介した。

テーマとVimモード

/config コマンドでライトモードとダークモードを切り替えられる。また、Vimキーバインドを好む開発者は /vim コマンドで有効化できる。

改行入力の設定

IDE内ターミナル、Apple Terminal、Warp、Alacrittyを使っている場合は、/terminal-setup を実行しておくべきだ。これにより、Shift+Enterで改行を入力できるようになる。バックスラッシュ \ を毎回打つ必要がなくなり、複数行のプロンプト入力が格段に快適になる。

通知の設定

長時間のタスクを実行する際に便利なのが通知設定だ。iTerm2ユーザーはターミナル内蔵の通知機能を有効化でき、それ以外の環境ではカスタムhookで通知を実装できる。

これらの設定はすべて公式ドキュメント（https://code.claude.com/docs/en/terminal-config )に詳しく記載されている。まだターミナル設定を触ったことがなければ、まずは /terminal-setup と /config の2つを実行するところから始めてみてほしい。

4. エフォートレベル：思考の深さを制御する

最も手軽で、最も効果を実感しやすいカスタマイズがエフォートレベルだ。1つのコマンドで、Claudeの「考える深さ」を3段階に切り替えられる。

3段階の使い分け

/model コマンドを実行すると、エフォートレベルを選択できる。

レベル	トークン消費	応答速度	適した用途
Low	少ない	速い	単純なリネーム、フォーマット修正、定型的な変更
Medium	中程度	中程度	一般的なコーディング、バグ修正
High	多い	遅い	アーキテクチャ設計、複雑なリファクタリング、新機能実装

トークン消費量と応答速度はトレードオフの関係にある。Lowは即座に返ってくるが思考が浅く、Highは時間がかかるが深い推論を行う。

Boris氏の推奨

Boris氏の設定は明快だ。「自分は全てにHighを使用している」。コスト効率よりも出力品質を重視する姿勢が表れている。筆者も同じくHighを常用しているが、単純なファイル操作やフォーマット修正など、深い思考が不要な場面ではLowに切り替えることでトークンを節約する使い方も有効だ。

注意点

Highはトークン消費が増えるため、コストとのバランスを考慮する必要がある。特にAPIキーで利用している場合は、タスクの複雑さに応じてレベルを切り替えるのが経済的だ。

始め方

/model

5. プラグイン、MCP、スキル：外部連携の3つの仕組み

Claude Codeの拡張性を支えるのが、プラグイン、MCP、スキルだ。これらを組み合わせると、外部ツールとの連携やタスクの自動化が実現し、Claude Codeの守備範囲が大きく広がる。

プラグインシステム

/plugin コマンドで、Anthropic公式マーケットプレイスからプラグインをインストールできる。プラグインが提供する機能は幅広い。

LSP（Language Server Protocol）：すべての主要プログラミング言語に対応した言語サーバー連携。コード補完、型チェック、リファクタリング支援が強化される
MCP（Model Context Protocol）：外部ツールとの接続。データベース、API、ファイルシステムなどの外部リソースにClaudeがアクセスできるようになる
スキル：タスク自動化の定義。繰り返し行う作業をスキルとして定義し、再利用できる
エージェント：専門特化したAIエージェントのインストール
カスタムフック：イベント駆動の処理をパッケージとして配布

企業向けマーケットプレイス

Boris氏が紹介した注目すべき機能として、企業が独自のマーケットプレイスを構築できる点がある。社内ツールやカスタムプラグインを自社マーケットプレイスで配布し、settings.jsonをチェックインしておけば、チームメンバーに自動的にマーケットプレイスが追加される。オンボーディングの手間を大幅に削減できる仕組みだ。

Boris氏の推奨

Boris氏はsettings.jsonをgitにチェックインし、プラグイン構成をチーム全体で共有することを推奨している。特に企業向けマーケットプレイスとの組み合わせにより、新メンバーのオンボーディングコストを大幅に削減できると述べた。

注意点

サードパーティプラグインの安定性は開発者に依存するため、本番環境に導入する前に信頼性を確認することを推奨する。公式マーケットプレイスのレビューやGitHubリポジトリのメンテナンス状況を確認するとよい。

始め方

/plugin

6. カスタムエージェント：専門AIを定義する

カスタムエージェントは、Claude Codeの中に「専門家チーム」を構築する機能だ。コードレビュー専門、テスト専門、ドキュメント生成専門など、用途に特化したエージェントを定義できる。

エージェントの作成方法

.claude/agents/ ディレクトリにMarkdownファイルを配置するだけでよい。たとえばコードレビュー専門のエージェントを作る場合、.claude/agents/code-reviewer.md というファイルを作成する。

エージェントファイルでは以下の属性をカスタマイズできる。

エージェント名
表示カラー
使用可能なツールセット
事前許可・事前不許可ツール
パーミッションモード
使用するモデル

エージェントの起動方法

作成したエージェントは2つの方法で起動できる。

# CLI起動時にフラグで指定
claude --agent code-reviewer

# 会話中にコマンドで一覧を確認
/agents

あまり知られていないデフォルト設定

Boris氏が「あまり知られていない機能」として紹介したのが、settings.jsonのagentフィールドだ。ここにエージェント名を指定すると、Claude Code起動時のデフォルトエージェントを変更できる。毎回 --agent フラグを付ける手間が省ける。

チームで共通のエージェント定義を .claude/agents/ に配置し、gitにチェックインしておけば、チーム全員が同じ専門エージェントを利用できる。公式ドキュメント（https://code.claude.com/docs/en/sub-agents ）で詳細な書式を確認してほしい。

Boris氏の推奨

Boris氏はデフォルトエージェントの設定（settings.jsonのagentフィールド）を活用し、プロジェクトごとに最適なエージェントが自動的に起動する環境を構築することを推奨している。

注意点

エージェント定義が複雑すぎるとコンテキストを圧迫する場合がある。エージェントのシステムプロンプトは簡潔に保ち、必要最小限の指示に絞ることが重要だ。

始め方

claude --agent code-reviewer

7. パーミッションとサンドボックス：安全にカスタマイズする

カスタマイズの自由度が高いほど、セキュリティへの配慮が重要になる。Claude Codeは4層の防御構造でこの課題に対応している。

4層防御のアーキテクチャ

Boris氏が解説したパーミッションシステムは、以下の4層で構成される。

プロンプトインジェクション検出：悪意ある入力パターンを自動検出し、実行前にブロックする
静的解析：コマンド実行前にコードを分析し、危険な操作を事前に検知する
サンドボックス：隔離された実行環境で、意図しないファイル操作やネットワークアクセスを防止する
人間による監視（Human Oversight）：最終的に人間が確認・承認する仕組み

この4層構造により、「便利だけど怖い」ではなく「便利で安全」な自動化が実現する。

パーミッションの事前設定

/permissions コマンドで、許可リストとブロックリストを設定できる。ワイルドカード構文をサポートしており、柔軟なルール定義が可能だ。

{
  "permissions": {
    "allow": [
      "Bash(bun run *)",
      "Edit(/docs/**)",
      "Bash(npm test *)"
    ],
    "deny": [
      "Bash(rm -rf *)"
    ]
  }
}

"Bash(bun run *)" は「bun runで始まるすべてのコマンドを許可」を意味する。"Edit(/docs/**)" は「プロジェクト内の/docs配下のすべてのファイル編集を許可」だ。これらを settings.json にチェックインしておけば、チーム全体で統一されたパーミッションポリシーを維持できる。

サンドボックスランタイム

Claude Codeのサンドボックスは、Anthropicがオープンソースで公開しているランタイム（sandbox-runtime）で動作する。公式ドキュメントによると、macOSではsandbox-exec、Linuxではbubblewrapを使用し、コンテナなしで軽量なサンドボックスを実現している。

/sandbox コマンドで有効化すると、ファイル分離とネットワーク分離の両方が適用される。サンドボックスが有効な状態では権限プロンプトの表示回数が減るため、自動化の快適さが向上する。安全性と利便性が両立する設計だ。Windows対応はBoris氏の投稿時点で近日予定とされていた。

前回の記事で触れた --dangerously-skip-permissions フラグは、この4層防御をすべてバイパスするため非推奨だ。サンドボックスとパーミッション設定を適切に構成すれば、権限プロンプトの煩わしさは十分に軽減できる。

Boris氏の推奨

Boris氏はパーミッション設定をsettings.jsonにチェックインし、チーム全体で統一されたセキュリティポリシーを維持することを強く推奨している。--dangerously-skip-permissionsの代わりにサンドボックスを活用すべきだと繰り返し述べている。

始め方

/permissions

8. ステータスラインとキーバインド：UIをカスタマイズする

開発中に目にするUIをパーソナライズすることで、日常的な作業の快適さが変わる。ステータスラインとキーバインドは、その「毎日触れる部分」のカスタマイズだ。

ステータスライン

ステータスラインは、コンポーザーの直下に表示されるカスタム情報バーだ。モデル名、カレントディレクトリ、残りコンテキスト、コストなど、作業中に確認したい情報を自由に表示できる。

導入は /statusline コマンドを実行するだけでよい。Claudeが .bashrc や .zshrc を読み取り、ユーザーの環境に合わせたステータスラインを自動生成してくれる。自分でゼロから設定を書く必要はない。

キーバインド

Claude Codeのすべてのキーバインドはカスタマイズ可能だ。/keybindings コマンドで任意のキーを再マッピングでき、設定はライブリロードされるため即座に反映を確認できる。変更を保存して再起動する必要がない。

公式ドキュメント（https://code.claude.com/docs/en/statusline ）でステータスラインの詳細な設定オプションを確認できる。

Boris氏の推奨

Boris氏は「Claude Codeチームのメンバーはそれぞれ異なるステータスラインを使用している」と述べ、正解は一つではないと強調した。自分が作業中に「今これが見えたら便利だ」と思う情報を表示させるのが正しい使い方だ。

始め方

/statusline

9. Hooks：ライフサイクルに決定論的に介入する

Hooksは、Claude Codeのカスタマイズの中で最も強力な機能の一つだ。Claudeのライフサイクルイベント（ツール呼び出し、ターン終了、パーミッションリクエストなど）に、決定論的なコマンドを紐付けられる。「決定論的」とは、AIの判断に頼らず確実に実行されるという意味だ。

Hooksでできること

Boris氏が紹介したユースケースは以下の通りだ。

パーミッションリクエストのルーティング：パーミッション要求をSlackやOpusに自動転送する。チームリーダーが離席中でも承認フローが止まらない
ターン終了時の継続制御：Claudeのターン終了時に継続を促し、長時間タスクを中断なく進める
ツールコールの前後処理：ファイル編集後にprettierを自動実行する、独自ログを追加するなど

導入方法

Boris氏が推奨する導入フローは驚くほどシンプルだ。「Claudeにhookの追加を依頼する」だけでよい。たとえば「ファイル編集後にprettierを自動実行するhookを追加して」と伝えれば、Claudeが settings.json にhook設定を書き込んでくれる。

Hooksはsettings.jsonで管理されるため、gitチェックインによるチーム共有も可能だ。チーム全体のコーディング規約（フォーマッタの自動実行など）をHooksで強制する、といった使い方が特に有効だろう。

Boris氏の推奨

Boris氏はHooksの導入方法として「Claudeにhookの追加を依頼する」というアプローチを推奨している。自分で設定を書くのではなく、Claudeに自然言語で指示するだけで適切なhook設定が生成される。

注意点

設定ミスはサイレントに失敗する場合があるため、デバッグ時はログ出力を活用することを推奨する。hookが期待通りに動作しない場合は、まずsettings.jsonのhook定義を確認し、コマンドが正しく記述されているかを検証するとよい。

始め方

「ファイル編集後にprettierを自動実行するhookを追加して」とClaudeに依頼

10. スピナー動詞とOutput Styles：体験を仕上げる

最後に紹介するのは、出力の「見た目」と「トーン」を調整するカスタマイズだ。機能的な変化は小さいが、毎日使うツールだからこそ、スピナーの表示一つ、応答のトーン一つで作業のテンポが変わる。

スピナー動詞のカスタマイズ

Claudeが処理中に表示するスピナー（「Thinking...」「Analyzing...」のような動詞表示）は、settings.jsonでカスタマイズできる。デフォルトの動詞リストに追加したり、完全に置き換えたりできる。

設定方法はClaudeに「スピナー動詞をカスタマイズして」と依頼するだけだ。チーム固有のユーモアを込めた動詞を設定しているチームもある。settings.jsonにチェックインすれば、チーム全体で同じスピナー表示を共有できる。

Output Styles

Output Stylesは、Claudeの応答トーンとフォーマットを調整する機能だ。/config コマンドから設定する。単なる見た目の変更ではなく、Claudeの作業アプローチ自体が変化する点が重要だ。

Boris氏が特に推奨している2つのスタイルがある。

explanatoryは、新しいコードベースに慣れる際に威力を発揮する。Claudeがフレームワークやコードパターンを説明しながら作業を進めてくれるため、コードを書いてもらいながら同時にコードベースの理解が深まる。新しいプロジェクトに参加した最初の数日間に特に有効だ。

learningは、コーチングモードとも言えるスタイルだ。Claudeがコード変更の方法を教えてくれる形式で応答する。ジュニアエンジニアの学習支援や、自分が不慣れな言語やフレームワークを扱う際に役立つ。

さらに、カスタムスタイルを独自に作成することも可能だ。公式ドキュメント（https://code.claude.com/docs/en/output-styles ）で詳細を確認してほしい。

Boris氏の推奨

Boris氏はexplanatoryスタイルとlearningスタイルを特に推奨している。新しいコードベースに慣れる際はexplanatory、スキルアップの場面ではlearningと、状況に応じた切り替えが効果的だと述べた。

始め方

/config

11. 実践ロードマップ：今日から始めるカスタマイズ

9つのカスタマイズ手段を一度に導入する必要はない。段階的に進めることで、各設定の効果を実感しながらステップアップできる。

Day 1（初心者）：まず体感する

最初の日は、設定ファイルを触らずにすぐ効果が出る3つから始める。

/terminal-setupを実行する。Shift+Enterで改行入力が有効になる
/modelでエフォートレベルをHighに設定する。Boris氏と同じ設定で、Claudeの応答品質が上がる
/configでOutput Stylesを試す。explanatoryスタイルを選んで、Claudeの応答がどう変わるか体感してみてほしい

この3つだけで、Claude Codeの使い心地が明確に変わるはずだ。

Week 1（基本設定）：設定基盤を整える

1週間かけて、設定の基盤を構築する。

settings.jsonの4スコープを整備する。User設定に個人の共通設定を、Project設定にチーム共有設定を配置する
/permissionsで頻繁に使うコマンドを事前許可し、権限プロンプトの頻度を下げる
CLAUDE.mdにプロジェクトの規約、よく使うコマンド、避けるべきパターンを記載する

Month 1（本格活用）：高度なカスタマイズに進む

基本設定が安定したら、より高度なカスタマイズに着手する。

.claude/agents/ にコードレビュー専門やテスト専門のエージェントを作成する
Claudeにhookの追加を依頼し、フォーマッタの自動実行やカスタムログの追加を設定する
/pluginで必要なプラグインをインストールし、外部ツールとの連携を構築する

まとめ

Claude Codeは「そのまま使っても機能する」ツールだ。だが、Boris Cherny氏が今回のスレッドで示したように、9つのカスタマイズ軸を活用することで、Claude Codeは「自分だけの開発環境」へと変わっていく。

9つの軸と、それぞれの入り口を一覧にしておく。

カスタマイズ手段	まず試すなら
Hooks	「フォーマッタの自動実行hook追加して」とClaudeに依頼
Plugins	`/plugin`で公式マーケットプレイスを閲覧
LSPs	自分の主要言語のLSPプラグインをインストール
MCPs	使用中の外部ツールのMCP連携を検索
Skills	繰り返しタスクをスキルとして定義
Effort	`/model`でHighに設定
Custom Agents	`.claude/agents/`に1つ作ってみる
Status Lines	`/statusline`を実行
Output Styles	`/config`でexplanatoryを試す

Boris氏の設計思想は一貫している。「優れたデフォルト設定と高いカスタマイズ性の両立」だ。デフォルトで十分に機能するから、カスタマイズは強制ではなく選択として提供される。だからこそ、自分のペースで、自分に必要なものだけを段階的に導入できる。

前回の記事では「Claude Codeの使い方」を、今回は「Claude Codeの育て方」を解説した。この2つがそろえば、あとは自分のプロジェクトで試すだけだ。Day 1の3ステップから始めてみてほしい。

参考リンク

163

199

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up