Google Drive APIのfiles.exportが大きなDocsで失敗するとき、10MB上限と別の取得方法を確認する

Google DocsをDrive APIからPDFやWordなどへ変換して受け取るとき、files.exportが失敗したなら、まず見るのはDocsファイルの保存容量ではなく、指定した形式で生成される出力データです。

確認日 2026年10月17日AIものさし編集部

Google DocsをDrive APIからPDFやWordなどへ変換して受け取るとき、files.exportが失敗したなら、まず見るのはDocsファイルの保存容量ではなく、指定した形式で生成される出力データです。Drive APIのfiles.exportは、エクスポートした内容に10 MBの上限があります。これはGoogle Driveの保存容量や、元のDocsのバイト数を表す制限ではありません。10 MBを超える結果を同じfiles.exportで何度も再試行しても解決しません。

最初に確認したいのは「どのAPIで、何を、どの形式にして取得しようとしたのか」です。ファイルの保存容量、export結果、本文構造の取得は別の話です。PDFを必要としているのか、プログラムで本文を処理したいのかによって、安全な代替手段も変わります。

先に結論：エラーと必要な成果物を分ける

Google Drive APIのfiles.exportは、Google Workspace文書を指定したMIME typeへ変換し、その出力バイトを返すAPIです。公式リファレンスは、エクスポート内容の上限を10 MBとしています。したがって、エラーがサイズ上限を示しているときは、同じfileId・同じMIME typeでの即時再試行を止め、出力形式や取得目的を見直します。

ただし「大きなDocsなら別の一つのAPIで必ず同じPDFを取得できる」とは言えません。Drive APIにはfiles.downloadという長時間処理（Long-running operation、LRO）を使うダウンロード経路があり、Google Workspace文書も対象に含まれ、MIME typeを指定できます。これはfiles.exportとは別のエンドポイントです。公式資料はfiles.exportの10 MB制限とfiles.downloadのLRO手順を説明していますが、すべての文書・形式で上限を回避できるという保証までは明記していません。利用前に対象ファイル、要求形式、権限、APIの応答を確認し、実環境で成立するか検証してください。

まず診断する4つのサイズ

「ファイルが大きい」という一言で、次の値を混ぜないようにします。

表は横にスクロールできます

確認対象	何を表すか	どこで確認するか
Drive上の元ファイル	DocsというWorkspace文書のメタデータや保存状態	Driveのfiles.getで取得するメタデータ。元文書のサイズがexport結果と同じとは限らない
files.exportの出力	要求したMIME typeに変換されたバイト列	exportの成功応答サイズ、またはサイズ上限を示すAPIエラー
files.downloadの出力	LROで生成される指定形式のファイル	download操作の状態、完了後のdownload URI、取得した出力サイズ
documents.getの構造データ	Docs APIが返す本文要素や段落などの構造	Docs APIのdocuments.get。レンダリング済みPDFやWordの代わりではない

PDFは改ページ、フォント、画像、表のレイアウト情報を含みます。プレーンテキストや構造化データとは生成物が違うため、同じ文書でも出力サイズや用途が変わります。形式を変えるのは単なる通信上の小細工ではありません。読者に渡すべきレイアウトが必要なら、内容の欠落や表示差を確かめずにテキストへ置き換えないでください。

エラーを見分ける

実装ログから、HTTPステータス、Google APIのerror.status、error.message、要求したendpoint、MIME type、fileId、操作時刻を確認します。アクセストークン、認証ヘッダー、文書本文や機密URLはログへ残しません。

サイズ制限に関する明示的なエラーなら、原因は要求されたexport結果にあります。同じ条件でリトライし続けず、出力形式・文書範囲・処理方式を選び直します。一方、429や一時的な5xx、接続切断などは別の失敗です。APIのレート制限とRetry-Afterなどの応答、指数バックオフの実装契約を確認してから、待機付き再試行を検討します。認証・権限エラーならOAuth scope、対象ファイルへのアクセス、ダウンロード制限を確認します。サイズ超過、権限不足、レート制限をすべて「時間が経てば直る失敗」とまとめてはいけません。

診断ログには少なくとも次を残すと、別の担当者が状況を再現しやすくなります。

呼び出したAPI名（files.export / files.download / documents.get）
Google WorkspaceのmimeTypeと、指定した出力MIME type
APIのHTTP statusと機械可読なerror.status / message
再試行した回数と間隔
LROならoperation name、done、errorまたはresponseの有無
出力のバイト数、ハッシュ、保存先の一時ファイル名
検証した内容の件数（ページ、段落、表、添付画像など、用途に応じた項目）

ファイル本文、OAuth token、個人情報を含む段落そのものを診断用ログにコピーする必要はありません。識別子もログの閲覧範囲や保持期間を確認したうえで扱います。

取得目的から経路を選ぶ

PDFやWordの完成ファイルが必要

まずfiles.exportで指定形式の出力を要求していることを確認します。公式のMIME type一覧にDocsで利用できる形式が載っているかを確認し、実際のコードのmimeTypeと一致させます。たとえば「PDFが必要」と言いながらDOCXのMIME typeを指定する実装ミスは、サイズ問題とは別です。

export結果が10 MB上限で拒否される場合、Drive APIのfiles.downloadによるLROを検討できます。Googleの公式ガイドはWorkspace文書についてもこの経路を示し、mimeTypeを指定できると説明しています。大まかな手順は、downloadを開始してoperation名を保存し、operations.get相当で状態を確認し、完了後に返るdownload URIから出力を取得する流れです。operationは最低12時間利用可能ですが、場合により長く継続し、ファイル種別によって異なります。この期間は変更される可能性があるため、実際のoperation状態と期限を確認し、長時間放置せず処理状態を監視します。

ただし、LROを使えば同じ出力を必ず取れる、またはfiles.exportのサイズ上限を必ず超えられる、と前提化しません。対象文書と必要MIME typeでテストし、完了応答にエラーがないこと、URIから取得できること、出力サイズとファイル形式が期待どおりであることを確認します。要求したrevisionIdがサポートされない場合はINVALID_ARGUMENTになり得ます。最新版を取得するのか、特定revisionを再現するのかも先に決めてください。認証・ファイル共有のresource keyが必要なケースでは、operation開始と最終ダウンロードの両方で適切に渡します。

本文を処理するだけならDocs APIの構造データ

アプリケーションが必要としているのがPDFの見た目ではなく、本文、見出し、表などの内容なら、Docs APIのdocuments.getで構造化された本文要素を読む方法があります。これはPDFを分割して取得する機能ではなく、文書の要素をデータとして処理する別経路です。表やリストを保持してWeb表示へ変換したい場合に向きますが、ページ組版や余白、改ページを再現する出力にはなりません。

構造データを使う実装では、段落・表・リスト・リンクなど必要な要素を明示的に扱います。段落テキストだけを連結して済ませると、表の行列関係、見出し階層、脚注、画像、ハイパーリンク、段落属性が落ちることがあります。本文の順序と境界を保てるか、空段落をどう扱うか、未対応要素を検知できるかをテストしてください。完全なコピーが求められる業務なら、構造データ取得とPDFエクスポートを同一視しないことが重要です。

文書を小さくする必要がある

PDFの画像や複雑なレイアウトがサイズに影響していそうでも、元データを削ってから再出力する前に、必要な範囲を見直します。大きな画像が本文の結論や証拠として必要なら、無断で除外しません。非本質的な高解像度画像を圧縮できるか、必要ページだけ別の文書へ分けられるか、複数形式のうち品質を保てるものがあるかを、文書の所有者と確認します。

段落範囲を手作業で複製する方法は、リンク先・注釈・表・見出し・コメント・脚注の関係を失う可能性があります。分割する場合はコピー後の文書を別ファイルとして作り、原本は保持します。ページ範囲、表の途中で切れていないか、画像の説明、見出しの親子関係を確認し、対象者がその分割版を正式成果物として使ってよいか承認を得ます。機械的に「先頭だけ」「本文だけ」と切り出すのは、読者や後続処理が必要とする文脈を欠落させるため避けます。

実行前チェックリスト

以下を順番に確認します。

対象のGoogle Docs fileId、所有者、MIME type、ダウンロード可能性を確認する。
生成したい成果物を特定する。PDFの見た目、DOCX、本文テキスト、見出し・表などの構造データは別の成果物。
endpointを確認する。files.exportなのか、files.downloadなのか、Docs APIなのか。
出力MIME typeが目的と一致し、そのGoogle Workspace文書で対応しているか確認する。
error.statusとmessageから、10 MBのexport上限、権限、対象形式、レート制限、一時障害を区別する。
失敗分類に応じて取得経路を選ぶ。サイズ上限なら同じexportを繰り返さない。
原本のrevisionを記録する。LROが対象revisionを扱えるか、APIの制約も確認する。
代替経路を試す前に、同じ内容・同じ用途が保持できるかテストケースを作る。
出力後にファイルが開くか、MIME type、バイト数、ページや本文の完全性を検証する。
不完全な出力や検証失敗時は、下流システムへ渡さず、原本を保持して原因を記録する。

出力後に欠落を見つけた場合

HTTP 200だけで成功とは判定しません。出力ファイルが空でないこと、拡張子と実際のMIME typeが一致すること、PDFならページ数や文字抽出を確認できること、本文処理なら段落・表・リンクなど必要要素が残っていることを確認します。原文にあった件数・識別子など、利用目的に合う整合性チェックを入れると、途中で切れた出力を見つけやすくなります。

ハッシュを記録するなら、比較対象を決めてください。Drive上のDocs本体と、PDFへレンダリングした出力のSHA-256は異なるのが当然です。異なるハッシュを「破損」と判断するのではなく、同じexport成果物の再取得間で変化がないか、同じrevision・同じ形式を扱っているかなど、意味のある比較に使います。

失敗パターン別の次の一手

表は横にスクロールできます

症状	最初に確認すること	次に進める方法
exportが10 MB上限で失敗	endpoint、mimeType、エラー内容	LROのfiles.downloadを対象形式で検証。出力が必要な理由に応じて別経路を選ぶ
401 / 403	OAuth scope、ファイル権限、ダウンロード可否	権限を勝手に広げず、所有者・管理者へ必要な最小アクセスを確認
404	fileId、削除・移動、共有対象	Drive上の現行IDと共有状態を確認。類似タイトルを代用しない
429 / 5xx	API応答、レート制限、Retry-After	一時障害と確認できた場合のみ待機後再試行。永久的なサイズ制限に適用しない
出力は取れるが本文・表が欠ける	取得経路、形式、変換処理	未対応要素と変換ロジックを調べ、原本を残して変換テストを直す
LROが完了しない	operation name、done、エラー、実際の期限（最低12時間。ファイル種別で異なり、変更される可能性あり）	固定の24時間期限を前提にせずoperationを監視し、期限前に完了可否を判断。新しい処理を無制限に起動しない
形式が要求と違う	MIME type、ファイル拡張子、実ファイルの識別	MIMEと出力名を整合させ、後続で安全に開けることを確認

運用に入れる前の小さなテスト

本番文書を大量に処理する前に、機密性の低いテスト文書で経路ごとの結果を確認します。短い文書だけでは上限や遅延を再現できません。現象が出るサイズ帯に近いテストデータを用意し、文書内容や画像をコピーする場合は利用許可を確認してください。

テスト表には、fileId（テスト用）、revisionId、API、mimeType、HTTP status、operationの状態、出力バイト数、検証結果を記録します。PDFとDOCXをそれぞれ試すなら、出力形式ごとに別行にし、比較したサイズがどの値かを明記します。サイズを変えたことで生成物が同一とは限らないため、正確なバイト数や視覚上の同一性を事前に仮定しません。

サイズ上限に該当した際の処理は、アプリのエラーハンドリングにも反映します。利用者に「時間を置いて再試行」とだけ案内すると、同じ条件で永久に失敗する可能性があります。代わりに、要求形式を確認し、代替取得手段を案内し、必要なら文書管理者へ範囲や形式の変更を相談するよう示します。テキスト抽出へ切り替える場合は、PDFのページ配置が必要かを先に問い直してください。

まとめ：サイズではなく必要な成果物で判断する

10 MBという数値は、Drive APIのfiles.exportが返す変換後コンテンツに対する上限です。元のDriveファイルの保存容量やGoogle Workspaceのストレージ割当と混ぜないでください。まずendpoint、MIME type、APIエラーを特定し、必要な成果物がレイアウト済みファイルなのか、本文の構造データなのかを決めます。

PDFやDOCXが必要ならfiles.downloadのLROを現在の公式仕様と対象文書で検証します。ただし、files.exportの上限を必ず回避する保証があると決めつけません。内容処理が目的ならDocs APIの構造データが候補ですが、ページレイアウトとは別物です。どの経路でも、変換後の件数・表・リンク・ファイル形式を検証してから下流へ渡します。

Sources

Editorial Notes

Fact status: Google公式資料を2026-10-15に確認。files.exportの10 MB出力制限、files.download LROによるWorkspace文書の取得、MIME type指定、operationの有効時間を確認。LROが10 MB制限を必ず回避するとは書かず、対象文書・形式で検証する条件付き経路とした。API実測・大容量出力のhands-onは未実施。Reader JobはAPIエラーを分類し、出力形式・取得方式を選び、完全性を検証してから下流へ渡すこと。