概要
| この記事の結論 Accessのテーブルでは、デザインビューの[入力規則]に条件式を設定し、[エラーメッセージ]に修正方法を入力します。単独の値はフィールドの入力規則、開始日と終了日の比較はテーブルのレコード入力規則を使います。未入力を禁止する場合は[値要求]も設定し、保存前の複雑な判定にはBeforeUpdateイベントを使います。 |
この記事でわかること
- 値の型と範囲を分けて設計する
- メッセージで修正方法を示す
- 未入力と空文字を区別する
- 既存データと別の入力経路も確認する
この記事の主な内容
- 入力規則を設定する場所と役割
- 数値の範囲とエラーメッセージを設定する手順
- 必須入力とNullと空文字を正しく扱う
- 日付の前後関係をレコード単位でチェックする
- フォームの保存前チェックとテーブルの制約を分担する
- 既存データの点検と安全なルール変更
- まとめ
- よくある質問
想定読了時間:約15分~20分
入力規則を設定する場所と役割
入力規則は、保存するデータに業務上の条件を付けるための機能です。数量に負の値を入れない、区分を決められた値から選ぶ、終了日を開始日以降にする、といった条件を設定できます。最初に「どの入力経路でも守る条件か」を考えると、設定場所を選びやすくなります。
例えば、フォームAでは数量の上限を守っていても、フォームBやCSV取込から不正な数量が入れば、集計結果は崩れてしまいます。画面での入力案内と、保存先のデータ制約を分けて設計することが大切です。
フィールドとレコードとフォームの違い
1項目の値を調べるのがフィールド入力規則、同じ行の複数項目を比較するのがレコード入力規則です。フォームのテキストボックスにも規則を設定できますが、その画面で使う条件として位置付けます。テーブルに設定した規則を、フォーム側で緩めることはできません。
| 設定場所 | 向いている条件 | 例 |
|---|---|---|
| テーブルのフィールド | 1項目の範囲や候補 | 数量は0〜999 |
| テーブル全体のレコード | 同じ行の項目間の関係 | 終了日は開始日以降 |
| フォームのコントロール | その画面固有の入力条件 | 受付画面だけの案内 |
| フォームのBeforeUpdate | 複数条件の案内や複雑な判定 | 不足項目を示して保存を中止 |

データ型や一意性の制約とは役割が違う
数値型は数値を扱うための型、入力規則はその数値に許す範囲です。値の重複を許さない条件は、主キーや一意なインデックスなどで設計します。存在する取引先だけを使う条件は、取引先マスターと参照整合性も含めて考えます。
「入力規則に何でも書く」という方針では、式が読みにくくなり、同時更新や別の入力経路への対応も難しくなります。何を保証したいかを言葉にしてから、データ型、必須、一意性、入力規則を使い分けましょう。
数値の範囲とエラーメッセージを設定する手順
最初の例として、数量に0〜999を許し、範囲外なら修正方法を表示する設定を作ります。ここでの0と999は説明用の値です。返品や取消で負数を使う業務なら、同じ規則をそのまま採用せず、正しい許容範囲を決めてください。
テーブルのフィールドプロパティを開く
説明用テーブルをT_入力確認、対象フィールドを数量とします。既存データへ設定する場合は、バックアップを取得し、現在の数量に範囲外の値がないか確認してから進めます。実データの例外を「入力ミス」と決め付けないことが重要です。
1. ナビゲーションウィンドウでT_入力確認を右クリックし、[デザインビュー]を開きます。
2. 「数量」の行を選択し、画面下部のフィールドプロパティを表示します。
3. [入力規則]に Between 0 And 999 を入力します。
4. [エラーメッセージ]に「数量は0〜999の範囲で入力してください。」と入力します。
5. 数量を必須にするなら[値要求]を[はい]にします。未入力を試す場合は、既定値が自動で0を補っていないかも確認します。
6. テーブルを保存し、データシートビューで正常値と範囲外の値を試します。

エラーメッセージは修正方法まで書く
[エラーメッセージ]は、入力規則に違反した場合の案内を指定するプロパティです。英語名はValidationTextです。単純な入力規則の案内であれば、メッセージを変えるためだけにVBAを書く必要はありません。
「入力エラーです」だけでは、利用者はどこを直すか判断できません。「数量は0〜999で入力してください」のように、対象項目と許される値を示します。例外を認める業務なら、その場で値を無理に変更させず、担当者への確認方法も用意します。
| 入力規則の例 | 許可する値の例 | 用途 |
|---|---|---|
| >=0 | 0、10、125 | マイナスを禁止 |
| >0 | 1、0.5などの正数 | ゼロも禁止 |
| Between 0 And 999 | 0、100、999 | 上限と下限を含む範囲 |
| In (1,2,3) | 1、2、3 | 数値コードの候補を限定 |
| In (“未着手”,”対応中”,”完了”) | 指定した文字列 | 小規模で固定の状態値 |
表の数値例は、保存先のデータ型でも表現できることが前提です。例えば整数型へ小数を入力したときは、型変換による丸めが関係する場合があります。「入力した小数を必ずエラーにしたい」という要件は、変換前の入力チェックも含めて別に確認してください。
候補が頻繁に増減するなら、入力規則へ候補を直接並べ続けるより、マスターテーブルと選択用コンボボックスを使うほうが更新箇所を整理しやすくなります。入力規則は、候補一覧を管理するための万能な仕組みではありません。
境界の値を実際に試す
0〜999という範囲なら、0と999は許可し、-1と1000は拒否することを確認します。100だけを入力して成功したとしても、境界が正しいかは分かりません。フォームからも同じ値を試し、保存先に同じ規則が働くか確認します。

必須入力とNullと空文字を正しく扱う
必須入力は[値要求]、空文字の許可は[空文字列の許可]で考えます。どちらも空欄に見える場合がありますが、Nullと空文字列は同じものではありません。「空欄を認めるか」という業務条件を、保存値の違いに分けて定義します。
Nullと空文字とゼロを区別する
Nullは値がない状態、空文字列は長さ0の文字列、0は数値です。例えば在庫数量の0は「在庫がないと確認済み」、Nullは「数量がまだ分からない」と使い分けることがあります。未入力をすべて0へ変えると、この違いが失われます。
| 状態 | 意味 | 確認に使う式の例 |
|---|---|---|
| Null | 値が入っていない | Is Null |
| 空文字列 | 文字数が0の文字列 | =”” |
| 数値の0 | ゼロという値 | =0 |
| 半角スペースだけ | 空文字ではなく空白文字がある | Trimなどで別途確認 |

必須の文字欄は空文字も確認する
氏名などの必須欄では、値要求を[はい]にするだけでなく、短いテキスト型などの[空文字列の許可]も確認します。Nullと空文字列を両方禁止したいなら、値要求を[はい]、空文字列の許可を[いいえ]にする方針です。
ただし、スペースだけの入力はさらに別の問題です。半角スペース、全角スペース、タブなどをどこまで無効とするかを決め、必要ならフォームで入力を案内します。Trimだけですべての種類の空白を同じように扱えると考えないようにしましょう。
任意入力の数値フィールドで空欄を認める場合は、値要求を[いいえ]にし、規則にも Between 0 And 999 Or Is Null のようにNullを認める条件を明示します。必須条件と式を別々に確認すると、仕様を読み取る人にも意図が伝わります。
既定値で必須チェックを隠さない
数量に既定値0があると、利用者が数量を入力しなくても0が入ります。「必須にしたのに入力せず保存できる」というときは、Nullのままではなく、既定値が補われていないか確認してください。
数量を必ず本人に確認してもらうなら、既定値を設けずに入力を促す方法が考えられます。一方、初期在庫0が正しい業務なら、0を補う設計にも意味があります。入力の手間と確認の必要性を比較して決めましょう。
日付の前後関係をレコード単位でチェックする
開始日と終了日の比較は、テーブル全体に設定するレコード入力規則で行います。フィールド入力規則では、別のフィールドを参照する条件は使えません。同じテーブルの同じ行にある項目の関係は、レコード側へまとめます。[2]
テーブル全体のプロパティへ設定する
T_予約に開始日と終了日があり、両方とも日付/時刻型、値要求が[はい]である例を考えます。テーブルのデザインビューでプロパティシートを開き、テーブル全体の入力規則に次の式を設定します。フィールドの行を選んだときの下部プロパティとは場所が違います。
[終了日]>=[開始日]
エラーメッセージは「終了日は開始日以降を入力してください。」とします。開始日と終了日が同じ場合を許可するので >= を使います。同日を許さない要件なら比較演算子を変更しますが、日付に時刻を含めるのかも先に確認してください。

終了日未定を許す場合は条件を分ける
開始日は必須、終了日は未定でもよい場合は、開始日の値要求を[はい]、終了日の値要求を[いいえ]にします。そのうえで、例えば次のレコード入力規則を使い、終了日が入っているときだけ前後関係を確認します。
[終了日] Is Null Or [終了日]>=[開始日]
この例は、開始日が必ずあるという前提で成り立ちます。両方を任意にしたい、終了日だけ先に入る場合がある、といった別の業務では、その組み合わせごとに許可・拒否を決め直してください。
| 開始日 | 終了日 | 両方必須の場合の期待結果 |
|---|---|---|
| 2026/09/01 | 2026/09/30 | 保存を許可 |
| 2026/09/01 | 2026/09/01 | 同日を許可 |
| 2026/09/30 | 2026/09/01 | 前後逆転を拒否 |
| 未入力 | 2026/09/30 | 開始日の入力を要求 |
| 2026/09/01 | 未入力 | 終了日の入力を要求 |
営業日数や休日を参照する条件は、単純な2項目の比較とは異なります。テーブルの入力規則には利用できる式の制約があり、別テーブルへの参照やユーザー定義関数を自由に書けるわけではありません。必要な判定を適切な処理へ分担します。
フォームの保存前チェックとテーブルの制約を分担する
共通の制約はテーブルで守り、フォームでは修正しやすい案内を追加します。保存を止める必要があるVBAは、更新前のBeforeUpdateを使います。AfterUpdateは更新後の処理なので、「メッセージを出したから保存も止まった」と判断してはいけません。
単純な案内はエラーメッセージから整える
まず入力規則のエラーメッセージを見直してください。範囲外、必須、日付の逆転といった条件なら、標準のプロパティで十分な場合があります。コードが増えるほど、テーブルの規則と文言がずれていないか確認する箇所も増えます。
画面によって案内文を変える、複数の不足項目をまとめて示すなどの要件があるときに、VBAを検討します。既存のイベントプロシージャがある場合は、同じイベントを重複作成したり、従来の処理を消したりせず、内容を整理して組み込みます。
フォームの保存前にチェックするVBA例
次の例は、F_予約にtxt開始日とtxt終了日があり、両方が日付/時刻型フィールドへ連結されている前提です。フォーム全体の[更新前処理]を[イベント プロシージャ]に設定し、そのフォームモジュールへ記述します。
Private Sub Form_BeforeUpdate(Cancel As Integer)
If IsNull(Me!txt開始日) Then
Cancel = True
MsgBox “開始日を入力してください。”, vbExclamation
Me!txt開始日.SetFocus
Exit Sub
End If
If IsNull(Me!txt終了日) Then
Cancel = True
MsgBox “終了日を入力してください。”, vbExclamation
Me!txt終了日.SetFocus
Exit Sub
End If
If Me!txt終了日 < Me!txt開始日 Then
Cancel = True
MsgBox “終了日は開始日以降にしてください。”, vbExclamation
Me!txt終了日.SetFocus
End If
End Sub
CancelをTrueにすると、この更新を取り消します。入力済みの内容を一律に消すコードは入れず、利用者が修正して再度保存できるようにしています。実際の画面では対象欄が表示・使用可能であることも確認します。
この処理はフォーム経由の保存が対象です。テーブルを直接編集する操作や別のプログラムからの更新を、同じフォームイベントがすべて検査するわけではありません。また、規則違反の種類によってAccess標準のチェックが先に働く場合もあるため、実際に表示される案内を確認してください。

SQL Serverなどのリンク先は保存先でも守る
外部DBのリンクテーブルでは、Accessローカルテーブルと同じ方法でフィールドやレコードの入力規則を設定できるとは限りません。Microsoftは、外部で作られたテーブルではAccess側のコントロールに規則を設定する方法を説明しています。
共通のデータをほかのアプリも更新するなら、SQL Serverなどの保存先で、NOT NULL、CHECK制約、外部キーなど必要な仕組みを設計します。Accessのフォームだけを直しても、別の経路からの不整合が解決するとは限りません。
入力規則とデータ不整合の改善を相談する
設定を見直しても解消しない場合や、複数のフォーム・保存先への影響が分からない場合は、対象画面と再現手順を整理してご相談ください。
既存データの点検と安全なルール変更
既存テーブルへ規則を追加する前に、現在のデータを点検します。規則を設定しても、過去の不適合データが自動的に正しい値へ変わるわけではありません。入力の失敗と、従来から存在する例外を分けて確認する必要があります。[1]
まず違反候補の一覧を確認する
数量を0〜999の必須値へ変える前なら、次の選択クエリで確認対象を抽出できます。これは一覧を表示するSQLで、データの削除や更新は行いません。実際のテーブル名と主キー名に合わせて使います。
SELECT [入力ID], [数量]
FROM [T_入力確認]
WHERE [数量] Is Null
OR [数量] < 0
OR [数量] > 999;
抽出された値について、入力ミスなのか、返品や特別受注など正当な例外なのかを確認します。例外が正しいなら、元の規則案そのものを見直す必要があります。「新ルールに合わない」という理由だけで、値を0や上限へ丸めてはいけません。

規則を適用して既存データを検証する
修正方針を決めたら検証用コピーへ規則を設定し、Accessの既存データに対する検証機能も使います。テーブルのリボンにある[入力規則]関連のメニューから、規則のテストを実行できる環境があります。表示名は使用する版で確認してください。
次に、本番へ反映するタイミングを決めます。共有利用中にテーブルの設計を変更すると、利用者が作業を続けられないことがあるため、利用を止める時間とバックアップを調整します。分割DBでは、フォームを配布するファイルと、データを持つファイルを取り違えないようにします。
入力経路ごとに結果を確認する
フォーム、テーブル直接入力、既存テーブルへの取込、追加クエリなど、実際に使っている経路から試します。取込時に規則が働いても、一部のレコードだけが取り込まれる場合を考え、エラー一覧と取込前後の件数を突き合わせてください。
| 確認対象 | 見ること |
|---|---|
| 新規入力 | 必須値と境界値が期待どおりか |
| 既存レコードの編集 | 過去の不適合値で編集不能にならないか |
| フォーム | 修正すべき項目が利用者に分かるか |
| CSVやExcelからの取込 | 失敗行、成功行、合計件数が一致するか |
| 外部DBへの更新 | 保存先の制約と画面の案内が整合するか |
| 規則を戻す場合 | 新たに入ったデータも含めて扱いを決めたか |

規則の記録には「式」だけでなく、「その条件が必要な理由」と「例外の扱い」も残します。担当者が替わったときに、なぜ負数を禁止したのか、なぜ終了日未定を認めたのかが分かれば、安易な解除や誤った修正を防ぎやすくなります。
まとめ
Accessの入力規則は、条件を設定する場所と、保存する値の意味を揃えて使います。単独項目はフィールド、同じ行の前後関係はレコードで検証し、分かりやすいエラーメッセージを付けます。
必須入力は値要求、空文字は空文字列の許可を確認します。複雑な保存前チェックはBeforeUpdateで補い、既存データと複数の入力経路を検証してから適用することが、長く運用できるルール作りにつながります。
入力規則とデータ不整合の改善を相談する
Accessの教科書では既存Accessの調査・改修・保守をご相談いただけます。フォーム名、症状、発生する操作、変更した設定が分かると、確認すべき範囲を整理しやすくなります。
よくある質問
入力規則は、保存する値に許す条件を指定します。定型入力は、入力する文字の形式を揃えるための仕組みです。日付の大小関係や数量の上限は、入力規則で考えます。
Nullを禁止するには値要求を[はい]にします。文字列の欄では空文字列の許可も確認し、空白文字だけの入力を認めるかも別に決めます。
テーブルの規則に違反する値を、フォーム側の規則だけで許可することはできません。共通ルールを変更するなら、保存先とほかの入力経路への影響も確認します。
自動修正されません。不適合の候補を抽出し、業務上の意味を確認したうえで修正や例外処理を決めてください。
保存前に拒否したい条件はBeforeUpdateで判定し、必要に応じてCancelをTrueにします。更新後にメッセージを表示するだけでは、保存中止にはなりません。
Accessローカルテーブルと同じ制約を設定できると考えないでください。フォームでの案内に加え、保存先のDBでも必要な制約を設計します。
参考情報
[1] Restrict data input by using validation rules 参照内容:入力規則の種類と既存データの検証
https://support.microsoft.com/en-us/access/restrict-data-input-by-using-validation-rules
[2] TextBox.ValidationRule 参照内容:式の制約とエラーメッセージ
https://learn.microsoft.com/en-us/office/vba/api/access.textbox.validationrule
[3] Require a value in a field 参照内容:値要求
https://support.microsoft.com/en-us/access/require-a-value-in-a-field
[4] Form.BeforeUpdate event 参照内容:保存前の取消
https://learn.microsoft.com/en-us/office/vba/api/access.form.beforeupdate-event
[5] Introduction to data types and field properties 参照内容:データ型と空文字
https://support.microsoft.com/en-us/access/introduction-to-data-types-and-field-properties