AIツールにpdfToolbox用の面付けスクリプトの作成を依頼する場合、一般的なJavaScriptを記述するよう求めているわけではありません。pdfToolboxの面付け環境内で動作するJavaScriptを記述するよう求めているのです。

つまり、AIはpdfToolboxに関する特定の概念を理解する必要があります。具体的には、JavaScriptコンテキストに挿入されるオブジェクト、それらのオブジェクトで利用可能な便利メソッド、使用する必要がある定数、期待される演算順序、そして面付けそのものの背後にある生成ロジックなどです。

ここからが面白くなってくる。

公開されているAIモデルは、膨大な量の一般的なJavaScriptを学習してきました。また、印刷制作や面付けに関する一般的な情報も学習しています。しかし、pdfToolbox専用の面付けスクリプトの作成に関する公開されたトレーニング資料はそれほど多くありません。つまり、モデルは一見妥当に見えるJavaScriptを記述できる一方で、pdfToolbox特有の重要な詳細については誤った処理をしてしまう可能性があるということです。

したがって、重要なのは単に「より良い質問」をすることだけではありません。重要なのは、AIにとってより良い作業環境を構築することです。つまり、AIが信頼性の高い面付けスクリプトを生成するために必要なドキュメント、事例、および文脈を提供できる環境を整えることです。

このウェビナーでは、AIツール内でプロジェクトベースの構成を採用しました。具体的なツール名よりも重要なのはそのアプローチです。つまり、AIには、複数の会話にまたがって、関連するドキュメント、ルール、事例、指示などを一箇所にまとめて保管できる場所が必要なのです。

このプロジェクトには、いくつかの種類の資料が含まれていました。

まず、pdfToolboxのドキュメント、特に面付けに関するドキュメントが含まれていました。これにより、AIは、使用することが想定されている機能に関する信頼できる情報源を得ることができます。

第二に、そこにはガイダンスファイルの小さなフレームワークが含まれていました。その

ルール、コーディングスタイル、推奨されるパターン、およびAIがユーザーとどのようにやり取りすべきかについて記述した。例えば、AIには「巧妙さよりも明快さを優先すること」「読みやすいコードを使用すること」、そして「ユーザーの要求が曖昧な場合に、黙って仮定を立てないこと」が指示された。

第三に、入念に作成されたサンプルスクリプトが含まれていた。これらのサンプルは、単に過去の実用スクリプトをそのままコピーしたものではなかった。そうしていたら、一貫性が著しく損なわれてしまっただろう。実際の実用スクリプトは時間の経過とともに変化することが多く、異なる習慣やスタイル、あるいは歴史的な制約が反映されている場合がある。AIワークベンチにとっては、ノイズの多いサンプルを大量に用意するよりも、一貫性のあるサンプルの方が有用である。

これらのファイルの目的は、AIを「創造的」にすることではありませんでした。その目的は、AIに狭く、信頼性の高い基準枠を与えることでした。

この実験から得られた重要な教訓の一つは、例が多ければ多いほど良いとは限らないということだ。

AIに、似たような問題を5つのわずかに異なる方法で解決した5つの例を与えた場合、AIはどのパターンに従えばよいのか判断できない可能性があります。AIは、異なるスタイルを混ぜてしまったり、時代遅れの手法を真似たり、ある例では技術的に妥当でも別の例では妥当ではない仮定を立ててしまったりするかもしれません。

そのため、ウェビナーで使用したサンプルファイルは、pdfToolboxの重要な面付けの概念を一貫したスタイルで網羅できるよう、意図的に作成されました。これらは架空の例ではありますが、この文脈においてはそれが強みとなります。これにより、モデルに、私たちが従ってほしいパターンを学習させることができるからです。

これは、新人開発者の研修と非常によく似ています。単に10年分の過去のスクリプトを渡して、うまくいくことを願うだけではいけません。ドキュメントを提供し、規約を説明し、良い例を示し、「良い」とはどういうものかを明確に定義する必要があります。

この設定の重要なポイントは、AIにコードを書く前に質問をするよう指示することでした。

これは、制作ワークフローには隠れた前提条件が数多く存在するため、重要な問題となります。どのページボックスを使用すべきか？ 裁ち代を含めるべきか？ どのような余白やマージンが必要か？ 用紙の有効活用につながるなら、ページを回転させるべきか？ 受け取るファイルは常に1ページのものか、それとも複数ページのものもあり得るか？

そうした詳細情報が欠けている場合、AIは単に推測すべきではありません。確認すべきです。

ウェビナーのデモでは、これが実際に確認できました。簡単なステップ・アンド・リピートの面付けを作成するよう求められた際、AIはスクリプトを生成する前に不足している情報を尋ねてきました。不足していた詳細情報を提供すると、AIはpdfToolboxにコピーしてテストできるJavaScriptを生成しました。

だからといって、生成されたスクリプトがすべて自動的に正しいというわけではありません。つまり、曖昧なプロンプトを1つ与えて、その後に検証されていないコードを実行するよりも、このプロセスの方がはるかに安全になるということです。

AIが生成したコードは、必ずテストを行う必要があります。

ウェビナーでは、生成されたステップ・アンド・リピート設定がpdfToolboxで正常に動作しました。しかし、それ以前の実験では、生成されたスクリプトにバグが含まれていました。あるケースでは、パターンの繰り返しを行うアルゴリズムが、想定されたページ領域を完全にカバーできていませんでした。 有用だったのは、AIが修正にも役立った点です。目に見える問題を説明することで、モデルはスクリプトを調整し、結果を改善することができました。

これは、このワークフローの中で最も有望な部分の一つです。AIの回答を最終的な答えとして受け入れる必要はありません。結果を確認し、どこが間違っていたかを説明し、スクリーンショットや出力ファイルを提供して、AIにスクリプトの修正を依頼することができます。

正しい考え方は、「AIがテストに取って代わる」というものではありません。正しい考え方は、「AIが、草案の作成、テスト、修正、改良というサイクルを加速させる」というものです。

ウェビナーで提起された質問の一つは、同じプロンプトを使えば、来週も同じスクリプトが生成されるかどうかということでした。

正直なところ、必ずしもそうとは限りません。

AIシステムは、従来のソフトウェアのように完全に決定論的ではありません。モデルによって、質問の表現が異なったり、生成されるコードがわずかに異なったり、同じ結果にたどり着くまでの過程が異なったりすることがあります。さらに、ツールそのものも急速に変化しています。今日利用可能なモデルと、来月利用可能なモデルとでは、その挙動がまったく同じとは限りません。

しかし、制御されたワークベンチアプローチを採用することで、再現性が向上します。AIにドキュメント、スタイルルール、標準的な例、および明確な操作指示を与えることで、制御不能な推測の割合を減らすことができます。出力は毎回まったく同じになるわけではありませんが、機能的に類似しており、読みやすく、期待されるpdfToolboxのパターンに沿ったものになる可能性が高くなります。

実運用においては、その区別が重要になります。目的は、盲目的に信頼することではありません。目的は、より良い出発点と、より効率的な開発プロセスを実現することにあります。

ウェビナーで出されたもう1つの興味深い質問は、この種のAIを活用したワークフローを、将来的にはpdfToolboxに直接統合すべきかどうかという点でした。

それは重要な質問ですが、単純なものではありません。

今日、最も優れた結果は多くの場合、最新のオンラインAIモデルによってもたらされますが、これらのモデルは急速に変化しています。また、ユーザーによって、コーディングスタイル、前提条件、本番環境での動作に関する好みも異なる場合があります。ウェビナーで使用されたフレームワークファイルの一部には、普遍的なルールではなく、個人的な好みが反映されているものもあります。

つまり、現時点では、pdfToolbox に関連する AI 対応の資料（ドキュメントの抜粋、厳選された例、プロンプトのテンプレート、ユーザーが自身のニーズに合わせて調整できるガイダンスなど）を提供することが、最も有効なアプローチであると考えられます。

将来的には、より深い統合が注目されるようになるかもしれません。しかし、実用を目的としたAI機能であれば、本実験で示されたのと同じ原則、すなわち明確な文脈、明示的な仮定、ユーザーによる制御、そして適切な検証を遵守する必要があります。

これらの資料は、あくまで出発点として用意されたものです。唯一の正しい作業方法として捉えるべきではありません。内容を精査し、必要に応じて調整やスタイルルールの変更を行い、独自の例を追加し、ご自身の制作要件に合わせてプロンプトを改良してください。

また、有用な改善点が見つかった場合は、ぜひ私たちと共有してください。実運用での経験が蓄積されればされるほど、こうしたAIを活用したワークフローはより良いものになっていきます。

このアプローチは、pdfToolboxの他の分野でも役立つ可能性があります。

例えば、pdfToolboxでは、HTMLテンプレート、JavaScript、CSS、およびpdfToolbox固有の挙動を用いたコンテンツの配置もサポートしています。その構造も同様で、広く知られた基盤技術と、製品固有のルールや制作上の要件が組み合わさっています。

このため、これは将来の実験に適した候補となります。

AIは、pdfToolboxの面付けスクリプトを作成する上で、実に役立つものです。しかし、その有用性は魔法のようなものでもなければ、単にプロンプトを書くことだけでもありません。

真に役立つのは、ドキュメント、ルール、事例、説明、テスト、そして反復という、管理された作業環境を構築することにあります。

そのように活用すれば、AIは謎めいた「ブラックボックス」というより、実用的なアシスタントとなります。それは実務の知識に取って代わるものではなく、その知識をより容易に適用するための手段なのです。