Google AI Onboarding — Hands-on Manual

Google AI 導入マニュアル

Gemini・Google Workspace・Workspace Studio を業務に導入し、
安全に運用するための準備・設定・ルールをまとめたマニュアル。

Ver. 1.0
Powered by Google
Agenda

本マニュアルの構成

01

導入の全体像

製品マップ・選定基準・共通設計

02

Geminiアプリと個人AI

Deep Research・Canvas・Gems・Spark

03

Workspace 実務

Gmail・Docs・Sheets・Meet・NotebookLM

04

自動化と企業AI基盤

Workspace Studio・Gemini Enterprise

05

開発・モデル・Labs

AI Studio・Antigravity・Gemma 4・Flow

06

運用・安全と導入支援

安全ルール・チェックリスト・導入ロードマップ

Section
01

導入の全体像

Google AI を「層」で整理し、どの業務にどの製品を使うかの選定基準と、実装前の共通設計を押さえる。

Chapter 01 — Product Map 1/2

製品マップ①：業務で使う層

「Gemini」の名称だけで理解せず、データとアクションの層で分けると選びやすい。

層代表ツール使いどころ
個人AIGeminiアプリ・Live・Deep Research・Canvas・Gems・Spark調査、文章化、対話、試作、個人の思考補助
業務アプリ内AIWorkspace with Gemini（Gmail・Docs・Sheets ほか）既存のGWS業務を作成・要約・検索・分析に拡張
ノーコード自動化Workspace Studio定型連絡・承認依頼・会議後フォローのフロー化
企業AI基盤Gemini Enterprise App社内検索、部門別エージェント、データ横断利用

※ AIが「書くだけ」なら Geminiアプリや Workspace で足りる。AIが「動く・接続する・更新する」なら Studio／Enterprise へ進む。

Chapter 01 — Product Map 2/2

製品マップ②：開発・モデル・Labs の層

エージェント開発・API組み込み・オープンモデル・クリエイティブ試作はこちらの層から選ぶ。

層代表ツール使いどころ
本番エージェント開発Agent Platform / Vertex AI・ADKRAG・ツール実行・監視・評価・IAMを含む開発
開発支援Antigravity・Gemini CLI・Code Assist・Jules・Stitchコード生成、改修、レビュー、UI設計、PR作成
モデル / APIAI Studio・Gemini API・Veo・Imagenアプリ組み込み、構造化出力、画像/音声/動画生成
オープンモデルGemma 4ローカル実行、オンプレ/エッジ、データ主権重視
Labs / クリエイティブFlow・Flow Music・Mixboard・Pomelli ほか動画、音楽、構想ボード、ブランドコンテンツ
Chapter 01 — Selection

選定フローチャート

「何をさせたいか」ではなく「どのデータへアクセスさせ、どのアクションを許可し、誰が最終承認するか」で選ぶ。

  • GWSアプリ内で完結するか。完結するなら Workspace with Gemini から始める。
  • 複数アプリをまたいで毎週・毎日繰り返すか。Workspace Studio でフロー化する。
  • 社内ナレッジが Drive 以外にも散らばるか。Gemini Enterprise App を検討する。
  • 外部システムへの問い合わせ・更新まで任せるか。Agent Platform。開発タスクは Antigravity / Jules。
  • クラウドに出しにくいデータか。Gemma 4 を候補に入れる。クリエイティブ試作は Labs 系を使い分ける。
Chapter 01 — Prompt

プロンプト設計の基本型（6要素）

共通テンプレート（コピーして使う）
# ① 目的
{何を達成したいか}
# ② 役割
あなたは{専門家 / 担当者 / レビュアー}です。
# ③ 参照情報
{ファイル、メール、表、会議メモ、範囲}
# ④ 作業手順
1) {抽出} 2) {分類} 3) {生成} 4) {検証}
# ⑤ 制約・出力形式
{文字数、トーン、禁止事項、機密の扱い}
{表、箇条書き、JSON、メール文}
# ⑥ 確認事項
根拠がない箇所は「要確認」と書き、
推測と事実を分ける。
6要素

Role〜Review をそろえる

役割・参照・作業・制約・出力・確認。この型に沿えば誰でも同じ品質になる。

悪い例

「いい感じにまとめて」

「Drive内の最新3ファイルだけを参照し、解約理由を5分類して表に」のように範囲と形式を指定する。

置き換え

自社の資料名に差し替える

そのまま使えるが、資料名・トーン・承認者は必ず自社のものに置き換える。

Chapter 01 — Data Classes

データ分類とAI利用可否

導入前に4段階の分類を決め、「どのアカウントで、どのAIを使うか」を明文化する。

分類例推奨する使い方注意点
公開情報公開Web、公開資料、製品ページGeminiアプリ、Deep Research、AI Studio の実験で扱いやすい更新日と出典を必ず確認する
社内一般社内Wiki、会議資料、手順書Workspace with Gemini、NotebookLM、Gemini Enterprise に集約共有権限と古い文書の混在に注意
社外秘顧客名、契約、価格、売上Workspace / Enterprise 管理下で、人間の承認を入れる個人アカウント・Labs実験への投入は原則避ける
高度機密個人情報、医療/法務/金融判断、認証情報最小権限、監査、DLP、専用環境、専門家レビューを前提入力前に規程・契約・法令を確認する
Chapter 01 — Evaluation

AI出力の評価：5つの観点

失敗の理由は共通する。目的が曖昧、データが古い、許可範囲が広すぎる、評価基準がない、教育がない。

  • 正確性。出典・根拠ファイルを確認し、数字・日付・固有名詞を別途検証する。
  • 再現性。同じ入力で同程度の品質が出るかを、5〜10件のサンプルで確認する。
  • 業務適合。実際の承認者・利用者が、出力形式のまま使えるかを確認する。
  • 安全性。機密情報、差別表現、著作権、個人情報、誤誘導の有無をレビューする。
  • コスト / 速度。API利用ではモデル、コンテキスト長、ファイル数、呼び出し回数を測る。
Section
02

Geminiアプリと個人AI

調査・文章化・試作・継続タスクまで、個人作業の速度を上げる。会社データはWorkspace側の統制と分けて考える。

Chapter 02 — Feature Map

Geminiアプリの機能マップ

「質問に答えるAI」から「継続的にタスクを進める個人AIエージェント」まで広がっている。

機能何に使うか実装パターン
Gemini Live画面やカメラを見せながら会話する面接練習、営業ロールプレイ、現物確認
Deep Research複数ソースをもとに調査レポートを作る市場調査、競合比較。出典確認を必須にする
Canvas文章・コード・試作品を対話的に作る研修クイズ、社内FAQミニアプリ、資料の教材化
Gems役割・口調・手順を固定したカスタムAI営業コーチ、議事録レビュー、契約チェック観点
Personal IntelligenceGmail/Drive/Calendar など個人文脈を使う予定・メール・資料の横断整理。会社利用は権限確認
Gemini Spark継続タスク・スケジュール実行のエージェント日次準備、定期調査。提供地域 / プランに注意
Chapter 02 — Deep Research

Deep Research を業務レポートに変える

プロンプト例｜市場調査
テーマ：{製品/市場}について、2026年度の
参入可否を判断するための調査をしてください。
対象地域：{国/地域}
比較対象：{競合名または代替手段}

出力：
1. 結論  2. 市場機会  3. 主要リスク
4. 競合比較  5. 参入仮説  6. 未確認事項
7. 追加で確認すべき一次情報

条件：2024年以降の情報を優先し、数値には
出典と日付を添える。推測は「仮説」と明記する。
問い

意思決定に使う問いに変換

「市場規模を調べる」ではなく「参入すべきセグメントを3つに絞る」と書く。

出力

結論・根拠・反対意見に分ける

結論、根拠、反対意見、未確認事項、次のアクションの5部構成にする。

展開

Docs・Slides・Sheetsへ

出典を確認後、経営会議向け要約・説明資料・比較表へ展開する。

Chapter 02 — Canvas

Canvas：「読める資料」を「触れる教材」に変える

プロンプト例｜確認テストWebアプリ
添付した業務手順書をもとに、新人向けの
確認テストWebアプリを作ってください。

要件：
- 10問の選択式クイズ
- 各問に解説を表示
- 最後に点数と、間違えた章への復習リンク
- 用語は社内文書の表記に合わせる
- 画面はスマートフォンでも読みやすくする

注意：文書にない内容は追加せず、
不明点は「確認が必要」と表示してください。
向く用途

クイズ・診断・ミニアプリ

長文レポートをクイズ、診断、インフォグラフィックに変換する用途に向く。

流れ

Docs → Canvas → Sheets

手順書を確認テストに変え、結果をSheetsで回収する流れを標準にする。

制約

創作させない

文書にない内容を追加させず、不明点は「確認が必要」と表示させる。

Chapter 02 — Gems

Gems を「チームの型」にする

まず1つだけチームで使い、改善履歴を残す。3つ以上を同時に作らない。

Gemの例固定する役割入れるべき指示利用場面
営業提案レビューB2B営業マネージャー顧客課題、予算、決裁者、競合、導入障壁を必ず確認する提案書作成前の抜け漏れ確認
CSエスカレーションカスタマーサクセス責任者感情的表現を中立化し、SLA・契約・再発防止を分ける重要顧客への返信草案
法務観点契約レビュー補助者法的判断はしない。リスク箇所と確認質問を抽出するNDAや利用規約の一次レビュー
採用面接構造化面接官評価項目と根拠発言を分け、バイアス表現を避ける面接メモの整理
Chapter 02 — Gemini Spark

Gemini Spark：個人AIエージェントの設計

Googleアプリ連携・スケジュール・スキル・ユーザー確認を前提に設計する。

任せやすいタスク設計ポイント人間の承認が必要な場面
毎朝の予定・未返信メール・重要ファイルの要約対象カレンダー、未返信条件、優先顧客、要約形式を固定するメール送信、予定変更、外部共有
毎週の業界ニュース収集情報源、地域、キーワード、除外サイト、競合名を固定する経営会議資料への採用、投資判断
旅行・生活タスクの継続管理日程、予算、移動条件、確認タイミングを指定する予約、支払い、個人情報入力
個人ファイル整理対象フォルダ、分類名、移動ルールを明示する削除、共有権限変更、社外送信

※ 提供地域やプランは限定される場合がある。利用可否は必ず公式画面で確認する。定期タスクでも「送信・変更・移動は実行せず、必ず確認を求める」と制約を書く。

Chapter 02 — Models

モデルの使い分け：Gemini 3.5 世代

本番は安定版を優先し、Preview は検証用途に限定する。

用途候補選定理由・注意
一般的なチャット・要約・分類Gemini 3.5 Flash など安定版Flash系速度・コスト・知能のバランス。既定の選択肢
複雑な推論・長い計画Pro系 / 上位モデル多段推論、設計、レビュー向き。コスト・速度を確認
大量分類・低遅延Flash-Lite系高頻度処理、フォーム分類。難問は上位へフォールバック
画像理解・生成画像対応Gemini / Nano Banana系画像編集、説明、スライド素材。著作権・ブランド確認
音声・リアルタイムLive / TTS対応モデル音声対話、読み上げ。遅延、録音同意、個人情報
動画生成・編集Veo / Flow研修素材、広告試作。利用権利、公開前情報

※ モデル名は設定ファイルで切り替えられるようにし、移行時は評価セットで品質差分を比較してから切り替える。

Section
03

Workspace 実務

Gmail・Docs・Drive・Sheets・Slides・Meet・NotebookLM。普段のアプリの中でAIを使う実装レシピ。

Chapter 03 — Plans

用語とプランの整理

2025年以降、AI機能の多くは Workspace プランに統合された。名称が指すものを分けて読む。

用語現在の読み方実装上の注意
Google Workspace with GeminiWorkspaceアプリ内でGemini機能を利用する総称利用可能機能はエディション、管理者設定、国/言語で変わる
Gemini Business旧アドオン名として残る文脈がある。2025年1月以降、新規購入停止の記載見積・契約で、現行プランの機能か旧契約かを確認する
Gemini EnterpriseWorkspace向けAI／Enterprise App／Agent Platform の複数文脈がある社内検索なら App、開発基盤なら Agent Platform
Google AI Pro / Ultra for BusinessWorkspace利用者向けに高度AI機能を追加するアドオン文脈動画生成・上位モデルなど。個人向けプランと混同しない
Chapter 03 — Rollout

Workspace 導入の標準ステップ

AI出力をそのまま送らない運用を最初に決め、30日後に拡大判断する。

  • 対象部門を決める。営業・CS・マーケ・管理部門など、文書・メール・会議の多い部門から始める。
  • データ分類を決める。公開・社内一般・社外秘・高度機密の4段階。過剰共有のドライブは先に棚卸し。
  • 管理コンソールで方針を確認する。AI機能、共有、DLP、外部アプリ接続、監査ログ。
  • 5領域で最初のユースケースを1つずつ決める。Gmail・Docs・Sheets・Drive・Meet。
  • 出力テンプレートとレビュー担当を決める。30日後に利用ログ・品質サンプル・リスク事例で拡大判断。
Chapter 03 — Gmail

Gmail：メールを「読む・返す・予定に変える」

要約・返信草案・検索・予定化の4パターンから始める。

目的最短手順指示の型
長いスレッドの要約スレッドを開き、要約または質問機能を使う「合意事項、未決事項、顧客の懸念、次の返信案に分けて」
返信草案の作成Help me write で下書きを生成し、トーンを調整「謝意、回答、代替案、次回確認、締めの順に。長すぎない」
過去メールから探す過去メール・Drive・Calendar に関する質問をする「A社との最終合意条件と、次回会議日程を探して」
カレンダー予定化メール内容から日程候補・イベント作成支援を使う「候補日、参加者、議題、事前資料を抜き出して」

※ 失敗例と防止策 — 古い条件の引用→「最新の返信を優先し日付を添える」と指示／責任を認める表現→承認前の送信禁止ルール／第三者情報の引用→「相手に共有されている情報だけを使う」と指示。

Chapter 03 — Docs

Docs：文書を「作る・整える・レビューする」

空白から書かせず、既存資料の要約から始めるのが定着の近道。

機能領域使い方実装レシピ
Help me write / Ask Gemini文書作成、要約、リライト、トーン調整企画書、議事録、提案書、FAQ をテンプレート化
RefineRephrase・Shorten・Elaborate・Formal/Casual部署ごとの表現基準に合わせて文章を整える
Drive sourcesDrive内ファイルを参照して質問・要約・比較RFP・契約条件・過去提案を参照した提案書作成
Audio generation文書や要約を音声で確認する長い手順書を移動中に確認できる音声版へ変換

※ 教える順序 — ①既存資料を要約させる → ②会社の文体・禁止表現を渡してリライト → ③レビュー観点を固定して指摘させる → ④Slides・Vids・NotebookLM へ展開。

Chapter 03 — Drive

Drive：ファイルを「探す・読む・比較する」

AIは権限内の情報を見つけやすくする。導入前に過剰共有を見直す。

業務DriveでのGemini活用運用ルール
ファイル探索自然言語でファイル・フォルダを探し、概要を確認ファイル名規則、版管理、所有者を先に整理
フォルダ要約フォルダ内の複数資料をまたいで要約・質問対象フォルダを限定し、古い資料はアーカイブへ
PDF・画像の理解PDFや画像の内容に関する質問・要約図表の数値は原本で確認。読み取り誤差に注意
Catch me up最近の変更や重要情報を把握するプロジェクトフォルダごとに責任者と更新ルール

※ 導入前の整理 — 同名ファイル・旧版・個人マイドライブ保管を棚卸し／「全社員閲覧可」の共有ドライブを見直す／社外秘フォルダには所有者・保存期限・共有ルールを明記。

Chapter 03 — Sheets

Sheets：分類・要約・分析・可視化

先に表（列）を設計してからAIに頼む。AI関数は「AI案」列と「人間確定」列を分ける。

目的表の設計（列）AIに頼むこと
VOC分類顧客ID、日付、原文、分類、感情、緊急度、根拠分類案、感情、重要語、返信優先度の生成
売上分析月、顧客、製品、売上、粗利、施策異常値、増減理由、グラフ、ピボット提案
採用候補者整理候補者、面接メモ、スキル、懸念、次アクション面接メモからスキル・懸念を構造化
問い合わせSLA受付日時、顧客、内容、分類、期限、担当期限計算、優先度、返信草案へのリンク

※ AI関数の例 — =AI("次の問い合わせ文を分類し、分類名だけを返してください: " & A2)。判断できない場合は「要確認」と返させ、結果をそのまま確定列にしない。

Chapter 03 — Slides

Slides：資料を「構成・図解・話し言葉」に変える

「誰に何を決めてもらう資料か」を指定してデッキ化する。

作業Geminiの使い方仕上げの観点
新規スライド作成テーマ、対象者、目的、ページ数、参照資料を指定してドラフト1スライド1メッセージ。根拠数値と出典を確認
既存資料の要約長いデッキをサマリ、FAQ、話者メモへ変換古いスライド・未承認資料が混ざらないか
画像生成図解、イメージ、背景、概念図を生成ブランドガイド、著作権、実在人物・商標
Drive参照Docs・Sheets・Drive資料を参照して提案資料を作るファイル版数と社外共有可否

※ 黄金パターン — SheetsでAIに「洞察候補」を出させる → 人間が数字と解釈を確定する → Slidesでデッキ化 → Docsに議事録、Vidsに短い説明動画。

Chapter 03 — Meet / Chat

Meet・Chat：会議と会話を「次アクション」に変える

会議の価値は記録ではなく「決定と次アクション」。議事録テンプレートを先に決める。

アプリ場面AIメモ・指示の型連携
Meet定例会決定事項、未決事項、担当、期限、ブロッカーChatで担当別アクション、Sheetsで進捗管理
Meet顧客会議顧客発言、要望、懸念、宿題、次回提案Docsで議事録、Gmailでお礼・確認メール
Meet採用面接・研修質問、回答要約、評価根拠、フォロー課題評価シートへ転記、NotebookLMで復習教材化
Chat朝の優先順位「今日対応すべき依頼を期限順にまとめて」依頼者、内容、期限、リンク、確認要否
Chatスレッド整理「論点、合意、未決事項を分けて」議論の交通整理、次の返信案
Chat会議後アクション「Meetメモから担当別タスクを投稿文にして」担当者別の短い依頼文を生成
Chapter 03 — Vids / Forms

Vids・Forms：説明動画とアンケート分析

Vids はDrive資料から台本・シーン・AIボイスオーバーまで生成。Forms は自由記述の集計に強い。

アプリ用途作るもの・指示レビュー観点
Vids新人研修手順書から3〜5分の章別説明と確認クイズ用語、社内ルール、誤解を招く省略
Vids製品紹介提案書から顧客向け短尺動画、話者メモ、字幕価格・機能・公開前情報
Vids社内周知ポリシー変更点の説明、AIアバター、音声人事・法務承認、言い切り表現
Forms研修アンケート満足度・理解度・改善要望を含むフォーム生成自由記述をテーマ別に集計し次回対応へ
Forms顧客ヒアリング課題、利用状況、予算、導入時期の事前調査セグメント別に課題と商談確度を整理
Chapter 03 — NotebookLM

NotebookLM：資料群を「根拠つき学習環境」にする

信頼できるソースを入れ、その範囲だけで要約・質問・教材生成を行う。

用途ソース設計出力例
新入社員研修社内規程、FAQ、手順書、過去Q&A学習ガイド、確認クイズ、音声解説
顧客別ナレッジ契約書、議事録、提案書、問い合わせ履歴アカウント概要、リスク、次回提案論点
研究・論文レビュー論文PDF、メモ、参考URL論点整理、反対意見、引用候補
製品ドキュメント理解仕様書、リリースノート、サポート記事FAQ、比較表、トラブルシュート

※ Audio / Video Overview・Mind Map・Flashcards・Quizzes・Slide Deck まで生成できる。「ソースにない説明は追加しない」と必ず指示する。

Chapter 03 — Action Layer

行動レイヤーと出口：Calendar・Tasks・Keep・Sites・AppSheet

AIの回答を、実際の予定・タスク・メモ・公開ページ・業務アプリへ落とす。

ツールAIと組み合わせる役割注意点
CalendarGmail・Meetメモから次回会議・準備資料・議題を抽出して予定化招待送信・予定変更・外部参加者追加は承認必須
Tasks会議メモ・Chatから担当者別タスクを抽出し期限・根拠リンクを付与チーム運用は Sheets・プロジェクト管理と併用
Keep移動中の音声メモ・現場チェックリストを後でDocs/Sheetsへ構造化機密メモが散らばりやすい。ラベル・共有をルール化
SitesDocs・Slides・Vids・Formsで作った社内ナレッジを集約して公開公開範囲、更新責任者、古いページのアーカイブ
AppSheet業務プロセスを自然言語で説明し、点検・申請・案件管理アプリを生成サンプルデータは本番前に削除。権限・承認・監査
Apps Script標準機能やStudioで足りない細かな自動化をAPIで補う実行権限、トリガー、AI生成コードのレビュー
Chapter 03 — Admin

管理者が見るべき場所：Admin console・DLP・Vault

使わせる範囲と止める範囲を、ユーザー機能とは別に設計する。

管理領域見るもの実装上の判断
AI機能管理OU/グループ、プラン、利用可能機能、AI control center全社一斉ではなく、部門パイロットから始める
監査ログGemini利用、Drive共有、Chat、Gmail、管理操作高リスク部門はログ保持とBigQuery連携を決める
DLP・AI分類Driveの機密ラベル、自動分類、データ保護ルールAIが見つけやすくする前に、見せないファイルを分類
Vault・保持メール、Chat、Driveの保持・eDiscoveryAI生成物と元データの保持期間を規程に合わせる
共有・外部連携共有ドライブ、外部共有、Marketplace、MCP/API最小権限、承認済みアプリ、外部送信制御を明確に
Section
04

自動化と企業AI基盤

Workspace Studio で定型業務をフロー化し、Gemini Enterprise で社内検索・エージェントへ拡張する。

Chapter 04 — Workspace Studio

Workspace Studio：ノーコード業務自動化の基本概念

繰り返し業務を「いつ始まるか・条件・処理・承認・出力」の形に分解して設計する。

概念意味設計例
Flow一連の自動化処理フォーム回答を分類し、担当者へ通知し、Sheetsへ記録
Starterフローを開始するきっかけメール受信、フォーム回答、ファイル追加、時間スケジュール
Step実行する処理要約、分類、文書作成、メール草案、通知、データ記録
Condition分岐条件緊急度が高い場合だけ責任者へ通知
Human review人間の確認社外メール送信前、契約文言生成前、顧客別対応前
Sharing / Governanceフローの共有・管理部門テンプレート化、所有者、変更履歴、停止条件
Chapter 04 — Flow Prompt

AIにフローを作らせるプロンプト

プロンプト例｜問い合わせの一次分類と担当通知
次の業務を自動化するフローを作成してください。
業務名：顧客問い合わせの一次分類と担当通知
開始条件：support@example.com 宛の新着メール

処理：
1. 件名と本文を読み、分類を
   「障害」「使い方」「契約」「機能要望」「その他」に分ける
2. 緊急度を「高・中・低」に判定する
3. 緊急度が高い場合はCS責任者にChatで通知する
4. すべてSheetsの「問い合わせログ」に追記する
5. 返信草案は作成するが、自動送信はしない

制約：顧客名・契約情報の通知は最小限にし、
社外送信前に人間の承認を入れる。
Starter

開始条件を絞る

すべてのメールを対象にしない。宛先・ラベル・件名・送信者で限定する。

承認

送信は人間が決める

返信・削除・外部共有・契約判断には必ず Human review を入れる。

禁止

赤字で明記する

AI案を確認したら「自動実行してはいけない操作」を必ず明記する。

Chapter 04 — Flow Card

実装カード：問い合わせトリアージFlow

フローは「目的〜停止条件」までを1枚のカードで設計してから作る。

項目設計内容
目的サポートメールを分類し、重要問い合わせの初動遅れを防ぐ
入力Gmailの新着メール、顧客マスタSheets、過去FAQ Docs/Drive
AI処理分類、緊急度、推奨担当、返信草案、FAQ候補の提示
出力Sheetsログ、Chat通知、Gmail下書き、担当者タスク
承認顧客への返信送信、契約・返金・障害認定に関わる文言
監視誤分類率、初回返信時間、エスカレーション漏れ、担当者修正履歴
停止条件誤分類が一定以上、顧客名漏洩、意図しない宛先通知、連携エラー
Chapter 04 — Anti-patterns

Workspace Studio の失敗パターン

テストは成功例だけでなく、例外メール・短文・添付のみ・英語メールなど例外を10件用意する。

  • 開始条件が広すぎる。すべてのメールを対象にすると誤作動が増える。宛先・ラベル・件名で絞る。
  • AI判断を最終決定にしてしまう。返信、削除、外部共有、契約判断には人間の承認を入れる。
  • フローの所有者が曖昧。異動や退職で止まる。部門アカウントと所有者を決める。
  • ログがない。AIの分類根拠、実行時刻、通知先、手動修正を記録する。
Chapter 04 — Gemini Enterprise

Workspace with Gemini と Gemini Enterprise App の違い

社内データが Drive 以外にも散らばるなら Enterprise App を検討する。

観点Workspace with GeminiGemini Enterprise App
主な利用者一般業務ユーザー。アプリ内で使う全社ナレッジ利用者、部門エージェント利用者、IT/管理者
データ範囲主にWorkspace内のファイル、メール、会議、チャットConfluence・Jira・SharePoint・ServiceNow など社内SaaSを含む
用途作成・要約・返信・会議記録・表分析社内検索、業務エージェント、権限を守った横断回答
管理Workspace管理コンソール、共有権限、DLPコネクタ、エージェント管理、ポリシー、データ統制
向く開始点個人・部門の生産性改善全社ナレッジ、IT/HR/営業/CSなど部門横断AI
Chapter 04 — Assistant Design

社内AIアシスタント構築の標準設計

AIが答えられる範囲は、ユーザーが見る権限を持つ範囲に合わせる。

  • 対象業務を1つに絞る。「営業が提案前に顧客情報を確認」「社員がIT手順を質問」など。
  • データソースを棚卸しし、権限を確認する。Drive、SharePoint、Confluence、Jira、CRM など。
  • 回答形式を固定する。結論、根拠、参照ファイル、更新日、次のアクション、問い合わせ先。
  • 評価セットを作る。よくある質問50件、機密質問10件、誤回答しやすい質問10件。
  • 監査と改善の運用を決める。利用ログ、低評価回答、データ鮮度、コネクタ同期。
Chapter 04 — Agents

部門別エージェントの設計例

「参照データ」「許可するアクション」「禁止・承認」を部門ごとに線引きする。

部門エージェント参照データ許可するアクション禁止・承認
ITITヘルプデスクAIIT手順書、チケット、障害履歴手順提示、関連チケット検索権限変更・アカウント停止は承認必須
人事人事規程AI就業規則、福利厚生、FAQ規程検索、相談先提示個別労務判断、個人情報開示
営業提案準備AICRMメモ、提案書、契約条件顧客概要、過去課題、提案論点整理価格確約、契約変更、未公開情報
CS顧客対応AI問い合わせ履歴、FAQ、契約SLA返信案、エスカレーション提案返金・障害認定・謝罪文の自動送信
法務契約一次レビューAI契約テンプレ、過去レビュー観点リスク箇所抽出、確認質問法的助言の断定、契約承認
Chapter 04 — Agent Platform

Agent Platform：本番エージェントのアーキテクチャ

モデル選定・ツール連携・監視・評価・ガバナンスを「層」で設計する。

層役割設計ポイント
UI / チャネルWeb、Chat、社内ポータル、アプリ内チャット認証、ユーザー属性、会話履歴、承認UI
オーケストレーションタスク分解、ツール選択、手順制御ADK、ルール、状態管理、ツール使用ポリシー
モデルGemini 3.5 系、必要に応じたマルチモデル安定版、コスト、速度、コンテキスト
ナレッジ / RAG社内文書、DB、検索、ベクトル、引用データ鮮度、権限、引用、再ランキング
ツール / APICRM、チケット、ERP、メール、社内API最小権限、承認、監査、リトライ、ロールバック
ガードレール安全性、DLP、プロンプト防御、出力制御禁止操作、PIIマスキング、ポリシー検査
運用ログ、トレース、評価、コスト、SLO失敗率、ユーザー評価、品質評価、アラート
Chapter 04 — KPI

本番化で必ず見るKPI

「作ったら終わり」にしない。低評価回答と失敗ログを毎週レビューする。

KPI意味改善アクション
回答採用率ユーザーがAI回答をそのまま使った・役立った割合プロンプト、データ鮮度、引用形式を改善
低信頼回答率根拠不足、矛盾、回答不能の割合RAG対象データ、検索、再ランキングを改善
ツール実行失敗率APIエラー、権限エラー、タイムアウトリトライ、権限、エラーハンドリング、監視
コスト / 会話1会話あたりのモデル・検索・ツールコストモデル選定、コンテキスト圧縮、キャッシュ
エスカレーション率人間確認に回った割合高すぎればデータ改善、低すぎれば安全性確認

※ RAGのチェック — チャンク粒度（見出し・表・更新日を保持）／ハイブリッド検索と再ランキング／回答への文書名・更新日の引用／検索時点での権限フィルタ／機密質問への拒否を評価。

Section
05

開発・モデル・Labs

AI Studio・Gemini API でアプリに組み込み、Antigravity で開発を進め、Gemma 4 と Labs を使い分ける。

Chapter 05 — AI Studio

AI Studio から本番へ：5つの段階

AI Studio でプロトタイプ、Gemini API で実装、必要に応じて Agent Platform へ移行する。

段階成果物次に確認すること
AI Studio で試すプロンプト、モデル、出力例、失敗例同じ入力で安定するか
API で最小実装CLI / Notebook / 小さなWebアプリエラー処理、JSONスキーマ、ログ
評価セット作成成功・失敗・境界ケースのサンプル品質基準、レビュー者、合格ライン
権限設計APIキー / サービスアカウント / IAM / Secret管理誰がどのデータとツールを使えるか
本番運用監視、コスト、SLO、改善サイクルモデル更新、フォールバック、障害対応

※ 長文コンテキストでも目的に関係ない資料を混ぜない。「全体を読んで」ではなく「この観点で該当箇所と根拠を抽出」と指示する。

Chapter 05 — Structured Output

構造化出力：回答をスキーマに固定する

Python：構造化出力の概念例
# 分類・抽出・RAG回答・次アクション生成に向く
from google import genai
from pydantic import BaseModel

class TicketTriage(BaseModel):
    category: str   # bug / how_to / billing / ...
    priority: str   # high / medium / low
    summary: str
    needs_human_review: bool
    reason: str

client = genai.Client(api_key="YOUR_API_KEY")
response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="問い合わせ文: ログインできず…",
    config={
        "response_mime_type": "application/json",
        "response_schema": TicketTriage,
    },
)
print(response.parsed)
Why

スキーマを先に決める

自然文をアプリで解析するより、JSON形式に固定する方が実装が安定する。

設計

要確認フラグを持たせる

needs_human_review のような人間承認のフラグをスキーマに含めておく。

Chapter 05 — Function Calling

Function calling：ツール実行の安全設計

ツール定義（疑似コード）
tools = [
  {
    "name": "search_customer_contract",
    "description": "顧客IDから契約条件を検索。
                    読み取り専用。",
    "parameters": {"customer_id": "string"}
  },
  {
    "name": "create_reply_draft",
    "description": "Gmail下書きを作る。
                    送信はしない。",
    "parameters": {"to": "...", "body": "..."}
  }
]
# 安全設計:
# - send_email / delete_file / change_permission
#   は最初から提供しない
# - 書き込み系は「draft」までにする
# - 本番では監査ログ・承認UI・レート制限
原則

「何でも実行」させない

関数ごとの引数、権限、承認、ロールバックを設計してから渡す。

境界

draft までで止める

送信・削除・権限変更は関数として提供せず、人間が実行する。

Chapter 05 — Antigravity

Antigravity：エージェント開発の司令塔

複数のAIエージェントを立ち上げ、監視し、成果物を確認しながら開発を進めるプラットフォーム。

要素役割実装上の使い方
Standalone / Command center複数エージェントの起動・監視・オーケストレーション大きな改修をタスク分割し、進捗と成果物を確認
Antigravity IDE / CLI / SDKコード編集との統合、ターミナル利用、独自組み込みローカル改修・CI前チェック・社内開発基盤
Visual Artifacts計画、差分、ブラウザ操作録画を高精度に確認信頼性レビュー、変更承認、デバッグ
Rules制約・スタック・規約をMarkdownで常時読ませる「テスト必須」「依存追加は承認制」を固定
Agent Skills再利用可能な知識・手順パッケージコードレビュー、テスト作成、セキュリティ観点を標準化
MCP外部ツールや社内システムと接続Issue、DB、ブラウザ、テスト、社内API連携
Chapter 05 — Workflow

Antigravity 実装ワークフロー：調査 → 計画 → 修正

プロンプト例｜調査だけ依頼する
Issue #123 の原因を調査してください。
まだコードは変更しないでください。

出力：
1. 再現手順の確認
2. 関連ファイル
3. 原因仮説
4. 修正方針
5. 影響範囲
6. 必要なテスト

制約：コード変更、依存関係追加、
DB変更は行わないでください。

# Rules（Markdown）の例
# - 挙動変更には必ずテストを付ける
# - 依存追加は理由と代替案を先に提案
# - 公開APIの互換性を維持する
# - UI変更は録画/スクリーンショットを添付
段階

計画を承認してから修正

調査→計画→承認→修正→Visual Artifacts確認→人間の差分レビュー→CI→PR。

安全

書き込み権限は後から

最初から本番認証情報を渡さない。各段階に人間の承認点を作る。

Chapter 05 — Dev Tools

Gemini CLI・Code Assist・Jules・Stitch の使い分け

「調査」「計画」「変更」「テスト」「PR」の各段階で人間の承認点を作る。

ツール向いている作業実装時の注意
Gemini CLI / Antigravity CLIターミナルでの調査、修正、テスト、ドキュメント生成シェル実行権限、秘密情報、Git差分を確認
Gemini Code AssistIDE内補完、説明、生成、リファクタ、エージェントモード社内コードの扱い、引用、ライセンス、レビュー
JulesGitHubリポジトリを対象に、クラウドVMで計画・差分・PR作成ブランチ権限、CI、PRレビュー、外部接続
Stitchモバイル / Web のUI案、画面遷移、デザイン試作そのまま本番化せず、アクセシビリティとブランド確認

※ 生成コードはセキュリティ・ライセンス・依存関係・テストをレビューし、AIの説明と実際の差分が一致するかを必ず確認する。

Chapter 05 — Gemma 4

Gemma 4：オープンモデルという選択肢

Gemini API は「Googleがホストするモデルを使う」、Gemma は「自分たちの環境でモデルを扱う」。

観点Gemini APIGemma 4
運用形態GoogleのAPI / クラウドで利用ローカル、オンプレ、独自クラウド、エッジで利用可能
データ統制API利用規約・クラウド管理・IAMで統制自社環境に閉じやすいが、運用・保護は自社責任
コスト利用量課金 / プランGPU・サーバー・運用人件費。高頻度処理で有利な場合
カスタマイズプロンプト、RAG、ファインチューニング等量子化、蒸留、評価を自社で設計
向く用途高性能な生成、エージェント、迅速な導入機密データ、低レイテンシ、オフライン、組込み、研究

※ 使うべきでない場面 — Googleホスト機能との統合が主目的／モデル運用・GPU・評価体制を持てない／高リスク判断で専門家レビューがない／ナレッジ更新が頻繁でRAGを組めない。

Chapter 05 — Google Labs

Google Labs：クリエイティブAIの使い分け

実験的機能が多い。業務で使う場合は、機密データを入れない試作から始める。

ツール用途注意
FlowAI動画制作、シーン生成、編集、モデル選択生成物の権利、人物・商標、公開前情報
Flow MusicAI音楽・サウンド制作。動画BGM、試作音源商用利用・著作権・ブランドガイド
MixboardAIコンセプトボード。発散と整理、企画探索正解を出すより「比較可能な案を並べる」
Pomelliブランドに沿ったSNS・広告・販促素材の生成ブランド素材の入力範囲、権利
Project Genie画像・テキストからインタラクティブ世界を作る研究研究段階として扱い、業務本番化は慎重に
Learn About ほか学習・調査・要約系の実験学術・業務判断では出典確認

※ PoC成果物を本番に使うときは、Workspace や Enterprise 管理下へ移す。プロンプト・入力素材・出力・採用/不採用理由をプロジェクト単位で保存する。

Chapter 05 — Flow / Mixboard

Flow と Mixboard の実装手順

動画は「権利確認の順番」、企画は「発散→収束→検証→展開」の型で進める。

Flow ・ 動画制作

5ステップ

  • 目的を決める（広告・研修・SNS・デモで尺と権利確認が変わる）
  • 素材を分ける（公開可能・社内限定・ブランド素材を混ぜない）
  • シーンごとにプロンプトを書く（人物・背景・カメラ・字幕）
  • 人物・ロゴ・文字・事実表現をレビューする
  • Vids・Slides・Docs と連携して台本・資料に展開
Mixboard ・ 企画

4工程

  • 発散：ターゲット・世界観・色・ユースケースを10〜20案に広げる
  • 収束：評価軸を置き、候補を3案に絞る（捨てた案も残す）
  • 検証：顧客像・利用シーン・反対意見を追加する
  • 展開：Slides・Flow・Docs・Stitch へ渡して企画書・試作へ
Section
06

運用・安全と導入支援

組織で安全に使い続けるためのルールとチェックリスト、30/60/90日ロードマップ、業務別プレイブック。

Chapter 06 — Safety

禁止事項と安全ルール

個人の便利さを優先すると権限や監査が抜ける。最初にデータ分類とロールを決める。

  • 会社データは管理されたアカウントで扱う。個人アカウントや Labs 実験に業務データを入れない。
  • 実行範囲は「データ×アクション×承認」で決める。送信・削除・権限変更は人間の承認を必須にする。
  • 出典と日付を確認する。数字・日付・固有名詞は原本で検証し、根拠のない主張は「要確認」とする。
  • 最小権限から始める。過剰共有の共有ドライブは、AI導入前に棚卸しする。
Chapter 06 — Examples

データの扱い：NG例 と OK例

「どのアカウントで、どのAIを使うか」を具体例でそろえる。

NG ・ やってはいけない

統制の外に出さない

  • 個人アカウントの Gemini に業務データを入れる
  • Labs 系実験に社外秘・個人情報を投入する
  • AIの返信草案をレビューなしで自動送信する
OK ・ 推奨する扱い

管理下で承認を通す

  • 管理された Workspace アカウントで利用する
  • 機密は伏字・要約で渡し、扱える範囲を明文化する
  • 出力は下書き止まりにし、人の承認で確定する
Chapter 06 — Checklist

導入前チェックリスト

7カテゴリすべてに「はい」と答えられる状態で開始する。

カテゴリチェック項目
目的AI導入の目的が「時間削減」「品質向上」「ナレッジ検索」「自動化」など成果で定義されている
範囲対象部門、対象ツール、対象データ、禁止データが決まっている
権限共有ドライブ、外部共有、管理者ロール、APIキー、サービスアカウントを棚卸しした
教育良いプロンプト、確認方法、禁止事項をユーザーに説明した
レビューAI出力を送信・公開・実行する前の承認者が決まっている
評価サンプルデータ、品質基準、失敗時の対応が決まっている
運用ログ、問い合わせ先、改善サイクル、利用停止基準がある
Chapter 06 — Risks

リスク別チェックリスト

確認質問に答えられないリスクから優先的に対策する。

リスク確認質問対策
機密漏洩個人アカウントや Labs に業務データを入れていないかアカウント利用ルール、DLP、教育、監査
誤回答根拠ファイル、日付、数字を確認しているか出典表示、評価セット、人間レビュー
過自動化送信・削除・権限変更・契約判断を自動実行していないか承認フロー、最小権限、停止条件
コスト超過API や動画生成の利用量を測っているか予算、クォータ、モデル選定、キャッシュ
定着しないユーザーの既存業務アプリ内で使えているかGWS内蔵AIから始め、テンプレートを配布
Chapter 06 — Roadmap

30 / 60 / 90日ロードマップ

GWS内蔵AIで小さく始め、フロー化・基盤化へ段階的に広げる。

DAY 1-30

小さく開始

Gmail・Docs・Drive・Meet で開始。利用ルール、プロンプト、レビュー観点を整備。

DAY 31-60

拡大・フロー化

Sheets・Slides・Vids・NotebookLM へ拡大。Studio で反復業務を1〜2本Flow化。

DAY 61-90

適用判断

Enterprise・Agent Platform・Antigravity・Gemma の適用判断。高価値ユースケースを本番化。

DAY 91+

全社展開

全社AIロードマップ、セキュリティ設計、評価セット、運用KPIを確定して展開。

Chapter 06 — Playbook

業務別プレイブック：ツールをつなぐ順番

ツール単体ではなく「この順番で使えば成果物まで進める」業務フローとして覚える。

業務使う順番ポイント
営業提案書を1日で作るDrive要約 → Gmail要望抽出 → Docs提案書 → Sheets試算 → Slidesデッキ根拠ファイル名と日付を必ず添える
CS問い合わせトリアージGmail要約 → Sheetsログ → Drive/NotebookLMで根拠 → Chat通知 → StudioでFlow化返金・契約変更・障害認定は断定させない
会議を「実行」に変えるMeetメモ → Docs議事録 → Chat担当通知 → Gmail確認メール → Sheets管理曖昧な担当・期限は「要確認」とする
社内ナレッジAIを作るDrive棚卸し → NotebookLMで品質確認 → Gemini Enterprise → Agent Platform小さなソースセットで品質を先に確認
新規アプリをAIで試作Mixboard → Stitch → Canvas試作 → Antigravity / Jules → AI Studio・APIコードを書く前に計画だけ出させる
研修教材を作るDocs手順書 → NotebookLMクイズ・音声 → Vids動画 → Forms理解度テスト未受講リマインドは Studio でFlow化
Chapter 06 — Templates

すぐ使えるプロンプトテンプレート集

コピーして { } を差し替えて使う
▼ 要約
以下の資料を {対象者} 向けに要約。出力は
結論 / 重要ポイント / 根拠 / リスク / 次のアクション。
推測は「仮説」と明記。

▼ メール返信
このメールへの返信草案を作成。お礼 → 相手の懸念
→ 回答 → 確認事項 → 次のアクションの構成。
禁止：未確認の納期、値引き、法的判断、過度な謝罪。

▼ 議事録
この会議メモを整理。決定事項 / 未決事項 /
担当者別タスク / 期限 / 顧客確認 / 次回議題。
担当や期限が曖昧なら「要確認」。

▼ RAG回答（社内ナレッジAI）
接続された社内ナレッジだけを根拠に回答。出力は
結論 / 手順 / 根拠文書 / 更新日 / 問い合わせ先。
根拠がない場合は「該当文書が見つかりません」。
How

{ } を置き換える

資料名・トーン・承認者を自社のものに差し替えるだけで使える。

Save

定着したら Gem・Flow に

繰り返し使うものは Gems に固定し、定型処理は Studio でフロー化する。

Appendix — Glossary

用語集

本マニュアルで使う主な用語。

用語説明
GeminiGoogleのAIの中核名称。アプリ名・モデル名・Workspace機能名として使われるため文脈で読む
GWSGoogle Workspace の略。Gmail・Docs・Sheets・Slides・Drive・Meet・Chat などを含む業務基盤
Workspace StudioWorkspace内の定型業務を、Geminiの支援でノーコード自動化するアプリ
Gemini Enterprise App企業検索、AIアシスタント、エージェントを扱う企業向けプラットフォーム
Agent Platformエージェントを構築・デプロイ・監視・統制する Google Cloud 上の開発者向け基盤
AntigravityAIエージェントによる開発を管理・監視・オーケストレーションする開発プラットフォーム
Gemma 4Googleのオープンウェイトモデル群。ローカル・オンプレ・エッジ実行の選択肢
NotebookLM指定したソースを根拠に、要約・質問・音声/動画概要・学習素材を作る思考支援ツール
RAG / MCP検索で取得した根拠で回答する設計／AIが外部ツールと接続する標準的な接続方式
Contact

導入を、伴走で確実に。

本マニュアルの内容を、弊所のハンズオン研修で貴社の業務に合わせて実装します。Workspaceの環境整備・プロンプト設計・Studioフロー化・安全ルールまで伴走します。

OfficeMizuki
【無料相談・お申し込みはこちら】
https://officemizuki.jp