最近よく聞くMCP。
ここ数週間いろいろな記事や情報に触れて、筆者のザリガニ脳で理解できた範囲において記事にしていきたいと思います。
- ※筆者の備忘録・キャッチアップ記録的な側面もあるので随時更新していく予定です
- ※記事の公開当初はMCPのみに絞っていましたが、MCP単体より「AI関連の包括的な情報まとめ」の方が
（主に筆者にとって）有益なので徐々に記述範囲が広がってきています
例えば、プロンプトとか、A2Aとか、Vibe Coding とか、活用方法とか、and so on...
今後も広げていく予定（は未定）
技術的な掘り下げとか、具体的な作成方法や構築などには一切触れません。
簡易な「ちょっと知りたい」人向けに書いていきます。
この記事を踏み台にして、他の有益な具体例が載った記事・情報を抵抗なく読み進めてもらえるようになると嬉しいです。
MCPとは
一言でいうと「生成AI（※厳密にはLLM）と外部サービスを連携することで、生成AIが自動・自律的に働いてくれる仕組み」です。
少しだけ踏み込むと以下が特徴になります。
- 生成AI（
Claudeなど各種LLM）が外部サービス（例：GitHubやPostgreSQL（外部のデータベース）、社内ファイルシステム）と連携できる規格 - 連携することで生成AIが連携先情報を活用して自律的に働いてくれる機能（＝AIが自動・自律的に他のソフトウェアやサービスを操作できる仕組み）
MCPで何できるん？
- 生成AIにブラウザでの情報収集を手軽にお願いできて、それらをまとめてくれたり、それらをもとに期待するネクストアクションまでしてくれる
-
GitHubで一例を挙げると 「当該リポジトリの内容を（読み取って）参照し、『○○な機能を追加して～』や『△△を改善・リファクタリングして～』といったこと」 が可能となる -
Figma
Figma MCPと連携させて簡易なLP制作（※保守や更新がないような作りきりページ）
MCPと少しだけ離れますが上記活用例に出てくるFigmaでいうと、以下のAI活用記事に豊富な知見が掲載されています
1-2. Figma Raw
FigmaのデザインをJSON形式で出力できるプラグイン「Figma Raw」も試してみました。このプラグインは、Figmaのレイヤー構造やカラー、フォントサイズなどのスタイル情報を含んだJSONを出力できるのが特徴です。
使い方はとてもシンプルで、Figma上で対象のFrameを選択し、プラグインを実行するだけ。環境依存せず、MCPのようなセットアップも不要なので、さまざまなAIと柔軟に組み合わせて活用できました。
上記「Figma Raw」や「画像・クリエイティブ生成」、「Figma Make」などデザイン領域におけるAI活用の豊富な知見がまとめられており、活用例をイメージしやすくなっています
MCPの活用例
記事内の「ガイドラインやヘルプの検索機能」や「カスタマーサポート業務での活用」など参考になります。
かなり具体的なMCP（サーバー）の活用例が記載された記事です。
E2Eテストでの利用参考となる記事です。しかし以下引用のような注意事項もあります。
Playwright MCPは、E2Eテスト設計を目的として導入しました。
GitHub MCPと同様に、テストシナリオ生成時のプロンプトに制約条件を設けて調整しました。
しかし、URL, class名などを間違えるなど精度があまり高くない点と、消費トークンが多く途切れる上にリトライもできない点が課題となっています。
後述するtoolというMCPサーバーが提供する機能（処理・振る舞い）を設定するための記述（※記事内のコードserver.toolの部分）が分かりやすい記事でした。
server.tool(
// 第1引数 : MCP経由でAIやクライアントがこのツールを呼び出すときに使う名前
"get-alerts",
// 第2引数 : このツールが何をするものかをAIに伝えるための説明
"Get weather alerts for a state",
// 第3引数 : ツールが受け取る「引数のスキーマ定義」(バリデーション)
{
state: z.string().length(2).describe("Two-letter state code (e.g. CA, NY)"),
},
// 第4引数 : 実際にツールが呼び出されたときに実行されるロジック
async ({ state }) => {
const stateCode = state.toUpperCase();
const alertsUrl = `${NWS_API_BASE}/alerts?area=${stateCode}`;
const alertsData = await makeNWSRequest<AlertsResponse>(alertsUrl);
if (!alertsData) {
return {
content: [
{
type: "text",
text: "Failed to retrieve alerts data",
},
],
};
}
const features = alertsData.features || [];
if (features.length === 0) {
return {
content: [
{
type: "text",
text: `No active alerts for ${stateCode}`,
},
],
};
}
const formattedAlerts = features.map(formatAlert);
const alertsText = `Active alerts for ${stateCode}:\n\n${formattedAlerts.join("\n")}`;
return {
content: [
{
type: "text",
text: alertsText,
},
],
};
},
);
情報収集する中で、個人的に普通のチャット形式の使用と比較して便利そうと感じたところに「生成AIがコンテキストなど背景情報を理解して行動してくれる」という部分があります。
例えば、チャット形式だと時には細かくプロンプトを記述する必要があったり、必要情報（各種ファイルなどリソース）を適宜提供する手間があります。
しかし、MCPではそういった手間から解放されます。
なぜなら生成AIが（情報取得元と連携していることで）必要な情報をすでに持っているためです。
そして、これら機能を得る（恩恵にあやかる）には生成AIに加えて、MCPホストとMCPクライアント、MCPサーバーが必要となります。
MCPってどう使うん？
（生成AIに加えて）MCPホストとMCPクライアント、MCPサーバーが必要となります。
MCPホスト, MCPクライアント（操作指示窓口）
MCPクライアントとは 人間とAIモデルとの仲介ポイント（操作指示を行うための窓口） と言えます。
これは後述のMCPサーバと1対1の関係になります。
そのため、複数のMCPクライアントを管理する役割としてMCPホストがあります。
MCPホストは今説明したMCPクライアントを包括管理するものです。
MCPクライアントを「操作指示リモコン」として例えると、MCPホストは各種リモコンを一元管理する大元リモコンのような存在です。
プログラミング領域で言うと、Claude Desktop, Cline, CousorのようなAIコードエージェンシー（コーディング・プログラミングを補佐または主導してくれる機能）を指します。
これらをMCPサーバー（連携先の外部サービス）と接続することで、先に説明したような機能拡張を実現できるのです。
ちなみに、AIのアクション（AIが自律的に行う処理や操作など）に対して詳細な設定や行動規定を設けるrulesというものがあります。
以下のリポジトリが作成参考例としてすごく分かりやすかったです。
MCPサーバー（外部サービスとの連携に必要な中継点）
GitHub, PostgreSQL, ファイルシステムなど 生成AI（各種LLM）と連携する（機能を備えた）接続先との仲介ポイント と言えます。
例えると、OSとアプリケーションの間にあるミドルウェアのようなものと筆者はイメージしています。
重要なのは連携する機能を備えている必要があるということです。
「じゃあ社内のこのシステムにすぐ使おう！」とはいかないと思います。
それをするには適したMCPサーバーを自作するか、サードパーティ（他人が制作・公開した）のMCPサーバーを見つけてエージェント（MCPクライアント）にそのMCPサーバーを教えてあげる（登録する）ことで期待した処理を実現できると思います。
※連携させたいシステムがMCPサーバーを備えている場合はそちらを利用すべきです。
例えば、LINEやGitHubとか自身のMCPサーバーを提供しています。
MCPサーバーにはtoolという「そのMCPサーバーができる処理リスト」のようなものがあります。
端的に説明すると、「自分（MCPサーバー）はこんな機能を持っています」とMCPサーバーが情報提供していて、
もし気になるものがあれば「エージェント（MCPクライアント）にそのMCPサーバーを登録して使ってみる」といったものになります。
何だか日常的なショッピングとかに似てますね。
脱線：MCPの通信方式について
MCPクライアントとMCPサーバーの通信方式には現状以下の3つがあります。
-
Stdio- 安全かつ高速。ローカルでの開発や、ネットワークを使いたくないセキュリティ重視のケース向け
- ネットワークを介さずプログラム同士が直接テキストデータをやり取りする
-
Streamable HTTPトランスポート- 現在のMCPで推奨されている通信方式
- 大きなデータやリアルタイム性が必要なケース向け
- 後述の
HTTP+SSE方式よりもシンプルで柔軟 - サーバーが単一の
HTTPエンドポイント（例：/mcp）を提供 - クライアントは
HTTP POSTでリクエストを送信し、（サーバー）レスポンスはストリーミング（分割送信）で返される
-
HTTP+SSE- 現在は
Streamable HTTPトランスポートを利用推奨 - リアルタイムなデータ配信や、ChatGPTのように文字が徐々に表示されるようなケース向け
- クライアントがHTTPリクエストでサーバーにアクセスし、サーバーからはSSEで複数のメッセージをストリーミング（サーバーからクライアントへの一方向通信）
- 現在は
ほんで、MCPってどう使うん？
MCPクライアントとMCPサーバーを接続（連携）することで利用可能
ただし原則として、MCPクライアントに使用（＝MCPとして動かす・処理能力を担う）するための生成AIのAPIキーが必要となります。
このAPIキーは、ベース料金およびトークンの使用量に応じた従量課金制なのが一般的です。
Geminiは（いつまでかは不明だが）現状無料です！ Google AI Studio 経由でAPIキーを発行できます。
その他AI関連の情報まとめ
プロンプト
生成AIの出力（期待する生成結果）を左右するのがプロンプト（生成AIへの命令文）です。
プロンプトに関することを網羅的かつ分かりやすく説明して下さっているのが以下の記事になります。
記事内の「3. よく使われるプロンプトエンジニアリング手法」とか、超初心者向けの本記事から脱線してしまうのですが勉強になるので関心のある方はご覧ください。
プロンプトをはじめ、昨今のAI活用情報を日々漁っていて気付いたことに以下フローが目立ってきている気がしました。
- アイデアをゼロショット（1〜3行程度の簡素なプロンプト）で出してAIと壁打ちしながら、ある程度進んだタイミングで対話内容をAIに要件定義としてまとめてもらう
- その要件定義をもとに（同じかまたは別の）AIエージェントに投げて作成してもらう
- タスク・粒度は小さく
- 可能な限りFigmaでモックアップを作っておくなどAIが参照できるソースを用意しておく
- 実装の区切りを見つけてコンポーネントや処理、使用ライブラリ情報などを随時ドキュメント化してもらう
- 要件定義など関連ドキュメントもAIに適宜更新してもらう
- プロンプト例：ここまでの実装を通して、プロジェクト全体を把握した上で差分検知してドキュメントに反映して
- 以降は
指示 -> 修正 -> ドキュメント化 ...というイテレーションでクオリティを高めていく
AIと協業する中で、明確な達成目標または課題（＝何がしたいのか）と、彼らにタスクを依頼する際の実装アプローチ（＝設計メソッドまたは設計力）が重要だと日々感じます。
例えば、機能実装や追加修正において補足情報または実装イメージがしっかりしないとうまく指示を出せないでしょう。
具体的には、スタイル修正においてドロップシャドウやブラー、処理実行においてマウスオーバー、キーダウンなどの用語を知っていないと適切かつ端的な修正指示ができない、といったことです。
その他も、CRUD機能やデータベースの種類、データベースを用いない簡易なデータ管理方法（localStorage）など、目標達成／課題解決するための要件定義や技術選定など上流工程に関わってくるような「つまり何がしたいのか」を具体的に伝達できる前提知識が必要だと思います。
脱線：AIにコーディングしてもらう時は pit of death に注意
AIフレンドリーとなるようプロンプトに配慮してAIにコーディング依頼しても、いずれpit of deathにぶつかる可能性があります。
-
pit of death
AIがエラーから抜け出せず同じ失敗を繰り返したり、詰まったりする頻度が増えたりする現象。これを復帰させるには、人間の開発者の手による修正が必要となる。
CursorやClineでAIにコーディングさせていると、いずれpit of death（エラーから抜け出せない、同じ失敗を繰り返す、etc・・・）が訪れます。これを復帰させるには、人間の開発者の手による修正が必要です。
pitから復帰させると、大抵の場合、そう進まないうちに次のpitにハマります。そしてアプリケーションが複雑になるほど、pitの間隔は短くなっていき、より開発者の介入が必要になります。
pit of deathを減らすには
- タスクのスコープを狭める
- 1つのタスクあたりのステップ数を少なくする
- 生成の特性を知る
- 現時点の生成AIは既存内容の修正が苦手で、基本的にスクラップ・アンド・ビルドのような生成の仕方（0→1）をするそうなので、ケース・バイ・ケースでプロンプトの内容や実装方針を変えてみたりする
プロンプトの内容や実装方針を変えてみたりする上では、Temperatureという数値調整（0〜1）が役立つかもです。
（Google AI Studio以外ではあまり見たことがないのですが）Temperatureで創造性や回答の多様性をコントロールできます。
-
創造的なアイデアが欲しいとき:
Temperatureを 0.7〜1.0 に設定 -
正確な回答（ファクトに基づく）を求めるとき
Temperatureを 0.0〜0.3 に設定
A2A：Agent to Agent（AI同士の円滑なコミュニケーションを実現する仕組み・規格）
A2A：Agent to Agentは、「人- AI」ではなく「AI - AI」向けの規格です。
ここまでの説明を経てMCPとは、人間がうまく扱ってどうこうするというよりも、生成AIが動きやすくなるためのブースター機能（AI向けのツール）のようなものだと解釈もできます。
つまり、AIが効率的に働ける環境があればパフォーマンスをより発揮できるようになるのです。
現状、色々な生成AIやコードエージェンシーがあり、当然それらは各々の仕様を持っています。
そういった（異なる）AI同士による円滑なコミュニケーションを実現するのがA2Aです。
MCPとA2Aは競合というより相互補完な関係となります。
Vibe Coding
ちなみに "Vibe Coding"（雰囲気コーディング）というのは、「人間が音声やテキストで指示を出し、AIが主体となってコードを書くコーディングスタイル」を指すワードです。
上記記事では、以下記述のように複数のAIをフェーズごとに使い分けるAIを併用した活用事例としても大変勉強になる内容でした。
- 要件定義
ツール: ChatGPT 4o
成果物: 要件定義.md
- 技術選定
ツール: ChatGPT 4o
成果物: 技術選定.md ディレクトリ構成.md DBテーブル設計.md API仕様.md など
- コードベース作成
ツール: Claude Code
成果物: 環境構築、各アプリケーションの動くコード
個人的にVibe Codingするときに唯一バイブスに身を委ねないのがGit管理です。
「さっきいい感じだったのに今の指示でめちゃくちゃになった！」みたいなことがよくあるので、いい感じになったらすかさずコミットしてます。
先に述べたように現時点の生成AIは都度0→1生成する傾向にあるので、良かった時（状態）に差し戻せるように適宜Git管理しておくのは貴重なTipsですね。
- 微調整
ツール: Cursor
成果物: 最終的なアプリケーション
ちなみに、AIのアウトプットに自分が手動で手を加えると、コンテキスト上で認識されていなくて次の生成で元に戻されちゃうことがよくあります。なので手を加えたときは「調整したので認識してください」って言っておくと戻されなくなります。へたに手を出すほうが手がかかる感…
上記に関しては今後進歩していく上で修正されていきそうですが、現段階では十分に留意しておきたいことな気がしました。
さいごに
先に述べたように、この記事を踏み台にして、他の有益な具体例が載った記事・情報を抵抗なく読み進めてもらえるようになると嬉しいです。
もし間違っている部分などありましたら、筆者の後学のためにもお教えいただけますとありがたい限りです。
ここまで読んでいただき、ありがとうございました。
参考情報集
※個人的に上記「MCP入門」がすごく分かりやすかったです。
※非エンジニアにも拡大できそうな「日々の振り返り」や「タスク管理」など業務アシスト関連での利用実施の参考になる記事です。
蛇足
正直、筆者からすると「生成AI関連は異常な速度で進歩している」印象です。
何なら数ヶ月前の情報が陳腐化していたりとか……、まじか、みたいなの普通にあります。
そうした中で筆者が必死（のつもり）で情報を追っている理由は「現状、AIに関する形式知と暗黙知を蓄積する戦略を採っていきたい」という考えがあります。
理由としては、（自分たちにとって）適切な使用イメージを掴むためには汎用性のある知見（形式知と暗黙知）の充実が大事になってくると思うためです。
例えば、「パソコン（またはスマホ）を使って何かして」と言われれば現代人は調べ物をしたり、資料作成など仕事に用いたりするといった使用イメージを苦もなく描けるはずです。
これは、多くの人がデジタルデバイスの利用が当たり前となって形式知と暗黙知が充分にあるからできることです。
この点はAIも同じだと思います。
そして、この先は ものごと（例：未知の課題やビジネスアイデアなど）へのアプローチを考える「問題把握力と問題想起力」がより重要 となるのでは？と考えています。
人と人とのコミュニケーションが必要な部分以外においては、課題解決力など実務面はAIが担っていくと考えられるので、人はものごと及びそれへのアプローチを考える役割が強くなりそうだと。
先に述べた問題把握力と問題想起力とは、課題解決における方針や仮説出し、アプローチ方法の選定など上流工程部分に関わってくるようなもの、と想定しています。
具体的には以下です。
-
問題把握力
どこにどんな問題があるかのアタリを付ける（アプローチ範囲を設定する） -
問題想起力
何がペインまたはボトルネックかを考える
上記のような「問題の切り分け方法」といったエンジニアリング以外に関する事柄については以下の記事が参照になりました。
そして、今後スタンダードとなるAIを活用した働き方（AIとの協業）においては、以下の「基礎知識」と「AI活用の知見」が重要となると考えています。
例えば、これまでの「Pythonを学ぶ」や「Nextを使ってトレンドに追従」という基礎学習となる部分に加えて、AI活用の学習が必要となるので学ぶ量が倍増すると思いますorz。
- 基礎知識
- サイトが表示される仕組みや通信などWeb・インターネットに関する土台となるような部分
- JavaScript（TypeScript）, Python, Go, PHP といった言語
- React/Next, Vue/Nuxt, Django, Flask , Laravel などのフレームワークの学習
- AIが生成したコードの安全性をチェックするためのセキュリティ関連の知識
- AI活用の知見
- プロンプトエンジニアリング（※進歩の仕方によっては不要となるかも）
- 各種生成AI（LLM）の特徴（例えば、検索系は
Perplexityとか） - MCP, A2A, Vibe Coding などトレンドのキャッチアップ
- 他者や他企業の活用事例（Tips）の収集と、自身や自社への還元方法の想起など
この蛇足で述べたことに関して、何か貴重なご意見やお考えがあって「コメント残してもいいか」と思ってくださる方は知見共有いただけますとありがたく存じます。
おしまい。