n8nで自動化の最終工程を実装中に、CSVファイルのデータが静かに破壊されていました。
エラーは出ていなかった。ノードは成功していた。それでもデータは壊れていました。
この記録では、何が起きたか・なぜ起きたか・どう判断して解決したかを整理します。
抽象化されたノードは、内部仕様を隠します。「動いている」と「正しく動いている」は別の状態です。**
この記事では、ノーコードツールの抽象化が壊れる瞬間の現象・原因・判断基準を整理します。同じ状況で同じ判断ができるようになることが目的です。
データが壊れていた、でもエラーは出なかった
ノーコード自動化で詰まったとき、どんな状態になっていましたか？
n8nでキーワード管理CSVに1行追記する処理を実装していました。Google Driveノードでファイルをダウンロードし、Codeノードで既存内容に新しい行を追加し、再びGoogle Driveノードでアップロードする。構造としてはシンプルでした。
実行しました。ノードは「成功」と表示されました。エラーは出ませんでした。
ファイルを開くと、1行目が文字化けしていました。既存の9行分のデータが消え、今回追記した1行だけが残っていました。
「またか」と思いました。ここに来るまでスムーズにいった試しがなかったからです。ただ今回は焦りが違いました。元データが上書きされていて、バックアップがなかったのです。
一度Claudeに元データを渡していたので最悪そこから復元できると思いましたが、そのデータも更新後のものに変わっていました。最終的にClaudeとのやり取りの履歴の中にデータが断片的に残っていたため、10件のデータを復元できました。綱渡りでした。
自分の意図しない変更が加えられる可能性がある処理を実行する前は、必ずバックアップを取ってください。「最悪Claudeに渡したデータがある」は復元手段になりません。Claudeのコンテキストは更新されます。
なぜ壊れたのか：binaryDataModeの罠
原因はn8nのbinaryDataMode: filesystem設定にあります。
このモードでは、バイナリデータがメモリではなくディスク上のファイルとして管理されます。Google Driveノードはこのバイナリを内部で処理しますが、Codeノードからはその実体に正しくアクセスできないケースがあります。
結果として何が起きたか。
- バイナリの読み取りが失敗していた
- でもエラーにはならなかった
- 空のデータとして処理が進んだ
- 追記した1行だけが残るファイルが生成された
これが2回繰り返されました。1回目で気づき、修正を試みましたが、コードを変えても同じ壊れ方をしました。ノードの抽象化が内部仕様を隠しているため、何が起きているか検証する手段がなかったのです。
構造分析をするとこうなります。
- 数値：2回の実行でデータが破損。既存9行が消滅
- 構造分析：binaryDataMode=filesystemのため、Codeノードがバイナリを正しく読み取れず空として処理された
- 判断基準：バイナリ処理でエラーなく壊れるケースが2回以上続いたら、ノードの抽象化ではなく生APIに切り替える
抽象ノードを捨てた判断の瞬間と決定打
「次は何を試せばいいか」で詰まったとき、どう判断しましたか？
私がGoogle Driveノードを捨てると判断したのは、2回目のデータ破損が起きた直後です。1回目は「コードのミスかもしれない」と思い修正を試みました。2回目が同じ壊れ方をしたとき、「ノード自体の問題だ」と判断しました。
判断の決定打は3つ揃ったことです。
① エラーなく壊れた
エラーが出るなら原因を特定できます。エラーなく壊れる場合、抽象化の内部で何かが起きています。検証できない問題は修正できません。
② 同じ修正を2回試みて同じ結果になった
同じアプローチで同じ結果が出るとき、アプローチではなく前提が間違っています。コードを直すより、ノード自体を変える判断が必要でした。
③ 検証手段がなかった
Google Driveノードのバイナリ処理は内部仕様が隠れています。「正しく読み取れているか」を確認する方法がありませんでした。HTTP Requestなら何を送って何を受け取っているかが明確になります。
比較した選択肢は「コードをさらに修正する」「別のノードに変える」「生APIに切り替える」の3つでした。最初の2つは同じ抽象化の上にある選択です。根本を変えるには生APIしかありませんでした。
判断トリガー一覧：
- エラーなく壊れるケースが1回出た → 抽象化を疑い始める
- 同じ修正を2回試みて同じ結果になった → ノードではなくアプローチを変える
- 検証手段がない → 生APIへ切り替える
- バイナリ処理でbinaryDataModeが絡む → 最初から生APIを検討する
- 「なぜ壊れるか」が分からないまま修正している → 根本原因の特定を先にする
バックアップがなかったことへの後悔と復元の記録
データが壊れたと気づいたとき、何を後悔しましたか？
バックアップを取っていなかったことです。自動化の実装中は「試験的な実行だから」という意識があり、本番データに対してバックアップなしで処理を走らせていました。
Google Driveにはバージョン管理機能があります。「版を管理」から以前のバージョンに戻せるはずでした。ところがCSVファイルでは「ダウンロード」ボタンがグレーアウトしており、以前のバージョンを取得できませんでした。
最終的な復元手段は、このチャット内での会話履歴でした。過去にClaudeに渡したCSVのデータがhead -5コマンドの出力として残っており、また別のチャット履歴から追記記録が断片的に確認できたため、10件のデータを再構築できました。
復元戦略は「壊れる前」に設計するものです。「壊れたら考える」では間に合わないケースがあります。自動化ワークフローを本番データに向ける前に、必ず復元手段を確認してください。
バックアップの判断基準：
- 本番データに対して書き込み処理を実行する → 事前にバックアップを取る
- 自動化の試験実行をする → テスト用のデータまたはフォルダで行う
- 復元手段が「Claudeとのやり取り」しかない → その時点でバックアップを取る
判断から導いた3つの原則
ノーコードツールを使っていて「うまくいっている」と感じるとき、何を根拠にしていますか？
今回の判断プロセスから、自然に導き出された原則が3つあります。経験の後付けではなく、判断の結果として出てきたものです。
原則1：「動く」より「壊れない」
「エラーなく壊れる」という状況を経験して気づきました。エラーは検知できます。壊れたデータの生成は検知できません。「動いている」の確認だけでは不十分です。「壊れていない」を確認する手順が必要です。
原則2：抽象化は疑う、信頼はしない
「検証手段がない」という判断がHTTP Requestへの切り替えを導きました。便利なノードほど内部を隠します。使うことと信頼することは別です。「使えるが、正しく動いているかは自分で確認する」という距離感が安全を保てます。
原則3：復元戦略は壊れる前に設計する
バックアップなしで本番データに書き込み処理を実行したことが、今回の最大のリスクでした。復元に成功したのは運によるものが大きく、再現性はありません。壊れることを前提に設計する必要があります。
詳しくは判断の軸を持つことでも整理していますので、あわせて読んでみてください。
詰まりが長引くときの判断補助：セカンドオピニオン
同じAIと同じ方向から修正を繰り返しても、前提が間違っている場合は解決しません。私は非エンジニアなので、エラーの構造を自分で判断できません。同じAI任せになると「どう直すか」だけを聞き続け、「なぜ壊れているか」を問えなくなります。
同じアプローチを3回以上繰り返して詰まっている場合、別のAIにセカンドオピニオンを求めることが有効です。目的は「別の答えをもらう」ことではなく「前提を問い直す視点を得る」ことです。
思想設計の全体像については思想設計の全体像でも確認できます。
この後どうなったか
HTTP Requestへの切り替え後、keyword_done.csvへの追記は1回で成功しました。取得：GET /drive/v3/files/{id}?alt=media、更新：PATCH /upload/drive/v3/files/{id}?uploadType=mediaのエンドポイントを直接叩く形で、バイナリの不透明さが解消されました。
n8nのワークフロー全体（インタビュー生成→本文生成→監査→リライト→WP投稿→CSV追記→Slack通知）が一通り完成しています。現時点では記事1本のテスト投稿を完了した段階で、本格稼働はこれからです。
– [ ] 本番データに対して書き込み処理を実行する前にバックアップを取っているか → NOなら今すぐバックアップを取る
– [ ] 処理がエラーなく完了したとき、データの中身を実際に確認しているか → NOなら確認の手順を自動化フローに組み込む
– [ ] 同じアプローチを3回以上繰り返して詰まっている場合、別の視点を取り入れているか → NOならセカンドオピニオンを求める
– [ ] 使っているノードの内部仕様を理解しているか → NOなら生APIへの切り替えを検討する
- ノーコードツールは非エンジニアには難しいですか？
-
使うこと自体は難しくありません。ただ「なぜ動いているか」が分からないまま進むと、壊れたときに手が止まります。「動かし方」より「なぜ動くか」を先に理解することが、詰まりを減らす近道です。
- セカンドオピニオンはどのAIに聞けばいいですか？
-
使っているAIと違うモデルであれば何でも構いません。重要なのは「別の視点」です。同じAIに同じ質問を繰り返しても同じ方向の答えが返ってきます。問い方を変えるか、モデルを変えるかのどちらかが必要です。
まとめ
今日できる小さな行動を3つ提案します。
① 今実行しているワークフローの復元手段を確認する（5分）
バックアップが取れているか、壊れたときに戻す方法があるかを確認してください。手段がなければ今日中に作ってください。
② 詰まっているノードの「内部仕様」を調べる（10分）
使っているノードが何を隠しているかを確認してください。binaryDataModeのような設定が影響している場合は、公式ドキュメントを確認することで見えてきます。
③ 同じ詰まりを3回繰り返していたら、問いを変える（即日）
「どう直すか」ではなく「なぜ壊れているか」を先に聞いてください。それでも解決しなければ、別のAIにセカンドオピニオンを求めてみてください。
関連記事
この記事を読んで「自分もどこかで同じ詰まり方をしているかもしれない」と感じた方は、判断設計の考え方を整理した無料PDFを受け取ってみてください。「何を見て、何を捨てるか」の判断軸が一枚で確認できます。
コメント