書籍制作にもSSoTと冪等性を持ち込みたい

新刊の原稿を書き終えて、編集者から初校ゲラが届いた。指摘は的確で、ありがたい。ただ、この先の工程を思うと、気が重い。

本を作るたびに引っかかっていることがある。原稿をInDesign（組版ソフト）に流し込んだ瞬間から、「正本」が行方不明になる問題だ。

原稿はMarkdownで書く。Gitで版管理もしている。ところがInDesignに流し込んで組版を始めると、修正の主戦場がInDesign側に移る。校正で見つかった誤字、リライト、改行の調整。それらはすべてInDesignのファイル上で直される。元の原稿には戻ってこない。

プログラマの目には、これはSSoT（Single Source of Truth）の崩壊に見える。正本がどこにもない。いや、正確にはInDesignのファイルが事実上の正本になっているのだが、それはMarkdownのように差分を取ったりGitで管理したりできるものではない。増刷や改訂のたびに「どれが最新版か分からない」が起きる。

では、InDesignを使わなければいいのか。CSS組版ツールを使えば、原稿ファイルから直接PDFを生成できる。SSoTは保たれる。だが、そう簡単な話ではない。

組版の現場で行われている微調整は、ちょっと代えが効かない。写真の回り込み、見開きの左右バランス、1行あふれたテキストの処理。ゲラを見ればわかるが、こうした調整は画面を見ながら手を動かさないと追いつかない。コードだけで再現しようとすると、エンジニアリングコストが跳ね上がる。

問題はInDesignではない。工程にある。

これはインフラの世界で起きたことに似ている。

昔のサーバー管理は、SSHで入って手作業で設定を変えていた。設定ファイルを直接編集し、手順書を頼りにコマンドを打つ。うまくいったら手順書にメモを追記する。やがてサーバーが増え、手順書と現実が乖離する。SSoTの崩壊だ。

これを解決したのがIaC（Infrastructure as Code）だった。設定をコードで記述し、ツールが自動で適用する。何度実行しても同じ結果になる。冪等性の担保。

書籍制作にも、同じ発想を持ち込めるのではないか。

Markdownを正本（SSoT）として維持しつつ、InDesignは「ヘッドレスなレンダリングエンジン」として使う。プロが作ったInDesignテンプレートをデザインシステムとして用意し、Markdownの見出しや本文をスタイルと1対1で対応させる。

目視で見つけた微調整（「32ページの図をY方向に2mm上げる」「このテキストフレームのトラッキングを詰める」）は、InDesign上で直接直すのではなく、レシピファイルにデータとして書き出す。

スクリプトがMarkdownとレシピを読み込み、流し込みと微調整を自動で実行する。何度ビルドしても同じ紙面が再現される。冪等性だ。

SSoTと冪等性が確保されていれば、AIとの相性は抜群に良い。正本が一箇所にあり、何度やり直しても壊れないなら、AIに任せられる範囲が一気に広がる。

MCPを介してAIが入ると、こうなる。InDesignにプラグインを常駐させてMCPサーバーとして動かし、人間は組版画面を見ながらAIに指示する。「32ページのキャプションが1行あふれてるから直して」。AIが文脈を判断して、文章を数文字削るか、オブジェクトを数ミリ動かすかを決め、変更をMarkdownとレシピファイルの両方に書き戻す。

人間はマウスを触らない。でも最高品質の組版画面を確認しながら、SSoTの更新と画面の修正が同時に起きている。APIもMCPも、そろそろ手が届くところまで来ている。

ツールを捨てるのではなく、工程をアップデートする。SSoTと冪等性は、ソフトウェア開発だけのものではない。