🌊

exit code 0を成功判定に使わないジョブ設計 - テスト設計

に公開
AI
Python
automation
testing
tech

exit code 0を成功判定に使わないジョブ設計 - テスト設計

自動処理は、スケジュール登録だけでは安定しません。ラッパーが正常終了しても、業務上の結果は保留・部分完了・公開失敗かもしれません。

この記事では「テスト設計」の観点から、入力、処理、成果物、公開結果を分離する方法を整理します。仕組み全体の理由まで扱います。

基本方針

業務結果はfinal_statusとして構造化し、rcはプロセス分類だけに使います。

プロセスが終了したことと、目的を達成したことは別です。下書き生成、品質検査、外部公開、公開URL確認を個別に記録します。状態を分けることで、翌日の処理が推測ではなく証拠から再開できます。

実装手順

  1. rc=0/1/2と業務状態を分離する
  2. 成功主張には成果物パスを必須にする
  3. 後段ではrcより先にfinal_statusを読む

各工程は、次工程が機械的に判断できるJSONを出力します。自由文ログだけに依存すると、再実行時にどこまで完了したかを人間が推測する必要があります。

result = {"rc": 2, "final_status": "CLEAN_HOLD_NO_CANDIDATE"}
assert result["final_status"] != "SUCCESS"

重要なのはコード量ではなく、入力と結果の契約が固定されている点です。成功だけでなく、候補不足や認証待ちも構造化して残します。

完了条件を4段階に分ける

  1. 生成完了: 本文、メタデータ、出典情報が存在する
  2. 品質完了: 文字数、タグ、コード例、重複検査を通過する
  3. 操作完了: 許可されたrunnerが対象を限定して実行する
  4. 結果完了: 実URLや外部IDを結果ファイルで確認する

途中停止では、最後に通過した段階と次の処理を記録します。最初からやり直さず、正しい地点から再開できます。

よくある失敗

  • 空のrc=0が公開停止を隠す
  • 自由文ログは集計できない
  • 再実行が外部処理を重複させる

再試行回数を増やす前に、どの状態なら再試行可能かを決めます。外部公開直前では、同日公開済みか、タイトルと本文ハッシュが新規か、対象下書きが今回作成されたものかを確認します。

テスト観点

  • 同じ入力を2回処理しても候補が重複しない
  • 公開済みタイトルを候補として選ばない
  • 本文ハッシュ衝突時は別角度へ切り替える
  • 成果物が欠けた場合は成功にしない
  • 外部URLがない場合は公開済みと記録しない
  • 7件の在庫を下回ったら投稿前に補充する

日次処理の具体例

投稿時刻を10時30分とします。2時30分の供給処理では、単にMarkdownファイルを数えるのではなく、source_packet.jsonとcandidate_audit.jsonがそろい、すべての品質チェックが真になっている候補だけを未公開在庫として数えます。在庫が7件未満なら、不足数だけ別の題材・角度を選んでローカル生成します。この段階では外部画面を操作しません。

10時30分の公開処理では、在庫の先頭から1件を選びます。選択後に公開済みタイトルと正規化本文ハッシュをもう一度読み直します。問題がなければ、その候補から1つの下書き要求を作成し、保存結果に含まれるタイトルと下書き状態を確認します。公開要求は、今作成した同じ下書きだけを対象にします。最後に実URLへ到達できたことを結果JSONへ保存して完了です。

画像生成に失敗した場合、本文候補は削除しません。cover_generation_failedとして候補を在庫に残します。認証が切れた場合も、同じ候補を作り直さずauthentication_requiredとして止めます。公開ボタン実行後に確認だけがタイムアウトした場合は、次の処理で外部状態を先に読み、未公開と証明できるまで再クリックしません。

監視する数値

日次監視では次を別々に記録します。

  • 補充前と補充後の未公開候補数
  • 新しく生成した候補数
  • タイトル重複と本文重複で除外した件数
  • 外部操作を開始した件数
  • 実URLを確認できた件数
  • 最後に通過した工程と停止理由

「タスクが起動した回数」だけを成功指標にすると、候補0件のまま毎日正常終了する問題を見逃します。公開URLが必要なレーンでは、実URL確認件数が1になって初めて日次目標達成と判断します。

再起動後の復旧

再起動後は、メモリ上の状態ではなくファイル成果物から再開します。候補監査が完了していれば生成を省略し、下書き保存結果があれば新規下書きを作りません。公開結果に実URLがあれば同日処理を終了します。この順序により、PC再起動やrunner停止があっても、外部操作を重複させずに続行できます。

テストには候補0件、壊れたJSON、残留ロック、公開結果なしも含めます。日次運用で起きやすいのは、例外よりも「処理は終わったが目的物がない」状態だからです。

運用チェックリスト

  • 入力元とSHA-256が記録されている
  • タイトルと本文の重複検査を通過している
  • providerとactionが固定されている
  • 1日あたりの公開上限を超えていない
  • 結果JSONに実URLまたは正確な停止理由がある

この形なら、候補生産と公開を独立させながら在庫数を契約として接続できます。投稿時刻に候補がなければ、供給工程を実行してから再評価します。

関連する実践例はAI Compass Journalの一覧から確認できます。

https://ai-note-homepage.vercel.app/?utm_source=zenn&utm_medium=article&utm_campaign=structured-job-results-testing-e1

Discussion