デジタルの紙を超えて

Share

紙の資料がPDFになった。たったそれだけのことが、実際にはどれほど革命的だったか。そしてなぜ、それだけでは足りないのか。

紙からPDFへ

少し前まで、「資料」といえば紙のことだった。コピー機を通すたびに劣化する文字。数世代のコピーを経て原形をとどめないページ。手書きの注釈が入り混じった印刷物。回覧のために物理的に持ち運ばなければならない書類の束。それが「資料を配布する」ということの実態だった。

コロナ禍を契機にオンライン化が一気に進み、紙の資料は急速にPDFへと置き換わった。コミュニケーションツールが普及し、ファイル共有が当たり前になった。

この変化の大きさを、過小評価すべきではないと心から思う。

ニール・アームストロング船長の有名な言葉が頭に浮かぶ。

That's one small step for a man, one giant leap for mankind.
一人の人間にとっては小さな一歩だが、人類にとっては偉大な飛躍である。

紙からPDFへ。ファイルを送るだけで同じ文書が相手の画面に表示される。文字を検索できる。拡大しても潰れない。地球の裏側にいる人にも一瞬で届けられる。紙の時代には夢物語だった。これは確実に「偉大な飛躍」だった。

しかしPDFは「デジタルの紙」である

ここで立ち止まって考えたい。PDFとは結局のところ何なのか。

PDF(Portable Document Format)は1993年にAdobe Systemsが開発し、2008年にISO 32000として国際標準化された文書フォーマットだ。設計思想は明確で、「どの環境で開いても同じ見た目で表示されること」を保証する。フォント、余白、行間、図の配置。すべてが固定され、再現される。

ここが核心だ。PDFが保存しているのは、文書の「見た目」なのだ。

PDFの内部は、座標を指定して描画命令を並べた構造になっている。「この座標にこの大きさでこの文字を描け」、「ここに画像を配置しろ」という指示の集合体であって、「ここは見出しである」、「これは本文の段落である」、「この文は前の段落に続く」といった意味的な構造は、基本的に保持していない。

「改行」すらPDFの内部には存在しない。視覚的な改行は、次の描画命令のY座標が変わることで表現されているにすぎない。

つまりPDFは、デジタルの力で完全に再現された「紙」なのだ。紙と同じように、レイアウトは完璧に保存される。紙と同じように、中身を別の用途に再構成することは容易ではない。

PDFからテキストをコピーしたとき、文字の順番がばらばらになったり、改行位置がおかしくなったり、表が崩壊したりした経験のある人は少なくないだろう。これはPDFの不具合ではなく、そもそもPDFが文章の論理構造を記録するようには設計されていないことの帰結だ。同じPDFでもビューアによって抽出結果が異なるのは、ビューアが座標情報から文の順序や行の区切りを「推測」しているためにすぎない。

なお、PDFの仕様にはTagged PDFと呼ばれる構造情報を埋め込む仕組みも存在する。見出しや段落などの論理構造をタグとして付与するものだ。しかし現実には、この機能が適切に実装されているPDFはごく少数であり、ほとんどのPDFはやはり「見た目の記録」にとどまっている。

コンテンツと見た目の分離という未解決問題

PDFの限界を目にすると、自然に一つの問いにたどり着く。文書の「内容」と「見た目」を分離して扱えないのか、と。

「コンテンツとプレゼンテーションの分離」は、情報技術の世界で繰り返し挑戦され、そして完全には達成されていない課題だ。多くの人が取り組み、苦心し、それでもなお決定的な解決には至っていない。

HTMLとCSSは、Webの世界でこの分離を試みた最も広く知られた例だろう。HTMLが文書の構造と意味を記述し、CSSが見た目を制御する。理念としては美しい。しかし実際のWeb開発の現場では、構造と見た目は複雑に依存し合い、きれいな分離が保たれることは稀だ。

LaTeXは学術分野で独自のアプローチを取った。著者は \section{} や \begin{theorem} といった論理的な構造だけを記述し、組版の細部はエンジンに委ねる。学術論文の組版においては強力だが、記法の学習コストの高さもあって、一般に広く普及するには至っていない。

Markdownは軽量さと読みやすさを武器にした。構造を最低限の記法で表現でき、書く側の負担は小さい。ただし表現力には限界があり、複雑なレイアウトや細かな視覚的制御には向かない。

どれも一長一短であり、「これさえ使えば万事解決」というフォーマットは存在しない。

そして、この問題が技術的に難しいのには理由がある。そもそも「コンテンツ」と「見た目」の境界そのものが曖昧なのだ。文字の太字強調は「意味」だろうか、「装飾」だろうか。箇条書きという形式は「論理構造」だろうか、「表示方法」だろうか。段落の間隔は「構造の区切り」だろうか、「視覚的余白」だろうか。こうした問いに一意の答えはない。見た目とコンテンツの分離は、言うほど簡単ではないのだ。

情報は散らばり、集めても使えない

フォーマットの問題と並行して、情報そのものの管理にも深刻な課題がある。

組織ではミーティングが日常的に開かれ、そこで共有された情報は議事録に残ることもあれば、そのまま流れていくこともある。チャットツールには膨大なやり取りが蓄積され、その中に重要な決定や貴重な知見が埋もれている。ファイルサーバには無数のフォルダが並び、同名の文書の異なるバージョンが散在する。

「すべてを一カ所に集約すればいい」という提案はよく聞く。しかし、それだけでは解決にならない。情報が一カ所に集まっても、構造化されていなければ、巨大な文書の山の前で途方に暮れるだけだ。

これは身近な場面で容易に想像できる。百科事典のような教科書を頭から通読しても、体系的な理解は得られない。あらゆる情報が一冊に収まっていることと、その情報を実際に理解し活用できることは、まったく別の問題だ。

情報には、適切な構造と、必要に応じて異なる角度から参照できる柔軟性が求められる。同じ内容であっても、全体を俯瞰したい場面と特定の詳細に集中したい場面がある。そのどちらにも対応するためには、情報が固定的な「見た目」に閉じ込められていてはならない。

発表と参考資料のジレンマ

ここで正直に一つの矛盾を認めたい。

情報は柔軟なデータとして保存されるべきだと主張しておきながら、自分自身が発表する側に回ったとき、実際にはどうしているか。スライドにはほとんど文字を載せない。長い文章を並べても、人には伝わらないからだ。図や図解を中心に構成し、説明は口頭で補う。発表原稿は別途作り込むが、聴衆に配布するわけではない。

そして、そうやって作った発表資料を後から「参考資料」として渡されたとしたら。はっきり言って、使い物にならない。図だけでは文脈がわからず、発表時の口頭説明なしには意味をなさないからだ。

これは個人の力量不足の問題ではなく、構造的なジレンマだ。

良い発表資料と良い参考資料は、求められる性質が根本的に異なる。 発表資料は、限られた時間で聴衆の注意を引き、要点を視覚的に印象づけることが目的だ。文字は最小限に抑え、図を大きく、テンポが重視される。一方、参考資料は、網羅性と正確性が要求される。文脈を自ら補い、後日読み返しても単体で意味をなす必要がある。

同じ知識を伝えるのに、最適な「形」が文脈によって全く異なる。ここにも、コンテンツとプレゼンテーションの問題が顔をのぞかせる。

もし情報が見た目から独立したデータとして保存されていれば、同じ内容を発表用のスライドとしても、後から参照する詳細資料としても、自在に出力できるはずだ。内容は一つ。見た目は用途に応じて変える。それが理想だ。しかし現実には、そのような仕組みはまだ広く実現されていない。

データとしての文書へ

率直な願望を言えば、見た目はどうでもいい。元のデータがほしい。

すべての文書をMarkdownで記述しろとは言わない。しかし、少なくともソースファイルにアクセスできるだけで状況は大きく変わる。PDFしか手に入らない現状では、内容を再利用するためにOCRや手作業による再入力が必要になることも珍しくない。元の構造化されたデータがあれば、検索、翻訳、要約、引用、形式変換のいずれも格段に容易になる。

見た目は必要なときに必要な形で生成すればいい。大切なのは、内容のデータが構造を保ったまま保存されていることだ。

次の一歩を

PDFは偉大な発明だった。紙を電子化し、どこでも誰でも同じ文書を同じ形で読めるようにした。その功績は揺るがない。

しかしPDFは到達点ではなく、通過点だ。

月面に降り立ったアームストロング船長の一歩は、宇宙開発の終わりではなく始まりだった。紙からPDFへの移行がデジタル文書における偉大な一歩だったとすれば、次の一歩は「見た目」から「コンテンツ」への転換ではないだろうか。

見た目に閉じ込められた情報を、構造を持ったデータとして解放すること。固定されたレイアウトの再現から、用途に応じた柔軟な表示への移行。それが次に踏み出すべき一歩だと思う。

その一歩を、切に待ち望んでいる。

Read more

Dependabotの対応が面倒なのでRenovateを導入する

Dependabotくんはある程度の依存関係の更新を通知してくれるが、山のようにprojectを抱えているとなんとも痒いところに手が届かない。 ということで、Renovateを使ってみる。 Build software better, togetherGitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.GitHub ここからGitHub Appを入れる。 あとは、指示に従ってポチポチするだけで、超かんたんだった。 感想 自動化最高。

By Sakashita Yasunobu

nodejsのバグを見つけたのでPRを投げてみた

概要 要するに、node --testで特定のバイナリを標準出力に書くと、テストランナーが固まったり、異常終了したりするバグです。 バグ自体は既知のものだったようで、修正がされていました。 test_runner: infinite loop in FileTest#drainRawBuffer when child stdout contains FF 0F followed by large size bytes · Issue #62693 · nodejs/nodeVersion v25.9.0 (also reproduced on v24.14.1 LTS, v22.21.0 LTS, v23.4.0) Platform Darwin 25.

By Sakashita Yasunobu
青空文庫のParser

青空文庫のParser

青空文庫のParserを作ってます。 GitHub - P4suta/aozora: Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks.Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks. - P4suta/aozoraGitHubP4suta Rustで作ってますが、配布物はcargoのほかにnpm/pypiでも入手できます Documentation * Playground — try it in

By Sakashita Yasunobu