ブログとか
2025-07-20
暇だったので Claude Code をたくさん使ってみた。
たまたま暇していた時期にClaude Codeや Gemini-cliなどが出てきたので、1ヶ月半ほどいろいろ試してみた。
その結果、自分なりに効率的な開発ワークフローを考えたので、その経験をまとめる。
まずはChatGPTとアイデアや実現方法について議論する。
ここからClaude Codeを使用開始。
gemini-cliはあまり試していないが、だいたい同じことができそうだった。
プロジェクトディレクトリを作成してClaudeを起動する。
アーキテクチャ・言語・フレームワークなどを軽くプロンプトに書いて、PLAN.mdを作成させる。
docs/ディレクトリなどに、mermaidでアーキテクチャ図を作成させる。
mmdcコマンドで画像化する際は、scaleを調整すると見やすくなる。
ちなみに、こういう方法で実装する場合は、フロント・バックエンドが分かれていても、mono-repoの方が管理しやすいと思う。
重要なポイント： 無駄にダラダラと書かせず、抽象的な基本方針や基本機能を簡潔に書かせること。将来的な拡張について触れても構わないが、簡潔に留める。
スカスカでも構わないので、ビルド・起動できるアプリケーションを作成する。
index.htmlだけでも可Dockerfileやcompose.yamlまで含めるWeb Application FrameworkやDBアクセスなど、影響の大きいライブラリ・フレームワークはこの段階で導入しておく。
.dockerignore, .gitignore も忘れずに。
変なファイルをコミットしないようにするのは自分の責任。
クラウド上での動作が前提のアプリケーション（ローカルでは動作再現が困難）の場合は、早期に全ワークロードをデプロイできる環境を整備。
Cloud Run だけなら shellscript一発でもいいかもしれないし、 AWSで、いろいろ連携させるならTerraform、Pulumiなどを使用したりなど。
GitHub Actionsを使うのも良いと思う。
（ただ、Rustとかのビルドはキャッシュを工夫しないと重いため、個人プロジェクトではローカルビルドのスクリプトの方が便利な場合もある。）
素早く回せる方法のほうがいい。
PLAN.mdやアーキテクチャ図を読ませ、TODO.mdを作成。
効率的になるように順序を考えて書かせるが、手動で入れ替えてもいい。 例えば自分はこういう感じの順序にしている。
MVP思考が重要： 普通に依頼すると、一つ一つのタスクで、個々の実装完璧に仕上げようとしがちだが、必要最小限の機能実装を心がける。
横展開的な実装は後からいくらでも可能。
連携が必要な部分は、先に最小限の実装を行い、後は追加するだけで機能が増える状態を作る。
ローカルで動作確認後、デプロイスクリプトでデプロイして本番環境での動作も確認。
ドキュメントのメンテナンス： PLAN.mdやTODO.mdは、完了した項目や不要になった内容を定期的に削除することも重要。古い情報が残っていると、AIが混乱する原因になる。
GitHubのissueを作成。
注意： 普通にやらせると無駄に長く細かく書きがちなので、簡潔に書かせることが重要。
全てはコンテキストマネジメントのため。人間にとっても読みやすい。
ユーザーレベルのCLAUDE.mdに、issue対応のガイドラインを記載しておくと効果的です。
## Issue-based task guidelines
- One pull request should usually resolve one cycle, unless combining cycles is more efficient.
- Always create a feature branch before starting issue work, never work directly on main branch.
- All issue-related changes must go through Pull Request workflow:
1. Create feature branch: `git checkout -b feature/issue-description`
2. Make changes and commit
3. Push feature branch: `git push -u origin feature/issue-description`
4. Create PR via `gh pr create`
5. Merge PR after review/approval
- When you work on an issue, create a feature branch if not exists it, work on the branch, commit changes as unit easy-to-understand, push them if you think your commits solve the issue, and create a PR.
issueやPRでは必要な情報を簡潔に記載させる。AIは隙あらばダラダラと長く、大げさにアピールするような文章を書こうとするので要注意。
酷いときは、嘘すらつく。
GitHubリポジトリの設定で、PR作成時に自動的にCopilotがレビューを開始するよう設定しておくと便利。
Copilotに任せることもできるが、ざっくりでも人間がレビューすることが重要。見当違いなことを実装している可能性もある。
理解できない部分があれば、AIに説明させれば良い。
このワークフローの最大のポイントは、AIの長文生成癖をコントロールしながら、段階的に確実に開発を進めることにある。
方針をコントロールするために、ざっくりとした設計(PLAN.md)を書かせることで、認識のズレを防ぐ。
TODO.md を作成するのは、issueを書かせる前に、チェックしたり、手動で順序を入れ替えたりするため。
issue 単位でやれば、複数のissueを同時に進めることも可能だし、レビューもしやすい。（ここは人間の場合と同じ）
レビュー時に理解できない部分があれば、AIに説明させれば良い。
しかし、AIが大げさな長文を好むのは、なんでだろう。
インターネットのどこかで、薄い内容を無駄にダラダラと引き伸ばして、ショボい内容を過剰にアピールするような文章が称賛されているのかもしれない。