MCPでクリニックの集患はどう変わるか｜AIが患者さんの代わりに医院を探す時代の備え方

• Facebook
• X(旧:Twitter)
• はてブ
• LINE

「AIに聞いてきたんですけど」。診察室でそう切り出す患者さんが、診療科を問わず明らかに増えたと感じている先生は多いはずです。どこで読んだのか尋ねても、答えは返ってきません。

出典を通らずに情報が届く、という話だけではありません。その先では、患者さん本人ではなくAIが医院を絞り込み、空き枠を確かめ、予約まで通す経路が動き出しています。

この経路を支えるのが、Anthropicが2024年に規格化したMCP(Model Context Protocol)です。それが2026年7月28日に大きく作り替えられました。英語の原文はKey Changesにあります。

この改訂で、クリニックの集患は前提から一変しました。順位を上げる努力がそのまま来院に結びつくという、これまで当たり前だった図式が崩れたからです。

記事の本数で積む戦い方は先に効かなくなり、知の束ね方が効いてきます。何がどう変わり、何から手を付ければよいかを順に整理します。

クリニックの患者さんが「調べてくる」中身が入れ替わった

患者さんが来院前に下調べをするようになったのは今に始まった話ではありません。変わったのは調べる回数ではなく、情報が患者さんの手元に届くまでの経路そのものです。

診察室で増えた「AIに聞いてきました」という一言

症状を打ち込んで返ってきた文章を読み、ページは一枚も開かないまま診察室に座る患者さんが、診療科を問わず確実に増えています。

院長からすると、この違いは最初のうち小さな戸惑いとしてしか現れません。話が妙に整理されている、あるいは一般論としては正しいのに自院の診療方針とずれている、といった形で顔を出します。

出典を答えられない患者さんが増えた背景

悪気があるわけではなく、そもそも出典を通らない読み方をしているからです。AIの回答は複数の情報源を溶かし込んで一つの文章として届きます。読んだ側には「どのサイトの記述だったか」という区別が残らず、内容だけが記憶に残る仕組みになっています。

つまり自院のページが読まれていても、患者さんはそれを自院の説明だと認識していない可能性があります。医院の名前が伴わないまま、書いた内容だけが患者さんの前提になっている状態です。

アクセス解析の数字に表れない変化

この経路がやっかいなのは、医院側の数字に痕跡をほとんど残さない点です。AIが要約を返して終わればクリックは発生せず、アクセス解析にはセッションが1件も立ちません。

そのため院長の目には「記事を増やしているのにアクセスが伸びない」という形でしか映らず、原因が制作会社の力不足に見えてしまいます。実際には読まれ方の経路が変わっただけ、という場合が混じります。

診察室での患者さんの発言と、解析画面の数字が食い違い始めたら、その食い違い自体が変化の合図だと考えたほうが実態に合います。

クリニックの探され方が三つの層に分かれた

来院前の行動をほどいていくと、いまはおおむね三つの層が同時に走っています。どれか一つに置き換わるのではなく、層が増えて重なったと捉えるのが実態に近いところです。

自分で検索して自分で選ぶ層

従来型の層で、「駅名と診療科」「症状と原因」といった語を打ち込み、上から数件を開いたうえで決めていきます。

この層はまだ厚く当分のあいだ消えないので、地域で選ばれる医院にとっては、いまも来院者数の主要な部分を支えている入口であり続けます。

したがって従来の対策を今すぐ全部やめる判断は行きすぎになります。問題は比重で、この層だけに予算を寄せ続けてよいかという配分の話に変わってきました。

AIに聞いて要約だけ読む層

二つ目の層はすでに日常のものです。自院のページの文章は読まれているかもしれませんが、引用元のひとつとして溶けた状態で読まれ、クリックは発生しません。

医院側が打てる手が無いわけではありません。AIが引くのは事実として書かれた記述なので、診療時間や対応可能な検査が正確に書いてあるほど、引かれる側に回りやすくなります。

逆に情報が古いまま残っていると、その古い記述が引かれます。人間なら「更新日が古いから怪しい」と割り引いて読むところを、機械はそのまま拾ってしまう点が厄介です。

AIが代わりに探して予約まで進める層

三つ目が新しい層です。症状と条件を伝えると、AIが対応可能な医療機関を絞り、空き枠を確かめ、予約まで通してしまいます。

人が複数の候補を見比べる工程が丸ごと省かれるため、比較検討の場で選ばれるという発想が働きません。候補に入るか入らないかが、機械の読める情報だけで決まっていきます。

この層はまだ全員の日常ではありませんが、方向としてはもう戻らないので、いまのうちに足元を整えておく価値のある層だといえます。

MCPという規格が三つ目の層の配管になる

三つ目の層を裏側で支えているのがMCPです。Anthropicが2024年11月に公開し、主要なAIサービスが相次いで対応したあと、2026年7月28日の改訂で接続の作法そのものが作り替えられました。

MCPは接続の共通ルールであって検索の仕組みではない

MCPの中身は「AIが外にあるシステムへ、決まった作法で問い合わせるための共通ルール」です。名前そのものを覚える必要はありません。

これまでAIが医院の情報を得る経路は、人間向けに書かれたページを読むしかありませんでした。そこへ予約システムや施設情報へ直接問い合わせる経路が加わった、という話になります。

人間向けの文章を経由しないので、診療時間や空き枠や対応している検査が、文章の巧拙と関係なく取り出されます。書き方の工夫が効かない領域が生まれた、と言い換えてもかまいません。

2026年7月28日の改訂では、やり取りの途中経過を持たない形へ整理され、サーバー側が自分にできることを名乗る手続きが必須になりました。AIから見ると、医院のシステムが何に対応しているかを一度の問い合わせで確かめられる形です。

オンライン資格確認や電子処方箋と同じ性質の話

医療の現場には、わかりやすい前例がいくつもあります。オンライン資格確認も電子処方箋も、突き詰めれば「どの端末からでも決まった形式で照会できるようにした」という取り決めでした。

どちらも仕組みそのものは地味で、導入時は手間がかかり、動き出すと誰も意識しなくなります。MCPも性質としては同じで、要するに配管の規格です。

配管が通ると、そこに流れる情報の正確さが結果を左右します。院内の運用が整っていなければ照会の結果も整わない、という関係もこれらの前例とよく似ています。

MCPに対応しても検索順位は上がらない

大事な注意をひとつ書いておくと、MCPに対応すれば検索順位が上がるという類の話では、まったくありません。

順位を決める仕組みとは別の層にある取り決めだからです。順位は「見つけてもらう」ための話で、こちらは「機械が扱える形で情報を置いてあるか」という在庫管理に近い話になります。

この二つを混ぜたまま業者から提案を受けると、費用の判断を誤ります。順位改善の見積もりに接続対応の項目が紛れていたら、まず切り分けて説明してもらうのが安全です。

クリニックの集患は記事の本数から知の束ね方へ移る

順位も記事の本数も、これから重みを落としていきます。ところが同じ流れのなかで、落ちるどころか他のすべての手当ての前提になっていくものがあります。

一般的な疾患解説から入る流入は細っていく

「症状」「治し方」といった語から入ってきていた流入は、AIが要約で返してしまうため確実に細ります。読者が知りたい水準の答えが、ページを開かずに得られてしまうからです。

この種の記事を毎月何本という契約で増やしてきた医院ほど、費用対効果の説明が難しくなります。本数を積む戦い方は、いちばん先に効かなくなる場所に置かれていました。

ただし、ここから「記事はもう要らない」と結論するのは早すぎます。要らなくなるのは本数を目的にした増やし方であって、記事という材料そのものではありません。

AIが読んでいるのは記事ではなく知の構造

AIが「この医院はこの分野に詳しい」と判断するとき、見ているのは記事1本の出来ではありません。ある領域について、どこまで漏れなく、どういう関係で語られているかという構造のほうです。

その構造を作る形がトピッククラスターです。中心に幹となる解説を置き、その周りへ枝葉の記事を配置し、幹と枝を内部リンクで結んで一つの塊にしていきます。

内部リンクは、単なる回遊の仕掛けではなく知の地図として読まれます。隅々まで行き届いていれば、機械は端の1本からでも医院全体の専門領域へたどり着けます。

現場を知らない業者ほど、まず構造化データの実装を勧めてきます。構造化データそのものは大切なもので、きちんと入れておく価値がありますから、否定するつもりはまったくありません。

ただ、優先順位としては知の構造化のほうが明らかに上に来ます。優れたトピッククラスターと隅々まで届く内部リンク構造があって初めて、構造化データが指し示すべき中身が生まれるからです。

散らばったままの知は評価の土俵に乗らない

逆に、同じ本数の記事がリンクもされず散らばっていると、AIから見えるのは互いに無関係な断片の山です。全体像を組み立てる手がかりが無いので、専門性として集計されません。

これは順番の問題です。診療情報を正確に整え、予約の導線を短くし、接続の準備まで済ませたとしても、肝心の知が散らばっていれば評価の土俵に乗る前で止まります。

一瞬でこの分野の専門だと分かる形に整えてあるかどうかが、他のすべての手当てを活かすかどうかを決めます。トピッククラスターの形成は選べる施策の一つではなく、前提として必須の条件だと考えてください。

いま持っている記事を束ね直すところから始める

幸いなことに、この作業は新しく大量に書くことを求めません。すでに持っている記事を領域ごとに並べ、幹になる1本を決め、そこへ枝を結び直す作業から始められます。

本数を積んできた医院ほど、実は材料が揃っています。足りないのは束ねる作業のほうで、そこに手を入れると同じ資産の見え方が変わります。

制作会社に頼むなら、新規記事の本数ではなく構造の設計と内部リンクの張り直しを発注内容に入れます。ここが見積もりに一行も無ければ、優先順位が現状とずれています。

予約システムのMCP対応は待っていられない

知を束ね直したうえで、次に詰まりやすいのが予約です。第三層でAIが最後に触れる場所であり、ここが閉じていると手前の努力がすべて空振りになります。

予約枠が閉じていると候補から静かに外れる

AIが代理で予約を取ろうとしたとき、空き枠を機械から確かめられない医院は候補から外れます。断られるのではなく、比較の対象に入らないまま通り過ぎられる形です。

電話でしか予約を受けていない医院はもちろん、Web予約があっても外部サイトの中で完結している場合は同じ結果になります。人間には見えていても、機械からは扉が無いのと変わりません。

しかもこの取りこぼしは、医院側の記録に一切残りません。問い合わせが来ないだけなので、何が起きているのか気づく手立てが無い点が厄介です。

既製の予約システムの対応時期は読めない

それなら予約システムの提供元が対応してくれるまで待てばよい、と考えたくなります。ただ、対応の予定が公表されている製品はまだ限られ、時期を当てにした計画は立てにくいのが実情です。

医療機関向けの予約製品は導入先の数だけ要件が違うため、共通規格への対応が後回しになりやすい分野でもあります。待つあいだに第三層が太っていけば、その差は取り返しにくくなります。

だからこそ、自院で持つという選択肢が現実味を帯びてきました。数年前なら考えられなかった話ですが、事情が変わっています。

Claude CodeやCodexで自院用に作るという道

Claude CodeやCodexといった開発支援のAIが実用になり、仕様を言葉で伝えれば動くものが組み上がるようになりました。予約枠の管理と接続の口を用意するだけなら、規模としては手が届く範囲です。

自院で作れば、対応の時期を自分で決められます。製品の都合に合わせるのではなく、必要になった時点で必要な口を開けられるという点が、いちばん大きな違いになります。

もっとも、扱うのは患者さんの個人情報です。自作を選ぶなら、権限の設計と保守の担い手を先に決めておく必要があり、そこを曖昧にしたまま走り出すのは避けたいところです。

• いま使っている予約システムに、外部から空き枠を照会する口があるか
• 提供元がMCPへの対応時期を公表しているか
• 自作する場合、予約データを誰が保守し、権限をどう分けるか
• 移行するとき、既存の予約をどう引き継ぐか

クリニックが明日から見直す四つの順番

全部を一度に着手する必要はなく、効きやすい順に四つ挙げるので、上から順に潰していく形が現実的です。

診療の事実を一か所に正確に置く

診療時間、休診日、対応している検査と処置、予約ページのURL、医師の氏名と資格。これらがページごとに食い違っている医院は珍しくありません。

人間は文脈で補って読みますが機械は補わないので、古い情報が一か所に残っているだけで、そこが拾われてしまう危うさがあります。

まずはこの棚卸しから始めるのが確実です。院内の掲示、ホームページ、地図サービスの登録内容を並べて、食い違いを潰していく作業になります。

記事のトピッククラスター化を必ず進める

次がトピッククラスター化で、ここは避けて通れない工程になります。手持ちの記事を領域ごとに集め、幹になる1本を決め、枝から幹へ、幹から枝へと内部リンクを通していきます。

いちばん多いのが、院長ブログという単一のカテゴリに記事が全部積み上がっている形です。日々の出来事も季節の挨拶も疾患の解説も同じ箱に入っているため、量があっても領域の地図になりません。

AIから見ると、この医院が何の専門なのかが立ち上がってきません。その形のまま本数だけを増やしている医院は、MCPが広がるほど置いていかれる側に回ります。

そのうえで足りない枝が見えたら、そこだけを新しく書きます。本数の目標を先に立てるのではなく、構造の穴が本数を決めるという順番に切り替えるわけです。

書く内容も、その医院でしか観測できないものへ寄せます。この地域でこの時期に多い相談、当院での検査の流れと所要時間、紹介で来られた方に多い経緯といったものが該当します。

署名と経歴をページに残す

執筆者または監修者として医師名を出し、経歴と資格を添えます。当たり前のようでいて、制作会社任せのサイトでは抜け落ちていることの多い箇所です。

誰が言っているのかを示せるのは医療機関の強みなので、使わずに置いておく理由がありません。記事の末尾に一行足すだけでも、無い状態とは大きく違います。

同時に、院長個人の名前と医院名の表記を揺らさないようにしておきます。旧字体と新字体、英語表記の有無といった小さな揺れが、機械には別人として見えます。

予約までのクリックを一つ減らす

予約導線の途中に人間の勘へ頼る段差があるほど、代理で動くAIはそこで落ちます。電話番号しか置いていない、予約システムが外部サイトで迷子になる、といった箇所が典型です。

導線を一つ短くする改修は、第一層の患者さんにもそのまま効きます。三つの層すべてに同時に効く数少ない打ち手なので、優先順位を上げる価値があります。

着手の前に、自分でスマートフォンから予約を取ってみるのが早い確認方法で、詰まった箇所がそのまま改修の候補になります。

E-E-A-TとSNSがクリニックをブランドへ押し上げる

ここまでを整えたうえで、いちばん強い状態は医院そのものが指名される形です。その到達点として効いてくるのが、E-E-A-Tという考え方になります。

経験(Experience)・専門性(Expertise)・権威性(Authoritativeness)・信頼性(Trustworthiness)の頭文字で、情報の質を四つの角度から見る枠組みです。医療のように誤りが人に及ぶ分野ほど、厳しく見られます。

医療広告ガイドラインが鍛えてきた強み

一般の業種はいま、誰が言っているのかを示せという要求に慌てています。体験談を並べ、施術前後の写真を載せ、数字を強めて集客してきた業界ほど、書き手の実体を問われると弱いからです。

医療は事情が違います。医療広告ガイドラインがあるおかげで、体験談も施術前後の比較も断定的な効果の表現も、そもそも使えませんでした。

使えたのは事実と、書いた人間の資格と、診療の実績だけです。十年以上にわたっていちばん厳しい条件で書かされてきた経験が、そのままE-E-A-Tの土台になります。

ショート動画とSNSの比重は確実に上がる

医師本人が語る短い動画は、資格や経歴と結びついた形で人格ごと伝わります。文章では届きにくい層に届くうえ、指名で探される回数を押し上げる働きも持ちます。

制作の手間は下がり続けています。私(山岡)がいま最も力を入れているのも質の高いショート動画の量産で、台本づくりから編集までの自動化に取り組んでいます。数年後には、着手した医院とそうでない医院の差が見えやすい領域になるはずです。

SNSでの言及が増えれば、AIが医院を語るときの材料も増えます。Webサイトの外側にある評判が、評価の一部として回収されていく流れです。

発信が効くのは受け皿が整理されているとき

ただし順序を間違えないでいただきたいところです。動画やSNSで関心を持った人も、AIも、最後は医院のサイトへ確かめに来ます。

そのとき知が束ねられていなければ、せっかくの関心が専門性の裏づけに変わりません。発信は増幅装置であって、増幅される中身は整理された知のほうが持っています。

だから投資の順番としては、束ね直しが先で、発信の強化が後になります。両方に手が回らない時期があるなら、先に土台を選ぶほうが結果として遠くまで行けます。

• 幹となる解説と、そこへ結ばれた枝の記事が領域ごとに揃っているか
• 医師の資格と経歴が、記事とプロフィールの両方から確かめられるか
• SNSや動画での名乗りが、サイト上の表記と一字も違わずに揃っているか

まとめ

2026年7月28日のMCPの改訂で、クリニックには第三の集患ルートができてしまいました。検索でもなく、AIの要約でもなく、AIが代理で探して予約まで済ませてしまう経路です。

この経路が太るほど、患者さんの行動は「自分で比較して調べる」から離れていきます。AIが薦め、そのまま予約まで取ってくれた医院しか選ばない、という形へ寄っていくからです。

その時代は、すぐそこまで来ています。候補に入るために要るのは、束ね直された知と、正確な診療情報と、機械から扱える予約の口の三つです。

順位を追う努力を捨てる必要はありません。ただ、その努力が届く先が変わったという一点だけは、早いうちに受け止めておくほうが有利に働きます。

よくある質問

クリニックのLLM最適化に戻る

クリニックGEO対策TOP

• Facebook
• X(旧:Twitter)
• はてブ
• LINE