社内でGoogle Driveを利用していると、
「業務システムで作成したPDFを自動的にGoogle Driveへ保存したい」
「案件登録時に顧客ごとのフォルダを自動作成したい」
「Google Driveに保存されているファイルを自社システムから検索したい」
といった要望が出てくることがあります。
このような連携に利用できるのがGoogle Drive APIです。
Google Drive APIを利用すると、プログラムからGoogle Driveに対して、
- ファイルをアップロードする
- ファイルを検索する
- フォルダを作成する
- ファイル名を変更する
- ファイルを移動する
- ファイル情報を取得する
- 共有設定を変更する
- ファイルを削除する
といった操作を実行できます。
そのため、Google Driveを単なるオンラインストレージとして使うだけでなく、業務システムのファイル保管・共有基盤として組み込むことも可能です。
この記事では、Google Drive APIの活用例から、業務システムとの連携方法、認証・権限設計、フォルダ構成、運用上の注意点まで実務目線で解説します。
Google Drive APIとは
Google Drive APIとは、プログラムからGoogle Driveのファイルやフォルダを操作するための仕組みです。
通常、Google Driveではユーザーがブラウザから、
フォルダを作る
↓
ファイルをアップロードする
↓
共有設定を変更する
といった操作を行います。
Google Drive APIを利用すると、これらの処理を業務システムから自動的に実行できます。
例えば請求管理システムで、
請求確定
↓
請求書PDFを生成
↓
Google Driveへ自動保存
↓
保存先URLをシステムへ記録
という処理が可能になります。
Google Drive APIを活用するメリット
Google Drive APIの大きなメリットは、既存のGoogle Drive環境と業務システムをつなげられることです。
例えばすでに社内でGoogle Driveを利用している場合、新しく独自のファイル管理基盤をすべて構築しなくても、Google Driveを活用できる可能性があります。
代表的なメリットを見ていきます。
ファイル保存を自動化できる
例えば現在、
システムからPDFをダウンロード
↓
Google Driveを開く
↓
顧客フォルダを探す
↓
PDFをアップロード
という作業をしているとします。
Google Drive APIを利用すれば、
システムでPDF生成
↓
Google Driveへ自動保存
まで自動化できます。
帳票数が多い業務では、保存作業だけでも大きな手間になるため効果が期待できます。
業務システムからGoogle Driveのファイルを扱える
利用者が毎回Google Driveを開かなくても、業務システム上からファイルを確認できるようにすることもできます。
例えば案件管理システムで、
案件詳細
↓
関連ファイル
↓
Google Driveの契約書・見積書・議事録を一覧表示
という画面を作る方法です。
利用者から見ると、案件情報と関連文書を一つの画面から確認できます。
Google Driveの共有機能を活用できる
Google Driveにはファイル・フォルダの共有機能があります。
そのため、
- 社内メンバーだけ
- 特定ユーザーだけ
- 特定グループだけ
といったアクセス管理と組み合わせることができます。
独自システム側の権限とGoogle Drive側の権限をどのように連携させるかは、設計時の重要なポイントです。
Google Drive APIの代表的な活用例
ここからは、実際の業務で考えられるGoogle Drive APIの活用例を紹介します。
1. 帳票PDFをGoogle Driveへ自動保存する
分かりやすい活用例が帳票保存です。
例えば業務システムから、
- 見積書
- 発注書
- 納品書
- 請求書
- 作業報告書
などをPDF生成するとします。
通常であればユーザーがPDFをダウンロードし、Google Driveへ手動で保存します。
Google Drive APIを使えば、
請求確定
↓
請求書PDF生成
↓
顧客フォルダ確認
↓
Google Driveへアップロード
↓
ファイルIDを保存
という処理を自動化できます。
これにより「PDFを作ったがGoogle Driveへ保存し忘れた」といった運用ミスも減らしやすくなります。
2. 顧客登録時にフォルダを自動作成する
顧客管理システムとの連携も考えられます。
例えば新しい顧客を登録するたびに、
顧客名フォルダ
├─ 契約書
├─ 見積書
├─ 請求書
└─ その他資料
という構成を手作業で作っているとします。
Google Drive APIを利用すると、
顧客登録
↓
顧客フォルダ作成
↓
サブフォルダ作成
↓
DriveのフォルダIDを顧客情報へ保存
という処理を自動化できます。
顧客が増えても一定のフォルダ構成を維持しやすくなります。
3. 案件管理システムとGoogle Driveを連携する
案件単位でファイルを管理する企業にも向いています。
例えば、
顧客A
└─ Webシステム開発案件
├─ 契約
├─ 要件定義
├─ 設計
├─ 議事録
└─ 納品物
というフォルダを作るケースです。
案件管理システムで案件を作成したタイミングでGoogle Driveにもフォルダを自動生成できます。
案件詳細画面に「Google Driveを開く」ボタンを配置すれば、案件とファイルを紐付けて管理しやすくなります。
4. 契約書管理と連携する
契約管理システムとGoogle Driveを連携する方法もあります。
例えば契約情報として、
- 契約先
- 契約開始日
- 契約終了日
- 契約金額
- 契約ステータス
- Google DriveファイルID
を管理します。
システム上では契約情報を検索し、契約書原本はGoogle Driveへ保存する構成です。
これによって、
「契約情報はデータベース」
「実際のファイルはGoogle Drive」
と役割を分けられます。
5. 申請・承認システムと連携する
申請書類をGoogle Driveへ保存するケースです。
例えば経費申請で、
ユーザーが申請
↓
領収書をアップロード
↓
Google Driveへ保存
↓
ファイルIDを申請データへ紐付け
↓
上司が承認
という流れを作れます。
申請データは業務システムで管理し、添付ファイルだけGoogle Driveへ保存する構成です。
6. 社内文書管理システムと連携する
社内規程やマニュアルをGoogle Driveで管理している場合、独自の検索・管理画面と組み合わせることもできます。
例えばシステム側で、
- 文書タイトル
- カテゴリ
- 所管部署
- 更新日
- 公開範囲
などを管理し、実ファイルはGoogle Driveへ保存します。
利用者は文書管理システムから検索し、必要なファイルだけGoogle Driveから取得します。
Google Driveのフォルダを直接探すより、業務に合わせた検索画面を作れることがメリットです。
7. ファイルアップロードを自動化する
Webシステムから受け取ったファイルを、そのままGoogle Driveへ保存することもできます。
例えば、
顧客がファイルをアップロード
↓
Webシステムで受信
↓
Google Driveへ保存
↓
保存先ファイルIDをDBへ登録
という処理です。
対象としては、
- Excel
- Word
- 画像
- CSV
- その他の添付ファイル
などが考えられます。
8. Google Drive上のファイルを検索する
Google Drive APIではファイル情報を取得できるため、自社システムからファイル検索する仕組みも作れます。
例えば、
顧客名：株式会社ABC
文書種別：契約書
という条件から対象ファイルを探します。
ただし、Google Drive側だけの検索に依存すると、業務上必要な検索条件を作りにくい場合があります。
そのため重要なメタ情報は自社システム側のデータベースにも保存し、
DBで検索
↓
Google Driveのfile_idを取得
↓
対象ファイルへアクセス
という構成も有効です。
Google Drive APIではfile_idとfolder_idが重要
Google Drive上のファイルやフォルダには、それぞれ識別するためのIDがあります。
業務システムとGoogle Driveを連携するときは、
- file_id
- folder_id
をシステム側で保持しておくと扱いやすくなります。
例えば顧客テーブルに、
- customer_id
- customer_name
- drive_folder_id
を保存します。
顧客情報を表示するときにdrive_folder_idを利用すれば、その顧客専用フォルダへアクセスできます。
ファイル名だけで紐付けない
例えば、
株式会社ABC
というフォルダ名だけを基準にシステムとGoogle Driveを紐付けると、問題が起こる可能性があります。
会社名が変更された場合、
株式会社ABC
↓
ABCホールディングス株式会社
となれば、フォルダを特定できなくなる可能性があります。
同じ名前のフォルダが複数作られるケースもあります。
そのため、表示名とは別にGoogle Driveのfolder_idを保持する設計が安全です。
Google DriveとDBの役割を分ける
Google Drive APIを使う場合、
「すべてGoogle Driveだけで管理する」
必要はありません。
むしろ、
データベース
- 顧客ID
- 文書種別
- ステータス
- 登録者
- 登録日時
- Google Drive file_id
Google Drive
- Excel
- Word
- 画像
というように、構造化された業務情報とファイル本体を分ける方法があります。
例えば契約書を探す場合も、ファイル名をGoogle Driveから探すのではなく、
契約管理システムで検索
↓
契約データ取得
↓
紐付くGoogle Driveファイルを表示
という流れにできます。
Google Drive APIの認証方法を考える
Google Drive APIを利用するときに重要なのが認証です。
「誰の権限でGoogle Driveを操作するのか」
を決める必要があります。
大きく分けると、利用者本人のGoogleアカウントを使う構成と、システム側の認証主体を利用する構成があります。
ユーザー本人のGoogleアカウントで操作する
例えばユーザーにGoogleアカウントで認証してもらい、そのユーザーがアクセスできるGoogle Driveを操作します。
利用イメージは、
Googleアカウントで認証
↓
利用許可
↓
APIからGoogle Driveを操作
という流れです。
利用者ごとの権限をGoogle Drive側でも反映しやすい方法です。
システム側でファイルを一元管理する
業務システムが共通の管理領域へファイルを保存したい場合は、ユーザー個人ではなくシステム側の認証主体を利用する構成も検討します。
例えば、
業務システム
↓
共通のファイル保管領域
↓
顧客・案件フォルダ
という構成です。
どの認証方式が適切かは、
- 個人のDriveを操作するのか
- 組織で共有するのか
- 利用者ごとにGoogle権限を反映するのか
- バックグラウンド処理が必要か
によって変わります。
OAuthの権限範囲を必要以上に広げない
Google APIの認証では、どの範囲へのアクセスを許可するかを指定します。
例えば、
「必要なファイルだけ操作したい」
システムなのに、利用者のGoogle Drive全体へ不必要に広いアクセス権を要求する設計は避けるべきです。
必要な操作を洗い出し、できるだけ必要最小限の権限にします。
これは「最小権限」の考え方です。
共有ドライブを活用する方法
企業でGoogle Workspaceを利用している場合、個人のマイドライブではなく、組織で管理する共有ドライブを利用したいケースがあります。
例えば、
営業部共有ドライブ
↓
顧客
↓
案件
↓
契約書
という構成です。
業務ファイルを個人のGoogleアカウントに依存させると、担当者の異動や退職時に管理が複雑になる可能性があります。
組織として管理するファイルであれば、保管場所の設計も重要です。
Google Drive API連携ではフォルダ構成を先に決める
APIを実装する前に、Google Drive上のフォルダルールを整理しておくと運用しやすくなります。
例えば、
顧客
└─ 顧客ID_顧客名
├─ 01_契約書
├─ 02_見積書
├─ 03_請求書
└─ 04_その他
という構成です。
ただし、フォルダを細かく分けすぎるとAPI処理も運用も複雑になります。
必要な検索性と業務上の分かりやすさを基準に決めます。
IDをフォルダ名へ含める方法もある
企業名や案件名は後から変更されることがあります。
例えば、
C000123_株式会社ABC
のようにシステム側のIDをフォルダ名へ含める方法があります。
表示名が変わっても、C000123という識別子で対応関係を確認できます。
ただし、システム内部ではfolder_idを持っておき、フォルダ名だけに依存しない設計にすることが重要です。
ファイル名の命名ルールも決める
ファイルが増えると、
請求書.pdf
請求書_最新.pdf
請求書_最新版2.pdf
のような状態になりがちです。
例えば、
20260731_INV-000123_株式会社ABC.pdf
のように、
- 発行日
- 帳票番号
- 顧客識別子
などを組み合わせる方法があります。
ただし、ファイル名へ個人情報や機密情報を必要以上に含めないことも重要です。
Google Drive側とシステム側で二重管理しない
連携システムで起きやすい問題が、同じ情報を両方で変更できる状態です。
例えばシステムでは、
契約書：A.pdf
となっているのに、Google Drive側でユーザーが手動で、
A.pdf → B.pdf
へ変更すると、表示内容がずれる可能性があります。
そのため、
- どちらを正とするか
- Google Drive上で手動変更を許可するか
- 変更を同期するか
を決めます。
「正となるデータ」を決める
システム連携ではSource of Truth、つまり正となる情報源を決めることが重要です。
例えば、
契約情報：
業務システムが正
ファイル本体：
Google Driveが正
という形です。
顧客名をGoogle Drive側で変更したからといって、業務システムの顧客名まで自動更新する必要はありません。
何をどちらで管理するのかを明確にします。
ファイル削除の扱いを決める
業務システムから文書を削除した場合、
Google Drive上のファイルも削除するのか
を決めます。
例えば、
同時削除
システム削除
↓
Google Driveからも削除
論理削除
システム上では非表示
↓
Google Driveファイルは一定期間保持
などがあります。
契約書や請求書など重要な文書では、利用者が削除ボタンを押しただけで完全削除される設計が適切とは限りません。
業務ルールに合わせて決定します。
ゴミ箱に入れるのか完全削除するのかも考える
Google Drive上でファイルを消す場合も、
「ゴミ箱へ移動する」
のか、
「完全に削除する」
のかで意味が違います。
誤操作から復旧したい場合は、一定期間ゴミ箱に残すなどの運用を検討できます。
ファイル更新とバージョン管理を考える
同じ契約書を修正した場合、
- 元ファイルを上書きする
- 新しいファイルとして保存する
という2つの考え方があります。
監査性が重要なら、
契約書_v1
契約書_v2
契約書_v3
のように過去版を追跡できる仕組みを検討します。
自社システム側で、
- バージョン
- 更新者
- 更新日時
- file_id
を管理する方法もあります。
Google Drive APIと監査ログを組み合わせる
業務システムからGoogle Driveを操作する場合、
「誰が何をしたのか」
をシステム側にも記録すると調査しやすくなります。
例えば、
- ファイルアップロード
- ファイルダウンロード
- ファイル削除
- 共有設定変更
などです。
監査ログとして、
- user_id
- action
- file_id
- document_id
- timestamp
などを記録できます。
機密ファイルを扱う場合には特に重要です。
ファイルへのアクセス権限は両側で考える
例えば業務システムでは、
人事部だけ閲覧可能
にしていたとしても、Google Drive側で全社員に公開されていれば権限管理が崩れます。
反対に、Google Driveでは正しい権限設定でも、システム側で別ユーザーのfile_idを指定して取得できる設計では問題があります。
そのため、
- 業務システム側の認可
- Google Drive側の共有権限
を両方確認します。
Google DriveのURLだけをDBへ保存する設計には注意する
シンプルなシステムではGoogle Driveの共有URLだけを保存することがあります。
例えば、
契約ID
契約書URL
という構成です。
簡単ですが、
- URLの変更
- 共有設定変更
- ファイル移動
- API操作
などを考えると、file_idも管理した方が扱いやすい場合があります。
URLは表示用、file_idはシステム連携用という分け方もできます。
APIの失敗を前提に設計する
Google Drive APIを利用する処理は、外部サービスとの通信です。
そのため必ず成功するとは限りません。
例えば、
請求確定
↓
PDF生成成功
↓
Google Driveアップロード失敗
というケースがあります。
この場合、
「請求処理全体を失敗にするのか」
「請求は確定し、ファイル保存だけ再実行するのか」
を決めておく必要があります。
リトライできる設計にする
一時的な通信失敗であれば、再実行することで成功する可能性があります。
そのため、
アップロード待ち
↓
処理中
↓
成功
または、
失敗
↓
再実行
といった状態管理をする方法があります。
重要な業務では、外部API呼び出しを1回失敗しただけでデータの整合性が崩れないようにします。
二重アップロードにも注意する
リトライ処理を実装すると、
1回目：
Google Driveへの保存は成功したが、応答を受け取れなかった
2回目：
もう一度アップロード
という状況で、同じファイルが2つできる可能性があります。
そのため、
- アップロード状態を記録する
- file_idを確認する
- 一意な処理IDを持つ
など、重複防止を考えます。
大量ファイル処理では非同期化を検討する
例えば月末に、
請求書3,000件生成
↓
Google Driveへ3,000ファイル保存
という処理がある場合、ユーザーの画面操作中にすべて実行するのは適切でない場合があります。
そこで、
一括処理開始
↓
バックグラウンドで順次アップロード
↓
完了件数を更新
↓
処理完了を通知
という構成を検討します。
大量処理では、Google Drive APIだけでなくPDF生成側の負荷も含めて設計する必要があります。
Google Drive APIを使うべきケース
Google Drive APIが向いているのは、例えば次のような場合です。
- すでに社内でGoogle Driveを利用している
- 業務システムとファイル保管を連携したい
- 手作業のアップロードをなくしたい
- 顧客・案件ごとのフォルダ作成を自動化したい
- 帳票をGoogle Driveへ自動保存したい
- Google Driveのファイルを自社画面から検索したい
既存のGoogle Workspace環境を活用したい企業には特に選択肢になります。
独自ストレージの方がよいケース
一方、Google Drive APIが必ず最適とは限りません。
例えば、
- 大量ファイルをサービス利用者へ配信する
- 一般消費者向けサービスのストレージとして利用する
- 独自の細かなアクセス制御が必要
- CDNと組み合わせて高速配信したい
- Google Workspaceへ依存したくない
といった場合には、クラウドのオブジェクトストレージなど別の選択肢が適することがあります。
「Google Driveを使えるから使う」のではなく、用途から判断することが重要です。
Google Drive API連携でよくある失敗
ファイル名だけで管理する
同名ファイルや名称変更によって紐付けが崩れる可能性があります。
file_idやfolder_idを管理します。
個人アカウントに依存する
担当者個人のGoogle Driveへ業務ファイルを保存すると、異動・退職時に問題になる場合があります。
組織としてどこに保存するかを決めます。
共有設定を広げすぎる
API連携を簡単にするために「リンクを知っている全員」に公開すると、機密情報が漏れるリスクがあります。
必要なユーザーだけに権限を設定します。
Drive側の手動変更を考えていない
ユーザーがフォルダ移動・削除・名前変更をすると、自社システムとの整合性が崩れる場合があります。
手動操作のルールも含めて設計します。
API失敗時の処理がない
外部APIは失敗する可能性があります。
エラー記録、再実行、重複防止を考えます。
業務データまでGoogle Driveだけで管理する
ファイル名やフォルダだけですべての業務情報を表現しようとすると、検索や集計が難しくなることがあります。
構造化された情報はDBで管理し、ファイル本体をGoogle Driveへ置く構成も検討します。
Google Drive API連携の設計手順
実際にGoogle Drive APIを導入する場合は、次の順番で整理すると進めやすくなります。
1. 現在のファイル管理業務を整理する
まず、
誰が
どのファイルを
どこへ保存しているか
を確認します。
2. 自動化したい操作を決める
例えば、
- フォルダ作成
- ファイル保存
- ファイル検索
- 共有設定
- ファイル削除
などです。
3. Google DriveとDBの役割を決める
どの情報をシステム側に持ち、どの情報をGoogle Drive側へ保存するか整理します。
4. フォルダ構成を決める
顧客単位、案件単位、年度単位などのルールを決めます。
5. 認証方式を決める
誰の権限でGoogle Driveへアクセスするのか整理します。
6. 権限を決める
誰がどのファイルを閲覧・編集できるのか整理します。
7. エラー時の処理を決める
API失敗時に、
- 再実行するか
- 管理者へ通知するか
- 業務処理全体を停止するか
を決めます。
8. 監査ログを決める
重要ファイルについて、アップロード・削除・ダウンロードなどを記録するか検討します。
【コピペ用】Google Drive API連携チェックリスト
Google Driveと業務システムを連携するときは、次の内容を整理すると要件定義を進めやすくなります。
ファイル
- どのファイルを保存するか
- PDF・Excel・画像など種類は何か
- 1日何件程度保存するか
- 1ファイルの最大サイズはどの程度か
フォルダ
- 顧客ごとに作るか
- 案件ごとに作るか
- 年度ごとに分けるか
- サブフォルダが必要か
- folder_idをシステム側で保存するか
アップロード
- いつアップロードするか
- 自動か手動か
- 同名ファイルをどう扱うか
- 二重アップロードをどう防ぐか
検索
- ファイル名で検索するか
- 顧客で検索するか
- 案件で検索するか
- 文書種別で検索するか
- メタ情報をDBへ保存するか
認証・権限
- 誰のGoogleアカウントを利用するか
- 共有ドライブを利用するか
- 誰が閲覧できるか
- 誰が編集できるか
- 必要最小限のAPI権限になっているか
削除・更新
- システム削除とDrive削除を連動するか
- ゴミ箱を利用するか
- 過去バージョンを残すか
- Drive側の手動変更を許可するか
エラー処理
- API失敗を記録するか
- 自動リトライするか
- 管理画面から再実行できるか
- 重複処理を防げるか
監査
- アップロード履歴を残すか
- ダウンロード履歴を残すか
- 削除履歴を残すか
- 共有権限変更を記録するか
Google Drive APIに関するよくある質問
Google Drive APIでファイルを自動アップロードできますか？
可能です。
業務システムで生成したPDFや、ユーザーがアップロードしたファイルをGoogle Driveへ自動保存する仕組みを作れます。
Google Drive APIでフォルダも作成できますか？
可能です。
例えば顧客登録や案件登録をきっかけに、対応するフォルダを自動作成できます。
作成後のfolder_idを業務システム側へ保存しておくと、その後のファイル保存に利用できます。
Google Driveのファイルを自社システムから検索できますか？
可能です。
Google Drive APIからファイルを検索する方法があります。
ただし顧客名、案件番号、ステータスなど複雑な業務条件で検索する場合は、メタ情報を自社DBへ保存した方が扱いやすいこともあります。
Google Driveを業務システムのファイルストレージとして使えますか？
用途によっては可能です。
特に社内向けシステムで、すでにGoogle Workspaceを利用している場合は有力な選択肢になります。
一方、大量配信や一般ユーザー向けサービスなどでは別のストレージが適する場合もあります。
Google Drive APIで共有権限も変更できますか？
Google Driveの権限管理と連携することは可能です。
ただし、誤った共有設定は情報漏えいにつながるため、どのユーザー・グループへ何の権限を付与するかを事前に整理することが重要です。
Google Drive APIとGASはどちらを使えばよいですか？
小規模なGoogle Workspace内の自動化では、Google Apps Scriptが手軽な場合があります。
一方、
- 独自Webシステムとの連携
- 外部DBとの連携
- 複雑な認証・権限管理
- 大規模な業務処理
などでは、WebアプリケーションからGoogle Drive APIを直接利用する構成が適する場合があります。
用途によって使い分けます。
Google Driveとシステムのデータがずれることはありませんか？
設計によっては発生します。
例えばDrive上でユーザーがファイルを手動削除した場合、システム側にはfile_idが残る可能性があります。
そのため、どちらを正とするか、手動変更をどこまで許可するかを決めておくことが重要です。
仕様が決まっていなくてもGoogle Drive連携を相談できますか？
可能です。
例えば、
「現在PDFを手作業でGoogle Driveへ保存している」
という状態から、
現在の業務
↓
保存ルール
↓
フォルダ構成
↓
必要な自動化
↓
API連携方法
という順番で整理できます。
hiro-dev-labではGoogle Drive APIを使った業務システム連携から相談できます
Google Drive APIを導入する目的は、APIを使うこと自体ではありません。
重要なのは、
現在の手作業
↓
どのファイルを扱うか
↓
どこへ保存するか
↓
誰がアクセスするか
↓
どこまで自動化するか
を整理することです。
hiro-dev-labでは、
- 現在のファイル管理業務のヒアリング
- 要求整理
- 要件定義
- Google Drive API連携設計
- フォルダ構成設計
- ファイル管理設計
- 認証・権限設計
- 帳票PDFの自動保存
- 顧客・案件管理システムとの連携
- Google Workspaceを活用した業務自動化
- Webシステム開発
など、業務整理からシステム開発まで相談できます。
例えば、
「帳票PDFをGoogle Driveへ自動保存したい」
「顧客登録時にフォルダを自動作成したい」
「案件管理画面から関連ファイルを確認したい」
「Google Driveにある契約書をシステムから検索したい」
「手作業のファイル整理を自動化したい」
といった段階からでも整理できます。
Google Drive API活用で重要なのは、単にファイルをアップロードできるようにすることではありません。
業務システム側のデータとGoogle Drive上のファイルをIDで正しく紐付け、認証・権限・エラー処理まで含めて運用できる仕組みにすることが、実務で使いやすいGoogle Drive連携を構築するための基本です。