2026 年上半期の Devin を見ると、変化の中心は、AI がコードを書く能力の向上だけには収まらない。より重要なのは、開発作業の置き場所が変わったことである。従来の開発支援 AI は、開発者の手元で候補を出し、説明し、差分の作成を補助するものとして理解されやすかった。そこでは、AI の出力は人間の作業場に差し込まれる補助材料であり、最終的な調査、実行、確認、修正は人間の流れの中に残りやすかった。Devin は、この配置を別の方向へ動かした。クラウド上に独立した作業環境を持ち、タスクを受け取り、リポジトリを読み、依存関係を調べ、実装し、テストし、プルリクエストを作り、レビュー指摘や継続的インテグレーションの失敗を受けて修正し、必要に応じて複数の Devin を並列に動かす。この変化は、単に作業速度が上がったという話ではなく、開発工程の一部が人間の手元から独立した作業主体へ移されることを意味する。
この変化には、少なくとも二段階の因果関係がある。第一に、AI がリポジトリ、シェル、ブラウザ、テスト、課題管理、プルリクエストと結びついたことで、出力の単位がコード断片から作業結果へ変わった。短い関数案を返すだけであれば、人間はその場で読んで採否を決めればよい。しかし、AI が既存コードを読み、コマンドを実行し、複数ファイルを変更し、テスト結果を見て修正するようになると、成果物は単なる提案ではなく、開発工程に流し込める差分になる。第二に、成果物が差分やプルリクエストに近づくほど、人間側の問題は「コードが出るか」から「その作業をどこまで任せ、どこで止め、何を根拠に採用するか」へ移る。能力が上がることで作業範囲が広がり、作業範囲が広がることで責任境界と検証経路が問題になる。この順序を押さえないと、Devin の半年の変化は、機能追加の羅列に見えてしまう。
既稿では、Devin と Claude Code の違いを、モデルの優劣ではなく作業の任せ方の違いとして整理した。Claude Code は、開発者の手元の環境に入り、差分を見ながら人間の判断を支える型である。Devin は、独立した作業場にタスクを渡し、調査、実装、検証をまとめて進める委任型の構造を持つ[1]。この差は、製品仕様の違いにとどまらない。前者では、曖昧さを作業中の対話と差分確認で処理しやすい。後者では、作業を渡す前に目的、制約、変更範囲、完了条件をより明確にする必要がある。したがって、Devin の進化を追うことは、一つの AI 開発製品の変化を見ることに加えて、開発作業をどの単位で切り出し、どの環境へ渡し、どの時点で人間が判断を戻すのかを読むことでもある。
この整理は、生成 AI の競争軸がモデル単体から業務実装へ移るという既稿の議論にも接続する。企業利用では、モデルが自然な文章や正しそうなコードを返せるだけでは価値が確定しない。どのリポジトリに接続できるのか、どの権限で動くのか、どのツールを使えるのか、どのログが残るのか、誰がレビューするのか、費用をどう管理するのかが成果を左右する[2]。Devin の 2026 年上半期の更新は、まさにこの業務実装の層を厚くする方向に進んだ。レビュー、自動修正、自己検証、複数エージェントの管理、定期実行、外部ツール接続、企業向けの権限制御、費用対効果の測定が積み重なったことで、Devin は単独のコード生成器ではなく、開発工程の中に配置されるクラウド型の作業基盤へ近づいた。
ここでいう AI ソフトウェアエンジニアとは、人間のエンジニアと同じ人格、経験、責任を持つ存在という意味ではない。ソフトウェア開発で必要になる調査、実装、実行、検証、報告、修正といった工程を、一定の独立性をもって遂行する作業主体という意味である。この言葉を使うと、AI が人間をそのまま置き換えるという誤解が生じやすい。しかし実務上の焦点は、置き換えではなく配置である。人間は、目的を定め、制約を与え、判断基準を作り、結果を採用する責任を持つ。AI は、その範囲内で調査や変更作業を前へ進める。AI に任せる前に人間が判断軸を残すべきだという既稿の議論[3]、および AI の出力は採用された時点で人間側の責任になるという既稿の議論[4]は、この点で Devin の問題と直接つながる。
1. Devin は実装代行から開発実行基盤へ移った
2026 年上半期の Devin の変化は、機能追加の一覧としてだけ見ると焦点がぼやける。1 月に Devin Review が登場し、2 月に Auto-Fix と Devin 2.2 が出て、3 月に Managed Devins と Scheduled Devins が加わり、4 月に Windsurf 連携、CLI、企業統制が進み、5 月に Android、Windows、Auto-Triage が追加され、6 月に Devin Desktop、Productivity Estimator、FrontierCode、Devin Fusion が発表された。この並びは多く、個別に追うと製品更新の記録に見える。しかし、機能を工程上の位置に置き直すと、別の構造が見える。Devin は、実装だけでなく、レビュー、修正、検証、並列化、定期実行、作業環境の拡張、企業統制、価値測定を一つの流れへ集めている。
初期の Devin は、Cognition によって「最初の AI ソフトウェアエンジニア」として紹介された[5]。その時点でも、Devin はチャット欄でコード片を返すだけの仕組みではなく、シェルやブラウザを使い、リポジトリ内で作業し、プルリクエストを開く存在として提示されていた。ここに、第一段階の変化がある。AI は、回答を返す場所から、作業を進める場所へ移った。コードを提案するだけなら、人間の作業場はそのままでよい。しかし、AI が実行環境を持ち、コマンドを走らせ、エラーを読み、修正を重ねるなら、AI 側にも開発作業の場が必要になる。
2026 年上半期の更新は、その第一段階をさらに進めた。第二段階では、作業場を持つ AI が、開発工程の複数地点に配置され始めた。Devin Review は、差分を理解し、レビュー負荷を下げる方向へ進んだ。Auto-Fix は、レビュー指摘や継続的インテグレーションの失敗を次の修正作業へ変えた。Computer Use は、変更結果を実際に動かして確認する経路を広げた。Managed Devins は、大きな作業を複数の Devin に分けて進める構造を示した。Scheduled Devins は、毎回人間が呼び出すのではなく、定期的に作業を拾う形を作った。これらは別々の便利機能ではなく、開発工程の各地点に AI の作業単位を置くための実装である。
この流れから見える中心命題は明確である。Devin の進化は、コード生成能力の向上ではなく、開発作業の配置転換である。人間がすべての実装、検証、修正を手元で抱える形から、明確に切り出された作業をクラウド側のエージェントへ渡し、人間は目的、設計判断、レビュー、採用判断に集中する形へ移る。この変化は、作業量の削減だけを意味しない。むしろ、人間が何を先に決めるべきかをより厳しくする。目的が曖昧なままなら、Devin はその曖昧さを作業結果として具体化してしまう。完了条件が弱ければ、見かけ上は進んだ作業でも、レビュー時に判断不能になる。つまり、Devin が強くなるほど、人間側のタスク設計、検証条件、責任境界が重要になる。
| 観点 | 従来の補助型 AI | 2026 年上半期の Devin |
|---|---|---|
| 作業場所 | 開発者の手元の作業環境に入り、補完や修正案を提示する。 | クラウド上の独立した作業環境で、調査、実装、検証、報告をまとめて進める。 |
| 成果物 | コード断片、説明、修正案、差分候補が中心になる。 | プルリクエスト、レビュー対応済み差分、テスト結果、録画、調査報告が成果物になる。 |
| 人間の役割 | AI の出力をその場で読み、必要に応じて手で直しながら作業を進める。 | 目的、制約、完了条件を先に定め、委任された作業結果をレビューして採用判断を行う。 |
| 失敗時の処理 | 人間がエラーやレビュー指摘を読み、修正方針を考えて再作業する。 | レビュー指摘、継続的インテグレーション、テスト失敗を Devin が次の修正入力として扱う。 |
| 導入条件 | 開発者個人の使いやすさやエディタとの相性が大きい。 | 権限、監査、秘密情報、外部ツール接続、費用上限、企業内の承認手順が重要になる。 |
この点を一般化すると、AI ソフトウェアエンジニアの進化は、人間の判断を消す方向には進んでいない。むしろ、判断の位置を変えている。従来は、開発者が手を動かしながら仕様理解、実装、検証、修正を一体として進めることが多かった。Devin 型の委任では、その一体化した作業から、AI に渡せる部分を切り出す必要がある。切り出された作業は、クラウド上で非同期に進む。その結果を人間が読み、採用するかどうかを判断する。この構造では、AI の性能だけでなく、作業単位の設計、接続する情報、実行権限、確認手順、費用管理が成果を決める。2026 年上半期の Devin は、この条件を満たすために、実装代行から開発実行基盤へ移ったのである。
2. 2026 年上半期には、大きな発表と細かな運用機能が同時に積み上がった
Devin の 2026 年上半期は、目立つ製品発表だけで進んだわけではない。公式リリースノートを見ると、2026 年 1 月 9 日から 6 月 26 日まで、ほぼ週次に近い密度で更新が並んでいる。そこには Devin Review、API、Automations、MCP、GitLab、Windows、Android、作業環境設定、ACU 管理、Slack、Linear、権限管理、利用分析、日本語対応などが記録されている[6]。この細かさは、Devin の進化を読むうえで重要である。AI エージェントは、一度の大きなモデル更新だけで開発現場に定着するわけではない。日々の作業で詰まりやすい接続、権限、通知、実行環境、費用、レビュー画面を少しずつ整えることで、実務の流れに入り込んでいく。
| 時期 | 主な更新 | 開発工程上の意味 |
|---|---|---|
| 1 月 | Infosys との提携、Devin Review、Linear 連携、セッション単位の秘密情報管理、Copy Context が確認できる。 | 企業導入の入口が作られ、Devin がプルリクエストの差分を読み、既存の開発管理の流れに接続する方向が明確になった。 |
| 2 月 | Scheduled Devins、Fast Mode、v3 API、Devin 2.2、Computer Use、Auto-Fix が並ぶ。 | 作業の起動、実行速度、API 化、自己検証、レビュー指摘の自動修正が前進し、Devin が一度作業して終わる存在から、指摘を受けて修正を重ねる存在へ近づいた。 |
| 3 月 | Managed Devins、Datadog MCP、スケジュール管理、セッション管理、知識管理、プレイブック管理が加わる。 | 単体エージェントが一つの作業を抱える構造から、複数の Devin へ作業を分け、定期的に発生する作業を継続処理する構造へ広がった。 |
| 4 月 | Windsurf 連携、CLI、企業向け秘密情報管理、MCP の許可リスト、ACU 上限、作業環境設定の管理、日本展開が続く。 | 手元の開発環境とクラウド側の委任作業が接続され、企業が Devin を使うために必要な権限、費用、接続先の制御が厚くなった。 |
| 5 月 | Android Emulator、Windows PC、Auto-Triage、GitLab Review、PR Review API、テスト信頼性の改善が加わる。 | 対象環境が Web アプリケーション中心から、モバイル、Windows、運用アラート、GitLab を含む現実の企業開発環境へ広がった。 |
| 6 月 | Devin Desktop、Productivity Estimator、Productivity Guarantee、FrontierCode、MCP Marketplace 拡張、Devin Fusion が出る。 | Devin の評価軸は、単にタスクを解けるかではなく、人間相当工数、品質、費用対効果、複数モデル運用、統合開発環境としての扱いやすさへ広がった。 |
この台帳から見えるのは、Devin の進化がモデル性能の上昇だけでは説明できないということである。もちろん、基盤となるモデルの能力は重要である。モデルが弱ければ、調査、実装、修正、説明のどの段階でも品質は安定しない。しかし、実際の開発現場では、モデルが賢いだけでは作業は完了しない。リポジトリへ安全に接続できるか、指示をセッションとして管理できるか、Slack や Linear から起動できるか、MCP 経由で監視情報や設計資料を読めるか、どの権限でプルリクエストを作るか、費用がどこまで増えるかを制御できるかが問われる。
ここには、二段階の因果関係がある。第一に、AI エージェントが実装以外の工程へ入るほど、必要な接続先と管理対象が増える。コードを書くためにはリポジトリが必要であり、修正の妥当性を確かめるにはテストや継続的インテグレーションが必要であり、障害や運用課題を調べるには監視情報や課題管理システムが必要になる。第二に、接続先が増えるほど、企業利用では権限、秘密情報、監査、費用管理が不可欠になる。便利に接続できるだけでは足りない。誰が、どの作業で、どの情報に触れ、どの範囲の費用を使い、どの成果物を残したのかを説明できなければ、実務には載せにくい。
したがって、2026 年上半期の Devin の更新台帳は、単なる機能追加の記録ではない。そこには、AI エージェントが開発現場に入るために必要な条件が、順番に積み上がっている。1 月から 2 月にかけて、Devin はレビュー、自己修正、自己検証へ広がった。3 月から 4 月にかけて、複数エージェントの管理、定期実行、ローカル開発環境との接続、企業統制が厚くなった。5 月から 6 月にかけて、対象環境、運用トリアージ、価値測定、費用対効果の議論が前面に出た。この順序は、Devin がコード生成器から開発実行基盤へ変わる過程そのものを示している。
3. 2026 年上半期の Devin は、企業の作業力を増やすものとして売られ始めた
2026 年上半期の Devin は、個人開発者が試す実験的な道具としてだけ展開されたわけではない。1 月 7 日には Infosys との提携が発表され、Devin を Infosys の組織とグローバル顧客基盤へ展開する方向が示された[7]。この発表で重要なのは、Devin が一人の開発者を補助する製品としてではなく、システムインテグレーターや大企業の開発力を増幅する手段として位置づけられている点である。AI エージェントは、コードを書く補助機能としてだけ売られているのではない。保守、移行、テスト、レビュー、調査、修正といった組織内の作業量を処理するための追加的な実行力として売られ始めている。
ここには、二段階の変化がある。第一に、AI が個人の作業を補助する段階では、価値は主に「一人の開発者がどれだけ速く作業できるか」で測られやすい。補完が速い、説明が分かりやすい、修正案が出る、という評価である。第二に、AI が企業に導入される段階では、価値は「組織全体の滞留をどれだけ減らせるか」に移る。開発組織では、コードを書く時間だけが問題ではない。レビュー待ち、テスト修正、古い依存関係の整理、移行作業、運用アラートの調査、ドキュメント更新、軽微だが放置されやすい不具合修正が積み上がる。Devin の企業導入は、こうした作業の滞留を、クラウド上のエージェントへ委任できるかという問題として現れている。
| 観点 | 個人利用で重視されること | 企業導入で重視されること |
|---|---|---|
| 価値の単位 | 一人の開発者が、実装や調査をどれだけ速く進められるかが中心になる。 | 組織全体で、レビュー待ち、保守、移行、テスト、調査の滞留をどれだけ減らせるかが中心になる。 |
| 接続対象 | 手元のエディタ、リポジトリ、ターミナルとの相性が大きい。 | GitHub、GitLab、Slack、Linear、監視基盤、社内文書、認証基盤、権限管理との接続が必要になる。 |
| 成功条件 | 実装案が有用で、開発者がその場で採用できることが重要になる。 | 作業の結果がレビュー可能で、監査でき、費用を説明でき、既存の承認手順に載ることが重要になる。 |
| リスク | 誤ったコード、過剰な修正、文脈誤解が主な問題になる。 | 秘密情報へのアクセス、権限過多、費用増大、責任分界の不明確さ、監査不能性が問題になる。 |
企業導入が前面に出ると、AI エージェントに求められる条件は変わる。個人が試すだけなら、数回の成功例で十分に有用に見えることがある。小さな不具合を直せた、テストを書けた、説明が正しかった、という成功体験がそのまま評価につながる。しかし企業では、それだけでは足りない。誰が使うのか、どのリポジトリへアクセスできるのか、秘密情報をどう渡すのか、監査ログは残るのか、費用は制御できるのか、出力を誰が承認するのかが問題になる。便利に動くことと、組織の中で安全に動かせることは別の条件である。
この違いは、Devin の製品更新の方向にも反映されている。企業導入では、AI エージェントは単独のチャット画面では完結しない。既存の開発管理、認証、通知、レビュー、監視、費用管理へ接続される必要がある。接続先が増えるほど、AI は多くの情報を使って作業できるようになる。その一方で、接続先が増えるほど、アクセス制御、秘密情報、監査、誤操作時の影響範囲も問題になる。したがって、企業向けの Devin では、単に多くの作業をこなせることに加えて、どの作業を、どの権限で、どの範囲まで実行できるかを制御できることが重要になる。
4 月には日本展開も発表され、Cognition は Takumi Masai 氏を Japan President and GM として迎え、日本企業との連携を進めると説明した[8]。日本展開は市場拡大のニュースであると同時に、Devin が英語圏の開発実験に閉じず、企業文化、言語、既存システム、運用慣行が異なる環境へ入っていくことを示している。AI エージェントが業務実装へ進むなら、機能だけでは不十分である。現場の説明責任、稟議や承認、委託先との関係、セキュリティ審査、既存システムの保守慣行、ドキュメント文化の違いにも向き合う必要がある。
| 層 | Devin に求められること | 企業導入での意味 |
|---|---|---|
| 作業遂行 | 調査、実装、テスト、修正、報告を一定の独立性をもって進める。 | 人間がすべてを手で抱えるのではなく、明確に切り出した作業を非同期に進められる。 |
| 開発工程への接続 | プルリクエスト、課題管理、チャット、監視、継続的インテグレーションへ接続する。 | AI の作業結果が、既存の開発手順から外れずにレビューと承認へ進む。 |
| 統制 | 権限、秘密情報、利用範囲、費用、監査可能性を管理する。 | AI エージェントを便利な個人ツールではなく、組織の管理対象として扱える。 |
| 説明責任 | 何を根拠に変更したのか、どの結果を確認したのか、どこに未確認点が残るのかを示す。 | 人間が最終的に採用判断を行うための材料を残せる。 |
この視点で見ると、上半期の早い段階で企業導入の発表が置かれていることは偶然ではない。Devin の価値は、単にコードを速く書くことではなく、企業が抱える保守、移行、テスト、レビュー、トリアージ、ドキュメント整備といった作業の滞留を減らすところにある。AI エージェントの販売対象が「一人の開発者」から「組織の作業力」へ広がると、製品の中心も変わる。チャット画面やコード生成機能だけではなく、組織内で動くための接続、権限、監査、費用管理、承認手順が重要になる。
ここから一般化できることは、企業向け AI エージェントの価値は、モデルの能力だけでは決まらないということである。モデルの能力は必要条件である。しかし、十分条件ではない。企業にとって重要なのは、その能力が既存の開発工程に入り、適切な権限で動き、結果を確認でき、費用を説明でき、責任を人間側へ戻せることである。2026 年上半期の Devin は、企業の作業力として売られ始めたことで、AI エージェントが個人の補助道具から、組織の工程設計に関わる存在へ移りつつあることを示した。
4. Devin Review は、生成された差分を人間が判断できる形へ戻した
1 月 21 日の Devin Review は、2026 年上半期の最初の大きな転換点だった。Cognition は、コード生成が容易になるほどコードレビューが新しいボトルネックになるという問題意識のもとで、Devin Review を発表した。Devin Review は、複雑なプルリクエストを理解しやすくするために、関連する変更を論理的にまとめ、コピーや移動されたコードを検出し、バグやセキュリティ上の問題を見つけ、プルリクエスト上で質問できる仕組みとして示された[9]。プルリクエストとは、変更内容をレビュー対象として提示し、既存コードへ取り込むかどうかを判断するための単位である。したがって、Devin Review の意味は、コードを書いた後の承認工程に AI が入ってきたことにある。
この変化には、二段階の因果関係がある。第一に、AI が実装速度を上げるほど、レビュー担当者の前に現れる差分は増える。差分が増えると、レビュー担当者は、何が変更され、どの変更が互いに関係し、どこに危険があるのかを短時間で読み解かなければならない。第二に、レビュー担当者が差分を理解できなければ、生成速度の向上は開発速度の向上に直結しない。コードは生成された時点で価値になるのではない。読まれ、検証され、必要な修正を受け、保守可能な変更として承認されて初めて、開発工程の成果になる。
Devin Review の価値は、レビューを人間から奪うことではなく、人間が判断するための材料を整えることにある。AI が作った差分は、量が増えるほど見通しが悪くなる。複数ファイルにまたがる変更、名前変更、関数移動、重複した処理、テスト変更、依存関係の更新が一つのプルリクエストに混ざると、レビュー担当者は、表示順に並んだ差分を自分の頭の中で意味のまとまりへ組み替えなければならない。Devin Review は、この組み替えを支援する。差分をそのまま要約するのではなく、変更の関係を見えやすくし、人間が判断しやすい単位へ戻すところに意味がある。
| 観点 | レビューで起きやすい詰まり | Devin Review が持つ意味 |
|---|---|---|
| 差分理解 | 変更がファイル順や行単位で並ぶため、意味としてまとまっている変更を人間が読み直す必要がある。 | 関連する変更を論理単位でまとめ、レビュー担当者が変更の意図と影響範囲を追いやすくする。 |
| コード移動 | 関数やクラスを移動しただけでも、表示上は削除と追加に見え、実質的なロジック変更と区別しにくい。 | コピーや移動されたコードを検出し、レビュー担当者が本当に読むべき変更へ注意を向けやすくする。 |
| 不具合検出 | 実装量が増えるほど、人間の注意だけでは境界条件、例外処理、セキュリティ上の問題を拾い切れなくなる。 | 潜在的なバグやセキュリティ問題を指摘し、人間が重点的に確認すべき場所を絞り込む。 |
| 文脈確認 | レビュー中に周辺コード、設計意図、既存仕様を調べるため、作業が頻繁に中断する。 | プルリクエスト上でコードベースに関する質問を行えるため、確認作業の往復を減らす。 |
差分理解は、単なる見た目の問題ではない。大きなプルリクエストでは、表示される順序と、意味として理解すべき順序が一致しないことがある。たとえば、ある変更が API の入力形式を変え、その影響でバリデーション、テスト、エラーメッセージ、ドキュメントが同時に変わったとする。ファイル単位で見ると変更箇所は散らばる。しかし意味としては、入力形式の変更を起点にした一つのまとまりである。レビュー担当者は、このまとまりを見抜かなければ、個々の差分を読めても、設計上の妥当性を判断できない。
ここで Devin Review が重要になる理由は、AI 生成コードが増えるほど、レビューの仕事が「読む量をこなすこと」から「変更の構造を判断すること」へ移るからである。人間はすべての行を同じ密度で読むことはできない。危険な変更、設計判断を含む変更、セキュリティやデータ整合性に関わる変更、既存の責務分担を崩す変更を優先して見なければならない。Devin Review は、この優先順位づけの材料を与える。これにより、レビュー担当者は、単純な読み取り作業に時間を奪われるのではなく、採用してよい差分かどうかという本来の判断へ集中しやすくなる。
| 段階 | AI 生成が増えたときに起きること | レビュー工程で必要になる対応 |
|---|---|---|
| 生成量の増加 | 実装、テスト、リファクタリング、修正案が短時間で多く作られる。 | 差分の量に比例してレビュー時間を増やすのではなく、確認すべき論点を整理する必要がある。 |
| 差分の複雑化 | 複数ファイル、複数責務、移動、コピー、生成されたテストが一つの変更に混ざる。 | 表示順ではなく、変更の意味、依存関係、影響範囲に沿って読む必要がある。 |
| 判断負荷の上昇 | コードが正しそうに見えても、設計意図、例外処理、保守性、セキュリティを別途確認する必要がある。 | 人間が最終判断を行うために、危険箇所、確認済み事項、未確認事項を見える形にする必要がある。 |
この構造から、AI 生成時代のレビュー支援の役割が見えてくる。レビュー支援とは、レビューを省略することではない。差分を人間が判断可能な形へ整えることである。Devin Review は、生成されたコードをそのまま開発工程に流し込むのではなく、変更の意味、危険箇所、確認すべき文脈を再構成する。ここに、Devin が実装だけでなくレビュー工程へ入り始めた意味がある。
一般化すると、AI がコードを増やす時代には、生成能力と同じくらい理解支援が重要になる。コードは、書かれた瞬間に価値になるのではない。読まれ、検証され、承認され、後から保守できる差分として受け入れられて初めて価値になる。Devin Review は、その受け入れ工程に AI が入り、人間の判断を支える形へ開発工程を組み替える動きである。
5. Auto-Fix によって、レビュー指摘やテスト失敗が Devin の次の作業入力になった
2 月 10 日の Auto-Fix は、Devin の進化を理解するうえで非常に重要である。Cognition は、Devin が Devin Review や他のレビュー支援ボットのコメント、lint や継続的インテグレーションの失敗、セキュリティスキャナーの指摘を受け取り、自動で修正する仕組みを「エージェントのループを閉じる」ものとして説明した[10]。lint とは、コードの書き方、形式、単純な品質違反を機械的に検査する仕組みである。継続的インテグレーションとは、変更が加わるたびにビルドやテストを自動で実行し、既存の動作を壊していないかを確かめる仕組みである。ここで重要なのは、これらの検査結果が、人間へ戻される通知にとどまらず、Devin が次に行う修正作業の入力になる点である。
この変化には、二段階の因果関係がある。第一に、AI が最初の実装差分を作れるようになると、次に問題になるのは、その差分がレビューやテストに通るかどうかである。コードは一度生成されただけでは完成しない。レビューコメント、テスト失敗、形式違反、セキュリティ指摘を受けて、何度も修正される。第二に、その修正のたびに人間がすべての指摘を読み、原因を調べ、手で直していると、AI が最初の差分を出した効果は途中で止まる。実装は速くなっても、レビュー後の修正が人間側に戻るため、開発工程全体の速度はレビューと再修正の部分で詰まる。Auto-Fix は、この戻りを変える。検出された失敗や指摘を Devin に渡し、Devin が原因を調べ、修正し、再び確認する流れを作る。
従来の流れでは、人間が実装し、人間がレビューし、人間が直す。AI を使う場合でも、AI が最初の差分を出したあとに、人間がレビュー指摘を読んで修正していれば、レビュー後の作業は人間側に戻る。Auto-Fix が変えたのは、この戻り先である。レビュー、継続的インテグレーション、lint、セキュリティスキャンの出力が、Devin の次の作業入力になる。つまり、検出系が人間の作業キューを増やすだけでなく、AI の修正作業を起動する信号になる。
| 入力 | 従来の位置づけ | Auto-Fix 後の位置づけ |
|---|---|---|
| レビューコメント | 人間が読み、実装者が修正するための指摘だった。 | Devin が問題の意図を読み取り、修正案を作るための作業入力になる。 |
| 継続的インテグレーションの失敗 | ビルド、テスト、依存関係の問題を人間へ通知する信号だった。 | Devin が失敗原因を調べ、修正し、再度確認するための検証信号になる。 |
| lint の失敗 | 形式、命名、単純な品質違反を人間に戻す仕組みだった。 | Devin が機械的に直せる違反を処理し、人間の注意を設計判断へ残しやすくする。 |
| セキュリティスキャン | 脆弱性や危険な書き方を警告する補助情報だった。 | Devin が修正候補を作り、プルリクエスト上で確認できる差分へ変える起点になる。 |
この構造は、ソフトウェア開発におけるフィードバックの意味を変える。テストやレビューは、失敗を知らせるだけのものではなく、エージェントに次の行動を与える制御信号になる。たとえば、テストが落ちた場合、従来は人間がログを読み、失敗箇所を探し、仮説を立て、修正し、再実行していた。Auto-Fix が入ると、失敗ログそのものが Devin に渡され、Devin は原因候補を調べ、修正を試み、再度検証する。人間は、その過程のすべてを手で実行するのではなく、Devin がどのような修正に到達したかを確認する立場へ移る。
ただし、この変化は、人間のレビューが不要になることを意味しない。レビュー指摘には、真の不具合、設計判断、命名や表現の好み、誤検出が混ざる。継続的インテグレーションの失敗にも、実装ミス、環境差分、テストの不安定さ、依存サービスの問題が含まれる。セキュリティスキャンの警告も、実際に危険なものと、文脈上は許容できるものに分かれる。Devin が修正を試みるとしても、その修正が設計意図に合っているか、不要な副作用を生んでいないか、警告の意味を正しく読んでいるかは、人間が最終的に判断しなければならない。
| 段階 | 工程で起きること | 人間の役割の変化 |
|---|---|---|
| 実装 | Devin がリポジトリを読み、変更差分を作る。 | 人間は、目的、変更範囲、完了条件を先に与える必要がある。 |
| 検出 | レビュー、lint、継続的インテグレーション、セキュリティスキャンが問題を示す。 | 人間は、どの検出結果を重視するか、どこに判断余地があるかを見極める必要がある。 |
| 修正 | Devin が検出結果をもとに原因を調べ、修正差分を作る。 | 人間は、すべての細部を手で直す役割から、修正方針と影響範囲を確認する役割へ移る。 |
| 再検証 | 修正後の差分が再びテストやレビューにかかる。 | 人間は、ループが問題を解消しているのか、別の問題を作っていないかを判断する。 |
このループが成立すると、人間の仕事は、すべての失敗を手で直すことから、ループが正しい方向へ収束しているかを確認することへ移る。これは単なる自動修正ではない。実装、検出、修正、再検証が連続した作業単位として扱われるようになる、という変化である。人間が毎回ログを読み、形式違反を直し、単純なテスト失敗を追う負担は下がる。一方で、人間には、Devin の修正が本当に妥当か、局所的な修正で設計を壊していないか、検出系の指摘に過剰適応していないかを見る責任が残る。
一般化すると、Auto-Fix が示したのは、AI エージェントにとって失敗は終点ではなく、次の入力になりうるということである。AI が最初から完璧な差分を出せるかどうかだけを見ると、開発工程の実態を見落とす。現実のソフトウェア開発では、最初の実装よりも、その後の指摘、修正、再確認の繰り返しが重要になる。Devin は、この繰り返しの中へ入り始めた。ここに、2026 年上半期の Devin が、実装代行から開発実行基盤へ進んだことを示す重要な根拠がある。
6. Devin 2.2 は、実装した結果を自分で確認する方向へ進んだ
2 月 24 日の Devin 2.2 は、見た目の更新や高速化としてだけ読むと重要性を見誤る。Cognition は Devin 2.2 について、起動速度が 3 倍になり、開発ライフサイクルをつなぐ新しい UI が導入され、Slack や Linear との連携が改善されたと説明している。同時に、Devin は Computer Use によって自分の作業をテストし、自己検証し、コードを自動修正できる方向へ進んだとされる[11]。ここで重要なのは、Devin が単にコードを生成するだけでなく、作った変更を実行環境の中で確かめ、人間が後から確認できる材料を返す方向へ進んだことである。
この変化には、二段階の因果関係がある。第一に、AI が複数ファイルにまたがる変更やプルリクエストを作るようになると、実装したという報告だけでは信頼できない。ソフトウェア開発では、コードが存在することと、実際に期待通り動くことは別である。ビルドが通るか、テストが通るか、画面操作で期待した結果が出るか、既存機能を壊していないかを確認する必要がある。第二に、その確認を毎回人間が手元でやり直すなら、AI に実装を委任しても確認作業が人間側に残る。Devin が自分の仮想環境で実行し、操作し、確認結果を返せるようになると、人間はすべてを最初から再現するのではなく、Devin が何を試し、どこまで確認したのかを読む立場へ移れる。
Computer Use とは、ここでは Devin が自分の仮想環境上でアプリケーションを起動し、画面を見て、クリックし、入力し、結果を確認する能力を指す。この語を単に「画面操作ができる機能」と理解すると、意味が狭くなる。重要なのは、AI が作った変更を、実行可能な状態で観察し、その観察結果を人間が後で確認できる証拠に変える点である。Devin が「実装しました」と報告するだけなら、人間は改めて手元で環境を作り、アプリケーションを起動し、動作を確認しなければならない。Devin が画面操作、テスト結果、録画を返せるなら、人間は少なくとも一部の確認を非同期に受け取れる。
| 観点 | 実装だけの場合 | 自己検証が加わった場合 |
|---|---|---|
| 報告の内容 | 変更したファイル、実装内容、修正方針が中心になる。 | 変更内容に加えて、何を実行し、何を確認し、どの結果が得られたかが示される。 |
| 人間の確認負荷 | 人間が手元で環境を作り、アプリケーションを起動し、動作を確認する必要が残る。 | 人間は Devin の確認結果を読み、不足している確認や判断が必要な箇所に集中できる。 |
| 失敗時の扱い | 実装後の失敗は、人間がログや画面を見て原因を調べることになりやすい。 | Devin が失敗を観察し、原因候補を調べ、修正を試みる流れへ接続しやすくなる。 |
| レビュー材料 | レビュー担当者は差分だけを読み、実行結果は別途確認する必要がある。 | 差分、テスト結果、画面録画、確認手順を組み合わせてレビューできる。 |
この自己検証の重要性は、Cognition 自身の利用実態からも分かる。同社は、2026 年 2 月のある週に Devin が自社コードベースへ 659 件のプルリクエストをマージしたと述べている。2025 年の最高週が 154 件だったという比較も示されている[12]。この数字は同社発表であり、そのまますべての組織に一般化できるものではない。それでも、生成される差分が増えるほど、レビュー、テスト、検証の仕組みがなければ運用が破綻しやすくなることは読み取れる。差分の量が増えると、単に書く能力よりも、確認できる能力、失敗を見つける能力、修正を繰り返す能力が重要になる。
ここにも、二段階の構造がある。第一に、Devin のようなエージェントが多くのプルリクエストを作ると、開発組織には大量の変更が流れ込む。大量の変更は、実装速度を上げる一方で、確認しきれない変更を増やす危険も持つ。第二に、その危険を抑えるには、生成する側が検証の材料も同時に返さなければならない。テスト計画、実行結果、画面録画、失敗時の再試行、確認できなかった点の明示がなければ、人間は差分を読むだけでなく、実行確認まで抱え込むことになる。Devin 2.2 の自己検証は、この確認負荷を下げる方向の更新として位置づけられる。
| 確認材料 | 役割 | 人間が見るべき点 |
|---|---|---|
| テスト結果 | 変更後のコードが、既存の検査条件を満たしているかを示す。 | テストが十分な範囲を覆っているか、重要な条件が漏れていないかを確認する。 |
| 画面操作 | 実際の利用手順に近い形で、変更後の動作を確認する。 | 操作手順が本当に利用者の行動に近いか、表面的な確認に留まっていないかを見る。 |
| 録画 | Devin が何を見て、どのような結果を確認したのかを後から追えるようにする。 | 期待結果と実際の画面が一致しているか、見落とされた異常表示がないかを判断する。 |
| 再試行の履歴 | 失敗後にどの原因を疑い、どの修正を試したのかを示す。 | 修正が根本原因に向いているか、偶然通っただけになっていないかを確認する。 |
この段階で Devin は、コードを書くエージェントから、作業結果を検証可能な形で返すエージェントへ進んだ。ソフトウェア開発で信頼されるのは、主張ではなく再現可能な確認である。人間の開発者でも、「直しました」という報告だけでは足りない。どの条件で確認したのか、どのテストが通ったのか、どこに未確認の範囲が残るのかを示す必要がある。AI エージェントにも同じことが求められる。実装の自己申告ではなく、テスト計画、実行結果、画面録画、失敗時の再試行が重要になる。
一般化すると、Devin 2.2 が示したのは、AI エージェントの自律性は生成能力だけでは成立しないということである。自律的に作業するとは、人間の代わりに好きな判断をすることではない。与えられた目的に沿って作業し、失敗を観察し、確認結果を残し、人間が採用判断できる材料を返すことである。Devin が「書いた」だけでなく「動かして見せる」方向へ進んだことは、開発実行基盤としての条件を一つ満たし始めたことを意味する。
7. Managed Devins は、長い作業を巨大な文脈ではなく分割された作業単位で進める
3 月 19 日の Managed Devins は、Devin の作業単位を変える更新だった。Cognition は、Devin が大きなタスクを分解し、複数の子 Devin に委任できるようになったと説明している。各子 Devin は独立した仮想マシンを持ち、シェル、ブラウザ、開発環境を使い、テストや検証を行ったうえで親 Devin に報告する。親 Devin は、作業範囲の設定、割り当て、進捗監視、衝突解決、結果統合を担う[13]。ここで重要なのは、Devin が一つの長い作業を抱え続けるのではなく、作業を分け、それぞれの単位で調査と実装を進める構造を持ったことである。
この変化には、二段階の因果関係がある。第一に、大きな作業を一つのセッションに抱え込むと、文脈が膨らみ、焦点がぼやける。調査結果、途中の判断、失敗、修正、暫定方針、未確認事項が同じ文脈に積み重なると、最初に与えた目的や重要な制約が埋もれやすくなる。第二に、文脈が膨らむほど、AI は何を優先すべきかを見失いやすくなり、作業結果も確認しにくくなる。人間が後から読む場合にも、どの調査がどの判断につながり、どの変更がどの目的に対応しているのかを追いにくい。Managed Devins は、この問題を、文脈をさらに長くするのではなく、作業を小さく切ることで処理しようとする。
この機能の意味は、複数の AI が同時に動くこと自体にあるのではない。重要なのは、作業を分割し、分割された作業ごとに狭い目的を与え、結果を統合することである。たとえば、大規模な移行では、依存関係の調査、古い API の置換、テスト修正、ドキュメント更新、画面確認が同時に発生する。これらを一つの Devin が最初から最後まで抱えると、作業の見通しは悪くなる。各作業を子 Devin に分ければ、それぞれは限定された目的に集中できる。親 Devin は、全体方針、作業の割り当て、結果の衝突、最終的な統合を見ることができる。
| 観点 | 一つの長いセッションで進める場合 | Managed Devins で分割する場合 |
|---|---|---|
| 文脈 | 調査、失敗、修正、判断、未確認事項が一つの文脈に積み重なり、重要な条件が埋もれやすい。 | 子 Devin ごとに目的と作業範囲を絞るため、各作業の文脈を短く保ちやすい。 |
| 焦点 | 作業が長くなるほど、最初の目的と途中の細部が混ざり、何を優先するべきかが曖昧になりやすい。 | 各子 Devin が限定された課題に集中し、親 Devin が全体の優先順位と統合を管理する。 |
| 並列性 | 一つの作業列にすべてが並ぶため、独立して進められる調査や修正も順番待ちになりやすい。 | 依存関係の薄い作業を並列に進められるため、調査、修正、確認を同時に進めやすい。 |
| 確認 | 人間が後から読むと、どの変更がどの目的に対応するのかを追いにくい。 | 子 Devin ごとの報告を見れば、作業単位ごとの成果、未解決点、統合時の注意点を確認しやすい。 |
ここで重要になるのは、子 Devin が勝手に全体方針を決めることではない。親 Devin が作業を切り、それぞれの子 Devin に狭い目的を与え、結果を統合する。つまり、並列化は自由放任ではなく、管理された分業である。これは人間の開発組織にも似ている。大規模な移行、リファクタリング、画面確認、依存関係調査、テスト修正は、うまく切れば並列化できる。しかし、仕様判断、設計方針、統合判断を分散させすぎると、成果物は破綻する。作業者を増やすほど、全体方針、責任分界、衝突解決、統合判断が重要になる。
この点で、Managed Devins は、AI エージェント運用における作業設計の問題を前面に出している。AI に長い文脈を与えれば大きな作業を安定して処理できる、という理解には限界がある。文脈が長くなるほど、情報は多くなるが、判断の焦点は必ずしも明確にならない。むしろ、目的を分け、担当範囲を狭くし、結果を統合する仕組みの方が、作業の品質を保ちやすい。Managed Devins は、AI の能力を一つの巨大な知能として伸ばす方向ではなく、作業単位を設計し、分業を管理する方向へ進んだ更新として読める。
| 役割 | 担当すること | 分業上の意味 |
|---|---|---|
| 親 Devin | 作業範囲を設定し、子 Devin へ割り当て、進捗を見て、衝突を調整し、結果を統合する。 | 全体方針を保ち、分割された作業がばらばらの成果物にならないようにする。 |
| 子 Devin | 限定された目的に沿って、調査、実装、テスト、検証を行い、結果を親 Devin へ報告する。 | 狭い文脈に集中することで、各作業の品質と追跡可能性を保ちやすくする。 |
| 人間 | 最初の目的、制約、成功条件を与え、統合結果を読み、採用判断を行う。 | すべての細部を手で処理するのではなく、作業の切り方と最終判断に責任を持つ。 |
この観点は、4 月の複数エージェント論にも接続する。Cognition は、複数エージェントの実用形として、無秩序な群れではなく、書き込みを一つの制御線に保ちながら、追加のエージェントが知能を補う形が有効だと述べている[14]。Managed Devins も同じ方向にある。複数の作業者を増やすほど、管理、文脈共有、責任分界が重要になる。並列化は、作業者の数を増やすだけでは成立しない。誰が全体方針を持ち、誰が部分作業を進め、どの時点で結果を統合するのかを決めて初めて、分業として機能する。
一般化すると、Managed Devins が示したのは、AI エージェントの進化が巨大な文脈容量だけでは解けないということである。長い作業には、長い記憶よりも、よく切られた作業単位が必要になる。人間の仕事も同じである。大きな課題を一人が抱え続けるより、目的を分け、責任を分け、結果を統合する方が安定する。Devin は、この分業構造を AI エージェントの側へ持ち込んだ。ここに、実装代行から開発実行基盤へ進むうえでの重要な一歩がある。
8. Scheduled Devins と Auto-Triage によって、Devin は呼び出される道具からイベントに反応する作業者へ移った
3 月 20 日の Scheduled Devins は、Devin の時間的な使われ方を変える更新だった。Cognition は、Devin が自分自身の定期セッションをスケジュールでき、前回の状態を保ちながら次回の作業を続けられると説明している[15]。公式リリースノート上でも、2 月からスケジュール作成、即時実行、一回限りのスケジュールなどが段階的に追加されている[6]。ここで重要なのは、Devin が人間に呼び出された瞬間だけ動く存在ではなく、時間や外部イベントをきっかけに作業を始める存在へ近づいたことである。
この変化には、二段階の因果関係がある。第一に、開発組織には、緊急ではないが繰り返し発生する作業が多い。リリースノートの作成、機能切り替えフラグの整理、依存関係の更新、日次の品質確認、ドキュメント点検、古いチケットの確認は、どれも重要ではあるが、目の前の開発や障害対応に押されて後回しになりやすい。第二に、こうした作業を毎回人間が思い出し、AI に依頼し、前回の状態を説明し直すなら、作業開始そのものが摩擦になる。Scheduled Devins は、その摩擦を下げる。あらかじめ目的、頻度、手順、参照すべき情報を与えておけば、Devin は定期的に作業を起動し、前回の状態を踏まえて続きを進められる。
定期実行という言葉だけを見ると、従来の cron のような仕組みに見えるかもしれない。cron は、決められた時刻に決められた処理を実行するための古典的な仕組みである。しかし、Devin の定期実行は、単に時刻になったら同じコマンドを走らせるものとは性質が違う。Devin は、自然言語の指示、プレイブック、過去の状態、コードベース、外部ツール、前回の結果を使いながら、繰り返し発生する開発作業を進める。つまり、定期実行の対象が固定された処理ではなく、状況を読みながら進める作業になる。
| 観点 | 従来の定期処理 | Scheduled Devins の意味 |
|---|---|---|
| 起動条件 | 決められた時刻や周期で、あらかじめ定義された処理を実行する。 | 時刻や周期をきっかけに、自然言語の指示やプレイブックに沿った開発作業を開始する。 |
| 作業内容 | 同じコマンドや同じ処理を繰り返すことが中心になる。 | 前回の結果、現在のコードベース、関連ツールの状態を見て、次に必要な作業を進める。 |
| 状態の扱い | 状態管理はスクリプトや外部の保存先に明示的に作り込む必要がある。 | Devin が前回の作業文脈を踏まえ、継続的な作業として扱える。 |
| 人間の負担 | 人間が処理内容を設計し、失敗時の調査や次回への引き継ぎを別途管理する。 | 人間は目的、確認条件、報告形式を定め、Devin の作業結果を確認する役割に寄る。 |
この構造が有効になるのは、開発組織に「急ぎではないが、放置すると負債になる作業」が多いからである。機能切り替えフラグは、実験や段階的リリースのために一時的に導入されることが多いが、役割を終えた後も残り続けると、コードの分岐を増やし、テストの見通しを悪くする。依存関係の更新も同じである。すぐに動かなくなるわけではなくても、放置すれば脆弱性、互換性問題、移行コストとして戻ってくる。Scheduled Devins は、このような作業を、思い出したときに処理するものから、定期的に拾い上げる作業へ変える。
この流れは、5 月 18 日の Auto-Triage でさらに明確になる。Auto-Triage では、Devin がバグ、アラート、インシデント、依頼を監視し、発生直後に調査を始め、コードベース、監視ツール、関連チケット、スレッドを確認し、必要なら 子 Devin を並列に起動し、原因や次の手順を返し、明確な修正があればプルリクエストを開くと説明されている[16]。ここで Devin は、ユーザーが明示的に依頼した瞬間だけ動く存在ではなく、開発組織の周辺システムで発生したイベントに反応して動く作業者になっている。
Auto-Triage の意味を理解するには、障害対応や不具合調査の初動を見る必要がある。障害通知が来たとき、人間はまず通知内容を読み、どのサービスで起きたのかを確認し、関連するログやメトリクスを探し、直近の変更を調べ、同じ問題が過去に起きていないかを探し、担当者や関連チケットを確認する。この段階では、まだ修正方針は決まっていない。むしろ、何が起きているのかを切り分けること自体が作業である。Auto-Triage は、この初動調査を Devin に移す方向の機能である。
| 入口 | 従来の初動 | Auto-Triage 後の位置づけ |
|---|---|---|
| アラート | 人間が通知を読み、監視画面を開き、影響範囲と緊急度を確認する。 | Devin が通知を起点に、関連するログ、メトリクス、直近の変更を調べる。 |
| バグ報告 | 人間が再現条件、関連コード、過去の類似事例を探す。 | Devin が報告内容を読み、コードベースや関連チケットを確認し、原因候補を整理する。 |
| インシデント | 人間が関係者を集め、状況を整理し、修正可能性を検討する。 | Devin が初期調査を進め、必要な情報、疑わしい変更、次の確認手順を提示する。 |
| 修正可能な問題 | 調査後に人間が修正方針を決め、実装者へ作業を渡す。 | Devin が明確な修正候補を作れる場合、プルリクエストとして提示する。 |
ここにも、二段階の因果関係がある。第一に、開発現場で時間を奪うのは、新規実装だけではない。障害通知を読み、関係するログを探し、最近の変更を追い、再現条件を調べ、担当者を探し、修正できるか判断する初動調査も重い。第二に、その初動が遅れると、修正そのものが簡単でも、問題の把握と関係者調整に時間を取られる。Auto-Triage は、発生したイベントを Devin の作業入口に変えることで、この初動の摩擦を下げる。人間は、最初からすべてを調べるのではなく、Devin が集めた材料を見て、原因仮説、影響範囲、修正方針を判断する立場へ移る。
この変化は、AI 利用の形を会話から運用へ移す。チャットで頼む AI は、呼び出されたときに動く。イベントに反応する AI は、Slack、Linear、GitHub、Datadog、Sentry、Webhook などの周辺システムを入口にして動く。ここで重要なのは、AI が会話画面の中だけにいるのではなく、開発組織の通知、課題、監視、レビューの流れに入ることである。入口が会話からイベントへ広がると、AI は「質問に答えるもの」から「発生した作業を拾うもの」へ変わる。
| 使われ方 | 起点 | 開発組織での意味 |
|---|---|---|
| 対話型利用 | 人間がチャットや入力欄から明示的に依頼する。 | 人間が問題を認識し、作業化した後に AI が支援する。 |
| 定期実行 | 予定された時刻や周期に従って Devin が作業を開始する。 | 後回しになりやすい保守作業や点検作業を、継続的に拾い上げる。 |
| イベント反応 | アラート、チケット、プルリクエスト、チャット、Webhook などの外部イベントをきっかけにする。 | 人間が作業化する前の初動調査や整理を、Devin が先に進める。 |
一般化すると、Scheduled Devins と Auto-Triage が示したのは、AI エージェントの価値が、会話中の応答能力だけでは測れないということである。開発組織では、作業は人間の依頼だけから生まれるわけではない。時刻、リリース周期、アラート、チケット、レビュー、監視指標、顧客報告からも作業は発生する。Devin がそれらを入口にして動けるようになると、AI は呼び出される道具から、開発組織の中でイベントに反応する作業者へ移る。この変化は、Devin が開発実行基盤へ近づいたことを示す重要な段階である。
9. ローカルで考え、クラウドへ任せる分業が明確になった
4 月 15 日の Devin in Windsurf は、Devin の作業配置を理解するうえで重要である。Cognition は、ローカルエージェントとクラウドエージェントは同じものではないと説明した。ローカルエージェントは手元の環境で動き、人間の注意がある間に計画、試作、反復を助ける。一方、Devin はクラウドエージェントとして、独自の環境で動き、人間が見ていない時間にも実装、テスト、品質確認、プルリクエスト作成を進める[17]。この整理は、Devin を単なる高性能なコード生成 AI として見るのではなく、人間の作業場とは別の場所で働く作業主体として見るための前提になる。
この違いには、二段階の因果関係がある。第一に、開発作業には、人間が画面を見ながら判断した方がよい作業と、目的が明確なら人間が離れている間に進められる作業がある。設計の迷いを解く、差分を細かく見ながら方針を変える、短い試作を繰り返す、といった作業では、人間の注意が近くにある方がよい。第二に、依存関係の更新、テスト追加、既知の不具合修正、調査、移行作業、品質確認のように、目的と完了条件を切り出せる作業では、クラウド側に委任する意味が大きい。人間が常に画面を見ていなくても、Devin が独立した環境で作業を進め、結果をプルリクエストや報告として返せるからである。
この整理は、既稿「Devin と Claude Code の違いは、作業の任せ方にある」と強く接続する。Devin は、作業を独立した場所へ委任する型であり、Claude Code のような手元の対話型エージェントとは使いどころが異なる[1]。違いは、どちらが賢いかだけではない。人間が常に画面を見ながら判断したい場面と、人間が不在でも進めてよい作業を任せたい場面は違う。前者にはローカルエージェントが向き、後者にはクラウドエージェントが向く。この違いを見落とすと、AI 開発支援をすべて同じ道具として扱ってしまい、どの作業をどこへ置くべきかが見えなくなる。
| 観点 | ローカルエージェントが向く作業 | クラウドエージェントが向く作業 |
|---|---|---|
| 人間の注意 | 人間が画面を見ながら、方針を変えたり、差分を確認したりする作業に向く。 | 人間が離れている間にも、明確な目的に沿って進められる作業に向く。 |
| 作業の性質 | 設計相談、短い試作、局所修正、細かな反復のように、対話しながら進める作業に向く。 | 調査、実装、テスト、移行、品質確認、プルリクエスト作成のように、まとまった成果へ進める作業に向く。 |
| 成果の受け取り方 | 人間がその場で差分を見て、必要に応じてすぐ修正方針を変える。 | Devin が作業結果を報告し、人間が後からプルリクエスト、テスト結果、調査内容を確認する。 |
| リスク | 人間が近くにいるため方針修正はしやすいが、作業は人間の注意時間に依存しやすい。 | 非同期に作業を進められるが、目的、制約、完了条件が弱いと、期待と異なる成果になりやすい。 |
4 月 27 日の Devin CLI は、この分業をターミナル側へ広げた。CLI は、ローカルで始めた作業を必要に応じてクラウド側へ渡す導線として発表された[18]。これは、ローカルとクラウドを完全に分けるというより、作業の段階に応じて移せるようにする考え方である。最初は手元で調べ、方針を固め、途中からまとまった実装や検証をクラウド側へ任せる。この流れが成立すると、開発者はすべての作業を自分の端末上で抱え続ける必要がなくなる。一方で、クラウドへ渡すためには、何を任せるのか、どこまでが完了なのか、どの結果を返すべきなのかを明確にする必要がある。
4 月 23 日のクラウドエージェント論では、クラウドエージェントを安全かつ自律的に動かす技術基盤と、組織内で生産的に使うための変革管理の両方が必要だと説明されている[19]。クラウド上で動くこと自体は出発点にすぎない。クラウドエージェントが開発組織の作業者になるには、安全な実行環境、適切な権限、作業文脈、通知、レビュー、運用手順が必要になる。ここでも、Devin の価値はモデルの能力だけでは決まらない。どの環境で動き、どの情報を読み、どの操作を許され、どの成果物を人間へ返すかによって、実務上の価値が決まる。
| 段階 | 作業の置き場所 | 分業上の意味 |
|---|---|---|
| 構想 | 人間の手元で、要件、制約、既存コード、修正方針を確認する。 | 人間が判断すべき曖昧さを残したまま、クラウドへ丸投げしないための段階になる。 |
| 切り出し | クラウドへ任せられる単位として、調査、実装、テスト、確認条件を整理する。 | Devin が独立して進められる作業範囲を明確にし、期待外れの成果を減らす。 |
| 委任 | Devin がクラウド上の環境で、リポジトリを読み、実装し、検証し、報告する。 | 人間の注意時間から切り離して、まとまった作業を非同期に進められる。 |
| 回収 | 人間がプルリクエスト、テスト結果、調査報告、未確認事項を読む。 | 作業そのものではなく、成果物の妥当性、影響範囲、採用可否を判断する段階になる。 |
6 月 2 日の Devin Desktop は、この方向をさらに進めた。Cognition は Devin Desktop を次世代の Windsurf と位置づけ、Devin Cloud、Agent Command Center、IDE を一つの面で管理するものとして説明した。エンジニアの仕事は、ひとつのエージェントとペアプログラミングすることから、複数のエージェントを使って作業を計画し、委任し、進捗を見て、本番へ入れるものを判断する方向へ変わると述べている[20]。この変化は、開発者が AI と一対一で対話する段階から、複数の作業者としての AI を管理する段階へ移りつつあることを示す。
ここにも、二段階の因果関係がある。第一に、AI エージェントが増えるほど、開発者は個々のコード生成だけでなく、どの作業をどのエージェントへ任せるかを考える必要が出てくる。第二に、任せる作業が増えるほど、成果物の進捗、衝突、品質、採用可否を管理する画面が必要になる。Devin Desktop や Agent Command Center は、この管理のための面として位置づけられる。AI が開発者の横に一つ置かれるだけなら、通常のエディタ統合で足りる。しかし、複数の AI がクラウド側で作業するなら、開発者には、それらの作業を見渡し、止め、修正し、採用するための操作面が必要になる。
| 構成要素 | 役割 | 開発者の仕事の変化 |
|---|---|---|
| IDE | 人間がコードを読み、差分を確認し、設計判断を行う手元の作業場になる。 | 実装のすべてを手で行う場所から、判断と確認を行う場所としての意味が強くなる。 |
| Devin Cloud | 独立した環境で、調査、実装、テスト、プルリクエスト作成を進める。 | 人間が見ていない時間にも、切り出された作業を前へ進める作業場になる。 |
| Agent Command Center | 複数のエージェントの作業、進捗、成果物を管理する面になる。 | 開発者は、AI と一つずつ会話するだけでなく、複数の作業を計画し、委任し、回収する役割を持つ。 |
一般化すると、2026 年上半期の Devin は、AI 開発支援の配置を「手元の補助」から「手元とクラウドの分業」へ進めた。ローカルエージェントは、人間が考えながら差分を作る場で強い。クラウドエージェントは、人間が不在でも進められる作業を受け取り、実装、検証、報告まで進める場で強い。重要なのは、どちらか一方が優れているという話ではない。作業の種類によって、置くべき場所が違うということである。Devin の進化は、この作業配置の違いを製品構造として明確にした。
10. Devin は Android と Windows に広がり、既存の企業システムへ近づいた
5 月 13 日の Android Emulator 対応は、Devin の対象環境を広げる更新だった。Cognition は、Devin が Android Virtual Device を起動し、Android アプリケーションを自分の環境でビルドし、実行し、挙動を確認し、問題を再現し、変更を検証できるようになったと説明している[21]。Android Virtual Device は、Android 端末の動作を開発環境上で再現するための仮想端末である。ここで重要なのは、Devin が Android のコードを読むだけでなく、アプリケーションが実際に動く環境で変更結果を確認できるようになったことである。コードを理解することと、端末上の動作を確認することは違う。画面遷移、入力、権限、通信、端末固有の挙動は、実行して初めて見える問題を含む。
この変化には、二段階の因果関係がある。第一に、AI エージェントが対象にできる開発作業は、読み取れるコードだけでは決まらない。実行環境がなければ、ビルドできるか、画面が崩れていないか、変更後の操作が期待通り進むかを確認できない。第二に、実行環境が増えるほど、AI が扱える作業は、静的なコード変更から、実際の利用場面に近い検証へ広がる。Android Emulator 対応は、Devin がモバイルアプリの変更を、コード差分としてだけでなく、動作確認を伴う作業として扱うための条件を整えた。
5 月 21 日の Windows PC も同じ方向にある。Cognition は、Devin が Windows VM 上でネイティブにビルド、実行、テストできるようになったと発表した。例として、.NET Framework アプリケーションの新機能追加や .NET Core への移行、Windows アプリケーションの画面確認、SQL Server や Windows サービスのような Windows 固有の作業が挙げられている[22]。企業のソフトウェア資産は、最新の Web アプリケーションだけではない。古い Windows アプリケーション、.NET Framework、Windows Forms、classic ASP、社内ツール、Windows Server 上の処理が残っている。Devin がそこへ入るには、実際の Windows 環境で動ける必要がある。
| 対象環境 | 従来の難しさ | Devin が対応する意味 |
|---|---|---|
| Android | コードを読めても、端末上の画面、入力、権限、実行時の挙動は確認しにくい。 | Android Virtual Device 上でビルド、実行、再現、検証を行い、モバイルアプリの変更を動作確認と結びつけられる。 |
| Windows | Windows 固有の実行環境、.NET Framework、Windows サービス、SQL Server 連携は、Linux 中心の環境では扱いにくい。 | Windows VM 上でネイティブにビルド、実行、テストできるため、企業に残る Windows 系資産へ作業範囲が広がる。 |
| 既存企業システム | 古い社内アプリケーション、移行途中の基盤、独自運用の仕組みは、きれいな新規開発だけでは説明できない。 | Devin の対象が新規実装から、移行、保守、動作確認、既存資産の整理へ広がる。 |
ここで見えるのは、Devin の進化が新しいコードを書く方向だけではないということである。企業の開発現場には、新規の Web アプリケーションだけでなく、長年使われてきた業務アプリケーション、古いフレームワーク、端末依存の挙動、データベース、認証、監視、運用手順がある。AI エージェントが実務に入るには、きれいに整ったリポジトリだけを相手にするのでは足りない。既存資産が動いている環境に近づき、その環境で変更を試し、動作を確認できる必要がある。
企業導入の文脈では、4 月 27 日の Mercedes-Benz との提携発表も重要である。Cognition は、Mercedes-Benz が Devin と Windsurf をグローバルエンジニアリング組織へ展開し、レガシーモダナイゼーション、クラウドネイティブ開発、物流領域から始めると説明している[23]。レガシーモダナイゼーションとは、古いシステムを現在の運用や保守に耐える形へ移行、整理、更新する取り組みである。この語は、古いものを単に捨てるという意味ではない。動き続けている既存システムを読み、依存関係を理解し、壊してはいけない業務要件を保ちながら、少しずつ新しい構成へ移す作業を含む。
この領域では、AI エージェントの価値は、新機能を速く作ることだけでは測れない。第一に、既存システムの移行では、古いコードの意味を読み、使われている箇所を調べ、変更してよい範囲と変更してはいけない範囲を分ける必要がある。第二に、そのうえで、変換、テスト、差分確認、ドキュメント更新、段階的な置き換えを進めなければならない。ここで Devin が役立つ可能性があるのは、人間が敬遠しがちな調査、整理、置換、確認の反復を、明確な作業単位として委任できるからである。新規開発よりも、むしろ既存資産の保守と移行において、非同期に進む作業者の価値は大きくなる。
| 作業領域 | 企業システムでの特徴 | Devin に委任しやすい作業 |
|---|---|---|
| レガシーモダナイゼーション | 古いコード、古いフレームワーク、暗黙の業務仕様が残り、変更の影響範囲を読み解く必要がある。 | 依存関係調査、古い API の置換候補整理、テスト追加、移行差分の作成、影響範囲の報告を任せやすい。 |
| クラウドネイティブ開発 | アプリケーション、インフラ、監視、デプロイ手順が密接に結びつく。 | 設定差分の確認、テスト、ドキュメント更新、運用手順の整備、軽微な修正を任せやすい。 |
| 物流領域 | 業務フロー、外部連携、例外処理、既存システムとの接続が多く、単純な画面開発だけでは済まない。 | 関連コードの調査、既存仕様の整理、再現手順の確認、修正候補の作成を任せやすい。 |
さらに、5 月 27 日の資金調達発表では、Mercedes-Benz のレガシーモダナイゼーション事例について、8 か月規模の作業が 8 日に短縮されたという Cognition 側の発表値が示されている[24]。この数値は、Cognition の発表として慎重に読む必要がある。対象範囲、測定方法、人間側の準備作業、レビュー工程、再利用可能な前提がどこまで含まれるかによって、同じ数字でも意味は変わる。それでも、この事例が示す方向は重要である。Devin の売り込み先は、新規開発だけではなく、既存資産の移行、保守、調査、検証へ広がっている。
TechCrunch も同じ時期に、Cognition が 10 億ドル超を調達し、ポストマネー評価額 260 億ドルに達したと報じている[25]。資金調達額や評価額は、製品の技術能力そのものではない。高い評価額は、ある時点の市場期待を示す材料であり、実装品質や導入効果を直接証明するものではない。しかし、技術記事としては、外部環境を読む材料にはなる。市場は、独立系の AI コーディング企業に対して、単なる補完機能ではなく、企業向け開発基盤としての成長を期待していると見られる。
| 材料 | 読み取れること | 読み取りすぎてはいけないこと |
|---|---|---|
| Mercedes-Benz 事例 | Devin が新規開発だけでなく、既存資産の移行や保守に売り込まれていることが分かる。 | 同社発表値だけから、すべての企業で同じ期間短縮が起きるとは判断できない。 |
| 資金調達報道 | 市場が AI コーディング企業に大きな期待を置いていることが分かる。 | 評価額だけから、製品の技術的完成度や現場での費用対効果を証明することはできない。 |
| Android と Windows 対応 | Devin の作業対象が、Web 開発中心からモバイル、Windows、既存企業システムへ広がったことが分かる。 | 対応環境が増えたことだけで、すべての複雑な業務システムを安全に任せられるとは言えない。 |
一般化すると、2026 年上半期の Devin は、理想的な新規開発環境から、現実の企業システムへ近づいた。現実の企業システムには、古い Windows アプリケーション、Android アプリケーション、.NET Framework、SQL Server、物流システム、運用手順、既存コードの暗黙知が含まれる。Devin がそこへ進むには、コードを生成する能力だけでなく、実行環境、検証手段、移行作業の分割、企業側のレビュー体制が必要になる。Android、Windows、Mercedes-Benz の文脈は、Devin が新しいものを作る AI から、既存の企業資産を扱う AI へ広がり始めたことを示している。
11. 非同期に働く Devin は、作業結果の証拠を返せなければ価値を失う
5 月 29 日の「Verifying Agentic Development at Scale」は、2026 年上半期の Devin を理解するうえで欠かせない。Cognition は、Devin が自分の仮想環境で作業を検証すること、そして非同期に起動される Devin セッションが対話的に起動されるセッションを初めて上回ったことを述べている[26]。この変化は大きい。対話型の利用では、人間が画面を見ながら指示を修正し、途中で方針を変え、結果をその場で確認できる。非同期の利用では、人間が見ていない時間に Devin が作業を進めるため、人間が戻ってきたときに、何が行われ、どこまで確認され、どこに未確認の範囲が残っているのかを短時間で判断できなければならない。
この変化には、二段階の因果関係がある。第一に、Devin の利用が対話型から非同期型へ広がるほど、作業途中の判断を人間が逐次確認する機会は減る。人間が画面の前にいれば、途中の出力を見て、違和感があれば止め、追加条件を与え、方針を修正できる。しかし、非同期に任せる場合は、そうした逐次介入を前提にできない。第二に、逐次介入できない作業では、最終的な成果物だけでなく、作業過程と確認結果が重要になる。完成したコードだけが返ってきても、何を試したのか、どのテストが通ったのか、どの画面を確認したのか、どの条件が未確認なのかが分からなければ、人間は結局、最初から確認し直すことになる。
非同期開発の弱点は、作業が見えにくいことである。Devin が長時間働いたとしても、何を試し、何に失敗し、どの確認を通し、どの条件を満たしていないのかが分からなければ、人間側の確認負荷はあまり下がらない。むしろ、AI が大きな差分を作ったぶんだけ、後から読む量が増える危険もある。したがって、Devin が返すべきものは、完成したコードだけではない。テスト計画、実行結果、画面の記録、通った確認、失敗した確認、未確認事項、再現手順が必要になる。
| 観点 | 対話型の利用 | 非同期型の利用 |
|---|---|---|
| 人間の関与 | 人間が画面を見ながら、途中の出力に反応し、方針を修正できる。 | 人間が不在の間に Devin が作業を進めるため、後から確認できる記録が必要になる。 |
| 失敗の発見 | 人間が途中で違和感に気づき、その場で追加指示や修正を入れられる。 | Devin がどの失敗を観察し、どのように対処したのかを結果として残す必要がある。 |
| 成果物の確認 | 人間は作業の流れを見ているため、最終差分の意図を把握しやすい。 | 人間は作業過程を見ていないため、差分、テスト結果、画面記録、未確認事項を組み合わせて判断する。 |
| 価値の条件 | その場の対話によって、曖昧さを修正しながら価値を出せる。 | 人間が戻ったときに短時間で採用判断できる証拠を返せなければ、非同期化の価値が下がる。 |
Cognition は同記事で、Computer Use にはまだ難しさがあることも認めている。たとえば、画面上の一時的な通知を見逃す、実際の利用者操作ではなく JavaScript で状態を作ってしまう、といった失敗があり得る[26]。これは重要な指摘である。Computer Use は、画面を操作できるからといって、それだけで人間と同じ確認ができるわけではない。人間の利用者が実際にたどる手順と、AI が内部的に状態を作って確認する手順は違う。後者だけで動作確認を済ませると、画面遷移、入力制約、権限確認、一時的な表示、エラー時の挙動を見落とす可能性がある。
ここにも、二段階の構造がある。第一に、AI が自分で検証するようになると、検証したという報告自体を確認する必要が生じる。テストを実行した、画面を見た、操作を試したという報告だけでは足りない。どの手順で、どの期待結果を置き、どの画面やログを根拠に成功と判断したのかが必要になる。第二に、検証手順が曖昧なままだと、AI は表面的に成功している状態を作るだけで、実際の利用者にとって重要な問題を見逃す可能性がある。したがって、非同期に働く Devin には、作業の実行力だけでなく、検証の設計と記録が求められる。
| 確認材料 | 役割 | 不足すると起きる問題 |
|---|---|---|
| テスト計画 | 何を確認すべきか、どの条件を満たせばよいかを事前に明確にする。 | Devin が確認しやすい箇所だけを試し、重要な条件を見落とす可能性がある。 |
| 実行結果 | ビルド、単体テスト、統合テスト、画面確認の結果を人間が追えるようにする。 | 人間が結果を信頼できず、同じ確認を手元でやり直すことになる。 |
| 画面記録 | Devin が実際にどの画面を見て、どの操作を行い、何を成功と判断したかを示す。 | 報告だけでは、表示崩れ、一時的な通知、操作の不自然さを確認できない。 |
| 未確認事項 | Devin が確認できなかった条件や、判断を人間に戻すべき箇所を明示する。 | 確認済みの範囲と未確認の範囲が混ざり、採用判断を誤りやすくなる。 |
| 再現手順 | 人間が必要に応じて同じ結果を再確認できるようにする。 | 問題が再発したときに、Devin の確認結果を検証できなくなる。 |
自己検証は万能ではない。しかし、失敗モードを観察し、テスト計画、明示的な期待結果、決定的な設定スクリプト、録画、スクリーンショット、期待結果の機械的な確認へ落とし込むことで、AI の作業を人間がレビュー可能にできる。ここで重要なのは、Devin の検証結果をそのまま信じることではない。Devin が何を根拠に成功と判断したのかを、人間が短時間で点検できる形にすることである。検証可能性とは、AI の作業を盲信するための仕組みではなく、信頼してよい範囲と、追加で確認すべき範囲を分けるための仕組みである。
この章の一般化は、AI エージェントの自律性は検証可能性と一体だということである。人間が見ていない間に動くなら、戻ってきた人間が短時間で確認できる証拠を残す必要がある。非同期開発の価値は、作業が進むことだけではない。作業結果を信頼できる形で受け取れることにある。Devin が開発実行基盤へ近づくほど、重要になるのは、どれだけ多くのコードを書けるかだけではなく、どの確認を行い、どの証拠を残し、どの判断を人間へ戻せるかである。
12. 企業統制と MCP は、Devin をどの権限でどの情報へ接続するかを決める
2026 年上半期のリリースノートには、細かい企業向け機能が多数並んでいる。v3 API、RBAC、セッション帰属、企業単位の秘密情報、MCP サーバーの許可リスト、ACU の上限設定、監査ログ、GitHub や GitLab の権限、利用分析、PR Review API、組織やメンバー管理、日本語翻訳の整備などである[6]。これらは、Devin Review や Managed Devins のように目立つ機能ではない。しかし、企業導入では中核になる。AI エージェントが強力になるほど、単に何ができるかではなく、誰の権限で、どの情報へ触れ、どの操作を行い、どの費用上限の中で動くのかを管理しなければならない。
この変化には、二段階の因果関係がある。第一に、Devin が実装、レビュー、自動修正、運用トリアージへ広がるほど、アクセスする情報と実行できる操作が増える。リポジトリだけでなく、課題管理、チャット、監視、設計資料、秘密情報、継続的インテグレーション、外部 API へ接続する必要が出てくる。第二に、接続先と操作範囲が広がるほど、企業にとっては利便性と同時にリスクも増える。AI が多くの情報を読めるなら、誤って読んではいけない情報に触れる可能性がある。AI が多くの操作を実行できるなら、誤った変更、過剰な修正、費用増大、監査不能な行動が問題になる。したがって、企業向けの Devin では、能力を広げることと同時に、その能力を制御する層が必要になる。
MCP は Model Context Protocol の略で、ここでは Devin が外部ツールやデータソースへ接続するための仕組みとして理解すればよい。コードベースだけを見ても、現実の開発判断には足りない。障害調査には Datadog や Sentry のログが必要になる。プロダクト分析には PostHog や Amplitude の情報が関係する。設計確認には Figma が使われることがある。ドキュメント、チケット、データベース、監視、顧客報告も判断材料になる。MCP は、こうした周辺情報へ Devin が入っていく入口になる。
| 接続先 | 開発判断で必要になる理由 | Devin に接続する意味 |
|---|---|---|
| 監視情報 | 障害や性能劣化の原因を調べるには、ログ、メトリクス、アラートの文脈が必要になる。 | Devin がコード変更だけでなく、運用上の異常と関連する変更を結びつけて調査できる。 |
| 課題管理 | 修正対象の背景、優先度、過去の議論、担当者、関連チケットを確認する必要がある。 | Devin が作業の目的と制約を読み取り、単なるコード変更ではなく課題に沿った修正へ進みやすくなる。 |
| 設計資料 | 画面仕様、設計意図、業務要件はリポジトリ内のコードだけでは分からないことがある。 | Devin が仕様や設計の文脈を参照し、実装差分の妥当性を判断する材料を増やせる。 |
| プロダクト分析 | どの機能が使われ、どの画面で離脱し、どの導線に問題があるのかは利用データを見なければ分からない。 | Devin が実装課題を、利用実態や影響範囲と結びつけて調査できる。 |
| 社内文書 | 運用手順、障害対応履歴、移行計画、技術的な制約は文書として残っていることが多い。 | Devin が過去の判断や運用ルールを踏まえ、現場の手順から外れにくい作業を行える。 |
しかし、外部情報へ接続できることは、そのままリスクにもなる。監視ログ、顧客情報、設計資料、社内チケット、データベースには、機密情報や権限上の制限が含まれる。Devin がそれらを読めるなら、どの範囲で読めるのか、どのセッションで使えるのか、どの監査ログが残るのか、外部入力に含まれる悪意ある指示をどう扱うのかを決めなければならない。5 月の Auto-Triage でも、Slack メッセージ、アラート、ログ、Webhook などの入力は信頼できる命令として扱えないため、プロンプトインジェクションやデータ流出への保護が必要だと説明されている[16]。
ここにも、二段階の構造がある。第一に、Devin が外部イベントや外部文書を読むようになると、入力の種類が増える。チャットの発言、アラート本文、ログ、チケット、Webhook の内容、ドキュメントの記述が作業の文脈に入る。第二に、入力の種類が増えるほど、その中に含まれる指示をそのまま信じてよいかが問題になる。外部入力には、誤った情報、古い情報、権限外の情報、悪意ある命令、文脈を誤らせる記述が混ざる可能性がある。したがって、MCP による接続は、単なる情報取得の拡張ではなく、信頼境界の管理でもある。
| 統制対象 | 必要になる理由 | Devin 上半期更新との関係 |
|---|---|---|
| 権限 | AI エージェントがどのリポジトリ、組織、外部ツールへアクセスできるかを制限する必要がある。 | RBAC、リポジトリ権限、GitLab ユーザー連携、企業管理機能が強化された。 |
| 秘密情報 | テストやデプロイに必要な認証情報を渡しつつ、過剰な共有を避ける必要がある。 | セッション単位、企業単位、MCP 単位の秘密情報管理が追加された。 |
| 費用 | 非同期セッションや並列 Devin が増えると、利用量が急増しやすい。 | ACU 表示、上限設定、消費分析、利用ランキング、利用状況分析が整備された。 |
| 監査 | 誰が、いつ、どの設定を変え、どの外部接続を使ったかを追跡できなければならない。 | 監査ログ、MCP 管理、企業設定、利用分析が強化された。 |
| 外部接続 | コードだけでは判断できないため、監視、設計、チケット、データ分析と接続する必要がある。 | MCP Marketplace が拡張され、Datadog、Figma、Axiom、PostHog、Google Drive などの接続が増えた。 |
ACU は Devin の利用量を測る単位であり、企業導入では費用管理の観点から重要になる。Devin が対話的に少数の作業を行うだけなら、費用は比較的把握しやすい。しかし、Managed Devins によって複数の Devin が並列に動き、Scheduled Devins によって定期実行が増え、Auto-Triage によって外部イベントから自動起動されるようになると、利用量は人間の意識の外で増えやすくなる。ここで費用上限、消費分析、利用者別の可視化がなければ、便利な自動化がそのまま予算上のリスクになる。
この費用管理も、単なる管理部門向けの機能ではない。開発者にとっても、費用は作業設計に関わる。調査をどこまで任せるか、複数 Devin を同時に動かすべきか、定期実行の頻度をどうするか、失敗時に何回まで再試行させるかは、技術判断であると同時に費用判断でもある。Devin が開発実行基盤へ近づくほど、作業の切り方、検証の深さ、並列化の範囲は、費用対効果と切り離せなくなる。
| 利用形態 | 費用が増えやすい理由 | 必要になる管理 |
|---|---|---|
| 並列実行 | 複数の Devin が同時に調査、実装、検証を行うため、短時間で利用量が増えやすい。 | 作業ごとの上限、並列数の判断、成果に対する費用の見直しが必要になる。 |
| 定期実行 | 人間が毎回意識しなくてもセッションが起動するため、不要になった作業が走り続ける可能性がある。 | スケジュールの棚卸し、実行頻度の調整、不要な自動化の停止が必要になる。 |
| 自動トリアージ | アラートやチケットが多い環境では、外部イベントに応じて調査セッションが増える可能性がある。 | 起動条件、対象アラート、重要度、通知先を設計し、無駄な調査を減らす必要がある。 |
| 自己検証 | テスト、画面確認、再試行を増やすほど、確認品質は上がるが利用量も増える。 | どの確認を必須にし、どこから先を人間の判断に戻すかを決める必要がある。 |
この構造から見えるのは、企業向け AI エージェントの成熟とは、自由に何でもできる方向ではないということである。むしろ、何ができ、何ができず、どの権限で、どの費用上限で、どの監査可能性のもとで動くかを細かく制御できる方向で成熟する。強い AI を入れるほど、制限が不要になるわけではない。強い AI を入れるほど、制限、記録、承認、費用管理が必要になる。Devin の上半期の細かな更新は、そのための基礎工事として読める。
一般化すると、Devin の企業統制と MCP の拡張は、AI エージェントの実用化が技術能力だけでなく、信頼境界の設計であることを示している。AI が多くの情報へ接続できるほど、判断材料は増える。しかし、情報が増えるほど、権限、機密性、入力の信頼性、費用、監査の問題も増える。企業で AI エージェントを使うとは、賢いモデルに自由を与えることではない。適切な情報へ、適切な権限で、追跡可能な形で接続し、人間が責任を持って採用判断できる構造を作ることである。
13. Devin の価値は、利用量ではなく開発成果と費用対効果で測られる
6 月になると、Devin の進化は評価と費用対効果へ移る。6 月 4 日の Productivity Estimator は、完了した Devin セッションを見て、その作業が人間のエンジニアであれば何時間分に相当するかを推定する仕組みとして説明された。Cognition は、126 人のユーザー、258 セッションを含むデータセットで検証し、集計値の推定に使える程度の相関を得たと述べている[27]。同日には、企業顧客向けに、Devin が支払額に見合うエンジニアリング価値を出せなければ Cognition が最大 1000 万ドルまで利用分を負担するという Productivity Guarantee も発表された[28]。ここで重要なのは、Devin の価値が、使った計算量や生成したコード量ではなく、開発組織にどれだけ有効な成果を返したかで測られ始めたことである。
この変化には、二段階の因果関係がある。第一に、AI エージェントが開発工程へ深く入るほど、単純な利用量は価値を表しにくくなる。長い時間動いた、たくさんのトークンを使った、多くの行を変更した、という事実だけでは、その作業が有用だったかは分からない。第二に、企業導入では、AI の作業が人間の時間を本当に空けたのか、レビュー負荷を増やしていないか、品質を落としていないか、費用に見合っているかが問われる。つまり、評価軸は「どれだけ使ったか」から「どれだけ意味のある開発成果になったか」へ移る。
AI の利用量と価値は同じではない。トークンを多く使ったから価値が高いわけではない。行数が多いから価値が高いわけでもない。機械的なリファクタリングでは行数が増えるが、判断の難度は低いかもしれない。逆に、数行の修正が数時間の調査を置き換えることもある。バグトリアージ、コードレビュー、ログ調査、分析クエリ、依存関係整理のように、コード量では測れない作業も多い。Devin の価値を考えるには、生成物の量ではなく、人間が担っていたどの作業が、どの程度、確認可能な形で前に進んだのかを見る必要がある。
| 指標 | 測れること | 測れないこと |
|---|---|---|
| トークン数 | Devin が処理した入出力の規模を示す。 | その作業が有用だったか、設計判断に貢献したか、人間の時間を空けたかは分からない。 |
| 変更行数 | コード差分の大きさを示す。 | 差分の品質、保守性、影響範囲、調査の難度は分からない。 |
| セッション数 | Devin が何回作業したかを示す。 | 各セッションが完了したのか、未解決のまま終わったのか、レビュー負荷を増やしたのかは分からない。 |
| プルリクエスト数 | Devin が成果物として提示した変更の数を示す。 | そのプルリクエストが採用されたか、どれだけ修正が必要だったか、長期的な負債を増やしていないかは分からない。 |
| 人間相当時間 | 人間が行えばどの程度の時間がかかったかを見積もる材料になる。 | その時間が本当に節約されたか、品質や責任判断を含めて妥当だったかは別途確認が必要になる。 |
この問題は、既稿「測ることは、考えることの代わりにならない」とも接続する。測定は重要だが、測定値を判断そのものに置き換えると、何を測っているのかを見失う[29]。Productivity Estimator は、AI の価値を見積もる試みとして重要である。ただし、それは最終判断ではなく、経営判断や開発運用の材料である。どの作業を AI に任せると本当に人間の時間が空くのか、どの作業ではレビュー負荷が増えるのか、どの作業では品質リスクが高まるのかを、人間が引き続き見なければならない。
ここにも、二段階の構造がある。第一に、価値を測ろうとすると、測定可能なものに注目が集まりやすい。セッション数、差分行数、プルリクエスト数、処理時間、推定工数は、数値として扱いやすい。第二に、数値として扱いやすいものほど、開発の本質的な価値を取り逃がすことがある。たとえば、難しい設計判断を避けたまま大量の差分を作れば、数値上は大きな作業に見える。しかし実際には、レビュー担当者が後から大きな判断負荷を背負うだけかもしれない。逆に、短い調査報告が、誤った実装方針を止めることもある。したがって、Devin の価値測定では、量の指標と判断の質を分けて考える必要がある。
| 評価対象 | 見るべきこと | 判断上の注意点 |
|---|---|---|
| 調査 | 関連コード、ログ、チケット、過去の変更をどこまで確認し、原因仮説をどれだけ絞れたかを見る。 | 調査量が多くても、結論が曖昧で次の行動につながらなければ価値は限定される。 |
| 実装 | 目的に沿った差分になっているか、既存設計と整合しているか、不要な変更を含んでいないかを見る。 | 変更行数が多いほど価値が高いわけではなく、小さく安全な差分の方が有用な場合がある。 |
| 検証 | どのテストを実行し、どの画面を確認し、どの条件が未確認なのかを見る。 | テストが通ったという事実だけでなく、テスト範囲が目的に合っているかを確認する必要がある。 |
| レビュー負荷 | Devin の成果物が人間の確認を楽にしたのか、逆に読み直しや手戻りを増やしたのかを見る。 | AI の作業時間が短くても、人間のレビュー時間が増えていれば、組織全体の価値は下がる可能性がある。 |
| 保守性 | 後から読める差分になっているか、責務分担を壊していないか、将来の変更を難しくしていないかを見る。 | 短期的に動く修正でも、長期的な負債を増やすなら価値を割り引く必要がある。 |
6 月 8 日の FrontierCode も、評価軸の変化を示している。Cognition は、従来のコーディングベンチマークはモデルが正しいコードを書けるかを示してきたが、実務では「良いコードを書けるか」が問われると説明し、実際のオープンソース保守者による品質評価を重視する FrontierCode を発表した[30]。これは、正解率だけではなく、保守性、設計妥当性、統合可能性、レビュー可能性を評価へ入れる方向である。実務のコードは、テストに通れば終わりではない。既存設計に自然に入り、他の開発者が読めて、将来の変更を難しくせず、保守者が受け入れられる形になっている必要がある。
FrontierCode が重要なのは、AI エージェントの評価を、問題集の正解率から開発共同体の受け入れ可能性へ近づけようとしている点である。競技的なベンチマークでは、入力と期待出力が比較的明確に定義される。しかし実務では、同じ不具合を直すにも、最小差分で直すのか、設計を整理するのか、既存の慣習を守るのか、将来の拡張に備えるのかで評価が変わる。保守者が見るのは、コードが動くかだけではない。差分が妥当な大きさか、既存の方針に従っているか、レビューしやすいか、長期的に維持できるかである。
| 評価軸 | 従来のベンチマークで見えやすいこと | 実務で追加して見るべきこと |
|---|---|---|
| 正しさ | 与えられたテストや期待結果を満たしているかを確認しやすい。 | 未テストの条件、例外処理、実際の利用文脈でも妥当かを確認する必要がある。 |
| 品質 | 局所的なコードの動作や形式は評価しやすい。 | 責務分担、読みやすさ、保守性、既存設計との整合性を確認する必要がある。 |
| 統合可能性 | 単体の問題として解けたかは判断しやすい。 | 既存コードベースへ自然に入り、他の変更と衝突せず、レビュー可能な差分かを見る必要がある。 |
| 採用可能性 | 出力が正解に近いかは測りやすい。 | 保守者やレビュー担当者が、実際に取り込める品質と説明を備えているかを見なければならない。 |
このように、6 月の発表群は、Devin の評価軸が単なる生成量から、品質、採用可能性、費用対効果へ移ったことを示している。さらに 6 月末には、この費用対効果の問題が、複数モデルをどう使い分けるかという Devin Fusion の話へ進む。
一般化すると、Devin の価値測定は、AI エージェントが開発組織の中で本当に役に立っているかを問う段階に入ったことを示している。初期の問いは、AI がコードを書けるかだった。次の問いは、AI がレビュー、修正、検証まで進められるかだった。6 月の発表群が示した問いは、AI が生み出した成果をどのように測り、どの費用で維持し、どの品質で採用できるかである。トークン数、行数、セッション数は材料にはなるが、価値そのものではない。最終的に問われるのは、人間の判断を支え、開発組織の滞留を減らし、保守可能な成果物を、説明可能な費用で返せるかである。
14. Devin Fusion は、作業に応じてモデルを使い分ける段階を示した
6 月 29 日の Devin Fusion は、2026 年上半期の締めくくりとして重要である。Cognition は Devin Fusion を、複数のモデルを組み合わせて Devin を動かす仕組みとして説明し、FrontierCode 上で最先端水準のコーディング能力を保ちながら、平均コストを 35% 下げたと発表した[31]。この数値は Cognition 側の発表として慎重に読む必要がある。しかし、方向性は明確である。AI エージェントの費用対効果は、常に最も高価で強力なモデルを使い続けることでは解けない。作業の性質に応じて、どの判断を強いモデルに任せ、どの処理を補助的なモデルへ渡すかが問題になる。
この変化には、二段階の因果関係がある。第一に、Devin の利用範囲が広がるほど、処理する作業の種類は増える。設計判断、調査、検索、テスト実行、機械的な置換、エラー原因の追跡、レビュー指摘への対応、報告文の整理は、同じ「開発作業」と呼ばれても、必要な判断の深さが違う。第二に、必要な判断の深さが違うにもかかわらず、すべてを同じ高価なモデルで処理すると、費用が過大になる。一方で、判断が必要な作業まで安価な補助モデルへ寄せすぎると、品質が落ち、レビュー負荷や手戻りが増える。したがって、Devin Fusion の要点は、モデルを節約することではなく、作業ごとに必要な判断能力を見極め、費用と品質の均衡を取ることにある。
Devin Fusion の中心にあるのは、主エージェントと補助エージェントの分業である。主エージェントは、重要な判断、計画、曖昧さの解釈、最終確認を担う。補助エージェントは、機械的な調査、テスト実行、広い検索、比較的判断の少ない作業を引き受ける。ここでの教訓は、人間組織の分業にも似ている。すべての作業を最上級の判断者が行うと高すぎる。だからといって、判断が必要な仕事まで経験の浅い作業者へ渡すと品質が落ちる。重要なのは、どの作業が手順化でき、どの作業が判断そのものなのかを分けることである。
| 作業の種類 | 主エージェントが担う意味 | 補助エージェントが担いやすい意味 |
|---|---|---|
| 計画 | 目的、制約、作業範囲、成功条件を整理し、全体の進め方を決める。 | 既存情報の収集や関連ファイルの洗い出しを補助できる。 |
| 調査 | 調査結果の意味を解釈し、どの仮説を採用するかを判断する。 | コード検索、ログ確認、類似箇所の抽出、関連資料の列挙を担当しやすい。 |
| 実装 | 設計意図、責務分担、既存構造との整合性を判断する。 | 機械的な置換、型や形式の修正、反復的な変更を担当しやすい。 |
| 検証 | どの確認結果を信頼できるか、どの未確認事項を人間へ戻すかを判断する。 | テスト実行、再試行、ログ収集、画面確認の補助を担当しやすい。 |
| 報告 | 作業結果、判断理由、リスク、未確認事項を統合して説明する。 | 実行結果や調査メモを整理し、報告材料を作ることに向く。 |
Cognition は、Fusion の例として、テスト実行や機械的な置換では大きな費用削減が得られた一方、微妙な意図や判断が成果物そのものになるタスクでは、委任が逆効果になった例も示している[31]。これは、AI エージェント運用にとって重要な観察である。すべてを小さなモデルや補助エージェントへ流せばよいわけではない。作業の中に含まれる判断の種類を見抜かなければならない。テストの再実行や単純な置換は、手順化しやすい。設計意図の読み取り、曖昧な要求の解釈、既存構造に対する責務判断は、手順だけでは処理しにくい。
ここにも、二段階の構造がある。第一に、作業を補助エージェントへ委任すると、主エージェントの負荷と費用は下がる。調査や反復処理を安価な経路へ逃がせるため、全体の処理効率は上がりやすい。第二に、委任した作業に判断が多く含まれていると、補助エージェントの出力を主エージェントが再解釈し直す必要が生じる。すると、費用を下げるつもりが、確認、修正、統合の手間を増やすことになる。費用対効果は、安い処理を増やすだけでは改善しない。判断の所在を誤らないことが必要である。
| 委任の判断 | うまく機能する場合 | 失敗しやすい場合 |
|---|---|---|
| 機械的な作業 | 置換、検索、テスト実行、ログ収集のように、目的と手順が明確な作業では費用削減に結びつきやすい。 | 表面上は機械的に見えても、例外判断や設計意図の理解が必要な場合は手戻りが増えやすい。 |
| 調査 | 広い範囲から候補を集める作業では、補助エージェントを使うことで主エージェントの探索負荷を下げられる。 | 集めた情報の重要度を判断できなければ、主エージェントが後から整理し直す負担が増える。 |
| 設計判断 | 補助エージェントが材料を集め、主エージェントが最終判断を行う形なら分業しやすい。 | 設計方針そのものを補助エージェントへ渡すと、局所最適な変更や一貫性のない差分になりやすい。 |
| 最終確認 | 補助エージェントの結果を主エージェントが統合し、未確認事項を明示するなら採用判断に使いやすい。 | 補助エージェントの結果をそのまま確定扱いにすると、誤った前提や見落としが残りやすい。 |
この点は、6 月時点の Devin の進化を象徴している。最初の問いは、AI はコードを書けるかだった。次の問いは、AI はレビュー指摘を直せるか、自分でテストできるか、並列に動けるかになった。6 月末には、問いは、どのモデルを、どの作業へ、どの費用で使うべきかへ移っている。これは、AI ソフトウェアエンジニアが実験段階から運用段階へ入るときに避けられない問題である。実験段階では、最も強いモデルで成功例を作ることが重視される。運用段階では、継続的に使える費用、安定した品質、レビュー可能な成果物、失敗時の切り戻しが問題になる。
一般化すると、Devin Fusion が示したのは、AI エージェントの成熟が単一モデルの能力競争だけでは終わらないということである。開発組織で継続的に使うには、強い判断を必要とする作業、手順化できる作業、広く探索する作業、確認だけでよい作業を分ける必要がある。その分け方を誤ると、費用は下がっても品質が落ちるか、品質を守るために人間の確認負荷が増える。Devin Fusion は、AI エージェントの価値が、モデルの強さだけでなく、作業配分、費用配分、判断の配置によって決まる段階に入ったことを示している。
15. Devin を使うには、明確な作業範囲、十分な文脈、成功条件、人間のレビューが必要になる
Devin の進化を強調すると、すべての開発作業をそのまま Devin に渡せるように見えやすい。しかし、公式ドキュメントはより現実的である。Devin に向く作業は、成功条件が明確で、必要な文脈が与えられ、テスト、継続的インテグレーション、lint、コンパイル、レビューのような検証経路がある作業である。大きすぎる作業は、小さなセッションへ分割することが推奨されている[32]。これは、Devin の能力を低く見積もる話ではない。むしろ、Devin を開発工程の中で安定して使うには、何を任せるのか、どこまで任せるのか、何をもって完了とするのかを先に定める必要があるということである。
この条件には、二段階の因果関係がある。第一に、Devin は独立した環境で作業を進めるため、指示が曖昧だと、足りない前提を自分で補って作業を具体化する。人間が横で逐次確認する使い方であれば、途中で方向を修正できる。しかし、Devin に非同期で作業を渡す場合、最初の指示に含まれる目的、制約、変更範囲、参照すべき既存実装がそのまま作業の土台になる。第二に、土台が曖昧なまま作業が進むと、結果として出てきた差分が期待とずれても、どこでずれたのかを後から判定しにくくなる。したがって、Devin を使う前の作業設計は、便利な補足ではなく、成果物の品質を左右する前提条件になる。
効果的な指示には、詳細な文脈、段階的な作業、明確な成功条件、既存パターンへの参照が必要だと説明されている。曖昧な依頼では、Devin が設計判断を補い、期待とずれる可能性が高い。フィードバックの経路として、テスト、静的解析、ビルド確認、Devin Review、Auto-Fix を組み合わせることも推奨されている[33]。ここでいう文脈とは、単に背景情報を多く渡すことではない。Devin が作業中に迷わないように、既存設計、類似実装、守るべき制約、変更してはいけない領域、確認すべき条件を与えることである。
| 必要条件 | Devin に渡す前に決めること | 人間側に残る判断 |
|---|---|---|
| 作業範囲 | どの機能、どのファイル、どの不具合、どの移行範囲を対象にするかを決める。 | 作業を大きくしすぎず、Devin が独立して進められる単位へ切る。 |
| 成功条件 | テスト通過、画面確認、既存挙動維持、性能条件、セキュリティ条件を明示する。 | 何をもって完了と認めるか、どの未確認事項を許容しないかを定義する。 |
| 文脈 | 既存設計、類似実装、利用すべき資料、避けるべき方針を渡す。 | Devin が補ってよい文脈と、人間が明示的に決めるべき判断を分ける。 |
| 検証 | 継続的インテグレーション、lint、単体テスト、結合テスト、画面録画、レビュー指摘を確認経路にする。 | 検証結果を採用してよいか、例外を許すか、追加確認を求めるかを判断する。 |
| 採用責任 | Devin が作った差分を誰がレビューし、誰がマージし、誰が保守するかを決める。 | 成果物を組織のコードとして受け入れる責任を引き受ける。 |
ここで重要なのは、Devin への指示が細かければ細かいほどよい、という単純な話ではない。必要なのは、作業に関係する判断材料を過不足なく与えることである。大量の背景情報を渡しても、目的や完了条件が曖昧であれば、Devin は何を優先すべきかを判断しにくい。逆に、目的だけを短く伝えても、既存の設計方針や避けるべき変更が分からなければ、局所的には動くが全体として不適切な差分になる可能性がある。したがって、人間は、Devin に任せる前に、作業対象、制約、参照すべき実装、検証方法を整理する必要がある。
| 指示の状態 | Devin の作業で起きやすいこと | 改善の方向 |
|---|---|---|
| 目的が曖昧 | Devin が目的を推測し、期待と違う設計判断を含む差分を作る可能性がある。 | 何を達成したいのか、どの利用者や機能に影響するのかを明示する。 |
| 範囲が広すぎる | 調査、実装、テスト、修正が一つの作業に混ざり、結果の確認が難しくなる。 | 調査、実装、検証、ドキュメント更新などを分け、Devin が扱える大きさに切る。 |
| 文脈が不足している | 既存パターンを無視した実装や、不要な設計変更が入りやすい。 | 類似実装、設計資料、変更してはいけない箇所、守るべき慣習を渡す。 |
| 成功条件が弱い | Devin がどこまで確認すればよいか分からず、見かけ上の完了で止まりやすい。 | 通すべきテスト、確認する画面、維持すべき挙動、未確認なら報告すべき条件を決める。 |
| 採用責任が曖昧 | 誰が最終的にレビューし、どの基準で受け入れるのかが不明確になる。 | レビュー担当、承認手順、マージ条件、保守責任を明確にする。 |
Devin が強くなるほど、人間の役割が消えるのではなく、前段へ移る。人間は、すべてのコードを手で書く必要は減るかもしれない。しかし、何を作るか、何を変えないか、どの既存パターンに従うか、どのテストを通すか、どの失敗を許容しないかを明示しなければならない。AI に任せるとは、判断を捨てることではない。判断を先に構造化し、作業を検証可能な単位へ切ることである。
この点は、Devin の利用条件を考えるうえで決定的である。Devin は、曖昧な目的をそのまま正しい仕様へ変換する万能の設計者ではない。適切に切り出された作業を、与えられた文脈と検証経路に沿って前へ進めるエージェントである。したがって、Devin に向く作業とは、人間が判断を放棄した作業ではなく、人間が判断を整理し、目的と制約を明確にした作業である。
| 人間の役割 | Devin 導入前の意味 | Devin 導入後の意味 |
|---|---|---|
| 目的設定 | 人間が自分で実装しながら、必要に応じて目的を調整する。 | Devin に渡す前に、目的と完了条件を作業指示として明確にする。 |
| 作業分割 | 人間が作業中に自然に調査、実装、確認を行き来する。 | Devin が独立して進められる単位に、調査、実装、検証を切り分ける。 |
| 文脈付与 | 人間が自分の記憶や経験で既存設計を補いながら作業する。 | Devin が参照すべき既存実装、設計資料、避けるべき方針を明示する。 |
| 検証設計 | 人間が手元でテストや画面確認を行い、感覚的に十分性を判断する。 | Devin がどの確認を行い、何を証拠として返すべきかを事前に設計する。 |
| 採用判断 | 人間が自分の変更として責任を持ち、レビューやマージを行う。 | Devin の成果物を読み、品質、影響範囲、未確認事項を踏まえて採用可否を判断する。 |
一般化すると、Devin の進化は人間の不要化ではなく、人間の判断位置の移動として理解できる。手で書く量は減るかもしれない。しかし、目的設定、分割、文脈付与、検証設計、レビュー、採用責任は残る。むしろ、これらを曖昧にしたまま AI を使うと、開発速度は上がっても品質と責任が不安定になる。Devin が開発実行基盤へ近づくほど、人間側には、何を任せるかだけでなく、どの条件で任せ、どの証拠を返させ、どの判断を自分たちに残すかを設計する力が求められる。
16. Devin の半年は、開発工程のどこに AI を置くかを変えた
2026 年上半期の Devin は、コード生成器として少し便利になっただけではない。1 月の企業導入と Devin Review、2 月の Auto-Fix と Devin 2.2、3 月の Managed Devins と Scheduled Devins、4 月の Windsurf、CLI、企業統制、5 月の Android、Windows、Auto-Triage、6 月の Devin Desktop、Productivity Estimator、FrontierCode、Devin Fusion を通じて、Devin は開発工程の複数地点へ入っていった。実装だけでなく、レビュー、修正、検証、定期実行、初動調査、外部情報連携、費用管理、価値測定までが対象になった。この流れを見ると、Devin の半年は、AI がどれだけコードを書けるようになったかではなく、開発工程のどこに AI を置くかが変わった半年だったと整理できる。
この変化には、二段階の因果関係がある。第一に、Devin が独立したクラウド環境で作業できるようになると、人間の手元で完結していた作業の一部を外へ出せるようになる。調査、実装、テスト、プルリクエスト作成、レビュー指摘への対応、画面確認、初動トリアージは、人間が常に画面の前にいなくても進められる作業になりうる。第二に、作業を外へ出せるようになるほど、人間側には、何を任せるか、どの文脈を渡すか、どの権限を与えるか、何を成功条件にするか、どの証拠を返させるかを設計する責任が生じる。Devin が強くなるほど、人間の役割が消えるのではなく、作業前の設計と作業後の採用判断へ移る。
この半年の変化を一文で表すなら、Devin は実装を代行する単体エージェントから、開発作業を受け取り、分解し、実装し、検証し、レビュー指摘を直し、外部情報を調べ、費用を管理され、価値を測定されるクラウド型の開発実行基盤へ移った、ということである。ここで重要なのは、基盤という言葉である。Devin の価値は、ひとつの画面やひとつのモデルに閉じない。Slack、Linear、GitHub、GitLab、MCP、Windows、Android、継続的インテグレーション、レビュー、監視、利用分析、権限管理へ接続されることで、開発組織の中に置かれる。
この構造を工程ごとに見ると、Devin の位置づけはより明確になる。実装工程では、Devin は変更差分を作る。レビュー工程では、Devin Review が生成された差分を人間が理解しやすい形へ戻す。修正工程では、Auto-Fix がレビュー指摘やテスト失敗を次の入力にする。検証工程では、Computer Use や録画、テスト結果が、人間の採用判断に使える証拠になる。運用工程では、Scheduled Devins と Auto-Triage が、定期作業や外部イベントを入口にして Devin を起動する。企業統制では、MCP、権限、秘密情報、監査、費用上限が、Devin を安全に使うための枠になる。価値測定では、Productivity Estimator、FrontierCode、Devin Fusion が、AI の成果を量ではなく品質と費用対効果で見る方向を示した。
| 工程 | Devin が入った位置 | 人間に残る判断 |
|---|---|---|
| 実装 | リポジトリを読み、変更差分を作り、プルリクエストとして提示する。 | 何を作るか、どの範囲を変えるか、既存設計にどう従うかを決める。 |
| レビュー | 差分を論理単位で整理し、危険箇所や確認対象を示す。 | 差分を受け入れてよいか、設計上の判断が妥当かを確認する。 |
| 修正 | レビュー指摘、lint、テスト失敗、セキュリティ指摘を受けて再修正する。 | 修正が根本原因に向いているか、過剰適応していないかを見る。 |
| 検証 | テスト、画面操作、録画、実行結果を返し、作業結果を確認可能にする。 | 確認範囲が十分か、未確認事項を許容できるかを判断する。 |
| 運用 | 定期実行やアラートを起点に、調査、整理、修正候補の作成を行う。 | 起動条件、重要度、対応範囲、最終的な対応方針を決める。 |
| 統制 | 外部ツール、秘密情報、リポジトリ、監視情報へ管理された形で接続する。 | どの情報へ、どの権限で、どの費用上限の中で接続させるかを設計する。 |
| 評価 | 人間相当工数、品質、費用対効果、モデル運用の観点で成果を測る。 | 測定値をどう読み、どの作業を AI に任せ続けるかを判断する。 |
しかし、この変化は人間を消す話ではない。Devin ができることが増えるほど、人間は何を任せるかをより明確に決める必要がある。AI が作業を進める速度が上がるほど、レビュー、検証、採用判断の重みは増す。AI が外部ツールへ接続されるほど、権限と監査の設計が重要になる。AI の成果が数値化されるほど、測定値をどう読むかという判断が必要になる。したがって、Devin の進化は、人間の責任を軽くするのではなく、人間の責任が現れる場所を変える。
ここにも、二段階の構造がある。第一に、AI が作業を肩代わりすると、人間は手を動かす時間を減らせる可能性がある。これは明確な利点である。調査、機械的修正、テスト、再実行、差分作成、初動整理の一部は、Devin に渡しやすくなる。第二に、手を動かす時間が減るほど、人間が何を正しい成果として認めるのかが重要になる。AI が速く作った差分を無条件に採用すれば、品質、保守性、責任分界は不安定になる。人間は、目的、制約、文脈、検証条件、採用責任を明確にしたうえで、Devin の成果物を組織のコードとして受け入れるかどうかを判断しなければならない。
| 誤解 | 実際に起きている変化 | 結論として必要な見方 |
|---|---|---|
| AI がコードを書けるなら人間の判断は減る | AI が作る差分が増えるほど、レビュー、検証、採用判断の重要性は増す。 | 人間の判断は消えるのではなく、作業前の設計と作業後の承認へ移る。 |
| 強いモデルを使えば開発工程は自動化できる | 実務では、権限、文脈、外部接続、費用、監査、既存手順との整合が必要になる。 | モデル性能だけでなく、業務実装と統制の層を含めて評価する必要がある。 |
| 非同期に動けば人間の時間はそのまま空く | 作業結果が検証可能でなければ、人間は結局最初から確認し直すことになる。 | 非同期開発の価値は、作業が進むことと、確認可能な証拠が返ることの両方で決まる。 |
| AI の成果は数値で客観的に測れる | セッション数、行数、推定工数は材料になるが、品質、保守性、レビュー負荷までは直接示さない。 | 測定値を判断材料として使い、人間が作業の実質的な価値を読む必要がある。 |
したがって、2026 年上半期の Devin が示した本質は、AI が人間のエンジニアを単純に置き換えることではない。人間が目的を定め、作業を切り、文脈を与え、検証条件を置き、成果物を採用する。その間にある実装、調査、確認、修正、定期実行、初動トリアージを、クラウド上のエージェントへ移していく。Devin の半年は、AI ソフトウェアエンジニアの進化を、知能の競争ではなく、開発工程の再設計として見るべきことを示している。
最終的に問われるのは、Devin が人間の代わりになるかではない。どの作業を Devin に渡せる形へ切り出し、どの情報を接続し、どの証拠を返させ、どの判断を人間が保持するかである。2026 年上半期の Devin は、その問いを抽象論ではなく、製品更新の積み重ねとして示した。レビュー、修正、検証、分業、定期実行、運用初動、企業統制、価値測定、費用対効果の各層がそろい始めたことで、Devin はコードを書く AI から、開発工程の中に置かれる作業基盤へ変わった。ここに、この半年の変化の核心がある。
参考文献
- id774, Devin と Claude Code の違いは、作業の任せ方にある（2026-07-09）. https://blog.id774.net/entry/2026/07/09/4967/
- id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/
- id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
- id774, AI の答えは、採用されたときに責任になる（2026-06-26）. https://blog.id774.net/entry/2026/06/26/4925/
- Cognition, Introducing Devin, the first AI software engineer（2024-03-12）. https://cognition.com/blog/introducing-devin
- Devin Docs, 2026 Release Notes. https://docs.devin.ai/release-notes/2026
- Cognition, Infosys partners with Cognition to expand engineering capacity and help scale its enterprise business（2026-01-07）. https://cognition.com/blog/infosys-cognition
- Cognition, Launching in Japan with Takumi Masai（2026-04-09）. https://cognition.com/blog/launching-in-japan
- Cognition, Devin Review: AI to Stop Slop（2026-01-21）. https://cognition.com/blog/devin-review
- Cognition, Closing the Agent Loop: Devin Autofixes Review Comments（2026-02-10）. https://cognition.com/blog/closing-the-agent-loop-devin-autofixes-review-comments
- Cognition, Introducing Devin 2.2（2026-02-24）. https://cognition.com/blog/introducing-devin-2-2
- Cognition, How Cognition Uses Devin to Build Devin（2026-02-27）. https://cognition.com/blog/how-cognition-uses-devin-to-build-devin
- Cognition, Devin can now Manage Devins（2026-03-19）. https://cognition.com/blog/devin-can-now-manage-devins
- Cognition, Multi-Agents: What’s Actually Working（2026-04-22）. https://cognition.com/blog/multi-agents-working
- Cognition, Devin can now Schedule Devins（2026-03-20）. https://cognition.com/blog/devin-can-now-schedule-devins
- Cognition, Introducing Auto-Triage（2026-05-18）. https://cognition.com/blog/auto-triage
- Cognition, Devin in Windsurf（2026-04-15）. https://cognition.com/blog/devin-in-windsurf
- Cognition, Devin CLI: Start Local, Hand Off to the Cloud（2026-04-27）. https://cognition.com/blog/devin-for-terminal
- Cognition, What We Learned Building Cloud Agents（2026-04-23）. https://cognition.com/blog/what-we-learned-building-cloud-agents
- Cognition, Introducing Devin Desktop（2026-06-02）. https://cognition.com/blog/introducing-devin-desktop
- Cognition, Devin now supports Android emulators（2026-05-13）. https://cognition.com/blog/android-emulator
- Cognition, Devin is Getting a Windows PC（2026-05-21）. https://cognition.com/blog/devin-is-getting-a-windows-pc
- Cognition, Engineering in the fast lane: Mercedes-Benz partners with Cognition（2026-04-27）. https://cognition.com/blog/mercedes-benz-cognition
- Cognition, More Devins in More Places（2026-05-27）. https://cognition.com/blog/series-d
- TechCrunch, AI coding startup Cognition raises $1B at $25B pre-money valuation（2026-05-27）. https://techcrunch.com/2026/05/27/ai-coding-startup-cognition-raises-1b-at-25b-pre-money-valuation/
- Cognition, Verifying Agentic Development at Scale（2026-05-29）. https://cognition.com/blog/testing-development
- Cognition, Estimating the Productivity of an Autonomous AI Software Engineer（2026-06-04）. https://cognition.com/blog/ai-productivity
- Cognition, AI should earn its keep: Introducing the AI Productivity Guarantee（2026-06-04）. https://cognition.com/blog/ai-guarantee
- id774, 測ることは、考えることの代わりにならない（2026-07-02）. https://blog.id774.net/entry/2026/07/02/4931/
- Cognition, Introducing FrontierCode（2026-06-08）. https://cognition.com/blog/frontier-code
- Cognition, Devin Fusion: Frontier Performance at 35% Lower Cost（2026-06-29）. https://cognition.com/blog/devin-fusion
- Devin Docs, When to Use Devin. https://docs.devin.ai/essential-guidelines/when-to-use-devin
- Devin Docs, Instructing Devin Effectively. https://docs.devin.ai/essential-guidelines/instructing-devin-effectively