vphone-cliでMacに仮想iPhoneを構築する方法と前提条件

「Apple Silicon Mac の上で iPhone が動く」という話題を見かけて、自分の環境でも試せるのかを調べ始めた方は多いはずです。実機を増やさずに iOS のシステム挙動を追えるなら、検証環境の作り方そのものが変わります。

ところが調べ始めると、情報がきれいに噛み合いません。「脱獄済みの状態で起動して Sileo や TrollStore がそのまま使える」と書く記事がある一方で、公式のガイドを開くと「それらは導入しない」と明記されています。必要なホスト設定についても、SIP を完全に無効にすると書くものと、有効のまま一部制限だけを緩めると書くものが混在しています。どれが現行の仕様なのかが判別できないまま、判断が止まってしまいます。

食い違いの原因の多くは、バージョンの違いにあります。このプロジェクトは 2026 年に入ってからメジャーバージョンが上がっており、1.x 時点の記述を前提にした二次情報が、そのまま現行の説明として流通している状態です。採用可否を決めるには、公式ドキュメントが現時点で何を要求し、何を提供しないと言っているのかを直接押さえるのが近道です。

判断の分かれ目は、機能の多寡ではありません。「物理の Apple Silicon Mac を 1 台占有できるか」「ホストのセキュリティ設定を緩める判断を自組織で下せるか」「検証したい端末が対応範囲に入っているか」という 3 点です。この 3 点のいずれかが成立しないなら、機能をどれだけ読み込んでも導入には至りません。

本記事では、vphone-cli の README と Documents/Guides 配下の公式ガイド、リポジトリ内の調査ノート、および Apple の公式ドキュメントをもとに、仕組み・前提条件・対応範囲・構築手順・類似 OSS との違いを整理します。インストールや実行、環境構築は行っておらず、記述はすべて公開ドキュメントの読解に基づくものです。数値は 2026 年 9 月時点の公開値です。

vphone-cliとは｜Apple Silicon Macで仮想iPhoneを動かすOSS

vphone-cli は、Apple Silicon Mac 上に「仮想 iPhone」を作成・実行するための CLI とアプリの集合です。README は、Apple の Virtualization.framework と PCC（Private Cloud Compute）研究用 VM 基盤を利用して仮想 iPhone を動かすツールであると説明しています（README）。

重要なのは、これがアプリ層のシミュレータではないという点です。iOS のカーネルを起動させるため、ファームウェア（IPSW）の準備・パッチ・DFU 復元までを一連のパイプラインとして扱います。この性質が、後述する前提条件の重さに直結します。

なお、公式には日本語の README も用意されています（日本語 README）。ただし日本語版は概要とクイックスタートのみで、詳細な手順は Documents/Guides 配下が正であると明記されています。更新点を 1 箇所に集約する方針であるため、判断材料として読むべきは Guides 側です。

リポジトリの基本情報とメンテナンス状況

採用を検討する前に、まずプロジェクトの規模と鮮度を押さえます。以下はいずれも 2026 年 9 月時点の値です。

このリポジトリはアーカイブされておらず、他リポジトリのフォークでもありません（archived と fork はいずれも false）。ライセンスは MIT が設定されています。作成から約 7 か月でスター 14,541 に達しており、直近でも 2.0.5 から 2.0.8 までのリリースが同日中に複数出るペースで更新されています。少なくとも「公開したまま放置されているリポジトリ」ではない、という点は客観的に確認できます。

一方で、プロジェクト自体が 2026 年 2 月に始まったばかりである点は評価に入れる必要があります。オープン Issue が 31 件あることと合わせ、仕様が今後も動きうる前提で扱うのが妥当です。

2.xで何が変わったか

現行の 2.x は、1.x から設計方針が変わっています。README によると、以前は実験扱いだったものを含むファームウェアの完全なパッチセットを常に適用する方式になり、パッチ構成をユーザーが選ぶことはできなくなりました。ファームウェアの準備・復元・VM 制御は自己完結した VPhone.bundle が担い、GUI アプリの vphone-launchpad が bundle のインストールと VM 作成を案内します。

VM の形式も変わりました。互換性ガイドは、v2.0.0 以降は schemaVersion=2 の VM のみ起動可能であり、旧バージョンで作成した VM は vm create で作り直す必要がある（in-place アップグレードはない）と記載しています。

この変更を把握していないと、1.x 前提で書かれた記事の手順をそのままなぞることになります。冒頭で触れた情報の食い違いは、ここを起点に発生しています。

仮想iPhoneが動く仕組み｜Virtualization.frameworkとPCC研究用VM基盤

なぜホスト側のセキュリティ設定を変える必要があるのか。それを理解するには、このツールが何の上に載っているかを押さえるのが先です。

Apple公式フレームワークの上に何を足しているか

土台は Apple 公式の Virtualization framework です。macOS 上で VM を構成・実行するための API 群で、通常は macOS や Linux のゲストを動かす用途で使われます。

vphone-cli はこのフレームワークに加えて、Apple が Private Cloud Compute 向けに提供している研究用 VM 基盤（research guest）を利用します。Apple は PCC の Virtual Research Environment のドキュメントで、この基盤を有効化するために csrutil allow-research-guests enable を実行する必要があると説明しており、あわせてこの設定がハードウェア機能への追加的なアクセスを許可し、攻撃面を広げうる旨も記載しています。

つまり vphone-cli は、Apple が研究目的で用意した仮想化の枠組みを、iPhone のファームウェアを起動する土台として転用している構成です。ホスト設定の変更を求めるのは、このツール独自の要求ではなく、その基盤自体が要求している条件だと理解すると筋が通ります。

ゲストに何を見せているのかは、リポジトリ内の参照実装から読み取れます。Research/VPhoneVirtualMachineRefactored.swift では、SEP コプロセッサ（_VZSEPCoprocessorConfiguration）、合成バッテリー（_VZMacSyntheticBatterySource）、USB タッチスクリーン（_VZUSBTouchScreenConfiguration）、PL011 シリアルポート（_VZPL011SerialPortConfiguration）が順に構成されています。iOS が前提とする周辺機器を仮想ハードウェアとして揃える設計だと分かります。ただし Research/README.md はこのディレクトリを「根拠（evidence）を置く場所であり、現行の手順は user guides を参照すること」と注記しているため、ここでは設計上の事実提示に留め、手順や動作の保証としては扱いません。

二次情報の位置づけも整理しておきます。技術メディアの InfoQ は、このプロジェクトがエミュレーションではなく Virtualization.framework を基盤としていること、wh1te4ever による先行研究を土台にしていること、ファームウェアのダウンロードからブートチェーンへのパッチ・DFU 復元・初回ブートまでを自動化すること、そして PCC の Virtual Research Environment に含まれるコンポーネントを利用していることを報じています。あわせて、Apple が自社 iOS ファームウェアのこうした利用を公式にサポートしているわけではない点にも触れています（InfoQ, 2026年9月）。本記事では二次情報をこの範囲でのみ参照し、実装の詳細や性能・安定性の根拠としては扱いません。

ホスト側4コンポーネントの役割分担

README は、ビルド成果物が複数のバイナリに分かれていることと、その意図を説明しています。

ホスト設定ガイドは、署名済みの vphone-vm が Apple 非公開の仮想化エンタイトルメントを持つ一方、エンタイトルメントを持たない vphone-cli はホストに拒否された場合でも有用なエラーを表示できると説明しています。特権が必要な部分を 1 つのバイナリに閉じ込め、入口のコマンドは特権なしで動かす、という分割です。

この分割を知っておくと、後述する「ビルドし直すたびに許可をやり直す」という運用上の制約が、どのバイナリに対する話なのかを取り違えずに済みます。

VM作成パイプラインの流れ

VM 作成ガイドによると、vm create は prepare → firmware patch → online DFU restore → ホストマウントによる CFW インストール → 初回 GUI ブート、という段階で進みます。復元チケットの取得のためネットワーク接続が必須で、CFW インストールには root 権限が必要です。

前段の fw prepare では、一時的な VM を DFU で起動して cloudOS の IPSW を復元し、復元された System ボリュームを読み取り専用でマウントして GPU バンドルを抽出したうえで、その一時 VM を削除します。抽出したバンドルは --gpu-driver-bundle で再利用できるため、2 回目以降は一時復元を省略できます。

「単に VM を起動するだけ」ではなく、ファームウェアの復元を 2 回分こなす処理系である点が、所要時間とディスク消費の実像を決めています。

構築の前提条件｜ハードウェア・macOS・SIP/AMFI設定

ここが本記事で最も判断に効く部分です。ここで挙げる条件のいずれかが成立しない場合、機能面の検討に進む意味はほとんどありません。

ハードウェア・OS要件とネスト不可の制約

ホスト設定ガイドは、次の要件を挙げています。

• Apple Silicon Mac であること
• macOS 15 以降であること
• PV=3 の research guest は、入れ子になった macOS VM の中では動かないこと

3 点目が実務上は重い制約です。「普段使いの Mac は汚したくないので、macOS の VM を 1 つ作ってその中で試す」という回避策が取れません。トラブルシューティングガイドも、Virtualization is not available on this hardware というエラーの原因としてネスト実行を挙げ、物理の Apple Silicon Mac で起動するよう記載しています。

つまり、後述するホスト設定の変更は物理マシンに対して行うことになります。検証用に 1 台を割り当てられるかどうかが、最初の関門です。

なお、配布される bundle は実行時に Homebrew・Python・Xcode を必要としません。ソースからビルドする場合のみ、vphoned のコンパイルのために Xcode と iPhoneOS SDK が必要になります。

ホスト設定の2経路（SIP無効／SIP維持＋AMFI許可）

ホスト設定ガイドは、エンタイトルメント付きバイナリを許可する方法として 2 つの経路を提示し、そのうえで「これらはホスト所有者が行うポリシー判断である」と明記しています。どちらの経路も csrutil allow-research-guests enable を前提とします。

経路 A は、SIP と AMFI を無効化する構成です。macOS の復旧環境のターミナルで次を実行します。

csrutil disable
csrutil allow-research-guests enable

出典: Documents/Guides/host-setup.md

再起動後、macOS 側で boot 引数を設定してもう一度再起動します。

sudo nvram boot-args="amfi_get_out_of_my_way=1 -v"

出典: Documents/Guides/host-setup.md

ガイドはこの経路を「より緩いホスト構成」と位置づけ、既存の boot-args を置き換える前に内容を確認するよう促しています。

経路 B は、SIP を有効に保ったままデバッグ制限だけを緩める構成です。

csrutil enable --without debug
csrutil allow-research-guests enable

出典: Documents/Guides/host-setup.md

再起動後、現在の署名済みビルドを許可リストに追加します。ソースチェックアウトの場合は次のコマンドが示されています。

bundle=.build/XcodeBundle/Build/Products/Debug/VPhone.bundle
sudo "$bundle/Contents/MacOS/vphone-escalator" allow "$bundle/Contents/MacOS/vphone-vm"
"$bundle/Contents/MacOS/vphone-escalator" status
"$bundle/Contents/MacOS/vphone-cli" host preflight

出典: Documents/Guides/host-setup.md

2 つの経路のトレードオフは明快です。経路 A は手順が短く済む代わりに、ホストの保護機構を広く外します。経路 B は SIP を維持できる代わりに、許可の運用が増えます。業務用のマシンで実施できるかどうかは、この差をどう評価するかに依存します。判断は各組織のセキュリティポリシーに照らして行う必要があり、本記事で一方を推奨することはしません。

ビルド運用上の注意

経路 B を選ぶ場合、運用面で押さえておくべき点があります。ホスト設定ガイドは、署名だけが変わる再ビルドを含め、ビルドのたびに allow コマンドを繰り返す必要があると明記しています。ヘルパーは AMFI の code-requirements 設定が存在しなければ作成し、存在する場合は現在の vphone-vm の cdhash を追記します。その際、他の cdhash や設定キーは保持されます。vphone-escalator off は、このヘルパーが追加したハッシュのみを削除します。

トラブルシューティングガイドも、vphone-vm が起動前に kill される場合の対処として host preflight の実行を挙げ、再ビルドで cdhash が変わるため許可をやり直す必要があると記載しています。ソースを追いながら調査する用途では、この再許可が繰り返し発生します。

GUI の vphone-launchpad を使う場合、bundle の preflight が「SIP のデバッグ制限が無効になっている（または SIP が完全に無効である）」ことと「Research Guests が有効である」ことを確認します。新しい SMJobBless ヘルパーを含むアプリに更新された際は、起動時に管理者認証を求められます。

対応範囲と必要リソース｜検証済みファームウェアはどこまでか

前提条件をクリアできたとしても、次に確認すべきは「自分が検証したい端末が対象に入っているか」です。ここを見落とすと、環境を整えたあとで手戻りが発生します。

検証済みファームウェアの組み合わせ

互換性ガイドが記載している検証済みの組み合わせは、いずれも iPhone17,3 に対するものです。

出典: Documents/Guides/compatibility.md

つまり、任意の機種や任意の iOS バージョンを選べるわけではありません。実質的な対応デバイスモデルは iPhone17,3 に限定されていると読むのが妥当です。

cloudOS 側についても、ガイドは 26.4 を「調査時点で vphone600ap を含むことが確認できた最新版」と表現しており、今後も最新であり続ける保証ではないと明記しています。現行のカタログは vphone-cli fw catalog で確認する運用です。

あわせて、旧 README に載っていた多数のホストとファームウェアの組み合わせは「研究上の履歴」であり、現行のサポートマトリクスではないとも明示されています。古い一覧を見て「自分の端末も対象に入っている」と判断しないよう注意が必要です。

ディスク・メモリ・ネットワークの要件

リソース面の要件は、VM 作成ガイドとトラブルシューティングガイドに散在しています。判断に関わるものをまとめます。

• 既定の仮想ディスクサイズは 64 GB
• IPSW と一時的な復元ツリーがディスクを大量に消費する。--keep-artifacts を指定すると巨大な準備済み復元ツリーが保持されるため、空き容量が厳しい場合は指定しない
• 巨大なキャッシュへのパッチ適用にはメモリを要する
• VM の作成は 1 台ずつ行う。メモリやディスクに余裕がない場合、並列での作成は避ける
• 復元チケットの取得のため、Apple へ到達できるネットワーク接続が必要。ローカルの IPSW を用意する場合も同様
• 初回ブートのチェックは 300 秒でタイムアウトする

VM 本体の保存先は既定で ~/.vphone/ です。より詳細には、~/.vphone/machines/<name>/ にディスク・config.plist・パッチ作業用ファイルが置かれ、ダウンロードした IPSW は ~/.vphone/machines/<name>/.ipsw-cache/ に保持されます。配置は VPHONE_ROOT および VPHONE_LIBRARY_ROOT で移動できるため、起動ディスクの空き容量が厳しい環境では外部ボリュームへ逃がす選択肢があります。

仮想iPhoneを構築する手順｜LaunchpadとCLIの2経路

構築の入口は 2 つ用意されています。どちらを選ぶかは、初回導入なのか、自動化や段階的な調査が目的なのかで分かれます。なお本記事は手順の完全な再現マニュアルを目指すものではなく、導入コストの実像を把握するための概観として整理します。実施時は必ず公式ガイドを参照してください。

Launchpad（GUI）での導入フロー

README が示す GUI 経路は 4 段階です。

1. macOS の復旧環境で csrutil の 2 コマンドを実行し、再起動する
2. アプリを開き、Host Setup で開発者ツールへのアクセス許可と特権ヘルパーの導入を済ませる
3. Core Bundle の画面で VPhone.bundle を Download and Install する
4. Machines → New Machine と進み、カタログからファームウェアの組み合わせを選んで Create する

入手経路は、公証済みの vphone-launchpad 2.0.8（zip）を物理 Apple Silicon Mac（macOS 15 以降）で使用する形です。README は、カタログを利用する場合もファームウェアのダウンロードは発生し、VM 作成には復元チケット取得のためのネットワーク接続と大きな空きディスク容量が必要であると注記しています。

初回起動チェックのあとも VM は起動したままになる点が、次に述べる CLI 経路との差です。

CLIのワンコマンドフローと成功時の出力の読み方

CLI 経路では、iPhone17,3 の復元 IPSW と対応する cloudOS の IPSW をローカルパスまたは URL で指定します。

vphone-cli host preflight
vphone-cli vm create myphone \
  --iphone-source /path/to/iPhone17,3_Restore.ipsw \
  --cloudos-source /path/to/cloudOS.ipsw

出典: Documents/Guides/create-and-run.md

ここで押さえておきたいのが、成功時の挙動です。ガイドは、処理が First boot: vphoned ping succeeded と JB VM created; vphoned connected で終わること、そして検証用の VM はそのあと停止されることを明記しています。ping はそのブート中にデーモンがホスト制御ソケット越しに応答した事実を示すだけで、稼働中の VM を残すものではありません。

トラブルシューティングガイドも、「vm create が成功したのに VM が動いていない」というケースを仕様として扱っています。利用する段階では vphone-cli vm launch <name> を実行します。この点を知らないと、正常終了しているのに失敗したと誤認する可能性があります。

ホストの制御ソケットは <VM bundle>/vphone.sock です。SSH や VNC のエンドポイントは、このワークフローでは導入されません。

手動ステージに分解する場合

調査や再現が目的の場合は、パイプラインを段階ごとに分解して実行できます。ガイドは vm new → fw prepare → fw patch → vm launch --dfu & → restore → vm stop → cfw install → vm launch という順序を示しています。オフラインでの復元については restore --help の --get-shsh および --offline を参照する形です。

ただし手動フローでは、初回ブートの ping による自動チェックが行われません。どこまで進んだかを自分で判断する必要があるため、まずはワンコマンドフローで一度通し、必要になってから分解するほうが手戻りは少なくなります。

日常運用とゲストAPIによる自動化

構築できたあと、どこまで「回せる」かは採用判断を左右します。ここは vphone-cli の実務的な価値が出る部分です。

VMのライフサイクル管理とバックアップ

README は主要なコマンドを表で示しています。

出典: README

このほかに vm clone があり、VM 作成ガイドによればデバイス識別情報とブートファイルを含む完全な状態をコピーします。APFS のコピーオンライトを利用するため、同一ボリューム上であれば複製のコストは抑えられます。

構築に時間とディスクを要する性質を踏まえると、export と clone が用意されている点は運用上の意味が大きいと言えます。「壊れたら作り直す」のコストが高いため、状態を保存できるかどうかが回せるかどうかを分けます。

vphoned APIでできること・意図的に提供されないもの

ローカルからの自動化は、--api-listen 127.0.0.1:8765 を付けて起動することで有効になります。README によると、VM は起動のたびに新しい API トークンを [api] token: … の形式で出力し、VPHONE_API_TOKEN を設定した場合はその値を使います。トークンのないリクエストは拒否され、Web ページからのリクエストも同様に拒否されます。

API の詳細はリポジトリ内の調査ノートにまとまっています（Research/vphoned_http_api.md）。VSOCK のポート 1339 で待ち受け、HTTP と WebSocket でゲストを制御する構成で、認証は Bearer トークン、WebSocket のクエリパラメータ token=、サブプロトコル vphone-token.<token> の 3 経路が用意されています。トークンは SecRandomCopyBytes 由来の 32 バイトの hex 文字列として起動ごとに生成されます。

提供される機能は次のように分類されています。

一方で、アカウントのパスワード、ブートロゴのレンダリング、パッケージインストールの一部については、意図的に提供しないと明記されています。

アクセシビリティツリーの取得とパケットキャプチャが API から扱える点は、UI 自動化や通信の調査をホスト側から回す前提での設計を示しています。単発で起動して眺めるだけでなく、調査を反復するための土台が用意されていると読めます。

2.xで導入されないコンポーネント

冒頭で触れた情報の食い違いに、ここで決着をつけます。VM 作成ガイドは、公開されているワークフローが単一の完全なパッチセットを適用し、ブートチェーンとゲストシステムにパッチを当てて vphoned を導入する一方、ユーザー環境は空のままであると記載しています。そのうえで、Sileo・apt・TrollStore・SSH サーバー・VNC サーバーは導入しないこと、およびこのワークフローでは SSH / VNC のエンドポイントが導入されないことを、いずれも明記しています。トラブルシューティングガイドにも、現行の JB ワークフローは VNC サーバーを導入しないという同趣旨の記載があります。

注意が必要なのは、この点について二次情報が現行仕様に追随しきれていないことです。英語圏のまとめ記事には「Sileo や TrollStore が入った状態で起動する」と書くものがあり、これは 1.x 時点の情報です。同様に、技術メディアの InfoQ も「root 権限での SSH アクセスと GUI への VNC アクセスを提供する」と記載しています（InfoQ, 2026年9月）。この記述は上記の公式ガイドの記載と正面から食い違うため、本記事では事実として採用していません。プロジェクトの更新ペースが速く、二次情報が追いつききれていない領域だと捉えるのが実態に近いでしょう。採用を判断する際は、こうした機能の有無を二次情報で確かめず、公式 Guides を直接確認することをおすすめします。

では SSH も VNC もない前提で何を操作経路にするのか。ホスト側からはさきほど触れた制御ソケット <VM bundle>/vphone.sock と、VSOCK のポート 1339 で待ち受ける vphoned の HTTP/WebSocket API が入口になります。GUI の操作は VM ウィンドウ側から行い、トラブルシューティングガイドは「Press home to continue」で停止した場合の対処として VM ウィンドウの Keys → Home を使うよう案内し、その理由として VNC サーバーが入っていないことを挙げています。細部まで一貫した仕様です。

なお、カスタムファームウェアの Bootstrap については、VM 起動後にメニューの Guest > Install Bootstrap… からゲストに Irisin を導入する経路が README に記載されています。初回は apt と bash を選び、Install を長押しして Bootstrap Install を実行する形です（debianutils と bash の依存循環を避けるため、全パッケージを先に展開する仕様）。既定で入っているわけではなく、必要なら明示的に導入する、という位置づけです。

類似OSSとの違い｜tart・UTMとどこが交わらないか

「Mac 上の仮想化なら既存のツールで足りるのでは」という問いに答えておきます。結論から言えば、同じ Virtualization.framework を使っていても、解いている問題が違います。

比較テーブル

tart は Apple Silicon 上で macOS と Linux の VM を扱うツールで、OCI 互換レジストリを使った VM イメージの push / pull、Packer プラグイン、Orchard によるクラスタ運用といった、ビルド環境を再現可能にするための機能を備えています。2026 年 9 月時点では openai/tart に移管されており（旧称は cirruslabs/tart）、公式サイトは tart.run です。ゲストに iOS は含まれないため、iOS のシステム挙動を追う用途では代替になりません。

UTM は QEMU をベースにした汎用の VM / エミュレータで、GUI 中心の作りで導入障壁が低いことが特徴です。Apple Virtualization バックエンドも選べますが、iOS ゲストの公式サポートはなく、iPhone のファームウェアを復元・パッチする機構も持ちません。異なるアーキテクチャを動かせる点が強みであり、目的の方向が異なります。

iOS Simulator・PCC VREとの棲み分け

近縁に見えるが層が違うものを 2 つ挙げておきます。

1 つは Xcode の iOS Simulator です。OSS ではありませんが、比較軸としてはよく挙がります。これは iOS のカーネルを起動しないシミュレータで、アプリ層の動作確認には最適である一方、システムレベルの挙動やカーネルの調査には使えません。vphone-cli は実カーネルを起動する点で、そもそも扱う層が異なります。アプリの表示や操作を確認したいだけであれば、Simulator のほうが圧倒的に低コストです。

もう 1 つは Apple 公式の apple/security-pcc（PCC Virtual Research Environment）です。csrutil allow-research-guests enable を前提とする点は vphone-cli と共通ですが、動かす対象は PCC のノードソフトウェアであり、iPhone のファームウェアではありません。vphone-cli は、この研究用 VM 基盤を iPhone 起動の土台として転用している、という関係にあります。

採用を判断するためのチェックポイント

ここまでの内容を、判断リストとして集約します。上から順に確認し、成立しない項目が出た時点で検討を打ち切れる順序に並べています。

1. 検証対象が iPhone17,3 相当か。互換性ガイドの検証済みテーブルは iPhone17,3 の 2 パターンのみです。別機種を対象にしたい場合、現時点では要件を満たしません
2. 物理の Apple Silicon Mac（macOS 15 以降）を 1 台用意できるか。PV=3 の research guest は macOS VM 内にネストできないため、仮想化による分離では回避できません
3. ホストのセキュリティ設定の変更を許容できるか。経路 A（SIP 無効 + AMFI 緩和）か経路 B（SIP 維持 + vphone-escalator allow）のいずれかが必要で、どちらも csrutil allow-research-guests enable を前提とします。Apple 自身がこの設定について攻撃面を広げうる旨を記載している点も判断材料です
4. IPSW の取得と取り扱いを自組織のルールで整理できるか。ファームウェアのダウンロードと復元チケットの取得が処理に含まれます。この領域は利用規約や社内規程に関わる論点を含むため、技術要件とは別に確認が必要です
5. ディスクとメモリの余裕があるか。既定の仮想ディスクは 64 GB、加えて IPSW と一時復元ツリーが容量を消費します。並列作成を避ける前提でのスケジュールも見込む必要があります
6. API による自動化が目的に合うか。アプリ管理・入力・ファイル操作・アクセシビリティツリー・パケットキャプチャが API から扱える一方、Sileo・apt・TrollStore・SSH・VNC は導入されません
7. トラブル時に公式ガイドと Issue を追える体制か。2026 年 2 月開始のプロジェクトで、2026 年 9 月時点のオープン Issue は 31 件です。仕様が動きうる前提で追随できるかを見積もる必要があります

なお、ホストのセキュリティ設定の変更やファームウェアの取り扱いについては、各組織のポリシーや適用される規約に照らした確認が必要な領域です。本記事は公開ドキュメントの記載事実を整理したものであり、特定の実施方法を推奨するものではありません。

まとめ｜vphone-cliが向くケース・向かないケース

vphone-cli は、Apple Silicon Mac 上に仮想 iPhone を構築するための OSS です。Virtualization.framework と PCC 研究用 VM 基盤を土台に、ファームウェアのパッチと DFU 復元を経て iOS の実カーネルを起動します。2026 年 9 月時点でスター 14,541、ライセンスは MIT、直近も活発に更新されており、アーカイブもフォークもされていない現行プロジェクトです。

向くのは、次のようなケースです。

• iOS のシステム挙動やカーネル層の調査を、実機を増やさずに行いたい
• セキュリティ研究の対象として、パケットキャプチャやファイルシステムへのアクセスを含む調査を反復したい
• API 経由で UI 操作やログ収集を自動化し、調査を回す仕組みを作りたい
• 検証対象が iPhone17,3 相当で、物理の Mac を 1 台占有できる

向かないのは、次のようなケースです。

• 一般的なアプリの表示・操作を確認したいだけの場合（iOS Simulator のほうが低コストです）
• CI で多数の VM を並列に立ち上げたい場合（作成は 1 台ずつが前提です）
• 対応範囲外の機種・OS を検証したい場合
• SIP 設定の変更が認められない業務端末しか用意できない場合
• Sileo や SSH での接続を前提とした運用を組みたい場合（2.x では導入されません）

判断を先に進めるなら、まず互換性ガイドで対象機種が成立するかを確認し、成立するならホスト設定ガイドで 2 つの経路のどちらを選べるかを検討するのが最短です。その 2 つが通れば、VM 作成ガイドの手順に進めます。

関連情報

モバイルアプリの検証環境整備や、社内の開発・検証基盤の設計をご検討中の場合は、お問い合わせフォーム からご相談いただけます。要件の整理段階からのご相談も承っています。

参考リンク

• Lakr233/vphone-cli（GitHub リポジトリ・README）
• vphone-cli 日本語 README
• Host setup（ホスト設定ガイド）
• Create and run（VM 作成・実行ガイド）
• Compatibility（互換性ガイド）
• Troubleshooting（トラブルシューティングガイド）
• vphoned HTTP/WebSocket API（Research ノート）
• VPhoneVirtualMachineRefactored.swift（Research・VM 構成の参照実装）
• Apple 公式: Virtualization framework
• Apple 公式: Private Cloud Compute Virtual Research Environment
• openai/tart
• utmapp/UTM
• apple/security-pcc
• Open-Source Project Brings Full iOS 27 Virtualization to Ap…