SPARQLとは？RDFを検索するクエリ言語の書き方とSQLとの違いを実行例で解説【2026年版】

SPARQLは、RDFで表現されたデータを検索するためのクエリ言語です。SQLに似た見た目をしていますが、テーブルではなくグラフを相手にするため、結合の考え方も欠損値の扱いも違います。この記事では定義を押さえたうえで、SELECT・FILTER・OPTIONAL・UNIONといった実際に使う構文を、サンプルデータに対して実行した出力とセットで並べます。掲載しているクエリは、この記事に載っている形のまま rdflib 7.6.0 で実行し、得られた結果をそのまま載せています。後半では、エラーを出さないまま結果が静かに変わる3つの落とし穴と、国立国会図書館やe-Statの公開エンドポイントで手を動かす手順を扱います。

まとめ

SPARQLはW3C勧告のRDF問い合わせ言語で、現行の正式版は2013年3月21日勧告のSPARQL 1.1です。次期版のSPARQL 1.2はまだWorking Draftの段階にあり、2026年8月時点で実装の前提にできるのは引き続き1.1です。

骨格はWHEREにトリプルパターンを並べ、一致した変数をSELECTで取り出すだけです。SQLと最も違うのは結合で、同じ変数名を複数のパターンで使うことがそのまま結合になります。値が無いかもしれない項目はOPTIONALで囲み、その有無はBOUNDで判定します。

実務で事故になりやすいのは、エラーにならず結果だけが変わるケースです。FILTERをOPTIONALの内側に置くか外側に置くかで件数が変わり、共有変数のないMINUSは1件も除外せず、比較する値のデータ型が食い違うとFILTERは例外を投げずに0件を返します。以下、この3つを含めて実行結果つきで見ていきます。

SPARQLの定義とRDFトリプルという前提

主語・述語・目的語の3つ組でデータを表す仕組み

RDFは、あらゆる事実を「主語・述語・目的語」という3つ組（トリプル）で表すデータモデルです。「書籍b2の著者は佐藤である」「書籍b2の刊行日は2022年4月15日である」といった具合に、1件の事実を1本の矢印として書きます。テーブルのように列をあらかじめ決めておく必要がなく、後から述語を足すだけでデータを拡張できます。

この記事で使うサンプルデータをTurtle形式で示します。書籍5冊、著者3名、組織3つからなる38トリプルの小さなグラフです。

@prefix ex:     <http://example.org/> .
@prefix schema: <https://schema.org/> .
@prefix rdfs:   <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd:    <http://www.w3.org/2001/XMLSchema#> .

ex:b1 a schema:Book ; rdfs:label "SPARQL入門"     ; schema:author ex:sato   ; schema:datePublished "2019-06-01"^^xsd:date .
ex:b2 a schema:Book ; rdfs:label "RDF実践ガイド"   ; schema:author ex:sato   ; schema:datePublished "2022-04-15"^^xsd:date ; schema:isbn "978-4-00-000000-1" .
ex:b3 a schema:Book ; rdfs:label "知識グラフ設計"   ; schema:author ex:tanaka ; schema:datePublished "2024-11-20"^^xsd:date ; schema:isbn "978-4-00-000000-2" .
ex:b4 a schema:Book ; rdfs:label "グラフDB入門"     ; schema:author ex:tanaka ; schema:datePublished "2021-02-10"^^xsd:date .
ex:b5 a schema:Book ; rdfs:label "オントロジー概論" ; schema:author ex:suzuki ; schema:datePublished "2016-09-05"^^xsd:date .

ex:sato   a schema:Person ; rdfs:label "佐藤" ; ex:affiliation ex:univA .
ex:tanaka a schema:Person ; rdfs:label "田中" ; ex:affiliation ex:univB .
ex:suzuki a schema:Person ; rdfs:label "鈴木" .

ex:univA  a schema:Organization ; rdfs:label "A大学" ; ex:partOf ex:groupX .
ex:univB  a schema:Organization ; rdfs:label "B大学" ; ex:partOf ex:univA .
ex:groupX a schema:Organization ; rdfs:label "X学園" .

注目してほしいのは、b2とb3にだけschema:isbnがあり、b1・b4・b5には無い点です。RDFではこれが正常な状態で、NULL列を持つ行ではなく「その述語のトリプルが存在しない」だけです。この非対称さが後述のOPTIONALとBOUNDの出番につながります。

SPARQL 1.1と1.2の仕様上の現在地【2026年8月時点】

SPARQLの最初の勧告は2008年1月15日の「SPARQL Query Language for RDF」です。現在ほぼすべての実装が準拠しているのは、2013年3月21日にW3C勧告となったSPARQL 1.1で、集約関数・サブクエリ・プロパティパス・BIND・VALUESはこの版で入りました。他のエンドポイントへ問い合わせを転送するSERVICE句は、同じ日に勧告となった別仕様のSPARQL 1.1 Federated Queryが定義しています。

次期版はSPARQL 1.2として12本の仕様がW3CのRDF & SPARQL Working Groupで策定中です。Query Languageは本稿執筆時点で2026年6月25日付のWorking Draftが最新で、勧告候補にも達していません。1.2ではトリプルそのものを値として扱うtriple termが導入され、<<( ?s ?p ?o )>>という構文、TRIPLE・SUBJECT・PREDICATE・OBJECT・isTRIPLEという関数群（第17.4.6節）、使用する版を宣言するVERSIONディレクティブ（第4.3節）が加わります。

Working Draftは勧告までに構文が変わりうるうえ、公開エンドポイントの実装も追随していません。いま書くクエリは1.1の範囲に収めてください。

SQLとの違いと4つのクエリ形式の使い分け

テーブル結合ではなくパターン照合という考え方

SQLとSPARQLは、キーワードの見た目こそ似ています。対応関係を整理すると次のようになります。

本質的な差は「結合」の行です。SQLでは結合対象をJOIN ... ONで明示しますが、SPARQLでは?book schema:author ?author .と?author rdfs:label ?name .のように同じ?authorを2つのパターンで使うと、それだけで結合が成立します。書き手は結合順序を指定せず、どの順で評価するかは処理系に委ねます。

SELECT・ASK・CONSTRUCT・DESCRIBEの使い分け

SPARQL 1.1のクエリ形式は4つで、仕様の第16章にまとめられています。表形式の結果が欲しいときはSELECT、条件を満たすデータの有無だけを真偽値で知りたいときはASKを使います。

PREFIX ex:     <http://example.org/>
PREFIX schema: <https://schema.org/>
PREFIX xsd:    <http://www.w3.org/2001/XMLSchema#>

ASK { ?book schema:author ex:sato ;
            schema:datePublished "2022-04-15"^^xsd:date . }

このクエリの実行結果はtrueです。存在確認だけならレコードを取り出さずに済むため、バリデーション用途ではSELECTよりASKが適しています。

取得結果を表ではなくRDFグラフとして受け取りたい場合はCONSTRUCTを使います。既存データを別の語彙に組み替えて出力できるため、データ変換のパイプラインに向きます。

PREFIX ex:     <http://example.org/>
PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>

CONSTRUCT { ?author ex:wrote ?label . }
WHERE {
  ?book schema:author ?author ; rdfs:label ?label .
  FILTER (?author = ex:suzuki)
}

実行するとTurtle形式でns1:suzuki ns1:wrote "オントロジー概論" .という1トリプルが返ります。ns1:はrdflibが出力時に自動で振った接頭辞で、他の処理系ではex:や完全なIRIで返ります。4つ目のDESCRIBEは指定リソースの記述を返しますが、何を返すかは仕様の第16.4節で「SPARQLクエリプロセッサが決定する」とされ、章そのものがinformativeな扱いです。移植性が必要な処理ではDESCRIBEに頼らず、CONSTRUCTで必要な形を自分で書くほうが安全です。

基本構文の書き方と実行結果

クエリの骨格はSELECTとWHEREだけです。IRIを毎回フルで書かずに済ませるため、先頭にPREFIXで名前空間の短縮名を宣言するのが通例です。並べ替えはORDER BY、件数制限はLIMITで、いずれもSQLと同じ位置に書きます。

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?label ?date WHERE {
  ?book a schema:Book ;
        rdfs:label ?label ;
        schema:datePublished ?date .
}
ORDER BY DESC(?date)
LIMIT 3

実行すると3行が返ります。

知識グラフ設計 | 2024-11-20
RDF実践ガイド | 2022-04-15
グラフDB入門   | 2021-02-10

WHEREの中でセミコロンを使うと主語を省略できます。上の例では?bookを主語とする3本のトリプルパターン（型・ラベル・刊行日）を、主語を1回だけ書いてまとめています。行末のピリオドがパターンの終端、セミコロンが主語の継続、カンマが主語と述語の両方の継続を表します。たとえばex:b1 schema:author ex:sato, ex:tanaka .と書けば、著者2名を1行で表せます。

取り出す変数を選ばず全部返すならSELECT *、重複を潰すならSELECT DISTINCTです。注意したいのはORDER BYとLIMITの評価順で、並べ替えが先、件数の切り取りが後になります。上の例でORDER BYを外すと、返る3件はグラフ内の任意の3件になります。RDFグラフには行の順序という概念が無いため、LIMITだけを書いて「先頭のN件」を期待すると、実行のたびに違う結果を受け取ることになります。

絞り込みと結合を担う句の書き方

FILTERとREGEXによる条件指定

FILTERは、パターン照合で得られた解の集合に対して条件を適用します。比較演算子はSQLとほぼ同じで、日付やリテラルの比較にはデータ型付きリテラルを使います。

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd:    <http://www.w3.org/2001/XMLSchema#>

SELECT ?label ?date WHERE {
  ?book rdfs:label ?label ; schema:datePublished ?date .
  FILTER (?date >= "2021-01-01"^^xsd:date)
}
ORDER BY ?date

結果はグラフDB入門 | 2021-02-10、RDF実践ガイド | 2022-04-15、知識グラフ設計 | 2024-11-20の3行です。文字列の部分一致にはregex関数を使います。

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?label WHERE {
  ?book a schema:Book ; rdfs:label ?label .
  FILTER regex(?label, "入門")
}
ORDER BY ?label

返るのはSPARQL入門とグラフDB入門の2行です。regexは第3引数に"i"を渡すと大文字小文字を無視します。ただし索引は使われません。Apache Jenaの全文検索ドキュメントはregexについて「a test on a value retrieved earlier in the query so its use is not indexed」と明記しています。取得済みの値に対する後段のテストだからです。大量データの部分一致ではregexに頼らず、エンジン側の全文索引（Jenaならtext:query）を使う設計に切り替えてください。

OPTIONALとBOUNDによる欠損データの扱い

OPTIONALは、中のパターンが一致しなくても外側の解を捨てない、SQLの左外部結合にあたる構文です。

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?label ?isbn WHERE {
  ?book a schema:Book ; rdfs:label ?label .
  OPTIONAL { ?book schema:isbn ?isbn . }
}
ORDER BY ?label

実行結果は5行で、ISBNを持たない3件は変数が未束縛（unbound）のまま返ります。

RDF実践ガイド   | 978-4-00-000000-1
SPARQL入門     | (unbound)
オントロジー概論 | (unbound)
グラフDB入門    | (unbound)
知識グラフ設計   | 978-4-00-000000-2

この未束縛を判定するのがBOUNDです。SQLのIS NULLに相当する「値が無いものだけ」を取り出すには、OPTIONALで結合してから!BOUNDで否定します。

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?label WHERE {
  ?book a schema:Book ; rdfs:label ?label .
  OPTIONAL { ?book schema:isbn ?isbn . }
  FILTER (!BOUND(?isbn))
}
ORDER BY ?label

返るのはSPARQL入門・オントロジー概論・グラフDB入門の3行です。OPTIONALを書かずに!BOUND(?isbn)だけを置くと、?isbnはどこでも束縛されないため全件が該当してしまいます。この2つは必ずセットで使います。

UNIONとVALUESによる複数条件の指定

「著者が佐藤、または鈴木」のようなOR条件はUNIONで書きます。2つのグラフパターンをそれぞれ評価し、解を合わせる構文です。

PREFIX ex:     <http://example.org/>
PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?label WHERE {
  { ?book schema:author ex:sato ; rdfs:label ?label . }
  UNION
  { ?book schema:author ex:suzuki ; rdfs:label ?label . }
}
ORDER BY ?label

結果はRDF実践ガイド・SPARQL入門・オントロジー概論の3行になります。ただし、違いが値だけで構造が同じならUNIONは冗長です。SPARQL 1.1で追加されたVALUESを使うと、候補値をインラインの表として渡せます。

PREFIX ex:   <http://example.org/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?name WHERE {
  VALUES ?person { ex:sato ex:suzuki }
  ?person rdfs:label ?name .
}
ORDER BY ?name

佐藤と鈴木の2行が返ります。候補が増えても行を足すだけで済むため、パターンを丸ごと複製するUNIONより保守が楽です。IDのリストで絞り込む用途なら、まずVALUESを検討してください。

BINDと集計関数による計算

クエリの途中で計算した値に名前を付けるのがBINDです。次の例では刊行日から経過年数を求めています。

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?label ?years WHERE {
  ?book rdfs:label ?label ; schema:datePublished ?date .
  BIND (2026 - YEAR(?date) AS ?years)
}
ORDER BY ?years

実行結果は知識グラフ設計 | 2、RDF実践ガイド | 4、グラフDB入門 | 5、SPARQL入門 | 7、オントロジー概論 | 10の5行です。基準年を2026と直接書いているので出力が固定されますが、実行時点で計算させたいならYEAR(NOW()) - YEAR(?date)に置き換えます。集約はGROUP BYとHAVINGで、こちらもSQLと同じ発想で書けます。

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?name (COUNT(?book) AS ?n) WHERE {
  ?book schema:author ?author .
  ?author rdfs:label ?name .
}
GROUP BY ?name
HAVING (COUNT(?book) > 1)
ORDER BY DESC(?n) ?name

著書2冊の佐藤 | 2と田中 | 2が返り、1冊だけの鈴木はHAVINGで除外されます。集約結果に別名を付ける(COUNT(?book) AS ?n)の括弧は省略できません。

プロパティパスによる多段のたどり方

SPARQL 1.1のプロパティパスは、述語を/でつないだり*や+で繰り返したりして、階層を一気にたどる記法です。中間ノード用の変数を書かずに済みます。

PREFIX ex:   <http://example.org/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?name ?org WHERE {
  ?person ex:affiliation/ex:partOf* ?o ;
          rdfs:label ?name .
  ?o rdfs:label ?org .
}
ORDER BY ?name ?org

サンプルデータではB大学がA大学に、A大学がX学園に属しています。*は0回以上の繰り返しなので、田中は所属先のB大学に加えて上位のA大学とX学園まで、佐藤はA大学とX学園が返り、合計5行になります。1回以上に限定したいときは+、いずれかの述語をたどりたいときは|を使います。国立国会図書館の解説ページでも、件名標目の下位語を再帰的にたどる例としてskos:narrower+が示されています。

エラーにならず結果だけが変わる3つの落とし穴

FILTERの位置で変わるOPTIONALの件数

同じ条件式でも、OPTIONALの内側に書くか外側に書くかで結果はまったく別物になります。次の2本は条件も対象も同じですが、FILTERの位置だけが違います。

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd:    <http://www.w3.org/2001/XMLSchema#>

SELECT ?label ?date WHERE {
  ?book a schema:Book ; rdfs:label ?label .
  OPTIONAL {
    ?book schema:datePublished ?date .
    FILTER (?date >= "2021-01-01"^^xsd:date)
  }
}

内側に置いた場合、FILTERは外部結合の対象を絞るだけなので、条件に合わない書籍も?dateが未束縛のまま残ります。実行結果は5行で、うち2行が未束縛です。

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd:    <http://www.w3.org/2001/XMLSchema#>

SELECT ?label ?date WHERE {
  ?book a schema:Book ; rdfs:label ?label .
  OPTIONAL { ?book schema:datePublished ?date . }
  FILTER (?date >= "2021-01-01"^^xsd:date)
}

外側に置くと、結合が終わった後の解全体に条件が適用され、未束縛の行は落ちて3行になります。5行と3行の差は、SQLのLEFT JOIN ... ONとWHEREの違いと同じ構図です。絞り込みたいのは結合相手なのか、結合後の全体なのか。毎回そこを言語化してから位置を決めてください。

共有変数のないMINUSが1件も除外しない挙動

否定を書く方法はFILTER NOT EXISTSとMINUSの2つあり、どちらも同じ結果になると説明されがちです。実際には共有変数の有無で挙動が分かれます。SPARQL 1.1 Query仕様も第8.3節を丸ごとこの差の説明に充て、8.3.1で変数を共有しない場合を例示しています。

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?label WHERE {
  ?book a schema:Book ; rdfs:label ?label .
  FILTER NOT EXISTS { ?x schema:isbn ?isbn . }
}

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?label WHERE {
  ?book a schema:Book ; rdfs:label ?label .
  MINUS { ?x schema:isbn ?isbn . }
}

否定の中の?xと?isbnは、外側の?bookとも?labelとも無関係です。この状態で実行すると、FILTER NOT EXISTSは0行、MINUSは5行、つまり全件を返します。NOT EXISTSが「そのパターンが1つでも成立するか」をグラフ全体で判定するのに対し、MINUSは解と解の差集合を取るため、束縛が重ならない解は除外対象にならないからです。

この差は静かに効きます。エラーも警告も出ないまま、除外したはずのデータが全件そのまま流れていきます。否定を書くときは、外側で使っている変数を否定パターンの中でも必ず使う、と決めてしまうのが実務的な防御策です。変数を共有していれば両者の結果は一致します。

データ型が食い違うFILTERのゼロ件化

3つ目は型の不一致です。サンプルデータのschema:datePublishedはxsd:dateですが、これをxsd:gYearと比較してみます。

PREFIX schema: <https://schema.org/>
PREFIX rdfs:   <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd:    <http://www.w3.org/2001/XMLSchema#>

SELECT ?label WHERE {
  ?book rdfs:label ?label ; schema:datePublished ?date .
  FILTER (?date >= "2021"^^xsd:gYear)
}

実行結果は0行です。構文エラーにも実行時エラーにもならず、静かに空の結果が返ります。仕様の第17.3節が順序比較（<、>、<=、>=）を定義しているのは、数値・単純リテラル・xsd:string・xsd:boolean・xsd:dateTimeの組み合わせだけです。表に載らない型の比較は評価エラーとなり、FILTERはエラーになった解を単に落とします。

この表にはxsd:dateも載っていません。前掲の日付比較が動いたのは、rdflib 7.6.0が仕様の許す拡張実装として対応しているからです。xsd:dateやxsd:durationの順序比較を使うクエリは、エンジンを乗り換えた瞬間に無言で0件へ変わりうると考えてください。

「クエリは正しいはずなのに0件」に遭遇したら、まずFILTERを外して?dateをSELECTに出し、実データの型と値を目視します。年で絞りたいならYEAR(?date) >= 2021のように関数で数値へ揃えるのが、実装差の影響を受けにくい書き方です。

公開エンドポイントでの実行と自前構築の選び方

SPARQLを試すのにローカル環境の構築は必須ではありません。ブラウザからそのまま叩ける公開エンドポイントがあり、2026年8月12日時点で次の3つはいずれもHTTP 200を返し、クエリ結果を取得できました。

日本語のデータで練習するなら国立国会図書館のWeb NDL Authoritiesが扱いやすい選択です。同館の解説ページによれば、1回に取得できる件数の上限は1,000件、毎日午前4時から5分程度はデータ更新のため停止し、API仕様書は2023年3月31日版が公開されています。クエリ入力の補助にはオープンソースのSPARQLサポートツールYasguiを拡張したものが使われており、CONSTRUCTクエリやDESCRIBEクエリの結果をグラフ図で確認できます（グラフ図は一部対応で、SELECTでは変数が?s ?p ?oのときに切り替えられます）。

WikidataではSERVICE wikibase:labelという独自サービスでラベルの言語を指定できます。bd:serviceParam wikibase:language "ja,en"と書けば日本語ラベルを優先し、無ければ英語で返ります。どちらの言語にもラベルが無い項目では、Q4115189のようにQ-idの文字列がそのまま返る点に注意してください。この種の拡張は仕様外なので、他のエンドポイントへそのまま持ち込んでも動きません。

自社データをSPARQLで検索したい段階になったら、まずはApache Jena Fusekiが手堅い出発点です。導入手順やエンドポイントの公開方法はApache Jena Fusekiとは何か？RDFデータを操作するSPARQLエンドポイントサーバーの概要解説にまとめています。マネージドサービスで運用ごと任せたい場合は、SPARQLを含む3つのクエリ言語に対応するAmazon Neptuneとは｜3つのクエリ言語・Analyticsとの違い・料金モデルを実装目線で解説【2026年版】が候補になります。

SPARQLを選ぶべき場面と避けるべき場面

SPARQLが明確に有利なのは、語彙が標準化された外部データと自社データをつなぎたいときです。国立国会図書館の典拠やWikidataのように、IRIで同一性が保証されたデータを相手にする限り、SERVICE句で他エンドポイントへ問い合わせを飛ばして結果を統合できます。スキーマ変更なしで述語を足していける性質も、語彙が育っていく途中のデータには合います。

逆に、採用を見送るべき条件もはっきりしています。まず、データが自社内で完結し外部語彙と接続する予定が無いなら、SPARQLの標準化の恩恵はほぼ受けられません。最短経路や中心性のようなグラフアルゴリズムを回したい場合も不向きです。標準SPARQLの範囲にこれらの演算子は無く、プロパティパスで到達可能性を調べるところまでが限界だからです（StardogやGraphDBは独自のパス検索を拡張として持ちますが、移植性は失われます）。この領域はプロパティグラフとCypherの担当で、選定の判断材料はNeo4jとは？グラフデータベースの構造とCypher・エディション選定を実装視点で解説【2026年版】で整理しています。

もう一つ、生成AIの検索基盤としてグラフを持ちたいという動機でSPARQLに手を出すのは遠回りになりがちです。RDFスキーマの設計とオントロジー整備に時間がかかるうえ、LLMが安定して正しいSPARQLを生成できる保証もありません。用途がRAGの精度改善なら、ベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】やGraphRAGとは？仕組みとベクトルRAGの違い【2026年版】で構成を比較してから決めるほうが早く着地します。

よくある質問

SPARQLとSQLは何が違いますか？

対象とするデータモデルが違います。SQLは行と列からなるテーブルを、SPARQLは主語・述語・目的語のトリプルからなるグラフを検索します。実装上いちばん影響が大きいのは結合の書き方で、SQLがJOIN ... ONで結合条件を明示するのに対し、SPARQLは複数のトリプルパターンで同じ変数名を使うことがそのまま結合になります。値が存在しない項目の扱いも異なり、NULL列ではなく「トリプルが無い」状態として表れるため、OPTIONALとBOUNDを組み合わせて判定します。

SPARQLでOR条件を書くにはどうしますか？

方法は3つあり、状況で使い分けます。グラフパターンの構造そのものが違うならUNIONで2つのブロックを並べます。同じパターンで値だけが複数あるならVALUESにインラインの候補表を渡すほうが簡潔で、候補が増えても行を足すだけで済みます。単一変数の値を列挙するだけならFILTER (?x IN (...))も使えます。実務ではVALUESを第一候補にして、パターン構造が分岐する場合だけUNIONに切り替えるのが保守しやすい方針です。

SPARQLを試す実行環境はどう用意しますか？

最初は公開エンドポイントで十分です。国立国会図書館のWeb NDL Authorities、e-StatのLOD、Wikidata Query Serviceはいずれもブラウザから直接クエリを実行でき、2026年8月12日時点で稼働を確認しています。手元で完結させたい場合は、Pythonのrdflibをインストールすればメモリ上のグラフに対してSPARQL 1.1をそのまま実行できます。この記事のクエリもrdflib 7.6.0で実行したものです。自社データを常時公開する段階になったら、Apache Jena FusekiやAmazon Neptuneといったサーバー側の選択に進みます。

RDFとは何ですか？

RDFはResource Description Frameworkの略で、データを「主語・述語・目的語」の3つ組で表現するW3Cのデータモデルです。「この書籍の著者はこの人物である」という1つの事実が1本のトリプルになり、主語と目的語をIRIで指定することで、異なる組織が作ったデータどうしを同じ識別子でつなげます。テーブルのように列を事前定義する必要がなく、新しい述語を追加するだけでデータを拡張できる点が特徴です。SPARQLは、このRDFで表されたグラフを検索するための問い合わせ言語です。

SPARQL 1.2はいつから使えますか？

時期は決まっていません。SPARQL 1.2 Query Languageは2026年8月時点でW3C Working Draftの段階にとどまり、勧告候補にも進んでいないためです。ドラフトはほぼ毎週更新されており、勧告までに構文が変わる可能性があります。設計するシステムは2013年3月21日勧告のSPARQL 1.1を前提にしてください。

関連記事

• Apache Jena Fusekiとは何か？RDFデータを操作するSPARQLエンドポイントサーバーの概要解説
• Amazon Neptuneとは｜3つのクエリ言語・Analyticsとの違い・料金モデルを実装目線で解説【2026年版】
• Neo4jとは？グラフデータベースの構造とCypher・エディション選定を実装視点で解説【2026年版】
• ベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】
• GraphRAGとは？仕組みとベクトルRAGの違い【2026年版】