Devinの「80%モーメント」が示す未来：バックグラウンドAIエージェントが変革するソフトウェア開発の最前線

ソフトウェア開発の世界は、かつてないほどの変革期を迎えています。特にAI技術の進歩は、コードの書き方、テストの方法、そして開発者とAIの関わり方に革命をもたらしつつあります。その象徴とも言えるのが、AIコーディングエージェント「Devin」が達成した「80%モーメント」です。これは、DevinがCognition社の内部リポジトリにおけるコミットの80%を占めるまでに成長したという驚くべき事実を示しています。

本記事では、DevinをはじめとするバックグラウンドAIエージェントがどのようにソフトウェア開発の風景を一変させつつあるのかを深く掘り下げます。Cognitionの共同創業者兼CPOであるウォルデン・ヤン氏と、Open Inspectの創業者であるコール・マレー氏の洞察に基づき、その重要性、具体的な機能、ビジネスへの影響、そして将来性を詳細に分析し、専門家と一般の読者の両方に理解しやすい形で解説していきます。

バックグラウンドAIエージェントの夜明け：Devinの「80%モーメント」

2025年12月頃、AIモデルの能力は飛躍的な向上を遂げました。特にAnthropicのOpus 4.5やOpenAIのGPT 5.2といったモデルの登場は、開発者とAIとのインタラクションのあり方を根本から変える契機となりました。これまでモデルを「手で導く」必要があった状況から、より自律的にモデルがタスクを遂行できるようになったのです。

ウォルデン・ヤン氏は、この変化を「仕様からプルリクエストまで、ほとんど摩擦なく完了できるようになった」と表現しています。これは、開発者が詳細な指示を与えることなく、高レベルの仕様に基づきAIが自律的にコードを生成し、テストし、プルリクエストを提出できるようになったことを意味します。このパラダイムシフトが、バックグラウンドエージェント（あるいはクラウドエージェント）という概念を現実的なものに変えました。

Cognitionの内部データがこの劇的な変化を裏付けています。マージされたプルリクエスト（PRs）の数は過去数ヶ月で7倍に増加し、さらに驚くべきことに、DevinがCognitionの全リポジトリにおけるコミットの占める割合は、1月には16%だったものが、3月には80%にまで達しました。これは、AIがもはや単なる補助ツールではなく、開発プロセスの中核を担う存在へと進化したことを明確に示しています。

多くの企業が自社版Devinの開発に乗り出している現状は、この技術が持つ潜在的な影響力への期待の表れと言えるでしょう。

技術的深掘り：エージェントアーキテクチャの選択と開発環境の課題

バックグラウンドエージェントを構築する上で、そのアーキテクチャは極めて重要な決定事項となります。コール・マレー氏がOpen Inspectを開発するきっかけも、既存ツールの摩擦（例：Slack経由のCloud Webセッションが共有できない問題）を解決し、より効果的なエージェントシステムを構築したいという思いからでした。

「脳と機械の分離」：インボックスとアウトオブボックス

エージェントの実行環境を設計する際、「ハーネスを箱の中に置くか、箱の外に置くか（in the box or out of the box）」という選択肢があります。これはエージェントの「脳」（意思決定ロジック）をサンドボックス環境内で直接実行するか、あるいは外部のコントロールプレーンで実行するかの違いを指します。

インボックス（Harness in the box）: エージェントがサンドボックス内で直接実行される方式です。
- デメリット: 主な懸念はセキュリティです。エージェントが箱の中で実行されるため、すべてのシークレット（APIキーなど）も箱の中に置く必要があり、AIの予測不可能性から意図せずシークレットが漏洩するリスクがあります。
- メリット: 状態管理が比較的容易です。エージェントのすべての状態が箱の中に局所化されるため、管理すべき複雑性が少なくなります。
アウトオブボックス（Harness out of the box）: エージェントの「脳」がサンドボックスとは別のワーカーやコントロールプレーンで実行され、サンドボックスはエージェントの「手」としてツールコールを受け取って操作を実行する方式です。
- デメリット: インボックス方式に比べて、アーキテクチャがより複雑になります。状態の管理（例：エージェントがサンドボックスを操作した結果の状態をどのように「脳」が認識するか）が課題となります。
- メリット: セキュリティ面で優位です。シークレットはコントロールプレーンに安全に保管され、サンドボックスには最小限の権限と情報のみが付与されます。これにより、サンドボックスが侵害された場合でも、より機密性の高い情報が保護されます。また、既存の開発環境インフラ（dev boxes）を再利用しやすいという利点もあります。Devinはこの「脳と機械の分離」アプローチを採用しており、ユーザーの権限スコープに応じたシークレット管理を容易にしています。

この選択は、セキュリティと複雑性のトレードオフを伴いますが、長期的に見てアウトオブボックスアーキテクチャが推奨される傾向にあります。

開発環境の課題と解決策：Repo Setup

エージェントが自律的にコードを開発するためには、適切に設定された開発環境が不可欠です。しかし、多くの企業では、開発環境のセットアップは「ボブに話してシークレットをもらう」といった属人的なプロセスに依存しているのが現状です。これはAIエージェントにとって大きな障壁となります。

Dockerの限界: Dockerコンテナはインフラの管理に広く利用されていますが、AIエージェントの実行環境としてはいくつかの課題があります。Dockerは真のセキュリティ境界とは言えず、また、実際のアプリケーションがDockerを使用している場合、「Docker in Docker」という複雑な状況が発生します。
フルVMの必要性: Cognitionが初期にフルVM（仮想マシン）の構築に注力した理由は、AIエージェントがアプリケーションを完全に実行し、クリック操作やスクリーンレコーディングを行うためには、より堅牢で分離された環境が必要だと認識したためです。
Open Inspectの解決策: Open Inspectでは、setup.shスクリプトを使用して必要なものをプリインストールし、そのビルドをプリスナップショットすることで、環境の起動を瞬時に行えるようにしています。さらに、サンドボックスの状態を復元するフックも提供されており、既存のマイクロサービス環境をエージェントにそのまま提供できます。
VMサービスの多様性: Mac OS、Windows、さらにはAndroid開発のためのNested Virtualization（ネストされた仮想化）をサポートするVMの必要性も指摘されています。Devinは現在、Android開発のベータサポートを提供しており、こうした多様な環境への対応を進めています。

テストの概念再定義：単なるUI操作を超えて

AIの能力を評価する際、「コンピューター利用」と「テスト」はしばしば混同されがちですが、ウォルデン・ヤン氏は両者の間に明確な違いがあると強調しています。「コンピューター利用」が単にボタンをクリックするために正しい座標を生成するような低レベルのUI操作を指すのに対し、「テスト」ははるかに複雑な問題解決の挑戦です。

「テスト」の複雑性: フロントエンドとバックエンドにまたがる変更をテストする場合を想像してください。AIはまず、アプリケーションを正しいバージョンのコードでオーケストレーションし、連携させて実行する方法を推論する必要があります。次に、特定の機能をトリガーする方法、あるいは目的のアクションを実行する方法を特定しなければなりません。これは、管理者権限が必要であったり、特定の機能フラグがオンになっている必要があったり、複数のセッションを起動して特定の単語を送信して振る舞いをトリガーしたりするなど、任意に難易度が上がります。
コードベースのコンテキストとオーケストレーション: これらの複雑なテストを遂行するには、大量のコードベースコンテキストと、異なるモデルを連携させるオーケストレーション能力が不可欠です。実際、単一のフロンティアモデルではエンドツーエンドのタスクを完遂できないケースもあり、複数のフロンティアモデルを協調させる必要が生じることもあります。
ビジュアルフィードバックの重要性: テストプロセスの可視化も極めて重要です。Open Inspectではスクリーンショット機能が追加され、Devinではテスト完了後に動画が提供されます。これらの動画では、カーソルの動きやテスト対象がラベル付けされており、「何がテストされているのか」を視覚的に理解できるようになっています。これにより、コードを直接確認する手間を省き、Slackなどのプラットフォームから直接マージを承認できる未来が示唆されています。

AIコードレビューの進化とインテグレーション

AIエージェントが生成したコードの品質を保証するためには、AI自身によるコードレビューも不可欠です。DevinはGitHub上でプルリクエストを作成するだけでなく、そのプルリクエストに対してコメントし、さらには自身のコメントに返信して修正を行う機能まで備えています。これは、エージェントが単にタスクをこなすだけでなく、そのプロセス全体を管理し、品質を向上させようとする高度な自律性を示しています。

ループ防止と高シグナルコメント: AIが自身のコメントに無限ループしないよう、Cognitionはコメントの「シグナル」を高め、エージェントが修正すべきコメントとそうでないコメントを賢く判断するようにチューニングしています。ウォルデン・ヤン氏は、Devinが自分の指示を「間違っている」と指摘し、異なる行動を促す瞬間に「AGI（汎用人工知能）の片鱗を感じる」と述べています。
Open Inspectのレビュー機能: Open InspectもGitHubコードレビュー機能を備えており、プロンプトで制御可能です。現在は手動でトリガーする必要がありますが、マージの競合解決など、特定のタスクをエージェントに依頼することができます。
エコシステムへの統合: AIエージェントが真価を発揮するには、企業の既存エコシステムへの深い統合が不可欠です。これには、本番データベース（読み取り専用）、ログシステム、社内知識ベース（Confluenceなど）との連携が含まれます。特にコンプライアンス要件の高い環境では、アクセス制御を慎重に設計する必要があります。
Slack連携の深化: 多くの企業がコミュニケーションの中心として利用するSlackとの連携も進化しています。単純なNCP（Multi-Connectors Platform）統合を超え、Webhookをサポートし、Devinが同僚のように自然にスレッド内で応答できるような深い統合が求められています。これは、エージェントがスパムにならないよう、応答の「チューニング」が重要となる領域です。ウォルデン・ヤン氏は、NCPの仕様が複雑になりすぎると、そのシンプルさという本来のメリットが失われ、結局はファーストパーティでの統合が必要になると指摘しています。

エージェントの能力拡張：記憶と知識ベースの管理

AIエージェントが長期的に複雑なタスクを効果的に遂行するためには、「記憶」や「知識ベース」の管理が不可欠です。しかし、これは現在も「未解決の問題」の一つとされています。

記憶の生成と検索の課題: Devinは「Knowledge」というシステムで記憶を管理しています。これは、ユーザーがDevinを訂正した際に、「これを将来のために覚えておきたいですか？」と尋ね、ユーザーの承認を得て自動的に記憶を構築する仕組みです。ウォルデン・ヤン氏によれば、Devinの記憶の約95%がこの自動生成プロセスによるもので、ユーザーが自ら詳細なドキュメントを作成することは稀です。しかし、記憶の「生成」と「検索」には課題があります。例えば、「ドラフトPRとして開く」と一度指示されたからといって、すべてがドラフトPRになるべきではありません。特定のユーザーが特定のことを好む、といった文脈に応じた記憶が必要です。また、数千もの記憶の中から適切なものを適切なタイミングで検索することは非常に難しく、コンテキストウィンドウを無用な情報で肥大化させずに正確な情報を引き出すための継続的な評価とチューニングが求められます。
記憶の編集と時間的側面: Devinの現在のシステムでは、記憶を編集することが可能です。例えば、「コールはすべてドラフトPRとして開くのが好きだった」という記憶を、「コールは通常のPRとして開くのを好むようになった」と更新できます。記憶の「プルーニング（剪定）」や時間的側面（古くなった記憶の扱いや自動削除）も重要な研究テーマです。
ファイルシステムとしての記憶: 近年のAIエージェントはファイルシステムをネイティブに扱うのが非常に得意になってきているため、記憶システムをエージェント自身がナビゲートできるファイルシステム（例：memory.mmdファイル）として再構築するアイデアも検討されています。OpenClawの「デイリーメモリージャーナル」も、エージェントが過去のやり取りを記録し、検索できるようにする試みの一つです。
エージェントが「常駐PM」になる未来: 記憶の概念を発展させることで、AIエージェントが単なるエンジニアリングタスクを超え、より高レベルの役割を担う可能性も生まれます。例えば、特定のSlackチャンネルに常駐し、優先順位の高い課題や担当者を記憶し、定期的に人間をタグ付けする「永久的なPM（プロジェクトマネージャー）」として機能するDevinが構想されています。これにより、Devinがチケットを作成し、人間や他のDevinがそれを解決するという、より上流のプロセスへのAIの統合が進むかもしれません。コール・マレー氏は、競合他社の調査を行い、毎週提案を行う自動化の例を挙げています。

新しい開発パラダイム：人間とAIの協調

AIエージェントの進化は、ソフトウェア開発における人間とAIの協調のあり方を問い直しています。

シングルエージェント vs マルチエージェント（エージェントの群れ）

以前のウォルデン・ヤン氏の立場は「Don't build multi-agents（マルチエージェントを構築するな）」でしたが、最近ではその可能性について議論が進んでいます。マルチエージェントとは、複数のエージェントが互いに協力してタスクを遂行するシステムを指します。

ツールコールとしてのサブエージェント: 現在の多くの「マルチエージェント」と称されるシステムは、実際にはツールコールに近い振る舞いをしています。例えば、メインエージェントが特定のファイルや実装を探すためにサブエージェントを呼び出す場合、これは効果的なコンテキスト管理のメリットがあります。サブエージェントが消費したトークンやツールコールは、メインエージェントへの回答として「畳み込まれる」ため、効率的な情報収集が可能です。Devinが「Deep Brooke」のような知識ベースをツールコールとして利用するのもこの例です。
協調的コミュニケーションの成熟: マルチエージェントの真の可能性は、エージェント同士が異なる情報を見た上で、どちらが正しいか、何が正しい実装かを議論し、相互に協力して問題を解決できる成熟したコミュニケーション能力にかかっています。ウォルデン・ヤン氏は、Devinが人間を「間違っている」と指摘し、押し戻すことができる能力が、マルチエージェントの世界を可能にする重要な指標だと考えています。これは、AIが単なる「Yesマン」ではなく、批判的思考を持つようになったことを示しています。
「スロップキャノン」アプローチの限界: 複数のエージェントが並行してコードを生成する「スロップキャノン」アプローチは、初期の高速開発には有効かもしれませんが、ウォルデン・ヤン氏の実験では、約2週間でコードベースがメンテナンス不能な状態（例：ボタンの色を変えるだけで10箇所を修正する必要がある）に陥ることが示されました。これは、コードレビューやクリーンアップを伴わない並行開発が、急速な「コード品質の退行」を招くことを意味します。

コード品質の維持とアーキテクチャの重要性

AIエージェントがコードの大部分を生成するようになる未来において、コード品質をどのように維持するかが重要な課題となります。「コードを見なくてよい」という考え方は危険であり、コール・マレー氏は、コードベースが「最悪のエンジニア」に退行するリスクを指摘しています。AIが品質の低いパターンを学習し、それを指数関数的に増殖させてしまう可能性があるのです。

対策としてのクリーンアップとリンティング: この問題に対処するためには、人間による、あるいはシステムによる定期的なコードクリーンアップが不可欠です。AIエージェントが生成しやすい特定のコードパターン（例：Pythonにおける不必要なhasattrの多用、過剰なコメント、後方互換性への固執による奇妙なimport/export、型なしタプル）を特定し、リンティングルールや静的解析ツール（semgrepなど）で自動的に検出・修正することが求められます。
モジュール境界と人間の監査: ウォルデン・ヤン氏は、モジュール間の厳格な境界を設定し、その間の変更には人間による承認を必須とすることを推奨しています。これにより、AIが自律的にブラックボックス内で作業しつつも、システム全体の整合性と品質が保たれるようになります。

インフラストラクチャの深遠な課題

AIエージェントが円滑に動作するためには、その基盤となるインフラストラクチャも最適化されている必要があります。AIの専門家が必ずしもインフラの深い知識を持っているわけではないため、思わぬ落とし穴にはまることがあります。

仮想マシンのファイルシステム問題: 例えば、多くの仮想マシンが基盤となるファイルシステムとして、実際にはネットワークファイルシステム（S3などでキャッシュされる）を使用していることがあります。この場合、コードベース内の文字列検索（grep）のような基本的な操作でさえ、ネットワークコールを大量に発生させ、パフォーマンスを著しく低下させます。Cognitionは、この問題に対処するためにネットワークファイルシステムを交換する必要がありました。
ブロック差分ファイルストレージフォーマット: Devinの高速起動・終了を可能にしている技術の一つに「ブロック差分ファイルストレージフォーマット」があります。これは、ディスク全体の変更ではなく、ファイルシステムの「差分」のみを保存・復元することで、VMの起動時間を劇的に短縮するカスタムファイルシステムフォーマットです。このような細かなインフラストラクチャの最適化が、日々のエージェント利用体験の質を左右します。
クラウドプロバイダーの選択: Open Inspectは、Cloudflareのコントロールプレーンを利用し、サンドボックスにはModal、Daytona、E2Bなどのプロバイダーをサポートしています。Modalは特にPythonのワークロードに強く、スナップショット機能やGPU提供など、エージェント開発に必要な機能を網羅していると評価されています。
言語エコシステムのトレンド: AIエージェントの開発において、PythonとJavaScriptのどちらが主流になるかという議論もあります。現在のAIライブラリはPythonネイティブなものが多いですが、フロントエンドとバックエンドで一貫した言語（特にTypeScript/JavaScript）を使用したいというニーズも高まっています。

AIエージェントの未来：ユースケースとビジネスインパクト

バックグラウンドAIエージェントは、既存のソフトウェア開発プロセスだけでなく、企業のさまざまな機能に新たな価値をもたらす可能性を秘めています。

主要なユースケース

コール・マレー氏とウォルデン・ヤン氏が指摘する主要なユースケースは以下の通りです。

SRE（サイト信頼性エンジニアリング）:
- オートトリアージ: SlackやDataDogなどのアラートシステムから発せられるアラートに対し、エージェントが「ファーストレスポンダー」として機能します。
- コンテキスト収集: 本番ログやデータベースにアクセスし、問題の完全なコンテキストを瞬時に収集します。
- 自動プルリクエスト: 多くのケースで、問題の原因を特定し、修正のためのプルリクエストを直接作成します。これにより、「エラー発生 → プルリクエスト作成」というシームレスなフローが実現します。Open InspectはSentryからのトリガーや汎用Webhookをサポートし、この自律的な対応を可能にしています。
非開発者によるコード貢献:
- PMやマーケティングチームによるコード修正: プロダクトマネージャー（PM）やマーケティング担当者が、Slackから直接プロンプトを送信するだけで、軽微なバグ修正や機能追加のプルリクエストを生成できるようになります。これにより、エンジニアリングチームへのボトルネックが解消され、コード変更のプロセスが民主化されます。
顧客サポート:
- 問題の迅速な診断: 顧客が抱える問題（例：特定の機能が動作しない）が発生した際、サポートチームがSlackでエージェントをタグ付けすると、エージェントが関連するコードベースのコンテキストやログを瞬時に参照し、問題の根本原因を特定します。これにより、エンジニアへの情報伝達がスムーズになり、「追加情報を顧客から得てきてください」といった往復が不要になります。
- CLIの代替としてのチャットインターフェース: 非技術者にとってコマンドラインインターフェース（CLI）は敷居が高いものですが、AIエージェントが提供する直感的なチャットインターフェースは、技術的な知識がなくてもコードベースに関する質問を投げかけ、回答を得られるようになります。これは営業担当者など、幅広い職種で活用される可能性があります。
継続的なセキュリティスキャン・レビュー:
- AIエージェントは、コードベースの継続的なセキュリティスキャンやレビューを自動的に実行し、潜在的な脆弱性を早期に発見し、修正する役割を担うことができます。

費用対効果と予算

AIエージェントの導入にはコストが伴いますが、その価値は計り知れません。コール・マレー氏によると、エージェントの利用コストはエンジニア一人あたり月額1,000ドルから5,000ドル程度が一般的ですが、場合によっては50,000ドルに達することもあるとウォルデン・ヤン氏は補足しています。

フロンティアモデルとサブフロンティアモデルのハイブリッド利用: 今後、非常に高価で高性能な「フロンティアモデル」と、特定のタスクに特化し、より安価で効率的な「サブフロンティアモデル」のハイブリッド利用がトレンドとなるでしょう。ウォルデン・ヤン氏が提唱する「Smart Friend」の概念は、高速で効率的なサブフロンティアモデルをメインとし、必要に応じてフロンティアモデルを呼び出すことで、パフォーマンスとコスト効率を両立させるアプローチです。

Windsurf 2.0：ローカルとクラウドのシームレスな連携

Cognitionが最近リリースしたWindsurf 2.0は、バックグラウンドエージェントとローカル（フォアグラウンド）エージェントの連携を強化するものです。AIエージェントによるテストが魔法のように機能する一方で、時には開発者がローカル環境で直接コードをプルダウンし、手動でテストする必要が生じます。

Windsurf 2.0は、開発者のローカルコマンドセンターとして機能し、バックグラウンドエージェントとローカルエージェントの間のシームレスなハンドオフを可能にします。例えば、エージェントがレビューを必要とするタスクを提示した場合、開発者はそれをローカルにプルダウンしてテストし、完了したら他のエージェントをバックグラウンドに移行させるといった流れが想定されます。

ここで重要なのは、ローカルエージェントとクラウドエージェントでは、その理想的な振る舞いが異なるという点です。ローカルエージェントは、ユーザーが迅速に意思決定できるよう、より高速でユーザーの介入を許容するべきですが、バックグラウンドエージェントは、一旦起動したらテスト完了まで止まらずに自律的に進行するべきです。この振る舞いの違いは、プロンプトの調整によって対応されますが、可能な限り多くのロジック（異なるGitプロバイダーやOS/VMへの対応など）を共有することで、開発の効率性が向上します。

結論：AIがソフトウェア開発を再構築する時代へ

Devinの「80%モーメント」は、ソフトウェア開発におけるAIの役割が根本的に変化したことを明確に示しています。バックグラウンドAIエージェントは、単なるコード生成ツールを超え、開発プロセスのほぼ全ての段階で自律的に機能し、生産性を劇的に向上させる可能性を秘めています。

しかし、この変革の道のりは、技術的な挑戦と新たなプラクティスを伴います。「脳と機械の分離」といった堅牢なアーキテクチャ設計、開発環境の自動化、テストの概念の再定義、そして記憶管理とエコシステムへの深い統合は、AIエージェントの真のポテンシャルを引き出すために不可欠です。

人間とAIの協調も、新たな段階へと進化しています。AIが人間の指示に異を唱え、より賢明な解決策を提示するような成熟した対話が可能になる一方で、コード品質の維持やアーキテクチャの厳格な管理には、依然として人間の専門知識と監査が不可欠です。

SRE、非開発者によるコード貢献、顧客サポート、セキュリティレビューなど、AIエージェントが切り開くユースケースは多岐にわたり、ビジネス全体に大きなインパクトを与えるでしょう。そして、Windsurf 2.0のようなツールは、ローカルとクラウド、人間とAIの間の境界線をさらに曖昧にし、開発体験をより流動的で効率的なものへと変えていきます。

私たちは今、「自動化されたコーディング工場」へと向かう時代に生きています。この変革の波に乗るためには、技術的な深い洞察力、絶え間ない学習、そして人間とAIが協力してより良い未来を築くためのオープンな姿勢が求められるでしょう。