はじめに
AIコーディングツールの発展は凄まじいスピードで変化しています。GitHub Copilot、Claude Code、Cursor、Codexなど、次々と新しいツールが登場し、既存のツールも日々アップデートされています。
この記事では、2025年11月時点での私のAIコーディングサイクルをスナップショットとして記録します。
この記事を書く背景
- 振り返りのため: AIツールの変化は速いので、現時点でのスナップショットを残すことは、後から振り返っても面白い
- 頭の整理: 現状のやり方を書き出すことで、自分の思考を整理できる
- フィードバック: 他の人からのフィードバックをもらうことで、さらに改善できる
この記事で扱う範囲
おもに個人開発において、AIコーディングツールを活用した実践的な開発サイクルを紹介します。単にツールを使うだけでなく、品質を保ちながら効率的に開発を進めるための方法を共有します。
開発環境:安全なAIコーディング環境の構築
AIコーディングツールを活用する前に、まず安全で効率的な開発環境を整えることが重要です。
私は、現在、主にDevcontainerを使って開発しています。
詳細なDevcontainerの環境構築については、以下の記事を参照してください:
最近では、Claude CodeやCodexなどのツールにSandbox環境が導入されていますが、完全にはキャッチアップができていないため、Devcontainerをメインで使っていますが、将来的にはSandbox環境への移行も検討しています。（一部ではSandboxを使っています。）
Sandboxに移行すると得られそうなメリット
- Dockerを立ち上げなくて済むためローカルPCのリソース使用量を気にしなくていい
- devcontainerの設定自体が不要
- localの設定 (~/.claude/ 以下のcommands, agents, skillsなど)をそのまま使える
今後、検証して開発環境の更新をしようと思います。
AIコーディングサイクル概要
私の開発サイクルは以下の5つのフェーズで構成されています:
- Plan: GitHub Issueでの設計とArtifact化
- Implementation: Slash Command/Agent活用による実装
- Review: 多層的なAIレビュー
- Resolve Review: レビュー対応の自動化
- 品質保証: AIに頼りすぎない仕組み
Phase 1: Plan - GitHub Issueでの設計
AIを使ったIssue作成
開発を始める前に、まずAIを使ってGitHub Issueを作成します。Jiraなどのチケット管理ツールでも同様のアプローチが可能です。
AIに以下の内容を調査・記述してもらいます:
-
現状のコードから関連部分の調査
- 問題が発生している箇所の特定
- 関連するコードの構造分析
-
一般的な情報の収集
- ベストプラクティス
- 類似のイシューの解決方法
- 関連するライブラリやフレームワークの情報
-
問題の根源の特定
- なぜこの問題が発生しているのか
- 根本原因は何か
-
実装方針の提案
- どのようなアプローチで解決するか
- 複数の選択肢がある場合は比較
Plan Artifactのメリット
このアプローチは、いわゆる「Plan」フェーズとほぼ同じですが、GitHub Issueなどに書き出すことで以下のメリットがあります:
- Planのartifact化: 後から参照しやすい形で記録が残る
- コンテキストの整理: 実際の実装フェーズで使うコンテキストを綺麗に整理できる
- チーム共有: 他のメンバーとも簡単に共有できる
- 議論の場: Issue上でディスカッションができる
人間によるレビュー
AIが作成したIssueに目を通し、自分の考えた方向性と一致しているか確認します。必要に応じて修正や追加を行います。
Phase 2: Implementation - Slash Command/Agent活用
実装方針が決まったら、実際の実装に移ります。
事前準備:カスタムSlash Commandの作成
実装を効率化するために、以下のようなカスタムSlash Commandを事前に用意しておきます:
-
/resolve-gh-issue: GitHub Issueを読んで実装し、PRを作成
詳細はこちらにあります。
実装の流れ
/resolve-gh-issue #111
このように、Issue番号を指定するだけで、AIが以下を実行します:
- Issueの内容を読み取る
- 実装方針に従ってコードを書く
- 必要なテストを追加
- PRを作成
このアプローチにより、実装フェーズで毎回長いコンテキストを説明する必要がなくなります。
Phase 3: Review - 多層的なAIレビュー
実装が完了したら、複数のツールを使ってレビューを行います。
ローカルでのレビュー
多くのAIコーディングツールにはreviewコマンドがあるのでローカルでレビューコマンドでレビューします。 (実際そこまで使ってないですが)
/review
GitHub PRでのレビュー
GitHub PR上では、複数のAIツールを活用します:
- GitHub Copilot
- Claude Code GitHub Actions
-
Gemini Review:
/gemini reviewコマンドで実行 (個人的なおすすめ✅️) - Codex (個人的なおすすめ✅️)
複数使えばいいというものではないと思いますが、複数のAIが同様の指摘をしてきたら、流石に直したほうがいいよなとか、Suggestionを比較して異なるアプローチがあるのかなど検討材料に使うことができます。
ChatGPT Plus (20USD)を契約していれば、Reviewが現在は無料でいくらでもできるのめちゃくちゃコスパがいいと思っています。 すべてのレポジトリで自分のPRをレビューしてもらう設定ができます。たった月20ドルですべてのPRレビューお願いできるとか個人開発では最高の贈り物だと思います。
/gemini reviewは無料ですぐに使える＆結構Reviewが的確で役に立っています。
参考: https://developers.google.com/gemini-code-assist/docs/review-github-code
レビュー観点の事前定義
AIツールを有効活用するために、レビュー観点を事前に定義しておくことが重要です。
.github/copilot-instructions.mdの例:
# Code Review Guidelines
## Clean Architectureの原則に従っているか
### 依存関係の方向性
- [ ] 内側のレイヤー（Domain/UseCase）が外側のレイヤー（Infrastructure/Presentation）をimportしていないか
- [ ] Repository実装（Infrastructure）がDomain層のinterfaceを実装しているか（逆ではない）
- [ ] UseCaseが具象クラスではなくinterfaceに依存しているか
- [ ] DIコンテナやコンストラクタインジェクションで依存を注入しているか
...
設計上の観点などを具体的に記述しておくことで、AIが効果的にレビューできるようになります。
プロジェクトごとにカスタマイズする必要があります。
肌感としては、「Clean Architectureの原則に従っているか」のような抽象的なチェック項目よりも
## 依存関係の方向性
- [ ] 内側のレイヤー（Domain/UseCase）が外側のレイヤー（Infrastructure/Presentation）をimportしていないか
- [ ] Repository実装（Infrastructure）がDomain層のinterfaceを実装しているか（逆ではない）
- [ ] UseCaseが具象クラスではなくinterfaceに依存しているか
- [ ] DIコンテナやコンストラクタインジェクションで依存を注入しているか
のように具体的なチェックリストを具体的に白黒つけやすい項目にしておくほうがレビューが的確になります。
こういった点も、Claudeに聞いて書き出してもらったものを参考にするとカバーしやすくなります。
あとの章で書きますが、実際はLLMに頼らずチェックできる部分はカスタムリントルールやスクリプトを整備するほうが、更に効率が良くなります。
Phase 4: Resolve Review - レビュー対応の自動化
AIや人によるレビューコメントを受け取ったら、対応が必要なものを選別します。
複数あるレビュー・コメントの確認
/check-gh-review-comments <pr number>
このコマンドを使って、今あるレビュー・コメントを以下に分類して、現在有効なコメントだけに絞って対応するものを明確にします。
- valid: 有効
- outdated: コードが更新されて古いコメント
- fixed: すでに対応済み
詳細はこちらで紹介しています。
レビューコメントの解決
/resolve-gh-review-comment <GitHub review comment URL>
このコマンドで、指定したレビューコメントに対する修正を自動で実施します。
AIがレビューした際は、どのように変更するべきかセットで提案されているケースが多いので、修正すると決めたら、あとはAIにお願いします。
詳細はこちらをご参照ください。
人間の判断
すべてのAIツールのレビューコメントを自動で解決するのではなく:
- レビューコメントに目を通す
- 修正が必要かどうか判断する
- 必要なものだけAIに解決してもらう
このプロセスにより、適切な品質を保ちながら効率的に開発を進められます。
Phase 5: 品質保証 - AIに頼りすぎない仕組み
AGENTS.md/CLAUDE.mdの限界
プロジェクトルートにAGENTS.mdやCLAUDE.mdなどのファイルを置いて、AIへの指示を記述することができます。しかし、これらの指示は:
- 忘れられることがある: 長い会話の中で無視されることがある
- 解釈が曖昧: 人間が読んでも解釈が分かれる内容は、AIも理解できない
- コンテキスト制限: 大量の指示を書いても、すべてを考慮できるわけではない
など、徹底させることは不可能だと思います。（少なくとも2025年11月現在では。）
そのために、従来の静的解析、スクリプト、linter、formatterなどの整備・活用が重要になると思います。
自動化ツールの整備
複数人でコードを管理する上では、LLMだけに頼らず、以下のツールを整備することが重要です:
pre-commit
pre-commit を活用することで、各Commitの品質を向上させることができます。
ただし、AIコーディングツールは、pre-commitすらも回避してくるので、そのための設定も大事です。
私は AIエージェントによる git commit --no-verify を完全に防ぐ方法 の記事の方法を設定して、AIコーディングツールの回避を防いでいます。
Lint & Test
ここは特に言うまでもありませんが、各プロジェクトの言語やフレームワークに合わせたlint&testを整備しておくことが大事です。
CI/CDでの品質チェック
（こちらも新しい話はないので割愛しますが、）GitHub Actionsなどを整備しておきます。
- Lint
- Test
- セキュリティスキャン
- カバレッジチェック
毎回新規プロジェクトごとに設定をすると、（AIコーディングツールにお願いして作るにしても）時間がかかるし、レポごとの設定がバラバラ担ってしまうので、GitHub Template Repositoryを言語ごとに作成して、プロジェクト開始時点で常に、必要な設定が適用されている状態にしています。
カスタムリントスクリプト
私が最近やっているのは、CLAUDE.mdやAGENTS.mdに書いていても徹底されないルールを、Scriptやカスタムリントとして、自動チェックに入れ込むことです。
例えば、上のAIレビューツールのプロンプトの例で言えば、以下のようなルールを書いていてもAIが毎回完全に一つも見逃さずにレビューで弾けるわけではありません。
- [ ] 内側のレイヤー（Domain/UseCase）が外側のレイヤー（Infrastructure/Presentation）をimportしていないか
そのため、こういった観点もスクリプトやカスタムリントルールにして、 「domainが定義されてるディレクトリ以下のコードが、infraのパッケージをインポートしてるかどうか」をチェックできるようにしてCIに組み込むことで、AIのレビュー観点を減らしていけます。
これらのスクリプトやカスタムリントルールをAIコーディングツールに生成してもらうことで、ルールを徹底させ、一貫性のあるコード品質を保つことができるようになります。
AIのレビュー観点は、自動チェックができないものに絞っていくことで、AIのレビューによる精度も自然と上がってきます。
AIと自動化ツールの使い分け
- AI: 設計レビュー、ロジックの妥当性チェック、改善提案など
- 自動化ツール: フォーマット、基本的なエラーチェックにプラスしてカスタムリントルールやスクリプトを使い、設計レビューや今まで暗黙的にレビューしていたものを言語化・ツール化して自動チェックでカバーできる部分を増やしていく
この組み合わせにより、高い品質を維持しながら効率的に開発できます。
まとめ
このAIコーディングサイクルで以下のメリットを享受できていると思います。
- 設計品質の向上: Planフェーズでの十分な検討
- 実装スピードの向上: Slash Commandによる効率化
- レビュー品質の向上: 複数のAIツールによる多角的なレビュー
- 保守性の向上: LLMだけに頼らず、自動化ツールによるルールの徹底とコードの品質の向上
今後も引き続き、開発サイクルの改善をしていきたいです。
直近では、以下をもっと有効活用できないか模索していこうと思っています。
- Sandbox環境
- Coderなどのリモート開発環境
- Codex/Claude Code on the web
- Cursor
また半年後か1年後くらいに、AIコーディング開発サイクルを書き出してみると全然違うものになっていて面白そうだなと今から期待しています。