proof-kb

直接検証できる証拠のナレッジベース（seo/kb/）

FAQ スキーマ、新しい updatedAt 日付、著者の略歴、文字数では、検索順位を獲得するページと、AI が生成したありふれた投稿をもはや差別化できません。競合他社が数秒でそれらをすべてコピーするからです。Google でトップ 3 に入り、ChatGPT、Claude、Perplexity に引用されるページには、競合他社にはコピーできない次の 2 つの要素があります。

1. 最初の 2 文で、具体的な一次情報の証拠を提示する（正確なテスト件数、レイテンシの差、金額、または本番データセット）。
2. 本文全体で、以下の 5 つの証拠カテゴリのうち少なくとも 4 つを組み合わせる。

検証可能な事実はすべて seo/kb/ に一度だけ保存し、それらの原子的な証拠ファイルを、収益につながるページ、比較ページ、ブログ投稿に組み込みます。単一の事実ストアを参照して執筆するエージェントは、仕様を捏造したり、古い価格を引用したりしなくなります。

ワークフローの振り分け判断ツリー

実行のたびに、このツリーに沿って判断してください。

Does `seo/kb/brand-ssot.md` exist?
├── No -> Workflow 1: `init`, then continue down this tree
└── Yes
    ├── Did the user just ship a benchmark, customer win, pricing change, or release?
    │   └── Yes -> Workflow 4: `route-fact`
    ├── Does the user want a site-wide proof gap audit?
    │   └── Yes -> Workflow 2: `interview` across the top 5 money/blog pages in `seo/kb/pages-index.md`
    └── Is the user drafting or upgrading a specific page?
        ├── Fewer than 4 proof categories in `seo/kb/proof/` match this page's topic?
        │   └── Yes -> Workflow 2: `interview`, then Workflow 3
        └── 4 or more -> Workflow 3: `draft` / `upgrade`

直接検証できる証拠の 5 つのカテゴリ

商用ガイド、比較ページ、ベンチマーク記事はすべて、以下の 5 つのカテゴリのうち少なくとも 4 つを含めて公開します。主張の種類が 1 つだけで、それを 5 回繰り返しても、購入者や情報検索モデルには薄いマーケティング文句としか受け取られません。

カテゴリ	場所	例（querybench.dev / deployfast.dev）
1. ベンチマークと統制テスト	seo/kb/proof/benchmarks/	m7g.xlarge で同時接続数 10,000 の条件下、Postgres のコネクションプーラー 14 種をテスト。PgBouncer は未プール時の 19.8ms に対し、p99 を 4.2ms に維持しました。
2. 顧客の成果と移行事例	seo/kb/proof/customers/	invoicekit.io は、定期請求の Webhook 42,000 件を AWS Lambda から deployfast.dev のワーカーに移行し、月間コンピューティングコストを $1,840 から $290 に削減しました。
3. 実際のスクリーンショットと短い動画	public/blog/<slug>/ + 証拠 ID	ターミナルトレースを Playwright で実際に撮影したもの、または稼働中のダッシュボードを 9 秒間ループ再生する <video>。AI 生成のアプリ画面は使わないでください。
4. 独自に集計した数値	seo/kb/proof/numbers/	2026 年第 3 四半期に deployfast.dev で実行された 140 万件の本番デプロイのうち、ビルド失敗の 78% は、固定されていない Node.js のマイナーバージョンが原因でした。
5. 実務上の失敗とエッジケースに関するメモ	seo/kb/proof/workflows/	ulimit -n を引き上げずに max_client_conn を 8000 より大きく設定すると、バースト負荷時にソケットが気付かないうちに切断されます。

ワークフロー 1：init（seo/kb/ のひな形を作成）

package.json、価格設定、データベーススキーマ、既存の /pricing、/about、/blog のソースに加え、リポジトリ内の未加工の証拠ソースをすべて確認します。対象には、ベンチマーク結果（bench/、benchmarks/）、分析データやデータウェアハウスのエクスポート、事例データ（data/）、インシデントの事後分析（docs/runbooks/、postmortems/）が含まれます。その後、次の 4 つのファイルを作成します。各証拠ファイルでは、レビュー担当者が 1 回のクリックで数値を確認できるよう、source: フロントマターのフィールドに未加工ソースを記載します。

1. seo/kb/brand-ssot.md（信頼できる唯一の情報源）

製品の正確な仕組み、価格プラン、対応スタック、製品が行わないことを記載します。コードベースで確認できた事実、またはユーザーが確認した事実のみを書き、それ以外はすべて [UNVERIFIED] とします。

# Brand SSOT: QueryBench (querybench.dev)
Last verified: 2026-11-12

## Product mechanics
- Runs Postgres and MySQL query regression benchmarks on every GitHub pull request.
- Spins up an ephemeral copy-on-write database branch in `1.8s` using ZFS snapshots.
- Parses `EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)` and fails the CI check if p95 execution time regresses by `> 15%` or buffer reads rise by `> 20%`.

## Pricing tiers
- Free: `$0/month` for 3 repositories and 100 PR benchmark runs/month.
- Pro: `$49/month` flat for unlimited repositories, 2,500 PR runs/month, 90-day flamegraph retention.
- Team: `$199/month` flat (no per-seat pricing) with SOC 2 reports, Slack alerts, and custom ZFS runners.

## Boundaries (what we do NOT do)
- No Oracle or Microsoft SQL Server (Postgres 14-17 and MySQL 8.0+ only).
- No persistent daemon inside production RDS instances.

2. seo/kb/proof/{benchmarks,customers,numbers,workflows}/<id>.md

検証可能な事実またはテストごとにファイルを 1 つ作成します。事実ごとにファイルを分けることで、複数のページから同じ数値を引用でき、テストを再実行したときも、route-fact で依存するすべてのページを一度に更新できます。

---
id: bench-zfs-branch-spinup-2026
category: benchmarks
date: 2026-11-04
topics: [postgres-branching, ci-database-testing, explain-analyze]
verified: true
source: bench/results/zfs-branch-spinup-2026-11.json
---

# 50GB Postgres branch spin-up: ZFS copy-on-write vs pg_dump restore

## Methodology
- Dataset: `50.4 GB` production-shaped Postgres 16 database (`180M` rows, 42 tables).
- Hardware: AWS `i4i.xlarge` (`4 vCPU`, `32 GB RAM`, NVMe), 50 consecutive cold runs.

## Raw numbers
| Method | Median | p99 | Disk per branch |
| --- | --- | --- | --- |
| `pg_dump` + `pg_restore -j 4` | `14m 22s` | `18m 05s` | `50.4 GB` |
| EBS snapshot clone | `48.6s` | `74.1s` | `50.4 GB` (provisioned) |
| QueryBench ZFS clone | `1.8s` | `2.4s` | `12 MB` delta on creation |

## Failure note
Pin ZFS ARC to at least `50%` of RAM (`zfs_arc_max`). Inside Docker with tight cgroup memory limits, the first sequential scan benchmark runs `3.2x` slower.

## Reusable snippet
In our 50-run benchmark on a `50.4 GB` Postgres 16 dataset (`180M` rows on `i4i.xlarge`), `pg_restore -j 4` took a median of `14m 22s` per PR environment, while a ZFS copy-on-write clone booted in `1.8s` (`2.4s` p99) using `12 MB` of disk.

3. seo/kb/competitors/claims-to-beat.md

検索順位を獲得している競合他社が引用する正確な数値を、それを上回るより大規模なテストと組み合わせて記載します。これにより、SERP の確認作業をエンジニアリングのタスクリストに変換できます。このセッションで SERP や Ahrefs にアクセスできない場合は、seo/kb/proof/ の情報を基に「Our stronger test」列を埋め、競合他社の列には [NEEDS SERP] と記載して、次回の実行に備えてファイルを残します（dataforseo-serp Workflow D が列を埋めます）。理由：競合他社の主張を捏造することは、他者についての統計を捏造することになるためです。

# Competitor claims to beat

| Keyword | Competitor URL | Their claim | Our stronger test | Status |
| --- | --- | --- | --- | --- |
| `postgres ci testing` | `competitor-a.com/blog/ci-db` | 3 Docker setups on a `100 MB` toy DB | 50 runs on a `50.4 GB` DB comparing `pg_restore`, EBS, ZFS (`bench-zfs-branch-spinup-2026`) | Shipped |
| `explain analyze tool` | `competitor-b.io/guides/explain` | 2 static `Seq Scan` examples | 10 real production regressions with before/after index buffer counts | Open |

4. seo/kb/pages-index.md

キーワードと証拠 ID に対応付けられた、すべての商用ページと投稿です。route-fact はこのファイルを読み、新しい事実がどのページに関係するかを特定します。

# Proof-to-page index

| File path | URL | Primary keyword | Proof IDs | Categories |
| --- | --- | --- | --- | --- |
| `content/blog/postgres-ci-testing.mdx` | `/blog/postgres-ci-testing` | `postgres ci testing` | `bench-zfs-branch-spinup-2026`, `cust-invoicekit-ci-cut`, `num-q3-regression-causes`, `wf-zfs-arc-limit` | 4/5 |
| `app/pricing/page.tsx` | `/pricing` | `querybench pricing` | `brand-ssot`, `cust-invoicekit-ci-cut` | 2/5 |

ワークフロー 2：interview（証拠の不足を補う。捏造はしない）

ベンチマーク、顧客の引用、レイテンシの数値、インシデントを決して捏造しないでください。読者が事実ではないと見抜く「50 個のツールをテストした」という主張を 1 つでっち上げるだけで、ドメイン全体の信頼を失います。また、顧客の成果を偽ると、法的リスクが生じます。

ページに証拠カテゴリが 4 つ未満しかない場合や、一般的な主張（「多くのチームが遅い CI に苦労しています」など）に頼っている場合に実行します。

ステップ 1：Scribiz で既存の録音を掘り起こす

ユーザーが創業者の音声メモ、YouTube のデモ、営業電話、監査の動画を持っている場合は、Scribiz（MCP：https://scribiz.com/mcp、または npx scribiz）を接続します。まず get_video_context を呼び出してチャプターと重要な場面を確認し、次に search_video で正確なフレーズを検索します。2 時間分の文字起こし全体を取得すると、25,000 トークン以上を消費するためです。記事に手を加える前に、検証済みの数値や事例をそれぞれ seo/kb/proof/ のアトミックファイルとして保存します。

ステップ 2：創業者に範囲を絞った質問を 3～5 個する

録音がない場合や、録音だけでは不足が残る場合は、それぞれが 1 つの数値または例外事例を引き出す質問を、正確に 3～5 個します。

To make `/blog/postgres-ci-testing` rank and get cited without inventing data, I need 3 facts:
1. **Metric:** What is the real median boot time and database size for your CI branches today?
2. **Customer win:** One customer (or an anonymized profile like "a 12-person Series A fintech") and their exact before/after metric.
3. **Failure note:** One non-obvious config mistake that broke when you ran this in production.

回答をアトミックファイルとして保存し、文章を書き始める前に seo/kb/pages-index.md を更新します。

ユーザーが今すぐ回答できない場合は、質問を seo/kb/open-questions.md に書き込み、それぞれの事実を記載すべき箇所に [NEEDS PROOF: <question>] マーカーを下書きに入れます。見える形になった不足は補われますが、捏造された数値は公開されます。

ワークフロー 3：draft / upgrade（コンセンサス＋証拠カードの設計）

すべての <h2> セクションを、次の 2 つの層から構成します。

1. [CONSENSUS]： 検索順位上位 5 ページのうち 4 ページ以上が扱っている定義、構文、サブトピックです。できるだけ少ない語数で説明してください。これらが欠けているとページが不完全だと見なされますが、繰り返しても何も加わりません。
2. [PROOF]： seo/kb/proof/ のアトミックファイル 1 つ以上（実際のスクリーンショットまたは再現可能なチャートも併用）です。競合にはないものを使います。

アウトラインの設計図（本文より先に書く）

seo/kb/outlines/<slug>.md に保存します。[CONSENSUS] タグと [PROOF] タグはアウトライン内にのみ記載し、公開ページにはタグではなく文章と数値を載せます。SERP にアクセスできない場合は、コンセンサスの各行に [CONSENSUS] [NEEDS SERP] とタグ付けし、次回の実行時に実際の上位 5 ページと照合します。

## H2: How ephemeral database branching works in CI
- [CONSENSUS]: copy-on-write blocks vs full file copies; the 6-line GitHub Actions YAML.
- [PROOF -> `bench-zfs-branch-spinup-2026`]: 50.4 GB / 180M-row table (`1.8s` ZFS vs `14m 22s` `pg_restore`).
- [PROOF -> `wf-zfs-arc-limit`]: the `zfs_arc_max` cgroup memory trap and the fix.

実行ルール

1. 導入は最後に書きます。 まず本文の各セクションを下書きし、その後、最も切れ味のある [PROOF] の根拠を冒頭の 2 文に入れます。本文を組み立てて初めて最も強力な数値が分かります。また、読者や検索システムは最初の 40 語で権威性を判断します。
   • 悪い例： 「現代のソフトウェア開発では、CI でのデータベース移行テストがエンジニアリングチームにとってますます重要になっています。」
   • 良い例： 「GitHub Actions で 50.4 GB の Postgres ダンプを復元するには、中央値で 14 分 22 秒かかります。ZFS のコピーオンライトブランチなら、同じ 1 億 8,000 万行のデータセットを 1.8 秒で起動できます。以下では、50 回のコールド実行にわたるベンチマーク、スキャンを 3.2 倍遅くする Docker のメモリの落とし穴、そして PR パイプラインに 2 秒未満のブランチ作成を組み込む方法を解説します。」
2. 証拠カテゴリを数えます。 完成した下書きに 5 カテゴリ中 4 カテゴリ未満しかない場合は、ワークフロー 2 に戻ります。3 カテゴリのまま公開しないでください。
3. ページを登録します。 seo/kb/pages-index.md に該当する行を追加または更新し、今後の事実をページに割り当てられるようにします。

ワークフロー 4：route-fact（複数ページへの反映）

新しいベンチマーク、導入事例、価格、またはリリースが出たら、それに依存するすべてのページに1回の変更で反映します。

1. ソースファイルを作成する： seo/kb/proof/<category>/<new-id>.md を作成するか、価格や機能の変更の場合は seo/kb/brand-ssot.md を編集します。既存テストを再実行する場合は、新しい日付入り ID（bench-zfs-branch-spinup-2026-12）を付け、frontmatter に supersedes: <old-id> を追加します。古いファイルには superseded_by: <new-id> を追加し、残しておきます。理由：古い数値を履歴として参照でき（「11月の1.8秒から短縮」）、どのテストの結果が変わったか差分で正確にわかります。変更の原因がリリースの場合は、brand-ssot.md の仕組みを説明する行も更新します。

2. 依存ページを特定する： seo/kb/pages-index.md を読んでから、リポジトリ内でトピックタグ、置き換えられた証拠 ID、古い数値そのものを grep します（インデックスにないページでも引用している場合があります）。

   grep -rnF --exclude-dir={node_modules,.next,.git,dist,build} -e '1.8s' -e '1.8 s' -e 'bench-zfs-branch-spinup-2026' .
   

   -F を使用し、ビルド出力は除外します。理由：エスケープしていない 1.8s の正規表現は 1x8s にも一致し、node_modules と .next によって、本当の一致箇所が大量の誤検出に埋もれてしまいます。一致した箇所をすべて開き、同じワークロードの同じ指標であることを確認します。同じ数値でも別のものを測定している場合があります（ページの 1.8s の LCP は、ブランチの 1.8s の起動時間とは異なります）。その場合はスキップし、次回もスキップできるよう、そのページの pages-index.md の行に記録します。bench/ 内の生の結果ファイルには手を加えません。

3. 一致箇所をすべてその場で編集する：

   • 古い数値や一般的な段落を、<new-id> に裏付けられた、そのページの文脈に合わせて書き直したスニペットに置き換えます。
   • 同じ文を複数の URL に貼り付けてはいけません。ページ間で定型文が同一だと、テンプレートを使い回したように見えます。
   • 事実を変更したページのみ updatedAt / lastModified を更新します。

4. seo/kb/pages-index.md を更新し、 変更したすべてのファイルに対して <new-id> を記載します。また、seo/kb/outlines/ と seo/kb/competitors/claims-to-beat.md の古い ID を新しい ID に差し替えます。

まとめの例

NEW PROOF: seo/kb/proof/customers/cust-invoicekit-ci-cut.md
Matched 3 pages:
├── content/blog/postgres-ci-testing.mdx (42,000-webhook migration outcome under H2 #3)
├── app/vs/branchbase/page.tsx (compute spend row: $1,840 -> $290/mo)
└── app/pricing/page.tsx (ROI callout above the Pro tier card)

引用効果の測定

証拠に裏付けられたページ、または route-fact の一連の作業を公開した後、対象となる購入者向けプロンプトを AI SEO Tracker（MCP：https://aiseotracker.com/api/agent/mcp）に追加します。ChatGPT、Perplexity、Claude、Gemini、Google AI Overviews が新しい数値を引用し始めたタイミングが表示されるため、どの証拠が効果をもたらしたかを把握できます。

検証チェックリスト

• seo/kb/brand-ssot.md と seo/kb/pages-index.md が存在し、今回の編集内容を反映している。
• 変更したページにあるすべての数値や顧客の成果が、seo/kb/proof/ または seo/kb/brand-ssot.md にたどれるか、seo/kb/open-questions.md に記載された [NEEDS PROOF] マーカーが付いている。
• 変更した記事は、最初の2文以内で一次資料に基づく根拠を示している。
• 変更した長文ページでは、4つ以上のカテゴリーの証拠を組み合わせている。
• 新規作成または編集したファイルに、捏造された統計情報や em ダッシュが一切ない。従来の文章が残っている更新済みページには、次回、unslop-seo のパスとそのチェック スクリプトを適用します。理由：proof-kb は根拠を追加するものであり、その周囲にある古い段落を整理するものではありません。