「同じ .docx をもう一回アップしただけなのに、SharePoint 側でメタデータやファイルサイズが変わってしまう……」という相談は、現場で非常によくあります。本記事では、この現象の仕組みを技術的に整理しつつ、実務でとれる現実的な回避策・運用方法までをまとめて解説します。
SharePoint に同一の .docx を再アップロードすると何が起こるか
まずは、よくある「現象」を整理します。
- まったく編集していない 同一の .docx ファイル を再度 SharePoint ドキュメント ライブラリにアップロードする。
- ところが、SharePoint 上の メタデータ（Title、Author、Last Modified By、Modified など）が変化する。
- さらに、ダウンロードして確認すると ファイルサイズが数 KB 増えている。
- その結果、ハッシュ値（SHA-256 など）も変わるため、「同じファイルかどうか」をバイナリ比較で判定しにくくなる。
現象を表にすると、次のようなイメージです。
| 項目 | 初回アップロード | 再アップロード（同一 .docx） |
|---|---|---|
| ファイル名 | sample.docx | sample.docx（同じ） |
| Title 列 | 空、または Word 側のタイトル | ライブラリ列の値で上書きされる（または Word 側から反映） |
| Author / 作成者 | Word の作成者、またはアップロードしたユーザー | SharePoint のユーザー情報に合わせて更新されることがある |
| Last Modified By / 編集者 | 初回アップロードしたユーザー | 再アップロードしたユーザーに変化 |
| Modified / 変更日時 | 初回アップロード日時 | 再アップロード日時に更新 |
| ファイルサイズ | 100 KB | 103 KB（数 KB 増加） |
| ハッシュ値（SHA-256） | abc123… | def456…（別物として認識される） |
ユーザーから見ると、「ファイル自体は一切触っていないのに、SharePoint に置いた途端に別物になってしまう」ように感じられます。この違和感の正体が、後述する「プロパティの昇格 (promotion)／降格 (demotion)」です。
メタデータが変わる技術的な理由：Property Promotion / Demotion とは
SharePoint ライブラリ列と Office ファイル内部プロパティの関係
SharePoint は、Office ファイル（.docx、.xlsx など）とドキュメント ライブラリの列情報を連携させるため、プロパティの昇格 (promotion) / 降格 (demotion) という仕組みを持っています。
- 昇格 (promotion)：
Office ファイル内部のプロパティ（タイトル、作成者など）を読み取り、SharePoint のライブラリ列に反映する動き。 - 降格 (demotion)：
SharePoint のライブラリ列の値を、逆にファイル内部のカスタムプロパティ（docx 内の XML）に書き戻す動き。
この「双方向同期」により、ライブラリの列とファイル内部プロパティの整合性を自動で保つのが SharePoint の基本設計です。
代表的な対応関係は次の通りです（環境・バージョンにより差異あり）。
| SharePoint 側の列 | Office ファイル側のプロパティ | 代表的な動き |
|---|---|---|
| Title | ドキュメントのタイトル（core properties） | アップロード時に、どちらか一方の値が他方にコピーされる |
| Author / 作成者 | author プロパティ | Word 側の作成者が SharePoint に反映されたり、逆に SharePoint のユーザー名で書き換えられたりする |
| Content Type | コンテンツ タイプ情報を示すカスタム XML | ライブラリで設定したコンテンツ タイプの情報が docx 内に書き込まれる |
| カスタム列（カテゴリなど） | カスタム プロパティ（docProps/custom.xml） | 列の値がファイル内部のカスタムプロパティとして追加される |
なぜファイルサイズが数 KB 増えるのか
.docx ファイルは、実体としては ZIP 形式のアーカイブです。中身を解凍すると、次のようなフォルダ／ファイル構成になっています。
[Content_Types].xmldocProps/core.xml（タイトル、作成者などの基本プロパティ）docProps/custom.xml（カスタムプロパティ）word/document.xml（本文）- その他、レイアウトやスタイル情報など多数
SharePoint が降格 (demotion) 処理を行うと、主に docProps/core.xml や docProps/custom.xml といったファイルに対して、ライブラリ列の値を書き込む／更新することになります。
- 新しいカスタムプロパティが追加される。
- 既存プロパティの値が更新される。
- XML 内のノード順序や空白が変わることでサイズが微妙に変動する。
こうした変更によって、ファイルのバイナリが少しだけ書き換えられ、結果として数 KB 程度のサイズ増加やハッシュ値の変化が起きる、というわけです。
「同じファイルなのにハッシュ値が違う」問題の整理
厳密に言えば、SharePoint に再アップロードした時点で、その .docx は「別バイナリのファイル」になっています。内容（本文）や見た目がまったく同じでも、内部の XML やプロパティ部分が変わっているためです。
そのため、例えば次のような運用をしていると問題が表面化します。
- 社内ツールで「SHA-256 が同じファイルは重複」と判定して、不要ファイルを削除する。
- コンプライアンスの都合で「原本ファイル」のハッシュ値を保管し、後から「改ざんされていないか」をチェックする。
- バックアップ／アーカイブシステムで、「ファイル内容が変わった時だけ差分保存」する仕組みを作っている。
どれもやりたいことは正しいのですが、SharePoint の Property Promotion/Demotion による「見えない変更」も差分として検出されてしまうため、現場で混乱が起こりがちです。
同じファイルをアップロードしてもメタデータを変えずに維持できるのか
ここが多くの方が知りたいポイントだと思います。結論から言うと、次のように整理できます。
- 完全に一切メタデータを変えない（バイナリも 1 ビットも変わらない）まま SharePoint に保存することは、基本的に期待しない方がよい。
- ただし、同じライブラリ・同じフォルダー（同一 URL）にアップロードし、ライブラリ列の値も同一であれば、最終的にはほぼ同じメタデータに揃うケースが多い。
- それでも 「Modified」「Last Modified By」など、一部の列はアップロード操作そのものを反映するため変わる。
つまり、
「実務上、同等とみなせるレベルでメタデータを維持する」ことはできるが、「完全にビット単位で同一のファイル」として維持するのは難しい、と考えるのが現実的です。
同一ライブラリ・同一フォルダーにアップロードした場合のイメージ
同じ URL（同じライブラリ・同じフォルダー）に同名ファイルをアップロードし直した場合、概ね次のような状態に収束します。
| 列 | 状態 | コメント |
|---|---|---|
| Title | 同じ値に揃うことが多い | ライブラリ列とファイル内部プロパティが同期するため |
| カスタム列 | 元ファイルと同じ値に設定すれば、内部プロパティも揃う | ただし設定漏れやバリデーションに注意 |
| Author | 環境によっては同じ・異なる場合がある | Word 側の作成者と SharePoint 側のユーザー情報のどちらが優先されるかによる |
| Last Modified By | 再アップロードしたユーザーに更新される | 操作履歴として重要な列のため、基本的に変化する |
| Modified | 再アップロードの日時になる | これも変更操作を示すため、変化は避けられない |
| ファイル内部のプロパティ | ライブラリ列と整合性が取れるように更新 | この結果としてバイナリ差分が発生する |
「まったく同じファイルとして扱いたい」という要件がある場合、SharePoint にアップロードした瞬間に「SharePoint 版のファイル」に変換される、と割り切って設計する必要があります。
実務で使える回避策・対処策
ここからは、現場で採用しやすい対処方法を具体的に紹介します。
バージョン管理を活用して「再アップロード」をやめる
最もおすすめなのは、「再アップロード」という発想をやめて、バージョン管理を前提とした運用に切り替えることです。
- 同じライブラリ・同じ URL のファイルに対して、「新しいバージョンとして上書き」する。
- SharePoint のバージョン履歴機能を有効化し、過去バージョンは履歴として管理する。
- ユーザーには「新規アップロード」ではなく「既存ファイルを置き換える」動作を教育する。
なぜこれが有効かというと、
- メタデータは 同じアイテム の中で更新されるため、「別ファイル」として扱われにくい。
- 差分検出や監査ログの観点からも、履歴の流れが明確になる。
SharePoint Online では、ドキュメント ライブラリの設定から 「バージョン管理設定」を確認し、少なくともメジャーバージョンの保存を有効にしておくとよいでしょう。
カスタム列・不要な既定列を見直し、プロパティ昇格の対象を減らす
昇格／降格が行われる対象が多いほど、ファイル内部に書き戻される情報が増え、差分も増えます。そこで、次のような観点で列を整理するのも有効です。
- 本当に必要な列だけを残し、使っていないカスタム列を削除する。
- 「とりあえず作ったが使われていない」列を洗い出し、非表示あるいは削除を検討する。
- コンテンツ タイプを整理し、重複しているフィールドを統合する。
イメージとしては、
| 列の種類 | プロパティ昇格への影響 | 見直しのポイント |
|---|---|---|
| Title / タイトル | 代表的な昇格対象 | 本当に必要な列か、名前や補足説明をわかりやすくする |
| カテゴリ、プロジェクト名など | カスタムプロパティとして docx に書き込まれる | SharePoint 側だけで管理してよいものかを検討 |
| デバッグ・検証用の列 | 不要なプロパティ増加の原因 | 運用定着後は削除または非表示にする |
列が減れば、書き戻されるプロパティも減り、その分だけバイナリ差分も抑えられる、というイメージです。
Property Promotion / Demotion を抑制するアプローチ
環境により事情は異なりますが、概念的には次のようなアプローチがあります。
- オンプレミスの SharePoint Server：
ファーム レベルまたはライブラリ レベルで、特定のファイル形式に対するプロパティ昇格／降格を抑制する設定が用意されている／可能なケースがあります。 - SharePoint Online / Microsoft 365：
基本的にはユーザー側で昇格／降格を完全に無効化する公式な設定はなく、ライブラリ設計や列の整理によって影響を間接的に減らす、というスタンスになります。
特に SharePoint Online では、サービス側の改善により、昔に比べると無駄な差分が出にくくなっているものの、ゼロにはならない、というのが実態です。「完全に同一バイナリを保つ」というより、どこまでを許容範囲とするかを要件として決めることが重要です。
差分検出の目的なら「ハッシュ値の取り方」を工夫する
もし「再アップロードしても同じファイルかどうかを判定したい」というのが主目的であれば、SharePoint が書き換えるメタデータ部分を無視するという発想も大切です。
代表的なパターンは次の通りです。
| 方法 | 概要 | メリット | デメリット |
|---|---|---|---|
| 通常の SHA-256 | .docx ファイル全体に対してハッシュを計算 | 実装が簡単で高速 | プロパティの差分もすべて別ファイルとして扱われる |
| 本文部分だけをハッシュ | .docx を解凍し、word/document.xml など本文に関わる一部ファイルだけを対象にハッシュ | 見た目や本文が同じなら「同一」と判断しやすい | 実装がやや複雑、ファイル形式仕様の理解が必要 |
| メタデータ削除後にハッシュ | docx を解凍し、docProps 以下のファイルを削ったうえで再 ZIP してハッシュ | SharePoint によるプロパティ書き換えの影響をほぼ排除できる | ツールやスクリプト側に手間がかかる |
運用要件（本当に守りたいのは「本文が同じこと」なのか、「ファイル全体が同じこと」なのか）を明確にしたうえで、どのレイヤーでの「同一性」を見るかを設計するのがポイントです。
スクリプトや自作ツール側での具体的な工夫例
たとえば PowerShell や C# などで独自の差分検出ツールを作る場合、次のようなステップで「メタデータを無視したハッシュ値」を計算することができます。
- .docx ファイルを一時フォルダーに解凍する。
docPropsフォルダーを削除する、あるいはcore.xml/custom.xmlを除外する。- 残りのファイルだけを ZIP に再圧縮する。
- 再圧縮した ZIP に対して SHA-256 などを計算し、それを「本文ベースのハッシュ」として扱う。
このようにして得たハッシュ値であれば、SharePoint によるプロパティ書き換えの影響を大幅に減らすことができるため、「人間が見て同じ文書なら同じと判定する」ための実用的な指標になります。
SharePoint Online とオンプレミスでの違い（ざっくり整理）
運用設計の際に意識しておきたい違いを、ざっくりと比較しておきます。
| 項目 | SharePoint Online（Microsoft 365） | SharePoint Server（オンプレミス） |
|---|---|---|
| Property Promotion/Demotion の制御 | ユーザー設定で完全無効化は基本不可。列設計などで影響を減らすアプローチが中心。 | 環境によってはファームやライブラリ単位の制御が可能なケースもある。 |
| サービス側の仕様変更 | Microsoft 側で随時改善あり。過去に比べると差分発生は減る傾向。 | バージョンごとに仕様が固定されがち。アップグレード時にのみ挙動が変わる。 |
| 運用の自由度 | テナント全体への影響を考慮する必要が大きい。 | 社内ルールの範囲で比較的自由にカスタマイズしやすい。 |
特に Microsoft 365 環境では、「SharePoint の仕様そのものを変える」のではなく、「仕様を前提に運用を設計し直す」という考え方が現実的です。
よくある疑問と注意点
Q. 「Last Modified By」や「Modified」が変わるのはバグ？
A. いいえ、これは 正常な挙動 です。再アップロードや上書き保存は「その時点での変更操作」とみなされるため、「誰がいつ操作したか」を示すために更新されます。監査ログや履歴管理の観点からも、ここを無理に固定しようとするのはおすすめできません。
Q. Title や Author などのメタデータを絶対に書き換えたくない
A. SharePoint に保存した時点で、ライブラリ列とファイル内部プロパティの同期処理が走る設計のため、「一切書き換えない」ことを保証することは難しいです。どうしても原本のプロパティを守りたい場合は、
- 原本ファイルは別のストレージ（書き込み禁止領域など）に保管し、
- SharePoint には「業務用コピー」として保存する、
といったアプローチで、「原本」と「業務利用ファイル」を分けて管理する設計が現実的です。
Q. SharePoint Online なら、今はもう差分が出ない？
A. 昔に比べて差分が出にくくなっているのは事実ですが、完全にゼロにはなりません。新しい列を追加したり、コンテンツ タイプの設定を変えたりすれば、そのタイミングで再びプロパティの書き換えが行われるため、バイナリ差分が発生し得ます。
Q. OneDrive for Business や Teams にアップロードした場合も同じ？
A. 基本的には 同じ SharePoint プラットフォーム上の仕組みを使っているため、似たような挙動になります。OneDrive や Teams 経由で保存した場合も、「SharePoint が裏で動いている」と理解しておくと、現象を説明しやすくなります。
運用設計の現実的なゴールを決める
ここまで見てきたように、SharePoint は「ファイルとメタデータの整合性を保つ」ために、どうしても ファイル内部を書き換える仕様になっています。
そのため、運用設計では次のような問いからスタートすると整理しやすくなります。
- 本当に守りたいのは何か？
本文内容なのか、見た目（レイアウト）なのか、バイナリそのものなのか。 - どのレイヤーで「同じファイル」とみなしたいか？
人が見て同じであればよいのか、ツールがハッシュ値で完全一致を確認したいのか。 - 原本と業務利用ファイルを分けるべきか？
法的・監査上の要件がある場合は、原本を別ストレージで保管するほうが安心なケースも多い。
これらを整理したうえで、
- SharePoint の仕様を前提に、バージョン管理・列設計・ハッシュ計算ロジックを組み立てる。
- ユーザーには「再アップロードではなく上書き」「不要な列は作らない」といったルールを周知する。
といった形で、システムと運用ルールの両面から対策していくのが、現場でトラブルを減らす一番の近道です。
まとめ
- SharePoint に .docx をアップロードすると、プロパティの昇格／降格（Property Promotion/Demotion）が行われ、ライブラリ列とファイル内部プロパティの整合性が自動的に取られる。
- その結果、ファイル内部の XML が書き換えられ、サイズが数 KB 増えたり、ハッシュ値が変わったりするのは仕様上の期待動作である。
- 同じライブラリ・同じフォルダーに再アップロードすれば、多くの場合メタデータは最終的に揃うが、「Modified」「Last Modified By」などの履歴系の列は変化する。
- 完全にバイナリを変えずに保存することは難しいため、バージョン管理の活用、列の整理、原本と業務利用ファイルの分離など、運用設計でカバーするのが現実的。
- 差分検出や重複判定が目的であれば、本文部分だけを対象としたハッシュ計算や、メタデータを除外したハッシュ計算を採用し、「何をもって同じとみなすか」を明確にすることが重要。
SharePoint の「ちょっとした親切機能」であるプロパティ昇格／降格が、運用によっては思わぬトラブルの原因になります。ファイルのライフサイクルとメタデータの役割を整理し、自社の要件に合ったルールとツールを組み合わせることで、「なぜかファイルが勝手に変わる」というモヤモヤを解消し、安心して SharePoint を使える環境を整えていきましょう。
コメント