複業ログの5本目。SNSアフィリエイト事業を、作った直後のリポジトリを一度アーカイブしてまで、クリーンアーキテクチャで作り直した経緯を書く。
目次
最初の実装をアーカイブした理由
SNSアフィリエイト事業（楽天・Amazon・DMM・myfans等の商材を、X・Instagram・TikTokで紹介する）は、最初にaffi-videoというリポジトリで着手した。だが、作成した直後にこのリポジトリはアーカイブし、afflowという新しいリポジトリに作り直した。
理由は単純で、この事業を「リサーチ→戦略→制作→投稿→計測」という一連のパイプラインとしてプラットフォーム化するつもりだったからだ。最初の実装は動画生成の部分だけを急いで作っていて、後から他の工程を継ぎ足していく設計になっていなかった。1つの動画を作って投稿するだけなら困らないが、複数商材・複数プラットフォームを継続的に回す仕組みとしては、土台からやり直した方が早いと判断した。
クリーンアーキテクチャを選んだ理由
作り直すにあたって、domain・usecase・adapter・infrastructureに分けるクリーンアーキテクチャ構成を採用した。依存の向きは外側（infrastructure）から内側（domain）への一方向に固定している。
この事業で特に効くと考えたのが、動画生成エンジン（Remotion）や各種プラットフォームのAPI SDKをadapter層に隔離することだ。SNSアフィリエイトは、プラットフォーム側の仕様変更やAPIの改廃が起きやすい領域だ。X・Instagram・TikTokそれぞれのAPI、Remotionのようなライブラリへの依存を外側に押し出しておけば、仕様変更の影響がその境界の外に漏れない。ビジネスロジック（どの商材をどう紹介するか、といった判断）を、外部ツールの都合から守れる設計にしたかった。
「縦に1本貫通」を優先する実装順
もう1つ意識したのは、実装の順番だ。「リサーチ→戦略→制作→投稿→計測」の5工程を、横に並んだ機能として全部同時に作り始めるのではなく、まず動画生成パイプライン（Remotion部分）を縦に1本通すことを優先した。
複数の機能を並行して作りかけの状態で持つよりも、1つの工程を実際に動くところまで仕上げてから、次の工程（計測・データ契約）に進む方が、複業の限られた時間では手戻りが少ない。実際に動くパイプラインが1本あれば、そこから学んだことを次の工程の設計に反映できる。
既存資産の負債にも向き合う
作り直しと並行して、既存のGASボット2本（楽天ふるさと納税アフィリ、FANZAセール情報）が抱えていた問題にも向き合う必要があった。どちらもX（旧Twitter）のOAuth失効で投稿が止まっており、楽天側は旧アカウントのログイン情報を紛失していて新アカウントの作成が必要、FANZA側はアカウント確認待ちの状態だった。
新しいパイプラインを作ることと、動かなくなった既存の仕組みを復旧することは、優先度で揺れる部分だ。今のところは新パイプラインの構築を優先しつつ、復旧作業も並行して進めている。
運用面のルールも設計に含めた
技術的な設計だけでなく、運用ルールもこの段階で決めた。ステマ規制対応として全投稿に#PR表記を徹底すること、商材のジャンルによって媒体を使い分けること（アダルト系はX限定、物販はInstagram・TikTokにも展開）は、パイプラインの投稿工程に組み込む前提としてあらかじめ固めておいた。
まとめ
- 動画生成だけの最初の実装は、継続運用を見据えた設計になっておらず作り直した
- プラットフォームAPIやライブラリへの依存をadapter層に隔離し、仕様変更の影響範囲を限定する設計にした
- 実装は「縦に1本貫通」を優先し、複業の限られた時間の中で手戻りを減らす順番で進めている
- 既存の負債（OAuth失効したGASボット）にも並行して向き合っている
次は、この新しいパイプラインで実際に動画を作り、投稿・計測まで回した実況を書く予定だ。
