～文字起こしの精度向上を待つより、
今ある技術で“使える”議事録を安定生産する3点セット活用術～
この記事でわかること（TL;DR）
- 残念な自動文字起こしテキストも、「トランスクリプト」「用語集」「プロンプト」の3点セットを使えば、実用的な議事録に劇的に改善できます。
- 完璧なトランスクリプトは不要！「そこそこの素材」で十分です。
- 「用語集」でAIの誤変換や専門用語の誤解を防ぎます（作り方も解説）。
- 「定型プロンプト」でAIに明確な指示を与え、議事録の品質と形式を安定させます（コピペ用テンプレートあり）。
- この「型」を使えば、議事録作成時間を大幅に短縮し、誰でも一定品質の議事録を作れるようになります。
0. Before / After で見る議事録変身
会議後、文字起こしを見て「使えない」と感じたこと、ありませんか？
🎧 フィラーだらけ
🌀 話者がごちゃまぜ
🤯 専門用語が謎変換
そんな“残念なトランスクリプト”が、型だけで激変します。
Before：典型的な「残念な」トランスクリプト例
[00:06:55.780 --> 00:06:59.680] はいそういういろんな不具合とか
[00:06:59.680 --> 00:07:03.380] いろいろある中で何が本当の問題なのかって
[00:07:03.380 --> 00:07:05.280] ちょっと見つけづらいし
[00:07:05.280 --> 00:07:12.040] みんなそれをそれに特化した業務をしているわけではない
[00:07:12.040 --> 00:07:14.080] いろんなものを持ちすぎたために
[00:07:14.080 --> 00:07:19.880] なかなかこう分かりづらいのかなと
[00:07:19.880 --> 00:07:22.480] それに対する手立てとか
[00:07:22.480 --> 00:07:25.480] それが何で起こっているかとかいうことが
[00:07:25.480 --> 00:07:28.320] 経験も浅かったりとか
[00:07:28.320 --> 00:07:34.480] あるのでそういう点ではそういうところも
[00:07:34.480 --> 00:07:38.080] 私も含めみんなも
[00:07:38.080 --> 00:07:41.880] 考えてほしいし考えなければならないと思っているので
[00:07:41.880 --> 00:07:43.880] なるほどなるほど
これが、本記事で紹介する「3点セット」を使うと、劇的に改善します。
After：本記事の手法で整形された議事録例
- 様々な不具合や問題に対し、何が本当の問題なのかを見つけにくい。
- メンバーも特定業務に特化しているわけではなく、業務範囲が広いため、問題の本質を把握しにくい。
いかがでしょう。この記事で解説するのは、AI（特にLLM：大規模言語モデル）の力を最大限に引き出すための、実用的な「型」＝構造と、少しの 「事前の準備」 です。
特別なAIモデルの知識や高度なプログラミングは不要です。
この「型」を使えば、
- 議事録作成の時間を大幅に短縮できる
- 専門用語や社内用語の誤変換を激減させられる
- 誰が作っても一定の品質を保てるようになる
可能性があります。
1. 議事録の質を決める3点セット
では、具体的にどうすれば良いのでしょうか？その答えが、以下の3つの要素を組み合わせるアプローチです。
- トランスクリプト（素材）: 会話の生データ。品質はそこそこでOK。
- 用語集（辞書）: AIの知識を補強し、誤りを正すための専用辞書。
- プロンプト（指示書）: AIに「何を」「どのように」議事録にしてほしいかを伝える設計図。
これら3つを「型」として使うことで、異なる会議のトランスクリプトに対しても、安定して質の高い議事録を生成し続けることが可能になります。
次のセクションから、それぞれの要素について詳しく見ていきましょう。
2. 要素①トランスクリプト：そこそこでOK
まず大前提として、議事録の元となるトランスクリプト（文字起こしテキスト）は、完璧である必要はありません。
現在、Zoom、Microsoft Teams、Google Meetといった主要なWeb会議ツールには、会議音声を自動で文字起こしする機能があります。また、OpenAIのWhisperのような音声認識モデルを使えば、より高精度な文字起こしも可能です。どのツールを使っても、特に専門用語や社内用語が多い会議、あるいは複数人が同時に発言するような場面では、誤変換や話者認識のミスは避けられません。
重要なのは、完璧なトランスクリプトを追求することではありません。
「会話の主要な内容がある程度網羅されている」状態であれば、素材としては十分。なぜなら、トランスクリプトに残る誤字脱字、不要なフィラー（「えっと」「あのー」など）、話者の誤認識といったノイズの多くは、後述する「用語集」と「プロンプト」の力で効果的に処理できるからです。
Whisperも使えますが、導入の手間を考えると、まずはZoomやTeamsの書き起こしで十分。大事なのは、素材の精度より「処理の型」です。
3. 要素②用語集：AI誤変換の防波堤
トランスクリプトの品質は「そこそこ」で良いと述べました。それでもAI（特にLLM）が苦手とする領域があります。それが、専門用語、社内用語、略語、そして固有名詞（人名、製品名、プロジェクト名など） の扱いです。
LLMは非常に広範な知識を持っていますが、あなたの会社や業界だけで使われる独特の言い回しや、音声認識が苦手とする特有の単語まではカバーしきれません。これを放置すると、どうなるでしょうか？
- 「RMSのポジショニング」が勝手に「リスクマネジメントの立場決定」に
- 「岩田さん」が「いしださん」に変換される
💡 専門用語や人名の誤解釈を防ぐのが、用語集の役割です。
用語集は、「この言葉はこの意味で、こう表記してね」とLLMに教える、いわばカンニングペーパーです。
用語集の作り方：LLMに手伝ってもらえば、実は簡単
🛠 用語集の作り方（ざっくり3ステップ）
-
素材を集める
過去の議事録・資料・社内文書など -
GPTに抽出させる
下記プロンプトを貼り付ければOK（後述） -
人力で見直す
読み仮名や誤変換候補を補完
-
情報源の収集:
まず、社内に存在するドキュメントを集めます。- 過去の議事録
- 会議資料（PowerPoint、Word、PDFなど）
- 業務報告書
- 製品マニュアルや仕様書
- 社内規定や業務フロー図 など
テキストデータとしてコピー・エクスポートできるものが望ましいです。
-
LLMによる抽出・リスト化:
集めた資料のテキスト（またはその主要部分）をGPTに読み込ませ、用語集を作らせます。以下はコピペで使えるプロンプトの例です。## あなたの役割 あなたは、提供された複数のドキュメントから、頻繁に使用される専門用語、 社内用語、略語、製品名、プロジェクト名、組織名、役職名、人名などを抽出し、 構造化された用語集の草案を作成するアシスタントです。 表記の揺れや一般的な誤変換も考慮し、正確な情報を整理することを目的とします。 ## 実行手順 1. 以下の【ドキュメント群】を解析し、専門用語、社内用語、略語、 固有名詞などを特定してください。 2. 特定した用語について、以下の【出力フォーマット案】を参考に、用語集を作成してください。 3. 特に表記揺れが想定される用語（例：ひらがな、カタカナ、漢字の違い、 略称など）や、音声認識で誤変換されやすいと思われる用語は、 積極的に「表記揺れ・誤変換候補」としてリストアップしてください。 ## 出力フォーマット案 - 用語: [ここに正式な用語を記載] - 読み: [ひらがなまたはカタカナで読み方を記載] - 意味・用途: [簡単な説明、定義、またはどのような文脈で使われるかの補足] - 表記揺れ・誤変換候補: [誤って認識されやすい表記や略称などをカンマ区切りで列挙] ## ドキュメント群 （ここに収集した資料のテキストを貼り付ける。 長すぎる場合は分割して投入するか、代表的な部分を抜粋する） ## 注意事項 - 「意味・用途」が不明な場合は、その旨を記載するか、可能な範囲で推測してください。 - 「表記揺れ・誤変換候補」は、音声認識で間違いやすいパターンを想像しながら記載してください。 -
人間による確認・追記:
GPTが出力した用語集の草案を人間がレビューします。- 不足している用語の追加
- 意味や読みの修正
- 「表記揺れ・誤変換候補」に、現場でよくある間違いパターンを追加
（例：「いわた」と聞こえるが正しくは「いしだ」という人がいる場合、用語: 石田さん, 表記揺れ・誤変換候補: いわた, いわだのように登録）
多くの場合、LLMが生成した草案をほ〜んの少し手直しするだけで、実用的な用語集が完成します。
最初から完璧を目指す必要はありません。必要が出てきたら直せばよいです。
【ステップアップ】用語集の運用とメンテナンス
- 基本の型: 会社や部署で共通して使える「ベース用語集」を一つ作成し、これを議事録作成時のデフォルト辞書とします。
- 追加・特化型: 特定のプロジェクトや会議テーマに固有の用語が多い場合は、ベース用語集に加えて、「追加用語集」をプロンプトで指定する形が柔軟です。（今回の記事で紹介するプロンプト例では、シンプルに1つの用語集ファイルを指定する想定です。）
- 更新頻度: 定期的な見直しが理想ですが、実際には「困ったら直す」で十分。
4. 要素③プロンプト：議事録の設計図
さて、素材となる「トランスクリプト」と、LLMの知識を補強する「用語集」が準備できました。これだけではまだ「使える議事録」にはなりません。最後に必要なのが、LLMに対して「どのように議事録を整形してほしいか」を伝える「プロンプト（指示書）」です。
プロンプトこそが、「3点セット」アプローチの心臓部、「型」の中心要素です。
なぜプロンプトがこれほど重要か？
LLMは指示がなければ空回りします。プロンプトは設計図です。議事録作成のように、ある程度の「型」や「品質基準」が求められる作業では、LLMに以下の情報を明確に伝える必要があります。
- 最終的なアウトプットの形式は？ （例：Markdown、プレーンテキストなど）
- どのような構成で情報を整理？ （例：要点、発言者ごとのやり取りなど）
- 文体や表現のトーンは？ （例：口語調を活かす、だ・である調、敬体など）
- どのような情報を「削除」または「保持」？ （例：フィラー削除、専門用語はそのままなど）
これらの「ルール」を指示することで、LLMは熟練の議事録職人のように、トランスクリプトを整形し始めるのです。
この記事では、汎用性と再利用性の高いMarkdown（マークダウン）形式での出力を前提とします。Markdownはテキストベースで軽量ながら、見出しやリスト、太字などの基本的な装飾が可能なため、議事録の構造化に適しています。また、多くのドキュメントツール（Googleドキュメント、Notion、Wordなど）へのコピー＆ペーストや、HTMLなど他の形式への変換も容易です。
実用的なプロンプトの全文（コピーして調整すれば使えます）
以下に、実際に筆者が業務で使用しているプロンプトの基本形を提示します。これをベースに、あなたの業務やチームのルールに合わせて調整してみてください。
あなたは「質の荒いトランスクリプトを一発で整える熟練の議事録職人」である。
添付のトランスクリプトと用語集を用いて、**Markdown形式の発言記録風議事録**を作成せよ。
以下の要件を厳守すること。
【入力ファイル】
- トランスクリプト：《transcript_file.txt》
- 用語集：《glossary_file.md》
【出力要件】
- コピペ可能な**コードブロック**で返す。
- Markdownのトップレベル見出しは「##」、二階層目は「###」。
- 構成は必ず下記の順序とラベルを用いる。
1. `## 《会議タイトル》`
2. `### 【要点】`（3〜6行程度の箇条書き）
3. `### 【主なやり取り】`（セクション任意で増減可）
【書式詳細】
- 「主なやり取り」では発言者を一次リスト、内容を二次リストで表現する。
- 例：
- 進行役
- 本日のアジェンダですが…
- 田中さん
- その件について質問があります。
- リストは * ではなく **-** を使用し、インデントは半角スペース2つ。
- 太字は必要最小限（固有名詞・キーワードなど）とする。過剰装飾は禁止。
- 文体は**だ・である調**かつ**体言止め**を交えて簡潔に。
- 言い淀み（例：「あのー」「えっと」）、重複語、無意味な相槌は削除し、自然で読みやすい日本語に整形する。
- トランスクリプトに存在しない情報を加筆しない。
- 進行役やファシリテーターの発言は要点を簡潔にまとめ、主要な発言者やゲストの発言は丁寧かつ網羅的に記録する。
【品質基準】
- ビジネス文書としてチーム内で共有可能なレベルを目指す。手作業による修正は、全体の2割程度に収まることが望ましい。
- 見出しの粒度や順序は、会話の流れと重要性を最もよく反映するように、あなたが判断して最適化してよい。
【備考（このセクションはユーザーが適宜調整する）】
- 《会議タイトル》は、トランスクリプトの内容やファイル名から適切なものを
LLMが設定するように促すか、固定で指定します。
- 発言者の名称（例：進行役、田中さん）は、トランスクリプトからLLMが識別
できる場合はそれを、不明な場合は「発言者A」「発言者B」などの一般的な呼称を
使用するよう指示します。
- チームやプロジェクト特有のルールがあれば、【書式詳細】や【品質基準】に
追記してください。
出力は以上の条件を満たす**単一のMarkdownコードブロック**のみとする。
プロンプトのポイント解説
上記のプロンプトで特に意識している点は以下の通りです。
- 明確な役割設定（ペルソナ）: 「熟練の議事録職人」とすることで、LLMに期待するアウトプットの方向性を示す。
- 入力と出力の厳密な指定: どのファイルを参照し（プレースホルダ形式で汎用性確保）、どのような形式（Markdownコードブロック）で出力してほしいかを具体的に。
- 構造化された指示: 【出力要件】【書式詳細】【品質基準】のように項目を分け、それぞれで守ってほしいルールを箇条書きで明確に伝える。
- 裁量の範囲指定: 「見出しの粒度や順序はあなたが判断して最適化してよい」のように、LLMの判断に任せる部分と、厳守してほしい部分を区別する。
このプロンプトを一度作成してしまえば、あとはトランスクリプトと用語集を指定するだけで、毎回同じ品質・同じ形式の議事録が生成されるようになります。これが「型」の力です。
5. 実践：トランスクリプト→議事録に変換
さて、ここまでの理論を踏まえ、0. はじめにの「残念な文字起こし」が、どのように「使える議事録」へと変わるか、具体的なプロセスを追いかけてみましょう。
再掲：あの「残念な」トランスクリプト（Before）
[00:06:55.780 --> 00:06:59.680] はいそういういろんな不具合とか
[00:06:59.680 --> 00:07:03.380] いろいろある中で何が本当の問題なのかって
[00:07:03.380 --> 00:07:05.280] ちょっと見つけづらいし
[00:07:05.280 --> 00:07:12.040] みんなそれをそれに特化した業務をしているわけではない
[00:07:12.040 --> 00:07:14.080] いろんなものを持ちすぎたために
[00:07:14.080 --> 00:07:19.880] なかなかこう分かりづらいのかなと
[00:07:19.880 --> 00:07:22.480] それに対する手立てとか
[00:07:22.480 --> 00:07:25.480] それが何で起こっているかとかいうことが
[00:07:25.480 --> 00:07:28.320] 経験も浅かったりとか
[00:07:28.320 --> 00:07:34.480] あるのでそういう点ではそういうところも
[00:07:34.480 --> 00:07:38.080] 私も含めみんなも
[00:07:38.080 --> 00:07:41.880] 考えてほしいし考えなければならないと思っているので
[00:07:41.880 --> 00:07:43.880] なるほどなるほど
この変換でLLMが「実際に活用した」用語集項目（抜粋）
上記のトランスクリプトを、冒頭で示した「After」の議事録に整形する際、LLMが私たちの用意した用語集の中から特に参照し、活用したであろう項目を以下に抜粋します。
- 用語: 問題の本質
- 読み: もんだいのほんしつ
- 意味・用途: 表面的な事象の裏にある根本的な原因や課題。
- 表記揺れ・誤変換候補: 本当の問題, ほんとうのもんだい
- 用語: メンバー
- 読み: めんばー
- 意味・用途: チームやプロジェクトの構成員。
- 表記揺れ・誤変換候補: みんな, ミンナ
- 用語: 業務範囲
- 読み: ぎょうむはんい
- 意味・用途:担当している仕事の領域や内容。
- 表記揺れ・誤変換候補: いろんなもの
LLMが内部でどのように用語集を参照しているかを把握することは難しいです。出力結果から逆算すると、これらの項目が特に変換の精度向上に貢献したと考えられます。実際の運用では、より多くの用語を登録した包括的な用語集が背景で機能しています。
使用するプロンプト
4. 要素③：プロンプト – LLMを「議事録の匠」に変える“設計図” で提示したプロンプトテンプレートを使用します。
LLMに処理を依頼する際には、概念的に以下のようにトランスクリプトと（より包括的な）用語集をプロンプトに組み込むイメージです。
- トランスクリプト： （上記の「残念なトランスクリプト」のファイル名を記載）
- 用語集： （実際の運用では、より多くの項目を含む用語集のファイル名を記載）
実際にLLMツールやAPIを利用する場合、トランスクリプトや用語集はファイルとして指定することが一般的です。
生成された議事録（再掲：After）
これらの素材とプロンプトをLLMに処理させると、冒頭でご覧いただいた以下の議事録が出力されます。
- 様々な不具合や問題に対し、何が本当の問題なのかを見つけにくい。
- メンバーも特定業務に特化しているわけではなく、業務範囲が広いため、問題の本質を把握しにくい。
なぜ、これだけで劇的に変わるのか？
- 用語集による的確な変換: LLMは提供された用語集を参照し、「本当の問題」という曖昧な表現をより専門的な「問題の本質」へ、「みんな」という砕けた言葉をビジネスシーンに適した「メンバー」へ、そして「いろんなもの」という具体性に欠ける部分を「業務範囲」へと、文脈に合わせてインテリジェントに変換しました。これが用語集の力です。
-
プロンプトによる構造化とノイズ除去:
- 元のトランスクリプトは一続きの文章でしたが、プロンプトの指示に基づき、話の区切りが良いところで箇条書きのポイントとして整理されています。
- 「はいそういう」「ちょっと」「～かなと」「～ということが」のような冗長な表現やフィラー、相槌が効果的に除去され、非常に簡潔で読みやすい内容になっています。
- 文末も、指定した「だ・である調かつ体言止め」に近い、ビジネス文書として適切なトーンに整えられました。
このシンプルな例からも、ターゲットを絞った用語集と、明確な指示を出すプロンプトが連携することで、LLMは“残念な”トランスクリプトを“使える”議事録へと効率的に変換できることがご理解いただけるかと思います。
6. 応用：会議でも面談でも使える型
🎯 「トランスクリプト × 用語集 × プロンプト」 の3点セットは、会議の種類を問いません。構造化する価値のある会話であれば、どんな場面でも有効です。
活用例：
- 🗓 定例会議・進捗報告
- 👥 1on1・人事面談
- 💼 顧客ヒアリング・商談
- 👤 採用面接・フィードバック
- 🎓 研修・勉強会の振り返り
- 💡 ブレスト・アイデア整理
💡 特に、専門用語や固有名詞が頻出する会話では「用語集」の威力が際立ちます。
⚠️ 録音の可否やプライバシー対応には十分ご注意を。
7. 本記事の適用範囲について（ご注意）
本記事で紹介した「型」は、あくまで実務現場における“ざっくり議事録”の生成を効率化するためのものであり、正確性や網羅性が厳密に求められる公的記録や法的文書には適しません。たとえば、議会・審査会・契約交渉といった場面では、引き続き人間による厳密な確認や整文が必要です。
ただし、それ以外の多くの場面――雑でいいが残すこと自体に意味がある記録――において、この「型」は極めて実用的です。具体的には：
- 今まで記録化されなかった1on1・打ち合わせ・レビューなどの会話を、気軽に記録に残せる
- 60分のトランスクリプトを、90秒で議事録化できる（プロンプトと用語集さえあれば）
- 人間の記憶に依存していた情報を、ある程度の構造を持ったテキストとして残せる
- 「時間をかけるべきでない議事録」に、余計な工数をかけずに済む
など、記録の即時化とコスト最適化の両立が可能になります。
LLMによる議事録生成は、まだ「正確性の自動担保」という段階には至っていません。
ですが、「今まで書かなかった記録が、ざっくりでも残るようになる」だけで、情報共有や組織の透明性は大きく前進します。
その意味で、この「型」は、
- “議事録を正確にする技術”ではなく、
- “議事録を生まれやすくし、手間をかけすぎない技術”
だと捉えていただくのが適切です。
8. おわりに：LLMは書記じゃない
多くの人が「LLMが自動で議事録を書いてくれる」ことを期待し、そして、思ったような成果が出ずに落胆します。しかし、それはLLMの能力が低いからではありません。むしろ、LLMに対して「何を期待しているか」の伝え方が不十分なのです。
LLMは、単なる“書記”や“要約マシン”ではありません。明確な指示と構造（＝型）を与えられて初めて、その真価を発揮する “超有能なアシスタント” です。
本記事で紹介した、
- そこそこの品質で十分な「トランスクリプト」
- LLMの知識を補い、誤解を防ぐ「用語集」
- LLMの動きを精密に制御する「プロンプト」
という3点セットは、まさにLLMを“超有能なアシスタント”として活用するための実用的な「構造」です。
音声認識技術がどれだけ進化しても、特定の文脈や組織内でしか通用しない「ドメイン知識」をAIが完全に網羅することは難しいでしょう。だからこそ、人間が「用語集」という形で知識を与え、「プロンプト」という形で期待するアウトプットを定義するアプローチは、今後もしばらくは有効であり続けるでしょう。
この「型」を一度作ってしまえば、トランスクリプトを差し替えるだけで、様々な会議の議事録を効率的かつ安定した品質で作成できるようになります。皆さんの現場でも、ぜひこのアプローチを試してみてください。きっと、議事録作成業務の景色が変わるはずです。
9. テンプレ集（コピペOK）
実際に試していただくために、この記事で紹介した「用語集のフォーマット例」と、「プロンプトの主要な骨子」を再掲します。コピー＆ペーストして、あなたの環境に合わせて調整してみてください。
🔹 用語集の基本フォーマット例（Markdown）
- 用語: [正式な用語 例：問題の本質]
- 読み: [読み方 例：もんだいのほんしつ]
- 意味・用途: [簡単な説明 例：表面的な事象の裏にある根本的な原因や課題。]
- 表記揺れ・誤変換候補: [誤変換されやすい表記 例：本当の問題, ほんとうのもんだい]
- 用語: [別の用語 例：メンバー]
- 読み: [例：めんばー]
- 意味・用途: [例：チームやプロジェクトの構成員。]
- 表記揺れ・誤変換候補: [例：みんな, ミンナ]
上記はあくまでフォーマットの例です。実際の用語集は、あなたの業務で使われる言葉に合わせて具体的に作成してください。特に「表記揺れ・誤変換候補」を充実させることが精度向上に繋がります。
🔹 プロンプトテンプレート（主要な骨子）
以下は、4. 要素③：プロンプト で提示したプロンプトテンプレートから、特に議事録の品質と形式を決定づける主要な指示を抜粋したものです。全文はセクション4をご参照ください。
あなたは「質の荒いトランスクリプトを一発で整える熟練の議事録職人」である。
添付のトランスクリプトと用語集を用いて、**Markdown形式の発言記録風議事録**を作成せよ。
以下の要件を厳守すること。
【入力ファイル】
- トランスクリプト：《transcript_file.txt》
- 用語集：《glossary_file.md》
【出力要件】
- コピペ可能な**コードブロック**で返す。
- Markdownのトップレベル見出しは「##」、二階層目は「###」。
- 構成は必ず下記の順序とラベルを用いる。
1. `## 《会議タイトル》`
2. `### 【要点】`（3〜6行程度の箇条書き）
3. `### 【主なやり取り】`（セクション任意で増減可）
【書式詳細】
- 「主なやり取り」では発言者を一次リスト、内容を二次リストで表現する。
- 例：
- 進行役
- 本日のアジェンダですが…
- 田中さん
- その件について質問があります。
- リストは * ではなく **-** を使用し、インデントは半角スペース2つ。
- 太字は必要最小限（固有名詞・キーワードなど）とする。過剰装飾は禁止。
- 文体は**だ・である調**かつ**体言止め**を交えて簡潔に。
- 言い淀み（例：「あのー」「えっと」）、重複語、無意味な相槌は削除し、自然で読みやすい日本語に整形する。
- トランスクリプトに存在しない情報を加筆しない。
- 進行役やファシリテーターの発言は要点を簡潔にまとめ、主要な発言者やゲストの発言は丁寧かつ網羅的に記録する。
【品質基準】
- ビジネス文書としてチーム内で共有可能なレベルを目指す。手作業による修正は、全体の2割程度に収まることが望ましい。
- 見出しの粒度や順序は、会話の流れと重要性を最もよく反映するように、あなたが判断して最適化してよい。
出力は以上の条件を満たす**単一のMarkdownコードブロック**のみとする。
このプロンプトの【入力ファイル】部分のファイル名指定（《transcript_file.txt》、《glossary_file.md》）は、ご自身の環境や使用するツールに合わせて適宜変更してください。また、《会議タイトル》や発言者名の扱いは【備考】（セクション4参照）を参考に調整すると、より実用的になります。