AI ヒューマナイザーの DOCX テスト：Track Changes とコメントは残るのか

2026年8月31日に実施した HumanPen のテストでは、答えはイエスだった。選択した 133 語の段落 1 つは書き換わったが、追跡された挿入 1 件、追跡された削除 1 件、レビューアーのコメント 1 件、コンテンツコントロール 1 件、ブックマークと REF フィールド 1 組、表 1 つは、返ってきた DOCX に残っていた。この記事は HumanPen が公開しており、テストも自社製品で実施している。ただしこれはファイル 1 つ・実行 1 回の結果であり、あらゆる Word 文書に対する保証ではない。

このテストでは検出器を使っていない。問いはもっと限定的だった。特定の段落を書き換えたとき、その段落の外にある Word のオブジェクトはどうなるのか、という点である。

ファイルは 3 つのレベルで確認した。まず Word 内部の構造を数え、次に DOCX パッケージ内の全パートを比較し、最後に入力と出力をレンダリングしてページを比較した。1 つだけ実施できなかった確認がある。ローカルのコンピューター操作権限が使えなかったため、出力を Microsoft Word で手動で開き、保存し、閉じて、再度開くという作業ができなかった。この穴は重要であり、開いたままである。

入力はこの実験のために作った合成文書で、2 ページ構成だった。学生のレポート、研究データ、顧客資料は一切含まれていない。1 ページ目には、数えたい Word オブジェクトを配置した。2 ページ目には、書き換え対象としてマークした通常の段落を 1 つだけ置いた。

センチネルには `TRACK-ANCHOR-23`、`COMMENT-ANCHOR-47`、`CONTROL-TABLE-91`、`37.5%`、`12.40 mg` が含まれていた。ブックマークのラベルは意図的に 2 回現れる。1 回はブックマーク自体に、もう 1 回は表示された REF の結果としてである。

この設定には重要な境界がある。計測対象のオブジェクトはすべて、選択した段落の外側に置いた。この実行は、書き換え範囲が確定している外側での保持を検証するものだ。コメントのアンカー、追跡された変更、フィールド、コンテンツコントロールが書き換えられる段落の内側にあった場合に何が起こるかは、ここからは分からない。

手を付けていない入力は 40,191 バイトで、SHA-256 は次のとおりである。

`cccbac04cf9742037b16c453b54ae3c8a2300e7491ba31a213566c979c6fe4f1`

このハッシュは、今回の実行で使った入力そのものを識別する。Word 上で同じに見えるファイルであっても、別のファイルなら別のハッシュになる。

2026年8月31日 20:00（中国標準時）に、DOCX を HumanPen にアップロードした。戦略は Balanced v3、モードは指定コンテンツを選び、開始前に範囲が段落 1 つ・英単語 133 語であることを確認した。

32 秒という所要時間と 14 クレジットの消費は、このジョブの記録であって、他のファイルに対する約束ではない。処理時間とコストは、選択するテキストや製品の状態によって変わり得る。

出力のハッシュが入力のハッシュと異なるのは、あるべき姿だ。選択した段落が変わったのだから。ファイル全体のハッシュは 2 つのファイルが異なることは証明できるが、その違いが意図した段落だけに収まっているかどうかまでは分からない。それを確かめるには、パートごとの比較が必要だった。

DOCX は、XML パート、リレーションシップ、メディア、スタイルといったリソースを格納した ZIP パッケージである。入力と出力はどちらも 20 個のパートを含み、パート名の集合は完全に一致していた。

七つのセンチネルグループも、入力時の件数を保った。パーセント表記は `37.5%` のまま、測定値は `12.40 mg` のままで、保護されたアンカーの出現回数が増減することもなかった。

続いて内部パートをすべてハッシュ化した。十八のパートハッシュは同一で、二つが異なっていた。

本文の段落がある `word/document.xml` では、整形済みの差分に変更された `w:t` テキストノードが 1 つだけ含まれていた。それが選択した段落である。そのパート内の他の整形済みノードは変わっていなかった。

生ハッシュの差分の 2 つ目は `[Content_Types].xml` だった。サイズは 2,125 バイトのままで、`Default` と `Override` のエントリも同じだった。出力では、既存の `/word/comments.xml` の override がリストの末尾から他の Word の override の並びへ移動している。コンテンツタイプの追加・削除・変更はなかった。この順序の違いは、比較がパート名やパース済みエントリの集合しか報告しない場合、見落としやすい。

これは「ファイルに 20 個のパートがあった」と言うより強い証拠である。パートは名前を保ったまま中身が変わることがある。目視の抜き取りチェックより強いとも言える。コメントのリレーションシップやコンテンツコントロールは、本文の普通のテキストのように見えなくてもファイル内に存在し得るからだ。

とはいえ、Word 上で個々のオブジェクトを実際に操作したことと同義ではない。件数が同じで XML 構造が一致していても、パッケージに何が残ったかが分かるだけだ。レビューアーが校閲ウィンドウでコメントをクリックした、古い挿入を承諾した、古い削除を拒否した、デスクトップ版 Word で REF フィールドを更新した、といったことまで示すものではない。

どちらのバージョンも二ページにレンダリングされた。画像比較では、2 ページ目だけが変更されたページと判定されている。

• 追跡された変更、コメントのアンカー、コンテンツコントロール、ブックマーク、REF フィールド、表を含む 1 ページ目は、見た目が変わらなかった。
• 2 ページ目は、選択した段落が現れる位置で変わっていた。
• 新しい文の長さによって、2 ページ目では通常の行の折り返しが起きた。
• レンダリングされた出力には、テキストの切れ、テキストの重なり、表の欠落、表のレイアウト崩れは見られなかった。

抽出テキストの差分も同じ境界に到達した。選択した段落が変わる一方、その後ろにある範囲指定のメモは元の位置に残っていた。

レンダリングが答える問いは、パッケージ監査とは別だ。パッケージ監査は構造を調べ、レンダリングは読者の目に触れるページを調べる。一方に通って他方に落ちるファイルもあるため、どちらかの結果でもう一方の代わりにすることはできない。

件数が変わらないという観測は、そのカウンターが喪失を検出できる場合にのみ意味を持つ。それを確かめるため、意図的に損傷させたコピーを二つ用意した。

一つ目のコピーではコメント構造を取り除いた。同じ監査処理は、コメント本文 0、範囲アンカー 0、コメント参照 0、コメントのリレーションシップ 0、コメントの content-type エントリ 0 を報告した。

二つ目のコピーでは追跡された変更を承諾した。監査処理は追跡された挿入 0、追跡された削除 0 を報告した。

これらのポジティブコントロールは、この監査経路が私たちの作った二つの喪失を捉えられることを示している。ただし、あらゆる DOCX の不具合に対してこの監査を保証するものではない。壊れた描画リレーションシップ、不正な数式、損傷したマクロについては、それぞれ専用のチェックと、既知の不良コントロールが必要になる。

使い捨てのコピーを使う。テストには、実際の文書で修復に手間がかかるオブジェクトを含めるべきだ。Word の構造が何もない一般的な段落では意味がない。

1. 依存しているオブジェクトごとに、識別しやすい例を 1 つ入れる。追跡された挿入、追跡された削除、コメント、文献管理ツールのコントロール、ブックマーク、相互参照、脚注、表、数式、キャプションなどが考えられる。
2. 各オブジェクトの脇に固有のアンカーを置く。例えば `CHECK-COMMENT-01` や、単位付きの数値だ。期待される件数を記録しておく。
3. それらのコントロールは通常の段落 1 つの外側に置く。書き換えのために選ぶのはその段落だけにし、実行前に最終的な範囲を確認する。
4. 手を付けていない入力を保存し、バイトサイズと SHA-256 を記録する。macOS なら `shasum -a 256 your-file.docx` という簡単なコマンドで足りる。
5. ダウンロード後、出力についても同じ値を記録する。DOCX のパート一覧を比較し、さらに該当する XML パートを解析してオブジェクト数を数える。圧縮された DOCX のバイト列を grep して、それを監査と呼んではいけない。
6. 両方のファイルを同じレンダラーで描画し、ページ数・テキスト・画像を比較する。自然な行の折り返しと、切れ・重なり・オブジェクトの欠落は別物だ。
7. 提出に使うデスクトップ版の Word で出力を開く。All Markup 表示とコメントウィンドウを確認し、コンテンツコントロールを 1 つ操作し、フィールドを 1 つ更新し、別名で保存し、閉じて、再度開く。
8. 意図的に損傷させたコピーを 1 つ作り、自分のチェックがその喪失を報告することを確認する。このコントロールがなければ、きれいなゼロは「そもそも計測がそのオブジェクトを見ていなかった」という意味かもしれない。

これらのチェックを 1 つのパーセンテージにまとめてはいけない。コメントが失われたのに他の九つの行が通っていても、コメントは満たされていない要件のままだ。合否の判断は、必要とする文書オブジェクトごとに下すものだ。

この実行は、普遍的な保持を主張する根拠にならない。テストしていないのは次の項目だ。

• 書き換えられるテキストの内側にあるコメントや追跡された変更
• Zotero、EndNote、Mendeley のライブラリを実際に接続した状態
• 脚注、数式、マクロ、埋め込みファイル、テキストボックス、浮動画像
• セクション固有のヘッダーとフッター
• HumanPen の他の戦略、文書全体の書き換え
• 他の Word バージョン、他の OS
• 書き換えられた段落の内容面の品質
• AI 検出器の判定結果

Microsoft Word での手動による再オープンは、依然として最大の未実施チェックである。OOXML とレンダリングの結果は証拠にはなるが、Word が修復警告なしにファイルを開いたとか、保持されたすべてのオブジェクトが操作可能なままだったと主張できるものではない。

正しい結論は、小さく、しかし実用的だ。この 1 回の指定コンテンツによる HumanPen 実行では、選択した段落は変わり、その外側に置いた計測対象オブジェクトは測定されたパッケージ構造を保ち、レンダリングされた文書も無傷のままであった。とはいえ、自分の DOCX には自分の検収テストが必要だ。

HumanPen は Track Changes を保持するか。 この 1 回の実行では、既存の追跡された挿入 1 件と追跡された削除 1 件が、返ってきた DOCX パッケージに残っていた。Microsoft Word で手動で承諾・拒否はしていないため、デスクトップ版 Word での挙動は未確認のままである。

HumanPen は Word のコメントを保持するか。 このファイルでは、コメント本文、開始と終了のアンカー、文書内の参照、パッケージのリレーションシップ、content-type エントリがいずれも残っていた。ダウンロード後に Word のコメントウィンドウで手動で開くことはしていない。

パート数が一致していれば、その DOCX は安全だと証明できるか。 否。パートは名前が同じままで中身が変わることがある。パートのハッシュを比較し、変更された XML を調べ、オブジェクト単位の件数を確認し、ページをレンダリングし、Word でオブジェクトを実際に操作する必要がある。

自分の学位論文やレポートでも同じ結果を期待してよいか。 単一のテスト用ファイルであらゆる Word オブジェクトを網羅することはできない。実際の文書が使っている構造を反映した小さなテストファイルを作り、使う予定の同じ範囲と設定で実行し、手を付けていない原本を保管しておくこと。