egov-law-mcp npm公開メモ: MCPサーバー配布とCI

日本法令をAIエージェントから出典付きで参照するMCPサーバー、@codeagentjp/egov-law-mcp の v0.1.0 をnpmに公開しました。

この記事は、機能紹介ではなく公開作業の実務メモです。既存の egov-law-mcp というnpm名が使われていたため、スコープ付きパッケージへ切り替え、GitHubリポジトリを独立させ、GitHub Actionsから npm publish --provenance で公開するところまでを整理します。

Claude CodeやCursorで実際に使う手順は、Claude Codeで日本法令を引く。@codeagentjp/egov-law-mcp の使い方実演に分けました。

結論

公開したもの

今回公開した成果物は次のとおりです。

インストール設定は、MCPクライアント側で次のように書きます。

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

@codeagentjp はnpmユーザースコープです。npm whoami が codeagentjp を返す状態だったため、npm Organizationを別途作る必要はありませんでした。

まず名前衝突を受け入れる

最初に想定していたnpm名は egov-law-mcp でした。しかし確認すると、同名のパッケージはすでに公開済みでした。

ここで取れる選択肢は3つあります。

後発で似たパッケージを出す場合、名前を変えるだけでは弱いです。READMEでは、既存実装との差分を明記しました。

この3点がないなら、後発で出す理由はかなり薄くなります。

monorepoから独立リポジトリへ切り出した理由

最初のMVPは codeagent サイトの packages/egov-law-mcp/ にありました。最終的にはこれを削除し、MCP本体を独立リポジトリへ移しました。

理由は単純です。MCPディレクトリ、GitHub検索、npm検索、README流入を考えると、サブディレクトリのままでは弱いからです。

公開リポジトリには、GitHub Topicsも設定しました。mcp、model-context-protocol、japanese-law、legal-tech、egov、japan、claude-code、cursor、anthropic、lawsy、gennai です。

これは飾りではありません。MCPはディレクトリ流入とGitHub検索流入の比重が高いので、READMEとTopicsは実質的な配布導線です。

package.jsonで決めたこと

package.json では、配布物を意図的に小さくしました。

{
  "name": "@codeagentjp/egov-law-mcp",
  "version": "0.1.0",
  "type": "module",
  "bin": {
    "egov-law-mcp": "./bin/egov-law-mcp.mjs"
  },
  "files": [
    "bin",
    "README.md",
    "LICENSE"
  ],
  "engines": {
    "node": ">=20.0.0"
  },
  "publishConfig": {
    "access": "public"
  }
}

ポイントは3つです。

1つ目は、files を絞ること。npmに余計な開発ファイル、メモ、環境ファイルを入れないためです。

2つ目は、bin を用意すること。MCPクライアントから npx -y @codeagentjp/egov-law-mcp で起動できるようにします。

3つ目は、publishConfig.access を public にすること。npmのスコープ付きパッケージは、デフォルトではprivate寄りの扱いになるため、公開パッケージでは npm publish --access public が必要です。npm公式ドキュメントでも、スコープ付きpublic packageは npm publish --access public で公開すると説明されています。

GitHub Actionsでタグ駆動publishにする

公開ワークフローは、タグ v* のpushで動くようにしました。

name: Publish to npm

on:
  push:
    tags:
      - 'v*'

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          registry-url: 'https://registry.npmjs.org/'
      - name: Verify version matches tag
        run: |
          PKG_VERSION=$(node -p "require('./package.json').version")
          TAG_VERSION="${GITHUB_REF#refs/tags/v}"
          if [ "$PKG_VERSION" != "$TAG_VERSION" ]; then
            echo "Tag $TAG_VERSION does not match package.json version $PKG_VERSION"
            exit 1
          fi
      - name: Publish
        run: npm publish --access public --provenance
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

package.json のversionとGitタグを照合しているのは、v0.1.0 なのに中身が 0.1.1、またはその逆の事故を避けるためです。

id-token: write は、provenance生成に必要になる構成です。npmのtrusted publishingでは、GitHub Actionsなどからの公開時にprovenance attestationを生成できます。今回のように npm publish --provenance を使う場合も、公開元のリポジトリとworkflowを検証可能にする意図があります。

npm Granular Access Tokenで入れた値

CIからnpmへpublishするには、npm側の認証情報をGitHub Secretsに入れる必要があります。今回はnpmのGranular Access Tokenを使いました。

入力した値は次です。トークン本体は当然ながら記事にもログにも出しません。

GitHub ActionsのRunnerはIPが固定ではないため、Allowed IP rangesは空欄にしました。Organizations権限も不要です。@codeagentjp はnpm Organizationではなくユーザースコープだからです。

npm公式ドキュメントでは、Granular Access Tokenはパッケージやスコープ単位でアクセスを制限でき、書き込み権限や2FA bypassも設定できます。CI用トークンは、必要なパッケージだけにRead and writeを付け、期限を短くするのが扱いやすいです。

GitHub Secretsへ入れる

生成したnpm tokenは、GitHub Actionsのrepository secretとして入れます。

gh secret set NPM_TOKEN -R SHAYOUWORLD/egov-law-mcp

貼り付けるのは、npmの画面で一度だけ表示される npm_... の文字列です。GitHub Docsでは、repository secretはCLIの gh secret set でも作成できると説明されています。

確認は次です。

gh secret list -R SHAYOUWORLD/egov-law-mcp

ここで NPM_TOKEN が表示されれば、workflowから参照できます。値そのものは表示されません。

タグを切って公開する

準備ができたら、タグを切ってpushします。

git tag -a v0.1.0 -m "v0.1.0: initial public release"
git push origin v0.1.0

今回はこのタグpushで Publish to npm workflowが走り、npm publishまで成功しました。GitHub側のリリースは v0.1.0 として公開されています。

公開後はnpm側も確認します。

npm view @codeagentjp/egov-law-mcp version name repository.url homepage

確認時点では、次の値が返りました。

version = '0.1.0'
name = '@codeagentjp/egov-law-mcp'
repository.url = 'git+https://github.com/SHAYOUWORLD/egov-law-mcp.git'
homepage = 'https://codeagent.jp/tools/egov-law-mcp'

Roadmap issueを先に置く

公開直後に重要なのは、次に何を作るかをREADMEの外に出しておくことです。今回はRoadmap issue #1として、関連MCPの候補を切りました。

優先順は C → D → A → B としました。理由は、データソースの扱いやすさとニュース/政策文脈との相性です。

このRoadmapを置いておくと、egov-law-mcp が「単発のe-Govラッパー」ではなく、日本語法令・制度データをMCP化していく入口だと伝わります。

今回やらなかったこと

初回公開では、あえてやらなかったこともあります。

• /tools/egov-law-mcp のランディングページ
• MCPディレクトリへの掲載申請
• Smithery / Glama / awesome-mcp系へのPR
• Cloudflare Workers版
• ローカル全文検索インデックス

理由は、npmに出る前に配布導線を作っても弱いからです。まず npx -y @codeagentjp/egov-law-mcp で使える状態を作り、その後にランディングページとMCPディレクトリ申請を積む方が順番として自然です。

注意点

CI publishは便利ですが、npm tokenを長期で放置しない方がよいです。期限を短めにして、不要になったtokenはrevokeします。npmのtrusted publishingが使える構成では、長期tokenよりもOIDCベースのtrusted publishingへ寄せる方が安全です。npm公式ドキュメントでも、trusted publishingは短命でスコープされた認証情報を使うため、長期tokenのリスクを減らせると説明されています。

また、MCPサーバーは利用者のローカル環境で起動されます。READMEには、次の境界を必ず書くべきです。

• シェルコマンドを実行しない
• e-Gov法令検索エンドポイントだけに通信する
• stdoutにはJSON-RPCだけを書く
• ログはstderrに書く
• 法的助言ではなく、法令参照ツールである

MCPは便利な接続口ですが、配布される側から見ればローカルで実行するプログラムです。小さく作るほど、監査しやすくなります。

まとめ

@codeagentjp/egov-law-mcp の初回公開でやったことは、派手な機能追加ではありません。名前衝突を受け入れ、スコープ付きで出し、READMEに差別化を明記し、GitHub Actionsで再現可能にpublishできる状態を作っただけです。

ただ、MCPサーバーはこの地味な配布設計がかなり大事です。AIクライアントから1行で起動でき、GitHubで中身を読めて、npmで取得でき、リリース履歴とRoadmapが見える。ここまでそろうと、個人開発の実験から、他人が試せる公開ツールに変わります。

次は、ランディングページとMCPディレクトリ申請です。npm公開が済んだので、ようやく配布導線を伸ばす段階に入れます。利用手順は、使い方実演記事で確認できます。

出典

• npm: @codeagentjp/egov-law-mcp
• GitHub: SHAYOUWORLD/egov-law-mcp
• GitHub Release: v0.1.0
• npm Docs: Creating and publishing scoped public packages
• npm Docs: About access tokens
• npm Docs: Creating and viewing access tokens
• npm Docs: Trusted publishing for npm packages
• GitHub Docs: Using secrets in GitHub Actions