Accessの画面はそのまま、データだけSQL Serverへ移す構成

結論：Accessの画面を残したままデータだけSQL Serverへ移す構成が選ばれる理由

AccessをSQL Serverに移す、というと「Accessを捨ててSQL Serverに全部乗り換える」と受け取られることがあります。しかし実際のところ、当社の移行支援でよく採用されるのは「フォームやレポートはAccessに残し、データを持つバックエンドだけをSQL Serverに移す」という構成です。Microsoftの公式移行ガイドも、この2層構成を移行後の代表的な構成として案内しています（Access データベースを SQL Server に移行する — Microsoft Support）。

この構成を「アップサイジング」と呼びます。Accessのフォームやレポート、VBAは引き続きAccessで動き、テーブルとデータだけSQL Serverに移してリンクテーブルで接続します。利用者側から見た操作画面は基本的に変わらないため、当社の経験上、研修コストを抑えやすい移行方式です。一方でデータの保管場所がSQL Serverになるので、公式ガイドはより多くの同時接続ユーザーに対応できるとしています。加えて、2GBの壁や複数人で使うと遅い・壊れる問題、accdbファイルの破損によるデータ消失リスクといったファイル共有型の弱点についても、当社の経験上、改善が期待できます。

この記事では、なぜこの構成が選ばれるのか、どんな課題が解決されてどんな課題が残るのか、実際の接続の仕組みはどうなっているか、の3点に絞ります。移行ツールの手順はSSMAの解説記事（SSMA詳細）に、無料版の仕様はSQL Server Express記事に委ねます。

バックエンドだけ移す構成が解決すること・しないこと

アップサイジングで解決できる課題と、解決できない課題を最初に整理しておきます。「移したのに期待した効果が出ない」という誤解の多くは、ここの認識のズレから来ます。

Microsoftの公式移行ガイドによると、SQL Serverは「2GB」を超えるデータ量、255人を超える同時接続ユーザーに対応できると説明されています。ファイル共有型のaccdbと比べてより多くの同時接続ユーザーに対応できる点は、Microsoftが案内している移行のメリットの一つです。

ただし、フロントエンドがAccessのままである以上、Accessのサポート期限問題は引き続き存在します。Access 2021のサポートは2026年10月13日に終了予定です。「データをSQL Serverに移しさえすればフロントエンドは何年でも使える」という理解は誤りで、フロントエンドの更新計画は別途必要です。

2層構成の仕組み：リンクテーブルとODBC接続

アップサイジング後の構成では、移行対象の業務データは原則としてSQL Server側に置かれます。フォームやVBAは引き続きAccessで動きますが、データの読み書きはSQL ServerにODBC経由でアクセスするリンクテーブルを通じて行います。

リンクテーブルは、Accessから見ると通常のローカルテーブルと同じように見えます。フォームをデザインする側からは「テーブルがどこにあるか」を意識せず作れます。フォームに紐付いたテーブルがリンクテーブルになっても、フォームの見た目は変わりません。ただし、動作が変わる箇所があります。

• VBAでローカルのaccdbを直接操作していたコードは、接続先によっては接続文字列をSQL Server向けに書き換える必要がある（リンクテーブルへの付け替えだけで既存DAOコードが動き続ける場合もある）
• AccessのローカルテーブルとSQL Serverのリンクテーブルを同一クエリで結合している箇所は、パフォーマンス問題が起きやすいので解消する
• Accessのフォームで使っているパラメータクエリが、リンクテーブルに対しても正しく動くか検証が必要（日付型の扱いなどでSQL ServerとAccessに差異がある）

ODBC接続の設定はDSN（データソース名）またはDSNレスの接続文字列で行います。Microsoftの移行ガイドでは、複数のPCで同じアプリを使う場合はDSNを各PCに同じ設定で作るか、DSNファイルに格納した接続文字列をVBAで読み込む方式を推奨しています。

パフォーマンスに問題が出た場合の選択肢の一つがパススルークエリです。AccessがSQL文を変換せずSQL Serverに送り、サーバー側で処理させます。Accessのリンクテーブル経由のクエリより効率よく実行できるケースがあります。ただしパススルークエリはTransact-SQLで記述する必要があり、Accessのクエリデザイングリッドが非表示になってSQL Viewでの編集に切り替わります（パススルークエリの作成 — Microsoft Support）。

段階移行の第一歩として使う考え方

バックエンドをSQL Serverに移す構成は、「全面移行の前段として動かしながら移行リスクを下げる」手段にもなります。

Accessを完全に廃止して新しいシステムに置き換えるには、要件定義から開発・テスト・教育まで相応のコストと期間がかかります。その間も現行のAccessシステムは動かし続けなければなりません。アップサイジングなら、フロントエンドは現状維持のまま、データの置き場所だけSQL Serverに移すことで、フロントエンドの作り直しを後回しにしながら2GB上限とMicrosoftが案内する同時接続ユーザー上限の課題に先に対処できます。当社の経験上、全面移行より短期間・低コストで着手できるケースが多いです。

その後のフロントエンドの移行先としては、Power Apps、kintone、Webシステムなど複数の選択肢があります。移行先比較も参考にしてください。データがSQL Server上にある状態での接続設計については移行先ごとの検討が必要ですが、「データの場所がSQL ServerかAccdbか」という差は後工程での選択肢に影響します。既存のAccessからの移行コストについては費用相場の解説をご覧ください。

移行の前に整理しておくこと

バックエンドをSQL Serverに移す作業を始める前に、Accessデータベース側で確認しておくことがあります。Microsoftの公式移行ガイドでは以下を事前作業として案内しています。

1. バックアップを取る（作業前の絶対条件）
2. 全テーブルに主キーを設定する（Microsoftの移行ガイドが事前作業として案内している。主キーがないと移行後の更新・削除操作に支障が出やすい）
3. Attachment型フィールドを確認する（SSMAでは変換できない）
4. テーブル間のリレーションシップを整理する

特に主キーは見落としがちです。Accessでは主キーなしのテーブルでも動きますが、SQL Serverへ移行後にAccessフロントエンドからデータを更新・削除しようとすると問題が出ます。移行ツール（SSMA）を実行する前に設定しておく方が作業がスムーズです。

SQL Serverのエディション選択については別途検討が必要です。無償で使えるSQL Server Expressは小規模な環境では十分機能しますが、エディションごとの上限はSQL Server Express記事を参照してください。

現状のAccessが実際にSQL Server移行に向いた構成かどうか確認したい場合は、無料の解析可否チェックで現状を把握するところから始めることができます。ファイルの送信は不要です。

よくある質問

Q. アップサイジングとはどういう意味ですか。

Accessのデータ（テーブル）をSQL Serverへ移し、フォームやレポートなどの画面側はAccessに残して、リンクテーブルで接続する構成のことです。もとはMicrosoftがAccess内蔵のアップサイジングウィザード（Access 2013で廃止）の機能として使っていた用語ですが、現在も同じ構成を指す言葉として使われています。

Q. 移行後もAccessのライセンスが必要ですか。

フロントエンドとしてAccessを使い続けるかぎり、製品版Accessまたは利用条件を満たすAccess Runtimeが各利用者の環境に必要です。アップサイジングはAccessを廃止する移行ではなく、Accessと組み合わせて使う構成です。SQL Serverのライセンスは選択するエディションによって変わります。SQL Server Expressは無償で提供されているエディションで、小規模環境ではサーバーライセンスのコストをかけずに始められます（SQL Server Expressの制限と手順）。ライセンス要件は環境によって異なるため、導入前にMicrosoftのライセンス条件を確認してください。

Q. 移行後にAccess側のフォームを全部作り直す必要がありますか。

全部作り直す必要はありません。リンクテーブルへの切り替えとODBC接続の設定を行えば、既存のフォームを継続利用できる場合があります（動作は個別に検証が必要です）。ただし、ローカルテーブルを直接参照しているVBAコードや、AccessとSQL Serverのデータ型の差異が影響する箇所については個別に対処が必要です。当社の経験上、日付型の取り扱いと自動採番（オートナンバー vs. IDENTITY列）の違いが修正箇所として出やすいです。

Q. バックエンドをSQL Serverに移したのに速くならない場合はなぜですか。

よく見られる原因の一つは混在クエリです。AccessのローカルテーブルとSQL Serverのリンクテーブルを同一クエリで結合していると、パフォーマンス問題が起きやすいとMicrosoftの移行ガイドも警告しています。移行後にパフォーマンスが出ない場合は、まずこの混在クエリが残っていないかを確認してください。もう一つは、絞り込みや集計がSQL Server側へ十分に委譲されず、生成されたSQLが非効率になるケースです。パススルークエリへの書き換えでサーバー側に処理を寄せると、改善につながることがあります。