こんな状況、心当たりはないだろうか。
- 「このVBAマクロ、誰が作ったの？」と聞いても、もう退職した人だった
- ボタンをダブルクリックしないとマクロが動かない。原因は誰にも分からない
- Excelファイルが20MBを超えて、開くだけで1分かかる
- VBAのソースコード管理のために、わざわざテキスト書き出しツール（vbac等）を使っている
私は製造業の生産技術職として5年以上働きながら、まさにこの問題と向き合ってきた。最終的にC#/.NETへの段階的な移行を選び、結果として業務の安定性と開発効率が大きく変わった。
この記事では、VBAの限界を製造業の現場目線で整理し、C#への移行を「段階的に、小さく始める」ロードマップとして紹介する。
この記事で分かること
- VBAの5つの構造的な限界（なぜ「頑張っても解決できない」のか）
- 移行先の選択肢（Python / Power Platform / C#）の比較と判断基準
- 段階的な移行ロードマップ（5ステップ）
- 移行後に実感した具体的な改善ポイント
対象読者
- 製造業でExcel VBAの業務ツールを運用している方
- VBAの属人化や保守の問題に悩んでいるDX担当者・情シスの方
- 「C#に移行すべきか」の判断材料を探しているエンジニア
VBAの5つの構造的な限界
「VBAが悪い」と言いたいわけではない。VBAは「今すぐ動くものをサッと作れる」という点で優秀なツールだ。問題は、それが組織の業務基盤として長期運用されたときに起きる。
1. ソースコードの変更管理ができない
VBAのコードはExcelファイルの中に埋め込まれている。Gitのようなバージョン管理システムで差分を追うには、vbacのような外部ツールでソースをテキストに書き出す必要がある。
私の現場でもvbacを使って管理していたが、正直に言うと運用は面倒だった。「書き出し忘れ」が起きると差分が追えなくなり、結局「どのバージョンが最新か分からない」という状態が発生する。
C#なら.csファイルがそのままテキストなので、GitHubで普通に管理できる。プルリクエストでレビューもできるし、変更履歴も完全に追える。
2. テストの自動化が難しい
VBAの単体テストフレームワークは存在するが、有料だったり導入のハードルが高い。結果として「手動で動かして目視確認」がテストの主流になる。
製造業の品質管理データを扱うマクロで「手動テスト」は正直怖い。数値の丸め処理や集計ロジックにバグがあっても、気づくのは問題が起きた後になりがちだ。
C#ならxUnitやNUnitで単体テストが書ける。さらにGitHub Copilotを使えば、テストコードの生成もかなり楽になった。
3. UIの挙動が不安定
VBAで作ったフォーム（UserForm）やシート上のボタンは、動作が安定しないことがある。私が経験した例では、ボタンをダブルクリックしないと反応しないという現象が発生し、原因の特定に丸1日かかった。
結局、Excelのバージョンやセキュリティ設定の組み合わせが原因だったが、このような「環境依存の不具合」はVBAの構造的な弱点だ。
C#のWinFormsやWPFならUIの動作は安定している。ボタンのクリックイベントが発火しない、なんてことはまず起きない。
4. 他システムとの連携が困難
製造業のDXが進むと、Excelの中だけで完結する業務は減っていく。データベース、計測器、基幹システム、クラウドサービスとの連携が必要になる。
VBAでもADO接続やHTTPリクエストは可能だが、書き方が古く、エラーハンドリングが複雑になる。非同期処理（async/await）も使えないので、通信中にExcelが固まることもある。
C#なら、NuGetでライブラリを入れるだけでほぼ何とでも繋がる。REST API、データベース（SQLite/SQL Server）、計測器（NI-VISA）、すべて対応できる。
5. 属人化からの脱却が構造的に難しい
上の4つの問題を総合すると、「VBAで作った業務ツールは、作った人にしか保守できない」という状態に陥りやすい。
- ソース管理がないから、変更の意図が追えない
- テストがないから、修正しても壊れていないか確認できない
- UIが不安定だから、「動かない」の原因がコードなのか環境なのか分からない
- ドキュメントがコードから自動生成できないから、仕様書が陳腐化する
これは個人の能力の問題ではなく、VBAのエコシステムが持つ構造的な弱点だ。
移行先の選択肢を比較する
VBAからの移行先は、大きく3つある。それぞれの特徴を比較しよう。
| 観点 | Python | Power Platform | C# (.NET) |
|---|---|---|---|
| 学習コスト | 低め | 低い | やや高め |
| Excel操作 | openpyxl等で可能 | 限定的 | ClosedXML/EPPlus で高機能 |
| デスクトップUI | 弱い（Tkinter等） | Power Apps（Web系） | WinForms/WPF で強力 |
| 計測器・ハード連携 | 可能だが情報少ない | 不可 | NI-VISA公式対応 |
| ソース管理 | ✅ Git対応 | △（ソリューションファイル） | ✅ Git完全対応 |
| テスト環境 | ✅ pytest等 | △ | ✅ xUnit/NUnit |
| AI支援（Copilot等） | ✅ 対応 | △ 限定的 | ✅ GitHub Copilot対応 |
| 社内展開のしやすさ | インストール必要 | Microsoft 365契約内 | exe配布で簡単 |
| 長期保守性 | ○ | ○ | ◎（型安全、IDE支援） |
私がC#を選んだ理由
製造業の現場では「デスクトップアプリとして動くこと」「計測器と通信できること」「作ったツールをexeで配布できること」が重要だった。この3点を満たすのはC#だけだった。
Pythonは汎用性が高いが、デスクトップUIが弱い。Power Platformは手軽だが、ハードウェア連携やオフライン動作に制約がある。
ただし、これは「製造業の業務アプリ」という文脈での判断だ。データ分析がメインならPython、ワークフロー自動化がメインならPower Automateのほうが合うケースもある。
C#への段階的移行ロードマップ
「全部いっぺんに移行する」のは現実的ではない。業務を止めずに、小さく始める5ステップを紹介する。
Step 1: 棚卸し — 今あるVBAを全部リストアップする
まず、社内で使われているVBAマクロを棚卸しする。以下の情報を整理しよう。
| 項目 | 内容 |
|---|---|
| ファイル名 | 例: 品質検査集計_v3.xlsm
|
| 作成者 | 分かれば記録 |
| 使用頻度 | 毎日 / 毎週 / 月1回 / ほぼ使わない |
| 業務上の重要度 | 高 / 中 / 低 |
| 保守リスク | 作成者が在籍しているか、ドキュメントがあるか |
| 移行の優先度 | 上記を踏まえて判断 |
ポイント: 「使用頻度が高い × 保守リスクが高い」ものから移行候補にする。全部移行する必要はない。
Step 2: 最小のC#アプリを1つ作る
いきなり大きなシステムを作ろうとしない。まずは一番シンプルなVBAマクロをC#で書き直すところから始める。
おすすめの最初のターゲットは「Excel帳票の自動生成」。理由は、VBA版と出力結果を比較しやすいからだ。
// ClosedXMLでExcelファイルを生成する最小例
using ClosedXML.Excel;
using var workbook = new XLWorkbook();
var sheet = workbook.AddWorksheet("検査結果");
sheet.Cell("A1").Value = "検査日";
sheet.Cell("B1").Value = "製品名";
sheet.Cell("C1").Value = "結果";
sheet.Cell("A2").Value = DateTime.Today;
sheet.Cell("B2").Value = "製品A";
sheet.Cell("C2").Value = "合格";
workbook.SaveAs("検査結果.xlsx");
このコードは10行程度だが、VBAとの違いを体感できる。Excelを起動する必要がなく、Gitで管理でき、テストも書ける。
Step 3: 開発環境を整える
C#での開発を続けるために、最低限の環境を整えよう。
- Visual Studio Community（無料）をインストール
- Git でソース管理を開始（GitHubのプライベートリポジトリでOK）
- GitHub Copilot を導入すると、コード生成やテスト作成がかなり効率化される
ここまで整えば、VBAでの開発とは別次元の体験になるはずだ。IntelliSenseによる補完、ブレークポイントを使ったデバッグ、リファクタリング機能。どれもVBAでは得られなかったものだ。
Step 4: 段階的に移行する
Step 1で棚卸しした優先度の高いものから、1つずつC#に移行していく。
移行のペース: 月に1つのマクロを移行する程度で十分。無理に急がない。
コツ: 移行期間中はVBA版とC#版を並行稼働させる。C#版が安定したことを確認してから、VBA版を廃止する。
Step 5: チームへの展開
C#で作ったツールは.exeファイルとして配布できる。Excelのマクロ設定を気にする必要もない。
チーム内の他のメンバーにも使ってもらい、フィードバックをもらおう。「前より使いやすい」と言ってもらえたら、移行は成功だ。
移行して実際に良くなった5つのこと
私がVBAからC#に移行して実感した変化を、具体的に書いておく。
1. ソース管理が「普通に」できるようになった
vbacでテキストに書き出す手間がなくなった。.csファイルをGitで管理するだけ。変更の差分がプルリクエストで見られるので、チームでのレビューもできるようになった。
2. AIがコードを書いてくれるようになった
GitHub Copilotの恩恵が大きい。C#はCopilotとの相性がよく、テストコードの生成、リファクタリングの提案、ドキュメントの自動生成など、開発速度が目に見えて上がった。
VBAでもCopilotは使えるが、C#ほどの精度は出ない。言語のエコシステムが充実しているほど、AIの支援も的確になる。
3. UI構成の自由度が上がった
WinFormsやWPFでは、UserFormでは実現できなかった柔軟なレイアウトが組める。DataGridViewでの一覧表示、タブ切り替え、ツリービューなど、業務アプリに必要なUIパーツが揃っている。
4. NuGetでライブラリが簡単に追加できる
Excel操作ならClosedXML、PDF生成ならQuestPDF、データベースならDapper。必要な機能をInstall-Package1つで追加できる。VBAでは「参照設定」で苦労していたのが嘘のようだ。
5. テストコードが書けるようになった
xUnitで単体テストを書き、CIで自動実行できる。「修正したら別の箇所が壊れた」という問題を事前にキャッチできるようになった。品質管理のデータを扱うツールで、これは本当に安心感がある。
よくある質問
Q. C#の学習コストはどれくらい？
VBAの経験があれば、C#の基本文法は1〜2週間で理解できる。変数、条件分岐、ループ、関数の概念はVBAと共通しているため、ゼロからのスタートではない。本格的な業務アプリを書けるようになるまでは2〜3ヶ月を見ておくといい。
Q. 既存のVBAマクロを全部移行しないとダメ？
全部移行する必要はない。使用頻度が低く、保守リスクも低いマクロはそのまま残してよい。「壊れたら困るもの」「属人化しているもの」から優先的に移行するのが現実的だ。
Q. 上司に移行を提案するにはどう説明すればいい？
「VBAのサポートがMicrosoftから段階的に縮小されている」「作成者が退職した場合の業務停止リスクがある」「C#なら外部ベンダーへの委託もしやすい」の3点が、経営層に伝わりやすい。コスト面では、Visual Studio Communityは無料であり、既存のPCで開発できることを伝えよう。
Q. Power Automateではダメなの？
ワークフローの自動化（メール通知、ファイル移動、承認フロー等）にはPower Automateが向いている。ただし、デスクトップUIを持つ業務アプリや、計測器との通信が必要な場面には対応できない。用途によって使い分けるのがベストだ。
Q. 小さな会社でも始められる？
むしろ小さな会社ほど始めやすい。大企業のような社内承認プロセスが少なく、1人のエンジニアの判断で技術選定を変えられることが多い。まずは自分の担当業務から小さく始めてみよう。
まとめ
VBAの限界は「個人の頑張り」では解消できない構造的な問題だ。ソース管理、テスト、UI安定性、外部連携、属人化——これらはVBAのエコシステムそのものに起因する。
移行先としてC#を選んだのは、製造業の業務アプリに求められる要件（デスクトップUI、ハード連携、exe配布）を満たし、かつAI（GitHub Copilot）との相性がよかったからだ。
大事なのは「一気に全部移行する」ではなく「小さく始めて、段階的に広げる」こと。まずは1つのマクロをC#で書き直すところから始めてみてほしい。
もっと詳しく知りたい方へ
この記事で紹介した「VBAからC#への段階的な移行」について、自社の業務に当てはめて具体的に検討したい方は、お気軽にご相談ください。
- 現状のExcel/VBA業務の課題をヒアリング
- 移行の方向性と優先順位をフィードバック
- 所要時間: 30分程度（オンライン）
筆者について
製造業で5年以上の生産技術経験を持つC#エンジニア。品質管理・計測器制御・業務自動化の現場経験をもとに、中小製造業の業務改善を支援しています。
📝 この記事は Zenn で最初に公開されました。
最新版はZennをご覧ください。
📝 この記事は Zenn で最初に公開されました。最新版はZennをご覧ください。