Devinがクラウド上の「自分のMac」でiPhoneアプリを検証できるように

WindowsやLinuxでiPhoneアプリのコードを書いていて、Macが無いせいで「本当に動くか」を確認できず止まった経験はないだろうか。AIエージェント開発企業のCognitionは2026年9月15日、自社のエージェント「Devin」の新機能を発表した。クラウド上に「自分のMac」を持ち、実機なしでiPhone・macOSアプリを実際に動かして確認できるようになった(公式ブログ)。動作確認だけでなく、TestFlightへのベータ配信まで任せられるという。実機なしで、いったいどこまで確認できるようになったのか。

コンパイルは動作確認と別物

Swiftのコードをコンパイルするだけなら、Macが無くてもできる作業は多い。しかし公式ブログが例に挙げるのは、もう一段先の確認だ。一時停止できるiPhoneゲームを作ったとき、アプリを完全に終了してから起動し直しても、続きから正しく再開するか。これを確かめるには、実際にアプリを起動し、操作し、終了し、また起動するという一連の動きをiPhone(またはそのシミュレータ)の上で再現する必要がある。コンパイルが通ることと、実際に正しく動くことは別の問題だ。

これまでDevinはLinuxとWindowsの仮想環境をクラウドに持っていたが、Macは無かった。iPhoneアプリの実行にはiOSシミュレータが要り、シミュレータを動かすにはmacOSそのものが要る。ここでMacを持たない開発者は足止めされていた。

実機MacはAWSから借りる

Devinの「自分のMac」は、ただクラウド上の仮想マシンにmacOSを入れただけのものではない。AppleのソフトウェアライセンスはmacOSの実行をApple製ハードウェアに限っており、任意のクラウドサーバーでmacOSを動かすことを認めていないからだ。Broadcom(旧VMware)のナレッジベースは、AppleのmacOS用ライセンス契約について「インストールと実行をApple製のコンピュータに法的に限定している」と説明する。

この制約があるため、Cognitionが選んだのはAWSが提供する「EC2 Mac」だった。実機のMacを用意する仕組みは、二段構えになっている(公式ブログ)。

• 土台: データセンターにあるApple製の実機Mac(AWS EC2 Macが提供するベアメタルのMacホスト)を、ネットワーク経由で1台単位で借りる
• その上: 実機の中で、Apple純正の仮想化基盤「Virtualization.framework」を使ってmacOSのゲスト環境を動かす

この実機縛りの重さはAWS自身の説明にも表れている。EC2 Macは秒単位の課金でありながら、「Appleの macOS ソフトウェア使用許諾契約を守るため」に24時間の最低確保時間を設けている。

土台から環境を作り直す

実機のMacを確保できても、それだけではDevinの開発環境にならない。Devinのクラウド作業は非同期が前提で、ユーザーがつきっきりで見ている必要はなく、放置中の仮想マシンも動かしっぱなしにしない。そのために必要なのが、作業内容を保存して後から同じ状態に戻れる仕組みと、セッションの通信を制限するネットワーク管理だ。今回はこの2つを、AppleのVirtualization.frameworkの上で作り直す必要があった。

ディスクはNBDで接続する

DevinはLinuxの仮想マシンで、ディスクの読み書きをvhost-userという方法で別プロセス(スナップショットの保存先)へつないでいる。ところがAppleのVirtualization.frameworkは、このvhost-userに対応していない。

代わりに使えたのが「Network Block Device(NBD)」という、ディスクを読み書きするための別の接続方法だった。Cognitionは既存のスナップショットの仕組みはそのままに、macOS向けにNBDでつなぐ入り口だけを新しく実装した(公式ブログ)。

NATを避け自前で処理する

ネットワークはもっと入り組んでいた。Appleの仮想化基盤には、仮想マシンをネットにつなぐ方法が複数用意されており、一番簡単なのはmacOSにおまかせの「NAT」だ。ところがこのNATは、macOSのパケットフィルタpfの設定を自動で書き換える。Devin自身のアクセス制御も同じpfを使っているため、両者が同じ設定を取り合う形になってしまう。

そこでCognitionは、あえて簡単な方法を捨てた。生のEthernetフレームをやり取りする低レベルな接続方式を選んだ。ARP応答やアドレスの検証もすべて自前で処理する「独自のEthernetゲートウェイ」を実装している(公式ブログ)。

実機のMacさえ確保すれば大部分は使い回せるだろうと自分は考えていた。Apple製のハードウェアを使っていても、Apple謹製の仕組みにそのまま乗れるとは限らない。ここが今回調べていて一番意外だった点だ。

本当に動いたかをどう確かめるか

環境が整ったあと、アプリのボタンを押して期待どおり反応したかを、Devinはどう確認しているのか。

一番単純な方法は、次の繰り返しになる。

1. 画面をスクリーンショットで撮る
2. AIモデルに「一時停止ボタンはどこか」を画像から推測させる
3. 推測した座標をクリックする
4. また撮り直して、反応したかを確かめる

公式ブログはこの方法を「素朴だが、遅く高くつく」と位置づけている(公式ブログ)。ボタンを探すたびに画像を処理し直す必要があり、一時停止・終了・再起動という一連の動きを何度も検証するには向かない。

Devinが使うのは、この画像頼みの方法ではない。スマートフォンの読み上げ機能のような支援技術のために、アプリ側があらかじめ公開している「アクセシビリティツリー」という構造だ。ボタン1つひとつに、役割(ロール)・名前・現在の状態・実行できる操作が情報として付いている。Devinはこの構造に対して「role=ボタン、name=Resume」という条件で直接問い合わせ、返ってきた参照先に対して「押す」という操作を実行する。名前とロールでボタンを名指しできるので、座標のズレや見落としに左右されず、一時停止・終了・再起動という一連の確認を何度でも素早く繰り返せる。

もっとも、アクセシビリティツリーにすべての情報があるわけではない。ゲーム画面の見た目のように、構造情報を持たず直接描画されている部分もある。そのためDevinは、アクセシビリティツリーによる操作と、見た目を確かめるスクリーンショットを両方使い分けている(公式ブログ)。

まとめ

Macを持たない開発者でも、コンパイルの先にある「実際に動くか」の確認と、TestFlightへの配信までをDevinに任せられるようになった。その裏には土台からの作り直しがあった。AppleのライセンスでクラウドVMが使えないため、AWSの実機Macを借りている。ディスクの接続方法をmacOS向けに新しく実装し、ネットワークもApple純正のNATを避けて自前のEthernetゲートウェイを構築している。

動作確認そのものも、画像頼みの遅い方法ではなく、アプリが公開するアクセシビリティツリーを使って名前とロールでボタンを直接指定する方式に変えている。2026年9月17日時点で、macOS対応に伴う追加料金や対象プランの限定は公式に明記されていない。Devin自体は無料枠のほか、月20ドルのProプランなどが用意されている(料金ページ)。試すにはdevin.aiで実際のプラン内容を確認するとよい。