TSV を XLSX に変換

シーケンサーのパイプライン、発現解析の表、注釈ファイル、機器のログ、検索コンソールの書き出し、広告プラットフォームのレポート——これらの多くはタブ区切りで出力され、ほかに選択肢がありません。遺伝子の説明や広告名、ページタイトルにはカンマがよく含まれるため、区切り文字にタブを選んだのは正しい判断です。

ただしこれは作業用のファイルではありません。列の型も、幅も、フリーズ枠も、次に起きることへの備えもありません。次に起きることとは、実際の分析が行われる Excel で開かれることです。この「開く」という一歩こそが危険で、この変換が置き換える部分です。

Excel がテキストを取り込むとき、値ごとに独自の解釈を適用します。その一部が、非常に広い網を張った日付解析です。`1-2` は 1 月 2 日になり、`MARCH1` や `SEPT1` は日付になり、`2/3` も日付になります。長い数字列は先頭のゼロを失い、非常に長いものは指数表記に書き換えられます。

これは噂ではありません。ゲノム学の論文の相当な割合で発生することが測定され、最終的には表計算ソフトを直すのではなく一部のヒト遺伝子の名前を改名することで対処されました。それがどれほど元に戻すのが難しいかを物語っています。元のテキストはすでに消えていて、セルには日付のシリアル値だけが残り、どんな文字がその値を生んだのかを示すものは何も残っていません。

この変換はタブ区切りファイルを読み、ワークブックを書き出すあいだ、Excel の日付解析を一度も実行しません。`1-2` は 4 文字の `1-2` のまま、`SEPT1` は `SEPT1` のまま、`2024-03-11` はその文字列のまま残ります。それぞれがセルに型付きのテキストとして書き込まれます。

この「型付き」という点が、防御を確実なものにしています。XLSX のセルは自分がどんな値を保持しているかを記録しているので、Excel がワークブックを開くとき、そこにあるものをそのまま表示し、再解析はしません。誤変換は型のないテキストの取り込み時にだけ起きるもので、ここで作られたワークブックが Excel に届く頃には、型のないテキストはもう残っていません。

これはすべてを無条件にテキスト扱いする仕組みではありません。それを装うのは正直ではないでしょう。単純な数値として読める値は数値のセルになり、件数や p 値、変化率、インプレッション数、費用といった列にはこちらのほうが望ましく、そのままソートや計算にかけられます。

その代償は先頭にゼロを持つコードにかかります。`00123` は 123 になり、プレート位置や社内参照番号がそのゼロに依存していると失われます。`1e5` のような指数表記の値は 100000 になります。こうした列が重要なら、対策は元のファイル側にあります。列を引用符付きで出力するか、非数値の接頭辞を付けたエクスポートならテキストとして残ります。コード列が数値セルなら右寄せ、テキストセルなら左寄せになるので、変換後にワークブックをひと目見れば、混在している列がないか確認できます。

`1-2` を守っているのと同じ拒否の姿勢が、本物の日付列にも及びます。`2024-03-11` は日付値ではなくテキストとして書かれ、時系列でのソートも Excel の中での日付計算も、そのままでは働きません。

これは意図した側の代償で、正しい向きの代償です。テキスト列を Excel の中で日付に変換するのは、確認した列に対して意識的に行う一手間で済みます——列を選び、データ、区切り位置、そこで日か月かどちらが先かを明示するだけです。誤って日付になってしまった列を、もとの識別子に戻すことはできません。日付である列にだけ少し手間をかけるほうが、日付でない列のいくつかがいつの間にか日付になっていたと後から気づくよりずっとましです。

タブ区切りファイルは 1 個の表を持つので、ワークブックも 1 個のシートを持ちます。名前はファイル名から拡張子を除いたもので、ワークシート名の上限である 31 文字に収まるよう切り詰められます。長い説明的な名前は拒否されるのではなく、切り詰められます。

ヘッダー行がシートの 1 行目になり、列を固定します。後続のすべての行はこのヘッダーを基準に読まれるため、途中で余分なフィールドを持つ行があっても、そのために新しい列は作られません。あふれた値は `__parsed_extra.0` という名前の列にまとめられ、これはシートがエクスポートの不揃いさを教えてくれているサインです。ヘッダーより少ないフィールドしかない行は、値がずれるのではなく空セルになります。ずれのほうが気づきにくい失敗なので、これは望ましい振る舞いです。

ワークシートはヘッダーを含めて 1,048,576 行、16,384 列まで保持できます。これはこの変換の制限ではなく、ファイル形式そのものの上限で、どんなツールもこれより大きなシートは書けません。

発現行列やイベントログ、キーワードの全件エクスポートはこの線を日常的に超えます。そのときの正しい答えは「もっと大きな変換ツールが必要だ」ではなく「表計算は適切な道具ではない」です。変換の前にフィルターや集計をかけるか、同じファイルを Parquet にして DuckDB や pandas で問い合わせるほうが、数百万行でも問題なく扱えます。

説明文や注釈の列に改行が含まれると、タブ区切りファイルの中では本当に危険です。行がそこで終わったと解釈され、以降の集計がすべてずれます。値に混ざったタブも同じように、その行以降に列を 1 個足す形で静かに事故を起こします。

ワークブックにはこの脆さがありません。セルの中の改行はただの改行、タブはただの文字として扱われます。タブ区切りのエクスポートがツールによって行数の食い違いを起こしていたなら、変換してみることは修正であると同時に診断にもなります。ワークブックの行数のほうが、テキストファイルの行数より信頼できます。

タブ区切りのパーサーとスプレッドシートの書き出しは、どちらもこのページの中で動きます。ファイルを運ぶ通信はないため、未公開の分析結果やクライアントの広告データ、患者と紐づいた表を第三者に開かせるために渡す必要がありません。

制限はプランではなくメモリーです。表全体を保持しながらワークブックを組み立てるため、数十メガバイトなら問題なく、数百メガバイトになるとブラウザータブが厳しくなり始めます。それはおおよそワークシートの行数の上限に達する頃合いとも重なります。

次の工程がスクリプトなら、そのまま残してください。R なら read.delim、pandas なら sep="\t" で読み込め、どちらも列の型を明示的に宣言でき、どんな変換より強い保証になります。ワークブックはそのパイプラインに何も付け加えず、差分を取る能力を奪います。

アーカイブとしても原本を残しておいてください。この変換は数値らしい値を数値として読むため、ワークブックはエクスポートのバイト単位の忠実な記録ではなく、列に何が入っていたかを巡る議論を最終的に裁定できるのは元のファイルだけです。繰り返し問い合わせる目的なら、同じ元ファイルから Parquet に変換するほうが向いています。