業務の引き継ぎを題材にしたブラウザゲーム「引き継ぎラボ」を作りました。背景・立ち絵・台詞の窓・選択肢・手帳が1画面に重なる、ノベルゲーム（ADV）風の画面です。
この手の画面は、画面サイズが変わると静かに壊れます。選択肢が別の窓の下に潜る、台詞が窓の外で切れる、ページが少しだけスクロールする。どれもエラーは出ません。スクリーンショットを目で見ても、1〜2枚では見落とします。
そこで、Playwrightで「押せるか・切れていないか・はみ出していないか」を11の画面サイズ × 9場面で機械的に検査しました。その検査の書き方と、検査があって初めて見つかった罠をまとめます。
前提
- TypeScript + Vite の静的サイト（サーバー通信なし）
- 単体テスト：Vitest 71件（判定ロジックはDOMに触らない純粋関数に分離）
- 画面のテスト：Playwright 1.56 + Chromium、39件
- 設計方針：ページ全体はスクロールさせない。1画面に収め、内容が溢れたときだけ特定の窓の中をスクロールさせる
検査1：ボタンの中心を、本当にそのボタンが受け取るか
重なりの多い画面で一番起きるのは、「表示はされているのに、上に別の要素がかぶっていて押せない」状態です。toBeVisible() は通ってしまいます。
document.elementFromPoint() で、ボタンの中心座標でポインターイベントを受け取る要素を取り、それがボタン自身（か、その子孫）かを確かめます。pointer-events: none の飾りは飛ばされ、画面外の座標では null が返ります。
for (const button of document.querySelectorAll<HTMLButtonElement>(".try-controls button, .stock button, .write button")) {
if (!visible(button) || button.closest(".is-off")) continue;
const rect = button.getBoundingClientRect();
const x = rect.left + rect.width / 2;
const y = rect.top + rect.height / 2;
const hit = document.elementFromPoint(x, y);
if (!hit || !button.contains(hit)) {
faults.push(`押せない: ${button.textContent?.trim().slice(0, 24)} → ${hit?.className ?? "画面外"}`);
}
}
失敗メッセージにかぶっている側のクラス名を出すのがポイントです。「選択肢が手帳の下に潜っている」と、名前ですぐ分かります。
Playwrightの click() も、クリックの前に「その位置で他の要素にイベントを奪われないか」を確認します（表示・安定・有効の確認と合わせた actionability check）。ただし、確認するのは押そうとした1つだけで、失敗の出方はタイムアウトです。この検査なら、その場面にある全ボタンの状態を1回で一覧にできます。中心点だけの確認なので、端が隠れているかまでは見ていません。
検査2：overflow: hidden の中で切れていないか
2つ目は「切れ」です。窓に overflow: hidden を付けていると、中身が溢れても画面上は見えなくなるだけで、エラーも警告も出ません。
子孫まで全部たどり、overflow が hidden か clip の要素で scrollHeight > clientHeight になっているものを探します。
for (const root of document.querySelectorAll<HTMLElement>(".order, .stock, .try-controls, .pane-work .stage")) {
for (const node of [root, ...root.querySelectorAll<HTMLElement>("*")]) {
if (!visible(node)) continue;
const style = getComputedStyle(node);
if (["hidden", "clip"].includes(style.overflowX) && node.scrollWidth > node.clientWidth + 1 ||
["hidden", "clip"].includes(style.overflowY) && node.scrollHeight > node.clientHeight + 1) {
faults.push(`切れ: ${node.className} ${node.scrollWidth}x${node.scrollHeight}/${node.clientWidth}x${node.clientHeight}`);
}
}
}
親だけを見ても検出できません。 最初は、スクロールできる窓（.pane-body）の scrollHeight だけを見ていました。ところが、窓の中の場面に overflow: hidden と min-height: 0 が付いていると、場面は窓の高さに合わせて縮みます。はみ出た台詞は場面の中で切られるので、親の scrollHeight には現れません。3つ目の選択肢が見えないのに、テストは通っていました。
+1 は、小数点のピクセルの丸めで誤検知しないための余白です。なお、これは「hidden/clip の要素で溢れが起きているか」を見る検査で、あらゆる切れを証明するものではありません。この画面で実際に起きた、内側の窓での切れを捕まえるためのものです。
検査3：ページがスクロールしないか
「ページ全体はスクロールさせない」の検査です。scrollY が0かを見るだけでは、まだスクロールしていないだけかもしれません。実際に端までスクロールさせて、動かないことを確かめます。
scrollTo(10000, 10000);
if (scrollY !== 0 || scrollX !== 0) {
const protruding = [...document.querySelectorAll<HTMLElement>("body *")]
.filter((n) => n.getBoundingClientRect().bottom > innerHeight + 1)
.slice(0, 8)
.map((n) => `${n.className}:${Math.round(n.getBoundingClientRect().bottom)}`);
faults.push(`ページがスクロールする x=${scrollX} y=${scrollY}: ${protruding.join(", ")}`);
}
scrollTo(0, 0);
失敗したときは、画面の下端より下に出ている要素を最大8個並べます。意図して画面外に置いた要素も混ざるので、あくまで原因の候補ですが、たいていはこれで見当がつきます。この画面では scroll-behavior: smooth を使っていないので、scrollTo() の直後に位置を読んでいます。
検査4：台詞が画面の外に出ていないか
台詞の窓・吹き出し・地の文は、getBoundingClientRect() の上下が画面の中にあるかを見ます。切れの検査（検査2）とは別に要ります。絶対配置の要素は通常の配置の流れから外れるので、置き方によっては、検査2で見ている窓の溢れとして現れないまま画面外へ出るからです。
11の画面サイズ × 9場面で回す
検査は1つの関数（expectAdvLayout）にまとめ、画面サイズごとに1テストを生成します。
const LAYOUT_SIZES = [
[1920, 960], [1600, 860], [1440, 800], [1366, 768], [1280, 900],
[1100, 800], [960, 1000], [390, 844], [360, 740], [1536, 754], [1280, 640],
] as const;
for (const [width, height] of LAYOUT_SIZES) {
test(`ADV配置を機械検査する（${width}×${height}）`, async ({ page }) => {
await page.setViewportSize({ width, height });
// 注文を読む → 在庫を選ぶ → 電話の返事を読む → 電話のあと → 判断 → 聞き取って書く → 連絡 → 記録 → 一日の終わり
// の各場面で expectAdvLayout(page, `${width}×${height} ${scene}`) を呼ぶ
});
}
サイズの選び方は、次のとおりです。
- ノートPCで多い 1366×768 と、手元のノートPC（表示倍率を上げた状態）で実際に測ったビューポート 1536×754
- ブラウザのタブやブックマークバーで高さが削られた 1280×640
- スマホ幅 390×844、360×740（ビューポートの大きさだけで、タッチ操作までは再現していません）
- レイアウトが切り替わる境目（1000px）の前後 960、1100
横幅より、高さの短いサイズで壊れました。 1920×1080だけで確認していると、ほぼ見落とします。
場面ごとにスクリーンショットも保存します。機械検査が通ったあと、見た目の違和感だけを目で見ます。
検査があって見つかった罠
固定表示のタイトルカードが、半分だけ画面の左に出ていた
「DAY 1/3」のタイトルカードは、position: fixed; inset: 0 で全画面を覆うはずでした。ところが、以前の別のルールが残っていました。width: 520px と transform: translateX(-50%) です。後から足したルールがこの2つを打ち消していなかったので、カードは x=-260、幅520px で表示されていました。
スクリーンショットの確認はいつも［始める］を押したあとの場面だったので、見落としていました。今は、押す前の状態を、幅と位置の数値で固定しています。
const box = await page.locator(".day-title-card").boundingBox();
expect(Math.round(box!.x)).toBe(0);
expect(Math.round(box!.width)).toBe(width);
expect(Math.round(box!.height)).toBe(height);
全画面の要素は「表示されているか」ではなく、幅と高さが画面と一致するかで見ます。
CSSの content の文字が、ボタンの名前に混ざる
選択肢に「1」「2」…のキー表示を付けるのに、最初は ::before { content: "1" } を使いました。すると、在庫の数字ボタン「5」のアクセシブルネームにキー表示の文字が混ざり、getByRole("button", { name: "5", exact: true }) で見つからなくなりました。疑似要素の content の文字は、アクセシブルネームの計算に含まれます。
飾りは、aria-hidden="true" の要素にするか、文字を使わずに図形（border で作る三角など）で描きます。
<button><span class="keycap" aria-hidden="true">1</span>5</button>
ホバーでボタン自体を動かすと、クリック時にページがスクロールした
選択肢をホバー時に transform: translateX(4px) で右へずらす演出を付けたところ、Playwrightで選択肢をクリックしたあと、ページがスクロールした状態が検査3で見つかりました。仕組みまでは追い切っていませんが、ボタン自体を動かすのをやめ、ボタンの中の飾りだけを動かすようにしたら解消しました。
それ以来、押す対象の位置は動かさないことを設計のルールにしています。人のクリックにとっても、そのほうが安全です。
まとめ
| 検査 | 見るもの | 捕まえたもの |
|---|---|---|
| elementFromPoint | ボタン中心でイベントを受ける要素 | 別の窓の下に潜った選択肢 |
| 子孫の overflow |
hidden/clip で scroll > client
|
窓の中で切れた3つ目の選択肢 |
| 強制スクロール | 端までスクロールして動くか | 数px下にはみ出した要素 |
| 画面外 | 台詞の上下が画面内か | 絶対配置で画面外に出た吹き出し |
| 全画面の数値 | 幅・高さ・位置が画面と一致 | 半分だけ出ていたタイトルカード |
重なりの多い画面は、「見えている」ことと「使える」ことが一致しません。見た目の確認は人がやり、壊れ方の確認は機械に任せる。この分担にしてから、画面サイズを変えても安心して手を入れられるようになりました。
ゲーム本体は、ブラウザですぐ遊べます。
👉 引き継ぎラボ
業務アプリの画面でも、同じように崩れを機械で止める作りからご相談を承っています。
- ご依頼（クラウドワークス）：https://crowdworks.jp/public/employees/6942778