朝出社してマクロを実行したら、昨日まで何事もなく動いていた処理が途中で止まる。担当者は心当たりを片っ端から試し、半日かけて復旧させたものの、何が原因だったのかは誰も説明できない。原因究明の手順や過去の調査記録がないと、切り分けに時間がかかることがあります。この記事では、現場が最初に確認すべき項目を順番に切り分ける方法と、復旧までの経緯を次回に活かせる形で残す進め方を整理します。
- 現象を言葉にする どの操作でどこまで進み、何が表示されたかを固定する
- 対象ファイルを疑う 列名・形式・値が前回から変わっていないか確認する
- 実行環境を疑う PC・Office更新・保存先・権限の変化を確認する
- 直前の変更を疑う コードと設定に手が入っていないかを突き合わせる
- 経緯を記録する 原因・対処・確認結果を案件単位で残す
まず「現象」を正確に言葉にする
「動かない」という一言だけでは、調査に必要な状況を共有できません。この言葉には、起動しない・途中で止まる・最後まで動くが結果が違う、といった全く別の状態が混在しています。最初にやるべきは原因の推測ではなく、現象の固定です。
再実行の前に、元ファイルと出力先をバックアップし、検証用コピーを用意します。メール送信・外部システム更新・ファイル削除などの副作用がある処理は、本番に影響しない検証環境で止められることを管理者と確認してください。途中まで実行済みなら、二重送信や二重登録の有無を確認してから再実行します。
次の項目を、作業を始める前にメモしてください。
| 確認項目 | 記録する内容 |
|---|---|
| 操作 | どのボタン・どのメニューから実行したか |
| 到達点 | どこまで進んだか（途中のメッセージ、シートの更新状況） |
| 表示 | エラー番号とメッセージの全文、デバッグ時の該当行 |
| 再現性 | もう一度実行しても同じか、別のPCでも同じか |
| 時点 | 最後に正常に動いた日時と、失敗した日時 |
エラーメッセージは要約せず、そのまま書き写すことが重要です。「型が一致しません」と「インデックスが有効範囲にありません」では、疑う先が全く変わります。
原因の推測より先に、現象・エラー全文・最後に動いた日時を固定します。
対象ファイル側の変化を疑う
突然止まるケースで最初に確認したいのは、コードではなくコードが扱うデータ側です。マクロは書かれたとおりにしか動かないため、入力ファイルの形の変化が、処理の停止や誤処理の原因になることがあります。
現場では、担当者が善意で列を1つ足した、取引先から届くCSVの書式が変わった、といった理由がよくあります。前回正常に処理できたファイルが手元にあれば、それを同じマクロに通してみてください。古いファイルで動き新しいファイルで止まる場合は、入力の違いや、その入力で表面化するコードの不具合が手がかりになります。データだけが原因とは断定せず、差分と処理内容を照合します。
実行環境の変化を疑う
ファイル側に問題がなければ、次は実行する側です。コードを1行も触っていなくても、環境が変われば動作は変わります。
- Windows や Office の更新が入っていないか
- マクロがセキュリティ機能でブロックされていないか（保護ビュー等の表示を記録し管理者へ確認する）
- 参照設定が「参照不可」になっていないか（別のライブラリを使う処理の場合）
- ファイルの保存先がローカルから共有フォルダやクラウド同期フォルダに移っていないか
- ネットワークドライブの割り当て文字やパスが変わっていないか
- 実行しているPCが前回と同じか、別の人のPCではどうか
クラウド同期フォルダに置いたファイルは、同期中にロックがかかって書き込みに失敗することがあります。また、担当者が交代して別のPCで実行した途端に止まる場合は、そのPC固有の設定が疑わしくなります。
直前の変更とコードの版を突き合わせる
ここまでで原因が見つからなければ、コードそのものか設定変更を疑います。問題は、「誰かが直前に何かを変えたか」を確認する手段がない現場が多いことです。
確認したい観点は次のとおりです。
- 最後に正常動作した日から今日までに、誰かがコードを開いていないか
- マクロ本体のファイルが上書きされ、ファイルの更新日時が変わっていないか
- 別件の改修で共通モジュールに手が入っていないか
- 外部の処理（別システムの出力、メール送信、スケジューラ設定）が変わっていないか
自動化案件の管理ツール Poxii は、VBA・Python・GAS などの案件を基本情報・仕様・資料・コード・会話・改修履歴の6分類で整理します。仕様とコードの版を固定して確認記録を残せるため、「正常に動いていたときの版」と「今動いている版」を突き合わせる作業が、記憶や個人のフォルダに頼らずに済みます。案件URLで管理と引継ぎができる点も、担当者が変わる場面では効いてきます。
直前の変更を追えるかどうかが、調査時間の差になります。
復旧の経緯を次回に活かす形で残す
復旧直後に、出力が正しいことと未処理・二重処理がないことを確認し、その結果と経緯を記録します。
次の6項目を基本に、業務の影響に応じて項目を追加します。
| 項目 | 内容 |
|---|---|
| 現象 | エラー全文と発生した操作 |
| 切り分け | 試したことと、その結果（効かなかったことも書く） |
| 原因 | 特定できた原因。できなければ「未特定」と書く |
| 対処 | 実際に行った修正・設定変更 |
| 確認結果 | 検証条件、期待値との照合、未処理・二重処理の確認、確認者・日時 |
| 再発防止 | 入力ファイルのルール、チェック手順の追加など |
「効かなかったこと」を書くことには意味があります。次に同じ現象が起きたとき、無駄な試行を省けるからです。原因が未特定のまま動き出した場合も、その事実を記録に残しておけば、再発したときに「前も同じだった」と気づけます。
記録の置き場所は、個人のメモやメールの中ではなく、案件に紐づく一箇所にまとめるのが前提です。会話と改修履歴が同じ案件の中に並んでいれば、「なぜこの修正をしたのか」という背景まで含めて後から追えます。
記録を案件単位に集約する
- 担当者が1人、または交代の可能性がある
- 外部委託先と仕様のやり取りがある
- 同じ仕組みを年単位で使い続ける
都度メモで足りる
- 一度きりの使い捨てマクロ
- 仕様が数行で説明でき、作り直したほうが早い
よくある質問
Q: エラーメッセージが出ずに、ただ途中で止まります。どこから見ればよいですか。
A: まず到達点を特定してください。処理の節目にメッセージ表示やログ出力を一時的に入れ、どこまで進んでいるかを確認します。そのうえで、止まる直前の処理が扱っているファイルやシートを、この記事の「対象ファイル側の確認項目」に沿って点検すると範囲を絞れます。無限ループや外部処理の応答待ちの可能性もあるため、止まった時点のCPU使用状況も手がかりになります。
Q: 作った担当者が退職し、コードの中身が分かりません。
A: その状態でいきなりコードを読み解くより、まず現在の動作仕様を外側から書き出すことをおすすめします。どのファイルを入力にして、何を出力しているかを整理すれば、修正範囲の判断ができるようになります。案件情報・仕様・コード・改修履歴を一箇所に集約しておく仕組みを用意すると、次の引継ぎで同じ事態を繰り返さずに済みます。
Q: 記録を残すルールを決めても、現場が書いてくれません。
A: 項目を増やしすぎている可能性があります。現象・試したこと・原因・対処・確認結果・再発防止を基本に、復旧した直後にその場で書き込む運用にしてください。記録の置き場所が案件ごとのURLで開けるなど、書き始めるまでの手間が少ないことも継続の条件になります。
まとめ
昨日まで動いていたマクロが止まったとき、現場が焦って手を動かすほど原因は見えにくくなります。現象を言葉として固定し、対象ファイル・実行環境・直前の変更の順に切り分ければ、確認すべき範囲は着実に狭まります。
そして、復旧できたかどうかと同じくらい重要なのが、経緯を残すことです。記録がなければ、以前に確認した内容も再調査することになります。案件の基本情報・仕様・コード・会話・改修履歴を同じ場所に集め、版を固定して確認記録を残しておけば、次の障害対応も担当者の引継ぎも、個人の記憶に頼らず進められます。まずは今動いているマクロについて、最後に正常動作した日とコードの版を書き留めるところから始めてみてください。
参考情報
