Devinとは？CognitionのAIソフトウェアエンジニアを解説

Devinは「エンジニアという職能を置き換える自律エージェント」なのか、それとも「境界の明確な作業を先に走らせる委任先」なのか。この線をどこに引くかで、導入判断は正反対になります。前者だと思って導入すると、Answer.AIが独立テストで報告した「20タスク中3成功」という数字に落胆することになりますし、後者だと理解して導入すれば、Goldman SachsやDeNAが公開している運用モデルに近づけます。

私はDevinを「AIエンジニアという職能の代替」ではなく「境界が確定した作業の委任先」として評価すべきだと考えています。導入の可否を決めるのはモデルの賢さやベンチマークの数字ではなく、自社に(1)渡せる形に切り出せる作業があるか、(2)成否を機械的に検証できるか、(3)人がレビューを差し込む運用があるか、の3点です。この3つが揃わない組織にとって、Devinは高価なハルシネーション製造機になり得ます。ただし、この境界の外側——研究的な仕事や仕様がまだ動いている仕事でのDevinの価値については、本記事では判断を保留します。

本記事では、Cognitionの公式サイト・料金ページ・Windsurf買収発表・DeNAの公開発表・Answer.AIの独立評価を出典として使います。個別のARRや評価額、ベンチマークスコアは時点依存で古くなりやすいため、そうした数値そのものよりも「どの作業を委任し、どこにレビューを置いているか」という運用モデルを軸に整理します。

「委任可能タスク」という枠組みは、Devin固有の話ではなく、コーディングエージェント全般に適用できる判断軸だと考えます。渡す作業のスコープが事前に確定でき、成否を機械的に検証できる仕組みがあり、人がレビューを差し込む位置が設計されている——この3条件は、どのベンダーのagentであっても導入可否を分ける境界線になるはずです。逆に言えば、この3条件を満たせない作業を「とりあえず投げてみる」導入の仕方は、ベンダーやモデルの性能に関係なく再現性のある成果を生みにくい、というのが本記事の立場です。

前提

この記事の主張を反証可能にするために、2つの言葉を先に定義します。

委任可能タスクとは、「スコープが事前に確定できる」「成否が機械的に検証できる(テストが通る、ビルドが通る、差分が期待通りなど)」「人がレビューを差し込むポイントがある」の3条件を満たす作業を指します。この定義がなぜ有効かというと、Answer.AIの「どのタスクが成功するか予測できない」という指摘と、Goldman SachsやDeNAの「うまくいっている」という報告を、矛盾なく同時に説明できるからです。前者は委任可能タスクの境界を越えたケースを含んでいた可能性が高く、後者は境界の内側に運用を絞っています。

ACU(Agent Compute Unit)は、Devinが使う計算資源をまとめる単位として公式に定義されています(出典: https://devin.ai/pricing/)。ここで重要なのは、ACUを「席数(seat)」ではなく「委任量」として読み替えることです。費用は使うエンジニアの人数ではなく、境界ある作業を何本委任し、何本のセッションを並列で回すかによって動きます。

Devinはセキュアなサンドボックス環境で動作し、Planning Checkpoint(タスク分解後・実行前)とPR Checkpoint(コード完成後・マージ前)の2箇所で人の承認を挟む設計になっています。この2段階承認は、上記の「レビューを差し込むポイント」の具体的な実装です。

全体像

Devinには3つの利用方法があります。Session(Web上のチャット形式)、Slackbot(チャンネルでのメンション起動)、API(CI/CDパイプライン統合)です。個人が単発タスクを試すならSession、チーム開発ならSlackbot、大量タスクの一括処理ならAPIが向いています。

いずれの経路でも、Devinは自然言語のタスクを受け取ったあと、まず計画を提示してPlanning Checkpointで承認を求め、実行後にPR Checkpointで再度承認を求めます。この2段階の外側で人が何を確認しているかが、次に見る事例の違いを生んでいます。

何に使われているか

case studyを数値そのものより先に見るべきは、何を委任しているかとどこで人がレビューしているかです。

Goldman Sachs——問題設定は人、先行はagent、レビューは人

Goldman Sachsについての公開報道(出典: CNBC https://www.cnbc.com/2025/07/11/goldman-sachs-autonomous-coder-pilot-marks-major-ai-milestone.html)で繰り返し現れるのは、Devinを「万能な代替人員」としてではなく、ドキュメント整備・セキュリティ修正・テスト準備のようなbacklog taskを前に進める補助線として使う見方です。ここでの運用モデルは、人が問題設定を行い、agentが先に動き、人が最後にレビューするという一点に集約できます。headcountや生産性向上の数字は時点依存なので、本記事では運用モデルの方を重視します。

DeNA——governanceを先に整えてから展開範囲を広げる

DeNA AI Linkの公開発表(出典: dena.com/intl/news/4755、日経・ITmedia報道)で注目すべきは、展開した人数規模よりもどのgovernanceを先に整えたかです。VPCと物理隔離を含むセキュリティ設計、SSOを含む認証・認可の運用整備は、いずれも全社展開の前段階で行われています。日本企業が参考にすべきなのは、プロンプトの巧拙よりも、隔離環境・権限設計・レビューフローをセットで用意するという導入の順序です。

得意・不得意の非対称

Cognitionが公開した2025年のパフォーマンスレビュー(出典: https://cognition.ai/blog/devin-annual-performance-review-2025)は、得意なタスクと苦手なタスクの非対称を示しています。得意なのはドキュメンテーション、QE/SRE/DevOps系の定型作業、小規模で反復的なマイグレーション、バグ修正のような境界が明確な作業です。苦手なのは曖昧なスコーピング、タスク中途での仕様変更、視覚デザインのような具体的な指定が必要な作業、そして反復的な「ラストマイル」の洗練です。この非対称は、前述の「委任可能タスク」の定義とそのまま重なります。

料金の読み方

devin.ai/pricingでは、Core($20からのpay-as-you-go)、Team($500/月、included ACUあり)、Enterprise(問い合わせベース)の3層で案内されています。固定のseat料金として読むのではなく、どれだけ作業を委任するかとどこまでセキュリティ・管理機能が必要かで見る方が実態に近いです。

料金を見るときに効くのは、1つのタスクがどれくらい長く走るか、調査・ブラウザ操作・テスト・レビュー準備までをDevinに持たせるか、同時に何本のセッションを回したいか、の3点です。月額の絶対値よりも、この委任量の設計が費用を動かします。Core・Team・Enterpriseという3層が示すのは「席数の上限」ではなく「委任量とガバナンス要件の段階」であり、Core→Team→Enterpriseの移行は人数が増えるからではなく、委任するタスクの本数とセキュリティ・管理機能の必要度が変わるから起きる、と読むのが公開情報からの妥当な解釈だと考えます。

公開されている料金体系(Core/Team/Enterpriseの3層)から読み取れるのは、Devinが「席数課金」ではなく「委任量・ガバナンス課金」の設計を意図的に選んでいるということです。Core($20からのpay-as-you-go)は個人が単発タスクを試す入口として、Team(included ACUあり)はチームで委任本数を積み増す段階として、Enterprise(問い合わせベース)はセキュリティ・管理機能が必要になる段階として、それぞれ性質の異なる導入フェーズに対応していると読むのが妥当でしょう。

批判と限界
、境界を越えている

2025年1月、AIリサーチ企業のAnswer.AIは、3人のデータサイエンティストが20の実世界コーディング課題をDevinに与えた独立テストを公開しました(出典: https://www.answer.ai/posts/2025-01-08-devin.html)。結果は成功3件(15%)、失敗14件(70%)、結論なし3件(15%)という数字です。

Answer.AIが最も深刻だとしたのは、パフォーマンスの予測不可能性でした。

"More concerning was our inability to predict which tasks would succeed. Even tasks similar to our early wins would fail in complex, time-consuming ways."

「より懸念されるのは、どのタスクが成功するか予測できないことでした。初期の成功と似たタスクでさえ、複雑で時間のかかる方法で失敗しました」

— Answer.AI

象徴的なのはハルシネーションの事例です。あるタスクで、DevinはRailway(クラウドプラットフォーム)に単一デプロイメントで複数アプリケーションをデプロイしようとしましたが、そのような機能はRailwayに存在しません。Devinは存在しない機能を探しながら、1日以上かけて様々なアプローチを試行し続けました。

私はこの「予測不可能性」を、Devinの性能が不安定だからではなく、Answer.AIが与えたタスクの一部が「委任可能タスク」の境界の外にあったからだと読みます。スコープが事前に確定できず、成否の検証手段も曖昧なタスクを与えれば、どのモデルであれ予測不可能な挙動になり得ます。Answer.AIの結論も「シニアエンジニアの代替ではなく、ジュニアエンジニアとして扱う必要がある」というものであり、明確な指示・監督・適切なタスク選定が前提になっています。

Answer.AIのRailway事例が示唆するのは、ハルシネーションそのものよりも「エージェントが自分の誤りに気づく手段を持たなかった」という構造の問題だと考えます。存在しない機能を1日以上探し続けられたのは、成否を機械的に検証する仕組み——たとえば実行結果を即座に突き返すテストやビルド——がそのタスクに組み込まれていなかったからです。委任可能タスクの3条件のうち「成否を機械的に検証できるか」が欠けると、モデルの賢さに関係なくこの種の暴走は起こり得ると見るべきでしょう。

Answer.AIのRailway事例が示す構造——検証手段のないタスクで、agentが自分の誤りに気づけないまま時間を溶かし続ける——は、Devinに限らず自律型エージェント全般が抱えるリスクだと考えます。エージェントに「賢さ」を求める前に、そのタスクに機械的な検証手段を用意できているかを問う方が、実務上は再現性の高い予防策になるはずです。

導入順序として読む

Cognitionの2025年7月のWindsurf買収(出典: https://cognition.ai/blog/windsurf、TechCrunch https://techcrunch.com/2025/07/14/cognition-maker-of-the-ai-coding-agent-devin-acquires-windsurf/)で持続的なのは、買収額そのものではなく、何を統合しようとしているかです。発表文はWindsurfのプロダクト・IP・チームを取り込みながら、Devinのagent実行とIDE workflowを近づける方向を示しています。ここで見るべき論点は、タスクの委任とエディタ上の手直しを同じ流れに置けるか、コードベース理解をドキュメントや計画立案にどう還元するか、人がアーキテクチャの判断を持ち続けたままagentを増やせるか、の3点です。

DeNAの導入プロセスも同じ順序で読めます。セキュリティ審査とVPC環境構築を伴う限定チームでのPoC、部門横断での活用拡大、SSO連携を含む全社展開という段階を経ています。つまりWindsurf買収もDeNAの展開も、「隔離環境→権限設計→レビューフロー」という同じ導入順序をなぞっています。

再分類

ここまでの事例を、タスクの種類ではなく「なぜ委任できたか」で並べ替えると、次の3つの条件に集約できます。

スコープが事前に確定できたか — Goldman Sachsのセキュリティ修正・ドキュメント更新、Cognitionの得意タスク(QE/SRE/DevOps、小規模反復)は、いずれも作業開始前にゴールが定義できています。
成否を機械的に検証できたか — テストが通る、ビルドが通る、差分が仕様通りといった検証手段がある作業は、Planning/PRの2段階承認と組み合わさって機能しています。Answer.AIの失敗事例の多くは、この検証手段自体が曖昧でした。
人がレビューを差し込む位置を設計していたか — Goldman Sachsの「人が問題設定→agentが先行→人が最後にレビュー」、DeNAの「governanceを先に整えてから展開範囲を広げる」は、いずれもレビュー位置を先に決めてから運用を始めています。

導入を検討する組織にとってのチェックリストは、この3条件をそのまま使えます。渡せる作業があるか、検証手段があるか、レビューの置き場があるか——この3つが揃わないまま導入すると、Answer.AIが遭遇したような予測不可能な挙動と向き合うことになります。

持ち帰れること

私自身は、この「委任できるか」の線引きを、コーディングエージェントに限らず今後の自社ツール選定の判断軸として使おうと考えています。スコープが確定できない仕事にAIを投げるのは、モデルの性能に関係なく構造的に分が悪い、というのがAnswer.AIの事例から読み取れる教訓だと思います。

小さなチームで導入を検討する場合ほど、この線引きは効いてくると考えます。人員が少ない組織はレビュー工数を十分に割けないため、渡す作業のスコープを事前に狭く確定し、検証手段をあらかじめ用意してから委任範囲を広げる方が安全なはずです。逆に、レビュー体制を整える前に委任範囲を広げると、少人数であるがゆえに予測不可能な挙動を吸収しきれず、かえって手戻りコストが大きくなるだろうというのが、ここまでの整理から導ける判断軸です。

小さなチームであるほど、この線引きを自社に持ち帰る際は「まず1つだけ、境界が明確な作業を選んで委任してみる」という順序を取るべきだと考えます。Goldman SachsやDeNAの事例も、いきなり広範囲に展開したのではなく、検証しやすい作業やgovernanceの整備を先に済ませてから範囲を広げています。少人数の組織ほどこの順序を飛ばす余裕がないはずで、委任範囲を広げる前にレビュー体制と検証手段を先に固める方が、結果的に手戻りを減らせると考えます。

境界の外側——研究的な仕事や仕様が動き続ける仕事でDevinがどこまで機能するかは、まだ判断を保留します。この線引き自体、Devinやその競合の運用モデルが変われば見直す必要が出てくるはずです。データや事例は脅しではなく、読者自身の導入判断の材料として使ってもらえればと思います。

対話型のIDE補助という別モードについては、Cursorの深掘り記事で扱っています。本記事はDevinの委任型に焦点を絞るため、両者の比較テーブルはそちらに委ねます。

ゼロからの構築というもう1つの別モードについては、Replit Agentの深掘り記事を参照してください。Devinの「既存コードベースへの委任」とReplitの「ゼロからの構築」は対になる軸です。

AIコーディング市場全体の規模や各社評価額については、AIコーディング市場の俯瞰記事にまとめています。

参考リソース

Cognition Labs公式

テックメディア報道

日本市場

独立評価

Scott Wu関連

本記事はネクサフローのAI研究シリーズの一部です。

この記事の著者

中村知良

代表取締役

早稲田大学卒業後、ソフトバンク株式会社にてAI活用やCEO直下案件のプロジェクトマネージャーに従事。その後、不動産スタートアップPit in株式会社の創業、他スタートアップでの業務改善・データ活用を経験後、2023年10月、株式会社ネクサフローを創業し代表取締役CEO就任。

前提

この記事の主張を反証可能にするために、2つの言葉を先に定義します。

全体像