マクロ・VBAでCAD作業を自動化する——覚える価値がある範囲の見極め

CADのマクロ機能について聞かれると、私はいつも「万能ではないが、覚えておいて損はない」と答えている。若手からベテランまで、現場で働く設計者であれば一度は誰もが「マクロを覚えれば作業が楽になるのではないか」と考えたことがあるはずだ。マクロやVBAを使いこなせば設計作業が劇的に速くなるという触れ込みをよく見かけるが、実際に現場でその通りになる場面は限られている。20年の実務の中で自分でマクロを組んだり、他の設計者が作ったものを引き継いだりしてきた経験から、どこまで手を出す価値があるのかを整理してみたい。

最初に手を出したのは図面枠の一括修正だった

私が初めてマクロに触れたのは、ある製造業の現場で図面のタイトルブロックを一括修正する必要に迫られたときだった。客先の会社名変更に伴い、数百枚の図面のタイトルブロックにある社名表記を修正しなければならなくなった。1枚ずつ開いて手で直すと、単純計算でも数日かかる作業量だった。

そのとき、社内に簡単なVBAマクロを書ける先輩がいて、図面を一括で開いてテキスト要素を置換するマクロを組んでもらった。実行してみると、数百枚の修正が数十分で完了した。この経験で、マクロの威力を初めて実感した。同時に、自分でこの程度のコードが書ければ、次に同じような依頼が来たときに他人に頼らず対応できると感じ、そこから独学でVBAを勉強し始めた。

最初は本当に基礎的な文法から始め、CADのオブジェクトモデル(図面のどの階層にどんな情報があるか)を理解するのに苦労した。ただ、最初の一歩は「自分が実際に困っている単純作業」から入ったことが良かったと思っている。抽象的な学習ではなく、目の前の面倒な繰り返し作業を解決する道具として学んだことで、モチベーションが続いた。当時は参考書を一冊通読するよりも、実際の業務データで試行錯誤する時間の方がはるかに多かったと記憶している。

振り返ってみると、最初の数ヶ月は失敗の連続だった。変数名を適当に付けていたために自分で書いたコードなのに数週間後には内容を思い出せなくなったり、ループの終了条件を誤って想定より多くのファイルを処理してしまったりと、小さなトラブルを繰り返しながら少しずつ勘所をつかんでいった。今振り返れば、この試行錯誤の期間こそが実務で使える感覚を養う上で欠かせない時間だったと思う。

マクロを学ぶ環境をどう確保するか

現場で働きながらマクロを学ぶ際、最大の課題は「まとまった学習時間を確保しづらい」ことだと感じている。私が独学を始めた当初は、日中の業務時間はもちろん通常の設計作業に充てる必要があり、マクロの学習は昼休みや終業後のわずかな時間に細切れで進めるしかなかった。

そこで意識したのは、学習内容を「今日中に使える小さな単位」に分解することだった。たとえば「ファイルを1つ開いて閉じる」という最小限の処理から始め、それができたら「フォルダ内のファイルを列挙する」、その次に「列挙したファイルを順番に開く」というように、小さな成功体験を積み重ねる形で進めた。まとまった時間が取れない状況でも、こうした細切れの学習で着実に前進できることを実感した。細切れであっても、毎日少しずつ触れ続けることの方が、たまにまとまった時間を取るより定着が早いというのが実感である。

自動化に向く作業と向かない作業の見分け方

マクロを覚えてから気づいたのは、自動化に向く作業と向かない作業がはっきり分かれるということだ。向いているのは、判断を伴わない機械的な繰り返し作業である。ファイル名の一括変更、図面枠の項目転記、部品リストのエクスポート、同じ形状の穴を規則的に配置する作業などがこれにあたる。こうした作業は、人間が判断する余地がほとんどなく、手順が明確に言語化できる。

一方で向かないのは、都度の判断が必要な作業だ。私が担当した案件で、ある若手が「干渉チェックの結果を見て修正箇所を自動で判断するマクロを作りたい」と相談してきたことがある。話を聞くと、干渉の種類によって対応方針が変わる(公差の問題なのか、そもそもの設計ミスなのか)ため、判断ロジックを組むには膨大な条件分岐が必要になることが分かった。開発にかかる時間と、そもそもの作業頻度を考えると、投資対効果が見合わないと判断し、その部分は手動チェックのまま残すことを勧めた。若手にとっては物足りない結論に聞こえたかもしれないが、無理に自動化しようとして中途半端なツールを作るより、人の判断に委ねた方が結果的に確実だと伝えた。

私は自動化を検討する際、次のような基準で判断している。

この表の全てを満たす必要はないが、複数当てはまるほど自動化の価値が高いと考えている。逆にこの基準を無視して「面白そうだから」という理由だけで自動化に手を出すと、開発時間ばかりかかって結局使われないツールが増えるだけになりがちだ。

判断に迷う場合、私は簡単な試算をするようにしている。1回あたりの作業時間と発生頻度から年間の総作業時間を概算し、それに対してマクロの開発時間がどの程度で回収できるかを見積もる。たとえば1回30分の作業が週3回発生する場合、年間で計算すると数十時間規模になる。これに対して開発に数時間かける程度であれば、投資対効果は十分に見合うと判断できる。逆に年間数時間程度にしかならない作業であれば、開発にかける時間の方が大きくなってしまうこともあり、その場合は自動化を見送っている。感覚だけで判断せず、簡単でも数字に落とし込むことで、周囲への説明もしやすくなるという利点もある。この試算を提示すると、上司や客先の担当者からも納得を得やすく、開発の時間を確保してもらう際の説得材料としても役立っている。数字で語ることの効果は、想像以上に大きいと感じている。

覚える範囲を絞ることの重要性

VBAは奥が深く、突き詰めようと思えばいくらでも学習範囲が広がる。しかし私は、CAD操作を自動化する目的であれば、覚えるべき範囲をかなり絞って良いと考えている。実際に私が日常的に使っているのは、繰り返し処理(For文)、条件分岐(If文)、ファイル操作、CADのオブジェクトを取得して値を読み書きする基本操作、この程度である。

私が担当したある部品表作成の自動化では、複雑なアルゴリズムは一切使わず、単純に「アセンブリ内の各部品を順番に取り出して、名前・材質・重量をExcelに書き出す」というループ処理だけで完結した。凝った処理を書こうとするより、単純な繰り返しの組み合わせで解決できる作業の方が、現場では圧倒的に多いというのが実感だ。

一方で、エラー処理だけはしっかり覚えておく価値がある。マクロは想定外のファイル状態(部品が見つからない、レイヤーが存在しないなど)に遭遇すると簡単に止まってしまう。私は必ず「異常があったらどこで止まったか分かるようにログを残す」処理を入れるようにしている。これを怠ると、深夜にバッチ処理を回している最中にエラーで止まり、翌朝出社したら何も処理が終わっていなかった、という失敗を経験したことがある。せっかく夜間に処理を任せたつもりが、朝になって振り出しに戻っていたときの徒労感は今でもよく覚えている。この一件以来、必ず途中経過をテキストファイルに書き出す仕組みを組み込むようにしている。

さらに、実行前に必ず対象ファイル数を数えて画面に表示するようにしている。想定していた件数と実際の処理対象件数が食い違っていれば、そこで一度立ち止まって原因を確認できる。この単純な確認を入れるだけで、意図しないフォルダを丸ごと処理してしまうような事故をかなり防げるようになった。

もう一つ習慣にしているのが、本番実行の前に必ず「実行内容を確認するだけで、実際には書き換えない」テストモードを用意することだ。処理対象のファイル一覧と、それぞれに対して何をするつもりかをログに出力するだけの空実行を挟むことで、想定通りの範囲が対象になっているかを事前に確認できる。この一手間は開発時間を多少増やすが、誤動作による被害を防げる効果を考えると、確実に見合う投資だと感じている。特に本番データに直接書き込む処理を含むマクロほど、このテストモードの有無が事故の起きやすさを大きく左右すると実感している。

CADソフトごとのマクロ環境の違い

複数の現場でCADソフトを渡り歩いていると、マクロ環境がソフトによって大きく異なることにも気づかされる。あるCADはVBAが標準搭載されている一方、別のCADは独自のスクリプト言語やAPIを別途学ぶ必要があった。私が最初に覚えたVBAの知識がそのまま通用しない場面に何度も遭遇し、そのたびに新しい環境のオブジェクトモデルを一から調べ直す作業が発生した。

このとき助けられたのは、言語仕様そのものよりも「繰り返し・条件分岐・エラー処理」という基本的なプログラミングの考え方が共通していたことだった。文法や関数名は違っても、CADのオブジェクトを順番に取得して処理するという骨格は驚くほど似ている。一度この骨格を体に染み込ませておけば、新しい環境への適応にかかる時間は思ったより短くて済むというのが、複数のCADを渡り歩いてきた実感である。むしろ苦労するのは文法よりも、そのCAD特有の用語や設定項目の把握であり、この部分はどうしても現場ごとに地道な調べ物が必要になる。

属人化のリスクとどう向き合うか

マクロを使いこなせるようになると、自分の作業効率は上がるが、同時に別の問題が生まれる。自分が組んだマクロを他の人が理解できず、自分が抜けた途端に誰も保守できなくなるという属人化のリスクだ。

私が過去に常駐した現場で、退職した設計者が残した大量のマクロ資産が、コメントもドキュメントもほとんどないまま放置されているのを見たことがある。動いているものは触りたくないという心理も働き、誰も中身を見ようとせず、結果としてブラックボックス化したツール群が延々と使われ続けていた。あるとき仕様変更でそのマクロが誤動作するようになったが、原因を追うのに数日を要してしまった。

この経験から、私は自分が組んだマクロには必ず簡単な説明をコメントで残し、可能であれば処理の概要を1枚のメモにまとめて共有フォルダに置くようにしている。凝ったドキュメントを作る必要はなく、「何のためのマクロか」「どんな入力を想定しているか」「エラーが出たときの対処法」の3点だけでも書いておくと、後任者の負担がかなり軽減される。

加えて、可能な現場では簡単な勉強会を開き、自分が作ったマクロの仕組みを他の設計者に説明する時間を設けるようにしている。全員がコードを書けるようになる必要はないが、少なくとも「何をしているツールなのか」を複数人が理解している状態を作っておくことで、属人化のリスクをかなり下げられると感じている。

この勉強会は、身構えずに気軽に参加できる雰囲気づくりを意識している。プログラミングという言葉を聞いただけで苦手意識を持つ設計者は少なくない。私はコードそのものの説明よりも先に「このマクロが動く前と後で何が変わるか」を実際の画面で見せることから始めるようにしている。結果が目に見える形で示されると、中身の仕組みにも自然と興味を持ってもらいやすくなる。実際、この進め方に変えてから、勉強会をきっかけに自分でも簡単なマクロを組み始める設計者が何人か出てきた。こうした小さな輪が広がることで、現場全体としての自動化への理解度も少しずつ底上げされていくと感じている。

他人の作ったマクロを引き継ぐときの注意点

外部設計者として複数の現場を渡り歩いていると、前任者が残したマクロを引き継いで使う場面によく遭遇する。このとき私が最初にやるのは、いきなり本番データで実行せず、必ずテスト用のダミーファイルで動作を確認することだ。

以前、前任者が残したファイル一括変換マクロを、確認を怠ってそのまま本番の図面フォルダに対して実行してしまったことがある。想定外のファイル形式が混ざっていたためにマクロが誤動作し、一部の図面のレイヤー設定が意図せず書き換わってしまった。幸いバックアップから復旧できたが、この一件以降、初めて使うマクロは必ずコピーしたテストフォルダで一通り動かし、想定通りの結果になることを確認してから本番に適用するというルールを自分に課している。

また、マクロのコードを読むこと自体も勉強になる。他人の書いたコードを追うことで、自分では思いつかなかった処理の組み方や、CADのオブジェクトモデルの使い方を学べることが多い。引き継いだマクロをそのまま使うだけでなく、時間があるときに中身を読んでおくと、後々自分で似たようなツールを作る際の引き出しが増える。読み解く過程で古い記法や非推奨の関数が使われていることに気づくこともあり、そうした場合は動作を変えない範囲で少しずつ書き直し、次の担当者が読みやすい状態に整えることも心がけている。

引き継いだマクロを改修する際は、一度に大きく手を加えないことも意識している。過去に、動作の分かりにくいマクロを整理しようとして一気に書き直したところ、想定していなかった副作用が発生し、正常に動いていた部分まで壊してしまったことがあった。この失敗以降、引き継いだコードは小さな単位で少しずつ手を入れ、その都度動作確認を挟むという地道な進め方に切り替えている。急がば回れという言葉がそのまま当てはまる作業だと感じている。効率を求めて急いだつもりが、結果的に余計な手戻りを生んでしまうという教訓は、マクロに限らず設計業務全般にも通じるものだと思う。

結局は「時間対効果」で判断する

マクロ・VBAは強力な道具だが、覚えること自体が目的化してしまうと本末転倒になる。私が現場で意識しているのは、自動化にかける学習時間と開発時間を、それによって将来節約できる作業時間と天秤にかけることだ。数年にわたって繰り返し発生する作業であれば、多少時間をかけてでも自動化する価値は十分にある。逆に一度きりの作業であれば、手作業で片付けた方が結果的に早いことも多い。

外部設計者という立場は、常駐先を移るたびに使用するCADソフトや業務内容が変わることも多い。だからこそ、特定のマクロ資産に過度に依存するのではなく、「どの現場でも通用する基本的な自動化の考え方」を身につけておくことが、長期的には最も役に立つと感じている。ツールそのものより、どこまで自動化すべきかを見極める判断力の方が、結局は長く使える資産になるというのが、これまでの経験から得た結論である。

新しい現場に入るたびに、まずは手作業でしばらく業務をこなしながら、どこに繰り返しの無駄があるかを観察する時間を意図的に作るようにしている。着任してすぐに自動化ツールを持ち込むのではなく、その現場特有の業務の流れやデータの癖を理解してから着手した方が、結果的に無駄のない自動化につながると実感しているからだ。マクロという道具を使いこなす力と同じくらい、どこにその力を向けるべきかを見極める観察力が、長く現場を渡り歩く上での実務的な財産になっていると感じている。