AI駆動開発を「フィードバックで育つ仕組み」にする

AIを使って開発を進めていると、以前よりもずっと速くシステムを作れるようになりました。

一方で、複数の案件やサービスを並行して進めていると、少しずつ別の課題も見えてきます。

たとえば、

• 前にも似たようなミスがあった
• 別のプロジェクトでも同じことを調べている
• 一度レビューで指摘した内容を、AIがまた繰り返している
• プロジェクトごとにルールが少しずつ違ってきた
• 「なぜこの設計にしたのか」が後から分からなくなる

といったものです。

AIが便利になるほど、こうした「小さな学び」をどう残すかが、以前より重要になってきたように感じます。

そこで考えたいのが、開発するたびに少しずつ学習していく仕組みです。

AIだけが賢くなるのではなく、開発環境そのものを育てる

AI駆動開発というと、

「もっと良いプロンプトを書く」
「AIモデルを使い分ける」

といった話になりがちです。

もちろんそれも大切ですが、長期的にはもう一段上の考え方が必要です。

それが、

今回の開発で得た気づきを、次の開発に残す

ということです。

例えば、あるプロジェクトで

「マルチテナント環境なのに、データ取得時のテナント条件が抜けていた」

という問題が見つかったとします。

その場でコードを修正すれば、ひとまず問題は解決します。

ただ、それだけでは別のプロジェクトで同じ問題が起こるかもしれません。

そこで、

1. 何が起きたのか
2. なぜ起きたのか
3. 今後どう防ぐのか

を簡単に残しておきます。

すると、単なる「修正」が「組織としての学習」に変わります。

フィードバックをためる場所を作る

こうした情報を残す場所として、GitHubはかなり使いやすいと思います。

コードと近い場所に置けますし、人間だけでなくAIからも参照しやすいからです。

例えば、会社共通のリポジトリとして、

engineering-knowledge/

├── principles/
├── patterns/
├── failures/
├── playbooks/
└── agent-rules/

くらいのシンプルな構成から始めてもよいでしょう。

それぞれの役割は難しく考えなくても構いません。

principles

開発全体で大切にする考え方です。

例えば、

• セキュリティを後回しにしない
• 権限チェックは必ずサーバー側でも行う
• 変更しやすい構造を優先する

といったものです。

patterns

「こうすると上手くいきやすい」という実装パターンです。

例えば、

• APIのエラー処理
• 認証・認可
• ログ出力
• DBトランザクション
• バックグラウンド処理

などです。

failures

ここが特に重要です。

実際に起きた問題や失敗を記録します。

失敗というと少し重く聞こえますが、

「次回のための気づき」

くらいの感覚でよいと思います。

例えば、

事象:
APIで権限チェックが不足していた

原因:
フロント側で制御していたため、
API側の確認が抜けていた

対応:
API側でも権限チェックを行うよう修正

今後:
APIレビュー時の確認項目に追加

くらいでも十分です。

大事なのは「記録すること」ではなく「次に活かすこと」

ここで注意したいのは、ドキュメントを増やすこと自体が目的にならないことです。

よくあるのが、

「ルールをたくさん書いたけれど、誰も読まない」

という状態です。

AIに読ませる場合も同じで、情報を大量に与えれば良いわけではありません。

むしろ重要なのは、

学びを少しずつ仕組みに変えていくこと

です。

例えば、

「このミスに気をつける」

という記録があったとします。

最初はそれだけでも構いません。

ただ、同じ問題が何度も起きるのであれば、

気づき
↓
開発ルール
↓
レビュー項目
↓
テスト
↓
自動チェック

というように、少しずつ強い仕組みにしていきます。

「気をつける」から「起こりにくくする」へ

例えば、

「テナントIDを付け忘れない」

というルールを作ったとします。

人間にもAIにも、

「必ずテナントIDを確認してください」

と伝えることはできます。

ただ、人間もAIも忘れることがあります。

そこで、

• 共通Repositoryで自動付与する
• テストを書く
• CIでチェックする
• 静的解析で検出する

といった仕組みに変えていきます。

すると、

「注意してください」

だったものが、

そもそも間違えにくい開発環境

へ変わっていきます。

この考え方は、AI駆動開発では特に重要だと思います。

人間とAIが同じ知識を見る

この仕組みの面白いところは、人間だけのマニュアルにする必要がないことです。

現在のAI開発ツールでは、

• AGENTS.md
• CLAUDE.md
• GitHubのInstructions
• AI Skills
• Hooks

などを使って、開発時のルールや知識をAIに渡すことができます。

そのため、

人がレビューで気づく
        ↓
フィードバックを残す
        ↓
共通ルールを更新する
        ↓
AIも次回から参照する

という流れを作れます。

つまり、

人がAIを教え、AIが次の開発でその知識を使う

という循環です。

プロジェクトごとに全部コピーしない

もう一つ重要なのが、共通知識と案件固有知識を分けることです。

例えば、

会社共通

・セキュリティ
・テスト
・API設計
・DB設計
・ログ
・認証認可

は共通知識として管理します。

一方、

案件A

・この案件特有の業務ルール
・特殊なデータ構造
・顧客固有の制約

は各リポジトリで管理します。

全部を1つの巨大なファイルに入れてしまうと、人にもAIにも扱いづらくなります。

そのため、

普段必ず守るルールは短く

詳しい知識は必要なときに参照する

くらいの分け方が扱いやすいと思います。

GitHub Issueを「気づき箱」にする

最初から大掛かりな仕組みを作る必要はありません。

GitHub Issueに、

改善フィードバック

発生したこと:
原因:
他案件でも起こりそうか:
今後どうするか:

というテンプレートを1つ用意するだけでも始められます。

そして、

「これは他のプロジェクトでも起こりそうだな」

と思ったものだけ、共通知識へ移します。

全てのミスを記録する必要はありません。

大切なのは、

再発する可能性があるものを残す

ことです。

開発するほど、次の開発が少し楽になる状態を作る

理想は、次のような循環です。

開発する
   ↓
レビューする
   ↓
問題や改善点が見つかる
   ↓
フィードバックとして残す
   ↓
ルール・テスト・仕組みに反映する
   ↓
AIも人も次回から利用する
   ↓
次の開発品質が上がる

1回の改善は小さいものです。

ただ、10案件、20案件と積み上がってくると、大きな差になります。

以前のプロジェクトで悩んだことを、次のプロジェクトでゼロから考えなくてよくなります。

AIも同じです。

毎回まっさらな状態から開発させるのではなく、

これまで会社として学んできたことを渡した状態からスタートする

ことができます。

AI駆動開発では「学習する組織」がより重要になる

AIによってコードを書く速度はかなり速くなりました。

だからこそ今後は、

「どれだけ速くコードを書けるか」

だけでは差がつきにくくなるかもしれません。

その代わり、

• 過去の失敗をどれだけ活かせるか
• 共通化できるものをどれだけ増やせるか
• 品質をどれだけ仕組みにできるか
• AIにどれだけ良い知識を渡せるか

といった部分が重要になっていくと思います。

AI駆動開発を単なる「高速開発」にせず、

開発するたびに少しずつ賢くなる仕組み

として育てていく。

そのための第一歩として、

「今回の開発から、次回に残せるものは何だろう？」

と考える習慣を作るだけでも、かなり違ってくるのではないでしょうか。