macOS 27 ベータが仮想マシンにインストールできない？修正ガイド

macOSTahoe ·
macOS 27 ベータが仮想マシンにインストールできない？修正ガイド

macOS 27 Golden Gate ベータが UTM、Parallels、VMware で「Installation failed」エラーによりインストールできない問題について、原因と対処法を解説します。

あなたは慎重に事を進めています。真新しい macOS 27「Golden Gate」ベータをメインで使っている Mac にいきなり導入するのではなく、責任ある開発者やパワーユーザーがそうすべきであるように、まず仮想マシン内でテストすることにしました。復元イメージをダウンロードし、UTM や Parallels、VMware Fusion にそのイメージを指定して VM の作成をクリックし、進捗バーが数分間にわたって前進していくのを見守ります。ところがある時点で完全に止まり、素っ気ないダイアログが表示されます。「インストール中にエラーが発生しました。インストールに失敗しました。」読むべきログもなく、検索できるコードもなく、何がうまくいかなかったのかというヒントすらありません。もう一度試しても結果は同じです。UTM から VirtualBuddy、Tart とアプリを乗り換えても、どれも同じ箇所で同じ役に立たないメッセージとともに失敗します。あなたの Mac で macOS 27 ベータが仮想マシンにインストールできない場合、設定を誤っているわけでも、ダウンロードしたファイルが壊れているわけでもありません。これは Apple も認めている既知の不具合に遭遇しているのであり、セットアップのある一点を変えない限り、何度リトライしても解決しません。

これは、新しい macOS ベータの早期採用者が直面する中でも特にもどかしい問題の一つです。というのも、正しい手順を踏んでいる人ほど割を食う構図になっているからです。VM を使う一番の理由はリスクを避けることなのに、ここでは安全なはずの経路そのものが破綻しています。さらに悪いことに、この一般的な「installation failed」というエラーは、まるでローカル側のミス――IPSW の破損、ディスク容量の不足、VM 設定の誤り――であるかのように見えてしまい、決して解決しない何時間ものトラブルシューティングへと人を誘い込みます。なぜなら根本原因は画面のこちら側には一切ないからです。原因は、現在お使いの Mac が動作している macOS のバージョンと、ゲストにインストールしようとしている macOS のバージョンとの間の相互作用の中にあります。

このガイドでは、まずこのエラーが具体的にどのように見えるのか、誰がこの問題に遭遇し誰が遭遇しないのか、そしてそもそもベータを VM でテストする価値がなぜあるのかを説明します。次に核心に迫ります。真の根本原因は、macOS 26.6 のホストと macOS 27 のインストーラーとの間にある Apple の Virtualization framework の非互換性であり、なぜすべての VM アプリが同じように失敗するのかを正確に理解できるよう、わかりやすく解説します。そこから、実際に効果のある 3 つの回避策、UTM・VirtualBuddy・Tart・Parallels・VMware Fusion それぞれのアプリ別の注意点、そして検討する価値のあるより安全な代替手段を順に見ていきます。これは流動的なベータ状況であるため、何が確定していて何が次のビルドで変わりうるのかについても、最後まで正直にお伝えします。

重要ポイント

  • **「インストール中にエラーが発生しました。インストールに失敗しました。」**というメッセージは、Apple も認めている既知の不具合であり、あなたのミスではありません。UTM、VirtualBuddy、Tart、Parallels、VMware Fusion で同一の失敗が起きるのは、これらすべてが同じ基盤となるインストーラー経路を共有しているためです。
  • 根本原因は、Apple の Virtualization framework――具体的には VZMacOSInstaller API――にある非互換性です。macOS Tahoe 26.6 を実行している Mac が macOS 27 Golden Gate 復元イメージをゲストにインストールしようとするときに発生します。ホスト OS が古すぎて、より新しいインストーラーを動かせないのです。
  • 回避策 1: すでに macOS 27 を実行している Mac 上で macOS 27 の VM を構築またはインストールする。これによりホストとゲストの不一致自体がなくなります。
  • 回避策 2: まず macOS Tahoe の VM を作成し、IPSW から 27 を新規インストールするのではなく、その VM を ゲスト内部から Software Update（Apple Beta 登録）経由で macOS 27 ベータにアップグレードする。
  • 回避策 3: API の不一致を解消する更新ビルドまたは VM アプリの更新を 単純に待つ。ベータであるため、影響を受けるビルドはリリースごとに変わり得ます。
  • Apple silicon では、これらのアプリはすべて同じ Apple のフレームワークをラップしており、macOS ゲストは Apple のライセンス上、これまで 1 ホストあたり 2 台まで に制限されてきました。また、ゲストは 一部の DRM や iCloud 連携サービスにサインインできません。VM に時間を投資する前に知っておく価値のある点です。

「Installation Failed」エラーの見え方と発生対象

どのアプリを使ってもほぼ同じ症状が出るという事実こそ、問題がアプリ側にはないという最初の大きな手がかりです。新しい macOS 仮想マシンを作成する通常の流れを開始します。macOS ゲストを新規インストールする選択をし、macOS 27 の復元イメージ（IPSW ファイル）をアプリに渡すか自動取得させ、CPU コア、メモリ、ディスクを割り当てて開始します。序盤は完全に健全に見えます。アプリは復元イメージを展開し、一時的なインストール環境を立ち上げ、30 秒から数分の間、説得力を持って前進する進捗インジケーターを表示します。そして途中で全体が止まり、「インストール中にエラーが発生しました。インストールに失敗しました。」といった素っ気ないダイアログが表示されます。ネイティブの macOS アラートとして表示するアプリもあれば、独自の UI に表示したり、ログに短い一行を書き出すだけのアプリもあります。文言があえて一般的なのは、実際に処理を行っているフレームワークから、アプリ自体が詳細な理由を受け取れないことが多いためです。

メッセージがあまりに素っ気ないため、人は自然と自分が何か間違えたのだと考え、決して原因ではなかったものを追いかけて時間を浪費します。IPSW が壊れていないか再ダウンロードする。チェックサムを検証する。VM にディスク容量、RAM、コアをさらに割り当てる。VM を削除して一から作り直す。見つけられる限りの設定を切り替える。しかし何をしても結果は変わりません。なぜならこれらのどれも失敗の原因ではないからです。インストールはダウンロードに問題がないこと、割り当てが十分であることを証明できる程度まで進みます――欠けたバイトや窮屈なディスクでつまずいているわけではありません――そのうえで、VM 側のどんな設定でも動かせない、インストール機構そのものに組み込まれた壁にぶつかるのです。

各アプリでの挙動の一致

この不具合を見分けやすくしているのは、その一貫性です。UTM では、VM 作成ウィザードがインストール段階に到達したところで失敗が発生します。まさにこの種のテストのために Apple の仮想化スタックを中心に構築された VirtualBuddy でも、ガイド付きインストーラーが同じ段階で失敗します。CI や自動化の現場で好まれるコマンドライン志向のツール、Tart も、使えるイメージを生成する代わりにインストールエラーを返します。二大商用ハイパーバイザーである Parallels Desktop と VMware Fusion も、影響を受けるホスト上で macOS 27 の復元イメージを渡すとどちらも失敗します。もしこれがローカルの設定ミスであれば、フレームワークをそれぞれ異なる方法でラップしているアプリごとに、失敗する段階もメッセージも癖も違って見えるはずです。すべてが同じポイントで同じ一般的なエラーとともに息絶えるという事実こそ、5 つの別々の偶然ではなく、共通する上流の原因の証です。

影響を受ける人と受けない人

境界線を引くのは、あなたが選んだ VM アプリではなく、ホスト の Mac が何を実行しているかです。あなたの Mac が現在 macOS Tahoe 26.6（そのベータを含む）で動作しており、標準の Virtualization framework インストール経路で macOS 27 のゲストをインストールしようとする場合、あなたは影響を受けるグループに含まれます。すでにあなたの Mac が macOS 27 自体を実行しており、そこで 27 のゲストを構築する場合は、ホストとゲストが一致しているため、通常は影響を受けません。ネット上で一部の人がベータは VM に「問題なく」インストールできると断言する一方で、何をしても同じエラーを超えられない人がいるのはこのためです――彼らは単に異なるホスト OS 上にいるのです。この問題がタイミングに強く結びついているのもこのためです。現行の Tahoe 環境の人々が公開直後の 27 ベータを立ち上げようとし始めた時点でちょうど表面化し、ホストが 27 へ移行するか、Apple が不一致を解消するビルドを出荷するにつれて薄れていきます。これはベータであるため流動的な対象であることに留意してください。この境界線の両側にある正確なビルドは変化し得るため、ここに書かれているバージョン番号は、恒久的な規則ではなく執筆時点の状況として捉えてください。

そもそも macOS 27 を仮想マシンでテストする理由

修正方法に入る前に、なぜこれほど多くの人がこの手間をかけるのかを明確にしておく価値があります。それによって、この不具合が単なる肩をすくめる程度の問題ではなく、大きな厄介事である理由が分かります。日々頼りにしている Mac 上で、真新しい初年度の macOS ベータを実行するのは本当にリスクがあります。初期のベータはカーネル拡張を壊したり、ダウングレード時にデータを破損させたり、バッテリー寿命を削ったり、サードパーティアプリを使い物にならなくしたりすることがあります。macOS 27 は今回のサイクルでさらに重みを持ちます。Apple silicon 専用の初のリリースであり、Rosetta 2 を搭載した最後のリリースであり、Intel Mac 時代の終わりでもあるからです――一度に多くの変化が押し寄せます。仮想マシンを使えば、作業環境を Apple 自身が未完成だと明言するベータに賭けることなく、そのすべてを試すことができます。何が変わるのかの全体像を知りたい場合は、機能、互換性、リリース時期を含む WWDC 2026 での発表内容 をまとめた記事が、今回のリリースがなぜこれほど多くのテスターを惹きつけているのかを理解する土台になります。

スナップショットと即時ロールバック

VM でテストする最大の理由はスナップショットです。リスクのあるアップデートをインストールしたり、新しい API を試したり、信頼できないソフトウェアを実行したりする前に、スナップショット――マシン全体の状態を凍結したコピー――を取っておけば、何か問題が起きても数秒でそこに戻せます。再インストールも、バックアップからの復元も、失われた午後もありません。ボタンをクリックするだけで、壊す前とまったく同じ状態の VM に戻ります。ベータテストにおいてこれは革命的です。ベータをインストールし、崩壊するのを見届け、元に戻し、何かを調整して、再び試す――それを実機で macOS を一度再インストールする間に何十回も繰り返せます。ベアメタルではこのループに到底かないません。バグを確実に再現する必要がある開発者がまず VM に手を伸ばすのはこのためです。

実データと環境からの分離

VM は密閉された箱でもあります。ベータが何をしようと――奇妙なバックグラウンドプロセスを起動しようと、環境設定を壊そうと、アカウントで問題を起こそうと――それはすべてゲストの内部で起こり、あなたの実際のディスク上では起こりません。あなたの本物の写真、書類、キーチェーン、アプリのライセンスは、ホスト上で無傷のまま安全に保たれます。この分離こそ、「installation failed」の不具合が痛手となる理由です。VM の存在価値そのものが、慎重な人が危険なソフトウェアを安全にテストできることにあるのに、この不具合は慎重な経路の扉を閉ざす一方で、「とにかくメインの Mac に直接インストールする」という無謀な経路は大きく開いたままにしているからです。VM と格闘したくなく、実機でのベータ導入を検討しているのであれば、コミットする前に macOS 27 デベロッパーベータをインストールすべきかどうかとその既知の問題 についての率直な見解を読んでみてください。VM の安全網は軽々しく手放すべきものではないからです。

根本原因：Virtualization Framework におけるホストとゲストの不一致

ここが実際にすべてを説明する部分です。macOS 27 ベータが Tahoe ホスト上の仮想マシンにインストールできない理由は、これらのアプリすべてが Apple silicon 上で macOS ゲストを作成・インストールするために依存している低レベルのシステムコンポーネント、Apple 自身の Virtualization framework の内部にある非互換性です。具体的には、macOS の復元イメージを受け取ってブート可能なゲストに変換する責任を持つ API、すなわちそのフレームワークのインストーラー部分が、macOS 26.6 ホスト上で動作しているときに macOS 27 の復元イメージを正しく処理できないのです。Apple は Developer Forums 上でこれを既知の問題として認めています。要約すると、Tahoe 26.6 を実行している Mac は、Apple の仮想化インストール経路を使って macOS 27 の復元イメージを配置することができず、ホストがバージョンアップするか Apple がフレームワークを修正するまで、その経路は塞がれたままです。

Apple silicon Mac 上の macOS 仮想マシンウィンドウ

Apple Silicon の仮想化が実際にどう動作するか

なぜこれが起きるのかを理解するには、Apple silicon 上で仮想マシンがどう動作するかを知る必要があります。Intel 時代とはかなり様子が異なるからです。Apple silicon Mac では、サードパーティ製アプリは macOS ゲストを実行するための独自の低レベルハイパーバイザーを同梱していません。代わりに、Apple が macOS の一部として Virtualization framework（Virtualization.framework）を提供しており、このフレームワークが重労働を担っています。仮想ハードウェアを定義し、ゲストを起動し――そしてここが肝心なのですが――復元イメージから新しいゲストに macOS をインストールします。UTM、VirtualBuddy、Tart、Parallels、VMware Fusion といったアプリは、macOS ゲストのケースに関する限り、実質的にはこの共有された Apple のフレームワークを包む洗練されたフロントエンドおよび管理レイヤーです。Apple は同じ基盤の呼び出しを実演する簡素なリファレンスツール macosvm すら提供しています。この設計はエレガントであり、通常時に Apple silicon 上で macOS-on-macOS の仮想化がこれほどスムーズに機能する理由でもあります――しかし同時に、どのアプリも同じエンジンを動かしている以上、フレームワークの不具合をすべて受け継ぐことも意味します。この全体像をさらに深く知りたい場合は、より詳しいメンタルモデルを扱った macOS 仮想化の総合ガイド をご覧ください。

VZMacOSInstaller 経路が壊れる箇所

そのフレームワークの中で、新しい macOS ゲストをインストールするコンポーネントが、あなたの復元イメージを受け取って動作するシステムを作り出す部分です。VM アプリに macOS 27 の IPSW を渡して新規ゲストの構築を指示すると、アプリはこのインストーラー API を呼び出します。この API は復元イメージを読み込み、検証し、ゲストの仮想ストレージをセットアップし、macOS 27 をそこに書き込みます。問題は、macOS 26.6 ホストに組み込まれているインストーラーのコードが、事実上、処理を求められている macOS 27 の復元イメージよりも古いということです。27 のイメージは、26.6 ホストのフレームワークがまだ提供していないインストーラーの挙動を前提としており、インストール途中でこの不一致が表面化すると、フレームワークは処理を中断します。上位のアプリは詳しい説明のないまま失敗を受け取り、一般的な「installation failed」のダイアログを表示します。これはバージョン間のずれによる問題です。インストールを行う側が、インストールされる側よりも一歩遅れており、両者が途中で折り合うことができないのです。

すべての VM アプリが同じように失敗する理由

インストーラーがアプリ側ではなく Apple のフレームワークの中にあると理解すれば、同一の失敗が起きること自体は謎ではなくなります。UTM、VirtualBuddy、Tart、Parallels、VMware Fusion はすべて、新規 macOS ゲストのインストールを最終的に同じ Apple のインストーラー API に振り分けています。そのため、この API が 26.6 ホスト上で 27 のイメージを処理できない場合、そこにたどり着くまでにどれだけ洗練されたインターフェースをクリックしたかは関係ありません――すべて同じ壊れた扉にたどり着くのです。これが、アプリ側でどれだけトラブルシューティングをしても助けにならない理由であり、VM アプリだけを更新しても直る場合と直らない場合がある理由でもあります。修正は、ホスト OS 側（27 のイメージを理解するバージョンへの移行）から来るか、Apple がホストのアップデートでフレームワークを修正するか、あるいは現行のフレームワークが処理できるイメージを持つ後続の 27 ベータから来るしかありません。この現実こそが、以下の 3 つの回避策の形を決めています。

アプリ別の注意点：UTM、VirtualBuddy、Tart、Parallels、VMware Fusion

根本原因は共通しているものの、各アプリには問題の見え方と、どの回避策が最も適しているかにそれぞれの癖があります。ここでは各アプリで何を期待すべきかを説明します。

UTM

UTM は無料でオープンソースの人気仮想化ツールで、費用がかからず、Apple 仮想化ベースの macOS ゲストと、他 OS 向けの QEMU ベースのゲストの両方を扱えるため、多くの人にとって最初の選択肢です。Apple silicon 上の macOS 27 ゲストについては Apple Virtualization バックエンドを使用するため、インストーラーの不具合を直接引き継ぎます。UTM では、IPSW を選択した後のガイド付き macOS インストール中に失敗が現れるのが典型的です。影響を受けるホスト上では、VM の再作成、IPSW の切り替え、リソース設定の調整のいずれもこれを回避する助けにはなりません。とはいえ UTM は回避策 2 に適した選択肢です。まず UTM で macOS Tahoe のゲストを構築し（Tahoe ホスト上では問題なくインストールできます）、その後内部から 27 ベータにアップグレードします。

VirtualBuddy

VirtualBuddy は、macOS ゲストのダウンロード・インストール・実行のために、Apple の Virtualization framework を中心に特化して構築された無料ツールであり、フレームワークの機能に簡単にアクセスできるため、まさにこの種のベータテストで好まれています。この密結合により、インストーラーの不具合にも直接さらされます。インストールフローそのものがフレームワークのインストールフローだからです。VirtualBuddy は復元イメージの取得やスナップショットの管理が非常に得意なので、この不具合を回避する経路を取った後は依然として有力な選択肢です。Tahoe ゲストを作成してスナップショットを取り、内部からアップグレードするために使いましょう。フレームワークにこれほど近いツールは新しいベータの癖への対応も早い傾向があるため、リリース情報には注目しておく価値があります。

Tart

Tart は、macOS の VM をプログラム的に作成・使用・破棄する自動化と継続的インテグレーション向けのコマンドラインツールです。これも Apple の Virtualization framework の上に成り立っているため、26.6 ホスト上で macOS 27 のイメージを取り込む tart create は、使えるイメージを生成する代わりに同じインストール失敗にぶつかります。CI パイプラインにとってこの不具合は特に破壊的です。まさに無人・再現可能なビルドこそがその存在意義だからです。Tart ユーザーにとって最もクリーンな修正は回避策 1 です。すでに macOS 27 上で動いているランナーでイメージ構築ステップを実行するか、27 のゲストを別の場所で事前構築し、影響を受ける各ホストで新規インストールするのではなく、完成済みのイメージをランナーに配布します。

Parallels Desktop

Parallels Desktop は、Mac 上で Windows を実行するツールとして最も知られている洗練された商用ハイパーバイザーですが、Apple silicon 上では Apple のフレームワークを通じて macOS ゲストも作成しており、それらの macOS ゲストは Tahoe ホスト上で同じインストーラーの壁にぶつかります。Parallels は新しい macOS リリースに合わせて速やかにアップデートを出す傾向があるため、アプリのアップデートを確認する価値はあります――ただし、不具合がホストのフレームワーク側にある場合、Parallels のアップデートだけではホスト自体が前進するまで解決しない可能性があることを覚えておいてください。Parallels のスナップショットとゲスト管理ツールは成熟しており、「Tahoe をインストールしてからアップグレードする」経路を簡単に実行できるため、回避策 2 にとって快適な環境です。

VMware Fusion

現在は個人利用向けに無料で提供されている VMware Fusion も、同様に Apple silicon 上の macOS ゲストで Apple の Virtualization framework に依存しており、影響を受けるホスト上で macOS 27 の復元イメージを渡すと同じように失敗します。Parallels と同様、Fusion のアップデートには注意しておきましょう。ただし、アプリのアップデート単体でホストのフレームワークの制約を上書きできるとは期待しないでください。Fusion は Tahoe を先にインストールしてからアップグレードする経路とも相性が良く、新規インストールの体験そのものを検証したいわけではなく、単に動作する macOS 27 のサンドボックスが欲しいだけであれば、この経路で何も待たずに目的を達成できます。

これら 5 つに共通するのは同じことです。選ぶアプリはインターフェースと便利機能を変えるだけで、根本的な原因を変えることはありません。スナップショットと管理ツールが最も気に入ったものを選び、以下の回避策のいずれかを適用してください。

回避策 1：すでに macOS 27 を実行している Mac 上で VM を構築する

最も直接的な修正は、不一致そのものを取り除くことです。すでに macOS 27 を実行している Mac をホストとして、そこに macOS 27 のゲストをインストールします。この不具合は根本的に、ゲストのイメージより一歩遅れたホストのフレームワークが原因であるため、ホストをゲストと同じ世代にそろえれば、インストーラー API は 27 の復元イメージを正しく処理でき、VM は正常に構築されます。すでに 27 ベータを実行している 2 台目の Mac、あるいは予備のパーティションや外付けの起動ディスクが手元にあれば、そこで 27 のゲストを作成すれば「installation failed」エラーはそもそも発生しません。

明らかな落とし穴は、これが堂々巡りになりがちなことです。多くの人がまさに、実機のどの Mac でも 27 を実行しなくて済むように VM を望んでいるのに、この回避策は VM を構築するために実機の Mac で 27 を実行することを求めます。これはもっともな異議であり、Mac が 1 台しかなく、それをベータに移行させたくない場合、この方法はあなた向けではありません。回避策 2 に進んでください。ただし、これがぴったりはまる状況もあります。ベータに投入して構わない古い Mac やサブ機の Apple silicon Mac を持っているなら、それを「VM 製造拠点」として専用化するのはきれいなやり方です。そのマシンを 27 に移行させ、ライセンスが許す限り多くの 27 ゲストを構築・スナップショットしておけば、そのゲストイメージは持ち運び可能で再利用できます。CI を運用しているチームも同じ発想を、27 上で動くビルドランナーを指定し、そこで生成したゲストイメージを他の全員が利用する形で応用できます。

この経路を取るなら、気まぐれにメインマシンをアップグレードするのではなく、意図的に行ってください。macOS 27 パブリックベータを安全にインストールする というガイドでは、適切なバックアップと逃げ道を用意して実機の Mac をベータへ移行する方法を解説しています。使い捨てのつもりのマシンであっても重要なポイントです。また、後でそのホストを安定版の macOS に戻したくなった場合に備えて、あらかじめ脱出経路を知っておきましょう。macOS 27 ベータからデータを失わずに Tahoe へダウングレードする方法 を解説したガイドは、まさにそのための存在です。

回避策 2：まず Tahoe VM を作成し、Software Update 経由でアップグレードする

これは、Mac を 1 台しか持たないほとんどのユーザーが実際に選びたくなる回避策です。すでに Tahoe が動いている手持ちの Mac 以外、何も必要としないからです。ポイントは、この不具合がフレームワークのインストーラーを通じて macOS 27 を復元イメージから新規にインストールする場合にのみ影響するということです。すでにインストール済みの macOS ゲストを実行することには影響せず、実行中のゲスト内部にある通常のその場アップデート機構にも影響しません。そこで、27 を直接インストールしようとする代わりに、まず macOS Tahoe のゲストをインストールします――ホストとゲストが一致するため、Tahoe ホスト上で完璧に動作します――そして、実機の Mac をアップグレードするのとまったく同じように、Software Update を使ってそのゲストを内部から 27 ベータにアップグレードします。

Software Update 経由で macOS VM をベータにアップグレードする様子

手順

まず、お好みの VM アプリで通常の macOS Tahoe 仮想マシンを作成します。Tahoe の復元イメージを指定するか（あるいはアプリに取得させ）、インストールを進めます。ホストとゲストが同じ世代なので、これはエラーなく完了します。新しい Tahoe ゲストを起動し、初期設定を進めて、動作するデスクトップにたどり着きます。他の作業をする前に、まずスナップショットを取ってください――このクリーンな Tahoe 状態は保持しておく価値があり、アップグレードがうまくいかなかった場合の即時ロールバック手段になります。

次に、実機の Mac と同じ方法でゲストをベータに登録します。システム設定を開き、「一般」から「ソフトウェアアップデート」に進み、ベータアップデートの設定を使って、macOS 27 を提供する Apple Beta プログラムのトラックにゲストを参加させます。登録が完了すると、ソフトウェアアップデートは macOS 27 ベータを利用可能なアップグレードとして提示します。ダウンロードを開始する直前にもう一度スナップショットを取ってから、ダウンロードとインストールを実行させましょう。これはフレームワークによる新規インストールではなく、ゲスト自身のソフトウェアアップデート機構によるその場アップデートであるため、壊れたインストーラー経路を完全に迂回でき、ゲストは macOS 27 を実行した状態で立ち上がります。

なぜこれが不具合を回避できるのか

これがうまくいく理由を明確にしておく価値があります。フレームワークの VZMacOSInstaller 経路が呼び出されるのは、ホストが復元イメージから新規のゲストを構築するときだけです。既存の実行中のゲストを新しい macOS バージョンにアップグレードする処理は、ゲスト内部で動作する macOS の通常のアップデートシステムが担当しており、これはホストのフレームワークが 27 の復元イメージを処理できるかどうかに依存しない、別のコードパスです。あなたは実質的に、ホストに空の箱へ 27 をインストールさせるのではなく、どの Mac も行うのと同じ方法でゲスト自身にアップグレードさせているのです。直接インストールより時間はかかり、ディスクも少し余計に消費しますが、2 台目の Mac も不具合の修正を待つ必要もなく、今日この時点で Tahoe ホスト上に動作する macOS 27 VM を確実に手に入れられます。

回避策 3：更新されたベータビルドまたは VM アプリを待つ

時には、まだ何もしないことが正しい選択になります。この不具合はホストのフレームワークとゲストの復元イメージとの相互作用の中に存在するため、ベータシーズンの通常の入れ替わりによって自然に解消されるタイプの問題です。自然に解消される経路は 3 つあります。第一に、Apple がホスト側のアップデート――後続の Tahoe 26.6 ビルドや正式リリース――を出荷し、その Virtualization framework が 27 の復元イメージを理解するようになれば、そのホスト上で新規インストールが機能し始めます。第二に、Apple が現行のフレームワークで処理できる復元イメージを持つ改訂版の macOS 27 ベータを出荷することもあります。第三に、VM アプリ自身がアップデートでこの癖に対応する場合もあります。少なくとも、それらのアプリが影響を及ぼせる部分については。これらのいずれかが起これば、直接インストール経路は復活します。

だからこそ、ベータのリリースペースを追い続けることが重要です。Apple は今回のサイクルで速いペースで反復を重ねており――デベロッパーベータ 3 のビルドはその 1 週間後に改訂版のデベロッパーベータ 3 が続き、それとほぼ同時に最初のパブリックベータも出荷されました――2 週間前の隙間を埋める改訂版はよくあることです。急いでいないのであれば、次のベータがリリースされた後にもう一度確認するのはまったく理にかなった戦略であり、コストはかかりません。待つことは、メイン機に何か思い切ったことをしてまでベータをテストしたくなる誘惑に駆られたときにも、正直な推奨事項です。この不具合はベータ特有のものであり、恒久的な状態ではありません。ベータにはこうした粗があるものです。

とはいえ、このトレードオフについては現実的に考えてください。目的が気軽な探索であれば「待つ」のは素晴らしい選択肢ですが、実際の期限――再現すべきバグ、新しいリリースに対して検証すべきアプリ、今週中に回答が必要なクライアント――がある場合はまったく向きません。その場合は回避策 2 を使って今すぐ動作する 27 ゲストを手に入れ、将来のフレームワーク修正はおまけと捉えましょう。そして、これは流動的な状況であるため、特定のビルドに過剰に投資したくなる衝動には抵抗してください。今日失敗することが来週はきれいにインストールできるかもしれませんし、来週インストールできることが再び違う挙動を示すかもしれません。一度見た挙動が直ったと決めつけるのではなく、既知の問題リストを追跡してください。macOS 27 デベロッパーベータの既知の問題 をまとめた記事は、この VM インストール問題が解決済みとマークされたかどうかを、さらに一晩を費やす前に確認するのに良い場所です。

IPSW の入手方法と検証方法

この不具合の原因は復元イメージではありませんが、回避策 1 や後で試す直接インストールのためには、正しいイメージが必要であり、この部分はきちんと行う価値があります。Apple silicon では、macOS は通常のアップグレードに使う「Install macOS」アプリではなく、署名付きの自己完結型復元イメージである IPSW ファイルとして、仮想化と復元のために配布されます。最も安全な入手元は、Apple 自身のベータイメージ向けデベロッパーチャネルと、VM アプリが自動取得してくれる復元イメージです。ここで紹介したツールのいくつか、特に VirtualBuddy や商用アプリのガイド付きインストーラーは、適切な復元イメージを直接ダウンロードできるため、ファイルを探し回る手間が省け、誤ったビルドを掴んでしまう可能性も減らせます。

ビルドの一致と整合性の確認

IPSW を手動で入手する場合は、それが本当に自分がテストしようとしている macOS 27 ベータビルドであり、誤ってラベル付けされた古いファイルではないことを確認してください。入手元にビルド識別子が記載されている場合はそれを控え、どのビルドを扱っているか把握しておきましょう。ベータビルドは頻繁に変わり、ビルド間で挙動が異なることがあるからです。ダウンロード後は、ファイルが破損していないか確認します。サイズが入手元の記載と一致しているか確認し、チェックサムが公開されている場合はイメージを使う前にそれを検証してください。切り詰められたファイルや破損したダウンロードは、それ自体の壊れ方で――多くの場合、フレームワークの不具合よりも早い段階で、異なる症状とともに――失敗します。そのため先に整合性を検証しておけば、「ファイルが壊れている」問題と、このガイドが扱っているホストフレームワークの問題とをきれいに切り分けられます。進捗バーがしばらくの間説得力を持って進んだ後にだけインストールが失敗し、メッセージが一般的な「installation failed」であれば、特にチェックサムを検証済みのイメージが同じように失敗するのであれば、ほぼ間違いなくフレームワークの不具合であり、壊れた IPSW ではありません。

検証済みの IPSW は再利用できる場所に保管しておきましょう。テスト中に同じゲストを何度も構築することになる可能性が高く、数ギガバイトの復元イメージを毎回再ダウンロードするのは無駄だからです。検証済みで正しくラベル付けされた単一のイメージを繰り返し使い回すことは、トラブルシューティングをきれいに保つことにもつながります。同じ既知の良好なファイルが Tahoe ホスト上で失敗し、27 ホスト上で成功すれば、あなた自身の手でこの診断を確認したことになります。

スナップショットとロールバック：VM の存在価値そのもの

どの回避策で動作する macOS 27 ゲストを手に入れたとしても、VM テストをこれだけの労力に値するものにしている唯一の機能を無駄にしないでください。スナップショットは惜しみなく、かつ意図的に取りましょう。スナップショットは、ある瞬間のゲストの完全な状態――ディスク、メモリ、設定、すべて――を捉えるため、後でクリック一つでその瞬間に正確に戻ることができます。ベータテストにおいて、これはあなたのシートベルトです。何も設定する前にクリーンインストールをスナップショットしてください。ベータに登録する前、大きなアップデートの前、実験的なものを実行する前にも再度スナップショットを取りましょう。テストでゲストが壊れたり、ベータへのアップグレードが失敗したりしても、ゼロから作り直すのではなく数秒でロールバックできます。新規インストールが塞がれたホスト上では、それがなければ Tahoe からアップグレードする一連の作業をもう一度やり直すはめになるところです。

これに関して小さな規律を身につけましょう。区別のつかない名前なしの復元ポイントを積み上げるのではなく、各スナップショットが何を表しているか分かるように名前を付けてください――「クリーン Tahoe」「ベータ登録済み・アップグレード前」「27 インストール済み・テスト前」のように。もう必要ない古いスナップショットは、それぞれディスク容量を消費するので削除してください。ただし主要なマイルストーンは残しておきましょう。一致する Tahoe のベースラインスナップショットと動作する 27 のスナップショットを組み合わせれば、安定環境とベータ環境をほぼ瞬時に切り替えられます。これこそが、この作業において VM がベアメタルより優れている柔軟性です。スナップショットは後回しにするものではなく、成果物そのものとして扱ってください。実行中の 27 ゲストが価値を持つのは、まさにいつでも既知の良好なバージョンに戻れるからです。

より安全な代替手段：独立した APFS ボリュームまたは外付けディスク

ベータを慎重にテストする方法は VM だけではなく、目的によっては VM が最善の選択肢とは限りません。特に現在のインストール不具合を踏まえると、ハードウェアに近い 2 つのアプローチが検討に値します。1 つ目は、Mac の内蔵ドライブ上の独立した APFS ボリュームです。APFS では複数のボリュームが同じ物理容量を共有できるため、既存のコンテナに新しいボリュームを追加し、そこに macOS 27 をインストールし、テストしたいときにそこから起動できます。実データの入ったメインボリュームは完全に切り離されたままです。起動時にどのボリュームから起動するかを選べ、ベータは自分専用の空間で動作します。これは実機上でフルスピードで動作するため、VM では忠実に再現できないパフォーマンスや GPU 関連の要素が絡む作業で重要になり、これは仮想化インストールではなく通常のハードウェア上のインストールであるため、フレームワークのインストーラーの不具合を完全に回避できます。

2 つ目の選択肢は外付けディスクです。ベータを高速な外付け SSD にインストールしてそこから Mac を起動すれば、内蔵ドライブにまったく触れない完全に独立したテスト環境が得られます。外付けを取り外せば、Mac は手つかずの安定版システムに直接戻って起動します。独立ボリュームのアプローチと同様、これも実際のシリコン上で動作し、仮想化インストーラー経路を回避するため、「installation failed」の不具合は関係ありません。

これらを VM と正直に比較検討してください。トレードオフは、独立ボリュームも外付けディスクも、VM を反復作業でこれほど高速にしている即時のスナップショット＆ロールバックのループを提供しない点であり――実際のインストールを元に戻すには再インストールか復元が必要で、クリック一つでは済みません――どちらも、通常の作業と並行してウィンドウ内でベータを実行するのではなく、環境を切り替えるために再起動が必要です。しかし、これらはネイティブ速度で動作し、実際のハードウェアの挙動を正確に表し、そして今のところ VM インストールを阻んでいるまさにその不具合には影響されません。テストの目的が、ソフトウェアを高速に反復することではなく、実世界のパフォーマンスやドライバーの挙動、ハードウェア機能を評価することであれば、独立ボリュームや外付けディスクの方が実際には賢い選択肢かもしれませんし、メインシステムを手つかずに保つ真に安全な方法でもあります。

知っておくべき Apple Silicon 仮想化の制限

動作する macOS 27 ゲストを手に入れた後でも、Apple が macOS の仮想化に課している境界を理解しておくと役立ちます。それによって VM 内で現実的に何ができるかが決まり、そうでなければ不具合に見えてしまうような挙動の一部も説明がつくからです。

2 台までのライセンス規定

歴史的に、Apple のソフトウェアライセンス条項は、1 台のホスト上で実行できる macOS 仮想マシンの数を制限しており、一般的にはホスト自体に加えて Mac 1 台あたり macOS ゲスト最大 2 台までと理解されています。これは技術的な壁というよりライセンス上の制約ですが、実在する制限であり、1 台のマシンで並行テスト用の macOS 27 ゲストの一群を丸ごと立ち上げるつもりだった場合には重要になります。それ以上が必要であれば、追加のホストが必要です。ほとんどの個人開発者やパワーユーザーにとっては、クリーンなベースラインと稼働中のテスト環境の 2 台で十分ですが、CI マトリクスを構築するチームは、1 台の高性能な Mac が無制限に macOS ゲストをホストできると想定するのではなく、この 1 ホストあたりの上限をキャパシティプランニングに組み込むべきです。

ゲスト内では利用できない DRM と一部の iCloud サービス

Apple silicon 上の Apple Virtualization framework で動作する macOS ゲストは、特定の保護されたサービスにアクセスできません。実際には、一部の DRM で保護されたコンテンツや、多くの iCloud およびアカウント連携サービスが、ゲスト内でサインインできなかったり、完全には機能しなかったりします。仮想マシンは実機の Mac と同じハードウェアアイデンティティやセキュアな証明を提示できず、Apple は特定のサービスをそれに基づいてゲートしています。そのため、テスト計画の一部にデバイスレベルの DRM や特定の iCloud 権限に依存するサービスへのサインインが含まれる場合、VM 内では摩擦や完全な拒否を覚悟してください。これは設計上の仕様であり、あなたの環境の不具合ではありません。特定の種類のテストにおいて、実機上の独立ボリュームや外付けディスクの方が優れた環境である理由がもう一つ増えたことになります。これをあらかじめ知っておけば、実際には仮想化の境界が正しく機能しているだけなのに、ベータ自体が壊れていると結論づけてしまうことを避けられます。

これらの制限はインストール不具合を回避する上での障害ではありませんが、期待値を設定するものです。VM は OS や API、ほとんどのアプリを試すには非常に優れていますが、少数のハードウェア紐付き・アカウント紐付きの機能からは意図的に締め出されています。それに応じてテスト計画を立て、そうした境界にぶつかる作業については実機インストールに頼ってください。

よくある問題のトラブルシューティング

問題：VM を何度作り直しても、どのアプリを使っても、macOS 27 のインストールが同じ箇所で失敗する。

解決策： これはローカルの設定ミスではなく、ホストフレームワークの不具合の特徴です。失敗はアプリやあなたの設定ではなく、共有された Apple のインストーラー経路の中にあるため、VM を作り直しても助けになりません。リトライをやめて戦略を切り替えましょう。回避策 2 を使って Tahoe ゲストを構築し内部から 27 にアップグレードするか、すでに 27 を実行している Mac 上でゲストを構築してください。

問題：VM アプリを最新版に更新したが、それでもインストールが失敗する。

解決策： アプリのアップデート単体では、ホスト OS の Virtualization framework 内にある不具合を修正できないことがあります。アプリは Apple のインストーラー API をラップしているだけなので、その API が 26.6 ホスト上で 27 のイメージを処理できない場合、新しいアプリのビルドでも同じ壁にぶつかります。ホストを macOS 27 に移行するか、Tahoe からアップグレードする経路を使うか、不一致を解消するホストまたはベータのアップデートを待ってください。

問題：自分の失敗が IPSW の破損なのか、既知の不具合なのか判断できない。

解決策： まず復元イメージを検証してください。ファイルサイズが入手元の記載と一致するか確認し、公開されているチェックサムがあれば確認します。破損したファイルは通常、より早い段階で、異なる形で失敗します。チェックサムを検証済みのイメージでも、進捗バーが 1〜2 分進んだ後に一般的な「installation failed」メッセージで終わるように失敗し、しかもアプリ間で同じように失敗するのであれば、それは壊れたダウンロードではなくフレームワークの不具合を見ているということです。

問題：Tahoe VM は問題なくインストールできるが、ゲスト内のソフトウェアアップデートで macOS 27 ベータが提示されない。

解決策： 実機の Mac と同様、ゲストもまず正しいベータトラックに登録されている必要があります。ゲスト内でシステム設定を開き、「一般」から「ソフトウェアアップデート」に進み、ベータアップデートの設定を使って macOS 27 を提供する Apple Beta プログラムのトラックに参加してください。登録後、27 ベータが利用可能なアップグレードとして表示されるはずです。ロールバックできるよう、ダウンロードを始める前にスナップショットを取っておきましょう。

問題：一部の iCloud やメディアサービスが macOS 27 ゲスト内でサインインまたは動作しない。

解決策： これは想定内の挙動です。Apple silicon 上の macOS ゲストは、VM が実機の Mac と同じハードウェアアイデンティティを提示できないため、一部の DRM で保護されたサービスやアカウント連携サービスにアクセスできません。これは意図的な仮想化の境界であり、ベータの不具合ではありません。それらの特定のサービスをどうしてもテストする必要がある場合は、VM の代わりに実機上の独立した APFS ボリュームや外付けディスクにベータをインストールしてください。

FAQ

「installation failed」エラーは自分の VM アプリの不具合ですか、それとも macOS 自体の不具合ですか。

macOS 自体の不具合です。具体的には、macOS 26.6 ホスト上で macOS 27 の復元イメージを処理する Virtualization framework のインストーラー経路にあります。Apple はこれを既知の問題として認めています。UTM、VirtualBuddy、Tart、Parallels、VMware Fusion がすべて同じように失敗するのは、いずれかのアプリに問題があるからではなく、これらすべてが同じ Apple のインストーラーを共有しているからです。

VM アプリを再インストールしたり、IPSW を再ダウンロードしたりすれば直りますか。

いいえ。不具合はアプリやファイルではなくホストの Virtualization framework の中にあるため、アプリの再インストールや検証済みの復元イメージの再ダウンロードでは何も変わりません。どちらもここでよくある時間の無駄です。本当に効果のある修正は、ホストを macOS 27 に移行すること、Tahoe ゲストを内部から Software Update でアップグレードすること、あるいは修正アップデートを待つことだけです。

2 台目の Mac なしで macOS 27 を VM にインストールできますか。

はい。回避策 2 を使ってください。既存の Tahoe ホスト上で macOS Tahoe 仮想マシンを作成し、起動し、ソフトウェアアップデートで Apple Beta プログラムに登録し、そのゲストをそのまま macOS 27 にアップグレードします。ゲスト内でのアップデート経路は壊れたフレームワークのインストーラーを回避するため、1 台の Mac だけで動作する macOS 27 ゲストにたどり着けます。

独立した APFS ボリュームでのテストは VM より安全ですか。

データの観点からは間違いなくより安全であり、これは仮想化インストールではなく実機上での通常のインストールであるため、この特定の不具合も回避できます。トレードオフは、即時のスナップショットロールバックを失い、環境を切り替えるには再起動が必要になることです。実際のパフォーマンスやハードウェアの挙動を評価するには優れていますが、ソフトウェアを高速に反復するには、動作させられるのであれば VM のスナップショットの方がまだ勝ります。

1 台の Mac で macOS 27 の VM をいくつ実行できますか。

Apple のライセンス条項は歴史的に、ホスト自体に加えて 1 ホストあたり macOS ゲスト 2 台までに制限してきました。これは技術的な制約ではなくライセンス上の規定ですが、実在するものであり、並行テストを計画している人には重要です。同時に動作する macOS ゲストがさらに必要な場合は、1 台に詰め込むのではなく、追加のホストマシンが必要です。

Apple が修正するのを待つべきですか。

気軽に探索していて期限がないのであれば、待つのは合理的です。後続のベータビルド、ホストのアップデート、更新されたフレームワークによって直接インストールが復活する可能性があり、ベータは速いペースで反復されます。macOS 27 のサンドボックスに依存する実際の作業がある場合は待たないでください。Tahoe からアップグレードする経路を使って今日動作するゲストを手に入れ、将来の修正はおまけと捉えましょう。

まとめ

macOS 27 ベータが仮想マシンにインストールを拒否するという問題は、個人的な失敗のように感じられるものの、実際にはまったくそうではないという典型例です。一般的な「installation failed」というメッセージの裏には、Apple も認めている具体的な原因があります。macOS Tahoe 26.6 ホストは、より新しい macOS 27 の復元イメージを配置するために Virtualization framework のインストーラーを動かすことができず、その結果、この共有フレームワーク上に構築されたすべてのアプリ――UTM、VirtualBuddy、Tart、Parallels、VMware Fusion――が同じ地点で失敗します。インストーラーがアプリではなく Apple のフレームワークの中に存在すると理解すれば、同一の失敗にも納得がいき、無駄なリトライは止まり、進むべき道が明確になります。VM の設定でどれだけ手を尽くしても、ホストに組み込まれた壁を動かすことはできません。

良い知らせは、これを回避する 3 つの実際に有効な方法と、1 つの本当に安全な代替手段があることです。余っている Mac があれば、すでに macOS 27 を実行している Mac 上でゲストを構築してください。Mac が 1 台しかない場合は、Tahoe ゲストをインストールして内部から Software Update でベータにアップグレードすれば、壊れたインストーラーをきれいに回避できます。あるいは、影響を受けるビルドが変わり得る流動的なベータ状況であることを踏まえ、ギャップを埋めるベータビルド、ホストのアップデート、アプリのアップデートを単純に待つという手もあります。そして、スナップショット速度での反復が必要でないなら、独立した APFS ボリュームや外付けの起動ディスクを使えば、この不具合の影響を受けず、メインシステムを手つかずに保てる、フルスピードの実機テスト環境が手に入ります。どの経路を取るにせよ、スナップショットは早め・こまめに取り、2 台までのライセンス上限やゲスト内の DRM・iCloud の境界に注意し、検証済みの IPSW を手元に用意しておきましょう。

ベータの道をどこまで進むべきか迷っているなら、まずは広い文脈に計画の軸足を置いてください。macOS 27 で何が変わり、いつ出荷されるのか を読み、Rosetta 2 終了と Intel アプリの移行 に照らしてお使いのアプリを点検し、最終的な Intel Mac 互換性リスト であなたのハードウェアがどこに位置するかを確認しましょう。賢くテストし、逃げ道をいつでも使える状態にしておき、VM に本来の役割を果たさせましょう――リスクを引き受けさせ、あなたの実機の Mac が二度とその必要に迫られないように。