bbizinets.life
n8nとGoogleドライブを連携できない原因|403・認証エラーで詰まった実践ログ
実践ログ

n8nとGoogleドライブを連携できない原因|403・認証エラーで詰まった実践ログ

# n8nとGoogleドライブを連携できない原因|403・認証エラーで詰まった実践ログ

n8nとGoogleドライブの連携でエラーが出た場合、まず確認するべきは3つです。

  • バイナリデータの扱い(filesystem-v2)
  • Search APIのパラメータ
  • フォルダ構造の認識

この3つを見れば、多くのエラーは切り分けできます。

私自身、403エラーやデータ取得失敗で止まりましたが、最終的に48件のmeta.json取得まで到達しました。この記事では、実際に詰まったポイントと、その対処をすべて記録しています。

n8nエラーの切り分けはこの3つで判断する

n8nとGoogleドライブの連携でエラーが出たとき、「どこを見ればいいか」が分からないと時間だけが過ぎていきます。私が今回詰まった箇所は大きく3つに分類できました。同じ状況で止まっていませんか?

① データが取れない場合(filesystem-v2)

Download fileノードは成功しているのに、次のCodeノードでデータが空になるパターンです。原因はn8nの新しいバイナリ管理方式にあります。詳細は後述します。

確認ポイント: binary.data.dataの値が"filesystem-v2"になっていないか

→ なっていればExtract from Fileノードを追加する

② APIエラーが出る場合(Search API)

「Bad request - Invalid Value」や「403」が返ってくるパターンです。GoogleドライブのSearch APIはFilterパラメータの組み合わせが独特で、エラーメッセージから原因を特定しにくいです。

確認ポイント: FilterのDriveフィールドが設定されていないか

→ My Driveを使う場合はDriveフィールドは不要。Filterごと削除する

③ ファイルが見つからない場合(構造ミス)

Queryは正しいのに結果が0件になるパターンです。フォルダの構造を正確に把握せずに設計していると起きます。

確認ポイント: 対象ファイルが想定どおりのパスに存在するか

→ MCPやGoogleドライブのUIで実際の構造を確認してから設計する

今回構築しようとしたワークフローの全体像

私が今回n8nで構築しようとしたのは、bizinets.bizの記事制作を自動化するパイプラインです。どんなフローを組もうとしていたか、まず全体像を共有します。

大まかな流れはこうなります。

  1. Googleドライブのkeyword_queue.csvからキーワードを1件ピック
  2. manifest.csvに書き出す
  3. create-article.txt・internal_links.csv・title_and_intro_rules.mdを並列で読み込む
  4. articles配下の全meta.jsonを読み込んで投稿済み判定を行う
  5. OpenAI APIで市場調査・記事設計
  6. Claude APIでインタビュー3問生成
  7. Slackにインタビューを送信→回答を受け取る
  8. Claude APIで本文生成・監査
  9. WordPressにdraft投稿

現在のClaudeとのチャット上で行っているパイプラインを、そのままn8nに移植する形です。このうち今回動かせたのはSTEP1〜4の途中まで、つまりGoogleドライブ周りのデータ取得部分です。

最初の壁:バイナリデータがfilesystem-v2になっていた

keyword_queue.csvをGoogleドライブからDownloadするノードは問題なく動きました。ファイルサイズ17.1kB、mime typeもtext/csvと表示されています。「これは動いた」と思ったのですが、次のステップで困りました。

次のCodeノードでCSVを読み込もうとすると何も取れませんでした。

const csvText = Buffer.from(item.binary.data.data, 'base64').toString('utf-8');

このコードを実行すると、csvTextは空になります。デバッグしてbinary.data.dataの中身を確認すると、こう返ってきました。

"data": "filesystem-v2"

Base64でエンコードされたCSVデータが入っているはずの場所に、filesystem-v2という文字列があるだけでした。

正直、この時点では「設定は合っているはずなのに、なぜ動かないのか分からない」という状態で、かなり時間を消費しました。

原因はn8nのバイナリデータの扱いにありました。実際のデータはn8nの内部ストレージに保存され、参照IDとしてfilesystem-v2が渡される仕組みになっていたのです。つまり、n8n×Googleドライブ連携においてCodeノードから直接バイナリを読み取ることができなくなっていました。

解決策はCodeノードの前に「Extract from File」ノードを挟むことです。

  • Operation:CSV
  • Input Binary Field:data
  • Delimiter: | (スペース・パイプ・スペース)

これを追加することで、145件のキーワードが正常にパースできるようになりました。ここはホッとした瞬間でした。

ここまでで「何が起きているか」の構造は見えてきました。
ただし、このままだと自分のプロジェクトでどの順番でノードを組むべきかは判断できません。
なぜなら、「どのノードが何を担当するか」という設計の判断基準がまだ整理されていないからです。

→ 判断軸の整理はこちら

n8nの403エラーが出たときに最初に確認するポイント

n8nで403エラーが出た場合、まず疑うべきは「認証」ではなく「Search APIのパラメータ設定」です。

meta.jsonを取得するために「Search files and folders」ノードを使いました。articlesフォルダ配下のサブフォルダを一覧取得し、そこからmeta.jsonのファイルIDを取得しようとした流れです。同じ場所で詰まっている方はいませんか?

n8nのエラー対処でよく詰まるのがこのSearch API周りです。最初に試みた設定はこうでした。

  • Drive:By ID → フォルダIDを入力
  • Query:name = 'meta.json'

結果は「Bad request - Invalid Value」でした。

次にDriveの設定を「From list → My Drive」に変えて試しましたが、同じエラーが返ってきました。FilterのDriveフィールドとFolderフィールドの組み合わせが原因でしたが、エラーメッセージからはその情報は読み取れませんでした。

試行錯誤の末に気づいたのは、DriveフィールドはShared Drive(共有ドライブ)専用のフィールドで、個人のMy Driveでのn8n×Googleドライブ連携には不要だということです。

正しい設定はこうなります。

  • Resource:File/Folder
  • Operation:Search
  • Search Method:Advanced Search
  • Query String:'[フォルダID]' in parents and mimeType = 'application/vnd.google-apps.folder'
  • Drive:設定不要(Filterごと削除)
  • Return All:ON

この設定で49件のサブフォルダIDが取得できました。

meta.jsonが取れなかった理由はフォルダ構造の理解不足だった

49件のフォルダIDが取れた後、続けて各フォルダのmeta.jsonを取得しようとしました。ここで自分の思い込みに気づかされました。

articlesフォルダの構造についての理解不足が発覚したのです。私はmeta.jsonがarticlesフォルダの直下にあると思い込んでいました。実際の構造はこうなっています。

articles/
  └── 2026-03-14__kw-decision-to-discard/
        ├── article.md
        └── meta.json
  └── 2026-04-26__kw-free-to-paid-tool-decision/
        ├── article.md
        └── meta.json

つまり、meta.jsonはarticlesフォルダの直下ではなく、日付とslugで構成されたサブフォルダの中にあります。この構造を把握せずに設計していたため、Search APIのQueryが正しく組めていませんでした。

構造を理解してから改めて設計すると、必要なのは2段階の検索です。

  1. articlesフォルダ直下のサブフォルダIDを全件取得
  2. 各サブフォルダIDを使ってmeta.jsonのファイルIDを取得

この流れで、48件のmeta.jsonファイルIDが取得できるところまで到達しました。

詰まったまま続けるより一度止まる判断をした

48件のファイルIDが取得できた時点で、本日の構築作業を一度止めることにしました。この判断は正解だったと思います。

理由は2つあります。

1つ目は、meta.jsonの中身(wp_post_id)を取得してMergeノードで統合するまでの工数が、その日の残り時間に対して多すぎると判断したからです。詰まりながら進めると設定ミスが増え、デバッグに余計な時間がかかります。

2つ目は、詰まっている時間を記事執筆に転用できると気づいたからです。今日起きたエラーと対処のプロセスは、そのまま実践ログの素材になります。構築が止まっている時間をコンテンツ制作に使う方が、全体のアウトプットとして見たときに効率がいいと判断しました。

「詰まったら止まる」は後退ではありません。何のために自動化しているかを忘れなければ、止まることも設計のうちです。

まとめ

今回の内容は以下の3つで整理できます。

  • filesystem-v2:Codeノードから直接読めない。Extract from FileノードをDownloadの直後に追加する
  • n8nの403エラー・Search API:DriveフィールドはShared Drive専用。FilterのDriveフィールドを削除してQueryだけで検索する
  • meta.jsonのフォルダ構造:日付+slugのサブフォルダ内にある。2段階の検索(フォルダID取得→meta.json取得)が必要

次回は、48件のmeta.jsonの中身を取得してMergeノードに統合し、OpenAIの市場調査ノードへ渡すところから再開します。同じところで詰まっている方は、ぜひこの記事の判断基準を参考にしてみてください。

ここまでの内容で、起きたエラーと対処の方向性は整理できたと思います。
ただし、このままだと同じエラーが別の場所でまた出るかどうかは判断できません。
なぜなら、「設定」ではなく「設計」の判断基準がまだ整理されていないからです。

→ 判断軸の整理はこちら

bizinets.biz

記事を読んで「もっと知りたい」と思ったあなたへ

bizinets.biz では、ビジネスの仕組みづくりを体系的に学べるコンテンツを用意しています。まずは一度、覗いてみてください。

bizinets.biz へ行く →

関連記事