MCP連携の罠。Lovable事件2ヶ月後、変えた運用3つ

[[IMG:hero]]

「MCPサーバー、何個繋いでます？」と聞かれて、3桁を答える人が最近じわじわ増えている。

私もその流れに乗りかけていた1人だ。便利そうなMCPサーバーを次々追加し、Claude Codeに「ここから先は全部見えてるから安心して書いて」と言わせるつもりで。

ところが2026年5月になって、その前提が静かに崩れてきました。Microsoftや海外のセキュリティメディアから、似た方向を指す警告が続いている。「MCPサーバーを増やすほど、エージェントは逆に賢くなくなる」「便利の代償が、まだ請求書として届いていないだけ」と。

きっかけは4月のLovable脆弱性報道だった。あれから約2ヶ月、現場のバイブコーディングがどう変わったかを、元・挫折エンジニアの目線で整理しておきたい。私自身がローカルで詰まった例も含めて、今週からどう運用を変えたかまで書く。

---

「MCPを増やすほど賢くなる」は誤解だった

最初に押さえておきたいのが、MCPに対する期待値のずれだ。

MCP（Model Context Protocol）は、Anthropicが公開した接続規格である。ClaudeなどのLLMエージェントと、外部ツール・データソースとを橋渡しする役割を担う。GitHub、Slack、ローカルファイルシステム、データベース、ブラウザ操作。あらゆる外部世界とエージェントを繋ぐ「USB-C」のような共通の口だと言われてきた。

USB-Cという比喩は、便利な反面ひとつ大事なことを覆い隠している。USB-Cのケーブルを5本同時に挿してもPCの性能は5倍にはならない。むしろ電源管理や帯域配分で混乱が起きる側面もある。MCPサーバーの「同時接続」も、これと似た構造を持つ。

複数のMCPサーバーを同時に接続すると、エージェントはどのツールを呼ぶかをまず選ぶ。選択肢が5個と50個では、選ぶ精度が変わる。Claude Codeでも実際に動かしてみると分かるが、MCPツールが2桁を超えてくると、最初に呼ぶべきツールを間違える頻度が体感で増えていく。

Microsoftが社内向け技術ブログでエージェント評価の文脈で似た傾向を指摘していると、複数の二次媒体が伝えている。「ツール選択精度はツール数に対して単調増加しない」「MCPサーバーの追加は便利さとトレードオフで判断ノイズを増やす」という方向の議論だ。一次URLは現時点では特定できていないが、「複数の二次媒体が伝えている」レベルで把握した。

私自身、Claude Code上で15個ほどのMCPサーバーを同時に有効にしていた時期がある。GitHub、Linear、Notion、Slack、ローカルDB、画像生成、データ可視化、PDF読み込み、Webブラウザ、社内API群、その他諸々。最初の1週間は感動の連続でした。あらゆることをClaude Codeから呼べる。

2週目に入ると、おかしな挙動が増えた。GitHubのIssueを更新したいだけなのに、Linear側のチケットを更新しようとする。SlackのDMを引っ張る作業でも、社内API側の検索が走り出す。「ツール選択ミス」が積もっていくのだ。

便利さの裏側で、エージェントは増えた選択肢に振り回されていた。MCPを増やすほど賢くなる、ではなく、増やすほど判断のコストが指数的に増える。これが2026年5月時点の現在地だ。

---

Lovable事件から2ヶ月、その後に何が積み重なったか

ここで時計を少し巻き戻したい。

2026年4月1日、私はLovable製アプリの脆弱性報道を起点に、バイブコーディングのセキュリティリスクを記事化した。生成AIで作られたアプリの一部に、認証バイパスや権限漏れの穴が広く残っていたという、Tenzai系のセキュリティ調査を起点にした内容だ。

あの記事を書いた時点で、論点は「生成されたコード自体の脆弱性」だった。LLMが書いたコードに、初学者が気づきにくいセキュリティホールが混入する。ここまでは多くの読者が直感的に理解できる話だろう。

ところが、4月下旬から5月にかけて論点が一段ずれてきている。問題は「生成されたコード」だけでなく、「エージェントが繋がっている経路」そのものへ移った。

具体的には、こういう報道や議論が蓄積している。海外のセキュリティメディアが、バイブコーディング環境におけるサプライチェーン汚染や、悪意あるMCPサーバーの混入リスクを取り上げはじめた。OSS実装のMCPサーバーで、想定より広い権限スコープを持つものも確認されている。社内導入したエージェントが、繋ぎ込んだSaaS側の認証情報を意図せず外部に渡してしまう。そんなリスクも議論の俎上に上がりはじめた。

これらの一部はInfosecurity Magazineの2026年版バイブコーディング特集でも触れられたと複数媒体が伝えており（一次URL未確認）、論点の方向は私自身のローカル体感と重なる。

つまり「Lovable事件」は単発の事件ではなく、入り口の話だった。生成コードの脆弱性から、エージェント周辺インフラの脆弱性へ。バイブコーディングが扱うリスク領域は、この2ヶ月で確実に広がっている。

ここで大事なのは「だから使うのをやめましょう」ではないということ。私はバイブコーディングをやめる気は一切ない。むしろ、ここから先の数ヶ月で運用ルールを整えた人と、整えなかった人で、被害の総量が大きく分かれるはずだ。

---

バイブコーディング2026の構造的リスク全景

ここでいったん発散させたい。2026年5月時点の構造的リスクを、私の現場感覚で全景化する。

5つの円を、ひとつずつ書く。

ひとつ目、生成コードの脆弱性。これが2026年初頭まで論点の中心だった。LLMが書いたコードに認証不備・権限漏れ・SQL注入・XSSなどが含まれる。Lovable系の事案で広く可視化されたパターンだ。今でもベースリスクとして残り続ける。

ふたつ目、MCP過剰連携。前章で書いたツール選択ミスの増加に加えて、繋がっているMCPサーバー間で本来別であるはずのデータが混ざりやすくなる。「Slackに書こうとして社内APIを叩く」エージェントの誤動作は、データ管理が厳しい現場では致命的だ。

3つ目、OSS MCPサーバーの権限スコープ。GitHubなどで公開されているMCPサーバーの中には、READMEには「読み取り専用」と書いてあるのに、コードを読むと書き込み権限まで持っているものが混じる。私自身、使用前のコードレビューを省略した結果、不要な権限をMCPに渡しかけた。

4つ目、認証情報の意図しない経路漏れ。MCPサーバーをローカルで動かすときに、APIトークンや認証情報を環境変数経由で渡す形になる。エージェントの会話履歴・ログ・スクリーンショット経由で、認証情報が想定外の場所へ漏れるリスクも無視できない。「ログをそのままSlackに貼り付ける」習慣がある人ほど、この穴に落ちやすい構造だ。

5つ目、サプライチェーン汚染。npmやpipのパッケージに紛れ込んだ悪意あるMCPサーバーが、開発者のローカル環境に静かに居座る可能性も指摘されている。Lovable事件後、海外のセキュリティ研究者の間でこの方向の懸念が継続的に共有されていると報じられた。

5つの円は独立していない。どれかひとつが破れると、隣の円にも影響が波及する構造だ。だからこそ「全部一気に対処しよう」と思うと心が折れる。

ここまでが発散だ。次の章で、ここから3つに圧縮する。

---

私がローカル環境で詰まった「MCP過剰連携」3例

圧縮の前に、自分の手で詰まった話を3つ書く。読者の方が同じ轍を踏まないように、ハマりポイントを先に共有しておきたい。

ひとつ目、LinearとGitHubの混線。

私は社内タスクをLinearで管理し、コードはGitHubで動かしています。Claude Codeに「このIssueに対応するPRを開いて」と頼んだとき、エージェントはGitHubのIssueとLinearのチケットを取り違えた。Linearのチケット番号と、GitHubのIssue番号が同じ「LIN-142」「#142」のような形式だったため、エージェントが選び間違えたのだ。

被害は小さく、本番には影響しなかった。ただし、本番DBに繋がるMCPサーバーが同時にONだったら、と思うと冷や汗が出る。

ふたつ目、読み取り専用と書いてあったMCPサーバーが、実は書き込みもできた話。

ある画像管理系のOSS MCPサーバーをローカルに入れました。READMEに「read-only」とはっきり書かれている。動かしてから1週間後、コードを読み返してみたら、削除APIまで呼び出せる関数が普通に実装されていた。READMEと実装にずれがあったわけだ。

私は使う前にコードを読まなかった。これは反省点。OSS MCPサーバーは、ライセンスとREADMEだけでなく、必ず実装まで目を通すべきだった。

3つ目、ログをそのままSlackに貼り付けかけた事案。

Claude Codeの出力ログを、社内Slackに「こんなエラー出てる」と相談で貼り付けようとした場面がある。直前で気づいたが、ログにAPIトークンの断片が混入していた。完全な漏洩ではなかったものの、設定によっては丸ごと貼ってしまっていた可能性もある。

便利さに乗ったまま走り続けると、こういう落とし穴は見えない。「ハマりポイントは先に共有する」がゲンの記事の原則なので、自分の失敗も先に出しておきたかった。

---

今週から変える3つの予防策

ここで圧縮する。5つのリスク・3つの失敗例から、今週から変えるべき予防策3つに絞り込みたい。

ひとつ目、同時接続するMCPは「3個まで」に絞り込む。

ここで言う3個は、目安にすぎない。私のローカル観測（体感値）: 2〜4個の同時接続が最も安定して動いた。GitHubと、ローカルファイルシステムと、いま触っているプロジェクト固有のSaaSがひとつ。これで多くの作業は回る。残りはプロジェクト切り替え時に有効化と無効化を回す運用に変えた。

設定ファイルでオンオフできるエージェント環境なら、「常時有効」グループと「都度有効」グループを分けたい。Claude Code系であれば、設定からMCPサーバーを必要な3個だけON、残りはコメントアウトで眠らせる。これだけでエージェントの判断ミスが体感できるほど減った。

ふたつ目、OSS MCPサーバーは、コードを読了してから有効化したい。

READMEは作者の意図、コードは実際の挙動。ふたつがずれるのは珍しいことではない。具体的な確認手順をひとつだけ書く。MCPサーバーが提供しているツール一覧（多くはJSONスキーマでツール名と引数を定義している）と、内部で呼ばれているAPI関数を突き合わせる。読み取りのはずのMCPで書き込み・削除系APIが呼ばれていたら、本番への接続は止めるべきだ。

「全部読むのは無理」と思うかもしれない。実際、私もMCPサーバー1個あたり30分以上は使えていない現実がある。ただし最低限、「ツール定義の一覧」と「呼び出されているHTTPメソッド」の2点だけは目を通す。GETしか出ていないなら読み取り専用としてほぼ信用できる範囲だ。POST/DELETE/PUTが混ざっていたら、READMEと実装の乖離を確認したい。

ターミナルで素早く確認する方法も書いておく。MCPサーバーのソースが src/ 以下にある場合、次のコマンドで書き込み系APIの呼び出しを30秒で抽出できる。

# OSS MCPサーバーの書き込み系API確認（READ-ONLYと書いてあっても必ず走らせる）
grep -rE "(DELETE|POST|PUT)" src/

何も出なければまず安全圏だ。出てきた場合は、READMEの記載と照らし合わせてから本番接続を判断する。

3つ目、ログを外部に貼る前に、必ずトークン文字列の検索をかける。

私が使っているのは、grep -E "sk-|ghp_|xoxb-|Bearer " のような簡易検索だ。OpenAI、GitHub、Slack、Bearerトークンの典型的な接頭辞を入れてある。社内SaaSのトークン形式があれば、社内のシークレットマネージャーの命名規則に合わせて検索パターンを足したい。

# ログをコピーする前に走らせる簡易チェック
grep -nE 'sk-[A-Za-z0-9]{20,}|ghp_[A-Za-z0-9]{20,}|xoxb-[A-Za-z0-9-]{20,}|Bearer [A-Za-z0-9._-]{20,}' \
  ./logs/claude-code-*.log

このチェックを「ログをSlackに貼り付ける前」と「ブログに事例として書く前」の2タイミングで必ず走らせる癖をつけた。7日間続ければ、自然と手が動くようになる。

3つの予防策をまとめ直す。MCPは3個まで、OSS MCPはコード読了後に有効化、ログ貼付け前にトークン検索。順番は逆でも構わない。今週中に3つすべてを一度回してみるところから始めるのが現実的だろう。

---

仲間の視点と、私の立ち位置

ここで一度、自分の立ち位置を整理しておきたい。

私はバイブコーディング推進派だ。これは何度書いても変わらない。Cursor、Claude Code、各種MCPサーバー、IDEプラグイン、どれもAIで開発体験を引き上げる装置だと考えている。CSや業務側の人がコードに戻ってこられたのも、これらの道具のおかげだろう。

それでも今回のテーマで予防策を書いた理由は、ナギの記事で繰り返し触れられている「AIエージェントの本番運用フェーズ」の話と地続きだからだ。実験段階では多少の事故も学びになる。ところが本番に使い始めた瞬間、同じ事故が顧客や同僚に影響を及ぼす。

ナギが書いてきたAIエージェント運用フェーズへという論考と、私が今回書いた「MCPは3個まで」という運用面の節制は、同じ景色を別の角度から見ている。技術的な深いアーキテクチャはナギの記事に任せ、私は手元の作業机から見えるリスクの輪郭を書く。

マサゴからは過去にも「テンションが上がりすぎたら『本当に神か？』と自問しろ」という指摘を受け続けてきた。今回もLovable事件後、私はMCPの便利さに乗りかけて、何度か警告を素通りしていた1人だ。マサゴ的な冷静さがなければ、3つの予防策にたどり着くまでにもっと時間がかかったはずである。

そしてミコトに聞かれそうな問いも先回りしておきたい。「で、それ誰のためになるんですか？」。答えは、これからバイブコーディングを本番運用に乗せ始めるすべての人。とくにエンジニア専業ではない人、CSやマーケで業務ツールを自作している人、フリーランス開発者。便利さに乗っているうちに、足元を切られたくない人たち全員に、今週変えてほしい3つだ。

---

まとめ——便利さと安全のバランス点

ここまでの内容を圧縮しておきたい。

MCPサーバーを増やすほどエージェントが賢くなる、という前提は2026年5月時点で崩れてきた。ツール選択の判断コストが増え、便利さの代償として精度が落ちる場面が現実に出てきている。

Lovable事件から約2ヶ月、論点は「生成コードの脆弱性」だけでなく「エージェントが繋がっている経路」全体に広がった。バイブコーディングのリスクは、生成コード・MCP過剰連携・OSS権限スコープ・認証情報の経路漏れ・サプライチェーン汚染の5領域に拡張されている。

私自身も、ローカル環境で3つの失敗をした。LinearとGitHubの混線、読み取り専用と書かれていたOSS MCPが書き込みできた事案、ログにトークンが紛れ込んだままSlackに貼り付けかけた事案。どれも本番事故には至らなかったが、設定次第では危なかったケースだ。

今週から変える予防策は3つに絞った。同時接続するMCPサーバーは3個まで、OSS MCPはコードを読了してから有効化、ログを外部に貼る前にトークン文字列を必ず検索。順番は問わない。7日間で全部を一巡してみるところから始めれば、運用の節制が手に馴染んでくる。

最後にひとつ。バイブコーディングは終わったわけではない。便利さと安全のバランス点を見つける運用フェーズに入ったというだけだ。挫折して一度コードから離れた私が戻ってこられたのは、これらの道具のおかげ。簡単にやめる気は一切ない。

ただ、便利さに乗ったまま走り続けるのは、もう違う段階に来ている。今週、3つだけ変えてみてほしい。MCPは3個まで、OSS MCPはコード読了後、ログ貼付け前にトークン検索。これだけで、Lovable事件後の2ヶ月で積み上がってきたリスクのうち、かなりの部分が手元で防げる。

便利さも安全も、どちらも諦めない。これがゲンの選んだバランス点だ。