うんざりする「クリック作業」をPythonで自動化する実践メモ

目次(11 項目)
ノートに「イラっとするクリック集」みたいなのをちょっとだけ作ってます。もし同じことを2回クリックしたなら、もうそれはPythonの自動化候補です。たいていの自動化って、壮大なシステムを作ることが目的じゃないんですよね。退屈な部分を消して、ちゃんとやるべき仕事に戻るためのものです。
じゃあ実践いきましょう。
本当に嫌な、退屈なタスクを選ぶ
まずは「繰り返し発生すること」を起点にします。ファイルのリネーム、ダウンロードの移動、同じメール文面を送る、画像のリサイズ、特定ページのスクレイピング、CSVからレポート生成、ぐちゃぐちゃのフォルダ整理――とにかく「ふぅ…」ってなるやつ。
コードに触る前に、入力と出力を書き出してください。何がトリガー?(フォルダ、タイムスタンプ、URL、スプレッドシート。)その作業は何を生む?(新しいファイル、データセットの更新、通知。)これをチェックリストみたいに説明できるなら、Pythonで大丈夫です。
一発の巨大スクリプトじゃなく、小さく自動化する
最初の頃の最大のミスは、「全部まとめて自動化しよう」としたことです。「ファイルをリネームするやつ」みたいな一点の方が、「全体のパイプライン」よりはるかにデバッグしやすい。
だから私はこう作ります。
- 小さな1作業のための関数を試作する
- 1〜2個の例でテストする
- ちゃんと動き始めたら、その時点から広げる
もしリスクがあることをやっているなら(ファイル削除、データの上書きとか)、安全確認を省かないでください。最初に「ドライラン」モードを入れて、実行する代わりに「何をするはずか」を表示させるのがおすすめです。未来の自分が感謝します。
まずは標準ライブラリを使う(マジで)
Pythonの標準ライブラリにも、役立つ自動化の要素はかなり揃ってます。動き出すだけのために、いきなり大量のパッケージを入れる必要はありません。
自動化スクリプトでよく出てくるモジュールはこんな感じ:
pathlib:ファイル操作(きれいで読みやすい)shutil:ファイルの移動/コピーsubprocess:システムコマンドを呼ぶ必要があるときcsvとjson:データ処理datetime:時間に関するタスクemail:メッセージ送信re:テキストの整形やパターンマッチング
例:パターンに基づいてファイル名を変更(まず表示するので比較的安全):
from pathlib import Path
folder = Path("downloads")
for path in folder.glob("report_*.csv"):
new_name = path.name.replace("report_", "monthly_report_")
print(f"{path.name} -> {new_name}")
# path.rename(folder / new_name) # 自信がついたらコメント解除
このやり方が好きなのは、重要なものに手を出す前に挙動を検証させてくれるからです。
データの雑用なら、CSV/JSONを“主役”として扱う
自動化がスプレッドシートや書き出しデータを扱う系なら、すぐにCSVかJSONにぶつかります。
私はだいたいこんな流れにします:
- データを読み込む
- 必要なクリーニング/変換をする
- 名前のルールが揃った新しいファイルを書き出す
- 信頼できるまで元データは触らない
本気のデータ処理(結合、形の変形、大きめの変換)をやるなら、pandasを使う価値はだいたいあります。魔法ではないけど、手でループを書きまくるのを避けられる。
定期実行なら cron / タスクスケジューラ / シンプルな実行役を選ぶ
作ってる間は、自分で手動実行してもいいです。でも動き出したら、勝手に動いてほしくなりますよね。
環境に合うスケジューラを選びましょう:
- Linux/macOS:cron
- Windows:タスク スケジューラ
- どちらでも:スクリプトを定期実行するジョブ(本当に単純なら小さいループでもOK)
典型的なcron(毎日7:30に実行):
30 7 * * * /usr/bin/python3 /path/to/automation.py
Windowsなら、タスクスケジューラでpython.exeにスクリプトのパスを渡して実行できます。実行ユーザーがログインしている/いないに関わらず動かす設定も可能です。やりたいことに合わせて決めてください。
ログこそが「動いた」から「信頼できる」に変える
ちょっとしたリネームスクリプト以上の自動化をするなら、ログは必須です。見ていない間に何が起きたのか分かるようにしたい。
まずはPythonの標準のloggingから:
import logging
logging.basicConfig(
filename="automation.log",
level=logging.INFO,
format="%(asctime)s %(levelname)s %(message)s"
)
logging.info("Run started")
# do work...
logging.info("Run finished")
もっと本格的になったら、件数(処理したファイル数、更新した行数)をログに出し、失敗については原因をすぐ直せるくらいの文脈と一緒に記録しましょう。
外部連携の自動化:API、Webリクエスト、Webhooks
タスクがローカル完結じゃないこともあります。アプリ同士のワークフローをまたぐケースですね。Pythonはこういうのもできます。
REST APIに話しかけたり、Webリクエストでアクションを起動したりするなら、たぶんrequestsやhttpxを使うことになります。「一回動いた」から「毎日確実に動く」への最大の違いは、失敗の扱いです。タイムアウト、リトライ、想定外のレスポンス、レート制限。
やり過ぎた設計(過剰な作り込み)までは不要だけど、現実は想定しておく必要があります。
読めるようにしておく。あとで自分が面倒を見る
自動化スクリプトは「賢そう」とか「センスが良い」とか褒められません。使われる、いじられる、そして11:47pmに何かが壊れた時にデバッグされます。
私は次の点を最適化します:
- 分かりやすい変数名
- 小さな関数
- 出力ファイル名の一貫性
- 誰かが迷わないためのコメントだけ(無駄に増やさない)
後で変えます。約束してないならなおさら。
よくある自動化の落とし穴(身をもって学んだやつ)
物事がこじれやすいポイントはいくつかあります:
- 入力形式がずっと同じだと思い込むこと。少し違う名前や構造でファイルが来たら、スクリプト側はうまく受け流すか、はっきり失敗すべきです。
- バックアップなしで上書きすること。データ変換では、基本は新しい出力ファイルに書き出してください。
- APIを呼んで「失敗しないはず」と思うこと。常に動く前提でごまかすより、エラーを扱いましょう。
- どんな検証もスキップすること。行数、必須カラム、ファイルの存在チェックみたいな簡単なものでも、数時間の後片付けを救ってくれます。
実際に使う“小さな”プロジェクトから始める
始めやすい場所としては、次のどれかを選んで最後まで動く形にしてみてください:
- フォルダを監視して、新しいファイルを日付/種類で整理されたサブフォルダに移動する
- CSVを受け取って、列をクリーニング(前後の空白を除く、見出しを標準化など)して、きれいなCSVとして書き出す
- 毎日のレポートを生成(CSVかAPIから)して、自分にメールする
どれか1個を選び、5個の例で動くようにしてからスケジュールして、触るのをやめましょう。
知識を確認する(インタラクティブクイズ)
Free In-Browser Developer Tools
Clean AI CLI logs, build cron expressions, decode JWTs, and calculate chmod permissions offline.
Related Articles

FastAPI 対 Litestar: 本番環境ベンチマークと高スループットマイクロサービスアーキテクチャ
FastAPIとLitestarの客観的かつベンチマークに基づいた比較。ASGIのパフォーマンス、依存性注入アーキテクチャ、シリアライゼーション速度、OpenAPIの型定義について掘り下げます。
Read more
PolarsとPandas:パフォーマンスとメモリのベンチマーク
PolarsとPandasのメモリ使用量、Apache Arrow統合、遅延クエリ最適化、マルチコアCPUスケーリングに関する包括的なベンチマーク。
Read more
実践ML評価: 精度、再現率、AUCで正確性を超える
不均衡データに対するaccuracyの使用をやめ、Precision-Recallトレードオフ、F-betaスコア、ROC-AUC対PR-AUC、確率キャリブレーション(BrierスコアとPlattスケーリング)、閾値調整を習得しましょう。
Read more