golden-luckyの日記

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

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

式の集まりとして構成されているプログラム*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

読み手と書き手にとっての『n月刊ラムダノート』

読み手にとっての『n月刊ラムダノート』

今期は「とにかく『n月刊ラムダノート』の企画をがんばる」を目標に設定しています。 『n月刊ラムダノート』というのは、当社の不定期刊行誌で、次のような特徴があります。

  • A5版で20ページ~50ページの解説記事を3つくらい収録
  • それぞれ雑誌記事やブログに比べるとだいぶ本格的だけど、論文よりは気軽に読める

こんなふうに特徴を列挙しても、それだけだと具体的なイメージがわきにくいと思うので、ぜひ実物を見てください! たとえば今年発行した各号には次のような記事が掲載されています(いずれも公式ブログの紹介からの引用)。

『n月刊ラムダノート』Vol.4 No.3(2024)の内容
『n月刊ラムダノート』Vol.4 No.2(2024)の内容
『n月刊ラムダノート』Vol.4 No.1(2024)の内容

どれも「いつか知りたい、でもキーワード解説や雑誌の特集ではわかった気にしかなれない、かといって入門書をしっかり読む時間もない」というトピックばかりですよね! コンピューター技術の分野には、こうした「休日の午前中にちょっと真剣に読んだらめっちゃ充実する」とでも言うべき読み物がもっとあっていいと思っていて、それが『n月刊ラムダノート』で実現できればなと考えながら発行しています。

出版企画の三つ組

とはいえ、理念だけで出版は実現できないのも現実。 『n月刊ラムダノート』も企画にはずっと苦悩していて、なかなか「定期」刊行誌になれそうもありません。

これは本誌に限らないのですが、出版の企画は「こういう解説を読みたい人がたくさんいるだろう」といった着想ではありません。 そうした着想からスタートするにせよ、実現に向けて不可欠な要素はほかにもあって、具体的には「構成」と「書き手」です。 言い換えると、「構成」と「書き手」、そして「着想」の三つ組がそろってはじめて企画になります。

着想 <-> 構成
  \      /
   書き手

編集者には、着想がいろいろ思いつく人もいれば、構成を練るのが得意な人もいれば、書き手とつながるのがうまい人もいます。 しかし、どれか1つが得意なだけで企画ができるわけではないので、得手不得手を補完しつつ三つ組をぶんぶん回すしかありません。 最強なのは書き手本人が着想と構成もぶんぶんやれる場合で、でも最近は同人誌とかウェブでの公開とか書き手にとっての手段が多様化しているから、出版社で本や記事を書いてもらう動機が昔に比べると示しにくい気がしています。 提示できる動機としては、対価や露出が考えられるけど、小さい出版社だと対価はともかく露出に期待してもらうのは難しい。

編集者としてのぼく個人は、「編集」を動機にしてもらえるように頑張っているつもりです。とはいえ「編集されること」は書き手にとってメリットとして自明ではないので、これを潜在的な書き手に認識してもらう手段が悩ましい。

書き手にとっての『n月刊ラムダノート』

実は『n月刊ラムダノート』は、この「編集されること」のメリットを潜在的な書き手に体験してもらう機会になれるんじゃないかなと考えています。 一冊の本だと「企画の三つ組を揃える」、「書き上げる」、「編集する」のイテレーションがけっこう重いけど、30ページくらいの記事なら比較的軽くなります。 企画自体も軽めに始動できるので、潜在的な書き手にとっても、「こういうの書けそう」とか「書いてみた」から「不特定多数が読むことを想定した日本語にして公開する」までのイテレーションを体験してもらうことで編集が入ることのメリットを見定めてもらう機会にしてもらえるかなと。

もちろんこれは編集者にもメリットがあって、本として完成するまでのイテレーションの重さを考えると躊躇するような企画にも取り組みやすくなります。 多様化する題材へのキャッチアップが大変といった別の悩みもあるのですが、これはむしろ編集者としての筋トレには役立つという見方もできるのでがんばる。 まあ、本よりだいぶ収益性が低いといった経営的な課題はあるのですが、それも企画の機会が増えることで補えるかなと。

それでも難しいのは、このイテレーションを体験してもらう潜在的な書き手、もう少し正確に言うと「書きたくて、かつ書ける人」にそもそも巡り合うことだったりします。 書くという行為にかかる時間や体力を考えると気軽にお願いしにくかったり、そもそも何を書いてもらうべきか(着想と構想)に対する自分の視野がなかなか狭かったり、自分側の原因はわかっているのでそこらへんはがんばっていくとして、潜在的な書き手の皆さんからのご相談もお待ちしています。

書きたいこと、書けることがあって、このイテレーションで編集のメリットを体験してみたいという方がいましたら、こちらを参考に気軽に寄稿を検討してみてください!