n8nでslugが毎回同じになる原因と解決方法【LLM動的生成に戻す】

LLMノードの直後に、出力を整形するCodeノードを追加します。LLMの出力に余分なスペースや記号が含まれることがあるため、以下のコードで正規化します。そのまま使えます。

const slug = $input.first().json.output[0].content[0].text
  .trim().toLowerCase().replace(/[^a-z0-9-]/g, '');
const up = $('統合後の整形').first().json;

const now = new Date().toISOString().split('T')[0];
const header = 'keyword | 検索意図 | 関連思想 | slug | picked_at';
const line = [up.keyword, up.intent, up.thought, slug, now].join(' | ');

return [{ json: {
  keyword: up.keyword,
  intent: up.intent,
  thought: up.thought,
  slug,
  csvContent: header + '\n' + line,
}}];

LLMノードの出力形式によって参照パスが変わるので注意が必要です。Responses APIの場合はoutput[0].content[0].textで取得できます。

ステップ4：manifest.csv書き込みノードの移動

slug生成が完了してから manifest.csv に書き込む必要があるため、Convert to FileとUpdate fileノードをslug整形の直後に移動します。

私のフローでは当初、ファイル取得の並列処理の前にmanifest書き込みを配置していたため、slugが確定する前に書き込みが走っていました。この順序の問題も修正が必要でした。

ハマりポイントと判断基準

修正の過程でいくつかハマった点があったので、判断基準と合わせて記録しておきます。

LLMノードの出力形式は使うノードによって違います。

OpenAI Responses APIの場合：

$input.first().json.output[0].content[0].text

OpenAI Chat Completionsの場合：

$input.first().json.message.content

Anthropicノードの場合：

$input.first().json.content[0].text

出力パスを間違えるとundefinedになりますが、エラーにならないことがあるので気づきにくいです。

判断基準として整理するとこうなります：

• slugがundefinedまたは空文字になっている → LLMノードの出力パスを確認する
• slugは取れているがmanifest.csvに反映されない → Convert to FileとUpdate fileの順序を確認する
• Mergeノードを使っている場合にデータが欠ける → ノード直接参照（$('ノード名').first()）に切り替える

Mergeノードのタイミング問題についても触れておきます。

並列で複数のファイルを取得してMergeノードで結合している場合、AppendモードではRunが分かれてしまうことがあります。このとき$input.all()で全アイテムを取得しようとしても、一部がnullになります。

MergeノードのAppendモードでは、並列処理した複数ノードの完了タイミングにより、Runが複数に分割されることがあります。その場合、`$input.all()`で全アイテムを取得しようとしても一部がNullになる問題が発生します。

解決策はMergeノードを経由せず、各ノードをノード名で直接参照する方法です。

const indexText = $('article-jsonのExtract').first()?.json.data ?? null;

これはRunの順番に依存しないので安定して動きます。

この後どうなったか

修正後にスケジュールトリガーを手動で起動してテストしました。Slackに届いたインタビュー依頼を確認すると、slugがgeo-era-survival-conditionsと正しくキーワードに対応した値になっていました。

記事設計サマリも正しく表示されており、パイプライン全体が期待通りに動くことを確認できました。

今後の方針として、Codeノードに一時的な固定値を書く場合は、コメントで// TODO: 本番前に削除と明記するルールを自分の中で決めました。「あとで直す」を忘れないための最低限の仕組みです。

まとめ

今回の問題で学んだことを整理します。

n8nのパイプラインでslugが固定される原因のほとんどは、テスト用の固定値の残存です。「動いているから大丈夫」と思っていても、一部だけ固定値のまま動いているケースは案外気づきにくいです。

今日できる一歩として、以下の3点を確認してみてください。

1. Codeノードに固定値がないか確認する — 特にslug、URL、ID系のハードコードがないかを探す
2. LLMノードのピン止めが外れているか確認する — テスト後に外し忘れているケースは多いです
3. データの流れをノード単位で追う — Executionsの実行ログで各ノードのoutputを確認する

自動化パイプラインは「動いていること」と「正しく動いていること」は別の話です。定期的にoutputを確認する習慣が重要だと感じました。