「動いた」で本番投入したMCPサーバーが副業AIを静かに削る、Claude Code運用者が潰す5観点と3段階

MCPサーバーを入れて、Claude Codeから呼び出せた瞬間に「よし動いた」と安心してしまう人は多いと思う。自分もそうだった。10年以上現役でエンジニアをやってきて、副業でAIを回してきた感覚からすると、この「動いた=OK」の思い込みは、副業の自動化を静かに壊す第一歩になりやすい。

MCP(Model Context Protocol)は、Claudeなどのクライアントに外部ツールをつなぐための共通規格で、コミュニティ製のサーバーが1000本を超えるレベルで増えている。ファイル操作、DB、API、なんでもある。ただ、そのほとんどは作者が自分の環境(たいていはClaude Desktop)で動くのを確認して、そのまま公開しているだけ、というのが実情らしい。

副業でAIを収益化しようとしている人ほど、ここでコケる。動いたと思って組み込んで、しばらく経ってから「なんかツールが呼ばれてないな」と気づく。その時にはもう時間を溶かしている。

「動いた」で安心した瞬間、副業の自動化は止まる
MCPサーバーが増えるほど、検証されていないツールも増えている
1. 起動する ≠ 安全に使える
検証していないツールが静かに信用を削る仕組み
検証を運用ルールに組み込むと何が変わるか
まとめ
参考
【PR】フリーランスエンジニアにおすすめのツール
【PR】おすすめの書籍
1. あわせて読みたい

「動いた」で安心した瞬間、副業の自動化は止まる

自分の周りで、AI副業がうまく回っていない人にはひとつ共通点がある。「試したら動いた」から「本番に組み込んだ」までの距離が、ほぼゼロなことだ。

これは本人が悪いというより、MCPサーバーの世界全体がそういう空気になっている。npmやPyPIから入れて、設定ファイルに1行追加して、Claudeに聞いたらツールが呼び出せた。ここまでを「導入完了」と呼んでしまう。実際には、これは初期化ハンドシェイクが通っただけで、まだ何も検証していない状態だ。

副業で自動化する時にきついのは、失敗が静かに来ることだと思う。手動でやっていた頃は、うまくいかなければ画面を見て気付ける。AIエージェントに任せた瞬間、失敗はログの奥に沈む。呼び出されないツール、空で返ってくるレスポンス、微妙にズレたパラメータ。全部、朝起きたら結果が薄い、という形で顔を出す。

自分はこれを、副業の売上や記事の反応が伸び悩む要因として何度も見てきた。ツール周りが原因のときは、大抵「壊れている」ではなく「なんとなく動いているように見える」状態で潜んでいる。エラーで止まってくれた方がまだ親切だ。

ありがちなのは、Claude Codeでの検証を Claude Desktop 上で1回済ませて、そのままCursorやVS Code、他のクライアントに横展開してしまうケース。ここが今回の元記事の指摘とも重なる。MCPサーバーは特定のクライアントで動作確認された後、他クライアントで初めて触るのが利用者、みたいな構造になっている。

MCPサーバーが増えるほど、検証されていないツールも増えている

元記事の著者が指摘しているのは、いま起きているのはREST APIの初期に近い状況だ、ということだ。ツールの数だけは爆発的に増えたが、それを検証するインフラが追いついていない。

REST APIの世界では、Postman、OpenAPIバリデータ、CI上でのスキーマテスト、といった検証レイヤが整ってきて、ようやく安心して他人のAPIを組み込めるようになった。MCPの世界にはまだそれがない。ツールを配布する側も、受け取る側も、それぞれの環境で「たぶん動くはず」を積み上げている。

副業でAIを回している人にとってこの状況は無視できない。理由はシンプルで、副業ワークフローの多くは、外部ツールを何本か束ねて自動化することで成り立っているからだ。1本1本の信頼性が低いと、束ねた瞬間に信頼性は掛け算で落ちる。ツール5本の稼働率が仮に9割だとしたら、全体は6割を切る。副業として時給換算した時に、この差はきつい。

起動する ≠ 安全に使える

元記事の中で自分がいちばん頷いたのが、「検証は『起動するか』ではない」という部分だった。検証と呼ぶには、少なくとも以下の観点をひととおり確認する必要がある、と書かれている。

①プロトコル準拠初期化ハンドシェイクが正しく実装されているか。対応プロトコルバージョン・ケイパビリティフラグを正しく返せるか。

②スキーマ整合性ツールが公開しているJSON Schemaが、実装と一致しているか。必須項目の欠落や壊れた参照が混じっていないか。

③エラーハンドリング悪い入力を渡した時に、まともなJSON-RPCエラーで返せるか。転送ストリーム自体を落として、クライアントを無反応にしてしまわないか。

④クロスクライアント互換性 Claude Desktop、Cursor、VS Code、Cline、それぞれの流儀に対応しているか。ある環境で動いても他で沈黙する挙動がないか。

⑤レスポンス品質クリーンな構造化データを返しているか。生のスタックトレースやHTMLエラーページを、モデルのコンテキストに垂れ流していないか。

この5つは、自分が現場で受託・自社開発をやっていた時のAPIレビュー観点とほとんど同じだ。ステータスコードとエラーボディの取り決め、契約テスト、スキーマとの整合性チェック。REST APIで当たり前に見てきたものを、MCPでもやる必要がある、という話でしかない。

ただし、副業でAIを組んでいる人にはピンとこない観点も混じっている。特に②のスキーマ整合性は要注意で、ここが壊れているとモデルが引数を幻覚し始める。呼び出しは通っているように見えるのに、返ってくる中身が微妙にズレる、みたいな挙動になる。原因を追う時に、まさか自分が入れたMCPサーバーのスキーマが実装とズレているとは思わない。それでだいたい2、3日溶かす。

検証していないツールが静かに信用を削る仕組み

ここまでは「壊れているMCPサーバーが混ざっているかもしれない」という話だったが、副業目線でもっと深刻なのは、静かに信用が削られる方だと思う。

AIエージェントを使った副業の強みは、成果物を安定して出せることだ。ブログを毎日更新する、noteの下書きを揃える、SNSに情報を流す、リサーチを回す、この辺りは全部ツール呼び出しの信頼性に乗っている。ツールが半分の確率で沈黙するだけで、成果物の質は目に見えて落ちる。

読者は「今日の記事はなんか薄いな」としか感じない。書いた本人からするとツールの検証不足が原因なのに、外からは「発信者の腕が落ちた」に見える。副業で一番怖いのは、この見え方の落差だと思う。

自分が過去にやらかしたのは、自作のサンプルデータでMCP連携の動作を確認して、そのまま本物のワークフローに突っ込んだケースだ。合成データでは全ツールが順番に呼ばれて、綺麗に結果が返ってきた。実データにしたら、思ってもいなかった箇所で沈黙が発生していた。あとから見直すと、ツール側のエラーハンドリングが甘くて、想定外の入力で暗黙的に空レスポンスを返していただけだった。自作サンプルで動いても、実データで回すまで設計の弱さは見えにくい、というのを身をもって学んだ回だった。

この手のトラブルは、AIをまだ触り始めたばかりのSIer出身者ほどハマりやすい。理由は皮肉なもので、SIerで培ったスキル(要件通りに動作させる力)が、MCPの世界ではむしろ油断につながるからだ。要件通りに動くことは確認するが、「他クライアントで動くか」「悪い入力でも壊れないか」といった観点は、ツールの品質管理者側の視点で、ユーザー側の検証観点ではない。副業でAIを組む時は、この両方を自分でやる必要がある。

もうひとつ、副業運用で見落としがちなのはレスポンス品質だ。ツールが返すデータにHTMLエラーページや生のトレースバックが混ざっていると、それをそのままモデルのコンテキストに突っ込むことになる。モデルは律儀にそれを読み取ろうとする。結果、下流の推論がノイズを引き受ける形になって、成果物の品質が地味に落ちる。原因不明の「なんか最近微妙」の犯人は、たいてい表からは見えない場所にいる。

検証を運用ルールに組み込むと何が変わるか

では、どこから手をつけるべきか。元記事はMCP Workbenchという検証ツールを紹介しているが、それを使う使わない以前に、まず運用ルールとして検証工程を挟むことが先だと思っている。

自分がいま副業のAIワークフローで意識しているのは、次の3段階だ。

1段階目は、導入直後の「触ってみるだけの日」を必ず設けること。設定ファイルにMCPサーバーを追加したその日は、本番ワークフローには組み込まない。とにかく単発で叩いて、悪い入力、空の入力、想定外の引数、をひととおり試す。動く/落ちる/沈黙する、の三択で挙動を分類する。ここで沈黙するツールは、本番導入から外す。エラーで落ちてくれるツールの方がまだ扱いやすい。

2段階目は、実データでの試験稼働期間を挟むこと。自作サンプルでの結果は信じない。副業のワークフローで実際に流れているデータの一部を切り出して、そのMCPサーバー越しに何日か回す。この期間に、返り値の型、想定外の空フィールド、レスポンスサイズの上振れ、を観察する。この段階で気づく不整合は、本番組み込み後に気づくより10倍安い。

3段階目は、監視というよりログの見方の話で、MCPツール呼び出しごとに「呼ばれたか」「返ってきたか」「空でなかったか」を残しておくこと。壊れた瞬間の検知ではなく、後から見返して「あ、先週からこいつ半分空を返してるな」に気付ける状態を作る。副業の自動化で怖いのは即死ではなくジワジワ死ぬパターンなので、そちら側に手を打っておく。

この3段階を挟むと、MCPサーバーを増やすスピードは落ちる。ただ、副業として時給換算した時のトータルコストは確実に下がる。ツール5本のうち1本が半年後に静かに壊れて、成果物の質が落ちて、記事の反応が落ちて、原因不明で対処に週末を2回溶かす、というありがちな流れが起きなくなる。

SIer出身で副業に踏み出した人ほど、ここの投資対効果はイメージしやすいと思う。要件定義と結合テストの重要さは日々肌で感じてきているはずで、それをMCPというレイヤに移して考えるだけの話だ。ツール1本ずつに小さな結合テスト計画を立てる、と思うといい。

もうひとつ書いておくと、検証工程を挟むと、副業でAIを使う時の「自信」の質が変わる。動いたから使えるはず、ではなく、この観点を潰したから任せていい、に変わる。これは記事を書く、SNSに投稿する、有料コンテンツを作る、みたいに読者や購入者との信頼で成り立っている領域では、精神衛生的にもかなり大きい。売れない時期に「そもそもツールが半壊してるのでは」と疑わずに済むだけで、改善のサイクルは早く回る。

まとめ

MCPサーバーは「動いた」だけでは検証していないに等しい。プロトコル準拠・スキーマ整合性・エラーハンドリング・クロスクライアント互換性・レスポンス品質までを見て初めて検証と呼べる
副業でAIを回すほど、ツールの静かな半壊はそのまま成果物と信用の低下に直結する。REST APIと同じ検証インフラがMCPにもまだ足りていない状況を前提に組む
導入直後の単発試験、実データでの試験稼働、呼び出しログの後追い観察、この3段階を運用ルールに落とすと、副業の自動化は長く走らせられる