golden-luckyの日記

ツイッターより長くなるやつ

10年前の小型サーバー機にGPUを外付けした記録

2018年8月に、HP ProLiant Thin Micro TM200という小型サーバー機を中古で買った（こういうやつ）。CPUとしてサーバー用のXeonをいちおう搭載しているが、D-1518というかなり低スペックなやつで、4コア8スレッドの2.2GHzしか出ない。とはいえ消費電力が低く（35W）、メモリもDDR4で32GBはあるので、Debian/GNU Linuxを常時稼働させて開発に使っているぶんには現在でも何ら不満はない。今後も物理的に壊れるまで使い続ける思う。

しかし、何も不満がないというと嘘で、当然ながらディスプレイ用の最低限のGPUしか載っておらず、汎用PCIeスロットもないから、機械学習タスクには手が出せない。GPUが必要なタスクだけをDocker化してGoogle Colabやさくらインターネットの高火力DOKといったサービスで計算してもらうことはできるし、やってもいたのだけど、いかんせんこのフローはエージェントを利用した開発との相性がよくない。もちろん権限を渡せば自動化はできるのだろうが、ただでさえトークン代でびくびくしてるのに、機械学習を試すたびに金額が読めないGPU代におびえることになるので、どうしたって気軽な実験は難しいだろう。

というわけでGPUがほしい。なにもDGX Sparkのようなマシンである必要はなく、そこそこの容量のVRAMを搭載したGPUさえあれば十分である。それでもTM200にPCIeスロットがない*1という現実をふまえるとマシンごと買うことになり、これにはだいたい70万円くらいは必要になる。やっぱり無理めの無理だなあ、と思っていた。

ところが、空き時間にGPUを調べまくっているうちに、NVMe SSD用のM.2 M-keyスロットをPCIeスロットに変換するというアダプターの存在に気が付いた。 AliExpress、ほんとうになんでもある。

TM200は、この時代のサーバー製品としては画期的なことに、筐体の底面からM.2 M-keyスロットにアクセスできる。 ここからPCIeスロットに変換すれば、理論的にはGPUを外付けできる。 もちろん帯域は細いので、MoEモデルをRAMやSSDに置いてローカルLLMをするような使い方は厳しいのだが、やりたいのはVRAMにモデルを載せて長時間学習できるようにすることなので、そこの帯域はそんなにどうでもいい。

そこで、こういう構成でTM200に外付けGPUを接続して機械学習モデル開発ができる体制を作ることにした。

graph LR
    TM200["HP ProLiant TM200"]
    M2["M.2 M-keyスロット"]
    K43["いい感じのアダプタ"]
    GPU["GPU"]

    TM200 -->|内蔵NVMe| M2
    M2 -->|外出しPCIe| K43
    K43 -->|PCIeスロット| GPU

物理的な接続

M.2 M-keyスロットからPCIeスロットを引き出すアダプターは、意外といろいろある。 確かにNVMe SSDはPCIe上のデバイスとして見えるので、電気的にはわりと単純な変換なのかもしれない。 逆向き（GPUを使わないけどSSDを増やしたい人向け）の製品もある。

そんなわけで仕様的な面ではあまり心配いらなそう。むしろ気にすべき制約は、GPUという高価な機材を「物理的にどう置くか」である。 GPUへの給電のための電源をどう確保するかも悩ましい。 NVMeからの給電はしょせんSSD向けの容量なので、それでGPUを動かすことはできない。

結論としては、この手のアダプターを出しまくっているADT-LinkというメーカーのK43SG-BK-BK7という製品を選択した。 これはK43SGというアダプターにGPUを固定できる金属製のブラケットが付いているやつで、このブラケットにはATX電源も固定できるようになっている。 ATX電源は古い自作PCで使っていた400W級の静音タイプがあるので、それを取り付けるつもり。

TM200側のM.2 M-keyスロットは、筐体の底面にあるねじ止めされた蓋を空けるとアクセスできる。 SSDを挿入する場合には蓋を締めて使うのだが、アダプターを指したら蓋は締まらないので、しかたないね。 埃や筐体の廃熱性能には問題がありそうだけど…。

GPU

GPUはRTX PRO 4000 SFF Blackwellにした。 VRAMが24GBあり、RTX 5090の32GBには及ばないものの、5070の2倍もある。 旧世代機だとRTX 3090が24GBなんだけど、いま新品を探すとPRO 4000と同じくらいの値段がする（むしろPRO 4000のほうが安い）し、旧世代機だと対応していない精度の量子化を施した言語モデルもあるっぽいので、現行世代にしない理由はなさそう。 70Wという低消費電力なのもえらい（RTX 3090だと350W級）。 PCIeスロット給電のみで動作するので、アダプターであるK43SGに普通のATX電源を接続するだけで動くのもありがたい。

購入と導入

購入前に残る唯一の不安として、TM200のUEFIでGPUが認識されない可能性があったのだけど（PCIeスロットを引き出せることと、その先に接続されたSSD以外のデバイスをUEFIが認識できることは別）、どうしても認識できなかったらWindowsマシン（こちらはPCIeスロット自体はある）で使うことはできるし、とにかくGPUは「必要なら一日でも早く買ったほうが得」という市況なので、購入に踏み切った。

納品されて接続し、とりあえず起動してDebianで確認すると、無事にVGA controllerとしてNVIDIA GB203が見えた。

$ lspci | grep -i -E 'nvidia|vga|3d'
01:00.1 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200EH (rev 01)
0e:00.0 VGA compatible controller: NVIDIA Corporation GB203GL [RTX PRO 4000 Blackwell SFF Edition] (rev a1)
0e:00.1 Audio device: NVIDIA Corporation GB203 High Definition Audio Controller (rev a1)

Debian 13にNVIDIAドライバを入れる

DebianでCUDA対応のGPUを使うには、NVIDIAのopen kernel moduleを導入する必要がある。 そのためには、NVIDIA公式のAPTリポジトリをsource.listに追加して、nvidia-driver-cudaとnvidia-kernel-open-dkmsをインストールする。 これはDebianのバージョンがtrixieであるだけではだめで、実行中kernelに対応するheaderが入っている必要がある。

$ sudo apt update
$ sudo apt install linux-image-amd64 linux-headers-amd64
$ sudo reboot
（再起動まち）

$ wget https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-keyring_1.1-1_all.deb
$ sudo dpkg -i cuda-keyring_1.1-1_all.deb
$ sudo apt update
$ sudo apt install nvidia-driver-cuda nvidia-kernel-open-dkms
（略）
nvidia/610.57.04, 6.12.107+deb13-amd64, x86_64: installed

もういっかい再起動してmodprobe nvidia後にnvidia-smiを実行するとこうなる

$ sudo modprobe nvidia
$ nvidia-smi
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 610.57.04              KMD Version: 610.57.04     CUDA UMD Version: 13.3     |
...

やったね。

Qwen3.8-27Bを動かしてみる

目的はローカルLLMではないのだけど、せっかくVRAMが24GBあるので、テストがてらここに収まるLLMを動かしてみたい。 そんな用途にぴったりのモデルとしてQwen3.8-27B（のQ4_K_M）があるので、これを載せてみた。 とりあえず動けばいいので推論エンジンは素のllama.cppです。

$ curl -LsSf https://llama.app/install.sh | sh
$ llama cli \
  -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \
  --n-gpu-layers all \
  --ctx-size 8192

やったね。

> こんにちは

[Start thinking] 

We need to respond to user: "こんにちは". Then final in Japanese likely. Simple. 
[End thinking]

こんにちは！有什么可以帮你的吗？

[ Prompt: 119.8 t/s | Generation: 17.9 t/s ]

特別に高速化していない素のllama.cppで生成17.9 tok/sを出せるのはちょっと意外だったけど、モデルの重みがぜんぶPRO 4000上に載っていて、TM200とのやり取りが頻繁に発生してるわけでないから、そんなものという気もする。

これからやること

なんでもっと早く買わなかったんだろうって思っている。 いまは、人間（ぼく）の推敲技術を言語モデルに移すための手立てを考えていて、エージェントに基盤を構築してもらいながら学習を回しているところ。 将来的にはローカルLLMも、いわゆるコーディングエージェントとしてでなく、日本語推敲のためのLLM-as-a-judgeとして使いたいので、本を買って応援してください！

www.lambdanote.com

*1:言うまでもなく外部GPUのためのThunderboltコネクタもない

編集者は日本語をどうやって推敲しているか（それを機械化できるのか）

ほんとうにわからない。とはいえ、原稿に対して「これは直す」パターンのようなものはある。「そういうパターンをどうやって見つけていますか」という質問に答えれば、編集者がどうやって日本語を直しているのかを明確にできるかもしれない。

「これは直す」パターンの1つに、「読み手が迷子になりそう」がある。このパターンを見つけるには、一つひとつの文字を次のような意図をもって読み進めなければならない。

  • いま読んでいる段落と、その前後の段落は、どういう関係にあるか。前の段落の話が掘り下げられているのか、違う話に移ったのか、ずっと前の話に戻ったのか
  • いま読んでいる文は、その段落でどういう役割があるのか。前の段落の内容を受けた文なのか、その段落で扱われる内容を展開しているのか、次の段落に繋げる役割なのか
  • いま目にしている単語は、その文の中でなぜその位置にあるのか。これから話題にする主題なのか、主題に対する述語なのか、何を修飾しているのか、文の調子を整えるために置かれているのか

もちろん原稿は、上記のような説明ができる状態になっているとは限らず、次のような問題が見つかることが多い。

  • 少し先まで読まないと意図がはっきりしない文がある（読み手をアンブッシュしてる）
  • 直接は関係のない内容が段落の一部に紛れている（書きたい順に書いたまま）
  • 直前の文に呼応すべき語が次の文の最後のほうに出てきたり、主体と客体が読み手の期待とずれている（事実が単純に羅列されている）

こうした問題を解消し、細部に至るまで先に挙げた「このような説明ができる状態」へ持っていくためには文章をどう直せばいいかを考えるのが、編集者による推敲の具体的な作業（の一つ）である。

たとえば、読み手をアンブッシュしている状態を直すには、次のようなことを考えて修正案を作る。

  • 読み手がそこまでの文章を通じて脳内に作っているであろう地図において、その新しい情報はどこに配置されるはずだろうか？
  • そもそも、この新しい情報を配置できるような地図が、ここまでの文章によって読み手の脳内に作れている？
  • 読み手が脳内に地図を作れているとして、ここで新しい情報が導入されるのだと気づいてもらえるような文は、どう書くべき？

ぼくの関心は、こういう作業を機械にどこまでどう移せるかにある。 ここで挙げた「読み手が迷子」というパターンは、明らかに「文章の大域的な性質」に関係しているから、ルールベースの手段で可能なことはかなり少ないだろう。 重み付け和による手段でも、素朴な単語や文節のベクトル化では限界がある。 Transformerのように「文章の大域的な性質」を扱える仕組みが、最低限の道具立てになるのは間違いない。 japanese-tech-writingというスキルは、それをもっとも直接的に実証してみようとした試みだった。

この先に何が可能なのかは、まだほんとうにわかっていない。 いまはベースとなる言語モデルに対するSFT/DPOや、そのための報酬モデルなどをいろいろ試しているが、やればやるほどわからなくなっているような気もする。

「型は集合」って言いきらないほうがいいと思う

式の集まりとして構成されているプログラム*1を考えよう。 プログラムを実行すると、式が順番に実行されていって、最終的に何らかの結果が得られたり、あるいは行き詰まり状態になって何も得られなかったりする。

いま、「実行すると数値になる式」と「実行すると真偽値になる式」とを区別したいとしよう。 なぜ区別したいかはいったん忘れて、とにかく「両者の区別がきちんとなされているようにプログラムを書きたい」というモチベーションがあるような状況を考えてほしい。

このような区別の価値は、たとえば「実行すると真偽値になる式」にBoolのような名前を付けるだけで満足してしまうと、半減する。 そんなふうに名前を付けるだけでは、「…真偽値になる式」の部分にしか言及できないからだ。 つまり、「実行すると…」の部分によってもたらされるかもしれないありがたみが反故になってしまう。 いま欲しいのは、あくまでも「実行すると何になる式か」を論じられるような区別であって、式を実行した結果の値の性質による分類ではない。

幸い、式に対する規則の集まりを定義することで、この区別が実現できることがわかっている。 そのような規則を「型付け規則」と呼ぶ。 型付け規則によって割り当てられるものが「型」である。

型付け規則の集まりをうまく用意すると、式を実行したときに行き詰まり状態にならないことが実行しなくてもわかる、という素晴らしい結果が手に入ることが数学的に証明できる。 これが一般に「型安全性」と呼ばれる性質である。

ここまでの話で読み取ってほしいことが2つある。

  • 型付けは、プログラムの式を素朴に分類するだけの話ではない
  • 値の種類による分類は、プログラムの型安全性とはけっこう違う

言い換えると、型を「取りうる値の集合」として説明してしまうと、プログラムの型安全性について説明したことにならない*2。

もちろんこれは、「型を集合としては説明できない」という意味ではない。 「取りうる値の集合」としての型、「その集合の要素」としての式を実行して得られる値、「集合間の写像」としての関数、「部分集合」としての部分型といったきれいな対応はあるし、バリアント型やレコード型を集合の和や積に対応させることもできる。 実際、そのような対応は単なる比喩ではなく、型安全性の証明は歴史的には集合としての解釈で示されていたらしいし、特にTypeScriptでは、和や積や部分型といった型の構造を説明するのに集合が使われている。

しかし一般には、型の構造が説明できることと、型安全性が説明できることは、別の話である。 後者については、型を「値の集合」とみなすと情報が足りなくて、たとえば再帰的なプログラムの振る舞いを説明できない。 型が違うけど同じ仕方で振る舞う関数みたいなやつ（いわゆるジェネリクス）についても、型変数を集合に対応させること自体はできるだろうけど、その性質はやはり型を「値の集合」として説明するだけでは説明できない。

そもそも「集合」という概念自体がふんわり使われすぎているのも気になる*3。 「Javaとかのtypeとは違うよ、むしろsetだと思うとよいよ」みたいな説明ならともかく、「型は（取り得る値の）集合です」というだけでは、説明をしたことにならない気がする。

というわけで、「型は（取りうる値の）集合」といった一般向けの説明は、型安全性の話をしたいときには、あまり好ましくないのではないかと考えている。 いろいろわかったうえで「集合という直観」を説明に使いたいという気持ちはわかるものの、そこはこらえて、せめて型安全性について話をするときには上記のような世界観のほうをなんとか（この記事よりうまくかつ正確に）伝えてほしいなと思う。

「そうはいっても、型とは何かの説明、めんどくさいんだよな」という場合には、『型システムのしくみ』という本がありますので、「プログラミングにおける型が何かについては、ひとまずこの本を読んでください」の一言で済みます。 便利です。

型システムのしくみ ― TypeScriptで実装しながら学ぶ型とプログラミング言語www.lambdanote.com

なお、小難しいことを言うと、むしろ「集合は型の一種」というべきです。 具体的には、ホモトピー型理論に「同一視型」というのがあり、この「同一視型が命題である型」が「集合」と定義されます。 ホモトピー型理論と同一視型については、『n月刊ラムダノート「特集：計算とは何か」Vol.6, No.1(2026)』をご覧ください。

n月刊ラムダノート「特集：計算とは何か」Vol.6, No.1(2026)www.lambdanote.com

*1:TypeScriptのようなプログラミング言語のそれ。

*2:「実行すると真偽値になる式」みたいな区別も「集合」による分類ではあるので、これを集合とみなした説明であれば、それなりに表現力のあるプログラムについて型安全性の話はできると思う。

*3:公理的集合論をやれ、みたいなことが言いたいわけではない。

TCP/IPについて語るときにATMについて語ること

この記事の主な目的は『ネットワークシステムについて語るときに我々の語ること』という本の宣伝です。

みなさんが「コンピューターネットワークの勉強」といって真っ先に思い浮かべるのは、十中八九「TCP/IPの勉強」でしょう（残りの1割か2割の人はにやにやしてください）。

しかし、ぼくが30年近く前にコンピューターネットワークについてはじめて勉強したのは「ATM（Asynchronous Transfer Mode）」という名前の技術でした。 ATMは次世代（当時）電話網での採用を目指して電話業界寄りの標準化委員会*1で設計された技術です。 ちなみに「目指して」というのは現代っぽいナチュラルな言い方で、当時は「うちらでこういうの標準化しといたから、みんな次の電話網はこれでつくろうね」という印象でした（印象です）。

もちろん、そのころにもTCP/IPはあって、というか最初は「TCP*2」でそこからIPが分離されたんですが、とにかくTCP/IPはありました。 もっとむかし、あちこちに乱立した独自のデータ通信ネットワークがあったころ、それらを相互に接続するための技術のひとつとして開発されたのがTCPです*3。 同じような動機の技術はいろいろ存在していたらしいですが、30年近く前にはすでにインターネットといえばTCP/IPという立ち位置を確立していました。

インターネットといえばTCP/IPだったからといって、TCP/IPだけを勉強していればコンピューターネットワークの勉強が済むことはありませんでした。 コンピューターネットワークはインターネットとは限らなかったからです。 むしろ「インターネットつっても、どのみちTCP/IPだけでは無理だから」という空気もあったように思います。 そういう空気を作っていたのが、当時のデータ通信の基盤として無視できなかった電話網の存在でした。

電話網は、インターネットのようなパケット通信ではなく回線交換という仕組みです。 「これからはデータ通信が増えるので、電話網もデータ通信に向いたパケット通信にしていこう」ということで考案されたのがATMです。 それまでの電話交換機をATMスイッチでリプレースすれば、そのうえでTCP/IPを使ったインターネットもできるし、テレビ電話もできるし、テレビの配信だってできるね、というわけです（このあたり、かなりはしょってます）。

ここで上記の文のポイントは、「TCP/IPを使ったインターネット」が「コンピューターネットワークで実現する数ある便利なやつ」の一つにすぎなかったことです。 テレビ電話とかテレビの配信とか、それ以外のサービスがなんかテレビを端末として使うものに偏重してるように見えますが、そういう時代でした。

そうはいっても、30年近く前にはもうウェブサイト（当時の言葉でいうとWWWのホームページ）を開設している会社や人は多かったし、コンピューターネットワークの未来はわりとインターネットとTCP/IPに決まりつつありました。 「もうTCP/IPを勉強しておけばいいんじゃないかなー」って空気が急速に出来上がりつつあった時代だったとも思います。 とはいえ、「出来上がりつつあった」ということは「なかった」わけで、だからぼくが最初に勉強したコンピューターネットワークの技術もATMだったのでした。

いまやATMは忘れ去られた技術です。この記事のタイトルを見て、TCP/IPと銀行の話かなと誤解した人もいるかもしれません。 ATMが生き残れなかった要因としてよく聞くのは、「複雑になりすぎたから」とか「Ethernetが安くなったから」といったものです。 確かにATMには、傍から見てもびっくりするくらいお金が動いていたと思います。

それに加えて、ATMが生き残れなかった理由には、「電話交換機をATMスイッチにリプレースしたネットワーク」のようなものに誰も旨味が見いだせなくなったってのもあるだろうなとぼんやり思っていました。 何億円もするCiscoの基幹IPスイッチがどしどし買われていて、そういうIPスイッチでインターネットそのもののバックボーンが作られる時代に、ぶっちゃけ電話交換機と併用できることくらいしかメリットがないATMにそれ以上の投資をするのは厳しいでしょう。

最近、この雑な見立てに説明の言葉を与えてくれる本を読みました。 『ネットワークシステムについて語るときに我々の語ること』です（繰り返しですが、これは本書の宣伝記事です）。


この本によると、ATMの敗因は下位層の選択肢が固定されていたことでした。 どんなに「その上でいろいろなサービスを実現できる」ような技術でも、それを載せる基盤が固定されていれば、その基盤を誰も使わなくなったとたんに無用の長物化します。 ATMの場合、従来型の電話回線の基盤を活用すること自体に旨味がなくなったことで、わざわざATMを選択するという動機がなくなったというわけです。

一方でTCP/IPは、その上のサービスだけでなく、下位層で選択できる技術も事実上無限大です。 それこそATMだってかまいません。 あちこちの独立したネットワークを相互に接続するための技術という出自からして、すでにあるデータ通信の基盤をなんでも活用できます。 このようなTCP/IPの設計は、もっとも細いくびれにIPを配置した「砂時計」としてモデル化できます。

なお、TCP/IPが砂時計モデルであるという指摘はこの本のオリジナルではありません。 この本では、Steve Deeringという人の講演と、米国政府後援の報告書 "Realizing the Information Future" の文脈で砂時計モデルが紹介されています。 いずれにしても、このようなシステムを評価するときに「砂時計」という便利な言葉があることを、ぼくは『ネットワークシステムについて語るときに我々の語ること』（の原書）を読んではじめて知りました。

この本には、まさに題名のとおり、ほかにも「ネットワークシステムについて語るとき」に便利な概念や文化がごろごろしています。 ATMってあったなーという方も、ネットワークはTCP/IPしか知らんという方も、ぜひ手に取ってみてください！

標準ATM教科書と記念撮影

*1:CCITT/ITU-T

*2:Transmission Control ProtocolではなくTransmission Control Program

*3:TCP自体はARPANETとパケット無線通信、パケット衛星通信を繋ぐことが目的だったらしい。

2026年にもなって日本語のTeXワークフローがいまだにDVIを経由しているわけ

欧米ではすっかりpdfTeXに移行してPDFを直接生成するワークフローになっているのに、なぜ日本語ではPDFを出力できない(u)pTeXがいまだに生き残っているのか。 簡単に言うと、TeXと事実上互換性があるpdfTeXが発明されたときに、日本語圏のデファクトだったpTeXのことが一切考慮されなかったからである。

このような事情により、pTeXをpdfTeXベースに改修することも、pdfTeXをpTeXとの互換性を最大限に保って日本語に対応させることも、技術的な制約によって無理という状態になった。 pdfTeXベースの日本語TeXを作るには、ぜんぜん違う日本語TeXを改めて作るしかなかったのである。

そのようにして作られたのがLuaTeX向けのluatex-jaである。 これはLuaTeXそのものを改良するという方法ではなく、LuaTeX向けのパッケージとして作られた。

同じ要領でpdfTeXを日本語対応すればいいじゃないか、あるいは、pTeXを作ったときになんでそうしなかったんだ、という気持ちになるかもしれないが、luatex-jaでこれが可能だったのは、LuaTeXがUnicodeエンジンだからである*1。 TeXはもちろん、pdfTeXでも日本語はそのままでは扱えないので、このアプローチが原理的にとれなかった。

と言ってしまうと、実は微妙に嘘になる。TeXやpdfTeXでも超絶技巧でUnicodeを扱うことはできる。 CJKパッケージがそれである。 pdfTeXでCJKパッケージを使って日本語の組版をする手もないわけではない。

ないわけではないのだが、やはりpTeXの資産は偉大で、それはpTeXがもともとアスキーという出版社が出版のために開発したものだったからという背景があるのだろう。 pTeXほどの日本語組版をCJKパッケージで実現するのはたいへんなのである（BXcjkjatypeがそれを目指していて、用途を選べば使える）。 そもそもpTeXが開発された当時にはCJKパッケージなどない（そもそもそもそもUnicode 1.0より前の話だ）。

というわけで、現在でも日本語の組版ではpTeX（あるいはその内部処理を拡張したupTeX）がよく使われており、これは出力がPDFではなくDVIなので、DVIをPDFにするというワークフローが必要になる。

さっさとluatex-jaに移行すればいいのはもちろんだが、pTeXと完全に互換というわけではないので、そんなに単純にもいかない。 新しく文書クラスを作るときはluatex-jaを前提にしましょう。

DVIはTeXとは別に発明されたものだった

TeXのオリジナルの出力形式と思われがちなDVIだが、TeXのエコシステムに最初からあった仕組みではなく、Knuthの発明でもない。 Knuthが最初に実装したTeXは、DVIではなく、スタンフォード大学にあったプリンタ向けの出力を吐き出す組版エンジンだった。

当然、プリンタが更新されたらそれまでの実装では使えなくなる。 プリンタのリプレイスのたびにTeX本体の実装をいじるのは厄介だぞ、ということで、その当時にKnuthの学生だったDavid Fuchsさんが中間形式としてDVIという出力形式を発明した。 DVIは文字通り「Device Independent」だったのである。

DVIではフォントの扱いもTeX本体から切り離された。 TeX本体ではフォントを「文字のメトリクス」としてだけ扱い、現物のフォントを扱うのはDVIドライバの仕事になった。

さらに、このレイヤー分けを応用して、仮想フォントという仕組みも発明された。 おかげで、実体フォントの一部のグリフだけを別のフォントのものに差し替えるといった芸当も可能になった（合成フォントのような機能） *2。

余談だが、DVIの発明者であるDavidさんは、2019年にスタンフォード大学で開催されたTUG（TeX User Group）ミーティングでかなり現代的なDVIビューワーを実装して発表されていた。 大規模なTeXソースの変更にリアルタイムで追随して再組版した結果が閲覧できるという、わりととんでもないビューワーで、DVIのDevice Independentっぷりと仮想フォントの威力を見せつけられるものだった。

DVIを発明した当時、DavidさんはKnuthの学生だったわけだけど、博士号はとらないまま学校を去ることになったらしく、2019年の発表では最前列にいたKnuth本人に「これで私も博士号がもらえますか？」と冗談を飛ばしていた。 Knuthは「Yes」と答えていた。 ハートウォーミングである。

*1:もちろんluatex-jaが実現できた理由はそんなに単純ではない。

*2:ただし、LuaTeXでも実体フォントだけでなく仮想フォントが扱えるようにエンジンが実装されているので、仮想フォントは現在でもDVIが利用されている理由というわけではない。

AI時代のコンピューター技術書

LLMのおかげで滑らかな自然言語をコンピューターで気軽に使えるようになった。ウェブを中心に、生成AIで出力された（とおぼしき）文章を見かける機会も増えた。これからもっと増えるだろう。特にコンピューター技術の解説という分野では、生成AIの出力がそのままコンテンツとして公開されていることも多い。ウェブだけではなく、書籍のようなオールドメディアでも、すでに生成AIが下書きや校正に使われている。もしかしたら、さらにアグレッシブな使い方がまかり通っているかもしれない。

生成AIがあれば、もう技術書などいらないような気もする。誰かが生成AIで解説コンテンツを作る必要すらないだろう。知らない技術が出てきたら、その場でAIチャットに解説してもらえばいい。誰がAI時代にコンピューター技術書を購入して読むんだ？

この疑問には、いまのところ否定的な反応（つまり「本は大切だよ！」という意見）が多いように思う。いわく、AIチャットの回答は信用できないから何らかの形でこれからも技術解説コンテンツの価値はある。いわく、生成AIは表面的な説明文は作れるが、それが妥当な説明である保証はないから、著者が責任をもって構成して読者がつまずくポイントを見越して書かれたコンテンツが重要になる。いわく、そもそも知らない技術があることに気が付けなければ、AIチャットに質問することさえできないではないか。

実際、LLMの解説書や、AIエージェントの使い方の本などは、それなりの点数が出ていて、どれも売れているように見える。それこそAIチャットに聞けば済むような技術について、有料の解説がこれだけ求められているのだとしたら、まだまだコンピューター技術書がAIチャットで代替されることはないような気もしてくる。やはりAI時代でもコンピューター技術書には一定の需要があるのだ。

いや、本当にそうか？

LLMが得意なのは文章の生成よりも読解

これは技術書だけの話ではなく、文章だけの話でもないのだが、生成AIとコンテンツという話題では「コンテンツを誰でも作れるようになった」という観点での議論が多いように感じている。誰でも作れるようになったので価値がない、いや、誰でも作れるコンテンツは品質が低いのできちんと作られたものには依然として価値がある。だけど個人的には、生成AIがもたらしたインパクトのうち「コンテンツを誰でも作れるようになったこと」はほんのきっかけに過ぎないだろうと思っている。話を文章コンテンツに絞ると、LLMの本当のインパクトっていうのは、むしろ「文章を読むのがやたらに得意」というLLMの性質から生まれてくるはずだ。言い換えるとぼくは、LLMの本当のインパクトは「われわれ人間が入力する文章を読むのが人間に限られなくなったこと」にあると考えている。

もちろんこれまでも、誰に読ませるつもりもなく自分のためだけに文章を書いている人はいた。それこそ日記などは誰かに読んでもらうために書く文章でもないだろう。異界の存在と交流する人や、SNSでボットと真剣に「対話」する人もいた。しかし通常、ほとんどの場合、人間が書く文章の読み手として暗黙に想定していたのは人間だっただろう。非人間、とくに機械に読ませるために書くものは、文章というよりはコードだった。

ところがLLMが存在しているいま、人間が書く文章の読み手はもはや人間だけではない。それどころか、自分がコンピューターで入力している文章のほとんどが読み手としてLLMを想定したものになっている人も少なくないはずだ。いまや人間は、人間に読まれる可能性をまったく想定せずに、日常的に文章を書き散らかしているのである。

ここで「書き散らかしている」という表現を使ったのは、言葉のあやでもなんでもない。人間以上に読むのがうまいLLMに渡す文章なら、ちゃんと書かなくてもよく、文字通りに書き散らかせる。人間に読まれる可能性がある文章ではそうはいかない。人間は全般的にそれほど文章を読むのがうまくないからだ。人間が文章をちゃんと読めるようになるには、かなりの訓練を要する。書き手がどんなに言葉を尽くして文章を書いても、それだけで誰もが「読める」とは限らないのである。

一方でLLMは、あらゆる文章を「読む」訓練ができている。というか、そういう訓練を終えた学習済みモデルである。だから、どんなに難しい文章でも、どんなに変な文章でも、読める。言葉足らずでも、なんなら非文でも、単語が並んでいれば「文意」らしきものを見つけられる。そんなLLMが読み手なら、書き手が文章を練り上げる必要はない。本当は練り上げた文章のほうがコンテキストを節約できていいとか、そういうのはあるかもしれないが、そういう方向で頑張るのは作文というよりもプログラミングに近いのではないだろうか。少なくとも、その結果は人間にとって読みやすい文章とはまた違ったものになるように思う。それなりに共通点はあるような気もするけれど、このへんはまだよくわかってない。

LLMという読み手には編集がいらない

話を戻すと、LLMが文章コンテンツにもたらした最大のインパクトは、「必ずしも文章を読む訓練をつんでいるわけではない人間向けではない文章」の価値を爆上がりさせたことだろうと自分は考えている。つまり、ちゃんと書かれていない文章が、LLMに読ませるという前提で、人間にとっても潜在的な価値が見出せるコンテンツになった。

これがコンピューター技術書のような文脈でどういう意味を持つのかは、わりと自明だろう。

LLM以前には、著者の知見やアイデアを読み手のために編集することが付加価値であり、それが出版社の意義のひとつでもあった。なるべく多くの読み手に受け入れられやすい文章の型のようなものがあり、それに合わせて原稿を調整できることが、編集者にとって必須のスキルであった*1。

しかし読み手がLLMなら、どんな原稿でも、いい感じに文意を汲み取ってくれる。少なくとも人間の読み手を意識した編集はいらない。読み手が人間のつもりで書かれた文章であっても、最近ではLLMに要約させて読ませる人が多いだろう。どうせLLMで要約するなら、やっぱりこれまでのように編集という手間をかける必要はないように思える。

要するにこういうことだ。文章コンテンツにとってのLLMは、編集がいらない訓練された読み手である。LLMという読み手にとって、文章の表現力や読みやすさはあまり意味がない。LLMという読み手の前では、人間がLLMを想定して書き散らかした文章未満の文字列も、LLM自身が生成した中身を薄めた長文も、プロの編集者が丁寧に編集した文章コンテンツも、たぶん同じような価値しかない。

人間が読み手であることをやめるまでは

LLMを読み手として想定する限り、従来の編集はいらなくなる。人間を読み手として想定していても、読み手がLLMで要約することが想定されるなら、やはり従来の編集はいらないように思える。それでも人間を読み手として想定するならちゃんと編集しろ、むしろちゃんと編集せずに読みにくい状態で世の中に出すから読み手がLLMで要約したくなるんだろうが、というもっともな意見が目に浮かぶのだが、便利なものがあったら使いたくなるのが人情だし、とにかく文章を読むというのは人間にとっては苦痛なので、読み手が「この内容ならLLMに渡して要約すれば十分だな」と感じる文章コンテンツは、どんなにちゃんと編集されていてもじゃんじゃんLLMで要約されるのがおちだと思う。

結局のところ、これからも人間が文章を読むとしたら、それは読む行為そのものを人間が楽しむような文章コンテンツか、読む行為そのものをしたい人間が文章を読む場合だけになっていくのだと思う。これはコーディングエージェントの興隆から類推しても、わりと確定した未来なんじゃないだろうか。どんなにコードを書くのが楽しくたって、人々がエージェントに書かせるという流れには逆らえなかったように、文章を読むことも、権利面などがクリアにされていくにつれ、どんどんLLMまかせになっていくだろう。

ただし、ぼくは「もう技術解説なら編集なしで世に出してしまえばいいじゃないか」と思っているわけでもない。読む行為そのものを人間に楽しんでもらうための文章コンテンツに対しては、読み手がLLMを使おうが使うまいが、人間のための編集をやめてしまうわけにいかない。そういう文章コンテンツは、文芸だけでなくコンピューター技術書にもある。LLMなら文章をトークン化してなんかすごい次元のベクトルをうねうねすることで「理解」できるのかもしれないが、人間が文章で書かれた知見を「理解」するためには、それなりに時間をかけて丁寧に読むという体験が必要になる。これはうちらが人間の脳を思考に使わないことにするまでは必要なコストに思えるし、そのコストを下げるのが編集という仕事だろう。

商売は厳しく

というわけで、文章コンテンツに対する編集が無駄な存在になったわけではないとは思っているのだが、かといってそれで編集者や出版社が生き残れるかとなると、現時点ではいくつかの理由でネガティブな気持ちが強い。

なにより理由として大きいのは、単純に経済合理性の観点である。これまで編集が商売になってきたのは、読み手が人間しかいなくて、その読み手のために最低限の編集が必要だったからだ。読み手があらゆる文章をLLMで要約するようになり、さらにはLLMしか読まない文章の割合が増えるにつれて、編集が求められる機会は減っていくだろう。LLMという読み手の存在によって文章の消費スピードが桁違いになっていることも、経済合理性にとっては都合が悪い。人間のための編集は、LLMによる生成のようにはスケールしない作業なのだ。

もう1つ言えることとして、人間のための編集をLLMで自動化するのは無理そうという直感がある*2。おそらく人間の読み手のための編集には、文章の滑らかさとは異なる、一定の価値を満たす必要がある。そのような深層学習モデルが誕生する未来もありうるが、少なくとも現在のLLMはそれではない。編集の自動化に使えるAIができるまでは、人間が既存の仕組みを使いながら読んで編集をするしかないように思える。

だから結局、AI時代のコンピューター技術書とは何かと問われたら、答えは「人間が読む気になる文章コンテンツを人間の読み手のために編集した本」ということになるのだろう。

でも、それって従来のコンピューター技術書と同じじゃないの？

同じなんだけど、置かれている環境が違う。従来のコンピューター技術書は、読む気がない人でも買ってくれる可能性があった。AI時代のコンピューター技術書は、自ら文章コンテンツを読む気がある人しか買わない。たとえ読み手がLLMを使えても、求められる編集は従来と変わらないので、そのためのコストが下がることはない。

コストは変わらないのに買ってくれる人は減るので、出版社は何か手を打たないとまずいだろう。しかしどんな手が打てるというのだろうか。

*1:この記事では「編集」という行為を「文章の調整」という狭い意味で使っている。言うまでもなく編集者にはほかにも重要な仕事がいくつもあるが、LLMとの対比では文章の調整という観点だけに絞ってしまって問題ないだろう。なにより、文章の調整以上に必須な編集者のスキルというのもないだろうし。

*2:人間の読み手のための編集が効いた文章を一発で生成できるAIがあれば、たとえばAI slopもそこまで問題にはならないんじゃないだろうか。

既刊書が売れるツイート、売れないツイート

冷静に考えれば当然だけど具体的なデータとして見える機会は珍しいであろう現象に遭遇したので、時雨堂のvoluntasに協力してもらって記事にしておくことにしました。

2つのツイート

2025年7月25日（金）の午後、ぼく自身がこんなツイートをしました。ちょうどAIコーディングエージェントによるWebアプリのセキュリティに関する話題をTLで目にしたので、これを機に当社で発行している書籍『Webブラウザセキュリティ』のことを思い出してもらおうという意図がありました。

その2日後の7月27日（日）の夜、たまたま時雨堂のvoluntasも同じ本についてツイートしてくれました。ぼくが気づいたのは翌朝なので前後の文脈はわからないのですが、時雨堂はラムダノートに出資してくれていることもあって、機会があると当社の本（のうちvoluntasが個人的に興味があるもの）について言及してくれます。

どちらのツイートも7月29日までには200favを超えています。これくらい多くの人の眼に触れると、サイトの訪問者数もそれなりに増えて、そのうちの何割かは書籍を購入してくれます（ありがとうございます！）。

インプレッションはどちらも同じ

これらのツイートによる直販サイトへの反響には、かなりはっきりとした差がありました。しかし、面白かったのは、両者のインプレッションがほぼ同一だったことです。まず、ぼくのツイートの7月29日時点でのアナリティクスはこちら。2万弱のインプレッションがあります。

voluntasのツイートについても、お願いして7月29日時点のアナリティクスを見せてもらいました。やはり2万弱のインプレッションです。ぼくのツイートのほうが集計期間が2日ほど長いですが、ツイッター上での反響は偶然とは思えないほど似通っています。

コンバージョン数はぜんぜん違った

インプレッション数はそっくりなのに、両ツイートによる当社直販サイトへの影響にはかなりはっきりとした違いが見られました。1つめのツイートの前日である7月24日から、2つめのvoluntasのツイートの翌々日である7月29日までの売上の変動を見ると、くっきりとした差が読み取れます。

このデータには両ツイートで言及している書籍以外の売上も含まれていますが、それにしてもvoluntasのツイートの直後のほうがかなりたくさんの人に手に取ってもらえていることが察せられると思います。

何が差を生んだのか

インプレッション数がほぼ同じツイートで、コンバージョン数にこれだけ大きな差が生じたのは、どういうわけでしょうか。

今回、2つのツイートが同じようなタイミングで投稿され、しかも同じようなインプレッション数になったのは、完全に偶然です。再現性がある現象でもないので、あくまでも感覚による推察でしかありませんが、おそらくツイートを見てくれた人の属性が大きく違うことが原因だと考えるのが合理的でしょう。

ぼくのアカウントは、現在は主に自社の本の宣伝をするために使っており、フォローしてくれている方々もそれを期待していると考えられます。言い換えると、たぶん、ぼくのアカウントのフォロワーはラムダノートに興味を持ってくれています。ぼくがツイートする本をすでに持っているという方も、きっといるでしょう。その方々がツイートをみて改めて本を買ってくれることはまずないと考えられます。

一方、voluntasのアカウントをフォローしている方々は、ラムダノートの本に興味があるわけではありません。ラムダノートの存在自体を知らない人も少なくないでしょう（しかもvoluntasのアカウントはぼくのアカウントの3.5倍くらいのフォロワー数がある）。そのアカウントにおける2万インプレッションは、ほぼ全員がラムダノートを知っている皆さんの中での2万インプレッションとは、少なくとも既刊書の存在を潜在的な対象読者に届けるという観点ではかなり違うと想像できます。

知らない人に知ってもらうには

今回の現象であらためて感じるのは、「知らない人に知ってもらう」のがほんとに難しいという現実です。ラムダノートでは「刺さる人に確実に刺さる本」を発行している自信がありますが、そもそも「刺さる人」に見つけてもらえないことには刺さりようがありません。幸い、「刺さる人」の大半が主にウェブで情報を取得してくれる層なので一定以上の割合の方々には存在を知ってもらえていると思うのですが、それでも当社をまだ知らない、あるいは当社の本の存在に気づいてもらえていない「刺さる人」もまだまだ多いのだろうなと、今回の現象を見てあらためて痛感しました。

最後に、ラムダノートの本をすでに知っていて「ちょっといいな」と思っていただいている方々へのいつものお願いです。まわりにまだラムダノートの本を知らない人がいたら「いい本あるよ」とぜひ教えてあげてください！

www.lambdanote.com