MCPの講座を最後まで見終わった瞬間、ToolもResourceもPromptも口では説明できるようになっていた。でも、いざエディタを開くと指が止まる。そんな経験で止まっている人は多い。
自分は10年以上現役でコードを書いていて、最近は副業で AI エージェントを自作運用している。新しいプロトコルを覚えるたびに思うのは、知識量と「作れる」の間には深い谷があるということだ。MCP も例外じゃない。
結論を先に置くと、その谷を渡す橋は 触る範囲を端から端まで広げること にしかない。小さくていいから、入口から出口まで通る 1 本のプロジェクトを作り切る。これをやった人とやってない人で、半年後の単価帯がガラッと変わる。
講座を受けても作れない壁は、知識じゃなくて『触る範囲』にある
講座は親切設計だ。Tool の章があり、Resource の章があり、Prompt の章がある。1 章ずつ理解すれば、その章の概念は説明できるようになる。これは正しい教え方なんだけど、副作用がある。頭の中で部品がバラバラに置かれた状態で講座が終わる。
実物のシステムは違う。GitHub から webhook が飛んできて、サーバーがリクエストを受けて、LLM にツールを呼ばせて、結果を整形して、別のサービスに投げる。この 1 本の流れに、Tool・Resource・Prompt が 同時に登場する。バラバラに覚えた部品を、ここで初めて 1 つの装置として組み立てる必要が出る。
部品の名前を覚えるのと、部品を繋いで装置を動かすのは、別のスキルだ。前者は数時間でも届くけど、後者は手を動かさないと永久に届かない。料理本を全部読んだけど一度も鍋を握ったことがない人は、家族の夕食を作れない。それと同じ構造だ。
元記事の著者の hugoferro 氏も、まさにこの壁を自覚していた。Anthropic と Hugging Face の MCP コースを 2 つ通しで受講して、最後の動画を見終わった時点で 自分のコードは 1 行も書いていなかった と書いている。Tool とは何か、Resource とは何か、Prompt とは何か、全部説明できる。でもエージェントシステムをゼロから組めるかは分からない。そこで「確かめる方法は 1 つしかない」と動き出した。
この自己診断ができる人は強い。「説明できる ≠ 作れる」と切り分けられた瞬間、次の一歩が明確になる。あいまいに「もう少し勉強してから」と言い続けている間は、触る範囲がいつまでも広がらない。
MCPを1本通しで触ると、ToolもResourceもPromptも『役割の違い』で腑に落ちる
概念を別々に覚えていると、どこで何を使うか判断する時に毎回迷う。「これは Tool にすべきか Resource にすべきか」が、答えではなく好みの問題に見えてしまう。1 本通しで触ると、この迷いがほぼ消える。
hugoferro 氏が題材に選んだのは、GitHub リリースが publish された瞬間に webhook を受け、Claude が生のチェンジログを読んで整ったリリースノートに書き直し、ReportLab で PDF を生成して、Discord チャンネルに直接配信するパイプラインだった。20 パートに分けた README として、手順を最初から最後まで人に教えるつもりで書いている。
ここで Tool は「外の世界に副作用を起こす行為」を担当する。Discord に投稿する、PDF を生成する、GitHub の API を叩く。動詞 だ。Resource は「LLM が読みたい素材」を担当する。チェンジログの本文、過去のコミット履歴、テンプレート。名詞 に近い。Prompt は「この素材をこういう方向で読め」という指示書を担当する。役割を分けて装置を組むと、どの登場人物がどの仕事をしているかが、説明じゃなく 手触り で分かる。
この腑落ちは、講座を 3 周しても起きない。1 本通すと 1 回で起きる。安いコストで効くから、最初にやるべき投資はここだ。
サーバー側・クライアント側・LLM側で見える景色がそれぞれ違う
もう一段深い話をすると、同じ MCP でも立っている場所によって見えている景色が違う。
サーバー側: Tool / Resource / Prompt を「外に公開する」立場 クライアント側: サーバーに接続して、提供されたものを「呼び出す」立場 LLM 側: tool_use_id で呼び出しと結果を「紐付ける」立場
hugoferro 氏が「tool_use_id がなぜ大事か説明できないなら、本当には理解していない」と書いていたのは、ここに直結する。LLM が複数のツール呼び出しを並行して出した時、どの結果がどの呼び出しに対応するかを ID で固定しないと、対話が壊れる。これはサーバー側の設計図を眺めていても気付かない。クライアント側で実際にレスポンスを受け取って LLM に戻す処理を書いた瞬間、必要性が肌で分かる。
自分の手元でも、自作の知識管理用 MCP サーバーをローカル環境で常駐起動させて、Claude Code から直接呼び出せるようにする仕組みを組んだ。サーバー側のコードを書いている時は「Tool を公開する」感覚しかないんだけど、クライアントからの呼び出しを実装した瞬間、初期化のタイミングや stdio の流れ が全部 1 本に繋がって見えた。バラバラに勉強していた時には絶対に来なかった視界だ。
通したから見える、というのはこういうことだ。実装して、テストして、待って……動いた。短文を畳みかけたくなる瞬間が、講座のどの章にもない場所で待っている。
小さな貫通プロジェクトは、受託案件の練習場として一番安い
ここから先は AI × ものづくり領域で独立や副業を狙っている人向けの話になる。MCP を「とりあえず触っておく」ことの実利を、もう少し計算高く考えたい。
大きな受託案件をいきなり取りに行くと、技術リスクが詰む。一方で勉強だけ続けても、ポートフォリオが残らない。間を取る最適解が、小さくても端から端まで通った貫通プロジェクト を 1 本作って、それを公開しておくことだ。
hugoferro 氏の MCP リリースノート配信ツールは、機能としてはシンプルだ。GitHub → Claude → PDF → Discord。たったこれだけ。でも、これを 20 パートの README にまとめて公開しているという事実が、技術的な深さよりも遥かに強いシグナルになる。「この人は端から端まで責任を持って繋げる」と一目で伝わるからだ。受託で発注する側が一番不安なのは、途中で技術が止まることであって、最先端じゃないことじゃない。
さらにこの方式は、自分の理解の穴を炙り出してくれる。教えるつもりで書くと、「ここは何となく動いているけど説明できない」というポイントが必ず出る。これを 1 つずつ潰すと、その領域での実装力がきれいに底上げされる。3 時間かけた章が 5 分の読書で済む読者には申し訳ないけど、書く側のリターンは大きい。
あと、案件化を考えるなら ターゲット領域を絞った貫通プロジェクト にすると効果が跳ねる。汎用的なリリースノート配信ツールよりも、たとえば「Unity プロジェクトのアセット更新を MCP 経由で AI に整理させて Notion に書き戻す」のように、自分が取りたい案件の周辺を最初から狙う。練習場と営業資料を兼用させる発想だ。
AI × ものづくり領域でMCP一本通しが効く具体的な接続先
creator 軸で動いている読者なら、MCP 一本通しの経験は次の領域で直接的に効く。一般論じゃなく、案件として出てきうる接続先を具体的に並べておく。
Unity × LLM の NPC 会話。Unity の C# から MCP サーバー経由で LLM に話しかけ、応答を NPC のセリフに流す経路は、ゲームジャム規模でも企業案件でも需要が増えている。会話履歴を Resource として渡し、行動決定を Tool として呼ばせる設計は、まさに MCP の役割分担と相性が良い。自分で 1 本組んだ経験があると、設計レビューで具体的なツッコミができる。
VRChat ワールド × AI キャラ常駐。OSC や外部 API を経由して、ワールド内のキャラクター挙動を LLM に駆動させる構成は、MCP で整理し直すと拡張性が一段上がる。新しいツールやサービスを足したい時に、共通プロトコルで繋いでおくと毎回独自実装する手間が消える。
AIVTuber の周辺ツール統合。OBS、わんコメ(OneComme)、各種音声合成、メモリ管理、配信ログ集計、外部 API。AIVTuber のバックエンドは異種ツールの寄せ集めになりがちで、MCP で抽象化しておくと差し替えが楽になる。配信者からの「これも繋ぎたい」が来た時に、対応コストが見積もれる側に立てる。
Godot や UE などゲームエンジンへの汎用組み込み。エンジン側で MCP クライアントを 1 つ持っておけば、AI ツール側の進化に追従しやすい。長期保守の案件ほどここが効く。
この分野は、AIVTuber 開発支援・AI NPC 実装受託・VRChat ワールド受注・Unity × LLM 連携実装といった案件が、今まさに動き始めている。小さくても貫通プロジェクトを 1 本持っている人から順に声がかかる構造なので、早めに手を動かしておくと独立の武器になる。
まとめ：手を動かす範囲を『端から端まで』にした人だけが次の単価帯に行く
3 行にまとめる。
講座で知識は十分に揃う。詰まるのは知識じゃなく触る範囲だ 小さくていいから入口から出口まで通る 1 本を作り、教えるつもりで文章化する 通した範囲が、そのまま次の単価帯への切符になる
MCP は単独の技術トピックじゃなくて、AI と外の世界を繋ぐ共通言語になりつつある。今のうちに 1 本通しの感覚を握っておくと、来年の案件選びで選択肢の幅が違ってくると思う。すごく。
参考
【PR】関連ツール・サービス
副業や独立で AI 開発をやるなら、まず手元のサーバー環境とドメインだけは早めに押さえておくと身動きが取りやすくなります。
XServerショップ は WordPress や検証用 VPS をまとめて立てられて、ポートフォリオサイトの起点として便利です。
.com/.net ０円〜 は屋号や案件用ドメインを早めに押さえたい人向け。空いている文字列は減り続けているので、検討中なら一度覗いておくと安心です。
DMMブックス は AI / ゲーム開発系の技術書を試し読みしながら拾えるので、新しい領域に手を出す前の地ならしに使いやすいです。
ブログ更新情報や開発の裏側は セレネのX (@selene_nyx_ai) で発信しています。AI × ものづくりの話に興味があればフォローしてもらえると嬉しいです。
【PR】おすすめの書籍
記事の内容に関連する書籍を紹介させてほしい。
Claude Codeを使った開発の流れを実用面から整理した一冊です。プログラミングを学びながら手を動かす場面で、コード周辺の作業設計を考える参考になります。
Claudeの基本的な使い方を短時間で押さえるための入門書です。AIを業務や副業に取り入れたい方が、最初の地図を描くきっかけとして手に取りやすい構成です。
コメント