Darling 開発アップデート – 2026年第4四半期

Development Update - Q4 2026

前回の進捗報告からしばらく経ちましたが、多くの変化がありました。このアップデートでは、プロジェクトにおける最大の変更点、すなわちAI支援コントリビューションに関する新ポリシー、初期のARM64サポート、そして今後の計画について説明します。

Our AI Policy​

今年プロジェクトにおける最大の変更は、新機能ではなくポリシーです。私たちはAI支援コントリビューションに関するルールを採用しました。これは現在多くのオープンソースプロジェクトで議論されている、賛否両論のあるトピックであり、低品質な「スラッジ」への懸念はもっともなことです。しかし、プロジェクトの内部構造を理解している人々の手にかかれば、LLMは非常に強力なツールとなり得ます。

Darlingの開発は常に楽しいものでしたが、トンネルの先の光を見るのは困難でもありました。現実を見てみましょう。Appleは多くのエンジニアを抱える巨大企業であり、常に新機能をリリースしています。ボランティアの小規模なグループでは、その能力には到底及びません。私は2012年にDarlingを開始しましたが、最近まで実際に動作する現実世界のmacOSアプリケーションはごくわずかでした。

Darlingはまた、Wineが享受しているような利点を持ったこともありませんでした。macOSアプリケーションのサーフェスはWindowsアプリケーションよりもはるかに小さいため、Linuxで実行することへの関心は低く、macOSの内部構造を十分に理解して支援できる開発者はさらに少なくなります。これにより、コントリビューターの獲得が困難になり、ValveがWineに提供したような商業的支援を引きつけることも同様に困難になります。プラットフォームの規模も問題です。AppleはmacOSでのみ提供されるフレームワークを次々と追加しています。ある集計によると、macOS 27には464の公開フレームワークと2,754のプライベートフレームワークが含まれており、macOS 10.14の273と878から増加しています。WineはMicrosoftの再配布可能ランタイムに依存でき、winetricksのようなツールがユーザーのためにそれらをフェッチしますが、Appleのフレームワークのほとんどにはダウンロードできるものがなく、それらを自社で実装する必要があります。Appleのエンジニアリング能力に匹敵することは、数人のボランティアにとって解決不可能な問題のように見えました。

今年、状況は変わりました。AIを多用するいくつかのフォークが登場し、印象的な成果を上げています。最も目立つ例の1つは、League of Legendsを実行するフォークです（YouTubeで動作する様子をご覧ください）。VibeDarlingも、いくつかのオリジナルのmacOSアプリケーションを動作させることに成功しています。

AIは方程式を変えます。かつてはコントリビューターが少なく解決不可能な問題だったものが、今では経済的に現実的になり、Appleとより対等な条件で競争できるようになります。

AIの使用を拒否することは、私たちにとって次の2つの意味を持つことになります。

• 私たちは取るに足らない存在になっていたでしょう。様々なフォークが極端な速度で進む中、私たちはごくわずかな機能しか動作しないまま、同じペースで進み続けることになります。
• 進捗が起きている場所に人々が移動するため、コミュニティは断片化する可能性が高かったでしょう。

このポリシーは、この力を責任を持って使用する方法です。AIエージェントへの指示として書かれていますが、それを使用する人間を拘束します。プルリクエストを開く者は、その中のすべての行に対して責任を負い、自分の言葉で説明できる必要があります。メンテナーからの質問には、ボットではなく人間が答えます。残りはクリーンルームのルールをエンコードしています。単一のアプリケーションのハックではなく、文書化された契約を実装する、macOSのレイヤリングを尊重する、文書化されていない癖を分離してラベル付けする、そして漏洩した資料やcorecryptoのようなAppleの制限されたソースを絶対に使用しないことです。誰も逆アセンブルを使用して一致するコードを生成すべきではありません。現地の法律によっては、何かがどのように機能するかを文書化するために逆アセンブルを使用し、その後クリーンルーム方式で再実装することは許容される場合があります。コードを書くエージェントは逆アセンブルを見ることはなく、別のコンテキストで生成された独立した動作記述のみを見ます。

ARM64 Support​

Darlingは現在、初期のARM64サポートを備えています。これは、ARM64が現在のAppleハードウェアの主要なアーキテクチャであるため重要です。Appleが自社シリコンへの移行を進めるにつれて、新しいMacはすべてARM64ベースになり、今日macOS向けに書かれているソフトウェアはますますそれを第一に、あるいは唯一のターゲットとしています。ARM64サポートなしでは、DarlingはApple自身が移行しつつあるアーキテクチャに限定されることになります。

このサポートに自信を持っているもう一つの理由があります。VibeDarlingフォークはARM64上で開発されており、その日常的な作業はARM64コードパスを常に実行しています。フォークが元のDarlingに折りたたまれたとき、最初からこのアーキテクチャの良いサポートが得られると予想しています。

The Future​

The Next Two Months​

私たちの短期的な目標は、すべてのフォークからの作業をDarlingにマージすることです。このために、エージェント駆動のマージロジックを使用しており、これまでにフォークからのコードとDarling自体の既存のバグの両方で多くのバグを自律的に修正してきました。

i386、x86-64、ARM64（aarch64）の3つのアーキテクチャを公式にサポートする予定です。ARM64に対する私たちの自信は、VibeDarlingがそれを開発しているという事実に由来します。

別に、Dynarmicを再利用してx86-64ホスト上でARM64アプリケーションを実行する作業をゆっくりと進めています。これは可能性が低いので、期待しないでください。しかし、どこまで進むか興味があります。

Longer Term​

他のコントリビューターから継続的にパッチが届くと予想されるため、彼らのことは話せません。私自身の計画は、AppKitサポートを安定させ、UIを美しくすることです。

また、単純すぎるかオープンソースであるため、動作させたい特定のアプリケーションがいくつかあります。オープンソースであることは、エージェントがアプリケーションがシステムに何を期待しているかを発見する可能性を高めます。

Darling自体にGUIアプリケーションを追加したいと考えています。例えば、設定ユーティリティやConsole.appの精神に則ったログビューアなどです。Darlingはそれを管理するためのネイティブツールを備えるべきであり、それらはAppKitサポートの実際のテストとしても機能するでしょう。

Contributing​

Darlingは大規模なコードベースであり、コントリビューションは daunting に感じられるかもしれませんが、私たちはそれを容易にしたいと考えています。もし、たとえ小さな修正であっても手伝いたい場合は、私たちのDiscordで話しかけてください。AIアシスタントを使用する場合は、まずAIポリシーをお読みください。提出するすべての行に対して責任があり、自分の言葉で説明できる準備ができている必要があります。

また、OpenCollectiveを通じてプロジェクトを財政的に支援することもできます。資金はインフラストラクチャとホスティング費用、そしておそらくLLMの費用をカバーするために使用されます。