kaigo_mcp

日本の介護の需給データを、AIエージェントが使える道具として公開するMCPサーバー。

Claude Code や Claude Desktop から接続すると、「この市は特養が足りているのか」を 公開データに基づいて答えられるようになる。

ステータス: Phase 1（サーバー本体）が動作。 エージェント本体とevalは未着手。

何をするものか

MCP（Model Context Protocol）は、LLMに道具を持たせるための規格。このリポジトリが作るのは 道具の側で、LLMそのものは含まない。サーバー単体ではAPIを一切呼ばず、課金も発生しない。

[考える側]                    [このリポジトリ]
Claude Code / 自作エージェント  ←stdio→  kaigo-gap サーバー
「どの道具を使うか」を判断              呼ばれたらデータを返す

道具

主指標は 要介護3以上の認定者100人あたりの特養定員数（全国24.6人・中央値26.7人）。 定義と出典は kaigo_gap_analysis 側にある。

集計をこちらで書いていない

データは案4（kaigo_gap_analysis）が export_web.py で書き出し、 公開ダッシュボード が配信しているのと 同じ insurers.json をコピーして使う。ここで割り算を書き直さない。

指標の定義を2か所に持つと、エージェントの答えとダッシュボードの数字が食い違ったとき、 どちらが正しいのか判定できなくなる。案4の dataset.py が「定義は1か所」という方針で 書かれているので、それを跨いで守っている。更新は python scripts/sync_data.py。

道具の設計で気をつけたこと

数字だけ返しても判断できない。 「12.4」を渡されてもLLMは高いか低いか分からないので、 全国順位と、道具の説明文に全国値を含めている。

同名自治体を1件に決め打ちしない。 「府中市」は東京都と広島県にある。 候補を両方返し、絞り込みは呼び出し側に委ねる。

特養定員0を「全国最下位」と読ませない。 該当が90保険者あり、全部が同率1位になる。 同率件数を必ず添え、さらに「小規模自治体では珍しくなく、住民は近隣自治体の施設を 利用していることが多い」という注記を付ける。これが無いと、 rank_insurers の結果から「新郷村は全国最悪の地域」という誤った結論が出る。

ドメイン知識を道具の応答に埋めておかないと、呼ぶ側のモデルを変えるたびに 同じ誤読が再発する。プロンプトではなく道具側に置くのはそのため。

使い方

pip install -r requirements.txt
python scripts/sync_data.py     # 案4からデータを取り込む
python scripts/smoke_test.py    # 通信の疎通確認

Claude Code から使うには、このディレクトリで起動すれば .mcp.json が読まれる。 他のクライアントに登録する場合の設定:

{
  "mcpServers": {
    "kaigo-gap": {
      "command": "python",
      "args": ["-m", "kaigo_mcp"],
      "cwd": "C:\projects\kaigo_mcp"
    }
  }
}

エージェント（Phase 2・動作確認まで）

python -m kaigo_mcp.agent --list
python -m kaigo_mcp.agent "尼崎市は特養が足りてる？" --verbose

道具はMCPサーバー越しに呼ぶ（関数を直接importしない）。importで済ませると MCPを通していないことになり、「MCPサーバーを作った」という主張が検証されないため。

比較する4列

BとCを同じQwen系で揃えている。 そうすると B→C の差が「モデルサイズだけの効果」、 C→D が「モデル系統の差」、A→B が「ハードと世代の効果」として読める。

ループは1本しか書かない。 片方だけSDKのツールランナー、片方だけ手書きにすると、 列間の差がモデルの差なのかループ実装の差なのか分離できなくなる。 バックエンドは履歴の変換だけを担当する。

実測（列A・列B）

各6回・python scripts/probe_tool_calling.py で計測。

温度0が要るのは 7B 固有だった

qwen2.5:7b は既定温度だと <tool_call> の開始タグが壊れ （olith pering のような数文字が先頭に付く）、ollama のパーサが認識できず 呼び出しが本文テキストに漏れる。閉じタグ </tool_call> だけが残るのが目印。温度0で解消。

qwen3.5:9b では既定温度でも 6/6。 この壊れ方はローカル実行一般の問題ではなく、 このモデルの世代・サイズに固有のものだった。

もっと大きい差は「指示に従うか」のほう

システムプロンプトは「答える前に get_national_baseline で全国の基準値を確認すること」 と指示している。9B は 6/6 で従い、7B は 0/6 で一度も従わなかった。 しかも 9B は2つの道具を1ステップで並列に呼ぶ。

7B が正しい答えを出せたのは、道具の説明文に埋めておいた全国値（24.6）を 拾ったからで、指示された手順は踏んでいない。安定性ではなく指示追従の差であり、 道具が増えるほど効いてくる。

この比較の限界

A→B でハードウェアとモデル世代が同時に変わっているので、 改善が GPU によるものか 9B によるものか分離できていない。 分離するには qwen2.5:7b を GPU 機でも走らせる（無料・数分）。

秒数も、初回のモデルロードが平均を押し上げる。列Aの実測では 初回 102.6秒・以降 7.6秒（平均 23.4秒）だった。 スクリプトは中央値と初回を分けて出すよう直したが、 列Bの数値は旧スクリプトで採ったものなので再計測が要る。

これから

• 列B の再計測（改良版スクリプトで秒数を採り直す）

• qwen2.5:7b を GPU 機で走らせ、ハードとモデル世代の効果を分離する

• 列C・D は未実行（課金が発生するので列が揃ってから1回だけ）

• Phase 3: eval 本体（複数質問×複数回での正答率・完走率）

関連

• kaigo_matching — 介護記録の構造化抽出（案1）

• kaigo_gap_analysis — 保険者別の需給ギャップ分析（案4・このデータの出所）