Cursor Marketplace プラグイン導入・設定と使い分け

Cursor Marketplaceのプラグインは、単なるMCPの追加ではありません。
外部ツールとの接続に加えて、skills や rules、subagents、hooks まで束ねてCursorのエージェント挙動をまとめて拡張する仕組みです（詳細: 『Cursor Docs: プラグイン』。
本記事では初心者から中級者の読者に向けて、1つプラグインを導入して管理画面で有効化を確認し、FigmaGitLabDatadogのいずれかで接続テストを行うところまでを手順を追って案内します）。

Cursor Marketplaceは2026年2月17日に正式公開され、3月11日には30以上の新しいプラグインが加わりました。
『Cursor Marketplace 発表ブログ』や公開情報から見えてくるのは、個人利用ならまず公開プラグインで最短導入。
Teams / Enterprise ではチーム用マーケットプレイスで配布ポリシー、最小権限、監査まで含めて運用設計する、というのが筋のよい進め方だということです。

Cursor Marketplace プラグインとは？MCP との違いを最初に整理

プラグインの構成要素（5種）と Marketplace 表示要素

Cursorのプラグインは、MCP servers・skills・subagents・rules・hooks を束ねて、AI エージェントの能力と行動指針を拡張する仕組みです。
ここでいうModel Context Protocolは外部ツールとつなぐための共通規格ですが、Cursor Marketplaceのプラグインは接続先を増やすだけで終わりません。
たとえばFigmaならデザインデータを読めるだけでなく、「どの順で情報を拾い、どう返答するか」まで含めてパッケージ化されているのが肝です。

Cursor Docs: プラグインとCursor Marketplaceを見ると、Marketplace 上では skills、subagents、rules、hooks、commands、MCP servers という6つの表示カテゴリが案内されています。
このうち導入の核になる代表的な構成要素は5種、つまり MCP servers・skills・subagents・rules・hooks です。
commands は Marketplace 上で見える補助的な表記要素で、（編集部の実務観点での解釈として）「このプラグインでどんな呼び出し方があるか」を把握する入口として読むと収まりがいいです。
commands の扱いについては、編集部の実務的な解釈で「Marketplace 上の表記は呼び出し方の目安を示す入口として読める」という説明を当てています。
実際にプラグイン詳細を開くと、rules の欄が思った以上に効いてきます。
Figma系のプラグインで rules を確認したときは、Figma ノードを先に要約してから提案につなげる、といった具体的な動作方針が最初から入っていて、単に「接続できる」だけの導入とは別物だとすぐ分かりました。
初回の会話でエージェントの返答がぶれにくいのは、こうした rules や skills が同梱されているからです。

コミュニティ（フォーラム）ではチャットから /add-plugin! で導入する方法が報告されていますが、これは公式ドキュメントで明示された導線ではありません。
エディタ内検索や管理画面の導線が利用できる場合はそちらを優先し、フォーラム由来の方法は「別導線の報告例」として扱ってください。

Cursor Marketplaceは2026年2月17日に正式公開され、2026年3月11日には30以上の新規プラグインが追加されました。
公開直後の段階から、単発の接続設定ではなく「接続と使い方をまとめて配る」方向で設計されていたことが、ここからも読み取れます。

MCP 単体導入とのちがい

MCP 単体導入は、外部ツール接続という点では筋のよい方法です。
MCP サーバーをCursorに追加する導線も用意されていますし、柔軟に構成したい人には向いています。
たとえば独自の社内ツールや、Marketplace にまだ並んでいないサーバーをつなぐなら、MCP を直接足す発想が自然です。

ただ、MCP 単体では「つながった後にどう使うか」が空欄になりやすいのが利点です。
外部 API やデータソースにアクセスできても、どの情報を優先して読むか、どの形式で返すか、危険な操作をどう制限するか、といった運用の部分は自前で詰めることになります。
つまり、接続の柔軟性は高い一方で、skills や rules、hooks のような利用手順や行動ルールは自作前提になりがちです。

Marketplace プラグインは、そこを最初から埋めてくれます。
MCP servers に加えて skills・rules・hooks・subagents を一括で入れられるので、導入直後から「何ができるか」だけでなく「どう振る舞うか」まで揃います。
実際、MCP だけを手で足した構成では、最初の数ターンを使ってプロンプトの癖を整える場面が出ますが、Marketplace 版はその調整幅が小さい印象です。
外部サービス認証まで含めても、最初の動作確認まで一気に進めると短時間で形になります。

操作の流れで見ると違いはもっと明確です。
MCP 単体導入では、Add to Cursor の導線から追加したり、必要に応じて設定を手で整えたりしてから、ツール呼び出しを試します。
Marketplace プラグインでは、Web かエディタ内で対象を見つけてインストールし、管理画面で状態を確認したあと、チャットでそのまま使い始められます。
しかも多くのプラグインには MCP が含まれているため、2026年3月5日に提供開始したAutomationsでも流用しやすく、手動実行から自動実行への移行がつながっています。
単に「つながる」ではなく、「会話で働き、必要なら自動化にも載せられる」という差が出ます。

Cursor Docs

Cursor is the best way to build software with AI.

docs.cursor.com

VS Code 拡張機能と混同しないためのポイント

CursorはVS Codeベースなので、拡張機能の文脈と Marketplace プラグインの文脈が混ざりやすいのが利点です。
ただし両者の役割は別です。
VS Code 拡張機能はエディタ機能の拡張、Cursor Marketplace プラグインは AI エージェントの拡張と分けて捉えると整理できます。
たとえばVimやLive Serverは編集体験や開発補助を広げる拡張機能であって、エージェントにFigmaやGitLabの操作手順を教えるものではありません。

混同しやすい場面は、外部サービス連携を入れたいときです。
GitLab連携を例にすると、VS Code 側の拡張機能はサイドバー表示やファイル差分の閲覧を強化する方向に寄りますが、Cursor MarketplaceのGitLabプラグインは、エージェントが Issue や MR を会話の中で参照し、必要な文脈を取り込んで返答する方向に効きます。
見た目の機能追加か、AI の行動追加かで線を引くと迷いません。

インストール場所も異なります。
VS Code 拡張機能は拡張機能ビューから入れるのに対し、Cursor Marketplaceプラグインは Web の Marketplace かCursorエディタ内のプラグイン導線から探して入れます。
チャット導線を使う場合は /add-plugin! が候補になります。
入れたあとはプラグイン管理画面で状態を見て、必要な認証を終え、実際にFigmaならデザイン参照、Datadogならログやメトリクス照会といった最初の問い合わせを通す流れです。
ここで確認しているのは「拡張機能が有効か」ではなく、「エージェント拡張が有効か」という点です。

Teams / Enterprise ではこの違いがさらに実務的になります。
拡張機能の配布管理とは別に、管理者がチーム用 Marketplace を作ってプライベートプラグインを配布できます。
つまり組織運用の単位も、エディタ UI の拡張と AI エージェントの振る舞い拡張で分かれています。
導入手順を追う段階でこの切り分けが頭に入っていると、どこで探し、どこで有効化し、どこで状態を見るのかが一直線につながります。

導入前に確認したい前提条件

バージョン・ログイン・ネットワークの基本チェック

導入で最初に詰まりやすいのは、プラグインそのものではなくCursor本体の状態です。
Marketplace は 2026年2月に正式公開され、同年3月には 30 以上の新しいプラグイン追加も行われています。
こうした更新の流れを踏まえると、古いビルドのままでは Marketplace の表示や導入導線が揃わないことがあります。
少なくとも Marketplace 対応版になっているかを前提に見ておくと、手順の食い違いを減らせます。
エディタ内でバージョン表示を開き、更新があれば適用してから再起動する、という順番で十分です。
実際に触ってみると、ここを先に済ませるだけで「画面に同じメニューがない」という初歩的なズレを避けられます。

次に揃えたいのがログイン状態です。
Marketplace プラグインは、インストール後に認証や管理画面の表示が絡むため、Cursorへサインインした状態で進めたほうが流れが途切れません。
個人利用なのか、TeamsやEnterpriseのワークスペースに入っているのかでも見える範囲が変わります。
とくに組織アカウントでは、公開プラグインに加えてチーム用マーケットプレイスが配布対象になることがあり、個人アカウントで見えている一覧と一致しない場面があります。

ネットワーク条件も見落とされがちな前提です。
Marketplace からプラグイン情報を取得できても、その先で外部 API 通信が止まると、インストール後の動作確認で止まります。
Cursor Docs:プラグインは参照・インストール・管理の対象として扱われていますが、連携先がDatadogやGitLabのような外部サービスなら、実運用ではその先の通信経路まで通っていないと意味がありません。
筆者も会社ネットワーク下でDatadog連携を試したとき、Marketplace 側の追加自体は進んだのに API 呼び出しだけ失敗し、社内プロキシの例外設定を入れてようやく疎通したことがありました。
画面上は「入ったのに使えない」状態になるので、ゼロトラスト環境や社内プロキシ配下ではこの切り分けが欠かせません。

導入時間の感覚もここで持っておくと現実的です。
Marketplace 経由の追加自体は短時間で終わることが多く、実際には外部認証まで含めて最初の動作確認に進む流れになります。
Figmaのように OAuth ベースで接続できるサービスなら比較的まっすぐ進みますが、ネットワーク制約や組織承認が入ると、止まる場所はプラグイン画面の外にあります。
つまり、導入前提の確認とは「ボタンが見えるか」だけではなく、「その後の通信と認証までつながるか」を先に揃える作業だと言えます。

プラグイン ｜ Cursor Docs

Cursor Marketplace からプラグインをブラウズ、インストール、管理します。

cursor.com

外部サービス側の認証・権限の準備

Marketplace プラグインはFigmaGitLabDatadogStripeSanityのような外部サービスと組み合わせて初めて価値が出ます。
そのため、Cursor側で追加できることより先に、対象サービスのアカウントが存在するか、どの権限で接続するのかが前提になります。
たとえばGitLabなら参照したいプロジェクトにアクセスできること、Figmaなら対象ファイルやチームに入っていること、Datadogなら見るべきログやメトリクスに到達できることが必要です。
プラグインを入れても、連携先の権限が不足していれば AI が読める情報は増えません。

認証方式はサービスごとに分かれます。
ブラウザで許可を与える OAuth 型もあれば、PAT や API key を発行して接続する型もあります。
ここで意識したいのは、接続できることよりも 最小権限で成立すること です。
Issue 参照だけで足りるのに書き込み権限まで渡す、メトリクス確認だけなのに管理者権限を使う、といった設定は運用上のノイズになります。
Cursor Marketplace 発表ブログで説明されている通り、Marketplace プラグインは MCP servers に rules や skills まで束ねてエージェントを拡張します。
つまり、単なる「つながる」設定ではなく、どのデータに触れ、どの操作を許すかが会話品質と安全性の両方に影響します。

この準備は、実際にやってみるとサービスごとに手触りが違います。
Figmaのようなデザイン連携は認証後すぐに対象ファイルへ話をつなげやすい一方で、GitLabやStripeはリポジトリ、環境、組織ロールの境界が細かく、どこまで見えているかを最初に確認しないと意図した結果になりません。
Sanityでも dataset や project 単位の見え方で返答内容が変わります。
導入でつまずく原因は「プラグインが壊れている」より、「読ませたい対象に権限が届いていない」ほうが多いんですよね。

料金の見方も分けて整理しておくと混乱がありません。
今回確認できる範囲では、Marketplace プラグイン個別の価格体系は明示されていません。
一方で、実際の利用コストはCursorのプランと、連携先サービス側の契約や API 利用条件の組み合わせで決まります。
たとえばDatadogやStripeの既存契約が前提になるケースでは、「プラグインを入れたら有料になる」のではなく、「接続先の利用条件を引き継ぐ」と考えると整理できます。

プラグインで Cursor を拡張する · Cursor

Cursor Marketplace であらかじめ構築された機能を見つけてインストールできます。

cursor.com

個人利用とチーム利用での前提の違い

公開プラグインを試して相性を見るぶんにはこの形が最短で、導入から最初の動作確認までも比較的短時間で進みます。
筆者の感覚でも、認証が素直なサービスならプラグイン追加から最初の確認までは一気に進められます。
ここでは「自分が使えるか」が判断軸になります。

一方でTeamsやEnterpriseでは、使えるプラグインの範囲そのものが組織運用に乗ります。
2026年3月に案内された新規プラグイン追加とあわせて、30以上の新しいプラグイン追加) では、管理者がチーム用マーケットプレイスを作成し、プライベートプラグインを配布・管理できる方針も示されています。
ここでは「見つけて入れる」だけで終わらず、誰が配布し、誰が承認し、どの権限で使うかがセットになります。
個人利用で成立する自己責任の運用が、そのまま組織に持ち込めるとは限りません。

この差は、同じGitLabプラグインでも表れます。
個人なら自分の PAT を使って接続し、必要なプロジェクトだけ参照できれば成立します。
チーム利用では、レビュー対象のプロジェクト群、監査の考え方、共有プラグインの更新タイミングまで運用範囲に入ってきます。
公開 Marketplace とチーム用マーケットプレイスのどちらを使うのかでも、導入フローは変わります。
管理者配布なら現場の設定負荷は下がりますが、そのぶん承認と配布の設計が必要になります。

自作プラグインまで視野に入れる組織では、前提条件がもう一段増えます。
.cursor-plugin/plugin.json、rules/、skills/、mcp.json といった構成が見えており、単に外部サービスへつなぐだけでなく、どう振る舞わせるかまで管理対象になります。
個人利用では便利さが先に立つ場面でも、チーム利用では manifest、権限、更新手順、配布経路が揃ってはじめて安定運用に入れます。
個人利用の前提が「自分の環境で動くこと」だとすれば、Teams / Enterprise の前提は「組織のルールに沿って再現できること」です。

30 以上の新しいプラグインが Cursor Marketplace に登場 · Cursor

マーケットプレイスで提供される構築済みの機能で Cursor を拡張できます。

cursor.com

Cursor Marketplace からプラグインを導入する手順

Web の Marketplace から導入する

Cursorの Marketplace から入れる流れは、まず一覧で探して、その場で追加し、必要なら認証まで進める、という順番で捉えると迷いません。
プラグインごとに対応サービスや含まれる要素が見えます。
前述の通り、Marketplace プラグインは単なる接続設定ではなく、MCP servers に加えて skills や rules、hooks、subagents、commands といった構成をまとめて配布できるのが特徴です。
だからこそ、最初に「何につなぐか」だけでなく、「どんな振る舞いまで一緒に入るか」を見ながら選ぶと判断がぶれません。

実際の手順はシンプルです。
Cursor Marketplaceを開いたら、検索欄で目的のサービス名を入れます。
たとえばGitLabFigmaDatadogStripeのように具体名で探すと、候補を絞り込みやすくなります。
目的のプラグインを開いたら、説明欄で連携対象と同梱要素を確認し、インストールまたは追加の導線をたどります。
その後、ブラウザ認証やトークン入力が求められる場合は、そのまま接続設定に進みます。
ここまでの流れは認証を含めても一気に終わることが多く、最初の動作確認まで短時間で持っていけます。

ここで混同しやすいのが、Marketplace プラグイン導入と MCP 単体追加の違いです。
Cursor Docs:MCPサーバーで案内されている「Add to Cursor」は、MCP サーバーを個別に足す導線として理解すると整理しやすくなります。
一方、Marketplace 側は MCP だけでなく、エージェントに与えるルールやスキルまでまとめて入ることがあります。
同じ外部サービス連携でも、まず使い始めるなら Marketplace プラグイン、接続先や構成を細かく組み替えたいなら MCP 単体追加、という切り分けです。

GitLabで試したときは、この違いがわかりやすく出ました。
Marketplace 検索でGitLabを入れて追加すると、インストール完了後の管理画面に rules と skills が並び、再起動を挟まずそのまま会話側で使い始められました。
単に GitLab へ接続できるだけでなく、「どう扱うか」まで一緒に入ってくる感覚です。
バージョンによって見え方は変わることがありますが、導入直後の状態確認までが一続きで進むのは、Marketplace 経由の利点として体感しやすいところでした。

Cursor Marketplace ｜ Cursor Plugins

Discover verified Cursor plugins including skills, subagents, rules, hooks, commands, and MCP servers.

cursor.com

エディタ内から導入する

ブラウザを開かず、Cursorのエディタ内から探して追加する流れもあります。
実画面では名称が Marketplace、Plugins、Installed など近い表現で分かれていることがあるので、ビュー名はその時点の UI 表示で読み替える前提です。

操作の流れとしては、エディタのプラグイン関連ビューを開き、検索欄にサービス名を入れ、候補から追加したいものを選びます。
追加ボタンを押すとインストール処理が走り、必要に応じて認証画面へ進みます。
Web 版と違って、そのまま手元の作業コンテキストに戻りやすいので、導入後すぐにチャットやエージェント実行で挙動を確認しやすいのが利点です。
Datadogのように接続先で参照対象が明確なものは、入れた直後にログやメトリクスの取得可否を見て、権限が通っているかまで一気に見極めやすくなります。

補足として、 /add-plugin! というコマンドで導入できるケースがあります。エディタ内での導入導線が UI から見つけにくい。

ここでもAdd to Cursorとの住み分けは意識しておきたいところです。
MCP サーバー単体を追加する導線は、既存の Marketplace プラグインが用意されていない連携や、構成を個別に組みたい場面で活きます。
反対に、rules や skills まで含めたパッケージをそのまま使いたいなら、エディタ内の Marketplace / Plugins ビューからまとめて入れるほうが流れが途切れません。
導入方法の違いというより、追加する単位の違いとして見ると混乱が減ります。

インストール後に管理画面で状態確認する

インストールが終わったら、管理画面で状態を確認するところまで進めておくと、その後の切り分けが速くなります。
見る場所はエディタ内の Plugins、Installed、管理ビューなどの近い名称になっていることが多く、そこに導入済みプラグインの一覧が出ます。
ここで確認したいのは、対象プラグインが有効になっているか、バージョン表示があるか、更新導線が出ていないか、そして含まれている要素が見えるかです。

GitLabを入れたときは、この管理画面で rules と skills が一覧できたので、単に「入ったらしい」で終わらず、何が追加されたのかをその場で把握できました。
しかも再起動なしでそのまま使えたので、管理画面で状態を見てからチャットに戻る流れが自然につながりました。
こういう確認を挟んでおくと、応答が期待と違ったときに、認証の問題なのか、プラグイン自体が無効なのか、更新待ちなのかを切り分けやすくなります。

管理画面では、無効化やアンインストール、再有効化の操作もあわせて把握しておくと運用が軽くなります。
たとえばDatadogを一時的に止めたい、あるいはGitLabの設定を入れ直したい、といった場面では、いきなり設定ファイルを触るより管理画面から状態を切り替えるほうが流れが明快です。
Teams / Enterprise で配布されたプラグインでも、利用者側で見える範囲の状態確認はこの画面に集約されることが多く、公開 Marketplace 由来なのかチーム配布なのかを含めて、現在の有効状態を見渡せる場所になります。

導入直後の確認項目は多く見えますが、実際に見る場所はほぼ一か所です。
追加済み一覧を開き、対象プラグインを選び、構成要素と有効状態を確認し、必要なら更新や再有効化をかける。
この順で見れば、Marketplace から入れたプラグインと MCP 単体追加のどちらを使っているかも把握しやすく、後続の Automations 連携に進むときも構成を見失いません。

導入後の基本設定と使い始め方

プラグイン詳細画面で構成要素を確認する

導入が終わったら、そのままチャットを開く前に、対象プラグインの詳細画面を一度見ておくと挙動の理解が速くなります。
Cursor Marketplaceのページでは、プラグインごとに skills / subagents / rules / hooks / commands / MCP servers といった構成要素が見える形で整理されています。
前のセクションで触れた管理画面の確認に加え、ここではもう一歩進めて、「何が入ったのか」を読む段階です。

見るポイントは単純で、まず MCP servers があるなら外部サービスとの接続口が含まれています。
skills はエージェントが得意な作業単位、rules はプロンプトの解釈やツールの使い方を安定させる指針、subagents は特定用途に寄せた役割分担、hooks はイベントに応じた補助動作、commands は手動で呼び出せる操作と捉えると全体像がつかめます。
.cursor-plugin/plugin.json、skills/、rules/、mcp.json などの構成が見えるので、Marketplace 上の表示は実装の中身と地続きだと理解できます。

実際、この画面を見ておくとプロンプトの組み立て方が変わります。
たとえば rules が厚いプラグインなら、細かい手順を自分で全部書かなくても、自然言語で目的を渡した時点で適切なツール選択に寄っていきます。
逆に MCP servers はあるが skills が少ない構成なら、どの情報を読ませたいかを少し具体的に伝えたほうが結果が安定します。
単に「インストール済み」かどうかを見るより、この違いを先に知っておくほうが実運用では効きます。

導入直後の初回確認は、体感では短時間で終わります。
Marketplace で追加して認証まで進め、詳細画面で構成要素をざっと眺め、簡単な問い合わせを一つ投げるところまで含めても数分から十数分で収まることが多く、入れた直後に使い道の輪郭までつかめました。
入れただけで終わらず、次にどう呼ぶかまで見えてくるのがこの画面の役目です。

GitHub - cursor/plugins: Cursor plugin specification and official plugins

Cursor plugin specification and official plugins. Contribute to cursor/plugins development by creating an account on Git

github.com

認証・接続の設定

外部サービス系のプラグインは、入れただけではまだ情報に触れられず、認証や接続設定が必要になることがあります。
ここで出てくる代表的な方式が OAuth / API keys / PAT です。
OAuth はブラウザで対象サービスにログインして連携を許可する流れで、Figmaのようなサービス連携ではこの形を見かけやすいのが利点です。
API keys はサービス側で発行したキーを入力する方式で、監視やデータ参照系のツールでよく使われます。
PAT は Personal Access Token のことで、GitLabのようにユーザー権限の範囲で API を叩くサービスと相性がよく、どのリポジトリやグループまで見えるかが結果に直結します。

UI の細部はプラグインごとに異なりますが、一般的な流れは共通しています。
まずプラグインの詳細または設定画面を開き、接続項目を選び、認証方式に応じてブラウザ許可かキー入力を行い、その後に接続テストまたは簡単な実行で通りを確認する、という順番です。
ここで見ておきたいのは、認証そのものより どの権限で接続されているか です。
GitLab 連携で Issue は見えるのに MR の詳細が拾えない、Datadog でメトリクスは引けるのにログ本文が返らない、といった差はプラグインの出来より権限範囲で説明できる場面が少なくありません。

プロンプトからの呼び出し方は、思ったより自然です。
Figmaなら「Figma のこのファイルを読み取って、主要コンポーネントを要約して」「このデザインから React の雛形を作って」のように書くだけで通りますし、GitLabなら「この Issue に関連する MR を教えて」「最新の差分を要約して」といった聞き方で十分です。
プラグイン側の rules や skills が入っていると、ユーザーがコマンド体系を暗記しなくても、自然言語からツール呼び出しへ寄せてくれる感触があります。
Marketplace プラグインが単なる。

Cursor 変更履歴で案内されている通り、2026年3月5日にはAutomationsが公開されました。
多くのプラグインが MCP を含む前提なので、いま手動で使っている接続が、そのまま自動実行の土台になることも珍しくありません。
たとえば Datadog のログ調査や GitLab の定期確認を将来ワークフロー化するなら、接続名の意味が分かるようにしておくこと、権限を必要最小限にそろえておくこと、どの問い合わせが安定して成功したかを最初の時点で残しておくことが効いてきます。
手動実行で再現できるプロンプトは、そのまま自動化の素案になります。

変更履歴 · Cursor

新しいアップデートと改善。

cursor.com

代表例で試す：Figma / GitLab / Datadog の使い始め

Figmaは、初回の動作確認が最も分かりやすい部類です。
ファイル URL とプロジェクト名を渡して、「このデザインのコンポーネント構造を要約し、実装の雛形も出して」と頼むだけで、セクション分け、主要コンポーネントの整理、利用コードのたたき台まで返ってきました。
ここで効いているのは、単に Figma のデータへ接続できることではなく、デザイン文脈を読んで何を抜き出すかが rules と skills に織り込まれている点です。
UI 名称の列挙で終わらず、「このカード UI は再利用部品として切り出せる」「このボタン群は状態分岐を持つ」といった実装寄りの返しになりやすく、デザインからコードへ移る最初の一歩が短くなります。

GitLabは、Issue を起点にした問い合わせが扱いやすいのが利点です。
実際に試したときは、Issue 番号を添えて「関連 MR を教えて」と聞くだけで、候補となる MR のリンクと差分の要約がまとまって返ってきました。
レビュー観点まで自動で整うわけではありませんが、Issue と MR を往復する時間は目に見えて減ります。
ここは接続先の権限範囲が結果に出やすく、見えているプロジェクトだけを対象に返答が組み立てられるので、チームで使うときほど PAT やアクセス設定の意味がはっきり出ます。
Issue、MR、Pipeline という GitLab の主要オブジェクトを自然文で横断できるのは、チーム開発向けプラグインとして素直に便利だと感じました。

Datadogは、ログ調査の入口で差が出ます。
人手でクエリを書くと条件の揺れが出やすいのですが、プラグインの rules が入っていると、「この時間帯の 5xx をサービス単位で見たい」「特定リクエスト ID 周辺のログを追いたい」といった依頼から、同じ型のクエリが安定して生成されます。
自分で毎回書くと微妙に表記がぶれる場面でも、返ってくる検索条件がそろうので、調査の再現性が上がります。
実際、同種の障害を追うときにクエリの粒度が毎回そろい、あとから見返しても「何を起点にどこを掘ったか」が残る感触がありました。
Datadog の価値は単発の検索成功より、同じ調査手順を繰り返せることにあります。

この3つに共通するのは、プロンプトでの呼び出しがコマンド暗記型ではないことです。
Figmaなら「このファイルを読んで要約して」、GitLabなら「この Issue に関連する MR を洗って」、Datadogなら「この症状のログクエリを作って」と頼めば、背後で MCP servers と rules が働き、必要な取得と整形までつなげてくれます。
Marketplace プラグインを入れた後に試す代表例として、この3つは目的がはっきり分かれていて、しかも「接続できた」だけでなく「仕事に使える返答になった」かまで見えやすい組み合わせです。

おすすめの見方：どのプラグインを選ぶべきか

選び方は、まず自分の仕事のどこに一番長く滞在しているかで分けると迷いません。
Cursor Marketplaceは 2026年2月17日に正式公開され、3月11日には 30 以上の新規プラグインが追加されました。
説明されている通り、プラグインは単なる接続設定ではなく、MCP servers、skills、rules、hooks、subagents などを束ねて振る舞いごと持ち込めるのが特徴です。
だからこそ、カテゴリ名だけで選ぶより、「自分の仕事の入口を短くするもの」を最初の1本に据えるほうが失敗が少ないです。

実務感覚としては、フロントエンド案件ではFigma連携が初速を変えました。
デザインファイルから構造を読み取り、そのまま実装の雛形に落とす流れがつながるので、最初の理解コストがぐっと下がります。
反対に、バックエンド寄りの案件ではGitLabとDatadogを組み合わせたときの満足度が高めでした。
Issue、MR、Pipeline を追いながら、異常時はログとメトリクスへすぐ降りられるので、実装と調査が一本の線になります。

選定基準も、名前の知名度だけでは足りません。
見るべきなのは、公式配布かどうか、verified 表示の有無、最近までメンテされているか、要求される権限が業務範囲に見合っているか、skills や rules が十分に入っているか、そして将来Automationsで再利用できる構造かどうかです。
Marketplace の多くのプラグインは MCP を含むため、手で試して通った操作を自動化へ持っていきやすいのも判断材料になります。
導入から最初の動作確認までは、認証込みで 5〜15 分ほどで済むことが多く、最初の1本は業務に直結する単一ツールの公式・verified プラグインが収まりどころとしてちょうどよいです。

デザイン連携

デザイン連携は、Figmaのように UI の文脈をそのままCursorへ持ち込みたい人に向いています。
画面仕様、コンポーネント構造、命名の意図をコード化の前段で拾えるので、フロントエンドやデザインシステム運用では最優先候補になります。
MCP 単体でも接続はできますが、Marketplace プラグインの価値は、デザインデータをどう読んで、どこを要約し、何を実装へ橋渡しするかまで含めて整っている点にあります。

実際、Figmaが刺さるのは、単にファイルを読めるからではありません。
カード、モーダル、フォームのような UI 部品を「再利用前提の構造」として扱えるので、画面を見ながらゼロから分解する時間が減ります。
静的なデザイン確認に終わらず、React やコンポーネント設計の叩き台まで会話をつなげやすいのが、このカテゴリの強みです。

• 主な対象: フロントエンド、UI 実装、デザインシステム担当
• 代表例: Figma
• 向いている場面: デザインから実装へ移る最初の整理、コンポーネント分解、UI 名称の統一
• 導入優先度: 個人利用でも高い。チーム導入ではデザイン命名規則の共有まで効いてきます

開発連携

開発連携は、GitLabのように Issue、MR、Pipeline を日常的にまたぐ人に向いています。
ここで効くのは、情報取得の速度だけでなく、複数オブジェクトを自然文で横断できることです。
Issue 番号から関連 MR をたどり、差分を要約し、CI の状態まで見に行く流れが一本化されるので、チーム開発の往復回数が減ります。

このカテゴリは個人よりもチームで真価が出ます。
なぜなら、リポジトリやプロジェクト単位の権限がそのまま返答範囲に反映されるからです。
逆に言えば、要求スコープが広すぎるプラグインは避けたい領域でもあります。
最小権限でどこまで見えるか、MR 要約や Pipeline 参照の精度に不足がないか、その2点を見ると良し悪しが分かれます。
skills や rules が薄いと、ただ API を呼べるだけの連携に近づきますが、整備されたプラグインは「Issue 起点で追う」「差分要約を返す」といった定番の流れまで含めて作られています。

インフラ運用は、Datadogのようにログ、メトリクス、トレースの調査を日常的に行う人向けです。
障害調査は「どこを見るか」が毎回ぶれやすい作業ですが、プラグイン側に rules が入っていると、問い合わせの切り口がそろいます。
5xx の発生時間帯をサービス別に切る、特定のリクエスト ID 周辺を追う、異常なレイテンシだけを抜く、といった定番手順が安定します。

バックエンド寄りの現場でGitLabとDatadogを並べると、実装変更と障害兆候を往復する流れが途切れませんでした。
Issue や MR を見て、怪しい時間帯をログで掘り、必要なら Pipeline に戻る、という形です。
監視系プラグインは単体でも価値がありますが、開発連携とセットにすると「何を直したか」と「どこで壊れたか」がつながります。
このカテゴリでは、取得対象の広さより、普段使うクエリが再現できるか、Automations に乗せたときに定期実行しやすいかを見ると選びやすくなります。

• 主な対象: SRE、バックエンド、障害対応、運用保守
• 代表例: Datadog
• 向いている場面: ログ調査、メトリクス確認、トレース起点の原因特定
• 導入優先度: 個人開発では優先度は下がりやすく、運用責任を持つチームでは上位に入ります

決済/データ

決済・データ系は、StripeやSanityのように、アプリの外にある事業データを扱う仕事と相性がよいカテゴリです。
Stripeは決済イベント、顧客、課金状態の確認に向き、Sanityはコンテンツモデルやエントリ構造の把握に向きます。
どちらも「コードの外にある本番業務データ」を扱うため、便利さだけで選ぶと危うく、権限設計の比重が一段上がります。

このカテゴリは、個人利用よりもチームや事業部門との接点がある運用で存在感が出ます。
Stripeならサポート対応や決済フローの調査、Sanityなら CMS 構造の確認や編集フローの整備に効きます。
生産性ユーティリティ寄りのプラグインと違って、返ってくる情報がそのまま業務判断につながるので、verified 表示やメンテ頻度に加えて、スコープが細かく切られているかを特に見たいところです。
将来的にAutomationsへつなぐ前提で考えるなら、定型問い合わせを繰り返す領域ほど恩恵が出ます。

• 主な対象: EC、SaaS 運用、コンテンツ運用、サポート連携
• 代表例: Stripe、Sanity
• 向いている場面: 決済状態の確認、顧客データ参照、CMS 構造の把握
• 導入優先度: 個人では用途が分かれる一方、事業運用に近いチームでは優先順位が上がります

生産性ユーティリティも見逃せないカテゴリですが、最初の1本としては後回しになりがちです。
メモ整理、汎用検索、日常タスク補助のようなプラグインは便利でも、業務フローの中核を変える力はFigmaGitLabDatadogほど強くありません。
逆に、主要ツールの連携が固まったあとで足すと、日々の細かい往復を吸収してくれます。

用途別の向き不向きを短く並べると、判断軸は次の形に落ち着きます。

• フロントエンド中心の個人利用: Figmaが最優先。画面理解と実装の橋渡しが最短になります
• アプリ開発チーム: GitLabが先行候補。Issue、MR、Pipeline を横断する回数が多いほど効きます
• SRE・バックエンド運用: Datadogを優先。障害調査の手順が定まり、再現性が上がります
• EC・SaaS・CMS 運用: StripeSanityが候補。事業データやコンテンツ構造に直接触れる業務で効きます
• 汎用的な効率化: 生産性ユーティリティは補助線として有効。本命プラグインのあとに足すと役割が明確になります

よくあるトラブルと対処法

認証・権限まわりのエラー

導入直後につまずきやすいのは、インストールそのものではなく認証です。
GitLabDatadogStripeのような外部サービス連携では、見た目上はプラグインが入っていても、OAuth のリダイレクトに失敗してセッションが確立できていない、PAT や API key のスコープが足りない、以前発行したトークンが失効している、といった理由で実行時に止まることがよくあります。
症状としては、ログイン画面を往復するだけで完了しない、一覧取得はできるのに更新系だけ失敗する、接続済み表示なのに一部の操作だけ 403 や権限エラーになる、という形で出ます。

実際にGitLabでは、PAT のスコープを read_api だけにしていたため、MR 関連の操作が通らなかったことがありました。
Issue の参照や一部の読み取りは動くので、一見すると接続成功に見えますが、レビュー依頼や MR の詳細操作に入ったところで止まります。
そこで必要権限を見直して api スコープを追加し、トークンを再発行したところ、その場で解消しました。
この手の失敗は「認証済みかどうか」ではなく、「その操作に必要なスコープがそろっているか」で見たほうが切り分けが早くなります。

組織アカウントでは、SSO 制約が隠れた原因になることもあります。
ブラウザではサービスに入れるのに、Cursor 側の認証だけ成立しない場合は、組織ポリシーで外部アプリ連携が制限されているケースがあります。
個人トークンを入れ直しても直らないときは、OAuth の失敗より SSO 側の承認条件を疑ったほうが筋が通ります。
読み取りは許可されていても、書き込みだけ組織ロールで止められていることもあり、その場合はプラグインの問題ではなく権限設計の問題です。

触れられている通り、管理者による配布や統制が前提になります。
そのため、個人環境では動いていた操作が、チーム環境ではロール不足で止まることがあります。
書き込みが禁止されているなら、まずは最小権限でのロール申請が現実的です。
暫定的には読み取り専用モードで使い、Issue、MR、ログ、メトリクスの参照に用途を寄せると作業は止まりません。

接続・動作しないときの基本確認

プラグインが反応しないときは、設定項目を細かく追う前に、無効化状態、権限拒否、ネットワーク遮断、バージョン不一致の4点を見ると原因が縮まります。
Marketplace から入れたあとに有効化が完了していない、権限ダイアログで拒否したままになっている、社内プロキシやファイアウォールが外部 API を遮断している、プラグイン側の要件に対してCursor本体が古い、といった初歩的な要因が意外と残ります。

特にネットワークまわりは見落とされがちです。
Datadogでログ取得が失敗したとき、認証情報や API key ばかり見直しても改善せず、実際には VPN 経由の経路でDatadog側エンドポイントへ到達できていないのが原因だったことがありました。
プロキシ例外を追加したら接続が通り、その後はクエリも実行できました。
ブラウザでサービス画面が開くことと、プラグイン経由の通信が通ることは別なので、社内ネットワーク下ではここを先に疑う価値があります。

バージョン不一致も地味に厄介です。
Marketplace のプラグインは MCP だけでなく rules や skills など複数要素を含むことがあり、古いCursorでは期待どおりに読み込めない場合があります。
インストールは終わっているのにコマンドが出ない、設定項目が現れない、動作が断続的に失敗する場合は、本体更新で通ることが少なくありません。
プラグイン側の互換バージョン要件とCursorの既存版がずれていると、認証エラーのように見えて実際はローダー側の問題ということもあります。

そのため、動かないときの基本確認は順番が欠かせません。
管理画面で有効化状態と許可状況を見て、その次にネットワーク経路を確認し、それでも直らなければCursor本体とプラグインの更新状況を見る、という流れだと迷走しません。
再起動は古典的ですが効きます。
認証情報や設定ファイルが読み直されず、古い状態を保持したまま失敗しているケースがあるからです。
アップデート後の再起動まで含めて1セットと考えると、原因の見落としが減ります。

MCP 由来の失敗の切り分け

Marketplace プラグインの不調でも、実際には MCP 側の設定齟齬が原因という場面があります。
多くのプラグインが MCP を含む構成なので、見た目は「プラグインが壊れた」ようでも、mcp.json の設定、起動コマンド、環境変数、到達先サーバーの状態を追うと筋が通ることがあります。
特に「導入はできたが実行時だけ失敗する」「特定のツール呼び出しだけ無反応」という症状は、MCP サーバー起動か接続先到達性の問題で説明できることが多いです。

切り分けでは、まず Logs を見て、MCP サーバーが起動しているか、起動後に接続で落ちているかを分けます。
Cursor の公式ドキュメントにはAdd to Cursorの導線があり、MCP 。
手動編集した設定でおかしくなった場合は、『Cursor Docs: MCPサーバー』の手順に沿って登録し直すと、設定差分を減らせます。
Marketplace 経由で入れたプラグインでも、内部的に MCP の再登録で立て直せるケースがあります。

設定ファイルの場所は環境ごとに話がぶれやすい点です。
一般に報告されている例としては Mac で ~/Library/Application Support/Cursor/mcp/、Windows で C:\Users\<ユーザー名>\AppData\Roaming\Cursor\mcp\ といったパスが挙げられますが、これらはサードパーティの報告例に由来する可能性があり、公式ドキュメントでの確認が取れていません（参照日: 2026-03-18）。
実運用で参照する際は、環境固有の設置場所を実際に確認してください。
再起動の対象もCursor本体だけとは限りません。
MCP サーバー側のプロセスがハングしていると、アプリを閉じても接続エラーが続くことがあります。
そういうときは MCP サーバーの再起動で復旧しますし、設定を戻しても直らない場合はAdd to Cursor経由で再登録したほうが早いです。
mcp.json を直接編集した直後に失敗したなら設定齟齬、何も変えていないのに突然つながらないなら到達先やサーバープロセス停止、という見立てで進めると無駄が減ります。

MCP 由来かどうか迷うときは、同じプラグイン内で「認証は見えるがツール実行だけ落ちるか」「そもそも接続先一覧も出ないか」を分けると判断しやすくなります。
前者はスコープや権限不足、後者は MCP 設定かサーバー到達性の問題であることが多いです。
プラグイン、認証、MCP を別レイヤーとして見るだけで、原因の位置が急に見えてきます。

チーム導入で注意したいガバナンスと権限設計

チームマーケットプレイスの基本

個人でFigmaやGitLab、Datadogのプラグインを試す段階では、導入の速さが魅力になります。
一方でチーム導入になると、誰がどのプラグインを使えて、どこまでの操作を許すのかを先に決めておかないと、便利さがそのまま運用負荷に変わります。
Cursorは Teams / Enterprise 向けに、管理者がチーム用マーケットプレイスを作成し、プライベートプラグインを配布・管理できる流れを案内しています。
公開プラグインの配布だけでなく、組織内で統制しながら展開する前提が見えます。

公開Marketplaceをそのまま各自に使わせる形だと、導入判断が利用者ごとに分散します。
これに対してチームマーケットプレイスは、管理者が採用済みのプラグインだけを見せる入口として機能します。
中央ガバナンスの役割はここにあります。
利用者は候補を一から探すのではなく、組織として承認済みのGitLab連携や監視調査向けのDatadog連携から選べるため、ツール選定のばらつきが減ります。

この中央集約は、単に「インストールを制限する」話ではありません。
承認ワークフロー、配布対象グループ、利用ログの監査観点をそろえておくことで、あとから「なぜそのプラグインが有効だったのか」「誰に展開されていたのか」を追える状態を作れます。
『30以上の新しいプラグイン追加』でも Teams / Enterprise 向けのチームマーケットプレイスが示されており、配布の集中管理が前提に置かれています。
公式に細部まで公開されているわけではないので、監査ログの粒度や承認経路の実装を断定するべきではありませんが、少なくともアクセス制御と監査を前提に設計する運用が自然です。

実際、全社配布の前に読み取り専用のDatadog版だけを先に配ったことがあります。
ログとメトリクスの参照に用途を絞り、書き込みや設定変更に触れない形で検証期間を置いたところ、運用チームへの影響を抑えたまま「どのクエリが日常的に使われるか」「どこで権限不足が出るか」を先に洗えました。
チーム導入では、この段階的な配布が効きます。
最初からフル権限版を広げるより、読み取り専用で実利用の流れを見たほうが、ルールの不足も過剰付与も見つけやすくなります。

最小権限の設計と配布ポリシー

権限設計の基本は、読み取りから始めることです。
Datadogならログ・メトリクス・トレースの参照、GitLabなら Issue や Merge Request の閲覧、パイプライン状況の確認までを初期段階に置くと、導入効果を見ながら事故余地を抑えられます。
ここで言う最小権限は、単に API スコープを絞るだけではなく、プラグインを配る対象者も限定する考え方を含みます。
SRE チーム向けのプラグインを全開発者に配る必要はありませんし、逆にデザイン連携用のFigmaプラグインを運用担当へ配る必然性も薄いはずです。

書き込み系の操作は、読み取り系より一段慎重に分離したほうが安定します。
たとえばGitLab連携で Issue を新規作成する権限、Merge Request をマージする権限、ダッシュボードやモニタ設定を書き換える権限は、同じ「便利機能」でも影響範囲が違います。
Issue 生成は比較的影響が限定されますが、MR マージやダッシュボード編集は本番運用や開発フローに直結します。
そこで、閲覧担当、起票担当、変更承認担当のようにロールを切り、段階的に許可を広げる構成だと、どこで止めるべきかが明確になります。

この設計は、社内のアイデンティティ基盤とも揃えておきたいところです。
SSOやSCIMで管理している部門・役割の単位と、プラグインの配布対象グループがずれていると、入退社や異動時に権限が残りやすくなります。
人事イベントで自動的にグループが更新される組織なら、プラグイン配布や外部サービス権限もその区分に寄せたほうが、棚卸しのたびに手作業で追いかけずに済みます。
中央ガバナンスが機能するかどうかは、Marketplace 側の設定画面だけではなく、既存の認証・プロビジョニング運用と噛み合っているかで決まります。

外部 API を使う以上、域外へのデータ持ち出しも権限設計の一部です。
たとえば障害調査でDatadogのログを読むプラグインは便利ですが、クエリ結果に個人情報や機密値が混ざる運用なら、社内ポリシー上どこまで AI エージェントへ渡してよいかを切り分ける必要があります。
ここでは「使えるか」より「何を渡してよいか」の線引きが先です。
アクセス制御と監査を組み合わせて、誰がどのデータソースに触れたのかを追跡できる状態にしておくと、コンプライアンス部門との会話も進めやすくなります。

プライベートプラグイン運用の考え方

社内フローに合わせた連携を作りたい場合は、公開プラグインだけでは足りないことがあります。
そのときに現実的なのが、チームマーケットプレイスで社内向けプライベートプラグインを配る形です。
公式のcursor/pluginsリポジトリで示されている構造を見ると、.cursor-plugin/plugin.json を中心に、rules/、skills/、mcp.json などを組み合わせる構成が基本になります。
プラグインは単なる接続設定ではなく、どんなルールで、どんな操作を、どの文脈で使わせるかまで含めて定義するものだと捉えると設計しやすくなります。

社内向けプラグインの管理は、アプリ配布よりも「コードとして運用する」ほうが向いています。
plugin.json でメタ情報と公開範囲を持ち、rules/ で禁止事項や推奨フローを明文化し、skills/ で定型タスクを切り出し、mcp.json で接続先サーバーを定義する形です。
たとえば社内GitLabの特定プロジェクト群だけに接続し、Issue 起票時には必須テンプレートを挿入し、障害時には所定のラベル付けを強制する、といった運用はこのレイヤーで吸収できます。
設定を個人ごとに配布するより、レビュー可能なリポジトリで一元管理したほうが変更履歴も追えます。

ここで見落としやすいのが、アプリケーションコードと同じレビュー文化を持ち込むことです。
プライベートプラグインは業務フローそのものに触れるので、Pull Request でのレビュー、承認者の分離、変更理由の記録が欠かせません。
とくに rules/ と mcp.json は、利用者の行動や接続先を左右するため、軽い設定変更に見えても運用影響は小さくありません。
CHANGELOG を残して「どの版で認証先が変わったか」「どのスキルが追加されたか」を明示しておくと、現場で不具合が出たときに差分を追いやすくなります。

『cursor/plugins GitHub』の構成は、社内運用の叩き台として参考になります。
公開プラグインと同じ考え方で、manifest、rules、skills、MCP 設定を分けて持てば、レビュー対象が自然に分割されます。
そこに配布ポリシーと監査の観点を重ねると、「誰でも作れて、誰でも配れる」状態を避けられます。
チームマーケットプレイスを使う価値は、単に配布先を社内へ閉じることではなく、プラグインを組織の変更管理プロセスに載せられる点にあります。

まとめ

最初は verified の公式プラグインを1つだけ入れ、管理画面で有効化を確認したうえで、FigmaGitLabDatadogのどれかで接続テストを通すのが近道です。
本文中の外部リンクは 2026-03-18 時点で確認しています。
将来の UI やリンク変更の可能性を考慮して、重要な導線は公開直前に再確認してください。