複業ログでSNSアフィリエイト（afflow）の実況を書くのは今回が初めてなので、まず「なぜGoogle Apps Script（GAS）で書いた自動投稿ボットをやめて、afflowという新しいリポジトリに作り直したのか」という経緯から書く。
結論から言うと、GASボットが動かなくなったこと自体がきっかけではない。動かなくなったことをきっかけに「この先も複数のプラットフォーム・複数の商材で運用し続けるなら、今の作り方のままでは破綻する」と判断し、作り直すことにした、という順序だ。
目次
最初はGASの個別ボット2本で始めた
SNSアフィリエイトは、最初から大きな設計を持って始めたわけではない。まず「楽天ふるさと納税の情報をXに自動投稿するボット」を1本作り、次に「FANZAのセール情報を投稿するボット」をもう1本、それぞれ独立したGASプロジェクトとして作った。
GASを選んだ理由は単純で、サーバー管理が要らず、Google側の認証まわりも含めて最短で「動くもの」を作れたからだ。実際、それぞれ数時間〜1日程度で最初のバージョンは動き始めた。1つの商材・1つのプラットフォームに対して1本のスクリプトを書く、という最小構成だった。
2本のボットが同時に止まった日
このやり方が破綻したのは、X（旧Twitter）のOAuth認証が両方のボットで同時に切れたときだった。楽天ふるさと納税のボットとFANZAセール情報のボットは、それぞれ別のXアカウントに紐づいており、コードも別々に書かれていた。
復旧作業をしようとして気づいたのは、2つのボットがほぼ同じロジック（投稿文の組み立て、X APIへのリクエスト、エラーハンドリング）を、それぞれ別々に、微妙に違う書き方で持っていたことだ。片方を直しても、もう片方には同じ修正が反映されない。さらに調べると、片方のアカウントはログイン情報自体を紛失しており、認証をやり直すには新アカウントの作成から必要という状態だった。
この時点で、単なる「認証切れの復旧」では済まないと判断した。仮に今回復旧できても、次に商材を1つ増やすたびに、また同じ量のコードを複製することになる。それは事業として持続可能な作り方ではない。
なぜGASのまま直さずに作り直したか
選択肢は2つあった。GASのまま2本のボットを個別に復旧・改修するか、共通基盤を持つ形で作り直すかだ。
判断材料にしたのは次の3点だった。
- 今後の拡張予定: 商材は楽天・Amazon・DMM・myfans・もしも・A8など複数を想定しており、投稿先もX・Instagram・TikTokへ広げる計画がある。GASの個別スクリプト方式だと、組み合わせの数だけコードが増える
- ロジックの重複度合い: 実際に見返すと、投稿文生成・API呼び出し・エラー処理のうち共通化できる部分が大半で、商材固有のロジックはごく一部だった
- GASの実行環境としての制約: 実行時間制限やライブラリの扱いにくさなど、複数プラットフォームを横断する処理を1つの基盤にまとめるにはGASのエディタ上での管理が窮屈になっていた
この3点を踏まえ、「動かなくなったボットを直す」のではなく「今後増える商材・投稿先を前提にした基盤を作る」方向に舵を切った。これが afflow というリポジトリの出発点になっている。
afflowで変えたこと
afflowでは、GAS時代の「1商材1スクリプト」という構造をやめ、research→strategy→production→posting→analyticsという処理の流れを共通の基盤の上に乗せる設計にした。実装はクリーンアーキテクチャ（domain/usecase/adapter/infrastructureの層分け）を採用し、X APIやRemotionのような外部依存はadapter層に隔離している。
これにより、商材やプラットフォームを追加するときに書く量が「その商材・プラットフォーム固有の差分」だけで済むようになった。GAS時代のように、投稿文生成やAPI呼び出しのロジックを商材ごとにコピーし直す必要がなくなったのが、一番の変化だ。
ただし移行はまだ完了していない。旧GASボット2本は現在もX側のOAuth認証が切れたままで、投稿を停止している。楽天側は新アカウントの作成、FANZA側はアカウント確認という復旧作業が別途必要で、afflow基盤への統合はこれからの作業になる。「動いていたものを壊さず作り直す」のではなく「壊れたのを機に作り直しを先に進める」という、あまり褒められた順序ではないやり方になっているのは正直に書いておきたい。
まとめ
- GASボット2本が同時にX認証切れで止まったことがきっかけで、単純な復旧ではなく基盤の作り直しを選んだ
- 判断材料は「今後の拡張予定」「ロジックの重複度合い」「GASの実行環境としての制約」の3点
- afflowではクリーンアーキテクチャを採用し、商材・プラットフォームを追加するコストを「固有の差分」だけに抑える設計にした
- 旧ボットの復旧とafflow基盤への統合はまだ途中で、今も並行して進めている
次回は、afflow基盤の中で最初に着手した動画自動生成パイプラインについて、具体的な実装の実況を書く予定だ。
