AI駆動開発で使用している原則・法則
AI駆動開発を始めると、生成されるコードの品質管理が最初の悩みとして挙がるかと思います。ユーザー本人が想定していない低品質なコードが量産されてしまって、リファクタリングに追われてしまいがちです。
これは、ソフトウェア開発において提唱されている原則や法則を使用すればある程度緩和されるものかと思っています。一例として、自分が意識していることを残しておきます。
MVP
昨今は仕様駆動開発が提唱されたりと設計に対する意識が高まっているようです。ところが、AIに設計書を生成させても、AIの提案する設計のスケールがでかすぎて、ユーザーが想定したスコープと一致しないという問題に直面します。
これはおそらくAIエージェントがユーザーから渡されたタスクが3日で終わらせるべきものなのか、30日かけて行うべきなのかを判断できないからなのではないかと思っています。期間が指定されない場合、AIは完璧を目指していってオーバーエンジニアリングになり、タスクに対して想定外の巨大なコードを生成してしまうということが起こってしまいます。
私は設計の際にMVP（Minimum Viable Product）を意識するように言っています。プロンプトに「MVP」を入れるだけでそれがMinimum Viable Productだということは文脈から認識できるようです。先ほど期間の話をしましたが、MVPを指定すると最小限の実装だと期間を短く実装しようとするので、オーバーエンジニアリングが緩和されるかと思います。
似たものにYAGNI原則（You aren't gonna need it）があり、エンジニアの間の方がこちらの方が普及している印象ですが、設計のスケールを抑えるという点においてはMVPの方が有効だと感じます。
Miller/KISS
設計書を作成すると、AIは疑似コード(Pseudocode)を生成します。この疑似コードを自己レビューしてイメージが固まったら実装を始めるのですが、疑似コードを確認すると何だか読みづらかったり、動作はしそうだが想定とは違う実装になっているということが良くあります。
こういった場合はコードが認知負荷が高い状態になっているので、Millerの法則（マジカルナンバー7±2）とKISSの原則（Keep it simple stupid.）を使用するようにしています。「Miller/KISSの観点で設計書をチェックして」というようなことを良く言っています。
Millerの法則を使用しているのは、1つメソッドに対して異様に責務が詰め込まれていたり、SRP（single responsibility principle）を守ろうとするあまりメソッドが細かく分かれすぎてどこで何をしているのかを追えなくなるという状況が発生するからです。Millerの法則を使用して認知負荷が考慮に入れることで自己レビューとリファクタリングの負荷を下げるアプローチをしています。
KISSの原則を使用しているのは、簡潔なタスクに対して疑似コードが妙に小難しいことをしているというケースが少なくないからです。疑似コードをKISS観点で見直すと既存の実装の存在に気付いて、シンプルな実装にするために統合するというような動作を良くします。
法則・原則の情報収集
法則・原則について知識がないという人が居るかと思いますが、AIに「〇〇について提唱者がいるような原則や法則を、提唱者とともに列挙してください。」というようなことを聞くことから始めると良いと思います。
例えば「ユニットテストについて提唱者がいるような原則や法則を、提唱者とともに列挙してください。」というと以下のような回答をします。
ユニットテストに関する主要な原則や法則を提唱者とともに紹介します。
FIRST原則
提唱者：Michael Feathers
- Fast（高速） - テストは素早く実行されるべき
- Independent（独立） - テスト間に依存関係があってはならない
- Repeatable（反復可能） - どの環境でも同じ結果が得られるべき
- Self-Validating（自己検証） - テストの結果は明確であるべき
- Timely（適時） - プロダクションコードの直前または直後に書かれるべき
3つのA（AAA）パターン
提唱者：Bill Wake
- Arrange（準備） - テストデータとオブジェクトを準備
- Act（実行） - テスト対象のメソッドを実行
- Assert（検証） - 期待する結果を検証
Given-When-Then
提唱者：Dan North（BDD提唱者）
- Given（前提条件） - テストの前提条件を設定
- When（実行） - 特定のアクションを実行
- Then（結果） - 期待する結果を検証
テストピラミッド
提唱者：Mike Cohn
ユニットテスト（基盤）> 統合テスト（中間）> E2Eテスト（頂点）の比率でテストを構成する概念テスト駆動開発（TDD）の法則
提唱者：Robert C. Martin（Uncle Bob）
- 失敗するユニットテストを成功するまで書いてはならない
- コンパイルエラー以上に失敗するユニットテストを書いてはならない
- 現在失敗しているユニットテストを成功させる以上にプロダクションコードを書いてはならない
Right-BICEPの原則
提唱者：Andy Hunt & Dave Thomas
- Right（正しい） - 結果は正しいか
- Boundary conditions（境界条件） - 境界条件を満たしているか
- Inverse relationship（逆の関係） - 逆の関係をチェックできるか
- Cross-check（相互チェック） - 他の手段で結果を相互チェックできるか
- Error conditions（エラー条件） - エラー条件を強制できるか
- Performance characteristics（パフォーマンス特性） - パフォーマンス特性は合理的か
単一責任の原則（テスト版）
提唱者：Robert C. Martin
1つのテストは1つの理由でのみ失敗すべきという原則これらの原則は、保守性が高く信頼できるユニットテストを作成するための指針として広く採用されています。
最初はAIが回答した有名な原則・法則を盛り込むことから出発して、開発を通して有効性を検証しながらプロンプトを改善していくのがAI駆動開発の基礎なのかなと最近は考えています。AIはコンテキストが一定以上になると精度が下がっていくため、知っている限りの法則や原則を詰め込むのではなく、自分のタスクに対して最低限のプロンプトが何なのかを掴むのが大切かと思います。
Discussion