はじめに
AIコーディングツールの発展は凄まじいスピードで変化していて、GitHub Copilot、Claude Code、Cursor、Codexなど、次々と新しいツールが登場し、既存のツールも日々アップデートされています。
この記事では、2026年1月時点での私のAIコーディングサイクルをスナップショットとして記録します。
2025年11月に書いたときから2ヶ月経ったので、
2ヶ月分のアップデートしたものを作成しようと思います。
2ヶ月前からの更新
前回と重複する内容が多いのですでに前回の記事を読んだ方は以下の内容だけを掻い摘んで呼んでいただくのがいいかもしれません。
この記事を書く背景
- 振り返りのため: AIツールの変化は速いので、現時点でのスナップショットを残すことは、後から振り返っても面白い
- 頭の整理: 現状のやり方を書き出すことで、自分の思考を整理できる
- フィードバック: 他の人からのフィードバックをもらうことで、さらに改善できる
この記事で扱う範囲
おもに個人開発において、AIコーディングツールを活用した実践的な開発サイクルを紹介します。単にツールを使うだけでなく、品質を保ちながら効率的に開発を進めるための方法を共有します。
開発環境:安全なAIコーディング環境の構築
前回から更新しました。
AIコーディングツールを活用する前に、まず安全で効率的な開発環境を整えることが重要です。
私は、2025年11月時点ではDevcontainerをメインに使っていましたが、今はSandbox環境をメイン使うように変わりました。
Devcontainerの環境構築についても以前書いた記事があるので興味がある方はこちらを見ていただければと思います。
DevcontainerとSandboxの比較については別の記事を書こうと思いますが、一番大きいのは、
- Dockerをたてなくていいので軽い・早い
- Dockerのリソース制限にかからない
- Claude CodeのUser-scopeの設定を別々のプロジェクトで直接つかる
などがあります。
ただ、Sandbox環境は設定を調整しないと、pre-commit, gh, git, npm, uv などのコマンドが権限にひっかかり思うように実行できない事があるのでこの点は注意が必要です。
私は結構雑ですが、git, gh, uv, pre-commitなどは sandbox外から実行を許すようにしています。ここらへんはもうちょっと改善の余地はあると思います。
{
...
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"network": {
"allowedDomains": [
"github.com",
"*.github.com",
"api.github.com",
"npmjs.org",
"*.npmjs.org"
],
"allowUnixSockets": [
"/var/run/docker.sock"
],
"allowLocalBinding": true
},
"excludedCommands": [
"git:*",
"gh:*",
"pre-commit:*",
"npm:*",
"uv run mypy",
"uv run pytest"
]
},
...
}
AIコーディングサイクル概要
私の開発サイクルは以下の5つのフェーズで構成されています:
- Plan: GitHub Issueでの設計とArtifact化
-
Implementation:
- Slash Command/Agent活用による実装
- Codex webやClaude on the WebをSlack連携から呼び出し実装
- 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-1: Implementation - Slash Command/Agent活用
実装方針が決まったら、実際の実装に移ります。
事前準備:カスタムSlash Commandの作成
実装を効率化するために、以下のようなカスタムSlash Commandを事前に用意しておきます:
-
/resolve-gh-issue: GitHub Issueを読んで実装し、PRを作成
詳細はこちらにあります。
実装の流れ
/resolve-gh-issue #111
このように、Issue番号を指定するだけで、AIが以下を実行します:
- Issueの内容を読み取る
- 実装方針に従ってコードを書く
- 必要なテストを追加
- PRを作成
このアプローチにより、実装フェーズで毎回長いコンテキストを説明する必要がなくなります。
Phase 2-2: Codex web/Claude Code on the webのSlack連携活用
新たに取り入れた内容です。
これらのリモート開発環境の活用が進みました。
イメージとしては、Devinのような使い方をしています。
思いついた特定の小さい変更実装依頼を直接Slackから @Codex または @Claude をメンションしてリモート上で実装してもらっています。
このタスクにあってるのは、gh issueを作るほどではない、環境変数の設定や細かいBugの修正、簡単なロジック修正など、自分の頭の中で変更内容はかなり明確にわかっているようなタスクです。
Claude Codeを立ち上げるコンテキストスイッチングのオーバーヘッドが大きいようなタスクにこの実装方式を使っています。
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や人によるレビューコメントを受け取ったら、対応が必要なものを選別します。
複数あるレビュー・コメントの対応
/resolve-all-gh-review-comments <pr number>
- コメントの分類 (Resolved, outdated, valid)
- Outdatedのコメントは直接Resolve
- Validなコメントだけを対象にしてコメントのグルーピングを行う
- グループごとにユーザに方針確認 (
AskUserQuestionツールを使う) - 修正→コミット→プッシュ→コメントに返信:
/resolve-gh-review-comment(1コメントに対応するコマンド) をそれぞれに対して回す
こちらで紹介しています。（commandの全てはどこにも書いてないので、改善してからまた別途記事にしようと思っています。）
/resolve-gh-review-commentに関してはこちら:
Before: 以前まではGHのPRを開いてコメントを一つずつ確認して必要そうなものに対して、処理をClaude Codeからお願いするというのをやっていたのですが、コメントの数がふえてくるとかなり時間がかかっていました。
After: この仕組みを導入してから、自分が判断する必要あるコメントは、Validなものでグルーピングされたあとのものだけなので、格段に減りました。そして、一つずつ対応する必要がないので、時間短縮もできました。
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だけに頼らず、自動化ツールによるルールの徹底とコードの品質の向上