運用ルール（無人時間帯の配信）¶

AWS Lambda + EventBridge ベースの自動配信は 担当者不在でも動く。ただし「動くこと」と「失敗に気付けること」は別。本ページでは無人時間帯の配信に対する運用ルールを定義する。

前提の確認¶

処理	実行ホスト
Webhook 受信	AWS API Gateway HTTP API
dispatch / 配信 / scan	AWS Lambda (Node 20 / arm64)
配信時刻トリガ	AWS EventBridge Scheduler
AI 生成	Claude Platform on AWS (IAM 認証)
通知	CloudWatch Alarms + SNS Topic `automedia-alarms`

spin-dd 側で用意するコンピュータはゼロ。サーバも担当者の PC も不要。詳細は Claude Code ランタイムモデル。

ルール	値
通常配信の許容時刻帯	8:00〜21:00 JST
静粛時間帯	22:00〜翌 8:00 JST（quiet_hours 既定値）
静粛時間帯の起票	dispatcher が警告コメントを返し、配信しない
例外的に深夜配信が必要	`project.yml` の `quiet_hours.enabled: false` で個別解除

失敗を 誰が・どの経路で・いつまでに 気付くかを業務クラス別に定義する。

業務クラス	例	通知先	対応期限
A: 即時対応（重大障害）	トークン失効で全配信停止 / API Gateway 障害	SNS Topic `automedia-alarms` (email: admin@spin-dd.com)	平日業務時間内、休日は翌営業日朝
B: 後追い対応（個別失敗）	単一配信が 422 で失敗	Backlog 課題コメント	翌営業日
C: 情報通知	配信成功 / 配信通数等の集計	Backlog 課題コメント	通知のみ

「即時対応」が真の意味のオンコール（24/365 即時）ではない。spin-dd の現体制では「翌営業日朝までに気付ければ OK」というレベル感。それ以上の SLA が必要なら別途定義。

MVP (Minimum Viable Product) では当番制を敷かない。

理由:

ただし以下のいずれかが満たされたら当番制を導入:

EventBridge Scheduler は 秒精度の at(投稿日時) で動的 schedule を作るため、業務上の遅延は実質ない (実測数秒)。

EventBridge → Lambda invoke 失敗: EventBridge の retry_policy (max 2 retries, max age 1h) で自動リトライ
deliver Lambda 内部失敗 (Claude / LINE / HubSpot): lock を release してリトライ余地を残す。次の scan (rate=1day) で救済 (frontmatter approval=true かつ dispatched コメント無し)
SQS DLQ: deliver が 3 連続失敗 (visibility timeout 905s × 3) で DLQ 入り → CloudWatch Alarm automedia-deliver-dlq-not-empty 発火
人手介入: Backlog コメントで /automedia send template=<id> を入れて再 invoke、もしくは Backlog 課題本文の dispatched コメントを削除して scan の救済を待つ

LINE / HubSpot / Backlog のトークン期限を AWS Secrets Manager の secret tag に expires_at として記載
CloudWatch Custom Metric で期限残日数を計算 → Alarm 発火 (Phase 1c で実装予定)

automedia が完全停止しても、各 SNS のマニュアル運用に戻せる体制を維持:

実装着手前に以下が確定していること: