Adobe自動化にMCPは不要?PowerShellのCOM活用術

クイックサマリー：AIエージェントにInDesignやIllustratorを操作させたいとき、MCPサーバーを新たに立てなくても、Windows標準のPowerShellからCOM経由でアプリに直接コマンドを届けられます。追加インストールはゼロ。Claude CodeやCodex CLI、Antigravity CLIといった主要なコーディングエージェントから同じ経路で呼び出せる、再現性の高いローカル自動化アプローチです。

「AdobeアプリをAIに操作させたいけれど、MCPサーバーの構築が大掛かりで手が出せない」——そう感じていないでしょうか。この記事で示す解決策はシンプルで、Windows環境ならPowerShellとCOM、そしてAdobeアプリ側のExtendScript実行機能（DoScript）だけで、AIエージェントから目の前のInDesignやIllustratorに指示を届けられます。この記事を読むと、以下がわかります。

• MCPサーバーを使わずにローカルのAdobeアプリを自動操作する具体的な手順
• Adobe公式MCPとコミュニティ製MCPを実際に調査した結果、なぜローカル操作には不要だったのか
• PowerShell経由の操作をClaude Codeのスキルとして定型化する方法
• MCP化する価値がある条件と、逆にMCP化がハードルを上げてしまうケース

紹介する手法はOSSのライブラリではなく、Windows OS標準機能とAdobeアプリ自体のスクリプト機能（20年以上前から存在する枯れた技術）の組み合わせです。ライセンス費用やインストールの手間は発生しません。

何ができるか

この手法で実現できるのは、AIエージェントが「今開いているInDesignやIllustratorのドキュメント」に対して、GUI操作と等価な処理を自動実行することです。indd・ai・psdといったAdobe独自フォーマットは仕様が公開されていないため、AIが直接バイナリを書き換えることはできません。代わりに、アプリ本体にExtendScript（JSX）を解釈させることで、人がGUIで行う操作と同じ結果を得ます。

対応CLI・エージェントは以下の通りです。

• Claude Code：定型処理をスラッシュコマンドやスキルとして登録し、自然言語トリガーで呼び出す
• Codex CLI / Antigravity CLI：同様にPowerShellラッパーをツール実行として呼び出せる（Windows上で動作する任意のエージェントが対象）

主要機能（ラッパースクリプトが担う役割）は次の3点です。

• 起動中のAdobeアプリのバージョン特定（プロセスから動的取得）
• 既存インスタンスへの接続（新規プロセスを誤って起動しない）
• ExtendScriptの実行結果とログの回収

実装手順（PowerShellラッパー＋Claude Codeスキル化）

公式ドキュメント相当の実装として、参照元記事では最小構成のコードが示されています。これは追加のモジュールインストールなしに、そのまま実行できる内容です。

$app = [Runtime.InteropServices.Marshal]::GetActiveObject("InDesign.Application.2024")
$app.ActiveDocument.FullName
# 1246973031 = ScriptLanguage.JAVASCRIPT
$code = Get-Content -Raw -Encoding UTF8 "task.jsx"
$app.DoScript($code, 1246973031)

実際にこのコードを追ってみると、GetActiveObjectで「今起動しているInDesign」を掴みにいっている点が重要だとわかります。もしNew-Object -ComObjectを使ってしまうと、アプリが未起動の場合に新規プロセスを立ち上げてしまうため、開発者が意図的に使い分けていることが読み取れます。この設計は、単に動くコードを書くだけでなく、実運用で事故を避けるための配慮です。

ステップ1：起動中バージョンの特定

参照記事によると、ProgIDをInDesign.Applicationのようにバージョン番号無しで書くと、β版が同居する環境では意図しないアプリに接続してしまう問題が実際に発生したとのことです。そのため、毎回プロセスから判定する実装が推奨されています。

Get-Process InDesign -ErrorAction SilentlyContinue | Select-Object Path, @{n='Ver';e={$_.MainModule.FileVersionInfo.FileVersion}}

ステップ2：ダイアログ抑止と復元

InDesignの場合、userInteractionLevel = NEVER_INTERACTを設定しないと、非表示状態で開いたドキュメントに対してもモーダルダイアログが表示され、処理が止まる、あるいはアプリがクラッシュすることがあると記事内で報告されています。この設定はセッションをまたいで残るため、処理後に元の値へ戻す実装が必須です。戻し忘れると、その設定に無関係な別のスクリプトが確認ダイアログなしに未保存の変更を破棄してしまうリスクがあります。

ステップ3：エラーハンドリングと戻り値の回収

AIエージェントにスクリプトの実行を任せる以上、「動いたかどうか」を確実に判定できる仕組みが運用の要になります。ExtendScript内部では、構文エラーだけでなく、フォントが見つからない・レイヤーがロックされている・対象のページ番号が存在しないといった実行時例外が起こり得ます。これをPowerShell側で捕捉せずに放置すると、エージェントは「コマンドを実行した」という事実だけを見て成功と誤判定してしまいます。

最小構成としては、DoScript呼び出しをtry/catchで包み、COMから返る例外メッセージをそのまま拾う方法が手早く確実です。

try {
    $result = $app.DoScript($code, 1246973031)
    Write-Output "OK: $result"
} catch {
    Write-Error "DoScript failed: $($_.Exception.Message)"
    exit 1
}

ただし、この方法で拾えるのはCOM層まで伝播した致命的なエラーだけです。JSX側でtry/catchを握りつぶしていたり、処理の途中経過（何件処理したか、どのオブジェクトをスキップしたか）を知りたい場合は、JSX自身に結果を文字列として組み立てさせ、DoScriptの戻り値として返す設計にするのが確実です。

// task.jsx 側
var log = [];
var processed = 0;
try {
    for (var i = 0; i < app.activeDocument.pageItems.length; i++) {
        // 何らかの処理
        processed++;
    }
    log.push("processed=" + processed);
} catch (e) {
    log.push("ERROR: " + e.message + " (line " + e.line + ")");
}
log.join("\n"); // DoScriptの戻り値になる

PowerShell側では$resultにこの文字列がそのまま入るため、$result -match "^ERROR"のような判定を挟めば、エージェントは「実行できたが中身は失敗している」ケースも機械的に検知できます。件数をログ出力し、後で処理対象の総数と突き合わせる運用（実用例で後述）も、この戻り値設計があって初めて成立します。

ステップ4：Claude Codeのスキルとして定型化する

毎回同じ手順を踏む案件については、Claude Codeの.claude/skills/配下にSKILL.mdを配置し、自然言語トリガーで呼び出せるようにします。Antigravity CLIの場合はワークスペース単位で<プロジェクトルート>/.agents/skills/、グローバルでは~/.gemini/antigravity-cli/skills/に配置します。

---
name: adobe-font-apply
description: 指定した案件の合成フォント適用をInDesignに対して実行する
---

## 手順
1. Get-Process InDesign でバージョンを確認する
2. GetActiveObject で既存インスタンスに接続する
3. ActiveDocument.FullName を表示し、対象ファイルを確認してから実行する
4. userInteractionLevel を NEVER_INTERACT に設定し、処理後に元の値へ戻す
5. task.jsx を DoScript(1246973031) で実行し、戻り値の文字列をログとして確認する
6. 戻り値に ERROR が含まれていないか、処理件数が想定と一致するかを確認してから完了とする

「◯◯案件 フォント当てて」という自然言語の指示から、この手順書が読み込まれ、決まったスクリプトが実行される——これはMCPの関数呼び出しと実質的に同じ抽象化です。呼び出し口が自然言語のトリガーか、関数名かという違いしかありません。

実用例

実際の組版業務でAIエージェントに任せられる処理として、参照記事では以下が挙げられています。

• 合成フォントの適用（名前の衝突が起きやすい処理）
• カーニングを「メトリクス」に設定する（APIから直接代入できないため、JSX経由の処理が必要）
• 案件ごとに異なる禁則・文字組みルールの適用
• 「このレイヤーだけ除外」「この言語だけフォントを変える」といった条件分岐処理

これらは関数のシグネチャに落とし込もうとすると引数が際限なく増えるか、結局コードを渡すことになる性質の処理だと記事は指摘しています。実際、183個のツールを実装したコミュニティ製MCPサーバーであっても、script_run(code, debug)という任意ExtendScript実行のツールを別途用意しており、19ツール規模の別実装でもrun_jsx（既定は無効、信頼できる環境でのみ有効化）という同種の逃げ道を残しています。関数化だけでは足りないと、実装者自身が判断した証拠だと言えるでしょう。

Claude Codeの実際の開発フローに組み込む場合は、hooksでテスト実行を自動化するのと同じ発想で、「編集前に必ず読み取り専用の調査スクリプトを走らせる」「処理件数をログ出力し、後で件数を突き合わせる」といった安全策をスキルの手順書に明記しておくと、想定外の破壊的操作を防ぎやすくなります。ステップ3で紹介した戻り値ログの設計は、まさにこの「件数の突き合わせ」を機械的に行うための土台です。

類似アプローチとの比較・注意点

3つの実装方式の比較

InDesign以外のAdobeアプリでの仕様差

ここまで紹介したコード（DoScript(code, 1246973031)やuserInteractionLevel = NEVER_INTERACT）はInDesign専用の仕様です。COM自体は各Adobeアプリに共通する土台ですが、ProgIDとスクリプト実行メソッドの名前はアプリごとに異なるため、そのまま流用すると動きません。主要なアプリでの対応関係を整理すると次のようになります。

いずれのアプリでも「起動中のインスタンスにGetActiveObjectで接続する」「処理後に抑止系プロパティを元に戻す」という設計思想自体は共通ですが、メソッド名を取り違えるとCOMの例外で即座に失敗します。複数のAdobeアプリを横断して自動化する場合は、アプリ名からProgIDとメソッド名を引く小さなマッピングをラッパースクリプト側に持たせておくと、エージェントへの指示がシンプルになります。

注意点・制約

公平を期すために、MCP化の実利についても触れておきます。複数のAIクライアントを併用していて、どこからでも同じ処理を呼びたい場合には、MCPサーバー化が正しい選択になります。標準規格としての強みはそこにあります。逆に単一クライアントで完結しているうちは、呼ぶ相手がいないため恩恵を得にくいと言えます。

配布性についても注意が必要です。「他の人にも使ってほしい」という動機がある場合、MCP化はむしろ導入のハードルを上げます。PowerShellとJSXだけの構成はWindowsさえあれば動きますが、MCPサーバーにするとNode.jsかPythonのインストールから案内する必要が生じます。

セキュリティ面では、この手法は外部通信を一切発生させません。処理はすべてローカルのAdobeアプリ内で完結し、データが外部サーバーに送信されることはありません（Adobe公式MCPはクラウドアセット操作が前提のため、この点で性質が異なります）。ただし、JSXによる編集操作はアンドゥ履歴を大量に積むため、Ctrl+Zでの原状復帰は実務上あてにならないと記事は警告しています。書き換え前のファイルコピーによるバックアップが推奨されます。また、ExtendScriptはES3相当の言語仕様であるため、let・const・アロー関数・forEach・テンプレートリテラルが使えない点もエージェントへの指示に明記しておく必要があります。

FAQ

まとめ

要点を3つに整理します。

• Adobe公式MCPはクラウド上のアセットを扱うもので、ローカルで開いているindd・aiファイルには届きません
• COM経由でローカルアプリを操作するMCPは実在し、技術的には同じ処理が可能ですが、183ツール規模の実装でも任意ExtendScript実行の穴が残されており、組版のような非定型業務を完全に関数化するのは難しい性質があります
• WindowsであればPowerShell標準機能とCOM、Adobeのスクリプト機能だけで、追加インストールなしに同等の自動化が完結します。定型処理はClaude CodeやAntigravity CLIのスキル機構に落とし込むことで、MCPの関数呼び出しと実質同じ抽象化を得られます

複数のAIクライアントを横断して同じAdobe操作を呼び出したい場合や、チーム全体で共有するインフラとして整備したい場合は、Claude Code MaxやCodex CLI ProのMCPエコシステムと組み合わせる選択肢も検討する価値があります。まずは手元の1クライアントで、PowerShellラッパーから試してみるのがよいでしょう。

よくある質問（FAQ）