Accessで「国を選ぶと都市だけを表示する」「部門を選ぶと所属社員だけを候補に出す」といったカスケード コンボボックスを作る場合、これまではVBAのAfterUpdateイベントやRowSourceのSQL調整に頼る実装が定番でした。Microsoftが公開したRoadmap ID 561328では、AccessのコンボボックスとリストボックスがLinkMasterFields/LinkChildFieldsプロパティをサポートし、VBAを書かずに親子連動のドロップダウンを作れるようになる予定です。対象はAccessのDesktop、リリースフェーズはGeneral Availability、予定時期はAugust CY2026、状態はIn developmentです。(Microsoft)
ポイントは「Accessの画面設計でよくある親子候補の絞り込みを、サブフォーム連携に近い考え方で設定できるようになる」ことです。ただし、すべての既存VBAをすぐ置き換える機能ではありません。データ型、連携キー、既存のイベント処理、利用者のAccess更新チャネルを確認してから展開する必要があります。
Accessのカスケード コンボボックスで何が変わるのか
今回の変更は、Accessのコンボボックスとリストボックスに対して、LinkMasterFields/LinkChildFieldsプロパティを使えるようにするものです。
Microsoftの説明では、たとえば「Countryを選ぶとCityを絞り込む」ようなカスケード ドロップダウンを、VBAコードなしで実現できるとされています。(Microsoft)
従来のAccessでは、同じような動きを作るために、次のような実装がよく使われていました。
Private Sub cboCountry_AfterUpdate()
Me.cboCity.Requery
End Subまたは、子側のコンボボックスのRow Sourceに次のような条件を入れる方法です。
SELECT CityID, CityName, CountryID
FROM M_City
WHERE CountryID = Forms!F_Address!cboCountry
ORDER BY CityName;この実装は柔軟ですが、フォーム名やコントロール名を変更すると壊れやすく、VBAに慣れていない担当者には保守が難しいのが弱点でした。新機能では、親側の値と子側のフィールドをプロパティで結び付けることで、より少ないコードで候補連動を設定できるようになる見込みです。
LinkMasterFields/LinkChildFieldsとは
LinkMasterFields/LinkChildFieldsは、Accessで親側のレコードやコントロールと、子側のレコードを関連付けるためのプロパティです。
Microsoft Learnでは、LinkMasterFieldsはメインフォームまたはレポート側のリンク フィールドやコントロール、LinkChildFieldsはサブフォーム、サブレポート、埋め込みオブジェクト側のリンク フィールドを指定するものとして説明されています。設定されている場合、メインフォームのレコード変更に応じて関連レコードが自動的に更新されます。(Microsoft Learn)
今回のRoadmap項目では、この考え方がコンボボックスとリストボックスにも広がります。つまり、サブフォームだけでなく、入力候補そのものを親項目に連動させやすくなるということです。
設定イメージ
たとえば、国と都市のマスタがあるとします。
| テーブル | 主なフィールド | 役割 |
|---|---|---|
| M_Country | CountryID, CountryName | 親マスタ |
| M_City | CityID, CityName, CountryID | 子マスタ |
フォーム上のコントロールは、次のように設計します。
| コントロール | 用途 | 設定の考え方 |
|---|---|---|
| cboCountry | 国を選択する親コンボボックス | Bound ColumnをCountryIDにする |
| cboCity | 都市を選択する子コンボボックス | Row SourceにCityID、CityName、CountryIDを含める |
| cboCityのLinkMasterFields | 親側の値 | cboCountryまたは親側のCountryID |
| cboCityのLinkChildFields | 子側の照合フィールド | CountryID |
重要なのは、表示名ではなくキーで連動させることです。「Japan」「Tokyo」のような文字列で絞り込むより、CountryIDやCityIDのような一意のIDを使う方が安全です。名称変更、同名データ、多言語表示の影響を受けにくくなります。
対象範囲とリリース予定
この機能は、Microsoft 365 Roadmap上ではAccess向けのDesktop機能として登録されています。Roadmap API上の作成・更新日時は2026-05-05T23:00:02 UTCで、日本時間では2026年5月6日に相当します。(Microsoft)
| 項目 | 内容 |
|---|---|
| Roadmap ID | 561328 |
| 機能名 | Access: Cascading combo and list boxes with LinkMasterFields/LinkChildFields |
| 対象サービス | Access |
| プラットフォーム | Desktop |
| クラウド | Worldwide (Standard Multi-Tenant) |
| 状態 | In development |
| リリースフェーズ | General Availability |
| 一般提供予定 | August CY2026 |
| 主な効果 | VBAなしでカスケード コンボボックス／リストボックスを構成しやすくなる |
Microsoft 365 Roadmapの情報は、商用機能の予定日と説明を示すもので、すべての情報は変更される可能性があります。一般提供、延期、キャンセルなどにより、Roadmap上の情報が変更または削除される場合もあります。(Microsoft)
そのため、2026年8月に必ず全環境で同時利用できると考えるのではなく、利用中のMicrosoft 365 Apps更新チャネル、Accessのビルド、組織の展開ポリシーと合わせて確認する必要があります。
管理者が確認すべき影響範囲
この更新は、Accessを使った業務アプリ、部門内データベース、見積・顧客・在庫・申請管理などのフォーム設計に影響します。特に、Accessフロントエンドを複数ユーザーに配布している組織では、機能追加そのものよりも「どの端末で、いつ使えるようになるか」が重要です。
Microsoft 365 Appsの更新チャネルを確認する
Accessのデスクトップ機能は、利用しているMicrosoft 365 Appsの更新チャネルによって反映タイミングが変わる可能性があります。
Microsoftは、Microsoft 365 Appsの更新チャネルとして、準備ができ次第新機能を提供するCurrent Channel、月次の予測可能なリリースを重視するMonthly Enterprise Channel、広範なテストを必要とする端末向けのSemi-Annual Enterprise Channelを説明しています。(Microsoft Learn)
管理者は、少なくとも次の点を確認しておきましょう。
| 確認項目 | 見るべきポイント |
|---|---|
| 利用中の更新チャネル | Current Channel、Monthly Enterprise Channel、Semi-Annual Enterprise Channelなど |
| Accessのビルド差 | 開発者端末と利用者端末で同じ機能が使えるか |
| Access Runtime利用 | Runtime環境で新しいプロパティを含むフォームが期待どおり動くか |
| フロントエンド配布方式 | ACCDB/ACCDEを共有しているか、端末ごとに配布しているか |
| ロールバック方針 | 新機能適用後に問題が出た場合、旧版フォームに戻せるか |
Microsoft 365 Appsの更新チャネル変更は、アンインストールと再インストールではなく、Microsoft 365 Appsの更新エンジンを使って行われると説明されています。既存端末のチャネルを変更する場合は、Intune、グループポリシー、Microsoft 365 Apps管理センターなど、組織の管理方式に合わせて計画する必要があります。(Microsoft Learn)
開発者が見直すべき既存フォーム
Accessで既にカスケード コンボボックスを実装している場合、新機能が使えるようになっても、既存処理を即削除するのは危険です。まずは、どのフォームが親子連動を使っているかを棚卸ししましょう。
確認すべき代表例は次のとおりです。
| 既存実装 | 確認ポイント |
|---|---|
| AfterUpdateで子コンボをRequeryしている | 新プロパティと二重に絞り込まないか |
| Row SourceにForms!フォーム名!コントロール名を直接書いている | フォーム名変更や再利用時の保守負荷を下げられるか |
| VBAでRowSourceのSQL文字列を組み立てている | 単純な親子条件だけならプロパティ化できるか |
| 複数条件で候補を絞っている | LinkMasterFields/LinkChildFieldsだけで表現できるか |
| Null時に全件表示している | 親未選択時の動作を新機能で再現できるか |
| 入力候補に権限条件を含めている | 単純なカスケード化でセキュリティ条件が抜けないか |
特に注意したいのは、既存のVBAと新しいプロパティ設定を併用したときの二重フィルターです。たとえば、LinkMasterFields/LinkChildFieldsで都市を国に連動させたうえで、AfterUpdateイベントでもRowSourceを書き換えていると、意図せず候補が空になる可能性があります。
移行時のおすすめ手順
既存のAccessアプリにこの機能を取り入れる場合は、いきなり本番フォームを変更せず、検証用コピーで段階的に確認するのが安全です。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現状把握 | カスケード コンボボックス、リストボックスを使うフォームを洗い出す | イベントプロシージャだけでなく、Row Source内のForms参照を見落とす |
| キー確認 | 親子テーブルの主キー・外部キーを確認する | 表示名で連動しており、同名データに弱い |
| データ型確認 | 親側のBound Columnと子側の連携フィールドの型を合わせる | AutoNumberと短いテキストなど、型不一致で絞り込みに失敗する |
| 子側Row Source確認 | 子コンボ／リストのRow Sourceに連携フィールドを含める | 画面には表示しない列をSQLから除外してしまう |
| 新プロパティ設定 | LinkMasterFieldsとLinkChildFieldsを設定する | コントロール名とフィールド名を混同する |
| VBA整理 | 不要になったRequeryやRowSource変更処理を無効化して比較する | いきなり削除して旧環境に戻せなくなる |
| テスト | 親変更、未選択、データ追加、既存レコード表示を確認する | 新規入力時だけ確認し、既存レコード編集時の動作を見ない |
| 展開 | 検証済みビルドのAccess端末へ段階展開する | 開発者端末では動くが、利用者端末では未対応ビルドだった |
実務で使いやすい活用シーン
この機能が特に役立つのは、親子関係が明確で、候補の絞り込み条件が比較的シンプルなケースです。
| 活用シーン | 親 | 子 |
|---|---|---|
| 住所入力 | 都道府県 | 市区町村 |
| 営業管理 | 顧客 | 案件 |
| 在庫管理 | 商品カテゴリ | 商品 |
| 人事管理 | 部門 | 社員 |
| 問い合わせ管理 | 問い合わせ種別 | 詳細カテゴリ |
| 設備管理 | 拠点 | 設備 |
たとえば、商品カテゴリを選んだ後に、そのカテゴリに属する商品だけを商品コンボボックスに表示できれば、入力ミスを減らせます。利用者は長い候補一覧から探す必要がなくなり、開発者は簡単な親子連動のためだけにVBAを書く場面を減らせます。
それでもVBAやクエリが必要になるケース
「VBAなしでカスケード ドロップダウンを作れる」と聞くと、すべての候補制御がプロパティだけで完結するように見えます。しかし、実務のAccessアプリでは、VBAやクエリが引き続き必要になるケースもあります。
| ケース | 理由 |
|---|---|
| 複数条件で候補を絞る | 部門、役職、在籍状態など複数条件が必要になる |
| 親未選択時だけ全件表示したい | Null時の動作を細かく制御する必要がある |
| ユーザー権限で候補を変える | ログインユーザーや所属に応じた制御が必要 |
| 入力値に応じてSQL自体を切り替える | 単純なキー一致では表現しにくい |
| 候補に「すべて」「未分類」などの疑似行を追加する | UNIONクエリや別処理が必要になることがある |
| 多対多の候補連動を行う | 中間テーブルを含む設計が必要になる |
新機能は、シンプルな親子連動を標準プロパティで扱いやすくするものです。複雑な業務ルールをすべて置き換える機能ではないと考えた方が、移行判断を誤りません。
設定時に注意したいデータ設計
LinkMasterFields/LinkChildFieldsを使った候補連動では、フォーム上の見た目よりも、裏側のキー設計が重要です。
Microsoft Learnでは、LinkMasterFields/LinkChildFieldsに使うフィールドやコントロールは同じ名前である必要はないものの、同じ種類のデータを含み、同じまたは互換性のあるデータ型とフィールドサイズを持つ必要があると説明されています。(Microsoft Learn)
実務では、次のように設計すると安定します。
| 設計項目 | 推奨 | 避けたい例 |
|---|---|---|
| 親子連携のキー | 数値ID、GUIDなどの一意キー | 表示名や略称 |
| コンボボックスの保存値 | 主キーID | 画面表示用の文字列 |
| 子側Row Source | 子ID、表示名、親IDを含める | 表示名だけを返すSQL |
| インデックス | 子テーブルの外部キーに設定 | 大量候補を毎回全件走査 |
| 名称変更対応 | IDは変えず表示名だけ変更 | 名称をキーとして使う |
たとえば、都市コンボボックスのRow SourceにはCityNameだけでなくCountryIDも含めておく必要があります。画面にCountryIDを表示する必要はありませんが、子側のLinkChildFieldsで照合するためのフィールドとして必要になる可能性があります。
複数フィールドで連動する場合の注意点
既存のLinkMasterFields/LinkChildFields仕様では、複数のフィールドやコントロールを指定する場合、両方のプロパティに同じ数の項目を指定し、セミコロンで区切る必要があります。(Microsoft Learn)
たとえば、年度と部門の両方で社員候補を絞り込むようなケースです。
LinkMasterFields: cboYear;cboDepartment
LinkChildFields : YearID;DepartmentIDただし、コンボボックス／リストボックスでの詳細な設定UIや制約は、一般提供後のAccessビルドで確認する必要があります。複数条件が業務上重要なフォームでは、従来のクエリ方式やVBA方式を残す判断も現実的です。
Access Runtimeや古いビルドとの互換性に注意
組織でAccess Runtimeを使っている場合や、端末によってAccessの更新チャネルが異なる場合は、互換性検証が欠かせません。
新しいプロパティを設定したフォームを、未対応のAccessビルドで開いたときにどう動くかは、公開情報だけでは判断しきれません。安全に進めるには、次のような運用が必要です。
| 状況 | 対応 |
|---|---|
| 一部端末だけ新機能対応 | 新機能版と従来版を混在させない |
| Access Runtimeを利用 | Runtime端末で本番と同じACCDEを検証する |
| 共有フォルダーからフロントエンドを起動 | 利用者ごとに異なるAccessビルドで開かれないよう管理する |
| 旧端末が残っている | 新プロパティを使うフォームを配布対象から外す |
| 不具合時に戻す必要がある | 旧版ACCDB/ACCDEを保管しておく |
Accessアプリは「開発者のPCで動く」だけでは不十分です。実際に利用する端末、権限、Runtime、リンクテーブル、ネットワーク環境でテストしてから展開しましょう。
管理者・開発者向けチェックリスト
一般提供前から準備できることは多くあります。特に、古いAccessアプリほど、フォームごとに実装方法がばらついていることが多いため、今のうちに整理しておくと移行しやすくなります。
| 役割 | 確認すること |
|---|---|
| 管理者 | Accessを含むMicrosoft 365 Appsの更新チャネルを把握する |
| 管理者 | 新機能を検証する端末グループを用意する |
| 管理者 | Access Runtime利用者の有無を確認する |
| 管理者 | 本番配布前に旧版へ戻せる手順を用意する |
| 開発者 | カスケード コンボボックスを使うフォームを洗い出す |
| 開発者 | 親子マスタの主キー・外部キー・インデックスを確認する |
| 開発者 | Row Source内のForms参照やAfterUpdate処理を確認する |
| 開発者 | 新機能で置き換える対象と、VBAを残す対象を分ける |
| 開発者 | Null、既存レコード、データ追加後の再表示をテストする |
この機能を導入すべきフォーム、見送るべきフォーム
新機能は便利ですが、すべてのフォームに適用する必要はありません。導入効果が大きいフォームから試すのが現実的です。
| 判断 | フォームの特徴 |
|---|---|
| 導入に向いている | 親子関係が1対多で明確 |
| 導入に向いている | VBAが単純なRequeryだけ |
| 導入に向いている | 表示候補の絞り込み条件がキー一致だけ |
| 導入に向いている | 市区町村、商品、社員など標準的なマスタ参照 |
| 慎重に判断 | 権限制御や承認状態で候補を変える |
| 慎重に判断 | 複数テーブルをまたぐ複雑な候補生成 |
| 慎重に判断 | 親未選択時の特殊処理が多い |
| 慎重に判断 | 古いAccessビルドやRuntime利用者が多い |
まずは、部門→社員、カテゴリ→商品など、構造が分かりやすいフォームで検証するのがおすすめです。複雑な業務ルールが入ったフォームは、既存VBAを無理に置き換えず、保守性が本当に上がるかを見極めましょう。
まとめ：Accessの親子候補連動は「コード削減」と「設計見直し」の好機
AccessのCascading combo and list boxes with LinkMasterFields/LinkChildFieldsは、コンボボックスやリストボックスの親子連動を、より標準的なプロパティ設定で実現しやすくする更新です。国→都市、部門→社員、カテゴリ→商品といった典型的なカスケード コンボボックスでは、VBAのAfterUpdateやRowSourceの書き換えを減らせる可能性があります。
一方で、実務ではデータ型、連携キー、既存VBA、Accessの更新チャネル、Runtime環境を確認しないまま導入すると、候補が表示されない、二重に絞り込まれる、利用者端末だけ動かないといった問題が起きやすくなります。
次に取るべき行動は、既存Accessアプリの棚卸しです。カスケード コンボボックスを使っているフォームを洗い出し、単純な親子連動は新プロパティの候補、複雑な業務ルールを含むものは従来方式を維持する候補として分類しておきましょう。一般提供後は、検証端末で小さなフォームから試し、問題がなければ段階的に本番フォームへ反映するのが安全です。
コメント