個人でアプリを運営していると、コードを書いている時間よりも「それ以外の業務」に追われている時間のほうが長い日があります。ユーザーからの問い合わせメール、ストアのポリシー更新の確認、広告収益レポートの集計。会社であれば部署ごとに分かれている仕事が、ひとりの手元に全部降ってきます。
私が Gemini を業務側に組み込み始めたのは、この「開発以外の雑務」が開発時間を侵食している、と気づいたことがきっかけでした。壁紙アプリを複数並行で運営していると、雑務は減るどころか毎年少しずつ増えていきます。ここでは、実際に手を動かして定着した使い方と、試したけれど手放した使い方の両方を、率直に書いてみます。
最初に効いたのは問い合わせメールの返信下書きでした
一番時間を奪われていたのは、英語での問い合わせ対応でした。海外ユーザーからのメールは内容自体は単純でも、失礼のない英文を組み立てるのに毎回 15 分ほどかかっていたのです。
Gemini に任せるようになってからは、次のような指示で下書きを作っています。
以下のユーザーからの問い合わせに対する返信を英語で書いてください。
- トーン: 丁寧だが堅すぎない
- 伝える内容: 報告された壁紙の表示不具合は次回アップデートで修正予定
- 含めること: 報告への感謝、修正時期の目安（来週中）
- 含めないこと: 過度な謝罪、技術的な詳細
ポイントは「含めないこと」まで指定する点です。これを書かないと、英文サポートメールの定型に引きずられて謝罪過多の長文が返ってきます。生成された下書きはそのまま送らず、修正時期などの約束事項だけは必ず自分の手で確認してから送っています。約束は AI ではなく自分がするものだ、という線は守りたいと考えています。
規約やポリシーの更新は「差分と影響」を聞く
ストアや広告プラットフォームのポリシー更新の通知は、読むのを後回しにしがちな文書の代表です。以前は全文を斜め読みして重要な変更を見落としかけたことがありました。
いまは更新文書を渡して、要約ではなく「差分と影響」を聞くようにしています。
このポリシー更新文書を読んで、次の観点で整理してください。
1. 前回の版から実質的に変わった点
2. 壁紙・画像系アプリの運営者に影響する箇所
3. 対応が必要な場合、その期限
観点を与えずに「要約してください」とだけ頼むと、誰にでも当てはまる一般論が返ってきます。「自分のアプリにとって何が変わるのか」という聞き方に変えてから、出力がそのまま対応タスクのリストとして使えるようになりました。これは要約させる場面すべてに共通するコツだと感じています。
レポート分析では数式より「どの数字を見るべきか」を聞く
収益レポートの分析にも使っています。AdMob のレポートを月次で眺めるとき、以前は eCPM や表示回数の増減を目で追って原因を推測していました。いまはデータを渡して、こう聞きます。
「先月と比べて収益が下がった要因として考えられる組み合わせを、このデータから挙げてください。」
返ってくるのはあくまで仮説ですが、「特定の国の eCPM 下落」「特定フォーマットの表示回数減」など、自分の思い込みの外にある観点を出してくれるのが価値です。Google Sheets 上であれば、複雑な VLOOKUP やピボットの数式を自然言語から組み立ててもらう使い方も安定しています。
ひとつだけ注意しているのは、集計値そのものを Gemini の出力で確定させないことです。合計や比率の計算は稀にずれることがあるため、最終的な数字は必ずスプレッドシートの数式側で検算しています。仮説出しは任せて、確定は任せない。この分担が私には合っていました。
スライドと議事録は、正直それほど使っていません
ビジネス活用の文脈ではスライド自動生成や議事録要約がよく紹介されますが、私の働き方では出番がほとんどありませんでした。ひとりで事業を回していると、定例プレゼンも会議メモも存在しないからです。
ただ、これは私の事業形態がそうだというだけの話です。チームで定例報告がある方なら、フォーマットの決まった資料のドラフト生成は時間短縮になるはずです。道具の価値は機能の一覧ではなく、自分の業務のどこに当てはまるかで決まる、というのが試してみての実感でした。
無料版と Workspace 版で一番大きいのはデータの扱いの差です
業務利用で機能よりも先に確認すべきなのは、入力したデータがどう扱われるかだと考えています。Google Workspace 経由で提供される Gemini は、入力内容がモデルの学習に使用されない設計で、組織のデータ管理ポリシーの中で運用できます。無料の個人向け環境とはここが根本的に違います。
私自身は、ユーザーのメールアドレスや問い合わせ文面を扱う作業は Workspace 環境の中だけで行い、一般的な調べものは個人環境で行う、という使い分けにしています。なお、プラン構成や料金は改定が続いているため、ここに表を書き写すよりも Google Workspace の公式ページ で最新の条件を確認していただくのが確実です。
繰り返す指示は Gem にして「業務の道具棚」を作る
使い方が定着してくると、同じ前提を毎回打ち込んでいることに気づきます。問い合わせ返信なら「壁紙アプリの運営者として」「丁寧だが堅すぎないトーンで」という前置きが毎回必要になり、これ自体が小さな雑務になっていました。
Gemini には、指示と前提をまとめて保存しておける Gems という仕組みがあります。私は「サポート返信」「ポリシー読解」「レポート分析」の 3 つを Gem として固定し、それぞれに前提条件と出力形式をあらかじめ書き込んでいます。たとえばサポート返信の Gem には、アプリの概要・返信で守るトーン・絶対に約束してはいけない事項（リリース日の確約など）を入れてあります。
こうしておくと、毎回の入力は問い合わせ本文を貼り付けるだけになります。プロンプトの工夫を「その場で思い出すもの」から「道具棚に置いてあるもの」へ変えられたことが、結果的に一番の時間短縮になりました。業務で繰り返し使う指示が 2 つ以上あるなら、Gem 化を検討する価値があります。
任せる仕事と、任せない仕事
数年使ってきて、線引きはシンプルなところに落ち着きました。下書き・要約・仮説出しといった「自分が後から直せる仕事」は積極的に任せます。一方で、ユーザーへの約束、確定した数字の報告、規約解釈の最終判断といった「間違えたときに自分以外へ影響が出る仕事」は、時間がかかっても自分の手に残しています。
効率化というと任せる範囲を広げる話になりがちですが、実際には「任せない領域を先に決める」ほうが安心して任せられるようになります。それが、ひとりで事業を回す中で見えてきた私なりの答えです。
まずは受信箱の中から「返信が億劫で放置しているメール」を 1 通選んで、下書きを作らせるところから始めてみてください。小さく始めて、自分の業務に合う場所を探していくのが確実です。同じようにひとりで多くの業務を抱えている方の参考になれば幸いです。