「作った人しか分からない」ExcelマクロとVBAを今いる人だけで解読する方法

「このExcel、開くたびにボタンを押すと勝手に集計されるんですけど、これ誰が作ったんですか」。そう聞かれて、答えられる人が社内にもう誰もいない。ファイルを開くと見慣れたボタンが並び、クリックすれば毎回きちんと動く。売上集計も、請求書の下書きも、在庫の締め処理も、このExcelファイルひとつに任せきりになっている。けれど、ボタンの裏で何が行われているのか、そのコードを開いて読める人は、少なくとも今の職場にはいない。

前任者が退職して数ヶ月、数年が経ち、ふと「これ、もし壊れたらどうするんだろう」という不安がよぎる。バージョンを上げたらエラーが出ないか。担当者が変わってパソコンを買い替えたら、同じように動くのか。誰に聞けばいいのかも分からないまま、今日もそのマクロは黙って業務を支え続けている。この記事は、そうした「作った人にしか分からないExcelマクロ・VBA」を、今いる人だけで解読していくための実務ガイドです。

先に結論を言います。VBAマクロの解読は、プログラミングを一から習得する必要はありません。「マクロの記録」機能で今の操作をコードに変換して見比べる、コードを1行ずつ実行して動きを目で追う、変化した値をその場で確認する、という3つの手を動かす方法を組み合わせれば、専門知識ゼロからでも「何が起きているか」は十分に読み解けます。難しいプログラミングの文法を暗記する必要はなく、Excelという「使い慣れたアプリケーションの延長線上にある仕組み」として捉え直すことが、最初の一歩になります。

この記事で分かること

この記事では、前任者が作成したExcelマクロ・VBAコードが業務の根幹を支えているものの、社内に中身を理解している人が誰もいない状況を想定し、非エンジニアの立場から安全にコードを解読していく手順を、着手前の準備から具体的な読み方、そして最終的な記録の残し方まで順を追って解説します。

対象とするのは、すでに稼働しているVBAマクロを「今いる人だけで」理解しようとする状況です。外部の開発会社に丸投げする前段階として、あるいは開発会社に依頼するにしても「何がどこまで分かっていないか」を整理するために、まず自分たちでできることを一通りやり切ることを目指します。

調査の全体像を先に示すと、次の順序で進めます。

• 準備: 壊さないための最低限の備え(バックアップ・環境の確保)
• ステップ1: マクロがどこに保存されているかを洗い出す
• ステップ2: Visual Basic Editor(VBE)を開き、全体の量を把握する
• ステップ3: 「マクロの記録」機能を使い、今の操作をコードに変換して見比べる
• ステップ4: コードの基本構造(オブジェクト・プロパティ・メソッド)を理解する
• ステップ5: デバッグ機能で1行ずつ実行し、動きを目で追う
• 補助策: AIツールにコードを読ませる際の注意点
• 記録: 分かったことをシステム管理台帳に残す
• 見極め: 自力で読み解けない場合の判断基準

それぞれのステップでやることと注意点を、順番に見ていきます。

なぜVBAマクロは「作った人にしか分からない」状態に陥りやすいのか

本題に入る前に、なぜこの種のマクロがここまで属人化しやすいのかを押さえておきます。理由が分かると、解読の際に「どこを重点的に見ればよいか」の見当がつきやすくなるからです。

理由は大きく3つあります。

1. ドキュメントを残さなくても動いてしまう。VBAはExcelファイルの中にコードごと保存できるため、設計書や仕様書を別途作らなくても、ファイルさえ渡せば一見「引き継げた」状態になります。しかし中身の意図やロジックの理由は、コードのコメントに書かれていない限りどこにも残りません。
2. 「マクロの記録」機能で作られたコードは読みにくい。後述しますが、Excelには操作を自動でコード化する便利な機能があります。この機能で生成されたコードは、動作はしても人間が読んで意図を追いやすい構造にはなっておらず、属人化をさらに助長します。
3. 一度動き出すと触る理由がなくなる。正しく動いている限り、誰も中身を確認する必要に迫られません。結果として、動いているという事実だけが引き継がれ、なぜそう動くのかという理由は失われていきます。

実務上の視点: VBAマクロは、正式なシステム開発を経ずに、業務の合間に「ちょっと便利にしたい」という動機で作られることが大半です。設計書がないのは怠慢ではなく、そもそも設計書を作る前提のプロジェクトとして始まっていないためです。この前提を理解しておくと、前任者を責める気持ちにならずに、淡々と調査に取りかかれます。

着手前に確認すること。壊さないことが最優先

VBAマクロは、良くも悪くも「ファイルの中に業務ロジックが直接埋め込まれている」仕組みです。調査のためにコードを不用意に書き換えたり、ボタンを連打して挙動を試したりすると、そのまま本番データを壊してしまうリスクがあります。着手前に、必ず次を確認・準備してください。

• ファイルのコピーを取る。調査対象のExcelファイル(マクロが含まれる.xlsmファイルなど)は、必ずコピーを作成し、コピーの方を開いて調査する。オリジナルには極力触れない
• 保存先を確認する。ファイルサーバー上の共有フォルダにあるファイルなら、他の人が同時に開いて上書きしてしまわないよう、調査中であることを周知する
• 「実行してよいもの」と「読むだけにとどめるもの」を区別する。ボタンを押して動かす前に、まずコードを目で追って何が起きるかを推測する。集計・表示だけならリスクは低いが、ファイルの削除・上書き・メール送信・他システムへの書き込みを行う処理は、実行前に必ず内容を確認する
• セキュリティ設定を変更した場合は元に戻す。後述するVBEを開くために設定を変更することがありますが、調査後に元の状態へ戻すか、少なくとも変更内容を記録しておく

実務上の心構え: 「動いているマクロは、動いている理由がある」という前提で臨んでください。一見無駄に見える処理や、コメントアウトされたまま残っているコードであっても、削除や無効化をする前には必ず「なぜこれが存在するのか」の仮説を立て、確認が取れるまでは手を出さないことが、調査中の事故を防ぐ最大の防御策になります。

ステップ1 マクロがどこに保存されているかを洗い出す

VBAマクロは、必ずしも今開いているファイル1つの中だけに存在するとは限りません。まず「どこにマクロが保存されているか」を洗い出すところから始めます。

主な保存場所は次の3パターンです。

「ボタンを押すと動く」という現象だけを見ていると、そのマクロが今開いているファイルの中にあるのか、パソコン内の見えない場所(個人用マクロブック)に隠れているのかを見誤ることがあります。特に前任者のパソコンをそのまま引き継いだ場合、個人用マクロブックの中に、誰も存在を知らないマクロが眠っているケースは珍しくありません。

• 前任者のパソコンを引き継いだ場合は、必ず個人用マクロブックの中身も確認する
• 複数のExcelファイルで同じような処理が動いている場合、共通のアドインを参照している可能性を疑う
• ファイルサーバー上に同名・類似名のファイルが複数ある場合、どれが「本物(実際に使われているファイル)」かを先に特定する

ステップ2 Visual Basic Editor(VBE)を開き、全体の量を把握する

保存場所が分かったら、次はVBA専用の編集画面である「Visual Basic Editor」(通称VBE)を開き、そのマクロがどれくらいの規模で書かれているかを把握します。

VBEを開く手順は次の通りです。

1. Excelのリボンに「開発」タブが表示されているか確認する。表示されていない場合は、「ファイル」→「オプション」→「リボンのユーザー設定」から「開発」にチェックを入れて表示させる
2. 「開発」タブの「Visual Basic」ボタンをクリックする(ショートカットキーはAlt + F11)
3. 画面左側に表示される「プロジェクトエクスプローラー」で、対象のファイル名の下に「標準モジュール」「クラスモジュール」「ThisWorkbook」「Sheet1」などの階層が展開できることを確認する

VBEを開いたら、いきなりコードを読み始めるのではなく、まず全体の「量」を数えることから始めてください。

• 標準モジュールの数。プロジェクトエクスプローラーの「標準モジュール」フォルダの中に、いくつのモジュール(Module1、Module2など)があるか
• 各モジュールの行数。モジュールをダブルクリックして開き、おおよそ何行のコードが書かれているか(数十行なのか、数千行に及ぶのか)
• シートに直接書かれたコードの有無。プロジェクトエクスプローラーで各シート名(Sheet1など)やThisWorkbookをダブルクリックし、そこにもコードが書かれていないか確認する。ボタンのクリックイベントなどは、標準モジュールではなくシートやブック自体に直接書かれていることがある

実務上のポイント: いきなり全体を読み解こうとせず、まず「全体でどれくらいの分量があるか」を把握するだけにとどめてください。数十行程度なら比較的短時間で読み切れますが、数千行に及ぶ場合は、優先順位をつけて重要な部分から読む方針に切り替える必要があります。この判断のためにも、最初の「量の把握」は欠かせません。

Microsoft公式のヘルプによれば、VBAプログラミングの基本は「Officeアプリケーションが公開する“オブジェクト”に対して、命令(メソッド)を送ったり、性質(プロパティ)を設定したりすること」にあるとされています。Excelというアプリケーション自体を、命令を受け取れる部品の集合体として捉える考え方です。この見方を持っておくと、後述するコードの構造も理解しやすくなります(参照: Microsoft Learn「Office VBA の基礎知識」)。

ステップ3 「マクロの記録」機能で今の操作をコードに変換し、見比べる

VBAのコードを読む上で、非エンジニアにとって最も実践的な武器になるのが「マクロの記録」機能です。これは、Excel上で行った操作(セルをクリックする、値を入力する、書式を変更するなど)を、Excelが自動的にVBAコードへ変換して記録してくれる機能です。

この機能を使えば、プログラミングの文法を先に覚える必要はありません。まず操作をしてみて、それがどんなコードになるかを確認するという、逆方向からのアプローチでコードの意味を推測できます。

「マクロの記録」の使い方

1. 「開発」タブの「マクロの記録」ボタンをクリックする
2. マクロ名(初期値のままでよい)を確認し、「OK」を押すと記録が始まる
3. 前任者が作ったマクロが行っていそうな操作を、自分の手で実際に行ってみる(例: 特定のセルを選択する、値を入力する、別シートに切り替える)
4. 「開発」タブの「記録終了」ボタンをクリックする
5. 「マクロ」ボタンを押し、今記録したマクロを選んで「編集」を押すと、VBEに生成されたコードが表示される

たとえば、セルB1を選択して「Hello World」と入力する操作を記録すると、次のようなコードが自動生成されます。

Sub Macro1()
'
' Macro1 Macro
'
'
    Range("B1").Select
    ActiveCell.FormulaR1C1 = "Hello World"
    Range("B2").Select
End Sub

このコードを、前任者が作った謎のマクロと見比べてみてください。「Range("B1").Selectは、B1セルを選択するという意味だったのか」「Valueという単語は、セルの値を指しているのか」というように、実際の操作と生成されたコードの対応関係から、単語の意味を一つずつ推測していくことができます。

実務上の注意: マクロの記録機能で生成されるコードは、動作の全ての手順を律儀に記録するため、無駄な行が多く読みにくいという特徴があります。Microsoft公式のヘルプでも「マクロレコーダーはユーザーが何を意図しているかを仮定して機能するため、その仮定が正確でないと、生成されたコードがあいまいになる」と説明されています(参照: Microsoft Learn「Office VBA の基礎知識」)。あくまで「読み解くための対応表を作る」目的で使い、これ自体を本番のマクロとして使い回すことは避けてください。

見比べのコツ

• 前任者のコードに出てくる見慣れない単語(プロパティ名・メソッド名)を1つ選び、それに近い操作を自分で試して記録してみる
• 記録して出てきたコードの単語で、その単語だけを選択してF1キーを押すと、Microsoftのヘルプがその単語について検索される(該当するリファレンスページが見つかる場合がある)
• 一度に全部を理解しようとせず、「よく出てくる単語から3〜5個」に絞って、集中的に対応関係を確認する

ステップ4 コードの基本構造を押さえる。オブジェクト・プロパティ・メソッド

いくつかの単語の意味が分かってきたら、次はコード全体の「構造」を把握します。VBAのコードは、細部の単語が分からなくても、構造さえ理解していれば「何が」「何に対して」「何をしているか」の骨格を追うことができます。

VBAコードの基本的な考え方は、次の3つの要素の組み合わせです。

たとえばWorksheets(1).Range("A1").Value = "Wow!"というコードは、「1番目のシートのA1セル(オブジェクト)の、値(プロパティ)を、"Wow!"に設定する」という意味になります。日本語の語順とは前後しますが、コードを左から右に「オブジェクト→プロパティやメソッド」の順に読んでいくと、英文法のように意味を追うことができます。

コード全体の構造としては、次の単位で分かれていることも押さえておいてください。

• Sub〜End Sub: 一連の処理のかたまり(プロシージャ)。ボタンに割り当てられているのは、通常このいずれかのSubプロシージャです
• Function〜End Function: 値を計算して返す処理のかたまり。Subと似ていますが、計算結果を呼び出し元に返す点が異なります
• コメント('で始まる行): プログラムの実行には影響しない説明書き。前任者が残していれば、コメントは何よりも貴重な一次情報です。まずコメントだけを拾い読みするのも有効な方法です
• If〜Then〜Else(分岐): 条件によって処理を変える部分。「もし〇〇ならA、そうでなければB」という日本語に置き換えて読む
• For〜Next(繰り返し): 同じ処理を指定回数繰り返す部分。「これを10回繰り返す」といった箇所によく使われる

実務上のコツ: 変数名やコメントに前任者独自の日本語ローマ字(uriage、seikyuなど)が使われていることがあります。読みにくく感じるかもしれませんが、裏を返せば「その単語が何を指しているか」の強力な手がかりでもあります。変数名から業務用語を逆引きする視点を持つと、理解が早まります。

ステップ5 デバッグ機能で1行ずつ実行し、動きを目で追う

コードの構造がある程度つかめたら、最も確実な理解の方法である「1行ずつ実際に動かして、その場で結果を確認する」作業に進みます。VBAには、この目的のためのデバッグ機能が標準で備わっています。

ステップイン実行(F8キー)

VBEでコードを開いた状態でF8キーを押すと、コードが1行だけ実行され、次に実行される行が黄色くハイライトされます。これを繰り返すことで、コードを1行ずつ順番に動かしながら、Excelの画面がどう変化するかを目視で確認できます。

• コードの先頭にカーソルを置いてからF8を押し始める
• 1行実行するたびに、Excelの画面(裏に見えているシート)を確認し、どのセルが変化したかを見る
• If文やFor文にさしかかったときに、どちらの分岐に進むか、何回繰り返されるかを目で追う

ブレークポイント(F9キー)

コード全体を1行ずつ追うのが大変な場合は、「ここまでは普通に実行して、この行に来たら止めてほしい」という指定ができます。これがブレークポイントです。

1. 止めたい行の左端の余白部分をクリックする(その行が赤色でハイライトされる)。または該当行にカーソルを置いてF9キーを押す
2. マクロを通常通り実行する(ボタンをクリックするか、F5キーを押す)
3. ブレークポイントを設定した行の直前で処理が自動的に停止する
4. 停止した状態からF8で1行ずつ進めたり、変数の中身を確認したりする

イミディエイトウィンドウ(Ctrl + G)

処理が停止している状態、あるいはコードを実行していない状態でも、「イミディエイトウィンドウ」という小さな入力欄を使うと、変数の中身やセルの値をその場で確認できます。

1. VBEの「表示」メニューから「イミディエイトウィンドウ」を選択する(ショートカットキーはCtrl + G)
2. 表示された入力欄に? 変数名または?Range("A1").Valueのように入力してEnterキーを押す
3. その時点での値が、イミディエイトウィンドウ上に表示される

たとえば、処理を一時停止させた状態でイミディエイトウィンドウに?goukeiと入力すれば、その時点でgoukeiという変数に何の値が入っているかを確認できます。これにより、「このコードが実際に何を計算しているか」を、コードを読むだけでなく実測値で裏付けることができます。

Microsoft公式のヘルプでも、イミディエイトウィンドウについて「コード内のステートメントのデバッグ、またはウィンドウに直接入力されたコマンドからの結果の情報が表示される」と説明されており、コードの理解とデバッグの両方に使える標準機能として位置づけられています(参照: Microsoft Learn「イミディエイト ウィンドウ (VBA) を使用する」)。

実務上の注意: ブレークポイントを設定したまま作業を終えると、次にファイルを開いた人が「処理が固まった」と誤解する可能性があります。調査が終わったら、設定したブレークポイントは必ず解除してください(該当行を再度クリックするか、「デバッグ」メニューの「すべてのブレークポイントの解除」を使う)。

補助策としてAIツールにコードを読ませる際の注意点

近年は、VBAのコードをChatGPTやClaudeなどのAIツールに読ませて、日本語で解説してもらうという方法も現実的な選択肢になっています。長いコードの大まかな要約を素早く得たいときには有効な手段です。

ただし、利用にあたっては次の点に注意してください。

• 機密情報を含んだままコードを貼り付けない。取引先名・顧客情報・社内の固有ルールを示すコメントなどが含まれている場合は、該当箇所を伏せ字にするか、無関係な文言に置き換えてから貼り付ける
• AIの説明を鵜呑みにせず、実際の動作(ステップ実行の結果)と突き合わせる。AIはコードの一般的な読み方は得意ですが、そのコードが自社の業務上どんな意味を持つかまでは推測できません。あくまで「読み方のヒントを得る」補助的な使い方にとどめ、実際の値の確認はステップ実行やイミディエイトウィンドウで行ってください
• 契約している法人向けAIサービスの利用条件を確認する。会社として法人契約しているAIツールがあれば、入力データの学習利用に関する設定(オプトアウト設定など)を事前に確認しておくと安心です

AIツールはあくまで「最初の要約」や「見慣れない単語の意味を尋ねる相手」として使い、最終的な業務判断の根拠は、必ず自分の手で確認した実際の挙動に置くようにしてください。

分かったことを記録に残す。次に引き継ぐ人のために

解読作業を進める中で分かったことは、その場限りにせず、必ず記録として残してください。せっかく苦労して読み解いた内容も、記録に残さなければ、また次の担当者が同じ苦労を繰り返すことになります。

記録として残すべき項目の例を整理します。

• マクロの保存場所(どのファイルの、どのモジュールにあるか)
• 実行されるタイミング(ボタンを押したときか、ファイルを開いたときか、定期的に自動実行されるのか)
• 処理の概要(何を読み込んで、何を計算し、何を出力するか。専門用語を使わず業務の言葉で書く)
• 分かっていないこと・未確認の部分(無理に「分かった」と書かず、保留中の箇所は正直に「未確認」と記録する)
• 関連するファイル・システム(このマクロが読み書きしているExcelファイルや、連携している他のシステムがあれば)

これらの記録は、システム管理台帳の一部として、他のシステム情報と合わせて一元管理することをおすすめします。マクロ単体の情報だけを別ファイルにまとめてしまうと、時間が経つにつれてその記録自体の存在が忘れられ、結局また「誰も分からない状態」に逆戻りしてしまうためです。

• 記録は完璧を目指さず、まず「分かったところまで」を書き残すことを優先する
• 記録した日付を必ず残す(コードは更新される可能性があるため、いつ時点の調査結果かが分かるようにする)
• 可能であれば、記録内容を後任者や上長にも共有し、自分一人だけが知っている状態を避ける

実務上のポイント: この記録作業こそが、今回の「解読」という一時的な作業を、恒久的な資産に変える最も重要なステップです。コードを読み解けたという事実そのものよりも、その内容が組織に残ることの方が、長期的には価値があります。

危険な兆候の見分け方。安易に触ってはいけないマクロの特徴

解読を進める中で、慎重に扱うべき「危険な兆候」を持つマクロに出会うことがあります。次のような特徴が見られた場合は、実行やコードの変更を一旦保留し、より慎重に扱ってください。

• ファイルの削除・上書きを行うコード(Killというコマンドはファイル削除を意味します。実行前に対象を必ず確認する)
• メール送信を自動で行うコード(Outlookオブジェクトを操作し、意図せず取引先や社内に大量のメールが送られてしまうリスクがある)
• 他システムへの書き込み・データベースへの接続を行うコード(社外のサービスや基幹システムに接続する処理は、誤操作が業務全体に波及するリスクが大きい)
• パスワードや接続情報がコード中に直接書き込まれているコード(セキュリティ上のリスクであると同時に、担当者交代のたびにこの情報が引き継がれているかも確認すべき対象になる)
• 極端に長い、あるいは複数のモジュールにまたがって処理が分岐しているコード(全体像の把握に時間がかかるため、優先順位を下げて後回しにする判断も選択肢の一つ)

これらの特徴を持つマクロについては、無理に自力で完全に理解しようとせず、次の「見極め」のセクションで触れる外部の力を借りる判断を早めに検討してください。

どうしても読み解けない場合の見極め

ここまでの手順を踏んでも、どうしても解読が進まない、あるいは業務への影響が大きすぎて自力での調査に踏み切れないケースもあります。そうした場合の判断基準を整理しておきます。

自力での解読を続けるべきか、外部に相談すべきかを判断する目安は次の通りです。

1. 業務が止まったときの影響範囲。そのマクロが止まると、経理の締め処理や請求書発行など、外部との取引に直結する業務が止まるのであれば、早期に外部の専門家へ相談する
2. コード量と自分たちの理解速度。ステップ2で数えたコードの分量に対して、1週間かけても半分も理解が進まない場合は、自力での完全解読よりも「重要な部分だけ理解し、残りは専門家に確認してもらう」方針に切り替える
3. 危険な兆候の有無。前セクションで挙げたファイル削除・外部送信・データベース接続などを含むコードが見つかった場合は、そのマクロだけでも早めに専門家の目を通すことを検討する

外部に依頼する場合の選択肢としては、次のようなものがあります。

• 保守契約のある開発会社に、現状調査(コードレビュー)だけを依頼する。マクロの改修や作り直しではなく、「何が書かれているか」の調査だけを切り出して依頼できないか相談してみる
• VBAからより保守性の高い仕組みへの置き換えを検討する。長期的な視点では、属人化しやすいVBAマクロを、Power Automateのようなノーコードツールや、外部のシステム開発に置き換えるという選択肢もあります。ただし、置き換えには相応のコストと検証期間が必要になるため、まずは現状のマクロの内容を正確に把握してから判断するのが安全です
• 自社で対応する(内製化)か、外部に任せ続けるかを改めて検討する。今回の調査を通じて社内にVBAを読める人材が育ってきたのであれば、今後の運用体制自体を見直すきっかけにもなります

いずれの選択肢を取るにしても、今回の記事で解説した手順を一通り自分たちで実施しておくことには意味があります。「何も分からない」状態と「ここまでは分かったが、この部分だけ判断がつかない」状態とでは、外部に相談する際の質問の精度も、見積もりの正確さも大きく変わってくるためです。

まとめ。読み解く力は、次の属人化を防ぐ力になる

「作った人にしか分からない」状態のExcelマクロは、多くの職場に静かに存在しています。今回紹介した手順は、マクロの記録機能で操作とコードを対応させ、デバッグ機能で1行ずつ動きを確認し、分かったことを記録に残すという、特別な予備知識を必要としない地道な積み重ねです。

一度この手順を踏んで得られた理解は、今回のマクロだけでなく、今後同じような属人化したシステムに出会ったときにも応用できる汎用的な調査の型になります。そして何より、今回の調査結果を記録として残しておくことこそが、次にこのポジションに就く誰かを、同じ苦労から救うことにつながります。

社内システムの引き継ぎでは、仕様書がないシステム全般の調査手順や、属人化を防ぐための管理台帳の作り方も合わせて押さえておくと、今回のようなケースへの備えがより強固になります。次は、そうした関連するテーマの記事も参考にしてみてください。