OneDriveでデータベースを共有するのは危険？複数PCからの同時更新を避けるべき理由
- yuji fukami
- 3 日前
- 読了時間: 9分
OneDriveは、複数のPCから同じファイルを開ける便利なサービスです。そのため、AccessやSQLiteのデータベースファイルもOneDriveに置いておけば、そのまま複数人で共有できそうに見えます。
実際、利用者が一人だけの場合や、更新のタイミングが重ならない間は、問題なく動いてしまうこともあります。しかし業務運用では、「たまたま動いた」と「安全に運用できる」は別の話です。
この記事は全2回シリーズの第1回です。第1回では、OneDrive上のデータベースファイルを複数PCから直接更新する運用に、どのような問題が起こり得るのかを整理します。第2回では、VPNやサーバー構築が難しい会社でも導入しやすい、安全なデータ共有の方法を解説します。
先に結論を書いておきます。危険なのはOneDriveというサービスそのものではありません。同期ストレージ上に置いたデータベースファイルを、複数端末から同時または断続的に直接更新する「設計」のほうです。
OneDriveはデータベースサーバーではない
まず、OneDriveがどのような仕組みで動いているかを確認します。
PC-Aのローカルファイル
↓
OneDriveへ同期
↓
PC-Bへダウンロードここで大事なのは、PC-AとPC-Bが一つのデータベースエンジン（データを管理する中心的なプログラム）へ同時に命令を送っているわけではない、という点です。
各PCは、あくまで自分の中にあるローカルのファイルを操作している
その変更を、OneDriveが後からクラウド経由で同期している
同期には時間差がある
オフライン、通信遅延、同期の一時停止なども起こり得る
つまり、次のように整理できます。
「同じファイルが見えていること」と「同じデータベースへ整合性を保って接続していること」は同じではありません。
一方、データベースサーバーは、複数のPCからの命令を1台がまとめて受け取り、順番や競合を管理しながら処理します。
【OneDrive】
PC-Aのコピー ─→ クラウド同期 ←─ PC-Bのコピー
【DBサーバー】
PC-A ─┐
├→ 1台のDBサーバーが更新を管理
PC-B ─┘図の上下で、更新を管理している場所が違うことが分かると思います。OneDriveには、更新の順序や排他制御を引き受ける中心的な存在がいません。
ファイル型データベースにはロックと更新順序がある
AccessやSQLiteのような「ファイル型データベース」（1つまたは数個のファイルにデータが入っているタイプ）では、複数の処理が勝手に同じ場所を書き換えないよう、ロックやトランザクションという仕組みを使います。
初心者の方向けに例えると、次のようなイメージです。
一冊の帳簿を二人で同時に修正する場合、誰がどのページを書いているかをその場で共有できなければ、修正内容が衝突します。データベースのロックは、この「今は誰が書いているか」を管理する仕組みです。
具体的には、次のような処理が行われています。
読み込み中・書き込み中の状態を管理する
書き込みの間は、他の処理が同じ場所を触れないように排他的に扱う
更新が確定する前に問題が起きた場合に、途中の状態を戻せるようにする
SQLiteでは、DB本体のほかにジャーナルやWALといった補助ファイルを使うことがある
Accessでは、誰が開いているかを示すロック情報のファイルが作られる
なお、AccessとSQLiteは内部の仕様が同じではありません。方式は異なりますが、「複数端末から安全に更新するには、ロック情報の整合性が保たれている必要がある」という点は共通しています。
そしてこのロック情報は、リアルタイムに全員へ共有されて初めて意味を持ちます。ここが、後から同期するOneDriveと相性の悪いところです。
OneDrive同期との組み合わせで想定される問題
1. 同期競合
次のような流れを考えてみます。
10:00 PC-Aが古い状態のDBを開く
10:01 PC-Bも同じ状態のDBを開く
10:05 PC-Aが更新して保存
10:06 PC-Bが別の内容で保存
10:07 OneDriveが両方の変更を同期しようとするこのとき、次のような結果が起こり得ます。
競合コピー（別名のコピーファイル）が作成される
一方の更新が反映されない
利用者が、どちらを正しいファイルとすべきか判断できない
データベースは全体が一つのファイルであるため、通常の文書より競合の影響が大きい
Wordファイルであれば「Aさんの版とBさんの版を見比べて統合する」こともできますが、データベースは全テーブル・全レコードが1ファイルに詰まっています。競合が起きると、失われるのは1行ではなく、その間に入力された更新全体になり得ます。
2. ロック情報の不整合
PC-Aでは「更新中」の状態になっている
PC-Bはまだ同期が終わっていないため、「更新中」であることを認識できない
端末ごとのローカルの状態と、クラウド側の状態が一致しない可能性がある
ロックは「今この瞬間、誰が書いているか」を伝えるためのものです。その情報自体が遅れて届く環境では、本来の役割を果たせません。
3. DB本体と補助ファイルの同期差
SQLiteでは、利用モードによってDB本体に加えてジャーナルやWALなどの補助ファイルを扱うことがあります。これらは本来、セットで整合性が取れている必要があります。
しかし同期環境では、次のようなことが起こり得ます。
DB本体だけが先に同期される
補助ファイルだけが残ってしまう
同期の途中でPCが停止する
通信が切断される
OneDriveは、データベースエンジンのトランザクション（一連の更新をひとまとまりとして扱う単位）を理解して、関連ファイルを一体として確定してくれるわけではありません。あくまで「変更されたファイルを順次同期する」だけです。
4. 読み取り専用・使用中・同期停止
運用中には、次のような現象も起こり得ます。
ファイルが「使用中」と表示されて開けない
読み取り専用として開かれてしまう
OneDriveの同期が保留のまま進まない
別名のコピーが作られる
古いファイルが再び同期されて戻ってくる
5. 問題が再現しにくい
私の経験上、最も厄介なのは「普段は動いてしまう」という点です。
たまたま同時更新が発生しなかった
通信状態が良かった
検証時の利用者が一人だった
データ量が少なかった
この状態で「検証できたから大丈夫」と判断して本番運用に入ると、忙しい時期や、拠点が増えたタイミングなど、条件が重なった瞬間に問題が表面化します。動作確認で問題がなくても、運用時の安全性を保証できるとは限りません。
MicrosoftとSQLiteの公式情報
これは経験則だけの話ではなく、提供元自身が注意を促している内容でもあります。
Microsoft Accessの公式説明
Microsoftは、AccessデータベースをOneDriveやSharePointのドキュメントライブラリから開くことを避けるよう案内しています。複数人が開くと複数のコピーが作られたり、予期しない動作が発生したりする可能性があると説明されています。
SQLiteの公式説明
SQLiteは、書き込み時に排他的なロックを使います。公式ドキュメントでは、ネットワークファイルシステム上ではロック処理が正しく動作しない実装があり、データベース破損につながった事例があると説明されています。
読むときの注意点
ここで一つ補足があります。OneDriveは、一般的なネットワーク共有フォルダと同じものではありません。各PCのローカルコピーをクラウド経由で同期する仕組みです。ですから、「SQLite公式のネットワークファイルシステムへの警告が、そのままOneDriveのすべてを直接証明する」とまでは言えません。
正確には、次のように整理するのが妥当だと考えています。
SQLite公式が警告するファイルロックの信頼性に加えて、OneDriveでは端末ごとのローカルコピーと同期遅延が存在します。そのため、共有データベースの保存場所としては、さらに慎重な判断が必要になります。
VPNを追加しても根本解決にはならない
「セキュリティが心配だからVPNを入れる」という相談をいただくことがあります。VPNは有用な仕組みですが、この問題の解決策にはなりません。役割を整理します。
VPNでできること
通信経路の暗号化
社内ネットワークへの安全な接続
接続元の制限
データベースサーバーをインターネットへ直接公開せずに済む
VPNで解決できないこと
OneDriveの同期遅延
端末ごとに複数のローカルコピーが存在すること
ファイルの同期競合
ファイル型データベースのロックの問題
通信切断時のデータベースファイルの更新
DB本体と補助ファイルの同期順序
つまり、それぞれの役割は次のように分かれています。
VPN＝通信経路を守る
DBサーバー＝同時更新を管理する
OneDrive＝ファイルを同期するVPNは「安全な通信経路」を作る仕組みであり、「OneDriveをデータベースサーバーに変える仕組み」ではありません。
OneDriveを使ってよい用途・避けるべき用途
OneDrive自体を否定する必要はまったくありません。用途を分けて考えるのが現実的です。
適している用途は次のとおりです。
Word、PDF、画像などの共有（通常のファイル共有）
Excel帳票の配布（ただし同時編集の条件には注意）
条件付きで使える用途は次のとおりです。
データベースを閉じた状態で、コピーを保管する（正規のバックアップ手順を優先する）
完成したデータベースファイルの受け渡し（同時に利用しないことが前提）
避けたほうがよい用途は次のとおりです。
Accessのバックエンドを複数PCから直接更新する（Microsoftも非推奨）
SQLiteのファイルを複数PCから直接更新する（ロックと同期の問題）
アプリが常時読み書きするデータベースファイルを置く（同期ストレージ向きではない）
もう一点、補足しておきたいことがあります。「同期」と「バックアップ」は同じではありません。誤って削除したファイルや、破損したファイルがそのまま同期されてしまう可能性もあります。重要なデータベースには、データベースエンジンに適したバックアップ方法と、実際に復元できるかの確認が必要です。
まとめ
改めて整理します。
OneDriveは、資料や帳票を共有する場所としては非常に便利です
しかし、リアルタイムに排他制御を担うデータベースサーバーではありません
AccessやSQLiteのファイルを、複数端末から直接更新する設計は避けるのが安全です
業務データを共有したい場合は、データベースサーバー、Webアプリ、Microsoft Listsなど、別の仕組みを検討します
「保存できたから大丈夫」ではなく、同時更新、通信切断、同期遅延まで含めて安全性を考える必要があります。動いているように見える期間があるからこそ、判断が難しいテーマだと感じています。
では、どうやって安全に共有すればよいのでしょうか。VPNや専門的なサーバー設定が難しい会社でも導入しやすい方法を、第2回の「VPNなしで業務データを安全に共有するには？ITに詳しくない会社向けの現実的な選択肢」で整理しています。あわせてご覧ください。
