Devinにコンテナイメージサイズを70%削減・デプロイ時間を40%削減してもらった話

こんにちは。LayerX AI・LLM事業部のエンジニア、Osukeです。普段は Ai Workforce のプロダクト開発に従事しています。

当事業部では、開発現場で役立つさまざまなAIツールを取り入れており、今回ご紹介するのはそのひとつ、Devin です。

Devinとは

Devinは2024年12月に正式リリースされたエージェント型プロダクトで、GitHubやSlackなど、普段使い慣れたツールと連携して、まるでAIエンジニアがサポートしてくれるかのように開発タスクを自律的にこなします。

Slack上で指示を与えるだけで、Task PlanningからPR作成を実施してくれます。コードベース全体の整合性を考慮しながら作業を進めてくれるため、開発現場のコンテキストを想像以上に考慮しながらコード生成など行なってくれるのが特徴的です。

背景

私たちのプロダクト、Ai Workforce の開発において、CI/CDの実行時間が長いことが課題となっていました。特に、Dockerfile の最適化に手が回っておらず、イメージサイズが大きく、デプロイのたびにビルド時間が長引いていることがリリース時間の増大につながっていました。

課題感は認識していたものの、なかなか作業に取れる時間が当てられなかったので、今回はDevinにDockerfile最適化タスクを任せることにしました。ちょうどDevinの導入を始めて、有効なDevinの使い方を模索している背景もありました。

タスク指示とDevinの実行プロセス

今回のDevinへの指示は非常にシンプルで、対象のDockerfileのURLと以下のメッセージをSlackで送るだけです。

これにより、以下のようなDockerfileの基本的な最適化をコードベース全体のコンテキストを考慮しながら実行してくれます。

マルチステージビルドの最適化
インストール不要なライブラリの削除
ベースイメージの最適化

特に「インストール不要なライブラリの削除」については、Devinがレポジトリ全体のコードを解析し、実際に不要かどうかを判断してくれます。単一のDockerfileの最適化であれば、他のLLMプロダクトでも可能ですが、Devinはリポジトリ全体の文脈を理解した上で整合性を保ちながら改善を進めてくれる点がポイントです。

Task Planningと選択肢の提示

メッセージ送信後、数分でDevinからタスクのPlan Overviewが返ってきました。その中で、最初は「.NET環境がインストールされているが使っていなさそうなので削除する」という案が提示されました。この案の確認をDevinから求められていましたが、自分はこれを見逃していて、実際には.NETを使っているにも関わらず、案の採用を指示してしまいました。

しかし、タスクを進めるうちに実際は.NET環境が必要であることがDevinが自律的に発見してくれて、さらに、Devinはその扱いについてどのようにすべきか、以下のような簡潔な選択肢を提示してくれました。

この柔軟な対応と選択肢の提示により、特殊なイメージに対しても最適な改善策を選ぶことができました。

PR作成と成果

最終的に、約20分弱で一連の処理が完了し、Devinは自動でPull Request（PR）を作成。途中、Dockerビルドの実行で若干時間がかかったものの、最終的には以下の成果を得ることができました。

イメージサイズ: 12GB → 3.8GB（約68%削減）
デプロイ時間: 12分 → 7分（約42%削減）

実際に作業を動かしたのはほぼDevinで、私はPRのレビューと動作確認、細かな修正指示を出すだけで、実作業時間は合計10分程度でした。

元々のDockerfileが全然最適化されておらず伸び代が多くあったのもありますが、片手間でこの成果を出すことができて驚きました。

タスク結果や内容について、雑に質問するとちゃんと答えてくれます。

Devinと今後の開発体制

AI・LLM事業部では、さまざまな開発タスクをDevinが担ってくれており、今回のDockerfileの最適化はその一例になります。

Devinが担えるタスクと不得意なタスクの傾向をナレッジ化し、効率的な活用法を模索しています。もちろん、Devinが全ての開発タスクに最適というわけではありませんが、適材適所で利用することで、エンジニアの生産性向上に大きく寄与しています。

さらに、Devin自身も我々のエンジニアの一員として扱い、作業環境の改善にも取り組んでいます。たとえば、ADRやDesign Docなどの設計情報をGitHubリポジトリに含め、より豊富なコンテキストを与えることで、Devinの処理精度を向上させることに繋がります。また、ファイルごとの行数を減らすなど、処理しやすいコードベースにする取り組みも進行中です。

そして、Devin自体にも実行ごとに自動提案されるKnowledgeを溜めることができるので、使えば使うほど我々のコードベースのコンテキストに習熟していくことになります。

Devinのその他のタスク例

他のうまくいった例としては、コード作成以外だとコードから非エンジニア向けの特定機能の仕様書やマニュアルを自動作成する例はかなりクオリティが高い文書を作成することができました。エンジニア以外も不具合調査のために活用したり、Devinを介して開発をすることができたりとより幅広い活躍も見込めています。

また、開発者自身が詳しくない部分のコードの修正などもDevinが開発を進めつつ開発者自身もキャッチアップできるので効果的でした。

一方で、Devinがうまくできそうでできなかった例が、ユニットテストの自動生成です。原因としては、テスト対象のファイルが1,000行以上と大きく、さらにそのファイルに存在するすべてのメソッドに対してユニットテストを作成するよう指示したので、処理コストが想定以上に大きくなってしまったことが考えられます。処理コストの上限を設定していたため、結果的に上限に達してしまい、十分なテスト生成が行えませんでした。

ユニットテストの自動生成はシンプルなケースであればうまくいきますが、背景知識が必要な複雑なビジネスロジックや優れたテストケースの作成は、ただコードを与えられただけではなかなか難しい印象です。

改善ポイントとしては、上述したDesign Docや仕様書をGitHubに含める他、テストケース自体は開発者が設計しつつ、具体的なテストコードはDevinに任せるといった方針が考えられます。このテストケースを考えるというフェーズで不具合を発見できることも多いので開発者自身が行うメリットもあります。