メディア運営者 ハンドブック¶
対象読者: メディア運営者 (spin-dd 運営担当)。automedia を日常的に使う際に「いま自分が何をすればいいか」を 1 ページで通読できるハンドブック。各論は専門ページへリンク。
あなたの作業ライフサイクル¶
- §1 → §2 → §3 は初回 1 回通る直線フロー
- §2 ↔ §3 が日常運用のループ
- §4 (チャネル追加) と §5 (テナント切替) は必要なときだけ
- §6 / §7 は随時参照
1. 利用開始 (初回 1 回だけ)¶
担当テナントを受け持ったら、最初の 1 回だけ実施します。すべて 運営者の作業 PC ローカル で完了する操作です。
1-1. 管理者から受領するもの¶
- 「bootstrap 完了」の連絡
- automedia オンボーディング招待メール (件名
[automedia] <tenant> の運営者オンボーディングご案内、noreply@automedia.spin-dd.comから届く) — 本文に初期パスワード設定手順 +~/.aws/config用 snippet が含まれる - 担当テナント名 (例:
bato) - テーマリポの clone 用 URL (
spin-dd/<tenant>-hubspot-theme)
1-2. 初期パスワード + MFA を登録 (初回 1 回 / #188)¶
ご自身の AWS Identity Center アカウントは管理者が API 経由で作成しています。初期パスワードは 未設定なので、以下の手順で password + MFA を登録してください。
- ブラウザで SSO start URL を開く (招待メール本文に記載、例:
https://d-xxxxxxxx.awsapps.com/start) - UserName 欄に自分のメールアドレスを入力 (Password 欄は空のまま) → Next
- AWS から OTP パスコードが記載されたメールが届く
(送信元:
no-reply@signin.aws.comまたはno-reply@login.awsapps.com) - メールに記載された OTP パスコードを SSO portal の画面に入力
- 任意の初期パスワードを設定
- パスワード設定直後に MFA デバイスの登録画面に遷移するので、Authenticator アプリ (1Password / Authy / Google Authenticator 等) で QR コードを読み取って登録
- 登録完了後、AWS access portal にログインできる状態になる
- 以降は
aws sso login等で MFA が要求される
「Forgot password?」リンクは押さないこと
既存ユーザーの再設定用で MFA 認証を要求されます。新規アカウントは MFA 未登録のため そこで止まってしまいます (Issue #188)。
OTP パスコードメールが届かない場合
迷惑メールフォルダを確認 (送信元: no-reply@signin.aws.com / no-reply@login.awsapps.com)。
それでも届かない場合は管理者に 「one-time password の発行」 を依頼してください。
管理者から受領した OTP を SSO portal に入力 → 初期パスワード設定 → MFA 登録、の順で
進めます (= 4 ステップ目以降と同じ流れ)。
1-3. AWS CLI のインストール¶
- macOS:
brew install awscli - Windows: https://aws.amazon.com/cli/ から MSI インストーラを取得
- WSL2 / Linux: 上記公式ページの Linux 手順
1-4. テーマリポを clone¶
Claude Code skill (
.claude/skills/automedia-*) はテーマリポに同梱されています。clone した時点で使える状態。
1-5. ~/.aws/config に snippet を貼り付け¶
推奨: Claude Code skill で対話的に設定 (エディタ操作・パス探索が不要):
$ claude
> /automedia-aws-config-setup
これから ~/.aws/config を編集します。
管理者から受け取った snippet を貼り付けてください (空行 2 つで終了):
> [snippet を貼り付け]
>
>
✓ パース成功: profile=spindd-bato
✓ パス解決: /Users/hanako/.aws/config (Windows なら %USERPROFILE%\.aws\config)
✓ 親ディレクトリを自動作成 (なければ)
✓ 既存ファイルをバックアップ: ~/.aws/config.bak.20260526-103045
? 追記してよろしいですか? (Y/n) y
✓ 追記完了
✓ aws configure list-profiles で spindd-bato が見つかりました
skill が以下を自動でやってくれます:
- OS 別の
~/.aws/configパス解決 (macOS / Linux / WSL2 / Windows) - 親ディレクトリ作成 (なければ)
- 既存ファイルの自動バックアップ
- snippet の ini パースと重複 profile 検出
- 追記後の
aws configure list-profilesでの検証
実装は別 Issue で着手予定 (22-credentials.md 実装スコープ)。
手動で行う場合 (skill が未提供 / 不調の時)¶
手動編集の手順を開く
ファイルが無ければ作成:
- macOS / Linux / WSL2:
mkdir -p ~/.aws && touch ~/.aws/config - Windows (PowerShell):
New-Item -ItemType Directory -Force "$env:USERPROFILE\.aws"; New-Item -ItemType File -Force "$env:USERPROFILE\.aws\config"
エディタ (VS Code / メモ帳 / nano など) で開き、管理者から受け取った snippet をファイル末尾にそのまま貼り付け:
[profile spindd-bato]
sso_session = spindd
sso_account_id = 695590128753
sso_role_name = TenantOperator-bato
region = ap-northeast-1
output = json
[sso-session spindd]
sso_start_url = https://<spindd-domain>.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access
既存設定がある場合は追記で OK。複数テナント担当の場合は §5 を参照。
1-6. 動作確認¶
aws sso login --profile spindd-<tenant>
# ブラウザが開き、SSO Portal で MFA → 完了
aws sts get-caller-identity --profile spindd-<tenant>
# Account / UserId / Arn が返れば OK
1-7. 担当チャネルを発行・接続¶
14b メディア運営者編 に従って LINE / HubSpot / Backlog の credential を発行し、/automedia-secret-set で投入。
1-8. E2E 配信確認¶
14b §6 のテスト課題で配信が成功することを確認したら初回セットアップ完了。以後は §2 以降が日常運用です。
2. 日次運用¶
2-1. セッション開始 (作業のたびに)¶
$ aws sso login --profile spindd-<tenant> # 8 時間有効、MFA は 1 日 1 回
$ cd <tenant>-hubspot-theme
$ claude # 通常作業 (個人 Claude Code アカウント / /login 経路)
> /automedia-init
# ✓ SSO 状態 OK / ✓ tenant = <tenant> / ✓ AWS_PROFILE = spindd-<tenant>
/automedia-init が緑なら全 skill が使える状態。red なら表示メッセージに従って aws sso login をやり直し。
Claude Platform on AWS 経路 (任意): AWS 集約課金・監査が要件のときは claude の代わりに ./.automedia/bin/claude を起動する。launcher が SSO 状態を再確認し、必要な env を立ててから claude を exec する。詳細は 21-dev-environment.md §Claude Code の 2 つの起動経路。
2-2. よく使う skill¶
| skill | 用途 | 副作用 |
|---|---|---|
/automedia preview <issue-key> |
Backlog 課題から配信プレビュー生成 | なし |
/automedia status |
テナントの配信状況 (直近の配信 / エラー件数) | なし |
/automedia audience-query <tag> |
HubSpot CRM からタグでリード抽出 | なし |
/automedia-secret-set provider=<line\|hubspot\|backlog> |
チャネル credential を更新 | Secrets Manager 書き込み |
→ read 系は何度叩いても安全。write 系 (/automedia-secret-set) は値の上書きが発生するので注意。
3. コンテンツ運用フロー (毎日の主作業)¶
「Backlog 課題を作って → 承認 → automedia が自動配信」が中核。
3-1. Backlog 課題を起票¶
- https://spindd.backlog.com/projects/TTRTAGSPIN で「コンテンツ運用」issueType の課題を新規作成
- 必須フィールド:
- 件名:
{{chsymbol}} {{summary}}形式 - category: 自分のテナント (例: 馬頭)
- 投稿日時: 配信したい日時 (JST、未来でも過去でもよい)
- チャネル: LINE / HubSpot 等
- テンプレID (任意): 使うテンプレが決まっていれば
- 件名:
- 本文に文面 / 変数 / 添付の指定を書く (13-content-workflow.md > Backlog 課題テンプレ を参照)
3-2. プレビュー確認¶
不満があれば本文を編集して再 preview。
3-3. 承認 → 自動配信¶
Backlog UI で課題の status を automedia承認 に変更。
これだけで自動的に:
1. webhook-backlog Lambda が EventBridge Schedule を登録
2. 投稿日時に deliver Lambda が起動 (即時の場合は 5 秒後)
3. LINE / HubSpot に配信
4. Backlog コメントに [automedia] dispatched at <iso> が付き、status が automedia実行済み に遷移
詳細: コンテンツワークフロー、Backlog 課題ライフサイクル図
3-4. エラー時の対応¶
status が automediaエラー になっていたら:
- Backlog コメントを開いて
[automedia] failed: <reason>を確認 - 課題本文を修正 (例: テンプレ ID 誤り / 投稿日時不正 / オーディエンス過大 等)
- status を
automedia承認に戻すと再実行される
3-5. 承認後の修正 (invalidate)¶
automedia承認 状態の課題本文 / 投稿日時 / テンプレ参照を編集すると、Lambda が 自動で status を 1 つ戻し Schedule を削除します。修正完了後にもう一度 automedia承認 にすれば再登録。
4. チャネル追加 / token ローテーション¶
新しい LINE OA を開設したり、HubSpot Private App を再発行したりした際の手順。
| シナリオ | 手順リンク |
|---|---|
| 新規 LINE 公式アカウントを開設 | 14b §3 LINE チャネル開設 |
| HubSpot Private App を作成 / 再発行 | 14b §4 HubSpot 投入 |
| Backlog 個人 API キーを再発行 | 14b §5 Backlog |
いずれも /automedia-secret-set provider=<...> を Claude Code セッションで実行するだけで管理者の介在なしに完了します。
ローテーションのタイミング¶
- Backlog 個人 API キー: 推奨 90 日。
secret-watchLambda が経過日数を週次監視し、CloudWatch Alarm で通知が来たら再発行 - HubSpot Service Key: 発行時に
expires_atを tag に記録、期限の 30 日 / 7 日前に Alarm - LINE Channel Access Token: 長期発行が多いが、漏えい疑いがあれば即時再発行
詳細: 22-credentials.md ローテーション運用
5. テナント切替 (複数テナント担当の方向け)¶
1 人で複数テナントを担当する場合、~/.aws/config に複数 profile を並べておくと ログイン 1 回で全テナントが有効 になります。
# 朝一の SSO ログインは sso_session 名指定でも、どれか 1 つの profile 名指定でも OK
$ aws sso login --sso-session spindd
# bato で作業
$ cd bato-hubspot-theme && claude
> /automedia-init # → aws.profile=spindd-bato が読み込まれる
> /automedia-secret-set provider=line # /automedia/bato/* のみ操作可
# okada へ切替: 別ターミナル or Claude セッションを終了して
$ cd ../okada-hubspot-theme && claude
> /automedia-init # → aws.profile=spindd-okada に切替
> /automedia-secret-set provider=line # /automedia/okada/* のみ操作可
安全性: profile を取り違えても IAM が拒否するので、誤って他テナントの secret を触ることはありません。内部仕様: 22-credentials.md SSO config の構造
~/.aws/config への profile 追加¶
新しいテナントを追加で担当する場合、管理者から 追加分の snippet を受け取って ~/.aws/config の末尾に追記すれば OK。sso_session ブロックは 1 つだけあれば共有されます。
6. 困ったとき FAQ¶
Q1. aws sso login でブラウザが開かない¶
~/.aws/configのsso_start_urlが正しいか確認- ブラウザのポップアップブロックを解除
- それでもダメなら管理者に SSO start URL を再確認
Q2. /automedia-secret-set が「権限不足」で失敗する¶
- 管理者の bootstrap が完了していない可能性 (Permission Set assignment 未済)
aws sts get-caller-identityで現在の Role を確認 →TenantOperator-<tenant>でなければ profile が違う- 管理者に「
TenantOperator-<tenant>Permission Set への assignment を確認してほしい」と連絡
Q3. 配信が動かない¶
- 課題の status が
automedia承認になっているか確認 automediaエラーになっていれば Backlog コメントに失敗理由が書かれている- それでも分からない場合は
/automedia statusで直近の配信履歴を確認
Q4. 承認したのに反応がない¶
- 投稿日時が 過去 か 未来 か確認
- 過去 → 約 5 秒後に発火するはず
- 未来 → その時刻に発火する
- 5 分以上経っても反応がなければ、Scan Lambda の救済を待つ (最大 24h) or 管理者へ連絡
Q5. token を間違って入力した¶
- 同じ
/automedia-secret-set provider=<...>をもう一度実行すれば上書きされる - 生キーがログに残ることはないので安全 (skill 実装で伏字 + メモリ内のみ利用)
Q6. SSO セッションが切れたメッセージが出る¶
- 8 時間経過で自動失効 →
aws sso login --sso-session spinddでもう一度ログイン
Q7. 複数テナントを切り替えたら違うテナントの操作が混じった¶
- 通常は IAM が拒否するので 混じることはない。もし混じった疑いがあれば CloudTrail で Role を確認 + 管理者へ報告
7. 関連ページ¶
- チャネル オンボーディング メディア運営者編 — 初回 / 追加チャネルのオンボーディング詳細
- クレデンシャル配布 — SSO / AWS profile /
/automedia-secret-setの内部仕様 - コンテンツワークフロー — Backlog 課題のライフサイクルとリトライ規則
- コントロールプレーンと責務分担 — 役割境界と承認フロー設計
- LINE follow フロー — 友だち追加時の挙動