Devin が Windows をサポート — VM 上でネイティブにビルド・実行・テストできるようになった

Posted on:2026-05-22

https://devin.ai/windows

https://docs.devin.ai/ja/onboard-devin/environment/windows-support

https://x.com/cognition/status/2057496130225668360

https://x.com/cognition/status/2057496136114413825

Cognition の Devin が、Windows VM 上でネイティブに動作するようになった。Windows は 14 億台以上のデバイスで動いており、エンタープライズやレガシー系の開発では依然として中心のプラットフォームだ。これまでコーディングエージェントの話は Linux 前提が多かったが、Devin は「Windows PC を手に入れた」と言い換えられる形で、Windows アプリのマッピング・構築・モダナイゼーションまで任せられるようになった、という位置づけだ。

製品ページ日本語ドキュメント を読むと、発表の要点は次の3つに整理できる。

  1. ブループリントとセッションが Windows を選べるruns-on: windows でビルド環境を指定する
  2. 実際の Windows 環境でビルド・テスト・反復 — .NET Framework から .NET 8 への移行など
  3. Computer Use で GUI まで検証 — アプリを起動し、UI をクリックして動作確認する

何ができるようになったか

Cognition の X 投稿とランディングページでは、次のユースケースが強調されている。

Windows アプリのマッピング・構築・モダナイゼーション

クラウド型 AI エージェントの強み——タスク委任、並列実行、自律的な反復——が Windows アプリケーションにも適用される、という説明だ。デモでは .NET Framework アプリに新機能を足し、その後 .NET 8 へ移行しながら 実際の Windows 環境でテストする流れが示されている。

.NET Framework から .NET Core への移行

組み込みの QA とテストを使い、.NET Framework から .NET Core(.NET 8 など)への移行を Windows 上でビルド・テスト・反復 できる。レガシー移行は「コードを書き換える」だけでなく、実行環境での検証がボトルネックになりがちだが、Devin はその検証ループまで含めて任せられる、という訴求だ。

Computer Use による Windows アプリのテスト

Devin は Windows アプリをビルドして起動し、UI を直接操作して 期待どおり動くか確認できる。あるいは、お気に入りアプリをゼロから再構築する、という例も挙げられている。CLI だけでなく、デスクトップアプリの QA まで視野に入る点が新しい。

ネイティブな Windows ツールチェーン

Devin は MSBuild、IIS、PowerShell、SQL Server など、Windows ネイティブのツールチェーンに対応した。これらのシステムが実際に依存する環境内で動く、というのがポイントだ。Linux 上のエミュレーションやクロスコンパイルではなく、本番に近い OS で作業する、という意味合いになる。

技術的な仕組み(ブループリント)

Windows サポートのドキュメント では、Linux と同じ 宣言的なブループリント システムの上に Windows が載っている。主な違いは runs-on フィールドで、Devin がどのプラットフォームでビルドと実行を行うかを指定する。

項目 Linux(デフォルト) Windows
ホームディレクトリ /home/ubuntu /c/Users/Administrator
リポジトリ ~/repos/<repo> /c/Users/Administrator/repos/<repo>
パッケージ apt-get chocowinget、直接インストーラー

シェルはどちらも bash(Git Bash)

Windows セッションでも Git Bash をデフォルトシェルとして使う。Linux と同じ bash なので、多くのブループリントのコマンドは両プラットフォームでそのまま動く、とドキュメントには書かれている。違いが出やすいのはファイルシステムのパスとパッケージマネージャーだ。

# Linux のパス
- run: cp config.json ~/.config/myapp/config.json

# Windows(Git Bash 形式)
- run: cp config.json /c/Users/Administrator/.config/myapp/config.json

runs-on の指定方法

Value Platform
default または linux Linux
windows Windows

単一プラットフォーム用:

runs-on: windows

initialize:
  - name: "Install .NET SDK"
    run: |
      winget install --id Microsoft.DotNet.SDK.8 --accept-source-agreements --accept-package-agreements

maintenance: |
  dotnet restore

knowledge:
  - name: build
    contents: dotnet build
  - name: test
    contents: dotnet test

Linux と Windows の両方で同じリポジトリをビルドする場合は、マルチブロック形式でプラットフォームごとにブロックを分ける。各ブロックで別々のスナップショットが生成され、セッションはプラットフォーム固有のスナップショットから起動する。

runs-on: [default, windows] のようにリストで複数プラットフォームを指定することもできるが、同一コマンドが両方で動く場合だけnpm installuv sync など)に使うべきだ。apt-getchoco のように OS 固有のコマンドがある場合は、ブロックを分ける。

ツールのインストール例

Chocolatey や winget が推奨される。

initialize:
  - name: "Install Chocolatey packages"
    run: |
      choco install git -y
      choco install nodejs-lts -y
      choco install python --version=3.12 -y

  - name: "Install with winget"
    run: |
      winget install --id Microsoft.DotNet.SDK.8 --accept-source-agreements --accept-package-agreements

Visual Studio / C++ 向けには visualstudio2022buildtoolsvisualstudio2022-workload-vctools を choco で入れ、msbuildvstest.console.exe を knowledge に書くパターンがドキュメントに載っている。

セキュリティとガバナンス

エンタープライズ向けの説明もセットで出ている。

  • 分離されたセッション — 専用の microVM 上で動作
  • エフェメラル VM
  • 顧客コードをトレーニングに使わない
  • SOC 2 Type IIISO 27001 準拠
  • SSORBAC

Windows 版でも、Linux セッションと同様に隔離環境で動く、というメッセージだ。レガシー系のコードベースを預ける場合、コンプライアンス要件を満たすかは導入前の確認ポイントになる。

利用できるか — 限定提供

ドキュメントでは Windows サポートは現在、限定提供 と明記されている。Devin で Windows を試すには、Cognition へのお問い合わせ で詳細確認とアクセス権の取得が必要だ。製品ページからは Try Devin for Windows への導線もあるが、一般公開の範囲はドキュメントの表現と照らして確認した方がよい。

前の Devin 記事との関係

直前に書いた Devin Auto-Triage は、Slack 監視とインシデント初動の話だった。今回の Windows サポートは、実装・移行・デスクトップ QA の軸が強い。Auto-Triage が「起きたあとの最初の15分」、Windows 版は「レガシーを本番に近い OS で直す・移す」、という補完関係に見える。

コーディングエージェントの議論が Linux / macOS / クラウドネイティブ寄りになりがちな中で、.NET や IIS、SQL Server が絡む現場 に Devin を置けるかどうかは、導入判断の分かれ目になりそうだ。

自分の整理

個人的に押さえておきたい点は次のとおりだ。

  • ブループリントの runs-on: windows が入口 — Linux と同じ YAML 思想で、OS を切り替えられる
  • シェルは Git Bash で共通化 — 完全な別言語ではなく、パスとパッケージマネージャーが主な差分
  • マルチプラットフォームはブロック分割が基本 — リスト構文は本当にクロスプラットフォームなコマンドだけ
  • Computer Use で GUI テストまで — CLI エージェントの延長ではなく、デスクトップ QA の文脈
  • 限定提供 — 記事を書く時点では全員がすぐ使えるわけではない

Windows 開発は「エージェントが Linux しか知らない」という不満が長くあった領域だ。Devin が Windows VM と MSBuild / PowerShell / SQL Server を前面に出したのは、そのギャップを意識した動きに読める。実際に .NET 移行やレガシー改修を任せる価値があるかは、ブループリントを組んだうえでの試用次第だろう。

詳細は 製品ページWindows サポート(日本語)Cognition の発表(1)発表(2) を参照。