Linux

Lightroom CCがLinuxで動いた、AIが組み上げた手順

長年「Linuxでは動かない」とされてきたAdobe Lightroom CCが、Wine上で動作するようになった。手順を組み上げたのは人間ではなく、自律で数時間デバッグを続けたAIエージェントだ。

岬徹

2026年5月17日 23:5300

「動かない」とされてきたソフトに、手順が出てきた

Adobeの写真編集ソフト「Lightroom CC」がLinux上で動いている。クラウド同期に対応したデスクトップ版、いわゆる「Lightroom Desktop」であって、ローカル管理型のLightroom Classicではない。Adobe公式はLinuxを動作対象外としてきた。Linuxで写真を扱う人には、見過ごせない動きだ。

動作の土台になっているのはWineだ。WindowsアプリをLinuxでそのまま動かすための互換レイヤーで、ここに実験的なパッチを束ねた「Wine-Staging」を組み合わせている。状態を公開したリポジトリには2026年5月16日時点で動作と明記され、対象はWine 11.8 staging、Lightroom CCのバージョンは9.3.1だ。

公開された手順をたどれば、Creative Cloudのデスクトップアプリへのサインインから、クラウド同期した写真ライブラリの表示、Edit(編集)モジュールでのLight・Color・Effects・Detailといった各パネルの描画までが動く。完璧ではない。「What's New」のような一部のダイアログはクラッシュすることがあり、GPUを使う高度な機能には不完全なものも残る。それでも、写真の取り込みから現像までの中心的な作業はひととおり成立している。

6つの「素直ではない」修正

なぜこれまで動かなかったのか。Lightroom CCはWindows向けに作られたアプリであり、Windowsにしか存在しない部品を前提に組まれている。その溝を、リポジトリは6つの修正で埋めている。

ひとつは描画の入り口だ。Lightroom CCの画面はAdobeがElectronという仕組みで組んだUIの殻で、その内側でWebView2というブラウザ部品が描画を担う。これがWine上ではそのままでは絵を出せない。DXVKのダミー描画経路を用意して、ようやく画面が出るようになる。

もうひとつは、起動を丸ごと巻き込むクラッシュだった。Adobeが自社のA/Bテスト用に同梱しているライブラリAdobeGrowthSDK.dllが、Wineにまだ実装されていない関数SetThreadpoolTimerExを呼びにいき、Creative Cloudのプロセス群を全滅させてしまう。修正はシンプルで、このライブラリを無効化する。テスト用の部品のために、本体ごと起動できなかった。

残る修正は、足りない部品を補うものだ。Lightroomが必要とする色管理機能を登録するためd2d1.dllにパッチを当て、Wine 11.8が同梱しない小さなDLLを3つ自前で用意し、Adobe同梱のDLLにWine側がたどり着けるよう小文字のシンボリックリンクを張る。いずれも「Windowsならあって当然」の部品を、Linux側で一つずつ用意し直す作業だ。

特に厄介だったのが、写真から不要なものを消す「除去・修復ツール」のクラッシュだった。原因はmfplat.dllという動画・音声処理まわりのDLLに、関数MFCreateSampleCopierMFTが欠けていたこと。パッチを当てたDLLを用意しても話は終わらない。Adobeは自分専用のmfplat.dllをLightroomのインストール先に同梱しており、Windowsの読み込み順ではそちらが優先される。修正版を2か所に置く必要があった。Adobeが自前のDLLを割り込ませる仕組みが、ここで問題になる。

リポジトリを丸ごと書いたのはAIエージェント

ここからが、この話の本筋だ。スクリプト、スタブDLLのソース、パッチ済みバイナリ、ドキュメント、手順書、そしてリポジトリの説明文。これらすべてを調査・執筆・検証したのは、自律で動作したClaude Opus 4.7だった。Claude CodeというCLIエージェントを通して動いている。

人間の貢献者がやったのは、ゴールを与えることだ。「Lightroom CCをLinuxで動かし、再現可能な手順を公開しろ」。あとは時おり出る確認の質問に答え、Adobeのサブスクリプションを用意し、成果をレビューした。手を動かす部分は、ほぼエージェントが担っている。

そのエージェントの作業ループが、リポジトリに具体的に書き残されている。クラッシュダンプとWineのログ、Adobeのバイナリをwinedumpやobjdump、Pythonでの生のPE解析で読む。システム上のすべてのmfplat.dll、つまりWine内蔵版とProton版、Adobe同梱版のエクスポートテーブル を突き合わせ、欠けている関数を1つに絞り込む。そのうえでバイナリに直接パッチを当てた。

エクスポートテーブルとは、そのDLLが外部に提供する関数の一覧表のこと。3つのDLLの一覧を並べて見比べることで、どれに何が足りないかが分かる。

検証の進め方は、人間の手作業とよく似ている。動いているLightroomの画面をImageMagickで撮影し、UI要素の位置をピクセル単位の検出で割り出し、xdotoolでマウスを動かして除去ツールをクリックする。ポップアップが出たか、それともクラッシュダンプが吐かれたかを見て判断する。

アイコンの座標検出が数ピクセルずれてクリックを外したときは、スクリーンショットを撮り直し、検出器を走らせ直し、調整して再試行した。何度かの試行をすべて自律でこなしている。

そして例の「修正版を2か所に置く」問題は、この検証の失敗から見つかったものだ。system32に置いたパッチ版mfplat.dllが、まったく読み込まれていなかった。Adobeがインストール先に置いた自前のDLLが優先されていたためだ。エージェントはパッチ版をAdobeのインストール先にもコピーし、再起動し、除去ツールの操作を画面で追って、ブラシ操作がクラッシュなしで通ることを確かめた。

AIの「次回への申し送り」が残っている

リポジトリには、もうひとつ見落とされがちな点がある。エージェントが作業の最後に、何が効いたかを記録し、「Adobe同梱DLLが優先される」という落とし穴を次のセッション向けのメモとして残している点だ。他のAdobeアプリでも同じ問題が起きうる、転用できる教訓として書かれている。

リポジトリの説明文には、バイナリに関する但し書きもある。stubs/binaries/に入ったパッチ済みDLLは、公開時点でディスク上のLightroom環境で実際に動作確認した、そのままのコピーだという。手順書に記されたチェックサムと、リポジトリ内のバイトが一致する。「AIが書いた」という曖昧さを、検証可能な形で潰しにいっている。

ライセンスの扱いも整理されている。パッチ済みのd2d1.dllとmfplat.dllはWineの実装から派生したものなので、Wineと同じLGPL-2.1+のライセンスを引き継ぐ。スクリプトとスタブはMITで公開し、Adobeのバイナリ自体は再配布していない。クローズドソースのソフトをLinuxで動かす試みにつきまとう権利の問題に、最初から線を引いている。

良いものは良い、と書ける材料がそろっている。動かないとされてきたソフトに再現可能な手順がつき、何が動いて何がまだ駄目かが正直に並び、ライセンスの整理まで済んでいる。一方で、これはAdobeが用意した道ではない。Wineの実験的なパッチに乗っており、LightroomのアップデートやWineの仕様変更で、明日にも崩れうる足場であることは見ておきたい。

それでも、Adobeが20年以上「対象外」と言い続けてきた領域に、AIエージェントが数時間で一本の道をつけた。次に同じことを試すのが人間とは限らない。

参照元