Houki e-Gov MCP Server
Summary: Houki e-Gov MCP Server lets you search and retrieve Japanese laws and provisions from e-Gov Law API v2, with abbreviation support and optional local full-text search.
Search laws by keyword, abbreviation, domain, or law type.
Retrieve specific provisions by law name/abbr, article, paragraph, item, effective date, and output format (Markdown/JSON/TOC).
Get a law's table of contents, optionally limiting depth.
Run full-text search across law bodies; uses local SQLite FTS5 if built, otherwise falls back to law-name search.
Resolve abbreviations/nicknames to official law names and law IDs.
Get amendment/revision history with promulgation, enforcement dates, and status.
Explain law types (Constitution, Act, Cabinet Order, Ministerial Ordinance, Rule, etc.).
From README: also supports range retrieval by part/chapter/section, related laws, article references, citation verification, attachments, and law files.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Houki e-Gov MCP Server消費税法30条1項を見せて"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
旧リポジトリ名houki-hub-mcp / 旧 npm 名 @shuji-bonji/houki-hub-mcp は使っていません。
現行は @shuji-bonji/houki-egov-mcp です。
Houki e-Gov MCP Server
日本の法令(憲法・法律・政令・省令・規則)を e-Gov 法令API v2 から、条・項・号の単位で、法令番号と URL を添えて返す MCP サーバーです。税法・労働法・会社法・民法など、分野を問わず条文を LLM から引けます。
通達・質疑応答事例・タックスアンサーは @shuji-bonji/houki-nta-mcp が担当します。2 つを分けているのは、「法律で決まっている」と「通達でそうなっている」を混ぜずに返すためです。
できること
税務・労務・会社の手続きなどを調べるときに、根拠になる条文を一次情報のまま確かめるための機能です。
e-Gov に収録されている法令の条文を、条・項・号の単位で返します。応答には法令番号と e-Gov の URL、取得日時が付きます
「消法」「労基法」「電帳法」のような略称でも引けます(略称辞書 174 エントリ・6 分野)
施行令・施行規則と、条文が「政令で定める」と委ねている先をたどれます
日付を指定して、その時点の条文を取れます。改正履歴(公布日・施行日)も引けます
民法の「契約」の章のように、章・節の単位でまとめて読めます
LLM が書いた引用(「所得税法第 121 条第 1 項」など)が実在するかを、まとめて確かめられます
相談の形の問いでの使い方
「会社員で、副業の所得が 20 万円以下なら確定申告はしなくてよいか」と尋ねると、LLM が get_law(law_name="所得税法", article="121", paragraph=1) を呼び、「確定所得申告を要しない場合」の条文が返ります。
条文には、答えを分ける条件が並んでいます。給与の支払者が 1 か所か 2 か所以上か、給与の全部が源泉徴収または年末調整の対象か、給与等の金額が 2,000 万円以下か、給与所得と退職所得以外の所得の合計が 20 万円以下か、ただし書きの「政令で定める場合」に当たらないか、です。利用者は、自分の事実がどの条件に当たるかを条文で確かめられます。
国税庁の解説(タックスアンサー「給与所得者で確定申告が必要な人」など)もあわせて引くには、houki-nta-mcp を併用してください。個別の事案に条文を当てはめた結論(「あなたは申告が不要です」)は返しません。理由は業法との関係に書いています。
Related MCP server: e-Gov Law MCP Server
まず試す(ローカル DB なし)
登録するだけで、14 ツールのうち 13 はそのまま動きます。e-Gov 法令 API v2 をその場で呼ぶためで、事前の取り込みは要りません。
// claude_desktop_config.json
{
"mcpServers": {
"houki-egov": {
"command": "npx",
"args": ["-y", "@shuji-bonji/houki-egov-mcp@latest"]
}
}
}再起動して「消費税法第 30 条第 1 項を見せて」「インボイス制度の登録要件は」のように尋ねると、search_law → get_law の順に呼ばれ、法令番号と e-Gov の URL 付きで本文が返ります。
ローカル DB が要るのは search_fulltext(条文本文の横断検索)だけです。DB が無いときは search_law(法令名の検索)に切り替わり、応答の source が "api-fallback" になります。本文の全文検索が要ると分かったら、そのとき一度だけ下記の「CLI(ローカル DB の構築)」を実行してください。全法令 zip(約 290 MB)の取得と取り込みが走ります。
ローカル DB なし | ローカル DB あり | |
| 動く(e-Gov API をその場で呼ぶ) | 同じ |
|
| 条文本文を横断検索する( |
提供ツール
Tool | 用途 |
| 法令タイトルでキーワード検索(略称→正式名解決済み)。 |
| 条/項/号レベルで本文取得(Markdown / JSON / TOC)。条は本則から探し、附則の条は |
| 目次のみ取得(トークン節約)。本則と附則を分け、附則は改正法ごとにまとめる(v0.13.0) |
| 編・章・節・款・目のいずれか、または附則 1 本を範囲にして条を本文ごと取得。上限を超える範囲は条の単位で打ち切り、続きの条番号を返す(v0.14.0) |
| 改正履歴を取得(公布日・施行日・状態) |
| 条文本文の横断全文検索(ローカル SQLite FTS5。bulk DB 未構築時は |
| 略称→正式名解決の診断。全角英数字・全角空白は揃えて照合し、辞書のエントリはどの管轄でも返して |
| 法令種別(憲法・法律・政令・省令・通達 等)の解説。e-Gov の法令種別コード( |
| 法令名の規則で施行令・施行規則(施行令からは親の法律)を引き、e-Gov に実在するものだけを |
| 本則の条の本文が引用している他法令の条( |
| 引用のリストをまとめて実在確認し、件ごとに |
| 法令に付いた添付ファイル(別表・様式・別記の図。jpg / pdf)の一覧。各ファイルに認証なしで開ける URL と、法令の中の置き場所(「別表第一(第一条関係)」など。附則の別表・様式は v0.18.0 から)を付ける(v0.15.0) |
| 添付ファイル 1 件(または zip)。既定は URL とメタ情報だけ、 |
| 法令本文を xml / json / html / rtf / docx のファイルで。既定は URL だけ、 |
search_fulltext は、2 文字の語(「相殺」「時効」)を渡されたときに何をして結果を出したかを short_tokens で返します(v0.12.0)。索引が trigram で 3 文字以上の語しか載せないため、既定では条の本文を引かず、法令名を添える形と scan_body: true で走査する形を next_actions で示します。詳しくは2 文字の語の検索をご覧ください。
get_toc は、本則を toc、附則を改正法ごとに suppl_provisions へ分けて返します(v0.13.0)。既定では附則は見出しと条数だけで、suppl: "full" で附則の中の条まで返します。詳しくは本則と附則の分け方をご覧ください。
list_attachments / get_attachment / get_law_file は、条文の文字列に入らないもの(別表・様式の図、Word や HTML の本文ファイル)を取る道です(v0.15.0)。ファイルの中身は応答に入れず、認証なしで開ける URL と、save: true のときだけ保存先の絶対パスを返します。詳しくは添付ファイルと法令本文ファイルをご覧ください。
get_law_range は、get_law(1 条ずつ)と get_toc(目次だけ)の間を埋めます(v0.14.0)。民法の「第三編第二章 契約」のように章・節を指定すると、その中の条を本文ごと返し、長い範囲は条の単位で打ち切って続きの条番号を返します。詳しくは章・節単位の取得をご覧ください。
略称辞書(174 エントリ・6 分野)は @shuji-bonji/houki-abbreviations を内部で利用しています。
施行令・施行規則と条文内の参照(v0.10.0)
get_related_laws と get_article_references は、法令名の文字列規則と条文本文の正規表現で 決定論的に引ける参照だけ を返します。同じ入力には同じ出力になり、LLM の判断は挟みません。
get_related_laws({ law_name: "所得税法" })→related[]に所得税法施行令(340CO0000000096)と所得税法施行規則(340M50000040011)。名前の末尾に「施行令」「施行規則」を付けた候補を e-Gov に問い合わせ、law_titleが完全一致した 1 件だけを採用します。無かった候補はnot_found[]に残しますget_article_references({ law_name: "所得税法", article: "57の2", paragraph: 2 })→references[]に「雇用保険法(昭和四十九年法律第百十六号)第十条第五項第一号」がlaw_idと条・項・号付きで入り、delegations[]に「政令で定める」×N と委任先(所得税法施行令)が入ります。「前項」「同法」はkind: "relative"で解決しません確かでないときは推定しません(v0.18.0)。
get_article_referencesは本則の条だけを対象にし、本文の「附則第N条」はkind: "suppl"・resolved: falseで返します。省令・府令の委任先は、施行規則を定めた命令の名前(法令番号の大蔵省令など。省の改称は同じ省として扱います)が委任の文言と合うときだけ付け、合わないときと主務省令はtarget_law: nullにします。施行規則の本文の「令第N条」は、兄弟の施行令が実在すればexternalに解決します。get_related_lawsは、法律でも施行令・施行規則でもない法令(省令・政令・規則など)からは候補を作らず、relatedを空にしてnoteに理由を書きますどちらの応答にも
note/coverage.noteが付き、抽出できた範囲だけを返していること、網羅性を保証しないことを書いています。委任の趣旨の解釈や意味的に近い条の推薦は行いません(houki-hub#8 の法令グラフの担当)
インストール
Claude Desktop で使う
上の「まず試す」の claude_desktop_config.json の例をそのまま使います。ローカル DB は無くても動きます。
Claude Code plugin で使う
リポジトリ同梱の .claude-plugin/plugin.json が MCP server として npx -y @shuji-bonji/houki-egov-mcp@latest を登録します。plugin として入れた場合も、下の「Claude Desktop で使う」も、起動されるのは npm に公開された同じパッケージです。
ローカル開発
git clone git@github.com:shuji-bonji/houki-egov-mcp.git
cd houki-egov-mcp
npm install
npm run build
npm test// 開発中の動作確認 (.mcp.json)
{
"mcpServers": {
"houki-egov-local": {
"command": "node",
"args": ["/absolute/path/to/houki-egov-mcp/dist/index.js"]
}
}
}手元のビルドも、HOUKI_EGOV_DB_PATH が無ければ plugin と同じ ~/.cache/houki-egov-mcp/laws.db を開きます。古いコミットや DB の版を上げる変更を試すときは、別のファイルに向けてください(CONTRIBUTING.md の「ローカル DB を使う開発」)。
使用例
# LLM への問いかけ → MCP ツール呼び出し
「消費税法30条1項を見せて」
→ get_law(law_name="消法", article="30", paragraph=1)
「消費税法第三十条第一項を見せて」(判決文や通達からの引き写し)
→ get_law(law_name="消法", article="第三十条", paragraph=1) # 漢数字は v0.7.0 から。項は数値で
「消費税法2条1項8号の2(特定資産の譲渡等)を見せて」
→ get_law(law_name="消法", article="2", paragraph=1, item="8の2")
「労働基準法の目次を取得」
→ get_toc(law_name="労基法")
「民法の契約の章をまとめて読みたい」
→ get_law_range(law_name="民法", part=3, chapter=2)
→ 第三編 債権 第二章 契約(198 条)を上限(既定 30,000 文字)まで返し、続きは from_article で取る
「会社法の設立の章を見せて」
→ get_law_range(law_name="会社法", path="Part2/Chapter1") # get_toc の toc[].path をそのまま渡せる
「個人情報保護法の改正履歴を最新5件」
→ get_law_revisions(law_name="個情法", latest=5)
「電帳法って正式名称なに?」
→ resolve_abbreviation(abbr="電帳法")
→ 電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律
「政令と省令の違いは?」
→ explain_law_type(name="政令")
「民法で不法行為について定めている条文は?」(bulk DB 構築後)
→ search_fulltext(keyword="民法 不法行為")
→ law_scope=[民法] に絞って本文検索。724 条・719 条・509 条 などが snippet 付きで返る
「民法 第709条」(法令名 + 条番号だけ)
→ search_fulltext(keyword="民法 第709条")
→ 本文検索をせず、民法 709 条を直接返すCLI(ローカル DB の構築 — v0.3.1+)
ローカル DB が要るのは search_fulltext だけです。それ以外の 13 ツールは DB が無くても動くので、条文本文の横断検索が要ると分かってから作れば足ります(上の「まず試す」)。
全文検索用のローカル DB(SQLite FTS5)は、e-Gov の bulk ダウンロード zip から構築します。MCP server として常駐する通常起動とは別に、フラグ付きで起動すると CLI モードで動作します。
# 全法令 zip (約 290 MB) を DL して DB に取り込む (初回)
npx -y @shuji-bonji/houki-egov-mcp@latest --bulk-download-everything
# 最終同期日から今日までの日次差分を取り込む (2 回目以降。v0.8.0+)
npx -y @shuji-bonji/houki-egov-mcp@latest --sync
# DB の件数と鮮度 (freshness) を表示
npx -y @shuji-bonji/houki-egov-mcp@latest --statusコマンドは、どのフォルダーからでも動く npx -y @shuji-bonji/houki-egov-mcp@latest <フラグ> の形で書いています。
npm install -g @shuji-bonji/houki-egov-mcpでグローバルにインストールしたときは、houki-egov-mcp <フラグ>でも動きます。インストールしていないとcommand not foundになりますnpx houki-egov-mcp <フラグ>は、npm にhouki-egov-mcpという名前のパッケージが無いので 404 になります(このリポジトリのフォルダーの中でだけ動きます)@latestを付けると、npx が以前に取得した古い版を使わずに、公開中の最新版で実行します。plugin と同じ版で DB を作り、更新するために付けています(0.18.x 以前の版で版 3 の DB を開くと全テーブルが消えるので、古い版を使わないことが大切です)
search_fulltext の応答(next_actions と note)と CLI の出力で案内するコマンドも、この npx -y @shuji-bonji/houki-egov-mcp@latest <フラグ> の形です(0.20.0 から)。HOUKI_EGOV_DB_PATH か XDG_CACHE_HOME で DB の場所を決めて起動・実行したときは、同じ変数を前に付けた形(例: HOUKI_EGOV_DB_PATH="$HOME/.cache/houki-egov-mcp/laws.dev.db" npx -y @shuji-bonji/houki-egov-mcp@latest --bulk-download-everything)になるので、そのまま実行すれば同じ DB を作り、更新します。--help の使い方だけは houki-egov-mcp <フラグ> の形で書いています。
--sync は、差分が無い日(土日など)を飛ばし、途中で失敗しても成功した日までを記録して終わります。最終同期から 90 日(HOUKI_EGOV_INCREMENTAL_LIMIT_DAYS)を超えて空いているときは、e-Gov の日次差分の公開範囲を超えるので、何もせずに --bulk-download-everything を促します。1 日分は数百 KB〜30 MB、13 日分でおよそ 1〜2 分です。
DB は既定で ~/.cache/houki-egov-mcp/laws.db に作られます。場所を変えるときは、下の「DB の場所を変える(HOUKI_EGOV_DB_PATH)」を見てください。
--status は、1 行目に版、2 行目に DB:(開く DB のファイル)、3 行目に DB の場所の設定:(HOUKI_EGOV_DB_PATH・XDG_CACHE_HOME・既定 のどれでその場所に決まったか)を出します(3 行目は 0.20.0 から)。同じフォルダーに、名前が laws で始まり .db で終わるファイルがほかにあるときは、その次の行の [WARN] 同じフォルダーに、この DB のほかに laws*.db のファイルがあります: … で、名前・大きさ・最終更新を挙げます。MCP サーバーと CLI が別のファイルを開いていないかを確かめるための行で、終了コードは変わりません。
MCP サーバー(plugin を含む)が開くファイルは、起動時のログ(標準エラー出力)の [server] DB: <絶対パス>(DB の場所の設定: <名前>) の行と、search_fulltext の応答の freshness.db_path(ホームディレクトリの部分は ~)で確かめられます(0.20.0 から)。起動時のログは、MCP クライアントが保存する MCP サーバーのログに出ます。
--bulk-download-by-date YYYYMMDD は 1 日分の差分だけを取り込む確認用のコマンドです。同期の状態(last_sync_date)は変えないので、最新化には --sync を使ってください。差分の無い日を指定したときは 差分なし を出して終了コード 0 で終わります。
引数を打ち間違えたとき(houki-egov-mcp status のような - の無い引数、--sync --status のようにフラグの後に続く引数)は、何もせずにエラーと使い方を出して終了コード 2 で終わります(0.19.0 から。それまでは MCP サーバーとして起動するか、最初のフラグだけを実行していました)。
日々の更新と作り直し
ふだんの更新は --sync だけで足ります。--bulk-download-everything を使うのは、表の 2〜5 行目の 4 つのときです。
場面 | 使うコマンド | すること |
ふだんの更新(毎日・毎週など) |
| 最後に同期した日から今日までの日次差分を取り込みます。差分の無い日は |
初めて DB を作るとき |
| 全件の zip(約 290 MB)を取得して DB を作ります |
最後の同期から 90 日( |
|
|
houki-egov-mcp を上げて DB の版が変わったとき(0.19.0 で版 2 → 3) |
| 版の古い DB を作り直して取り込みます(取り込んだ中身は消えます) |
|
| 施行日を過ぎても未施行のまま残った版の状態を直します(条の本文は入れ直しません) |
版が同じ DB に --bulk-download-everything を実行しても、作り直しはしません。全件の zip を取り直して、中身の変わった法令と、施行されて状態が変わった版だけを書き換えます。ふだんの更新に使う必要はありません。
0.19.0 で 2026-10-04 以降に --sync した DB は、0.19.1 で 1 回取り込み直してください
e-Gov は、改正の施行日の当日の差分に、それまで未施行として配っていた版を同じ中身のまま「施行済み」としてもう一度入れます。0.19.0 はこの版を「中身が同じ」として飛ばしていたので、施行日を過ぎても版が未施行のまま残り、search_fulltext が改正前の条文を返し続けることがありました(#107)。0.19.1 は、中身が同じでも状態だけを書き換えます。
0.19.0 で 2026-10-04 以降に --sync した DB は、0.19.1 に上げた後に次のコマンドを 1 回実行してください。施行日を過ぎても未施行のまま残った版の状態を直します(条の本文は入れ直しません。全件の zip 約 290 MB を取得します)。0.19.1 の --sync や --status が [WARN] 施行日が last_sync_date … を出したときも同じです。
npx -y @shuji-bonji/houki-egov-mcp@latest --bulk-download-everything取り込みで状態だけを書き換えた版があると、
ingest 完了: …の行の後に状態の更新: <件数> 件 (…)の行が出ますこのコマンドが要る DB の正確な範囲(
--syncだけで直る場合)は docs/NOTES.md の「施行日の当日に配り直される版(0.19.1)」にあります
0.19.0 に上げたら DB を作り直してください
0.19.0 で DB のスキーマの版を 2 から 3 に上げました。0.18.x 以前に作った DB は 0.19.0 では使えないので、次のコマンドで作り直してください。全件の zip(約 290 MB)を取得し直し、取り込み直します。
npx -y @shuji-bonji/houki-egov-mcp@0.19.0 --bulk-download-everything作り直すまで、
search_fulltextは条文本文を検索せずにsearch_law(法令名のタイトル一致)の結果を返し、noteで作り直しを案内します。--sync・--status・--bulk-download-by-dateは DB に触れずにエラー(終了コード 1)で終わります作り直すのは、zip の取得に成功した後です。取得に失敗したときは古い DB がそのまま残ります
作り直した後に 0.18.x 以前の houki-egov-mcp でこの DB を開くと、版が違うため全テーブルが消えます(0.18.x 以前の動きで、0.19.0 からは直せません)。0.19.0 で作り直した後は 0.18.x に戻さないでください。plugin などで版を固定している場合は、CLI と同じ版にそろえてください
0.18.x の plugin を使い続けたまま 0.19.0 を試すときは、0.19.0 の側だけ
HOUKI_EGOV_DB_PATHで別のファイルを指定してください(下の「DB の場所を変える」)。2 つの版が別々の DB を使うので、どちらの DB も消えません
環境変数
環境変数 | 内容 | 既定 |
| DB ファイルのパス(フォルダーではなく、ファイル名まで書く)。CLI と MCP サーバーの両方に同じ値を設定します(下の「DB の場所を変える」) |
|
| 一括ダウンロードの zip の取得に失敗したときに試す回数 | 3 |
|
| 90 |
| e-Gov 法令 API への同時リクエスト数の上限 | 4 |
|
|
|
数値の 3 つ(HOUKI_EGOV_BULK_RETRY・HOUKI_EGOV_INCREMENTAL_LIMIT_DAYS・HOUKI_EGOV_CONCURRENCY)は 1 以上の整数で指定します。0・負の数・小数・数字以外を指定すると、CLI(取り込み・同期・状態の表示)は何もせずに終了コード 2 で終わり、MCP サーバーは警告を出して既定値で起動します(0.19.0 から。それまでは 0 や数字以外は黙って既定値になり、負の数はそのまま使っていました)。
DB の場所を変える(HOUKI_EGOV_DB_PATH)
DB の場所は、次の順で決まります。
環境変数
HOUKI_EGOV_DB_PATHがあれば、その値のファイル無ければ、環境変数
XDG_CACHE_HOMEの下のhouki-egov-mcp/laws.dbどちらも無ければ、
~/.cache/houki-egov-mcp/laws.db
起動のしかたによって、環境変数が渡るかどうかが違います。どのファイルを開くかは次のとおりです。
起動のしかた | 環境変数 | 開く DB |
Claude Code plugin( | plugin は |
|
MCP の設定ファイル( | 設定の |
|
ターミナルの CLI( | そのシェルの環境変数 |
|
環境変数を付けずに CLI を実行すると、plugin が使う laws.db を作り、更新します。 plugin で使う DB は、環境変数を付けずに CLI で作り、--sync で更新してください。逆に、plugin と別の DB を試したいときは、CLI にだけ HOUKI_EGOV_DB_PATH を付けます。そのときに作った DB を plugin は読みません。シェルの設定(~/.zshrc など)で HOUKI_EGOV_DB_PATH を export しているときは、plugin と同じ DB を扱う CLI の前に env -u HOUKI_EGOV_DB_PATH を付けます(例: env -u HOUKI_EGOV_DB_PATH npx -y @shuji-bonji/houki-egov-mcp@latest --sync)。
HOUKI_EGOV_DB_PATH を使うのは、DB を別のディスクに置きたいとき、版の違う houki-egov-mcp を並べて使うとき(0.18.x の plugin と 0.19.0 など)、試しに別の DB を作りたいときです。設定するときは、次の 3 点に気を付けてください。
CLI と MCP サーバーの両方に、同じ値を設定します。 DB を作る CLI(
--bulk-download-everythingなど)と、DB を読む MCP サーバー(search_fulltext)は別々に起動するので、片方だけに設定すると、CLI が作った DB を MCP サーバーが見つけられません(search_fulltextがローカル DB (<パス>) が無いためかHOUKI_EGOV_DB_PATH が指すファイル (<パス>) が無いためでsearch_lawに切り替わります)フォルダーではなく、ファイル名まで書きます。 例:
/Users/you/data/houki-egov/laws.db。途中のフォルダーが無ければ、--bulk-download-everythingが作りますMCP の設定ファイル(JSON)では、
~を使わずに絶対パスで書きます。 JSON のenvの値はシェルを通らないので、~/…は展開されません。ターミナルでexportするときは~が使えます
CLI での指定(ターミナル):
export HOUKI_EGOV_DB_PATH=~/data/houki-egov/laws.db
npx -y @shuji-bonji/houki-egov-mcp@latest --bulk-download-everything
npx -y @shuji-bonji/houki-egov-mcp@latest --status # 2 行目の「DB:」に使っている場所、3 行目に DB の場所の設定が出ますMCP サーバーでの指定(claude_desktop_config.json や .mcp.json):
{
"mcpServers": {
"houki-egov": {
"command": "npx",
"args": ["-y", "@shuji-bonji/houki-egov-mcp@latest"],
"env": {
"HOUKI_EGOV_DB_PATH": "/Users/you/data/houki-egov/laws.db"
}
}
}
}設定を変えたら、MCP クライアント(Claude Desktop など)を起動し直してください。MCP サーバーが使っている場所は、起動時のログの [server] DB: … の行か、search_fulltext の応答の freshness.db_path で確かめられます。CLI では、同じ値を付けて --status を実行し、2 行目の DB:、3 行目の DB の場所の設定:、laws: の件数で確かめてください。
search_fulltext が api-fallback になるとき
ローカル DB を作ったはずなのに search_fulltext が source: "api-fallback" を返すときは、note の先頭で原因を見分けます。
| 考えられる原因 | 確かめ方・直し方 |
|
|
|
| MCP サーバーの |
|
| ファイルはあるが、法令が取り込まれていない(0 バイトのファイル、取り込みを途中で止めた DB、houki-egov-mcp で作っていない SQLite のファイル) |
|
| 開いた DB が、前の版の houki-egov-mcp で作ったもの |
|
| 開いた DB が、新しい版の houki-egov-mcp で作ったもの(plugin の版が CLI より古い、など) | plugin と CLI の版をそろえます |
| DB の版の記録が、整数でない値になっている |
|
| パスがフォルダーを指している、途中が普通のファイル、権限が無い |
|
<パス> は MCP サーバーが開こうとしたファイルで、ホームディレクトリの部分を ~ にして書きます(0.20.0 から。0.19.x までは bulk DL 未実行のため などの文で、開こうとしたファイルが分かりませんでした)。CLI の側は、MCP サーバーと同じ環境変数で --status を実行し、2 行目の DB: と 3 行目の DB の場所の設定: で、開くファイルとその場所に決まった理由を確かめます。plugin なら HOUKI_EGOV_DB_PATH を付けずに実行します(上の env -u)。同じフォルダーに別の laws*.db が残っていれば、--status が [WARN] の行で挙げます。
別のファイルで作った DB を laws.db に移す
HOUKI_EGOV_DB_PATH で別のファイル(例: laws.v3.db)に作った DB は、名前を laws.db に変えれば、取り込み直さずに plugin から使えます。
その DB を開いている MCP サーバーを止めます(Claude Desktop などを終了し、
--syncなどの CLI も動いていないことを確かめます)WAL の中身を DB ファイルに書き戻します:
sqlite3 ~/.cache/houki-egov-mcp/laws.v3.db 'PRAGMA wal_checkpoint(TRUNCATE);'今の
laws.dbを退避します:mv ~/.cache/houki-egov-mcp/laws.db ~/.cache/houki-egov-mcp/laws.v2.bak.db(laws.db-wal・laws.db-shmがあれば、同じように名前を変えるか消します)名前を変えます:
mv ~/.cache/houki-egov-mcp/laws.v3.db ~/.cache/houki-egov-mcp/laws.db(2 で空になったlaws.v3.db-wal・laws.v3.db-shmは、laws.dbの名前に付け替えずに消すか別の名前にします)環境変数を付けずに
npx -y @shuji-bonji/houki-egov-mcp@latest --statusを実行し、DB:がlaws.dbでlaws:の件数が入っていることを確かめますHOUKI_EGOV_DB_PATHで古いファイル名を指している設定(MCP の設定ファイルのenv、シェルのexport)があれば、消すかlaws.dbに直します。古い名前を指したままのサーバーは、ファイルが無いのでHOUKI_EGOV_DB_PATH が指すファイル (…) が無いためを返します
退避した古い DB は、確かめた後に消してかまいません。
SQLite と DB の置き場所(npx / plugin 経由で使う場合)
SQLite は本パッケージが依存する better-sqlite3 に同梱されています(SQLite 3.53 系の amalgamation。OS の sqlite3 は使いません)。npx や plugin で初めて起動したときに npm が better-sqlite3 を取り込み、実行中の Node.js と OS に合ったビルド済みバイナリ(prebuild-install)を GitHub Releases から取得します。対応する prebuilt がない Node.js の場合は node-gyp でその場でコンパイルするため、Python と C++ ビルドツール(macOS なら Xcode Command Line Tools)が必要になります。Node 22 / 24 の LTS では prebuilt が用意されているので、通常はコンパイルは走りません。
DB ファイルはパッケージの中ではなく、上記のユーザーのキャッシュディレクトリに置かれます。したがって次の 3 つは 同じ 1 つの DB を読み書きします。
起動方法 | 実行されるコード | 読む DB |
| npx のキャッシュ内のパッケージ |
|
Claude Desktop / Claude Code plugin( | 同上( | 同上 |
ローカル開発( | リポジトリの | 同上。古いコミットや DB の版を上げる変更を試すときは、 |
どれも環境変数が無いときの場所です。HOUKI_EGOV_DB_PATH を設定した起動だけが別のファイルを開きます(上の「DB の場所を変える」)。
このため、DB の構築は一度 CLI で行えば、plugin 経由の search_fulltext からもそのまま使えます。--bulk-download-everything のあとに MCP server を再起動する必要はありません(search_fulltext は呼び出しごとに DB を開いて閉じます)。書き込みは CLI だけが行い、MCP server は読むだけです(journal は WAL なので、取り込み中に検索しても壊れません)。DB を作るのは --bulk-download-everything だけで、search_fulltext と --status は DB が無くてもファイルやフォルダーを作りません(0.19.0 から)。
DB が存在しない、または条が 1 件も入っていないときは、search_fulltext は source: "api-fallback" で search_law の結果を返し、next_actions に --bulk-download-everything の実行を案内します。パッケージを更新しても DB は消えません。版が古い DB は --bulk-download-everything を実行したときだけ作り直します。新しい版の DB は触りません。
DB の版(DB に記録したスキーマの版)ごとの扱いは次のとおりです(0.19.0 から)。
DB の状態 |
|
|
|
|
ファイルが無い | 作って取り込む | 作らない。全件の取り込みを促して終了コード 1 | 作らない。DB が無いことを出して終了コード 0 | 作らない。 |
版が同じ(3) | 取り込む | 取り込む | 表示する | 検索する |
版が古い(1・2) | 取得に成功してから作り直して取り込む | 書き込まずに終了コード 1 | 書き込まずに終了コード 1 | 使わずに |
版が新しい・版を読めない | 取得せずに終了コード 1 | 書き込まずに終了コード 1 | 書き込まずに終了コード 1 | 使わずに |
全データを消すコマンドはありません。中身を消したいときは DB のファイルを消してください(場所は --status の DB: の行に出ます)。
DB を構築すると search_fulltext が条文本文を SQLite FTS5 で検索します(v0.5.0〜)。略称は正式名称にも展開され(労基法 → 労基法 または 労働基準法)、通称(インボイス など)は元の語で条が当たらないときだけ正式名称で探し直します(v0.18.0)。「民法 不法行為」「労基法 時間外」のように法令名と語を並べるとその法令の条に絞って本文を検索します。各ヒットに条番号・snippet・score・DB の鮮度(freshness)が付きます。DB が未構築のときは従来どおり search_law(法令名のタイトル一致)にフォールバックし、note でその旨を返します。
v0.5.0 以前に構築した DB について: v0.5.0 で本文の正規化を投入時に行うようになり(スキーマバージョン 2)、v0.5.1 で編(Part)を持つ法令の本則が取り込まれていなかった不具合を直しました。0.19.0 からはスキーマの版 3 の DB だけを使うので、どの版で作った DB も
--bulk-download-everythingで作り直してください。検索語の制約: 索引が trigram のため、条文本文は 3 文字以上の語で索引から引きます。2 文字の語(「相殺」「時効」等)の扱いは v0.12.0 で変わりました(下記)。「第30条」のような条番号は本文検索には使わず、該当条を上位に寄せる加点にだけ使います(漢数字は未対応)。
添付ファイルと法令本文ファイル(v0.15.0)
法令には、条文の文字列に入らないものが付いています。別表・様式・別記の図(e-Gov では jpg か pdf)と、法令全体を 1 つのファイルにした本文(xml / json / html / rtf / docx)です。get_law の Markdown には図の中身は入らず、様式の図が要る作業(届書の書式、旗の寸法図)は条文だけでは済みません。v0.15.0 の 3 ツールはそのための道です。
「戸籍法施行規則の出生届の様式を見たい」
→ list_attachments(law_name="戸籍法施行規則")
attachments[] の location.title が「附録第十一号様式」の 1 件(pdf)の url を得る
→ pdf-reader-mcp の read_url(url=…) # URL は認証なしで開ける
(またはディスクに置くなら)
→ get_attachment(law_name="戸籍法施行規則", src="./pict/2FH00000076885.pdf", save=true)
→ saved.path を pdf-reader-mcp の read_text に渡す
「民法の全文を Word で」
→ get_law_file(law_name="民法", file_type="docx", save=true)
→ saved.path(182 KB)。saved.law_revision_id にどの履歴の本文かが入る中身は返しません。バイナリを base64 にして応答に入れることはせず、URL(
https://laws.e-gov.go.jp/api/2/attachment/<law_revision_id>?src=…、…/law_file/<file_type>/<law_id>)を返します。URL は認証なしで開けるので、pdf-reader-mcp のread_urlや、利用者のブラウザーにそのまま渡せます保存先はサーバー側で決めます。
save: trueのときだけファイルを取得し、${XDG_CACHE_HOME:-~/.cache}/houki-egov-mcp/files/<law_revision_id>/<ファイル名>に書いてsaved.pathを返します。保存先は環境変数HOUKI_EGOV_FILES_DIRで変えられますが、ツールの引数にはありません(LLM が渡した文字列をパスに使わないため)。1 ファイル 50 MB を超えるときは保存せずFILE_TOO_LARGEを返します。e-Gov の応答の Content-Length で分かるときは本文を読みません(v0.16.0)置き場所を付けます。
list_attachmentsは e-Gov のattached_files_info(src と更新日時)と本文のFig要素をsrcで突き合わせ、各ファイルにlocation(別表・様式の見出しと関係条文、条の中なら条番号、附則の中なら改正法番号)を付けます。一覧にだけあって本文に無いファイルはlocation: nullです添付ファイルは法令履歴ごとに付くので、
atで時点を変えると一覧も変わります。添付が無い法令はlist_attachmentsではcount: 0の成功応答、get_attachmentではATTACHMENT_NOT_FOUNDですget_law_fileのxml/jsonは法令全体(民法で 1.6 MB)なので、条文を読むだけならget_law/get_law_rangeを使ってください。docx/html/rtfは人が開く版です
章・節単位の取得(v0.14.0)
get_law_range は、編・章・節・款・目のいずれか、または附則 1 本を範囲にして、その中の条を本文ごと返します。get_law で 1 条ずつ引くと手数がかかり、法令全体を返すには長すぎる法令(民法・会社法・消費税法)のためのツールです。
範囲の指定は次の 3 通りで、同時に指定できるのは 1 つだけです。
指定 | 書き方 |
編・章・節・款・目の番号 |
|
範囲のパス |
|
附則 |
|
章番号は編ごとに振り直されます(民法には第一章が 5 つ、第一節が 19 あります)。chapter だけを指定して複数の範囲に当たったときは、候補のパスを hint と next_actions に入れた INVALID_ARGUMENT を返します。
大きい範囲は max_chars(既定 30,000 文字)で条の単位で打ち切ります。条の途中では切らないため、1 条目だけは上限を超えても返します。2026-09-20 に測った条本文のサイズは次のとおりです(UTF-8 の日本語は 1 文字 3 バイト)。
法令 | 章の条本文(中央値 / 最大) | 既定の上限での回数 |
民法 | 6.2 KB / 98.2 KB | ほとんどの章は 1 回。第三編第一章(183 条)は 2 回 |
会社法 | 17.9 KB / 207.6 KB | 大きい章は 2〜3 回 |
所得税法 | 10.8 KB / 229.1 KB | 大きい章は 2〜3 回 |
消費税法 | 59.5 KB / 102.4 KB | 章は 2〜4 回(編が無く章が大きい) |
打ち切ったときの応答の range は次の形です。
{
"path": "Part3/Chapter2",
"titles": ["第三編 債権", "第二章 契約"],
"tag": "Chapter",
"article_count": 198, // 範囲が持つ条の数
"returned_count": 186, // 本文を返した条の数
"skipped_count": 0, // from_article より前で返さなかった条の数
"first_article": "第521条",
"last_article": "第684条",
"truncated": true,
"body_chars": 29911,
"max_chars": 30000,
"next_from_article": "685",
"note": "範囲の条 198 件のうち 186 件を返しました(第521条〜第684条)。本文 29,911 文字(上限 30,000 文字)。上限で打ち切りました。続きは from_article: \"685\" を付けて同じ範囲を呼び直してください。"
}from_article に next_from_article の値を渡すと、同じ範囲の続きから返します。条を立てず項だけで書かれた附則(「1 この法律は、公布の日から施行する。」の形)は、範囲の本文をそのまま返します。
削除された条は、e-Gov の法令データでは複数の条をまとめた範囲表記になっています(民法第534条は Article Num="534:535"、見出しは「第五百三十四条及び第五百三十五条」、本文は「削除」)。応答ではこれを 第534条及び第535条(3 条以上なら 第170条から第174条まで)と表示し、next_from_article にも "534:535" の形を返すので、そのまま from_article に渡せます(v0.14.1)。なお get_law に article: "534" を渡してこの条を引くことは、まだできません。
本則と附則の分け方(v0.13.0)
附則は改正法ごとに 1 本ずつ積み上がります(所得税法は 352 本・条 983 件)。v0.12.1 までの get_toc は、この附則の条を本則の章の後ろにそのまま並べていたため、いま効いている規定と、ある改正法の施行日・経過措置の区別が目次から付きませんでした。
v0.13.0 からは、本則を toc、附則を suppl_provisions に分けて返します。附則 1 本は次の形です。
{
"index": 2, // LawBody の中での並び順。ローカル DB の Suppl2_1 と同じ番号
"label": "附則",
"amend_law_num": "平成元年六月二八日法律第三九号", // どの改正法の附則か。制定時の附則には付かない
"extract": true, // 抄(改正法の附則のうち一部だけを載せた形)
"article_count": 1,
"paragraph_only": false, // 条を立てず項だけで書かれた附則か
"children": [] // suppl: "full" のときだけ中の目次が入る
}suppl で附則をどこまで返すかを選びます。
| 返すもの | 所得税法の Markdown |
| 改正法ごとの見出しと条数だけ | 752 行 / 54.5 KB |
| 附則の中の条まで | 1,735 行 / 114.4 KB |
| 附則を返さない(本数と条数は | 395 行 / 24.6 KB |
既定を "list" にしているのは、附則の条が目次の大半を占めるためです(所得税法は本則 388 ノードに対し附則の条 983 件)。何を返したかは suppl.note に書きます。
with_amend_titles: true を付けると、改正法の題名も付けます。附則の属性には法令番号しか無いため、改正履歴(get_law_revisions と同じ e-Gov の応答)を 1 回引き、法令番号で照合します。2 つの表記は違うので(附則は 令和七年六月二〇日法律第七四号、改正履歴は 令和七年法律第七十四号)、公布の月日と漢数字の書き方を落とした「元号 + 年 + 種別 + 号数」で突き合わせます。e-Gov の改正履歴は近年の改正が中心なので、それより古い改正法には題名が付きません(消費税法は附則 167 本のうち 28 本に付き、改正履歴は 65 件)。付いた本数と付かなかった本数は suppl.amend_law_titles に入ります。
get_law の format: "toc" でも本則と附則を分け、附則は見出しだけを返します。
2 文字の語の検索(v0.12.0)
「相殺」「時効」「善意」のような 2 文字の法律用語は、条本文の索引 articles_fts(trigram)に載りません。v0.12.0 からは、そのときに何をして結果を出したかを応答の short_tokens で返します。
クエリ |
| 何をするか |
|
| 3 文字以上の語で索引を引き、その条の本文に 2 文字語が含まれるかで絞る |
|
| 法令名で対象法令を絞り、その範囲の条の本文を引く |
|
| 条の本文は引かず、法令名・略称・番号の照合だけを返す(既定) |
|
| 索引を使わず、全法令の条の本文を端から照合する |
short_tokens.hits_by_match_type に article(条本文由来)と law_meta(法令名・略称・番号由来)の件数が入ります。v0.11.0 までは「相殺」で「相殺関税に関する政令」だけが返り、条の本文が引かれなかったことが応答から分かりませんでした。
既定で not_searched にしているのは、全法令の走査に時間がかかるためです。2026-09-20 に実データ(条 1,434,710 件・本文 587,926,852 バイト)で測ったところ、ヒットが多く上限 150 件で打ち切れる語で 5.4 秒、該当が少なく全表を走り切る語で 22 秒かかりました。LIKE を instr や GLOB に変えても、JOIN を外しても同じ時間です。588 MB を読んで照合する分そのものなので、書き方では縮みません。
そのため not_searched の next_actions は 2 つの道を示します。
「
<法令名> 相殺」の形(例:民法 相殺)— 法令名を添えると、その法令の条に絞って索引で引けます(速く、並び順も関連度順)。語から法令名は決まらないので、この案内にはexampleを付けず、reasonに形を書きます(v0.18.0){ keyword: "相殺", scan_body: true }— 法令名が分からないときの最後の手段です。5〜20 秒かかり、並び順は関連度順になりません。上限(150 件)で打ち切ったときはtruncated: trueになります
3 文字以上の語を含むクエリでは索引を引くので、scan_body は効きません。
引用の実在確認(v0.11.0)
verify_citations は、回答に添える引用のリストを送り出す前に、その条(指定があれば項・号)が e-Gov の法令にあるか を 1 回の呼び出しでまとめて確かめます。存在しない引用が混ざっていてもツール全体はエラーにならず、件ごとに判定が返ります。
{
"citations": [
{ "law_name": "所法", "article": "9", "paragraph": 1, "item": 1, "label": "所法9①一" },
{ "law_name": "電子帳簿保存法", "article": "7" },
{ "law_name": "所得税法", "article": "9999" }
]
}上の 3 件は順に
found(条見出し「(非課税所得)」付き)、found(resolved_by: "exact_title"で410AC0000000025)、not_found(code: "ARTICLE_NOT_FOUND")になりますsummaryに件数の内訳とall_foundが入るので、「全部実在した」と書いてよいかを 1 つの値で判断できます法令名が e-Gov の法令名と完全一致しなければ
ambiguousにし、部分一致の候補をcandidates[]に最大 5 件返します(例: 「所得税法施行」→ 所得税法施行令・所得税法施行規則)。項が複数ある条で項を書かずに号だけを指定した件もambiguousです通達など houki-egov の管轄外の引用は
OUT_OF_SCOPEにし、next_actionsでhouki-ntaを指します条は本則の中で確かめます。本則に無く附則にだけある条番号は
ARTICLE_NOT_FOUNDにし、附則の番号を案内します。附則の条はsuppl_index(get_tocのsuppl_provisions[].index)で附則を指して確かめます(v0.18.0)確かめるのは条文が実在するかどうかだけです。引用した条文が主張を支えるかどうかは判定しません
e-Gov に問い合わせられなかったときは、件ごとの判定を返さずツール全体を
SOURCE_*エラーにします。「聞けなかった」を「存在しない」と書かないためです
状態
v0.15.0 (2026-09-20)
e-Gov 法令API v2 クライアント(
searchLaws/getLawData/getLawRevisions/getAttachment/getLawFile)法令ツリー走査(条/項/号、目次抽出)+ LRU cache
14 ツール本実装
略称辞書を
@shuji-bonji/houki-abbreviationsに分離(v0.15.4 から ^0.6.1)法令階層ナレッジ(憲法・法律・政令・省令・規則・条例・告示・訓令・通達・通知 の10種別)
houki-hub family 共通の error contract(
SOURCE_*/OUT_OF_SCOPE)に準拠Phase 2 基盤:bulk DL → SQLite FTS5 の取り込みパイプライン(schema / CSV・XML parser / zip fetcher / ingester / freshness / CLI)
Phase 2-7:
search_fulltextの FTS5 本実装(略称 OR 展開 / revision 重複排除 / relevance scoring / freshness)MCP SDK v2(
@modelcontextprotocol/server)/ Node 22・24 / TypeScript 7 / BiomeTrusted Publisher (OIDC) で publish
get_lawのitemで枝番号の号("8の2"・"第8号の2")を指定(v0.6.0)ツールの引数の型を inputSchema から導き(json-schema-to-ts の
FromSchema)、未知の引数はINVALID_ARGUMENT(v0.6.0)get_lawのarticle/itemで漢数字("第三十条の二"・"八の二")と全角数字を受け付ける(v0.7.0)--syncで最終同期日から今日までの日次差分を取り込む。差分が無い日は飛ばし、途中で失敗しても成功した日までを記録(v0.8.0)get_related_laws/get_article_references: 施行令・施行規則の関連付けと条文内の参照抽出(v0.10.0、Issue #20)verify_citations: 引用リストの実在確認(v0.11.0、Issue #18)search_fulltextの 2 文字語(「相殺」「時効」)の扱いをshort_tokensで明示し、scan_bodyで全走査を選べるようにした(v0.12.0、Issue #23)get_tocで本則と附則を分け、附則を改正法ごとにまとめた(v0.13.0、Issue #24)get_law_range: 編・章・節(または附則 1 本)を範囲にした条文の取得(v0.14.0、Issue #22)list_attachments/get_attachment/get_law_file: 添付ファイル(別表・様式の図)と xml / html / rtf / docx の本文ファイル(v0.15.0、Issue #19)テストスイート(456 tests)
計画中
Phase 2-8: 差分同期(
--sync)— v0.8.0Phase 2-13: API enrichment(
category/ 改正履歴 / 廃止ステータスの精緻化)漢数字対応(「第三十条」を 30 に変換)— v0.7.0 で
get_lawのarticle/itemに対応。search_fulltextのキーワード中の「第三十条」は未対応大規模法令の応答サイズ対策(民法・会社法)— v0.14.0 の
get_law_rangeで章・節単位の取得に対応
houki-hub MCP family
houki-egov-mcp は 単体で利用可能ですが、houki-hub MCP family の一員でもあります。同じ family 内の他 MCP と組み合わせると、通達・判例等まで横断的に扱えます。
パッケージ | 役割 | 状態 |
略称辞書・正規化・freshness 判定(共有ライブラリ) | ✅ v0.5.0 | |
| e-Gov 法令API クライアント + ローカル全文検索(このリポジトリ) | ✅ v0.5.1 |
国税庁通達・Q&A・タックスアンサー・文書回答事例 | ✅ v0.9.5 | |
family を横断する Claude Skill(error contract の正典) | ✅ | |
| 厚労省通達・通知 | 計画中 |
| 判例(裁判所サイト) | 構想中 |
| 国税不服審判所裁決 | 構想中 |
family 全体の設計思想・想定利用シーン・業法との関係は docs/DESIGN.md を参照。
エラー応答 (houki-hub family contract)
v0.3.0 より、本 MCP のエラー応答は houki-hub family 共通契約に完全準拠します。code 文字列は family 全体で統一された語彙を使用するため、複数の MCP を併用しても LLM・Skill 層は一貫したロジックで解釈できます。
docs/ERROR-CODES.md— 共通エラーコード語彙の正典 (houki-research-skill)docs/ERROR-HANDLING.md— 解釈ポリシー / next_actions テンプレ
houki-egov-mcp の src/errors.ts は family 全体の リファレンス実装として位置付けられています。他 MCP は同じ code 語彙を共有しつつ、共通パッケージへの依存は持たずに独立実装します。
{
"error": "法令『消費税法』第3000条は存在しません",
"code": "ARTICLE_NOT_FOUND",
"hint": "条番号を get_toc で確認してください",
"next_actions": [
{ "action": "get_toc", "reason": "目次で正しい条番号を特定", "example": { "law_name": "消費税法" } }
],
"retryable": false
}本 MCP で使用するコード
code | 用途 | retryable |
| 引数が |
|
| 条番号・号番号のフォーマットが不正 (例: "30-2"、位ごとに並べた "三〇") |
|
| 通達名で |
|
| 略称辞書に無く、e-Gov の法令名の検索で題名の完全一致が無かった(0 件、または部分一致だけ。部分一致のときは候補を |
|
| 指定された条/項/号が見つからない( |
|
|
|
|
|
|
|
| e-Gov API がエラー応答(5xx は再試行できる、429 以外の 4xx は再試行できない。 | 状況による |
| e-Gov API がタイムアウト |
|
| e-Gov API がレート制限 (HTTP 429) |
|
| e-Gov に接続できない( |
|
|
|
|
| 内部エラー (バグ・予期せぬ例外)。 |
|
| 存在しない tool 名が呼ばれた |
|
verify_citations の code は件ごとに付きます(v0.11.0)
verify_citations は、存在しない引用が混ざっていてもツール全体を isError にしません。上の表の code は results[] の 1 件ごとに付き、LAW_NOT_FOUND / ARTICLE_NOT_FOUND / INVALID_ARTICLE_NUM / OUT_OF_SCOPE / INVALID_ARGUMENT のいずれかです。法令名が完全一致せず候補が複数あった件は status: "ambiguous" と candidates[] だけを返し、code は付きません。
ツール全体がエラーになるのは、引数の形が壊れているとき(INVALID_ARGUMENT)と、e-Gov が時点 at を受け付けないとき(INVALID_ARGUMENT。at は全件に共通のため。v0.18.0)と、e-Gov に問い合わせられなかったとき(SOURCE_*)と、e-Gov との通信と関係の無い処理中の例外(INTERNAL_ERROR。v0.16.0)だけです。e-Gov に問い合わせられなかったときに件ごとの判定を返さないのは、「聞けなかった」を「存在しない」と書かないためです。
Migration (v0.2.x → v0.3.0)
v0.2.x までは
EGOV_API_ERROR/EGOV_TIMEOUT/EGOV_RATE_LIMITEDを返していました。v0.3.0 からは family 共通のSOURCE_API_ERROR/SOURCE_TIMEOUT/SOURCE_RATE_LIMITEDに切替。EGOV_*は v0.15.x までLawErrorCodeの型に残していましたが、v0.16.0 で型からも外しました(返さないABBREVIATION_NOT_FOUNDも同じ)。構造化エラーの形 (
{ error, code, tool?, hint?, next_actions?, retryable?, detail? }) は不変(toolは v0.16.0 で引数の検査のINVALID_ARGUMENTに足した)。クライアント側でcode文字列の比較をしている場合はSOURCE_*を受け付けるよう更新してください。OUT_OF_SCOPEを新たに受け取る可能性があります。例えば「消基通」(消費税法基本通達 / 国税庁の通達) をget_lawのlaw_nameに渡すと、next_actions[0].example.mcp = "houki-nta"を含むOUT_OF_SCOPEが返されるので、Skill 層は houki-nta-mcp に切り替えてください。
ドキュメント
docs/LAW-HIERARCHY.md— 法令種別の階層リファレンス(専門家でない利用者向け)docs/USE-CASES.md— プロダクト開発の典型ユースケース(電帳法・電子契約・個情法・e-KYC)docs/DESIGN.md— 設計原則・houki-hub family のロードマップ・業法との関係docs/NOTES.md— README の注意書きの詳細(施行日の当日に配り直される版と 0.19.1 の DB の直し方)DISCLAIMER.md— 利用上の注意(業法との関係)CONTRIBUTING.md— 貢献方法CHANGELOG.md— リリースノート
業法との関係
本MCPは 一次情報の取得・提示のみ を担います。分析は LLM、判断は利用者(または有資格者)の責任です。業としての法律事務・税務業務への利用は想定外です — 詳細は DISCLAIMER.md 参照。
デジタル庁公式 MCP との関係
デジタル庁は 2025年12月〜2026年3月の「法令×デジタル」ハッカソンで法令API / MCP のプロトタイプを試行提供した。将来一般公開された場合は、本 MCP のコアを公式 MCP に委譲し、houki-hub family 全体は 公式が手を出さないレイヤ(通達・裁決・判例の横断インデックス、業法対応 Skill 等) に注力する方針。
ライセンス
MIT — 個人利用・学習用途のフォーク・改変・再配布を自由に許可します。
ただし、業としての使用(弁護士法72条・税理士法52条・社労士法27条が定める独占業務) については想定外であり、作者は一切の責任を負いません。DISCLAIMER.md を必ずご確認ください。
Available Tools
7 toolsexplain_law_typeA
法令種別(憲法・法律・政令・省令・規則・条例・告示・通達 等)の制定主体・階層上の位置・国民への拘束力・実務上の注意点を解説する。法務専門家でない利用者が「政令と省令の違い」「通達は守らなくていいのか」等を確認するための知識ツール。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 法令種別の名前。例: "法律", "政令", "省令", "規則", "条例", "告示", "通達", "訓令", "憲法"。aliases も解決可(例: "施行令" → 政令、"施行規則" → 省令、"Act" → 法律) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It accurately describes the tool as an educational/knowledge tool with no side effects. It does not mention read-only status explicitly, but the explanatory nature makes it non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence packs all necessary information (what, aspects, audience) without redundancy. Slightly dense but efficient; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single param, no output schema), the description fully covers its purpose, input, and expected output (explanations). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with a single parameter 'name' and its description. The tool description adds significant value by listing concrete examples (法律, 政令), explaining alias resolution (施行令 → 政令), and confirming the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states verb 'explain' and resource 'law type' (法令種別). It lists specific types (憲法・法律・政令 etc.) and aspects covered (制定主体, 階層上の位置, etc.), clearly distinguishing from siblings that retrieve actual law texts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Target audience (non-legal experts) is specified, and the purpose (confirming differences) is clear. While no explicit when-not-to-use or alternatives are stated, the sibling tools (search_law, get_law, etc.) imply this is for conceptual explanations, not text retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lawC
日本の法令から条文を取得する。略称(消法・所法・労基法 等)対応。条/項/号レベル指定可能。
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | 時点指定。YYYY-MM-DD 形式。例: "2024-04-01" でその時点の条文を取得(e-Gov v2 対応) | |
| item | No | 号番号。省略時は項全体 | |
| format | No | 出力形式。"markdown"=条文全文(デフォルト), "toc"=目次のみ(トークン節約), "json"=構造化 | markdown |
| article | No | 条番号。例: "30", "30の2"。format="toc" の場合は省略可 | |
| law_name | Yes | 法令名または略称。例: "消費税法", "消法", "労基法", "民法" | |
| paragraph | No | 項番号。省略時は条文全体 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits like read-only nature, authentication needs, or any side effects. It does not mention the e-Gov v2 dependency from the parameter description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with no unnecessary words. It is concise but could be better structured with clear separation of key features.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and multiple parameters, the description lacks completeness. It does not explain return formats, date specification, or how the 'toc' format works, leaving critical gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond what the schema already provides, only briefly mentioning abbreviation support and level specification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves articles from Japanese laws and supports abbreviations and level specification. However, it does not distinguish itself from sibling tools like get_toc or search_law.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to alternatives such as search_law or get_toc. The description lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_law_revisionsA
法令の改正履歴を取得する。e-Gov v2 /law_revisions を使用。各改正の公布日・施行日・改正法令番号・状態(現行/旧法/未施行)等を返す。
| Name | Required | Description | Default |
|---|---|---|---|
| latest | No | 最新N件のみ返却(省略時は全件)。例: 5 | |
| law_name | Yes | 法令名または略称。例: "消費税法", "消法", "民法" |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
アノテーションがないため、動作特性の説明は記述に委ねられている。外部API使用と返却フィールドの列挙はあるが、読み取り専用であることやレート制限、副作用については触れられていない。最低限の情報は提供しているが、完全ではない。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
2文で目的と返却内容を効率的に伝えており、冗長な表現がない。フロントローディングも良好。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
パラメータ数2、必須1、出力スキーマなしという状況で、返却フィールドや外部API使用を明記しており、ツールを利用するのに十分な文脈を提供している。ページネーションやエラーハンドリングの欠如はあるが、スコープ内では良くできている。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
スキーマですべてのパラメータに説明があり、カバレッジ100%。記述はパラメータの意味を追加で説明しておらず、ベースラインの3が適切。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
明確に法令の改正履歴を取得する機能を説明し、e-Gov v2 APIを使用すること、返却データの内容(公布日・施行日等)を列挙している。sibling tools(get_law, get_toc)との違いが明確で、特定の動詞+リソースを備えている。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
改正履歴を取得するという使用場面は明示されているが、代替ツール(search_law等)との使い分けや、使用すべきでない状況は明記されていない。代替案への明示的な言及がないため、最高点ではない。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tocA
法令の目次(編・章・節・条の構造)のみを取得する。トークン節約用。depth で階層を浅く打ち切れる(民法・会社法のような大規模法令の概観把握向け)。
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | 時点指定(YYYY-MM-DD) | |
| depth | No | 構造階層の打ち切り深さ。1=編まで、2=章まで、3=節まで。省略時は全階層。例: 民法を depth=1 で取得すると「第一編 総則」「第二編 物権」のような大区分のみが返る | |
| law_name | Yes | 法令名または略称 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It explains that depth truncates hierarchy and that the tool is for token saving, but does not disclose error handling, authentication needs, or rate limits. Acceptable for a simple retrieval tool but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each with clear purpose: first defines core function, second adds depth parameter context and use case. No wasted words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should clarify return format. It mentions 'structure of parts, chapters, sections, articles' but not whether output is nested or flat. Missing details on behavior for invalid law names or depth values. Adequate for a simple tool, but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides 100% coverage with good descriptions. Tool description adds extra context by explaining depth's purpose for overview and token saving, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves only the table of contents structure, explicitly distinguishing from full law retrieval with 'のみ' (only) and token-saving purpose, and mentions depth for overview of large laws, setting it apart from siblings like get_law.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for token-saving and large law overview via depth, but does not explicitly state when to avoid this tool or list alternative tools for full content or search, leaving guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_abbreviationA
略称・通称から正式な法令名と law_id を解決する。略称辞書の内容を確認するための診断ツール。
| Name | Required | Description | Default |
|---|---|---|---|
| abbr | Yes | 略称。例: "消法", "所法", "労基法", "民" |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the core behavior (resolving abbreviation to law name and ID) but lacks details on error handling, multiple results, or the exact response format. It does not contradict any facts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and usage context. Every sentence is meaningful, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, no output schema), the description sufficiently covers functionality. It could mention the output format, but the lack is not critical for this diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description provides examples. The tool description adds no additional semantic information beyond what the schema already provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves official law names and law_ids from abbreviations, and identifies it as a diagnostic tool. This distinguishes it from siblings like search_law or get_law, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly guide when to use this tool vs alternatives. Calling it a 'diagnostic tool' implies it's for checking abbreviation coverage, but no direct 'when-not-to-use' or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_fulltextA
法令本文をキーワードで横断全文検索する。HOUKI_HUB_BULK_CACHE=1 環境時に SQLite FTS5 で動作。未有効時は API フォールバック。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 取得件数(デフォルト: 10、最大: 30) | |
| domain | No | 分野タグで絞り込み | |
| keyword | Yes | 検索キーワード。スペース区切りで AND 検索 | |
| law_type | No | 法令種別で絞り込み |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the cache-dependent behavior (SQLite FTS5 vs API fallback), adding valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loading the main purpose and adding a crucial behavioral note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Moderate complexity with 4 parameters; description lacks output format or return value details, but covers core function and a key environmental behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description does not add new meaning to parameters beyond what schema already provides (keyword, limit, domain, law_type).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs full-text search across legal texts by keyword, which distinguishes it from sibling tools like search_law that likely search by law identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for broad keyword search, but no explicit guidance on when to use versus competitors like search_law, or mention of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_lawA
日本の法令をキーワード・略称・分野で検索する。e-Gov法令API v2 を使用。略称辞書による正式名称への自動補完あり。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 取得件数(デフォルト: 10、最大: 50) | |
| domain | No | 分野タグで絞り込み(略称辞書ベース) | |
| keyword | Yes | 検索キーワード。例: "消費税", "労働基準", "育児休業"。略称も可(例: "消法", "労基法") | |
| law_type | No | 法令種別で絞り込み |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful context such as using the e-Gov API v2 and auto-completion of abbreviations, but it does not disclose safety traits (e.g., read-only nature, auth requirements, rate limits, or side effects). The description partially compensates but lacks full behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three short sentences that are front-loaded with the main purpose, then API source, then auto-completion feature. Every sentence adds unique value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the four parameters (two with enums) and no output schema, the description is fairly complete. It covers search scope, API source, and auto-completion. However, it does not describe the return format (e.g., list of law objects with titles, dates), which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are described in the schema (100% coverage), so the baseline is 3. The description adds value beyond the schema by mentioning auto-completion of abbreviations and the use of the e-Gov API v2, helping agents understand the underlying mechanism and data enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '日本の法令をキーワード・略称・分野で検索する。' (search Japanese laws by keyword, abbreviation, or field). It also specifies the use of the e-Gov law API v2 and auto-completion of abbreviations, making it distinct from siblings like get_law, search_fulltext, and resolve_abbreviation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for keyword, abbreviation, or field searches, but it does not explicitly state when to use this tool versus alternatives like search_fulltext or resolve_abbreviation. No usage exclusions or contextual cues are provided, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
7 tool updates
v0.3.1- First observed
explain_law_type - First observed
get_law - First observed
get_law_revisions - First observed
get_toc - First observed
resolve_abbreviation - First observed
search_fulltext - First observed
search_law
TDQS
Scored across 7 tools
Each tool serves a clear, non-overlapping purpose: searching by keyword, retrieving specific text, getting TOC, full-text search, abbreviation resolution, revision history, and educational explanation. No ambiguity.
All tools use the consistent verb_noun pattern in snake_case (e.g., search_law, get_law, get_toc, search_fulltext, resolve_abbreviation, get_law_revisions, explain_law_type). Perfectly uniform.
Seven tools is well-scoped for a specialized legal information server. Each tool earns its place covering search, retrieval, navigation, history, and education without redundancy.
The tool set covers all core activities: finding laws (search_law, search_fulltext), retrieving content (get_law, get_toc), resolving abbreviations, checking revisions, and understanding law types. No obvious gaps.
Maintenance
Related MCP Connectors
Japan Law MCP — Japanese national laws & ordinances via the e-Gov Law API.
Search Japanese subsidies and public company data using J-Grants, gBizINFO, and EDINET.
Japan data tools for AI agents: calendar (rokuyo), address, name splitting, corporate number lookup
Resolve, search and verify legal citations against the official sources, with provenance.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables searching and retrieving Japanese legal information from the e-Gov Law API, including law searches by keyword, detailed law data retrieval, and revision history tracking.31,779 npm48MIT
- AlicenseAqualityDmaintenanceEnables intelligent search and retrieval of Japanese legal statutes through the e-Gov API. Supports smart lookup of laws and articles with abbreviation recognition, batch processing, and multi-tier caching for high-performance legal research.815MIT
- AlicenseNot gradedqualityBmaintenanceEnables querying Japanese national laws and ordinances via the e-Gov Law API, allowing AI agents to access legal data through natural language questions.404 npmMIT
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to query Japanese public data (laws, corporations, statistics) from official government APIs, returning normalized English metadata with source attribution.1MIT