Accessのデータ型についてお探しですね。

広告

Accessのテーブル作成で迷わない!データ型とフィールドサイズの選び方

Accessでテーブルを作るとき、多くの人が最初につまずくのが「データ型」と「フィールドサイズ」の設定です。

見た目は同じ数字でも、計算に使うのか、電話番号みたいに文字として扱うべきなのかで選ぶ型が変わってきます。

この記事では、Accessのデータ型一覧と、適切なフィールドサイズの決め方を、初心者の方でも判断しやすいように具体例を交えて解説していきます。

最初にきちんと設計しておけば、入力ミスや集計エラー、ファイル容量の肥大化を防げて、後から修正するのも楽になりますよ。

Accessのデータ型一覧と基本的な役割

Accessのデータ型とは、テーブルの各フィールドに「どんな種類のデータを保存するか」を指定する設定のことです。

Excelなら同じ列に文字と数値を混ぜて入力できますが、Accessではフィールドごとにデータ型を決めることで、入力できる値を制限して、データの整合性を保つ仕組みになっています。

たとえば、生年月日のフィールドを日付/時刻型にしておけば、「13月」みたいな存在しない日付は入力できなくなりますし、年齢計算や期間の抽出もやりやすくなります。

Accessでよく使われるデータ型には、短いテキスト、長いテキスト、数値型、日付/時刻型、通貨型、オートナンバー型、Yes/No型などがあります。

他にも、ハイパーリンク型、添付ファイル型、OLEオブジェクト型、集計、ルックアップウィザード、大きい数値、拡張した日付/時刻型なども用意されています。

ただし、全部を同じくらい使うわけではなくて、普通の業務データベースでは主要な型をしっかり理解しておけば大丈夫です。

主なデータ型の用途はこんな感じです。

| データ型 | 主な用途 | 代表例 |
|—|—|—|
| 短いテキスト | 255文字以内の文字列 | 氏名、住所、電話番号、郵便番号、商品コード |
| 長いテキスト | 長文の文章 | 備考、問い合わせ内容、説明文 |
| 数値型 | 計算に使う数値 | 数量、在庫数、点数、割合 |
| 大きい数値 | すごく大きい整数 | 外部DBとの連携、巨大なID |
| 日付/時刻型 | 日付や時刻 | 生年月日、登録日、注文日時 |
| 拡張した日付/時刻型 | より精密または広範囲の日時 | 歴史データ、高精度ログ |
| 通貨型 | 金額計算 | 売上金額、請求額、単価 |
| オートナンバー型 | 自動で振られる番号 | 顧客ID、商品ID、伝票ID |
| Yes/No型 | 二択の状態 | 完了フラグ、有効/無効、確認済み |
| ハイパーリンク型 | URLやメールアドレス | Webサイト、メール、ファイルパス |
| 添付ファイル型 | ファイルの保存 | 商品画像、PDF、資料 |
| OLEオブジェクト型 | 外部アプリのオブジェクト保存 | 古い形式の文書や画像 |
| 集計 | 他のフィールドの計算結果 | 金額=数量×単価 |
| ルックアップウィザード | 選択リストから入力 | 部署名、分類、商品選択 |

ここで一つ注意したいのが、ルックアップウィザードは厳密には保存形式そのものというより、別のテーブルや値リストから選ばせるための入力補助機能に近いということです。

初心者には便利なんですが、実際に保存されている値が見た目と違う場合があるので、リレーションシップやクエリの仕組みを理解しながら使うのが大切です。

よく使うデータ型の選び方と間違えやすいポイント

短いテキスト型

短いテキスト型は、Accessで一番よく使うデータ型の一つです。

氏名、住所、会社名、商品コード、電話番号、郵便番号など、**計算しない文字情報**に使います。

数字だけで構成されているデータでも、足し算や平均などの計算をしないなら、数値型ではなく短いテキスト型を選ぶのが基本です。

電話番号を数値型にすると先頭の「0」が消えちゃうことがありますし、郵便番号や社員番号でも桁数やハイフンをちゃんと保持できない可能性があります。

長いテキスト型

長いテキスト型は、備考欄や問い合わせ本文みたいに、255文字を超える可能性がある文章に向いています。

ただし、短い文字列で済むフィールドに何となく長いテキスト型を使うと、設計があいまいになって、検索や並べ替え、パフォーマンス面で扱いにくくなることがあります。

入力される内容が名前やコードみたいに短く決まっているなら短いテキスト型、文章量が読めない説明欄なら長いテキスト型、という切り分けが実務では分かりやすい基準です。

数値型

数値型は、数量、在庫数、点数、回数など、**計算対象になる値**に使います。

ここで大事なのは、見た目が数字かどうかではなく、「計算する意味があるか」で判断することです。

たとえば、商品コード「00123」は数字に見えますが、商品同士を足したり平均したりしないので、短いテキスト型が適しています。

一方、販売数量や単価に対する個数は集計や比較を行うので、数値型または通貨型を選ぶべきです。

日付/時刻型

日付/時刻型は、日付として検索・計算したい情報に使います。

文字列で「2026/01/15」と保存しても見た目は日付っぽいですが、Access内部では単なる文字として扱われるので、DateDiff関数で経過日数を求めたり、今月分だけを抽出したりする処理が複雑になっちゃいます。

登録日、納期、生年月日、更新日時などは、原則として日付/時刻型にしておくと、後のクエリやフォーム作成が楽になります。

通貨型

金額を扱う場合は、数値型ではなく通貨型を検討しましょう。

通貨型は固定小数点の形式で金額計算に向いていて、丸め誤差を抑えやすい特徴があります。

単価、売上金額、請求金額、給与など、お金として扱うフィールドは通貨型にしておくと、集計や帳票出力で扱いやすくなります。

小数を含むからといって常に倍精度浮動小数点型を選ぶのではなく、金額なら通貨型、測定値や割合なら数値型の小数対応サイズ、という判断が現実的です。

適切なフィールドサイズの設定方法

フィールドサイズとは、保存できる文字数や数値の範囲を決めるプロパティです。

特に設定が重要になるのは、短いテキスト型と数値型です。

短いテキスト型のフィールドサイズ

短いテキスト型では最大255文字まで指定できますが、すべてのフィールドを何となく255文字にするのはおすすめできません。

たとえば、都道府県なら10文字程度、郵便番号ならハイフン込みで8文字、性別コードや区分コードなら1〜2文字など、実際に必要な長さに合わせることで入力ミスの抑制にもつながります。

フィールドサイズは、「最大で何文字入る可能性があるか」を基準に決めます。

ただし、現在のデータだけで判断すると将来足りなくなることがあるので、少し余裕を持たせるのが実務的です。

たとえば、氏名は日本語だけなら20〜30文字程度で足りることが多いですが、法人名や海外の名前を扱う場合は長めに設定します。

住所は建物名まで含めるなら100文字程度を見込むなど、入力ルールと業務の実態を合わせて考えることが大切です。

数値型のフィールドサイズ

数値型のフィールドサイズは、保存できる数値の範囲と精度に関わります。

代表的な種類を理解しておくと、必要以上に大きなサイズを選ばずに済みます。

| 数値型のフィールドサイズ | 保存できる値の目安 | 向いている用途 |
|—|—|—|
| バイト型 | 0〜255の整数 | 年齢、月、評価点など小さい整数 |
| 整数型 | -32,768〜32,767の整数 | 小規模な個数、点数 |
| 長整数型 | 約-21億〜約21億の整数 | ID、件数、在庫数など一般的な整数 |
| 単精度浮動小数点型 | 約7桁精度の小数 | 厳密性が高くない測定値 |
| 倍精度浮動小数点型 | 約15桁精度の小数 | より精度が必要な小数計算 |
| 十進型 | 小数点以下の桁を重視する数値 | 利率、精度が必要な小数 |
| レプリケーションID型 | GUID形式の一意識別子 | レプリケーションや特殊な識別子 |

一般的な業務システムでは、整数を扱うなら長整数型を選ぶ場面が多く、小数が必要なら倍精度浮動小数点型や十進型を検討します。

ただし、容量を抑える目的だけで極端に小さい型を選ぶと、将来データが増えたときに範囲不足になる可能性があります。

たとえば、在庫数が255を超える可能性があるならバイト型ではなく整数型以上、伝票番号や連番に近い値なら長整数型を選ぶ方が安全です。

オートナンバー型

オートナンバー型は、新しいレコードを追加するたびに自動で番号を振るデータ型で、主キーによく使われます。

主キーとは、各レコードを一意に識別するための項目です。

オートナンバーは削除された番号が再利用されないので、途中に欠番が発生することがありますが、これは異常ではありません。

請求書番号みたいに欠番を避けたい業務番号をそのままオートナンバーで管理すると運用上困る場合があるので、内部管理用IDと表示用番号は分けて設計すると安全です。

データ型変更時の注意点と設計で失敗しないコツ

Accessでは、作成後にフィールドのデータ型を変更することもできますが、既にデータが入っている場合は注意が必要です。

長いテキスト型から短いテキスト型に変更すると255文字を超える部分が切り捨てられる可能性がありますし、テキスト型から数値型に変更する場合は、数値として解釈できない文字が含まれていると変換できません。

日付や通貨でも同じで、変換先の形式に合わない値があるとエラーやデータ損失の原因になります。

さらに、テーブルのデータ型を変更すると、そのフィールドを参照しているクエリ、フォーム、レポート、VBAにも影響することがあります。

たとえば、数値型として作った顧客IDを後から短いテキスト型に変更すると、クエリの抽出条件や結合条件の見直しが必要になる場合があります。

変更前には必ずバックアップを取って、テスト用のコピーで変換結果を確認してから本番データに反映するのが基本です。

クエリでの注意点

クエリで条件指定を行うときも、データ型の違いを意識する必要があります。

短いテキスト型の値は引用符で囲み、日付/時刻型の値はAccessでは「#」で囲むのが一般的です。

一方、数値型は引用符で囲まずに指定します。

この違いを理解していないと、「抽出条件でデータ型が一致しません」といったエラーが出やすくなります。

データ型は保存時だけでなく、検索、集計、フォーム入力、レポート出力まで影響する設定だと考えるといいでしょう。

その他の設定も合わせて検討

設計時には、データ型だけでなく、入力規則、既定値、必須入力、インデックス、ルックアップの使い方も合わせて検討しましょう。

たとえば、数量にマイナス値を入れたくないなら入力規則で「0以上」に制限したり、登録日は既定値に現在日付を設定すると入力ミスを減らせます。

部署や分類みたいに選択肢が決まっている項目は、別テーブルを用意してルックアップやコンボボックスで選ばせると、表記ゆれを防ぎやすくなります。

まとめ:データ型選びで押さえておきたいポイント

Accessのデータ型一覧と適切なフィールドサイズの設定方法を実務で判断する際は、次の視点で確認すると失敗を減らせます。

1. **保存したい値は文字なのか、計算対象なのか、日付なのかを最初に分類する**
2. **最大文字数や数値範囲を見積もり、将来の増加分を少しだけ加味してフィールドサイズを決める**
3. **電話番号や郵便番号のような「数字に見える文字列」を数値型にしない**
4. **金額は通貨型を優先する**
5. **主キーには原則としてオートナンバー型を使う**

Accessのテーブル設計は、最初のデータ型選びで使いやすさが大きく変わります。

適切なデータ型とフィールドサイズを設定しておけば、不正な入力を防げて、クエリやフォーム、レポートの作成もスムーズになります。

逆に、あいまいな設定のまま運用を始めると、後からの修正範囲が広がりやすくなります。

テーブルを作る段階で「この値は何に使うのか」「どの範囲まで入るのか」を確認しながら設計することが、Accessを長く安定して使うための基本です。

広告