結論：公開サンプルの77本は全部自動変換できた。ただし条件付きの数字です
当社はAccessデータベースの解析・移行サービスの一環として、AccessのクエリをPostgreSQLへ自動変換する仕組みを開発しています。2026年7月、Microsoftが長年配布してきた公開サンプル「Northwind」（受発注管理のテンプレート。Access公式ブログでも「数十年前に作られたサンプル」として紹介されています）を題材にした実測で、保存クエリ全77本の自動変換に到達しました。変換しただけでなく、変換後のSQLをPostgreSQLで実際に実行し、Access本体の実行結果と値まで突き合わせています。値まで一致を確認できたのは74本で、不一致は0件です。残る3本は、照合に使った条件ではAccess側・PostgreSQL側ともに対象行が0件になったため、「一致」には数えていません（不一致ではありません）。後述のとおり、添付列を分割したクエリは分割後の列構成での照合です。
「100%」という数字は、それだけを切り出すと誇大広告のようにも見えます。だからこの記事では、数字の分母をどう数えたか、何を条件にした照合か、そしてお客様の実案件でこの数字がそのまま出るわけではない理由まで、実測の中身を隠さず書きます。
分母をどう数えたか：フォームに埋め込まれたクエリも含む77本
自動変換率の議論でいちばん怪しくなりやすいのが分母です。「変換できたクエリだけを分母にする」操作をすれば、率はいくらでも上がります。当社の実測では、Northwindのデータベースファイルからクエリ定義（QueryDef）を機械的に列挙した実数77本を分母にしました。ここには、クエリ一覧に表示される保存クエリだけでなく、フォームやコンボボックスのレコードソースとしてファイル内部に保存されている隠しクエリ（名前が「~sq_」で始まるもの）も含みます。
内部クエリまで含めたのは、移行の実務ではそちらが本丸だからです。画面のドロップダウンひとつにもクエリが埋まっていて、移行時にはそれも全部動かす必要があります。見えるクエリだけ変換できても、画面は動きません。
最大の壁は添付ファイル型と複数値フィールドだった
変換の壁になりやすいのは、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月30日に実行した最新の全量検証では、77本のうち74本で両者の結果が一致し、不一致は0件でした。照合の土台はあくまで変換後の設計で、添付列を分割したクエリについては、分割後に残した列の値を突き合わせています（落とした添付列まで一致を主張するものではありません）。
内訳は、そのまま実行して照合したものが59本、パラメータに代表値を与えて照合したものが9本、フォーム参照に値を差し込んで照合したものが5本、システムテーブル参照の1本です。残る3本は、照合に使った条件ではAccess側・PostgreSQL側ともに対象行が0件になりました。両側とも空では変換の正しさを何も確かめられないので、当社はこれを「一致」に数えず、検証していない扱いにしています（不一致ではありません）。この3本には、日付を固定して照合する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で、添付ファイルのデータはどうなりますか。
添付列は子テーブルに分割する設計までを自動化しており、添付ファイルの中身（画像などのバイナリ）の移し替えは別工程です。「クエリが動くこと」と「添付データの移行が終わること」は分けて管理し、後者を済ませたと偽らないよう、変換結果に未了の範囲を明示しています。
訂正（2026年8月2日）
公開時（2026年7月26日）、この記事は「77本すべてで結果が一致した」と書いていました。これを「74本で一致、不一致は0件」に訂正します。数字を下げる訂正です。
理由は2つあります。1つは、当社が検証の数え方を厳しくしたことです。Access側とPostgreSQL側の両方で対象行が0件になった照合は、実際には何も確かめられていません。公開時はこれを「一致」に数えていましたが、その後「両側とも空なら一致に数えない」という規則に改めました。もう1つは、その規則で最新の全量検証をやり直したところ、該当が3本あったことです。不一致（結果が食い違ったもの）は、公開時も今回も0件のままです。変換できた本数77本も変わりません。
当社は「確かめた範囲だけを確かめたと言う」ことを社内の規則にしています。それに照らすと公開時の書き方は過大でした。お詫びして訂正します。