Access

AccessのCSV・Excel取込でエラーが出るときの確認手順

Microsoft AccessでCSVやExcelファイルをインポートする際、突然のエラーメッセージやデータの抜け(Null化)が発生して業務が止まってしまうトラブルは少なくありません。この記事では、インポートエラーが発生する原因を徹底的に究明し、初心者でも実践できる確認手順から、VBAを活用したエラーを再発させないデータベース設計手法までをわかりやすく解説します。

公開日:2026年7月7日 更新日:2026年7月7日
AccessのCSV・Excel取込でエラーが出るときの確認手順
目次

この記事で分かること

  • AccessへのCSV・Excelインポート時にエラーが発生する主な原因と仕組み
  • 「~_ImportErrors」テーブルを用いた、迅速なトラブルシューティングの手順
  • Excelのデータ型自動判定(先頭8行ルール)を回避して安全に取り込む方法
  • 業務停止を防ぐために実務で推奨される「ワークテーブル(バッファ)」を用いた頑健なインポート設計

AccessのCSV・Excel取込エラーが発生する主な原因

Accessでデータのインポートを行う際にエラーが発生する原因は、リレーショナルデータベース(RDB)特有の厳格なデータ管理ルールにあります。Excelのように「どんなデータでも1つの列に混在させられる」柔軟なシートとは異なり、Accessのテーブルは「1つの列(フィールド)には特定のデータ型しか格納できない」という強い制約を持っています。そのため、取込元データと受け側のテーブル設定に少しでも不一致があると、インポート処理は失敗してしまいます。

取込エラーを引き起こす代表的な要因と、その発生メカニズムは以下の通りです。

発生原因 エラーメッセージ・発生する現象 発生する理由と具体的な状況
データ型の不一致(型変換エラー) 「型変換エラー(Type Conversion Error)」がインポートエラーテーブルに記録される、または特定のセルが空白(Null)になる。 数値型(整数・長整数など)のフィールドに対し、取込元データに「未定」や「-(ハイフン)」などの文字列が混入している場合。
主キー・インデックスの重複 「キー重複エラー(Key Violation)」が発生し、一部のレコードが追加されない。 テーブルの主キー(Primary Key)や「重複なし」に設定されたフィールドに対して、すでに存在する値や、重複した値をインポートしようとした。
必須入力制限の違反 「キー不足(Null Rule Violation)」などのエラーにより、レコードがスキップされる。 テーブル側で「値要求」が「はい」に設定されているフィールドに対し、取込元のCSVやExcelのデータが空(空白)のままになっている。
フィールドサイズの超過 「フィールド切り捨て(Field Truncation)」が発生し、文字の後ろが途切れるか、インポート自体が失敗する。 「短いテキスト型」の文字数制限(デフォルトは255文字、または個別に設定された文字数)を超える長さの文字列をインポートしようとした。
列構成・ヘッダー名の不一致 「実行時エラー ‘2391’: 貼り付け先のテーブル ‘テーブル名’ にフィールド ‘フィールド名’ が存在しません。」などのシステムエラー。 取込元のExcelやCSVの列名(ヘッダー)が変更された、または列の順番が変わり、Access側のテーブル定義と一致しなくなった。

このように、Accessのインポートエラーはデータの整合性を保つための「防衛反応」でもあります。エラーを解消するためには、単に警告を無視して進めるのではなく、どのデータがどの制約に違反しているのかを正しく特定することが重要です。

インポートエラー発生時の迅速な調査・確認手順

AccessでCSVやExcelのインポートを実行した際、エラーが発生すると画面上に警告ダイアログが表示され、ナビゲーションウィンドウに自動的に「(元のテーブル名)_ImportErrors」という名前の新しいテーブルが作成されます。このエラーテーブルは、トラブルの原因を特定するための「通信簿」とも言える非常に重要な情報源です。以下の手順に従って、効率的に原因調査を行いましょう。

手順1:インポートエラーテーブルを確認する

自動生成された「~_ImportErrors」テーブルをダブルクリックして開きます。ここには以下の3つの重要なカラム(列)が存在します。

  • エラー(Error):エラーの種類(例:「型変換エラー」「キー重複」「フィールド切り捨て」など)が記載されています。
  • フィールド(Field):エラーが発生したAccessテーブル側の列名です。これにより、どのデータ項目に問題があるかが一目でわかります。
  • 行(Row):取込元ファイルにおける、エラーが発生したレコードの「行番号」です。CSVやExcelをテキストエディタやスプレッドシートで直接確認する際、この行番号をターゲットに調査を進めます。

手順2:取込元ファイルをテキストエディタやExcelで直接検証する

エラーテーブルに記載された「行」と「フィールド」の情報を元に、実際のCSVやExcelファイルを精査します。

  • Excelの場合の注意点:Excel上では「表示形式」によってデータが見かけ上綺麗に整えられている場合があります。例えば、セルには「12,345」とカンマ付きで表示されていても、内部的には「12345」であったり、逆に文字列として認識されていることがあります。セルの値を選択し、数式バーで実際のデータがどうなっているかを確認してください。また、セルの四隅に緑色の三角マーク(エラーインジケーター)が表示され、数値がテキストとして保存されている場合もエラーの引き金になります。
  • CSVの場合の注意点:CSVファイルはExcelで直接開くと自動的に型変換(先頭の「0」が消えるなど)されてしまうため、調査時は「メモ帳」や「サクラエディタ」などのテキストエディタで開くのが鉄則です。不要なダブルクォーテーション(”)のネストや、データの途中に意図しない改行コード(LF)が混入していないか、カンマの数が合っているかを確認しましょう。

手順3:リンクテーブルの再更新を試みる

直接インポートするのではなく、外部ファイルを「リンクテーブル」として参照している場合にエラー(「~は有効なパスではありません」や接続エラー)が発生している場合は、リンク情報が古い可能性があります。Accessの「外部データ」タブから「テーブルリンクマネージャー」を起動し、対象ファイルのパスが正しいかを確認した上でリンクの更新を実行してください。

修正で済むか、作り直すべきか迷ったら

現状を確認し、修正・保守・刷新のどれが現実的かを整理します。

CSV・Excelファイル取込でのエラーを防ぐ安全な設定と実装手順

Accessのインポート処理を定常業務として安定して運用するためには、場当たり的なデータ修正ではなく、取り込み処理自体の設定を最適化する必要があります。ここでは、CSVとExcelのそれぞれについて、エラーを確実に回避するための具体的な設定手順を解説します。

1. CSV取込時には「インポート定義」を保存して活用する

CSVファイルをインポートする際、カンマ区切りや文字コード(UTF-8、Shift-JIS)、各列のデータ型を事前に固定しておく仕組みが「インポート定義(仕様)」です。これを使用することで、インポートごとに型推測が行われるのを防ぎ、エラーの発生を大幅に低減できます。

【設定手順】

  1. 「外部データ」タブ > 「新しいデータソース」 > 「ファイルから」 > 「テキストファイル」を選択します。
  2. ダイアログに従って進め、インポートウィザードが表示されたら、左下にある「詳細設定」ボタンをクリックします。
  3. 開いた「インポート定義」画面にて、各フィールドのデータ型、文字コード(コードページ)、区切り記号(カンマなど)が正しいかを確認・修正します。
  4. 右側の「名前を付けて保存」をクリックし、わかりやすい定義名(例:MyCSVImportDefinition)を登録します。
  5. 以降、手動で取り込む際はこの定義を呼び出すか、VBA(DoCmd.TransferText)の引数にこの定義名を指定することで、毎回同じ条件で安全にインポートが実行されます。

2. Excel取込時の「先頭8行のデータ型自動判定ルール(先頭8行問題)」を理解し、対策する

AccessがExcelファイルをインポートする際、パフォーマンス向上のために「最初の8行」だけをスキャンして各列のデータ型を自動判別します。これが原因で以下のような深刻なエラーが発生します。

  • 現象:先頭8行がすべて「数値」で構成されている列があり、9行目以降に「A123」のようなアルファベット混じりの文字列が含まれている場合。Accessはその列を「数値型」と判定するため、9行目以降の文字列データを取り込めず、そのセルを強制的に「Null(空欄)」にするか、レコードごとエラーとして弾いてしまいます。

【対策方法】

  • Excelの先頭行にダミー行を挿入する:Excelデータの1行目(ヘッダー直下)に、すべての列がテキスト形式となるダミーデータ(例: 「dummy」という文字列や長文)を挿入しておきます。Accessに「この列はテキスト型である」と強制的に認識させた上でインポートを実行し、インポート後に不要なダミーレコードをクエリで削除します。
  • レジストリの「TypeGuessRows」を変更する:Windowsのレジストリ(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\...\Access Connectivity Engine\Engines\Excel)の「TypeGuessRows」の値を「8」から「0」に変更することで、全行をスキャンしてから型を決定するように変更可能です。ただし、PCごとの設定変更が必要になるため、複数ユーザーが使う社内システムでは上記「ダミー行の挿入」や後述する「ワークテーブルの活用」が現実的です。

3. VBAを活用した堅牢なインポートプログラムの実装例

手動でのインポートウィザード操作はヒューマンエラーの温床となります。VBAを使ってエラーハンドリングを施したインポート処理を構築することで、システムとしての安定性が格段に向上します。

' VBAを用いた安全なExcelインポートのサンプルコード
Sub ImportExcelSheet_Safe()
    On Error GoTo Err_Handler
    
    Dim openFilePath As String
    Dim targetTable As String
    
    ' 取り込み対象ファイルと格納先テーブルの定義
    openFilePath = "C:\Database\ImportData.xlsx"
    targetTable = "t_ReceivedData"
    
    ' 画面描画と警告メッセージを一時的に非表示にする(処理の高速化とユーザーの混乱防止)
    DoCmd.Hourglass True
    DoCmd.SetWarnings False
    
    ' Excelファイルのインポート実行
    ' acSpreadsheetTypeExcel12Xmlは「.xlsx」形式を指定、Trueは1行目をヘッダーとして扱う設定
    DoCmd.TransferSpreadsheet acImport, acSpreadsheetTypeExcel12Xml, _
                              targetTable, openFilePath, True
    
    ' 正常終了メッセージ
    DoCmd.SetWarnings True
    DoCmd.Hourglass False
    MsgBox "データの取り込みが正常に完了しました。", vbInformation, "処理成功"
    Exit Sub

Err_Handler:
    ' エラーが発生した場合の処理
    DoCmd.SetWarnings True
    DoCmd.Hourglass False
    MsgBox "【インポートエラー】処理中に不具合が発生しました。" & vbCrLf & _
           "エラー番号: " & Err.Number & vbCrLf & _
           "エラー内容: " & Err.Description, vbCritical, "システムエラー"
End Sub

再発を防ぐためのワークテーブルを活用した頑健な取込設計

実務でAccessデータベースを長く運用していると、外部から提供されるCSVやExcelのレイアウト、表記の揺れを完全に制御することは不可能です。「CSVに文字化けがあった」「日付欄に『未定』と書かれていた」といった理由でシステムが停止してしまうのを防ぐため、開発のプロが実践しているのが「ワークテーブル(バッファテーブル)を経由した2ステップインポート方式」です。

この設計を導入することで、どれだけデータの「表記の揺れ」や「型の崩れ」があっても、インポート処理そのものが途中で異常終了しシステムがハングアップする事態を完全に回避できます。

ワークテーブル経由インポートの全体イメージ

直接本番用のマスターテーブルや実績テーブルに流し込むのではなく、クッションの役割を果たす一時テーブル(ワークテーブル)を挟んでから、本番テーブルへデータを追加・更新します。

【具体的な実装手順】

  1. ワークテーブル(w_ImportBuffer)の作成
    すべての列のデータ型を「短いテキスト型(または長いテキスト型)」、フィールドサイズを「255文字以上」に設定した専用テーブルを作成します。このテーブルには主キー(PK)や必須入力、値の制限などを一切設定せず、「どんな崩れたデータでも、エラーを出さずに100%受け止める」箱として設計します。
  2. ワークテーブルへの一括取込
    CSVやExcelを、まずこの w_ImportBuffer に取り込みます。すべてがテキスト型として定義されているため、データ型の不一致(型変換エラー)やヌル値(Null)違反、文字数切り捨てといったインポートエラーはここで完璧に防ぐことができます。
  3. データクレンジングと不整合データの抽出(クエリ/VBA)
    ワークテーブル内のデータを対象に、不整合がないかをSQLクエリやVBAでチェックします。

  4. 例:IsNumeric([数量]) = False のデータを抽出し、エラーログに書き出しつつ除外する。
  5. 例:IsDate([売上日]) = True のレコードのみを対象とし、不正な日付形式を事前に弾く。
  6. 例:Trim([顧客コード]) で、データの前後に入り込んだ不要なスペースを自動で削除・整形する。
  7. 本番テーブルへの流し込み(追加クエリ)
    クレンジング処理をクリアした正常データのみを、本番テーブル(t_SalesResultsなど)へ「追加(インサート)クエリ」または「更新(アップデート)クエリ」を用いて流し込みます。チェックに引っかかったエラーレコードのみを画面にリスト表示し、ユーザーに修正を促す画面を挟むと親切です。
  8. ワークテーブルのクリア
    一連の処理が完了したら、DoCmd.RunSQL "DELETE * FROM w_ImportBuffer" を実行し、次回取り込みに備えてバッファ内のデータを完全に空にしておきます。

この2ステップインポート方式を構築しておけば、「誰かが作ったExcelの書き方が悪かったために、基幹システムへの取り込み時にエラー画面が出て社内業務が数時間止まってしまった」というような、ビジネス上のクリティカルな損失を未然に防ぐことができます。

修正で済むか、作り直すべきか迷ったら

現状を確認し、修正・保守・刷新のどれが現実的かを整理します。

まとめ:強固な取込処理で業務停止を防ぐ

AccessでのCSV・Excel取り込みにおけるエラーは、Access側がデータの整合性とデータベースの品質を保とうとするために起こる仕様上の制約です。しかし、運用のたびにデータの手修正を行ったり、エラーダイアログに悩まされるのは業務効率を著しく低下させます。

インポートエラーテーブル(ImportErrors)を読み解く手順をマスターした後は、ぜひシステムとして安定した取り込み仕様の構築に踏み出してください。特に「ワークテーブル(バッファ)」を経由する設計は、長期的に不具合を起こさないデータベース運用のためのベストプラクティスです。もし「マクロが複雑になりすぎて自分では改修できない」「取込エラーがどうしても解消できず、毎日業務が止まって困っている」という場合は、プロのAccess開発エンジニアに現状のデータベース構成を診断してもらい、改修を依頼するのも一つの有効な手段です。

よくある質問(Q&A)

CSVをインポートすると「型変換エラー」が出ます。元のファイルを見ても、どこがおかしいのかわかりません。

インポート後に自動生成される「~_ImportErrors」というテーブルを確認してください。そこにエラーが発生した「行番号」と「フィールド名(列名)」が記録されています。その行番号を目安に、メモ帳などのテキストエディタでCSVを開き、データに不要な文字(空白、カンマ、文字化け、スペースなど)が混じっていないか直接確認してください。また、列内のデータが完全に空(Null)のセルがないかもチェックしてください。

Excelファイルをリンクテーブルにしたとき、急に「データベース エンジンが~を開くことができませんでした」というエラーが出ます。

このエラーは主に、取込元のExcelファイルが別のユーザーによって開かれてロックされている場合、またはファイルサーバーのネットワークが切断されている場合、ファイルパスやシート名が変更された場合に発生します。誰もファイルを開いていないか確認のうえ、「外部データ」タブにある「テーブルリンクマネージャー」から、現在の正しいファイルパスにリンクを更新・再接続してください。

CSVやExcelの列の並び順が毎回微妙に変わるのですが、エラーなく取り込む方法はありますか?

Accessテーブルへの「直接インポート」ではなく、ExcelやCSVを一度「リンクテーブル」としてAccessに接続するか、すべてテキスト型で受け止める「ワークテーブル」に一括格納します。その後、フィールド名(列名)を基準に「追加クエリ」を使って本番テーブルにマッピングして流し込む処理を作れば、元ファイルの列順が変わっても影響を受けずに安定して取り込むことができます。

レジストリを変更せずにExcelの「先頭8行の自動判定(先頭8行問題)」を回避するにはどうすればいいですか?

最も簡単な回避策は、本番用のマスターデータの最上部に「すべてのセルにテキストが入力されたダミーの行」を1行作成しておくことです。これにより、Accessは強制的にその列をテキスト型と誤判定・解釈するため、9行目以降に長いテキストやアルファベットが含まれていてもNullにならずに取り込めます。インポート後にダミーレコードを削除するクエリを実行するようにシステムを組むだけで、レジストリを触らず安全に対策が可能です。

インポートエラーテーブル(_ImportErrors)がナビゲーションウィンドウに溜まってしまうのですが、消しても大丈夫ですか?

はい、これらはインポート時に一時的に作成されるエラーログ用テーブルですので、原因の特定が終わった後であればすべて削除(デリート)してしまって全く問題ありません。削除してもAccess内の実データや本来のテーブル、クエリに影響を与えることはありません。VBAでシステム化する際は、インポート処理の直前にこれらのエラーテーブルを自動で削除するコード(DoCmd.DeleteObjectなど)を記述して、システム内を綺麗に保つ工夫を施すのが一般的です。

Accessについてのご相談

Accessについてのご相談を受け付けています

現状の課題をお聞きし、最適な進め方をご提案します。まずはお気軽にご相談ください。