Microsoft Purview 感度ラベルの多言語化手順：Set-Label -LocaleSettings とポリシー ヒント対策

Microsoft Purview の感度ラベルを海外拠点へ展開すると、「ラベル名や説明が英語のまま」「警告メッセージ（ポリシー ヒント）も翻訳されない」といった壁にぶつかります。本記事では、PowerShell を使ったラベル表示の多言語化と、ポリシー ヒントを各国言語で出すための設計・運用方法を整理します。

結論：多言語化できる範囲と、設計で吸収する範囲

Microsoft Purview の感度ラベルを多言語展開する場合、まず押さえるべきなのは「ラベルそのものの表示（ラベル名・説明）」と「クライアントに出る案内文（ポリシー ヒント等）」が別物だという点です。前者は PowerShell で言語別の表示名・説明を登録できますが、後者は同一ポリシー内で言語ごとの文言を持てないため、設計で吸収します。

対象	自動翻訳	多言語化の可否	現実的な対応策	運用メモ
感度ラベルの表示名（ラベル名）	なし	可能	PowerShell の LocaleSettings に言語ごとの表示名を登録	同一ラベルの「見え方」だけを変える。暗号化などの動作は共通。
感度ラベルの説明（ツールチップ）	なし	可能	LocaleSettings に言語ごとの Tooltip を登録	短く具体的に。ユーザー判断に直結するため翻訳品質が重要。
ポリシー ヒントのカスタム文言（警告、理由入力の案内など）	なし	単一ポリシー内では不可	言語（国）ごとにラベル ポリシーを分割し、対象ユーザーをグループで分岐	「ラベルは共通、配布ポリシーとメッセージだけ分岐」にすると破綻しにくい。
ヘッダー／フッター／透かし等のコンテンツ マーキング文字列	なし	ケース次第	全言語で共通表現にする、または国別にラベルを分ける（要設計）	ローカル表現にこだわるほどラベルが増えがち。必要性を見極める。

前提知識：ラベルは「実体」と「表示」が分離している

感度ラベルには、暗号化、アクセス権、透かし、外部共有の制御などの実体としての設定があります。一方で、ユーザーが UI 上で目にするのは表示名（DisplayName）と説明（Tooltip）です。多言語化で変えられるのは基本的にこの「表示」の部分で、ラベルの技術的な動作（暗号化されるか、透かしが入るか等）は変わりません。

この分離を理解しておくと、設計がシンプルになります。つまり、全世界で同じラベルを使いつつ、各国のユーザーには母国語のラベル名・説明を見せられる、ということです。

感度ラベル（ラベル名・説明）を多言語化する

自動翻訳はないため、管理側で言語ごとの文字列を登録する

Microsoft Purview の感度ラベルは、ユーザーの言語設定に合わせてラベル名や説明が自動翻訳されません。英語でラベルを作ってそのまま海外へ展開すると、英語圏以外のユーザーも英語のラベル名・説明を目にすることになります。

多言語対応を実現するには、管理者が PowerShell で各言語分の表示名と説明を登録します。よく使うのが Set-Label の -LocaleSettings です。

準備：管理用 PowerShell でラベルを操作できる状態にする

感度ラベルの設定は管理者権限が必要です。実行前に、影響範囲が小さいテスト用ラベルで試し、変更履歴とロールバック手順を用意しておくことをおすすめします。

# 例：必要なモジュールの準備（環境により差異があります）
# Install-Module ExchangeOnlineManagement -Scope CurrentUser

# 例：接続（管理者アカウントで実施）
# Connect-ExchangeOnline
# Connect-IPPSSession

上記は接続のイメージです。テナントの運用ルールに従い、必要な管理ロール（コンプライアンス管理、情報保護など）を付与したアカウントで実行してください。

ロケール（言語コード）の決め方

-LocaleSettings は、キーにロケール（例：日本語は ja-JP）を指定して、言語ごとの表示名・説明文を設定します。多言語展開でよく使うロケール例をまとめます。

言語	ロケール例	備考
日本語	ja-JP	日本国内向け。社内の表記ルール（です・ます／である）を統一する。
英語（米国）	en-US	既定（デフォルト）を英語にする場合の基準として扱いやすい。
英語（英国）	en-GB	綴りや表現が違うため、必要なら分けて登録する。
フランス語（フランス）	fr-FR	カナダ向けが必要なら fr-CA も検討。
ドイツ語	de-DE	一般に de-DE を基準にすることが多い。
中国語（簡体）	zh-CN	簡体字・繁体字でロケールを分けるのが実務では重要。
中国語（繁体）	zh-TW	台湾向け。香港向けは zh-HK を検討。
韓国語	ko-KR	韓国拠点向け。
スペイン語（スペイン）	es-ES	中南米向けには es-MX 等を検討。
ポルトガル語（ブラジル）	pt-BR	ポルトガル向けは pt-PT と分ける。

設定例：Set-Label -LocaleSettings で言語ごとの表示名と説明を登録

例えば、-LocaleSettings に各言語の DisplayName と Tooltip を登録すると、ユーザーの表示言語に応じてラベル名・説明が切り替わるようになります。

Set-Label -Identity "Confidential" `
  -LocaleSettings @{
    "ja-JP" = @{ DisplayName = "機密"; Tooltip = "社外共有や転送を行う前に、取り扱いルールを確認してください。"; };
    "fr-FR" = @{ DisplayName = "Confidentiel"; Tooltip = "Ne partagez pas ce contenu en dehors de l’entreprise."; };
    "de-DE" = @{ DisplayName = "Vertraulich"; Tooltip = "Nicht außerhalb des Unternehmens weitergeben."; }
  }

ポイントは次の通りです。

• ロケールごとに DisplayName（表示名）と Tooltip（説明）を定義します。
• 対象言語が増えても、同じラベルに対してキー（ロケール）を追加していく設計です。
• ユーザー側の言語設定と一致するロケールが登録されていない場合、既定の表示（通常はラベル作成時の表示）が使われます。

重要：LocaleSettings の上書きに注意（既存翻訳を消さない）

-LocaleSettings は「追加」ではなく「設定値の更新」として扱われるため、運用によっては既存のロケール設定を上書きしてしまうことがあります。すでに他言語が入っているラベルに対して一部言語だけ追加したい場合は、現在の LocaleSettings を取得してからマージする流れが安全です。

# 例：既存 LocaleSettings を取り出し、ja-JP だけ追加してから再設定するイメージ
$label = Get-Label -Identity "Confidential"

# 既存があれば引き継ぐ（環境により型が異なる場合があるため、必要に応じて変換してください）
$ls = @{}
if ($label.LocaleSettings) { $ls = $label.LocaleSettings }

$ls["ja-JP"] = @{ DisplayName = "機密"; Tooltip = "社外共有や転送を行う前に、取り扱いルールを確認してください。"; }

Set-Label -Identity "Confidential" -LocaleSettings $ls

「言語追加のつもりが、別言語の翻訳を消してしまった」という事故は意外と起きます。実行前の棚卸しと、適用後の差分確認までをセットにしてください。

既存のロケール設定を確認・棚卸しする

すでに一部言語を登録済みのラベルがある場合、重複登録や意図しない上書きを避けるため、まず現状を取得して棚卸しします。ローカライズは「追加して終わり」ではなく、定期的に見直す運用が重要です。

# ラベルの一覧を確認（例）
Get-Label | Sort-Object DisplayName | Format-Table DisplayName, Name

# 特定ラベルのロケール設定を確認（例）
(Get-Label -Identity "Confidential").LocaleSettings

また、運用開始前に「どのラベルに、どの言語を、どんな文言で入れたか」を管理台帳（Excel/CSV/リポジトリなど）で必ず残してください。あとから見返せない状態が、翻訳品質の劣化と運用事故を招きます。

複数ラベル・複数言語を一括反映する（CSVで運用する実務例）

ラベル数×言語数が増えると、手作業での Set-Label は現実的ではありません。おすすめは、翻訳テキストを CSV に集約し、PowerShell で一括適用する方式です。更新時も差分管理がしやすく、監査にも耐えられます。

CSV列（例）	内容	例
Identity	ラベル識別子（スクリプトでは Name 等、ブレないキーを推奨）	Confidential
Locale	ロケール	ja-JP
DisplayName	その言語での表示名	機密
Tooltip	その言語での説明	社外共有前に確認…

# 例：CSVから読み込み、ラベルごとに LocaleSettings を組み立てて反映するイメージ
# ※この例は「CSVにそのラベルの全言語が揃っている」前提です。
$rows = Import-Csv ".\\LabelLocaleSettings.csv"

$rows | Group-Object Identity | ForEach-Object {
  $identity = $_.Name
  $localeHash = @{}

  $_.Group | ForEach-Object {
    $localeHash[$_.Locale] = @{
      DisplayName = $_.DisplayName
      Tooltip     = $_.Tooltip
    }
  }

  Set-Label -Identity $identity -LocaleSettings $localeHash
}

既存翻訳を残したい場合は、先に Get-Label で現行の LocaleSettings を取り出し、CSV で指定した分だけ上書きする「マージ方式」にします。テナント規模が大きいほど、マージ方式の方が安全です。

テストの観点：どこで表示が切り替わるか

ロケール設定を追加したら、テストユーザー（各言語の表示環境）で必ず確認します。特に、デスクトップ アプリと Web、Outlook と Office（Word/Excel/PowerPoint）で表示差が出ないかを見ます。

• ラベルの一覧に、翻訳した表示名が出るか
• ラベルにマウスオーバーしたときの説明（ツールチップ）が翻訳されるか
• 推奨ラベルや自動ラベル適用の提示がある場合、ユーザーが文面を理解できるか
• 多言語ユーザー（英語UI＋日本語ユーザーなど）で意図しない言語が出ないか

ポリシー ヒント（クライアント側メッセージ）を多言語対応する

なぜ翻訳されないのか：カスタム文言に言語別の入れ物がない

ポリシー ヒントは、Office クライアント側で「このラベルはこういう理由で推奨されます」「この操作には理由入力が必要です」といったメッセージをユーザーに提示するための仕組みです。ここで指定するカスタム文言は、ラベル名のようにロケール別に複数登録する入れ物がなく、テナント側で設定した1つの文言がそのまま表示されます。

つまり、英語でポリシー ヒントを作っている場合、海外展開すると英語の警告が各国に表示され続けます。これを解消するには、メッセージを言語ごとに持てる設計へ組み替える必要があります。

推奨アーキテクチャ：ラベルは共通、ラベル ポリシーを言語ごとに分割

最も実務的で破綻しにくいのは、ラベル自体はグローバルで共通にしつつ、配布（公開）するラベル ポリシーだけを国・言語別に分ける方法です。これにより、ユーザーに見せるポリシー ヒント文言だけをローカル言語にできます。

要素	グローバル共通にする	国・言語ごとに分ける	理由
感度ラベル（実体の設定）	◯	△（必要時のみ）	暗号化や制御は統一した方がガバナンスが強く、運用も軽い。
ラベル名・説明（表示）	◯	◯	LocaleSettings で多言語を同居できるため、ラベル分割が不要。
ラベル ポリシー（配布）	△	◯	ポリシー ヒント等のメッセージを言語別にしたい。
ポリシー ヒントの文言	×	◯	言語別登録ができないため、ポリシーを分けて持つ。

構成例：国・言語別ポリシー＋ユーザー属性でスコープ

国別・言語別にポリシーを分ける場合、ユーザーの振り分け（スコープ設計）が要です。一般的には Entra ID（Azure AD）グループで分岐し、それぞれのグループに対して該当するラベル ポリシーを割り当てます。

対象	Entra ID グループ例	ラベル ポリシー名例	ポリシー ヒント例
日本（日本語）	Group-Japan-Users	LabelPolicy-JP	このメールには機密情報が含まれています。社外には転送しないでください。
フランス（フランス語）	Group-France-Users	LabelPolicy-FR	Ce message contient des informations sensibles. Ne le transférez pas à l’extérieur.
ドイツ（ドイツ語）	Group-Germany-Users	LabelPolicy-DE	Diese Nachricht enthält vertrauliche Informationen. Nicht extern weiterleiten.
共通（英語）	Group-Global-English	LabelPolicy-EN	This message contains sensitive information. Do not forward externally.

運用上のコツは、グループの定義をブレさせないことです。国で分けるのか、ユーザーの優先言語で分けるのか、部署で分けるのかを決め、後から「例外だらけ」にならない軸を選びます。

ユーザーの振り分けパターン

• 国（拠点）で分ける：出張や多国籍チームが少ない組織で管理しやすい。国ごとに方針が違う場合にも向く。
• ユーザーの優先言語で分ける：多国籍チームが多い場合に合理的。本人が英語UIを好む場合も吸収できる。
• 両方を組み合わせる：国別をベースにしつつ、例外ユーザーだけ言語別グループへ入れる。例外管理が増える点に注意。

Entra ID のグループは手動運用でも良いですが、ユーザー属性（国/地域、部署、優先言語など）が整備されているなら動的グループで自動化できるケースもあります。いずれの場合も、人事データの品質がそのままポリシー配布の品質になります。

重複配布を避ける：グループは原則として排他的に設計する

同一ユーザーが複数のラベル ポリシー対象になると、意図せずラベルの表示やメッセージが揺れたり、問い合わせの原因になったりします。多言語目的でポリシーを分ける場合は、「JP か FR か EN か」のように、原則としてユーザーが1つに確実に属する設計（排他的なグループ設計）にしておくのが安全です。

ポリシーが増えたときに破綻しない命名と管理

言語ごとにポリシーを分けると、ポリシー数が増えます。増えたときに破綻しないために、次のルールを最初に決めておくと運用が安定します。

• ラベル ポリシー名に 国コード/言語コード を入れる（例：LabelPolicy-JP, LabelPolicy-FR）
• ポリシー ヒント文言は、翻訳台帳で 原文→各言語 を紐づけて管理する
• 例外（海外転籍、言語の変更）は、グループ運用の手順に落とし込む
• 変更時は、必ずテストユーザーで Office クライアントの表示を確認する

方言・地域差をどう扱うか

「同じ言語でも国や地域で言い回しが違う」問題は、ローカル言語対応の現場で必ず出ます。Microsoft 365 側で判定できる単位は基本的にロケールなので、まずはロケールが分かれている言語は分けて登録するのが近道です。

• フランス語：fr-FR（フランス）と fr-CA（カナダ）
• 英語：en-US（米国）と en-GB（英国）
• スペイン語：es-ES（スペイン）と es-MX（メキシコ）など
• ポルトガル語：pt-PT（ポルトガル）と pt-BR（ブラジル）
• 中国語：zh-CN（簡体）と zh-TW/zh-HK（繁体）

一方で、ロケールが分かれていない「社内方言」「拠点独自の言い回し」まで自動で出し分けたい場合は、現実的には次のどちらかになります。

• ラベル名・説明は標準語に寄せる（最も安全で、運用負荷が小さい）
• どうしても必要な場合のみ、拠点別にラベルを分ける（ラベル増加と誤選択リスクが上がるため慎重に）

方言や言い回しの差は、ラベル名よりもポリシー ヒントで吸収する方が運用上は現実的です。ポリシー ヒントはラベル ポリシー分割で拠点別に作り分けられるため、「同じラベルを使いながら、案内文だけ地域に最適化する」構成が取りやすくなります。

翻訳品質で事故を防ぐ：文言作成の実務ガイド

感度ラベルの多言語化は「翻訳できたら終わり」ではありません。ラベル名とポリシー ヒントは、ユーザーの行動（共有するか、暗号化するか、理由を入力するか）を直接左右します。誤訳や曖昧表現は、そのまま情報漏えいリスクになります。

ラベル名のルール（短い・区別できる・誤解しない）

• ラベル名は短くし、一覧で見たときに区別できる語を使う
• 「社外秘」「機密」「極秘」など、組織の既存の分類に合わせる
• 翻訳語が長くなる言語（ドイツ語など）は、略語や一般的な表現を検討する

ツールチップ（説明）のルール（行動につながる具体性）

ツールチップは「何をしてはいけないか」「迷ったら誰に相談するか」まで書くと効果が高いです。例として、日本語の Tooltip に入れやすい要素を表にします。

入れる要素	例	狙い
禁止行為	社外への転送・外部共有は禁止	判断を迷わせない
許可条件	取引先共有は契約上必要な場合のみ	例外を明確化
相談先	不明点は情報セキュリティ窓口へ	誤操作の抑止

ポリシー ヒントのルール（短い・強い・次の行動がわかる）

ポリシー ヒントは表示される時間が短く、読み飛ばされやすいので、長文よりも「要点＋次の行動」が向きます。特に、理由入力を求める場合は、入力例を1つ入れるだけでユーザーのストレスを大幅に下げられます。

• 悪い例：背景説明が長く、何をすればよいか分からない
• 良い例：社外共有のため理由を入力してください（例：取引先への見積提出）

よくある落とし穴と対策

ロケールを入れたのに英語のまま

• ユーザーの表示言語が想定と違う（例：OSは日本語だが Office UI は英語）
• 登録したロケールがユーザーの言語と一致していない
• クライアント側のキャッシュで反映に時間差がある

対策としては、まずテストユーザーで表示言語の設定を確認し、次に Get-Label で LocaleSettings が入っているかを確認します。言語が揺れる環境があるなら、主要言語（例：ja-JP と en-US）を同時に登録しておくとトラブルが減ります。

国・言語別にポリシーを分けたら管理が煩雑になった

ポリシーが増えるのは避けられません。だからこそ、最初から「増えても回る設計」に寄せます。

• ラベルは極力共通にし、ポリシーだけ分岐する
• 翻訳文言は台帳（CSV）で一元管理する
• 各国の承認フロー（レビュー担当）を決める
• 新拠点追加時は「言語追加＋ポリシー追加」をテンプレ化する

コンテンツ マーキングの文言が英語で残る

ラベル名・説明を多言語化しても、ヘッダー／フッター／透かし等に固定文言を入れている場合、その文言は別途設計が必要です。全世界で共通の短い表現（例：CONFIDENTIAL）に寄せるか、国別ラベルを増やすか、どちらがコストに見合うかを検討してください。ラベルを増やす場合は、ユーザーが選び間違えないように、表示名・説明の設計とセットで進めます。

運用テンプレ：最小コストで始めて拡張する進め方

最後に、実務で失敗しにくい進め方をまとめます。いきなり全言語・全ラベルを完璧にしようとすると、翻訳と運用の負債が膨らみます。まずは「利用者が多い言語」から段階的に広げるのが現実的です。

フェーズ	やること	成果物	チェックポイント
設計	ラベル体系（分類）と、国/言語の分岐軸を決める	ラベル一覧、翻訳台帳のひな形	「ラベルを増やさない」方針が守れているか
実装（表示）	Set-Label -LocaleSettings でラベル名・説明を多言語化	LocaleSettings 設定、テスト結果	主要クライアント（Outlook/Office）で表示確認
実装（メッセージ）	言語ごとにラベル ポリシーを分割し、ポリシー ヒントを翻訳	国別/言語別ポリシー、グループ割当	グループの定義が崩れていないか（例外運用の増加）
運用	翻訳の更新、拠点追加、例外ユーザー対応	変更履歴、承認フロー	翻訳品質レビューと、ユーザー問い合わせの減少

まとめ：多言語展開は「表示のローカライズ」と「配布ポリシーの分岐」を分けて考える

• 感度ラベルのラベル名・説明は自動翻訳されないため、Set-Label -LocaleSettings で言語ごとに手動登録する
• ポリシー ヒントのカスタム文言は、単一ポリシー内での多言語登録ができないため、言語ごとにラベル ポリシーを分割してユーザーをグループで振り分ける
• ロケールが分かれている言語は LocaleSettings で出し分け、方言・地域差はポリシー ヒントで吸収すると現実的
• ラベルはグローバル共通にして、表示とメッセージだけをローカルに最適化すると、拡張しやすく運用が破綻しにくい

この構成にしておけば、国・言語の追加時も「LocaleSettings の追加」と「該当言語のポリシー追加」で段階的に拡張できます。多言語化は設定作業ではなく運用設計です。翻訳台帳と承認フローまで含めて仕組みにすると、長期的に安定した情報保護が実現できます。