Weekly API Radar v0.1.0
STEP 2073 rei-aios-85 tab 2026-09-16
公開 API を持つ学術・計測系サービスを 週次 で 4 reject 語彙で分類、 コネクタ候補 (全 reject を pass する service) を出力する 探索器。 STEP 2068 rei-crossref-mcp land 直後 の chat-Claude cowork session 「最小の提案 3 項目」 の ② 実装。
rei-scout との 分離 rationale
rei-scout (repo 発見 + MCP 導入判断) と reject 基準が違うため 独立。
- MCP サーバは 接続時点 で 任意コード実行 = 導入判断 は 必ず 人間 (rei-scout の 規律)
- 公開 API は 読取専用 = 自分のマシンで コード実行しない (安全度が違う)
- 同じ reject 語彙に入れると、危険度の違う 2 つが同じ列に並ぶ → 誤読 pattern
取得層 (fetch pattern) は research-radar / rei-scout 系列を参考、選別層 (reject 4 語彙) は 独自。
4 reject 語彙 (閉じている)
| code | 意味 |
|---|---|
NO_API | 公開文書化された自動アクセス手段が存在しない (Web UI のみ / undocumented) |
AUTH_REQUIRED | API key / OAuth / 契約が必要 (無料でも key 発行 は 「登録 = 契約」 相当) |
TOS_FORBIDS_AUTO | 利用規約が自動取得を禁止 (robots.txt / TOS explicit clause) |
UNREACHABLE | HTTP 到達不能 (5xx / DNS 失敗 / timeout / 接続拒否) |
未定義の code で Reject を作ろうとすると Error。語彙は閉じている。
週次 cadence 理由 (chat-Claude 起点)
- 「新しい公開 API は毎日は生まれません」 — API registry の変化は 月単位
- 「何も出ない計器は、やがて読まれなくなります」 — 日次だと「新規なし」疲弊
source_freshnessv4 実測 = TRUE 2 / NEITHER 15 / FLOWING 13 / ZERO 42 (n=73) = 既存の源の 42 本 が 死んでいる、日次 cron を足すのは ZERO の山を増やす方向
Seed 候補 8 服 (chat-Claude 2026-09-16 message で 名前挙がった 7 + Crossref)
| id | name | staticVerdict |
|---|---|---|
crossref | Crossref | CANDIDATE (STEP 2068 で rei-crossref-mcp land 済) |
openalex | OpenAlex | CANDIDATE (匿名 tier あり、mailto polite pool) |
issn-portal | ISSN Portal | AUTH_REQUIRED (メイン検索 = subscription、詳細調査 defer) |
research-com | Research.com | NO_API |
ad-scientific-index | AD Scientific Index | NO_API |
clarivate-hcr | Clarivate Highly Cited Researchers | NO_API |
nature-index | Nature Index | NO_API |
rsci | RSCI (Russian Science Citation Index) | NO_API |
週次 manual run 2026-W38 実測
| Verdict | Count |
|---|---|
| CANDIDATE | 2 (Crossref + OpenAlex) |
| NO_API | 5 |
| AUTH_REQUIRED | 1 |
| TOS_FORBIDS_AUTO | 0 |
| UNREACHABLE | 0 |
| total | 8 |
chat-Claude cowork session の 予測 table (「7 つ調べて、コネクタになるのは 2 つ」) と 完全一致。 Live probe: Crossref HTTP 405 in 638ms (server alive、HEAD not allowed = reachable=true 正確判定) + OpenAlex HTTP 200 in 436ms。
2 層 self-test (装置設計の原則 ②)
| 層 | 種別 | 件数 | 失敗時の意味 |
|---|---|---|---|
| 層 1 | offline fixture (fetch 注入式) | 53 assertion | コネクタのバグ |
| 層 2 | live (Crossref 1 probe) | 1 assertion | Crossref 側の問題として SKIP (FAIL でない) |
正常系 (Crossref/OpenAlex reachable) + 異常系 (5xx/DNS/timeout) 両立の fixture (STEP 2068 rei-crossref-mcp 継承)。
使い方
# manual run (live probe)
npx tsx scripts/weekly-api-radar/index.ts
# dry-run (probe skip、curated verdict のみ)
REI_SKIP_LIVE=1 npx tsx scripts/weekly-api-radar/index.ts
# self-test
npx tsx scripts/weekly-api-radar/tests/test-offline.ts
REI_SKIP_LIVE=1 npx tsx scripts/weekly-api-radar/tests/test-offline.ts
Output
data/weekly-api-radar/<YYYY-Www>.json— 機械可読 reportdata/weekly-api-radar/<YYYY-Www>.md— 人間可読 report
MODULE_INFO (STEP 1676 8-key 契約 voluntary conformance)
lib/module-info.ts の MODULE_INFO は STEP 1676 SelfDescriptionContract 8 key
(name / version / step / purpose / publicApi / keyConcepts / relatedModules / honestScope)
に voluntary 準拠。verifyModuleInfo() で verify、test 側で issues == [] を assertion。
enumerate.ts で research-radar / rei-scout は
evolutionKind: 'function-add' = out-of-scope 明示分類。本採用は
voluntary conformance (契約からの逸脱ではなく良い自己記述 discipline)。
STEP 2068 rei-crossref-mcp と同じ pattern。
既知の限界 (honest scope)
- seed 候補 8 服 は 初期 pool、網羅ではない (拡張は 別 STEP or 手動追加)
TOS_FORBIDS_AUTO判定 は 人間 curate metadata のみ (自動 TOS 読解 は 別 arc)UNREACHABLEは HTTP HEAD/GET probe で 自動、timeout / 5xx / DNS 失敗 を 一括畳込- 「weekly cron」 は 本 STEP では skeleton + manual run のみ、cron 化 は 別 STEP defer
- chat-Claude 「③
source_freshnessZERO 42 本片付けから」 は 別 STEP、本 STEP は ② のみ - OpenAlex 判定は 現行 API 情報 に 基づく 私 curate、auth 要否 は 実際 に は tier 差 あり
装置設計の 3 原則 (embed、 STEP 2068 継承)
- Reject 語彙 は 閉じている — 4 種の 閉じた 語彙 +
wheredict で「どこで・なぜ」を返す - Self-test を 被診断対象 から 切り離す — HTTP を fetch 関数として注入、偽 fetch で offline test 可能
- 正常系の fixture を必ず含める — 異常系だけだと 「常に reject を返す 実装」 が満点を取る
関連 STEP
- STEP 2068 (rei-aios-85、 2026-09-16): rei-crossref-mcp — 「① Crossref を 先にコネクタ 1 本にする」 実装
- STEP 1605 (2026-08-31):
source_freshnessgauge (n=73、 ZERO 42 signal 起点) - STEP 1676 (2026-09-02): SelfDescriptionContract 8-key 起源