# Claude Codeで最初に入れるべきMCP 2026年版：ワークフロー別の初手 > Claude Code の best MCP は、人気順にたくさん入れることではありません。まずは一番大きい external workflow gap を閉じる integration を一つ選び、official や trusted surface を先に使い、`.mcp.json` は shared workflow が固まってからにする方が実務的です。 - URL: https://blog.laozhang.ai/ja/posts/claude-code-best-mcp-servers - Published: 2026-04-08 - Updated: 2026-04-08 - Author: AI Free API Team (https://blog.laozhang.ai/ja/about) - Topic: Claude Code - Tags: Claude Code, MCP, Connectors, 開発ツール, Anthropic --- ひとつだけ default answer を出すなら、人気の Claude Code MCP を片っ端から入れるところから始めないことです。最初に足すべきなのは、いま一番大きい external workflow gap を閉じる integration です。2026 年 4 月 8 日時点では、それはたいてい **GitHub** です。repo、PR、issue が bottleneck なら GitHub、古い docs が何度も足を引っ張るなら **Context7 のような current-docs MCP**、browser QA や再現確認が本題なら **Playwright**、そして incident debugging が本当に日常の仕事なら **Sentry** のような observability connector を考えます。official または clearly trusted surface があるならまずそこから入り、workflow が本当に共有レベルになってから `.mcp.json` や plugin-bundled MCP に進む方がきれいです。 この答えは、多くの “Claude Code MCP おすすめ一覧” よりかなり狭いです。でも実際には、その方が役に立ちます。高くつく失敗は、別の server name を一つ見逃すことではありません。最初の integration が value を証明する前に、Claude Code を connector の山にしてしまうことです。 2026 年 4 月 8 日時点の Anthropic の current docs では、**official connectors**、**remote MCP servers**、**local または project-scoped MCP configs**、そして **plugin-bundled MCP** がすでに別々の surface として扱われています。Claude Code MCP docs でも、project-scoped servers は `.mcp.json` に置くこと、利用前に approval が入ること、third-party servers には trust と prompt-injection risk の注意が必要であることが明記されています。つまり、最初の判断は単なる tool choice ではなく、packaging と trust boundary の choice でもあります。 > エビデンス注記：この記事は Anthropic の current [Claude Code MCP docs](https://code.claude.com/docs/en/mcp)、[Connectors overview](https://claude.com/docs/connectors/overview)、[connector help-center guide](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) を 2026 年 4 月 8 日に確認した内容と、日本語圏で自然な `最初に何を入れるか` の reader language をもとに再構成しています。 ## 最初の判断を速くする route board ![Claude Code MCP のスタータールートボード](https://blog.laozhang.ai/posts/ja/claude-code-best-mcp-servers/img/surface-route.jpg) たくさんの server names を見比べる前に、今日壊れている workflow を先に特定します。 | いまの bottleneck | 最初に試す MCP | ベストな first surface | Stop rule | | --- | --- | --- | --- | | repo、issue、PR、review context | GitHub | official または trusted GitHub integration | 足りないのが repo 外の context だけなら GitHub で止まる | | framework や API docs の古さ | Context7 または current-docs MCP | trusted remote docs server | 一つの docs path が効いたら、docs tool を重ねない | | browser QA、UI flow、repro steps | Playwright | trusted automation server。まずは personal が多い | team で同じ flow を共有すると確信するまで project scope にしない | | incidents、traces、production debugging | Sentry などの observability connector | incident work が recurring job の時だけ使う | incident が主仕事でないなら入れない | このボードの目的は、四つの名前を永遠の正解にすることではありません。tool directories が省きがちな問いを先に答えさせることです。**最初に何を足すべきか。今は何を足さないべきか。** ## 最初に選ぶべきなのは server 名ではなく surface です このテーマで検索する人の多くは、MCP server の shopping list を探しています。実際に最初のミスが起きやすいのは、その一歩前です。Claude Code の integrations を全部同じ種類のものとして扱ってしまうことです。 そうではありません。Anthropic の current ecosystem では、recommendation を変えるのに十分な差を持つ surfaces がすでに並んでいます。**Official connector** は、Anthropic がその service を直接サポートしている時の最も clean な start です。friction が低く、余計な configuration ownership を背負いにくいからです。**Remote MCP server** は別物です。first-party integration がない service や data source を使う時には有効ですが、その server operator を trust する必要が出てきます。**Project-scoped `.mcp.json`** はさらに別の surface で、そこでは personal experiment ではなく repo が integration を持つことになります。**Plugin-bundled MCP** はもっと後ろの packaging answer で、setup 自体に distribution や lifecycle management が必要になった時に意味を持ちます。 だから giant top-20 list は弱い出発点になりやすいのです。real problem は discovery ではなく、missing workflow を安全に閉じる最小の surface を選ぶことだからです。 順番としては、こう考えると分かりやすいです。 1. その service に official connector または clearly vetted surface はあるか。 2. なければ、real な recurring gap を埋める remote MCP server はあるか。 3. それはまだ personal workflow か、それとも repo が持つべき shared workflow か。 4. Repo が持つなら、`.mcp.json` で十分か、それとも plugin-style packaging まで必要か。 この四つを先に答えると、server name の選択は一気に楽になります。飛ばしてしまうと、全部 equally plausible に見えてしまいます。 ## Day one の場所を本当に取るべき starter MCP ![Claude Code MCP の workflow 別スターターマトリクス](https://blog.laozhang.ai/posts/ja/claude-code-best-mcp-servers/img/workflow-starters.jpg) 最初に入れるべき path は popularity ではなく、何が一番仕事を止めているかで決まります。だから leaderboard より workflow-first guide の方が役に立ちます。 ### Repo-heavy workflow なら、最初の一つは GitHub が最有力です 毎日 issue、pull request、diff、review comment、repository metadata のために流れが切れているなら、GitHub は多くの開発者にとって最も強い first integration です。ローカル checkout だけでは埋まらない external context を補えるからです。 しかも、この integration は value が出るまでが速いです。大げさな justification は要りません。Claude Code とブラウザを行き来して PR thread や issue history を見に行っているなら、その時点で GitHub path はかなり本命です。 GitHub が flashy な MCP より勝ちやすい理由は novelty ではありません。すでに real な workflow の context switching を減らすからです。良い first MCP は、既存 bottleneck を短くするべきで、新しい playground を増やすべきではありません。 GitHub が唯一の missing gap なら、そこで止めて構いません。最初の integration が役立ったからといって、次を追加する義務はありません。 ### Current-docs MCP は stale docs が税金になっている時の最初の third-party add です 開発者によっては、最初に必要なのは issue tracker でも browser automation でもありません。最近変わった framework や SDK について、Claude Code が古い記憶で答えてしまうことを止めたいのです。 その時に Context7 のような current-docs MCP が効きます。これはしばしば、最初に入れる価値がある third-party server です。implementation guidance が current reality に寄り、hallucinated APIs が減り、自分で最新版 docs を確認するための手動の行き来も減るからです。 この種の docs integration は、browser automation ほど派手に見えないので過小評価されやすいです。でも stale guidance が週の中で何度も retry を発生させているなら、最も leverage が大きい first add になりえます。 ここにも clear な stop rule があります。一つの clean docs path が freshness problem を解いたら、すぐに別の docs tools を重ねないことです。目的は、Claude に同じ docs を五通りで読ませることではなく、古い案内に時間を奪われるのを止めることです。 ### UI の missing proof が問題なら Playwright が最初の add になります ボトルネックが code を書くことではなく、ブラウザでそれが本当に正しく動いているかを確かめることなら、最初の MCP は Playwright になりやすいです。 Playwright 系の integration が早めに場所を取る価値があるのは、曖昧な frontend discussion を observable behavior に変えるからです。Claude Code が app を開き、flow を辿り、page state を見て、bug reproduction を手伝えるなら、それは単に情報量が増える話ではなく、できる仕事の種類が増える話です。 これは “たぶん動くはず” と manual browser checking の往復に時間を取られている team には特に効きます。browser automation が workflow の一部になると、Claude は UI fixes の検証、regression の再現、仮説から evidence までの距離短縮を手伝えるようになります。 ただし packaging は急がない方がいいです。Playwright に value があるからといって、すぐ shared project setup に上げる必要はありません。まだ一人が workflow を証明している段階なら、personal のままが自然です。` .mcp.json` に上げるのは、その browser-testing pattern が repo-owned になるほど安定してからです。 ### Sentry のような observability connector は、incident work が主線の時だけ早く入れる Observability access は powerful ですが、universal な day-one add ではありません。production debugging や incident response が本当に weekly workflow の中心にある時だけ、早めの位置を取るべきです。 例外、trace、error triage、on-call investigation が仕事の大きな部分を占めるなら、Sentry のような monitoring connector は高い価値を持つ first または second integration になります。local code だけでは見えない operational context を Claude Code に渡せるからです。 ただし、ここは setup が早く ambitious になりすぎる典型でもあります。Observability integration は見栄えが良いので、need が証明される前に入れがちです。incident が occasional で central ではないなら、prestige add にしない方がいいです。 ## Official connector が raw server より勝つ時と、project scope が personal setup を超える時 ![official surface、remote MCP、project scope、stop rule のエスカレーション図](https://blog.laozhang.ai/posts/ja/claude-code-best-mcp-servers/img/setup-ladder.jpg) Workflow が見えたら、次の判断は誰が integration を持つべきかです。 **Official または clearly vetted surface があるなら、まずそこを使います。** Anthropic の current connector surfaces は、raw server config に飛びつく前に十分検討する価値があります。first-party path は常にあるとは限りませんが、ある時は setup ambiguity と trust overhead を減らせます。 **Official surface がないが workflow は real なら、remote MCP server を使います。** これは many third-party tools では normal case です。ただし trust はここで一気に重くなります。Anthropic の current Claude Code MCP docs は、すべての third-party servers の correctness や security を確認していないこと、untrusted content を扱う server には prompt-injection risk があることを明示しています。つまり “third-party MCP を使うな” ではなく、“real な recurring workflow 以外の理由で入れるな” ということです。 **Project-scoped `.mcp.json` は repo が integration を持つべき時だけです。** Shared config を seriousness の badge のように扱うと、ここで判断を誤ります。複数人が同じ integration から利益を得ていて、setup も標準化できるほど stable になって初めて、この route は成立します。まだ “自分で試している” 段階なら personal のままで十分です。 **Plugin-bundled MCP は packaging と lifecycle が問題になってからです。** これはほとんどの team にとって first step ではありません。distribution、startup behavior、consistent enablement across team が問題になった時に初めて意味を持ちます。 実際の順番は単純です。personal first、shared config second、packaged distribution later。この順を逆にすると、usefulness の前に sophistication にコストを払うことになります。 ## 最悪の初手は connector sprawl です Claude Code を “強くしたつもりで弱くする” 一番簡単なやり方は、個別にはどれも良さそうに見える integrations を次々に足すことです。 Connector sprawl には少なくとも三つのコストがあります。 一つ目は **trust cost** です。Anthropic の current MCP docs は、third-party server の trust は自動ではないと明言しています。untrusted content を扱う server は prompt-injection path や wider workflow risk の一部になり得ます。Third-party server は clever demo ではなく、real workflow value で正当化されるべきです。 二つ目は **attention cost** です。Integrations が増えることは capability だけでなく、覚える名前、debug する setup、approval path、維持する habit も増えることを意味します。たまにしか助けない server なら、maintenance burden の方が value を超えやすいです。 三つ目は **usage cost** です。Claude Code はもともと context-heavy です。Tool definitions、tool results、広い automation loops は session を noisier で expensive にします。Workflow がそのコストを正当化するほど重要でなければ、その integration は見た目ほど役に立っていません。 だから stop rule が重要です。一つの integration が real gap を閉じたら、一度止まる。次の gap は自然に見えてきます。早い段階で本当に良い setup は、広い stack ではなく、実際に使う compact stack です。 ここで一つ boundary をはっきりさせておきます。もし本当に足りないのが external tool access ではなく **repo 内の reusable workflow knowledge** なら、読むべきなのは [Claude Code skills guide](https://blog.laozhang.ai/ja/posts/claude-code-best-skills) です。Skills は内部の手順知識向きで、MCP は外部ツールや data access 向きです。 そして、そもそも broader Claude Code setup がまだ固まっていないなら、このページを総合入口にしない方がいいです。先に [Claude Code install guide](https://blog.laozhang.ai/ja/posts/claude-code-install) から始める方が自然です。このページは narrower なままであるべきです。役目は first integration judgment であって、environment 全体の再説明ではありません。 ## FAQ ### Claude Code で最初に入れるべき MCP は何ですか？ 一番大きい external workflow gap を閉じるものです。多くの repo-heavy developer では GitHub、docs freshness が問題なら Context7 のような current-docs MCP、frontend verification なら Playwright が最初の候補になります。Novelty ではなく interruption cost で選びます。 ### Connectors と raw MCP server config のどちらを使うべきですか？ 仕事を終わらせるのに十分で、しかも最も trusted な surface を選びます。Official connector や clearly vetted route があるなら、それが普通は best first move です。Workflow が real で、official path がない時だけ raw や third-party server config に進みます。 ### `.mcp.json` が正しいのはどんな時ですか？ その integration が一人ではなく repo に属するべき時です。Workflow 自体が必要かどうかをまだ試している段階なら、personal のままで十分です。Shared config は stable repeated need を表すべきで、early experiment を表すべきではありません。 ### Third-party MCP servers は安全ですか？ 自動では安全ではありません。Anthropic の current Claude Code MCP docs は、すべての third-party MCP servers の correctness や security が確認済みではないこと、untrusted content を露出する server には prompt-injection risk があることを明言しています。Browser extension のように軽く扱うのではなく、real workflow dependency として扱ってください。 ### 最初は何個くらいの MCP を入れるべきですか？ たいていは一つか二つで十分です。最初の integration が main gap を閉じたなら、そこで止まる方がいいです。早期の Claude Code MCP setup は、大きい stack より、小さいけれど pay for itself している stack の方が強いです。 ### これは Claude Code skills を選ぶ話と同じですか？ 違います。Skills は internal workflow knowledge を扱い、MCP は external tools と data access を扱います。似て見えるのは、knowledge が足りないのか access が足りないのかを見分ける境界だけです。 本当に役に立つ Claude Code MCP strategy は、検索語の響きよりずっと小さいです。Ecosystem map ではなく workflow bottleneck から始め、official または clearly trusted surface を優先し、shared project setup は workflow が繰り返し現れるようになってからにします。それ以外の “とりあえずもう一つ足す” は、たいてい noise です。 ## 参考資料 本文で参照している外部ページを、登場順に並べています。最終更新日：2026-04-08。 - [Claude Code MCP docs](https://code.claude.com/docs/en/mcp) (code.claude.com) - [Connectors overview](https://claude.com/docs/connectors/overview) (claude.com) - [connector help-center guide](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) (support.claude.com)