はじめに
この記事は株式会社ナレッジコミュニケーションが運営するチャットボット と AIエージェント Advent Calendar 2025 の15日目にあたる記事になります！
DatabricksのModel Serving（モデルサービング）を運用していると、「どのエンドポイントに、誰（ユーザー／グループ／サービスプリンシパル）が、どこまでの権限を持つべきか」で悩みがちです。
特に、特定のチーム・プロジェクト・業務用途に閉じたエンドポイントと、ワークスペース共通で使うエンドポイントが混在すると、作成者依存の運用になったり、サービスプリンシパル（SP）の権限が強すぎたりして、管理が難しくなります。
この記事では、実運用を前提に「こうしておくと扱いやすい」という観点で、モデルサービングエンドポイントの権限設計（ベストプラクティス案）をまとめます。
権限の前提：Can View / Can Query / Can Manage の3種類
モデルサービングエンドポイントには、次の3つの権限を設定できます。付与対象は ユーザー／グループ／サービスプリンシパル です。
- Can View：閲覧のみ（推論の実行は不可）
- Can Query：推論（エンドポイント呼び出し）が可能
- Can Manage：設定変更・権限付与・削除など、管理操作が可能
デフォルト権限の注意点
- エンドポイント作成者はデフォルトで Can Manage
- ワークスペース管理者（Admin） もデフォルトで Can Manage
- Adminは、全ユーザーが作成した全エンドポイントを閲覧・編集・削除可能
まず決める：エンドポイントを「用途の広さ」で2種類に分ける
権限設計をシンプルにするため、エンドポイントを以下の2つに分類するのがおすすめです。
-
限定利用のエンドポイント（ドメイン／チーム／プロジェクト単位）
例：特定部署の業務でのみ使う、特定アプリからのみ呼ぶ、など -
WS共通エンドポイント（横断利用）
例：複数チームで共通に使う、共通APIとして提供する、など
方針1：Can Manage（管理権限）は「作成者」ではなく「グループ」で持つ
作成者を管理者のままにすると、異動・退職・担当替えなどで運用が不安定になりがちです。
そのため、Can Manageは役割ベースのグループに寄せるのが扱いやすいです（必要に応じて作成者の権限は外す）。
推奨例（Can Manage）
-
限定利用エンドポイント（ドメイン／チーム／プロジェクト単位）
-
ドメイン管理グループ：Can Manage -
エンドポイント管理者グループ：Can Manage
-
-
WS共通エンドポイント
-
共通エンドポイント管理グループ：Can Manage -
エンドポイント管理者グループ：Can Manage
-
意図としては、以下の両立です。
- エンドポイントの責任範囲を「提供元（ドメイン側）」で持てる
- 障害対応や設定変更など、横断的な運用を「エンドポイント管理者」が担える
方針2：Can Query / Can View は「利用の前提」で分ける
限定利用エンドポイント：基本は Can View（必要な人だけ Can Query）
限定利用のモデルは、誤用やコスト増、想定外の利用を避けるため、デフォルトは“呼べない”寄りにしておくと運用が落ち着きます。
- 関係者以外：Can View
- 推論が必要な人（アプリ・担当者など）：Can Query（ドメイン利用グループ等で付与）
WS共通エンドポイント：WS内の利用者は Can Query を付けやすい
共通提供のエンドポイントは「広く使ってもらう」前提が多いので、
-
WS内共通利用グループ：Can Query
のような設計が分かりやすいです。
（段階公開したい場合は、最初はCan View→承認後Can Queryも有効です）
まとめ：権限設計の例（WS内）
| エンドポイント種別 | Can Manage | Can Query | Can View |
|---|---|---|---|
| 限定利用（ドメイン／チーム／プロジェクト単位） | ドメイン管理グループ + エンドポイント管理者グループ | 必要者のみ（ドメイン利用グループ等） | その他WSユーザー（必要なら） |
| WS共通（横断利用） | 共通エンドポイント管理グループ + エンドポイント管理者グループ | WS内共通利用グループ | 段階公開したい場合に利用 |
WS外共有（外部から呼び出す）とサービスプリンシパルの扱い
WS外からエンドポイントを呼び出す場合、一般に以下が必要です。
- エンドポイントURL
- アクセストークン（Databricks推奨はOAuth想定）
OAuth認証であっても、最終的には エンドポイントに設定した Can View / Can Query / Can Manage が適用されるため、WS外共有でも同じ考え方で制御できます。
SPに Can Manage を付けない（推奨）
SPのクライアントID／シークレットが流出した場合、SPが Can Manage を持っていると、編集・削除などの影響が大きくなります。
そのため、WS外共有用途のSPは原則として次に寄せるのが安全です。
- Can Query（推論実行に必要な最小権限）
- Can View：外部から推論する用途では基本的に使わない（呼び出しても推論できないため）
SPは「グループ管理」がおすすめ（ただしCan Manageグループには入れない）
運用上は、SPを個別にACLへ追加していくより、Can Query専用のグループに所属させる方が管理しやすいです。
-
外部共有（Query）グループを作る - 外部共有用SPをそのグループに所属させる
- エンドポイント側で、そのグループに Can Query を付与する
一方で、Can Manageが付いたグループ（例：エンドポイント管理者グループ）にSPを入れるのは避けるのが無難です。
どうしてもグループ設計が難しい場合は、暫定的に SP単体にCan Queryを直接付与する運用でも構いません。ただし、対象が増えると棚卸しが難しくなりやすい点は注意です。
本記事は、ナレッジコミュニケーションによる生成AIセキュリティ支援の実務知見をもとに執筆しています。
安全にAIを活用するための導入支援・運用設計をご希望の方は、ぜひご相談ください。
AIセキュリティ支援サービス
https://www.knowledgecommunication.jp/product/ai-security.html