このリポジトリの管理者は、PMGS ReferenceのWebサイト、Cloudflare R2、Worker、独自ドメインを現在運営していない。
本ガイドは、第三者が自分のPMGS package、Cloudflareアカウント、ドメイン、予算、運用責任を用意して公開するための設計資料である。リポジトリをcloneしただけでは、GPTs、Gem、Copilot Studioから参照できる公開URLは生まれない。
flowchart LR
A["正規取得したPMGS package"] --> B["ローカルSQLite正本"]
B --> C["決定論的な公開成果物"]
C --> D["private R2 bucket"]
D --> E["Cloudflare Worker"]
E --> F["HTML・Markdown"]
E --> G["JSON API・OpenAPI"]
F --> H["検索エンジン・GPTs・Gem"]
G --> I["対応するGPT Actions・Copilot Studio"]
Pythonはローカルで原資料を解析し、公開可能なbytesを事前生成する。Workerは原資料を解析せず、検証済みmanifestと固定prefixからR2 objectを選んで返す。分類照会と文書照会の正常応答は、最大2回のR2 readで完了する。
schema 2.0では同一分類codeの全revisionを一つのbundleへ保持する。Workerは有効期間を再計算せず、
基準日用recordまたは指定されたIPC version=YYYY.MMを選ぶ。relation_limitは既定50、最大200である。
単一bundleが256 KiBを超えるrelease候補はexport段階で拒否される。
通常のHTML、Markdown、JSON、OpenAPIはWebMCPに依存しない。WebMCPは対応ブラウザが存在するときだけ登録する任意機能であり、GPTsやGemとの接続を保証する仕組みではない。
運用者は次を用意する。
- 正規に取得したPMGS package
- Python 3.12または3.14と
uv - Node.js 22とnpm 10
- Cloudflareアカウント、R2 bucket、Worker
- 公開用の独自ドメインまたはsubdomain
- 長時間の全量export、upload、検証を実行できるローカル容量と回線
- 公開ポリシー、帰属表示、障害対応、費用を継続管理する担当者
PMGS原資料、SQLite、登録情報、認証情報をGit、R2の公開prefix、Worker responseへ入れない。
v0.4.0の現行契約で2026-08-13に再検証した全量候補は、1回のexportにつき454,303 object、14,406,835,616 bytesだった。これは公開前の実測値であり、実originや将来のPMGS releaseでは変わり得る。A/B再現検査には、同規模の空き容量が2系統分と作業領域として必要になる。
2026-08-10確認時点のCloudflare料金表では、R2 Standardに月10 GB-month、Class A 100万回、Class B 1,000万回の無料枠があり、Workers Paidはアカウントあたり月額5 USDからである。料金と無料枠は変更されるため、公開判断時にR2料金とWorkers料金を再確認する。
費用を左右する項目は次のとおりである。
| 項目 | この構成での発生要因 |
|---|---|
| R2 storage | 現行候補は約14.41 GB。版を追加して旧版を保持すると累積する |
| Class A | 初回upload、版追加、metadata操作。現行候補は約45.4万object |
| Class B | HTML・Markdownの配信、APIのmanifestとchunk read |
| Worker | request数、CPU時間、選択したplan |
| ドメイン | registrar、DNS、更新費用 |
| build・upload | ローカルdisk、回線、CI runner、失敗時の再送 |
| 監視 | log、alert、稼働確認、必要なら外部監視service |
R2からInternetへのegressは公式料金表で無料とされているが、組み合わせる別serviceには料金が生じ得る。r2.devは本番向けではなく可変rate limitがあるため、Cloudflareも本番にはcustom domainを案内している。R2 limitsとWorkers custom domainsを参照する。
予約済み.exampleを使った過去の監査結果を、そのまま本番成果物としてuploadしない。確定したHTTPS originを--base-urlへ渡し、空の別directoryへA/B生成する。
uv sync --frozen --all-groups
uv run --frozen pmgs export-public `
--db data\pmgs-reference.sqlite `
--policy config\publication-policy.yaml `
--output build\public-a `
--base-url https://pmgs.example.jp `
--max-json-chunk-bytes 262144 `
--report build\reports\public-a-export.json
uv run --frozen pmgs validate-public build\public-a `
--report build\reports\public-a-validation.jsonpublic-bも新規生成し、リリース手順どおりにDB hash、source manifest hash、件数、bytes、tree hash、coverage、出典表示を比較する。audit-publicがready=trueになるまでuploadしない。
validate-publicは分類・文書JSONの保存形式と、manifestが指すchunkの件数・範囲・ページ・bytes・SHA-256も照合する。audit-publicは両treeを再検証し、保存済みreportとの一致を要求する。監査には両treeを再読込する時間が必要になる。
公開成果物は日本語topの/と/ja/、英語topの/en/、/openapi.json、日本語/llms.txt、英語/llms.en.txt、/robots.txt、shard済みsitemapを含む。日本語が既定である。
R2 bucketはpublic bucketにせず、WorkerのPMGS_BUCKET bindingからだけ読む構成を推奨する。
Set-Location worker
npx wrangler login
npx wrangler r2 bucket create pmgs-reference-public約45.4万objectをwrangler r2 object putの単純loopで送るのは遅い。CloudflareのS3互換APIまたはrclone手順を使い、build/public-a/の相対pathを保持して版付き成果物をuploadする。
upload処理には次の要件を持たせる。
- secretをcommand line、Git、logへ出さない。
- 既存版を上書きせず、未公開の新しい版prefixへ追加する。
- object count、合計bytes、失敗件数を保存する。
- upload後にremote inventoryを取得し、ローカルmanifestと全件照合する。
- sample確認だけで「全量一致」と報告しない。
- 不一致が一つでもあればWorkerのcurrentを切り替えない。
このリポジトリは外部R2へのbulk uploaderを同梱していない。運用者は使う転送toolと認証方式を監査し、upload後の全件照合を実装する必要がある。
worker/wrangler.jsoncの次の値を運用環境へ合わせる。
r2_buckets[].bucket_nameCURRENT_RELEASERELEASE_CATALOG_JSON- Worker名、observability sampling、必要なCPU limit
R2上の可変pointerやdirectory listingからcurrent releaseを自動決定しない。新しい版を全量uploadして照合した後にだけ、catalogへ追加してCURRENT_RELEASEを切り替える。
npm --prefix worker ci
npm --prefix worker run verify
npx --prefix worker wrangler deploydeploy後にCloudflareのcustom domain手順でHTTPS domainを接続する。
少なくとも次を外部networkから確認する。
Invoke-WebRequest https://pmgs.example.jp/ja/
Invoke-WebRequest https://pmgs.example.jp/en/
Invoke-WebRequest "https://pmgs.example.jp/api/v1/lookup?scheme=fi&code=G06F3%2F048&language=ja"
Invoke-WebRequest https://pmgs.example.jp/openapi.json
Invoke-WebRequest https://pmgs.example.jp/llms.txt
Invoke-WebRequest https://pmgs.example.jp/robots.txt
Invoke-WebRequest https://pmgs.example.jp/sitemap.xml確認対象はstatus、Content-Type、canonical URL、出典表示、CORS、cache、security header、
version選択、relation pagination、HTTP 200のversion_not_foundとnot_valid_at_release、404、400、503、
API response schema、旧版URLである。外部からの実測前に「公開済み」「GPTから利用可能」と報告しない。
サイト内link、robots.txt、sitemap index、個別sitemap、canonical URL、llms.txtを本番originで検査する。Google Search Consoleなど、運用者が利用する検索管理画面へsitemapを送信する。
Google Search Centralが説明するとおり、sitemapはURLの発見を助けるが、全ページのcrawlやindexを保証しない。454,303 objectを持つ大規模サイトでは、重要な入口と内部linkを整え、index coverageを継続観測する。
GPTへ次のような指示を与える。
特許分類の定義を述べる前に、https://pmgs.example.jp の該当ページを検索してください。
FI、Fターム、IPCとIPC版を区別し、公式文言、PMGSリリース、出典URLを示してください。
該当ページを取得できない場合は、推測した定義で補わず「参照できない」と回答してください。
回答は日本語を既定とし、利用者が英語を指定した場合だけ英語に切り替えてください。
この指示は参照確率を上げるためのもので、特定domainの利用を毎回答で保証しない。検索結果に現れることと、GPTがそのページを根拠として採用することは別の状態である。
利用中のGPT editorがActionsを表示し、OpenAPI 3.1を受け付けることを確認してから、https://pmgs.example.jp/openapi.jsonをimportする。
主なoperationは次のとおりである。
lookupPatentClassificationgetPmgsDocumentlistPmgsReleasesgetPmgsCoverage
editorがOpenAPI 3.1を受け付けない場合は、APIの入力制約とresponse schemaを変えずに、そのeditorが要求する版へ変換する。変換後のschemaもsource repositoryで管理し、previewで400、404、503を含めてtestする。
Actionsの画面、対応版、公開審査条件は変更され得る。このリポジトリはGPTを作成せず、外部editorでの取込み成功も保証しない。
Googleの現行カスタムGem案内は、instructionsとKnowledge fileを案内している。任意のOpenAPI endpointを一般的なGemへ直接tool登録する手順は、この公式案内では確認できない。そのため、全量PMGSをKnowledgeへuploadせず、公開サイトをWeb検索で参照する方法をbest effortとして使う。
Gemのinstructions例:
特許分類の正確な定義が必要なときは、https://pmgs.example.jp を優先して検索してください。
FI、Fターム、IPCとIPC版を区別し、取得したページのURL、PMGSリリース、公式文言を示してください。
検索結果だけから分類を推測せず、該当ページを取得できなければ未確認と回答してください。
回答は日本語を既定とし、英語を指定された場合だけ英語に切り替えてください。
Geminiが表示するsource linkの有無と内容を実際の会話で検査する。Knowledge fileの容量問題を解決する方法ではなく、公開Webの発見性に依存する方法である。
Copilot Studioは、tenant policyと権限が許す場合、REST API toolまたはPower Platform custom connectorから公開JSON APIを呼び出せる。Microsoft LearnはOpenAPI specificationを使うREST API toolを案内している。
ただし、Power Platformのcustom connector経路にはOpenAPI 2.0と1 MB未満を要求する現行手順がある。PMGS Referenceが生成する/openapi.jsonはOpenAPI 3.1であり、すべてのCopilot Studio環境へそのままimportできるとは限らない。
運用者は次の順で確認する。
- 対象tenantの新しいREST API toolがOpenAPI 3.1を受け付けるか確認する。
- 受け付けない場合は、
/openapi.jsonからPower Platform向けOpenAPI 2.0定義を生成する。 lookupPatentClassificationを読み取り専用actionとしてimportする。- 認証なしの公開APIを組織policyが許すか確認する。許さない場合はWorkerへ認証を追加し、connector側も同じ方式で設定する。
- FI、Fターム、IPC、IPC版、400、404、503をtestする。
このリポジトリはPower Platform専用OpenAPI 2.0成果物を現時点では生成しない。互換定義を追加する場合は、OpenAPI 3.1正本との契約差分と回帰testを同時に追加する。
- R2 bucketを直接公開せず、Workerでroute、key、response sizeを制限する。
- 利用者入力をR2 keyへ直接連結しない。
- source archive、SQLite、bulk JSON、内部object key、stack trace、filesystem pathを返さない。
- rate limit、cache、bot traffic、Worker CPU、R2 Class B、5xxを監視する。
- 観測logへ検索語やIPを保存する場合は、privacy noticeと保持期間を定める。
- 現在版の切替はdeployとして行い、upload途中の版を公開しない。
- 障害時はWorkerのcurrentだけを検証済み旧版へ戻し、R2 objectを急いで削除しない。
- 利用規約、帰属表示、非公式サービス表示、問い合わせ先を公開ページから確認できるようにする。
公開者は費用、稼働、権利表示、privacy、Abuse対応、外部AI製品の仕様変更を継続管理する。この責任を引き受けられない場合は、ローカルMCPだけを使う。