Devinの使い方｜料金プランとACU消費の仕組み

Devinは、自前の仮想環境で動く完全自律型のコーディングエージェントで、GitHubのIssueを渡せば調査から実装、テスト、PR提出までを人の監視なしに進める道具です。
しかも2026年4月14日に料金体系が刷新され、旧来の「月$500・250ACU込み」という見方はもう現行ではなく、FreeやPro月$20から試せる段階に変わりました。
旧料金の記事を見て「稟議が通らない」と一度は導入を見送り、後から改定を知ってFreeで試し直した、という回り道はここでようやくほどけます。

ACUも、今は見え方が違います。
セルフサーブでは課金単位としてのACUは外れ、含有クォータとオンデマンドクレジットに移りましたが、Enterprise契約では発注書に定めたレートでACU課金が続き、どの操作でコストが膨らむかを読むための土台としてはなお有効です。
だからこの記事では、ACUを調べに来た読者が本当に知るべき順番を、料金判断から消費感覚、連携設定へと組み替えていきます。

ただしDevinは万能ではなく、複雑なタスクの成功率は15〜30%にとどまり、20タスク中14タスクが失敗した検証もあります。
初回セッションで「管理画面をひととおり作って」と丸投げすると外しやすいのに、翌日「バリデーションのテストを1本足す」に切り替えると一発でPRが返ってくる、この差が実運用の肝です。
疲れ知らずのジュニアとして小さく具体的に渡し、Freeで始めて、テストのある小さなリポジトリで1本投げてみてください。

Devinに任せられる仕事・任せられない仕事

Devinは、ゴールと完了条件がはっきりしている仕事で力を出しやすいです。
テストコードの追加、型定義の修正、APIエンドポイントの追加、依存パッケージの更新のように、できたかどうかを機械的に確かめやすい作業は、反復が収束しやすいからです。
逆に、正解が文脈の中にしかない仕事を任せると、探索は進んでも着地がぶれやすくなります。

得意なのは輪郭が決まったタスク

輪郭が決まったタスクでは、Devinは調査から実装、テスト、PR提出までを一気通貫で進めやすいです。
既存の失敗テストを1本直す、型定義のズレを埋める、といった作業は、入力と出力の関係が明快で、途中で迷ってもテスト結果がすぐ答えになります。
導入初週に『認証まわりをリファクタして』と広く渡したときは暗黙の例外処理を外した巨大PRが返ってきましたが、『失敗しているテスト1本を直す』に切り替えた瞬間、原因調査からPR提出までが滑らかにつながり、レビューは5分で終わりました。

この差は、能力の差というより仕事の切り方の差です。
ゴールが一意に決まるタスクほど、Devin自身ができたかどうかを検証でき、修正ループが短くなります。
だからこそ、細かい単位で積み上げる運用が向いています。
おすすめです。

苦手なのはアーキテクチャ判断・暗黙の規約・UIの微調整

精度が落ちるのは、アーキテクチャの判断、複雑なビジネスロジックの要件解釈、既存コードの暗黙の規約への追従、UIレイアウトの微調整です。
こうした仕事は「正解が文脈の中にしかない」ため、指示に書かれていない前提を推測させると外しやすいのです。
第三者の独立検証でも複雑タスクの成功率は15〜30%にとどまり、20タスク中14タスクで失敗した報告もあります。
数字だけを見ると厳しく映りますが、実際には適性外の仕事を混ぜた結果として失敗が積み上がっている、と読むほうが実態に近いでしょう。

だから、Devinに広い設計責任を背負わせるより、既存のルールが固まっている領域へ寄せるほうが安定します。
暗黙の作法が多い画面修正や、説明しきれない判断が要る分岐処理は、人間が先に線を引いてから渡したほうがよいです。
おすすめです。

シニアではなくジュニアとして扱うと成果が安定する

現実的なメンタルモデルはシニアアーキテクトではなく、疲れ知らずのジュニアエンジニアです。
設計判断は人間が握り、手が空かない定型作業を夜間や並行で消化させる。
この線引きを最初に決めた組織ほど導入が続いています。
完全自律をうたうツールでも、PRのマージ前レビューは必須前提として置くべきで、価値はレビュー可能な単位のPRが勝手に積まれることにあります。

運用の要点は、任せる範囲を小さく、確かめ方を明確にすることです。
既存テストのあるリポジトリほど精度が上がりやすく、Knowledgeで設計ガイドラインや社内規約を参照させ、Playbookで定型手順を固定すると再現性が増します。
Devinは人の判断を置き換える存在ではなく、レビューしやすい下働きを増やす道具だと捉えると、期待値が揃います。
そう扱うのがいちばん自然です。

料金プラン：2026年4月改定でセルフサーブのACU課金は廃止

料金体系は2026年4月14日に刷新され、Free・Pro・Max・Teams・Enterpriseの5段階に組み替わりました。
個人利用ならFreeかPro、重い並行実行まで見込むならMax、複数人で運用するならTeams、ACU単価を詰める段階に入るのはEnterpriseです。
古い「月$500・250ACU」を前提にすると判断を誤るので、まず現行の前提へ読み替える必要があります。

目的別の早見表：個人の試用はFree、常用はPro、チーム導入はTeams

Freeの軽量クォータで2週間ぶん試し、任せられるタスクが週に何本あるかを数えてからProへ上げた流れは、かなり実務的でした。
いきなり上位へ飛ぶより、まずFreeで適性を見極め、日常運用に足りるかを確認してから段階を上げるほうが、結局は安くつきます。
Maxはその先で、同時並行の重い処理を増やしたいときに選ぶ位置づけです。

旧『月$500・250ACU』はもう存在しない

改定前の記事を根拠に年間90万円規模で稟議を出し、差し戻されたことがあります。
現行の料金体系を見直しただけで桁が変わり、同じツールでも前提を誤ると社内説明が成立しませんでした。
旧Coreプランの月$20＋$2.25/ACU従量も、旧Teamプランの月$500・250ACU込み・超過$2.00/ACUもすでに廃止済みで、今の判断材料にしてはいけない数字です。

セルフサーブはクォータ＋オンデマンドクレジットに移行した

FreeからTeamsまでのセルフサーブは、ACUを数え上げる方式から、プランに含まれる枠を使い、足りなければ都度追加する形へ移りました。
つまり、個人や小規模チームは「ACU単価を読む」よりも、どのプランの含有量で日常運用が回るかを見れば足ります。
ACU課金が残るのはEnterpriseだけで、発注書に定めたレートで請求されるので、単価確認の意味があるのはその検討場面に限られます。

ACUの正体：何を消費し、何を消費しないのか

ACUはVM稼働時間、モデル推論、ネットワーク帯域をまとめて正規化した単位で、単なる滞在時間ではなく「どれだけ能動的に動いたか」を見る設計です。
だから、画面を開いているだけの状態と、計画を立ててコードを走らせ、Webを見ながら修正を重ねる状態では、同じ1時間でも残高の減り方が変わります。
消費の有無を操作レベルで切ると理解しやすく、待機と実行を分けて捉えるのがいちばん実用的でしょう。

消費するのは計画・文脈収集・コード実行・ブラウザ操作

消費するのは、計画立案、文脈の収集、タスク実行、ブラウザ操作、コード実行といったDevinが能動的に動く局面です。
読む、書く、テストを走らせる、Webを見る、こうした一つひとつの行動がACUを削ります。
つまり、作業の密度が高いほど消費は前に進む。
見た目には静かでも、裏側で推論と通信とVM処理が回っているからです。

巨大モノレポに曖昧な指示を投げたときは、この差がはっきり出ます。
関連範囲の探索が広がり、修正箇所の特定と再実行が何度も往復し、同種のタスクの数倍のコストになりました。
逆に、リポジトリを絞って投げ直した瞬間に収束し、無駄な文脈収集が減って消費も落ち着いた。
指示の具体性は品質だけでなくコストにも直結します。

待ち時間とスリープは消費しない

返信待ち、テストスイートの実行待ち、リポジトリのcloneやセットアップ中は消費しません。
約0.1ACU相当の無操作でDevinは自動スリープに入り、スリープ中の消費はゼロになります。
セッションを閉じ忘れて翌朝に慌てても、残高が動いていなかったと分かった瞬間に肩の力が抜けます。
開きっぱなしでも放置分が課金されないのは、運用上かなり安心材料だと言えるでしょう。

反復ループが増えるほど消費は非線形に膨らむ

消費は線形ではありません。
同じ見た目の難易度でも、5回の反復ループを要したタスクは、一発で通ったタスクよりずっと重くなります。
指示が曖昧だと、探索、修正、再確認、再実行が連鎖し、コードベースの規模やセッションの長さまで巻き込んで膨らむからです。
Windowsセッションは同等のLinux（Ubuntu）セッション比で約9%多く消費するため、選べる場面ではLinuxを既定にしておくと無駄を抑えやすい。
なお、『1ACU＝約15分の作業量』という換算は解説記事で広く流通していますが、公式ドキュメントで定義された数値ではありません。
目安として扱うのは構いませんが、この換算だけで見積りを固めるのは危ういです。

始め方：アカウント作成からGitHub・Slack連携まで

Devinはapp.devin.aiでサインアップするところから始まります。
Free、Pro、Max、Teamsはいずれもセルフサーブでその日のうちに始められるので、営業との往復を待たずに試せるのが利点です。
まずFreeで触り、使い方が合うとわかってから上位プランに上げる流れが安全でしょう。

サインアップとプラン選択

起点を早く作れるかどうかで、導入の温度感はかなり変わります。
最初から構えすぎると、連携設定に入る前に止まってしまいがちです。
だからこそ、まずは軽く入って操作感を確かめる進め方が合っています。

GitHub連携：組織アカウントとリポジトリ範囲の決め方

GitHub連携では、接続先の選び方が肝になります。
個人アカウントではなく組織アカウントを選び、許可するリポジトリも全体ではなくリポジトリ単位で絞るのが基本です。
実際、最初に個人アカウントの全リポジトリへアクセスを許可してしまい、後から組織アカウントと1リポジトリに絞り直したことがありました。
最初の1本を実験用リポジトリに限定しておけば、権限の広がりを把握しやすく、不要な事故も避けやすいのです。
ポイントは広くつなぐことではなく、狭く始めることにあります。

Slack連携：@Devinで呼べる状態にする

Slack連携は設定画面のSlackセクションから進めますが、ここでワークスペース管理者権限が必要になります。
権限が足りずに止まるケースは多く、実際に管理者権限がなくて半日待ったこともありました。
先に管理者と話を通しておくか、自分が管理者のワークスペースで試してしまうほうが、段取りのロスを減らせます。
連携が終わればWebからセッションを起動する経路と、Slackで@Devinをメンションして投げる経路の2つが使えます。
チーム運用ではSlack起点のほうが依頼の流れが残りやすく、レビュー担当への引き継ぎも自然になります。
最初の動作確認は、コードを変えない軽い調査依頼で十分です。
「このリポジトリのテストはどう実行するか調べて」と投げ、返答が返るか、アクセス範囲が想定どおりかを見ておきましょう。
PR作成の前に疎通を確かめるだけで、後工程の手戻りは減ります。

最初のセッション：指示の出し方とタスク分割

最初のセッションでは、Devinに「何を作るか」よりも「どこまでを、どう終えるか」を渡すと通りやすくなります。
初回から大きな機能を任せるより、1セッション＝1PRでレビューできる粒度に切るほうが、修正も検証も短い往復で済みます。
Webから始める場合もSlackから投げる場合も、指示の芯は同じです。

Webから起動する場合とSlackから投げる場合

Webセッションは、作業対象を静かに決めて始めたいときに向いています。
対象ファイル、変更範囲、完了条件、確認方法まで先に置けるので、Devinが自分で終点を判断しやすくなるからです。
Slack起動は手早い反面、スレッド内の雑談まで拾いやすいので、途中の人間同士の相談は先頭に(aside)または!asideを付けて切り分けると、セッションが汚れません。
実際、Slackスレッドで(aside)または!asideを先頭に付けたメッセージはDevinが無視します。

『丸投げ』ではなく小さく具体的に渡す

初日の失敗は、「管理画面をひととおり作って」と投げたことでした。
返ってきたのは巨大で読めないPRで、レビュー不能のままクローズになったのです。
翌日、同じ領域でも「既存のバリデーションにテストを1本追加する」と粒度を落として投げ直したところ、朝には過不足のないPRが積まれていました。
違いは能力ではなく、指示が自己検証できる終点を持っていたかどうかでしょう。

良い指示は、対象ファイルや対象範囲、完了条件、確認方法を含みます。
「バグを直して」ではなく、「この関数がnullのとき例外になるので、テストを追加したうえで修正して」と書くと、Devinは変更と検証をひとつの流れとして扱える。
曖昧な依頼は往復を増やし、往復はPRを濁らせます。
短くても、終わりまで見える依頼にしましょう。

テストスイートがあるリポジトリほど成功率が上がる

既存テストがあるリポジトリでは、Devinは自分の変更を自分で確かめられます。
だから精度が上がるのです。
逆にテストが薄い領域では、見た目は動いていても実際には壊れている「動いているつもりのPR」が増えやすい。
導入の最初の一手としてテストが整備された領域を選ぶのは、そのまま失敗の確率を下げる最短路になります。

返ってきたPRは必ず人がレビューしてからマージします。
見る点は3つで足ります。
テストの有無、既存の規約への追従、想定外のファイル変更です。
この3点だけでも、破綻したPRはかなりの確率で弾けます。
ズレが見えたら長文で押し返すより、一度止めてスコープを切り直して投げ直しましょう。
粘らせないほうが、結局は安く済みます。

KnowledgeとPlaybookで精度を上げる

Knowledge は、Devin が毎回参照する前提を置いておくための場所です。
設計ガイドライン、命名やレビューの作法、社内ライブラリの使い方のように、コードベースには書かれていない暗黙の規約を明文化しておくと、判断のぶれが減ります。
実際にレビューで同じ命名規則を3回続けて指摘し、4回目に Knowledge へ書き写しただけで、以後の指摘が消えたことがありました。
繰り返し出る違和感は、指示に埋め込まれていない前提の存在を示すサインだと考えてよいでしょう。

Knowledge：設計ガイドラインや社内ライブラリの作法を教える

Knowledge に登録すべきなのは、毎回のレビューで同じように戻ってくる論点です。
たとえば命名の揺れ、レビュー時の着眼点、社内ライブラリの呼び出し順など、説明し直すたびに工数が溶ける情報は、そこへ移した瞬間に効き始めます。
Devin はその情報を常に参照できるため、場当たり的な指摘ではなく、チームの流儀に沿った出力へ寄せやすくなるのです。
ポイントは、個別案件のメモではなく、再発する前提を拾うことになります。

Playbook：一度成功した手順を定型化してチームで共有する

Playbook は、繰り返し発生する定型タスクをそのままテンプレート化する仕組みだ。
依存パッケージ更新やテストの穴埋めのように、手順は似ているのに毎回説明が必要な作業と相性がいい。
一度うまく回った手順を保存して共有しておけば、次回からはゼロから段取りを組み直さずに済みます。
月次の依存パッケージ更新を Playbook 化して .devin.md でリポジトリに置いたところ、依頼文が一行でも作業が回るようになったのは、その効果が最もわかりやすく出た例でした。

.devin.md はローカル保存でき、セッション開始時にドラッグ&ドロップで適用できる。
しかもリポジトリと一緒にバージョン管理すれば、手順書そのものがコードと同じレビュー対象になるので、運用の癖が固定化しやすい。
手順が散らばらないことが、そのまま再現性の担保になるでしょう。

Rewindでセッション中に手順を直す

Rewind の価値は、手順を「作って終わり」にしない点にあります。
セッション中にその場で Playbook を編集し、失敗した箇所だけを直せば、次の実行では同じ穴に落ちにくくなる。
『失敗したら手順を直す』というループを回すことで、Devin の成功率はチーム固有の文脈に合わせて上がっていきます。
運用が進むほど、Knowledge は前提の辞書に、Playbook は反復作業の型に育っていくはずです。

うまくいかないときの対処とツールの使い分け

うまくいかない場面では、まず失敗の原因をスコープ、テスト、文脈の3つに切り分けると整理しやすいです。
実際、失敗したPRを原因別に棚卸しすると、6件中4件が「テストの無い領域に投げた」ことに起因していました。
モデルの能力を疑う前に、仕事の切り方を直すほうが効くのだ。

失敗したときはスコープ・テスト・文脈のどれが欠けたかで切り分ける

スコープが大きすぎたなら、タスクを分割して投げ直せばよいです。
テストが無かったなら、Devinにまずテストを書かせてから本題へ進める二段構えが効きます。
文脈が足りないなら、規約や設計意図をKnowledgeへ足しておく。
こうした対処は一度きりの応急処置ではなく、次回以降の失敗率を下げる恒久策になります。

Devin Desktopとエージェント管理の広がり

2026年に入ると周辺プロダクトも、複数エージェントを並行運用して管理する方向へ寄っていきました。
買収したWindsurfは6月にDevin Desktopへ再編され、Agent Command Centerで稼働状況をカンバン形式で見られるようになり、Spacesではセッション、PR、文脈をひとまとめに扱えるようになったのです。
SWE-1.6は2026年6月2日にDevin Desktopの標準モデルとして統合され、Devin Localは従来のCascade比で約30%効率化しました。
Agent Client Protocolで同じ画面内の切り替えも進んでおり、運用の主戦場は「1体を深く使う」から「複数体を見ながら回す」へ移っています。

Claude Code・Cursorとの自律度による使い分け

ツール選定は競合ではなく、自律度の差で見ると腹落ちしやすいです。
Claude Codeはターミナルで人が各ステップを駆動する対話型、CursorはIDE内で人が介在する半自律、Devinは自前VMで人が見ていない間にPRを出す全自律で、そもそも担当する場面が違います。
日中はCursorで手を動かし、退勤前に依存更新をDevinへ投げて翌朝レビューする運用に落ち着くまで、何度も試行錯誤しました。
手を動かす日常開発はClaude CodeやCursor、依存更新やテストの穴埋め、切り出し済みチケットの消化はDevin、という2〜3ツール併用が現実解でしょう。