十度の修理、一文字
九人のアリバイを確認して、ようやく真犯人が見えた
StackTubeには、一か月分のノートを一冊の電子書籍にまとめる機能がある。月末になると、その月に分析された動画ノートが章になり、表紙がつけられ、メールとKindleに配達される。月刊ムックと呼んでいる。この機能を作っていた週末の話だ。
ビルドは成功した。ファイルも生成された。容量もそれらしかった。ところが本を開くと、白紙だった。
目次はあるのに本文がない本。エラーメッセージはなかった。システムのどこを見ても「成功」と書かれていた。成功したという白紙の本。ここから捜査が始まった。
エラーが出ればエラーメッセージをAIに送ればいい。それはもう怖くない。ところが今回は送るものがなかった。「本が空だ」という言葉は手がかりではなく症状だ。病院に行って「痛いです」としか言えない患者になった気分だった。どこがどう痛いのか分からなければ、医者も当て推量で始めるしかない。
だから当て推量で始めた。フォントパッケージが抜けているのか——直した。白紙。スタイルシートがつながっていないのか——直した。白紙。デプロイ設定でファイルが漏れたのか——直した。白紙。変換器のオプションか——直した。白紙。一度直すたびに「今度こそいけた」という確信があり、毎回、本は空だった。
ここで奇妙な点があった。直すものごとに、実際に問題ではあった。フォントも、スタイルシートも、デプロイ設定も、すべて手を入れるべき箇所だった。一つ一つが本物の欠陥だった。だからかえって混乱した。直すたびに「これが原因だったろう」と信じる根拠があったから。真犯人が別にいるのに、小物たちが次々と捕まる状況だった。
これがこの種のバグの持つ罠だ。容疑者が一人なら捜査は簡単だ。その人を調べれば終わる。しかし容疑者が十人で、そのうち九人がそれぞれ別の些細な過ちを犯していたら——真犯人を選り分ける仕事が難しくなる。過ちを犯した者が多いほど、誰がこの事件の本当の原因なのかがぼやける。
七度目の修理でAIが犯人を見つけた。原因はコード一行。正確には、文字列をバイトに変換する処理が一つ抜けていた。
説明を聞いてもしばらく理解できなかった。要約すればこうだ。本の各ページを作るライブラリがあり、そのライブラリに文章を渡すときは特定の形式でなければならなかった。形式が合わなければライブラリはそのページを作れない。ところがその失敗が表に出ず、空のページに置き換えられていた。だからすべてのページが静かに空だったのだ。
修正は.encode("utf-8")——一行だ。この一行を入れると712,841バイトの本ができた。本文のある本だった。
その夜に考えた。十度の修理のうち九度は無駄だったのか?
違った。それがこの事件で私が得た最大の教訓だ。九度の修理は無駄ではなく、真犯人を浮かび上がらせた過程だった。フォントを、スタイルシートを、デプロイ設定をすべて直して容疑者リストから消していくと、残った場所に本当の原因が一人で立っていた。容疑者が十人のときは推理ができない。九人のアリバイを確認する仕事は退屈だが、それが捜査だ。その退屈な消去なしには、最後の一人を指し示せない。
非開発者にとって、これは特に重要な感覚だった。私はコードを読めないから、「この部分が原因だろう」という直感がない。開発者ならコードを眺めて真犯人をすぐ絞り込めるかもしれない。しかし私にはそんな近道がない。代わりに私には消去法があった。一つずつ直し、一つずつ消し、残るものを見る。遅いが、結局たどり着く。
そしてもう一つ。私はもう「成功」という言葉を少し信じなくなった。システムが「ビルド成功」と言うことと、成果物がまともであることは別の問題だった。ビルドが成功したというのは「ファイルを作る過程にエラーがなかった」という意味であって、「そのファイルの内容が正しい」という意味ではなかった。その二つを同じものと錯覚している間、私は白紙の本を七度作った。
一文字。正確には一行。しかしその一行を見つけるまで九度の消去が必要で、その九度は無駄ではなかった。
🔧 このエピソードの技術用語解説
EPUB 電子書籍の標準ファイル形式。内部的には複数のウェブページ（XHTML）を圧縮してまとめたもの。Kindle、Apple Booksなどで読める。
文字列とバイト（String / Bytes）
人が読む文字（文字列）と機械が保存する0と1（バイト）は異なる形式だ。両者を行き来するときは変換（エンコーディング）が必要。.encode("utf-8")がその変換だ。
消去法（Elimination） 可能な原因を一つずつ排除しながら本当の原因にたどり着く方法。コードを読めない人がデバッグで使える最も強力な道具。直感で原因を絞れないなら、一つずつ消して残せばいい。
ビルド成功 ≠ 結果正常 ビルドが成功したということは「作る過程に致命的なエラーがなかった」という意味であって、「作られた成果物の内容が正しい」という保証ではない。この二つを区別することが、このエピソードの核心的な教訓だ。
ホットフィックス（Hotfix） 運用中のサービスの緊急修正。この事件にはホットフィックスが十度あり、七度目が真犯人だった。