AppleScriptによる並列処理は、これまでにも何度かテストを行ってきました。

古くは、Mac OS X 10.5ぐらいの時代に行っていた、大量のEPS書類の破損チェック。これは、割と骨の折れる作業のうえに効果も大きかったので（実用性があって）よかったのですが、EPS書類を大量に扱う現場自体が一般的ではありません。また、macOS 13以降ではEPSを取り扱うAPI自体が廃止になり、実際に呼び出せなくなりました。

Intel Macの時代にノート機で並列処理（画像変換）を行ってみましたが、当時はSSDのI/O速度がボトルネックになって、並列化をすすめても変更前よりも速く処理することはできませんでした。

Intel Mac時代、たとえば4コア8スレッドのCPUでAppleScriptによる並列処理を行うと、4スレッド分動かすだけで割とCPUの処理が埋まるという状態になっていました。あとは、密度の高い処理を行うことで、CPUの熱問題に直面しやすくなったということもありました。外部機器により強制冷却といった話も必要になってきました（あるいは、デスクトップ機でやるとか）。

やがて、REST APIを呼び出す処理（とくに、高速メール送信など）といった、「並列処理すると効果が大きそうな用途」が見つかってきました。待ち時間が割と長いうえに、サーバー側の処理が多重化されているので、リクエストを大量に出せば大量に処理してもらえるという環境でもあります。

技術的には「十分に可能」な」レベルに基礎研究が進んできましたが、問題は「用途」です。

並列処理すると効果が大きくて、その速度的なメリットを多くのユーザーに共有できる「用途」。

この用途を見つけることが並列処理の大きなテーマになっていました。

最近「これならいけるのでは？」と考えている用途が、PDFのページごとの画像化処理です。

300ページ強のPDFを連番つきのJPEG画像に分割するのに、M1 Macでも1分ぐらいかかります。1ファイルあたり0.2秒以下で処理できているので十分に速いのですが、正直なところCPUの能力にはぜんぜん余裕がある状態ですし、1分も待たされるのはどうかと感じます。

これを並列処理化して、50パーセント程度の処理時間で完了できたら成功。これよりも短い時間で処理できたら大成功でしょう。

AppleScriptの並列処理については、macOSの並列処理用Frameworkを活用するのではなく、複数アプレットを同時起動し、それぞれのアプレットに指定のAppleScriptをローディング。中心となるAppleScriptから順次「手の空いている」アプレットに処理を割り振るという構造で動いています。

当初は、並列処理用アプレットをその場で生成して起動していたのですが、セキュリティ的にそのような運用が許可されなくなりそうだったので、「あらかじめ用意していたアプレットをCPUのコアの個数だけ起動」とかいった使い方をするように変化しました。