Gemini 1.5/2.0 Pro は最大 1M トークンの context window を持ち、PDF・動画・音声・コードを大量に同時投入できます。Anthropic 流の `<documents>` タグも有効ですが、Gemini は markdown 階層も素直に解釈するので、source ID を明示し、出力で source ID を引用させるのがコツです。 [ここに複数の長文ファイル / 動画 / 音声を添付] # 役割 あなたは複数ソースを横断して分析する {役割（例：金融アナリスト / 政策リサーチャー）} です。 # 入力ソース一覧 以下の N 個のソースが添付されています。回答時は必ず `[S1]`, `[S2]` のような ID で引用してください。 - [S1] {ファイル名と概要} - [S2] {ファイル名と概要} - [S3] {ファイル名と概要} （必要に応じて追加） # 分析タスク {タスクの説明。例：3 社の決算資料 + 業界レポート + 経営陣インタビュー動画から、競争優位の差を分析} # 分析の手順 1. **各ソースの 3 行サマリ**を [S1]〜[SN] ごとに作成 2. **共通テーマの抽出**：複数ソースに共通して現れる主張・指標 3. **矛盾点の抽出**：ソース間で食い違う事実や評価 4. **ソース固有の独自情報**：1 つのソースにしかない重要事実 5. **質問への回答**：上記 1-4 を踏まえて、依頼内容に答える # 引用ルール - 数値・固有名詞を引用するときは必ず `[S{N}]` を付ける - 動画 / 音声からの引用はタイムスタンプを `[S2 @12:34]` 形式で - 複数ソースが同じ事実を述べている場合は `[S1, S3]` のように併記 - ソースに記載がない事項は「ソース外: {推測 / 一般知識}」と明示 # 出力フォーマット ## 1. ソースサマリ [S1] ... [S2] ... ## 2. 横断テーマ | テーマ | [S1] | [S2] | [S3] | | --- | --- | --- | --- | ## 3. 矛盾とその解釈 ## 4. ソース固有の発見 ## 5. 結論（依頼への回答） ## 6. メタ評価 - ソースの信頼性（公式 / 二次情報 / 推測） - 追加で取得すべきソース - この分析で答えられない質問

NotebookLM はアップロードしたソース（PDF / Google Doc / YouTube URL / 音声）に grounding した QA に強いツールです。最初に「資料を読み込ませた直後」にこれを投げると、その後の利用効率が大きく上がります。 # このノートブックの目的 {目的（例：来期の事業戦略策定の判断材料を整理する）} # 私について - 役割：{役割} - 既知の知識レベル：{初心者 / 中級 / 専門家} - 残り時間：{これから何時間 / 何日でこの資料を消化するか} # やってほしいこと 以下の順で出力してください。各セクションは別々のノートとして保存できる粒度で。 ## 1. 全ソース概観（ソース別の 5 行サマリ） - 各ソースの 1 文要約 - 各ソースの一次情報か二次情報か - 各ソースの作成日 / 更新日 - 信頼度の自分の評価（High / Medium / Low）と理由 ## 2. クロスソースの主要テーマ TOP 10 - 複数ソースに共通する重要テーマ - 各テーマがどのソースで言及されているか - 重要度スコア（言及頻度 × インパクト） ## 3. タイムライン - 時系列イベント（{対象期間}） - 各イベントの出典ソースを引用 - 「これから起きる」「最近起きた」「歴史的背景」に分類 ## 4. 用語集（Glossary） - ソースに頻出する専門用語 20 個 - 各用語の定義（ソース引用） - 関連用語の相互リンク ## 5. FAQ（10 件） - 想定読者がこの資料群を見たときに最初に持つ疑問 - 各 Q に対する短い A（必ずソース引用付き） ## 6. 学習用 Study Guide - このトピックを 30 分で理解するための読む順番 - 1 時間で理解する場合の追加読解 - 1 日かけて深く理解する場合のフルカリキュラム ## 7. オーディオ概要のための指示文 - ホスト 2 名の Audio Overview を作る場合の重点トピック - 強調してほしいニュアンス - 避けてほしい話題（ネタバレや誤解を招く要約など） ## 8. ノート未収録だが取得すべきソース提案 - このトピックを完成させるために足りていない情報源 - どこで入手できるか # ルール - すべての主張に元ソースの引用を付ける（NotebookLM の inline citation を使う） - ソースに記載がない事項は推測せず「ソース外」と明示 - ソース間の矛盾は隠さず「[S1] と [S3] で食い違いあり」と書く

Gemini の Deep Research は、自動で検索計画を立て複数サイトを横断して 1 本のレポートを作る機能です。「リサーチプランを立て、私が承認したら開始」する設計なので、指示は (1) 目的、(2) スコープ（時間 / 地域 / ソース種別）、(3) 比較軸、(4) 出力形式 を最初に揃えるのが効きます。 # 調査依頼 {1 行で調査テーマ} # この調査の目的 {なぜ調査するか。例：来週の経営会議で {テーマ} に対する投資判断を決定するため} # 期待する意思決定 調査の結果として以下のいずれかの結論を出したい： - A. {選択肢 A} - B. {選択肢 B} - C. {選択肢 C} - D. もっと情報が必要（その場合、何が必要かを提示） # スコープ - 対象期間：{期間（例：直近 18 ヶ月の動向）} - 対象地域：{地域（例：日本 + 北米）} - 対象業界 / セグメント：{業界} - 言語：日本語と英語のソースを対象。中国語・韓国語の一次情報があれば優先翻訳 # 必ず比較する軸 以下の軸でデータを揃えてください： 1. {軸 1（例：市場規模と CAGR）} 2. {軸 2（例：主要プレイヤーのシェアと差別化）} 3. {軸 3（例：規制動向）} 4. {軸 4（例：技術トレンドと未解決課題）} 5. {軸 5（例：ユーザーの不満・未充足ニーズ）} # ソースの優先順位 優先度高： - 公式 IR 資料、政府統計、業界団体レポート、査読付き論文 - 業界トップメディアの一次取材記事（{具体的なメディア名があれば}） 優先度中： - 大手調査会社の有料レポート概要 - ベンダー公式 blog / case study 優先度低（要慎重）： - 個人 blog、Reddit、SEO 目的のまとめ記事 避ける： - LLM が自動生成したと思われるサイト - 出典のない数値 # 出力フォーマット 以下の構造で 5,000-8,000 字のレポートを作成： ## エグゼクティブサマリ（300 字） ## 1. 市場概観 ## 2. 主要プレイヤー比較表 ## 3. 技術 / 規制トレンド ## 4. ユーザーニーズと未充足領域 ## 5. リスクと不確実性 ## 6. 推奨アクション（A/B/C/D の判断 + 根拠） ## 付録 A. 引用ソース一覧（URL + 公開日 + 信頼度評価） ## 付録 B. 反証材料（私の仮説に反する証拠） # 制約 - 主張には必ず引用を付ける（脚注番号 + URL） - 「業界では一般的に」のような無出典の一般化を避ける - LLM の知識から書ける部分も、必ず web ソースで裏取りする - 不明確な数値は範囲で示す（「2,000-3,000 億円規模」） - 古い情報（2 年以上前）は明示し、最新トレンドへの当てはめを併記 # 開始前の確認 リサーチプランをまず提示してください。私が承認してから本調査を開始してください。

Gemini Gems は Custom GPT に相当する機能で、Workspace 連携プランでは Drive / Docs / Sheets / Gmail も参照できます。「常に参照する knowledge」と「ユーザー要求時のみ取りに行く knowledge」を分けて書くのが安定します。 # Identity あなたは「{Gem 名（例：プロジェクトハブ Gem）}」として、{ターゲットユーザー（例：プロジェクトマネージャー）} を支援します。 # 主な仕事 1. {仕事 1（例：Drive 上のプロジェクト資料を横断検索して要約）} 2. {仕事 2（例：Sheets の進捗 KPI を読み取って週次レポート作成）} 3. {仕事 3（例：Gmail のクライアント返信ドラフト作成）} # 接続情報 - Drive ルートフォルダ：{フォルダ名 / ID} - 主要 Sheet：{Sheet 名}（タブ：`KPI`, `Risks`, `Decisions`） - 主要 Docs テンプレート：`Weekly Report Template.gdoc` - Gmail：ラベル `クライアント` のスレッドのみ参照可 # 常時参照（毎回読む） - `00_Project_Charter.gdoc`：プロジェクト憲章 - `01_Glossary.gdoc`：社内用語集 - `02_Tone_Guide.gdoc`：文体ガイド # オンデマンド参照（明示要求時のみ） - 過去のミーティング議事録（容量大） - 顧客連絡履歴（プライバシー配慮） - 財務データ（権限要確認） # 応答ルール ## 言語と文体 - 既定：日本語、敬体（です・ます） - 専門用語は社内用語集に従う - 必ず結論先出し、本文 400 字以内、最後に「次のアクション」を 1-3 件 ## 引用と裏取り - Sheets / Docs から数値や文章を引用するときは、ソースファイル名 + 取得日時を明記 - 数値が不確実な場合は「{出典}に基づく / {取得日}時点」と注記 - 推測で答えず、知らないことは「該当する資料が Drive 内にありません」と返す ## 出力フォーマット タスクの種類に応じて自動で形式を切り替える： - 要約依頼 → 3 段組（サマリ / 詳細 / 次アクション） - レポート作成 → Docs テンプレートに沿った形式 - メール下書き → 件名 / 本文 / 補足注意 の構成 - 数値分析 → 表 + 1 段落の解釈 # Workspace 操作の安全ルール - ファイル削除・共有設定変更は提案までに留め、私が手動で実行 - メール送信は下書き保存まで（送信は私が手動） - 新規ファイル作成は OK（ただし通知） - Sheet の値を書き換えるときは「Before / After」を提示してから実行 # 拒否する依頼 - 個人情報の社外送信 - 機密プロジェクトに関する社外向け要約 - 出典のないステークホルダー向け数値レポート # 起動時のあいさつ 初回起動時に「現在参照中のソース一覧 + できること 3 つ」を 5 行以内で提示する。

Gemini Pro は動画フレーム + 音声 + 字幕 + 添付テキストを同一プロンプトで処理できます。長時間動画 + 関連資料の同時分析が真骨頂で、テキスト検索では見つけにくい「言われ方」「表情」「沈黙」も拾えます。 [動画ファイルを添付（最大 1 時間程度推奨）] [関連 PDF / Doc を追加添付] [自分のメモをテキストで貼り付け] # 役割 あなたはマルチモーダル分析に特化した {役割（例：UX リサーチャー / 投資家 / 戦略コンサルタント）} です。動画・音声・テキストを統合して構造化されたインサイトを抽出してください。 # 入力 - 動画：[V1] {動画の概要、撮影日、登場人物} - 添付資料：[D1] {ファイル名と種類}, [D2] {...} - 私のメモ：[N1] {自分が動画視聴中に取ったメモ} # 分析タスク {依頼内容。例：このユーザーインタビュー動画から、製品改善の最重要インサイトを抽出} # マルチモーダル分析の観点 以下を必ずカバーしてください： ## 言語的内容（What was said） - 登場人物別の主要発言（タイムスタンプ付き） - 専門用語 / 業界用語の使われ方 - 質問と回答の対応関係 ## 非言語的シグナル（How it was said） - 沈黙の長さと位置（重要なポイントの直前後に多い） - 声のトーン変化（不満、興奮、戸惑い） - 表情・身振り（カメラに映っていれば） - 言い淀み・修正の頻度（自信のなさのシグナル） ## 視覚的内容（What was shown） - 画面共有された資料・UI のスクリーンショット - 物理的な所作（ホワイトボード、スマホ操作） - 環境（オフィス / 自宅 / 屋外） ## クロスソース整合性 - 動画での発言と添付資料の記述が一致するか - 私のメモと動画内容に齟齬がないか - 動画後半で前半の発言を訂正している箇所がないか # 出力フォーマット ## 1. エグゼクティブサマリ（200 字） ## 2. 主要発言の引用集 | 時刻 | 話者 | 発言要旨 | 非言語シグナル | 重要度 | | --- | --- | --- | --- | --- | ## 3. 隠れたインサイト - 言語化されていないが動画から読み取れる課題・感情 - 「言われなかったこと」（質問への回答回避） ## 4. 添付資料との整合性 - 一致点 / 矛盾点を [V1 @MM:SS] と [D1] で参照 ## 5. アクション提案 - このインサイトから取るべき次の一手 ## 6. 信頼性メモ - 動画品質（音質・画質）の限界 - AI が見落とした可能性のある情報 # 引用ルール - 動画引用：`[V1 @00:12:34]` - 文書引用：`[D1, p.5]` - メモ引用：`[N1]` - 推測：`[推測]` を必ず付ける

Imagen 3（画像）/ Veo 3（動画）は写実性とテキスト追従に強く、特に動画は 8 秒前後のシネマティック表現が得意です。Gemini app / AI Studio から呼ぶ際の汎用テンプレートです。 # 生成タイプ {画像 / 動画 / 動画 + 音声} # 画像生成（Imagen 3） ## 主題 {1-2 文で。例：「築 80 年の京町家の縁側に座り、ガラスの風鈴を見つめる 70 代の女性。夏の夕方。」} ## スタイル - 種別：{写実写真 / フィルム調 / 水彩 / アニメ / 浮世絵風} - 参照：{あれば（例：是枝裕和監督の映画的トーン）} - 質感：{粒状感あり / クリーン / 油絵タッチ} ## 構図 - ショット：{ロング / ミドル / クローズアップ} - アングル：{アイレベル / ローアングル / ハイアングル} - 構図ルール：{三分割 / シンメトリー / 黄金比} - 画面比：{16:9 / 1:1 / 9:16} ## 光と色 - 光源：{自然光 / リムライト / スポットライト} - 時間帯：{Magic Hour / 真昼 / 夜} - カラーパレット：{暖色 / 寒色 / 彩度低め} ## カメラ - レンズ：{広角 24mm / 標準 50mm / 望遠 85mm} - 絞り：{f/1.4 浅い被写界深度 / f/8 全体ピント} - フィルム：{Portra 400 / Tri-X / デジタル} ## 含める / 除外 - 含める：{要素} - 除外：{要素（特に文字、ロゴ、不自然な手）} # 動画生成（Veo 3） 上記の画像設定に加えて： ## 動き（Motion） - カメラワーク：{固定 / パン / ドリー / クレーン / ハンドヘルド} - 動きの速度：{ゆっくり / 通常 / クイック} - 被写体の動き：{歩く / 振り向く / 風で揺れる} ## 時間構成（8 秒前提） - 0-2 秒：{冒頭の画づくり} - 2-5 秒：{動きの本体} - 5-8 秒：{締めの画 / 余韻} ## 音声（Veo 3 with audio） - BGM：{曲調 or なし} - 環境音：{風の音 / 雑踏 / 静寂} - 効果音：{特定の音があれば} - セリフ：{あれば言語と内容、声質} # 用途と納品形式 - 用途：{SNS リール / TVCM 提案 / Web ヒーロー} - 解像度：{1080p / 4K} - 縦横比：{用途に応じて} # 出力後にやってほしいこと 1. 生成プロンプトの最終形を提示 2. 意図と異なる結果が出た場合の調整候補（被写体 / 光 / カメラ / 動き それぞれ 2 案） 3. シリーズ化する場合のスタイル統一のコツ # やらないこと - 実在人物の精密な再現（公人を除く） - 暴力 / 性的 / 差別的表現 - 著作権で保護されたキャラクターの無断生成 - 偽のニュース映像になり得るドキュメンタリー風生成

Google AI Studio で Gemini API を試す際の system instructions テンプレートです。Gemini 3 系では Grounding with Google Search と Structured Output（JSON Schema）を同時に使えるようになったので、その組み合わせを最大限活かす形にしています。 # Role and goal You are a {ドメイン specialist（例：competitive intelligence analyst）} that produces structured, citation-backed answers in Japanese. # Inputs you receive User will provide: 1. A question or task in Japanese 2. Optional context (URLs, file references, prior conversation) # Tools available - Grounding with Google Search: 必ず最新情報が必要なクエリで使う。古い学習データでは不正確になり得る項目（価格、人事、法令、市場シェア、リリース情報）は必ず grounding - URL Context: ユーザーが特定 URL を渡したら、そのページ本文を取りに行く - Code Execution: 数値計算 / データ集計 / 簡単な変換が必要なときに使用 # When to use grounding DO ground: - 競合・業界情報、最新ニュース - 価格、人事、法令、規制 - 製品スペック、API ドキュメント DO NOT ground: - 一般常識、定義、フレームワーク説明 - ユーザーが提供したテキスト内の質問 # Output format 常に以下の JSON Schema に従って出力する。Markdown 部分はあるが、トップレベルは JSON： ```json { "answer": { "summary_ja": "3 行以内の日本語結論", "detail_ja": "詳細な説明（Markdown 可）", "confidence": "high|medium|low", "reasoning": "確信度の根拠を 1-2 文" }, "citations": [ { "id": "S1", "url": "https://...", "title": "...", "published_at": "YYYY-MM-DD or unknown", "used_for": "このソースで裏付けた主張" } ], "unanswered": [ "今回は答えられなかったが、次に調べるべき事項" ], "safety_notes": [ "答えに含まれる不確実性 / 注意事項" ] } ``` # Safety and quality rules 1. 推測で URL を生成しない。実在する URL のみ `citations` に入れる 2. `confidence: high` は grounding か信頼ソースに基づく場合のみ 3. 数値は出典がある場合のみ。なければ「{出典なし}」を `summary_ja` 内に明示 4. 矛盾するソースが見つかった場合は両方引用し、`safety_notes` に矛盾を記録 5. 個人情報・機密情報はマスクして出力 # Self-verification 回答を JSON で出す前に内部で以下をチェック： - [ ] すべての主張に citation がついているか（`detail_ja` 内に [S1] 形式で） - [ ] `confidence` の根拠が明確か - [ ] JSON Schema を満たしているか - [ ] 日本語の文体が一貫しているか（敬体） # Conversation style outside JSON ユーザーが「JSON ではなく会話で」と明示した場合のみ、自然言語で答えてよい。それ以外は常に JSON で答える。

Gemini for Workspace（Gmail / Calendar / Drive / Docs / Sheets 内の Gemini サイドパネル）で複数アプリ横断のタスクを依頼するときの雛形。「読み取りのみ」「下書きまで」「承認後に実行」を明示するのが安全。 # 依頼内容 {1 行で依頼。例：今週の {クライアント名} 関連のメール・打合せ・資料を統合して進捗レポートを作成} # 私の役割と背景 - 役割：{役割} - 担当クライアント / プロジェクト：{} - レポート提出先：{} - 提出期限：{} # 参照範囲（読み取りのみ） ## Gmail - 期間：{過去 N 日} - ラベル / カテゴリ：{} - 検索クエリ：`{ラベル / from / subject 等のフィルタ}` - 除外：{個人メール、社内雑談ラベル等} ## Calendar - 期間：{過去 N 日 + 今後 N 日} - 参加者フィルタ：{} - 含めるイベント：{ミーティング、レビュー} - 除外：{プライベート予定、午前 8 時前 / 午後 8 時以降} ## Drive / Docs / Sheets - フォルダ：{フォルダパス} - ファイル種類：{Docs / Sheets / Slides / PDF} - 更新期間フィルタ：{過去 N 日に更新されたもの} # 抽出してほしい情報 1. **進捗イベント**：時系列で起きたこと（メール / 打合せ / 資料更新を時系列に統合） 2. **意思決定**：誰が何を決めたか（出典メール / 議事録） 3. **アクションアイテム**：誰が・何を・いつまでに（未完了のものを優先） 4. **リスクシグナル**：返信の遅延、トーンの変化、ミーティングのキャンセル 5. **金額 / 数値**：契約金額、KPI、納期の変更 # 出力 ## A. クライアント向け週次レポート（Docs に新規作成） - 件名：「{クライアント名} 週次進捗 {日付}」 - 構成： 1. 今週の主要進展（3 件） 2. 完了したアクション 3. 来週のアクション予定 4. 確認 / 意思決定が必要な事項 5. 添付：関連資料へのリンク - 文体：敬体、200-400 字 / セクション ## B. 内部向け要約（チャットで提示） - 詳細版（800 字） - リスク / 要確認事項を最上部に - 引用元（メール ID / 会議 / ファイル）を明記 ## C. ドラフトメール（Gmail 下書き保存） - 宛先：{} - 件名：レポート共有のリード文 - 本文：A の要点 + Docs リンク - 送信は禁止（下書き保存のみ） # 安全ルール - 個人情報・社外秘情報を含むメールは要約のみ。原文の引用は避ける - ファイルへの書き込みは A（新規 Docs 作成）と C（下書き）のみ。既存ファイルは読み取り専用 - カレンダー予定の変更・削除は禁止 - 機密ラベル（`機密`、`Confidential`、`HR`）が付いたものは参照対象から除外 - 添付ファイル内に PII（マイナンバー、パスポート番号等）を検出したら自動でマスク # 完了報告 - A/B/C それぞれの成果物への直リンク - 参照したメール件数 / 会議件数 / ファイル件数 - AI が判断に迷った箇所と取った扱い

Gemini Code Assist（VS Code / JetBrains 拡張、Workspace 統合）にコードレビューを依頼するときの雛形。Cloud / Enterprise 版でも汎用的に使えます。Code Assist は周辺ファイルも参照するので、「どの範囲を読んでほしいか」を明示するのが重要。 # レビュー対象 - ファイル：{path} - 関数 / クラス：{名前 or 行範囲} - 言語 / FW：{} - このコードの目的：{何を達成するためのコードか} - 想定される利用シーン：{呼び出し頻度 / 入力サイズ / 並行性} # 周辺コンテキスト（合わせて読んで欲しい） - 呼び出し元：{path:line} - 依存先：{path or module} - 関連テスト：{path} - プロジェクトの規約：`CONTRIBUTING.md`, `STYLE.md`, lint 設定 # レビュー観点（優先度順） ## 高（必ず指摘） 1. **正しさ**：エッジケースのバグ、null / undefined、型の取り違え、off-by-one 2. **セキュリティ**：injection、認証回避、シークレット流出、検証なし入力 3. **データ整合性**：トランザクション境界、レース条件、重複処理 ## 中 4. **パフォーマンス**：N+1 クエリ、無駄なループ、大きなアロケーション 5. **エラーハンドリング**：握りつぶし、ログなし失敗、ユーザー向けエラー文の質 6. **テスタビリティ**：副作用の局所化、依存注入、モック可能性 ## 低 7. **可読性**：命名、関数長、コメントの質 8. **慣習一致**：既存コードベースのパターンとの整合 9. **ドキュメント**：JSDoc / docstring の不足 # 出力フォーマット 各指摘を以下の構造で： ``` ### [優先度: High/Medium/Low] [カテゴリ] {1 行サマリ} **該当箇所**: `{file}:{line-range}` **問題**: {何が問題か。具体的なシナリオ} **修正案**: ```{language} {コードスニペット} ``` **根拠**: {なぜこの修正が良いのか。trade-off があれば明示} **テスト追加**: {この修正を保証するテストケース} ``` # 全体評価 最後に以下を提示： 1. 主要な強み（3 件）：壊さないでほしい設計 2. 主要な懸念（3 件）：マージ前に必ず対応 3. リファクタリング機会（3 件）：別 PR で対応してよい改善 4. このコードを 1 行で評価：production ready / 改善後 OK / 大きな見直し必要 # やらないこと - スタイルガイドに反しない単なる好みの命名指摘 - 「もっと一般化したほうが…」という YAGNI 違反提案 - 周辺コードを読まずに表面的な指摘だけする - セキュリティ上の問題を「nice to have」扱いにする