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-communityREADMEには「プラグインがコミュニティマーケットプレイスに公開されたあとは」という前提が付いています。マーケットプレイスの掲載ページにFeaturebaseの項目があることは確認できますが、/plugin install が通らない場合は、まずマーケットプレイスの追加が済んでいるかを /plugin の画面で確かめてください。
リポジトリを手元に置いて試すだけなら、クローンしたディレクトリでセッションを開始します。この方法はセッション限りの読み込みで、インストールは残りません。
claude --plugin-dir .導入後に /reload-plugins を実行するか、Claude Codeを起動し直すと、プラグインが読み込まれます。続いてセッション内で /mcp を開き、featurebase を選んで認証を進めます。READMEは「ブラウザの手順に従ってFeaturebaseワークスペースへのアクセスを許可する。OAuthを使うのでAPIキーは不要」としています。
導入から最初の問い合わせまで
- 1
マーケットプレイスを追加する
/plugin marketplace add anthropics/claude-plugins-communityを実行します。 - 2
プラグインを入れる
/plugin install featurebase@claude-communityを実行し、/reload-pluginsで読み込みます。 - 3
/mcpでOAuthを通す
featurebaseを選び、ブラウザでFeaturebaseにログインしてアクセスを許可します。 - 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に個別指定する順番が無理のない進め方です。