mcp-jp-corporate-id

mcp-jp-corporate-id

こちらは日本語版です

日本の法人番号（houjin bangou）と適格請求書発行事業者の登録番号を検証・正規化し、一般的な表記の違いをまたいで会社名を正規化・照合するMCP（Model Context Protocol）サーバーです。

ネットワークアクセスは一切使用しません（v1 では外部 API を呼び出しません）。すべてのチェックは、コードに組み込まれた数式と辞書データを使って行います。

最初にお読みください

• このツールが検証するのは、番号や名称の形式のみです。会社が実在するかどうか、または請求書発行事業者の登録が現在有効かどうかは確認しません。 実際の確認には、必ず以下の国税庁公式サイトを直接ご確認ください。
  • 法人番号公表サイト
  • 適格請求書発行事業者公表サイト
• 日本の個人番号（マイナンバー）は絶対に入力しないでください。 会社の登録番号（12 桁）と個人のマイナンバー（12 桁）は桁数が同じで、このツールでは入力された番号がどちらの種類かを判別できません。calculate_check_digit は、応答に必ずこの点についての注意を含めます。
• このサーバーはリクエストの入力を記録しません。また、検証エラーのメッセージに送信された番号そのものが含まれることもありません。

ツール（全 7 種類）

ツール	説明
validate_corporate_number	13 桁の法人番号のチェックデジットを検証します
calculate_check_digit	12 桁の会社登録番号からチェックデジットを計算し、13 桁の法人番号を導き出します
validate_invoice_number	適格請求書発行事業者の登録番号（「T」＋13 桁）を検証します
parse_corporate_number	法人番号の構成（区分、登記所コード、組織種別、連番）を分解します
normalize_company_name	会社名の表記（株式会社／(株)／㈱など、接頭辞・接尾辞の位置、旧字体）を正規化します
generate_matching_key	会社名の重複排除・照合に使用する正規化キーを生成します
compare_company_names	2 つの会社名が同じ法人を指している可能性が高いかを判定します（likely_different は厳密で限定的な条件の場合にのみ返され、判定できない場合は常に「unknown」が返されます）

各ツールの応答には、その処理の根拠となる一次情報（sources）が含まれます。

1. validate_corporate_number

13 桁の法人番号のチェックデジットが正しいかどうかを検証します。全角数字、ハイフン、空白を受け付け、検証前に正規化します。正規化後の桁数が 13 桁でない場合、またはチェックデジットが一致しない場合、ツールは例外を発生させず valid: false を返します。

2. calculate_check_digit

商業登記簿の記録に基づいて割り当てられる 12 桁の会社登録番号からチェックデジットを計算し、13 桁の法人番号を導き出します。正規化後の入力が 12 桁ちょうどでない場合は、例外を発生させます（推測やゼロ埋めは行いません）。

注意：12 桁の番号は、会社登録番号ではなく個人番号（マイナンバー）の可能性もあります。すべての応答には、呼び出し元にマイナンバーを決して送信しないよう促す caution フィールドが含まれます。登記所コード部分が、一次情報に基づき確認された一般的な範囲（0100～5000）外の場合は、note が追加されます。

3. validate_invoice_number

適格請求書発行事業者の登録番号（「T」＋13桁）を検証します。

• 法人が保有する番号（「T」＋法人番号）については、チェックデジットを数式で検証し、一致した場合は entityType: "corporate" を返します。
• 個人事業主や法人格のない団体が保有する番号は、国税庁が発行する独立した13桁の番号で、マイナンバーとも 法人番号とも重複しません。**確認した一次資料では、この種の番号のチェックデジットのアルゴリズムが 公開情報として文書化されていることを確認できませんでした。**番号が法人番号のチェックデジットの 数式と一致しない場合、ツールは entityType: "individual_or_other" を返し、形式のみを検証して、 このケースでは数式による検証ができないことを明示します。
• 入力が「T」＋13桁の形式に一致しない場合、例外ではなく formatValid: false を返します。

4. parse_corporate_number

13桁の法人番号のチェックデジットを検証したうえで、12桁の基礎番号の構造を解析します。

• category：national_organ_legislative / national_organ_administrative / national_organ_judicial / local_government / registered_corporation / unregistered_corporation_or_unincorporated_association / unused_range
• registered_corporation の場合は、registryOfficeCode（4桁）、organizationTypeCode（2桁の生コード）、 serialNumber（6桁）を返します。
• 2桁の組織種別コードと実際の法人形態（株式会社、合同会社など）との対応関係を、文書化された数値コード 表として確認できませんでした（商業登記規則では3つの文言上の区分が定められていますが、確認した 条文にはそれらの数値コードが明記されていません）。そのため、ツールはラベルを付けずに2桁の生コードのみを 返します。詳しくは、以下の「確認できなかった項目」を参照してください。

5. normalize_company_name

会社名の表記を正規化し、法人格を取り除いた「本体名称」を分離します。

• 主な法人格の表記（株式会社/(株)/（株）/㈱など）を相互に変換します。
• 法人格が接頭辞（株式会社○○）と接尾辞（○○株式会社）のどちらにあるかを判定します。
• 全角・半角文字と、厳選した旧字体・異体字（例：髙→高、﨑→崎）を正規化します。

辞書の制限：対象となるのは、主な法人格と異体字のみです。日本のあらゆる法人形態や表記の異形を網羅して いるわけではありません。辞書にないものは認識されず、そのまま本体名称に残ります。

6. generate_matching_key

内部で normalize_company_name を使用し、重複排除用の照合キーを生成するため、本体名称から空白を削除します。

7. compare_company_names

両方の名称を正規化して比較し、verdict、confidence レベル、および reasons を返します。

設計：判定結果と理由は、同じ構造化された根拠からどちらも機械的に生成されます

判定結果／信頼度のロジックと説明文を別々に手書きするのではなく、このツールは単一の構造化オブジェクト evidence から両方を導き出し、レスポンスにそのまま含めます。

フィールド	意味
scriptMismatch	本体名の文字種が大きく異なるため、比較自体に意味がないと判断されたかどうか
bodyMatch	本体名の関係：「exact」、「partial」、または「none」
commonTokens	実際に見つかった共通部分文字列
labelMatch	会社形態の表記（株式会社／合同会社など）が一致するかどうか（該当しない場合は null）
positionMatch	接頭辞／接尾辞の位置が一致するかどうか（該当しない場合は null）
distinguishing	likely_different の判定の根拠となる、共通トークンと識別要素の組み合わせ（それ以外の場合は null）

判定ロジック（evidence → verdict／confidence）と説明ロジック（evidence → reasons）は別々の関数ですが、どちらもこの同じ evidence オブジェクトだけを参照します。判定ルールを変更しても説明との整合性は自動的に保たれるため、信頼度の高い判定に対して reasons／notes が「判定できません」と述べるような事態は、構造上起こり得ません。

文字種の不一致に対するガード（スコアリングの前に実行）

2つの本体名の文字種が大きく異なる場合（片方がラテン文字のみで、もう片方に日本語（ひらがな／カタカナ／漢字）が含まれる場合）、文字列として比較することには原理的に意味がありません。たとえば、「日本電気株式会社」（Nippon Electric Company）と「NEC」は同じ会社を指しますが、本体名の文字列には共通する文字がまったくありません（「NEC」は略称であり、文字列比較では検出できません）。この文字種の不一致が検出されると、スコアリングを試みる前に、ツールは直ちに unknown（confidence: "low"）を返します。

likely_different を返す条件

likely_different が返されるのは、以下のすべてを満たす場合に限られます。

• 2つの本体名に、2文字以上の共通する接頭辞または接尾辞（「共通トークン」）があります。
• それぞれの側で共通部分に含まれない残りの部分（「識別要素」）が両方とも2文字以上あり、2つの識別要素が異なります。

例：「東京電力」と「東北電力」では、接尾辞の「電力」が共通トークンで、「東京」と「東北」が識別要素です。両方の名前が同じ命名パターンに従いながら、地域を明確に特定する要素が異なるため、このツールは別会社である可能性が高いと判定します。

この条件を満たさない場合（共通部分がまったくない場合、または一方の名前が他方の部分文字列にすぎない場合）、別会社であることを示す肯定的な根拠はないため、ツールは必ず unknown を返します。2つの文字列が一致しない、または重複しないという事実だけでは、決して likely_different の根拠になりません。文字列が重複しないことは、別の事業体であることの根拠ではありません。reasons のテキストでは、両方に同じ表現を使うのではなく、「共通部分がまったくない」場合と「部分的に一致する」場合を区別して説明します。

信頼度はmediumまでに制限され、判定と必ず整合します

confidenceの値は"medium"と"low"の2種類のみです。"high"は廃止されました。 2006年の会社法施行により類似商号の規制が廃止されたため、本店所在地が異なれば、無関係な2社が同じ名称で登記される可能性があります。そのため、商号のみを根拠に強い信頼度（"high"）を付与することは、原則としてできません。

有効なconfidenceの値は、TypeScriptの型レベルでverdictごとに制約されています。unknownに指定できるconfidenceは"low"のみであり、likely_sameとlikely_differentに指定できるconfidenceは"medium"のみです。このツールがunknownとconfidence: "medium"を同時に返すことは、構造上あり得ません。

このツールが「信頼度を下げて曖昧さを残す」ことはありません。 以下の接頭辞／接尾辞の位置の不一致のように、本質的に判断できない場合、このツールはlikely_sameの信頼度を下げるのではなく、verdict自体をunknownにします。これは、verdictだけを基準に分岐する呼び出し元（たとえば、likely_sameとマークされたものをすべて自動マージするバッチジョブ）にとって重要です。曖昧さがconfidenceにしか反映されていなければ、そのような呼び出し元は曖昧さを見落とすことになります。

reasonsには、ツールが結論に至った具体的な理由、または結論を出せなかった理由（文字種の不一致、共通トークンがない、一部のみ一致、会社形態または接頭辞／接尾辞の位置の不一致、略称／英語名の可能性など）が、evidenceから直接生成されて常に記載されます。すべての応答には、手法の制約についての固定の注記も含まれます。

このツールは表記の正規化に基づいてテキストを比較するだけであり、略称、英語名、愛称が同じ事業体を指すかどうかは判断できません。確実に同一性を確認するには、法人番号との照合が必要です。

What this tool can and cannot determine

Case	Example	verdict	confidence
Body name, corporate form, and prefix/suffix placement all match	"株式会社サンプル" vs. "㈱サンプル"	likely_same	medium (same trade name could still belong to a different company — cross-reference the corporate number)
Body name and corporate form match, but prefix/suffix placement differs (prefix vs. suffix)	"株式会社サンプル" vs. "サンプル(株)"	unknown	low (prefix/suffix placement is part of the trade name itself — legally a different trade name that could belong to a different company)
Body name matches, but the corporate form itself differs (株式会社 vs. 合同会社)	"株式会社サンプル" vs. "合同会社サンプル"	unknown	low (an organizational conversion — e.g. a stock company converting to an LLC — keeps the same corporate number, so the two records could just be the same entity at different points in time)
Script mismatch (one Latin-only, the other contains Japanese)	"日本電気株式会社" vs. "NEC"	unknown	low (guard fires before scoring)
Shared common token (≥2 chars) with clearly different distinguishing elements (≥2 chars each)	"東京電力" vs. "東北電力"	likely_different	medium
One body name is a substring of the other (doesn't meet the distinguishing-element condition)	"株式会社サンプル" vs. "株式会社サンプル商事"	unknown	low
No shared token at all	"株式会社あいうえお" vs. "株式会社かきくけこ"	unknown	low

The only case where this tool returns likely_same (medium) is when the body name, corporate form, and prefix/suffix placement all match. Even when the body name appears to match, a differing prefix/suffix placement or a differing corporate form leaves a real possibility of a different entity that cannot be ruled out in principle, so the tool returns unknown. likely_different is returned only when the strict "shared pattern

• clearly different identifier" condition above is met. Every other case is unknown. unknown does not mean "probably different" — it means "this method cannot determine it." When a definitive identity check is required, obtain each company's corporate number and cross-reference with validate_corporate_number or similar.

Primary sources

The number-validation logic was implemented only after retrieving and reading the following primary sources directly (last checked: 2026-07-29):

• Check-digit formula: NTA Corporate Number site, "Check Digit Calculation" https://www.houjin-bangou.nta.go.jp/documents/checkdigit.pdf
• Corporate number (13-digit) structure: NTA Corporate Number site, "Structure of the Corporate Number" https://www.houjin-bangou.nta.go.jp/documents/houjinbangounokousei.pdf
• Overview of the corporate number system (who is assigned a number; categories for national organs, local governments, registered corporations, etc.): NTA Corporate Number Management Office, "About the Corporate Number" (June 2026 edition) https://www.houjin-bangou.nta.go.jp/setsumei/pamphlet/images/houjinbangou_gaiyou.pdf
• Act on the Use of Numbers to Identify a Specific Individual in Administrative Procedures, Article 39: https://laws.e-gov.go.jp/law/425AC0000000027
• Its Cabinet Order (Cabinet Order No. 155 of 2014), Articles 35 (corporate number structure) and 36 (units for assigning numbers to national organs): https://laws.e-gov.go.jp/law/426CO0000000155
• Ordinance on the Assignment of Corporate Numbers (MOF Ordinance No. 70 of 2014), Articles 2 (check-digit formula) and 3 (base numbers for non-registered entities): https://laws.e-gov.go.jp/law/426M60000040070
• Commercial Registration Rules (Ministry of Justice Ordinance No. 23 of 1964), Article 1-2 (recording of company registration numbers): https://laws.e-gov.go.jp/law/339M50000010023
• Invoice registration number structure: NTA Qualified Invoice Issuer Publication Site, "About Registration Numbers" https://www.invoice-kohyo.nta.go.jp/about-toroku/index.html

検証できなかった項目（正直に開示）

• 会社登録番号の「組織種別」にあたる2桁部分の具体的な数値コード表（例：「株式会社」と「合同会社」を示す数字）は確認できませんでした。商業登記規則第1条の2では、3つの文言上の区分（「株式会社」「合名会社・合資会社・合同会社および外国会社」「商号を使用する者など」）が定められていますが、確認した法令本文にはそれらの数値コードが記載されておらず、オンラインで見つかった二次資料（ブログ記事など）の内容も互いに異なっていました。このため、parse_corporate_number は解釈上のラベルを付けず、生の2桁コードのみを返します。
• 地方自治体のサブコード（「20」／「30」）が具体的に何を区別しているのか（例：都道府県と市区町村）は確認できませんでした。
• 個人事業主および法人格のない団体に発行される13桁のインボイス登録番号のチェックディジットアルゴリズムは、公開文書で確認できませんでした。そのため、この区分の番号は形式のみを検証し、数理的なチェックディジット検証は行いません。
• 会社形態と旧字体の辞書は、法令上の定義を網羅したものではありません。一般的に見られる表記を実用目的で手作業によりまとめたものです。

セットアップ

1. 前提条件

• Node.js（LTS を推奨）

node --version

2. 依存関係のインストール

npm install

3. ビルド

npm run build

成功すると、build/index.js が作成されます。

Claude Desktop からの使用

以下を Claude Desktop の設定ファイル（claude_desktop_config.json）に追加します。

{
  "mcpServers": {
    "jp-corporate-id": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-jp-corporate-id/build/index.js"]
    }
  }
}

設定ファイルの場所：

• Windows：%APPDATA%\Claude\claude_desktop_config.json
• macOS：~/Library/Application Support/Claude/claude_desktop_config.json

その後 Claude Desktop を再起動すると、validate_corporate_number などのツールが利用可能になります。

テストの実行

npm test

すべてのテストに ✔ が表示されるはずです。

プロジェクト構成

mcp-jp-corporate-id/
├── src/
│   ├── sources.ts          … list of cited primary sources
│   ├── errors.ts            … shared validation-error class
│   ├── normalize.ts         … full/half-width, hyphen, etc. input normalization
│   ├── checkDigit.ts        … the check-digit formula
│   ├── corporateNumber.ts   … 12-digit base-number structure parsing
│   ├── corporateIdCalc.ts   … logic for tools 1-4
│   ├── companyNameData.ts   … corporate-form dictionary, legacy-kanji map
│   ├── companyName.ts       … logic for tools 5-7
│   └── index.ts             … MCP server entry point (registers the 7 tools)
├── tests/                   … automated tests (node:test)
├── package.json
├── tsconfig.json
├── LICENSE
├── README.md                … this file
└── README.ja.md             … Japanese version

関連ツール

同じ作者による他のサーバー：

• mcp-jp-paid-leave — 日本の労働基準法に基づく法定年次有給休暇を計算する MCP サーバー
• mcp-jp-calendar — 日本の営業日、祝日、五十日（ごとおび）の決済日、会計四半期に対応する MCP サーバー

ライセンス

MIT