Edge 147 Web プラットフォームのリリースで追加されたマニフェストのローカリゼーション サポートは、PWA やインストール可能な Web アプリの name、icons、shortcuts などを、ユーザーの言語や地域に合わせて切り替えやすくする機能です。2026年4月10日には Stable Channel の Edge 147.0.3912.60 が公開され、同月の Web Platform リリースノートでは manifest localization が新機能として案内されています。 (Microsoft Learn)
要点だけ先に言うと、Edge 147 以降は manifest.json の中で既定値と *_localized を整理し、ブラウザー側に最適な言語を選ばせる設計が取りやすくなりました。多言語対応の PWA でありがちな「UI は英語なのにアプリ名は日本語のまま」「ショートカット名だけ未翻訳」「文字入りアイコンが地域に合っていない」といったズレを減らしやすくなります。ただし、実際の表示面やショートカット数はブラウザーや OS の裁量が大きいため、実機確認は欠かせません。 (W3C)
Edge 147 Web プラットフォームのリリースで追加されたマニフェスト ローカリゼーションとは
Microsoft の案内では、Edge 147 で Web app manifest がローカリゼーションをサポートし、Web アプリは name、description、icons、shortcuts をユーザーの言語と地域に合わせて適応できるようになりました。ローカライズ済みの値を manifest に用意しておくと、ブラウザーがユーザーの言語設定に応じて適切な値を自動選択します。 (Microsoft Learn)
実務上、まず押さえておきたい対象は次の3つです。
- アプリ名と短縮名。
nameとshort_nameはどちらも localizable member で、name_localizedとshort_name_localizedを持てます。アプリ名はアプリ一覧やアイコンラベルに使われ、表示スペースに応じてnameとshort_nameのどちらを採るかは実装側に委ねられています。 (W3C) - アイコン。
iconsも localizable member なので、icons_localizedで言語別アイコンを持てます。文字入りアイコンや地域別ブランド表記があるアプリでは特に効果が大きい部分です。 (W3C) - ショートカット。shortcut item の
name、short_name、description、iconsも localizable member です。これらは OS 側のアプリアイコンのコンテキストメニュー相当で使われる想定です。 (W3C)
description については少し整理が必要です。Microsoft は今回の機能説明で description も対象に含めていますが、W3C の supplementary manifest members では description はアプリの目的を説明する補足メタデータで、デジタルストアフロントやインストールダイアログなどの表示面を強化する用途が想定されています。しかもこれらの supplementary members は runtime の挙動そのものを変えるものではありません。つまり、説明文のローカライズは「アプリの見た目全体」というより、「配布面・導入面の説明品質」を上げる意味合いが強いと考えると理解しやすいです。 (Microsoft Learn)
まず理解したい _localized の考え方
現在の Web App Manifest 仕様では、localizable member ごとに対応する *_localized メンバーを持てます。元の name や icons が既定値で、name_localized や icons_localized は言語タグをキーにした language map です。ブラウザーはユーザーのローカライズ設定に最も近い値を選び、該当がなければ既定値を使います。 (W3C)
テキスト系の localized value は、単純な文字列でも、value・lang・dir を持つオブジェクトでも書けます。lang は BCP 47 の言語タグで、dir は ltr、rtl、auto を使います。アラビア語やヘブライ語のように文字方向が既定値と異なる可能性がある場合は、dir まで明示したほうが安全です。 (W3C)
ここでありがちな見落としが、name だけローカライズして short_name を放置するパターンです。実際のアプリ名は name または short_name から導かれ、どちらが使われるかは表示スペースや実装次第です。ランチャーやタスク切り替え UI で省略名が使われることを考えると、実運用では両方をセットでローカライズするのが基本です。 (W3C)
manifest.json の実装例
仕様上は、ルートの name_localized と short_name_localized、画像リソース向けの icons_localized、そして shortcut item の name_localized、short_name_localized、description_localized、icons_localized を処理できます。実装イメージは次のとおりです。 (W3C)
{
"id": "/",
"start_url": "/",
"scope": "/",
"display": "standalone",
"lang": "ja",
"dir": "ltr",
"name": "社内ポータル",
"name_localized": {
"en": "Company Portal",
"en-GB": "Company Portal",
"ar": {
"value": "بوابة الشركة",
"dir": "rtl"
}
},
"short_name": "ポータル",
"short_name_localized": {
"en": "Portal",
"ar": {
"value": "البوابة",
"dir": "rtl"
}
},
"icons": [
{
"src": "/icons/app-ja-192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "/icons/app-ja-512.png",
"sizes": "512x512",
"type": "image/png"
}
],
"icons_localized": {
"en": [
{
"src": "/icons/app-en-192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "/icons/app-en-512.png",
"sizes": "512x512",
"type": "image/png"
}
]
},
"shortcuts": [
{
"name": "申請を作成",
"name_localized": {
"en": "Create request"
},
"short_name": "新規申請",
"short_name_localized": {
"en": "New request"
},
"description": "新しい申請フォームを開きます",
"description_localized": {
"en": "Open a new request form"
},
"url": "/requests/new",
"icons": [
{
"src": "/icons/shortcut-ja-96.png",
"sizes": "96x96",
"type": "image/png"
}
],
"icons_localized": {
"en": [
{
"src": "/icons/shortcut-en-96.png",
"sizes": "96x96",
"type": "image/png"
}
]
}
}
]
}この書き方で重要なのは、通常メンバー側が常に既定値の受け皿になることです。たとえば en-US を明示していなくても、ユーザーの言語設定に一致する localized value がなければ、name や icons の既定値に戻ります。多言語対応を始めるなら、まずは既定言語を1つ安定させ、そのうえで優先度の高い言語だけ *_localized を足していくのが現実的です。 (W3C)
もう1つ大事なのが scope です。仕様では shortcut の url は manifest の scope 内でなければ失敗扱いになります。また、予期しないナビゲーションを避けるために scope を明示することが推奨されています。ローカリゼーション対応に気を取られて scope 設計が雑になると、ショートカットだけ効かないというトラブルが起きやすくなります。 (W3C)
アプリ全体の description を使っている場合は、インストールダイアログや配布面で見せる説明文として扱い、name や short_name と同じ翻訳ポリシーで管理すると運用しやすくなります。特に B2B アプリでは、アプリ名だけ日本語化して説明文が英語のままだと、導入時の印象がちぐはぐになりがちです。 (W3C)
この機能が特に効くケース
ランチャー名と実際の言語を揃えたい PWA
name はアプリ一覧やアイコンラベルで使われ、short_name は表示幅が足りないときの短縮表記として使われます。Edge 147 の manifest localization により、この2つをユーザーの言語に合わせて出し分けやすくなるため、インストール後の第一印象がかなり改善します。グローバル展開の SaaS や社内ポータルでは、ここがいちばん効果を実感しやすい部分です。 (W3C)
文字入りアイコンを使う業務アプリ
アイコンに「請求」「申請」「HR」などの文字が入る業務アプリは珍しくありません。このタイプは icons_localized の恩恵が大きく、言語別アイコンをそのまま manifest に持たせられます。逆に、文字のないシンボルアイコンしか使っていないなら、アイコンのローカライズは後回しでも問題になりにくいです。 (W3C)
ショートカットを使う社内ツールや業務フローアプリ
ショートカットは OS のアプリアイコンから直接操作されることを想定した仕組みで、name、description、icons までローカライズできます。たとえば「新規申請」「タイムシート入力」「承認待ち一覧」のような業務導線を、言語別に違和感なく見せられるのが強みです。 (W3C)
RTL 言語を扱うアプリ
dir の既定値は manifest 全体に効き、localized text object ごとに dir を上書きできます。日本語や英語を既定にしつつ、アラビア語だけ rtl を指定するといった設計ができるため、見た目だけでなく読み上げやアクセシビリティ面でも整合性を取りやすくなります。 (W3C)
実務で決めるべき運用ルール
ローカリゼーション対応を始める前に、次のルールを決めておくと後で崩れません。
- 既定言語を必ず決める。
*_localizedに一致がない場合、ブラウザーは通常メンバー側の既定値を使います。既定値が曖昧だと、未翻訳言語の体験が不安定になります。 (W3C) - 言語タグは BCP 47 準拠に統一する。
langは妥当な言語タグである必要があり、構造的に無効なタグは処理されません。まずはja、enのような基本言語で始め、必要な地域だけen-GBのように増やす運用が現実的です。 (W3C) nameとshort_nameはセットで管理する。片方だけ翻訳すると、表示面によって言語が混在するリスクがあります。 (W3C)- アイコンのローカライズは「文字や地域表記が変わるときだけ」に絞る。不要な言語別アイコンを増やすと、アセット管理が一気に重くなります。一方で名前やアイコンは security-sensitive member として扱われるため、変えるなら軽い文言修正ではなく UI 変更として管理するほうが安全です。 (W3C)
scopeは省略しない。ショートカット URL とローカリゼーションの検証を切り分けやすくなります。 (W3C)
失敗しやすいポイント
ja_JPのように BCP 47 ではない書き方を混ぜると、そのエントリーだけ無視される可能性があります。言語タグはハイフン区切りで統一したほうが安全です。 (W3C)name_localizedだけ用意してshort_name_localizedを忘れると、OS の表示幅が狭い場面で未翻訳の短縮名が出ることがあります。 (W3C)- shortcut の
urlを scope 外にすると、その shortcut は処理に失敗します。多言語ルーティングの都合で/en/...と/ja/...を分けているアプリは特に注意が必要です。 (W3C) - インストール済みアプリの名前やアイコンを後から変えると、すぐ反映されるとは限りません。仕様上、
name、short_name、iconsとその localized 表現は security-sensitive member で、更新時に明示的な許可が求められることがあります。ユーザーの言語設定変更に応じた launch surface の調整も、次回起動時に見せる想定です。 (W3C) - アイコン画像の中身だけ差し替えて
srcを変えない運用は、更新検知が読みにくくなります。仕様では、まずsrcの変化が更新判定の基準です。確実に切り替えたいなら、言語別または更新版でsrcまで変えるほうが堅実です。 (W3C) - ショートカット数や見え方を固定で期待しないこと。仕様上、どのように提示するか、いくつ表示するかは user agent や OS の裁量で、必要に応じて切り詰められます。 (W3C)
Edge 147 で確認したいテスト手順
実装したら、少なくとも次の順番で確認すると判断しやすくなります。
- 既定言語でインストールし、アプリ一覧、アイコンラベル、タスク切り替え画面相当で
nameとshort_nameが想定どおりに見えるか確認する。 (W3C) - Edge または OS の優先言語を英語などに切り替え、再度表示名とアイコンが localized 版に変わるか確認する。Edge はユーザーの言語設定に応じて値を選ぶ前提です。 (Microsoft Learn)
- アプリアイコンの右クリックや長押し相当で shortcut の言語、説明、アイコンを確認する。表示数は固定ではないので、数ではなく「重要導線が見えるか」を見るのがポイントです。 (W3C)
- 対応していない言語設定でも既定値に自然にフォールバックするか確認する。未対応言語の体験が実運用ではいちばん露出しやすいことがあります。 (W3C)
- 既存インストールユーザー向けに更新も試す。
nameやiconsを変えたときの反映タイミング、必要ならsrcの変更、permission 表示の有無まで見ておくと本番で慌てません。 (W3C)
まとめ
Edge 147 Web プラットフォームのリリースで追加されたマニフェストのローカリゼーション サポートは、単なる「翻訳が増えた」機能ではありません。アプリ名、短縮名、アイコン、ショートカット、そして場合によっては導入面の説明文まで、manifest ベースで整理しやすくなったことが本質です。ブラウザーがユーザー言語に応じて値を選び、該当がなければ既定値に戻るので、manifest.json を多言語対応の起点として扱いやすくなりました。 (Microsoft Learn)
次にやるべきことは明確です。まず name、short_name、icons、shortcuts のうち、実際にユーザーの目に触れるものから *_localized を追加してください。そのうえで Edge 147 でインストール済みアプリの表示面まで確認すれば、このリリースを単なる仕様ニュースではなく、実際の UX 改善につなげられます。 (W3C)
コメント