概要
| この記事の結論 Accessのインポート時のキー違反は、主キーや重複禁止インデックスに同じ値を追加しようとしたときなどに起こります。まず取込先と取込元の重複を確認し、新規追加か既存更新かを切り分けます。バックアップを取り、IDを引き継ぐ必要性や一部取込の有無も確かめてから、修正・再取り込みを行いましょう。 「主キーを外す」「IDを振り直す」という操作を先に行うと、二重登録や関連データの不整合につながります。本記事では、制約を確認しながら原因行を見つける手順と、定期取込で同じ問題を繰り返さないための運用を紹介します。 |
この記事でわかること
- キー違反が発生する原因と、主キー以外に確認する設定
- オートナンバーで新規採番してよい場合と、既存IDを保持する場合
- 取込元の重複と、取込先にすでに存在するデータの見つけ方
- 新規追加と既存更新を分け、安全に再取り込みする手順
- 定期取込の二重登録を防ぐ工夫と、専門会社へ相談する目安
この記事の主な内容
- キー違反エラーの原因を知る
- 修正前にバックアップと取込結果を確認する
- 主キー・インデックス・元データを調べる
- オートナンバー型の主キーで対処する
- 通常の主キー・複合キーで対処する
- 安全に再取り込みし、再発を防ぐ
- よくある質問
- まとめと相談のご案内
想定読了時間:約14分~約17分
1. キー違反エラーの原因を知る
キー違反とは、取り込むデータが主キーや一意インデックスなどの制約を満たさず、登録できない状態です。よくある原因は値の重複ですが、主キーの列だけを見て問題がないと判断しないことが大切です。
主キーと重複禁止インデックスの役割
主キーは、テーブル内の1件のレコードを特定するための項目です。売上IDや社員IDなどが使われ、同じ値を複数のレコードに登録することはできません。また、主キーにはNull、つまり値がない状態も認められません。
一方、一意インデックスは、指定した項目や項目の組合せについて重複を防ぐ設定です。主キーとは別に設定できます。Microsoftの取込トラブル解説でも、主キーに加えて[インデックス]が[はい(重複なし)]の項目を確認するよう案内されています。
例えば、売上IDを主キーとし、伝票番号にも重複禁止の設定があるテーブルを考えてみましょう。売上IDが新しい番号でも、伝票番号が既存データと同じなら、そのまま追加することはできません。
重複には確認する場所が2つある
重複は「取込先にすでにある値」と「今回取り込むファイルの中」の両方で確認します。取込先に同じ値がなくても、Excel内に同じ伝票番号が2行あれば、取込処理の途中で制約に抵触する可能性があります。
| 確認対象 | 例 | 確認の考え方 |
|---|---|---|
| 取込先との重複 | 登録済みの伝票番号A001を再追加 | 既存データとの一致を調べる |
| 取込元内の重複 | Excelに伝票番号A002が2行ある | 同じキーの出現回数を調べる |
| 別の一意インデックス | 売上IDは別でも伝票番号が同じ | 主キー以外の重複禁止設定を調べる |
複合主キーは組合せで確認する
複数の項目をまとめて主キーにする構成を、複合主キーと呼びます。例えば「伝票番号+明細番号」が主キーなら、伝票番号だけが同じでも、明細番号が異なれば別の組合せです。片方の列だけで重複を判定すると、必要な明細を削除するおそれがあります。

2. 修正前にバックアップと取込結果を確認する
最初に行うのは、データの削除ではなく現状の保存です。エラーが出ても一部の行は取り込まれている場合があるため、同じファイルをそのまま再実行する前に、何が登録されたかを確認します。
DBと取込ファイルを保存する
共有利用中なら利用者と作業時間を調整し、更新が止まった状態でバックアップを取得します。テーブルを別ファイルに分けている構成では、画面側のファイルだけでなく、実データを保存するバックエンドも対象です。
取込元のExcel・CSVは原本として保管し、修正用のコピーを作成してください。ファイル名、実行日時、取込先テーブル名、実行前の件数、表示されたメッセージを記録すると、再取り込み後の照合に役立ちます。
追加クエリは通常の[元に戻す]で取り消せる操作ではありません。Microsoftも、実行前のプレビューとバックアップを案内しています。
追加・新規テーブル・更新を分けて考える
既存テーブルへの追加は、新しい行を増やす操作です。同じキーの行が存在しても、自動でその行を上書きするわけではありません。既存データの金額や日付を変更したい場合は、更新処理として設計します。
| 目的 | 選ぶ処理 | 既存データの扱い |
|---|---|---|
| 新しい売上を登録する | 既存テーブルへの追加 | 新規行を増やす |
| 取込内容を別の場所で調べる | 取込用テーブルへ取り込む | 本番テーブルを直接変更しない |
| 登録済み売上の金額を直す | 更新クエリなど | 一致する行の指定項目を変更する |
エラー情報と登録済みの行を確認する
インポートの完了画面にエラーログのテーブル名が表示された場合は、そのテーブルを開き、エラー内容・フィールド・行の情報を調べます。ただし、処理方法によって表示やログの有無は異なります。ログだけに頼らず、取込先の実データも照合してください。
ログの行番号は、ヘッダー行や指定範囲などとの対応を確認して使います。元ファイルを並べ替えてから行番号を見ても、同じデータを指すとは限りません。伝票番号などの識別項目と照らし合わせて対象を特定します。

3. 主キー・インデックス・元データを調べる
原因を絞るには、取込先の設計を確認し、その条件で元データを比較します。ここでは1伝票を1行で保存する売上テーブルを例にします。複数明細を持つ場合は、後述の複合キーの例と区別してください。
デザインビューとインデックス画面を確認する
ナビゲーションウィンドウで取込先テーブルを右クリックし、[デザインビュー]を開きます。鍵マークの付いた項目が主キーです。データ型と、画面下部のフィールドプロパティも確認しましょう。
続いて、テーブルのデザイン用タブから[インデックス]を開きます。名称はAccessのバージョンなどで異なる場合があります。主キー以外のインデックスと[固有]の設定、複数フィールドにまたがるインデックスの構成を確認してください。
次の例では、売上IDだけでなく伝票番号にも制約があります。エラーを消すために設定を変更するのではなく、まず何を重複させない設計なのかを把握します。
| T_売上の項目 | データ型の例 | 役割・条件 |
|---|---|---|
| 売上ID | オートナンバー型 | 主キー。新規追加時に採番 |
| 伝票番号 | 短いテキスト型 | 重複なし。値の入力も必須とする |
| 売上日 | 日付/時刻型 | 売上の発生日 |
| 金額 | 通貨型 | 伝票単位の売上金額 |

取込用テーブルで重複と既存一致を抽出する
行数が多い場合は、元ファイルを「W_売上取込」などの確認用テーブルへ取り込みます。このテーブルでは、調査対象の伝票番号に重複禁止設定を付けず、重複している行も残して調べます。本番の制約を外す操作とは異なります。
元行番号、取込売上ID、伝票番号、売上日、金額を持たせると比較しやすくなります。元行番号は元ファイルで行ごとに付けた追跡用の番号です。取込用テーブルのオートナンバーが、そのままExcelの行番号になるとは考えないでください。
伝票番号は文字として扱い、先頭の0が欠落していないかを確認します。数値化されて消えた0は、表示形式だけを変更しても元の値を判断できない場合があります。取込元の仕様に照らして修正しましょう。
画面操作なら、[作成]の[クエリウィザード]から重複クエリのウィザードを選び、W_売上取込の伝票番号を対象にします。確認用に元行番号や金額も表示すれば、同じ番号の行を比較できます。
SQLで調べる場合は、次の選択クエリを使います。[作成]からクエリを作成し、[SQLビュー]に記述します。以下は作例のテーブル名・項目名を使った確認用SQLであり、元のデータを変更しません。
SELECT [伝票番号], Count(*) AS [件数]
FROM [W_売上取込]
GROUP BY [伝票番号]
HAVING Count(*) > 1;
この結果は、同じ伝票番号が何件あるかを示します。金額や日付が同じかどうかまでは判定しません。重複が出たら該当行を開き、同じ伝票の重ね取り込みなのか、明細を1行ずつ出力したファイルなのかを確認します。
次に、取込先にすでにある伝票番号を探します。次のクエリは取込元と登録済みデータの両方にある行を表示します。
SELECT W.[元行番号], W.[伝票番号],
W.[金額] AS [取込金額],
T.[売上ID], T.[金額] AS [登録金額]
FROM [W_売上取込] AS W
INNER JOIN [T_売上] AS T
ON W.[伝票番号] = T.[伝票番号];
一致した行は、直ちに削除せず内容を比較します。同じ内容なら取込済みの可能性があり、金額が違うなら訂正データかもしれません。どちらを正とするかは業務ルールで判断します。

Null・型変換・参照整合性を切り分ける
重複が見つからないときは、エラー文言を改めて確認します。必須項目の空欄、データ型の不一致、入力規則、ロックなどは、キーの重複とは別に確認する問題です。追加クエリのエラーは複数の理由で起きるため、すべてを同じ対処法で直すことはできません。
また、親テーブルに存在しない顧客IDを子テーブルへ登録しようとすると、参照整合性に反することがあります。参照整合性は、存在しない相手を参照するデータが生まれないようにする仕組みです。親データの登録状況を確認し、必要な順序で取り込みます。
4. オートナンバー型の主キーで対処する
新しいレコードとして登録し、元のIDを引き継ぐ必要がない場合は、オートナンバーの項目を追加対象から外してAccessに採番させます。ただし、別の重複禁止項目がある場合、その値の重複は別途解消する必要があります。
新規レコードは追加対象からIDを除外する
前述の売上例なら、伝票番号・売上日・金額だけを追加し、売上IDは渡しません。取込元にIDがある場合でも、確認用テーブルには「取込売上ID」として残し、本番への追加対象から除外できます。
この方法なら原本のID列を削除せずに調査情報を残せます。[クエリデザイン]で必要項目を選び、選択結果を確認してから[追加]へ切り替え、追加先のT_売上を指定します。[レコードの追加]行の対応を確認し、売上IDを追加対象に含めないようにします。
直接Excelから取り込む場合も、取込用コピーで対象列を整理できます。ただし、列名や必須項目などの条件は取込先に合わせてください。列を削除する方法に不安がある場合は、確認用テーブルを経由して項目を指定する方が、処理内容を追いやすくなります。
空欄のID列を渡す方法とは異なる
ID列を対象から除外することと、空欄のID列を取り込むことは同じではありません。インポートでは、オートナンバー項目へNullを渡したことがエラーになる場合もあります。新規採番させたいときは、追加対象の指定を確認することが重要です。
また、オートナンバーに欠番があっても、それだけでデータが不足しているとは判断できません。件数の照合にはレコード数や業務キーを使い、番号が連続しているかどうかだけで成功・失敗を判断しないようにします。
既存IDや親子関係を保持する場合は先に設計を確認する
他のテーブルがそのIDを参照しているなら、単純な振り直しは避けます。例えば売上IDを明細テーブルが参照しているとき、売上側だけ新しいIDにすると、元の明細との対応が変わってしまいます。
IDを保持して移行するか、新しく採番して旧IDと新IDの対応表を作るかを決めてから作業します。後者では明細側の参照先も対応表に沿って変換します。取引先のシステムと共通の番号として使う場合も、関連する処理への影響確認が必要です。

5. 通常の主キー・複合キーで対処する
主キーが短いテキスト型や数値型の場合は、その設計に従った値を用意します。重複しない番号なら何でもよいわけではありません。顧客コードや伝票番号は、実際の取引や他システムとの対応を表す場合があるためです。
誤入力と本当の重複を分けて修正する
誤入力なら正しい原票と照合して修正します。同じ伝票を二重に出力していた場合は、どの行を残すかを決めて重複を解消します。金額や日付が違う複数行を、キーが同じという理由だけで1行へまとめてはいけません。
例えば1伝票に複数の商品明細があるなら、伝票番号の重複はファイルの構造として正常です。取込先が1伝票1行なのか、1明細1行なのかを確認し、伝票単位で集計して取り込むか、明細テーブルへ取り込むかを選びます。
複合キーでは明細単位の組合せを比較する
伝票番号と明細番号を組み合わせる場合、次のように判断します。元ファイルのどちらの項目も欠けていないことを確認してください。
| 伝票番号 | 明細番号 | 判断 |
|---|---|---|
| A001 | 1 | この組合せを1件として識別 |
| A001 | 2 | 上の行とは別の組合せ |
| A001 | 1 | 1行目と同じ組合せなので重複 |
この構成なら、重複確認も両方の項目で行います。SQLではGROUP BYに伝票番号と明細番号を指定し、既存一致の確認では両項目を結合条件に含めます。別々の列にある値をただ連結するより、項目ごとに比較する方が境界の取り違えを避けられます。

既存レコードを直すなら更新を検討する
登録済みの売上を訂正したい場合は、更新クエリなどで対象項目を変更します。追加クエリと更新クエリは役割が異なります。既存行へ追加しようとしてエラーが出ているなら、IDの変更より先に処理目的を確認してください。
まず、取込側のキーが一意であることを確認し、対象の伝票を選択クエリで表示します。登録済みの金額と取込金額を並べ、変更対象が想定どおりかを見てから更新します。1件の既存行に複数の訂正候補が一致する状態では実行しません。
また、空欄を「変更しない」と扱うか「値を消す」と扱うかも決めておきます。更新対象の項目を必要最小限に絞り、キー自体や、今回のファイルに含まれない項目を誤って変えないようにしてください。

データの取り込みで業務が止まっている方へ
複数テーブルのIDを保持する必要がある場合や、どのデータが正しいか判断できない場合は、取込処理とテーブル設計を一緒に調べることが近道です。既存Accessの保守・改修についてお気軽にご相談いただけます。
6. 安全に再取り込みし、再発を防ぐ
再取り込みでは、原因を直したことに加え、対象行を正しく選べていることも確認します。エラーが消えたという結果だけでは、二重登録や取りこぼしがないとは言い切れません。
取込用テーブルで検査してから反映する
定期的な処理では、本番テーブルへ直接入れる前に、取込用テーブルで検査する流れが役立ちます。検査で問題が出た行は保留し、新規・更新・取込済みを分けてから本番へ反映します。
1. 取込元を保存し、今回の取込回を識別できるようにする。
2. 取込用テーブルへ読み込み、元ファイルとの件数・項目を確認する。
3. キーの空欄、元データ内の重複、データ型、親データの存在を検査する。
4. 既存データと比較し、追加・更新・取込済み・保留に分ける。
5. 対象をプレビューし、検証用コピーで結果を確認する。
6. 本番へ反映し、件数と内容を照合して取込履歴を残す。
新規候補だけを探す確認用SQLは次のとおりです。T_売上の売上IDが主キーであるため、結合結果で売上IDがNullなら、伝票番号に一致する既存行がないと分かります。
SELECT W.[元行番号], W.[伝票番号],
W.[売上日], W.[金額]
FROM [W_売上取込] AS W
LEFT JOIN [T_売上] AS T
ON W.[伝票番号] = T.[伝票番号]
WHERE T.[売上ID] Is Null;
このクエリだけでは、取込元内の重複や伝票番号の空欄を排除できません。必ず事前検査を済ませ、追加してよい行だけを選んでください。複合キーの場合は、全構成項目を結合条件に含める必要があります。
新規候補を確認したら、前章の手順で追加クエリへ切り替え、伝票番号・売上日・金額を追加します。確認から実行までの間に他の利用者が同じ伝票を登録すれば、再び重複する可能性があります。定期取込の時間帯や担当者を決め、本番側の重複禁止設定も維持します。

件数だけでなく対象行と金額も照合する
例えば既存100件のテーブルに、新規3件を追加したなら、追加後は103件です。これは同時に他の追加や削除がない場合の例です。既存2件の金額を更新するだけなら、行数は増えません。
今回の対象が「新規3件・更新2件・取込済み4件・保留1件」なら、合計10件がどの状態になったかを追えるようにします。分類は重複しないルールにし、保留行は理由を添えて残してください。
| 確認項目 | 確認する内容 |
|---|---|
| 件数 | 新規追加分だけ増えているか |
| 業務キー | 今回の対象伝票が存在し、余分な行がないか |
| 更新内容 | 指定した行・項目だけが変わっているか |
| 金額・日付 | 元データとの比較で欠落や変換ミスがないか |
| 保留・失敗行 | 対象と理由が残り、未処理分を説明できるか |
オートナンバーで毎回新しいIDが付いても、同じ売上が二度登録されれば業務上は重複です。IDとは別に、何をもって同一の取引と見なすかを決めることが再発防止につながります。

取込履歴と再実行のルールを整える
取込日時、担当者、ファイル、対象期間、追加件数、更新件数、保留件数を記録します。同じファイル名でも内容が差し替わることがあるため、原本や取込回も保存して追跡できるようにしましょう。
失敗時に全件を再実行するのか、未処理分だけを実行するのかも決めます。複数の追加・更新をひとまとめに扱う仕組みが必要なら、トランザクションやエラー処理を含む実装を検討します。画面操作で行った複数の処理が、自動で一括取消になるとは限りません。
7. よくある質問
主キー以外の重複禁止インデックス、取込元内の重複、複合キーの組合せを確認してください。見た目だけでは分かりにくい場合は、取込用テーブルのクエリで比較します。エラー文言が別の制約を示していないかも確認しましょう。
原因と影響を確認せずに削除することは避けてください。二重登録を許したり、関連テーブルとの関係を変えたりするおそれがあります。制約が業務に合わない場合は、テーブル設計と取込データの単位をまとめて見直します。
必ず解決するとは限りません。空欄を渡すことと、追加対象からID列を除外することは異なります。新規採番させる場合は追加対象の指定を確認し、既存IDを引き継ぐ必要がある場合は先に関連データとの関係を調べます。
既存データの更新は可能ですが、通常の追加取込で自動上書きされるわけではありません。取込用テーブルで既存行と照合し、正しいキーで一致する行の必要項目だけを更新する処理を用意します。
先に、すでに取り込まれた行があるかを確認してください。一部が登録済みなら、再実行で同じ行を追加しようとしてエラーや二重登録が起きる可能性があります。原本を保存し、未処理行を特定してから再実行します。
8. まとめと相談のご案内
キー違反の対処では、取込先の主キー・一意インデックスと、取込元の内容を両方確認します。新規追加なのか既存データの訂正なのかを決めると、IDを新規採番するか、保持するか、更新処理にするかを判断しやすくなります。
バックアップを取り、確認用テーブルで原因行を特定し、必要な修正をしてから反映しましょう。最後に件数・業務キー・更新内容を照合することで、エラー解消だけでなく、取り込み結果の確認まで進められます。
既存Accessの取込エラーや定期取込の改修をご相談ください
「毎月同じエラーが出る」「元の設計が分からない」「関連テーブルが多くIDを変更できない」といった場合は、データと処理の関係を整理することが必要です。既存Accessの保守・改修や、取込処理の見直しについてご相談いただけます。
ご相談の際は、表示されたエラー、取込元の形式、取込先テーブル、実行した操作をお知らせください。個人情報や取引情報を含む実データは、共有方法を確認してからご提供ください。
参考情報
[1]Microsoft Support Import or link to data in an Excel workbook
https://support.microsoft.com/en-us/access/import-or-link-to-data-in-an-excel-workbook
参照箇所:重複禁止項目、取込エラー、一部取込、エラーログ、オートナンバー項目のNull。
[2]Microsoft Support Add records to a table by using an append query
https://support.microsoft.com/en-us/access/add-records-to-a-table-by-using-an-append-query
参照箇所:追加と更新の違い、プレビュー、追加先の項目指定、実行後の取消制限。
[3]Microsoft Support Common errors when you run an append query
https://support.microsoft.com/en-us/access/common-errors-when-you-run-an-append-query
参照箇所:キー違反、型変換、ロック、入力規則の区別。
[4]Microsoft Support Guide to table relationships
https://support.microsoft.com/en-us/access/guide-to-table-relationships
参照箇所:主キーと外部キーの対応、参照整合性。