AIエージェント入門

DevinがmacOS対応｜できること・設定・注意点【2026年9月】

22分で読める
DevinがmacOS対応｜できること・設定・注意点【2026年9月】

この記事の結論

DevinのmacOS対応（2026年9月15日発表）を公式ドキュメントで整理。クラウドMac VMでできること、blueprintの設定手順、TestFlight連携、料金と制限、既存のDevin運用との違いまで。

「DevinがmacOSに対応した」と聞いて、手元のMacをDevinが操作してくれるようになったのか——と受け取った人が多いのではないでしょうか。答えは違います。動くのはDevin Cloud側に用意されたmacOSの仮想マシンで、あなたのMacではありません。Cognitionは2026年9月15日（現地時間）付の公式ブログでこれを発表し、DevinはクラウドのMac VMでXcodeを叩き、iOSシミュレータでアプリを起動し、実際にタップして動作を確認し、TestFlightへ上げるところまでを担当します。2026年9月24日時点の公式ドキュメントでは、Pro / Teamsプランは既定で利用可能、Enterprise・Dedicated SaaSはアカウントチームに有効化を依頼する扱いです。

以下は発表の要約ではなく、「自分のリポジトリでmacOSセッションを動かすには何を書けばいいか」を公式ドキュメントの記述だけで組み立てた手順です。

  • 発表日：2026年9月15日（現地時間、Cognition公式ブログ）。日本法人名義のプレスリリースは9月18日付
  • 実行場所：Devin Cloud内のmacOS VM（AWS EC2 Macのベアメタルホスト上、Apple Virtualization.framework）
  • 入口：プロンプト欄下のプラットフォームメニュー、blueprintのruns-on: macos、Slackの!mac、APIのplatform: "macos"
  • 課金：macOSセッションはLinux同等の消費で追加料金なし。ただし公式に「promotional launch pricing」と明記され、変更があり得る
  • できないこと：実機のiPhone/iPadでのテスト（USBパススルーなし）、実用速度でのDocker、Instrumentsによる実機相当の性能計測

「Devinに自分のMacを渡した」わけではない — 何が増えたのか

「Devinに自分のMacを渡した」わけではない — 何が増えたのか
「Devinに自分のMacを渡した」わけではない — 何が増えたのか

今回増えたのは、Devinが使えるワークスペースの種類です。従来のDevin CloudはLinuxとWindowsのVMを提供していましたが、そこにmacOSが加わりました。公式ブログのタイトルが「Bringing macOS to Devin」であるとおり、Devinの側にMacを用意した、という構図です。

なぜクラウドにMacが要るのか。公式ブログはiPhoneゲームを例に説明しています。Swiftを書いてコンパイルを通すだけなら多くのエージェントがすでにできますが、「アプリを閉じても中断した場所から再開する」という仕様が満たされているかを確かめるには、実際に遊んで、一時停止して、終了して、起動し直して、再開できているかを見る必要があります。コンパイルが通ることと動くことは別物で、この検証ループをクラウドで閉じるためにMac環境そのものが要った、という説明です。

できるようになったこと／ならないこと

観点 2026年9月時点の状態
iOS / iPadOS / macOSアプリのビルド 可能。Xcodeとシミュレータが入ったmacOS VMでxcodebuildを実行
シミュレータ上での動作確認 可能。DevinがiOSシミュレータを起動して操作し、録画を共有できる
TestFlightへのアップロード 可能。App Store Connect APIキーをDevinのシークレットに登録した場合に限る
実機のiPhone / iPadでのテスト 不可。USBパススルーがないためシミュレータのみ
あなたのMacをDevinが直接操作する Devin Cloudでは不可。自社マシンで動かしたい場合はOutpostsまたはDevin CLIが別系統として存在する
コンテナ（Docker）を使うビルド 動くが実用性は低い。ネステッドのハードウェア仮想化がなく、ソフトウェアエミュレーションになる

裏側の作りも公式ブログが細かく書いています。VMはAWS EC2 Macのベアメタルホスト上でAppleのVirtualization.frameworkによって起動し、Linuxで使っていたvhost-userが使えないためNBD（Network Block Device）のフロントエンドを既存のスナップショット基盤に追加した、という経緯が説明されています。ネットワークもApple管理のNATではなく、ARP応答から自前で処理するユーザー空間のEthernetゲートウェイを実装し、セッションごとのアクセスルールをpfで維持しています。

UIの見方も変わりました。スクリーンショットを撮って座標をクリックする素朴な往復は、一時停止・終了・再起動を繰り返す検証ではコストに見合いません。そこでCognitionは、支援技術向けのアクセシビリティツリーをDevinのcomputer-useツールに公開しました。コントロールをロール・名前・値・状態で問い合わせ、返ってきた参照に対して操作し、もう一度ツリーを読んで変化を報告する、という流れです（基盤にはDioxusのオープンソース実装accessibility-cliを使用）。ゲーム画面のように直接描画される領域はツリーに出ないため、スクリーンショットと併用する、と役割分担も明記されています。利用者側にはMacデスクトップのVNCに加えてiOSシミュレータ専用のペインが新設され、Devinがアプリをタップする様子をリアルタイムに見られます。なお、DevinはmacOSのショートカットにControlではなく⌘キーを使います。

この「セッションごとのアクセスルールを維持したまま外に出す」という設計思想は、Devinのセキュリティプロファイル・PATがGAになったときの方向性と地続きです。macOSワークスペースでも同じ統制の考え方が引き継がれている、と読むのが自然でしょう。

混同しやすい3つの「DevinとMac」を切り分ける

混同しやすい3つの「DevinとMac」を切り分ける
混同しやすい3つの「DevinとMac」を切り分ける

「Devin macOS 対応」で検索した人がたどり着く先には、実は性質の違うものが3つ並んでいます。既存のDevin運用との違いを判断するうえで、ここが一番の分かれ目です。

形態 コードが動く場所 Macの用意 向いている用途
Devin Cloud の macOSセッション（今回の発表） Cognition側のクラウドMac VM 不要 iOS / macOSアプリの自律開発・シミュレータ検証・TestFlight配信
Devin CLI あなたのMacのターミナル 自分のMac 手元のリポジトリで対話的に作業し、必要に応じてクラウドへハンドオフ
Devin Outposts 自社が管理するマシン（机上のMac miniも可） 自社で用意・運用 ソースや資格情報を自社インフラから出したくないケース

Devin CLIはcurl -fsSL PH_1_ | bashまたはHomebrewのbrew install --cask devin-cliで入れる、macOS / Linux / WSL / Windows対応のローカルエージェントです。こちらは以前からMacで動いていました。「前からMacで使えていたのでは」という違和感はここに由来します。

Outpostsは、推論とプランニングのエージェントループをDevinのクラウドに残したまま、コマンド実行・ファイル編集・リポジトリアクセスを自社マシン側で行う方式です。macOSマシンをOutpostにする場合は既存のデスクトップセッションを使うため、ワーカーを起動するプロセスに画面収録とアクセシビリティの2つのTCC権限が必要になります（管理端末ならMDMのPPPCプロファイルで事前承認可）。

もうひとつ、Xcode 26.6以降のコーディングアシスタントにDevin CLIをカスタムエージェント（Agent Client Protocol対応）として登録する経路もあります。コマンドにはwhich devinで得た絶対パス、引数にはacpを指定します。~始まりのパスは展開されないと明記されているので、/Users/…の形で書きます。

macOSセッションの始め方は4通りある

macOSセッションの始め方は4通りある
macOSセッションの始め方は4通りある

最短経路は、Devinのプロンプトボックス下にあるプラットフォームメニューからmacOSを選ぶことです。公式チュートリアルはこの状態で「build a flappy otter game for iphone」とだけ打つ例を載せています。Xcode、iOSシミュレータ、Homebrewはイメージに入っているため、セットアップ待ちは発生しません。

継続的に使うなら、リポジトリのblueprintに書いてしまうのが本筋です。macOSサポートはLinuxと同じ宣言的設定の仕組みの上に載っており、runs-onフィールドがプラットフォームを決め、プラットフォームごとに別のスナップショットが作られます。

runs-on: macos

initialize:
  - name: "Install build tooling"
    run: |
      brew install xcodegen swiftlint xcbeautify

maintenance: |
  xcodebuild -resolvePackageDependencies -project MyApp.xcodeproj -scheme MyApp

knowledge:
  - name: build
    contents: xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 17' build
  - name: test
    contents: xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 17' test
  - name: lint
    contents: swiftlint

Web側とiOS側が同居しているリポジトリなら、YAMLドキュメントを---で区切って複数プラットフォームを並べます。トップレベルはマッピングでなければならず、- runs-on: defaultのようにシーケンス（リスト）で書くとバックエンドに拒否される、という注意がドキュメントに明示されています。

runs-on: default
initialize: |
  apt-get update && apt-get install -y build-essential

maintenance: |
  npm install

knowledge:
  - name: test
    contents: npm test

---
runs-on: macos
initialize: |
  brew install cocoapods

maintenance: |
  npm install
  (cd ios && pod install)

knowledge:
  - name: test
    contents: npm test

残りの2通りは運用向けです。Slack連携を使っているチームはbangコマンドの!macでmacOS VM上のセッションを開始でき、自動化に組み込むならセッション・スケジュール・オートメーション作成時にplatform: "macos"を指定します。runs-onの値はdefault（＝linux）、macos、windowsの3つ。runs-on: [default, macos]というリスト表記は同一コマンドを両方で実行する指定なので、apt-getとbrewが混ざる場合には使えません。

プリインストールされているもの、Linux用blueprintから移すときにズレるもの

プリインストールされているもの、Linux用blueprintから移すときにズレるもの
プリインストールされているもの、Linux用blueprintから移すときにズレるもの

macOSセッションのイメージには、Appleのツールチェーンが最初から入っています。blueprintでXcodeを落としにいく設定を書くと数ギガバイトのダウンロードとApple IDの入力を毎回引き受けることになるため、ドキュメントは「必要がない限りblueprintでXcodeを入れるな」と明確に書いています。

カテゴリ 含まれるもの（2026年9月時点のドキュメント記載）
Xcode Xcode 26系の最新リリースが既定（/Applications/Xcode.app）、加えてXcode 27のプレリリースが併置（例：/Applications/Xcode-27.0-RC.app）
シミュレータ インストール済みXcodeごとに1つのiOSシミュレータランタイム（iOS 26 / iOS 27）。iPhoneデバイスが設定済み
Appleツール xcodebuild、xcrun、simctl、Swift、Metalツールチェーン
パッケージ管理 Homebrew（/opt/homebrew）
言語 Node.js、Python、Java、Rust（npm / yarn / pnpm）
CLI git、git-lfs、gh、jq、ripgrep、ffmpeg、wget、direnv
ブラウザ Google Chrome

バージョンはAppleのリリースに合わせて動くため、固定値として扱わないのが安全です。実際のセッションの中身はsw_vers・xcodebuild -version・xcrun simctl list runtimesをDevinに実行させれば確認できます。

複数のXcodeが同居しているので、どれを使うかは明示したほうが事故りません。単発ならDEVELOPER_DIR、セッション全体ならxcode-selectです。罠が一つあり、DEVELOPER_DIRを尊重するのは/usr/bin/xcodebuildのシムのほうで、特定Xcode配下から解決されたxcodebuildは自分のバージョンを報告します。

# 単発で別バージョンを使う（/usr/bin/xcodebuild を明示するのがポイント）
DEVELOPER_DIR=/Applications/Xcode-27.0-RC.app/Contents/Developer /usr/bin/xcodebuild -version

# セッション全体の既定を切り替える
sudo xcode-select -s /Applications/Xcode-27.0-RC.app

Linux用のblueprintをそのまま持ってくると、次の差分でつまずきます。ホームは/home/ubuntuではなく/Users/devin、リポジトリは/Users/devin/repos/<repo-name>、添付は/Users/devin/.files/。シェルはzsh、パッケージマネージャはbrewです。BSD系ユーザーランドのためsed -iは引数が要り（sed -i ''）、gsedやgdateはHomebrewのcoreutilsから入れます。

コールドビルドの遅さ対策も公式が推奨しています。maintenanceにxcodebuild -resolvePackageDependenciesとbuild-for-testing、さらにxcrun simctl boot "iPhone 17" || trueを入れておくと、解決済みのSwift PackageやCocoaPods、DerivedDataがスナップショットに残り、次のセッションが増分ビルドから始まります。スナップショット再構築直後のビルドが極端に遅いときは、ここが抜けていることを疑ってください。

スリープ時はディスクへスナップショットが取られるため、ツール・リポジトリ・ビルドキャッシュ・DerivedDataは復帰後も残ります。一方で実行中のプロセスは残りません。開発サーバ、シミュレータ、ファイル監視は起き直したあとに再起動が必要です。

TestFlightまで通すなら、先に決めるのは「鍵の置き場所」

TestFlightまで通すなら、先に決めるのは「鍵の置き場所」
TestFlightまで通すなら、先に決めるのは「鍵の置き場所」

ビルドしたアプリを実機で確認したい場合の出口がTestFlightです。ここはDevinが勝手に整えられない領域で、公式も「多くはAccount HolderかAdminの操作で、個人のApple Accountの二要素認証が要るものもあるため代行できない」と書いています。前提は有料のApple Developer Programメンバーシップ、所要時間の目安は2〜10分とされています。

人間側で先に済ませるのは、(1) App Store Connectで保留中の契約への同意、(2) アプリターゲットと一致するバンドルIDの登録、(3) アプリレコードの作成、(4) ベータグループの作成、(5) 輸出コンプライアンスへの回答、の5点です。5番目はInfo.plistにITSAppUsesNonExemptEncryptionを設定しておけばビルドごとの質問を省けます。

そのうえでDevin側に登録するシークレットは4本です。

シークレット名 中身 取得場所
ASC_KEY_ID キーID App Store Connect → Users and Access → Integrations → App Store Connect API
ASC_ISSUER_ID Issuer ID（UUID） 同じページのキー一覧の上部
ASC_PRIVATE_KEY AuthKey_<KEY_ID>.p8の全文（BEGIN/END行を含む） キー作成時に一度だけダウンロードできるファイル
APPLE_TEAM_ID 10文字のTeam ID Apple Developerポータル → Membership details

APIキーはチームキーとしてApp Managerロールで作成します（生成操作自体にはAdminロールが必要）。最重要の注意は.p8の扱いです。ドキュメントは「このファイルを持つ者は、そのチームのすべてのアプリについてビルドのアップロードとTestFlightの管理ができる」と警告し、Devinのシークレットにのみ保存してリポジトリにコミットしないよう求めています。ダウンロードはApple側で一度しかできず、紛失したら失効させて作り直すしかありません。

シークレットは$SECRET_NAMEの形で使えますが、全シェルにexportされるのではなく必要なコマンドにバインドされる仕組みです。スコープは組織単位と個人単位から選びます。

アップロードを頼むときの指示は自然文で構いません。公式ドキュメントの例は「MyAppスキームをアーカイブしてTestFlightにアップロードし、App Store Connectの最新ビルドより大きいビルド番号を使い、QAグループに追加して、終わったらビルド番号を教えて」という内容です。

DevinはASC_PRIVATE_KEYを~/.appstoreconnect/private_keys/AuthKey_$ASC_KEY_ID.p8へ0600で書き出し、APIで最新ビルド番号を調べ、アーカイブ、署名とアップロード、処理完了後にベータグループへ追加、という順で進めます。実行されるコマンドも公式に公開されています。

xcodebuild -project MyApp.xcodeproj -scheme MyApp \
  -configuration Release -destination 'generic/platform=iOS' \
  -archivePath build/MyApp.xcarchive \
  CURRENT_PROJECT_VERSION=<build-number> archive

xcodebuild -exportArchive \
  -archivePath build/MyApp.xcarchive \
  -exportOptionsPlist ExportOptions.plist \
  -exportPath build/export \
  -allowProvisioningUpdates \
  -authenticationKeyID "$ASC_KEY_ID" \
  -authenticationKeyIssuerID "$ASC_ISSUER_ID" \
  -authenticationKeyPath ~/.appstoreconnect/private_keys/AuthKey_$ASC_KEY_ID.p8

-allowProvisioningUpdatesにより、配布証明書とプロビジョニングプロファイルをAPIキー経由でXcodeに作らせられます。手順を毎回書くのが面倒なら、blueprintのknowledgeに書いておけます。

ネットワーク制限をかけている組織は、macOS VMからAppleのサーバーへ到達できるようにしておきます（*.apple.comの許可でカバー）。厄介なのは、ブロックされたホストがネットワークエラーではなく認証エラーとして現れる点です。No Accounts with App Store Connect Accessが出たらまずネットワークを疑い、直前の行にITunesConnectFoundationErrorDomain Code=-1003がないか見るよう公式は案内しています。

料金・プラン・制限 — 導入前に確認しておく3点

まず料金です。2026年9月時点で、macOSセッションは同等のLinuxセッションと同じ使用量を消費し、macOSサーチャージはありません。ただしドキュメントには「promotional launch pricingであり変更される可能性がある」と明記されています。Macのベアメタルホストを使う構成である以上、この条件が恒久的だと前提を置いた社内計画は立てないほうが無難です。アイドル30分でスリープし、その間は使用量を消費しません（Enterpriseは5〜120分に調整可）。

次にプランです。自己申込はFree、Pro（月20ドル）、Max（月200ドル）、Teams（月80ドル下限・最大200人）の4種類で、価格の正本は公式の料金ページ側にあります。iOSアプリ構築チュートリアルの前提条件は次のように分かれています。

プラン macOSセッションの扱い
Pro / Teams 既定で利用可能
Enterprise アカウントチームにmacOS VMの有効化を依頼し、さらに設定でComputer useをオンにする
Dedicated SaaS アカウントチームに連絡してmacOS VMを有効化

最後に制限です。ここを読み飛ばすと、導入してから気づくことになります。

制限 内容
Docker / コンテナ ネステッドのハードウェア仮想化がないため、コンテナはソフトウェアエミュレーション（QEMUのTCG）で動く
物理デバイス USBパススルーがないため、実機のiPhone / iPadではなくシミュレータでテストする
Xcodeの追加取得 別のXcodeやシミュレータランタイムを取りにいくにはApple IDの資格情報と長いダウンロードが必要
性能計測 VM内のInstrumentsによる計測は実機性能を代表しない

コンテナについては数字まで示されています。Colimaは仮想化が使えないことを検出して自動でエミュレーションに切り替わりますが、使える状態になるまで2〜4分かかり、コンテナ内のCPU実行はネイティブのおおよそ15〜25倍遅い——リンタやパッケージングなら許容できてもコンパイルには厳しい、というのが公式の評価です。コンテナ中心の処理はLinuxセッションに寄せるか、リモートのDockerデーモンを指す構成にする、と案内されています。

つまずきやすいポイントと、その回避

公式ドキュメントのトラブルシューティングと注意書きから、実際に起こりやすい形にまとめます。

❌ Linux用のblueprintのruns-onだけをmacosに書き換える
apt-getや/home/ubuntuがそのまま残っていると初期化で失敗します。
⭕ シェル（zsh）、パス（/Users/devin）、パッケージマネージャ（brew）、BSDのsed -i ''まで含めて書き換える。 Web側とiOS側が同居するなら、---で区切ったマルチドキュメントで別々に書く。

❌ プラットフォームを列挙すれば両対応になると考える
runs-on: [default, macos]は同じコマンドを両方で走らせる指定です。プラットフォーム固有のコマンドが混ざると片方が必ず壊れます。
⭕ 真にクロスプラットフォームなコマンド（npm installなど）だけリスト表記を使い、それ以外はマルチドキュメント形式にする。

❌ ビルドが途中で依存解決に失敗するのをネットワークの一時不調として片付ける
macOSの許可リストはLinuxとは別に設定されます。Linuxで通っていたCocoaPods、Swift Package Manager、Firebase、プライベートレジストリのホストがmacOS側で抜けていると、依存解決やTLSの失敗として顕在化します。
⭕ macOSの許可リストにLinuxと同じレジストリが入っているかを最初に照合する。 TestFlightを使うなら*.apple.comも忘れずに。

よくある質問

Devinの料金はmacOS対応で上がりますか？

2026年9月時点では上がりません。公式ドキュメントはmacOSセッションが同等のLinuxセッションと同じ使用量を消費し、macOSサーチャージはないと明記しています。ただし同じ箇所に「promotional launch pricingであり変更される可能性がある」という注記が付いています。

どのプランで使えますか？

公式チュートリアルの前提条件では、Pro / Teamsは既定で利用可能です。Enterpriseはアカウントチームに依頼してmacOS VMを有効化し、設定でComputer useをオンにする必要があります。Dedicated SaaSの場合もアカウントチームへの連絡が案内されています。

手元のMacをDevinに操作させられますか？

今回のDevin Cloudの機能ではできません。自社が管理するマシンで動かしたい場合はDevin Outpostsが該当し、机上のMac miniのような構成も想定されています（画面収録とアクセシビリティのTCC権限、録画にはffmpegが必要）。ターミナルで対話的に使いたいだけなら、以前からmacOSで動くDevin CLIがあります。

Cognitionからの直近のアップデートは他にありますか？

公式リリースノートによれば、2026年9月21日にCognitionの次世代ソフトウェアエンジニアリングモデル「SWE-2」がリサーチプレビューとしてエージェントセレクタに追加されています（Slackでは!swe2）。リサーチプレビューのため挙動と提供範囲は変わり得る、と注記されています。モデル世代の流れはDevin SWE-1.7の解説記事と合わせて追うと把握しやすいはずです。

結論

今回のアップデートを一言でまとめるなら、「Appleの開発ツールに依存するから自動化できない」という最後の砦が、クラウド側のMacで埋められたということです。Swiftを書けるエージェントは前からありましたが、シミュレータで遊んで確かめ、録画を添えて報告し、TestFlightまで運ぶところを1本のセッションで閉じられるのは新しい段階です。

一方で、実機テストができない、コンテナが実用速度で動かない、現在の価格はプロモーションである、という3点は導入判断にそのまま効きます。Devinの全体像と導入手順を押さえたうえで、既存のiOSリポジトリにruns-on: macosのblueprintを1本追加し、buildとtestのknowledgeだけ書いて1セッション動かすのが、いちばん少ない手数で判断材料が揃う進め方でしょう。

チームに広げる段階では、macOS側のネットワーク許可リストがLinux側と揃っているか、App Store Connectの.p8をDevinのシークレット以外に置いていないか、この2点を先に固めてください。鍵の置き場所は、あとから直すのがいちばん高くつきます。

運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）

参考・出典

あわせて読みたい

この記事を読んで導入イメージが固まってきた方へ

UravationではAIエージェント導入の研修・コンサルを行っています。

著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。著書『AIエージェント仕事術』。

あわせて読みたい

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

30分無料相談を予約 支援実績を見る

この記事をシェア

X Facebook LINE

※ 本記事の情報は2026年9月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

関連記事

worktrunkとは｜git worktree管理CLIの使い方【2026年9月】 AIエージェント入門

worktrunkとは｜git worktree管理CLIの使い方【2026年9月】

worktrunkは並列AIエージェント向けのgit worktree管理CLI...

27分で読める
WeKnora導入手順｜Tencent製RAG基盤をDockerで【2026年9月】 AIエージェント入門

WeKnora導入手順｜Tencent製RAG基盤をDockerで【2026年9月】

TencentがMITで公開するRAG基盤WeKnoraの導入手順。Docker...

27分で読める
Kevとは｜Jev風オープン判断モデルをローカルで動かす【2026年9月】 AIエージェント入門

Kevとは｜Jev風オープン判断モデルをローカルで動かす【2026年9月】

Kevは、Jevと同じSystem One APIを自分のマシンで動かせるオープ...

26分で読める