Launch HN: Vespper (YC F24) – SOTA Docx MCP

HNの皆さん、こんにちは！ Vespper（https://vespper.com）のDuduとTopazです。Vespperは、AIエージェントがWord文書を効率的に編集できるMCP（Model-Centric Platform）で、ファインチューニングされたモデルを搭載しています。現在、競合製品と比較して3倍高速、2倍安価で、より高精度です。製品の概要はこちらでご覧いただけます：https://youtu.be/odKxsgPjzzw 私たちは、製薬会社向けに1年間AI文書エディターを開発した後、この問題に取り組むことになりました。それ以前は、Topaz（私）はSnykでシニアSWEとして分散システムを開発し、DuduはViz.aiでディープラーニングエンジニアとして脳卒中検出のためのコンピュータビジョンモデルを構築していました。 私たちのエディターは、製薬会社が規制文書（例：CSR）を生成し、提出を迅速化するのを支援しました。当初、出力はMarkdownで、WYSIWYGエディターに表示されていました。しかし、ユーザーは独自のWordテンプレートで作業することを好みました。そこで問題が発生しました。 AIエージェントはWord文書の編集が得意ではありません。Word文書は、OOXML仕様に従った冗長なXMLファイルのZIPアーカイブです。たとえ「小さな」変更であっても、多くの手間が必要です。例えば、番号付きリストを追加するには、numbering.xmlに新しいIDを作成し、それをdocument.xmlにリンクする必要があります。文を太字にするには、それを3つ以上のrun要素に分割する必要があります。リストは延々と続きます。 これにより、ZIPファイルを直接（unzip + grep + sed）編集することはエージェントにとって悪い考えとなります。なぜなら、これらのメカニズムのために多くの時間とトークンを消費してしまうからです。 実際には、今日のツールは主に3つのカテゴリに分類されます。エージェントにpython-docxやOpen XML SDKのような低レベルライブラリに対してコードを書かせるか、意見のある編集ツール（SuperDoc、Office CLI、Adeuなど）を持つMCPを与えるか、あるいはpandoc/mammoth.jsのようなものでMarkdown/HTMLにラウンドトリップさせるかです。 どれも実際にはうまくいきません。最初の2つのカテゴリでは、エージェントはタスク自体ではなく、Wordのメカニズムにコンテキストを費やしてしまいます（MCPは学習すべき新しいDSLも導入します）。そして、3番目の方法は非常に多くの情報が失われます（pandoc/mammoth.jsなどは十分な忠実度を維持できません）。 直接的な経験から、これらの問題は下流タスクのパフォーマンスを低下させます。 エージェントに大きな文書を記入させようとしたところ、すぐに問題が発生しました。コンテキストウィンドウはすでに顧客データ（ファイル、ユーザーコンテキスト、グローバルルールなど）でいっぱいでしたが、エージェントは文書の探索と編集の失敗のデバッグにトークンと時間を費やしました。単一のCSR（臨床試験報告書）を記入するのに約50分かかり、結果は悪かったです（フィールド/セクションの欠落、スタイルの破損など）。Harvey.aiのチームも同様の結論に達しました：https://www.harvey.ai/blog/building-an-agent-for-complex-document-drafting-and-editing そこで私たちは焦点をシフトしました。私たちは、エージェントがHTMLを編集するのと同じようにWord文書を編集できるMCPを設計しました。エージェントはHTMLを受け取り、検索と置換の編集を行い、私たちはそれらの編集を元の.docxファイルに反映させます。 pandocやmammoth.jsが十分な忠実度を維持できなかったため、独自のDOCX→HTMLコンバーターを作成する必要がありました。HTMLをMarkdownよりも選択したのは、構造的にOOXMLに近く、CSSがOOXMLと同様の方法で要素にスタイルを関連付けるためです。 明確にしておくと、私たちのDOCX → HTML変換も情報が失われます。しかし、それは問題ありません。なぜなら、私たちはHTMLをDOCXに戻すことは決してないからです。HTMLはエージェントのための単なる投影であり、エージェントが編集対象の構造とスタイルを理解するのに十分な忠実度があれば良いのです。元のファイルは真実の情報源として残り、私たちはそれをインプレースで変更します。 これにより、エージェントは新しいDSLを学習する必要もありません。Word文書の編集は、ファイルシステム上のHTMLファイルの編集と全く同じように感じられます。これはエージェントがすでに得意としていることです。多くのDOCX MCPは、エージェントにオンザフライで把握すべき数十、あるいは数百ものツールを提供します。私たちのMCPは、3つのツール（read、search、edit）のみを公開します。Word文書は完全に抽象化されています。 エージェントが編集リクエスト（「old_html」と「new_html」のペア）を送信した後、私たちはそれを元の.docxファイルに反映させます。この反映処理は、私たちのファインチューニングされたモデル、LoRAアダプターを備えた3〜8Bベースモデルによって行われます。HTMLの差分を入力として、元のローカライズされたOOXMLブロックと共に受け取り、新しいOOXMLを出力します。「ローカライズ」は決定論的に行われます。エージェントが指定したアンカーを取得し、それらのXMLツインを見つけようとします。これにより、リコンサイラーモデルは単一の責任を持ちます。 この狭いタスクでは、小さなモデルでもフロンティアレベルの、適切にプロンプト調整されたモデルと同等のレベルに達し、ホットパスに配置できるほど小さく高速です。 このプロジェクトは数ヶ月に及ぶ作業となりましたが、v1をリリースできたことを嬉しく思います。私たちの内部ベンチマークでは、DOCXスキルや生のpython-docxよりも高精度でありながら、タスクあたり3回のツールコール（p50）で済むのに対し、DOCXスキルは10回、Office CLIは13回かかるため、約2倍安価で約3倍高速であることが示されています。 まだ完璧ではありません。例えば、現時点では画像やコメントの操作はサポートしていません。それでも、すでに多くの人々が私たちのMCPを様々な方法で使用しているのを見ています。 - Legal tech企業がOffice.jsでのライブ編集フローを強化しています。 - AIスタートアップが履歴書を最適化し、代わりに申請を行っています。 - ポリシースタートアップが、ポリシーメモを作成する必要があります。 - ライフサイエンススタートアップが、長期実行エージェントを使用して規制フォームを完成させています。 プライバシーに関する注意：私たちのMCPはクラウドで実行されるため、ユーザーは.docxファイルを私たちに送信します。私たちはユーザーデータで学習しません。チームはZDRまたはセルフホスティングを選択できます。 月500回の編集が可能な無料ティアがあり、ぜひお試しください。後でこれを増やしたいのですが、私たちは小さなチームであり、ファインチューニングされたモデルの実行は安価ではありません :( 文書編集全般に関するアイデアやコメントをお聞かせください！数時間、コメント欄でお返事します。