2026-07-12

PDF や議事録の山から必要な情報だけ抜き出して表にまとめる

PDF を全部読んでから表を作る、あれは一番だるい。しかも大抵、読み落としが出る。Claude Code の出番はそこだ。ファイルの山を丸ごと相手にして、必要な項目だけ拾い、CSV か Markdown の表に整える。人力で目を通す仕事を、最初のふるい分けだけでもかなり減らせる。

ここで大事なのは、いきなり「全部まとめて」と投げないことだ。雑に頼むと、抜き出し対象がぶれたり、表の列が途中で増えたりする。筆者は最初、会議議事録を一気に食わせて「決定事項だけ表にして」と頼み、欲しかったのは案件名・担当者・期限だったのに、Claude Code が空気を読んで論点まで拾い始めたことがある。悪くはないが、欲しい形ではない。こういう手戻りが一番もったいない。

まずは対象を狭く決める。PDF や議事録の置き場をひとつのフォルダに寄せて、何を抜き出したいのかを列ごとに言葉で固定する。たとえば、案件ごとの一覧なら「ファイル名、日付、案件名、決定事項、担当者、期限」で十分だ。全部を要約させるより、表にしたい項目だけ指定したほうが強い。

実際の頼み方はこんな感じでいい。

claude

このフォルダ内の PDF と議事録テキストから、次の項目だけを抽出して表にしてください。

列:
- 元ファイル名
- 会議日
- 案件名
- 決定事項
- 担当者
- 期限

ルール:
- 事実として書かれている内容だけを入れる
- 推測で埋めない
- 項目が見つからないときは空欄にする
- 1 行 = 1 件でまとめる
- 重複は統合する
- 出力は Markdown の表にする

PDF が多いなら、最初から「全部を一度に完璧に」狙わないほうがいい。まずは対象ファイルを減らす。たとえば月ごと、案件ごと、部署ごとに分ける。Claude Code は長い文書を扱えるが、だからといって無限に雑に読ませてよいわけではない。入力が膨らむほど、表の精度より「何を優先して拾うか」の指定が効いてくる。

議事録系で効くのは、抽出基準を先に決めておくことだ。「決定事項だけ」「宿題だけ」「期限があるものだけ」のように絞ると、後で人が確認しやすい表になる。逆に、要約と抽出を同時にやらせると、表の列が太りやすい。筆者はここで何度も失敗した。要約がうまいからといって、表づくりまで自動でうまくいくわけではない。役割を分けたほうが安定する。

たとえば、会議の宿題管理ならこう頼む。

このフォルダ内の議事録から、未完了の宿題だけを抜き出してください。

列:
- 会議日
- 依頼元
- 宿題内容
- 担当者
- 期限
- 補足

条件:
- 宿題として明示されているものだけ対象
- 「検討する」「確認する」だけで担当者や期限がないものは、補足にそのまま書く
- 同じ宿題が別ファイルに重複していたら、最新の記載を優先して1件にまとめる
- 判断があいまいなら、表に入れずに別リストで出す

ここで地味に効くのが「曖昧なら別リストに回す」という指示だ。無理に埋めさせると、表はきれいでも中身が怪しくなる。人が後で確認する仕事なら、怪しいものを混ぜないほうが結局早い。

PDF がスキャン画像のままだと、文字として拾えるかが先にある。ここは Claude Code だけの話ではなく、OCR の問題だ。文字が読めない PDF は、当然ながら抽出もうまくいかない。画像 PDF を相手にするなら、まずテキスト化できる状態かを確かめる。ここで「読めているはず」と思い込むと、表が空欄だらけになる。これは本当にある。

出力先も最初に決めると迷わない。Markdown の表で見たいのか、CSV でスプレッドシートに入れたいのかで、頼み方が少し変わる。

出力は CSV 形式で、ヘッダー行を付けてください。
文字列の中にカンマが入る可能性があるので、必要なら引用符で囲んでください。

スプレッドシートに流すなら CSV が扱いやすい。人間が読むだけなら Markdown の表で十分だ。用途が曖昧なまま始めると、せっかく抜き出したのに再整形が発生する。二度手間はここで起きる。

一歩進めるなら、表にする前の下ごしらえを Claude Code にやらせるといい。たとえば、長い議事録から「日付ごと」「案件ごと」に見出しを揃えさせてから抽出する。あるいは、ファイル名のゆれを整えてから一覧化する。ファイル整理まで含めると、後の検索がかなり楽になる。

このフォルダ内の議事録について、まず次をしてください。

1. ファイル名から会議日が分かるものは拾う
2. 本文中の日付も照合する
3. 案件名の表記ゆれを統一する
4. そのうえで、宿題一覧を表にする

表の前に、表記ゆれの統一ルールも短く書いてください。

最後に、やってはいけないことをはっきり言う。根拠のない補完を許すことだ。「たぶんこの担当者だろう」「期限は普通こうだろう」は危ない。議事録や PDF の抽出は、推測が混ざった瞬間に信用を落とす。必要なのは賢い作文ではなく、見つかった事実をそのまま表に落とすことだ。

もし扱う文書がさらに増えるなら、次は「フォルダの構成を先に整える」「重複 PDF を減らす」「よく使う抽出フォーマットを固定する」に進むといい。Claude Code は一発芸より、同じ型を何度も回すと強い。文書の山を毎回ゼロから読むのではなく、最初の整理役として使う。そこがいちばん効く。

関連 TIPS

同じ著者の記事

非エンジニアのための最小ターミナル入門：Claude Code に任せる前提で

「ターミナルはエンジニアの武器」みたいな顔をしているが、Claude Code を使うなら、非エンジニアこそ最低限だけ覚えておいたほうが速い。全部を理解する必要はない。だが、入口と出口を知らないまま突っ込むと、ファイルの置き場所が分からず詰む。そこで止まるのはもったいない。ここでいうターミナルは、黒い画面そのものをいじり倒す話ではない。Claude Code に「このフォルダで作業して」「このファイルを見て」「この名前に直して」と頼むための、最低限の足場だと思えばいい。要るのは、移動する、見る、戻る、そして作業前に退避する、の4つだけである。まず覚えるのは、たったこれだけで足りる。 ```bash pwd ls cd フォルダ名 cd .. ``` `pwd` は今いる場所を表示する。`ls` はその場所にあるファイルやフォルダを見る。`cd フォルダ名` は移動、`cd ..` はひとつ上の階層に戻る。これで家の中をうろつくくらいのことはできる。深い仕組みは要らない。 Mac ならターミナル、Windows なら PowerShell を開いて、まず自分がどこにいるかを見る。思っ

papoo.work

フォルダの中身を棚卸しして「何が入っているか」を一覧化する

フォルダを見て「何が入っているか」を口で説明できないなら、だいたい整理は崩れている。ファイル名を眺めるだけでは足りないし、サブフォルダが深いと、人間の頭ではすぐ抜け落ちる。Claude Code は、その見落としを雑に埋める道具としてかなり使える。やることは単純だ。指定したフォルダの中身を洗い出し、階層ごとに一覧にする。必要なら、種類ごとに分ける。重複っぽいものや、でかいファイルが混じっていないかまで見える。ディスク整理でも、案件フォルダの把握でも、書類の棚卸しでも効く。最初に大事なことを言うと、Claude Code に「このフォルダを見て要約して」とだけ投げるのは雑すぎる。そうすると、見出しだけのふわっとした返事になりやすい。欲しいのは要約ではなく、一覧だ。しかも、後で自分が再利用できる粒度の一覧である。たとえば、こういう頼み方をする。 ```bash claude ``` プロンプトでは、まず目的をはっきり書く。 ```text このフォルダの中身を棚卸しして、何が入っているかを一覧にしてください。人間が後で整理しやすいように、次の順で出してください。 1. 直下のフォル

papoo.work

大量のファイルを内容で分類してフォルダに振り分けてもらう

ファイル名だけ見て振り分けようとするのは、だいたい雑に終わる。`final_2` とか `新規` とか `scan0007` みたいな地獄を、名前だけで救えるわけがない。こういうときは、Claude Code に「中身を読ませて分類させる」ほうが早い。やりたいことは単純だ。大量の PDF、テキスト、Markdown、メモ、書類を、内容を見て「契約」「請求」「議事録」「レシート」「未分類」みたいなフォルダへ振り分ける。人間がやると面倒だし、疲れると判断がブレる。Claude Code なら、ルールをきっちり渡せば、かなり機械的に回せる。ただし、ここを雑に頼むとすぐ詰まる。分類基準があいまいだと、よくわからないフォルダが増えるだけだし、元ファイルの移動を先にやらせると取り返しがつかない。まずは「コピーで試す」「ルールを固定する」「例外を作る」の三つを押さえるのが筋だ。最初に、分類の軸を人間側で決める。Claude Code は賢いが、勝手にあなたの仕事の流儀を理解してくれるわけではない。たとえば、法務書類ならこんな切り方が現実的だ。契約書見積書請求書受領書・領収書議事録仕

papoo.work

重複ファイルと不要キャッシュを洗い出してディスクを大幅に空けた話

ディスクが足りないとき、多くの人はまず「大きいフォルダ」を探す。だが、実際に効くのはそこじゃない。見落としやすい重複ファイルと、放置された不要キャッシュだ。ここを片付けると、ディスク整理とストレージ削減の効き方が一段違う。 Claude Code は、こういう“散らかった証拠集め”に向いている。ファイル一覧を読ませて、重複候補を洗い出し、消してよさそうなものと残すべきものを切り分ける。自分で全部目視するとだるい作業を、かなり前まで持っていける。ただし、雑にやると普通に痛い目を見る。筆者も最初は「大きいファイルだけ見ればいいだろ」と思って進め、あとで同じ画像の複製や、文書生成ツールのキャッシュをまとめて抱えていたことに気づいた。そこから先は、Claude Code に“見つける役”をやらせるようにした。まずやることは単純だ。Claude Code に、対象フォルダの一覧を見せて、サイズ順に怪しいものを拾わせる。重複はファイル名だけでは当てにならない。よくあるのは、`final`、`final2`、`final_revised` みたいな半端な複製だし、画像なら見た目が同じでも保存形式

papoo.work

弁護士が案件ごとにフォルダを掘り、関連書類から書面の下書きを作る

案件フォルダが散らかっていると、書面づくりはただの手作業地獄になる。士業でも書類整理でも同じで、探す時間が長いほど、肝心の中身を考える時間が削れる。 Claude Code はコードを書く道具だと思われがちだが、実は「フォルダを掘って、関連ファイルを拾い、下書きを作る」作業にかなり向いている。弁護士の案件管理みたいな使い方でも効く。やることは単純で、案件ごとにディレクトリを切り、そこに集めた PDF、メモ、メール書き出し、下書きテキストをまとめて読ませる。すると、論点の整理や書面のたたき台づくりが一気に楽になる。ただし、雑に使うとすぐ詰まる。フォルダが深すぎる、指示が曖昧、関係ない資料まで全部入れる。この三つで平気で手戻りする。筆者も最初は「案件名だけ投げれば何とかなる」と思って失敗した。実際には、何を優先して読ませるかを先に決めないと、出てくる下書きがぼんやりする。これはかなり重要だ。まず、案件の単位で作業用フォルダを切る。たとえばこうだ。 ```text 案件A/ 00_依頼内容/ 10_証拠/ 20_相手方書面/ 30_メモ/ 90_下書き/ ``` 番号を付けるのは見た目の

papoo.work

写真や書類のファイル名を内容に沿って一括リネームする

「IMG_4839.jpg」を100枚並べて、あとで中身を見てから直そうとする。あれ、だいたい破綻する。写真でも書類でも、名前が意味を持っていないと、探すだけで時間を食う。Claude Code は、その手の雑な山を一気に片づけるのに向いている。ただし、いきなり「全部いい感じにリネームして」と投げるのは危ない。ファイル名は短いのに、中身は長い。だから先にやるべきことは、Claude Code に内容を読ませる前提を整えて、命名ルールを決めることだ。ここを飛ばすと、出力はそれっぽいが、あとで人間が直す羽目になる。筆者は最初、このあたりを雑に頼んで、日付形式がバラけたファイル群を量産してしまった。見た目は整っているのに、並び順がぐちゃぐちゃで、結局やり直しだ。痛い。まず大事なのは、Claude Code に「何を材料にして、どういう名前にするか」をはっきり渡すことだ。写真なら撮影日、場所、被写体。書類なら日付、相手先、案件名、文書種別。この4つのどれを優先するかで、後の検索性が変わる。たとえば、写真整理ならこういう指示でいい。 ```text このフォルダ内の画像ファイルを見て、内容

papoo.work

Claude Code に自分の作業を検証させる：思い込みを潰す確認の頼み方

人は、自分で直したコードや片づけたファイルをいちばん雑に見てしまう。見たつもりで見落とすし、「たぶん合ってる」で突っ走る。Claude Code を使う場面でも、ここが一番まずい。この手の失敗は、派手なバグより地味に痛い。ファイル整理なら不要データを残したまま「空いた気になる」。文書作成なら、参照漏れや表記ゆれを見逃す。開発なら、テストが通っただけで安心して、実は境界条件を壊している。だから Claude Code には「作って」と頼むだけでなく、「自分の作業を疑え」と頼むのが効く。要は、Claude Code を作業者ではなく、検査役として使う発想だ。しかも、ただ「チェックして」と投げるだけでは弱い。どこを、何と照合し、何をもって問題なしとするかを、先に決めておく必要がある。一番ありがちな失敗は、作業のあとにこう言うことだ。 ```text これ、確認して。 ``` これでは甘い。Claude Code は広く見られるぶん、広く見て終わる。見る範囲が曖昧だと、確認の密度が下がる。確認役にしたいなら、検証対象をはっきり切るべきだ。たとえば、コードなら「変更した関数だけ」「テスト

papoo.work

エラーログを貼って原因を切り分けてもらう頼み方

ログを貼らずに「動きません」だけ投げるのは、ほぼ自爆だ。Claude Code に原因切り分けを頼むなら、症状の説明より先に、エラーログをそのまま渡したほうが速い。これは開発作業でも、ファイル整理でも、書類の自動生成でも同じである。曖昧な依頼は、余計なやり取りを増やしてコンテキストを食い、最後に「それ、最初に出してくれれば済んだのに」になる。 Claude Code は、端末上で見えているエラー文や関連ファイルを手がかりに、何が壊れているかをかなり実務的に絞れる。だが、こちらの頼み方が雑だと、関係ない方向を見始める。筆者も最初は「なんか失敗する」で投げて、延々と見当違いの説明を掘らせたことがある。ログを最初から貼っておけば、あの無駄な往復はかなり減ったはずだ。まず、頼み方の基本形はこれでいい。 ```text 次のエラーログを読んで、原因候補を優先度順に切り分けてください。不明な点は、追加で見るべきファイルやコマンドも挙げてください。推測だけで断定せず、ログから読める事実と推測を分けてください。 ``` これだけでも十分使えるが、実際には少し足したほうが強い。Claude Cod

papoo.work

失敗するテストを先に書いてもらい、それを通す形で直す

「直してから確認する」は、だいたい遠回りだ。Claude Code にも同じで、まず壊れるテストを作らせてから、その赤を消す形でコードを直すほうが、手戻りが少ない。このやり方の良さは単純だ。何を満たせばいいかが先に固定される。しかも、Claude Code が勝手に話を広げにくい。いきなり実装をいじらせると、見た目は動いても境界条件を落とすことがある。先に失敗するテストを書かせれば、「何を守るべきか」をコードより先に置ける。筆者も最初は、仕様を口で説明してそのまま直させていた。すると、動くけれどテストが増えない。次に同じ不具合が出たとき、また同じ説明を繰り返す羽目になる。そこで先にテストを書かせるようにしたら、会話の焦点が一気に締まった。曖昧な依頼が減るし、差分も追いやすい。かなり地味だが、効く。やり方はこうだ。Claude Code に最初から「壊れているテストだけを作れ」と頼む。実装はまだ触らせない。たとえば Python なら pytest、JavaScript なら既存のテストランナーに合わせて書かせる。非エンジニアが文書整理やファイル整理に使う場合でも同じで、たとえば「

papoo.work

「再現手順」を渡してバグを再現させてから直してもらう

「壊れてるから直して」で投げると、だいたい遠回りになる。Claude Code みたいなCLIエージェントは、雰囲気で当てるより、再現できる条件を渡したほうがずっと強い。バグ修正で本当に効くのは、症状の説明を増やすことではない。再現手順を切り分けて、同じ失敗をもう一度起こさせることだ。そこまでできれば、Claude Code はログやコードを追いやすくなるし、修正後の確認まで一気通貫で進められる。逆に、あいまいな「なんか動かない」は、コンテキストを食うだけ食って、外す。筆者も最初はこれで手戻りした。変更箇所を広げすぎて diff が膨らみ、直したいバグより副作用の確認に時間を取られた。あれはだるい。まずやることは単純だ。Claude Code に「原因を探して」と丸投げする前に、こちらで再現条件を短く固める。たとえばこうだ。 ```text 次の不具合を再現してから修正してほしい。症状: ファイル名に日本語が入っていると、出力先のリネームが失敗する再現手順: 1. sample/ に「議事録 2024-01.txt」を置く 2. そのファイルを対象に変換コマンドを実行する 3.

papoo.work