DeNA 的 Devin Enterprise 導入 ~8つの課題とアプローチ~

はじめに

こんにちは、IT基盤部の小池です。副部長とパブリッククラウドチームのリーダーを兼務しています。

2025年7月、 DeNA AI Link は Cognition AI と戦略的パートナーシップを締結しました。

このパートナーシップの一環として、DeNA は AI ソフトウェアエンジニアである Devin のエンタープライズ向けプラン「Devin Enterprise」の社内導入を進めています。すでに Devin Team は導入済みですが、よりセキュアかつ大規模に Devin を活用するためには Devin Enterprise が不可欠だと考えたためです。

しかし、Devin Enterprise の導入には、多くの課題があることも事実でした。そこで私たちは、以下の三段階に分けて段階的に社内展開を進めていく計画を立て、その計画通り展開を進めています。

段階	人数	説明
$\boldsymbol{\alpha}$	50人	主要機能の価値を検証する初期段階。手作業による運用や、システムの不安定さが残ることを前提とする。
$\boldsymbol{\beta}$	200人	対象範囲を拡大し、実用化に向けた改善を進める段階。運用の自動化とシステムの安定性向上に注力する。
GA	1,000人~	全社展開フェーズ。$\alpha$, $\beta$ 版で特定した課題をすべて解決し、高い品質（QCD）での安定稼働を実現する。

この記事では、DeNA のパブリッククラウドチームが Devin Enterprise の導入準備を進める中で明らかになった期待と現実、そして導入の課題にどう立ち向かっているのか、そのリアルな実態と具体的なアプローチを共有します。

Devin とは？

「Devin」は、ソフトウェア開発プロセス全体を自動化する革新的な自律型のAIソフトウェアエンジニアです。従来のコーディングを補助するAIツールに対し、「Devin」はコードの作成だけでなく、要件定義、設計、コーディング、テスト、デプロイまでの複数のタスクを統合して、効率的かつ精度高く自律的に実行できます。また、コードの変更後にテストを実行し、最終的に人間がレビューできる形にまで仕上げることなども可能です。

Devin Team と Devin Enterprise の比較

Devin には、個人やチーム向けの「Devin Team」プランと、より大規模な組織向けの「Devin Enterprise」プランがあります。

機能	Devin Team	Devin Enterprise
データプライバシー	Cognition AI 社の環境で管理される ( “Opt-Out” は可能)	ユーザー所有のクラウドアカウント内の環境で管理できる
組織管理	１アカウント毎の管理	SSO 連携を含めたマルチアカウント管理
コスト管理	Devin Team のアカウントごとの ACU (Agent Compute Unit: Devin の作業単位) 管理	組織内での ACU 共有
インテグレーション	GitHub, Slack	GitHub, Slack, Self-Hosted Services (Jira Server / GitHub Enterprise Server など)

DeNA が Devin Enterprise に期待した点

DeNA が Devin Enterprise に期待したのは以下の点です。

自社データを “物理的” に他社と独立した環境に保存できること
DeNA 的なクラウドアカウント管理¹ができること
1. DeNA 的なマルチアカウント管理²
2. 組織全体のコスト管理・最適化
3. SSO 活用によるユーザーの権限管理
4. 管理用 API による運用自動化
Devin Team と同等、あるいはそれを上回る使い勝手であること
1. Slack をインターフェースとし、あたかもチームの一員として Devin に指示ができること
2. GitHub Enterprise Cloud (GHEC) と連携し、自律的な開発ができること
GitHub Enterprise Server (GHES) とも連携ができること

Devin Enterprise の導入を進めてみてわかった点

実際に Devin Enterprise の導入準備を進めてみると、期待通りだった点と、導入の課題となる点が明らかになってきました。

まず、DeNA が期待していた点についての評価を表にまとめます。

期待した点	評価
1. 自社データを “物理的” に他社と独立した環境に保存できること	○
2-1. DeNA 的なマルチアカウント管理²	○
2-2. 組織全体のコスト管理・最適化	○
2-3. SSO 活用によるユーザーの権限管理	△
2-4. 管理用 API による運用自動化	△
3-1. Slack をインターフェースとし、あたかもチームの一員として Devin に指示ができること	△
3-2. GitHub Enterprise Cloud (GHEC) と連携し、自律的な開発ができること	△
4. GitHub Enterprise Server (GHES) とも連携ができること	×

DeNA の期待にマッチしていた点

まずは、DeNA の期待にマッチしていた点を説明します。

1. 自社データを “物理的” に他社と独立した環境に保存できること: ○
- Devin Enterprise は、ユーザー所有のクラウドアカウント内の VPC （カスタマー VPC）内にデータを保存することができ、実際に我々のデータが保存されていることを確認できました。
- Devin Enterprise の構成図: https://docs.devin.ai/enterprise/deployment/overview から引用 (2025年9月19日時点)
2. DeNA 的なクラウドアカウント管理¹ができること
- 2-1. マルチアカウント管理²: ○
  - Devin Enterprise は、組織全体を管理する管理 Organization と、その配下である Sub-Organization というツリー構造を作ることができます。
  - これにより、組織の管理者が管理することと、Sub-Organization の利用者が管理することを分割することができました。
    - 組織の管理者が管理すること
      - Sub-Organization の発行・解約
      - Sub-Organization と GitHub / Slack の紐付け
      - 各 Sub-Organization の ACU 上限設定と利用状況の確認、その ACU コストの支払いと計上
    - Sub-Organization の利用者が管理すること
      - Sub-Organization を利用できるメンバーの管理
      - Devin の実行
  - Devin Enterprise のマルチアカウント管理
- 2-2. 組織全体のコスト管理・最適化: ○
  - Devin Enterprise では、Devin リソースの利用単位である ACU を組織全体で共有できます。
    - これにより、組織全体で利用状況を平準化しコストを最適化できました。
    - Sub-Organization ごとに ACU の利用上限を決めることもできるので、予算に応じたコストの管理も可能でした。
- 2-3. SSO 活用によるユーザーの権限管理: △
  - Devin Enterprise では、 Okta などと連携した SSO が可能です。
  - また、内製の IdP による SSO にも対応することができました。
  - ただし、SSO 導入への課題もあったので、それに関しては次の節で説明します。
- 2-4. 管理用 API による運用自動化: △
  - Devin Enterprise では管理用 API が提供されており、Sub-Organization の作成などの一部作業を自動化することができました。
3. Devin Team と同等、あるいはそれを上回る使い勝手であること: △
- Slack, GHEC との連携はできましたが、連携の自由度が低いなど使い勝手が悪い点もありました。
4. GitHub Enterprise Server (GHES) とも連携ができること: ×
- 導入への課題があり、DeNA では GHES との連携ができていません。

課題とその具体的なアプローチ

DeNA の期待にマッチしていた部分もあった一方で、多くの課題も存在しました。ここではその具体的な内容と、私たちがどのように対処しているかを紹介します。

1. カスタマー VPC (Amazon EC2 インスタンス) の管理

課題:
- Devin Hypervisor 用の Amazon EC2 インスタンスを自社で運用する必要があります。これには、当然ながら運用監視のコストが伴います。
具体的なアプローチ:
- 地道に運用します。SRE としての腕の見せ所です。

2. Devin Hypervisor 用の Amazon EC2 インスタンスのコスト

課題:
- AWS で運用する場合、Devin Hypervisor 用の Amazon EC2 には i3.metal インスタンスが推奨されます。これはオンデマンドの場合、月額約 $4,274.88 もかかります (2025年9月時点、東京リージョン・オンデマンド価格)。
具体的なアプローチ:
- Reserved Instances (RI) や Savings Plans (SP) を活用してコストを最適化します。将来的には、スポットインスタンスの活用やオートスケーリングの導入が可能か検討し、さらなるコスト削減を目指します。

3. ACU の利用状況ダッシュボード

課題:
- 各 Sub-Organization ごとの消費 ACU 状況を把握するためのダッシュボードがまだ提供されておらず、組織管理上の課題があります。
  - 現時点で提供されているダッシュボードは、「組織全体の月/日ごとの ACU 利用量」「ユーザーごとの ACU 利用量」
具体的なアプローチ:
- 管理用 API から利用状況の JSON データを取得し、必要な情報を抽出・加工する簡易的なツールを内製しています。

4. SSO 連携

課題:
- 管理者が SSO を管理するための WEB UI がなく、SSO 用の認証情報を Cognition AI の担当者と直接やりとりする必要があります。これにはセキュリティ上の懸念とコミュニケーションコストが伴います。
- Devin Team で利用しているドメイン (@example.com など) を Devin Enterprise の SSO に設定すると、そのドメインのユーザーは Devin Team が利用できなくなります。
具体的なアプローチ:
- 認証情報の受け渡し方法を工夫し、セキュリティリスクを可能な限り減らしています。
- Devin Team を利用したいユーザーには、別ドメイン (@example.jp のようなエイリアスなど) で登録してもらうようアナウンスしています。

5. Sub-Organization 作成業務の自動化

課題:
- API で自動化できる作業と、手動で実施しなければならない作業が混在しており、完全な自動化は現状できません。
具体的なアプローチ:
- API で可能な範囲のみ自動化し、残りは手作業で対応します。将来的には、API で対応できる範囲を広げてもらえるよう、Cognition AI と継続的にコミュニケーションを取っています。

Sub-Organization 作成 ToDo と API の有無

タスク	API	備考
Devin Sub-Organization 作成	○
Devin Organization ユーザーの作成	○
Devin Sub-Organization へのユーザー紐付け	○
SSO 用 Google Group の作成	○	Google Workspace の API を利用
Devin Sub-Organization に GitHub Organization を紐付け	×	手動。GitHub Organization の Owner 権限が必要
Slack Channel の作成	○	Slack の API を利用
Slack Channel を Devin Sub-Organization に紐付け	×	手動

6. Slack 連携

課題:
- Slack 連携は Enterprise Admin のみが設定可能で、Sub-Organization の管理者に権限を委譲できません。
- 1 Devin Organization に対して 1 Slack Workspace しか連携できず、1 Sub-Organization には 1 Slack Channel しか紐付けられません。
  - 1 Slack Workspace で運用する場合、その Workspace に全 Devin Enterprise ユーザーが入る必要があります。これは情報統制上の課題になり得ます。
    - 例えば Public Channel と Devin Sub-Organization を紐付けてしまうと、その Slack Workspace に属している人はすべてその Channel の閲覧権限があることになります。
    - そうすると Devin Sub-Organization との権限差分が生まれ、本来その情報が閲覧できてはいけない人にも閲覧できてしまうという状況となり得ます。
    - よって、Devin Sub-Organization に紐付いた Slack Channel の権限管理が重要です。
具体的なアプローチ:
- Devin Sub-Organization と Slack Private Channel の紐付けは、Devin Enterprise Admin の手作業で行います。
- Devin 専用の Slack Workspace を一つ用意し、そこに各 Devin Sub-Organization ごとに Slack Private Channel を作成します。Slack Private Channel と Devin Sub-Organization のユーザーを一致させることによりプロジェクト外のユーザーの操作を禁止します。

7. GitHub 連携

課題:
- GitHub 連携も Enterprise Admin のみが設定可能です。Sub-Organization の管理者に権限を委譲できません。
- Sub-Organization 間の GitHub 権限が不安定な場合があり、関係のない Sub-Organization のリポジトリへの Write 権限が付与されてしまうケースがありました。
- GitHub Apps などを利用した WEB UI 上での GHES 連携が、まだサポートされていません。
具体的なアプローチ:
- Devin Enterprise Admin は GitHub Organization との紐付け作業を行います。
- 権限の不安定さに対しては、Devin の Repository Permissions が正しく設定されていることを都度確認することで対応しています。
- GitHub 連携については、現状は GHEC のリポジトリのみを連携対象としています。
  - Cognition AI からは「GHES の Organization Admin の PAT (Personal Access Token) を担当者経由で共有してくれれば連携できる」という提案もありましたが、現状 DeNA ではその方法を採用していません。

8. Cognition AI とのコミュニケーション

課題:
- ドキュメントがまだ十分に整備されておらず、仕様の確認や問題解決のためには Cognition AI との密なコミュニケーションが不可欠です。
  - 当然ながら、コミュニケーションは英語で行われ、かつ米国との時差があるため、迅速な問題解決が難しい場合があります。
具体的なアプローチ:
- 英語でのコミュニケーションには AI (翻訳ツールなど) を積極的に活用し、少しでもスムーズにやりとりできるよう工夫しています。

おわりに

Devin Enterprise の導入は、まさに最先端の技術と共に新しい道を切り拓く挑戦です。期待通りだった点、そして導入の課題と私たちの具体的なアプローチをまとめると、以下のようになります。

	DeNA の期待にマッチしていた点	課題と具体的なアプローチ
セキュリティ	○ カスタマー VPC によるデータの物理的な分離	△ SSO や GitHub 連携時の手動設定 (セキュリティリスクとコスト)
組織管理	○ マルチアカウント管理、SSO	△ API の不足による一部手動運用
コスト	○ ACU 共有による組織管理と最適化	△ Hypervisor の EC2 コストが高い、利用状況の可視化が不十分
連携機能	○ Slack, GHEC との連携	× GHES 未対応、連携設定の自由度が低い
運用	-	△ ドキュメント不足、コミュニケーションコスト