Kon's DX Lab - Case Study

Day 83 │ Google Sheets APIで「権限エラー」が出るときのチェックリスト

Published on 2025-06-23

🔬 Case Study Summary
Problem

(ここに課題を記述)

Result

(ここに具体的な成果を記述)


Tech & Process

(ここに採用技術とプロセスを記述) コードを詳しく見る »

こんにちは、こんです🦊
Slack勤怠ボットをCloud RunからGoogle Sheetsに連携しようとしたとき、最初に直面したのが「権限まわりのエラー」でした。

googleapiclient.errors.HttpError: <HttpError 403 when requesting...>

このエラー、最初は「認証コードは通ったはずなのに、なんで?」と思ってけっこう混乱しました。

なので今回は、Google Sheets APIでありがちな権限エラーと、そのとき見直すポイントをリスト形式でまとめておきます。


🧭 まず前提:どこからSheetsを操作してる?

今回の想定はこんな構成です:

  • Google Cloud Run(Python + Flask)で動いているアプリ

  • その中から Google Sheets API を使ってシートにアクセス

つまり、Sheetsにアクセスするのは「Cloud Run のサービスアカウント」なんですよね。


✅ チェックリスト:これで通るはず


🔍 補足:共有されていないとどうなる?

Slackコマンドを叩いたとき、Cloud Run上ではこんなエラーが出ているかもしれません。

googleapiclient.errors.HttpError: <HttpError 403 when requesting... returned "The caller does not have permission">

この場合、スプレッドシートの共有設定がされていない可能性が高いです。
ローカルの認証(OAuth)では気づきにくいので、Cloud Runに移したあとで「書けない…」となりがちです。


🧩 例:Cloud Runデフォルトサービスアカウントを共有するには

  1. IAM画面にアクセス

  2. 該当プロジェクトの中から、xxx-compute@developer.gserviceaccount.com を探す

  3. メールアドレスをコピー

  4. Sheets側で「共有」→「編集者」として追加

これだけで、Slackボットからの書き込みが通るようになりました!


💡 まとめ:コードより設定が大事だったかも

Google Sheets APIに限らず、「動いてるのに書けない・読めない」ってケースは、コードではなくアクセス権限がネックなことが多いです。

特にCloud Runのようなクラウド環境では、認証の前提が「人」ではなく「サービスアカウント」になるため、気づかずに詰まりやすいところだなと実感しました。


#100日チャレンジ
#Slackボット開発
#GoogleSheetsAPI
#認証エラー
#Flask
#CloudRun
#GCP構築メモ
#DX実験記録
#Python開発
#MVP開発