業務システムの要件定義には、ほぼ確実に「一覧画面のデータをExcelで落としたい」が入ります。CSVでいいですかと聞くと、だいたい駄目だと言われます。列幅が揃っていない、日付が数値になる、取引先にそのまま送れない。Excelで落とすというのは、多くの場合「そのまま印刷して回覧できる状態で落とす」という意味です。
この一行を実装するときに入れるライブラリの選定が、ここ数年でやりにくくなっています。
定番だったものが、普通には入らなくなっている
JavaScript でExcelファイルを扱うライブラリとして長く定番だったのが SheetJS（パッケージ名 xlsx）です。読み書きの対応範囲が広く、日本語の情報も多い。まず候補に挙がるのはこれでした。
ところが SheetJS は公開npmレジストリでの配布をやめ、自社CDN（cdn.sheetjs.com）での配布に移しています。**結果として、npm 上の xlsx は 0.18.5 で止まっており、数年前の公開のままです。**セキュリティ上の修正を含む更新は CDN 側の新しいバージョンにあり、npm から普通に npm install xlsx した場合は古いコードが入ります。
これが実務でどう出るかというと、依存関係の脆弱性スキャンで引っかかったときに困ります。「更新してください」というアラートに対して、レジストリ上には更新先がない。CDNのtarball URLを直接指定する形でインストールし直すことになりますが、その方式は社内のプロキシ設定やCI環境、監査の仕組みと衝突しがちです。技術的には解決できても、承認の手続きが一手増える。受託の現場では、この一手が地味に重くのしかかります。
もう一つの定番である ExcelJS を選ぶ場合も、依存関係のツリーがそれなりの大きさになる点は変わりません。Excel出力という「業務としては1機能」のために、監査対象のパッケージが数十増える構造です。
依存ゼロで読み書きできる選択肢
2026年8月、hucre というライブラリが v1.0.0 に到達しました。純粋な TypeScript で書かれた依存パッケージゼロのスプレッドシートエンジンで、XLSX・CSV・ODS の読み書きに対応します。セルの数式を評価する計算エンジンを内蔵しており、Excel の一般的な関数を扱えます。Node.js、Bun、Deno、ブラウザのいずれでも動作します。
選定の観点として効くのは、機能よりも監査対象が1つで済むことのほうです。依存ゼロというのは、脆弱性スキャンで拾われる範囲が自分たちの選んだ1パッケージに閉じるということで、サプライチェーン側のリスク評価が単純になります。npm のインストール時スクリプトを経路とした攻撃が現実の脅威として扱われるようになった今、依存の数そのものが判断材料になります。この文脈はパッケージマネージャ側からの対策でも扱いました。
一方で、v1.0 に到達したばかりのライブラリであることは差し引く必要があります。公開APIの安定を約束するのが v1 の意味であって、実績が積み上がったことの証明ではありません。5年運用する業務システムの基盤に据えるかどうかは、次の節の切り分けで決まります。
何を出したいのかで、必要なものが変わる
「Excelで落とす」という要件は、実際には性質の違う3つが同じ言葉で呼ばれています。ここを分けないと、ライブラリの選定は決まりません。
| 要件の実体 | 必要なこと | 選定の重さ |
|---|---|---|
| データ交換（他システムへの取り込み） | 値が正しく入っていること。見た目は不問 | 軽い。CSVでも足りる場合がある |
| 一覧のダウンロード（利用者が加工する） | 型が崩れないこと。日付が日付として入る | 中。依存の少ないもので足りる |
| 帳票（そのまま印刷・送付する） | 罫線、セル結合、印刷範囲、ヘッダーフッター | 重い。表現力の実績が要る |
発注者が「Excelで」と言うとき、頭にあるのは3行目であることが多い。そして3行目を実装しようとした瞬間に、ライブラリの表現力の差が効いてきます。罫線のスタイル、結合セル、列幅の自動調整、印刷時の改ページ位置。ここまで求められるなら、実績のある選択肢を選ぶか、そもそもExcelではなくPDFで出す設計に持ち込むかを検討したほうが早い場合があります。
逆に1行目と2行目であれば、依存ゼロの選択肢は十分に現実的です。むしろ、たかがデータ落としのために大きな依存ツリーを抱え込むほうが、運用期間全体で見たときのコストは高くつきます。
実装場所をどこにするか
もう一つ、依存ゼロでブラウザでも動くライブラリが出てきたことで判断が変わる点があります。Excel生成をサーバー側でやるか、ブラウザ側でやるかです。
ブラウザ側で生成すると、サーバーの負荷とメモリを使いません。数万行の帳票を同時に複数人が落とすような業務では、この差が効きます。ただし、生成に必要なデータを全部ブラウザに送ることになるため、画面に表示していない列や、権限で見せていないはずの項目まで渡していないかの確認が必要です。個人情報を含む一覧では、この確認を飛ばすと事故になります。
サーバー側で生成するなら、出力内容を権限で絞り込んだ状態で作れます。監査ログにも「誰が何を落としたか」を残しやすい。業務システムでは、この記録が残ることのほうが性能より重要なケースが多い。判断は性能ではなく、扱うデータの機微度から入ってください。
そもそもExcelに落とす必要があるのか
最後に、要件そのものを疑う枠を置いておきます。「Excelで落とす」が要件に入る理由の多くは、システムの中でその集計ができないからです。落としたExcelで関数を組んで集計し、それを別の人がまた加工する。この連鎖が起きているなら、実装すべきはExcel出力ではなく、その集計そのものかもしれません。
Excel運用をどこまで残し、どこからシステム側に取り込むかの切り分けはExcel運用をいつシステム化に切り替えるかにまとめています。既存のExcel資産をスプレッドシート側に寄せる場合の実務はテーブルとピボットを作り直さずに移すを参照してください。
次にやること
Excel出力の要件が上がってきたら、上の表のどれに当たるかを発注者に確認してください。「印刷して取引先に渡しますか」と聞けば、たいてい即答が返ってきます。ここが決まると、ライブラリ選定は自動的に絞れます。
すでに xlsx を使っているシステムを保守しているなら、インストール元が npm レジストリなのかCDNなのかを確認してください。npm から入っているなら、そのバージョンは更新が止まった系列です。すぐ危険という話ではありませんが、脆弱性の指摘を受けたときに動けない構造になっていることは把握しておく必要があります。
既存システムの依存関係の棚卸しや、帳票・出力機能の設計方針については、グリームハブの開発・AI・自動化のご相談で承っています。出力の用途とデータの機微度によって適切な作りは変わるため、個別にご相談ください。お問い合わせからどうぞ。
