最初は、チェックが壊れているのだと思いました。n8nの自動化フローに重複チェックを入れていたのに、記事化済みのキーワードでSlackにインタビューが届いたからです。
チェック機能は、作っただけでは動きません。正しい場所に置かなければ、チェックは存在しているだけになります。
今回、LLMを数回呼び出した後に「記事化済みです」と通知が来ました。チェックは機能していました。ただ、位置が遅すぎました。
この記事では、チェックをどこに置くかという設計判断を、自動化フロー全体の構造から分解します。
チェックは「存在するか」ではなく「どこに置くか」で価値が決まります。コストが発生する処理・人間が動く処理の前に置かなければ、チェックは防止ではなく事後報告になります。
– 「チェックをどこに置くべきか」知りたい方は「チェックはコストが発生する前に置く」へ
– 「なぜ位置が問題になるのか」を知りたい方は「遅いチェックが設計ミスになる理由」へ
チェックしていたのに、止められなかった
Slackにインタビューが届いたとき、最初は「ちゃんとフローが動いている」と感じました。
ところが質問内容を見ているうちに、見覚えがある気がしました。以前に同じ質問に回答したような、そんな感覚です。遡って確認すると、やはり重複していました。
keyword_queue.csvとkeyword_done.csvを並べて確認すると、両方に同じキーワードが記載されていました。重複チェックが機能していなかったのです。
まず疑ったのは、keyword_queue.csvを復元したときのデータ混入でした。フロー改善中にCSVが上書き消去されるトラブルがあり、n8nの実行履歴から古いデータを復元していたからです。その復元データに記事化済みキーワードが混入していました。
しかし、それだけが問題ではありませんでした。本当の問題は、重複チェックが正しく実装されていたにもかかわらず、LLMを数回呼び出した後にしか通知が来ない設計になっていたことでした。
問題は、チェックの有無ではなく位置だった
最初は「チェックが壊れている」と思いました。でも確認すると、チェック自体は機能していました。keyword_done.csvを取得して照合するロジックは動いていました。
問題は「いつチェックするか」でした。
重複チェックの通知がSlackに届くのは、市場調査LLM・記事設計LLMを経由した後でした。つまり、こういう流れです。
キーワード選定
→ LLM（市場調査）← クレジット消費
→ LLM（記事設計）← クレジット消費
→ LLM（インタビュー生成）← クレジット消費
→ Slack送信
→ 重複チェック通知「このキーワードはdone済みです」
これは防止ではなく、事後報告です。
「チェックがあること」と「チェックが効くこと」は別のことです。遅すぎるチェックは、失敗を防ぐのではなく、失敗した後に報告するだけになります。
なぜ遅いチェックは設計ミスになるのか
自動化フローは、処理が流れ始めると後続ノードが次々に動きます。特にLLMノードはAPIコール1回ごとにコストが発生します。インタビュー生成まで進むと、人間がSlackを確認してフローに関与する時間も奪います。
つまり、止めるべき判断を後ろに置くほど、失った後に気づくものが増えます。
つまり問題は、チェック処理そのものではなく、チェックをどの段階に置くかという設計でした。「チェックを入れた」という事実に満足して、「どこに入れるか」まで考えていなかったのです。
さらに、keyword_queue.csvが壊れてからデータを復元したという経緯が、この問題を表面化させました。もしCSVが正常に保たれていれば、重複データが入り込むことはなかったかもしれません。ただ、そうだとしても「LLM後に重複チェックが来る」という設計の問題は潜在したままでした。
チェックは、コストが発生する前に置く
修正の判断は明確でした。「LLMを挟まなくてもチェックできる処理であれば、コストが発生するより前に置く」というものです。
チェックをLLM前に移動することを決めた理由は2つです。
1つ目は、LLMを呼ばなくてもkeyword_done.csvとの照合だけで重複判定は完結するからです。複雑な処理は不要です。
2つ目は、LLMを使うたびにAPIクレジットが消費されるからです。記事化済みキーワードのためにクレジットを使い続けることは、コストとして明らかな無駄でした。
修正後のフローはこうなりました。
キーワード選定
→ keyword_done取得
→ 重複チェック（Codeノード）← クレジット消費なし
→ 重複あり？（IFノード）
├─ true → Slack通知「重複キーワードです」→ 停止
└─ false → LLM（市場調査）へ続行
同じ考え方は人間の作業にも当てはまります。Slackへの通知や人間の確認が発生する前に止められているかを確認することも重要です。今回、インタビューがSlackに届いてしまったのはここが抜けていたからです。
この順番にしてから、done済みキーワードがLLMに流れることはなくなりました。
session.jsonの残存チェックでも同じ問題が起きていた
チェックの位置が問題になるのは、重複チェックだけではありませんでした。
フローを見直していると、session.jsonの残存チェックも同様の問題を抱えていることに気づきました。インタビューに未回答のsession.jsonが残っているとき、次のフロー起動を止める設計を入れていたのですが、パス設定のミスでチェックが正しく機能していませんでした。
「チェックを作っている」つもりで、実際には見る場所が間違っていた。これも「チェックの存在」と「チェックが効くこと」が別物だという同じ構造の問題です。
同じインタビューが届いたことは望ましくありませんでした。ただ、この出来事がなければsession.jsonの問題も放置されたままだったかもしれません。静かに失敗する自動化で書いたように、自動化の問題は表面に出てきにくいものです。今回は表面に出たことで修正できました。
チェックは置いただけでは機能しません。見る場所を間違えれば、存在しないのと同じです。「チェックしているつもり」になっていないか、定期的に確認することが必要です。
判断基準：そのチェックは、何を防ぐためにあるのか
チェックを設計するとき、私は以下の問いで判断するようにしました。
問い1：このチェックは何を防ぐためにあるのか
チェックの目的を1文で言えない場合、置く場所も決めにくくなります。「重複を防ぐ」「未完了を防ぐ」という目的が明確になれば、どのタイミングで実行すべきかが決まります。
問い2：その失敗は、どの段階で止めるべきか
失敗が広がる前の最も早い段階で止めることが原則です。コストが発生する前、人間が動く前、後続処理が走る前のいずれか早い段階を選びます。
問い3：チェックの後に、無駄な処理が走っていないか
今回の問題はここでした。チェックが正しく動いていても、後ろにあることで「チェック通過後にコストをかけて失敗を発見する」構造になっていました。
問い4：コストが発生する前に止められているか
LLMのAPIコール、外部サービスの利用、時間のかかる処理の前にチェックを置けているかを確認します。
問い5：人間の作業が発生する前に止められているか
Slackへの通知・メールの送信・人間の確認作業が発生する前に止められているかを確認します。
問い6：チェック結果によって、フローが本当に分岐しているか
チェックを入れても、その結果でフローが止まらないならチェックとして機能していません。IFノードの条件設定・分岐先の接続が正しいかを確認します。
– このチェックは何を防ぐか1文で言えるか → NOなら目的を再定義してから配置する
– コストが発生する処理の前にあるか → NOなら前に移動する
– 人間の作業が発生する処理の前にあるか → NOなら前に移動する
– チェック結果でフローが実際に止まるか → NOなら分岐設定を見直す
– 「チェックしているつもり」になっていないか → YESなら実際に動作確認する
自動化で大事なのは、処理を増やすことではなく止める場所を決めること
フローを設計していると、つい「何を追加するか」を考えてしまいます。新しいノード、新しいチェック、新しい通知。しかし本当に重要なのは「どこで止めるか」を先に決めることです。
止める場所が後ろにあるほど、失敗は広がります。自動化は速く動く分、間違いも速く広がります。
増やす前に入れ替える判断でも書いたように、新しいものを追加する前に「今ある流れのどこを変えるか」を考えることが設計の出発点です。チェックを前に移動するだけで、コストも時間も節約できました。ノードを増やしたわけではありません。
自動化に判断を残す設計と合わせて言えば、チェックの位置を設計することは「自動化の中に人間が判断できる場所を守る」ことでもあります。チェックが後ろにあると、判断が必要な場面を通過してしまいます。
まとめ：チェックは、正しい場所に置いてはじめて意味を持つ
今回の問題は、チェックがなかったことではありませんでした。チェックはありました。ただ、位置が遅すぎました。
修正してから、自動化フローへの安心感が戻りました。それ以上に、放置されていたsession.jsonの問題も同時に発見・修正できたことは想定外の収穫でした。問題が表面に出ることで、構造の見直しができました。
次に自動化フローのチェックを設計するとき、以下の3点だけ確認してみてください。
- そのチェックは何を防ぐためにあるのか
- コストまたは人間の作業が発生する前に置かれているか
- チェック結果で実際にフローが止まるか
チェックは、安心するために置くものではありません。失敗を広げないために、正しい場所へ置くものです。
関連記事
今回のような問題は、技術の知識だけでは防げません。どこに判断を置くかを、フローを作る前に整理しておく必要があります。判断の順番を整理したい方に、無料PDFを用意しています。自分の自動化フローのどこに判断を置くべきかを一枚で整理できる構造チェックリストです。
コメント