Google AI Studio、スプシをデータベースにして簡易CRMなど自社業務データをUIに乗せる

顧客リストも案件管理も、結局スプレッドシートに戻ってきている会社は多い。kintoneやNotionを検討して、料金とデータの預け先で止まった経験を持つ人もいるはずだ。

先日、Google AI Studio がスプレッドシート連携に対応した。今回、試作したところ、自社のスプシをデータベースとして使い、UIだけを被せた業務アプリが30分で立ち上がった。データはスプシに残ったままになり、アプリからスプシのデータ操作も可能である。

できるようになること

30分後:

自社の業務スプレッドシートに、入力・編集・削除ができるアプリができあがっている
Googleログインで複数人が同じUIから読み書きできる
「スプシを業務SaaSに乗り換える」以外の選択肢を、自分の目で確認できている

その先:

「住所から最速ルートをマップ表示する」「条件分岐で入力フォームを変える」など、スプシ単体ではしんどい操作をアプリ側に逃がす
既存スプシの構造を変えずに、見せる相手ごとに違うアプリにする（営業向け／経理向け）

最終アウトプット

今回作ったのは、簡易な顧客管理アプリ（CRM）だ。スプレッドシートに顧客情報のテーブルを用意し、Google AI Studio上で次の操作ができるアプリを作った。

操作	動き
一覧表示	スプシのデータをカード／テーブル形式で表示
追加	UI上のフォームから入力 → スプシに行が追加される
編集	行を選択 → 編集 → スプシの該当セルが書き換わる
削除	行を選択 → 削除 → スプシから該当行が消える
再ログイン	Googleアカウントの連携情報が保存され、次回以降は連携をやり直さなくていい

データの実体は、最初から最後までスプシにある。Google AI Studio はあくまでスプシを読み書きするUIレイヤーになっている。

結論

30分で動く。スプシ側を変えずに、UIだけ被せる構造になる。

向いている人:

スプシで顧客・案件・在庫を管理していて、「入力フォームが欲しい」「複数人で触りたい」と感じている1人〜数人規模の事業者
kintone・Notion・Airtable などへの乗り換えを検討したが、料金・運用負荷・データの預け先で止まった会社
クライアントの業務を軽くするフリーランスや受託側で、短納期で動くものを渡したい人

向いていない人:

数十人で同時編集する、ミリ秒単位の整合性が要る業務。本物のデータベースを使うべきだ
既にスプシで限界が来ている規模（行数が数万、シート連携が複雑など）。素直にSaaSを選んだ方が早い
Googleエコシステム以外で運用したい組織

なぜkintoneでもNotionでもなくGoogle AI Studio × スプシなのかは、記事の後半「なぜスプシ側にデータを残すのか」で扱う。

30分を始める前に揃えるもの

前提条件:

Googleアカウント（無料）
Google AI Studio（https://aistudio.google.com/、Gemini 系の開発者向けプラットフォーム）
Googleスプレッドシート（無料）

全体の流れ:

AI Studio に「何を作りたいか」を伝える
対象スプレッドシートを準備する（カラム設計の最小例）
Google AI Studio とスプシを接続する（Googleログインと権限）
UIから読み書きを試す
再ログイン時の連携保存を確認する

工程1〜5で約30分になる。

商用利用範囲について（実業務投入前に必ず読む）

Google AI Studio は Gemini API を含めた開発者向けプラットフォームで、利用規約・料金・商用範囲は今後変動する可能性がある。実業務に投入する前に、自分のユースケースで以下を確認してほしい。

Google AI Studio の利用上限（無料枠のレート制限、Gemini API の課金条件）
公開・配布の可否（社外メンバーに共有する場合、誰がコストを負担するか）
顧客データを扱う場合のデータ取り扱いポリシー
商用利用の明示的な許可有無（規約原文を読む）

この記事は手順の説明であって、規約の保証ではない。 実クライアント業務に投入する前に、公式のGemini API 利用規約を自分の目で読むことを強く勧める。

30分を5ステップに割る

ステップ1：Google AI Studio に「何を作りたいか」を伝える

最初にやるのは、Google AI Studio を開いて、作りたいものを言葉にすること。

私が試作したときに最初に投げたプロンプトは、こうだ。

作成したいアプリは、Googleスプレッドシートをデータベースにした顧客管理アプリです。
顧客のデータは、Googleスプレッドシートから参照する。
参照したデータを元に、顧客の管理ができ、アプリ側で行った操作（例えば、契約中から解約のステータス変更）をスプレッドシートにも反映させたい。
対象のスプレッドシートは、ユーザーが選択できるような設定を設ける。スプレッドシートのデータとアプリに表示するデータは設定から連携できるようにする。

Google AI Studioのチャットで指示

Google AI Studio は「スプシ連携を使う」「カラム構成は何にする？」と返してくる。この段階で、頭の中にあるカラム構成を伝える。

顧客ID、会社名、電話番号、メール、メモ、最終接触日、ステータス。

カラム名は後から変えられるが、ここで一度決めておくと後の手戻りが減る。

ポイント: Google AI Studio に「いい感じに作って」と投げると、ボヤけた汎用CRMが返ってくる。自社のスプシで使われている語彙（「顧客」ではなく「クライアント」と呼んでいる、「最終接触」ではなく「直近商談」など）をそのまま伝える。アプリ側がスプシの言葉に合わせてくれる方が、運用に乗りやすい

ステップ2：対象スプレッドシートを準備する

スプシ側の準備は、思っているより軽い。

新しいGoogleスプレッドシートを作る（既存スプシを使うなら、対象シートを決める）
1行目に、ステップ1で伝えたカラム名を入れる
数行ダミーデータを入れる（テストで確認するため）

カラム名は半角英数字でなくて構わない。日本語のままで動く。

Googleスプレッドシートを準備

ポイント: スプシのシート名は、後で接続時に指定する。既存スプシを使う場合は、対象シートURLまたはID（URL末尾の英数字）を控えておく。

ステップ3：Google AI Studio とスプシを接続する

Google AI Studioで最初に指示した作りたいものが完成しているか確認し、Googleログイン・スプシとの連携を行っていく。

もちろん、アプリそのものを作っているため、「Googleログインではなく、メール登録したい」や「スプシはURLだけで接続できるようにしたい」など仕様そのものを変えていくこともできる。

今回は、シンプルにGoogleログインをベースにした。

Googleログインでアカウントを連携して使うように構築

Google AI Studioの画面で、スプレッドシートのリンクまたはIDを接続して設定を保存すれば準備完了。この設定画面も自分の指示で作っている。

Google AI Studio はスプシのカラム構造を読み取って、UIのフィールドを自動でマッピングしてくる。マッピングが意図と違っていたら、その場で修正もできるようにした。

スプシを連携する設定画面を作成

ポイント: アプリそのものを作っているため、どの画面で何が行えるのか、この画面の目的とゴールは何かを自身で設計する必要がある。もちろんAIと相談しながらでOK。

ステップ4：UIから読み書きを試す

接続が通ったら、UIから操作してみる。

顧客一覧画面: スプシのダミーデータが、Google AI Studio 側のUIで一覧表示される
ダッシュボードの数値表示：顧客のステータスを変更すると、数値が変動する
追加: 「新規顧客追加」から新規入力 → スプシを開くと、最終行に追加されている
編集: 顧客の「詳細」を選択 → 編集 → スプシの該当セルが書き換わっている
削除: 顧客の「詳細」を選択 → 削除 → スプシから該当行が消えている

アプリを実際に操作して使用感を確認

ここまで動けば、ミニCRMとしては十分機能している。

ポイント: 曖昧な指示でもGoogle AI Studio（Gemini）がいい感じに作り込んではくれる。しかし、作成時に明確な指示があるとなお想定通りになるので、いきなり作り始めるはおすすめしない。

ステップ5：再ログイン時の連携保存を確認する

最後に、ブラウザを閉じて再ログインしてみる。

Google AI Studio の連携情報（どのGoogleアカウントで、どのスプシに繋いでいるか）が保存されていれば、次回以降は連携をやり直す必要がない。これが保存されない場合は、業務に投入したときに毎回再接続を求められて面倒。

試作時点で、私の環境では連携保存が動いた。ただし、Googleアカウント側のセッション切れや、Google AI Studio のアプリ構成変更で挙動が変わる可能性はある。本番投入前に、想定する利用頻度で再ログイン挙動を確認しておくのが安全だ。

今回はここまでを顧客管理システムの要件として、Google AI Studioで作成してみた。もちろんここからさらに発展させて、Salesforceのような作り込んだものにしたり、自社の業務フローに適合した仕様にしていくこともできる。

ポイント: これはエンジニアとして開発を行うのと同じ工程や思考が必要になってくる。開発スキルは必要ないが、どうやってアプリやサービスを作っていくのかというノウハウは重要。試験運用から知見を積み上げていく必要はある。

なぜスプシ側にデータを残すのか

ここまで読んで、「結局これはノーコード業務アプリの一種で、別にGoogle AI Studio でなくてもいいのでは」と感じる人もいると思う。

違いは、データの置き場所にある。

読者                AI Studio              スプシ
───              ───────              ───
UI操作   ──▶   APIとして仲介  ──▶   実データの置き場
（追加/編集/削除）   （ロジック）          （会社の資産）

UIレイヤー（Google AI Studio）と、データレイヤー（スプシ）が分かれている。AI Studio のアプリを止めても、スプシは残る。Google AI Studio から別のツールに乗り換えても、データはスプシから取り出せる。会社の業務情報が、外部SaaSのDBに人質にされない構造になっている。

これは、業務SaaSの一般的な構造と逆だ。SaaSは「データを自社のDBに預けてもらう」ことで顧客を囲い込む。乗り換えコストはデータの取り出し・再投入の負担として顧客にかかる。料金が上がっても辞めにくい。

Google AI Studio × スプシは、囲い込みの矢印が逆向きになる。UIだけを差し替え可能な構造にしておけば、ツールベンダーへの依存を最小化できる。

業務SaaSへの乗り換えを検討する前に、この設計を一度試してから決めても遅くはないと思う。

ハマりどころ・落とし穴

試作で気になった点を、率直に書いておく。

アクセス権限が広めにかかる: Google AI Studio に「スプシを読み書きしていい」と一度許可すると、その許可は対象の1枚のスプシだけでなく、同じGoogleアカウントで開けるスプシ全部に効いてしまう。私用と業務のスプシを同じアカウントで管理していると、思わぬスプシまでアプリ側からアクセス対象になる。業務で使うなら、業務専用のGoogleアカウントを切ってそこで設定するのが安全
同時編集の挙動: 同じレコードを複数人がほぼ同時に編集した場合、後勝ちで上書きされる可能性がある。整合性が要る業務（在庫・予約など）には、別途排他制御が必要になる
カラム名の変更: スプシ側で1行目のカラム名を変えると、UIのマッピングが崩れる。運用に乗せたあとは、カラム名を凍結するなど運用ルールを敷く
大量データ: 数千行を超えると、UI側の表示パフォーマンスが落ちる可能性がある。大規模データを扱うなら、本物のDBに移すべきだ
Google AI Studio の仕様変動: プレビュー段階の機能を含むため、UIや連携仕様が変わる可能性がある。本番運用に投入する前に、自分の用途で十分に試す
商用利用範囲: 既に触れた通り、規約を必ず自分の目で確認する

スプシ × AI で似たことを試した過去記事としてAIで請求書作成システムを作る。Gemini×スプレッドシート×GASを使って会話だけで完成があるが、あれは「裏で動くスクリプトをAIに書かせる」アプローチだった。今回は「UIごと別レイヤーで作る」アプローチになる。同じスプシを軸にしていても、できる体験の幅が違ってくる。

編集者あとがき

試作した直後に思ったのは、「これは構築工数の桁を下げる」だった。

業務アプリを作るとき、これまでは画面設計・DB設計・認証・データ入出力・ホスティングまで一通り組み立てる必要があった。1～3ヶ月の仕事だ。Google AI Studio × スプシは、その大半を肩代わりする。残るのは、対象業務をどんなカラムで切り出すかという、設計の一番おもしろい部分だけになる。しかも、自分たちの業務フローに合わせて細かくカスタムもできるのだ。

この変化が本当に効くのは、たぶん「クライアントの業務に小さく入る」場面だと考えている。

これまでは、業務システムを提案するハードルが高すぎた。要件定義に時間がかかり、見積もりが膨らみ、クライアント側で稟議が止まる。動くものを見せるまでに、何週間もかかった。30分で動くものが出せるなら、提案の温度が変わる。「とりあえず動かしてみて、合うかどうか触ってから決めましょう」が現実的になる。

一方で、これだけで全てがまかなえるとは思っていない。

ミリ秒単位の整合性、複雑な権限制御、高度なワークフロー、本格的なシステムに必要な要素は、Google AI Studio × スプシの守備範囲を超える。試作で動いたものを、そのまま100名規模の業務に乗せると壊れる。スプシの限界に当たる。

それでも、「何も考えずに業務SaaSに乗り換える」と「何もしない」の間に、新しい選択肢が増えたことには意味があると思う。

スプシを残したまま、UIだけ被せる。データの所有権はクライアントに残る。ツールを乗り換えるときの摩擦は最小になる。この設計が選べる時代が始まっている。

本番クライアント投入で気づきが出たら、続編を書く。今日のところは、自分のスプシで試してみてほしい。

Author