Excelマクロを置き換える前の棚卸し｜入力・出力・利用者から残す処理を決める

Excelマクロで動いている業務を、生成AIで作った仕組みに置き換えたい。そう考えたとき、最初に決めたいのは移行先の製品ではなく、今の処理のうち何が必要かです。古いファイルにも後工程を支える計算があり、毎日動くマクロでも、出力が使われなくなった処理は廃止候補になります。

部門と情シスで棚卸しを進める際は、入力、出力、その出力を使う人をつなげて記録します。本記事では、その記録を使って、止める処理、残す処理、置き換えを試す処理を見分ける方法を整理します。

棚卸しは、マクロの本数より出力の行き先から始める

共有フォルダにあるマクロ付きファイルを集めるだけでは、置き換える範囲を決めきれません。同じファイルのコピーが複数あったり、別のブックが出力を取り込んでいたりする可能性があります。ファイル一覧を入り口にしつつ、「この出力を、誰が、何のために使うか」を確認し、そこから処理をたどります。

たとえば月次集計なら、完成した一覧を見て判断する人に、必要な列、受け取りたい時点、確認後の作業を聞きます。次に実行担当者と、元データの取得、ファイルの準備、マクロの実行、結果の修正、保存や送付までをつなぎます。ボタンを押す前後に人が行っている作業も、今回の棚卸しに含めます。これは説明用の例であり、特定の企業の業務を紹介するものではありません。

ここでの単位は、ファイル単独ではなく、出力が次の仕事に渡るまでの一連の処理です。同じブック内でも、集計と印刷の利用者が違えば分けて記録します。反対に、別ファイルでも前の出力がないと動かないなら、関係を結んでおきます。処理の境目が見えると、集計を維持したまま、不要になった印刷だけを止めるといった判断ができます。

聞き取りでは「いつもの集計です」で終えず、直近の実行に使った入力と完成物を確認します。担当者の記憶による説明と、実物で確かめたことを分け、分からない箇所は質問として残します。観察の記録方法は、実際の操作と担当者の説明を書き分ける方法が参考になります。今回はその記録から、各処理を存続させる理由を確かめます。

ファイル名、保管場所、実行ボタン、呼び出される処理名は、同じ仕事を識別するための手がかりとして控えます。名前が似ていても同じ処理とは決めず、実際に使っている版を担当者に示してもらいます。聞き取りの対象から漏れた部門があれば、その部門が使う出力も追加で確かめます。作成者が退職していても、現在の実行者と出力の受け手から調べ始められます。作成者不在という理由だけで、必要な機能まで廃止候補にしないことが大切です。

入力・出力・利用者を、確認できた根拠と一緒に記録する

棚卸し台帳には、移行担当者が読んで分かる言葉を使います。「データを加工する」「結果を共有する」だけでは、残すべき条件が読めません。入力なら取得元と対象期間、出力なら形式と保存先、利用者ならその結果で行う仕事まで具体化します。以下は、月次集計を題材にした記入観点の例です。

記録すること	確認する内容
入力と起動条件	どのシステムのどの期間を取り出し、誰が何を確認してから実行するか
加工と判断	対象外の行、重複の扱い、端数処理、集計の単位をどう決めるか
出力と後続処理	必要な列、並び順、ファイル形式、保存先、次に取り込む処理は何か
関係者	実行する人、結果を使う人、廃止や変更を決める業務責任者は誰か
例外と手修正	入力不足、訂正、再実行のときに、何を止め、どこを直すか
根拠と未確認事項	実物・操作・聞き取りのどれで確かめ、未確認部分を誰に聞くか

入力については、取得後に担当者が列を並べ直していないか、不要な行を消していないかも見ます。マクロには正しい入力だけが渡っていても、その前処理が手作業なら、コードの解析だけでは条件を拾えません。元データと、実際に読み込ませたデータを見比べ、違いの理由を残します。保存した入力には、どの実行結果と対応するかが分かる印を付けます。

出力は、見えている合計額だけで判断しません。受け手が別の処理へ取り込む場合、列名や順序、日付の書き方、ファイル名にも意味があるかを確認します。見栄えのための変更に見えても、次の処理の条件なら残す対象です。変えてよい形式と、相手側の変更が済むまで維持する形式を分けると、置き換えの範囲が明確になります。

手修正は「例外対応あり」とまとめず、修正前の状態、変更した箇所、理由、判断した人の役割を記録します。毎回の修正なのか、入力に問題があったときだけなのかで、次に作る処理が変わります。理由が不明なら、自動化する仕様へそのまま移さず、業務責任者に確認する課題として残します。現行処理を説明することと、その処理を正しいと認めることは別の作業です。

生成AIにコードの説明を求める場合も、結果は台帳の下書きとして扱います。利用を認められた環境で、投入してよいコードやデータの範囲を確認し、説明された入力元、書き込み先、分岐を元コードと照合します。VBAの読み方が必要な担当者は、マクロの記録と条件分岐などの基礎を確認すると、解析結果を質問しやすくなります。

「最近使っていない」だけで廃止を決めない

廃止候補は、出力が不要になった処理から探します。「別のシステムで同じ結果を得られる」「受け手がその帳票を使わなくなった」といった理由を、出力の利用者と確かめます。その際、同じ情報があるだけで十分かも確認します。対象期間や集計条件が異なれば、見た目が似た帳票でも代わりにはならないためです。

実行頻度が低い処理には注意が必要です。年次の締めや期末の整理だけで動くものは、直近の利用状況だけでは必要性を判断できません。いつ必要になるか、前回は何を出したか、次回も同じ用途があるかを聞きます。最終更新日が古い、作成者が不在、最近実行を見ていないという事実は、調査の優先順位を決める材料として扱います。

利用者が見つからないときは、「不要」ではなく「利用者未確認」と記載します。出力先のフォルダ、定期的な送付、別のブックからの参照などを手がかりに、確認先を探します。担当部門に尋ねても答えが出なければ、その経緯と残る不明点を業務責任者へ渡します。回答がないことを、廃止への同意に読み替えないようにします。

廃止を試す段階では、停止する範囲、確認する業務の周期、問題が出たときの再開方法を決めます。現行ファイルや必要な入力を管理された場所に保全し、受け手に停止の予定と連絡先を伝えてから進めます。試行中は苦情の有無だけでなく、従来の出力を使っていた後続業務が、代替手段で完了したかを確認します。他部門の締め作業にも使う出力なら、その部門の責任者を確認に含めます。結果が出るまでは、恒久的な廃止と区別して記録します。

この判断ができれば、不要な帳票を新しいAIの仕組みで再現する必要はありません。棚卸しで減らしたいのは、保管しているマクロの数だけでなく、意味を失った作業を続ける負担です。停止の根拠がそろった処理から整理し、判断材料が足りない処理は調査待ちにします。廃止の確定日と判断者を台帳へ戻し、後で同じ調査を繰り返さないようにします。

残す業務ルールと、生成AIに任せる仕事を分ける

必要な処理が分かったら、何を残すかを決めます。ここでは「業務ルールを残す」と「VBAのコードを残す」を分けて考えます。対象行の選び方、集計単位、照合条件などは維持しつつ、実装だけ変えられるかもしれません。一方、端末や他のアプリとの連携に依存する部分は、移行先で同じ動作を再現できるか、別途確認が必要です。

MicrosoftのVBAとOffice Scriptsの比較では、VBAはデスクトップ向けで、COMなどを介した連携ができる一方、Office ScriptsにはExcelレベルのイベントがなく、手動またはPower Automateから起動すると説明されています。したがって、置き換え先を選ぶ前に、現在の起動条件と他アプリへの依存を台帳へ書く必要があります。

海外の公開例でも、すべてを同じ方式へ移すとは限りません。IBMが2026年10月2日に公開したVBA移行事例では、依存関係や業務ルールを調べ、テストの比較基準を作ったうえで、互換性が必要なExcel COMの処理を残しています。新旧の処理を並行して動かし、一致も確認しています。これは海外の公開事例であり、国内での情報管理、保存、承認に関する制度・社内規程への適合は、自組織で別途確認します。

生成AIの使い道も分けます。既存コードの説明、移植案、テスト項目の作成をAIに補助させることと、業務を実行するたびにAIが分類や判断を行うことは異なります。固定ルールの集計は、通常のプログラムや既存機能で実行し、AIは開発時の補助に使う方法もあります。何をもって一致とするかが決まっている処理に、理由なく自由な判断を加えないようにします。

自由文の分類や説明文の下書きなどを実行時のAIへ任せたい場合は、台帳の該当処理をさらに分けます。参照する情報、出してよい候補、採用を判断する人、判定できないときの戻し先を書きます。分類の提案だけを試すのか、その結果で登録まで行うのかも区別します。従来の集計まで一緒に変更せず、AIの出力が影響する範囲を絞ることが、比較可能な試行につながります。

置き換え候補は、同じ入力で出力と後続処理を比べる

置き換え候補ができたら、棚卸しで保管した入力を使い、現行処理と候補の出力を比較します。通常のデータに加え、空欄、重複、訂正、対象外の行など、実際の業務で確認すべき条件を選びます。入力、期待する結果、実行結果、差が出た理由を対応させれば、何が未解決かを担当者と話せます。

現行の出力を無条件の正解にはしません。以前から誤っていたルールを直す場合は、業務責任者が正しい期待値を決め、旧処理との差を意図した変更として記録します。差が出るたびに候補を旧処理へ近づけると、不要な手修正や既知の不具合まで引き継ぐおそれがあります。維持する条件と改善する条件を、同じ比較記録の中で区別します。期待値を決められない箇所は、合格とせず確認先へ戻します。

Microsoftが2026年6月24日に説明したExcelのAI評価は、値の正しさに加え、ブックの使いやすさや追跡可能性なども確認しています。業務側の検証でも、集計値だけでなく、受け手が結果を読み取れるか、元データへ戻れるか、次の処理へ渡せるかを確かめます。保存や取り込みまで通してみると、画面上の比較では見えない不足を確認できます。

確認が済んだ範囲は、台帳へ「維持」「廃止」「置き換え試行中」などの状態と、その根拠を戻します。未確認の依存先があれば、対象を広げる前に解消します。現場の確認と試作を往復する進め方は、renueの要件定義と実装を並行する開発モデルともつながります。棚卸しの記録があれば、試作で何を再現し、何を変えるかを具体的に示せます。

renueが重視するのは、実際の仕事と前後の受け渡しを明らかにしてから、AI化・効率化の範囲を決めることです。マクロの全廃を先に目標にするより、使われない出力を止め、必要な計算や確認を残し、比較できる処理から置き換えを試します。棚卸しが終わったと言えるのは、一覧が埋まったときではなく、各処理を残す理由と、次に確かめることを説明できるようになったときです。