Part3：Geminiを使った業務自動化

設定画面の歩き方：ツールの全体像を把握する (1) 名称・説明: Gemの「顔」。チームで運用するための命名規則が重要です。 (2) インストラクション: Gemの「脳」であり「憲法」。核となる指示はすべてここに記述します。 (3) 知識: Gemの「外部記憶」。独自の情報を参照させるための本棚です。 (4) プレビュー: 作成中のGemをテストする対話画面。トライ&エラーの場です。 Pro-Tip: ここでの設定が、Gemの性能と安定性を決定づける最初の、そして最も重要なステップです。

設計図の4本柱 (1)役割 (Role): 専門家ペルソナを与える ・なぜ役割設定が重要か？ → 回答のトーン、語彙、視点を決定づけるためです。「何でも屋」から「専門家」へと変貌させます。 PRO-TIP より具体的に。「マーケター」よりも「B2B SaaS向けのコンテンツマーケティング戦略を10年経験した熟練マーケター」。具体性が出力品質を高めます。 あなたは、日本の商慣習と法律に精通した、経験豊富な法務レビュー担当者です。

設計図の4本柱 (2)タスク (Task): 実行すべき作業を定義する Gemが実行すべき主目的。曖昧さを排除し、具体的かつ明確に指示します。「いい感じに」はNGです。 PRO-TIP IPOモデル (Input, Process, Output) を意識します。 「[Input]を[Process]して[Output]を作成してください」という構文が基本です。 ユーザーがアップロードした契約書のドラフトをレビューし、潜在的なリスクを特定・指摘してください。

設計図の4本柱 (3)制約 (Constraint): やってはいけない事を教える 思考の暴走や蛇足を防ぎ、出力を安定させるための「ガードレール」です。 PRO-TIP 禁止事項を明確に。「～はしないでください」「～のみを行ってください」といった表現が有効です。情報が不足している場合の例外処理（エラーハンドリング）の指示もここに含まれます。 # 制約事項 - 修正案の提案は行わないでください。リスクの指摘に徹底してください。 - 契約書に記載のない情報の推測や創作は絶対にしないでください。 - リスクが見つからない場合は、その旨を正直に報告してください。

設計図の4本柱 (4)形式 (Format): 出力の「型」を指定する 後続の業務（コピペ、システム連携）を効率化するための最終出口の設計です。 PRO-TIP Markdown、JSON、HTMLなど、機械的に処理しやすいフォーマットを指定すると自動化の幅が広がります。 # 出力形式 以下のMarkdown形式で、リスクレベル（高・中・低）ごとに箇条書きで出力してください。 ## リスクレベル: 高 - (指摘事項1) - (指摘事項2) ## リスクレベル: 中 - (指摘事項3)

実践テクニック(1) Few-Shot Promptingとは？ Instruction -> AI -> (Good Example / Bad Example) -> AI -> High-Quality Output 指示文の中に具体的な「お手本（良い例）」と「反面教師（悪い例）」を数例含めることで、AIの出力スタイルを精密に誘導する技術です。 「百聞は一見に如かず」。言葉で説明するだけでなく、実際のアウトプットを見せて学ばせる家庭教師のようなものです。 特にトーン&マナー、文章のニュアンス、独自のフォーマットなど、言葉で定義しにくいスタイルを模倣させたい場合に絶大な効果を発揮します。

なぜFew-Shotは効くのか? 解釈の「ブレ」をなくす技術 Vague Instruction -> (Brain) -> (Multiple outputs) Instruction + Examples -> (Brain) -> (Single output) ・Problem: 言葉だけの指示 (Zero-Shot) では、AIの解釈に「ブレ」が生じます。「簡潔に」の尺度はAIと人間で異なります。 ・Solution: 具体例は、その「ブレ」をなくすための強力なアンカー（錨）となります。AIは例とのパターンマッチングを行い、最も近いスタイルで出力を生成しようとします。 ・Result: 誰が使っても、いつ使っても、出力品質が安定します。これは「個人のスキル」を「チームの資産」に変えるプロセスです。

実例：悪い例から学ぶ (Few-Shotなし) 悪いプロンプトの例 # 指示 以下の顧客からの問い合わせメールを、丁寧かつ簡潔に要約してください。 # 顧客メール [長文のメール本文をここに挿入] この指示では、AIが「丁寧」「簡潔」を独自解釈するため、要点が抜けていたり、逆に長すぎたりと、品質が安定しません。実行するたびにアウトプットが変わってしまう可能性があります。

実例：良い例で導く (Few-Shot活用) 良いプロンプトの例 # 指示 あなたは顧客対応のプロです。顧客からの問い合わせメールを、以下の良い例・悪い例を参考に、指定のフォーマットで要約してください。 # 良い要約の例 - 問い合わせ元: 株式会社A 鈴木様 - 要点: B製品の納期遅延に関するクレーム - 感情: 強い不満 - 緊急度: 高 # 悪い要約の例 - 鈴木さんが怒ってる。B製品が遅れてるらしい。早く対応しないとやばい。 # 出力フォーマット - 問い合わせ元: - 要点: - 感情: - 緊急度: --- # 顧客メール [長文のメール本文をここに挿入]

Few-Shot Prompting まとめ こういう時に使う - トーン&マナーを厳密に揃えたい時 - 独自のフォーマットを教えたい時 - 出力の品質を安定させたい時 実践のコツ - 良い例と悪い例は対比させると効果的 - 例は2～3個が適切（多すぎると混乱の元） - 指示の最後に例を記述すると認識されやすい

実践テクニック(2) 「知識(Knowledge)」の設定 Concept Gemに社内規定、マニュアル、過去の議事録などの独自ファイルを「参照」させる機能です。 How it Works (Simplified) これはRAG (検索拡張生成) と呼ばれる技術です。ユーザーの質問に関連する部分をファイルから探し出し、その内容を基に回答を生成します。 Use Case 「弊社の出張規定に基づいて、この申請が承認可能か教えて」のような、社内情報が必須のタスクで活躍します。

ファイルの選び方：何を読み込ませるべきか そのタスクの実行に「必要最小限」のファイルに絞り込みます。 良いファイルの例 - テキストベースのPDF: 検索性が高い（例：就業規則、製品マニュアル） - .txt / .md ファイル: 最もシンプルで確実 - 構造化されたデータ: Q&A集、用語集など、一貫したフォーマットの文書 Pro-Tip: ファイル名は内容がわかるようにリネームしましょう。（例：`2024_travel_policy_jp.pdf`）

読み込ませてはいけないファイルと検索精度の話 無関係な情報が多すぎると、AIが参照すべき箇所を見つけられなくなります（ノイズの増加）。 - 画像が主体のPDF: スキャンしただけの文書など、テキスト情報が埋め込まれていないもの - 巨大なファイル: 数百ページに及ぶ包括的なマニュアルより、章ごとに分割したファイルの方が精度が高い場合があります - 無関係なファイル: 「出張規定Gem」に「マーケティング戦略資料」は不要です Pro-Tip: 「知識ファイルの読み込みすぎ」は、Gemが期待通りに動かない時の主要な原因の一つです。迷ったら減らす方向で考えましょう。

「知識」活用時のプロンプト術 Gemに「知識ファイルを参照する」ことを明確に指示し、それ以外の情報源を禁じます。 # 指示 あなたは社内規定の専門家です。 アップロードされている「出張旅費規定.pdf」の内容のみを根拠として、以下の申請内容をレビューしてください。 規定に記載のない事項については、あなたの知識で回答せず、「規定に記載がありません」と回答してください。 「～のみを根拠として」「～で創作せず」といった制約が、ハルシネーション（もっともらしい嘘）を防ぐ鍵となります。

ハンズオン(1)：目的(1)：目的とゴール [乱雑なメモ] -> [Gem] -> [フォーマット済み日報] 外出先で音声入力した箇条書きの活動メモを、上司提出用の綺麗な日報フォーマットに自動変換するGemを作成します。 - Input (入力)：箇条書きの活動メモ（いつ、どこで、誰と、何をしたか） - Output (出力)：指定されたMarkdownフォーマットの整形済み日報

ハンズオン(2)：インストラクションの作成 以下のプロンプトを「インストラクション」にコピー&ペーストしてください。 # Role あなたは、ビジネス文書作成能力に長けた優秀なアシスタントです。 # Task ユーザーが入力した箇条書きの業務メモを、指定のフォーマットに基づいた丁寧な日報に清書してください。 # Constraint - メモにない情報は創作しないでください。 - 事実を簡潔に、客観的に記述してください。 - 各項目は「です・ます調」で記述してください。 # Format ## 本日の業務報告 - **訪問先:** [訪問先] - **面会者:** [面会者] - **活動内容:** - [活動内容1] - **所感:** [所感やネクストステップ]

ハンズオン(3)：Few-Shotで品質安定 品質をさらに安定させるため、以下のFew-Shot例をインストラクションの末尾に追記しましょう。 --- # 良い日報の例 ## 本日の業務報告 - **訪問先:** ABC商事 本社 - **面会者:** 経理部 佐藤部長 - **活動内容:** - 新会計システムのデモンストレーションを実施しました。 - **所感:** 機能面での評価は高いものの、価格面で競合と比較検討されている様子でした。 # 悪い日報の例 ABC商事の佐藤さんと会ってデモした。たぶん契約してくれると思う。

ハンズオン(4)：テストしてみよう プレビュー画面で、以下のメモを入力して結果を確認してみましょう。 - XYZ建設 - 建築一部 田中様 - 定例ミーティング。来週のプレゼン資料の合意形成。 - 次回は最終版を持参する。 前のスライドの「良い日報の例」と同じフォーマットで、上記の内容が整形されて出力されることを確認します。

テストとデバッグの方法 プレビュー画面は「対話形式のデバッグツール」 - 正常系テスト：意図した通りの入力で、期待通りの出力が得られるか？ - 異常系テスト：曖昧な指示や情報が不足した入力を投げかけ、どう反応するか？（エラーハンドリングの確認） - 境界値テスト：非常に長い文章や、逆に一言だけの入力を試す。 Pro-Tip: 期待通りの出力でなければ、がっかりせず「インストラクションのどこが曖昧だったか？」を考え、制約や例を追加して修正する。このサイクルがGemを「育てる」ということです。

実装時のよくあるミス TOP 3 1 指示が長すぎる・構造化されていない - Problem: 重要な指示が文章の海に埋もれてしまい、AIが無視します。 - Solution: Role/Task/Constraint/Formatのようにセクションを分け、箇条書きと見出し（`#`）を使って構造化します。 2 矛盾した指示が混在している - Problem: 「簡潔に、かつ網羅的に」など。AIが混乱し、出力が不安定になります。 - Solution: 優先順位を明確にします。「最も重要なのは正確性です。その上で、可能な限り簡潔にしてください。」 3 「知識」を信頼しすぎる - Problem: 関連性の低いファイルを大量に読み込ませて検索精度を下げてしまう。または、ファイル参照の指示を忘れてしまいます。 - Solution: タスクに必須のファイルに厳選し、プロンプトで「アップロードしたファイルのみを根拠に」と明確に指示します。