第二回:AI駆動開発までのみちのり

前回のまとめ

私は約2年間、AIを活用した個人開発を続け、最終的に「AI駆動開発」というスタイルに辿り着きました。しかし、その先に待っていたのは機能追加のたびにバグが増え続けるという問題でした。このままでは開発が破綻すると感じ、開発手法そのものを見直すことになりました。

AI開発を行なった過程でどうしてこのように壊れ始めたか考えた結果以下の要因が挙げられます。

DocDD（Document Driven Development）とは、

ドキュメントを一次情報とし、コードはそれに従属させる開発手法

です。以前は正体となるものが存在しなかったことで煩雑なシステムが生まれました。反省としてまず正体を作成する設計手法に切り替えました。

この設計手法を参考に私は次のような運用に変更しました。

これにより、仕様と実装の乖離を検出できるようになりました。

従来は評価をせずコードを正しいものとして扱っていました。このため、下記のような評価フローを実装し、設計に評価を組み込みました。

ここで重要な点は人間が評価方針及び最終評価を担うと言うことです。いくら仕様を設定してもシステムを考えているのは人間のため、何をするのかは人間が判断するべきです。

以前はドキュメント作成もAIに任せていました。ただ複雑なシステムになればなるほど、図を見ても仕様を見ても構造が把握できない状況に陥りました。

そこで最初のシステムフローは必ず人間が書くように変更しました。現在はdraw.ioを使用しています。draw.ioは下記のような点で相性がいいです。

AIにすべて任せてしまうと、問題の発覚は最後にしか発覚せず、この場合修正するコストは高くなってしまいます。

これを解決するため、Human-in-the-Loopを取り入れました。これは

AIの処理プロセスの中に、人間の判断を組み込む設計思想

です。今回のAI駆動開発では開発途中で人間が確認を行うステップを挟みました。これにより大規模な作り直しが減り、修正が局所化されるようになりました。

実際に使用するAIと開発工程は以下となります。

私は主に3つのAIツールを利用しています。

実際の開発手順は下記となります。人間が確認する場面や、人間による動作を少し含ませており、AIに丸投げをしないところがポイントです。

このシステムは二ヶ月ほど稼働しており、順調に動作しています。しかし今後より複雑なコードを設計していくことを考えるとまだ問題点は多いです。

コード規約がなく可読性が低いテストの妥当性に不安がある（pytest依存）エージェントの安定性が低い（bash承認など） Web/API設計の知識不足変更履歴の管理が不十分

AI駆動開発は「楽をする手法」ではなく、管理コストを別の場所に移す手法です。この前提を理解しないと、コードは増え続け、いずれ破綻します。

逆に、「ドキュメント」「フロー設計」「評価設計」この3つを押さえれば、AI開発においては重要だと感じました。