はじめに
昨今、様々な場所で AI の話題を耳にします。
弊社でも今年の5月ごろから AI の導入を始めており、私自身、担当する業務のあちこちで AI を使う機会が増えています。
文章の作成はもちろん、計画の立案補助や、コードの作成など様々な場所で利用しています。
中でもコーディングスタイルは大きく変化しており、以前は自分で一から書いていたものが、今は AI を中心に据えたものに変化してきました。
この記事は、Indesignスクリプトにおける AI活用の知見を共有しようと思って作成したものです。
完全なる初学者ではなく、少しプログラムをかじった人向けですが、
AI をつかったスクリプト作成のサンプルの一つとして、参考にしていただければと思います。
AI を使うことで効率が良くなる部分
AI を使って一番効率的になったと感じるのは、コードを書く前後の調べ物が減ったことです。
プログラム開発では、実際にコードを書いている時間よりも、調べ物やデバッグの時間のほうが長い、とよく言われます。
Indesign のスクリプト開発でも、これはそのまま当てはまると感じています。
言語の仕様や文法のリサーチ、調べ物とトライアルアンドエラーの繰り返しのほうが、書いている時間よりずっと長かったと思います。
具体的に時間を取られていたのは、DOM の仕様把握や ExtendScript 特有の記法などでしょうか。
例えば、JavaScript では値の中身を確かめたいときに console.log() を使いますが、ExtendScript ではこれが使えず、代わりに $.write() を使います。
// JavaScript（ブラウザや Node.js）
console.log(doc.name);
// ExtendScript
$.write(doc.name);当時 AI があれば、これを調べるのに遠回りはしなかっただろうなと思います。
初学者を脱してからも、自動化対象のinddファイルの構造の把握や、曖昧なままの文法のリサーチには、相変わらず時間がかかります。作業で言えば、地道にオブジェクトの構造を調査したり、資料で該当のオブジェクトやメソッドを探したりなどです。
例えば、以前は「正規表現で、テキストフレームから特定の文字を含むものを調べたいな」と思ったときに
まずは方法を調べて、それから書く……のようなプロセスを踏んでいました。
その粒度までやりたいことが具体的になっているのであれば、今では AI のチャット欄にやりたいことを
そのまま流すだけでプログラムを組んでくれます。便利ですね。
エラーで詰まったときは、自分で仮説を立てて、AI にコードを書かせトライさせる流れを繰り返して
以前より圧倒的に多くの量を試せるようになりました。
AI を使うことによるデメリット
便利な一方で、デメリットもあります。一番大きいのは、自分の頭で考える機会が減ることです。
AI を使い始めてから、エラーが出たときにチャット欄へそのまま貼り付けることが明確に増えたと感じます。
以前ならエラーメッセージを読んで、どこが怪しいかを自分で考えてながら調べていました。
仕事自体は早く進むもののこのままでいいのかな、という漠然とした危機意識があります。
そこで、自分の中で一つ決めていることが、「AI が返してきたコードや説明の中に、わからない語が出てきたら、理解するまで勉強する」というものです。これは、勉強の手段に AI を使うことはやめないが、意味がわからないままにしておくのは避けようと心がけです。
また、ある程度調べてもわからなければ、そこでいったん諦めても構わないとも思っています。
プログラムに触れ続けていると、以前わからなかったことが、ふと急に理解できる瞬間があります。
一度調べておいたことは、そのときのための引っかかり、いわば楔として残ってくれるので、その場では理解しきれなくても調べた意味はあると考えています。
込み入った処理をしたい時
簡単なスクリプトなら、やりたいことを伝えるだけで動くものが返ってきます。
ですが、込み入った処理を行わせたいときは、人間が主導してスクリプトを書かせたほうが、結果的に効率が良いと感じています。
投げるだけではできないこと
複雑であったり長い工程のスクリプトを作る際には、
やりたいことを AI にそのまま投げるだけでは、期待したものはなかなか返ってきません。
あまり長い指示を出しても、記憶量の問題などでうまく処理しきれないからです。
運良く返ってくることもあるのですが、確率が高いとは言えないですし、都度生成し直すのでは効率が悪いです。
また、別の問題として返ってきたコードが長大だと、
どこでエラーが出ているのか検査しづらく、同時に拡張性も低いです。
そのため、私が込み入った作業を頼むときは、一度に投げるのではなく、仕様書を用意しています。
どう解決する？
以下は、私が AI に命令して書いたスクリプトの仕様書の一部です
(Animate CC のものですがご容赦ください。)
# makeShapeTween スクリプト仕様書
（中略）
## 処理フロー
> **実装メモ**: ステップ 1〜3 は `changeDuration.ts` に同様の処理があるため、そちらを参考に実装する。
### ステップ 1: ドキュメント取得
- `fl.getDocumentDOM()` でドキュメントを取得する
- 取得失敗時: `fl.alert()` で通知して終了
### ステップ 2: 対象レイヤーの抽出
- L 系レイヤーの命名規則に一致するレイヤーを収集する
- 0 件の場合: `fl.alert()` で通知して終了
### ステップ 3: 選択レイヤーの取得と検証
- `timeline.getSelectedLayers()` で選択中のレイヤーのインデックスを取得する
- 0 件の場合: `fl.alert()` で通知して終了
- L 系命名規則に合わないレイヤーが含まれる場合: `fl.alert()` で通知して終了
（後略）
実際の方法は必要そうな処理をそのままチャット欄に入力し、処理の手順や、
そのスクリプトを処理する対象の仕様などを AI にまとめてもらうだけです。
AI への伝え方や、最終的な形式はなんでも良いのですが、実装する箇所をできるだけ細かく区切ってあげることが肝要です。
ある程度プログラムの作り方に慣れている人であれば、
作りたいものをどう細かくしていくかがなんとなく頭に思い浮かんでいると思いますし、
ここは経験が問われてくるところだと思います。
Indesign で例を挙げると、「ドキュメント内のテキストフレームのうち、特定の文字列を含むものに赤い枠線を付けたい」という処理なら……
- 指定した文字列を含むフレームに赤い枠線を付けるスクリプトを作りたい
- app.activeDocument を取得する。
- 全テキストフレームを配列にする。
- 各フレームの contents に検索文字列が含まれるかを判定し、含まれるものだけを別の配列へ集める
……
このくらいの処理であれば分けなくても動くものが返ってきますが、手順を区切っておくと、
動かなかったときにどこで止まったかがすぐにわかりますし、
あとから判定条件を正規表現に変えたくなったときも判定の部分だけを直せば済みます。
経験則ですが、そのまま生成するより、ざっくりとでも処理は分けたほうがアウトプットの質がよくなるので
初学者の方でもできる限り頑張ってチャレンジしてみてください。
仕様書を作るメリット
仕様書を作るのは手間ですが、それ自体にメリットもあります。
一つは、テストに役立つことです。
仕様書に前提条件やエラー時の挙動を書いてあるので、テストで確かめる項目を洗い出しやすくなります。
テストと言われてもピンとこない初学者の方は、ここはいったんスルーしてください。
もう一つは、ドキュメントが残ることです。
ここで言うドキュメントとは、そのスクリプトが何をするものか、どう使うのかを書いた説明書のことです。
スクリプトは意識しなければ、コードだけが残っていましたが、
最初に書いた仕様書がそのままドキュメントの草書となるので、作業コストが省略できます。
まとめ
AI の運用について、自分の頭で考える機会をどう残すか、
どこまで仕様書を書くか、など考えるべきことはたくさんありますが、
どれも使い始めてから見えてきたことで、使う前に机上で悩んでいても答えは出なかったと思います。
なのでこれからも悩んで試行錯誤しながら使っていけたらと思います。
ここまででも紆余曲折ありましたが、仕事が確実に早くなったことは間違いありませんし、
調べ物に費やしていた時間が減った分、時間を有効活用できるようになったと思います。
この記事が AI を使ったスクリプト作成のサンプルの一つとして、参考になれば幸いです。