ChatGPT 出力の文字数制御テクニック
ChatGPT をはじめとする大規模言語モデル (LLM) は、文章生成の強力なツールとして広く活用されています。しかし、「500 文字で要約して」と指示しても正確に 500 文字にはならない、出力が途中で切れてしまう、といった文字数に関する悩みを抱えるユーザーは少なくありません。その根本原因は、LLM が文字数ではなく「トークン」という独自の単位でテキストを処理している点にあります。本記事では、トークナイザの内部動作から各モデルの実測出力データ、プロンプトエンジニアリングによる制御テクニック、そして API と Web UI の違いまで、出力文字数を制御するための実践的な知見を体系的に解説します。LLM の入門書も併せて参考になります。
BPE トークナイザの仕組みと文字数の乖離
ChatGPT が使用する GPT 系モデルは、BPE (Byte Pair Encoding) と呼ばれるアルゴリズムでテキストをトークンに分割します。BPE は学習データ中の頻出バイト列を繰り返し結合し、語彙テーブル (vocabulary) を構築する手法です。GPT-4o が採用する o200k_base トークナイザは約 200,000 語彙を持ち、従来の cl100k_base (約 100,000 語彙) から大幅に拡張されています。
この仕組みが文字数との乖離を生む原因です。英語では "information" のような一般的な単語が 1 トークンに収まる一方、日本語では漢字・ひらがな・カタカナが混在するため、同じ意味の文でもトークン消費量が大きく異なります。ChatGPT のプロンプト文字数の制限を理解する上でも、この仕組みの把握は不可欠です。
具体的な乖離パターンを見てみましょう。「東京都渋谷区」は 5 文字ですが、o200k_base では 4〜5 トークンに分割されます。一方、英語の "Tokyo Shibuya" は 13 文字で 3 トークン程度です。つまり、日本語は 1 トークンあたり約 1〜1.5 文字、英語は約 4〜5 文字という効率差が生じます。この差は文字数とバイト数の違いにも関連しており、UTF-8 エンコーディングで日本語 1 文字が 3 バイトを消費することが、BPE の分割効率にも影響しています。
| テキスト例 | 文字数 | トークン数 (o200k_base) | 1 トークンあたり文字数 |
|---|---|---|---|
| 「人工知能の研究開発」 | 9 文字 | 5〜7 トークン | 約 1.3〜1.8 文字 |
| "artificial intelligence research" | 35 文字 | 4 トークン | 約 8.8 文字 |
| 「おはようございます」(ひらがな) | 9 文字 | 5〜9 トークン | 約 1.0〜1.8 文字 |
| 「機械学習モデル」(漢字+カタカナ) | 7 文字 | 4〜5 トークン | 約 1.4〜1.8 文字 |
Python コード: print("hello") | 14 文字 | 5 トークン | 約 2.8 文字 |
注目すべきは、ひらがなのみの文は漢字混じりの文よりトークン効率が低い点です。ひらがなは 1 文字 3 バイト (UTF-8) で、BPE の結合対象になりにくいため、1 文字が 1 トークンに近くなります。漢字は頻出する 2 文字熟語が 1 トークンにまとまることが多く、相対的に効率が高くなります。
モデル別の出力トークン上限と実測比較
各モデルの公称スペックと、同一プロンプト (「日本の四季について 3,000 文字程度で詳しく解説してください」) で実測した出力結果を比較します。
| モデル | 最大出力トークン | コンテキスト | 実測出力トークン | 実測日本語文字数 |
|---|---|---|---|---|
| GPT-4o | 16,384 | 128K | 約 2,800〜3,500 | 約 2,000〜2,800 文字 |
| GPT-4o mini | 16,384 | 128K | 約 2,200〜2,800 | 約 1,600〜2,200 文字 |
| o1 | 32,768 | 200K | 約 3,500〜5,000 | 約 2,800〜4,000 文字 |
| o1-mini | 65,536 | 128K | 約 2,500〜3,500 | 約 2,000〜2,800 文字 |
| GPT-4 Turbo | 4,096 | 128K | 約 2,000〜3,000 | 約 1,500〜2,400 文字 |
| GPT-3.5 Turbo | 4,096 | 16K | 約 1,500〜2,500 | 約 1,100〜2,000 文字 |
実測データから読み取れる重要な傾向があります。まず、どのモデルも最大出力トークン数の上限まで使い切ることは稀です。GPT-4o は最大 16,384 トークンまで出力可能ですが、通常のプロンプトでは 3,000〜4,000 トークン程度で自然に終了します。これは、モデルが「文章として適切な長さ」を学習しているためです。上限いっぱいまで出力させるには、明示的な指示が必要になります。
また、o1 系モデルは推論トークン (思考過程) を内部で消費するため、表示される出力文字数に対して実際のトークン消費量が多くなる点に注意が必要です。API の usage フィールドで確認すると、completion_tokens が表示テキストのトークン数を大幅に上回ることがあります。
日本語と英語の出力トークン効率比較
同じ意味内容を日本語と英語で出力させた場合、トークン消費量にどの程度の差が生じるかを検証しました。プロンプトは「以下のトピックについて 5 つのポイントで解説してください: クラウドコンピューティングのメリット」を日英それぞれで実行しています。
| 指標 | 日本語出力 | 英語出力 | 効率比 (英語基準) |
|---|---|---|---|
| 出力文字数 | 約 800 文字 | 約 1,500 文字 | — |
| 出力トークン数 | 約 650 トークン | 約 350 トークン | 1.86 倍 |
| 情報密度 (文字/トークン) | 約 1.2 文字 | 約 4.3 文字 | — |
| API コスト (GPT-4o 基準) | 約 $0.0065 | 約 $0.0035 | 1.86 倍 |
同じ情報量を伝えるのに、日本語は英語の約 1.9 倍のトークンを消費します。これは API コストに直結するため、コスト最適化が重要な場面では、英語でプロンプトを記述し、出力のみ日本語に翻訳する「英語プロンプト + 日本語出力」戦略が有効です。ただし、この手法では日本語特有のニュアンスが失われるリスクがあるため、用途に応じた使い分けが求められます。
出力長に影響する API パラメータの実験結果
OpenAI API の主要パラメータが出力長に与える影響を、同一プロンプトで temperature と max_tokens を変化させて検証しました。
| パラメータ設定 | 平均出力トークン | 標準偏差 | 出力の特徴 |
|---|---|---|---|
| temperature=0.0 | 約 1,850 | ±50 | 毎回ほぼ同一の出力。文字数の再現性が最も高い |
| temperature=0.5 | 約 1,900 | ±200 | 適度な変化。実用上のバランスが良い |
| temperature=1.0 | 約 2,100 | ±450 | 冗長になりやすく、文字数のばらつきが大きい |
| temperature=1.5 | 約 2,300 | ±700 | 繰り返しや脱線が発生しやすい |
| max_tokens=500 | 500 (打ち切り) | ±0 | 文の途中で切断される。日本語約 400〜600 文字 |
| max_tokens=2000 | 約 1,850 | ±200 | 自然な終了。上限に達しないことが多い |
temperature が高いほど出力が長くなる傾向は、確率分布の広がりに起因します。temperature=0 ではモデルが最も確率の高いトークンを常に選択するため、簡潔で決定的な出力になります。temperature が上がると低確率のトークンも選ばれやすくなり、説明の追加や言い換えが増えて出力が長くなります。
max_tokens はハードリミットとして機能し、指定値に達すると文の途中でも即座に出力が停止します。日本語では 1 トークンが 1〜2 文字に相当するため、max_tokens=500 で約 400〜600 文字の出力が得られます。ただし、文の途中で切断されるリスクがあるため、目標文字数の 1.3〜1.5 倍のトークン数を設定し、自然な終了を促す方が実用的です。
プロンプトで文字数を制御するテクニック
ChatGPT に特定の文字数で出力させるためのプロンプト設計テクニックを紹介します。LLM は文字数を正確にカウントする能力が限定的であるため、工夫が必要です。
- 文字数ではなく「量」で指定する: 「500 文字で書いて」よりも「3 段落で書いて」「箇条書き 5 項目で書いて」の方が、期待に近い出力が得られます。1 段落は約 100〜200 文字、箇条書き 1 項目は約 30〜80 文字が目安です
- 文字数の範囲を指定する: 「ちょうど 500 文字」ではなく「400〜600 文字の範囲で」と幅を持たせると、より自然な文章が生成されます
- 出力形式を具体的に指定する: 「見出し 3 つ、各見出しの下に 2〜3 文の説明」のように構造を指定すると、文字数のコントロールがしやすくなります
- 「簡潔に」「詳細に」のキーワードを使う: 「簡潔に 1 文で」は 20〜50 文字、「詳細に説明して」は 300〜800 文字程度の出力になる傾向があります
- max_tokens パラメータを設定する (API 利用時): OpenAI API では max_tokens パラメータで出力トークン数の上限を設定できます。日本語 500 文字を目安にする場合、max_tokens を 700〜1,000 に設定します
文字数制御の実践例
具体的なプロンプト例と、期待される出力文字数を示します。
| プロンプト例 | 期待される出力文字数 | 精度 |
|---|---|---|
| 「一言で要約して」 | 20〜50 文字 | 高い |
| 「3 行で要約して」 | 60〜120 文字 | 高い |
| 「100 文字以内で説明して」 | 60〜130 文字 | 中程度 |
| 「500 文字程度で書いて」 | 300〜700 文字 | 低い |
| 「箇条書き 5 項目で」 | 150〜400 文字 | 高い (項目数) |
| 「Twitter 投稿用に 140 文字以内で」 | 80〜160 文字 | 中程度 |
| 「見出し 3 つ、各 100 文字で」 | 250〜400 文字 | 中程度 |
LLM は文字数を正確にカウントする能力が弱いため、「ちょうど 500 文字」のような厳密な指定は困難です。これは、モデルがトークン単位で生成を行い、各トークンが何文字に相当するかを逐次計算していないことに起因します。出力後に文字数カウントスで文字数を確認し、必要に応じて「もう少し短くして」「あと 100 文字追加して」と調整するのが現実的なアプローチです。
Web UI と API の出力制限の違い
ChatGPT の Web UI (chat.openai.com) と OpenAI API では、出力制限の挙動が異なります。この違いを理解していないと、「Web UI では長文が出力できたのに API では途中で切れる」といった混乱が生じます。
| 項目 | Web UI (ChatGPT) | OpenAI API |
|---|---|---|
| 出力トークン上限 | モデル依存 (自動設定) | max_tokens で明示指定可能 |
| 「続きを書いて」 | 会話履歴を自動保持 | 自前で会話履歴を管理する必要あり |
| ストリーミング | デフォルトで有効 | stream=true で明示的に有効化 |
| 出力の打ち切り表示 | 「Continue generating」ボタンが表示 | finish_reason="length" で判定 |
| コスト管理 | サブスクリプション料金に含まれる | トークン単位の従量課金 |
API で長文を安定して取得するには、finish_reason フィールドの確認が不可欠です。finish_reason が "length" の場合、出力が max_tokens の上限で打ち切られたことを意味します。"stop" であれば、モデルが自然に出力を終了したことを示します。この判定を自動化し、"length" の場合に続きを自動リクエストするロジックを組むことで、API でも Web UI と同等の長文出力が実現できます。
長文出力を安定して得るためのプロンプトテクニック
出力上限を超える長文を生成する場合、単に「長く書いて」と指示するだけでは不十分です。以下のテクニックを組み合わせることで、安定した長文出力が得られます。
- チェーンプロンプト (分割生成): 「まず第 1 章を書いて」「次に第 2 章を書いて」のように、セクションごとに分割して生成します。各セクションの文字数を指定することで、全体の文字数をコントロールできます。API では各リクエストの出力を結合して最終的な長文を構成します
- アウトライン先行法: 最初にアウトライン (見出しと各セクションの概要) を生成し、その後各セクションを個別に展開します。アウトラインで全体の構成と文字数配分を決めておくと、バランスの取れた長文が生成できます
- コンテキスト引き継ぎ: 出力が途中で切れた場合、前の出力の末尾 200〜300 文字を次のリクエストに含めて「以下の続きを書いて」と指示します。単に「続きを書いて」だけでは文脈が失われ、内容が重複したり矛盾したりするリスクがあります
- 明示的な長さ指示の強化: 「必ず 3,000 文字以上で書いてください。各セクションは最低 500 文字としてください」のように、最低文字数を強調すると、モデルが早期に出力を終了する傾向を抑制できます
- JSON 構造化出力の活用: API の response_format で JSON モードを指定し、各セクションを JSON のフィールドとして出力させると、セクション単位での文字数管理が容易になります。OpenAI API プログラミングの実践書で詳しく学べます
ChatGPT の出力文字数に関するよくある問題と落とし穴
ChatGPT の文字数制御で遭遇しやすい問題と、見落としがちな落とし穴を紹介します。
- 出力が途中で切れる: 出力トークン上限に達した場合に発生します。API では finish_reason="length" で検出し、自動的に続きをリクエストする仕組みを構築するのが確実です。GPT-4o は最大 16,384 トークンまで出力可能ですが、o1 は 32,768 トークンまで対応しています
- 指定した文字数と大きくずれる: LLM は文字数を正確にカウントできないため、±30% 程度のずれは想定内です。構造 (段落数、箇条書き数) で指定する方が精度が高くなります。特に日本語では、トークンと文字数の対応が不安定なため、英語よりもずれが大きくなる傾向があります
- 日本語の出力が英語より短い: 同じ max_tokens 設定でも、日本語は英語の約 50〜60% の文字数しか出力されません。日本語で英語と同等の文字数を得るには、max_tokens を 1.8〜2.0 倍に設定する必要があります
- 繰り返しが発生する: 長文生成時に同じ内容が繰り返されることがあります。frequency_penalty を 0.5〜1.0 に設定すると抑制できますが、値を上げすぎると文章の自然さが損なわれます。0.3〜0.7 の範囲で調整するのが実用的です
- トークンカウントの誤算: tiktoken ライブラリ (Python) や gpt-tokenizer (JavaScript) でプロンプトのトークン数を事前に計算できますが、モデルのバージョンアップでトークナイザが変更されると、同じテキストでもトークン数が変わることがあります。o200k_base と cl100k_base では同一テキストのトークン数が最大 20% 程度異なるケースがあるため、使用モデルに対応したトークナイザを選択してください
- コンテキストウィンドウの消費: 入力プロンプトが長いほど、出力に使えるトークン数が減ります。128K コンテキストのモデルでも、100K トークンのプロンプトを送ると出力に使えるのは残りの 28K トークンです。ただし、出力は max_output_tokens の上限にも制約されるため、コンテキストが余っていても出力上限を超えることはできません
まとめ
ChatGPT の出力文字数は BPE トークナイザによるトークン分割に基づいて制限されます。日本語は 1 トークンあたり約 1〜1.5 文字で、英語 (約 4〜5 文字) の 3〜4 倍のトークンを消費します。文字数を制御するには、構造 (段落数・箇条書き数) で指定するのが最も効果的で、API では temperature=0 に近い設定で出力の安定性を高められます。Web UI と API の挙動の違いを理解し、用途に応じた制御手法を選択することが、効率的な ChatGPT 活用の鍵です。ChatGPT で生成した文章の文字数確認には、文字数カウントスをぜひご活用ください。