滝Libで既存ExcelVBAマクロを調査する

コードを直す前に、全体像・データフロー・呼び出し階層・実行時の値を地図にする

Copyright © 2026 LWP 山中 一弘

本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

記事要約

既存のExcel VBAマクロを調べるとき、最初からコードを上から順に読もうとすると失敗しやすくなります。

理由は単純です。既存マクロでは、処理の入口、呼び出し関係、シートと配列の関係、辞書やコレクションに入っている中間データ、エラーが起きた行と本当の原因の位置が、必ずしも同じ場所にないからです。

この記事では、滝Libを「新しいマクロを書くための道具」ではなく、「既存マクロを調査するための道具」として使う考え方を整理します。

中心になるのは、次の3つです。

1. mod_amalgam でソース全体を1つのファイルに集める

2. mod_list でモジュールとプロシージャの一覧を作る

3. mod_tree で呼び出し階層を確認する

そのうえで、全体概要図、データフロー、関数コールツリー、判断表を作り、最後にブレークポイントと呼び出し履歴で実行時の値を確認します。

本記事の対象とゴール

想定読者

この記事は、次のような人を対象にしています。

• 引き継いだExcelマクロの中身を調べたい人

• エラーが出ている既存マクロを直したい人

• 仕様書がない、または古くなっているVBAを調査したい人

• AIにマクロを読ませる前に、コードを安全に整理したい人

本記事で得られること

この記事を読むと、次のことが整理できます。

4. 既存マクロ調査で最初に見るべきもの

5. 滝Libの mod_amalgam、mod_list、mod_tree の役割

6. コードを読む前に作るべき調査資料

7. エラー行だけを追わないデバッグの考え方

8. 調査時にやってはいけない危険な操作

本記事で扱わないこと

この記事では、滝Libの全機能のリファレンスは扱いません。

また、Excel VBAの文法入門や、新規マクロ開発の設計方法も中心にはしません。主題は、すでに存在するマクロを調べ、直せる状態にするための実務手順です。

先に結論

既存マクロの調査では、いきなりコードを直してはいけません。

まず作るべきものは、次の4つです。

9. 全体概要図

10. データフロー

11. 関数コールツリー

12. 判断表

これらを作るために、滝Libの調査用機能を使います。

通常の調査で取り込むのは taki3lib.bas です。taki3libUTF8.bas は、AIや外部ツールで読みやすいようにUTF-8で扱うための版であり、通常のExcel VBAプロジェクトへ入れる対象として説明すると混乱します。

調査の基本は、次の順序です。

13. 本番ファイルではなく調査用コピーを作る

14. taki3lib.bas をコピー側のVBAプロジェクトへ取り込む

15. mod_amalgam でコード全体を1ファイル化する

16. mod_list でプロシージャ一覧を作る

17. mod_tree で呼び出し階層を見る

18. 入口、出力、シート操作、中間データを確認する

19. ブレークポイントと呼び出し履歴で、実行時の値を確認する

20. 直す前に、どこを直すべきかを決める

1. 既存マクロは、作るより読むほうが難しい

新しくマクロを書くときは、自分で入口を決め、処理の順序を決め、データの置き場所を決めます。

しかし、既存マクロを読むときは違います。

すでに誰かが決めた入口、途中で増改築された処理、古い仕様に合わせた分岐、使われなくなったプロシージャ、意味の分からない一時変数、シート上には見えない配列や辞書が混ざっています。

そのため、既存マクロ調査で最初に必要なのは、コードの読解力だけではありません。

先に必要なのは、地図です。

• どこから処理が始まるのか

• どのプロシージャが、どのプロシージャを呼んでいるのか

• どのシートを読んで、どのシートに書くのか

• 配列、辞書、コレクションにどのデータが入るのか

• エラーが出た行は、原因なのか、結果なのか

この地図がないまま、目の前の1行だけを直すと、別の場所を壊すことがあります。

2. 調査は必ずコピーで行う

既存マクロ調査では、最初に調査用コピーを作ります。

本番ファイルをそのまま開いて、そこに調査用モジュールを入れたり、ブレークポイントを置いたり、途中で処理を止めたりしてはいけません。

最低限、次のように分けます。

本番ファイル

    実務で使う正本。直接触らない。

調査用コピー

    コードを読み、滝Libを入れ、デバッグするための作業ファイル。

退避コピー

    調査前の状態へ戻せるように残す保険。

調査用コピーでは、次の点も確認します。

• 開いた瞬間に自動実行されるマクロがないか

• 外部ブック、CSV、Access、メール、Web APIなどへ接続しないか

• 参照設定が自分の環境で切れていないか

• 本番フォルダーのファイルを書き換えないか

• 個人情報や社外秘データを外部へ出さないか

既存マクロ調査では、コードを読む前に「調査してよい状態」を作ることが重要です。

3. 滝Libを調査用に入れる

滝Libは、Excel VBAの作業を助けるためのライブラリです。

この記事で使うのは、その中でも既存マクロ調査に役立つ機能です。

通常は、調査用コピーのVBAプロジェクトへ taki3lib.bas を取り込みます。

ここで大事なのは、滝Libを「自分の処理を置き換える魔法の部品」として入れるのではない、ということです。

既存マクロ調査では、滝Libは次の役割を持ちます。

• ソースコードを外へ取り出しやすくする

• モジュールとプロシージャの一覧を作る

• 呼び出し関係を見えるようにする

• AIやエディタで読みやすい形に整える

つまり、滝Libは調査の補助線です。

調査対象のマクロを勝手に作り替えるためのものではありません。

4. 調査三点セット

既存マクロ調査で特に使うのは、次の3つです。

4.1 `mod_amalgam`

mod_amalgam は、VBAプロジェクト内のソースを集め、1つの .bas ファイルとして出力するための機能です。

VBEの画面だけでコードを読むと、標準モジュール、クラスモジュール、フォーム、シートモジュール、ThisWorkbookの間を何度も行き来することになります。

それでは全体を把握しにくくなります。

mod_amalgam で1ファイルにまとめると、次のことがしやすくなります。

• エディタで全文検索する

• AIにコードを読ませる前に不要部分を整理する

• 同じ名前の変数やプロシージャを探す

• 入口候補を探す

• 変更前後の差分を確認する

出力されたファイルは、調査資料です。

そのまま本番へ戻すものではありません。

4.2 `mod_list`

mod_list は、モジュールとプロシージャの一覧を確認するための機能です。

既存マクロでは、入口らしいプロシージャが複数あることがあります。

たとえば、次のような名前が混ざります。

Main

Run

実行

集計開始

CommandButton1_Click

Workbook_Open

Worksheet_Change

名前だけでは、本当に使われている入口かどうかは分かりません。

それでも、一覧を作る意味はあります。

一覧があると、少なくとも次の切り口で調べられます。

• イベントから始まる処理

• ボタンから始まる処理

• 外部から呼ばれる処理

• 使われていない可能性がある処理

• 名前は似ているが役割が違う処理

コードを読む前に、まずプロシージャの棚卸しをします。

4.3 `mod_tree`

mod_tree は、プロシージャの呼び出し構造を確認するための機能です。

既存マクロで重要なのは、エラーが出たプロシージャだけではありません。

そのプロシージャを呼んだ側が、間違った引数を渡していることがあります。

さらに、その呼び出し元が、もっと前の処理で作った配列や辞書を間違えていることもあります。

mod_tree で呼び出し関係を見ると、次のような読み方ができます。

集計開始

    入力チェック

    マスタ読込

        商品マスタ読込

        得意先マスタ読込

    明細読込

    集計処理

        キー作成

        金額計算

    結果出力

この形で見ると、「エラーが出た場所」だけでなく、「その場所へ至る流れ」を追えます。

5. 作るべき四つの成果物

滝Libで一覧や呼び出し構造を出しただけでは、まだ調査は終わりません。

実務で使うためには、読み手が判断できる形に落とす必要があります。

5.1 全体概要図

最初に、マクロ全体の大まかな構造を書きます。

きれいな図である必要はありません。

最初は、次のようなテキストで十分です。

ボタン押下

    入力シートを確認

    設定シートを読む

    明細シートを配列に取り込む

    マスタシートを辞書化する

    明細とマスタを突き合わせる

    結果シートへ出力する

この段階で、細かい条件分岐を全部書こうとしないほうがよいです。

まずは、入力、処理、出力を押さえます。

5.2 データフロー

次に、データがどこから来て、どこへ行くかを書きます。

VBAマクロでは、シートに見えているものだけがデータではありません。

実際には、途中で配列、辞書、コレクション、ユーザー定義型、クラスなどに入っていることがあります。

たとえば、次のように整理します。

入力シート

    ↓

明細配列

    ↓

商品コードをキーにした辞書

    ↓

集計結果配列

    ↓

出力シート

この図がないと、「シート上の値は合っているのに、なぜ出力が違うのか」が見えません。

原因は、シートではなく、途中の配列や辞書にあるかもしれません。

5.3 関数コールツリー

関数コールツリーは、処理の呼び出し関係を表すものです。

滝Libの mod_tree で確認した内容を、そのまま読むだけでなく、調査用に少し整理します。

特に見るべきなのは、次の3点です。

• どこが入口か

• どこで外部データを読むか

• どこで結果を書き出すか

すべてのプロシージャを同じ重さで読む必要はありません。

入口、入出力、主要な変換処理を先に押さえます。

5.4 判断表

条件分岐が多いマクロでは、判断表を作ります。

コードの If や Select Case をそのまま日本語に写すだけでは足りません。

実務上の意味に直して、次のように整理します。

条件1: 得意先区分がA

条件2: 商品区分が通常

条件3: 割引対象フラグがON

結果: 標準単価から割引率を差し引く

判断表を作ると、テストすべきパターンも見えます。

既存マクロの修正では、コードを直すことより、どの条件を壊してはいけないかを把握することのほうが重要です。

6. 実行して初めて見えるもの

ソースコードを読んだだけでは分からないことがあります。

代表的なのは、実行時の値です。

同じプロシージャでも、呼び出し元によって渡される値が違うことがあります。

たとえば、次のようなプロシージャがあったとします。

Sub OutputResult(ByVal targetMonth As String, ByVal dataArr As Variant)

この定義だけを見ても、targetMonth にどの形式の値が入るかは分かりません。

"2026-06" なのか、"202606" なのか、日付型を文字列化したものなのかは、呼び出し元を見ないと判断できません。

ここで使うのが、ブレークポイントと呼び出し履歴です。

VBEでは、実行中に処理を止め、現在の値を確認できます。

また、呼び出し履歴を開くと、今のプロシージャがどこから呼ばれたのかを確認できます。VBEでは、標準的に Ctrl+L で呼び出し履歴を開けます。

調査では、次のものを確認します。

• 実引数として何が渡されているか

• 仮引数がどの型として受けているか

• 配列の次元と件数

• 辞書のキー

• コレクションの件数

• 処理前と処理後で値がどう変わるか

エラーが起きた行だけを見るのではなく、そこへ値が来るまでの流れを見ます。

7. エラー行は原因とは限らない

既存マクロ調査でよくある失敗は、エラー行を原因だと思い込むことです。

たとえば、次のような行でエラーが出たとします。

amount = priceDict(productCode) * qty

この行だけを見ると、辞書の参照が悪いように見えます。

しかし、原因は別の場所かもしれません。

• productCode が前処理で空になっている

• 商品コードの桁数が途中で変わっている

• 辞書を作るときのキーが数値型になっている

• マスタ読込で対象外の商品が除外されている

• 呼び出し元が別の月のデータを渡している

つまり、エラー行は症状であって、原因とは限りません。

ここで呼び出し階層、データフロー、実行時の値を合わせて見ます。

8. シートに見えるものだけを信じない

Excelマクロでは、シートが目に見えるため、ついシートだけを確認したくなります。

しかし、実際の処理はシートだけで完結していないことがよくあります。

高速化のために、シートを一度配列へ読み込み、配列上で処理してから最後にシートへ戻すことがあります。

また、検索を速くするために、マスタを辞書へ入れていることもあります。

この場合、シート上の値を見ても、中間処理の誤りは分かりません。

調査では、次の場所を確認します。

• シートから配列へ読み込む箇所

• 配列を加工する箇所

• 辞書へ登録する箇所

• 辞書から値を取り出す箇所

• 配列や辞書からシートへ書き戻す箇所

特に、配列の添字、辞書のキー、列番号のずれは、画面だけでは見落としやすいところです。

9. 調査の標準手順

既存マクロを調査するときは、次の順序を標準にすると安定します。

21. 調査用コピーを作る

22. 自動実行や外部接続の危険を確認する

23. taki3lib.bas を取り込む

24. mod_amalgam でソース全体を1ファイル化する

25. mod_list でプロシージャ一覧を作る

26. mod_tree で入口候補から呼び出し階層を見る

27. 全体概要図を書く

28. データフローを書く

29. 判断表を書く

30. ブレークポイントを置いて実行時の値を見る

31. 原因候補を1つずつ潰す

32. 修正範囲を決める

33. 修正後に、入口から一連の処理を再実行する

34. 調査用のログ、停止コード、メッセージを残していないか確認する

この順序にすると、思い込みで直す危険が下がります。

10. AIに読ませる前にやること

既存マクロをAIに読ませる場合も、いきなりブックやコードを渡すのは避けます。

先に、次のことを行います。

• 個人情報や社外秘の値をマスクする

• 不要なシート名、顧客名、ファイルパスを一般化する

• mod_amalgam でコードを1ファイル化する

• mod_list の一覧を付ける

• 調べたい入口を明示する

• 何を知りたいのかを絞る

AIに渡すときは、「このコードを全部読んで」ではなく、次のように依頼するほうがよいです。

このVBAは、売上明細を読み込み、商品マスタと突き合わせ、集計結果を出力する処理です。

入口は RunMonthlySummary です。

まず、入力、処理、出力の流れを整理してください。

次に、金額計算に関係するプロシージャだけを抽出してください。

調査の入口と目的を絞ることで、AIの回答も実務に使いやすくなります。

11. よくある悪い調査

避けたい調査は、次のようなものです。

• 本番ファイルを直接開いて直す

• エラー行だけを見て修正する

• 呼び出し元を確認しない

• シート上の値だけを確認する

• 配列や辞書の中身を見ない

• 入口が複数あるのに1つだけだと思い込む

• 使われていないコードと使われているコードを区別しない

• 調査用のメッセージやログを残したまま納品する

既存マクロでは、1行の修正が遠い場所に影響します。

だからこそ、先に地図を作ります。

まとめ

滝Libを使った既存Excel VBAマクロ調査では、滝Libを開発部品として見るより、調査キットとして見るほうが分かりやすくなります。

mod_amalgam でコードを集め、mod_list で棚卸しし、mod_tree で呼び出し階層を見る。

そこから、全体概要図、データフロー、関数コールツリー、判断表を作る。

最後に、ブレークポイントと呼び出し履歴で実行時の値を確認する。

この順序を守ると、既存マクロを「なんとなく読む」のではなく、「直せる状態に分解する」ことができます。

既存マクロ調査で大事なのは、急いで直すことではありません。

どこを直すべきかを間違えないことです。

出典メモ

• 元資料: C:\Users\hoehoe\Downloads\takilib_macro_debug_research_article_source_revised.md

• 滝Lib確認元: C:\Dropbox\takilib\release\latest_release\taki3lib.bas

• 確認した主なプロシージャ: mod_amalgam、mod_list、mod_tree

• 関連記事: 記事088_VBA関数コールツリーを軽量に理解する260524

• 確認日: 2026-06-21