Cognition、AIソフトウェアエンジニア「Devin」向けにネイティブなmacOSクラウドサポートを発表

Cognitionは、自律型AIコーディングエージェント「Devin」に対するmacOSサポートを発表し、自律型クラウド開発ワークフローをiOSアプリ、ネイティブmacOSプログラム、およびApple開発ツールチェーンに依存するすべてのプロジェクトへと拡張した。

なぜDevinにはMacが必要なのか？

AIエージェントがAppleエコシステム内で自律的に開発タスクを完遂できるようにするためには、段階的な2つの現実的要件が存在する。

• コンパイルと起動の成功は、ランタイム挙動の正しさを証明しない：ローカル開発において、コーディングアシスタントはコンパイラのエラー出力に基づいてビルドが通るまでコードを修正し続けることが容易である。しかし、ユーザー向けのグラフィカルインターフェースアプリケーションにおいては、単にコードのコンパイルが通りプロセスが正常に起動したからといって、実際に正しく動作しているとは限らない。真の検証は、ランタイムの振る舞いと状態復元にある。
• ネイティブアプリの検証とツールチェーンはmacOSワークスペースに依存する：Appleエコシステムのネイティブアプリは、XcodeやiOS Simulatorといった専用の開発ツールチェーンに深く依存している。実行時におけるアプリケーションの実際の挙動を検証するには、エージェント自身が実際に実行、操作、検証を行えるネイティブなmacOSワークスペースを保持していなければならない。

例えば、iPhone向けモバイルゲームの開発において、ユーザーがゲームを一度終了しても、再度開いた際に前回一時停止した状態へと正確に復帰できることがコア要件となる。単にコンパイルが通り正常に起動しただけでは、ゲームエンジンが実行データを正しく保存・復元できているかは保証できない。エージェントは実際のユーザーと同様に、「プレイし、一時停止し、終了し、再起動して復元を検証する」という完全な閉ループを完遂しなければならない。

クラウド上でこの閉ループを成立させるのは決して容易ではない。仮想マシン上でmacOSを起動することは最初のステップにすぎない。実用的な自律開発ワークスペースとして機能させるには、データ状態の永続化、セッションネットワークの安全な分離、人間による手動介入を排した起動時構成、そして人間とマシンの双方によるリアルタイム画面表示とコントロール操作といった問題を低レイヤーで解決する必要がある。

これらの取り組みは、単一の5層の検証チェーンに沿って順次連結されている。最下層でまずストレージスナップショットを開通させてネットワークを統制し、イメージの事前準備によって手作業によるポップアップ対応をタスク実行時間外へと排除する。リアルタイム画面によってユーザーが実行中のアプリの確認や操作の引き継ぎを行えるようにし、構造化されたアクセシビリティツリーによってDevinがネイティブコントロールの照会、操作、検査を行えるようにしている。

1. ストレージ層の設計：NBDプロトコルによるセッション間スナップショットの開通

DevinのクラウドサービスはAWS EC2 Macベアメタルインスタンス上に構築されており、ホストマシンはApple公式のVirtualization.framework仮想化フレームワークを介してmacOSゲスト仮想マシンを実行する。

クラウドにおけるエージェント開発の大きな特徴は非同期コラボレーションにある。ユーザーは要件をエージェントに渡した後に付きっきりで監視する必要はなく、アイドル状態のセッションで仮想マシンを常時稼働させておく必要もない。ユーザーが次回セッションを開いた際に前回までの作業進捗へ直接復帰できるようにするため、システムにはセッション内のすべての依存関係、プロジェクトファイル、コード変更を保存し、環境の再構築プロセスを不要にするスナップショット機構が求められる。

オペレーティングシステムにとって、仮想ディスクは低レイヤーのブロックデバイスである。すなわち、固定サイズデータブロック単位での生データの読み書きのみを担い、上位のファイルシステムやスナップショットストレージの具体的な実装は関知しない。Linux仮想マシンにおいて、Devinは通常vhost-userプロトコルを利用して、仮想ディスクのI/O操作をホスト上の独立したストレージプロセスに直接委譲する。しかし、AppleのVirtualization.frameworkはvhost-userをサポートしていない。

その代替として、Appleの仮想化フレームワークはもう一つの古典的な通信プロトコルであるネットワークブロックデバイス（Network Block Device、略称NBD）をサポートしている。NBDは、クライアントがローカルソケットを介してリモートまたはホストマシン上のブロックデバイスを直接読み書きすることを可能にする。チームは既存のスナップショットストレージシステムの前面にネットワークブロックデバイス（NBD）フロントエンドを追加した。これにより、下位のスナップショットバックエンド（snapshot backend）に変更を加えることなく既存の永続化アーキテクチャを再利用することに成功し、ゲスト仮想マシンからは依然として通常の仮想ディスクとして認識される。

仮想マシンとスナップショットストレージの接続パス

[macOS ゲスト内部]
アプリケーションとファイルシステムの読み書き
       ↓
標準仮想ディスク（ブロックデバイス）
       ↓
[システム境界：ホストマシン]
Virtualization.framework
       ↓ (NBD プロトコル / ローカル Unix Socket)
ホストのスナップショットストレージプロセス（NBD フロントエンドが既存のスナップショットバックエンドに接続）

仮想マシンの停止ライフサイクルも同様に厳格な制御が必要とされる。仮想マシンがタスクを完了して切断され終了した後も、ホスト上のストレージプロセスは稼働を継続し、未完了の書き込み待ちデータの保存とスナップショットのアップロードを担当する。ホストの仮想化マネージャ（hypervisor）はこの終結処理（finalization）の完了を厳密に待機し、その後に初めて最終的なリソースのクリーンアップを実行する。

仮想マシン終了とスナップショット確定のシーケンス

仮想マシン状態：     [ 実行中 ] ──────> [ 切断 / 停止 ]
ストレージプロセス状態： [ 読み書き処理 ] ──> [ ペンディングデータの書き込み ] ──> [ スナップショット準備完了 ]
仮想化マネージャ：                        [ データのディスク書き込み待機 ] ──────> [ リソースの破棄・回収 ]

2. ネットワーク層の制御：自作のユーザー空間Ethernetゲートウェイによるファイアウォール競合の回避

クラウドワークスペースには厳格なネットワーク境界保護が不可欠である。仮想マシンはセッションポリシーに基づいて外部の依存ネットワークへアクセスする必要がある一方で、ホストマシンのプライベートインフラストラクチャへのアクセスは厳格に遮断されなければならない。

AppleのVirtualization.frameworkは、仮想マシンをネットワークに接続する3つの方式を提供している。

ブリッジモード（Bridged）：仮想マシンのEthernetフレームをホストの物理ネットワークカードに直接送信する。

NATモード：仮想マシンにホストマシンの外部IPアドレスを共有させ、macOSオペレーティングシステムがアドレス変換を担う。

ファイルハンドルモード（File-handle attachment）：ホストマシンのローカルUnixデータグラムソケット（Datagram Socket）を介して生のEthernetフレームを直接送受信する。データグラムごとに1フレームが格納され、後続の処理は受信側が担当する。

NATモードは直感的ではあるものの、このデプロイ環境においては、macOSシステムのApple NATとDevinのネットワーク制御機構の双方が低レイヤーのパケットフィルタファイアウォール（pf、Packet Filter）を管理することになる。双方が同時に稼働すると同一のパケットフィルタを競合して設定し合うため、ルール設定の不整合や競合状態（レースコンディション）が発生する。

この競合を回避するため、チームはApple管理のNATを断念し、最も低レイヤーな「ファイルハンドルモード」を選択した。この選択に伴う課題は、ホストマシンが受け取るデータが直接ルーティング可能なレイヤー3のIPパケットではなく、レイヤー2のEthernetフレーム（MACアドレスなどの物理リンク情報を含む）になる点である。例えば、仮想マシンが外部へパケットを送信する前には、ローカルネットワーク内でまずARP（アドレス解決プロトコル）要求をブロードキャストし、ゲートウェイの物理アドレスが何であるかを問い合わせる必要がある。

そのため、ホストマシン上に専用の独自ユーザー空間Ethernetゲートウェイを構築し、これらの通信の詳細を処理させている。

仮想マシンネットワークパケットの往復経路

[ macOS 仮想マシン ]
       │ 生のEthernetフレーム（Guest MAC → Gateway MAC）
       ▼
[ ホストのユーザー空間Ethernetゲートウェイ ]
  ├── 仮想マシンからのARP物理アドレス問い合わせに応答
  ├── Ethernet送信元/宛先MACアドレスの正当性を検証
  └── 送信元IPアドレスがシステム割り当てと一致するか確認
       │ クリーニング済みのレイヤー3 IPパケットを通過
       ▼
[ ホストの仮想トンネルインターフェース（Tunnel Interface）]
       │
       ▼
[ pf ファイアウォールルールおよびプロキシサービス ] ──> セッションアクセス制御ポリシーを実行して外部ネットワークへ送出

これは明確な技術的トレードオフである。チームは、Apple標準のNATとファイアウォール設定を競合させる問題を回避するため、データリンク層のパースと検証をホストマシン側で自前で担うという明確なコストを引き受け、受け入れたIPパケットをホストのtunnel、pfルール、およびプロキシサービスに引き渡して処理させている。

3. イメージの事前作成とウォームアップ：システム起動前に権限ダイアログを遮断

Macに開発ソフトウェアをインストールした経験がある人なら誰でも知っている通り、OSをインストールした直後のPCは実際の作業を開始できる状態からは程遠い。システムにはユーザーアカウント、利用可能なデスクトップ、Xcodeツールが存在せず、さらに極めて重要な点として、自動化された対話処理に必要な各種システム権限が欠落している。

macOSは、画面収録やアクセシビリティ制御といった権限に対して確認ダイアログをポップアップ表示する。これらの対応をセッション開始後に先送りした場合、ダイアログが表示されるたびにDevinの処理が停止し、人間によるクリックを待つことになりかねない。

1つのアプローチは、マシン起動後にUI自動化を用いてユーザーを作成し、デスクトップへログインし、権限要求をトリガーして1つずつ承認していくことだが、一連のGUI操作を協調動作させることは信頼性に欠け、コストも高くなる。

そこでシステムは段階的な準備アプローチを採用した。まずベースイメージのビルド段階でゲストディスクをオフラインマウントする。ホストマシンが仮想ディスクをローカルディレクトリとして直接マウントし、GUIを迂回してシステムユーザーを作成し、macOS内部の設定データベースを修正することで、起動前にあらかじめ基本構成を完了させておく。

しかし、一部の依存関係はオフライン状態のままでは設定を完了できない。これらのタスクをエージェントの作業開始後に残しておくと、Devinがシステムの初期化処理とリソースを奪い合うことになる。そのため、システムはイメージ構築段階で「オンラインウォームアップ」を追加で実行する。

• あらかじめ構成されたイメージを起動し、残りの開発ツールをインストールしてXcode環境を検証する。
• 事前にiOS Simulatorを起動して「立ち上げ」、シミュレータ内部のシステム起動が完了するまで待機する。
• Spotlightによるデスクトップのインデックス作成およびバックグラウンドの初期化タスクがすべて完了するのを待ち、不要なシステムのバックグラウンドデーモンを明示的に停止する。

オフライン構成と起動後のウォームアップ準備を経ることで、ワークスペースはエージェントが接続する前にツールのインストール、環境検証、不要なバックグラウンドデーモンの停止を完了させ、起動後の初期化処理による干渉を削減している。

4. リアルタイム画面：遅延のない追従性の維持

開発環境が整った後、システムは2種類の役割を持つアクターをアプリケーション操作に関与させる必要がある。人間の開発者は画面を監視し必要に応じて操作を引き継ぎ、AIエージェントはインターフェースの実行結果を効率的に検証しなければならない。

人間によるリモートアクセスは主にVNCプロトコルに依存してmacOSデスクトップを表示し、さらにiOS Simulatorのウィンドウを専用にマッピングした独立ビューパネルを提供する。リアルタイム画面の追従性を十分に保つため、チームは2つの具体的な動画エンジニアリングの詳細に対処した。

バッファ競合の問題：ScreenCaptureKitは有限の再利用可能バッファを使用する。画面を保持する必要がある場合、システムは独立したコピーを複製し、キャプチャシステムが必要とするバッファを継続的に占有することを回避する。

キュー滞留の問題：ビデオのキャプチャ、エンコード、伝送、表示のいずれかの段階で処理が追いつかなくなると、キュー内に古いフレームが滞留し、リモート画面の動作遅延を引き起こす。

無差別なフレームドロップによるデコード異常を防ぐため、システムはキューイング可能なフレーム数の上限を制限した。シミュレータストリーム画面の遅延が検出されると、システムは直近のキーフレーム（keyframe）から復元するか、または新たなキーフレームを要求することで、再生側が滞留した履歴を再再生することなく最新の状態へと同期できるようにしている。

5. アクセシビリティツリー：ネイティブコントロールを検索可能にする

AIエージェントにとって、グラフィカルインターフェースの操作にはより高効率で安定したインタラクション経路が求められる。スクリーンショット（Screenshot）のみに頼るマルチモーダルなアプローチは、記事内で「低速かつ高コスト（slow and expensive）」と表現されている。エージェントは画面全体の画像をキャプチャし、マルチモーダルモデルを通じてボタンのピクセル座標を特定して仮想マウスを呼び出し、操作ごとに再びスクリーンショットを撮って検証しなければならない。長いインタラクション経路を伴うテストにおいて、この方式は極めて大きな負荷となる。

WebにおいてDOMツリーを用いて要素を特定するのと同様に、ネイティブアプリケーションにも基盤となるインフラストラクチャが存在する。それがアクセシビリティツリー（Accessibility Tree）である。システムはインターフェース要素を、役割（role）、名前（name）、値（value）、状態（state）、関係（relationship）、およびサポートされるアクション（actions）を含む構造化されたセマンティックツリーとして整理する。

Dioxusオープンソースプロジェクトのaccessibility-cliを活用することで、システムはアクセシビリティアクセス、入力制御、画面キャプチャといった基本プリミティブ（accessibility、input、capture primitives）を獲得した。Devinはこれに基づき、構造化された操作チェーンを確立した。

エージェントによるiOS Simulator操作のセマンティックループ

1. エージェントが構造化されたコントロールクエリを発行
{
  "action": "query",
  "target": "ios",
  "role": "button",
  "name": "Resume"
}

2. システムがセマンティックツリーのマッチング結果と一時ハンドルを返却
@i17 button "Resume" {press}
（@i17 はハンドル、button は役割、Resume は名前、press はサポートされる操作）

3. エージェントがハンドルを直接指定してアクションを実行
{
  "action": "act",
  "target": "ios",
  "reference": "@i17",
  "operation": "press"
}

4. エージェントがアクセシビリティツリーを再読み込みして状態変化を報告

このツールにより、Devinはピクセル画像からコントロールの座標を推測することなく、セマンティックツリーを通じて直接コントロールを照会・参照して操作を実行できる。

しかし、アクセシビリティツリーがすべての視覚的コンテンツを網羅できるわけではない。例えば、独自描画されたゲーム画面などの視覚的状態はアクセシビリティツリーに反映されないため、システムは依然としてスクリーンショット撮影機能を保持しており、必要に応じてスクリーンショットを組み合わせて完全な状態検証を行っている。

適用限界とエンジニアリング上の示唆

DevinのmacOSサポートは、Appleネイティブアプリのクラウド開発と検証に向けた技術的経路を切り拓いたが、その適用範囲を評価するにあたっては、技術的前提とエンジニアリング上の境界を明確に整理しておく必要がある。

• アクセシビリティツリーはすべての視覚状態を網羅できない：一時停止メニューが消えたことが確認できても、ゲームキャラクターの位置が正しく復元されたことまでは証明できない。直接描画された画面はツリーに一切出現しない場合もあるため、視覚的な結果を照合するには依然としてスクリーンショットが必要となる。
• 定量的なベンチマークの不在：この技術解説はクラウドワークスペースのアーキテクチャと製品機能を説明しているものの、実行性能、インフラコスト、あるいはセキュリティ効果に関する定量的なデータは提示していない。そのため、これに基づいて他の開発環境との効率やコストを比較することはできない。

仮想ディスク、ネットワーク境界、イメージの事前準備から、リアルタイム画面、セマンティックコントロール、スクリーンショットによる検証に至るまで、これらの低レイヤーエンジニアリングがDevinにネイティブアプリのビルドとテストに必要な完全なAppleワークスペースを提供した。単なるコード記述にとどまらず、実際の実行インターフェース内での「開発・実行・検証ループ」へと拡張されたこと。これこそが、DevinがmacOSサポートを獲得したことによる最も本質的な変化である。