なぜAIは文字数を数えられない？トークンの正体と実践的制御術

AIに文字数を指定しても思い通りにならないのは、生成AIを活用するライターをはじめ、文章作成が絡む業務に関して生成AIの能力を必要としているすべての方々が抱える共通の悩みです。なぜ生成AIは指定した文字数の範囲内で文章を書いてくれないのでしょうか、その原因と実践的な制御術について詳しく解説します。

AIが文字数指定を無視してしまう構造的な理由

AIが文字数を守れない最大の要因は、私たちが使う「文字」という単位でテキストを処理していないという根本的な仕組みにあります。

AIは「文字」ではなく「トークン」で世界を認識している

AIの脳内では、テキストは「トークン」という断片的な単位に分解されて処理されています。英語であれば単語単位に近い処理が可能ですが、日本語の場合は漢字、ひらがな、助詞などの組み合わせによってトークンの区切りが複雑に変化します。

このため、AIが「3000文字書こう」と計画しても、内部のトークン計算と実際の文字数カウントには必ずと言っていいほど物理的な乖離が生じてしまうのです。

～トークンとは、 AI がテキストの理解や生成を行う際に扱う単位のことです。簡単に言えば、文章を分解した小さなパーツの一つひとつがトークンであり、 AI はこのトークンを学習や処理を行うための最小単位として使用します。
例えば、「彼は職場に行きます」という文章を AI が処理する場合、これをそのままの形で使うのではなく、まずはトークンの単位に分解します。具体的には、「彼」「は」「職場」「に」「行き」「ます」のように、小さい単位に分けられるのです。
～

Ggen

日本語特有の「1文字1トークン」ではない複雑な変換

日本語は1文字が1トークンになるとは限りません。日本語の数文字が1トークンになる事もよくあります。さらに、専門用語や珍しい言い回しになると消費量が増大します。

AIはこのトークンの総量制限（コンテキストウィンドウ）の中で出力を調整するため、日本語の文字数を正確に把握することは技術的に非常に困難な作業となります。これが日本語ライティングにおける分量の不安定さを招く正体です。

逐次生成モデルの限界と「書き直し」ができない脳内プロセス

AIの文章生成プロセスは、人間が全体構成を俯瞰しながら執筆するスタイルとは根本的に異なり、常に「次の一歩」のみを見ています。

次に続く一文字を予測する「オートコンプリート」の仕組み

現在の生成AIは、入力された文脈から「次に来る確率が最も高い文字」を一つずつ順番に選んでいく逐次生成という仕組みを採用しています。これは超高性能な自動補完（オートコンプリート）のようなものであり、書き進めている最中に「全体の進捗が70％だから、残りの文字数を調整しよう」といったリアルタイムの全体制御を行っているわけではありません。

ゴール（総文字数）から逆算して書くことが苦手なAI

人間は「あと500文字で締めなければならない」と考えれば、話題を絞ったり表現を簡潔にしたりしてゴールに合わせます。しかし、AIは出力の瞬間に全力を注ぐため、途中の解説が盛り上がるとそのまま突き進んでしまいます。

結果として、後半で文字数が足りなくなって急に話を畳んだり、逆に情報密度が薄いままダラダラと長文を吐き出したりといった現象が起こるのです。

プロンプトで文字数をコントロールする3つの実戦テクニック

構造上の問題を理解した上で、実務では「AIに全体を任せない」というスタンスが、最も確実な分量制御の近道となります。

アウトラインで各章の「目標文字数」を事前に合意する

いきなり「3000文字の記事を書いて」と命じるのは得策とは言えません。まず構成案を作成させ、各見出しに対して「h2-1は400文字、h2-2は800文字」といった具合に数値目標を細かく設定しましょう。AIにこれから書くべき「各パーツの重要度」をあらかじめ認識させることで、大幅なボリュームの過不足を防ぐことが可能になります。

一括出力を捨てた「セクションごとの分割執筆」の威力

最も効果的なのは、1つのプロンプトで記事を完結させない「分割生成」です。1章ずつ「前の章の内容を踏まえて、この章を〇文字で書いてください」と指示を出すことで、AIの注意力を特定のセクションに集中させられます。この分割ワークフローを導入するだけで、文字数の精度は劇的に向上し、人間側の修正コストも大幅に削減できます。

箇条書きや段落数を指定して物理的なボリュームを縛る

「詳しく書いて」といった曖昧な指示ではなく、「段落を3つ作り、各段落は3文構成にする」や「重要なポイントを5つの箇条書きで出す」といった構造的な制約を与えてください。AIは論理的な構造を指定されるとその枠組みを守ろうとする性質があるため、結果として総文字数がコントロールしやすくなります。

文字数が足りない・多すぎる時の「上級」微調整コマンド

一度出力された文章が理想の分量でなかった場合でも、適切な追加プロンプトを投げることで、質を落とさずに調整が可能です。

情報密度を上げる「深掘り・具体例追加」の指示出し

文字数が足りないときは、単に「長くして」では不十分です。「〇〇の箇所に初心者向けの用語解説を補足して」などのように具体的な内容で指示しましょう。これにより、文脈の整合性を保ったまま、読者にとって価値のある情報を増強しながら文字数を稼ぐことができます。

冗長さを削ぎ落とす「要約・圧縮」のプロンプト例

逆に出力が長すぎた場合は、「意味を変えずに、同じ内容を300文字以内で要約して」といった圧縮指示が有効です。特に「同じ意味の繰り返しを避けて」という一言を添えるだけで、文章のキレが向上し、SEO的にも評価されやすい、無駄のない洗練されたコンテンツへと進化します。

• 不足時は「なぜ」「どのように」といった背景情報の記述を促す。
• 超過時は「重複表現の削除」と「接続詞の最適化」を優先的に命じる。
• 調整後は必ず「文末のトーン」が崩れていないかを確認する。

文字数の微調整を行う際は、AIに対して「どの情報を残し、どの情報を膨らませるか」という優先順位を明確に伝えることが重要です。単なる「増減」ではなく「編集」の視点で指示を出すことで、記事の説得力を維持したまま目標の文字数へと着地させることができます。

AIとの協働でライティングの生産性を最大化するために

最終的に重要なのは、AIを「完成品を出す魔法の箱」ではなく、共に記事を作り上げる下書きパートナーとして扱うマインドセットです。

AIは「下書き職人」と割り切るディレクションの重要性

現在のAI技術では、一発で完璧な文字数のプロ品質の記事を出すのは困難です。AIには素材となる「初稿」を全力で吐き出させ、人間が最終的なディレクションと微調整を行うという役割分担を徹底しましょう。この割り切りが、最もストレスなくAIライティングを継続する秘訣となります。

筆者の回想・生成AI普及間もない頃の扱いにくさ

本記事の筆者である私は現在、生成AIを使ってweb掲載用の記事を作成するという業務に携わっています。使用する生成AIは主にChatGPTとGemini、いずれも無料版です。

作業の流れとしては、掲載ブログの主旨に関連するテーマを決定し、それに沿った3000～4000字程度の記事を生成AIで作成、その後に出来上がった記事の内容に誤りがないかファクトチェックし、サイトにUPする、大まかに言えばこのようになります。

一連の作業でとくに厄介に感じるのは、本記事のテーマとしてとりあげた「指定した文字数どおりに記事を書いてくれないAIの特徴」です。私が現在の業務を開始したのは今（2026年5月）からちょうど2年前となりますが、当時はChatGPTとGeminiいずれも画像生成で人物などのキャラクターが描けないなど、今と比べるとAIの性能がずいぶん低かったような印象があります。

そんな背景もあってか、生成AIの文章の精度もかなり雑でした。3000字の文章を一気に仕上げる能力は備わっておらず、分割して記事生成させなければならない状況でした。後半に近づくと文章がかなりアバウトになり、支離滅裂な箇条書きを挙げてくるという状況もしばしば見られました。

今ではそのような現象もすっかりなくなりましたが、未だ頻発する問題が残っています。「文字数が指定範囲内に収まらない」というのがまさにそれです。しかしながら、本記事で挙げたような対応策をとることで問題は概ね回避できています。

人間側すなわち私がついうっかりラクしようとAIへの具体的指示をせず丸投げに近いプロンプトを入力してしまうと、AIはこれみよがしに文字数のズレという仕返しで足を引っ張る、そんな関係性にあるような気がしている今日このごろです。

まとめ

AIが文字数を守れないのは、知能の欠如ではなく「トークンによる計算」と「逐次予測」という技術的な仕様が原因です。この特性を無理に変えようとするのではなく、私たちがプロンプトの出し方を工夫することで、ズレは最小限に抑えられます。

一括生成に頼らず、アウトラインを固めてセクションごとに分割執筆させる「丁寧なディレクション」こそが、AIライティングで圧倒的な成果を出すための王道です。仕組みを理解し、AIを賢く使いこなすことで、記事制作の生産性を次なるステージへと引き上げていきましょう。

あとがき

本記事作成に合わせてトークンについて調べた印象ですが、数ある言語の中で日本語はとくに文字数のズレが生じやすい言語であるようです。ぜひとも生成AI運営会社各位には文字数ズレ解決に向けて励んでいただきたい、そんな私個人の強い思いはあるのですが、今後も使用者自身がプロンプトで気をつけていかなければならない部分かと思います。