Web Google シートアクセス

Google シートへのアクセスは、持ち込む認証情報に従います。デプロイ済みの Web サイトには 並んだ二つの入り口 があります: Google でサインインする(OAuth)か、あなた自身のブラウザーが直接使う サービスアカウントの JSON キーファイル を選ぶかです。Unity / ローカルの経路は、マシンローカルのサービスアカウントキーをそのまま保持します。

デプロイ済みサイト上では — OAuth による読み書き

デプロイ済みのサイト上では、サインインしたユーザーは、自分自身の OAuth トークン を通じて、Google シートを 読み書きの両方 できます。

最小権限。 サインインが求めるのは、基本プロフィールとファイル単位のスプレッドシートアクセス権限(drive.file)だけです。アプリが読み書きできるのは、あなたが明示的に開いて許可したスプレッドシートファイルだけです。アカウント全体に及ぶ権限は一切ありません——残りの Drive を一覧表示したり閲覧したりすることはできず、開いて許可していないファイルは見えないままです。
同じコアのプラン。 Web 上での書き込みは、他のどの経路とも まったく同じコアのプラン、そして 同じ共有された楽観的ロックの検証 を通じて実行されます——送信の直前に本番シートが再チェックされるため、あなたのインポート後に第三者が変更したセルはスキップされ、決して上書きされません。異なるのはトランスポート層だけです: この経路では OAuth のベアラートークンを運びます。
シートの ACL が最終的な権限者です。 誰が書き込めるかを決めるのは SheetForge ではなく Google です。Google からの 403 は、部分的な書き込みではなく 正直な権限エラーメッセージ に変換されるため、拒否は拒否として読み取れます。

OAuth トークンはセッション Cookie(JWT)に保持され、サーバーアクションから使用されます。唯一の例外は、次に説明する Google のファイルピッカーです。これはページ内で動作する Google のウィジェットであるため、開くとページにあなた自身のセッション用の短命なアクセストークンが渡されます。

サインイン後のタブは Google からスプレッドシートを選択 から始まります: Google 自身のファイルピッカーがページの上に開き、スプレッドシートを選ぶと、その ID がパネルに収まり、インポートがひとりでに実行されます。選ぶという行為そのものが、drive.file のもとでそのファイルへのアクセス権をアプリに与えることにもなるため、一つの操作で両方が済みます。現在のスプレッドシート の行が、パネルが何を指しているかを示します。

ID を手入力することも引き続き可能です——これは 詳細設定: スプレッドシート ID から始める の折りたたみの下に移動しており、以前保存された ID は以前とまったく同じように動作し続けます。正直な落とし穴もそこに明記されています: Google は少なくとも一度は選んだことのあるファイルしか開かないため、一度も選んだことのないファイルの ID は、あなたがそれを選ぶまで拒否されます(下記の ファイルアクセスを許可… の行がその場合をカバーします)。

アプリのためにファイルを開く — 一度だけ

drive.file のもとでは、権限はファイルごとに増えていきます。アプリがまだアクセス権を持っていないスプレッドシートに行き当たった場合——詳細設定の下で入力した ID や、アカウントを切り替えた後の保存済み ID など——権限エラーに行き当たった瞬間、そのスプレッドシートをあらかじめ検索済みの状態で Google 自身のファイルピッカー が開きます。一度そのファイルを選択すれば、開始していた取り込みや push はそれだけで完了します。それ以降、そのスプレッドシートはこれまでどおりに動作します。

事前に準備することは何もありません。 あらかじめアクセス権を付与しておく必要はありません。ピッカーは必要になったまさにその瞬間に、対象のファイルがプリセットされた状態で表示され、選択後にはあなたが求めていた操作が自動的に再試行されます。
再付与はいつでも手元にあります。 Google パネルには、いつでも同じピッカーを開ける ファイルアクセスを許可… という項目が常に用意されています——たとえば別の Google アカウントに切り替えた後などに使えます。
正直な境界線です。 ピッカーはページ内で動作する Google のウィジェットであるため、使用中はページがあなたのセッション用の短命なアクセストークン(最長でも一時間だけ有効)を保持します。このトークンは、ログインを必要とする同一オリジンのエンドポイントから取得されます。これは、以下の鍵ファイルの経路がページに置いているのと同じ種類の信頼です——アプリの厳格な Content Security Policy がそれを守っています。トークンが保存されたりログに記録されたりすることはありません。

キーファイルタブは、ID フィールドを意図的にそのまま残しています: サービスアカウントには選ぶための、サインインしたブラウジングセッションが存在しないため、そのアカウントにシートを共有した上での ID が、そこでは引き続き正直な入り方です。

デプロイ済みサイト上では — ブラウザーが署名するサービスアカウントキーファイル

Google パネルの二つ目のタブは、サービスアカウントの JSON キーファイル を受け付けます。そのキーが行うことはすべて、あなたのブラウザーの中で起こります:

キーはサーバーに届きません。 ブラウザー自身がトークンリクエストに署名し、Google の API を直接呼び出すため、キー・署名済みリクエスト・アクセストークン・あなたのシートデータは、いずれも SheetForge のサーバーに触れません。サーバー側のサービスアカウント用ルートは、デプロイ済みサイトでこれまでどおり 閉じられたまま(501)です——この経路は、何かを開くことなく新しい能力を追加します。
キーを記憶することについて、何が保存されるかを正直に伝えます。 キーを記憶させることを選んだ場合、ファイルのテキストはただちに破棄されます。保存されるのは——その端末上の、ブラウザーのストレージの中に——ページ上のスクリプトが使うことはできても決して読み出すことはできない署名用キーです。そのブラウザープロファイルを開ける人であれば、それでも復元できてしまうため、その端末はキーファイルそのものと同じように扱ってください。キーを忘れる を押すと、開いているすべてのタブで即座に削除され、アプリは Google に現在のアクセストークンの取り消しも求めます。
プランも検証も同じです。 読み取りと書き込みは、他の経路と同じコアのプランと同じ送信前検証を通じて実行されます。

Unity / ローカルの経路

Unity とローカル開発サーバーが使うサービスアカウントキーは、マシンローカルのパス から読み取られ、アップロードされることも同梱されることも決してありません——これは Google シートの設定で説明されているのと同じキーです。Assets/ の外、かつリポジトリの外に置いてください。リポジトリには認証情報が一切含まれていません。

push のたびにドロップダウンが更新される

Web アプリから push すると、シートのデータ入力規則のドロップダウンは自動的に書き換えられます——すべてのタブが一つのバッチで処理され、参照列のドロップダウンは 対象シートのキー列全体を範囲とする 形で書き込まれるため、レコードが追加されるにつれて自動的に広がります。存在しないシートタブを対象にしたルールはスキップされ、その旨が報告されます。これは、エディターの Google への push が書き込む内容と一致します。

どの経路が何をするか

実行場所	Google の認証情報	読み取り	書き込み
Unity / ローカル	サービスアカウントキー、マシンローカルのパスから読み取り	可能	可能 — 精密なセル単位の書き込み、構造の書き換え、Push
デプロイ済みサイト	サインインしたユーザーの OAuth トークン(`drive.file`——アプリのために開かれたファイル)	可能	可能 — 同じコアのプラン + 楽観的ロックの検証
デプロイ済みサイト	あなたが選んだサービスアカウントキーファイル、ブラウザーが直接使用	可能	可能 — 同じコアのプランと検証、リクエストはブラウザーから直接 Google へ
デプロイ済みサイト	サーバー側のサービスアカウント用ルート	—	閉じられている(`501`)

書き込みの挙動は、どこで実行しても同一です。すべての経路が、同じコアのプランと、送信前の検証を共有しているためです。異なるのはトランスポート——ブラウザーが署名するサービスアカウントトークンか、ユーザーごとの OAuth ベアラーか、ローカルサーバーのキーか——だけです。