個人運営で、性格の異なる4つのメディアサイトを並行運用しています。2025年11月から半年で、合計149記事を公開しました。AI で記事生成すれば量はこなせますが、本当の難所は「サイトごとに違う設計」「ビルダーとデプロイの自動化」「アフィ配置の整合性」「品質チェックの自走化」をどうつなげるかです。本記事では実際に動いている構成と数値を、運用工程ベースで公開します。
運用している 4 メディアサイト
サイトの性格は明確に分けています。同じドメインの下に詰め込まず、テーマ別に独立ドメインまたはサブドメインで運用する方が、検索意図の混在を避けられて Search Console の評価も上がりやすい体感です。
| サイト | 記事数 (2026-05-21時点) | テーマ | 言語 |
|---|---|---|---|
| ai-pick.tech | 54本 | AI × SNS集客のピックメディア | ja/en/pt/es 4言語 |
| lab.ai-pick.tech | 11本 | AI × 自動化の実装ノート | ja |
| prompts.ai-pick.tech | 50本 | 実用プロンプト集 (コーディング/ライティング/分析/翻訳/画像生成) | ja |
| saas-diary.com | 34本 | 個人開発SaaS ジャーニーの記録 | ja |
| 合計 | 149本 | (ai-pick は 4言語化で 216 HTML) | - |
4サイトのうち saas-diary.com は AdSense の主審査用と位置づけて、アフィリンクを一切配置しないクリーン運用にしています。他の3サイトは Ezoic Incubator 申請中で、もしも・A8 の既存アフィを配置しています。「全サイトに同じ広告を入れる」設計にしないことで、審査クリーン要件と収益化を両立させています。
コンテンツ生成パイプライン — Gemini 自走 と Claude ペアモデルの役割分担
記事生成は2系統に分けています。役割分担を最初に決めることで、量と質のトレードオフが解消されました。
系統1: Gemini 自走バッチ (毎朝定時実行)
Gemini を使った無人記事生成バッチを、毎朝定時に走らせています。Topics 候補リストから1本選んで Gemini API を呼び出し、HTML 出力をそのまま articles.json に書き込む構成です。コストは Haiku 4.5 換算で1記事あたり数円、ai-pick.tech は週5-7本のペースで増え続けています。Gemini を選んだ理由はキャラクター上限の大きさで、3,000-3,500字の本文を1往復で生成できるためです。
系統2: Claude (Claude Code 内のペアモデル) の手動執筆
独自性が必要な記事 (実装ログ、レビュー、固有体験) は、Claude Code 内のペアモデル (Claude Opus 4.7、1M context) と対話しながら執筆しています。Anthropic API 契約は不要で、Claude Code セッション内で「lab のワークフロー1本書いて」と指示すれば Claude が body_html を直接生成し、articles.json に追加してビルドまで一気通貫で完了します。月の API コストは0円、品質は Sonnet 以上です。
系統の使い分け基準
1記事ずつ独自性が試される領域 (実装ログ・コスト圧縮の実数値・特定ツールの比較) は系統2 (Claude手動)、テーマが明確で網羅性重視の領域 (一般的な解説・カテゴリ紹介・基礎ガイド) は系統1 (Gemini自走) にしました。実体験ベースのライターと、解説型のライターを社内に2人雇った状態に近いです。
ビルダー系統 — 4言語 ai-pick と単言語ビルダー
ビルダーは2系統に分けています。
系統A: lib/html-builder.mjs (ai-pick.tech 専用、4言語)
ai-pick.tech は ja/en/pt/es 4言語対応のため、専用の lib/html-builder.mjs (1,300行) で運用しています。data/articles.json (ja) + data/translations/<lang>/articles.json の組み合わせで、ja の本文をベースに各言語の HTML を生成します。翻訳ファイルが欠落している場合は ja にフォールバックする仕組みなので、ビルドが落ちません。
系統B: lib/site-html-builder.mjs (lab/saas-diary 共通、単言語)
lab と saas-diary は単言語 (ja) のシンプル運用なので、共通の lib/site-html-builder.mjs (約800行) を使っています。sites/<site>/site-config.json 駆動で、カテゴリ・著者情報・収益化設定・GA4 などをサイトごとに切り替えます。新サイトを追加するときも、site-config を1つ作るだけでビルドが通る設計です。
系統C: prompts-site/scripts/build.mjs (prompts.ai-pick.tech 専用)
prompts.ai-pick.tech はプロンプト集なので、「使い方」「効くポイント」「コピペボタン」など独自の UI 要素があり、別ビルダー (prompts-site/scripts/build.mjs、約820行) で運用しています。Schema.org の HowTo 構造化データを各プロンプトに自動付与する設計です。
デプロイ — FTPS で WING に chunked deploy
4サイトすべて ConoHa WING の同一 FTP アカウント (apick01@ai-pick.tech) を共有し、/public_html/<ドメイン> 配下に書き込みます。WING は長時間 FTPS セッションを張りっぱなしにするとタイムアウトするため、basic-ftp ライブラリで 25 ファイルごとに access し直す chunked deploy を組みました。
- ai-pick.tech のフル再デプロイ: 611 ops (4言語×54記事+カテゴリ index+legal+assets で約20分)
- lab.ai-pick.tech: 33-36 ops (1分以内)
- prompts.ai-pick.tech: 118 ops (約3分)
- saas-diary.com: 79 ops (約2分)
デプロイは node scripts/deploy.mjs 1コマンドで完了、進捗とリトライは標準出力に流れるので Claude Code から直接実行して結果確認が完結します。
運用で踏み抜いた4つの落とし穴
1. ConoHa WING の URL ベース microcache
WING には URL ベースのコンテンツキャッシュがあり、デプロイ直後は古い HTML が返り続けることがあります。記事修正→デプロイ→ブラウザ確認の間にキャッシュが効いて「変わってない」と勘違いするトラブルが頻発したため、コンテンツキャッシュは検証期間中だけ OFF にする運用に切り替えました。本番運用時は ON に戻します。
2. Edit ツールは編集前 Read 必須
Claude Code の Edit ツールは、同セッション内で対象ファイルを Read していないと書き込みを拒否します。File has not been read yet. Read it first before writing to it. エラーが何度か出ました。新規ファイルは Write、既存ファイル編集は Read→Edit、というフローを身体で覚える必要があります。
3. AI 生成記事の独自性チェック漏れ
Gemini 自走バッチで生成した記事の中に、E-E-A-T が薄く「ネット記事の合成」レベルの記事が混入してしまいました。文字数 5,000字を超えていても、実測値の固有名詞ゼロ・失敗エピソードゼロ・1次データゼロ、の3点が抜けていれば AI 生成丸出しで判定されます。独自性5項目チェック (実測値固有名詞3個以上・実エラーメッセージ1つ・1次データ・個性視点・再現困難経験) を公開前ゲートに組み込みました。
4. 4言語ビルドの翻訳欠落
ai-pick.tech は4言語化していますが、翻訳ファイルの追加が記事追加と非同期になるため、新規 ja 記事に対応する en/pt/es の翻訳ファイルが欠落していることがあります。ビルダーが ja にフォールバックするため落ちはしないものの、英語ページに日本語が混じることになります。記事追加と同時に翻訳を生成する batch を別途用意するべきでした。
監視と改善ループ
4サイト並走の運用負荷を抑えるために、3層の監視を組んでいます。
- 毎朝の自動化チェック: Gemini 自走バッチが正常完了したか、デプロイが通ったかを Discord に通知
- 週次の品質点検: 6カテゴリ×4観点でスパム判定・法的リスク・AI判定を全点検
- 月次の戦略レビュー: AdSense 申請の準備状況、新規 ASP 提携、サイト追加判断
この3層は Claude Code から定期実行する設計で、人間の介入が必要なのは「月次レビューでの判断」だけです。日次の運用は自走しています。
再現できる部分と、できない部分
本記事の構成のうち、他の個人開発者が再現できるのは「ビルダー2系統+FTPS デプロイ」と「Gemini 自走+Claude 手動の役割分担」までです。一方、再現困難なのは「4サイトを同時に運営する判断負荷」と「サイトごとのテーマ設計」です。4サイト並走の認知負荷は、本人の関心領域が AI × SNS集客 / 個人開発SaaS / 自動化レシピ / プロンプト という具体的な4軸に揃っていないと、運用方向を決める意思決定の数が増えすぎて崩壊します。
テーマがある程度交差していて (例えば「AI で SNS マーケを自動化する」が4サイト共通の上位概念)、それぞれのサイトが具体的な切り口を担当している、という関係性が運用負荷を下げる鍵でした。
関連の運用記録は 自動化カテゴリ と AIツール実用カテゴリ にも蓄積しています。同じく Claude Code を運用基盤として使った別の事例は 3サイト114記事のアフィリンク最適化を Claude Code で半日完走させた実装ログ (姉妹サイト lab.ai-pick.tech) もご参照ください。
