Super Claude(Claude Code)を使ったシステム開発の工夫

はじめに

昨日、「ClaudeCode（SuperClaude）はまだまだ」と偉そうにダメ出ししておきながら、最後には「工夫して使い倒します」的な記事を書いたので、今日はどうやって工夫してるかを一部書いてみようと思います。みんな当たり前にやっていることかもしれません。

---

工夫している方法

1. コンテキストウィンドウをまたがない
2. タスクをなるべく小さくする
3. プロンプトの工夫

全体方針としては、「コンテキストをまたがない（圧縮させない）」ということ。１つのコンテキストウィンドウ内で完結することを目指しています。

コンテキストを圧縮すると、何かの情報が落ちて要約されるのですが、何の情報が落ちたのかわからないです。仕様を覚えているか不安だからもう一度読ませたりしたら、もしかしたら冗長かもしれない。そんなことをするくらいなら、クリア(/clear)から必要な情報のみを渡して進みたい。
そういう思いで方針を立ててます。

コンテキストをまたがないようにするため、タスクを小さくし、プロンプトを工夫してます。

順番に説明します。

1. コンテキストウィンドウをまたがない

またがないと言うのは、もうすっぱり過去は切り離します。

クリア(/clear)から、タスクや仕様書を読んで実装・テストを、一気にやります。そして次のタスクの時にはまたクリア。

終了(/exit)するときもあるけど、行動を承認し直さないといけなくてめんどくさいのでクリア。承認の作業を除けば、どちらでも同じ認識です。

2. タスクをなるべく小さくする

小規模でもシステム開発をする際には、ステップがあって、そのステップをなるべく小さくします。それを事前に、１つずつファイルへ出力しておいてもらいます。

コンテキストウィンドウを圧迫しないように、今必要なタスクのやることだけを見てもらうために、ファイルを別々にします。

これは/sc:workflowで仕様書から落とします。このファイルは、私は結構しっかり読みます。後で、Claude Codeにはこの仕様書を手に進んでもらうので。

3. プロンプトの工夫

指示の流れは、下記を１つのタスクごとに繰り返してます。クリア直後の"タスクの確認"が、特に重要だと思います。

1. タスクの確認
2. タスクを実行
3. 終了後の確認
4. 不具合の修正
5. 終了のドキュメンテーション
6. git操作
7. (そして/clear)

3.1. タスクの確認

クリア後なので、AIの頭は真っ白という状態からです。

私が使っているプロンプトはこんな感じ。（コードブロックにすると改行されず見づらいので引用で）

/sc:analyze "`CLAUDE.md`、`docs/specifications/*.md` をもとにシステムを構築している。
`docs/tickets`以下の[チケット](docs/tickets/TICKETS_LIST.md)のうち、T001, T002, T003, T004, T101, T401, T201, T402, T202, T103, T104, T203, T204を完了している。
次のチケットは[T301](docs/tickets/T301_api_books.md)である。必要なファイルを読み込み、チケットの概要と注意点を調べて。"

ポイントは、CLAUDE.mdと仕様書、TICKET_LIST.mdを都度読ませていること。CLAUDE.mdは、起動したりクリアしたら読むという話もありますが、よくわからないので指示しています。

3.2. タスクを実行

次は本丸の実装指示。短い指示ですが、事前にドキュメントを読んでから実装なので、大きくは外れません。

超荒く使うと、この文章だけでコーディングはしてくれるといえばしてくれる。

/sc:implement "[T301](docs/tickets/T301_api_books.md)を実装して"

3.3. 終了後の確認

念には念をというレベルではなく、テストコードを作るだけ作って実行していなかったり、buildをしていなかったりの状態で、「完成しました！次のステップはT302です！」的なことを大体言うので、確認させます。

ここでは、チェック対象は自分(ClaudeCode)がやったことなので全否定はしないものの、大体何かしらの問題が見つかります。

3.2や3.3で正常と言われたとしても、buildや動作確認は自分でも実施した方がよいです。

/sc:analyze "[T301](docs/tickets/T301_api_books.md)の実装が完了した。ドキュメントに記載されていることに抜け漏れや矛盾点がないことと、lintやbuild、テストに問題がないか確認して。"

3.4. 不具合の修正

タスクごとに不具合内容が違いますが、3.3の分析結果をもとに、大体こんな感じで修正してもらいます。

/sc:improve "次の内容を順にfixしてください。

1. 重要度:中の2件
2. 重要度:低の`process.exit()`とフォーマット
3. T301以外のNodeJS型未定義エラー"

3.5. 終了のドキュメンテーション

ここまでくれば大体完了です。
最後に、ドキュメント内に「やったよ」というチェックボックスを作っていたり、ステータス：TODOとか書いてあったりするので、それをメンテナンスしてもらいます。

/sc:document "T301は終了とします。下記を順に実行し、それぞれ報告してください。

1. ステータス更新: [T301](docs/tickets/T301_api_books.md)にステータスがあるので、DONEに更新して。
2. ドキュメント修正: ほかにも修正すべきドキュメント・修正すべき箇所を確認し、あったら修正して。
3. ドキュメント追記: 暫定的に対応したソースやあとで修正すべき残タスクがあったら、ドキュメントに追記してください。"

3.6. git操作

ブランチの扱いや確認を入れることがありますが、大体こんな感じ。Claude Codeがカレントディレクトリを移動しているときがある（でも見えない）ので、移動してと言います。これがないと、漏れたり、../../config/config.jsonといった変なパスを指定したりするときがあります。

/sc:git --smart-commit "[T301](docs/tickets/T301_api_books.md)が終了した。プロジェクトルートディレクトリに移動して、すべての更新ファイルをadd, commit, pushして。"

まとめ

こんな感じで工夫してますというお話でした。

これを、たくさんのタスクで繰り返し繰り返しやるので、「このプロンプトを順に出してくれるシステムがほしい！」ということで、Claude Codeを働かせている裏で、簡単なReactAppを作りました。そしたらまず楽になったし、前回のプロンプトがうまくいったかどうかでPDCAを回せるようになったので、さらにブラッシュアップしていきそうです。

ではよきバイブコーディング（with 人の工夫）を。