Windowsの開発者と話をしていて、「複数のGUIアプリを操作して自動化するという話が理解できない」と言われます。

　ファイル情報（選択中のファイル、選択中のフォルダ）をFinderから取得して
　spotlight機能を用いて選択中のフォルダ以下のPages書類を抽出し
　個別にPagesでオープンしてPDFを書き出し
　書き出したPDFをファイル名順にならべかえて連結し
　DropboxにREST API経由でアップロードして共有し
　得られた共有URLを指定の送付先にメール（Mail.app）で送信する

と、複数のGUIアプリを操作した自動化のワークフローは、普通にありえるものです。ありふれすぎています。

自動化のサイズ

ここで、ひとことに「自動化」といったときに、ユーザーごとに想定する「サイズ」がぜんぜん違うことに気づきます。

・(A)メニュー項目をいくつか連続して操作する「操作自動化」
・(B)1つの連続した操作を繰り返して実行する「作業自動化」
・(C)MacがタイマーでいくつかのScriptを実行してロボット動作する「業務自動化」

(A)＜（B）＜（c）と粒度の大きさが変わるところで、世間で言われる「自動化」というのは、ほぼ(A）の操作自動化のレベルと思われます。

自分が行なっているのは、（B）や（c）のレベルの自動化です。

（A）のレベルの「操作自動化」が悪いとは言いませんし、そういうレベルでも自動化に取り組むことには意義はあることでしょう。

ただ、(B）（c）と比べると成果として得られる「メリットが少ない」とは思います。操作を行うための心理的な障壁を下げる、という意味ではメリットがあるのかもしれませんが……。

（B）や（C）では、まとまった動作を放置状態のMacで行うものであり、人間が作業を眺めている必要はないものです。

放置状態で勝手に作業

（B「作業自動化」）や（C）「業務自動化」では、人間がいちいち指示する必要がないか、Scriptの動作を開始する場合にのみ対象フォルダなどのパラメータを指定するものです。

独立した作業なり業務を実行できるようにしておけば、実行するMacの台数を増やせば、それだけ同時にこなせる仕事が増やせます。

それだけ自動化してあれば、作業のためにアルバイトを雇う必要もありませんし、夜通し作業を行わせておいてもよいでしょう。

作業自動化や業務自動化に必要な「仕様書」

これらのまとまった作業を行うAppleScriptを作って運用する場合には、開発前に「仕様書」が必要になります。たいしたものでなくてもいいですが、どういった作業をどういう手順で行うのか、プログラムに書く前に人間の言葉でまとめておく必要はあるのです。

それは、箇条書きの文章で書いておいてもいいですし、画面キャプチャをまとめておいてもよいでしょう。

仕様書を書かないと、どこに向かって、どのように進んでいくのかを誰も理解していないという話になってしまいますし、それではScriptはおろか関与する人々が誰も「正しい作業」を理解できていないという話になってしまいます。

AppleScriptを使ったことのない人が、AppleScriptを使うときに、どのような考え方で問題を解決したらよいでしょうか？

（1）特定のアプリ上でのデータの作成/取得

AppleScriptの一番やりやすい作業は、アプリケーションの書類を大量に作成/チェックするというものです。

書類をともなうアプリで、AppleScriptに対応しているものは、AppleScriptによる書類作成やチェックの自動化が行える可能性が高いと考えてよいでしょう。

Word、Excel、PowerPoint、Pages、Numbers、Keynoteなどのオフィスアプリ。

InDesign、Illustrator、Photoshopといったクリエイティブ系のアプリ。

そうしたアプリを中心に作業を自動化したい、という話はとても「やりようがある」と考えます。難易度が低いわけではありませんが、何か困っていて解決したいことがある場合には、解決できる可能性が高い、ということです。

（2）Webブラウザやメーラーの操作

日常的に使う機会の多いWebブラウザやメーラーで行う作業をまとめて自動化することができます。

やや、難易度が高くなりますが……Webブラウザを操作して特定のWebサイトにログインして、データを取得し、ログアウトするという操作は実際にAppleScriptで行えるものの代表的なものです（Webサイト側の「作り方」によってうまく操作できないこともあります）。

メーラー関係の作業についても、大量のメールを、内容を変更しつつ送信するという作業はAppleScriptに適した作業です。ただし、日常的に利用しているメーラーが、Appleのメール.appである必要があります。他のメーラーではAppleScriptへの対応度が低いとかまったく対応していないケースがあるため、これ以外の選択肢がないといって差し支えないでしょう。

（3）AppleScriptだけでデータ処理

AppleScriptに特殊なデータを扱うような（他のGUIアプリのデータを、アプリなしで読み書きして操作するような）機能は用意されていません。

テキスト、画像、PDF、QuickTimeムービーといった一般的なデータであれば、AppleScriptだけで処理できる可能性は高いところです。とくに、PDFについてはmacOS 10.10以降でmacOSのAPI CocoaをAppleScriptから直接呼べるようになったために、ウォーターマークを追加する「以外」の操作であれば実際に処理できます。

当Blogでは、日々AppleScriptを書いている中で、「この情報は有用なので共有しておくべき」と考えたものを掲載し、すぐに使っていただけるようにして公開しています。

書き方、使い方、詳しい説明については、電子書籍にまとめて約90冊ほど出しています。

つまり、当BlogはAppleScriptが何であるかを理解していて、実際に書ける人に対して情報を発信する立場です。

ただ、ちょうど夏休みということもあり、ちょっとそのあたりについて書いてみることにしました。

AppleScriptってなに？

「macOS上で動くマクロ言語」とか言うと、何か理解できたような気になりますが……これだけでは何も説明わかりません。

macOS上の機能、各種GUIアプリの機能、shell scriptの機能など、さまざまな機能を呼び出して、データをやりとりする、インタプリタ型（逐次解釈実行型）のプログラミング言語です。

macOS上の大きな機能や小さな機能を呼び出せるようになっていて、とくにGUIアプリの操作や、GUIアプリの設定情報や、GUIアプリがオープンしている「書類」にアクセスして情報をとってきたり、設定したり……という操作が行えます。

AppleScriptがGUIアプリを操作する方法は、いくつか手段が用意されています。

（1）アプリ内の用語辞書を通じてやりとりする

AppleScriptがGUIアプリを操作するやりかたは、マウスカーソルを操作してメニューを選ぶといった方法ではありません（別途ありますが）。それでは、遅すぎるし、画面に表示されていなかったら操作できないですし、「できないこと」が多すぎます。

なので、あらかじめ「こういうコマンドを受け付けるよ！」というコマンドの一覧がAppleScriptに対して読める形でアプリ内に格納されています。ユーザーもこのコマンド一覧（用語辞書）を読んで、AppleScriptを書くことになります。

（2）GUI部品を操作してGUIアプリを操作する

「メニューのx番目の項目を選んでクリックする」といったGUI部品を操作するやりかたです。これはこれで便利ではあるものの、スピードが（1）にくらべて100倍以上遅いですし、毎回確実に動くAppleScriptをこの方法で書くのは、けっこう難しいです。

いまだと、システム設定.appを操作していろんなシステムの状態を変更するようなAppleScriptを動かしたいと考えているユーザーさんがけっこういて、そのための方法をいろいろ探してはいるんですけれど、システム設定.appで細部まですべて操作するのはかなり無理があるので（iOSっぽい作り方になったことが災いして、GUI部品の階層を追いきれない）、この（2）の方法があるからできるっしょ！　と、安易に考えないほうがいいです。

先日、X（旧Twitter）上でMacにつながっている複数のディスプレイのうち、メインディスプレイを切り替えたり、画面の解像度を切り替えたいという人がいて、ちょっとやりとりしました。その彼は、この（2）の方法でなんとかなるんじゃないかと考えていたようですが、実際に自分でやってみたところ、それはできませんでした。

なので、かつて調べてあった「SwitchResX」を用いる記事を紹介したところ、「有料アプリを買うほどではない」とのことでした。事実上、SwitchResXを使う方法でしか実現できないのですが、どうするんでしょう？

（3）その他の手段をさがす

shell commandなどでディスプレイ解像度を取得・変更するものがあれば、それを呼び出すことになります。

AppleScript初心者がつまづきやすいのが、logコマンドのようです。

スクリプトエディタ上でlogコマンドによって、スクリプトエディタ上にログ表示されるので、他の実行環境（Mail.appのプラグインScriptとか、AppleScriptアプレットとか）でlogコマンドを実行して、その内容がスクリプトエディタにログ表示されないことにブチ切れる初心者が何度も観測されています。

logコマンドは、スクリプトエディタ（もしくはScript Debugger）上でAppleScriptを実行している場合に、その実行しているエディタのウィンドウ内のログエリアに表示されます。

スクリプトエディタ（およびScript Debugger）以外の実行環境でAppleScriptを実行しても、スクリプトエディタのログ表示エリアに表示は出ません。これは、バグでもなんでもない仕様なのですが、この点でブチ切れる初心者の多いこと多いこと。

AppleScriptの実行環境＝ランタイム環境はmacOS標準装備されているだけでも11個ぐらいありますが、環境によって実行できないコマンドがいくつか存在します。

logコマンド

前述のとおり、便利なコマンドではあるものの、「いつでも使える」「どこでも使える」というものではない点に注意が必要。

display notificationコマンド

本コマンドは、アプリケーションの組み込みAppleScript環境で実行できないケースが観測されています。AppleScript実行をXPCサービス内で行なっているアプリケーション（Keyboard Maestro、BBEdit）では、notification表示がOSの制約（仕様）により行えません。

この実装自体が間違っているわけではないのですが、ユーザーに「本アプリの内蔵スクリプトメニューから実行したAppleScriptでdisplay notificationコマンドは有効ではない」ことが周知されていないことに問題があります。

display dialogコマンド

本コマンドが実行できないケースはほとんどありませんが、Xcode上でAppleScriptによりGUIアプリを組んでいる際に、メインのAppleScriptではなくサブクラスを定義しているAppleScript内でダイアログ表示が行えない（デバッグしにくい）という現象を確認しています。

sayコマンド

おおよそ、display dialogコマンドと同様です。

on openイベントハンドラ

ドロップレット形式で書き出した（＝スクリプトエディタやScript Debugger上で実行した状態ではない）状態であればドラッグ＆ドロップは受け付けますが、そうでない場合には本イベントハンドラにより他のファイルやフォルダをFinder上でAppleScript書類にドラッグ＆ドロップしても、ファイル/フォルダの受信は行われません。