メール本文の整形｜RFC 5322の78字推奨を実務で使う

1. RFC 5322が定める本文行長

IETFが管理する RFC 5322「Internet Message Format」の Section 2.1.1「Line Length Limits」では、メール本文の1行の長さを次のように定めています。

• ・推奨：78 octets以下（CRLFを除く）
• ・上限：998 octets以下（CRLFを除く）

この「octets」はUTF-8でエンコードしたバイト数のことで、ASCII文字なら1字＝1 octet、日本語（ひらがな・漢字）なら1字＝3 octetsです。つまり、ASCIIなら78文字、日本語なら26文字（78÷3）でCRLFまでに収める必要があるという推奨です。

2. 日本語環境での「全角36〜40字」が基準になる理由

日本のビジネスメールでは「全角35〜40字で改行」というローカルルールが広く使われていますが、これはRFC 5322の78 octets推奨と若干乖離します。

• ・全角40字＝120 octets → 78 octets推奨を超える（998上限内）
• ・全角26字＝78 octets → 厳密推奨に収まる
• ・全角36字＝108 octets → 推奨超過だが視認性重視のローカル慣習

MUA（Outlook・Gmail・Apple Mail）は78 octets超過でもエラーにせず受け取れるよう実装されているので、日本のビジネスメールで全角36〜40字運用してもメール配信に問題はありません。ただし、英語と日本語が混在するメールでは英語パートが78 octets内に収まるかを意識してください。

3. 各MUAの自動折り返し挙動

主要なメールクライアントは、送信時にRFC 5322の上限998 octetsを超えないように自動的に折り返しを入れます。

• ・Outlook：プレーンテキスト送信時に1行76文字相当で自動改行（オプションで変更可）
• ・Gmail：HTMLメールでは折り返しを入れない／プレーンテキストでは表示時に折り返し
• ・Apple Mail：送信時に78 octetsを目安に自動改行
• ・Thunderbird：「format=flowed」エンコードで送信時72字推奨

MUAの自動折り返しに依存すると、受信側で意図しない位置で改行されることがあります。重要なビジネスメールでは、本ツールで事前に全角36字や78 octets相当に整形してから送信するのが確実です。

4. ビジネスメールで読みやすい段落設計

行長だけでなく、段落の長さも読みやすさに直結します。ビジネスメールの実務では、以下を意識すると読み手の負担が下がります。

• ・1段落＝3〜5行程度（多くても7行）
• ・段落と段落の間は1行空ける（空行を入れる）
• ・1メールあたりの段落数は3〜5段落（用件1つにつき1段落）
• ・箇条書きは「・」または「-」で揃え、文の途中で折り返さない
• ・引用（>）は2階層まで（>>以上は読みにくい）

本ツールで全角36字で分割すると、自動的に段落感が出るので、長文の打診メールや謝罪メールでも視覚的に整います。

5. 998 octets超過は何が起きるか

RFC 5322の998 octets上限を超えると、メール配信時に次の問題が起きる可能性があります。

• ・古いMTA（メール転送エージェント）でメッセージが拒否される
• ・SMTPのformat=flowedエンコードが崩れる
• ・スパム判定スコアが上がる（特定のフィルターで）
• ・受信側MUAが意図しない位置で改行を挿入する

実際のところ現代の主要MUA・MTAは998 octets超過でもほぼ問題なく配信できますが、社内メーリングリストやレガシー受信側がある場合は、本ツールで300字（約900 octets）以下に分割しておくと安全です。

6. 関連ツール・記事

• ・長文を文字数で分割：全角36字プリセットで本記事の推奨が一発適用
• ・SNS別 文字数上限完全ガイド：X・LINE・Slackなどの上限
• ・AIプロンプト分割の作法：Claude/ChatGPTに長文を渡す
• ・テキスト整形：メール下書きから余計な空白・改行を除去