違和感の正体は改行でした。アイキャッチ画像をHTMLとヘッドレスChromeで自動生成する仕組みをClaude Codeに組んでもらって、しばらく運用していました。記事タイトルを渡せば画像が出てくるので楽なんですが、ある日できあがった画像を眺めていて「なんか読みにくいな」と感じました。よく見たら、タイトルが変なところで改行されていたんです。
🎥 この記事の内容は動画でも解説しています。
「バラ / ンス」で改行されていた
実例はこれです。実際に起きていたのは、こういう折り返しです。
- 「バラ」で改行して次の行が「ンス」
- 「細か」で改行して次の行が「いのか」
単語の途中どころか、カタカナ語が真っ二つになっています。パッと見の違和感の正体はこれでした。
原因を疑いました。最初は自分のCSSの書き方が悪いのかと思って、word-breakやoverflow-wrapの指定を見直しました。でも、ここを変えても改善しません。というより、そもそも指定していない状態がブラウザの標準動作で、その標準動作が今回の期待と合っていなかった、というのが実際のところでした。
ブラウザは意味を見ていない
英語の文章なら、ブラウザは単語の途中で折り返しません。単語の間にスペースがあるので、そこを区切りとして扱えるからです。
ここが盲点でした。ところが日本語にはスペースがありません。ブラウザから見ると、どこが単語の切れ目なのか判断する材料が文字そのものにはないんです。結果として、指定した幅に何文字入るかだけを見て、そこで機械的に折り返すことになります。「バラ」と「ンス」の間に意味の切れ目がないことは、ブラウザは知りません。
例外もあります。厳密には禁則処理という仕組みがあって、句読点や閉じカッコが行頭に来ないようにする調整はブラウザ側でもやってくれます。ただそれは「行頭に来てはいけない文字を避ける」だけの話で、「意味のまとまりで区切る」こととは別物でした。
自動折り返しをやめて、手で改行位置を決めた
対応はこうです。いろいろ試した結果、自動折り返しに任せるのをやめました。テンプレート側にこう書いて、
white-space: pre-wrap;タイトルの文字列に自分でnを入れて改行位置を指定する方式に変えました。
理由はここです。ここでpre-wrapを選んでいるのは、文字列中の改行をそのまま反映しつつ、それでも幅に収まらない場合は折り返してくれるからです。preだと折り返しが一切効かなくなるので、想定より長いタイトルが来たときに画像からはみ出してしまいます。保険を残しておきたかったのでpre-wrapにしました。
改行位置は、句読点の直後を基本にしています。読点で切ればだいたい意味のまとまりになるので、迷うことが少ないです。読点がない場合は助詞の後ろで切っています。
自動化を一段あきらめた話でもある
トレードオフはありました。この対応をするということは、タイトルを渡すだけで画像ができる状態から、改行位置を毎回考える状態に戻ったということでもあります。手間としては増えました。
差は歴然でした。ただ、実際に自動生成された画像を並べて見ると、不自然な改行があるものは明らかに素人っぽく見えてしまいます。ブログのアイキャッチは記事一覧やSNSで並んで表示されるので、そこで安っぽく見えるのは避けたいところでした。1本あたり数秒で済む作業なので、この交換は妥当だったと思っています。
教訓はここにあります。全部を機械に任せられないことが分かったときに、無理に自動化を守るより、人が入る場所を1箇所だけ決めてしまう方が結果的に楽だ、というのは他の場面でもありそうな話だなと思いました。
生成した画像は必ず目で見る
もうひとつ運用として決めたのが、生成した画像は必ず一度目で確認してから使うことです。
落とし穴もあります。改行位置を手で指定していても、フォントサイズの自動調整が絡むと想定と違う見え方になることがあります。文字数が多いタイトルではサイズが小さくなるので、そのぶん1行に入る文字数が変わって、指定した改行位置と合わなくなるんです。
スクリーンショットを撮って終わりにせず、一度開いて眺める。この数秒を挟むだけで、変な画像がそのまま公開される事故は防げています。
まとめ
結論はシンプルです。日本語の自動折り返しは、ブラウザが手を抜いているわけではなくて、単語の区切りを判断する材料がそもそもない、というだけの話でした。仕組みが分かってしまえば「じゃあ人が教えるしかないな」と納得できます。
日本語のテキストを画像やスライドに流し込む処理を書くときは、最初から改行位置を手で持てるようにしておくと後が楽だと思います。
この記事が参考になったら、応援クリックをお願いします
