Anthropic のエージェントスキル docx の機能、コード構成、使用法、注意事項を分析する

Anthropic の skills/docx は本質的に、「AI が Word ドキュメントをより安定して処理できるようにする」作業仕様書とスクリプトツールのセットです。
これはモデルに単に「.docx を書く」と指示するのではなく、Word 文書の処理をいくつかの明確なパス (新しい文書の作成、コンテンツの読み取り、既存の文書の編集、改訂の処理、コメントの追加、形式の変換、OOXML 構造の検証) に分割します。

一文だけ読めば次のように理解できます。

エージェントが .docx をブラックボックスとして扱うのではなく、ZIP + XML + Office の互換性の問題として扱うようにします。

このスキルはどのような問題を解決しますか?

通常のテキスト生成モデルが Word 文書を処理する場合、いくつかの一般的な問題が発生します。

テキストを出力するだけであり、実際には構造的に正しい .docx は生成されません。
既存のドキュメントを変更する場合、OOXML 構造は簡単に壊れてしまう
コメント、改訂、コメントスレッドに遭遇したとき、どの XML を変更すればよいのかわかりません。
ドキュメントを生成できますが、Word、LibreOffice、Google Docs 間の互換性が不安定です
pandoc をいつ使用するか、いつ解凍して XML を直接変更するかがわからない

ここに、docx スキルの価値があります。「何をするか」を事前に制約します。

コンテンツを読み取るときは、pandoc の使用または解凍を優先してください。
新しく .docx を作成する場合は、docx-js を優先してください。
既存の .docx を編集する場合は、まず「解凍 -> XML の変更 -> 再パッケージ化 -> 検証」に進みます。
モデルをハードコーディングするのではなく、コンパニオンスクリプトを使用して、リビジョン、コメント、スキーマ検証の受け入れの詳細を処理します。

Word 文書の問題は、多くの場合、「テキストが正しく記述されているかどうか」ではなく、「ファイル構造が Office で受け入れられるかどうか」であるため、この考え方は非常に実用的です。

ディレクトリとコードの構成

このスキルは大きく4つのレベルに分かれています。

1. 説明レイヤー: `SKILL.md`

SKILL.md はスキル全体への入り口です。主に次の 2 つのことを行います。

トリガー条件を定義する
このスキルは、ユーザーが Word、.docx、コメント、改訂、目次、ページ番号、テンプレート、書式設定されたドキュメントなどを必要とする限り有効にする必要があります。
作業パスを指定する
毎回即興で作るのではなく、さまざまなタスクに対してどの技術的なルートを取るべきかを明確に書き出します。

内容から判断すると、「使用説明書」と「動作仕様書」の両方です。
特に価値があるのは、そこにリストされている次のような多くの Word 互換性ルールです。

docx-js のデフォルトは US レターではなく A4 です
ページが水平の場合、内部ロジックに従って幅と高さのパラメータを渡す必要があります。
リストは手動で挿入できません Unicode 箇条書き
表の幅は表とセルと同時に設定する必要があります。
画像を挿入する場合、typeは省略できません。
生成後、validateを実行

これは、作者が単に「生成できること」ではなく、「安定して開くことができ、安定してレンダリングでき、生成後に互換性があること」を望んでいることを示しています。

2. Office パッケージ操作層: `scripts/office/*`

この層は、.docx/.pptx/.xlsx を Office Open XML パッケージとして処理する役割を果たします。

`unpack.py`

その機能は、Office ファイルをディレクトリに解凍し、いくつかの補助タスクを実行することです。

ZIPパッケージを解凍します
XML/.rels できれいに印刷します
.docx に対する merge_runs のオプションの実行
.docx に対する simplify_redlines のオプションの実行
スマートクオートを XML エンティティに変換して、後続の処理リスクを軽減します

その設計の焦点は、「単純な解凍」ではなく、エージェントや人間が編集を続けるのに適した状態にファイルを整理することにあります。

`pack.py`

この機能は、変更されたディレクトリを .docx/.pptx/.xlsx に再パッケージ化することです。
梱包する前に行うべき重要なことが 2 つあります。

オプションの動作検証と自動修復
XML を再圧縮し、無意味な空白やコメントを削除します。

--original が指定されている場合は、バリデーターと比較されます。これは非常に重要です。
Word の変更の多くは「元に戻すことができれば成功する」わけではなく、文書の構造とリビジョンの追跡セマンティクスがまだ有効であることを確認する必要があるためです。

`validate.py`

これはスキル全体の品質ゲートです。
検証をサポートします。

XML は整形式ですか?
名前空間は正しいですか?
すべての種類の ID は一意ですか?
関係性/コンテンツタイプは一致していますか?
XSDスキーマに準拠
空白の保持ルールは正しいですか?
挿入、削除、コメントマークは合法ですか?

.docx の場合、このステップはほぼコアコンピテンシーです。
「XML が少しだけ変更されているだけ」のように見える多くの文書の場合、本当の問題はここにあります。

`soffice.py`

これは非常にエンジニアリング的なガジェットです。
単に LibreOffice を呼び出すのではなく、制限された環境向けの互換性処理を準備し、自動的に SAL_USE_VCLPLUGIN=svp を設定し、制限された AF_UNIX ソケットの問題を解決するために必要に応じて shim を構築します。

これは、スキルの対象環境が「ローカルデスクトップの手動操作」だけではなく、エージェントやCI、サンドボックスなどの自動化された環境も考慮していることがわかります。

3. Wordの特殊能力レベル：コメント、修正、朱書き

`comment.py`

このスクリプトは、DOCX にコメントを追加する役割を果たします。
Word のコメントは単一のファイルメカニズムではなく、連携して動作する一連のコンポーネントであるため、その動作は「コメント XML を書く」よりもはるかに複雑です。

word/comments.xml
commentsExtended.xml
commentsIds.xml
commentsExtensible.xml
document.xml のコメント範囲マーカー
[Content_Types].xml および document.xml.rels での関係宣言

スクリプトでは、これらの依存関係がすでに考慮されています。
初めてコメントを追加する場合、テンプレートファイル、リレーションシップ、コンテンツタイプが自動的に完成するため、OOXML を手動で変更する際のエラー率を大幅に減らすことができます。

`accept_changes.py`

このスクリプトの目標は非常に明確です。すべてのリビジョンを受け入れることです。
実装方法はXMLを自分で修正するのではなく、LibreOfficeのヘッドレス+Basicマクロで.uno:AcceptAllTrackedChangesを調整する方法です。

Word セマンティクスにおける「リビジョンの受け入れ」は、<w:ins> / <w:del> を削除するほど単純ではないため、この選択は非常に安全です。 XML を直接変更すると、重大な問題が残る可能性があります。
通常、これを Office エンジン自体で行うと、互換性が向上します。

`validators/redlining.py`

これがこのスキルの最も注目すべき部分です。
元の文書と変更された文書から「作成者の改訂」を分離し、テキストが一貫しているかどうかを比較して、改訂が追跡された変更構造に正しくラップされているかどうかを判断します。

言い換えれば、XML 形式をチェックするだけではなく、「リビジョンセマンティクスに従ってドキュメントを編集したか?」をチェックします。

AI は次のような間違いを犯しやすいため、これはエージェントにとって特に重要です。

テキストを直接修正します。ただし、<w:ins> / <w:del> は含めません。
他の人の挿入または削除構造の階層を変更する
最終的なテキストは変更されましたが、朱書きのロジックは保持されません

このバリデータは、この「表面の可用性とセマンティックエラー」の問題を防ぐためのものです。

4. スキーマと補助層: `schemas/`、`helpers/`、`templates/`

`schemas/`

ここに、OOXML / ECMA / Microsoft 拡張機能関連の XSD の完全なセットを示します。
これは、スキルの検証が頭でルールを記述することではなく、可能な限り形式的なスキーマ制約に基づいて行われることを意味します。

`helpers/`

主なものは次のとおりです。

merge_runs.py
simplify_redlines.py

その機能は、解凍された Word XML を適度にクリーンアップして、構造をより安定させ、編集と比較を容易にすることです。

`templates/`

コメント関数が依存する次のような XML テンプレートがここに保存されます。

comments.xml
commentsExtended.xml
commentsIds.xml
commentsExtensible.xml
people.xml

このタイプのテンプレートファイルは重要です。多くの Word パーツは「不足している場合に自動的に埋められる」わけではなく、Office で受け入れられる形式で事前に設定されている必要があるからです。

一般的な使用法

SKILL.md による提案から判断すると、このスキルは次のワークフローに最適です。

シナリオ 1: 既存の DOCX の読み取りまたは分析

コンテンツを抽出し、構造を読み取り、Markdown に変換することが目的の場合は、以下を使用します。

1

pandoc --track-changes=all document.docx -o output.md

基礎となる XML を表示したい場合は、以下を使用します。

1

python scripts/office/unpack.py document.docx unpacked/

前者は内容を読むのに適しており、後者は構造を見るのに適しています。

シナリオ 2: 新しい DOCX を作成する

スキルの提案は、OOXML を手動でロールするのではなく、docx-js を使用して以下を生成することです。

1

npm install -g docx

次に、ドキュメントを生成して検証します。

1

python scripts/office/validate.py doc.docx

このルートは次のような場合に適しています。

報告
memo
letter
タイトル、目次、フッター、ページネーション、表を含む正式な文書

シナリオ 3: 既存の DOCX を編集する

これはスキル全体の中核となるワークフローです。

1
2
3


python scripts/office/unpack.py document.docx unpacked/
# 修改 unpacked/ 下的 XML
python scripts/office/pack.py unpacked/ output.docx --original document.docx

ここで重要なのは「XML の変更」ではなく、最後のステップ --original です。
これにより、システムはパッケージを返すときに、やみくもにパッケージ化するのではなく、スキーマとレッドラインレベルの検証を実行できるようになります。

シナリオ 4: すべてのリビジョンを受け入れる

1

python scripts/accept_changes.py input.docx output.docx

このステップは LibreOffice に依存します。
レビューされた文書を「クリーンなバージョン」に整理するのに適しています。

シナリオ 5: コメントを追加する

1
2


python comment.py unpacked/ 0 "Comment text"
python comment.py unpacked/ 1 "Reply text" --parent 0

ここでは特別な注意を払う必要があります。スクリプトはコメントの内容と必要なコメントコンポーネントのみを追加します。実際、コメントを対応するテキスト範囲に実際に添付するには、コメントの指示に従ってコメント範囲マーカーを document.xml に追加する必要があります。

このスキルの最も注意すべき落とし穴

SKILL.md をざっと見ただけでは、その「互換性ルール」の価値を過小評価するのは簡単です。
特に以下の点は覚えておいてください。

1. `.docx` はテキストファイルではなく、Office パッケージです

最も危険な誤解は、これを「フォーマットされたテキストファイル」として扱うことです。
実際、変更には以下も含まれる場合があります。

テキスト XML
relationships
content types
comments / people / ids
スキーマ制約
リビジョンセマンティクス

そのため、このスキルでは「パッケージの開梱、編集、確認、返却」に重点が置かれています。

2. `docx-js` はドキュメントを生成できますが、デフォルトのパラメーターが目的を満たしているという保証はありません。

SKILL.md は、次のような多くのデフォルト値の落とし穴を強調表示します。

デフォルトの用紙はA4です
水平方向のページ幅と高さの処理には内部ロジックがあります
リストに箇条書き文字を直接挿入することはできません
テーブル幅を二重に宣言する必要があります
Google ドキュメントはパーセント幅との互換性が低い

これは、生成ツールが出発点にすぎず、最終的な品質を保証するものではないことを示しています。

3. コメントと修正は単一点の修正ではありません

コメントであっても、変更の追跡であっても、XML を変更するだけの問題ではありません。
複数のコンポーネント間で一貫性を維持する必要があるため、スキルはこれらのアクションをスクリプト化します。

4.「オープンできる」は「修正される」という意味ではない

文書を Word で開くことができるからといって、その構造が正しいとは限りません。
多くのエラーは、次のシナリオでのみ公開されます。

再度編集するとクラッシュする
レビューモード例外
注釈がありません
Google ドキュメントを開いた後にレイアウトが崩れる
リビジョンを再度受け入れるときにエラーが発生する

したがって、validate.py と pack.py --original は非常に重要です。

5. 外部ツールを利用する場合は事前に環境を準備する

このスキルは、いくつかの種類の外部ツールに依存しています。

pandoc
LibreOffice / soffice
docx-js
Python の依存関係 (defusedxml、lxml など)

これらのツールが環境にない場合、エージェントがプロセスを知っていても、それを完全に実行することはできません。

このスキルは何に向いていて、何が不向きなのでしょうか？

適切な

Word レポートをバッチ生成する
構造化された正式文書の生成
自動変更 .docx
追跡された変更を保存または処理する
コメントを自動的に追加する
Word ドキュメントをスクリプトまたはエージェントワークフローに組み込む

あまり適していない

PDF をエクスポートするだけの簡単なシナリオ
プレーンテキストコンテンツのみが必要で、Word 形式は気にしません
手動によるビジュアル編集に完全に依存している
依存関係や環境の準備を一切せずに、すべての Word 自動化を完了したいと考えています。

要約する

Anthropic の skills/docx の強みは、「Word を生成する」ことではなく、「Word が問題を起こしやすい理由を知り、問題を事前に分解する」ことにあります。
これは、ドキュメント生成、基礎となる XML 編集、リビジョンセマンティクス、スキーマ検証、および Office 互換性に関する元々散在していた知識を実行可能なワークフローに編成します。

単純なドキュメントを時々エクスポートするだけの場合は、少し重く感じるかもしれません。
ただし、シナリオに既存の .docx の変更、コメント、リビジョン、自動バッチ処理、または互換性要件が含まれる限り、この一連のスキルは貴重です。AI が無視する可能性が最も高く、Office ドキュメントが覆される可能性が最も高い詳細を正確に埋めるためです。

簡単な要約は次のとおりです。

SKILL.md はエージェントにどちらの方向を取るかを伝える責任があります
scripts/office/* は開梱、返品、チェック、Office の互換性を担当します。
comment.py と accept_changes.py は Word の特殊能力を担当します
schemas/ とバリデーターは、「機能しているようだ」を「構造的に信頼できる」に改善する責任があります。

コードアドレス：https://github.com/anthropics/skills/tree/main/skills/docx

このスキルはどのような問題を解決しますか?

ディレクトリとコードの構成

1. 説明レイヤー: SKILL.md

2. Office パッケージ操作層: scripts/office/*

unpack.py

pack.py

validate.py

soffice.py