AIにマクロを頼むと複雑化する理由と対処
「AIに頼んだらマクロが動いた。でも、そこから修正を重ねるうちに誰も中身を触れなくなった」——エンジニアがいない会社でAIにマクロを書かせると、かなりの確率でこの状態に行き着きます。
結論から言うと、これはAIの性能の問題ではなく依頼の仕方が「継ぎ足し」になっている構造の問題です。AIは前提の全体像を持たないまま、目の前の要望を満たすコードを追加します。追加は積み上がり、削除は起きません。
株式会社Fyveは中小企業のAI活用を月額で支援しています。この記事では、AIにマクロ（VBA）を頼むとなぜ複雑になるのかを構造から説明し、非エンジニアでも判断できる対処を整理します。扱うのは「うまく書かせるコツ」ではなく、そもそもマクロにするかどうかの判断から始まる設計の話です。
動いているのに誰も触れないマクロが増えていく
Excelのマクロは、中小企業の事務作業に深く入り込んでいます。整形、転記、印刷、集計、メールの下書き。かつては詳しい社員が1人で作り、その人が辞めたあと誰も触れないまま動き続けている、という状況があちこちにあります。
AIが使えるようになって、この状況に2つの変化が起きました。1つは、マクロを作れる人が増えたこと。もう1つは、誰も読めないマクロが増える速度も上がったことです。後者はあまり語られませんが、実務上はこちらのほうが深刻です。
問題の本質は「動くかどうか」ではありません。動くコードは簡単に手に入ります。問題は動いているものを安全に変えられるかです。事務作業のマクロは、業務が変われば必ず変更が必要になります。変更できないマクロは、変更が必要になった瞬間に業務を止めます。
なぜAIに頼むとマクロが膨らむのか
膨らむ理由は感覚的なものではなく、構造として説明できます。大きく4つあります。
1. AIは前回の文脈を引き継いでいない
会話の中では続いているように見えても、AIは「このマクロが会社のどの業務のどこに位置しているか」を持っていません。渡されたコードと、その回の指示だけを見て判断します。したがって既存のコードの意図を尊重するより、指示を満たす最短の追加を選びます。
人間の担当者なら「この処理は3か月前に例外対応で入れたものだから、本筋を直すべきだ」と判断できます。AIにはその判断材料がありません。結果として、本筋を直すべき場面でも分岐が1本足されます。
2. 継ぎ足しの依頼は継ぎ足しのコードを生む
非エンジニアがAIにマクロを頼むとき、依頼はほぼ例外なくこの形になります。「動いたけど、この場合だけうまくいかない」「あと、こういうときも対応して」。1回ごとに見れば妥当な依頼ですが、これを10回繰り返すと、10個の例外分岐を持つ1つの巨大な処理ができます。
本来なら、3回目か4回目の時点で「この処理は2つに分けたほうがいい」という設計変更が必要です。ところがその判断は、コードの全体を俯瞰できる人にしかできません。依頼する側が俯瞰できないと、AIは求められていない設計変更を提案しないので、そのまま積み上がります。
3. エラー処理が過剰になる
AIは安全側に寄せる傾向があります。値が空だったら、シートが無かったら、型が違ったら——想定される失敗ごとに対処を書き込みます。1つずつは正しいのですが、量が増えると本来の処理が何行目にあるのか分からないコードになります。
さらに問題なのは、エラーを検知して黙って処理を続ける形のコードが混ざることです。これは事務作業のマクロとしては最悪の挙動です。止まってくれれば気づけるものが、気づけないまま間違った結果を出すようになるからです。集計処理で1件だけ黙って飛ばされたことに、人は気づけません。
4. 消す判断ができない
コードが膨らむのは、追加が起きるからではなく削除が起きないからです。「もう使っていない処理を消してほしい」という依頼は、使っていないと判断できる人がいないと出せません。AIに「不要な処理を消して」と頼んでも、何が不要かはAIには分かりません。
この4つを並べると、共通の原因が浮かびます。全体を把握して設計を判断する役割が、どこにも置かれていないということです。AIはその役割を担いません。人が担うか、担える人がいないなら別の方法を選ぶ、という分岐になります。
「動いた」と「保守できる」は別の合格ライン
非エンジニアがAIにコードを頼むときに最も欠けているのが、この2つの区別です。動いたことは確認できるので、そこで完了にしてしまう。しかし事務作業の仕組みとして使うなら、合格ラインはもう1つあります。
保守できる状態の定義
専門知識がなくても判定できる基準として、次の4つを使ってください。
- 説明できるか——このマクロが何をするか、作った本人以外が3行で説明できる
- 入口と出口が分かるか——どのファイル・どのシートを読み、どこに書くかが明示されている
- 失敗したら止まるか——想定外のデータが来たとき、黙って進まずに止まる
- 手作業でも同じことができるか——マクロが動かなくなったとき、時間はかかっても人が同じ結果を出せる
4つ目は特に重要です。手作業に戻せない自動化は、業務のリスクを増やしています。マクロが壊れた日に業務が止まる状態は、効率化ではなく単一障害点の追加です。
判定はAIにさせない
「このコードは保守しやすいですか」とAIに聞くと、たいてい前向きな評価が返ってきます。書いた側に評価させても意味がありません。上の4つは人が業務側の目で判定する項目です。とくに1つ目と4つ目は、コードを読む力ではなく業務を知っているかどうかで判定できます。
そもそもマクロにしなくていい作業を見分ける
最も効く対処は、マクロを上手に書かせることではありません。マクロにしないことです。事務作業でマクロが選ばれている処理のうち、かなりの割合はマクロ以外の方法で置き換えられます。
マクロを使わないほうがいい作業
- CSVやテキストの取り込み・整形——取り込み手順として保存できるので、コードを書く必要がありません。設定として残るぶん、後から読める点でも優れています
- 集計・クロス集計——ピボットテーブルと数式で足ります。マクロで集計すると、計算の中身がコードに隠れて検証できなくなります
- 表記の変換・分類の付与——対応表との突き合わせで済みます。分類ルールをコードに書くと、ルールを変えるたびにコードを触ることになります
- 体裁の整形——書式やスタイルの適用は、テンプレートと条件付き書式で足りることが多い工程です
マクロが必要になりやすい作業
- 大量のファイルを個別に開いて処理し、個別に保存する
- Excelの外側（メール送信、印刷、他アプリの操作）に手を伸ばす
- デスクトップの機能に依存する処理
この区別が重要なのは、前者をマクロで書くと保守コストだけが増えるからです。取り込みや集計は、マクロを使わなければコードが1行も増えません。コードが無ければ、複雑化する余地もありません。
CSVの取り込み・整形をマクロから設定に移す具体的な設計は、別記事で扱っています。マクロを直す前に、この置き換えができるかを先に検討してください。
仕様を先に文章で固める
マクロが必要だと判断した場合、依頼の前にやることが1つあります。何をするものなのかを日本語で1枚に書くことです。コードを書く前に仕様を書く、という当たり前の順番ですが、AIに頼むときはこれが飛ばされます。会話で頼めるからです。
1枚に書く項目
- 目的——この処理で何をなくしたいのか（例: 拠点別ファイルを1つに束ねる手作業）
- 入力——どのファイル、どのシート、どの範囲を読むか。ファイル名の規則も書く
- 出力——どこに、どんな形で書くか。上書きするのか追記するのか
- やらないこと——この処理の範囲外を明記する。ここが最も効きます
- 想定外だったときの動作——止まる／スキップして記録する／続行する、のどれか
- 実行する人と頻度——誰がいつ動かすのか
この6項目のうち、AIへの依頼で最も抜けるのは「やらないこと」です。範囲を書かない依頼は、AIが親切に範囲を広げます。「ついでにこれもやっておきました」が積み重なるのは、範囲を明示しないことの結果です。
仕様はAIに書かせてよい、ただし確定は人
仕様書の下書きをAIに作らせるのは有効です。「こういう作業をマクロにしたい。仕様を6項目で整理して、足りない情報を質問して」と頼めば、抜けている前提を洗い出せます。ただし確定するのは人です。とくに「やらないこと」と「想定外だったときの動作」は業務側の判断なので、AIに決めさせてはいけません。
小さく分ける
膨らんだマクロの共通点は、1つの処理が複数の目的を持っていることです。対処は1マクロ1目的に分けることです。分ける基準は技術的なものではなく、業務側から決められます。
- 止めたい場所で分ける——人が確認を入れたい地点が処理の切れ目です。取り込み→確認→集計→確認→出力、のように分けます
- 変更の頻度で分ける——毎月変わる部分（分類ルール、対象月）と、ほとんど変わらない部分（ファイルの読み込み）は分けます
- 責任者で分ける——判断する人が違う処理は同じマクロに入れません
分けると実行回数が増えるので、面倒に見えます。しかし途中で確認できる状態は、間違いを早く見つけられるという利点があります。1回のボタンで最後まで走る仕組みは、間違いも最後まで走ります。
分けたあとに全体を束ねようとしない
分けたマクロを「1つのボタンで順番に全部実行する」形にまとめたくなりますが、これをやると分けた意味が消えます。確認の地点が無くなるからです。まとめるのは、各工程が十分に安定してからにします。
VBAとOffice Scripts・取り込み手順の使い分け
マクロの選択肢はVBAだけではありません。Microsoftの公式ドキュメント「Office スクリプトと VBA マクロの違い」（Microsoft Learn）が両者の違いを整理しているので、判断材料として重要な点を原文のまま挙げます。なお公式の日本語版では Office Scripts を「Office スクリプト」と表記しているため、引用部分はその表記に従います。
公式は根本的な違いをこう説明しています。「基本的な違いは、VBA マクロはデスクトップ ソリューション用に開発され、Office スクリプトはセキュリティで保護されたクロスプラットフォームのクラウドベースのソリューション用に設計されていることです。」そのうえで対応状況が表で示されています。
- Office Scripts——Excel on the web・Windows・Macで利用可、iOSは非対応、他のOffice製品は非対応、Power Automateから実行可能
- VBAマクロ——Excel on the webは非対応、Windows・Macで利用可、iOSは非対応、他のOffice製品で利用可、Power Automateは非対応
セキュリティの違いも明記されています。公式は「VBA マクロのセキュリティクリアランスは Excel と同じです。これにより、デスクトップへのフル アクセスが提供されます。」とし、対して「Office スクリプトは、ブックをホストしているマシンではなく、ブックにのみアクセスできます。」と書いています。
管理者側の制御についても差があります。公式は「管理者には、VBA マクロの 3 つのオプションがあります。テナント上のすべてのマクロを許可するか、テナントでマクロを許可しないか、署名された証明書を持つマクロのみを許可します。」とした上で、「この細分性の欠如により、1 つの不適切なアクターを分離するのが困難になります。」と指摘しています。VBAは会社単位でしか制御できないため、1つの問題あるマクロだけを止めるということができません。
一方でカバー範囲はVBAのほうが広く、公式は「現時点では、VBA では、特にデスクトップ クライアントで使用できる Excel 機能のより完全なカバレッジが提供されています。」と述べています。またOffice スクリプトについては「Office スクリプトでは、Excel レベルのイベントはサポートされていません。 スクリプトは、ユーザーが手動で起動したとき、または Power Automate フローがスクリプトを呼び出すときにのみ実行されます。」と記載されています。ライセンス面では、Office Scriptsの利用・作成に法人または教育機関のライセンスが必要で、VBAはデスクトップ版Excelに組み込まれていて特別なライセンスは不要とされています。
非エンジニアの判断としてどう使うか
この公式情報を、判断できる形に落とすと次のようになります。
- 取り込み・整形・集計——コードを書かない方法（取り込み手順・ピボットテーブル・数式）を第一候補にする
- Web版のExcelも使う／スケジュール実行したい——Office Scriptsを検討する。Power Automateから呼べる点が決定的な差になります
- デスクトップ固有の機能や他のOffice製品に手を伸ばす必要がある——VBAを選ぶ。ただし保守できる体制があることが前提
もう1つ、Copilotとの相性という観点があります。公式ヘルプは、Copilot in Excelについて複雑な .xlsm ブックを .xlsx にエクスポートするよう案内しています。またExcel for the webではVBAマクロの作成・実行・編集ができず（マクロを含むブックを開いて編集することはでき、マクロはブック内に残ります）、マクロの削除もデスクトップアプリで行う必要があると明記されています。
つまりマクロで固めた業務は、Copilotを載せる方向とは反対を向いているということです。今後AIを業務に載せる前提があるなら、この点は選択の判断材料になります。Copilot側で何ができるのかを業務別に確認しておくと、置き換えの見通しが立ちます。
AIに頼むときの依頼文の作り方
マクロが必要だと判断し、仕様を1枚にまとめたうえで依頼する場合の、実務的な作り方です。専門用語は要りません。
1回目の依頼に入れること
- 仕様の6項目をそのまま貼る
- 「まずコードを書かず、この仕様で足りていない点を質問してください」と先に書く
- 「専門用語を使わず、処理の流れを日本語で説明してから書いてください」と条件を付ける
1つ目のポイントは、いきなり書かせないことです。質問させると、こちらが決めていなかった前提が出てきます。そこで決めるほうが、書いたあとに直すより早く終わります。
2回目以降の依頼で守ること
- 「追加して」ではなく「仕様を更新したので、この仕様で全体を作り直して」と頼む——継ぎ足しを断つ唯一の方法です
- 修正が3回を超えたら、分けるべきかどうかを一度立ち止まって考える
- 変更のたびに、仕様の1枚を必ず先に更新する
1つ目が本記事の中心的な対処です。コードに追記させるのではなく、仕様を更新して作り直させる。これをやると、不要になった処理が自然に落ちます。削除が起きない問題は、作り直しでしか解決しません。
頼んではいけないこと
- 「いい感じに直して」——範囲が無い依頼は範囲が広がります
- 「エラーが出ないようにして」——エラーを消すのではなく、止まるべき場所で止まらせます
- 「このコードを短くして」——短さは目的ではありません。読めることが目的です
すでに膨らんだマクロをどうするか
手元にすでに誰も読めないマクロがある場合の進め方です。全部を作り直す判断はほとんどの会社で現実的ではないので、順番を決めます。
- 棚卸し——今あるマクロを一覧にし、それぞれ「誰が・いつ・何のために使っているか」を書き出す。使われていないものが必ず見つかります
- 凍結——使っていないマクロは削除せず、使わないと決めて記録する。削除は最後でいい
- 説明の生成——残ったマクロについて、AIに「このコードが何をしているかを、専門用語を使わず業務の言葉で説明して」と頼む。この用途はAIが最も安全に効きます
- 置き換え可能性の判定——説明を読んで、取り込み手順や数式で置き換えられるものを選ぶ。ここで大半が候補になります
- 1つだけ置き換える——最も単純なものから1つ。うまくいったら次へ
3の「説明の生成」は、業務側の人が読める形で出させることが要点です。コードの解説ではなく、業務の説明を求める。「A列をB列にコピーしています」ではなく「拠点別の売上を集計シートに転記しています」という粒度です。
4で置き換え候補を選ぶとき、集計処理の設計をどう組み直すかは別記事で扱っています。
よくある質問
AIが書いたマクロは信頼できないということですか
そうではありません。問題はコードの品質ではなく変更の重ね方です。1回で完結する処理をAIに書かせるのは実務的に有効です。危険なのは、同じコードに何度も追記を重ねていく使い方で、これは人が書いても同じ結果になります。仕様を更新して作り直す形にすれば、AIに書かせることのリスクは大きく下がります。
コードが読めなくても大丈夫ですか
コードそのものを読める必要はありません。ただしそのマクロが業務として何をしているかは、必ず言葉で分かる状態にしてください。この記事の4つの判定基準（説明できる／入口と出口が分かる／失敗したら止まる／手作業に戻せる）は、コードを読まずに判定できるように選んであります。
CopilotにVBAマクロを書かせることはできますか
Copilot in Excelの公式ドキュメントに列挙されている機能は、シートやセルの操作、書式、数式、グラフ、ピボットテーブル、データの質問といったブックの操作が中心で、VBAマクロの作成は挙げられていません。またExcel for the webではVBAマクロの作成・実行・編集自体ができないと公式に明記されています。VBAが必要な場合は、汎用のAIに書かせてデスクトップ版Excelで動かす形になりますが、その場合も本記事の依頼の作り方は同じように適用してください。
マクロを全部やめるべきですか
いいえ。デスクトップ固有の機能や他のOffice製品に手を伸ばす処理は、VBAが適しています。やめるべきなのはマクロを使わなくても同じことができる処理をマクロにしている状態です。取り込み・整形・集計・分類付与は、その代表です。
マクロを分けると実行が面倒になりませんか
面倒になります。そのぶん途中で間違いに気づけるという交換をしています。事務作業で最も高くつくのは、間違ったまま最後まで走った処理を後から遡って直す作業です。実行回数が3回増えることと、締めのやり直しが1回発生することを比べてください。
担当者が1人しかいない場合はどうすればいいですか
1人でも、仕様の1枚を書いて残すことは成立します。むしろ1人しかいない会社ほど効きます。その人が休んだ日に、書いたものだけを頼りに誰かが同じ作業をできるかどうかが、業務が止まるかどうかの分かれ目になります。仕様は引き継ぎのための書類ではなく、自分が3か月後に読み返すためのものと考えると続きます。
マクロを直すのとAI導入は、どちらを先にやるべきですか
マクロの棚卸しが先です。棚卸しをすると、AIを載せる対象になる業務と、そもそも不要だった業務が分かれます。AIを先に入れると、不要な作業を高速化してしまいます。棚卸しから締めの短縮までの進め方は、月次のExcel締めが遅い原因と短縮の設計で工程単位に整理しました。
まとめ
AIにマクロを頼むと複雑化するのは、AIが劣っているからではありません。AIは全体の文脈を持たず、指示を満たす追加を選び、削除の判断ができない。そこに継ぎ足しの依頼が重なると、例外分岐と過剰なエラー処理が積み上がり、誰も読めないコードが残ります。
対処は3つです。マクロにしない——取り込み・整形・集計はコードを書かずに済みます。仕様を先に文章で固める——とくに「やらないこと」と「想定外のときの動作」を書きます。追記させず作り直させる——削除が起きない問題は、作り直しでしか解決しません。
そして合格ラインを2つ持ってください。動いたかどうかと、保守できるかどうか。説明できる、入口と出口が分かる、失敗したら止まる、手作業に戻せる。この4つはコードが読めなくても判定できます。私たちが支援に入るときも、まずここから確認します。動いているマクロを増やすことは簡単ですが、増えた分だけ会社が触れない領域が広がっていくなら、それは効率化ではありません。
御社の業務に合わせたCopilot導入・定着支援
「ライセンスを配ったのに使われない」を終わらせる。
業務の棚卸しから、効く業務の切り分け、社内への定着まで一貫して支援します。