わたしは、予約したはずの投稿が動いていなかった、という失敗を何度かやっている。
予約実行は「実行される日まで、成功も失敗も分からない」のがいちばん厄介なところだった。
なので今回は、予定日を待たずに本番とまったく同じ経路でDryRun（空打ち）するやり方に切り替えた。その検証ログを残しておく。
検証したもの：タスクスケジューラの予約実行3件
対象はWindowsのタスクスケジューラに登録してある予約タスク3件。
| # | 内容 | 実行までの間隔 |
|---|---|---|
| A | SNS投稿の予約 | 数日後 |
| B | SNS投稿の予約 | 数日後 |
| C | 記事公開の予約 | 十数日後 |
（実行日は伏せている。予約そのものが動くかどうかの検証なので、暦日は本題ではない）
DryRunの結果は3件すべて合格。ただし、合格させるまでに3か所直している。そこが本題になる。
DryRun（空打ち）の考え方：本番と同じ経路を通す
DryRunと言っても、スクリプトの中身を目視で読み返すだけなら意味がないと思っている。実際にやったのは次の形だった。
- タスクスケジューラから手動で即時実行する（テスト用に別のコマンドを叩くのではなく、登録済みのタスクそのものを走らせる）
- スクリプトにはDryRunフラグを渡し、最後の「送信」「公開」だけを止める
- そこに至るまでの認証・下書きの読み出し・投稿先の解決・ログ出力は、本番と完全に同じ処理を通す
- 実行はタスクスケジューラ経由の非表示ウィンドウで行う（手元のターミナルから叩くと環境が違ってしまう）
Instagram側は、送信直前まで組み立てた内容を照合するところまで入れた。
- 投稿予定のキャプションが、下書きの内容と文字列として一致しているか
- 投稿先アカウントの表示名が意図したものか（アカウントを取り違えていないか）
この2つを通したことで、「動くかどうか」だけでなく「正しい宛先に、正しい文面が出るか」まで当日前に確認できた。
見つかって直した3件
1. WakeToRun（スリープ解除して実行）が無効だった
予約タスクの設定で「タスクの実行時にスリープを解除する」が無効のままだった。
この状態だと、予定時刻にPCがスリープに入っていた場合、タスクは起動せず、復帰後も実行されない（設定によっては遅れて走るが、投稿系では遅延自体が問題になる）。有効化した。
DryRunでは実行そのものは成功してしまうので、ここは設定値の確認でしか見つからない部分だった。実行テストと設定監査は別物だと考えている。
2. 無人実行（非表示ウィンドウ）でログの日本語が文字化けした
手元のターミナルから叩くと正常なのに、タスクスケジューラ経由の非表示実行だとログファイルの日本語が化ける、という症状が出た。
原因は出力時のエンコーディングが実行環境によって変わっていたこと。スクリプト側で出力エンコーディングを明示するように直した。
これは「壊れていない不具合」なので放置もできたが、当日に失敗したときに読むのがそのログだけなので、化けていると原因究明ができない。先に直した。
3. 予約公開スクリプトがドライブ文字でプロジェクトの場所を固定参照していた
いちばん危なかったのがこれ。スクリプト内でプロジェクトのルートを D:\work\project のようなドライブ文字込みの絶対パスで書いていた。
ドライブ文字は環境やマウント順で変わりうるので、変わった瞬間に予約当日だけ失敗する。スクリプト自身の位置から相対的にルートを算出する形に変更した。
下に書くパスは説明のための架空のもので、わたしの実際の置き場所とは関係がない。変更の向きだけ見てほしい。
# 変更前：固定参照
$Root = "D:\work\project"
# 変更後：スクリプト自身の位置から算出
$Root = Split-Path -Parent $PSScriptRoot予約登録を手作業でやらないためにツールを3本作った
同じ確認を毎回手で回すと、そのうちやらなくなる。なので次の3本を作った。
1. note記事の予約登録ツール — タスク登録とDryRunまでを一度に行う。公開先マガジンの指定は、名前の思い込みで書くと静かに外れるので、APIで完全一致を確認してから登録する
2. 本文の目印を画像に差し替えるツール — 原稿中のプレースホルダを画像に置換する
3. 見出し画像を設定するツール
1番のツールは「登録したら必ずDryRunが走る」構造にした。検証を人間の意志に任せない形にしたかった。
わたしが使ったチェック観点
同じことを確認するときに見た項目を、そのまま並べておく。
- 登録済みのタスクそのものを手動実行しているか（別コマンドで代用していないか）
- DryRunで止めているのは最後の送信だけか（途中の処理まで飛ばしていないか）
- 非表示ウィンドウ（無人と同じ条件）で実行したか
- 実行ユーザー・作業ディレクトリが、手元で叩いたときと同じか
- WakeToRun／「電源に接続している場合のみ」等の設定値を目で見たか
- ログに日本語が正しく出ているか
- 投稿先（アカウント・マガジン）を、名前の思い込みではなくAPIの応答で確認したか
- パスがドライブ文字や特定環境に依存していないか
残っている未確認のこと
- 予定時刻にPCがスリープしていた実環境での復帰実行は、未確認。WakeToRunを有効化しただけで、実際にスリープ状態から起きて走るところまでは見ていない
- ログオフ状態での実行も未確認
- 当日に本当に投稿されたかどうかは、実行後にログを見て確認する
予約系の失敗は、だいたい「予約したつもり」で終わっている。同じ系列の失敗の経緯は別途まとめている。
次は、DryRunの結果を実行ログに自動で残して、合格していない予約タスクがあれば朝に気づける形にしたい。
関連する記録
予約実行の結果が「成功」でも実際の処理が動いていなかった経緯は、自動タスクが1週間「成功」と報告しながら何もしていなかった記録にまとめました。
実行を任せるAIへの指示を短く整理した過程は、CLAUDE.mdを7万字から5千字にした手順に書いています。
コメント