概要要約
Microsoft Accessのテーブルは、顧客・商品・受注など業務で扱うデータを保存する、データベースの最も基本的なオブジェクトです。見た目はExcelの表に似ていますが、Accessではフィールドごとにデータ型や入力ルールを設定し、主キーによって各レコードを識別します。また、複数のテーブルをIDで関連付けることで、同じ情報を何度も保存せずに管理できます。本記事では、フィールド・レコード・データ型、データシートビューとデザインビュー、主キー、テーブルの作り方から、初心者が避けたい設計ミスまで実務視点で解説します。
この記事でわかること
Accessのテーブルの役割、フィールドとレコードの違い、データシートビューとデザインビューの使い分け、データ型とフィールドプロパティ、主キーを設定する理由、テーブルの基本的な作り方、Excelとは異なるAccessらしいテーブル設計の考え方が分かります。
この記事の主な内容
1.Accessのテーブルとは？まず30秒で役割を理解しよう
2.テーブルを構成するフィールド・レコード・主キーとは？
3.データシートビューとデザインビューの違い
4.データ型とフィールドプロパティ｜何を設定すればよい？
5.Accessでテーブルを作る基本手順
6.初心者がやりがちなテーブル設計の失敗7選
7.まとめ
8.よくある質問（FAQ）
想定読了時間：約12～16分
Accessのテーブルとは？まず30秒で役割を理解しよう
Accessのテーブルとは、データを保存するためのオブジェクトです。顧客管理なら顧客名・住所・電話番号、商品管理なら商品名・単価・商品区分など、同じ種類の情報を決められた構造で蓄積します。
Accessにはクエリ、フォーム、レポート、マクロ、VBAなどさまざまな機能がありますが、その土台となるデータは基本的にテーブルへ保存されています。つまり、テーブルの設計が曖昧だと、その後に作る検索・入力画面・帳票も複雑になりやすくなります。
見た目はExcelに似ているが、目的は違う
データシートビューでテーブルを開くと、行と列でデータが並ぶためExcelの表に似ています。しかし、Accessでは列ごとにデータ型・必須・既定値・入力規則などを定義でき、同じルールでデータを蓄積できます。
| 比較項目 | Excelの表 | Accessのテーブル |
| 基本目的 | 計算・分析・自由な表作成 | 構造化したデータの保存 |
| 列の扱い | 比較的自由 | フィールドとして定義 |
| 入力できる値 | セルごとに柔軟 | データ型や入力規則で制御 |
| 1件の識別 | 行番号等で運用することも多い | 主キーで一意に識別 |
| 複数表の関連 | 関数・参照 | IDとリレーション |
| 利用先 | 計算・グラフ・分析 | クエリ・フォーム・レポート等 |
テーブルを構成するフィールド・レコード・主キーとは？
テーブルを理解するうえで最初に覚えたいのが、「フィールド」「レコード」「主キー」です。
| 用語 | 意味 | 例 |
| フィールド | テーブルを構成する項目・列 | 顧客名、住所、電話番号 |
| レコード | 1件分のデータ・行 | A社1社分の顧客情報 |
| 主キー | レコードを一意に識別する項目 | 顧客ID |
| データ型 | フィールドへ保存できる情報の種類 | 短いテキスト、数値、日付/時刻 |
フィールドは『1項目1情報』を基本にする
例えば「氏名・電話番号」という1つのフィールドに『山田太郎 03-1234-5678』をまとめて保存すると、氏名だけを検索したり電話番号だけを利用したりするのが難しくなります。
後から検索・並べ替え・集計・帳票で使う可能性がある情報は、基本的に別々のフィールドへ分けます。Microsoftも、後から分解するより組み合わせる方が容易なため、データを有用な最小単位に分けることを推奨しています。
主キーは『この1件』を特定するID
顧客名だけでは同名企業や名称変更に対応しにくいため、通常は顧客IDのような一意の値を主キーに設定します。新しいテーブルをデータシートビューで作成すると、Accessは「ID」というオートナンバー型フィールドを自動作成し、主キーとして設定します。
| 主キーに向く値 |
| 主キーは、①重複しない、②空欄にならない、③原則として後から変わらない、という特徴を持つ値が適しています。適切な既存IDがない場合は、オートナンバー型のIDを使うのが分かりやすい方法です。 |
データシートビューとデザインビューの違い
Accessのテーブルは、主に「データシートビュー」と「デザインビュー」の2つの見方があります。
| 項目 | データシートビュー | デザインビュー |
| 主な目的 | データの確認・入力・編集 | テーブル構造の設計 |
| 表示内容 | 実際のレコード | フィールド名・データ型・説明 |
| フィールド追加 | 可能 | 可能 |
| フィールド名変更 | 可能 | 可能 |
| データ型変更 | 可能 | より詳細に設定可能 |
| 主キー設定 | 限定的 | 明確に設定可能 |
| フィールドプロパティ | 一部設定可能 | 詳細設定に向く |
データシートビューはデータを見る・入力する画面
データシートビューでは、Excelに近い見た目でレコードを確認・入力できます。新規フィールドを追加すると、Accessが入力内容からデータ型を推測することもできます。
なお、現在のAccessでは、データシートビューからフィールド名の変更やデータ型変更なども可能です。『構造は必ずデザインビューでしか変更できない』わけではありません。
デザインビューは構造を正確に設計する画面
デザインビューでは、フィールド名、データ型、説明に加えて、フィールドサイズ、既定値、入力規則、必須、インデックスなどを細かく設定できます。
業務用データベースを作る場合は、データを先に大量入力するのではなく、デザインビューで構造を確認してから運用を始める方が安全です。
データ型とフィールドプロパティ｜何を設定すればよい？
Accessでは各フィールドにデータ型を設定します。データ型は『この項目にどの種類のデータを保存するか』を定義するもので、検索・集計・計算・入力チェックに影響します。
| データ型 | 主な用途 | 例・注意点 |
| 短いテキスト | 文字列・コード | 顧客名、電話番号、商品コード |
| 長いテキスト | 長文・備考 | 問い合わせ内容、詳細メモ |
| 数値 | 計算対象の数値 | 数量、点数、割合 |
| 通貨 | 金額 | 単価、売上金額 |
| 日付/時刻 | 日付や日時 | 受注日、登録日時 |
| Yes/No | 二択 | 有効／無効、対応済み／未対応 |
| オートナンバー | 自動採番ID | 顧客ID、受注ID |
電話番号・郵便番号・商品コードは数値型とは限らない
数字だけで構成されていても、計算しないデータは短いテキスト型にした方が適切な場合があります。電話番号、郵便番号、社員番号、商品コードなどが代表例です。
Microsoftも、電話番号や部品番号など数学的計算に使用しない数字は、NumberではなくTextデータ型を選ぶことを案内しています。
短いテキストは最大255文字
Accessデスクトップデータベースの短いテキスト型は最大255文字です。長い文章や自由記述欄は長いテキスト型を検討します。
フィールドプロパティで入力ルールを決める
| プロパティ | 役割 | 例 |
| フィールドサイズ | 保存できる文字数や数値範囲を制御 | 商品コードを20文字まで |
| 既定値 | 新規レコード時の初期値 | 登録日=Date() |
| 必須 | Nullを許可するか | 顧客名は必須 |
| 入力規則 | 入力可能な条件を指定 | 数量 > 0 |
| 書式 | 表示方法を指定 | 日付をyyyy/mm/dd表示 |
| インデックス | 検索や重複制御に利用 | 顧客コードを重複なし |
| 既存データがあるテーブルのデータ型変更に注意 |
| すでにレコードが入っているフィールドのデータ型を変更すると、変換できないデータが失われたり、変更できなかったりする場合があります。本番テーブルを変更するときは、必ずバックアップを取得し、コピー環境で影響を確認してください。 |
Accessでテーブルを作る基本手順
Accessではデータシートビューから作る方法と、デザインビューから設計する方法があります。初心者の練習ならどちらでも構いませんが、業務で利用するテーブルでは、最終的にフィールド・データ型・主キー・プロパティを確認することが重要です。
- ［作成］タブから新しいテーブルを作成する
- 保存したい情報を洗い出し、フィールド名を決める
- フィールドごとにデータ型を設定する
- レコードを一意に識別する主キーを決める
- 必要に応じて必須・既定値・入力規則などを設定する
- 分かりやすいテーブル名で保存する
- テストデータを入力し、検索・入力が想定通りか確認する
顧客テーブルの設計例
| フィールド名 | データ型 | 主な設定 |
| 顧客ID | オートナンバー | 主キー |
| 顧客名 | 短いテキスト | 必須 |
| フリガナ | 短いテキスト | 検索・並べ替え用 |
| 電話番号 | 短いテキスト | 数値型にしない |
| メールアドレス | 短いテキスト | 必要に応じ入力規則 |
| 住所 | 短いテキスト | 必要なら住所1・住所2に分割 |
| 登録日 | 日付/時刻 | 既定値を設定可能 |
| 備考 | 長いテキスト | 自由記述 |
テーブル名・フィールド名は第三者が理解できるようにする
『Table1』『項目1』『項目2』のような名称は、作成者本人でも時間が経つと意味が分からなくなります。業務上の意味が伝わる名称を付けることが、保守性を高める基本です。
命名規則は組織によって異なりますが、少なくとも同じシステム内ではルールを統一します。
初心者がやりがちなテーブル設計の失敗7選
| 失敗 | 問題 | 改善方法 |
| ① 主キーを設定しない | レコードを確実に識別できない | 顧客ID等の一意な主キーを設定 |
| ② すべてを1テーブルに入れる | 同じ情報が繰り返される | 顧客・商品・受注など主題で分割 |
| ③ 商品1・商品2・商品3を作る | 商品数増加で列追加が必要 | 受注明細テーブルへ行で保存 |
| ④ 顧客名で関連付ける | 名称変更・同名で不整合 | 顧客IDで関連付け |
| ⑤ 電話番号を数値型にする | 先頭0やハイフンに不向き | 短いテキスト型 |
| ⑥ 本番テーブルを直接変更 | データ消失・業務停止リスク | バックアップ・検証環境で確認 |
| ⑦ フォームの見た目から設計 | データ構造が後付けになる | テーブル→関係→画面の順で設計 |
『商品1・商品2・商品3』ではなく明細テーブルを作る
例えば1件の受注に複数商品を登録したい場合、受注テーブルに商品1・商品2・商品3というフィールドを作ると、4商品目が発生したときにテーブル構造そのものを変更しなければなりません。
実務では受注テーブルと受注明細テーブルを分け、受注明細に商品ID・数量・単価を1行ずつ登録する構造が一般的です。
テーブルはSQL Server移行後も重要な設計資産
Accessのデータ量・利用人数が増えた場合、テーブル部分をSQL ServerやAzure SQL Databaseへ移行し、Accessをフロントエンドとして使う構成もあります。 このとき、主キー、データ型、テーブル分割、リレーションが整理されていれば移行しやすくなります。逆に、主キーなし・重複だらけ・データ型不統一の状態では、アップサイジング前にデータ構造の整理が必要になることがあります。
| そのAccess、テーブル設計から見直した方がよいかもしれません |
| Accessが重い、改修しにくい、同じデータが複数箇所に存在する、SQL Serverへ移行しづらいといった問題は、フォームやVBAだけでなく、テーブル構造が原因になっている場合があります。 既存Accessのテーブル・データ型・主キー・リレーションを調査し、Excel業務のAccess化からSQL Serverへのアップサイジングまで、データベース設計を含めて支援しておりますのでお気軽にご相談下さい。 |
まとめ｜Accessのテーブルはデータベース全体の土台
Accessのテーブルは、単にExcelのような一覧表ではなく、データベース全体の構造を決める重要なオブジェクトです。
- テーブルはデータを保存する場所
- 列をフィールド、1行をレコードと呼ぶ
- フィールドごとに適切なデータ型を設定する
- 各レコードを一意に識別する主キーを設定する
- データシートビューはデータ確認・入力、デザインビューは構造設計に向く
- フィールドプロパティで必須・既定値・入力規則などを設定できる
- 情報を1テーブルへ詰め込まず、主題ごとに分けて関連付ける
次に理解したいのは、テーブルから必要なデータを取り出す「クエリ」と、複数テーブルを関連付ける「リレーション」です。テーブルを正しく理解すると、その後のAccess学習がかなり分かりやすくなります。
よくある質問（FAQ）
顧客・商品・受注などのデータを保存するオブジェクトです。フィールド（列）とレコード（行）で構成されます。
フィールドは顧客名・住所などの項目、レコードは顧客A社1件分のような1行のデータです。
データシートビューは主にデータの確認・入力、デザインビューはフィールド名・データ型・主キー・プロパティなどテーブル構造の詳細設定に向きます。
Microsoftも特別な理由がない限り主キーを指定することを推奨しています。各レコードを一意に識別し、他テーブルとの関連付けにも重要です。
新しいレコードごとにAccessが自動的に値を付与するデータ型です。顧客IDなどの主キーによく使われます。
通常は短いテキスト型が適しています。電話番号は計算に使わず、先頭0やハイフンを保持する必要があるためです。
単純な連絡先一覧などでは1テーブルでも利用できますが、顧客・商品・受注など種類の異なる情報は複数テーブルへ分けて関連付ける設計が一般的です。
変更できます。ただし、クエリ・フォーム・VBAなどから参照されている場合は影響が出る可能性があるため、既存システムでは慎重に確認します。
変換できないデータがあるとデータ損失やエラーにつながる可能性があります。必ずバックアップと検証を行ってから変更してください。
練習や管理者による確認では問題ありませんが、実務利用者にはフォームを使わせ、入力規則や操作を制御する設計が適するケースが多くあります。
参考資料・確認ソース
Microsoft Support：Create a table and add fields
https://support.microsoft.com/en-us/access/create-a-table-and-add-fields
Microsoft Support：Create a new database
https://support.microsoft.com/en-us/access/create-a-new-database