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

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

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

この記事の位置づけ

デジタル庁の源内OSSで何が公開され、何が公開されていないかは、次の源内OSS公開の背景で要点だけ押さえます。本題はそこから一段狭く、Google Cloud版の法令AIアプリであるLawsy-Custom-BQを題材に、codeagent.jpで公開できる低コスト実装へ落とす場合の設計です。

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

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

源内OSS公開の背景

2026年4月24日、デジタル庁はガバメントAI「源内」の一部を、GitHub上で無償のOSSとして公開しました（デジタル庁）。源内は、デジタル庁が開発・運用する政府職員向けの生成AI利活用基盤です（政策ページ）。

公開されたのは、源内のWebインターフェース部分のソースコードと構築手順、そして源内で使われている一部AIアプリの開発テンプレート・実装です。ライセンスは「商用利用可能」と説明され、地方公共団体、政府機関、民間企業による再利用・改変・サービス化を念頭に置いています。ただし、源内のすべてや、政府が使っているLLMが公開されたわけではありません。 政府製AIモデルの公開ではなく、行政向け生成AI基盤の参照実装の公開と見るのが正確です。

公開された2つのリポジトリ

源内Webは、外部REST APIとして作られた行政実務用AIアプリを登録して呼び出す構成で、入力フォームはJSON定義から自動生成されます（AIアプリAPI仕様書）。AIアプリ側を独立したAPIとして切り出す発想は、この記事でLawsyの機能を小さなMCPツールへ分ける考え方とも近いものです。

genai-ai-api のAIアプリは、AWS、Azure、Google Cloudの3系統に分かれています。

ライセンスの切り分け

「商用利用可能」は正しいものの、ファイルによって条件が違います。

さらに、利用するLLMやデータセットにはコードとは別の利用条件があります。AzureテンプレートにはPLaMo翻訳モデルの実装例がありますが、使う場合はPLaMo側のライセンス確認が別途必要です。後で扱うMCPを別名で作り、READMEでソフトウェアのライセンスとデータの利用条件を分けて書くのは、こうした条件の混同を避けるためです。

公開されていないもの

デジタル庁の公式noteは、次のものを公開しないとしています（デジタル庁note）。

• 実際の源内で行政実務用RAG等が参照する内部マニュアル類
• デジタル庁が権利を保有しない大規模言語モデルや書籍
• 稼働中の源内の生ログ

内部の知識ベースや運用データまでは出さず、基盤を再現・参照するためのコードとテンプレートに限った公開です。

参照実装としての性格

開発の進め方は、コミュニティ協働型のOSSとは違います。両リポジトリともIssueはサービスの安定運用に影響する致命的な問題に限って受け付け、Pull Requestは受け付けない方針です。脆弱性対応などのメンテナンスは当面続けるものの、永続的な保守は保証されず、将来OSS公開を終了する場合があるとも明記されています。導入面でも、源内Webのデプロイ手順はAWS CDKやSAML認証、ログ送信先の準備を前提にしており、公開コードをそのまま本番運用できるほど軽いものではありません（事前準備）。

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の隣で常時公開するには、運用面も費用面も重くなります。上流はPull Requestを受け付けず、保守の継続も保証されていないため、フォークして追従し続ける前提も置きにくいです。

さらに、サーバー側で法律レポートまで生成すると、モデル費用だけでなく、法的助言に見える回答の責任も重くなります。MCPにするなら、運営側が回答文を生成するのではなく、根拠データをAIクライアントに渡す設計にした方が安全です。高コストな生成処理をサーバーに寄せるほど、公開者が負担する費用と責任が増えます。逆に、検索・取得・出典整形に絞れば、ツールとして配布しやすくなります。

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に分けて書く
• 源内由来のコードや図表を流用する場合は、MIT・CC BY 4.0・ASLのどれに当たるかを確認する
• e-Govの出典表記をすべてのツール出力に含める
• 法的助言ではなく、法令参照ツールであることを明記する
• 法令名の曖昧一致にはconfidenceや候補リストを返す
• 条文本文、条番号、URL、取得日をセットで返す
• LLM APIキーや認証情報をパッケージ側で要求しない
• 運営側でLLM費用が発生しない構成にする

まとめ

源内OSSは、政府LLMの公開ではなく、行政向け生成AI基盤とAIアプリの参照実装の公開です。その中の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を例に、作る前に決める設計境界を参照してください。

出典

• デジタル庁: ガバメントAI「源内」をOSSとして公開しました
• デジタル庁note: ガバメントAI「源内」をオープンソースとして公開します
• デジタル庁: ガバメントAI「源内」政策ページ
• GitHub: digital-go-jp/genai-web
• GitHub: digital-go-jp/genai-ai-api
• GitHub: Lawsy-Custom-BQ
• GitHub: law_report_pipeline.py
• GitHub: retrieval_bq.py
• GitHub: prompts.py
• e-Gov Developer: 利用規約
• e-Gov APIカタログ: 法令API