作成者不在のExcelマクロ・VBAが業務の急所になっていませんか。AIエージェントでロジックを解読・文書化し、Webツールや自動処理へ移す手順、全部移行しない判断基準、優先度の付け方を整理します。
経理の月次締め、営業事務の受注データ集計、情シスの棚卸レポート——日々当たり前に回っている業務のかなりの部分が、実は一つのExcelファイルの中に埋め込まれたマクロやVBAで動いている、という状況は珍しくないと考えられます。ボタンを押せば集計表ができあがり、別のボタンで請求データが吐き出される。使っている本人にとっては「そういうもの」であり、中で何が起きているかを意識する機会はほとんどありません。
問題は、そのマクロを書いた人がもう社内にいない場合です。退職・異動・定年で作成者が去り、引き継ぎ資料もない。ファイルは動き続けているので誰も困らない——壊れるまでは。ある日、Windowsやofficeの更新、参照先ファイルの仕様変更、あるいはちょっとした入力データの形式違いをきっかけに、マクロがエラーで止まる。すると、その業務を回すために毎月手作業で数時間を費やす、という「昔のやり方」に逆戻りするか、外部に緊急で解析を依頼するしかなくなります。
属人化したExcel資産のやっかいなところは、正常に動いている限り誰も問題視しないという点にあります。むしろ「触ると壊れるかもしれないから触らない」という判断が働き、ブラックボックスのまま年々重要度だけが増していきます。中身を理解している人が減り、依存している業務が増える。この二つが同時に進むと、いつのまにか会社の基幹業務が「誰も中身を説明できない一つのファイル」に乗っている状態になります。
これは、製造現場で特定の熟練者しか調整できない検査基準がブラックボックス化していく構造とよく似ています。私たちが検査の自動化で繰り返し向き合ってきたのも、まさに「その人にしか分からない暗黙知を、いかに他者が扱える形へ翻訳するか」という課題でした。Excel資産の救出も、本質は同じ「暗黙知の言語化」だと考えています。
「たかがExcelマクロ」と軽く見られがちですが、実際には請求・在庫・原価計算・出荷指示といった、止まると事業に直結する処理を担っているケースが少なくありません。しかも、長年の運用の中で例外処理や特殊ケースへの対応が少しずつ書き足され、当初のシンプルなロジックが誰にも追えない分岐の集合体になっていることもあります。表計算の数式とVBAコード、手動の運用ルールが混在し、「Excelファイル＋担当者の頭の中」で一つのシステムが成立している、という状態です。
まず認識しておきたいのは、これは怠慢や管理不足の結果ではなく、限られた人手で業務を効率化しようとした現場の工夫の積み重ねだということです。責めるべき対象ではありません。ただ、その工夫が個人に紐づいたまま放置されると、退職と同時に事業リスクへ転化する。だからこそ、いま動いているうちに中身を救出しておく意味があると考えます。関連する視点として、Excel定型業務を生成AIで減らす方法もあわせて参照いただくと、日常業務側からの入口が見えやすいかもしれません。
ここ数年でAIコーディングエージェント——コードを読み書きできる生成AIの実行環境——が実用域に入り、レガシーコードの解析という領域で新しい選択肢が生まれています。従来、退職者が残したVBAを読み解くには、そのコードを理解できるエンジニアの時間を確保する必要がありました。VBAは書ける人が減っている言語でもあり、この確保自体が難しいことも少なくありませんでした。AIエージェントは、この「読み解く」工程を大きく肩代わりできる可能性が高いと考えられます。
いきなりWebツールへの作り替えを目指すと、たいてい失敗します。中身が分からないものを別の形に作り替えれば、元の挙動を再現できたかどうかすら検証できないからです。最初にやるべきは、AIエージェントに既存のマクロ・VBAを読ませ、「このマクロは何を入力に、どんな処理をして、何を出力しているか」を自然言語の仕様書として書き起こさせることだと考えます。
具体的には、次のような出力をAIに作らせるイメージです。これらは人間が最終確認する前提の「たたき台」ですが、ゼロから人が読むのに比べれば着手の負担は大きく下がると考えられます。
この文書化は、移行するかどうかに関わらず価値があります。仮に当面Excelのまま運用を続けると決めた場合でも、中身が言語化されていれば、担当者が代わっても引き継げますし、障害時に別の人が対応できるようになります。つまり文書化は「移行の準備」であると同時に、それ単体で属人化リスクを下げる打ち手になります。まず解読・文書化までを一区切りとして進める、という考え方をおすすめします。
もっとも、AIの出力を鵜呑みにするのは禁物です。AIはコードの構造を読み解くのは得意でも、そのコードが「業務上なぜそうなっているか」の背景までは知りません。「この分岐は何のためにあるのか」を、業務を知る担当者が突き合わせて確認する工程は省けないと考えます。AIが下書きを作り、人が意味づけと検証を担う——この役割分担が現実的です。この内製の進め方については、社内AIエージェントは内製か外注かの論点も参考になると思います。
属人化Excelの棚卸しをすると、たいてい想定より多くのマクロ・ファイルが出てきます。これを全部Webツールや自動処理に作り替えようとすると、工数も費用も膨らみ、結局どれも中途半端に終わりがちです。重要なのは「全部移行しない」と最初に決めることだと考えます。移行はコストのかかる打ち手であり、すべてに投じる合理性はありません。
毎日・毎週動いているマクロと、決算期にしか使わないマクロでは、壊れたときの緊急度がまったく違います。頻度が高いほど、止まったときに業務全体が滞る可能性が高く、救出の優先度は上がると考えられます。逆に、年に数回しか使わないものは、たとえ壊れても手作業で乗り切れる余地が残っていることが多く、優先度は下がります。
そのマクロが止まったとき、何が起きるかを想像します。請求や出荷が止まる、顧客への納期回答ができなくなる、といった事業インパクトが大きいものは、頻度が低くても優先的に手当てすべきだと考えます。一方、社内の参考資料を整形するだけのマクロなら、影響は限定的です。この「影響の大きさ」は、部門をまたいで波及するかどうかでも測れます。部門間のデータ連携が絡む業務については、部門間のデータサイロをAIエージェントでどうつなぐかの視点もあわせて検討する価値があると考えられます。
三つ目は、そのマクロが今どれだけ「触れない状態」かです。作成者が在籍していて中身も単純なら、リスクは相対的に低い。逆に、作成者不在・コードが複雑・外部依存が多い、という三拍子が揃っているものは、いざ壊れたときの復旧が極めて困難で、リスクが高いと考えられます。
これらを組み合わせると、おおよそ次のような整理ができると考えます。数値化にこだわる必要はなく、関係者の共通認識として「どれから手を付けるか」の順番が見えれば十分です。
この優先度付けは、一度作って終わりではなく、業務の変化に応じて見直すものだと考えます。最初から完璧なマップを目指すより、粗くてもいいので全体像を一枚にし、関係者で合意することの方が実務上は重要だと考えられます。
「移行する」と決めたマクロについても、移行先は一通りではありません。Excelマクロを別の形に移す選択肢はいくつかあり、どれが適切かは業務の性質によって変わると考えます。移行イコール「本格的なWebシステム化」と短絡すると、過剰投資になりかねません。
複数人が同時に使う、外部データと連携する、スマホやタブレットからも触りたい——こうした要件があるなら、ブラウザで動く社内ツールへ作り替える価値が高いと考えられます。AIコーディングエージェントを使えば、文書化した仕様をもとに、画面付きの簡易ツールをかなり短い期間で試作できる可能性があります。ただし、業務データを扱う以上、権限管理・入力チェック・バックアップといった「Excelでは暗黙だった前提」を明示的に設計し直す必要が出てきます。ここは省略できない工程です。
人が画面を操作する必要がなく、「毎晩データを突き合わせて結果を出す」ような定型処理であれば、画面のあるツールにせず、サーバ上で動くスクリプトや自動処理に置き換える方が素直な場合があります。ボタンを押す人すら不要になり、定時実行に載せれば無人で回ります。VBAの中でも「集計して転記するだけ」の処理は、この形に向いていることが多いと考えられます。
「Excelという道具自体は現場に合っている」というケースも実際には多くあります。その場合、無理にWeb化せず、VBAコードを整理し、コメントを補い、壊れやすい箇所を直し、仕様書を添える——という「延命・健全化」も立派な移行の一形態だと考えます。使い慣れたUIを変えずにブラックボックスだけ解消できるため、現場の受け入れコストが低いのが利点です。移行の目的は「最新技術に置き換えること」ではなく「属人化リスクを下げること」だと捉え直すと、この選択肢の価値が見えてきます。
どの移行先が合うかは、次のような問いで整理できると考えます。
とくに最後の「不満の在り処」を切り分けることは重要だと考えます。多くの場合、真の課題はExcelそのものではなく「誰も中身を説明できないこと」にあります。そこが解消されるなら、道具はExcelのままでも構わない、という結論は十分にあり得ます。
ここまでの考え方を、実際の進め方として時系列に整理します。あくまで一般的な目安であり、業務の複雑さによって前後すると考えられますが、大枠の順序としては次のようになると考えます。
まず、部署内で動いているマクロ付きExcel・VBAファイルを洗い出します。共有フォルダ、個人PCのローカル、メール添付で回っているもの——散在していることが多いので、ここで抜けが出ると後工程が崩れます。「誰が・いつ・何のために使っているか」を、使っている本人へのヒアリングで拾うことが有効だと考えられます。
洗い出したファイルのうち優先度の高いものから、AIエージェントにコードを読ませ、仕様書のたたき台を作らせます。ここで大事なのは、AIの出力を業務担当者が確認し、「この処理は実は◯◯のためにある」という背景知識を書き足していくことです。コードだけでは読み取れない業務の意図を補うのは人の役割で、この突き合わせを通じて、暗黙知が初めて言語化された資産になります。
文書化で中身が見えたところで、前述の三軸に照らして判断します。この段階まで来て初めて「移行する/しない」を根拠を持って決められる、という点が重要だと考えます。中身が分からないまま移行の是非を議論しても、結論は出ません。
移行対象については、いきなり全部を作り替えるのではなく、一部を試作し、既存Excelと同じ入力で同じ結果が出るかを突き合わせる、という検証を挟むことが欠かせないと考えます。「元と同じ答えが出る」ことを確認できて初めて、移行は完了と言えます。この照合を軽視すると、移行後に「昔と数字が合わない」というトラブルを招きかねません。
この一連の作業を全部情シスに丸投げすると、業務の背景が分からず手が止まります。逆に業務部門だけで進めると、技術的な検証や権限設計が抜けます。現実的には、次のような分担が機能しやすいと考えられます。
どの部門から着手するかで迷う場合は、AIエージェントはどの部門から入れるべきかの整理も判断材料になると考えます。属人化Excelは経理・営業事務に濃く溜まっている傾向があり、そこを起点にすると効果が見えやすいかもしれません。
Excel資産の救出は、進め方を誤ると「かえって混乱した」で終わりかねません。実務で起こりやすい落とし穴を、あらかじめ挙げておきます。
これらはいずれも、「速さ」を優先しすぎたときに起きがちです。中身の見えないものを扱う以上、一段ずつ検証しながら進める慎重さが、結局は近道になると考えられます。
最後に、これから着手する場合の現実的な道筋を整理します。大切なのは、いきなり全社最適を目指さず、一つの部署・一つの急所から始めて、進め方の型を作ることだと考えます。
まずは「これが壊れたら本当に困る」という一本を特定し、それだけをAIエージェントで解読・文書化してみることをおすすめします。ここで「中身が言語化される」という体験を得られれば、対象を広げる判断がしやすくなります。最初から網羅を狙うより、一本で型を作る方が確実だと考えられます。
一本目で得た進め方を、三軸の優先度マップに沿って他のマクロへ広げていきます。この段階では、移行するもの・据え置くもの・廃止するものの仕分けが効いてきます。すべてを救出するのではなく、投じた労力に見合う効果が出るところに絞る——この規律が、横展開を息切れさせない鍵だと考えます。
救出と並行して、そもそも「作った人しか分からないファイル」を今後生まないための運用も考える価値があります。業務ロジックを社内ナレッジ基盤に残す、AIエージェントで解読しやすい形でコードとコメントを整える、といった小さな習慣が、次の属人化を防ぐと考えられます。救出は一度きりの対処ですが、再発防止は文化の問題です。
ここまで一般論として進め方を述べてきましたが、実際のマクロは一本ごとに事情が異なります。どれだけ複雑か、外部依存がどれだけ絡むか、業務の意図がどこまで残っているか——これらは現物のコードと業務を見なければ判断できません。私たちは産業用画像検査の領域で、元キーエンス画像処理事業部出身の監修者のもと、「現場の暗黙知をいかに他者が扱える形へ翻訳するか」に長く向き合ってきました。その知見は、Excel・VBAという別の形をした暗黙知の救出にも通じると考えています。
属人化したExcel資産の救出に踏み出すなら、まずは一本を持ち寄っていただき、現物のコードと業務の流れを一緒に確かめるところから始めるのが確実だと考えます。机上の一般論ではなく、御社の実際のファイルで「解読・文書化がどこまで進むか」を検証しながら、移行の要否と優先度を一緒に見極めていく——そうした進め方をご提案します。中小規模から無理なく始める入口としては、社内AIエージェントは内製か外注かの論点整理もあわせてご覧いただければと思います。
コードそのものが残っていれば、AIエージェントで処理の構造を読み解き、入力・出力・分岐を自然言語で書き起こすことは相当程度可能だと考えられます。ただし、AIが読めるのはコードの構造までで、「なぜその処理があるのか」という業務上の背景は分かりません。AIの下書きを業務担当者が確認し、意図を補う工程を挟むことが前提になると考えます。
全部を移行する必要はないと考えます。使用頻度・壊れたときの影響・改修のしにくさの三軸で優先度を付け、頻度が高く影響も大きいものから救出するのが現実的です。低頻度で影響も小さいものは文書化だけ残して据え置く、実は使われていないものは廃止する、という判断も十分に合理的だと考えられます。
その懸念はもっともで、実際に起こりやすい落とし穴です。防ぐには、移行物にも仕様書とコメントを残し、業務ロジックを社内ナレッジ基盤に蓄積して、次の担当者が引き継げる形にしておくことが欠かせないと考えます。救出は一度きりの対処ですが、属人化の再発防止は運用習慣の問題だと捉えるとよいと考えられます。
既存のExcelと移行先に同じ入力を与え、同じ結果が出るかを突き合わせる検証が基本になると考えます。とくに例外処理や特殊ケースは移行漏れが起きやすいため、通常データだけでなく、過去に起きたイレギュラーな入力でも照合することをおすすめします。『元と同じ答えが出る』ことを確認できて初めて移行完了と言える、という考え方が安全だと考えます。
コードを読み書きできるAIコーディングエージェントであれば、解読・移行の下書き作成に活用できると考えられます。ただし各ツールの料金・機能・利用条件は変わり得るため、最新は各サービスの公式情報をご確認ください。ツール選定以上に重要なのは、AIの出力を人が検証する体制と、優先度を付けて進める設計だと考えます。
「これが壊れたら困る」という一本を、まず解読・文書化してみるところから始められます。御社の実際のファイルで、移行の要否と優先度を一緒に見極めます。
Excel資産の救出について相談する