2025.04.13 2025.04.13

Azure DevOps/ GitとAccess：どうやってバージョン管理する？

nanikatoaccess

以下では、「Azure DevOps/ GitとAccess：どうやってバージョン管理する？」をテーマに、Microsoft Accessファイル（.accdb/.mdb）をクラウドベースでバージョン管理したり、チーム開発でソースコードを安全に共有する際のポイントを解説します。Accessは単体ファイルにデータベースやオブジェクトをまとめているため、テキストベースのGit運用が難しい面がありますが、工夫次第でGit/Azure DevOpsを活かした開発フローを構築可能です。

1. なぜAccessでバージョン管理が必要か？

共同開発やバックアップ: 複数人がフォームやレポートを追加・変更していると、どの時点で何を変えたか分からなくなる
リリースとロールバック: 新バージョンの配布後に不具合が見つかった際、すぐ過去バージョンに戻せるようにしたい
安全な更新プロセス: Git等を通じてプルリクレビュー的なフローを採り入れれば、誤変更を早期に発見

2. AccessファイルをそのままGitに入れるのは困難？

ないものはない！お買い物なら楽天市場

2.1 バイナリファイル問題

Accessファイル(.accdb/.mdb) はバイナリであり、テキスト差分管理が困難
変更があればファイル全体が差分として扱われてしまい、コミットのたびに大容量になる可能性がある
マージコンフリクトが発生すると、バイナリゆえに手動で解決が難しい

2.2 実務的な影響

単純に.accdbをGitリポジトリにコミットし続けると、リポジトリ容量が膨張しがち
一時的にはできても、チームで同時に開発する場合にマージできない問題が出やすい

3. アプローチ1：ファイルをまるごとバイナリ管理し、世代管理のみ行う

Git LFS (Large File Storage)
- Gitに大きなバイナリを保存する際にLFSを使い、差分ではなくファイルを世代管理
- 変更点を比較するのは難しいが、ロールバックや「どの時点のファイルか」把握は可能
Azure DevOpsリポジトリ + LFS
- Azure DevOpsでGitリポジトリを作成し、.accdbファイルをLFSに登録
- コミットメッセージで変更内容を記録し、同時に1人が編集→コミットする運用
Lock 機能
- Git LFSには「ファイルロック」機能があり、誰かが編集中は他の人が変更できないようにロックをかけられる
- これによりバイナリファイルの競合を防ぎ、常に1人ずつが更新する形

メリット:

比較的簡単に世代管理でき、コミット履歴で過去バージョンに戻せる
複数人同時編集は原則避ける
デメリット:
差分やマージができず、編集は単独で行う必要がある
ファイルサイズが大きいとリポジトリ肥大に注意

4. アプローチ2：VBAコードをテキストエクスポートし差分管理

4.1 コードエクスポートの考え方

Accessのフォーム/レポートのVBAモジュールはテキスト形式でエクスポート可能
「Access Developer Extensions」やAuto FE Updaterに付属する機能、あるいは自作VBAでSaveAsTextを使いモジュールをテキストファイル化
Gitはテキスト差分を管理しやすいため、VBAロジックの変更点を普通のソースコードのように追跡・比較できる

4.2 実際の手順例

Accessファイルを運用
マクロ/VBA、あるいは外部スクリプトでApplication.SaveAsText acForm, "フォーム名", "Forms_フォーム名.txt"といった命令でエクスポート
生成されたテキストファイルをGitリポジトリにコミット
差分を見る・プルリクを出すなど一般的なGitワークフローが使える
逆にApplication.LoadFromText acForm, "フォーム名", "Forms_フォーム名.txt" で読み込み復元
テーブルやクエリはどうする？→ テーブル構造の変更は手動管理、クエリのSQLを.sqlとして保存する等

メリット:

VBAロジックの差分を見やすい → デバッグとコードレビューが楽
チームでコード変更を共有できる
デメリット:
画面デザイン(コントロール配置)部分はテキスト化されるが大量行で可読性低い
フォームやレポートのビジュアル変更は差分確認が大変
SaveAsText/LoadFromTextで同期する手間が増える

5. 実務上のワークフロー例

5.1 バイナリ管理 + コードエクスポートの組み合わせ

Git LFS で .accdb ファイルを管理し、週1回程度コミット
日々のコード変更（VBA）はSaveAsTextでテキスト化 → Git管理（差分レビューが可能）
GUI面の変更はバイナリファイルをローカルで編集し、マージではなくロックまたは1人集中作業で更新

5.2 Azure DevOpsビルドパイプライン

高度なケースでは、Azure DevOpsのビルドパイプラインで**SaveAsTextを実行し、成果物(テキストファイル)をビルド出力として保存。テスト後にLoadFromText**で再組立→配布
Accessでの自動テストは限定的だが、簡易スクリプトで起動～マクロ実行のチェックが可能

5.3 小規模チーム運用

1～2名が主に開発 → .accdbをOneDrive/SharePointかGit LFSに置き、ロックして編集
コミットメッセージで何を変えたか書く
大きなリリース前に全員がテストし、問題なければバージョンタグを付ける

6. 注意点とベストプラクティス

同時編集の衝突は不可避
- バイナリファイルをGitで扱うとマージが困難。1人1編集を徹底 or ファイルロックを利用
容量増大に注意
- Accessファイルが大きいとリポジトリ肥大化。LFSを使っても履歴が大きくなる
- 定期的なコンパクト＆修復でファイルサイズを抑える
Data vs Code
- Accessのテーブル内のデータはGitで追えない(差分やマージできない)ので、バックエンドをSQL Server等に移行し、Accessはフロントエンドとしてコードだけ管理が理想
Key: 1変更1コミット
- 頻繁にコミットしすぎず、1機能変更 or 1バグ修正でコミット
- コミットメッセージを丁寧に書くと後で追跡しやすい

7. まとめ：Access×Azure DevOps/Gitの現実的アプローチ

完全にテキスト差分管理は困難
- フォーム/レポートのビジュアルレイアウトはバイナリ要素。差分マージができない
2段階戦略:
- (A) Accessファイルそのものをバイナリ(LFS)でコミットし、世代管理
- (B) VBAやクエリSQLなどテキスト化できる部分をSaveAsText/エクスポートで差分管理
ロック or 1人集中編集
- バイナリファイルはマージできない → 誰かがフォームを編集中はロックして他の人が触らないように
SQL Server移行でデータとロジックを分離
- テーブルはサーバー側で管理し、Accessフロントエンドの構造をGitバージョン管理 → 推奨形態

AccessをGit/Azure DevOpsで管理する際は、小規模ならバイナリファイルをまるごと世代管理し、大幅なフォーム改修がなければ問題ない運用ができるでしょう。複数人で活発に開発するならVBAコードをテキストエクスポートする仕組みを併用し、差分確認やレビューを行うのがベスト。将来的にはバックエンドをSQL Serverに移行し、Accessフロントエンドだけをバージョン管理する流れが最も安定した運用モデルになるはずです。

関連記事

SQL Serverへの移行ステップ：SSMA for Accessを使ってみよう

Accessファイル(.accdb/.mdb)の構造を理解する：拡張子とエンジンの話

バックアップの自動化：バッチスクリプトでACCDBを定期コピーする術

このようにAzure DevOps/Git × Accessは決して“不可”ではなく、工夫によって一定のバージョン管理メリットを得られます。ソースコードテキスト化やGit LFSなどのテクニックを適用し、チームで安全にAccessアプリを開発・保守していきましょう。

DMM

ABOUT ME