設計
個人事業主として開発の仕事をしていると、経費のほとんどが SaaS のサブスクになります。しかもその領収書は、メールの中・各サービスの請求ページ・決済代行のポータルにバラバラに散らばっています。
しかも 2024 年からは電子帳簿保存法で、メールや Web で受け取った領収書は電子データのまま保存することが義務になりました。印刷してファイルに綴じる、はもう逆に NG です。
この作業を手でやると、毎月こうなります。
カード明細を見て、この引き落としは何の支払いかを思い出す
各サービスにログインして領収書 PDF を拾う
会計ソフトにアップロードして、対応する取引に 1 件ずつ紐づける
事業と私用が混ざった支出を仕分ける
月 60 件もあれば半日仕事です。しかも毎月同じ手順。こういう「定型だが判断も入る」作業は、まさに Claude Code の skill 向きです。
この連載では、実際に運用している自動化プロジェクトを題材に、設計と実装の細かい話を短編で並べていきます。
確定申告周りの何を自動化できて、何を人に残すべきか
UI を作らないという割り切りが、個人の業務自動化で合理的な理由
台帳（docs）・実行系（scripts）・手順（skills）の 3 層構成
skill をどの粒度で分割するか（月次・単発・年次の軸）
お金を扱う自動化で「壊さない」ためのガードの入れ方
Claude Code で自分の業務を自動化したい人
個人事業主・フリーランスで経理に時間を取られている人
「アプリを作るほどではないけど、毎回手でやるのは辛い」規模の作業を抱えている人
Claude Code の skill（.claude/skills/<name>/SKILL.md）の基本を知っている
会計 SaaS は freee を使用（API が公開されているものなら設計は流用可能）
Python 3 と curl が使える環境
まず業務フローを並べます。青色の部分が自動化対象です。
カード・口座の明細（会計 SaaS が自動同期）
|
v
[1] 明細を仕分ける（事業経費 / 私用 / 利息）
|
v
[2] 対応する領収書を集める（メール / Web ポータル）
|
v
[3] 規約通りのファイル名で保存する（電帳法の検索要件）
|
v
[4] 会計 SaaS にアップロードし、取引に添付する
|
v
[5] 家事按分・私用振替を計上する
|
v
[6] 年末に集計し、証憑の抜けを監査する
ポイントは、このフローには「機械的な作業」と「判断」が交互に現れることです。PDF を拾ってリネームしてアップロードするのは完全に機械作業ですが、「この支出は事業か私用か」は判断です。
だから「全部自動」を目指すのではなく、機械作業を全部引き受けて、判断を人に見やすく提示する形に設計しています。
最初に決めたのが「UI は作らない」という方針です。理由は 3 つあります。
利用者が 1 人しかいない。 自分だけが使うツールに画面を作るのは、本体より UI の保守の方が高くつきます。
入力の形が毎回違う。 「先月分やって」「このレシート経費にして」「今年いくら経費使った？」は、すべて形の違うリクエストです。これをフォームで表現しようとすると画面が増え続けますが、自然言語ならそのまま渡せます。
例外処理が本体。 領収書収集は「リンクが失効していた」「ポータルの構造が変わった」「再認証を求められた」の連続です。これを全部分岐として実装するのは現実的ではなく、「手順を文章で書いておいて、その場で判断させる」方が壊れにくい。
つまりこのプロジェクトの成果物は、アプリではなく skill（手順書）とスクリプト（部品）の集合です。
実際の構成はこうなっています。
.
├─ CLAUDE.md # プロジェクトの前提と運用ルール（毎回読まれる）
├─ .claude/skills/ # 手順：人が呼ぶ単位
│ ├─ monthly-close/ # 月次締め（一括）
│ ├─ fetch-receipts/ # 領収書の取得と添付
│ ├─ sort-txns/ # 未登録明細の仕分け
│ ├─ add-receipt/ # 紙レシート 1 枚を経費化
│ └─ year-end/ # 年次集計・監査
├─ scripts/ # 実行系：部品
│ ├─ freee_api.py # 会計 API の薄い CLI ラッパー
│ ├─ annual_report.py # 年間集計
│ └─ tax_estimate.py # 納税額の試算
├─ docs/ # 台帳：判断基準の正
│ ├─ vendors.md # ベンダー台帳と私用判定ルール
│ └─ 家事按分根拠.md # 按分割合の根拠（税務調査対応）
└─ receipts/ # 証憑の正本（電帳法）
└─ 2026/01/ …
見てほしいのは、コード（scripts）より文書（docs / skills）の方が多いことです。これは意図したバランスです。
このプロジェクトは役割を 3 つに分けています。
| 層 | 場所 | 役割 | 変更頻度 |
|---|---|---|---|
| 台帳 | docs/ | 判断基準の「正」。支払い先の分類、私用判定ルール、按分割合の根拠 | 新しい支払い先が出たとき |
| 実行系 | scripts/ | API を叩く・集計する部品。出力はすべて JSON | ほとんど変わらない |
| 手順 | .claude/skills/ | 人が呼ぶ単位の作業手順。台帳を参照し、実行系を呼ぶ | 運用しながら頻繁に育てる |
この分け方の効果は、知識の更新先が 1 ヶ所に定まることです。
例えば「ある定期購入は私用だと確定した」という知見は、skill に書くと複数の skill に重複します。台帳側に 1 行足して、skill からは「台帳を見ろ」と参照させる。これだけで矛盾が激減します。
実際、プロジェクトの CLAUDE.md にはこう書いてあります。
**ベンダー台帳・各種 ID・私用判定ルールは docs/vendors.md が正** — 作業前に必ず参照
「どこが正か」を明記するのは、人間向けのドキュメントよりも LLM 向けの指示で効きます。
skill を機能単位で切ると、1 回の作業で何個も呼ぶことになって使いづらくなります。このプロジェクトでは 「人がどう声をかけるか」を単位に切っています。
| skill | 呼ばれ方（人の発話） | 粒度 |
|---|---|---|
| monthly-close | 「月次締めして」「先月分の経理やって」 | 月次の全工程を包含するオーケストレータ |
| fetch-receipts | 「◯月分の領収書取って」 | 収集と添付だけ。月次からも呼ばれる |
| sort-txns | 「未登録明細を仕分けて」 | 仕分けだけ。月中に単発で走る |
| add-receipt | 「このレシート経費にして」 | 1 枚単位。最小の入口 |
| year-end | 「確定申告の準備」「今年いくら経費使った？」 | 年次。集計と監査 |
重要なのは skill 同士が参照し合ってよいという点です。monthly-close の中には「領収書の取得は fetch-receipts skill のベンダー別の手順に従う」と書いてあり、手順の本体を重複させていません。
会計データは壊すと痛い。しかも、壊れたことに気づくのが確定申告の直前だったりします。そこで、skill には必ず次の 3 つを入れています。
不可逆な操作は明示承認を取る。 取引の削除や大きな勘定科目の変更は、必ず人に確認してからやると skill に明記しています。
判断に迷ったら勝手に処理しない。 台帳にない支払い先が出てきたら、推測で仕訳せずにリスト化して確認する。これを書いておかないと、LLM は親切心で勝手に分類してしまいます。
実行後は必ず検証する。 添付や更新のあとは必ず取得系の API を叩いて、金額・ステータス・添付状態が意図通りか確かめる。「エラーが出なかった」を成功と見なさない。
この 3 つは、いずれも実際に事故を踏んでから追加されたものです。とくに 2 つ目は重要で、分類を間違えると帳簿が黙って歪みます。
以降の回では、実際に踏んだ設計問題を 1 テーマずつ短編で扱います。
第 2 回: 電子帳簿保存法の検索要件を「ファイル名規約」だけで満たす
第 3 回: 会計 API と UI 操作の役割分担 — 同期明細は必ず UI から登録する
第 4 回: メールリンクの失効と戦う — 決済ポータルから PDF の URL を組み立てる
第 5 回: ブラウザ自動操作の落とし穴集
第 6 回: 月次締めを skill にする — 定型作業を「一言」に畳む設計
自分 1 人が使う自動化に UI を作らない。自然言語がそのまま入力フォームになるのが skill の最大の利点
判断基準は skill ではなく台帳（docs）に置く。skill に直書きすると複数の skill に重複し、やがて矛盾する
CLAUDE.md に「どこが正か」を明記する。人間向けの説明より、参照先を指定する一文の方が効く
skill の粒度は「人がどう声をかけるか」で切る。機能単位で切ると呼び出しが面倒になる
実行系の出力は JSON に統一する。LLM が扱いやすく、python3 -c でその場の集計もできる
事故を踏んだら必ず skill に 1 行追加する。自動化の品質は「過去の失敗がどれだけ手順に戻っているか」で決まる
確定申告周りの作業は「機械作業」と「判断」が交互に現れる。全自動を目指さず、機械作業を引き受けて判断を人に提示する
利用者が 1 人なら UI は作らない。成果物は skill（手順）とスクリプト（部品）の集合でよい
台帳（docs）・実行系（scripts）・手順（skills）の 3 層に分けると、知識の更新先が 1 ヶ所に定まる
skill の粒度は機能ではなく「呼ばれ方」で切る。skill 同士の参照を許して手順の重複を避ける
お金を扱う自動化には「不可逆操作は承認」「迷ったら処理しない」「実行後に検証」の 3 つを必ず入れる
