📄 AIにWordファイルを触らせるならCLI経由 — docx-cliの実測ベンチで小型モデルが化けた

AIエージェントにWordファイルを渡すと、地味に事故る。中身はXMLの塊なので、そのまま読ませればトークンを浪費するし、書かせれば書式が飛ぶ。最悪、Wordで開けないファイルを平然と納品してくる。契約書の日付を1箇所埋めるだけの仕事で、これをやられると結構つらい。

Show HNに出ていた「docx-cli」は、この問題を「エージェントにXMLを見せない」方向で解決するツールだ。スターはまだ132だが、READMEのベンチマークが具体的で面白かった。

CLIを1枚挟むだけで小型モデルが化ける

docx-cliは.docxの読取・置換・コメント・変更履歴(トラックチェンジ)・リドライン挿入をコマンドで提供する。エージェントはXMLの構造を理解する代わりに、こういうコマンドを叩けばいい。

docx read mnda.docx --from t1 --to t1
docx replace mnda.docx "Fill in: date" "May 6, 2026"
docx track-changes mnda.docx on

置換や変更履歴の操作が「文書構造の理解」から「コマンドの選択」に変わる。エージェントに渡す問題の難易度そのものを下げるアプローチだ。

READMEのベンチマークは、契約書入力・リドライン・コメント・請求書作成など6タスクを各3回、Claudeのデフォルトスキルと比較している。数字がはっきりしていて、Haikuクラスの小型モデルだとタスク完了率0.7/6 → 4.3/6。トークン消費は2.2〜2.6倍少なく、速度は1.7〜2倍。そして生成ファイルがWordで開けない事故が、デフォルト側は36回中5回あったのに対し、docx-cli側は36/36でゼロだった。

Sonnetクラスでも4/6→6/6に上がる。つまり「賢いモデルでゴリ押す」代わりに「道具を整えて安いモデルで済ませる」が成立する。うちは分類・要約をHaikuに寄せてコストを管理しているので、この方向の実測値は素直にうれしい。

数字の出所には注意

ただし、このベンチは作者自身によるもので、外部検証はまだない。HNスレッドも読みに行ったんですが、429ではじかれて反響の詳細は確認できなかった。MITライセンスでバイナリ配布(Linux/macOS/Windows)があるので、疑うより手元で試す方が早いタイプのツールだ。

「モデルを賢くする」より「タスクを簡単にする」。エージェントの精度問題は、案外こっち側に伸びしろが残っている気がする。あなたのエージェントが一番事故るファイル形式は何ですか。そこにCLIを1枚挟む余地、たぶんありますよ。