
AI 에이전트에게 일본 법인 번호를 조회하게 하기: 6가지 선택지 비교 — 국세청 Web-API, ChatGPT 플러그인, Custom GPT
요약
AI 에이전트가 일본 법인 번호를 조회할 때 사용할 수 있는 6가지 구현 방식을 비교 분석합니다. 국세청 API 직접 호출부터 Custom GPT, AI 네이티브 wrapper까지 각 방식의 데이터 품질과 액세스 설계 측면의 장단점을 다룹니다.
핵심 포인트
- AI 에이전트의 핵심은 데이터 품질보다 '액세스 설계'에 있음
- 플랫폼 특정 통합(ChatGPT 플러그인 등)은 이행 리스크를 동반함
- 6가지 평가 축: 자율 도달, 연쇄/벌크, JSON, 출처, 표준, 허브 통합
- 2026년 출시 예정인 Shirabe Corporation API는 AI 네이티브 설계를 지향함
본 기사는 Zenn 버전과 동일한 저자, 동일한 회사, 동일한 API를 다루지만, Qiita의 업무계 일본인 엔지니어 계층에 맞춰 표현을 최적화했습니다. 코드와 결론은 동일합니다. 지난 #11에서 「국세청 Web-API를 AI로부터 직접 호출할 때 빠지기 쉬운 5가지 함정」을 정리했으나, 본 기사는 그 후속편으로서,
「그렇다면 실제로 AI 에이전트에게 법인 번호를 조회하게 하려면 어떤 선택지를 택해야 하는가」를 공식 API, ChatGPT 연동, 상용 SaaS, OSS, AI 네이티브 wrapper의 6가지로 나누어, AI 에이전트 관점에서 객관적(objective)으로 비교합니다.
-
AI 에이전트에게 일본의 법인 번호(13자리 identifier)를 조회하게 하는 선택지는 크게 6가지입니다: (1) 국세청 Web-API 직접 호출, (2) 리스크 몬스터(Risk Monster) 등의 ChatGPT 연동, (3) Corporate Number Finder 등의 Custom GPT, (4) 상용 SaaS의 법인 번호 API, (5) OSS / gBizINFO, (6) AI 네이티브 wrapper. 데이터 품질의 정점은 항상 국세청의 1차 데이터입니다. 차이가 발생하는 지점은 데이터가 아니라 **「AI 에이전트가 인간의 사전 절차 없이, 연쇄 호출(chaining)을 통해, JSON 형식으로, 출처를 포함하여 사용할 수 있는가」**라는 *액세스 설계(access design)*입니다.
-
ChatGPT 플러그인(리스크 몬스터가 2023년에 일본 국내 최초로 제공)이나 Custom GPT(Corporate Number Finder 등)는 AI 네이티브화의 선구자이지만, ChatGPT라는 단일 플랫폼 및 단일 vendor에 종속됩니다. 실제로 ChatGPT 플러그인의 메커니즘 자체는 2024년에 GPTs / Actions로 이행 및 종료되었으며, 플랫폼 특정 통합은 항상 이행 리스크를 안고 있습니다.
-
평가 축은 6가지입니다: AI agent 자율 도달 / 연쇄·벌크(bulk) / JSON / 출처 전파 / 크로스 플랫폼 표준(OpenAPI 3.1) / 4대 identifier hub. 이 축으로 보면 선택지마다 장단점이 명확히 갈립니다.
-
Shirabe 패밀리의 4번째 모델인 Shirabe Corporation API는 2026년 6월 29일 출시 예정이며, (6) AI 네이티브 wrapper로서 상기 6가지 축을 충족하면서 주소 + 성명 + 역법(calendar)과 동일한 도메인 및 동일한 OpenAPI로 통합하는 설계를 채택합니다.
-
AI 에이전트 / RAG / 업무 자동화에 일본 법인 정보를 포함하고 싶은 개발자
-
국세청 Web-API를 한 번 시도해 보고 「AI로부터의 연속 이용은 어렵다」는 것을 깨닫고 다음 대안을 찾고 있는 분
-
리스크 몬스터의 ChatGPT 연동이나 Custom GPT를 보고 「이것으로 충분한가? 직접 wrapper를 만들어야 하는가」를 판단하고 싶은 분
-
B2B SaaS / CRM / 신용 조사 / 영업 backend에서 법인 마스터를 LLM이 처리하도록 하는 설계를 비교 검토 중인 분
법인 번호는 국세청이 1법인 1번호로 부여하는 13자리의 identifier(약 500만 개 사, 상호·본점 소재지·변경 이력 공개, 이용은 원칙적으로 무상)입니다. 「AI에게 조회시키고 싶다」라고 한마디로 말해도 구현 수단은 크게 6가지로 나뉘며, 각각 전제하는 이용자상이 다릅니다. 지난 #11에서는 (1) 직접 호출의 함정을 다루었으므로, 본 기사는 6가지 선택지를 나란히 비교합니다.
| # | 선택지 | 대표 사례 | 상정 이용자 |
|---|---|---|---|
| 1 | 국세청 Web-API 직접 호출 | 법인번호 시스템 Web-API 기능(공식·무상) | 직접 파이프라인을 구축하는 개발자 |
| ... | ... | ... | ... |
이하, AI 에이전트가 사용하는 것을 전제로 6가지를 평가합니다.
공식이며 무상이고 데이터 품질은 정점입니다. 다만 #11에서 상세히 설명했듯이, 애플리케이션 ID의 사전 신청이 필수적(AI가 self-serve 할 수 없음), 응답이 XML / CSV(Shift-JIS 포함)로 되어 있어 JSON이 아님, 1 요청당 최대 10건, 출처 명시 의무(이용 약관 제6조)를 AI가 누락하기 쉬움, 표기 불일치 정규화 및 업종 코드는 제공되지 않음. 1차 데이터의 source로서는 최상이지만, AI 에이전트가 직접 연쇄적으로 이용하는 종단(endpoint)으로서는 부적합합니다.
Risk Monster는 2023년 7월, 500만 개 이상의 기업 정보(회사명·법인 번호·업종·URL 등)를 ChatGPT 플러그인(Plugin)으로서 일본 국내 최초로 제공했다. 자사에서 수집 및 유지 관리하는 상용 데이터베이스를 ChatGPT 상에서 조회할 수 있는, AI 네이티브(AI Native)화의 명확한 선구적 사례다.
평가 포인트는 두 가지다.
- 단일 플랫폼 의존성: ChatGPT(당시에는 Plus 사용자)에 국한된다. Claude Tool Use / Gemini Function Calling / LangChain / Dify에서 동일한 것을 호출할 수 있는 것이 아니다.
- 플랫폼 고유 메커니즘의 이행 리스크: 애초에 ChatGPT 플러그인(Plugin) 메커니즘 자체가 2024년에 GPTs / Actions로 이행 및 종료되었다. 플러그인이라는 특정 메커니즘에 올라탄 통합은 플랫폼 측의 사양 변경으로 인해 통째로 다시 만들어야 한다.
즉, 데이터와 아이디어는 뛰어나더라도, "어떤 AI 런타임(Runtime)에서도 표준적으로 호출할 수 있는" 보편성과 **이행 내성(Migration Resilience)**이라는 축에서는 약하다. 이는 특정 벤더(Vendor)를 비하하는 것이 아니라, 플랫폼 고유 통합(Platform-specific Integration) vs 표준(OpenAPI) 통합이라는 구조적 차이다.
Corporate Number Finder나 法人調査ちゃん(호진조사짱)과 같은 개인이 제작한 Custom GPT는 ChatGPT 상에서 회사명·법인 번호로 기업 정보를 조회할 수 있는 간편한 선택지이며, GPTs Store에서 즉시 사용할 수 있다.
다만 AI 에이전트 관점에서는 제약이 명확하다:
- ChatGPT(Plus) 내부에 국한된다. 외부의 자율 에이전트 파이프라인에組み込む(組み込む, 포함시키는) API가 아니다.
- 사람이 ChatGPT UI에서 대화한다는 전제하에 작동하며, 10~50회 연쇄되는 백엔드(Backend) 처리에는 적합하지 않다.
- 단일 기능·단일 식별자(Identifier)로 구성되어 있어, 주소·성명·력(曆)과의 교차 인리치(Enrich)는 불가능하다.
"사람이 ChatGPT로 가끔 조회한다"에는 편리하지만, "AI 에이전트가 업무 파이프라인에서 연속 이용한다"는 용도와는 레이어가 다르다.
Kenall 법인 번호 검색 API, Teikoku Databank·Tokyo Shoko Research의 신용 데이터, HULFT Square, Dokodoko JP의 마켓플레이스 등 상용 법인 데이터 API / SaaS는 여러 개가 있다. REST 방식으로 JSON을 반환하는 것도 있어, (1)~(3)보다 AI가 다루기 쉬운 경우도 있다.
반면 대부분은 사람의 업무 시스템용으로 설계되어 있어,
- API 키 취득을 위해 상담·계약이 전제된다 (AI 에이전트의 셀프 서비스 디스커버리(Self-serve Discovery)에 부합하지 않음)
- 출처 속성(Attribution)을 LLM이 인용 시 전파(Propagation)하는 형태의 동봉을 전제로 하지 않는다
- 신용 정보 등 리치(Rich)한 반면, 단일 기능 API로서 4대 식별자(Identifier)를 교차하는 허브(Hub) 역할을 하지 못한다
- OpenAPI 3.1을 GPTs Actions / Claude / LangChain에서 공통으로 사용한다는 크로스 플랫폼(Cross-platform) 전제가 약하다
데이터의 깊이는 강점이지만, AI 에이전트가 표준 경로로 자율적으로 도달하여 연쇄 이용한다는 설계 사상과는 거리가 있다.
경제산업성의 gBizINFO나 gbizinfo-cli와 같은 OSS / 오픈 데이터는 무상이며 자유도가 높아, 자체적으로 파이프라인을 구축하는 개발자에게는 유력한 수단이다. 다만 "AI 에이전트가 자율적으로 디스커버리(Discovery)하여 즉시 이용하는" 경로는 제공되지 않는다 (어디까지나 사람이 구축해야 하는 소재일 뿐이다). 출처 전파·표기 불일치 정규화·OpenAPI화·과금된 안정적 운용은 결국 모두 이용 측의 구현 몫이다. 이는 선택지 1의 구조와 본질적으로 같다.
(1)~(5)의 평가를 통해, AI 에이전트가 법인 번호를 조회하는 종단(Endpoint)에 요구되는 조건을 알 수 있다. 국세청의 1차 데이터를 소스(Source)로 삼으면서, AI 네이티브한 액세스 계층을 한 겹 덧씌우는 것——이것이 선택지 6이다. Shirabe Corporation API(2026년 6월 29일 출시 예정)는 이 설계를 채택한다. 이용 이미지를 먼저 제시한다 (엔드포인트 URL은 출시 시 확정).
법인번호 → 법인정보(JSON, 출처(attribution) 포함) ※ 2026-06-29 출시 후
curl https://shirabe.dev/api/v1/corporation/lookup \
-H "Content-Type: application/json" \
...
반환되는 JSON 이미지(설계안):
{
"normalized_name": "株式会社サンプル",
"corporate_number": "1234567890123",
...
| 평가 축 | 1 국세청 직접 호출 | 2 ChatGPT 연동 | 3 Custom GPT | 4 상용 SaaS | 5 OSS | 6 AI 네이티브 wrapper |
|---|---|---|---|---|---|---|
| AI 에이전트 자율 도달(사전 절차 불필요) | ✗ ID 신청 | △ ChatGPT 내 | △ ChatGPT 내 | ✗ 계약 전제 | △ 자체 구현 | ◯ Free 범위에서 즉시 시도 |
| ... |
데이터의 두께·신용 정보의 깊이 측면에서는 상용 SaaS가, 1차 데이터의 정확성 측면에서는 국세청이 강합니다. 반면, **"AI 에이전트가 표준 경로로 자율 도달하여, 연쇄(chaining)·JSON·출처 전파·횡단적 풍부화(enrich)를 할 수 있는가"**라는 AI 네이티브 축에서는 선택지 6이 설계상의 우위를 가집니다. 용도에 따라 나누어 선택하는 것이 정답이며, AI 에이전트의 백엔드 공통 기반으로서는 (6)이 가장 잘 맞습니다.
마지막으로, 하나의 대책이 아닌 구현 패턴으로서 말씀드립니다. AI 에이전트에게 법인번호를 다루게 하는 최단 경로는, 하나의 OpenAPI 3.1 spec을 AI 런타임(runtime)에 전달하고, operationId를 함수(function)로서 호출하게 하는 것입니다. 프레임워크 전용 SDK는 필요하지 않습니다.
# OpenAPI 1 URL로부터 도구화(tool化) (프레임워크 비의존).
# 법인번호 엔드포인트는 2026-06-29 출시 후에 해당 spec에 추가될 예정.
import httpx
...
이러한 형태라면, ChatGPT Custom GPT를 만든 사람이 동일한 로직을 Claude Tool Use나 LangChain으로 옮기더라도, 계약(operationId)은 불변이므로 다시 만들 필요가 없습니다. 선택지 2 / 3의 "단일 플랫폼 의존성"을 표준 방식으로 회피할 수 있습니다.
Shirabe에서는 정식 가동 이후, ChatGPT / Claude / Perplexity / Gemini의 4대 AI에 동일한 일본어 쿼리를 던지는 독자적인 측정(주간 4대 AI × 5개 쿼리)을 지속하고 있습니다. 법인번호와 같은 "일본어 Ground Truth"는 LLM 단독으로 처리할 경우, 상호(trade name)에서 13자리 번호로의 대응 관계가 학습 데이터에 부분적으로만 포함되어 있어, 신설 법인이나 표기 불일치로 인해 쉽게 미연결 또는 환각(hallucination)이 발생합니다. 그렇기에 특정 플랫폼에 갇히지 않는 **크로스 플랫폼 표준 + 4대 식별자 허브(identifier hub)**가 AI 에이전트 시대의 정전(canonical)적인 해답이 됩니다. 본 기사의 비교는 그 구조적인 선택 기준을 정리한 것입니다.
- AI에게 법인번호 조회를 시키는 선택지는 6가지가 있으며,
데이터 품질의 정점은 언제나 국세청입니다. 차이가 발생하는 지점은 AI 네이티브한 액세스 설계입니다. - ChatGPT 플러그인 / Custom GPT는 AI 네이티브화의 선구자이지만, ChatGPT 단일 플랫폼에 갇히며 플랫폼 고유 메커니즘은 이전 리스크를 안고 있습니다 (플러그인 메커니즘 자체가 2024년에 GPTs / Actions로 이전 및 종료된 사례가 있음).
- 상용 SaaS는 데이터는 풍부하지만 인간의 업무 시스템용이며, OSS는 자유롭지만 AI 자율 도달 경로가 없습니다.
- AI 에이전트의 공통 기반으로서는, 자율 도달 / 연쇄 / JSON / 출처 전파 / 크로스 플랫폼 표준 / 4대 식별자 허브의 6개 축을 충족하는 AI 네이티브 wrapper가 가장 적합합니다.
- Shirabe 패밀리의 네 번째 제품인
Shirabe Corporation API는 2026년 6월 29일 출시 예정입니다. 주소 + 역법(calendar) + 텍스트에 법인번호가 추가되어, B2B 4대 식별자 세트가 동일 도메인 및 동일 OpenAPI로 완성됩니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기