2026-10-06

調べた結果をその場で短く要約させて次に渡す

検索しただけで満足して、長い出力をそのまま次の作業に持ち込むと、だいたい後で詰まる。ログも、記事の下書きも、調査メモも、全部そのままだと長すぎるのだ。

Claude Code は、調べた内容をその場で短く圧縮して、次の指示に渡すのがうまい。ここでいう圧縮は、雑な要約ではない。必要な論点だけを抜き出して、次の作業で扱える密度に落とすことだ。調査メモ、検索結果の圧縮、と呼んだほうが通りがいい場面もある。

この使い方を覚えると、調べる → 読む → また調べ直す、という無駄な往復が減る。特に Claude Code では、長い出力をそのまま食わせるより、先に短く整えておいたほうが、その後の修正や比較が楽になる。

まずやることは単純だ。Claude Code に「要点だけ」「次に渡せる形で」「長文にしない」と明示する。ふわっと「まとめて」だけだと、やたら丁寧な長文が返ってきて、結局また読む羽目になる。そこがいちばん無駄だ。

たとえば、調べ物をした直後にこう頼む。

以下の調査結果を、次の作業にそのまま渡せる短いメモに圧縮して。
条件:
- 200〜400字くらい
- 事実、判断、未確認点を分ける
- 次に確認すべき点があれば最後に1行で書く
- 余計な前置きは不要

もっと実務寄りにするなら、次のように用途を指定するといい。

この検索結果を、社内共有用の調査メモにして。
条件:
- 箇条書きは3〜5個まで
- 重複は消す
- 似た話はまとめる
- 結論を先に書く
- URLは要るものだけ残す

文章作成なら、こうだ。

以下の資料を読んで、議事録の下書きに使えるように短く要約して。
条件:
- 論点ごとに1文ずつ
- 決定事項と未決事項を分ける
- 読み手が次のアクションを迷わない形にする

ファイル整理やディスク削減でも使える。たとえば、どのキャッシュや一時ファイルが邪魔なのかを調べたあと、Claude Code に「削除候補だけ」「大きい順」「手を付ける順」で圧縮させる。非エンジニアなら、長い説明を読んで納得するより、今すぐ何を消すかが見えたほうがありがたいはずだ。

以下の調査結果を、削除判断しやすい順に短く並べ直して。
条件:
- 何を消すと何が起きるかを1行ずつ
- 危険なものは先頭に「注意」と付ける
- 自信がない項目は「要確認」に入れる

この手の頼み方で効くのは、要約の目的をはっきり言うことだ。単に短くするのと、次の作業に渡すために短くするのは違う。前者は「読める短さ」、後者は「使える短さ」になる。Claude Code には後者をやらせるほうがいい。

筆者は最初、調査結果をそのまま貼って「短くして」とだけ頼んでいた。すると、短くはなるが、重要な未確認点が消えたり、逆にどうでもいい補足が残ったりして、あとで手戻りが出た。要約は短ければ勝ちではない。次の一手に必要な情報が残っていなければ、ただの圧縮ゴミだ。

だから、圧縮の基準を先に置く。たとえば次の3つはかなり効く。

何を知りたいのかを最初に書く
事実と推測を分けさせる
次の作業で使う形式を指定する

この調査結果を、次の担当者に渡す前提で整えて。
条件:
- まず結論
- 次に根拠
- 最後に未確認点
- 推測は推測だと分かるように書く
- 文章は短く、でも意味が抜けないようにする

ここで気をつけたいのは、要約に全部を詰め込ませないことだ。長文を無理に一発で短くすると、重要な差分まで潰れることがある。特に比較対象が複数あるときは、いきなり一段落にせず、先に「項目ごとに分けてから圧縮」させたほうが安定する。

まず、調査結果を論点ごとに分けて整理して。
そのあとで、各論点を2文以内に圧縮して。

この二段階のほうが、いきなり「要約して」よりずっと扱いやすい。Claude Code は指示が雑でもそれなりに動くが、調べた結果を次に渡す用途では、雑さがそのまま品質の揺れになる。

もうひとつ大事なのは、出力の長さを決めることだ。長さの目安がないと、要約は平気で伸びる。200字なのか、箇条書き5点なのか、1画面で読み切れる程度なのか。ここを曖昧にすると、次の作業に持っていけない。

以下を300字以内で要約して。
ただし、結論・理由・未確認点の3つは必ず残すこと。

要約結果をそのまま次に渡すなら、整形まで一緒にやらせるとさらに楽だ。たとえば、調査メモとして残すなら見出し付き、チャットで渡すなら短い段落、作業指示にするなら箇条書き、という具合だ。

この内容を、次の人が読んでそのまま動けるメモにして。
出力形式:
- 結論
- 根拠
- 注意点
- 次の確認

この型にしておくと、あとで自分が見返したときも迷いにくい。検索結果の圧縮は、単なる省スペースではない。次に考えるための足場づくりだ。長い情報を短くするのではなく、次の判断に必要な形へ並べ替える。そこまでやって、やっと使える。

細かいコツをひとつ足すなら、「何を削るか」も指示したほうがいい。たとえば、例示、繰り返し、一般論、長い前置きは、だいたい邪魔になる。Claude Code にそこを先回りさせると、読む側の負担がかなり減る。

以下を短く要約して。
削ってよいもの:
- 似た内容の繰り返し
- 長い前置き
- 一般論
残すもの:
- 具体名
- 数値
- 未確認点
- 次のアクション

調べた結果をその場で短く要約させるやり方は、Claude Code を「検索の先読み装置」にする使い方でもある。検索して、読んで、忘れるのではなく、検索して、要点を抜いて、次の仕事へ渡す。この流れができると、調査の疲れがかなり減る。

もし次に伸ばすなら、要約だけで終わらせず、最後に「このメモをもとに次の指示文を作って」とつなげるといい。調査メモがそのまま作業指示になると、検索と実務のあいだの無駄な一往復が消える。そこまで持っていけると、かなり気持ちいい。

関連 TIPS

同じ著者の記事

会話が長引く前に前提を 1 行で書き出す

会話がぐだるのは、相手が悪いからではない。前提を言葉にしていないからだ。 Claude Code に頼みごとをするときも同じで、いきなり「これ直して」「整理して」「要約して」と投げると、返ってくるものが妙に広がる。修正対象が曖昧なまま進むので、途中で「いや、そうじゃない」と戻す羽目になる。これは開発でも文書作成でもファイル整理でも同じだ。先に前提を 1 行で置くだけで、会話の往復がかなり減る。筆者はこれをサボって、あとから手戻りして diff が膨らんだことが何度もある。地味にだるい。ここで言う前提は、立派な仕様書ではない。現在地の明文化、前提の再確認、呼び方はいろいろあるが、要するに「今どこから始めるか」を 1 行で固定することだ。Claude Code は文脈を読んで進めるぶん、こちらが土台を曖昧にすると、広く解釈して広く返してくる。そこを最初に狭める。たとえば、文章を直したいなら、いきなり「読みやすくして」ではなく、こう書く。 ```text この原稿は、技術に詳しくない人も読む想定です。専門用語は減らし、難しい語は言い換えてください。 ``` コードを直したいなら、前提を先

papoo.work

作業の終わり方を先に決める

作業がだれる人は、始め方より終わり方が雑だ。これを決めずにClaude Codeを走らせると、修正がだらだら伸びる。diffは太り、指示はあいまいになり、最後の数回でいちばんコンテキストを食う。そこで先に「止まりどころを指定する」「出口条件を明示する」。要するに、どこで手を止めるかを先に決めておく話だ。 Claude Codeは、こちらが終点を渡すとかなり扱いやすい。逆に終点がないと、見た目は進んでいるのに、実は作業の輪郭がぼやけていく。ファイル整理でも文書作成でも同じで、「ここまでやったら終わり」を先に言うだけで、戻し作業が減る。たとえば文書なら、こんな頼み方でいい。 ```text この下書きを、3段落だけ整えてください。やることは以下に限定します。文章の重複を減らす箇条書きを2つまでにまとめる結論は変えない終わり方は「修正案を出した時点」で止めてください。追加の案は出さなくていいです。 ``` ここで大事なのは、「何をやるか」だけでなく「どこで止まるか」まで書くことだ。Claude Codeは、うっかりすると親切に広げてくる。文面を整えるつもりが、構成の組み替えまで

papoo.work

返答の長さに上限をかける

Claude Code に雑に投げて、返ってきた返答が長すぎて読む気を失う。これ、かなりありがちな失敗だ。分量を絞る、短く要約させる、そういう指定を先に入れておかないと、こちらの意図よりも「丁寧さ」が勝ってしまい、出力がだらっと伸びる。特に Claude Code は、説明を求めると親切に広げやすい。調べ物でも、文書作成でも、ファイル整理でも、返答が長いと次の判断が遅れる。だから「返答の長さに上限をかける」は、地味だが効く。要は、最初からゴールを狭く切るのだ。たとえば、要点だけほしいなら、依頼文に最初からこう入れる。 ```text 以下を300字以内で答えてください。結論を先に、細かい説明は不要です。「このフォルダ内の重複ファイルをどう扱うべきか」 ``` もう少し実務寄りなら、こうだ。 ```text 次の内容を、箇条書き3点以内で短く要約してください。各項目は1文まで。余計な前置きは不要です。 ``` 長さを制御したいときは、単に「短くして」では弱い。Claude Code はそこを雑に受け取って、まだ長い返答を返すことがある。そこで、文字数、文数、箇条書き数、段落数

papoo.work

返答の形式を先に固定する

Claude Code で地味に効くのに、みんな後回しにするのがこれだ。最初に「Markdown で返すのか、表で返すのか」を決めないまま投げると、あとで整形し直す羽目になる。内容は合っているのに、出力がバラけていてそのまま使えない。あれはかなりだるい。たとえば議事録、ファイル一覧、比較表、手順書。どれも似ているようで、欲しい形は違う。ここを曖昧にすると、Claude Code はそれなりに頑張ってしまうが、こちらの用途には微妙に噛み合わない返答を返しやすい。逆に、先に形式を固定すると、同じ材料でもぐっと使いやすくなる。Markdown か表かを決める、出力形式を指定する。たったそれだけで、手戻りが減る。いちばん簡単なのは、依頼文の最初に「出力形式」を書くことだ。Claude Code に作業を頼むとき、いきなり中身から入らない。まず箱を決める。 ```text 次の内容を、Markdown の見出しと箇条書きで返してください。表にはしないでください。対象: 契約書レビューのメモ出力したい項目: 論点、気になる表現、確認先、次にやること ``` 逆に、一覧性が大事なら表を先

papoo.work

長い会話は節目ごとに要約を挟む

長文の依頼を一気に投げて、そのまま最後まで走らせる。これ、かなりの確率で手戻りになる。Claude Code は賢いが、会話が長くなるほど前提が散り、途中で「どの話を軸にしていたか」がぼやけるからだ。そこで効くのが途中要約、つまり前提の圧縮である。要するに、長い会話の節目ごとに「ここまでの理解」を短く固定する。すると、指示の食い違いが減るし、後半で出る修正もだいぶ軽くなる。ファイル整理でも、文書作成でも、ディスク削減でも同じだ。最初の前提を詰めたつもりでも、会話が続くと細部が積もって、どこかでズレる。そこで一回、話を畳む。たとえば、案件ごとの文書を整える場面を考える。最初に「このフォルダ内の重複ファイルを探して、不要なものを候補にして」と頼み、そのあとに「やっぱり契約書だけ対象にしたい」「ただし最終判断は人間がやる」と追加していく。ここで要約がないと、Claude Code の中では古い条件と新しい条件が混ざったまま残りやすい。筆者はこれで一度、対象範囲が広がりすぎて、見なくていい資料まで候補に上げられた。手戻りがだるい。節目で要約しておけば、そういう無駄をかなり抑えられる。やり

papoo.work

作業ログから迷った地点だけを次回の依頼に戻す

作業ログを丸ごと次の依頼に貼るのは、だいたい無駄だ。しかも、長いログほど Claude Code の思考を散らす。必要なのは全部ではなく、迷った地点だけである。ここを切り出すやり方は、振り返りテンプレにもなるし、迷いポイントの抽出としても使える。このやり方のうまみは単純だ。前回の作業で「どこで判断に詰まったか」「どの分岐で止まったか」だけを次回に渡せるので、同じ迷いをもう一度なぞらなくて済む。ファイル整理でも、文書作成でも、コード修正でも効く。全部を引き継ぐと重い。迷った地点だけ戻すと、次の一手が速くなる。たとえば、前回の依頼で「古い資料を年度ごとに分けてほしい」と頼んだのに、年度の切り方がファイル名基準なのか更新日基準なのかで止まったとする。このとき次回に必要なのは、作業ログ全文ではない。「年度の境目をファイル名で見るのか、更新日で見るのか迷った」という一点だ。ここだけ戻せば、Claude Code は同じ確認を繰り返さずに済む。実際には、ログを見て次の三つだけ拾えばいい。まず、判断が止まった場所だ。次に、そのとき迷った選択肢だ。最後に、決め手にならなかった理由だ

papoo.work

調べた結果をその場で短く要約させて、次の指示に渡す

調べっぱなしで終わると、Claude Code は平気で長文を抱えたまま次の仕事に入る。そこが雑だと、あとで「あれ、さっき何を見つけたんだっけ」となる。そこで使うのが、その場で短くまとめさせてから次の指示に渡すやり方だ。調査サマリ、中間要約、引き継ぎメモ、と呼び方は何でもいいが、やることは同じである。見つけた事実だけを短く圧縮して、次の判断材料に変える。これが効くのは、Claude Code が「長い調査結果」をそのまま抱え込むと、肝心の次の作業に使うコンテキストがじわじわ削られるからだ。特に、複数ファイルを見たり、候補を比較したり、不要ファイルの洗い出しをしたあとに、そのまま編集へ入る流れは危ない。筆者は最初、調べた内容を全部貼って「これで直して」と投げて、要点がぼやけたまま手戻りした。長文を読ませるより、要点を切って渡したほうが速い。これはかなりはっきりしている。やり方は単純だ。まず調べさせる。次に、調査結果を短く要約させる。最後に、その要約だけを使って次の指示を出す。たとえば、重複ファイルや大きすぎるファイルを見て、削除候補を絞りたいなら、こう頼む。 ```text この

papoo.work

調べた内容をその場で要約させて、次の指示に渡す

調べものをしたあとに、そのまま長文を抱えて次の指示を投げると、Claude Code のコンテキストはあっさり太る。ここで雑に進めると、必要な事実よりも、読み込んだメモやログのほうが邪魔になる。だから一度、中間要約で調査の圧縮を挟む。これだけで、次の一手がかなり安定する。たとえば、ファイル整理でも文書作成でも同じだ。散らかったフォルダ一覧、重複候補、PDF の抜き書き、議事メモ。これらを全部そのまま次の依頼に放り込むと、指示がぼやける。Claude Code は「何を見たか」より「何を判断材料にするか」を短く渡したほうが強い。要は、調べた直後にこう使う。 ```text ここまでに調べた内容を、次の指示に渡しやすい形で短く要約して。目的、重要な事実、迷いどころ、次に決めるべきことを分けて書いて。余計な説明は削って、後続の作業に必要な情報だけ残して。 ``` この一文だけでもかなり効くが、もう少し実務向けに詰めると使いやすい。筆者は最初、調べた内容をそのまま貼って次の指示を出していた。すると、要約すべき箇所まで毎回読み直すことになり、コンテキストが無駄に消える。し

papoo.work

修正後の説明を短く要約させて引き継ぎやすくする

修正した説明を、そのまま長文で押しつけるのはだいたい失敗する。読む側は「で、何が変わったのか」だけ知りたいのに、前提や経緯まで全部読む羽目になるからだ。ここで効くのが、要約だ。さらに引き継ぎメモとしてそのまま使える形に落としておくと、次の人が拾いやすい。 Claude Code は、長い説明を短く圧縮するのが得意だ。ただし、雑に投げると要点まで薄まる。修正後の内容を、誰に渡しても同じ理解になる粒度に削るには、最初に「何のための要約か」を言い切るのがコツになる。単なる短縮ではなく、引き継ぎ用のメモにする。ここを外すと、ふわっとした文章が返ってきて終わる。たとえば、修正した文章がこれだとする。 ```text この機能は、重複したファイル名をまとめて整理できる。対象フォルダを選ぶと、同名ファイルを一覧化し、最後にまとめて確認してから処理を実行する。誤削除を避けるため、最初はプレビューだけ表示する。 ``` これを Claude Code にそのまま丸投げするより、次のように頼むほうが使える出力になる。 ```text 次の説明を、引き継ぎメモとして使えるように短く要約してください。条件

papoo.work

会話が長くなったら、節目で要約させて前提を保つ

長いやり取りで一番こわいのは、Claude Code が急に変な方向へ走ることではない。前提を忘れたまま、もっともらしい修正を積み増していくことだ。これで差し戻しが増える。diff は肥大化する。こっちは「何の話だったっけ」と画面を見返す羽目になる。そこで効くのが、節目要約、途中要約だ。会話が一定の長さになったら、いったん要点を短くまとめさせて、前提を言葉に戻す。地味だが、これを入れるだけで迷走がかなり減る。 Claude Code は、ファイルを読ませて直したり、複数ステップの作業を続けたりすると、会話の流れに引っ張られる。だから「今どこをやっていて、何を変えない方針なのか」を途中で固定し直すのが大事になる。特に、リネーム、ファイル整理、文書の推敲みたいに、見た目以上に前提が崩れやすい作業で効く。やり方は単純だ。作業がひと区切りついたら、次のように節目要約を頼む。 ```text ここまでの前提と、今確定している方針を5行で要約してください。あわせて、まだ未確定の点を箇条書きで分けてください。そのあと、次に触るべきファイルだけ挙げてください。 ``` この頼み方のいいところは

papoo.work