Geminiを使っているだけでは業務は変わらない──ADHD管理職が6ヶ月で構築した『ひとりAI駆動オフィス』全設計図

Gemini for Workspaceで、毎朝のメール処理・スケジュール調整・返信ドラフト作成を自動化する業務アシスタントGemを構築した。
Gem 1つにシステムプロンプト約600行、ナレッジファイル4種を登録する。6ヶ月・約50回のイテレーションで磨いた設計済みプロンプト一式を、汎用テンプレートとして公開する。

この記事では、プロンプトの全文・ナレッジテンプレート・導入手順をセットで提供する。個人向けGeminiでもGmail・Calendar・ToDoリストへのアクセスは可能だが、Workspace Studioによる指名メール捕獲を含む全機能をフル活用するには、Google Workspace Business Standard以上を推奨する（後述するが、Workspace Studioはなくても動く）。

月曜の朝の受信トレイ

僕はADHD診断済みの50代中間管理職だ。ただ、この記事はADHD当事者に絞ったAI活用記事ではない。

日々浴びるように届くメール、Slack通知。複数の進行中プロジェクトのトラブル。部下からの割り込みの相談。大脳皮質の注意（アテンション）が枯渇し、重要なメールを見落とし、小さな判断を伴う返信を先延ばしにして自己嫌悪に陥る——これはADHDの特性であると同時に、情報過多社会で働く人間の普遍的な症状でもある（そうでしょ？）。

メール見落とし、割り込みタスクの忘却、スケジュールのブッキング。これらはすでに個人の注意力ややる気の問題ではない。処理すべき情報が多すぎるのだ。人間のワーキングメモリは有限だ。ADHDの僕が最初にぶつかった壁は、ADHD関係なく、管理職なら誰もが覚えのある壁だった（たぶん）。

Geminiは使える、でも足りない

僕は一年ほど前から仕事でGeminiを使っている。長いメールスレッドを要約させ、「とどのつまり、何？」を分析させたり、提案書の骨子を壁打ち相手にしたり。特にモヤモヤするセンシティブなメール下書きには便利。論理的かつ簡潔な主張を他人事のような熱量で書き上げてくれる。もちろん、モヤモヤが残れば最後に一行追加すればいい。これには未来を感じた。

でも、始業時に受信トレイを開く恐怖は消えなかった。

ブラウザを開いて「要約して」と頼んでいるうちは、AIはまだ業務フローの外側にいる。ツールである以上、使うか使わないかの判断は人間に委ねられ、疲れている時は「使うこと」さえ億劫になる。

「使う」と「組み込む」は違う

Geminiに「メール要約して」と頼む。要約は出る。翌日もまた「メール要約して」と頼む。要約は出る。翌日もその翌日も同じことを繰り返している。

これが「使う」だ。

「組み込む」は違う。Gemを作り、プロンプトを設計し、ナレッジを登録して、決まった品質で毎回再現する仕組みを構築する。

Gemini for Workspaceの「業務への組み込み」とは、Gemにシステムプロンプトとナレッジファイルを設定し、再現可能なタスク処理フローを構築すること。

「使う」と「組み込む」の差は、具体的にはこうなる。

毎回の入力
「使う」→ 都度「〜して、ただし前提は○○で、□□のメールは除外していい。あ、でも指名メールはピックアップしてほしい」と指示
「組み込む」→ 「DT-000（メールチェックタスク）を実行して」の一言

出力品質
「使う」→ 指示の書き方次第でばらつく
「組み込む」→ プロンプト設計で品質を固定

人名・社名の精度
「使う」→ Geminiが推測で補完。
「組み込む」→ ナレッジで正確な固有名詞を担保

セッション間の記憶
「使う」→ 毎回ゼロから始まる
「組み込む」→ Keep日報ログで前日の続きから

出力の検証
「使う」→ ユーザーが目視で確認
「組み込む」→ Guard監査で自動チェック

「使う」を「組み込む」に変えるには、3つのものが要る。

1. システムプロンプト: タスクの実行手順・分類基準・出力フォーマットを定義した制御ロジック。Geminiの癖や弱点を熟知した上でその穴を防ぐ。

2. ナレッジファイル: 人名・組織・文体・業務用語を登録した参照データ

3. 外部メモリ: セッション間でコンテキストを引き継ぐ仕組み（Google Keep + NotebookLM）

この記事では、この3つの設計済み完成品を提供する。

Gem 1つに600行

業務アシスタントGemは、以下のコンポーネントで構成される。

【Gem本体】
  └─ カスタム指示欄: システムプロンプト（約600行）
  └─ Knowledgeファイル:
       ├─ 登場人物・関係先一覧
       ├─ メールスタイルガイド
       ├─ 業務辞典（社内用語・型番）
       └─ 出力形式サンプル

【外部メモリ（短期）】
  └─ Google Keep: 日報ログ（日次更新・翌日自動読込）

【外部メモリ（長期）】
  └─ NotebookLM:
       ├─ Knowledgeファイル:
       │    ├─ 登場人物・関係先一覧
       │    ├─ メールスタイルガイド
       │    ├─ 業務辞典（社内用語・型番）
       │    └─ 出力形式サンプル
       ├─ 週報アーカイブ（DT-WEEKで週次登録）
       └─ プロジェクト振り返り（案件完了後に教訓・地雷を登録）

【突合検証（任意）】
  └─ Workspace Studio: 指名メール判定の自動ラベリング

各コンポーネントの役割と設計意図を説明する。

システムプロンプト（約600行/16,000文字）

Gemの「カスタム指示」欄に設定する制御ロジック。
6つのタスク（メールチェック・アクションプラン計画・スケジュール調整・メール返信・業務終了ログ・週報出力）の実行手順・判定基準・出力フォーマットを定義している。

これまでの経験と調査によって蓄積したGemini独特の癖・弱点の穴を完全に埋めた。プロンプトには「Absolute Rules（絶対規則）」として6つの不変ルールを組み込んでいる。根拠のない事実を断定しない、ツールを使っていないのに「確認しました」と言わない、固有名詞はツール結果からコピーする——Geminiが最もやりがちなミスを、プロンプトレベルで完璧封じている。

Claude Opus4.6やChatGPTｰ5.3 Codexといった最高知能AIによるクロスレビュー、Geminiの非公式な挙動・癖についての情報収集。コミュニティでの対話。

僕のAIとのやり取りの大部分は、このひとつのプロンプトをブラッシュアップすることに費やしてると言って過言ではない（ない）。

ナレッジファイル（4種）

Gemの知識欄にアップロードする参照データ。ナレッジをプロンプト本体から分離したのには設計上の理由がある。人事異動や取引先変更のたびにプロンプト全体を修正するのは危険だ。600行のプロンプトの一部を触ると、意図しない副作用が起きる。ナレッジに分離すれば、ファイルを差し替えるだけで済む。つまりシステムプロンプトの外付けアドオン。

登場人物・関係先一覧 — 社内メンバーの名前・役職・メールアドレス、主要顧客・取引先の担当者を登録する。また備考も記載する（携帯電話には出てくれないので必ずチャットかメールで連絡等）。
間違えが許されない人名については、正解なデータを外部から与える。また社内なのか社外なのか、どんなメンバーなのかを登録することでGeminiからの提案の現実性を高める。

メールスタイルガイド — 書き出し・語尾・署名・段落の長さなど、自分のメール文体を定義する。例えば「社名には前株も後株もつけない」「顧客名は元メールに氏名があっても氏＋様にする」など。Geminiによる返信案（ドラフト）が「自分の文体」で出力されるようにする。

業務辞典 — 社内略語、製品名・型番、取引先の正式名称を登録する。「AP」→「アクセスポイント」のような翻訳ルール。Geminiがこういった略語からハルシネーションを発生させないようにする。また毎月15日は中締めの日などの自社独自のルールを登録してもいい。

出力形式サンプル — 各タスクの期待される出力フォーマットの実例を登録する。本来ならシステムプロンプト内に記載すべき内容だが、システムプロンプトを少しでも圧縮するための外部化。
Few-Shot（実例提示）で出力品質のばらつきを抑制する。

日報ログ（Google Keep保存/短期記憶）

Gemini for Workspaceは、セキュリティの観点からスレッド間でのコンテキストメモリ共有を持たない。新しいチャットを開始すると、前のチャットで把握した相談の状況は引き継がれない。

この問題はGoogle Keepで解決する。業務終了時に、その日の対応案件・ステータス・未完了タスクをGoogle Keepに書き込む。翌朝のセッション開始時に、Gemが自動でそのNoteを読み込む。これで「昨日の続き」から始められる。

運用サイクルはこうなる。

Keepを選んだのは、GeminiがGoogle Keepのネイティブ操作（作成・検索・削除）に対応しているから。Gemの中からKeep ノートを直接作成・読み込みできる。

NotebookLM（長期記憶）

Keepの日報ログは「昨日の続き」を引き継ぐ短期記憶だ。「先月のプロジェクトの課題をどう解決したか」「A社案件の失注理由は」を振り返るには足りない。

NotebookLMが長期記憶を担う。格納するのは3種類のソース。

1. Knowledgeファイル4種（人名ログ・業務辞典・メールライティング方法・出力形式サンプル）——Gemのナレッジと同一のファイルを登録し、NotebookLM側でも横断検索できるようにする

2. 週報アーカイブ——毎週金曜にDT-WEEK（週報出力タスク）を実行し、Keep日報ログの5日分を集約した週報を登録する

3. プロジェクト振り返り——案件完了後に、教訓や地雷（「Aさんのスケジュール見積は実績の半分」「B社との会議には必ず議事録を送付（言った言ってないが多い）」「B社は見積精度が甘く、かつ、事後相談がある」）を個別に登録していく

週報と振り返りが蓄積されると、NotebookLMが過去案件の横断検索に答えられるようになる。「この取引先とはどんなやり取りが多いか」「過去に同じ失敗をしていないか」といった問いに対して、記憶に基づいた回答が返る。

Guard監査（出力の自動検証）

Geminiは事実と推測を混ぜる。日付を間違える。存在しないメールの内容を「確認しました」と言う。

このシステムでは、全ての出力の末尾にGuard監査サマリを自動付与し、ツール使用・日付・事実確認など複数項目をチェックする。NG項目がある場合は何が不足しているかを明示し、根拠が取れない情報には 【推定】 タグを自動付与する。もちろん、それでもGeminiはハルシネーションを起こす時がある。ここではその発生しやすさをユーザー側でどれだけ低減させるか、ということだ。

Guard監査の具体的なチェック項目と実装方法は、有料パートで解説する。

20分で動く

構築から日常運用までの流れを概要で示す。

STEP 1: Gem作成

Gemini for Workspace → Gem → Gemを作成。
名前と説明を記入。
（例:「業務アシスタント」「Workspaceを統合した業務支援」）

STEP 2: システムプロンプトの設定

カスタム指示に、システムプロンプト全文をペーストする。

なお、事前にプロンプト内のプレースホルダ（`{USER_NAME}`、`{COMPANY_NAME}`、`{COMPANY_DOMAIN}` 等）を、自分の情報に置換してください。

STEP 3: 知識（ナレッジ）ファイルの登録

知識に4ファイルをアップロードする。各ファイルはテンプレートを用意しているので、自分の情報を記入してからアップロード（ファイルの詳細は前セクション「ナレッジファイル（4種）」を参照）。

STEP 4: 初期動作テスト

新しいチャットを開き、「業務支援チャットを開始してください」と入力する。初期化シーケンスが走り、以下が出力されれば成功。

• セッション情報（日付・時刻の認識）

• 役割の自己言語化

• Absolute Rules 6項目の箇条書き

• 対応タスク一覧（DT-000〜DT-WEEK）

• 読み込み済みナレッジ概要

• `[Ready - 初期化完了]`

STEP 5: 日次運用開始

朝:「DT-000タスク（メールチェック）して」→ 直近48時間のメールを全件取得 → 🔴要返信・🟡要把握・⚪参考に自動分類 → 次アクション提案

夕:「業務終了。DT-ENDを実行」→ 当日の作業内容をサマリ化 → Google Keepに日報ログとして保存。

STEP 6: 週次運用（週報出力）

金曜夕方:「DT-WEEK（週報）お願い」→ 保存された日報ログ5日分を集約 → 週報で出力 → ユーザーがNotebookLMに登録

所要時間の目安: STEP 1-3は約20分、STEP 4は約5分。STEP 5以降は日常運用。

6つのトリガー

このシステムには6つのタスクが定義されている。各タスクは「トリガー → 実行フロー → 出力フォーマット」が固定されており、毎回同じ品質で動作する。

DT-000 メールチェック
トリガー:「メールチェックして」
直近48hのメールを全件取得 → 本文を読み文脈分析 → 🔴🟡⚪に分類 → 分類リスト + 次アクション提案

DT-001 アクションプラン
トリガー: DT-000直後に自動提案
Calendar + ToDoリスト + メール分類 + Keep日報ログを統合 → 時系列の優先順位付きプラン

DT-002 スケジュール調整
トリガー:「日程調整して」
カレンダー参照 → 移動時間・バッファ考慮 → 3案比較 → 候補日時 + 日程打診文

DT-003 メール返信
トリガー:「返信ドラフト作って」
スレッド経緯を読込（3通以上） → ユーザー文体で作成 → 返信ドラフト + 確認事項

DT-END 業務終了
トリガー:「業務終了」
当日の対応案件をサマリ化 → Keep日報ログ書き込み → セッションサマリ + Keep書込

DT-WEEK 週報出力
トリガー:「週報お願い」
Keep日報ログ5日分を集約 → 週報生成 → 週報ログ（NotebookLM登録用）

メールチェック（DT-000）の動き方

最も使用頻度が高く、最も設計に手間をかけたタスク。

「メールチェックして」と入力すると、直近48時間のGmailを全件取得する。Geminiが1回に取得するメールはデフォルトで100件程度。100件に達した場合は自動的に期間を分割し、残りを追加取得する。取りこぼしリスクを低減する設計（0件・上限到達時の再取得手順あり）。

取得したメールは本文全体を読み、以下の基準で分類する。

• 🔴 要返信: 自分宛の依頼・質問・クレーム・催促・リスク案件

• 🟡 要把握: 共有アドレス宛の障害報告・他メンバー宛の進捗・判断に影響する情報

• ⚪ 参考: CC中心。スレッド経緯を3行以内で要約

また名指し検出ロジックを組み込んでいる。
メール本文内に自分の名前（敬称付き）が検出された場合、他の条件に関わらず自動的に🔴に昇格する。「CCだが本文で名指しされている」メールの見落としを防ぐ仕組み。

分類後、Workspace連携提案（ToDo登録・Calendar登録・Keep一時メモ）を自動で出す。ユーザーが番号を指定するだけで登録が実行される。

安全装置

Geminiに業務を任せる以上、出力の信頼性を構造的に担保する仕組みが要る。このシステムでは、Guard監査（出力の自動検証）、【推定】タグ（確信度の低い情報の自動マーキング）、Absolute Rules（6つの不変ルール）、名指し検出ロジック、0件時の自動リトライ——5つの安全装置を各タスクに組み込んだ。

安全装置の具体的な実装（Guard監査5項目の定義、Absolute Rulesの全文、各ルールの設計意図）は、有料パートのシステムプロンプト本体に記載している。

ここから先

6ヶ月で踏んだ地雷の話をしよう

このシステムはもちろん最初から安定していたわけではない。Geminiのできること、その挙動も日夜変わる。考えて、試して、見直して…そういう6ヶ月・約50回のイテレーションーーつまり50回の失敗の記録でもある。

たとえば、初期のころはGmailに上手く接続していないのに、接続した体で回答してきたことがあった。
存在しない顧客名、存在しない会社名。これはなんだと尋ねたら、セキュリティ上マスクしたという回答だった。嘘つきなのではない、たぶんGeminiは本気でそう信じていたんだと思っている。

このようにツール（Workspace）を呼んでいないのに、呼んだふりをすることは多い。だからAbsolute Rules（絶対規則）の「ツールを使っていないのに『確認しました』と言わない」は、この地雷を踏んだから生まれたルールだ。他の5つのルールにも、それぞれ「踏んだ地雷」がある。

有料パートでは、こうした地雷を踏まずに済む設計済みの完成品を提供する。

有料パートに含まれるもの

1. システムプロンプト全文（汎用テンプレート版・約600行）— プレースホルダを自分の情報に置換するだけで使える

2. ナレッジテンプレート4種（記入ガイド付き）— 登場人物一覧・スタイルガイド・業務辞典・出力形式サンプル

3. Workspace Studio用プロンプト — 指名メール判定の自動ラベリングで、Gem分類との2系統突合検証を実現

4. 詳細導入ガイド（STEP 1-6の詳細版）— プレースホルダ一覧・初期化チェックリスト・トラブルシューティング付き

5. カスタマイズガイド — メール分類ルールの変更・タスクの追加削除・自分の業務への適応方法

前提条件（購入前に必ず確認）

個人向けGeminiでも、そのアカウントに紐づいたGmail・Calendar（広義のWorkspace）へのアクセスは可能なため、Gem本体の基本機能は動作する。Workspace Studioによる指名メール判定の突合検証を含む全機能をフル活用するには、Google Workspace Business Standard以上を推奨する。

FAQ

Q. 機密メールが処理されるのが不安だ

プロンプト内に除外ルールを設定できる。特定の差出人ドメインやシステム通知メールの自動スキップが可能。Gemini for Workspaceでは、プロンプトや会話内容はCloud Data Processing Addendumの下で顧客データとして保護され、許可なくGoogleの生成AIモデルのトレーニングに使用されることはない。

Q. プログラミング知識は必要か

不要。コピー&ペースト + プレースホルダの置換で完結する。プレースホルダは `{USER_NAME}` のような形式で、何をどこに書けばよいかを記入ガイドで説明している。

Q. 自分の業務に合わせてカスタマイズできるか

できる。有料パートのカスタマイズガイドで、メール分類基準の変更方法・タスクの追加削除方法・ナレッジの更新手順を解説している。プロンプト内のカスタマイズポイントには
`<!-- ★カスタマイズ -->`
コメントを付けている。

Q. メールの取りこぼしが発生しないか

100件到達時の自動分割ロジックをプロンプトに組み込んでおり、取りこぼしリスクを低減する設計（0件・上限到達時の再取得手順あり）。実運用で欠落が疑われる場合は、期間指定を短くする（例: 48時間 → 24時間）ことで対処できる。

詳細導入ガイド

無料パートの概要STEPでは「何をするか」を示した。ここでは「具体的にどうやるか」を手順単位で解説する。

プレースホルダ一覧

このシステムのプロンプトとナレッジには、以下のプレースホルダが埋め込まれている。自分の環境に合わせて置換してから使う。

`{USER_NAME}` — 自分の名前（例: 田中）
`{USER_NAME_EN}` — 自分の名前の英語表記（例: Tanaka）
`{USER_EMAIL}` — 自分のメールアドレス（例: tanaka@example.co.jp）
`{USER_TITLE}` — 自分の役職（例: 営業部長）
`{COMPANY_NAME}` — 自社名（例: 株式会社サンプル商事）
`{COMPANY_DOMAIN}` — 自社のメールドメイン（例: example.co.jp）