AI で開発フローはどう変わったか
-
小檜山 隆太 (こひやま りゅうた)Exa Enterprise AI株式会社(グループ会社) AXサービス事業開発部 AXサービスグループ
生成AIやAIエージェントの進化が、企業経営のあり方を大きく変えようとしている今、私たちエクサウィザーズは、自らが最前線の「実験場」となり、AIドリブン経営を日々実践しています。
今回は、ソフトウェアエンジニアとして現場でプロダクト開発を担当する私が、普段の仕事で生成AIをどのように使っているか、そしてAIを使うようになって開発の進め方がどう変わったのかを紹介します。
AIが実用化される以前の開発
AIが開発現場で実用化される以前は、開発のすべての工程を、自分が手を動かして進めていました。要件を読んで実装方針を考え、設計をドキュメントに落とし、それに沿ってコードを書く。書き終えたらテストケースを整理して動作を確認し、メンバーにレビューしてもらって、指摘があれば直す ── そのひとつひとつを、人が手作業で行っていました。自分の手が動いている間は、頭の中もたいてい、ひとつの開発で埋まっている状態でした。

AIと一緒に開発サイクルを回す
設計・実装・レビュー・テストという一連の流れを、今はAIと一緒に回しています。普段はClaude Opusを中心に使っていて、やり取りのしやすさや、出力する文章量のコントロールのしやすさを気に入っています。一方で、レビューのように多様な観点がほしい場面では、Codexなど別系統のAIも併用しています。
設計と実装
解決すべき課題をまとめた文書をAIに読み込ませ、実装レベルの設計を作ってもらいます。そこに私がフィードバックを返し、AIが直す ── これを繰り返して設計を詰めます。設計が固まれば実装ですが、ここ数カ月は、コードを書く作業はほぼAIが担当しています。私の役割は方針と判断軸を渡し、出てきたものを採用するか方針を変えるかを決めること。手を動かすより、判断に時間を使うようになってきました。
レビュー専門のAIチーム
AI がコードを書き上げると、レビュー専門のAIチームが自動的に立ち上がります。セキュリティ、テストの十分さ、保守性、ユーザー影響など、5〜6 体のAIがそれぞれ違う観点を担当し、まとめ役のAIが結果を集約します。
一定の条件を満たす指摘は、実装担当のAIに修正指示が自動で渡り、再レビューに回る ── これを重要な指摘がなくなるまで繰り返します。意識しているのは、異なる生成AIモデルを混ぜること。同じAIで揃えると見落としやすい観点を、別系統のAIが拾ってくれることがあります。私のところに上がってくる頃には一次レビューは済んでいて、その結果の確認から始められます。
テストも AI と分業する
何をチェックすべきかをAIと一緒にテスト項目として整理したら、その先はAIが引き受けます。AIが実際にアプリを操作し ── ボタンを押したり、データを入力したり、画面の表示を確かめたり ── テスト項目をひとつずつチェックしていきます。その操作の様子は動画として記録されるので、私に残るのは、その動画を見て、想定どおりに動いているかを確認する部分だけです。
自分で画面をひとつずつ操作する手動テストは億劫になりがちでしたが、いまは上がってくる動画をチェックする形になり、負担は軽くなっています。
並列で走らせる
AIに作業を依頼している間は、自分の手が空きます。その時間に別のタスクを取って、こちらも同じようにAIと一緒に進める。それぞれのAIが「完了しました」と返してきたタイミングで、順に判断を返していく。いまはこうして、2〜3並列くらいで開発を回しています。開発全体としては、以前より大きく効率化できていると実感しています。
AI が質の高いアウトプットを出すために
AIがうまく動いてくれるように、開発環境やドキュメントの面でいろいろと整備をしてきました。
ひとつは、機械的に判断できる部分を、あらかじめ整理しておくこと。自動テスト、型チェック、静的解析(lint)など、書いたコードが事前に決めたルールに沿っているかを機械的にチェックできる仕組みを用意しておくと、AIは自分の書いたコードへのフィードバックをその場で受け取り、確かめながら作業を進められます。
もうひとつは、これまでの意思決定や、コードだけでは読み取りづらい設計思想、過去に検討したトレードオフなどを文書として残し、AIが確認できるようにしておくこと。こうした情報があると、AIが文脈を踏まえた提案を出しやすくなります。
おわりに
私自身の開発の進め方がAIでどう変わってきたかをお伝えしました。まだ試行錯誤の途中ですが、現場のひとつの現在地として共有できればと思います。