スマホで日本語の見出しが崩れたとき、GAOCRAFTが直したこと

スマートフォンで記事を確認していると、見出しの最後の一文字だけが次の行に送られていることがあります。

GAOCRAFT公式サイトでも、そんな表示に出会いました。

「公開は完成ではな」の次の行に「く」。

「まだ判断できな」の次の行に「い」。

文章は読めます。でも、読んだ瞬間に少し引っかかる。見出しとして伝えたい意味のまとまりが、途中で切れていたからです。

2026年10月7日、FIELD NOTESの記事をiPhoneで確認していたときに、この問題を見つけました。CSSを一度変えれば終わり、という修正にはなりませんでした。

今回は、どんな順番で直そうとし、何がうまくいかず、最終的に共通の見出しスタイルをどう見直したのかを記録します。日本語の改行に万能なCSSを紹介する記事ではなく、GAOCRAFTで実際に起きた小さな改善の話です。

スマホで、日本語の見出しが途中で切れていた

問題が見つかったのは、FIELD NOTES第3記事「公開して終わりにしないWebプロダクトの育て方」の公開後です。

iPhone幅の画面でH2見出しを確認すると、次のような位置で折り返されていました。

• 公開は完成ではな / く

• まだ判断できな / い

ここでの / は、実際に確認した改行位置を表しています。

文字が欠けていたわけでも、リンクが壊れていたわけでもありません。それでも、見出しの最後に一文字だけ残ると、読み手はそこで一瞬立ち止まります。

英語なら単語と単語の間にスペースがあることが多いですが、日本語の文章では、見た目の文字数だけで自然な区切りを決められません。横幅に収めることと、意味のまとまりを読みやすく保つことは、同じではありません。

このとき確認できたのは、特定のiPhone幅で不自然な改行が起きていた、という事実です。すべてのスマートフォンで同じ位置に改行が入ると分かったわけではありません。

最初は text-wrap を変えた。でも直りきらなかった

pretty から balance へ

最初の変更では、見出しに使っていた text-wrap を見直しました。

変更内容はシンプルです。

/* 変更前 */
text-wrap: pretty;

/* 最初の変更 */
text-wrap: balance;

pretty は読みやすい折り返しを目指す指定、balance は複数行の長さのバランスを取ろうとする指定です。

GAOCRAFTでは、見出し全体の行のバランスを整えれば、気になっていた表示も改善するのではないかと考えました。実際、一部は改善しました。

見た目のバランスと、言葉のつながりは別

ただし、それだけでは終わりませんでした。

balance に変更したあとも、先ほどの「ではな / く」「できな / い」のような分断が残りました。

見出し全体の行の長さが整っても、日本語として自然な場所で折り返されるとは限りません。

つまり、「行の見た目を整える指定を追加した」ことと、「読んだときの違和感を解消した」ことは、別の確認が必要だったのです。

最初の変更を無駄だったとは考えていません。でも、そこで修正完了とはしませんでした。

スマホ専用ルールで、別の問題も確認した

560px以下のH2に追加したCSS

次に、スマートフォン程度の狭い画面幅へ向けて、H2に専用の改行ルールを追加しました。

当時の変更では、幅560px以下の見出しに次の指定を入れています。

@media (max-width: 560px) {
  .body h2 {
    text-wrap: wrap;
    word-break: keep-all;
    overflow-wrap: normal;
    line-break: strict;
  }
}

このコードはその時点で採用したものです。現在の最終的な設定とは一部異なります。

ここで目指したのは、短い見出しを無理に一行へ押し込むことではありません。画面に合わせて折り返しつつ、日本語の区切りや句読点をできるだけ不自然にしないことでした。

anywhere で句読点が行頭に出た

2026年10月7日の検討では、BudouXを使わずに、文字が画面幅からはみ出しにくくなるよう overflow-wrap: anywhere を使う案も試しました。

ところが、そのPreviewを実機で確認すると、別の違和感が出ました。

PreviewとProductionの確認も / 、改善ループの一部

読点の「、」が次の行の先頭に来てしまったのです。

anywhere は、通常の位置で折り返せない文字列を途中で分割するために役立つ指定です。一方で、今回試した組み合わせでは、見出しを日本語として自然に読める状態にはできませんでした。

この組み合わせは採用しませんでした。

その後、PR #23・#24でBudouXの区切りと組み合わせて再検証し、現在のmainではこの別構成を採用しています。10月7日の結果は、そのとき試した組み合わせの記録です。

大切なのは、横にはみ出さなくなったかどうかだけを合格条件にしなかったことです。画面の中に収まっていても、文章として読みにくければ、まだ直す余地があります。

別の記事でも共通CSSを見直した

keep-all を入れた状態が、最後の答えではなかった

ここまでで、ひとまず見出しの改行ルールを調整できました。

しかし、同じ10月7日、別のFIELD NOTES記事の公開作業でも、スマートフォンで見出しがはみ出さないようにする修正が必要になりました。

そのときに変更されたのが word-break です。

/* 先の修正 */
word-break: keep-all;

/* 後続の修正 */
word-break: normal;

keep-all は、日本語などのCJK文字の途中で改行することを制限する指定です。言葉を途中で切りたくない場面では有力な候補ですが、長い見出しと狭い画面幅の組み合わせでは、折り返しを制限しすぎることもあります。

今回の修正履歴から確実に言えるのは、後続の変更で keep-all から normal に切り替えた、ということです。ひとつの表示例から、あらゆる端末での原因や最適解まで決めたわけではありません。

2026年10月10日時点のmainでは normal を使っていた

2026年10月10日にGitHubの main で確認した、560px以下のH2の設定です。

@media (max-width: 560px) {
  .body h2 {
    text-wrap: wrap;
    word-break: normal;
    overflow-wrap: normal;
    line-break: strict;
  }
}

これは確認日のmainにあった設定の記録で、記事の公開時点や現在の設定を示すものではありません。幅560pxより広い画面向けのH2には、text-wrap: balance や word-break: auto-phrase の指定もありました。つまり、画面幅に応じて同じ見出しに異なるルールが適用されていました。

最初の改行対策と、あとから発生したはみ出し対策。その両方を経て、2026年10月10日のmainではこの共通CSSになっていました。

一方、FIELD NOTES #006のDraft Previewでは、H2「スマホで、日本語の見出しが途中で切れていた」の「途／中」と、H3「keep-all を入れた状態が、最後の答えではなかっ／た」が確認課題になりました。PR #23ではH2、PR #24ではH3にBudouXを適用し、文節の境界へ <wbr> を挿入する方法を検証しました。

PR #23では390pxのChromiumで、対象H2が「途中で」のまとまりで折り返すことを確認しました。PR #24ではH3にも処理を適用しました。ローカルChromiumでは修正前の「なかっ／た」という分断を再現できませんでした。Humanは統合Draft PreviewをiPhone Chromeで確認し、対象H3の末尾「た」が孤立せず表示されたと報告しています。これはiPhone Chromeで修正前後を比較した結果ではありません。

2026年10月10日、Humanが同じ統合Draft PreviewをiPhone Safariで確認しました。対象H2の「途中」は分断されず、対象H3の末尾「た」も孤立せず、図解①も読みやすく表示されました。一方、図解②・③には一部不自然な改行が残っていました。この確認は厳密な修正前後比較ではなく、すべての見出しや端末での改善を示すものでもありません。その後、BudouXを含む実装はmainに取り込まれました。ここで述べた実機結果は当時のPreviewについての記録です。

現在の実装を再現するには

現在のmainでは、H2・H3の通常テキストをBudouXで区切り、Intl.Segmenter で単語途中や一文字の区切りを補正してから、区切りに <wbr> を挿入しています。強調・リンク・コードなどの内側は同じ処理の対象外です。サーバー側でReact要素として出力し、本文の文字自体は変えません。

次は仕組みを示す最小例です。実際のGAOCRAFTの補正処理は含まないため、この例だけで同じ区切り結果にはなりません。budoux を導入したReact環境で使えます。

import { Fragment } from "react";
import { loadDefaultJapaneseParser } from "budoux";

const parser = loadDefaultJapaneseParser();

function Heading({ text }: { text: string }) {
  return <h2>{parser.parse(text).map((part, index) => (
    <Fragment key={index}>{index > 0 && <wbr />}{part}</Fragment>
  ))}</h2>;
}

現在の560px以下のH2・H3で共通する設定は次のとおりです。H2には加えて text-wrap: wrap が適用されます。

@media (max-width: 560px) {
  .body h2, .body h3 {
    word-break: keep-all;
    overflow-wrap: anywhere;
    line-break: strict;
  }
}

<wbr> は改行候補で、そこで必ず改行する指定ではありません。長い英数字やインライン要素を含む見出し、句読点も対象に加え、実際に使うフォントとブラウザーで確認してください。anywhere は長い文字列のはみ出しを防ぐ一方、望ましくない位置でも折り返す可能性があります。

最初に決めた設定をずっと守るより、別の文章や画面で問題が見つかったときに見直せる方が大切だと考えています。

4つのCSS指定は、同じ仕事をしていない

text-wrap と word-break

今回登場したCSSには、似た名前のものがいくつもあります。でも、担当している役割は同じではありません。

text-wrap は、文章を行に分ける際の振る舞いや、折り返した行のバランスに関係します。balance にすれば行の長さを整えようとしますが、見出しに含まれる日本語の意味を完全に理解して改行位置を決めてくれるわけではありません。

word-break は、どこで文字を分割してよいかという規則に関係します。keep-all と normal では、日本語のような文章で許される折り返し方が変わります。

なお、GAOCRAFTの幅広画面向け指定にも使われている auto-phrase は、言語に応じて自然な語句のまとまりを考慮するための値ですが、ブラウザーによって対応状況が異なります。

overflow-wrap と line-break

overflow-wrap は、通常の区切りで折り返せない文字列があるとき、はみ出しを防ぐために追加の分割を許すかどうかに関係します。

line-break は、特に日本語・中国語・韓国語などの禁則処理を含む、改行の厳しさに関係します。今回の strict は、より厳格な改行規則を使う指定です。

それぞれの役割を区別しないまま「改行しそうなCSS」をいくつも重ねると、ひとつの問題が消えても別の問題が生まれることがあります。

今回も、行のバランス、語途中での分断、句読点の位置、画面からのはみ出しを、別々の観点として確認しました。現在のmainでは10月7日とは異なり、BudouXの <wbr> と overflow-wrap: anywhere を組み合わせています。

これらの指定だけで、あらゆる日本語の見出しが必ず自然になるとは言えません。フォント、画面幅、ブラウザー、文章の長さでも結果は変わります。

なぜ見出しごとの手動改行にしなかったのか

記事ごとに改行を埋め込まない

例えば、問題になった見出しにだけ手動で改行を入れれば、ある画面幅ではきれいに見せられるかもしれません。

しかし、文章が変わったらどうでしょう。別のスマートフォンではどうでしょう。

GAOCRAFTでは、今回の問題に対して、見出し本文へ個別の <br> や目に見えない区切り文字を追加する方法を選びませんでした。

その場の一画面に合わせた行分けを記事ごとに増やすと、あとから変更するときに、どの記事のどこを調整したのか分かりにくくなるからです。

共通CSSの責務として直す

FIELD NOTESの見出しには共通のスタイルがあります。だからこそ、一つの記事で不自然な改行を見つけたとき、同じ仕組みを使う記事全体で考える必要があります。

もちろん、共通CSSを変更すると別の記事にも影響します。実際、後続の記事でさらに調整が必要になりました。

共通化しているから一度直せば終わり、というわけではありません。共通化しているからこそ、変更の影響をほかの記事でも確認し、必要ならもう一度直す。

今回は、その方針を選びました。

PreviewとiPhone実機では確認できることが違う

語途中の分断、句読点、横方向のはみ出しを見る

コードを変更してビルドが成功することは大切です。Previewでページを開き、狭い幅で表示を確かめることも欠かせません。

ただし、それだけでiPhone上の日本語見出しの読みやすさまで保証できるわけではありません。

自分のサイトでは、まず修正前の表示を保存し、同じフォント・幅で修正後と比較します。375px・390pxなどの狭い幅とPC幅で各記事のH2・H3を見て、実際に対象とする端末でも次の点を確認します。

• 「ではな / く」のように、意味のまとまりが途中で切れていないか

• 読点や句点が不自然に行頭へ来ていないか

• 見出しが画面の右側にはみ出していないか

• 見出しの文字が変わっていないか、リンクや強調を含む箇所が読めるか

• 表やコードを横スクロールでき、ページ全体が横にはみ出していないか

画面に収まっているか、という技術的な確認と、文章として読みやすいか、という確認を分けて見るようにします。

Preview、実機、Productionの確認をつなげる

今回の作業では、Previewでの変更確認に加えて、HumanがiPhone実機で表示を確認しました。修正後はProductionでも見出しの表示を確認しています。

実装や自動テストで確認できることと、読む人の目で確認することは違います。特に日本語の見出しは、文章の長さや改行位置によって違和感の出方が変わります。

だから、新しい記事を追加したときにも、本文の内容だけでなく、スマートフォンでのH2の見え方を確認する必要があります。

「前の記事で直したから、次の記事も問題ない」とは考えないようにしています。

今回の学び｜改行位置を固定するより、読みやすい状態を守る

今回の問題は、最初のCSS変更だけでは解決しませんでした。

pretty から balance に変えたあとも、不自然な改行は残りました。スマートフォン用のルールを追加する過程では、句読点が行頭に出る案も見つかりました。さらに別の記事では、共通CSSをもう一度見直しました。

もし「横にはみ出していなければOK」としていたら、読みにくさを見落としていたかもしれません。

反対に、特定の端末で改行位置をぴったり固定しようとしていたら、記事ごとの手動調整が増えていたかもしれません。

今回GAOCRAFTが重視したのは、決まった場所で必ず折り返させることではありません。

意味が途中で切れすぎないこと。句読点が不自然にならないこと。画面からはみ出さないこと。そして、別の記事でも確認を続けられること。

この4つを、実機を見ながら少しずつ調整することでした。

見出しの改行は小さな問題に見えます。でも、読む人にとっては、ページを開いた瞬間から関わる部分です。

GAOCRAFTでは、こうした小さな違和感も、公開後に見つけたら記録し、直し、次の制作へつなげていきます。

公開後に何を観測して改善するのかという全体の考え方は、「公開して終わりにしないWebプロダクトの育て方」にも記録しています。今回の見出し修正は、その考え方を実際の画面で試した一例です。