Azure AI Foundryで会話ログやコールセンターの文字起こしを扱っている場合、今回のポイントは明確です。2026年6月4日に公開・更新された「[Launched] Public Preview: Conversational PII NextGen Playground in Microsoft Foundry」は、複数話者の会話データを使って、個人情報・機密情報の検出とマスク結果をAPI連携前に確認しやすくするパブリックプレビューです。Microsoftの公式更新では、Conversational PII（ConvPII）NextGen Playgroundに、トランスクリプト入力とAPI Configuration Panelが追加されたことが示されています。(Microsoft Azure)
すぐに既存システムを置き換える話ではありません。まずは、サポートチャット、通話録音の文字起こし、会議トランスクリプト、AIエージェントの会話ログなどを扱うチームが、検出対象のPII、マスク方式、API・モデルバージョン、RBAC、プレビュー利用条件を確認するための変更と捉えるのが現実的です。
なお、Microsoftのドキュメントでは現在の名称として「Microsoft Foundry」が使われていますが、旧称・関連名称として「Azure AI Foundry」も引き続き検索されます。公式ドキュメントでは、Azure AI Studio → Azure AI Foundry → Microsoft Foundryへ名称が変わった一方、Azureリソース種別はMicrosoft.CognitiveServices/accountsのままと説明されています。(Microsoft Learn)
Azure AI FoundryのConversational PII NextGen Playgroundで何が変わるのか
今回の変更は、Azure AI Foundry、現在のMicrosoft Foundry上で、会話形式のPII検出をPlayground上で試しやすくする更新です。
PII検出は、テキスト、会話、ネイティブドキュメントに含まれる機密データを識別・分類・編集するAzure Languageの機能です。入力に対して、エンティティカテゴリ、信頼度スコア、編集済み結果などの構造化された出力を返します。(Microsoft Learn)
その中でもConversation PIIは、単一の文章ではなく、発話者ごとのターン、複数発話、会話全体の文脈を前提にしたPII検出です。公式ドキュメントでは、カスタマーサポート会話、コールトランスクリプト、会議トランスクリプトなどに使える機能として説明されています。(Microsoft Learn)
今回のNextGen Playgroundにより、開発者は次の作業をAPI実装前に画面上で確認しやすくなります。
| 確認できること | 実務上の意味 |
|---|---|
| 複数話者のトランスクリプト入力 | 顧客とオペレーター、ユーザーとAIエージェントなど、実際の会話構造に近い形で検証できる |
| API Configuration Panel | APIバージョン、モデルバージョン、言語、PII種別、マスク文字などを画面上で調整できる |
| 検出結果のハイライト表示 | どの文字列がどのPII種別として検出されたかを目視確認できる |
| JSONレスポンス確認 | アプリ連携時に必要なレスポンス構造、信頼度、オフセット、長さを確認できる |
| VS Codeへの連携 | Playgroundで試した設定を開発環境へ持ち込み、実装に進めやすくなる |
特に重要なのは、「PII検出APIを呼べるか」ではなく、「自社の会話データで期待通り検出・マスクできるか」を事前に検証しやすくなった点です。
Text PIIとConversation PIIは使い分けが必要
PII検出には、Text PII、Conversation PII、Document-based PIIがあります。すべてPII検出という大きな目的は同じですが、入力データの形が異なります。Microsoftの公式ドキュメントでも、Text PIIは文字列ベースのペイロード、Conversation PIIはマルチターン交換とトランスクリプト指向のペイロード向けと整理されています。(Microsoft Learn)
| 項目 | Text PII | Conversation PII |
|---|---|---|
| 主な入力 | 単一のテキスト、ログ、フォーム、プロンプト | 複数発話のチャット、通話文字起こし、会議録 |
| 向いている用途 | 問い合わせ本文、ログ行、自由記述欄のマスク | 顧客対応履歴、コールセンター記録、AIエージェント会話の匿名化 |
| 処理の考え方 | 文字列単位で検出 | 発話ターンや会話構造を考慮 |
| 実装時の注意 | 入力文字列単位の扱いで済むことが多い | 話者ID、ターン、改行、トランスクリプト形式の整備が重要 |
| 検証で見るべき点 | 必要なPII種別が検出されるか | 話者をまたいだ会話でも過不足なく検出されるか |
たとえば、Webフォームの「お問い合わせ内容」に含まれる電話番号やメールアドレスを検出したいだけなら、Text PIIで十分なケースがあります。一方で、次のような会話データではConversation PIIを優先して検証すべきです。
Agent: 本人確認のため、お名前をお願いします。
Customer: 山田太郎です。
Agent: 登録済みの電話番号も確認します。
Customer: 090-xxxx-xxxxです。
Agent: ご契約番号は分かりますか？
Customer: A123456789です。このように、個人名、電話番号、契約番号が複数ターンに分かれて出てくる場合、単なるテキスト処理ではなく、会話構造を前提に検証した方が実装後の手戻りを減らせます。
NextGen Playgroundで追加・強化された主な確認ポイント
トランスクリプト入力で複数話者の会話を検証できる
Conversation PII Playgroundでは、サンプルトランスクリプトを選択する、ファイルをアップロードする、または会話ターンを直接入力する方法で検証できます。Microsoftのドキュメントでは、各ターンを新しい行に分け、可能であれば話者ラベルを含めることが推奨されています。参加者ID、コロン、メッセージ、改行の使い方が一貫していないと、予期しない出力になる可能性があるとも説明されています。(Microsoft Learn)
実務では、次のようなルールを先に決めてからテストすると、検出結果を比較しやすくなります。
| 項目 | 推奨する決め方 |
|---|---|
| 話者名 | Agent、Customer、User、Assistantなど固定名にする |
| 区切り文字 | 話者名: 発話内容に統一する |
| 1ターンの単位 | 発話者が変わるごとに改行する |
| 実データ利用 | まずは合成データや匿名化済みデータで検証する |
| 音声起こしデータ | Speech to text由来の表記揺れ、句読点欠落、数字表記の違いも試す |
Playgroundには入力構造を整えるための「Format for me」も用意されていますが、最終的には本番パイプライン側で安定したフォーマットを作れるかが重要です。画面上で整形できても、API連携時の入力が崩れていれば期待通りの検出結果にならない可能性があります。
API Configuration PanelでAPI・モデル・言語・PII種別を調整できる
PlaygroundのConfigureペインでは、APIバージョン、モデルバージョン、入力言語、検出対象のPII種別、マスク文字などを設定できます。検出後は、エンティティの種類、信頼度、オフセット、長さを確認できます。(Microsoft Learn)
管理者や開発者が特に確認すべきなのは、次の4点です。
| 設定 | 確認すべき理由 |
|---|---|
| APIバージョン | プレビュー版と既存版でレスポンスや対応機能が異なる可能性がある |
| モデルバージョン | デフォルトの「最新」を使うと、将来の変更で検出結果が変わる可能性がある |
| 言語 | 日本語・英語・多言語混在の会話で期待通り検出されるか確認が必要 |
| PII種別 | Person、Phone、Email、CreditCard、NumericIdentifierなど、業務上マスクすべき範囲を明確にする |
「検出できるものを全部マスクする」だけでは、実務ではうまくいかないことがあります。たとえば、問い合わせ分析では地名や組織名を残したい一方、氏名、電話番号、メールアドレス、契約番号は確実に伏せたい場合があります。逆に、監査や不正調査では一部の識別子を保持し、閲覧権限で制御する方が適切な場合もあります。
JSONレスポンスを見てAPI連携前の実装イメージを固められる
Playgroundの価値は、単に画面でハイライトを見ることではありません。JSONレスポンスを確認し、アプリケーション側でどのフィールドを使うかを事前に決められる点にあります。
たとえば、実装時には次の判断が必要です。
| 実装判断 | 例 |
|---|---|
| 信頼度スコアをどう扱うか | 低信頼度の検出結果は人手確認に回す |
| オフセットと長さを使うか | 元テキスト上の位置を保持し、UIでハイライト表示する |
| マスク済みテキストを保存するか | 生データは保存せず、redacted outputだけを分析基盤に送る |
| エンティティ種別をログ化するか | 実際のPII値ではなく、検出種別と件数のみを監査ログに残す |
Microsoftのドキュメントでは、Conversation PIIの結果として、カテゴリ・サブカテゴリ・信頼度スコアを含む認識エンティティと、PIIを編集したテキスト文字列が返されると説明されています。(Microsoft Learn)
Open in VS Codeで検証結果を実装に持ち込みやすい
Playgroundで検証した後、Open in VS Codeを使うと、APIバージョン、モデル、編集設定などを反映したコードサンプルを開発環境に持ち込めます。Microsoftのドキュメントでは、Playground上でAPIバージョンやモデルバージョン、入力、エンティティ種別、マスク文字、言語を調整したうえで、VS Codeに構成を反映できると説明されています。(Microsoft Learn)
ただし、これをそのまま本番コードにするのは避けるべきです。実装時には、少なくとも次の置き換え・追加が必要です。
| 必要な作業 | 内容 |
|---|---|
| 認証情報の安全な管理 | キーをコードに直書きせず、Key Vaultや環境変数などで管理する |
| 入力データの置き換え | サンプルではなく、本番に近い合成データ・検証用データでテストする |
| 例外処理 | APIエラー、タイムアウト、非同期ジョブ失敗、再試行を実装する |
| ログ設計 | PII本文をログに残さず、処理ID、件数、カテゴリなどに限定する |
| バージョン固定 | 本番前にAPI・モデルバージョンを明示して再現性を確保する |
影響を受ける対象者
今回の更新で直接影響を受けるのは、Azure AI Foundryを使う開発者だけではありません。会話データを扱う組織では、管理者、セキュリティ担当、データ基盤担当、業務部門も確認が必要です。
| 対象者 | 影響 | 最初に確認すべきこと |
|---|---|---|
| Azure AI Foundry管理者 | Playground利用、RBAC、プロジェクト権限の確認が必要 | 誰がConvPII Playgroundを利用できるか |
| アプリ開発者 | API統合前の検証フローが変わる | APIバージョン、モデルバージョン、レスポンス形式 |
| セキュリティ・プライバシー担当 | PII検出範囲とマスク方式の確認が必要 | どのPII種別を検出・編集対象にするか |
| コールセンター・サポート部門 | 通話・チャットログの匿名化設計に影響 | 実際の会話ログで検出漏れ・過検出がないか |
| データエンジニア | 分析基盤へ渡す前の前処理に影響 | 生データ、マスク済みデータ、メタデータの保存方針 |
| コンプライアンス担当 | プレビュー利用と法規制対応の判断が必要 | 本番利用可否、人手確認、監査証跡 |
特に、会話ログをRAG、品質評価、オペレーター教育、AIエージェント改善、VOC分析に使っている企業では、PIIを含む生データが後続処理へ流れやすくなります。ConvPII Playgroundは、その前段で「どこまで自動マスクできるか」を検証する入口になります。
管理者が確認すべき設定と運用上の注意点
RBACと権限名の変更を確認する
Foundry関連のRBACロールは名称変更が進んでいます。Microsoftのドキュメントでは、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前のAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerに相当し、ロールIDと中核的な権限は変更されていないと説明されています。(Microsoft Learn)
管理者は、次の観点で棚卸ししてください。
| 確認項目 | 判断基準 |
|---|---|
| Playgroundを使えるユーザー | 開発者・検証担当に限定し、不要な利用者を増やさない |
| プロジェクトの管理権限 | 検証だけのユーザーに過剰なOwner権限を付けない |
| マネージドID | API連携時に使うIDへ必要最小限の権限を付与する |
| 旧名称のロール | ポータルやドキュメントで旧名称が残っていても同一系統のロールか確認する |
PII検証は機密データに近い作業です。単なるAI機能の試用ではなく、データ保護の入口として権限管理を設計する必要があります。
プレビュー機能として扱い、本番展開は慎重に判断する
今回の更新は「Public Preview」です。公式ドキュメントでも、Conversation PIIのプレビューAPIやプレビューモデルは、Microsoft Product Terms、DPA、Azure Previewsの補足条項の対象として説明されています。(Microsoft Learn)
そのため、社内ルールとしては次のように扱うのが安全です。
| 利用段階 | 推奨対応 |
|---|---|
| 初期検証 | 合成データ、匿名化済みデータ、代表サンプルで検証する |
| PoC | 実データを使う場合は承認プロセスを通す |
| 本番前 | 法務、セキュリティ、データ保護担当のレビューを受ける |
| 本番利用 | プレビュー条項、SLA、サポート、変更リスクを確認して判断する |
「Playgroundで検出できたから本番投入できる」と判断するのは危険です。PII検出は補助機能であり、業務上のリスク許容度、法規制、監査要件とセットで評価する必要があります。
言語対応とモデルバージョンを確認する
Conversation PIIは、モデルやAPIバージョンによって対応言語や挙動が異なる場合があります。Microsoftのドキュメントでは、Conversational PIIのGAモデルは英語のみをサポートし、プレビューモデルとAPIは他のLanguage機能と同じ言語リストをサポートすると説明されています。(Microsoft Learn)
日本語圏の利用では、次のテストを必ず入れてください。
| テスト対象 | 例 |
|---|---|
| 日本語氏名 | 山田太郎、田中花子、カタカナ氏名、ローマ字氏名 |
| 電話番号 | 090-1234-5678、090 1234 5678、全角数字 |
| 住所 | 都道府県、市区町村、建物名、部屋番号 |
| メールアドレス | 通常形式、会話中にスペースが入った形式 |
| 契約番号・会員番号 | 数字のみ、英数字混在、接頭辞付き |
| 多言語混在 | 日本語の会話内に英語名、海外住所、国際電話番号が出るケース |
特に音声認識後のトランスクリプトでは、「090」が「ゼロキューゼロ」と文字起こしされたり、数字が漢数字や全角数字になったりします。Playgroundでは、きれいなサンプルだけでなく、実際の文字起こしに近い崩れた入力も試すべきです。
非同期処理と結果取得の扱いを確認する
Conversation PII APIは非同期処理を前提にしたワークフローです。公式ドキュメントでは、会話アイテムをジョブとして送信し、ジョブステータスをポーリングし、エンティティと編集済み会話出力を取得する流れが説明されています。(Microsoft Learn)
また、非同期機能のAPI結果はリクエスト取り込み後24時間利用可能で、その後は削除されると説明されています。1リクエストで送信できる会話は1つです。(Microsoft Learn)
実装時は、次のような設計が必要です。
| 設計項目 | 注意点 |
|---|---|
| ジョブ管理 | ジョブIDと元データIDを安全に対応付ける |
| ポーリング | タイムアウト、失敗、再試行、重複実行を考慮する |
| 結果保存 | 24時間以内に必要な結果を取得し、保存方針を決める |
| 生データ削除 | マスク後に生データを残す必要があるかを検討する |
| 監査ログ | PII値そのものではなく、処理日時、件数、カテゴリを中心に記録する |
開発者向け：ConvPII Playgroundで検証する手順
まず合成トランスクリプトを用意する
最初から実際の顧客データを貼り付けるのは避けましょう。まずは、業務で出やすいPIIを含む合成データを作ります。
Agent: 本人確認のため、お名前をお願いします。
Customer: 山田太郎です。
Agent: ありがとうございます。登録済みのメールアドレスを確認します。
Customer: [email protected]です。
Agent: お電話番号もお願いします。
Customer: 090-1234-5678です。
Agent: ご契約番号は分かりますか？
Customer: C-987654321です。検証データには、正常な表記だけでなく、表記揺れも含めます。
Customer: 電話番号は ０９０ １２３４ ５６７８ です。
Customer: メールは taro dot yamada at example dot com です。
Customer: 会員番号はAの123の456です。この段階で見るべきなのは、「きれいな入力で検出できるか」ではなく、実際の会話で起きる崩れにどれだけ耐えられるかです。
Configureで検出条件を変えながら比較する
次に、API Configuration Panelで条件を変えて検証します。
| 比較軸 | 見るべき結果 |
|---|---|
| APIバージョン | レスポンス形式や検出結果の差 |
| モデルバージョン | 旧モデル・新モデルでの検出漏れ、過検出 |
| 言語 | 日本語、英語、多言語混在での精度差 |
| 検出対象PII | 必須カテゴリだけに絞った場合の結果 |
| マスク文字 | *、固定ラベル、マスクなしの扱いやすさ |
検出対象には、Person、Phone、Email、CreditCard、NumericIdentifierなどがあります。Microsoftのドキュメントでは、Conversation PIIが住所、年齢、生年月日、電話番号、メール、クレジットカード、銀行口座番号、政府発行ID、NumericIdentifierなど多様なエンティティを扱うことが示されています。(Microsoft Learn)
redactionPolicyを業務目的に合わせて選ぶ
Conversation PIIでは、redactionPolicyとしてnoMask、characterMask、entityMaskを扱えます。Microsoftのドキュメントでは、characterMaskは元のテキストの長さとオフセットを保持しながらマスクでき、entityMaskは検出されたPIIをエンティティ種別で置き換えると説明されています。(Microsoft Learn)
| 方針 | 向いているケース | 注意点 |
|---|---|---|
| characterMask | オフセットや文字位置を後続処理で使う | 読みやすさは下がる |
| entityMask | 分析用テキストとして読みやすくしたい | 元の文字数や位置情報が必要な処理では要確認 |
| noMask | 検出エンティティだけ取得したい | マスク済みテキストが不要な場合に限定し、出力管理を厳格にする |
たとえば、会話分析用に「顧客が契約番号を伝えた」という流れを残したいなら、entityMaskで[NumericIdentifier]のように置換する方が扱いやすい場合があります。一方、音声の一部を後からミュートするような処理では、位置情報や長さを保持する設計が必要になります。
検証結果を合否表に落とし込む
Playgroundで確認した結果は、感覚ではなく合否表に落とし込みます。
| テスト項目 | 合格基準 |
|---|---|
| 氏名検出 | 顧客名、担当者名をPersonとして検出できる |
| 連絡先検出 | 電話番号、メールアドレスを検出できる |
| 識別番号検出 | 契約番号、会員番号、チケット番号を必要に応じて検出できる |
| 過検出 | 製品型番や日付を不要にマスクしすぎない |
| 多話者構造 | AgentとCustomerの発話を崩さず処理できる |
| JSON処理 | アプリ側でType、Confidence、Offset、Lengthを扱える |
| 再現性 | API・モデルバージョンを固定した状態で同じ結果になる |
| 運用性 | 低信頼度や検出失敗時の人手確認フローがある |
合格基準は「100%検出」ではなく、業務リスクに合わせて決めます。本人確認、金融、医療、採用など、PII漏えい時の影響が大きい領域では、人手確認や追加ルールを組み合わせる前提で設計してください。
移行・展開時に失敗しやすいポイント
既存のText PII処理をそのままConversation PIIへ置き換えない
既存のチャットログをText PIIで処理している場合、Conversation PIIへ単純に差し替えるのは避けましょう。入力形式、非同期処理、レスポンス構造、マスク結果が変わる可能性があります。
安全な進め方は、次の順番です。
| 段階 | 作業 |
|---|---|
| 現状確認 | Text PIIで処理している入力、出力、保存先を洗い出す |
| 並行検証 | 同じ会話データをText PIIとConversation PIIで比較する |
| 差分分析 | 検出漏れ、過検出、マスク方式、レスポンス形式の違いを見る |
| 影響評価 | UI、検索、分析、監査ログ、データ保持への影響を確認する |
| 段階展開 | feature flagや対象部門限定で切り替える |
特に、既存システムが「マスク済みテキストの文字数」「オフセット」「特定フィールド名」に依存している場合は、レスポンス差分で不具合が出やすくなります。
実データをPlaygroundへ入れる前に社内承認を取る
Playgroundは便利ですが、そこに入力するデータは慎重に扱う必要があります。顧客名、電話番号、住所、契約番号、問い合わせ履歴などを含む実データを貼り付ける前に、社内のデータ利用ルールを確認してください。
最初の検証では、次の順番を推奨します。
- 完全な合成データで機能を把握する
- 匿名化済みの過去ログで形式を確認する
- 限定された実データを承認済み環境で検証する
- 結果とリスクをセキュリティ・法務・業務部門でレビューする
MicrosoftのTransparency Noteでも、個人情報の編集失敗が大きなリスクにつながるシナリオでは慎重な人間の監督が必要であり、法的・規制上の義務は組織側で評価する必要があると説明されています。(Microsoft Learn)
話者ラベルと改行ルールを軽視しない
Conversation PIIでは、会話構造が重要です。話者ラベルが抜けたり、1つの行に複数話者の発話が混ざったりすると、検証時と本番時で結果がずれる可能性があります。
悪い例です。
本人確認します 山田太郎です 電話番号は090-1234-5678です良い例です。
Agent: 本人確認をします。
Customer: 山田太郎です。
Customer: 電話番号は090-1234-5678です。音声文字起こしの後処理では、話者分離、改行、タイムスタンプ、不要なフィラーの扱いを先に決めておくと、ConvPIIの検証結果が安定しやすくなります。
PII検出を「コンプライアンス完了」と誤解しない
PII検出は、個人情報保護や情報漏えい対策を支援する機能です。ただし、これだけで法令対応や社内統制が完了するわけではありません。
実務では、次のレイヤーを組み合わせる必要があります。
| レイヤー | 具体策 |
|---|---|
| 入力制御 | 収集する会話データを最小化する |
| 検出・マスク | ConvPIIでPIIを検出・編集する |
| アクセス制御 | 生データとマスク済みデータの閲覧権限を分ける |
| ログ管理 | PII本文をログに残さない |
| 人手確認 | 高リスクデータや低信頼度の結果をレビューする |
| 保持期間 | 生データとマスク済みデータの保存期間を分ける |
| 監査 | いつ、誰が、どのデータを処理したかを追跡する |
ConvPIIは強力な補助線ですが、最終的な責任はデータを扱う組織側にあります。
管理者・開発者が今すぐ確認すべきチェックリスト
| チェック項目 | 確認済み |
|---|---|
| Azure AI Foundry／Microsoft Foundry上で利用するプロジェクトが決まっている | |
| ConvPII Playgroundを利用するユーザーと権限を限定している | |
| 旧称・新名称のRBACロールを対応付けて確認した | |
| 合成トランスクリプトを用意した | |
| 日本語・英語・多言語混在のテストケースを用意した | |
| APIバージョンとモデルバージョンを記録した | |
| 検出対象のPII種別を業務要件に合わせて選んだ | |
| redactionPolicyとマスク文字の方針を決めた | |
| JSONレスポンスのType、Confidence、Offset、Lengthを確認した | |
| 低信頼度・検出漏れ・過検出時の人手確認フローを決めた | |
| 実データを使う場合の社内承認を取った | |
| プレビュー利用条件と本番適用可否を確認した | |
| 既存Text PII処理との差分を比較した | |
| 本番展開時のfeature flag、ロールバック手順を用意した |
まとめ：まずはAPI統合前の検証環境として使う
Azure AI Foundryの「Conversational PII NextGen Playground」は、会話ログやトランスクリプトに含まれるPIIを、API実装前に実データに近い形で検証しやすくする更新です。複数話者の会話入力、API Configuration Panel、検出結果のハイライト、JSONレスポンス確認、VS Code連携により、開発者は「動くか」だけでなく「業務要件を満たすか」まで確認しやすくなります。
一方で、これはパブリックプレビューです。管理者はRBAC、プレビュー利用条件、データ取り扱い、言語対応、API・モデルバージョンを確認し、開発者は合成データから検証を始めるべきです。
次に取るべき行動は、既存のチャットログ、通話文字起こし、会議トランスクリプト、AIエージェント会話のどこにPIIが含まれているかを洗い出し、代表的な合成トランスクリプトを作ることです。そのうえでConvPII Playgroundで検出結果を確認し、必要なPII種別、マスク方式、API設定、運用フローを固めてからAPI統合へ進めると、実装後の手戻りを大きく減らせます。
コメント