概要
| この記事の結論 Accessの入力フォームなら、候補の一覧を一つのマスターテーブルで管理し、利用者には同じ選択画面を提供できます。名前を表示してIDを保存する設計にすると、表記揺れや候補の修正漏れも減らせます。ただし、候補の追加だけが悩みならExcelのテーブル参照でも改善可能です。移行前に、入力人数、変更頻度、過去データの扱いを整理しましょう。 |
この記事でわかること
- Excelで直せる問題とAccessへ移す判断
- 候補マスターと入力データを分ける
- 名前を表示してIDを保存するコンボボックス
- 候補の追加と廃止を安全に運用する
- 連動する選択肢と入力エラーを整える
この記事の主な内容
- Excelで直せる問題とAccessへ移す判断
- 候補マスターと入力データを分ける
- 名前を表示してIDを保存するコンボボックス
- 候補の追加と廃止を安全に運用する
- 連動する選択肢と入力エラーを整える
- Excelから移す前後の確認と共同利用
- 小さく導入して運用を定着させる
- よくある質問
想定読了時間：約15分～20分
Excelで直せる問題とAccessへ移す判断
プルダウンの維持が面倒でも、すぐにAccessへ移す必要はありません。まず、候補を各セルへ直接書いているのか、共通の一覧を参照しているのかを確認します。候補をExcelテーブルにまとめ、その一覧を利用するドロップダウンへ変更すると、候補追加のたびに多数のセルを直す運用を改善できます。［参考3］
ただし、候補の追加と入力先の行追加は別の問題です。候補一覧が更新されても、入力先で規則が外れたセルや、別の範囲を参照するセルが残っていれば統一できません。新しい行、コピー貼り付け、複製したシートの三つで、実際に同じ候補が出るかを確かめてください。
| 状況 | 先に試す方法 | Accessが有効になる条件 |
|---|---|---|
| 候補が少なく担当者も固定 | Excelの候補テーブルと入力規則 | 複数の台帳で同じ候補を共有したい |
| 毎月候補を追加する | 共通の候補参照と管理者の明確化 | 名称変更や廃止を一元管理したい |
| 入力が複数部署にまたがる | 入力項目とルールの整理 | 入力画面と保存データを分けたい |
| スマートフォンでも入力したい | Webフォーム等も比較 | Access単体のデスクトップ利用では要件に合わない |
Accessへ移す目的は、ドロップダウンを付けること自体ではありません。「誰が候補を変え、どの画面へ反映し、過去の記録をどう残すか」を一つの運用にすることです。この管理が必要なら、フォームとテーブルを分ける利点が大きくなります。
候補マスターと入力データを分ける
候補マスターとは、部署や商品など、繰り返し選ぶ値の原簿です。入力データには部署名そのものではなく部署IDを保存し、表示時に名称を参照する形を基本にします。同じ「営業部」でも別会社の部署であれば、別のIDとして扱えます。
ここでは架空の作業受付を例にします。M_部署に部署の候補を、T_受付に実際の受付記録を保存します。以下はWindows版Accessの通常のACCDBを想定した設計例です。既存ファイルを直接変更せず、コピーした検証用データベースで進めてください。
| テーブル | フィールド | データ型と設定 | 用途 |
|---|---|---|---|
| M_部署 | 部署ID | オートナンバー型・主キー | 候補を一意に識別 |
| M_部署 | 部署名 | 短いテキスト・必須 | 画面に表示する名称 |
| M_部署 | 有効 | Yes/No・既定値True | 新規選択を許すか |
| M_部署 | 表示順 | 数値型・長整数 | 候補の並び順 |
| T_受付 | 受付ID | オートナンバー型・主キー | 受付を識別 |
| T_受付 | 受付日 | 日付/時刻型・必須 | 受付の日時 |
| T_受付 | 部署ID | 数値型・長整数・必須 | 選択した部署を保存 |
M_部署の部署IDとT_受付の部署IDを、［データベースツール］の［リレーションシップ］で結びます。既存データに不正なIDがないことを確認して、参照整合性を設定します。これは「存在しない部署IDを受付へ保存しない」ための仕組みです。履歴を守るため、関連レコードの連鎖削除は安易に有効にしません。
部署名を変更すると、IDから現在の名称を表示する過去の受付も新名称で見えます。当時の帳票名を再現したい場合は、受付時名称を別項目へ保存する、または有効期間を持つ履歴マスターを設計します。名前をIDへ置き換えるだけで過去の表示まで固定されるわけではありません。
名前を表示してIDを保存するコンボボックス
コンボボックスは、候補を一覧から選べるフォームの部品です。重要なのは、候補の取得先である［値集合ソース］と、選んだ値の保存先である［コントロールソース］を分けて設定することです。両者を逆に考えると、選べるのに受付へ保存されない画面になります。［参考1］
ウィザードで作り設定を照合する
1. T_受付を選択し、［作成］からフォームを作り、F_受付として保存します。
2. フォームをデザインビューで開き、コントロールウィザードを有効にしてコンボボックスを配置します。
3. テーブルまたはクエリから値を取得する選択肢を選び、M_部署の部署IDと部署名を指定します。
4. キー列を非表示にし、選択した値の保存先としてT_受付の部署IDを選びます。ラベルは「担当部署」にします。
5. コンボボックスの名前をcbo部署にし、F4でプロパティシートを開いて下表を確認します。
| プロパティ | 設定例 | 意味 |
|---|---|---|
| コントロールソース | 部署ID | 受付テーブルの保存先 |
| 値集合タイプ | テーブル/クエリ | 候補を表から取得 |
| 値集合ソース | 下記SELECT文 | 候補のIDと名称 |
| 連結列 | 1 | 先頭列のIDを保存 |
| 列数 | 2 | IDと名称の2列 |
| 列幅 | 0cm;5cm | IDを隠して名称を表示 |
| 入力チェック | はい | リストにない文字の確定を拒否 |
SELECT [部署ID], [部署名]
FROM [M_部署]
ORDER BY [表示順], [部署ID];
［入力チェック］を「はい」にしても、未選択のNullは別の扱いです。部署の未入力を禁止するには、保存先フィールドの［値要求］も「はい」にします。「一覧外を拒否」と「必ず選ばせる」は二つの設定だと覚えてください。
［参考2］
試験データとして部署ID=1の「営業部」を選択し、別の受付へ移動して保存します。その後T_受付を確認し、部署名ではなく数値の1が保存されたかを調べます。フォームを閉じて開き直しても「営業部」が表示されることまで確認すれば、表示と保存の両方を検証できます。
候補の追加と廃止を安全に運用する
候補の追加はM_部署へ行い、受付フォームの候補一覧を再取得します。候補追加用フォームを閉じた後など、利用者が理解しやすいタイミングでcbo部署.Requeryを実行する設計にします。候補マスターへ行が増えただけでは、開いたままの一覧がその場で更新されるとは限りません。
部署が廃止されても、過去の受付が参照している行は削除しません。有効をFalseにし、新規受付では選べないようにします。ただし値集合ソースを単純に「有効=True」へ絞ると、廃止部署を持つ過去レコードの名称がコンボボックスに表示されなくなる場合があります。
| 用途 | 候補の扱い | 画面の方針 |
|---|---|---|
| 新規受付専用フォーム | 有効な部署だけ | 廃止候補を選ばせない |
| 過去の受付を閲覧 | 廃止部署も参照 | 結合クエリの名称を読み取り専用で表示 |
| 既存受付の部署変更 | 有効候補と現在値を考慮 | 履歴表示を保ち、不正な変更を検査 |
| 部署名の改称 | 現在名と当時名を区別 | 帳票の再現要件に合わせて保存 |
初心者には、新規入力と過去閲覧を別画面にする構成が分かりやすくなります。同一画面で扱う場合は、現在レコードの廃止部署を候補に残すクエリと、変更時に廃止候補を拒否する検証が必要です。まず基本の2列コンボを完成させてから、この運用を追加してください。
Accessの教科書でプルダウン業務の改善を相談する
候補や集計条件が部署ごとに異なる、既存の画面を直せる担当者がいないなど、プルダウンの手順だけでは解決しない場合は、現在のExcelと業務の流れを整理して相談すると検討が進みます。Accessの教科書のお問い合わせで、対象データ、利用人数、困っている操作をお知らせください。
連動する選択肢と入力エラーを整える
「事業部を選ぶと部署候補が絞られる」といった連動コンボでは、上位の値を変更したときに下位の値を消してから再取得します。部署候補だけを変えると、以前選んだ別事業部の部署IDが残り、見た目は空欄でも保存値は不正という状態になりかねません。
説明用にM_部署へ事業部IDを追加し、F_受付のcbo事業部で選んだ事業部に限定します。部署用の値集合ソースの条件は「WHERE [事業部ID]=Forms![F_受付]![cbo事業部]」です。この条件はF_受付が開いている前提で、フォーム名と部品名を完全に一致させます。
‘ F_受付のcbo事業部 更新後処理
rivate Sub cbo事業部_AfterUpdate()
Me!cbo部署 = Null
Me!cbo部署.Requery
End Sub
この例は連動の基本だけを示しています。既存レコードを表示する際にも、適切な事業部の候補へ再取得する処理が必要です。連続フォームでは一つの値集合ソースを複数行が共有するため、行ごとの表示が空欄になる問題もあります。まず単票フォームで実装し、連続フォームへは同じ設計を無条件に流用しないでください。
| 症状 | まず見る場所 | 修正の方向 |
|---|---|---|
| 選べるが保存されない | コントロールソース | 保存先の部署IDへ連結 |
| 名前でなく番号が見える | 列幅・連結列 | IDを非表示にして名称列を表示 |
| 新しい候補が出ない | 値集合ソース・再取得 | 候補を保存してRequery |
| 型が一致しない | 保存先の型 | 通常のオートナンバーに対し長整数を使用 |
| 廃止後に過去の表示が消える | 候補の有効条件 | 閲覧用名称と選択候補を分ける |
Excelから移す前後の確認と共同利用
Excelの名称をAccessへ取り込むときは、名称をIDへ対応付ける表を先に作ります。前後の空白や表記の違いを点検し、「営業」「営業部」を同じ部署とみなすかは管理者が判断します。文字が似ているという理由だけで自動統合すると、別組織の記録が混ざるおそれがあります。
本番テーブルへ直接追加せず、一時取込テーブルで未対応の名称を抽出します。対応する部署IDがない行、複数の候補が一致する行、未入力の行を分けて修正してください。すべての行に正しいIDが付いた後、件数と代表レコードを比較してから移行します。
| 試験 | 期待する結果 |
|---|---|
| 正常な部署を選択して保存 | 部署IDが保存され、再表示で名称が出る |
| 必須の部署を空欄にする | 保存できず、選ぶべき項目が分かる |
| 一覧外の部署名を入力 | 受け付けず、候補の登録方法へ案内 |
| 候補を追加して再取得 | 新規候補を選べる |
| 廃止部署を持つ過去受付を表示 | 過去の部署を識別できる |
| 別担当者が同時に利用 | 自分の画面が他人の操作で切り替わらない |
複数人利用では、フォーム等を置くフロントエンドを各PCへ配布し、データを共有バックエンドへ分ける構成を検討します。OneDriveなどの同期フォルダにある同じACCDBを直接同時編集する方法は採用しません。画面を分けてもアクセス権限が自動で整うわけではないため、ファイル権限や必要に応じたサーバー側の制御も確認します。
小さく導入して運用を定着させる
初回の対象は、候補が頻繁に変わり、入力ルールの維持に困っている一つの台帳に絞ります。最初から全帳票を作り直すと、比較対象が増えて移行確認が難しくなります。入力だけAccessへ移し、月次の分析や提出用の加工をExcelへ残す方法も選べます。
導入前に、候補修正にかかる時間、表記修正の件数、未入力で差し戻した件数を記録します。導入後も同じ期間と件数で比べ、操作時間だけでなく、入力者が迷う場面や管理者の確認時間も測ります。削減効果は業務と設計次第なので、一律の削減率は置きません。
管理者向けには、候補追加、名称変更、廃止、誤設定からの復旧の四つの手順を残します。利用者向けには「候補がない場合は自由入力せず管理者へ連絡する」と案内します。担当者交代でも同じルールを守れることが、フォーム化を長く役立てる条件です。
よくある質問
はい。候補の修正漏れが主な問題なら、候補一覧をExcelテーブルにまとめ、同じ参照先を使う入力規則へ統一する方法を先に試せます。ただし、候補の更新と、新しく増やした入力行への規則の適用は別です。行追加やコピー後にも同じ候補が表示されるか確認しましょう。複数の台帳をまたいで候補を管理したい、変更履歴を残したいといった要件が加わる場合に、Accessへの移行を比較すると判断しやすくなります。
単純な記録では名前を保存する設計もありますが、共通の候補を管理するならID保存が扱いやすくなります。表記揺れがあっても同じIDで集計でき、改称時も原則としてマスターを修正すれば済むためです。ただし現在名を参照するだけでは、過去の帳票も新名称で表示されます。当時の名称を再現する必要がある場合は、受付時名称の保存や履歴マスターを追加します。「ID保存なら履歴も自動で守られる」と考えないことが大切です。
いいえ。コンボボックスの入力チェックを「はい」にする設定は、一覧にない入力値の確定を制限するものです。未選択を表すNullは別途扱うため、保存先テーブルの部署IDで値要求を「はい」にする必要があります。フォーム側にも「担当部署を選択してください」という案内を用意すると、直す場所が分かりやすくなります。設定後は一覧外の文字、完全な空欄、正常な候補の三通りを試し、保存できる条件が業務ルールと合うか確認してください。
過去の受付などから参照されている候補は、原則として削除せず無効化します。削除すると履歴から名称をたどれなくなるほか、参照整合性によって削除が拒否される場合があります。有効フラグで新規選択を止め、過去の閲覧では名称を表示できるようにしてください。候補を有効な行だけに絞ると、既存レコードのコンボ表示が空欄になることもあります。新規入力と履歴閲覧を分けるなど、表示と選択を別々に設計すると安全です。
基本の候補一覧は、コンボボックスウィザードとプロパティの設定で作れます。まずは一つのマスターから選び、IDを保存するフォームを完成させるのがおすすめです。一方、候補追加後の即時反映、上位項目に連動する絞り込み、複雑な入力チェックには、マクロやVBAを使うことがあります。コードを増やす前に、必要な動作と設定場所を文章で整理してください。作成者以外が保守できるよう、フォーム名、部品名、候補の管理手順も残します。
フォームの設定だけでは、すべての変更経路を防げません。利用者がテーブルを直接開ける場合や、別の取込処理がある場合には、フォームの検査を通らずにデータが変わる可能性があります。必須や参照整合性はテーブル側にも設定し、ファイルへのアクセス権と配布方法を整えます。厳密な権限制御や監査が必要なら、データをSQL Serverなどへ置く構成も検討します。画面の使いやすさとデータの保護は、分けて設計することが重要です。
まとめ
プルダウンの問題は、選択部品の設定と候補管理の運用に分けて解決します。Excelの候補テーブルで十分ならその改善を優先し、複数の画面や担当者で共通管理したい場合にAccessを検討しましょう。Accessでは名前を表示してIDを保存し、未入力、廃止候補、過去の表示、取込経路まで確認すると、入力の揺れを抑えられます。
Accessの教科書でプルダウン業務の改善を相談する
候補や集計条件が部署ごとに異なる、既存の画面を直せる担当者がいないなど、プルダウンの手順だけでは解決しない場合は、現在のExcelと業務の流れを整理して相談すると検討が進みます。Accessの教科書のお問い合わせで、対象データ、利用人数、困っている操作をお知らせください。
関連記事
参考情報
［参考1］Microsoft ComboBox.BoundColumn
https://learn.microsoft.com/en-us/office/vba/api/access.combobox.boundcolumn
［参考2］Microsoft ComboBox.LimitToList
https://learn.microsoft.com/en-us/office/vba/api/access.combobox.limittolist
［参考3］Microsoft ドロップダウン リストを作成する
https://support.microsoft.com/ja-jp/excel/get-started/create-a-drop-down-list
［参考4］Microsoft Form.Requery
https://learn.microsoft.com/en-us/office/vba/api/access.form.requer