OfficeCLIとは何か――OfficeとAIの「相性問題」に対する一つの解¶

対象 / ポイント

対象: OfficeファイルとAIをどう連携させるかに取り組んでおり、その選択肢の一つとしてOfficeCLIにたどり着いたエンジニア層。

ポイント:

OfficeCLIは、マークダウン化や画像化とは別系統の「編集できる経路」を選ぶ
単一バイナリとJSON契約でOOXMLを直接操作し、HTML/PNGで結果を確認する
強みは編集と検証の統合、弱みは往復整合性と描画忠実性の見極めにある

OfficeとAIの「相性問題」とは何か¶

企業の文書業務では、AIに読ませたいファイルほどWord、Excel、PowerPointで残っている。契約書、営業資料、予算表、レビューコメント付きの提案書。どれも業務上は重要だが、AIにとっては単純なテキストではない。

.docx / .xlsx / .pptx は、XMLをZIPで固めたOOXML（ECMA-376 / ISO/IEC 29500）という構造をとる¹。AIが直接読み書きしづらい形式なのだ。

そのため現場では、いくつもの回避策が試されてきた。代表的なものは次の4系統に整理できる。

マークダウン化：本文を抽出してテキスト化する。読ませやすいが、書式・レイアウトは失われ、原本への書き戻しが難しい
画像化＋マルチモーダル：ページを画像にしてAIに「見せる」。見た目は伝わるが、コストが高く編集には向かない
ライブラリ操作：python-docx や openpyxl で直接編集する。言語依存で、複雑な文書では再現が部分的になりやすい
Office自動化：COMやUNO APIでOffice本体を操る。再現性は高いが、Officeのインストールと特定OSが前提になる

OfficeCLIは、この見取り図に新しく加わった「AIエージェント向けに設計された」系統である²。位置づけを一言で言えば、Office不要でOOXMLを直接編集し、その結果をエージェント自身が描画して確認できるようにしたCLIツールだ。

仕組み：単一バイナリがOOXMLを直接たたく¶

OfficeCLIの実体は、C#/.NETで書かれた自己完結型の単一バイナリである。.NETランタイムが埋め込まれているため、別途インストールするものはなく、Officeも不要で動作する²。

操作の中心にあるのは、パスによる要素指定だ。スライドの図形は /slide[1]/shape[2] のように、1始まりのインデックスと要素名で指す。XMLの名前空間を理解しなくても、エージェントが文書内を移動できる設計になっている。

操作は3層に分かれており、必要な深さだけ降りていく構造をとる。

層	役割	主なコマンド
L1 読み取り	内容の意味的なビュー	`view`（outline / text / html / screenshot 等）
L2 DOM操作	要素単位の編集	`get` `query` `set` `add` `remove` `move`
L3 生XML	XPathによる直接操作	`raw` `raw-set` `validate`

描画は本ツールの特徴の一つだ。OOXMLからHTMLへの変換はバイナリ内部で行い、HTMLからPNGへの変換はヘッドレスブラウザに渡す²。これにより、ディスプレイのないCIやDocker環境でも、生成物を画像として確認できる。

出力はすべて --json で構造化でき、エラーも not_found などのコード付きで返る。エージェントがstdoutを正規表現で解釈する必要がない、という点が一貫して重視されている。

思想：エージェントに「見て直す」ループを与える¶

このツールの設計思想は、「エージェントは文書を見えないまま生成している」という課題認識から出発している。DOMは読めても、タイトルがはみ出したか図形が重なったかは、描画しなければ分からない。

そこでOfficeCLIは、render -> look -> fix の閉ループを提供する。

文書を生成する
HTML/PNGに描画して読む
ズレを見つけて直す

この検証経路を、Office不要・ヘッドレスでも回せるようにした点が中核の主張である。

もう一つの軸は、トークン経済性だ。3層構造で安価な操作から始め、必要なときだけ深い層に降りる。テンプレートの {{key}} 差し込みでレイアウトを一度だけ設計してN回再利用する。既存文書を dump でバッチJSONに変換し、お手本から学ぶ。

いずれも、エージェントが毎回ゼロから生成してトークンを浪費する事態を避けるための設計である²。

連携の障壁も低く抑えられている。SKILL.mdとMCPサーバの両方を同梱し、検出したエージェントへ自動でskillを導入する。「エージェントが置かれている場所に、ツールの側から歩み寄る」という発想が一貫している。

できること¶

カバー範囲は広い。Word/Excel/PowerPointの3形式すべてで、読み取り・改変・新規作成に対応する²。要点を機能群で整理すると次のようになる。

読む・作る・直す：本文/構造/書式/数式を、プレーンテキストまたはJSONで取得し、要素単位で編集する
描く：view html / view screenshot / watch で、Officeなしに見た目を確認する
計算する：150以上のExcel関数を書き込み時に自動評価し、ピボットテーブルを一括生成する
量産する：テンプレート差し込み、バッチ実行、dump/batchによる複製で、同型文書を大量生成する
つなぐ：全コマンドの --json 出力、MCPサーバ、各エージェントへのskill導入で、自動化・エージェント連携に組み込む

Word側では脚注・コメント・変更履歴・目次・数式・RTL（右横書き）まで、Excel側では条件付き書式・スライサー・スパークラインまで、対応要素は細かい。「足りない機能を探すより、できることを把握する方が早い」水準の網羅性がある。

できないこと・限界¶

一方で、できないこと、あるいは信頼しきる前に検証すべき領域も明確にある。「操作できる」ことと「壊さず正しく操作できる」ことは別問題だからだ。

第一に、往復整合性の課題がある。複雑な既存文書を改変するとき、触れていない部分が壊れる事例が報告されている。inline文字列セルの旧表現が残って表示が古くなる、IDで指定した脚注ではなく別の脚注を削除する、行挿入時にデータ検証式の参照がずれる、といった症状だ³。validate を通過しても意味が壊れる「サイレントな誤改変」は、自動運用で気づきにくい⁴。

第二に、描画の忠実性に限界がある。前述のとおり描画はOOXMLからHTMLへの変換とブラウザ委譲で実装されており、HTML/CSSのレイアウトはOfficeのレイアウトと別物だ。Excelと比べチャートのオーバーレイがズレる問題はIssue化され、修正PRがマージされている。XY散布図がカテゴリ軸の折れ線として描画される問題も報告された⁵。これは個別バグの列挙ではなく、描画プレビューを検証チャネルとして使うならOffice実レンダリングとの差分を評価対象に含めるべき、という示唆である。

第三に、「依存なし」は条件付きだ。XML操作とHTML出力では追加依存なしと説明されているが、PNG生成のスクリーンショット機能はヘッドレスブラウザを使う。導入時の評価では、コマンド操作と画像化を分けて考える必要がある。

第四に、運用上の留意点がある。curl ... | bash での導入、検出した全エージェントへの自動書き込み、バックグラウンドでの自動更新、という設計は、エージェントに接続され文書へフルアクセスを持つバイナリとしては、企業環境では統制の対象になる。自動連携自体にも、MCP登録が誤ったファイルに書き込まれる報告がある⁶。READMEには自動更新を止める OFFICECLI_SKIP_UPDATE や config autoUpdate false も用意されている²。

OfficeCLIは、ピクセル単位でOfficeを再現するWYSIWYG置換ではない。生成・量産と、その軽量な検証に強みを持つツールである。

まとめ：既存アプローチの中での位置¶

冒頭の見取り図に戻すと、OfficeCLIの立ち位置がはっきりする。

アプローチ	書式保持	編集・書き戻し	検証手段	導入
マークダウン化	なし	限定的	テキスト確認	軽い
画像＋マルチモーダル	見た目は保持	なし	目視	中
ライブラリ（python-docx等）	部分的	あり	別途必要	言語依存
OfficeCLI	あり	あり	描画ループ内蔵	単一バイナリ

この比較で言えば、OfficeCLIは「書式を保ったまま編集し、結果を検証する」経路を一本でまかなおうとする点が、他系統と異なる。マークダウン化が捨てるレイアウトを保持し、画像化が持てない編集能力を持ち、ライブラリにない描画検証を備える。

ここから一つの示唆が出る。エージェントの文書生成は、「ファイルを作れるか」から「作ったファイルを検証できるか」へと重心を移しつつある。OfficeCLIの本質的な貢献は、機能の多さよりも、検証チャネルをヘッドレスで安価にした点にある。

そして検証チャネルの価値は、その忠実性を超えない。OfficeとAIの相性問題に取り組むうえで、このツールを評価する軸は「何ができるか」ではなく「何を、どれだけ正確に確認できるか」になる。

OOXMLは操作可能な仕様であり、論点は操作可否ではなく往復整合性と描画忠実性にある
強みは「書式保持・編集・検証」を一本化した経路、弱みはその忠実性の発展途上にある
入力を統制でき出力を検証できる用途から導入し、任意の複雑文書の無損失編集は慎重に見極める