概要
| この記事の結論 Accessの検索フォームは、よく使う条件を画面の入力欄にまとめ、条件に合うレコードを一覧表示する仕組みです。顧客名や状態を指定するたびに複数列のフィルターを設定し直す手間を減らせます。ただし、条件欄を保存データへ連結しないこと、空欄の意味と検索後の再表示を決めることが大切です。Excelのフィルター等との使い分けから、具体的な作成例まで説明します。 |
この記事でわかること
- 検索と抽出の違いから改善方法を選ぶ
- 検索専用フォームと結果一覧を分ける
- 顧客名と状態の検索クエリを作る
- 検索ボタンと条件クリアを実装する
- 日付検索と空欄と特殊文字を扱う
この記事の主な内容
- 検索と抽出の違いから改善方法を選ぶ
- 検索専用フォームと結果一覧を分ける
- 顧客名と状態の検索クエリを作る
- 検索ボタンと条件クリアを実装する
- 日付検索と空欄と特殊文字を扱う
- 検索が遅い場合と結果が出ない場合
- 共有運用で検索条件と権限を分ける
- よくある質問
想定読了時間：約16分～20分
検索と抽出の違いから改善方法を選ぶ
検索は該当する場所を探す操作、抽出は条件に合う行だけを取り出す操作です。一つの顧客名を見つけたいだけならExcelの検索で十分です。「未処理の案件のうち、今月登録した特定の顧客」を繰り返し確認するなら、複数条件をまとめた検索フォームが役立ちます。
Excelでもフィルター、対応版のFILTER関数、利用環境に応じたシートビューなどで改善できます。シートビューは他の利用者と表示条件がぶつかる問題を軽減する選択肢です。Accessを使う理由を「Excelではできない」と一括りにせず、条件の定型化と保存データの共通管理が必要かで判断しましょう。
| 業務の例 | 先に検討する方法 | 判断のポイント |
|---|---|---|
| 時々1件の名前を探す | Excelの検索 | 独自画面を作る負担が小さいか |
| 同じ表を条件で絞る | Excelのフィルター等 | 複数人の表示条件を分けられるか |
| 毎日同じ複合条件で探す | Accessの検索フォーム | 条件を画面へ固定できるか |
| 顧客と履歴を関連付けて探す | Accessの結合クエリ | IDで正しく関連付けられるか |
検索画面を作る前に、実際に使われる条件を五つ程度まで書き出します。すべての項目を一度に並べると、初めて使う人が何を入れるべきか迷います。まず日常の問い合わせに必要な項目を用意し、特殊な検索は詳細画面へ分ける方が使いやすくなります。
検索専用フォームと結果一覧を分ける
条件欄は「探すための入力」であり、元の案件データを直す入力ではありません。親フォームを非連結にし、その上に検索欄とボタンを置きます。結果は選択クエリを基にしたサブフォームへ表示し、まずは読み取り専用にして誤更新を防ぎます。
例としてT_案件を用意します。案件IDはオートナンバー型の主キー、顧客名は短いテキスト型、状態は短いテキスト型、受付日は日付/時刻型です。状態は「未処理」「対応中」「完了」の三つとします。実運用で複数の表を関連付ける場合は、顧客名だけで結合せず顧客IDを使ってください。
| オブジェクトや部品 | 名前 | 設定 |
|---|---|---|
| 親フォーム | F_案件検索 | レコードソースを空欄 |
| 顧客名入力欄 | txt顧客名 | コントロールソースを空欄 |
| 状態コンボ | cbo状態 | 非連結・値リスト・入力チェックはい |
| 検索ボタン | cmd検索 | クリック時に結果を再クエリ |
| クリアボタン | cmd条件クリア | 条件を消して再クエリ |
| 結果フォーム | SF_案件結果 | Q_案件検索をレコードソースに指定 |
| サブフォーム部品 | sub結果 | リンク親・リンク子フィールドを空欄 |
状態コンボの値集合ソースは「未処理;対応中;完了」とし、未選択のNullも許す検索条件として使います。SF_案件結果の追加の許可、削除の許可、更新の許可は「いいえ」にします。後から編集機能を設けるなら、案件IDを引き継いで編集用フォームを開く設計に分けると、検索と更新を混同しにくくなります。
顧客名と状態の検索クエリを作る
条件が空欄ならその項目では絞り込まない、入力があれば絞り込むというルールを明示します。複数の項目をANDでつなぐと、すべてを満たす行だけを抽出します。ORならどちらかを満たす行も含まれるため、条件の意味を取り違えないようにしてください。［参考1］
下の例は、顧客名を文字どおりの部分一致、状態を完全一致で探します。InStrは、文字列の中に指定文字が現れる位置を返す関数です。0より大きければ含まれています。これにより、利用者が「*」などを入力しても、特別な検索記号として扱わない検索画面にできます。
PARAMETERS [Forms]![F_案件検索]![txt顧客名] Text (255),
[Forms]![F_案件検索]![cbo状態] Text (50);
SELECT [案件ID], [顧客名], [状態], [受付日]
FROM [T_案件]
WHERE
(Trim(Nz([Forms]![F_案件検索]![txt顧客名],””)) = “”
OR InStr(1,Nz([顧客名],””),
Trim(Nz([Forms]![F_案件検索]![txt顧客名],””)),1) > 0)
AND
(Nz([Forms]![F_案件検索]![cbo状態],””) = “”
OR [状態] = [Forms]![F_案件検索]![cbo状態])
ORDER BY [受付日] DESC, [案件ID] DESC;
［作成］からクエリデザインを開き、SQLビューへ切り替えて入力し、Q_案件検索として保存します。F_案件検索が開いている状態で動くクエリです。フォームを閉じて単独で実行するとパラメーター入力を求められることがあるため、名前の誤りと区別して確認しましょう。
NzはNullを空文字に置き換え、Trimは前後の通常の空白を除きます。全角空白、半角カナ、会社名の略記などをすべて同一視する処理ではありません。あいまいな表記を吸収したい場合は、検索用の正規化項目を別に持つなど、業務に合うルールを追加します。
検索ボタンと条件クリアを実装する
検索条件を変えた後は、結果一覧に対してRequeryを実行します。［参考2］
非連結の条件欄を書き換えただけでは、既に表示している結果が変わらない場合があります。「検索」を押した時点の条件を反映する仕様にすると、入力途中の結果変化を避けられます。
Private Sub cmd検索_Click()
On Error GoTo Err_Handler
Me!sub結果.Form.Requery
Exit Sub
Err_Handler:
MsgBox “検索できません。条件や設定を確認してください。” _
& vbCrLf & Err.Description, vbExclamation
End Sub
Private Sub cmd条件クリア_Click()
Me!txt顧客名 = Null
Me!cbo状態 = Null
Me!sub結果.Form.Requery
End Sub
このコードはF_案件検索のフォームモジュールへ置き、各ボタンのクリック時をイベントプロシージャに設定します。sub結果は、フォーム内に置いたサブフォーム部品の名前です。中で表示するSF_案件結果というフォームの名前とは別なので、プロパティの［名前］を確かめてください。
この基本例は、条件をすべて消すと全件を表示します。データ量が多い運用では、期間の指定を必須にする、起動時は結果を出さないなど、別の仕様を決めます。全件表示が必要なのかを利用者と整理し、使われない大量データを最初から読み込まない設計を検討しましょう。
結果が0件のときは「該当する案件はありません」と表示し、エラーと区別できるようにします。また条件欄と結果の近くに「検索を押すと反映」と案内すると、入力途中の条件と表示中の結果が一致していると思い込む事故を減らせます。
Accessの教科書で検索業務の改善を相談する
候補や集計条件が部署ごとに異なる、既存の画面を直せる担当者がいないなど、検索の手順だけでは解決しない場合は、現在のExcelと業務の流れを整理して相談すると検討が進みます。Accessの教科書のお問い合わせで、対象データ、利用人数、困っている操作をお知らせください。
日付検索と空欄と特殊文字を扱う
日付条件を追加する場合は、日付/時刻型で保存されているかを先に確認します。開始日以上、終了日の翌日未満という形にすると、時刻付きの受付日でも終了日全体を対象にできます。検索欄へ文字列をそのままつないでSQLを作るより、型を宣言したパラメーターを利用する方が、日付の解釈をそろえやすくなります。
例えば開始日が10月1日、終了日が10月31日なら、「10月1日0時以上、11月1日0時未満」と考えます。フォームにはtxt開始日とtxt終了日を追加し、クエリにもDateTimeのパラメーターを追加します。両方必須にするのか、片側だけの指定を許すのかを決め、空欄のときに実行する条件を分けます。
| 入力状態 | 画面で決める動作 |
|---|---|
| 顧客名が空欄 | 顧客名では絞り込まない |
| 状態が未選択 | 全状態を対象にする |
| 開始日が終了日より後 | メッセージを出して検索しない |
| 文字としての日付が不正 | 日付へ直す場所を案内 |
| 検索文字に*や? | 文字どおり探すか、記号として扱うかを統一 |
Likeを使う方法では、通常のANSI-89設定のAccessは「*」「?」、ANSI-92設定では「%」「_」などをワイルドカードに使います。ワイルドカードは任意の文字を表す記号です。設定と記号が合わないと検索結果が変わるため、この記事のInStr例と、Likeによる記号検索を混ぜないでください。
InStrによる部分一致は単純で分かりやすい一方、インデックスを利用した高速な絞り込みに向かない場合があります。データが増えたら、まず案件IDの完全一致、次に期間、最後に名前の部分一致というように、頻繁に使う検索を分けて設計すると改善の方向が明確になります。
検索が遅い場合と結果が出ない場合
検索が遅いときは、表示件数と抽出条件を先に絞ります。すべての列、すべての期間、すべての関連表を毎回取得する画面では、条件を入力してから結果が出るまでの負荷が大きくなります。必要な列だけを取り出し、IDや日付などの検索対象に適切なインデックスがあるか確認します。
| 症状 | 確認すること | 対処の方向 |
|---|---|---|
| パラメーター入力が突然出る | フォーム名・部品名・開閉状態 | 名称を統一し親フォームから実行 |
| 条件を変えても結果が同じ | 再クエリの対象 | sub結果.Form.Requeryを確認 |
| 空欄にすると0件になる | Nullの比較方法 | 空欄条件を明示して分岐 |
| 一部の名前が出ない | 全半角・空白・略称 | 元データと検索仕様を照合 |
| 複数条件で件数が増える | ANDとORの括弧 | 条件のまとまりを見直す |
| 検索が遅い | 部分一致・取得範囲・接続 | 完全一致や期間指定を併用 |
架空の試験では、「青葉工業・未処理」「青葉工業・完了」「さくら製作所・未処理」の3行を用意します。顧客名「青葉」だけなら2件、状態「未処理」だけなら2件、両方なら1件、全条件クリアなら3件になることを確認します。この期待結果があると、ANDの括弧を変更したときの誤りにも気付けます。
検索結果をExcelへ出力する場合は、条件と出力日時も残します。画面では「未処理のみ」だったのに、出力ボタンが別の無条件クエリを使う事故があるためです。画面の件数と出力件数を照合し、検索条件が帳票やCSVにも引き継がれることを確かめましょう
共有運用で検索条件と権限を分ける
利用者ごとにフロントエンドを配布すると、検索欄の値や一覧の表示を個別に扱いやすくなります。ただし検索条件で絞ることは、データへのアクセス権限を制限することではありません。「自部署だけを検索する初期条件」があっても、別の画面や接続から他部署の情報へ到達できれば保護になりません。
見せてよい範囲を厳密に分ける場合は、ファイル権限やサーバー側のアクセス制御も含めて設計します。画面に表示しない項目を、出力用のクエリが取り出していないかも点検します。入力・検索・印刷・CSV出力のそれぞれに、誰が何をできるかを整理してください。
導入効果は、案件を見つけるまでの時間、条件設定のやり直し回数、0件だと思い込んだ問い合わせの件数などで確認します。よく使う条件のボタンは、実際に使われた検索を見て追加します。検索条件を増やすたびに、空欄、単独条件、複数条件、0件のテストを更新すると、後から保守しやすい画面になります。
よくある質問
Accessの検索フォームは、よく使う条件を一つの画面へまとめ、決まった抽出処理を再利用できる点が特徴です。ただしExcelでもフィルターや対応版のFILTER関数、シートビューなどで改善できる場面があります。一件の文字を探すだけなら、専用画面を作る必要はないこともあります。複数の条件を毎日組み合わせる、顧客と履歴を関連付けて探す、出力の条件も統一したいといった要件がある場合に、Accessの構築負担と効果を比較するとよいでしょう。
検索欄がテーブルのフィールドへ連結されている可能性があります。条件入力用の親フォームはレコードソースを空欄にし、テキストボックスやコンボボックスのコントロールソースも空欄にします。結果は別のサブフォームへ表示し、最初は更新を許可しない構成にすると役割が明確になります。既に本番データを変えてしまった場合は、続けて操作せず影響したレコードを確認してください。修正前のバックアップや履歴があれば、正しい値を照合して戻します。
Nullや空文字をそのまま検索条件と比較している可能性があります。空欄ならその条件を使わない設計では、「空欄である、または条件に一致する」という形を項目ごとに作ります。この記事の例はNzでNullを空文字に変え、顧客名と状態の条件をANDで結んでいます。ただし空欄で全件を表示するか、条件入力を求めるかは業務によって決めます。大量データでは全件表示を避ける仕様も有効です。単独条件と条件クリアの両方で件数を確認してください。
条件欄を変更しただけで、結果一覧のクエリが再実行されていない可能性があります。検索ボタンから、サブフォームコントロールのForm.Requeryを呼び出しているか確認してください。部品の名前と、その中に表示するフォーム名は別なので、取り違えにも注意します。クエリが参照する親フォーム名や条件欄名が違う場合にも、想定どおりに動きません。まずクエリを単独で確認し、次に画面と接続する順で調べると原因を絞りやすくなります。
文字どおりの部分一致にするか、ワイルドカードを利用できる検索にするかを先に決めます。この記事はInStrを使い、入力した文字が含まれるかを調べる例です。Likeを使う場合はANSI設定によって記号が異なり、利用者が入力した星印なども条件として解釈されます。また全角空白や会社名の略記を自動ですべて同一視するわけではありません。データが多い場合は部分一致が遅くなることもあるため、案件IDの完全一致や期間指定を組み合わせます。
初期の検索条件だけでは、厳密な閲覧制限にはなりません。利用者が条件を変えられる、元テーブルを開ける、別の出力から情報を取得できる場合は、画面で非表示にしても保護できないためです。検索の使いやすさとアクセス権限は別に設計します。厳密な部署別制御が必要なら、ファイル権限やSQL Server等のサーバー側の権限も検討してください。検索画面だけでなく、印刷、CSV出力、直接接続も含めて、誰がどこまで使えるかを確認します。
まとめ
Access検索フォームでは、非連結の条件欄、抽出クエリ、読み取り用の結果一覧を分けて作ります。空欄の意味とAND条件を明示し、ボタンで再クエリするところまで含めて動作を確かめましょう。Excelの改善策とも比較し、日付、特殊文字、出力条件、アクセス権まで考慮すると、日常の検索を安定させられます。
Accessの教科書で検索業務の改善を相談する
候補や集計条件が部署ごとに異なる、既存の画面を直せる担当者がいないなど、検索の手順だけでは解決しない場合は、現在のExcelと業務の流れを整理して相談すると検討が進みます。Accessの教科書のお問い合わせで、対象データ、利用人数、困っている操作をお知らせください。
関連記事
参考情報
［参考1］Microsoft クエリに抽出条件を適用する
https://support.microsoft.com/ja-jp/access/apply-criteria-to-a-query
［参考2］Microsoft Form.Requery
https://learn.microsoft.com/en-us/office/vba/api/access.form.requery
［参考3］Microsoft クエリの概要
https://support.microsoft.com/ja-jp/access/introduction-to-queries
［参考4］Microsoft Excelでのシートビューの作成と管理
https://support.microsoft.com/ja-jp/excel/create-and-manage-sheet-views-in-excel