VBAの「メッセージボックス地獄」を卒業して、Pythonのログ出力に救われた話

親切心が生んだ、自動化エラーの罠

深夜2時、ひっそりと静まり返ったオフィス。誰もいないフロアで、一台のPCだけが青白い光を放っています。タスクスケジューラによって自動起動されたExcelマクロ。それは順調に数万件のデータを処理し、集計表を作り上げている……はずでした。

翌朝、意気揚々と出社した私を待っていたのは、完了した集計ファイルではなく、画面中央に居座る小さなダイアログボックスでした。『実行時エラー 1004: ファイルが見つかりません』そしてその下には、冷酷な『OK』ボタン。

このボタンが押されるのを、プログラムは深夜からずっと待ち続けていました。本来なら数分で終わるはずの処理でした。それが、たった一つのエラーメッセージによってせき止められ、何時間も立ち往生していたのです。「なんで止まってるんだよ……」崩れ落ちそうになる膝を必死で支えながら、私は昨晩の自分を呪いました。エラーが起きたら知らせてあげようという、あの愚かな『親切心』。それが自動化という魔法をただの『時限爆弾』に変えていたことに、その時はまだ気づいていませんでした。

自動化のタブー、MsgBoxの弊害

VBAを覚えたての頃、私はエラーが起きるたびにMsgBoxを表示させるコードを書いていました。「エラーを無視して進んじゃったら危ないから、ちゃんと止めて知らせなきゃ」そう思っていたのです。

でも、これが「自動化」においては最大のタブーでした。メッセージボックスは、人間がそこにいてボタンを押すことを前提とした仕組みです。サーバーや無人のPCで動かすバッチ処理には、メッセージボックスは合いません。処理を永遠に停止させる「死の宣告」に他ならないからです。

1. **デッドロックの発生**：誰もいない場所でプログラムが停止し、次のスケジュール処理すら阻害します。2. **原因特定が不可能**：朝起きて画面を見ても「何が起きたか」はわかります。でも「なぜ起きたか」「何件目で起きたか」というプロセスは全く見えません。3. **再現性の欠如**：ダイアログを閉じてしまった瞬間、その時の変数の値はすべて消えます。二度と同じ状況を再現できなくなります。

自由を奪う「OK」ボタンの呪い

「エラーが出たら止まる」のは正しい考え方です。でも「人間の介入を待って止まる」のは、自動化における敗北でしかありません。深夜のオフィスでひとり虚しく『OK』ボタンを表示し続けるPC。それは私たちの『自由な時間』を再びPCの前に縛り付ける呪いでした。

Pythonログの自動化哲学

Pythonを学び始めて最初に驚いたのは、「ログ（記録）」という概念の深さでした。VBAでは「画面にメッセージを出す」のが当たり前でした。Pythonの世界では「ファイルにログを吐き出す」のが標準的な流儀です。この考え方の転換が、私の自動化ライフを根本から変えてくれました。

「プログラムは止めるな。何が起きたかを雄弁に語らせろ」これがPython移行で学んだ最大の設計思想です。

エラーが起きたら、プログラムはそこで死んではいけません。「何時何分、どの処理の、どのデータで、どんなエラーが起きたか」をログファイルに刻み込む。可能であれば次の処理へと静かにバトンを渡す。朝、そのファイルを開くだけで夜の間に起きたことがわかります。いちいちコードを追いかける必要がありません。

エラーログで業務を止めないプロの自動化

例えば、1000件の顧客データを処理している時に、500件目でエラーが起きたとしましょう。VBAのMsgBoxならそこで「完全停止」です。残りの500件は未処理のまま朝を迎えることになります。でも、適切なログ設計がされたPythonは違います。「500件目はエラーだったよ」とログに書き残し、501件目以降を淡々と続行させることが可能です。朝、ログを見て500件目だけをサッと手動で修正すれば、業務は完了。「被害を最小化し、事後報告を完璧にする」。このアプローチこそがプロの自動化だと痛感しました。

ログ出力で得た、精神的余裕と効率

Python移行後、初めてのエラーに遭遇した日のことは忘れられません。出社してPCを開くと、タスクは無事に（エラーを記録した上で）終了していました。恐る恐る `log.txt` を開くと、そこには犯人の名前がはっきりと記されていました。

『202X-XX-XX 02:15:03 ERROR: [商品マスタ未登録] 商品コード: A-999 (45行目)』

以前なら2時間コースでした。「なんで止まったんだ？」と頭を抱え、コードを一から追いかけ、データを一件ずつ確認する「推理」が待っています。でも今は、ログを見るだけで原因が確定します。「あ、マスタに登録し忘れただけか」原因特定までわずか30秒。修正して再実行して、5分後にはすべてが完了していました。

この「精神的な余裕」こそが、ログ出力がもたらした最大の恩恵でした。「何が起きても、ログを見ればわかる」という安心感。それは、暗闇の中を手探りで歩く恐怖から、ライトを持って夜道を歩く安心感へと変わったようなものです。

AIと作る、チームへ届く日本語ログ

Pythonには `logging` という標準ライブラリがありますが、最初は使い方が難しそうに見えて敬遠していました。でも、AIに相談しながら、初心者でも使いやすい「日本語ログ出力テンプレート」を一緒に作り上げました。

工夫したのは、専門用語ではなく「日本語」で状況を出力することです。

logging.error(f"[データ取込失敗] {customer_name} 様の行でエラー： {e}")

このように書いておくと便利です。エンジニアでない同僚もログを見れば「あ、田中さんのデータでエラーが出た」とすぐにわかります。ログは自分のための備忘録ではなく、未来の自分やチームへの「手紙」です。

loggingの基本設定とログ運用

「loggingって難しそう」と思っている方も多いと思います。でも、最低限これだけ書けば動く、というテンプレートがあります。私が実際に使っているのは、たったこれだけの設定です。

import logging

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s [%(levelname)s] %(message)s",
    handlers=[
        logging.FileHandler("app.log", encoding="utf-8"),
        logging.StreamHandler()
    ]
)

ロギング設定と文字化け・サイズ対策

`FileHandler` でファイルへ書き出します。`StreamHandler` でコンソールへの同時出力もできます。`encoding=”utf-8″` を忘れると日本語が文字化けするので要注意です。この5行を書いておくだけです。スクリプト内のどこでも `logging.info(“処理開始”)` や `logging.error(f”エラー: {e}”)` が使えます。

「RotatingFileHandler」も便利です。ログファイルが巨大になりすぎないようサイズ制限をかけられます。本番運用に入ったら `maxBytes=1*1024*1024`（1MB）程度で設定しておくと安心です。

実践！ロギングレベル活用術

Pythonのloggingには5つのレベルがあります。DEBUG / INFO / WARNING / ERROR / CRITICAL の順で重大度が上がります。最初の頃、私は `logging.error()` しか使っていませんでした。実際に運用すると「エラーじゃないけど記録したい」場面が意外と多いことに気づきます。

ログレベルの種類と使い分け

私が現在使っている使い分けはこんな感じです。- `DEBUG`: 開発・デバッグ時のみ使うレベルです。変数の中身の確認など、本番環境では基本オフにします。- `INFO`: 処理の進捗報告。「1000件中 500件処理完了」のような通常の動きを記録します。- `WARNING`: おかしいけど処理は続けられる状態。「金額がマイナスです。念のため確認ください」のようなケースです。- `ERROR`: 処理の一部が失敗した場合。次の件に進んで処理を続けます。- `CRITICAL`: もう続行不可能な致命的エラー。

プログラム全体を停止させる直前に使うレベルです。

本番は `INFO` か `WARNING` に設定しておくのがお勧めです。DEBUGの大量ログに埋もれず、必要な情報だけが残ります。エラー時は `logging.exception(e)` が特に便利です。スタックトレース（どこでエラーが起きたかの詳細）も一緒に記録できます。

ログで築く自動化の透明性と運用

自動化を進めれば進めるほど、私たちは「見えないエラー」への恐怖に直面します。MsgBoxで処理を止めてしまうのは、その恐怖から目を逸らしているだけかもしれません。

プログラムにログを語らせる。自分にしか分からないブラックボックスを解体し、透明なシステムに変える作業でもあります。誰でも状況を把握できるのが最大の利点です。ログがあれば、あなたが不在でも後任の担当者が動けます。ログを見て原因を特定し、対処できるからです。

「何が起きているか分からない」という状態こそが、自動化における最大の恐怖です。沈黙するプログラムは、いつか必ずあなたを裏切ります。でも、ログという名の対話を続けていれば、プログラムはあなたの最高のパートナーになってくれます。

ログで育てる、システム運用の真の喜び

自動化は「作って終わり」ではありません。運用が始まってからが、本当のスタートです。日々のログを眺めてエラーの兆候を察知する。より堅牢なシステムへ育てていく。そのプロセスの中に、プログラミングという道具を使いこなす真の喜びがあります。今ではそう確信しています。

もし今、あなたの手元にあるプログラムが、いまだに「黙って止まる」仕様なら。まずは一行、ファイルに状況を書き出すコードを追加してみてください。その一行がきっと、深夜の残業と朝イチの絶望から救い出す第一歩になります。

関連リンクとチェックリスト

学習サービスとアンケート