MacはいまやM4・M5チップで世界トップクラスの処理性能を誇ります。それでも、VRの世界では長らく「対応外」に置かれてきました。AppleがOpenXRを自社プラットフォームに採用しないため、PCVRの標準エコシステムはmacOSをスコープ外とし続けてきたからです。そのギャップを、ベテランVR開発者1人がコミュニティ発の仕組みで埋めようとしています。
VR開発者のYannick Comte氏が開発する「OpenXR OSX」は、macOS上でOpenXRアプリケーション（OpenXR SDK でMac向けにビルドされたPCVRゲーム）を動作させるためのランタイムだ。MacにOpenXRランタイムをインストールし、Quest 2/3などのスタンドアロンHMDにストリーミングすることで、OpenXR対応のPCVRゲームをMacからプレイできるようになる。
構成は、macOS向けOpenXRランタイム（簡素なSteamVR相当）、HMD向けシンクライアント（Quest 2/3対応、Vision Pro版は検証中）、macOS向けシミュレーターの3点。ハンドトラッキングとコントローラーの両方に対応している。現状の課題はレイテンシー、コマンドラインによる起動操作、Wi-Fiのみの接続の3点だが、M5 GPUでのテストでは描画は滑らかだったと報告されている。リリースはオープンソースで2026年5月中が見込まれており、現時点では未公開。AppleがOpenXRを採用していないため、これまでPCVRアプリはmacOS上で動作できなかった。
From: 
OpenXR OSX lets you play PCVR games on Mac
【編集部解説】
Appleの「不参加」は、本当は「不採用」である
元記事では「AppleはOpenXRコンソーシアムに参加していない」と記述されています。しかし、実態はもう少し複雑です。
OpenXRを管理するKhronos Group（クロノス・グループ）には、AppleがPromoter Memberとして最上位の階層で名を連ねています。これはAMD、NVIDIA、Google、Samsung、Sony、Valveなどと同列の、規格策定にもっとも深く関与できる立場です。Promoter Memberは、Khronos傘下のすべての作業部会に参加し、ガバナンスにも関わる権限を持っています。
ところが、OpenXRの公開支持企業リストにはAppleの名前がありません。OpenXRが2019年に暫定仕様として公開された当時から、この「いるはずの場所にいない」状態が続いています。
つまり、AppleはOpenXRの議論にアクセスできる立場にありながら、自社プラットフォーム——macOSにもvisionOSにも——OpenXRを採用していないのです。これは「コンソーシアムに参加していない」のではなく、「参加しながら採用を選ばなかった」と言うべき構図です。Apple Vision Proが採用しているのは、ARKit、Metal、RealityKit、CompositorServicesといった独自APIの組み合わせです。
規格に乗らないことは、Appleの一貫した戦略である
この構図を、Appleの過去の選択と並べて見ると、ある一貫性が浮かび上がります。
グラフィックスAPIの世界で、AppleはかつてOpenGLを長く使っていましたが、2014年にiOS向けにMetalを導入し（Mac対応は2015年）、2018年にはOpenGLとOpenCLを「非推奨」に格下げしました。Web技術ではWebKit（Safari）の独自路線、メッセージングではiMessage、決済ではApple Pay。共通APIに乗ることでエコシステム全体の利便性を上げるよりも、自社プラットフォーム内の体験を磨き上げ、移行コストの高い壁を作ることを選んできました。
Vision Proでも同じ判断がなされたと考えるのが自然です。Vision Proで動くアプリがそのままQuestやPicoで動いてしまえば、Appleが約3,500ドルの価格に見合うとして主張する「空間コンピューティング体験」の独自性は、相対化されてしまいます。OpenXRに乗らないことで、Vision Proのコンテンツエコシステムは「Vision Proでしか体験できないもの」として囲い込まれます。
ただし、この戦略には代償も伴います。Unreal Engine 5は、Vision Pro向けビルドの内部でOpenXRをvisionOS API向けに変換するブリッジを実装しました。開発者にとっては、OpenXRを書けばVision Proでも動く、という構図が事実上できています。Appleが「公式には」OpenXRを採用しないまま、ゲームエンジンレイヤーで開発者が橋を架けてしまっているのです。
Yannick Comte氏が架ける、もうひとつの橋
そうしたAppleの自社API体系が続く外側で、全く異なるアプローチが動き始めています。
OpenXR OSXは、「橋を架ける」という行為を、エンジンの先のランタイム層でやろうとする試みです。
開発者Yannick Comte氏は、Unreal Engine向けのOpenXRハンドトラッキングプラグインや、各種VRシミュレーターを長年単独で開発してきた人物です。本人は今回のmacOS向けOpenXRランタイムについて、LinkedInで「ゼロから（from scratch）」構築していると述べています。実装はC++で書かれ、グラフィックスにはAppleのMetalと、MoltenVK経由のVulkanを使う構成だと公開されています。Vulkan APIをそのままmacOSで動かすのではなく、MetalにマップするMoltenVKを噛ませる——Apple独自のグラフィックスAPIスタックを尊重しつつ、OpenXRのクロスプラットフォーム性を保つための、現実的な設計です。
注目に値するのは、これが1人の開発者の発意で動いているプロジェクトだということです。
個人開発者が、プラットフォーム間の溝を埋めてきた歴史
VR/XRの世界では、プラットフォーム間の橋渡しを個人開発者や小規模コミュニティが担ってきた系譜があります。
最も有名な例の一つが、PCVRをスタンドアロンHMDに無線でストリーミングするALVRです。これは2018年頃にpolygrapheneという開発者が個人で立ち上げたオープンソースプロジェクトで、当初はGear VRやOculus Go向けでした。その後オリジナル開発者がメンテナンスを離れ、alvr-orgというコミュニティ組織が継承して現在まで開発が続いています。Linux向けのOpenXRランタイムMonado、有償のVRストリーミングソフトVirtual Desktop（Guy Godin氏が開発・運営する個人発のプロダクト）など、いま当たり前のように使われている基盤の多くが、最初は1人または少数の開発者の手から生まれています。
この構図には、考えるべきことが二つあります。
ひとつは、健全さです。プラットフォームホルダー（Apple、Meta、Microsoft、Valveなど）が引いた線を、個人や小コミュニティが自発的に越えていける——これはオープンな開発文化の強さです。誰の許可も要らず、誰の戦略にも従属しない橋を架けることができる。OpenXRという規格そのものが、その越境を制度的に支えている、とも言えます。
もうひとつは、脆弱さです。Yannick氏自身が記事内で言及している通り、現状OpenXR OSXには明確な課題があります。レイテンシーの問題、コマンドラインによる起動の煩雑さ、Wi-Fi接続のみで有線非対応。これらを解決するには、コミュニティの貢献が必要です。逆に言えば、もしコミュニティが集まらなければ、このプロジェクトは個人の余暇に依存することになります。私たちがいま「Macで使えるPCVRランタイム」と呼ぶインフラは、1人の開発者が他のことに忙しくなった瞬間に止まりうる、ということでもあります。
三大OS対応の意味と、その先に残る問い
OpenXR OSXがリリースされ、コミュニティの貢献が集まれば、OpenXRアプリケーションはWindows（SteamVR、Quest Link）、Linux（Monado）、macOS（OpenXR OSX）の三大OSで動作することになります。これは、規格の理念が技術的に実現する瞬間です。
ただし、ここで注意したい点があります。Apple自身の態度は、何も変わっていないということです。OpenXR OSXは、Appleが提供しているわけでも、Appleが祝福しているわけでもありません。Macが「PCVR対応」と呼べるかどうかは、依然として一人の開発者と、その周りに集まるコミュニティの手にかかっています。
そして、Vision Proの位置づけも残されたままです。OpenXR OSX上のVision Pro向けクライアントは、まだシミュレーターでしか検証されていません。Vision Proは、Quest 2/3とは異なり、開発者がアプリを自由にサイドロードしにくい仕様の上に成り立っており、ストリーミング・クライアントを成立させるためのハードルがそもそも高い構造になっています。
OpenXR本来のビジョンは「あらゆるデバイスで同じコンテンツが動く」ことでした。しかし実際には、その理念に最も同調しないプレイヤー（Apple）が、最も注目される空間コンピューティングデバイスを世に出している、という捻れがあります。OpenXR OSXはこの捻れを部分的に和らげる試みですが、根本的に解消するものではありません。
ある規格の価値は、それを採用したプレイヤーの数だけで決まるのではなく、採用しないプレイヤーをどう扱うかでも問われます。OpenXR OSXが私たちに見せているのは、その問いの最前線です。
【用語解説】
OpenXR
VR・ARデバイスを横断してアプリケーションの互換性を保証するオープン規格。Khronos Groupが管理。開発者が一度書いたコードを複数のデバイスで動かせることを目指す。
PCVR
PCに接続して使用するVRの総称。Meta QuestなどのスタンドアロンHMDと対比されるカテゴリ。SteamVRが代表的なPCVRプラットフォーム。
スタンドアロンHMD
外部PCなしで単体動作するVRヘッドセット。Meta Quest 2/3、Picoなどが代表例。内蔵チップで処理を完結させる。
OpenXRランタイム
OpenXR APIとVRハードウェアの間を仲介するソフトウェア層。SteamVR、Quest Link、Monado、そして今回のOpenXR OSXがこれにあたる。アプリはランタイムを通じてデバイスと通信する。
Khronos Group（クロノス・グループ）
OpenGL、Vulkan、OpenXRなどグラフィックス・XR領域の標準規格を策定する業界コンソーシアム。AMD、NVIDIA、Google、Apple、Meta、Valveなどが参加。
ALVR（Air Light VR）
PCVRのコンテンツをスタンドアロンHMDに無線ストリーミングするオープンソースソフトウェア。もとはOpenVR（SteamVR）ベース。2018年に個人開発者が立ち上げ、現在はコミュニティ組織（alvr-org）が継承・開発を続けている。
Monado
Linux向けのオープンソースOpenXRランタイム。Collaboraが主導して開発。HTC Vive、Valve Indexなど多数のHMDに対応し、LinuxでPCVRを実現する主要な手段のひとつ。
Metal
AppleがmacOSおよびiOS向けに提供する独自の低レベルGPU API。2014年にiOS向けに導入され、2015年にMacへ展開。2018年にはOpenGLをmacOSで「非推奨」に格下げした。OpenXR OSXはグラフィックスレンダリングにMetalを使用。
MoltenVK
Khronos Group管理のオープンソースライブラリ。Vulkan APIの呼び出しをAppleのMetalに変換する。macOS・iOSでVulkanを使うソフトウェアを動かすために使われる。OpenXR OSXの内部実装にも採用されている。
サイドロード
公式アプリストアを経由せずにアプリをデバイスにインストールする行為。Meta Quest（Androidベース）ではDeveloper Modeを有効にすることで比較的容易に可能。Apple Vision Pro（visionOS）は仕組みが異なり、サイドロードの自由度が低い。
【参考リンク】
OpenXR — Khronos Group（外部）
OpenXR規格の公式ページ。仕様書、採用企業リスト、SDKへのリンクなどを掲載。開発者向けの一次情報源。
Yannick Comte — LinkedIn（外部）
OpenXR OSX開発者のLinkedInプロフィール。開発の進捗や技術的な詳細をこちらで発信している。コントリビューションに関心がある場合の連絡先でもある。
Yannick Comte — X（@CYannick）（外部）
開発者のXアカウント。OpenXR OSXに関する最新情報やデモ映像はここで随時共有されている。
ALVR — GitHub（alvr-org）（外部）
PCVRをスタンドアロンHMDに無線ストリーミングするオープンソースプロジェクト。現在も活発に開発が続くコミュニティ継承型プロジェクトの実例。
Monado — freedesktop.org（外部）
Linux向けオープンソースOpenXRランタイム。OpenXR OSXと並ぶ「プラットフォームの壁を超えるランタイム」の先行事例。ソースコードや対応デバイスの情報を掲載。
MoltenVK — GitHub（KhronosGroup）（外部）
Vulkan APIをAppleのMetalに変換するオープンソースライブラリ。OpenXR OSXの内部実装を理解するうえでの参照先。Khronos Group管理のもとAppleも協力する形で開発されている。
【参考記事】
Apple missing from list of companies supporting OpenXR AR and VR spec — AppleInsider（2019年3月）（外部）
OpenXRが2019年に暫定仕様として公開された際、AppleがKhronos Group会員でありながらOpenXRの公開支持企業リストに含まれていないことを報じた記事。編集部解説の「不参加ではなく不採用」という分析の一次情報源。
Yannick Comte — LinkedIn投稿（2024年以降）（外部）
開発者本人による技術的説明（C++・Metal・MoltenVK経由のVulkan・Quest 3とPicoでの動作確認）の一次情報源として参照。
ALVR（オリジナルリポジトリ） — GitHub（polygraphene）（外部）
ALVRのオリジナル開発リポジトリ。個人発のオープンソースプロジェクトがコミュニティに継承される経緯の確認に使用。
【編集部後記】
私たちは規格や互換性の話を、つい大企業同士の交渉として捉えがちです。けれどOpenXRをWindows・Linux・macOSの三方向に届ける最後の橋を架けようとしているのは、1人の開発者と、その周りに集まるかもしれないコミュニティです。日々使う技術基盤の少なくない部分は、特定の誰かの選択と時間に依存している——そのことに気づくと、「対応している」「対応していない」という言葉の見え方も、少し変わってきます。
