概要
| この記事の結論 Accessのクエリでは、空いている列の［フィールド］行に「金額: [数量]*[単価]」と入力すると、演算フィールドを作成できます。先頭は列名と半角コロンで、Excelのように等号から始めません。計算結果はクエリ実行時に求められ、通常の保存項目とは別です。Null、ゼロ除算、端数処理のルールを決めてから、通常値と例外値の両方で確かめましょう。 クエリの演算フィールドとは、元データを式で計算して結果を表示する列です。 |
この記事でわかること
- 列名と式を半角コロンで区切る
- 元のデータ型を先に確認する
- 未入力を0にするか業務で決める
- 分母の0を式の内側で避ける
- 端数処理と計算時点を固定する
この記事の主な内容
- 演算フィールドと保存する項目の違い
- 数量と単価から金額を作成する
- 実務で使う計算式と入力場所の使い分け
- Nullとゼロ除算を安全に扱う
- 計算できない原因と金額の検算
- 計算式を共通化して帳票へ引き継ぐ
- よくある質問
想定読了時間：約15分～20分
演算フィールドと保存する項目の違い
クエリの演算フィールドは、保存済みの数量や単価を式へ渡し、金額などの結果を表示するために使います。実行するたびに元データを基に計算するため、同じ計算結果を別の列へ手入力して更新し忘れる問題を減らせます。[1]
ただし、「計算できる値は何でも保存しない」が常に正解とは限りません。見積確定時の金額や当時の単価を後日も再現する業務では、何を確定履歴として残すかを決める必要があります。計算の便利さと、過去の取引を再現するための保存設計は分けて考えましょう。
クエリとテーブルと画面で役割が異なる
| 作る場所 | 主な目的 | 注意点 |
|---|---|---|
| クエリの演算フィールド | 取り出したデータを計算し再利用する | 通常は計算結果へ直接入力しない |
| テーブルの計算データ型 | テーブル内の項目から結果を求める | 利用できる式や参照範囲に制約がある |
| フォーム・レポートの計算部品 | その画面や帳票で結果を表示する | 同じ式が多数の場所へ分散しやすい |
| 通常の保存フィールド | 確定時点の値などを保持する | 更新条件や再計算ルールが必要 |
この記事ではクエリの演算フィールドを扱います。表の同じ行で計算すること、複数行を合計すること、確定値として保存することは別の処理です。まず「1行の金額を出したい」のか「顧客ごとに合計したい」のかを決めると、必要なクエリを選びやすくなります。
数量と単価から金額を作成する
基本の書式は「新しい列名: 計算式」です。半角コロンの左側が結果の列名、右側が計算内容になります。ここでは、架空のT_売上明細にある数量と単価を掛け、金額を表示します。数量は数値型、単価は通貨型を想定します。
デザインビューで入力する手順
1. 既存クエリをコピーしてデザインビューで開くか、［作成］の［クエリデザイン］からT_売上明細を追加します。
2. 明細ID、数量、単価をデザイングリッドへ追加します。
3. 右側の空いている列の［フィールド］行をクリックします。
4. 半角の記号を使い、「金額: [数量]*[単価]」と入力します。
5. データシートビューへ切り替え、数量3、単価1200の行が3600になるか確認します。
6. 「Q_明細金額」として保存し、閉じて開き直します。
金額: [数量]*[単価]
「金額」は元テーブルに追加される保存列ではなく、このクエリの結果列です。計算結果を直接直すのではなく、元となる数量・単価、または計算ルールを修正します。結果画面の元項目を編集できるかはクエリの構成によるため、本番データを触らず試験用コピーで確認してください。
SQLビューではASで名前を付ける
SQLでは計算式の後ろへASと列名を置きます。デザインビューの「列名: 式」と意味は同じでも、書く順序が異なります。次のSQLはAccessの通常の選択クエリ用です。SQL Serverへ直接送るパススルークエリでは、関数や構文の違いを別に確認します。
SELECT [明細ID], [数量], [単価],
[数量]*[単価] AS [金額]
FROM [T_売上明細];
実務で使う計算式と入力場所の使い分け
クエリのフィールド行では、Excelのセルのように等号から書き始めません。フォームやレポートのテキストボックスの［コントロールソース］では等号を付けるため、入力場所を最初に確認しましょう。式が同じでも、先頭の書き方が変わります。[1][6]
| 入力場所 | 記述例 |
|---|---|
| クエリのフィールド行 | 金額: [数量]*[単価] |
| SQLビュー | [数量]*[単価] AS [金額] |
| 計算テキストボックス | =[数量]*[単価] |
四則演算と文字列と日付の例
| 目的 | クエリの式 | 確認すること |
|---|---|---|
| 値引き後の金額 | 差引額: [金額]-[値引額] | 値引額のNullをどう扱うか |
| 表示名をつなぐ | 氏名表示: [姓] & ” ” & [名] | 片方が空欄のときの空白 |
| 受注日の年を取り出す | 受注年: Year([受注日]) | 元が日付/時刻型か |
| 金額による区分 | 区分: IIf([金額]>=10000,”対象”,”対象外”) | 金額未入力を対象外にしてよいか |
計算式に条件分岐を使えば、金額帯や状態に応じた表示もできます。ただし、未入力という状態を「条件に当てはまらない」と同一視すると、確認すべき行が埋もれます。まず実際の項目名、型、Nullの有無を調べ、通常値だけでなく境界の値も試します。
1行の計算と複数行の合計を分ける
数量×単価は行ごとの計算です。一方、顧客別の合計は集計クエリの役割になります。先にQ_明細金額で金額を求め、そのクエリを基に顧客IDごとのSumを計算すると、明細と合計を別々に検算できます。結合で行が増えている場合は、正しい掛け算でも総額が膨らむため、件数も確認します。
Nullとゼロ除算を安全に扱う
Nullは「値が入っていない」状態で、0という数値ではありません。数量か単価がNullなら、通常の掛け算の結果もNullになります。結果が空欄のときは、式が壊れたと判断する前に、入力漏れや未確定値がないか調べてください。
Nzは業務上の意味を決めてから使う
値引額が未入力なら値引きなしとする業務であれば、Nz([値引額],0)として0へ置き換えられます。クエリでは第2引数を明示し、何へ置き換えるかを読み取れる式にします。ただし、単価未確定を0にすると無料の取引のように見えるため、同じ置換を無条件に広げてはいけません。[3]
差引額: [金額]-Nz([値引額],0)
IIfで割り算全体を囲むだけでは不十分
IIfは返さない側の式も評価するため、「分母が0ならNull、それ以外なら割り算」と外側だけで分岐しても、ゼロ除算が起きる可能性があります。分岐の中に危険な割り算を置かず、分母自体を安全な値へ置き換える構成にします。[4]
次の達成率の例は、目標がNullまたは0なら分母をNullへ置き換えます。実績もNullなら結果はNullです。計算できない状態を0％と混同しないため、未計算の行は別途確認対象にします。実績・目標はいずれも数値型を前提とします。
達成率: [実績]/IIf(Nz([目標],0)=0,Null,[目標])
| 実績 | 目標 | 期待する結果 |
|---|---|---|
| 80 | 100 | 0.8（パーセント表示なら80％） |
| 80 | 0 | Null |
| 80 | Null | Null |
| Null | 100 | Null |
この式を百分率表示にする場合、計算結果0.8へパーセント書式を設定します。先に100を掛けて80にしたうえでパーセント書式を使うと8000％となるため、値と表示形式を分けて確認してください。
Accessの計算式と金額の不一致を相談する
基本設定は、まずコピーしたクエリやレポートで試してください。複数の帳票や既存処理にまたがって不一致が出る場合は、対象名、操作手順、期待する結果、実際の結果を整理すると調査しやすくなります。Accessの教科書の問い合わせ窓口から、現在の状況をご相談ください。
計算できない原因と金額の検算
演算フィールドのトラブルは、式の入力場所、参照名、データ型、Null、業務ルールの順に切り分けます。パラメーター入力や型不一致が出たときに、画面へ適当な値を入力して先へ進めると、根本原因が隠れてしまいます。
表示形式と端数処理は別に決める
小数点以下の表示桁数を変えても、内部の計算値をその桁数へ確定する処理とは限りません。見た目が同じ100円でも、内部では100.4円を持つ場合があります。帳票の行合計と全体合計が違うときは、どの段階で端数を処理しているかを確認します。
Accessで使うRoundには、ちょうど中間の値を偶数側へ丸める動作があります。一般的な「5なら常に切り上げる四捨五入」と同一視しないでください。例えばRound(2.5,0)は2、Round(3.5,0)は4となるため、既存業務の規則と照合が必要です。[5]
また、丸める時点によって合計が変わります。10.4が2行ある場合、各行を整数へ丸めてから足すと20ですが、先に20.8を合計してから丸めると21です。明細単位か請求単位か、負数の返品も含むかを決め、計算方式を一か所へまとめましょう。
原因別の対処表
| 症状 | 主な確認点 | 対処 |
|---|---|---|
| パラメーターの入力が出る | フィールド名や参照元の誤記 | ダイアログの名称を式と照合する |
| データ型が一致しない | 数字が文字列、文字混入 | 元の型と実データを確認する |
| 結果が空欄になる | 元項目がNull | 未入力を残すか置換するか決める |
| ゼロ除算になる | 分母が0、IIfの書き方 | 分母側で0を回避する |
| 循環参照のエラー | 別名と参照名の重複 | 元項目と異なる別名へ変更する |
| 合計だけが大きい | 結合で同じ明細が複数行 | 明細IDと件数を照合する |
正常値だけで完成としない
金額の検算には、数量0、単価0、Null、少数、値引きあり、返品などの負数を含めます。今回の業務で認めない値は、式で隠すのではなく入力規則などで防ぐ方が適切な場合があります。仕様上許可される値と、入力間違いを区別して確認表を作ってください。
計算式を共通化して帳票へ引き継ぐ
同じ金額式を多数の画面や帳票へコピーすると、改修時に一部だけ古い式が残りやすくなります。複数の場所で使う計算は保存クエリへまとめ、その結果の列をフォームやレポートから参照すると、変更箇所と検算箇所を整理できます。
計算結果を次のクエリで再利用する
同一クエリ内で複雑に別名を参照し合うより、基礎計算と追加計算を二段に分けると読みやすくなります。まずQ_明細金額に金額と値引額を出し、次のクエリで差引額を求めます。元の数量・単価と結果を一緒に表示しておけば、どの段階で差が出たか追えます。
SELECT [明細ID], [金額],
[金額]-Nz([値引額],0) AS [差引額]
FROM [Q_明細金額];
この例を使う場合、Q_明細金額のSELECTへ値引額も追加してください。必要な元項目が前段のクエリへ含まれていないと、後段から参照できません。列を追加する際には、同じ名前の計算列を二重に作らないことも確認します。
確定履歴と再計算のルールを残す
商品マスターの現在単価を参照して過去の明細を計算すると、単価改定で過去の金額まで変わる設計になり得ます。取引当時の単価、確定日、必要な確定金額を何に保存するかを先に決めましょう。確定後の修正を誰がどの手順で行うかも、計算式とは別に管理します。
まとめ
演算フィールドは「列名: 式」で作成し、SQLではAS、画面の計算部品では等号を使います。元項目のデータ型とNullの意味を確認し、ゼロ除算や丸め方を含めた業務ルールを決めることが、正しい計算の前提です。
数量×単価の1行計算が合っていても、結合で行が増えたり、端数処理の時点が異なったりすると合計は変わります。例外データを含む検算表を用意し、再利用する式はクエリにまとめて、帳票の最終金額まで確認してください。
よくある質問
クエリのデザインビューの［フィールド］行では、通常、等号ではなく「金額: [数量]*[単価]」のように列名と半角コロンから入力します。フォームやレポートのテキストボックスでは「=[数量]*[単価]」となるため、入力場所を混同しないでください。SQLビューは式の後ろにASと列名を置きます。式を別の場所から転記するときは、先頭の記号だけでなく、参照するフィールドがその場所から利用できるかも確認しましょう。
元の数量や単価からいつでも再計算できる表示用の金額なら、クエリで計算する方法が基本になります。一方、見積や請求の確定金額、取引当時の条件を残す必要がある場合は、確定時点の保存設計が必要です。現在の商品マスターの単価で過去分を再計算すると、単価改定で結果が変わる場合があります。何を履歴として固定するか、確定後の修正をどう管理するかを決め、単純に保存の有無だけで判断しないようにします。
数量または単価がNullになっていないか確認します。Nullは未入力を表し、通常の掛け算では結果もNullになります。表示形式で値が見えない場合や、結合した相手のデータが存在しない場合もあるので、元項目を同じクエリに表示して比べると切り分けやすくなります。Nzで0へ置き換える方法はありますが、未確定の単価を無料と同じ扱いにしてよいとは限りません。未入力をエラーとして検出する方が適切な業務もあります。
IIfは条件に応じて片方の結果を返しても、両方の式を評価するためです。0のときにNullを返す分岐の反対側に割り算があると、その計算でエラーになることがあります。本文では、割り算を分岐の外へ置き、分母が0またはNullなら分母そのものをNullにする式を示しています。結果がNullなら計算不能という意味を残し、0％と混同しないようにします。式へ渡す実績と目標が数値型であることも、使用前に確認してください。
Accessで使うRoundには、中間の値を偶数側へ丸める動作があるため、一般的な四捨五入と同じ結果になるとは限りません。2.5を整数へ丸めると2、3.5なら4になる例があります。金額の仕様では、切り捨て・切り上げ・四捨五入の別、明細単位か請求単位か、返品などの負数の扱いまで決めてください。表示桁数を減らすだけでは計算値の確定と同じにならないため、既知の正解を持つデータで帳票合計まで照合しましょう。
意図的に入力を求めるクエリでなければ、式の中の名前をAccessが見つけられていない可能性があります。ダイアログに出た名称を控え、元テーブルのフィールド名、クエリの別名、参照元の削除や変更を確認します。全角記号や余分な空白も見直してください。適当な値を入力して進めると、誤った条件で計算されるおそれがあります。原因の列を一つずつ確認し、まず数量×単価のような短い式で正常に動く状態へ戻すと追いやすくなります。
できます。基礎の金額を求めるクエリを保存し、それを元に別のクエリで値引き後の金額などを計算する方法が分かりやすいです。後段で必要な値引額やIDも前段へ含めておきます。同じクエリ内で別名を重ねて参照すると、循環参照や名前の曖昧さで原因を追いにくくなる場合があります。二段へ分けると、各段階の入力値と結果を比較でき、同じ計算を使うフォームやレポートへの修正反映も管理しやすくなります。
通常、演算フィールドは式の結果を表示する列なので、計算結果へ直接入力して直すものではありません。数量・単価などの元データ、または計算式を修正します。ただし、元項目をクエリの結果画面で更新できるかは、結合や集計などの構成によって異なります。例外的な調整額が必要なら、計算結果の上書きではなく、調整額と理由を別の保存項目で管理する設計を検討します。自動計算と手修正の境界が分かる形にしておくことが重要です。
Accessの計算式と金額の不一致を相談する
基本設定は、まずコピーしたクエリやレポートで試してください。複数の帳票や既存処理にまたがって不一致が出る場合は、対象名、操作手順、期待する結果、実際の結果を整理すると調査しやすくなります。Accessの教科書の問い合わせ窓口から、現在の状況をご相談ください。
関連記事
参考情報
[1] Microsoft Support 式の作成
https://support.microsoft.com/en-us/access/learn-to-build-an-expression
[2] Microsoft Support 式の例
https://support.microsoft.com/en-us/access/examples-of-expressions
[3] Microsoft Learn Nz
https://learn.microsoft.com/en-us/office/vba/api/access.application.nz
[4] Microsoft Learn IIf
https://learn.microsoft.com/en-sg/office/vba/Language/reference/user-interface-help/iif-function
[5] Microsoft Learn Round
https://learn.microsoft.com/en-ie/Office/vba/language/reference/user-interface-help/round-function
[6] Microsoft Support 式の構文
https://support.microsoft.com/en-us/access/guide-to-expression-syntax