Zenn
Solvio株式会社Publicationへの投稿
🤩

【Claude Code】まだ定型プロンプト打ってません？？カスタムコマンド活用して作業効率爆上げ

sho_
に公開
AI
Claude
Anthropic
Claude Code
Vibe Coding
tech

はじめに

皆さん、Claude Codeを使っていてこんな経験はありませんか？
毎回同じような指示を出している、作業の進捗が分からなくなる、ultrathinkを忘れて精度が下がってしまう...

自分も普段Claude Codeを使い倒しているのですが、これらの課題を解決するためにカスタムコマンドを自作し、効率的な開発フローを構築してきました。

その中で特に効果的だったカスタムコマンドと、その活用法について今回ご共有させていただきます。

想定読者

  • Claude Codeを日常的に使用している方
  • 作業効率を向上させたい方
  • カスタムコマンドの活用方法を知りたい方

カスタムコマンドを使用するにあたった経緯


今回カスタムコマンドの作成の仕方・自分が使用しているカスタムコマンドをご共有させていただきますが、そもそもなぜカスタムコマンドを使用しているのかと思っている方もいるかと思います。
こちらに関してご説明させていただきます。

anthropicが提示している指示出しのベストプラクティス

anthropicではClaude Codeに指示を出す場合一括でその要件を満たすような実装を行わせるのではなく、調査・プラン・実装・コミットなどいくつかのステップに分かれて実行するとより精度が高まると言っています。

また、一括で処理を行おうとすると大量のコンテキストを使用してしまい、その際に途中でcompactが実行され、コンテキストの圧迫が行われます。
このcompactが自分としてはあまり精度が良いように思えず、うまく会話のコンテキストを引き継いでくれない体感があることから日々できるだけ処理を分割するように指示を出しています。

しかし、結構毎回打つテンプレート文のようなものがあり、また指示を出すのすらめんどくさくなってしまっている人もいるかと思います。
（自分もその一人です😂）

そのため、自分は処理ごとにカスタムコマンドを作成し、使い分けることによってできるだけ簡単に自分の要望を満たすような実装を行ってくれるようにカスタマイズしています。

自分は以下のようなフローを普段は使用しており、今回ご紹介させていただくカスタムコマンドは以下のフローごとにいちいちプロンプトを考えたりするのが手間だと思ったためにできるだけ簡略化したいという願望のもと作成しました。

今回はその詳細に関してご共有させていただければと思います。

カスタムコマンドとは？？

Claude Codeはデフォルトで定義されているコマンド以外に自分で作成したコマンドを定義することができます（カスタムコマンド）

実際にこの記事ではこのカスタムコマンドをご紹介していきます。普段定型的に使用しているプロンプトなどをカスタムコマンドに定義しておくと毎回入力する手間が省けてとても便利です

カスタムコマンドは.claude/commands/以下に.md形式のファイルを作成することで定義することができます。

PJ中の.claude に記述を行えばそのPJにて使用できるカスタムコマンド。
~/.claudeに追加すればユーザ単位で全てのPJにて使用ができるカスタムコマンドを定義することができます。

また、普通のコマンドと同じように引数を指定することができ、その場合は.mdファイル中に#$ARGUMENTS を記述します。

必ずやってほしいことなど、CLAUDE.mdに記述をする方法もあるのですが、体感ですがカスタムコマンドの方がその確率が異様に高いように思えるのでこちらを使用しています。
（おそらくカスタムコマンドは普通のプロンプトと同じ扱いなのでしょうか？？）

自分が使用しているカスタムコマンド

1. 調査コマンド (/investigate)

概要

新機能の実装前や問題分析の際に使用するコマンドです。
ultrathinkを必須化し、徹底的な調査を行うようになっています。

コマンド内容

# INVESTIGATE フェーズ

# ユーザの入力
#$ARGUMENTS 

## 目的
背景・要件・制約の把握を行い、実装の方向性を決定する。

## 注意事項
- 関連するコードは全て読むこと。
- 全ての処理においてultrathinkでしっかりと考えて作業を行うこと。
- ファイルへの記述において絵文字を使用してはいけません。

## タスクに含まれるべきTODO
2. 調査対象・スコープを明確化
3. 現在のブランチ状況を確認し、`feature/<topic>` ブランチを作成
4. 関連ファイル・ログ・ドキュメントを収集し、体系的に分析
5. 技術的制約・可能性を調査
6. 既存システムとの整合性を確認
7. 問題の根本原因・解決方針を特定
8. 調査結果を文書化し、`docs/investigate/investigate_{TIMESTAMP}.md`に保存
9. 次フェーズ（Plan）への推奨事項を提示
10. 調査完了とファイル保存に関して`afplay /System/Library/Sounds/Sosumi.aiff`を実行しユーザに通知
11. 作成したブランチ名、調査結果ファイル名をコンソール出力

## ブランチ作成規則
- ブランチ命名: `feature/<topic>` または `fix/<issue>`
- 必ず `main` ブランチから作成
- ブランチ作成後はそのブランチで全作業を継続

## 出力ファイル
- `docs/investigate/investigate_{TIMESTAMP}.md`

## 最終出力形式
- 必ず以下の二つの形式で出力を行ってください

### 調査完了（実装推奨）の場合
status: COMPLETED
next: PLAN
details: "調査完了。feature/<topic>ブランチ作成済み。docs/investigate/investigate_{TIMESTAMP}.mdに詳細を記述。実装方針策定を推奨。"

### 調査完了（実装不要）の場合
status: COMPLETED
next: NONE
details: "調査完了。docs/investigate/investigate_{TIMESTAMP}.mdに詳細を記述既存機能で対応可能。実装・変更は不要。"

おすすめポイント

このコマンドではultrathinkを必須化することで、最大限リソースを使用して思考するモードになります。また、調査結果を必ずドキュメント化することで、後から見返すことができます。

2. プランニングコマンド (/plan)

概要

調査結果を基に具体的な実装計画を立てるコマンドです。
引数では先ほどのinvestigateフェーズの出力をそのまま利用します。

コマンド内容

# PLAN フェーズ

## 目的
実装方針の決定、タスク分解、ファイル変更計画、テスト方針を策定する。

## 必要な入力ファイル
- `docs/investigate/investigate_{TIMESTAMP}.md` - 調査結果

## 注意事項
- 関連するコードは全て読むこと。
- 全ての処理においてultrathinkでしっかりと考えて作業を行うこと。

# ユーザの入力
#$ARGUMENTS


## テスト方針
- **エンドポイントテスト**: 必須（FastAPI: TestClient / httpx）
- **統合テスト**: 必要に応じて実施
- **E2Eテスト**: UI変更がある場合は実施
- **Docker環境での実行**: 全てのテストはDocker環境で実行

## タスクに含まれるべきTODO
1. ユーザの指示を理解する
2. 最新の `docs/investigate/investigate_{TIMESTAMP}.md` を読み込み、調査結果を確認
3. 調査結果を元に実装方針を決定
4. 詳細実装タスクを分解し、優先度を設定
5. ファイル変更計画を作成（新規作成・修正・削除）
6. テスト戦略を策定（単体・統合・E2E）
7. リスク分析と対策を検討
8. 実装計画を文書化し、`docs/plan/plan_{TIMESTAMP}.md`に保存
9. 必要に応じて `@ai-rules/ISSUE_GUIDELINES.md` を確認してGitHub Issue を作成
10. プラン完成とファイル保存に関して`afplay /System/Library/Sounds/Sosumi.aiff`を実行しユーザに通知
11. プランファイル名、作成されたIssue番号（もしあれば）をコンソール出力

## GitHub Issue作成（必要に応じて）
`@ai-rules/ISSUE_GUIDELINES.md`に従い、以下を含むIssueを作成：
- タイトル
- 概要
- 受入基準
- タスクリスト
- 優先度・ラベル

## 出力ファイル
- `docs/plan/plan_{TIMESTAMP}.md`

## 最終出力形式
- 必ず以下の二つの形式で出力を行ってください

### プラン策定完了の場合
status: SUCCESS
next: IMPLEMENT
details: "実装プラン策定完了。plan_{TIMESTAMP}.mdに詳細記録。実装フェーズに移行。"

### 調査不足の場合
status: NEED_MORE_INFO
next: INVESTIGATE
details: "情報不足。plan_{TIMESTAMP}.mdに詳細記録。追加調査が必要。"

3. 実装コマンド (/implement)

概要

プランに従って実際の実装を行うコマンドです。
引数では先ほどのplanフェーズの出力をそのまま利用します。

# IMPLEMENT フェーズ

# ユーザの入力
#$ARGUMENTS

## 目的
plan.mdに基づきタスク単位で実装を行う。Draft PRを継続的に更新する。

## 注意事項
- 常にultrathinkでしっかりと考えて作業を行うこと
- コード中に絵文字は使用されるべきではありません。

## 必要な入力ファイル
- `docs/plan/plan_{TIMESTAMP}.md` - 実装計画書
- GitHub Issues（もしあれば）
- 関連する既存ファイル・コード

## タスクに含まれるべきTODO
1. ユーザの指示を理解し、実装開始をコンソールで通知
2. 最新の `docs/plan/plan_{TIMESTAMP}.md` ファイルを読み込み、実装計画を確認
3. 現在のブランチを確認し、適切なブランチにいることを確認
4. プランに従った実装を段階的に実行
5. `@ai-rules/COMMIT_AND_PR_GUIDELINES.md`に従ったコミット・プッシュ
6. Draft PRを作成または更新（初回実装時は作成、継続時は更新）
7. 実装内容の詳細を `docs/implement/implement_{TIMESTAMP}.md` に記録
8. 実装完了とファイル保存に関して`afplay /System/Library/Sounds/Sosumi.aiff`を実行しユーザに通知
9. 関連するplanファイル、実装詳細ファイル、PR番号をコンソール出力

## ブランチ・コミット規則
- ブランチ命名: `@ai-rules/COMMIT_AND_PR_GUIDELINES.md` に準拠
- コミットメッセージ: 同ガイドラインに従う
- 小粒コミット: タスク単位で適切に分割
- Draft PR: 実装初回時は作成、継続時は更新


## 出力ファイル
- `docs/implement/implement_{TIMESTAMP}.md` - 実装詳細記録

## 最終出力形式
- 必ず以下の三つの形式で出力を行ってください

### 実装完了の場合
status: SUCCESS
next: TEST
details: "実装完了。implement_{TIMESTAMP}.mdに詳細記録。テストフェーズへ移行。"

### 追加作業が必要な場合
status: NEED_MORE
next: IMPLEMENT
details: "依存関係の実装が必要。implement_{TIMESTAMP}.mdに詳細記録。タスク継続。"

### プラン見直しが必要な場合
status: NEED_REPLAN
next: PLAN
details: "設計変更が必要。implement_{TIMESTAMP}.mdに詳細記録。プランフェーズに戻る。"

4. テストコマンド (/test)

概要

実装した機能の包括的なテストを行うコマンドです。
引数では先ほどのimplementフェーズの出力をそのまま利用します。

コマンド内容

# TEST フェーズ

# ユーザの入力
#$ARGUMENTS

## 目的
追加・変更されたコードの **エンドポイント機能** をDocker環境で実行検証する。

## テスト実行方針
- **Docker環境での実行を必須**: 全てのテストはDockerコンテナ内で実行する
- **環境の一貫性**: 本番環境との差異を最小限に抑える
- **再現性の確保**: 環境依存の問題を排除する

## 必要な入力ファイル
- `docs/plan/plan_{TIMESTAMP}.md` - テスト要件の確認
- `docs/implement/implement_{TIMESTAMP}.md` - 実装内容の詳細
- 実装されたコード（現在のブランチ）

## テスト種別
- **エンドポイントテスト（必須）**
  - Docker Compose環境での実行
  - FastAPI: `TestClient` / `httpx`
  - 各エンドポイントの status_code == 200
  - レスポンス JSON が期待スキーマと一致
- **統合テスト（任意）**
  - Dockerコンテナ内でのデータベース連携テスト
  - Dockerコンテナ内での外部API連携テスト
- **E2Eテスト（任意）**
  - Docker環境でのPlaywright を使用したブラウザテスト


## タスクに含まれるべきTODO
1. ユーザの指示を理解し、テスト開始をコンソールで通知
2. 最新の `docs/plan/plan_{TIMESTAMP}.md` からテスト要件を確認
3. 最新の `docs/implement/implement_{TIMESTAMP}.md` から実装内容を確認
4. Docker Compose環境の構築・起動をユーザに通知
5. 追加・変更されたエンドポイントのテストケースを作成
6. Docker環境内でエンドポイントテストを実行
7. 統合・E2EテストをDocker環境内で必要に応じて実行
8. 各種テストの実行状況をユーザにリアルタイム通知
9. 失敗したテストがあれば詳細をユーザに報告
10. テスト結果を総合評価し文書化
11. Docker環境の停止・クリーンアップをユーザに通知
12. `docs/test/test_{TIMESTAMP}.md`でテスト結果を保存
13. テスト完了とファイル保存をユーザに通知
14. 次フェーズへの移行判定をコンソール出力


## 出力ファイル
- `docs/test/test_{TIMESTAMP}.md`

## 最終出力形式
- 必ず以下の三つの形式で出力を行ってください

### テスト成功の場合
status: SUCCESS
next: DONE
details: "全テスト通過。test_{TIMESTAMP}.mdに詳細記録。"

### テスト失敗・修正が必要な場合
status: FAILURE
next: IMPLEMENT
details: "失敗: /users GET で 500 エラー。詳細はtest_{TIMESTAMP}.mdを確認。修正が必要。"

### 根本的な問題が発覚した場合
status: CRITICAL_FAILURE
next: INVESTIGATE
details: "重大な問題を発見。test_{TIMESTAMP}.md。根本原因の再調査が必要。"

全体的なこだわりポイント

ドキュメント化を必須にしている

個人的にClaude Codeを使用していて、よくあるのが「後からどのような変更を行なったのか振り返ることができない」ことです。
こちらは予想外の編集などを行なっていたときに、変更を辿って元に元したい！などたまにあるのですが、普段コミットなどを指示していないと振り返ることができない、変更を辿ることもできない、、と詰みます😭

なので必須にして、ドキュメントでどのような変更を行なったのか、どのような方針で作業を行なったのかを振り返られるようにしています。

ultrathinkを必須にしている

こちらは思考レベルを指定することができるワードなのですが、いかんせん毎回プロンプトに入れることが少し面倒だと思っています。
また、たまに忘れると思ってもいないことをやったりもするので必ずプロンプトに入れたいワードです。

なので全てのカスタムコマンドでこのワードを入れることにより失念防止をしています。

ある程度コマンドだけで調査・プラン・実装ができるようにしている

前段階の出力をそのまま次のフェーズの入力にすることができるので、とても楽に複数のステップを処理することができます。

ユーザ通知も必ず入れるようにしているのでサウンドがなったら出力内容をそのまま次のフェーズのコマンドの引数に入れれば作業継続することができ、とても作業が効率的に行うことができるようになりました。

読んでほしいファイルに関してはコマンド中で定義している

自分はAIに読んでほしいガイドラインなどは全てドキュメントでまとめています。
こちら読んでほしいものに関して、CLAUDE.mdに定義する方法もあるのですが、カスタムコマンド中にTODOとして定義した方がよりその内容を読んでくれる確率が高いと体感しているのでこのように定義を行なっています。

実際の使用例

エラー解消の場合

  1. investigate フェーズ
    /investigate フロントエンドでエラーが起きている。これ解消したい
  2. planフェーズ
/plan   status: SUCCESS
  next: IMPLEMENT
  details: "実装プラン策定完了。plan_20250707_054741.mdに詳細記録。実装フェーズに移行。

このように自然言語で最初のフェーズのみ指示を出すことで後続のコマンドではその一個前のコマンドの出力内容を入力するだけで作業を続けることができます。

また、これ以降のフェーズに関しても同じように入力していけば、最終的にtestが終了しているようになっています。

まとめ

カスタムコマンドを活用することで自分は作業効率や作業のマネジメントがよりできるようになりました！
ぜひ皆さんも自分の作業フローに合わせたカスタムコマンドを作成してみてください。

この記事がみなさんの参考になれば幸いです

Solvio株式会社
Solvio株式会社Publication

生成AIを軸に企業の課題解決を行う会社です。

Discussion