🤖
レバテック開発部にもDevinを導入しました！活用事例と組織で管理するつらみ

かに
2025/06/25に公開
Devin
idea
 はじめにこんにちは、レバテック開発部の塚原です。

昨今、さまざまな企業で各種 AI エージェントの活用が進んでいますが、レバテック開発部でも4月から自律型 AI エージェントである Devin を導入しています。そこで、2ヶ月半ほど組織で Devin を運用してわかったことを共有していきます。

 利用状況6月時点では14チーム (計30人ほど) が利用しており、Devin が作成してマージした PR 数は177になっています。
Devin に依頼したタスクの種別ごとの割合は以下の通りで、さまざまなタスクに Devin を利用してきました。



タスク種別ごとの Devin の利用割合

 費用対効果の測定方法Devin を導入した効果を測定するため、利用者にポジティブ面・ネガティブ面を含めた定量・定性の効果をスプレッドシートに記載してもらっています。集まった効果のうち「Devin の利用により、人間の工数が〇〇から△△になった」のような定量的に効果が報告されたものについて、以下の計算式で費用対効果を算出しました。
費用対効果 = 消費した ACU の金額 - 削減時間分の時給
!Team プランを利用しているため、1 ACU あたり $2.00 換算です。
上記のように費用対効果を測定してわかった費用対効果が高い活用事例や費用対効果が低い活用事例を共有していきます。

 費用対効果の高かった事例
 Devin によるレビューDevin による PR のレビューは、1レビューあたりの消費 ACU が1~2程度と少なく、ある程度真っ当なレビューができるため、一次レビューとして高い効果が得られました。

Devin によるレビューの仕組みは、Devin 101: Automatic PR Reviews with the Devin APIを参考にしつつ、PR に「devin-review」というラベルを付与し、Github Actions 経由で Devin の API を呼び出してレビューさせる形式にしています。また最近では、Typescript のレビュー観点を集めた Github リポジトリが作成され、それを Playbook から呼び出す形で運用しています。

https://zenn.dev/levtech/articles/4b540d6398bda1
[yaml] Devin によるレビュー用の Github ActionsPlaybook を !review_typescript というマクロで呼び出しています。
devin-pr-review.yaml
name: 'devin-pr-review'

on:
  pull_request:
    types: [labeled]

permissions:
  contents: read
  pull-requests: read

jobs:
  review-pr:
    runs-on: ubuntu-latest
    if: github.event.action == 'labeled' && github.event.label.name == 'devin-review'
    timeout-minutes: 5

    steps:
      - name: Create Devin Review Session
        id: devin-review
        env:
          DEVIN_API_KEY: ${{ secrets.DEVIN_API_KEY }}
          REVIEW_PROMPT: |
            !review_typescript
            PR_URL: https://github.com/${{ github.repository }}/pull/${{ github.event.pull_request.number }}
        run: |
          ESCAPED_PROMPT=$(echo "$REVIEW_PROMPT" | jq -Rs .)
          HTTP_STATUS=$(curl -s -o /tmp/api_response.json -w "%{http_code}" -X POST \
            -H "Authorization: Bearer $DEVIN_API_KEY" \
            -H "Content-Type: application/json" \
            -d "{
              \"prompt\": $ESCAPED_PROMPT,
              \"idempotent\": true,
              \"tags\": [\"devin-review\", \"${{ github.repository }}\"],
              \"title\": \"[PR レビュー]${{ github.event.pull_request.title }}\",
              \"max_acu_limit\": 3
            }" \
            "https://api.devin.ai/v1/sessions")
          echo "HTTP Status Code: $HTTP_STATUS"
          if [ "$HTTP_STATUS" -eq 200 ]; then
            echo "✅ Successfully created Devin review session"
            echo "Response:"
            cat /tmp/api_response.json
          else
            echo "❌ Failed to create Devin review session"
            echo "Response:"
            cat /tmp/api_response.json || echo "No response body"
            exit 1
          fi


実際に Devin による一次レビュー時のコメント例
作成したレビュー観点集を Devin に与えてレビューさせることで、推奨コードやレビュー観点へのリンク付きレビューをしてくれるため、レビュアーとレビュイー双方のコストが削減されています。

さらに、Typescript を利用している複数のチームで共通のレビュー観点を利用したり、育てられるようにもなりました。

 システム定期メンテナンスの実装・リスク評価システムで利用しているライブラリやフレームワークのバージョンを定期的に更新していますが、バージョン更新時の影響を把握するのに時間がかかっていました。Devin を活用することで、バージョンが更新されたライブラリの変更履歴と既存のコードベースを参照してリスク評価が簡単にできるようになり、高い効果が得られました。
下記は定期的に実施している npm パッケージ更新時のリスク評価に Devin を使った例です。



与えたプロンプト



実装結果 (一部のみ)

 レガシーなコードベースでも類似 PR がある場合レバテック開発部では、10 年以上運用している PHP で実装されたレガシーなコードベースがあります。具体的には、
テストの実装が全くない
ライブラリのバージョンが古いまま更新されていない
ファットコントローラーや不要な条件分岐などが多い
構築に関わった人が残っておらず、仕様も引き継がれていない
という状態になっているため、人間でも変更を入れるのに苦労します。このコードベースに対して、Devin に実装タスクを依頼すると、成果が得られないケースがほとんどでしたが、類似の PR を与える ことで Devin による修正で高い効果が得られました。
!上記のようなレガシーなコードベースに対する他の活用事例として、Devin Search と用いた既存コードの仕様調査がありました。上記のレガシーなコードベースの特徴の一つとして「構築に関わった人が残っておらず、仕様も引き継がれていない」を上げましたが、これにより現状の仕様をコードから調査するケースが多くありました。Devin Search と対話しながらコード調査をすることで、人間だけで調査するよりもかなり生産性が高まっています。

 費用対効果の低かった事例
 広範囲のリファクタリング広範囲に渡るリファクタリングを Devin に依頼した場合、セッションの途中で Devin の修正精度が落ちるケースがありました。
一例として、モノレポでファイル名の規則を見直した部分があり、Devin に一括でファイル名を変換する実装を依頼したケースを紹介します。このケースでは、変更対象のファイル数が数十〜数百あったせいで最初に PR を上げるまでに 1 時間使っていました。また、その PR も CI が通らない状態でした。

詳しく見てみると、ファイルが書き換わっているが、そのファイルをインポートしている箇所の記述が書き換わっていない部分があり、それが原因で CI が失敗していました。結局 30 ACU ほど消費しましたが、Devin が実装を仕上げることができませんでした。
公式ドキュメントに記載されている BestPractice にも
Try not to spend too many (>10) ACUs on one run. Devin’s performance degrades in long sessions.
と記載がありました。広範囲なリファクタリングでは、Devin に与えるコンテキストが大きくなってしまい、コンテキストウィンドウオーバーフローを起こした結果として修正精度が落ちた、ということかと思います。そのため、例えば、広範囲のリファクタリングが必要な場面でも、モジュールなどの一定の単位でタスクを分解し、分解したタスクごとに Devin のセッションを起動する方法を取る方が、精度を落とさずにリファクタリングが可能かと思います。

 小さすぎるタスク人間が実施しても数分から数十分で完了するくらい小さいタスクの場合、人間が直接コードを編集する時間に比べて、Devin への依頼のためのプロンプトの用意にかかる時間的なコストと消費する ACU の金額的なコストが大きくなり、費用対効果が低かったりマイナスになるケースが多かったです。
しかし、小さすぎるタスクが複数あるケースでは、一括でタスクごとの Devin セッションを起動できれば、タスク間のコンテキストスイッチのコストがかからない分、費用対効果が高くなりそうだと考えています。試しに、Github Issue に小さいタスクを蓄積していき、一括で devin というラベルを付与することで Github Actions 経由でタスクごとに Devin セッションを起動させるような仕組みを作ってみました。
以下３つの簡単な Issue を用意し、一括選択で devin というラベルを付与すると、Github Actions 経由で3つの Devin セッションが起動し、PR が作成されました。


用意した Github Issue



作成された PR の一つ
Devin が一括で実装できるため、Devin が自力である程度質の高い実装を完結できるくらいタスクの場合は有効そうです。逆に Devin が自走できないタスクの場合は、質の低い PR がたくさん作成されてしまうので、効果が低そうです。とはいえ、まだ一度試した程度なので、今後の運用してみて有用性を確認していきたいと思っています。
[yaml] Github Issue から Devin セッションを起動する Github Actionsdevin-issue-trigger.yaml
name: 'devin-issue-trigger'

on:
  issues:
    types: [labeled]

permissions:
  contents: read
  pull-requests: read

jobs:
  trigger-devin:
    runs-on: ubuntu-latest
    if: github.event.action == 'labeled' && github.event.label.name == 'devin'
    timeout-minutes: 5

    steps:
      - name: Create Devin Session
        id: devin-issue-trigger
        env:
          DEVIN_API_KEY: ${{ secrets.DEVIN_API_KEY }}
          PROMPT: |
            以下の Github Issue について、既存実装の調査を行い、分析・実装してください。
            Issue 情報:
            - タイトル: ${{ github.event.issue.title }}
            - 内容: ${{ github.event.issue.body }}
            - 番号: #${{ github.event.issue.number }}
            - URL: ${{ github.event.issue.html_url }}
            - 作成者: ${{ github.event.issue.user.login }}
            - リポジトリ: ${{ github.repository }}
        run: |
          ESCAPED_PROMPT=$(echo "$PROMPT" | jq -Rs .)
          HTTP_STATUS=$(curl -s -o /tmp/api_response.json -w "%{http_code}" -X POST \
            -H "Authorization: Bearer $DEVIN_API_KEY" \
            -H "Content-Type: application/json" \
            -d "{
              \"prompt\": $ESCAPED_PROMPT,
              \"idempotent\": true,
              \"tags\": [\"devin-issue-trigger\", \"${{ github.repository }}\"],
              \"title\": \"${{ github.event.issue.title }}\",
              \"max_acu_limit\": 10
            }" \
            "https://api.devin.ai/v1/sessions")
          echo "HTTP Status Code: $HTTP_STATUS"
          if [ "$HTTP_STATUS" -eq 200 ]; then
            echo "✅ Successfully created Devin review session"
            echo "Response:"
            cat /tmp/api_response.json
          else
            echo "❌ Failed to create Devin review session"
            echo "Response:"
            cat /tmp/api_response.json || echo "No response body"
            exit 1
          fi

 組織で管理するときのつらみDevin を開発部に導入してから管理上困るポイントがあったため、いくつか共有していきます。

 Slack と Devin を接続できない...Devin の公式ドキュメント Common Issues にも記載がありますが、一つの Slack Organization / Github Organization には、一つの Devin Organization しか接続できない という仕様です。

弊社では、会社で一つの Slack Organization を運用していますが、既に他の部署で Devin Organization を紐づけており、レバテック開発部の Devin Organization を Slack に紐づけることができませんでした。そのため、Slack からではなく、Devin の Web アプリケーションを使って、Devin のセッションを作成しています。

組織で新たに Devin Organization を作成する場合は、利用している Slack Organization に既に他の部署が Devin Organization を紐づけていないか、確認しておきましょう。

 チームごとの ACU が管理しづらい...複数チームで Devin を共同利用しているため、チームごとに利用可能な ACU を決めています。

しかし、チームごとに消費 ACU の制限する機能はないため、チームごとに当月に消費した ACU を可視化し、それを参照して予定以上の ACU を消費しないようにしてもらっています。

また、消費 ACU の可視化にあたり、Devin API を利用していますが、現時点ではセッションごとの消費 ACU を取得する API が存在しないため、以下のような非常に泥臭い方法で集計しています。

List all sessions を使って、セッションの一覧を取得

Retrieve details about an existing session　を使って、そのセッションを作成したユーザーを取得
PlayWright を使って、Devin のセッションにアクセスし、画面要素からそのセッションの消費 ACU を取得
セッションごとの 消費 ACU を CSV 形式のファイルに吐き出し、スプレッドシードで集計

 気づかないうちに数十 ACU 消費しているケースがあった...デフォルトでは、Devin が作成した PR に対して、人間がレビューコメントつける度に Devin のセッションが起動して、修正が行われます。

これに気づかず、想定以上に ACU が消費されてしまっていた事例がありました。現在は、Devin で以下の設定を有効にしており、PRに「DevinAI」という接頭辞を付けてコメントしたときのみ Devin にセッションを起動させることで、この問題を防いでいます。意図しない ACU 消費を抑えるために、この設定をおすすめします。



"Only respond to PR comments that mention Devin" をオンにする

 Devin への Github リポジトリの追加が並行できない...複数チームで Devin を利用しているため、各チームが所有している Github リポジトリを公式ドキュメントの手順に沿って、 Devin に登録する必要があります。

しかし、一つのリポジトリがセットアップ途中の場合、他のリポジトリのセットアップを新たに開始することができませんでした。

そのため、他のチームのリポジトリのセットアップを開始するために、自チームのリポジトリのセットアップを一時的に中断するなどのコミュニケーションが発生していました。

 おわりに管理上のつらみも紹介しましたが、ここまで運用してきて正しく活用することで確実に開発生産性の向上させられると考えています。今後より費用対効果を高く Devin を活用していくために、6月11日にリリースされた Session Insights を活用して、コスト最適化を図っていきたいと考えています。
https://x.com/cognition_labs/status/1932492208583946327