n8n記事生成パイプラインを別サイトへ移植した実践ログ｜設計差分と変更点を公開
# n8n記事生成パイプラインを別サイトへ移植した実践ログ｜設計差分と変更点を公開
n8nの記事生成パイプラインを一度作ると、「別サイトにも横展開したい」と考えることがあります。
ただ、同じ構成をそのまま移植すると、サイト特性の違いによって運用が破綻することがあります。
この記事では、bizinets.biz向けに作った記事生成パイプラインをjogtime.jpへ移植した実践例をもとに、「何を残して・何を廃止して・何を追加したか」の設計差分を公開します。
bizinets.bizとjogtime.jpで何が違ったか
移植を始める前に、2つのサイトの違いを整理しました。同じn8nパイプラインを使っていても、サイトの性質が違えば設計も変わります。
bizinets.biz：
- テーマ：思想・判断設計（副業ブロガー向け）
- YMYL該当度：低（健康・医療・金融の直接的な言及が少ない）
- 読者分類：シンプル（副業初心者・中級者の2層）
- 記事公開：AIが生成→人間確認→公開（通常フロー）
jogtime.jp：
- テーマ：フレイル予防（高齢者・家族向け）
- YMYL該当度：高（健康・身体機能に直結する情報）
- 読者分類：5種（不安顕在層・問題理解層・実践方法層・根拠理解層・家族支援層）
- 記事公開：AIは必ずdraftedまで・公開は人間が手動
この違いが、移植時の設計判断のほぼすべての根拠になりました。「サイトが変われば設計も変わる」という当たり前のことですが、具体的にどう変えるかを考えるのに意外と時間がかかりました。
廃止したファイルと変更した仕組み
移植にあたって最初にやったのは、bizinets.biz側で使っていたファイル構成を棚卸しすることでした。全部そのまま移植しようとすると、不要な複雑さが残ります。
廃止したファイル
summary_cache.json： bizinets.biz側では記事のサマリーをキャッシュするために使っていましたが、Jogtimeでは記事インデックスの管理方法を変えたため廃止しました。
keyword_done.csv： 処理済みキーワードを記録するためのCSVファイルです。Jogtimeではキーワード管理をGoogle Sheetsに一元化したため、このファイルは不要になりました。statusカラムで処理済み・未処理を管理する方式に変更しています。
article_index.json： 記事一覧を管理するJSONファイルです。Jogtimeではpages_enriched_v2.csvに移行したため廃止しました。
変更した仕組み
重複チェックの位置： bizinets.biz側ではLLM呼び出し後に重複チェックをしていましたが、Jogtimeではキーワード変換直後・LLM呼び出し前に移動しました。LLM後に重複が発覚すると、APIコスト・処理時間の両方が無駄になるためです。
pages.csvの構成： bizinets.biz版のpages.csvをそのまま使うと、Jogtimeに不要なカラムが混入します。frailty_stage（フレイルステージ）・target_reader（読者分類5種）などJogtime専用カラムを追加したpages_enriched_v2.csvに切り替えました。
判断基準：
- summary_cache.jsonを使っている → Jogtimeでは廃止・Google SheetsのstatusカラムとGSC/GA4キャッシュで代替
- keyword_done.csvを使っている → Jogtimeでは廃止・Google Sheetsのqueueシートで一元管理
- 重複チェックがLLM後にある → LLM呼び出し前のキーワード変換直後に移動する
キーワード管理をCSVからGoogle Sheetsに移行した設計理由
bizinets.biz側ではキーワード管理をCSVファイルで行っていました。Jogtimeへの移植タイミングで、Google Sheetsに切り替えることにしました。移植のタイミングは、仕組そのものを見直す機会にもなります。
移行の直接的なきっかけは、keyword_queue.csvの上書き消去です。n8nのCSV書き込みノードが設定ミスでファイルをまるごと上書きし、キーワードキューが消えました。n8nの実行履歴から復元できましたが、「同じことがまた起きる」という不安が残りました。
Google Sheetsに移行して変わったことは主に3つです。
変更1：Append or Update Rowによる重複防止
keyword_ja列をキーとして、同じキーワードがあれば更新・なければ追記という動作になります。CSVでは重複チェックのコードを書く必要がありましたが、Sheetsのノード設定だけで対応できます。
変更2：ブラウザから直接確認・編集できる
VPS上のCSVファイルを確認するにはSSH接続が必要でした。Sheetsならスマートフォンからでも確認でき、手動でstatusを変更したいときも簡単です。
変更3：26列構成での多段階ステータス管理
todo → selected → writing → drafted → publishedという状態遷移を1カラムで管理できます。加えてymyl_status・error_logなど、bizinets.biz側では不要だったカラムもJogtime専用として追加しました。
移行のコストはありましたが、その後のキーワード管理のストレスが大幅に下がりました。新規サイトへの移植タイミングは、こういった仕組みの見直しに最適だと感じています。
Dify RAG統合の設計とJogtime思想カードの構成
bizinets.biz側のパイプラインにはRAGの仕組みがありませんでした。Jogtimeへの移植にあたって、Difyのセルフホスト環境を使ったRAG統合を新たに設計しました。RAG統合によって、実際に品質は改善したのでしょうか。
RAGを入れた理由は2つあります。1つ目は記事の根拠品質を上げるためです。フレイル予防メディアとしてYMYL該当度が高いJogtimeでは、記事に根拠となるエビデンスを含める必要があります。毎回プロンプトに全情報を入れるより、RAGで必要な情報を検索して渡す方が品質が安定します。
2つ目はJogtime独自の思想をAIに一貫して持たせるためです。「外出・社会参加を促す」「恐怖訴求をしない」「読者の自己決定を尊重する」というJogtimeの編集方針をRAGカードとして登録し、記事生成時に参照させています。
Jogtime思想カードの構成
RAGに登録しているカードは大きく2種類です。
エビデンスカード： フレイル予防に関する研究・統計データを登録しています。「高齢者の〇〇%がフレイルに該当する」「週3回の有酸素運動でフレイルリスクが〇〇%低下する」といった数値情報です。記事生成時に関連する数値を自動で参照させることで、根拠のある記述が増えます。
思想カード： Jogtimeの編集方針・禁止表現・読者への姿勢を記録しています。「〜してはいけない」という恐怖訴求ではなく「〜するとどうなるか」という提案型の表現にするといった方針です。
bizinets.bizにはこのRAG統合がないため、Jogtimeへの移植で追加した最も大きな変更点の1つです。
YMYL自動公開禁止ポリシーを確定した理由
bizinets.bizではAIが記事を生成した後、一定の監査を経て自動でWordPressに下書きとして投稿し、人間が確認して公開するフローになっています。Jogtimeでも同じフローにしようとしましたが、方針を変更しました。
YMYL該当サイトにおいて、AIにどこまで任せるべきか悩んだことはないでしょうか？
Jogtimeの場合、n8nはWordPressへの投稿を必ず`draft`ステータスで行い、公開ボタンを押すのは人間の判断というポリシーを確定しました。
この判断には3つの理由があります。
理由1：YMYLの責任所在を明確にする
健康・身体機能に関する情報は、誤りがあった場合に読者の実際の行動に影響します。AIが生成した記事でも、「公開する」という判断をした人間が内容に責任を持つ構造にする必要がありました。
理由2：AIのYMYLチェックの限界を認識している
n8nフロー内にYMYLチェックノードを設けていますが、「明らかにアウト」なものを弾くことはできても、「グレーな表現」の判断はAIには難しいです。最終的な判断は人間が行うべきと考えました。
理由3：読者分類5種に対応した確認が必要
Jogtimeでは読者を「不安顕在層・問題理解層・実践方法層・根拠理解層・家族支援層」の5種に分類しています。どの読者層に向けた記事かを人間が確認してから公開することで、意図しない読者ミスマッチを防げます。
bizinets.bizとJogtimeで「人間の関与タイミング」が異なるのは、サイトのYMYL該当度と読者への責任の重さが違うからです。
ただし、このままだと自分のサイトに移植するときに何を変えるべきかは判断できません。
なぜなら、「サイトの性質の違いをどう設計判断に落とし込むか」という軸がまだ整理されていないからです。
→ 判断軸の整理はこちら
よくある質問
Q. bizinets.biz側のフローはそのまま残しておいていいですか？
はい、2つのフローは完全に独立して動きます。site_configノードをフロー先頭に置いてサイト固有の設定を読み込む構成にしているため、フロー間の干渉は起きません。bizinets.biz側のフローに手を加えずにJogtime側を新規構築できます。
Q. RAGはDify以外でも実装できますか？
できます。n8nのHTTP RequestノードでAPIを呼び出す構成にしているため、RAGの実装先はDifyに限りません。ただし、セルフホストでコストを抑えたい場合はDifyが現実的な選択肢の1つだと思います。
Q. YMYL判定はどのタイミングで行いますか？
記事本文の生成が完了し、自己監査・外部監査のリライトが終わったタイミングで行っています。最終的な本文に対してYMYLチェックをかける方が、途中の下書き段階でチェックするより精度が上がります。
まとめ
n8n記事生成パイプラインを別サイトに移植するとき、最初にやるべきことは「2つのサイトの違いの整理」です。YMYL該当度・読者分類・公開フローの違いを明確にすると、何をそのまま使えて何を作り直すべきかが自然に決まります。
今日できる一歩として、移植先サイトのYMYL該当度を確認することをおすすめします。これが高い場合は、自動公開の設計を根本から見直す必要があります。ここを曖昧にしたまま移植すると、後から大きな修正が発生します。
廃止・変更・追加の判断基準は「サイトの性質の違い」から逆算すると整理しやすくなります。同じ構成を検討している方の参考になれば幸いです。
ただし、このままだと自分のサイトで同じ判断を再現するのは難しいです。
なぜなら、「サイトの性質の違いをどう設計判断に落とし込むか」という軸が、まだ整理されていないからです。
→ 判断軸の整理はこちら
bizinets.biz
記事を読んで「もっと知りたい」と思ったあなたへ
bizinets.biz では、ビジネスの仕組みづくりを体系的に学べるコンテンツを用意しています。まずは一度、覗いてみてください。
bizinets.biz へ行く →
