概要
Microsoft Accessのフォームは、テーブルやクエリに保存・抽出されたデータを、利用者が見やすく入力・編集・検索するための画面です。フォーム自体に業務データを保存するのではなく、テーブルやクエリをレコードソースとして利用し、テキストボックス、コンボボックス、ボタンなどのコントロールを配置して操作画面を作ります。単票・複数アイテム・分割・サブフォームなど用途に応じた形式があり、VBAやマクロを組み合わせれば検索や登録処理も自動化できます。本記事では、フォームの仕組み、種類、3つのビュー、レコードソース/コントロールソース、主要コントロール、基本的な作り方から、実務で入力ミスを減らす画面設計まで体系的に解説します。
この記事でわかること
この記事を読むと、Accessフォームがデータベースの中でどのような役割を持つのか、テーブル・クエリとの違い、単票・複数アイテム・分割・サブフォームなどの使い分け、フォームビュー・レイアウトビュー・デザインビューの違い、レコードソースとコントロールソースの仕組み、テキストボックスやコンボボックスなど主要コントロール、そして実務用の入力画面を作る際に注意したい設計ポイントまで理解できます。
- フォームとテーブル・クエリの役割の違い
- フォームに入力したデータがどこへ保存されるのか
- 単票・複数アイテム・分割・サブフォームの使い分け
- フォームビュー・レイアウトビュー・デザインビューの違い
この記事の主な内容
1.Accessのクエリとは?まず30秒でテーブルとの違いを理解しよう
2.クエリでできる6つのこと
3.Accessのクエリにはどんな種類がある?
4.データシートビュー・デザインビュー・SQLビューの違い
5.選択クエリを作ってみよう|東京都の顧客を抽出
6.クエリを実務で使うときの注意点
7.まとめ
8.よくある質問(FAQ)
想定読了時間:約15~20分
Accessのフォームとは?まず30秒でテーブル・クエリとの違いを理解しよう
Accessのフォームとは、利用者がデータを表示・入力・編集・検索・操作するための画面です。Accessで業務システムを作る場合、利用者が最も多く触れるオブジェクトの一つがフォームです。
ただし、ここで重要なのは「フォーム自体が顧客情報や受注情報を保存しているわけではない」という点です。業務データの実体はテーブルに保存され、フォームはテーブルやクエリを通してそのデータを見せたり更新したりします。

| オブジェクト | 主な役割 | 例 |
| テーブル | データそのものを保存する | 顧客テーブル、受注テーブル |
| クエリ | 必要なデータを抽出・結合・計算・集計する | 東京都顧客、未処理受注 |
| フォーム | 利用者がデータを見て入力・編集・操作する | 顧客入力画面、検索画面 |
| レポート | 一覧・帳票として整形・印刷する | 顧客一覧、請求書 |
フォームに入力したデータはどこへ保存される?
例えば顧客入力フォームで顧客名や電話番号を入力した場合、フォームの各入力欄が顧客テーブルのフィールドへ連結されていれば、入力した値は顧客テーブルへ保存されます。
フォームを閉じたからデータが消えるわけではなく、フォームはあくまでデータへアクセスするための画面です。

なぜテーブルへ直接入力せずフォームを使うのか
テーブルへ直接入力する方が簡単に見えることもあります。しかし、業務利用ではフォームを使うことで、利用者に見せる項目を絞り、入力方法を統一し、誤操作を防ぎやすくなります。
- 必要な項目だけを分かりやすい順番で配置できる
- コンボボックスで選択式入力にできる
- ボタンから検索・登録・印刷などの処理を実行できる
- 削除や更新など危険な操作に確認処理を入れられる
- IDや内部管理項目を利用者から隠せる
- 利用者ごとに操作できる機能を分ける設計もできる
| フォームは『見た目』だけではなく業務ルールの入口 |
| 良いフォームは、単にきれいな画面ではありません。利用者が間違った値を入力しにくく、必要な処理へ迷わず進めるように設計された業務インターフェースです。Accessの使いやすさはフォーム設計によって大きく変わります。 |
連結フォームと非連結フォーム
Accessのフォームは、データソースとのつながり方で大きく「連結フォーム」と「非連結フォーム」に分けて考えることができます。
| 種類 | 特徴 | 主な用途 |
| 連結フォーム | テーブルやクエリをレコードソースに持ち、各コントロールがフィールドに連結される | 顧客入力、受注入力、マスタ編集 |
| 非連結フォーム | 特定のレコードソースを持たず、コントロールへ値を入力して処理に利用する | 検索条件入力、メニュー、処理実行画面 |
実務では、顧客登録画面は連結フォーム、検索条件を入力して検索ボタンを押す画面は非連結フォーム、といった使い分けがよくあります。
Accessフォームの種類|単票・複数アイテム・分割・サブフォームをどう使い分ける?
フォームは用途によって表示形式を使い分けます。初心者はまず単票フォームを理解し、その後に一覧・分割・サブフォームへ進むと分かりやすくなります。

単票フォーム|1件ずつ詳しく表示・入力する
1レコードを1画面に表示するフォームです。顧客情報、社員情報、案件詳細など、1件の情報を詳しく確認・入力するときに向いています。
フォームツールから作成する基本フォームも、通常は1レコードずつ表示する形式です。
複数アイテム/連続フォーム|複数レコードを一覧表示する
複数のレコードを縦に並べて表示するフォームです。検索結果一覧、顧客一覧、案件一覧などに向きます。
見た目はデータシートに近くできますが、ボタンや色分けなどを加えられるため、一覧画面として柔軟に作り込めます。
分割フォーム|一覧と詳細を同時に見る
1つのフォーム内に、データシート形式の一覧と単票形式の詳細を同時に表示する形式です。
一覧から対象レコードを選び、その内容を詳細側ですぐ確認・編集したい場合に便利です。
メインフォーム+サブフォーム|1対多のデータを1画面で扱う
フォームの中に別のフォームを配置する構成です。典型例は「受注」と「受注明細」です。
上部のメインフォームに受注日・顧客など1件分の受注情報を表示し、下部のサブフォームにその受注に含まれる商品明細を複数行表示できます。

ナビゲーション/メニューフォーム|システムの入口にする
Accessを業務システムとして利用する場合、起動後にテーブルやクエリを直接見せるのではなく、メニューフォームから各機能へ移動させる設計がよく使われます。
「顧客管理」「受注登録」「帳票出力」「マスタ管理」のように機能を整理すれば、利用者はAccess内部のオブジェクト構造を意識せず業務を進められます。
| フォーム形式 | 向いている用途 | 代表例 |
| 単票 | 1件を詳しく見る・入力する | 顧客詳細、案件詳細 |
| 複数アイテム/連続 | 複数件を一覧で確認 | 検索結果、一覧画面 |
| 分割 | 一覧と詳細を同時表示 | 顧客一覧+詳細 |
| メイン+サブ | 1対多データを同時編集 | 受注+受注明細 |
| ナビゲーション/メニュー | システム機能の入口 | メインメニュー |
フォームビュー・レイアウトビュー・デザインビューの違い
Accessのフォームを理解するときは、利用者が操作する画面と、開発者が設計する画面を区別することが重要です。Microsoft Accessでは、フォームビュー、レイアウトビュー、デザインビューを用途に応じて使い分けます。

| ビュー | 主な用途 | 特徴 |
| フォームビュー | 利用者が入力・検索・操作 | 通常業務で使う画面 |
| レイアウトビュー | データを見ながらサイズ・配置調整 | 実データを表示した状態でデザイン変更可能 |
| デザインビュー | 構造・プロパティ・イベントを詳細設定 | フォームは実行状態ではなく、セクションや各種設定を確認 |
フォームビュー|利用者が実際に操作する
フォームビューは、利用者がデータを入力したり、ボタンを押したり、レコードを移動したりする通常の操作画面です。
利用者に列幅やレイアウトを自由に変更させず、開発側が決めた操作方法に統一できるため、業務画面として使いやすくなります。
レイアウトビュー|データを見ながら見た目を調整する
レイアウトビューでは、フォームを実行して実データを表示した状態のまま、テキストボックスの大きさや位置などを調整できます。
Microsoftのフォームツールでフォームを作ると、作成後はレイアウトビューで表示されるため、初心者にも使いやすいビューです。
デザインビュー|詳細な構造を設計する
デザインビューでは、フォームヘッダー、詳細、フォームフッターなどのセクションや、コントロール、プロパティ、イベントを細かく設定できます。
フォームが実行状態ではないため実データを見ながら編集する画面ではありませんが、複雑なフォームやVBAイベントを作る際に重要です。
フォームのセクション
| セクション | 役割 | よく配置するもの |
| フォームヘッダー | フォーム上部に固定表示 | タイトル、検索条件、説明 |
| 詳細 | レコードごとの内容を表示 | 顧客名、住所、受注日など |
| フォームフッター | フォーム下部に固定表示 | 登録、閉じる、印刷等のボタン |
フォームを作るコントロールとは?レコードソースとの関係も解説
フォーム上に配置するテキストボックス、ラベル、コンボボックス、ボタンなどの部品を「コントロール」と呼びます。
フォームを本当に理解するためには、見た目の部品名だけでなく、「フォームのレコードソース」と「コントロールのコントロールソース」の関係を知ることが重要です。

レコードソースとは?
レコードソースは、そのフォームがどのデータ集合を表示・編集するかを決める設定です。テーブル名、保存クエリ、SQL文などを指定できます。
例えば顧客入力フォームのレコードソースを「顧客テーブル」にすれば、フォームは顧客テーブルのレコードを表示・編集します。検索条件や複数テーブルの結合が必要なら、クエリをレコードソースにすることもあります。
コントロールソースとは?
コントロールソースは、フォーム上の各コントロールがどのフィールドや計算式を表示するかを決める設定です。
例えばフォームのレコードソースに顧客テーブルを指定し、テキストボックス「txt顧客名」のコントロールソースを「顧客名」にすると、そのテキストボックスには現在の顧客レコードの顧客名が表示されます。
| 用語 | 何を決める? | 例 |
| レコードソース | フォーム全体が扱うレコード集合 | 顧客テーブル、Q_顧客一覧 |
| コントロールソース | 各コントロールが表示・編集するフィールドや式 | 顧客名、電話番号、=[数量]*[単価] |
連結・非連結・演算コントロール
| 種類 | 特徴 | 例 |
| 連結コントロール | テーブル/クエリのフィールドに連結される | 顧客名入力欄 |
| 非連結コントロール | 特定フィールドに連結されない | 検索キーワード入力欄 |
| 演算コントロール | 式の計算結果を表示する | 数量×単価、合計金額 |
主要なコントロール

| コントロール | 主な用途 | 実務例 |
|---|---|---|
| テキストボックス | 文字・数値・日付の表示/入力 | 顧客名、電話番号、金額 |
| ラベル | 固定文字を表示 | 項目名、注意書き、タイトル |
| コンボボックス | 候補をプルダウン選択 | 担当者、商品、区分 |
| リストボックス | 候補一覧から選択 | 検索結果、少数の選択肢 |
| チェックボックス | Yes/Noの選択 | 有効、対応済み |
| コマンドボタン | 処理を実行 | 検索、登録、印刷、閉じる |
| サブフォーム | 別フォームを埋め込む | 受注明細、案件履歴 |
コンボボックスでIDを安全に選択する
担当者IDや商品IDを利用者に直接入力させると、存在しないIDや入力ミスが発生しやすくなります。コンボボックスを使えば、画面上は「田中太郎」「商品A」と分かりやすい名称を見せつつ、内部では担当者ID・商品IDを保存する設計ができます。
これはAccessフォームを業務システムとして使う際の重要なメリットです。
顧客入力フォームを作ってみよう|初心者向け7STEP
ここでは、顧客テーブルを元に基本的な顧客入力フォームを作る流れを確認します。

STEP1|元になる顧客テーブルを準備する
| フィールド | データ型 | 用途 |
| 顧客ID | オートナンバー | 主キー |
| 顧客名 | 短いテキスト | 顧客名称 |
| フリガナ | 短いテキスト | 検索・並べ替え |
| 電話番号 | 短いテキスト | 連絡先 |
| メールアドレス | 短いテキスト | メール |
| 住所 | 短いテキスト | 所在地 |
| 登録日 | 日付/時刻 | 登録日時 |
STEP2|ナビゲーションウィンドウで顧客テーブルを選択する
フォームの元にしたい顧客テーブルを選択します。クエリを元にフォームを作る場合は、そのクエリを選択します。
STEP3|[作成]タブから[フォーム]をクリックする
Accessが選択したテーブルまたはクエリを元にフォームを自動作成し、通常はレイアウトビューで表示します。Microsoftのフォームツールでは、元データソースのフィールドがフォームへ自動配置されます。
STEP4|必要な項目だけを残し、配置を調整する
自動作成されたフォームをそのまま本番利用するのではなく、業務上必要な項目へ絞り、利用者が入力する順番に配置します。
顧客IDのように利用者が変更すべきでない項目は編集不可にしたり、画面上で目立たなくしたりすることを検討します。
STEP5|入力しやすいコントロールへ変更する
担当者や区分など決まった選択肢がある項目はコンボボックスへ変更します。日付は日付型として扱い、必要に応じて既定値や入力規則を設定します。
入力項目の色、必須表示、説明ラベルなども統一すると、利用者が迷いにくくなります。
STEP6|フォームビューで入力・更新テストを行う
新規レコードを登録し、テーブルへ正しく保存されるか確認します。また既存レコードを変更し、意図したフィールドだけが更新されるか確認します。
Tabキーによる入力順、必須項目、コンボボックスの候補、ボタンの動作も確認します。
STEP7|分かりやすいフォーム名で保存する
「Form1」のままではなく、目的が分かる名前を付けます。
| 避けたい名前 | 分かりやすい例 |
| Form1 | F_顧客入力 |
| フォーム2 | F_顧客検索 |
| test | F_受注登録 |
| 画面1 | F_メインメニュー |

実務で使いやすいフォーム設計のポイント|入力ミス・誤操作・保守性を改善する
業務用のAccessフォームでは、情報が表示できれば完成というわけではありません。利用者が迷わず、間違いにくく、担当者が変わっても保守できることが重要です。
1. 画面にすべてのフィールドを表示しない
テーブルに30項目あるからといって、30項目すべてを1画面へ並べる必要はありません。利用頻度や業務の流れでグループ化し、必要であればタブや別フォームへ分けます。
2. 入力できるものは選択式にする
担当者、商品、部署、ステータスなど候補が決まっている項目は、自由入力ではなくコンボボックス等で選択させる方が表記揺れや入力ミスを防ぎやすくなります。
3. Tabキーの移動順を業務の入力順にする
キーボード中心で入力する業務では、Tabキーで項目を移動する順番が作業効率へ直結します。見た目だけでなくタブオーダーまで確認しましょう。
4. 削除・確定など危険なボタンは確認を入れる
「削除」「一括更新」「確定」など取り消しが難しい操作は、ボタンを押しただけで即時実行しない設計が安全です。確認メッセージ、対象件数の確認、権限チェックなどを組み合わせます。
5. フォームのレコードソースは『更新できるか』まで考える
複数テーブルを結合したクエリをフォームのレコードソースにすると便利ですが、クエリ構造によってはフォームから編集できない場合があります。
表示専用フォームなのか、入力・編集フォームなのかを先に決め、更新が必要なら更新可能性を確認してレコードソースを設計します。
6. VBAへ処理を集中させすぎない
フォームイベントへ大量のVBAを書けば、多くの処理を実現できます。しかし、標準機能、クエリ、入力規則、マクロ等で簡潔に実現できる処理までVBA化すると、将来の改修が難しくなることがあります。
フォーム、クエリ、VBA、テーブルのどこへ責務を持たせるかを整理することが、保守性の高いAccessにつながります。
7. コントロール名を分かりやすくする
既定の「テキスト23」「コマンド15」のままVBAを書くと、後からコードを読んでも役割が分かりません。例えば顧客名テキストボックスなら「txt顧客名」、検索ボタンなら「btn検索」のように、一定の命名規則を持たせると保守しやすくなります。

| よくある問題 | 起こりやすいこと | 改善例 |
| 項目が多すぎる | 入力場所が分からない・ミスが増える | 業務単位で整理しタブ・別画面へ分割 |
| IDを直接入力 | 存在しない値・誤入力 | コンボボックスで名称から選択 |
| 自由入力が多い | 表記揺れ・集計不能 | マスタ選択式にする |
| 削除ボタンが即実行 | 誤削除 | 確認画面・権限制御 |
| 更新不可クエリを使用 | フォームで編集できない | レコードソースを再設計 |
| VBAが各イベントに分散 | 改修影響が追えない | 共通化・標準機能・クエリを活用 |
| コントロール名が既定 | コードが読みにくい | 命名規則を統一 |
複数人で使う場合はフォームだけでなくDB構成も確認する
複数人でAccessを利用する場合、使いやすいフォームを作るだけでは不十分です。フロントエンド/バックエンド分割、レコードロック、ネットワーク環境、データ量なども考慮する必要があります。
利用人数やデータ量が増えた場合は、Accessのフォームを残しながらバックエンドをSQL Serverへ移行する構成も選択肢になります。
| そのAccess、利用者にとって使いやすい画面になっていますか? |
| テーブルへ直接入力している、入力ミスが多い、検索しづらい、画面に項目が多すぎる、ボタンの役割が分からない、前任者しか操作できない――こうした課題は、フォーム・クエリ・テーブル・VBAを含めて画面設計を見直すことで改善できる場合があります。 Accessの新規フォーム開発、既存画面のUI改善、検索画面・入力画面・サブフォームの改修から、SQL Serverへの拡張まで対応しておりますのでお気軽にご相談ください。 |
まとめ|Accessフォームは利用者とデータベースをつなぐUI
Accessのフォームは、単なる見た目を作る機能ではありません。テーブルやクエリのデータを、利用者が安全かつ効率的に扱うためのユーザーインターフェースです。
- フォーム自体は原則として業務データの保存場所ではない
- テーブルやクエリをレコードソースとして利用する
- 各コントロールはフィールドや式をコントロールソースとして利用する
- 単票・複数アイテム・分割・サブフォームを用途で使い分ける
- フォームビュー・レイアウトビュー・デザインビューは役割が異なる
- コンボボックスやボタンを使うことで入力ミスや誤操作を減らせる
- VBAだけに頼らず、テーブル・クエリ・フォームの役割を整理して設計する
初心者はまず単票の入力フォームを1つ作り、フォームとテーブルのデータがどのようにつながっているかを確認してみましょう。その後、検索フォーム、コンボボックス、サブフォーム、VBAへ進むと、Accessを業務システムとして活用する仕組みが理解しやすくなります。
よくある質問(FAQ)
テーブルやクエリのデータを、利用者が見やすく表示・入力・編集・検索・操作するためのユーザーインターフェースです。
連結フォームの場合、フォームのレコードソースとなっているテーブルや、更新可能なクエリの元テーブルへ保存されます。
テーブルはデータそのものを保存する場所、フォームはそのデータを利用者が操作するための画面です。
クエリはデータを抽出・結合・計算・集計する処理、フォームはそのデータを人が見る・入力するための画面です。
単票フォームは1レコードずつ詳しく表示し、複数アイテムフォームは複数レコードを一覧形式で表示します。
レイアウトビューは実データを表示しながら配置やサイズを調整でき、デザインビューはフォームの構造・セクション・プロパティ・イベントを詳細に設定できます。
フォーム全体がどのテーブル・クエリ・SQLのレコードを表示・編集するかを決める設定です。
テキストボックスなど各コントロールが、どのフィールドや計算式を表示するかを決める設定です。
フォームの中に別のフォームを表示する機能です。受注と受注明細など、1対多の関連データを1画面で扱う際によく使います。
レコードソースとなるクエリが更新不可、フォームの編集許可プロパティが無効、フィールドが読み取り専用など複数の原因が考えられます。
はい。基本的なデータ表示・入力・コンボボックス・フォーム作成はVBAなしでも可能です。複雑な検索や自動処理が必要になった段階でVBAやマクロを検討します。
参考資料・確認ソース
Microsoft Support:Introduction to forms
https://support.microsoft.com/en-us/access/introduction-to-forms
Microsoft Support:Create a form in Access
https://support.microsoft.com/en-us/access/create-a-form-in-access
Microsoft Support:Create a form by using the Form tool
https://support.microsoft.com/en-us/access/create-a-form-by-using-the-form-tool