「MacがなくてもmacOSアプリが動く」——200超のツールをLinux上で直接実行するオープンソース「Kakehashi」

「AppleのソフトウェアはMac上でしか動かない」——長年当然とされてきたこの常識に、大きな一石が投じられました。2026年8月初旬、世界最大級の技術掲示板 Hacker News で「Kakehashi（架け橋）」と名付けられたオープンソースプロジェクトが話題となり、156ポイント・34件のディスカッションを獲得しました。このプロジェクトが目指すものは極めてシンプルです。ARM仕様のLinuxマシン上で、macOSをインストールすることも仮想マシン（VM）を使うこともなく、macOS用アプリを直接実行することです。現時点で200以上のmacOS標準コマンドラインツールが動作し、解凍・圧縮ソフトの 7-Zip も正常に機能しています。Appleの「ハードとソフトの完全統合」という堅牢な壁に、初めて本気の技術的アプローチで穴が開けられようとしています。

図：Hacker Newsに投稿されたKakehashiの発表スレッド。作者がコメント欄で進捗や技術仕様について回答している。出典：news.ycombinator.com

なぜ「あり得ない」と思われていたのか

一般のユーザーにとって、AppleのソフトウェアとMacハードウェアは不可分な存在です。Mac用に作られたアプリを他のPCに持っていっても起動すらしないのは偶然ではなく、Appleの緻密なビジネス設計によるものです。

Appleのビジネスモデルは、ハードウェア販売とソフトウェアエコシステムを強力に結びつけています。macOSのライセンス利用規約（EULA）には「Appleブランドのハードウェア上でのみ実行可能」と明記されており、他社製端末へのインストールは規約違反となります。さらにApp Storeの手数料やクラウドサービスが連携し、**Macを購入すること自体が「庭園への入場チケット」**となっています。そのため、他OS上でmacOSアプリを動かすには、重くリソースを消費するVMでmacOS全体をエミュレートするか、グレーゾーンである「Hackintosh（夢のMac）」を構築するしか選択肢がありませんでした。

Kakehashi はそのどちらでもない「第3の道」、すなわち「OSを移植するのではなく、アプリの実行環境だけを移植する」というアプローチをとっています。

どうやって動かしているのか：システムレベルの「通訳」

macOSアプリをLinux上で動かす最大の難関は、両者のシステム言語（ABIやシステムコール）が異なる点にあります。これまでは、Appleの独自フレームワークやカーネル動作を丸ごと持ってこない限り会話が成り立ちませんでした。

Kakehashi の着眼点は、**「Apple Silicon（Mシリーズ）とLinuxが動く最新のARM PCは、根本で同じ言語（ARM命令セット）を話している」**という事実にあります。CPUレベルの命令が同一であるため、アプリのバイナリ自体はエミュレーションなしで直接Linux CPU上で実行できます。通訳が必要なのは、アプリが「ファイルを開く」「ネットワークに接続する」「メモリを確保する」といったOSに処理を依頼する局面（システムコール）だけです。Kakehashi はこの境界で通訳として機能し、macOSアプリからのOS要求をリアルタイムでLinuxの対応する動作に変換して結果を返します。

図：AppleのMシリーズチップと一般的なLinux ARM端末は同じARMアーキテクチャを共有しているため、バイナリ変換のオーバーヘッドを劇的に削減できる。出典：Wikimedia Commons

このような仕組みは「互換レイヤー（compatibility layer）」と呼ばれ、WindowsアプリをLinuxで動かす「Wine」が最も有名な先行例です。

30年前にも同じ挑戦があった

1993年、WindowsアプリをLinuxで動かすという壮大な目標を掲げて「Wine」プロジェクトがスタートしました。当時「膨大なWindows APIを再現するなど不可能だ」と懐疑的な声が支配的でしたが、30年におよぶ開発の積み重ねにより、Wineは実用的なテクノロジーへと進化しました。

現在、Wineは巨大なエコシステムへと成長しています。Valveの携帯型ゲーム機「Steam Deck」に搭載されているProtonもWineをベースにしており、何万人ものゲーマーが手元のLinuxデバイスでWindowsゲームを楽しんでいます。かつて「無謀」と言われたプロジェクトが、今や大手ハードウェアビジネスの基盤となっているのです。

macOSアプリの架け橋を目指したプロジェクトは Kakehashi が初ではありません。過去には「Darling」というプロジェクトが先行していましたが、進捗は緩やかでした。Kakehashi の作者はHacker News上で、本プロジェクトはDarlingのフォークではなくRust言語で一から書き直した独立実装であり、カーネル空間を使わずユーザー空間のみで動作するため高い安全性を確保していると説明しています。また、開発過程でAIによるコード生成を活用したことについても触れ、議論を呼びましたが、コードはすべてオープンソースであり誰でも監査可能であると回答しています。

「5.2倍遅い」は致命的なのか

現在公表されている注目すべきベンチマークとして、7-Zip による8,000ファイル・計240MBのデータ圧縮テストがあります。処理結果は完全かつ正確に一致したものの、実行速度はLinuxネイティブ版の5.2倍遅い結果となりました（ネイティブ22.5秒に対し、Kakehashi経由では118秒）。一方で、200以上の curl ネットワークコマンドの自動テストをパスし、Appleの Xcode に付属する Git バージョン管理ツールの基本機能も動作しています。

5.2倍という数字は一見大きく見えますが、互換レイヤーの初期段階としては「想定内のコスト」と言えます。遅延の主な原因は、システムコール発生時の通訳処理（コンテキストスイッチ）にあります。小規模なファイルアクセスが大量に発生するタスクではオーバーヘッドが顕著になりますが、大きな単一ファイルを処理するケースでは速度差は1.1〜1.2倍程度に収まります。初期のWineも同様のパフォーマンス課題を抱えていました。作者は今後のロードマップとして、Xcode の完全なツールチェーン（iOSアプリのビルド含む）や macOS版 Homebrew の対応を掲げており、これこそが開発者にとって真の主戦場となります。

一方で、コミュニティからは「Appleは毎年のメジャーアップデートで内部APIを頻繁に変更するため、互換レイヤー側は永遠に後追いせざるを得ない」という冷ややかな指摘もあります。囲い込みを強化するプラットフォームとの非対称な戦いであることは間違いありません。

この「小さな穴」が意味するもの

より大きな視点で見れば、これは「オープン」と「クローズド」の思想的対立の新たな局面です。オープンソースコミュニティは「ソフトウェアはハードウェアに縛られず自由に動くべきだ」と主張し、Appleは「統合された庭園内こそが最高のユーザー体験を提供する」と主張してきました。

もし将来、XcodeやMac専用のデザイン・音楽・映像制作ツールが手頃なARM PC上で動作するようになれば、Appleのハードウェアにおける参入障壁（護城河）はどのように変化するでしょうか。歴史が示しているように、WineによってWindowsが衰退したわけではなく、むしろ「Windowsアプリがどこでも動く環境」が整ったことでソフトウェアの価値が高まりました。壁に穴が開いたからといって庭園が崩壊するとは限りませんが、庭師（Apple）は壁の外の世界を意識せざるを得なくなります。

Kakehashi の挑戦がどこまで到達するかは未知数です。5.2倍の速度差、アップデートされるOSインターフェース、ライセンス上の課題など乗り越えるべきハードルは山積みです。しかし、1993年にWineが誕生したとき、それが将来ポータブルゲーム機を支えることになると予測した人がいなかったことも事実です。すべての巨大な変化は、壁にできた一つの小さな穴から始まるのです。

参照リンク：

• Kakehashi GitHub リポジトリ（wie-project）：プロジェクトページ、README、アーキテクチャドキュメント、ロードマップ
• HN ディスカッション（item?id=49145937）：作者による7-Zip、curl、Xcode Gitの進捗説明およびDarlingとの違い
• Wine 公式歴史ドキュメント：WineHQ「Wine Is Not an Emulator」プロジェクト概要
• Wine Wikipedia エントリ：1993年の誕生から現在までの歴史とSteam Deckでの活用