Claude Codeを事務作業で使う: 文書とレポートの8つの自動化
Claude Codeで繰り返しの文書作業を準備する8つの方法と、結果の確かめ方、人に残すべき判断を紹介します。
目次
Claude Codeを事務作業で使う: 文書とレポートの8つの自動化
Claude Codeはターミナルで動くエージェントです。指定したフォルダ内のファイルを読み、依頼ごとに必要なスクリプトを書いて実行し、結果を元ファイルの隣に出力します。事務作業では、相談相手として使うチャットとは少し違います。入力、期待する出力、結果の確かめ方を伝えると、必要なコードはエージェントが組み立てます。
これらの作業に従量課金のAPI接続を使いたい場合は、現在のBetterTokenのClaude Code設定ガイドを開き、自分のAPI Keyで設定します。BetterTokenはClaudeのサブスクリプションではなく、独立したAPIサービスです。実際の文書を扱う前に短いリクエストを1回送り、Dashboardでリクエストのステータス、使用モデル、input・output・cache tokenの消費を確認してから進めてください。
先に要点を確認する
- Claude Codeが得意なのは、入力と出力の形を言葉で指定できる仕事です。たとえば表の統合、PDFからの項目抽出、二つの文書の差分比較です。
- 深い技術知識は必須ではありません。ただし、ターミナルを開き、変更を許可する前に計画を読めることは必要です。
- すべての依頼には検証を付けます。行数、元の条番号、原文からの短い引用など、結果を照合できるものを残します。
- 契約リスクや数値の妥当性のような判断では、Claude Codeには材料の整理までを任せます。結論を出すのは人です。
まず作業用フォルダを作る
よくある失敗は、原本が置かれたフォルダをそのままClaude Codeで開き、「このファイルを整理して」と頼むことです。エージェントは実行しようとしますが、その並べ替え方が意図どおりとは限りません。
手間は増えますが、安全なのは仕事ごとに専用フォルダを作り、入力と出力を分ける方法です。
office-work/
├── inbox/ # 元ファイルのコピー
└── output/ # Claude Codeが作る成果物inbox/に入れるのはコピーだけで、原本は置きません。初めての作業やファイル数が多い案件では、変更を許可する前に計画だけを出させます。
cd /path/to/office-work
claude --permission-mode planこのモードでは、Claude Codeはフォルダを調べ、何を行うつもりかを説明しますが、ファイルは変更しません。フラグを使わずに「最初に計画だけを書き、私が確認するまで何も変更しないで」と伝えても同じです。どちらの場合も計画を読む責任は残ります。ファイル一式を監督なしで渡しても自動的に正しく処理してくれる、というボタンはありません。
実際に任せやすい8つの仕事
表計算とレポート
複数のExcelファイルを一つの表にまとめる。 支店や担当者から届く報告書では、列見出しが少しずつ違い、空行が混ざり、合計が数値でなく文字列になっていることがあります。依頼は次のように具体的にします。
inbox/excel に xlsx の報告書があります。
最初に列見出しを確認し、どこが違うかを説明してください。
私が確認した後、output/combined.xlsx に統合してください。
各行に元ファイル名を入れた source_file 列を追加してください。
空行または壊れた行は「要確認」シートへ移してください。
最後に、読んだファイル数、最終表の行数、要確認の行数、
重複の有無を報告してください。ここでの検証は算数です。入力ファイル全体の行数は、最終表の行数と「要確認」シートの行数の合計に一致する必要があります。合わないときは「正しいですか」とだけ聞かず、どの行がどこで落ちたのかを示すよう求めます。
列の意味が同じでも見出しが違う場合は、勝手に一つへ寄せないようにします。たとえば売上と売上高を同じ列として扱うのか、税込み・税抜きが混在していないかを、統合前の計画で確認します。数値に見える文字列、日付の表示形式、同じ伝票の重複も、最終ファイルではなく「要確認」に残す基準を先に決めます。これなら、統合結果を受け取った後に元の表から検算できます。
PDFをまとめて読み、報告書用のデータを作る。 PDFは見た目以上にばらばらです。あるPDFは通常のテキスト、別のPDFは表組み、さらに別のPDFはテキスト層のないスキャンかもしれません。フォルダ全体を渡す前に、性質の異なる3ファイルを手作業で確認します。取引先、対象期間、金額、分類といった各項目を、どのように取り出したかをファイルごとに示させてください。pdfplumberやOCRを提案されたら理由も確認します。スキャンから文字を読むにはOCRが必要で、後から出典に戻れないページ番号なしの行は、誤りを調べるとき役に立ちません。
抽出結果には、値だけでなくsource_file、ページ番号、読み取れなかった理由も入れると扱いやすくなります。金額の通貨記号や桁区切り、複数ページにまたがる表、OCRで取り違えやすい0とOのような文字は、抽出成功と見なさず確認対象にします。最初の三件で項目ごとの根拠が追えなければ、残りのPDFを一括処理しても、後の修正コストが増えるだけです。
文書と契約の定型作業
形式が混在するフォルダから台帳を作る。 DOCX、PDF、XLSXが一つのフォルダに混在している場合、「このフォルダを整理して」だけでは足りません。形式ごとに使う読み取り手段が異なるからです。まず、存在する形式と、それぞれを何で読む予定かの一覧を作らせます。その後にfile_name、title、author、date、subject、needs_reviewなどの列を持つ台帳を作ります。見つからなかった項目は推測で埋めず、空欄のままにします。
ここでも出力先はoutput/に限定します。原本を移動したり、拡張子だけで内容を決めつけたりしないことが重要です。パスワード付き、破損、画像だけのPDFのように開けないファイルは、台帳にneeds_reviewを付け、失敗理由を記録します。ファイル名から著者や日付を推測して埋めるより、空欄を残したほうが後の検索と確認に役立ちます。
契約書の版を比較する。 エージェントに向く依頼は「この契約のリスクを評価して」ではありません。「変更された条項を見つけ、旧文と新文を横に並べ、各差分に該当する条番号を付けて」です。出力は、法務担当者が自分で判断するための下書きです。差分のすべてが特定の節へ戻れなければ、もっともらしい要約になっても鵜呑みにはできません。
比較する前に、どちらが旧版でどちらが新版か、添付資料を含めるか、変更のない条項を省くかを明示します。句読点や見出し番号の差だけと、責任範囲・金額・期間の変更を同じ重みで扱わないよう、差分表に種別を設けるのも有効です。ただし、その種別は法的な評価ではありません。法律上の意味、交渉方針、署名の可否は、必ず担当者が原文を読んで決めます。
管理レポート
週報を月報へ集約する。 報告の形式はそろいません。テンプレートで出す人もいれば、チャットに三行だけ書く人もいます。担当者と週ごとにまとめ、完了と未完了を分け、複数週に繰り返し現れる問題、期限も担当者もない項目を印として残すよう依頼します。Claude Codeは読みやすい要約を作れますが、本当に価値があるのは、事実が合わない箇所や担当者が欠けた箇所の一覧です。
月報の文章だけを作らせるのではなく、元の週報への参照を残した表も同時に出力させます。「完了」と書かれた仕事が翌週も未完了として現れる、期限が日付ではなく「来週」とだけ書かれている、といった矛盾を拾うためです。エージェントには矛盾の一覧を作らせられますが、実績の訂正や優先順位の判断まで自動で確定させないでください。
議事録からタスク一覧を作る。 会議メモは、決定事項、タスク、未解決の問いを取り出すまでほとんど使えません。一方で、モデルは「田中さんも議論に参加した」を「田中さんが担当する」に変えてしまいやすいものです。各項目の横に原文の短い引用を必ず付ける、というルールで多くの誤りを防げます。引用はエージェントにも、後で一覧を読む人にも、根拠を確認させます。
タスク表には、担当者、期限、状態を分けて置きます。ただし、原文にない担当者や期限は空欄にして要確認とします。決定事項と検討中の発言も同じ欄に混ぜません。会議の最後に誰が何を引き受けたかを人が確認できる状態にすることが目的であり、会話の要約を滑らかにすることではありません。
ファイル整理と公開準備
写真や文書のファイル名を手作業なしで整える。 IMG_0001.jpg、final.docx、final2.docxのような状態は珍しくありません。ただし、すぐにリネームを許可しないでください。最初に、決めた命名規則に従ったCSVを作らせます。CSVには旧名、新名、変更理由を入れ、新しい名前どうしが衝突しないかも先に確認します。計画をレビューしてから実際のリネームを行い、何を変更したかのログを残します。ログのない一括リネームは、夜のうちに書類棚の全フォルダを入れ替え、翌朝に置き場所を思い出そうとするようなものです。
命名規則には、日付をどの形式で入れるか、連番を何桁にするか、元の拡張子を保持するかまで書きます。同名ファイルがすでに存在する、日付がファイル名とメタデータで食い違う、対象外のサブフォルダが見つかる、といった場合は停止するように指定します。一回の承認で「計画の作成」と「実ファイルの変更」を済ませようとしないことが、復旧しやすさを保ちます。
記事を公開できる状態まで準備する。 これは一段階の仕事ではありません。Markdown、画像、リンクを確認し、ローカルのHTMLプレビューを作り、必要なサイズのカバー画像を準備します。その後で初めて、APIやMCPを使って下書きを送ることを検討します。まず外部送信やAPI Keyの使用を明示的に禁止した状態でローカルプレビューを完成させ、公開は別の、意識して許可するコマンドとして扱うのが安全です。
公開準備の依頼では、壊れたリンク、存在しない画像、見出し階層、出力ファイルの場所を報告させます。ローカルプレビューが完成したことと、外部サービスへ送信したことは別の成功条件です。API Keyを読む、下書きを作成する、公開するという操作は、それぞれ対象と結果を確認してから個別に許可します。テキストの整形作業に、意図しない外部送信まで含めないためです。
うまくいかない場所
入力と出力を構造で定義できる仕事、つまり項目抽出、表の統合、文章比較、規則によるグループ分けは、Claude Codeが比較的安定して処理できます。反対に、OCRのないスキャン、結合セルが多いExcel、共通テンプレートのない文書では確認が増えます。契約条項のリスク評価、レポート数値のずれの理由、どの公開テーマを優先するかといった判断も同様です。この種の作業では、事実を並べ、出典への参照を付けるところまでを任せ、最終判断は人が行います。
一つのセッションで扱える無関係な仕事の量にも実務上の限界があります。異なる案件を長く続けるほど文脈が膨らみ、古い指示と新しい指示を混同しやすくなります。月報を終えたら、契約書の作業は新しいセッションで始めるほうが安全です。
Plan modeはいつも必要か
必ずしも必要ではありません。構造が完全に同じExcelファイルを100件、一つの規則で統合するような単純な反復作業では、計画を読む追加の一往復が保護よりも遅延になることがあります。形式が混在している、契約書を扱う、間違えて変更すると戻しにくい、といった場合にはPlan modeが役立ちます。ミスのコストが高いほど、実行を許可する前に計画を確認する数分の価値も上がります。
どのような場面でskillにするか
同じ依頼が毎月のように戻ってくるなら、skillとして固定する価値があります。つまり、読むもの、作るもの、実行する検証、人に確認を求める停止地点を決めた指示ファイルです。目安は単純です。まず数回は手動で実行します。よくない指示は自動化しても改善せず、同じ失敗を予定どおり、より速く繰り返すだけです。
よくある質問
プログラミング経験は必要ですか？
最初の作業には不要です。ターミナルを開き、フォルダへ移動し、実行を確認する前に計画を読むことができれば始められます。ライブラリ、ファイル形式、依存関係のレベルで問題が起きたときにはコードの理解が役立ちますし、遅かれ早かれその場面は来ます。
Claude CodeはExcel、Word、PDFを自分で読めますか？
いいえ。マシンにすでに入っているプログラムやライブラリを使います。表計算には通常、対応するライブラリを備えたPythonが必要で、スキャンにはOCRが必要です。ファイルを渡す前に、どのツールで開くつもりなのかを聞いておくほうが、失敗してから原因を調べるより安く済みます。
全工程を任せられますか？
読む、変換する、グループ分けする、名前を変える、下書きを組み立てる、といった機械的な部分は任せられます。お金、人、契約、公開に関する決定は、エージェントが判断材料を準備した場合でも、人が持つべきです。
参考資料
まずは、面倒でも検証しやすい仕事から始めてください。五つの表を統合する、報告書フォルダを台帳にする、ファイル名を整える、といった作業です。コピーを渡し、計画を読み、実行前に何をもって成功とするかを決める。それができれば、自動化はfinal_final_2のようなフォルダを増やすのではなく、実際に作業時間を減らせます。
