ジャパンサーチ・IRDB・researchmap をAPIで使い分ける
論文を探すなら J-STAGE や CiNii、書誌なら国会図書館サーチ——ここまでは定番ですが、「浮世絵の高精細画像が欲しい」「大学の紀要論文を横断したい」「あの研究者の業績一覧が欲しい」となると、使うAPIが変わります。ジャパンサーチ・IRDB・researchmap の3つは、いずれも登録不要で叩ける一方、それぞれ設計思想がまったく違い、同じ感覚で使うと必ず躓きます。このガイドでは、3つの守備範囲と、実際に叩いて確認した癖を整理します。
3つの守備範囲（何を探すときに、どれか）
**ジャパンサーチ**（国立国会図書館）は、論文ではなく**デジタルアーカイブ**が主戦場です。美術品・古典籍・浮世絵・映像などを、100以上の連携データベースを横断して検索できます。最大の特徴はIIIF対応で、高精細画像へのアクセス経路が取れます。
**IRDB**（国立情報学研究所）は、全国の大学等の**機関リポジトリ**を横断します。J-STAGEやCiNiiが拾いきれない**大学紀要・学位論文・技術報告書**といった、いわゆる「灰色文献」に強いのが持ち味です。実際に検索結果の資料種別を見ると、Departmental Bulletin Paper（紀要論文）や Thesis or Dissertation（学位論文）が並びます。
**researchmap**（JST）は文献検索ではなく、**研究者個人の業績データベース**です。他の2つと決定的に違うのは、キーワード検索ではなく「この研究者の業績をください」という一方通行の設計であること（後述）。
ジャパンサーチ：IIIF画像が取れる、ただしDBごとに別物
エンドポイントは `https://jpsearch.go.jp/api/item/search/jps-cross` です。必須パラメータは `keyword`（`query` ではありません）。任意で `size`（デフォルト20・最大100）、`from`（最大10000）が使えます。認証は不要です。
実際に「浮世絵」で検索すると162,200件、「東海道五十三次」で5,772件がヒットしました。各アイテムには `iiifUrl` フィールドがあり、`https://dl.ndl.go.jp/api/iiif/971864/manifest.json` のような本物のIIIF Manifest URLが返ります。浮世絵検索では全体の約87%（141,786件）がIIIF対応でした。IIIFに対応していれば、画像の任意領域を任意サイズで切り出せるので、ビューアを自作する土台になります。`thumbnailUrl` も別途取れます。
そして最大の落とし穴が、**連携DBごとにフィールド構成がまったく別物**であることです。ジャパンサーチは各データベースの生のスキーマをそのまま出力するため、同じ検索結果の中に、国会図書館デジタルコレクション由来の `dignl-rdf:RDF`（DCNDL準拠）と、浮世絵版画DB由来の `arc_nishikie-77-u` のような番号付き独自フィールドが混在します。実測では1つのクエリ結果に5種類の異なるスキーマが同居していました。「タイトルは `title` フィールドにある」といった前提でパースすると、DBが変わった瞬間に取れなくなります。DBごとにマッピングを用意するか、共通で使えるフィールドだけに絞る設計が必要です。
ジャパンサーチ：二次利用条件は1件ずつ違う
デジタルアーカイブを扱う以上、避けて通れないのが権利処理です。ジャパンサーチは `rights` というフィールドで二次利用条件を返しますが、**その値がアイテムごとにまったく違います**。
公式に定義されている値は、`cc0`（CC0）、`pdm`（パブリックドメインマーク）、`ccby` / `ccbysa` / `ccbync` / `ccbyncsa` / `ccbyncnd`（CCライセンス各種）、`incr`（要許諾）、`incr_edu`（教育利用のみ許可）、`nocr_cont`（著作権はないが契約上の制限あり）、`nocr_other`、`uneval`（未評価）、`undet`（裁定制度対象）、`others` です。実測では、同一の検索結果の中に `pdm`（自由に使える）と `nocr_cont`（制限あり）と権利表示なしが混在していました。
つまり「ジャパンサーチのデータだから自由に使える」は成立しません。**1件ずつ rights を確認してから使う**設計が必須です。幸いコードがAPIで取れるので、機械的にフィルタできます。
なお `rights` ファセットの件数合計は、ヒット総数と一致しません（浮世絵検索で合計約29,564件に対しヒットは162,200件）。書誌情報のみでデジタル画像を持たないアイテムには権利表示が付かないためと見られますが、公式の明記は見つけられなかったので推測です。
IRDB：countは20/50/100しか効かない（黙って20に戻る）
エンドポイントは `https://irdb.nii.ac.jp/opensearch/search`。レスポンスはJSONではなく**XML（RSS 2.0 + OpenSearch拡張）**です。実測では「機械学習」で3,678件、「量子」で9,556件でした。認証は不要です。
各itemには、タイトル・リンク・著者（複数可）・subject（キーワード）・category（資料種別）・URI（リポジトリ本体へのパーマリンク）・pubDate・**irname（所蔵機関名）** が入ります。機関名が取れるのは機関リポジトリ横断ならではで、「どの大学の紀要か」を機械的に仕分けられます。
ここで最も危険な罠が `count` パラメータです。公式サポートページに「選択可能な値：**20、50、100**」と明記されており、この3値しか受け付けません。問題は、**それ以外の値を渡してもエラーにならないこと**です。実測で `count=5` `count=3` `count=2` `count=30` をそれぞれ試したところ、**すべて黙ってデフォルトの20件にフォールバック**しました（`itemsPerPage` が20のまま）。`count=50` と `count=100` は正しく反映されます。「3件だけ欲しい」と書いたコードが20件取ってくる、しかもエラーは出ない——気づきにくい類の事故です。
もう一点、著者検索（`creator`）が絞り込みとして機能していない疑いがあります。実測で著者名を指定したところ4,773,201件がヒットしました。キーワード検索が数千件規模であることを考えると桁が違いすぎます。技術的な原因までは確認できていないため推測ですが、著者名での厳密な絞り込みを前提にした設計は避けたほうが無難です。
researchmap：検索できない（permalinkを知っている前提）
researchmap APIの設計は、他の2つと根本的に違います。エンドポイントは `https://api.researchmap.jp/{permalink}/{achievementType}` で、**キーワードで研究者を探す機能がありません**。permalink（researchmapの個人ページURL末尾の識別子。例: `SatoshiMatsuokaHPC`）を**すでに知っている前提**で、その人の業績を引く一方通行のAPIです。
つまり「AIの研究者を探す」といった用途には使えません。researchmap.jp のWeb UIで研究者を特定してpermalinkを控え、それを起点に業績を辿る、という流れになります。この制約を知らずに設計を始めると詰みます。
`achievementType` で取れる業績は、`published_papers`（論文）、`presentations`（発表）、`research_projects`（研究課題）、`awards`（受賞）、`misc`、`books_etc`（著書）、`research_areas`（研究分野）、`works`（作品）です。実測では、ある研究者で published_papers が266件、awards が35件取れました。ページングは `_links.next` に次ページのURLが入ります。
面白いのが `rm:creator_type` フィールドで、その業績を**誰が入力したか**（`myself` / `institution` / `assistant` / `ai`）が分かります。AIが自動投入したレコードと本人が登録したレコードを区別できる、ということです。データの確からしさを判断する材料になります。
取得できるのは研究者本人が「公開」設定にした情報のみという設計で、レコードに `display: "disclosed"` が付きます。認証は不要で、レスポンスヘッダに `Access-Control-Allow-Origin: *` が付くため、ブラウザから直接叩ける設計になっています。ただし研究者個人の情報を扱う以上、収集・再掲の範囲には配慮してください。なお researchmap には更新系の「researchmap.v2 API」が別にあり、そちらはJST発行のクライアントIDが必須です。ここで説明しているのは公開情報を読むだけの別スコープのAPIです。
共通：0件でもエラーにならない
3つとも、検索結果が0件でもHTTPは200を返します。ジャパンサーチは `hit: 0` と空の `list`、IRDBは `totalResults: 0` で item 要素そのものが無くなります。ステータスコードでの成功判定は使えないので、本文の件数フィールドを見てください。
researchmap は存在しないpermalinkに対して404を返します。researchmap自体は `{"error":"not_found","error_description":"ページが見つかりません。"}` という親切なJSONを返しているので、エラー本文を読む実装にしておくと原因が分かりやすくなります。
応答速度は実測で、ジャパンサーチ約0.11秒、IRDB約0.48秒、researchmap約0.19秒でした。いずれも軽快です。
実際に叩いてみる（IRDB OpenSearch・登録不要）
学術機関リポジトリDB（IRDB）の OpenSearch は登録不要で、大学の紀要・学位論文・研究データを横断検索できます。レスポンスはRSS（XML）です。ジャパンサーチ（デジタルアーカイブ）や researchmap（研究者業績）とは返る形式・フィールドが異なるため、用途で使い分けます。
curl -s "https://irdb.nii.ac.jp/opensearch/search?q=AI&count=1"
# 実際のレスポンス（抜粋・RSS/XML）
<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/" version="2.0" xml:lang="ja">
<channel>
<title>IRDB OpenSearch</title>
<item> <title>…</title> <link>…</link> </item>
</channel>
</rss>出典
元システムエンジニア。Web系アプリ開発6年＋ソリューション9年、IT実務およそ15年。個人開発者として、政府オープンデータや各府省のAPIを実際に叩いて検証し、「何が取れるか」「実装時にどこで詰まるか」「どう活用するか」を一次検証にもとづいて記録しています。
運営者・検証方針について →