前回の記事（DTPの仕事はAIでどう変わる？ 校正PDFからInDesign修正まで自動化して見えたこと）では、校正PDFに書かれた修正指示をAIに読み込ませ、InDesignの修正から修正後の確認までを行う実験を紹介しました。
実験を通して見えてきたのは、AIが単にDTP作業を代行するのではなく、これまで人が行っていた「指示を読む」「内容を理解する」「操作する」「確認する」という一連の工程そのものを組み替えられる可能性です。
では、もう一歩進めて考えてみます。AIは、修正するだけではなく、組版が正しいかどうかをチェックできるのでしょうか。
今回は組版ルールのチェックを題材に、従来のスクリプトによる自動化とAIを組み合わせる実験を行いました。そこで見えてきたのは、「スクリプトかAIか」という二者択一ではなく、ルールをコードで実行し、そのコードをAIが必要に応じて作るという、新しいDTP自動化の形でした。
概要
DTPの品質管理では、これまでもInDesignのスタイル設定やプリフライト、JavaScriptなどを使ったチェックが行われてきました。しかし実際の制作現場では、デザイン、データ、ワークフローなどの仕様が変わります。その結果、「以前作ったチェック用スクリプトが、いつの間にか現在の仕様と合わなくなっている」ということが起こります。
今回は「組版ルールのチェック」というよくある場面を想定し、PDFの見た目とInDesign内部のデータを確認しながら、必要なチェックコードをAIに生成させ、実行結果を検証しました。
判断すべきルールを人が定義し、そのルールを検証するためのコードをAIに作らせる。ここが今回の実験のポイントです。
こんな人に向けて書いています
- InDesignの品質チェックを自動化したい方
- DTPの校正・検版作業を効率化したい方
- InDesignスクリプトを使っているが、保守に課題を感じている方
- AIとスクリプトをどう使い分ければよいか知りたい方
- AI時代のDTPオペレーターや制作担当者の役割を考えている方
この記事のポイント
- 組版ルールは、InDesignの設定だけでは完全には担保できない
- 固定スクリプトは有効だが、実際の制作仕様と乖離することがある
- AIは、必要なチェックコードを生成・補完する役割と相性がよい
- PDFの見た目とInDesign内部データの両方を見ることで、チェック範囲が広がる
- 重要なのは、コードを書く能力以上に「何を正しい状態とするか」を定義する力である
目次
- 一字落ちをチェックする
- 従来なら、チェック用スクリプトを書く
- では、なぜAIが必要なのか
- スクリプトは「仕様そのもの」ではない
- AIにチェックコードを書かせる
- 「AI対スクリプト」ではない
- PDFだけを見るのか、InDesignも見るのか
- 画像フレームではなく、「画像そのもの」の重なりを見る
- 「固定された自動化」から「その場で作る自動化」へ
- AIが書いたコードをそのまま信用してはいけない
- 最も重要なのは「何をチェックするか」
- 暗黙知だったDTPルールを、明文化する
- DTP担当者の仕事は「操作」から「判断」へ
- 「仕事の中身」が変わる
- まとめ
一字落ちをチェックする
今回、最初に試したのは非常に単純なチェックです。たとえば本文の行末で、次のように最後の一文字だけが次の行へ落ちてしまっている状態です。
あいうえお
かきくけこ
す。ここでは便宜的に「一字落ち」と呼びます。
一文字だけ次の行にあること自体が間違いとは限りません。しかし媒体によっては「句点を含めて二文字以下になった場合は調整する」といったルールがあります。人間なら紙面を見て「ここはちょっと格好が悪い」と気付きます。では、これをコンピューターにどう判断させるのでしょうか。
従来なら、チェック用スクリプトを書く
従来の方法なら、JavaScriptなどでInDesignの各行を取得し、行頭や行末の文字を調べ、「一文字＋句点」のような条件を検出します。条件が明確で、毎回同じ条件で大量のページを調べるなら、人が目視するよりはるかに速く正確です。
ルールが明確なものは、AIでなくてもプログラムで処理できる。AIが登場したからといって、何でもAIに判断させる必要はありません。条件が明確ならコードで処理する。この原則は今後も変わりません。
では、なぜAIが必要なのか
問題は、そのスクリプトを誰が作り、変わっていく仕様やルールに対して誰が保守するかです。制作現場には、特定の場所では一字落ちを許容する、見出しは除外する、特定のスタイルだけを対象にする、縦組みと横組みで条件を変えるなど、さまざまなルールがあります。
条件が増えるほどスクリプトは複雑になり、制作仕様そのものも変わります。その結果、「制作上の正しい仕様」と「スクリプトが考える正しい仕様」が違うという状態が起きます。
印刷物のデザインや組版仕様は、コンテンツの内容によっても変わります。ここに、AIの「コンテクストを理解する」能力を使える可能性があります。
スクリプトは「仕様そのもの」ではない
スクリプトやプログラムは、あくまでルールを実行する仕組みです。本来先にあるべきなのは、「どういう状態を正しいとするのか」という、印刷物のコンテクストごとの仕様です。
その仕様を適用する方法として、InDesignのスタイル、プリフライト、InDesign用スクリプト（JSX）、Pythonなどの汎用言語、AIがあります。「このスクリプトが動いているから正しい」のではなく、「このルールを確認するために、このスクリプトを使っている」という関係です。
AIにチェックコードを書かせる
そこで試したのが、必要なチェック内容に応じて、AIにコードを作らせるという方法です。
たとえば「このInDesignドキュメントで、一字＋句点だけになっている行を探してほしい」と指示すると、AIはInDesignを調べるJavaScriptを生成します。条件を変えたければ、「見出しは除外して」「この段落スタイルだけを対象にして」と指示を変え、その都度コードへ反映できます。
AIが行うのは組版品質の最終判断ではなく、人が定義した判断基準を実行可能なコードへ変換することです。
「AI対スクリプト」ではない
AIが普及すると、スクリプトはいらなくなるどころか、もっと使われる可能性があります。これまでは「自動化したいが、スクリプトを書くほどでもない」「誰もコードを書けないから目視する」という作業が大量にありました。AIがコードを書くことで、そのハードルが下がります。
従来の「人 → スクリプト → InDesign」から、これからは「人 → AI → スクリプト → InDesign」へ。AIが人の意図をコードへ翻訳します。
PDFだけを見るのか、InDesignも見るのか
DTPには「PDFとして見える結果」と「InDesign内部に存在するデータや設定」という二つの情報があります。
文字の欠け、画像の不自然な重なり、意図しない位置などはPDFの見た目から判断しやすい。一方、画像リンク、段落スタイル、テキストフレーム、オーバーセットテキスト、座標、実際の画像領域などは、InDesign内部のデータを調べた方が確実です。
そこで今回の実験では、「見た目」と「データ」の両方から検証するという考え方を取りました。
画像フレームではなく、「画像そのもの」の重なりを見る
InDesignでは画像はフレーム内に配置されるため、フレーム同士の重なりだけでは、本当に画像が重なっているかは分かりません。必要なのは、画像フレームではなく、実際に表示されている画像領域の重なりを調べることです。
こうした複雑な条件では、人が毎回ゼロからコードを書くと費用対効果が合わない場合もあります。しかしAIがコード生成を補助すれば、「この案件ではここを確認したい」という一時的なチェックにもプログラムを使いやすくなります。
（最下段だけを検知するにはAIの方がやりやすいという印象を得た）
（見た目の判断はAIの方が優位のようだという印象を得た）
「固定された自動化」から「その場で作る自動化」へ
従来の自動化は、業務分析、仕様決定、開発、テスト、運用という流れで、繰り返しのある仕事でなければ開発コストを回収できませんでした。
AIでコード生成のコストが下がると、その場限りのチェックのためにコードを書くことが現実的になります。「自動化するほどではなかった仕事」が自動化できるようになり、必要なときに、必要な処理を生成する使い方が増えていくでしょう。
ただし、AIが書いたコードをそのまま信用してはいけない
AIが生成したコードが正しいとは限りません。対象範囲を間違える、InDesignの仕様を誤解する、想定外のデータを変更する、機密情報を送信するといった可能性があります。
テストデータの作成 → コード生成 → 実行 → 検証はセットで考える必要があります。何を変更するのか、どのドキュメントやデータを対象にするのか、元に戻せるのか、結果をどう確認するのかを設計しなければなりません。
プログラムを安全に使うための知識まで不要になるわけではありません。
最も重要なのは「何をチェックするか」
コードを書くこと以上に難しいのは、何をチェックすれば「正しい組版」と言えるのかということです。一字落ちや画像の重なりは必ずNGなのか、例外はないのか。これはAIには決められません。
最終的には、制作側がルールを定義する必要があります。AIでコードを書く作業が簡単になるほど、「われわれは何をルールとして制作しているのか」が問われます。
暗黙知だったDTPルールを、明文化する
DTPの現場には「ここは普通こうする」「この場合は少し詰める」「これは見れば分かる」といった暗黙知があります。しかしAIに作業を任せるなら、何を見るのか、どの状態なら問題なのか、問題の場合どう処理するのかを言語化しなければなりません。
これはAIのためだけではなく、会社や制作チームが持っている組版ノウハウを整理する作業でもあります。
AI時代、DTP担当者の仕事は「操作」から「判断」へ
前回の記事では、「InDesignを操作する仕事」から「AIが品質よく動ける制作環境を設計する仕事」への変化について書きました。
AIがコードを書き、操作を実行できるようになると、重要なのは、何を正しい状態とするか、どこまで機械的に判断できるか、何をAIに任せるか、何を人が判断するか、どう検証するかです。
つまり、操作ではなく、ルールと判断を設計する仕事です。
AIに仕事を奪われるのではなく、「仕事の中身」が変わる
人が一つひとつチェックし、修正するところから、ルールを定義し、AIにコードを書かせ、処理を実行させ、結果を検証するところへ。単純に仕事がなくなるというより、仕事のレイヤーが一段上がる感覚があります。
人の仕事は、「作業すること」から「作業の仕組みをつくること」へ移っていく。その変化なのだと思います。
まとめ：AIが変えるのは、スクリプトではなく「ルールの持ち方」
今回の実験では、組版ルールのチェックをAIとスクリプトを組み合わせて行いました。そこで感じたのは、AIかスクリプトかを選ぶことには、あまり意味がないということです。
ルールが明確ならコードで処理する。コードが必要ならAIに作らせる。見た目はPDFで、内部情報はInDesignデータで確認し、最後に人が結果を判断する。
重要なのは技術の選択ではなく、制作の中にあるルールを整理し、機械が実行できる形へ変えることです。AIによってコードを書くハードルが下がるほど、DTPの現場に蓄積された経験や暗黙知をルールとして整理する価値は高まります。
AIがDTPを理解するのではありません。私たちがDTPを理解し直し、それをAIが扱える形にする。今回の実験で見えてきたのは、そんなAI時代のDTPの姿でした。
