1. 導入
複数のSNSアカウントを毎日手動で運用していた作業を、「前日に承認 → 当日は自動実行 → 翌日に確認」の半自動フローに置き換えた。
開発にはAIコーディングアシスタント（Antigravity）を活用し、投稿のストック管理、スケジュール実行、APIコスト管理、成果の計測・比較までを一貫して回す仕組みを構築した。ただし完成品ではない。コンバージョン追跡の自動化は未実装で、コンテンツ品質の最終判断は人間に依存している。
この記事は製品紹介ではなく、実務の課題に対して試作と改善を繰り返した記録として書いている。
2. 背景と課題
2-1. 手動運用のボトルネック
運用していたのは、役割の異なる複数のSNSアカウントを連携させたアフィリエイトの導線だ。集客用のアカウントでインプレッションを集め、別のアカウントで交流し、最終的に収益接点のアカウントへ誘導する。
この一連の作業——投稿の作成、各アカウントへのログイン、投稿の実行、リプライによる誘導——をすべて手動でやっていた。1日あたり30分から1時間はこの作業だけに取られていた。再現性もない。「昨日と同じことをする」つもりでも、微妙にタイミングや文面がずれる。
2-2. コストが見えない怖さ
SNSのAPIには無料枠の制限がある。手動運用のときは投稿数が少なかったため気にならなかったが、自動化して投稿頻度を上げようとすると、API消費量が見えないまま運用するのは怖い。
当時のコスト管理は、月末に利用量をまとめて確認するだけだった。超過していたことに気づいたときには、もう取り返せない。
2-3. 「何が効いたか」が分からない
おそらく自動化以上に深刻だった課題がこれだ。
毎日投稿して、誘導して、多少の成果は出ている。しかし「どの投稿文が良かったのか」「どの誘導方法が成果を生んだのか」を判断する根拠がなかった。改善しようにも、「何を変えればいいか」が分からない状態だった。
2-4. アカウント停止で全部止まる
SNSプラットフォームの運用では、アカウント停止は「いつか起こる」前提で設計すべきリスクだ。当時はアカウント間の依存が強く、1つ止まると導線全体が崩壊する構造だった。
3. 何を作ったか
3-1. 3層に分けたファネル構造
アカウントの役割を「集客」「交流」「収益接点」の3層に分離し、それぞれを独立したジョブとして管理する設計にした。
各層は独立して投稿を行い、投稿時にデータベースから下流の層の最新投稿URLを自動取得して導線をつなぐ。ある層のアカウントが停止しても、他の層はそのまま稼働し、差し替えるだけで復旧できる。誘導方式（自己リプライ型と引用投稿型）も切り替え可能で、どちらが効果的かをA/Bテストで検証できる。
ただし、この設計に最初からたどり着いたわけではない。当初は「1回のジョブで3層すべてを順番に実行する」チェーン方式だった。この問題点とやり直しの経緯は後述する。
3-2. コストを「使う前に」管理する予算台帳
APIコストの管理には、会計処理にある「与信」の考え方を取り入れた。
API呼び出しの前に予算枠を「予約」する。呼び出しが成功したら「消費を確定」し、失敗したら「予約を解放」する。この3ステップにより、1日の予算上限に達した時点で残りのジョブは翌日に自動スリープする。予算超過が構造的に起こりえない設計にした。
3-3. ジョブキュー・A/Bテスト・ダッシュボード
投稿タスクはデータベース上のキューで管理し、スケジュール実行・自動リトライ・連続失敗ジョブの隔離を組み込んだ。ワーカーがクラッシュしても二重実行が起きないリース方式を採用しており、夜間に放置しても翌朝ダッシュボードで結果を確認するだけで済む。
成果計測では、「集客コンテンツの種類」「交流文面」「収益接点の文面」を独立した変数として記録し、組み合わせ別に効果を比較できるようにした。ダッシュボードでは、API残予算・待機タスク一覧・エラー隔離ジョブ・アカウント連携状況をブラウザから一覧確認できる。
3-4. AI提案 → 人間承認のストック型ワークフロー
AIが自律的にAPIを呼んで投稿する方式は採用しなかった。最終的に落ち着いたのは「AIが下書きを提案し、人間が承認したら一括登録する」という半自動のストック方式だ。
運用フローを6つのフェーズ（情報収集 → 下書き生成 → 承認・登録 → スケジュール実行 → 成果回収 → 分析・改善）に分割し、各フェーズをAIアシスタントが実行可能なワークフローとして定義した。人間は「提案を確認してOKを出す」ことに集中できる。
4. AIコーディングアシスタントをどう使ったか
このプロジェクトでは、開発工程と日常運用の両方にAIコーディングアシスタント（Antigravity）を活用した。
4-1. 設計・実装・レビューの場面
設計の壁打ちと実装
アーキテクチャの設計策定からコード実装までをAntigravityと対話しながら進めた。たとえば「1ジョブで3層を連続実行する方式」から「各層が独立ジョブとして動く方式」への設計変更では、Antigravityがジョブ分離の設計案を提示し、コード変更を実装し、ワークフロー定義の更新まで通しで行った。人間はレビューと方針判断に集中できた。
コードレビューで致命的バグを発見
もっとも価値があったのは、おそらくコードレビューの場面だ。
ある時点のコードには、特定の認証設定が抜けている場合にメインアカウントで全操作を代行するフォールバック処理が残っていた。これが本番で動くと、本来は別のアカウントが担当すべきコンテンツをメインアカウントが投稿してしまい、アカウント停止に直結する致命的なバグだった。
この問題はAntigravityによるコードレビューで発見され、本番稼働前に修正できた。同じレビューで、A/Bテストの計測精度を破壊する設計ミスや、ファネルの部分的な失敗を無視する問題も指摘された。
4-2. 日常運用の場面
日々の運用では、翌日分の投稿案の提案、蓄積された成果データの集計・整理、A/Bテスト結果に基づく改善提案をAntigravityが担当している。いずれも人間がOKを出したものだけが反映される。
4-3. 人間が判断した部分
以下の領域はAIには任せず、人間が判断している。
- コンテンツ戦略の方向性: AIが最初に提案した方向性がターゲット層に合わなかった場面があり、市場の反応を見て人間が再定義した。
- コンプライアンス判断: 内部ドキュメントに残っていた「絶対安全」「完全に規約準拠」といった過信表現を、リスク実態に合わせてトーンダウンした。
- 投稿の最終承認と損切り判断: AIは下書きと分析データを出すが、投稿するかどうか、どのパターンを続けるかの最終判断は毎回人間が行っている。
5. 1日の運用フロー
現在の日常運用の流れは以下のとおりだ。
【前日まで：ストック準備】
- AIアシスタントに「翌日分のジョブを提案して」とチャットで指示する
- AIが、設定されたペルソナとテンプレートに基づき、翌日分の投稿案（各層あわせて約10件）を表形式で提示する。各投稿の文面、投稿時刻、誘導方式のA/Bテスト割り当てが含まれる
- 内容を確認し、修正があれば指示し、問題なければ「OK」と伝える
- AIが承認内容をジョブキューに一括登録する。この時点で、実行日時・投稿テキスト・比較テスト変数がすべて確定する
この準備作業にかかる時間は、通常5〜10分程度。
【当日：自動実行】
- ワーカープロセスを起動しておく（バッチファイルをダブルクリックするだけ）
- スケジュールされた時刻になると、ワーカーがキューからジョブを取り出し、対象アカウントで投稿を実行する
- 投稿完了後、下流アカウントの最新投稿URLを自動取得し、リプライやリンクで導線をつなぐ
- 予算上限に達した場合、残りのジョブは自動的に翌日に繰り越される
この間、人間は何もしなくてよい。
【翌日以降：確認と改善】
- ダッシュボードを開き、投稿結果・API消費量・エラー隔離ジョブの有無を確認する
- 成果分析ワークフローを実行し、各投稿のインプレッション・クリック等を回収する
- A/Bテストの結果（パターン別の限界利益）を確認し、次回の改善方針を決める
- 必要に応じてペルソナ設定やテンプレートを更新する
確認作業は10〜15分程度。改善作業が入る日でも30分以内には終わる。
改善前の手動運用では、投稿作業だけで1日30分〜1時間、成果確認と改善にさらに時間がかかっていた。現在はその大半がシステムとAIの提案に置き換わっている。
6. 途中で起きた失敗と、その修正
開発と運用を通じて、いくつかの設計ミスと判断の失敗があった。いずれも本番稼働前後に発見・修正されたが、放置していれば深刻な事故につながるものだった。
6-1. メインアカウントを壊すところだった
最も危険だった問題は、アカウント設定の不備に対するフォールバック処理だった。
初期の実装では、特定のアカウントの認証トークンが環境設定に未登録の場合、メインアカウントの認証情報で代行して投稿する処理が入っていた。開発時は「設定が不完全でもとりあえず動く」ことを優先した結果だ。
しかし、これは本来は別アカウントが投稿すべきコンテンツを、メインアカウントが投稿してしまうことを意味する。内容次第ではメインアカウントが即座に停止される。
この問題はAntigravityのコードレビューで発見された。修正として、アカウント未設定時には代行せず即座にエラーを投げる安全装置に切り替えた。「動かない」ことのほうが「間違って動く」ことよりはるかに安全だという判断だった。
6-2. 壊れたファネルを「成功」にしていた
もうひとつの深刻な問題は、部分的な失敗の扱いだった。
3層のファネルを順に実行する際、下流の投稿（たとえば収益接点の投稿）が失敗しても、上流の投稿（集客投稿）が成功すれば、システムはジョブ全体を「完了」として記録していた。
結果として、誘導先のリンクが存在しない投稿が量産されていた。外から見ると何も問題ないように見えるが、導線が切れているため成果は出ない。しかもシステム上は「成功」なので、この問題が起きていることに気づきにくい。
修正として、全層の投稿がすべて成功しない限りジョブを完了扱いにしない「原子性」を導入した。途中で失敗した場合はジョブ全体をリトライまたは隔離に回す設計にした。
6-3. テスト結果が計測できなくなっていた
A/Bテストの仕組みを作ったにもかかわらず、計測結果が使い物にならなくなっていた時期がある。
原因は、投稿テキストの選択タイミングだった。ワーカーがジョブを実行する際に、テンプレートの中からテキストをランダムに選択する仕様になっていた。これでは「どの集客コンテンツが成果に貢献したのか」と「どの交流文面がたまたま選ばれたか」の区別がつかず、因果関係が崩壊する。
修正として、テキストの選択をジョブ登録時に確定させる方式に変更した。ジョブが登録された時点で、どの投稿文・どの誘導文が使われるかが確定し、実行時にランダム要素が入らない。これにより、A/Bテストの計測精度を回復できた。
6-4. アーキテクチャをやり直した
当初の設計は「1つのジョブで3層すべてを順番に実行する」チェーン方式だった。シンプルで分かりやすい設計のはずだった。
しかし運用を始めると問題が見えてきた。
- 途中の1層で失敗した場合、どこまで戻してやり直すかのリカバリーが複雑になる
- 各層のスケジュールを個別に調整できない（時間帯をずらすA/Bテストができない）
- 特定の層だけジョブを追加・削除する柔軟性がない
これらの問題を受けて、各層を完全に独立したジョブとして実行する設計に全面的に作り直した。層と層の接続は、実行時にデータベースから下流層の最新投稿を自動取得して行う。
Antigravityが新設計の策定・コード実装・ワークフロー更新まで一貫して担当し、既存のジョブに影響を与えない形で移行を完了した。
ほかにも、SNSプラットフォームのAPI仕様による制約（引用投稿のAPIパラメータでエラーが出るため、URL埋め込み方式に切り替えた）や、外部CDNのメディアURLが期限切れになる問題（ジョブ登録前にローカル保存する必須ステップを追加した）など、実運用で初めて遭遇するトラブルがいくつかあった。
7. 改善前後でどう変わったか
具体的な数値は公開できないが、工程と判断負荷の変化は明確だ。
| 観点 | 改善前 | 改善後 |
|---|---|---|
| 日常の作業 | 複数アカウントに個別ログイン → 手動投稿 → リプライ誘導 → 目視確認。毎日30分〜1時間 | AIの投稿案をチャットで確認してOK。残りは自動。日常は数分〜15分 |
| コスト管理 | 月末にまとめて確認。超過に気づいたときには手遅れ | 投稿前に予算枠を自動確保。上限到達で翌日スリープ。超過が構造的に発生しない |
| 障害対応 | スクリプト停止 → 手動で原因調査 → 手動で再実行 | 自動リトライ＋隔離。異常ジョブが正常ジョブに影響しない。翌朝ダッシュボードで確認するだけ |
| 施策の評価 | 「なんとなく効いた気がする」の感覚判断 | 3軸のA/Bテストでパターン別に限界利益を比較。継続・中止に定量根拠がある |
層分離により、アカウント停止時も該当層だけ差し替えれば復旧できるようになった。
8. 現時点でできること / できないこと
できること
- 翌日分の投稿案をAIが提案し、承認後に自動投稿するストック型の運用
- 複数アカウントの役割分離と、層間の自動導線構築
- APIコストのリアルタイム管理と予算超過の構造的な防止
- 投稿成果の定期的な自動回収と、3軸でのA/Bテスト比較
- 障害時の自動リトライ、問題ジョブの隔離
- ブラウザからのアカウント連携と運用状況の監視
できないこと
- コンバージョンの自動追跡: アフィリエイト成果の取り込みは手動。インプレッションやクリックは自動回収できるが、実際の成約情報はまだ手入力に頼っている。これは最優先の改善課題。
- 大規模運用: 軽量なデータベースを使用しており、大量のアカウントやジョブを同時処理する設計にはなっていない。現在の規模では問題ないが、スケールする場合はデータベースの移行が必要。
- プラットフォーム変更への自動対応: SNS側のポリシー変更やAPI仕様変更には手動で対応する必要がある。現にAPI経由の引用投稿が使えなくなるケースに遭遇し、代替方式に切り替えた。この種の問題は今後も起こりうる。
- コンテンツ品質の保証: AIが生成する投稿テキストが、ターゲット層に本当に刺さるかどうかの判断は、いまだに人間の直感に頼っている。AIは「それっぽい」文章を作れるが、市場感覚を持つことはできない。
9. まとめ
このプロジェクトで得た学び
APIコスト管理は「事後集計」ではなく「事前予約」で設計すべきだ。
使った後に合計しても手遅れになる。使う前に枠を確保する仕組みを入れたことで、予算超過への不安がなくなった。APIを使うシステムなら規模を問わず有効な設計パターンだと思う。
AIは完全自動より、承認前提の半自動のほうが現実的だ。
AIが勝手に動くことへの不安は、コスト面でもコンテンツ面でも大きかった。「AIが提案し、人間がOKを出す」方式は地味だが、事故を防ぎながら工数を減らすバランスとして、今のところ最善だった。
障害処理は後付けではなく最初から設計に入れるべきだ。
個人開発では後回しにしがちだが、自動リトライとジョブ隔離を初期から入れたことで、夜間や外出中でも放置できる運用基盤ができた。
AIコーディングアシスタント（Antigravity）について
Antigravityが力を発揮したのは、設計の壁打ち・コード実装・コードレビュー・データ整理といった、作業量が多く注意力が求められるタスクだった。特にコードレビューでの致命的バグの発見と、アーキテクチャ全面変更の迅速な実装は、人手だけでは判断を先延ばしにしていたかもしれない。一方で、コンテンツ戦略の方向性やコンプライアンスのリスク判断は、人間のほうが適切に行えた。
SNSマーケティングの自動化に限らず、AIコーディングアシスタントは「ボトルネックを特定して、そこだけを自動化する」プロセスを大幅に加速してくれるツールだった。ただし、どこを自動化するかを決めるのは人間の仕事だ。
この記事は、開発中のプロジェクトについて、公開可能な範囲で記録したものです。
具体的なサービス名、売上数値、コードは含んでいません。
今後の運用結果を踏まえ、内容を更新する予定です。
コメント