0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@shuji-bonji

「LLM が日本の法令を雑に答える」問題を、e-Gov MCP の設計でどこまで潰せるか — `houki-egov-mcp` 設計ノート

0
Posted at

「LLM が日本の法令を雑に答える」問題を、e-Gov MCP の設計でどこまで潰せるか — houki-egov-mcp 設計ノート

ファミリー全体（egov / nta / abbreviations / research-skill）の話は別途 Zenn 記事 に書きました。本記事は 法令本文 MCP @shuji-bonji/houki-egov-mcp 単体 にフォーカスして縦に深く掘ります。

要点

  • 「日本の e-Gov 法令を扱う MCP」は 2026-05 時点で 少なくとも 5 系統公開されている
  • が、素朴に e-Gov v2 を叩くだけだと検索結果の relevance が壊れていて LLM が誤読する
  • houki-egov-mcp は「略称解決 / 取得粒度コントロール / 時点指定 / Normalize-everywhere + family 統一の error contract」の 4 軸でこの前段を矯正している
  • 略称辞書 (@shuji-bonji/houki-abbreviations) は MCP の dependencies に内蔵されているので、利用者は意識不要で常に効く
  • 横断的な振る舞いルール (houki-research-skill) は 別 install が必要だがセット推奨

1. LLM はそもそも法令を正しく引けない

LLM はもっともらしい次の単語を生成し続けるだけで、何が正しいかを判断していません。
正典が決まっている領域である法令でこれをやると、典型的には次の 3 種類の事故が起きます。

  • 条文番号の捏造：「消費税法 10 条には〜」と存在しない条文を作文
  • 改正前条文の混在：学習データの時点で古い条文を最新であるかのように回答
  • 略称の取り違え：「消基通」（消費税法基本通達）と「消法」（消費税法）を取り違える

これらを潰す方法は、
　「LLM に外部から原典を渡す」=「MCP を噛ませる」
が王道です。

問題は 「e-Gov 法令 API があるんだからラップすれば終わりでは？」が思ったよりそうでもない ということ。

これが本記事の本題です。

2. 日本法令系 MCP の現在地（2026-05）

公的な日本法令 MCP は 2026-05 時点でまだ未公開です。デジタル庁・e-Gov 公式 MCP の一般公開は引き続き見送り中。

なので各人が自前 MCP を作っているのが現状で、執筆時点で確認できる「日本の e-Gov 法令を扱う MCP」は次の 5 系統あります。

MCP リポジトリ / npm 言語 法令 通達 略称
@shuji-bonji/houki-egov-mcp GitHub / npm TS e-Gov v2 別 MCP に分離 共有 npm 辞書
groundcobra009/hourei-mcp-server GitHub / npm JS e-Gov v1 × ×
kentaroajisaka/tax-law-mcp GitHub / npm TS プリセット 24 法 国税庁 17 通達 + 裁決 1,950 件 内蔵ハードコード
kentaroajisaka/labor-law-mcp GitHub / npm TS プリセット 45 法 厚労省 + JAISH 内蔵ハードコード（12）
ryoooo/e-gov-law-mcp GitHub Python 16 法直接マッピング × 内蔵ハードコード（20）

※ 上記は執筆時点（2026-05）の調査範囲での見解です。他にも近い MCP が存在する可能性があります。

5 つもあるなら自前で作る必要なくない？ となるところですが、実際に同じクエリを叩かせると、これらの間で 挙動の差が想像より大きいことが分かります。

3. 素直に e-Gov v2 を叩くだけだと relevance が壊れる

同じ「消費税法」を 3 件で取得させてみます。
（houki-egov のみ略称「消法」で投げて、それでも同じ結果が返ることを確認）

groundcobra009/hourei-mcp-server 

<LawNameListInfo>
  <LawId>321CONSTITUTION</LawId>
  <LawName>日本国憲法</LawName>
</LawNameListInfo>
<LawNameListInfo>
  <LawName>明治六年太政官布告第六十五号（絞罪器械図式）</LawName>
</LawNameListInfo>
<LawNameListInfo>
  <LawName>明治十七年太政官布告第三十二号（爆発物取締罰則）</LawName>
</LawNameListInfo>
... (limit=3 を指定したのに 24 件以上返る)

raw XML を返す上に、limit が効かず、relevance ゼロな結果が並ぶ。LLM はこれを見せられても「消費税法」にたどり着けません。

kentaroajisaka/tax-law-mcp 

1. **明治五年太政官布告第三百三十七号（改暦ノ布告）**
2. **明治六年太政官布告第六十五号（絞罪器械図式）**
3. **明治八年太政官布告第五十四号（勲章制定ノ件）**

Markdown に整形されていて読みやすいのですが、「消費税法」検索の先頭 3 件が明治の太政官布告です。プリセット内の「消費税法」を直接指定すれば取れるものの、検索動作は崩れています。

houki-egov-mcp 

{
  "query": { "keyword": "消法", "resolved": "消費税法" },
  "total_count": 3,
  "results": [
    { "law_id": "363AC0000000108", "title": "消費税法",
      "law_num": "昭和六十三年法律第百八号", "law_type": "Act" },
    { "law_id": "363CO0000000360", "title": "消費税法施行令",
      "law_num": "昭和六十三年政令第三百六十号", "law_type": "CabinetOrder" },
    { "law_id": "363M50000040053", "title": "消費税法施行規則",
      "law_num": "昭和六十三年大蔵省令第五十三号", "law_type": "MinisterialOrdinance" }
  ]
}

略称「消法」を 黙って「消費税法」に解決して、本命の法律本体・施行令・施行規則が関連性順に並びます。

これは e-Gov API 自体の制約というより、「クエリをどう正規化するか・結果をどう並べ直すか」という MCP 側の責任です。houki-egov-mcp ではこの前段処理を仕込んであります。

4. houki-egov-mcp が仕込んでいる4つの工夫

4-1. 略称解決：「消法」「労基法」を黙って正式名称に直す

houki-egov-mcp は @shuji-bonji/houki-abbreviations という独立した npm パッケージを dependencies として内蔵 しています。

// @shuji-bonji/houki-egov-mcp の package.json (抜粋)
"dependencies": {
  "@modelcontextprotocol/sdk": "^1.29.0",
  "@shuji-bonji/houki-abbreviations": "^0.3.0",
  "fast-xml-parser": "^4.5.0"
}

利用者は別途インストール不要で、@shuji-bonji/houki-egov-mcp を入れた瞬間から略称解決が常に効きます。

略称辞書を MCP 内部にハードコードせず、外部 npm パッケージとして分離している理由は 2 つあります。

  1. family 全体（egov / nta / 将来の mhlw / saiketsu）で同じ辞書を共有したい。MCP ごとに略称テーブルを持つと、必ずズレます。
  2. 各エントリに source_mcp_hint を持たせて、「この略称は別 MCP の管轄」と返せるようにしたい。

たとえば resolve_abbreviation("消基通") を houki-egov-mcp に投げると、消基通は通達なので egov 管轄外なのですが、辞書はそれを知っていて誘導 hint を返します。

{
  "abbr": "消基通",
  "resolved": {
    "formal": "消費税法基本通達",
    "category": "kihon-tsutatsu",
    "source_mcp_hint": "houki-nta",
    "note": "国税庁長官が発する消費税法の解釈通達。実務の主要参照"
  }
}

LLM 側はこの source_mcp_hint を見て houki-nta-mcp に振り直す判断ができる。MCP の誤接続を辞書層で防ぐ設計です。

競合 MCP（tax-law-mcp / labor-law-mcp / ryoooo/e-gov-law-mcp）は略称テーブルを **MCP 内部にハードコード（12〜24 件）**していて、各 MCP が自分の辞書を持つ構造です。横断的な共有・MCP 振り分けは難しい。

4-2. 取得粒度のコントロール：条/項/号 + format=toc

get_law は 法令まるごとではなく 条/項/号単位 で引けます。さらに format を切り替えると、出力形式そのものをコントロールできます。

get_law({ law_name: "消費税法", article: "9" })                // 9 条全文
get_law({ law_name: "消費税法", article: "9", paragraph: 1 })  // 9 条 1 項
get_law({ law_name: "消費税法", article: "9", paragraph: 1, item: 2 }) // 9 条 1 項 2 号
get_law({ law_name: "消費税法", format: "toc" })               // 目次のみ
get_law({ law_name: "消費税法", format: "json" })              // 構造化 JSON

これが効くのはコンテキスト経済の話です。法令まるごとを LLM に渡すと数十万トークンを食いつぶし、肝心の質問に答える前にウィンドウが詰まる。

format="toc" で目次 → 該当条の特定 → get_law で該当条のみ深掘り、というワークフローを組めると、1 法令あたり数 KBで済むようになります。LLM 側のオーケストレーション（後述する houki-research-skill）がこの段階的取得を前提に書かれているので、デフォルトでこの形に倒れます。

4-3. 時点指定 (at パラメータ) — 改正前後の混乱を防ぐ

e-Gov v2 は特定時点の条文取得に対応しています。houki-egov-mcp はこれを at パラメータでそのまま露出します。

get_law({ law_name: "消費税法", article: "30", at: "2024-04-01" })

「2024-04-01 時点の消費税法 30 条」が返るので、改正前の規定を確認したい / 過去事案を検証したい用途に直接効きます。

LLM が 「いつ時点の条文か」を区別できない と法令系では致命的です（学習データ時点の旧条文を最新であるかのように回答する事故が起きやすい）。プロトコルレベルで時点を明示できる作りは、ここの予防線です。競合の e-Gov v1 ベースの MCP では、これが API 制約で素直にできません。

4-4. Normalize-everywhere パターンと family 統一の error contract

法令テキストには全角半角・機種依存文字・罫線文字・古い文字コードが混ざります。houki-egov-mcp は クエリ・DB（family の中で使う場合）・レスポンスの全レイヤーで同じ正規化を通す「Normalize-everywhere」パターンを採用しています。これも houki-abbreviations が text-normalize 機能を共有レイヤとして提供していて、family 全体で同じ正規化が走ります。

エラーレスポンスも family 統一です。エラーコード語彙の正典は houki-research-skill 側の docs/ERROR-CODES.md に置き、各 MCP は同じ語彙のエラーコードを返します。LLM 側で「同じ意味のエラーが MCP ごとに違う言葉で返ってくる」事故が起きません。

5. セットで使うべき周辺パッケージ

houki-egov-mcp は技術的には単体で動きますが、実用上は 2 つのセット要素があります。それぞれ性質が違います。

5-1. @shuji-bonji/houki-abbreviations — 利用者は意識不要

§4-1 の通り、これは houki-egov-mcp の dependencies に入っているので、@shuji-bonji/houki-egov-mcp を入れた時点で勝手に同居します。利用者が別途インストールする必要はなく、設定もありません。

設計上は別 npm パッケージとして公開しているので、MCP を介さない自前スクリプトや別 LLM ツール（Custom GPT など）に「日本法令の略称辞書」だけ取り込みたい場合も npm i @shuji-bonji/houki-abbreviations だけで使えます。

5-2. houki-research-skill — 別 install だがセット推奨（Claude Skill）

これは MCP ではなく Claude Skill で、別途インストールが必要です。技術的には houki-egov-mcp 単体でも動きますが、法規を扱うときの行動指針を Claude に注入する役割なので、実質セットで使うべきと考えています。

Skill が担う責務：

  • 業法独占規定への注意喚起（税理士法 52 条 / 弁護士法 72 条 / 司法書士法 3 条 / 社労士法 27 条）
  • 横断オーケストレーション（法律 → 政令 → 省令 → 通達 → 改正 → PDF → 解釈 → 判例 → 裁決の階層順を強制）
  • citation の標準化（出典 URL・取得時刻・legal_status の統一フォーマット）
  • family error contract の正典管理（§4-4 で触れた ERROR-CODES.md / ERROR-HANDLING.md）

なぜ MCP に組み込まず Skill に分離したかは Zenn 側に書きましたが、要点は 「業法に注意して回答する」みたいな振る舞いルールを MCP に押し込むと、別 Skill から呼ばれた時の挙動まで縛ってしまうから。MCP は fetch + parse に徹し、振る舞いは Skill が統制する責務分離です。

インストールは shuji-bonji/claude-plugins marketplace から：

# Claude Code から
/plugin marketplace add shuji-bonji/claude-plugins
/plugin install houki-research@shuji-bonji

Cowork（個人）の場合は GitHub Releases から .plugin ファイルを直接アップロードする経路もあります（詳細は README）。

まとめると、利用者から見た「セットで入れるもの」は MCP 1 つ + Skill 1 つの 2 つだけで、辞書は MCP の中に勝手に入っています。

6. 既存 e-Gov MCP との比較（フェアに）

houki-egov-mcp 以外にもいくつかある中で、選ぶべき場面・他を選ぶべき場面を率直に書いておきます。

こういう人 推奨
LLM に法令本文を確実に引かせたい / family を組みたい houki-egov-mcp
税務領域だけで全部入り（裁決事例 1,950 件込み）が欲しい tax-law-mcp
労務領域だけで全部入り（厚労省 + JAISH 通達込み）が欲しい labor-law-mcp
Python 環境でパフォーマンス特化を選びたい ryoooo/e-gov-law-mcp
軽量な薄い e-Gov ラッパだけ欲しい groundcobra009/hourei-mcp-server

houki-egov-mcp 単体では 裁決事例 1,950 件を持っていない（tax-law-mcp は内蔵）、3 層キャッシュのような作り込みは ryoooo/e-gov-law-mcp の方が深い など、競合が先行している領域もちゃんとあります。「全部入り」を望む人は kentaroajisaka 系の方が手早く目的に届きます。

houki-egov-mcp の差別化は 「family を作って横展開する前提」 であり、その思想に乗るなら強く推奨できる、というのが正直なところです。

7. 免責

本 MCP は 公布された法令を機械可読にしているだけであり、AI による応答は 個別具体の法律相談・税務判断・労務判断ではありません。業として法律事務・税務業務に利用することは想定外で、税理士法 52 条・弁護士法 72 条・司法書士法 3 条・社労士法 27 条等の 業法独占規定 に踏み込まない設計です。

個人が 自分の事業について確認する、あるいは 実現可能性調査の補助に用途を絞ってください。

8. まとめ

LLM に日本の法令を正しく引かせるための前段処理は、素朴な e-Gov ラップでは足りないというのが今回の中心メッセージでした。houki-egov-mcp は次の 4 軸でその前段を矯正しています。

  • 略称解決 — houki-abbreviations を dep として内蔵、source_mcp_hint で MCP 振り分けまで支援
  • 取得粒度コントロール — format=toc + 条/項/号で LLM のコンテキストを節約
  • 時点指定 — at で特定日の条文取得、改正前後の混乱を防ぐ
  • Normalize-everywhere + family 統一の error contract — 揺らぎを全レイヤーで吸収、Skill 側に正典

辞書 (houki-abbreviations) は意識不要、Skill (houki-research-skill) はセット推奨。MCP 1 つ + Skill 1 つで実用構成になります。

法令系に限らず、LLM が雑に扱うと困る一次情報 がある領域は、こういう「前段の矯正」をどこまで作り込むかで応答品質が決まる、という話でした。

リンク

本記事は 2026-05 執筆時点（houki-egov-mcp v0.3.0 / houki-abbreviations v0.4.1）の内容です。最新版は npm を参照ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?