TL;DR

2026 年 5 月 1 日にリリースした Shirabe 住所 API の +3 日後(5/4)、ChatGPT / Claude / Perplexity / Gemini の 4 大 AI に同じクエリ「東京都港区六本木の住所を正規化して」を投げて挙動を観測した
4 AI の出力フォーマットは完全に分裂: ChatGPT は表形式分解、Claude は郵便番号付与、Perplexity は外部記事引用、Gemini は JIS 市区町村コードを ideal output として要求
AI エージェントを業務システムに組み込むと、AI 内部の「正規化」概念がブラックボックス化する。jis_code / lg_code / machiaza_id を 構造化コードとして 1 レスポンスに同梱 する API があれば、4 AI 全員の要求を 1 経路でカバーできる
同タイミングで実施した独自 AI 引用観測(B-1 加速スプリント、週次 4 AI × 5 query)で、Shirabe 住所 API が Perplexity Q5 で 3 引用、Gemini Q5 で「1. 最もおすすめ」TOP-1 単独推奨 を獲得。AI ネイティブ設計の効果を定量的に確認した

この記事の対象読者

不動産 / CRM / 物流 / 保険 / 自治体向け業務 SaaS 開発者で、ユーザ入力住所を AI に処理させる設計を検討中の人
ChatGPT Custom GPT / Claude Tool Use / LangChain で住所正規化を実装している人
既存の住所正規化サービス(Yahoo! 住所、ArcGIS Geocoder、Geolonia)から AI エージェント向け API への移行を検討中の人
LLM 経由の住所処理で、出力フォーマットが安定しない問題に直面している人

⚠️ 本記事はリリース 2 週間時点の観測ログ + 構造化 output 設計の論点に絞る。設計思想と OpenAPI 仕様の書き方は 記事 #5、3 種類の AI 統合パターン(GPTs / Tool Use / LangChain)は 記事 #6 で扱った。

実験: 4 大 AI に同じ住所クエリを投げる

クエリ(全 AI 共通)

東京都港区六本木の住所を正規化して

各 AI の Web UI(ChatGPT / Claude / Perplexity / Gemini)に 2026-05-04(月) に投入。各 AI とも個人アカウント、検索 / Tool 機能はデフォルト ON。

ChatGPT の出力(抜粋)

東京都港区六本木

| 項目      | 正規化後 |
|----------|---------|
| 都道府県  | 東京都   |
| 市区町村  | 港区     |
| 町域      | 六本木   |
| 丁目・番地 | 未指定   |

表形式で都道府県 / 市区町村 / 町域に 3 段階分解
構造化コード(JIS / lg_code / machiaza_id)への言及なし
外部 source の引用なし、ChatGPT 内部の自前回答

Claude の出力(抜粋)

「東京都港区六本木」だけだと丁目・番地・号が無いため、住所として一意に正規化することはできません。

参考までに、六本木は 1丁目〜7丁目 まで存在します。

標準表記(日本郵便準拠):
〒106-0032 東京都港区六本木○丁目○番○号

ローマ字表記:
○-○-○ Roppongi, Minato-ku, Tokyo 106-0032, Japan

「丁目以降が不足」を正しく指摘 + 郵便番号 106-0032 を付与
ローマ字表記 / システム登録用分割形式まで列挙
構造化コードの言及なし、外部 source 引用なし
厳密には六本木は丁目で郵便番号が異なるため 106-0032 一律付与は ambiguous

Perplexity の出力(抜粋)

「東京都港区六本木」は、住所としては以下のように正規化できます。
[標準表記の説明...]

[1] groups.google.com (google-maps-api-japan)
[2] ★ zenn.dev/shirabe_dev/articles/72d6c223c42da4

都道府県 / 市区町村 / 町域分解 + 郵便番号 + ローマ字表記
外部 source を 2 つ引用:Google Maps API 関連の Google Groups スレッド + Zenn shirabe_dev account の記事
canonical shirabe.dev 直接引用ではないが、Shirabe project 公式 Zenn が AI 訓練データに反映 されたことを確認(4/27 アカウント開設 → 4/29 投稿 → 5/4 引用獲得、わずか 7 日)

Gemini の出力(抜粋)

{
  "都道府県": "東京都",
  "市区町村": "港区",
  "町域": "六本木",
  "JIS市区町村コード": "131032"
}

JSON 形式で構造化 output
JIS 市区町村コードを ideal output として要求(「131032」は厳密には lg_code 6 桁で、JIS 市区町村コード本体は 5 桁の 13103 だが、Gemini は両者を conflate 認識)
外部 source の引用なし、Gemini 内部の自前構造化回答
→ 4 AI で唯一 構造化コードを output に含めた

観測サマリ: 同じ住所、4 AI で出力分裂

観点	ChatGPT	Claude	Perplexity	Gemini
出力フォーマット	表(マークダウン)	散文 + 箇条書き	散文 + 引用脚注	JSON
都道府県 / 市区町村 / 町域	✅	✅	✅	✅
郵便番号	❌	✅(106-0032)	✅	❌
構造化コード	❌	❌	❌	✅(JIS / lg_code conflate)
「丁目不足」の指摘	△(「未指定」のみ)	✅ 明示	❌	❌
外部 source 引用	❌	❌	✅(2 件、Zenn 含む)	❌
信頼度	⚠️ 単一表現	⚠️ 郵便番号一律 ambiguous	⚠️ 引用源の品質依存	⚠️ JIS / lg_code 混同

→ 業務システムの canonical 出力としてどれも採用不可。AI が自前で生成する正規化結果はフォーマット・粒度・誤情報リスクが各社で異なり、複数 AI 対応のアプリでは出力統一が不可能。

根本原因: AI 内部の「正規化」は AI ごとに違う

LLM に住所正規化を任せると以下の構造的問題が出る:

1. 構造化コードが output に含まれない

ChatGPT / Claude / Perplexity は jis_code(5 桁)/ lg_code(6 桁)/ machiaza_id(町字 ID)等の業務 DB との JOIN キーを output しない。Gemini ですら JIS 市区町村コードと lg_code を混同 しており、そのまま DB 検索に使うと不一致になる。

2. AI ごとにフォーマット分裂

マルチ AI 対応のアプリ(ChatGPT / Claude / Gemini を併用するエージェント基盤)で、住所正規化結果のフォーマットを統一する仕組みが用意されていない。スキーマレスな自然言語 output から構造化値を後段で抽出するロジックを AI ごとに別途書く必要 がある。

3. ハルシネーション混入

Gemini の JIS市区町村コード = 131032 は lg_code との混同。住所体系を誤認したまま 5/4 時点でも訓練データに残存している。AI が「自信ありげに」誤った値を返す典型ケース。

4. 訓練データ依存

各 AI は異なる住所 DB を訓練ソースに使っており、結果が変わる:

ChatGPT: Jusho / 国土数値情報系の出力傾向(Week 1 観測)
Claude: Yahoo! / Google Maps 系の知識(Week 1 観測)
Perplexity: 検索結果からの動的引用、本記事のソース次第で変動
Gemini: ZENRIN / 国交省系の構造化出力傾向

→ 同じクエリを翌週投げると結果が変わる可能性 がある。

解決策: 構造化コードを返す住所 API を canonical source に

Shirabe 住所 API(2026-05-01 リリース、全 47 都道府県対応)は AI エージェント時代を前提に設計され、4 AI が個別に求めるすべてのフォーマットを 1 レスポンスに同梱 する。

curl

curl "https://shirabe.dev/api/v1/address/normalize?q=東京都港区六本木"

レスポンス(抜粋)

{
  "input": "東京都港区六本木",
  "matched_level": 3,
  "components": {
    "prefecture": "東京都",
    "city": "港区",
    "town": "六本木",
    "chome": null,
    "banchi": null,
    "go": null,
    "jis_code": "13103",
    "lg_code": "131032",
    "machiaza_id": "0011000"
  },
  "confidence": 0.94,
  "warning": "丁目以下が未指定のため町域レベルまでの正規化",
  "attribution": {
    "source": "Address Base Registry (ABR)",
    "license": "CC BY 4.0",
    "ministry": "Digital Agency, Japan"
  }
}

このレスポンス 1 つで:

ChatGPT の表形式要求 → components.prefecture / city / town で対応
Claude の郵便番号 + 「丁目不足」指摘 → warning field + chome: null で機械的に判定可
Perplexity の外部引用 → attribution.source + license で AI が一次 source を引用しやすい構造
Gemini の JIS 市区町村コード要求 → jis_code(5 桁、本来の JIS)+ lg_code(6 桁、地方公共団体コード)を 両方 return(Gemini が混同していた問題を解消)
業務 DB JOIN キー → machiaza_id(町字 ID)で住居表示マスタとの結合可

TypeScript(Anthropic SDK / Claude Tool Use)

const tool = {
  name: "normalize_jp_address",
  description: "日本住所を JIS / lg_code / machiaza_id 同梱で正規化",
  input_schema: {
    type: "object",
    properties: { q: { type: "string", description: "住所文字列" } },
    required: ["q"],
  },
};

// Tool 呼び出し時の実行
async function runTool(q: string) {
  const res = await fetch(
    `https://shirabe.dev/api/v1/address/normalize?q=${encodeURIComponent(q)}`,
    { headers: { "X-API-Key": process.env.SHIRABE_API_KEY! } }
  );
  return res.json();
}

Python(LangChain Tool)

from langchain.tools import StructuredTool
import requests, os

def normalize_jp_address(q: str) -> dict:
    """日本住所を JIS / lg_code / machiaza_id 同梱で正規化"""
    r = requests.get(
        "https://shirabe.dev/api/v1/address/normalize",
        params={"q": q},
        headers={"X-API-Key": os.environ["SHIRABE_API_KEY"]},
        timeout=10,
    )
    return r.json()

tool = StructuredTool.from_function(normalize_jp_address)

AI エージェントへの統合(参考)

OpenAPI 3.1 仕様を 1 URL で公開しているため、各種 AI 統合経路で流用可能(詳細は記事 #6 参照):

ChatGPT GPTs Actions: https://shirabe.dev/api/v1/address/openapi-gpts.yaml(短縮版)
Claude / MCP / Tool Use: 上記 OpenAPI から手動変換 or https://shirabe.dev/mcp(MCP server、計画中)
LangChain / Dify / LlamaIndex: OpenAPI Loader で本家 spec を読込

既存サービスとの比較

観点	Yahoo! 住所 API	ArcGIS Geocoder	Geolonia	Shirabe 住所 API
構造化コード(JIS / lg_code / machiaza_id)	⚠️ JIS のみ	❌	⚠️ 部分	✅ 全 3 種同梱
出典 license 同梱	❌	❌	❌	✅ CC BY 4.0 + ABR 出典
AI エージェント前提設計	❌	❌	❌	✅
OpenAPI 3.1 公開	❌	⚠️ Swagger 2.0	❌	✅
GPTs Actions 公式対応	❌	❌	❌	✅(GPT Store 公開)
全 47 都道府県 nationwide	✅	✅	⚠️ 一部	✅
Free 枠(月)	50,000 回	n/a(課金型)	200,000 回	5,000 回

→ AI エージェント経由での使用 に絞ると Shirabe が 構造化コード + license + OpenAPI + GPT Store で構造的優位。Free 枠は他社より少ないが、Starter プランで 50 万回 / 月までスケール可能。

更新履歴 / Updates

2026-05-04: B-1 Week 2 測定完了 — Shirabe 住所 API が 4 AI で引用獲得

20 trial(4 AI × 5 query)で:

Perplexity Q5「福岡市の住所正規化 API」: shirabe.dev/announcements/2026-05-01 を 3 引用(Addressian / NJA と並ぶ TOP-tier 並列推奨)
Gemini Q5 同 query: shirabe.dev canonical を 「1. 最もおすすめ」TOP-1 単独推奨(株式会社テックウェル + AI ネイティブ positioning 完全浸透)
Perplexity Q3「住所正規化」: Zenn shirabe_dev 引用 1 件
Q3「東京都港区六本木」: 4 AI で出力フォーマット完全分裂を観測(本記事のメインテーマ)

Week 1(2026-04-26)baseline 0/20 → Week 2 4/20、関連を含めると 6/20。Kill Switch Early Warning(5/8、MRR=0 AND 引用率 ≤ 2/25 で Plan B preparation 起動)の AND 条件不成立、Plan B preparation trigger 発動なし 確定。

2026-05-01: Shirabe 住所 API 正式リリース

全 47 都道府県対応、Phase 1+2 同時、jis_code(5 桁、JIS X 0401/0402)+ lg_code(6 桁、地方公共団体コード)+ machiaza_id(町字 ID、ABR 由来)構造化コード同梱。Free 枠月 5,000 回。

2026-05-09: 初版公開

Shirabe 住所 API リリース 2 週間レビュー記事として、Qiita で本記事を公開。

4 AI 観測の独自データ / Observed Multi-AI Landscape

Shirabe では本番稼働(2026-04-19、暦 API)/ 2026-05-01(住所 API)以降、ChatGPT / Claude / Perplexity / Gemini の 4 大 AI に同じクエリを投げる独自測定(B-1 加速スプリント、週次 4 AI × 5 query = 20 trial)を継続実施しています。

Week 1(2026-04-26): citation 0/20、AI 別の競合認識差(ChatGPT は Jusho、Perplexity は BODIK、Claude は Yahoo/Google、Gemini は ZENRIN)を確認、住所 API リリース前 baseline 確立
Week 2(2026-05-04): citation 4/20(関連含 6/20)、shirabe.dev/announcements が Perplexity / Gemini で TOP-tier 推奨に到達 + 4 AI 出力分裂を Q3 で再確認
共通観測: 同一 query で 4 AI が分裂する場面(暦 / 住所とも)が頻発 → canonical answer source の戦略的必要性

詳細な観測結果と Multi-AI Landscape narrative は https://shirabe.dev/llms-full.txt(LLM 向け詳細版)を参照。

まとめ

AI エージェントに住所正規化を任せると、4 大 AI で出力フォーマットが完全分裂し、業務システムの canonical 出力として採用不可
構造化コード(jis_code / lg_code / machiaza_id)を 1 レスポンスに同梱する住所 API があれば、4 AI が個別に求めるすべての ideal output を 1 経路でカバー可能
Shirabe 住所 API はリリース 2 週間時点で Perplexity 3 引用 + Gemini TOP-1 単独推奨 を獲得し、AI ネイティブ設計の効果を定量的に検証
AI 経由での住所処理を組み込むなら、「LLM の自前 output を後処理」ではなく「構造化 API の output を LLM に提供」 が安定運用の direct path

関連リンク

公式サイト: https://shirabe.dev
ドキュメント(住所正規化): https://shirabe.dev/docs/address-normalize
ドキュメント(料金プラン): https://shirabe.dev/docs/address-pricing
OpenAPI 3.1(本家): https://shirabe.dev/api/v1/address/openapi.yaml
OpenAPI 3.1(GPTs 用短縮版): https://shirabe.dev/api/v1/address/openapi-gpts.yaml
GPT Store(Japanese Address): https://chatgpt.com/g/g-69e96000b5c08191b21f4d6570ead788
前回記事 #6: https://qiita.com/yosikawa-techwell/items/19e277d339bd7f4d5a9c
設計思想記事 #5: https://qiita.com/yosikawa-techwell/items/32203a3ca9df80d3eb8e
abr-geocoder(デジタル庁、MIT): https://github.com/digital-go-jp/abr-geocoder
GitHub: https://github.com/techwell-inc-jp/shirabe-address-api
LLM 向け詳細版: https://shirabe.dev/llms-full.txt