メールが途中で切れる原因｜文字数ではなくバイト数

「送ったメールの途中に『メッセージ全体を表示』というリンクが出てしまう」「本文は短くしたつもりなのに、また切れた」——自分が配信したメールが最後まで読まれていないと気づいた瞬間は、肝が冷えます。

結論から言うと、メールを切っているのは文字数ではなくバイト数です。Gmailは本文のデータ量が約102KBに達したところで表示を打ち切ります。日本語は1文字あたりのバイト数が英語よりはるかに大きいため、「何文字書いたか」の感覚で判断していると、この線はほぼ確実に読み違えます。

株式会社Fyveは、自社のニュースレターをAIで生成して配信する運用をしています。その中で実際にこの上限に当たり、原因を特定したうえで本文の上限値を決め直しました。この記事では、102KBという数字の意味と出所、日本語が不利になる仕組み、そして実測から自分の配信の上限を決める手順までを整理します。

結論：Gmailが見ているのは文字数ではなくバイト数

メールの末尾に「[メッセージの一部が表示されています] メッセージ全体を表示」というリンクが出る現象を、英語圏ではクリッピング（clipping）と呼びます。メールが届かなかったのでも、迷惑メールに入ったのでもありません。届いてはいるが、途中から先を畳まれている状態です。

この線引きの基準として、メール配信の実務では102KBという数字が共有されています。Mailchimpのヘルプは「Gmailはメッセージサイズが102KBより大きいメールをクリップし、残りのコンテンツを『メッセージ全体を表示』リンクの裏に隠す」と明記しています。Email on AcidとLitmusも同じ102KBを挙げており、少なくとも実務上の作業値としては各社の記述が一致しています。

ただし102KBは「Googleが公表した数字」ではない

ここは記事として正確に書いておきます。102KBという値は、Googleが公式ドキュメントで公表している数字ではありません。メール配信に関わる事業者やコミュニティが観測を持ち寄って収束させた、信頼できる作業値です。

Email on Acidは、この点についてさらに踏み込んだ観察を書いています。同社の記事（2021年7月16日公開）は6,000通以上のメールを分析したうえで、「Gmailがクリップを決める正確なサイズは完全に一貫してはいない。もっと小さいメールでクリッピングが起きることもある」と述べ、加えて「本来意図されている上限はおそらく100KBだろう」という見立てを示しています。

なお、ここで引用している各社の記事は2021年から2024年にかけて公開されたものです（Litmusの記事は2024年2月29日付で、同社サイト上にも内容が古くなっている可能性を示す注記が出ています）。102KBという数字は長く共有されてきた目安ですが、Googleが保証している値ではない以上、自分の環境で実測して確かめる姿勢は今後も必要です。

つまり102KBは、崖の位置を示す正確な座標ではなく、崖のだいたいの場所だと捉えるのが実態に合っています。ぴったり102KBまで攻める運用設計は、この時点で筋が悪いということです。

なぜ日本語のメールは圧倒的に不利なのか

ここからが、日本語で配信している人にとっての本題です。102KBという上限はバイト数で測られますが、私たちが原稿を書くときに見ているのは文字数です。この2つの換算率が、日本語では非常に悪くなります。

1文字が3バイトになる（UTF-8）

現在のメールやWebで標準的に使われているUTF-8という文字コードでは、英数字の1文字は1バイトで表せます。しかし日本語のひらがな・カタカナ・漢字は、1文字あたり3バイトを使います。この時点で、同じ「1文字」でも英語の3倍の重さです。

さらに送信時の変換で膨らむ

メールは、本文をそのまま生のデータで運ぶとは限りません。歴史的な経緯から、メール本文は送信時にASCII文字の範囲へ変換されて運ばれることがあります。この変換方式のひとつがQuoted-Printableです。

この方式の仕様は、メールの形式を定めた標準規格RFC 2045の6.7節に書かれています。原文は「任意のオクテット（1バイト）は、『=』とそのバイト値を16進数2桁で表した表記によって表現されうる」と定めています。つまり1バイトが3文字に置き換わるということです。

結果として、日本語1文字＝3バイトが、さらに3倍に展開されます。単純計算で1文字あたり実質9バイトです。英数字1文字が1バイトのままであることを考えると、同じ「1文字」でも日本語は9倍の場所を取る計算になります。

ただしこれはあくまで規格から導いた計算値です。実際の配信では、すべてのバイトがこの方式で変換されるとは限らず、本文以外の要素も乗ります。運用の判断に使うべきなのは、次に示す自分の環境での実測値のほうです。

私たちの実測値：1文字あたり11〜15バイト

理屈だけでは運用の判断に使えないので、私たちは実際に配信したメールの本文データを測りました。結果は次のとおりです。

1文字あたりに直すとおおむね11〜15バイトです。理論値の9バイトより重いのは、本文の文字そのものだけでなく、見出し・リンク・段落などを構成するHTMLのマークアップが同時に乗っているためです。

注目してほしいのは3行目です。文字数では5,000字弱、データ量では56KB。102KBの半分程度しか使っていないように見えるのに、実際にはここで畳まれました。前述のとおりGmailの線は完全に一貫しておらず、配信側が挿入する要素も加算されるためです。「102KBまでは安全」ではないという実例として、私たちはこの1件を基準に運用を組み直しました。

102KBに数えられるもの・数えられないもの

上限に対処するとき、多くの人が最初に「画像を減らそう」と考えます。しかしこれは、半分正しくて半分間違いです。

画像ファイルそのものは数えない

Litmusは「102KBの上限に画像は含まれず、コード自体のデータサイズのみが対象になる」と明記しています。メール本文のHTMLは画像の実体を抱えているわけではなく、画像が置いてある場所を指し示しているだけだからです。したがって、500KBの写真を1枚貼っても、102KBの計算には500KBぶんは乗りません。

ただし画像を置くための「記述」は確実に嵩む

ここを混同すると判断を誤るので、分けて書きます。画像ファイルは数えられませんが、画像を表示するための記述（マークアップ）は本文のコードの一部なので、しっかり数えられます。

私たちの配信で実測したところ、画像1枚あたり約3,372バイトを消費していました。画像そのものではなく、画像を置くための記述だけでこの量です。配信システムは画面サイズごとの出し分け情報などを自動で付け加えるため、1枚の画像に対する記述は思ったより長くなります。

この数字を本文の文字数に換算すると分かりやすくなります。1文字あたり13バイト前後とすると、画像を1枚減らせば、本文をおよそ250字ぶん増やせる計算です。画像と文章が同じ財布を奪い合っている、と考えると設計しやすくなります。

配信システムが後から足す分もある

さらに、書いた本人が把握していない加算があります。Email on Acidは「配信システムがトラッキングリンクを挿入するなどコードを書き換えると、HTMLのサイズが増える」と指摘し、「経験則として80KBを下回るようにしておくとよい」と勧めています。

つまり、自分の手元で測った数字がそのまま受信側のサイズになるとは限りません。手元の実測値に対して、あらかじめ余白を持たせておく必要があります。

引き金はサイズだけではない——非ASCII文字という第2の要因

ここまではデータ量の話をしてきましたが、Email on Acidはクリッピングの引き金を2つ挙げています。HTMLのサイズと、非ASCII文字です。

ASCIIというのは、英数字と基本的な記号だけを含む古い文字の規格です。それに対してUTF-8は、日本語や記号類を含む現代的な規格です。同社は「配信システムがUTF-8で符号化していない場合、特殊な文字を使うとこの問題に当たりやすい」と説明しています。

ここは分けて理解してください。この第2の要因は、私たちが当たったサイズの問題とは別系統です。同社の説明は「配信システム側の文字の扱いが適切でないケース」を指しており、日本語だから自動的に該当するという話ではありません。

ただし、日本語の配信は本文のほぼ全体が非ASCII文字で構成されているという事実は残ります。英語圏では「著作権記号やアクセント付き文字を使ったとき」という限定的な話ですが、日本語の配信では常時その条件下にあるわけです。使っている配信システムが本文をどの文字コードで扱っているかは、一度確認しておく価値があります。

切れると何が壊れるのか（読まれない以外の実害）

「途中で切れても、リンクを押せば全部読める」と考えると対処が後回しになります。しかし実際の損失は、本文が読まれないことだけではありません。

レイアウトが壊れる

Litmusは「クリッピングは102KBに達した場所で発生するため、テーブルやdivといったコード構造が正しく閉じられなくなり、レイアウトが崩れる可能性がある」と説明しています。切断は文章の区切りを見て行われるわけではないので、デザインが途中から崩れた状態で表示されることがあります。

開封の計測ができなくなる

Mailchimpは「Gmailがメッセージをクリップすると、開封を計測するコードも一緒にクリップされる」と明記しています。開封計測の仕組みは本文の末尾付近に置かれるのが一般的なため、切られる側に入ってしまうのです。

これは地味に厄介です。実際には読まれているのに、数字の上では開封率が下がって見えるため、「今回の件名は悪かったのか」と誤った反省をしてしまいます。原因が配信の長さにあるのに、件名や配信時間を調整し続けることになりかねません。

配信解除リンクが押せなくなる

最も避けたいのがこれです。Email on Acidは「配信解除リンクがクリップされると、読者はそれを見つけられず、迷惑メール報告ボタンを押す可能性が高くなる」と警告しています。配信解除の導線は本文の最後に置かれるため、切られやすい位置にあります。

配信解除の代わりに迷惑メール報告が積み上がると、そのドメインから送るメール全体の信頼度が下がります。本文が長かったという理由で、届く力そのものを損なうわけです。届くかどうかの土台については、認証まわりを整理した記事も用意しています。

参考：急にGmailにメールが届かない？原因と対策を実務者が解説

AIに書かせると、この上限に当たりやすくなる

私たちがこの問題に正面から当たったのは、配信物の生成をAIに任せているからです。

AIに文章を書かせたことのある方なら想像がつくと思いますが、出力の長さは「足りない」よりも「余る」方向に振れます。指示に「簡潔に」と書いても、論点を丁寧に拾おうとするほど本文は伸びます。人が毎回書いていた頃は、書く手間そのものが長さの歯止めになっていました。生成を自動化すると、その歯止めが外れます。

そこに、この記事でここまで見てきた性質が重なります。

• 畳まれる基準はバイト数なのに、書き手が見ているのは文字数
• 日本語は1文字あたり11〜15バイトと換算率が悪く、感覚が効かない
• 画像を1枚足すと、本文250字ぶんの余白が黙って消える
• 境界は完全には一貫しないので、「前回は大丈夫だった」が根拠にならない

この4つが揃うと、人間の目視確認は原理的に機能しません。画面を眺めて「今日はちょっと長いかな」と判断することは、バイト数を見ていない以上どうやってもできないからです。AIに品質を一定に保たせる話は別記事でも扱っていますが、長さの問題はその中でも特に人の感覚が効かない部類です。

AI業務効率化SEO記事をAIに書かせる時、品質を一定に保つためにやったこと

私たちが打った手：上限を人ではなく機械に持たせる

私たちの対処は、運用ルールを増やすことではありませんでした。本文の上限を3,000字に確定し、配信前に必ず通しているチェッカーに、その上限を超えたら止まる条件として実装しました。

3,000字という値の根拠は、上の実測表です。2,225字で約32KB。1文字13バイト前後で換算すると、3,000字ならおよそ40KB前後に収まります。Email on Acidが勧める80KBの目安に対しても、画像の記述や配信システムの加算を吸収できる余白が残ります。102KBから逆算した最大値ではなく、実測から余白を引いた安全値として置いたということです。

上限はブロック、下限は参考値のまま——非対称にした

この実装で意識的に非対称にした点があります。上限は超えたら止める。下限は超えなくても止めない。同じ「分量のチェック」でありながら、扱いを変えました。

理由は、失敗したときに起きることが違うからです。

下限割れは人が読めば気づける失敗です。一方、上限超えは送った側の画面には何の異常も表示されない失敗です。受信者のGmailで初めて畳まれるため、送信者は自分では永久に気づけません。

止める対象を選ばずに何でもブロックすると、チェックは邪魔なものになり、やがて迂回されます。機械に止めさせるのは「人が気づけない失敗」だけに絞る——これが、私たちがこの一件から取り出した設計の指針です。チェックを増やすほど抜けが生まれる話は、以前に別の角度から整理しています。

AI業務効率化AIのチェックは増やすほど抜ける｜1本にして観点で割る

自分の配信の上限を決める4ステップ

102KBや3,000字という数字をそのまま借りても、配信システムもテンプレートも違えば結果は変わります。自分の環境で決め直す手順を示します。

ステップ1：過去に配信した実物のデータ量を測る

推定から始めないでください。すでに送ったメールの本文データを3通ほど取り出し、文字数とデータ量を並べて記録します。私たちの表と同じ形にすれば十分です。ここで自分の環境の「1文字あたり何バイトか」が出ます。

測り方が分からない場合、いちばん確実なのは自分宛てに届いた実物のメールから元データを取り出す方法です。主要なメールソフトには、受信したメールの元データ（メッセージのソース）を表示する機能が用意されています。Gmailの場合はメール個別のメニューから辿れますが、項目名や配置は変わることがあるため、お使いの画面で「ソース」「元のメッセージ」といった項目を探してください（本記事は2026年9月時点の情報です）。

表示された画面に全体のサイズが出ていればその数字を、出ていなければ内容をテキストファイルとして保存し、そのファイルサイズを見れば同じことが分かります。

ポイントは、編集画面の文字数ではなく、受信した実物のサイズを見ることです。配信システムが後から加える要素は、送信前の画面には出てきません。受信側の実物を見て初めて、実際に運ばれた量が分かります。

切れた号と切れなかった号の両方があると、境界の位置が一気に絞れます。切れた号が1通あることは、その環境における上限の位置を知るうえでは強い手がかりです。失敗した号を消さずに取っておいてください。

ステップ2：画像1枚あたりのコストを出す

画像の枚数を変えた号どうしを比べれば、1枚あたりの記述量が分かります。私たちの環境では約3,372バイトでした。これを文字数に換算しておくと、「今回は図を2枚入れるから本文は500字削る」という交換が現場でできるようになります。

ステップ3：余白を引いて上限を決める

測った値の上限いっぱいに設定してはいけません。理由はここまでに3つ出ています。境界が一貫しないこと・配信システムが後から加算すること・画像の記述が乗ることです。実測で安全だった水準から、さらに引いた値を採用します。

ステップ4：その上限を機械に持たせる

最後がいちばん大事です。決めた上限を手順書やチェックリストに書くだけで終わらせない。配信前に必ず通る場所に、超えたら止まる条件として置きます。

ルールを文書に書いても、それを守るのは毎回人間の注意力です。バイト数のように人が感じ取れない量については、注意力に任せた時点で運用が成立しません。人が気づけない失敗は、気づける仕組みのほうに移す——対処の本体はここです。

本文を削る前に試す3つの手当て

上限を超えたとき、いきなり内容を削るのは最後の手段です。Email on Acidは、クリッピングが確認された場合の対処を3段階で挙げています。削るべき順番があり、本文はいちばん最後という考え方です。

手当て1：コードの余分な空白やコメントを落とす

同社が最初に挙げるのが、HTMLの圧縮です。コメント・空白など、メールの内容そのものに結びついていない部分を機械的に取り除きます。文章は1文字も減らないのにデータ量だけが減るので、最初に試す価値があります。

ただし同社は「メール用に作られた圧縮ツールを使うこと」と注意を添えています。一般的なWeb用の圧縮をかけると、特定のメールソフト向けに必要な記述まで削ってしまう可能性があるためです。

手当て2：テンプレートそのものを見直す

圧縮しても収まらない場合、同社は「内容の量に対してコードが多すぎないか、テンプレートを見直す時期かもしれない」と述べています。

長年使い回しているメールのひな型は、装飾や入れ子の構造が積み重なって重くなっていることがあります。同じ見た目を、より少ない記述で実現できないかという観点で組み直すと、1通あたりの固定費が下がります。これは一度やれば以降のすべての号に効きます。

手当て3：特殊な文字を実体参照に置き換える

3つめとして同社は、「メールが102KBの上限に対して十分な余裕をもって収まっているなら、特殊な文字をHTMLの実体参照へ変換しておくとよい」と挙げています。前述した非ASCII文字の要因に対する備えです。

ここで注目したいのは、同社がこの手当てに「十分な余裕があるなら」という条件を付けていることです。原文はその理由までは説明していませんが、これはサイズを減らすための手当てではなく、サイズに余裕がある前提で別の要因に備えるものだと読むのが自然です。上限が逼迫しているときに最初に選ぶ手ではない、という順序づけとして受け取っておけば十分です。

よくある質問

Q. 短くするしか手がないのでしょうか

いいえ。Litmusは「Gmailのクリッピングを避けるために内容を大幅に短くしなければならないと考えるのは、理解できるが早計だ」という趣旨を述べ、必要なだけのマークアップに絞り、それ以上は持たないという方向を勧めています。同じ文章量でも、装飾や余分なコードが減れば軽くなります。まず削るべきは本文ではなく、本文を包んでいるほうです。

Q. Gmail以外のメールソフトでも起きますか

クリッピングとして広く知られているのはGmailの挙動です。ここで挙げた102KBという数字もGmailを対象とした作業値なので、他のメールソフトにそのまま当てはまるものとして扱わないでください。ただし「本文が重いと不利になる」という方向自体は共通なので、軽く保つこと自体は無駄になりません。

Q. 自分では切れていないように見えるのですが

送信側の画面では判断できません。自分のGmailアカウント宛てにテスト送信して、受信側で確認してください。なお、同じ件名のメールを何通も自分宛てに送ると、Gmailがそれらをひとつにまとめて表示することがあり、そのせいでテストメールだけが畳まれる場合があります。Mailchimpのヘルプもこの点に触れています。件名を変えて試すのが確実です。

Q. AIに書かせている場合、指示文で長さを制限すれば足りますか

足りません。指示文はあくまでお願いであって、境界ではないからです。長さの指示は守られることもあれば、論点が増えたときに超えることもあります。指示で減らす努力と、超えたら止める仕組みは、どちらか一方では機能しません。AIにメールそのものを扱わせる場合の権限の切り方については、別途整理しています。

AI業務効率化AIにメール・予定を任せる境界の作り方

まとめ

メールが途中で切れる現象について、この記事で整理した要点をまとめます。

• 切っているのは文字数ではなくバイト数。Gmailは約102KBで本文を畳む
• 102KBはGoogleが公表した数字ではなく、各社の観測が一致している作業値。境界は完全には一貫しない
• 日本語はUTF-8で1文字3バイト、送信時の変換でさらに膨らみ、実測で1文字11〜15バイトになる
• 画像ファイルそのものは数えられないが、画像を置く記述は数えられる（実測で1枚約3,372バイト＝本文約250字ぶん）
• 切れると読まれないだけでなく、レイアウト崩れ・開封計測の欠落・配信解除リンクの消失が起きる
• 送信側の画面では気づけないため、上限は人の注意力ではなく機械に持たせる
• 止めるのは上限だけでよい。人が読めば気づける失敗まで機械で止めると、チェックそのものが迂回される

この件で私たちが得た一般的な教訓は、メールに限った話ではありません。「人が感じ取れない単位で決まっている制約」は、必ず機械の側に検査を移す必要があるということです。文字数とバイト数のように、見ている単位と判定される単位がずれている場所は、業務の中に他にもあります。

株式会社Fyveでは、こうした「仕組みで止める」設計を含めて、中小企業のAI活用を月額で伴走支援しています。自動化を進めるほど、人の注意力に頼れない場所が増えていきます。どこを仕組みに移すべきかの判断からご相談いただけます。