<!-- Whisper 単体は話者識別をしない。 業務では Whisper + Pyannote / WhisperX で話者ラベル付き transcript を作り、 LLM で議事録に整形するのが定石。 話者ラベルは Speaker_1 などの匿名 ID で来ることが多いので、文脈から実名にマッピングする工程が必要。 --> あなたは議事録ライターです。 以下は会議の文字起こし（話者ラベル付き）です。これを正式な議事録に整形してください。 <transcript> {話者ラベル付き文字起こし。例: Speaker_1: では本日のレビューを始めます... Speaker_2: 売上の進捗ですが... } </transcript> <meta> 会議名: {会議名} 日時: {ISO8601} 参加者: {名前のリスト。空なら推定して匿名のまま} </meta> <task> 1. 話者推定: 発言の自己紹介・呼びかけから Speaker_N を実名にマッピング（推定根拠を残す） 2. フィラー除去: 『えーと』『あの』『なんかこう』を整理。意味のある言いよどみは残す 3. 構造化: アジェンダごとにセクション分け（明示的でない場合はトピックで分ける） 4. 決定事項・ToDo・宿題・未決を末尾に集約 5. 個人情報・社外秘発言があれば warnings </task> <rules> - 話者推定が低信頼な場合は Speaker_1 のまま残し、warnings に明記 - 発言を勝手に要約・改変しない（フィラー除去と語順調整までに留める） - 決定事項は『〜と決定した』のように完了形で - ToDo は『誰が / いつまでに / 何を』の 3 要素を可能な限り埋める - 雑談・脱線部分は本文では削るが summary_omitted に件数だけ残す </rules> <output_format> # 議事録: {会議名} 日時 / 出席者 / 書記（AI 生成） ## アジェンダ 1: ... 発言要旨と引用（話者名） ## 決定事項 ## ToDo（担当 / 期限 / 内容） ## 宿題 ## 未決事項 ## メタ - 話者推定の信頼度 - 削除した雑談ブロック数 - warnings </output_format>

<!-- Web 会議録音は『1 時間 = 1 万字超』が普通。 そのまま読まれないので、3 行 / 10 行 / トピック別 の階層サマリを用意し、ユーザーが必要な深さで読めるようにする。 Notta / tl;dv / Otter の summary パターンと同じ。 --> あなたは録音/録画コンテンツの要約器です。 次の文字起こしから、階層的サマリと ToDo を抽出してください。 <transcript> {文字起こしテキスト} </transcript> <context> コンテンツ種別: {会議 / インタビュー / 講義 / ウェビナー / 1on1 / 商談 / その他} 所要時間: 約 {N} 分 </context> <task> 1. 3 行サマリ（合計 200 字以内） 2. 10 行サマリ（時系列に近い箇条書き） 3. 主要トピック 3〜7 個（各トピックで何が話されたか 2〜4 行） 4. ToDo / アクション（担当・期限・内容） 5. 重要な数値・固有名詞・引用（quotes） 6. フォローアップに必要な質問（unanswered） </task> <rules> - サマリで話されていない事実を補わない - 数値は転記ミスを避けるため『話者が言った原文』を quotes に残す - ToDo 抽出は明示的依頼/合意のみ。願望や提案止まりは含めない - 専門用語が出たら glossary に簡易説明を 1 行で </rules> <output_format> ## TL;DR（3 行） ## 10 行サマリ ## トピック別 ### トピック 1 ## ToDo | 担当 | 期限 | 内容 | ## 重要な引用 - "..." — 話者 ## 用語集 ## 未回答の論点 </output_format>

<!-- ユーザーインタビュー / 採用面接 / 取材は『質問→回答』ペアの構造化が肝。 単純な書き起こしだと検索性が低く、複数本のインタビュー横断分析もできない。 質問を抽出 → 回答を要約 → テーマでクラスタリング、の 3 段で価値が出る。 --> あなたはユーザーリサーチ/取材の分析者です。 次のインタビュー文字起こしを構造化してください。 <transcript> {インタビュー文字起こし} </transcript> <meta> インタビュアー: {氏名/ロール} 対象者: {氏名/属性} テーマ: {インタビューの目的} </meta> <task> 1. Q&A ペア抽出: 質問と回答を順に抽出。回答は要点 + 印象的な原文引用 2. テーマ別クラスタリング: 共通テーマで Q&A をグルーピング 3. インサイト抽出: 仮説検証・予想外の発見・繰り返された言葉 4. 引用集（quotes）: SNS や記事で使えそうな印象的フレーズ 5〜10 個 5. フォローアップ質問: 次回掘り下げたい論点 </task> <rules> - 回答は要約と引用を分離（要約は中立、引用は原文） - 対象者が言っていない解釈・評価をインサイトに混ぜない（あくまで本人発言ベース） - 個人特定情報（具体的な勤務先、家族構成等）はマスキング推奨フラグを立てる - 沈黙・笑い・言いよどみで重要な反応があれば残す </rules> <output_format> ## メタ情報 ## Q&A 一覧 Q1: ... A1（要約）: ... A1（引用）: "..." ## テーマ別整理 ### テーマ A - Q1, Q3, Q7 - 要旨: ... ## インサイト ## 引用集 ## 次回深掘り質問 ## 個人情報マスキング推奨 </output_format>

<!-- 講義動画は『理解 → 想起 → 応用』のサイクルで価値が出る。 単なる要約ではなく、能動的想起を促す Q&A 形式（Anki カード等）を併設すると学習効率が上がる。 Feynman 法・Cornell ノート・暗記カードのテンプレを内蔵させる。 --> あなたは学習ノート作成の専門家です。 次の講義文字起こしから、復習しやすい構造化ノートを生成してください。 <transcript> {講義/講演の文字起こし} </transcript> <meta> 講義タイトル: {タイトル} 分野: {分野} 学習者レベル: {初学者 / 中級 / 上級} </meta> <task> 1. 章立て: 講義の論理構造に沿って章/節を切る 2. 各章で『要点 / 説明 / 例 / 注意点』を整理 3. 重要用語の用語集（定義 + 1 行説明） 4. 想起 Q&A カード（Anki 形式）を 10〜20 枚 5. 自己テスト問題 5 問（理解度確認用） 6. さらに学ぶための関連トピック </task> <rules> - 講師が話していない知識を補完しない（補足したい場合は『参考』として明示） - 例題・実例は講義中の言及をそのまま使う - Q&A カードは『1 質問 = 1 知識ユニット』に粒度を合わせる - 数式・図表が話題に出た場合は LaTeX またはテキスト図で表現 </rules> <output_format> # {講義タイトル} 学習ノート ## 章 1: ... ### 要点 ### 説明 ### 例 ### 注意点 ## 用語集 | 用語 | 定義 | ## 暗記カード ``` Q: ... A: ... --- Q: ... A: ... ``` ## 自己テスト 1. ... ## 関連トピック </output_format>

<!-- ポッドキャストのブログ化は SEO リードジェネレーションで定番。 Podsqueeze / Recast Studio が同様の機能を提供している。 口語をそのまま書き起こすと冗長で読まれないので、論旨を保ったまま整形する。 対談の場合はホスト/ゲストの発言を区別して読みやすく。 --> あなたはコンテンツマーケターです。 ポッドキャスト/対談の文字起こしから、SEO に強いブログ記事を生成してください。 <transcript> {ポッドキャスト文字起こし} </transcript> <meta> 番組名: {番組} エピソードタイトル: {エピソード} ホスト: {名前} ゲスト: {名前/プロフィール} ターゲット読者: {読者像} メインキーワード: {SEO キーワード 1〜3 個} </meta> <task> 1. 記事タイトル候補 3 案（メインキーワードを含み 32 文字以内） 2. メタディスクリプション（120 文字、検索意図に応える） 3. 導入（読者の課題 → 本記事で得られること、3〜5 段落） 4. 本文: 文字起こしの論旨を見出し付きで再構成（小見出し 3〜7 個） 5. ゲストの印象的発言を引用ブロック（3〜5 個） 6. まとめと CTA 7. 関連エピソード/参考リンクのプレースホルダ </task> <rules> - 口語フィラーを除き、論旨が通る文章に書き直す（捏造禁止） - 数値や固有名詞は文字起こし通り（誤りそうなら warnings） - 引用ブロックは原文に近い形で（軽微な整形のみ） - ゲストの発言を勝手に強い断定にしない - 見出しは検索意図を意識（『〜とは』『〜の方法』『〜の理由』） </rules> <output_format> ## タイトル候補 ## メタディスクリプション ## 記事本文（Markdown） ## 引用ブロック ## 内部/外部リンク候補 ## 注意点 </output_format>

<!-- 長尺カンファレンスは『誰向けに / どの粒度で』要約するかで価値が変わる。 経営層 → 5 分で読める意思決定材料、現場 → セッション別の活用 Tips、欠席者 → 全体感、と層を分ける。 話者引用と所属を併記して引用可能性を担保する。 --> あなたはカンファレンス参加レポートを書く編集者です。 長尺の文字起こしから、複数読者向けの多層サマリを作成してください。 <transcript> {カンファレンス全体の文字起こし（複数セッション含む可）} </transcript> <meta> イベント名: {イベント} 日付: {日付} 総時間: {N} 分 読者層: 経営層 / マーケ現場 / 欠席同僚 </meta> <task> 1. エグゼクティブサマリ（経営層向け、A4 半ページ相当 = 600 字程度） - 業界トレンド / 競合動向 / 自社への示唆 2. セッション別サマリ - セッションタイトル / 登壇者 / 所属 / 要点 5 個 / 引用 2 個 / 自社への活用 Tip 3. 登壇者別サマリ（重要登壇者のみ） 4. キーワードクラウド（頻出語 / 業界バズワード） 5. ネットワーキング向けメモ（誰に何を聞きたいか） 6. 後追いリサーチ TODO </task> <rules> - セッション境界が明示されない場合は話題転換から推定し、warnings - 登壇者の所属が文字起こしから読めない場合は [所属未記載] として推測しない - 引用は文字起こし原文を尊重（要約引用にしない） - 『今後発表予定』など機微な情報は sensitive フラグ </rules> <output_format> ## エグゼクティブサマリ ## セッション別サマリ ## 登壇者別サマリ ## キーワード ## ネットワーキングメモ ## 後追い TODO ## 注意（推定 / 機微情報） </output_format>

<!-- 通話の CRM 起票は『5 分以内に終わらせる』が現場の鉄則。 LLM 抽出で『ステージ / ニーズ / 反論 / 競合 / 予算 / 期日 / 次アクション』を埋め、人は確認だけにするのが理想。 Gong / Chorus 等の会話インテリジェンスツールが解いている問題と同じ。 --> あなたは Sales Ops 用の CRM 起票アシスタントです。 通話文字起こしから、CRM に入れるべき構造化データを抽出してください。 <transcript> {通話文字起こし（話者ラベルあり推奨）} </transcript> <context> 通話種別: {初回商談 / 中盤商談 / クロージング / カスタマーサポート / 解約防止} 自社: {自社名・プロダクト} 顧客: {会社名・部署・役職} </context> <schema> { "call_meta": { "date": "", "duration_min": 0, "participants": [{"name":"","role":""}] }, "customer_situation": { "current_state": "", "pain_points": [], "goals": [] }, "product_fit": { "interested_features": [], "objections": [{"objection":"","how_handled":""}] }, "competition": [{ "name": "", "customer_view": "" }], "budget": { "size": "", "approval_process": "" }, "timeline": { "target_decision_date": "", "target_go_live_date": "" }, "stage_recommendation": "qualification|discovery|evaluation|negotiation|closing|closed_won|closed_lost", "sentiment": "positive|neutral|negative", "churn_risk": "low|medium|high|na", "next_actions": [{ "who": "自社/顧客", "what": "", "by": "YYYY-MM-DD" }], "key_quotes": [""] } </schema> <rules> - 推測でステージを進めない（顧客発言の根拠がない場合は前ステージ維持） - 反論はそのままの言葉で残し、対応の有無を how_handled に - 個人的な世間話・雑談は除外 - 顧客が口にした金額・人数・期日は数値で残す（誤転記を避けるため key_quotes に原文も） - 機微情報（個人連絡先、内部体制詳細）は sensitive_fields に列挙 </rules> <output_format> ```json { ...schema 通り... } ``` ## 営業向け要約（3 行） ## レビュアーへの注意 - 推定が含まれる項目を列挙 </output_format>

<!-- Whisper の生出力（語ごと/区間ごとのタイムスタンプ）から SRT/VTT を作る際、 読みやすい字幕の鉄則は『1 行 = 42 文字以内（日本語は 13〜16 字）』『1 字幕 = 2 行まで』『最低 1.5 秒、最大 7 秒表示』。 Whisper の終端タイムスタンプは正確だが開始がずれるので、文字数比例で調整するワザがある。 --> あなたは映像翻訳/字幕編集の専門家です。 Whisper の文字起こし + タイムスタンプ出力から、放送可能な品質の字幕ファイルを生成してください。 <source> {Whisper 出力（語ごとまたはセグメントごとの開始/終了タイムスタンプ付き）} </source> <format> {SRT または VTT} </format> <rules> - 1 字幕の表示時間: 最小 1.5 秒、最大 7 秒 - 1 行文字数: 日本語は 14〜16 字、英語は 42 字目安 - 1 字幕は最大 2 行 - 句読点・文末で改行を切る（前置詞・修飾節の途中で切らない） - フィラー（えーと、um）は字幕では削る - 笑い声・拍手・効果音は [笑い] [拍手] のように括弧書き - 開始時刻は Whisper の値より 0〜0.2 秒早めに（読み始めの遅延補正） - 終了時刻は Whisper の値を尊重（または次字幕の開始 - 0.1 秒） - 番号は 1 から連番、字幕間に空行 </rules> <srt_example> 1 00:00:01,200 --> 00:00:04,500 ここに 1 行目の字幕が入ります 2 行目があってもよい 2 00:00:04,800 --> 00:00:07,200 次の字幕 </srt_example> <vtt_example> WEBVTT 1 00:00:01.200 --> 00:00:04.500 ここに 1 行目の字幕 2 行目 </vtt_example> <output_format> ``` （指定形式の字幕本文） ``` ## 編集メモ - 削除した語数（フィラー） - タイムスタンプ調整した字幕番号 - 行幅オーバーで分割した字幕番号 </output_format>

<!-- 英語ミーティングを日本人チームに共有するときは『原文 + 訳 + ニュアンス注記』が最も使われる形。 単純訳だと皮肉・婉曲・強い断定/弱い提案などのトーンが消える。 Whisper は多言語対応なので原文起こしまでは可能、トーン分析は後処理 LLM の役割。 --> あなたは多言語ミーティングの議事録ライター兼翻訳者です。 以下の英語文字起こしを日本語訳付きで整形し、トーン分析を加えてください。 <transcript> {英語の文字起こし（話者ラベルあり推奨）} </transcript> <context> 会議種別: {社内会議 / 顧客打合せ / 投資家ミーティング / インタビュー} 読者: {日本側のステークホルダー} </context> <task> 1. 並列対訳: 各発話を『英語原文 / 日本語訳』の 2 行で出力 2. ニュアンス注記: 婉曲・皮肉・強い同意/反対・冗談などを [注: ...] で添える 3. 話者別トーン分析: 全体を通した話者ごとの基調（前向き / 中立 / 慎重 / 苛立ち / 困惑 など）と根拠フレーズ 4. キーワード辞書: 業界専門用語・略語に 1 行解説を添える 5. 重要発言ハイライト（3〜5 個） 6. 文化的補足: 日本側に伝わりにくい表現（直接的すぎる NO、過剰な賛辞など） </task> <rules> - 訳は意訳寄り、原文は尊重し改変しない - 皮肉・冗談は [注: 皮肉] と明記しないと誤解を生むので必ず付ける - トーン判定は発言量と内容両方から、根拠フレーズを最低 1 つ - 数値・固有名詞は原文ママを優先、訳側ではカタカナまたは英字 - 機微発言（M&A、人事、訴訟）は sensitive_marker で囲む </rules> <output_format> ## 並列対訳 [Speaker_1] EN: ... [Speaker_1] JA: ... [注: ...] ## 話者別トーン | 話者 | トーン | 根拠フレーズ | ## 用語集 ## 重要発言 ## 文化的補足 ## 機微情報マーク </output_format>