PII・PHIを含む生成AIログを守るLog Analyticsロール設計｜Azure Monitor・Microsoft Foundry

Azure Monitor／Microsoft FoundryでPII・PHIを含むプロンプトや応答へのアクセスを最小化するLog Analyticsロール設計では、生成AIの本文を専用のAppGenAIContentテーブルへ分離し、そのテーブルをProtectedに設定します。そのうえで、日常の運用担当者にはログ閲覧権限を持たないメトリック専用ロールだけを付与し、プロンプト、応答、ツール呼び出しを閲覧できる権限はABACとPIMで別管理するのが基本です。

Monitoring Readerはメトリック専用ではなく、ログを含む監視データ全般を読み取れるため、「運用担当者には稼働状況だけを見せ、生成AIコンテンツは見せない」という要件には広すぎます。Microsoftは、専用テーブルとProtected Tablesを使って機微な生成AIテレメトリを分離する仕組みをPublic Previewとして案内しています。(マイクロソフトアジュール)

ただし、2026年9月30日より前は、対象となる生成AI属性がAppGenAIContentだけでなく、従来のAppDependencies、AppTraces、AppEventsにも保存される移行期間です。現在の設計では、AppGenAIContentを保護するだけでなく、早期移行用の機能フラグと既存データへのアクセスも確認する必要があります。(Microsoft Learn)

結論：メトリック閲覧と生成AIコンテンツ閲覧を完全に分ける

推奨構成は、監視データを次の3層に分ける形です。

Microsoft Foundry／Application Insights
├─ Azure Monitor Metrics
│  └─ 日常の運用担当者
│
├─ AppRequests、AppExceptionsなどの一般ログ
│  └─ 障害調査担当者
│
└─ AppGenAIContent［Protected］
   └─ セキュリティ・プライバシー担当者のみ
      PIMによる時間制限付きアクセス

設計上の重要点は次のとおりです。

設計項目	推奨内容
日常監視	Azure Monitor Metricsだけを閲覧可能にする
一般ログ調査	必要なテーブルだけをABACで許可する
プロンプト・応答	`AppGenAIContent`を`Protected`に設定する
機微情報の調査	専用グループへPIMで一時的に付与する
ワークスペース管理	日常運用者と管理者を分離する
データ収集	RBACだけに頼らず、記録前にPII・PHIを削減する

運用担当者に必要なのは、通常、要求数、成功率、エラー率、応答時間、モデル別利用量、ツール実行の成功・失敗といった数値です。プロンプト本文やツールの引数・戻り値を見せなくても、サービスの稼働監視は実現できます。

AppGenAIContentに分離される生成AIデータ

Application Insightsでは、生成AIのコンテンツがLog Analytics上のAppGenAIContentに格納されます。対象にはプロンプトや応答だけでなく、システム指示、ツール定義、ツール呼び出しの引数と結果、評価理由も含まれます。これらはPIIやPHIを含む可能性があるため、一般的な監視ログとは異なるアクセス制御が必要です。(Microsoft Learn)

OpenTelemetry属性	保存される内容	想定されるリスク
`gen_ai.input.messages`	ユーザーのプロンプト、入力メッセージ	氏名、メールアドレス、顧客番号、症状、診療情報
`gen_ai.output.messages`	モデルの応答	入力情報の再掲、要約された個人情報
`gen_ai.system_instructions`	システムプロンプト	内部ルール、業務手順、非公開の指示
`gen_ai.tool.definitions`	利用可能なツールの定義	内部システム名、API構造
`gen_ai.tool.call.arguments`	ツールへ渡した引数	顧客ID、検索条件、レコード識別子
`gen_ai.tool.call.result`	ツールが返した結果	顧客情報、医療情報、社内データ
`gen_ai.evaluation.explanation`	評価時に生成された説明	元のプロンプトや応答の引用、判断理由

Microsoft Foundryのトレースも、ユーザーのプロンプト、応答、アプリケーション固有のコンテンツなどを記録する可能性があります。基盤となるLog Analyticsテーブルを保護すると、Foundry側からトレースを参照する利用者にも、保護テーブル用の追加権限が必要になります。(Microsoft Learn)

Protectedは列のマスキングではない

AppGenAIContentをProtectedにすると、権限を持たない利用者にはテーブルのデータ行が返されなくなります。ただし、テーブル名、列名、データ型などのスキーマは表示されます。また、特定の列だけを伏せ字にする仕組みではなく、テーブルのデータ行全体に対するアクセス制御です。(Microsoft Learn)

そのため、運用担当者にも必要な情報をAppGenAIContent内だけに保存してしまうと、その情報まで見せられなくなります。運用に必要な値は、次のようにコンテンツから切り離してメトリック化するのが適切です。

運用上知りたい情報	運用担当者へ公開する値
エージェントの稼働状況	要求数、成功数、失敗数
応答性能	平均時間、p50、p95、タイムアウト数
モデル利用状況	モデル名、トークン数、呼び出し数
ツール連携状況	ツール種別、成功・失敗、処理時間
品質傾向	集計済み評価スコア
個別の会話内容	公開しない

ツール引数、ツール結果、評価理由、ユーザーID、メールアドレスなどをメトリックのディメンションへ入れないことも重要です。

Monitoring Readerをメトリック専用ロールとして使ってはいけない理由

Azureの組み込みMonitoring Readerは、「メトリックを読むロール」ではありません。公式定義では、メトリックやログなど、すべての監視データを読み取れるロールです。また、コントロールプレーンの*/readも含まれています。Log Analytics Readerも、すべての監視データと監視設定を閲覧できる広いロールです。(Microsoft Learn)

ロール	主な用途	今回の評価
Monitoring Reader	メトリック、ログ、監視設定の閲覧	メトリック専用としては広すぎる
Log Analytics Reader	Log Analyticsを含む監視データ全般の閲覧	日常運用者には原則付与しない
Log Analytics Data Reader	許可されたログの検索・閲覧	一般ログの調査担当者向け
Privileged Monitoring Data Reader	割り当てスコープ内の保護テーブル閲覧	PIMによる一時利用向け
カスタムメトリック閲覧ロール	メトリックのみ閲覧	日常運用者に最適

Azure RBACとLog AnalyticsのABACは加算方式です。制限付きロールを追加しても、同じ利用者がサブスクリプション、リソースグループ、グループメンバーシップなどを通じてMonitoring Readerや*/readを持っていれば、広い権限が有効になります。アクセス制限を成立させるには、上位スコープから継承された広いロールも削除しなければなりません。(Microsoft Learn)

2026年9月30日までの二重保存に注意する

現在の移行スケジュールでは、2026年9月30日より前に取り込まれる次の7属性は、専用のAppGenAIContentと従来テーブルの両方に保存されます。

プロンプト
モデル応答
システム指示
ツール定義
ツール呼び出し引数
ツール呼び出し結果
評価理由

2026年9月30日以降に新しく取り込まれるデータについては、従来テーブル側には属性名とAppGenAIContentへの短い参照情報が残り、実際の値は専用テーブルだけに保存される予定です。ただし、2026年9月30日より前に保存されたデータは、従来テーブルに残り続けます。(Microsoft Learn)

状況	リスク	対応
`AppGenAIContent`だけをProtectedにした	従来テーブルから内容を読まれる可能性がある	早期移行フラグを有効化する
早期移行フラグを有効化した	過去の二重保存データは残る	過去データの保持期間とアクセスを見直す
一般ログ担当者へ旧テーブルを許可した	過去の生成AIコンテンツまで見える可能性がある	対象期間を確認するまで権限を付与しない
移行延期用フラグを利用した	二重保存期間が延びる	セキュリティ上の理由がなければ避ける

早期に専用テーブルだけへルーティングする

Microsoftは、2026年9月30日より前に専用テーブルへの移行を有効化するため、protectGenAISensitiveData機能フラグを用意しています。新規環境では、トレースの本格利用を始める前に有効化するのが安全です。(Microsoft Learn)

az feature register \
  --namespace Microsoft.Insights \
  --name protectGenAISensitiveData

登録状態は次のコマンドで確認できます。

az feature show \
  --namespace Microsoft.Insights \
  --name protectGenAISensitiveData \
  --query properties.state \
  --output tsv

この設定は、新たに取り込まれるデータのルーティングを変更するものです。すでにAppDependencies、AppTraces、AppEventsへ保存された生成AIコンテンツを移動または削除するものではありません。

移行を延期するoptOutProtectGenAISensitiveDataも用意されていますが、これは2027年9月30日に終了予定です。セキュリティを優先する場合は、既存のKQL、Workbook、アラートを更新したうえで、専用テーブルへの移行を進める方が適切です。(Microsoft Learn)

推奨するLog Analyticsロール設計

実務では、個人単位でロールを割り当てるのではなく、Microsoft Entra IDのグループを役割別に作成します。

Entra IDグループ例	利用者	付与する権限	AppGenAIContent
`AI-Ops-Metrics`	日常の運用担当者	メトリック専用カスタムロール	閲覧不可
`AI-Ops-Diagnostics`	障害調査担当者	Log Analytics Data Reader＋テーブル条件	閲覧不可
`AI-Sensitive-Investigators`	セキュリティ・プライバシー担当者	保護テーブル用ロールをPIMで有効化	必要時のみ閲覧
`AI-Telemetry-Admins`	監視基盤管理者	Log Analytics ContributorまたはOwner	設定変更可能
`AI-Protected-Alert-MI`	アラートのマネージドID	必要な保護テーブルだけ	アラート実行時のみ

管理者グループと機微データ閲覧グループは分けます。保護レベルを変更できる人が、日常的にすべての生成AIコンテンツも読める構成にする必要はありません。

日常運用者にはメトリック専用カスタムロールを付与する

Azureの権限定義には、Application Insightsコンポーネントの読み取り、メトリック定義の読み取り、メトリック値の読み取りを個別に許可するアクションがあります。これらだけを使えば、Log Analyticsのクエリ権限やデータアクションを含まないロールを作成できます。(Microsoft Learn)

{
  "Name": "Application Insights Metrics Reader",
  "IsCustom": true,
  "Description": "Read Application Insights and Azure Monitor metrics without log query access.",
  "Actions": [
    "Microsoft.Insights/Components/Read",
    "Microsoft.Insights/Components/MetricDefinitions/Read",
    "Microsoft.Insights/Components/Metrics/Read",
    "Microsoft.Insights/MetricDefinitions/Read",
    "Microsoft.Insights/Metricnamespaces/Read",
    "Microsoft.Insights/Metrics/Read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/<SUBSCRIPTION_ID>"
  ]
}

このロールには、次の権限を入れないことが重要です。

Microsoft.Insights/Components/Query/Read
Microsoft.Insights/logs/data/read
Microsoft.OperationalInsights/workspaces/query/read
Microsoft.OperationalInsights/workspaces/tables/data/read
*/read

ロール定義を登録し、Application Insightsリソースだけをスコープとして割り当てます。

az role definition create \
  --role-definition application-insights-metrics-reader.json

az role assignment create \
  --assignee-object-id <GROUP_OBJECT_ID> \
  --assignee-principal-type Group \
  --role "Application Insights Metrics Reader" \
  --scope <APPLICATION_INSIGHTS_RESOURCE_ID>

カスタムロールのAssignableScopesがサブスクリプションであっても、実際のロール割り当てはApplication Insightsリソースまで狭めます。リソースグループやサブスクリプション全体へ割り当てると、同じ範囲にある別リソースのメトリックまで閲覧できるようになります。

Workbookを見せる場合は、対象Workbookに対するMicrosoft.Insights/Workbooks/Readなどの読み取り権限を別途付与します。メトリック専用ロールへ安易に*/readを追加して、ポータル操作を通しやすくする設計は避けてください。(Microsoft Learn)

ダッシュボードはログベースメトリックを避ける

Application Insightsには、事前集計された標準メトリックと、Log Analyticsのログからクエリ時に生成されるログベースメトリックがあります。ログベースメトリックは、内部的にはKQLでログを読み取るため、メトリック専用ロールでは表示できない場合があります。(Microsoft Learn)

日常運用者向けダッシュボードでは、次のデータを利用します。

Azure Monitor Metricsに保存される標準メトリック
メトリックストアへ送信したカスタムメトリック
プロンプト本文を含まない集計済みの数値
メトリックアラートから得られる状態情報

既存のWorkbookやダッシュボードにKQLが含まれている場合は、「グラフに見えるからメトリックだろう」と判断せず、データソースがMetricsかLogsかを確認してください。

障害調査担当者には一般ログだけを許可する

障害調査でAppRequests、AppExceptions、AppDependenciesなどが必要な場合は、Log Analytics Data Readerを基礎にして、ABAC条件で必要なテーブルだけを許可します。

Log Analytics Data Readerには、ワークスペースでクエリを実行するアクションと、許可されたテーブルのデータを読むDataActionが含まれています。Log Analytics Readerより狭い権限でログ調査を行えるロールです。(Microsoft Learn)

ただし、2026年9月30日より前の従来テーブルには生成AIコンテンツが二重保存されている可能性があります。次の条件を満たすまでは、一般ログ担当者へAppDependencies、AppTraces、AppEventsを許可しない方が安全です。

protectGenAISensitiveDataが有効になっている
新規データに生のプロンプトや応答が残っていない
過去データの保持期間とアクセス方針が決まっている
ステージング環境で旧テーブルを検査している

AppGenAIContentの閲覧はABACとPIMで限定する

Protected Tablesは、標準の読み取りロールに対して拒否を既定とし、明示的なABAC条件を持つ利用者だけにアクセスを許可します。すべての保護テーブルを読めるPrivileged Monitoring Data Readerもありますが、割り当てたスコープ内の保護テーブル全体を閲覧できるため、常時付与には適しません。(Microsoft Learn)

Log Analyticsワークスペースから直接クエリする場合、AppGenAIContentだけを許可するABAC条件は、次のように構成できます。これはMicrosoftの公式例で使われているテーブル名をAppGenAIContentへ置き換えたものです。(Microsoft Learn)

(
  (
    !(ActionMatches{'Microsoft.OperationalInsights/workspaces/tables/data/read'})
  )
  OR
  (
    @Resource[Microsoft.OperationalInsights/workspaces/tables:name]
      StringEquals 'AppGenAIContent'
    AND
    @Resource[Microsoft.OperationalInsights/workspaces/tables:protectionLevel]
      StringEquals 'Protected'
  )
)

DataActionを含むロールを条件なしで割り当てると、割り当てスコープ内のデータ全体へアクセスできる可能性があります。カスタムロールを作成しただけで安心せず、ロール割り当てにABAC条件が付いていることまで確認してください。(Microsoft Learn)

機微データの調査担当者には、PIMで次のような運用を設定します。

通常時はロールを無効にする
インシデント番号や調査理由を入力させる
多要素認証を要求する
承認者をセキュリティ担当者にする
有効時間を1時間または2時間に制限する
利用後は自動的に権限を失効させる

Protected Tablesは、カスタムロールまたはPrivileged Monitoring Data ReaderをPIMの対象にして、時間制限付きのアクセスにできます。(Microsoft Learn)

AppGenAIContentをProtectedに設定する手順

自動作成されたManaged Workspaceではないか確認する

Application Insights作成時にLog Analyticsワークスペースを指定しなかった場合、AzureがManaged Workspaceを自動作成している可能性があります。

Managed Workspaceが配置されたリソースグループにはDeny Assignmentが設定されており、Protected Tablesの構成がブロックされます。AppGenAIContentを保護するには、自組織が所有する通常のLog AnalyticsワークスペースへApplication Insightsを接続する必要があります。(Microsoft Learn)

確認するポイントは次のとおりです。

ワークスペース名がmanaged-<Application Insights名>-wsになっていないか
リソースグループ名がai_<Application Insights名>_..._managedになっていないか
ワークスペースのManaged ByにApplication Insightsが表示されていないか
リソースグループにDeny Assignmentがないか

該当する場合は、組織管理のLog Analyticsワークスペースを作成し、Application Insightsの接続先を変更してから保護設定を行います。

AppGenAIContentのProtection levelを変更する

ポータルでは、次の順に操作します。

Log Analyticsワークスペースを開く
設定からテーブルを開く
AppGenAIContentのメニューを開く
テーブルの管理を選択する
Protection levelをProtectedへ変更する
保存する

設定変更には、ワークスペースに対するOwnerまたはLog Analytics Contributorと、Microsoft.OperationalInsights/workspaces/tables/protectionLevel/writeが必要です。(Microsoft Learn)

Azure CLIからREST APIを呼び出す場合は、次のように設定できます。APIバージョンは実行時点の公式ドキュメントも確認してください。(Microsoft Learn)

subscriptionId="<SUBSCRIPTION_ID>"
resourceGroupName="<RESOURCE_GROUP_NAME>"
workspaceName="<WORKSPACE_NAME>"
tableName="AppGenAIContent"

url="https://management.azure.com/subscriptions/${subscriptionId}"
url+="/resourceGroups/${resourceGroupName}"
url+="/providers/Microsoft.OperationalInsights"
url+="/workspaces/${workspaceName}"
url+="/tables/${tableName}"
url+="?api-version=2025-02-01"

az rest \
  --method patch \
  --url "$url" \
  --body '{"properties":{"protectionLevel":"Protected"}}'

DataActionsOnlyを有効にする

既定状態では、ReaderやMonitoring Readerのようなコントロールプレーンの読み取りロールが、ログデータへの暗黙的なアクセス経路を持つことがあります。

DataActionsOnlyを有効にすると、ログデータへのアクセス判定がDataActionsに限定されます。これにより、コントロールプレーンの*/readを経由してログへアクセスする経路を閉じられます。(Microsoft Learn)

ポータルでは、Log Analyticsワークスペースの設定、プロパティから、データ承認モードをData actions onlyに変更します。

CLIでは次のように設定できます。

subscriptionId="<SUBSCRIPTION_ID>"
resourceGroupName="<RESOURCE_GROUP_NAME>"
workspaceName="<WORKSPACE_NAME>"

url="https://management.azure.com/subscriptions/${subscriptionId}"
url+="/resourceGroups/${resourceGroupName}"
url+="/providers/Microsoft.OperationalInsights"
url+="/workspaces/${workspaceName}"
url+="?api-version=2025-02-01"

az rest \
  --method patch \
  --url "$url" \
  --body '{"properties":{"features":{"dataAuthorizationMode":"DataActionsOnly"}}}'

DataActionsOnlyを有効化すると、これまでMonitoring Readerだけでログを見ていた利用者はアクセスできなくなる可能性があります。先に利用者とアラートの権限を棚卸しし、必要なDataActionを持つロールへ移行してから切り替えてください。

リソースコンテキストを使う場合はRequire workspace permissionsにする

Application Insightsや関連画面からログへアクセスする経路では、リソースコンテキストの権限判定が関係する場合があります。

Log Analyticsワークスペースのアクセス制御モードがUse resource or workspace permissionsの場合、Azureリソースへの読み取り権限によってログ全体へアクセスでき、ワークスペース側のABAC条件が無視される可能性があります。リソースコンテキストでもABACを確実に適用したい場合は、対象ワークスペースをRequire workspace permissionsへ変更します。(Microsoft Learn)

設定後は、次の両方で動作確認してください。

Log AnalyticsワークスペースのLogs画面
Application InsightsまたはMicrosoft Foundryのトレース画面

一方だけを確認すると、別のアクセス経路から機微情報が見える設定を見逃すことがあります。

設定後に行うアクセス検証

検証では、少なくとも3種類のテストアカウントを用意します。

テスト利用者	期待する結果
メトリック専用利用者	メトリックは表示されるが、Logsは実行できない
一般ログ調査利用者	一般ログは表示されるが、`AppGenAIContent`は0件
PIM有効化済み調査利用者	`AppGenAIContent`のデータ行が表示される

一般ログ調査利用者で次のKQLを実行します。

AppGenAIContent
| project
    TimeGenerated,
    InputMessages,
    OutputMessages,
    ToolCallArguments,
    ToolCallResult
| take 10

Protected Tablesでは、権限がない場合でも必ずしも403エラーにはなりません。クエリ自体は成功し、0行が返されるのが公式に案内されている動作です。(Microsoft Learn)

そのため、検証結果は次のように判定します。

メトリック専用利用者がLogsを開けない：正常
一般ログ調査利用者のクエリが成功し、0行になる：正常
一般ログ調査利用者に1行でも返る：権限設定を再確認
PIM有効化後の調査利用者にデータが返る：正常
PIM失効後もデータが返る：継承ロールやキャッシュを確認

さらに、次の項目も確認します。

Foundryのトレース画面でプロンプトや応答が表示されない
Metrics Explorerの稼働グラフは表示される
一般ログから生のプロンプトや応答が取得できない
サブスクリプションやリソースグループから広いロールを継承していない
Activity LogのUpdate Tableで保護レベルの変更履歴を確認できる

Protected Tablesの設定変更は、ワークスペースのActivity LogにUpdate Tableとして記録されます。(Microsoft Learn)

よくある設計ミスと対処法

設計ミス	問題	対処
Monitoring Readerを運用担当へ付与する	ログを含む監視データ全般を読める	メトリック専用カスタムロールへ変更する
AppGenAIContentだけをProtectedにする	移行前の旧テーブルに内容が残る	早期移行フラグと過去データを確認する
Managed Workspaceをそのまま使う	Deny Assignmentで保護設定できない	組織所有のワークスペースへ接続する
制限ロールを追加するだけ	継承された広いロールが優先される	上位スコープとグループ経由の権限を削除する
DataActionsOnlyを設定しない	コントロールプレーン経由のアクセスが残る	利用者を移行してから有効化する
Privileged Monitoring Data Readerを常時付与する	すべての保護テーブルを継続的に読める	PIMまたはテーブル限定のカスタムロールを使う
KQLベースのグラフをメトリックと誤認する	メトリック専用利用者には表示できない	Azure Monitor Metricsへ置き換える
403エラーだけを確認する	Protectedの0行応答を見逃す	行数と実データの有無を確認する

アラートとクロスワークスペースクエリにも注意する

Protected TablesはPublic Previewのため、通常のLog Analyticsテーブルとは動作が異なる部分があります。

権限のないクエリはエラーではなく0行になる
テーブルのスキーマは権限がなくても表示される
app()やworkspace()を使うクロスワークスペースクエリは未対応
保護テーブルを読むアラートには適切な権限を持つマネージドIDが必要
エクスポート、共有、検索ジョブなどのデータ移動操作は、必要なアクセスがなければ失敗する

これらの制約は、Protected Tablesのプレビュー時点の公式仕様です。複数ワークスペースをまたぐ監視や、保護テーブルを使うログアラートを設計している場合は、事前検証が必要です。(Microsoft Learn)

アラートについては、日常的な死活監視や性能監視をAppGenAIContentへ依存させない設計が望ましいです。要求数、エラー率、応答時間などはメトリックアラートで監視し、プロンプト本文を使う検査だけを専用のマネージドIDと保護テーブル用ロールで実行します。

RBACだけでなく記録するデータ自体を減らす

Protected Tablesは、記録されたデータへのアクセスを制限する仕組みです。プロンプトへ入力された個人情報を自動的に匿名化したり、認証情報を安全な値へ置き換えたりする機能ではありません。

Microsoft Foundryのトレースに関する公式ガイダンスでも、シークレット、資格情報、トークンを記録しないこと、個人データを記録前に削減または編集すること、アクセス制御と保持期間を設定することが推奨されています。(Microsoft Learn)

実装段階では、次の対策も組み合わせます。

APIキー、アクセストークン、パスワードをトレース対象から除外する
メールアドレスや電話番号を記録前にマスキングする
患者名と診療情報を同じログへ残さない
ツール呼び出し結果を全文ではなく成功・失敗と件数だけにする
評価処理ではプロンプト全文ではなく参照IDを利用する
本番環境と検証環境のワークスペースを分離する
AppGenAIContentの保持期間を業務上必要な期間に限定する
権限付与、PIM有効化、クエリ実行を監査する

最も安全なのは「権限がある人なら見られる」状態を作ることではなく、「そもそも不要なPII・PHIを保存しない」ことです。

実施すべき作業を整理する

PII・PHIを含むプロンプトや応答へのアクセスを最小化するには、次の順で対応します。

Application Insightsの接続先が組織所有のLog Analyticsワークスペースか確認する
protectGenAISensitiveDataを有効化し、生成AIコンテンツを専用テーブルだけへ送る
AppGenAIContentをProtectedに設定する
ワークスペースでDataActionsOnlyを有効化する
必要に応じてアクセス制御モードをRequire workspace permissionsへ変更する
運用担当者をメトリック専用カスタムロールへ移行する
一般ログ担当者には必要なテーブルだけをABACで許可する
機微データ閲覧権限はPIMで時間制限付きにする
旧テーブルに残る過去の生成AIコンテンツを確認する
Log Analytics、Application Insights、Foundryの各画面で権限テストを行う

特に重要なのは、Monitoring Readerを「メトリックを見るだけの安全なロール」と考えないことと、2026年9月30日までの二重保存期間を見落とさないことです。専用テーブル、Protected Tables、DataActionsOnly、ABAC、PIMを組み合わせることで、運用担当者にはサービスの状態を見せながら、プロンプト、応答、ツール呼び出しに含まれるPII・PHIへのアクセスを必要最小限に抑えられます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

PII・PHIを含む生成AIログを守るLog Analyticsロール設計｜Azure Monitor・Microsoft Foundry

結論：メトリック閲覧と生成AIコンテンツ閲覧を完全に分ける

AppGenAIContentに分離される生成AIデータ

Protectedは列のマスキングではない

Monitoring Readerをメトリック専用ロールとして使ってはいけない理由

2026年9月30日までの二重保存に注意する

早期に専用テーブルだけへルーティングする

推奨するLog Analyticsロール設計

日常運用者にはメトリック専用カスタムロールを付与する

ダッシュボードはログベースメトリックを避ける

障害調査担当者には一般ログだけを許可する

AppGenAIContentの閲覧はABACとPIMで限定する

AppGenAIContentをProtectedに設定する手順

自動作成されたManaged Workspaceではないか確認する

AppGenAIContentのProtection levelを変更する

DataActionsOnlyを有効にする

リソースコンテキストを使う場合はRequire workspace permissionsにする

設定後に行うアクセス検証

よくある設計ミスと対処法

アラートとクロスワークスペースクエリにも注意する

RBACだけでなく記録するデータ自体を減らす

実施すべき作業を整理する

この記事を書いた人

コメント

コメントするコメントをキャンセル

PII・PHIを含む生成AIログを守るLog Analyticsロール設計｜Azure Monitor・Microsoft Foundry

結論：メトリック閲覧と生成AIコンテンツ閲覧を完全に分ける

AppGenAIContentに分離される生成AIデータ

Protectedは列のマスキングではない

Monitoring Readerをメトリック専用ロールとして使ってはいけない理由

2026年9月30日までの二重保存に注意する

早期に専用テーブルだけへルーティングする

推奨するLog Analyticsロール設計

日常運用者にはメトリック専用カスタムロールを付与する

ダッシュボードはログベースメトリックを避ける

障害調査担当者には一般ログだけを許可する

AppGenAIContentの閲覧はABACとPIMで限定する

AppGenAIContentをProtectedに設定する手順

自動作成されたManaged Workspaceではないか確認する

AppGenAIContentのProtection levelを変更する

DataActionsOnlyを有効にする

リソースコンテキストを使う場合はRequire workspace permissionsにする

設定後に行うアクセス検証

よくある設計ミスと対処法

アラートとクロスワークスペースクエリにも注意する

RBACだけでなく記録するデータ自体を減らす

実施すべき作業を整理する

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル