Claude Media
Claude CodeにFeaturebaseプラグインを入れて問い合わせとフィードバックを操作する

Claude CodeにFeaturebaseプラグインを入れて問い合わせとフィードバックを操作する

Featurebaseのプラグインは、スキルを持たずホスト型MCPサーバーへの接続だけを束ねた構成です。導入手順、OAuthの流れ、読み取りと書き込みの権限の分け方を示します。

Featurebaseのプラグインを入れると、Claude Codeが自社のFeaturebaseワークスペースに接続し、サポートの問い合わせ、チケット、顧客フィードバック、ヘルプセンター記事を自然文の指示で読み書きできます。APIキーは要りません。ブラウザでOAuth認証を一度通すだけです。

この記事では導入手順に加えて、プラグインの中身が何かを確かめます。リポジトリを開くと、スキルもスラッシュコマンドも見当たりません。あるのはMCPサーバーへの接続設定が1つだけです。この構成の違いは、権限の絞り方と手動でMCPを足す場合との差に直結します。

プラグインの中身はMCP接続の設定1つ

マーケットプレイスの掲載ページは、Featurebaseを「カスタマーサポート、フィードバック、CRM、チケット、ヘルプセンターの業務にClaudeをつなぐもの」と説明しています。提供元リポジトリのファイルは3つだけです。

ファイル役割
.claude-plugin/plugin.json役割名前 featurebase、バージョン 1.0.0、作者はFeaturebase
.mcp.json役割MCPサーバー featurebase の接続先
README.md役割導入手順と使い方の例

.mcp.json の中身は次のとおりです。

{
  "mcpServers": {
    "featurebase": {
      "type": "http",
      "url": "https://mcp.featurebase.app/"
    }
  }
}

接続先はFeaturebaseがホストするHTTP型のMCPサーバーです。手元で起動するプロセスも、npmパッケージの取得もありません。Zilliz CloudのプラグインのようにCLIとスキル群を同梱するタイプとは性格が違い、ツールの一覧と挙動はすべてサーバー側が決めます。プラグインはそこへの入口を配る役目に絞られています。

Featurebaseの開発者向けドキュメントによると、このMCPサーバーはFeaturebase APIと同じ範囲を型付きのツールとして出します。扱える対象はフィードバックのボード、ロードマップ、チェンジログ、ヘルプセンターの記事、会話、チケット、コンタクトと会社、レポートなどです。

導入手順とOAuth認証

READMEの手順は、Claudeのコミュニティ向けマーケットプレイスからの導入です。Claude Codeのセッション内で次の2行を実行します。

/plugin marketplace add anthropics/claude-plugins-community
/plugin install featurebase@claude-community

READMEには「プラグインがコミュニティマーケットプレイスに公開されたあとは」という前提が付いています。マーケットプレイスの掲載ページにFeaturebaseの項目があることは確認できますが、/plugin install が通らない場合は、まずマーケットプレイスの追加が済んでいるかを /plugin の画面で確かめてください。

リポジトリを手元に置いて試すだけなら、クローンしたディレクトリでセッションを開始します。この方法はセッション限りの読み込みで、インストールは残りません。

claude --plugin-dir .

導入後に /reload-plugins を実行するか、Claude Codeを起動し直すと、プラグインが読み込まれます。続いてセッション内で /mcp を開き、featurebase を選んで認証を進めます。READMEは「ブラウザの手順に従ってFeaturebaseワークスペースへのアクセスを許可する。OAuthを使うのでAPIキーは不要」としています。

手順

導入から最初の問い合わせまで

  1. 1

    マーケットプレイスを追加する

    /plugin marketplace add anthropics/claude-plugins-community を実行します。

  2. 2

    プラグインを入れる

    /plugin install featurebase@claude-community を実行し、/reload-plugins で読み込みます。

  3. 3

    /mcpでOAuthを通す

    featurebase を選び、ブラウザでFeaturebaseにログインしてアクセスを許可します。

  4. 4

    読み取りの質問から始める

    最初は「未解決の問い合わせを一覧して」のような読み取りだけの依頼で動作を確かめます。

認証前のサーバーに直接リクエストを送ると、Unauthorized: missing or invalid Authorization header. という内容のJSONエラー(HTTP 401)が返ります。/mcp の画面で未認証と表示されているときは、この状態です。失敗した接続を再試行する操作は/mcp reconnect allにまとめています。

読み取りと書き込みの権限を分ける

Featurebase側の仕様に、見落としやすい点があります。MCP経由で発行されるトークンには mcp:read と mcp:write の2つのスコープがあり、読み取りには前者、変更には後者が必要です。ツールは「あなたのアクセス権の範囲内」に限られるため、ワークスペースで権限の低いアカウントで認証すれば、Claudeにできることもそれだけ狭くなります。APIの仕様書(API spec)の公開や削除のような一部の機密性の高い操作は、MCP経由では使えずAPIキーが必要です。

つまり、Claude Code側で事故を防ぐ層は次の3つに分けて考えられます。

権限設計

事故を防ぐ3つの層

  • Featurebaseのアカウント権限

    認証に使うアカウントを、必要最小限のロールにします。

  • トークンのスコープ

    トークンは読み取りの mcp:read と変更の mcp:write に分かれます。付与されるスコープは認証画面で確認します。

  • Claude Codeの権限ルール

    ツール単位でask・denyを設定し、送信や更新の前に必ず確認を挟みます。

3つ目はClaude Code側で完結する設定です。プラグイン同梱のMCPサーバーのツール名は mcp__plugin_<プラグイン名>_<サーバー名>__<ツール名> の形になります。プラグイン名もサーバー名も featurebase なので、全ツールを指すパターンは次のとおりです。

{
  "permissions": {
    "ask": ["mcp__plugin_featurebase_featurebase__*"]
  }
}

この設定は .claude/settings.json に置くと、Featurebaseの全ツールの呼び出しで毎回確認が出ます。ここで注意したいのが評価順です。権限ルールはdeny、ask、allowの順に見られ、一致したaskルールは、同じ呼び出しに、より限定的なallowが一致していても確認を出します。つまりワイルドカードのaskを残したまま、読み取り系ツールだけを allow に足しても、読み取りは通りません。

読み取りを確認なしで通したいときは、ワイルドカードのaskを外します。ツール名を /mcp で確認し、読み取り専用のツールを allow に、書き込みを伴うツールを ask に、それぞれ個別に書きます。allow のワイルドカードは mcp__<サーバー>__ の固定部分より後ろにしか書けないため、mcp__* のような広い許可は無視される点に注意してください。ツールの一覧と名前はサーバー側の定義なので、この記事では個別のツール名を決め打ちしません。権限ルールの書き方全般は権限ルールをパラメータで書く方法も参考になります。

プラグイン経由ではなく手動で足した場合は、ツール名の形が変わります。

claude mcp add --transport http featurebase https://mcp.featurebase.app/

この場合のツール名は mcp__featurebase__* です。プラグイン用に書いた mcp__plugin_featurebase_featurebase__* のaskルールは手動追加のサーバーには効きません。同じワークスペースを両方の経路で登録すると、ルールの片方が素通りになります。どちらか一方に統一してください。

READMEの用途別に、依頼文を組み立てる

READMEが挙げる用途は5つです。それぞれ、読み取りで終わるか、書き込みを伴うかが違います。

用途依頼文の例(READMEの例に沿う)書き込み
問い合わせの要約依頼文の例(READMEの例に沿う)開いている問い合わせを要約し、緊急度の高いものを挙げる書き込みなし
フィードバックの傾向依頼文の例(READMEの例に沿う)ある機能への最近の声から、繰り返し出る論点を要約する書き込みなし
顧客の調査依頼文の例(READMEの例に沿う)会社を検索し、コンタクト、会話、関連フィードバックを並べる書き込みなし
返信の下書き依頼文の例(READMEの例に沿う)会話の文脈から返信文を起草する書き込み送信すれば発生
ヘルプセンターの見直し依頼文の例(READMEの例に沿う)古くなっていそうな記事を探し、改善案を出す書き込み編集すれば発生

READMEは返信について「Featurebaseに保存された文脈を使って更新を下書きし、送る」としています。つまり送信までが射程に入っています。顧客に届いたメッセージは取り消せません。依頼文に「下書きまでで止めて、送信は私が確認してから」と書くのが最も簡単な歯止めです。

もう一段、毎回書かなくて済むようにするなら、プロジェクトの CLAUDE.md に運用ルールを置きます。次は一例です。

## Featurebase 操作ルール
- 問い合わせへの返信は下書きのみ作る。送信は人が承認するまで実行しない
- ヘルプセンター記事は、編集前に現在の本文を引用して差分案を示す
- 顧客の個人情報(メールアドレス・氏名)は、要約や記事の下書きに転記しない

この断片はFeaturebaseの仕様ではなく、運用の提案です。ただしClaude Codeは CLAUDE.md をセッション開始時に読むので、毎回の依頼文に同じ注意を書き足す手間は減ります。拘束力はないので、前節のask設定と併用するのが前提です。

他のプラグインや手動追加との違い

Featurebaseの構成を、似た導入記事と並べます。

観点FeaturebaseプラグインCLI同梱型のプラグイン
実体FeaturebaseプラグインMCP接続の設定のみCLI同梱型のプラグインCLI、スキル、コマンド
認証FeaturebaseプラグインOAuth(ブラウザ)CLI同梱型のプラグインCLIごとのログインやキー
ツールの更新Featurebaseプラグインサーバー側で変わるCLI同梱型のプラグインプラグインの更新で変わる
権限ルールの対象Featurebaseプラグインmcp__plugin_… のツール名CLI同梱型のプラグインBashの実行コマンドなど

サポート業務の流れそのものを手順化したいなら、チケット対応の型を扱うカスタマーサポートプラグインの手順が補完になります。そちらは業務フロー側の話で、Featurebaseはデータの置き場に当たる側の接続です。

ツールの一覧がサーバー側で決まることには利点と注意点があります。Featurebaseが新しい機能を足せば、プラグインを更新しなくても使える範囲が広がります。一方で、昨日まで読み取りだけだった権限ルールの想定が、新しい書き込み系ツールの追加で崩れる可能性もあります。askをワイルドカードで掛けておけば、新しいツールも自動で確認対象に入ります。ただしこの利点は、ワイルドカードのaskを残している間に限られます。読み取りを通すために個別のallowへ切り替えると、あとから増えた書き込み系ツールは自動では確認対象に入らないので、プラグインを更新したあとにツール一覧を見直す手間が生じます。

導入前に確認しておくこと

  • Featurebaseのワークスペースと、そこにログインできるアカウントが必要です。ツールはそのアカウントのアクセス権の範囲に限られます
  • APIの仕様書の公開や削除のような機密性の高い操作は、MCP経由では使えずAPIキーが必要です
  • プラグインのバージョンは 1.0.0 です。READMEは導入手順のみで、制限事項やプラン条件の節は持ちません。料金プランによる利用可否はFeaturebaseの案内で確認してください
  • Claude Code全体の設定や権限の考え方はClaude Codeの全体像にまとめています

まとめ

Featurebaseのプラグインは機能の追加ではなく、接続の配布です。入れて認証すれば使えるぶん手軽ですが、読み取りしかしない用途でも、ツールが書き込みを持っている以上、確認を挟む設計が要ります。最初はワイルドカードのaskで全ツールを確認対象にし、実際に使うツールが見えてきたらワイルドカードを外して、読み取り系をallow、書き込み系をaskに個別指定する順番が無理のない進め方です。

この記事を共有:XはてブLinkedIn