PaPoo
cover

Word文書をAIに任せるなら、たしかにここが一番しんどい

最初に思ったのは、​Word編集ってこんなに“状態管理”の仕事だったのか、ということだった。文章を直すだけならまだしも、段落の見た目、テンプレート由来のスタイル、番号付きリスト、追跡変更まで絡むと、AIは文章理解とは別の泥臭い作業を延々やらされる。記事が言う「Word state machine」という表現は少し大げさにも見えるけれど、読んでいるとわりと本当にそうだなと思う。

特に引っかかったのは、​​「LLMにWordをそのまま触らせる」のが筋悪に見えるという指摘よりも、そこから逆算して「いったんHTMLにして、最後はreconcileする」という発想を取ったところだ。MarkdownではなくHTMLを選んだのも自然に感じた。Wordの文書って、見た目以上にスタイルの継承や構造が効いてくるので、Markdownの素朴さだと足りないのは想像しやすい。HTMLのほうがまだ近い、という感覚はわかる。

ただ、面白いのはここからで、ふつうなら「じゃあ変換精度をもっと上げよう」となりそうなところを、彼らはreconciler自体を学習させる方向に振っている。要するに、人間が考える“きれいな中間表現”と、実ファイルに戻すときの“整合”をモデルにやらせる。これは発想としてかなりAIらしいし、同時にかなり危うくもあると思う。うまくいけば強いが、失敗すると原因が見えにくい。手書きのルールなら追えるけれど、学習したreconcilerがどこで取りこぼしたかは、たぶんデバッグが難しい。

それでも、法律・金融・医療みたいにWordが納品物そのものになる領域では、こういう方向に寄せるしかないのかもしれない。文書の中身を理解したいのに、XMLの都合でトークンを食われるのは確かにもったいない。AIにやらせたいのは契約の差分であって、w:tbl の機嫌取りではないので。そこを切り分ける狙いはかなり筋がいいと思った。

一方で、ベンチマークの数字は気になる。3倍速い、2倍安い、しかも正確、というのは派手だが、記事を読むとかなり丁寧に条件を揃えていて、逆に「それでも本当に現場で同じように効くのか」はまだ少し保留したい気持ちが残る。Word編集は文書の種類ごとにクセが強いので、内部ベンチマークでの勝ち筋が、そのまま各社の実運用に持ち込めるとは限らないと思う。とはいえ、少なくとも「WordをAIに触らせるのは無理」という段階からは一歩進んでいる感じがある。


参考: Launching Vespper DOCX MCP: 3× faster, 2× cheaper, more accurate

同じ著者の記事