AIエージェントにWord文書を編集させると、たいてい書式が壊れるか、開けないファイルができあがる。docx-cli（npmパッケージ名 bun-docx）は、この問題を「エージェントにOOXMLを直接触らせない」設計で解決しようとするCLIツールだ。公式NDAサンプルへの記入・変更履歴・コメント追加のワークフローを、ネットワーク遮断済みの専用Docker環境で実際に動かして確認した。結論から言うと、記入・変更履歴・コメントの一連の操作はすべて期待どおりに動作したが、動作にはBunランタイムが必須で、Node.jsだけの環境では動かない。
対象読者は、Claude CodeやCodexなどのコーディングエージェントに契約書・NDA・議事録といったWord文書の編集を任せたい個人開発者だ。
docx-cliは何ができるツールか
docx-cliは、エージェントが.docxファイルをXMLとして直接いじるのではなく、docx read／docx find／docx replace／docx comments／docx track-changesといったコマンドを組み合わせて編集するためのCLIだ。文書内の位置はp3:5-20のような安定したロケータで指定し、人間側は普段どおりWordで開いて変更履歴やコメントを確認・承認できる、という役割分担になっている。
公式READMEでは、Haiku・Sonnetそれぞれに「NDA記入・請求書記入・レジュメ整形・契約書の赤入れ・契約の確定・文書の新規作成」という6タスクを3回ずつ実行させ、docx-cliを使った場合とClaude標準スキルを使った場合を比較したベンチマークが公開されている。この数値については後述のとおり自分では再現していない。
実際に動かした結果
Bun専用の動作確認用イメージを自作し、公式配布のNDAフィクスチャに対して以下を実行した（すべてネットワーク遮断・read-only・非rootのコンテナ内）。
カバーページの記入
記入前は[Fill in: today's date]のようなプレースホルダが4箇所あった。docx replaceで日付・州名2箇所・変更事項欄を埋め、docx findで正規表現\[(Fill|fill)[^]]*\]を検索して未記入箇所が0件になったことを確認した。
変更履歴とコメント
docx track-changes onで変更履歴の記録を有効化したうえで、Use & Protection条項の”having a reasonable need to know”を”with a documented need to know”に置換。この置換が変更履歴として記録されていることをdocx track-changes listの出力で確認した。続けてdocx comments addでレビューコメントを1件追加し、docx comments listにそのコメントが載っていることも確認した。
これら一連のチェックはログを目視するだけでなく、置換結果や変更履歴・コメントの有無をスクリプト内でアサーションし、最終的な終了コード0で裏付けている（1つでも失敗すればその時点で非ゼロ終了する）。
うまくいったこと
- ドキュメントに書かれているコマンド例（
docx read／docx replace／docx find --regex／docx track-changes／docx comments add）は、READMEのNDA記入例をそのままなぞる形で全て動作した - 未記入プレースホルダの検出は正規表現1発で済み、「埋め忘れがないか」を人間が目視で確認する手間を減らせそうだった
- 変更履歴・コメントはどちらも校閲データとしてdocx内に記録され、CLI上でも列挙できた（Word実物での表示確認は未実施）。CLI側だけで完結させず、人間のレビュー導線につなげる設計だと分かった
うまくいかなかったこと・制約
- Bunランタイムが必須。 npmでインストールできてもNode.jsだけの環境では動かない（
TypeError: __require is not a functionで落ちる）。原因と解決手順はbun-docxがNode.jsで動かない原因と解決に詳しくまとめた - 動作確認は専用に組んだDockerイメージの中で行っており、手元のBunやnpmグローバル環境にそのままインストールした場合の挙動までは確認していない
- 実際のWord（またはLibreOffice等）で生成後の
.docxを開いてレンダリング崩れがないかまでは、今回の検証環境（レンダラを持たないコンテナ）では確認できていない
公式説明との差
公式READMEはHaiku・Sonnetそれぞれ3回ずつのA/Bベンチマーク（docx-cli使用時とClaude標準スキル使用時のタスク達成数・トークン数・実行時間の比較）を掲載しているが、今回はこの数値の再現や他ツールとの比較検証は行っていない。確認したのはあくまで「READMEに書かれているNDA記入コマンド例が、公式配布のフィクスチャに対して宣言どおりに動くか」という一点で、それは終了コード付きで確認できた。ベンチマークの数値そのものについては「公式の自己申告」として扱うのが妥当で、自分の環境・タスクで同じ差が出るかは別途検証が要る。
向いている人・向いていない人
向いている人: Claude CodeやCodexにNDA・契約書・議事録などのWord文書編集を任せたいが、「壊れたファイルが返ってくる」「書式が崩れる」といった事故を避けたい人。Bunランタイムの導入に抵抗がない人。
向いていない人: 既にMS Graph APIやpython-docx等でWord自動化パイプラインを構築済みで、置き換える予定がない人。Node.js限定の環境で完結させたい人（Bunが使えないと動かない）。
まとめ
docx-cliの核となるワークフロー——プレースホルダの一括置換、未記入箇所の検出、変更履歴とコメントの追加——は、公式NDAフィクスチャに対して実際に動かし、アサーション付きスクリプトの終了コードで裏付けが取れた。一方で、Bunランタイムが前提になっている点は、Node.js中心の開発環境だと導入コストとして無視できない。公式サイトのベンチマーク数値については自分では未検証なので、導入判断の材料としては「NDA記入のような定型フローは実際に動く」という事実と、「公式の速度・精度の主張は自己申告」という2つを分けて捉えるのがよさそうだ。