概要

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日ぶっ続けで作業されたことがあって、それは流石に勘弁してほしいと思った。

インストール数の増加とGPT-6 Astraの登場など (9/13追記)

2ヶ月空いたのでまた状況を記録しておきたい。まず、npmのインストール数と、GitHubのstarsが伸びてきた。npmの方は直近週間インストール数が60,000、GitHubのstarは790になっている。線形に伸びてきたというよりは、2回跳ねたタイミングがあって、それはどちらもHacker Newsに取り上げられたのがきっかけだった。

https://news.ycombinator.com/item?id=48436863

https://news.ycombinator.com/item?id=49523361

一回目は実は6月で、割と否定的意見の方が多かった。（中には「It's 100% hallucinated.」のような辛辣なものも。）正直その頃は自分の中でもとりあえず世に出してみたという側面の方が大きく、まだまだ描画品質に多く問題を抱えているのは認識していたため、そういった外部の評価もやむなしという感じだった。それに、これが生成AIで取り組むべき筋の良い課題だというところには自信があって、需要も絶対にあると考えていたので、全く気にも掛からなかった。で、2回目に取り上げられたのが9月だった。実はその間に、ちらほらとこのライブラリに注目してくれた人たちがいて、GitHubでissueやPRもぽつぽつ来るようになり、それを起点に改善も進んできていたタイミングだった。そういうこともあって、この時に付いていたコメントは6月とは一転して、好意的な意見が多かったと思う。その結果、npmの週間インストール数が一気に2万から4万くらいに、GitHubのstar数も200くらい伸びたと記憶している。また、それをきっかけにか、issueやらPRを出してくれる人もさらに増えてきており、少しずつ認知と利用者が増えてきているのかなと感じるところである。サンプル提供を伴う描画不具合の報告はとてもありがたく、OSSはこうして磨かれていくのだなと体感できたことも印象的だった。

というのは自分のライブラリの話で、それとは別に、この期間、色々とゴール設定の近いプロジェクトが出てきていることを認識する機会があった。どれも大なり小なり生成AIを使ったvibe?コーディングでOOXMLを扱えるソフトウェアを作ろうとしており、やはりこの分野の需要の高さを感じると同時に、それぞれ微妙にスコープが異なっており、同じゴール、同じツールで取り組むにしても、このような差が出てくるのだなというのが面白かった。少し脇道に逸れるが、OOXMLを扱うソフトウェアをAIで実装するの、本当に良い課題設定だったと思っていて、それは前にも書いたが、仕様書が公開されており仕様がほぼ枯れていること、Officeという正解出力が存在していること、それを実現するOSSが数十年にわたって出てきていないことなどがその理由である。たとえばWebブラウザなんかも仕様書が公開されていて、それを実装したブラウザが世に出ているという点では一見状況が似ているように見えるが、Webの仕様は今後も枯れることはないし、そもそも無料でChromeやFirefoxのような素晴らしいブラウザが手に入ることを考えると、自前のブラウザを”AIを使って”実装することは、自分にとってはエンジニアの技術的興味を満たす以外にやる理由があまり見当たらない。生成AIのベンチマークとしてやるにしても、その成果物を実際に求めている人がいるという点において、タスクの意義は全く異なるだろうと考えている。（もちろんAIを使ったブラウザ実装も、個人に帰属する意義は大いにあると思っていて、そこを腐す意図は全くないというのは一応保険として書いておく。）それで話を戻すと、生成AIを使ったOOXML関連のプロジェクトがいくつか立ち上がってきており、スコープがそれぞれ微妙に異なっていることがわかった。自分の場合は責任範囲を限定するために、プロジェクトのスコープを表示のみに明確に絞っており、その中でいかに妥当に（ブラウザとデスクトップのOfficeは原理的に同等になり得ない部分があるので、正確に、ではなく、妥当に、と書く）表示できるかを突き詰めている。READMEにも書いたが、どうしても編集に手を出すと実装スコープが広がり、複雑な依存関係を持つデータを扱うときにデータを破損させる恐れがある（そしてそれを自分はとてもじゃないがVibeで修正しきる自信がない）ので、最悪バグがあっても影響度を限定できる（ユーザーが異常に気づけうる）表示に絞り、編集はキッパリ切り捨てたのだった。（あと、ついでに書くと自分は編集までやるならMicrosoft 365使えばいいじゃん、と思っている節がある。）でも、世に今出てきているものは、自分が知る限りどれも編集をスコープに含めており、個人的にはその野心的なゴールに驚くと同時に、どこかで破綻するのではないかという心配も、部外者ながら多少抱きつつ経過を観察している。また、そういったライブラリは、今のところ、自分のライブラリに比べてそもそも表示品質で劣っており（派手にレイアウトが破綻したり、そもそも表示できないファイルがあることを確認している）、これだと適用できる先は相当限られるのでは？と感じているのが正直なところである。やはりこの分野、先に書いたようにいかにバリエーション豊富なサンプル、もっと良いのは表示が壊れるサンプルをいかに効率よく集められるかが肝で、そのためにはユーザー数を先に確保する必要があるんじゃないだろうか。まあ自分のライブラリ含め、どういう結末になるのかは、今のAIの進歩スピードを踏まえると全く見当もつかないが。ただ、生成AIによってソフトウェアエンジニア職は焼き尽くされる、という説が共通認識になりつつある昨今、確かに数的には相当とうたされるのだろうが、何かこの辺りの差に、人に残る価値が見出せるのではないかと考えたりしている。

だいぶ長くなってきたが、最後、9月3日、GPT-6 Astraがリリースされた。いつもの如く自分は自分の納得のために最上位モデルを利用する、という方針のもと、難しいタスクにAstraを当てるようにし始めた。正直Solの時点で全く不満がなかったので、このタスクにおいてはもはやモデル性能はカンストしていて上位モデルを利用する意味がないようにも感じるが、一応利用できるものは使っておこうということでそうしている。今のところ、このタスクにおいてはAstra単にトークン消費が多いだけで、何か素晴らしいことをしてくれた感覚はない。

追記の終わりに。この記事のタイトル、Claudeで、と書いているが、実態として現状はGPTになってしまったなというのを、最近少し気にし始めている。なんか一時期はAnthropicすげー、OpenAIオワコン、みたいな風潮だったのが、すっかりOpenAIがモデル性能もコスパもAnthropicを凌駕してしまって（それは世間のコンセンサスとしても）、つくづく先の読めない世界だなと感じる。あ、あと、ちなみにこの記事は全部人間が書いています。そういうポリシーです。これは今後もそうする予定。