TogoMCP チュートリアル

生命科学のデータベースに、SPARQL を書かずに自然言語で問い合わせるための実践チュートリアルです。

対象は、生命科学の研究者・大学院生。情報系のバックグラウンドは前提としません。RDF や SPARQL を知らなくても最後まで進めます。

この教材で身につくこと

1. TogoMCP を自分の環境に繋いで、生命科学の主要データベース群に自然言語で問い合わせられるようになる
2. 返ってきた答えがデータベース由来なのか、AI の記憶由来なのかを見分けられるようになる
3. 結果を論文や報告に使えるだけの再現性のある形で残せるようになる

3 番目が最も重要です。 1 番目だけなら 10 分で終わります。

この教材が最も時間を割くのは、うまくいく例ではなく、うまくいかない例です。第 4 章では、意図的に曖昧な問いを投げます。それは十数秒で流暢な答えを返しますが、その答えはデータベースを一度も参照していません。しかも画面上には、そのことに気づく手がかりが何もありません。

速くて自信満々に間違うほうが、遅くて失敗するより危険です。

見分けられるようになることが、この教材の中心です。

読み方

通しで約 90 分。ただし全部読む必要はありません。

急いでいる方は ★ の 3 章だけでも実用になります（01 → 02 → 06、約 30 分）。

このページの使い方:

• 左の目次から各章へ。読んでいる位置は自動で追従します
• プロンプトやクエリはワンクリックでコピーできます（コードブロックにマウスを乗せると「コピー」が出ます）
• ◐ でダーク／ライト切替、⎙ で印刷（PDF 保存もここから）
• スマートフォンでも読めます

⚠️ この教材の数値について — 先に読んでください

本文には accession 番号、件数、分解能といった実行結果が多数出てきます。すべて実測値です。

測定条件:

そして、あなたが同じクエリを走らせても、数値は違うはずです。

それは異常ではありません。データベースが生きているからです。 実際、この教材を作る過程でも PDB の件数は数日のあいだに動きました。

だから、この教材が持ち帰ってほしいのは数値そのものではなく、クエリと、そこに至る考え方です。結果の表よりクエリ本文を重視しているのは、そのためです。

これは弱点ではなく、この教材が教えている作法そのものです。 第 7 章で、なぜ「実行日とクエリを記録せよ」と言うのかを扱います。

もう一点。所要時間とツールの使われ方は、使うモデルによって変わります。 同じ問いに対して、あるモデルは検索を 1 回打ち、別のモデルはデータベースに一度も触れませんでした。返ってきた値はどちらも一致しましたが、そこに至る過程は違いました。

この教材を使って講習会を開きたい方へ

教材一式が GitHub で公開されています ── 90 分／60 分の進行表、逐語の講師台本、全デモの実行記録（ネットワーク障害時の差し替え用）、演習と解答例、投影用スライド。

https://github.com/dbcls/togomcp

Markdown ソースとビルドスクリプトも含まれているので、自分の分野に合わせて改変して構いません。

引用

TogoMCP を研究に使った場合は、以下を引用してください。

Kinjo, A. R., Yamamoto, Y., Bustamante-Larriet, S., Labra-Gayo, J.-E., & Fujisawa, T. (2026). TogoMCP: Natural Language Querying of Life-Science Knowledge Graphs via Schema-Guided LLMs and the Model Context Protocol. Database 2026:baag042. https://doi.org/10.1093/database/baag042

MIE ファイルの設計根拠（アブレーション研究）については、こちらもあります。

Kinjo, A. R., & Yamamoto, Y. (2026). Measure before you rewrite: ablation-driven redesign of LLM-facing RDF schema documentation in TogoMCP. BioHackrXiv. https://doi.org/10.37044/osf.io/6v5ra_v1

あわせて、実際に使った個々のデータベースも引用してください。 TogoMCP は入り口であって、データの出どころではありません。

• ホスト版: https://togomcp.rdfportal.org/
• リポジトリ: https://github.com/dbcls/togomcp
• RDF Portal: https://rdfportal.org/

00

00. 概要 — なぜ TogoMCP なのか

解こうとしている問題

生命科学の主要データベースは、この 15 年でおおむね RDF 化されました。UniProt も PDB も ChEMBL も Reactome も、SPARQL という問い合わせ言語で機械可読に検索できます。理屈のうえでは、「ヒトのライソゾーム酵素のうち承認薬の標的になっているもの」のような問いは、1 本のクエリで答えが出るはずです。

実際にはそうなっていません。理由は 3 つあります。

1. SPARQL を書ける研究者が少ない。 これは能力の問題ではなく、投資対効果の問題です。年に数回しか書かないものを習得し続けるのは合理的ではありません。

2. データベースごとに語彙もグラフ構造も違う。 UniProt でタンパク質は up:Protein、遺伝子との関係は up:encodedBy。PDB では pdbo:datablock から pdbo:has_entityCategory を辿ります。1 つ覚えても次で使えません。

3. 横断的な問いは、エンドポイントの癖を知らないと書けない。 どのグラフを指定すべきか、どの述語が速いか、どこで結合が壊れるか。これは文書化されていないことが多く、失敗も静かです — エラーではなく、間違った件数が返ってきます。

TogoMCP は、この 3 つを AI アシスタント側に肩代わりさせるための MCP サーバです。

RDF と SPARQL とは

この節は、あなたが SPARQL を書けるようになるためのものではありません。 書くのは AI の仕事です。ただし、AI が何をしているかを画面で追い、返ってきた数字を疑うには、ここにある 4 語だけは要ります。

RDF は、データを「A の B は C」という 3 つ組だけで表す形式です。表の代わりに、この 3 つ組を大量に積み上げてデータベースを作ります。

インスリン ──  生物種  ──→ ヒト
インスリン ──  長さ    ──→ 110
インスリン ── 関連疾患 ──→ 糖尿病

真ん中の「生物種」「長さ」にあたるものを 述語と呼びます。どの述語が使えるかはデータベースごとに違います。 これが第 3 章の主題です。

SPARQL は、この 3 つ組に対する問い合わせ言語です。表に対する SQL にあたります。

3 つ組の「インスリン」や「ヒト」は、実際には日本語ではなく http://purl.uniprot.org/uniprot/P01308 のような URL の形をした名前で書かれています。これを IRI と呼びます。IRI は名前であって、リンク先ではありません。 クリックして開くためではなく、同じものを世界中で同じ名前で呼ぶためにあります。UniProt の言う「ヒト」と PDB の言う「ヒト」が同じ IRI なら、両者は機械的に繋がります。

最後に グラフ。1 つのデータベースの中で 3 つ組を入れておく仕切りのことです。1 つの置き場に複数のデータセットが同居していることがあり、仕切りを指定し忘れると、隣のデータセットの行まで拾ってしまいます。 第 3 章で実際にやってみます。

覚える必要はありません。 出てきたときにここへ戻れば十分です。

MCP とは

MCP (Model Context Protocol) は、AI アシスタントに「道具」を配るための標準規格です。AI 本体を作り変えることなく、外部のデータやサービスへの接続口を後付けできます。

  あなた  ──→  Claude など  ──→  MCP サーバ  ──→  外部のデータ
   (質問)        (道具を選ぶ)      (TogoMCP)      (SPARQL / REST)

重要なのは、AI が「知っていること」ではなく「取りに行けること」に変わる点です。訓練データに含まれていた記憶を思い出すのではなく、いま生きているデータベースに問い合わせて答えを作ります。

TogoMCP とは

一言でいうと：

RDF Portal の約 37 データベースを、自然言語で問い合わせられるようにする MCP サーバ

日本発のデータベース（TogoVar、jPOST、GlyCosmos、NBRC、MoG+、NANDO、MediaDive）が揃っている点は、他では代えがきかない特徴です。第 4 章でその価値が具体的に見えます。

「便利そう」ではなく「測って効いている」

この種のツールは、デモでは印象的でも実務では役に立たないことがよくあります。TogoMCP については定量的な評価があります。

TogoMCP の有無で同一の問題セットを解かせた比較で、効果量 Cohen's d = 1.82*、Wilcoxon 検定で p < 0.001*。

出典: Kinjo, A. R., Yamamoto, Y., Bustamante-Larriet, S., Labra-Gayo, J.-E., & Fujisawa, T. (2026). TogoMCP: Natural Language Querying of Life-Science Knowledge Graphs via Schema-Guided LLMs and the Model Context Protocol. Database 2026:baag042. https://doi.org/10.1093/database/baag042

上記の数値はこの論文で報告されたものです。本教材で独自に測定し直したものではありません。

効果量 1.82 は、行動科学の慣例では「大きい」の目安（0.8）を大きく超えます。ただし、これはベンチマーク問題セット上での測定であり、あなたの研究テーマで同じ差が出ることを保証するものではありません。第 4 章と第 7 章で、効かない場合も具体的に見ていきます。

💡 なぜ出典をここまで丁寧に書くのか。 この教材は「典拠のない数字を信じるな」と言い続けます。その教材自身が典拠なしに数字を出すわけにはいきません。 第 6 章・第 7 章で扱う作法を、本文でも守っています。

この教材のゴール

3 つあります。

1. 繋いで、使えるようになる（第 1〜2 章）
2. なぜ動くのかを理解する（第 3 章）— これがないと、動かないときに手が出せません
3. 答えを疑い、検証できるようになる（第 4・6・7 章）

3 番目を強調しておきます。この教材で最も時間を割くのは、うまくいく例ではなく、うまくいかない例です。

第 4 章では、意図的に曖昧な問いを投げます。それは 12 秒で流暢な答えを返しますが、その答えはデータベースを 1 度も参照していません。しかも画面上には、そのことに気づく手がかりが何もありません。

速くて自信満々に間違うほうが、遅くて失敗するより危険です。

見分けられるようになることが、この教材の中心です。

次 → 01. セットアップ

01

01. セットアップ

3 つの経路があります。まずは経路 A を試してください。 インストール不要で 3 分です。B と C は必要になったときに読めば十分です。

いずれの経路でも、TogoMCP 側のアカウント登録や API キーは要りません（NCBI ツールを使う場合のみ NCBI の API キーが要ります → 付録）。

経路 A：Claude のカスタムコネクタ（推奨）

Claude（Web / デスクトップ / Cowork）の全プランで使えます。Free プランはカスタムコネクタを 1 つまで、有料プランは上限なしです。

手順

1. Claude を開き、設定 → カスタマイズ → コネクタ へ
2. 「+」 → 「カスタムコネクタを追加」
3. MCP サーバの URL を入力：

https://togomcp.rdfportal.org/mcp

4. 追加後、チャット画面の 「+」 ボタンから コネクタ を選び、その会話で有効化する

Team / Enterprise プランの場合

先に組織のオーナーが 1 手順を踏む必要があります。 メンバーが個人で追加することはできません。

1. オーナーが 組織設定 → コネクタ → 追加 で、カスタム にホバーして Web を選択し、組織全体に追加する
2. その後、各メンバーが カスタマイズ → コネクタ から自分で接続する

💡 所属組織が Team/Enterprise プランの場合、自分では追加できません。 管理者に依頼してください。

カスタムコネクタが使えない環境の場合

mcp-remote というローカルブリッジを経由する方法があります。コミュニティ製ツールであり Anthropic 公式の手順ではありませんが、動きます。

claude_desktop_config.json に以下を追加：

{
  "mcpServers": {
    "togomcp": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://togomcp.rdfportal.org/mcp"]
    }
  }
}

経路 B：Claude Code (CLI)

ターミナルで（Claude のセッションに入る前に）以下を実行します。

claude mcp add --scope user --transport http togomcp https://togomcp.rdfportal.org/mcp

--scope user を付けるとすべてのプロジェクトで使えるようになります。付けないと、そのディレクトリでしか有効になりません。

接続の確認

claude mcp list

togomcp の横に ✔ Connected と出れば成功です。

Claude のセッション内では /mcp と打つと同じ状態が見られます。

削除・確認

claude mcp list              # 一覧
claude mcp remove togomcp    # 削除
claude mcp remove togomcp --scope user   # スコープを指定して削除

よくある間違い

1. claude mcp add を Claude のセッション内で打ってしまう。 これはターミナルで打つコマンドです。claude と入力してセッションに入ったあとでは動きません。
2. URL の末尾の /mcp を落とす。 404 になります。
3. スコープを忘れる。 既定の local は、そのディレクトリでしか効きません。「昨日は動いたのに」の大半はこれです。
4. 設定ファイルの場所を間違える。 Claude Code が読むのは ~/.claude.json と、プロジェクト直下の .mcp.json だけです。~/.claude/.mcp.json などは読まれません。

上記は Claude Code v2.1.210 以降で確認。claude --version で自分のバージョンを確認できます。

経路 C：ローカル stdio

開発者向け、および KEGG ツールを使いたい場合の唯一の経路です。手順は 付録 にまとめました。

接続できたかの確認（全経路共通）

Claude にこう聞いてください。

TogoMCP からどんなデータベースが使えるの？

期待される反応: 10 秒ほどで、UniProt・PDB・ChEMBL・TogoVar などを含む 37 データベースの一覧が、分野ごとに整理されて返ってきます。

うまくいかない場合:

詳しくは 08. トラブルシュート へ。

補足：ChatGPT / Gemini から使う場合

TogoMCP は Claude 専用ではありません。ただしホスト側の事情で癖があります。

• ChatGPT: Developer Mode（Web のみ、モバイル非対応）。Pro は read/fetch のみですがそれで足ります。Plus はカスタム MCP コネクタが使えません。 ⚠️ ChatGPT はコネクタ追加時にツール一覧を記録したきり、自動で取り直しません。 後から追加されたツールは見えないままです。「あるはずのツールが無い」と言われたら Scan Tools を再実行するか、コネクタを削除して追加し直してください。なおデータベースの追加は影響しません（データベース目録は問い合わせ時に配信されるため常に最新です）。
• Gemini / Antigravity: ~/.gemini/config/mcp_config.json に "serverUrl" として指定。TogoMCP は Streamable HTTP であって SSE ではない点に注意。

一緒に使うと強い MCP サーバ

TogoMCP 単体でも動きますが、以下と併用すると扱える範囲が広がります。第 5 章のスキルはこれらを前提にしているものがあります。

典型的な連携は「OLS4 で正規の用語 ID を確定 → TogoMCP でその ID を使って照会」。第 6 章で、なぜこの順序が効くのかが分かります。

次 → 02. 最初のデモ

02

02. 最初のデモ

まず動かします。そのあと裏で何が起きたかを開けて見ます。後者のほうが重要です。

デモ 1：1 ホップの問い

そのまま貼り付けてください。

ヒトのインスリン (INS) 遺伝子産物の UniProt エントリを教えて。機能と配列長も。

返ってくるもの（実測 18〜28 秒。モデルによって差があります）:

機能（UniProt の記載そのまま）:

Insulin decreases blood glucose concentration. It increases cell permeability to monosaccharides, amino acids and fatty acids. It accelerates glycolysis, the pentose phosphate cycle, and glycogen synthesis in liver.

「110 aa」で引っかかった人へ

正しい反応です。インスリンは 51 アミノ酸と習ったはずです（A 鎖 21 + B 鎖 30）。

110 はプレプロインスリン前駆体の長さです。シグナルペプチド（24）+ B 鎖（30）+ C ペプチド（31）+ A 鎖（21）+ 切断部位。UniProt の P01308 が指すのは翻訳産物であって、成熟した循環中のホルモンではありません。だから答えの名称にも [Cleaved into: Insulin B chain; Insulin A chain] と書いてあります。

これがこの教材で最初に学ぶことです。

データベースは、あなたの記憶より精密です。そして、あなたが期待していたのと別のものを指していることがあります。

答えが「違う」と感じたとき、まず疑うべきは自分の期待とデータベースの定義のずれです。AI が間違えたのではありません。

デモ 2：ID を持って別のデータベースへ渡る

続けて、同じ会話でこう聞きます。

その UniProt ID を Ensembl 遺伝子 ID と HGNC ID に変換して。あと PDB の構造も。

「その UniProt ID」で通じます。前のやりとりの文脈が引き継がれています。

返ってくるもの（実測 18〜30 秒）:

これは TogoID という ID 変換サービスを呼んでいます。「UniProt から Ensembl へは is product of gene という関係で辿れる」という関係の定義を持っているので、闇雲な文字列マッチではありません。

💡 HGNC は 6081 という裸の数字で返ることがあります。正式には HGNC:6081 です。

裏で何が起きたか（ここが本題）

ツール呼び出しのログを開いてください。

• Claude デスクトップ / Web: 回答中に表示される折りたたみを展開
• Claude Code: 実行時にそのまま表示されます

デモ 1 では、こういう順番で動いていました。

1. TogoMCP_Usage_Guide()          ← 使い方ガイドを読む
2. search_uniprot_entity(...)     ← INS で UniProt を検索して P01308 を特定
3. get_MIE_file("uniprot")        ← UniProt の「スキーマ説明書」を読む
4. run_sparql("uniprot", "...")   ← SPARQL を組み立てて実行

魔法ではなく、手順です。

ステップ 3 が TogoMCP の核心です。 次の章で詳しく扱います。ここでは「SPARQL を書く前に、必ずそのデータベースの説明書を読んでいる」という事実だけ押さえてください。

気づいてほしいこと

ステップ 1 は、あなたが発言するたびに毎回実行されます。 セッションの最初に 1 回ではありません。

📖 用語：「ターン」

会話の 1 往復のことです。あなたが 1 回発言し、それに対する応答が終わるまでが 1 ターン。

1 ターンの中でツールを何回呼んでも 1 ターンです。上の例では 4 つのツールが動いていますが、これで 1 ターン。デモ 1 とデモ 2 は別々に打ち込んだので 2 ターンです。

[ターン1] あなた: 「ヒトのインスリンの…」 → Usage_Guide, search_uniprot, get_MIE, run_sparql, 回答 ↑ここで1回 [ターン2] あなた: 「その ID を Ensembl に…」 → Usage_Guide, togoid_getRelation, togoid_convertId, 回答 ↑また1回

これは設計上そうなっています ── ツールの説明に「毎ターン、他のどのツールより先に呼べ」と明記されており、前のターンの作業内容は引き継がれないという前提です。

ガイドの実体は 44,570 文字（英語のマークダウン 5 ファイルを連結したもの。おおよそ 1.1〜1.3 万トークン相当）。会話が長くなるとこれが積み上がるので、利用量が気になる場合は把握しておいてください。

💡 ローカル導入で KEGG を有効にしている場合、KEGG の節が追加されるぶんさらに大きくなります。

この 2 つのデモが示していること

デモ 1: 曖昧な語（「インスリン」）から、検証可能な ID（P01308）に着地した。答えには出どころがある。

デモ 2: その ID を持って、別のデータベースへ渡れた。生命科学データベースの最大の面倒 ── 同じものが DB ごとに別の名前で呼ばれている ── が自動化された。

この 2 つを組み合わせると、第 4 章の「複数 DB をまたぐ問い」に届きます。

自分でやってみる

あなたの関心のある遺伝子・タンパク質で、デモ 1 を繰り返してください。

ヒトの ◯◯ の UniProt エントリを教えて。機能と配列長も。

確認するポイント:

1. 返ってきた accession は正しいものか（UniProt の Web サイトで 5 秒で確認できます）
2. 配列長は、あなたが期待した長さか。違うなら、なぜ違うのか（前駆体？ アイソフォーム？）
3. ツールのログに run_sparql は出ているか。出ていない場合、答えはどこから来たのか

3 番目が引っかかった人は、そのまま第 4 章の後半に進んでください。そこが本題です。

次 → 03. 仕組み

03

03. 仕組み

なぜ AI が、教わってもいないデータベースに対して正しい SPARQL を書けるのか。答えは「賢いから」ではありません。説明書を渡しているからです。

3-1. データの形 — この章を読むための下ごしらえ

第 0 章の「RDF と SPARQL とは」で足りている人は飛ばして構いません。この章の本題は後半の「落とし穴」です。 そこを理解するのに必要な分だけ、もう少し踏み込みます。

RDF のデータベースは、「A の B は C」という 3 つ組の集まりです。3 つの位置にはそれぞれ名前があります。

   主語            述語           目的語
    │               │               │
    ▼               ▼               ▼
インスリン ──── 生物種 ─────────→  ヒト
    │
    ├──────── 長さ ─────────────→  110
    │
    └──────── 関連疾患 ─────────→ 糖尿病

この 3 つ組を トリプルと呼びます。「件数」とは、条件に合うトリプルが何本あるかということです。 ここが後半で効いてきます。

名前は URL の形をしている

上の図は日本語で書きましたが、実際のデータは違います。

<http://purl.uniprot.org/uniprot/P01308>          ← 主語（インスリン）
    <http://purl.uniprot.org/core/organism>       ← 述語（生物種）
        <http://purl.uniprot.org/taxonomy/9606> . ← 目的語（ヒト）

この URL の形をした名前が IRI です。長いので頭の部分に別名を付けます。これが SPARQL の冒頭に並ぶ PREFIX 行の正体です。

PREFIX up: <http://purl.uniprot.org/core/>
#      ↑ 以降 up:organism と書けば上の長い IRI を指す

📖 なぜ URL の形なのか。 クリックして開くためではありません。同じものを世界中で同じ名前で呼ぶためです。UniProt の言う「ヒト」も NCBI の言う「ヒト」も taxonomy/9606 なら、両者は機械的に繋がります。第 4 章で複数のデータベースを渡り歩けるのは、この一点によります。

裏を返すと、IRI が違えば、人間の目に同じものでも機械は別物として扱います。 第 4 章で実際にこれに当たります。

グラフ — トリプルの仕切り

1 つの置き場（エンドポイント）に、複数のデータセットが同居していることがあります。そこでトリプルは グラフという仕切りに入れて管理されます。

エンドポイント (sparql.uniprot.org)
 ├─ グラフ <.../uniprot>        ← UniProt 本体のトリプル
 ├─ グラフ <.../taxonomy>       ← 生物種のトリプル
 └─ グラフ <.../別データセット>   ← 同居している別のもの

SPARQL で FROM <グラフ名> と書くと、その仕切りの中だけを見ます。 書かないと全部の仕切りをまたいで探します。

「書かなくても答えは出るのだから、細かい話だろう」と思うかもしれません。3-6 節で、それが間違いであることを実演します。

クエリの読み方（書けなくてよい）

この先、SPARQL が何度か出てきます。書けるようになる必要はありませんが、形だけ知っておくと AI が何をしたか追えます。

SELECT ?protein ?mass                     # 何を返してほしいか
FROM <http://sparql.uniprot.org/uniprot>  # どの仕切りを見るか
WHERE {                                   # どんな形のトリプルを探すか
  ?protein up:mass ?mass .                #  主語     述語   目的語
}

? で始まるものが穴です。「?protein の up:mass は ?mass」という形のトリプルを全部探し、穴に入った値を表にして返す。それだけです。

3-2. 全体の構造

   あなた
     │  「ヒトのインスリンの…」
     ▼
 ┌─────────────┐
 │  Claude     │  ← 道具を選ぶ・クエリを組む・結果を読む
 └─────────────┘
     │  MCP プロトコル
     ▼
 ┌─────────────┐
 │  TogoMCP    │  ← 道具の実体。説明書も配る
 └─────────────┘
     │
     ├──→ SPARQL エンドポイント (rdfportal.org ほか)
     └──→ REST API (UniProt, ChEMBL, PDB, NCBI, TogoID, TogoVar …)

TogoMCP は単なる中継役ではありません。SPARQL を投げる機能に加えて、「このデータベースはこういう構造で、こう書けば速く、ここで失敗する」という知識を配る機能を持っています。後者がなければ、前者は使い物になりません。

3-3. ツールは 3 層に分かれている

TogoMCP のツールを役割で分けると、こうなります。この 3 層構造が理解できれば、あとは応用です。

第 1 層：ガイダンス層 — 「どう使うか」を教える

第 2 層：グラウンディング層 — 「言葉」を「ID」に変える

この層が「グラウンディング（接地）」と呼ばれる理由: 「インスリン」「膵がん」といった揺れる言葉を、P01308、D010190 のような動かない識別子に固定する。ここを飛ばすと、あとの工程が全部あてずっぽうになります。第 4 章の失敗例は、まさにこの層をすり抜けた場合に起きます。

第 3 層：実行層

たった 1 つです。しかし、第 1 層を読まずにここに来てはいけないというのが TogoMCP の最重要ルールです。

3-4. MIE ファイル — この仕組みの核心

MIE (Metadata Interoperability Exchange) ファイルは、1 つのデータベースにつき 1 つ用意された YAML の説明書です。設計目標は明快です。

LLM が初回で正しく速い SPARQL を書けるだけの情報を、過不足なく与える。

「過不足なく」が肝です。全スキーマを丸ごと渡せば正確ですが、巨大すぎて実用になりません。逆に概要だけでは書けません。MIE は「モデルが自力で復元できないことだけを載せる」という方針で作られています。

MIE に載っているもの

MIE の中心は 「検証済みの実行例」 です。1 つの例が、同時に 3 つの役割を果たします。

examples:
  - id: sequence_mass
    description: タンパク質の配列と質量を取得する
    sparql: |
      PREFIX up: <http://purl.uniprot.org/core/>
      SELECT ?sequence ?mass
      FROM <http://sparql.uniprot.org/uniprot>
      WHERE {
        ?protein up:sequence ?seq .
        ?seq rdf:value ?sequence ; up:mass ?mass .
      }
    traps_avoided:
      - union_inflation: FROM 句でグラフを固定しないと、
        同居する他データセットの行を拾って件数が膨らむ
    verified: 2026-07-29

同じ内容を「スキーマ説明」「サンプル」「注意書き」と 3 回書く代わりに、動く例 1 つに集約しています。

実際に見てみる

自分で確認できます。Claude にこう聞いてください。

UniProt の MIE ファイルを見せて。examples の節だけでいい。

3-5. 「SPARQL の前に必ず MIE を読む」というルール

TogoMCP の使い方ガイドには、いくつか強制的なルールがあります。最も重要なのがこれです。

run_sparql を呼ぶ前に、必ずそのデータベースの get_MIE_file を呼べ。

意地悪でルールを課しているわけではありません。理由は 2 つあります。

理由 1：IRI のハルシネーションを防ぐ。 MIE を読まないと、AI は「たぶんこういう述語名だろう」と推測します。up:hasSequence のような存在しない述語を書くと、SPARQL はエラーを出しません。0 件を返します。 そして AI は「該当なし」と報告します。これは検出が非常に困難な失敗です。

理由 2：タイムアウトを防ぐ。 同じ答えを返すクエリでも、書き方で実行時間が桁で変わります。ガイドには速度の階層が書かれています。

特定の IRI 指定  ≫  型による絞り込み  ≫  FILTER(CONTAINS(...))
     速い                              遅い（大規模グラフでは実質不可）

実測例: インスリンの配列を取るのに FILTER(CONTAINS(STR(?seq), "/P01308-1")) を使ったクエリは、60 秒のタイムアウトで落ちました。アイソフォームの IRI を直接指定する形に書き換えたら、約 5 秒で返りました。

3-6. 落とし穴 — 「間違った答え」ではなく「間違った件数」

生命科学 RDF の失敗の多くは静かに起きます。エラーは出ません。もっともらしい表が返ってきます。ただし数字が違います。

(a) フェデレーション（SERVICE）は使えない

複数のエンドポイントを 1 本のクエリで繋ぐ SERVICE 句は、rdfportal.org では無効化されています。正しいやり方は、同一エンドポイント内で GRAPH 句を使って結合するか、ID を持って手動で渡り歩く（第 4 章のやり方）です。

(b) 同居エンドポイントでの行数膨張

1 つの SPARQL エンドポイントに複数のデータセットが同居していることがあります。共有されるノード（生物種の IRI など）に対して、複数のデータセットがそれぞれ述語を宣言していると、グラフを指定しないクエリは全部を拾い、行数が黙って膨らみます。

対策は、MIE が指示するとおり FROM <グラフ名> でグラフを固定することです。

FROM <http://sparql.uniprot.org/uniprot>     ← これを書く

🔬 やってみる：罠を自分の目で見る

MIE に従っていると、この罠は一度も発火しません。 最初からグラフが固定されるからです。つまり、黙って守っていると罠があったことすら分かりません。

そこで、わざと破ってみます。

UniProt のヒトのライソゾーム内腔酵素を数えるクエリを、
FROM 句でグラフを固定した版と、固定しない版の両方で実行して、
件数を比較して見せて。COUNT(*) と COUNT(DISTINCT) の両方を出して。

最後の一文が重要です。これを付けないと、この罠は見えません。

実測（2026-08-21）:

ここが肝心です。 行数は 2 倍に化けましたが、COUNT(DISTINCT ?protein) は両方 98 で完全に一致しています。

つまり「グラフを固定しなかったら答えが変わる」という単純な話ではありません。COUNT(DISTINCT) を使っている限り、この例では答えが合ってしまいます。 危険なのは COUNT(*) のほうで、そちらを使っていたら 196 という誤った数字が、エラーも警告もなく返ってきます。

さらに悪いことに、膨張率は固定ではありません。対象によって 2 倍になったりならなかったりします。AVG や SUM を使う場合、あるいは再宣言された述語で結合を重ねる場合（k 本で 2^k 倍）には、DISTINCT では吸収しきれず答えそのものが狂います。

出どころを突き止める

「どこから重複が来たのか」は、こう聞けば分かります。

その2倍の行はどのグラフから来ているの？ GRAPH ?g で調べて。

実測では、a up:Protein という型付けを 2 つのグラフが供給していました ── UniProt 自身と、同じエンドポイントに同居している別のデータセット。同じ IRI に対して両方が型を宣言しているので、グラフを指定しないと 1 タンパク質あたり 2 行ヒットします。

この診断のしかた自体を覚えてください。 「怪しい件数が出たら GRAPH ?g で供給元を数える」は、そのまま実務で使えます。

(c) 多価の述語による重複 — こちらは実際に起きます

(b) を防いでも、まだ膨らむことがあります。1 つのエンティティが同じ述語を複数持つ場合です。

実測例: 第 4 章で使うライソゾーム内腔酵素の集合を数えると、こうなります。

COUNT(*)                    = 62
COUNT(DISTINCT ?protein)    = 52      ← 19% の差

原因は、1 つのタンパク質が EC 番号を複数持つことでした。実際に該当したのは 7 個で、たとえば ──

素朴に行数を数えていたら「ライソゾーム内腔酵素 62 個」と報告するところでした。正しくは 52 です。

教訓: 件数を報告する前に、COUNT(*) と COUNT(DISTINCT ...) を比べる。差があるなら、何が重複しているのかを説明できるまで報告しない。

第 7 章で、この検証手順を整理します。

3-7. まとめ

1. TogoMCP は「SPARQL を投げる道具」ではなく、「どう投げるべきかの知識を配る仕組み」である
2. ツールは ガイダンス層 / グラウンディング層 / 実行層 の 3 層
3. MIE ファイルが核心。検証済みの実行例を原子単位として、スキーマ・実例・罠を同時に伝える
4. ルール（MIE を先に読む、グラフを固定する）は、静かな失敗を防ぐためにある
5. 生命科学 RDF の失敗はエラーではなく件数のずれとして現れる

次 → 04. やや複雑な問い合わせ

04

04. やや複雑な問い合わせ

ここからが本番です。3 つ扱います。

1. デモ 4 — 検索だけでは答えられない問い（PDB）
2. デモ 3' — 複数データベースをまたぐ問い（UniProt × ChEMBL）
3. 失敗デモ — ★この章で最も重要

デモ 4：検索だけでは答えられない問い

SARS-CoV-2 の main protease (3CL protease) の PDB 構造を、
分解能の良い順に上位10件教えて。

実測 39〜51 秒。5 つのデモ中で最も堅牢（2 種類のモデルで測定し、いずれも失敗ゼロ・リトライゼロ）。

注目すべきは、途中で一度行き詰まること

最初に search_pdb_entity が走ります。結果は 1,872 件、順不同。

この検索ツールでは質問に答えられません。 「分解能の良い順に上位10件」を出すには、分解能という数値フィールドでソートする必要があり、それは検索 API ではなく SPARQL の仕事です。

だから次に get_MIE_file("pdb") → run_sparql と進みます。SPARQL が必要な理由が、画面の上で目に見える数少ないデモです。

結果（2026-08-21 実測）

手法別の内訳も取れます：X 線 1,799 / クライオ EM 25 / 中性子 4 / 溶液 NMR 3 / 電子線結晶 1（計 1,832、2026-08-21 実測）。

💡 この数字は動きます。 3 週間前の測定では計 1,822 でした。10 件増えています。データベースは生きています。

実行されたクエリ

PREFIX pdbo: <http://rdf.wwpdb.org/schema/pdbx-with-vrptx-v50.owl#>
PREFIX dc:   <http://purl.org/dc/elements/1.1/>
SELECT ?entry_id ?res (SAMPLE(?title) AS ?title)
FROM <http://rdfportal.org/dataset/pdb>
WHERE {
  ?entry a pdbo:datablock .
  FILTER(STRSTARTS(STR(?entry), "http://rdf.wwpdb.org/pdb/"))
  BIND(STRAFTER(STR(?entry), "http://rdf.wwpdb.org/pdb/") AS ?entry_id)
  ?entry pdbo:has_entityCategory/pdbo:has_entity ?ent .
  ?ent pdbo:link_to_enzyme <http://purl.uniprot.org/enzyme/3.4.22.69> .
  ?entry pdbo:has_entity_src_genCategory/pdbo:has_entity_src_gen/pdbo:link_to_taxonomy_source
         <http://purl.uniprot.org/taxonomy/2697049> .
  ?entry pdbo:has_exptlCategory/pdbo:has_exptl/pdbo:exptl.method "X-RAY DIFFRACTION" .
  ?entry pdbo:has_refineCategory/pdbo:has_refine/pdbo:refine.ls_d_res_high ?res .
  OPTIONAL { ?entry dc:title ?title }
}
GROUP BY ?entry_id ?res
ORDER BY ?res
LIMIT 10

このクエリで見るべき 3 点

1. 対象の絞り方が「標題のキーワード検索」ではない。 EC 番号の IRI（enzyme/3.4.22.69）と分類群の IRI（taxonomy/2697049）で絞っています。標題の文字列で絞ると、"Mpro" と書いていないエントリを取りこぼし、無関係なものを拾います。IRI で絞れるなら文字列で絞らない。

2. 分解能は X 線のみ。 クライオ EM の分解能は別の述語（em_3d_reconstruction.resolution）に入っています。この順位表は手法混在ではありません。それで正しいのですが、口に出して言うべきことです。

3. 結果は動きます。 9ZNL は比較的新しい構造です。明日 1.1 Å の構造が登録されれば順位が変わります。だから表ではなくクエリを保存してください。

デモ 3'：複数データベースをまたぐ

ヒトのライソゾーム酵素のうち、承認薬のターゲットになっているものを教えて。

UniProt（機能・局在のアノテーション）と ChEMBL（薬剤と標的の関係）を繋ぐ必要があります。実測 79 秒。

結果

ヒトのライソゾーム内腔酵素 52 種のうち、承認薬の作用機序ターゲットになっているのは 3 つでした。

💡 混同しやすい点。 ChEMBL でポンペ病（Glycogen Storage Disease Type II）の適応を持つのはミグルスタットであって、ミグリトールではありません。名前が似ています。

3 番目の PDGFRB は、行数だけ見ると結果を支配しています（14 薬剤のうち 11 剤）。しかしこれは受容体の取り込み・分解の文脈でライソゾーム内腔に注釈されているだけで、いわゆるライソゾーム酵素ではありません。スコープ定義がそのまま結果に効いた例です ── この直後の節で扱います。

PDGFRB を除くと、読み取れるのはこういう姿です。

この 52 種の範囲では、ライソゾーム酵素を直接狙う承認低分子は GLA のミガーラスタット 1 系統だけでした。 GAA の 2 剤は適応の違う糖尿病薬。

意外ではありません。ライソゾーム病は酵素を「阻害」するのではなく「補充」して治療するからです。

⚠️ 言い方に注意。 これは「世の中にミガーラスタットしかない」という主張ではありません。「GO:0043202 が付いたヒトの reviewed 酵素 52 種を ChEMBL の承認薬と突き合わせた結果、そうなった」という測定結果です。範囲を外して一般化すると、この教材が第 7 章で戒めていることを自分でやることになります。

★ 一番面白い着地点 ── GBA1 が 0 行

ゴーシェ病の原因酵素 GBA1（P04062）は 52 件に含まれているのに、承認薬側は 0 行でした。

ゴーシェ病治療薬のミグルスタットは、GBA1 ではなく基質合成酵素 UGCG（セラミドグルコシルトランスフェラーゼ）が標的です。そして酵素補充療法のイミグルセラーゼは ── 次の節で見るとおり ── 標的が基質側に登録されています。

「原因酵素 ＝ 創薬標的」ではないことが、データ構造のレベルで見えます。

ついでに、もう一つ良い教材が出てきます

同じゴーシェ病の薬でも、ミグルスタットとエリグルスタットで DB の見え方が違います。

エリグルスタットも UGCG 阻害剤ですが、それは文献で裏を取る必要があります。

教訓:「データベースに無いこと」は「事実でないこと」ではありません。

0 件が返ったとき、それは「存在しない」証拠ではなく「この経路では見つからない」証拠です。第 7 章でもう一度扱います。

⚠️ ここで最も重要なのは、最初の質問文が悪かったこと

「ライソゾーム酵素」をどう定義するかで、答えがまったく別物になります。

素直に UniProt のキーワード KW-0458「Lysosome」を使うと、161 タンパク質が該当します。しかしこれは細胞内局在のキーワードであって、「ライソゾーム酵素」ではありません。INSR（インスリン受容体）、PDGFRB、MTOR、PCSK9、LRRK2、そして 20 個ほどの RAB GTPase が入ってきます。

承認薬側の結果はこうなります：

インスリン製剤 22 種と、PDGFR キナーゼ阻害剤 12 種

「ライソゾーム酵素の承認薬」という見出しでこれを出したら、生物学者の部屋なら数秒で指摘されます。

EC 番号で 3.*（加水分解酵素）に絞っても直りません。 161 のうち 113 が生き残ります。RAB GTPase は EC 3.6.5.2 で、立派な加水分解酵素だからです。

効いた修正は、GO の用語に変えることでした。

up:classifiedWith obo:GO_0043202     # lysosomal lumen（ライソゾーム内腔）

候補が 161 → 52 に絞られ、GBA1・GLA・HEXA/HEXB・GAA・IDUA・IDS・ARSA/ARSB といった本物の内腔加水分解酵素が中心になります。

この章の教訓その 1: 答えが変なとき、間違っているのはクエリの文法ではなく、「対象をどう定義したか」であることが多い。

想定される質問

Q. イミグルセラーゼなどの酵素補充療法はなぜ出てこないのか？

イミグルセラーゼは ChEMBL に存在します（CHEMBL1201632、承認済み phase 4、作用機序も登録あり）。追跡するとこうなっています。

標的が「基質」であって、タンパク質ではありません。 酵素補充療法は「酵素を阻害する薬」ではなく「酵素そのものを補う薬」なので、ChEMBL では標的が基質側に立ちます。UniProt accession 経由の結合では、どうやっても引っかかりません。 データベースの表現として正しい挙動です。

Q. なぜ PDGFRB が混ざっているのか？

PDGFRB には本当に GO:0043202 が付いています。局在のアノテーション ≠ 機能の分類です。これは間違いではなく、あなたの問いの解像度が足りていないだけです。

Q. 同じ薬が 2 回出ているように見えるが？

塩形が別分子として登録されているためです（ミガーラスタット / 同塩酸塩、スニチニブ / 同リンゴ酸塩）。行数 ≠ 薬剤数。 16 行・14 薬剤ですが、実質的な有効成分は 12 です。

⚠️ 書いてはいけないクエリ

ChEMBL 側で「単一のタンパク質だけ」に絞りたくなりますが、やってはいけません。

?target a cco:SingleProtein .    # ← これを足すと

実測で 16 行 → 8 行、薬剤 14 → 7 に、エラーなく落ちます。 ボグリボースは「Alpha glucosidase」というタンパク質ファミリーに、PDGFRB の 7 剤は「PDGF receptor」という複合体に紐づいているためです。1 つの UniProt accession が、型の違う複数の標的実体に対応します。

これが「静かな失敗」の典型です。 エラーは出ず、件数だけが減ります。

★ 失敗デモ：この章の中心

ここからが、この教材で最も重要な部分です。

まず、悪い問いを投げる

がんに関係する遺伝子を教えて

実測 12〜22 秒。そしてツール呼び出しは 1 回、あるいは 0 回。 返ってくるのは、こういう流暢な答えです。

がんに関係する主な遺伝子には、がん抑制遺伝子として TP53、RB1、PTEN、APC、BRCA1/2、がん遺伝子として KRAS、MYC、EGFR、ERBB2 (HER2)、PIK3CA、ALK、BRAF などがあります。TP53 はヒトがんの約半数で変異が…

もっともらしい。速い。そして、データベースを参照していません。

ツールのログを開く

ここで見えるものは、使っているモデルによって変わります。 実測では 2 通りありました。

パターン① ── ログが空

何も呼ばれていません。 使い方ガイドすら読まれていません（そのガイド自身に「毎回まず私を呼べ」と書いてあるのに、です）。

27 個の遺伝子が、がん遺伝子とがん抑制遺伝子にカテゴリ分けまでされて、20 秒で返ってきました。そのどれ一つとして、いま調べたものではありません。

このときのモデルの自己申告がこれです。

「TogoMCP を読み込んでいて ── その使い方ガイドは『毎ターン［＝発言のたび］最初に呼べ』と自分で書いてある ── どれにも触れませんでした。教科書的な知識の想起として扱い、ツールがゼロ本繋がっているときと同じように答えました。」

結論は明白なので、パターン②は読み飛ばして次の節へ進んで構いません。

パターン② ── 検索が 1 回だけ

実行された唯一の検索はこれでした。

search_uniprot_entity(query="cancer AND organism_id:9606 AND reviewed:true", limit=20)

返ってきたもの：

Q9Y238  Deleted in lung and esophageal cancer protein 1
P51587  Breast cancer type 2 susceptibility protein
Q5HYN5  Cancer/testis antigen family 45 member A1
O00559  Receptor-binding cancer antigen expressed on SiSo cells
P35243  Recoverin (Cancer-associated retinopathy protein)
P78358  Cancer/testis antigen 1 (NY-ESO-1)
...

回答に並んだ TP53・KRAS・MYC・PTEN・RB1・APC は、この中に 1 つもありません。

偶然ではありません。この検索はタンパク質名の文字列に "cancer" が含まれるかを見ているだけです。TP53 の UniProt 名は "Cellular tumor antigen p53"、KRAS は "GTPase KRas"。"cancer" という文字列が入っていないので、原理的に到達不可能です。

データベースを触った形跡だけがあって、答えは記憶由来。

これがこの教材で最も伝えたい失敗モードです。

★ どちらのパターンでも、結論は同じ

パターン①は「触っていない」、パターン②は「触った形跡だけがある」。言い方は違いますが、答えが記憶由来であることは変わりません。

そしてここが重要です ── 画面の見た目からは、どちらなのか分かりません。 答えの流暢さも速さも同じです。ログを開いて初めて分かります。

💡 これはモデルに依存する挙動です。 あなたが手元で試したとき、ここに書いたのと違うことが起きるかもしれません。大事なのは「どのパターンだったか」ではなく、「ログを開いて確かめた」という事実のほうです。

なぜ危険なのか

画面上には、これに気づく手がかりが何もありません。答えは速く、流暢で、しかも内容としては概ね正しい（TP53 は確かにがん抑制遺伝子です）。

問題は正しさではなく、出どころが不明で、検証も反証も再現もできないことです。論文には書けません。

遅くて失敗するほうが、速くて自信満々に間違うより、はるかに安全です。

曖昧だったのは 3 つの軸

次に、同じ意図をきちんと仕様化して投げる

MeSH で 'Pancreatic Neoplasms' に対応するディスクリプタを特定した上で、
その疾患に関連付けられているヒト遺伝子を、典拠となるデータベースとフィールド名を
明示して、上位20件、関連の強い順に表で出して。件数はCOUNTでも裏取りして。

実測 182 秒、ツール呼び出し 8 回。約 15 倍のコスト。

何が変わったか

1. 対象が検証済みの ID に接地した。 search_mesh_descriptor が走り、MeSH D010190 が確定しました。以降のすべてのクエリがこの IRI に接地するので、文字列マッチが完全に消えました。

2. 典拠が言えるようになった。

3. 結果が出た。

4. そして COUNT の裏取りが、方法論の欠陥を暴きました。

D010190 が注釈された論文の総数            = 236,144
うち TP53 も共起する論文数（厳密・全件）  =  32,597

サンプル上の値（1,581）と厳密値（32,597）が約 20 倍ずれています。タイムアウト回避のために内側で LIMIT 20000 を掛けていたのですが、その 2 万件は一様なランダム標本ではなかったわけです。

しかも、ずれたのは絶対数だけではありませんでした。

標本は 236,144 件のうち 20,000 件 ＝ 8.47%。一様な標本なら、全件の値は標本値の 11.81 倍になるはずです。ところが実測倍率は 14.97 倍 〜 32.33 倍で、20 遺伝子すべてが期待値を上回り、遺伝子間で 2.2 倍のばらつきがありました。

その結果、順位が実際に入れ替わりました。

裏取りを要求しなかったら、間違った順位の表がそのまま通っていました。 絶対数だけでなく、順位そのものが信用できなかったのです。

なお、20 遺伝子を 1 本のクエリで厳密に数えようとしたら 60 秒でタイムアウトしました。3〜6 遺伝子ずつのバッチに分けて初めて完走しています。

裏取りを要求しなかったら、それらしい表がそのまま通っていました。

「COUNT でも裏取りして」というたった 1 行が、この教材で最も費用対効果の高い要求です。

★ そして、良い問いにしても限界は残る

ここで終わりにしないでください。仕様化した版の答えにも、はっきりした欠陥があります。

(a) 上位に生物学的でないものが混じっている

• INS（インスリン）6 位 — 膵臓という臓器の共起。膵がんの論文にインスリンが出てくるのは当然で、因果関係ではありません
• GAPDH 16 位 — 長年ハウスキーピング遺伝子として実験の内部標準に使われてきたため、多数の論文の Methods に登場するだけ
• POTEF 14 位 — アクチンのレトロ遺伝子が融合した霊長類特異的なキメラ遺伝子（UniProt A5A3E0 の記載名も "Chimeric POTE-actin protein"）。C 末端側が ACTB と高度に類似し、質量分析では ACTB 由来とされたペプチドの一部が POTEF/POTEE/POTEI/POTEJ と共有されることが報告されています
• ⚠️ ただし、それが「膵がん論文で 14 位に来る理由」かどうかは確認できていません。 配列類似による同定のあいまいさが疑われる、というところまでです。推測を断定に格上げしないこと ── この教材が第 7 章で戒めていることを、ここでやってはいけません

(b) 本物のドライバーが入っていない

膵がんの主要ドライバーである SMAD4 と CDKN2A が上位 20 圏外です。

なぜか。 共起論文数は「その遺伝子がどれだけ有名で、どれだけ論文が書かれているか」を測っており、疾患特異性を測っていないからです。TP53 は全がんで研究されているので、膵がん論文にも大量に登場します。

問いは「関連の強い順」と言いましたが、「どの関連か」までは指定していませんでした。 特異性が欲しければ、「全がんでの共起数で正規化して」といった追加の指定が要ります。

この章の教訓その 2: 良い問いは答えを良くする。しかし、良い問いにしてもなお残る限界がある。

検証は問いの改善で終わりません。第 7 章 へ。

この章のまとめ

1. 検索ツールでは答えられない問いがある。 そこで SPARQL が必要になる（デモ 4）
2. 答えが変なときは、文法ではなく「対象の定義」を疑う。 KW-0458 と GO:0043202 で答えがまったく変わった（デモ 3'）
3. 曖昧な問いは、12 秒で、データベースを参照せずに、もっともらしく間違う（失敗デモ）
4. 仕様化すると 15 倍のコストがかかるが、典拠が言え、誤りを自分で見つけられる
5. 仕様化してもなお限界はある。 テキストマイニングの共起は因果ではない

次 → 05. スキル ／ 先に 06. 良い問いの書き方 へ進んでも構いません

05

05. スキルを使ったワークフロー

MCP と スキルの違い

ここまで扱ってきた MCP は 「能力」 です ── 何ができるか。UniProt を引ける、SPARQL を投げられる、ID を変換できる。

スキルは 「方法論」 です ── どういう手順でやるか。

同じ道具を持っていても、手順書があるかないかで結果の質は変わります。これは第 4 章で見たとおりです。同じツール群を使いながら、曖昧な問いは 12 秒でデータベースを参照せずに答え、仕様化した問いは自分の誤りを発見しました。その差を再現可能な形でパッケージ化したものがスキルです。

MCP  = 道具箱（何ができるか）
Skill = 手順書（どう使うか、どの順で、何を検証するか）

スキルは、この教材の第 6 章・第 7 章でやってきたことを、毎回手で書かなくて済むようにしたものと考えてください。

3 つのスキル

TogoMCP のリポジトリには、以下のスキルが含まれています。

入手先: https://github.com/dbcls/togomcp （.claude/skills/ 以下）

Claude Code で使う場合、スキルのディレクトリを ~/.claude/skills/<名前>/ に置くと全プロジェクトで、プロジェクト直下の .claude/skills/<名前>/ に置くとそのプロジェクトで有効になります。リポジトリを clone してその中で claude を起動するのが最も簡単です。

research-article-analysis — 論文の主張をデータベースで検証する

何をするか: 論文を渡すと、その本文を信じずに、主張を 1 つずつデータベースに照合します。

分子式、反応式、パスウェイ、タンパク質の機能、GO の定義 ── それぞれについて ChEBI → Rhea → UniProt → Reactome → GO という証拠チェーンを構築し、主張ごとに検証結果を返します。

なぜ効くか: キーワード検索で得られる断片（「この論文にはこう書いてある」）ではなく、独立した典拠に当てるからです。論文の記述が正しいかどうかは、その論文の中を読んでも分かりません。

使いどころ: 査読、追試の前の下調べ、引用しようとしている論文の確認、自分の原稿の事実確認。

この論文の生物学的な主張をデータベースで検証して。
（PDF を添付、または DOI / PMID を指定）

disease-analysis — 疾患を多階層でマッピングする

何をするか: 1 つの疾患を、分子 → 経路 → 細胞 → 組織 → 臨床 → 治療の各階層に分けて記述します。TogoMCP に加えて TogoID・OLS4・PubMed を組み合わせます。

なぜ効くか: 疾患の情報は階層ごとに別のデータベースに散っています。分子欠損は UniProt、経路は Reactome、表現型は HP、疾患概念は MONDO/MeSH、治療は ChEMBL。手で繋ぐと半日かかる作業です。

使いどころ: 馴染みのない疾患を短時間で把握する、研究計画の初期調査、共同研究の相手の分野を理解する。

ファブリー病の病態を分子レベルから臨床症状まで多階層で分析して。

PRISM — 複数の条件の交差を取る

何をするか: 「A でもあり B でもある」エンティティを見つけます。名前は Predicate-defined, Reproducible, Identifier-bridged, Set-intersection Mining の頭文字。

• 「疾患 X に関連し、かつ創薬可能な標的」
• 「経路 P に関与し、かつ既存薬で調節されている遺伝子」
• 「表現型 Q に関連し、かつ酵素 A の基質でもある化合物」

なぜ効くか、そして最も重要な点: PRISM は各条件（軸）を、再現可能な述語として定義することを強制します。オントロジーの階層に沿って展開し、複数の証拠源で三角測量し、安定した ID で交差を取り、provenance ledger（典拠台帳）を残します。

これは第 7 章の検証 4 手順を、自動で、漏れなくやるための仕組みです。

スキルの説明文に、こういう一文があります ── 「候補遺伝子を記憶から挙げそうになったら、止めて PRISM を使え」

第 4 章の失敗デモそのものです。

使いどころ: ドラッグリポジショニング、創薬標的の同定、「この 2 つの集合に共通するものは？」型の問い。

◯◯病に関連し、かつ既存の承認薬で調節可能な遺伝子を PRISM で探して。

実績のある適用例として、加齢黄斑変性の脂質輸送、ポンペ病の解析があります。

試してみるには

スキルはリポジトリに入っています。最初に試すなら research-article-analysis を勧めます ── 入力が論文 1 本で分かりやすく、出力が「主張ごとの検証結果表」になるので、何が起きたかが読み取りやすいからです。

自分の分野の論文を 1 本渡して、主張がどこまでデータベースで裏付けられるかを見てみてください。第 7 章の検証作法が、そのまま自動化されているのが分かります。

スキルを使うべきかの判断

スキルの本質的な価値は、あなたが疲れていても、急いでいても、同じ手順が踏まれることです。第 4 章の失敗デモが示したように、手順を省くと 12 秒で答えが出てしまいます。そして省いたことは画面に表示されません。

自分でスキルを作る

スキルは Markdown ファイルです。SKILL.md に、いつ使うか（description）と、どういう手順で作業するかを書きます。

あなたの研究室に固有の手順 ── 「うちの解析では必ずこの 3 つの DB を当てて、この形式で表にする」── があるなら、それをスキルにできます。TogoMCP リポジトリの既存スキルが実例になります。

次 → 06. 良い問いの書き方

06

06. 良い問いの書き方

この章は、非情報系の研究者にとって最も持ち帰り価値が高い部分です。

以下の 5 要素は一般論ではありません。第 4 章の失敗デモで、同じ意図の 2 つの問いを実際に走らせて観察された因果です。

対比の全体像

12 秒は速いのではありません。何もしていないから速いのです。

良い問いの 5 要素

1. 正規語彙と特定手段で対象を与える

「MeSH で 'Pancreatic Neoplasms' に対応するディスクリプタを特定した上で」

曖昧版で何が起きたか: 「がん」という語がそのまま全文検索に流れ、「タンパク質名に "cancer" の文字列を含むか」というまったく別の意味に化けました。到達したのは NY-ESO-1 と recoverin。

仕様化版で何が変わったか: search_mesh_descriptor が呼ばれ、D010190 という検証済み IRI が生まれました。以降のすべてのクエリがこの 1 個の IRI に接地したため、oa:hasBody <mesh/D010190> という厳密な構造化照合になり、文字列マッチが消えました。

語彙名を指定するだけで、ツール選択が「全文検索」から「ID 解決 → 構造化照合」に切り替わる。

使える語彙の例：MeSH（疾患・医学概念）、GO（機能・局在・プロセス）、MONDO / NANDO（疾患）、HP（表現型）、UBERON（解剖）、ChEBI（化合物）、NCBI Taxonomy（分類群）。

2. 典拠（DB 名・フィールド名）の明示を要求する

「典拠となるデータベースとフィールド名を明示して」

曖昧版: 出典を要求されなかったので、MIE を読む理由が発生しませんでした。SPARQL を書かないのでグラフを固定する機会もゼロ。記憶からの列挙が「出典なしでも成立してしまう」構造でした。

仕様化版: 出典を書く義務が生じた瞬間、get_MIE_file(pubtator) が必須の前段になりました。その MIE が 3 つの落とし穴を事前に開示しました ── 述語の値が大文字固定であること、対象グラフが 1 つに決まること、そして遺伝子の注釈が生物種を区別しないこと。

「出典を書け」は書式の要求ではなく、スキーマを読ませるトリガとして機能する。

3. 生物種・対象範囲を明示する

「ヒト遺伝子を」

曖昧版: ユーザは種を言っていないのに、勝手に organism_id:9606 が付きました。ユーザに見えない形での仕様の捏造です。もし対象がマウスだったら、誰も気づかないまま間違った答えが返っています。

仕様化版: MIE の警告（この文献注釈データはヒトとモデル生物のオーソログを区別しない）に対して、分類群でのフィルタという具体的な対処が発動しました。この処理がなければ、マウス・ラットの同名遺伝子が混入し、エラーもゼロ件も出さずに数字が膨らんでいました。

種の指定は「絞り込み」ではなく、サイレントな混入を防ぐ処理を発生させるスイッチ。

4. 件数と順序基準を数値で固定する

「上位20件、関連の強い順に表で」

曖昧版: 件数指定がないので勝手に「10 個くらい」が決まり、順序は「有名な順」という定義不能な基準になりました。検証も反証もできません。

仕様化版: 「上位 N・順序付き」が GROUP BY … ORDER BY DESC(COUNT(DISTINCT ?article)) LIMIT 20 という実行可能な定義に翻訳されました。同時に「関連の強さ ＝ 共起論文数」という操作的定義が明文化されたため、第 4 章で述べた批判 ── 共起は因果ではない ── が言語化できるようになりました。曖昧版には、批判すべき定義そのものが存在しませんでした。

順序基準を要求すると、「強さ」を測定可能な量に還元せざるを得なくなる。その還元の妥当性は、還元が明示されて初めて議論できる。

5. 独立した手段での裏取り（COUNT）を要求する

「件数はCOUNTでも裏取りして」

5 要素中、最も効きました。

これがなければ「TP53 = 1,581」という表がそのまま出て終わりでした。COUNT により、疾患の総論文数 236,144 と TP53 の厳密共起 32,597 が得られ、両者の比が合わないことから 「内側の LIMIT で取った 2 万件は一様標本ではない」という方法論的欠陥が発見されました。

そして厳密に数え直したところ、順位そのものが入れ替わりました ── MTOR が 20 位から 9 位へ、INS が 6 位から 16 位へ。絶対数だけでなく、順位も信用できなかったわけです。

「COUNT で裏取り」は答え合わせではなく、サンプリングバイアスや集計の罠を露出させる検出器。1 行の追加要求に対するリターンが最大。

そのまま使えるテンプレート

汎用テンプレート

【対象】を、【語彙】の【ID/用語】で特定した上で、
【求める関係】に該当する【出力の単位】を、
【件数】件、【順序基準】の順に、
典拠となるデータベース名とフィールド名を明示して表で出して。
件数は COUNT でも裏取りして。

用途別

あるタンパク質について調べる

ヒトの ◯◯ を UniProt で特定して（accession を明示して）、
機能・配列長・細胞内局在・関連する疾患を、
それぞれ UniProt のどのフィールド由来かを示して整理して。

ある機能を持つタンパク質を列挙する

GO の ◯◯（GO:XXXXXXX）が付与されたヒトのタンパク質を、
reviewed のものに限って列挙して。
件数は COUNT(DISTINCT) と COUNT(*) の両方を出して、
差があるなら何が重複しているか説明して。

疾患に関連する分子を調べる

MeSH（または MONDO）で ◯◯ に対応するIDを特定した上で、
関連付けられているヒト遺伝子を上位N件、
関連の強さの定義を明示して列挙して。
その定義が測っているものと測っていないものも書いて。

構造を条件付きで探す

◯◯ の PDB 構造を、【実験手法】に限って、
分解能の良い順に上位N件。
実験手法ごとの件数の内訳も出して。

ID をまたぐ

この ID 群を ◯◯ に変換して。
変換できなかったものがあれば、それも明示して。

最後の「変換できなかったものも明示して」は重要です。黙って減った件数が一番危険です。

逆に、やってはいけない聞き方

最後の行は特に効きます。「合ってる？」ではなく「反証を探して」と聞いてください。

コストについて

5 要素をすべて満たすと、約 15 倍の時間がかかります。毎回やる必要はありません。

論文に書く数字については、必ず 5 要素を満たしてください。12 秒で返ってきた数字を論文に書くと、査読で聞かれたときに答えられません。

次 → 07. 検証と再現性

07

07. 結果を信じる／疑う — 検証と再現性

第 6 章で見たとおり、良い問いは答えを良くします。しかし、良い問いにしてもなお残る限界があります。 この章はそこを扱います。

前提として一つ。

AI の出力をそのまま論文に書くことはできません。

これは AI が信用ならないからではなく、あなたが検証した記録がないと査読に答えられないからです。実験ノートを取らずに実験結果を報告しないのと同じことです。

7-1. 実際に観測された失敗モード 5 種

いずれも第 4 章の実測で起きたものです。すべてエラーを出しません。

(a) 件数の膨張

COUNT(*)                 = 62
COUNT(DISTINCT ?protein) = 52      ← 19% の差

1 つのタンパク質が EC 番号を複数持つために起きていました（GBA1 は 4 個、ASAH1 は 3 個）。素朴に行数を数えていたら「ライソゾーム内腔酵素 62 個」と報告するところでした。

(b) サンプリングの偏り

タイムアウト回避のために内側で 2 万件に制限したところ、

サンプル上の TP53 共起数  =  1,581
全件での TP53 共起数      = 32,597      ← 約 20 倍

「TP53 は膵がん論文 1,581 報に登場する」と書いていたら誤りです。

さらに悪いことに、順位そのものも入れ替わりました ── MTOR が標本 20 位から全件 9 位へ、INS が 6 位から 16 位へ。「絶対数はずれても順位は信じてよい」という逃げ道すらありませんでした。

(c) 定義の取り違え

UniProt のキーワード KW-0458「Lysosome」は細胞内局在であって「ライソゾーム酵素」ではありません。これを使うと、承認薬側の結果がインスリン製剤 22 種と PDGFR 阻害剤 12 種に支配されました。

文法は完全に正しく、実行も成功し、答えは無意味でした。

(d) 集計単位の誤読

TogoVar でバリアントを調べたとき：

457 はバリアント数ではありません。 「バリアント × 条件」の組の数です ── 1 つのバリアントが複数の疾患に紐づくため。consequence はさらに「バリアント × 転写産物」なので 14 倍に膨れます。

しかも直感に反することが起きます。 「病原性」で絞ったのに、内訳には Uncertain significance が 35 件、Likely benign が 1 件出てきます。矛盾ではありません ── フィルタはバリアント単位、内訳はバリアント × 条件レコード単位だからです。実際、1 個のバリアント（rs421016）だけでも 13 レコードあります。

ツール自身が statistics_caveats で警告を返してきます。読んでください。

"significance": "... counted PER VARIANT-CONDITION classification record ... Do NOT compare the sum to \filtered`."`

(e) 指標が測っているものの誤解

膵がんの関連遺伝子として、INS・GAPDH・POTEF が上位に来ました。いずれも膵がんのドライバーではありません。

• INS — 膵臓が内分泌器官であることによる臓器の共起
• GAPDH — ハウスキーピング遺伝子として実験の内部標準に言及されているだけ
• POTEF — アクチンのレトロ遺伝子が融合したキメラ遺伝子で、ACTB と配列が高度に類似する

⚠️ ここで一つ、この教材自身の失敗を告白します。 初稿では POTEF を「遺伝子正規化の既知の偽陽性源」と書いていました。もっともらしいので、そのまま通るところでした。 検証したところ、PubMed に POTEF の論文は全 17 報しかなく、そのどこにもこの主張の裏付けはありませんでした。

確認できたのは「ACTB とペプチドを共有する」という別の事実だけで、それが PubTator の順位の原因かどうかは分かっていません。

これがこの章の主題そのものです。 検証しないと、自分の推測が自分の文章の中で事実に格上げされます。

逆に、真のドライバーである SMAD4・CDKN2A は上位 20 圏外でした。共起論文数は「有名度 × 論文数」を測っており、疾患特異性を測っていないからです。

7-2. 検証の 4 手順

論文・報告に使う数字については、例外なくこれをやってください。

手順 1：実行されたクエリを出させて、保存する

いま実行した SPARQL を全文そのまま出して。使ったエンドポイントも。

要約させないでください。 全文が要ります。これが実験ノートにあたります。

手順 2：COUNT で件数を裏取りする

その結果の件数を、COUNT(DISTINCT ...) と COUNT(*) の両方で出して。
差があるなら、何が重複しているのか説明して。

差があるのは異常ではありません。説明できないまま報告するのが異常です。

サンプリング（内側の LIMIT）が使われた場合は、さらに：

LIMIT なしの全件で同じ集計をすると、この数字はどうなる？
重すぎるなら、上位数件だけ厳密に数え直して比較して。

これで (b) のサンプリング偏りが検出できます。

手順 3：元のデータベースで 1〜2 件を目で確認する

これを飛ばさないでください。 30 秒で済みます。

上位 1 件と、下位または「意外な」1 件を見てください。意外な 1 件のほうが情報量があります ── PDGFRB がライソゾーム酵素のリストに入っていたのは、目視で気づけます。

手順 4：実行日とエンドポイントを記録する

データベースは更新されます。「いつ」問い合わせたかがない結果は再現できません。

7-3. 再現性のために保存するもの

問い合わせ 1 件につき、以下を残してください。

├─ query.rq          実行された SPARQL の全文
├─ endpoint.txt      エンドポイントの URL とグラフ名
├─ result.csv        結果そのもの
├─ counts.txt        COUNT による裏取りの結果
└─ meta.txt          実行日時、元の質問文、★モデル名、★クライアント、
                     使ったツールとバージョン

meta.txt に「元の質問文」を入れるのを忘れないでください。 半年後、なぜその絞り込みをしたのかを思い出す唯一の手がかりです。

★ モデル名を記録する — LLM を介した問い合わせに固有の要件

普通の SPARQL なら、クエリとエンドポイントと日付があれば再現できます。LLM を介した場合はそれだけでは足りません。

同じ質問文でも、モデルが違えば挙動が変わります。 この教材の実測でも、こういう差が出ました。

答えの中身が同じでも、そこに至る過程が違います。 「なぜこの答えになったのか」を後から検証するには、モデルの記録が要ります。

したがって meta.txt には最低限これを：

• モデル名（例: claude-opus-5 / claude-sonnet-5）
• クライアント（Claude デスクトップ / Web / Claude Code / API）
• MCP サーバ（ホスト版か、ローカル導入か。バージョンが分かれば併記）

⚠️ 注意: 「設定したモデル」と「実際に処理したモデル」は必ずしも一致しません。フォールバックや切り替えが起こりえます。厳密には「設定は〜」と書くのが正確です。この教材の測定記録もその書き方をしています。

Claude にまとめて出させることもできます。

いまの問い合わせについて、
(1) 実行した SPARQL 全文 (2) エンドポイントとグラフ名
(3) 結果の CSV (4) COUNT の裏取り (5) 実行日時と元の質問文
を、そのままファイルに保存できる形で出して。

💡 第 5 章の PRISM スキルは、この記録を構造化して自動的に残す仕組み（provenance ledger）を持っています。手作業が面倒になったら検討してください。

7-4. 論文に書くときの作法

引用は 2 段構え

TogoMCP と、実際に使った個々のデータベースの両方を引用してください。TogoMCP は入り口であって、データの出どころではありません。

Kinjo, A. R., Yamamoto, Y., Bustamante-Larriet, S., Labra-Gayo, J.-E., & Fujisawa, T. (2026). TogoMCP: Natural Language Querying of Life-Science Knowledge Graphs via Schema-Guided LLMs and the Model Context Protocol. Database 2026:baag042. https://doi.org/10.1093/database/baag042

加えて UniProt、PDB、ChEMBL など、実際に参照したデータベースそれぞれの引用を。

方法欄に書くべきこと

• 使ったデータベースとバージョン／リリース、アクセス日
• 実行したクエリ全文（補足資料に）
• 対象の絞り込みに使った識別子（GO:0043202、MeSH D010190 など。名前ではなく ID で）
• サンプリングや LIMIT を使った場合はそのこと自体と、その影響

最後の項目を書ける人は多くありません。書けると強いです。

書いてはいけないこと

• 「AI に聞いたところ」 ── 方法ではありません
• 検証していない数字
• 出どころを言えない主張

7-5. 向いている用途／向いていない用途

正直に。

向いている

• 探索と仮説生成 ── 「この機能を持つタンパク質で、まだ薬のないものは？」
• 横断的な確認 ── 「この ID は他の DB で何と呼ばれている？」
• 既知の整理 ── 散らばった情報を 1 つの表にまとめる
• SPARQL の下書き ── 自分で書き直す前提の叩き台として（これは非常に有効です）
• 見落としの発見 ── 自分の分野の外にある関連を拾う

向いていない

• 網羅性が要件の解析 ── 「すべての」を保証できません。系統解析やメタ解析の母集団構築には向きません
• 統計的推論 ── 件数は返しますが、検定や効果量の設計はあなたの仕事です
• 臨床判断 ── 絶対に使わないでください。TogoVar の病原性分類は ClinVar の登録内容であって、診断でも助言でもありません
• 一次データの生成 ── 既存のデータベースを引くだけです。新しい測定はしません
• 専門的判断の代替 ── PDGFRB がライソゾーム酵素かどうかを判断したのは、この教材ではあなたです

7-6. その他の注意

ライセンス。 KEGG はアカデミック機関所属者に限定されており、公開サービスでの提供には別途ライセンスが必要です（付録）。各データベースにも利用規約があります。商用利用の前に確認してください。

個人情報。 TogoVar が返すのは集計値（アレル頻度、登録件数）であって個人レベルのデータではありません。管理アクセスのデータセットはコホートの件数としてのみ現れます。ただし ClinVar の条件記述には症例由来の表現型が含まれることがあります。公開情報ですが、「我々が見つけた患者」のように語らないでください。

疾患情報の扱い。 特定のバリアントに複数の疾患が紐づいていることがあります（あるバリアントにはゴーシェ病とパーキンソン病の両方が）。これは ClinVar の分類として述べるべきものであって、リスクの助言ではありません。プレゼンで見せるときは特に注意してください。

この章のまとめ

1. 失敗はエラーではなく、正しく見える数字として現れる
2. 検証の 4 手順 ── クエリを残す／COUNT で裏取り／元 DB で目視／日付を記録
3. 保存すべきは結果の表ではなくクエリ
4. 引用は TogoMCP ＋ 個々のデータベースの 2 段構え
5. 向いていない用途がある。 特に網羅性の保証と臨床判断

次 → 08. トラブルシュート

08

08. トラブルシュート

接続できない

クエリが失敗する・遅い

60 秒でタイムアウトする

SPARQL には実行時間の上限があります。同じクエリを投げ直さないでください。 同じ結果になります。

対処を、効果の大きい順に：

1. 対象を IRI で絞る。 FILTER(CONTAINS(...)) や FILTER(regex(...)) は大規模グラフでは実質的に使えません。IRI を直接指定できないか検討してください。

実測例: FILTER(CONTAINS(STR(?seq), "/P01308-1"))  → 60 秒でタイムアウト
        IRI を直接指定する形に書き換え           → 約 5 秒

2. OPTIONAL を減らす。 1 つ増えるごとに重くなります。まず必須部分だけで動かし、後から足してください。

3. LIMIT を掛ける。 ただし ⚠️ 内側の LIMIT は一様標本ではありません。 第 7 章を必ず読んでください。件数を報告するなら別途 COUNT が要ります。

4. 段階に分ける。 1 本の巨大なクエリより、ID を取ってから次を投げるほうが速く、途中経過も見えます。

Claude にこう頼めます：

そのクエリが重い。IRI で絞る形に書き換えられない？
OPTIONAL を減らすか、2 段階に分ける案も出して。

0 件しか返らない

エラーが出ていないのに 0 件は、最も危険なパターンです。 述語名やグラフ名が間違っていても SPARQL はエラーを出しません。

確認の順序：

1. MIE を読んだか。 読まずに書いたクエリの述語名は推測です ◯◯ の MIE ファイルを確認して、使った述語名が実在するか照合して
2. グラフ名は正しいか。 グラフ名は改名されることがあります。古い名前を指定すると静かに 0 件になります
3. 絞り込みを 1 つずつ外す。 どの条件で 0 になるかを特定します 条件を1つずつ外して、どこで結果が消えるか調べて
4. ID そのものを疑う。 変換元の ID が存在しない・改名されている可能性

件数がおかしい

第 3 章と第 7 章へ。要点だけ：

COUNT(DISTINCT ...) と COUNT(*) の両方を出して。差があるなら何が重複しているか説明して。

膨らむ主な理由は 2 つ ── グラフを固定していない、述語が多価（1 つのエンティティが同じ述語を複数持つ）。

答えが間違っている・変

まず疑うのは文法ではなく「対象の定義」

第 4 章の実例：「ライソゾーム酵素」を UniProt のキーワード KW-0458 で定義すると、インスリン受容体と mTOR が入り、承認薬の結果がインスリン製剤に支配されました。文法は完全に正しく、実行も成功していました。

この結果に含まれるべきでないものが入っている気がする。
対象をどう定義したのか、その定義が何を含んで何を含まないのか説明して。

データベースを参照していない疑いがあるとき

症状: 答えが速すぎる（10 秒台）、ツールのログに run_sparql や検索ツールが出ていない、accession や ID が付いていない。

その答えの根拠になったツール呼び出しを列挙して。
データベースから取得した値と、そうでない値を分けて示して。

これで「実は記憶から答えていた」が炙り出せます。→ 第 4 章の失敗デモ

AI が同意してくる

「合ってる？」と聞くと同意しがちです。反証を要求してください。

この主張に反する証拠をデータベースから探して。

エンドポイントが落ちている

実際に起きます。 2026 年 8 月には rdfportal.org の全 SPARQL エンドポイントが不通になったことがあります。

見分け方: 特定のクエリだけでなく、どのデータベースへの run_sparql も失敗する。一方で get_MIE_file や使い方ガイドは普通に応答する（これらはサーバ内のファイルなので、外部エンドポイントに依存しません）。

対処:

1. 時間をおく。 復旧を待つ以外にありません
2. REST 系のツールに切り替える。 togovar_*、ncbi_*、search_chembl_* などは別系統なので、SPARQL が落ちていても動くことがあります

SPARQL エンドポイントが応答しない。同じ問いに REST 系のツールだけで答えられる？

それでも解決しない

• リポジトリの Issue: https://github.com/dbcls/togomcp
• ホスト版の状況: https://togomcp.rdfportal.org/

報告するときは、実行されたクエリ全文・エンドポイント・実行日時・エラーメッセージを添えてください（→ 第 7 章の保存形式がそのまま使えます）。

付録

付録：ローカル導入（経路 C）

開発者向け、および KEGG ツールを使う場合の唯一の経路です。

通常の利用には不要です。経路 A（カスタムコネクタ）で十分機能します。以下が必要になるのは：

• KEGG ツールを使いたい（アカデミック機関所属者に限る）
• MIE ファイルを書く・直す
• サーバ自体を開発する
• 組織内に自前でホストする

前提

• Python >= 3.11
• uv パッケージマネージャ

uv を入れる

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

導入

git clone https://github.com/dbcls/togomcp.git
cd togomcp
uv sync

NCBI API キー（NCBI 系ツールを使う場合は必須）

NCBI のドキュメントからキーを取得して：

export NCBI_API_KEY="your-key-here"

Claude Desktop の設定

設定ファイルの場所：

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: ~\AppData\Roaming\Claude\claude_desktop_config.json

{
    "mcpServers": {
        "togomcp": {
            "command": "/path/to/uv",
            "args": [
                "--directory",
                "/path/to/togomcp",
                "run",
                "togo-mcp-local"
            ],
            "env": {
                "NCBI_API_KEY": "your-key-here"
            }
        }
    }
}

💡 uv の絶対パスは which uv（macOS/Linux）または where uv（Windows）で調べられます。相対パスや uv だけでは動きません。

設定後、Claude Desktop を完全に終了して再起動してください。

KEGG（オプトイン・ローカル stdio 限定）

KEGG は既定でオフです。必要ありません。TogoMCP は KEGG なしで完全に機能します。 この節は、資格があって、かつ使いたい場合にのみ関係します。

kegg_find / kegg_get_entry / kegg_conv / kegg_link / kegg_pathway_graph / kegg_pathway_neighborhood / kegg_pathway_paths / kegg_pathway_cycles の 8 ツールは、次の 2 条件が両方成立したときだけ有効になります。

1. ローカルの stdio エントリポイント togo-mcp-local で動かしている
2. TOGOMCP_ENABLE_KEGG=1 を設定している

なぜ 2 つの門があるのか — 理由は別々です

(1) 通信経路の制限は構造的なもので、設定では変えられません。

KEGG API は「アカデミック機関に所属するアカデミックユーザーの学術利用のため」に提供されており、KEGG を用いたサービスの提供には別途 academic service-provider license が必要です（KEGG の利用条件）。

公開サーバは呼び出し元の所属を検証できません。したがって togomcp.rdfportal.org を含むあらゆる HTTP 配備は rest.kegg.jp に到達しません。環境変数では変えられません ── TOGOMCP_ENABLE_KEGG は HTTP 経路に対して何の効果もありません。

(2) オプトインが存在するのは、資格の主張があなたのものだから。

stdio ではあなた自身が呼び出し元です。しかし、あなたの所属機関のアクセス権があなたを含むかどうかは、あなたにしか分かりません。

既定で KEGG を有効にすると、あなたに権利がないかもしれない API 呼び出しを、最も抵抗の少ない経路に置くことになります。AI アシスタントは、見えている道具は使います。アカデミック用途でない利用者にとって、変数を設定しないことが正しい構成であり、他には何の影響もありません。

有効にする

"env": {
    "NCBI_API_KEY": "your-key-here",
    "TOGOMCP_ENABLE_KEGG": "1"
}

制約

• 呼び出しは 毎秒 3 リクエストに制限されます（プロセス全体で強制。403/429 のリトライは行いません）
• KEGG は RDF Portal の一部ではありません。 SPARQL エンドポイントを持たないので、run_sparql で database="kegg" は無効です
• RDF データベースと繋ぐには、kegg_conv で KEGG の識別子を UniProt / NCBI Gene / NCBI Protein / ChEBI / PubChem に変換してから使ってください

Docker

cp .env.example .env                                # NCBI_API_KEY を記入
docker build -t localhost/togo-mcp:latest .
docker compose up -d togomcp-main                   # ポート 8000

compose.yaml は togomcp-main（8000）と togomcp-test（8001）の 2 サービスを定義しているので、本番と検証を同じイメージから並走させられます。

docker compose logs -f togomcp-main    # ログ
docker compose down                    # 停止・削除

リバースプロキシの背後に置く場合

2 つの環境変数が効いてきます。どちらも誤診しやすい壊れ方をします。

TOGOMCP_ALLOWED_HOSTS — Host ヘッダが検証され（DNS リバインディング対策）、許可リストにないホストには 421 を返します。既定は localhost と DBCLS の公開 vhost のみ。自分のホスト名を追加しないと、プロキシ経由のリクエストが全部拒否されます。

TOGOMCP_FORWARDED_ALLOW_IPS — どのピアアドレスが X-Forwarded-Proto / -For を設定してよいか。uvicorn は既定で 127.0.0.1 しか信用せず、公開ポート経由のコンテナはループバックとして到着しません。設定を誤ると、ヘッダは拒否されず黙って捨てられます。するとアプリは平文 HTTP で提供していると信じ込み、https:// を http:// に降格するリダイレクトを吐きます。

プロキシ側も X-Forwarded-Proto を送る必要があります。 nginx は既定で送りません：

proxy_set_header X-Forwarded-Proto $scheme;

Caddy と Traefik は送ります。両方が揃って初めて機能します。片方だけでは動きません。

ツール呼び出しログ（オプション）

TogoMCP は全ツール呼び出しを 1 行 1 JSON で記録できます（タイムスタンプ、ツール名、引数、状態、所要ミリ秒、セッション/リクエスト/クライアント ID、トランスポート、クライアント IP）。SPARQL 呼び出しにはエンドポイント URL、HTTP コード、行数・バイト数、クエリの SHA-256 が付きます。

ベンチマーク、MIE の改良、複数ツールにまたがる手順の再構成に有用です。 第 7 章の再現性の記録を自動化したい場合にも使えます。

オン・オフは環境変数 TOGOMCP_QUERY_LOG ひとつ。未設定＝無効（オーバーヘッドゼロ）。書き込み可能なファイルパスを設定すると有効になります。

Claude Desktop（ローカル stdio）の場合、env ブロックに追加します。絶対パスを使い（起動プロセスの作業ディレクトリは予測できません）、親ディレクトリを先に作っておいてください：

"env": {
    "NCBI_API_KEY": "your-key-here",
    "TOGOMCP_QUERY_LOG": "/Users/you/togomcp-logs/togomcp.jsonl"
}

mkdir -p ~/togomcp-logs

そのあと Claude Desktop を完全に再起動します。

⚠️ プライバシー: IP は既定でソルト付きハッシュ（ip_hash）として記録されます。TOGOMCP_LOG_RAW_IP=1 を設定すると平文でも記録され、不正利用者の特定・遮断が可能になりますが、ログが個人データになります。フィールドごとの詳細はリポジトリの log_file_specs.md を参照。

データベースを追加する場合（開発者向け）

5 箇所あります。2 箇所ではありません。 最初の 2 つだけがサーバの検証に影響し、残りは静かにずれていくドキュメント面です。テストがそれを捕まえます。

1. togo_mcp/data/resources/endpoints.csv — 登録行（これだけが有効な database= 値を決めます）
2. togo_mcp/data/mie/<db>.yaml — MIE ファイル（仕様は togo_mcp/data/docs/ に）
3. uv run python scripts/generate_usage_guide_catalog.py — 使い方ガイドのデータベース目録を再生成
4. togo_mcp/data/resources/usage_guide_v6/02_budgets_and_discovery.md — 生成器が触らない手書きの写し。件数とキーの両方を更新
5. togo_mcp/data/docs/togomcp-intro.html — ランディングページのカード（非生成）

← 目次に戻る

演習

自己確認の演習

解答例は solutions-ja.md にあります。先に自分でやってから見てください。

難易度：★ 基本 ／ ★★ 応用 ／ ★★★ 発展

⚠️ 実行結果の数値は日々変わります。解答例と数字が違っても、それ自体は誤りではありません。考え方と、そこに至る手順を照合してください。

演習 1 ★ — 接続確認と最初の問い合わせ

(a) TogoMCP が接続できていることを確認してください。

(b) あなたの関心のあるヒトのタンパク質を 1 つ選び、UniProt エントリを調べてください。accession、配列長、機能を得ること。

(c) 返ってきた accession を UniProt の Web サイトで確認してください。合っていましたか。

(d) 配列長は、あなたが期待した長さでしたか。違うなら、なぜ違うのか調べてください。

ヒント: 前駆体？ アイソフォーム？ シグナルペプチドを含む？

演習 2 ★ — ID を持って渡り歩く

演習 1 で得た accession を使います。

(a) その UniProt ID を、Ensembl 遺伝子 ID・HGNC ID・PDB ID に変換してください。

(b) PDB の構造はいくつありましたか。0 件だった場合、それは「構造がない」という意味でしょうか。 確かめてください。

(c) 変換できなかった対象があれば、それを明示させてください。

💡 「黙って減った件数」が最も危険です。 変換の失敗を報告させる習慣をつけてください。

演習 3 ★★ — TogoVar：日本人集団のバリアント

GBA1 の病原性バリアントは何件？
そのうち日本人集団で頻度が高いものは？

(a) 実行してください。

(b) 「GBA1」と「GBA」の両方で検索して、match_type を比べてください。何が違いますか。

⚠️ どちらも 1 行目に GBA1 が出ます。それでも違いがあります。 表示された match_type を必ず見てください。

(b2) HGVS 表記（NM_... / p....）を出させてください。最初の呼び出しでは返ってきません。 何を足せば出ますか。

(c) 病原性＋おそらく病原性のバリアント数と、significance の分類レコード数の合計は一致しますか。一致しない場合、それぞれ何を数えているのでしょうか。

(d) 日本人コホートと国際的なコホートで、頻度はどれくらい違いましたか。

⚠️ この結果には ClinVar が登録している疾患名が含まれます。ClinVar の分類として扱ってください。医学的な助言ではありません。

演習 4 ★★ — 定義を変えると答えが変わることを体験する

第 4 章のデモ 3' を、自分で壊してみます。

(a) 「ヒトのライソゾーム酵素で、承認薬の標的になっているもの」を、UniProt のキーワード KW-0458 を使って調べてください。

(b) 同じ問いを、GO の GO:0043202（lysosomal lumen） を使って調べてください。

(c) 2 つの答えを比べてください。なぜこれほど違うのですか。

(d) あなたの研究分野で、これと同じ罠が起きそうな用語を 1 つ挙げてください。

これは演習の中で最も重要です。答えが変なとき、疑うべきは文法ではなく対象の定義です。

演習 5 ★★ — 検証の 4 手順を通す

演習 3 または 4 の結果について、第 7 章の検証手順を実際に踏んでください。

(a) 実行された SPARQL を全文出させて保存する（要約させないこと）

(b) COUNT(DISTINCT ...) と COUNT(*) の両方を出させる。差があるなら、何が重複しているか説明させる

(c) 元のデータベースの Web サイトで、上位 1 件と「意外な」1 件を目視確認する

(d) 実行日・エンドポイント・元の質問文を記録する

(e) これらを 1 つのフォルダにまとめて保存する

半年後の自分が再現できる形になっていますか。

演習 6 ★★★ — 悪い問いと良い問いを自分で作る

(a) あなたの研究テーマについて、わざと曖昧な問いを 1 つ作って投げてください。

(b) ツールのログを開いて確認してください： - run_sparql や検索ツールは呼ばれましたか - 答えに出てきた具体名（遺伝子名・化合物名など）は、ツールの出力に実在しましたか - accession や ID は付いていましたか

(c) 第 6 章の 5 要素を使って、同じ意図を仕様化して投げ直してください。

(d) 何が変わりましたか。所要時間、ツール呼び出しの数と種類、答えの中身。

(e) 仕様化した版にも、まだ残っている限界はありますか。

(e) が本番です。良い問いは答えを良くしますが、限界を消しはしません。

演習 7 ★★★ — 反証を探させる

あなたが正しいと信じている、自分の分野の主張を 1 つ選んでください。

(a) 「この主張は正しいか」と聞いてください。

(b) 次に、「この主張に反する証拠をデータベースから探して」と聞いてください。

(c) 答えは変わりましたか。どちらがより有用でしたか。

AI は同意しやすい傾向があります。「合ってる？」ではなく「反証を探して」が実務では効きます。

最後に ── 自分のテーマで

あなたの研究テーマで、実際に知りたいことを 1 つ聞いてください。

うまくいかなくて構いません。うまくいかなかったときこそ、何が起きたのかを切り分けてください。

記録しておくとよいこと：

• 何を聞いたか（元の文面のまま）
• どのツールが呼ばれたか
• 何が返ってきたか
• 期待と違った点は何か。それは AI の問題か、データベースの問題か、問いの問題か

最後の 1 行が、この教材で持ち帰るべきものです。

解答

解答例とつまずきどころ

⚠️ 数値はすべて実測（2026-08-20 / 08-21 再測定）。データベースは更新されるので、同じ数字にならなくて正常です。 手順と考え方を照合してください。

演習 1 — 接続確認と最初の問い合わせ

(a)(b) 割愛（各自のタンパク質による）。

(c) つまずきどころ: accession が返ってこない、または複数返る場合。

タンパク質名は一意ではありません。「アミラーゼ」には AMY1A/AMY1B/AMY1C/AMY2A/AMY2B があります。曖昧なら、AI は勝手にどれかを選びます。 遺伝子シンボルで指定し直してください。

(d) 配列長が期待と違う ── 大半はこの 3 つです。

確認のしかた:

その配列長は前駆体のものですか、成熟タンパク質のものですか。
シグナルペプチドやプロペプチドの領域が UniProt に注釈されているなら、それも示して。

教訓: 数字が期待と違うとき、まず疑うのはあなたの期待とデータベースの定義のずれです。AI の誤りではありません。

演習 2 — ID を持って渡り歩く

(a) インスリン P01308 の場合：Ensembl ENSG00000254647 / HGNC 6081（正式には HGNC:6081）。

💡 HGNC が裸の数字で返ることがあります。表記を整えてください。

(b) PDB 0 件の解釈 ── ここが本題です。

0 件は「構造がない」ことを意味しません。 考えられるのは：

1. 本当に構造が解かれていない
2. 構造はあるが、ID 変換の経路にその対応が登録されていない
3. 複合体の一部として解かれていて、そのタンパク質単独のエントリになっていない

確かめ方 ── 別の経路で当たること：

このタンパク質の PDB 構造を、ID 変換ではなく PDB を直接検索して探して。
件数が違うなら、なぜ違うのか説明して。

RCSB PDB の Web サイトで直接検索するのも 30 秒で済みます。

教訓: 単一の経路で 0 件が返ったとき、それは「無い」証拠ではありません。「その経路では見つからない」証拠です。

(c) 変換できなかったものの明示:

この ID 群を ◯◯ に変換して。変換できなかったものも明示して。

黙って減った件数が最も危険です。 20 個投げて 12 個返ってきたとき、8 個が消えたことに気づかないまま「12 個ありました」と報告してしまいます。

演習 3 — TogoVar

(a) 実測値（2026-08-21）：病原性＋おそらく病原性 = 182 バリアント。

(b) 遺伝子名の解決 ── 「GBA1」は完全一致、「GBA」は完全一致しません。

HGNC が 2022 年に GBA → GBA1 へ改名したため、旧シンボル「GBA」は現行の承認シンボル集合にありません。「GBA」で検索すると exact 一致が 1 件もなく、GBA1・GBA2・GBA3・GBAT2・GBA1LP の 5 件すべてが前方一致で並びます。

★ここで引っかからなかった人へ。 GBA1 が 1 行目に来るので、そのまま通過できてしまいます。それは再ランクの結果であって、運です。

match_type: prefix は「あなたが聞いたシンボルは存在しない」という意味です。同列に並ぶ GBAT2 を見てください ── 正式名は "RFX5 antisense RNA 1" で、GBA ファミリーですらありません。「最初のヒットを取る」を習慣にすると、いつか刺されます。

その遺伝子シンボルは完全一致でしたか、前方一致でしたか。
別の候補があるなら、なぜそれではないのか説明して。

(c) 一致しません。★これが最大のポイント

「病原性バリアント 277 個」と言えば誤りです（277 は Pathogenic レコードの数で、合計はさらに大きい 457）。

もう一つ、直感に反すること。 「病原性」で絞ったのに、内訳に Uncertain significance 35 件、Likely benign 1 件が出てきます。矛盾ではなく、フィルタはバリアント単位、内訳はバリアント × 条件レコード単位だからです。rs421016 だけでも 13 レコードあります。

ツール自身が statistics_caveats を返してきます。読んでください。

(b2) HGVS が出ない ── ライブで必ず詰まる箇所

HGVS 表記はデフォルトの出力に含まれません。include_transcripts=True を付けた追加の呼び出しが必要です。

そのバリアントの HGVS 表記を、転写産物の情報も含めて出して。

得られるもの: NM_000157.4:c.1448T>C / NP_000148.2:p.Leu483Pro

💡 旧慣用名は L444P です（シグナルペプチド 39 残基を除いた旧番号）。文献では L444P で書かれていることが多いので、橋渡しとして覚えておいてください。

⚠️ ただし include_transcripts の出力は大きく、GBA1 では 12 転写産物ぶん返ります。BRCA1 級（400 超）で同じことをすると画面が破綻します。

(d) 日本人集団での濃縮 ── この演習の見どころ

病原性＋おそらく病原性に ToMMo 頻度 ≥0.0005 を掛けると、残るのは 1 個だけ ── rs421016（古い表記で L444P、現行表記 NP_000148.2:p.Leu483Pro）。

日本人集団で約 10 倍に濃縮（ToMMo / gnomAD exomes ≈ 9.5 倍、GEM-J WGA では ≈ 15.7 倍）。日本人 3 コホートが揃って高いので、単一コホートのアーティファクトではなく集団差として読めます。国際データベースだけを見ていたら見落とす情報です。これが TogoVar の存在理由であり、TogoMCP が日本発データベースを揃えている価値です。

⚠️ ただし断定しないでください。 ToMMo と NCBN には VQSRTrancheSNP99.95to100.00、GEM-J WGA には NotHighConfidenceRegion の品質フラグが立っています。GBA1 は偽遺伝子 GBAP1 と高度に相同でショートリードのマッピングが難しく、頻度差の一部が技術的な偽陽性である可能性は排除できません。

これは第 7 章の「向いていない用途」に直結します。集団差の主張は、品質フラグを見てからにしてください。

⚠️ 「ヘテロ保因者は発症しないので心配ない」とは言わないでください。

ゴーシェ病は常染色体潜性で、ヘテロ保因者はゴーシェ病自体は発症しません。しかしそれは「無関係」という意味ではありません ── GBA1 のヘテロ変異はパーキンソン病のリスクを大きく高めるという報告が複数あります（Sanyal et al., Mov Disord 2020, PMID 32034799）。

画面に Parkinson 病と Lewy 小体型認知症が並んでいるのは、まさにそれです。断定的な安心づけは、この場面では不正確になります。

もう 1 つの罠（気づいた人は鋭い）: 病原性バリアントの多くが tgv_id: null を持ちます。REST の側には存在しますが、TogoVar の SPARQL 側のサブセットには入っていません。SPARQL で追いかけると静かに取りこぼします。

演習 4 — 定義を変えると答えが変わる ★最重要

(a) KW-0458（UniProt キーワード "Lysosome"）を使った場合

候補 161 タンパク質。承認薬側は 48 行。

48 行のうち 34 行がインスリン製剤と PDGFR 阻害剤。 「ライソゾーム酵素の承認薬」の見出しでこれを出すと即座に指摘されます。

(b) GO:0043202（lysosomal lumen）を使った場合

候補 52 タンパク質。承認薬側は 16 行 / 3 タンパク質 / 14 薬剤。候補の中心は GBA1・GLA・HEXA/HEXB・GAA・IDUA・IDS・ARSA/ARSB・SGSH・NAGLU・GALC・SMPD1・TPP1・PPT1 といった本物の内腔加水分解酵素です。

インスリン製剤 22 種が消えました。 PDGFRB は残りますが（本当に GO:0043202 が付いているため）、結果を読める規模になります。

答え:

ヒトのライソゾーム内腔酵素 52 種のうち、承認薬のターゲットは 3 つ ── GLA（ミガーラスタット、薬理学的シャペロン）、GAA（ミグリトール／ボグリボース、ただし適応は 2 型糖尿病）、そして PDGFRB（11 剤。受容体型チロシンキナーゼで、ライソゾーム酵素ではない）。

PDGFRB を除くと、ライソゾーム酵素を直接狙う承認低分子は実質ミガーラスタット 1 系統だけ。ライソゾーム病は酵素を阻害するのではなく補充して治療するから。

(c) なぜこれほど違うのか

KW-0458 は細胞内局在のキーワードであって、機能の分類ではありません。 「ライソゾームに局在する（ことがある）タンパク質」という意味なので、INSR・PDGFRB・MTOR・PCSK9・LRRK2・PSEN2、そして 20 個ほどの RAB GTPase が入ります。

EC 番号で 3.*（加水分解酵素）に絞っても直りません。 161 のうち 113 が生き残ります。RAB GTPase は EC 3.6.5.2 で、立派な加水分解酵素だからです。

それでも PDGFRB は GO:0043202 版にも残ります。 本当にそのアノテーションが付いているからです。局在アノテーション ≠ 機能分類。 間違いではなく、問いの解像度の問題です。

(d) 自分の分野での類例 ── 探すときの目印：

• 局在の語を機能の語として使っている（「ミトコンドリアタンパク質」＝ミトコンドリアで働く？ 局在する？ コードされる？）
• 上位概念で言っている（「キナーゼ」「転写因子」── どこで線を引く？）
• 臨床の語と分子の語が混ざっている（「がん遺伝子」── 体細胞ドライバー？ 生殖細胞系列易罹患性？）
• 慣用名が正式名と違う（GBA / GBA1 のように）

演習 5 — 検証の 4 手順

よくある失敗:

(b) 差があった場合の説明の求め方:

COUNT(*) と COUNT(DISTINCT) に差がある。
どの述語が複数の値を持っているせいか、実例を1件挙げて示して。

「実例を 1 件」が効きます。抽象的な説明では検証できません。

(c) 目視確認は「意外な 1 件」を見ること。 上位 1 件はたいてい正しいので情報量が少ないです。PDGFRB がライソゾーム酵素のリストに入っている、のような違和感は意外な 1 件を見て初めて気づきます。

演習 6 — 悪い問いと良い問い

(b) チェックリスト:

2 番目が決定的です。第 4 章の実例では、答えに並んだ TP53・KRAS・MYC がツール出力に 1 つも存在しませんでした。

(d) 期待される変化（第 4 章の実測値）:

(e) 残る限界 ── ここが本番です。 第 4 章の仕様化版でも：

• 上位に INS（膵臓という臓器の共起）・GAPDH（実験の内部標準）・POTEF（ACTB と配列が高度に類似するキメラ遺伝子。ただし順位の原因かは未確認）が混入
• 真のドライバー SMAD4・CDKN2A が上位 20 圏外
• 理由：共起論文数は「有名度 × 論文数」を測っており、疾患特異性を測っていない

あなたの (c) の答えにも、同種の限界があるはずです。「この指標が測っているものと、測っていないもの」を 1 行で書けますか。 書けたら、この教材の目的は達成されています。

演習 7 — 反証を探させる

期待される差:

「この主張は正しいか」→ AI は同意しやすい。裏付けになる証拠を選択的に集める傾向があります。

「この主張に反する証拠を探して」→ 探索の方向が変わり、別のデータが出てきます。

どちらが有用か: ほぼ常に後者です。あなたはすでに賛成側の証拠を持っています。持っていないのは反対側です。

実務での応用:

この解釈以外に、同じデータを説明できる仮説はある？
その仮説を支持する証拠をデータベースから探して。

論文の考察を書くとき、査読コメントを予測するときに効きます。

自由演習 — 振り返りの観点

うまくいかなかったとき、原因は 3 つに分かれます。どれなのかを切り分けられることが重要です。

最も多いのは 1 番目です。 そして最も気づきにくいのも 1 番目です ── 答えが返ってくるので、失敗に見えないからです。