コンテンツワークフロー¶

Backlog 課題のライフサイクルとして定義する。実行系は Claude Code ランタイムモデル Phase 1b に従い、AWS Lambda（Claude Agent SDK + Claude Platform on AWS）で配信が動く。承認と責務境界はコントロールプレーンと責務分担を参照。

ワークフロー図¶

flowchart LR
    A[起票<br/>既存 status] --> B[内容編集<br/>処理中 等]
    B --> C{人手で<br/>status 変更<br/>= 承認}
    C -->|承認| D[automedia承認<br/>EventBridge<br/>Schedule 登録]
    C -->|差し戻し| B
    D --> E[配信実行<br/>Deliver Lambda]
    E -->|成功| F[automedia実行済み<br/>+ 結果コメント]
    E -->|失敗 / 要追加指示| G[automediaエラー<br/>+ 失敗コメント]
    G -->|課題修正| C
    F --> H[効果測定追記]

Status 設計 (Phase 1b)¶

TTRTAGSPIN プロジェクトに 3 つの新規 status を追加 (詳細は 08-control-plane.md):

Status	意味	遷移元	遷移先
`automedia承認`	承認済み、automedia による処理待ち	既存 status (処理中等) からの人手遷移	`automedia実行済み` (成功) / `automediaエラー` (失敗)
`automedia実行済み`	配信成功 (terminal)	`automedia承認` (automedia 自動遷移)	(terminal)
`automediaエラー`	配信失敗 / 要追加指示 (要人手介入)	`automedia承認` (automedia 自動遷移)	`automedia承認` (修正後の再承認)

Backlog 課題テンプレ（提案）¶

[件名] {{chsymbol}} {{summary}}

## 配信メタ
- チャネル: {LINE|TikTok|Instagram|HubSpot}
- 投稿日時: 2026-05-15 10:00 (JST)
- 対象タグ: tag:active, !tag:opt_out
- テンプレ: announce_open@<commit>

## 文面 / 変数
- date: 2026-05-15
- hours: 7:00-18:00

## 添付
- 画像: rich_menu_2026Q2.png
- 動画: なし

## 補足
- 雨天時の変更は別課題で

提案: issueType を 「コンテンツ運用」 として新設し、課題テンプレを Backlog 側に登録する。

起票 → 配信各段階の責務¶

段階	主アクター	Backlog status	システム動作
起票	メディア運営者 (spin-dd 運営担当)	未対応 / 処理中等 (既存)	Backlog 課題作成
内容編集	メディア運営者 (spin-dd 運営担当)	処理中 (既存)	テーマリポで Claude Code セッションを使い、`automedia preview` で確認 (read 系 endpoint)
承認	メディア運営者 (spin-dd 運営担当)	→ `automedia承認`	人手で status 変更 = 承認の意思表示 (変更者は Backlog 履歴に残る)
配信予約登録	システム (`webhook-backlog` Lambda)	`automedia承認`	Backlog Webhook 受信 → EventBridge Schedule `at(max(投稿日時, now+5s))` を登録 (即時送信も予約も常に Schedule 経由で経路統一)
配信実行	システム (`deliver` Lambda)	`automedia承認`	Claude Agent SDK + Claude Platform on AWS → 外部 API (LINE / HubSpot 等)
結果コメント	システム (`deliver` Lambda)	→ `automedia実行済み`	Backlog にコメント `[automedia] dispatched at <iso>` + カスタムフィールド「自動配信実行日時」更新
失敗ハンドリング	システム (`deliver` Lambda)	→ `automediaエラー`	リトライを使い切ったら遷移、Backlog にコメント `[automedia] failed: <reason>`
効果測定追記	システム	(terminal)	クリック・既読集計を後追いで追記
アラート	システム	(任意)	CloudWatch Alarm で `automediaエラー` 件数や Lambda Errors を監視

配信トリガの主経路は Backlog Webhook → webhook-backlog Lambda (秒精度)。Scan Lambda (rate(1 day)) は Webhook 取りこぼし時の日次セーフティネット で、通常運用では検知件数 0。詳細は Webhook 受信と Claude Code ランタイムモデルを参照。

失敗時のリトライ規則¶

deliver Lambda の内部で外部 API 呼び出し失敗時に適用。自動 retry を使い切った時点で automediaエラー に遷移 する。

失敗種別	自動 retry	終端動作
5xx / Timeout	指数バックオフ (30s, 2m, 10m, 30m, 1h) 最大 5 回	リトライ尽き → `automediaエラー`
認証失敗 (401 / 403)	なし (token 更新が必要)	即時 `automediaエラー` + token 期限切れ通知
422 (ペイロード不正)	なし	即時 `automediaエラー` + Backlog コメントに理由
その他 (4xx)	なし	即時 `automediaエラー`

automediaエラー 状態の課題は、人手で内容を修正してから automedia承認 に戻して再実行する。現状は自動 retry のみで、automediaエラー 後の自動再実行は行わない (人手介入を前提とする設計、Issue #104 確定事項)。

取り消し / 修正¶

ライフサイクル上の代表的なケース:

ケース	仕組み
配信予約 (`automedia承認`) を取り消す	status を `automedia承認` から戻す → `webhook-backlog` Lambda が `IssueUpdated` を検知して EventBridge Schedule を削除
配信予約後に内容を編集 (invalidate)	`automedia承認` 状態の課題本文 / 投稿日時 / テンプレ参照が変更されたら、Lambda が自動で status を 1 つ戻す＋ Schedule 削除。再承認で再登録
配信実行中の取り消し	原則不可 (LINE / HubSpot 等の外部送信が始まったら戻せない)。途中失敗で `automediaエラー` に遷移するのみ
`automediaエラー` からの復帰	課題を修正 → status を `automedia承認` に戻して再実行

invalidate の判定ルール (本文・投稿日時・テンプレ参照変更で status 戻し) の詳細は 08-control-plane.md の Invalidate ルールを参照。

invalidate 時の revert 先 status¶

invalidate 発火時に課題が戻る先の status は、デフォルトでは Backlog 標準の 処理中 (statusId=2) を fetchProjectStatuses で動的解決する。プロジェクトに 処理中 が無い (delete された / 別名にした) 場合は webhook-backlog Lambda の env で上書き可能:

環境変数	用途
`INVALIDATE_REVERT_STATUS_NAME`	動的解決のターゲット名 (例: 英語環境の `In Progress` / 顧客社固有 `審査中`)
`INVALIDATE_REVERT_STATUS_ID`	NAME 解決失敗時の fallback statusId (NAME 未設定なら直接この id を使う legacy 経路)

優先順位:

NAME 設定時 → fetchProjectStatuses で動的解決、ID は fallback に格下げ
ID のみ設定 → 動的解決スキップ、ID を直接使う (legacy override)
両方未設定 → デフォルト 処理中 を動的解決