Makeかn8nか、ではなく。道を分けたのは「AIとの対話」と「偶然の要因」だった

2026年2月25日 12:00

Noteの「スキ」を毎日記録する仕組み。同じ目的を持ちながら、結果としてMakeでは「表面（DOM）」を、n8nでは「裏側（NUXT）」を扱うことになりました。

手法が分かれたのは、ツールの優劣によるものではありません。そこには、AIとのやり取りの中で起きた、ある「偶然の要因」がありました。

分岐点は「AIチャットの仕様」に隠れていた

今回、手法を分けた一番の理由は、AIチャットの仕様上の制限が影響していました。

最初にMakeで構築していたとき、私は裏側のデータ構造をAIに伝えようとしましたが、情報が多すぎてチャット欄でエラーが出てしまいました。その結果、私は「今できるやり方」として、表面上の構造を拾うDOM（ドム）での構築を選びました。

一方、n8nのときは、たまたま新しいチャット欄で作業を開始しました。すると、以前は送れなかった大量のコードが正常にコピペでき、AIがその中から「裏側の入り口」であるNUXT（ナクスト）の存在を教えてくれたのです。

ツールの性能差というよりは、「その時のAIとの対話の解像度」が、私を別の道へと導いたのでした。

製造現場では、いくら計画を完璧にしたつもりでも、予期せぬ事態で歯車が狂うことは珍しくありません。だからこそ、その場の状況を整理し、最善を尽くす。私は今回の「偶然に身を任せる」ような進め方を、決して悪いことだとは思っていません。

ITの世界では「最適なルート」を事前に定義することが美徳とされがちですが、経験値が足りない今の私にとっては、「まずは失敗を恐れず、その時できるやり方で形にする」ことの方が重要だと感じています。

どちらも構築に「苦戦」したという感覚はありません。ただ、その時の状況に合わせて、手を動かせる方を選んだ結果です。

あえて言うなら、視覚的な操作で設定を進めるMakeよりも、中身は分からずとも「データの塊」を加工するn8nの方が、どこか「データに直接触れている」感覚がありました。

しかし、これも今の時点での個人的な感覚に過ぎません。DOMからの抽出がMakeに向いているのか、NUXTからの抽出がn8nに向いているのか。その「相性」を語るには、まだ私の経験値は足りていないのでしょう。

当然ながら、どちらの手法を使っても、抽出される「スキの数」という事実に違いは生まれません。アウトプットが同じである以上、現時点では手法の違いが数字の違いに直結しているとは言えません。

それでもあえて二つの仕組みを走らせているのは、どちらの「秤（はかり）」がより安定して動き続けるのか、あるいはサイトの仕様変更などにどう反応するのかといった、仕組みとしての挙動を観察したいからです。

「DOMだからMakeが良かった」「NUXTだからn8nが良かった」と決めつけるのではなく、この「状況によって分かれた二つの道」そのものを、大切な経験値として蓄積していこうと思います。

次回は、1週間分のデータをもとに、この観測にどれほどの意味があったのかを整理してみます。

初動が気になり始めたきっかけと、Makeで組んだ最初の観測実験
Vol.21：「スキ」の初動が気になって。Noteの反応を定点観測してみる話
https://note.com/toto_automake/n/na9c35081ee6c

n8nで再構築したもう一つの観測ルートと、その手応え
Vol.22：裏側の入り口「NUXT」を探し当てて。n8nで挑む、もう一つの定点観測
https://note.com/toto_automake/n/n089a94947b52

1週間の観測結果をもとに、この実験の意味を整理してみた
Vol.24：「スキ」の定点観測は必要だったのか？静止した数字から見えた「記事の役割」
https://note.com/toto_automake/n/na86a830a4e8b

Xでは、
作業中に感じた違和感や、
判断を引き受ける場面での引っかかりを、
メモや簡単な2コマとして残しています。

記事になる前の、
思考の途中経過を置いている場所です。
https://x.com/toto_automake