Xはほとんどのプラットフォームより量が評価されるため、バッチ処理する価値が本当にあります。280文字という制限のおかげで、30投稿のバッチも見た目より短いライティングセッションで済みます。
バッチを書いてから予約する
よくある間違いは、スケジューラの中で書くことです。時間を選ぶことに気を取られて、投稿の質が落ちてしまいます。
普段使っている場所で30本の短い投稿を書きましょう。それから読み込んで、1回でまとめて予約します。総作業時間は同じでも、はるかに短い時間で終わり、30本まとめて読むことでどれが本当に良いかも分かります。
バッチのインポート
BulkPublishの一括作成エディタ(/compose/bulk)は、次を含むCSVを受け付けます。
| 列 | 必須 |
|---|---|
content | はい |
scheduled_at | いいえ |
media_urls | いいえ |
content列だけで30行あるファイルは有効なインポートで、テキストのみのXバッチには通常それで十分です。
本文もメディアもない行はスキップされるため、末尾の空行が空の投稿になることはありません。テキストにカンマが含まれる場合はフィールドをクォートし、絵文字が壊れないようUTF-8で保存してください。
文字数は投稿ごとにチェックされる
280文字は、公開時ではなく投稿がキューに入る際に検証されます。バッチではこれがいつも以上に重要です。30本のうち1本だけ文字数オーバーというのは目で見て気づきにくく、コンポーザーが警告すれば見逃しようがありません。
これはスレッド内の各投稿にも同様に適用されます。
バッチの中のスレッド
280文字という制限では、まとまった内容を伝える手段はスレッドです。バッチでも変わらない2つのルールがあります。
**最初の投稿は単体で成立しなければなりません。**表示されるのはそれだからです。前置きとしてしか機能しない最初の投稿は、みんなを逃してしまいます。
**デフォルトでスレッド化しないこと。**バッチではすべてのアイデアを3投稿に膨らませたくなりますが、1投稿に収まる内容を2投稿のスレッドにするのは、その1投稿より劣ります。
280文字のおまけ
Xは短文系ネットワークの中で最も厳しい制限を持っています。
| プラットフォーム | 上限 |
|---|---|
| X | 280 |
| Bluesky | 300 |
| Threads | 500 |
| Mastodon | 500 |
つまり、Xのために書いたバッチは他の4つすべてに変更なしで公開できます。これらのうち複数のプラットフォームを使っているなら、作成中に追加のチャンネルを選ぶだけで、追加の執筆なしに1つのバッチが4つのプラットフォーム分になります。
例外はメンションです。ハンドルが異なるためです。また、リプライも会話が存在する場所でのみ意味を持ちます。
予約を先まで詰めすぎない
Xは、予約したコンテンツが最も速く古びるプラットフォームです。そこで機能するものの多くが、今起きていることへの反応だからです。
エバーグリーンな投稿には4〜6週間が妥当な上限です。今起きていることを参照するものは、バッチにまったく入れるべきではありません。
プラン制限
- 投稿: Free:3件/日。Pro:30件/日。Business:無制限。
- チャンネル: Free:3(プラットフォームごとに1)。Pro:30(プラットフォームごとに2)。Business:75(プラットフォームごとに5)。
X公開は他のプラットフォームとは異なる価格体系です。そのAPIには実際のリクエストあたりのコストがかかるためです。FreeプランではPay-as-you-go方式のクレジット、有料プランでは月ごとの利用枠が含まれます。大きなバッチをキューに入れる前に知っておく価値があります。
まとめ
スケジューラから離れてバッチを書き、content列を持つCSVとしてインポートし、投稿ごとの文字数検証に文字数オーバーの投稿を見つけてもらいましょう。Xのコンテンツは速く古びるため、キューは浅く保ってください。そして280文字で書けば、その1つの判断だけでBluesky、Threads、Mastodonも同じバッチでカバーできます。