実装もテストもレビューも、AIに任せる前提で開発フローを組み直した
blueleaf
受託開発の現場でも、実装をAIに任せるのはもう珍しくありません。ただ「AIに作ってもらう」というだけでは、工程ごとに明確なルールがないと、品質は安定しません。AIが書いたコードをそのままプッシュするだけの人もいれば、テストまで含めてきちんと固める人もいる。同じ"AIで実装する"でも、間に挟むルール次第で結果がまったく変わってきます。
今回は、実装・テスト・コードレビュー・開発フローの進行判定という4つの工程すべてを、最初からAIが担当する前提で設計し直した記録です。工程ごとにルールを明文化し、その進行自体もスキルとしてAIに任せることで、品質の確保の仕方が変わりました。
きっかけは、人力レビューの限界
発端は、シンプルな運用上の悩みでした。
「プルリクエストが出てきたら、朝会の30分で内容を確認して進めています。ただ、変更行数が何百行とかになると、30分内での確認がなかなか厳しくて、作業負荷を感じています」
実装自体はAIに任せて速く出てくるようになった一方、それを人が読んで確認する工程は昔のままの速度でした。行数が増えるほど、確認の密度は薄くなります。実際、ある画面の改修プルリクエストを見てみると、対象データの抽出条件がシステムの改版をまたげていない、という問題が見つかりました。実データで検証すると、対象1万5千件超のうち450件が改版後の最新データに正しく紐づいておらず、うち31件は審査が完了しないまま埋もれていました。
これは「AIに実装させたから」起きた問題というより、「実装は速くなったのに、検証のルールが工程ごとに決まっていなかった」ことが本当の原因でした。AIは指示されたことは速く正確にこなしますが、指示されていない前提(この場合は「システムの改版をまたぐ場合の考慮」)までは、ルールとして与えない限り拾ってくれません。
開発フローを、工程ごとに"誰が"担当するかで整理する
そこで、開発フロー全体を工程ごとに洗い出し、それぞれ「人が担当するか、AIが担当するか」「AIなら開発者側のAIか、設計者側のAIか」を1つずつ決めていきました。
| # | 工程 | 担当 |
|---|---|---|
| 1 | オリエン・内容理解 | 人(設計者→開発者) |
| 2 | 実装 | 開発者＋AI(開発者側) |
| 3 | 自動テスト作成(RSpec・Jestなど) | 開発者＋AI(開発者側) |
| 4 | 通しテストの作成・実施 | AI(開発者側) |
| 5 | プルリクエスト作成 | AI(開発者側) |
| 6 | プルリクエストのレビュー | AI(設計者側) |
| 7 | マージ・デプロイ | 自動(人手なし) |
| 8 | 開発環境での通しテスト | AI・必要な箇所は開発者も |
| 9 | 受け入れ | AI(設計者側)・必要に応じ設計者本人も |
こうして並べてみると、見えてくるのは「実装する側のAI」と「検査する側のAI」が別々に立っている、という構図です。開発者側のAIは手を動かして作る役、設計者側のAIはできあがったものを検査する役。同じ"AIを使う"でも、立場が違えば見るものが違います。
この構図のうえで、検査を担当する設計者側のAIには、次のようなルールを持たせました。
プルリクエストのレビュー
見る観点も広げました。コーディング規約や既知の不具合パターンとの突き合わせに加えて、実装がIssueの仕様を満たしているかどうかまで、プルリクエストのレビューで確認するようにしています。人力のレビューでは、行数が多いプルリクエストになるほどそこまで手が回らないことがありましたが、AIなら毎回同じ深さで確認できます。従来は「仕様を満たしているか」をテストだけで担保していましたが、テストとプルリクエストのレビューの両方で確認する形になり、品質確保の網が二重になりました。
運用としては、1日に複数回AIが自動で巡回し、まだ人がレビューしていない最新のプルリクエストを検知します。コメントの1行目は「AIレビューです」で固定。指摘があれば紐づくタスクを自動で「対応中」に差し戻します。この一次レビューの自動化自体は、以前の記事「レビュー待ちで実装が止まる──一次レビューをAIに任せて滞りを解消した」で扱った仕組みの延長線上にあります。
テストケースレビュー
通しテストと自動テストの中身を、仕様と突き合わせてレビューします。過去に実際すり抜けてしまった不具合の型――確定済みデータの扱い漏れ、権限チェック漏れ、キー名の不一致など――を観点として1つずつテーブルに紐付け、毎回考える代わりに機械的に総当たりでチェックできるようにしました。
開発フロー全体の進行判定
Issue番号を渡すと、プロジェクト管理ボードの状態から「今どの段階にいるか」を判定し、必要な工程を順番に呼び分けます。「次に何をすればいいんだっけ」を考える工程そのものを、AIに引き取ってもらう形です。
AIが担当するからこそ、今までの作業量を超えられた
これらを設計する過程で、人力では現実的でなかった検証も実施できました。
- 直近1ヶ月分のレビューコメントを、AIに全部読み返してもらったところ、プルリクエスト58件のうち実質的な指摘があったのは9件。その9件を分類すると「要件・仕様の理解不足」「外部連携の状態を考慮していない実装」といった型が繰り返し出ていました
- 直近2ヶ月分の作業履歴から手戻りの量を数えたところ、プルリクエスト74件のうち45件で後から追加の修正が入っていました。6割が「実装のやり直し」に費やされていた計算です
こうした「全履歴を読み返して型を数える」作業は、人が手作業でやろうとすれば非常に骨が折れます。AIが担当する前提だからこそ、感覚ではなく実測値として、繰り返している不具合の型を可視化できました。
巡回レビューの頻度も同じ理屈です。人のレビューが1日1回・30分だったのに対し、AIの巡回は平日日中に複数回まわります。実装もテストもレビューもAIが担当するようになった結果、「1回あたりをどれだけ丁寧に見るか」ではなく「どれだけの頻度・粒度で見続けるか」という、人力では選べなかった選択肢が使えるようになりました。
それでも、人にしか決められないことは残す
工程の大半をAIが担当する形にしても、"何をしてほしいか"を伝えることと、"できたと認めるか"を最終的に判断することまで、AIに委ねたわけではありません。設計の過程で、次の役割ははっきり人に残しました。
- オリエンでの内容理解:設計者が開発者に、Issueの内容を伝える。ここで理解のズレを拾う
- 受け入れの最終確認:受け入れ自体は設計者側のAIが行いますが、必要に応じて設計者本人が確認する
実装・テスト・レビュー・進行判定という"実行"の大部分はAIに任せても、「何をしてほしいか」を最初に伝えることと、「それで要件を満たしていると言えるか」を必要に応じて人が見ることは、線引きとして残しました。
まとめ:品質を「人の能力に依存」するのではなく「AIという仕組み」で確保する
一連の作業を振り返って残るのは、シンプルな結論です。開発者側と設計者側、それぞれのAIが役割を分担して実装・テスト・レビューを担当する前提に立ったとき、品質を確保する主体は「人の能力」から「AIという仕組み」に移ります。
- 実装・テストは開発者側のAIが、レビューは設計者側の別のAIが、それぞれ明文化されたルールに沿って担当する
- 検査を担当する設計者側のAIだからこそ、全履歴の読み返しや1日複数回の巡回といった、人力では現実的でなかった粒度・頻度の検証ができる
- 開発フロー全体の進行判定もスキル化し、「次に何をすべきか」自体をAIがサポートする
- そのうえで、内容を伝えることと最終確認は、人の役割として残す
品質を個人の能力に依存させず、仕組みで確保するという考え方自体は、システムインテグレーションの現場では昔からあるものです。今回変わったのは、その"仕組み"の中身です。AIが実装からレビューまでを担当できるようになったことで、同じ考え方のもとで組める仕組みが、以前より一段進化しました。
同じように、実装からレビューまでAIに任せているのに品質が安定しない、という悩みを抱えている受託開発の現場は、決して珍しくないはずです。もし仕組み化に興味があれば、お気軽にご相談ください。
＼ 最新情報をチェック ／
