【要約】コンテンツ生成と公開操作を分離するtrusted runner設計 - テスト設計 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
自動化エンジニアは、スケジュール実行のみに頼ることで、処理の完了と目的の達成が乖離する問題に直面する。単にプログラムが終了しただけでは、意図した成果物が正しく公開されたか保証できないためだ。具体的には以下の課題が生じる。
- ・UIの直接操作による、設定したポリシー検査の迂回。
- ・汎用的な実行主体（runner）が、意図しない別対象を変更してしまうリスク。
- ・事後的な証拠がないため、公開が成功したかを推測で判断せざるを得ない状況。
- ・例外発生時に、どこまで完了したかを人間が判断しなければならない不透明さ。
// Approach
開発者は、生成工程と公開工程を分離し、中間状態を構造化データで管理する設計を採用する。各工程の入出力を厳格な契約として定義し、機械的な判断を可能にする手法だ。具体的なステップは以下の通りである。
- ・工程を「生成」「品質」「操作」「結果」の4段階に定義し、完了条件を明確化する。
- ・各工程の成果物をJSON形式で出力し、次工程が機械的に判断できる状態を作る。
- ・再起動時はメモリ上の状態ではなく、source_packet.json等のファイルから状態を復元する。
- ・公開要求は、直前に作成した特定の下書きのみを対象とするよう範囲を限定する。
// Result
この設計により、運用者は再起動やエラー発生時でも、外部操作の重複を避けつつ確実に業務を継続できる。不完全な状態での再試行を防ぎ、実効的な目標達成を可視化できる。具体的な成果は以下の通りである。
- ・中断・再起動時でも、正しい地点から処理を再開できるレジリエンスの確保。
- ・「実URLの確認件数」を指標とすることで、実効的な目標達成度の正確な把握。
- ・画像生成失敗や認証切れなどの例外状態を、構造化された理由として記録・管理可能。
Senior Engineer Insight
> 非常に実践的な設計思想である。単なる「スクリプト」を「システム」へと昇華させるための要諦が詰まっている。特に「完了」の定義を多層化し、副作用を伴う操作を分離する点は、分散システムやAIエージェント運用において必須の知見だ。実装コストは増大するが、障害復旧コストと、不完全な自動化による事故リスクを劇的に下げられるため、ミッションクリティカルな自動化には不可欠なアプローチである。