AIエージェント前提の開発体制をゼロから組む: 最低限のCI/CD
最近、Manus/Devin/Cline/Codexなど、様々なAIエージェントが現れてきています。
これらのAIエージェントは大量の開発タスクを並列にこなすことができ、大量にコードを生成したり、大量のコード変更を加えることができます。しかし、生成されたコードや設計の品質は高スキルなエンジニアが手作業で作っているものと比較すると低く、これを高品質なものにするためのレビュー作業や手直しが必要になってきます。また、検証作業やUX評価も必要になってきます。
本シリーズでは、高品質なプロダクトを高品質に運用する体制を最高の効率で作っていきます。人とAIの能力を最大限活かして、最高効率の開発体制を作っていきます。本稿では、まずは、最低限のCI/CD環境を整えていきます。具体的には、実行環境の構築をプルリクエストごとに自動化して行う仕組みを作ることで、それぞれの変更の検証を簡単にできるようにしました。また、PRごとに構築した環境を使って、UXの自動テストを回したり、アプリケーションログを見れるようにすることで、AIエージェントが自律的に修正を行っていけるような仕組みを作りました。
PRごとにインフラから検証環境を構築して、PR終了時にすべてを削除するので、インフラも含む変更が多く発生しそうな、PMF前のプロダクトなんかは、今回の仕組みが役立つのではないかと思います。この環境が出来ても気にしなくてはならないのは、タスク間の依存関係で、タスクの依存関係を整理して、人、AIエージェントに振り分けるとともに、いかにボトルネックがないようなプロジェクト管理をするかが重要になってくると思います。
最終的な開発のフロー
最終的なフローは下記のような感じで、非常にシンプルになりました。
この実験を行ったプロダクトはモノレポであり、インフラコードも一つのリポジトリに入っているので、多くの開発作業はDevin/Codexへのチャットでの指示とコードレビュー＆確認作業のみですみます。
めちゃめちゃ便利にプロダクト開発をやっていけます。
- Devin/Codexに修正を依頼する
- PRが飛んでくるので、ユニットテストの結果、コードなどを見て、自動デプロイされた環境を触る。
- 修正点あれば修正の指示を出して、2に戻る。
- マージする。
成果
3時間で8個のPRを検証もしてマージできました。
設定をする上でのポイント
PR時の自動環境構築
設定をする上でのポイントを説明します。詳細はo3とかに聞いていただければと思います。
まず、第一に、インフラコードを汎用化する必要があります。例えば、devとprodを切り替えるだけで共通で使えるモジュールを定義して、最小限の設定変更でdevとprodのインフラを定義できるようにする必要があります。環境名にdevとかprodとかstageをいれると、それ専用のインフラができるような感じになると思いますが、そこにpr-111とか、プルリク用の環境名をいれることで、プルリクごとの環境構築を実現します。prodとdevでのIaCの共通化は、大体の環境では実施されていると思うので、あまり、気にする必要はないと思います。環境名を変更しても、問題なく構築できるインフラコードを書くことを心がけることは、prod/devのインフラメンテだけでなく、PR用の一時環境の構築にも役立ちます。
次に、githubからawsを操作できるような権限周りをAWSにセットします。今回は、私が１人で開発しているリポジトリであるため、ほとんどの操作権限がついたRoleを使って、インフラも含めた再構築を殆ど行えるようにしています。複数人開発だったり、セキュリティを気にするべき組織にいる場合、いくつかroleを用意して、PRを作った人ごとに、更新できる範囲を決めて、権限が強い人のアカウント管理はかなり厳格に行う。などをしたほうがいいかもしれません。
最後に、github actionを書いて、その中でアプリのDockerコンテナの構築やPushやインフラ構築を自動的に行うことで、仮の検証環境をプルリクエストごとに作成しています。ポイントとしては、PRごとに、Terraformのステートを別のs3オブジェクトとして保存しており、dev環境やほかのpr環境に影響がないようにすること、おなじPR内ではおなじ環境を使いまわすこと（ActionのRunごとに分けない）としています。そして、ブランチが何らかの理由でCloseされたタイミングのみで、クリーンアップをするようにしています。AWSでは、何らかのリソースを削除すると、その後使えるようになるまでに、数十分以上かかるため、多少トラブルが起きたとしても、ブランチをクローズするまでは、クリーンアップをしないような実装にしています。
また、自動テストも環境構築後に実行するようにします。
これで、環境構築〜自動テストまで実行できて、CIが通れば、最低限の品質が担保されたもののUXテストを試せるようになります。
デバッグを快適にするために
また、PR上で/logsとコメントした際に、アプリケーションの実行ログを表示するような機能も実装しました。これをすることで、コーディングエージェントに自動でデバッグをしてもらったり、自分でもスマホ上で多少はエラーを探ったりできます。将来的にはデータベースのリード権限だけ持たせて、障害対応やより複雑なデバッグなども任せてもいいかもしれません。
今後５年以内のソフトウェア開発の形
vercel v0、bolt.new、AWS PartyRockなどのサービスでは、チャットでAIに話しかけてアプリケーションを作り、デプロイまですることができるため、似たようなことはできます。しかし、バックエンド側はシンプルなものに限られ、単純なアプリケーションまでしか作ることが出来ません。バックエンドが複雑なアプリケーションを作ろうと思うと、AWS/GCP/Azureなどのクラウド環境が選択肢になってくると思います。そのため、今回は、AWS上に開発環境を作りました。
この仕組みはここ5年以内のソフトウェア開発の形に近いと思っております。そのような兆候はそこそこ前から見えており、今回の私の取り組みもそうですが、有名所ではGemini Cloud Assist ＋ Application Design Centerといったインフラをチャットベースで作る仕組みが出てきています。boltなどでチャットベースでアプリが作れて、GCPでインフラも作れるとなると、複雑なインフラからアプリのUIまですべてチャットアプリで作れる仕組みは１年以内はかなりの数が出てくるのではないかと思います。
ただ、ハードウェア、インフラはブラックボックスなものも多いですし、仮にすべてが文章化、ソースコード化されていて、すべてのソースがオープンであったとしても、すべてのコードを理解して、作業するほどのコンテキスト長にLLMがたどり着き、長コンテキストでも高い性能を出せるにはまだまだ時間がかかると思っています。となると、何らかのエラーとは当面は引き続き付き合わなければならずに、そう考えると、現実的には、近い未来では、インフラも合わせてチャットを通して開発、エージェントAIがログを見ながらある程度修正し、最終的に、エンジニアがレビューや追加の検証を行い、コードを承認するという形のソフトウェア開発になると思います。
今後の取り組み
- AIエージェントを使った自動障害対応の仕組みを構築しようと思います。
- プロダクトの運用開発のメトリックを測定してデータを集めようと思います。
最後に
株式会社Titan Intelligence、Hen&Ai株式会社では、一緒に働けるフルスタックエンジニアを募集しております！
AI前提の開発環境で一緒に開発していければと思います。一緒に働いていただける方は、https://x.com/yusuke_hentoai にDMください。
Discussion