文字数・単語数の制限 2026 — Twitter、SMS、SEO、Instagram
文字数制限とは、プラットフォームが一つのフィールドで受け付ける Unicode コードポイント（codepoint）の最大数のことだ。Twitter の投稿なら 280、GSM-7 エンコーディングの単一セグメント SMS なら 160、Google の meta description は切り詰められる前で約 160 文字。気にすべき数字は公開先によって変わるし、本文に絵文字、スマートクォート、CJK 文字が含まれるかどうかでも計算結果が変わる。
このガイドは、ソーシャルメディアのライター、SEO スペシャリスト、マーケティングコピーライター、セグメント単位で課金される SMS 送信者、そして Twitter や Instagram、SMS ゲートウェイが実際にカウントする方法と一致するバリデーションを書く開発者のためのものだ。25 プラットフォームのチートシートはクイックリファレンス表へ、6 つの主要プラットフォームに対して下書きをリアルタイムで照合するなら文字数カウンターを使えばよい。制限を超えた瞬間にプログレスバーが赤くなる。
クイックリファレンス — 全プラットフォームの文字・単語制限
以下の表は、ライターと開発者が最も頻繁に遭遇する 30 以上のフィールドを網羅している。「ハード制限」はプラットフォームが強制する上限、「可視 / fold より上」は切り詰めが入る前に読者が目にする範囲、「スイートスポット」はコンテンツが最もよくパフォーマンスする経験的な範囲だ。
| プラットフォーム | ハード制限 | 可視 / fold より上 | スイートスポット | 絵文字のカウント |
|---|---|---|---|---|
| Twitter / X 投稿 | 280 文字 | 280 | 70-100 文字 | 1 コードポイント |
| Twitter / X bio | 160 文字 | 160 | — | 1 コードポイント |
| Twitter / X 表示名 | 50 文字 | 50 | — | 1 コードポイント |
| X Premium 長文 | 25,000 文字 | — | — | 1 コードポイント |
| Instagram キャプション | 2,200 文字 | 最初の 125 文字（その後「もっと見る」） | フックは 125 未満 | 1 コードポイント |
| Instagram bio | 150 文字 | 150 | — | 1 コードポイント |
| Instagram ハッシュタグ | 最大 30 個 | — | 5-10 | — |
| LinkedIn 投稿 | 3,000 文字 | 最初の 210 文字（その後「see more」） | 1,300 未満 | 1 コードポイント |
| LinkedIn 記事 | 110,000 文字 | — | — | 1 コードポイント |
| LinkedIn 見出し | 220 文字 | 220 | — | 1 コードポイント |
| Facebook 投稿 | 63,206 文字 | デスクトップ ~477 / モバイル ~125 | オーガニックは 80 未満 | 1 コードポイント |
| TikTok キャプション | 2,200 文字 | 最初の ~100 | 150 未満 | 1 コードポイント |
| YouTube タイトル | 100 文字 | 70（検索） | 60 未満 | 1 コードポイント |
| YouTube 説明 | 5,000 文字 | fold より上に最初の 100-150 | フックは最初の 150 | 1 コードポイント |
| YouTube コメント | 10,000 文字 | — | — | 1 コードポイント |
| Reddit タイトル | 300 文字 | — | 60 未満（subreddit 依存） | 1 コードポイント |
| Reddit コメント | 10,000 文字 | — | — | 1 コードポイント |
| Discord メッセージ | 2,000 文字 | 2,000 | — | 1 コードポイント |
| Discord embed description | 4,096 文字 | — | — | 1 コードポイント |
| Slack メッセージ | 40,000 文字 | — | 可読性のため 2,000 未満 | 1 コードポイント |
| Pinterest ピン説明 | 500 文字 | 最初の 50-60 | 125 未満 | 1 コードポイント |
| Mastodon toot | 500 文字（設定可能） | 500 | — | 1 コードポイント |
| Bluesky 投稿 | 300 文字 | 300 | — | 1 grapheme cluster |
| Threads 投稿 | 500 文字 | 500 | — | 1 コードポイント |
| SEO meta description（Google） | デスクトップ ~160 文字 / モバイル ~120 文字 | 150-160 | 150-160 | 1 コードポイント |
| SEO ページタイトル（Google） | デスクトップ ~60 文字 / モバイル ~50 文字 | 50-60 | 50-60 | 1 コードポイント |
| Open Graph description | LinkedIn/FB で切られる前 ~200 文字 | 150-200 | 150-200 | 1 コードポイント |
| Twitter Card description | 最大 200 文字 | 200 | 150-200 | 1 コードポイント |
| SMS 単一セグメント（GSM-7） | 160 文字 | — | — | 特殊 — 下記参照 |
| SMS 単一セグメント（UCS-2 / 絵文字） | 70 文字 | — | — | 1 コードポイント |
| WhatsApp メッセージ本文 | 65,536 文字 | — | — | 1 コードポイント |
| メール件名 | プラットフォーム制限なし | デスクトップ ~60 / モバイル ~30 | 50 未満 | 1 コードポイント |
| Google Ads 見出し | 30 文字 × 15 見出し | 各 30 | 30 | 1 コードポイント |
| Google Ads 説明 | 90 文字 × 4 説明 | 各 90 | 90 | 1 コードポイント |
| App Store タイトル | 30 文字 | 30 | 30 | 1 コードポイント |
| App Store サブタイトル | 30 文字 | 30 | 30 | 1 コードポイント |
| App Store 説明 | 4,000 文字 | fold より上に最初の 252 | フック 252 | 1 コードポイント |
| Play Store 短い説明 | 80 文字 | 80 | 80 | 1 コードポイント |
| Play Store 詳細説明 | 4,000 文字 | fold より上に最初の 80 | フック 80 | 1 コードポイント |
「スイートスポット」のラインを超えるコンテンツは、切り詰められたり、ランクを下げられたり、可視カードからクロップされたりする傾向がある。X Premium 長文と Mastodon（インスタンス単位で設定可能）は、ペナルティなしに 500 文字超を書ける数少ない例外だ。上記のカウントは SMS のルールが適用される箇所を除き、すべて Unicode コードポイント単位で、絵文字 1 つは 2 文字ではなく 1 文字としてカウントされる。下書きを 6 つの主要な制限に対して一度に検証するには、文字数カウンターに貼り付ければよい。公開を押す前にプログレスバーが超過分を検出してくれる。
文字は実際にどう数えられるか（Unicode コードポイント vs UTF-16）
同じ文字列に対して、ツールごとに違う文字数が返ってくることがある。理由は、「文字」というのは単一の概念ではないからだ。Unicode コードポイントを指すこともあれば、UTF-16 のコードユニット（code unit）、grapheme cluster を指すこともあり、プラットフォームによって採用する単位が違う。
「文字」とは何か — コードポイント vs コードユニット vs grapheme
**コードポイント（codepoint）**は Unicode のスカラー値で、Unicode が文字に割り当てたか予約済みとマークした U+0000 から U+10FFFF までの任意の整数だ。**コードユニット（code unit）**はエンコーディングの最小単位で、UTF-16 は 16 ビット、UTF-8 は 8 ビットのコードユニットを使う。grapheme cluster は人間が単一の可視文字として知覚するもので、コードポイント 1 つの場合もあれば、ベースコードポイントに結合マークが付いた形、家族絵文字 👨👩👧👦（7 つのコードポイントが結合されて 1 つの可視グリフになる）のような zero-width-joiner シーケンスの場合もある。
文字列 "a🌍👨👩👧" では、三つのカウントが食い違う。
| カウント方法 | 結果 | 採用先 |
|---|---|---|
UTF-16 コードユニット（JS の string.length） | 10 | 素朴な JavaScript コード |
| Unicode コードポイント | 6 | Twitter、Instagram、SMS ゲートウェイ |
| Grapheme cluster | 3 | Bluesky、スクリーンリーダー、テキストエディタ |
string.length が絵文字について嘘をつく理由
JavaScript は内部的に文字列を UTF-16 で保持する。U+FFFF を超えるコードポイント（すべての絵文字、すべての astral-plane 文字）は、サロゲートペア（surrogate pair）、つまり 2 つの 16 ビットコードユニットとしてエンコードされる。.length プロパティはその 2 ユニットを返し、1 文字とはカウントしない。
"🌍".length // 2 (UTF-16 code units)
[..."🌍"].length // 1 (codepoints — what Twitter/SMS counts)
"🌍".match(/./gu).length // 1 (codepoints via regex with /u flag)スプレッド演算子と /u regex フラグはどちらもコードポイント単位で反復し、これは Twitter、Instagram、SMS ゲートウェイが制限と比較する単位と一致する。生の .length を使うバリデーション関数は、実際には上限内のツイートを拒否したり、もっと悪い場合は、下流システムが拒否する 285 コードポイントの下書きを通してしまうこともある。
CJK と結合マークについて
中国語、日本語、韓国語の表意文字はそれぞれ単一のコードポイントであり、どのプラットフォームでも 1 文字としてカウントされる。コストが跳ね上がるのは SMS で、GSM-7 以外の文字が 1 つでも含まれると、メッセージ全体が UCS-2 エンコーディングに切り替わり、セグメント制限が 160 から 70 に落ちる（次のセクションで扱う）。
結合マークの挙動は異なる。アクセント付き á を á と書けば 1 コードポイント、同じ á を a + ́（結合アキュート）として書けば 2 コードポイント・1 grapheme cluster だ。ほとんどのプラットフォームはコードポイントで数えるので、後者は 1 文字余計にコストがかかる。Bluesky が目に見える例外で、grapheme cluster で数えるためどちらも 1 となる。
各言語でのカウント — クイックリファレンス
// JavaScript
[...str].length // codepoints
Array.from(str).length // codepoints
// Python 3 — len() is codepoint by default
len(s)
// Go — utf8 package
utf8.RuneCountInString(s)
// Rust — chars() iterates codepoints
s.chars().count()
// Java — codePointCount
s.codePointCount(0, s.length())対比として、Base64 デコード・エンコードは逆方向の話になる。テキストを伝送のために Base64 にエンコードすると、UTF-8 入力 3 バイトごとに ASCII 出力 4 文字になるため、エンコード後の長さはコードポイント数ではなくバイト数で決まる。絵文字を 1 つ貼り付けて、Base64 出力が 8 文字に膨らむのを観察してほしい。Twitter で 1 文字としてカウントされる同じ絵文字が、UTF-8 では 4 バイトを占める。
下書きでコードポイント数（Twitter が実際に計測する数）を確認するには、文字数カウンターがデフォルトで Unicode 正確だ。
SMS 文字数制限 — GSM-7、UCS-2、マルチパートメッセージ
SMS は、絵文字を 1 つ加えるだけで請求額が文字どおり倍になりうる唯一の主要チャネルだ。理由はエンコーディングにあり、計算式は 1985 年から変わっていない。
160 文字というマジックナンバー — GSM-7 の歴史
1985 年の GSM-03.38 規格は、SMS のペイロードを 140 バイトに固定した。7 ビット文字エンコーディングなら 140 バイトに 1,120 ビット ÷ 7 = 160 文字が入る。これが有名な sms character limit 160 の由来だ。GSM-7 文字セットは 128 のベース文字に加え、10 文字の拡張（{ } [ ] | \ ~ ^ € とフォームフィードをカバー）を持つ。このセット内なら、セグメントあたり 160 文字をフルに使える。
GSM-7 の外側に出て切り替えを引き起こす文字は次のとおり。
- すべての絵文字
- 巻きクォート / スマートクォート（
""''）——これらは ASCII の直線クォート"'とは別物 - GSM-7 に含まれる 35 字を超えるアクセント付きラテン文字の大半（
é á ñ ü øなど。GSM-7 にはä ö å æ ø à è ì ò ùほか数文字のみ） - 全角句読点、CJK 文字、アラビア文字、ヘブライ文字、ギリシャ語小文字、キリル文字
- バッククォート
`とチルダ~（チルダは GSM-7 拡張表にあるので、160 字のうち 2 文字を消費する）
UCS-2 の罠 — 絵文字 1 つで 160 が 70 に落ちる
GSM-7 以外の文字がメッセージのどこかに 1 つでも現れた瞬間、メッセージ全体が UCS-2 エンコーディングに切り替わる。UCS-2 は 1 文字あたり 16 ビットを使うので、140 バイト ÷ 2 = セグメントあたり 70 文字となる。実例。
"Hello, your code is 12345" → 26 chars, GSM-7, 1 segment
"Hello, your code is 12345 ✓" → 28 chars, GSM-7 (✓ in extension), 1 segment
"Hello, your code is 12345 ✅" → 28 chars, UCS-2 (emoji), 1 segment (under 70)
"Hello, "your" code is 12345 ✅" → smart quotes + emoji → UCS-2
"Hi 你好" → CJK → UCS-2, 1 segment (5 chars)最後の Hi 你好 の例こそが落とし穴だ。たった 5 文字なのに UCS-2 料金を食い、次に追加する 65 文字までは 1 セグメントに収まり、その後セグメント 2 が始まる。
マルチパート SMS セグメント（連結）
160（GSM-7）または 70（UCS-2）を超えると、メッセージは複数のセグメントに分割される。各セグメントは再構成のために 7 文字の User Data Header（UDH）を運ぶので、セグメントあたりの利用可能ペイロードが減る。
- GSM-7 マルチパート：セグメントあたり 153 文字
- UCS-2 マルチパート：セグメントあたり 67 文字
受信側の端末は受信者に見えないかたちでセグメントを再構成する。だが課金はメッセージ単位ではなくセグメント単位だ。161 文字の GSM-7 メッセージは 2 セグメントぶんかかる。1,000 文字の GSM-7 メッセージは 7 セグメントかかる（153 × 6 = 918、7 番目のセグメントが残り 82 を運ぶ）。
コスト計算 — 絵文字 1 つで請求額が倍になるとき
80 文字のプレーンテキストのマーケティングメッセージを考えよう。
- プレーンテキスト：80 文字 → GSM-7 → 価格 X の 1 セグメント
- 絵文字を 1 つ追加：80 文字 → UCS-2 → 80 > 70 → 価格 2X の 2 セグメント
絵文字 1 つで請求額が倍になるのは現実の話で、しかもスケールする。10 万通のキャンペーン、セグメントあたり $0.0075 とすると、GSM-7 なら $750、UCS-2 なら $1,500——$750 の絵文字だ。主要な SMS プロバイダはすべて（Twilio、Bandwidth、AWS SNS、MessageBird、Vonage）この方式で課金する。エンコーディングのルールはベンダーのポリシーではなく GSM 規格だ。バイトレベルのエンコーディングのトレードオフの深い歴史と、なぜ ASCII / UTF-8 / UCS-2 が別個の規格として存在しているのかについては、Base64 を理解するで扱っている。SMS ではなくメールに適用された、同じ「ビットを文字にする」系の問題だ。
メッセージを GSM-7 に保つ方法
- スマートクォートではなく ASCII の直線クォート
"'を使う - em-dash
—や en-dash–ではなく ASCII ハイフン-を使う ©や®ではなく(c)、(R)と綴る- キャンペーン予算が UCS-2 コストを織り込んでいない限り、絵文字を避ける
- プロバイダのコンソール（Twilio、Bandwidth、MessageBird など）はプレビューの隣に「encoding: GSM-7」または「UCS-2」と表示する。配信前に必ず確認する
下書き中の最速のサニティチェックは、文字数カウンターの SMS プログレスバーで、これは 160 文字基準に対して報告する。テキストが UCS-2 をトリガーするなら、文字数を 2.29 で割って 70 字ルール下のセグメント数を概算すればよい。
SEO 制限 — Meta description、タイトルタグ、OG、Twitter Card
SEO の文字数制限はプラットフォーム制限よりもソフトだ。Google は meta description が 300 文字になっても拒否はしない。だが実用上の切り詰めルールはクリックスルー率に効いてくる。2026 年でも通用する数字は次の通り。
Meta description — 150-160 文字のスイートスポット
Google のデスクトップ検索結果は meta description を 155-165 文字あたりで切り詰める。モバイルは 100 から 120 のあいだのどこかで切る。正確な切り詰めポイントが揺れるのは、Google が表示ピクセルを計測しており、文字数を計測していないからだ。W や M のグリフだらけの説明文は、i や l だらけのものより早く切り詰めピクセルに達する。
実用的なライティング規則。
- 合計 150-160 文字を狙う
- 中核メッセージを最初の 120 文字に置く（モバイルセーフ）
- ページの meta description character limit キーワードを最初の 30 文字に置いてリードする
- 最後の 30 文字に CTA を置いて締める。デスクトップが中央を切っても読める
2017-2018 年の時期、Google は一時的に meta description の表示を 320 文字に拡大しており、当時の SEO チュートリアル世代はいまだにこの数字を引用している。Google は 2018 年半ばに 160 に戻した。今 200 文字を超えて書いても、後半が隠れるだけだ。
別の失敗パターンもある。120 文字未満の説明文は、まるごと差し替えられることが多い。Google は「あなたの説明文はクエリに完全には応えていない」と判断し、ページ本文から別のパッセージを引っ張ってくる。警告なしに CTR コントロールを失う。
タイトルタグ — デスクトップ 60、モバイル 50
タイトルタグはデスクトップで約 60 文字、モバイルで約 50 文字で切れる。説明文と同じピクセルベースの切り詰めで、ワイドグリフについての注意点も同じだ。
スイートスポット：50-60 文字、ターゲットキーワードを最初の 30 文字に置けば、どんな切り詰めにも生き残る。ロングテールのブランドサフィックス（| Brand Name）は末尾、つまり切り詰めの痛みが最も小さい場所に置くのがよい。
ピクセル幅 vs 文字数 — Google の実際の規則
Google の SERP の説明文コンテナはデスクトップで約 920 ピクセル幅だ。平均的な文字幅は約 6.5 ピクセルで、これが経験的な目標 140-160 文字を生む。だが文字あたりの広がりは大きい。i は約 3 ピクセル、M は約 11 ピクセルでレンダリングされる。全大文字のコピー（“BEST WIDGETS FOR WINTER WEDDINGS”）は、小文字版よりずっと早く切れる。
SEO コピーには、文字数カウンターよりピクセル正確な SERP シミュレータによる公開前プレビューのほうが信頼できる。
OG description と Twitter Card description
Open Graph プロトコルの og:description は、Facebook、LinkedIn、Slack、Discord が共有リンクのプレビュー下に描画するものだ。表示上限はプラットフォームによって異なり、多くは約 200 文字で切れ、一部は 300 まで延びる。Twitter Card の twitter:description は Twitter のパーサーで 200 文字にハードキャップされている。
合理的なデフォルト。
- OG と Twitter Card の両方で 150-200 文字
- meta description と同じにしてもよいが、OG の長さは検索ランキングに影響しないので OG は少し長めにできる
- 構造化データの選択（特に誤って OG に引かれてくるもの）の検証には、セキュリティのベストプラクティスで扱うパターンを使う。信用できない OG メタデータはよくあるフィッシングのベクタだ
「文字数制限なし」が実際に意味するもの
H1 タグ、本文コンテンツ、URL slug にはプラットフォーム強制の SEO 文字数制限はないが、ソフトな上限は依然として適用される。
- H1 が 70 文字を超えると、視覚的階層とスキャナビリティが崩れる
- URL slug は技術的には無制限。Google は SERP で約 90 文字を表示し、それ以上は装飾扱い
- 本文の長さに上限はないが、Google は水増しではなく有用なコンテンツを評価するので、単語数だけではランキングシグナルにならない
文字数カウンターは、ドラフト中に meta description（160）とタイトルタグ（60）の両方をリアルタイムに追跡し、切り詰めピクセルに近づくとプログレスバーが黄色から赤に変わる。
ソーシャルプラットフォーム — Twitter/X、Instagram、LinkedIn、Facebook ほか
各プラットフォームの文字数の天井には、その背景にある経緯と、ハード制限の下に位置する「コンテンツが実際にパフォーマンスするスイートスポット」がある。
Twitter / X — 280、Premium 25,000、URL 置換ルール
標準の twitter character limit は 280 文字で、2017 年 11 月に 140 から倍増した。X Premium 加入者は 25,000 文字までのリッチフォーマット対応の長文を投稿できるが、オーガニックリーチではいまだに 280 文字の投稿が支配的な形だ。
自明でないルールが URL 置換だ。Twitter は公開時にすべての URL を——どれだけ長くても——23 文字の t.co 短縮リンクに包む。23 文字というコストは固定だ。
published_length = raw_length − URL_length + 23例："Check this: https://example.com/very-long-path?id=12345" という下書きは生で 53 文字。URL は 38 文字なので 23 文字の t.co リンクに置き換えられ、公開後の長さは 53 − 38 + 23 = 38 文字になる。気付かなかった 15 文字の節約だ。
長い URL を下書きに貼り付けるとき、URL エンコード・デコードは何が URL としてカウントされるかを素早く確認する手段になる（Twitter は RFC 3986 のパターンで URL を認識し、クエリ文字列とフラグメントも含む）。サブドメイン、スキーム、ポート、パス、クエリ、フラグメントはすべて 23 文字の置換に飲み込まれる。
その他の Twitter のフィールド：表示名 50 文字、bio 160 文字、ハンドル 15 文字。Threads（Meta の Twitter 相当）は代わりに 500 文字制限を採用している。
Instagram — 2,200 のキャプション、ハッシュタグ 30、125 文字のフック
Instagram のキャプションは 2,200 文字まで許されるが、フィードに見えるのは最初の 125 文字だけで、残りは「…もっと見る」のタップの裏に折り畳まれる。読者の半数以上はタップしない。エンゲージメントに効く instagram caption limit は実質 125 で、ハード制限 2,200 ではない。
ハッシュタグ 30 個の上限はハードだ。31 個目を試みると投稿が失敗する。5-10 個のハッシュタグの範囲が最もパフォーマンスする傾向にあり、11 個を超えると発見ブーストが頭打ちになり、アルゴリズムからはスパムっぽく見え始める。
その他のフィールド：bio 150 文字、表示名 30 文字、DM 1,000 文字。
LinkedIn — 3,000 の投稿、1,300 のスイートスポット、「see more」のフォールド
投稿の linkedin character limit は 3,000 文字だが、フィードは「see more」フォールドの前で最初の 210 文字だけを表示する。LinkedIn で勝つ投稿は 1,200-1,500 文字の範囲にある（複数の Buffer や Hootsuite の調査がピークとしてだいたい 1,300 に収束している）。価値を示すには十分長く、スクロールに疲れさせないには十分短い。
LinkedIn Articles（長文出版面）は 110,000 文字を許す。事実上無制限だ。プロフィールの見出しは 220 文字、about セクションのテキストは 2,600 文字でキャップされる。
Facebook — 63,206 文字、オーガニックは 80 文字スイートスポット
Facebook の 63,206 文字の投稿上限は雑学に近い。実際には 80 文字未満の投稿は長い投稿より約 30% 高いオーガニックエンゲージメントを得る（HubSpot がこれを毎年安定して報告している）。fold より上ではデスクトップで約 477 文字、モバイルは約 125 文字で切れる。
コメントの最大は 8,000 文字。リアクション、シェア、クリックスルーはすべて短い投稿に偏るので、長いコピーはリンク先の記事に置き、Facebook のキャプションには置かない。
新興プラットフォーム — Bluesky、Mastodon、Threads、TikTok
- Bluesky の投稿は 300 文字でキャップされ、特殊なケースだ。Bluesky は grapheme cluster で数えるので、7 コードポイントの家族絵文字 👨👩👧👦 は 7 文字ではなく 1 文字としてカウントされる
- Mastodon はデフォルトで toot あたり 500 文字だが、インスタンス管理者は 5,000、あるいは無制限まで引き上げられる。投稿先のインスタンスを確認すること
- Threads は Twitter スタイルの 500 文字制限でコードポイントカウントを採用
- TikTok のキャプションは 2,200 文字を許し、fold より上に約 100 文字が表示される
Reddit、Discord、Slack — 長文とコミュニティのデフォルト
- Reddit のタイトルは 300 文字（subreddit のモデレータが AutoModerator で 60 未満を強制することが多い）、コメントは 10,000 文字
- Discord の標準メッセージは 2,000 文字、embed description は 4,096、Nitro はプレーンメッセージで 4,000 まで引き上げる
- Slack のメッセージは 40,000 文字。2,000 を超えると可読性が急落し、多くの受信者は長いメッセージを無視する
コンテンツタイプ別の単語数ターゲット
文字数制限はソーシャルと SEO を支配し、単語数はそれ以外のすべて——学術、課金、コンテンツマーケティング、長編原稿——を支配する。以下の表は、各代表的コンテンツタイプの目標範囲と読了時間の推定値（230 wpm、Brysbaert 2019 黙読メタアナリシス中央値）を示す。
| コンテンツタイプ | 単語ターゲット | 読了時間 @ 230 wpm | 備考 |
|---|---|---|---|
| ツイート | 30-40 単語 | 10 秒 | 単語ではなく文字で最適化 |
| LinkedIn 投稿（スイートスポット） | 170-250 単語 | 1 分 | fold より上 |
| Instagram キャプション（フック） | 20-25 単語 | 10 秒未満 | 最初の 125 文字 |
| ブログ — 短い | 500-700 単語 | 2-3 分 | リスト記事、ニュース、ホットテイク |
| ブログ — 標準 | 1,000-1,500 単語 | 4-7 分 | チュートリアル、深掘りガイド |
| ブログ — 長い | 2,000-3,000 単語 | 9-13 分 | 包括的ガイド |
| SEO ピラーページ | 2,500-5,000 単語 | 11-22 分 | トピカルオーソリティ |
| 学術エッセイ（高校） | 500-1,500 単語 | 2-7 分 | 課題により変動 |
| 学術エッセイ（大学学部） | 1,500-3,000 単語 | 7-13 分 | 課題により変動 |
| NaNoWriMo デイリー | 1,667 単語/日 | — | 30 日で 50K 単語 |
| 小説 — 短い | 50,000-70,000 単語 | — | YA、ミステリー |
| 小説 — 標準 | 80,000-100,000 単語 | — | 大人向けフィクション |
| 講演（12 分 @ 130 wpm） | 1,500-1,600 単語 | 発話 | リハーサルで確認 |
| ポッドキャストエピソード（30 分 @ 130 wpm） | 3,900 単語 | 発話 | 台本部分 |
コンテンツマーケティングでは、読了時間のほうが単語ターゲットより有用な単位だ。読者は「5 分で読める」というラベルに、「1,150 単語」というラベルよりも安定して反応する。単語数は依然として、課金（翻訳は原文単語あたりで請求される）、プラットフォーム遵守（NaNoWriMo の 50K、学術の 2,000 単語上限）、契約条件の単位として残る。文字数カウンターは入力中にこの両方をリアルタイム表示し、講演やポッドキャスト用に 130 wpm での発話時間も併せて表示する。
実プロダクトを壊す 6 つのカウントミス
これらは実稼働のコードや、実施済みのマーケティングキャンペーンで繰り返し目にする失敗だ。各項目で症状、根本原因、修正をセットにしてある。
ミス 1：文字数バリデーションに string.length を使う
症状： ユーザーが絵文字 3 つ入りのツイートを貼り付ける。実際には 270 コードポイントだ。フロントエンドのバリデーションは 276 と表示し送信を拒否する。あるいは、もっと悪いことに、絵文字の予算が相殺して 285 コードポイントの下書きが通過し、Twitter がサーバー側で拒否する。
根本原因： JavaScript の String.prototype.length は UTF-16 コードユニットを返す。すべての絵文字はサロゲートペアで、2 ユニットを消費する。すべての astral-plane 文字（数学記号、古代文字）も同様だ。
修正： スプレッド演算子または Array.from でコードポイント単位に反復する。
// ❌ wrong
function isUnderTwitterLimit(text) {
return text.length <= 280;
}
// ✅ correct
function isUnderTwitterLimit(text) {
return [...text].length <= 280;
}regex ベースのコードポイント反復パターン（grapheme cluster 対応を含む）の詳細は、正規表現チートシートで /u と /v フラグ、Unicode プロパティエスケープを扱っている。
ミス 2：単語数のために CJK テキストを空白で分割する
症状： 500 文字の中国語記事が 1 単語と報告される。それに基づいた翻訳の見積もりが 500 倍ずれる。
根本原因： CJK 言語は単語間スペースを使わない。text.split(/\s+/) はエッセイ全体を含む単一のトークンを返す。
修正： CJK 表意文字 1 つを 1 単語として数える。これは Microsoft Word、Google Docs、すべてのネイティブ CJK ワープロが採用する慣習だ。
function countWordsMixed(text) {
const cjk = (text.match(/[一-鿿-ヿ가-]/g) || []).length;
const latin = (text
.replace(/[一-鿿-ヿ가-]/g, ' ')
.match(/[A-Za-z0-9]+(?:['’-][A-Za-z0-9]+)*/g) || []).length;
return cjk + latin;
}Unicode 範囲は CJK 統合漢字（U+4E00 から U+9FFF）、ひらがなとカタカナ（U+3040 から U+30FF）、ハングル音節（U+AC00 から U+D7AF）をカバーする。これは Microsoft Word の単語数機能が表意文字としてカウントする 4 つのブロックだ。
ミス 3：Twitter の URL 23 文字置換を忘れる
症状： カウンターは 80 文字の URL を含む 320 文字の下書きを表示する。10 分かけてトリミングしてようやく、オリジナルが 263 文字として Twitter に受け入れられたはずだったことに気付く。
根本原因： Twitter は公開時にすべての URL を 23 文字の t.co リンクに置き換える。生のカウンターはそれを知らない。
修正： 各 URL について raw − URL_length + 23 で公開後の長さを事前計算する。複数 URL を含む下書きでは、補正を合算する。公開コンテンツでの URL 検出は RFC 3986 に従う。URL エンコード・デコード ガイドが同じ解析ルールを順に説明している。
ミス 4：meta description を 320 文字で書く（古いガイドライン）
症状： 末尾に CTA を据えた 280 文字の meta description を仕上げた。Google の検索結果では、説明文は 158 文字目で文の途中で切れ、CTA は決して現れない。
根本原因： 2017 年 12 月から 2018 年 5 月のあいだ、Google は一時的に meta description の表示を 320 文字に拡大した。多くの SEO チュートリアルが今もこの数字を引用している。Google は 2018 年半ばに約 160 に戻し、それ以来そこに留まっている。
修正： 150-160 文字で書く。プライマリキーワードを最初の 30 文字に、CTA を最後の 30 文字に置く。重要なページにはピクセル正確な SERP シミュレータを使う。ワイドグリフ（W、M、K）は狭いグリフ（i、l、t）よりも予算を早く食いつぶす。
ミス 5：280 文字を 280 単語と混同する
症状： チームの誰かが「280 単語のツイートが必要」と書き、見事な散文で 1,500 文字を仕上げる。そのツイートは投稿できない。
根本原因： 文字 vs 単語の混同。英文の散文では、両者はおおむね 5-6 倍違う。
修正： プラットフォーム単位でルールを固定する。Twitter、SMS、SEO meta は文字を数える。NaNoWriMo、学術課題、翻訳契約、大半のコンテンツマーケティングのブリーフは単語を数える。迷うときは仕様を確定する前にプラットフォーム自身のカウンター（Twitter の作成ボックス、Word の「校閲 > 文字数カウント」）を確認する。
ミス 6：スマートクォートを貼り付けて SMS を静かに UCS-2 に切り替える
症状： Google Docs から顧客レシートのテンプレートを SMS 送信機にコピーする。オリジナルは 145 文字、GSM-7 で 1 セグメントとして送信されていた。貼り付け後も同じ 145 文字だが、UCS-2 で 2 セグメント請求される。100 万通のキャンペーンで費用が倍になる。
根本原因： Google Docs と Word は " や ' を活字家のクォート " " ' ' に自動変換する。それらのクォートは GSM-7 文字セットに含まれていないので、メッセージ全体が UCS-2 に切り替わる。
修正： 送信前に正規化する。
function toGsm7Quotes(s) {
return s
.replace(/[“”]/g, '"') // " " → "
.replace(/[‘’]/g, "'") // ' ' → '
.replace(/[–—]/g, '-'); // – — → -
}課金に関わる送信の前にこれを走らせる。Twilio、MessageBird、Bandwidth はすべて応答にエンコーディングフィールドを出す。ログを取り、GSM-7 として意図したテンプレートに UCS-2 が現れたらアラートを上げる。
FAQ
文字数と単語数の違いは何か
文字数は、スペース、句読点、絵文字を含むすべての文字を数え、現代のほとんどのプラットフォームでは Unicode コードポイントで計測される。単語数は、ラテン系スクリプトでは空白区切りのトークン、CJK では表意文字 1 つを 1 単語として数える。Twitter、SMS、SEO meta description は文字数を使う。学術エッセイ、NaNoWriMo の原稿、翻訳請求書は単語数を使う。
Twitter は絵文字を 1 文字として数えるのに、JavaScript が 2 文字として数えるのはなぜか
Twitter は Unicode コードポイントで計測する。絵文字 1 つはコードポイント 1 つで、1 文字だ。JavaScript の string.length は UTF-16 コードユニットを計測する。多くの絵文字は U+FFFF より上にあり、UTF-16 ではサロゲートペアとしてエンコードされるので 2 コードユニットを取り、.length は 2 を返す。Twitter が実際に数えるコードポイント数を得るには [...text].length や Array.from(text).length を使う。
SMS の文字数制限が 160 のときと 70 のときがあるのはなぜか
SMS はデフォルトで 7 ビットの GSM-7 エンコーディングを使い、140 バイトのペイロードに 160 文字が入る。メッセージに GSM-7 にない文字（絵文字、スマートクォート、CJK、ごく一部以外のアクセント付きラテン）が 1 つでも含まれると、メッセージ全体が 16 ビットの UCS-2 エンコーディングに切り替わり、セグメントあたりの制限が 70 文字に落ちる。メッセージ内のどこか 1 か所に絵文字があるだけで切り替えがトリガーされる。
2026 年における meta description の理想的な長さは
150-160 文字を狙う。Google のデスクトップ SERP は表示ピクセル幅に応じて 155-165 あたりで切り詰めるし、モバイルは 100 から 120 のあいだで切る。120 文字未満では、Google はあなたの説明文をページ本文のパッセージでまるごと置き換えることが多い。プライマリキーワードを最初の 30 文字に、CTA を最後の 30 文字に置けば、どちらの方向に切り詰められてもメッセージが生き残る。
文字数制限にはスペースや絵文字も含まれるか
実質的にあらゆるプラットフォームで含まれる。スペース、改行、句読点、絵文字はそれぞれ Unicode コードポイント 1 つとして数えられる。知っておくべき例外は二つある。前述の通り絵文字がエンコーディング切り替えをトリガーする SMS、そして grapheme cluster で数える Bluesky だ。Bluesky では家族絵文字 👨👩👧👦 のような複数コードポイントの絵文字も 7 文字ではなく 1 文字で済む。
中国語、日本語、韓国語のテキストでは単語数はどう計算されるか
CJK 表意文字 1 つを 1 単語として数える。これは Microsoft Word の中国語モードの単語数機能、Google Docs、ネイティブの CJK エディタ、すべての商用翻訳メモリシステムが採用する慣習だ。500 文字の中国語エッセイは 500 単語と報告される。混在テキストは、CJK 表意文字を文字単位、ラテン系トークンを空白単位で数え、両者を合算する。
Twitter は 280 文字制限内で URL の長さをどう扱うか
Twitter は元の長さに関係なく、公開時にすべての URL を 23 文字の t.co 短縮リンクに自動的に包む。公開後の長さは URL ごとに published = raw − URL_length + 23 の式に従う。100 文字の URL を 1 つ含む 320 文字の下書きは、243 文字として送信される。Twitter は RFC 3986 のパターンで URL を認識するので、クエリ文字列とフラグメントも URL トークンに吸収される。
関連記事
- 正規表現チートシート — 文字バリデーションのためのパターンマッチング、Unicode プロパティエスケープ
- テキスト差分オンライン ガイド — 二つのテキストを行単位、文字単位で比較する
- URL エンコード・デコード ガイド — テキストが URL を通るときの文字エスケープルール
- Base64 を理解する — メールとバイナリデータに適用される「ビットを文字にする」エンコーディングのもう半分