Apple SiliconのMacで、Linuxディストロ「Omarchy」をそのまま動かすTry Omarchyというアプリ

当サイトでは以前、Linuxディストリビューション「Omarchy」のエコシステムから発足した非営利財団Omacomを扱った。そのOmarchyを、Linux機を用意せずMac上でそのまま動かすための非公式アプリ「Try Omarchy」が、2026年8月23日にGitHubへ公開されている。本記事の初稿確認時点(8月27日)でリポジトリ作成から4日というできたばかりのプロジェクトだったが、加筆にあたり2026年8月31日にGitHub APIで再確認したところ、star数964・フォーク数42まで伸びており、直近pushも同日(8月30日)と、公開から1週間強で活発に更新が続いていることが分かった。

3行まとめ

1. Try Omarchyは、Apple Silicon Mac上でOmarchy本体を、Apple Hypervisor Framework+QEMU+VirGLによるハードウェアアクセラレーション付きの仮想マシンとして動かすSwift/AppKit製アプリ
2. Mac↔Omarchy間のクリップボード共有(テキスト・PNG)、1つのMacフォルダの共有、音声入出力の切り替えなど、単なるVMを超えた統合機能を備える
3. 動画デコードは現時点でCPUのみのため高解像度再生は遅くなりうる、とREADME自身が明記している。Omarchy公式(Basecampやその作者DHH氏)による認定・提携はない非公式プロジェクト

Omacosyとは別物──「ネイティブ再現」ではなく「本体をそのまま動かす」

当サイトでは以前、macOS向けにOmarchy風のタイリング環境を再現する非公式ツール「Omacosy」も扱った。Omacosyは、macOS自体の上にHyprland風のウィンドウ管理を後付けする、SIP(System Integrity Protection)を無効化しない「再現」型のアプローチだった。

Try OmarchyはこれとはOSレベルで異なるアプローチを取る。READMEはプロジェクトの内容を次のように説明している。

Try Omarchy packages a project-built ARM64 Arch Linux image configured with Omarchy Quattro, a QEMU runtime using Apple Hypervisor Framework, and a small Swift/AppKit launcher into one macOS app. The image is built from pinned Arch Linux ARM packages and a pinned revision of the upstream Omarchy source.

(Try Omarchyは、Omarchy Quattroで構成されたプロジェクトビルドのARM64 Arch Linuxイメージ、Apple Hypervisor Frameworkを使ったQEMUランタイム、そして小さなSwift/AppKit製ランチャーを、1つのmacOSアプリにパッケージ化したものだ。イメージは、バージョン固定されたArch Linux ARMパッケージと、バージョン固定された上流Omarchyソースのリビジョンからビルドされている)

つまり、macOSの見た目をOmarchy風に「寄せる」のではなく、Omarchy Linuxそのものを、Apple製の仮想化フレームワーク上でハードウェアアクセラレーション付きで走らせる、という設計だ。READMEは「Try Omarchy is not official or affiliated with Omarchy(Try OmarchyはOmarchyの公式・提携プロジェクトではない)」とも明記している。

VM「らしくない」統合機能

READMEのHighlights欄には、単なる仮想マシンランチャーを超えた統合機能が並んでいる。

• Hardware-accelerated ARM64 virtualization and VirGL graphics
• Resizable native window with automatic guest resolution and HiDPI scale updates
• Mac audio input/output selection inside Omarchy, with live routing and system-default fallback
• Two-way clipboard sharing for text and PNG images between macOS and Omarchy
• One optional shared Mac folder, available inside Omarchy under the same name (~/Work stays ~/Work)

(・ハードウェアアクセラレーション付きのARM64仮想化とVirGLグラフィックス／・自動でゲスト解像度とHiDPIスケールが更新される、サイズ変更可能なネイティブウィンドウ／・Omarchy内からMacの音声入出力を選択でき、ライブでのルーティングとシステムデフォルトへのフォールバックに対応／・macOSとOmarchy間で、テキストとPNG画像の双方向クリップボード共有／・任意で1つのMacフォルダを共有可能。Omarchy内でも同じ名前で利用できる(~/Workは~/Workのまま)

クリップボード共有について、READMEはさらに具体的な挙動を説明している。

Copy and paste work in both directions as soon as you sign in to Omarchy: text and PNG images copied on the Mac appear in the Omarchy clipboard, and content copied in Omarchy lands on the Mac pasteboard. Nothing is transferred until something is copied.

(Omarchyにサインインすればすぐに、コピー&ペーストは双方向で機能する。Macでコピーしたテキストや画像はOmarchyのクリップボードに現れ、Omarchy内でコピーした内容はMacのペーストボードに届く。何かがコピーされるまでは、何も転送されない)

フォルダ共有は、共有をオフにした状態がデフォルトで、明示的にフォルダを選ぶまでは何も共有されないという設計になっている。

Folder sharing is off until you pick a folder. [...] The whole home folder, ~/Library, and system directories cannot be shared.

(フォルダ共有は、フォルダを選ぶまでオフになっている。[中略]ホームフォルダ全体、~/Library、システムディレクトリは共有できない)

ホームフォルダ全体やシステムディレクトリを共有対象から明示的に除外している点は、ゲストOS(Linux)側から見えるファイルの範囲を限定する設計意図として読み取れる。

動作要件と、今のところの弱点

READMEが挙げる動作要件は、Apple Silicon Mac(arm64)・macOS 15以降・初期状態で8GB以上の空き容量。永続的な仮想マシンのデータは~/Library/Application Support/Try Omarchy/VM/v1に置かれ、アプリを削除してもこのデータは残るという。

現時点での制約として、READMEは動画再生の遅さを自ら明記している。

Current limitation: Video decoding is CPU-only, so playback can be slow, especially at high resolutions. An improved video path is in development.

(現時点での制約:動画デコードはCPUのみで行われるため、特に高解像度では再生が遅くなることがある。改善された動画パスは開発中)

VirGLによるグラフィックスアクセラレーションは備えているものの、動画のハードウェアデコードには対応していないという、機能ごとの濃淡がある実装だと分かる。

v0.1.0からv0.2.0への変化——初回公開時にはなかった機能が増えている

READMEを2026年8月31日に再度curlで取得すると、本文執筆時点(8月27日)からさらに機能が追加されていた。GitHub APIでリリース一覧を確認すると、Try Omarchyはこれまでに2回のリリースを行っている。

（出典: api.github.com/repos/themartiano/try-omarchy/releasesのリリースノートを日本語要約。v0.2.0のリリースノートには「v0.1.0のディスクはv0.2.0へ自動移行されない」との注記もあった）

つまり、この記事で紹介した「クリップボード共有」「フォルダ共有」は、初回リリース(v0.1.0、8月25日)にはまだ存在せず、2日後のv0.2.0(8月27日)で追加されたばかりの機能だったことが、リリースノートから分かる——本文執筆時点(8月27日)のREADME確認は、ちょうどこの機能追加の直後だったことになる。

さらに8月31日時点のREADMEには、v0.2.0のリリースノートにも記載のない機能が新たに追加されていた。

• FaceTime HD and other Mac cameras exposed to Omarchy as an on-demand 720p webcam
• Loopback-only TCP and UDP port forwarding from the Mac into Omarchy

（・FaceTime HDなどMacのカメラを、オンデマンドの720p Webカメラとして Omarchy に公開／・Macからloopbackのみに限定したTCP・UDPポートフォワーディング）

docs/architecture.md(アーキテクチャ文書)を確認すると、これらの実装の技術的な仕組みも書かれていた。カメラ共有は、Mac側の署名済みヘルパーがAVFoundation経由で1280×720のNV12フレームを取得し、virtio-serialポート(dev.tryomarchy.camera)でゲスト側に転送、v4l2loopbackデバイス(/dev/video42)としてMac Cameraの名前でOmarchy内に公開する、という設計だという。クリップボード共有は、Mac側がNSPasteboardの変更カウントを監視するSwiftブリッジ、Omarchy側がwl-clipboardのdata-controlプロトコルを使うPythonエージェントで構成され、両者が別のvirtio-serialポート(dev.tryomarchy.clipboard)経由で改行区切りJSONをやり取りする。ポートフォワーディングは、ホスト側を常に127.0.0.1にのみバインドし、Try Omarchy自身がLAN向けのリスナーを作ることはない、と明記されている。

フォルダ共有についても、docs/architecture.mdはvirtio-9p(security_model=none)を使い、QEMUに独自パッチを当てたguest_owner_uid/guest_owner_gidオプションで、Mac側のファイルをOmarchy内の最初のアカウント(uid/gid 1000)所有として見せる、という実装だと説明している。

Omarchy本体をめぐっては、非営利のOmacom Foundationが2026年8月に発足し、3日で資金が1,000万ドルに達したことも当サイトで扱った。Try Omarchyはこの財団や作者DHH氏とは無関係の第三者プロジェクトだが、Omarchyというディストリビューションを取り巻く周辺プロジェクトが、財団化・Mac移植の両面で同時に活発化している時期だと言える。

開発は継続中、リポジトリはまだ4日目

gitのログこそ確認していないが、リポジトリ自体は2026年8月23日に作成されており、本記事の確認時点(8月27日)でまだ4日しか経っていない。README末尾は「Try Omarchy is pre-1.0 and under active development(Try Omarchyはpre-1.0であり、活発に開発中)」と明記している。開発ビルドの手順(Xcodeコマンドラインツール、Docker互換エンジン、複数のC言語ライブラリの特定バージョン指定など)も詳細に書かれており、単発の思いつきではなく継続的な開発体制を敷いていることがうかがえる。

作者はGitHubプロフィールとREADME末尾のクレジット「by @martiano」から、X(旧Twitter)アカウント@martianoを持つ人物と分かるが、それ以上の身元(所属や他プロジェクトとの関係)はREADMEからは確認できなかった。

実際には試していない

本記事はGitHubリポジトリのREADME本文(2026年8月27日・8月31日の2時点でcurl取得)、docs/architecture.md、GitHub APIのリリース情報にもとづく。実際にApple Silicon MacへTry Omarchyをインストールし、Omarchyを起動して動作を確認したわけではない。「初回起動でのアカウントプロビジョニングに時間がかかる」「クリップボード共有やフォルダ共有が実際にどの程度スムーズか」「カメラ共有やポートフォワーディングが説明通りに動くか」といった体感面は、README・アーキテクチャ文書に書かれた説明をそのまま紹介しているだけで、自分の手元で検証したものではない。SECURITY.md・docs/releasing.md・THIRD_PARTY_NOTICES.mdといった、READMEからリンクされている個別のドキュメントファイルまでは読み込んでいない。Zenn・Qiitaを検索した範囲でも日本語での言及は見当たらなかった。

普段からmacOSとLinuxを行き来する開発環境をVMで使い分けたことはあるが、Apple Hypervisor FrameworkベースのVMを深く比較検討した経験はなく、既存のVM系ツール(UTM、Parallelsなど)とのパフォーマンス差についてコメントできるだけの土地勘は持っていない。

感想・指摘はコメント欄へ。