【要約】コンテンツ生成と公開操作を分離するtrusted runner設計 - 実装手順 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
自動化システムを運用するエンジニアが、タスクの実行成否と、実際の目的達成を混同する問題に直面している。単なるスケジュール実行では、以下の課題が発生する。
- ・下書き作成と外部アカウント操作の区別が曖昧になる。
- ・自由文ログに依存するため、再実行時に完了地点の推測が必要になる。
- ・汎用的な実行環境が、意図しない対象を変更するリスクがある。
- ・事後証拠がないため、公開状況を推測で判断せざるを得ない。
// Approach
設計者は、各工程の成果物を構造化されたJSONとして定義し、状態遷移を明示化する手法を提案した。要求、事前状態、添付、事後状態を検証する「trusted runner」を採用している。
- ・工程の分離: 生成、品質検査、操作、結果確認の4段階に定義する。
- ・JSONによる契約: 各工程が次工程で利用可能な構造化データを出力する。
- ・完了条件の厳格化: 本文の存在、品質検査通過、許可された実行、実URLの確認を分ける。
- ・ファイルベースの復旧: メモリではなく、ファイル成果物から状態を再開する。
// Result
この設計により、運用者は正確な在庫数と公開状況を把握でき、障害時も安全に復旧できる環境が構築される。具体的な改善点は以下の通りである。
- ・冪等性の確保: ハッシュ値や実URLの確認により、重複投稿を防止する。
- ・精緻な在庫管理: 品質チェック済みの候補のみを在庫として正確にカウントする。
- ・高度な観測性: 実URL確認件数などの具体的な指標で、目標達成度を判定できる。
Senior Engineer Insight
> 「処理の終了」と「目的の達成」を分離する視点は、極めて実践的だ。AIエージェント等の非決定的な要素を含む自動化において、この設計は不可欠となる。実装コストは増すが、運用時の「推測による復旧」という最大のリスクを排除できる。スケーラビリティ確保のため、将来的なDB管理への移行も検討すべきだ。