文字サイズ最大でも盤が溢れない：AIとやった Dynamic Type 対応

子ども向けのボードゲームアプリを iOS で作っています。本体の設定で文字を大きくしても、このアプリの文字だけは1ピクセルも変わりませんでした。この記事では、その直し方を Claude Code に頼んだときに、どの画面が崩れ、どう逃がしたかを書きます。

作りたかったもの

やりたかったのは2つです。ひとつは Dynamic Type への対応。Dynamic Type は、本体の設定で決めた文字の大きさに、アプリの中の文字も合わせる仕組みです。目が見えにくい人だけでなく、小さい文字が読みづらい大人も使います。

もうひとつは iPad で文字が小さすぎないようにすること。台帳に書いた完了の条件は、「本体の文字サイズ設定を変えると画面の文字も変わる」「iPadで文字が小さすぎない」の2行でした。

AIへの頼み方

直す作業は Claude Code に任せました。画面の中の文字指定を探して置き換える仕事は、数が多いわりに判断がほとんど要りません。こういう作業はAIのほうが速く、抜けも少ないです。どこまでやるかを決めるのは私、実際に直すのは Claude Code、という分け方にしました。

頼んだのは、固定の大きさで書かれた文字指定をすべて探し、本体の設定に追従する書き方に置き換えること。そのうえで、文字を最大にしたときに崩れる画面を直すようにも頼みました。実際の指示文は記録に残していないので、ここでは要約で書いています。

固定の大きさというのは、「17ポイント」のように数で書いた指定のことです。ポイントは画面上の文字の大きさの単位で、数で書くと本体の設定をどう変えても動きません。代わりに使うのが、Apple が用意している「テキストスタイル」です。見出し用、本文用、注釈用といった役割の名前で指定すると、本体の設定に合わせて大きさが変わります。今回割り当てたのは8種類で、内訳は大きさの違う見出しが4段階、本文、補足、小さめの見出し、注釈です。

丸ゴシックのような書体は、画面ごとに指定するのをやめました。アプリ全体の起点になる場所で一度だけ「丸い書体を使う」と指定し、その下の画面すべてに効かせています。同じ見た目を各画面で書き直すと、どこかで書き忘れたときに1画面だけ字体が違う、という崩れ方をするからです。

つまずいたところ

文字の指定を置き換えた直後に、画面の中身が入りきらなくなりました。文字が大きくなるぶん、置き場所が足りなくなるからです。崩れ方は画面ごとに違いました。

まるばつの2つの画面では、下にある「もういっかい」ボタンが画面の外へ押し出されました。押せないので、1局終わったら先に進めません。マインスイーパーの画面では、「あける／はた」の切替と、残りの数のカウンターが、横一列に並びきらなくなりました。

盤の中も問題でした。マスに入る記号や数字まで本体の設定に合わせて大きくすると、文字だけが育って盤からはみ出します。盤は正方形のマスが並ぶもので、外の文字とは事情が違いました。

どう判断したか

崩れた場所ごとに、逃がし方を変えることにしました。全部を同じやり方で直そうとすると、どこかに無理が出ると考えたからです。次の図は、その分かれ道を表しています。

flowchart TD
  A["文字が大きくなって入らない"] --> B{"どこが入らないか"}
  B -- "縦に長くなった" --> C["スクロールできるようにする"]
  B -- "横一列に並ばない" --> D["入らなければ縦に落とす"]
  B -- "盤の中の記号" --> E["マスの大きさに比例させる"]

縦に長くなる画面には、スクロールできる入れ物を足しました。まるばつの2画面がこれです。画面の外に出た「もういっかい」は、下にスクロールすれば出てきます。あわせて、このボタンの見た目を2画面で共通の部品にそろえ、画面によって形が変わらないようにしました。

横一列が入らないマインスイーパーの操作部分には、SwiftUI の ViewThatFits という部品を使いました。「横並びで置いてみて、入らなければ縦並びにする」という判断を、自分で書かずに任せられます。「この文字サイズを超えたら縦」と数で線を引くより、実際に入るかどうかで決めたほうが、端末や設定が変わっても崩れません。

盤の中の記号と数字は、本体の設定から切り離し、マスの大きさに比例させました。マスが大きければ記号も大きい、という関係です。これなら文字を最大にしても盤から溢れません。

その代わり、盤の中の文字は本体の設定を大きくしても変わりません。盤そのものを大きく表示する機能は、今回は対象外にしたからです。文字だけを追従させる作業と、盤の見え方を変える作業は別物で、一緒にやると確かめる範囲が広がりすぎると判断しました。ここは私が引いた線です。

iPad は、縦横4方向すべてで使えるようにしました。設定ファイルの iPad 用の項目に4方向を書いています。Apple の技術ノート TN3192（iPad アプリを古い設定から移行するときの案内）の方針に合わせた形です。iPhone の向きは今回さわらず、縦のみのままにしました。

できたもの

確かめたことを並べます。もともとあったユニットテスト（画面を出さずに、計算や判定の部分だけを自動で確かめる仕組み）は103件すべて通りました。

画面を実際に触って確かめるテストは4件足しました。中身は、文字サイズを最大にした状態でまるばつを1局遊べること、同じ状態でマインスイーパーの切替を押せること、iPad を横向きにしてまるばつを1局遊べること、同じく盤と切替を押せることの4つです。文字サイズは、アプリを起動するときに「一番大きい設定で立ち上げる」と指定して再現しています。

この4件を足して、画面を触るテストは合計23件になりました。iPhone 17 Pro で走らせると、iPad でしか意味のない2件は飛ばされ、残りはすべて通過。iPad Pro 11インチでは、その iPad 専用の2件が通りました。あわせて、文字サイズを最大にしたタイトル画面を画像に残し、以前は1ピクセルも変わらなかった文字が、設定どおり大きくなってスクロールできることを目で確かめています。iPad を横向きにした画像でも、勝敗の表示・盤・「もういっかい」が1画面に収まっていました。ビルドし直したときの警告も0件です。

確かめていないことも書いておきます。標準の文字サイズでの見え方が、以前と1〜2ポイントずれる可能性があります。この差は画像を並べて見比べていません。実機での確認と、画面を読み上げる機能（VoiceOver）の読み上げ方も、まだ試していません。

まとめ

文字の大きさを数で書くのをやめ、役割の名前（テキストスタイル）で指定すると、本体の設定に追従します。置き換え作業そのものはAIに任せやすい仕事です。
追従させると画面は必ず崩れます。縦に伸びるならスクロール、横に並ばないなら縦に落とす、盤の中は別扱い、と場所ごとに逃がし方を変えると直しやすくなりました。
どこまでやるかは自分で決めます。今回は盤の拡大表示を対象外にして、確かめる範囲を小さく保ちました。

次は実機と VoiceOver で確かめ、標準サイズでの見え方のずれを見比べます。

参考にした資料

この記事は、筆者の開発記録をもとにAI（Claude）が下書きし、筆者が確認して公開しています。