MCPとは何か。e-Gov法令MCPを例に、作る前に決める設計境界

MCPは、AIエージェントに外部データや外部操作を渡すための接続規格です。単なるプラグイン名ではありません。Claude Code、Claude Desktop、Cursor、ChatGPTなどのAIクライアントが、ファイル、データベース、検索API、業務システム、開発ツールを同じような形で呼び出せるようにするための標準インターフェースです。

この記事では、MCPの基本を、e-Gov法令検索APIにつなぐ「日本法令MCP」を例に整理します。特に、すでに egov-law-mcp というnpmパッケージとGitHubリポジトリが公開されている状況を前提に、後発で作るなら何を変えるべきかまで踏み込みます。

追記: この方針に沿って、@codeagentjp/egov-law-mcp をnpmとGitHubで公開しました。公開作業の実務手順は、@codeagentjp/egov-law-mcp を npm 公開するまで。MCPサーバー配布の実務メモに、Claude Codeでの使い方はClaude Codeで日本法令を引く。@codeagentjp/egov-law-mcp の使い方実演にまとめています。

結論から言うと、いま作るべきものは「同じ名前のe-Govラッパー」ではありません。狙うべきは、出典明示、施行令・施行規則の補完、ローカル全文検索インデックス、改正履歴や更新検知など、法令参照の実務で差が出る部分です。

MCPを一言で言うと

MCPは、AIアプリと外部システムをつなぐ共通の口です。公式ドキュメントでは、AIアプリがローカルファイル、データベース、検索エンジン、計算機、専門プロンプト、ワークフローなどに接続するためのオープン標準として説明されています。

AIクライアントとMCPサーバーの関係は、次のように見ると分かりやすいです。

ユーザー
  ↓
Claude Code / Claude Desktop / Cursor / ChatGPT など
  ↓
MCPクライアント
  ↓
MCPサーバー
  ↓
外部API、DB、ファイル、業務システム

MCPサーバーは、LLMそのものではありません。AIに代わって答えを書くものでもありません。外部の情報や操作を、AIクライアントが呼べる形にそろえる中継役です。

たとえば日本法令MCPなら、役割はこうなります。

ユーザー: 個人情報保護法の第2条を確認して
Claude Code: get_article ツールを呼ぶ
MCPサーバー: e-Gov法令APIから条文XMLを取得する
MCPサーバー: 条文本文、法令ID、出典URL、取得日時を返す
Claude Code: 返ってきた根拠をもとに説明する

ここで重要なのは、MCPサーバー側では法律相談も法的解釈も生成しないことです。MCPサーバーは「出典付きの材料」を返すだけにします。

MCPの3つの登場人物

MCPを理解するときは、クライアント、サーバー、ツールを分けると混乱しにくくなります。

MCPサーバーは、複数の機能をまとめて持てます。e-Gov法令MCPなら、法令検索、全文取得、条文取得、関連法令検索を別々のToolとして公開できます。

MCP仕様では、Toolは名前、説明、入力スキーマを持ちます。クライアントは tools/list で利用可能なTool一覧を取得し、tools/call で実行します。Toolの戻り値はテキスト、画像、音声、リソースリンク、構造化JSONなどにできます。法令のようなデータでは、本文だけでなく structuredContent やJSON文字列で返す設計が向いています。

stdio型MCPサーバーとは何か

ローカルで配るMCPサーバーの多くは、stdio型です。stdio型では、AIクライアントがMCPサーバーをサブプロセスとして起動し、標準入力と標準出力でJSON-RPCメッセージをやり取りします。

設定例はこうです。

{
  "mcpServers": {
    "egov-law": {
      "command": "npx",
      "args": ["-y", "egov-law-mcp"]
    }
  }
}

この設定では、Claude Desktopなどのクライアントが npx -y egov-law-mcp を実行します。MCPサーバーはstdinからJSON-RPCを読み、stdoutへJSON-RPCの応答を書きます。

stdio型で特に大事なのは、stdoutへ余計なログを出さないことです。MCP仕様では、stdoutには有効なMCPメッセージだけを書く必要があります。ログはstderrに出します。これを守らないと、クライアント側がJSON-RPCとして読めず、MCPサーバーが壊れて見えます。

stdout: JSON-RPC応答だけ
stderr: ログ、デバッグ、エラー表示

小さなMCPサーバーでも、この境界はかなり重要です。

e-Gov法令APIでできること

e-Gov法令API Version 1は、HTTP GETでXMLを返すWeb APIです。公式ドキュメントでは、主に次の機能が提供されています。

e-Gov APIカタログでも、法令APIは「法令データを外部サービスで利用するためのWebAPI」と説明されています。レスポンス形式はXMLです。つまり、MCPサーバー側ではXMLを取得し、AIクライアントが扱いやすいJSONやプレーンテキストに変換する処理が必要になります。

最小構成では、次の3つだけでも価値があります。

search_laws   法令名から法令IDを探す
get_law       法令IDから全文またはプレビューを取る
get_article   法令IDと条番号から条文を取る

ただし、法令実務ではこれだけだと不足しやすいです。法律、政令、省令、施行規則、告示、改正履歴が絡むからです。ここが後発MCPの差別化余地になります。

既存の egov-law-mcp がある

重要な前提として、npm名 egov-law-mcp はすでに使われています。公開リポジトリは ymadd/egov-law-mcp で、README上では次のToolが説明されています。

READMEには、APIレスポンスのキャッシュも説明されています。法令一覧は24時間、法令本文は7日間、更新一覧は1時間で、キャッシュは ~/.cache/egov-law-mcp/ に保存される設計です。

この時点で、同名パッケージを取ろうとする計画は終了です。ここで無理に似た名前の同じ機能を出すと、利用者から見て分かりにくくなります。

後発で出すなら、方針は3つあります。

個人的には、2番目と3番目を組み合わせるのがよいと考えています。つまり、スコープ付きパッケージ名で出しつつ、既存版とは別物として設計する方法です。

後発で作るなら、名前より先に差別化軸を決める

候補名だけを考えても、あまり意味がありません。先に「何を解決するMCPなのか」を決めるべきです。

同じe-Gov APIラッパーなら、先行実装があります。後発で出す価値を作るなら、たとえば次のどれかに寄せます。

この中で最初に価値が出やすいのは、出典明示と関連法令補完です。実装が軽く、記事でも伝わりやすいからです。

次に強いのが、ローカル全文検索インデックスです。これは既存の単純APIラッパーと立ち位置が変わります。e-Gov APIを毎回叩くのではなく、週次でXMLを取得し、ローカル検索に向いた形へ加工する。すると、パッケージ名も egov-law-index-mcp や jp-law-index-mcp の方が自然になります。

Lawsy-Custom-BQから持ち込むべきもの

源内のGoogle Cloud版に含まれるLawsy-Custom-BQは、法令に関する質問から関連法令を検索し、レポートを生成する構成です。BigQuery MLのベクトル検索、Vertex AI Gemini、Cloud Functions、API Gatewayなどを使うため、そのまま個人サイトやnpmパッケージに移すには重いです。

ただし、MCPに持ち込む価値がある考え方はあります。

1つ目は、法令名の推定と確認です。ユーザーが「個人情報保護法」と書いたとき、それが正式名称とどれくらい一致しているかを明示します。曖昧な場合は、勝手に1件へ決めず候補を返します。

2つ目は、関連法令の補完です。本体法だけでなく、施行令や施行規則も重要になる場面があります。AIクライアントが回答を作る前に、MCP側で候補を出せると、根拠の取り落としが減ります。

3つ目は、出典の強制です。法令ID、条番号、e-Gov URL、取得日時を戻り値に入れておけば、AIクライアントが回答時に根拠リンクを添えやすくなります。

一方で、MCPサーバー側でレポート生成までやる必要はありません。そこまでやると、LLM費用、モデル選定、法的助言に見えるリスク、回答品質責任が一気に重くなります。MCPは「根拠を渡す道具」に留める方が扱いやすいです。

作るならこういうMCPにする

後発で作るなら、私は次のような設計にします。初回公開では、スコープ付きの @codeagentjp/egov-law-mcp として出し、ローカルインデックスや法令diffは後続パッケージ候補としてRoadmapへ切り出しました。

パッケージ名:
  @codeagentjp/egov-law-mcp

目的:
  e-Gov法令データを、AIクライアントから出典付きで検索・参照する

主な特徴:
  - 全Toolが出典URL、API URL、取得日時を返す
  - 本体法、施行令、施行規則の候補を返す
  - e-Gov XMLをローカルインデックス化する余地を持つ
  - 法的助言ではなく、法令参照に限定する

最初のToolは、次の5つでよいです。

この設計なら、既存の egov-law-mcp と完全には重なりません。既存版を否定せず、「単純なe-Gov APIアクセスなら既存版、出典強制・関連法令・インデックス志向ならこちら」という棲み分けにできます。

戻り値は文章ではなく根拠データにする

法令MCPで避けたいのは、MCPサーバーがもっともらしい法律回答を返すことです。戻り値は、文章回答ではなく根拠データに寄せるべきです。

悪い例はこうです。

{
  "answer": "この場合、個人情報保護法上は本人同意が必要です。"
}

これはMCPサーバーが法律判断をしているように見えます。

よい例はこうです。

{
  "lawId": "415AC0000000057",
  "lawName": "個人情報の保護に関する法律",
  "article": "2",
  "text": "条文本文...",
  "source": {
    "name": "e-Gov法令検索",
    "url": "https://laws.e-gov.go.jp/law/415AC0000000057",
    "apiUrl": "https://laws.e-gov.go.jp/api/1/articles;lawId=415AC0000000057;article=2",
    "attribution": "出典: e-Gov法令検索（https://laws.e-gov.go.jp/）",
    "retrievedAt": "2026-04-25T00:00:00.000Z"
  },
  "notice": "This tool returns source text for reference only and does not provide legal advice."
}

この形なら、MCPサーバーは「根拠条文を取ってくる係」に留まります。最終的な要約や比較は、ユーザーが使っているAIクライアント側のモデルに任せられます。

MCP導入時の安全境界

MCPは便利ですが、導入するとAIクライアントの権限が増えます。特にstdio型MCPは、クライアントがローカルコマンドを起動します。知らないMCPサーバーを入れることは、知らないCLIツールを実行することに近いです。

法令MCPのような読み取り専用ツールでも、READMEには最低限次を明記した方がよいです。

• シェルコマンドを実行しない
• ファイルを書き換えない
• e-Gov法令検索以外へ通信しない
• APIキーや認証情報を要求しない
• stdoutにはMCPメッセージだけを書く
• ログはstderrに出す
• 法的助言ではなく法令参照ツールである

この説明は、利用者への安心材料になるだけでなく、MCPディレクトリやawesomeリストに載せるときの信頼にも関わります。

公開導線はGitHub、npm、記事の3点セット

MCPサーバーを作るなら、コードだけ置いても見つかりません。最低限、次の3点をそろえます。

特にMCPは、利用前に「このサーバーは何を読むのか」「何を書けるのか」「どこへ通信するのか」を確認したい人が多いです。READMEだけでなく、記事側で設計境界を書いておく価値があります。

さらに、公開後はMCP Registryやコミュニティ系ディレクトリへの掲載を狙います。公式MCP Registryは、公開MCPサーバーを発見するための場所として提供されています。MCPは検索流入だけでなく、ディレクトリ流入も大きいジャンルです。

今回の判断

今回、egov-law-mcp という名前は既存パッケージに使われていました。したがって、同じ名前のリポジトリ作成やnpm公開は止めるべきです。

ただし、企画そのものを止める必要はありません。むしろ前提がはっきりしました。

既存:
  e-Gov法令APIをMCPから使う最小ラッパー

後発で狙う場所:
  出典強制、関連法令補完、更新検知、ローカル全文検索

この立ち位置なら、既存実装と競合するより、隣を埋める形になります。記事では既存パッケージを明記し、後発で作る理由を透明に説明する方がよいです。

まとめ

MCPは、AIエージェントに外部データや操作を渡すための規格です。e-Gov法令APIと組み合わせると、Claude CodeやClaude Desktopから日本法令を出典付きで参照できるようになります。

ただし、すでに egov-law-mcp は公開されています。後発で同じものを作るなら、名前を変えるだけでは弱いです。狙うべきは、法令参照の実務で必要になる出典明示、関連法令補完、更新検知、ローカル検索インデックスです。

MCPサーバーは、法律回答者ではなく、根拠データを渡す道具として設計する。この境界を守るほど、公開しやすく、説明しやすく、使う側も安心して導入できます。

出典

• Model Context Protocol: What is MCP?
• Model Context Protocol: Transports
• Model Context Protocol: Tools
• Official MCP Registry
• e-Gov 法令API（Version 1）の概要
• e-Gov APIカタログ: 法令API
• GitHub: ymadd/egov-law-mcp