Accessクエリで連番を作成する方法 DCountと並び順の注意点

概要

この記事の結論
Accessのクエリで表示用の連番を付けるには、DCount関数で現在行の主キー以下にあるレコード数を数えます。元のIDに欠番があっても、抽出対象と数える対象、並び順をそろえれば1からの番号を表示できます。ただし、この番号はデータの追加や削除で変わります。請求書番号などの固定番号や主キーには流用せず、用途に応じて採番方法を分けることが大切です。
クエリの連番とは、抽出した行の順序を読者に示すために計算する表示用の番号です。

この記事でわかること

  • DCountで1からの連番を作成する
  • 絞り込みと並び替えに合わせて採番する
  • グループ別の連番と大量データに対応する
  • 連番がずれる原因を切り分ける

この記事の主な内容

  1. 表示用の連番と主キーを使い分ける
  2. DCountで1からの連番を作成する
  3. 絞り込みと並び替えに合わせて採番する
  4. グループ別の連番と大量データに対応する
  5. 連番がずれる原因を切り分ける
  6. 運用前の確認と用途別の選び方
  7. よくある質問

想定読了時間:約15分~20分


表示用の連番と主キーを使い分ける

クエリで作る連番は、一覧に1、2、3と表示するための計算値です。テーブルにある売上IDが2、5、9でも、結果に1、2、3を付けられます。欠番を埋めるために元のIDを書き換える必要はありません。主キーとは1件を一意に識別する項目であり、別のテーブルから参照されることがあります。

まず番号の用途を決める

見やすさのための番号と、データを追跡する番号は目的が違います。表示用連番は抽出条件やデータの増減によって変わっても構いません。一方、伝票番号や請求書番号は、発行済み文書とデータを継続して対応付ける必要があります。DCountで計算した値を、そのまま固定番号の代わりにしないでください。

番号の種類主な目的番号が変わってよいか
表示用連番一覧の何行目かを示す再抽出で変わり得る
主キーのID他のデータと同じ1件を識別する原則として変更しない
業務上の番号発行済み伝票などを追跡する業務規程に従い固定管理する
表示用連番・主キー・業務番号の役割と変更可否を比較する図

オートナンバーの欠番は異常とは限らない

オートナンバーは、隙間のない見た目の番号を保証する仕組みではありません。削除や登録の取り消しなどで欠番が生じても、識別子としての役割を果たしていれば問題ありません。欠番を詰めるための再採番は、関連テーブルとの対応を壊す原因になります。印刷物の番号を整えたいだけなら、表示側で解決します。


DCountで1からの連番を作成する

DCountは、指定したテーブルや保存クエリの中で、条件に合うレコード数を数える関数です。「現在行のID以下の行が何件あるか」を求めれば、IDの小さい順に1からの連番を作れます。ここではIDが重複せず、Nullもない数値型であることを前提にします。

練習用データを準備する

検証用のAccessファイルに、T_売上というテーブルを用意します。売上IDは数値型の長整数で主キー、部門IDも長整数、金額は通貨型とします。以下は説明用のサンプルです。既存システムの主キーを練習のために変更せず、別のテーブルで試してください。

売上ID部門ID金額
2101000
5201000
9103000

IDが2なら条件「売上ID<=2」に合うのは1件です。IDが5なら2と5の2件、IDが9なら3件になります。IDの値そのものを足し引きしているのではなく、条件に合う行を数えている点がポイントです。

IDが2、5、9の3行で現在行以下の件数が1、2、3になる仕組み

デザインビューで計算列を追加する

1. [作成]タブから[クエリデザイン]を開き、T_売上を追加します。

2. 売上ID、部門ID、金額を下のデザイングリッドに追加します。

3. 空いている列の[フィールド]行に、次の式を入力します。

4. 売上ID列の[並べ替え]を[昇順]に設定します。

5. データシートビューに切り替え、1、2、3と表示されるか確認します。

連番: DCount(“*”,”T_売上”,”[売上ID] <= ” & [売上ID])

「連番:」は結果列の名前です。第1引数の”*”は行を数える指定、第2引数は対象テーブル、第3引数は条件の文字列です。最後の[売上ID]には現在行の値が入り、半角の&で条件文字列につなぎます。数値型のIDなので、値の前後に引用符を加える必要はありません。

テーブル追加、計算式入力、ID昇順、結果確認の4手順

SQLビューで確認する

同じ処理をSQLで書く場合は、次のようになります。SQLはデータベースへの処理を記述する言語です。例のORDER BYは結果の表示順を指定します。採番用の条件だけを設定しても、結果の表示順まで自動的に固定されるわけではありません。

SELECT S.[売上ID], S.[部門ID], S.[金額],
 DCount(“*”,”T_売上”,
 “[売上ID] <= ” & S.[売上ID]) AS [連番]
FROM [T_売上] AS S
ORDER BY S.[売上ID];

DCountの返り値は公式資料上Variantです。「必ず文字列になるのでValが必要」とは扱いません。通常の件数計算にValを付けることを前提にせず、表示の寄せ方だけでデータ型を判断しないでください。数値型を明示する必要がある処理では、値の範囲を確認してCLngなどを検討します。


絞り込みと並び替えに合わせて採番する

連番のずれは、画面に出す対象とDCountが数える対象の違いで発生します。例えば部門10だけを表示しても、DCountがT_売上全体を数えれば、ID2とID9には1と3が付きます。表示対象が2行でも、2番目の行が「2」になるとは限りません。

絞り込んだ保存クエリを採番元にする

まず部門10だけを抽出するQ_連番対象を保存します。次に、このクエリを表示元とDCountの対象の両方に使用します。2段階に分けることで、絞り込み条件を一方だけ修正してしまうミスを減らせます。DCountの対象には、入力パラメーターを要求しない保存クエリを使います。

SELECT [売上ID], [部門ID], [金額]
FROM [T_売上]
WHERE [部門ID] = 10;

続いて別のクエリを作り、次のSQLを設定します。結果はID2が連番1、ID9が連番2です。フォームのフィルターだけを後から変えても、この保存クエリの条件は自動では変わりません。画面側の条件と採番対象を、同じ定義で管理する必要があります。

SELECT Q.[売上ID], Q.[部門ID], Q.[金額],
 DCount(“*”,”Q_連番対象”,
 “[売上ID] <= ” & Q.[売上ID]) AS [連番]
FROM [Q_連番対象] AS Q
ORDER BY Q.[売上ID];

抽出した保存クエリを表示とDCountの両方に使う構成

同じ値には主キーで優先順位を付ける

金額順に表示したい場合、金額だけを数える条件では同額の行に同じ番号が付きます。サンプルの1000円は2行あるためです。「金額が小さい行」または「同額で売上IDが現在行以下の行」を数えれば、順序が1つに決まります。金額がNullの場合は、先に除外または配置ルールを決めます。

次はDCountを使わず、同じテーブルの行数を数える相関サブクエリの例です。相関とは、内側の処理で外側の現在行を参照することを意味します。金額とIDの並びを条件とORDER BYでそろえ、サンプルで結果を検算してから利用してください。

SELECT A.[売上ID], A.[金額],
 (SELECT Count(*) FROM [T_売上] AS B
  WHERE B.[金額] < A.[金額]
     OR (B.[金額] = A.[金額]
         AND B.[売上ID] <= A.[売上ID])) AS [連番]
FROM [T_売上] AS A
WHERE A.[金額] Is Not Null
ORDER BY A.[金額], A.[売上ID];

金額が同額のときに売上IDを追加して順序を一意にする図

この例も対象範囲を限定したい場合は、内側と外側の両方に同じ範囲を適用します。文字列や日付をDCountの条件文字列に埋め込む場合は、引用符や日付表記の扱いが追加で必要です。初心者の段階では、数値型の一意キーと保存クエリを使う構成から始めると切り分けやすくなります。

クエリの採番・速度改善を整理したい方へ

検証用データで手順を確かめても解決しない場合や、複数の画面・テーブル・利用者への影響を整理する必要がある場合は、Accessの教科書へご相談ください。現在の構成、起きている症状、期待する結果をまとめると、確認すべき範囲を伝えやすくなります。


グループ別の連番と大量データに対応する

部門ごとに1から振り直すには、「同じ部門である」という条件を数える範囲に加えます。ここでも部門IDと売上IDは数値型で、Nullなしを前提とします。表示順は部門ID、売上IDの順に指定します。グループを分けずに表示すると、番号が途中で戻るように見えるため注意してください。

部門内連番: DCount(“*”,”T_売上”,”[部門ID] = ” & [部門ID] & ” AND [売上ID] <= ” & [売上ID])

表示順部門ID売上ID部門内連番
11021
21092
32051
部門IDと売上IDの条件を組み合わせて部門ごとに採番する例

遅くなったら処理する場所を見直す

DCountや相関サブクエリは、結果の各行について数える処理が必要になるため、件数や接続方式によって時間がかかります。まず抽出範囲を必要な期間に絞り、主キーや条件項目のインデックスを確認します。「何件まで必ず速い」という一律の基準はなく、実際の環境で測定する必要があります。

印刷物に行番号が欲しいだけなら、レポートのテキストボックスに=1を設定し、[集計実行]を[全体]または[グループ全体]にする方法があります。レポート側の並べ替え・グループ設定と合わせて使います。これでクエリ自体の表示連番や固定番号が作られるわけではありません。

SQL Serverにデータがある構成では、サーバー側でROW_NUMBERを計算し、必要な結果だけAccessへ渡す設計も候補です。ただしROW_NUMBERはAccessの通常クエリへそのまま書ける機能ではありません。接続方式と処理場所を明確にし、単にSQLを書き換えるだけで対応できると考えないでください。


連番がずれる原因を切り分ける

式を大きく変更する前に、数える対象、順序、一意性の順で確認します。件数と順序を3~5行のサンプルで手計算し、期待した結果をメモすると原因を絞れます。見た目だけを合わせるためにIDを書き換えたり、エラーを空文字に置き換えたりすると、誤りが見えなくなります。

症状主な確認点対処の方向
1、3、5のように飛ぶ表示範囲とDCountの対象が違う共通の保存クエリを使う
番号が逆順になるORDER BYと採番条件が違う両方の順序を合わせる
同じ番号が出る並び替え項目に同値がある主キーで順序を確定する
パラメーター入力を求められるフィールド名・クエリ名の誤記実際の名前と照合する
追加後の表示が古い結果を再取得していない保存後に再クエリする
処理に時間がかかる各行の計算・対象件数・接続先範囲と処理場所を見直す
対象範囲、並び順、重複、再クエリを点検する4項目

再クエリで番号が変わることを共有する

データの追加・削除後に結果を再取得すると、表示用連番が変わる場合があります。業務で「一覧の3番の人」と伝えていると、別の時刻の一覧では違う人を指すおそれがあります。問い合わせや引き継ぎでは、変わらない顧客IDや伝票IDを併記する運用にしてください。


運用前の確認と用途別の選び方

最初は一意の数値キーの昇順で作り、期待結果を確認できたら抽出条件やグループを追加します。フィルター、並べ替え、データの追加・削除をそれぞれ試し、番号がどう変わるかを確認します。固定番号が必要な場合は、採番の保存、同時利用時の重複防止、取消時の扱いを別途設計します。

1. 元データと関連テーブルのIDを変更していないか確認します。

2. 表示対象と採番対象が一致するか確認します。

3. 同値の行を含めても並び順が一意に決まるか確認します。

4. 追加・削除後の再クエリと実データ量での速度を確認します。

クエリ表示、レポート印刷、固定業務番号の実装を分ける図

表示用はクエリ、印刷用はレポート、発行済み文書の番号は専用の採番管理というように、目的に合う場所で処理することが重要です。DCountの基本式を覚えるだけでなく、何を数えてどの順番で表示しているかを説明できる状態にすると、後の修正も容易になります。


よくある質問

見た目を整える目的で主キーを振り直すことは避けてください。主キーは別のテーブルや帳票から同じデータを識別するために使われ、番号の変更で対応関係が壊れることがあります。欠番があるだけではデータの異常とはいえません。画面で1から順に見せたいなら、元のIDを保持したままクエリに表示用連番を追加します。どこから参照されているか分からない既存システムでは、IDの変更より先に関連テーブルと利用箇所を確認しましょう。

画面に表示している行と、DCountが数えている行が一致していない可能性があります。例えば部門10だけを表示しても、関数の対象が全社のテーブルなら、非表示の部門の行も数えます。まず抽出条件を持つ保存クエリを作り、そのクエリを表示元とDCountの対象の両方に設定してください。フォームのフィルターを変更する運用では、その条件が採番側にも反映される設計が必要です。表示を絞っただけで関数の対象まで変わるとは限りません。

採番に使った順序と、実際に表示する順序が違うためです。売上ID以下の件数を数える式はID順の番号を作るので、後から金額の降順に並べ替えると番号も入れ替わります。連番を表示順にそろえたい場合は、金額と主キーなどで並び順を一意に決め、その条件で行数を数えてください。利用者が自由に並べ替える画面では、番号の意味を固定するか、並べ替えに応じて計算を作り直すかを先に決める必要があります。

必須ではありません。MicrosoftのDCountの説明では返り値はVariantとされており、必ず文字列になる関数として扱うのは不適切です。左寄せに見えるという理由だけで文字列型と断定せず、クエリの式や書式、出力先での扱いを確認してください。数値型を明示したい場合は、想定する値の範囲に合う型変換を検討します。Valは文字列を数値として読み取る関数であり、連番の範囲や並び順のずれを直すための機能ではありません。

付けられます。同じ値が複数ある場合にどの行を先にするか決めるため、売上IDなどの一意キーを追加します。例えば「金額の昇順、同額なら売上IDの昇順」と定義し、金額が小さい行と、同額でIDが現在行以下の行を数えます。日付を使う場合も同様ですが、時刻を含むか、Nullがあるかを確認してください。単に金額以下や日付以下の件数を数えるだけでは、同じ値の行に同じ番号が付き、行番号として一意になりません。

部門IDを数える条件に加えれば、部門ごとに1から採番できます。数値型の部門IDなら、同じ部門であり、売上IDが現在行以下という2条件をANDで組み合わせます。表示順も部門ID、売上IDの順にそろえてください。部門名の表記ゆれがある場合は、名前でまとめるより管理用のIDを使う方が安定します。また、部門未設定の行を除外するのか、未設定グループとして扱うのかを決め、Nullを条件に組み込む方法も別途整理します。

まず必要な期間や部門に対象を絞り、条件項目と主キーのインデックス、リンク先との通信を確認します。DCountは結果の行ごとに数えるため、件数が増えるほど負荷が大きくなることがあります。印刷時の番号だけならレポートの集計実行、SQL Server上のデータならサーバー側での採番も検討できます。効果はデータ量と接続環境で変わるため、同じ条件で実行時間を測定してください。式を複雑にするだけで必ず高速化するわけではありません。

DCountで作った表示用連番を、そのまま請求書番号として使うことは勧められません。データの削除や抽出条件の変更で番号が変わり、複数人の同時登録でも重複を防げないためです。請求書番号には、確定した番号を保存する項目、一意性を守る制約、同時採番の制御、取消や再発行の規則が必要です。すでに社外へ発行した番号との整合も確認します。一覧の行番号と取引の識別番号を分けて管理することが、追跡性を保つ基本です。

Accessの教科書へのご相談

クエリの採番・速度改善を整理したい方へ

検証用データで手順を確かめても解決しない場合や、複数の画面・テーブル・利用者への影響を整理する必要がある場合は、Accessの教科書へご相談ください。現在の構成、起きている症状、期待する結果をまとめると、確認すべき範囲を伝えやすくなります。

関連記事

Accessクエリでグループ化して集計

Accessのフォームフィルターの使い方

Accessで2つのテーブルを比較


参考情報

確認日:2026年10月12日。

Microsoft Learn DCount
https://learn.microsoft.com/en-us/office/vba/api/access.application.dcount

Microsoft Support DCount関数
https://support.microsoft.com/ja-jp/access/dcount-function

Microsoft Support Count関数
https://support.microsoft.com/en-us/access/functions/count-function

Microsoft Learn レポートの集計実行
https://learn.microsoft.com/ja-jp/office/vba/api/access.textbox.runningsum

TOP