office-open-xml-viewer: Rust + WASM で DOCX・XLSX・PPTX を browser 上の Canvas に描く

Office 文書 preview が必要になると、今でもまず思い浮かぶのは「server 側で PDF に変換する」か、「外部 preview service を埋め込む」か、という構成です。

このやり方は手早い反面、かなりはっきりした制約があります。

preview pipeline が server 変換に依存する;
大きい file や同時閲覧で cost が上がりやすい;
private document を外部 service に渡す設計になりやすい;
front-end 側は black box viewer を貼るだけで、rendering を自分で制御しにくい。

今日メモしておきたい yukiyokotani/office-open-xml-viewer は、そこを browser 側で解こうとしている project です。DOCX / XLSX / PPTX を browser 内で直接 parse・layout・render する方向を取り、parser は Rust 製で WebAssembly 化、描画は Canvas 2D API で行います。しかも完成済み viewer だけでなく、下層の document engine も公開しているので、自前 UI に組み込みやすいのが特徴です。

GitHub repository page と最新 release page を 2026-06-23 時点で見ると、この repository は 546 stars、16 forks、主要言語は TypeScript。作成日は 2026-04-18、公開上の最終更新日は 2026-06-23 です。license は MIT。最新 release は v0.66.0 で、公開日も 2026-06-23 です。

Project overview

項目	内容
Repository	yukiyokotani/office-open-xml-viewer
位置づけ	browser で DOCX / XLSX / PPTX を表示する front-end document viewer
Stars	546
Forks	16
主要言語	TypeScript
作成日	2026-04-18
最終更新日	2026-06-23
License	MIT
Latest release	v0.66.0
Release date	2026-06-23
Live demo	ooxml.silurus.dev

面白いのは「文書を開けるか」ではなく「front-end が rendering を握れるか」

この project の良さは、iframe 的な black box preview に留まらないところです。

README で示されている中核はかなり明快です。

parser は Rust + WebAssembly;
renderer は Canvas 2D API;
3 形式それぞれに headless engine がある;
caller 側が自分の canvas や UI に組み込める。

つまりこれは単なる document preview widget ではなく、front-end で再利用できる document rendering capability に近いです。

その結果、

独自の scroll view;
slide の thumbnail pane;
table / sheet の master-detail UI;
既存の workbench への埋め込み;

のような構成を自分で作りやすくなります。

knowledge base、approval system、internal drive、contract viewer、education platform のような product では、ここがかなり大きいです。

3 形式まとめて扱い、しかも viewer と engine を分けている

README の設計を見ると、@silurus/ooxml は単一 format の proof of concept ではありません。

公開されているのは：

DocxViewer
XlsxViewer
PptxViewer

だけではなく、

DocxDocument
XlsxWorkbook
PptxPresentation

のような下層 engine です。

ここが重要です。document preview 系の project は、見た目の component は用意されていても、少し custom UI を作りたくなると何も再利用できないことが多いです。

office-open-xml-viewer は、

まずすぐ使える viewer を出しつつ;
下では parse / render の entrypoint を残し;
必要なら UI だけ差し替えられる;

という構成になっています。

この分離は、試作にも本実装にも向いています。

重い rendering を main thread から逃がせるのが実務的

README の中で特に実務的だと思ったのが off-main-thread rendering です。

default では parse を worker に逃がし、render は main thread で行います。さらに mode: 'worker' を渡すと、parse だけでなく render も Web Worker 側で行い、main thread は ImageBitmap を受け取って表示するだけにできます。

Office document preview の現場でつらいのは、単に「表示できるか」ではなく、

page 切り替えで UI が固まる;
重い slide で scroll や input が鈍る;
複雑な workbook で tab 切り替えが重い;

といった体感速度です。

この project はそこに対して、

Worker;
OffscreenCanvas;
ImageBitmap;

を使った browser 的な解き方を用意しています。

README でも、worker mode は raw speed 最優先ではなく main thread の応答性を守るための mode だと説明されていて、このあたりの書き方もかなり誠実です。

難しいのは第一画面ではなく、Office 特有の細部だと分かっている

最新の v0.66.0 の release note を見ると、この project が本当に向き合っている難所が分かります。

今回の更新で触っているのは主に：

DOCX の continuous section と multi-column layout;
section をまたいだ header / footer の継承;
細い column での長い token の折り返し;
paragraph border と spacing の挙動;
EMF figure の rasterization。

Office 文書 rendering が厄介なのは、最初に文字や画像を出すところではなく、

section break;
page fill;
複数 column;
embedded graphics;
Word に近い layout behavior;

のような細部です。

そこを継続的に詰めているということは、この project が demo 段階から一歩進んで、実ファイルで困るところ に入り始めているということでもあります。

bundle size、equation、font まわりの現実もちゃんと扱っている

README で良いと思ったのは、機能の見せ方がかなり現実的なことです。

まず package は：

ESM-only;
docx / xlsx / pptx ごとの subpath import に対応;
OMML equation 向け math engine は別 entry;
必要なものだけ import すれば tree-shake しやすい;

という構成です。

さらに equation rendering についても、

MathJax + STIX Two Math を使う;
ただし opt-in;
import しなければ bundle に入らない;
worker mode では equation を描かない;

という制約と trade-off を先に明示しています。

この手の project で大事なのは「全部できる」と言うことより、何を読者が選べて、どこに cost があるか を見せることだと思います。その点でかなり分かりやすいです。

security / privacy の境界も比較的はっきりしている

document viewer は demo の派手さより、まず boundary が重要です。

README では次のような方針が書かれています。

source document の active content を DOM に注入せず、HTMLCanvasElement に描画する;
zip bomb 対策として archive entry の展開量に default cap を持つ;
telemetry や analytics を default では送らない;
useGoogleFonts を明示しない限り、外部 font request をしない;
XML parser は外部 entity を解決しない。

もちろん、untrusted file handling をこれだけで完全に片付けられるわけではありません。ただ、browser-side Office rendering を名乗る project として、典型的な懸念点を最初から意識しているのは大きいです。

境界も明確で、これは online Office editor ではない

この project の価値は、browser 上で Office を丸ごと再実装することではありません。重心はあくまで：

preview;
rendering;
embedding;
custom UI integration;

にあります。

なので向いているのは、

document preview;
front-end viewer;
internal platform への埋め込み;
slide / sheet の閲覧 UI;
自前の document experience 構築;

のような用途です。

逆に、

本格的な editing;
annotation collaboration;
desktop Office と完全一致する behavior;
すべての edge case feature の再現;

が必要なら、これは直接の置き換えではありません。

でも「Office 文書を browser front-end に安全寄りで持ち込み、自分の UI に載せたい」という要件にはかなり合っています。

なぜ追っておきたいのか

私がこの project を面白いと思うのは、単に DOCX / XLSX / PPTX が見られるからではありません。

browser 側で Office preview を扱いたい product は多いのに、front-end に統合しやすい形で parse と render を渡してくれる project は意外と少ない。

office-open-xml-viewer はそこに対して、

Rust + WASM で parser を持ち;
Canvas 2D で browser rendering を行い;
viewer と headless engine を分け;
worker mode で responsiveness を守り;
layout / equation / graphics / boundary を少しずつ詰めていく;

というかなり筋の通った道を選んでいます。

見た目だけの widget ではなく、front-end 文書基盤として育つ余地のある repository だと思います。

まとめ

yukiyokotani/office-open-xml-viewer の面白さは、「browser で Office file を開ける」ことだけではありません。Rust + WASM の parser、Canvas rendering、headless engine、worker mode、security-aware な初期設計まで含めて、front-end に統合できる document rendering capability を揃えようとしているところにあります。

DOCX、XLSX、PPTX を browser 製品に取り込みたいなら、この project はかなり見ておく価値があります。