Claude Codeを使いこなす10のTips——CLAUDE.md設計からCI/CD連携まで実践テクニック集

Claude Codeを使いこなす10のTips——CLAUDE.md設計からCI/CD連携まで実践テクニック集

「とりあえず動かしてみた」段階から「チームで本番運用できる」段階に上げるための実践テクニックをまとめた。HackerNewsや国内エンジニアブログで話題になっているものを中心に紹介する。

概要

Claude Code は導入のハードルが下がっているぶん、「なんとなく使ってる」状態の人も多い。このTips集では、以下のような問いへの答えを実例とともにまとめている:

• チームで使うとき「毎回同じ説明」をしなくて済むようにするには?
• 長いセッションでClaudeが迷子になったときの対処は?
• CI/CDパイプラインにどう組み込む?

Tip 1: CLAUDE.md でプロジェクトの文脈を定義する

プロジェクトルートに CLAUDE.md を置くと、Claude Code が起動時に自動で読み込む。コーディング規約・ディレクトリ構成・よく使うコマンドなどをここに書いておくと、毎回「このプロジェクトは〜」と説明しなくてよくなる。

# このプロジェクトについて
- TypeScript + Next.js 15
- テストは Vitest、`npm test` で実行
- コミット前に `npm run lint` 必須
- API クライアントは `src/lib/api.ts` に集約すること

チームで使うなら Git にコミットして共有するのが定石。

/init で自動生成

既存プロジェクトに追加するときは /init コマンドを使うと、package.json や tsconfig.json を解析して CLAUDE.md のたたき台を自動生成してくれる。そのまま使わず必ず手で調整すること。

Tip 2: Plan-Then-Execute で大きなタスクを安全に進める

複雑な機能実装を一発で頼むと、Claude が勝手に判断して予想外の変更をしてしまうことがある。「まず計画を作る → レビューする → 実行する」の2段階にすると制御しやすい。

> 認証機能を追加したい。まず実装計画だけ作って。コードは書かないで。
（計画をレビュー）
> OK、その計画で進めて。ただし JWT 部分は既存の auth.ts を使うこと。

Plan Mode（Shift+Tab 2回）を使うと、Claude が自律的に調査・質問してから計画を立ててくれる。

Tip 3: /compact でコンテキストを適切に管理する

長いセッションではコンテキストが膨らみ、レスポンスが遅くなったり応答品質が落ちる。/compact を使うと会話履歴を圧縮・要約してくれる。

タイミングの目安:

• 大きな機能が一段落したとき
• /context で使用率が70%を超えたとき
• 「さっきの話」を Claude が混乱し始めたとき

長いセッションを維持するより「節目でコンパクト化して再スタート」のほうが最終的な品質が高くなることが多い。

Tip 4: MCPサーバーで外部データにアクセスする

Claude Code は MCP（Model Context Protocol）経由で外部ツールに繋げられる。データベースのスキーマを直接読ませながらコードを書かせると、型の不一致やカラム名の間違いが激減する。

よく使われる MCP サーバー:

• @modelcontextprotocol/server-postgres - PostgreSQL接続
• @modelcontextprotocol/server-github - GitHub API
• @modelcontextprotocol/server-slack - Slack連携

v2.1.128 から /mcp コマンドでツール数が確認できるようになったので、接続確認がしやすくなった。

Tip 5: テストファーストでコード品質を担保する

「テストを先に書かせてから実装させる」パターンは Claude Code と非常に相性がいい。

> UserService クラスの単体テストを書いて。
  正常系・異常系・エッジケースを網羅すること。
  実装コードはまだ書かないで。
（テストをレビュー・修正）
> このテストが全部通るように UserService を実装して。

実装から始めると Claude が仕様を勝手に解釈するが、テストが先にあると制約が明確になる。

Tip 6: --allowedTools で権限を絞る

チーム環境やCI環境では、Claude に与えるツールを最小限にすると安全:

claude --allowedTools "Read,Edit,Write,Bash(npm test,npm run lint)" \
  "テストが全部通るようにバグを直して"

ファイルの読み書きとテスト実行だけを許可して、それ以外のBashコマンドはブロックする、という設定。

Tip 7: git diff をパイプしてコードレビューを自動化する

git diff HEAD~1 | claude "このdiffをレビューして。
バグ・セキュリティ問題・可読性の問題を日本語で指摘して"

pre-commit フックに仕込むことで、コミット前に自動レビューをかけることも可能:

#!/bin/bash
git diff --cached | claude --print "セキュリティリスクだけチェックして。
問題なければ何も出力しないで" && git commit "$@"

Tip 8: ヘッドレスモードでCI/CDに組み込む

--print フラグを使うとインタラクティブUIなしで動作する:

# GitHub Actions での例
- name: Claude Code Review
  run: |
    git diff ${{ github.base_ref }}..HEAD | \
    claude --print "PRレビュー: バグと改善提案を箇条書きで" \
    >> $GITHUB_STEP_SUMMARY

ただし API コストが発生するため、トリガー条件は慎重に設定すること。

Tip 9: カスタムスラッシュコマンドでチームの作業を標準化する

.claude/commands/ ディレクトリにMarkdownファイルを置くと、チームで共有できるスラッシュコマンドになる:

<!-- .claude/commands/review.md -->
このファイルの変更点を以下の観点でレビューして:
1. バグ・ロジックの誤り
2. 型安全性
3. テストの抜け漏れ
4. パフォーマンス上の問題

日本語で箇条書きにして。

Git にコミットすれば git pull するだけで全員が同じコマンドを使える。

Tip 10: セッションカラーとセッションリキャップで複数セッション管理

複数のClaude Codeセッションを並行して動かす場合:

• /color でセッションごとに異なる色を設定（v2.1.128から引数なしでランダム）
• セッションから離れた間に何が起きたかは /recap で確認

Week 17（v2.1.114〜）から追加されたセッションリキャップ機能は、「別のタスクをやって戻ってきたら何が起きてた?」という状況に効く。/config から自動リキャップをオフにもできる。

まとめ

Claude Code は「CLIツール」という外見よりずっと奥が深く、設定と組み合わせ方次第で生産性が大きく変わる。まず試してほしいのは:

1. CLAUDE.md を書く（これだけで体験が変わる）
2. Plan-Then-Execute を意識する（勝手に動かさない）
3. /compact を使う（長いセッションを諦めない）

残りは使いながら少しずつ追加していけばOK。チームで使うなら CLAUDE.md とカスタムスラッシュコマンドのリポジトリ共有が最初の一歩になる。