Claude Code入門の次の一歩:これから活用していくための設定方法と考え方
こんにちは!フクロウラボの若杉です。
Anthropic社が提供するターミナル上で稼働できるAIコーディングエージェント、Claude Codeについて書きたいと思います。多くの方が、Claude Codeを利用しているところだと思いますし、この界隈においてはここ数ヶ月での注目を集めているトピックだと思います。
Claude Codeが注目されてからも、高頻度で機能追加・改善が行われています。そこで現時点(2025年8月時点)において、「おおよそこんな感じで使うよね」という部分をまとめてみたいと思います。
今までもGitHub Copilot、Cursor、Roo Code、Cline、DevinなどのAIツールやエージェントを使っていて、Claude Codeへ本格的に移行していこうと考えている方などに参考になればと思います。
使いこなしのポイントまとめ
ざっくり使いこなしのポイントをまとめると下記の5つかと思っています。
- CLAUDE.mdの設定
- コマンド実行の権限管理
- GitHub Actionsとの連携設定
- Hooks機能による自動化
- カスタムスラッシュコマンドの作成
1. CLAUDE.mdの設定
プロジェクト横断のコーディング規約や手順は、CLAUDE.mdファイルで定義できます。
CLAUDE.mdには、下記のような4つの種類が存在します。
メモリタイプ | 位置 | 目的 | ユースケース例 | 共有相手 |
---|---|---|---|---|
企業ポリシー | macOS: /Library/Application Support/ClaudeCode/CLAUDE.md Linux: /etc/claude-code/CLAUDE.md Windows: C:\ProgramData\ClaudeCode\CLAUDE.md
|
IT/DevOpsによって管理される組織全体の指示 | 会社のコーディング標準、セキュリティポリシー、コンプライアンス要件 | 組織内のすべてのユーザー |
プロジェクトメモリ | ./CLAUDE.md |
プロジェクトのチーム共有指示 | プロジェクトアーキテクチャ、コーディング標準、共通ワークフロー | ソース管理を介したチームメンバー |
ユーザーメモリ | ~/claude/CLAUDE.md |
すべてのプロジェクトに対する個人的な好み | コードスタイルの設定、個人用ツールのショートカット | あなただけ (すべてのプロジェクト) |
プロジェクトメモリ (ローカル) | ./CLAUDE.local.md |
個人プロジェクト固有の設定 | (非推奨、下記参照) サンドボックスURL、推奨テストデータ | あなただけ (現在のプロジェクト) |
※参照元:https://docs.anthropic.com/en/docs/claude-code/memory#determine-memory-type
企業ポリシー用のCLAUDE.mdは、セキュリティやデータの取り扱いについて、絶対にやってほしくない挙動について記載するなどが考えられそうです(実際の強制は、managed-settings.jsonを使うイメージ)。プロジェクトメモリ (ローカル)./CLAUDE.local.md
は、非推奨のようなので、基本体には、プロジェクトメモリ(./CLAUDE.md
)とユーザーメモリ(~/.claude/CLAUDE.md
)を設定する感じになると思います。
何を記載するか
プロジェクトメモリは、会社でチームで開発するプロジェクトか個人で開発するプロジェクトかによって、CLAUDE.mdの設定方針は変わると思います。チーム開発ではしっかりとした「共有のルール」を、個人開発ではラフに「未来の自分へのメモ」を記載するイメージかなと思っています。
チーム開発でのプロジェクトメモリは、全員が従うべき公式なルールブック的な役割を目指して、主に下記のような内容をチーム内で吟味して記載していく感じになると思います。
-
コーディング規約
会社の全体ルール(Enterprise Policy)を補足する、プロジェクト固有の命名規則やスタイル。 -
アーキテクチャ
このプロジェクトで採用している設計(例: クリーンアーキテクチャ、レイヤー構造)の説明。 -
共通ワークフロー
Gitのブランチ戦略(例: Git-flow)、コードレビューの手順、チケットの運用ルールなど。 -
技術スタック
使用するライブラリやフレームワークのバージョンと、その選定理由。 -
セットアップ手順
新しいメンバーがすぐに開発を始められるような環境構築の手順。
個人開発では、上記の内容で個人的に遵守したいルールを盛り込めばよいと思います。あと、CLAUDE.md自体をClaude Codeに作ってもらい、それを手直しして利用するのはよくやっています。
@path/to/import で他ファイルを取り込む
構造化して分割(import):@path/to/import で他ファイルを取り込めます。
例:
...
## Coding Standards
- Python/TS standards are listed below and always referenced.
- @docs/policies/python.md
- @docs/policies/typescript.md
以前はCLAUDE.mdに詳細なルールを書き込む手法が取られていましたが、役割毎の.mdファイルを作成し、それぞれシンプルに記載する方が管理しやすいと思います。また、後述するカスタムコマンドやHooksの発達により、CLAUDE.mdを肥大化させないように記述することができるようになりました。
CLAUDE.mdの適用の法則について
下記のAnthropic公式のClaude Codeのベストプラクティスの記事にCLAUDE.mdがどのように適用されるかの記述があります。
You can place CLAUDE.md files in several locations:
- The root of your repo, or wherever you run claude from (the most common usage). Name it CLAUDE.md and check it into git so that you can share it across sessions and with your team (recommended), or name it CLAUDE.local.md and .gitignore it
- Any parent of the directory where you run claude. This is most useful for monorepos, where you might run claude from root/foo, and have CLAUDE.md files in both root/CLAUDE.md and root/foo/CLAUDE.md. Both of these will be pulled into context automatically
- Any child of the directory where you run claude. This is the inverse of the above, and in this case, Claude will pull in CLAUDE.md files on demand when you work with files in child directories
- Your home folder (~/.claude/CLAUDE.md), which applies it to all your claude sessions
基本的には、先の4つの種類のCLAUDE.mdは、Claude Code実行時に自動的に読み込まれます。ただ、CLAUDE.mdファイルはあらゆるディレクトリに設置することができます。その場合の挙動を補足すると、
・Claude Codeを実行したディレクトリから、リポジトリルートディレクトリまでに存在するCLAUDE.mdは自動で読み込まれる。
ということのようです。
例えば、リポジトリ全体がモノレポで役割が異なるアプリのディレクトリが存在している場合、それぞれのアプリのディレクトリ毎にCLAUDE.mdファイルを設置し、そのディレクトリに移動してからClaude Codeを起動させれば、アプリ毎のCLAUDE.mdを自動で反映させることができるということです。
repo_root/
├── CLAUDE.md # ルート:共通の方針
└── apps/
├── web/
│ ├── CLAUDE.md # web 専用の追記
│ └── src/...
└── admin/
├── CLAUDE.md # admin 専用の追記
└── src/...
CLAUDE.mdは英語で記述すべき?
よく聞くのが、
「CLAUDE.mdは回答を日本語に返すような記述を冒頭に挿入し、全体は英語で記述した方がトークン数の節約と回答の精度がよくなる。」
というもの。
# Claude Code — Company Policy
**Primary response language: Japanese (ja-JP).**
- Unless explicitly asked otherwise, all explanations, summaries, and PR descriptions must be in Japanese.
- Keep code and logs in their original language; explain them in Japanese.
## Coding Standards
- Follow Ruff/ESLint rules…
確かにこの効果が多少あると思いますが、CLAUDE.mdファイルは人間(社内メンバー)が読む運用ドキュメントでもあるため、チームの共通言語(全員が最も読む言語)で書く方が、当然、保守性は高いです。このあたりも何を重視するのかをチームで話し合って決める必要があるところです。
2. コマンド実行の権限管理
Claude Codeはコード修正やテスト実行、Git操作など様々なツールを内部で呼び出して作業を行います。デフォルトでは危険なコマンド実行を防ぐため、各ツールの使用時にユーザー承認を求めてきます。このPermission設定を調整することで、許可フローを簡略化し生産性を向上できます。
-
許可プロンプトのスキップ: 開発マシン上でClaude Codeにフルアクセスを与えても問題ない場合、
--dangerously-skip-permissions
オプションで全ツールの許可確認をスキップできます。例えばclaude -c --dangerously-skip-permissions
とすれば、対話再開時に毎回「実行しますか?」と尋ねられることなく自動でコマンドが実行されます。当然、このモードでは誤ったコマンドも即時実行されるため、利用は慎重にすべきです。 -
特定コマンドのみ自動許可: 全てを無条件に許可するのはリスクが高い場合、設定ファイルで個別に許可ルールを定義できます。
~/.claude/settings.json
内のpermissions.allow
にツール名を指定すると、該当ツール実行時に確認が不要になります。例えばGit操作を頻繁に行うなら以下のように設定可能です:
{
"permissions": {
"allow": [
"Bash(npm run lint)",
"Bash(npm run test:*)",
"Bash(pytest:*)",
"Bash(git status)",
"Bash(git diff:*)"
]
}
}
-
特定コマンドの禁止: 同様に、~/.claude/settings.json
内の
permissions.deny`に絶対に実行してほしくないコマンドを記載することで、確実に遮断することもできます。
denyの設定については、下記が参考になります。
https://izanami.dev/post/d6f25eec-71aa-4746-8c0d-80c67a1459be
詳細は上記の内容を見ていただければと思いますが、ざっくり下記のような内容です。
- Bashでの危険操作の禁止
"Bash(sudo:*)",
"Bash(rm:*)",
"Bash(rm -rf:*)",
- 機密ファイルへのアクセス制限
"Read(./.env)",
"Read(~/.ssh/**)",
"Read(~/.aws/**)"
- 外部との通信系コマンドの禁止
"Bash(curl:*)",
"Bash(wget:*)",
"Bash(nc:*)",
- データベース操作の禁止
"Bash(psql:*)",
"Bash(mysql:*)",
"Bash(mongod:*)",
ちなみに、権限の優先順位は deny > ask > allow (deny が最強、次に ask、最後に allow)です。下記に明記されています。
ですので、allowの設定よりも、denyの設定の方が重要になります。想定外の挙動で破壊的操作が行われないように設定しておきます。
3. GitHub Actionsとの連携設定
Claude Codeはローカル開発支援だけでなく、GitHubリポジトリにおける自動化も強力にサポートします。その代表例がClaude Code GitHub Actionsです。GitHub上でAnthropic提供のActionsを設定すると、Pull RequestやIssue上で@claudeをメンションするだけでAIによるコード提案や修正が実行されるようになります。
GitHub Actionsクイックセットアップ
最も簡単な導入手順は、Claude Codeの対話モードから/install-github-app
コマンドを実行する方法です。これによりAnthropicのGitHub Appを自分のリポジトリにインストールする対話フローが開始し、必要なAPIキーやシークレットの登録も自動で案内してくれます。セットアップが完了すると、リポジトリに.github/workflows/claude.yml
(Claude用のワークフロー定義)が追加され、以後は、@claude
とメンションを付けてコメントすることで、Claude Code呼び出すことができます。
例えば、Github Issuesに下記のように指示を記載することで、Claude Codeへ指示を与える事ができます。
すると、Claude Codeが起動し、ToDoリストを作成し、指示内容を実装し、コミットまで作成します。
Github Actionsの利用どころ
ちなみに、Anthropic社では、
- PRのコメント(コードレビュー)
- フォーマットのチェック
- テストケースのリファクタリング
などの自動化に利用していると、下記に記載されています。
デザイン変更をフロント実装へ反映
個人的には、ちょっとしたデザインの変更があった場合に、フロント側の実装をしてもらうなど効果的ではないかと考えています。
その場合、いくつかIssueの書き方にコツが必要かもしれません。
例えば、下記のようなテンプレートに沿って記載するなど。
-
タイトル
変更内容が簡潔にわかるように記述する。
例:「ログインページのボタンデザインを更新」など。 -
デザインの共有
変更対象箇所を矢印などで分かりやすく示した画像やスクリーンショットなどを貼り付けます。
全体像や詳細を確認したいときのために、該当箇所のFigmaリンクも貼るのも良いかもしれません。 -
テキストでの具体的な指示
ここでの指示が重要ですが、あまり細かく指示するのも大変ですが、デザイナーとして言語化できる範囲で詳細を記載すると良いのではないかと思います。
目的:この変更で何を実現したいのかを簡潔に書きます。
例:「添付のFigmaデザインに合わせてボタンの見た目を変更する」
対象ファイル:エンジニアに確認して、変更対象となるファイルパスを記述します。
例:src/components/primaryButton.tsx
対象要素:変更するHTML要素のクラス名やIDを記述
Figmaを利用している場合、インスペクトから変更箇所の情報などをコピペするなどでも良いかもです。
上記の内容を盛り込んで、@claude
で依頼すれば割と安定して狙ったコミットを作成してくれるのではないかと思います。
実際には、Claude Codeがこのリポジトリのコンテキストをどの程度理解させることができているかによって異なるので、Issueの指示にどこまで詳細を記載すべきかは、使用しながら調整していく感じになります。
また、FigmaのMCPサーバーを利用できるようにし、デザインのURLを共有することで、Claude Codeが精度高くデザインを理解できるようになります。FigmaのMCPサーバー利用には、有料プランが必要ですが、そちらを使った方がより質の高いアウトプットが引き出せると思います。
4. Hooks機能による自動化
Claude CodeのHooks機能は、特定のイベント(Claudeのライフサイクル各所)にフックして任意のコマンドやスクリプトを自動実行できる仕組みです。2025年7月にリリースされた新機能で、以前はCLAUDE.mdやカスタムコマンドに書いてもうまく働かなかった自動処理も、Hooksなら確実に実行させることができます。
Hookイベント一覧について
Hooksは、Claude Codeのライフサイクルにおける様々なイベントをトリガーにして実行されます。イベントには以下のようなものがあります。説明と主な用途例として、表にまとめてみました。
イベント名 | 説明 | 主な用途例 |
---|---|---|
PreToolUse |
ツール(ファイル編集、コマンド実行、Git操作など)が使用される直前に実行 ※このフックはツールの実行をブロックすることが可能です。 |
・セキュリティチェック: 危険なコマンド(例: rm -rf )や本番環境への書き込みをブロックする。・ログ記録: 実行されるすべてのコマンドと引数を記録し、監査ログとして残す。 ・入力の書き換え: ユーザーの指示をより安全または一貫性のあるコマンドに自動的に修正する。 |
PostToolUse |
ツールが使用された直後に実行 |
・自動フォーマット: ファイル編集後にPrettier やBlack などのフォーマッターを自動実行する。・自動テスト: コード変更後に単体テストやリンターを自動実行し、結果をフィードバックする。 ・成果物の管理: 生成されたファイルを特定のディレクトリに移動したり、バックアップを作成したりする。 |
UserPromptSubmit |
ユーザーがプロンプトを送信し、Claudeがそれを処理する前に実行 |
・プロンプトの拡張: ユーザーのプロンプトに、プロジェクトの規約や前提条件などの定型文を自動で追加する。 ・言語の指定: プロンプトに常に「日本語で回答してください」といった指示を付与する。 ・機密情報のマスキング: プロンプトに含まれるAPIキーなどの機密情報を送信前にマスキングする。 |
Notification |
Claude Codeがユーザーに通知(例:ツールの実行許可など)を送信するときに実行 |
・カスタム通知: デフォルトの通知をSlack、Discord、またはOSのデスクトップ通知に置き換える。 ・音声通知: 長時間かかる処理の完了を音声で知らせる。 ・進捗の可視化: 複数のステップがあるタスクの進捗状況を外部ツールに表示する。 |
Stop |
Claude Codeの応答が完了したときに実行 |
・セッションログの保存: 一連の対話の最終結果や要約をファイルに保存する。 ・完了通知: タスクの完了をチームのチャットツールに通知する。 ・後処理: 生成された一時ファイルをクリーンアップする。 |
SubagentStop |
サブエージェント(/task コマンドなどで実行される独立したタスク)の応答が完了したときに実行 |
・タスク単位の完了通知: 複数のサブタスクが並行している場合に、個々のタスクの完了を通知する。 ・結果の集約: 各サブエージェントの実行結果を一つのレポートにまとめる。 ・タスクの連鎖: あるサブタスクの完了をトリガーに、次のタスクを自動的に開始する。 |
PreCompact |
Claude Codeがコンテキスト圧縮(/compact )を実行する前に実行。 |
・状態の保存: 圧縮によって失われる可能性のある重要な情報を、圧縮前にファイルに退避させる。 ・トークン使用量の監視: 圧縮前後のトークン数を記録し、コスト管理に役立てる。 |
SessionStart |
新しいセッションを開始したとき、または既存のセッションを再開したときに実行 |
・環境の初期設定: セッション開始時に必要な環境変数を設定したり、仮想環境をアクティベートしたりする。 ・プロジェクト概要の読み込み: プロジェクトの README.md やCLAUDE.md を読み込み、Claudeにコンテキストを自動で与える。 |
SessionEnd |
Claude Codeのセッションが終了するときに実行 |
・作業内容のコミット: セッション中に行われた変更を自動的にGitにコミットする。 ・作業時間の記録: タイムトラッキングツールに作業時間を記録する。 ・リソースの解放: データベース接続などを安全にクローズする。 |
※参照:Hooks reference
Hooks設定の基本
Hooksを使うには、settings.json
にhooks
セクションを追加します。設定例を簡略化すると以下のようになります。
{
"hooks": {
"EventName": [
{
"matcher": "ToolPattern",
"hooks": [
{
"type": "command",
"command": "your-command-here"
}
]
}
]
}
}
※参照:Hooks reference
設定例
例えば、Claude Codeの処理が何らかの処理が完了した場合やユーザーに対してレスを求めて通知した場合に、音で知らせるというHooksの設定は下記になります。
{
"hooks": {
"Stop": [
{
"run": "afplay /System/Library/Sounds/Glass.aiff",
"matcher": {}
}
],
"SubagentStop": [
{
"run": "afplay /System/Library/Sounds/Glass.aiff",
"matcher": {}
}
],
"Notification": [
{
"run": "afplay /System/Library/Sounds/Glass.aiff",
"matcher": {}
}
]
}
}
Stop、SubagentStop、Notificationのイベントが発生したタイミングで、通知音を鳴らすことで、気付けるようにするよくある設定です。この設定は、好みもあると思うので、ユーザー毎の設定~/.claude/settings.json
に記述して利用する感じになります。
5. カスタムスラッシュコマンドの作成
Claude Codeでは「/」から始まる内部コマンドが多数提供されていますが、独自のスラッシュコマンドを定義して開発フローをさらに効率化できます。カスタムスラッシュコマンドとは、よく使う指示や手順をMarkdownファイルに登録し、ワンライナーで再生できる機能です。毎回長々と同じプロンプトを入力する代わりに、/コマンド名 引数
で呼び出せるので作業が簡素化されます。
カスタムコマンドの仕組み
カスタムコマンドはプロジェクト単位かユーザー全体かのスコープで作成できます。具体的には:
-
プロジェクト固有コマンド: リポジトリの
.claude/commands/
ディレクトリにMarkdownファイル(コマンド内容)を置きます。そのプロジェクト内でのみ有効で、チームメンバーと共有可能です(Gitで管理できる)。 -
個人用コマンド: ホームディレクトリの
~/.claude/commands/
にファイルを置きます。自分の環境全プロジェクトで使えますが、他の人には共有されません。
ファイル名がコマンド名になり、コマンドの呼び出しは/scope:名前 引数
という形式です。例えばプロジェクト内にfix-issue.md
を作れば/project:fix-issue 123
で実行できます。ユーザー全体のcode-review.md
なら/user:code-review
で呼び出せます。
カスタムコマンドの作成手順と活用例
作成方法はシンプルで、指定のフォルダにMarkdownを置くだけです。以下に例を示します。
- 現状での変更内容を読み取り、コミットを作成するコマンド
.claude/commands/commit.md
というファイルを作成。
---
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git diff:*), Bash(git commit:*), Bash(git restore:*), Bash(git rev-parse:*), Bash(git branch:*)
argument-hint: [scope optional] e.g. ui or api
description: Stage & commit with a Conventional Commit message
---
## Context
- Branch: !`git rev-parse --abbrev-ref HEAD`
- Status: !`git status --porcelain`
- Diff: !`git diff`
## Task
1. 変更内容を読み取り、Conventional Commits(feat|fix|refactor|docs など)で最小の意味単位にまとめたコミットメッセージ案を作ってください。scope は `$ARGUMENTS` があれば採用。
2. 必要に応じて部分ステージングを提案 → 実施。
3. 最終的に `git add -A && git commit -m "<message>"` を実行。
4. 破壊的変更があれば BREAKING CHANGE を追記。
上記の例では、/commit
で実行できます。
カスタムコマンドでは、allowed-tools
によるコマンド実行の自動許可や、バッククォート記法による事前Bash実行も可能です。
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git diff:*), Bash(git commit:*), Bash(git restore:*), Bash(git rev-parse:*), Bash(git branch:*)Bash(git diff:*), ...
と記述していけば、そのコマンド操作を許可できます。
また、任意のコマンドの実行結果をcontextとして利用したい場合には、
- Status: !`git status --porcelain`
のように
!` + バッククォート付きコマンド
と書くことで、その部分はコマンド実行前に実際にシェルで実行され、その結果(出力)がプロンプト文に埋め込まれます。これを使うことで、「現在のGitブランチ名」や「最新のコミットログ」など動的情報を組み込んだコマンドも作成できます。
カスタムスラッシュコマンドをうまく設定することで、生産性を上げることができると思います。
チームで開発を進める場合、プロジェクトの.claude/commands/
にコマンドを作成していきますが、ここでプロジェクト独自のコマンド集をいい感じに作成していくことが、今後、開発面や運用においても、重要になってきそうです。
サブエージェント機能について
あと、1点、下記のサブエージェント機能という重要な機能も2025年7月にリリースされています。
この機能については、正直まだうまく使いこなせていないので、個人的にもっといろいろ試してみたいと思います。使いこなすには割と多くのノウハウが必要そうなので、サブエージェントについては、別記事にて記載できればと思います。まとめ
以上、Claude Codeの基本的な設定や挙動を紹介しました。要件定義から実装・テスト・デプロイに至るまで、Claude CodeはCUI(コマンドライン)に慣れたエンジニアであれば、直感的に操作できる優れたAIエージェントだと思います。以下に、記事内で扱ったポイントをまとめました。
-
CLAUDE.md:
プロジェクト横断のガイドラインを定義して、Claudeの挙動を統制します。ただし、あまり多くコンテキストを記述すると情報過多になるので、小分けにして、それぞれ要点のみを簡潔に書いて管理していく流れ。 -
権限設定:
禁止・許可するコマンドは精査し、いかに確認待ちを削減できるかがポイント。安全と効率のバランスを考慮する。 -
GitHub連携:
非常に簡単なタスクや非エンジニアが非同期的にタスクを実行するなどで利用できそう。 -
Hooks:
Claude上のあらゆるイベントにフックして通知や整形など、さまざまな定型作業を自動化。 -
カスタムスラッシュコマンド:
アイデア次第であらゆる作業手順をコマンド化して、時短・効率化ができる強力な機能。コマンド操作とプロンプトの指示で、「やりたいこと」を一発で実現できる環境を整えていくイメージ。
Claude Codeが注目された理由の1つとして、リポジトリ全体にわたる「ハイコンテキスト」な情報を理解し、それを踏まえた上でコード生成や質問への回答を行える点にあると思います。GoogleもGEMINI CLIという同等のソリューションをリリースしてきていますし、今後は、何がデファクトスタンダードになっているのか読めない状況です。
Claude Codeは、現在も日々ユーザーのフィードバックを取り込み、急速に進化しています。最新動向を追いつつ、道具として手に馴染むまで使い込んでもらえればと思います!
Discussion