こんにちは。
株式会社キカガクの @tetsuro_b です。
弊社では 2025/5 から Devin を導入し運用をしています。
そんな弊社ですが...。
Devin 使い放題です。（ドン!!）
とはいえ、上手く組織で運用していくためのルールはいくつか設定をしていますので、この記事では『Devin 使い放題』な組織のコスト最適化ルールを５つ紹介していきます。
対象読者
- Devin を導入したばかりで組織内の運用ルールが定めきれていない方
- これから Devin を導入したいけど実際どうやって運用しいけばよいかイメージがつかない方
- Devin のコストをなるべく抑えたい方
前提
- キカガクでは Devin を全エンジニア（15 名前後）が利用可能
- うち３名が主なヘビーユーザー
- 導入１ヶ月目のセッション立ち上げ数は 117 セッション
- 消費 ACU は約 450 ACU /月
- これくらいの規模感で得られた知見の紹介
前置きは以上で、ここから本題です。
1️⃣ Session Insights で消費 ACU の多いセッションを振り返る
正直、コスト最適化の取り組みはこれだけで十分というレベルです。
それくらい強力な分析ツールになりますので紹介させてください。
従来のコスト分析方法は Usage History を見る以外に手段がありませんでした。（おそらく）
※ Usage History とは以下の画面です。セッションに対する消費 ACU を一覧で確認ができます。
※ 他にもセッション詳細から Devin のアクティビティを追う方法もありますが、ACU を消費している部分を探し出すのに一苦労な印象で現実的な方法ではない印象です。
Usage History に頼りすぎると以下の観点で正確な分析ができません。
- 「消費 ACU = タスクの粒度」ではない
- 以下のような複数の要因が絡み合い ACU が消費される
- 信頼度
- メッセージの回数
- CI の実行時間
- 以下のような複数の要因が絡み合い ACU が消費される
- そのため Usage History を見るだけでは何に無駄に ACU を消費してしまったか分析ができない
- つまりコスト最適化として取れる手段がタスクの粒度の見直しだけに限られてしまう
そこで、上記のような要因を視覚化できる機能こそが Session Insights です。
Session Insights はセッション詳細の以下の箇所から閲覧が可能です。
Session Insights からは以下の２つの情報の閲覧が可能です。
- ✅ セッション内のどのフェーズで ACU 負荷が高かったのか閲覧可能
- ✅ より正確なアウトプットを出すためのお手本プロンプトの表示
Session Insights を少し見るだけでもコスト最適化のヒントがたくさん見つかります。
例えば弊社では Session Insights を見ることで以下のような問題を発見できました。
- CI 待ちによる余計な待機時間が発生している
- レビュー回数が多いがために過剰に AUC を消費
- あいまいな指示による Devin の過剰な考察
Session Insights を見て、対策と改善を実行していくことこそが簡単かつ効果的なコスト最適化手法だと思います。
運用２ヶ月目以降は Session Insights を週に１回は振り返る時間を作り、より効率的に ACU を使えるように運用を改善していきます。
2️⃣ セッションごとの消費 ACU は 5 以下を目指す
弊社の１ヶ月間の Devin の活動記録を分析すると以下の様になっていました。
| PRの状態 | 平均消費ACU |
|---|---|
| merge された PR | 3.8 |
| close された PR | 5.3 |
なんと merge された PR よりも close された PR のほうが平均消費 ACU が高い傾向にありました。
このことから「ACU の過剰消費 = PR が merge される確率が下がる」可能性があるということがわかります。
参考までに Devin の Session Insights から閲覧できる情報です。
セッションごとの消費 ACU は 10 以上は推奨されていないようです。
では非推奨に近い 10 ACU 付近のセッションをもう少し振り返ってみると 10 ACU 付近のセッションは単純に「タスクの粒度が大きい」のではなく以下のような傾向が多いことがわかりました。
- タスクの粒度自体は 5ACU 以下のタスクとそこまで大きく変わらないものもある
- 最初のプロンプトが悪く実装内容の精度が悪い
- そのためレビュー修正が多く過剰に ACU を消費
- その他の要因で過剰に ACU を消費している
つまり「5ACU 程度タスク + 過剰な ACU 消費 = 10ACU 付近」です。
あくまで弊社の利用状況からの考察ではありますが上記のようなセッション傾向があったので、セッション単位では 10 ACU ではなく 5 ACU を目安として運用２ヶ月目以降はタスクの粒度設計をしていこうと思います。
3️⃣ 信頼度は「High 🟢」にしてから Devin に作業してもらう
Devin 運用開始直後に小さめタスクをいくつか依頼してみた結果、信頼度は「Medium 🟡」でも十分期待する PR が生成可能だということがわかりました。
そのため運用初期段階では、信頼度「Medium 🟡」であれば実装をしてもらって OK としていました。
ただ、実際にこのルールで運用を１ヶ月行い１ヶ月の振り返りを行ったところ...
作成された PR のうち 17% が close されているという結果となってしまいました。
※ 初期段階の検証用の PR の close なども含まれるのでそのあたりを精査したらもう少し割合は下がりそうですが...。
個人の感覚ですが信頼度における PR の質は以下のようになっていそうです。（体感）
- 信頼度 High 🟢：8 ~ 10 割の確率で期待する PR を作成可能
- 信頼度 Medium 🟡：6 ~ 8 割の確率で期待する PR を作成可能
- 信頼度 Low 🔴：未検証
まぁ、黄色でもそれなりに良い PR は作成されるのですが結局レビュー修正などがかさむとそれに伴い消費 ACU も増えてしまうので１撃で良い PR を作成してもらうというのが一番のコスト最適化だと考えています。
そのため運用２ヶ月目以降「High 🟢」を意識することでどれくらいコスト最適化につながったかはまた１ヶ月後にブログにしようと思います。
4️⃣ Devin とのやり取りは「実装前の指示＆レビュー修正依頼」の２回まで
「え、メッセージ２回までは少なすぎじゃない？」と思われる方もいるかもしれません。
もう少し具体的に記載すると以下のようになります。
-
Devin にタスク依頼
- ここでは信頼度🟢になるまでは何回メッセージを送っても OK
- ※ メッセージの都度、Devin の考察が走るのでもちろん回数は少なければ望ましい
- ※ 理想は最初のメッセージで信頼度🟢を出す - 信頼度🟢になったら実装をしてもらう
これをやりとり１回目とカウント
- ここでは信頼度🟢になるまでは何回メッセージを送っても OK
-
Devin が PR を作成
- レビュー修正をする必要があれば何件コメントを入れても良い
- コメントに対するレビュー修正は Devin に任せる
これをやりとり２回目とカウント
-
Devin によるレビュー修正が完了
- ここで意図するような修正ではなかった場合には作業は人間が引き継ぐ
- 原則、これ以上のレビューコメントはしない
- ※ レビュー内容次第で最終的には個人の判断に委ねる
特に３.の部分での再レビューコメントを原則しないこととしているのは以下の通りです。
- Devin に限らず AI は修正作業のさらなる修正にめっぽう弱い
- 間違った修正に FB を送ると、さらに変に解釈されて実装もおかしな方向に進むことが多い
- そこで時間を浪費する可能性があるのであれば人間でサクッと直したほうが効率的
-
Session Insights 機能で確認すると PR の diff が１行の PR でもレビュー修正を重ねることで消費 ACU が増えてしまう傾向があった
- Devin の Session Insights で指摘されている実例
２回というのは過剰な指標かもしれないですが、「Devin とのやりとりは最小限にとどめタスクを完了さえること」がコスト最適化につながってくると思うので、運用２ヶ月目以降は Deivn とのやりとりを２回までを１つの指標として運用をしていきいます。
5️⃣ Pending 状態になる PR 上の CI がある場合は要注意
最後は限定的な条件下でのコスト最適化戦略となりますがご了承ください。
例えば Chromatic を PR の CI で実行すると以下のように CI が Pending 状態となります。
Devin を活用するうえでこの CI の Pending 状態が非常に危険です。
通常 Devin は何も指示がなければ 30 分経過後に Sleep 状態に移行するため過度な ACU 消費を抑えることができます。
ただ作業中に CI の Pending を観測すると Devin は 30 分経過後にも Sleep することはなく弊社の観測だと PR の作成からなんと 1 時間 30 分 Sleep せずに CI が完了するのを待機していました。
Session Insights で状況を確認すると以下のような問題点が指摘されていました。
これによりわずか１行の修正を行った PR でも 10 ACU 以上消費されている...というケースが複数件発生していました。
こちらの現象に関しては以下のような Knowledge を入れることで解決が可能でした。
Knowledge：UI Review と UI Test は手動確認が必要なチェックです。他の CI チェック（build、test など）が通過していれば、PR はレビュー可能な状態と判断できます。
その他、コスト面以外で設定している組織ルールをついでに紹介
Devin を運用していくなかで「組織でやるならこんな感じがいいのでは？」というルールもいくつか設定して運用していますのでそちらもせっかくなので紹介します。
1️⃣ タスクの依頼は Slack の #team-devin-task 以外では禁止
Devin は Slack 連携をしておくと基本的には「どのチャンネルでも」「どのメッセージスレッドでも」@Devin とメンションをつければいつでもタスクの依頼が可能です。
ただこの柔軟性を運用１ヶ月目では禁じました。
理由としては「誰がどんなタスクをどのように依頼しているのか」を全員で見える化したかったからです。
この運用により以下のようなメリットがありました。
- 日々どれくらい Devin が活用されているのかリアルタイムで分かる
- どれくらいの粒度のタスクを依頼すると良さそうか Slack のメッセージを見るだけで暗黙知が出来上がる
- 依頼がひとつのチャンネルに集まることで Devin がたくさん使われている感が生まれ Devin にタスクを依頼しやすい雰囲気を作ることができる
せっかく『Devin 使い放題』が許可された環境なのでたくさんのメンバーにたくさんタスクを依頼してほしく設定したルールでしたがある程度うまいこと機能していたと思います。
この運用は２ヶ月目以降も継続していこうと思っています。
2️⃣ どんな粒度/内容のタスクでも依頼 OK
Devin に依頼するタスクに関しては一切の制限を設けていません。
ただし Devin のドキュメントにはタスクのベストプラクティスとして「ジュニアエンジニアレベルの複雑さ」と明記されています。
Junior engineer level complexity.
https://docs.devin.ai/get-started/devin-intro
この基本原則は全員で頭に入れつつも「これ Devin に任せてもいいですかね？」的な承認フローは必要とせず、どんな粒度/内容のタスクでも Devin に依頼しても良いとしています。
タスクの複雑性に関してはそもそもタスクの言語化がむずかしい場合は依頼もできないはずなので、Devin に依頼できる時点である一定の複雑さの境界は超えることはないという判断です。
またこのルールで運用を続けて良かった点としては「やったほうが良いけど必須ではない」タスクがどんどん消化されていったことです。
例えば「ここにコピーボタンついてたら便利だな...」など改善点がふと思い立った時に、すぐに Devin にタスクを依頼して実装してもらうという雰囲気が徐々に形成されています。
運用２ヶ月目以降もどんどん Devin に依頼しても良い雰囲気を作るべくこのルールも継続です。
3️⃣ Devin には Issue と PR をセットで作ってもらう
Knowledge コピペ用
1. ユーザーから Issue の提供がなかったら PR を作成するリポジトリと同じリポジトリに Issue を作成すること
- Issue の作成は常に最初に実行し、以下を記載
- Devin が考えたタスクの計画内容も記載すること
- ユーザーからの指示に関しても「ユーザーからの指示」のような見出しを作り issue に記載すること
- Issue の Assign は PR の Reviewers と同じ人を設定すること
2. ユーザーから既存のissueが指定された場合は、新しいissueを作成せず、指定されたissueにコメントを残すこと
3. PR の概要欄には作成した Issue を「Closes #Issue番号」のような形式で記載すること
- これは Issue に PR を紐づけるための重要な操作です
- ユーザーから Issue の提供があればその Issue を PR に「Closes #Issue番号」のような形式で記載すること
全てのリポジトリに対して上記の Knowledge を適用しています。用途としては以下のとおりです。
- Devin に依頼したタスクの振返りや集計に活用したい
- 期待する PR が作成できなかった際（レビューでも修正不可なレベル）に Issue に記載のある実行計画を人間が手修正することでそれをそのまま新しい Devin に依頼できるように
- Copilot Coding Agent や Claude Code Actions との性能比較を簡単にできるように（同じ指示や実行計画でのアウトプット比較）
- Issue さえあれば Assign(Copilot) or メンション(Claude) で実装してもらえますからね
- 作成された PR をローカルにチェックアウトする際に Issue をコンテキストとして活用できる
上記のように当初は考えていたのですが、そのように現状活用されているかというと...正直されていないです。（されていないというよりも、活用するケースがない）
このルールに関してはもうしばらく続けてみようとは思っています。
4️⃣ 毎朝 9:30 に 24 時間以内にマージされた PR を Slack へ送付
Devin の立てる PR は Devin 依頼者ではなく Bot(Devin) となります。
弊社ではブランチのプロテクションルールとして１名以上の Approve を必須としています。
つまり Devin の PR に限っては PR の作成者が Devin になりますので自分で Devin に PR を作らせて、自分で Approve して、自分でマージするというセルフスタイルが仕組み上は可能というわけです。
※ 弊社では Devin の運用においては、現状はこのセルフマージを許容しています。
そのためチーム内で Devin の PR がどれくらいマージされたのか把握がむずかしいという課題がありました。
※ Slack を見ているだけではどのリポジトリでどれくらいのタスクが１日に依頼されたのか把握しづらい
そこで「AM 9:30 に 24 時間以内にマージされた PR を Slack へ送付するスクリプト」を作成しました。
※ これ自体は Devin の機能でもなんでもなく単純に TypeScript で作ったスクリプトを Cron でクラウド環境で定期実行しています。
この仕組みがあるおかげで以下のようなメリットがありました。
- マージされた PR を一覧で確認できるのでデイリースクラムでのリリース計画が立てやすくなった
- セルフマージが可能な状況でどんな PR がマージされたのかメンバー全員が把握しやすい
この定期通知は、1️⃣ で書いたような特定チャンネルの縛りを解禁した後も有効かと思うので、今後もずっと続けていこうと思います。
まとめ
以上が、キカガクで取り組んでいる、もしくはこれから取り組もうと思っている『Devin 使い放題』なコスト最適化ルールでした。
- 1️⃣ Session Insights で無駄な ACU 消費を発見
- 2️⃣ セッションごとの消費 ACU は 5 以下を目指す
- 3️⃣ 信頼度は🟢にしてから Devin に作業してもらう
- 4️⃣ Devin とのやり取りは「実装前の指示＆レビュー修正依頼」の２回まで
- 5️⃣ Pending 状態になる PR 上の CI がある場合は要注意
- 番外編
- 1️⃣ タスクの依頼は Slack の #team-devin-task 以外では禁止
- 2️⃣ どんな粒度/内容のタスクでも依頼 OK
- 3️⃣ Devin には Issue と PR をセットで作ってもらう
- 4️⃣ 毎朝 9:30 に 24 時間以内にマージされた PR を Slack へ送付
最後に（宣伝）
わたしの X アカウントでは AI 活用に関する情報を日々情報発信しております！
ぜひフォローおねがいします！
また、株式会社キカガクでは組織全体で AI 活用の積極的な推進をしています！！
AI 活用に興味のある方、自信のある方はぜひ「求人一覧」のぞいてみてください！
Discussion