OfficeCLIとは何か――OfficeファイルをAIエージェントが生成・検証する仕組み¶
対象 / ポイント
対象: Word、Excel、PowerPointをAIエージェントから生成・修正し、機械検査と見た目の確認まで自動化したい開発者
ポイント:
- OfficeCLIは
.docx、.xlsx、.pptxを単一バイナリから読み書きするApache-2.0のOSS - パス指定とJSON出力に加え、OpenXML検証、issues検出、HTML/PNG描画で「作る→見る→直す」を構成できる
- 重要文書はOfficeCLIの検査だけで完了とせず、配布先アプリでの最終表示と業務内容を人が確認する
OfficeファイルがAIに難しい理由¶
.docx、.xlsx、.pptxは単純なテキストではない。OOXMLというZIPパッケージ内に、本文、書式、画像、関係情報などを複数のXMLパートとして持つ1。
本文だけをMarkdownへ変換すれば読みやすくなるが、元のレイアウトへ書き戻しにくい。ページを画像にすれば見た目を読めるが、セルや段落を正確に編集しにくい。Pythonライブラリは強力だが、Word、Excel、PowerPointごとにAPIと実装が分かれる。
OfficeCLIは、この間に「エージェントが安定したCLI契約でOffice文書の構造を操作する」という経路を置く。
現在のOfficeCLI¶
OfficeCLIは、Word、Excel、PowerPointを読み取り、変更し、新規作成するOSSのCLIだ。実行時にMicrosoft Officeや.NETを別途導入する必要がない自己完結バイナリとして配布される。ソースからのビルドにだけ.NET 10 SDKを使う2。
2026年7月19日時点の最新リリースはv1.0.139で、公式リポジトリは高頻度に更新されている3。固定された小さな変換ツールではなく、Wordの変更履歴やフィールド、Excelの数式・ピボット、PowerPointの図形、描画、SDKまで広い面を実装するプロジェクトだ。
エージェント向けの4つの設計¶
1. 要素をパスで指定する¶
文書内の要素を、XML名前空間ではなく安定したパスとして扱う。
officecli get deck.pptx '/slide[1]/shape[1]' --json
officecli set deck.pptx '/slide[1]/shape[1]' --prop text="売上は25%増加"
OfficeCLIのパスは1始まりで、XPathそのものではない。エージェントが「1枚目のスライドの1番目の図形」のように対象を特定しやすい。
2. 結果とエラーをJSONで返す¶
get、query、変更系コマンドは--jsonを使える。存在しない要素や不正な値では、エラーコード、修正候補、有効範囲を返す2。
{
"success": false,
"error": {
"code": "not_found",
"suggestion": "Valid Slide index range: 1-8"
}
}
自然言語の標準出力を正規表現で読むより、エージェントが失敗から修正しやすい。
3. 複数操作を原子的に適用する¶
batchは複数の変更を1回で処理し、既定では途中の1件が失敗すると全体をロールバックする。部分成功を許す--best-effortも選べる。
officecli batch report.xlsx --input updates.json --json
複数セルや図形を順番に変更する途中で文書が半端な状態になるリスクを下げられる。
4. 構造と見た目を別々に検査する¶
OfficeCLIはOpenXML schemaの検証、文書上の問題検出、HTML/PNG描画、ライブプレビューを提供する2。
officecli validate report.pptx
officecli view report.pptx issues --json
officecli view report.pptx screenshot
officecli watch report.pptx
構造が妥当でも文字が枠からはみ出すことがある。見た目が整っていても数式やリンクが壊れていることがある。両方の検査を持つ点が、単純なファイル生成ライブラリとの大きな違いだ。
導入する¶
開発者向けの公式手順は次の通りだ2。
curl -fsSL https://raw.githubusercontent.com/iOfficeAI/OfficeCLI/main/install.sh | bash
brew install officecli
npm install -g @officecli/officecli
irm https://raw.githubusercontent.com/iOfficeAI/OfficeCLI/main/install.ps1 | iex
導入後にofficecli installを実行すると、PATHへの配置と検出したAIコーディングツールへのSkill設定を行う。自動設定を望まない場合は、先に--helpと公式SKILL.mdを読み、対象を確認してから実行する。
officecli --help
officecli install
最小ワークフロー¶
PowerPointを1枚作り、構造と見た目を検査する。
# 作成
officecli create report.pptx
# 内容を追加
officecli add report.pptx / --type slide --prop title="四半期レポート"
officecli add report.pptx '/slide[1]' --type shape \
--prop text="売上は25%増加" --prop x=2cm --prop y=5cm \
--prop size=28
# 読み取りと検査
officecli view report.pptx outline
officecli validate report.pptx
officecli view report.pptx issues --json
officecli view report.pptx screenshot
自動化では、次の順番を固定するとよい。
flowchart LR
A[create / open] --> B[get / query]
B --> C[set / add / batch]
C --> D[validate]
D --> E[view issues]
E --> F[HTML / PNGで確認]
F -->|修正| C
F -->|合格| G[配布先アプリで最終確認]向く用途¶
- 定型レポートや請求書をテンプレートから繰り返し生成する
- 既存ファイルの文字、セル、図形をJSONで検査・更新する
- CIでOpenXML妥当性、数式エラー、代替テキスト不足を検出する
- 人が作った文書を
dumpで再生可能なbatch JSONへ変換する - ヘッドレス環境でOfficeファイルをHTML/PNGへ描画してレビューする
- PythonまたはNode.js SDKから常駐プロセスとして操作する
特に価値が出るのは、生成だけでなく検証と再修正を同じインターフェースで閉じたい場合だ。
限界と確認ポイント¶
OfficeCLIの機能範囲は広いが、次の境界は残る。
- Microsoft Officeの描画エンジンそのものではない。HTML/PNGが正しく見えても、配布先のExcelやPowerPointで同じとは限らない
- OOXMLの機能は広大で、文書内のすべての要素・組み合わせが同じ成熟度とは限らない
- 数式やグラフが構造上妥当でも、業務上の数字が正しいとは限らない
- 高頻度更新のため、コマンドや出力契約を自動化へ固定するならバージョンをpinし、更新時に回帰テストする必要がある
- Skillやインストールスクリプトはコード実行権限を持つ。公式ソースと差分を確認する
契約書、取締役会資料、決算数値、顧客提出物では、OfficeCLIのvalidateと描画確認に加え、利用者が実際に開くOfficeアプリで最終確認する。
他の方法との使い分け¶
| 目的 | 第一候補 |
|---|---|
| 本文だけを検索・要約したい | Markdownやテキストへの抽出 |
| 見た目だけを読みたい | PDF/画像化 + マルチモーダルモデル |
| Pythonアプリで限定的な表を生成したい | openpyxlなどの専用ライブラリ |
| Office本体の完全な自動化が必要 | Office Scripts、COM、Graphなど公式環境 |
| AIが3形式を共通CLIで編集・検査したい | OfficeCLI |
OfficeCLIは他方式を置き換える万能層ではない。エージェント向けの操作契約と、ヘッドレスな検査ループが必要な場所に向く。
まとめ¶
OfficeCLIの中心価値は「Officeファイルを書ける」ことだけではない。
- パスとJSONで対象・結果を安定させる
- batchと構造検証で壊れた途中状態を減らす
- HTML/PNGでエージェントへ見た目を返す
- 問題があれば同じCLIで直す
このループをCIやコーディングエージェントへ組み込める点が特徴だ。一方で、重要文書の最終責任までCLIへ委ねず、対象アプリでの表示と内容を人が確認する線を残すべきだ。
