概要
| この記事の結論 Accessのテーブル名は、扱うデータと1行の意味が分かり、チームで表記がそろう名前にします。使用できない文字などの仕様と、接頭辞や英語表記などの運用ルールは区別しましょう。日本語の名前やT_などの接頭辞の有無だけで良し悪しは決まりません。運用中の名前変更はクエリ、フォーム、VBA、外部連携へ影響するため、対応表とバックアップを用意して検証用コピーから進めます。 |
この記事でわかること
- Accessの制約と推奨ルールを分ける
- 日本語と英語の使い分けを決める
- 1行の意味が伝わるテーブル名を選ぶ
- 依存関係を確認して名前を変更する
この記事の主な内容
- テーブル名はデータの内容と単位を表す
- Accessの制約と避けたい名前を整理する
- チームで使える命名ルールを決める
- マスターと取引データの名前を設計する
- 既存テーブル名を安全に変更する
- 名前変更後のエラーを切り分ける
- 命名台帳と運用のまとめ
- よくある質問
想定読了時間：約12分～15分
テーブル名はデータの内容と単位を表す
テーブル名は、その表が何を保存し、1行が何を意味するのかを伝える名前にします。「テーブル1」「データ」「新しい売上」などの名前は作成直後には分かっても、数年後の改修や担当交代では判断材料が足りません。
例えば「T_受注」は受注1件、「T_受注明細」は受注内の明細1件を表す、と決めます。両方を単に「売上」と呼ぶと、受注金額を集計する際にどちらを使うべきか迷います。命名は見た目の統一だけでなく、誤った集計や更新を防ぐ設計の一部です。
正しい名前には2種類の基準がある
Accessが受け付ける名前かどうかという「仕様上の制約」と、チームが理解しやすいかという「運用上の推奨」は別です。接頭辞を付ける、英語を使う、単数形で統一する、といったルールは組織内の選択であり、Access共通の必須仕様ではありません。
［参考1］
［参考4］
本記事では、現場の担当者がAccessを保守するケースを想定し、「M_商品」「T_受注」などの例を使います。これは一つの設計案です。既にtblCustomerなどのルールで安定運用しているシステムを、見た目を合わせるためだけに一括改名する必要はありません。
Accessの制約と避けたい名前を整理する
Accessのオブジェクト名は最大64文字です。ただし、長さの上限まで使うことを推奨するものではありません。名前を短くするために意味不明な略語へ置き換えるのも避け、対象業務と内容が読み取れる長さにします。
［参考1］
［参考4］
使用できない文字と避けたい表記
Microsoftのガイドラインでは、ピリオド、感嘆符、角かっこなどを名前に使用できないことが示されています。テーブル作成の資料には、テーブル名に対する追加の制限もあります。細かな例外を利用するより、英数字・日本語・アンダースコアを基本にし、記号は使わないルールが確認しやすくなります。
［参考1］
［参考2］
| 区分 | 例 | 考え方 |
|---|---|---|
| 仕様上の制約 | 64文字を超える名前 | 上限を守る |
| 仕様上の制約の代表例 | 商品.一覧、商品!、商品[旧] | ピリオド・感嘆符・角かっこを避ける |
| 仕様上の制約 | 先頭の空白・印字できない制御文字 | コピーした名称に混入していないか確認 |
| 運用上避けたい例 | Ｍ_商品、M_ｼｮｳﾋﾝ | 英数字・カナの表記揺れをなくす |
| 運用上避けたい例 | 商品 一覧、商品-一覧 | 空白や記号を使わず命名を簡単にする |
| 運用上避けたい例 | Data、Table1、最新データ | 対象と用途が分かる名前へ変える |
| 衝突を避けたい例 | Date、Name、Order | 予約語・関数名・プロパティ名と紛らわしくしない |
この表の禁止文字は代表例で、使用できない文字の完全な一覧ではありません。新しい命名ルールでは、使ってよい文字を限定する方が運用しやすくなります。例えば「英数字は半角、カナは全角、区切りは_のみ」と決め、記号を使う必要があるかを最初に検討します。
角かっこで囲めば解決するとは限らない
SQLでは、空白を含む識別子や曖昧な名前を角かっこで囲んで参照することがあります。ただし、これはAccessが受け付けない名前を保存できるようにする方法ではありません。また、名前が紛らわしいままだと、式やVBAでの読み間違いは残ります。
SELECT [商品ID], [商品名]
FROM [M_商品];
この例の角かっこは名前の境界を明示しています。実際のテーブル名に角かっこが含まれているわけではありません。SQLを読む担当者へ、識別子と記号の役割を説明すると引継ぎ時の混乱を防げます。
チームで使える命名ルールを決める
命名ルールは、例外なく完璧な規則を作ることより、チームが同じ判断をできることが大切です。名前の言語、接頭辞、略語、大小文字、履歴や取込用の扱いを1枚の台帳にまとめ、レビュー時に参照できるようにします。
日本語名と英語名を選ぶ観点
| 観点 | 日本語名が扱いやすい場面 | 英語名が扱いやすい場面 |
|---|---|---|
| 主な保守担当 | 日本語の業務用語で運用する担当者 | 複数言語の開発者や外部ベンダー |
| 利用範囲 | Access中心の社内システム | APIや他DBとの共通スキーマ |
| 名称の一致 | 帳票・業務規程の用語に合わせる | 外部連携先の定義に合わせる |
| 必要な補助資料 | 略称と正式名称の辞書 | 英語名と日本語業務名の対応表 |
日本語名そのものを理由に、Accessで使えない、64bit版で必ず壊れる、と判断するのは適切ではありません。32bitから64bitへの移行では、VBAのAPI宣言、ActiveX、ドライバー、コンパイル済みファイルなどを別に調べます。命名の問題と実行環境の互換性を混同しないでください。
将来SQL Serverへ移行する可能性がある場合は、移行先の識別子・予約語・スキーマの扱いも考慮します。ただし「今すぐ全テーブルを英語へ変更する」が唯一の選択ではありません。Access側のリンク名とサーバー側の実テーブル名を分けて管理する方法もあります。
接頭辞は付けても付けなくてもよい
接頭辞とは名前の先頭に付ける分類記号です。「M_」をマスター、「T_」を取引、「W_」を作業用とすれば、名前から用途を予測しやすくなります。一方、顧客・商品・受注のような名称だけでも、台帳と運用が整っていれば成立します。
| ルール項目 | 今回の採用例 | 採用理由 |
|---|---|---|
| 基本形 | 接頭辞_業務名 | 用途と内容を分けて読める |
| 接頭辞 | M_、T_、W_ | 基本情報・取引・作業用を区別 |
| 英数字 | 半角 | 入力や検索の表記揺れを減らす |
| カナ | 全角 | 同じ語の別表記を作らない |
| 区切り | アンダースコア | 空白や演算記号との混同を避ける |
| 略語 | 合意した語だけ使う | 作成者しか分からない名前を避ける |
| 年月や版番号 | 恒久テーブルには原則付けない | 同じ構造の表を増殖させない |
年月を名前に含める運用が必要な場合は、保存期限や統合方法まで決めます。毎月「売上202610」「売上202611」を増やす設計より、通常は売上日をフィールドとして持ち、1つのテーブルから条件で抽出する方が集計しやすくなります。法令保存や外部納品の要件がある場合は、別途その条件を優先します。
マスターと取引データの名前を設計する
名前を決める前に、何を1行として保存するかを文章にします。「顧客1社」「受注1件」「受注内の商品1行」の違いが決まれば、テーブルを分けるべきか、どの名称にするべきかも考えやすくなります。
| 名前の例 | 1行の意味 | 主キーの例 | 注意点 |
|---|---|---|---|
| M_顧客 | 顧客1件 | 顧客ID | 同じ顧客を部署別に重複させるか定義 |
| M_商品 | 商品1件 | 商品ID | 商品コードの一意性を別に確認 |
| T_受注 | 受注1件 | 受注ID | 明細ごとの数量を混在させない |
| T_受注明細 | 受注内の明細1件 | 受注明細ID | 受注IDとの関係を定義 |
| W_商品取込 | 今回の取込候補1件 | 作業IDなど | 元ファイル・処理回を追跡 |
作業用テーブルにはW_を付ければ自由に消してよい、という意味にはなりません。共有データベース上の作業用表を全削除すると、別の利用者の処理へ影響することがあります。名前の分類とは別に、所有者、利用単位、削除タイミングを決めます。
また、保存済みクエリと実テーブルを取り違えないことも重要です。テーブルとクエリの接頭辞を分けるかどうかはチームで決めますが、台帳にはオブジェクト種類を明示してください。名前の読みやすさだけで、更新対象やデータの実体まで判断しないようにします
既存テーブル名を安全に変更する
運用中の名前変更は、ナビゲーションウィンドウで名前を直す作業だけでは終わりません。その名前を参照するクエリ、画面、帳票、VBA、外部ファイルを調べ、変更後に一通り動くことを確認する必要があります。
名前の自動修正の範囲を理解する
Accessには名前変更を追跡して参照を修正する「名前の自動修正」があります。ただしMicrosoftは、マクロやコード内のテーブル名・クエリ名・フィールド名などが自動修正されないことを示しています。自動修正を有効にしたから参照調査が不要になるわけではありません。
［参考3］
特にVBAでSQL文字列を組み立てる処理、DLookupなどへ文字列で渡す名前、Excelからの外部接続は見落としやすい箇所です。オブジェクトの依存関係表示は調査の入口として役立ちますが、文字列として組み立てた参照を含め、すべての依存関係を網羅する前提にはしません。
検証用コピーで変更する手順
- 利用者と変更時間帯を調整し、Accessファイルとデータのバックアップを取ります。
- 現在の名前、新しい名前、用途、参照先、変更理由を対応表へ記録します。
- クエリ、レコードソース、値集合ソース、式、マクロ、VBA、外部連携を調べます。
- 検証用コピーでテーブルを閉じ、ナビゲーションウィンドウから名前を変更します。
- 残った旧名参照を修正し、VBAのコンパイルと主要処理を確認します。
- 入力、検索、集計、帳票、取込を確認し、運用への反映と切り戻し条件を決めます。
分割データベースでは、フロントエンドの表示名とバックエンドの実テーブル名が別になります。リンクテーブルの名前を変更しても、リンク先の実体名が同時に変わるとは限りません。逆に実体名を変更した場合は、各フロントエンドのリンク更新も必要になる可能性があります。
| 旧名 | 新名 | 影響範囲 | 確認結果の記録例 |
|---|---|---|---|
| 商品一覧 | M_商品 | Q_売上、F_受注、Excel集計 | 選択・保存・集計の確認日 |
| 受注データ | T_受注 | F_受注、R_受注票 | 既存伝票・新規入力の結果 |
| 取込 | W_商品取込 | 取込マクロ、VBA | 正常・重複・エラー時の結果 |
テーブル設計と名前変更の影響調査でお困りの方へ
検証用コピーでの確認が難しい場合や、複数の画面・外部連携へ影響する場合は、Accessの教科書のお問い合わせ窓口へご相談ください。現在の構成、困っている操作、変更したい内容を整理すると、確認すべき範囲を伝えやすくなります。
名前変更後のエラーを切り分ける
名前変更後に「パラメーターの入力」が出たり、フォームが開かなくなったりする場合は、旧名が参照先に残っている可能性があります。まず直前に変更した名前と症状の出る操作を記録し、関係するデータソースから順に確認します。
| 症状 | 確認する箇所 | 注意点 |
|---|---|---|
| パラメーター入力を求められる | SQL、式、並べ替え、値集合ソース | 旧名を未解決の名前として解釈していないか |
| フォームが開かない | レコードソース、起動イベント | 基になるクエリを単独で確認 |
| コンボの候補が空になる | 値集合ソース、抽出条件 | 画面本体と別の参照がある |
| 帳票だけ動かない | 帳票クエリ、グループ化、式 | プレビューと印刷を両方確認 |
| 別PCだけ動かない | 旧フロントエンド、外部接続 | 修正版の配布とリンク先を確認 |
| VBA実行時にエラーになる | 文字列SQL、DLookupなど | コンパイル成功だけでは見つからない場合がある |
変更後にエラーが発生しても、さらに名前を変えて試し続けないようにします。変更対応表へ症状を記録し、必要ならバックアップへ戻して原因を整理します。本番データが更新されている場合は、古いバックアップの無条件復元で新しいデータを失わないよう、切り戻す範囲も判断してください。
命名台帳と運用のまとめ
命名台帳には名前だけでなく、用途、1行の意味、主キー、管理担当を残します。取込元や利用する画面が分かると、使われていない表を整理するときも判断しやすくなります。更新日を記録し、システム変更と同時に台帳も直す運用にしましょう。
名前の良し悪しは、接頭辞や日本語・英語の好みだけでは決まりません。仕様上の制約を守り、業務の意味を伝え、変更の影響を追跡できることが大切です。新規開発ではルールを先に決め、既存改修では改名の効果と影響範囲を比較して実施を判断してください。
よくある質問
必須ではありません。T_やtblはテーブルであることを示す命名上の慣習で、Accessの仕様ではありません。既存システムにルールがある場合は、その規則に合わせる方が保守しやすくなります。新しく決めるなら、T_を全テーブルに付ける方法と、M_・T_・W_で用途を分ける方法のどちらも考えられます。記号の選択より、同じ意味を同じ表記で使い続けること、例外を台帳に残すことを重視してください。
日本語名を一律に避ける必要はありません。日本語の業務担当者がAccessを保守する場合は、商品や受注などの名称が理解を助けます。一方、海外の開発者や外部システムとの共通定義がある場合は、英語名と日本語の説明を組み合わせる方法が適しています。どちらでも表記揺れや曖昧な略語は避けましょう。日本語を使っていることだけで64bit移行時の原因と決め付けず、部品やAPIなどの互換性も別に確認します。
Accessでは名前に空白を含められる場合がありますが、先頭の空白は認められず、空白入りの名前はSQLやVBAで扱いに注意が必要です。運用ルールとしては、空白を使わずアンダースコアで区切る方が分かりやすくなります。既存の空白入り名称を参照するときは角かっこで境界を示せますが、それだけで命名や依存関係の問題がすべて解消するわけではありません。変更する場合は参照先を調べてから進めてください。
すべては直りません。Microsoftの説明では、マクロやコード中のテーブル名、クエリ名、フィールド名などは自動修正の対象外です。特にVBA内のSQL文字列や、関数へ文字列で渡した名前は手作業の確認が必要です。オブジェクトの依存関係表示だけにも頼らず、旧名の検索と実際の業務操作を組み合わせます。VBAのコンパイルが通っても、ボタンを押したときに初めて組み立てられるSQLの誤りは残ることがあります。
技術的に作れることと、保守しやすいことは別です。同じ構造のテーブルを毎月増やすと、年間集計や項目追加のたびに複数の表を扱う必要があります。通常は売上日をフィールドに持たせ、1つのテーブルから月を条件に抽出する設計を検討します。ただし保存要件や外部システムの制約がある場合は別判断です。既存の月別表を統合する場合も、重複キー、項目差、過去帳票への影響を確認してから移行してください。
古い名前を必ず残す必要はありませんが、改名の効果と影響範囲を比較して判断します。意味が伝わらず誤操作の原因になっている場合は、台帳整備と改名を検討する価値があります。一方、見た目だけの統一が目的で多数の外部参照を修正するなら、説明を台帳へ追加する方が負担は小さくなります。改名する場合はバックアップ、旧名と新名の対応表、業務テスト、利用者への配布手順まで用意して実施しましょう。
テーブル設計と名前変更の影響調査でお困りの方へ
検証用コピーでの確認が難しい場合や、複数の画面・外部連携へ影響する場合は、Accessの教科書のお問い合わせ窓口へご相談ください。現在の構成、困っている操作、変更したい内容を整理すると、確認すべき範囲を伝えやすくなります。
関連記事
参考情報
参考1 Microsoft Support｜命名ガイドライン
https://support.microsoft.com/ja-jp/access/guidelines-for-naming-fields-controls-and-objects
参考2 Microsoft Support｜テーブルとフィールドの作成
https://support.microsoft.com/ja-jp/access/create-a-table-and-add-fields
参考3 Microsoft Support｜名前の自動修正
https://support.microsoft.com/en-us/access/set-name-autocorrect-options
参考4 Microsoft Support｜Accessの仕様
https://support.microsoft.com/en-us/access/access-specifications