文字数カウント完全攻略 — 原稿・英文・画像 OCR

そもそも何を「1 文字」と数えるか

文字数カウントの話を始める前に、いちばん根っこの問いからいきましょう。「1 文字」というのは、いったい何を 1 と数えているのでしょうか？ 答えは一つではありません。言語・用途・技術レイヤーのどこに立つかで、同じ文字列でも数え方がまったく違ってきます。ここがブレると、後の議論がすべてブレるので、最初に全体地図を描いておきます。

大きく分けると、世界の言語は「文字ベースで数える言語」と「単語ベースで数える言語」の 2 系統に分かれます。日本語・中国語・韓国語・タイ語・ラオ語などは前者で、1 つの表意文字（漢字・仮名・ハングルなど）が強い意味を持つため、文字数が分量の主な指標になります。原稿用紙に「400 字詰め」「800 字詰め」という区切りがあるのもこの文化圏ならではです。一方、英語・ドイツ語・フランス語などのヨーロッパ言語では「単語」が最小の意味単位とされ、word count（ワード数）が分量指標の主役です。エッセイは「1500 ワード」、論文は「6000 ワード」、新聞記事は「800 ワード」のように、字数ではなく単語数で設計されます。

さらにプログラマ目線で見ると、同じ文字列に対して 2 つの技術的な数え方が存在します。1 つは「Unicode コードポイント数」で、これは文字列を構成する内部的な記号の個数。もう 1 つは「書記素クラスタ（grapheme cluster）数」で、これはユーザーが「1 文字」として知覚する視覚単位の個数です。普段は両者が一致しますが、絵文字や結合文字が絡むと一致しません。たとえば家族絵文字 👨‍👩‍👧‍👦 は、コードポイントで見ると男・女・女の子・男の子の 4 文字と 3 つの ZWJ（ゼロ幅接合子）で合計 7 コードポイント、ですが書記素クラスタとしては 1 文字です。

そして最後に、用途やプラットフォーム固有の「その世界のローカルルール」があります。X（旧 Twitter）は日本語 1 文字を「半角 2 文字分」として数え、英字はそのまま 1 文字として扱う独自の計算方式を持っています。Google の検索結果は「表示ピクセル幅」で切り詰められ、文字数ぴったりでは切れません。Word の「文字数カウント」機能と、ブラウザの string.length の結果も違う値を返します。要するに「カウントの正解」は場面ごとに分かれていて、どの基準で数えたいのかを意識することが第一歩なのです。

日本語の字数（原稿用紙・スペース込み / 除く）

まずは日本語の字数カウントから整理しましょう。日本の書き物の世界では「400 字詰め原稿用紙」というフォーマットが長く基準として使われてきました。20 字 × 20 行 = 400 文字、1 ページあたりちょうど 400 字というシンプルな設計です。紙の原稿用紙を使わなくなった現在でも、小説の分量は「原稿用紙換算で〇〇枚」という表現が広く残っています。原稿用紙 1 枚 = 400 字、10 枚 = 4000 字、100 枚 = 4 万字。短編小説がだいたい 20〜80 枚、中編が 100〜300 枚、長編が 500 枚以上、という感覚です。

ここで悩ましいのが「原稿用紙換算では何をどう数えるのか」という問題です。厳密に言うと、原稿用紙のマスは「1 マス 1 文字」のルールで、句読点（、。）、カギカッコ（「」）、記号類もそれぞれ 1 マス使います。段落の先頭の 1 字下げも 1 マス分。そのため、紙の原稿用紙では「本文字数＋句読点＋記号＋改行関連の空白マス」を全部含めた総マス数が、実質的な分量になります。

一方で、デジタルの「文字数カウント」ツールでは、扱いがツールによって分かれます。典型的には 「スペース込み」と「スペース除く」の 2 つのカウントを同時に出すのが標準的です。「スペース込み」は半角スペース・全角スペース・タブを 1 文字と数えた総数、「スペース除く」はそれらを除いた純粋な本文の字数。原稿用紙換算に使うなら「スペース込み」、純粋なテキスト量の目安として使うなら「スペース除く」が近い値になります。

もうひとつ悩みがちなのが 改行の扱いです。改行文字（\n）は通常 1 文字として内部的にはカウントされますが、多くの文字数ツールでは「改行は文字に含めない」のがデフォルトです。これは「改行は分量というより構造（段落の区切り）」と見なすためで、この方針が自然に受け入れられています。ただし CSV や JSON のようなデータ形式で厳密な文字数が必要な場合は、改行コードも含めた Unicode 視点のカウントを使う必要があります。

半角・全角の扱いも場面で違います。原稿用紙のルールでは「英字 2 文字で 1 マス」とすることが多いですが、デジタルのツールでは「半角英数も 1 文字、全角仮名も 1 文字」と統一して数えるのが普通です。X のような SNS では「日本語 1 文字 = 英字 2 文字」という独自の重みづけがあり、後述するようにプラットフォームごとの癖を把握しておかないと「140 文字のはずなのに投稿できない」といった混乱を招きます。ベンリーの 文字数カウントは、スペース込み・スペース除く・行数・原稿用紙換算枚数を同時に表示するので、ブログや記事を書くときの「ざっくり分量把握」に便利です。

Unicode コードポイント基準

次はプログラマ視点での「1 文字」の話です。世界中の文字を 1 つの大きな表にまとめようとしたのが Unicode で、その表上の各文字に割り振られた番号が「コードポイント（code point）」です。たとえば平仮名の あ は U+3042、漢字の 日 は U+65E5、ラテン文字の A は U+0041。Unicode は 10 万を超える文字を収容できるよう U+0000 から U+10FFFF まで、約 110 万コードポイント分の「部屋」を用意しています。

ここで話がややこしくなるのが、Unicode コードポイントを実際のメモリやファイルに格納するときの「エンコーディング」です。現在もっともよく使われているのは UTF-8・UTF-16・UTF-32 の 3 つで、それぞれ 1 コードポイントを何バイトで表すかのルールが違います。UTF-8 は可変長で 1〜4 バイト、UTF-16 は 2 または 4 バイト、UTF-32 は固定 4 バイト。Web の世界は UTF-8 で統一されつつあり、HTML・JSON・メール・ソースコードの大半は UTF-8 で書かれています。

問題は、プログラミング言語の文字列型が内部でどのエンコーディングを使っているかが言語ごとに違うことです。JavaScript の String は UTF-16 の「コードユニット数」を .length で返します。つまり U+0000〜U+FFFF の範囲（基本多言語面、BMP）の文字は 1、それ以外のサロゲートペアが必要な文字（絵文字・数学記号・古代文字など）は 2 としてカウントされます。

// JavaScript の落とし穴
'a'.length        // → 1
'あ'.length       // → 1 (BMP 内)
'𝄞'.length       // → 2 (音楽記号、BMP 外でサロゲートペア)
'😀'.length       // → 2 (絵文字もほとんど BMP 外)
'𩸽'.length      // → 2 (ほっけ、U+29E3D)

// コードポイント単位で数えたいなら
[...'𝄞'].length   // → 1 (スプレッドで反復)
[...'😀'].length  // → 1
Array.from('𩸽').length // → 1

JavaScript で「ユーザーから見た文字数」に近い値が欲しい場合、単純な .length は絶対に使ってはいけません。上記のようにスプレッド演算子（[...str]）や Array.from(str) を使うと、反復子がコードポイント単位で動くので正しいコードポイント数が得られます。

一方、Python 3 の len() は素直にコードポイント単位です。len('あ') = 1、len('𝄞') = 1、len('😀') = 1。Python 2 の時代は str がバイト列で unicode 型が別に存在する混乱した世界でしたが、Python 3 ではすべて Unicode ベースで統一されました。この違いを知らずに JavaScript から Python に移ると「どうしてこっちは正しく数えるんだ？」と驚くことになります。

Ruby・Go・Rust・Swift もそれぞれ独自の流儀があります。Go では len(s) が UTF-8 のバイト数、utf8.RuneCountInString(s) がコードポイント数。Swift の String は最初から書記素クラスタ単位で数えてくれる、かなり進んだ設計になっています。言語によって「1 文字」の定義が違うことを知らずにコードを移植すると、文字数バグが混入しやすいので注意してください。

書記素クラスタ（絵文字・結合文字）

コードポイント単位で数えても、まだ「ユーザーが見た目で 1 文字と感じる単位」には届きません。その最後のレイヤーが 書記素クラスタ（grapheme cluster）です。Unicode の公式定義では、書記素クラスタとは「一般的なユーザーが 1 つの文字と考える視覚上の単位」を指します。言い換えれば、画面の 1 マスに表示される単位です。

書記素クラスタとコードポイント数がずれる代表例は次のとおりです。まずは 結合文字。たとえば濁点付きの が は、合成済みの 1 コードポイント U+304C として表すこともできるし、か（U+304B） + ◌゙（U+3099、濁点）の 2 コードポイントで合成することもできます。前者は NFC（正規形合成済み）、後者は NFD（正規形分解）と呼ばれます。見た目は同じ「が」でも、コードポイント数が 1 か 2 かは内部表現次第です。macOS のファイル名は歴史的経緯で NFD 寄りに保存される傾向があり、Windows・Linux の NFC とやり取りすると「同じファイル名なのにマッチしない」というトラブルが起きがちです。

次に 絵文字のゼロ幅接合子（ZWJ、U+200D）シーケンス。現代の絵文字は「基本絵文字を ZWJ でつなげて合成する」仕組みを採用しており、見た目は 1 つの絵文字でも内部は複数コードポイントで構成されます。代表例が 👨‍👩‍👧‍👦（家族 4 人）で、これは 👨 + ZWJ + 👩 + ZWJ + 👧 + ZWJ + 👦 の計 7 コードポイントですが、書記素クラスタとしては 1 文字です。国旗絵文字も同様で、🇯🇵 は 🇯（regional indicator J） + 🇵（regional indicator P）の 2 コードポイント 1 書記素、👩🏽‍💻（女性ハッカー・中間肌色）は 👩 + 肌色修飾子 + ZWJ + 💻 の 4 コードポイント 1 書記素、という具合です。

では書記素クラスタを正しく数えるにはどうするか。モダンブラウザとモダン Node.js には Intl.Segmenter という API が用意されており、これで正しい書記素単位の分割ができます。

// Intl.Segmenter で書記素単位にセグメント化
const seg = new Intl.Segmenter('ja', { granularity: 'grapheme' });

function graphemeLength(str) {
  return [...seg.segment(str)].length;
}

graphemeLength('あ');           // → 1
graphemeLength('👨‍👩‍👧‍👦');          // → 1  (7 コードポイントだが 1 書記素)
graphemeLength('🇯🇵');          // → 1
graphemeLength('👩🏽‍💻');         // → 1
graphemeLength('a\u0301');      // → 1 (a + コンビネーションアクセント)

Intl.Segmenter は第 1 引数にロケール、第 2 引数に granularity（'grapheme' / 'word' / 'sentence'）を指定します。'word' を指定すると単語単位、'sentence' を指定すると文単位で分割できるので、英文のワード数・センテンス数を正しく数えたいときにも便利です。古いブラウザには存在しないので、必要ならポリフィルやライブラリ（grapheme-splitter など）を併用します。

下の比較表で、典型的な文字列がそれぞれの数え方でいくつになるかを一覧しておきます。

同じ「1 文字」と言っても、実装レベルでは数値が最大で 10 倍以上ずれることが分かります。ベンリーの 文字数カウントは 書記素クラスタ単位でカウントするよう実装しているので、絵文字や家族絵文字を入れてもユーザーの直感どおりの数値が出ます。

英文の単語数・センテンス数

英語圏の文章では、分量の基本単位は「文字」ではなく「単語（word）」です。大学のエッセイ課題は「1500 words」、ビジネス文書のブログ記事は「600〜800 words」、学術論文のアブストラクトは「250 words 以内」、TED トークの原稿は「1000〜1500 words」のように、ワード数でサイズが規定されます。日本語に翻訳すると 1 ワードあたり 2.0〜2.5 倍の字数になる、という経験則があるので、英文 1000 ワードは日本語訳で 2000〜2500 字くらい、と換算すると感覚が合います。

ワードカウントの基本ルールはシンプルで、空白文字で区切られた塊を 1 ワードと数えます。JavaScript で素朴に実装するなら：

// 単純なワードカウント
'hello world'.split(/\s+/).filter(Boolean).length;
// → 2

'The quick brown fox jumps over the lazy dog'
  .split(/\s+/).filter(Boolean).length;
// → 9

// 連続する空白や先頭末尾の空白にも強い書き方
function wordCount(text) {
  return text.trim().split(/\s+/).filter(Boolean).length;
}

split(/\s+/) で連続する空白もまとめて区切り、filter(Boolean) で空文字列要素を除外する、という定石です。これで「前後に空白がある」「タブや改行が混じっている」場面でも安全にカウントできます。ただし it's のようなアポストロフィを含む単語や、well-known のようなハイフン付き語、U.S.A. のようなピリオド付きの略語などは、別のルールで分割されると困ることがあるので、厳密なカウントが必要な場合は Intl.Segmenter の 'word' モードを使う方が安全です。

センテンス数（文の数）は、ピリオド・疑問符・感嘆符で区切ります。

// 素朴なセンテンス分割
'Hello. How are you? Fine!'
  .split(/[.!?]/).filter(Boolean).length;
// → 3

もちろんこれは Dr. や e.g.、3.14 のようなピリオドも 1 文の終わりとして扱ってしまう素朴な実装で、本物の自然言語処理では「略語辞書」や機械学習モデルを使って区切ります。それでも「おおよその文数」をつかむだけならこの素朴版で十分実用になります。

段落数は連続する改行で区切るのが一般的で、split(/\n\s*\n/) のように「空行」を区切りに使います。英文エッセイの構造分析では「1 段落 3〜5 文、1 文 15〜25 ワード、合計 5 段落」といった目安がよく出てきます。ベンリーの ワードカウントツールは、ワード数・センテンス数・段落数・文字数を一度に表示するので、英文エッセイの分量調整に使うのが向いています。

SNS 文字数制限（X / Threads 等）

SNS に投稿するときに避けて通れないのが「文字数制限」です。プラットフォームごとに上限が違い、さらにカウント方式も微妙に違うので、投稿前に「今の文面は何文字なのか」を把握しておくのが大人の嗜みです。主要な SNS の制限を表にまとめます。

X のカウント方式がとくに独特で、英語圏と日本語圏で扱いが違うのは前述のとおりです。具体的には「CJK Unified Ideographs（漢字）」「ひらがな」「カタカナ」「ハングル」などの範囲の文字は 1 文字あたり 2 重み、それ以外の文字は 1 重み、として総重みで 280 を上限にしています。つまり「純粋な日本語文は 140 文字（= 280 重み）」、「英語文は 280 文字」、「日英混在文はその中間」という一貫した計算になるわけです。この方針はオープンソース化されており、twitter-text という公式ライブラリで誰でも同じロジックを再現できます。

Mastodon や Misskey のような分散型 SNS では、文字数制限は「インスタンス（サーバー）ごとに管理者が設定する」方式です。標準値は 500 / 3000 ですが、フォークされた実装ではさらに長い上限を設けているインスタンスもあり、「あちらのインスタンスでは通るけど、こちらでは弾かれる」現象が発生します。フェデレーション（連合）で相手インスタンスに投稿が届いたときに、相手側の上限で切り詰められる可能性もあるので、長文を投稿するときは気をつけましょう。

ベンリーの 文字数カウントは、日本語の原稿用紙ベースの字数を表示しますが、SNS 投稿前のチェックには「スペース込み」の数値を参照するのがいちばん近いです。本格的に X の重み計算を再現したい場合は、公式の twitter-text ライブラリを組み込んだ専用ツールを使ってください。

SEO メタディスクリプション文字数の目安

もうひとつ「文字数を気にする代表的な場面」が、ウェブサイトの SEO（検索エンジン最適化）です。<title> タグと <meta name="description"> タグは、Google の検索結果に表示される「青いリンクと黒い説明文」になるため、長すぎても短すぎても不利になる、という微妙なバランスが要求されます。

まず title タグは、全角 30〜35 文字、半角で 60〜65 文字が一般的な目安です。Google は title を「ピクセル幅」で切り詰めており、PC 版の検索結果ではだいたい 600 ピクセル前後が限界とされています。全角の日本語文字はピクセル幅が大きいので、半角換算より短い文字数で切れてしまうのです。逆に半角英数主体の英語タイトルは 60 文字超でも収まることがあります。

meta description の目安は 全角 120 文字、半角 160 文字程度。Google は検索クエリに応じて表示位置を動的に変えることが多いので、「最重要キーワードを先頭 50〜60 文字に入れる」のがコツです。長すぎると末尾が切れ、短すぎるとクリック率が下がる、というトレードオフがあります。近年は Google 側が検索結果上の description を自動生成で置き換える頻度も上がっており、「完全にコントロールできる値」ではなくなっていますが、それでも「整った description を書いておく」意義は残っています。

以下が文字数の目安を一覧にしたものです。

ベンリーのガイド記事は、1 本あたりスペース除く字数で 11,000〜15,000 文字を目安にしています。これは「ユーザーが検索して辿り着いたページで、しっかり情報を得て帰れる」ための情報量と、Google が好む滞在時間を両立させるラインです。短いページは逆引き型ツールへのリンク集、長いページは腰を据えて読む解説記事、という棲み分けをサイト全体で設計しています。

画像 OCR で文字数カウント

文字数カウントの話題の最後は、「画像に写っている文字を数えたい」という、ひと捻りしたケースです。紙に手書きされたメモ、スクリーンショットに映った文章、看板の写真、PDF の 1 ページ——文字列としてコピペできない画像から文字数を出すには、OCR（Optical Character Recognition、光学文字認識）で一度テキストに起こす必要があります。

OCR の歴史はコンピュータよりも古く、1914 年にエマニュエル・ゴールドバーグが開発した機械式の文字読み取り装置が起源とされています。デジタル化以降は 1970〜80 年代に郵便番号の自動読み取り装置として本格普及し、1990 年代に商用 OCR ソフト（OmniPage や Kurzweil など）が登場、2000 年代以降にオープンソースの Tesseract が登場して状況が一変しました。Tesseract は元々 HP の研究所で 1980 年代に開発され、2005 年にオープンソース化、2006 年から Google がメンテナンスを引き継いだことで急速に進化しました。

現在、ブラウザ内で OCR を動かすなら Tesseract.js（JavaScript 版の Tesseract）が定番です。WebAssembly で Tesseract 本体を動かし、Web Worker でメインスレッドをブロックせずに文字認識を実行します。日本語・英語・中国語・アラビア語など 100 言語以上に対応しており、学習済み言語モデル（.traineddata ファイル）をブラウザに読み込ませるだけで OCR が動き始めます。

// Tesseract.js の基本形（擬似コード）
import Tesseract from 'tesseract.js';

const result = await Tesseract.recognize(
  imageFile,
  'jpn+eng',  // 日本語 + 英語
  {
    logger: (m) => console.log(m),
  }
);

console.log(result.data.text);  // 認識されたテキスト
console.log(result.data.confidence);  // 全体の信頼度 (0-100)

ただし OCR は万能ではありません。精度に影響する要因は大きく 画像の解像度・コントラスト・フォントの種類・言語モデルの品質の 4 つです。印刷物をスキャンした高解像度画像では日本語でも 90〜95% の文字正解率を期待できますが、スマホでの斜めからの撮影、手書き文字、装飾フォント、背景との干渉、低解像度のスクショなどは正解率が 60% 以下に落ち込むことも珍しくありません。

日本語の OCR 精度は、英数字やラテン文字に比べると一段階低いのが現実です。理由は、漢字の字形が多種多様（JIS 第一水準だけで約 3000 字、第二水準まで含めると 6000 字以上）、フォントによる差が大きい、縦書きと横書きが混在する、ルビや振り仮名が紛らわしい、などなど。Tesseract の日本語モデルは年々改善されていますが、完璧を期待するのは禁物で、OCR 後に人間が軽く校正する前提で使うのが実務的です。

とはいえ「ざっくり文字数を把握したい」「この画像に写っているテキストを検索可能にしたい」という用途では、多少の誤認識があっても十分役に立ちます。ベンリーの 画像文字数カウントは、ブラウザ内で画像をアップロードすると Tesseract.js を使って OCR を実行し、認識されたテキストと文字数を返します。研究用の元資料、手書きメモのデジタル化、スクリーンショットからの転記補助、といった場面で活用してください。

ブラウザ内処理とプライバシー

文字数カウントや画像 OCR を Web 上のツールで行うとき、気になるのが「入力した文章や画像が、どこかのサーバーに送信されているのではないか」という不安です。社内文書、顧客情報、法律文書、未発表の原稿——こうした機密性の高い文章を外部サービスにコピペするのは、多くの職場でセキュリティ規定に抵触します。画像 OCR に至っては「紙の契約書を撮影して流し込んだら、それが外部に渡ってしまう可能性がある」という、さらに踏み込んだリスクがあります。

そこでベンリーが一貫して採用しているのが「100% ブラウザ内処理」という方針です。文字数カウントのロジックは全部クライアント側の JavaScript で動き、入力したテキストは 一度もサーバーに送信されません。画像 OCR も同じで、Tesseract.js は WebAssembly でローカル実行されるので、画像ファイルがユーザーのブラウザから外に出ることはありません。最初に言語モデル（.traineddata）を CDN から読み込むだけで、その後の認識処理は全てローカル完結です。

この方針には副次的なメリットもあります。まず、オフラインでも動く（モデルさえキャッシュされていれば）。次に、サーバー側の計算リソースが不要なので、サイト運営側のコストが抑えられ、結果としてユーザーに広告や登録を強いずに無料で提供できる。そして レスポンスが速い——ネットワーク往復が発生しないので、数千文字〜数万文字のテキスト処理でも 1 秒以内に結果が返ります。

もちろん「ブラウザ内処理」にもできないことはあります。たとえば「複数端末で履歴を同期したい」「大量のファイルをバッチ処理したい」「サーバー側の強力な AI モデルで翻訳と同時に処理したい」といった要求には応えられません。ベンリーは割り切って「単発のテキスト / ファイルを、その場で素早く処理する」ユースケースに特化しており、それ以上の要求がある人は Google Docs や Microsoft Word のようなフル機能のサービスを使ってください、というスタンスです。機密文書の扱いに神経を使う職種の方には、この割り切り方がちょうどいいはずです。

3 ツール使い分け

ここまで取り上げてきた 3 つのツール、それぞれの得意分野と使いどころをまとめます。どれか 1 つだけを覚えるより「場面によって切り替える」ことを意識すると、作業効率がぐっと上がります。

文字数カウント（char-count） — 日本語中心の分量チェック

日本語の記事・ブログ・小説・レポートなど、文字数ベースで分量を把握したい場面の主役ツールです。スペース込み / 除く両方の字数、改行数、原稿用紙換算枚数、書記素クラスタ単位のカウントを同時に表示します。絵文字や結合文字が入っても、ユーザーの直感と一致する数値が返るのが特徴。ブログ記事の下書き、クラウドソーシングの発注前チェック、原稿の分量確認、学校レポートの字数確認などに使ってください。

ワードカウント（word-count） — 英文のワード数・文数

英語・ドイツ語・フランス語など、単語ベースで分量を数える言語のためのツールです。ワード数・センテンス数・段落数・文字数を一括で表示します。英文エッセイの執筆、ビジネスメールの推敲、学術論文のアブストラクト、プレゼン原稿の尺調整などに向いています。「1 分スピーチは何ワード？」を逆算したいときにも便利です（英語のスピーチは 1 分あたり 120〜150 ワードが目安）。

画像文字数カウント（image-char-count） — OCR 経由の字数抽出

コピペ不可能な画像から文字を抽出して数えたい場面で使います。Tesseract.js の日英モデルで OCR を実行し、認識結果のテキストと文字数を表示します。PDF のスクショ、看板の写真、印刷物のスキャン、手書きメモの確認など、「そもそも文字列としてアクセスできない素材」を扱えるのが強み。精度には限界があるので、正確さが必要な用途では OCR 結果を目視で軽く校正してから使ってください。