ooxml-validatorというnpmモジュールをつくった
生成AIが普及して以降、PowerPointのスライドを自動で生成させようというユースケースをよく見かけるようになった。python-pptxやpptxgenjsのようなライブラリを使うのはもちろん、pptxファイルを始めとするOOXML（.pptx, .docx, .xlsxみたいなOfficeファイル）はどれもXMLファイルをzip圧縮しただけのものなので直接ファイルを操作することもできる。
ただこのOOXML、zip＋XMLという構造は自体は単純なものの、その内部仕様は異様に複雑で壊れやすく、適当にXMLを書くだけではすんなり読み込めるファイルが作れなかったりする。出力されたpptxファイルをPowerPointで開いてみると「破損しています、修復しますか？」といったダイアログが出てくる様子は見慣れた光景だ。問題はこの壊れたファイルの一体どこがinvalidなのかを調べるのは簡単ではないという点にある。前述したように巨大で複雑なXML仕様ではそう簡単に破損したポイントを特定し、修正するのはほとんど不可能だった。
PowerPointやWordには破損したファイルを自動で修復するための仕組みが存在するものの、それがどこまで修復可能であるかなどは公開されておらず、また、修復結果がどうなるのかも予測できない。さらにそれらのOfficeアプリそのものを開かない限り破損しているかどうかもわからないので、普通のCI上で壊れたOOXMLを検知することすらできなかった。
一応、既存の検証方法としてOpen XML SDKという公式のC#ライブラリが存在しており、これを使えばOOXMLの標準仕様（ECMA-376 / ISO/IEC 29500）に準拠しているかを検証することができる。これ自体はMicrosoft Office自体の開発にも使われているため、事実上世界で最も正確なOOXMLバリデータとなっていた。しかしこれには当然.NETのビルド環境が必要で、さらに検証用のプログラムを書かなければ使えなかったのであまり気軽なものではなかった。
なので単一バイナリしたライブラリをnpm配布するようにし、npm installだけでOOXMLを検証できるようにしたのがooxml-validatorである。各環境向けのバイナリはGitHub Actionsのmatrix buildでself-containedのバイナリをビルドするだけでよく、それをGitHub Releasesに置くだけで終わる。それをnpm scriptsのpostinstallで適切なバイナリをダウンロードすれば良いだけなので導入コストはだいぶ下がる。
Officeを起動せずにファイル構造の破損が捉えられるので、OOXML生成のデバッグ処理はだいぶ楽になると思う。これが役に立つという人は、まぁだいぶ限られている気がするが、誰かの役にたったらうれしい。