こんにちは。Legalscape Co-founder & CTOの城戸（きど）です。この記事はLegalscape アドベントカレンダー 2021の12/23のエントリです。

私たちが提供するリーガルリサーチツール「Legalscape」では、法令やパブコメ、ガイドライン、そして書籍などたくさんの種類の文献を扱っています。その上で逃れられないのが、PDFというポピュラーながら困りものなファイル形式の扱いです。今回は、なぜ私たちが、PDFという難敵とがっぷり四つに組んで戦うことに決めたのか、そしてそれはどんな戦いなのかの一端を伝えられたらと思います。

リーガルリサーチツールとPDFの切っても切れない関係

私たちが扱う文献は大きく分けて2つの出自を持っています。インターネットから収集したものと、出版社等コンテンツホルダーから直接提供いただいたものです。

前者にはパブコメやガイドラインなど、官公庁がそれぞれのウェブサイト上で公開している資料が含まれます。こういった資料は、ご覧になった経験がある方も多いと思いますが、多くがPDFで公開されています。これらはPDFの形で入手し、活用せざるをえませんが、実は私たちにとってPDFはあまり嬉しい形式とも言えないというのが実情です。次節以降で詳しく語りますが、PDFは再利用性の低い、いわば最終成果物に過ぎないからです。ITエンジニアの方であれば、「ビルドしたバイナリだけもらっても困るけど、ソースコードがあったら嬉しい」という比喩で伝わるでしょうか。

話を戻して、では後者の、出版社からのデータはどうでしょうか。起稿から出版まで、全てを扱っている出版社から直接データをもらえるのであれば、PDFではなく、より使い勝手のいい、機械可読性の高い（コンピュータで処理しやすい）形式で手に入るのでしょうか。

残念ながらこれは真ではありません。私はこの理由を知ったとき大変驚きました。なぜなら、そもそも出版社は自社の出版物の電子データをPDF形式でしか持っていないことが少なくないからです（個人の経験に基づく見解です。「うちは違うよ！」という指摘は甘んじて受けます）。なぜこんなことが起きるのでしょうか？　答えはシンプルです。そのような出版物は組版を出版社が自社ではやっておらず、印刷会社が担っているからです（個人の経験に基づく、以下略）。

どうやらPDFからは逃れられそうにないということがわかってきました。ではそもそもPDFとはどういったファイル形式なのでしょうか。

PDFはなぜ私たちにとって厄介なのか

PDFはAdobeが開発した電子文書ファイル形式です。そして、国際標準であるISO 32000には「PDFの目的は利用者が電子文書を簡単かつ確実に、それらが作られた環境や、それらが閲覧・印刷される環境に依存せず、交換・閲覧できるようにすることである」と規定されています（鉤括弧内は拙訳）。すなわち、PDFは閲覧するためのファイル形式なのです。

このおかげで、出版物のような高い品質の文書を、あらゆる環境で、作成者が意図した通りに閲覧することができます。ですから、たとえば利用者にPDF文書を閲覧させるだけのWebサービスであれば、作るのはとても容易だと言えるでしょう。

ですが、私たちのように書籍などの文献の内容を自然言語処理などの技術を用いて解析し、より高い価値を提供できるようにしたいと考えている人にとっては、話が違います。PDFはあらゆる環境で同じ見た目を再現するという目的に特化しているために、再利用が困難であるからです。

PDFには「テキストデータ」は含まれていない

PDF文書の内容を解析しようとするとき、まず初めに取り組まないといけないのがテキストの抽出です。一見簡単そうなタスクに思えますが、実は一筋縄ではいきません。

先に、PDFは閲覧するためのファイル形式だと述べました。つまり、テキストデータを格納するためのファイル形式ではありません。ではどんな内部構造になっているのでしょうか。

正確に説明すると非常に長くなるため、イメージだけ伝わるような説明をしますと、PDFは、機械語のように「描画位置を (x, y) に移動せよ」「フォントサイズを S に変更せよ」「ABC という文字を描画せよ」というような命令が羅列されたデータになっており、その命令を上から順に実行していくことでページを描画する仕組みになっています。そして「ABC という文字を描画せよ」という例を出しましたが、「F というフォントの 12345 番のグリフを描画せよ」と言った方が実態に近いです。グリフというのは大雑把にいうと一字一字の図形的なかたちのことです。要するに、閲覧する、すなわち画面や紙に表示するためのデータですから、その内容がどうであるということは関係なく、どの図形を描画すればいいか、という指示だけが入っているということです。

このような構造のPDF文書からテキスト抽出をするには、出現するグリフの番号が実際にどの文字なのかの対応づけをもとに図形から文字に変換してあげる必要があります。この対応づけが、UnicodeだとかASCIIだとかよくある既知の文字コードと一致していれば良いのですが、実際にはCIDやGIDと呼ばれるフォント独自の番号システムになっています。

ではPDF文書からのテキスト抽出は全く不可能か？　というとそういうわけでもありません。PDFにはCMapというCID/GIDとUnicodeの対応表があり、これに照らしわせながら読めば実際のテキストを手に入れることができます。問題はこのCMapのデータが正しく指定されていないPDF文書です。

私たちが実際に出版社から受領した書籍のPDF文書の中にも、一定の割合でCMapのデータが適切に含まれないものが混ざっていました。当然テキスト抽出するとまともなテキストは得られません。それどころか（同じ原理で、当たり前ですが）PDFビューアーで開いた上で文章をコピー＆ペーストしても壊れたデータしか手に入りません。PDF文書を印刷会社が作成したとき使われたソフトウェアの特性なのか、あるいはわざとそのようなオプションを指定したのか、……どうしてこのようなPDF文書が生まれたのかは、謎です。

PDF探求の旅は続く

こういった複雑な内部構造を持つPDFから、どうにかテキストらしきものを抽出できたとしても、まだ苦労は終わりません。グリフのIDから文字に変換できたとはいえ、手に入る情報は「どの位置にどのテキストが描画されたか」というデータだけです。この状態で、得られたテキストはどこからどこまでが「行」なのでしょうか？　どこからどこまでが「段落」なのでしょうか？　いずれも座標やテキストのデータだけでは明らかではありません。何らかの方法で推定する必要があります。「段組」はどう扱えばいいのでしょうか？　「本文」と、「本文」以外の「ノンブル」（ページ番号のことです）「柱」（ページの上端や下端に章タイトルなどが書かれている箇所です）はどう区別すればいいでしょう？　さらに、テキスト以外にも「図」や「表」も重要な要素です。PDF解析の道のりは長く険しいのです。

なおLegalscapeでは、すでに上記のようなPDF解析の一連の流れを可能にする、自動と人手を組み合わせたソフトウェアを開発し、順次法律文献の解析を進めています。これにより、12/1の八木田のエントリのように、単なるPDFやPDFを画像化したもののビューアーを超え、他製品では実現できない様々な機能を実現しています。

終わりに

この記事では、Legalscapeを裏から支えるPDF解析技術の事情について触れました。私たちのチームに加わって、自然言語処理などでそのデータを活用するために避けては通れないこの苦労を分かち合っていただき、法情報の本質的な利活用を可能にするべく、一緒に戦っていただける方を募集しています。採用情報をご覧いただけたら嬉しいです。