長い資料を全部貼って「さあ読め」でうまくいくと思っているなら、そこがまずズレている。Claude Code は長文を処理できるが、だからといって一気読みさせるのが正解ではない。むしろ章ごとに渡したほうが、分割投入もしやすいし、章単位で扱うほうが手戻りも減る。
筆者は最初、仕様書や長い手順書を丸ごと投げて、あとから「この章の前提は無視して」とか「さっきの表だけ見て」と言い直して、かなり無駄を出した。大きい資料ほど、最初のひと押しを雑にすると全体がだるくなる。Claude Code にも、人間にもだ。
やることは単純だ。資料をいきなり全文で渡さず、章や節ごとに区切る。最初に全体像だけ渡して、そのあと必要な章を順番に扱う。これで指示の焦点がぶれにくくなる。
たとえば、次のような資料があるとする。
この手のものは、最初から全文を相手に食わせるより、目次や章立てを先に見せたほうがいい。Claude Code は、その場で全体構造をつかんでから作業したほうが強い。
依頼文は、こんなふうに切る。
この資料は長いので、章ごとに扱ってください。
まず全体の目次だけ確認し、そのあとで第1章から順に要約していってください。
各章の要約は、重要点、注意点、未解決点の3つに分けてください。
一度に全文の処理はしないでください。
これだけでも、だいぶ違う。全文を前提にした雑な返しが減る。
一番使いやすいのは、先に「全体の地図」を渡してから、章ごとに本体を渡すやり方だ。長い資料の扱いでは、地図なしで山登りを始めるようなものがいちばん危ない。
こう進める。
この資料は次の章でできています。
1. 背景
2. 現状整理
3. 提案内容
4. 実施手順
5. 付録
まずは各章の役割を整理してください。本文はまだ要約しなくていいです。
そのあとで、章ごとにこう渡す。
第2章「現状整理」を貼ります。
この章だけを読んで、次を出してください。
- 要点3つ
- 数字や固有名詞
- 他章に持ち越すべき論点
第3章「提案内容」を貼ります。
この章の変更点だけに注目して、前章との差分がわかる形でまとめてください。
このやり方のいいところは、Claude Code の出力が安定することだ。章ごとに役割が決まっているので、要約なのか、抽出なのか、比較なのかがぶれにくい。指示が軽くなるぶん、返ってくる答えも締まる。
資料がすでにファイル分割されているなら、それをそのまま使えばいい。Claude Code には、対象ファイルを明示して読ませるほうが扱いやすい。逆に、複数ファイルを混ぜて一気に説明すると、どこからどこまでが一章なのかが曖昧になる。
たとえば、こういう依頼は素直だ。
docs/01-background.md から docs/05-appendix.md までを、章ごとに順番に要約してください。
各ファイルは独立した章として扱ってください。
全文を一度に要約するのではなく、1ファイルずつ進めてください。
ファイル名に章の意味が乗っているなら、そこを使わない手はない。人間が見ても分かる区切りは、そのまま Claude Code にも効く。
フォルダ整理や文書整理で使うなら、このやり方はかなり便利だ。たとえば請求書、見積書、社内メモ、議事録が混ざったフォルダでも、種類ごとに分けて渡せば、要約も抽出もかなり楽になる。
長文の問題は、単純に長いことではない。章ごとに前提が変わることだ。前半のルールが後半では無効になる、登場人物が変わる、対象期間が違う、こんなことは普通にある。全文をまとめて扱うと、この切り替えが雑になりやすい。
筆者が手戻りしたのもここだ。長い手順書を丸ごと読ませて、「この条件で再実行して」と頼んだら、前半の古い条件を引きずった返答が混ざった。あとで章を分けて渡し直したら、かなりマシになった。資料の中でルールが変わるなら、なおさら分割投入がいる。
だから、次のような指示が効く。
この資料は途中で前提が変わります。
第1章から第2章まではAルール、第3章以降はBルールです。
章ごとに前提を切り替えながら処理してください。
これを最初に言っておくと、Claude Code が勝手に一本化してしまう事故を減らせる。
すべての資料がきれいに章立てされているわけではない。議事録やメモは特にそうだ。話題が飛ぶし、見出しもない。こういうときに全文をぶつけると、必要なところまで流れてしまう。
ここでは、先に人間側でざっくり区切るのが正解だ。
このメモは3つの話題に分かれています。
1. ファイル命名
2. 重複ファイルの削除
3. 共有フォルダの運用
まず1だけを処理してください。終わったら次に進みます。
この程度の区切りでいい。完璧な章分けを作る必要はない。大事なのは、Claude Code に「今はどこを見るべきか」をはっきり渡すことだ。
逆にやりがちなのが、章ごとに渡したつもりで、毎回「最初から全部読んで」と付け足すやり方だ。これをやると、せっかくの分割が消える。分けた意味がない。
長い資料を一度に扱うと、修正指示が巨大になる。どの部分を直したいのか、こちらも説明しづらい。章単位なら、修正点が小さくなる。
たとえば、こんな流れだ。
第2章だけ見て、誤字と数字の不整合を洗ってください。
第2章の要約は良いですが、重要点の順番を「背景 → 問題 → 対応」に変えてください。
第4章だけ、手順を箇条書きに直してください。
こうすると、毎回全部をやり直さなくて済む。長い資料を相手にするときほど、修正対象を小さくするのが効く。これは文書作成でもファイル整理でも同じだ。
このやり方は、コードレビューだけの話ではない。むしろ非エンジニアのほうが恩恵を受けやすい。
たとえば、長い社内文書を読みやすく直したいときは、前文、本文、付録を別々に渡す。フォルダ整理なら、年度ごと、案件ごと、種類ごとに分ける。ディスク削減なら、まず大きなカテゴリごとに重複候補を見て、そのあと細部を確認する。全部を一気にやろうとすると、確認漏れが出る。
依頼の言い方も、そのままでいい。
このフォルダ内のファイルを、種類ごとに章のように扱ってください。
まず画像、次にPDF、最後に古い圧縮ファイルという順で確認してください。
一度に全部を判断せず、カテゴリごとに進めてください。
章という言葉は、文書だけの話ではない。まとまりを切るための考え方だ。Claude Code に何かを頼むとき、この切り方があるだけで、だいぶ事故が減る。
長い資料ほど、気合で押し切るより、区切って渡すほうが強い。全文を一発で読ませるのは、派手だが雑になりやすい。章ごとに渡して、必要なら次の章へ進める。これだけで、返答の精度も修正のしやすさも変わる。資料が長くなるほど、この基本が効いてくる。