n8nでGoogle Driveのファイルを取得・保存する方法

この記事では、資料を取得して別のフォルダへ保存する小さな流れを、公開仕様に沿って説明します。Google Sheetsのセル更新や、元ファイルの上書き・移動・共有変更は、ここで扱う基本例とは別の操作です。

項目名は2026年10月31日に確認したn8n公式ドキュメントを基にしています。利用中のn8n本体・ノードの版で表示が異なる場合は、同じ役割の設定かを確かめてから進めてください。

操作と権限を決め、テスト用の対象を分ける

最初に決めたいのは、「どのアカウントで、どこから読み、どこへ保存するか」です。認証が通っていても、そのアカウントが目的のファイルを読めるとは限らず、読み取りできても新規保存できるとは限りません。

たとえば、入力用の「確認資料」フォルダと出力用の「連携テスト」フォルダを分ければ、元資料と試験用の作成物を見分けやすくなります。最初は秘密情報を含まない資料1件だけを対象にし、読み取りから始める形が扱いやすいでしょう。

基本の認証は、人のアカウント権限でアクセスするOAuth2です。n8n CloudではGoogle Drive向けのManaged OAuth2が案内されており、セルフホストではGoogle Cloud側にアプリを用意するCustom OAuth2の設定が必要になります。

ここで確認するのは、使用するCredentialと接続アカウント、要求される権限、操作対象の対応までです。Client Secretやトークンを記事・相談用ログへ貼らず、認可や期限管理の詳細は認証側の手順で整理してください。

Googleのdrive.fileで扱えるのは、アプリが作成したファイルや、ユーザーがアプリへ許可した特定ファイルなどに限られます。一方、drive.readonlyは読み取り用でも、そのユーザーが扱えるDriveファイルを広く閲覧・取得する権限です。

「読み取りだけなら狭い権限」とは判断せず、実際の認可画面で要求されるscopeを確認してください。Googleが最小権限を勧めていることと、n8nの標準Credentialで任意のscopeへ簡単に変更できることは、同じ意味ではありません。

My Drive・Shared Drive・共有されたフォルダを区別する

誰かから共有されたフォルダでも、置き場所はMy Driveの場合があります。個人のMy Driveにある共有フォルダと、組織のShared Driveにあるフォルダは、所有や検索の前提が異なる対象です。

n8nのSearchは、既定で個人のMy Driveを検索します。Shared Driveを使う場合は、フォルダ名だけでなく検索対象のDriveも合わせましょう。

Google APIにはShared Drive向けの対応パラメーターや検索条件があります。ノードが使用版で適切に扱えるかも確認対象であり、見つからないからといって公開範囲を広げる必要はありません。

Searchで候補を絞り、名前からファイルIDを確定する

検索結果の役割は、「取得してよい対象を選ぶ材料」をそろえることです。Driveでは同じフォルダ内にも同名ファイルが存在できるため、名前の一致だけで対象は確定しません。

1. 検索するDriveとフォルダを指定する

   Google DriveノードでResourceをFile/Folder、OperationをSearchに設定します。FilterのDrive・Folderを対象に合わせ、ファイルだけを扱うならWhat to SearchでFilesを選ぶ形です。

2. 候補を返し、識別に必要な項目を見る

   Search File/Folder Nameでは、検索語に部分一致する候補も返ります。少なくともID・Name・mimeTypeを確認できるようにし、ごみ箱内の項目を含める設定も見直してください。

3. 0件・1件・複数件で進み方を分ける

   候補の数だけでなく、予定したフォルダと種類に合っているかを照合します。正規のファイルIDが決まってから、次のDownloadへ渡しましょう。

説明用に、同じ「資料.pdf」がID-AとID-Bの2件見つかった場面を考えてみてください。片方が古い原稿、もう片方が配布用でも、名前の見た目だけでは区別できません。

既知のIDがあるならそれを照合し、不明なら保存場所・種類・更新情報など必要な材料を補って対象を選びます。並び順が先だからという理由で決めるのは避けたいところです。

Limitで指定するのは、返却件数の上限に当たります。Limitを1にして1件返っただけでは、ほかに一致候補がないことを証明できません。

Return Allで対象になるのも、認証主体がアクセスできる範囲です。対象を限定したうえで候補を確認し、件数制限で判断材料を隠していないか見直しましょう。

条件を細かく指定するAdvanced Searchでは、Googleの検索構文を使います。ファイル名に引用符やバックスラッシュが含まれる場合はエスケープも必要なので、任意の名前をそのままQuery Stringへ連結する設計は避けてください。

Downloadで実ファイルとGoogle文書の書出しを分ける

PDF・画像などのファイルと、Google Docs・SheetsなどのGoogle文書は、内容の取り出し方が異なります。先にmimeTypeで種類を確かめると、取得後に何が必要なのかを整理しやすいでしょう。

n8nではResourceをFile、OperationをDownloadにし、確定したファイルIDを指定します。Google文書の場合は、DownloadのOptionsにあるGoogle File Conversionで出力形式を選ぶ構成です。

たとえば、Google Docsの閲覧用コピーを次の処理へ渡すならPDFを選び、Put Output File in Fieldには後続で使うbinary欄名を設定してください。独立したExport操作を探すのではなく、現在のノードではDownload内の変換設定を確認する流れになります。

Google APIでいう通常ファイルのコンテンツ取得と、Google文書のfiles.exportは別の処理です。files.exportの書出し内容は10MBまでという制限であり、通常のPDFや画像のダウンロード上限を一律10MBとするものではありません。

大きな資料が失敗する場合は、ファイルの種類、書出し後の大きさ、n8nの実行環境や版を分けて調べましょう。閲覧できる資料でも所有者や組織がダウンロードを制限していることがあり、Googleはcapabilities.canDownloadの確認を案内しています。

Google DocsのPDF化は、文書編集や完全バックアップとは別

PDFへの書出しは、その形式で内容を利用するための処理です。元のGoogle Docsが持つ共同編集の状態、コメント、履歴、共有権限まで含めた完全な複製にはなりません。

配布用の閲覧資料がほしいならPDFが候補になります。一方、元の文書本文を書き換えたい場合はGoogle Docs側の編集設計が必要で、ファイル取得の設定だけでは目的が異なるでしょう。

Google SheetsをCSVやExcel形式へ書き出す場合も、セルをキーに取得・更新する操作とは別です。タブや数式、配置などが必要な形で残るかを、実際の受け側で確認してください。

binary欄を合わせ、テストフォルダへ新規保存する

Downloadの後にUploadを置くときは、出力と入力のbinary欄名をそろえるのが要点です。ファイルIDや名前がJSONに入っていても、それだけでアップロードする中身が渡っているとはいえません。

1. Downloadの出力を確認する

   対象itemに予定したbinary欄があり、ファイル名・MIME typeと実体が対応しているかを確認します。閲覧用URLやファイル名だけのJSONを、実ファイルと取り違えないでください。

2. Uploadの入力と保存先を決める

   ResourceをFile、OperationをUploadにして、Input Data Field Nameを取得側とそろえます。Parent Drive・Parent Folderはテスト先へ固定し、新しいファイル名にも試行を識別できる情報を付けましょう。

3. 新規作成1件の応答を残す

   秘密を含まないテスト資料で保存し、応答の新規ファイルIDを記録します。次の確認に使うため、出力を簡略化してID等が見えない場合は返却項目も確認する形です。

途中の整形ノードを通した後でbinary欄がなくなったら、Uploadの設定だけを変えても解決しません。どのノードのどのitemから実体を渡すのか、対応が途切れた位置まで戻って調べます。

UploadとUpdateを分け、同名だけで上書きしない

Uploadは新規保存であり、同じ名前を指定しただけで既存ファイルを上書きする操作ではありません。既存物を変更するUpdateでは対象ファイルを指定でき、内容を置き換える設定も用意されています。

事前に同名を検索するだけでは、並行実行による重複を完全には防げません。定期実行へ広げるときは、同じ入力を処理した記録や実行の重なりも含めて再試行の扱いを決めましょう。

保存先・内容・共有範囲を読み戻して完了を確かめる

ノードの成功表示は、意図した内容が正しい場所に保存されたことを、人が確認した記録とは別です。返却されたIDから保存物をたどり、次の確認を終えたところを完了にしましょう。

• 保存されたファイルIDが、この試行で返ったIDと一致している
• 親フォルダとDriveが、予定したテスト保存先になっている
• ファイル名・種類・出力形式が、受け側の用途に合っている
• 必要な本文・ページ・画像などが実際に読める
• 元ファイルの内容・所在・共有設定を意図せず変えていない
• 保存物の閲覧範囲が、予定したフォルダや組織の設定に合っている

「名前は正しいが別フォルダにある」「PDFは開けるが必要なページが欠けている」といった状態では、後続へ進める材料が足りません。存在と形式の確認に加え、必要内容を読めるかまで見るのが大切です。

同じ形式の通常ファイルをそのまま受け渡す場合は、対応するチェックサムが比較材料になることもあります。ただし、Google DocsをPDFへ書き出した前後のように表現が変わる処理では、同一hashを求める確認は適しません。

webViewLinkなどの返却URLは、ファイルを開くための入口です。URLの返却だけではAnyoneへの公開や閲覧権限の付与を意味しないため、アクセスできる人の範囲は共有権限として別に確認してください。

記録には必要な識別情報だけを残し、資料本文や認証情報を過剰に実行ログへ出さない形にします。取得した画像をWordPressへ送りたい場合も、まずここまでの保存確認を終え、メディア登録や下書き保存・再試行の設計へ進む順序です。

権限・形式・データ欄のエラーを切り分けて後片付けする

止まったときは、認証を作り直す前に「どこまではできたか」を残してください。一覧・取得・保存は必要条件が違うため、同じエラー対処を当てはめるより、直前の出力から分けるほうが原因を絞れます。

401・403・404というHTTPコードだけで、すべての原因を確定することはできません。Googleのエラー理由も併せて読み、404でも「存在しない」だけでなく、そのアカウントからアクセスできない場合があると考えて調べましょう。

サービスアカウントで保存に失敗した場合も、人のOAuth2と同じ前提にはできません。Googleはサービスアカウントにストレージ割当がなくファイルを所有できないと案内しており、Shared Driveへの保存か、人の代理でのOAuth2による処理を区別する必要があります。

フォルダを共有するだけで、個人のMy Driveへ新規保存できると一般化しないでください。広い代理権限を持つドメイン全体の委任を、初歩的な接続エラーの簡単な解決策として追加するのも適切ではありません。

管理者に相談するときは、利用版、認証方式、止まった操作、秘密を除いたエラー理由、対象Drive・フォルダ・ファイルの識別情報を必要な範囲で共有します。認証JSONやClient Secret、トークンをそのまま渡す必要はありません。

試験を終えるときは実行を止め、不要な作成物をこの試行のIDで限定して整理してください。元資料や同名ファイルの一括削除、ほかの処理でも使うCredentialの無条件失効を、定型の後片付けにはしない方針です。

まとめ｜ファイルIDと形式をそろえ、保存結果まで確認する

n8nとGoogle Driveの連携は、対象アカウント・Drive・フォルダを決め、SearchでIDと種類を確認するところから始めます。Downloadで必要な実体を取得し、Google文書なら出力形式を選び、binary欄をそろえたUploadの保存結果まで照合する流れです。

次は、秘密を含まないテストファイル1件と、元資料から分けた保存先を用意しましょう。入力ID・種類・出力形式・binary欄・保存先IDを対応させ、まず読み取り結果を確かめてから、新規保存1件へ進めてください。

ノードをつなぐこと以上に、何を、どの形で、どこへ渡したかを追える状態が継続運用には役立ちます。名前や成功表示だけで判断を終えず、IDと内容を確かめる小さな確認を残すことは、後の切り分けにも役立つ運用上の工夫です。