ClaudeCodeで同じ轍を踏まない仕組みを作る

この記事のまとめ
AIコーディングエージェントの使い道は開発や日々の業務効率化だけじゃない！
自分の弱点リストを作ってもらい、克服するまで尻を叩いてもらいましょう！

はじめに

ClaudeCodeなどのAIコーディングエージェントを使ったバイブコーディング（vibe coding）が普及してきました。
実装は格段に早くなりましたが、レビューに関してはまだ人間の目を通すことが多いです。実際ClaudeCodeに全任せしたアプリはセキュリティがイマイチだったなんて話も耳にします。

そのため、エンジニアに求められる能力としてAI書いたコードが問題ないかを見極める力が挙げられます。

一方で私は残念ながらまだそのレビュー力が全然足りてないと感じてます！！！（泣）
AI書いたコードをセルフレビューでヨシッしてしまい、PR上で他エンジニアの方にたくさん修正コメントをいただくこともしばしば…

おそらく↑みたいな状況の人は私以外にいそうだな〜と思い、今回は同じ轍を踏まないようにする仕組み作りをした話をします。

想定読者

• バイブコーディングでのミスが減らない人
• バイブコーディングを通して技術を学びたい人

私と私の環境

• エンジニア歴4年（バックエンド多め、フロントも触る）
• 現職は入社1年経過
• 2025年8月よりClaudeCode利用開始

レビューコメントから学ぶ

AIが台頭する前からですが、PRレビューで指摘いただいたコメントをNotionなどのドキュメントにメモして定期的に見直すようにしていました。
今後同じようなミスをしないように学習することが目的です。

しかし、それでもたまに同じミスを再度犯してしまうことがあります。その時にレビュアーの方に同じ指摘をさせてしまうのが申し訳なさすぎて申し訳なさすぎて申し訳なくなります。（「前にも言いましたよね？」とは言わず優しく指摘してくださる方々が多く感謝の極みです。。。！）

AIを使ったバイブコーディングでの実装をセルフレビューする際、ほとんどのコードが初見レビューになり、認知不可も高く同じミスの再犯率が高くなってしまいます。

これをなんとか防ぎたいと思い、後述の仕組みを整えました

①自身の過去PRの指摘を収集する

Githubの自身のPRのうちRequest ChangeになったPRについた指摘コメントを収集し、チェックリストを作成するskillsを作成しました

my-pr-review-survey/SKILL.md

---
name: my-pr-review-survey
description: >
  devmatsuko の過去PRで受けた Request Changes レビュー指摘を調査し、
  claudedocs/pr-review-feedback-summary.md にまとめるスキル。
  「PRレビュー調査」「PR survey」「レビュー指摘調査」「PR指摘まとめ」
  「レビューフィードバック」等のキーワードで起動する。
  定期的にPRを調査してドキュメントを更新したい場合にも使う。
---
詳細は略

こちらのskillでは下記の手順で指摘コメントを収集しています

1. 前回調査した最新PRの番号と調査日が保存されている状態ファイル claudedocs/.pr-review-survey-state.json を確認する

   .pr-review-survey-state.json

   {
     "last_surveyed_pr_number": 32094,
     "last_survey_date": "2026-03-09",
     "total_prs_surveyed": 400
   }
   

2. gh CLIを使ってlast_surveyed_pr_number より新しいPRを調査し、途中で CHANGES_REQUESTED があったものを抽出する

3. Request Changes があったPRについて、自身とAI(bot)以外のコメントを取得する

②セルフレビュー用のチェックリストに過去の指摘を追加する

①で収集した指摘はカテゴリ別に分類され、 claudedocs/pr-review-feedback-summary.md にまとめられます。
pr-review-feedback-summary.mdには各カテゴリごとに、どのPRで誰からどんな指摘をもらったかを下記のようなフォーマットで記録していきます。

pr-review-feedback-summary.md

## 1. 命名規則・ファイル名

### PR #12345: HogeMenuの実装
**指摘者**: reviewer-name
**指摘内容**: `HogeMenu`コンポーネントの`Hoge`という呼称が他の同一機能コンポーネント
（`FugaMenu`, `FugaList`）と整合していない
**教訓**: 新しいファイル/コンポーネント/関数を作る際は、
既存の命名パターンを必ず確認し、「何をする/何のため」が名前から読み取れるようにする。

上記のような指摘を「命名規則・ファイル名」のようにカテゴリ分けし、新しい種類の指摘があれば自動でカテゴリが追加されます。
こうしてPR作成前のセルフレビューリストが完成します。

pr-review-feedback-summary.md

## チェックリスト（PR作成前の確認用）

### 命名・コメント
- [ ] 命名規則: 既存のパターンに合っているか？PascalCase等のルールを守っているか？
- [ ] hooks名: 責務が名前から読み取れるか？

### 設計・アーキテクチャ
- [ ] ビジネスロジック: UIコンポーネントにビジネスロジックが混入していないか？
- [ ] ドメイン知識の漏れ: hooksに寄せるべき判定ロジックがコンポーネント側にないか？

...

このチェックリストは「自分が実際に指摘を受けたこと」だけが並んでいるので、効率よく弱点を潰せます。
しかし、PR提出前に毎回手動でチェックリストと差分を照合するのは正直しんどいので、セルフレビュー用のskillにpr-review-feedback-summary.mdを参照させてチェックして貰うのがオススメです！

SubAgentにpr-review-feedback-summary.mdを参照させて違反したらめちゃくちゃ叱ってくれるようにするのもありだと思います。

何にせよ自身が過去に受け取った指摘、弱点リストを作っておくと今後いろんなことに活用できそうです！💪

おわりに

バイブコーディングの時代は「コードを書く力」よりも「コードを見極める力」が重要になります。

とはいえレビュー力は一朝一夕では身につかないので、自分の弱点を仕組みで補うこともまた重要になります。

今回紹介した仕組みをまとめると

1. 過去の指摘を自動収集してmdファイルに蓄積する
2. 蓄積した指摘をAIに読ませてセルフレビューさせる
3. このサイクルを回すことで同じミスの再犯を防ぐ

完璧なレビューはできなくても、「少なくとも前と同じミスはしない」状態を目指せたり、バイブコーディングを通して学びを得ることもできます。

最後まで読んでいただきありがとうございます！
同じ悩みを抱えている方の参考になれば幸いです〜🙏