n8nでGoogle DriveのCSV更新が壊れる原因と解決法【HTTP Request + Drive API】

alt=mediaを付けることが重要です。これを省略するとファイルのメタ情報だけが返ってきて、中身が取得できません。

取得結果は$json.dataにテキストとして入ります。

2. CSVに追記する（Codeノード）

const prev = $('05_finalize').first().json;
const doneLine = prev.done_line + ' | ' + prev.moved_at;

const existing = $('keyword_done.csv 取得').first().json.data
  .replace(/\r\n/g, '\n')
  .trimEnd();

const newContent = existing + '\n' + doneLine;

return [{ json: { updated_csv: newContent } }];

replace(/\r\n/g, '\n')で改行コードを統一しておくことで、文字化けを防げます。

3. CSVを更新する（PATCHリクエスト）

HTTP Requestノードの設定：

• Method：PATCH
• URL：https://www.googleapis.com/upload/drive/v3/files/{fileId}?uploadType=media
• Authentication：Predefined Credential Type → Google Drive OAuth2 API
• Body Content Type：Raw
• Content Type：text/plain
• Body：{{ $json.updated_csv }}

PATCHが正しいメソッドです。PUTではファイルを置き換えるのではなく更新情報が届かないことがあります。

ハマりやすいポイントと対処法

実際に試してみると、いくつかつまずきやすい箇所があります。

exportエンドポイントは使えない

/drive/v3/files/{fileId}/exportはGoogle DocsやSheetsのエクスポート専用です。通常のCSVファイル（Driveにアップロードしたファイル）には使えず、403エラーが返ってきます。

/drive/v3/files/{fileId}?alt=mediaが正しいエンドポイントです。

PATCHのURLにuploadTypeが必要

更新時のURLは/upload/drive/v3/files/{fileId}?uploadType=mediaです。/upload/と?uploadType=mediaの両方が必要で、どちらか一方でも欠けると400エラーになります。

Content-Typeにtext/plainを指定する

text/csvでも動きますが、text/plainの方が安定していました。ヘッダーにContent-Type: text/plainを明示的に指定してください。

判断基準：

• 403エラーが出た → exportエンドポイントを使っていないか確認する
• 400エラーが出た → URLに/upload/と?uploadType=mediaが両方あるか確認する
• 更新後にデータが化ける → Content-Typeを明示的に指定する

この後どうなったか

HTTP Requestへの切り替え後、CSV更新は1回で成功しました。

取得時に$json.dataでテキストが正しく取得できていること、更新後にファイルを開いて内容が正しく書き込まれていることを確認しました。Google Driveノードのときに起きていた「エラーなく壊れる」問題は完全に解消されました。

n8nのワークフロー全体（インタビュー生成→本文生成→監査→リライト→WP投稿→CSV追記→Slack通知）はこの修正を経て一通り完成しています。現時点では記事1本のテスト投稿を完了した段階で、本格稼働はこれからです。

まとめ

n8nでGoogle DriveのCSV更新が壊れる場合、原因はbinaryDataMode: filesystemの設定にあることが多いです。Google Driveノードのバイナリ処理がエラーなく失敗するため、発見が遅れやすい問題です。

解決策はHTTP RequestノードでDrive APIを直接叩くことです。

• 取得：GET https://www.googleapis.com/drive/v3/files/{fileId}?alt=media
• 更新：PATCH https://www.googleapis.com/upload/drive/v3/files/{fileId}?uploadType=media
• 認証：Google Drive OAuth2 API（n8nのPredefined Credential Type）

今日できる一歩として、まず取得ノードだけをHTTP Requestに切り替えて、$json.dataにCSVの内容が正しく入るかを確認してみてください。それが確認できれば、更新ノードへの切り替えも同じ方法で進められます。

ここまでの内容で、CSV更新の原因と解決の方向性は整理できたと思います。
ただし、このままだと「どの条件が揃ったらノードを捨ててAPIに切り替えるか」は自分では判断できません。
なぜなら、ツールの抽象化をどこまで信頼するかという判断軸が、まだ整理されていないからです。

今回の詰まりを「n8nの使い方の問題」で終わらせると、別のノードで同じ状況になったときに同じ詰まりを繰り返します。「どのタイミングでノードを捨てるか」という判断の記録をノーコード自動化でデータが壊れた記録【抽象化を捨てた判断基準】にまとめています。あわせて読んでみてください。