docx-tracked-changes

Word Doc Tracked Changes Skill

Word 文書に適切な形式の変更履歴（挿入、削除、置換、余白コメント）を作成します。変更履歴は、元の文書にそのまま適用できる形式で整えられます。.docx の変更履歴と編集履歴の生成における Opus 4.7 の改善を活用できるように設計されています。

必要な入力

与えられた情報をもとに作業します。以下の項目が不足している場合でも、完全な出力を作成してください。それぞれの不足分には妥当な仮定を補い、(仮定、要確認) と記して、最後に仮定を列挙します。中心となるテーマ自体が不明（何について書けばよいか分からない）場合に限り、先に質問してください。

• 文書（テキストを貼り付けるか、.docx をアップロード）
• レビューの種類（法務レビュー／コピー編集／内容の実質的な書き換え／コンプライアンスチェック／平易な英語への書き換え）
• レビュー範囲（文書全体／特定のセクション／特定の条項の種類）
• レビュアーの役割（著者／マネージャー／法務顧問／分野の専門家）

出力形式

1. 変更履歴の概要

文書： [名前または識別子] レビューの種類： [指定された内容] レビュアー： [役割] 変更の合計： [挿入：N／削除：N／コメント：N] 全体評価： [1～2文。文書はほぼ完成しているか、大幅な修正が必要か]

2. 主な変更点

文書の意味または構成に影響する変更：

変更 N — [セクションまたは段落の参照先]

• 原文：「[原文を正確に記載]」
• 提案：「[提案する新しい文]」
• 理由：[この変更を提案する理由 — 内容／法務／明瞭さ]

3. 行ごとの変更履歴

変更が必要な各段落について、次の形式で記載します。

[段落の参照先 — 例：「セクション 3、段落 2」]

原文：

[原文の段落を正確に記載]

変更履歴：

[削除箇所に 取り消し線、挿入箇所に 太字 を付けた同じ段落]

クリーン版：

[変更を適用した後の最終版のテキスト]

4. 余白コメント

具体的な文案を提案せずに問題を指摘するコメント：

コメント N — [場所] 「[レビュアー自身が書くようなコメント。直接的で、具体的かつ実行可能な内容。]」

コメントの例：

• 「この条項はセクション 7 と矛盾しています。整合性を取ってください」
• 「全体で使用されている［用語］の定義がありません」
• 「数値を財務チームに確認してください」

5. 文体上の編集

文単位の文体上の変更（対象範囲にコピー編集が含まれる場合）：

場所	変更前	変更後	理由
段落 3	[テキスト]	[テキスト]	[読みやすさ／文法／一貫性]

6. パターンに関する指摘

文書全体で繰り返される問題：

[パターン — 例：「受動態の多用」]

• 該当箇所数：[数]
• 例：[具体的な場所を2～3箇所]
• 推奨する対応：[対処方法]

7. レビューの完了状況

レビュー項目	対応済み
文法と構文	はい／いいえ
明瞭さと読みやすさ	はい／いいえ
内容の正確性	はい／いいえ／該当なし
コンプライアンス／法務チェック	はい／いいえ／該当なし
参照文書との一貫性	はい／いいえ／該当なし

8. 変更の適用方法

変更履歴を適用する手順：

Microsoft Word の場合：

1. 変更履歴を有効にします（［校閲］タブ → ［変更履歴の記録］）
2. セクション 3 の変更を順に適用します
3. ［校閲］→［新しいコメント］を使用して、セクション 4 のコメントを追加します
4. 変更履歴付きの文書をレビュアーに返送します

Google ドキュメントの場合：

1. 提案モードに切り替えます（右上の鉛筆アイコン）
2. セクション 3 の変更を適用します
3. 余白のコメントボタンを使用してコメントを追加します

品質チェック

• すべての変更履歴で原文が正確に保持されている
• 内容に関する変更と文体上の変更が分けられている
• コメントはメタコメントではなく、レビュアー自身が書くような内容になっている
• パターンに関する問題が個別の変更と分けて特定されている
• 適用手順が対象プラットフォームに合っている

アンチパターン

• 追跡される削除を作成する際に元のテキストを言い換えないでください — 元のテキストは文字単位で正確に保持される必要があります。そうでなければ、追跡された変更をソースと照合してレビューできません
• 同一セクション内で実質的な変更と文体上の編集を混在させないでください — レビュー担当者は、コピー編集とは異なる基準で実質的な変更を承認する必要があります
• レビュープロセスに関するメタコメンタリーとしてマージンコメントを書かないでください（「このセクションは要修正」） — コメントは、著者が実行できる実行可能な指示でなければなりません
• 不完全な文をすべて変更として指摘しないでください — 過剰なレッドラインは、著者に変更を読まずに受け入れる習慣を身につけさせ、追跡レビューの目的を損ないます
• トップレベルの変更の要約なしにレッドラインを作成しないでください — レビュー担当者はまず要約を読み、どの変更を詳細に精査するかを決めます

トリガーフレーズの例

• 「この契約書をレッドラインして」
• 「この文書の追跡変更を作成して」
• 「この文書に提案された編集をマークアップして」
• 「これをレビューして、追跡変更形式で変更を提案して」
• 「この下書きのレッドライン版をください」

これが Opus 4.7 でよりうまく機能する理由

追跡変更では、モデルが代替案を提案しつつソーステキストを正確に保持する必要があります — 以前のモデルは元のテキストを言い換えたり、どのテキストが元でどれが提案されたものかを追跡できなくなったりしていました。Opus 4.7 の改善は、まさにこのワークフローを対象としています。