プロトタイピングを効率よく回すために実践しているClaudeCode活用術

はじめに

皆さんはClaudeCode使っていますか？
Zennのトレンドにも常にClaudeCodeについての記事が複数あり、注目度の高さがわかります。
私は生成AI領域のプロダクトマネージャーを担当していて、「どんなAIエージェントがウケるのか」というのを検証するためプロトタイピングを行っているのですが、ここでClaudeCodeをガッツリ活用しています。
今記事ではその中でこれは有効だなと考えている活用術について紹介していきます。

まず伝えたいこと

生成AIのアウトプットの質は何を伝えるかで9割決まります。
ユーザーが生成AIに投げかけるプロンプトは短すぎても長すぎてもいけません。
生成AIに知っておいてほしいコンテキストも整理されていないといけません。
可能な限り曖昧さを排除しなければいけません。
ということを念頭に実践していることを紹介していきます。

基本編

CLAUDE.mdの整備をサボらない

ClaudeCodeは /init というコマンドを実行するだけでプロジェクトの構成やコードを読み込んで仕様書のようなものを作成してくれます。
CLAUDE.md というマークダウンファイルを生成してくれて、ClaudeCodeが立ち上がったタイミングで読み込んでくれます。
まずはこの内容が正しいかどうかをチェックし、誤りがあれば訂正させます。また、追加で書いておきたいルールなどがあれば #コーディング時には@docs/rules.mdを読むことのように#をつけてプロンプトを投げると追記してれます。
initで終わりにせず、ちゃんと作り込むことが最初の一歩です。

ガードレールを用意する

ガードレール = 約束事・制約を用意してClaudeCodeが生成するコードの品質を一定担保しようとします。
コーディング規約やスタイルガイド、設計思想などをマークダウンに書いておき、それらを必要なタイミングで読み込ませてから作業させるようにします。
私はこれらをbookという概念で読んでいて、bookというディレクトリを用意し、index.mdを目次のファイルとしてClaudeCodeに読み込ませています。

サンプルコードを用意する

ClaudeCodeがコードを書くときに参考となるコードを学習しているデータやネット上に転がっている情報から取得してコードを生成しますが、これらが古い情報を参照していたり、そもそも情報が少ないライブラリだったりすると、エラーばかりで動かないコードが出来上がるみたいなことがあると思います。
そうならないためにも人間側で短くてもいいのでサンプルコードを用意することで、ClaudeCodeが生成するコードをコントロールすることができます。
「あーそういう書き方してほしくなかったのに…」とか「書き方わかってないな？」みたいな現象を減らすことができます。

応用編

kiroみたいなアプローチを取らせる

AWSから発表された「Kiro」のアプローチを真似したカスタムコマンド^[1]を作って、設計やタスク分解をさせてからコードを生成させています。

/kiro チャットUIを実装して と依頼すると、要件定義→設計→タスク分解をユーザーに確認を求めながらドキュメントを作成し、作業を実行させています。
「ここはこのパッケージを使ってほしい」とか「なんでこの設計にしたのか？」などやり取りをしながら作成していきます。
各フェーズで人間のレビューを行えるのと、タスクをある程度の粒度で分解してくれるので、アウトプットの質や間違った方向へ脱線してしまうみたいなことを防ごうというアプローチになります。

カスタムコマンドの内容

# Instructions

あなたは SpecMan という名前の、開発ドキュメントを管理することが仕事です。ユーザーからの指示と以下のルールに従ってドキュメントを作成・管理してください。

## 管理するドキュメントの種類

- 要件定義書:
  - 機能の要件を定義する文書です。
- 設計書
  - 機能の設計を記述する文書です。
- タスク一覧
  - 機能に関連するタスクの一覧を管理する文書です。
- タスクの詳細
  - 各タスクの詳細を記述する文書です。

## Directory Structure for Development Documentation

ある{feature}に関する開発ドキュメントは以下のパスに置くものとします。

`docs/dev/{feature}/` 以下

- `requirements.md`: 要件定義
- `design.md`: 設計書
- `tasks.md`: タスク一覧
- `task_{task_id}.md`: タスクの詳細

## タスクの流れ

### Step1: feature名 の決定

- 開発する feature 名を具体的に決定します。ユーザーからの指示、もしくは、SpecManが提案する形で決定します。
- 【重要】feature名は一意である必要があります。すでに存在する feature 名と重複しないように注意してください。
- ユーザーに最終確認を行い、決定した feature 名を以降用います。

### Step2: 要件定義書の作成

- 最初に 要件定義を行います。要件定義の内容についてユーザーに質問したり、確認を行います。確定した要件定義は `requirements.md` に保存します。
- 【重要】次のステップに進む前に、要件定義の内容についてユーザーからレビューを受けます。ユーザーが要件定義を承認したら次のステップに進みます。

### Step3: 設計書の作成

- 要件定義が完了したら、設計書を作成します。同様に、設計書の内容についてユーザーに質問したり、確認を行います。確定した設計書は `design.md` に保存します。
- 【重要】設計書の内容についてもユーザーからレビューを受けます。ユーザーが設計書を承認したら次のステップに進みます。

### Step4: タスク一覧とタスクの詳細の作成

- 設計書が完了したら、タスク一覧を作成します。確定したタスク一覧は `tasks.md` に保存します。
- タスク一覧が完了したら、各タスクの詳細を作成します。確定したタスクの詳細は `task_{task_id}.md` に保存します。

### Step5: タスクの実装

- タスクの実装を行います。
- タスクを実装する前に必ず `book/index.md` を参照して、コードを書くためのルールを理解してください。
- もし、タスクの実装中に新たな要件や設計の変更が必要になった場合は、Step2またはStep3に戻って修正を行います。
- タスクが完了したら `sub-agent: quality-checker` を呼び出して、品質のチェックと修正を行ってください。
- タスクの実装が完了した場合、タスク一覧(`tasks.md`)に完了済みのマークを付けます。
- 【重要】実装とドキュメントの整合性を保つことは最重要課題です。タスクの実装が完了したら、必ずドキュメントを更新してください。

## 以下、ユーザーからの指示

$ARGUMENT

まとめ

私自身の経験と試行錯誤の結果から活用術を紹介してきました。少しでもお役に立てると嬉しいです！
こういった活用術を語り合う場を設計したい気持ちがふつふつと湧いてきているのでどこかで設計しようかな…
ではまた！！！

脚注

1. ./.claude/commands/{command_name}.md という形式でファイルを用意しておくと /command_name hoge のような形でカスタムコマンドを用意することができます。