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

第2部：設計の極意 いきなり作り始めてはいけない 優れたGemは、優れた「設計図」から生まれる。 チャット脳から設計脳へ、思考を切り替えよう。

全ての自動化は、このフレームワークから始まる Gemを作る前に、必ず以下の3つの要素を紙に書き出しましょう。 これが自動化の設計図の根幹です。 [ I ] Input (入力) ユーザーは何を、どのよ うな形式で入れるのか？ [ P ] Process (処理) AIは具体的に何をするの か？ [ O ] Output (出力) 何が、どのような形式で 出てくれば正解か？

IPOモデル徹底解説①：Input (入力) の定義 Gemに何を与え、何を前提とさせるか？ 入力の質が、Gemのパフォーマンスの天井を 決めます。「ゴミを入れたらゴミが出てくる (Garbage In, Garbage Out)」原則を忘れな いでください。 入力の具体例 ・箇条書きの会議メモ ・顧客からの長文問い合わせメール ・音声入力したままの、未整理のテキスト ・スプレッドシートの特定セルのデータ 設計のポイント どのような形式のデータが 投入されるかを明確に定 義することで、AIの迷い をなくします。

IPOモデル徹底解説②：Process (処理) の定義 AIにどのような「思考」や「作業」をさせるか？ ここがGemの「頭脳」にあたる部分です。複数の処理を組み合わせることも可能です。 処理の具体例 ・要約 (Summarization): 長い文章 の要点をまとめる。 ・翻訳 (Translation): ある言語を別 の言語に変換する。 ・トーン変換 (Tone Conversion): カジュアルな文章をフォーマルな 敬語に書き換える。 ・抽出 (Extraction): テキストから 特定の情報(例: 人名、日付、会 社名)を抜き出す。 ・分類 (Classification): 問い合わ せ内容を「緊急」「通常」「質問」 などに分ける。 ・構造化 (Structuring): 自由記述 の文章を表形式に整理する。

IPOモデル徹底解説③：Output (出力) の定義 何が出てくれば「成功」と言えるか？ 出力は、自動化の「ゴール」です。フォーマットまで含めて具体的に定義することで、 誰が使っても同じ品質の成果物が得られます。 出力の具体例 ・Markdown形式の表 ・HTML形式のメール本文 ・JSON形式のデータ ・上司への報告用に整形された、3つの箇条書きの テキスト ・プレゼン資料の各スライドのタイトル案リスト

ケーススタディ：議事録Gemの設計 まずは、多くの人がやってしまう「悪い設計」から見てみよう。 `さっきの会議のメモです。いい感じに議事録にまとめてくださ い。` `(Here are the notes from the meeting a minute ago. Please summarize them into minutes that look good.)` これから、この指示が「なぜダメなのか」を分解していく。

なぜこの設計は悪いのか？3つの欠陥 この指示には、AIを混乱させる致命的な「曖昧さ」が含まれています。 1. Inputが不明確 ・「さっきの会議のメモ」 とは何か？ ・手書き？テキスト？箇 条書き？ ・AIは前提知識を持ってい ません。 2. Processが不明確 ・「まとめる」とは具体的に 何をするのか？ ・要約するだけ？整形する？ ToDoを抽出する？ 3. Outputが不明確 ・「いい感じに」は人によ って解釈が異なります。 ・どのようなフォーマット (箇条書き、表)を期待し ているのか不明です。

設計改善ステップ①：Inputを再定義する まず、Gemに与える情報を厳密に定義します。今回は「会議中の箇条書きメモ」をインプットと 定めましょう。 BEFORE (悪い例) 「さっきの会議のメモ」 AFTER (良い例) 以下のルールで書かれた、会議中の箇条書 きテキスト： ・発言者の名前は行頭に【】で記載 ・決定事項は「(決定)」と末尾に記載 ・タスクは「(ToDo)」と末尾に記載 **Key Takeaway**: 入力にルールを設けることで、AIの処理精度が飛躍的に向上します。

設計改善ステップ②：Outputを定義する 次に、Gemが生み出すべき最終成果物を、フォーマットを含めて具体的に定義します。「いい感じ」 をロジックに変換します。 Desired Output Format: ```markdown ## 議事録 ### 1. 決定事項 - [ここにAIが抽出した決定事項をリスト] ### 2. ToDoリスト - [ここにAIが抽出したToDoをリスト] ### 3. 主要な議論 - [ここにAIが要約した議論内容をリスト] ``` **Key Takeaway**: ゴールが明確であればあるほど、AIは最短距離でそこに到達できます。

完成形：IPOを定義した「良い設計」 InputとOutputを定義したことで、指示はここまで具体的かつ強力になります。 Bad Design 「さっきの会議のメモです。いい感 じに議事録にまとめてください。」 Good Design ```prompt あなたはプロの書記です。提供された会議メモから、以下のフォーマットに 従って議事録を作成してください。 # 入力データ [ここにユーザーが会議メモをペースト] # 出力フォーマット ## 1. 決定事項 ## 2. ToDoリスト ## 3. 主要な議論 # 制約事項 - メモから「(決定)」と書かれた項目を決定事項に抽出してください。 - メモから「(ToDo)」と書かれた項目をToDoリストに抽出してください。 ```

Gemを「再利用可能なツール」にするための重要概念 優れた自動化ツールは、毎回変わる部分と、絶対に変わらない部分を明確に分離して設計されています。 変数 (Variables) ・毎回変わるもの (Things that change every time) ・例：顧客名、日付、製品名、問い合わせ内容 ・→ ユーザーが入力する部分 定数 (Constants) ・絶対に変わらないもの (Things that never change) ・例：自社の署名、定型挨拶、社内用語、フ ォーマット ・→ Gemの指示文に固定で埋め込む部分

具体例で考える：メール作成Gemの場合 あなたが毎週、新しい顧客に送っている製品案のフォローアップメールを想像してください。文面は以下 の通りです。 件名：【株式会社XXX】製品Aに関するお問い合わせのお礼 株式会社YYY 田中様 いつもお世話になっております。 株式会社XXXの鈴木です。 先日は、弊社の製品Aについてお問い合わせいただき、誠にありがとうございました。 つきましては、お打ち合わせの日程を調整させていただけますと幸いです。 来週20日の週でご都合のよろしい時間帯をいくつかお教えいただけますでしょうか。 何卒よろしくお願い申し上げます。 --- [Your Signature Block]

この中で「毎回変わる部分」はどこだろう？ このメール文面の中で、送る相手や状況によって毎回書き換える部分を特定してみましょう。これらが「変 数」になります。 件名：【株式会社XXX】製品Aに関するお問い合わせのお礼 株式会社YYY 田中様 いつもお世話になっております。 株式会社XXXの鈴木です。 先日は、弊社の製品Aについてお問い合わせいただき、誠にありがとうございました。 つきましては、お打ち合わせの日程を調整させていただけますと幸いです。 来週20日の週でご都合のよろしい時間帯をいくつかお教えいただけますでしょうか。 何卒よろしくお願い申し上げます。 --- [Your Signature Block] [商品名] [顧客企業名] [顧客担当者名] [商品名] [提案日程]

「変数」をユーザー入力として定義する 特定した変数は、Gemがユーザーに質問すべき項目になります。これにより、Gemは毎回カスタマイズされた 出力を生成できます。 フォローアップメール作成Gem 顧客企業名を入力してください: 顧客担当者名を入力してください: 製品名を入力してください: 提案したい日程を入力してください: [User inputs variables] [Gem inserts them into the template] [Customized email is generated]

「定数」はカスタム指示に固定記述する 一方で、変数以外の部分は「定数」として、Gemのカスタム指示に直接書き込みます。 これにより、ブランドボイスや敬語のレベル、フォーマットが常に統一されます。 ``` # メール本文テンプレート いつもお世話になっております。 株式会社XXXの鈴木です。 先日は、弊社の[商品名]についてお問い合わせいただき、誠にありがとうございました。 ... # 制約事項 - 常に丁寧なビジネス敬語を使用すること。 - 署名は必ず所定のフォーマットを使用すること。 ``` **Key Takeaway**: 定数を固定することで、Gemは「常にベストコンディションの優秀な部下」 として機能します。

信頼性を揺るがす最大の敵：情報の不足 もしユーザーが必要な情報 (変数) を入力し忘れたら、何が起きるか？ 情報が不足している時、AIは不完全なアウトプットを生成したり、最悪の場合、事実に 基づかない「嘘」を自信満々に創作(ハルシネーション)したりすることがあります。 Hallucination 明日の14時に お伺いします **Example Scenario**: ユーザーがメール作成Gemで「日程」を入れ忘れた → AIが勝手に「明日の14時」という嘘の日程を生成してしまう。

AIに「嘘」をつかせない技術：聞き返しの指示 信頼性の高いGemを設計する鍵は、例外処理 (エラーハンドリング) をあらかじめ指示に組み込んで おくことです。具体的には、「もし～がなければ、～と聞き返す」というルールを追加します。 # エラーハンドリング もしユーザーの入力内容に「お打ち合わせの日時」に関する情報が含まれていない場合は、 決して日時を創作してはいけません。 代わりに、ユーザーに「お打ち合わせの希望日時を教えてください。」と質問し、応答を待 ってください。 (If the user's input does not contain information about the "meeting date and time," you must never invent a date and time. Instead, you must ask a spo-time, you must envead. Intead, you must ask the user, "Please tell me your desired date and time for the meeting," and wait for a response.)

聞き返しルールの有無による挙動の違い 聞き返しルールなし `株式会社YYYの田中様へ製品Aの フォローアップメールを作成` 承知しました。[...本文...]つきまして は、来週月曜の15時にお打ち合わせ はいかがでしょうか。[...以下略] 危険 (DANGER) - AIが勝手に日程を創作 聞き返しルールあり `株式会社YYYの田中様へ製品Aの フォローアップメールを作成` 承知しました。お打ち合わせの希望 日時を教えていただけますか？ 安全 (SAFE) - ユーザーに確認し、正確 な情報でタスクを遂行

エラーハンドリングが実用性を劇的に向上させる たった一行の「聞き返し」指示が、あなたのGemを「面白いおもちゃ」から 「信頼できる業務ツール」へと昇華させます。 事故の防止 (Prevents Accidents) 不正確な情報に基づく誤った アクションを防ぎます。 ユーザーの信頼獲得 (Builds User Trust) 賢明な挙動は、ユーザーに「この ツールは信頼できる」という安心 感を与えます。 利用の定着 (Promotes Adoption) 失敗体験が少ないツールは、チー ム内で広く使われるようにな ります。

PCを開く前に、この設計チェックリストを埋めよう 優れたGemはコードを書く前に9割完成している。このリストが全て埋まるまで、Gemの作成画 面を開いてはいけない。 □ 目的 (Purpose) : このGemは何を、誰のために解決するのか？ □ INPUT (入力) : ユーザーは何を、どのような形式で入力するのか？(例: 箇条書きメモ) □ PROCESS (処理) : AIは具体的に何を行うのか？(例: 要約、抽出、変換) □ OUTPUT (出力) : どのような形式で、何が出力されれば成功か？(例: Markdownの表) □ 変数 (Variables) : 毎回ユーザーが指定する必要がある情報は何か？(例: 顧客名、日付) □ エラー処理 (Error Handling) : 入力が不足していた場合、AIはどう振る舞うべきか？(例: 聞き返す)