Microsoft Purview 統合カタログのデータプロダクトで「Request Access（アクセスを要求）」を押すと、Purpose プルダウンに既定の3項目が表示されます。削除や名称変更を REST API（policy set 系）で試すと HTTP 500 になるケースもあります。この記事では、仕様として何が可能で何が不可能か、UIでの設定手順、現実的な回避策、必要な権限を整理します。
結論：既定の3つの Purpose は削除・変更できない（現時点の仕様）
先に結論から整理します。
- 既定で表示される3つの Purpose（例：Assessing Fit / Critical Reporting など）は、システム定義の値としてロックされており、削除・名称変更・非表示はできません。
- UI（Purview Studio）で管理できるのは、自分たちで追加したカスタム Purpose だけです。
- REST API（policy set エンドポイント）で既定 Purpose を直接いじろうとして HTTP 500 が返るのは、その更新がサポート外（想定外の更新）になりやすいことが主因です。
つまり、「既定の3つを消したい／置き換えたい」という要望に対しては、今のところ“削除”ではなく“運用で使わせない設計”に寄せるのが現実的です。
Purpose とは何か：統合カタログの「Request Access」で何のために選ばせるのか
統合カタログ（Unified Catalog）のデータプロダクトで「Request Access」を実行すると、申請フォーム内に Purpose のプルダウンが出ます。Purpose は端的に言うと、
- 「このデータを何の目的で利用するのか」
- 承認者（データプロダクト所有者など）が「この用途なら許可できる／追加確認が必要」と判断するための材料
- 後から監査・振り返りをする際に「アクセス許可が妥当だったか」を説明しやすくするためのメタ情報
という役割を持ちます。データガバナンスの観点では、Purpose は「利用目的の正当性」を示す入口であり、承認ワークフロー・監査ログ・アクセス条件（ポリシー）と組み合わせることで初めて価値が出ます。
REST API（policy set）で既定 Purpose を更新しようとして HTTP 500 になる理由
Purview のアクセス管理は、内部的には「ポリシー」「ポリシーセット」「アクセス要求設定」など複数の要素で構成されます。Purpose の選択肢は見た目には単なるプルダウンですが、実体としてはアクセス要求の設定（アクセス ポリシーの一部）に紐づく扱いになります。
このとき、既定で用意されている Purpose のような “システム値” は、Microsoft 側が整合性（コンプライアンス／監査モデル、他機能との連携）を崩さないためにロックしている領域になりがちです。そのため、policy set 系のエンドポイントから無理に更新しようとすると、
- 入力は受理されたように見えても、サーバー側のバリデーションや整合性チェックで破綻する
- 結果として HTTP 500（内部サーバーエラー） が返ってくる
という挙動になります。500 は「クライアントのリクエストが悪い（400）」と違い、サービス側が想定していない状態に入ったことを示唆します。実務的には「その操作は API でやる前提になっていない」と捉えるのが安全です。
| 観点 | REST API（policy set 系） | Purview Studio（UI） |
|---|---|---|
| 既定の Purpose を削除／変更 | 非サポート（失敗しやすい／500になりやすい） | 不可（UIでもロック） |
| カスタム Purpose の追加 | 想定されていない可能性が高い（構成が崩れるリスク） | 可能（推奨） |
| 運用ルールの反映 | 自動化はできるが、Purposeの置換は難しい | 説明文・選択肢の設計で誘導しやすい |
| サポート観点 | 仕様変更・例外ケースに弱い | サポートされる操作範囲が明確 |
結論として、Purpose の「既定値の置換」を API で実現しようとするより、UIで許容されている範囲（カスタム Purpose の追加・整理）を最大限活用し、どうしても足りないところは運用で補うのが失敗しにくい進め方です。
Purview Studio でできること：カスタム Purpose の追加・整理
統合カタログの機能が有効化されている前提で、データプロダクト単位に Purpose を追加・編集できます。手順は次のイメージです（UI文言は環境によって若干異なる場合があります）。
- Purview Studio（ガバナンスポータル）で対象のデータプロダクトを開く
- 上部メニューで Access（アクセス）を選択
- Access request settings（アクセス要求設定）を開く
- Purpose options の Edit（編集）をクリック
- Purpose を追加／（自分で追加したもののみ）名称変更／（自分で追加したもののみ）削除
- Save（保存）
ここで重要なのが、編集対象の範囲です。
| Purposeの種類 | 例 | 編集可否 | コメント |
|---|---|---|---|
| システム定義（既定） | Assessing Fit / Critical Reporting など | 不可 | 削除・名称変更・非表示ができない |
| カスタム（自社追加） | 社内BIレポート、顧客分析、運用監視など | 可 | 追加・名称変更・削除ができる |
「既定の3つだけが邪魔なので消したい」という気持ちは自然ですが、現時点の仕様では消せません。代わりに、選ばせたい Purpose を明確に用意し、ユーザーが迷わない形に整えることで、実害を最小化できます。
既定 Purpose を“実質的に使わせない”ための設計テクニック
既定の Purpose が消せない以上、成功しやすいのは「ユーザーが自然にカスタム Purpose を選ぶ」状態を作ることです。ここでは、現場で効きやすい設計を具体的に紹介します。
Purpose 名称の命名規則を決める（検索性と迷いを減らす）
Purpose は短いテキストだからこそ、命名の揺れが運用負債になります。おすすめは、用途の大分類を先頭に付ける方式です。
- BI: 経営ダッシュボード／定例レポート／部門KPI
- Analytics: 分析・検証（アドホック分析、施策効果測定）
- ML: 機械学習（特徴量作成、学習、推論検証）
- Ops: 運用（監視、障害調査、監査対応）
- Dev/Test: 開発・テスト（本番データ利用が必要な場合のみ）
こうしておくと、既定の「Assessing Fit」等よりも、ユーザーは自分の業務に近い選択肢を見つけやすくなります。
「推奨」や「必須アクション」を Purpose に含める（誤選択の抑制）
UI上で既定値を消せないなら、選択肢そのものに運用ルールを埋め込むのが有効です。
- 【推奨】BI: 定例レポート（部門長承認）
- 【推奨】Analytics: 施策効果測定（期間限定）
- 【要追記】その他（申請理由欄に利用目的を具体的に記載）
「その他」を用意しておくと、既定 Purpose を雑に選ぶ人を減らしやすくなります。承認者側も「その他を選んだ＝理由欄が薄いと差し戻す」というルールを作りやすくなります。
Purpose の数は増やしすぎない（5〜12個くらいが運用しやすい）
選択肢を増やしすぎると、今度は「どれを選べばいいか分からない」問題が起こり、結局既定 Purpose に流れます。おすすめは、最初は少数精鋭で始めて、運用ログを見て増減させるやり方です。
| 状態 | 起きがちなこと | 対策 |
|---|---|---|
| 選択肢が少なすぎる | 「その他」だらけになり、監査・分析で分類できない | 頻出用途を2〜3個追加して粒度を上げる |
| 選択肢が多すぎる | 迷って適当に選ぶ／既定 Purpose に流れる | 大分類＋補足の形に統合する |
| 名称が曖昧 | 承認者が判断できず差し戻しが増える | 誰が見ても用途が分かる業務語に寄せる |
申請フォームの説明文（ガイダンス）を強化する
Purpose を運用でコントロールするには、申請者が読まざるを得ない場所にルールを書くのが重要です。例えば次のような文面が効きます。
- 「Purpose は最も近い社内 Purpose（【推奨】から始まるもの）を選択してください。」
- 「既定 Purpose（Assessing Fit 等）は移行期間の互換用途です。原則として使用しないでください。」
- 「『その他』を選ぶ場合は、理由欄に対象データ・利用期間・利用者・成果物を記載してください。」
この“誘導”だけで、既定 Purpose の誤使用はかなり減ります。
回避策：カスタムのアクセス ポリシーセットを用意する（設計の自由度を上げる）
「既定の枠組みに依存せず、自社のガバナンスに合わせたPurpose群を持ちたい」という場合、アプローチとしてはカスタムのアクセス ポリシーセットを用意する案があります。
一般的な流れの一例：
- Purview Studio の Settings（設定） を開く
- Access Management（アクセス管理） → Access Policies（アクセス ポリシー） に移動
- 新しいカスタム ポリシーセットを作成
- 自社運用に合わせて、承認者・条件・（可能な範囲で）Purpose の運用設計を行う
注意点：「カスタム ポリシーセットを作れば、既定の Purpose が UI から完全に消える／非表示になる」とまでは言い切れません。環境や機能の実装状況によっては、既定値が残ったままになることもあり得ます。ここでの狙いは、
- 既定の仕組みを“置き換える”というより、自社の承認・運用の中心をカスタム側に寄せる
- Purpose を含めた申請・承認の設計を自分たちのルールで標準化する
という方向性です。結果として、既定 Purpose を選ばれても承認の段階で弾ける、または差し戻せるようになります。
「Access request settings」が見えない／編集できないときのチェックポイント（権限とスコープ）
Purpose の編集画面や、Access Management のメニュー自体が見えないケースは少なくありません。多くの場合、原因はロール不足か割り当てスコープ（コレクション階層）のズレです。
よく使うロールの整理
| ロール | 主な役割 | このテーマで期待すること |
|---|---|---|
| Purview Administrator | Purview 全体の管理 | Access Management を含む設定画面へのフルアクセス |
| Global Administrator（Entra ID） | テナント全体管理 | 前提条件の整備やロール割り当ての調整ができる |
| Policy Author | ポリシーの作成・更新 | アクセス ポリシーやポリシーセットの設計・管理に関与 |
| Collection Administrator | コレクション単位の管理 | 該当コレクション配下の管理機能へアクセス |
| Data Product Owner | データプロダクトの所有・責任 | 申請承認や、プロダクト設定（範囲内）の管理 |
| Data Curator | メタデータ整備・キュレーション | カタログ運用に関与（ただし管理画面が出ないことも） |
スコープの落とし穴：ルート コレクションに付与されているか
Purview の権限は「どのコレクションに割り当てたか」で見える機能が変わります。特に Access Management まわりは、
- ルート コレクションに必要ロールが付与されていない
- 子コレクションだけに付与している
という状態だと、設定メニューが出なかったり、編集ボタンが表示されなかったりします。まずは「誰が」「どのコレクション」にロールを持っているかを棚卸しするのが近道です。
機能が出ない場合の実務的な切り分け
| 症状 | 原因候補 | 確認・対策 |
|---|---|---|
| Access request settings が見えない | ロール不足／機能が未有効 | Purview Administrator 付与、統合カタログ機能の有効化状況を確認 |
| Edit が押せない | 対象がシステム定義／権限不足 | カスタム Purpose のみ編集可能。Data Product Owner 等の権限も確認 |
| 環境によって画面が違う | テナント・リージョン差／段階的展開 | 別ブラウザで再ログイン、キャッシュ削除、時間を置いて再確認 |
「既定 Purpose を消せない」前提で、ガバナンス品質を上げる運用案
ここからは、既定値が残る前提で、申請品質と承認効率を上げるための実践案です。単に「使わないでください」と言うだけだと形骸化しやすいので、仕組み側に寄せます。
承認者が判断できる“申請の最低要件”をテンプレ化する
Purpose は入口に過ぎません。承認者が本当に知りたいのは「誰が、いつまで、何を、何のために、どこへ出すのか」です。申請者向けに、次の項目を理由欄に書かせる運用が効きます。
- 利用目的：（Purpose の補足。成果物が何かまで）
- 利用期間：開始日・終了日（期限付きアクセスに寄せる）
- 利用者：個人名／チーム名
- 取り扱い：社外共有の有無、加工の有無、保存先
Purpose の既定値が残っていても、ここが揃っていれば承認は回ります。逆にここが空っぽなら、Purpose が良さそうでもリスクが残ります。
Purpose と承認フローを連動させる（差し戻しを減らす）
可能なら、Purpose のカテゴリに合わせて承認フローや追加確認の観点を変えると運用が安定します。例：
- BI: データ品質と定義の確認（レポートが広く配布されるため）
- Analytics: 期間限定・目的限定で許可（アドホックが多いため）
- ML: 学習データの二次利用・再識別リスクの確認
- Ops: 緊急時の取り扱い（監査ログと最小権限）
Purpose が「選ぶだけの儀式」にならず、承認判断の軸として機能します。
既定 Purpose を選んだ申請は“自動で差し戻す”運用を作る
「既定 Purpose を絶対に使わせたくない」なら、運用ルールとして次を明文化します。
- 既定 Purpose を選んだ申請は、原則差し戻し（理由欄に具体化を求める）
- 移行期間のみ例外を認める（期限を決める）
最初は面倒に見えますが、数週間で申請者側の行動が変わり、結果的に承認負荷が下がることが多いです。
REST API を使うなら：Purpose の置換ではなく「監査・可視化・ガードレール」へ寄せる
「APIで Purpose を消したい」というニーズの背景には、たいてい次の2つがあります。
- 手作業での設定がつらい（複数プロダクトに一括適用したい）
- 運用を強制したい（ルール逸脱を防ぎたい）
この場合、APIの使いどころを「Purpose 値の破壊的変更」ではなく、次の方向に振ると現実的です。
- 現状把握：どのデータプロダクトで、どんなアクセス要求設定になっているかを棚卸しする
- 監査：申請・承認のログから、既定 Purpose がどの程度使われているかを可視化する
- 運用ガード：既定 Purpose が多いチームに周知を入れる、教育コンテンツを改善する
「消す」よりも「使われない状態にする」「使われたら検知して是正する」の方が、組織運用として再現性が高いです。
よくある質問
既定 Purpose の表示順を入れ替えられますか？
既定値はシステム定義で固定されているため、表示順の制御も難しいことが多いです。カスタム Purpose 側に命名規則（【推奨】やカテゴリ接頭辞）を付け、ユーザーが迷わない状態を作るのが有効です。
既定 Purpose を“非表示”にする設定はありますか？
現時点では、既定 Purpose を非表示にする正式な手段は提供されていない前提で設計するのが安全です。
統合カタログのメニューが見えません
ロール（Purview Administrator / Collection Administrator 等）と、ロールの付与先がルート コレクションになっているかを確認してください。加えて、機能の段階的展開の影響で UI が異なることもあるため、別ブラウザで再ログイン・キャッシュ削除も試す価値があります。
どうしても既定 Purpose を変更したい場合は？
仕様として不可である以上、改善を求めるには Microsoft 側への要望が必要です。実務としては、カスタム Purpose を整備し、既定 Purpose を選んだ申請を差し戻すなど、運用で吸収しつつフィードバックを継続するのが現実的です。
まとめ：できないことを前提に、Purpose を“運用で効く仕組み”にする
- 既定の3つの Purpose はシステム定義で、UIでもAPIでも削除・変更できない
- UIで編集できるのは自社で追加したカスタム Purpose のみ
- REST API（policy set）で既定 Purpose を触ろうとして HTTP 500 になるのは、更新がサポート外になりやすいため
- 現実的な対策は、カスタム Purpose の設計（命名規則・数の最適化・ガイダンス）と、承認運用のルール化
- 画面が見えない場合は、Purview Administrator などの権限と、ルート コレクションへの割り当てを最優先で確認
Purpose は「選択肢を消すかどうか」よりも、「承認判断に使える情報として機能しているか」が本質です。既定値を消せない前提でも、カスタム Purpose と運用ルールを組み合わせれば、申請品質とガバナンス品質は十分に引き上げられます。
コメント