属人化したExcelマクロをAIで解析してみた｜罠15個・仕様書化からPython再構築まで実測

作った人はもう会社にいない。でもそのマクロは今日も動いている——心当たりはありませんか。属人化したExcelマクロを模した「呪いのブック」（VBA約250行・罠15個入り）をわざと作りました。これをClaude（Opus 4.8）にブラインドで解析させ、仕様書化からPython再構築までを実測。どこまで見抜けて、何を見落とすのか。数字で確かめます。

結論：罠15個のうち11個。ただし「バグかどうか」は決めてくれない

結論から言うと、「コードが何をしているか」の解読はほぼ満点でした。一方で、「それが仕様なのかバグなのか」の判断は人間に残ります。実測の数字がこちらです。

指標	実測値
罠の検出（15個仕込み）	11.0個相当（73.3%・完全9＋部分4＋見落とし2）
業務ルールの再現（全10個）	10個（100%）
Python再構築との出力突合	128/128セル一致（100%）
AI解析の所要時間	183.5秒
計画外の指摘	8件（うち1件は本物の潜在バグ）

実測サマリー（検証環境と手順は本文参照）

値引き率の条件分岐も、丸めの混在も、未登録得意先が黙って素通りする挙動も、AIは正確に文書化しました。その仕様書だけを頼りにPythonへ作り直したら、元のVBAと出力が1セルも違わなかった。正直、ここまで一致するとは思っていませんでした。

ただし手放しでは喜べません。金額計算の境界に仕込んだ「バグとも仕様とも取れる罠」は、挙動こそ正確に読み取られたものの、「バグでは？」とは指摘されませんでした。ここが本記事でいちばん伝えたい点です。順に見ていきます。

「作った人がいないマクロ」は、どの会社にもある

キーマンズネットの2025年調査（N=330）では、組織内でExcelマクロ（VBA）を「現在使用している」が50.9%。半数の職場でマクロは現役です。同記事は、追加コストなしで短期間に作れるマクロが「導入当初は合理的な選択肢」になっている構図も指摘しています。合理的に始まったものが、担当者の異動や退職で誰にも触れなくなる。属人化の典型コースです。

属人化そのものの調査でも傾向は同じです。管理職200名への実態調査（taiziii・2025年8月）があります。ベテラン社員が突然辞めた場合の懸念1位は「問題発生時に誰も解決できなくなる」の36.5%。「業務が完全にストップする」も23.5%に上ります。Excelマクロに限った数字ではありませんが、「マクロを作った人が辞めた」は、この懸念がそのまま現実になるケースです。

では、AIはこの状況をどこまで救えるのか。実物を作って確かめました。

検証用の「呪いのブック」を実際に作った

実在の会社のマクロを晒すわけにはいきません。そこで架空の卸売会社「株式会社ミナトヤ商事」を設定し、属人化マクロの典型を全部盛りした検証用ブックを生成しました。データはすべて合成ダミーで、実在の企業・個人の情報は含みません。

シート構成：受注100行／得意先・商品マスタ／隠しシート「設定」（手数料率入り）
マクロ：月次売上レポートを作るVBA 3モジュール・約250行
業務ルール：得意先ランク別値引き・大口追加値引き・15日締め・手数料計算など10個
検証環境：Excel 16.0／Python 3.13／openpyxl 3.1.5／解析はClaude Opus 4.8

実験の流れの図。罠15個入りの呪いのブックをブラインドのClaude Opus 4.8が解析して仕様書を生成し、仕様書だけを頼りにPythonへ再構築、元のVBA出力と128セル中128セル一致した — 実験の流れ。解析側には正解リストを渡さない「ブラインド」方式

仕込んだ罠は15個。すべて「あるある」です

コメント0行、変数名は a や tmp、ループはGoTo。エラーはOn Error Resume Nextで握りつぶし、手数料率は隠しシート頼みです。どれも現場のレガシーマクロで実際に見かけるものばかり。実物のコードを少しだけお見せします。

    i = 2
Loop1:
    If i > n Then GoTo Done1
    d = ws.Cells(i, 1).Value
    tokuCode = ws.Cells(i, 2).Value
    suryo = ws.Cells(i, 4).Value
    tanka = ws.Cells(i, 5).Value
    '（中略）
    If Day(d) > 15 Then          ' 16日以降は繰越。月は見ていない
        kuri(b) = kuri(b) + 1
        GoTo NextI
    End If
    '（中略）
    If suryo > 100 Then          ' 100ちょうどは対象外。仕様？バグ？
        nrate = nrate + 0.03
    End If
    tmp = kingaku * (1 - nrate)
    Kingaku2 = Int(tmp)                  ' 切り捨て
    tesu = Round(Kingaku2 * gRitsu, 0)   ' 四捨五入（しかも偶数丸め）
NextI:
    i = i + 1
    GoTo Loop1
Done1:

※原本はコメント0行です。上のコメントは、記事用にわたしが後から付けた注釈です。見どころは2つ。数量が「100を超えたら」3%の追加値引き（100ちょうどは対象外）。それと、値引後金額は切り捨て・手数料は四捨五入という丸めの不統一です。15個の罠は正解リストとしてJSONに記録し、採点にだけ使います。

実測1：ブラインドのClaudeは罠をどこまで見抜いたか

解析側のClaudeに渡したのは、.basファイル全文とシート構造の要約（シート名・列見出し・行数のみ）だけ。罠リストも設計メモも渡していません。カンニングなしの一発勝負で、「業務仕様書と技術仕様書を書いてください」とだけ依頼しています。183.5秒後に返ってきた仕様書を、正解リストと突き合わせた結果がこちらです。

罠15個の検出結果マップ。9個を完全検出、4個を部分検出、コメント皆無と命名混在の2個を見落とし。計画外の指摘も8件あった — 検出マップ。数値・構造の罠に強く、様式・命名の罠は拾いにくい

数値と構造の罠にはめっぽう強い。マジックナンバーの意味推定、二重実装の乖離リスク、隠しシート依存、デッドコードの副作用——9個は完全検出でした。丸めの不統一への指摘は、こちらの想定より一段深いものです。「VBAのRoundは銀行丸め（偶数丸め）なので、他システムと1円差が出る可能性がある」——そこまで読むのかと驚きました。

一方で、見落としもありました。「コメントが1行もない」「日本語ローマ字混在の命名」という様式面の罠2個はスルー。動作に影響しない“属人化臭”は、意外と拾わないのが現状です。

想定外だったのは「仕込んでいないバグ」の発見

技術仕様書のリスク欄には、わたしが仕込んだ覚えのない指摘が8件並んでいました。その筆頭がこれです。

### 日付空欄・非日付セルの扱い（バグ疑い）
本体 Sub にエラーハンドラがない。d = Cells(i,1).Value が空欄だと
d=0（1899-12-30）となり Day(0)=30 > 15 で
空欄行が「繰越」として計上される。

—— AI生成の技術仕様書（spec_technical.md）より抜粋

日付が空欄の行があると、VBAはd=0を「1899年12月30日」と解釈します。Day(0)=30が締め日の15を超えるため、空欄行は繰越として静かに計上される——実際にその通りに動く挙動です。設計者であるわたし自身が意図していない、本物の潜在バグでした。前任者のコードをAIに読ませる価値は、この「誰も知らなかった挙動の発見」にもあります。なお、レガシーコードの解析・ドキュメント化はAnthropic公式もClaudeの用途として掲げている領域です。

実測2：仕様書だけでPythonに作り直したら、全セル一致した

次に、AIが書いた技術仕様書「だけ」を頼りに、openpyxlで月次レポートを再実装しました。元のVBAコードは見ません。仕様書が間違っていれば出力がズレて即バレる、という仕掛けです。

結果は128セル中128セル一致（16得意先×8列・行の並び順まで一致）。「100ちょうどは値引き対象外」も「切り捨てと四捨五入の混在」も「未登録得意先は黙って計上」も、そのまま再現。仕様書が怪しい挙動まで正確だった証拠です。並行稼働での突合が一発で通った形になります。

では、そのまま移行してよいのか——1,350円の答え

ここで最初の問いに戻ります。数量「>100」は仕様か、バグか。試しに「100以上」へ直した場合の影響を計算すると、数量ちょうど100の受注を持つ得意先C001の数字がこう動きます。

項目	現行（100超で値引き）	修正（100以上で値引き）	差
値引後金額合計	332,574円	331,224円	−1,350円
手数料合計	9,977円	9,936円	−41円
純売上合計	322,597円	321,288円	−1,309円

境界を1つ動かすだけで金額が変わる（得意先C001・感度分析）

どちらが正しいかは、コードのどこにも書かれていません。決められるのは業務側だけです。AIは挙動を正確に文書化しましたが、「これはバグでは？」という疑義としては挙げませんでした。移行プロジェクトの最後の1ピースは、いまも人間の確認作業です。

向かない場面と注意点

VBAのままが合理的なケースは普通にあります。業務がExcelで完結し、作った本人が現役で、改修も頻繁でないなら、急いで移行する理由はありません。まず仕様書化だけで十分です。
AIに移行を丸投げはできません。IBMは「数十年のハードウェアとソフトウェアの統合はコード移植では再現できない」とAIによる近代化に釘を刺し、Thoughtworksも「現実はそう単純ではない」と検証しています。今回も、境界値の意思決定は最後まで人間に残りました。
様式面の指摘は苦手。コメント皆無・命名の混在といった負債はAIの指摘に出てこないので、人間のレビュー観点として残しておくのが安全です。
Python移行には環境配布の問題が付きます。各PCへのPython導入やライブラリ管理という新しい保守が生まれるので、「Excelだけで完結」の手軽さとは交換条件になります。
コストの注記：今回の解析はAPI直呼びの計測経路が使えず、実測コストは取得できませんでした。トークン量からの概算で22円前後（±50%）です。実測値と性質が違うため、分けて書いています。

移行する・しないの判断基準

状況	現実的な一手
作った人が現役・Excel内で完結・改修まれ	VBAのまま。AI解析で仕様書だけ作って保険にする
作った人が不在・エラーが出たら誰も直せない	まずAI解析で現状を仕様書化する（数分で終わる）
定時実行したい・他システムと連携したい・行数が増え続ける	Python等へ再構築し、並行稼働で出力突合してから切替
金額まわりの境界・丸めの意図が不明	移行前に業務側と確定する。ここはAIでは決められません

属人化マクロの現実的な対処フロー

まとめ：解読はAI、判断は人間

属人化したExcelマクロ（罠15個・約250行）をブラインドのClaude Opus 4.8で解析。罠検出73.3%・業務ルール再現10/10だった
AI仕様書だけからのPython再構築で、元のVBA出力と128/128セル一致（100%）
仕込んでいない本物の潜在バグ（日付空欄→繰越に誤計上）まで自力発見した
ただし「仕様かバグか」の判断は人間の仕事。様式面の負債指摘も苦手だった
解析だけなら約3分。前任者マクロの「保険としての仕様書化」は今日からできます

「うちにも触れないマクロがある」という会社の方へ。この記事と同じ属人化マクロの解析・ドキュメント化・再構築は、NEORIVAとして法人向けにも構築しています。ブックを開ける状態なら、入り口は現状の仕様書化からで十分です。

AIにどこまで任せられるかの実測は、ほかにも記録があります。散らかったフォルダのAI自動整理（分類精度94.3%）と、請求書のAI読み取り→CSV化です。ほかの実測記録は業務自動化・API連携カテゴリにまとめています。