Devinレビュー2026｜料金と使い方、Cursor・Devin Desktopとの違い

Devin（デヴィン）は、クラウド上で動く自律型のソフトウェアエンジニアです。開発元は米 Cognition で、2026年11月7日に確認した公式トップの題は「Devin: the autonomous software engineer」、説明文は「Devin runs in the cloud or on your machine, tests in its own browser, and won’t stop until the PR is ready to merge」、つまり「クラウドか手元で動き、自分のブラウザで試し、PRがマージできる状態になるまで止まらない」という主張です。提供形態は Web のセッション画面と、デスクトップ版の Devin Desktop の2つ。料金は Free が0ドル、Pro が月20ドル、Max が月200ドル、Teams がチーム月80ドルに加えてフル開発シート1人あたり月40ドル、Enterprise は要相談です（2026年11月7日確認の公開情報）。ただし利用量の単価にあたる ACU の金額は公式の料金ページに無く、この記事では書きません。実際にセッションを走らせた検証は行っておらず、生成されるコードの品質は未検証です。

Devinとは何か。2026年のCognitionが描く「クラウド上の同僚」

Devin は、Cognition が2024年に公開した自律型のエンジニアとして知られてきました。2026年11月7日に公式トップを開くと、その説明は「同僚」という言葉で整理されています。見出しは「Meet Devin, your team’s autonomous software engineer」、続く一文は「Devin runs in the cloud or on your machine, tests in its own browser, and won’t stop until the PR is ready to merge」です。クラウドでも手元でも動き、自分のブラウザで試し、PRがマージできる状態まで止まらない、という3つの約束が並んでいます。

この約束のうち、最も重いのが3つ目です。「PRがマージできる状態になるまで止まらない」というのは、指示を1回受けたら、途中で人に聞き返さずに、テストを回し、失敗を直し、ブランチを上げるところまで進む、という意味に読めます。公式トップの実演画面にも、SAML の SSO を追加する指示に対して「Explored authentication across 3 repositories」「Implemented SSO and organization settings」と段階が並び、最後に「I tested setup, sign-in, and account linking in the browser. 5 tests passed」と記録されます。人の手が入るのは、PRを確認する段階からです。

この表で目を引くのは、実行環境と記録の2行です。OS をまたいだ仮想環境を必要に応じて立ち上げ、その中でビルドとテストを行い、操作の様子を録画する。これは、人が手元でやっていた確認の手順をそのまま機械に移す設計です。コードを書く部分だけを自動化しても、確認と修正の手間は人に残ります。Devin は書く・試す・直す・記録するを1つの流れにまとめている。「止まらない」という主張の実体は、確認と修正の手順まで自分で回すという設計だと読めます。

ナビゲーションには、セッション以外の機能も並びます。オートメーションは決まった手順を繰り返す仕組み、セキュリティレビューは脆弱性の確認、ウィキはリポジトリの知識を文書にする機能です。これらは単発の依頼ではなく、チームの運用に組み込む前提の機能です。1回の大きなタスクを任せる道具から、日常の小さなタスクを流し続ける道具へと、使い方の重心が移っていることがうかがえます。

公式トップには期間限定の告知もあります。「We’re giving enterprises $100M+ in credits to fix critical vulnerabilities with Claude Mythos. Terms apply.」という帯が最上部に掲載されています。脆弱性の修正にクレジットを出す、という案内です。金額は告知の表現なので、この記事では条件として書きません。こうした告知は期間と条件で変わるため、検討する場合は公式の案内を直接確認してください。

Devinの料金はいくらか。プラン構成と利用量の仕組み

2026年11月7日に取得した公式の料金ページから、プランを書き出します。個人向けは Free が0ドル、Pro が月20ドル、Max が月200ドルです。チーム向けは、チームプランが月80ドルで、これにフル開発シート1人あたり月40ドルが加わります。Enterprise は要相談で、SAML や OIDC の SSO、VPC 内への配備、専任の担当が含まれます。

表で注意したいのは、Teams の料金の書き方です。公式は「$80 /month for team plan + $40/mo per full dev seat」と表示しています。チームの土台に80ドル、その上に開発シート1人あたり40ドルが乗る形です。10人のチームなら月480ドルになります。全員が開発シートを持つ必要があるかは、公式の比較表からは読み取れません（未確認）。閲覧だけの人を安く入れられるかどうかは、見積もりの前に確認したい項目です。

より重要なのは、プランの月額が「利用量の上限」ではなく「枠の大きさ」だということです。公式の FAQ には「Each paid plan comes with a usage allowance that refreshes automatically on a daily and weekly basis.」とあります。枠は毎日と毎週、自動で補充されます。そして「Cost per message varies based on the model used, the task size and complexity, and the reasoning required.」とあり、1回の依頼の費用はモデル、作業の大きさ、必要な推論の量で変わります。つまり月20ドルは、使える量ではなく、枠の初期値です。

枠を使い切ったときの扱いも書かれています。「If you do go beyond your included usage on a paid plan, you can purchase extra usage which is consumed at API pricing.」という説明で、超えた分は API 価格で追加購入する形です。API 価格がいくらかは、料金ページに記載がありません。エージェントが使う計算量の単位である ACU の単価も、このページには無い。そのため「月20ドルでどれだけ任せられるか」を公開情報から金額で示すことはできません。Devinの費用は月額では読めず、モデルの選択とタスクの切り方で決まると理解しておくのが正しいと考えます。表示は地域・支払い周期・為替で変わるため、契約前に公式サイトの料金表を確認してください。

月20ドルのProで足りるのはどんな使い方か

公式の FAQ は、枠を長持ちさせる方法として3つを挙げています。プロンプトの大きさを抑えること、定型作業は小さいモデルに切り替えること、不要な文脈を削ることです。この3つは、裏を返せば枠の消費が「依頼の書き方」で変わるという意味です。大きなリポジトリを丸ごと読ませる依頼は、小さく切り出した依頼より消費が多くなります。Pro の月20ドルで足りるかは、依頼をどれだけ小さく切れるかで決まる。タスクの切り方が上手い人ほど、同じ金額で多くを任せられる構造です。

Cursor・Devin Desktopとの違いは？3つの道具を並べる

Cognition の製品は2つあり、名前が似ていて紛らわしいので整理します。Devin はクラウド上のエージェントで、指示を出して離れる使い方が中心です。Devin Desktop は、windsurf.com で案内されるデスクトップの製品で、公式の料金ページでも「Access to Devin Desktop」と書かれています。両方とも同じ会社の製品で、役割が分かれています。どちらかを選ぶというより、両方が同じ契約体系の中に置かれている形です。

Cursorとの違いは、仕事の置き方です。Cursor は、人が書く隣にAIがいて、補完と編集を速くする道具です。Devin は、人が席を外している間にエージェントが書いて、戻ってきたらPRを確認する道具です。この差は、作業の刻み方に現れます。Cursor は1行から数十行の単位で効き、Devin は1つのPRの単位で効きます。「書く速度を上げたいのか、書かない時間を作りたいのか」が、CursorとDevinの分かれ目だと考えます。両方を使うチームもあり、その場合の分担は、設計と試作が Cursor、切り出せる作業が Devin になります。

Devin Desktopの名で案内される Devin Desktop は、さらに別の役割です。公式の説明は「The home for every agent you run」「Manage any agent, locally or in the cloud, from one command center」で、走らせたすべてのエージェントを1か所で管理する、という位置づけです。Devin が「クラウド上の同僚」なら、Devin Desktop は「同僚が複数いる現場の進行管理」にあたります。1人で1つのタスクを任せる段階では Devin で足り、同時に5つのタスクを流す段階になると、Devin Desktop の一覧がないと状況が追えなくなります。

生成ツールとも性格が違います。v0 by Vercel、Bolt、Lovableは、指示から動くアプリとその公開までを担う道具です。Replitは開発環境ごとブラウザに置く方向、BubbleとSoftrはノーコードでアプリを組む方向になります。Devin は公開までを担わず、既存のリポジトリに手を入れてPRを出す側です。OnlookやMagic Patternsは画面の設計からコードへ渡す方向で、Devin の受け取る側にあたります。自社のコードベースがあるかどうかが、Devin と生成ツールの分かれ目になります。

どの道具を最初に置くべきか

最初に置くべきなのは、今いちばん時間を食っている作業を減らす道具です。設計を考えながら書く時間が長いなら Cursor、定型のタスクが溜まっているなら Devin、複数のタスクを同時に流したいなら Devin Desktop。自社のコードベースがまだ無いなら、生成ツールのほうが早い。4つの道具は置き換えの関係ではなく、開発の流れのどこを担うかが違います。1つずつ入れて、どこが詰まるかを見る順序が現実的です。

評価できるところ。PRが完成するまでを1つの単位にしたこと

• PRがマージ可能になるまでを1つの単位として扱う。確認と修正の往復を人に戻さない設計
• 自分のブラウザで試して、操作を録画する。何を確かめたかが記録として残る
• OS をまたいだ仮想環境を必要に応じて用意する。環境依存の不具合を確認しやすい
• Slack、Teams、Linear、Jira、GitHub、GitLab、Bitbucket とつながる。既存の流れを変えずに導入できる
• 作業の大きさに応じてモデルを切り替える。定型作業を小さいモデルに回せば枠が長持ちする
• Teams で請求が一本化され、管理画面から状況を見られる。最大200人まで対応
• Free の0ドルから始められ、インライン編集とタブ補完は無制限

一番の見どころは、作業の終わりの定義です。多くのAIコーディングの道具は、コードを提案して終わります。提案が正しいかは人が確かめ、間違っていれば直して再度頼む。この往復が、実際には時間の大半を占めます。Devin は「マージ可能」という状態を終わりに置き、その手前の確認と修正を自分で回します。人がPRを開いたときには、テストが通った状態になっている。作業の単位を「提案」から「PR」へ上げたことが、Devinの一番の差だと考えます。

二つ目は、記録が残ることです。公式の実演画面では、5つのテストが通ったこと、ブラウザで何を確かめたかが短く並びます。操作の録画も残ります。レビューする人は、コードだけでなく、何を根拠に正しいと判断したかを見られます。これは、外部の協力会社に作業を出したときに効きます。「試しました」という報告ではなく、試した様子が残るため、確認の往復が減ります。

三つ目は、既存の開発の流れに入る形です。Slack や Teams から依頼し、Linear や Jira のチケットと結び、GitHub、GitLab、Bitbucket に PR を出す。新しい道具を覚えるのではなく、すでに使っている道具の中にエージェントが現れる形です。導入の説明コストが低いことは、開発の現場では大きな差になります。

四つ目は、モデルの切り替えです。公式トップには Fusion、SWE-2 と外部のモデルが並び、作業に応じて選べる形が示されています。難しい設計は強いモデル、依存パッケージの更新は速くて安いモデル、という使い分けができます。この切り替えは費用にも直結します。枠の消費を抑える運用と、品質を優先する運用を、同じ契約の中で分けられるのは実務的です。

気になるところ。テストの前提と、金額の読みにくさ

• ACU の単価が公式の料金ページに無い。月20ドルでどれだけ任せられるかを金額で示せない
• テストが揃っていないリポジトリでは力を出しにくい。マージ可能の判断を自分で行う前提のため
• 枠は毎日と毎週で補充されるが、消費はモデルとタスクの大きさで変わる。見積もりが立ちにくい
• Teams の閲覧だけの席を安く入れられるかは未確認
• 生成コードの品質、日本語のコメントや指示への追従は未検証
• 期間限定の告知やモデル構成が変わりやすく、この記事の記述が古くなる可能性がある

一番の引っかかりは、費用の読みにくさです。プランの月額は明示されていますが、実際にいくら使うかは利用量で決まります。その利用量の単価にあたる ACU の金額が、料金ページにありません。API 価格で追加購入するという説明はありますが、その価格も記載が無い。そのため「月20ドルで何件のPRを出せるか」を、公開情報からは答えられません。見積もりは、Free か Pro で1週間動かし、日ごとの枠の減り方を記録してから行うべきです。

二つ目は、テストへの依存です。「PRがマージできる状態になるまで止まらない」という約束は、マージできるかどうかを判定する手段があって初めて成り立ちます。テストが無いリポジトリでは、何をもって完了とするかが曖昧になります。画面を触って確かめたという録画は残りますが、それが十分かは人が判断するしかない。テストの整備が済んでいないチームでは、Devin を入れる前にテストを足す必要があります。この順序を飛ばすと、生成されたコードの確認が人の負担に戻ります。

三つ目は、変化の速さです。ナビゲーションに並ぶ機能、選べるモデルの名前、トップの告知は、いずれも数か月で変わります。モデル名は SWE-2 のように公式の表記であっても、構成そのものが入れ替わる可能性があります。レビュー記事を読む側も、書かれた日付を先に確かめるべき製品です。導入の判断は、記事の記述ではなく、公式の画面で最新の構成を確認してから行ってください。

どんなチームに向き、どこで止まるか

向くのは、テストが整ったリポジトリを持ち、切り出せるタスクが毎週発生するチームです。依存パッケージの更新、小さなバグの修正、テストの追加、ドキュメントの整備。この種の作業は、要件が明確で、終わりの判定もしやすい。向かないのは、テストが無く、要件が会話の中で決まる開発です。新規サービスの立ち上げや、顧客と画面を見ながら詰める制作は、人とAIが交互に手を動かす必要があります。タスクを「切り出せる形に書けるか」が、Devinを使いこなせるかの分かれ目になります。

導入の順序。任せるタスクを選ぶところから

Devin を入れるとき、最初に決めるのはタスクの種類です。大きく3つに分けて考えます。1つは、依存パッケージの更新や小さなバグの修正で、手順が決まっていて終わりの判定が明確なもの。2つは、テストの追加やドキュメントの整備で、作業量は大きいが判断が少ないもの。3つは、新機能の実装で、設計の判断が要るもの。最初に任せるのは1つ目です。2つ目は量が多いので効果が出やすいが、確認の手間も増えます。3つ目は、任せる範囲を明確に切れないと、PRの確認が長引きます。

1. テストが通る状態のリポジトリを1つ選ぶ。テストが無ければ、先にテストを足す
2. 直近1か月で発生したタスクのうち、手順が決まっているものを10件書き出す
3. そのうち3件を Free か Pro で任せ、PRの確認にかかった時間を記録する
4. 枠の減り方を日ごとに記録し、1件あたりの消費の目安を出す
5. 確認時間が自分で書く時間より短ければ、任せる件数を増やす。長ければタスクの切り方を見直す

記録する項目は3つに絞ります。PRの確認にかかった時間、手直しの回数、そして枠の減り方です。確認時間が短いことと、手直しが少ないことは別です。確認が速くても、手直しが毎回2回入るなら、任せる範囲が広すぎます。枠の減り方は、日ごとの残量をメモするだけで足ります。この3つが揃えば、月の段を上げるか、タスクを絞るかの判断が、印象ではなく数字でできます。

任せる依頼の書き方も、この段階で決めます。公式の FAQ は、依頼の大きさを抑えること、定型作業は小さいモデルに回すことを推奨しています。この2つは、依頼の書き方とモデルの選択で実行できます。「この機能を追加して」ではなく「この3つのファイルのうち、この関数を修正して、このテストを通す」と書く。依頼が具体的なほど、消費する枠も小さく、PRの確認も速くなります。この書き方を社内のひな形にすると、誰が依頼しても同じ粒度になります。

導入の範囲は、段階を分けて広げます。最初の1か月は1人の開発者が3件、次の1か月は同じ人が10件、その次にチームの2人目を加える。各段階で確認時間と手直しの回数を比べます。手直しが増えたら、タスクの切り方かレビューの手順に問題があります。道具の性能ではなく、運用の設計を見直す合図です。この往復を3か月続けると、どのタスクを任せ、どこを人が見るかの分担が、チームの中に定着します。

任せてはいけないタスクの見分け方

次の3つは、最初から任せないほうが安全です。1つは、認証と課金の処理です。誤りが外に出たときの影響が大きく、テストで全てを拾えるとも限りません。2つは、本番のデータを触る移行作業です。取り返しがつかない操作は、人が手順を確認しながら行うべきです。3つは、外部のAPIの仕様が変わりやすい箇所です。ドキュメントが古いまま実装され、後で壊れる可能性があります。この3つを除いた範囲で、まず10件を任せて記録を取る。そこで得た数字が、次の段階に進むかどうかの根拠になります。

Cursorと併用するチームの、現実的な分担

Devin と Cursor は、競合として語られがちですが、現場では併用する形が現実的です。理由は、1日の開発の流れに、速度が要る場面と、離れて待てる場面の両方があるからです。設計を考えながら書く午前と、切り出したタスクを流して会議に出る午後。この2つの時間は、別の道具が向いています。

分担の線は、人がその場にいる必要があるかで引きます。判断をその場で積み上げたい作業は Cursor、判断を最後にまとめてしたい作業は Devin。会議や移動の合間に進めたい作業は、迷わず Devin に向きます。この線を引いておくと、依頼を出すタイミングが自然に決まります。依頼を出してから会議に出て、戻ってPRを確認する、という1日の組み立てができる。

併用するときの注意は、同じファイルを2つの道具が同時に触らないことです。Cursor で開いているブランチと、Devin が作業しているブランチは分けます。同じ箇所を別々に直すと、マージの手間が増え、どちらの変更が正しいかの判断も難しくなります。担当をファイル単位かタスク単位で分けるのが基本です。この運用は、Devin を単独で使うときにも同じように効きます。

費用の面でも、併用は合理的です。Cursor の月額は固定で、Devin は利用量で変わります。書く時間の大半を Cursor で賄い、切り出せるタスクだけを Devin に流すと、Devin の枠の消費を抑えられます。逆に、すべての作業を Devin に流すと、枠が早く減ります。どの作業をどちらに振るかは、タスクの切り出しやすさと、待てる時間の長さで決めてください。

併用を続けるかの判断基準

3か月続けて、次の3つを見ます。1つは、Devin が出したPRのうち、手直しなしでマージできた割合。2つは、人が書いていた時間のうち、Devin に移せた割合。3つは、枠の消費が月の想定に収まっているか。1つ目が半分を下回るなら、任せるタスクの選び方が合っていません。2つ目が伸びないなら、依頼を出す習慣が定着していない。3つ目が大幅に超えるなら、モデルの選択を見直す段階です。この3つが揃って初めて、併用を続ける価値があるかを判断できます。

よくある質問

まとめ：Devinは「終わりの定義」を変える道具

主な参照元：Devin公式サイト「Plans and Pricing | Devin」（2026年11月7日確認。Free 0ドル、Pro 月20ドル、Max 月200ドル、Teams 月80ドルとフル開発シート1人あたり月40ドル、Enterprise 要相談、最大200人、SWE-2 の無料利用、超過は API 価格での追加購入、枠が日次と週次で補充される旨、利用量がモデルとタスクの大きさと推論の量で変わる旨、枠を長持ちさせる方法、SAML と OIDC の SSO、VPC 内への配備、Devin Desktop へのアクセスはここによります）。Devin公式サイト「Devin: the autonomous software engineer」（2026年11月7日閲覧。クラウドか手元で動くこと、自分のブラウザで試すこと、PRがマージ可能になるまで止まらないこと、Windows・Mac・Linux の仮想環境、操作の録画、Automations・Security Review・Wiki、Fusion と SWE-2 を含むモデル選択、Slack・Teams・Linear・Jira・GitHub・GitLab・Bitbucket との連携、トップのクレジット提供告知はここによります）。Devin Desktop は windsurf.com の案内に基づきます。ACU の単価と API の追加購入価格は料金ページで確認できていないため記載していません。生成コードの品質、日本語の指示への追従、閲覧専用シートの扱いは未検証です。実機検証は未実施です。