Gemini APIを社内ツールで使う前に。無料枠の規約とキー管理

GASで社内ツールを作っていると、入力された文章を要約する、問い合わせを分類する、返信の文案を作る、といった処理を足したくなる場面が必ず来ます。
「このツール、AIに要約までさせられたら便利なのに」という声は、現場からもよく上がります。

そこでGemini APIを業務で呼ぼうとした瞬間に、無料枠の規約と、有料枠の課金と申請という2つの壁にぶつかります。
ここでは、無料枠を業務に使えない理由と、APIを使わずにAI処理を組み込む構成、APIが必要なときのキーとプロジェクトの管理方針を、社内ルールとして整理します。

自動化の手段とコストの全体像は、AIによる業務自動化の全体像。手段の選び方とコスト設計にまとめています。

社内ツールづくりは、AIを呼ぶところで止まる

Google Workspaceの会社なら、社内ツールはGoogleサイトやGASで作って配るのが安全で扱いやすく、外部のサービスを契約せずに組織内で公開まで完結できます。

ただ、ツールの中で「都度AIに何かさせたい」となると、GASの標準機能だけでは埋まらず、AIを呼ぶ必要が出てきます。
多くの現場は、ここで手が止まります。
作れる人がいないからではなく、試すまでの距離が遠いからです。

無料枠は、規約上業務データを送れない

まず、無料枠で済ませようという発想が出てきますが、業務データを扱う場面では選べません。
Gemini APIの利用規約では、無料枠について「機密情報や個人情報を送信しないでください」と明示されています。
無料枠で送った内容はGoogleのプロダクトの改善に使われ、人間のレビュアーが入力と出力を読んで注釈を付けることがある、とされているからです。
議事録、商談のメモ、社内文書、問い合わせの内容など、社内ツールが扱うのはまさにこうしたデータなので、無料枠は最初から候補から外れます。

有料枠であれば、「プロンプトもレスポンスも製品改善に使わない」と明記されています。

入力した情報が学習に使われるかどうかの違いは、AIに入力した情報は学習される？無料版・法人版・APIの違いを整理で詳しく扱っています。

有料枠にすると、今度は試すまでの距離が遠くなる

そこで有料枠にすると、APIキーを発行して自前のツールから呼び始めた時点で、従量課金の領域に入ります。
自分が試すたびに会社に費用が発生するので、金額は小さくても「これ、いくらかかっているんだろう」と気にしながら手を動かすことになります。
ツールづくりは、プロンプトを何度も書き直して試すのがいちばん効きますが、その試行の回数がそのまま費用になると、そこで手が止まります。

さらに、費用が発生すれば、利用の申請や費用の承認、予算の出どころ、情シスへの相談といった手続きが要ります。
会社によっては、これだけで何週間かかかります。
「ちょっと作ってみたい」の段階でこの手続きを通そうとする人は、ほとんどいません。

従量課金の予算と上限の決め方は、AI利用の従量課金をコスト設計する。予算とガードレールの決め方で扱っています。

AIを呼ぶ部分は、定額の自動化フローに寄せられる

そこで選択肢になるのが、「GASからAIを呼ばない」構成です。
AIを使う部分はWorkspace Studioにやらせて出力をスプレッドシートに書き出し、GASのツールはそのシートをデータベースとして読みます。
Studioは普段のWorkspaceの契約の枠内で動くので、使うほど費用が増える設計ではなくなり、APIキーの管理も社内の申請も要らなくなります。
情シス側の統制も、Studioのステップの許可設定でまとめてかけられます。

組み方は3通りあります。

• 事前生成型：Studioを定期実行して結果をシートに書き溜め、ツールは読んで表示するだけにする

• キュー型：ツールがシートに依頼を1行書き、Studioがそれを開始条件にして同じ行に結果を書き戻す

• マスタ生成型：分類の定義や返信のテンプレートをStudioで作ってシートに置き、ツールは参照だけする

例えば週次レポートの要約や問い合わせの分類済み一覧なら事前生成型で足り、待ち時間もありません。
キュー型は数十秒から数分の待ちが出るので、画面には先に「受け付けました」と返す作りにします。

なお、Canvasアプリで作るツールも定額の範囲で動き、APIキーを空欄にしておく指示を入れれば従量課金を避けられます。

スプレッドシートをデータベースとして扱うときの設計は、スプレッドシートを社内DBとして扱う。AI自動化の土台設計にまとめています。

即時の応答と大量の処理は、この構成に向かない

もちろん、この構成にも合わない場面があります。
ユーザーの入力にその場で返す必要があるなら届きません。
Studioにつなぐ場合は、モデルを細かく選べない制約もあります。
一言でいうと、1件ずつ確実に、大量に、速く処理したいのであれば、APIを使うのが正解です。

また、シートに中身が残るので、シートの共有範囲を設計しないと、そこが情報の出口になります。
むしろここが本番の管理ポイントです。

APIを使うなら、キーは情シスのプロジェクトに集約する

APIを使う場合も、各メンバーがそれぞれキーを持つ形にはしません。
情シスが管理するプロジェクトを用意して、そこに集約します。

ここで知っておきたいのが、課金はAPIキーの単位ではなく、Google Cloudのプロジェクトの単位で効くという点です。
既存のキーと同じプロジェクトで課金を有効にすると、そのプロジェクトのキーが一斉に有料になります。
逆に、用途ごとにプロジェクトを分けておけば、業務データを扱うものは課金するプロジェクト、公開情報だけの試作は別のプロジェクト、という形で課金と規約の範囲を区切れます。

つまり、選択肢は「全員がAPIキーを持つ」か「誰も持たない」かの二択ではありません。

キーを入れたツールを公開すると、課金を他人に使われる

キーの管理でもうひとつ決めておくのが、キーを内部で使うツールの公開範囲です。
GASの中でAPIキーを使って処理するツールを「全員」に公開すると、キーそのものは漏れなくても、利用枠と課金を第三者に使われるおそれがあります。
Canvasアプリから呼ぶGASのURLは、アプリのHTMLソースに平文で書かれるので、共有した時点で誰でも読める状態になります。

GASはSLAの対象外で、作成者の権限で動く点もあわせて、キーを入れたツールは公開範囲を「自社ドメイン内」に絞るか、審査を通してから出すことをルールにしておきます。

API利用の社内ルールを、一緒に決めるところから

無料枠の扱い、プロジェクトの分け方、ツールの公開範囲は、使っている基盤や情シスの体制によって決め方が変わります。

私たちが提供しているAIコンサル＆伴走支援でも、AI利用のガイドラインづくりから、社内ツールでAIを使うときのルールの整理までを伴走しています。
現場の「作りたい」が申請の手前で止まっている場合は、進め方の参考になるかもしれません。

最初に考えるのは、AIを外に出さずに作れるか

社内ツールを作るとき、最初から「AIはAPIで呼ぶもの」と決めてしまうと、課金と規約の話でそこで止まります。
AIの出力を、あらかじめ用意したデータに変えられないかを先に考えると、現場のメンバーが自分で作れる範囲はかなり広がります。
そのうえで、APIが本当に必要な処理だけを、情シスが管理するプロジェクトに通します。
今作ろうとしているツールのAIを使う部分が、事前に作っておける形に変えられないかを、作り始める前に一度確かめてみてください。