MCPサーバー自作は簡単？でも認証の3つのMUSTは外せない

📺 この記事は YouTube チャンネル きなこもっちーのテック深掘り の動画解説記事です。
▶️ 動画はこちら → MCPサーバー自作は簡単？でも認証の3つのMUSTは外せない

🐹🦜 この記事に登場する2匹

• 🐹 もっちー （ハムスター）… AI はまだ勉強中。「それどういうこと？」と素朴に質問する生徒役
• 🦜 きなこ （セキセイインコ）… AI で調べものをこなす解説役。やさしく深掘りして教える先生役

この記事は2匹の掛け合いを書き起こした形式です。発言の先頭にいる絵文字＋名前が話者です。

はじめに

🐹 もっちー「MCPって最近よく聞くけど、大企業のエンジニアが専門知識を総動員して使う難しい仕組みってイメージなんだよなあ」

🦜 きなこ「大企業しか使えない、って思う気持ちはよく分かるよ。今までは接続の仕組みそのものがかなり複雑だったからね」

🦜 きなこ「その感覚、実はもう古いんだよ。2026年7月28日にMCPの仕様が変わって、状況がかなり変わったの」

🐹 もっちー「え、仕様が変わったって、ぼく全然知らなかったよ…」

🦜 きなこ「無理もないよ、公式が正式に発表したのはつい先月のことだから。ここからじっくり中身を一緒に見ていこうね」

🦜 きなこ「双方向でずっと接続を保つ仕組みだったのが、リクエストごとに完結するシンプルな形に作り直されたんだよ」

🐹 もっちー「根っこから変わったってことだよね？それって結構大きな話じゃん」

🦜 きなこ「うん。しかも実装のハードルも同時に下がってるの。ただ認証で外しちゃいけない3つのMUSTがあって、そこを踏み外すと簡単に事故る」

🐹 もっちー「3つのMUST…？なんか怖い響きやん」

🐹 もっちー「実装が簡単になったのは嬉しいけど、簡単になった分どこかにしわ寄せが来てそうで、ちょっと身構えちゃうな」

🦜 きなこ「その勘、悪くないよ。実装が簡単になった分、しわ寄せは認証のところに全部寄せられてるの。だから今日はそこを一番の重点にして丁寧にやっていくね」

🦜 きなこ「何が変わって、今からMCPサーバーを作るなら実際どう書けばいいのか、公式ドキュメントの原文つきで3つのMUSTまで含めて順番に見せていくね」

仕様の中身、実は別物になっていた

🐹 もっちー「ねえきなこ。MCPってさ、つなぐ前にお互い挨拶して、それから会話を始める仕組みだよね。ぼく、前に教わったときそう覚えたんだけど、それで合ってる？」

🦜 きなこ「うん、その覚え方ね、少し前までは完全に正解だったの。でも今の最新の仕様書を開くと、その挨拶のところがもう載ってないんだよ。私も最初は見落としかと思って二度見した」

🐹 もっちー「えっ、載ってないの？ぼくが覚えたやつ、どこ行っちゃったのさ。まだ新しい話のつもりでいたのに、ぼくのおぼえた分、まるっとムダになっちゃった？」

🦜 きなこ「ムダじゃないよ。まずね、MCPの仕様はバージョンが数字じゃなくて日付で管理されてるの。前の安定版が2025年11月25日で、いまの最新が2026年7月28日なんだよ」

🐹 もっちー「日付？バージョン1.0とか2.0みたいなのじゃないんだ。ぼく、数字がだんだん増えていくやつしか知らなかったよ。日付にすると何かいいことあるの？」

🦜 きなこ「いつ時点の話かが一発で分かるの。それでね、この7月28日版で、イニシャライズっていう最初の握手と、セッションIDを持ち歩くヘッダが、どっちもきれいに廃止されたんだよ」

🐹 もっちー「えっ、セッションIDってやつ、ワイついこないだ覚えたばっかりやで！それがもう廃止てどういうことやねん。ワイの記憶の賞味期限、短すぎるやろ！」

🦜 きなこ「気持ちは分かるよ。公式ブログにはね、双方向でステートフルなプロトコルから、リクエストとレスポンスのステートレスなプロトコルへ変わる、ってはっきり書いてあるの」

🐹 もっちー「ステートフルにステートレス…ごめん、ぼくには完全に呪文だよ。要するにさ、こっちのことを覚えててくれる係の人が、いなくなっちゃうってこと？」

🦜 きなこ「近いね。前は最初に握手して、そのやり取りの続きをずっと覚えててもらってたの。今は一回のお願いだけで話が完結するから、そもそも覚えててもらう必要がないんだよ」

🐹 もっちー「あー、受付で名前を覚えてもらうのをやめて、毎回ぜんぶ紙に書いて窓口に渡す感じか。ちょっと手間だけど、それならぼくでもなんとかイメージできるや」

🦜 きなこ「そう、その手間の代わりに大きな得があるの。同じ機械に戻らなくてよくなるから、順番にぐるっと配るだけでよくて、どのサーバーが受け取ってもちゃんと動くんだよ」

🐹 もっちー「じゃあ混んでる時は空いてるところに回せるんだ。お店で言うと、どのレジに並んでもいいようにして行列をさばく感じでしょ。それは確かにお店側も楽そう」

🦜 きなこ「うん、負荷分散がぐっと楽になるの。それともうひとつ、つなぎっぱなしにする古いHTTPプラスSSEっていう通信のやり方も、この版で正式に非推奨になったんだよ」

🐹 もっちー「えっ、非推奨って、もう使っちゃダメってこと？今それで動かしてる人は、ある日いきなり止まっちゃったら大変じゃない。ぼくだったら絶対泣くよ」

🦜 きなこ「そこは大丈夫、まるっと一年の移行期間つきなの。ここまでで仕組みが変わったのは分かったよね。でも実装のハードルまで下がったって話は、実はもっと意外なの」

型注釈だけでtoolになる — 最小実装

🐹 もっちー「実装のハードルが下がったって言われても、専門の人が何日もかけてやる大仕事ってイメージが抜けないんだけど」

🦜 きなこ「じゃあ実物を見せるね。公式のPython SDKはmcpってパッケージで、Python 3.10以上あればすぐ始められるんだよ」

🐹 もっちー「そもそもtool登録って何をすること？AIが使える道具の棚に自分の関数を並べる作業、って理解でいい？」

🦜 きなこ「その理解で合ってるよ。今までその一覧のために、JSON Schemaって仕様書を手で書いてたんだよ」

🐹 もっちー「え、そのJSON Schemaってやつ書かんでええの？ワイあの波カッコずらっと並んだやつ見ただけで眠となるねんけど」

🦜 きなこ「書かなくていいの。関数の上に@mcp.tool()って一行足すだけ。解析コードも検証コードも一行も要らないんだよ」

🐹 もっちー「デコレータって、ケーキにいちごをちょこんと乗せるみたいなイメージなんだけど、合ってる？」

🦜 きなこ「近いかも。関数に「これはtoolだよ」って目印を貼るだけの一行。中身は普段書いてるPythonのままでいいんだよ」

🐹 もっちー「うーん、まだ半信半疑だなあ。実際に動くコードを画面に出して見せてほしいな」

🦜 きなこ「公式READMEの例だとこう。@mcp.tool()の次の行に def add(a: int, b: int) -> int。これだけで終わりなんだよ」

🐹 もっちー「え、待ってよ。ただの足し算の関数じゃん。入門書の一番最初のページと何も変わってないよ」

🦜 きなこ「呼べるの。この一行が付いてるだけで、普通の関数の三か所がAIから見える形へ自動的に変換されて登録されるんだよ」

🐹 もっちー「三か所？どことどこなの？順番にひとつずつ教えてほしいな」

🦜 きなこ「まず関数名のaddがそのままtoolの識別子になるの。二つ目がdocstring、関数の下に書く説明文なの」

🐹 もっちー「え、コメントみたいに気軽に書く説明文が、AI向けの取扱説明書になるってこと？びっくりだよ」

🦜 きなこ「そういうこと。三つ目が型ヒントで、a: intの部分がそっくり入力スキーマになるんだよ」

🐹 もっちー「ちょっと待って。関数から説明書まで自動で作るなんて手が込んだ仕組みだよね。それって誰が用意してくれてるの？」

🦜 きなこ「FastMCPっていうフレームワークなの。公式のPython SDKはこれがベースになってるんだよ」

🦜 きなこ「言語もPythonだけじゃないの。TypeScriptなら@modelcontextprotocol/sdkで、Node.js 18以上あれば同じ最小構成が組めるんだよ」

🐹 もっちー「できたサーバーって、AIとはどうやって繋がるの？そこだけ点と点が繋がらなくてモヤモヤしてるんだ」

🦜 きなこ「繋ぎ方はトランスポートっていうの。Python SDKはstdioとStreamable HTTPとSSEの三つに対応してるんだよ」

🐹 もっちー「こんな簡単でええんか…って思ったけど、簡単やからこそ危ないとこあるんちゃう？なんや嫌な予感がしてきてんねんけど」

簡単さの裏にある3つのMUST

🦜 きなこ「もっちー、鋭いね。正直に言うとね、私も最初は認可の章を後回しにしてたの。あとで読めばいいって見立てが甘かったんだよ」

🐹 もっちー「えっ、きなこが後回しにするって相当やん。ワイ、さっきまで浮かれてたのに急に背筋が寒なってきたで」

🦜 きなこ「そう、ここが今日いちばん大事なところ。関数一個で動くからこそ、認証を素通りさせやすいの。MCPの認可はOAuth 2.1がベースなんだよ」

🐹 もっちー「オーオースって、アプリで「アクセス許可しますか」って出てくる、あの画面のことだよね？」

🦜 きなこ「うん、あの仕組みの新しい版なの。仕様ではMCPサーバーがトークンを守る側、クライアントが持ってくる側って役割が決まってるんだよ」

🐹 もっちー「守る側と持ってくる側で、役割がきっちり分かれてるんだね。守る側のMCPサーバーは何をどこまで確かめればいいの？」

🦜 きなこ「そのうえで公式は、大文字のMUSTで「絶対に守れ」って条件を三つ置いてるの。ここを外した瞬間に事故になる、いちばん危ないポイントだよ」

🐹 もっちー「三つもあるの？さっきまで「デコレータ一個で完成」って喜んでたのに、急に話が重たくなってきたんだけど」

🦜 きなこ「一つ目はトークンのパススルー禁止。仕様の原文は「自分に発行されたトークン以外を受け取ってはならない」なの。MUST NOTだよ」

🐹 もっちー「お客さんから預かった鍵をそのまま奥の金庫に挿したらアカンってことか。それワイやったらそのまま使い回してるやつやん」

🦜 きなこ「まさにそれ。社内APIを叩くときは、クライアントの鍵をそのまま渡さず、上流の認可サーバーが発行した別のトークンを使わないといけないの」

🐹 もっちー「クライアントの鍵と社内APIに出す鍵は完全に別物ってことやんな。そのまま渡しても動いてまうから気づかへんやつやで」

🦜 きなこ「弾いたあとの作法も決まってるの。ツール側の失敗はisErrorってフラグと理由の文章で返して、知らないツールを呼ばれたらJSON-RPCのエラーコードで返すんだよ」

🐹 もっちー「ただ失敗した、で突き放さへんのやな。門前払いするときも理由の紙を渡す感じか。黙って追い返したら誰も直しようがないもんな」

🦜 きなこ「二つ目はaudienceバインディング。RFC 8707に従ってトークンが自分宛か検証して、違うものは必ず拒否しないといけないの」

🐹 もっちー「宛名が自分じゃない宅配便は受け取らない、ってことだね。中身も確かめずにハンコ押しちゃダメって話か」

🦜 きなこ「そう。公式のセキュリティ文書は「混乱した代理人」攻撃への対策として、クライアントごとの同意管理をMUSTにしてるの」

🦜 きなこ「同じ文書はSSRFにも触れてるの。取得先を確かめずに繋ぐと、クラウドの内部情報まで覗かれるし、サーバーごと乗っ取られる話も載ってるんだよ」

🐹 もっちー「急に怖い名前が出てきたな。で、肝心の三つ目は？あとになってから泣くのはワイもう嫌やからな」

🦜 きなこ「三つ目はクライアント側の話。2026年7月28日の改定で、認可レスポンスのiss、発行元を示す値をRFC 9207に従って検証するのが必須になったんだよ」

🐹 もっちー「発行元の名札を毎回確かめろってことか。偽物の認可サーバーにすり替えられてたら、社内の中身を全部持っていかれちゃうもんね」

🦜 きなこ「うん、それがmix-up攻撃の対策なんだよ。実装は関数一個で終わっても、この三つを外した瞬間に社内データが素通りするの」

Claude Codeに繋いで、社内ツールに広げる

🐹 もっちー「ふぅ…認証の話、頭から湯気が出そうだったよ。ところでさ、そうやって作ったサーバーって、結局どうやって手元のClaudeに繋ぐの？」

🦜 きなこ「そこはね、拍子抜けするくらいあっさりなの。ターミナルを開いて claude mcp add って打つ。それだけで終わりなんだよ」

🐹 もっちー「コマンド一つ！？さっきまでaudienceがどうとか脅されたのに、繋ぐとこはそんな軽いんかい！ワイでも打てるやん！」

🦜 きなこ「重いのは中身を守る話で、繋ぐ作業そのものは軽いの。自分のパソコンで動かすなら、stdioが既定だから指定もいらないんだよ」

🐹 もっちー「stdioって、同じパソコンの中で口移しみたいに直接やり取りするから、住所も要らないって話だったっけ？」

🦜 きなこ「そう、よく覚えてたね。だから最初の一歩に向いてるんだよ」

🐹 もっちー「じゃあ会社のサーバーに置いて、みんなでひとつのやつを使うタイプはどうなるの？」

🦜 きなこ「そこはURLで届くホスト型だから、--transport httpを足すの。公式ドキュメントに例があるから書き換えれば大丈夫」

🐹 もっちー「繋いだあとさ、ちゃんと動いてるか確かめる方法ってあるの？分からなかったら毛繕いに逃げちゃいそうなんだよ」

🦜 きなこ「公式のMCP Inspectorがあるの。npxで起動すれば、Web画面・コマンド・端末表示の三通りで中身を覗けるよ」

🐹 もっちー「画面で見られるなら安心だ。でもサーバー自体をゼロから書くのはやっぱり無理そうな気がするんだよね」

🦜 きなこ「公式のサーバー集が手本になるの。MicrosoftもPostgreSQL接続の見本を、権限の扱いごと公開してるんだよ」

🐹 もっちー「よし、繋ぎ方は分かった。で、結局ぼくの会社の古いツールに繋げるとしたら、どういう作り方をすればいいの？」

🦜 きなこ「いい質問。まずは既存の社内APIの前に、受付窓口を一枚だけ足すやり方。中の仕組みは書き換えないの」

🐹 もっちー「え、作り直さなくていいんだ。うちの古い在庫管理でもいけるのかな」

🦜 きなこ「そこが狙いなの。この薄い窓口を足すやり方をResource Gatewayパターンって呼ぶんだよ」

🐹 もっちー「へえ、わざわざ名前まで付いてるんだ。ほかにも型があって、場面によって使い分けるってことだよね？」

🦜 きなこ「その感覚で合ってる。二つ目はSemantic Adapterパターン。社内データを意味が伝わる形に整えて渡すやり方なの」

🐹 もっちー「それはぼくでも分かる気がする。伝票番号だけ渡されても何の伝票か分からないもんね。三つ目は？」

🦜 きなこ「三つ目がAPI Gatewayパターン。バラバラの社内APIを一つに束ねる形で、海外の大手も使ってると報じられてるよ」

まとめ

🦜 きなこ「今日の話を振り返ってまとめると、MCPはステートレス化・SSE非推奨・認可の強化っていう大きな3つの変化を経てるんだよ」

🐹 もっちー「難しそうって思ってたけど、まず動かすだけならワイでもできそうやな」

🦜 きなこ「その気持ちが一番大事なんだよ。難しそうに見えても、実際に自分の手を動かしてみると理解の速度が全然変わってくるから」

🦜 きなこ「そう思ってくれたなら、今日からできる一歩があるの。コマンド1個打つだけだから」

🐹 もっちー「コマンド1個か。それくらいなら帰ってすぐ試せそうだよ」

🦜 きなこ「npx @modelcontextprotocol/inspector って打つだけで、公式のMCP Inspector画面が開くんだよ」

🐹 もっちー「それくらいなら今日中にワイでもできそうやな」

🦜 きなこ「ただ、実際に社内APIに繋ぐときは、今日話した3つのMUST——トークンパススルー禁止・audience検証・iss検証を絶対に忘れないでね」

🐹 もっちー「実装は関数一個でできるのに、認証だけはそんなに気を遣うんやな。ギャップがすごいや」

🦜 きなこ「そう。簡単なところと重いところの差がはっきりしてるのが、今のMCPの姿なんだよ」

🐹 もっちー「重いところ、ちゃんと肝に銘じとくわ。まずは実装のとこから、コツコツ手を動かしてみるよ」

🦜 きなこ「MCPサーバーを実際に社内APIに繋いで動かしてみた話、実はまた別の動画でやってるんだよね」

🦜 きなこ「今日の内容と繋げて見てもらうと、社内ツール接続のイメージがもっとくっきりすると思うよ」

🐹 もっちー「確かに、机上の話だけだとまだピンときてない部分もあるし、実際に動いてるとこを自分の目で見たら理解が一気に深まりそうな気がするよ」

🐹 もっちー「え、それめっちゃ気になるやん。今日の話が終わったら、絶対あとでじっくり見に行くわ」

🐹 もっちー「そういや飼い主も最近こういうツールに詳しなってきて、ワイらのタブレット使用時間がまた伸びてる気がするで」

🦜 きなこ「気のせいじゃないと思うよ。まあ私たちも人のこと言えないけどね。コメント欄で質問や感想もたくさん待ってるね」

---

きなこもっちーのテック深掘り では、AI/LLM を中心としたテック全般をハムスター（🐹 もっちー）とセキセイインコ（🦜 きなこ）の掛け合いで楽しく解説しています。

▶️ 動画で観る → MCPサーバー自作は簡単？でも認証の3つのMUSTは外せない

👍 この記事が役に立ったら LGTM・ストックしてもらえると励みになります！

📺 チャンネル登録はこちら → きなこもっちーのテック深掘り

🔗 他の解説動画も見る → きなこもっちーのテック深掘り の動画一覧