ローカライズ済みスクリーンショット・ガバナンス 2025 — 多言語LPを崩さない画像差し替えワークフロー

プロダクト紹介ページやヘルプセンターでは、UI のスクリーンショットを各言語で差し替えるケースが急増しています。ところが、テキストの長さや文化的要素によってスクリーンショットがズレ、レイアウト崩れや用語ズレが生じがちです。2025 年のローカリゼーションでは、スクリーンショット管理を「翻訳後の最後の作業」ではなく、制作初期から組み込む必要があります。

この記事では、撮影計画・翻訳レビュー・アクセシビリティ確認・差し替え公開までを 1 本のガバナンスループとして設計する方法を紹介します。

TL;DR

• スクリーンショットをコンポーネント単位で管理し、撮影担当とレビュー担当を明確化する。
• 各言語でテキスト長が変わる箇所は UI 文字列 ID と連携させ、差分通知を自動化する。
• 撮影→翻訳→アクセシビリティ→公開を 48 時間で回す SLA を設定し、Performance Guardian に KPI を記録。
• ALT テキストとキャプションは翻訳メモリと同期し、ALT Safety Linter で機械翻訳による事故を防ぐ。
• 仮差し替え時は Placeholder Generator のローカライズモードで、未翻訳箇所を視覚的に示す。

1. 撮影計画のフレームを定義

スクリーンショット・インベントリ表

撮影対象には UI 文言 ID を紐づけ、翻訳ファイルの変更がコミットされた際に CI がスクリーンショット更新を促すように設定します。

2. 撮影〜翻訳〜公開の 4 段階チェック

1. 撮影: Figma や Storybook のローカライズビルドを Playwright で自動キャプチャ。--lang=es-ES のようにヘッドレスブラウザへロケールを指定。
2. 翻訳レビュー: 翻訳者はスクリーンショットと文字列 ID を並べた Table View で用語監査。翻訳メモリとの不一致は自動ハイライト。
3. アクセシビリティ: ALT Safety Linter で ALT テキストの長さと NG ワードをチェック。色覚多様性の観点では # ベースのトーンが問題ないかを確認。
4. 公開: CMS のエントリにスクリーンショットのバージョンと翻訳レビューログを添付。公開後 24 時間は Performance Guardian で LCP/CLS をモニタリングし、差し替えがページ速度に影響を与えていないかチェック。

3. パイプライン実装例

import { chromium } from 'playwright';
import locales from './locales.json' assert { type: 'json' };

for (const locale of locales) {
  const browser = await chromium.launch();
  const page = await browser.newPage({ locale });
  await page.goto(`https://preview.site/${locale}/feature`);
  await page.setViewportSize({ width: 1440, height: 900 });
  await page.waitForLoadState('networkidle');
  const path = `./shots/${locale}/analytics-dashboard.png`;
  await page.screenshot({ path, fullPage: true });
  await browser.close();
  console.log(`captured ${path}`);
}

生成したスクリーンショットは LQIP も同時に生成しておくと、公開前のテスト環境でもレイアウト変化が即座に確認できます。shots/<locale>/metadata.json には翻訳レビューワークフローのステータスやレビュワー名を記録し、証跡として保持します。

4. QA チェックリスト

• [ ] 各ロケールのスクリーンショットが最新リリースのブランチから生成されている。
• [ ] 翻訳レビューログ（承認者・日時・指摘内容）がチケットに紐づいている。
• [ ] ALT テキストが翻訳メモリと一致し、敏感表現が含まれていない。
• [ ] LCP/CLS 指標が差し替え後も SLA を満たしている。
• [ ] 旧バージョンのスクリーンショットが 30 日以内にアーカイブへ移動されている。

5. ローカライズ運用チームでの導入例

• 背景: 12 言語で製品更新を展開する B2B SaaS。スクリーンショット差し替え遅延が平均 9 日、整合性エラーが月 15 件発生していた。
• 対応: 撮影スクリプトを Playwright で自動化し、翻訳 ID と紐づけたダッシュボードを構築。未更新のスクリーンショットは Slack Bot が通知。
• 結果: 差し替え遅延が 9 日 → 2 日へ短縮。翻訳不一致は 1 件/月以下に減少し、マーケティングチームの差し戻し工数が 60% 削減。
• 教訓: 撮影を開発サイクルに組み込んだことで、翻訳とデザインのコミュニケーションが統制され、ブランド整合性が担保された。

まとめ

ローカライズされたスクリーンショットの品質を支えるのは、キャプチャ自体ではなく、その前後にあるコミュニケーションと証跡です。撮影計画・差分検出・アクセシビリティ検証を自動化すれば、グローバル施策でありがちな「画像だけ旧バージョン」という事故を未然に防げます。制作チームと翻訳チームの連携を強化し、ユーザー体験をロケールごとに最適化していきましょう。