TL;DR
生成AIによる要約は便利ですが、単純な「全文を渡して短くして」では、実務上の判断材料を落とします。
特に失われやすいのは、次の4種類です。
- 原文に明示されていない前提条件
- 結論を限定する例外・留保・適用範囲
- 文書内の矛盾、曖昧さ、未解決事項
- 要約者が「重要ではない」と判断した情報
この記事では、これらをまとめて 行間損失 と呼びます。
行間損失をゼロにはできません。しかし、要約を1本の短文として生成するのではなく、要約・根拠・欠落候補・矛盾・未解決事項を分離して出力し、レビュー可能な形で保持すれば、実務リスクは下げられます。
本稿の結論は単純です。
要約を最終成果物にしない。要約を、原文へ戻るための索引として設計する。
はじめに：シビュラシステムは「人間を要約しすぎた社会」と読める
『PSYCHO-PASS サイコパス』の公式紹介では、シビュラシステムは「人間のあらゆる心理状態を数値化し管理する巨大監視ネットワーク」と説明されています。作中では、人間の複雑な内面が、社会運用に使える数値へ変換されます。
もちろん、業務文書の要約と、人間の心理を数値で判定する架空の管理社会は同じものではありません。
それでも、情報システム設計として見ると共通点があります。
- 入力は複雑である
- 処理コストを下げるために圧縮する
- 圧縮結果を、意思決定に使う
- 圧縮時に捨てた情報は、画面上から見えなくなる
- その後の利用者は、捨てられた情報の存在すら意識しにくい
槙島聖護という存在を批評軸に置くと、問いはこう変わります。
要約結果は便利か。
ではなく、
何を捨てた結果として、この便利さが成立しているのか。
です。
この記事では、この問いをLLM要約の設計へ落とし込みます。
注意：本稿は作品を題材にした技術的な批評・設計論です。槙島聖護の行動や倫理観を肯定するものではありません。
1. 要約とは何か：圧縮ではなく、選択である
要約を単なる文字数削減として扱うと、設計を誤ります。
要約処理には、少なくとも次の3工程があります。
- 文書中の情報単位を抽出する
- 重要度を推定する
- 残す情報と捨てる情報を選ぶ
数式のように書けば、要約は次の関数として表現できます。
summary = compress(source, objective, audience, constraints)
同じ原文でも、目的と読者が変われば要約は変わります。
たとえば、障害報告書を要約するとします。
- 経営層向け：影響範囲、復旧時刻、再発防止策
- 運用担当向け：検知経路、一次切り分け、暫定対応
- 開発者向け：原因コード、再現条件、修正差分
- 監査向け：承認経路、証跡、未完了事項
どれも間違いではありません。しかし、いずれも完全ではありません。
要約は必ず、特定の観点を強調し、別の観点を後景化します。
この事実を隠したまま「AIが文書を理解して短くした」と考えると、要約結果が過剰に権威化します。
2. 行間を技術用語として定義する
文学的な意味の「行間」は、明示されていない感情や含意を指します。
実務システムで扱うには、もう少し分解したほうが使いやすいです。
本稿では、行間を次のように定義します。
行間 = 意思決定に影響し得るが、通常の要約結果から脱落しやすい情報
具体的には、次の6分類です。
| 分類 | 内容 | 例 |
|---|---|---|
| 前提 | 結論が成立する条件 | 「現行バージョンに限る」「国内拠点のみ」 |
| 留保 | 断定を弱める情報 | 「現時点では」「暫定的に」「追加調査が必要」 |
| 例外 | 通常ルールが適用されない条件 | 特定顧客、旧データ、移行期間 |
| 矛盾 | 文書内で整合しない情報 | 本文と付録で件数が異なる |
| 不在 | 書かれていないが確認が必要な事項 | 責任者、期限、根拠、影響範囲 |
| 温度差 | 言葉遣いから推測できる優先度や迷い | 「必須」と「推奨」、「決定」と「検討」 |
ここで大事なのは、LLMに行間を自由に推測させないことです。
推測を許しすぎると、行間の検出ではなく、もっともらしい補完になります。
したがって、出力は次の3種類に分離します。
- Fact：原文に明示されている
- Inference：原文から推測できるが、明示されていない
- Unknown：原文だけでは判断できない
この区別を保持するだけでも、要約の実務品質はかなり変わります。
3. なぜ「全文を一度に渡して要約」では危険なのか
3.1 長文コンテキストは、入れば読めるわけではない
長いコンテキストを処理できるモデルでも、入力中の情報を均等に利用できるとは限りません。
Liuらの研究「Lost in the Middle」では、関連情報の位置を変えるとモデル性能が大きく低下する場合があり、入力の先頭や末尾にある情報は拾いやすい一方、長い文脈の中央にある情報は拾いにくくなる傾向が報告されています。
これは実務文書で問題になります。
- 冒頭：概要
- 中盤：重要な例外条件
- 末尾：結論
という文書を一括要約すると、中盤の例外条件だけが消える可能性があります。
「コンテキストウィンドウ内に収まった」ことと、「必要な情報が評価された」ことは別です。
3.2 流暢さと正しさは別物である
要約文が読みやすいことは重要です。しかし、読みやすさは事実整合性を保証しません。
ROUGEは古典的で有用な要約評価指標ですが、KryścińskiらのFactCC論文は、一般的な要約評価指標が原文との事実整合性を十分に扱わない問題を指摘しました。
WangらのQAGSも、抽象型要約の実用を制限する要因として、入力と整合しない事実が頻繁に現れる点を挙げています。
つまり、読み手が最も警戒すべき要約は、読みにくい要約ではありません。
滑らかで、短くて、もっともらしいが、判断材料を静かに落としている要約です。
3.3 要約は「事実」だけでなく「優先順位」を固定する
要約では、何を残すかが決まります。
その瞬間、原文の複数の読み方は、ひとつの読み方へ狭まります。
たとえば次の2文は、同じ状況を異なる方向へ固定します。
A: 障害は復旧済みであり、影響は限定的だった。
B: 復旧は完了したが、影響範囲の確定と再発防止策の検証は継続中である。
Aは報告を閉じる文章です。
Bは次の行動を開く文章です。
この差は単なる文体ではありません。
要約が、その後の組織行動を変えるということです。
4. 設計方針：要約を1本の文章として保存しない
実務向けの要約は、文章ではなく、レビュー可能な構造体として扱います。
最低限、次の情報を分けて保持します。
{
"executive_summary": "意思決定者向けの短い要約",
"facts": [
{
"claim": "原文に明示された事実",
"evidence": {
"document_id": "DOC-001",
"section": "3.2",
"quote": "根拠となる短い抜粋"
}
}
],
"inferences": [
{
"statement": "原文から推測されるが断定できない事項",
"reason": "推測理由",
"confidence": "low | medium | high"
}
],
"omission_risks": [
{
"category": "前提 | 留保 | 例外 | 矛盾 | 不在 | 温度差",
"description": "短縮時に失われると危険な情報",
"source_location": "section or page"
}
],
"contradictions": [
{
"left": "記述A",
"right": "記述B",
"status": "unresolved"
}
],
"open_questions": [
"原文だけでは判断できないため、人間が確認すべき問い"
],
"read_original_first": [
"要約だけで判断せず、原文確認を優先すべき箇所"
]
}
この設計のポイントは、要約文を賢くすることではありません。
要約文の外側に、要約が捨てたものを置く場所を作ることです。
5. 推奨アーキテクチャ：行間を失わない要約パイプライン
5.1 全体像
単純な一括要約との違いは、次の3点です。
- 文書をオーバーラップ付きで分割する
- 要約と同時に、根拠・例外・矛盾を別系統で抽出する
- 最後に、要約を肯定するレビューではなく、反証するレビューを入れる
5.2 スライディングウィンドウを使う
LiらのSliSumは、入力文書を重複するウィンドウへ分割し、ローカル要約を生成した後、クラスタリングと多数決で全体要約を作る戦略を提案しています。
実務では、論文と同一実装にする必要はありません。
重要なのは、長文を1回で要約せず、複数の視点で重複して読むことです。
from dataclasses import dataclass
from typing import Iterable
@dataclass
class Chunk:
index: int
text: str
start: int
end: int
def sliding_chunks(text: str, size: int = 4000, overlap: int = 600) -> Iterable[Chunk]:
"""文字数ベースの簡易例。実運用ではトークン数と章節境界を併用する。"""
if overlap >= size:
raise ValueError("overlap must be smaller than size")
start = 0
index = 0
while start < len(text):
end = min(start + size, len(text))
yield Chunk(index=index, text=text[start:end], start=start, end=end)
if end == len(text):
break
start = end - overlap
index += 1
分割時の注意点は次の通りです。
- 固定長だけで切らず、見出し・段落境界を優先する
- 例外事項がチャンク境界で分断されないように重複させる
- 表や箇条書きを途中で切らない
- ページ番号、章節番号、行番号を保持する
- 後段で原文へ戻れる識別子を必ず持つ
5.3 要約プロンプトと監査プロンプトを分離する
1回のプロンプトで「きれいな要約」と「厳格な監査」を同時にやらせると、出力の目的が混ざります。
役割を分けます。
ローカル要約プロンプト
あなたは業務文書の要約担当です。
入力範囲だけを使用し、事実と推測を分離してください。
出力:
1. 明示された事実
2. 条件・前提・例外
3. 数値・期限・責任主体
4. この範囲だけでは判断できない事項
5. 原文確認を推奨する箇所
禁止:
- 入力にない背景事情の補完
- 一般論による穴埋め
- 曖昧な記述の断定化
統合要約プロンプト
複数のローカル要約を統合してください。
同じ事実をまとめ、矛盾する記述は解消せずに列挙してください。
重要度を付ける際は、次の順序を優先してください。
1. 意思決定を変える情報
2. 適用範囲を限定する情報
3. 数値、期限、責任主体
4. 例外と未解決事項
5. 背景説明
最終要約と、削除したが確認価値のある情報を分けて出力してください。
反証レビュー用プロンプト
あなたは要約を承認する担当ではありません。
要約が誤読を誘発する箇所を探す監査担当です。
原文と要約を比較し、次を検出してください。
- 原文にない断定
- 主語、目的語、時制、数量の変化
- 条件、例外、留保の欠落
- 文書中央部から脱落した重要事項
- 矛盾を解消したように見せている箇所
- 読み手が追加確認すべき問い
この「反証役」を入れると、要約生成モデルが作った滑らかな物語へ、そのまま乗らずに済みます。
6. 評価設計：ROUGEだけでは足りない
6.1 評価軸を分ける
実務要約では、単一スコアにまとめないほうがよいです。
推奨する評価項目は次の通りです。
| 評価軸 | 確認内容 | 自動化の目安 |
|---|---|---|
| Readability | 短く読みやすいか | LLM、ルール |
| Coverage | 重要事項を含むか | 参照要約、チェックリスト |
| Attribution | 各主張が原文へ紐づくか | 根拠スパン抽出、QA、NLI |
| Contradiction | 原文と矛盾しないか | NLI、ルール、LLMレビュー |
| Omission Risk | 条件・例外・留保を落としていないか | ルール、LLMレビュー |
| Actionability | 誰が何を判断すべきか明確か | 人間レビュー |
6.2 既存研究から実務へ持ち込める考え方
- ROUGE：参照要約との重なりを見る代表的な指標。比較には便利だが、事実整合性の保証には使えない。
- FactCC：要約文が原文と整合するかを判定し、根拠スパンや不整合箇所の抽出を扱う。
- QAGS：要約と原文へ質問し、回答が一致するかという発想で事実整合性を評価する。
- TRUE：複数タスク・複数データセットを統合して、事実整合性評価指標を比較する枠組み。
- SummaC：文書と要約の粒度差を意識し、文単位へ分割してNLIスコアを集約する考え方。
大切なのは、どれか1つを導入して終わりにしないことです。
TRUEの研究でも、大規模NLI系と質問生成・回答系の方法が、強く補完的な結果を示したと報告されています。
実運用でも、次のように複数系統を組み合わせるのが現実的です。
ルールベース検査
+ 根拠スパン照合
+ QAベース検査
+ NLIベース検査
+ LLMによる反証レビュー
+ 高リスク文書の人間承認
7. 「行間レポート」を別出力する
通常の要約結果には、読み手が早く判断できるという価値があります。
しかし、要約へすべて詰め込むと、また長文へ戻ります。
そこで、最終出力を2層に分けます。
Layer 1：意思決定用サマリー
- 何が起きたか
- 影響は何か
- 何を決める必要があるか
- 期限はいつか
- 誰が担当するか
Layer 2：行間レポート
- この要約が成立する前提
- 省略した例外
- 解消していない矛盾
- 原文に書かれていない事項
- 推測として扱った事項
- 原文を読むべき箇所
Layer 2は、全員が毎回読む必要はありません。
ただし、存在していることが重要です。
圧縮前の複雑さへ戻れる経路があれば、要約は便利な道具になります。
戻れない場合、要約は意思決定を支援するものではなく、意思決定を代替するものへ変わります。
8. 監査ログを残す
生成AI要約を業務利用するなら、出力本文だけでなく、生成過程を観測できるようにします。
最低限、次のログを残します。
{
"request_id": "SUM-20260601-0001",
"document_id": "DOC-001",
"document_hash": "sha256:...",
"model": "model-name-or-deployment-id",
"prompt_version": "summary-pipeline-v1.3.0",
"chunk_strategy": {
"size": 4000,
"overlap": 600,
"boundary": "heading-aware"
},
"generated_at": "2026-06-01T12:00:00+09:00",
"review_status": "pending | approved | rejected",
"risk_flags": [
"missing-owner",
"scope-ambiguity",
"contradictory-count"
]
}
監査ログが必要な理由は、要約結果が後から変わり得るためです。
- 原文が更新された
- モデルが更新された
- プロンプトが更新された
- チャンク分割方法が変わった
- 利用目的が変わった
同じ文書でも、同じ要約になるとは限りません。
「要約が正しいか」だけでなく、どの条件で生成された要約かを追えるようにします。
9. NIST AI RMFの観点で見る
NISTは、生成AI固有のリスクへ対応するため、AI RMFのGenerative AI Profileを公開しています。
要約システムと特に関係が深いのは、次の観点です。
- Confabulation：自信ありげだが誤った内容
- Human-AI Configuration：自動化バイアス、過信、過度な依存
- Information Integrity：事実、意見、フィクション、不確実性が区別されにくくなる問題
要約サービスを作るとき、誤り率だけを見るのでは不十分です。
読み手が要約をどう受け取るかも設計対象です。
たとえば、次のUIは危険です。
AI要約：問題ありません。
より安全なのは、次のようなUIです。
AI要約：現時点で重大な問題は検出されていません。
未確認事項：3件
例外条件：2件
原文確認推奨：section 4.2, appendix B
人間レビュー：未承認
精度を上げるだけでなく、過信しにくい表示を作ります。
10. 導入ロードマップ
いきなり高度な評価基盤を作る必要はありません。
Level 0：単純要約
原文 → 1回のLLM要約 → 要約文
個人メモには使えますが、重要判断には弱い構成です。
Level 1：根拠付き要約
要約文 + 根拠箇所 + 原文リンク
まずここまで作る価値があります。
Level 2：行間レポート付き要約
要約文 + 根拠 + 前提 + 例外 + 矛盾 + 未解決事項
業務文書では、この水準を基準にしたいところです。
Level 3：反証レビュー付き要約
生成モデル + 監査モデル + ルール検査 + 人間承認
対外文書、契約、要件定義、障害報告、経営判断に関わる文書へ適用します。
Level 4：評価・監査基盤
データセット化 + 定期評価 + プロンプトバージョン管理 + モデル差分検証 + 監査ログ
組織運用として継続するなら、この段階が必要です。
11. ユースケース別の最低ライン
| ユースケース | 許容しやすい構成 | 必須にしたい追加対策 |
|---|---|---|
| 個人の読書メモ | Level 0〜1 | 原文リンク |
| 会議議事録 | Level 1〜2 | 決定・宿題・担当・期限の分離 |
| 要件定義 | Level 2〜3 | 例外、未決、矛盾、用語定義の抽出 |
| 障害報告 | Level 2〜3 | 時系列、影響範囲、暫定対応、恒久対応の分離 |
| 契約・規約 | Level 3以上 | 人間承認、原文優先、法務確認 |
| 人事評価 | 自動要約のみで判断しない | 根拠提示、異議申立て、人間の説明責任 |
特に、人を評価する用途では慎重さが必要です。
人間の行動履歴を短い評価文やスコアへ圧縮すると、文脈が消えます。
そして、圧縮後の評価だけが次の判断へ使われると、本人が説明できないまま評価が自己増殖します。
ここに、「人間を要約しすぎた社会」という比喩が現実味を持ちます。
12. 槙島聖護という補助線
槙島聖護というキャラクターを設計思想へ持ち込む価値は、彼を正解にすることではありません。
むしろ、システムが「社会を効率よく運用できる」という理由だけで、人間の複雑さを扱い切ったつもりになる危険を見抜く補助線として使えます。
要約システムでも同じです。
- 読みやすい
- 速い
- コストが安い
- 検索しやすい
- 比較しやすい
これらは正しい価値です。
しかし、その価値だけで設計すると、行間はノイズとして除去されます。
本当に必要なのは、ノイズをすべて残すことではありません。
何を捨てたか分からない状態を避けることです。
まとめ
LLM要約は、原文を読まなくてよい魔法ではありません。
大量の情報を扱うための索引です。
設計の要点は次の通りです。
- 要約は価値中立な短縮ではなく、情報選択である
- 行間を、前提・留保・例外・矛盾・不在・温度差へ分解する
- 長文はオーバーラップ付きで分割し、中央部の脱落リスクを下げる
- 要約と監査を分離し、反証レビューを入れる
- 要約文だけでなく、根拠・欠落候補・未解決事項を保存する
- 高リスク用途では、人間承認と監査ログを必須にする
- UIも含めて、AIへの過信を誘発しない構造にする
最後に、一文でまとめます。
シビュラシステムとは、人間を要約しすぎた社会である。だから要約システムには、原文へ戻るための扉が必要になる。
参考文献
- アニメ『PSYCHO-PASS サイコパス』シリーズ公式サイト, INTRODUCTION
https://psycho-pass.com/story/ - Nelson F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts”, TACL 2024.
https://aclanthology.org/2024.tacl-1.9/ - Taiji Li, Zhi Li, Yin Zhang, “Improving Faithfulness of Large Language Models in Summarization via Sliding Generation and Self-Consistency”, LREC-COLING 2024.
https://aclanthology.org/2024.lrec-main.771/ - Chin-Yew Lin, “ROUGE: A Package for Automatic Evaluation of Summaries”, 2004.
https://aclanthology.org/W04-1013/ - Wojciech Kryściński et al., “Evaluating the Factual Consistency of Abstractive Text Summarization”, EMNLP 2020.
https://aclanthology.org/2020.emnlp-main.750/ - Alex Wang, Kyunghyun Cho, Mike Lewis, “Asking and Answering Questions to Evaluate the Factual Consistency of Summaries”, ACL 2020.
https://aclanthology.org/2020.acl-main.450/ - Or Honovich et al., “TRUE: Re-evaluating Factual Consistency Evaluation”, NAACL 2022.
https://aclanthology.org/2022.naacl-main.287/ - Philippe Laban et al., “SummaC: Re-Visiting NLI-based Models for Inconsistency Detection in Summarization”, TACL 2022.
https://aclanthology.org/2022.tacl-1.10/ - NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile”, NIST AI 600-1, 2024.
https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf