1時間の会議の文字起こしを、まるごとAIに貼って「議事録にして」と頼む。よくやる手ですが、終盤に決まった数字がスッと抜けることがあります。そこで同じ文字起こし（13,066字・要点24個）を、一括で投げる方法と、チャンクに割って部分要約してから統合する方法の両方で要約させ、どちらが何個取りこぼすかを実測しました。要約はClaude Haiku 4.5に、正解を見せないブラインドで処理させています。結果と、コピペで動くスクリプトを置きます。
結論：長いほど「割って→部分要約→統合」が漏れにくい。ただし1時間くらいなら一括でもほぼ足りる
先に答えです。同じ会議ログで比べると、一括要約は要点24個中23個（95.8%）、チャンク分割（map-reduce）は24個すべて（100%）を拾いました。差は1個だけ。正直、もっと差がつくと思っていたので肩透かしでした。
つまり、1時間ぶん（1.3万字くらい）の文字起こしなら、現行の安いモデルに一括で投げても9割5分は拾えます。コストも1回で数円。取りこぼしを1個も許したくない、あるいは会議がもっと長い——そういうときに、コストを払ってチャンク分割に切り替える。この線引きが、今回の実測で見えてきたことです。
なぜ一括だと終盤が抜けるのか
長文をまとめて投げると要点が薄まる理由は、ざっくり2つあります。
ひとつは、入れられる量と、ちゃんと使える量が違うこと。Anthropicの公式ドキュメントは、トークン数が増えるほど精度とリコール（拾い切る力）が落ちる現象を「context rot」と名前を付けて説明しています。コンテキストウィンドウが広い（Opus 4.8やSonnet 4.6は100万トークン）からといって、全部入れれば良いわけではない、という立場です。
もうひとつは、出力の長さに上限があること。長い入力を短い議事録に圧縮する以上、どこかを削るしかありません。経験的には、まとめの後ろのほうにある細かい数字が削られやすい。
関連して「lost in the middle」という研究があります。長い文脈では、関連情報が先頭か末尾にあると拾いやすく、真ん中に埋もれると大きく取りこぼす、という報告です（Liu ほか, 2023）。ただしこの研究の主な題材は質問応答や検索で、要約そのものではありません。なので「中盤が抜けるはず」という当たりを付けつつ、自分のデータで確かめました。
検証：同じ1時間ぶんの文字起こしで「一括」と「チャンク集約」を回す
題材は、要点を前半・中盤・後半に8個ずつ埋めた会議ログ
本物の会議の文字起こしは公開できないので、合成の社内定例を1本作りました。司会＋参加者4名、雑談や脱線、「さっきの件ですが」みたいな前方参照ありの、いかにもありそうなやつです。長さは13,066字（1時間相当）。
その中に、採点用の「要点」を24個仕込みました。内訳は決定事項8・ToDo（担当と期限つき）7・重要な数値9。位置は前半に8個、中盤に8個、後半に8個と均等に置いています。要点は箇条書きで目立たせず、発話の中に自然に埋めました。実際の文字起こしと同じ「埋もれた」状態にするためです。
さらにフェアにするため、「次回テーマにしよう」「いったん検討メモで」のように決まっていない話題や、ダミーの数字もノイズとして混ぜています。決まっていないことを決定事項に書いてしまわないか、も見たかったからです。
要約の指示は両方式でまったく同じにしました。
次の会議文字起こしから議事録を作って。出力は「決定事項」「ToDo（担当・期限つき）」「重要な数値」の3見出しの箇条書き。簡潔に、要点のみ。
大事なのは、要約する側に正解リストを見せないことです。正解を知っている人がまとめると、無意識にそこを拾ってしまう。なので要約は、正解を一切渡していないまっさらなサブエージェント（Claude Haiku 4.5）にブラインドでやらせています。一括は1回、チャンクは部分要約5回＋統合1回。要点リストは渡していません。
チャンク分割の中身（境界・オーバーラップ・統合）
やっていることは map-reduce です。長文を一定の文字数で区切り（map で各チャンクを部分要約）、最後に部分要約をまとめて1本の議事録にする（reduce で統合）。今回は5チャンク・各2,600〜2,800字・境界で200字オーバーラップさせました。オーバーラップは、区切り目で発言が分断されて文脈が切れるのを防ぐ保険です。
実際に使ったスクリプトの核を、そのまま動く形で置きます。pip install anthropic して、APIキーを環境変数に入れれば、自分の文字起こしに使えます。
import os, sys
from anthropic import Anthropic
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
MODEL = "claude-haiku-4-5"
PROMPT = ("次の会議文字起こしから議事録を作って。出力は"
"「決定事項」「ToDo（担当・期限つき）」「重要な数値」の"
"3見出しの箇条書き。簡潔に、要点のみ。nn")
def summarize(text):
msg = client.messages.create(
model=MODEL, max_tokens=2000,
messages=[{"role": "user", "content": PROMPT + text}],
)
return msg.content[0].text
def chunk(text, size=2800, overlap=200):
out, i = [], 0
while i < len(text):
out.append(text[i:i + size])
i += size - overlap
return out
def map_reduce(text):
parts = [summarize(c) for c in chunk(text)] # map
joined = "nn---nn".join(parts)
reduce_prompt = ("以下は会議の各パートの議事録です。"
"重複を除き、3見出し（決定事項／ToDo／重要な数値）に統合して。nn")
msg = client.messages.create(
model=MODEL, max_tokens=2000,
messages=[{"role": "user", "content": reduce_prompt + joined}],
)
return msg.content[0].text
if __name__ == "__main__":
text = open(sys.argv[1], encoding="utf-8").read()
print(map_reduce(text))
一括で投げたいだけなら、summarize(text) に全文を渡すだけです。比較はこの2つを同じ文字起こしに当てるだけで再現できます。
実測：網羅率・取りこぼしの「位置」・トークンコスト
まず全体の成績です。
| 方式 | 網羅率 | 取りこぼし | 呼び出し | 推定コスト |
|---|---|---|---|---|
| 一括（stuff） | 95.8%（23/24） | 1個 | 1回 | 約2.44円 |
| チャンク（map-reduce） | 100%（24/24） | 0個 | 6回 | 約5.18円 |
次が今回いちばん見たかった、取りこぼしの「位置」です。
| 位置 | 一括 | チャンク |
|---|---|---|
| 前半 | 100%（8/8） | 100%（8/8） |
| 中盤 | 100%（8/8） | 100%（8/8） |
| 後半 | 87.5%（7/8） | 100%（8/8） |
ここが面白いところでした。事前の予想は「中盤が抜ける（lost in the middle）」。でも実際に落ちたのは後半です。前半と中盤は一括でも完璧に拾えていて、こぼれたのは後半の1個だけ。今回のモデルと長さでは、真ん中が消えるより、出力を絞る側の終盤が圧縮された、という結果でした。
消えたのは具体的にこれです。一括要約の「重要な数値」リストはこう終わっていました。
…・サーバー費用：月額38万円（前月比12%増）
・四半期売上目標：4800万円（現在進捗6割）
会議の終盤で出た「夏キャンペーンの想定リーチ：5万人」が、まるごと抜けています。一括の出力本文に「キャンペーン」も「5万」も「リーチ」も一度も出てきませんでした。これは採点の取りこぼしではなく、本当に消えていました。一方チャンク版は、後半を担当したチャンクが独立して要約するので、最後の行にちゃんと「夏キャンペーンの想定リーチ：5万人（SNS広告中心）」が残っていました。
コストの内訳も見ておきます。チャンク方式は一括の約2.1倍、呼び出し回数は6倍でした。増える主因は入力の再送です。各チャンクを送り、最後に部分要約をもう一度送る。長く・チャンクが増えるほど、この差は開きます。網羅率を4.2ポイント上げるのに、コスト約2.1倍・呼び出し6倍。これが今回の交換レートでした。
なお、トークン数はAPIの実測値ではなく字数ベースの概算です（日本語1字をおよそ0.9トークンと仮定、Haiku 4.5の単価で計算、1ドル160円換算）。本番のコストを正確に出すなら、レスポンスの usage を見てください。
正直な弱点：チャンクは「決まってないこと」まで拾いやすい
チャンク方式は網羅では勝ちますが、ただ得をするわけではありません。実は精度の面で気になる差が出ました。
両方式とも、本文で「次回テーマにしよう」「今日決めることじゃない」と明確に保留された話題を、決定事項に混ぜていました。誤って拾うほうのミスです。そして項目数を見ると、決定事項は一括8件に対しチャンク17件。チャンクのほうが拾う量が多い分、こうしたノイズも増えていました。「懇親会の時間を早める」「会議室のケーブル配置を改善」みたいな、決定でも何でもないものまで決定事項に並んでいた、という具合です。
網羅性を上げると、いらないものも一緒に増える。これは取りこぼし（リコール）と取り違え（精度）のトレードオフで、どちらの方式でも出てきます。だから議事録は鵜呑みにせず、特に金額と期限は元の発言で裏取りする。この一手間は外せません。
どちらを選ぶか：長さ別の早見表
| 文字起こしの長さ | おすすめ | 理由 |
|---|---|---|
| 〜1万字（30分程度） | 一括 | ほぼ取りこぼさない。1回数円で速い |
| 1〜2万字（1時間程度） | まず一括、終盤が大事ならチャンク | 今回は一括95.8%。後半の数字を落としたくないならチャンク |
| 2万字〜（長尺・複数会議） | チャンク（map-reduce） | 後半の取りこぼしが消える。コスト増は許容範囲のことが多い |
もうひとつ、お金をかけずに効く保険があります。会議の最後に「今日の決定とToDoを口頭で復唱する」こと。終盤にもう一度同じ要点が出てくれば、AIにも人間にも残りやすい。今回こぼれたのも、まさに一度しか出てこなかった終盤の数字でした。
この「一括処理を同じデータで実測して正直に書く」やり方は、これまでもやってきました。たとえば顧客リストの名寄せをClaude APIで実測した記事や、請求書を画像認識でCSV化して精度を測った記事も、同じ温度で数字を出しています。あわせて業務効率化実践のカテゴリも覗いてみると、近い温度で数字を出しています。
実運用：議事録テンプレに流し込む
仕上げのコツを少しだけ。出力フォーマットを「決定事項／ToDo（担当・期限）／重要な数値」の3見出しに固定しておくと、そのままNotionやスプレッドシートのテンプレに貼り込めます。reduceの統合プロンプトで「重複を除く」と明示しておくと、チャンクをまたいで同じ話が二重に出るのをだいぶ抑えられました。
担当と期限が入ったToDoは、そのままタスク管理に転記できる形にしておくと後がラクです。あとは決定事項と数字だけ、人が元発言で確認する。全文を読み直すより、ここだけ見ればいいので、確認も短く済みます。
まとめ
- 1時間（1.3万字）の文字起こしなら、安いモデルへの一括投入でも要点の95.8%を拾えた。まず一括で試して問題ない
- こぼれたのは中盤ではなく後半の1個（終盤に出た数字）。「末尾が圧縮されやすい」ほうに注意
- チャンク分割（map-reduce）は100%まで上がるが、コスト約2.1倍・呼び出し6倍。長尺や、取りこぼし厳禁の場面で使う
- チャンクは網羅と引き換えに、決まっていないことまで拾いやすい。金額と期限は元発言で裏取りする
- 会議の最後に決定とToDoを口頭で復唱するだけでも、取りこぼしの保険になる
長い文字起こしの要約を社内の仕組みに組み込みたい、自分の業務に合わせてチューニングしたい——そんなときは、業務効率化の導入支援もやっています。30分の無料相談から始められます。 → サービス詳細
