「ウェブに公開」を使わずにスプレッドシートを読む——Sheet Widget が Google の drive.file を選んだ理由

Sheet Widget2026年10月4日

Sheet Widget は、Google スプレッドシートの好きな範囲を、iPhone のホーム画面にウィジェットとして置けるアプリです。

このアプリを作っていて一番時間がかかったのは、画面のデザインでもグラフの描画でもありませんでした。「Google のどの権限を使って、スプレッドシートを読むか」です。この記事では、そこで考えたことと、実際に Google の審査でやり取りした内容をまとめます。同じように Google のデータを扱うアプリを作る人の参考になればうれしいです。

スプレッドシートを外から読む方法は3つある

アプリから Google スプレッドシートの中身を読む方法は、大きく分けて3つあります。

方法	シートの公開範囲	Google の審査	使い心地
① シートを「ウェブに公開」して、その URL を読む	URL を知っている人なら誰でも読める	不要	実装は一番簡単
② 「スプレッドシートを読む」「ドライブを読む」などの広い権限を使う	非公開のまま	必要（機密性の高いスコープ）	アプリ内でファイル一覧を出せる
③ `drive.file`（ユーザーが選んだファイルだけ読める権限）を使う	非公開のまま	不要	ファイルは Google の選択画面（Picker）で選ぶ

① 「ウェブに公開」は、一番簡単だけど選ばなかった

シートの「ウェブに公開」を使えば、そのシートはただの Web ページになります。アプリはその URL を読むだけで済むので、技術的には一番簡単です。

ただ、「ウェブに公開」は、URL を知っている人なら誰でもシートを読める状態にする機能です。家計簿、在庫表、シフト表のように「毎日見るけれど、人には見せたくない」データをホーム画面に置くアプリで、この方法をすすめる気にはなれませんでした。

② 広い権限は、審査が重い

「スプレッドシートを読む」（spreadsheets.readonly）のような権限を使えば、シートを公開しなくても読めます。ただしこれは、Google が「機密性の高いスコープ」に分類している権限です。使うには Google の審査（OAuth のアプリ検証）が必要で、審査に通るまでは、アプリを使えるユーザーが100人までに制限されます。ドライブ全体を読むような、さらに強い権限になると、第三者のセキュリティ評価まで求められることがあります。

③ drive.file は、選んだファイルだけ

drive.file は、ユーザーが Google のファイル選択画面（Picker）で選んだファイルだけに、アプリがアクセスできる権限です。ドライブのほかのファイルは、アプリからは存在すら分かりません。この権限は「非機密」に分類されていて、審査も100人の制限もありません。

条件としては③が一番良いのですが、最初からここにたどり着いたわけではありませんでした。

最初は②で申請して、一度落ちた

最初に選んだのは、②の「スプレッドシートの読み取り専用」（spreadsheets.readonly）でした。読み取りだけなら狭い権限だろうと思っていたのですが、これも機密性の高いスコープの扱いで、審査が必要でした。

審査では、主に次のものを求められます。

アプリのホームページと、プライバシーポリシーの URL（自分が所有を確認したドメインで）
そのスコープが必要な理由の説明
デモ動画（実際のアプリで、Google のログインから許可までの流れを見せる）

デモ動画で差し戻された理由

1回目の審査は、デモ動画が要件を満たしていないという理由で差し戻されました。指摘は「OAuth の同意画面が映っていない」というものでした。

撮り直すときに気をつけたのは、次の点です。

アプリを入れ直して、ログインしていない状態から撮り始める
Google のログイン → 同意画面（アプリが求める権限の一覧が表示される画面） → 「許可」までを、途中で切らずに映す
同意画面に、申請しているスコープが表示されていることがはっきり分かるようにする
審査担当が読めるように、各手順に英語の字幕を付ける（字幕あり・なしの2本を、YouTube の限定公開で提出）

注意点として、テストに使う Google アカウントがすでにアプリを許可していると、同意画面が出ずに素通りしてしまいます。撮影の前に、アカウントの設定からアプリの許可を外しておく必要がありました。

Google から「もっと狭い権限にできないか」と提案された

動画を出し直したところで、今度は Google の側から「drive.file にできないか」という提案がありました。③の方法です。審査の手続きも軽くなるので、そちらに切り替えることにしました。

ここからが本当に時間のかかったところです。

Picker を「アプリの中」で出すのに1か月かかった

drive.file では、ファイルを Google の Picker で選んでもらう必要があります。Google のドキュメントには、Picker はブラウザで開くもので、アプリに埋め込んだ Web 画面（埋め込みウェブビュー）の中では表示できない、という趣旨のことが書かれています。

つまり普通に作ると、ファイルを選ぶたびにアプリから Safari に移り、選んだらまたアプリに戻ってくる流れになります。ウィジェットをいくつも設定する人にとって、毎回これが起きるのはつらいので、なんとかアプリの中で完結させようとしました。試したのは次の3つです。

方法	結果
WKWebView（アプリに埋め込む Web 画面）	Google が、埋め込みウェブビューでのログインそのものを禁止している
SFSafariViewController（アプリ内の Safari 画面）	Cookie が Safari 本体と別に保存されるため、毎回ログインし直しになる
ASWebAuthenticationSession（ログイン用の画面）	1回目は選べるが、2回目以降に Picker が求める「Cookie を許可してください」の確認が出ず、必ず行き止まりになる

3つ目は一番いいところまで行ったのですが、原因がこちらのコードのどこにも見つからず、Google のサポートに直接問い合わせました。返ってきた答えは、iOS の仕組み上、Picker は埋め込みの画面の中で安定して動くようには作られていない、というものでした。1回目だけ動くのは、Google 側の確認画面が一度だけ出る作りになっているためで、こちらの実装の不備ではなかったと分かりました。

最終的な形：ファイルを選ぶときだけ、毎回ログインする

最終的には、次の形に落ち着きました。

アプリ本体のログインは、Google の公式のサインイン（drive.file のみ）で行う。ログイン情報は端末の中（キーチェーン）にだけ保存し、ウィジェットの更新に使う。
ファイルを選ぶ画面は、自分のサイト（sheetwidget.com）に置いた Picker のページを、アプリ内の Safari 画面で開く。選び終わったら、アプリ専用の URL でアプリに戻す。
Picker のページは、開くたびに Google にログインし直してもらう（Cookie の問題を避けるため）。

「一度ログインしたら、ずっとアプリの中だけで完結する」という理想の形は諦めました。代わりに、次の3つは守れました。

シートを「ウェブに公開」しなくていい
Google の重い審査を受けなくていい
アプリが読めるのは、ユーザーが Picker で選んだファイルだけ

Sheet Widget はサーバーを持っていないので、選んだシートの中身が開発者に届くこともありません。

同じことをする人へのチェックリスト

最後に、Google のデータを読む iOS アプリを作るときに、最初に考えておくとよかったことをまとめます。

読みたいデータは「ユーザーが選んだファイルだけ」で足りるか → 足りるなら、最初から drive.file を検討する
機密性の高いスコープを使うなら、ホームページ・プライバシーポリシー・ドメインの所有確認・デモ動画の準備に時間がかかる前提で、リリースの予定を組む
デモ動画は、未ログインの状態から同意画面まで切らずに撮る。テスト用アカウントの許可は先に外しておく
Picker はアプリに埋め込めない前提で、画面の流れを設計する
自分で原因が切り分けられないときは、Google のサポートに実測の結果を添えて聞く（今回は具体的な回答がもらえました）

権限の設計は、使う人の目にはほとんど触れない部分です。それでも、ここで妥協すると「人に見せたくないデータを、安心してホーム画面に置ける」というアプリの前提が崩れてしまうので、時間をかけてよかったと思っています。

Sheet Widget は App Store で公開しています。