概要
Accessの「短いテキスト（Short Text）」は、氏名・住所・電話番号・商品コードなど、比較的短い文字列を保存するデータ型です。最大255文字まで保存でき、Field Sizeでは1～255文字の範囲で上限を設定できます。数字だけで構成されていても、計算ではなく識別に使う値なら短いテキストが適する場合があります。
この記事でわかること
- Accessの短いテキストが何を保存するためのデータ型なのか
- 最大255文字という仕様と、Field Sizeを1～255で設定する意味
- 電話番号・郵便番号・社員番号・商品コードを文字列として扱う考え方
- 短いテキストと数値型、長いテキストの違いと使い分け
- Format、Input Mask、Required、Indexedなど主要なフィールドプロパティ
- 既存データがあるフィールドのデータ型を変更するときの注意点
- 将来のSQL Server移行も見据えた文字列フィールド設計の考え方
この記事の主な内容
1.Accessの短いテキストとは？まず30秒で理解しよう
2.短いテキストに向いているデータ・向いていないデータ
3.短いテキストと数値型・長いテキストの違い
4.短いテキスト型フィールドの作り方とField Sizeの設定
5.短いテキストで覚えておきたいフィールドプロパティ
6.短いテキストで失敗しやすいポイントと既存Access変更時の注意
7.まとめ｜データ型は「見た目」ではなく「用途」で決める
8.よくある質問（FAQ）
想定読了時間：約12～15分
1. Accessの短いテキストとは？まず30秒で理解しよう
Accessの短いテキストは、文字・数字・記号などを「文字列」として保存するためのデータ型です。現行のAccessではShort Textと表記され、旧バージョンの「Text（テキスト）」型に相当します。氏名、会社名、住所、メールアドレス、コード類など幅広い項目で利用されます。
Microsoftの仕様では、短いテキストフィールドに保存できるのは最大255文字です。ここでいう255は「半角255文字」という意味ではなく、文字数としての上限です。そのため、日本語を含むデータでも「最大255文字」と理解するのが適切です。
| 30秒でまとめると、、、 短いテキストは「比較的短い文字列を保存するデータ型」です。最大255文字で、文字だけでなく数字や記号も保存できます。ただし、数字を保存できるからといって計算向けのデータ型ではありません。保存する値を何に使うかで、数値型などと使い分けます。 |
「数字に見える値」も短いテキストになることがある
例えば「00123」という商品コードは数字だけで構成されています。しかし、加算や平均を求めるための数値ではなく、商品を識別するためのコードです。このような値は短いテキストとして保存すると、先頭の0をそのまま保持しやすくなります。
一方で、数量「12」や単価「1500」、売上金額「18000」のように計算する値は数値型や通貨型などを検討します。つまり、データ型は見た目が数字かどうかではなく、その値を「計算するのか」「識別に使うのか」で判断することが重要です。
2. 短いテキストに向いているデータ・向いていないデータ
短いテキストは非常に柔軟なため、多くのデータを保存できます。ただし、何でも短いテキストにすればよいわけではありません。まずは「計算しない比較的短い文字列」を基本とし、データの意味に応じて他の型と使い分けます。
| データ例 | おすすめ | 理由・補足 |
|---|---|---|
| 氏名・会社名 | 短いテキスト | 文字列として検索・表示するため |
| 住所 | 短いテキスト | 255文字以内で収まる住所なら扱いやすい |
| メールアドレス | 短いテキスト | 文字列として保存・検索するため |
| 電話番号 | 短いテキスト | ハイフンや+、先頭0を含み、計算しないため |
| 郵便番号 | 短いテキスト | 先頭0やハイフンを保持し、計算しないため |
| 社員番号・商品コード | 短いテキスト | 識別子として扱い、文字混在への拡張にも対応しやすい |
| 数量・単価・金額 | 数値型／通貨型等 | 加減算・集計・比較などの計算に利用するため |
| 長い説明文・備考 | 長いテキスト | 255文字を超える可能性があるため |
| 日付・時刻 | 日付/時刻型 | 日付計算・期間検索・書式処理を行うため |
電話番号・郵便番号を数値型にしない理由
電話番号や郵便番号は数字の並びですが、通常は足したり引いたりしません。また、電話番号にはハイフンや国番号の「+」が含まれることがあり、日本国内の番号では先頭の0も意味を持ちます。そのため、文字列として保存する方がデータの意味に合っています。
さらに、コード体系は運用途中で変更されることがあります。現在は数字だけでも、将来「A00123」のように英字が追加される可能性があるなら、最初から短いテキストとして設計しておくと変更の影響を抑えやすくなります。
3. 短いテキストと数値型・長いテキストの違い
短いテキストを適切に使うには、特に「数値型」と「長いテキスト」との違いを理解しておくことが大切です。保存できる見た目だけで判断すると、並べ替えや計算、入力制御で想定外の結果になる場合があります。
短いテキストと数値型の違い
| 比較項目 | 短いテキスト | 数値型 |
|---|---|---|
| 主な用途 | 文字列・コード・名称 | 計算する数値 |
| 保存例 | 00123、03-1234-5678、A-100 | 123、1500、98.5 |
| 先頭0 | 保持できる | 通常は数値として解釈されるため意味を持たない |
| 文字混在 | 可能 | 不可 |
| 算術計算 | 基本的に不向き | 得意 |
| 並べ替え | 文字列として比較 | 数値として比較 |
文字列として保存した数字は、文字列として扱われる
例えば短いテキストに「1」「2」「10」を保存した場合、文字列としての並び順や比較が行われます。数値として1、2、10を扱いたい業務なら数値型を選択する方が自然です。反対に「001」「010」「100」のようなコードであれば、文字列としての比較が目的に合う場合があります。
短いテキストと長いテキストの違い
| 比較項目 | 短いテキスト | 長いテキスト |
|---|---|---|
| 主な用途 | 名称・コード・短い文字列 | 説明・備考・文章 |
| 文字数 | 最大255文字 | 255文字を超える長文向け |
| Field Size | 1～255文字を設定可能 | 短いテキストと同じField Size指定ではない |
| 代表例 | 顧客名、住所、商品コード | 対応履歴、詳細説明、長文備考 |
| 使い分け | 検索・照合・キー的利用にも扱いやすい | 長い文章を保持したい場合に向く |
255文字を超える可能性があるなら長いテキストを検討
備考欄や問い合わせ内容のように、運用上255文字を超える可能性がある項目は長いテキストを検討します。最初は短文しか入っていなくても、将来の利用方法まで考えてデータ型を決めることが重要です。
ただし、既存の長いテキストを短いテキストへ変更すると、Microsoftの仕様上、255文字を超える部分が失われる可能性があります。すでにデータが入っているフィールドの型を変更するときは、事前にバックアップとデータ内容の確認を行います。
データ型を選ぶ簡単な判断フロー
| 質問 | YESの場合 | NOの場合 |
|---|---|---|
| その値を計算しますか？ | 数値型・通貨型等を検討 | 次の質問へ |
| 日付として期間検索や日付計算をしますか？ | 日付/時刻型を検討 | 次の質問へ |
| 255文字を超える文章になる可能性がありますか？ | 長いテキストを検討 | 短いテキストを検討 |
4. 短いテキスト型フィールドの作り方とField Sizeの設定
短いテキストはテーブルのデザインビューから簡単に設定できます。操作自体は数分で完了しますが、実務では「フィールド名」「データ型」「Field Size」をセットで考えることが重要です。
短いテキストを作成する5STEP
| STEP | 操作 | 確認ポイント |
|---|---|---|
| 1 | 対象テーブルをデザインビューで開く | 変更するテーブルを間違えない |
| 2 | 新しいフィールド名を入力する | 用途が分かる名称にする |
| 3 | データ型で「短いテキスト」を選択 | 数値型等と間違えない |
| 4 | フィールドプロパティのField Sizeを確認 | 1～255文字で必要な上限を設定 |
| 5 | 保存してデータシートビューで入力確認 | 想定文字数・形式で入力できるか確認 |
Field Sizeとは？
Field Sizeは、短いテキストフィールドに入力できる最大文字数を指定するプロパティです。1～255の範囲で設定できます。例えば固定長8文字の商品コードなら8、最大20文字の社員番号なら20など、業務ルールに合わせて決めます。
Microsoftは、必要十分な範囲で小さいField Sizeを指定することを推奨しています。ただし、短いテキストではField Sizeを255にしたからといって、すべてのレコードに255文字分の保存領域が固定で予約されるわけではありません。Field Sizeは「入力できる最大長」と考えると分かりやすいでしょう。
| 項目例 | Field Size例 | 考え方 |
|---|---|---|
| 郵便番号（ハイフンなし） | 7 | 業務ルールが7文字固定の場合 |
| 郵便番号（ハイフンあり） | 8 | 123-4567の形式で保存する場合 |
| 商品コード | 10～20など | 実際のコード体系＋将来拡張を考慮 |
| 電話番号 | 20など | 国番号・ハイフン等の運用を考慮 |
| 顧客名 | 50～100など | 実データと将来の最大長から決める |
| 実務視点 Field Sizeは「何となく255」にするより、コード体系・外部連携・将来のSQL Server移行まで含めて決める方が管理しやすくなります。一方で、短く設定しすぎると将来必要な値を保存できなくなるため、現行データだけでなく運用ルールも確認して設計します。 |
5. 短いテキストで覚えておきたいフィールドプロパティ
短いテキストでは、Field Size以外にも入力・表示・検索に関わるプロパティを設定できます。すべてを使う必要はありませんが、業務ルールをテーブル側へ反映しておくと、フォームやクエリでの入力ミスを減らしやすくなります。
| プロパティ | 役割 | 利用例 |
|---|---|---|
| Field Size | 最大文字数 | 社員番号を20文字までに制限 |
| Caption | 画面や帳票で使う表示名 | フィールド名CustomerNameを「顧客名」と表示 |
| Default Value | 新規レコードの初期値 | 区分に既定値を設定 |
| Format | 表示・印刷時の見せ方 | 表示形式を統一 |
| Input Mask | 入力時の形式をガイド・制御 | 郵便番号や電話番号の入力形式 |
| Validation Rule | 入力値の条件 | 特定の文字列パターン等を制御 |
| Validation Text | 規則違反時のメッセージ | 「指定形式で入力してください」 |
| Required | Nullを許可するか | 必須項目を設定 |
| Allow Zero Length | 空文字列 “” を許可するか | Nullと空文字を区別する設計 |
| Indexed | 検索用インデックス | 頻繁に検索するコードや一意キー候補 |
FormatとInput Maskは役割が違う
Formatは主に「どう表示するか」を決める設定です。一方、Input Maskは「どのような形式で入力させるか」を補助・制御する設定です。見た目だけを整えたいのか、入力そのものを一定形式にしたいのかで使い分けます。
ただし、入力マスクの設定によっては区切り文字をデータとして保存するかどうかも変わります。電話番号や郵便番号を他システムへ連携する場合は、画面表示だけでなく実際に保存される値まで確認したうえでルールを統一します。
RequiredとAllow Zero Lengthの違いにも注意
短いテキストでは「値がない状態」にNullと空文字列（””）があります。Requiredは主にNullを許可するかを制御し、Allow Zero Lengthはゼロ文字の文字列を許可するかを制御します。必須項目を設計する際は、この2つを混同しないことが大切です。
6. 短いテキストで失敗しやすいポイントと既存Access変更時の注意
短いテキストは扱いやすいデータ型ですが、設計判断を誤ると後から修正コストが大きくなることがあります。特に既存Accessでは、フィールドのデータ型がクエリ、フォーム、レポート、VBA、外部連携などから参照されている可能性があります。
失敗1｜数字に見えるコードを数値型にする
商品コードや社員番号を数値型にすると、先頭0や将来追加される英字を扱いにくくなる場合があります。計算しない識別値なら短いテキストを検討します。
失敗2｜すべてのField Sizeを255にする
動作するからといって、すべての項目を255文字にする必要はありません。業務ルールや外部連携仕様を確認し、必要な長さを設定します。
失敗3｜Field Sizeを小さくしすぎる
現在のデータだけを見て最小値にすると、将来のコード体系変更や長い氏名・住所が保存できなくなることがあります。余裕を含めて設計します。
失敗4｜長文を短いテキストに入れようとする
備考や対応履歴のように255文字を超える可能性があるデータは、長いテキストや別テーブル化を検討します。
失敗5｜データが入った状態で安易に型を変更する
Microsoftは、データ型変更によってデータが切り捨てられたり削除されたりする可能性があると案内しています。必ずバックアップと検証を行います。
失敗6｜テーブルだけ見て変更する
型変更はクエリ条件、結合、フォームのControl Source、VBA、CSV連携などへ影響する場合があります。依存箇所を確認してから変更します。
安全にデータ型・Field Sizeを変更する流れ
| STEP | 作業 | 確認内容 |
|---|---|---|
| 1 | バックアップ | 変更前のAccessファイルを保存 |
| 2 | 現行データ確認 | 最大文字数・Null・空文字・形式を調査 |
| 3 | 依存関係確認 | クエリ・フォーム・VBA・連携処理を確認 |
| 4 | コピー環境で変更 | 本番ファイルを直接変更しない |
| 5 | 変換後データ確認 | 切り捨て・変換エラー・先頭0等を確認 |
| 6 | 機能テスト | 検索・入力・帳票・連携を確認 |
| 7 | 本番反映 | 問題がなければ変更内容を記録して反映 |
| SQL Server移行を見据えるなら Access内で文字列長やコード体系が曖昧なままでも運用できてしまうことがあります。しかし、SQL Serverへアップサイジングする段階では、各列の型・長さ・Null可否などを改めて整理する必要があります。Access段階から意味のあるField Sizeと入力ルールを設定しておくと、移行設計を進めやすくなります。 |
まとめ｜データ型は「見た目」ではなく「用途」で決める
Accessの短いテキストは、最大255文字までの文字列を保存するための基本的なデータ型です。氏名、住所、電話番号、郵便番号、社員番号、商品コードなど、計算を目的としない比較的短い値に適しています。
重要なのは、数字だけで構成されているから数値型、文章だからすべて短いテキスト、という決め方をしないことです。計算するのか、識別するのか、255文字を超える可能性があるのか、外部システムとどう連携するのかを確認してデータ型を選びます。
また、Field SizeやRequired、Input Mask、Indexedなどのプロパティを業務ルールに合わせて設定すると、入力ミスや表記ゆれを減らしやすくなります。既存フィールドを変更するときは、データだけでなくクエリ・フォーム・VBAへの影響も含めて確認しましょう。
| そのAccess、データ型を「なんとなく」で決めていませんか？ Accessは柔軟なため、曖昧なテーブル設計でも一見動作してしまうことがあります。しかし、データ量や利用者が増えたり、SQL Serverへ移行したりすると、型・文字数・入力ルールの不整合が問題になることがあります。既存Accessのテーブル構造調査、データ型の整理、正規化、改修、SQL Serverアップサイジングまで対応していますのでお困りごとが御座いましたらお気軽にご相談ください。 |
よくある質問（FAQ）
最大255文字までの文字列を保存するためのデータ型です。氏名、住所、電話番号、商品コードなど比較的短い文字列に利用します。
最大255文字です。Field Sizeでは1～255の範囲で最大文字数を設定できます。
いいえ。Microsoftの現行仕様では「最大255文字」と説明されています。半角だけに限定した上限ではありません。
短いテキストに入力できる最大文字数を設定するプロパティです。例えば8文字固定のコードなら8など、業務ルールに合わせます。
動作上は可能ですが、すべて255にするのが最適とは限りません。コード体系や外部連携、将来拡張を確認して必要十分な長さを決めるのが基本です。
多くの場合は適しています。電話番号は計算せず、先頭0やハイフン、国番号の+などを文字として扱うためです。
識別値として扱うため、短いテキストが分かりやすいケースが一般的です。先頭0やハイフンも保持できます。
計算しない識別コードであれば短いテキストが適することが多いです。将来英字が入る可能性も考慮します。
短いテキストは最大255文字の比較的短い文字列向けです。255文字を超える文章や詳細な備考には長いテキストを検討します。
保存はできますが、文字列として扱われます。継続的に算術計算する値なら数値型等を使う方が適切です。
短いテキストなら「00123」を文字列として保持できます。コードや番号で先頭0が意味を持つ場合に有効です。
変更できる場合がありますが、内容が数値として変換可能である必要があります。既存データがある場合はバックアップと変換テストを行ってください。
可能ですが、Microsoftの仕様上、255文字を超える部分が失われます。実データを確認してから変更してください。
短いテキストならField Sizeで最大文字数を設定できます。さらに入力規則やフォーム側の設定を組み合わせる方法もあります。
文字列フィールドの長さ、Null可否、コード体系、インデックス、外部連携仕様を確認します。AccessでField Sizeが曖昧な場合は移行前に整理すると設計しやすくなります。
参考情報
Microsoft Support｜Data types for Access desktop databases
https://support.microsoft.com/en-US/Access/data-types-for-access-desktop-databases
Microsoft Support｜Introduction to data types and field properties
https://support.microsoft.com/en-us/office/introduction-to-data-types-and-field-properties-30ad644f-946c-442e-8bd2-be067361987c
Microsoft Support｜Access specifications
https://support.microsoft.com/en-us/access/access-specifications
Microsoft Support｜Set the field size
https://support.microsoft.com/en-us/office/set-the-field-size-ba65e5a7-2e6f-4737-8e72-36b93f966a33
Microsoft Support｜Modify or change the data type setting for a field
https://support.microsoft.com/en-us/access/modify-or-change-the-data-type-setting-for-a-field
Microsoft Support｜The Memo data type is now called Long Text
https://support.microsoft.com/en-us/access/the-memo-data-type-is-now-called-long-text