概要
| この記事の結論 Accessで「抽出条件でデータ型が一致しません」と表示される主な原因は、クエリが比較している値どうしのデータ型がそろっていないことです。まずは対象フィールドの実データ型を確認し、テキストは文字列、数値は数値、日付は#で囲んだ日付、Yes/NoはTrue/Falseとして条件を書き分けます。それでも直らない場合は、ルックアップの保存値、パラメーターの型定義、結合フィールド、計算式、リンクテーブルや外部データを順番に確認すると原因を絞り込みやすくなります。 |
この記事でわかること
- 「抽出条件でデータ型が一致しません」とは何か、まずどこを確認すべきか
- テキスト・数値・日付・Yes/No・通貨における正しい抽出条件の書き方
- 条件が正しいように見えてもエラーが出る、ルックアップとパラメーターの落とし穴
- 結合・計算フィールド・リンクテーブル・Excel/CSV連携で起きる型不一致
- 原因を特定する5STEPの切り分け手順と、再発を防ぐ設計・運用のコツ
この記事の主な内容
1.「抽出条件でデータ型が一致しません」とは？まず原因を30秒で確認
2.データ型別の正しい抽出条件｜テキスト・数値・日付・Yes/No・通貨
3.条件が正しいのに直らない原因①｜ルックアップとパラメーターを確認
4.条件が正しいのに直らない原因②｜結合・計算フィールド・リンクテーブルを確認
5.原因を特定する5STEP｜デザインビューから順番に切り分ける
6.再発を防ぐ設計と運用｜データ型を揃え、パラメーターを明示する
7.まとめ
8.よくある質問（FAQ）
想定読了時間：約10分～15分
1. 「抽出条件でデータ型が一致しません」とは？まず原因を30秒で確認
このエラーは、Accessが抽出条件や結合条件を評価するときに、「同じものとして比較できない型どうしを比べようとしている」と判断したときに発生します。典型例は、数値フィールドに文字列を当てている、日付型に文字列のまま条件を書いている、Yes/No型を文字列として扱っている、といったケースです。
まずは、エラーが出ているクエリで「どのフィールドに、どんな条件を書いているか」を確認してください。そのうえで、対象フィールドの実データ型と、条件に書いた値の型が一致しているかを見るのが最短ルートです。
よくある発生パターン
- 数値型のフィールドに「”100″」のように文字列で条件を書いている
- 日付/時刻型のフィールドに「2026/09/05」と書き、#で囲っていない
- Yes/No型のフィールドに「はい」「いいえ」など、Accessが真偽値として解釈しない文字列を書いている
- ルックアップフィールドの表示値ではなく、実際の保存値を参照すべき場面で取り違えている
- パラメータークエリでパラメーターの型が未定義のままになっている
- 結合フィールドどうしの型が異なる、またはFormat関数などで文字列化されている
2. データ型別の正しい抽出条件｜テキスト・数値・日付・Yes/No・通貨
最も基本的な対処は、「フィールド型ごとに正しい条件の書き方へ直す」ことです。ここでつまずきやすいのは、見た目の表示形式ではなく、テーブルに保存されている実データ型に合わせて条件を書く必要がある点です。
| フィールド型 | 正しい条件例 | NG例 | ポイント |
| テキスト | =”東京” / Like “*東京*” | =東京 / >100 | 文字列はダブルクォーテーションで囲う |
| 数値 | =100 / >1000 | =”100″ | 数値は文字列化しない |
| 日付/時刻 | =#2026/09/05# / Between #2026/09/01# And #2026/09/30# | =”2026/09/05″ / 2026/09/05 | 日付は#で囲う |
| Yes/No | =True / =False | =”True” / =”はい” | 真偽値は文字列にしない |
| 通貨 | >5000 / Between 1000 And 5000 | =”¥5,000″ | 表示形式ではなく実数値として比較する |
テキスト型の条件
テキスト型は、文字列として比較できる形で条件を書く必要があります。完全一致なら「=”東京”」、部分一致なら「Like “*東京*”」のように指定します。引用符なしの「=東京」は、Accessがフィールド名や式として解釈しようとして想定外の動作になることがあります。
数値型と通貨型の条件
数値型や通貨型では、条件も数値として評価できる書き方にします。たとえば「>1000」「Between 1000 And 5000」のように記述し、ダブルクォーテーションで囲みません。表示上「¥1,000」と見えていても、実際には数値として保存されているため、条件に通貨記号やカンマ付きの文字列を書くのは避けます。
日付/時刻型の条件
日付/時刻型は、Accessの日付リテラルとして評価できるよう#で囲むのが基本です。たとえば「=#2026/09/05#」「Between #2026/09/01# And #2026/09/30#」のように書きます。日付に見える値でも、取り込んだ元データがテキスト型なら同じ書き方では比較できないため、元フィールドの型確認も重要です。
Yes/No型の条件
Yes/No型はTrue/Falseで扱うのがわかりやすい方法です。クエリ条件には「=True」「=False」と書き、文字列の「”True”」や「”はい”」のような指定は避けます。フォーム上のチェックボックス表示だけを見て判断せず、テーブル定義でYes/No型になっているかを確認しましょう。
3. 条件が正しいのに直らない原因①｜ルックアップとパラメーターを確認
条件の見た目に問題がないのにエラーが消えない場合は、フィールドの裏側の型を疑います。特に初心者が混乱しやすいのが、ルックアップフィールドとパラメータークエリです。
ルックアップフィールドは「表示値」と「保存値」を分けて考える
ルックアップフィールドでは、画面上には得意先名などの文字列が見えていても、テーブルには得意先IDのような数値が保存されていることがあります。この状態で表示値の文字列を基準に条件を書いていると、保存値の数値型と合わずにエラーや想定外の結果につながります。
まずは、対象フィールドがどの列にバインドされているか、実際の保存値は何かを確認してください。必要に応じて、ルックアップ元テーブルと結合したクエリにし、表示値側で抽出する設計へ変更するとわかりやすくなります。
パラメータークエリは型を明示する
パラメータークエリでは、入力欄に見える値だけではなく、Accessがその入力値を何型として扱うかが重要です。日付や数値のパラメーターで型指定がないと、文字列として解釈されて型不一致が起きることがあります。
デザインビューの［クエリ デザイン］タブから［パラメーター］を開き、パラメーター名ごとにテキスト・数値・日付/時刻などの型を明示してください。
| SQL例 PARAMETERS [開始日] DateTime; SELECT * FROM T_売上 WHERE 売上日 >= [開始日]; |
4. 条件が正しいのに直らない原因②｜結合・計算フィールド・リンクテーブルを確認
もう一つの盲点は、抽出条件そのものではなく、クエリの土台側に型のずれがあるケースです。結合条件、計算フィールド、外部データとの連携を確認すると、原因が見つかることがあります。
結合フィールドどうしの型を揃える
Accessでテーブルやクエリを結合するときは、対応づけるフィールドの型が同じ、または互換性のある組み合わせである必要があります。たとえば、片方がオートナンバー/長整数、もう片方が短いテキストになっていると、抽出時や結合時に問題が起きやすくなります。
計算フィールドは関数による型変化に注意する
計算式にFormat関数を使うと、結果は見た目が数値や日付でも文字列になります。そのため、Format([売上日], “yyyymm”) の結果に対して日付型の条件を当てる、Format([金額], “#,##0”) の結果に数値条件を当てる、といった使い方は型不一致の原因になります。
日付へ戻したいときはCDateやDateValue、数値へ戻したいときはCLngやCDblなど、目的に応じた変換関数を使うか、そもそも表示用の式と抽出用の式を分けて設計してください。
リンクテーブル・Excel/CSV・SQL Server連携の型ずれ
ExcelやCSVを元にしたリンクテーブルでは、列の内容によってAccessが型を推定します。文字と数値が混在している列や、日付に見えるテキスト列は、期待と異なる型で取り込まれることがあります。外部DBやODBC接続先を含む場合も、元システム側の型とAccess側の型対応を確認し、必要なら中間クエリで型を整えてから抽出するのが安全です。
5. 原因を特定する5STEP｜デザインビューから順番に切り分ける
原因が複数ありそうな場合は、いきなり全部直そうとせず、デザインビューから順番に切り分けると効率的です。
- STEP1：エラーが出ているフィールドを特定する — どの列にどの条件を書いているかを確認する
- STEP2：テーブルの実データ型を確認する — デザインビューで短いテキスト、数値、日付/時刻、Yes/Noなどを確認する
- STEP3：条件の記法を見直す — 文字列の引用符、日付の#、True/False、数値条件の書き方を点検する
- STEP4：ルックアップ・パラメーター・計算式を確認する — 見えている値と保存値、型指定、関数の戻り値を確認する
- STEP5：結合・リンク元・外部データを簡略化して検証する — 問題のクエリを単純化し、どこで型がずれるかを切り分ける
6. 再発を防ぐ設計と運用｜データ型を揃え、パラメーターを明示する
一度直して終わりではなく、今後同じエラーを起こしにくい構造へ整えることも重要です。Accessでは、テーブル設計・リレーション・クエリ設計の段階で型をそろえておくと、抽出条件のトラブルが大きく減ります。
- 主キーと外部キーは、同じ型（例：オートナンバーに対する長整数）でそろえる
- ルックアップは表示値だけで判断せず、保存値の型を把握する
- パラメータークエリは、パラメーターごとに型を明示する
- 表示用にFormat関数を使う場合は、抽出用クエリと分離する
- Excel/CSVを取り込む前に、元データの列型と表記ゆれを整理する
- 複雑なクエリは1本で詰め込まず、中間クエリに分けて検証しやすくする
7. まとめ
Accessの「抽出条件でデータ型が一致しません」は、単純な引用符の付け間違いだけでなく、ルックアップの保存値、パラメーターの型、結合フィールド、計算式、外部データの型ずれでも発生します。まずは対象フィールドの実データ型を確認し、テキスト・数値・日付・Yes/Noの正しい条件へ修正してください。
それでも直らない場合は、ルックアップ、パラメーター、結合、計算、リンクテーブルの順に切り分けると原因が見えやすくなります。Accessのクエリエラーは、設計の整合性を見直すきっかけにもなります。再発防止まで含めて整理すると、保守しやすいデータベースになります。
抽出条件を直してもエラーが消えないAccess、クエリ全体の型を確認できていますか？
単純な条件ミスなら記事内の手順で解決できます。一方、複数クエリの入れ子、ルックアップ、リンクテーブル、SQL Server連携が絡む場合は、原因箇所が別レイヤーにあることも少なくありません。既存Accessの調査、クエリ修正、データ型・リレーション設計の見直し、改修方針の整理まで対応しておりますのでお気軽にご相談ください。
8. よくある質問（FAQ）
クエリが比較している値どうしの型が一致していない、または互換性がないときに出るエラーです。
数値フィールドでは文字列ではなく数値として比較するのが基本です。通常は「100」や「>100」と書きます。
日付/時刻型の条件は「#2026/09/05#」のように#で囲みます。期間指定ならBetween #開始日# And #終了日#が基本です。
わかりやすいのはTrue/Falseです。文字列の「”True”」や「”はい”」ではなく、真偽値として指定します。
画面に見える表示値と、実際に保存される値の型が異なることがあるためです。保存値の型を確認してください。
パラメーターの型を未指定のまま使うと、文字列として解釈されることがあります。クエリのパラメーター設定で型を明示してください。
はい。主キーと外部キー、または結合対象フィールドどうしの型がずれていると、抽出や結合結果に影響します。
起きます。列内の値が混在していると、Accessの型推定が期待とずれることがあります。
参考情報
- Microsoft Support｜データ型の不一致に関するメッセージが表示される（I get a message about data type mismatch）
- Microsoft Support｜クエリの抽出条件の例（Examples of query criteria）
- Microsoft Support｜クエリ・フォーム・レポートでパラメーターを使用する（Use parameters in queries, forms, and reports）
- Microsoft Support｜Accessで2つのテーブルを比較して一致するデータだけを検索する