管理のMakeか、突破のn8nか。同じ「データ整形」で分かれた手触り
今回の検証の目的はシンプルです。「人間が見やすいように作られた温湿度管理表（Excel）」を、「AIやシステムが処理しやすいデータ（CSV）」に変換すること。
同じゴールを目指しましたが、その過程で感じた「手触り」の違いは、今後の道具選びの指針になりそうなものでした。
「初期コスト」と「運用コスト」の天秤
まず直面したのは、「使い始めるまでのハードル」の違いです。
Make： ログインすればすぐに始められる圧倒的な手軽さがあります。しかし、設定を一つ誤ればクレジット（コスト）を無駄に消費しかねないという、従量課金特有の緊張感が常に付きまといます。
n8n（セルフホスト）： 最初の環境構築や認証（クレデンシャル）の手間は、正直に言って「重い」です。ただ、一度その壁を越えてしまえば、処理件数やコストを気にせず回せる「自前の道具」としての安定感があります。
仕組みを構築する側の視点に立てば、最初の手間を飲んででもn8nの安定感を取りたくなりますが、これが「時間がない、まずは一歩踏み出したい」という状況であれば、評価は真逆になるはずです。
「ボタンを探す」か「AIに頼む」か
修正が必要になった際のアプローチも、実に対照的でした。
Makeは、複雑なUIの中から該当する設定箇所を探し出す必要があります。一方でn8n（Codeノード）は、AIに状況を伝えてコードを書き直してもらうだけで済みます。
今回は、AIとのやり取りがスムーズだったこともあり、「コードの書き直し」の方が精神的なハードルが低く感じられました。 もちろん、これは作業内容にもよりますが、「設定画面という迷路」を歩くより、AIという外注先をコントロールする方が、今の私のスタイルには合っていたようです。
「ヘッダー」をどう扱うかで、思想の違いが見えた
データ整形を進める中で、Makeはデフォルトでは項目名（ヘッダー）を抽出しないという「思想」を持っていました。
しかし、私は「ヘッダーは絶対に必要だ」と考えています。データは、それを作成した本人だけが使うとは限りません。次にそのデータを受け取る誰か、あるいは数ヶ月後の自分が「これが何の数値か」を瞬時に理解するためには、ヘッダーという「文脈」が不可欠だからです。
たとえAIに処理させるためであっても、人との繋がりが残る現場のデータである以上、この一線は譲れないポイントだと再確認しました。
今回の検証で、判断に使える材料が揃った
今回の検証を終えて、私はどちらか一方に絞るつもりはありません。
Makeを使うなら： 少ない行数からテストを始め、クレジットの浪費を防ぎながら「制御」を楽しむ。
n8nを使うなら： 最初の泥臭い設定を乗り越え、AIコードという「力技」で大量データを一気に抜く。
「中身のメカニズムを完璧に理解していなくても、アウトプットの形が明確で、期待通りに動いているなら、今はそれでいい」。
そう割り切りつつも、いつかプロセスを振り返る必要がある時のために、少しだけ余白を残しておく。そんな「戦略的な距離感」こそが、今の私にとって最も効率的な自動化との付き合い方であると感じています。
📎 過去の記事はこちら
「簡単そう」に見えるMakeが、意外と判断を要求してくる理由
Vol.16：Excelは「人のため」、CSVは「AIのため」。Makeで挑むデータ整形の第一歩
https://note.com/toto_automake/n/n00eb4d37ff68
コードとAIに任せる、n8nでのデータ整形体験
Vol.17：道具が変われば、解法も変わる。n8nとAIコードで挑む「おまかせ」データ整形
https://note.com/toto_automake/n/n58d98b020ce9
📎 次の記事はこちら
整形したデータ、で何をするのか
Vol.19：整えたデータに「意味」を吹き込む。AI分析で見えてきた、一歩先のデータ活用
https://note.com/toto_automake/n/nc8d2d77126bb
📎 リアルタイムの学習ログはこちら
Xでは、
作業中に感じた違和感や、
判断を引き受ける場面での引っかかりを、
メモや簡単な2コマとして残しています。
記事になる前の、
思考の途中経過を置いている場所です。
https://x.com/toto_automake
