本稿は TeX & LaTeX Advent Calendar 2021 の23日目の記事です．22日目は t-kemmochi さんでした．24日目は golden_lucky さんです．

今回はタイトルの通り，jlreq と expl3 を用いてとある学会の年次大会予稿集向けの文書クラス NLProceedings を開発した話をしたいと思います．具体的には，どういった目標や目的意識を持ち，どんなことに気をつけて文書クラスを設計したのかという話を中心に進めていきます．その中で，依拠する技術的成果物として jlreq と expl3 を採用した理由についても説明したいと思います．

一方で，一部の方は期待はずれに思われるかもしれませんが，文書クラスの実装の中身を技術的に詳しく解説することはしません．というよりも，そもそも NLProceedings の実装において，解説が必要になるほど技術的に高度な部分はほとんどありません¹．逆に言えば jlreq や expl3 を用いると，少なくとも技術的には文書クラスを作成するのはとても簡単だということの証左であるとも言えるかもしれません．

本稿の目的は，同じように学会文書クラス（または類似の目的に供するもの）を新たに作成したり改訂したりする必要があるが，しかし組版のプロではないという方に向けて，少しでも抽象化できる知識や考え方を共有しようというところにあります．そのため特定の学会に固有の事情や詳細な依頼内容，属人的な部分には触れません．また，当然ですが，本稿の内容は私個人がどんなことを考えて開発を行ったかを説明するもので，いかなる学会の公式見解とも何ら関係ありません．

前提：学会文書クラスに求められること

そもそも学会文書クラスの目的とは何でしょうか．これは第一義的には「投稿規定を満たす論文を容易に作成できるようにすること」になるのではないかと思います．この学会文書クラスを用意することの目的について，学会の運営者側と実際に原稿を作成する投稿者側の双方の視点から検討することで，学会文書クラスにどのようなことが求められているのかを明らかにしていきましょう．

まず学会の運営者側，すなわち学会文書クラスを用意する側の視点に立って，なぜ文書クラスが必要になるかを考えます．投稿規定を策定する目的は学会によって少しずつ異なる可能性がありますが，多くの場合は「論文誌や予稿集など巻全体で見た目を統一的にするため」「投稿論文の中身の分量を規定するため²」あたりに集約されることと思います．ともかく，こうした理由からしばしば投稿規定というものが学会の運営者によって策定されるわけですが，実際にその規定を満たす原稿を数多くの人々から投稿してもらうには，その規定を満たす原稿を作りやすいように準備をしておく必要があります．現実の投稿者の多くは，投稿用の原稿を作成する他にも研究活動を始めさまざまな業務をこなす必要のある方々なので，原稿のレイアウト作りのために無限の時間を使えるわけではないからです．この目的を達する方法は MS Word のテンプレートを用意する，LaTeX のテンプレートを用意する，専用の LaTeX パッケージを用意するなど色々あるわけですが，LaTeX の文書クラスを用意するというのはこうした手段のうちの1つになります．いずれの手段を用いるにしても，学会運営者としては投稿規定という “要件” を満たす “実装” を求めることになります．

また運営者視点では中長期的にみた保守性も大切です．学会の運営者というのは，必ずしも LaTeX などの組版ツールに特化した専門家の集団ではないわけですが，投稿規定の “実装” はそうした運営者たちによっても当分の間なるべく少ない時間と労力で動くものを維持できる状態であることが望ましいでしょう．ただこの点に関しては，理想としてはそうであっても，現実的にはかなり低い位置に限界があるのもまた事実ではあります．

ここで見方を変えて，実際にそうした “実装” を使用するユーザ，すなわち投稿者の視点で実装に求めたいことを考えてみると，さらに追加で満たしているとよい性質が見えてきます．そうした性質のうち，まず最初に挙げるべきは利便性です³．すでに言及していることですが，一般に投稿者というのは1つの原稿にいくらでも時間と労力をつぎ込むことができるわけではないので，なるべく簡便に原稿を用意する方法が整っていて欲しいと願っていることでしょう．その観点から，多くの投稿者が普段使っているツールや知識で原稿を作成できることが望ましいです．この部分は分野によっても大きく異なるだろうと思いますが，例えば理工系の一部の分野では論文作成ツールのデファクトスタンダードは LaTeX であり，そういった分野では LaTeX 向けの論文作成手段が整っている方が良いということに異論のある人は稀でしょう．

利便性に加えて，投稿者視点では私がそれと同じぐらい大事だと考えた性質があります．それは「うっかり」で規定違反になってしまうことがないという意味での安心性です⁴．もちろん，投稿規定を隅々まで読み込み，さらに使用しているツールに関して十分に豊富な知識と経験があれば，意図せずに投稿規定に違反してしまうということは防ぐことができるはずですが，実際には忙しい投稿者にとって長い投稿規定の隅々までを漏れなく把握し，自分がツールに対して行った設定が規定を満たすものになっているかどうかを確認するというのは意外と大変なことです．実はこのことが，学会からの依頼を受けて今回の “実装” を用意する段階で，少なくとも私が個人的に，テンプレートでもパッケージでもなく文書クラスでの実現にこだわった直接の理由になっています．

一方で，少なくともそれぞれの論文著者が組版まで行うという方式が採られている場合には，商業出版レベルの高い組版品質を実現することはあまり重視する必要がないと思われます．もちろん，読者にとっての読みやすさという意味ではなるべく品質のよい組版成果物を目指すことは重要ですが，それは学会の用意するテンプレートや文書クラスだけでどうにかなる問題ではなく，実際に組版を行う作業者にも高い力量を求めなければなりません．組版的に商業出版レベルの品質を目指すというのであれば，文書クラスの作成をプロに依頼すべきなのはもちろんのこと，実際の1つ1つの原稿の組版までプロに面倒を見てもらう必要があります．本稿における議論の対象には，現実的なコストとの兼ね合いで，この部分についてはある程度妥協をしている場合を想定しているので，この点はぜひ留意しておいてもらいたいと思います．

jlreq + expl3 という技術選定

さて，前節で延々と述べた4つの性質を満たす文書クラスを作成する上で，一番肝心だったのは私が実際にコーディングした部分ではなく，技術選定だったと思います．タイトルにもなっているので結論は明らかですが，今回そのために私が選んだ技術は jlreq と expl3 でした．最近の LaTeX 事情にそこまで詳しくない方のために，そもそもこれらのツールがどんなものなのかを簡単に紹介しつつ，それぞれの採用理由について述べていきます．

jlreq をベースに

まずは jlreq クラスです．これはその名の示す通り，W3C が発行する日本語組版処理の要件 (JLREQ) の実装を試みる，比較的新しい LaTeX の文書クラスです．名前が jlreq なので「日本語組版処理の要件に準拠していること」が特に強調されがちですが，私が重視したのはそのことよりも pLaTeX2e の標準文書クラス (jclasses) やその後のデファクトである pLaTeX2e 新ドキュメントクラス (jsclasses) と比べても後発にあたる汎用文書クラスなので，過去の教訓を生かしたさまざまな工夫が凝らされているということです⁵．具体的には，以下に挙げる2つの特徴がとても大きいです：

• クロスエンジンである（pLaTeX, upLaTeX, LuaTeX をサポートしている）
• カスタマイズ性に優れている

1点目についてですが，これはまず利便性に貢献します．あまり使用するエンジンにこだわりのない方は現在も（ともすれば無自覚に）pLaTeX を使用しているかもしれませんが，JIS 第一・第二水準の範囲に収まらない文字種が必要で upLaTeX を使用したい方や，より先進的な機能を求めて LuaLaTeX を使用したい投稿者も中にはいる可能性があり，そのような人にとって pLaTeX でしか使えないというような制約は単純に不便です．

また実はクロスエンジンにしておくことには将来的な保守性を考える上でもメリットがあります．pLaTeX は現在でも日本語組版のためには最もよく用いられている LaTeX 処理系ではありますが，その実かなり古い技術であり，かつ欧米では今も活発に開発が続く本家 LaTeX に対する「巨大になり過ぎたパッチの塊」です．これを極めて少数のメンテナの手によって辛うじて延命し続けているというのが実情です．実際のところ，最近は本格的に存続が危ぶまれているところであり，いつまでこれまでと同じように使い続けることができるかはわかりません．こうした状況を踏まえれば，いつまでも pLaTeX にしか対応していない学会クラスはかなり崖っぷちの状況にあると言えます．今のうちから upLaTeX や LuaTeX といった比較的新しい処理系にも対応しておくことで，いつの日か pLaTeX が現役を退くときに向けて，少しずつでも予め備えをしておく意味があります．

2点目のカスタマイズ性の高さはエンドユーザたる投稿者にはあまり関係のないことですが，学会文書クラスの実装者にとってはとても良い性質です．これは是非とも強調しておきたい jlreq クラスの特徴ですが，このクラスは単に1つの汎用文書クラスとして完成されているというだけではなく，このクラスをベースにして別の新しいクラスを作成するのにも大変好都合な機能を多数備えています．そういった意味で jlreq はクラスを作るためのクラス，すなわちメタクラスであると言ってもよいかもしれません．具体的にはクラスオプションや \jlreqsetup 命令を用いた key-val 形式の設定記述により基本版面設計をはじめ紙面レイアウトを決定するさまざまなパラメタを自由に変更できるほか，\New***Heading など新しい見出し命令を作るような機能も提供されています．したがって jlreq という汎用クラスを用いることにより，学会文書クラスのような “専用クラス” をかなり手軽に開発することができます．NLProceedings においても，ほとんど独自の機能実装や内部実装へのパッチ当てを行うことなく，jlreq のパラメタ指定を行うだけで学会の指定する投稿規定を満たす紙面レイアウトを実現できています．

ただし jlreq をベースとする場合にはいくつか注意すべき点もあります．まず第一に，多くの方が慣れ親しんできた昔からある文書クラスとは別物であるということは意識しておく必要があります．ごく基本的な使い方，\maketitle でタイトルを作って見出しは \section，といったあたりは古典的なクラスと何ら変わりがないようにできていますが，利用できるパッケージには若干の差があります．例えば jlreq が意図する組版の実現には専用 JFM の利用が不可欠なので，otf パッケージを読み込んでしまうと期待とは異なる出来上がりになってしまいます．そのため「\usepackage[deluxe]{otf} 相当のことがしたい場合は代わりに jlreq-deluxe パッケージを利用する」などの知識は，サポート情報として投稿者に周知するのを怠るわけにはいきません．

第二は実装時の注意点ですが，jlreq の開発はまだ続いていて内部実装が固まっているわけではないので，内部命令に依存したようなコードを書くことは避けておかないと将来的に期待通り動かなくなってしまうリスクが高いです．これは LaTeX2e カーネルの内部実装に依存する場合も同じことが言えるので，本来であれば当たり前のことですが，TeX/LaTeX 文化圏では必ずしも守られていないことも多いので敢えて言及をしておきます．これまで何度も強調しているように，学会文書クラスのような用途の場合には中長期の保守性もかなり大事な要素になってくるので，jlreq をベースにすると決めたのであれば，クラスの実装者といえどあくまで「いち jlreq ユーザ」として振る舞うことに徹するのがよいと思います．実際，今回私が開発した文書クラスにおいても，内部実装への介入が必要となる機能の要望があったものの，保守性を優先して機能の導入を見送った事例があります．

expl3 で機能を実装

expl3 というのは LaTeX の世界において歴史的に TeX 言語が担ってきた役割を引き継ぐことを目的に開発されているプログラミング言語です．TeX のマクロとして実装されているので，ほとんど TeX 言語と同じように利用することができますが，より人間にとっての可読性が高まるように意図して設計されています⁶．また，やはりクロスエンジンという強みがあり，jlreq がサポートする3つのエンジン (pLaTeX, upLaTeX, LuaTeX) をすべてサポート対象にしています．さらには直接各エンジンの TeX のプリミティブを使用する場合には，実装者自身が考慮しなければならないエンジン間の細かな違いも，expl3 のレイヤでは多くが吸収されており，使用するエンジンの違いをほとんど意識する必要がないというメリットがあります．

こうした expl3 の高い可読性とクロスエンジン性は，保守性の観点でとても大きなアドバンテージなので，NLProceedings 自体の実装には TeX 言語ではなく expl3 を採用しました．そもそも今回の文書クラス開発において，実装量は決して重いものではなかったのですが，expl3 は標準モジュール（ライブラリ）の機能が充実していることもあり，欲しい機能をさらに短いコードで実現することが可能となりました．

ただし，expl3 があれば TeX 言語を一切使用せずに済むかと言うと，残念ながら現状そうではありません．LaTeX2e 本体の実装には基本的に TeX 言語が用いられているため⁷，LaTeX2e の内部実装に依存するコードでなければ実現できない機能についてはどうしても TeX 言語を使わざるを得ないという場合もあります．NLProceedings の開発においても，実装の大半は expl3 で行いましたが，完全に TeX 言語レスというわけにはいかず，一部に TeX 言語も使用しています．

最近の TeX 情勢も追い風に

ここまで見てきたように，jlreq と expl3 は現代的な学会 LaTeX 文書クラスを作成するのにはとても都合の良いプロダクトですが（TeX の世界で古参と言えるパッケージ類と比べれば）相対的には最近になって使われるようになってきたものであり，未だに開発途上で近年にも大きな変更が加えられた部分もあります．そのため，こうした技術に依存したコードを広く多くの人に使ってもらうには，比較的新しい TeX 環境，理想的には直近数年以内の TeX Live リリース，が誰にとっても利用可能な状況であることが重要でした．

折しも，このように誰もが最新の TeX 環境を利用できる状況はここ数年で急速に達成されつつありました．その立役者は，なんと言っても Overleaf や Cloud LaTeX に代表される LaTeX のクラウドサービスです．私自身は TeX プロダクトの開発者で，多くのデバッグ作業を行ったり，使い慣れた高機能エディタでコード編集をしたいという要求があったりするため積極的に利用してはいませんが，今日では多くの初中級 LaTeX ユーザがこうしたクラウドサービスを活用するようになってきています．こうしたサービスのおかげで LaTeX ユーザであれば誰もがインストールに時間や労力を割くことなくほぼ最新の TeX Live を利用できる環境が整っています．そのため，例えば「TeX Live 2018 以降」の環境を必須要件として課したとしても，投稿者にとってどうしようもなく困惑するような事態にはならなくなっています⁸．このように，jlreq や expl3 などの新しい技術を利用した文書クラスを開発・運用していくのに必要な下地は，幸運なことに既にでき上がっていました．

文書クラスかテンプレートか

さて，このように jlreq と expl3 についてポジティブな宣伝をすると「そうであれば学会文書クラスなど必要なくて，単に jlreq で投稿規定を満たす原稿のサンプル文書（いわゆるテンプレート）を用意すればいいのでは？」と思われた方もいるかもしれません．確かに jlreq は汎用文書クラスなので，そのような使い方は個人のレベルでは自然です．しかし，先に述べた安心性の観点から，私は学会の提供物としてそれでは不十分だと感じています．

投稿規定の実装をテンプレートという形で実現する場合，そのプリアンブルには

• 規定を満たすためには決していじってはいけない設定
• 著者の好みや裁量によって変更しても構わない設定

が混在することになります．もちろん投稿規定を隅から隅まで読み込み，またプリアンブルに書かれた内容についてどの部分がどんな役割を果たしているのかをきちんと把握すれば，意図せずして投稿規定違反の原稿を作ってしまうことはないはずですが，時間のない方も含めてすべての投稿者にそこまで求めるのは酷なことでしょう．またコメント等で「ここは変更してはいけない」などと逐一書くこともできますが，煩雑な見た目になることは容易に想像できます．

学会単位で用いるような LaTeX 資源を構築するにあたり，私が単なるテンプレートではなく文書クラスでの実現にこだわった理由はここにあります．投稿規定の実装内容は，プリアンブルではなく文書クラスの中にすべて押し込むことで，そのユーザたる投稿者にとっての「テンプレートのどの部分は絶対に手を加えてはいけないのか」という迷いを軽減することができます．要するに投稿規定実装のカプセル化です．逆に，単に便利だからなどの理由で推奨しているだけの，著者の裁量で自由に変更しても構わない設定部分についてはテンプレートのプリアンブルに説明付きで残しておくことで「テンプレートは編集しても構わないけれど，文書クラスは変更不可」という明確な線引きを行うことができます．

もちろん，そうはいってもプリアンブルで（例えば TeX 言語を直接使用することによって）意図的に投稿規定違反になるような変更を加えることは可能であり，そういった行為まで完全に防ぐのは困難ですが，投稿者が投稿をしようと意図する以上は，誰も好き好んで規定違反をしようとはしないと仮定しても問題はないでしょう．文書クラスの役割は，あくまで「意図せず」不運にも投稿規定違反になってしまうことを極力防ぐことにあるはずです．

結局 NLProceedings は何をしているのか

あまりに長々と設計思想を語ってきましたが，結局 NLProceedings という文書クラスが，その実装において行っていることは何なのでしょうか？ これについては，本当に簡単なことしかしていません．

まず，当然ながら投稿規定を満たすような基本版面設計その他の指定を行っています．そのため，究極的には \documentclass{nlproceedings} と文書ファイルの冒頭で宣言するだけで投稿規定を完全に満たす原稿が作成できます．それから，これも安心性に関わることですが，クラスオプションの指定が悪くて規定に反する原稿ができてしまうことがないように，投稿規定と矛盾する jlreq のクラスオプションは無効化しています．一方で，規定とは無関係なクラスオプションはそのまま jlreq に渡されるようになっています．

主な実装内容はと言えば上記がほとんどすべてです．細かいところでは，処理エンジンが (u)pLaTeX である場合には，私が今年『日本語 LaTeX の新常識 2021』でも紹介した plautopatch パッケージの読み込みを行うことで，(u)pLaTeX と非互換なパッケージがパッチなしに読み込まれることを防いでいます⁹．また，NLProceedings は日本語用の文書クラスで基本的に日本語組版を行う前提で設計されたものですが，その点は割り切って英語原稿に利用する場合のために，「参考文献」等のデフォルト見出し文字列を英語化するための english オプションも用意しています．

今後の展望

NLProceedings は前回年次大会から実用されており，実際に致命的な問題もなく予稿集も出来上がったようなので，jlreq + expl3 で作った文書クラスでそれなりの規模の論文集を作成できることは実証されました．もちろん，現状の文書クラスが非の打ち所がない完璧なものであるというわけではないですが，すでに実用されているという事実も受けてこれまでにバージョン1.0のタグが打たれています．

最近は私の時間的リソースもかなり限られてきてしまっているため，どこまで実現できるかはわかりませんが，個人的にバグ対応や投稿規定変更への追随以外にやりたいことが少なくとも2つあります．いずれも文書メタデータに関わることです．1つは複雑な所属関係だったり，多数の共著者がいる場合のタイトル部の調整です．jlreq に限らず典型的な LaTeX の文書クラスはかなり単純な \author, \thanks 命令しか提供していませんが，分野によっては1人の著者が2つも3つもの組織に所属していたり，ナイーブに並べると紙面領域を取りすぎるほどの共著者がいる場合も珍しくないでしょう．現状では苦肉の策として，著者側でさまざまな工夫を凝らして無理やり狭いスペースにすべての著者情報を詰め込むということが行われていますが，できれば文書クラスの機能としてこうしたケースにも対応できるしくみを導入したいと思っています．

もう1つは文書のメタデータを PDF に適切に埋め込む機能の実装です．最近，本家の LaTeX2e カーネルの開発が活発なのも，実はタグ付き PDF というさまざまなメタデータが PDF 本文中に埋め込まれたものを出力したいというのが根源的なモチベーションとして存在します．

最近本家 LaTeX の開発が活発で，既に “枯れている” はずの LaTeX2e に多くの破壊的変更が加えられているのは，究極的にはその出力を「タグ付き PDF」に対応させるためである．これはつまり LaTeX ソースに（理想的には）ある構造情報をある程度出力先の PDF にも反映しようという試みである．

— ワトソン (@wtsnjp) August 9, 2021

文書全体のメタデータというのは，こうした付加情報の中でも最も基本的なものですが，将来的に論文データを言語資源（コーパス）として再利用するためにも，通常通りの手順で LaTeX 文書を処理するだけで，出力 PDF に適切な文書プロパティが反映される方が理想的だと考えています．

まとめ

文書クラスを自前で用意するのは歴史的には大変なことでしたが，jlreq や expl3 などの優れた汎用ツールの登場によって，特定用途の専用文書クラスの開発をかなり手軽に行えるようになってきました．こうした手段で専用文書クラスを用意することにより

• 学会運営者にとっては……
  • 統一的な見た目・基準の投稿規定の徹底
  • 中長期に渡り，小さなコストで維持できる保守性
• 投稿者にとっては……
  • 投稿規定を満たす原稿を，使い慣れたツールで簡単に作成できる利便性
  • 「うっかり」で規定違反になってしまうことがないという安心性

などのメリットを享受することができます．また，こうした目的のために文書クラスを作成する場合，その開発者は jlreq のカスタマイズ用機能をフル活用しつつ

• 投稿規定の実装にあたる部分を文書クラスにカプセル化すること
• jlreq の内部実装には依存しないこと
• 独自に必要な機能は expl3 で可読性高く実装すること

に留意することが大切です．

残念ながら，pLaTeX がいつまでこれまでと同じように使い続けられるかは不透明な状況になってきています．そのリスクヘッジのためにも，なるべく早い段階で多くの LaTeX エンジンをサポートする文書クラスに移行していくことは，LaTeX を利用するどこの学会にとっても重要です．さまざまな投稿規定を満たす文書クラスの作成を手軽にする汎用ツールと，誰もが新しい TeX Live 環境にアクセスできる状況になりつつある2020年代は，その移行のために必要な下地がすべて整った時代です．これからは jlreq + expl3 を活用した新しい学会文書クラスが次々と出てきて欲しいと思っています．

最後になりましたが，それぞれの利用ケースにあった専用文書クラスを作成することはもちろん大切で必要不可欠なことですが，そうした営為は jlreq や expl3 などの汎用ツールの存在によって支えられています．エンドユーザからは少し見えにくいながらも，汎用ツールの開発者はさまざまなニーズに答えるため，多くの時間と労力を注いで多様な機能を実装・サポートし，複雑で奇っ怪なコーナーケースへの対応という果てしない作業にも従事してくださっています．最大の賛辞は，彼らにこそ贈られるべきでしょう．