はじめに

Claude Code を使い始めて数ヶ月、便利だなと思いつつも「同じ指示を何度も書いてないか？」「無駄な前置きを毎回読まされてないか？」と感じる場面が増えてきました。

AI に作業を任せるのは便利ですが、AI を使うこと自体に発生するタイムロスに目を向けると、まだまだ効率化の余地があると気づきました。

この記事では、Claude Code を触り始めたエンジニア向けに、私が実際にやってみて効果が高かった「個人ルールの設定」をまとめます。難しい設定はなく、ファイルに数行追記するだけで作業効率がはっきり変わるものを紹介します。

読み終わるころには、自分の CLAUDE.md に何を書けば良いかのイメージが掴めるはずです。

基礎となる知識

CLAUDE.md とは

Claude Code には、起動時に自動で読み込まれる CLAUDE.md というファイルがあります。ここにルールを書いておくと、毎回プロンプトに含めなくても Claude が従ってくれます。

CLAUDE.md には大きく分けて 2 種類あります。

プロジェクト用は他のメンバーにも影響するので、チーム共通のルールを書きます。一方、個人用は自分専用なので、自分の作業スタイルに合わせて自由に書けます。

今回フォーカスするのは個人用のほうです。

良いルールの条件

CLAUDE.md に書くルールには、効果の高いものとそうでないものがあります。経験上、効果が高いルールには 2 つの共通点があります。

• 短い - 長文のルールは読み飛ばされやすく、Claude のコンテキストも圧迫する
• 多くの動作に関与する - 特定の場面でしか効かないルールより、毎回のセッションで効くルールのほうが恩恵が大きい

この 2 つを意識して、以下の設定を入れていきます。

効果が高かった設定

1. 回答スタイル

## 回答スタイル
- 挨拶・前置き・段階報告・絵文字禁止。結論ファースト
- 指摘すべきことは率直に指摘

これが個人的に一番効果を実感した設定です。

デフォルトの Claude は「承知しました！それでは～」のような前置きや、「素晴らしい質問ですね」といった社交辞令を返してきがちです。一度や二度なら気にならないですが、1 日に何十回もやり取りしていると地味にトークンと時間を消費します。

このルールを書いておくだけで、

• 無駄なトークンが減る（=コスト削減）
• 出力が読みやすくなる
• 必要な情報にすぐアクセスできる

という 3 つの効果が一気に得られます。全セッションで効くので投資対効果が非常に高いです。

「率直に指摘」を入れているのは、Claude が過度に肯定的な反応を返してくることがあるからです。設計の問題点などを忖度なく指摘してほしい人にはおすすめです。

2. ブランチ管理

## ブランチ管理
- ブランチを切る前に develop ブランチで git pull origin develop を実行して最新化する
- サブモジュールがある場合は git submodule update --remote で最新化する
...

ブランチを切って作業を始めるとき、毎回「develop を最新化してから切って」と指示するのは面倒です。このルールを書いておくと、「ブランチを切って作業して」だけで必要な前処理を全部やってくれるようになります。

「プッシュはユーザーが明示的に指示した時のみ」も重要なポイントです。意図しないプッシュを防げるので、安全弁として効きます。

3. サブモジュール反映の手順

## 親リポジトリへのサブモジュール反映（動作確認用）
親リポジトリで動作確認したい場合は、以下のコマンドでサブモジュールをローカルパスから反映する。
git -C lib/shared pull /Users/ローカルパス {common のブランチ名}
...

私のプロジェクトではサブモジュール方式を採用しています。サブモジュール側で変更を加えたあと、親リポジトリで動作確認するには、サブモジュールに変更を反映する必要があります。

この手順、毎回 AI に伝えるのが地味に面倒なんですよね。コマンドをルール化しておくことで「動作確認したい」と一言伝えれば、Claude が正しい手順で反映してくれるようになりました。

プロジェクト固有の手順は、自分の CLAUDE.md に書いておくのがおすすめです。チームに共有するほどではないけれど、自分は毎回使うような Tips をためておく場所として最適です。

4. コード説明のルール

## コード説明のルール
### 指摘対応時
指摘内容の説明と妥当性の評価を行い、変更前の問題点・変更内容・変更後のコードの意図と内容を説明する。
...

実装判断の背景を確認したい場面が多く、Claude が書いたコードを見て「なぜこの書き方にしたんだろう？」と思うことがよくあります。

そのたびに質問するのは時間がかかるので、最初から意図を説明させるようにルール化しました。

これにより、

• コードを見ただけでは分からない設計判断の意図が分かる
• 「なぜこの実装にしたのか」を毎回聞き返す必要がなくなる
• 提案されたコードの妥当性を自分で判断しやすくなる

という効果がありました。とくにジュニア層には強くおすすめしたい設定です。

CLAUDE.md以外でやって効果があった設定

ルール設定とは別に、Claude Codeのsettings.json

をいじって効果があった設定も 2 つ紹介します。

ステータスラインのカスタマイズ

~/.claude/settings.json

の statusLine

フィールドを設定すると、CLI 上に現在の使用状態（モデル名・コンテキスト使用率・コストなど）を常時表示できます。

ブラウザでわざわざダッシュボードを開かなくてもトークン使用量が分かるので、

• 確認の手間が減る
• 常時見ることで「このプロンプトは無駄に長くないか？」というセルフフィードバックがかかる

という効果があります。

statusLine は「任意のコマンドの出力をステータスラインとして表示する」という公式機能です。コマンドには stdin 経由で JSON 形式の情報が渡ってきます。中身はこんな感じです。

{
"model": { "display_name": "Sonnet 4.6", ... },
"cost": {
...

これを jq

で加工して整形すれば、自分好みのステータスラインが作れます。今回はモデル名・git ブランチ・コンテキスト使用率・コストを表示するシェルスクリプトを作成しました。

セットアップ手順

1. シェルスクリプトを作成

~/.claude/statusline.sh

を以下の内容で作成します。

#!/bin/bash
# Custom statusline for Claude Code
# Reads JSON from stdin and outputs formatted status line.
...

2. 実行権限を付与

chmod +x ~/.claude/statusline.sh

3. settings.json に登録

~/.claude/settings.json

に以下を追加します。

{
"statusLine": {
"type": "command",
...

4. Claude Code を再起動

設定は新しいセッションから反映されます。一度 Claude Code を抜けて起動し直すと、画面下部に statusLine が表示されます。

表示される内容

こんな感じで表示されます。

コミュニティ製パッケージという選択肢

もっと多機能にしたい・対話的にカスタマイズしたいという場合は、コミュニティ製の npm パッケージ ccstatusline

を使う方法もあります。

npm install -g ccstatusline

{
"statusLine": {
"type": "command",
...

ターミナルで ccstatusline

を実行すると、表示項目を選ぶ対話 UI が起動します。Anthropic 公式ではないので、依存を増やしたくない場合は今回のシェルスクリプト方式がおすすめです。

ちなみに今回のスクリプトは Claude Code に書かせているのでカスタマイズも Claude Code を使用すれば個人の好きなように変更するのも容易です。

サードパーティ製のものを使うのが不安な方は Claude Code に私と同じように書かせるというのも手段の一つだと思います。（コピペでも良いですが、それだとあまり変わらない気もするので...）

6. 自動 Compaction の値変更

これは効果が大きかった設定です。

Claude Code では/context

コマンドでコンテキストの使用状況が確認できますが、コンテキストの空きが少なくなると出力精度が一気に落ちます。

それを防ぐには/compact

コマンドで定期的に圧縮する必要がありますが、毎回手動で打つのは面倒。そこで、.claude/settings.json

で自動 Compaction の閾値を設定できます。

{
"env": {
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "60"
...

デフォルトは 95% ですが、これを 60% に下げました。

デフォルトのままだと「もう終わった作業」と「今の作業」が混ざってしまい、Claude が混乱することが多かったのですが、60% に設定してからはそれがほぼなくなり、回答精度がかなり安定しました。

精度の劣化を実感している人は、同じように設定値を下げることをおすすめします。

やってみた結果

これらの設定を入れる前と後の体感としては以下の効果がありました。

• 同じ指示を繰り返さなくて済む→ ブランチ管理・動作確認手順をルール化することで、短い指示で同じ品質の作業ができる
• 読む量が減る→ 回答スタイルのルールで、応答が必要最小限になりストレスが減った
• 出力精度が安定する→ 自動 Compaction のしきい値を下げたことで、長いセッションでもブレが減った
• コードレビューが速くなる→ コード説明ルールで、なぜこう書いたかが先に説明されるので確認が速い

총체적으로 느낀 점은, 프로젝트 전체에 적용할 수준은 아니지만, 나는 매번 수행하는 작업을 CLAUDE.md 에 적어두는 것만으로도 평소 작업이 상당히 효율화된다는 것입니다.

AI 를 사용한 작업은 편리한 반면, AI 와의 대화 자체에 타임로스 (시간 손실) 가 발생합니다. 여기에 주목하면, 여전히 생산성을 높일 여지가 많습니다.

まとめ

이번에 소개한 설정을 정리합니다.

개인용 CLAUDE.md（ ~/.claude/CLAUDE.md）에 쓰는 것

• 답변 스타일 (전치 금지·결론 우선)
• 브랜치 관리 (develop 최신화·명시 지시에서만 push)
• 프로젝트 고유 절차 (서브모듈 반영 등)
• 코드 설명 규칙 (변경 의도를 매번 설명하게 함)

.claude/settings.json

에서 설정하는 것

• 상태 라인 커스터마이징
• 자동 Compaction 임계값 (83.5% → 60%)

모두「짧게 쓰는 것」「많은 세션에서 효과적」을 의식한 설정입니다. 각각은 몇 줄이지만, 매일 사용하는 것이므로 누적 효과가 큽니다.

이번에는 Claude Code 를 메인으로 설명했지만, 기초적인 설정에서도 한 번의 추가 작업으로 사용감이 크게 달라지거나, 어떤 경우에는 비용이나 품질에도 영향을 미칩니다. 캐치업 (Catch-up) 은 어렵지만, 안테나를 켜두는 것은 중요하다는 것을 다시 한번 실감했습니다.

여기서 소개한 것은 기초적인 설정이므로, 더 편리한 방법은 많을 것입니다. AI 를 단순히 사용하는 것이 아니라 올바르게 다루도록 하기 위해 앞으로도 캐치업을 계속해 나가고 싶습니다.