Devinは2026年現在、自律型AIエンジニアとして注目を集めるAI開発ツールである。プロンプトを渡すだけでコーディング・PR作成・テスト実行までを自動で行う。本記事では、Devin APIを自社システムに統合する際の実装パターンを、renueが実装している`DevinClient`をもとに解説する。セッション管理、ACU(Agent Compute Unit)制御、プレイブック活用、3階層のエラーハンドリングまで、本番運用に耐える設計を公開する。
Devin API統合の基礎
Devinはブラウザ経由だけでなく、REST APIで外部システムから制御できる。これにより以下のような運用が可能になる。
- Slackからの起動: ボットコマンドでDevinセッションを開始
- CI/CDとの連携: PRコメントでDevinを呼び出し
- チケット駆動開発: JiraチケットからDevinに自動割当
- 大量タスクの並列処理: 複数のDevinセッションを同時起動
- 管理された子セッション: 親Devinが子Devinを制御
本番品質Devin API統合に必要な5レイヤー
レイヤー1: エラー階層の設計
Devin APIとの統合で最初に設計すべきは、エラー階層である。renueの実装では3つの例外クラスを定義している。
class DevinClientError(Exception):
# Devin API関連のエラー(基底クラス)
pass
class DevinConfigurationError(DevinClientError):
# Devin API設定エラー(APIキー未設定など)
pass
class DevinAPIError(DevinClientError):
# Devin API呼び出しエラー
def __init__(self, message, status_code=None):
super().__init__(message)
self.status_code = status_code
3階層にする理由
- DevinClientError(基底): 一括catchで全Devinエラーを捕捉できる
- DevinConfigurationError: 起動時チェックで早期検出
- DevinAPIError(status_code付き): HTTPステータスコードで適切なリトライ判断
この階層化により、呼び出し側は「設定ミスはfail-fast、API一時障害はリトライ、それ以外は管理者通知」という分岐を自然に実装できる。
レイヤー2: セッション作成APIの実装
Devinの中核機能は「セッション作成」である。1つのセッションが1つのタスクに対応し、プロンプトに応じてDevinが自律的にコーディングする。
create_session のパラメータ設計
async def create_session(
self,
prompt: str,
snapshot_id: Optional[str] = None,
playbook_id: Optional[str] = None,
unlisted: bool = False,
idempotent: bool = False,
max_acu_limit: Optional[int] = None,
) -> Dict[str, Any]:
url = f"{self.base_url}/sessions"
payload = {"prompt": prompt}
if snapshot_id:
payload["snapshot_id"] = snapshot_id
if playbook_id:
payload["playbook_id"] = playbook_id
if unlisted:
payload["unlisted"] = unlisted
if idempotent:
payload["idempotent"] = idempotent
if max_acu_limit is not None:
payload["max_acu_limit"] = max_acu_limit
# ...
各パラメータの使い分け
| パラメータ | 用途 | 使うべきシーン |
|---|---|---|
| prompt | タスクの詳細指示 | 必須。具体的かつ明確に書く |
| snapshot_id | マシンスナップショット | 特定の環境設定を再現したい場合 |
| playbook_id | プレイブック参照 | 定型タスクで品質を安定化 |
| unlisted | 非公開セッション | 機密性の高いタスク |
| idempotent | 冪等性確保 | 同じプロンプトで二重起動を防ぎたい |
| max_acu_limit | ACU上限 | コスト制御(必須設定推奨) |
レイヤー3: ACU(Agent Compute Unit)の制御
Devinの料金体系は「ACU(Agent Compute Unit)」というユニット制である。本番運用ではACU消費を厳密に管理する必要がある。
ACUの基本
- 1 ACU ≒ 約15分の作業時間
- Devinが稼働しない時間はACU消費されない
- 複雑なタスクほどACU消費が大きくなる
- 月額契約にACU数が含まれ、追加購入も可能
max_acu_limit の設定指針
`max_acu_limit`を指定することで、セッションあたりのACU消費上限を設定できる。これを超えるとセッションは自動停止する。renueの実装ではタスク種別に応じた目安を設けている。
- 小タスク: max_acu_limit = 2 (〜30分)
- 中タスク: max_acu_limit = 4 (〜1時間)
- 大タスク: max_acu_limit = 8 (〜2時間)
- 調査・プロトタイピング: max_acu_limit = 1 (〜15分)
制限なしで実行するとACUが予期せず大量消費されるリスクがある。必ず上限を設定することが推奨される。
ACU管理の運用パターン
- 事前予算化: プロジェクト別にACU予算を割り当て
- 実績集計: 週次でACU消費をダッシュボード表示
- コスト配賦: 部門別/プロジェクト別にチャージバック
- 異常検知: 単一タスクで想定以上のACU消費があればアラート
レイヤー4: プレイブックの活用
プレイブックはDevinの「定型タスクのテンプレート」である。同じ種類のタスクを繰り返し実行する場合、プレイブックを使うことで品質が安定する。
プレイブックが有効なユースケース
- PRレビュー: コード品質チェック、命名規則、コメントの妥当性
- バグ修正: 再現 → 原因調査 → 修正 → テストの標準フロー
- 新機能実装: 要件確認 → 設計 → 実装 → テストの標準フロー
- ドキュメント作成: コードから仕様書を自動生成
- リファクタリング: 特定パターンのコードを一括修正
プレイブック運用のメリット
- Devinの出力品質が安定する(毎回「どう進めるべきか」考える必要がない)
- ACU消費が予測可能になる
- チーム全体でベストプラクティスを共有できる
- 新メンバーのオンボーディングに活用できる
レイヤー5: httpx非同期クライアントの活用
Devin APIはRESTだが、セッション作成後の進捗確認などで複数の並列リクエストが発生することが多い。そのため非同期HTTPクライアント`httpx.AsyncClient`を使うのが推奨される。
renueの実装パターン
async with httpx.AsyncClient(timeout=self.timeout) as client:
try:
response = await client.post(url, headers=self._get_headers(), json=payload)
response.raise_for_status()
return response.json()
except httpx.TimeoutException as e:
logger.error(f"Devin API timeout: {str(e)}")
raise DevinAPIError(f"Devin API request timed out after {self.timeout}s") from e
except httpx.HTTPStatusError as e:
logger.error(f"Devin API error: {e.response.status_code} - {e.response.text}")
raise DevinAPIError(f"Devin API returned error: {e.response.status_code}", status_code=e.response.status_code) from e
except httpx.RequestError as e:
logger.error(f"Devin API request error: {str(e)}")
raise DevinAPIError(f"Failed to connect to Devin API: {str(e)}") from e
3種類の例外を区別する意義
- TimeoutException: ネットワーク遅延またはサーバー過負荷。リトライ有効
- HTTPStatusError: 4xx(クライアントエラー)/5xx(サーバーエラー)。status_codeで分岐
- RequestError: ネットワーク接続失敗。リトライまたは代替手段
それぞれを個別にcatchすることで、呼び出し側は適切な対応ができる。例えばTimeoutは自動リトライ、5xxは短時間で再試行、4xxはユーザー通知、といった使い分けが可能になる。
APIキー管理のベストプラクティス
Devin APIキーは高度な権限(コード改変・PR作成)を持つため、管理が特に重要である。
設定時のチェック
def __init__(self, api_key=None, timeout=DEFAULT_TIMEOUT):
self.api_key = api_key or env_setting.DEVIN_API_KEY
self.base_url = "https://api.devin.ai/v1"
self.timeout = timeout
if not self.api_key:
raise DevinConfigurationError("DEVIN_API_KEY is not configured. Please set the DEVIN_API_KEY environment variable.")
APIキー管理の原則
- 環境変数で管理: コードに直書き禁止
- 起動時チェック: `DevinConfigurationError`で早期検出
- Secret Manager連携: AWS Secrets Manager/Azure Key Vault等で管理
- ログに出さない: エラーメッセージにAPIキーを含めない
- ローテーション: 定期的にAPIキーを更新
- 権限分離: 開発/ステージング/本番で別々のAPIキー
メルカリ流のSecret管理(2026年1月〜)
2026年1月、Devinは**Secret管理機能のv3 API**を追加した。これにより、APIキー等の機密情報をDevinに安全に渡せるようになった。大規模運用では以下のパターンが推奨される。
- Secretの登録: Devinに事前にSecretを登録しておく
- セッションへの注入: セッション作成時にSecretをスコープ指定して注入
- 監査ログ: どのセッションがどのSecretにアクセスしたか記録
- 自動ローテーション: CI/CDパイプラインでSecretを定期更新
セッションの進捗監視
Devinセッションは非同期で進行する。開始後の進捗を監視するには`get_session`エンドポイントを定期的に呼ぶ。
進捗ステータス
- pending: キューで待機中
- running: 実行中(Devinがコーディング中)
- blocked: 人間の確認を待っている(エスカレーション)
- completed: タスク完了
- failed: エラーで停止
- expired: ACU上限に達して停止
ポーリング戦略
本番運用では以下のポーリング間隔が推奨される。
- 開始直後5分: 30秒間隔(初期エラー早期検出)
- 5〜30分: 1分間隔(通常実行中)
- 30分〜: 5分間隔(長時間タスク)
- blocked状態: 通知を送信して人間の介入を待つ
Slackボット統合のパターン
Devin API統合の典型的なユースケースが「Slackからの起動」である。以下のフローが標準的である。
- ユーザーがSlackで`/devin`コマンドを実行
- Slackボットがプロンプトを取得
- `DevinClient.create_session`でセッション作成
- セッションURLをSlackに返信
- バックグラウンドタスクでステータスをポーリング
- `completed`/`failed`/`blocked`になったらSlackに通知
- ユーザーはSlackから結果を確認
この仕組みにより、非エンジニアでも日常業務からDevinを起動できる環境が整う。
Claude × Devin のハイブリッド運用
2026年現在、Claude CodeとDevinを使い分けるハイブリッド運用が注目されている。両者の特性を活かした役割分担が効果的である。
役割分担の指針
| タスク | 推奨ツール | 理由 |
|---|---|---|
| 探索的コーディング | Claude Code | 対話型で素早く試行錯誤 |
| 定型タスクの自動化 | Devin | プレイブックで品質安定 |
| 長時間のリファクタリング | Devin | 非同期で進行、人間は並行作業 |
| 緊急バグ修正 | Claude Code | 対話型で即応答 |
| 並列タスク処理 | Devin | 複数セッション同時起動 |
| 設計の壁打ち | Claude Code | 対話の質が高い |
renueの実装特徴
renueは「Self-DX First」の方針のもと、Devin API統合を自社プロダクトとして実装している。社内12業務を553のAIツールで自動化済み(2026年1月時点)であり、DevinもClaude Codeと並んで社内開発で活用されている(全て公開情報)。
技術スタック
- 言語: Python 3.11
- HTTPクライアント: httpx(非同期対応)
- エラー階層: DevinClientError → Configuration/API の2分岐
- 設定管理: 環境変数(`DEVIN_API_KEY`)
- デフォルトタイムアウト: 30秒
導入時のよくある失敗パターン
- max_acu_limit を設定しない: ACU消費が予期せず爆発する
- APIキーを環境変数以外で管理: セキュリティリスク
- 同期HTTPクライアントを使う: 並列処理で詰まる
- 例外をキャッチしすぎる: 適切な対応ができない(`except Exception`の乱用)
- プレイブックを使わない: タスクごとに品質がブレる
- ポーリング間隔が一定: 早すぎるとレート制限、遅すぎるとUX悪化
- blocked状態を検知しない: Devinが人間の介入を待ったまま放置される
業界別の活用パターン
| 業界 | 典型的なタスク |
|---|---|
| SaaS開発 | バグ修正、機能追加、リファクタリング |
| 受託開発 | 要件定義書から実装への変換、レビュー |
| DevOps | インフラコード生成、CI/CD設定 |
| Web制作 | LP実装、デザインからコード化 |
| データ分析 | SQL/Pythonスクリプト生成、レポート作成 |
よくある質問
Devinの料金はどれくらい?
コアプランで月額500ドル程度から。ACU追加購入は別料金。1 ACU ≒ 約15分の作業時間なので、月間200ACU使うなら実質約50時間のAIエンジニア工数として考えられる。月額契約にACU数が含まれるため、公式サイトで最新の料金プランを確認すること。
Claude Codeと比べた強みは?
Devinは「バックグラウンドで長時間走らせる」ことに特化している。Claude Codeは対話型で即応答が強み。長時間のリファクタリングや大量PR作成にはDevin、日常的なコーディングにはClaude Codeが適している。
プロンプトはどう書くべき?
具体的かつ明確に。「このコードをリファクタリングして」ではなく「以下のファイルの関数Aを単一責任の原則に従って分割し、テストを追加してPRを作成してください」のように、成果物まで明示する。プレイブックでテンプレート化すると品質が安定する。
blocked状態になったらどうする?
Devinが「人間の判断が必要」と判定した場合、blocked状態になる。Slack通知等で即座に人間に知らせる仕組みが必須。通知を見た人間がDevinのUIで指示を出すと再開する。通知がないと長時間放置されACUが無駄になる。
導入後に最も改善するKPIは?
「定型タスクの処理時間」と「エンジニアの付加価値業務への集中度」が最も顕著に改善する。renueのようなSelf-DX企業では、定型タスクをAIに任せ、人間は戦略的な開発・設計に集中する運用に移行している。