構成案: Geminiでスライド作成を効率化する方法｜用途別プロンプトと失敗回避まで解説
1. 基本情報
項目 内容 対象キーワード gemini スライド作成 対象案件 05_rockhearts 想定読者 Google Workspaceを業務で使う企画、営業、採用、管理部門の担当者。短時間で資料初稿を作りたいが、品質や情報精度に不安がある人。 検索意図 GeminiでGoogleスライドを作る具体的な手順、用途別のプロンプト、生成後の修正方法、企業利用時の注意点を知りたい。 記事のゴール 読者が「目的整理、Geminiで初稿生成、人手で品質確認、共有前チェック」まで再現できる状態にする。 記事想定文字数 6,500〜7,500文字 本文構成 LEAD 400〜500文字、BODY 各H2 1,200〜1,800文字、CONCLUSION 300〜400文字 H2数 6個（まとめ含む） CTA 記事末尾1箇所のみ。本文中CTA、H2末尾CTA、サービス紹介H2は禁止。 箇条書き率 完成記事全体の10%以下。プロンプト例以外は自然文中心で書く。
2. 執筆前提
この記事は、Geminiの新機能紹介ではなく、業務でGoogleスライドを作る人が実際に使える判断材料を提供する記事として設計する。読者は「Geminiでスライドを作れるらしい」という情報は知っているが、どの程度任せてよいのか、どんな指示を出せば品質が安定するのか、生成後にどこを直すべきかで迷っている。
したがって、本文では「便利です」「簡単です」で終わらせない。Geminiは資料作成の初稿化や表現整理には有効だが、事実確認、意思決定に関わる数値、ブランドトーン、最終的な説得設計は人が担う必要がある。この境界線を明確にすることが、競合記事との差別化になる。
ROCKHEARTSのトーンとしては、専門的だが高圧的ではない実務パートナーの語り口を採用する。クリエイティブの見栄えだけでなく、社内合意、営業提案、採用広報、マーケティング施策の成果につながる資料設計として説明する。自社紹介は本文前半で押し出さず、最後のCTAで自然に接続する。
3. 競合分析から見た勝ち筋
競合上位は、Google公式ヘルプ、Google Workspace公式リソース、Workspace Updates、Google Blog、Computerworld、TechRepublic、PCWorldが中心である。公式系は機能仕様と更新情報の信頼性が高く、メディア系は新機能のわかりやすい紹介に強い。一方で、実務の資料作成フローに落とし込む情報は不足している。
最も避けるべきなのは、公式ヘルプの機能一覧を言い換えるだけの記事である。画像生成、新規スライド生成、文章改善、要約、Drive参照といった機能を並べても、読者は「結局、自分の営業資料や社内報告にどう使うのか」を判断できない。
本記事の勝ち筋は、用途別プロンプト、失敗パターン、生成後の編集フロー、セキュリティと運用ルールを一体で扱うことにある。特に「できること」と「任せてはいけないこと」を同じ温度で書くと、ツール礼賛ではない信頼性のある記事になる。
4. H1
Geminiでスライド作成を効率化する方法｜用途別プロンプトと失敗回避まで解説
5. リード文方針（400〜500文字）
リードでは、資料作成の負担に共感する。営業提案、社内報告、採用説明など、スライド作成は情報整理、構成検討、デザイン調整、文章修正が重なり、想像以上に時間がかかることを言語化する。
次に、Geminiを使えばGoogle Slides上でスライドの初稿作成、文章整理、画像生成、要約などを効率化できると示す。ただし、生成AI任せにすればそのまま提出できるわけではない。事実確認、読み手に合わせた構成、ブランドトーン、共有前の権限確認は人が見る必要がある。
最後に、この記事ではGeminiでスライド作成する基本手順、用途別プロンプト、失敗回避、品質を上げる編集フロー、企業利用時の注意点まで解説すると約束する。
H2: Geminiでスライド作成はどこまでできる？まず押さえたい基本機能（目安: 1,200〜1,400文字）
この章の役割
最初に、Geminiでできることと、過度に期待してはいけないことを整理する。読者にとっての不安は「本当に使えるのか」と「どこまで任せられるのか」であるため、機能説明と限界をセットで提示する。
H3: Gemini in Slidesでできる主なこと
Google Slides上のGeminiでは、スライドの新規作成、既存内容の要約、文章の作成や書き換え、画像生成、Drive上の資料参照などが可能であることを説明する。ここでは公式ヘルプとGoogle Workspace公式リソースを根拠にし、断定しすぎず「利用環境やプランによって表示や提供状況が異なる場合がある」と補足する。
書くべき内容は、機能を羅列するだけでなく、どの作業時間を短縮できるのかに変換すること。たとえば、白紙から構成を考える時間、説明文を整える時間、イメージ画像を探す時間、既存資料から要点を抜き出す時間を減らせる、という形で読者の業務に接続する。
H3: 生成できるのは「完成品」ではなく「初稿」と捉える
Geminiで作成したスライドは、実務では初稿として扱うべきだと明記する。生成AIは短時間で形を作るのに強いが、読み手の関心、社内政治、提案先の温度感、ブランド上の細かな表現までは完全に判断できない。
ここでは「Geminiが作る、担当者が仕上げる」という役割分担を示す。特に営業提案や採用説明では、相手が何を不安に思っているか、どの順番で納得してもらうかが重要になる。単にきれいなスライドができても、意思決定につながらなければ資料としては弱い。
H3: 利用前に確認すべき環境と権限
Google Workspaceのプラン、管理者設定、機能提供状況、Workspace Labs/Experiments系の条件に触れる。ここでは具体的なプラン名を過度に断定せず、公式ヘルプや管理者画面で最新状況を確認するよう促す。
企業利用では、個人アカウントで試す場合と組織アカウントで使う場合のリスクが異なる。機密資料や顧客情報を入力する前に、自社のAI利用ルール、データ取り扱い、共有権限を確認する必要がある。
H2: Geminiでスライドを作成する基本手順（目安: 1,200〜1,500文字）
この章の役割
読者が実際に手を動かせるよう、資料作成の流れを「目的整理、材料準備、生成、修正、共有前確認」の順で説明する。競合記事の多くは操作説明やニュース紹介に寄っているため、本記事では業務フローとして再構成する。
H3: いきなり生成せず、目的と読み手を先に決める
最初に決めるべきなのは、スライドの目的である。営業提案なら相手に検討を前に進めてもらうこと、社内報告なら意思決定や承認を得ること、採用説明なら候補者に企業理解を深めてもらうことが目的になる。
ここで、読み手、利用シーン、最終的に取ってほしい行動、必ず入れる情報、入れない情報を整理してからGeminiに指示する必要があると説明する。目的が曖昧なまま生成すると、見た目は整っていても、誰に何を伝えたいのか分からない資料になりやすい。
H3: Geminiに渡す材料を整理する
Geminiに渡す材料として、既存資料、箇条書きメモ、構成案、商品情報、数値データ、参考トーンなどを整理する。ただし、未公開情報や個人情報、顧客固有の機密情報は入力前に社内ルールを確認し、必要に応じて匿名化する。
この章では、材料を多く渡せばよいわけではないと書く。重要なのは、読み手に必要な情報を優先順位付きで渡すこと。情報量が多すぎると、Geminiは要点を絞れず、1枚に複数メッセージが詰まった資料を作りやすくなる。
H3: 初稿生成後は大きな構成から直す
生成後すぐに細かな文言や色を直すのではなく、まず構成を確認する。結論が先に出ているか、各スライドの役割が重複していないか、読み手が自然に理解できる順番になっているかを見る。
次に、数値、固有名詞、日付、引用元、サービス内容などの事実確認を行う。最後に、文体やデザインを調整する。この順番を守ることで、見た目を整えた後に構成ごと作り直す無駄を避けられる。
H2: 用途別に使えるプロンプト設計（営業提案・採用説明・社内報告）（目安: 1,400〜1,700文字）
この章の役割
本記事の差別化の中心となる章。読者が自分の業務に置き換えられるよう、用途別にプロンプトの考え方を説明する。完成記事ではプロンプト例を載せてもよいが、箇条書きやコードブロックの量を増やしすぎない。プロンプト例は必要最小限にし、前後を自然文で説明する。
H3: 営業提案スライドのプロンプト
営業提案では、相手の課題、提案する解決策、導入後の変化、判断材料、次のアクションが伝わる構成にする。Geminiに指示する際は、提案先の業種、相手の課題、提案サービス、競合との違い、必ず入れる根拠、避けたい表現を渡す。
プロンプト例では、「10枚前後」「1枚1メッセージ」「結論を先に」「専門用語は補足する」「誇大表現を避ける」といった制約を含める。ROCKHEARTSの文脈では、動画、WEB、広告、SEO、SNSなど複数施策を組み合わせる提案資料にも応用できると自然に触れる。ただし、この章でサービス誘導はしない。
H3: 採用説明スライドのプロンプト
採用説明では、候補者が知りたい情報と企業が伝えたい情報を分けて整理する。企業理念、仕事内容、働く環境、選考フロー、求める人物像を並べるだけでは、候補者の不安解消につながらない。
Geminiへの指示では、候補者の立場、説明会の目的、入社後のイメージ、強調したい価値観、避けたい過度な美化を明確にする。ここでは、採用広報資料では「魅力づけ」と「誤解を生まない正確さ」の両立が重要だと説明する。
H3: 社内報告スライドのプロンプト
社内報告では、結論、背景、現状、課題、選択肢、推奨アクションを整理する必要がある。読み手は詳細な説明よりも、何を判断すべきかを早く知りたい場合が多い。
Geminiに指示する際は、報告先、会議時間、意思決定したい内容、使用する数値、前提条件、未確定情報を明確にする。未確定情報は断定させず、「確認中」「仮説」として扱うよう指示する。これにより、AIがもっともらしい断定を作るリスクを下げられる。
H2: Geminiスライド作成で失敗しやすいポイントと回避策（目安: 1,300〜1,600文字）
この章の役割
競合記事が薄い失敗回避を扱い、記事の信頼性を高める。便利さだけでなく、実務で起きる手戻りを具体的に示す。完成記事では、失敗例を架空の具体企業事例として捏造しない。一般的に起きやすいパターンとして書く。
H3: 情報過多で1枚1メッセージが崩れる
Geminiに多くの情報を渡すと、1枚のスライドに複数の論点が詰まりやすい。特に社内報告や営業提案では、伝えたいことが多くなりがちで、結果として読み手が何を判断すべきか分からなくなる。
回避策として、生成前に各スライドの役割を決めること、生成後に「このスライドで一番伝えたい一文は何か」を確認することを書く。必要に応じて、Geminiに「各スライドを1メッセージに絞って再構成してください」と再指示する方法を示す。
H3: デザインは整っていても、説得の流れが弱い
AI生成のスライドは、見た目が整っているため完成度が高く見える場合がある。しかし、結論が遅い、根拠が弱い、読み手の不安に答えていない資料は、実務では使いにくい。
ここでは、デザイン確認より先に論理構造を確認する必要があると説明する。読み手の疑問が「なぜ今必要か」「なぜこの案か」「次に何をすべきか」の順に解消されるかを見る。
H3: 事実誤認や古い情報が混ざる
Geminiが生成した文章には、もっともらしいが確認が必要な情報が含まれる可能性がある。数値、日付、固有名詞、料金、機能提供範囲、法令や規約に関わる内容は、必ず一次情報で確認する。
この章では、Google Help、Workspace Updates、Google Blogなどの公式情報を確認先として示す。特にGemini関連の機能は更新が速いため、記事執筆時点の情報として固定せず、最新の公式情報を確認する習慣が必要だと書く。
H3: ブランドトーンや表現が合わない
企業資料では、色やフォントだけでなく、言葉遣い、温度感、訴求の強さもブランドの一部である。Geminiに「かっこよく」「わかりやすく」とだけ指示すると、自社らしさから外れた表現になる場合がある。
回避策として、トーン、避けたい言葉、使いたい表現、読み手との関係性を事前に渡すことを書く。ROCKHEARTS文脈では、感情を動かすクリエイティブと成果につながるマーケティングの両面を大切にするような表現が望ましい。
H2: 生成後の品質を上げる編集フローと企業利用時の注意点（目安: 1,300〜1,700文字）
この章の役割
初稿生成から実務投入までの仕上げ工程を示す。ここで、品質チェック、セキュリティ、共有権限、運用ルールをまとめて扱う。読者が「生成して終わり」ではなく「使える資料に仕上げる」視点を持てるようにする。
H3: 構造、内容、表現の順でチェックする
編集は、構造、内容、表現の順に進める。構造では、結論の位置、スライド順、重複、抜け漏れを見る。内容では、数値、固有名詞、根拠、引用元、前提条件を確認する。表現では、文体、文字量、見出し、図版、読みやすさを整える。
この順番を守る理由を説明する。先にデザインや言い回しを整えても、構成がズレていれば作り直しになる。実務では、見た目の完成度よりも、意思決定に必要な情報が過不足なく並んでいるかが重要である。
H3: AIに再生成させる領域と人が直す領域を分ける
AIに任せやすいのは、表現の言い換え、要約、構成案の別案、スライドタイトル案、文章量の調整などである。一方で、人が見るべきなのは、提案の核心、数値の妥当性、顧客固有の事情、社内事情、ブランド上の判断である。
完成記事では、ここを曖昧にしない。Geminiを使うほど、人の判断が不要になるわけではない。むしろ、作業を短縮した分、担当者は読み手理解と意思決定に関わる部分へ時間を使うべきだと書く。
H3: 共有前にデータ取り扱いと権限を確認する
企業利用では、入力した情報と生成した資料の扱いを確認する必要がある。機密情報、顧客情報、未公開の業績数値、採用候補者情報などを扱う場合は、社内ルールに従う。共有時には、閲覧権限、編集権限、リンク共有範囲、外部共有の可否を確認する。
Gemini関連機能の提供状況やデータ取り扱いは更新される可能性があるため、公式ヘルプ、Workspace Updates、Google Blogを確認先として示す。ここでも「必ず安全」といった断定は避け、組織の管理者設定と最新公式情報を確認する姿勢を徹底する。
H2: まとめ（目安: 300〜400文字）
まとめでは、Geminiを使えばスライド作成の初稿化、文章整理、画像生成、要約などを効率化できるが、完成品としてそのまま使うのではなく、人が目的、構成、事実、表現、権限を確認することが重要だと振り返る。
また、用途別にプロンプトを設計することで、営業提案、採用説明、社内報告などの資料品質を安定させやすくなると締める。最後に、ROCKHEARTSへのCTAを1箇所だけ配置する。CTAは押し売りにせず、資料制作やマーケティング施策の整理を相談したい読者に向けた控えめな表現にする。
末尾CTA指定
完成記事では、まとめ本文の最後に以下の趣旨を自然文で1回だけ入れる。本文中や他H2末尾にはCTAを入れない。
資料制作やマーケティング施策の進め方を整理したい場合は、動画制作、WEB制作、広告運用、コンテンツSEO、SNS運用まで横断して支援するROCKHEARTSへの相談も選択肢のひとつです。 [ お問い合わせはこちら ]( https://rockhearts.co.jp/contact ) 6. メタディスクリプション案
Geminiでスライド作成を効率化する方法を解説。Google Slidesでできること、基本手順、用途別プロンプト、失敗回避、企業利用時の注意点まで実務目線で整理します。 7. Claude Codeへの執筆指示
.claude/SKILL.md を必ず守ること。完成記事は6,500〜7,500文字、H2は4〜6個、本構成ではH2 6個で執筆する。箇条書きは全体の10%以下に抑え、プロンプト例以外は自然文を中心にする。
架空事例、架空データ、根拠のない効果断定は禁止。特に「Geminiを使えば必ず資料品質が上がる」「誰でもプロ品質になる」といった誇大表現は不可。公式情報として扱う内容は、競合資料内のGoogle Help、Workspace Updates、Google Blogに基づく範囲に限定する。
CTAは記事末尾1箇所のみ。本文中、各H2末尾、導入文直後に問い合わせ誘導を入れない。ROCKHEARTSの自社紹介は控えめにし、最後に「選択肢のひとつ」として自然に触れる。
参照すべきローカル資料は以下。
種別 パス 品質基準 .claude/SKILL.md競合分析 dev/05_rockhearts/articles/022_gemini スライド作成/01_競合分析.md競合資料 dev/05_rockhearts/articles/022_gemini スライド作成/competitors/サービス情報 dev/05_rockhearts/_context/01_サービス情報.mdトンマナ dev/05_rockhearts/_context/02_トンマナ・文体.md業界知識 dev/05_rockhearts/_context/03_業界知識.md内部リンク dev/05_rockhearts/_context/04_内部リンク設計.md
コピーしました！ # 構成案: Geminiでスライド作成を効率化する方法｜用途別プロンプトと失敗回避まで解説
## 1. 基本情報
| 項目 | 内容 |
| :-- | :-- |
| 対象キーワード | gemini スライド作成 |
| 対象案件 | 05_rockhearts |
| 想定読者 | Google Workspaceを業務で使う企画、営業、採用、管理部門の担当者。短時間で資料初稿を作りたいが、品質や情報精度に不安がある人。 |
| 検索意図 | GeminiでGoogleスライドを作る具体的な手順、用途別のプロンプト、生成後の修正方法、企業利用時の注意点を知りたい。 |
| 記事のゴール | 読者が「目的整理、Geminiで初稿生成、人手で品質確認、共有前チェック」まで再現できる状態にする。 |
| 記事想定文字数 | 6,500〜7,500文字 |
| 本文構成 | LEAD 400〜500文字、BODY 各H2 1,200〜1,800文字、CONCLUSION 300〜400文字 |
| H2数 | 6個（まとめ含む） |
| CTA | 記事末尾1箇所のみ。本文中CTA、H2末尾CTA、サービス紹介H2は禁止。 |
| 箇条書き率 | 完成記事全体の10%以下。プロンプト例以外は自然文中心で書く。 |
## 2. 執筆前提
この記事は、Geminiの新機能紹介ではなく、業務でGoogleスライドを作る人が実際に使える判断材料を提供する記事として設計する。読者は「Geminiでスライドを作れるらしい」という情報は知っているが、どの程度任せてよいのか、どんな指示を出せば品質が安定するのか、生成後にどこを直すべきかで迷っている。
したがって、本文では「便利です」「簡単です」で終わらせない。Geminiは資料作成の初稿化や表現整理には有効だが、事実確認、意思決定に関わる数値、ブランドトーン、最終的な説得設計は人が担う必要がある。この境界線を明確にすることが、競合記事との差別化になる。
ROCKHEARTSのトーンとしては、専門的だが高圧的ではない実務パートナーの語り口を採用する。クリエイティブの見栄えだけでなく、社内合意、営業提案、採用広報、マーケティング施策の成果につながる資料設計として説明する。自社紹介は本文前半で押し出さず、最後のCTAで自然に接続する。
## 3. 競合分析から見た勝ち筋
競合上位は、Google公式ヘルプ、Google Workspace公式リソース、Workspace Updates、Google Blog、Computerworld、TechRepublic、PCWorldが中心である。公式系は機能仕様と更新情報の信頼性が高く、メディア系は新機能のわかりやすい紹介に強い。一方で、実務の資料作成フローに落とし込む情報は不足している。
最も避けるべきなのは、公式ヘルプの機能一覧を言い換えるだけの記事である。画像生成、新規スライド生成、文章改善、要約、Drive参照といった機能を並べても、読者は「結局、自分の営業資料や社内報告にどう使うのか」を判断できない。
本記事の勝ち筋は、用途別プロンプト、失敗パターン、生成後の編集フロー、セキュリティと運用ルールを一体で扱うことにある。特に「できること」と「任せてはいけないこと」を同じ温度で書くと、ツール礼賛ではない信頼性のある記事になる。
## 4. H1
# Geminiでスライド作成を効率化する方法｜用途別プロンプトと失敗回避まで解説
## 5. リード文方針（400〜500文字）
リードでは、資料作成の負担に共感する。営業提案、社内報告、採用説明など、スライド作成は情報整理、構成検討、デザイン調整、文章修正が重なり、想像以上に時間がかかることを言語化する。
次に、Geminiを使えばGoogle Slides上でスライドの初稿作成、文章整理、画像生成、要約などを効率化できると示す。ただし、生成AI任せにすればそのまま提出できるわけではない。事実確認、読み手に合わせた構成、ブランドトーン、共有前の権限確認は人が見る必要がある。
最後に、この記事ではGeminiでスライド作成する基本手順、用途別プロンプト、失敗回避、品質を上げる編集フロー、企業利用時の注意点まで解説すると約束する。
## H2: Geminiでスライド作成はどこまでできる？まず押さえたい基本機能（目安: 1,200〜1,400文字）
### この章の役割
最初に、Geminiでできることと、過度に期待してはいけないことを整理する。読者にとっての不安は「本当に使えるのか」と「どこまで任せられるのか」であるため、機能説明と限界をセットで提示する。
### H3: Gemini in Slidesでできる主なこと
Google Slides上のGeminiでは、スライドの新規作成、既存内容の要約、文章の作成や書き換え、画像生成、Drive上の資料参照などが可能であることを説明する。ここでは公式ヘルプとGoogle Workspace公式リソースを根拠にし、断定しすぎず「利用環境やプランによって表示や提供状況が異なる場合がある」と補足する。
書くべき内容は、機能を羅列するだけでなく、どの作業時間を短縮できるのかに変換すること。たとえば、白紙から構成を考える時間、説明文を整える時間、イメージ画像を探す時間、既存資料から要点を抜き出す時間を減らせる、という形で読者の業務に接続する。
### H3: 生成できるのは「完成品」ではなく「初稿」と捉える
Geminiで作成したスライドは、実務では初稿として扱うべきだと明記する。生成AIは短時間で形を作るのに強いが、読み手の関心、社内政治、提案先の温度感、ブランド上の細かな表現までは完全に判断できない。
ここでは「Geminiが作る、担当者が仕上げる」という役割分担を示す。特に営業提案や採用説明では、相手が何を不安に思っているか、どの順番で納得してもらうかが重要になる。単にきれいなスライドができても、意思決定につながらなければ資料としては弱い。
### H3: 利用前に確認すべき環境と権限
Google Workspaceのプラン、管理者設定、機能提供状況、Workspace Labs/Experiments系の条件に触れる。ここでは具体的なプラン名を過度に断定せず、公式ヘルプや管理者画面で最新状況を確認するよう促す。
企業利用では、個人アカウントで試す場合と組織アカウントで使う場合のリスクが異なる。機密資料や顧客情報を入力する前に、自社のAI利用ルール、データ取り扱い、共有権限を確認する必要がある。
## H2: Geminiでスライドを作成する基本手順（目安: 1,200〜1,500文字）
### この章の役割
読者が実際に手を動かせるよう、資料作成の流れを「目的整理、材料準備、生成、修正、共有前確認」の順で説明する。競合記事の多くは操作説明やニュース紹介に寄っているため、本記事では業務フローとして再構成する。
### H3: いきなり生成せず、目的と読み手を先に決める
最初に決めるべきなのは、スライドの目的である。営業提案なら相手に検討を前に進めてもらうこと、社内報告なら意思決定や承認を得ること、採用説明なら候補者に企業理解を深めてもらうことが目的になる。
ここで、読み手、利用シーン、最終的に取ってほしい行動、必ず入れる情報、入れない情報を整理してからGeminiに指示する必要があると説明する。目的が曖昧なまま生成すると、見た目は整っていても、誰に何を伝えたいのか分からない資料になりやすい。
### H3: Geminiに渡す材料を整理する
Geminiに渡す材料として、既存資料、箇条書きメモ、構成案、商品情報、数値データ、参考トーンなどを整理する。ただし、未公開情報や個人情報、顧客固有の機密情報は入力前に社内ルールを確認し、必要に応じて匿名化する。
この章では、材料を多く渡せばよいわけではないと書く。重要なのは、読み手に必要な情報を優先順位付きで渡すこと。情報量が多すぎると、Geminiは要点を絞れず、1枚に複数メッセージが詰まった資料を作りやすくなる。
### H3: 初稿生成後は大きな構成から直す
生成後すぐに細かな文言や色を直すのではなく、まず構成を確認する。結論が先に出ているか、各スライドの役割が重複していないか、読み手が自然に理解できる順番になっているかを見る。
次に、数値、固有名詞、日付、引用元、サービス内容などの事実確認を行う。最後に、文体やデザインを調整する。この順番を守ることで、見た目を整えた後に構成ごと作り直す無駄を避けられる。
## H2: 用途別に使えるプロンプト設計（営業提案・採用説明・社内報告）（目安: 1,400〜1,700文字）
### この章の役割
本記事の差別化の中心となる章。読者が自分の業務に置き換えられるよう、用途別にプロンプトの考え方を説明する。完成記事ではプロンプト例を載せてもよいが、箇条書きやコードブロックの量を増やしすぎない。プロンプト例は必要最小限にし、前後を自然文で説明する。
### H3: 営業提案スライドのプロンプト
営業提案では、相手の課題、提案する解決策、導入後の変化、判断材料、次のアクションが伝わる構成にする。Geminiに指示する際は、提案先の業種、相手の課題、提案サービス、競合との違い、必ず入れる根拠、避けたい表現を渡す。
プロンプト例では、「10枚前後」「1枚1メッセージ」「結論を先に」「専門用語は補足する」「誇大表現を避ける」といった制約を含める。ROCKHEARTSの文脈では、動画、WEB、広告、SEO、SNSなど複数施策を組み合わせる提案資料にも応用できると自然に触れる。ただし、この章でサービス誘導はしない。
### H3: 採用説明スライドのプロンプト
採用説明では、候補者が知りたい情報と企業が伝えたい情報を分けて整理する。企業理念、仕事内容、働く環境、選考フロー、求める人物像を並べるだけでは、候補者の不安解消につながらない。
Geminiへの指示では、候補者の立場、説明会の目的、入社後のイメージ、強調したい価値観、避けたい過度な美化を明確にする。ここでは、採用広報資料では「魅力づけ」と「誤解を生まない正確さ」の両立が重要だと説明する。
### H3: 社内報告スライドのプロンプト
社内報告では、結論、背景、現状、課題、選択肢、推奨アクションを整理する必要がある。読み手は詳細な説明よりも、何を判断すべきかを早く知りたい場合が多い。
Geminiに指示する際は、報告先、会議時間、意思決定したい内容、使用する数値、前提条件、未確定情報を明確にする。未確定情報は断定させず、「確認中」「仮説」として扱うよう指示する。これにより、AIがもっともらしい断定を作るリスクを下げられる。
## H2: Geminiスライド作成で失敗しやすいポイントと回避策（目安: 1,300〜1,600文字）
### この章の役割
競合記事が薄い失敗回避を扱い、記事の信頼性を高める。便利さだけでなく、実務で起きる手戻りを具体的に示す。完成記事では、失敗例を架空の具体企業事例として捏造しない。一般的に起きやすいパターンとして書く。
### H3: 情報過多で1枚1メッセージが崩れる
Geminiに多くの情報を渡すと、1枚のスライドに複数の論点が詰まりやすい。特に社内報告や営業提案では、伝えたいことが多くなりがちで、結果として読み手が何を判断すべきか分からなくなる。
回避策として、生成前に各スライドの役割を決めること、生成後に「このスライドで一番伝えたい一文は何か」を確認することを書く。必要に応じて、Geminiに「各スライドを1メッセージに絞って再構成してください」と再指示する方法を示す。
### H3: デザインは整っていても、説得の流れが弱い
AI生成のスライドは、見た目が整っているため完成度が高く見える場合がある。しかし、結論が遅い、根拠が弱い、読み手の不安に答えていない資料は、実務では使いにくい。
ここでは、デザイン確認より先に論理構造を確認する必要があると説明する。読み手の疑問が「なぜ今必要か」「なぜこの案か」「次に何をすべきか」の順に解消されるかを見る。
### H3: 事実誤認や古い情報が混ざる
Geminiが生成した文章には、もっともらしいが確認が必要な情報が含まれる可能性がある。数値、日付、固有名詞、料金、機能提供範囲、法令や規約に関わる内容は、必ず一次情報で確認する。
この章では、Google Help、Workspace Updates、Google Blogなどの公式情報を確認先として示す。特にGemini関連の機能は更新が速いため、記事執筆時点の情報として固定せず、最新の公式情報を確認する習慣が必要だと書く。
### H3: ブランドトーンや表現が合わない
企業資料では、色やフォントだけでなく、言葉遣い、温度感、訴求の強さもブランドの一部である。Geminiに「かっこよく」「わかりやすく」とだけ指示すると、自社らしさから外れた表現になる場合がある。
回避策として、トーン、避けたい言葉、使いたい表現、読み手との関係性を事前に渡すことを書く。ROCKHEARTS文脈では、感情を動かすクリエイティブと成果につながるマーケティングの両面を大切にするような表現が望ましい。
## H2: 生成後の品質を上げる編集フローと企業利用時の注意点（目安: 1,300〜1,700文字）
### この章の役割
初稿生成から実務投入までの仕上げ工程を示す。ここで、品質チェック、セキュリティ、共有権限、運用ルールをまとめて扱う。読者が「生成して終わり」ではなく「使える資料に仕上げる」視点を持てるようにする。
### H3: 構造、内容、表現の順でチェックする
編集は、構造、内容、表現の順に進める。構造では、結論の位置、スライド順、重複、抜け漏れを見る。内容では、数値、固有名詞、根拠、引用元、前提条件を確認する。表現では、文体、文字量、見出し、図版、読みやすさを整える。
この順番を守る理由を説明する。先にデザインや言い回しを整えても、構成がズレていれば作り直しになる。実務では、見た目の完成度よりも、意思決定に必要な情報が過不足なく並んでいるかが重要である。
### H3: AIに再生成させる領域と人が直す領域を分ける
AIに任せやすいのは、表現の言い換え、要約、構成案の別案、スライドタイトル案、文章量の調整などである。一方で、人が見るべきなのは、提案の核心、数値の妥当性、顧客固有の事情、社内事情、ブランド上の判断である。
完成記事では、ここを曖昧にしない。Geminiを使うほど、人の判断が不要になるわけではない。むしろ、作業を短縮した分、担当者は読み手理解と意思決定に関わる部分へ時間を使うべきだと書く。
### H3: 共有前にデータ取り扱いと権限を確認する
企業利用では、入力した情報と生成した資料の扱いを確認する必要がある。機密情報、顧客情報、未公開の業績数値、採用候補者情報などを扱う場合は、社内ルールに従う。共有時には、閲覧権限、編集権限、リンク共有範囲、外部共有の可否を確認する。
Gemini関連機能の提供状況やデータ取り扱いは更新される可能性があるため、公式ヘルプ、Workspace Updates、Google Blogを確認先として示す。ここでも「必ず安全」といった断定は避け、組織の管理者設定と最新公式情報を確認する姿勢を徹底する。
## H2: まとめ（目安: 300〜400文字）
まとめでは、Geminiを使えばスライド作成の初稿化、文章整理、画像生成、要約などを効率化できるが、完成品としてそのまま使うのではなく、人が目的、構成、事実、表現、権限を確認することが重要だと振り返る。
また、用途別にプロンプトを設計することで、営業提案、採用説明、社内報告などの資料品質を安定させやすくなると締める。最後に、ROCKHEARTSへのCTAを1箇所だけ配置する。CTAは押し売りにせず、資料制作やマーケティング施策の整理を相談したい読者に向けた控えめな表現にする。
### 末尾CTA指定
完成記事では、まとめ本文の最後に以下の趣旨を自然文で1回だけ入れる。本文中や他H2末尾にはCTAを入れない。
```markdown
資料制作やマーケティング施策の進め方を整理したい場合は、動画制作、WEB制作、広告運用、コンテンツSEO、SNS運用まで横断して支援するROCKHEARTSへの相談も選択肢のひとつです。
[お問い合わせはこちら](https://rockhearts.co.jp/contact)
```
## 6. メタディスクリプション案
```text
Geminiでスライド作成を効率化する方法を解説。Google Slidesでできること、基本手順、用途別プロンプト、失敗回避、企業利用時の注意点まで実務目線で整理します。
```
## 7. Claude Codeへの執筆指示
`.claude/SKILL.md` を必ず守ること。完成記事は6,500〜7,500文字、H2は4〜6個、本構成ではH2 6個で執筆する。箇条書きは全体の10%以下に抑え、プロンプト例以外は自然文を中心にする。
架空事例、架空データ、根拠のない効果断定は禁止。特に「Geminiを使えば必ず資料品質が上がる」「誰でもプロ品質になる」といった誇大表現は不可。公式情報として扱う内容は、競合資料内のGoogle Help、Workspace Updates、Google Blogに基づく範囲に限定する。
CTAは記事末尾1箇所のみ。本文中、各H2末尾、導入文直後に問い合わせ誘導を入れない。ROCKHEARTSの自社紹介は控えめにし、最後に「選択肢のひとつ」として自然に触れる。
参照すべきローカル資料は以下。
| 種別 | パス |
| :-- | :-- |
| 品質基準 | `.claude/SKILL.md` |
| 競合分析 | `dev/05_rockhearts/articles/022_gemini スライド作成/01_競合分析.md` |
| 競合資料 | `dev/05_rockhearts/articles/022_gemini スライド作成/competitors/` |
| サービス情報 | `dev/05_rockhearts/_context/01_サービス情報.md` |
| トンマナ | `dev/05_rockhearts/_context/02_トンマナ・文体.md` |
| 業界知識 | `dev/05_rockhearts/_context/03_業界知識.md` |
| 内部リンク | `dev/05_rockhearts/_context/04_内部リンク設計.md` |