Sociofy 開発マイルストーン

1. 全体方針

初期は単一モノレポで進める: pnpm workspace、Turborepo、apps/*、packages/*、共有パッケージ、React SPA、MUI v7、Emotion、TypeORM、AWS中心。
最初から外部SaaS化を意識するが、MVPは内部運用ツールとして完結させる。
AI生成、レンダリング、承認、投稿を1つずつ完成させるのではなく、TikTok審査動画を撮れる最小縦切りを先に作る。
投稿API連携は、各SNSごとにadapter化し、UIから直接呼ばずSQS worker経由で実行する。
Step FunctionsはMVP標準にしない。DB状態を正とする薄い自前オーケストレーターで、調査、再実行、手動復旧をしやすくする。
本格モニタリングは社内MVPのスコープから外す。MVPではジョブ状態、失敗理由、再実行履歴、監査ログ、生成コスト概算、最低限のCloudWatch Logsに限定する。
Google Docs版は運用しない。正本はMarkdownと公開HTMLにする。

2. マイルストーン一覧

ID	マイルストーン	主目的	目安	外部依存
M0	プロジェクト立ち上げ	開発判断を止める未決定事項をなくす	1 week	なし
M1	基盤と開発環境	AWS/monorepo/CI/CD/DBの土台を作る	1-2 weeks	AWS環境
M2	コアドメインとジョブ基盤	ProductからPublishJobまでの状態管理を作る	2 weeks	DB設計
M3	審査用縦切りUI	TikTok申請動画を撮れる画面を先に作る	2 weeks	TikTok sandbox
M4	画像生成/レンダリング最小実装	4枚生成 + 固定CTA + Photo Mode assetsを作る	2-3 weeks	OpenAI API
M5	TikTok sandbox連携と申請準備	実アプリ動画を録画し、TikTok申請を出す	1-2 weeks + review	TikTok review
M6	Instagram/YouTube連携	Reels/Carousel/Shorts投稿を内部利用可能にする	3-4 weeks	Meta/Google review readiness
M7	内部MVP Alpha	1 product、4切り口、4 active localeの運用を回す	2 weeks	内部SNSアカウント
M8	MVP後の運用強化Beta	失敗復旧、監査、予約、日次運用を安定化する	2-3 weeks	実投稿検証
M9	Production Readiness	内部本番運用に耐える状態へ固める	2 weeks	セキュリティ確認
M10	外部SaaS準備	マルチテナント/課金/審査資料を追加する	Later	各SNS production review

3. 推奨実行順

0M0 立ち上げアカウント、scope、審査前提を固定

1M1 基盤AWS、DB、CI/CD、空deploy

2M2 ジョブ基盤DB状態、SQS、audit

3M3 審査UITikTok動画に映す実画面

4M4 生成/配信5枚スライドと公開URL

5M5 TikTok申請Sandbox、動画、申請提出

6M6 他SNSInstagram/YouTube adapter

7M7 Alpha16 feed/dayの内部試験

8M8 MVP後Beta復旧、bulk、calendar

9M9 本番準備security、runbook、cost

4. 詳細マイルストーン

M0: プロジェクト立ち上げ

開発前に、チームが同じ前提で見積もり、設計、API申請を進められる状態にする。

主な作業

仕様書の確定版をレビューする。
初期対象product、既存4つの編集切り口、4 active locale、対象SNSアカウントを決める。SmartScoutの中国語初期運用は zh-Hant、zh-Hans はcandidateにする。
TikTok、Instagram、YouTubeの内部検証用アカウントを用意する。
TikTok Developer accountとSandbox appを作る。
申請予定scopeを最小化する。
Privacy Policy、Terms、問い合わせ先、アプリ名、アプリアイコンの暫定版を用意する。

完了条件

対象アカウント、対象言語、対象productが決まっている。
TikTok Developer PortalでSandbox appを作成済み。
TikTok申請動画で示すべき画面一覧が合意されている。
仕様書とこのマイルストーン文書が最新版になっている。

M1: 基盤と開発環境

既存社内標準に沿った、継続開発できる土台を作る。

主な作業

単一モノレポを作成し、apps/web、apps/api、apps/worker、packages/shared、packages/ui、packages/configを用意する。
pnpm workspace、Turborepo、lint、format、test、typecheck、build、release手順を整える。
React SPA + MUI v7 + Emotionの管理画面雛形を作る。
S3 + CloudFront + OACでフロントエンドをdeployする。
ECS Fargate、ECR、ALB、SQS、EventBridge Scheduler、Secrets Manager、CloudWatch LogsのCDK雛形を作る。
Aurora PostgreSQL Serverless v2または既存方針に合わせたRDS/Aurora PostgreSQLを用意する。
TypeORM migrationの実行フローをCI/CDに組み込む。

完了条件

管理画面がCloudFront URLで表示できる。
API serviceとworker serviceの空デプロイができる。
TypeORM migrationが検証環境で実行できる。
CloudWatch LogsでAPI/workerの最低限のログを確認できる。dashboard、alarms、X-Ray、OpenTelemetryはこの時点では作らない。

M2: コアドメインとジョブ基盤

投稿前後の状態をDBで追えるようにし、Step Functionsなしで安全にジョブを進められる基盤を作る。

主な作業

Product、EditorialAngle、LogicalFeed、SocialAccount、ContentPackage、Slide、Asset、PlatformRendition、PublishJob、JobAttemptを実装する。
DB-backed thin orchestratorを実装する。
SQS workerでjobを取得し、状態遷移、retry、dead-letter、idempotencyを扱う。
Audit logを実装する。
Secrets ManagerからSNS token、OpenAI key、DB credentialを取得する。
Platform adapter interfaceを定義する。

完了条件

UIまたはAPIからContentPackageを作成できる。
PublishJobがSQSに投入され、workerが処理状態を更新できる。
失敗時にJobAttemptとerror summaryが残る。
同じidempotency keyで重複投稿処理が起きない。

M3: 審査用縦切りUI

TikTok申請動画を撮るために、実際のアプリとして見せられる最小のUIを先に完成させる。

主な作業

ログイン後のProduct一覧、Product詳細、ContentPackage作成画面を作る。
5枚構成のスライドプレビューを表示する。
投稿先としてTikTok Photo Modeを選択できるようにする。
Caption、description、AI生成/ブランド投稿開示を編集できるようにする。
Human approval画面を作る。
TikTok接続状態、必要scope、token状態、account readinessを表示する。
PublishJob dashboardで状態、attempt、error、raw platform IDを確認できるようにする。

完了条件

実際のWebアプリとして、ログインから投稿予約/投稿開始までの流れを画面で辿れる。
TikTok申請動画に映すUIが揃っている。
申請動画で使わないscopeや未実装機能がUI/申請内容に混ざっていない。

M4: 画像生成/レンダリング最小実装

MVP前提の「AI生成画像4枚 + 固定CTA画像1枚」を実際に生成/保存/配信できるようにする。

主な作業

OpenAI GPT Image 2で4枚の画像を生成する。
固定CTA画像を設定として保持する。
生成画像、CTA画像、派生画像をS3に保存する。
TikTok Photo Mode向けにWebP/JPEGの公開URLを作る。
CloudFront custom media domainで公開URLを配信する。
S3 lifecycle ruleで一時公開アセットを削除する。
画像生成費用をContentPackage単位で記録する。

完了条件

1つのContentPackageから、5枚の投稿用画像URLを生成できる。
TikTok/Meta fetcherから取得できるHTTPS URLになっている。
URLにinternal ID、token、secretが含まれていない。
画像生成費用がDB上で確認できる。

M5: TikTok sandbox連携と申請準備

TikTok Content Posting APIの申請に必要な実アプリ動画と資料を揃え、早期に審査へ出す。

TikTok申請には、実際に統合されるWebアプリ上でのend-to-end flowを示すデモ動画が必要。初回審査ではSandbox環境で統合を示す必要があり、選択したproducts/scopesは動画内で明確に利用されている必要がある。

主な作業

TikTok Login/OAuth flowをSandbox appで実装する。
creator_info/queryで投稿可能状態を取得する。
Photo Mode content/initをSandboxで実行する。
status/fetchで処理状態を取得する。
token refreshとtoken失効時のUIを実装する。
TikTok申請用デモ動画を録画する。
申請フォームのApp review informationを作成する。
Privacy Policy、Terms、app icon、app description、website URLを最終確認する。

完了条件

TikTok SandboxでOAuthからPhoto post init/status fetchまで動く。
申請動画が録画済み。
申請時のscope、URL、説明文、動画の内容が一致している。
TikTok審査へ提出済み、または提出可能な状態になっている。

5. 後続マイルストーン

M6: Instagram/YouTube連携

TikTok審査待ちの間に、InstagramとYouTubeのadapterを内部運用可能な水準にする。

Instagram Graph API setup、Professional account、Page接続を確認する。
Instagram Carousel media container、publish flowを実装する。
Instagram Reels向けMP4 rendererとpublish flowを実装する。
YouTube OAuth、動画upload、Shorts向けmetadataを実装する。
YouTube quota usageを記録する。
Platform adapter共通のvalidate、publish、pollStatusを実装する。

M7: 内部MVP Alpha

人間が用意したSmartScoutの既存4つのEditorialAngleを手動登録できるようにする。
EditorialAngleの編集、複製、有効/無効切り替えを実装する。
4 active locale分のLogicalFeedを作成する。zh-Hans はcandidateとして追加可能にしておく。
1日分、16 ContentPackagesを生成する。
Human review、approval、scheduleを実行する。
48-64 PublishJobs/dayのjob生成を検証する。

M8: MVP後の運用強化Beta

社内MVP Alphaの実運用で見えた失敗、差し戻し、再生成、再投稿に対応する。本格モニタリングはここ以降で必要性を判断する。

token refresh automationを実装する。
Platform readiness dashboardを作る。
画像再生成、caption修正、approval差し戻しを実装する。
Bulk approvalを実装する。
Content calendarを作る。
Prompt/template versioningを実装する。
Basic analytics importの最小版を作る。
Slackまたはemailの失敗通知は必須にしない。ジョブ画面だけでは運用が回らない場合に追加する。

M9: Production Readiness

IAM権限を最小化する。
Secrets Manager/KMS設定をレビューする。
S3/CloudFront公開prefixとlifecycleをレビューする。
Audit logとPII/token redactionを確認する。
必要なCloudWatch metrics/alarms/dashboardを設定する。
必要に応じてSlack/emailの失敗通知を追加する。
Backup/restore手順を確認する。
OpenAI画像生成費用、S3/CloudFront転送量、ECS/RDS/Aurora費用を月次で見積もる。
Runbookを作る。

M10: 外部SaaS準備

Organization/Tenant modelを導入する。
Per-tenant RBACを実装する。
Customer self-serve onboardingを実装する。
Customer OAuth connection/disconnection flowを実装する。
Billingとplan enforcementを実装する。
Data export/deleteを実装する。
Abuse control、rate limit、account suspensionを実装する。
TikTok、Meta、Googleのproduction permission review資料を更新する。

6. TikTok申請ゲート

Gate	条件	理由
T1	実際のSociofy Web appが公開URLで動いている	申請動画は実際の統合先アプリを示す必要がある
T2	Website URLと動画内domainが一致している	domain不一致は審査遅延要因になる
T3	Sandbox OAuth flowが動く	初回審査ではSandbox統合を示す必要がある
T4	申請scopeが最小化されている	使わないscopeがあると審査が遅れる
T5	選択したproducts/scopesが動画内で明確に使われている	動画と申請内容の不一致を避ける
T6	Human approvalと開示表示が動画内で確認できる	自動投稿/AI生成/ブランド投稿の誤解を避ける
T7	投稿job statusと監査ログが確認できる	運用・安全性を説明しやすくする
T8	動画が50MB以内で、レビュー担当者が読める解像度	アップロード制限と視認性の両方を満たす

TikTok申請動画チェックリスト

実際のSociofy Web appを開くところから始まる。
申請するWebsite URLと同じdomainが映っている。
TikTokアカウント接続、OAuth consent、接続後のaccount readinessが映っている。
ProductまたはContentPackage作成が映っている。
AI生成または審査用サンプル画像が5枚のスライドとして表示される。
Caption、description、開示ラベル、投稿先の確認が映っている。
Human approvalを経て投稿処理を開始する流れが映っている。
TikTok Photo Modeに必要なscope/productが実際の画面操作として説明されている。
PublishJob status、platform response、失敗時の表示方針が映っている。
申請していないscopeや未実装機能は動画に出さない。
動画は最大5本、各50MB以内に収める。

7. 主要リスクと対策

リスク	影響	対策
TikTok審査で動画不備により差し戻し	production postingが遅れる	M3で審査用UIを先に作り、M5で動画チェックリストを満たしてから提出
申請scopeが実装と一致しない	審査遅延、再提出	申請scopeをM0で仮決めし、M5で最終固定
SNSごとの審査期間が読めない	リリース計画がずれる	TikTokはMVP完成前に縦切りで早期申請、Instagram/YouTubeは並行準備
Step Functionsなしの自前orchestratorが肥大化	保守性低下	DB状態と次job作成だけに責務を限定し、複雑なDSLを作らない
画像生成費用が増える	運用費増	生成枚数、quality、再生成回数をContentPackage単位で記録
CloudFront公開URLに機密情報が混ざる	セキュリティ事故	publish-specific prefixとランダムobject keyを使い、tokenやinternal IDをURLに含めない
多言語/多アカウントで運用UIが複雑化	オペレーター負荷増	M7まではSmartScout初期4切り口 x 4 active localeに固定し、bulk操作はM8で追加。AI翻訳の追加自体よりも、アカウント作成、承認、分析が運用負荷になる

8. 参照資料

確認日: 2026-05-26