Claude Codeを作った本人が、何を一番大事だと言っているか知ってますか。
プロンプトの書き方じゃないです。モデルの選び方でもない。
「Claudeに、自分の出力を検証する手段を渡せ」
これ1つです。彼はこれを、Claude Codeを使う上で最も重要なTipだと言い切ってます。
で、今回の記事はその話の続きです。原則は分かった。じゃあその手段を、具体的にどうやって渡すのか。答えがMCPサーバーなんですよね。
正直、これ知ってるか知らないかでClaude Codeの使い心地が本当に変わります。毎回ドキュメントを貼り付けてた時間、Issueをコピペしてた時間、作った画面を自分で開いて確認してた時間。全部要らなくなります。
Claude Code使ってて、こんな状態になってないですか。
- 生成されたコードが古い書き方で、毎回自分で直してる
- 作った画面が本当に動くか、結局自分でブラウザ開いて確認してる
- Issueの内容をコピーして、Claudeに貼って、実装させて、また戻って進捗を書いてる
- 本番でエラーが出るたびに、Sentryの画面からスタックトレースをコピペしてる
- MCPって言葉は知ってるけど、何を入れればいいのか分からないまま放置してる
はい。全部、僕もやってました。
先に言っておきますが、この記事はコードが書けない人でも読めます。専門用語はその都度かみ砕きます。むしろMCPは、エンジニアじゃない人ほど恩恵がデカい仕組みです。
読み終わる頃には、自分の作業の中から「毎回コピペしてる場所」を1つ探したくなってるはずです。
保存しといてください。
そもそも「ボリス」って誰なのか
Boris Cherny（ボリス・チェルニー）。Claude Codeを作った本人です。
本人が「I created Claude Code」と明言してるので、ここは疑いようがない。Claude Codeというツールの設計思想を、いちばん深いところで理解している人物です。
彼の使い方が異常なんですよ。
まず、もうずっと自分でコードを手で書いてません。じゃあ何をしてるかというと、ターミナルで5つ前後、Webでさらに5から10のClaudeセッションを同時に走らせて、タブに番号を振って、通知で「どのClaudeが人間の入力待ちか」を管理してる。
（想像してみてください。部下が15人いて、全員が別々の作業をしてて、手が止まった人だけが呼びに来る状態です）
しかも彼のCLAUDE.md、つまりプロジェクトのルールブックは100行程度しかない。ルールを大量に書き込むタイプじゃないんです。
彼が言ってることで一番よく引用されるのが、これです。
「プロンプトを書くな。ループを書け」
うまくお願いする方法を探すんじゃなくて、Claudeが自分で回れる環境を作る。ここが彼の思想の中心にあります。
ボリスが繰り返し言っている3つの原則
彼の発信を並べると、言ってることはずっと同じです。
原則1．Claudeに、自分の出力を検証する手段を渡す
彼はこれを「最も重要なTip」と呼んでます。理由の説明が本当に分かりやすいので、そのまま紹介します。
誰かにWebサイトを作ってくれと頼んで、でもブラウザを使うのは禁止、という条件をつけたらどうなるか。まともなものは上がってこないですよね。
でもブラウザを渡せば、その人は作って、見て、直して、また見て、良くなるまで繰り返す。
Claudeも同じだと。検証する手段さえ渡せば、勝手に納得いくまで反復する。
原則2．1日1回以上やる作業は、仕組みにする
毎回チャットで同じ手順を説明するのは時間の無駄なので、Skillやコマンドにしてしまう。しかも呼ぶまではコストがほぼゼロだから、作っておいて損がない。
原則3．外部ツールを、Claude Codeの作業面に持ち込む
Slack、課題管理ツール、データベース、社内API。これらをClaude Codeから直接触れるようにすると、ツール間の移動そのものが消える。
ここで登場するのがMCPです。
最後に
MCPの話をすると、必ずこの壁にぶつかります。
MCPを繋いだ瞬間、Claude Codeの手が本番環境に届くようになるんですよ。デプロイも、DNSも、決済も、顧客データも。読み取りだけならいいんですけど、書き込みや削除まで一気に許可すると、普通に事故ります。
じゃあ、どこまで任せて、どこから人間が確認するのか。
その線引き表を無料で配ってます。MCPを入れる前に一度見ておいてほしいので、置いておきます。
👇
MCPを一言で言うと何なのか
まずここを潰しておきます。
MCPは「AIツールと外部サービスをつなぐ共通の差し込み口」です。USBの規格みたいなものだと思ってください。
これがない世界だと、Claude用の連携、ChatGPT用の連携、別のAI用の連携、と全部バラバラに作る必要がありました。MCPという規格ができたことで、サービス側は1回作れば、対応してるAIツール全部から使えるようになった。
で、勘違いされやすいんですけど、MCPはClaude Codeに機能を追加するものじゃないです。
作業対象そのものを、Claude Codeの中に持ってくるもの。
Figmaのデザインを、Sentryのエラーを、Linearのチケットを、Cloudflareの本番ログを、Claudeが直接見て、直接触れる状態にする。だからコピペが消える。
そして今、この規格がかなり大きく変わりました。
MCPの前提が変わった話
ここ、日本語圏でまだほとんど整理されてないので押さえておいてください。
最新の仕様改定で、MCPは規格の公開以来いちばん大きく作り替えられました。主な変更はこの4つです。
ステートレス化。これまでのリモートMCPは、サーバー側が接続の状態を持ち続ける設計でした。それをやめて、普通のHTTPと同じリクエスト・レスポンス型になった。何が嬉しいかというと、サーバーレスやエッジ環境にそのまま載る。1台の常駐サーバーじゃなく、アクセスに応じて増減する仕組みとしてMCPを建てられるようになりました。
長時間処理への対応。ツールを呼んだら結果を即返す、という前提が外れました。先に受付番号だけ返して、あとから進捗確認、更新、キャンセルができる。大規模なコード移行、動画生成、長時間のデータ分析、全環境へのデプロイ。こういう「数時間かかる仕事」をMCP経由で投げて、後から結果を回収する設計が正式に認められた形です。
会話の中にUIを返せるようになった。これまでのMCPはテキストとJSONが中心でしたが、サーバー側が操作画面を返せるようになりました。デプロイ対象を選ぶ画面、グラフ、承認と却下のボタン、フォーム。要するにMCPは、AIが裏でAPIを叩く仕組みから、AIの上で動く小型アプリの規格へ向かってます。
組織単位の認証。企業のIDプロバイダーと結びついて、管理者が一度承認すれば、社員は初回ログインで自動的に繋がる。APIキーを1人ずつ配る運用が消えます。
ちなみにAnthropic側の対応は順次ロールアウト中です。仕様が確定したことと、手元のClaude Codeが今すぐ全部使えることは別なので、そこは分けて考えてください。
（ここ盛って書いてる記事をたまに見かけますが、公式の表現は「順次展開中」です）
Claudeのコネクタ一覧に載っているMCPサーバーは950を超えてます。数だけ見ると圧倒されますけど、実際に入れるべきものはそんなに多くないです。
Claude Codeが別物になる公式MCPサーバー8選
ここからが本編です。
選定基準は3つ。提供元が自分で管理している公式のものであること。初心者でも効果を体感しやすいこと。そしてボリスの3原則のどれかを直接実装できること。
1．Context7 MCP。古いコードを吐く原因を潰す
Claude Codeが間違ったコードを出すとき、原因はモデルの頭の悪さじゃないことが多いです。
参照してる情報が古いだけ。
廃止されたAPIを使う。古い書き方のNext.jsを出す。バージョン違いの設定を混ぜる。存在しないオプションを生成する。ドキュメントにない実装を推測で埋める。全部これです。
Context7は、ライブラリやフレームワークの最新ドキュメントを、バージョン別にClaude Codeへ渡すMCPです。記憶から答えるんじゃなくて、対象バージョンの資料を引いてから実装させる状態を作れます。
実践プロンプト
Context7を使って、このプロジェクトで使っている
Next.jsの現在のバージョンの公式資料を確認してください。
確認後、以下を整理してから実装に入ってください。
- 現バージョンで推奨される実装
- すでに廃止された実装
- 現在のプロジェクトコードとの差分
- 修正が必要なファイル
推測で実装せず、資料に書かれている方法だけを使ってください。
注意点。1回の問い合わせに複数の概念を混ぜないでください。「認証とルーティングとキャッシュについて教えて」だと、広く浅い結果が返ってきます。概念ごとに分けて引く方が精度が出ます。
公式リポジトリ：https://github.com/upstash/context7
2．Playwright MCP。Claude自身にブラウザを触らせる
ボリスの原則1をそのまま実装するのがこれです。
Claude Codeはコードを書けますけど、書いた画面が実際に動くかは知りません。Playwright MCPを繋ぐと、Claudeが本物のブラウザを開いて、ボタンを押して、フォームに入力して、画面遷移を追って、エラーを拾って、直して、もう一度確認するところまでやります。
この仕組みで面白いのは、スクリーンショットを画像として眺めてるわけじゃないところです。アクセシビリティツリーという、画面の構造化された情報を読んでます。どこがボタンで、どこが入力欄で、どこが見出しなのか。意味として読んでるから、見た目が似てる要素を取り違えにくい。
実践プロンプト
実装が終わったら、Playwright MCPでローカル環境を開いてください。
以下を実際に操作して検証してください。
- 新規登録
- ログイン
- 入力エラー時の表示
- スマートフォン幅での表示崩れ
- ログアウト
失敗した場合は、コードを読むだけで原因を推測せず、
ブラウザ上で再現してから修正してください。
修正後は同じ操作を再実行し、成功を確認してから完了と報告してください。
ここで正直に書いておきます。
ボリス本人がWeb作業で毎回使ってると言っているのは、実はPlaywright MCPではなくClaude Codeのブラウザ拡張の方です。ログイン状態をそのまま共有できるので、似た用途のMCPより安定する、という言い方をしてます。
なので使い分けはこうなります。自分のログイン済みブラウザで、実際の画面を見ながら確認したいなら拡張。テストとして自動化して、何度も同じ手順を回したいならPlaywright MCP。
どちらも思想は同じで、要するに「Claudeにブラウザを渡せ」です。
公式リポジトリ：https://github.com/microsoft/playwright-mcp
3．Figma MCP。画像じゃなく設計データを読ませる
デザインをスクリーンショットで渡してるうちは、Claudeはずっと推測してます。
余白は何ピクセルか。フォントサイズはいくつか。この色はブランドカラーなのか一時的な色なのか。このパーツは再利用すべきコンポーネントなのか。全部、画像から目視で当ててる状態です。
Figmaの開発者向けMCPを繋ぐと、デザイン側の構造化された情報を直接取れます。数値、色、コンポーネント構造、デザイントークン。推測が消えます。
実践プロンプト
Figma MCPから、現在選択中のフレームを取得してください。
最初に以下だけを抽出して、実装には入らないでください。
・ページ構造
・再利用すべきコンポーネント
・色とタイポグラフィの定義
・余白のルール
・レスポンシブ時に想定される変化
抽出内容を確認したうえで、
既存プロジェクトのコンポーネントを優先して実装してください。
新規コンポーネントを作る場合は、なぜ既存で足りないのかを先に説明してください。
そして、ここからが本番です。
Figmaで設計を取る、Claude Codeで実装する、Playwrightで実際に開いて確認する、崩れてたら直す。この3つを繋げると、デザインから検証までが1本の線になります。
MCPは単体で語るより、この繋がりで見た方が価値が分かります。
公式ドキュメント：https://developers.figma.com/docs/figma-mcp-server/
4．Linear MCP。チケットを読んで、進捗まで書かせる
ボリスは、同僚のPRに@claudeとメンションして、そこで得た学びをルールブックに追記させる運用をしてます。要するに、課題管理の場所とAIの作業場所を分けてない。
Linear公式のMCPを繋ぐと、Issueの検索、作成、更新、コメントがClaude Codeの中で完結します。Linear側がホストしている認証つきのリモート接続なので、自分のPCでサーバーを常駐させる必要もありません。
これで、こういう流れが一気通貫になります。
Issueを読む → 関連コードを調べる → 実装計画を作る → 実装する → テストする → Issueに進捗をコメントする → ステータスを更新する
実践プロンプト
Linearで、自分が担当していて進行中になっているIssueを確認してください。
優先度と依存関係を整理したうえで、
最も優先度が高いIssueについて以下を実行してください。
- 要件で不足している情報を洗い出す
- 関連するコードを調査する
- 実装計画を作成し、実装前に提示する
- 承認後に実装とテストを行う
- 実施内容をIssueへコメントする
ステータスの変更は、私が確認してから行ってください。
最後の1行、必ず入れてください。ステータス変更まで自動でやらせると、チームの他のメンバーから見て「終わったことになってる未完成の仕事」が生まれます。
公式ドキュメント：https://linear.app/docs/mcp
5．Sentry MCP。エラーを貼らずに原因まで追わせる
本番でエラーが出たとき、何をしてますか。
Sentryの画面を開いて、スタックトレースをコピーして、Claudeに貼って、心当たりのあるファイルを探して、また貼って。あれ、全部いらないです。
Sentry MCPの価値は、エラー一覧を見せることじゃありません。エラー内容、スタックトレース、発生頻度、影響ユーザー数、どのリリースから出てるか、関連コード、過去の類似障害。これを1つの調査ループに入れられることです。
実践プロンプト
Sentryから、直近24時間で影響ユーザー数が最も多い未解決エラーを取得してください。
以下の順で調査してください。
- 発生条件を分析する
- 関連するコードを特定する
- 再現テストを作成する
- 再現できたら最小限の修正を実装する
- 全テストを実行する
- 根本原因と修正内容をまとめる
再現できない場合は、推測で修正しないでください。
原因を絞り込むために追加で必要な情報を列挙して、そこで止まってください。
「再現できないなら推測で直すな」の一文が効きます。これがないと、それっぽい修正が入って、根本原因が残ったまま「直しました」と報告されます。
公式ドキュメント：https://docs.sentry.io/product/sentry-mcp/
6．Cloudflare MCP。デプロイ先の状態まで見せる
ここまでは開発の話でしたが、ここからは運用です。
Cloudflareは自社サービスを操作する公式のMCPサーバーを複数出してます。設定の確認、Workersの管理、ログ分析、DNS設定、セキュリティ設定、パフォーマンス確認。読むだけじゃなく、提案して、実際に変更するところまで想定されてます。
つまりClaude Codeが、自分の書いたコードがデプロイ先でどう動いてるかを見た上で改善できる。
実践プロンプト
Cloudflare MCPで現在の本番環境の状態を確認してください。
・直近24時間のエラー
・レスポンス時間
・キャッシュヒット率
・セキュリティイベント
・Workersで発生している例外
を調査したうえで、問題を次の2つに分類してください。
A. コード変更が必要なもの
B. Cloudflare側の設定だけで改善できるもの
どちらも、変更を実行する前に必ず計画を提示してください。
私が承認するまで設定変更を行わないでください。
これはインフラを触るMCPなので、導入初期は読み取りだけに絞ってください。設定変更を最初から許可する必要はないです。
公式ドキュメント：https://developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/
7．Stripe MCP。決済コードとStripe側の設定を突き合わせる
決済まわりの実装がキツい理由って、コードだけ見てても正解が分からないところなんですよね。Stripe側にどんな商品と価格が登録されてるか、Webhookがどう設定されてるか、それを別タブで確認しながら書くことになる。
Stripe公式のMCPは、Stripe APIの操作に加えて、公式ドキュメントとサポート情報の検索まで持ってます。実装、設定確認、資料参照が同じ場所に乗る。
しかもStripeは、MCPだけじゃなくエージェント向けのSkillも用意してます。MCPで操作して、Skillで作法を守らせる。この組み合わせが強いです。
実践プロンプト
Stripe MCPとStripe公式ドキュメントを使って、
月額課金機能の実装計画を作成してください。
以下を必ず確認してください。
- ProductとPriceの構成
- Checkout Sessionの作り方
- Webhookで受け取るべきイベント
- 解約処理の流れ
- 支払い失敗時の挙動
- 二重登録を防ぐ方法
- テスト方法
作業中はStripeのテストモードだけを使用してください。
本番データには一切変更を加えないでください。
最後の2行は絶対に消さないでください。ここを空けたまま走らせるMCPではないです。
公式ドキュメント：https://docs.stripe.com/mcp
8．GitHub MCP。レビュー対応まで閉じる
最後がこれです。
ただ、勘違いしないでほしいんですけど、GitHub MCPの価値は「gitのコマンドを打てること」じゃありません。Claude Codeは元からローカルのgitもGitHub CLIも触れます。
価値が出るのは、リモート側にしかない情報を横断するときです。Issueの詳細、PRのレビューコメント、CIの結果、別リポジトリの状況、組織内のコード検索、過去の議論。
実践プロンプト
GitHub MCPで、現在のブランチに対応するPRを確認してください。
未解決のレビューコメントをすべて拾って、次の3つに分類してください。
・必ず修正すべきもの
・設計判断が必要で、私が決めるべきもの
・修正不要と判断できるもの（理由も書く）
「必ず修正すべきもの」だけを実装し、テストを通してください。
設計判断が必要なものには手をつけず、
論点と選択肢を整理して提示してください。
レビューコメントを読んで、直して、テストして、報告するところまでClaude Codeの中で閉じます。
公式リポジトリ：https://github.com/github/github-mcp-server
単体じゃなく「スタック」で組む
MCPは1つずつ入れても効果が薄いです。工程に沿って並べると化けます。
Web制作スタック
Figmaで設計を取る → Context7で今の正しい書き方を確認 → Claude Codeで実装 → Playwrightでブラウザ検証 → GitHubでPRとレビュー対応 → Cloudflareでデプロイとログ確認
SaaS開発スタック
Linearで要件を取る → Context7で技術仕様を確認 → Claude Codeで実装 → Stripeで決済を設定して検証 → Playwrightでユーザー操作をテスト → Sentryで本番エラーを監視
何が起きてるか
どっちのスタックも、やってることは同じです。
情報を取る、計画する、作る、自分で検証する、外部に反映する、結果を見る。
このループを、Claude Codeから一歩も出ずに閉じてます。
ボリスが言う「検証する手段を渡せ」は、ブラウザ1個の話じゃないんですよ。工程ごとに、その工程の正解を確認できる手段を渡せ、ということです。
初心者は、この3つだけ入れればいい
8個全部入れましょう、とは言いません。それをやると次の章の落とし穴に落ちます。
第1段階：Context7
目的は、間違ったコードを減らすこと。
読み取り中心なのでリスクが低いです。ここから始めるのが一番安全で、しかも効果を一番早く体感できます。
第2段階：Playwright、またはブラウザ拡張
目的は、Claude自身に成果物を検証させること。
Web系の作業をしてるなら、ここで一段変わります。作る、開く、崩れを見つける、直す、また開く。人間が挟まらなくなります。
第3段階：LinearまたはGitHub
目的は、仕事の入口と出口を繋ぐこと。
チケットから実装、PR、進捗更新まで。ここまで来ると、Claude Codeは「指示待ちのコーダー」から「仕事を自分で進めるメンバー」に変わります。
この3つで十分です。マジで。
必ず読んでほしい落とし穴
落とし穴1．MCPを増やすほど賢くなるわけではない
これが最大の勘違いです。
MCPを大量に繋ぐと、Claudeが選べるツールの候補が増えます。増えるとどうなるか。
どれを使うべきか迷う。文脈を食う。似たツールを取り違える。頼んでない操作をする。権限管理が複雑になって、何が許可されてるか自分でも分からなくなる。
100個繋ぐより、今の作業に必要な3つから5つだけ有効にする方が結果が出ます。プロジェクトごとに繋ぐものを変えるのが正解です。
（僕も一時期10個以上繋いでて、Claudeが変なツールを呼び続けて「なんで急にバカになったんだ」と思ってました。減らしたら直りました）
落とし穴2．読み取りと書き込みを最初から一緒にしない
導入初期にこの設計を必ず作ってください。
読み取りは許可。作成は確認を挟む。更新も確認を挟む。削除は拒否。本番操作は拒否。
特に、最初から全面許可すべきでないのはこのあたりです。本番デプロイ、DNS変更、顧客データの変更、決済の本番操作、Issueの削除、PRのマージ、データベースの削除。
MCPは便利さと危険さが完全に比例します。
落とし穴3．公式とコミュニティ製を混同しない
MCPの検索サイトには、同じ名前のサーバーが複数並んでることがあります。公式一覧に載っていても、それが提供元の公式実装とは限りません。
入れる前にここを見てください。
提供元の公式組織が管理してるか。最終更新はいつか。セキュリティポリシーがあるか。認証方式は何か。どこまでの権限を要求してくるか。削除や本番変更ができてしまう設計か。
権限を要求してくるものほど、慎重に見てください。
落とし穴4．外部から来た文章をそのまま実行させない
IssueやPRコメントを読ませて実装させる運用は強力ですけど、そこには他人が書いた文章が入ってきます。
「このIssueの手順に従ってください」と書いてある中に、余計な指示が混ざっていた場合、Claudeがそれを読んでしまう可能性があります。外部から来る入力を扱うMCPでは、そのまま実行させず、何をやろうとしてるかを一度提示させてください。
まだ固まってない領域
盛らずに書いておきます。
長時間ジョブをMCP経由で外部に投げる仕組みは、仕様としては正式に入りましたが、各サーバーが対応してるかは別問題です。仕様が公開されたことと、実装が追いついてることは違います。使う前に、そのサーバーの現在の対応状況を確認してください。
会話の中にUIを返す仕組みも、これから広がる段階です。今の時点で全部のMCPが操作画面を返してくるわけではないです。
あと、料金や提供条件はわりと動きます。この記事に載せた公式リンクは、使う前に一度見に行ってください。特に認証方式と権限範囲は、確認せずに繋ぐ場所じゃないです。
「MCPを入れると性能が何倍になる」みたいな数字も、僕は出しません。証明されてないので。
代わりに測るべきはこっちです。1日のうち、コピペと画面移動と目視確認に何分使ってるか。MCPで消えるのはそこです。
今日やること
全部やろうとしないでください。1つだけです。
自分の作業を思い返して、「Claude Codeと別の画面を、行ったり来たりしてる場所」を1つ探してください。
ドキュメントかもしれない。Issueかもしれない。エラー画面かもしれない。デザインかもしれない。
その1つを消すMCPだけを入れる。それで効果を体感してから、次を足す。
ボリスの原則は結局これに尽きます。Claudeに、自分の仕事を確認する手段を渡す。渡した瞬間から、Claudeは納得いくまで勝手に回り始めます。
止まってる間、あなたは今日も同じものをコピーして、同じ画面に貼り付けます。動いた瞬間、その往復は二度と戻ってきません。
今夜、Claude Codeを開いて、いちばん往復してる画面を1つだけ思い浮かべてください。
そこから、全部始まります。
