概要
| この記事の結論 Accessでは、選択クエリで抽出結果を確認してから[テーブルの作成]へ切り替え、作成先のテーブル名を指定して実行します。SQLではSELECT INTOを使います。作成したテーブルは実行時点のコピーで、元データの更新は自動反映されません。同名テーブルの再作成や、主キー・インデックスなどの設定漏れに注意が必要です。 |
この記事でわかること
- 選択クエリで対象データを先に確認する
- SELECT INTOで新規テーブルを作る
- 主キーと各種プロパティを作成後に確認する
- 件数・合計・日付境界を照合してから利用する
この記事の主な内容
- テーブル作成クエリの仕組みと使い分け
- 作成前に準備するデータと確認事項
- デザインビューでテーブルを作る手順
- SELECT INTOで書くSQLと実行結果の確認
- 作成できない原因と再実行の注意点
- 業務で繰り返し使うときの設計と保守
- まとめ
- よくある質問
想定読了時間:約12分~16分
テーブル作成クエリの仕組みと使い分け
テーブル作成クエリを使うと、必要な行だけを抽出したり、金額を計算したりした結果を、新しいテーブルに保存できます。月末の集計対象をいったん固定する、別の担当者へ必要な項目だけを渡す、といった場面で役立ちます。
通常の選択クエリは、開くたびに元データを読み、条件に合う結果を表示します。一方、テーブル作成クエリが作るのは実行時点のデータのコピーです。元の売上を後で修正しても、作成済みのテーブルには自動反映されません。この固定された状態をスナップショットと呼びます。
選択クエリや追加クエリとの違い
まず決めるのは「新しい保存先が必要か」です。結果を画面で確認したいだけなら選択クエリ、設計済みのテーブルに毎月データを蓄積したいなら追加クエリが候補です。既存の金額や区分を変更したい場合は更新クエリを使います。
| 目的 | 使うクエリ | 実行後の状態 |
|---|---|---|
| 結果を確認する | 選択 | 原則として表示するだけ |
| 結果を新しい表に保存する | テーブル作成 | 新しいテーブルとレコードができる |
| 既存の表へ行を足す | 追加 | 既存テーブルのレコードが増える |
| 既存の値を変更する | 更新 | 条件に合うレコードの値が変わる |

テーブル作成は、既存表の「完全な複製」とは異なります。データと一緒に、主キーや入力規則まで同じ状態で引き継がれると考えると、重複を許したり、後続処理が遅くなったりする原因になります。作成後の設計確認までを一つの作業にします。
保存したコピーの用途を決める
例えば、月次会議で使った売上の根拠を保存するなら、対象年月に加えて作成日時と抽出条件を記録します。後から元データに訂正が入ったときに、どちらが正しいかを判断できるようにするためです。これは運用上の設計提案であり、テーブルを作るだけで自動的に記録される情報ではありません。
作成前に準備するデータと確認事項
最初は業務データベースのコピーで試します。特に同名テーブルを使い回している場合は、その表を参照するフォーム・レポート・別クエリがないか確認してください。自分だけの一時表と思っていても、月次処理の途中結果として他の処理が利用している可能性があります。
説明用の売上データ
以下は教育用の架空データです。T_売上の売上IDは一意、売上日は日付/時刻型、顧客IDと数量は数値型、単価は通貨型とします。各行は売上明細1件を表し、金額は数量×単価で求めます。実際の帳票では税や端数処理のルールを別途合わせてください。
| 売上ID | 売上日 | 顧客ID | 数量 | 単価 |
|---|---|---|---|---|
| 1001 | 2026/09/01 09:00 | 201 | 2 | 1,000 |
| 1002 | 2026/09/15 10:00 | 202 | 3 | 500 |
| 1003 | 2026/09/30 15:30 | 201 | 1 | 2,000 |
| 1004 | 2026/10/01 00:00 | 201 | 4 | 800 |
9月分を対象にする場合の期待結果は1001~1003の3件で、金額合計は5,500です。先にこの期待値を用意すると、操作が成功したかどうかをテーブルの有無だけで判断せずに済みます。
実行前にそろえるもの
- 元データベースのバックアップと、試行用のコピー。
- 作成元のテーブル名、抽出条件、必要なフィールド名。
- 未使用の出力先名。例はT_売上保存_202609_検証です。
- 期待する件数・合計・対象外データと、保存先の空き容量。

対象ファイルの内容を信頼できない場合、クエリが動かないからといって無条件にコンテンツを有効化しないでください。自社の管理対象であることを確認したうえで、組織の信頼設定に従います。また、他の人が出力先を開いている場合は、処理時間を調整する必要があります。
デザインビューでテーブルを作る手順
基本操作は「選択クエリを完成させる」「テーブル作成へ切り替える」「実行する」の順です。抽出条件が未確認のまま、いきなりアクションクエリを実行しないことが大切です。アクションクエリとは、データの追加や変更、新しいテーブルの作成などを行うクエリの総称です。
選択クエリで抽出結果を確かめる
1. [作成]から[クエリ デザイン]を開き、T_売上を追加します。
2. 売上ID、売上日、顧客ID、数量、単価をデザイングリッドへ追加します。
3. 空いているフィールド欄へ「金額: [数量]*[単価]」を入力します。
4. 売上日の抽出条件へ「>=DateSerial(2026,9,1) And <DateSerial(2026,10,1)」を入力します。
5. [表示]をデータシートビューへ切り替え、3件・合計5,500となることを確認します。
画面のタブ名やボタン配置はAccessの版やリボン幅によって異なることがあります。[クエリ デザイン]にあるクエリの種類と[実行]を目印にしてください。抽出結果を直す場合はデザインビューへ戻り、条件を修正して再度表示します。
テーブル作成に切り替えて実行する
1. 正しい結果が出たらデザインビューへ戻り、クエリの種類で[テーブルの作成]を選びます。
2. テーブル名にT_売上保存_202609_検証を入力します。今回は現在のデータベースを指定します。
3. クエリをQ_売上保存作成_202609などの名前で保存します。
4. [実行]を押し、表示された確認メッセージの対象・件数を読んでから進めます。
5. ナビゲーションウィンドウで作成されたテーブルを開き、内容を確認します。

クエリの保存と実行は別の操作です。クエリを保存しただけでは、抽出条件などの定義が保存されるだけで、新しいテーブルはまだできません。また、実行による変更を通常の元に戻す操作だけで回復できると考えず、事前のコピーを保管してください。
月末の時刻を取りこぼさない
日付/時刻型に時刻が入っている場合、9月30日という表示でも内部では15時30分を持っていることがあります。「9月30日の午前0時以下」という条件では、その日の午後の売上が対象外になります。月初以上かつ翌月初日未満にすると、この境界を明確にできます。
例の条件では2026/09/30 15:30を含み、2026/10/01 00:00を含みません。表示書式を日付だけにしても、保存されている時刻は消えません。月末の売上が少なくなる問題では、画面上の見た目だけでなく内部値も確認します。

SELECT INTOで書くSQLと実行結果の確認
SQLビューではSELECT INTOで同じ目的を表現できます。次の例はT_売上のうち2026年9月分を抽出して、新しいT_売上保存_202609_検証へ保存するものです。テーブル名・フィールド名を実際の構成に合わせ、検証用コピーで実行してください。
SELECT [売上ID], [売上日], [顧客ID], [数量], [単価],
[数量] * [単価] AS [金額]
INTO [T_売上保存_202609_検証]
FROM [T_売上]
WHERE [売上日] >= DateSerial(2026,9,1)
AND [売上日] < DateSerial(2026,10,1);
INTOが新しい保存先、FROMが元データ、WHEREが抽出条件です。まず結果だけを見るならINTOの行を外したSELECTで確認します。実行のたびに新しい表を作るSQLなので、毎月同じテーブルへ追記する用途にそのまま使うものではありません。
主キーや入力規則を作成後に確認する
MicrosoftのSELECT INTOの説明では、元のフィールドからデータ型とフィールドサイズを引き継ぎますが、それ以外のフィールド・テーブルのプロパティは引き継がないとされています。主キー、インデックス、既定値、入力規則、リレーションなどは、必要に応じて作成後に設定します。
計算式で作った金額などは、意図した型・桁・Nullの扱いになっているかも確認します。型を毎回一定にしたい定期処理では、保存先を事前に設計してから追加クエリを使うほうが管理しやすい場合があります。型変換で丸めが生じる可能性も含め、実データに近い値で確認してください。

件数と合計を確認するSQL
次の確認はテーブルを変更しない選択クエリです。前述の架空データなら件数3、合計金額5,500が期待値です。件数だけが合っていても、別の行が混ざったり、計算式が違ったりすることがあるため、合計と代表レコードも照合します。
SELECT Count(*) AS [件数], Sum([金額]) AS [合計金額]
FROM [T_売上保存_202609_検証];
売上IDの重複は次のSQLで確認できます。結果に行が出なければ、このフィールドについて2件以上の重複候補はありません。ただし、別の業務キーで重複判定すべきデータでは、その項目の組み合わせを使います。
SELECT [売上ID], Count(*) AS [件数]
FROM [T_売上保存_202609_検証]
GROUP BY [売上ID]
HAVING Count(*) > 1;

作成できない原因と再実行の注意点
実行できないときは、表示されたメッセージを記録し、出力先名、利用中のオブジェクト、抽出条件、信頼設定の順に確認します。確認画面を消す設定で解決しようとすると、原因を見失ったり、意図しない置換に気づきにくくなったりします。
| 症状 | 確認する内容 | 対処の方向性 |
|---|---|---|
| 同名の表があると表示される | 出力先が既存表と重複していないか | まず別名にして検証する |
| テーブルが使用中と表示される | 開いているフォーム・レポート・他利用者 | 対象の利用を調整してから再実行 |
| 0件で作成される | 日付や文字の条件、パラメーター | 選択クエリに戻して確認 |
| 想定より件数が多い | 結合先に同じキーが複数ないか | JOINとキーの一意性を確認 |
| クエリが無効化される | ファイルの出所と信頼設定 | 管理方針に沿って信頼できるファイルのみ対応 |
| 容量や書込みで失敗する | DBサイズ、ディスク、保存先権限 | 不要な複製や保存先を確認 |
同じ名前で再実行するとき
テーブル作成クエリは追加処理ではありません。同名表がある場合、Accessの画面操作では既存表の削除・置換に関する確認が出ることがあり、実行経路によってはエラーになります。どちらの場合も、既存データがそのまま残る前提で進めないでください。
特にDAO等でSQLを実行する処理を、画面からのクエリ実行と同じ確認動作だと思い込まないことが重要です。自動処理では存在確認、失敗時の扱い、実行ログを設計します。初心者向けの手動手順では、確認メッセージを表示したまま、未使用名で試す方法が分かりやすくなります。

結合で行が増える場合
例えば売上1件に対して顧客マスターが2行一致すると、結合結果も2行になることがあります。この状態で表を作ると、合計が倍になる可能性があります。作成機能の不具合と決めつけず、元の選択クエリと結合キーを確認します。
重複を見つけたら、原因を理解する前にDISTINCTや削除クエリで隠さないでください。本来複数行あってよいデータなのか、マスター登録が重複したのかで対処が変わります。元データ・結合条件・期待する1行の意味を先に整理します。
テーブル作成や月次集計の誤更新を防ぐ設計を相談する
基本操作で解決できる範囲は、まずコピーで試し、出力結果を確認しましょう。同名テーブルの置換が業務に影響する、集計が重い、複数人で作業テーブルが競合する場合は、専門家への相談もご検討ください。
既存Accessの状況整理から、クエリ・フォーム・レポートの改修までご相談いただけますのでお気兼ねなく下記へご相談下さい。
業務で繰り返し使うときの設計と保守
毎月の処理では「都度作り直す表」「履歴として残す表」「他の人と共有する表」を分けて考えます。便利だからという理由で日付付きの表を無制限に増やすと、探しにくくなり、同じデータの二重管理にもつながります。
単発保存と定期蓄積を分ける
単発の調査なら、目的と削除予定が分かる名前で新しい表を作る方法が使えます。一方、売上を継続的に蓄積するなら、対象年月や取込IDを列として持つ設計済みテーブルへ追加し、重複取込を防ぐ仕組みを検討します。
後者では、主キーや一意インデックスを定義しておくと、同じデータを二度取り込む誤りを検出しやすくなります。ただし、一意とすべき組み合わせは業務次第です。請求書番号だけでは明細を区別できない場合、明細番号を含めたキーが必要になります。
複数人が同時に使う一時表
共有先に同じ名前の作業テーブルを作ると、別利用者の作業結果を置換したり、利用中のため処理が止まったりします。各利用者のフロントエンドへ作業表を置く、実行IDで領域を分けるなど、データの共有範囲を明確にします。
保存した表は元データのバックアップを完全に代替しません。フォーム・レポート・クエリ定義などを含めて復旧するには、データベース全体やバックエンドの適切なバックアップが必要です。保存目的、保持期間、削除担当を決めると保守しやすくなります。

作成後に引き継ぐ記録
- 出力テーブルと元クエリの名前、抽出条件、作成日時。
- 作成前後の件数・合計、エラーの有無。
- 作成後に設定した主キーやインデックス。
- 参照する帳票、保持期間、再作成してよい条件。
これらが分かれば、翌月の担当者は「先月と同じ操作をしたつもり」という状態から一歩進めます。処理が遅くなった場合も、行数増加、結合、索引、保存の重複のどこが原因かを調べる手がかりになります。
まとめ
テーブル作成クエリは、選択クエリの結果を新しい表へ固定する機能です。最初に抽出結果を確認し、未使用の名前で作成して、件数・合計・主キーなどの設計を点検すると進めやすくなります。定期処理では、追加クエリや実行履歴の管理も含めて保存方法を選びましょう。
よくある質問
通常のSELECT INTOは元テーブルを読み、新しい表へ結果を保存します。元データの削除処理ではありません。ただし、出力先に既存表を指定する場合は置換の影響を確認してください。
保存はクエリの定義を保存する操作です。テーブルを作成するにはアクションクエリとして実行する必要があります。先にデータシート表示で抽出結果を確認しましょう。
自動的に元の設計一式が引き継がれる前提にはできません。作成後のデザインビューで主キーやインデックスなどを確認し、必要な設定を行います。
更新されません。実行時点のコピーなので、元データの訂正後に再作成するか、別途同期する運用が必要です。
追加したい場合は追加クエリを使います。テーブル作成クエリを繰り返す方法とは、既存データや設計を維持する考え方が異なります。
できます。数量×単価などの計算列を選択クエリに含めて作成します。Null、丸め、出力先のデータ型は別途確認してください。
条件に一致するレコードがない可能性があります。日付の時刻、条件のAND・OR、パラメーターの入力値を、元の選択クエリで確認します。
既存表の置換や実行エラーになる可能性があります。表の用途と依存関係を確認し、蓄積したい場合は設計済みの表への追加を検討してください。
複数テーブルの結合で1件が複数行になっていないか確認します。重複を消す前に、期待する1行の単位と結合キーを整理してください。
アクションクエリの結果を通常の元に戻す操作だけで復旧できる前提にしないでください。事前コピーを残して検証します。
作成先に別のデータベースを指定する機能があります。最初は現在のDBで結果を検証し、その後に保存先パスや書込み権限を確認して切り替えます。
作業表の競合、毎月の手作業、二重取込、容量増加、主キーの再設定漏れが繰り返される場合です。処理の目的と保存設計をまとめて見直すと保守しやすくなります。
テーブル作成や月次集計の誤更新を防ぐ設計を相談する
基本操作で解決できる範囲は、まずコピーで試し、出力結果を確認しましょう。同名テーブルの置換が業務に影響する、集計が重い、複数人で作業テーブルが競合する場合は、専門家への相談もご検討ください。
既存Accessの状況整理から、クエリ・フォーム・レポートの改修までご相談いただけますのでお気兼ねなく下記へご相談下さい。
参考資料
Microsoft資料は仕様確認に使用しました。
[1] Microsoft テーブル作成クエリの操作
https://support.microsoft.com/en-us/access/create-a-make-table-query
[2] Microsoft SELECT INTOの構文と引き継ぎ制約
https://support.microsoft.com/en-us/access/select-into-statement
[3] Microsoft クエリの種類
https://support.microsoft.com/en-us/access/introduction-to-queries
[4] Microsoft アクションクエリの確認メッセージ
https://support.microsoft.com/en-us/access/turn-delete-object-and-action-query-confirmation-messages-on-or-off