Wikidata

Wikidata — 構造化ナレッジグラフ

Wikidata は、自由に利用できる、Wikipedia の姉妹プロジェクトである構造化データベースです。約 1 億 1,000 万件の項目（人物、場所、作品、概念）があり、機械可読なプロパティと関係性を備えています。オープンウェブにおいて、汎用ナレッジグラフに最も近い存在です。無料で、認証は不要で、SPARQL クエリに対応しています。

Pipeworx の一部です。AI エージェントを 1,684 以上の稼働中データソースにつなぐ MCP ゲートウェイです。

AI エージェントにとって重要な理由

エンティティの曖昧さの解消、著名な事柄に関する構造化された事実の取得、またはグラフの探索（「この著者が書き、賞を受賞した本は？」）には、Wikidata がオープンソースの標準的な情報源です。Wikipedia（文章）や OpenAlex（学術分野の詳細情報）と組み合わせれば、オープンナレッジを幅広く網羅できます。

よくあるフロー：

• エンティティの検索。 「ポール・マッカートニーとは誰ですか？」→ 構造化された事実（生年月日、国籍、職業、バンドへの所属）を含む Q2599。
• プロパティのクエリ。 「フランスの人口は？」→ Q142、プロパティ P1082（人口）、参照情報とタイムスタンプ付き。
• 曖昧さの解消。 「Paris」→ Q90（フランスの首都）、Q830149（テキサス州パリス）、Q3296（ギリシャ神話のパリス）。Wikidata の構造化されたタイプを使えば、エージェントが尋ねている「Paris」がどれなのかを特定できます。
• グラフの探索。 SPARQL：「イタリア生まれの物理学ノーベル賞受賞者全員」→ 構造化プロパティをまたいで結合できます。

ツール

ツール	返される内容
search_entities	ラベルまたは別名に一致する Q-ID と、ラベル、説明、別名。名前は分かっていて ID が必要な場合は、ここから始めてください。
get_entity	Q-ID によるエンティティ全体。ラベル、説明、別名、生の P コード形式のクレーム、サイトリンクに加えて、lastrevid / modified を返します。language を指定します。
get_entities	最大 50 個の Q-ID を 1 回の呼び出しで取得します。同じ情報を返します。Q-ID ごとのマップと not_found リストを返すため、不正な ID が 1 つあってもバッチ全体が失敗しません。下記の「以前は不正な ID が 1 つあるとバッチ全体が空になっていました」を参照してください。language を指定します。
get_wikidata_facts	プロパティ名と値を人が読めるラベルに変換した、同じステートメントに加えて、lastrevid / modified を返します。「X の <属性> は何ですか？」という質問には、こちらを優先してください。language を指定します。
wikidata_recent_changes	list=recentchanges による、最近作成または編集された項目を新しい順に返します。Q-ID、リビジョン ID、UTC タイムスタンプ、ユーザー、コメント、バイト数に加え、さらに過去の変更をページングするための cursor を含みます。

別の言語でラベルを取得する

search_entities、get_entity、get_entities、get_wikidata_facts はすべて language を受け取ります。これは API 独自の languages パラメーターにそのまま渡されるため、単一のコード （"ka"）でも、カンマまたはパイプでつないだリスト（"ka,ru,en"）でも動作します。リストを指定すると、要求した各言語のラベル、説明、別名が1 回の上流呼び出しで横並びに返されます。これは、異なる言語の 2 つのレコードが同じエンティティかどうかを判断するために必要な形式です。省略すると、これまでどおり英語が返されます。

フィールドは 2 種類あり、その違いが重要です。

• labels / descriptions / aliases_by_language は言語ごとに分類され、Wikidata に実際に存在する内容のみを含みます。エンティティにラベルがない言語を指定すると、そのキーは単に存在しません。この不在が正確な回答であり、翻訳が欠けていることを検出できます。
• label / description は単一の最適な値で、要求した言語の値がない場合は英語にフォールバックします。そのため、get_entity({id:"Q162887", language:"zu"}) は label: "Enguri HPP" と空の labels マップを返します。ズールー語のラベルはなく、そのことを確認できます。

get_wikidata_facts は、プロパティ名と値の両方をローカライズします。そのため {id:"Q162887", language:"ka"} は、英語のキーにジョージア語の値を付けるのではなく、ジョージア語のキー（ქვეყანა → საქართველო）を返します。

ここでは mul も実際の言語コードであり、目にすることがあります。 Wikidata は、言語に依存しないラベル（人名、ほとんどのラテン語の二名法、多くの地名）を mul（「複数の言語」）コードに移行しました。そのため、wbgetentities はそれらの項目に対して、空の en ラベルマップを返します。Q42（Douglas Adams）がその一例です。英語の説明はありますが、英語のラベルはありません。したがってフォールバックの順序は 要求された言語 → en → mul となり、名前が mul から取得された場合は、labels マップの mul キーに表示されます。

{"id":"Q42","label":"Douglas Adams","labels":{"mul":"Douglas Adams"},
 "description":"British science fiction writer and humorist (1952–2001)"}

このキーが出所を示します。つまり、そのエンティティに存在しない言語に名前が誤って帰属されることはありません。以前、このパックは Q42 に対して label: null を返していました。回答があるにもかかわらず null を返す、正常な 200 レスポンスでした。

不正な ID ひとつでバッチ全体が空になっていました

wbgetentities は未知の ID の扱いが一貫しておらず、次の 2 つのケースはまったく異なります。

• 形式は正しいものの未知の ID（Q999999999）は missing として返され、リクエスト内のほかの ID はすべて解決されます。
• 項目 ID の範囲外の ID、または明らかに不正な ID（Q99999999999、NOTAQID） を指定すると、API はリクエスト全体を拒否します。HTTP 200 で entities は一切返されず、トップレベルに {"error":{"code":"no-such-entity","id":"Q99999999999"}} が返されます。

素朴に読み取ると、2 つ目のケースは空のマップです。そのため、50 個の ID を含むバッチにタイプミスが 1 つあるだけで、50 個すべてが not_found と報告されていました。つまり、何も解決されなかったことを示す正常な 200 レスポンスです。エラーには問題のある ID が示されるため、get_entities はその ID を除外して再試行します（上限あり、1 回の処理につき 1 つの ID）。これにより、["Q162887","Q99999999999","Q90","NOTAQID","Q1326165"] のバッチは、実在する 3 つのエンティティを解決し、2 つの不正な ID を not_found に返すようになりました。

ステートメントを編集にひも付ける

Wikidata は常に更新され続けるため、「現在のステートメント」が意味を持つのは、リビジョンとの関係においてのみです。両方のエンティティツールは lastrevid、modified、revision_url を返すため、それらを使って作成した回答を、参照した正確な編集にひも付け、後から差分がないか再確認できます。

wikidata_recent_changes は、もう一方の情報、つまりどの項目がいつ変更されたかを返します。名前空間 0 は項目（Q-ID）、120 はプロパティ（P-ID）、146 はレキシームです。type は new（新規作成）、edit（既存項目の編集）、または all です。時間範囲には since を指定し、さらに過去の変更をページングするには cursor を使います。

認証

不要です。Wikidata は全面的にオープンです。Wikidata の SPARQL エンドポイントには適正利用のレート制限がありますが、ほとんどのエージェントのトラフィックには十分な余裕があります。

識別子スキーム

プレフィックス	種類
Q	項目（エンティティ — 人物、場所、物）
P	プロパティ（関係の種類 — 「配偶者」「インスタンス」「所在地」）
L	レキシーム（単語／語義。言語データ用）

すべてのエンティティには、Wikipedia の各言語版で恒久的な識別子として機能する安定した Q 番号があります。エージェントの出力には、正規の参照として Q 番号を埋め込んでください。

よくある落とし穴

• エンティティによって品質に大きな差があります。 著名人（アインシュタイン、Q937）には、出典が十分に示されたプロパティが数百件あります。一方、小さな町の政治家には、プロパティが5件しかなく、その半分が自動インポートされた出典という場合もあります。利用するプロパティの references フィールドは、必ず確認してください。
• 「現在」のプロパティに複数の値があります。 「企業 X の社長」には、過去の値が8件と現在の値が1件ある場合があります。Wikidata では、現在の値を示すために修飾プロパティ（開始時点、終了時点、「preferred rank」）を使いますが、エージェントは最初の値をそのまま取得しがちです。
• プロパティの重複。 関連する概念を表すプロパティが複数あります（「国」P17、「出身国」P495、「国籍」P27）。正確さのためには、適切なプロパティを選ぶことが重要です。
• 荒らしのリスク。 Wikidata は Wikipedia と同様に編集できます。注目度の高いエンティティは監視されていますが、あまり知られていないエンティティには、数日間荒らしの情報が残ることがあります。権威ある情報源へつながる references の連鎖がない限り、Wikidata の事実を1件だけ取り上げて確定情報として引用しないでください。
• 翻訳の欠落。 ラベルは多くの言語で登録されていますが、指定された言語では登録されていないことがあります。その場合、label は英語、次に言語に依存しない mul ラベルへフォールバックするため、英語以外のリクエストでも結果が空になることはありません。ただし、返された label は、その言語でエンティティのラベルが登録されている証拠にはなりません。確認するには labels マップを参照してください。キーがない場合は実際に欠落しており、mul キーがある場合は、名前が翻訳済みではなく言語に依存しないことを意味します。上記の「別の言語でラベルを読む」を参照してください。
• SPARQL のタイムアウト。 複雑なグラフクエリは、SPARQL エンドポイントの60秒のタイムアウトに達することがあります。クエリを小さく分割するか、プロパティを指定した検索を使用してください。
• 識別子であり、事実ではありません。 Wikidata は、「このエンティティの正規 ID は何か」「何にリンクしているか」を調べるのに最適です。詳しい伝記や歴史の記述については、リンク先の Wikipedia 記事を参照してください。

データソース

• MediaWiki Action API — https://www.wikidata.org/w/api.php
  • action=wbsearchentities（検索）、action=wbgetentities（エンティティの読み取り。props=info|labels|descriptions|aliases|claims|sitelinks、言語フィルターには languages= を指定。1回の呼び出しにつき、パイプで連結した ID を最大50件指定できます）
  • action=query&list=recentchanges（最近の変更フィード）
• API ドキュメント：https://www.wikidata.org/w/api.php および https://www.mediawiki.org/wiki/API:Recentchanges
• エンティティのページ：https://www.wikidata.org/wiki/<QID>、特定のリビジョン：https://www.wikidata.org/w/index.php?oldid=<revid>

すべてのエンドポイントで API キーは不要です。Wikidata は、呼び出し元に説明的な User-Agent の送信を求めています。この パックは Pipeworx-Wikidata-MCP/1.0 を送信します。

クイックスタート

MCP クライアント（Claude Desktop、Cursor、Windsurf など）に追加します：

{
  "mcpServers": {
    "wikidata": {
      "url": "https://gateway.pipeworx.io/wikidata/mcp"
    }
  }
}

このエンドポイントが実際に提供するもの

https://gateway.pipeworx.io/wikidata/mcp の tools/list は、上の表にあるツールに加えて、共有 Pipeworx メタツール（ask_pipeworx、 discover_tools、search_within、remember／recall など、ゲートウェイ全体で利用できるツール一式）も返します。そのため、表示されるツール数はこの表より多くなります。現在、単一パックのエンドポイントには、パック固有のツールと併せて、共有ツールが約 30 個リストされます。接続の initialize レスポンスに正確なスコープが記載されており、その日の状況を確認するうえで最も信頼できる情報です。

これは意図的な設計であり、偶然の多重化ではありません。メタツールを使うと、このパックでは対応していない質問にも、カタログ全体を対象にルーティングする ask_pipeworx を通じて回答できます。MCP サーバーをもう 1 つ追加する必要はありません。現時点では、メタツールなしでパックのエンドポイントをマウントする方法はありません。追加のスキーマによるコンテキスト消費がルーティングの利点を上回る場合は、複数のパックのエンドポイントではなく、フルゲートウェイに一度だけ接続してください。

または、フル Pipeworx ゲートウェイに接続すると、このパックのツールだけでなく、すべてのパックのツールを直接リストできます。

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

どちらの URL も、同じゲートウェイと同じ 1684+ のデータソースに接続します。異なるのは、どのパックのツールが直接リストされるかだけです。どちらからでも、ask_pipeworx を通じてすべてのツールを利用できます。

MCP クライアントがない場合：HTTP で呼び出す

curl -X POST https://gateway.pipeworx.io/v1/tools/wikidata_search_entities \
  -H 'Content-Type: application/json' \
  -d '{"query":"Albert Einstein"}'

最初の呼び出しにアカウントは必要ありません。ツールを確認するには、GET https://gateway.pipeworx.io/v1/tools/wikidata_search_entities を実行します。ツールを探すには、{"query":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を実行します。

スタンドアロン（ゲートウェイアカウント不要）

このパッケージはローカルの stdio MCP サーバーとしても実行できるため、Pipeworx アカウントやゲートウェイとの往復通信は不要です。

{
  "mcpServers": {
    "wikidata": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-wikidata"]
    }
  }
}

または、直接実行して起動を確認します。

npx -y @pipeworx/mcp-wikidata

stdin/stdout 経由で MCP を使用し、このパックのツールのみを対象に initialize／tools/list／tools/call に応答します。上記のゲートウェイ接続で追加される共有メタツールは含まれません。同じソース、同じツールで、ask_pipeworx によるルーティングはありません。

ask_pipeworx の使用

ツールを直接呼び出す代わりに、自然な英語で質問できます。これは上記のパックのエンドポイントでも、フルゲートウェイでも利用できます。

ask_pipeworx({ question: "your question about Wikidata data" })

ゲートウェイが適切なツールを選び、引数を自動的に設定します。

詳細情報

• ドキュメントとガイド
• pipeworx.io

ライセンス

MIT