【ITニュース解説】The same one-line table-parsing bug turned up in five separate tools. I fixed it four times.

ITシステムを開発する上で、私たちが日常的に扱うデータは様々な形式で存在している。その中でも、情報を整理して表現するためによく使われるのが「テーブル」（表）だ。多くのITツールやシステムは、これらのテーブルから必要な情報を読み取り、処理する機能を持っている。この「読み取り、解析する」ことをプログラミングの世界では「パース」と呼ぶ。一見単純に見えるパース処理だが、実は思わぬ落とし穴が潜んでいる場合がある。

今回のニュース記事は、Markdown形式で書かれたテーブルのパース処理に潜んでいた、ある共通のバグと、その解決に至るまでの経緯、そしてそこから得られた重要な教訓について語っている。Markdownは、シンプルながらも文書構造を記述できる軽量なマークアップ言語で、多くの開発現場でドキュメント作成に使われている。テーブルもMarkdownの記法の一つで、縦棒「|」を使ってセルを区切り、行を表現する。

記事で問題となったのは、この「|」の扱いだった。一般的なテーブル行をパースする際、プログラムは「|」を見つけるたびに、それをセルの区切りとして文字列を分割していく。例えば、「A | B | C」という行があれば、プログラムは「A」「B」「C」という三つのセルを認識する。しかし、問題は「セルの中に『|』が含まれる場合」に発生した。Markdownの記法では、セルの中に特殊な意味を持つ文字（ここでは「|」）を含めたい場合、「\|」のようにバックスラッシュ「\」を使ってその文字を「エスケープ」する。エスケープされた文字は、特殊な意味ではなく、単なる文字として扱われる。つまり、「\|」と書かれた「|」は、セルの区切りではなく、セルの中身の一部として解釈されるべきなのだ。

ところが、多くのツールで使われていたテーブルパース処理のコードは、非常にシンプルだった。それは、受け取った行の文字列を、単に「|」という文字で分割するだけのものだ。「const cells = line.split('|').slice(1, -1).map((s) => s.trim());」という一行のコードは、エスケープされた「\|」の存在を考慮していなかった。そのため、例えば「| E0 | the admitted set | N_t := {x \| E(x,t) = true} |」という行があった場合、最後のセルに含まれる「\|」が、本来の「|」と同様にセルの区切りと誤解釈されてしまい、一つのセルが複数のセルに「割れて」しまう事態が発生した。これにより、意図しない数のセルが生成され、テーブルの構造が崩れてしまったのだ。

このバグが特に厄介だったのは、その症状の現れ方だ。システムは「テーブルのパースに失敗しました」という直接的なエラーメッセージを出すことはなかった。代わりに報告されたのは、「この定義は未検証です」といった、システムが扱っている「データの内容」に関する、あたかも「データ自体がおかしい」かのようなメッセージだった。これは、パースの失敗によって、テーブルの列がずれてしまい、本来あるべき情報が入るはずの列に別の情報が入ってしまったために起こった。例えば、ある列が「定義が検証済みかどうか」を示す情報を持つべきだったのに、パーサーの誤動作によって別の情報が入ってしまい、それを読み取ったシステムは「未検証」と判断してしまったのだ。つまり、パーサーの失敗という「読み取り方の問題」が、データ自体が間違っているかのような「内容の問題」として現れたわけである。

さらに問題は、この同じ種類のバグが、複数の異なるツールで何度も繰り返し発見されたことだ。このプロジェクトには、Markdownテーブルを読み取るツールがいくつも存在していたが、それらのツールはそれぞれ独立して開発・修正されてきた。以前に同じようなバグを発見した開発者は、目の前のツールを修正して問題が解決したため、そこで作業を終えていた。これは、その場しのぎとしては合理的な行動に見えるが、システム全体として見ると、根本的な解決には至っていなかったため、別のツールで同じバグが再発し続けていたのだ。誰もが「テーブルを読み取るツールがいくつあるのか」という全体像を把握していなかったことが、この再発の連鎖を招いていた。

最終的に、この問題に終止符を打った解決策は、単に「より賢いパース処理のコードを書く」だけではなかった。それは、まず「テーブルをパースする全てのツールを明確にリストアップし、管理する」という「インベントリ（目録、台帳）の作成」だった。システムに存在する全てのテーブル読み取りツールを洗い出し、そのリストと実際に存在するツールの数が一致するかを自動的にチェックする仕組みが導入された。新しいツールがテーブルを読み取る機能を実装した場合、必ずこのリストに登録する必要があり、登録を忘れるとシステムが警告を出すようになった。これにより、どのツールがテーブルをパースしているのか、という全体像が常に明確に保たれるようになったのだ。

そして、このリストアップされた全てのツールに対して、パース処理が正しく行われるかを確認するための厳密なテストが導入された。「フィクスチャ」と呼ばれるテスト用の特殊なデータが用意され、そこにはエスケープされた「\|」が含まれるテーブルの行だけでなく、もう一つの巧妙な罠が仕掛けられていた。それは、見た目はほとんど同じだが、コンピュータ内部での表現が全く異なる文字の存在だ。具体的には、通常の縦棒「|」（U+007CというUnicode文字）と、数学記号の「⁝」（U+2223というUnicode文字、DIVIDES文字）だ。モノスペースフォント（全ての文字幅が同じフォント）では、この二つの文字はほとんど見分けがつかないほど似ている。しかし、コンピュータにとっては全く別の文字であるため、エスケープされた「\|」の処理には対応できたとしても、この「似て非なる文字」を正しく扱えないパーサーは、依然としてテーブルの構造を誤って解釈してしまう可能性がある。この両方のケースを網羅したテストによって、より堅牢なパース処理が実現された。

この経験から得られた教訓は二つある。一つは、「同じ種類のバグが二度以上発生した場合、それは単なるバグではなく、インベントリの欠如である」ということだ。つまり、個々のバグ修正に時間を費やすのではなく、システム全体の中で同じような問題が発生しうる場所が他にないか、その全体像を把握するための仕組みが不足しているのではないか、と考えるべきである。表面的な修正を繰り返すよりも、根本原因である「見える化」の不足を解消することが、再発防止には不可欠だ。

もう一つは、「パース処理の失敗は、データの内容が間違っているかのように現れることが多い」という点だ。システムが突然「データがおかしい」と報告してきた場合、昨日まで問題なかったデータ自体を疑う前に、まずそのデータを読み取ったり、加工したりしているパーサーなどの処理部分に問題がないかを確認することが重要だ。パーサーが誤った情報を生成したり、既存の情報を誤って解釈したりすると、その後の処理は「ゴミ」を受け取ったことを正直に報告する。しかし、その報告は「データのゴミ」について語るものであり、「パーサーがゴミを生成した」とは直接教えてくれないため、原因特定には注意が必要となる。

システムエンジニアを目指す上で、このような問題は避けられない。複雑なシステム開発では、今回のような見落としや、予期せぬ挙動は常に発生しうる。しかし、そこから何を学んで、どう改善していくかが、良いシステムを構築し、維持していくために非常に重要だ。特に、システムの全体像を把握し、問題を根本から解決しようとする姿勢、そしてエラー報告の裏に隠された真の原因を見抜く洞察力は、今後のエンジニア人生において大きな武器となるだろう。