ClaudeとAgility CMSを連携する方法 — Stagingと権限で線を引く

Claude Agility CMS連携とは何か

Agility CMS連携は、ヘッドレスCMSのAgility CMSが運営するリモートMCPサーバーをClaudeにつなぐ仕組みです。コンテンツモデルの設計、ページの組み立て、コンテンツの公開、メディアの管理を、管理画面を開かずに自然文で頼めます。

接続先は https://mcp.agilitycms.com/api/mcp、トランスポートはStreamable HTTP、認証はOAuth 2.0です。ドキュメントではGenerally Availableのv2.0.0と表記されています。

Claudeのコネクタディレクトリには「Anthropic verified」の表示付きで掲載されています。カテゴリは開発者ツール、生産性、営業・マーケティングの3つで、追加時期は2026年6月、サインインは必須です。

押さえておきたい点が2つあります。1つ目は、このコネクタが読み取り専用ではないことです。モデルの作成、ページの保存、公開、削除まで一通りのツールが揃っています。2つ目は、操作の範囲がAgilityの自分のアカウント権限で決まることです。AIだけが特別な権限を持つ構造にはなっていません。

同じヘッドレスCMS系のコネクタでは、Claude Contentful連携やClaude Sanity連携があります。コネクタ全般の仕組みはClaudeコネクタの解説にまとめています。

接続前に確認する条件

接続そのものに必要なのは、Agility CMSのアカウントと、コネクタに対応したAIクライアントです。ドキュメントはAPIキーやパスワードをコピーする手順を設けておらず、初回接続時にブラウザが開いてAgilityへOAuthでサインインします。

実際の操作範囲は、サインインしたユーザーのロールで決まります。ガバナンス向けのドキュメントには次の対応が書かれています。

見えるインスタンスも、普段のアカウントで入れるものに限られます。get_available_instances を呼ぶと、その一覧が返ります。

最初の試用には、本番ではないインスタンスか、新しく作ったコンテナを使うのが無難です。移行ガイドも、失敗した最初の一回を捨てやすくするために非本番のインスタンスを勧めています。

Claude TeamやEnterpriseのワークスペースでは、管理者がコネクタを有効にします。ただし有効にしても誰かが接続されるわけではなく、メンバーが各自でAgilityにサインインします。共有の認証情報はありません。

Claudeに接続する手順

ClaudeのデスクトップとWebから追加する

ディレクトリに載っているので、URLの入力は要りません。

ディレクトリに項目がまだ届いていない場合は、「Customize」の「Connectors」から「Add」で、カスタムコネクタとして追加できます。名前は Agility CMS、MCPサーバーのURLは https://mcp.agilitycms.com/api/mcp です。

Claude Codeから追加する

Claude Codeでは、HTTPトランスポートで登録します。ドキュメントの例はサーバー名に Agility-CMS を使っていますが、後で権限ルールに書く名前になるので、ここでは短い agility にします。

claude mcp add --transport http agility https://mcp.agilitycms.com/api/mcp

登録したらセッション内で /mcp を開き、サーバーを選んで認証します。ブラウザでAgilityのログインが済めば、ツールが使える状態になります。

誰として動いているかを最初に確かめる

接続できたら、本格的な作業の前に次の依頼を投げます。

Which Agility user am I connected as, and how many instances can I reach?

get_current_user は読み取り専用の「whoami」で、トークンの持ち主のユーザーID、メールアドレス、ジョブロール、アクセスできるインスタンス数などを返し、認証情報は返しません。ガバナンス向けのドキュメントも、一括変更や削除の前にこれを走らせる習慣を勧めています。個人のアカウントと自動化用のアカウントを使い分けている人ほど、取り違えを防げます。

32個のツールをどう読むか

ツールは5つの分類に分かれます。ドキュメントの表を、書き込みの有無で読み直すと次のとおりです。

読み取り系は get_ で始まるものと list_media です。それ以外は、何らかの形でインスタンスの状態に触れます。manage_content_workflow と manage_page_workflow は承認、却下、承認依頼を扱うツールです。

ツール数の数え方が2つある

ドキュメントは「32個」と書いています。一方、Claudeのコネクタ掲載ページは「27 tools」です。ドキュメントによると、v2.0で20個から27個に増え、その後にコンテンツとページ用の公開・非公開ツールと save_page_model の5個が加わりました。掲載ページの数字は、その追加前の時点に合っているように見えます。

実際に何が使えるかは、自分のクライアントで接続した後に /mcp などのツール一覧で確かめるのが確実です。権限ルールにツール名を書くときも、一覧に出ている名前を使ってください。

保存はStagingまで — 公開は別の操作

ここがこのコネクタで最も誤解されやすい点です。save_content_items は、インスタンスの既定のワークフロー状態に保存します。通常はStagingです。保存時に state を渡しても反映されず、ツールの応答でそのことが示されます。

ページも同じです。save_page はStagingに保存し、ライブにするには publish_page を別に呼びます。公開済みの項目を変更して保存すると、ライブ版はそのままで、Stagingに新しい版ができます。

承認ワークフローを有効にしている一覧やページでは、AIが加えた変更も人の手による変更と同じ状態を通ります。誰が変更したかは、サインインしているユーザーとして版履歴に残ります。

公開と削除の確認は、どこまで当てにできるか

破壊的な操作の確認は3層で説明されています。

elicitationに対応するクライアントとして、ドキュメントはClaude Codeを挙げています。対応していないクライアントでは第2層が働かず、応答に humanConfirmed: false が記録されます。

掲載ページとドキュメントで、公開の扱いが食い違う

ここに1点、読み合わせると食い違う箇所があります。Claudeの掲載ページには「Publish and unpublish ask for explicit confirmation」とあります。ところがドキュメントでは、publish_content と publish_page は破壊的と注釈されておらず、確認の対象外です。確認が付くのは unpublish_* と delete_* だけです。

ガバナンス向けのドキュメントも、公開の確認を強制するのはサーバーではなく、クライアントの設定と承認ワークフローの役割だと説明しています。「公開の前には必ず確認が出る」と思い込まず、公開を止めたい場面は次の方法で自分で固めてください。

• 承認ワークフローを、止めたいコンテンツ一覧とページで有効にする
• 公開させたくない人のロールから、Publish権限を外す
• Claude Codeなら、次の節の権限ルールで publish_* を ask に入れる

ガバナンス向けのドキュメントは、管理者が完全に制御できるのは第3層のロールだけだと整理しています。ユーザーが「常に許可」を選べば第1層は消えるためです。

Claude Codeの権限ルールで線を引く

Claude Codeでは、MCPツールを mcp__<サーバー名>__<ツール名> の形で指定できます。許可ルールのワイルドカードは、mcp__<サーバー名>__ という固定の接頭辞の後ろに限って使えます。

上の登録コマンドで agility と名付けた場合、.claude/settings.json の例は次のとおりです。

{
  "permissions": {
    "allow": [
      "mcp__agility__get_*",
      "mcp__agility__list_media"
    ],
    "ask": [
      "mcp__agility__publish_content",
      "mcp__agility__publish_page",
      "mcp__agility__unpublish_content",
      "mcp__agility__unpublish_page",
      "mcp__agility__save_content_model",
      "mcp__agility__save_component_model",
      "mcp__agility__save_page_model",
      "mcp__agility__save_container"
    ],
    "deny": [
      "mcp__agility__delete_content_item",
      "mcp__agility__delete_page",
      "mcp__agility__delete_media"
    ]
  }
}

読み取り系は確認なしで通し、公開とモデルの変更は毎回確認し、削除は会話に出さない構成です。deny に入れたツールは、Claudeのコンテキストから外れます。削除を使う作業の日だけ、deny から ask に移す運用もできます。

名前が合わないとルールは一致しません。ディレクトリ経由のコネクタをClaude Codeが取り込む場合、サーバー名の部分が変わることがあります。/mcp やツール一覧に出ている名前を確かめてから書いてください。

設定ファイルでは表せない運用ルールは、CLAUDE.mdに添えます。

# Agility CMS連携の運用
- 作業の最初に get_current_user を実行し、接続中のユーザーとインスタンス名を報告する
- save_content_items のあとは、項目のIDと編集用URLを一覧にして返す
- 公開は私が項目を確認してから頼む。勝手に publish_* を呼ばない
- モデルの作成では、PascalCaseの参照名を先に表で提案し、承認を待つ

依頼の例と、エージェントに任せる量の線引き

ドキュメントが挙げる使い方は、モデル設計、ページ構成、一括更新、監査、多言語、移行、公開、後始末の8つです。実際の依頼文に直すと次のようになります。

件数が増えたらスクリプトに切り替える

移行ガイドには、エージェントに任せる量の目安が書かれています。数十件はエージェント経由、数百件以上はManagement SDKのスクリプトです。MCPの呼び出しは1回ごとに会話を通り、ツールが扱える件数にも上限があるためです。

上限があるので、1ページだけ読んで「全件確認した」と報告されると、残りを見落とします。移行ガイドは、take と skip でページを送り、短いページが返るまで読む手順を勧めています。

移行の流れは、公式のガイドでは次の順です。

1. 移行元の在庫を取る。依頼では「Agilityには何も書かない」と明記する
2. モデルを提案させる。先に get_content_models と get_containers で既存と重複しないか調べさせる
3. 承認したモデルとコンテナを作る
4. 10〜20件のサンプルをStagingに取り込み、Agilityのエディタで目視する
5. 量が多ければSDKのスクリプトに移す

サンプルの確認はチャットの文面でなく、save_content_items が返す編集用URLからエディタを開いて行います。モデルの直しは、5,000件が入った後より前のほうがはるかに安く済みます。

つまずきやすい点

もう2つあります。

• リンクされたコンテンツのフィールドは3つ組になる。選択式のリンクフィールドには、選んだ値を保持するテキストフィールドが2つ付きます。例では Category、Category_TextField、Category_ValueField です。Claudeが提案したモデルでこの2つが欠けていないか、承認前に見てください。
• 「選択式のリンク」で参照名の大文字小文字が合わないと、ドロップダウンが空に見える。エディタは参照名を大文字小文字を区別して照合します。MCPの save_content_items は、get_containers が返す正規の表記に自動で直して保存するので、MCP経由なら起きにくい不具合です。SDKのスクリプトで書くときは自分で合わせます。

認証を巡っては、Microsoft 365 Copilot経由で使う場合に、Copilot Studioの認証を「End user」にしないと作成者の権限を全員が使うことになる、という注意が別に書かれています。Claudeから使う場合の話ではありませんが、同じAgilityのインスタンスに複数のAIクライアントをつなぐ管理者は、見ておくとよい箇所です。

組織で広げるときの段階の踏み方

導入の順番は、ガバナンス向けのドキュメントの勧めに沿うと、読み取り専用から始める形になります。

最初は、Readerロールのユーザーだけに試してもらいます。要約や監査はできて、書き込みはAPI側で拒否されるため、設定の誤りがあっても被害が出ません。次にパイロットのグループと、使ってよいAIクライアントの一覧を決めます。elicitationに対応するクライアントなら、削除の確認がサーバーのフォームで出ます。VS Code拡張でelicitationが自動で辞退される不具合は、Claude CodeのMCP elicitationの記事で扱っています。

そのうえで、コンテンツの種類ごとに自律の度合いを決めます。ドキュメントは「Assist」「Approve」「Autonomous」の3段階を示しています。

• Assist: AIはStagingに保存するまで。公開は人が確認してから行う。追加の設定は不要で、既定の状態です。
• Approve: AIが承認を依頼し、承認者が通したうえで公開する。対象の一覧とページで承認を有効にします。
• Autonomous: AIが検査して公開まで行う。自動化専用のユーザー、検査、ログ、元に戻す手順を整えたときの形です。

自動公開を試す場合も、まずはSEO用の説明文や代替テキストのように、失敗しても影響が小さい種類から始めます。自動化用のユーザーには最小権限のロールを割り当て、公開イベントはWebhookでログに流します。元に戻すときは unpublish_content や unpublish_page を使い、以前の版は版履歴から復元します。

まとめ

Agility CMS連携の中心は、保存がStagingで止まり、権限がAgility側で決まるという2点です。AIが書いたものは、公開の操作を別に通さなければライブに出ません。

迷いやすいのは確認の層で、公開にはサーバー側の確認が付かず、削除と非公開には付きます。公開を止めたい項目には、承認ワークフロー、ロール、ask ルールのいずれかを重ねてください。最初の接続では get_current_user で身元を確かめ、サンプル数件から始めると、モデルの直しが安く済みます。