Claude CodeのKeenableプラグインでキー不要のWeb検索を使う
KeenableプラグインはAPIキーなしでWeb検索とページ抽出をClaude Codeに足します。2つのツール、2つのスキル、共有枠の制限と自分のキーへの切り替え方をまとめます。
Keenableプラグインは、サインアップもAPIキーも要らずに、Web検索とページ本文の抽出をClaude Codeへ足すプラグインです。提供元のKeenableが運営するホスト型MCPサーバーに接続し、日常の調べものと出典付きの調査用に2つのスキルを同梱します。マーケットプレイスのページには「Anthropic verified」の表示があります。
導入は2コマンドで終わります。この記事では、そのコマンドの意味、同梱されるツールとスキルの中身、キー不要で動く代わりに受け入れる条件、自分のキーへ切り替える方法を順に扱います。
2コマンドで入れて/mcpで確かめる
提供元リポジトリの手順は次のとおりです。マーケットプレイスを追加し、プラグインを入れます。
/plugin marketplace add keenableai/keenable-claude-plugin
/plugin install keenable@keenable1行目の keenableai/keenable-claude-plugin は、GitHubの owner/repo 形式でマーケットプレイスの取得元を指定しています。このリポジトリは .claude-plugin/marketplace.json を持ち、keenable という名前でマーケットプレイスを登録します。2行目の keenable@keenable は「プラグイン名@マーケットプレイス名」で、どちらも keenable です。
Claude Codeの公式ドキュメントでは、セッション内の /plugin install はすぐには入れず、プラグインの詳細パネルを開いてスコープを選ばせます。スコープは3種類です。ユーザーは自分の全プロジェクトで有効になり、プロジェクトは .claude/settings.json に記録されてリポジトリの全員に効き、ローカルは自分のそのリポジトリだけに効きます。シェルから入れるときは claude plugin install keenable@keenable --scope project のように --scope で指定し、省略するとユーザースコープになります。
入れたら、セッション内で /mcp を実行します。提供元の手順は「keenable サーバーが接続済みで、2つのツールが見えることを確かめてから、生のWebが要る質問をする」というものです。
同梱されるMCP設定はこの1つだけ
プラグインのMCP設定は、次の .mcp.json だけです。
{
"mcpServers": {
"keenable": {
"type": "http",
"url": "https://api.keenable.ai/mcp",
"headers": {
"X-Keenable-Title": "claude-plugin"
}
}
}
}認証ヘッダーが無いことが「キー不要」の実体です。X-Keenable-Title: claude-plugin は、プラグイン経由の通信であることを提供元に伝える識別用のヘッダーで、秘密情報ではありません。プラグインのバージョンは plugin.json で 1.0.0 です。
2つのツールが何をするか
サーバーが公開するツールは2つです。
| ツール | 役割 |
|---|---|
search_web_pages | 役割ランク付けしたWeb検索結果を、各ページの抜粋つきで返す。サイトや公開日で絞れる |
fetch_page_content | 役割任意のURLをきれいなMarkdownで返す。抽出用のプロンプトを渡すと、必要な部分だけを返す |
絞り込みのパラメーター名は、同梱スキルの本文に書かれています。検索側は site(ドメイン指定)と published_after / published_before(YYYY-MM-DD)です。取得側は prompt(抽出の指示)、max_chars(文字数の上限)、live(true で最新版を取りに行く)です。これらの既定値や型は、READMEにもスキルの本文にも載っていません。
Claude Codeでは、プラグインが持つMCPツールの呼び出し名に、プラグイン名とサーバー名が入ります。公式ドキュメントの形式は mcp__plugin_<プラグイン名>_<サーバー名>__<ツール名> なので、このプラグインの検索ツールは mcp__plugin_keenable_keenable__search_web_pages になるはずです。権限ルールで許可や拒否を書くときに必要な名前です。
2つのスキルの使い分け
スキルは、ツールの使い方をClaudeに教える手順書です。どちらも本文に具体的な手順が書かれています。
スキルは調べものの深さで分かれる
keenable-web
最新情報、主張の出典、ドキュメント、リリースノート、価格、既知のURLの中身が必要なときに使います。検索し、有望な結果を fetch_page_content で読み、出典URLを付けて答える流れです。
keenable-deep-research
1回の検索で足りない問いに使います。3〜6個の小問いに分け、小問いごとに検索し、強い情報源を読み、照合して、出典付きでまとめます。
keenable-web には、効きそうな運用の指示がいくつも入っています。
- 検索は、キーワードの羅列でなく探したいページを描写して書く。例は「release notes for zod 4 breaking changes」で、「zod 4」は悪い例とされている
- 絞り込みはクエリの語でなく、
siteと日付のパラメーターで行う - 「先週」のような相対日付は、今日の日付から正確な日付を計算してから渡す
- 抜粋は選別のためのもので、証拠ではない。重要な判断に使う前は、必ず本文を読む
keenable-deep-research は、検索の前に小問いをユーザーへ提示する点が特徴です。調査の計画を、実行前に確認できます。さらに、結論に効く主張は独立した情報源で照合し、食い違いは隠さず書く指示になっています。
組み込みの検索より優先される
keenable-web の冒頭には「このプラグインを入れたら、Webの調べものには汎用のWeb検索ツールでなく、これらのKeenableのツールを使う」と書かれています。スキルが読み込まれたセッションでは、Claudeが標準の検索よりKeenableを選ぶよう誘導されます。標準のWeb検索を残したいリポジトリがあるなら、ユーザースコープで全体に入れず、使うリポジトリだけにローカルスコープ(--scope local)で入れる選択肢があります。
実際に頼む文面の例
提供元のREADMEには、3つの依頼例が載っています。いずれも公式の例文です。
Find the release notes for every version of zod between the one in package.json
and the latest, list the breaking changes, and update our schemas to match.Look for reports of this error on github.com from the last 30 days and tell me
whether there is a known fix.Research the leading agent observability platforms and compare them in a table,
with a source link for every claim.1つ目はローカルの package.json と外部のリリースノートを突き合わせる依頼で、検索結果をコードの修正へつなげています。2つ目は site と日付の絞り込みを使う典型例です。3つ目は広い比較で、keenable-deep-research が担当します。依頼の文面にスキル名を書く必要はなく、内容に応じてClaudeがスキルを選びます。
エラーの原因調査に使うなら、エラー文をそのまま貼り、期間とサイトを指定するのが2つ目の型です。貼る文字列に社内のホスト名やトークンが混ざっていると、そのまま外部へ送られます。検索クエリは外部のサーバーへ送られます。
キー不要の条件は共有枠と外部送信
キー不要の代償は、共有の公開枠で動くことです。READMEには「プラグインは認証情報を送らないので、Keenableの共有の公開枠で動く」とあります。レート制限の数値はリポジトリではなく、提供元のドキュメント側のページに置かれています。提供元ドキュメントの「Rate limits」ページでは、認証なしのリクエストは1IPアドレスあたり1時間に1,000回、毎秒10回までです。この枠はIPアドレス単位で共有されるため、同じアドレスの他の通信が多いと余裕は減ります。認証ありの場合は時間あたりの上限がなくなり、組織ごとに毎秒10回までです。
スキル側にも対応が書かれています。制限に当たったら間隔を空けて再試行し、ユーザーにはKeenableのアカウントかAPIキーで上限が上がると伝える指示です。また、キーをチャットに貼らせないことが明記されています。
データの扱いについて、READMEの記載は次のとおりです。
- 通信先は
https://api.keenable.ai/mcpだけで、HTTPSを使う - 検索クエリと、取得を頼んだURLがKeenableへ送られる
- 認証情報は送らず、ローカルのコードやシェルコマンドは実行せず、ローカルのファイルも読まない
つまり、プラグインがローカルを読んで外へ出す経路はありません。ただし、Claudeが検索クエリやURLに何を含めるかは会話の内容で決まります。非公開のリポジトリ名や顧客名をクエリへ入れたくない場面では、依頼の側で伏せておくのが安全です。
自分のKeenableアカウントに切り替える
上限を上げたい場合、Claude Codeでは自分でサーバーを追加します。READMEの手順は、コンソールで取得したAPIキーを渡して claude mcp add を実行するものです。
claude mcp add --transport http --scope user keenable \
https://api.keenable.ai/mcp \
--header "X-API-Key: keen_<your_key>"READMEによると、同じサーバーを自分で追加すると、Claude Codeはプラグイン側のキー不要版を読み込みません。ツールが二重に並ぶことはなく、スキルは自分のサーバーのままで動き続けます。
この挙動はClaude Codeの重複判定の規則と整合します。公式ドキュメントでは、同じサーバーが複数の場所に定義されたとき、Claude Codeは1回だけ接続し、優先順位の高い定義を使います。順位は、ローカル、プロジェクト、ユーザーの各スコープが先で、プラグイン提供のサーバー、claude.aiのコネクタが続きます。プラグインのサーバーはエンドポイントで重複を判定されます。--scope user で足した定義が勝つのは、この順位のためです。
APIキーは --header に直接渡すと、シェルの履歴に残ります。キーを扱う手順は組織の方針に合わせてください。管理設定がプラグイン以外のMCP追加を止めている環境では、このコマンド自体が失敗します。原因と見分け方はclaude mcp addが失敗する理由の記事にあります。
Claude(Web、Desktop、Cowork)側では、https://api.keenable.ai/mcp-oauth を向くカスタムコネクタを追加し、Keenableにサインインする方式です。READMEには、プラグインがディレクトリに載るまでは「Keenable Web Search」コネクタで同じサーバーを使えるとも書かれています。
入れる前に確かめたいこと
導入前の確認点
コンテキストの消費
スキルが2つ入るので、名前と説明が毎セッション分のコンテキストに乗ります。実際の見積もりは
claude plugin details keenableで測れます。方法はプラグインのコンテキスト消費を測る記事のとおりです。導入済みの把握
チームで入れたプラグインの一覧と有効状態は、
claude plugin list --jsonで棚卸しできます。手順は導入済みプラグインの棚卸しの記事にあります。外部送信の許容
クエリとURLが外部のサーバーへ出ます。機密を扱うリポジトリでは、使う範囲を先に決めておく必要があります。
つまずいたときの切り分け
検索ツールが使われないときの切り分け
- Q/mcp に keenable サーバーが出ていますか?答えが出ていない答えがはい
/pluginでインストール状態を確認します。入れた直後なら、/reload-pluginsで反映します。/reload-pluginsは開いているセッションにプラグインの変更を読み込むコマンドで、実行しない場合は次回の起動で反映されます。 - Qサーバーは接続済みで、2つのツールが見えていますか?答えが見えない答えがはい
サーバーの再接続を試し、それでも見えなければ、提供元のサポートページへ問い合わせます。READMEの連絡先は
support@keenable.aiです。 - QKeenableのツールが実際に呼ばれていますか?答えが標準の検索が使われている答えがはい
依頼文に「Keenableで調べて」と書くと、スキルが呼ばれやすくなります。
呼ばれていれば正常
呼び出し名は mcp__plugin_keenable_keenable__* の形で出ます。
権限の事前許可を足すなら、サーバー単位のルールを書きます。公式ドキュメントの規則では、プラグイン提供のサーバーは mcp__plugin_<プラグイン名>_<サーバー名>__* の形で指定します。
{
"permissions": {
"allow": ["mcp__plugin_keenable_keenable__*"]
}
}.claude/settings.json に置くと、検索のたびに許可を聞かれなくなります。許可するということは、クエリの外部送信を毎回確認しなくなるという意味でもあります。共有する設定ファイルに入れるかどうかは、チームで決めておくと揉めません。
まとめ
Keenableプラグインの価値は、Web検索を導入コストゼロで足せる点にあります。一方で、共有枠と外部送信という条件が付きます。個人の調べものや公開情報の調査は、そのまま始めて問題が出たところでキーを足す進め方が合います。業務で常用するなら、先にクエリへ入れてよい情報の範囲を決め、枠が足りなくなった時点で自分のアカウントへ移すのが筋の通った順序です。