AccessからPostgreSQLへの移行、クエリ77本を全件自動変換した実測記録

結論：公開サンプルの77本は全部自動変換できた。ただし条件付きの数字です

当社はAccessデータベースの解析・移行サービスの一環として、AccessのクエリをPostgreSQLへ自動変換する仕組みを開発しています。2026年7月、Microsoftが長年配布してきた公開サンプル「Northwind」（受発注管理のテンプレート。Access公式ブログでも「数十年前に作られたサンプル」として紹介されています）を題材にした実測で、保存クエリ全77本の自動変換に到達しました。変換しただけでなく、変換後のSQLをPostgreSQLで実際に実行し、Access本体の実行結果と値まで突き合わせて、77本すべての一致を確認しています（後述のとおり、添付列を分割したクエリは分割後の列構成での照合です）。

「100%」という数字は、それだけを切り出すと誇大広告のようにも見えます。だからこの記事では、数字の分母をどう数えたか、何を条件にした照合か、そしてお客様の実案件でこの数字がそのまま出るわけではない理由まで、実測の中身を隠さず書きます。7月21日の時点では、当時対象にしていた40本のうち12本しか変換できていませんでした。そこから数日で何を潰していったかの記録でもあります。

分母をどう数えたか：フォームに埋め込まれたクエリも含む77本

自動変換率の議論でいちばん怪しくなりやすいのが分母です。「変換できたクエリだけを分母にする」操作をすれば、率はいくらでも上がります。当社の実測では、Northwindのデータベースファイルからクエリ定義（QueryDef）を機械的に列挙した実数77本を分母にしました。ここには、クエリ一覧に表示される保存クエリだけでなく、フォームやコンボボックスのレコードソースとしてファイル内部に保存されている隠しクエリ（名前が「~sq_」で始まるもの）も含みます。

内部クエリまで含めたのは、移行の実務ではそちらが本丸だからです。画面のドロップダウンひとつにもクエリが埋まっていて、移行時にはそれも全部動かす必要があります。見えるクエリだけ変換できても、画面は動きません。

最大の壁は添付ファイル型と複数値フィールドだった

7月21日時点の実測で変換が止まっていたクエリの多くは、SQLが難しかったわけではありません。テーブル側の問題でした。Northwindの社員テーブルには顔写真の「添付ファイル型」列があり、商品テーブルには複数の値をひとつの列に持てる「複数値フィールド」があります。どちらもAccess独特のデータ型で、一般的なリレーショナルデータベースに直接対応するものがありません。

これはAccess移行の世界では昔から知られた壁で、Microsoft公式の移行ツールSSMA（SQL Server Migration Assistant）でも、公式ガイドに「SSMAは添付ファイル列を含むテーブルを移行しない」「複数値フィールドは変換されない」と明記されています。SSMAの守備範囲についてはSSMAでのアップサイジング解説に詳しく書きました。

当社の対応は、添付列・複数値フィールドを親テーブルから切り出して別の子テーブルに分割し、残りの列を変換するという方法です。教科書的な正規化で、SSMAの公式ガイドが移行前の準備として利用者に促している設計見直しを、自動化した形になります。ここで効いたのが、テーブル全体を「*」（ワイルドカード）で参照しているクエリの扱いです。添付列を含むテーブルの「SELECT T.*」は、そのままでは分割後のテーブルと列構成が食い違ってしまうため、変換器が「*」を分割後に残る列の明示リストに展開してから変換します。落とした添付列は変換結果に注記として開示し、「元のAccessと完全に同じ列構成だ」とは主張しない設計にしています。この対応で、社員・得意先・仕入先・運送会社まわりの止まっていたクエリが連鎖的に動くようになりました。

パラメータ・フォーム参照・日付。単純なSELECT以外をどう扱ったか

実務のAccessクエリは、単純なSELECT文ばかりではありません。実行時に値を尋ねるパラメータクエリ、開いているフォームの入力値を参照する「Forms!フォーム名!コントロール名」形式のクエリ、Date()関数で今日の日付に依存するクエリ。たとえばパラメータ付きクエリは、SSMAでは「変換されない」と公式に明記されている領域です（AccessからPostgreSQLへの移行手順でも触れています）。フォーム参照と日付依存は、当社の変換器にとっても追加の仕掛けが必要だった部分です。

当社の変換器は、パラメータやフォーム参照を、PostgreSQL側でプレースホルダ（実行時に値を渡す穴）を持つSQLに変換します。値の型が証明できる場合だけ変換し、証明できなければ「変換できない」側に倒します。日付依存のクエリは、タイムゾーンを指定した固定日時の変換として扱います。Accessは手元のパソコンの時刻とタイムゾーンで動き、PostgreSQLは接続ごとのタイムゾーン設定に依存するため、この指定を曖昧にすると「同じクエリなのに日をまたぐと結果が違う」事故が起きるからです。今回の77本にはこの3種類が全部含まれており、いずれも上記の条件付きで変換しています。

「変換できた」の証明：Access本体と実行結果を突き合わせる

構文エラーなく変換できることと、正しく変換できていることは別問題です。SQLの方言変換では、構文は通るのに結果の値が微妙に違うバグがいちばん怖い。当社はこれを検証するため、Windows仮想マシン上で本物のAccessに77本のクエリを実行させ、その結果を正解データとして、PostgreSQL側で変換後SQLを実行した結果と行の値まで突き合わせる自動検証を組んでいます。

2026年7月25日時点の実測では、77本すべてで両者の結果が一致し、不一致は0件でした。照合の土台はあくまで変換後の設計で、添付列を分割したクエリについては、分割後に残した列の値を突き合わせています（落とした添付列まで一致を主張するものではありません）。内訳は、そのまま実行して照合したものが60本、パラメータに代表値を与えて照合したものが9本、フォーム参照に値を差し込んで照合したものが5本、日付を固定して照合したものが2本、システムテーブル参照の1本です。パラメータ付きクエリの照合は「代表的な値での一致」であって、あり得る全入力での一致証明ではありません。また日付依存の2本は、固定した日付での結果が両側とも空集合になる一致で、行のあるデータでの一致より証拠として軽いことも書き添えておきます。それでも「変換器が出したSQLを本物のAccessと突き合わせ、不一致が出たら変換器のバグとして直す」というループを回し続けたことが、この期間の実質でした。

この数字が、あなたのAccessでそのまま出ない理由

正直に書きます。Northwindは、Microsoftが教材として設計したサンプルです（後継のNorthwind 2.0を発表した公式ブログ自身が、旧版の命名や正規化には改善余地があったと述べているくらいで、決して理想形ではありませんが）。それでも、実際の業務システムに比べれば規模は小さく、20年分の改修が積み重なったクエリ、VBAの中で組み立てられる動的SQL、外部システムへのODBC接続の入り混じり方は再現していません。当社の実測でも、題材が変われば自動変換率は変わります。

それでも公開サンプルでの実測を公開するのは、「どこまで自動でできて、どこから人手か」の境界線を、具体的な題材つきで示せるからです。Northwindは誰でも入手できるので、この記事に出てくるテーブルやクエリがどんなものかは、手元で開いて確認できます。お客様の実案件では、まず解析で「自動変換できるクエリ／できないクエリ」を理由付きで仕分けし、できない分を人手の工数として見積もる。この仕分けの精度が、移行見積りの精度そのものになります。お手元のAccessファイルが解析可能かどうかは無料の解析可否チェック（約2分・ファイル送信不要）で確認できます。

よくある質問

Q. 自分の会社のAccessでも100%自動変換できますか。

お約束できません。この記事の数字は公開サンプルNorthwind 2007の77本に対する実測で、実案件のデータベースでは構成次第で下がります。当社の方針は、率を約束することではなく、解析の段階で「変換できないクエリはどれで、理由は何か」を1本ずつ開示することです。

Q. フォームやVBAも自動変換されますか。

この記事の対象はクエリ（SQL）です。フォームは別機能として、解析結果から画面プロトタイプを自動生成する仕組みを開発しています。VBAは自動翻訳せず、どの画面のどの操作がどのVBAにつながっているかの対応付けを解析して開示する方針です。翻訳しないのは、VBAの自動翻訳は「動くように見えて挙動が違う」リスクが大きいと判断しているためです。

Q. なぜSQL ServerではなくPostgreSQLなのですか。

ライセンス費用のかからないオープンソースで、クラウド各社のマネージドサービスでも動かせるため、移行後の選択肢が広いからです。SQL Serverへの移行が適するケースももちろんあり、その場合はMicrosoft公式のSSMAが第一候補になります。使い分けはPostgreSQL移行の解説記事を参考にしてください。

Q. 変換後のPostgreSQLで、添付ファイルのデータはどうなりますか。

添付列は子テーブルに分割する設計までを自動化しており、添付ファイルの中身（画像などのバイナリ）の移し替えは別工程です。「クエリが動くこと」と「添付データの移行が終わること」は分けて管理し、後者を済ませたと偽らないよう、変換結果に未了の範囲を明示しています。