Crafting AppsがAdobe7種をRustで完全再構築、MCP対応でAI自動化も可能に

• 事実と背景：Adobeの主要7アプリをRustで完全再構築したオープンソース「Crafting Apps」がRC版として登場。
• 技術的変革：Electronを排除した純粋なRustネイティブ実装で、Wasmによるブラウザ動作やMCPによるAI操作に対応。
• 現場への影響：サブスクコストの削減だけでなく、CLIやJSON、MCPを介したデザイン・動画編集の自動化パイプラインが構築可能に。

我々開発者は、デスクトップアプリの「Electron化」によるメモリ大食いと起動の遅さに、長年静かな怒りを抱えてきた。SlackやVS Codeを開き、さらにAdobe Creative Cloudの重厚なアプリ群を立ち上げた瞬間、マシンのファンが悲鳴を上げ、メモリが枯渇する――そんな「デッドロック寸前」の日常に、ついに一石が投じられた。

「Crafting Apps」が提示した最大の技術的回答は、すべてのアプリをRust言語でゼロから構築し、ElectronやWebビューを一切排除した純粋なネイティブアプリとしてコンパイルした点にある。Windows、macOS、Linuxのマルチプラットフォームに対応しながら、各OSのネイティブなパフォーマンスを極限まで引き出す。このアーキテクチャの選択こそ、パフォーマンスに妥協したくないシニアエンジニアの心を揺さぶる。

さらに驚くべきは、これらのコードがWebAssembly（Wasm）へとコンパイルされ、ブラウザのタブ上でも動作するという事実だ。ローカルのネイティブアプリとして超高速に動作する一方で、Webブラウザというサンドボックス環境でも同一のロジックが走る。このポータビリティは、Rustのメモリ安全性を活かした厳密なメモリ管理と、プラットフォーム抽象化の賜物である。

Adobeのコードを1行も使わずに、Photoshop互換の「PhotoCraft」やIllustrator互換の「VectorCraft」など、7つの巨大なアプリケーションを再構築したその執念には脱帽するしかない。実際にPhotoCraftでレイヤー構造を維持したままPSDファイルを開き、調整レイヤーやマスク、ブラシツールが軽快に動作する様子を見たとき、私は「ついにAdobeの独占体制に風穴を開ける技術的基盤が整った」と確信した。

しかし、私がこの記事で最も強調したいのは、単なる「Adobeの無料代替品ができた」という表面的なニュースではない。本質的な破壊力は、Crafting Appsが「エージェント準備完了（Agent Ready）」を掲げ、CLI、JSON制御チャネル、そしてMCP（Model Context Protocol）サーバーを標準搭載している点にある。

これまでのクリエイティブツールは、人間がGUI（グラフィカルユーザーインターフェース）を介してマウスとキーボードで操作することを前提に設計されていた。一部の自動化スクリプトは存在したものの、それはスパゲッティコードになりがちな独自のAPIやマクロに依存しており、現代のAIエージェントからシームレスに制御することは極めて困難だった。

Crafting Appsは、この前提を根底から覆す。MCPサーバーを内蔵することで、ClaudeなどのLLM（大規模言語モデル）やAIエージェントが、直接アプリケーションの内部状態を操作し、画像の編集、ベクターデータの生成、動画のカット編集、PDFのレイアウト調整を自律的に実行できるようになる。

例えば、深夜の障害対応や急な仕様変更の際、「このバナーのテキストを『キャンペーン終了』に変更し、背景のトーンを少し暗くして再書き出しして」とAIに指示するだけで、AIエージェントが裏側でPhotoCraftのJSON制御チャネルを叩き、一瞬でPSDを書き換えてデプロイする――そんな未来が、すでに技術的に可能になっているのだ。

これは、クリエイティブ制作のワークフローにおける「無限ループ」のような単純作業から人間を解放する、真のパラダイムシフトである。我々エンジニアは、単にコードを書くだけでなく、デザインやメディア編集のパイプライン全体をコードで制御する「クリエイティブ・インフラ」の構築者へと進化を求められている。

もちろん、手放しで賞賛するばかりではプロのジャーナリスト、そしてシニアエンジニアとしての職責を果たせない。現状のCrafting Appsは「RC版（リリース候補版）」であり、実務にそのまま投入するにはいくつかの致命的なデッドロックが存在する。

最も顕著な課題は、日本語をはじめとする2バイト文字への対応不足だ。現状、日本語フォントの英数記号は表示されるものの、日本語テキストの入力やレンダリングには不具合があり、実質的に国内の商用デザイン実務で使うことはできない。また、PSDやAIファイルの完全な互換性を保証しているわけではなく、複雑なエフェクトや3D機能、高度なカラーマネジメントにおいては、本家Adobe CCとの間にまだ明確なスペックの壁が存在する。

では、我々エンジニアは「まだ使えないおもちゃ」として、このプロジェクトを静観すべきなのだろうか？ 答えは断じて「否」である。

我々が今すぐ取るべき具体的な処方箋は、まずこのオープンソースプロジェクトのGitHubリポジトリ（Apache-2.0 / MITライセンス）をクローンし、自らの手でビルドしてみることだ。そして、日本語レンダリングのバグを修正するプルリクエスト（PR）を送り、コントリビューターとしてプロジェクトに参画することである。あるいは、社内の非クリエイティブな自動化タスク（例えば、定型的なPDFレポートをPrintCraftで自動生成する、CLI経由で大量の画像を一括リサイズ・補正するなど）において、限定的に導入実験を開始することだ。

Adobeのサブスクリプション料金は年々上昇し、開発現場を圧迫し続けている。この「Adobe税」とも呼ばれる独占的状況に対して、我々はただ文句を言うだけでなく、オープンソースの力で対抗する手段を手に入れた。

最後に、読者であるあなたに問いかけたい。あなたはこれからも、ブラックボックス化された巨大企業のサブスクリプションに依存し続けるのか？ それとも、自らの手でコードをコントロールし、AIと協調する新しいクリエイティブの未来を自ら切り拓く側に回るのか？ 明日の開発現場を変えるのは、あなたの最初の一歩である。