源内のLawsy実装をMCP化するなら、どこを残してどこを捨てるべきか

結論から言うと、源内のLawsy-Custom-BQをそのままWebサービスとして再現するより、日本法令を参照するMCPサーバーとして小さく作り直す方が現実的です。残すべきは「法令名を特定し、根拠条文を取得し、出典URLを返す」部分。捨てるべきは、運営側でLLM回答まで生成する部分です。

これは法律相談サービスを作る話ではありません。Claude Code、Cursor、Claude DesktopなどのAIクライアントから、e-Gov法令データに基づく根拠条文を取得するための開発者向けツールを作る話です。

この記事の位置づけ

源内OSS公開そのものの概要は、先に公開予定の政府AI「源内」のソースコードが商用利用可能な形で公開で扱います。この記事では一段狭く、Google Cloud版の法令AIアプリであるLawsy-Custom-BQを題材に、codeagent.jpで公開できる低コスト実装へ落とす場合の設計を考えます。

対象読者は、MCPサーバーやRAGツールを自作したい開発者、法令・規程・社内文書の検索ツールをAIエージェントに接続したい人です。

MCPそのものの基本や、既存の egov-law-mcp がある中で後発の法令MCPをどう差別化するかは、MCPとは何か。e-Gov法令MCPを例に、作る前に決める設計境界で整理しました。

Lawsy-Custom-BQの処理を分解する

公式READMEによると、Lawsy-Custom-BQはGoogle Cloud Functions、BigQuery MLのベクトル検索、Vertex AI Gemini、API Gateway、Terraformで構成されます。入力された法令質問に対して、法令名推定、BigQuery検索、条文選択、レポート生成、出典整理を行うサーバーレスAPIです。

実装の中心は law_report_pipeline.py です。処理の流れはおおむね次のように読めます。

ポイントは、Lawsyの価値が「Geminiに文章を書かせること」だけにあるわけではない点です。むしろ実装上おもしろいのは、法令名の揺れ、施行令・施行規則、条文番号の照合、出典の明示といった、法令検索に特有の前処理・後処理です。

そのまま移植しない理由

Lawsy-Custom-BQをそのまま動かすには、BigQuery、BigQuery ML、Vertex AI、Cloud Functions、API Gatewayが必要です。個人や小規模サイトがcodeagent.jpの隣で常時公開するには、運用面も費用面も重くなります。

さらに、サーバー側で法律レポートまで生成すると、モデル費用だけでなく、法的助言に見える回答の責任も重くなります。MCPにするなら、運営側が回答文を生成するのではなく、根拠データをAIクライアントに渡す設計にした方が安全です。

この境界は、APIコストとコンテキスト管理で扱った考え方にも近いです。高コストな生成処理をサーバーに寄せるほど、公開者が負担する費用と責任が増えます。逆に、検索・取得・出典整形に絞れば、ツールとして配布しやすくなります。

MVPは「日本法令MCP」にする

最初の成果物は、lawsy-mcp ではなく egov-law-mcp のような中立名がよいです。源内やLawsyの公式派生に見える名前は避けるべきです。この記事の方針に沿って、MVP実装は packages/egov-law-mcp として開始しました。

MVPで提供するツールは4つで足ります。

AIクライアント側から見ると、使い方はこうなります。

{
  "tool": "get_article",
  "arguments": {
    "lawId": "503AC0000000035",
    "article": "2"
  }
}

返すデータは、文章回答ではなく構造化された根拠です。

{
  "lawTitle": "デジタル社会形成基本法",
  "article": "第2条",
  "heading": "定義",
  "text": "条文本文...",
  "source": {
    "name": "e-Gov法令検索",
    "url": "https://laws.e-gov.go.jp/law/503AC0000000035"
  }
}

この形なら、MCPサーバーは「回答者」ではなく「出典付き検索ツール」になります。最終的な要約や比較は、ユーザーが契約しているClaudeやCursor側のモデルが行います。

データ層はBigQueryではなくローカルインデックスでよい

初期版では、BigQuery MLのベクトル検索を再現しない方がよいです。法令検索のMVPに必要なのは、最新性、出典、条文番号の正確性であり、意味検索の精度は後から足せます。

構成は次で十分です。

1. e-Gov法令データまたは法令APIからXMLを取得する。
2. 法令ID、法令名、条番号、見出し、本文、アンカーURLを抽出する。
3. SQLite FTS、MiniSearch、FlexSearchのいずれかで全文検索インデックスを作る。
4. npmパッケージとしてMCPサーバーを配布する。
5. インデックスは初回起動時にダウンロードするか、別パッケージに分離する。

e-Govの利用規約では、公開コンテンツは条件に従って商用利用も可能とされています。ただし、利用時は出典記載が必要です。したがって、ツール出力には必ず「出典: e-Gov法令検索」とURLを含める設計にします。

Lawsyから持ち込むべき設計

MCP化で特に持ち込む価値が高いのは、LLM呼び出しそのものではなく、周辺のガードです。

1つ目は、施行令・施行規則の補完です。Lawsy-Custom-BQには、本体法名から施行令・施行規則名を検索対象に追加する処理があります。定義や委任規定は本体法だけで完結しないことがあるため、この補完は法令検索ツールでも有効です。

2つ目は、法令名の読み替え警告です。実装では、クエリ内の法令名と推定法令名、実際に取得した法令名の乖離を検出し、回答冒頭で明示するための警告文を作っています。MCP版でも、曖昧な一致は「confidence」を低く返し、AIクライアントに確認を促すべきです。

3つ目は、条文番号の照合です。クエリに「第X条」が含まれる場合、Lawsyはその条文番号に対応する条文情報を優先的に参照させる設計です。MCPでは、get_article を明示ツールに分けることで、この照合をより単純にできます。

4つ目は、出典の自動付与です。MCPツールの戻り値には、条文本文だけでなく、法令ID、条番号、取得日、e-Gov URLを含めます。AIクライアントが回答する場合も、根拠リンクを落としにくくなります。

あえて持ち込まない設計

一方で、初期版に持ち込まない方がよいものもあります。

まず、サーバー側のレポート生成です。Lawsy-Custom-BQの prompts.py では、定義確認型、手続き確認型、比較検討型、解釈適用型、政策研究型、包括分析型の6パターンでレポート構成を選ばせています。これはアプリとしては強力ですが、公開MCPのMVPには重いです。

次に、Web groundingです。最新情報の補足には有効ですが、MCP配布物としては外部検索の不安定性と利用規約確認が増えます。まずはe-Gov法令検索に対象を絞るべきです。

最後に、Cloudflare Workers常時公開です。リモートMCPやWeb APIとして提供すると、レート制限、キャッシュ、DDoS、ログ、問い合わせ対応が必要になります。最初はローカルMCPとして配布し、利用者自身の環境で動かす方がコストも責任境界も明確です。

実装ロードマップ

第1段階は、記事と設計メモです。源内のLawsy-Custom-BQを読み、どの処理をMCPに移すかを公開します。この記事がその出発点です。

第2段階は、ローカルMCPのMVPです。search_laws と get_article だけでも価値があります。検索精度を追うより、出典URL、法令ID、条番号、更新日を正しく返すことを優先します。

第3段階は、インデックス更新の自動化です。GitHub Actionsで定期的にe-Govデータを取得し、差分があれば検索インデックスを更新します。配布物はMCP本体と法令インデックスを分けると、更新頻度を管理しやすくなります。

第4段階で、必要ならリモート版を検討します。Cloudflare WorkersやPages Functionsに載せるとしても、最初からLLM回答APIにはせず、検索APIに留める方が安全です。

公開前チェックリスト

• 名称が源内・Lawsyの公式派生に見えない
• ソフトウェアライセンスとデータ利用条件をREADMEに分けて書く
• e-Govの出典表記をすべてのツール出力に含める
• 法的助言ではなく、法令参照ツールであることを明記する
• 法令名の曖昧一致にはconfidenceや候補リストを返す
• 条文本文、条番号、URL、取得日をセットで返す
• LLM APIキーや認証情報をパッケージ側で要求しない
• 運営側でLLM費用が発生しない構成にする

まとめ

源内のLawsy-Custom-BQは、行政向け法令AIアプリの参照実装としてかなり学びが多いです。ただし、個人や小規模メディアがそのままWebサービス化するには、クラウド構成も責任範囲も大きすぎます。

codeagent.jpで公開するなら、狙うべきは「Lawsyの再現」ではなく「Lawsyから学んだ法令検索の境界設計」です。MCPサーバー側は、e-Gov法令データを検索し、条文と出典を返す。生成・解釈・比較は、利用者側のAIクライアントに任せる。この分担にすると、コストを抑えつつ、AIエージェント時代の法令参照ツールとして実用的な形になります。

最初のゴールは「Claude Codeから日本の法令条文を出典付きで引けること」です。egov-law-mcp はこの範囲に絞り、運営側でLLM費用を持たず、e-Gov法令検索への出典付き参照を返すローカルMCPとして育てるのがよいです。それだけで、源内OSSの文脈に乗った、codeagent.jpらしい技術コンテンツになります。

なお、npm名 egov-law-mcp は既に公開済みパッケージが存在します。後発で進める場合は、同名の単純ラッパーではなく、出典明示、関連法令補完、更新検知、ローカル全文検索インデックスなどに寄せた別設計にするのが現実的です。詳しくはMCPとは何か。e-Gov法令MCPを例に、作る前に決める設計境界を参照してください。

出典

• GitHub: Lawsy-Custom-BQ
• GitHub: law_report_pipeline.py
• GitHub: retrieval_bq.py
• GitHub: prompts.py
• e-Gov Developer: 利用規約
• e-Gov APIカタログ: 法令API