Claude Codeの使い方｜請求書の手打ち月2時間を、日本語一文で自作ツールに

Claude Code とは、ターミナルに常駐し、自然言語の指示だけでファイルの読み書きやコード生成、テスト実行までこなす AI コーディングエージェントだ。Anthropic が提供し、2025年 5 月に正式リリースされた。

経理担当の田中さんは、毎月 200 枚超の請求書 PDF を開いて、取引先名と税抜金額を Excel に手打ちしている。1 枚 40 秒として、月に 2 時間かかる。以前この作業を自動化したくて社内のエンジニアに相談したが、「他の案件で手が空くのは来四半期」と言われ、そのまま棚上げになった。頼む相手がいないと、小さな不便はずっと残る。

Claude Code の使い方の核心は、この「頼む相手」を自分の手元に置けることだ。ターミナルを開き、「このフォルダの請求書 PDF から取引先名と税抜金額を抜いて CSV にまとめて」と日本語で打つ。すると、Claude Code が PDF を読み、抜き出す処理を書き、実際に走らせ、結果のファイルまで残す。田中さんがやったのは、片づけたい仕事を文章で説明したことだけだ。

コードを書く仕事ではない。片づけたい仕事を、言葉にする仕事だ。

しかも、一度作ったものは使い捨てにならない。生成された処理は手元のファイルとして残るため、翌月は同じ指示を繰り返す必要がない。プロジェクトに CLAUDE.md という指示書ファイルを置き、「金額はカンマ区切り、消費税は税抜で抽出」といったルールを書いておけば、セッションをまたいで同じ約束が引き継がれる。これが、非エンジニアでも業務ツールを自作して手元に残せることを意味する。

ただし、できないことや向かない場面も正直に伝えておく。3 秒で判定してほしいのはこの 3 点だ。

• 使い始めるまでに Node.js 18 以上などの環境構築が要る。PC に管理者権限がないと、最初の一歩でつまずく。
• Claude Pro / Max のサブスクリプション、または API の従量課金が必須で、無料では本格利用できない。
• 生成物はレビューしてから使う。Anthropic 自身、レビューなしの本番反映を推奨していない。

Claude Code のできることは広いが、「AI が作ったから正しい」という過信だけは持ち込まない方がいい。抜き出した金額が 1 桁ずれていれば、それは自動化の失敗ではなく確認の失敗になる。

つまり、エンジニアに頼んでいた小さな作業ツールを日本語で自作できるかどうかは、環境を整えられるかにかかっている。その最初の関門を、次で先に潰しておこう。

「まず Node.js を入れてください」の一文で、田中さんの手が止まった。ターミナルに node --version と打っても「command not found」と返る。ここが、多くの非エンジニアが Claude Code の使い方の最初でぶつかる最大の壁だ。Claude Code インストールの本当の難所は、Claude Code 本体ではなく、その手前にある。

土台になるのが Node.js (JavaScript をサーバー側で動かす実行環境) だ。Claude Code は Node.js 18 以上と npm または curl を前提に動くため、これが入っていないと本体をインストールする段階に進めない。厄介なのは、多くの会社支給 PC ではソフトの新規インストールに管理者権限が必要で、その権限が情シスに握られていることだ。ここで止まったら、自力で突破しようとしないことが肝心だ。「Node.js 18 以上を業務利用で入れたい」と情シスに連絡を入れる——これが最短ルートになる。無断で回避策を探すより、正規の申請のほうが結局は早い。

次にお金の話だ。ここも先に正直に言っておく。Claude Code の本格利用には Claude Pro / Max のサブスクリプション、または API の従量課金が必須で、Claude Code 無料の範囲だけで請求書処理を回し続けるのは難しい。しかも見えにくいコストがある。長い会話を自動で要約するバックグラウンド処理などもトークン (AI が文章を処理する単位) を消費するため、使い方しだいで料金が予想外に伸びる。対策は単純だ。いきなり月 200 枚を流し込まず、まず 10 枚で試して 1 回あたりの手応えとコスト感をつかむ。小さく始めれば、請求が跳ねてから慌てることはない。

インストールを終えたら、いきなり本題に入る前に一手だけ挟むと後が楽になる。作業したいフォルダで /init を実行することだ。これはカレントディレクトリ (いま作業中のフォルダ) の中身を解析し、前セクションで触れた指示書ファイルの初期テンプレートを自動で書き起こしてくれる。ゼロから白紙に向き合う代わりに、たたき台が最初から手元にある状態で始められる。Claude Code の初回セットアップにかかる数十分が、これで丸ごと省ける。

ここからは、知らずに踏むと痛い落とし穴を先につぶす。特に注意したいのが --dangerously-skip-permissions のフラグだ。名前のとおり「危険なほど確認を飛ばす」もので、通常なら「このファイルを書き換えていいですか」と一つずつ聞いてくる確認を、すべてスキップする。ネット上の手順記事が「これを付ければサクサク動く」と勧めていることもある。しかし、機密の請求データが入った業務 PC でこれを付ければ、意図しないファイルの上書きや削除が、あなたの承認なしに行われる。

確認を飛ばして得た数秒が、消えたデータで数日を奪う。

そのため業務 PC では、このフラグを外したまま使う必要がある。一つずつ「はい」を押す手間は、あなたの目が事故を止める最後の関門だ。面倒に感じたら、それは安全装置が効いている証拠だと思えばいい。

もう一つ、地味だが効いてくるのが会話の長さだ。Claude Code は会話が長くなると /compact で履歴を自動要約し、文脈を圧縮する。便利な反面、「金額は税抜で」「取引先名は正式名称で」といった細かい約束が、要約の過程で薄まることがある。1 時間後、抜き出した金額の桁が微妙にずれる——原因はここにあることが多い。備えは二段構えでいい。

• 絶対に外せない制約は、会話の冒頭で毎回あらためて伝え直すこと
• 恒久的なルールは前セクションの指示書ファイルに書いておき、要約に消されない場所に置くこと

この二つをやっておけば、会話が長引いても指示の芯はぶれない。

環境、課金、危険フラグ、会話の要約——Claude Code を使い始める前に潰すべき四つの壁は、いずれも知ってさえいれば数分でよけられる。土台が整えば、あとはツールの出来を決めるのは指示の書き方そのものになる。その品質を左右する指示書ファイル、CLAUDE.md を次で掘り下げる。

同じ請求書フォルダで、田中さんは月曜に「税抜金額を抜いて」と頼み、木曜に再度同じ指示を出す。木曜の CSV には、なぜか税込の数字が混じっていた。悪いのは Claude Code (Anthropic 社の AI コーディングツール) ではない。長い会話の中で「税抜で」という約束が要約に埋もれ、次のセッションでは白紙から始まっていた。指示は、伝えた瞬間から薄まっていく。

これを止める場所が ==CLAUDE.md== だ。プロジェクトのフォルダにこのテキストファイルを一枚置き、「金額は税抜」「取引先名は登記上の正式名称」「単位が空欄の請求書は処理せず一覧に残す」といった、毎回守ってほしい約束を記載しておく。Claude Code は起動のたびにこのファイルを読み、書かれたルールを前提として動く。会話が要約されても、ここに書いた芯は消えない。Claude Code の使い方でツールの品質が安定するかどうかは、この一枚をどれだけ具体的に書けるかにかかっている。

特に効果的なのが用語集だ。Claude Code に日本語で指示を出すと、モデルは「請求」「立替」「支払サイト」あたりまではだいたい正しく解釈する。しかし社内でしか通じない略語——「A 掛け」「本チャン」「先方 NG 分」などは、平気で別の意味に取る。何を指すのか、こちらが定義しない限りモデルは推測で埋める。だから CLAUDE.md の末尾に、社内語とその正確な意味を対訳で並べておく。

• 略語や社内用語は「本チャン=本番用の確定データ」のように、置き換え後の言葉も記載する。
• 「取引先名」のように解釈の幅がある語は、どのフィールドの値を指すかを一文で固定する。
• やってはいけないことは禁止形で明記する（例：「金額が読み取れない請求書は勝手に 0 と補完しない」）。

この対訳が一行あるだけで、10 枚流しても 200 枚流しても、抜き出し方が揃う。ばらつきの多くは、モデルの能力ではなく、言葉の定義漏れだ。

出力がぶれるのは AI が迷うからではない。こちらが定義を渡していないからだ。

ルールが固まれば、Claude Code の使い方として日々の運用は対話すら要らなくなる。--print（短く -p）を付けて起動すると、Claude Code は質問を返さず、結果だけを出力する。claude -p 'このフォルダの請求書を集計して' > report.txt のように書けば、出力をそのままファイルに落とせる。これを PC のタスクスケジューラ (指定時刻にプログラムを自動実行する仕組み) で毎朝動かせば、出社した田中さんの机には、前夜のうちに生成された集計レポートが一枚。朝の定例が、ターミナルを開く前に終わっている。

もう一つ、数日がかりのツール作りを支えるのが --resume だ。「取引先マスタと突き合わせて表記ゆれを直す」ような込み入ったツールは、一度の会話では作りきれない。月曜に設計を相談し、火曜に試作、水曜に手直し——その途中で PC を閉じても、--resume で過去のセッションを名前で選んで呼び戻せば、あの日の会話の続きから再開できる。CLAUDE.md がルールの記憶なら、こちらは作りかけの記憶だ。二つが揃って初めて、非エンジニアでも腰を据えたツール作りが手元で進む。

ここまでの Claude Code の使い方の型——ルールを一枚に書き、用語を対訳で渡し、対話なしで回す——は、請求書だけのものではない。定義さえ言葉にできれば、稟議書の要約でも、問い合わせメールの分類でも、同じやり方がそのまま通用する。

請求書 CSV を作れるようになった田中さんが、次に片づけたくなったのは会議の後の仕事だった。週明けの朝、共有フォルダには先週分の議事録が 5 本たまっている。それを一本ずつ開いて、決定事項と担当者だけを拾い、部長宛の週報に貼り直す。金額の抜き出しと構造は同じだ。フォルダの中身を読み、必要な情報を取り出し、一枚のファイルにまとめる。変わるのは対象が PDF からテキストになったことと、抜くのが「金額」ではなく「決まったこと」になったことだけである。

議事録の要約も、請求書とほとんど同じ一行で回る。--print フラグを使って対話なしでファイル出力する Claude Code の使い方や、朝までに下書きを用意しておく段取りは前述のとおりだ。対象がテキストに変わっても、組み方は変わらない。仮に 1 本の議事録を読み返して要点を拾うのに 4 分かかっていたとすれば、5 本で 20 分ということになる。しかし、この数字はあくまで田中さんの体感に基づく仮定であり、実際の短縮幅は議事録の分量や書き方の癖によって変わる。確かなのは、開き直る手間そのものが一つの指示に置き換わる点だ。決定事項の言い回しがぶれるなら、CLAUDE.md に「担当者名は敬称なしのフルネームで」と一行足せば、抜き方が揃う。

集計の仕事も横に伸びる。支店ごとにフォーマットの違う売上 Excel が毎月フォルダに集まり、それを一つの表に手で足し込む。この手の作業には、「このフォルダの Excel を読んで、支店別の売上を月次で合計する集計スクリプトを作って」と頼む。Claude Code が集計処理を書き、実際に走らせ、結果を残す。スクリプトは手元のファイルとして保存されるので、翌月は同じものを走らせるだけで済む。フォーマット変換の繰り返しや、取引先から届く独自形式の CSV を社内システムに取り込める列順に並べ替える作業も、一度型を作れば毎回の手作業から解放される。

ここまで請求書、議事録、売上集計と三つの例を見てきたが、これらに共通する条件を分解しておく方が、次に自分の仕事に当てはめるときの見立てが立てやすい。具体的には、以下の三つである。

• 入力の置き場所が決まっている（同じフォルダに同じ種類のファイルが集まる）
• 抜き出す・並べ替える・合計するといった、手順を言葉で説明できる処理である
• 出力の形が毎回同じ（同じ列、同じ見出しの一枚に落ちる）

一つ目の条件が崩れると、フォルダを探すところから毎回人の判断が必要になる。二つ目が崩れると、「どれが決定事項か」「どの数字を採用するか」の見極めそのものが仕事の核心になり、言葉に落とし込んだ指示書がすぐに追いつかなくなる。三つ目が崩れると、出力のたびに受け取り側の使い方が変わり、そもそも自動化する意味が薄れる。三条件がそろう作業ほど、指示の型がそのまま効く。

逆に、届くファイルの形が毎回違う、あるいは「どれを重要とみなすか」が案件ごとの判断に依存する仕事は、ルールを言葉に固定しきれず、結局は人が見た方が早い。たとえば取引先ごとに書式がまちまちな見積書の突き合わせや、クレーム対応の優先順位づけのように、判断基準そのものが状況次第で変わる仕事は、CLAUDE.md にどれだけルールを書き足しても穴が残る。「型があるか」を先に見極め、型がある仕事から自作していくのが遠回りに見えて早い。

対象が変わっても、片づけたい仕事を言葉にする手順は変わらない。

ターミナルに毎回打ち込むのが心細いなら、入り口を変える手もある。Claude Code は VS Code 拡張としても動き、エディタのチャットパネルから同じ指示を投げられる。コマンドを覚えなくても、フォルダを開いてパネルに「この議事録を要約して」と打つだけで済む。ターミナルの黒い画面に身構えていた人ほど、この入り口の方が続く。

請求書で覚えた型は、請求書のためだけのものではなかった。今日フォルダを一つ開いて、そこにたまっている繰り返し作業に「これも言葉で説明できるか」と問うてみる。入力の置き場所が決まっているか、手順を言葉にできるか、出力の形が毎回同じか——この三つに照らして説明できたなら、それはもう自作できる仕事だ。