ExtendScriptかUXPかではなく、AIにどう操作させるかの時代へ

Adobe製品の自動処理では、長年「ExtendScript」が使われてきました。

DTP作業の自動処理または作業補助をするためのExtendScriptは、AIが普及する前後で、捉え方に変化があります。

AIがまだ浸透していない頃（といってもここ1，2年の話ですが）は、DTPでスクリプトを使うということは少しハードルが高いと思われていました。

これは、プログラム知識がなければ作ることができない、意図しない動作のときに調整ができない、というような理由です。

しかし、ChatGPTやGemini、CloudeCodeなどのAIが浸透したことによって、自然言語でやりたいことを伝えてスクリプトを生成することができるようになりました。

これは今までのハードルを大きく下げる効果があり、コード生成AIの登場は、プログラム知識がない人にもスクリプトという概念を広める契機となりました。

MCPという概念もまた広まっていくのかもしれないと検証をしていたのですが、自然言語でアプリケーションに指示を出すAIエージェントという概念が広がりを見せています。

DTPの分野でもAdobeが進めているこのAIエージェントは、果たして浸透するのだろうか、という辺りを今回は考察してみたいと思います。

この記事では、ExtendScriptからUXPへの移行が進みにくい理由を整理しながら、Adobe自動化がAI時代にどこへ向かうのかを考えます。

ExtendScriptとは何か

ExtendScriptは、Adobe製品を自動操作するために長く使われてきたスクリプト環境です。

InDesign、Illustrator、Photoshopなどのアプリケーションを操作し、定型作業を自動化できます。

たとえば、InDesignであれば次のような処理です。

• ExcelやCSVのデータを流し込む
• 商品画像を決められた位置へ配置する
• ページを複製して量産する
• 商品情報ごとにレイアウトを切り替える
• PDFを書き出す
• ファイル名や保存先をルール化する
• 複数のドキュメントをまとめて処理する

DTPや印刷物の制作では、同じような手作業が繰り返されます。

その繰り返しを機械に任せるために、ExtendScriptは長年使われてきました。

古い仕組みではありますが、単に古いというだけで捨てられない理由があります。

それは、ExtendScriptが現場の制作フローに深く入り込んでいるからです。

UXPとは何か

UXPは、Adobeが新しく導入している拡張基盤です。

ExtendScriptよりも新しいJavaScriptを使え、HTMLやCSSを含めた現代的な開発手法で、スクリプトやプラグインを作ることができます。

UXPの登場によって、Adobe製品の自動化は次のように変わることが期待されました。

• モダンなJavaScriptを使える
• Web開発者が入りやすくなる
• UI付きのツールを作りやすくなる
• APIや外部サービスと連携しやすくなる
• より安全な実行環境を作れる
• 将来的な機能拡張に対応しやすくなる

技術的に見れば、UXPはExtendScriptより新しい仕組みです。

しかし、新しい仕組みであることと、現場で移行が進むことは別の話です。

Photoshop、InDesign、Illustratorの現在地

UXPの状況は、Adobe製品ごとにかなり異なります。

Photoshop：UXPは進んでいる

PhotoshopはAdobeの中心的なアプリケーションであり、新しい技術が先に入る傾向があります。

UXPについても、Photoshopでは比較的早くから環境が整えられ、スクリプトやプラグイン開発で使われ始めています。

画像処理、フィルター、レイヤー操作、外部サービス連携など、UXPの強みを活かしやすい領域も多くあります。

Photoshopはもともと、デザイン、写真、Web、映像、アプリ開発など、さまざまな領域の利用者が混ざるアプリケーションです。

そのため、モダンなJavaScript環境を受け入れやすい土壌が比較的あるのだと思います。

InDesign：UXPは増えているが、ExtendScriptがまだ現役

InDesignでもUXPは使えるようになってきています。

新しい技術を試したい開発者や、今後の移行を見据えている人の中には、UXPでスクリプトを書く人も増えています。

しかし、現場ではExtendScriptがまだ強く残っています。

理由は、既存資産が多すぎるからです。

InDesignは、書籍、カタログ、情報誌、帳票、チラシ、マニュアル、商品データの組版など、繰り返し制作される媒体に使われます。

そのため、長年にわたって数え切れないほどのExtendScriptが作られてきました。

そこには、単純な自動処理だけではなく、個別案件ごとの例外、制作ルール、命名規則、画像処理、校正対応、出力条件などが積み重なっています。

これをUXPへ移すことは、単なる書き換えではありません。

現場の運用そのものを再検証する作業になります。

Illustrator：そもそもの自動化に課題が残る

Illustratorは、ExtendScriptの時代からスクリプトで操作できない範囲が少なくありませんでした。

必要な処理をスクリプトだけで完結できず、アクションを呼び出したり、別の仕組みを組み合わせたりする必要がある場面もありました。

そのため、Illustratorの自動化はもともと少し特殊です。

UXPになればすべて解決する、という話ではありません。

ExtendScriptで苦労していた部分は、UXPへ移っただけでは解決しないことがあります。

この状況では、新規でUXPを学び、書き直し、検証し、既存フローへ組み込むだけの価値を見出しにくいのも自然です。

なぜUXPへの移行は進みにくいのか

UXPへの移行が進みにくい理由は、一つではありません。

主に次のような要因が重なっています。

• 既存のExtendScript資産が膨大にある
• 現在動いている仕組みを止められない
• JavaScriptの学び直しが必要になる
• アプリごとにAPIの成熟度が異なる
• 従来のローカルファイル処理を移植しにくい
• 新しい仕組みへ移る明確な業務上のメリットが見えにくい
• 移行後の保守や検証の負担が大きい

現場にとって重要なのは、技術が新しいかどうかではありません。

• 毎月の制作が止まらないこと。
• 修正に対応できること。
• トラブルが起きたときに直せること。
• 担当者が変わっても運用できること。

UXPへの移行が、それらを確実に良くするとは限らない限り、ExtendScriptは残り続けます。

JavaScriptが進化しすぎた問題

ExtendScriptが使われ始めた頃のJavaScriptは、今と比べるとかなりシンプルでした。

変数を定義し、関数を書き、配列やオブジェクトを使い、上から順に処理する。

DTPの現場で必要な範囲なら、ある程度学べば使える言語でした。

しかし、現在のJavaScriptは大きく進化しています。

• let / const
• class
• module
• Promise
• async / await
• arrow function
• npmを前提にしたパッケージ利用
• 非同期通信
• 型やテストを含めた開発環境

これらは現代のJavaScript開発では普通のものです。

ただし、ExtendScriptを書いてきた人にとっては、単純な機能追加ではありません。

ほとんど別の開発文化に入り直す感覚になります。

特に、非同期処理は大きな違いです。

ExtendScriptでは、スクリプトを実行すれば、基本的には上から順にAdobeアプリが操作されます。

一方でUXPでは、外部通信、UI、権限、ファイル操作などで、非同期処理を意識する場面が増えます。

これは技術としては自然な進化です。

しかし、現場の制作者やDTPオペレーターが、自動化のためにそこまで学び直せるかというと、別の問題です。

セキュリティ強化とローカル処理の壁

UXPでは、セキュリティがより重視されています。

これは、アプリケーション全体としては必要な方向です。

しかし、DTPの自動化にとっては、難しさも生まれます。

ExtendScriptでは、ローカルフォルダ内のファイルを読み書きしたり、フォルダを走査したり、外部処理と連携したりすることが比較的自由にできました。

制作現場では、こうした処理が重要です。

• 指定フォルダにある画像を収集する
• ExcelやCSVを読み込む
• 出力PDFを決まった場所へ保存する
• 画像変換ツールを呼び出す
• サーバー上のデータと同期する
• 入稿用フォルダを作成する
• ファイル名をルールに沿って変更する

しかし、セキュリティが強化された環境では、こうした操作に権限や制約が生まれます。

これは安全のためには正しいことです。

ただし、従来の自動化処理をそのまま移植するには障害になります。

UXPが悪いというよりも、これまでの自動化が「ローカルPCをかなり自由に操作できること」を前提として成立していた、ということです。

現状はハイブリッド運用が現実的

そのため、現時点ではExtendScriptとUXPを二者択一にするより、役割ごとに使い分ける方が現実的です。

たとえば、次のような考え方です。

処理の種類	向いている方向
既存のInDesign自動処理	ExtendScriptを維持
ローカルファイルの一括処理	ExtendScriptを活用
過去の業務フローを止めないための処理	ExtendScriptを活用
APIとの通信	UXPや外部サービスを活用
新しいUI付きツール	UXPを検討
Webサービスとの連携	UXPやサーバーサイド処理を検討
大量の定型組版	自動組版システムを検討

現場では、「新しいから移行する」のではなく、「どの処理をどこへ置くと、最も安定するか」で決めるべきです。

• ローカル処理に強い仕組み。
• WebやAPIに強い仕組み。
• データベースやクラウドに強い仕組み。

それぞれを無理に一つへ寄せる必要はありません。

ExtendScriptかUXPかは、利用者には関係なくなるかもしれない

ここまでの話は、主に開発者や自動化担当者の視点です。

しかし、もう少し先を考えると、ユーザーにとってはExtendScriptかUXPかという違い自体が、あまり関係なくなるかもしれません。

ユーザーが求めているのは、スクリプトを書くことではないからです。

求めているのは、作業を終えることです。

たとえば、ユーザーは次のように指示するだけになるかもしれません。

• この商品データを読み込んで、カテゴリごとにページを作ってください。
• 画像がない商品は除外してください。
• 前回から価格が変わった商品は目立つようにしてください。
• 最後に確認用PDFを書き出してください。

このとき、裏側でExtendScriptが動くのか、UXPが動くのか、クラウドAPIが処理するのかは、ユーザーには見えません。

見えるべきでもありません。

重要なのは、意図した処理が正しく実行され、成果物が出ることです。

つまり、スクリプトは人が直接書くものから、AIやシステムが必要に応じて選択し、実行するものへ変わっていく可能性があります。

MCPはAdobe自動化の中心になるのか

AIが外部ツールやデータベースを使う仕組みとして、MCPが注目されています。

MCPは、AIが外部のツールやデータソースを呼び出すための共通的な接続方法です。

たとえばAIが、商品データベースを検索し、画像管理システムから素材を取り出し、PDF出力ツールを実行し、進行管理システムへ結果を記録する。

このような連携において、MCPは役立つ可能性があります。

ただし、Adobe自動化の中心がMCPになるかというと、そこは少し疑問です。

理由は、DTPやデザインの制作業務では、「何でもつなげられること」よりも、「決められた処理を、正しく、安定して実行できること」の方が重要だからです。

MCPは、AIと外部ツールを接続するためには便利です。

しかし、制作現場では次のようなことが求められます。

• どのファイルを操作するのか
• どのデータを使うのか
• どの版を正とするのか
• どのルールでレイアウトするのか
• 誰が承認するのか
• どこまでAIに任せるのか
• 出力結果を誰が確認するのか

MCPは、これらを解決するものではありません。

MCPは接続の仕組みです。

制作フローそのものを設計するものではありません。

そのため、MCPはAI活用の選択肢として使われることはあっても、DTPやAdobe自動化の主役になるというより、必要な場面で裏側をつなぐ技術になるのではないでしょうか。

Adobeが進めるAIエージェントによる操作

Adobeが今進めようとしている方向は、MCPによって外部からAdobeアプリを自由に操作することよりも、Adobeアプリの中にAI Assistantを置き、ユーザーが自然言語でアプリを操作する方向に見えます。

これは、かなり自然な流れです。

ユーザーはアプリの中で作業しています。

ドキュメントを開き、ページを見て、画像や文章を確認し、必要な変更を考えています。

その画面の中でAIに対して、

• このページをもう少し読みやすく整えて
• この見出しを短くして
• この表を2ページにまたがらないようにして
• この画像に説明文を付けて
• このレイアウトを別の商品にも適用して

と伝えられる方が、外部のチャットから操作するより自然です。

Adobeにとっても、アプリ内の状態を理解しながらAIが操作する方が、権限や操作対象を管理しやすいはずです。

利用者にとっても、「AIに指示したらアプリが動く」という体験の方が分かりやすいでしょう。

ただし、AIにAdobeアプリを任せることは現実的には難しい

ここで重要なのは、AIがアプリを操作できることと、制作業務を任せられることは別だということです。

たとえば、AIに「この見開きを読みやすくして」と伝えることはできます。

しかし、「読みやすい」の基準は案件によって異なります。

• ブランドガイドライン。
• 媒体のデザインルール。
• ページ数の制約。
• 印刷仕様。
• 広告主との取り決め。
• 既存号との統一感。
• 校正上の注意点。
• 例外処理。

こうした条件があるため、AIが見た目だけを整えても、正しい成果物になるとは限りません。

• AIがレイアウトを調整した結果、ページ数が増えるかもしれません。
• 文字が小さくなりすぎるかもしれません。
• 意図しない改行が入るかもしれません。
• 商品画像が別の商品と入れ替わるかもしれません。
• 校正済みの原稿に変更を加えてしまうかもしれません。
• 制作現場では、こうした小さなズレが大きな事故につながります。

だからこそ、AIによるAdobe操作には、単に指示を理解する能力だけではなく、次のような仕組みが必要になります。

• 操作できる範囲の制限
• データやファイルへの権限管理
• 作業ログの記録
• 変更前後の比較
• 承認フロー
• ルール違反の検出
• 差分だけを確認する仕組み
• いつでも元に戻せる仕組み
• 出力結果を検証する仕組み

AIエージェントが現場で役立つためには、「自由に操作できること」よりも、「勝手に壊さないこと」の方が重要です。

AIが活きるのは、自由な操作より、ルール化された処理かもしれない

AIは、曖昧な指示を理解し、提案を出し、下準備をすることには強みがあります。

一方で、印刷物や定型媒体の制作では、最終的な出力には高い再現性が求められます。

そのため、AIにすべてを任せるよりも、

• AIが原稿を整理する
• AIが表記ゆれを検出する
• AIが不足情報を見つける
• AIが画像候補を提案する
• AIがルールに沿ったデータへ整形する
• 自動組版が決められたルールでページを生成する
• 人が最終確認をする

という分担の方が、現実的だと思います。

AIは、

• 制作の曖昧な部分や判断の補助を担う。
• 一定のフローをカプセル化したスクリプトを生成する。

そして、その中で、

• 自動組版やスクリプトは、決められた処理を再現性高く実行する。
• 人は、最終的な判断と責任を持つ。

この役割分担の方が、AIがAdobeアプリを自由に操作するよりも、制作現場に入りやすいのではないでしょうか。

まとめ

UXPは、Adobe製品の自動化を次の段階へ進めるための重要な仕組みです。

モダンなJavaScriptを使え、WebサービスやAPIと連携しやすく、今後のAdobe製品の拡張基盤として重要性は増していくと思います。

しかし、UXPへの移行は簡単には進みません。

ExtendScriptには、長年積み上げられた現場の資産があります。

その資産は単なるコードではなく、制作フロー、例外処理、ファイル運用、出力ルール、現場の知識そのものです。

そのため、ExtendScriptは古いから終わるのではなく、現場で動いているから残り続けます。

一方で、ユーザーにとっては、今後ExtendScriptかUXPかという違いは、次第に重要でなくなるかもしれません。

自然言語で目的を伝え、AIが必要な処理を選び、Adobeアプリや外部システムを動かす。

そうした方向へ進む可能性はあります。

ただし、MCPのような接続技術がそのまま制作現場の答えになるわけではありません。

接続できることと、正しく制作できることは別です。

Adobeが進めるAI Assistantのように、アプリ内で自然言語から操作できる方向は、ユーザーにとって分かりやすく、今後広がっていくと思います。

しかし、実務では、AIが自由にレイアウトやデータを操作できることよりも、ルールに沿って正しく処理できること、変更を確認できること、責任を持って出力できることの方が重要です。

これからのAdobe自動化は、ExtendScriptかUXPかという二択ではありません。

使う側が、メーカーの仕様に振り回されるということは避けなければいけません。

私たちが考えるべきことは、AdobeまたAdobe以外も視野に入れ、

• AIに何を任せるのか。
• 人がどこを確認するのか。
• どの処理をルール化するのか。
• どのデータを正として扱うのか。

その設計こそが、これからの制作自動化の中心になっていくのだと思います。