ファイル共有のバージョン管理:上書き混乱を防ぐ方法

上書き混乱を排除するには三つのツールを組み合わせる。同期プラットフォームのネイティブバージョン履歴（Google Driveは100バージョンまたは30日、Dropbox Businessは180日、OneDriveは500バージョン）、一度に一人だけが編集すべきファイルのチェックイン/チェックアウトロック（SharePoint、Box、BynderなどのDAM）、そしてテキストベースのコンテンツまたは明示的な分岐が必要な場合のGitまたはGit-LFS。これらの上にファイル名へのvNNサフィックス命名規則を重ねれば、自動的なリカバリー（同期ツール）と意図的なスナップショット（Git形式の分岐）の両方が手に入る。個人情報保護委員会（PPC）のガイドラインでも、個人情報を含むドキュメントの変更管理と監査可能性を確保することが求められている。

共有ファイルの三つの失敗パターン

全ての上書き災害は三つのパターンのどれかだ。これを認識すれば修正策が明確になる。

同時保存の衝突: 二人が同じファイルを同時に編集し、最後に保存した人が勝ち、最初の保存内容が消える。修正：リアルタイム共同編集（Google Docs、Office Online）または明示的なロック（SharePointのチェックアウト）
誤った上書き: 誰かが「そのファイル」を開き、作業コピーとして保存するつもりが正規コピーを上書きする。修正：読み取り専用の正規コピーによる明確な真実の源泉の分離
履歴の喪失: ファイルは3バージョン前が正しかったが、現在の状態が壊れていて中間ステップを再構築できない。修正：プラットフォームでのバージョン履歴の保持と規律あるスナップショット作成

ほとんどのチームは三つ全てを経験する。複合解決策は異なる失敗パターンに異なるツールを使う。

生きているドキュメントのリアルタイム共同編集

多くの人が編集する文章やスプレッドシートには、リアルタイム共同編集が上書き衝突を完全に排除する。Google Docs、Sheets、Slidesは100人以上の同時編集者をドラマなしで処理する。Microsoft 365のWord OnlineとExcel Onlineは古い.docxの忠実度でわずかに遅れるが接近している。

Notion、Coda、Airtableは構造化ドキュメントとデータベースにこれを拡張する。Figmaはカスタムマルチプレイヤーエンジンでデザインファイルに対して同じことをする。

ツールを選ぶとき、実際のファイルサイズでリアルタイム共同編集が機能するか確認する。一部のツールは1,000行または50ページを超えると劣化する。

バイナリファイルのチェックイン/チェックアウトロック

バイナリファイル——PSD、Illustratorの.ai、InDesignの.indd、Revitの.rvt、Premiereの.prproj、AutoCADの.dwg——は競合を綺麗にマージできない。二人が編集すれば一人の変更が消える。明示的なロックが解答だ。

成熟したチェックイン/チェックアウト機能を持つツール：

SharePoint: あらゆるライブラリでのネイティブチェックイン/チェックアウト。使われていないが堅固
Box: 「誰が持ち出しているか」インジケーター付きのファイルロック
Bynder、Frontify、Brandfolder: クリエイティブアセット用の組み込みロックを持つDAM
Perforce Helix Core: ゲームスタジオとVFXハウスの金の標準——数百GBのバイナリアセットをまたぐアトミックコミット

ネイティブロックなしのDropboxやDriveを使うチームには規律ベースのロックが機能する：フォルダ内のLOCKED-owner.txtファイル、またはプロジェクトチャンネルのピン留めSlackメッセージ。小規模チームには使えるが脆い。

テキストベースの全コンテンツにGitとGit-LFS

Gitはバージョン管理の金の標準だ。以下に使う：

ソースコード（明らか）
Markdownベースのドキュメント、wiki、社内ナレッジベース
設定ファイル（Kubernetes YAML、Terraform、Ansible）
データスキーマ（Prisma、dbtモデル、SQLマイグレーション）
明示的な分岐、差分、コードレビューが必要なもの全て

Git-LFSはGitを大きなバイナリアセットに拡張する。バイナリブロブを別サーバーに保存し、Gitはポインターを追跡する。GitHubのGit-LFSは月1GBストレージと1GB帯域まで無料、月750円のデータパックで50GB追加できる。

ネイティブバージョン履歴：セーフティネット

全ての主要な同期ツールはバージョン履歴を自動的に保持する。デフォルトを把握しておく：

Google Drive: 100バージョンまたは30日（遅い方）。Workspaceプランではタイム制限なしで100バージョンまで延長
OneDriveとSharePoint: デフォルト500バージョン、ライブラリごとに設定変更可能
Dropbox: Basicは30日、Businessは180日、Advancedは365日、Enterpriseは無制限
Box: Businessは100バージョン、Enterpriseは無制限
Apple iCloud Drive: 30日のみ——主要サービス中最弱

プランが実際に思っている通りの機能を提供しているか確認する。ストレージ節約のために管理者が2年前に保存期間を短縮したことを、危機の最中に発見する組織がある。

明示的なスナップショットとしての命名規則

自動バージョン履歴は小さなリカバリーに優れている。プロジェクトのマイルストーンには、人間がナビゲートできる明示的な名前付きスナップショットの方が明確だ。ファイル名のvNN規則がポイントインタイムのスナップショットを提供する：

2026-06-12_TANAKA-RB_spec_v01.pdf
2026-06-15_TANAKA-RB_spec_v02.pdf
2026-06-19_TANAKA-RB_spec_v03.pdf

「6月15日にクライアントに何を送ったか」と聞かれたとき、バージョン履歴のメタデータを掘り返さずに答えられる。メジャーバージョンに名前を付けて、自動履歴に中間的なものを任せる。

ロールバック訓練でシステムが機能することを証明する

テストされたことのないバックアップはバックアップではない。バージョン履歴も同じだ。四半期に一度、ランダムなファイルを選び、昨日壊れたと仮定して、以前のバージョンを復元するのに何分かかるかを計測する。10分以上かかれば何かが壊れている——同期ツールの保存期間が思ったより短いか、バージョン履歴UIがどこにあるか誰も知らないか、休暇中の特定の人に依存しているか。

各ツールのロールバック手順を文書化する。スクリーンショットが助けになる。共有ドライブのルートにピン留めする。

実験的な作業への分岐

「こうしたらどうなるか」というスパイクは正規ファイルに触れるべきでないことがある。ソースコードではGitで分岐する（git checkout -b experiment/new-hero）。クリエイティブファイルの同等は並行フォルダだ：

/Projects/TANAKA-RB/02-working/
/Projects/TANAKA-RB/02-working/experiment-alt-direction/

実験フォルダで作業し、メインの方向を置き換えるか（02-working/に移動し、正規を02-working/archive-original-direction/にリネーム）、棚上げにする（探索の記録として実験フォルダに残す）。

このパターンは「もしも」の作業がメインの作業ファイルを汚染するのを防ぎつつ、有効な参照として保存する。

それでも起きる競合の解決

以上の対策があっても競合は起きる。同期ツールの対処法はそれぞれ異なる：

Google Drive: Googleフォーマット以外の最後保存勝ちの挙動。共同編集するファイルにはDocs/Sheets/Slidesを使う
Dropbox: 編集者名付きの「競合コピー」ファイルを作成する。手動でマージするか不要なら削除
OneDrive: 同様——Document_user1.docx対正規ファイル
Git: 人間の解決が必要な明示的なマージ競合マーカー。明確だが不親切

チームに競合コピーを無視せず実際に見るよう教える。3週間前の古い競合コピーに重要な編集が含まれていたことに誰も気づかなかったという事態が起きる。

バージョン管理されたファイルを外部に納品する

クライアントがレビュー中の特定のメジャーバージョン——継続中の作業ではなく——を外部に送るとき、同期リンクではなく転送チャネルで送る。同期ツールからのリンク共有はクライアントに変化し続けるライブ編集バージョンを見せるリスクがある。

転送リンクはファイルをある瞬間にキャプチャして送る。HexaTransferやDropbox Transfer、Smashのようなサービスは送信時の状態を固定する。クライアントはリンクの有効期限が切れるまで、送ったものを正確に見られる。

https://hexatransfer.com をお試しください——無料・アカウント不要・最大10GB。