AIエージェントに日本人の氏名を姓名分割・読み推定させる 6 つの選択肢を比較する — MeCab/Sudachi・namedivider・デジタル庁氏名突合支援・商用ふりがな API・LLM 直接・AIネイティブ wrapper

Posted at 2026-07-05

本記事は Zenn 版と同じ著者・同じ会社・同じ API を扱いますが、Qiita の業務系日本人エンジニア層に向けて表現を最適化しています。コードと結論は同一です。以前 #12 で法人番号、#13 で住所正規化の選択肢を比較しました。本記事はそのシリーズ第 3 弾 = 「AI エージェントに日本人の氏名(姓名分割・読み推定)を処理させるなら、どの選択肢を採るべきか」 を、形態素解析ライブラリ・専用 OSS・公的 API・商用サービス・LLM 直接・AI ネイティブ wrapper の 6 つに分けて、AI エージェント観点で objective に比較します。

TL;DR

「山田太郎」を「山田/太郎」に割る(姓名分割)と、「やまだたろう」と読む(読み推定)は、日本語処理の中でも“正解が一意に定まらない”難所。「東海林」は姓か名か、「裕子」は「ゆうこ」か「ひろこ」か — 文字列だけでは決まらない
選択肢は大きく 6 つ:(1) 形態素解析ライブラリ(MeCab / Sudachi + 辞書)、(2) 姓名処理専用 OSS(namedivider 等)、(3) 公的 API(デジタル庁氏名突合支援サービス)、(4) 商用ふりがな変換 API、(5) LLM に直接推定させる、(6) AI ネイティブ wrapper
分割精度の頂点は専用 OSS の namedivider(公称 99.9%)。ただしライブラリ組込前提で、外部の AI エージェントが登録なしで叩く REST 終端ではない
LLM 直接は一見便利だが、読みは「もっともらしい推測」を確定値のように返すのが構造的な弱点。名寄せ・口座名義・宛名など業務データに使うと事故る
評価軸は 6 つ: AI agent 自律到達(登録・キー不要)/ 連鎖・バルク / JSON 構造化 / confidence・出典の明示 / OpenAPI 3.1 標準 / 他 identifier(住所・法人・暦)との横断。この軸で見ると選択肢ごとに得手不得手がはっきり分かれる
Shirabe ファミリーの Text API(name-split / name-reading)は 2026 年 5 月 18 日からリリース済み。キー不要の匿名 Free 枠(月 10,000 回)で、AI エージェントが会話の中からそのまま叩ける

この記事の対象読者

AI エージェント / RAG / 業務自動化に「顧客名簿の姓名分割・ふりがな付与」を組み込みたい開発者
CRM / 名寄せ / 帳票系 SaaS で氏名データのクレンジングを LLM に任せようとして、読みの誤りに気付いた方
namedivider を試して「精度は申し分ないが、外部エージェントから SaaS 的に叩ける終端はないか」を探している方

前提: 氏名処理は「分割」と「読み」で難しさの質が違う

日本人の氏名処理には 2 つの独立した問題がある。

1. 姓名分割: 「山田太郎」のようにスペースなしで届いた氏名を姓と名に割る。「佐藤」「鈴木」なら簡単だが、「東海林太郎」(東海林=しょうじ、姓)や 1 文字姓・複合姓が絡むと文字列規則だけでは決まらない。統計・辞書ベースの手法で高精度化されてきた領域で、専用 OSS は公称 99.9% に達している。

2. 読み推定: 「裕子」は「ゆうこ」「ひろこ」「やすこ」のどれか。漢字表記から読みは原理的に一意に定まらない。取れる立場は「候補と確度を返す」(推定)か「本人確認済みのカナと突合する」(検証)のどちらかで、この違いがそのままツール選定の分岐になる。

#	選択肢	代表例	想定利用者
1	形態素解析ライブラリ	MeCab / Sudachi + 辞書	NLP パイプラインを自前構築する開発者
2	姓名処理専用 OSS	namedivider-python 等	ライブラリを組み込む開発者
3	公的 API	デジタル庁氏名突合支援サービス	行政・給付事務、突合業務
4	商用ふりがな変換 API	よみたん API、AI JIMY Converter 等	業務システム担当
5	LLM 直接	GPT / Claude / Gemini にそのまま推定させる	プロトタイピング
6	AI ネイティブ wrapper	Shirabe Text API(2026-05-18 リリース済)	AI から呼出、開発者 / 組織が採用

以下、AI エージェントから使う前提で 6 つを評価する。

選択肢 1: MeCab / Sudachi + 辞書 — 汎用 NLP の王道、ただし「氏名特化」ではない

MeCab や Sudachi は日本語形態素解析の標準的な選択肢で、辞書(IPAdic / UniDic / NEologd 系)を組み合わせれば人名の分割・読みもある程度は取れる。既に NLP パイプラインを自前で持っているなら追加コストは小さい。

AI エージェント観点では、

汎用の形態素解析であって氏名特化ではない。姓名の境界判定や人名読みの精度は搭載辞書に依存し、辞書に無い名前は一般語の読み規則に引きずられる。
ローカル実行・辞書管理・ホスティングは利用側の責任。外部エージェントが登録なしで叩ける REST 終端ではない。
読みの「確度」を構造化して返す仕組みは自分で設計する必要がある。

自前パイプラインの一部品としては優秀。氏名処理の完成品ではない。

選択肢 2: namedivider — 姓名分割の専用 OSS、精度の頂点

namedivider-python は日本人のフルネームを姓と名に分割する専用 OSS で、漢字の統計情報を使い公称 99.9%(GBDT モード)の分割精度を出す。CLI / Python ライブラリ / Docker で使え、Rust 実装(namedivider-core)による高速化も進んでいる。姓名分割に関しては、これが事実上の precision の基準と言ってよい。

評価上のポイントは 2 つ。

守備範囲は分割。読み推定(ふりがな付与)は目的外で、読みが要るなら別のコンポーネントを重ねる必要がある。
ライブラリ組込前提。自分のビルドに同梱して使うもので、外部の自律エージェントが OpenAPI 経由で discovery して即叩く REST 終端とはレイヤーが違う(この構図は住所比較(#13)における Geolonia OSS と同じ)。

なお読み推定側の OSS としては、LINE のエンジニアリングブログで公開された Namelti(人名の読み仮名候補を列挙するライブラリ)のように「一意に決めず候補を返す」設計が知られている。読みが原理的に非一意である以上、この設計思想は正しい。

選択肢 3: デジタル庁氏名突合支援サービス — 「推定」でなく「突合」の公的 API

デジタル庁の氏名突合支援サービスは、氏名の「漢字・アルファベット」と「カナ」を突合・推定する業務支援 API で、照合(簡易/詳細)と漢字⇔カナの相互推定の機能を提供する。給付業務での「漢字氏名と振込先口座名義(カナ)の突合」が典型ユースケースで、セルフホスティング方式も選べる。

AI エージェント観点では、

メールアドレスでのアカウント登録が必要。人間の事前手続きを挟むため、エージェントが会話の中で自律到達して即叩く用途には一段の摩擦がある。
設計の主眼は「手元に漢字とカナの両方があり、その整合を検証する」突合業務。カナが手元に無い状態でのふりがな新規付与を主目的とするサービスではない(推定機能はある)。
公的サービスとしての信頼性は高く、該当業務(行政・給付・本人確認系)では第一候補。

選択肢 4: 商用ふりがな変換 API — 実務の定番、契約・料金体系は要確認

商用のふりがな変換サービスも複数ある。例えばよみたん API は非商用無料・商用/企業内 API 利用は有料の読み変換 API、AI JIMY Converter は人名フリガナ変換のツール + API を提供し外国人名にも対応をうたう。帳票・OCR 後処理などの業務文脈で実績がある。

AI エージェント観点では、

商用利用の契約・APIキー発行・料金体系が前提になるものが多く、自律エージェントの「まず 1 回叩いて試す」には手続きの摩擦がある。
各社の現行仕様・料金・利用条件は変わり得るため、採用前に必ず各社ドキュメントで確認してほしい(本記事は名指しの優劣評価をしない)。

選択肢 5: LLM に直接推定させる — プロトタイプは最速、業務データでは事故る

「この名簿の氏名にふりがなを振って」と LLM に投げるのが最速の実装であることは間違いない。文脈(メールアドレスに yuko とある、等)を使える柔軟さは LLM にしかない強みだ。

構造的な弱点は 3 つ。

読みの「推測」を確定値のように返す。「裕子」を根拠なく「ゆうこ」と返し、confidence も出典も付かない。名寄せ・口座名義・宛名印字のような業務データでは、この“もっともらしさ”がそのまま事故になる。
結果が再現しない。同じ入力でもモデル・タイミングで揺れるため、バッチ処理の冪等性が成立しない。
1 件ごとに LLM 推論コストがかかり、数万件の名簿クレンジングでは分割・読みのような決定的処理に LLM を回すのは割に合わない。

LLM は「どのツールを呼ぶか」を判断する側に置き、氏名の確定値は決定的な API/ライブラリに取らせるのが 2026 年時点の妥当な設計だと考える。

選択肢 6: AI ネイティブ wrapper — Shirabe Text API(name-split / name-reading)

手前味噌のパートであることを明示した上で、Shirabe Text API は上記の隙間 — 「外部の AI エージェントが、事前手続きゼロで、JSON で、confidence と出典付きで氏名処理を叩ける REST 終端」 — を埋める設計を採る。エージェントの tool として「確定値(と、確定できない場合はその旨)」を返す部品、という位置づけだ。

キー不要・登録不要で、この 1 行がそのまま動く:

curl -s -X POST https://shirabe.dev/api/v1/text/name-split \
  -H "Content-Type: application/json" \
  -d '{"name": "山田太郎"}'

{
  "name": "山田太郎",
  "family": "山田",
  "given": "太郎",
  "confidence": 0.97,
  "matched_by": "dictionary_both",
  "attribution": { "dictionary": "IPAdic v3.0.7", "license": "BSD 3-Clause", "...": "..." }
}

読み推定は name-reading:

curl -s -X POST https://shirabe.dev/api/v1/text/name-reading \
  -H "Content-Type: application/json" \
  -d '{"name": "山田太郎"}'

{
  "family": "山田", "given": "太郎",
  "family_reading": "やまだ", "given_reading": "たろう",
  "reading": "やまだたろう",
  "confidence": 0.97,
  "matched_by": "dictionary_both",
  "attribution": { "dictionary": "IPAdic v3.0.7", "...": "..." }
}

Python(標準ライブラリのみ)なら:

import json, urllib.request

def name_reading(name: str) -> dict:
    req = urllib.request.Request(
        "https://shirabe.dev/api/v1/text/name-reading",
        data=json.dumps({"name": name}).encode(),
        headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(req) as res:
        return json.load(res)

print(name_reading("山田太郎")["reading"])  # やまだたろう

設計上のポイント:

匿名 Free 枠月 10,000 回(キー・登録不要、1 req/s)。AI エージェントが会話の中で「試しに 1 回叩く」をそのまま実行できる。有料プランと上限は Text API のページ参照。
confidence と matched_by を必ず返す。辞書で確定できない名前を「それらしく」返さず、確度を数値で明示する。
精度の限界も API 自身が開示する。現行は IPAdic ベースの実装で、読み推定の的中率は有名な姓名で 80–90%、希少名では大きく下がることを attribution.notes に明記している。読みの非一意性を隠さないことは、業務データに組み込む上での前提情報だと考えている。分割単体の精度では選択肢 2(namedivider)が上であり、本 API の価値はアクセス設計(自律到達・JSON・confidence・出典)と、読み・ふりがな・正規化・トークナイズが同一終端に揃っていることにある。
OpenAPI 3.1(https://shirabe.dev/api/v1/text/openapi.yaml)を公開しており、ChatGPT GPTs の Actions や Function Calling にそのまま取り込める。
同一ドメイン(shirabe.dev)に住所正規化・法人番号・暦 API が同居しており、名寄せパイプライン(氏名 + 住所 + 法人番号)を 1 つの OpenAPI ファミリーで完結できる。

比較表: AI エージェント観点の 6 軸

軸	1 MeCab/Sudachi	2 namedivider	3 デジタル庁突合	4 商用ふりがな API	5 LLM 直接	6 Shirabe Text
AI agent 自律到達(登録・キー不要)	✕(自前ホスト)	✕(ライブラリ組込)	△(要アカウント登録)	△(商用契約前提が多い)	◯(ただし下記)	◯(匿名 Free)
連鎖・バルク呼出	◯(自前次第)	◯(自前次第)	◯	◯(契約次第)	△(コスト・レート)	◯(連鎖呼出、上位プランで増枠)
JSON 構造化レスポンス	自作	自作	◯	◯	△(形式が揺れる)	◯
confidence・出典の明示	自作	スコアあり	◯(突合結果)	サービス次第	✕(推測を断定)	◯(confidence + attribution)
OpenAPI 3.1 標準	—	—	◯(仕様公開)	サービス次第	—	◯
他 identifier(住所・法人・暦)との横断	✕	✕	✕	✕	△(都度推測)	◯(同一ドメイン)
分割・読みの精度	辞書依存	分割 99.9%(公称)	突合用途で高信頼	実務実績あり	再現性なし	辞書ベース + confidence 開示(限界も明示)

※ 各サービスの仕様・料金は 2026-07 時点の公開情報に基づく。採用前に必ず一次ドキュメントを確認してほしい。

使い分けの結論

自前 NLP パイプラインがあり、分割精度が最優先 → namedivider(+読みは別コンポーネント)
行政・給付・本人確認系の突合業務 → デジタル庁氏名突合支援サービス
帳票・OCR 後処理の業務システム → 商用ふりがな API(契約・仕様は各社確認)
プロトタイプで今すぐ → LLM 直接(ただし業務データに昇格させる前に確定値系へ差し替える)
AI エージェントの tool として、登録なしで叩ける氏名処理の終端が欲しい / 住所・法人と合わせて名寄せしたい → Shirabe Text API

更新履歴 / Updates

2026-07-06: 初版公開

AIエージェントに日本人の氏名を姓名分割・読み推定させる 6 つの選択肢を比較する — MeCab/Sudachi・namedivider・デジタル庁 氏名突合支援・商用ふりがな API・LLM 直接・AIネイティブ wrapper

TL;DR

この記事の対象読者

前提: 氏名処理は「分割」と「読み」で難しさの質が違う

選択肢 1: MeCab / Sudachi + 辞書 — 汎用 NLP の王道、ただし「氏名特化」ではない

選択肢 2: namedivider — 姓名分割の専用 OSS、精度の頂点

選択肢 3: デジタル庁 氏名突合支援サービス — 「推定」でなく「突合」の公的 API

選択肢 4: 商用ふりがな変換 API — 実務の定番、契約・料金体系は要確認

選択肢 5: LLM に直接推定させる — プロトタイプは最速、業務データでは事故る

選択肢 6: AI ネイティブ wrapper — Shirabe Text API(name-split / name-reading)

比較表: AI エージェント観点の 6 軸

使い分けの結論

更新履歴 / Updates

関連リンク

AIエージェントに日本人の氏名を姓名分割・読み推定させる 6 つの選択肢を比較する — MeCab/Sudachi・namedivider・デジタル庁氏名突合支援・商用ふりがな API・LLM 直接・AIネイティブ wrapper

選択肢 3: デジタル庁氏名突合支援サービス — 「推定」でなく「突合」の公的 API