Claudeでセミナーレポートを文字起こしから作る — 登壇者の発言を引用と要約に分ける
セミナー録画の文字起こしをClaudeに渡し、直接引用・言い換え・筆者の補足を分けたレポートを作る手順。登壇者に確認を取る箇所の抜き出しと、引用の原文照合つきです。
セミナーレポートは「誰の言葉か」を保つ記事
セミナーやイベントのレポートは、登壇者が話したことを、参加していない人に伝える記事です。議事録と違って公開が前提で、記事に載った発言は登壇者本人の言葉として読まれます。Claudeに文字起こしを渡せば構成案と本文の下書きまでは短時間で進みますが、速さの代わりに起きやすいのが、言っていないことが引用符の中に入る事故です。
Claudeが出す引用には注意が必要です。ヘルプセンターには、Claudeが権威ありげで説得力のある引用を表示しても、事実に基づかない場合があると書かれています。そこで、この手順は書く前に発言を台帳にし、書いた後に原文と機械で突き合わせ、最後に登壇者へ見せる箇所だけを抜き出す順にします。
レポート作成の5段階
- 1
文字起こしに発言IDを振る
話者名と時刻を付け、1発言1行にします。
- 2
発言台帳を作る
発言を直接引用・言い換え・補足の候補に仕分けします。
- 3
構成案と本文を書く
引用には必ず発言IDを添えさせます。
- 4
引用を原文と照合する
スクリプトで、引用が文字起こしに実在するかを検算します。
- 5
登壇者への確認リストを作る
確認に出す箇所だけを、理由つきで抜き出します。
同じ「文字起こしを記事にする」でも、顧客事例やインタビューとは勝手が違います。登壇者が複数いること、質疑応答で参加者の発言が混ざること、スライドを見ながら話した内容は音声だけでは意味が通らないことが、セミナー固有の難所です。顧客1社を取材する事例記事の流れは導入事例の作り方、10本前後の逐語録の横断分析はインタビュー逐語録の横断分析が扱っています。
記事に出てくる発言は3種類に分ける
レポートの文章は、出どころで3つに分けて書きます。ここを混ぜないことが、登壇者に確認を取りやすくする前提になります。
| 種類 | 記事での見え方 | 確認の重さ |
|---|---|---|
| 直接引用 | 記事での見え方「」で囲み、発言IDを持つ | 確認の重さ全件を登壇者に見せる |
| 言い換え要約 | 記事での見え方地の文。登壇者の主張として書く | 確認の重さ数字・固有名詞・断定の強さを見せる |
| 筆者の補足 | 記事での見え方背景説明や用語の注。登壇者の発言ではない | 確認の重さ登壇者の確認は不要。事実は別途照合 |
この仕分けをClaudeに任せるとき、いちばん崩れやすいのは言い換え要約です。登壇者が「検討の余地がある」と言った箇所を、要約で「有効です」と書き換えると、引用符が付いていなくても本人の主張が変わります。要約にも、元になった発言IDを付けさせるのはそのためです。
録画は渡せない。文字起こしの形を先に決める
ヘルプセンターのファイル種類の一覧に載っているのは、PDF・DOCX・CSV・TXT・HTML・ODT・RTF・EPUB・JSON・XLSXのドキュメントと、JPEG・PNG・GIF・WebPの画像です。音声や動画のファイル形式は載っていません。録画から文字起こしを作る作業は、会議ツールの自動文字起こしや文字起こしサービスで済ませ、できたテキストをClaudeに渡します。録音を会話から検索する方法は、PlaudのMCP連携にまとめています。
文字起こしは、Claudeに渡す前に次の形へ整えます。話者を区別するラベルと時刻、そして1発言ごとの通し番号があれば足ります。
[S001 00:00:41 司会] 本日はご参加ありがとうございます。
[S002 00:02:10 登壇者A] 当社では、問い合わせの一次回答を半年かけて見直しました。
[S003 00:02:48 登壇者A] 結果として、再問い合わせの件数は体感で減っています。
[S041 00:48:05 参加者] 導入の費用感を教えてください。
[S042 00:48:20 登壇者B] 規模によりますが、まず小さく試す形をお勧めしています。S003の「体感で」のような話し言葉の留保は、記事に載せるときに落ちやすい部分です。台帳の段階で、こうした留保つきの発言には印を付けます。参加者の発言は、話者を「参加者」のままにしておきます。質疑応答の発言者は、記事に名前を出さない前提で扱うほうが安全です。
文字起こしはTXTかDOCXで保存します。ツールが出す自動文字起こしは、人名・社名・製品名の誤変換が残りがちなので、固有名詞だけは登壇者の資料(スライド、配布資料)と見比べて直してからClaudeに渡します。
Projectsに置くもの
セミナーが連続開催なら、毎回の指示を短くするためにプロジェクトを使います。ヘルプセンターによれば、プロジェクトは独立したチャット履歴とナレッジを持つ作業スペースで、ナレッジに置いた資料はプロジェクト内のすべてのチャットで使われます。ただし、プロジェクト内でもチャット同士の文脈は共有されないので、前のチャットで決めたルールは、ナレッジかプロジェクト指示に書いておく必要があります。
置くものは次の3つです。
- 文字起こし(発言ID付きのTXTまたはDOCX)
- 登壇者のスライドや配布資料(固有名詞と数字の突き合わせ用)
- 過去のレポート1本(文体と見出しの見本)
プロジェクトを作るとき、名前と説明にルールを書いても意味がありません。作成手順の説明に、Claudeはプロジェクトの名前と説明にアクセスできないと明記されています。ルールは「プロジェクト指示を設定」に書きます。次のような形が使えます(例示です。自社の媒体に合わせて書き換えます)。
あなたはセミナーレポートの下書きを手伝う。
- 登壇者の発言は、文字起こしの発言IDで特定できるものだけを使う。
- 「」で囲む直接引用は、文字起こしの文言をそのまま使う。
言い換える場合は「」を付けず、元の発言IDを [S012] の形で添える。
- 筆者の補足は、文頭に【補足】と付けて区別する。
- 文字起こしに無い数字・固有名詞・因果関係を書かない。
不明な点は「不明」と書いて質問に回す。ファイルのサイズにも上限があります。プロジェクトに置くファイルは1つ30MBまでで、枚数に制限はないものの、内容全体がコンテキストウィンドウに収まる必要があります。2時間級のセミナーの文字起こしは、これに触れる長さになることがあります。
全文を読ませたいのに、検索に切り替わることがある
有料プランでは、プロジェクトのナレッジがコンテキストの上限に近づくと、Claudeが自動でRAGモードに切り替わります。このモードでは、すべての内容を一度に読み込むのではなく、必要そうな部分を検索して取り出します。容量は最大10倍に広がりますが、レポート作成のように「全発言を漏れなく見て、重要度を判断する」作業とは相性がよくありません。検索で拾われなかった発言は、台帳に載らないからです。
対策は、文字起こしを30分程度の区間に分けてファイルにし、区間ごとに台帳を作らせることです。台帳ができたら、台帳そのもの(こちらは短い)を使って構成案へ進みます。RAGが働いているかどうかは、Claudeがプロジェクトナレッジの検索ツールを使う様子で見分けられます。検索に切り替わる仕組みの詳細はプロジェクトのRAG検索にあります。
手順1: 発言台帳を作る
区間ごとのファイルを渡して、次のように頼みます。
添付の文字起こし(S001〜S120)から、発言台帳を作って。
列: 発言ID / 話者 / 時刻 / 分類 / 要点(30字以内)
分類は次の4つから1つ選ぶ。
引用候補 … 記事に「」で載せる価値がある、言い切りの発言
要約 … 主張を地の文で伝える発言
留保あり … 「体感で」「かもしれない」など断定を弱める語を含む
対象外 … 司会進行、雑談、聞き取れない部分
文字起こしに無い発言は一行も作らない。台帳の出力を見るとき、確認するのは「引用候補」と「留保あり」の件数です。留保あり、かつ引用候補のものは、登壇者の本意が最も変わりやすい発言です。後の確認リストで最初に見せる対象になります。
分類の判断はClaudeに任せきりにせず、台帳を見て人が直します。「引用候補」に司会の挨拶が入る、重要な数字を含む発言が「対象外」になっている、といったずれは、数分で見つかります。
手順2: 構成案を台帳から作る
構成案は、台帳だけを材料に作らせます。文字起こしの全文を見せると、発言IDのない言い回しを拾いがちだからです。
台帳をもとに、レポートの構成案を作って。
- 見出しは登壇ごとに立て、各見出しの下に使う発言IDを並べる。
- 質疑応答は、登壇者の回答だけを使う。参加者の発言は要約にとどめる。
- 台帳に無い論点は構成に入れない。構成案の各見出しに発言IDが並ぶので、書き手は「この見出しは、どの発言を根拠にしているか」をその場で追えます。ここで根拠の薄い見出しが見つかれば、本文を書く前に落とせます。
手順3: 本文を書かせる
構成案を確認したら、見出しごとに本文を書かせます。一度に全体を頼むより、見出し2〜3個ずつのほうが、引用の取り違えを見つけやすくなります。
構成案の「見出し1〜3」の本文を書いて。
直接引用は「」の直後に [S002] の形でIDを付ける。
言い換えの文にも、文末に元の発言IDを付ける。
登壇者の留保(「体感で」など)は、要約でも落とさない。出力された本文には、あとで機械が見つけられるよう、「引用」[S002] の形で印が付きます。記事として公開する前に、このIDは取り除きます。IDの付いたままの下書きは、照合専用の版として別に保存しておくと、修正を重ねるときに便利です。
手順4: 引用を原文と照合する
Claudeに「引用は正確か」と聞き直しても、確認にはなりません。同じ誤りを繰り返す可能性があるからです。照合は、文字起こしのテキストを相手に、手元のスクリプトで行います。次のPythonは、下書きの 「…」[S###] を拾い、そのIDの発言に引用が含まれているかを調べます。
import re, sys, unicodedata
def norm(s):
s = unicodedata.normalize("NFKC", s)
return re.sub(r"\s+", "", s)
lines = {}
for ln in open("transcript.txt", encoding="utf-8"):
m = re.match(r"\[(S\d+) [\d:]+ [^\]]+\] (.*)", ln)
if m:
lines[m[1]] = norm(m[2])
draft = open("draft.md", encoding="utf-8").read()
bad = 0
for quote, sid in re.findall(r"「([^」]+)」\[(S\d+)\]", draft):
for part in quote.split("…"):
if norm(part) not in lines.get(sid, ""):
bad += 1
print("不一致:", sid, part)
print("不一致", bad, "件")
sys.exit(1 if bad else 0)実行は次のとおりです。
python3 check_quotes.py引用の途中を省くときは、… でつないだ断片ごとに照合されます。「不一致」と出た引用は、次のどちらかです。Claudeが文言を整えてしまったか、IDを取り違えたかです。出力を貼って、文字起こしの原文に直させます。
check_quotes.py が次を不一致と出した。
不一致: S003 再問い合わせは体感で減った
S003の原文を引いて、引用を原文どおりに直すか、
「」を外して言い換えとして書き直して。このスクリプトが保証するのは、文字が文字起こしの発言に含まれていることだけです。文脈を切り取って意味が変わる引用や、そもそも文字起こしが聞き間違えている場合は、機械では見つかりません。次の確認リストが、その穴を受け持ちます。
手順5: 登壇者に確認を取る箇所を抜き出す
登壇者に記事全体を送って「ご確認ください」と頼むと、長くて読まれず、返事も「問題ありません」の一言になりがちです。確認してほしい箇所だけを、理由つきで抜き出すほうが、返答が具体的になります。
下書き全体から、登壇者に確認を取る箇所を抜き出して表にして。
列: 登壇者 / 本文の箇所 / 元の発言ID / 確認する理由 / 確認の聞き方
理由は次のいずれかから選ぶ。
直接引用 / 数字を含む / 固有名詞を含む / 留保を要約で弱めた可能性
社内事情・未公開情報に触れる / 質疑応答で他者に言及している
表にない箇所は、確認不要と判断した理由を最後に1行で書く。出てきた表は、そのまま登壇者に送る文面にはしません。登壇者ごとに、その人の発言に関わる行だけを残し、依頼メールに貼ります。「確認の聞き方」の列は、「この数字は〇〇の意味で合っていますか」「この引用は公開してよいですか」のように、はい・いいえで答えられる形にしておくと、返信が早くなります。
登壇者が複数いるセミナーでは、他の登壇者の発言を引用する箇所を、どちらに確認するかも決めておきます。基本は発言者本人です。ただし、司会者が登壇者の発言を要約して紹介した部分は、司会者の言葉として書かれているため、確認先を登壇者本人に切り替える必要があります。この判断はClaudeに任せず、人が決めます。
参加者と公開範囲で、あらかじめ決めておくこと
質疑応答には、登壇者ではない人の発言が入ります。録画・文字起こしの利用や、参加者の発言を記事にする扱いは、セミナーの案内文や申込時の同意で決まっているはずなので、レポートを書く前にその文面を確認します。文字起こしには参加者の氏名や所属が残っていることもあります。
- 参加者の発言は、原則として要約にとどめ、「」で引用しない
- 氏名・所属は、記事に出さない前提で話者を「参加者」に置き換えてから渡す
- 非公開セッションやオフレコ部分は、台帳の段階で「対象外」にする
法的な可否の判断は、Claudeに頼まず、主催側の担当者か専門家に確認します。Claudeに任せられるのは、「この発言は参加者の発言か」「氏名が含まれているか」といった、文字起こし上の見分けまでです。
チームで下書きを回すときの設定
TeamまたはEnterpriseプランでは、プロジェクトを組織内の人と共有できます。権限は「Can view」と「Can edit」の2種類です。広報担当が下書きを作り、事業部の担当者に内容をチェックしてもらう場合は、チェックする側を「Can view」にすれば、プロジェクト指示やナレッジを書き換えられる心配がありません。
プロジェクトの作成時、公開範囲として「非公開(招待した人のみ)」か「組織全体」を選べます。登壇者の未公開情報を含む文字起こしを置くなら、非公開にして必要な人だけを招待します。後から公開範囲を変えることもできます。なお、管理者がプロジェクト共有をオフにしている組織では、共有そのものが使えません。
つまずきやすい点
落とし穴
引用が「ほぼ合っている」まま通る
Claudeは話し言葉を読みやすく整えようとして、「えー」や言い直しを落とし、助詞を直してしまうことがあります。意味は同じでも、直接引用としては原文と違います。手順4のスクリプトで落とせますが、プロジェクト指示にも「『』の中は文字起こしのまま」と書いておくと、不一致の件数が減ります。
- スライドの内容が文字起こしにない: 登壇者が「こちらの数字を見てください」と話した箇所は、数字そのものが音声に出ていません。スライドをPDFで渡し、数字は資料の記載と照らして書かせます。画像だけのスライドは、PDFなら100ページ以下で視覚要素も読まれます。
- 話者の取り違え: 自動文字起こしの話者ラベルは、取り違えている場合があります。登壇者が2人以上いるときは、台帳の話者列を録画で数か所サンプル確認します。
- 質疑応答の回答を単独で引用する: 回答は質問を前提にしています。質問を省くと意味が変わる場合は、質問側を要約として併記します。
まとめ
セミナーレポートで守るのは、登壇者の言葉を登壇者のまま届けることです。Claudeに任せるのは、台帳の仕分け、構成案、本文の下書き、確認リストの抜き出しまで。引用が原文にあるかの照合は手元のスクリプトで行い、数字と留保の意味の確認は登壇者本人に戻します。
最初の1回は、30分程度の区間1つだけで一周してみてください。台帳の分類がずれる箇所と、スクリプトが落とす引用のパターンがつかめれば、プロジェクト指示に足すべき一文が見えてきます。開催前後のフォローメールや台本まで一続きに作る場合は、ウェビナーの告知・台本・事後フォローが先の工程になります。動画に載せるチャプターを同じ文字起こしから作る手順はYouTubeのチャプターと概要欄にあります。