概要

ClaudeでMicrosoft Officeのサポートするファイル拡張子のうち、Office Open XML (OOXML) として仕様が標準化されている3つ、docx, xlsx, pptxの表示機能を提供するJSのライブラリを作った。

経緯

コーディングにおけるAI活用の文脈だと、一昨年くらいからGitHub CopilotやChatGPTは活用していたものの、所謂バイブコーディングというものに関しては、Clineが一時期盛り上がっていたのを横目に見ていたくらいで、手を出さないままで来ていた。昨年の夏頃、始めてChatGPT以外のAIエージェントとしてClaudeを触る機会があった。これはMCPに興味が湧いたのがきっかけで、当時調べたところ、無料で使えるエージェントで、ローカルに立てた自前のMCPとの接続をサポートしていたのがClaudeだけだったからである。そのときは、エージェントとしての性能は特に可もなく不可もなくで、本当にMCPという抽象化レイヤーを備えていることだけが、自分のアプリと生成AIをつなぐ架け橋として、魅力的に映った記憶がある。で、その後はまたしばらく空いて、秋になり、そうすると色々なところから、Claude Codeがすごい、という話がちらほら聞こえ始めた。MCPの件で多少Claudeに親近感もあり、今度は試しに課金して実際に触り始めることにした。

それで最初に作ったのが下の「Stencil Canvas」というWebアプリである。これはユーザーのブラウザ上で完結して、画像をステンシル（孔版印刷）で印刷したような見た目に変換してくれるアプリだ。

https://yukiyokotani.github.io/stencil-canvas/

本題から逸れるのでここでは特に触れないが、実装時にエラーでコケることなど皆無で、shader実装含めトントン拍子で要望を実現してくれることに心底驚いた。

その様子を見て、やりたくなったのがこの記事の本題であるOfficeファイルのViewerライブラリの実装である。実はこれも以前欲しくなって調べたことがあるのだが、これまでに世に出ているOfficeファイルのViewrはOSSの範囲だと、Word, Excel, PowerPointのどれか一つだけをターゲットにしているものがほとんどで、また、描画のクオリティもお世辞にも良いとは言えないものばかりだった。有料ライセンスのライブラリになると描画のクオリティはグッと上がり、編集もできるものが出てきたりするのだが、当然ライセンス料は相応にかかり、そもそも自分はそこまで機能的にリッチなものが欲しいわけではなかった（そこまでやりたいならそもそも公式のMicrosoft 365でやるわ、というね…）ということもあって、どうも丁度よいものがなかったのである。自分が欲しかったのは純粋にOfficeファイルのバイナリをそれなりに忠実に表示（プレビュー）すること、ただそれだけだった。

この調べ物をしていたときに、Officeのファイルの内、docx, xlsx, pptxについては仕様がOOXMLとして標準化されて公開されていることを知った。Claudeで遊んで、適当な思いつきレベルの要望をどんどん実現してくれるところまで生成AIが進化した今、仕様の存在するdocx, xlsx, pptxのViewerの実装をClaudeにお願いすることはまさにやればできるようなレベルの話に思えた。ちょうどClaude周りで色々キャッチアップをしたいタイミングだったのもあり、ClaudeのプランをMaxにアップグレードして取り組むことにした。

できたもの

そうしてできたものが下の2つである。1つ目はJS (TS) のライブラリで、parser部分は速度面を重視してRust (WebAssemblyにビルド)　、renderer部分はフレームワーク問わず利用できるようにプレーンなTSで実装をしている。描画品質はそれなりにこだわっているので、Office公式と比較して完全ではないが、それでもすでにかなりいい線まで行っている自負がある。（まあ 実装したのはClaudeなんだけど）

2つ目はVSCode拡張で、1つ目のJSライブラリを使ってVSCodeのWebViewでOfficeファイルを表示するものである。このVSCode拡張はおまけとしてオプションでdocx, xlsx, pptxのparserをベースに、ファイルの読み取りツールを提供するMCPを提供する。OfficeファイルをClaudeだったり、GitHub Copilotに食わせてコーディングしたいときに、何もないとエージェントは書き捨てのPythonスクリプトを書いて、ファイルをunzipし、xmlをパースして中身を読み取るのだが、これが毎回行われるのはとても無駄に思えたので、個人的にぜひ改善したかった。刺さる人には刺さるんじゃないかと思う。

https://www.npmjs.com/package/@silurus/ooxml

https://marketplace.visualstudio.com/items?itemName=silurus.office-open-xml-viewer

実装の思い出

実装をしたのは完全にClaudeで、今回自分は一行たりともコードを書いていないが、他の部分でいくらか自分（人間）にしかできない貢献をしたので思い出として書き残しておきたいと思う。ただ、うまくやって権限も与えればもしかしたら全部エージェントで乗り越えられたのかもしれない。

正解データの提供

これは一番大きな話で、自分も実際にClaudeにやらせてみてわかったことであるが、OOXMLの仕様書はOfficeの表示を再現するという点においては完全ではない。Claudeからの返信メッセージで知ったが、いくらか実装側に任せられているものがあり、そこは何を正とするか（今回で言えばWord, Excel, PowerPointがどう表示しているか）をアドホックに与えていかないといけなかった。そこで、自分はまず初めにデモデータとなるOfficeファイルをいくつか用意し、docx, pptxについてはそこからせっせとページorスライドを画像出力してClaudeにVRTを組ませることにした。ただ、この方法は結果的にはほぼうまくいかなかった。VRTは前回断面と比較してレイアウトのリグレッションを検知するのには役に立つが、一からレイアウトを組む局面において利用しても、正解とのピクセル差分が大きすぎて、また機械には何が間違っているのか（要素がないのか、見た目が違うのか、など）の解釈が難しすぎて、精度改善には一向に寄与しなかった。そこで、docx, pptxについてはpdf出力し、これを正解として与える方式に舵を切った。正解pdfはClaudeによって良しなにpdf.js等でパースされていたようであるが、これによって何の要素がどの座標に描かれるべきか、エージェントが正確に把握できるようになり、あとはそれがOOXMLのどの仕様に基づくものなのかを適宜紐解いて、実装につなげてくれた。これで描画クオリティは大きく上がり、ベースライン実装を完成させることができた。現状は、それでもまだポツポツと存在する差異について、人の目で一つ一つ指摘しながら改善を進めているフェーズである。なお、xlsxについてはPDF出力だとそもそもページの概念との不整合により表示崩れが起きることから、当初より人の目で一つ一つ指摘して改善するという流れで実装を進めた。幸いExcelはセル番号でどこが違うかを伝えやすいこともあり、この方法でも割とスムーズに改善を進めることができたと思う。ピクセルベースのVRTも完全に捨てたわけではない。正解（Officeの出力）との差分を取ると先述の通り意味のある指標にならなかったが、自分の過去のレンダリング結果と比較するものと位置付けを変えて、これでリファクタリング前後のリグレッション検知に役立てている。

Claudeの使用制限管理

一番初めはシングルセッションでPlanモードでOpusとSonetを使い分けるという運用をしたが、それではMaxプランのセッションリミットを全く使い切れないことがわかり、次にこれをマルチセッションで実行するようにした。これはdocx, xlxs, pptxのparser, rendererのベースラインを整備するときにはかなり効率を上げてくれたが、結局途中から先に書いたような人の目での合わせ込みが必要になって、自分がボトルネックになった結果、シングルセッションに戻った。それでやっぱりセッションリミットを使い切れなくなったと、だんだん承認が面倒になってきたのもあって、今はOpusの自動モードですべてを流している。これをやると、Max (5x) の直列実行でも簡単にセッション制限、週次制限にかかるようになったが、使い切れないよりはいいだろうということで良しとしている。結果的に色々試せて、$100のプランでできることへの肌感を得られたのがとりあえず良かった。

歴史の転換点？ (6/13追記)

2026/6/9 Claude Fable 5が使えるようになった。早速このライブラリの開発にも利用を開始した。最初単にモデルだけFableに切り替えて、シングルセッションでこれまでの実装の全体レビューを依頼したら、大量にサブエージェントが起動して、しかもどうやらそれらが全部Fableで立ち上がったみたいで、15~20分くらいで5時間のセッションリミットに到達してしまった。これまではOpus 4.8のシングルセッションで自分がつきっきりで指示を出しつづけたらリミットに達するかどうかくらいだったので、びっくりした。GitHub Copilot経由だとトークン消費はOpusの2倍と出ていたからこんなにトークン消費が激しいとは思わなかった。で、次のセッションからは計画はFable、実行はOpus 4.8という構成にした。これでとりあえずこれまでに近い使用感に戻ることができた。自分はFableの実力を評価できるほどの実力を持ち合わせていないけれど、それでもOpus 4.8の実装（いろいろな紆余曲折があったから当然負債の蓄積はあっただろうけど）の問題（それも真っ当な設計不備）をあっさりと短時間で指摘してきたこと、途中全然止まらずに依頼を（多分指示に欠けているコンテキストも補って）完遂しきったことあたりから、賢さの片鱗は感じることができた。ただ、GUIを見る「目」は正直まだ微妙で、一度Canvas描画における不具合をスクリーンショット＋言葉で指摘する機会があったが、とんでもない勘違いで直す必要もないところに手を加えて、真の問題にしばらくたどり着けないということがあった。人間に同じ情報を与えたら（それが熟練者でなくても）間違いなく一発で問題が通じただろうから、そのへんはまだまだなのだなと思った。

そういったレビューを追えて、次の大仕事としてビューワーのOffscreenCavas対応の設計、計画を依頼し、6/12の深夜ちょうどそれが完了して週次リミットにかかってしまった。自分は翌6/13の15時に週次リミットリセットなので、またそこで作業を再開しようと思っていた矢先、6/13午前、突如アメリカ政府からFableに対して輸出規制がかかる（アメリカ国外ではFableが使えなくなるという話だが、一旦世界中のユーザーがFableを使えない状態になる）という出来事が起きた。幸い先程の自分のタスクはOpusで実装させる前提で詳細な計画までできていたので、こちらに関しては特に問題なく終えることができたが、ニュースを見ていると今後のタスクにはFableが使えなさそうな気配が漂っている。自分の今進めている設計・実装がFableでないとだめなのかと言われるとだめとも言い切れないところではあるが、やっぱりFableを使ったあとだと、そして先日FableがOpusの実装にたくさん指摘をつけたあとだと、どうもOpusが出してきたものがそれでいいのだろうか、と疑心暗鬼にはなってしまう。Fableだと、Falbeにやらせてだめらな仕方ないか、みたいな諦めがつくところが、ただ仕事を横流しするだけの自分にとってはとても気楽だった。6/13は一日とりあえずOpusでタスクを流したが、頭の片隅でFableがいないことを寂しく思う自分がいたのであった。

※Fableはその後7/1に一部タスクをOpus 4.8にfallbackさせる仕様で再公開された。

GPT-5.6 Solの登場 (8/1追記)

2026/7/9 OpenAIからGPT-5.6 Solが一般公開された。7/1にFableが再公開されてから引き続きFable+Opusで安定した開発が回ってたので、若干の不安と躊躇はあったが、恐る恐る手を出す。ライブラリの細かい不具合修正から使い始めたが、何も言わずともTDDで問題を再現させて解消に持っていくという堅実な進め方。課題解決までのスピードも、最終的なアウトプットの品質も全く問題なく、これは実装にかなり使えるぞという印象を持った。その後Fableと組ませて、設計タスクなども任せたが、Fableとの議論でも勝つことが多く、かなり優秀なモデルであることがわかった。

エージェント間のヒエラルキーについて。作業を進める中で、Fableの下でSolを使うか、Solの下でFableを使うかは迷ったが、Fableに実装させるとトークン消費が早く5hリミットや週間リミットに直ぐ到達することもあり、Solメインで設計から実装まで一気通貫で行い、要所要所のレビューとアドバイザーでFableを利用するという運用で安定した。リリース後のキャンペーンとして5hリミットの撤廃と、Tiboによる頻繁な週間リミットのリセットがあり、あれだけClaudeに依存していたのが嘘かのように、Codexの利用に傾いていった。特にTiboの軽いトーンのポストで毎日のようにアナウンスされるリミットリセットは狂気じみてもいたが、利用者視点ではありがたいことこの上無かった。「SAINT TIBO / GIVER OF TOKENS RESETER OF LIMITS」のミームも発生し、皆がXでリセットを乞うような事態になっていた。

そんなこんなでClaudeのOpus 4.8は利用する機会が全くなくなり、しばらくしてOpus 5も出たがこれも結局あまり使わないまま、というのが現状である。Opus 5ではもちろん進歩も感じたが（というか4.8は壊れていたから進歩も何もないが…）、結局実装担当としてみた時に、Solから乗り換えたくなるような何かはなかった。やはりフロンティアモデルでどこまでも走れるというのはとてつもなく快適なのである。

一点、Solは巷でも指摘されている通り、オーバーエンジニアリングするというか、考えすぎる癖があって、自分も一度大規模なリファクタでgoalを設定したら約3日ぶっ続けで作業されたことがあって、それは流石に勘弁してほしいと思った。