はじめに

Claude Codeで100ページ超の技術仕様書を要約しようとしたら、途中から出力の精度がガタ落ちした——そんな経験はないでしょうか。

私自身、製造業のDX推進で大量のドキュメント処理にClaude Codeを活用していますが、長大な文書を扱うたびに「なぜか途中で前の指示を忘れる」「品質が安定しない」という壁にぶつかりました。

試行錯誤の結果、コンテキスト管理を意識するだけで、これらの問題がほぼ解消できることが分かりました。この記事では、2万〜10万文字規模のドキュメントを効率的に処理するための実践的なテクニックを紹介します。

この記事の対象読者

Claude Codeで長文ドキュメントの処理に苦戦している方
技術仕様書、契約書、マニュアルなどの要約・分析をしたい方
AIツールを業務に本格導入したい方

読むと得られること

コンテキスト超過による品質低下を防ぐ具体的な方法
分割処理のワークフロー
Sub AgentやSkillを活用した効率化のコツ

全体像：3つの基本原則

長大ドキュメント処理で押さえるべきポイントは、実はシンプルです。

原則	具体的なアクション	なぜ効くのか
70%で`/compact`	コンテキスト使用量70%で手動圧縮	95%の自動発動を待つと品質が落ちる
Sub Agentに委譲	重いファイル処理は別エージェントへ	メインのコンテキストを汚染しない
外部ファイルに保存	進捗を`.md`ファイルに書き出す	セッションをまたいでも情報が消えない

コンテキスト管理の基本

なぜコンテキスト管理が重要なのか

Claude Codeには「記憶の限界」があります。

コンテキストウィンドウ: 200Kトークン
日本語換算: 約8〜10万文字（推定）
実際に使える量: システムやツール定義で一部消費済み

この限界を超えると何が起きるかというと、途中で前の指示を忘れたり、出力品質が急激に低下したりします。特に厄介なのがLost-in-the-Middle問題で、長いコンテキストの「中間部分」が見落とされやすくなります。

使用量の目安

 0%                    50%         70%         95%        100%
 ├──────────────────────┼───────────┼───────────┼──────────┤
 │       安全領域 　　    │   注意  　 │   警告  　 │  危険　   │
 │                      │           │           │          │
 │ 　　　 普通に作業OK 　  │ 　意識する　│  /compact │　自動発動  │
 │                      │           │ 　実行推奨  │ 品質低下  │

覚えておく数字:

70% → この時点で/compactを実行
20分 → この間隔で/contextを確認

主要コマンド

コマンド	いつ使う？	何が起きる？
`/context`	20分ごと	使用量を表示
`/compact`	70%到達時	会話を要約・圧縮
`/clear`	タスク完了後	完全リセット

/compactは引数で保持したい情報を指定できます。

# 基本
/compact

# 保持したい情報を指定（推奨）
/compact 分析結果と次のアクションのみ保持

# 具体例
/compact 契約書レビューの高リスク項目リストを維持

実践：4ステップの処理フロー

長大ドキュメントは、以下の4ステップで処理すると安定します。

Step1: 構造を把握する（5分）

全部読む前に、まず優先順位を把握します。

> このPDF仕様書の目次と章構成を把握して。
> 最も重要な章を3つ特定して。

Step2: 計画を立てる（5分）

Plan Mode（Shift+Tabで切替）を使って、処理の戦略を決めます。

# Plan Modeに切り替え
> この仕様書を分析する計画を立てて。
> 処理順序と担当（メイン/Sub Agent）を決めて。

事前に全体像が見えていれば、途中で迷うことがなくなります。

Step3: 分割して処理する（20分）

ここがポイントです。コンテキスト超過を防ぐため、セッションを分割します。

# セッション1: 前半の章
> 第1-4章をサブエージェントで要約して。
> 結果をdocs/summary-1.mdに保存。

# 進捗を保存してリセット
> 現在の進捗をdocs/progress.mdに保存して
/clear

# セッション2: 後半の章
> docs/progress.mdを読んで続きを処理して。

ファイルに保存しておけば、何日かかっても続きから再開できます。

Step4: 統合して検証する（10分）

最後に結果を統合し、ファクトチェックを行います。

> docs/summary-*.md を統合して、A4 1枚のエグゼクティブサマリーを作成して。
> 数値と固有名詞が正確か確認して。

ユースケース別クイックガイド

技術仕様書を要約したい（100ページ以上）

ゴール: 経営層向けエグゼクティブサマリー（A4 1枚）

上記の4ステップをそのまま適用します。ポイントは「サブエージェントへの委譲」と「外部ファイルへの保存」です。

契約書をレビューしたい

ゴール: リスク項目の洗い出しと修正案の提示

Step1: リスクを抽出する

> この契約書をレビューして、リスクの高い条項を抽出して。
> 優先度（高/中/低）をつけて。

チェック観点は以下の3点に絞ると効率的です。

観点	なぜ重要？
責任制限条項	上限がないと際限なく損害賠償を請求される
契約解除条件	一方的に解除されると事業が止まる
知的財産権の帰属	曖昧だと後で揉める

Step2: 高リスク条項を詳細分析

> 高リスクと判定された条項について：
> - 問題点を具体的に説明
> - 修正案を提示
> - 交渉時の落としどころを提案

Step3: レポート化

> 分析結果をWord文書（docx）でレポート化して。
> 経営層が判断できる形式で。

マニュアルを校閲したい

ゴール: 誤字脱字・表現の統一・手順の漏れを修正

# Step1: 構成チェック
> このマニュアルの構成を分析して。
> 不足している章や冗長な部分を特定して。

# Step2: 校閲実行
> 以下の観点で校閲して：
> - 誤字脱字
> - 表現の統一性（「行う」と「実施する」の混在など）
> - 手順の漏れ
> - 専門用語の正確性

# Step3: 修正反映
> 修正箇所をTracked Changes（変更履歴）で反映したdocxを作成して。

変更履歴があれば、上司の承認も得やすくなります。

ファクトチェックをしたい

ゴール: 数値・引用・固有名詞の正確性を検証

# Step1: 検証対象を抽出
> この文書から検証が必要な事実を抽出して：
> - 具体的な数値（金額、割合、件数）
> - 日付
> - 固有名詞（人名、企業名、製品名）
> - 引用・出典

# Step2: Web検索で検証
> 抽出した事実をWeb検索で検証して。
> 検証結果と出典URLを記録して。

# Step3: 報告書を作成
> 検証結果を一覧表にして。
> 誤りがあれば正しい情報と出典を付記して。

出力イメージ:

項目	原文	検証結果	正しい値	出典
売上高	30%増	⚠ 未確認	-	出典なし
発売日	2024年3月	✅ 正確	-	公式サイト
CEO名	山田太郎	❌ 誤り	鈴木一郎	IR資料

Sub Agentで負荷を分散する

Sub Agentを使うと、メインのコンテキストを消費せずに重い処理を実行できます。

使い方:

# 明示的に呼び出す
> サブエージェントを使って、この200ページのPDFを要約して

# 並列処理
> 以下の3ファイルをそれぞれサブエージェントで分析して：
> - doc-a.pdf
> - doc-b.pdf
> - doc-c.pdf

トラブルシューティング

「応答が途切れる」「品質が急に落ちた」

原因: コンテキスト超過

# 1. 状態確認
/context

# 2. 重要情報を退避
> 現在の分析結果をdocs/checkpoint.mdに保存して

# 3. 圧縮またはクリア
/compact 分析結果と次のステップのみ保持
# または
/clear

「前に言ったことを忘れている」

原因: Lost-in-the-Middle問題

対処:

重要な指示は「最初」か「最後」に置く
長い文書は分割して処理
定期的に/compactで整理

「Sub Agentが動かない」

# 明示的に指示
> doc-analyzerサブエージェントを「必ず」使って分析して

「処理が遅い」

チャンクサイズを小さくする
出力を簡潔に指示（「3点に絞って」「A4 1枚で」）
不要なMCPサーバーを無効化（/mcpで確認）

設定テンプレート集

ディレクトリ構成

project-root/
├── .claude/
│   ├── agents/           # カスタムSub Agent
│   │   └── doc-analyzer.md
│   ├── skills/           # カスタムSkill
│   │   └── contract-review/
│   │       └── SKILL.md
│   └── settings.json
├── CLAUDE.md             # プロジェクト設定
└── docs/
    └── progress.md       # 作業ログ

CLAUDE.md テンプレート

# プロジェクト: ドキュメント処理

## 処理対象
- 技術仕様書、契約書、マニュアル

## 出力ルール
- 要約は元の10%以下
- 数値には出典を付記
- 不明点は「要確認」と明記

## 禁止事項
- 推測で数値を記載しない
- 出典のない主張をしない

## 参照
- 契約書チェックリスト → docs/contract-checklist.md

カスタムSub Agent テンプレート

.claude/agents/doc-analyzer.md:

---
name: doc-analyzer
description: 長大ドキュメントの分析専門。技術仕様書、契約書、マニュアルの要約・抽出に使用。
tools: Read, Grep, Glob, Bash
model: sonnet
---

あなたは文書分析の専門家です。

## 処理手順
1. 文書の構造を把握（目次、章立て）
2. 重要セクションを特定
3. 要約を作成（元の10%以下）
4. 重要ポイントを抽出

## 出力形式

### 文書概要
[1-2文で要約]

### 重要ポイント
- ポイント1
- ポイント2
- ポイント3

### 注意事項
[リスクや確認が必要な点]

settings.json テンプレート

.claude/settings.json:

{
  "model": "claude-sonnet-4-20250514",
  "permissions": {
    "allow": [
      "Read(*)",
      "Write(docs/*)",
      "Bash(pdftotext *)",
      "Bash(pandoc *)"
    ],
    "deny": [
      "Bash(rm -rf *)"
    ]
  }
}

まとめ

長大ドキュメント処理のポイントを振り返ります。

やること	コマンド/アクション	タイミング
コンテキスト確認	`/context`	20分ごと
手動圧縮	`/compact`	70%到達時
進捗保存	外部ファイルに書き出し	セッション終了前
重い処理の委譲	Sub Agent指定	大きいファイル処理時

正直なところ、最初は「こんな細かいことを気にしないといけないのか」と面倒に感じました。でも、一度ワークフローを身につけてしまえば、手戻りが激減して結果的に楽になります。

ぜひ試してみてください。

参考資料

Context windows - Anthropic Docs
Claude Code Documentation
Liu, N. F., et al. (2024). "Lost in the Middle: How Language Models Use Long Contexts". TACL, 12, 157-173.

注記: 本記事の数値（70%閾値、チャンクサイズ等）は実践的なベストプラクティスに基づく目安値です。環境や用途によって最適値は異なる場合があります。