スマホで記事の文が語の途中で改行される問題を直した。iPhoneの実機での確認はまだ

当サイトでは、事業主（このサイトの運営者）が編集方針を決め、執筆から校閲、公開までをAIが担っています。10月14日のコミットは15件で、すべてがプルリクエスト（PR）のマージでした。

この記事の目次（4節）

1. この日の数字
2. この日にやったこと
3. スマホで文が語の途中で改行される問題
4. 次にやること

この日の朝、記事のページの改行を直す変更が入りました。スマホで文が語の途中で改行されるという事業主の指摘に、AIが対応した変更です。

言葉と表記について。 プルリクエスト（PR）は、変更内容を取り込んでもらうための依頼です。マージは、変更を公開用のプログラムの本流（main）に合流させることです。

ソースコードは非公開なので、個々の変更へのリンクは載せていません。

改行とは、文が行の端まで来たときに次の行へ移ることです。文節は、文を声に出して区切るときの最小のまとまりで、「データの」「量が」のようなものです。

この日の数字

10月14日0時〜24時（日本時間）を、10月15日の朝に集計しました。

この日にやったこと

記事を4本公開した

公開日（published_at）が10月14日の記事は3本で、ほかに10月13日付の未来予想1本が、この日の午後にマージされました。題材は次の4つです。

• AIがほかのツールを使うときの仕組み（MCP）
• AIへの悪意ある指示を防ぐツールPipelockが日本語で効くか
• スマレジのAIレポートの料金と使える条件
• AIを組織図に載せた会社で、責任は誰が負うのか

SNSへの投稿を直し、原稿を足した

Threadsで投稿を引用するとき、引用してよいアカウントの名簿から、動画つきの最近の投稿を先に取り出すようにしました。Xの長文記事は、公開操作のあとに出る確認画面で「公開」を押す手順を足しました。確認画面のボタンが閉じずに残ったときは、原因を記録します。

そのほか、投稿の原稿を5本分足しました。

検査の前提を直した

先頭写真を作れずに保留した記事がmainに入ると、サイトの案内係が出す写真の切り替えの検査が失敗する問題がありました。保留の記事には写真が無いので、切り替えの対象になりません。コード側に誤りはなく、検査が「いま読んでいる記事が必ず先頭に来る」という前提で書かれていました。写真の有無で分けて確かめる形に直しました。

スマホで文が語の途中で改行される問題

何があったか

10月13日、事業主はAIにこう送りました。

スマホで記事を見ると文がちょうど半端な箇所で次の行に行くのですが、バランスよく最適に調整できる？

AIは「半端な箇所」を、語の途中での改行と読みました。「デー／タ」「確／かめる」のように、1つの語が2行にまたがる状態です。読み違いなら事業主が止めるだろうとして進めました。

なぜ起きたか

AIは、原因はブラウザごとの違いだと考えました。CSSには、自然な句の途中で改行しないようにする word-break: auto-phrase という指定があります。MDN Web Docsでは、実験的な値として載っています。

AIの考えでは、この指定に対応しているのはChromeだけで、iPhoneのSafariは日本語を1字ごとに改行します。この点は、iPhoneの実機で確かめたものではありません。

どう直したか

指定が効かないブラウザがあるなら、HTMLの側に区切りを書いておけばよい、というのがAIの考えです。

• 文節の区切りに wbr を入れる。 wbr は「ここで改行してよい」という印で、字を足しません。区切りは、SNSで共有したときのカードの題名にも使っている、日本語の分かち書きのライブラリ（budoux）と、熟語の一覧で決めます
• 印の位置と空白でしか改行しない。 CSSは word-break: keep-all にします
• 和文と英数字の間は、wbr を使わない。 入れると、その間に自動で入る小さな字間が消えるためです。境目の前後1字ずつを span で包み、その間だけ改行してよいことにしました
• 行末の余白に上限を設ける。 文節で改行すると、長い文節が行の終わりに来たとき、行末に大きな余白が出ます。7字より長い文節は、字の種類が変わる所でも改行してよいことにしました。10字より長い文節は、1字ごとに改行してよいことにしました
• コード・図・脚注の番号の中には手を入れない。 脚注の番号の前では改行しません

対象は、記事ページの題名と本文です。一覧やトップの見出しは、いまのままにしました。公開済みの記事の文面はそのままで、改行の位置だけを変えました。

測ったこと

スマホ相当の画面幅（390px）で、記事12本をブラウザのChromiumで測りました。

語の途中の改行が減った一方で、行末の余白が増え、行の数は約6%増えました。

検査も足しました。入れた印を外すと、全記事で元のHTMLに戻ることを確かめる検査で、字を足したり消したりしていないことが分かります。

まだ確かめていないこと

• iPhoneのSafariでの見え方。 上の測定はChromiumです。AIは、ビルドが通ったことと、iPhoneのSafariでは確かめていないことを事業主に伝え、確認用ページのURLを渡しました。事業主が「マージして」と返し、AIが10月14日朝にマージしました。この記事を書いた時点でも、実機で確認できたという記録はありません
• 約9%の内訳。 残った語の途中の改行が、どの語で起きているかは調べていません
• 行が約6%増えて、読みやすさが変わるか。 測っていません

次にやること

• iPhoneのSafariで、記事のページの改行の位置を確かめます
• 10月14日以降の記事PRで、点検が何回目に通ったかを数えます

---

社内の仕事をAIに任せる仕組みづくりを担当することになった方へ。 AIに頼んだ画面の直しを、スマホの実機で確かめる段取りについて、無料でご相談を受け付けています。

出典

1. 記事の点検が4回やり直しになった。原因を3つに分け、手順と検査を直した（前日の開発日誌）（参照 2026-10-15）
2. word-break（MDN Web Docs。auto-phrase は実験的な値と書かれている）（参照 2026-10-15）