2026年版・1人＋AIで1,000ドメイン量産アフィの設計図【全公開】
前回、いまのSEOで残っている勝ち筋として「第4の道」
——Googleの監視レーダーに引っかからないサイズのロングテールKWでドメインを分散して大量に刈り取る戦略——
をさわりを公開しました。
今回はその設計図を全部公開します。
ドメインの選定基準、サーバー構成、サイト構造、コンテンツ生成フロー、内部リンク設計、被リンク戦略、運用ツール。隠す理由がもうないので、私が今この瞬間に作るならどう組むかを、そのまま書き出します。
『1,000ドメインって、いまの時代にバカじゃないの？』
って思うでしょ？でも、これやればほぼ稼げます。
（アフィリエイト歴26年の私が確信をもって言える。どれくらい稼げるかはその人のセンスにも左右されるけど）
ただ、そもそものSEOでのアフィリエイト経験がないならまずは、CVするキーワードとCVさせるための記事を勉強してください。とりあえずそこから。
いままで、その経験があるならAIと根気があれば月１００万くらいは余裕だと思います。
全体像：5層構造で考えていく
このパイプラインは5層で設計します。
ドメイン層：仕入れと履歴チェック
サーバー層：物理的な分散と隔離
サイト層：構造とテンプレート
コンテンツ層：AI生成と品質コントロール
監視層：被弾の早期検知と損切り
それぞれが独立していて、1層が崩れても他層が連鎖崩壊しない。これが量産パイプラインの基本思想。
はっきりいってこれ。私が過去に超量産してたときの構造とそんなに変わりません。
コンテンツの精度があがったのと人力が必要なくなったことが違うくらい。
昔だと、すべてのドメインに実弾（CVする記事）をこめるのは無理だったけど、今なら低コストで可能。
これやってたころ、クラウドワークスやシュフティ、＠SOHOとかいろんな外注サイトを使ってて外注費用が軽く100万を超えてました。今思えばゴミコンテンツなのに。。（納品された記事がコピーでチェックが漏れてたり…）
第1層：ドメイン層
仕入れ基準
最低価格帯の中古ドメインを月100本ペースで仕入れます。
（ここにそこそこ費用がかかるのでお財布と相談しつつ少しずつ増やすのがいいでしょうね。）
この戦略の肝、ロングテール量産戦略ではドメインの「質」をあまり追わないのが正解。理由は、狙うKWが3語以上の弱いロングテール（月間検索数100〜1000）だから、ドメインパワーは要らない。インデックスさえ通ればそれで十分なところを狙います。それでもたぶん大当たりがでるドメインも出てくるはず。（今までも経験的に…）
仕入れ先はexpireddomains.netで、期限切れをお名前かバリュードメインで狙う。（まだ使えるかは知らん。多分使える。）
必須チェック項目（4点のみ）
Wayback Machineで過去履歴を確認。アダルト・出会い系・違法系の履歴があるドメインは弾く
Ahrefs/Majesticで被リンクスパム履歴を確認。日本語以外の不審なリンクが大量にあれば弾く
**Google検索で「site:ドメイン名」**を試す。インデックスペナルティ済みなら復活困難なので弾く
レジストラ・登録日・所有者履歴をWHOISで確認
これだけ。深追いしない。1本あたり3分以内で判定。100本買って60〜70本が使えれば十分。
めっちゃ頑張ってしらべても精度がちょっと上がる程度なのでサクっと調べるのがGOOD。
普通にインデックスが残ってるのもあるので、そういうのを狙うのもいいと思う。
中古ドメインをずっとやってた人なら知ってると思うけど、海外から『勝手にとるな。』『返せ。』『訴える』ってのが0.05％くらい混じる笑
1000ドルで返すよ？ってメールしたらほとんど返事がなくなるんだけどね。
英語圏なら裁判されて有無を言わせず引き上げられたことも。。
これ書いてて思い出したんだけど、当時はこのチェックだけをひたすらやってもらってる外注さんがいた。月20万だった…
仕入れ予算
月10万円で50〜100本が現実的かな。年間1,200本ペース。どんどん入れ替えるから、3年で1500ドメインくらいになるんじゃないかな。この管理が毎月結構手間になってくる。
第2層：サーバー層
構成原則
googleにスパムと判定されるときがあり、そのときは同じサーバに収容されてるドメインが根こそぎ行かれることがあるので、サーバは少し分散。
「1サーバー被弾しても、全滅しない」ように設計。
具体的には：
1サーバーあたりドメイン上限10〜20本
IPアドレスを物理的に分散
レンタルサーバーを3〜5社に分散
昔はIP分散サーバーやいっぱいドメインを入れられるエックスサーバ、ほかいろんなサーバを手当たり次第借りてたのが懐かしい。
推奨構成
メインサーバー：エックスサーバー（複数アカウント）
1アカウントあたり10〜20ドメインを上限に運用
マルチドメイン無制限プランなので大量設置可能
安定性が高く、被弾時の復旧が早い
IP分散サーバー：mixhostやColorfulBoxなど別系統
IPレンジを完全に変える
1サーバーあたり10ドメイン程度
クラウド分散：必要に応じてVPSやAWSのS3静的ホスティング
静的HTML運用ならS3＋CloudFrontで月数百円
合計サーバー費用は、月3〜5万円程度。1,000ドメイン運用でも月10万円は超えない設計。
私が今組むとしたら、エックスサーバとミックスホストかなぁ。。ミックスホストはアダルトもOKだし。困ったときにミックスホストの代表が夜中なのに対応してくれたのを思い出す。ミックスホスト一押し！
ムームー系はトラフィックが多いと止められるので私的にはあまり好きじゃない。
第3層：サイト層
構造選択：WordPressを使わない
これが今回の設計の重要ポイント。
WordPressを使うと、プラグインの脆弱性、PHPバージョン管理、データベースのバックアップ、自動更新の事故といった保守工数が爆発します。1,000ドメイン規模では物理的に管理不能。
代わりに採用するのが、WordPress風の構造を持つ静的HTML。
これ実は、10年前も同じことやってた。。
テンプレはたしか・・・色違いも入れたら２０くらいあったはず。
サイト構成とHTML内のclass名とか変えてた。。意味あったのかどうかしらんけど。
ワードプレスは管理できないならやるべきではない。
いつの間にかハッキングされて海外のカジノとかアダルトに変身してることもあるので笑
静的HTML構成
共通CSSは外部ファイル化（CDN経由でロード）
共通ヘッダー・フッター・サイドバーはJSでincludeするか、ビルド時にインライン展開
記事本文・カテゴリページ・トップページを静的に書き出し
サイトマップXMLとRSSフィードのみ動的に再生成
テンプレート設計
3〜5パターンのテンプレートをローテーションします。1テンプレートで100本以上のサイトを作ると、同一構造として検知される可能性が上がる。まあ、おまじないみたいなもんだけど工数はそんなに増えないのでやるべき。
パターン検知はほんとヤバイよ。一気にアクセスが半分になって、その次の週はまた半分に。。。
これはgoogleのスパム検知アルゴリズムに組み入れられてると思う。トラフィックが増えてきたサイトの中で、パターン検知（未知のパターンも）でドメインの集団を見つけていっきに主要キーワードの順位を落とすってやつ。
具体的には：
テンプレA：ブログ型（記事一覧+サイドバー）
テンプレB：マガジン型（トップに特集記事+カテゴリ別ブロック）
テンプレC：辞書型（ABC順インデックス+詳細ページ）
テンプレD：比較サイト型（ランキング+詳細レビュー）
テンプレE：Q&A型（質問見出し+回答本文）
CSSの色味、フォント、見出しスタイルもテンプレごとに変える。「サイトごとに違うサイトに見える」のが目標。
まあ、こんなのもclaudeに聞けばいくらでも提案してくれるから手を動かす必要はなし。自分で方向性を決めて判断・決断するだけ。
内部リンク設計
ここも重要。機械的なカテゴリ均等配置を避けるのがコツ。
関連記事の表示は記事ごとに2〜5本でばらつかせる
パンくずリストは含むが、機械的なサイロ構造にはしない
記事内リンクは1記事0〜3本でランダム化
フッターからのリンクは内部限定、外部サイトへの不自然なリンクを排除
このランダム化を、Claude Codeで自動生成する仕組みを作ります。
内部リンクで思い出した。
昔、サイト内検索窓を使ったら、そのワードで楽天APIをたたいてページが生成されるってのがあって、どんどんページが増える。内部リンクも増えるし、インデックスも増えてトラフィックもどんどん・・・
すげ～って思ってたらすぐ対策されて終わったんよね笑
第4層：コンテンツ層
ここが連載の核心。ちょっと技術的な話なので分からない人はAIに食わしてこれやりたいって言えばできると思う。
Claude Code＋ルールファイル構成
私がclaude codeをプロジェクトで回すときは、Harness Engineeringという考え方で構築してるんだけど、その構成（CLAUDE_APPEND.md・ERRORS.md・CONVENTIONS.md・skills/・validators/validate.pyの6点構成）を、量産パイプライン用にカスタマイズします。（いつものシステムはもっと複雑。AIがすべて構築するので私がみてもよくわからない状態になってる。）
具体的なファイル構成：
CLAUDE.md：プロジェクト全体の方針と禁則事項
WRITING_RULES.md：AI文体排除20項目（前回記事で公開した文体ガイド）
TEMPLATES/：テンプレート別の構造定義
VALIDATORS/check.py：生成記事の自動チェッカー
DATA/：独自データの参照元
SKILLS/：ジャンル別の執筆ルール
これ構築するとほんとなんでもできる。
SEO用の記事を書いてサイトを量産する程度は超簡単。
もっとハイレベルな仕事がなんでもできるようになる。
私が昔つくったスパムならない記事生成ソフトと比べると比較にならない。（小学生低学年と大学生の文章くらいの差がある。）
はっきり言って人間が文章を書く必要はないんじゃないかと思う。ナレッジに関してはだけど。。
エモい記事はまだまだ私のほうが上に感じる。知らんけど。
生成フロー
KWリストを準備（GoogleキーワードプランナーやAhrefsから抽出）
1KWに対し、テンプレを指定してClaude Codeで初稿生成
validator/check.pyで禁則事項違反を自動検出
違反箇所を修正してリライト
一次データ（自前スクショ・自前計測値・独自比較表）を1記事1個以上挿入
公開キューに追加
公開ペースのランダム化
毎日3本×3ヶ月のような機械的な公開は致命傷。
代わりに：
週2〜5本でランダムに公開
投稿時刻も09:00〜23:00の範囲でばらつかせる
同一カテゴリの記事を連続投稿しない
月単位の総数も80本〜120本でばらつかせる
このランダム化スケジューラもPythonスクリプトで組みます。1サイトあたり50〜80本で打ち止め、次のドメインに移行。
1記事1独自データの絶対ルール
これが、AI量産記事と「使える量産記事」を分ける最大の差別化点。
独自データの例：
自前で撮ったスクリーンショット（公式サイトの該当箇所をキャプチャ）
自前で計測した数値（処理時間、文字数、価格比較）
公的オープンデータからの独自抽出（厚労省、総務省、e-Stat）
自前の比較表（5〜10商品/サービスを項目別に並べた表）
自前の手順動画（GIF化してそのまま記事内に埋め込み）
このうち最低1個を、必ず1記事に入れる。validator/check.pyで「画像数が0なら不合格」のような機械チェックも入れる。
実はこういうのも手間はかかるけど、ちょっとアイデアを入れれば全自動でできる。
googleはユニークな情報を評価するから、APIでAIをたたいて情報を追加するとか、手持ちの画像を切り取って入れるとか。。ちょっと考えればユニーク（っぽい）な情報を入れるのはそんなにむつかしくない。
第5層：監視層
日次でログ化する指標
インデックス状況（site:ドメイン名 の結果数）
主要KWの順位変動
トラフィック（アクセス解析で確認）
ページごとの滞在時間と直帰率
被リンクの増減
こんなログもAIでシステム構築して自動チェックは可能な領域。
被弾兆候の検知
以下のシグナルが出たら、損切り判断に入ります：
インデックス数が前週比50%以上減
主要KWで10位以下に一斉落ち
トラフィックが3日連続で急減
損切り基準
被弾サイトに復旧コストをかけない、が原則。
具体的には：
被弾後7日でインデックス回復しない
アクセスがない。CVしたことがない
被弾サイトの記事資産（独自データ部分）は別ドメインに移植して再利用
このサイクル全体を、ダッシュボードで一元管理。
量産は比較的損切できるけど、1年間フルベットして月間2000万を超えたサイトはなかなか損切できなかった。いまだに記念にドメインは持ってる。
でも、一度、とんだサイトはまず戻らない。戻すリソースを次に使ったほうが絶対いい。覚えておいてください。
全体ワークフロー：1日の動き
参考までに、私が今この設計でオペレーション設計するなら、1日のフローはこうなります。
朝：
監視ダッシュボードで全1,000ドメインの状況確認（自動レポート）
被弾兆候があるサイトをピックアップ
損切り判断と移植処理の指示出し
午前：
ドメイン仕入れ判定（前日に見つけた候補20〜30本を3分×2時間でチェック）
採用ドメインのDNS設定とサーバー紐づけ
新規サイトのテンプレート割り当て
午後：
Claude Codeで記事生成（1サイトあたり5〜10本の初稿）
validator/check.pyで自動チェック
一次データの挿入指示
公開キューに投入
夕方：
公開スケジューラで翌日の公開キュー確認
全体サマリーレポート確認
これを1人＋オペレーター2〜3人で回す想定。最悪1人でできる。
実際にやってた当時は、ドメインを探す人、ドメインを設定する人、記事を書く人、サーバを設定する人、管理する人、アクセスが増えてきたドメインにCV記事を入れる人とかものすごいいろんな人でやってた。
今なら全部ひとりでできると思う。（一部はツール化してたが。。）
設計図の本体は、ここまで
骨格としての設計図は以上です。
ただし、この設計図には想定される懸念がたくさんあります。AI生成は検知されないのか。中古ドメインの最低価格帯で本当にインデックスが通るのか。1,000ドメイン規模の管理は現実的か。被弾時の損切りはちゃんと回るのか。
次回（3本目）では、この懸念を1つずつ潰していきます。Q&A形式で、技術的に成立するかどうかを検証する内容。
設計図を「実装可能な計画」にするためには、懸念の解像度を上げる作業が不可欠。次回はそこを書きます。
設計自体は大まかにはこんな感じ。
自分の環境に合わせて修正してもいいと思う。本質がずれてなかったら問題ない。
ここまででもわかる人だったら進められるんじゃないかな。claude codeを使ってないならまずはその勉強は必要。
コメント