ClaudeとSanityを連携する方法 — スキーマ配備からドラフト管理までMCPで扱う

Claude Sanity連携とは — 何ができるか

Sanity連携とは、Sanity社が公式に運営するMCPサーバー(https://mcp.sanity.io)にClaudeをつなぎ、構造化コンテンツの検索・作成・更新とスキーマの配備を会話から行えるようにする仕組みです。Claudeのコネクタディレクトリでは「Anthropic verified」の表示があり、カテゴリーは「Developer tools」と「Productivity」、追加時期は2026年3月、サインインは必須と案内されています。

コネクタページの説明は、コンテンツ監査の実行、ドキュメントの更新、リリースの調整、プロジェクト横断の検索です。スキーマ・コンテンツ・設定を含む新規プロジェクトを会話だけで立ち上げる使い方も挙げられています。

読み手の作業は大きく2つに分かれます。

• 編集者・運用担当: 記事の下書き作成、既存ドキュメントの一括修正、リリースへの振り分け
• 開発者: スキーマの確認と配備、データセットやCORS設定などのプロジェクト管理

同じサーバーがどちらの道具も持っているため、ClaudeはSanityのスキーマを読んだうえで、その型に合うドキュメントを作れます。

ClaudeにSanityを接続する手順

接続の入口は3つあります。使う面ごとに選びます。

claude.aiやClaude Desktopから追加する

コネクタの共通手順は、ディレクトリでSanityを選んで「Add to Claude」から追加し、Sanityのアカウントでサインインする流れです。認証はOAuthで、Sanityのプロジェクトに対して自分の権限で操作します。

Team・Enterpriseプランでは、Ownerが組織側で先にコネクタを有効化する必要があります。有効化しただけではメンバーは使えず、各自の認証が別に要ります。

Claude Codeから追加する

Claude Codeでは、Sanity公式ドキュメントが次のコマンドを案内しています。サーバー名を Sanity にする点が、後述の権限設定に効きます。

claude mcp add Sanity -t http https://mcp.sanity.io --scope user

次にClaude Codeを起動したとき、SanityのMCPが使える状態になり、OAuthで認証します。MCPの追加方法の全体像はClaude CodeのMCPサーバー設定ガイドに、運用面の考え方はMCP実践ガイドにまとめています。

Sanity CLIで自動設定する

Sanity CLIには、Cursor・VS Code・Claude Codeといった主要なAIエディタを検出して設定を書き込むコマンドがあります。

npx sanity@latest mcp configure

ログイン済みのCLIユーザーで認証されるため、手動でOAuthを通したりトークンを管理したりする必要がありません。

APIトークンで認証する場合

OAuthの代わりに、設定に Authorization ヘッダーを置いてAPIトークンで認証することもできます。ヘッダーを設定するとサーバーはOAuthを使わず、ツール呼び出しはそのトークンのロールと権限の範囲で動きます。トークンはsanity.io/manageかCLIのtokensコマンドで作成できます。

{
  "mcpServers": {
    "Sanity": {
      "url": "https://mcp.sanity.io",
      "headers": {
        "Authorization": "Bearer sk..."
      }
    }
  }
}

権限を絞ったトークンを使えば、Claudeに渡す操作範囲をSanity側の権限で先に制限できます。個人トークンを渡すと自分のロールと権限を引き継ぎ、変更履歴にも自分の名前で残ります。

ツールの種類と役割

公式ドキュメントに載っているツールは、役割で次のように分けられます。表は作業の入口として使ってください。

whoami は、アクセスやアカウントのトラブルで最初に呼ぶ想定のツールです。名前・メール・プロバイダー・MCPの認証方式を返すため、どのアカウントで動いているかを確認できます。

スキーマを配備する流れ

スキーマの配備は、deploy_schema がクラウドへ型を直接配備します。Studioのコードを書き、ビルドし、デプロイするという通常の手順を通らず、会話のなかで型定義を反映できる点が特徴です。

公式ドキュメントでは、get_schema が配備済みのスキーマを取得します。ワークスペース名を省くと、有効なスキーマが1つならそれを、複数あるときは既定のワークスペースを返します。複数のスキーマの出どころがあるとき(MCPが管理するもの、Studioから配備されたもの、旧式の system.schema)は、優先順位はMCP管理、Studio配備、旧式の順です。迷ったら list_workspace_schemas で一覧を出し、返ってきた schemaId を get_schema に渡して特定のスキーマを読みます。

管理型のStudioが必要な場合は deploy_studio を使います。前提は、同じ (projectId, dataset, workspaceName) にMCP管理のスキーマが既にあることです。なければ先に deploy_schema を呼びます。あとで deploy_schema を再実行したら、配備済みのStudioに最新のスキーマを反映するため deploy_studio も再度実行します。

依頼文の例は次の形です。

Sanityのプロジェクトのスキーマを取得して、articleドキュメントに
「著者」参照フィールドを追加する案を出して。
確認したら deploy_schema で反映して、その後 deploy_studio もやり直して。

スキーマの配備は、配備先のプロジェクト全体に影響する操作です。案を出させてから反映を指示する二段階にしておくと、意図しない型の変更を防げます。

ドラフトとリリースを扱うときの順序

Sanityではドキュメントの状態が3種類あります。公開済み、ドラフト(drafts. 接頭辞)、リリースのバージョン(versions.{releaseId}. 接頭辞)です。Claudeの操作は、この区別を守る順序で組み立てると事故が減ります。

ドラフトを作る・更新する

create_documents は、内容を直接渡してドラフトを作ります。releaseId を指定したときだけバージョンとして作られます。patch_documents はドキュメントIDをキーにした形式でパッチを渡し、1回の呼び出しで最大25件まで扱えます。書き込みはドラフトかリリースのバージョンに保存され、公開済みのコンテンツを直接書き換えることはありません。

Markdownから作る場合は、コネクタページに create_documents_from_markdown があり、Markdownの文章からドキュメントを作るためのツールです。ただし前述のとおり、公式ドキュメントの一覧には同名のツールがありません。Markdownの取り込み用ツールが見えないときは、create_documents で構造化した内容を渡す形に切り替えます。

リリースに載せる

リリースの流れには順序の決まりがあります。ドキュメントを内容変更つきでリリースに追加するなら、先に create_version を呼び、次に返ってきたバージョンIDに同じ releaseId で patch_documents をかけます。公開済みIDやドラフトIDに先にパッチを当てると、リリースとは無関係なドラフトが生まれます。

create_release はリリースの器を作るツールです。releaseType と intendedPublishAt はメタデータとして記録されるだけで、スケジュールは設定されません。リリースの予約、公開、アーカイブ、削除はこのMCPでは扱えず、Sanity StudioかHTTP Actions APIで行います。

公開する・破棄する

• publish_documents: ドラフトを公開する。create_documents や query_documents が返した正確なIDを渡す
• unpublish_documents: 公開済みをドラフトへ戻す
• discard_drafts: ドラフトを削除する。公開済みは残る
• version_discard: リリースからバージョンを外して破棄する

discard_drafts は、公開済みが残るため見た目より安全な操作ですが、ドラフトの中身は戻せません。まだ公開していない下書きを破棄する前に、get_document で内容を確認させる運用が向いています。

Claude Codeで公開系ツールを止める設定

Claude側の具体策として、書き込み系ツールの確認を挟む権限設定を置きます。Claude Codeの権限ルールでは、MCPツールを mcp__<サーバー名>__<ツール名> の形式で指定でき、サーバー名だけ、または * によるワイルドカードで、サーバー単位にも指定できます。前述のコマンドで登録した名前が Sanity なので、ルールもその名前を使います。

次の設定は、読み取り系だけを許可し、公開・スキーマ配備・破棄は毎回確認する例です。プロジェクトの .claude/settings.json に置きます。

{
  "permissions": {
    "allow": [
      "mcp__Sanity__query_documents",
      "mcp__Sanity__get_document",
      "mcp__Sanity__get_schema",
      "mcp__Sanity__list_workspace_schemas"
    ],
    "ask": [
      "mcp__Sanity__deploy_schema",
      "mcp__Sanity__deploy_studio",
      "mcp__Sanity__publish_documents",
      "mcp__Sanity__unpublish_documents",
      "mcp__Sanity__discard_drafts",
      "mcp__Sanity__version_discard"
    ]
  }
}

あわせて、CLAUDE.md に運用規約を短く書いておくと、依頼のたびに前提を言い直さずに済みます。例えば次のような断片です。

## Sanity 運用規約
- コンテンツの変更は必ずドラフトかリリースのバージョンで行う
- 公開(publish_documents)は、対象ドキュメントIDの一覧を提示して確認を得てから
- リリースに載せるときは create_version を先に呼び、その後に patch_documents を使う
- スキーマを変える前に get_schema で現状を取得し、差分案を出す

この2つの役割は分かれています。権限設定は確認を強制し、CLAUDE.md は手順の順序を覚えさせます。

実際の依頼例

公式ドキュメントに挙がっている依頼文は、次のとおりです。

• 「このプロジェクトをSanityへ移行するのを手伝って」
• 「Markが書いた記事をGROQで全部取得して」
• 「articleドキュメント型に多言語対応を追加して」
• 「既存コンテンツを新しいスキーマの形へ移行して」
• 「このデータセットのリリースを一覧して」

例えばコンテンツ監査なら、query_documents でGROQを実行させ、結果を表に整えさせる流れが基本です。GROQの書き方に自信がないときは、get_sanity_rules に groq を渡して規則を読ませる想定が、query_documents の説明に書かれています。結果は切り詰められないため、フィールドの射影やスライスで必要な分だけ取る指示を添えると、会話の文脈を無駄に使わずに済みます。

つまずきやすい点と制約

認証が切れる

CLI経由で入れた場合はトークンが失効したり取り消されたりしていることがあり、npx sanity@latest mcp configure を再実行してエディタを選び直すと新しいトークンで更新されます。手動設定でOAuthを使っている場合、セッションは通常7日で切れます。クライアントが再認証を促しますが、止まったときはVS CodeならCommand Paletteの Authentication: Remove Dynamic Authentication Providers、Cursorなら Cursor: Clear All MCP Tokens で状態をリセットします。

ツールが見えない・失敗する

query_documents などが見当たらない、または失敗するときは、対象のプロジェクトとデータセットに対するアカウントの権限を確認します。提供されるツールはサーバーの更新で変わるとも案内されています。

AIクレジットを使うツールがある

ほとんどのツールは通常のAPI呼び出しで、AIクレジットを消費しません。generate_image と transform_image は例外で、SanityのAI推論エンドポイントを呼ぶためクレジットを使います。使いたくなければ、MCPクライアント側でこの2つを無効化できます。

手元のファイルは渡せない

アセットの取り込みツールは、公開されたHTTPSのURLから取得する形式です。手元のローカルファイルなどURLで公開されていない素材は取り込めず、dataset_assets_upload はファイルを読み込まずにCLIでのアップロード手順を案内するだけです。

使い分けの目安

契約書やドキュメントを扱う別のコネクタの例はPandaDocの連携記事にあります。書き込み系を持つコネクタは権限を先に確認する、という考え方は共通です。

まとめ

Sanity公式のMCPサーバーは、閲覧だけでなくスキーマの配備、ドラフトの作成と破棄、リリース用バージョンの作成までClaudeに任せられます。一方で、リリースの予約・公開はStudioかHTTP Actions APIの担当で、ローカルファイルのアップロードもできません。

手を付ける順序は3つです。まず読み取り系だけで接続を確認し、次に ask ルールで公開・配備・破棄を止め、最後にドラフトとリリースの順序を CLAUDE.md に書きます。この順にすると、Claudeに広い操作を渡しても、公開済みのコンテンツを意図せず動かすリスクを抑えられます。