これはエイプリルナイツアドベントカレンダー2025の16日目の記事です

初めに

今年はPythonのバッチ開発等を中心にgithub copilotを利用した業務を多く経験できて、リーダーとの会話でも「とりあえずcopilotに聞いてみましょうか？」等のワードが増えてきたので、少しづつでも現場にAI利用が浸透し始めているのかな？と感じるこの頃です。
今までの業務経歴でもPythonを使った開発はあまり経験が無かったのですが、他の言語の知識とcopilotへの質問やagentの活用で十分開発ができる為、とても強力なツールだと感じています。
copilotのサブスク料金を承認してくれた上司の方とGitHub社には一生頭が上がらなそうです。

本題

皆さんはPythonでバッチ処理を開発する際にプログラム終了時、エラー発生時の処理をどのように組んでいるでしょうか？
バッチに限らずプログラムでエラーが発生した際の切り戻し処理は重要な処理として考えることになりますし、単純なログ出力からプログラムが更新した個所のロールバックまで必要な処理が多岐にわたるケースもあり、確実に実行されることを要求されます。
また、バッチ処理で一時的にローカルに対して変更加えるケース(一時フォルダの作成,環境変数の一時的な変更,プロキシ等のネットワーク設定の一時変更,etc....)ではプログラムが正常終了した際の戻し作業が確実に実行されることが要求されます。
私も実際にPythonのバッチ処理を開発する際に上記のような課題がありcopilotに質問したところ、下記の機能を提案してくれて「Pythonってスゲー！！！」と一人関心しました。

atexitハンドラー

atexitモジュールをインポートしてatexit.registerメソッドを使用することで、プログラムが終了した際に確実に実行されるクリーンアップ関数を登録することができます。

atexit_sample.py

import atexit

#クリーンアップ処理の定義
def cleanup():
  #プログラム終了時に実行したい処理

#registerメソッドを使ってクリーンアップ処理を登録
atexit.register(cleanup)

これによって、プログラムが正常終了した際に確実にクリーンアップ処理が実行されます。
また、main関数で適切にtry-catchを使用しておけば、catch句でエラーログの出力等を行った後でsys.exit(1)でプログラムを終了したあとにクリーンアップ処理が実行されます。
この書き方のありがたいところはmain関数内にクリーンアップ処理の記述をしなくて済むのでmain関数の見通しが良くなりますし、クリーンアップに特化したクラスを定義してメイン関数が肥大化するのを防止することができるところでしょうか。
Python以外の言語で昔にバッチ処理のソースコードを見た際に肥大化した後処理がmain関数内に罹れていてどこからが後処理なのか困惑したことがあるので、この書き方はありがたく見えます。

シグナルハンドラー

signalモジュールをインポートしてsignal.signalメソッドを使用することで、プログラム実行中に特定のシグナル(例えばCtrl+Cによるプログラムの中断等)を受け取った際の処理を登録することができます。

signal_sample.py

import signal
import os

#クリーンアップ処理の定義
def cleanup():
  #プログラム終了時に実行したい処理

#signalメソッドを使ってCtrl+Cのシグナルを受け取った時のクリーンアップ処理を登録
signal.signal(signal.SIGINT,cleanup)

実際にユーザにツールを配布して使ってもらう際にユーザ側でCtrl+Cによる中断をされると問い合わせの際に現在のユーザの状況が分からず対応の際にコミュニケーションが必要になりますが、Zoomで通話を繋いで対応できるケースばかりではないので、この手のクリーンアップ処理を登録しておける仕組みは社内ユーザにちょっとしたツールを配布したりする際に便利に思えます。

まとめ

Pythonでバッチ開発をする際のクリーンアップ処理については上記2つの方法が効果的でコストも少なく実装できるので、copilotの提案見たときに関心しました。
SnowflakeでデータのUpsert処理をするために一時テーブルへデータ入れてからMERGEクエリを発行している処理とかも一時テーブルのTRUNCATE処理を上記のクリーンアップ処理の要領で発行するようにすれば今まで作ったPythonバッチの可読性を上げられそうだし、Python開発のTIPSや標準としてチーム内に展開しても良さそう。
そして、公式ドキュメントを読み込まなくてもこれらのモジュールの存在を教えてくれるcopilotに感謝。
今後の開発でも課題をcopilotに聞いてからピックアップしてもらった解決策について自分でドキュメントを読み込んでいく流れが増えるだろうし、copilotに相談する癖を定着させていきたい。