every Tech Blog

株式会社エブリーのTech Blogです。

トップ > Devin > DevinでLP改善タスクを自動化してみた

DevinでLP改善タスクを自動化してみた

Devin AI AWS

はじめに

こんにちは。開発本部開発1部デリッシュキッチンMS1に所属している江﨑です。

今回は、User Matching（以下、UM）事業において、AIソフトウェアエンジニアであるDevinを導入し、LP（ランディングページ）の運用タスクを自動化した事例について紹介します。

前提知識

Devinとは

Devinは、Cognition AI社が開発したAIソフトウェアエンジニアです。コードの理解、実装、デバッグ、テストまでを自律的に行うことができ、開発者の作業を大幅に効率化します。GitHubとの連携により、Issueの内容を理解してPull Requestを作成することも可能です。

UMとは

デリッシュキッチンやトモニテではプレゼントキャンペーンが定期的に行われており、ユーザー様はいくつかの質問にLP経由で回答することで応募できるようになっています。 この中で、エンジニアは、LP作成・変更、ETL処理の実装などを担当しています。 事業の特性上、クライアント様の要望に応じたLPを個別で作成しているため、LPの新規作成やCVR改善などのための既存のLPの修正が頻繁に発生します。

Devinの導入目的

具体的に、UM事業におけるLPの運用タスクは、画像の差し替えや文言修正、設問の追加・削除といったものが多くを占めていました。 これらは単純な定型作業ではなく、クライアント様ごとの要望に応じて個別カスタマイズが必要となる作業です。 一つ一つの難易度は高くないものの、数が多く、かつそれぞれ微細なカスタマイズが必要で、エンジニアの貴重なリソースを割いてしまっているという課題がありました。 そこで私たちは、これらのLP運用タスクを自動化し、開発工数の削減、エンジニアがよりクリエイティブな業務へ集中できる環境の構築を目指すため、Devinの導入を決定しました。

LP運用タスクの自動化

Asanaから実装までの流れ

弊社では、タスク管理ツールとしてAsanaを採用しています。 LP運用タスクは、ビジネス職の人がクライアント要望を踏まえて、Asanaにチケットをすることでエンジニアに開発依頼が渡ってきます。 そこで、Asanaから実装までを自動で行うようなフローを構築しました。

具体的な流れは以下のようになります。

  1. トリガー：依頼者がAsanaチケットのカスタムフィールドをDevin実行に変更します。
  2. Webhook発火：フィールド変更をトリガーにAsana Webhookが発火し、API Gateway経由でLambda関数を呼び出します。
  3. Issue作成：LambdaがGitHub APIを叩き、LPのリポジトリにIssueを自動作成します。
  4. 実装計画の立案：Issueが作成されると、自動でdevin-planラベルが付与されます。これをトリガーにGitHub ActionsでDevin APIを叩くことでDevinが起動し、Asanaの依頼内容を元に実装計画を練り、Issueのコメントとして投稿します。
  5. 計画のレビュー：エンジニアがDevinの作成した実装計画を確認します。もし修正が必要な場合は、Issueにコメントを投稿します。
  6. 実装開始：計画の確認が終わったら、エンジニアがIssueにdevinラベルを付与します。これもdevin-planラベルと同様にGitHub Actions経由でDevinが起動し、実装を開始します。
  7. Pull Request作成：Devinが実装を完了すると、自動でPRを作成します。
  8. PRのレビューと修正：エンジニアは生成されたコードをレビューします。修正が必要な場合は、PR上で@DevinAIとメンションすることで、Devinに修正を依頼できます。

このフローにより、エンジニアは「計画のレビュー」と「最終的なコードのレビュー」をするだけで良くなります。

実装のポイント

1. 段階的な実装アプローチ

DevinにAsanaからPR作成までを全自動でやってもらうのではなく、実装計画をエンジニアがレビューするステップを設けました。これには以下の意図があります：

  • 全く異なる計画を立てて実装を行なってしまった時の手戻りリスクを回避
  • Devinの1セッションのACU（Devinがタスクを実行するのに必要な計算リソースの単位）を削減し、コスト最適化

2. プロンプトエンジニアリング

devin-planで実装計画を立てるときに、計画をIssueのコメントに投稿せずに、実装まで行なってしまうことが多々ありました。そこで、以下のようにDevinに行うタスクのゴールを明確にしたところ、動作が安定するようになりました。

**Issueにコメントとして投稿するのみで実装は行わないでください。**
コメントとして投稿したらゴールです。
投稿した時点で、sleepしてください。
以下のIssueの内容を確認し、計画を立てて、Issueにコメントとして投稿してください。

Issue タイトル: （高-3）DK_xxx_開発依頼
Issue 本文:
---
## 📋 タスク詳細
xxx

---
Issue URL: https://github.com/xxx/xxx/issues/xxx

計画には以下を含めてください:
1. 実装の概要
2. 必要な変更ファイルのリスト
3. 実装手順
4. 考慮事項やリスク

システムアーキテクチャ

この自動化フローは、Asana Webhook、AWS、GitHub APIを連携させて構築しています。 具体的なアーキテクチャは以下のようになっています。

AWS構成の詳細

API Gateway

AsanaのWebhookリクエストを受信するRESTエンドポイントとして機能します。

Lambda (受信・検証)

Webhookの認証やSQSへの転送を実行します：

  • HMAC署名検証: Asanaからの正当なリクエストかを検証
  • User-Agent検証: 想定外のクライアントからのアクセスを排除
  • SQSへの転送: 処理内容を非同期キューに送信
  • 即座に200レスポンス: Webhookタイムアウトを回避

SQS FIFO Queue

1つ目のLambdaから処理内容を受け取り、2つ目のLambdaを起動する中継役として機能します。

Lambda (処理実行)

SQSから受け取ったメッセージを基に、実際のビジネスロジックを実行します：

  • カスタムフィールド確認: Asanaタスクの特定フィールド値をチェック
  • Issue内容成型: GitHub Issue用のフォーマットに変換
  • GitHub API呼び出し: RESTful APIによるIssue作成とラベル付け

失敗から学んだ技術的工夫

初期実装での大失敗

最初の実装では、1つのLambda内でAsana Webhookの受信からGitHub Issue作成まで全て処理しようとしました。しかし、これが大きな問題を引き起こしました。

問題: Webhook タイムアウト

AsanaのWebhookは10秒以内にレスポンスを返さないと失敗扱いになります。失敗すると、Asanaは24時間の間1時間ごとにリトライを繰り返します。

問題は、Lambdaでの全処理に10秒以上かかってしまったことでした。実際にはGitHub Issueの作成は成功しているのに、Asanaには失敗として認識され、Webhookのバックオフが発生してしまいました。

その結果、テスト用タスクが深夜に約200個のIssueとして自動生成されました。さらに、それらがdevin-planラベルに反応して大量のDevinが起動し、60ACU（約2万円）分のコストを無駄に消費してしまいました。

解決策: 非同期処理による分離

これらの失敗を受けて、Lambda→SQS→Lambdaという2段階の非同期処理構成に変更しました。（詳細は上記「AWS構成の詳細」を参照）

この構成変更により、Webhookのタイムアウト問題は完全に解決され、現在は安定して稼働しています。

結果と成果

導入効果

こちらの運用フローは、現在本番運用を開始したばかりのフェーズになります。 現在は、ビジネス職から依頼が来たAsanaのタスク説明をエンジニアが微修正して運用しています。

現時点でも、大量のLPタスクを並列で実装することができるようになり、エンジニアの負担が軽減されてきています。

今後の展望

今後、以下のような対応を進めることで、ビジネス職からの指示でも安定してLP運用タスクを行なっていけるようになれば、エンジニアの介入がさらに少なくなると考えられます。

  1. Asanaへの記載フォーマットの整備：テンプレート化による依頼品質の向上

  2. Devinのknowledge強化：うまく実装できないパターンのドキュメント化

また、弊社では現在、コードレビューAIツールのCodeRabbitとgreptileの検証を行なっています。 今後、Devinによる実装とこれらのコードレビューAIを組み合わせることで、エンジニアの負担をさらに軽減できると期待しています。

まとめ

今回は、Devinを活用してLP運用タスクを自動化した事例をご紹介しました。

AIに実装を任せる場合は、タスクの粒度が非常に大切であり、今回のLP運用のタスクはDevinに与えるタスクの粒度として適切だと思いました。また、自動化を進める中で、以下のような学びがありました：

  • 明確な指示の重要性：誰が見ても同様の解釈ができるプロンプトの設計
  • 適切な人間の介入：全自動化ではなく、計画レビューとコードレビューという重要なポイントでエンジニアが介入する仕組み
  • ナレッジの蓄積：よくあるパターンや失敗事例、ドメイン知識をドキュメント化し、Devinの精度向上に活用

この記事が、皆さんのチームでのAI活用や業務改善のヒントになれば嬉しいです。

最後までお読みいただきありがとうございました。