2022/06/23

条件付書式で色変更されたセル値を合計する関数

• １．背景
• ２．システム概要
• ３．プログラムの流れ
• ４．ワークシート
• ５．標準モジュール
• 　よりみち（複数フォーム起動時の実行順序）
• ６．フォーム
• 　６－１．フォームデザイン
• 　６－２．フォームモジュール
• 　　６－２－１．起動準備
• 　　６－２－２．引数の引継ぎとフォーム起動
• 　　６－２－３．計算とフォーム終了
• ７．アドインとしてExcelにマクロを登録
• ８．最後に
• サンプルファイル

１．背景

Excelで表を作り、ある範囲内の合計を計算するには、御存知の通りワークシート関数のSUM等を使用します。データを更新すれば、合計値もすぐに自動更新されます。
その表に対し、条件付き書式で特定のセルに背景色などを付けて強調することも良くやる手法です。しかし、その強調されたセルの値だけを拾って合計しようとすると、やっかいです。

ワークシート関数には「セルの背景色」を取得するものは無さそうですし、「Cell関数の"format"」を使えばセル書式の一部を情報として取得できますが「条件付き書式で変更された書式」には反応してくれません。
VBA側で考えてみると、RangeのDisplayFormatオブジェクトを使えば取得は可能ですが、VBAから呼び出す時にしか使用できない（＝ユーザー定義関数内では使用できない）という制限がありますし、VBAから呼び出すという事は「シート上の何らかのボタンをユーザーがクリック」する必要があるということになるため、自動更新という訳には行きません。
また条件付き書式の数式を取り出して、改めて各セル値を調べ、条件付き書式に合致しているセルの値を合算していくという手法は使えそうです。しかし、条件が複数になると「優先度の高い条件に合致していたか否か」も判断に加えなくてはならず、なかなか面倒そうです。

そこで今回は「初回入力日時を保存できるワークシート関数」でも紹介をした「ユーザーフォームをモードレスで起動し、そのフォーム側から計算を行う」手法を用い、DisplayFormatオブジェクトを使って「条件付き書式で変更された書式（今回は背景色）のセル範囲の合計を計算するユーザー定義関数」を実現させます。

２．システム概要

今回作成したものは「標準モジュール＋ユーザーフォーム」です。ですのでユーザー定義関数として使用するには、そのコードを「関数を使うブックに搭載」しておくか、または「Excelにアドイン」しておくという準備が必要です。
アドインのやり方については「アドインとしてExcelにマクロを登録」を参照下さい。

ワークシートからユーザー定義関数を呼び出せる準備が完了したら、条件付き書式で色分けする様な表を作ります。図２－１は「１ヶ月間の４名の〇〇の毎日の数」を表した表で、図２－２のように条件付き書式で「土日はオレンジ色」「5･10日（ゴトウビ）は緑色」と塗りつぶしをしています。なお、土日の方を優先させているため、例えば10日や30日は5･10日ではありますが、土日の色になります。

図２－１

図２－１のように、この表の左端部にユーザー定義関数「ColorSum」を書き込みます。ユーザー定義関数「ColorSum」の引数は以下のように指定します。
　ColorSum( 計算対象範囲 , 条件付き書式の番号 , 結果を出力するセル )
①第一引数「計算対象範囲（Range型）」は、合計計算の対象となるセル範囲を指定します。図２－１で言えば、D4セル～AH7セルを計算対象としています（８行目に列合計の計算をしていますので、D8～AH8を対象としてもOKです）。
②第二引数「条件付き書式の番号（Integer型）」は、計算対象範囲に設定してある条件付き書式の番号を指定します。今回は図２－２のように２種の条件付き書式を設定してあり、上側（優先度高）よりNo.1、No.2 ･･･としています。例えばNo.1の書式はオレンジ色なので、A2セルに記載したColorSum関数は「オレンジ色のセル値を合計」する事を意味します。またA5セルのColorSum関数は「緑色のセル値を合計」します。
③第三引数「結果を出力するセル（Range型）」は、合計値を出力するセル範囲です。今回は条件付き書式No.1については「B3セル」に、条件付き書式No.2については「B6セル」に出力することにしています。

計算対象範囲（D4～AH7セル）の中の値を変更すると、その範囲を参照しているユーザー定義関数（ColorSum：A2セル・A5セル）が反応し、計算対象範囲の背景色と条件付き書式の背景色を比較して、条件付き書式で変更された背景色と判断されたセル範囲の合計値をB3セル・B6セルに書込みます。
なお、条件付き書式の背景色が変わる（例えば、C2セルの年月を変更する）だけや、同じセル値を入力するだけでは、ユーザー定義関数は反応しません。計算対象範囲（または、結果出力セル）の「値を変更」することで再計算が実行されます。
（この辺が、通常のSUM関数などとは感覚がズレる感じです。）

なお通常の関数でしたら「合計値は、関数が記入してあるセルに表示」されます。しかし今回の関数は合計値を表示するセル位置は第三引数で指定し、関数が記入してあるセルは「条書No=1」などという文字列（＝関数の戻り値）となります（条書は、条件付き書式の略のつもり）。
もちろん「文字列も何も戻さない」ことも可能ですが、セルに何も表示されないと「どこに関数を書いたか分からなくなる」と思い、適当な文字列を返すことにしました。


図２－２

なお今回システムが計算対象としているのは「条件付き書式の背景色」のセルですので、第一引数として条件付書式が設定されていないセル範囲を設定してしまうと、その部分の値は無視します。（全てが条件付き書式外の場合は、合計値はゼロ表示となります）
また第二引数に、条件付き書式の設定数を超えた値を設定（例えば図２－２のように２つしか条件付き書式が無いのに、「3」を第二引数として設定）した場合も、全て無視されることになり合計値はゼロ表示となります。

３．プログラムの流れ

ワークシートのセルに入力されたユーザー定義関数の実体は、標準モジュールに置いてあります。計算対象範囲内の値に変化が生じると、標準モジュールの「ColorSum 関数プロシージャ」が呼び出されることになります。


図３－１

関数プロシージャは３つの引数を受け取り、その引数を引き継ぐ形でフォーム上のSubプロシージャを呼び出します。
フォーム上のSubプロシージャは、受け取った引数をフォーム上の共有変数とした後、フォームを「モードレス」で起動します。

「モードレス」で呼び出すことで、制御はフォーム上で留まることなく「呼び出された標準モジュールへ戻る」ことになります。戻った標準モジュール（＝関数プロシージャ）の中で、ユーザー定義関数としての戻り値（ここでは合計値では無く、設定値の一部を使った文字列）を作成しセルへ返します。返されたセルにはその文字列が表示されます。

一方「モードレス」で呼び出されたフォームは、フォーム起動時に自動的に発生するLayoutイベント（ActivateイベントでもOKです）内で、フォームとして受け取った引数を使って「計算対象範囲」のセルの表示色（DisplayFormatオブジェクト）を条件付き書式の設定色と比較をし、同じ（＝条件付き書式が成立している状態と判断）であればセル値を積算していきます。
計算対象範囲の走査が終了したら、積算した結果（＝合計値）を「結果出力セル」に書き込み、フォームを閉じます。

４．ワークシート（サンプルファイルではSheet1）

今回のワークシートは、図４－１のような「月間集計表」としました。月の基準日（１日付け）はC2セルに手入力し、そのセルの書式は「yyyy/mm」と年月だけが表示されるようにしています。

図４－１

その月の基準日（C2セル）の値をD2セルへコピーし、そこから右側は＋１ずつすることで月間の日付（３１日分）を表示しています。日付欄（D2～AH2セル）の書式は「d」と日付だけにしています。
３行目は曜日欄ですので、数式を「=TEXT(D2,"aaa")」とし簡略的な曜日を表示しています。
８行目は日毎の合計欄ですので、数式を「=SUM(D4:D7)」としています。
そして、条件付き書式のセル色による合計関数「ColorSum」は、A2セル・A5セルに入力しました。計算対象範囲は「D4～AH7セル」とし、条件付き書式の１番目（土日のオレンジ色）及び２番目（5･10日の緑色）に対応させています。合計値の出力は、それぞれB3セル、B6セルとしました。
セルに記入した数式は、A2セルが「=ColorSum(D4:AH7,1,B3)」、A5セルが「=ColorSum(D4:AH7,2,B6)」となります。

集計表には、図４－２のように条件付き書式を使って「土日をオレンジ色」「5･10日を緑色」にしています。彩色の範囲（適用先）は「D2～AH8セル」と日付・曜日・データ記入欄・合計欄の全てとしました。
土日を彩色する式は、３行目（＝曜日行）に対して「=OR(D$3="土",D$3="日")」としました。また5･10日は２行目（＝日付行）に対して「=MOD(DAY(D$2),5)=0」と、５で割り切れる日付としました。
なお、土日の彩色を優先させた（条件付き書式のルールが上にある）ので、例え5･10日であっても土日であればオレンジ色になります。

図４－２

なお「B2～B3・B5～B6セル」は、分かり易くするために手動で背景色を「オレンジ色」「緑色」に変更しています。

５．標準モジュール（Module1）

標準モジュール先頭の宣言部では、０１行目「Dim UF As UserForm1」とUserForm1型の変数UFを宣言しています。これは今回のように同時にユーザー定義関数が複数回呼び出される場合の対応です。

ユーザー定義関数（図５－２）内の１９行目の先では「UserForm1を起動」しているのですが、複数セルから「ほぼ同時に」ユーザー定義関数が呼び出されると、UserForm1が起動している最中に、別のところから「UserForm1を起動せよ」との指令が出ることになります。また起動中のUserForm1の中からも再帰的にユーザー定義関数が呼び出されるため、更に重複します。

もしUserForm1を１つで対応しようとすると、同じUserForm1の中で受け渡す引数値が入れ替わってしまうようです。実際にやってみると「一方の関数側しか計算をしてくれない」ような現象が発生します。
ですので、ユーザー定義関数が呼び出される度に「新たなUserForm1を起動」できるようにします。

0. '==========　⇩(1)　変数の宣言　============
1. Dim UF As UserForm1

図５－１

ワークシート上のセルに書かれた数式から呼び出されるのが、図５－２の「ColorSum ユーザー定義関数」です。引数として、以下の３つを受け取ります。
　第一引数：計算対象範囲（Rng：Range型）
　第二引数：条件付き書式の番号（FormatCond：Integer型）
　第三引数：結果を出力するセル（ WriteCell：Range型）
なお、ユーザー定義関数が戻す値は今回文字列のため、戻り型はString型にしています。

10. '==========　⇩(2)　ユーザー定義関数　============
11. Public Function ColorSum(Rng As Range, FormatCond As Integer, WriteCell As Range) As String
13. 　On Error Resume Next
14. 　　If UF.Enabled = False Then Set UF = Nothing
15. 　On Error GoTo 0
17. 　Set UF = New UserForm1
19. 　Call UF.UFstart(Rng, FormatCond, WriteCell)
21. 　ColorSum = "条書No=" & FormatCond
22. End Function

図５－２

１３～１５行目は、古いUserForm1を削除（＝初期化）しています。
１４行目「If UF.Enabled = False Then Set UF = Nothing」では、UserFormが操作可能（Enabled）状態以外の時には初期化しているように見えますが、実際には「操作可能状態の時には初期化しない」という意味で、UserFormのEnableプロパティが取得出来ない状態（＝既に閉じられているUserFormなど）の時に初期化をするという実行内容になります。

フォームは「生成直後」と「起動中」には初期化してはいけないので、このIf文をどう組み立てるかを図５－９で検討し、今回は「Enableプロパティ」を使用しました。それ以外の「初期状態」「フォームが閉じた後」はエラーとなりますので、１３行目「On Error Resume Next」で１４行目の前半のIf文をスルーさせ、後半の「 Set UF = Nothing」を実行させます。
（「初期状態」は本来は初期化する必要は無いのですが、If文を二重にするのも面倒だったため、一緒に初期化しています。）

１７行目「Set UF = New UserForm1」では、UserForm1のインスタンスを新しく生成しています。つまり「ユーザー定義関数が呼び出される度に、新たなUserForm1を作成」し、その新たに作成されたUserForm1の中で「単一条件での計算＋合計値の出力」を行っていきます。

１９行目「Call UF.UFstart(Rng, FormatCond, WriteCell)」では、UserForm1内のUFstartプロシージャ（図６－５）を呼び出します。呼び出す際に、ユーザー定義関数ColorSumが受け取った３つの引数をそのままフォーム側に渡します。この段階では、まだUserForm1のShowメソッドを実行していないため、フォームは起動していません。

２１行目「ColorSum = "条書No=" & FormatCond」は、ユーザー定義関数としての戻り値を設定し、呼び出したセル側へ戻しています。今回は「合計値」を戻すのではなく、「何番目の条件付き書式の関数か」が分かるような文字列を戻しています。（条書：条件付き書式の略のつもり）

今回、同じユーザーフォーム（UserForm1）を複数起動させ、それぞれのフォーム内で合計計算を実行しています。複数個起動させるために０１行目で「Dim UF As UserForm1」と宣言し、１７行目で「Set UF = New UserForm1」とフォームを生成しています。しかしVBEで確認しても、複数のフォームが起動しているようには見えません。唯一、フォームの形が見えるようにする（例えば図６－３の４４行目を「Me.Top = +100」にして、画面内表示させる）と複数のフォームが同時に起動しているのが分かります。 そのフォームは、最終的には「Unload Me（図６－６の９１行目）」で消えるかと思いきや、消えずに全てのプロパティが「オートメーションエラー」という内容で残ってしまうのです（フォームの形は消えてくれます）。原因は「Unload Me」を実行した時には、既に呼び出し元であるユーザー定義関数は終了している　ためのようです。 一体どういう状況になっているのか知りたくて、今回のUFという変数の代わりにオブジェクト配列などを使って確かめてみました。すると起動したフォームは延々と全て残っており、中身は全てオートメーションエラーであることが分かりました。 （もちろんEndステートメントなどで一旦初期化すればクリアされます。また、実行時エラーのオートメーションエラーとは異なり、いきなりプログラムが止まることは無さそうです。） これでは、データが更新された回数 × ユーザー定義関数の数の分だけ「ゴミが溜まる」ことになり、悪くすればExcelの停止やWindows不安定などにも繋がります。そこで「一連の計算途中はガマンする」として、「次の計算が始まる直前に、UserForm1オブジェクトをクリア」しようと考えました。 しかしオブジェクトをクリアするには、「Set UserForm11 = Nothing」というコードを実行することになります。試しに複数のフォームが起動している途中でクリアすると「全てのUserForm1が初期化」されてしまいます。 そこで、色々調べている内に「VBEで見えているのは、最も最新のUserForm1の姿」であることが分かってきました。 すると、見えている最新のUserForm1の状態が終了処置済みだとして、その後ろに隠れている複数個のUserForm1を全てクリアしても良いのかが問題になります。実行される順番によっては、例えばその１つ前のフォームは「生きている」可能性も考えられるからです。 この実行順序を確かめるために、まずコード単位でのプログラムの流れを調べたのが図５－３です。 図５－３ 図３－１でも大雑把に説明しましたが、流れは大きくＡ・Ｂ・Ｃに分けられます。複数のフォームが起動したとしても、このＡ・Ｂ・Ｃが更に分かれて実行されることは無さそうです。 Ａは、ユーザー定義関数としての「一連の動作」に相当します。フォームの域まで達していますが、繋がっている流れです。 Ｂは、Showメソッドにより「フォームをモードレスで起動した先」であり、ユーザー定義関数の「一連の動作」からは外れた所です。このＢの部分で計算をし、その計算結果をセルに書き込むと、その瞬間にまた「ユーザー定義関数」が呼び出されることになります。セルへの書込みが無い場合（今回では、書き込む値が同じ値の時）は、Ｃのフォームを閉じるコードを実行します。 このＡ・Ｂ・Ｃの３つのかたまりが、どの順番で実行されるかを示したのが以下になります。 まず、１つだけのユーザー定義関数の場合が図５－４です。 計算した結果が元の値と変わらない場合は、図５－４の上側のように「ストレートにＡ→Ｂ→Ｃ」と進みます。 合計値が変わる場合は、セルへの書込みをした直後（Ｂ）に、ユーザー定義関数が呼び出されて新たなフォームを起動（Ａ）します。フォームを起動した後は、元のルートに戻りフォームを終了（Ｃ）させた後、新たに発生したフォームで計算（Ｂ）を始めます。しかし計算結果は、元のルートで書き換え済みなので「セル値と同じ」となり、書き込みをせずにフォームを終了（Ｃ）します。 図５－４ ユーザー定義関数が２ヶ所にある場合は、図５－５以下になります。２ヶ所とも値変更がない場合が図５－５になります。 数式からの呼出しはほぼ同時に発生しますので、１ヶ所目のフォーム起動が完了した時点で、１ヶ所目の計算を始める前に２ヶ所目のフォーム起動が始まります。２ヶ所目のフォームが起動したら、１ヶ所目の計算を開始し終了したら２ヶ所目の計算に入ります。 図５－５ 片方の計算結果が元の値と異なる場合は、セルへの値出力が行われた瞬間に新たなフォームが起動されます。１ヶ所目の合計値が異なる場合が図５－６です。 図５－６ 図５－６と同類で、２ヶ所目の合計値が異なる場合が図５－７です。 図５－７ ２ヶ所共の合計値が異なる場合は、図５－８になります。 それぞれ、フォームが起動された順番に処理を完了させる動きになるようです。 図５－８ 図５－４～図５－８の「フォームを起動するブロック（＝Ａ）」に、起動した順番の番号を振りました。VBAでは「最新のUserForm1の状態」のみが見えるので「各番号の１つ前のブロックが生きているか」という視点で確認してみると、「１つ前は、必ず生きている（＝終了処理がされていない）」事が分かります。 ３ヶ所以上の組合せを確認している訳ではありませんが、「フォームを起動した後で、それより前に起動したブロックの計算処理を開始する」ことを考えれば「１つ前のブロックは生きている」と言えると思います。 ということで、図５－２の１３～１５行目で「VBAとして見えるUserForm1（＝１つ前のフォーム）」の状況を調べ、オートメーションエラーであれば「全フォームは終了処理済み」と判断しても良いだろう、と考えました。 では、その「フォームが終了処理済みか否か」を調べる手段ですが、図５－９のように３種類を考えました。「閉じた後」だけを選別できれば良いのですが、エラー番号がExcelバージョン等により異なる可能性も考えられるため、決して削除してはいけない「生成直後」と「起動中」以外で選別できる「Enabledプロパティ」を今回使用することにしました。 初期状態 生成直後 起動中 閉じた後 ｵｰﾄﾒｰｼｮﾝｴﾗｰ状態 UserForm1 Is Nothing True False False False UserForm1.Visible ｴﾗｰ(91) False True ｴﾗｰ(-2147418105) UserForm1.Enabled ｴﾗｰ(91) True True ｴﾗｰ(-2147418105) 図５－９ 削除のコードは、図５－２の１４行目のように「If UF.Enabled = False Then Set UF = Nothing」とし、「生成直後」「起動中」は実行されずに、エラーの場合（初期状態、フォームが閉じた後）だけその後の「Set UF = Nothing」が実行されるようにしました。 「初期状態」も初期化してしまう事になりますが、更にIf文を重ねるとゴチャゴチャになりそうなので止めました。

なお、モードレスで起動したフォーム内で処理をする以外に「OnTimeを使って時間差でプロシージャを動かす」という手法も思い付くかもしれませんが、今回のようなユーザー定義関数の「一連の動作」の中では、残念ながら「OnTimeは動作しない」ので使えません。

６．フォーム（UserForm1）

６－１．フォームデザイン

ユーザーフォームのフォーム自体は今回使用しません。図６－１のように初期状態のまま、手を加える必要はありません。

図６－１

６－２．フォームモジュール

先頭の宣言部には、フォームモジュール内で共有する変数の宣言をします。
変数は、ユーザー定義関数として受け取った３つの引数を、フォームレベルの変数にしています。変数への値代入は、図６－５内で行っています。

30. '==========　⇩(3)　フォームレベル変数の宣言　============
31. Dim Rng As Range
32. Dim FormatCond As Integer
33. Dim WriteCell As Range

図６－２

６－２－１．起動準備

フォームが起動する際に、最初に呼び出されるのがInitializeイベントです。今回で言えば図５－３で分かるように、図５－２の１７行目「Set UF = New UserForm1」から呼び出される形になります。

40. '==========　⇩(4)　フォームの初期設定　============
41. Private Sub UserForm_Initialize()
42. 　Me.StartUpPosition = 0
43. 　Me.Left = 0
44. 　Me.Top = -100
45. 　Me.Height = 0
46. 　Me.Width = 0
47. End Sub

図６－３

Initializeでは、（表示して欲しくないが）表示されてしまうフォームの表示位置を定めています。今回はできるだけ「フォームを見せたくない」ので、サイズを小さく（サイズ＝ゼロ）します。しかしゼロにしたとしても「タイトル部は表示されてしまう」ので、表示位置は画面の外に追い出すようにします。

４２行目「Me.StartUpPosition = 0」は、フォームの表示位置を指定するものです。位置指定は４３～４４行目で行いますので、それよりも前にStartUpPosition設定を行う必要があります。
設定値は図６－４の中から選びますが、今回は画面から外しますので「ゼロ」を指定します。

設定(定数では無い)	値	説明
Manual	0	初期設定値を指定せず
CenterOwner	1	UserFormが属する項目の中央
CenterScreen	2	画面全体の中央
WindowsDefault	3	画面の左上隅

図６－４

４３行目「Me.Left = 0」で左右方向の位置をゼロ、４４行目「Me.Top = -100」で上下方向をマイナスにすることで、画面外に追い出しています。
４５行目「Me.Height = 0」ではフォームの高さをゼロにし、４６行目「Me.Width = 0」では幅をゼロにします。
上でも説明した通り、高さ・幅をゼロにしてもタイトル部は表示されてしまいますので、タイトル部も含めて画面外に追い出すためにTop値をマイナスにしています。

６－２－２．引数の引継ぎとフォーム起動

図５－２の１９行目から呼び出されるのが図６－５です。引数として「計算対象範囲（UFRng）」「条件付き書式の番号（ UFFormatCond）」「結果出力セル（UFWriteCell）」を受け取ります。これらは、ユーザー定義関数ColorSumが受け取った引数そのものですが、フォームレベルの変数名をColorSumの引数名と同じにするために、頭にUFを付けた引数名にしています。

50. '==========　⇩(5)　標準モジュールからの引数受け取り　============
51. Public Sub UFstart(UFRng As Range, UFFormatCond As Integer, UFWriteCell As Range)
52. 　Set Rng = UFRng
53. 　FormatCond = UFFormatCond
54. 　Set WriteCell = UFWriteCell
56. 　Me.Show vbModeless
57. End Sub

図６－５

５２行目「Set Rng = UFRng」では、引数として受け取った計算対象範囲をフォームレベル変数Rngに代入します。
５３行目「FormatCond = UFFormatCond」では、条件付き書式の番号を変数FormatCondに代入します。
５４行目「Set WriteCell = UFWriteCell」では、結果出力セルを変数 WriteCellに代入します。

５６行目「Me.Show vbModeless」では、自分（＝UserForm1）を「モードレス」で起動します。モードレスで起動することで、制御は次の行に移り、UFstartプロシージャを抜け、呼び出し元のユーザー定義関数ColorSumに戻ります。
一方、起動したフォームは、Initializeイベントは完了していますので、その次の「Layoutイベント」→「Activateイベント」へと自動的に進んで行きます。

６－２－３．計算とフォーム終了

フォームが起動されたことで発生する「Layoutイベント」が図６－６です。この中で計算と出力の処理を行います。
なお、同じ内容をActivateイベント内で行っても同じ機能となります。
（Layoutを使えばフォームが非表示になるかな？　と期待したのですが、残念ながら表示されてしまいました）

70. '==========　⇩(6)　計算と合計値出力　============
71. Private Sub UserForm_Layout()
72. 　Dim r As Range 　　　　　 '←計算対象範囲の１つ１つのセル
73. 　Dim SumN As Double 　　　 '←合計値
74. 　Dim ColorNum As Double 　 '←条件付き書式で設定されている背景色
76. 　For Each r In Rng
77. 　　On Error Resume Next
78. 　　　ColorNum = r.FormatConditions(FormatCond).Interior.Color
80. 　　　If Err.Number = 0 Then
81. 　　　　If r.DisplayFormat.Interior.Color = ColorNum Then
82. 　　　　　SumN = SumN + Val(r.Value)
83. 　　　　End If
84. 　　　End If
86. 　　On Error GoTo 0
87. 　Next r
89. 　If Not WriteCell.Value = SumN Then WriteCell.Value = SumN
91. 　Unload Me
92. End Sub

図６－６

７６～８７行目では、計算対象範囲の１つ１つのセルの表示色（DisplayFormatオブジェクト）を調べ、「そのセルに設定されている条件付き書式」の設定番号の「設定書式（今回は、背景色）」と合致している場合に、セル値を変数SumNに積算をしていきます。
ですので複雑に条件付き書式を設定してしまうと「あるセルには黄色設定は２番でも、あるセルにとっての２番は青色」のような設定になり、思った結果が得られない事も考えられます。

７６行目「For Each r In Rng」は、計算対象範囲Rngから１つずつセルを取り出します。１個のセルは変数rとしています。
７８行目「ColorNum = r.FormatConditions(FormatCond).Interior.Color」は、そのセル（r）に設定してある条件付き書式の番号（FormatCond）の背景色を取得し、変数ColorNumに代入します。
但し、そのセルに「条件付き書式が設定されていない」場合も考えられます。また、条件付き書式の番号（FormatCond）が条件付き書式の数よりも多い場合もあります。その時には７８行目でエラーが出ますので、７７行目「On Error Resume Next」でエラーをスルーさせます。

今回は「条件付き書式で変更された背景色」でのセル値のみを拾い上げていきますので、８０行目「If Err.Number = 0 Then」で、エラーが出ていない（＝条件付き書式が設定されていて、正しく背景色が取得できる）場合だけ８１～８３行目の値積算を実行していきます。
８１行目「If r.DisplayFormat.Interior.Color = ColorNum Then」では、セルの表示色が条件付き書式の背景色と同じ時に８２行目「SumN = SumN + Val(r.Value)」でセル値を積算していきます。セル値はVal関数で数値にしていますので、もし文字列が入っている場合は「ゼロ」を積算することになります。

計算対象範囲の全てのセルに対する積算が終了したら、８９行目「If Not WriteCell.Value = SumN Then WriteCell.Value = SumN」で、積算値を結果出力セルへ貼り付けます。但し「If Not WriteCell.Value = SumN Then」で、「結果出力セルの値が積算値と異なっている場合」に限っています。
通常ユーザー定義関数は、参照しているセル値を「手入力で同じ値に書き換え」ても、再計算しない（ユーザー定義関数は呼び出されない）のですが、VBA側から同じ値に書き換えると呼び出されてしまいます。そのため「If Not WriteCell.Value = SumN Then」という制限をつけないと、呼び出しが繰り返し発生してしまいます。

９１行目「Unload Me」は、フォームを閉じています。この操作で確かにフォームの形は消えるのですが、「よりみち」でも説明したように、フォームの全プロパティがオートメーションエラーという内容に変わり「オブジェクト変数UF」として残ってしまいますので、次回の呼出し開始時に図５－２の１３～１５行目でオブジェクト変数の初期化を行っています。

７．アドインとしてExcelにマクロを登録

このマクロ付ファイル（サンプルファイル）をExcelのアドインに登録することで、今回の「フォームカレンダー」を他のブックから呼び出して使うことが出来ます。アドイン方法については「年賀状リスト等の宛名検索と追記　アドイン登録」を参照下さい。
なお、ボタンを押して何かを実行するシステムではないので、「開発」タブ→「アドイン」グループ→「Excelアドイン」ボタンで開くダイアログから、登録された今回のアドインを「有効（レ点を付ける）」にするだけでユーザー定義関数として使用できます。

８．最後に

今回、ユーザー定義関数とは一連の流れが切れた「モードレスで起動したユーザーフォームから計算」という手法を用いました。他にも、計算対象範囲の値を変更したことを「Worksheet_Change等のイベント」で受け取り、計算を開始する　という方法も考えられます。但し、自由に配置できるユーザー定義関数がどこにあるのか（ユーザーがどこに合計値を表示したいのか）を調べる方法が思いつかず、フォームをモードレスで呼び出し・・・という手法にしました。
もう少し考えれば、上手い方法を思いつきそうな気もします。


条件付書式で色変更されたセル値を合計する関数（it-083.xlsm）

C2セルの年月日を変更しても、合計値は変わりません。計算対象範囲内の数値を変更することで再計算が実行されます。

セキュリティ向上を目的として「インターネット経由でダウンロードしたOfficeファイル（Excel等）のマクロは、既定でブロック」されるようにOfficeアプリケーションの既定動作が変更になりました。（2022年4月より切替開始） 解除の方法については「ダウンロードファイルのブロック解除方法」を参照下さい。