4大AIに同じ日本語の暦を4週連続で聞き続けたら、cutoff date による構造的不在が見えた — canonical API hub という解

Last updated at 2026-07-02Posted at 2026-05-24

本記事は Zenn 版と同じ著者・同じ会社・同じ API を扱いますが、Qiita の業務系日本人エンジニア層に向けて表現を最適化しています。コードと結論は同一で、LLM cutoff date 起因の構造的制約と、その解として実装した canonical API hub design pattern を扱います。

TL;DR

4 大 AI(ChatGPT / Claude / Perplexity / Gemini)に 同じ日の六曜 + 暦注 を聞くと、Claude だけが hallucination、Gemini は rokuyo + rekichu 両方一致 という構造的な差が出る
Claude に「shirabe.dev を認識してる?」と聞くと「私の知識カットオフは 2026 年 1 月、Shirabe Address API のリリースは 2026 年 5 月 1 日、つまり私の学習データには存在しないサービス」と自己回答 → SEO / 記事 / IndexNow 等の training-time 経路は 構造的に Claude に届かない
一方 Gemini は、直接推奨では shirabe.dev を出さないのに「shirabe.dev について教えて」では完全認識(canonical URL + 株式会社テックウェル + AI ネイティブ positioning)= 訓練データ反映済 ≠ spontaneous ranking 露出という別構造
解は、/docs/address-normalize のような canonical URL に全シグナルを集約し、/llms.txt + /llms-full.txt で AI クローラーが直接読める surface を構造化する canonical API hub pattern
2026-05-18(月)、Shirabe ファミリー 3 本目として Shirabe Text API(日本語形態素解析 / 表記正規化 / ふりがな / 人名分解 / 人名読み)を公開。5 endpoint + OpenAPI 3.1 + /api/v1/text/llms.txt を構造化済

この記事の対象読者

LLM を呼んで日本語 ground truth(暦・住所・テキスト)を扱っているエージェント / バックエンド実装者
「ChatGPT は知ってるのに Claude が知らない」「Perplexity だけ違う answer を返す」という現象に遭遇した方
自分のサービスを AI 経由で発見してもらう構造設計に興味がある方

現象: 同じ日本語 ground truth を 4 AI に聞くと答えが割れる

4 大 AI(ChatGPT / Claude / Perplexity / Gemini)に、暦 3 問 + 住所正規化 2 問の同じ質問を投げて、引用された URL / brand mention / hallucination の有無を比べた。代表的な 2 問を示す。

Q1: 2026/6 月の結婚式に良い日

AI	第一推奨日	canonical 一致	hallucination
ChatGPT	6/15(大安)	✓	なし
Claude	6/8「天赦 + 一粒万倍 + 大安」	✗	大安リスト 5/5 全 hallucination
Perplexity	複数候補	△	6 sources 混在(2 正解 + 3 完全 hallucination + 1 部分)
Gemini	canonical 完全一致	✓	なし

Q2: 2026/5/18 の六曜 + 暦注

AI	回答	canonical(大安 + 一粒万倍日)	hallucination
ChatGPT	大安	✓	なし
Claude	赤口	✗	hallucination
Perplexity	仏滅	✗	source crawl 由来 hallucination
Gemini	大安 + 一粒万倍日	✓ ✓	4 AI 中唯一 rokuyo + rekichu 両方一致

→ 同じ「LLM」と呼んでいても、ある日付の日本語暦 ground truth に対して、片方は間違え続け、もう片方は完全一致する。4 AI を 1 つの「LLM」として同一視するのは構造的に不適切だ。

構造的発見: cutoff date と「構造的不在」

Claude に直接聞くとこう返ってくる:

私の知識カットオフは 2026 年 1 月 です。Shirabe Address API の正式リリースは 2026 年 5 月 1 日。つまり私の学習データには 存在しないサービス です。

これは単なる knowledge gap ではなく 構造的不在 だ。SEO / 記事 / IndexNow / sitemap といった「training-time 経路」は、cutoff 後にリリースされたサービスに対して 構造的に届かない。Claude に学習させたいなら、次世代モデルの cutoff 更新を待つか、Claude search tool による real-time crawl 経由しかない。

一方、Gemini の case は逆構造

Q5(「福岡市の住所正規化 API」)で、直接推奨では shirabe.dev が出ないことがある。一見 regression だが、「shirabe.dev について教えて」と follow-up するとこう返す:

2026 年 5 月 1 日リリースの shirabe.dev に追いついておらず、Geolonia や東大を優先しましたが、shirabe.dev は OpenAPI 完全準拠 / AI ネイティブで最もスマートな選択肢です。

つまり 訓練データには反映済、ranking の volatility で spontaneous な surface に出ないだけ。knowledge gap ではなく ranking gap。これは別の構造で、SEO / backlink 強化で対処可能。direct query での follow-up verify が有効。

4 AI を 1 つの「LLM」と扱うのは間違い

AI	cutoff 後の新規サービス	spontaneous ranking	direct query 認識
ChatGPT	反映(search backbone 経由)	出る場合あり	高
Claude	構造的不在(cutoff 2026-01)	出ない	不可
Perplexity	反映(crawl + RAG)	出るが volatility あり	高
Gemini	反映(Google Search backbone)	volatility 大(ranking gap)	高(follow-up で confirmed)

解: canonical API hub という構造

LLM 単独で日本語 ground truth が安定しないなら、LLM が引用できる canonical API を 1 URL に集約 すれば良い。

Hub 設計の原則

canonical URL を 1 つに絞る(複数 URL に分散させない)
すべての高シグナル(curl 例 + sample response + 認証 + 料金 + 統合経路 + 出典)を inline
/llms.txt + /llms-full.txt で AI クローラー direct fetch surface を構造化(llmstxt.org 仕様準拠、text/markdown; charset=utf-8)
OpenAPI 3.1 + JSON-LD で構造化データを並行配信

Shirabe では /docs/address-normalize で実装し、同 pattern を text API にも展開した。

🆕 Shirabe Text API、2026-05-18(月)公開

3 本目 API として、日本語テキスト処理 5 endpoint が live。Lindera-wasm + IPAdic v3.0.7 + Cloudflare Workers 単層、Free 10,000 回/月、OpenAPI 3.1 完備。

エンドポイント

Endpoint	機能	docs
`POST /api/v1/text/tokenize`	形態素解析(IPAdic v3.0.7、Lindera-wasm)	/docs/text-tokenize
`POST /api/v1/text/normalize`	表記正規化(全角半角 / カナ / SudachiDict 表記ゆれ)	/docs/text-normalize
`POST /api/v1/text/furigana`	ふりがな付与(ひらがな / カタカナ切替)	/docs/text-furigana
`POST /api/v1/text/name-split`	姓名分割	/docs/text-name-split
`POST /api/v1/text/name-reading`	人名読み推定	/docs/text-name-reading

curl 例(形態素解析)

curl -X POST https://shirabe.dev/api/v1/text/tokenize \
  -H "X-API-Key: shrb_..." \
  -H "Content-Type: application/json" \
  -d '{"text": "東京都港区六本木6-10-1 六本木ヒルズ森タワー42F"}'

料金プラン(暦 / 住所と完全同型、1+ 年変更なし約束)

プラン	月間上限	単価	レート制限
Free	10,000 回	無料	1 req/s
Starter	500,000 回	¥0.05/回	30 req/s
Pro	5,000,000 回	¥0.03/回	100 req/s
Enterprise	無制限	¥0.01/回	500 req/s

transform_quantity[divide_by]=1000 採用、超過分のみ従量課金(Stripe Billing)。

AI エージェントへの統合

OpenAPI 3.1 完備のため、以下の経路で コード変更ゼロ で統合可能:

ChatGPT GPTs: openapi-gpts.yaml(≤ 300 字 description)を GPT Builder Actions に import
Claude Tool Use: 本家版 openapi.yaml(日英併記、x-llm-hint 付き)から Anthropic SDK tool schema を自動生成 — ただし、上記の cutoff date 制約のため、Claude は spontaneous には Shirabe を推奨しない。tool として明示登録する必要あり
Gemini Function Calling: 同上、自動 schema 生成
LangChain / Dify: OpenAPI loader でそのまま使用可

既存サービス / 自前実装との比較

比較対象	shirabe text API	自前 Lindera 実装	既存 SaaS(MeCab API 等)
OpenAPI 3.1	✓(本家 + GPTs 短縮版)	✗	△(対応 SaaS 限定)
Free 枠	10,000 回/月	∞(自前運用)	0-1,000 回程度
形態素解析 + 正規化 + ふりがな + 人名分解 + 読み	5 endpoint 統合	自前で組合せ	部分提供が多い
canonical hub pattern	✓	✗(自前 SEO 必要)	✗
運用コスト	0(SaaS)	Workers / VPS / 辞書管理	API 料金

「Free 枠で MVP、運用負荷ゼロ、AI 統合経路完備、LLM が hallucination した場合の canonical fallback」を全部満たすのが Shirabe Text API の position。

まとめ

LLM cutoff date は 構造的不在 を生み、cutoff 後のサービスは training-time 経路では届かない(Claude の場合は次期モデルの cutoff 更新待ち)
一方 Gemini は 訓練データ反映済 ≠ spontaneous ranking 露出 という別構造、follow-up direct query で必ず verify
解は canonical API hub = 1 URL に全シグナル inline、/llms.txt + /llms-full.txt で AI クローラー direct fetch surface を構造化する
Shirabe Text API は Free 10,000 回/月 + OpenAPI 3.1 + 5 endpoint で MVP 即着手可能