業務マクロ設計者になるための学習体系
AI時代に、VBAが書ける人から、業務を理解してマクロを設計できる人へ進むための学習地図
Copyright © 2026 LWP 山中 一弘
本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。
記事要約
VBAの基本文法を覚えると、セルの値を読んだり、行を繰り返し処理したり、条件に応じて転記したりできるようになります。ここまで来ると、自分の作業を自動化する力はかなり身につきます。
しかし、部署や顧客の業務で使い続けるマクロを作る段階になると、単にコードが書けるだけでは足りません。業務マクロでは、入力データの構造、処理工程、出力結果、例外処理、検証方法、運用後の修正、引き継ぎやすさまで考える必要があります。
AIを使えば、コードのたたき台を作ることや、既存コードを説明させることは速くなります。けれども、どのデータを正とするのか、どの例外を拾うのか、どこを自動化し、どこを人間確認に残すのかは、AIが勝手に決めてくれるわけではありません。
この記事では、入門マクロを終えた人が、業務マクロを設計・実装・レビューできる人になるために、何をどの順番で学ぶべきかを整理します。VBAそのものだけでなく、Excel表をデータとして見る力、業務ルールを処理へ落とす力、検証する力、仕様書に残す力、AIの出力を評価する力までを一つの学習体系として扱います。
本記事の対象とゴール
想定読者
VBAの基本文法、セル操作、繰り返し、条件分岐はある程度書ける方。
自分用の便利マクロから、部署や顧客向けの業務マクロへ進みたい方。
AIにコードを書かせるだけでなく、設計、レビュー、検証にも使いたい方。
作った本人しか直せないマクロから脱却したい方。
Excel業務改善を、単発の自動化ではなく、継続して運用できる仕組みにしたい方。
本記事で得られること
入門マクロの次に学ぶべき領域を整理できます。
業務マクロに必要な力を、実装力だけでなく設計、検証、運用まで広げて捉えられます。
AI時代にマクロ作成者が担うべき役割を理解できます。
自分の学習計画や講座設計の骨格として使えます。
本記事で扱わないこと
VBA文法の個別解説。
具体的な業務マクロの完成コード。
Excel、Power Query、Office Scripts、Pythonの網羅的な比較。
AIツールごとの操作手順。
先に結論
入門マクロの次に学ぶべきことは、難しいVBA構文を増やすことだけではありません。
本当に必要なのは、業務データを読み、処理を分け、例外を決め、結果を検証し、他人が使える形にし、AIの出力を評価する力です。
言い換えると、目指す姿は「VBAが書ける人」から「業務マクロを設計して判断できる人」への移行です。
AI時代には、コードを書く速度は上がります。しかし、入力データの意味、業務上の例外、正しい出力、失敗時の確認方法、運用上の責任は自動では決まりません。ここを決められる人が、業務マクロ設計者になります。
第1章 中級マクロ作成者が伸び悩む理由
1.1 コードは書けるが、設計が決まっていない
中級者は、セルの値を読む、範囲をループする、条件に応じて転記する、といった処理は書けます。目の前の作業を自動化する力もあります。
ただし、業務マクロでは、コードを書く前に決めるべきことがあります。どのシートを入力とするのか。どの列をキーにするのか。途中結果をどこで確認するのか。出力形式は誰が何に使うのか。エラーになったとき、止めるのか、警告だけ出すのか。
ここが曖昧なまま書き始めると、最初は動いても、修正を重ねるほど読みにくくなります。条件分岐が増え、同じような処理が複数箇所に散らばり、どこを直せばよいか分からなくなります。
中級者が伸び悩む本当の理由は、VBAの文法不足だけではありません。コードを書く前の設計が不足していることです。
1.2 個人マクロと部署マクロは別物である
自分だけが使うマクロなら、多少の前提は自分の頭で補えます。入力ファイル名が変わったら自分で直せますし、エラーが出ても自分で原因を探せます。
部署で使うマクロではそうはいきません。別の人が実行しても同じ結果になり、エラー時に原因を確認でき、業務変更が起きても修正箇所を追える必要があります。
個人マクロでは「自分が分かる」が基準になります。部署マクロでは「他人が使える」「他人が確認できる」「他人が引き継げる」が基準になります。この違いを理解しないまま個人マクロの作り方を広げると、作った本人しか直せないマクロになります。
1.3 動くマクロと運用できるマクロの違い
動くマクロは、一度実行して期待結果が出れば成立します。
運用できるマクロは、毎月、毎週、別の担当者、別のデータ量、少し違う入力でも壊れにくく作られています。さらに、壊れた場合に、どこで止まったか、どのデータが原因か、どの確認をすればよいかが分かります。
動くマクロは、実装中心です。運用できるマクロは、設計、検証、説明、保守まで含みます。業務マクロ設計者が目指すのは後者です。
1.4 場当たり的な改修が複雑化を生む
業務マクロは、作って終わりではありません。運用後に、列が増える、ファイル名が変わる、対象外データが混ざる、部署が増える、コード体系が変わる、といった変更が起きます。
このとき、設計がないマクロでは、例外対応を後付けします。後付けされた条件分岐が増え、似た処理がコピーされ、修正箇所が分散します。
最初の改修は小さく見えます。しかし、同じ構造のまま数回直すと、全体の見通しが失われます。場当たり的な改修は、短期的には速くても、長期的には保守性を下げます。
第2章 業務マクロに必要な全体スキル
2.1 業務データを読む力
まず必要なのは、表の構造を見る力です。
どの行が1件を表しているのか。どの列がキーなのか。空白は未入力なのか、対象外なのか。コード値と表示名はどちらを使うのか。重複してよいデータなのか。
ここを読めないままマクロを書くと、正しいコードを書いても業務上は間違った処理になります。たとえば、同じ社員名が複数人いるのに氏名で突合する、月別列をそのまま増やし続ける、途中集計行を明細として処理する、といった失敗が起きます。
業務マクロ設計では、コードを書く前に、データを見ることが第一工程です。
2.2 Excel表をデータとして見る力
Excelの表には、人間が見やすい表と、機械が処理しやすい表があります。
人間が見やすい表は、セル結合、空白行、途中集計、色分け、見出しの段組みを使うことがあります。報告書としては見やすくても、マクロで読むには不安定です。
機械が処理しやすい表は、1行1レコード、1列1項目が基本です。見出し行、データ行、集計行が分かれていて、キー項目が明確です。
業務マクロ設計者は、入力表、マスタ表、作業表、出力表を分けて考えます。
入力表: 外部から受け取る元データ。
マスタ表: コード、名称、分類、変換ルールなどの基準データ。
作業表: 突合、整形、判定、検証の中間結果。
出力表: 利用者や提出先が見る結果。
この4つを混ぜないだけで、マクロはかなり保守しやすくなります。
2.3 データを解析する力
業務マクロの前には、簡単なデータ解析が必要です。
見るべき項目は多くありません。件数、重複、空白、異常値、日付範囲、コード種類、金額合計です。
たとえば、売上明細を処理するなら、総件数、取引先コードの空白、商品コードの未登録、金額のマイナス、対象期間外の日付、部門別の合計を先に確認します。給与、請求、在庫、仕訳でも考え方は同じです。
この確認をしないままマクロを書くと、想定外データが出たときに、処理が止まるか、誤った結果を静かに出してしまいます。
データ解析は、マクロ設計の前工程です。いきなりコードを書かないことが、結果的に速い開発につながります。
2.4 処理を設計する力
次に必要なのは、処理工程を分ける力です。
業務マクロの処理は、たいてい次の流れに分けられます。
入力を読む。
入力データを整える。
マスタと突合する。
業務ルールに基づいて判定する。
出力形式に整える。
件数や金額を検証する。
エラーや未照合データを一覧化する。
このように工程を分けると、コードも関数もシート構成も整理しやすくなります。すべてを1つのSubに詰め込むと、最初は速く見えます。しかし、条件が増えた瞬間に読めなくなります。
2.5 VBA、Power Query、数式を使い分ける力
業務マクロ設計では、すべてをVBAで書く必要はありません。
データ取得や整形はPower Queryが向くことがあります。行ごとの単純な判定は数式が向くことがあります。画面操作、ファイル保存、複数処理の制御、ユーザー操作の誘導はVBAが向くことがあります。
大切なのは、使える技術を増やすことではなく、どの処理をどこに置くと保守しやすいかを判断することです。
VBAだけで全部書ける人よりも、VBA、Power Query、数式、テーブル、名前定義を役割分担できる人の方が、業務では強いことがあります。
第3章 業務ルールを処理へ落とす
3.1 業務ルールは、コードの前に文章で整理する
業務マクロで難しいのは、VBA構文よりも業務ルールです。
たとえば、「対象月のデータを取り込む」という一文だけでは、設計できません。対象月は伝票日付なのか、計上月なのか、支払月なのか。月末日を含むのか。取消データは対象か。コード未登録は止めるのか。後続月のデータが混ざったらどうするのか。
このような条件を、いきなりIf文で書き始めると、後から分からなくなります。まず文章で整理し、その後で処理に落とします。
3.2 例外処理を先に決める
業務マクロでは、正常系だけではなく例外系が重要です。
例外には、入力ファイルがない、シート名が違う、必須列がない、キーが重複している、マスタに存在しない、金額が合わない、対象外データが混ざる、といったものがあります。
例外が起きたときに、処理を止めるのか、警告を出して続けるのか、対象外リストへ出すのかを決めます。ここを曖昧にすると、利用者は「何が正しい結果なのか」を判断できません。
3.3 検証を最後ではなく設計に含める
業務マクロでは、結果が出たことよりも、結果が正しいと説明できることが重要です。
件数が合っているか。金額が合っているか。キーの未一致がないか。重複は想定内か。出力対象外になったデータは説明できるか。
この確認を最後に慌てて作るのではなく、最初から設計に入れます。検証用の作業表、差分一覧、エラー一覧、処理ログを用意しておくと、利用者も開発者も安心して使えます。
第4章 AI時代に必要なマクロ作成者の役割
4.1 AIに任せられること
AIは、関数のたたき台、既存コードの説明、リファクタリング案、エラー原因の候補、テスト観点の列挙に使えます。
長いVBAコードから処理の流れを抽出したり、変数名や関数分割の改善案を出したりすることもできます。仕様書の下書きや操作説明書のたたき台にも使えます。
AIを使うことで、手作業の速度は大きく上がります。
4.2 人間が判断すること
一方で、AIが判断しにくいことがあります。
どのデータを正とするか。例外をどう扱うか。業務上どの結果が許容されるか。どこまで自動化し、どこを人間確認に残すか。誰が結果を承認するか。マクロが間違ったときに、どの業務リスクがあるか。
これらは業務側の判断です。AIの出力は、業務要件に照らして評価しなければなりません。動くコードでも、業務上の正解とは限りません。
4.3 AIを使うほど、設計力が重要になる
AIがコードを書く時代には、コードを書く力が不要になるわけではありません。
むしろ、AIが出したコードの前提、責務分担、例外処理、検証方法を評価する力が必要になります。AIが作ったコードをそのまま使うのではなく、業務データ、処理工程、検証方法と照らして採用するか判断します。
これからのマクロ作成者は、コードを書く人から、設計して判断する人へ移っていきます。
第5章 学習体系として何を順に学ぶか
5.1 第1段階: Excel表をデータとして見る
まず、表の構造を見ます。行の単位、列の意味、キー項目、空白、重複、異常値を確認します。
ここでは、VBAを書かなくても構いません。フィルター、COUNTIF、ピボットテーブル、Power Queryのプレビューなどを使って、データの癖を見ます。
5.2 第2段階: 処理を分ける
次に、入力、整形、判定、突合、出力、検証を分けます。
処理工程が分かれていれば、VBAの関数分割も自然になります。シート構成も、入力表、作業表、出力表、マスタ表に分けやすくなります。
5.3 第3段階: 実装する
VBAで書くべき部分を実装します。
この段階では、すべてをVBAに寄せる必要はありません。Power Queryで整形し、テーブルで範囲を安定させ、VBAで制御し、数式で確認列を作る、といった分担も有効です。
5.4 第4段階: デバッグする
不具合を再現し、原因箇所を切り分け、変数や中間結果を確認します。
エラーが出た場所だけを見るのではなく、そこへ至るデータの流れを追います。入力、作業表、出力のどこで想定とずれたかを確認します。
5.5 第5段階: 検証する
件数、金額、キー、差分、対象外データを確認します。
検証は最後に慌てて行うものではありません。処理設計に含めます。検証できないマクロは、業務で安心して使えません。
5.6 第6段階: レビューする
他人のマクロを読み、処理の流れ、関数分割、変数名、シート構成、保守性を見ます。
レビューできるようになると、自分の設計も良くなります。レビューは他人を責めるためではなく、業務のリスクを下げ、引き継ぎやすい形にするための作業です。
5.7 第7段階: 仕様書に落とす
入力仕様、出力仕様、処理概要、操作手順、エラー時の対応を書きます。
仕様書は形式ではありません。将来の自分や他人が直せるようにするための道具です。マクロの中にしか仕様がない状態を避けることが、保守性を高めます。
第6章 学習するときの実務課題
6.1 売上明細の整形
売上明細を題材にすると、入力表、マスタ表、作業表、出力表の分離を学びやすくなります。
商品コード、得意先コード、日付、数量、金額を使い、マスタ照合、未登録チェック、金額集計、出力表作成を行います。業務マクロの基本要素が一通り含まれます。
6.2 請求データの突合
請求データと入金データを突合する課題では、キー設計、金額差異、未照合データ、複数候補の扱いを学べます。
完全一致だけでなく、日付ずれ、手数料差し引き、複数明細の合算など、実務らしい例外が出ます。
6.3 仕訳データの作成
仕訳データの作成では、入力データから会計システム向けの出力形式へ変換する考え方を学べます。
勘定科目、補助科目、部門、税区分、借方貸方、金額、摘要など、出力側の仕様に合わせてデータを組み立てます。ここでは、業務ルールをどれだけ明確にできるかが重要になります。
まとめ
入門マクロの次に学ぶべきことは、VBAの細かい構文だけではありません。
業務マクロでは、データを読み、処理を設計し、結果を検証し、他人が使える形にし、AIの出力を評価する力が必要です。
AIは、マクロ作成者の仕事を置き換えるだけではありません。コード作成、解析、レビューを速くする一方で、人間側には設計と判断の力をより強く求めます。
これから目指すべき姿は、単にVBAを書ける人ではなく、業務を理解し、処理を分け、検証できる業務マクロ設計者です。
出典メモ
元Markdown: C:\Users\hoehoe\マイドライブ\LWP記事\codex\archives\processed_downloads\20260521_business_macro_expert_outline_ai.md
改訂日: 2026年5月21日
加工方針: 元Markdownの章立てをもとに、章節名だけでは伝わらない前提、具体例、業務での判断ポイント、AI時代の役割を補い、単独で読める公開記事へ再構成した。