目次
Sanityは2026年10月28日、 Server v2.45.0でによる文書の作成・・公開を配備済みに照らして検証し、不正な変更を遮断する機能を追加しました。翌29日にはv2.45.2を公開し、MCPクライアントの探索に関係するドキュメント向け条件も修正しています。
Sanity MCP ServerをClaude Code、Cursor、VS Code、Codex などから使い、Content Lakeの文書を変更しているチームが対象です。今回の更新はコンテンツ整合性を高めますが、配備済みスキーマを一意に選べない場合は警告付きで変更を続け、スキーマ自体が配備されていないプロジェクトでは警告も出ません。したがって、更新確認だけで終えず、スキーマの選択、権限、警告時の停止、での拒否試験を合わせて点検する必要があります。
スポンサーリンク
v2.45.0で変わった文書改変の境界
v2.45.0では、作成、パッチ、公開の各変更について、対象データセットに配備されたスキーマを明確に特定できる場合、そのスキーマで検証してから処理します。必須項目の欠落、型の不一致、値の範囲、カスタム検証などに反する変更は遮断されます。AIエージェントが自然言語の指示を誤解したり、古いフィールド名を使ったりしたときに、壊れた文書をそのまま保存・公開する可能性を下げる更新です。
背景にはSanity Content Lakeの設計があります。Content Lakeは意図的にスキーマレスで、Sanity Studioの検証ルールはサーバー側ではなくStudio内で動きます。 、@sanity/client、データ移行、インポートによる一般的な書き込みは、通常はStudioの検証規則を通りません。今回のMCP Serverの検証は、Content Lake全体の保存方式がスキーマ強制型へ変わったという意味ではなく、MCPツール経由の変更前に追加された保護層です。
一意に選べない場合は失敗ではなく警告になる
運用で最も重要なのは例外条件です。v2.45.0は、候補となるスキーマが複数あり、対象を一意に決められない場合、警告を返したうえで変更処理を続けます。プロジェクトに配備済みスキーマがない場合も変更は続き、こちらは警告なしです。「検証機能が追加された」ことを、常に拒否される強制境界と解釈すると、検証されていない変更を見逃します。
複数のStudioやworkspaceが同じデータセットを参照する構成では、どのスキーマを使うべきかが曖昧になりやすくなります。MCP Serverのget_schemaは、workspace名を省略した場合、単一の有効なスキーマ、または複数ある場合の既定workspaceを選びます。厳密な対象が必要な場合はlist_workspace_schemasで候補を確認し、提示されたschemaIdを使って明示的に取得します。
警告が出たまま変更を許すかどうかは、MCPクライアントやエージェント側の運用判断です。本番データセットでは、スキーマが一意に決まらない警告を成功扱いにせず、workspaceとschemaIdを確認するまで次のツール呼び出しを止めるルールにします。警告文をチャット画面に表示するだけでは、自律実行中のエージェントが続行する可能性を除けません。
スポンサーリンク
liveEdit文書は公開IDへ直接変更される
v2.45.0は、liveEditが有効な文書タイプを作成・変更するとき、公開済みIDへ直接書き込むよう改善しました。通常の文書操作では下書きやリリース内のversionを使い、patch_documentsも下書きまたは指定したリリース版へ保存します。しかしliveEditは下書きと公開版を分けないため、変更の影響が公開コンテンツへ直結します。
この違いは承認フローに反映すべきです。通常文書なら「下書きを作る権限」と「公開する権限」を分けられますが、liveEditでは作成・パッチ自体が公開状態を変えます。エージェント用のロールが更新権限を持つ文書タイプにliveEditが含まれていないかを確認し、含まれる場合は人の承認後だけツールを実行するか、対象データセットを分離します。
スキーマ検証と認可は別の制御
スキーマ検証が判断するのは、変更後の文書が定義に適合するかです。誰がどの文書を作成・更新・公開できるかは、SanityのロールとContent permissionsが決めます。正しい形式の悪意ある変更や、権限を持つアカウントの誤操作は、スキーマ検証だけでは防げません。
- Viewerは全データセットの読み取り専用
- Contributorは下書きを作成・更新できるが公開できない
- EditorやDeveloperはデータセットへ読み書きできる
- Enterpriseのカスタムロールではデータセットや文書条件を絞れる
MCP ServerはOAuthを既定とし、認証した利用者の権限で操作します。代わりにAPIトークンを指定した場合は、そのトークンに付与されたロールと権限が境界になります。個人用の強いトークンを共有設定へ埋め込まず、エージェント専用の主体とを使います。公開が不要ならContributor相当、特定タイプだけ扱うならカスタムリソースで対象文書を限定します。
権限は加算される点にも注意が必要です。限定ロールと広いEditorロールを同じ主体へ付与すると、限定側の条件で広い権限を打ち消せません。エージェント用トークンが複数ロールを持つ場合、個々の設定ではなく合成後の実効権限を確認します。
スポンサーリンク
専用MCPツールをCLI代替より優先する
同じ操作について専用MCPツールとSanity CLIコマンドの両方が利用できる場合、v2.45.0は専用ツールを優先するよう改善されました。スキーマを理解するMCPツールを使うことで、検証、下書き、リリースID、liveEditなどの規則を適用しやすくなります。エージェントがターミナルから汎用CLIや独自スクリプトを呼べる構成では、専用ツールの検証を迂回して直接APIへ書き込む経路が残ります。
本番セッションでは、Sanityの変更に必要な専用ツールだけを許可し、任意のシェル実行を同じ承認範囲へ入れないようにします。読み取り、下書き変更、公開、スキーマ配備、データセット設定を別のツール群として扱い、公開や管理系の操作は常時承認対象にします。ツール名や説明の安全注釈は運用の補助であり、Sanity側のを置き換えません。
v2.45.2のOAuth探索修正を誤解しない
10月29日のv2.45.2では、ドキュメントへ誘導するリダイレクトを、ブラウザーのナビゲーションとHTMLまたはMarkdownを要求するリクエストに限定しました。MCPクライアントがOAuthのメタデータを探索するとき、機械向けリクエストまでドキュメントへ転送される状況を避ける修正です。
公式変更履歴は、この修正をやトークン漏えいとして説明していません。脆弱性や実害を推測せず、接続できないクライアントの互換性修正として扱います。接続障害があった環境ではMCPクライアントを再接続し、OAuthの認可先、付与されたSanityアカウント、利用可能ツールを確認します。古い手動トークン設定へ安易に切り替えると、OAuthより強い権限を長期保持する可能性があります。
更新後に行う拒否試験
- 非本番データセットに本番と同じ配備済みスキーマを用意する
list_workspace_schemasとget_schemaで対象を一意に確認する- 必須項目の欠落、誤った型、禁止値を含む作成・パッチを試し、遮断されることを確認する
- 複数スキーマで一意に選べない状態を再現し、警告時にエージェントが停止することを確認する
- 配備済みスキーマがない環境で警告が出ない条件を把握し、本番へ持ち込まない
- Contributor相当の主体で下書きは変更できても公開は拒否されることを確認する
- liveEditタイプへのパッチが公開IDへ反映されることを確認し、承認対象へ追加する
既存文書全体の確認には、Studioプロジェクトのディレクトリからnpx sanity documents validateを実行できます。このコマンドは下書きやContent Release内のversionも含めて検証します。公開済み文書だけを確認したい場合は、下書きを除外してデータセットをエクスポートし、そのファイルを検証します。MCPの1回の変更が拒否されたことと、データセット全体が健全であることを分けて確認してください。
検証で既存文書の別項目に問題が見つかった場合、MCP Serverは警告として報告することがあります。今回変更した項目が通ったことだけを根拠に警告を消さず、文書ID、規則名、既存データか今回の差分かを分けて修正計画へ登録します。公開時に止まる問題は、下書き作成の段階で解消してから人のレビューへ渡します。
本番運用で残す証跡
各セッションについて、利用したMCPクライアント、Sanityの主体、対象project・dataset・workspace、選択したschemaId、呼び出したツール、変更対象の文書ID、警告と拒否結果を記録します。公開操作では、下書きの差分と人の承認者も残します。想定外の変更が見つかったとき、モデルの応答だけでは実際にどの権限とスキーマで書き込んだかを再現できないためです。
今回の更新で、Sanity MCP ServerはStudio外からのAI書き込みにスキーマ検証を持ち込みました。運用上の結論は「最新なら安全」ではなく、検証できた変更だけを通し、検証できなかった警告は止め、公開権限は別の主体へ分けることです。スキーマ選択、認可、承認、証跡の4つを合わせて初めて、本番コンテンツの改変境界になります。
スポンサーリンク
参考資料
- Sanity Docs「Safer document mutations and schema management」（v2.45.0）
- Sanity Docs「Fix MCP client OAuth discovery」（v2.45.2）
- Sanity Docs「Get started with the Sanity MCP server」
- Sanity Docs「Schema validation and the Content Lake」
- Sanity Docs「Roles」
