• Projects
  • Service
  • About
  • branding.bz
  • Podcast
  • Tips
  • FAQ
  • Recruit
  • Download
  • Contact
  • branding.bz(ブランド構築SaaS)
  • DESIGN NOW(デザインメディア)
  • X
  • LinkedIn
  • Spotify
  • Facebook

213-0011 神奈川県川崎市高津区久本3-6-7-303

© 2026 ID INC. All rights reserved

claude-skills/スキル
SKILLSkills

docx

プラグイン
document-skills
ライセンス
Proprietary. LICENSE.txt has complete terms
ソース
GitHub で見る ↗
説明

このスキルは、ユーザーがWord文書(.docxファイル)またはWordテンプレート(.dotxファイル)を作成・閲覧・編集・操作したい場合に使用してください。 **使用する場合:** - 「Word文書」「.docx」「.dotx」などの言及がある場合 - 目次・見出し・ページ番号・レターヘッドといった書式を整えたプロフessional文書の作成が求められる場合 - .docxまたは.dotxファイルから内容を抽出したり、整理し直したりする場合 - 文書に画像を挿入・置換する場合 - Word文書内で検索・置換機能を使う場合 - 変更履歴やコメント機能を使う場合 - レポート・メモ・手紙・テンプレートなど、Word形式または.docx形式の成果物に内容を整形する場合 **使用しないでください:** - PDF、スプレッドシート、Google Docsの場合 - 文書生成と無関係なコーディング作業の場合

原文を表示

Use this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files) or Word templates (.dotx files). Triggers include: any mention of 'Word doc', 'word document', '.docx', '.dotx', or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx or .dotx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a 'report', 'memo', 'letter', 'template', or similar deliverable as a Word or .docx file, use this skill. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.

ユースケース
  • Word文書やテンプレートを作成したい
  • Professional文書の書式を整えたい
  • .docxファイルから内容を抽出したい
  • Word文書に画像を挿入・置換したい
  • 文書内で検索・置換機能を使いたい
本文(日本語訳)

DOCX ファイルの作成、編集、分析

.docx ファイルは XML ファイルを圧縮した ZIP アーカイブです。作業内容に応じて次のいずれかの方法を選んでください:

作業内容 方法
新しいドキュメントを作成 docx(npm パッケージ)スクリプトを実行 — 注意点は下記参照
既存のドキュメントを編集 unzip → word/document.xml を編集 → zip(docx-js は既存ファイルを開けません)
内容を読み込む pandoc -t markdown file.docx を実行

以下のスクリプト パスはこのスキルのディレクトリからの相対パスです。

docx-js での作成時の注意点

docx は事前インストール済みです — 最初に npm install を実行しないでください。スクリプトを書いて require('docx') を直接使用してください。この require が失敗する場合のみ npm install docx を実行してください。モデルは API を理解していますが、以下の落とし穴に注意:

  • ページサイズは A4 が初期値です。 US Letter サイズにするには page: { size: { width: 12240, height: 15840 } } を設定してください(DXA 単位;1440 = 1 インチ)。
  • 横向きレイアウト: 縦向きの寸法を指定し、orientation: PageOrientation.LANDSCAPE を渡してください — docx-js が内部で幅と高さを自動で入れ替えます。
  • 表は二重の幅設定が必要: テーブルに columnWidths を、すべてのセルに width を設定し、両方とも WidthType.DXA で指定してください(PERCENTAGE は Google Docs で動作しません)。列の幅の合計はテーブル幅と一致する必要があります。
  • 表の背景色: ShadingType.CLEAR を使用し、SOLID は使わないでください(黒くレンダリングされます)。
  • リスト: • を直接挿入しないでください。numbering 設定と LevelFormat.BULLET を使用してください。
  • ImageRun には type: が必須です:("png"、"jpg"など)。
  • PageBreak は Paragraph の中に置く必要があります。
  • \n を使わないでください — 個別の Paragraph 要素を使用してください。
  • 目次: 見出しは組み込みの HeadingLevel.* を使う必要があります。カスタム見出しスタイルは outlineLevel を設定しないと目次に表示されません。
  • 水平線として表を使わないでください — 段落の下端ボーダーを使用してください。
  • ドットリーダー / 同じ行の右揃え: リテラルの . またはスペース パディングではなく、TextRun 内で PositionalTab(alignment: PositionalTabAlignment.RIGHT、leader: PositionalTabLeader.DOT)を使用してください。

出力内容の確認

.docx を作成した後、レンダリングして表示してください:

python scripts/office/soffice.py --headless --convert-to pdf output.docx
pdftoppm -jpeg -r 100 output.pdf page
ls page-*.jpg   # 画像を確認してください

pdftoppm はページ番号をページ数の桁数に合わせてゼロパディングします(page-01.jpg…page-12.jpg)。

既存ドキュメントの編集

従来の .doc ファイルはまず変換する必要があります:python scripts/office/soffice.py --headless --convert-to docx file.doc。

unzip -q doc.docx -d unpacked/
find unpacked -type l -delete   # シンボリックリンク エントリを削除 — 外部からの docx は信頼できません
python scripts/merge_runs.py unpacked/   # テキストが検索可能になるよう、細切れになったテキスト単位を統合
# unpacked/word/document.xml をその場で編集 — 整形やきれいに表示しなおさないでください
(cd unpacked && rm -f ../out.docx && zip -Xr ../out.docx .)
python scripts/office/validate.py out.docx --original doc.docx   # XSD チェック;--auto-repair で一般的な問題を修正
# 変更追跡を使う場合は、--author "<変更追跡名>" を追加して、すべての編集が追跡されていることを確認してください

Word はテキストを多くの <w:r> テキスト単位(変更 ID、スペルチェック マーカー)に分割するため、ドキュメントで見えるフレーズが XML に連続した文字列として存在しないことがよくあります。merge_runs.py は word/document.xml の隣接した同じ書式の単位を内容またはレンダリングを変えずに統合します。また、.docx ファイルを直接受け入れることもできます(python scripts/merge_runs.py doc.docx -o merged.docx)。

変更追跡: 変更を加える際は、--author "<変更追跡名>" で検証してください(--original が必要)— <w:ins>/<w:del> で囲まれていないテキストを報告します。これは誤って実行しやすく、受け入れたビューでは見えません。<w:ins>/<w:del> で w:id、w:author、w:date 属性を持つテキスト単位をラップしてください。<w:del> の内側では、テキスト要素は <w:t> ではなく <w:delText> です。削除された段落記号(<w:pPr><w:rPr><w:del w:id=".." w:author=".." w:date=".."/></w:rPr></w:pPr>)は「この段落を次の段落に統合」を意味します — 段落全体を削除するには、それにすべてのテキスト単位の周りに <w:del> を加えます。<w:del/> は rPr の他の子要素より前に来る必要があります。順序はスキーマで強制されます。

すべての変更を受け入れたきれいなコピーを作成するには:python scripts/accept_changes.py in.docx out.docx。

削除された段落記号を受け入れると、その段落が下の段落に結合されるはずです。そのため、テキスト単位がすべて削除された段落は消えます。Word はこれを正しく行いますが、accept_changes.py と pandoc --track-changes=accept は常にはうまくいきません。両方とも同じ方法で失敗します — 削除されたテキストを削除しますが、空になった段落を残します。自動番号の場合、これは迷い弾としてのブレット ポイントと読まれます:

  • pandoc --track-changes=accept は段落を結合しません。
  • accept_changes.py(LibreOffice)は正しく結合しますが、削除された段落の後に空のスペーサー段落がある場合は除きます。

どちらのビューでも空のブレット ポイントはそのビューの加工品であり、ドキュメント自体の欠陥ではありません。XML で段落の削除を確認してください。

コメント

コメントには 6 つの相互リンクされたファイルが必要です。また編集する場合はディレクトリ モード(unzip/rezip サイクルを節約)、それ以外は .docx ダイレクト モードを使用してください:

# 既に展開されたディレクトリに対して(マーカーを配置する場合は推奨)
python scripts/comment.py unpacked/ "Fees & expenses cap is too low"
python scripts/comment.py unpacked/ "Agreed" --parent 0

# .docx に直接
python scripts/comment.py contract.docx "This cap is too low" -o annotated.docx

スクリプトは comments.xml、commentsExtended.xml、commentsIds.xml、commentsExtensible.xml、関連ファイル、コンテンツ タイプ オーバーライドを書き込みます。コメント ID は自動割り当てされます。その後、word/document.xml に追加する <w:commentRangeStart>/<w:commentRangeEnd>/<w:commentReference> スニペットを出力します。これにより、特定のテキストにコメントが固定されます — マーカーを配置するまで、コメントは存在しますが表示されません。

依存関係

docx(npm、事前インストール済み — require('docx') が失敗する場合のみインストール)· pandoc · LibreOffice(soffice)· pdftoppm(Poppler)

原文(English)を表示

DOCX creation, editing, and analysis

A .docx is a ZIP archive of XML files. Choose your approach by task:

Task Approach
Create a new document Write a docx (npm) script — see gotchas below
Edit an existing document unzip → edit word/document.xml → zip (docx-js cannot open existing files)
Read content pandoc -t markdown file.docx

Script paths below are relative to this skill's directory.

Creating with docx-js — gotchas

docx is preinstalled — do not run npm install first; write the script and require('docx') directly. Only if that require fails: npm install docx. The model knows the API; these are the footguns:

  • Page size defaults to A4. For US Letter set page: { size: { width: 12240, height: 15840 } } (DXA; 1440 = 1″).
  • Landscape: pass portrait dimensions and orientation: PageOrientation.LANDSCAPE — docx-js swaps width/height internally.
  • Tables need dual widths: set columnWidths on the table AND width on every cell, both in WidthType.DXA (PERCENTAGE breaks in Google Docs). Column widths must sum to the table width.
  • Table shading: use ShadingType.CLEAR, never SOLID (renders black).
  • Lists: never insert • literally; use a numbering config with LevelFormat.BULLET.
  • ImageRun requires type: ("png", "jpg", …).
  • PageBreak must be inside a Paragraph.
  • Never use \n — use separate Paragraph elements.
  • TOC: headings must use built-in HeadingLevel.*; custom heading styles need outlineLevel set or they won't appear.
  • Don't use a table as a horizontal rule — use a paragraph bottom border instead.
  • Dot-leader / right-aligned-on-same-line: use PositionalTab (alignment: PositionalTabAlignment.RIGHT, leader: PositionalTabLeader.DOT) inside a TextRun, not literal . or space padding.

Verify the output

After writing a .docx, render it and look at it:

python scripts/office/soffice.py --headless --convert-to pdf output.docx
pdftoppm -jpeg -r 100 output.pdf page
ls page-*.jpg   # then Read the images

pdftoppm zero-pads page numbers to the width of the page count (page-01.jpg…page-12.jpg).

Editing existing documents

Legacy .doc files must be converted first: python scripts/office/soffice.py --headless --convert-to docx file.doc.

unzip -q doc.docx -d unpacked/
find unpacked -type l -delete   # strip symlink entries — docx from external parties is untrusted
python scripts/merge_runs.py unpacked/   # coalesce fragmented runs so text is findable
# edit unpacked/word/document.xml in place — do NOT reformat or pretty-print
(cd unpacked && rm -f ../out.docx && zip -Xr ../out.docx .)
python scripts/office/validate.py out.docx --original doc.docx   # XSD checks; --auto-repair fixes common issues
# redlining? add --author "<the name you redlined under>" to check every edit is tracked

Word splits text across many <w:r> runs (revision ids, spell-check markers), so a phrase you can see in the document often doesn't exist as a contiguous string in the XML. merge_runs.py merges adjacent identically-formatted runs in word/document.xml without changing content or rendering; it also accepts a .docx directly (python scripts/merge_runs.py doc.docx -o merged.docx).

Tracked changes: when redlining, validate with --author "<the name you redlined under>" (needs --original) — it reports any text you changed without a <w:ins>/<w:del> around it, which is easy to do by accident and invisible in the accepted view. Wrap runs in <w:ins>/<w:del> with w:id, w:author, w:date attributes. Inside <w:del>, the text element is <w:delText>, not <w:t>. A deleted paragraph mark (<w:pPr><w:rPr><w:del w:id=".." w:author=".." w:date=".."/></w:rPr></w:pPr>) means "merge this paragraph into the next" — so deleting a paragraph outright is that plus a <w:del> around every run. The <w:del/> must come before the rPr's other children; their order is schema-enforced.

To produce a clean copy with all tracked changes accepted: python scripts/accept_changes.py in.docx out.docx.

Accepting a deleted paragraph mark should join that paragraph to the one below it, so a paragraph whose runs are all deleted vanishes. Word does this; accept_changes.py and pandoc --track-changes=accept don't always. Both fail the same way — they strip the deleted text but leave the emptied paragraph behind, which reads as a stray empty bullet when it was auto-numbered:

  • pandoc --track-changes=accept never joins the paragraphs.
  • accept_changes.py (LibreOffice) joins them correctly, except when the deleted paragraph is followed by an empty spacer paragraph.

An empty bullet in either view is an artifact of that view, not a defect in the document. Check paragraph deletions in the XML.

Comments

Comments require six cross-linked files. Use the helper — directory mode when you'll also be editing document.xml (saves an unzip/rezip cycle), .docx-direct mode otherwise:

# Against an already-unpacked directory (preferred when also placing markers)
python scripts/comment.py unpacked/ "Fees & expenses cap is too low"
python scripts/comment.py unpacked/ "Agreed" --parent 0

# Against a .docx directly
python scripts/comment.py contract.docx "This cap is too low" -o annotated.docx

The script writes comments.xml, commentsExtended.xml, commentsIds.xml, commentsExtensible.xml, the relationships, and the content-type overrides. Comment IDs are auto-assigned. It then prints the <w:commentRangeStart>/<w:commentRangeEnd>/<w:commentReference> snippet to add to word/document.xml so the comment anchors to specific text — until you place those markers, the comment exists but is not visible.

Dependencies

docx (npm, preinstalled — install only if require('docx') fails) · pandoc · LibreOffice (soffice) · pdftoppm (Poppler)

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。