After Effects の拡張構造と、外部プロセスから操作する経路
After Effects を AI から操作する MCP サーバーが、この数か月でいくつも公開されている。
実装を1つ開いてみると、Adobe の内部APIを解析した形跡はどこにもなかった。 使っているのは、Adobe が20年以上前から公開しているスクリプティングAPIだけである。
ただしそのAPIには、古い時代の制約がそのまま残っている。 制約は実装の細部にまで影響していて、外部プロセスから AE を操作しようとすると設計の選択肢が2つに絞られる。
AEを拡張する3つの層
AE を拡張する仕組みは、性格の違う3つの層でできている。
| 層 | 実体 | 守備範囲 |
|---|---|---|
| C++ SDK | AEGP プラグイン、エフェクトプラグイン | メニュー項目の追加、内部コマンドのフック、ドッキング可能なパネルの追加、レンダーキューの管理 |
| ExtendScript | ES3 のスクリプトエンジン | プロジェクト、コンポジション、レイヤー、プロパティ、キーフレームの読み書き |
| CEP | Chromium と Node.js を内蔵した HTML パネル | パネルのUI、ネットワーク通信、ファイル操作 |
見落とされやすいのが CEP の位置である。 CEP 12 は Chromium 99 と Node.js 17.7.1 を内蔵していて、パネル内では Node のモジュールがそのまま動く。
ところが CEP パネルは AE のプロジェクトデータに直接アクセスできない。
CSInterface.evalScript() に ExtendScript のコードを文字列で渡し、AE 側のエンジンに実行させて、結果をコールバックで受け取る。
CEP のドキュメントには、渡したスクリプトが「ホストアプリケーションのメインスレッドで動く ExtendScript エンジン」で実行されると書かれている。
つまり CEP が担当するのは UI と外部通信であって、AE を操作する部分は結局 ExtendScript が引き受ける。
C++ SDK だけは別格で、スクリプトからは届かない領域に手が入る。 AE 内部のコマンドをフックして横取りする、AE のUIに溶け込むパネルを追加する、といったことができる。 ただしコンパイルしたバイナリの配布とインストールが必要になるので、コマンド1行で入る道具にはならない。
Adobe が新世代の拡張基盤として用意した UXP は、After Effects では使えない。
Photoshop や InDesign が移行を済ませた一方、2026年8月時点でも developer.adobe.com/after-effects/uxp/ にあたる公式ページが存在しない。
AE の拡張は CEP と ExtendScript の組み合わせが現役のままである。
スクリプトから見たプロジェクトの形
ExtendScript から見た AE は、app を頂点とする木になっている。
app
└─ project
└─ item (CompItem / FootageItem / FolderItem)
└─ layer
└─ property (PropertyGroup / Property)
└─ keyframe
この木の形は、AE を操作するツールの語彙にそのまま現れる。
layer.create_solid や keyframe.add のような操作名は、DOM の階層を操作の名前へ写したものである。
もう一つ、外部から操作するときに効いてくるのが取り消しの単位である。
app.beginUndoGroup() と app.endUndoGroup() で囲んだ一連の操作は、AE 上で1つの取り消し単位にまとまる。
1リクエストをこれで囲んでおけば、意図しない操作が入っても取り消し1回で戻せる。
ExtendScriptランタイムに残っている制約
外部連携の設計を縛っているのは、このエンジン自体の性質である。
エンジンの言語仕様は ECMA-262 3rd Edition、つまり1999年の JavaScript である。
JSON オブジェクトが無い。
そのため JSON を扱うには、json2.js 相当の実装を自前で持ち込む必要がある。
スクリプトは AE のメインスレッドで動く。 実行している間、AE のUIは応答しない。
ソケットはあるが、待ち受けサーバーには向かない。
ExtendScript には Socket オブジェクトがあるものの、非同期に対応しておらず、SSL も使えない。
macOS では listen() が false を返すという報告が続いている。
待ち受けようとすれば無限ループで回すことになり、その間 AE を人間が操作できなくなる。
app.scheduleTask() による擬似的な非同期にも穴がある。
呼び出しのたびに新しい JavaScript VM でプロセスが作られるため、グローバル以外の変数が見えない。
そしてアラートや環境設定など、AE が何かウィンドウを開いた瞬間に動作が止まる。
これらを重ねると、AE のプロセスの中に常駐サーバーを置く設計は分が悪いという結論になる。
外部から操作する2つの設計
常駐サーバーが現実的でないとなると、外部プロセスから AE を操作する経路は実質2つになる。
| 方式 | 通信の担い手 | 導入 | 往復のコスト |
|---|---|---|---|
| CEPパネル常駐 | パネル内の Node がソケットで外部とつながる | 拡張パネルのインストールが必要 | 低い |
| 都度起動とファイル受け渡し | 起動のたびにスクリプトを送り込む | インストール不要 | 高い |
後者の入口として、Adobe は2つのコマンドを公式に用意している。
- Windows:
afterfx.exe -r <スクリプトのパス> - macOS: AppleScript の
DoScriptとDoScriptFile
どちらも After Effects Scripting Guide に記載された正規の実行方法である。 リバースエンジニアリングの余地はない。
前者の実例として、Mike Chambers による adb-mcp がある。 Photoshop、Premiere Pro、InDesign を対象に、UXP プラグインが localhost のプロキシサーバーへ WebSocket でつなぐ構成をとっている。 UXP プラグインもソケットの待ち受け側にはなれないため、あいだにプロキシを挟んでいる。 AE は UXP に対応していないので、同じことをするなら CEP パネルで組み直すことになる。
ファイル受け渡し方式の実装
後者の実装として、2026年8月8日に公開された kumoproductions/mcp-aftereffects を読んだ。 TypeScript、MIT ライセンス、Windows と macOS の両対応である。
この実装は、OSの一時ディレクトリを郵便受けとして使う。
書き込みはどちらの向きも .tmp に書いてから rename する。
書きかけのファイルを相手に読まれる事故を防ぐためである。
AE 側のディスパッチャは、候補ディレクトリを走査して最も古いリクエストを1件だけ処理する。
読み込んだ時点でファイルを削除するので、起動が重なっても同じリクエストが二度実行されない。
実行そのものは new Function("app", "log", "payload", request.code) で、app を引数として渡している。
多重起動への備えもある。
open("wx") でロックファイルをアトミックに作成し、MCPサーバーのプロセスが複数立っても衝突しない。
ロックの更新時刻が古ければ、落ちたプロセスの残骸とみなして削除する。
ES3 と格闘した跡も残っている。
JSON.stringify(request).replace(/\u2028/g, "\\u2028")
U+2028 と U+2029 は行区切りの制御文字で、ES3 のパーサはこれを見ると文字列リテラルが終わったと判断してしまう。 テキストレイヤーの中身にこの文字が混ざれば、リクエストはその位置で壊れる。 上のエスケープはその対策である。
MCP のツール設計も、この方式に合わせてある。
操作ごとにツールを定義するのではなく、ae_catalog で操作の一覧を引かせ、ae_do(operation, args) の1本で実行する。
複数の操作は batch.run にまとめさせる。
1往復ごとにプロセス起動とポーリングが挟まる方式なので、往復回数を減らす作りになっている。
動かす前に必要な設定
どちらの方式でも共通して引っかかるのが、AE 側の環境設定である。
「スクリプトによるファイルへの書き込みとネットワークへのアクセスを許可」は既定でオフになっている。
オフのままでは ExtendScript から File の書き込みも Socket も使えない。
ファイル受け渡し方式は、この設定に完全に依存する。
macOS ではさらに、osascript が AE を操作するためのオートメーション許可をユーザーが手で与える必要がある。
公式コネクタにAfter Effectsが無い理由
Adobe は2026年4月28日に、公式の MCP コネクタ「Adobe for creativity」を提供開始している。 Photoshop、Lightroom、Illustrator、Firefly、Express、Premiere、InDesign、Stock を対象に50を超えるツールが並ぶ。 そこに After Effects は入っていない。
ここまでの構造をふまえると、理由は2つに分けて読める。
一つは、公式コネクタがクラウド側のAPIを MCP にしたものであること。 手元で起動しているアプリケーションを操作する仕組みではない。 AE の自動化は手元のプロジェクトファイルを対象とするので、層が違う。
もう一つは、手元の AE を公式に組み込もうとすると拡張基盤の問題に突き当たること。 Photoshop や Premiere Pro が UXP へ移行した一方で、AE の足元には ES3 のエンジンが残っている。 公式が AE を対象に加えるには、その上に何を載せるかを先に決める必要がある。
コミュニティ側の実装は、すでにいくつも並んでいる。
通信方式とツール設計に違いはあるものの、AE のデータに触る部分が ExtendScript である点はいずれも共通している。 作者ごとの好みの差ではなく、AE の構造が選択肢を絞っているためである。
業務のプロジェクトで試す前に
読んだ実装の README には、AI が読み取った情報が外部のAIサービスへ送られる可能性が明記されていた。 コンポジション名、レイヤー名、エクスプレッション、フッテージのファイルパスが対象になる。
任意の ExtendScript を実行する機能は既定で無効化され、読み取り専用で動かす環境変数も用意されている。
とはいえ実行の仕組みは new Function なので、有効にすれば任意のコードが AE の権限で走る。
秘密保持契約のかかった案件のプロジェクトで、いきなり試すものではない。
まずバックアップか検証用の .aep で挙動を確かめるのが順当だと考える。