2026年11月1日 · 1分で読めます

自前で作るか、APIを使うか。「SNSに投稿」機能の本当のコスト

プロダクトにSNS投稿を自前で組み込む場合と、ソーシャルメディアAPIを使う場合を、作業項目ごとに比べます。

チケットには、こう書いてあります。「ユーザーがXとLinkedInにシェアできるようにする。」 見た目は1スプリントです。その下に実際にあるものを並べて、見積もりが崩れないようにします。

順調なときの経路（誰もが見積もる部分）

プラットフォームあたり数日です。仕事がここまでなら、自前で作ってよいでしょう。

作業項目	必要な理由	継続するか
トークンの保存と暗号化	セキュリティ審査では、顧客のトークンをどこに置くかを聞かれます	はい
プラットフォームごとのトークン更新	有効期限も更新のルールも、ネットワークごとに違います	はい
プラットフォームごとの本文検証	文字数、メディアの種類、サイズ、カルーセルの枚数はすべて異なります	はい。制限は変わります
メディアのアップロード処理	画像と動画で、アップロードの流れがプラットフォームごとに違います	はい
予約投稿の基盤	多くのプロダクトには「あとで投稿」が必要で、ネイティブ対応はばらつきます	はい
リトライと冪等性	再送したリクエストが、顧客の告知を二重投稿してはいけません	—
失敗の通知	投稿が出なかったことと、その理由をユーザーは知る必要があります	—
連携解除の扱い	ユーザーがアクセスを取り消したら、UIはそれに気づく必要があります	はい
レート制限とバックオフ	プラットフォームごと、ときにはユーザーごとに違います	はい
プラットフォームAPIの変更	エンドポイントは廃止され、ポリシーやティアも変わります	終わりません

高いのは最後の行です。SNSのAPIは、こちらの予定ではなく、相手の予定で変わります。変更のたびに、ロードマップから予定外の作業が引き抜かれます。

SNS投稿はプロダクトそのものですか。それとも、その中の一機能ですか。 売っているものの中心なら、基盤を自前で持つ価値があるかもしれません。一機能なら、トークン更新に使った1時間は、顧客がお金を払う部分に使わなかった1時間です。
ユーザーは、いくつのプラットフォームを求めてきますか。 最初の2つで終わることはありません。
午前2時にLinkedInが投稿を拒んだとき、誰が対応しますか。

bash

curl -X POST https://hapi.tools/v1/posts \
  -H "Authorization: Bearer $HAPI_API_KEY" \
  -d '{"content":"Shipped!","platforms":["x","linkedin"]}'

この1回の呼び出しの裏側には、次のものがあります。

ホスト型のOAuth（PKCE）。トークンはAES-256-GCMで暗号化され、更新もこちらで行います。
実際のプラットフォーム制限に対する検証。投稿を受け付ける前に行います。
タイムゾーンに対応した予約投稿。
冪等キー。リトライしても二重投稿しません。
署名付きWebhook（post.published、post.failed、account.disconnected）。再送は6回までです。
スコープ付きAPIキー、監査ログ、チーム向けのロールベースアクセス。

いま本番で使えるのはX、LinkedIn、Bluesky、Telegram、Discord、Slackです。Instagram、TikTok、YouTubeともう7つはサンドボックスで使えるので、公開を待たずに実装を進められます。

上の表に、エンジニアの時間の単価を乗せてください。「終わりません」の行も含めて、次と比べます。

料金を見る → または トライアルを始める →