1. はじめに
こんにちは。DMM.comでプラットフォーム開発本部の副本部長をしている石垣です。 今回は当社で実施したAIエージェント「Devin」と「Cline」の導入検証の結果について共有したいと思います。
DMMグループのクリエイター組織は、現在1,200名近くのメンバーを抱え、エンジニアだけでも1,000名近くのメンバーがいる組織です。 この規模感を考えると、AIとの協働を行い開発組織のわずか数％の生産性向上であっても、事業全体へのインパクトは非常に大きくなります。 小さな改善の大きな積み重ねが競争力を高める重要な要素になると考えています。
こうした背景から、昨今急速に進化しているAIエージェント技術に着目し、開発者の生産性向上と業務効率化を目指して約2週間のトライアルを行いました。
選定したツールの立ち位置としては、開発者と帯同しながら同期的に生産性をあげていく「Cline」を選定し、もう一つは完全独立型AIとして「Devin」を選定しました。人間の開発者とは独立して動作し、Slackで指示を出しながらもほぼ非同期的にタスクを処理します。ある種、新しいメンバーを加えるのに近い形でタスクを任せることが可能になります。
具体的な目的と評価指標は以下の2点です。
- 人間が開発したときの工数予測と実際にAIエージェントで自動化または副操縦士として並走したときの実工数の違い（どれだけ早く価値提供できるのか）
- 純粋な開発作業が早くなる以外の開発者体験向上の発見があるか
2. 制約
利用するにあたって、いくつかの制約を設けました。
- 部門ごとにDevinを管理するのではなく全社横断して運用する（DevinをGitHubに繋ぎこむにあたり、DMMは単一のGitHub Org運用してため1つのOrgに対して1つのDevinを紐づけています）
- Clineは、ClaudeやOpenAIといったコンシューマ系のLLMに直接繋ぐのではなく、AWS/Google/Microsoftのマネージドサービス経由（Amazon Bedrock..etc）で繋ぎこむことを情報管理観点でデフォルトにする
3. トライアル成果
2週間やった成果として今回のトライアルでは、品質向上、工数短縮、エンジニアの学習効率アップという3つの面で大きな可能性を示唆してくれました。
発見1. 技術負債の特定とリファクタリング実装の半自動化
弊社在籍のミノ駆動さんの取り組みですが、Clineを通じて技術負債の分析と特定、並びにリファクタリングの半自動化を検証しました。 これが成功し、水平展開できれば、組織レベルで爆発的に負債解消できる期待を持っていました。
やったことは以下の2点です。
- 負債の分析方法やリファクタリング方針に関するプロンプトを記述したmarkdownをリポジトリに用意
- Clineがリファクタリングの指示を受けたときに上記markdownに基づいて負債分析やリファクタリングをするよう.clinerulesに記述
結果としては、技術的負債の分析による特定は実用レベルと言えるところまでトライアル期間で実現できました。
実際に、特定からのリファクタリング実装は精度が十分ではなかったですが時間の問題とも言えます。 これをうまく活用できれば、ドメイン駆動設計における技術負債の特定および設計スキルの向上はスケールさせることができ、将来の変更コストが削減できると期待しています。
発見2. イベントストーミングで設計した画像をもとにドメインモデルと制約の実装
特に印象的だったのは、Devinを活用したドメインモデルの実装です。イベントストーミングで作成した設計図を画像としてDevinに提供したところ、その内容を正確に理解し、制約を含めたドメイン層のコードとテストケースを生成しました。 マルチモーダルなのでテキストだけではなく、普段チームで使っているツール上のもの（他で言えばPlantUMLなども）を連携して認識させることでDevin側の理解が進むのはとても便利だと思いました。
発見3. 指示範囲を明確に絞れば、人より格段に早い
バグの特定やテストケースの拡充、ライブラリのアップデートといった負債解消の保守開発の部分は人間がやるよりも早いという結果になりました。特にDevinを代表とする完全自律型AIであれば人間と非同期にできるため効果は大きいと感じます。
| # | 概要 | コスト | Cline / Devin | 人 | 備考 |
|---|---|---|---|---|---|
| 1 | バグの特定・実装修正 | $0.62 | 1h | 2h | 開発者がこのファイルが怪しいというヒントは与えたもののClineが3mくらいでバグの特定を行ってくれ、工数が大幅に削減できた |
| 2 | ライブラリのメジャーアップデートに伴うエラーを修正 | $0.17 | 15m | 1.5h | ESLintの設定周りの汎用的な知識をCline(というかClaude)が持ってくれているおかげで、調査時間を大幅に削減できた |
| 3 | テストケースの拡充 | $0.15 | 7m | 1h | 特に技術負債が多いコードの理解は人間が見るよりDevin/Clineのほうが読み解きが早いため有効だった |
| 4 | 小さな新機能追加 | $1.25 | 1.5h | 2.5h | Clineが既存コードを参考にしながらベースとなる実装・テストケースを書いてくれたので、多少の手直しをするだけで済んだ |
発見4. 開発者の学習効率を上げる
Clineに関しては開発コストの削減というメリットも大きいですが、並走して開発してくれることで開発者の学習に繋がる効果も発揮しました。 例えば、バグの特定を依頼した際にClineが仮説を立ててファイルを調査する思考ステップを示すため「こういう仮説があるので、このファイルを見ます」「このファイルが大丈夫だったので次はこのファイルを見ます」といった風にステップbyステップで進めてくれます。これはオンボーディングにも使えると感じました。
Devin or Cline？
エンジニアの挙動を見ていると、まず「Cline」を使い、AIリーダブルな指示の出し方やコードの書き方に慣れていき、そのあとにDevinを活用する順番が効率的だと感じました。 Devinを利用し始めても、指示出しの勘所がわからず無駄にコストを使うことが多くありましたが、Clineからはじめることで「これは非同期でDevinに任せても良いな」という判断ができるようになりました。
また、ClineにもAuto approve機能がありDevinのように半自動で自律的にコードを書いてくれるため、ほぼ同じ挙動をします。
そのため、今後どちらに投資するべきかは考えていなければなりません。細かい違いとしては、DevinはPRまで作成してくれる一方、Clineの場合は.clinerulesに細かくブランチ名のルール、どのPRテンプレを使うか、PRを作る際のコマンドを指定しなければいけません。その他にもDevinの場合はSlackを経由できるインターフェースがあったり、課金体系（DevinのBilling）の違いがあったりします。
25年3月25日のDevin 1.5のアップデートでは、「Devin IDE」と題してVSCode環境で操作が可能になりました。 Devinの編集内容をリアルタイムでチェックし、変更点を修正したり、使い慣れた IDE ツールやショートカットを使用してDevin のコードを直接テストができることから、その差はどんどんなくなってくるのかもしれません。
引用 : https://docs.devin.ai/release-notes/overview
以上がトライアルで得られた結果でした。 それ以外にも、DatadogのMCP サーバを作りClineとログの連携をすることでエラーの問題を発見したチームもありました。過去のインシデントの事例などのドキュメントを連携し障害調査を半自動化できそうという所感も示されました。
4. 25年3月時点での課題
多くの成果が得られた一方で、いくつかの課題も見えてきました。
- ドメイン知識の教示について。AIに適切な指示を与え期待する成果を得るためには、ドメイン知識を効果的に伝える方法を確立する必要があります（ドメイン層がAIリーダブルな形で書かれていれば精度は出る）
- 1,2割の確率でプロンプトの指示に従わないことがあったり、指示以外の余計なことをするケースもあるので改良が必要です
- コストについて、サービスとして利用しているAWSアカウントでBedrockなどに繋ぎ込んでいるとAIに投資したコストと純粋なサービスコストの内訳見えづらいので分けて管理が必要です
- Actionフェーズでの試行錯誤によるコストの無駄遣いが起こる。Devin/Clineを使っていると早く実行し成果を得たくなるのでPlanフェーズを短縮しがちになります。コスト削減も考えてここのノウハウを確立していきます
5. 投資対効果と組織スケールの変化
また、組織としてAIツールにコストをかける以上費用対効果については考えていかなければなりません。
AIツールの投資対効果
AIツールにかけたコストが元を取れているかの計算は比較的簡単だと思っています。 特定のタスクに対して「人でやった場合」「AIエージェントの場合」を明確にしていきます。人でやった場合については予測になるため通常通り、見積りから算出していきます。
| 項目 | ヒト(予測) | AI | 削減時間 |
|---|---|---|---|
| Issue-a | 5h | 1h | -4h |
| Issue-b | 10h | 1h | -9h |
| Issue-xx | ... | ... | ... |
このデータを半自動的に取り込み積み上げていけば、月間2人月（360h）が削減できましたというデータが理論上出来上がってきます。
AIツールによって変化した組織スケールの方法
この数値をもとに以下の選択肢が考えられます。
- 採用計画として1名プレイヤーを採用しようとしたが、AIツールで代替し人材関連費の削減ができる
- 採用計画はそのままで、開発者全員がAIを使って価値提供を早めていこう
- 採用計画を変更し、作業・労力はAIツールで効率化できるので組織のゲームチェンジャー、ハイレイヤー採用に注力しよう
これらの選択肢を考える時に、従来の組織スケールのやり方から頭を切り替えなければいけません。
組織目標を達成するための生産量を確保するために、従来のように人を採用して生産量を上げていくのか、AIツールのようなライセンス料にお金をかけていくべきなのかはすでに直面している課題ではあります。
なぜなら、従来の人員増加によるコストスケールとAIツールの活用ではコストのかかり方が大きく異なるからです。 良くも悪くも、人を採用すると人材関連費が固定でかかります。雇用形態によって変わってきますが、メンバーの採用からオンボーディングまではリードタイムがかかりますし、さらに環境によってはモチベーションに変化が生まれ、同じ人でもパフォーマンスの違いが出てくるでしょう。
一方、非同期で動いてくれるDevinやClineは稼働させるタイムボックスがこちらで設定できるのでうまく使えばコスト的にもコントロールしやすくなります。 とはいえ、Devinは課金体系（タスクを任せるたびにACUというクレジットが減っていく）からも分かるとおり、きちんとlimit（pay-as-you-go）の制限をかけながらタスクを任せるようにしないと課金額が膨れ上がります。従来の再現性があるコンピュータというより、優秀な人（AI）という形で扱っていく必要があります。 Clineについても同様で強制停止がしづらいため工夫に必要です。
今後の選択としては、人を増やすのか / 個の生産性をあげるAIツールに投資するのか / 人の代わりに完全自律型のAIツールを増やすのかを柔軟に考えていかなければいけないと考えています。
今後の展望
組織として先行して進めたトライアル結果を開発組織全体に共有したことで、今では他の開発組織にも波及し利用組織も増えてきました。 日々、Slack上で知見が溜まっていく様子を見ていると組織がどんどん強くなっている実感があります。
今回紹介したツール以外にも、開発フェーズの前工程として、企画やリサーチ、デザイン、PRDやDesign Docといった設計フェーズ、そこからのPBI作成といった工程についてもAIを活用できれば、全体的なリードタイムの短縮につながると考えています。そのため、うまくMCPやプラットフォームに乗っかりながら進めていきたいと思っています。
DMM.comではエンジニアを随時募集しています。 カジュアル面談も行っていますので、気軽に話したい方はぜひお申し込みください。
