腐らない資産を設計する — 1995 年の TeX が 2026 年もコンパイルできる条件

1995 年に書かれた TeX のソースファイルが、2026 年のいまも lualatex-ja を通すと PDF になります。技術的には、何でもないことに見えるかもしれません。けれども、多くの人にとって 30 年前の知的資産は既に失われている という事実と並べると、妙に重い実証データになります。

世の中の知的労働者の大半は、自分の知的資産を失い続けています。5 年前の Word 文書は、レイアウトが崩れて開けない。10 年前の Notion ノートには、アクセスできなくなる。15 年前のクラウドサービスは消え、資料も一緒に消える。20 年前の MO ディスクは、読む装置がない。そういう時間の尺度です。30 年前の論文を 同じ 1 行のコマンド で作り直せるという事実は、この対比の中で初めて意味を持ちます。

本稿では、知的資産が時間を越えて使い続けられるための設計原理を整理します。中心の主張は単純です。腐らない資産を作るには、書く時に「30 年後にも開けるか」を判断基準に組み込めばよい。この基準は UNIX 哲学から来たもので、新しい思想ではありません。けれども、それを 30 年続けて実践することは、いまの知的労働ではむしろ珍しい選択になっています。

この設計は、本サイトの基礎記事 決定論的にではなく、相対的に で述べた態度を、時間の軸に広げたものでもあります1。特定の編集ツール (= 媒介物) を「正解」として固定すると、資産はそのツールの運命に縛られます。逆に、開放形式という 媒介の境界 のほうを固定し、レンダリングの装置のほうを相対的に差し替えられるようにしておく。TeX → LaTeX → LuaLaTeX、さらに将来の何か。そうすれば内容は、装置の世代交代を越えて流れていきます。「決定論的にではなく、相対的に」を 30 年続けると、副産物として耐久性が生まれる。そういう構造です。

なぜ資産は腐るのか

知的資産が失われる道筋は、いくつかの型に分けられます。

プロプライエタリ形式の世代差: Word .doc (1990 年代) は、.docx で互換性が一部失われました。AppleWorks の文書は、保存形式が引き継がれないまま消えました。一太郎、Lotus 1-2-3、QuarkXPress。どれも時代の主流から外れると、その形式で書かれた資産は 読めるが編集できない 状態で固まります。

SaaS のプラットフォーム依存: Notion / Evernote / Google Docs / Dropbox Paper といったクラウド型エディタでは、利用規約の変更、料金体系の改訂、サービス終了、アカウント停止のどれか一つが起きた瞬間に、資産へのアクセスが断たれます。エクスポート機能があっても、多くは劣化を伴い、構造が失われます。

フォントの絶版: 商用フォントは、ライセンスの継続を求めます。特殊なフォントは、作った会社が廃業すると二度と手に入りません。フォントを埋め込んでいない PDF は表示が変わり、版面が崩れます。

編集機の世代交代: 32-bit から 64-bit へ。PowerPC から Intel、そして Apple Silicon へ。Windows 7 から 11 へ。移り変わりのたびに、「ある時点の編集環境を再現する」ことが難しくなっていきます。エミュレータは部分的な解決にしかなりません。

メディアの物理寿命: フロッピー、MO、CD-R、DVD-R、外付け HDD。どれも 5–20 年ほどで、読み取り装置を含めて使えなくなります。クラウドストレージは、一見この問題を解決します。けれども実際には、上の SaaS 依存の問題に置き換わるだけです。

認証の継続コスト: Adobe Creative Cloud、Microsoft 365、各種の商用ライセンスは、月額・年額の支払いを止めた時点で編集する権利が失われます。それまでに作った資産は手元にあっても、編集する装置がなくなるのです。

これらが連鎖した結果、個人の知的労働の蓄積は数年から十数年で実質的に失われる。これが、いまの標準的な道筋です。

腐らない資産の構造

逆に問えば、何が時間を貫くか が見えてきます。設計原理として整理すると、6 つになります。

  1. プレーンテキストを最優先する ── UTF-8 のテキストは、Unix 系から Windows まで、どのエディタでも開けます。grep で検索でき、diff で版どうしを比べられ、Git で版を管理できます。50 年以上現役で、今後 30 年も続くという予測の信頼区間がいちばん狭い形式です
  2. 開放形式を選ぶ ── LaTeX (Knuth 1978–3、Lamport 19864)、Markdown (Gruber 20045)、JSON、PNG、PDF/A (ISO 190056)。仕様が公開され、実装が複数ある形式は、特定のベンダの運命に左右されません
  3. ソースと成果物を分離する ── テキストのソースを原本とし、PDF / HTML / EPUB などは作り直せる派生物として扱います。原本がテキストである限り、レンダリングの装置が変わっても、作り直せば済みます
  4. Git で分散保存する ── 分散版数管理は、一つのプラットフォームに依存しません。GitHub / GitLab / 自前サーバ / ローカルディスクのどこに置いても、git clone で完全な履歴を別の場所に複製できます
  5. XDG 標準を尊重する ── XDG Base Directory Specification7 は、設定ファイルの置き場所を $XDG_CONFIG_HOME、データを $XDG_DATA_HOME というように、OS をまたいで標準化します。マシンを乗り換えるときの移行の手間が、大きく減ります
  6. 依存関係を最小化する ── 自作のスクリプトは、POSIX シェル (50 年安定8) と、grep / awk / sed / find といった UNIX の標準ツールで組みます。これらは 1970 年代から本質的に変わっていません

これらは新しい設計原理ではありません。UNIX 哲学が 1970 年代に既に答えを提供していた 設計です2。新しいのは状況のほうです。SaaS とプロプライエタリ形式が主流になったいま、これらの古典的な判断を貫くには、意識的な選択 が必要になりました。

オーケストレーター視点 ── 書かないことが耐久性を生む

腐らない資産を作るための設計判断のうち、いちばん見落とされやすいのは「自分で書かない」という選択です。

自前のコード、自前のフォーマット、自前のツールを作れば、それを 30 年間自分で保守する責任 を負います。これはほぼ不可能です。書き手は引退します。興味が変わり、時間がなくなり、技能が古びます。そして資産は腐ります。

Eric Raymond の再利用の原則 (1999)9 が指摘するように、偉大な書き手は「書き直す (そして再利用する) べきもの」を知っています。腐らない資産の設計では、この命題は時間軸に拡張されます。自分が保守し続けられるものだけを書く。それ以外は、他者が長く保守してきた基盤に乗る。LaTeX、POSIX、Git、PDF/A、JSON。これらはどれも、30 年級の保守実績を持つ「他人の優秀なコード」です。

本サイトの既掲記事 偉大なプログラマは優秀なプログラマのコードを利用する で論じた再利用の原則は、技術的な効率の話に見えます。けれども、時間軸で読み直すと耐久性の問題でもある ことが見えてきます。書かないという選択は、書いたものを保守する責任から自分を解き放つ選択でもあるのです。

30 年の実証データ

本稿の議論は、書き手自身の実践で 30 年にわたって確かめられています。1995 年の学部論文、1999 年の修士論文、その後の研究ノート・学会発表資料・原稿の大部分が、テキストと開放形式で残っています。いまもコンパイルも編集も検索もできる状態です。

大事なのは、特別な保存の努力をしたわけではない、という点です。当時から判断していたのは、三つだけです。

  • テキストで書く (TeX / プレーン UTF-8)
  • 開放形式を選ぶ (LaTeX / 後年は Markdown も)
  • バックアップを分散させる (ローカル + 複数の保存先、後年は Git)

30 年後もコンパイルできるという性質は、その副産物として手に入りました。長い期間にわたって意識的な選択を続けられたから、ではありません。短期で楽だったから腐りやすい選択を回避した、と言うほうが実態に近いです。プロプライエタリなツールは、流行が変わるたびに学び直しを求めます。エクスポート機能で資産を運び出す手間も生じます。テキストと開放形式は、その学ぶコストと運ぶコストを、30 年単位で消してくれます。長期の耐久性は、短期の楽さの結果として副次的に立ち上がる のです。

反論への応答

「専門ツールの方が便利では?」── 短期では、その通りです。Photoshop / Illustrator / Final Cut Pro は、その時点で最高の編集体験を与えてくれます。ただし長い目で見れば、その快適さと引き換えに囲い込みを受け入れていることになります。判断は、「30 年使う資産」と「3 年使う資産」を分けて扱う という形で実用に落とせます。前者ではプロプライエタリなツールを避け、後者では積極的に使います。

「PDF だけ残せば良いのでは?」── 読むためには十分ですが、編集するためには足りません。PDF は作り直せる派生物で、ソースではありません。ソースを失うと、引用の追加、章の入れ替え、誤字の修正、別の言語への翻訳、どれもできなくなります。資産が「読める状態」と「書き継げる状態」は、別々の保全の要件です。

「クラウドの方が安全では?」── 物理的な信頼性は確かに上がります。けれども、それと「自分の資産であり続けること」は別の問題です。クラウド事業者には、規約変更、値上げ、サービス終了、アカウント凍結のどれもが起こりえます。だから、手元のディスクに完全な複製がある状態 が、長期の耐久性の前提になります。Git の分散モデルが、そのまま当てはまります。どこか 1 箇所が失われても、全体は失われない設計です。


ここからは、30 年かけて確かめた資産設計を、2026 年の文脈で読み直してみます。

本サイトの既掲記事と照らし合わせると、「腐らない資産」という命題が、いくつもの方向から支えられていることが見えてきます。

  • 決定論的にではなく、相対的に で宣言した態度を、時間軸に広げたものがこれです。媒介物 (編集ツール) を固定するのではなく、媒介の境界 (開放形式) を固定して、道具のほうを相対的に差し替える。30 年後の自分は別人だと考えれば、資産を残すこと自体が 未来の他者に向けた妥当性確認の準備 にもなります。その他者が「そもそも何を記録したかったのか」をさかのぼって言葉にできる余地を、開放形式で確保しておくのです
  • 記録を標準化する で論じた 段階間の取り決め は、自分自身に対しても働きます。いまの自分が残す資産は、未来の他者 (= 30 年後の自分) とのあいだで、相互に運用できる取り決めを満たしている必要があります。標準形式を尊重することは、時間をまたいだ検証 (Verification) を成り立たせる条件でもあります。過去の資産と現在の装置が一致しているかを、差異として検出する検証です
  • 書くことは考えることか — 思考と道具の境界 と 思考と作業を分離する で扱った 思考と道具の関係 を時間軸に広げると、こうなります。「思考の延長としての媒介物」は、長く安定して使える形式でなければならない
  • 世界は分けてもわからない の動的平衡論は、生体の代謝が 流れの中で構造を保つ ことを示しました。知的資産も同じように、形式の流れの中で内容を保つ 性質を持っています。テキストとして残しておけば、レンダリングの装置が変わっても、内容は流れを通り抜けていきます

そして、「囲い込みに加担しない」という含意があります。資産が 自分の手元 にあり続けるか、それともプラットフォームの 借家 にあり続けるか。これは媒介性の問題そのものです。媒介物が他者の規約変更・料金改訂・サービス終了で動けば、自分の知的資産へのアクセスも他者の都合で動いてしまいます。プラットフォーム税を 30 年払い続けるか。最初に開放形式を選んで、以後は払わずに済ませるか。この判断は、媒介を自分の手の内に置き続けるための設計です。知的労働で「囲い込みに加担しない」ことの、いちばん具体的な実践です。

腐らない資産を設計するとは、結局、30 年後の自分 (あるいは未知の他者) に向けて、開放形式で手紙を書く ことです。差出人は今日の自分、宛先は 2056 年の誰か。あいだに立つ郵便局はプラットフォームではありません。テキストと UNIX 哲学が 1970 年代から営んできた、まだ閉鎖していない長期サービスです。

参考文献


  1. 媒介性 / 差延 / 検証と妥当性確認 (V&V) の非対称性 の操作的な定義と理論的な扱いについては、本サイトの基礎記事 決定論的にではなく、相対的に の脚注、および著者の Zenodo プレプリント・シリーズ (レター版 DOI: 10.5281/zenodo.20096462) を参照。 ↩

  2. McIlroy, M. D., E. N. Pinson, and B. A. Tague. “UNIX Time-Sharing System: Foreword.” The Bell System Technical Journal, vol. 57, no. 6, July–August 1978, pp. 1899–1904. ↩

  3. Knuth, Donald E. The TEXbook. Addison-Wesley, 1984. TeX の設計とその後方互換性を守る姿勢について著者本人が論じた基本書。 ↩

  4. Lamport, Leslie. LATEX: A Document Preparation System. Addison-Wesley, 1986. ↩

  5. Gruber, John. “Markdown.” Daring Fireball, 2004. https://daringfireball.net/projects/markdown/ ↩

  6. ISO 19005-1:2005 Document management — Electronic document file format for long-term preservation — Part 1: Use of PDF 1.4 (PDF/A-1). 国際標準化機構, 2005. ↩

  7. freedesktop.org. “XDG Base Directory Specification.” https://specifications.freedesktop.org/basedir-spec/ ── 設定ファイル・キャッシュ・データの置き場所を環境変数で標準化する仕様。 ↩

  8. ISO/IEC 9945:2009 (POSIX.1-2008) Information technology — Portable Operating System Interface (POSIX®) Base Specifications. ISO, 2009 (改訂は継続中)。1988 年の IEEE 1003.1 を起点とする標準。 ↩

  9. Raymond, Eric S. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. O’Reilly, 1999, Lesson 5. ↩