最終更新:

ChatGPT 出力の文字数制御テクニック

約 8 分で読めます

ChatGPT をはじめとする大規模言語モデル (LLM) は、文章生成の強力なツールとして広く活用されています。しかし、「500 文字で要約して」と指示しても正確に 500 文字にはならない、出力が途中で切れてしまう、といった文字数に関する悩みを抱えるユーザーは少なくありません。その根本原因は、LLM が文字数ではなく「トークン」という独自の単位でテキストを処理している点にあります。本記事では、トークナイザーの内部動作からモデルごとの出力トークン上限、プロンプトエンジニアリングによる制御テクニック、そして API と Web UI の違いまで、出力文字数を制御するための実践的な知見を体系的に解説します。

BPE トークナイザーの仕組みと文字数の乖離

ChatGPT が使用する GPT 系モデルは、BPE (Byte Pair Encoding) と呼ばれるアルゴリズムでテキストをトークンに分割します。BPE は学習データ中の頻出バイト列を繰り返し結合し、語彙テーブル (vocabulary) を構築する手法です。GPT-4o が採用する o200k_base トークナイザーは約 200,000 語彙を持ち、従来の cl100k_base (約 100,000 語彙) から大幅に拡張されています。

この仕組みが文字数との乖離を生む原因です。英語では "information" のような一般的な単語が 1 トークンに収まる一方、日本語では漢字・ひらがな・カタカナが混在するため、同じ意味の文でもトークン消費量が大きく異なります。ChatGPT のプロンプト文字数の制限を理解する上でも、この仕組みの把握は不可欠です。

具体的な乖離パターンを見てみましょう。「東京都渋谷区」は 6 文字ですが、日本語は地名のような固有名詞でも 1 文字から数文字単位で細かく分割されるため、文字数に近いトークン数を消費します。一方、英語の "Tokyo Shibuya" は 13 文字でも数トークンに収まります。ざっくりした目安として、日本語は 1 トークンあたり 1 文字強、英語は数文字分の情報が入ると考えておくと見積もりを外しにくくなります。この差は文字数とバイト数の違いにも関連しており、UTF-8 エンコーディングで日本語 1 文字が 3 バイトを消費することが、BPE の分割効率にも影響しています。

テキスト例文字数トークン数の目安1 トークンあたり文字数
「人工知能の研究開発」9 文字5〜7 トークン約 1.3〜1.8 文字
"artificial intelligence research"32 文字4〜6 トークン約 5.3〜8.0 文字
「おはようございます」(ひらがな)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 トークンにまとまることが多く、相対的に効率が高くなります。

ただし上表の値は幅を持った目安として扱ってください。トークン分割は使用するトークナイザーの版と前後の文脈の両方で変わり、同じ語でも文中の位置によって切れ目が動きます。見積もりの精度が必要な場面では、利用するモデルに対応したトークナイザーで実際に数えるのが唯一の確実な方法です。

出力トークン上限はコンテキストとは別枠

文字数制御でつまずく人が最初に取り違えるのが、「コンテキストウィンドウ」と「最大出力トークン」の関係です。この 2 つはまったく別の枠で、しかも比率がモデルごとに大きく違います。公開ドキュメントで示されている値を 2026 年 8 月時点で確認すると、GPT-4o はコンテキスト 128,000 トークンに対して出力上限 16,384 トークン、o1 はコンテキスト 200,000 トークンに対して出力上限 100,000 トークンです。前者は入力枠の 8 分の 1 程度しか出力に使えず、後者は半分を出力に回せます。同じ「大きなコンテキスト」でも、一度に書ける長さは桁が違うということです。

ここで注意したいのは、モデル名と上限値の寿命が短いことです。世代交代のたびに系列名も上限値も入れ替わるため (2026 年 8 月時点の主力系列は GPT-4o・o1 世代からさらに先へ進んでいます)、実装に数値を焼き込む前に必ず利用時点の公式ドキュメントで確認してください。上限を定数としてコードに書くのではなく、設定値として外に出しておくのが安全です。

もう一つの落とし穴は、上限に達する前にモデルが自分で書き終えてしまう点です。出力上限は「そこまで出せる」枠であって「そこまで出す」保証ではありません。モデルは文章として自然な長さで終わるよう学習しているため、上限が大きくても長文にはならず、長く書かせたい場合は明示的な指示が必要になります。加えて推論を行う系列のモデルは思考過程のトークンを内部で消費するため、画面に出た文字数に対して課金対象のトークンが大きく上回ることがあります。API の usage フィールドで実際の消費量を確認する習慣をつけてください。

日本語出力はコストと長さの両方で不利になる

同じ内容を伝える場合、日本語は英語よりも多くのトークンを消費します。理由は前述のトークン分割の効率差です。英語は単語がまとまって 1 トークンになりやすいのに対し、日本語は 1 文字強で 1 トークンを使ってしまうため、同じ情報量でもトークン数が数倍に膨らみます。

この差は 2 か所に同時に効いてきます。1 つは API コストで、出力トークン単位の従量課金なので日本語のほうが割高になります。もう 1 つは出力の長さで、max_tokens を同じ値に設定していても、日本語では得られる文字数が英語よりかなり少なくなります。「英語では十分な長さが返ってきたのに日本語だと途中で切れる」という現象の正体はこれです。

対策として、指示文だけを英語で書いて出力を日本語で受け取る使い分けが挙げられます。ただし節約できるのは入力側のトークンで、日本語の本文を出力する分のコストは減りません。指示文が長大なテンプレートである場合には効きますが、短いプロンプトで大量の日本語を書かせる用途では効果が薄い点は押さえておきましょう。日本語特有のニュアンスが指示から抜け落ちるリスクもあるため、費用対効果を見て判断するのが妥当です。

出力長に効く API パラメータの性格の違い

出力の長さに関わるパラメータは、性格が二種類に分かれます。ここを混同すると「上限を上げたのに長くならない」「下げたら文章が壊れた」という噛み合わない結果になります。

1 つは出力の上限を決めるパラメータで、max_tokens (モデルによっては max_output_tokens) が該当します。これはハードリミットとして働き、指定値に達すると文の途中であっても即座に生成が止まります。文章として区切りの良いところで止めてくれるわけではないので、目標の長さぴったりに設定すると末尾が欠けた文章が返ってきます。目標文字数から換算したトークン数に余裕を足して設定し、モデル自身の自然な終了を待つほうが実用的です。日本語では 1 トークンが 1 文字強に相当するため、換算時は文字数よりやや多めのトークン数を見ておきます。

もう 1 つは出力の選び方を変えるパラメータで、temperature が代表です。これは上限とは無関係に、次のトークンを選ぶ際の確率分布の広がりを調整します。低い値ではモデルが高確率のトークンを優先するため出力のばらつきが小さくなり、同じプロンプトに対する再現性が高まります (完全な決定性は保証されません)。高い値では低確率のトークンも選ばれやすくなり、言い換えや脱線、繰り返しが起きやすくなります。文字数を安定させたい用途では低めの値から調整するのが基本です。ただし temperature は長さを直接指定するパラメータではないため、これで狙った文字数に寄せようとするのは筋の悪い使い方になります。

プロンプトで文字数を制御するテクニック

ChatGPT に特定の文字数で出力させるためのプロンプト設計テクニックを紹介します。LLM は文字数を正確にカウントする能力が限定的であるため、工夫が必要です。

文字数制御の実践例

具体的なプロンプト例と、期待される出力文字数を示します。

プロンプト例出力文字数の目安文字数の安定度
「一言で要約して」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 と OpenAI API では、出力制限の挙動が異なります。この違いを理解していないと、「Web UI では長文が出力できたのに API では途中で切れる」といった混乱が生じます。

項目Web UI (ChatGPT)OpenAI API
出力トークン上限モデル依存 (自動設定)max_tokens で明示指定可能
「続きを書いて」会話履歴を自動保持自前で会話履歴を管理する必要あり
ストリーミングデフォルトで有効stream=true で明示的に有効化
出力の打ち切り時続きの生成を促す操作が用意されるfinish_reason="length" で判定
コスト管理サブスクリプション料金に含まれるトークン単位の従量課金

API で長文を安定して取得するには、finish_reason フィールドの確認が不可欠です。finish_reason が "length" の場合、出力が max_tokens の上限で打ち切られたことを意味します。"stop" であれば、モデルが自然に出力を終了したことを示します。この判定を自動化し、"length" の場合に続きを自動リクエストするロジックを組むことで、API でも Web UI と同等の長文出力が実現できます。

長文出力を安定して得るためのプロンプトテクニック

出力上限を超える長文を生成する場合、単に「長く書いて」と指示するだけでは不十分です。以下のテクニックを組み合わせることで、安定した長文出力が得られます。

ChatGPT の出力文字数に関するよくある問題と落とし穴

ChatGPT の文字数制御で遭遇しやすい問題と、見落としがちな落とし穴を紹介します。

まとめ

ChatGPT の出力文字数は、文字数ではなく BPE トークナイザーによるトークン分割を単位に制限されます。日本語は 1 トークンあたり 1 文字強にとどまるため、同じ内容でも英語より数倍のトークンを消費し、コストと出力の長さの両方で不利になります。文字数を制御するには、構造 (段落数・箇条書き数) で指定するのが最も効果的で、API では temperature=0 に近い設定で出力の安定性を高められます。Web UI と API の挙動の違いを理解し、用途に応じた制御手法を選択することが、効率的な ChatGPT 活用の鍵です。ChatGPT で生成した文章の文字数確認には、文字数カウントスをぜひご活用ください。

この記事を共有

ChatGPT の文字数制限｜Claude / Gemini との入力上限比較

ChatGPT の文字数制限はトークン数で決まります。日本語が英語の 1.5〜2 倍のトークンを消費する非対称性、入力と出力でコンテキストを分け合う仕組み、Claude / Gemini も含めた使い分けと長文入力のコツを解説します。