記事をSNSへ流す運用を始める―X連携の前に投稿方法と候補を確認する
ゆまラボの記事をSNSへ流す前に、X、Bluesky、Threads、Mastodonの投稿方法を現在の公式情報で確認する。リンクプレビュー、投稿、GA4での流入計測を分け、まずXから始めるための前提を確認する。
ゆまラボは、記事を公開して検索から読んでもらうところまでは進めてきた。
Search Consoleを登録し、Google Analyticsも導入した。アクセス解析の記事では、SNSを始めたあとに「Google検索、SNS、直接アクセス、外部サイトのどこから読まれているか」を確認したいという話も書いている。
次に実作業として進めるのはXとの連携。
Xを使うこと自体は決めている。ただ、SNS連携という言葉だけでは範囲が広い。
記事ページにシェアボタンを置くのか。記事公開後に自動投稿するのか。SNS上でリンクカードを表示するのか。Google Analyticsで流入元を分けるのか。
さらにX以外を見ると、Bluesky、Threads、Mastodonにも公式の投稿APIがある。
全部を同時に始めるつもりはないが、Xの実装へ入る前に現在の選択肢を確認しておく。
SNS連携は投稿・リンク表示・流入計測を分ける#
ブログとSNSをつなぐ処理は、大きく3つに分かれる。
1. 記事URLをSNSへ投稿する
2. SNS上でタイトル・説明・画像などを表示する
3. SNSから来たアクセスを計測するこの3つは別の処理。
例えばXへ記事URLを投稿する部分は、Web Intentを使って投稿画面を開く方法と、X APIから自動投稿する方法で実装が違う。
一方、投稿後にURLがどう見えるかは、サイト側のメタデータが関係する。
現在のゆまラボは、ブラウザのDevToolsでHTMLを確認すると、canonical、description、Open Graph、Twitter Card系のmetaが出ている。
SNSを始めるために、まず記事本文の公開方法を変える必要はない。
Markdownを公開
↓
記事URLができる
↓
SNSへURLを投稿
↓
SNS側がリンク情報を使って表示
↓
読者がクリック
↓
bringain.comへアクセス
↓
Google Analyticsで流入を確認という経路になる。
ここで投稿方法とアクセス計測を一緒に実装すると分かりにくい。
最初は「Xへ記事を出せること」と「X経由のアクセスを判別できること」を分けた方が確認しやすい。
XはWeb IntentとAPIで役割が違う#
Xには、サイトから投稿画面を開くWeb Intentが現在も用意されている。
公式ドキュメントではhttps://x.com/intent/tweetを使い、ユーザーがX側の投稿画面で内容を確認して投稿する。Web Intent自体にはXアプリの作成、認証情報の保存、投稿権限の取得は必要ない。
これは「この記事をXで共有する」ボタンには向いている。
ただし、ゆまラボ側で記事公開を検知し、自動的にXへ告知する処理とは別。
自動投稿まで行うならX APIを使う。
現在の公式ドキュメントでは新規実装にX API v2が推奨され、投稿作成は次のエンドポイントになっている。
POST https://api.x.com/2/tweets
Authorization: Bearer <access-token>
Content-Type: application/json本文はJSONのtextで送る。認証にはOAuth 2.0で取得したアクセストークンが必要。
ここで確認しておきたいのが料金。
2026年9月12日時点のX APIは、以前の固定プランではなくpay-per-usage方式になっている。公式料金表では、
Post: Create $0.015 / request
Post: Create (with URL) $0.200 / requestとなっている。
ゆまラボでやりたいのは記事URL付きの告知なので、APIからURL付きPostを作成する場合は現在のPost: Create (with URL)が関係する。
1記事を1回投稿するだけなら大きな金額ではない。ただ、無料だからとりあえず組み込む機能ではなくなっている。
X側も価格は変更される可能性があり、最新価格はDeveloper Consoleで確認するよう案内している。実装時にはもう一度確認する。
このためX連携には少なくとも、
記事ページから読者が共有する
→ Web Intent
記事公開後にゆまラボ側から自動投稿する
→ X APIという2つの候補がある。
次にXを実装するときは、ここを先に決める必要がある。
X以外はBluesky・Threads・Mastodonを候補に残す#
記事URLをテキストと一緒に流す用途に絞ると、X以外にもAPIを持つSNSがある。
現時点で確認できた範囲は以下。
| サービス | 投稿方法 | URL・リンクカード | 現時点の扱い |
|---|---|---|---|
| X | X API v2 / Web Intent | URL付きPost、Web Intent | 次に連携する |
| Bluesky | AT Protocol / app.bsky.feed.post | app.bsky.embed.externalでWebサイトカードを持てる | 候補 |
| Threads | Threads API / OAuth 2.0 | テキスト中のURL、link_attachmentに対応 | 候補 |
| Mastodon | POST /api/v1/statuses | status本文へURLを含められる | 候補 |
Blueskyは投稿そのものがapp.bsky.feed.postというレコードになっている。
URLを投稿するだけでなく、公式ドキュメントにはapp.bsky.embed.externalを使ったWebsite Cardの例もある。URI、title、description、thumbnailを投稿レコード側に持たせる構造で、Xとはリンクカードの扱いが少し違う。
Threadsも公式APIからテキスト投稿ができる。
Metaの公式Threads APIコレクションでは、OAuth 2.0を使い、テキストだけのPostでは本文中の最初のURLをリンクプレビューへ使う方法と、link_attachmentでURLを明示する方法が案内されている。
MastodonはインスタンスごとにAPIのホストは変わるが、公式API仕様には、
POST /api/v1/statusesがあり、ユーザートークンとwrite:statuses権限で投稿できる。
技術的にはどれも「ブログ記事の公開後にURLを投稿する」処理を作れる。
ただ、APIがあることと、ゆまラボで運用する価値があることは別。
X以外はまだ連携を決めていないので、先にアカウントや自動投稿処理を増やす必要はない。Xを動かして、実際の流入と運用負荷を見てから追加すればよい。
SNSからのアクセスはUTMで分ける#
SNSへの投稿を始めるなら、流入の計測方法は最初に決めておきたい。
Google Analyticsはすでに導入している。
過去の人気記事とアクセス解析の記事でも、SNS開始後に流入元を確認することを想定していた。
Google Analyticsでは参照元からSNS流入を見ることもできるが、複数のSNSへ同じ記事を投稿するならUTMを付けておくと区別しやすい。
Googleの公式ヘルプでは、カスタムキャンペーンURLに、
utm_source
utm_medium
utm_campaignを付ける方法を案内している。
例えばXなら、
https://example.com/blog/example/
?utm_source=x
&utm_medium=social
&utm_campaign=article_publishBlueskyなら、
https://example.com/blog/example/
?utm_source=bluesky
&utm_medium=social
&utm_campaign=article_publishという形にできる。
ThreadsやMastodonもutm_sourceだけサービスごとに変える。
GoogleはUTMの値について表記を統一することも勧めている。値は大文字小文字を区別するため、
x
X
twitter
Twitterのように途中で変えると、分析時に別データとして扱われる可能性がある。
SNS連携を作るなら、投稿処理の中で毎回手入力するのではなく、サービスごとのutm_sourceを決めてURLを生成する方が扱いやすい。
記事ごとの差はリンク先のパスで分かるので、最初から大量のUTMパラメータを追加する必要はない。
最初はXだけで運用を確認する#
候補を調べると、X以外もAPIで投稿できる。
それでも、最初から4サービスへ自動投稿する構成にはしない。
ゆまラボで次に確認したいのは、
記事を公開
↓
Xへ投稿
↓
リンク表示を確認
↓
実際にクリックする
↓
Google AnalyticsでX流入を確認という1本の経路。
ここまで動けば、同じ考え方をBlueskyやThreadsへ増やせる。
逆に、Xだけでも投稿文を毎回直す、認証の管理が必要、料金が気になる、といった運用上の問題が出るなら、SNS数を増やす前にそちらを修正した方がよい。
現時点で確定しているのはXとの連携。
Bluesky、Threads、Mastodonは「APIがあり、記事URLを配信できる候補」として残す。
次の実装では、XをWeb Intentで扱うのか、APIで自動投稿するのかを決め、実際の投稿とGA4での流入確認まで行う。
参考#
関連記事
CodexにX投稿を手伝わせる―未投稿記事を管理してWeb Intentで半自動化する
ゆまラボの記事をXへ流す方法として、Codexに未投稿記事の抽出、投稿文生成、UTM付きURL作成、Web Intent起動まで任せ、最後のポストだけ人が確認する半自動運用を考えます。
第5回 記事をXへ流す運用を始める―手動投稿からWeb Intentで半自動化する
ゆまラボの記事をXへ流す運用を、手動投稿からWeb Intentを使った半自動方式へ進めました。未投稿記事の管理、UTM付きURL、Codexからの投稿画面起動、実投稿、Google Analyticsのリアルタイム確認まで記録します。
Webサイトの個性はどこまで必要か―ゆまラボの変更から考えるブランディングと使いやすさ
Astroの初期テンプレートから始めたゆまラボの変更を振り返り、Webサイトの個性をどこに出すと使いやすさを壊しにくいか、逆に独自性を強くしすぎたときに起きる問題を考える。