株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
Devinは2026年現在、自律型AIエンジニアとして注目を集めるAI開発ツールである。プロンプトを渡すだけでコーディング・PR作成・テスト実行までを自動で行う。本記事では、Devin APIを自社システムに統合する際の実装パターンを、自社での実装経験をもとに解説する。セッション管理、ACU(Agent Compute Unit)制御、プレイブック活用、3階層のエラーハンドリングまで、本番運用に向けて確認すべき設計上の観点を解説する。対象の権限・負荷・障害復旧条件に応じた検証が必要である。
Devin API統合の基礎
API仕様は2026年9月17日に確認した。本記事のパラメータ表と状態名は既存統合向けのLegacy API v1を対象とする。現行APIは/v3/organizations・/v3/enterpriseを使い、認証や権限モデルも異なる。新規実装では現行APIと移行ガイドを確認し、v1のパラメータをそのまま当てはめない。（出典：Devin：v1/v2からの移行）
Devinはブラウザ経由だけでなく、REST APIで外部システムから制御できる。これにより以下のような運用が可能になる。
- Slackからの起動: ボットコマンドでDevinセッションを開始
- CI/CDとの連携: PRコメントでDevinを呼び出し
- チケット駆動開発: JiraチケットからDevinに自動割当
- 大量タスクの並列処理: 複数のDevinセッションを同時起動
- 管理された子セッション: 親Devinが子Devinを制御
Devin API統合の本番運用で確認したい5レイヤー
レイヤー1: エラー階層の設計
Devin APIとの統合で最初に設計すべきは、エラー階層である。一般に3階層の例外設計が有効である。
3階層にする理由
- 基底例外: 一括catchで全Devinエラーを捕捉できる
- 設定エラー例外: 起動時チェックで早期検出
- APIエラー例外(ステータスコード付き): HTTPステータスコードで適切なリトライ判断
この階層化により、呼び出し側は「設定ミスはfail-fast、API一時障害はリトライ、それ以外は管理者通知」という分岐を自然に実装できる。
レイヤー2: セッション作成APIの実装
Devinの中核機能は「セッション作成」である。1つのセッションが1つのタスクに対応し、プロンプトに応じてDevinが自律的にコーディングする。
セッション作成API（v1）のパラメータ設計
各パラメータの使い分け
| パラメータ | 用途 | 使うべきシーン |
|---|---|---|
| prompt | タスクの詳細指示 | 必須。具体的かつ明確に書く |
| snapshot_id | マシンスナップショット | 特定の環境設定を再現したい場合 |
| playbook_id | プレイブック参照 | 定型タスクで品質を安定化 |
| unlisted | v1の真偽値オプション（既定値false） | 公式の型定義だけでは閲覧制限の保証を確認できない。機密情報の入力可否は組織・共有・アクセス権限で別途判断する |
| idempotent | 冪等性に関するv1オプション（既定値false） | 同一判定の条件・有効期間は公式の型定義では説明されていない。同じプロンプトだけで二重起動を防げると仮定せず、要求とセッションIDを対応づけて再送を判断する |
| max_acu_limit | ACU上限 | コスト制御(必須設定推奨) |
パラメータ名・型は（出典：Devin：Create a new session（v1））を参照。snapshot_id・playbook_id・max_acu_limitも同じv1仕様を対象とする。
レイヤー3: ACU(Agent Compute Unit)の制御
Devin Enterpriseでは「ACU(Agent Compute Unit)」を契約に基づく課金単位として使う。一方、セルフサービスのFree・Pro・Max・Teamsはプランの利用枠と追加クレジットの体系である。以下のACU制御は利用しているAPI・契約条件と照合し、本番運用では該当する消費量を管理する。（出典：Devin：Billing）
ACUの基本
- ACUは計算・処理の消費単位で、実際の経過時間に固定換算しない（出典：Devin：Usage）
- スリープ中は消費しない。返答・テスト実行等を待つ間は、VM維持分の少量消費があり得る（出典：Devin：待機とスリープ）
- 複雑なタスクほどACU消費が大きくなる
- EnterpriseのACU単価・契約量は注文書による。セルフサービスの利用枠・追加クレジットとは分けて確認する（出典：Devin：Enterprise課金）
max_acu_limit の設定指針
`max_acu_limit`を指定することで、セッションあたりのACU消費上限を設定できる。v1では正の整数の上限パラメータとして定義されているが、固定時間での停止を指定するものではない。上限到達時の状態・消費量・再開条件も監視して確認する。（出典：Devin：max_acu_limit）タスクごとの上限は、許容予算と試行時の消費実績を基に設定し、完了品質と併せて見直す。
- 小タスク: 作業範囲を絞って消費量と完了条件を確認する
- 中・大タスク: 工程を分割し、各工程の予算と承認条件を決める
- 調査・プロトタイピング: 調査範囲と打ち切り条件を先に決める
制限なしで実行するとACUが予期せず大量消費されるリスクがある。必ず上限を設定することが推奨される。
ACU管理の運用パターン
- 事前予算化: プロジェクト別にACU予算を割り当て
- 実績集計: 週次でACU消費をダッシュボード表示
- コスト配賦: 部門別/プロジェクト別にチャージバック
- 異常検知: 単一タスクで想定以上のACU消費があればアラート
レイヤー4: プレイブックの活用
プレイブックはDevinの「定型タスクのテンプレート」である。同じ種類のタスクを繰り返し実行する場合、プレイブックを使うことで品質が安定する。
プレイブックが有効なユースケース
- PRレビュー: コード品質チェック、命名規則、コメントの妥当性
- バグ修正: 再現 → 原因調査 → 修正 → テストの標準フロー
- 新機能実装: 要件確認 → 設計 → 実装 → テストの標準フロー
- ドキュメント作成: コードから仕様書を自動生成
- リファクタリング: 特定パターンのコードを一括修正
プレイブック運用のメリット
- Devinの出力品質が安定する(毎回「どう進めるべきか」考える必要がない)
- 同じ範囲のタスクの消費実績を比較し、ACU予算の見積もりを改善できる
- チーム全体でベストプラクティスを共有できる
- 新メンバーのオンボーディングに活用できる
レイヤー5: httpx非同期クライアントの活用
Devin APIはRESTだが、セッション作成後の進捗確認などで複数の並列リクエストが発生することが多い。そのため非同期HTTPクライアント`httpx.AsyncClient`を使うのが推奨される。
renueの実装パターン
3種類の例外を区別する意義
- TimeoutException: 接続・読み取り・書き込み・接続プールの待ち時間超過。作成要求が処理済みか不明な場合は無条件に再送しない
- HTTPStatusError: 4xx(クライアントエラー)/5xx(サーバーエラー)。status_codeで分岐
- RequestError: ネットワーク接続失敗。リトライまたは代替手段
それぞれを個別にcatchし、HTTPメソッドと処理の成否を合わせて対応を決める。セッション作成POSTのタイムアウトや5xxでは、作成済みか確認できないまま再送すると二重起動し得る。重複防止条件または未実行を確認できた場合に限り再試行する。取得GETの一時障害は上限付きの待機・再試行を設計する。4xxも一括扱いせず、認証・入力エラーは修正を促し、429はRetry-Afterがあれば従って送信頻度を下げる。（出典：HTTPX：例外、HTTP仕様：冪等性と再試行、HTTP 429）
APIキー管理のベストプラクティス
Devin APIキーは高度な権限(コード改変・PR作成)を持つため、管理が特に重要である。
設定時のチェック
APIキー管理の原則
- 環境変数で管理: コードに直書き禁止
- 起動時チェック: `DevinConfigurationError`で早期検出
- Secret Manager連携: AWS Secrets Manager/Azure Key Vault等で管理
- ログに出さない: エラーメッセージにAPIキーを含めない
- ローテーション: 定期的にAPIキーを更新
- 権限分離: 開発/ステージング/本番で別々のAPIキー
DevinのSecret管理機能（対象API版と利用条件を確認）
DevinはSecretsの管理機能と、セッションへ渡すSecretを指定するAPIを提供している。2026年1月16日のAPI更新はSecretの型定義の更新であり、管理API全体の新規提供開始日を示すものではない。保存時の暗号化があっても、共有範囲や利用権限の確認は必要である。以下ではDevinの提供機能と、呼び出し側で設計する監査・更新処理を分けて扱う。（出典：Devin：Secrets、Devin：API Release Notes）
- Secretの登録: 必要なSecretを登録する。組織共有Secretは組織メンバーが利用できるため、全員に共有してよい範囲に絞る（出典：Devin：組織共有Secret）
- セッションへの注入: v1のsecret_idsで渡す登録済みSecretを指定する。未指定・nullは全Secret、空配列はなしとなる。session_secretsはそのセッションだけに渡し、組織Secretとして保存しない（出典：Devin：secret_ids / session_secrets）
- 監査ログ: 呼び出し側で、どの要求・セッションにどのSecret IDを渡したかを記録する。Secretの値はログに残さない。実際のアクセスイベントは、利用できる監査ログの仕様を別途確認する
- 自動ローテーション: 呼び出し側のCI/CD等で、資格情報の発行元での更新とDevin側の登録更新を連携させる。標準機能だけで自動更新されるとは扱わない
セッションの進捗監視
Devinセッションは非同期で進行する。本記事のv1ではGET /v1/sessions/{session_id}を定期的に呼び、status_enum・status・messagesを組み合わせて確認する。（出典：Devin：セッション詳細取得（v1））
進捗ステータス
- 待機（アプリ側で設ける状態）: 起動要求をキューで管理する場合。v1のstatus_enumにpendingはない
- working（v1）: 作業中。status・messagesで実行内容を確認する
- blocked（v1）: 進行が止まっている状態。status・messagesを確認し、人の指示が必要か判断する
- finished（v1）: 終了状態。成果物・テスト結果は別途検証する
- 失敗（アプリ側で設ける状態）: API呼び出しや業務上の検証失敗を管理する場合。v1のstatus_enumにfailedはない
- expired（v1）: 公式にある列挙値だが、ACU上限到達と同一視しない。status・messagesと利用状況で停止理由を確認する
v1にはこのほかsuspend_requested・suspend_requested_frontend・resume_requested・resume_requested_frontend・resumedがあり、status_enumはnullも取り得る。上の6項目はAPIの全状態一覧ではなく、アプリ側の待機・失敗管理と区別して扱う。（出典：Devin：status_enum）
ポーリング戦略
以下は本記事のポーリング間隔の設計例であり、Devin公式が一律に推奨する値ではない。同時セッション数・必要な検知速度・APIの利用制限に応じて調整し、429では待機時間を延ばす。
- 開始直後5分: 30秒間隔(初期エラー早期検出)
- 5〜30分: 1分間隔(通常実行中)
- 30分〜: 5分間隔(長時間タスク)
- blocked状態: 通知を送信して人間の介入を待つ
Slackボット統合のパターン
Devin API統合のユースケースの一つが「Slackからの起動」である。以下は独自のSlackボットを構築する場合の設計例である。公式Slack連携はアプリを接続したうえで@Devinをメンションして起動する。（出典：Devin：公式Slack連携）
- ユーザーが独自ボットに登録したコマンド（例：`/devin`）を実行
- Slackボットがプロンプトを取得
- セッション作成APIを呼び出してセッションを作成
- セッションURLをSlackに返信
- バックグラウンドタスクでステータスをポーリング
- v1の`finished`/`blocked`を検知、またはアプリ側で処理失敗と判断したらSlackに通知（中断・期限等もstatus/messagesで確認）
- ユーザーはSlackから結果を確認
この仕組みにより、非エンジニアでも日常業務からDevinを起動できる環境が整う。
Claude × Devin のハイブリッド運用
Claude CodeとDevinを使い分ける場合は、対象リポジトリ・権限管理・レビュー負荷を含めて比較する。以下は役割分担を試すための案であり、性能の優劣を示す比較試験ではない。Claude Codeにも非対話実行や独立したクラウドセッションがあり、長時間・並列処理をDevinだけの機能とは扱わない。（出典：Claude Code：プログラムからの実行、Claude Code：クラウド実行）
役割分担の指針
| タスク | 検討候補の例 | 理由 |
|---|---|---|
| 探索的コーディング | Claude Code | 対話型で素早く試行錯誤 |
| 定型タスクの自動化 | Devin | プレイブックで手順をそろえる |
| 長時間のリファクタリング | Devin | 非同期で進行、人間は並行作業 |
| 緊急バグ修正 | Claude Code | 対話しながら修正箇所を確認 |
| 並列タスク処理 | Devin | 複数セッション同時起動 |
| 設計の壁打ち | Claude Code | 対話を通じて設計案を検討 |
renueの実装特徴
renueは「Self-DX First」の方針のもと、Devin API統合を自社で実装している。社内の主要業務に自社開発のAIツールを導入し、DevinもClaude Codeと並んで社内開発で活用している。
技術スタック
- 言語: Python 3.11
- HTTPクライアント: httpx(非同期対応)
- エラー階層: 基底例外から設定系/API系の2分岐
- 設定管理: 環境変数で注入
- デフォルトタイムアウト: 30秒
導入時のよくある失敗パターン
- max_acu_limit を設定しない: ACU消費が予期せず爆発する
- APIキーをコードや平文ファイルへ直書き: 漏えいリスク。Secret Manager等で保管し、実行環境へ必要な範囲で渡す
- 同期HTTPクライアントを使う: 並列処理で詰まる
- 例外をキャッチしすぎる: 適切な対応ができない(`except Exception`の乱用)
- プレイブックを使わない: タスクごとに品質がブレる
- ポーリング間隔が一定: 早すぎるとレート制限、遅すぎるとUX悪化
- blocked状態を検知しない: Devinが人間の介入を待ったまま放置される
業界別の活用パターン
| 業界 | 典型的なタスク |
|---|---|
| SaaS開発 | バグ修正、機能追加、リファクタリング |
| 受託開発 | 要件定義書から実装への変換、レビュー |
| DevOps | インフラコード生成、CI/CD設定 |
| Web制作 | LP実装、デザインからコード化 |
| データ分析 | SQL/Pythonスクリプト生成、レポート作成 |