git で Excel が壊れる原因と完全対策【差分・バイナリ管理・2026年版】

「git pull したら Excel ファイルが開けなくなった」「チームメンバーとマージしたら xlsx が壊れた」——そんな経験はないだろうか。

Excelファイルをgitで管理するのは一見シンプルに思えるが、バイナリ形式の特性上、テキストファイルとは根本的に異なる扱いが必要だ。実際にこの問題に直面したとき、ネット上の情報は断片的で「.gitattributes を設定すればいい」「lockファイルを使え」といった表面的な回答しか見つからないことが多い。

この記事では、gitでExcelが壊れる具体的なメカニズムから、現場で実際に機能する5つの対処法まで、コマンド例を交えて体系的に解説する。筆者自身も複数のプロジェクトでこの問題に遭遇し、壊れたxlsxを修復した経験をもとにまとめた。

gitでExcelファイルが壊れた状態と正常な状態の比較

この記事で解決できること

  • ✅ gitでExcelファイルが壊れる根本原因（バイナリ競合のメカニズム）を理解できる
  • ✅ .gitattributes を使ってマージ競合によるファイル破損を防止できる
  • ✅ チームで安全にExcelを共有・バージョン管理する運用設計ができる

動作確認環境: Windows 11 / macOS Sequoia 15 / Git 2.47.x / Microsoft Excel 2021・Microsoft 365

問題の再現と確認

まず、実際にどのような状況でExcelが壊れるかを確認しておく。

典型的な壊れ方パターン

パターン1: git merge/pull後にExcelが開けなくなる

# feature ブランチで Excel を編集してコミット
git checkout -b feature/update-budget
# → Excel を編集して保存
git add budget_2026.xlsx
git commit -m "2026年度予算を更新"

# main ブランチでも同じファイルを編集してコミット済み
git checkout main
git merge feature/update-budget

# コンフリクト発生
Auto-merging budget_2026.xlsx
CONFLICT (content): Merge conflict in budget_2026.xlsx
Automatic merge failed; fix conflicts and then commit the result.

この状態で budget_2026.xlsx を開こうとすると：

"budget_2026.xlsx"は正しい形式ではないか、または壊れています。
回復機能を使用してできるだけ多くのコンテンツを取得しますか？

というダイアログが表示され、データが失われることがある。

パターン2: git checkoutでファイルが壊れる

# 古いコミットのExcelを確認しようとした際
git checkout abc1234 -- report.xlsx

# ファイルは存在するが開けない
# Excelが「ファイルが壊れています」と報告

パターン3: git stashから復元した際に壊れる

git stash
# ... 別の作業 ...
git stash pop
# Excel ファイルが正常に復元されているが、内部構造が壊れている

Excelの「ファイルが壊れています」エラーダイアログ

原因

なぜExcelファイルがgitで壊れるのか

Excel (.xlsx, .xlsm, .xlsb) ファイルの正体はZIPアーカイブだ。拡張子を .zip に変えれば展開でき、内部はXMLファイルの集合体になっている。

budget_2026.xlsx（実体はZIPアーカイブ）
├── [Content_Types].xml
├── _rels/
│   └── .rels
├── xl/
│   ├── workbook.xml
│   ├── worksheets/
│   │   ├── sheet1.xml
│   │   └── sheet2.xml
│   ├── sharedStrings.xml
│   └── styles.xml
└── docProps/
    ├── app.xml
    └── core.xml

gitはデフォルトではすべてのファイルをテキストとして扱おうとする。バイナリファイルに対してテキストマージを試みると、ZIPアーカイブのバイナリ構造が破壊される。

原因の種類

原因 発生条件 頻度
バイナリ競合マージ 複数人が同じxlsxを編集してマージ 高
改行コード変換（CRLF/LF変換） core.autocrlf=true でチェックアウト 高
デルタ圧縮の破損 git pack-objects でバイナリを誤圧縮 中
BOMの混入・文字コード誤変換 gitのテキスト判定誤り 低

改行コード変換が特に危険な理由

git config core.autocrlf true（Windowsのデフォルト設定）が有効な場合、gitはテキストとみなしたファイルの改行コードを変換する。しかしxlsxはバイナリなので、この変換によってZIPアーカイブのバイト列が崩れる。

# 危険な設定（Windowsのデフォルト）
git config --global core.autocrlf true

# この設定でxlsxをチェックアウトすると内部バイナリが変換される

解決策

解決策1: .gitattributes でExcelをバイナリとしてマーク（必須・最重要）

これが最も確実な予防策だ。.gitattributes ファイルをリポジトリルートに置き、Excelファイルをバイナリとして明示することで、gitはいっさいのテキスト処理を行わない。

# リポジトリルートに .gitattributes を作成
touch .gitattributes

.gitattributes の内容：

# Excel ファイルをバイナリとして扱う（改行変換・マージ無効化）
*.xlsx binary
*.xlsm binary
*.xlsb binary
*.xls  binary

# Word・PowerPoint も同様に
*.docx binary
*.docm binary
*.pptx binary
*.pptm binary

# OpenDocument 形式も
*.ods  binary
*.odt  binary

# コミットして全員に配布
git add .gitattributes
git commit -m "chore: Officeファイルをバイナリとしてマーク"
git push origin main

既存のキャッシュをリセットする（重要）:

.gitattributes を追加しただけでは既存のgitキャッシュが残るため、すべてのチームメンバーが以下を実行する必要がある。

# インデックスをリセット（作業ツリーは変更されない）
git rm -r --cached .
git add .
git commit -m "chore: gitattributesの変更を全ファイルに適用"

# 確認コマンド：xlsxがバイナリとして認識されているか確認
git check-attr -a path/to/your/file.xlsx
# 期待する出力:
# path/to/your/file.xlsx: diff: binary
# path/to/your/file.xlsx: merge: binary
# path/to/your/file.xlsx: text: unset
# path/to/your/file.xlsx: binary: set

注意: git rm -r --cached . はインデックス（ステージング）のみをクリアし、作業ディレクトリのファイルは削除しない。ただし実行前に git status が clean であることを確認すること。

.gitattributes設定前後でのgitマージ動作の違い

解決策2: merge=ours でExcelの自動マージを完全に無効化

.gitattributes で binary を指定すると、コンフリクト時はどちらか一方のバージョンのみが選択される。どちらを優先するかを明示したい場合は以下の設定が有効だ。

# コンフリクト時は常に自分のバージョン（HEAD）を使用
*.xlsx merge=ours

# または相手のバージョンを使用
*.xlsx merge=theirs

注意: merge=theirs はgit組み込みではないため、カスタムマージドライバーを定義する必要がある。実用上は binary 指定で十分なケースがほとんどだ。

解決策3: git-lfs（Large File Storage）でバイナリを分離管理

Excelファイルが大きく（数MB以上）、かつ更新頻度が高い場合は git-lfs を使うことで、gitリポジトリの肥大化とバイナリ破損の両方を解決できる。

# git-lfs のインストール
# macOS
brew install git-lfs

# Windows（Chocolatey）
choco install git-lfs

# Ubuntu/Debian
sudo apt-get install git-lfs

# lfs の初期化
git lfs install

# 追跡するファイルパターンを登録
git lfs track "*.xlsx"
git lfs track "*.xlsm"

# .gitattributes が自動更新される（内容を確認）
cat .gitattributes
# 出力例:
# *.xlsx filter=lfs diff=lfs merge=lfs -text
# *.xlsm filter=lfs diff=lfs merge=lfs -text

# コミット
git add .gitattributes
git commit -m "chore: Excel ファイルを git-lfs で管理"
git push origin main

LFS を使うメリット:

  • リポジトリのcloneが高速になる（バイナリは別途ダウンロード）
  • GitHubのFile History画面でバイナリ変更履歴が閲覧できる
  • ファイルサイズ制限を超えた大きなxlsxも管理できる

LFS を使う際の注意:

  • GitHub Free では LFS ストレージが1GBまで（超過は有料）
  • git lfs pull を忘れると「LFSポインタ」ファイルとしてExcelが保存される
# LFS ファイルが正しく取得されているか確認
git lfs status
# Expected output:
# On branch main
# Objects to be committed:
#         (nothing)

解決策4: ロックファイル戦略でExcelの同時編集を防止

技術的な解決策だけでなく、運用ルールでExcelの競合を根本から防ぐ方法も重要だ。

方法1: git-lfs のロック機能を使う（推奨）

# lfs ロック機能を有効化
git lfs track "*.xlsx" --lockable
# または .gitattributes に直接記述
# *.xlsx filter=lfs diff=lfs merge=lfs -text lockable

# ファイルをロック（他者の編集をブロック）
git lfs lock path/to/budget_2026.xlsx
# 出力: Locked path/to/budget_2026.xlsx

# ロック一覧確認
git lfs locks
# 出力:
# path/to/budget_2026.xlsx  username  ID:1

# 編集完了後にロック解除
git lfs unlock path/to/budget_2026.xlsx

lockable を指定するとロックしていない場合はファイルが読み取り専用になり、誤って編集してしまうことを防げる。

方法2: ブランチ運用で同時編集を防ぐ

main ブランチ（常に安全なExcel）
├── feature/excel-q1-budget（担当者Aが編集）
└── feature/excel-q2-forecast（担当者Bが別ファイルを編集）

ルール：
– Excelファイルは一人ずつブランチを切って編集する
– マージは必ず編集担当者がレビューの上で行う
– 同じxlsxを同時に複数人が編集することを禁止する

解決策5: 壊れたExcelファイルの修復方法

すでに壊れてしまったxlsxを修復する手順を説明する。

方法1: git で健全なバージョンに戻す

# コミット履歴を確認して壊れる前のコミットを特定
git log --oneline -- path/to/budget_2026.xlsx
# 出力例:
# a3f9d12 2026年度予算を更新
# 8c2e071 Q4実績を追加         ← ここが最後の正常バージョン
# 4b1a293 初回コミット

# 壊れる前のバージョンを取り出す
git checkout 8c2e071 -- path/to/budget_2026.xlsx

# ファイルが正常に開けるか確認後、コミット
git add path/to/budget_2026.xlsx
git commit -m "fix: 壊れたExcelを正常バージョンに戻した"

方法2: ZIPとして展開して修復する

xlsx はZIPアーカイブなので、ZIPとして操作して修復できる場合がある。

# xlsx をZIPとしてコピー
cp budget_2026.xlsx budget_2026_backup.zip

# 展開（Linux/macOS）
mkdir xlsx_contents
cd xlsx_contents
unzip ../budget_2026_backup.zip

# 内部のXMLを確認（コンフリクトマーカーが混入していないか）
# "<<<<<<" のようなマーカー文字列を検索する
grep -r "<<<" .
# コンフリクトマーカーが見つかった場合は該当XMLを手動で修正

# 再パック（zipコマンドで）
cd ..
zip -r budget_2026_fixed.xlsx xlsx_contents/
mv budget_2026_fixed.xlsx budget_2026.xlsx

注意: ZIPの再パック時はファイル順序と圧縮形式に注意が必要だ。特に [Content_Types].xml は必ずアーカイブの先頭に配置する必要がある。正確な方法は以下のコマンドを使う。

# 正しい順序でZIPを再構築
cd xlsx_contents
zip -0 -X ../budget_fixed.xlsx "[Content_Types].xml"
zip -r ../budget_fixed.xlsx . --exclude "[Content_Types].xml"

方法3: Excelの「ファイルの修復」機能を使う

  1. Excel を開き、「ファイル」→「開く」→「参照」を選択
  2. 壊れたxlsxを選択し、「開く」ボタンの横の▼をクリック
  3. 「開いて修復する」を選択
  4. 「修復」を選ぶ（データが少し失われても良い場合は「データの抽出」）

よくある関連エラーと対処法

エラー1: .gitattributes 設定後もxlsxがテキストとして扱われる

# 症状：git diff でxlsxのバイナリが表示される
git diff HEAD~1 -- budget.xlsx
# Binary files a/budget.xlsx and b/budget.xlsx differ
# ↑ ではなく以下のようなゴミが表示される場合
# -PK<03><04><14><00><06><00>...

対処法: gitキャッシュのリセットが必要。

git rm --cached budget.xlsx
git add budget.xlsx
git commit -m "fix: xlsxのgitattributes適用"

エラー2: git-lfs で「Smudge error」が発生する

# エラー例
error: external filter 'git-lfs smudge -- %f' failed

対処法: LFSストレージへの認証が切れているか、LFSオブジェクトが存在しない。

# LFS の状態確認
git lfs status

# LFS オブジェクトを再取得
git lfs pull

# それでも失敗する場合は .git/lfs/ ディレクトリを削除してから
rm -rf .git/lfs/
git lfs pull

エラー3: Windows で core.autocrlf=true が残っている

# 現在の設定確認
git config --global core.autocrlf
# true が返る場合は危険

# グローバル設定を修正（Officeファイルがあるリポジトリ向け）
git config --global core.autocrlf false
# または input に変更（Unix系改行をそのまま保存）
git config --global core.autocrlf input

エラー4: merge=ours 設定が効かない

# .gitattributes に merge=ours を設定しているのに
# コンフリクトが発生する場合
git config --list | grep merge
# merge.ours.driver= が設定されていない場合

対処法: binary 属性を使う方が確実だ。binary は diff=binary merge=binary -text の組み合わせ設定と等価で、改行変換・テキストマージ・diff処理をすべて無効化する。

まとめ

git excel 壊れる問題について解説した。

  • 主な原因: gitがxlsxをバイナリとして認識せず、テキストマージや改行変換を行うことでZIPアーカイブの内部構造が破壊される
  • 最短の解決策: .gitattributes に *.xlsx binary の1行を追加し、git rm -r --cached . でキャッシュをリセットする
  • 再発防止策: チーム全員が .gitattributes をpullすること、大容量・頻繁更新のxlsxには git-lfs + ロック機能を活用すること

Excelファイルの管理は「gitの使い方」と「Officeファイルの特性」の両方を理解していないと落とし穴にはまりやすい。この記事の設定を一度しっかり入れておけば、チーム全員が安心してExcelをgit管理できるようになる。まず .gitattributes の設定から始めてみよう。

関連記事

未分類

Posted by GENDOSU