コンテンツにスキップ

Backlog 連携

立ち位置

Backlog は メディア運営者 (spin-dd 運営担当) の UI であり、ContentTask の起票・承認・履歴閲覧の窓口。さらに 業務 SoT (承認・監査・タスクキュー) として、automedia への write 操作 (配信実行) を承認経由で統制する役割を担う (コントロールプレーンと責務分担)。

採用：TTRTAGSPIN 共用 + ウォッチ対象 Backlog の設定

8 サイト分のコンテンツ運用課題は TTRTAGSPIN プロジェクトを共用する。 顧客サイトごとに別プロジェクトを作らない。ただし「顧客承認フローを Backlog に乗せたい」等の理由で 必要なサイトだけ別 Backlog プロジェクトに切り出す ことができるよう、automedia は ウォッチ対象 Backlog プロジェクトのリスト を config として持つ（詳細）。

根拠

  • TTRTAGSPIN は既に spin-dd 運用代行業務のハブ。Wiki も同居
  • 既にサイト別 category が運用されている（馬頭 / おかだ / ラテール / いちの / 採用 / TACウェブサイト）
  • 顧客社への課題公開は要件外（spin-dd 社内運用が前提）
  • Webhook 設定が 1 箇所で済む
  • 新規サイト立ち上げ時に Backlog プロジェクトを作らずに済む

既存資産

調査結果（時点: 2026-05-11）:

項目 状態
issueType タスク / バグ / 要望 / その他（標準のみ）
category いちの / ラテール / 採用 / TACウェブサイト / おかだ / 馬頭 が登録済み
customField 未登録
status 未対応 / 処理中 / 処理済み / 完了（標準ワークフロー）+ 追加で automedia承認 / automedia実行済み / automediaエラー (Issue #104 確定)
既存課題 約 61 件（運用代行全般のタスク）

TTRTAGSPIN に必要な追加設定

automedia 運用開始前に以下を Backlog 管理者で設定する。

1. category 追加

不足分:

  • 太平エンジニアリング
  • 太平人事（既存「採用」と統合するか別立てかは要合意）
  • SPIN

既存 馬頭 → bato、おかだ → okada、いちの → ichino、ラテール → laterre、採用 → recruit、TACウェブサイト → tac にマップ。

2. issueType 追加

issueType 用途
コンテンツ運用 automedia 配信対象の課題

既存 タスク を流用すると、汎用タスクと配信課題が混ざる。新設を推奨。

3. カスタムフィールド追加

名前 型 必須 用途
投稿日時 日時 ◯ scheduled_at。dispatcher が「≤ now()」を走査
チャネル リスト（複数選択可） ◯ LINE / TikTok / Instagram / HubSpot
対象タグ テキスト（カンマ区切り） narrowcast のターゲティング指定
テンプレID テキスト .automedia/templates/<channel>/<id>.yml 解決元
自動配信実行日時 日時 システム dispatcher が書き込み。二重 dispatch 防止
配信結果サマリ テキスト（複数行） システム 配信後のレポートが入る

「自動配信実行日時」「配信結果サマリ」は人手では基本書かない。スキル/スクリプトが書き込み。

4. issueType=コンテンツ運用 のワークフロー

automedia は 既存 status (標準ワークフロー) に 3 つの新規 status を追加 する形で承認フローを実装する (Issue #104 確定):

status 意味 区分
未対応 draft（起票直後） 既存
処理中 review（メディア運営者が文面整備中） 既存
処理済み （automedia の trigger には使わない、社内タスク完了用に温存） 既存
完了 delivered（最終クローズ用） 既存
automedia承認 承認済 → automedia 処理待ち。webhook-backlog Lambda が拾う 新規 (Phase 1b)
automedia実行済み 配信成功 (terminal) 新規 (Phase 1b)
automediaエラー 配信失敗 / 要追加指示。修正後 automedia承認 に戻して再実行 新規 (Phase 1b)

承認＝配信対象 のセマンティクスは automedia承認 に統一。処理済み には載せない (社内タスクの「処理完了」と混同しないため)。

ライフサイクル: 未対応 → 処理中 → automedia承認 → (automedia 配信実行) → automedia実行済み (成功) / automediaエラー (失敗)

マッピング規約

Backlog automedia
TTRTAGSPIN プロジェクト automedia の全テナントの共通起票場所
課題 issueKey（例 TTRTAGSPIN-123） ContentTask の識別子
category 名 サイト識別子（例: 「馬頭」→ bato）
issueType=コンテンツ運用 フィルタ条件
customField「投稿日時」 scheduled_at
customField「チャネル」 配信チャネル
status=automedia承認 配信対象（webhook-backlog Lambda の検証条件、automedia承認 未満は 400 拒否）
status=automedia実行済み 配信成功 (terminal、automedia が自動遷移)
status=automediaエラー 配信失敗 / 要追加指示 (automedia が自動遷移、修正後 automedia承認 に戻して再実行)
課題コメント（人手） manual トリガー or 修正指示
課題コメント（システム） 配信結果 / エラー通知

ウォッチ対象 Backlog プロジェクト

automedia の dispatcher は 「ウォッチ対象 Backlog プロジェクト」のリスト を走査して issueType=コンテンツ運用 の課題を抽出する。MVP (Minimum Viable Product) では TTRTAGSPIN 1 件のみだが、将来 1 サイト = 1 Backlog プロジェクトに切り出す場合はこのリストに追加するだけで対応できる。

設計原則

  • デフォルトは TTRTAGSPIN 1 つ（共用モデル）
  • サイト単位で別プロジェクトに切り出せる（顧客協調が必要になったサイトのみ）
  • dispatcher は全ウォッチ対象を合算走査（プロジェクトが増えても他サイトに影響しない）
  • サイト識別ロジックはプロジェクト別に切り替え:
  • 共用プロジェクト（TTRTAGSPIN）: 課題の category でサイト識別
  • 専用プロジェクト（例 BATO）: プロジェクトキーそのものでサイト識別

サイト解決マップ

automedia リポ（本リポ）に台帳ファイルを置き、dispatcher が参照する:

# config/sites.yml

# ウォッチ対象 Backlog プロジェクト（dispatcher が走査するプロジェクトのリスト）
backlog:
  watched_projects:
    - key: TTRTAGSPIN
      mode: shared           # 課題の category でサイト識別
    # 将来、顧客協調が必要になったサイトを切り出す場合の例:
    # - key: BATO
    #   mode: dedicated       # プロジェクトキー = サイト識別子
    #   site: bato

# サイト台帳
sites:
  - key: bato
    backlog:
      project: TTRTAGSPIN     # 所属プロジェクト
      category: 馬頭          # shared プロジェクト内での識別子
    repo: spin-dd/bato-hubspot-theme
  - key: okada
    backlog: { project: TTRTAGSPIN, category: おかだ }
    repo: spin-dd/okada-hubspot-theme
  - key: laterre
    backlog: { project: TTRTAGSPIN, category: ラテール }
    repo: spin-dd/laterre-hubspot-theme
  - key: ichino
    backlog: { project: TTRTAGSPIN, category: いちの }
    repo: spin-dd/ichino-hubspot-theme
  - key: taihei
    backlog: { project: TTRTAGSPIN, category: 太平エンジニアリング }
    repo: spin-dd/taihei-hubspot-theme
  - key: recruit
    backlog: { project: TTRTAGSPIN, category: 採用 }   # or 太平人事
    repo: spin-dd/recruit-hubspot-theme
  - key: tac
    backlog: { project: TTRTAGSPIN, category: TACウェブサイト }
    repo: spin-dd/tac-hubspot-theme
  - key: spindd
    backlog: { project: TTRTAGSPIN, category: SPIN }
    repo: spin-dd/spindd-hubspot-theme

dispatcher の識別ロジック:

  1. backlog.watched_projects の各プロジェクトに対し、issueType=コンテンツ運用 かつ status=automedia承認 の課題を取得 (scan Lambda の漏れ救済用クエリ条件)
  2. プロジェクトの mode に応じてサイトを特定:
  3. shared → 課題の category（複数あれば最初）でサイト識別。マッチしない category は無視
  4. dedicated → watched_projects[].site でサイト固定
  5. 解決できなければスキップ（automedia 対象外として扱う）

取り込み方式

Backlog Webhook → API Gateway → webhook-backlog Lambda の構成。詳細は Webhook 受信 と トリガー・スケジューラ を参照。

  • 課題追加 / 更新 → status が automedia承認 か検証 → EventBridge Schedule at(max(投稿日時, now+5s)) を upsert (即時送信も予約送信も常に Schedule 経由で経路統一)
  • 投稿日時に到達 → deliver Lambda が発火 → Claude Platform on AWS で content 生成 → LINE / HubSpot へ配信
  • deliver Lambda は完了時に status を automedia実行済み / automediaエラー に更新
  • 取りこぼし救済として scan Lambda (rate(1 day)) が automedia承認 状態のまま「自動配信実行日時」が空の課題を救済 invoke

コマンドコメント（manual トリガー）

/automedia send             # 即時配信（投稿日時を待たない）
/automedia preview          # プレビューを返信 (Phase 1c で実装)
/automedia cancel           # EventBridge Schedule 削除
/automedia status           # 現状を返信

webhook-backlog Lambda が IssueCommented event を受けて parse する。

顧客社への課題公開（現状は不要）

基本方針: コンテンツ運用は spin-dd 単独で行う。顧客社の人を Backlog に巻き込まない。

これは TTRTAGSPIN 共用を選んだ前提条件であり、現状のスコープでは何の問題もない。

将来の進化パス（必要になった時）

特定の顧客サイトで「顧客承認フローを Backlog に乗せたい」となった場合は、そのサイトだけ専用 Backlog プロジェクトに切り出すことができる。共用モデルを全廃する必要はない。

切り出し手順（例: bato が顧客協調モードになる場合）:

  1. 新規 Backlog プロジェクト BATO（仮）を作成
  2. issueType / customField を TTRTAGSPIN と同等に設定（テンプレ化しておくと楽）。category は専用プロジェクトでは不要
  3. automedia リポ config/sites.yml を更新:
  4. backlog.watched_projects に { key: BATO, mode: dedicated, site: bato } を追加
  5. sites[].key=bato の backlog を { project: BATO } に変更
  6. 顧客社ユーザーを新プロジェクトに招待
  7. 既存の TTRTAGSPIN-XXX 課題は履歴として残し、新規分は BATO-XX で運用

dispatcher は watched_projects を順に走査するだけなので、他のサイト（共用継続）への影響はない。

中間案（軽量）

「課題を見せる」までは要らないが「承認だけ顧客に通したい」場合:

  • Slack / メールでプレビュー URL を送って承認受領
  • automedia リポ側の仕組みがその承認を受けて Backlog 課題を automedia承認 に遷移

これも共用モデルのまま実現可能。

失敗時の動き

  • webhook-backlog Lambda が EventBridge upsert に失敗 → CloudWatch Logs にエラー、scan が翌日救済
  • deliver Lambda 内部失敗 → lock release で再 invoke 可、[automedia] dispatched コメント未付与 → scan が救済
  • SQS DLQ 入り → automedia-deliver-dlq-not-empty Alarm 発火 → SNS で運用者に通知

TTRTAGSPIN 共用にしたデメリットの緩和策

デメリット 緩和策
通知が他の運用業務と混ざる category や issueType 別に通知設定を分ける
既存タスクと一覧上で混在 issueType=コンテンツ運用 で常時フィルタ
顧客社の人を呼ぶときに他サイトが見える 招待しない / 別ルートで承認