概要
| この記事の結論 Accessのフィールド名は、項目の意味が分かり、他のフィールドや予約語と混同しにくい名前にします。最大64文字などの仕様上の制限と、空白や表記揺れを避ける運用ルールを分けて考えることが大切です。表示名だけを変えたい場合は標題やラベルを使い、既存フィールドを改名するときはクエリ・フォーム・VBA・外部連携への影響を確認します。 フィールド名とは、テーブルの各列をクエリやフォームなどから参照するための識別名です。 |
この記事でわかること
- 最大64文字などの制限を守る
- 空白や予約語は避ける方針にする
- 表示名と内部名を分ける
- 改名前に依存関係を確認
この記事の主な内容
- 使えない名前と避けたい名前を分ける
- 意味が伝わる命名規則を決める
- 日本語名と英語名を使い分ける
- 主キーと外部キーの名前をそろえる
- 表示名は標題やラベルで調整する
- 既存フィールド名を安全に変更する
- 名前の不備によるエラーを切り分ける
- よくある質問
想定読了時間：約12分～16分
使えない名前と避けたい名前を分ける
フィールド名はテーブルの列を識別する名前です。クエリの抽出、フォームの保存先、レポートの表示、VBAの参照などで使われます。最初に分かりやすく決めることが大切ですが、既存の名前を整える場合は、見た目の変更以上の影響があることも理解しておきましょう。
Accessデスクトップデータベースの名前には公式の制限があります。一方で、空白を避ける、英字の大文字と小文字を統一するといった方針は、保守しやすくするための運用ルールです。「作成できない」と「作成できるが避けたい」を分けると、既存データの調査でも判断がぶれません。[S1]
| 区分 | 内容 | 判断 |
| 仕様上の制限 | 名前は最大64文字 | 上限以内にする |
| 仕様上の制限 | ピリオド、感嘆符、バッククォート、角括弧を含めない | 使用しない |
| 仕様上の制限 | 先頭の空白、制御文字を含めない | 使用しない |
| 運用上の推奨 | 名前の途中の空白や紛らわしい記号を避ける | チームの規則として統一 |
| 運用上の推奨 | 予約語やプロパティ名との衝突を避ける | 意味を加えた別名を選ぶ |
禁止文字を具体的に書くと、.、!、`、[、]です。角括弧はSQLで名前を囲むときに使いますが、フィールド名自体に含めるものではありません。同じテーブル内では、それぞれの列を区別できる名前を付けます。
空白や日本語が一律に禁止されているわけではない
名前の途中の空白は仕様上使えますが、VBAやSQLで参照する際の扱いが複雑になることがあります。日本語名や全角英数が存在するだけで、64bit版Accessでは必ずエラーになる、と一律に説明するのは適切ではありません。表記の混同とbit数による部品・APIの互換性は分けて調べます。
意味が伝わる命名規則を決める
名前を見て「何の値か」が分かることを優先します。日付、金額、番号だけでは、項目が増えたときに役割を区別できません。受注日、税込金額、顧客IDのように対象や意味を加えると、クエリを読む人にも伝わります。
| 分かりにくい例 | 改善例 | 明確になること |
| 日付 | 受注日、出荷予定日 | どの出来事の日付か |
| 金額 | 税抜金額、税込金額 | 税を含むか |
| 番号 | 顧客ID、受注ID | 何を識別する値か |
| Name | 顧客名、CustomerName | 名前プロパティとの混同を避ける |
| 区分1 | 支払区分 | 区分の用途 |
| 2026年10月 | 売上年月 | 値を列名へ埋め込まない |
最後の例は命名だけでなく、テーブル構造の問題です。毎月列を増やす設計なら、「売上年月」と「金額」のように値をレコードへ持つ形も検討します。ただし、既存の月別帳票を急に作り替えるのではなく、利用先や移行方法を先に整理してください。
予約語と曖昧な略語を避ける
Date、Name、Valueなど、AccessやVBAで意味を持つ語と同じ名前は、参照時の混乱につながります。予約語の一覧はMicrosoftの資料を確認し、新規設計では受注日、顧客名のように用途を表す名前を選ぶと分かりやすくなります。[S1][S2]
略語を使う場合も、担当者しか分からない名称を増やさないようにします。Amt、Flgなどを採用するなら意味をデータ定義書へ記載します。名前を短くすることだけを目的にせず、引き継ぎ時に列の意味を説明できるかで判断しましょう。
日本語名と英語名を使い分ける
日本語名は業務担当者が読みやすく、英語名は外部システムや開発規約との統一に向いている場合があります。どちらかが常に正しいわけではありません。利用者、開発者、外部連携先の3つの視点で規則を決めます。
| 方針 | 例 | 適用時の注意 |
| 日本語中心 | 顧客ID、受注日 | 全角と半角の混在を統一 |
| 英語中心 | CustomerID、OrderDate | 用語集と表示名を用意 |
| 単語区切りを使用 | customer_id、order_date | 区切り方を全テーブルで統一 |
| 既存規則を継続 | 既存の命名体系に合わせる | 不要な一括改名を避ける |
「顧客ID」と「顧客ＩＤ」は、見た目が似ていても文字が異なります。担当者が手入力するたびに取り違えると、参照切れや想定外の入力要求の原因になります。日本語を使う場合でも、英数字は半角にそろえるといった規則が役立ちます。
外部連携の列名は契約として確認する
CSVのヘッダー名を別システムが参照している場合、名前変更は連携仕様の変更になります。Access内部の都合で列名を整えても、相手の取込処理が旧名を前提にしていれば失敗します。内部名と出力列名をクエリの別名で分ける方法も検討できます。
主キーと外部キーの名前をそろえる
主キーはテーブル内のレコードを識別する項目、外部キーは別テーブルのレコードを参照する項目です。同じ顧客を指すなら、顧客テーブルと受注テーブルの双方で顧客IDという名称にすると関係が読み取りやすくなります。
| テーブル | フィールド | 役割の例 |
| T_顧客 | 顧客ID | 顧客を識別する主キー |
| T_顧客 | 顧客名 | 表示する名称 |
| T_受注 | 受注ID | 受注を識別する主キー |
| T_受注 | 顧客ID | T_顧客を参照する外部キー |
同じ名前にすれば自動的に正しいリレーションが完成するわけではありません。参照する値の意味、データ型、主キー側の一意性、参照整合性の設定まで確認します。主キーがオートナンバー型なら、参照側には通常、対応する長整数型などを使う設計になります。
すべての主キーがIDでも間違いとは限らない
各テーブルの主キーをIDとする規則も成立します。ただし、複数テーブルを結合するときは、どのテーブルのIDかを明確に参照する必要があります。初心者も保守するシステムなら、顧客IDや受注IDの方が説明しやすい場面があります。既存規則を評価せず一括改名する必要はありません。
SELECT C.[顧客ID], C.[顧客名], O.[受注ID]
FROM [T_顧客] AS C
INNER JOIN [T_受注] AS O
ON C.[顧客ID] = O.[顧客ID];
CとOは、このSQL内で使うテーブルの別名です。同名フィールドが複数あっても、C.[顧客ID]のように取得元を指定すれば読み分けられます。名前の統一と参照の明示は、どちらも保守性を高めるための方法です。
表示名は標題やラベルで調整する
利用者に見せる見出しだけを変えたい場合は、内部のフィールド名を変更せず、標題やフォームのラベルを調整できないか検討します。テーブルのフィールド名、フィールドの標題、フォーム上のラベルは同じものではありません。[S4]
| 要素 | 設定例 | 主な役割 |
| フィールド名 | OrderDate | クエリなどが参照する識別名 |
| フィールドの標題 | 受注日 | データシート等の表示名 |
| テキストボックスの名前 | txtOrderDate | VBAが画面部品を参照する名前 |
| テキストボックスの保存先 | OrderDate | 値を連結するフィールド |
| 付属ラベルの標題 | ご注文日 | 画面の見出し |
既存フォームのラベルが、テーブルの標題変更に合わせて必ず更新されるとは限りません。すでに作られた画面部品は個別に確認します。また、表示が「受注日」でもSQLで参照するのは内部名OrderDateである場合があります。表示だけを見てクエリへ名前を入力しないようにしましょう。
フィールド名の命名の影響範囲が分からない場合
設定だけで解決できない場合や、既存のフォーム・クエリ・外部連携への影響を判断できない場合は、Accessの教科書へご相談ください。対象の画面、起きている症状、変更したい内容を整理すると、調査や改修の範囲を検討しやすくなります。
既存フィールド名を安全に変更する
改名は、元テーブルだけでなく利用先の修正を伴います。バックアップを作り、コピーで対象の参照箇所を調べてから進めます。稼働中のファイルを直接変更しながら問題の出る箇所を探す方法は、業務への影響を把握しにくくなります。
1. 変更前のACCDBと、必要ならバックエンドもバックアップします。
2. 旧名と新名、変更理由、参照先を一覧にします。
3. クエリのSQL、フォーム・帳票の保存先や式、VBA・マクロを調べます。
4. コピー側で改名し、必要な参照式を修正します。
5. 入力、保存、検索、集計、印刷、外部出力まで通して確認します。
6. 変更版の配布手順と切り戻し方法を決めて本番へ反映します。
名前の自動修正だけに任せない
Accessには名前の自動修正機能がありますが、データベース内のすべての参照を安全に修正してくれるわけではありません。Microsoftはマクロやコードなどの参照について制限を示しています。特にVBA内で文字列として組み立てるSQL、外部ファイル、別のAccessからの参照は個別の確認が必要です。[S3]
| 調査対象 | 確認例 |
| クエリ | SELECT、WHERE、JOIN、ORDER BY、計算式 |
| フォーム・レポート | レコードソース、コントロールソース、並べ替え |
| VBA・マクロ | 旧フィールド名を含む参照やSQL文字列 |
| 外部連携 | CSVヘッダー、Excel参照、取込定義、別DB |
| 運用資料 | 入力マニュアル、項目一覧、テスト表 |
変更先がSQL Serverなどのリンクテーブルの場合は、Access側の表示だけでなく、元のデータベース設計とリンク情報の更新も確認します。Access内で名前が変わったように見えることと、外部DBの列名が変わることは同じではありません。
名前の不備によるエラーを切り分ける
予定していない「パラメーターの入力」画面が出るときは、存在しない名前をクエリが参照している可能性があります。入力欄へ適当な値を入れて通すのではなく、画面に表示された名前を控え、元の列名と照合します。
| 症状 | 確認先 | 改善の方向 |
| 名前を尋ねる入力画面が出る | 誤記・改名前の参照 | 実在するフィールド名へ修正 |
| 名前が曖昧と表示される | 複数テーブルの同名列 | テーブル名や別名で修飾 |
| VBAで別の値が返る | Nameなどプロパティとの衝突 | 名前と参照方法を整理 |
| CSV取込先が失敗する | ヘッダー変更 | 連携仕様と出力列名を確認 |
命名規則は、ルールを細かく増やすためのものではありません。「意味が分かる」「表記がそろう」「参照先を追える」を満たす少数の規則を決め、表示名の変更と内部名の変更を使い分けることが、長く保守するAccessでは役立ちます。
よくある質問
日本語のフィールド名は使用できます。社内の担当者が直接テーブルやクエリを読むなら、受注日や顧客名のような名称は理解しやすい選択肢です。一方、外部システムとの連携や開発規約で英語名を求められる場合は、内部名を英語にし、標題や画面ラベルを日本語にする方法があります。重要なのは言語そのものより、同じ意味の項目で表記をそろえることです。既存の日本語名を理由だけで一括改名せず、利用先への影響を先に確認してください。
文字種だけを理由に、64bit版Accessでは必ずエラーになるとは言えません。半角カナや全角英数を避ける主な利点は、似た文字の取り違えや表記揺れを減らし、参照しやすくすることです。64bit移行で問題が起きた場合は、VBAのAPI宣言、外部部品、参照設定などの互換性も別に調べます。命名の問題と実行環境の問題を混ぜないようにしてください。新規設計では英数字を半角へ統一するなど、分かりやすい規則を用意すると管理が容易です。
仕様上認められる文字であれば使用できる場合がありますが、保守上は空白やハイフンを避ける規則が扱いやすくなります。SQLや式で名前を参照するとき、区切りや演算子と混同しないよう角括弧などが必要になるためです。仕様で禁止されるピリオド、感嘆符、バッククォート、角括弧と、運用上避けたい文字は区別してください。既存の名前が使えているなら、直ちに改名せず、参照方法と変更範囲を確認した上で段階的に整理します。
IDという共通の主キー名を使う設計も成立します。ただし、複数テーブルを結合すると、どのIDを指すのかをテーブル名や別名で明示する必要があります。Accessを初心者も保守するなら、顧客IDや受注IDのように対象を含めると理解しやすくなります。一方で、既存システムの規則が明確なら、その規則を維持する方が変更リスクを抑えられます。同じ名前を使うかよりも、主キーと外部キーの意味、データ型、参照先を正しく管理することが大切です。
標題だけの変更なら、通常は内部のフィールド名を参照するクエリを改名する必要はありません。例えば内部名OrderDateの標題を受注日にしても、SQLで使う名前はOrderDateのままです。ただし、既存フォームのラベルや外部出力の見出しまで一括して変わるとは限りません。表示を変えたい場所を実際に確認してください。また、表示名を見て新しいクエリを作る担当者が混同しないよう、項目一覧に内部名と標題を併記すると引き継ぎが容易になります。
確認は必要です。名前の自動修正は一部の依存関係を扱いますが、VBA、マクロ、動的に作るSQL、外部連携まで完全に修正する機能ではありません。改名前にバックアップと参照箇所の一覧を作り、コピーで変更した後、入力、検索、帳票、CSV出力まで動かしてください。予期しないパラメーター入力が出る場合は旧名が残っている可能性があります。自動修正を補助として利用しつつ、業務の一連の流れで影響を確かめることが大切です。
関連記事
フィールド名の命名の影響範囲が分からない場合
設定だけで解決できない場合や、既存のフォーム・クエリ・外部連携への影響を判断できない場合は、Accessの教科書へご相談ください。対象の画面、起きている症状、変更したい内容を整理すると、調査や改修の範囲を検討しやすくなります。
参考情報
[S1] Microsoft 名前のガイドライン
https://support.microsoft.com/en-us/access/guidelines-for-naming-fields-controls-and-objects
[S2] Microsoft Accessの予約語と記号
https://support.microsoft.com/en-us/access/learn-about-access-reserved-words-and-symbols
[S3] Microsoft 名前の自動修正
https://support.microsoft.com/en-us/access/set-name-autocorrect-options
[S4] Microsoft データ型とフィールドのプロパティ
https://support.microsoft.com/en-us/access/introduction-to-data-types-and-field-properties