【比較】GASでローカルファイルを取り込む、Drive経由方式とクライアント側パース方式はどちらを使うべき？

記事内には広告が含まれます

2026年9月1日

GASでローカルファイルを取り込む2方式（Drive経由方式 vs パース方式）を比較

はじめに

前々回のDrive経由方式でアップロード→自動変換→転記する記事 (gas-07)では、選択したファイルをいったんGoogleドライブにアップロードしてスプレッドシート形式に自動変換するDrive経由方式を検証しました。前回のクライアント側パース方式でブラウザ内変換→転記する記事 (gas-06)では、ブラウザ側のSheetJSライブラリでその場でファイルをパースするクライアント側パース方式を実機検証しました。どちらも同じ「GASにはVBAのGetOpenFilename/FileDialogのような、ローカルファイルを直接開く仕組みがない」という制約への対処法ですが、実装のしやすさ・必要な権限・処理速度・対応できるデータの性質はかなり異なります。

今回はこの2方式を横並びで比較し、どちらをどんな場面で使うべきかを整理します。

注意： 本記事は新しい実機検証を行うものではなく、前々回の記事(gas07)と前回の記事(gas06)で実際に確認した内容をもとにした比較・整理の記事です。数値や挙動の出典は各記事の該当セクションを参照しています。

前回までの記事：

GASでローカルファイルを取り込む｜Drive経由方式でアップロード→自動変換→転記する — Googleドライブを経由してスプレッドシート形式に自動変換する方式を検証した記事
GASでローカルファイルを取り込む｜クライアント側パース方式でブラウザ内変換→転記する — ブラウザ側のSheetJSライブラリでその場でパースする方式を検証した記事
【Excel VBA】ファイルを開いてデータを取得する（その１）・（その２） — VBAでの元の実装方法を解説した記事

前回までのおさらい：どちらもVBAにはない発想への対処

VBAではApplication.GetOpenFilenameやFileDialogを使えば、ローカルPCや社内サーバー上のファイルを直接指定して開けます。ところがGASはブラウザ上で動くサンドボックス環境（外界と隔離され他には影響が出ない環境）のため、スクリプト側からローカルのファイルシステムに直接アクセスすることができません。

この制約に対して、2つの記事はそれぞれ異なるアプローチを取りました。

項目	Drive経由方式（gas-06）	クライアント側パース方式（gas-07）
変換処理を行う場所	サーバー側（Googleドライブ・Drive API）	クライアント側（ブラウザのJavaScript）
Excel/CSVの中身を読み取る主体	Googleドライブの自動変換機能	SheetJSライブラリ
Googleドライブを経由するか	する（一時ファイルを作成）	しない

どちらも「HTMLフォームの<input type="file">でファイルを選択し、google.script.runでサーバー側に渡す」という前半部分は共通していますが、中身をどこで・何を使って読み取るかが根本的に異なります。

比較①：実装のしやすさ

項目	Drive経由方式（gas-06）	クライアント側パース方式（gas-07）
新規に覚える概念	Advanced Google Services（Drive API）、`Drive.Files.create`	ブラウザ側ライブラリ（SheetJS）のCDN読み込み、`FileReader`でのパース
事前準備	Drive APIをv3で追加する必要あり（v3が選択肢に出てこない場合は`appsscript.json`の直接編集が必要になることがある）	HTMLファイルの`<head>`にCDNの`<script>`タグを1行追加するだけ
サーバー側の処理	Base64デコード→Blob化→Drive変換→データ取得→書き込み→一時ファイル削除と工程が多い	受け取った配列を`setValues()`するだけとシンプル
VBAでの近い操作感	「ツール→参照設定」で外部ライブラリを追加する操作に近い	該当する概念がVBAにはない（ブラウザという実行環境自体がVBAには存在しないため）

VBAとの対比： Drive経由方式のAdvanced Google Services追加は、VBAで外部の型ライブラリを「参照設定」で組み込む操作に近い感覚です。一方クライアント側パース方式のCDN読み込みは、VBAには対応する概念自体がありません（VBAはローカルのExcelプロセス内で完結するため、外部のJavaScriptライブラリをその場で読み込むという発想が存在しないためです）。

実装コストだけで見ると、クライアント側パース方式のほうが準備・サーバー側コードとも軽量です。Drive APIの有効化という、GASに不慣れな読者がつまずきやすい準備手順が不要な点は大きな差です。

比較②：必要な権限・後片付けの有無

項目	Drive経由方式（gas-06）	クライアント側パース方式（gas-07）
Driveへのアクセス権限	必要	不要（実機確認済み）
一時ファイルの後片付け	必要（`Drive.Files.remove()`で完全削除。ゴミ箱にも残らないことを確認済み）	そもそも発生しない（ブラウザのメモリ上だけで処理が完結）

VBAとの対比： VBAでファイルを開く操作は、基本的に「開いて読んで閉じる」だけで後片付けの概念がほぼありません。Drive経由方式で必要な「一時ファイルを確実に削除する」という工程は、クラウド上に痕跡を残さないための後片付けというクラウド実行特有の配慮であり、VBAの感覚からするとひと手間多く感じられるはずです。

比較③：処理速度の実測値

同一のCSVファイル（995KB・32,486行×2列）で比較すると、クライアント側パース方式のほうが高速でした。

方式	所要時間
Drive経由方式（gas-06）	約14秒
クライアント側パース方式（gas-07）	9.0秒

25万行規模のExcelファイルでも、同一ファイル（250,292行・.xlsm・約17.9MB）で条件をそろえて両方式を計測したところ、小規模CSVと同じ傾向が確認できました。

方式	所要時間（複数回計測）
Drive経由方式（gas-06）	205.6秒／231.4秒（平均約218秒）
クライアント側パース方式（gas-07）	177.3秒／169.8秒／172.9秒（平均約173秒）

小規模なCSVでも25万行規模のExcelファイルでも、クライアント側パース方式のほうが一貫して高速という結果になりました（25万行規模では平均で約45秒、割合にして約2割の差）。いずれの方式も複数回計測すると数十秒単位のブレが生じるため1回ごとの数値に一喜一憂する必要はありませんが、「クライアント側パース方式が速い」という傾向自体はデータ量の大小によらず変わりませんでした。

VBAとの対比： VBAのローカル実行に慣れていると、いずれの方式も「クラウドを経由する分だけ時間がかかる」という感覚になるはずです。特にDrive経由方式は「アップロード→変換→再度読み取り」という工程を挟む分、クライアント側パース方式より遅くなる傾向が実測でも裏付けられました。

比較④：対応できるデータ量の違い

処理速度だけでなく、扱えるデータ量の上限にも違いがあることが分かっています。

クライアント側パース方式（gas-07）： 約100万行規模のExcelファイルで「シートが見つかりませんでした」というエラーが発生し失敗することを確認済み（25万行までは成功）。原因はSheetJSがxlsxのXMLをJavaScript文字列に変換する際のブラウザ（V8エンジン）の文字列サイズ上限と考えられます（詳しくはgas-07のStep3を参照）。
Drive経由方式（gas-06）： 25万行のデータを含む123,541KB（約123.5MB）のファイルをアップロードしたところ、読み込み自体が失敗しました（ダイアログの表示が崩れ、ブラウザが描画に失敗したことを示すアイコンに置き換わり、データを取得できない状態）。ファイル内の不要なシートを削除してファイルサイズを17,911KB（約17.9MB）まで縮小したところ、同じ25万行のデータの取り込みに成功しました（所要時間4分23秒、データ欠損なく完全に取り込めたことを確認）。行数自体は変わらず成功したことから、ボトルネックは行数ではなくファイル全体のサイズと考えられます。正確な上限値は特定できていませんが、17.9MBは成功・123.5MBは失敗という結果から、その間のどこかに制約があると推測されます。

原因の推測： この失敗はDriveへのアップロード段階（サーバー側）ではなく、その手前のブラウザ側での処理で起きていた可能性があります。Drive経由方式はクライアント側でFileReaderのreadAsDataURL()によりファイルをBase64文字列に変換してからサーバーに送信しますが、Base64変換すると元のファイルサイズの約1.33倍にデータが膨れ上がります（123.5MB→約165MB相当）。HtmlServiceのダイアログはサンドボックス化されたiframeとして描画されているため、この巨大な文字列をメモリ上に保持しようとした際にiframeの描画プロセスがメモリ不足でクラッシュし、結果としてダイアログが正常に表示できなくなったと考えられます。もしこの推測が正しい場合、ボトルネックは厳密には「ファイルサイズ」というより「Base64変換後のデータをブラウザのメモリ上に保持できるかどうか」ということになります。

実務への影響： 同じ「超大量データ」でも、方式によって気にすべき指標が異なります。クライアント側パース方式は行数（約100万行が目安）、Drive経由方式はファイル全体のサイズ（複数シートを含む場合はその合計サイズ。100MB前後のどこかに制約があると推測）がボトルネックです。行数は多いがファイルサイズは小さい（不要なシートが少ない）場合はクライアント側パース方式が有利ですが、逆に他シートを含めてファイルサイズが大きい場合はDrive経由方式でも失敗しうるため、あらかじめ不要なシートを削除してファイルサイズを抑える対策が必要です。

比較⑤：Excelのスピル関数（動的配列）の扱い ★最大の差別化ポイント

2つの方式で最も明確に結果が分かれたのが、スピル関数（FILTER・UNIQUE・SORT・SEQUENCEや、複数条件範囲を使うXLOOKUP/MAXIFSなど）を含むファイルの取り込みです。

方式	スピル関数を含むファイルの取り込み結果
Drive経由方式（gas-06）	❌ スピル元セルの値のみ残り、スピル先の周囲セルはすべて空白になる（`SORT`関数など一部は`#NAME?`のように全く変換できないケースもあり）
クライアント側パース方式（gas-07）	✅ スピル先を含め、表示されている値がそのまま静的な値として取り込まれる

原因は変換処理の仕組みの違いにあります。Drive経由方式はGoogleドライブが自動変換時にスピル数式を「1つの数式・1つの値」としてしか扱わないのに対し、クライアント側パース方式で使うSheetJSは表示されている計算結果をそのまま読み取るため、スピル先の値も欠落しません。

なお、両方式に共通する例外として、FORMULATEXT()で他セルの数式を文字列表示していたセルは、書き込み時に=始まりの文字列が生きた数式として解釈されてしまう癖があります。特殊な使い方のため実務上の影響は限定的です。

実務への影響： 元のExcelファイルにスピル関数が含まれる可能性がある場合は、クライアント側パース方式（gas-07）が明確に有利です。Drive経由方式を使う場合は、取り込み前に「値貼り付け」でスピル関数を確定させておくといった対策が必要になります。

比較⑥：ファイル形式・文字コードの取り扱い

対応ファイル形式（.xlsx／.xls／.xlsm／.csv）はどちらの方式もすべて取り込みに成功しており、この点で差はありません。ただし文字コードの扱い方は異なります。

Drive経由方式（gas-06）： 変換はGoogleドライブの内部処理に任せるため、記事内で文字コードの問題は特に発生していません。
クライアント側パース方式（gas-07）： CSVファイルのみ、SheetJSの文字コード自動判定に頼れず自前の対応が必要でした。日本語Windows版Excelが既定で保存するBOMなしShift-JIS（cp932）のCSVで文字化けが発生し、TextDecoderでBOMの有無を判定した上でUTF-8／Shift-JISを明示的に切り替えてデコードする実装で解決しています（xlsx/xls/xlsmはバイナリ内に文字コード情報を持つため対象外）。

実務への影響： CSVファイルを扱う可能性がある場合、クライアント側パース方式では文字コード対応のコードが追加で必要になる点を踏まえておく必要があります。Drive経由方式はこの点で追加対応が不要でした。

比較⑦：その他の共通する制約・注意点

両方式に共通して見られた制約もあります。

項目	内容
`SpreadsheetApp.getUi()`のコンテキスト制約	両方式とも、エディタの「実行」ボタンから直接実行すると`Cannot call SpreadsheetApp.getUi() from this context.`エラーになる場合とならない場合があり、プロジェクトによって挙動が異なる（原因未特定）。シート上のボタンからの実行であれば両方式とも確実に動作する
シート名の指定	両方式とも、未指定時は「先頭シート」（VBAの`ActiveSheet`とは異なる）が使われ、指定時は`getSheetByName()`が参照する「シートタブの表示名」（VBAの`.CodeName`ではない）で一致させる必要がある
「取込先」シートの行数不足	クライアント側パース方式（gas-07）では書き込み前に`getMaxRows()`と比較して`insertRowsAfter()`で自動拡張する対応を明示的に追加している。Drive経由方式（gas-06）のコードにはこの対応がないが、比較④の25万行テストでは行数不足のエラーは発生せず正常に書き込めており、実際に問題になるかは確認できていない

VBAとの対比： シート名の指定でVBAの.CodeName（オブジェクト名）を使ってしまう誤りは、両方式に共通する落とし穴です。VBAのプロジェクトエクスプローラーで見慣れているのがコード名であるため、GASでシートタブの表示名を使う必要がある点は意識しておく必要があります。

結局どっちを使うべき？ユースケース別の使い分け

状況	おすすめ
スピル関数（動的配列）を含むExcelファイルをそのまま取り込みたい	クライアント側パース方式（gas-07）一択。Drive経由方式はスピル先が空白になることを実機確認済み
Drive APIの有効化やDriveへのアクセス権限の付与を避けたい	クライアント側パース方式（gas-07）
できるだけ準備・実装をシンプルに済ませたい	クライアント側パース方式（gas-07）
処理速度を優先したい（中規模データまで）	クライアント側パース方式（gas-07）。同一CSVで約1.5倍高速
数十万行規模の超大量データを扱う可能性がある（行数は多いがファイルサイズは小さい）	クライアント側パース方式（gas-07）。約100万行が目安の上限
ファイルサイズが大きい（他の不要なシートを多く含む等）データを扱う可能性がある	Drive経由方式（gas-06）は要注意。約123.5MBのファイルで読み込み失敗を確認済み（17.9MBでは成功）。取り込み前に不要なシートを削除してファイルサイズを抑える対策が必要
CSVファイルの文字コード判定を自前で書きたくない	Drive経由方式（gas-06）
VBAのGetOpenFilenameからの移行で、まず1つだけ試したい	クライアント側パース方式（gas-07）。準備が少なく着手しやすい

どちらも「ローカルファイルを直接開けない」というGASの制約への有効な対処法ですが、スピル関数の扱いと必要な準備の少なさから、多くのケースではクライアント側パース方式が扱いやすい選択肢です。Drive経由方式は、超大量データを扱う可能性がある場合や、CSVの文字コード対応を避けたい場合の代替案として検討する位置づけになります。

よくある質問

Q. 両方の方式を1つのプロジェクトに共存させることはできる？

→ できます。gas-06の関数（importFileViaDrive等）とgas-07の関数（importParsedData等）は名前が重複しないため、同じスクリプトファイル内に共存可能です。ボタンをそれぞれ別に用意し、「通常はクライアント側パース方式、スピル関数が心配なファイルだけDrive経由方式」のような使い分けもできます。

Q. どちらから使い始めるべき？

→ 準備が少なく実装もシンプルなクライアント側パース方式（gas-07）から試すことをおすすめします。スピル関数を含まないファイルしか扱わない、またはあらかじめ値貼り付けで確定させる運用であれば、Drive経由方式でも問題ありません。

Q. 100万行規模の超大量データを扱いたい場合はどうすればいい？

→ クライアント側パース方式は約100万行で失敗する制約が確認されています。Drive経由方式に切り替える手もありますが、こちらも約123.5MBのファイルで読み込みに失敗する制約が確認されているため、他の不要なシートを削除してファイルサイズを抑える、SheetJS公式のIssue #563で報告されているようにファイルをあらかじめ分割する、といった対策を組み合わせて検討してください。

まとめ

Drive経由方式（gas-06）とクライアント側パース方式（gas-07）は、どちらも「GASにはローカルファイルを直接開く仕組みがない」という同じ制約への異なる対処法
実装のしやすさ・必要な権限・処理速度は、いずれもクライアント側パース方式が有利（Drive API有効化が不要、Driveアクセス権限も一時ファイルの後片付けも不要。処理速度は小規模CSVで約1.5倍、25万行規模のExcelファイルを同一ファイルで比較しても約2割高速）
最大の差別化ポイントはスピル関数（動的配列）の扱い：Drive経由方式はスピル先の値が空白になるが、クライアント側パース方式は表示値をそのまま取り込める
超大量データでは方式ごとにボトルネックが異なる：クライアント側パース方式は行数（約100万行が目安）、Drive経由方式はファイル全体のサイズ（約123.5MBで失敗を確認、17.9MBでは成功）が制約になる。他の不要なシートを含めたファイルサイズにも注意が必要
CSVの文字コード対応は、Drive経由方式は不要、クライアント側パース方式は自前のTextDecoder対応が必要という違いがある
総合すると、多くのケースではクライアント側パース方式から試し、超大量データやCSVの文字コード対応を避けたい場合にDrive経由方式を検討するのが実用的な選び方