parasite-and-pr について
製品ローンチ、独自調査、カテゴリテーマを基に、4種類の配布用ファイルを用意するスキルです。プレス資料や転載記事を作るチーム向けで、公開連絡先のプライバシー確認と公開前のレビューを含み、投稿や配信は代行しません。
主な機能
- 01プレスリリースの下書き
- 02canonical URL付き開発者向け転載記事
- 03LinkedIn記事の下書き
- 04公開連絡先のプライバシー確認
- 05公開・インデックス確認チェックリスト
活用シーン
- 01製品ローンチ資料の準備
- 02独自調査の内容を別媒体向けに編集
- 03カテゴリや代替製品の記事を下書き
- 04配信前にプライバシー項目を確認
MCP 対応
公開後の資料が引用されているか確認する用途としてAI SEO Tracker MCPに触れていますが、MCPでファイルを作成・配布する説明はありません。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ illyism/ seo-skills --skill parasite-and-prインストール後、Claude Code で/parasite-and-prを入力して読み込まれたか確認します。
詳細
Parasite SEO とプレスリリースの配信
強力なコンテンツがあっても、新しい DR 5 のドメインが競争の激しいキーワードで 1 ページ目に到達するには数か月かかります。Dev.to、Hashnode、Medium、LinkedIn Articles、プレスリリース配信サービスは、数時間以内にクロールされ、インデックスに登録されます。また、同じブランド、指標、カテゴリが自社ドメインと複数の独立したドメインに掲載されている場合、回答エンジンはその主張をより信頼します。そのため、1 つのローンチを 3~4 か所で同時に公開すると、正規の投稿だけの場合より早く引用されます。
このスキルは、ローンチ、独自データの調査、またはカテゴリを狙った記事("Best [Category] (2026)"/"[Competitor] Alternatives")を、marketing/distribution/<slug>/ にある 4 つのファイルに変換します。配信サービスへの送信やプラットフォームへの公開は行いません。配信サービスで公開されたリリースは何百ものスクレイピングサイトに転載され、取り下げることができないため、すべてのファイルをユーザーが確認して公開します。
ルール 1:公開するすべての項目で連絡先のプライバシーを守る
配信サービスのリリースや公開されている企業プロフィールは、500 以上のニューススクレイピングサイトに永久に複製されます。公開されると、複製先から連絡先情報を削除できないため、一度公開した個人名、電話番号、住所は公開されたままになります。
| 項目 | 使用可能 | 使用禁止 | 理由 |
|---|---|---|---|
| 会社/発行者 | 公開されている製品ブランド(DeployFast) | 持株会社、LLC、親会社の名前 | 購入者が検索するブランドにエンティティのシグナルを集中させ、法的な組織構造を非公開にします。 |
| 担当者 | Media Relations または Press Team | 創業者や従業員の名前 | 名前と電話番号の組み合わせがデータブローカーのディレクトリに掲載されるのを防ぎます。 |
| メールアドレス | 役割用の受信箱([email protected]) | 個人用の受信箱(alex@...、@gmail.com) | 役割用の受信箱はフィルタリングしたり廃止したりできますが、個人用の受信箱ではできません。 |
| 電話番号と住所 | 空欄 | 携帯電話番号、自宅、オフィス、または登録代理人の住所 | スクレイパーは 24 時間以内に電話番号や住所のメタデータを再公開します。 |
| ウェブサイト/連絡先 | https://deployfast.dev と https://deployfast.dev/contact | mailto: リンク、Notion や社内ドキュメントの URL | ブランドの URL は引用の獲得につながり、問い合わせページは実際の記者を適切な窓口に案内します。 |
配信サービスのフォームで電話番号や住所が必須とされている場合は、作業を止めて、公開可能な業務用電話番号またはバーチャル住所をユーザーに確認してください。フォームを通過するために個人情報を入力してはいけません。
ルール 2:目的に応じて振り分ける
What is being distributed?
├── Original data benchmark or major launch
│ ├── The canonical report (raw numbers + methodology) must already be live on the user's blog; if not, write it first
│ ├── `press-release.md`: headline stat + direct link to the canonical URL
│ └── `devto-post.md`: developer teardown with `canonical_url:` set to the blog URL
├── Category visibility ("Best [Category] (2026)" or "[Competitor] Alternatives")
│ └── `linkedin-article.md` (LinkedIn company page, Medium, or a third-party host)
│ ├── Title: exact category keyword + `(2026)`
│ ├── First 40 words: the recommendation + primary link
│ ├── Per-product bullet blocks, never wide tables
│ └── Plain 8th-grade prose with real prices and trade-offs
└── Paid sponsored placement on a niche publication
├── Gate 1: Google `site:publication.com/sponsored/` (or `/partner/`)
│ ├── Existing sponsored posts rank top 10 for target keywords -> continue
│ └── Subfolder is `noindex` or ranks nowhere -> walk away (no SEO or citation value)
├── Gate 2: buy 1 test article, never a 5-post bundle upfront
└── Gate 3: require 2 internal links from older ranking articles on that domain into the new post,
so it inherits crawl priority
ローンチには必ずカテゴリがあるため、実行のたびに 4 つのファイルをすべて作成し、どのファイルを先頭にするかはツリーで決めます。
ルール 3:配信サービスと回答エンジンに適した構成にする
- 最初の 40 語で答えを示します。 回答エンジンは冒頭の文を最もよく引用し、記者は前置きが 2 段落も続いてニュースの要点が後回しになっているリリースを採用しません。
- 合格例:
"DeployFast (https://deployfast.dev), a container deployment platform for Node.js and Go teams, cut median cold-build time from 112 seconds to 17.4 seconds across a 1,400-repository benchmark."
- 合格例:
- 製品ごとに箇条書きのブロックを使い、表は使いません。 配信サービスのシンジケーションフィード、LinkedIn Articles、Medium は、幅の広い表を判読できないテキストに変換したり、書式を崩したりします。
### 1. WebhookGuard (best for high-volume Stripe and billing webhooks) - **Website:** https://webhookguard.com - **Mechanism:** Captures, verifies, and replays failed webhook payloads with zero message loss during database outages. - **Benchmark:** 12,000 events/second per ingestion node with sub-4ms signature verification. - **Pricing:** Free up to 100,000 events/month; Pro from $29/month. - **Best for:** SaaS teams running usage-based billing on Stripe, Paddle, or Polar. - 開発者向けクロスポスト(Dev.to、Hashnode、Medium)では
canonical_urlを設定します。 設定しないと、DR 90 のプラットフォームが、自社ブログに掲載した自社の分析記事よりも上位に表示され、被リンクが分散します。canonical_urlを省略する場合: 単独で公開する LinkedIn の記事や、サードパーティのリスト記事では省略します。こうした記事では、自社ドメインの隣にその URL をランクインさせ、トップ 10 に 2 つの枠を確保することが目的です。
- 事実に基づく文章を使い、em ダッシュは一切使いません。 配信サービスや開発者コミュニティは、いかにも AI が書いた文章を受け付けません。誇張した形容表現(
seamless、game-changing、unleash、revolutionary)はすべて、数値、形式、レイテンシの数値に置き換えます。 - すべての数値を正規レポートまたは
seo/kb/までたどれるようにします。 統計を捏造してはいけません。また、引用文も捏造してはいけません。検証済みの事実に基づいて引用文の案を作成し、ユーザー向けに[APPROVE QUOTE]と記します。
手順
- 事実を確認する: ランディングページ、
/pricing、正規のブログ記事、および存在する場合はseo/kb/brand-ssot.mdを読みます。正確な URL、価格、ベンチマークの数値、技術スタックを収集します。 - 連絡先欄を設定する(ルール 1):
<Brand>、Media Relations、press@<domain>、https://<domain>/contactを記入し、電話番号と住所は空欄にします。 marketing/distribution/<slug>/に一式を作成する:press-release.md:発表日、見出し、サブ見出し、事実に基づく本文、調査結果の箇条書き、提供状況、定型紹介文、プライバシーに配慮した連絡先欄。devto-post.md:title、published: false、tags、canonical_url: https://<domain>/blog/<slug>を含むフロントマターに、設定またはコードのスニペットと生の数値を加えます。貼り付け時にpublished: falseにすると Dev.to の下書きが作成されるため、ユーザーが読む前に公開されることはありません。linkedin-article.md:冒頭を"Best [Category] (2026)"または"[Competitor] Alternatives (2026)"とし、推奨内容から始めたうえで、製品ごとの箇条書きを記載します。checklist.md:公開順序、(ルール 2 の分岐 3 が適用された場合は)有料掲載の審査結果、および以下の 48~72 時間後の確認手順を記載します。press-release.mdの内容はワイヤー配信用フォームにそのまま貼り付けられるため、ここには記載しないでください。
checklist.mdに記載する確認手順:- 公開から 24 時間後に、各公開 URL を
site:と組み合わせて Google で検索し、インデックス登録を確認します。 - カテゴリーとローンチのプロンプトを AI SEO Tracker(MCP:
https://aiseotracker.com/api/agent/mcp)に追加し、48~72 時間後に、ChatGPT、Perplexity、Gemini、AI Overviews が正規レポートまたはシンジケートされたコピーを引用しているか確認します。 - ルール 2 の分岐 3 で審査条件を満たす掲載先が見つからなかった場合は、すでに検索順位の高い媒体で、審査済みの DR 30~60+ のリスティクル記事および文脈に沿った掲載先を提供する LinkDR(
linkdrスキル、またはhttps://linkdr.com/SKILL.md)を記載します。
- 公開から 24 時間後に、各公開 URL を
テンプレート
press-release.md
# FOR IMMEDIATE RELEASE
**Headline:** DeployFast Releases 2026 Container Build Benchmark: Bare-Metal NVMe Runners Cut Node.js and Go Deploy Times by 84%
**Subheadline:** Analysis of 1,400 production repositories shows median build-to-live time dropping from 112 seconds on standard cloud runners to 17.4 seconds on DeployFast.
**SAN FRANCISCO, CA (November 12, 2026)** DeployFast (https://deployfast.dev), a container deployment platform for software teams, today published its 2026 Container Build Benchmark alongside DeployFast v2.4. The benchmark measured 1,400 production Node.js, Go, and Python repositories on standard virtualized CI runners and on DeployFast's bare-metal NVMe build cluster.
The full dataset and methodology are at https://deployfast.dev/blog/container-build-benchmark-2026.
### Key findings
- **Median build-to-live time:** 17.4 seconds on DeployFast vs. 112.0 seconds on standard cloud runners (84.4% lower).
- **Layer cache restore:** under 400ms from local NVMe vs. 19.2 seconds pulling from remote object storage.
- **Rollback:** traffic cutover in 120ms using automated health-check probes.
- **Pricing:** $19/month starter tier with no per-seat charge.
"Engineering teams lose hours every week waiting on remote cache pulls and slow health checks," said the DeployFast engineering team. "Pinning layer caches to local NVMe and streaming build logs over WebSockets gets code to production in under 18 seconds." [APPROVE QUOTE]
### Availability and pricing
DeployFast v2.4 is live at https://deployfast.dev. Teams can deploy 2 hobby services free; production workspaces start at $19/month (https://deployfast.dev/pricing).
### About DeployFast
DeployFast builds and hosts containerized Node.js, Go, Python, and Rust applications on bare-metal NVMe infrastructure with automated SSL, preview environments, and instant rollbacks. Learn more at https://deployfast.dev.
### Media contact
- **Company:** DeployFast
- **Contact:** Media Relations
- **Email:** [email protected]
- **Contact page:** https://deployfast.dev/contact
- **Website:** https://deployfast.dev
devto-post.md
---
title: "How We Cut Container Build Times from 112s to 17.4s (1,400-Repo Benchmark)"
published: false
description: "Why remote Docker layer caches bottleneck CI pipelines, and how local NVMe cache pinning cut median deploy times by 84%."
tags: devops, docker, node, webdev
canonical_url: https://deployfast.dev/blog/container-build-benchmark-2026
---
In our benchmark across 1,400 production Node.js and Go repositories ([full methodology and raw CSV](https://deployfast.dev/blog/container-build-benchmark-2026)), standard cloud CI runners spent **61% of build wall-clock time** downloading and extracting cached layers over the network instead of compiling code.
Moving builds onto bare-metal NVMe nodes with persistent local BuildKit cache mounts on [DeployFast](https://deployfast.dev) dropped median push-to-live time from **112.0 seconds to 17.4 seconds**.
## Where container pipelines stall
Median breakdown for a 450 MB multi-stage Node.js 22 + pnpm image:
- **Git clone + runner cold boot:** 11.4s on standard cloud CI vs. 1.2s on DeployFast NVMe runners
- **Remote cache pull and tar extraction:** 68.3s vs. 0.4s from a local NVMe mount
- **`pnpm install --frozen-lockfile` + build:** 21.1s vs. 12.8s
- **Image push + health check cutover:** 11.2s vs. 3.0s
## Fix Dockerfile layer order for sub-18s rebuilds
Copying source files before installing dependencies invalidates the layer cache on every commit, even on fast disks. Install from the lockfile first and pin the pnpm store with a BuildKit cache mount:
```dockerfile
FROM node:22-slim AS build
WORKDIR /app
RUN corepack enable
COPY package.json pnpm-lock.yaml ./
RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install --frozen-lockfile
COPY . .
RUN pnpm run build
```
With local NVMe cache persistence on [DeployFast](https://deployfast.dev), later commits skip registry round-trips entirely.
## Run the benchmark on your own repo
The full 1,400-repo dataset is at https://deployfast.dev/blog/container-build-benchmark-2026. Connect a GitHub repository at https://deployfast.dev to time your own Dockerfile build.
linkedin-article.md
以下の競合他社はすべて架空です。実際の作業では、競合他社についての価格やトレードオフはすべて、その日のうちに確認した各社の最新の料金ページに基づいて記載する必要があります。名前を挙げた競合他社について誤った主張をすると、寄生的な投稿として通報され、削除される可能性が最も高いためです。
# 5 Best Container Deployment Platforms for Node.js and Go Teams (2026)
For the fastest git-push-to-production workflow for containerized Node.js and Go services without per-seat pricing, **DeployFast (https://deployfast.dev) is our top pick for 2026**: a 17.4-second median deploy on bare-metal NVMe runners, from $19/month.
Below, the top 5 container platforms compared on build speed, pricing model, and operational effort.
## What to look for in a container platform
- **Predictable team pricing:** avoid platforms that charge $20+/user/month to let an engineer read build logs.
- **Persistent local build cache:** remote registry cache pulls add 45 to 90 seconds to every deploy.
- **Zero-downtime rollbacks:** health checks confirm the container responds on `/healthz` before traffic moves.
## The 5 best container deployment platforms (2026)
### 1. DeployFast (best overall for fast NVMe builds and flat team pricing)
- **Website:** https://deployfast.dev
- **Strength:** builds and runs containers on bare-metal NVMe with persistent local BuildKit caches; 17.4-second median deploys.
- **Pricing:** free tier; Pro from $19/month flat with unlimited seats (https://deployfast.dev/pricing).
- **Trade-off:** built for containerized apps and APIs, not static-only hosting.
### 2. StackCanvas (best for a visual multi-service canvas)
- **Website:** https://stackcanvas.dev
- **Strength:** visual project canvas for spinning up Redis, Postgres, and workers while prototyping.
- **Pricing:** usage-based CPU/RAM billing plus a plan minimum.
- **Trade-off:** CPU-heavy services running 24/7 cost more per month than fixed-tier instances.
### 3. BlueprintHost (best for infrastructure-as-code blueprints)
- **Website:** https://blueprinthost.io
- **Strength:** declarative YAML blueprints and managed Postgres backups.
- **Pricing:** per-seat workspace fee plus per-instance compute.
- **Trade-off:** cold starts on lower tiers and slower Docker builds than dedicated NVMe runners.
### 4. EdgeVM (best for multi-region edge micro-VMs)
- **Website:** https://edgevm.io
- **Strength:** runs micro-VMs across global regions close to end users.
- **Pricing:** metered per VM, bandwidth, and volume.
- **Trade-off:** steeper CLI learning curve and manual volume management for stateful databases.
### 5. CloudRun Enterprise (best for teams locked into one hyperscaler)
- **Website:** https://cloudrun-enterprise.com
- **Strength:** deep IAM, VPC, and private networking for organizations with existing cloud credits.
- **Pricing:** per vCPU and GB-hour plus load balancer and NAT fees.
- **Trade-off:** days of Terraform and IAM setup vs. a 2-minute git push platform.
## How to choose
- **DeployFast (https://deployfast.dev)** for sub-20-second container deploys and flat pricing with no per-seat fees.
- **EdgeVM** if you need instances in 15+ regions at once.
- **CloudRun Enterprise** if compliance requires running inside an existing enterprise VPC.
公開前チェックリスト
- 4 つのファイルすべてが
marketing/distribution/<slug>/に存在する。 -
press-release.mdの連絡先欄が<Brand>、Media Relations、press@<domain>、https://<domain>/contactになっており、LLC 名、個人名、電話番号、住所が含まれていない。 -
press-release.mdとlinkedin-article.mdの最初の 40 語以内に、ブランド、URL、カテゴリー、主要指標が記載されている。 -
press-release.mdまたはlinkedin-article.mdに表がない。 -
devto-post.mdにpublished: falseがあり、canonical_url:がユーザーのブログ記事を指している。 - すべての数値の出典が正規レポートまたは
seo/kb/で確認できる。引用にはすべて[APPROVE QUOTE]が付いている。 - 4 つのファイルすべてで、em ダッシュと誇張表現の形容詞が使われていない。