VBAの合計が合わないとき、F8でどこを見るか

LWP | VBAの合計が合わないとき、F8でどこを見るか

図解1｜エラーが出なくても、結果は間違う

図1｜実行が終わることと、期待した答えになることは別です。

解説1｜合計を作る変数の役割を確かめる

合計の計算には、今回の金額と、それまでの累計という二つの値があります。今回の金額はループのたびに変わり、累計は前回までの値を引き継いで増えます。この関係が崩れても、文法が正しければVBAは最後まで実行できることがあります。

今回の入力は100・200・300、期待する合計は600です。次の誤りを含むコードは、最後に300を表示します。標準モジュールに入れて試す小例で、セルやファイルへ書き込みません。Windows版ExcelのVBEを想定しています。

サンプルコード｜原因を観測するための誤り例



Public Sub TraceTotal()
    Dim amounts As Variant
    Dim i As Long
    Dim total As Long
    amounts = Array(100, 200, 300)
    total = 0
    For i = LBound(amounts) To UBound(amounts)
        total = amounts(i)
        Debug.Print i, amounts(i), total
    Next i
    Debug.Print "total="; total
End Sub

01	`Option Explicit`
02
03	`Public Sub TraceTotal()`
04	`Dim amounts As Variant`
05	`Dim i As Long`
06	`Dim total As Long`
07	`amounts = Array(100, 200, 300)`
08	`total = 0`
09	`For i = LBound(amounts) To UBound(amounts)`
10	`total = amounts(i)`
11	`Debug.Print i, amounts(i), total`
12	`Next i`
13	`Debug.Print "total="; total`
14	`End Sub`

amountsは入力の配列、iは現在見ている要素の番号、totalは累計を入れる変数です。このモジュールでは配列の添字は0から2です。ループの範囲にはLBound・UBoundを使い、配列の下限と上限をそのまま参照しています。

読むポイント

最終値300を見て「最後の金額と同じだ」と気づけても、それだけでは上書きが起きた証拠にはなりません。どの文の実行前後で、どの値が変わるかを確認します。変更する前に、期待値600と現状300を記録しておきましょう。

図解2｜黄色い行は、これから実行する行

図2｜2回目の代入直前はtotalが100。F8で代入すると200になります。画面の関係を説明する概念図です。

解説2｜F8の前と後を、同じ変数で比べる

ブレークポイントは、指定した文を実行する直前で止める目印です。通常のVBE設定では、停止中の黄色い行は「次に実行する文」を表します。赤いブレークポイントの印と、現在の実行位置を区別してください。

操作｜2回目の代入を見る

Alt＋F11でVBEを開き、total = amounts(i) の行へカーソルを置いてF9を押します。TraceTotal内にカーソルを置いてF5で実行すると、その行の直前で止まります。［表示］→［ローカルウィンドウ］を開き、iとtotalを確認します。

最初の停止ではi＝0、total＝0です。もう一度F5を押すと、1回目の代入と出力を実行して、次のループの同じブレークポイントで止まります。ここがi＝1、total＝100となる2回目の代入直前です。amountsを展開して、今回使うamounts(1)＝200も確認します。

比較｜代入を一文だけ実行する

観測する値	F8の前	F8の後
i	1	1
amounts(1)	200	200
total	100	200
次に実行する文	totalへの代入	Debug.Print

ここでF8を一度押すと代入が実行され、次のDebug.Printの行へ進みます。totalは300になるはずなのに200になりました。実行前の100が加算されていないことを、この一文の前後で確かめられます。

読むポイント

黄色い行が代入を示している間は、ローカルに見えるtotalは代入前の値です。表示を見た瞬間に「代入しても変わらない」と判断せず、一文進めて比べましょう。実行位置を前へ戻しても変数の値は巻き戻りません。初期状態を再現したいときは、リセットして最初から実行します。

図解3｜途中の記録で、最初の食い違いを見つける

図3｜最終値だけでなく、最初に期待値から外れた回を調べます。

解説3｜Debug.Printを、読む目的のある記録にする

ローカルウィンドウは停止した時点の値を確認する場所です。一方、Debug.Printは、実行した時点の値をイミディエイトウィンドウへ出します。この例では代入の直後に置いているため、「代入した後のtotal」が残ります。置く位置が変われば、記録の意味も変わります。

操作｜三つの項目を対応させる

VBEでCtrl＋Gを押してイミディエイトウィンドウを表示します。前の実行結果と混ざらないよう出力を消し、［実行］→［リセット］で一度終了します。代入行のF9でブレークポイントを外してから、TraceTotalを最初からF5で実行します。

Debug.Print i, amounts(i), total は、要素の番号、今回の金額、代入後の累計を順に出力します。カンマは表示位置を区切るための指定です。ウィンドウの空白幅そのものをデータの一部として読む必要はありません。

結果｜期待値と実際の値を照合する

i	今回の金額	期待する累計	実際のtotal
0	100	100	100
1	200	300	200
2	300	600	300

1回目は、0に100を加えても、100を上書きしても同じ結果になります。そのため、最初の行が合っているだけでは正しい加算だと判断できません。2回目から食い違い、毎回totalが今回の金額と一致することが、上書きという仮説を支えます。

読むポイント

調査では「今回の値」「処理前までの値」「処理後の値」を区別します。大量の変数を出力するよりも、この三つの関係を確かめられる観測点を選ぶほうが、原因を絞れます。調査用のログには目的を持たせ、無関係な情報は増やさないようにします。

図解4｜一文を直し、同じ条件からやり直す

図4｜修正後は初期状態から再実行し、途中値と最終値の両方を確認します。

解説4｜原因の修正と、直ったことの確認を分ける

原因は、累計を作る文が今回の金額の代入だけになっていたことです。VBAの代入は、右辺を評価してから、その結果を左辺の変数へ入れます。右辺に処理前のtotalを含めれば、前回までの累計を引き継げます。

修正する一文

01	`total = total + amounts(i)`

解説1の total = amounts(i) を、この一文へ置き換えます。total = 0 はループの前に一度だけ置いたままにします。ループの中へ移すと、毎回累計を消してしまうため、別の原因で同じような症状になります。

結果｜同じ入力と、区別しやすい入力で確かめる

入力の配列	修正前の最終値	修正後の最終値
100, 200, 300	300	600
50	50	50
100, -100, 25	25	25
100, 0, 200	200	300

元の入力では、修正後の途中値も100・300・600になることを確認します。一件だけの入力や、途中までの合計が0になる入力では、誤ったコードでも最終値が一致することがあります。最終値だけで合否を決めず、食い違いを見つけた条件を必ず再実行してください。

確認が終わったら調査用のブレークポイントを外します。Ctrl＋Shift＋F9はプロジェクト全体のブレークポイントを解除する操作なので、ほかの調査で残すものがある場合は個別に外します。この小例のDebug.Printは観測教材として残せます。

読むポイント

コードを直す前に、どの文の前後で期待値から外れたかを示す。直した後は、同じ初期状態・入力で途中値まで一致するかを確かめる。この一組を、別の不具合でも使える調査の単位にします。

出典

『デバッキング Excel VBA』V026_261006、3.1.1・3.1.2・3.2.1・3.2.4をもとに、独立した累計の誤り例を作成。操作の仕様：Microsoft Learn：実行のトレース、Debugメニュー。2026-10-12確認。