概要
| この記事の結論 「このレコードセットは更新できません」は、フォームやクエリが参照しているレコードセットをAccessが更新可能と判断できないときに表示されます。まずフォームのレコードソースを直接開き、そこで編集できるかを確認してください。更新できなければ、主キー・一意インデックス、結合、クエリ種別、フォーム設定、ODBC・権限・読み取り専用・ロックの順に切り分けると原因を特定しやすくなります。 |
この記事でわかること
- エラーが出たときに最初に確認する「レコードソース」の見方
- 主キー・一意インデックス不足や結合キー重複の確認方法
- 集計・クロス集計・UNION・GROUP BY・DISTINCTなど、更新できないクエリの種類
- フォームのRecordsetType、更新の許可、編集ロックの確認ポイント
- ODBCリンク、読み取り専用、権限、レコードロックを含む最短の切り分け手順
この記事の主な内容
1.「このレコードセットは更新できません」とは？まずレコードソースを確認
2.原因① 主キー・一意インデックスがない／結合キーを一意に特定できない
3.原因② リレーション・結合構造の問題｜1対多・多対一対多を正しく理解する
4.原因③ 集計・クロス集計・UNION・GROUP BY・DISTINCTなど更新できないクエリ
5.原因④ フォーム設定・ODBC・読み取り専用・権限・レコードロック
6.最短で直すための切り分け手順と、直らない場合の考え方
7.まとめ
8.よくある質問（FAQ）
想定読了時間：約12～15分
1. 「このレコードセットは更新できません」とは？まずレコードソースを確認
このメッセージが出たとき、最初からフォームを作り直す必要はありません。多くの場合、フォームそのものではなく、そのフォームが表示しているテーブルやクエリの「更新可能性」に原因があります。
Accessのフォームは、［レコードソース］に指定されたテーブルやクエリをもとにデータを表示します。そのため、レコードソースが読み取り専用になっていれば、フォーム側で入力欄が見えていても保存できません。まず「どのフォーム設定が悪いか」ではなく、「元データを直接開いたときに更新できるか」を確認するのが最短です。
最初の確認は「フォーム → レコードソース → クエリ／テーブル」の順
対象フォームをデザインビューで開き、プロパティシートの［データ］タブから［レコードソース］を確認する
レコードソースに指定されているクエリまたはテーブルを直接開く
データシート上で既存データを変更できるか、新規レコードを追加できるかを確認する
直接開いても編集できなければ、フォームではなくレコードソース側の設計から調べる
「全部更新できない」のか「一部のフィールドだけ更新できない」のかを分ける
更新可否はレコードセット全体で一律とは限りません。たとえば平均値や合計値などの集計フィールドは編集できませんが、同じクエリ内の別フィールドは編集できる場合があります。Microsoftも、クエリ自体を編集できないケースと、特定フィールドだけ編集できないケースを分けて説明しています。
| 症状 | 疑う場所 | 次に確認すること |
|---|---|---|
| クエリを直接開いても何も編集できない | クエリ構造・主キー・結合・権限 | 主キー／一意性、クエリ種別、結合線、読み取り専用を確認 |
| 既存レコードは編集できるが新規追加できない | フォーム設定・クエリ構造 | AllowAdditions、結合先レコードの有無などを確認 |
| 特定の計算列・集計列だけ編集できない | フィールドの性質 | 計算結果や集計結果は直接編集しない |
| クエリでは編集できるがフォームで編集できない | フォームプロパティ | RecordsetType、AllowEdits、Lockedを確認 |
2. 原因① 主キー・一意インデックスがない／結合キーを一意に特定できない
複数テーブルを結合したクエリで更新できないときは、「Accessが表示中の1行を、基になるテーブルのどの1行へ反映すればよいか特定できるか」が重要です。主キーや一意インデックスは、その行を一意に識別するための代表的な仕組みです。
特にマスターテーブルなど「1側」に相当するテーブルで、結合に使う項目が重複していたり、一意なキーが存在しなかったりすると、Accessが更新先を安全に特定できない構造になります。まずテーブル設計を確認し、更新対象を一意に識別できるキーがあるかを確認しましょう。
主キーがないときの確認ポイント
- テーブルに主キーが設定されているか
- 主キー以外の項目を結合キーにしている場合、その値に重複がないか
- 複合キーで一意になる設計なら、必要な全フィールドがキーとして扱われているか
- リンクテーブルの場合、Access側で一意キーが正しく認識されているか
| 注意 重複データが存在する列を、エラー解消だけを目的にそのまま主キーへ変更してはいけません。主キー設定前に重複・Null・既存リレーション・VBAやクエリへの影響を確認し、必ずバックアップを取ってから作業します。 |
ODBCリンクテーブルでは「一意インデックスの認識」も重要
SQL ServerなどをODBCリンクしている場合、元テーブルに一意なキーがあっても、Access側でその一意性を正しく認識できていないと更新できないことがあります。Microsoftは、一意インデックスを持たないリンクODBCテーブルは更新できない場合があること、さらにリンクテーブルの一意インデックスを構成する全フィールドをクエリ出力へ含める必要があるケースを案内しています。
| 確認項目 | 正常な状態 | 問題があるときの対処 |
|---|---|---|
| ローカルテーブルの主キー | 更新対象行を一意に識別できる | 主キー候補の重複・Nullを整理してから設定 |
| 結合キー | 1側で値が一意 | 重複原因を解消し、適切なキーで結合し直す |
| ODBCリンクの一意キー | Access上でもキーとして認識される | リンク再作成や一意インデックス設定を確認 |
| 複合一意インデックス | 構成フィールドを必要に応じ出力へ含める | 不足フィールドをクエリへ追加する |
3. 原因② リレーション・結合構造の問題｜1対多・多対一対多を正しく理解する
「1対多のクエリは更新できない」と覚えるのは正確ではありません。1対多でも更新できるケースはあり、重要なのは更新対象の行と結合先の行をAccessが矛盾なく特定できることです。
一方で、複数の1対多関係をまたいだ「多対一対多」のような構造では、1つの表示行が複数の基データ候補に対応しやすくなります。Microsoftは、3つ以上のテーブルに基づき、多対一対多のリレーションシップを持つクエリはデータシートから編集できないケースとして挙げています。
1対多で確認したい3つのポイント
- 結合線が正しく設定され、結合すべきテーブルやクエリが未結合のまま残っていないか
- 「多」側の結合フィールドが、必要に応じクエリの出力フィールドへ含まれているか
- 外部結合を使っている場合、「1側」に値が存在しない行を編集しようとしていないか
Microsoftの案内では、1対多のクエリで「多」側の結合フィールドが出力されていない場合、「1」側の結合フィールドを編集できないケースがあります。この場合は、「多」側の結合フィールドをクエリ出力へ追加することで改善できることがあります。
「ダイナセット（矛盾を許す）」は最後に検討する
フォームのRecordsetTypeには「ダイナセット（矛盾を許す）」があります。Microsoftは、通常のクエリデータシートでは編集できない多対一対多の構造でも、フォーム側のRecordsetTypeをこの設定にすることで編集できる場合があると説明しています。
ただし、これは「設計上の問題を直さなくてもよい」という意味ではありません。更新対象となるテーブルが増え、どこへ値が書き込まれるかを理解しにくくなるため、主キー・結合・参照整合性を確認したうえで、必要なフォームだけに限定して使用するのが安全です。
4. 原因③ 集計・クロス集計・UNION・GROUP BY・DISTINCTなど更新できないクエリ
クエリの種類によっては、設計上「結果を見るためのクエリ」であり、データシートから元テーブルへ書き戻すことを想定していません。主キーを追加しても解決しない場合は、まずクエリ自体が更新可能な種類かを確認します。
| クエリ／設定 | 更新可否の考え方 | 主な対処 |
|---|---|---|
| クロス集計クエリ | 基本的に更新不可 | 入力は元テーブルや専用フォームで行う |
| SQL固有クエリ（UNIONなど） | 基本的に更新不可 | 元テーブル側で更新する／更新用クエリを別に用意 |
| Totals・GROUP BY | 集計結果のため更新不可 | 集計前の明細を更新する |
| 集計フィールド（Sum、Avg等） | そのフィールドは更新不可 | 元となる明細値を修正する |
| 一意の値＝はい（DISTINCT） | クエリ結果は更新不可 | 重複排除が不要なら［一意の値］を［いいえ］へ |
| 通常の選択クエリ | 条件次第で更新可能 | 主キー・結合・権限等を確認 |
「一意の値＝はい」は見落としやすい
重複を消すためにクエリの［一意の値］を［はい］にすると、SQLではDISTINCTに相当する動作になります。Microsoftは、この設定が［はい］のときクエリ結果は更新できないと明記しています。デザインビューの何もない場所をクリックし、プロパティシートで［一意の値］を確認してください。
| SELECT DISTINCT 顧客コード, 顧客名 FROM T_顧客; |
上記のようなDISTINCTは一覧表示には便利ですが、編集用のレコードソースとしては適しません。入力・更新用フォームでは、更新対象を一意に特定できる通常の選択クエリを用意し、重複排除が必要な一覧表示とは役割を分けると設計が分かりやすくなります。
GROUP BYやUNIONは「表示用」と「更新用」を分ける
| SELECT 部門コード, Sum(金額) AS 合計金額 FROM T_売上 GROUP BY 部門コード; SELECT 顧客コード, 顧客名 FROM T_顧客_東日本 UNION SELECT 顧客コード, 顧客名 FROM T_顧客_西日本; |
集計結果や複数データソースを統合した結果は、参照・分析には向いています。一方、入力画面のレコードソースとして使う場合は更新できないため、明細テーブルや更新可能な選択クエリを別に用意するのが基本です。
5. 原因④ フォーム設定・ODBC・読み取り専用・権限・レコードロック
レコードソース側が更新可能でも、フォームの設定やファイルの状態によって編集できないことがあります。クエリを直接開くと編集できるのにフォームでは変更できない場合は、フォームプロパティから確認しましょう。
フォームのRecordsetTypeを確認する
| RecordsetType | 意味 | 更新の考え方 |
|---|---|---|
| ダイナセット（既定） | 通常の更新可能レコードセット | 更新可能な元データであれば編集できる |
| ダイナセット（矛盾を許す） | 複数テーブルの更新範囲を広げる設定 | 一部の複雑な結合で有効だが、設計確認後に使用 |
| スナップショット | 読み取り専用のレコードセット | 連結コントロールは編集できない |
［スナップショット］になっているフォームは閲覧専用です。更新画面で誤って設定されていないか確認してください。一方、「ダイナセット（矛盾を許す）」へ切り替えるだけで問題が消える場合でも、主キーや結合構造の問題が隠れていないか確認することが重要です。
AllowEditsとLockedは役割が違う
フォーム全体で既存レコードの編集を許可するかは［更新の許可（AllowEdits）］で制御します。［いいえ］なら保存済みレコードは編集できません。対して、テキストボックスなど個別コントロールの［編集ロック（Locked）］が［はい］なら、そのコントロールだけ編集できません。
| 設定 | 対象範囲 | 確認ポイント |
|---|---|---|
| 更新の許可（AllowEdits） | フォーム全体の既存レコード | 更新画面なら通常［はい］ |
| 追加の許可（AllowAdditions） | 新規レコード追加 | 追加できない場合に確認 |
| 編集ロック（Locked） | 個別コントロール | 特定項目だけ入力できない場合に確認 |
| レコードセット（RecordsetType） | フォームのレコードセット全体 | Snapshotなら読み取り専用 |
ODBC・読み取り専用・権限・レコードロックも切り分ける
Accessの設定が正しくても、外部データやファイル側が更新できない状態なら保存できません。Microsoftは、更新権限がない、データベースを読み取り専用で開いている、読み取り専用ドライブ上にある、別ユーザーがレコードをロックしている、といったケースを更新できない原因として挙げています。
| 原因 | 確認する場所 | 対処 |
|---|---|---|
| ODBCリンクの一意キー不足 | リンクテーブル・元DB | 主キー／一意インデックスを整備しリンクを確認 |
| DBを読み取り専用で開いている | Access起動方法・ファイル属性 | 読み取り専用を解除して開き直す |
| 保存先への更新権限がない | フォルダ・共有・DB権限 | 必要な更新権限を付与する |
| 別ユーザーがレコードをロック中 | 複数人利用時の操作状況 | ロック解除後に再実行する |
| リンク先・接続情報の不整合 | ODBC・リンクテーブル | リンク更新、DSN・ドライバ・接続先を確認 |
| 主キーやクエリを直しても更新できない場合は、Access全体の設計を確認します フォームのレコードソース、複雑な結合クエリ、主キー・リレーション、ODBC／SQL Serverリンク、VBA処理まで含めて既存Accessを調査できます。業務を止めずに原因を切り分け、必要な範囲だけ改修する方針をご提案しますのでお気軽にご相談ください。 |
6. 最短で直すための切り分け手順と、直らない場合の考え方
原因候補を一度に触ると、どの変更で直ったのか分からなくなります。次の順番で「更新できる／できない」を一つずつ確認すると、最短で原因へたどり着けます。
| 順番 | 確認内容 | 判断 |
|---|---|---|
| 1 | フォームのレコードソースを確認 | 元がテーブルかクエリかを特定する |
| 2 | レコードソースを直接開いて編集 | 直接編集できなければクエリ／テーブル側へ |
| 3 | クエリ種別を確認 | クロス集計・UNION・GROUP BY・DISTINCT等なら更新用設計を分離 |
| 4 | 主キー・一意インデックスを確認 | 更新対象行を一意に識別できるか確認 |
| 5 | 結合線・1対多・多対一対多を確認 | 結合漏れ、重複、出力フィールドを確認 |
| 6 | フォームプロパティを確認 | Snapshot、AllowEdits、Locked等を確認 |
| 7 | ODBC・権限・読み取り専用・ロック | Access外の更新条件を切り分ける |
| 8 | バックアップ後に設計変更 | 本番DBでは影響範囲を確認してから修正 |
補足：DAOでレコードセットが更新可能か確認する
VBAを扱える場合は、DAOのRecordset.Updatableプロパティでレコードセットに更新可能なフィールドがあるかを確認できます。これは原因を自動修復するものではありませんが、診断の補助には便利です。
| Public Sub CheckUpdatable() Dim rs As DAO.Recordset Set rs = CurrentDb.OpenRecordset(“qry対象クエリ”, dbOpenDynaset) Debug.Print “Updatable = ” & rs.Updatable rs.Close Set rs = Nothing End Sub |
Microsoft Learnでは、Snapshot型のRecordsetはUpdatable=Falseになり、ダイナセットでも読み取り専用フィールドを含む場合があると説明しています。Updatable=Trueでも「すべてのフィールドが編集できる」とは限らない点に注意してください。
本番データベースで主キーやリレーションを変更する前に
- ACCDBファイルを必ずバックアップする
- 主キー候補の重複・Nullを事前に抽出する
- 既存クエリ、フォーム、VBA、リンクテーブルへの影響を確認する
- 複数人利用中なら利用者を止め、排他的に作業できる時間を確保する
- 変更後は入力・編集・新規追加・削除・帳票・外部連携まで一連の業務をテストする
直らない場合は「フォームの問題」ではなく設計全体を見直す
長年継ぎ足してきたAccessでは、1つのフォームの背後に多数のクエリ、サブフォーム、VBA、ODBCリンクが連鎖していることがあります。この場合、画面だけを修正しても根本原因が残り、別の場所で同じ更新エラーが発生しやすくなります。
複数テーブルを結合して直接更新する設計が複雑になりすぎている場合は、入力処理と集計処理を分離する、更新専用クエリを用意する、データ層をSQL Serverへ移して主キー・制約・権限を整理する、といった見直しも選択肢です。Accessの画面を残し、データだけSQL Serverへ移行する構成も可能です。
7. まとめ｜「更新先の1行を特定できるか」を軸に確認する
「このレコードセットは更新できません」が表示されたら、まずフォームのレコードソースを直接開き、元のクエリやテーブル自体が更新できるかを確認します。直接編集できなければ、フォームを作り直しても解決しない可能性が高いからです。
原因を切り分けるときは、主キー・一意インデックス、結合構造、クエリ種別、フォームのRecordsetType、ODBC・読み取り専用・権限・レコードロックの順に確認します。特に、集計・クロス集計・UNION・GROUP BY・DISTINCTは、結果表示には使えても更新用途には向きません。
また、1対多だから必ず更新できないわけではありません。Accessが表示中のレコードを基になるテーブルのどの1行へ反映すべきか一意に判断できるか、という視点で設計を見ることが重要です。
| Accessの更新エラー・既存DBの修正でお困りの場合 複数テーブルのクエリを直しても更新できない、主キーやリレーションを変更するのが不安、SQL Server／ODBC移行後から更新できなくなった、VBAやサブフォームが絡み原因を特定できない、といったケースは専門調査が有効です。 |
8. よくある質問（FAQ）
フォーム設定が原因の場合もありますが、多くはフォームのレコードソースであるクエリやテーブル側の更新可否を先に確認した方が早く切り分けられます。レコードソースを直接開いて編集できるか確認してください。
いいえ。主キーは重要ですが、クロス集計、UNION、GROUP BY、DISTINCTなどクエリ種別そのものが更新不可の場合や、読み取り専用・権限・フォーム設定が原因の場合は主キーだけでは解決しません。
一律に更新できないわけではありません。更新対象行を一意に特定できる構造なら編集できる場合があります。ただし、3テーブル以上の多対一対多など複雑な構造では更新できないケースがあります。
基本的に、集計クエリやGROUP BY、クロス集計、UNIONなどはデータシートからの直接更新には向きません。入力・更新は元テーブルまたは更新可能な選択クエリで行い、集計・統合クエリは表示用に分けます。
はい。平均、合計などの集計フィールドや計算結果は直接編集できないことがあります。同じクエリ内の他フィールドが更新できる場合は、クエリ全体が読み取り専用とは限りません。
一部の複雑な結合では編集可能になる場合がありますが、万能な解決策ではありません。どのテーブルが更新されるか、主キーや結合が正しいかを確認したうえで限定的に使用します。
元テーブルの主キー・一意インデックス、Access側でのキー認識、複合一意インデックスを構成するフィールドがクエリ出力に含まれているか、接続権限やドライバ、リンク状態を確認します。
参考情報
- Microsoft Support｜クエリのデータを編集する
https://support.microsoft.com/ja-jp/access/edit-data-in-a-query - Microsoft Support｜RecordsetType/レコードセット プロパティ
https://support.microsoft.com/ja-jp/access/recordsettype-property - Microsoft Support｜UniqueValues Property
https://support.microsoft.com/en-us/access/uniquevalues-property - Microsoft Learn｜Recordset.Updatable プロパティ (DAO)
https://learn.microsoft.com/ja-jp/office/client-developer/access/desktop-database-reference/recordset-updatable-property-dao - Microsoft Support｜AllowEdits/更新の許可 プロパティ
https://support.microsoft.com/ja-jp/access/allowedits-property - Microsoft Support｜Locked/編集ロック プロパティ
https://support.microsoft.com/ja-jp/access/locked-property