# docx

> 追跡変更、コメント、フォーマット保持、テキスト抽出をサポートする包括的なドキュメント作成、編集、分析。Claudeがプロフェッショナルドキュメント（.docxファイル）で作業する必要がある場合：(1) 新しいドキュメントを作成、(2) コンテンツを変更または編集、(3) 追跡変更で作業、(4) コメントを追加、またはその他のドキュメントタスク

- Author: mahha
- Repository: mahha/anthropic_skills
- Version: 20260105081446
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-07
- Source: https://github.com/mahha/anthropic_skills
- Web: https://mule.run/skillshub/@@mahha/anthropic_skills~docx:20260105081446

---

---
name: docx
description: "追跡変更、コメント、フォーマット保持、テキスト抽出をサポートする包括的なドキュメント作成、編集、分析。Claudeがプロフェッショナルドキュメント（.docxファイル）で作業する必要がある場合：(1) 新しいドキュメントを作成、(2) コンテンツを変更または編集、(3) 追跡変更で作業、(4) コメントを追加、またはその他のドキュメントタスク"
license: プロプライエタリ。完全な条件はLICENSE.txtに記載されています
---

# DOCX作成、編集、分析

## 概要

ユーザーが.docxファイルの作成、編集、または内容の分析を依頼する場合があります。.docxファイルは、基本的に読み取りまたは編集できるXMLファイルとその他のリソースを含むZIPアーカイブです。タスクごとに異なるツールとワークフローが利用可能です。

## ワークフロー意思決定ツリー

### コンテンツの読み取り/分析
以下の「テキスト抽出」または「生XMLアクセス」セクションを使用します

### 新しいドキュメントを作成
「新しいWordドキュメントを作成」ワークフローを使用します

### 既存のドキュメントを編集
- **自分のドキュメント + 簡単な変更**
  「基本的なOOXML編集」ワークフローを使用します

- **他の人のドキュメント**
  **「レッドライニングワークフロー」**を使用します（推奨デフォルト）

- **法的、学術、ビジネス、または政府のドキュメント**
  **「レッドライニングワークフロー」**を使用します（必須）

## コンテンツの読み取りと分析

### テキスト抽出
ドキュメントのテキストコンテンツを読み取るだけの場合、pandocを使用してドキュメントをマークダウンに変換する必要があります。Pandocは、ドキュメント構造を保持する優れたサポートを提供し、追跡変更を表示できます：

```bash
# 追跡変更を保持してドキュメントをマークダウンに変換
pandoc --track-changes=all path-to-file.docx -o output.md
# オプション: --track-changes=accept/reject/all
```

### 生XMLアクセス
コメント、複雑なフォーマット、ドキュメント構造、埋め込みメディア、メタデータには生XMLアクセスが必要です。これらの機能のいずれかについて、ドキュメントをアンパックして生XMLコンテンツを読み取る必要があります。

#### ファイルをアンパック
`python ooxml/scripts/unpack.py <office_file> <output_directory>`

#### 主要なファイル構造
* `word/document.xml` - メインドキュメントコンテンツ
* `word/comments.xml` - document.xmlで参照されるコメント
* `word/media/` - 埋め込み画像とメディアファイル
* 追跡変更は`<w:ins>`（挿入）と`<w:del>`（削除）タグを使用します

## 新しいWordドキュメントを作成

ゼロから新しいWordドキュメントを作成する場合、JavaScript/TypeScriptを使用してWordドキュメントを作成できる**docx-js**を使用します。

### ワークフロー
1. **必須 - ファイル全体を読み取る**: [`docx-js.md`](docx-js.md)（約500行）を最初から最後まで完全に読み取ります。**このファイルを読み取る際、範囲制限を設定しないでください。** ドキュメント作成に進む前に、詳細な構文、重要なフォーマット規則、ベストプラクティスについてファイル全体のコンテンツを読み取ります。
2. Document、Paragraph、TextRunコンポーネントを使用してJavaScript/TypeScriptファイルを作成します（すべての依存関係がインストールされていると想定できますが、そうでない場合は、以下の依存関係セクションを参照してください）
3. Packer.toBuffer()を使用して.docxとしてエクスポートします

## 既存のWordドキュメントを編集

既存のWordドキュメントを編集する場合、**Documentライブラリ**（OOXML操作のためのPythonライブラリ）を使用します。このライブラリは、インフラストラクチャのセットアップを自動的に処理し、ドキュメント操作のためのメソッドを提供します。複雑なシナリオでは、ライブラリを通じて基になるDOMに直接アクセスできます。

### ワークフロー
1. **必須 - ファイル全体を読み取る**: [`ooxml.md`](ooxml.md)（約600行）を最初から最後まで完全に読み取ります。**このファイルを読み取る際、範囲制限を設定しないでください。** DocumentライブラリAPIとドキュメントファイルを直接編集するためのXMLパターンについて、ファイル全体のコンテンツを読み取ります。
2. ドキュメントをアンパック：`python ooxml/scripts/unpack.py <office_file> <output_directory>`
3. Documentライブラリを使用してPythonスクリプトを作成して実行します（ooxml.mdの「Document Library」セクションを参照）
4. 最終ドキュメントをパック：`python ooxml/scripts/pack.py <input_directory> <office_file>`

Documentライブラリは、一般的な操作のための高レベルメソッドと、複雑なシナリオのための直接DOMアクセスの両方を提供します。

## ドキュメントレビューのためのレッドライニングワークフロー

このワークフローでは、OOXMLで実装する前に、マークダウンを使用して包括的な追跡変更を計画できます。**重要**: 完全な追跡変更の場合、すべての変更を体系的に実装する必要があります。

**バッチング戦略**: 関連する変更を3-10個の変更のバッチにグループ化します。これにより、デバッグが管理しやすくなり、効率を維持します。次のバッチに進む前に各バッチをテストします。

**原則：最小限で正確な編集**
追跡変更を実装する場合、実際に変更されたテキストのみをマークします。変更されていないテキストを繰り返すと、編集のレビューが困難になり、非専門的に見えます。置換を以下に分割します：[変更されていないテキスト] + [削除] + [挿入] + [変更されていないテキスト]。変更されていないテキストについては、元の`<w:r>`要素を抽出して再利用することで、元の実行のRSIDを保持します。

例 - 文で「30 days」を「60 days」に変更：
```python
# 悪い - 文全体を置換
'<w:del><w:r><w:delText>The term is 30 days.</w:delText></w:r></w:del><w:ins><w:r><w:t>The term is 60 days.</w:t></w:r></w:ins>'

# 良い - 変更されたもののみをマークし、変更されていないテキストの元の<w:r>を保持
'<w:r w:rsidR="00AB12CD"><w:t>The term is </w:t></w:r><w:del><w:r><w:delText>30</w:delText></w:r></w:del><w:ins><w:r><w:t>60</w:t></w:r></w:ins><w:r w:rsidR="00AB12CD"><w:t> days.</w:t></w:r>'
```

### 追跡変更ワークフロー

1. **マークダウン表現を取得**: 追跡変更を保持してドキュメントをマークダウンに変換：
   ```bash
   pandoc --track-changes=all path-to-file.docx -o current.md
   ```

2. **変更を識別してグループ化**: ドキュメントをレビューし、必要なすべての変更を識別し、論理的なバッチに整理します：

   **位置特定方法**（XMLで変更を見つけるため）：
   - セクション/見出し番号（例：「セクション3.2」、「記事IV」）
   - 番号が付けられている場合は段落識別子
   - 一意の周囲テキストを含むGrepパターン
   - ドキュメント構造（例：「最初の段落」、「署名ブロック」）
   - **マークダウンの行番号を使用しないでください** - XML構造にマッピングされません

   **バッチ組織**（バッチごとに3-10個の関連する変更をグループ化）：
   - セクション別：「バッチ1：セクション2の修正」、「バッチ2：セクション5の更新」
   - タイプ別：「バッチ1：日付の修正」、「バッチ2：当事者名の変更」
   - 複雑さ別：簡単なテキスト置換から始め、次に複雑な構造変更に取り組みます
   - 順次：「バッチ1：ページ1-3」、「バッチ2：ページ4-6」

3. **ドキュメントを読み取り、アンパック**：
   - **必須 - ファイル全体を読み取る**: [`ooxml.md`](ooxml.md)（約600行）を最初から最後まで完全に読み取ります。**このファイルを読み取る際、範囲制限を設定しないでください。** 「Document Library」と「Tracked Change Patterns」セクションに特に注意してください。
   - **ドキュメントをアンパック**: `python ooxml/scripts/unpack.py <file.docx> <dir>`
   - **推奨RSIDをメモ**: アンパックスクリプトは、追跡変更に使用するRSIDを提案します。このRSIDをコピーして、ステップ4bで使用します。

4. **バッチで変更を実装**: 変更を論理的にグループ化（セクション別、タイプ別、または近接性別）し、単一のスクリプトで一緒に実装します。このアプローチ：
   - デバッグを容易にします（小さなバッチ = エラーの分離が容易）
   - 段階的な進捗を可能にします
   - 効率を維持します（3-10個の変更のバッチサイズがうまく機能します）

   **推奨バッチグループ化：**
   - ドキュメントセクション別（例：「セクション3の変更」、「定義」、「終了条項」）
   - 変更タイプ別（例：「日付の変更」、「当事者名の更新」、「法的用語の置換」）
   - 近接性別（例：「ページ1-3の変更」、「ドキュメントの前半の変更」）

   関連する変更の各バッチについて：

   **a. テキストをXMLにマッピング**: `word/document.xml`でテキストをgrepして、テキストが`<w:r>`要素間でどのように分割されているかを確認します。

   **b. スクリプトを作成して実行**: `get_node`を使用してノードを見つけ、変更を実装し、次に`doc.save()`を実行します。パターンについては、ooxml.mdの**「Document Library」**セクションを参照してください。

   **注意**: スクリプトを書く直前に常に`word/document.xml`をgrepして、現在の行番号を取得し、テキストコンテンツを確認します。各スクリプト実行後に行番号が変わります。

5. **ドキュメントをパック**: すべてのバッチが完了したら、アンパックされたディレクトリを.docxに戻します：
   ```bash
   python ooxml/scripts/pack.py unpacked reviewed-document.docx
   ```

6. **最終検証**: 完全なドキュメントの包括的なチェックを実行します：
   - 最終ドキュメントをマークダウンに変換：
     ```bash
     pandoc --track-changes=all reviewed-document.docx -o verification.md
     ```
   - すべての変更が正しく適用されたことを確認：
     ```bash
     grep "original phrase" verification.md  # 見つからないはず
     grep "replacement phrase" verification.md  # 見つかるはず
     ```
   - 意図しない変更が導入されていないことを確認します


## ドキュメントを画像に変換

Wordドキュメントを視覚的に分析するには、2段階のプロセスを使用して画像に変換します：

1. **DOCXをPDFに変換**：
   ```bash
   soffice --headless --convert-to pdf document.docx
   ```

2. **PDFページをJPEG画像に変換**：
   ```bash
   pdftoppm -jpeg -r 150 document.pdf page
   ```
   これにより、`page-1.jpg`、`page-2.jpg`などのファイルが作成されます。

オプション：
- `-r 150`: 解像度を150 DPIに設定（品質/サイズのバランスを調整）
- `-jpeg`: JPEG形式で出力（PNGが必要な場合は`-png`を使用）
- `-f N`: 変換する最初のページ（例：`-f 2`はページ2から開始）
- `-l N`: 変換する最後のページ（例：`-l 5`はページ5で停止）
- `page`: 出力ファイルのプレフィックス

特定の範囲の例：
```bash
pdftoppm -jpeg -r 150 -f 2 -l 5 document.pdf page  # ページ2-5のみを変換
```

## コードスタイルガイドライン
**重要**: DOCX操作のコードを生成する場合：
- 簡潔なコードを記述します
- 冗長な変数名と冗長な操作を避けます
- 不要なprint文を避けます

## 依存関係

必要な依存関係（利用できない場合はインストール）：

- **pandoc**: `sudo apt-get install pandoc`（テキスト抽出用）
- **docx**: `npm install -g docx`（新しいドキュメント作成用）
- **LibreOffice**: `sudo apt-get install libreoffice`（PDF変換用）
- **Poppler**: `sudo apt-get install poppler-utils`（pdftoppmでPDFを画像に変換するため）
- **defusedxml**: `pip install defusedxml`（安全なXML解析用）