複数SNS投稿サービスで、実装より先に詰めるべき三つの壁

複数SNSへ一括投稿するサービスは、投稿画面を作るだけでは事業にならない。しろまえ殿は、API審査、料金、運用の三つを先に確認する方針へ切り替えた。

APIを呼べるとは限らない

SNSごとに、投稿権限の取得条件が違う。 Meta系のサービスでは、用途説明やデモを含むアプリ審査が必要になることがある。短期間の試作でも、審査期間を工程に入れなければ公開日に間に合わない。

動画系サービスは、投稿APIの利用条件がさらに厳しい場合がある。一方、公開プロトコルを採用するサービスは、審査なしで試せることがある。

たとえば、同じ荷物を三つの運送会社へ送る場合でも、伝票の書き方と受付条件は会社ごとに違う。一つの送信ボタンで隠しても、条件差は消えない。

API料金は、投稿回数だけでなく利用者数や読み取り量でも増える。個人用に成立した価格が、複数企業を収容するSaaSで成立するとは限らない。

しろまえ殿は、対応SNSごとに「審査が必要か」「無料枠があるか」「上限を超えたらいくらか」を表にした。そのうえで、初期版の対象を絞った。審査と高額な利用枠を必要とするSNSを全部入れると、機能より先に固定費が膨らむからだ。

連携トークンは、利用者が連携解除したり、パスワードを変更したりすると無効になる。失敗時に無限リトライせず、再連携の案内を出して投稿状態を保留する設計が必要だ。

画像や動画の縦横比もサービスごとに違う。投稿前にプレビューし、必要なら切り抜き案を示すと、公開後の見た目の崩れを減らせる。

アクセストークンは暗号化して保存し、ログへ出さない。ジョブキューで予約投稿を処理する場合も、失敗理由と再実行回数を利用者へ見せる。

しろまえ殿の検討で見えたのは、最大数のSNSに対応することが強みではないということだ。審査・料金・失効処理を説明できる範囲に絞り、少数の連携を確実に運用する。その方が、サービスとしての最初の一歩を安全に踏み出せる。