自動処理でExcelを書き換える前に必ず入れる「事前チェック」1手順【原本を壊さない書き方つき】

夜のうちに走るはずの自動処理が、たまに失敗している。ログには「’○○.xlsx’ にアクセスできません」としか書いていなくて、原因が分からない。実は前日、自分がそのExcelを開いたまま帰っていた。

原因が書かれていないログほど不安になるものはありません。ですが実はこれ、原因の見当さえつけば「事前に1手順足すだけ」で防げる種類のトラブルです。

⚠️ この記事の情報は2026年9月時点のものです。記事に出てくる自動処理のシステムは観測・研究用のもので、自動発注はしません（read-only）。実際のお金での発注はしていません（仮想発注のみ・実発注なし）。

症状：夜間の自動処理が、原因不明のまま止まっていた

本記事が対象にしているのは、PC内・社内共有フォルダにある.xlsxファイルを、Excelの外側から操作する自動処理（Pythonスクリプト、バッチ、タスクスケジューラで動くもの）です。Excel内で動くVBAマクロは対象外、Power Automateなどクラウド連携の自動処理は未検証です。クラウド上で共同編集中のファイルについても未検証としてください。

「毎晩勝手に走っているはずの自動処理が、なぜか失敗する日がある。エラーメッセージを見ても原因が書いていない」——そんな状態で困っていないでしょうか。

この記事で得られることは次の3つです。

• 原因不明のExcel書き込みエラーの、本当の原因の見つけ方
• 自動処理に足すだけで原本を壊さなくなる「事前チェック」の手順
• やってはいけない3つのこと（原本を先に消す・Excelを強制終了する・証拠ファイルを消す）

この後、症状→原因→対処の順で、実際にあったトラブルをもとに説明していきます。

実際に起きていたのは次のような状況でした。Excelでブックを開いたまま自動処理を走らせたところ保存処理が失敗し、担当者の手元には「'(ブック名)’ にアクセスできません」というExcel側の一行と、整形されていないエラーの詳細表示（トレースバック）だけが残っていました。ファイル自体は存在していて、読み取り専用にもなっておらず、保存先フォルダも書き込み可能。それなのに、書き込みモードで開こうとした瞬間だけ権限エラー（errno=13＝アクセスが拒否されました）になっていたのです。

原因：”~$”ファイルではなく「Excelが掴んだままだったこと」

ここで一番間違えやすいポイントがあります。原因は「怪しいファイルが存在すること」ではなく、「Excelがそのファイルを開いたまま掴んでいること」です。調べてみると、対象ブックに対応する一時ロックファイルが見つかり、そのブックを開いたままのExcelが起動していました。この一時ファイルはあくまで「Excelが今そのブックを使っている」ことの手がかりであって、それ自体が原因なのではありません。

この一時ファイルを実際に確認するには、エクスプローラーの〔表示〕タブから〔隠しファイル〕にチェックを入れる必要があります。標準設定では表示されないためです。表示をONにすると、名前が「~$」で始まるファイル（前方一致で探してください）が対象ブックと同じフォルダに見つかります。

ただし、この「~$」ファイルが見つかったからといって、それだけで「今ロック中」と断定してはいけません。閉じ忘れの残骸だけが残っていて、実際には誰も開いていないケースもあるからです。「~$」ファイルの存在は記録・証拠として扱うだけにとどめ、ロック中かどうかは別の方法で実際に確かめる、という設計にしました。

対処：書き換える前に「開けるか」を試す事前チェック

そこで、自動処理が本処理（実際の書き換え）を始める前に、「今このファイルを差し替えられるか」を実際に試して測る、1つの事前チェックを入れることにしました。手順は次の4つです。

• 対象ファイルを open(パス, "r+b") で開けるか試す
• 開けたら、何も書き込まずにそのまま即closeする（開けるかどうかの確認だけが目的）
• 開けなければ、1バイトも書き換えずに処理を中止し、成功とは別の専用の終了コードで終える
• 中止した旨を、日付つきでテキストファイルに追記する（「ファイルが使用中のため中止しました。開いているExcelを閉じて再実行してください」など。画面表示ではなくファイルに残す）

ここで重要なのは、「何もせず終わる＝正常終了（終了コード0）」にしないことです。中止は成功と区別しないと、後から誰も気づけません。ログを画面ではなくファイルに日付つきで残しておくことで、翌朝の確認や過去の傾向調査がしやすくなります。

あわせて、ロック状態は次の3種類に分けて判定するようにしました。

原本を壊さない書き方（”w”・”w+”は絶対に使わない）

ここが一番の注意点です。「書き込みモードで開いて試す」とだけ覚えてしまうと、事故につながります。Pythonで open(パス, "w") や open(パス, "w+") を使うと、そのファイルは開いた瞬間に中身が0バイトになります。事前チェックで使うのは、必ず open(パス, “r+b”) です。“w”・”w+”は絶対に使わないでください。

同じ理由で、VBAで「Workbooks.Openで開いてSaveしてみる」という試し方も禁止です。開いて保存する動作自体がファイルの内容を書き換えてしまうため、確認のつもりが原本を変えてしまいます。

実際の書き換え処理そのものも、原本に直接上書きするのではなく、いったん一時ファイルとして新しい内容を作り、最後の最後に一気に差し替える形にしています。設計上、次の3つを禁止として明記しました。

• 原本を先に消さない
• 強制的に置き換えない
• 開いている既存のExcelを強制終了しない

“~$”ファイルは証拠であって、消していい物ではない

先ほど登場した「~$」で始まるファイルについても、扱い方を明確に分けておく必要があります。自動処理の役割は「見るだけ」で終わりです。このファイルをプログラム側から削除することは絶対にしません。Excel側の排他管理の仕組みを壊してしまうおそれがあるためです。

もし「~$」ファイルが残ったままで気になる場合は、それは人間が判断する領域です。関係者が全員そのブックのExcelを閉じたことを確認したうえで、人の手で削除する、という切り分けにしてください。自動処理が自分の判断で消してよいものではありません。

まとめると、自動処理がやってはいけないことは次の3つです。

• 原本を先に消す
• Excelを強制終了する
• “~$”ファイルを消す

実機で確認できたこと

実機で、使用中の本番ブックに対してこの処理を実行したところ、正常に終了し、関連ファイルは1バイトも変化しませんでした。書き換え前に確実に止まる、という設計どおりの動きが確認できたことになります。

関連する2つのテスト群をまとめて実行し、39本のテストを新設したうえで、272 passed / 0 failedという結果になりました。

あわせて、タスクスケジューラ側の設定も見直しておくとよいでしょう。タスクの〔設定〕タブにある「失敗した場合の再起動」を有効にし、数分後に1〜2回だけ再試行させるようにしておくと、たまたま短時間だけファイルが開いていたようなケースを自動で拾い直せます。

非エンジニアが得た教訓・まとめ

今回のトラブルから得られる教訓は、「原因不明のエラーほど、実は単純な事前確認1つで防げることが多い」ということです。Excelを触る自動処理を作る・運用するときは、次の点だけ押さえておいてください。

• 本処理の前に、対象ファイルが今すぐ差し替えられるか（open(パス,"r+b")で開けるか）を試す事前チェックを1つ足す
• 開けなければ1バイトも書き換えず中止し、日付つきでテキストファイルに記録。終了コードは成功と分ける
• “~$”ファイルは隠しファイル表示をONにして見るだけ、消さない
• 原本を先に消す・Excelを強制終了する・”~$”を消す、の3つは絶対にしない

専門的な仕組みを新しく覚える必要はありません。「書き換える前に、開けるかどうかだけ試す」——このひと手間があるかないかで、原本を壊すリスクは大きく変わります。同じような自動処理を運用している方は、ぜひこの事前チェックを1つ足してみてください。

関連記事

• 「古いコピーが残っている」で慌てて消さない｜まだ使われていないか確かめる手順
• 「該当0件」を「異常なし」と書いてはいけない｜チェックが空振りしていたことに気づく方法
• タスクスケジューラ「前回の実行結果」早見表｜0x41303・0x41301・0x41306の意味と、動いたか確かめる手順

無料テンプレート配布のお知らせ

Claude Codeを安全・便利に使うための設定テンプレート（CLAUDE.md）を無料配布しています。メールアドレスをご登録いただくと、すぐにダウンロードリンクをお送りします。

免責事項

本記事は執筆時点（2026年9月）の情報に基づく、筆者個人の体験の記録です。記事中の自動売買システムに関する記述は、特定の投資手法や自動売買の利用を推奨するものではありません。投資には元本割れのリスクがあり、最終的な判断はご自身の責任で行ってください。また、本記事ではセキュリティに関わる話題に触れていますが、悪用防止の観点から、具体的な脆弱性や攻撃手法の詳細は記載していません。AIツールの仕様は予告なく変更される場合があります。最新情報は各公式ドキュメントをご確認ください。本記事の内容を用いて生じたいかなる損害についても、筆者は責任を負いかねます。