【設計】UIを作らず Claude Code の skill だけで確定申告を自動化する — プロジェクト全体像（確定申告自動化 第1回）

概要: 個人事業主の確定申告に向けた領収書収集・仕訳・証憑管理を、Web UI を一切作らずに Claude Code の skill とスクリプトだけで回しています。本記事はその全体像。台帳（docs）・実行系（scripts）・手順（skills）の 3 層構成、skill の分割粒度、そして「判断を人に残す」設計を整理します。以降の回で個別の設計・実装に踏み込む、そのハブです。

はじめに#

個人事業主として開発の仕事をしていると、経費のほとんどが SaaS のサブスクになります。しかもその領収書は、メールの中・各サービスの請求ページ・決済代行のポータルにバラバラに散らばっています。

しかも 2024 年からは電子帳簿保存法で、メールや Web で受け取った領収書は電子データのまま保存することが義務になりました。印刷してファイルに綴じる、はもう逆に NG です。

この作業を手でやると、毎月こうなります。

• カード明細を見て、この引き落としは何の支払いかを思い出す
• 各サービスにログインして領収書 PDF を拾う
• 会計ソフトにアップロードして、対応する取引に 1 件ずつ紐づける
• 事業と私用が混ざった支出を仕分ける

月 60 件もあれば半日仕事です。しかも毎月同じ手順。こういう「定型だが判断も入る」作業は、まさに Claude Code の skill 向きです。

この連載では、実際に運用している自動化プロジェクトを題材に、設計と実装の細かい話を短編で並べていきます。

1. 何を自動化するのか#

まず業務フローを並べます。青色の部分が自動化対象です。

カード・口座の明細（会計 SaaS が自動同期）
        |
        v
  [1] 明細を仕分ける（事業経費 / 私用 / 利息）
        |
        v
  [2] 対応する領収書を集める（メール / Web ポータル）
        |
        v
  [3] 規約通りのファイル名で保存する（電帳法の検索要件）
        |
        v
  [4] 会計 SaaS にアップロードし、取引に添付する
        |
        v
  [5] 家事按分・私用振替を計上する
        |
        v
  [6] 年末に集計し、証憑の抜けを監査する

ポイントは、このフローには「機械的な作業」と「判断」が交互に現れることです。PDF を拾ってリネームしてアップロードするのは完全に機械作業ですが、「この支出は事業か私用か」は判断です。

だから「全部自動」を目指すのではなく、機械作業を全部引き受けて、判断を人に見やすく提示する形に設計しています。

2. なぜ UI を作らないのか#

最初に決めたのが「UI は作らない」という方針です。理由は 3 つあります。

利用者が 1 人しかいない。 自分だけが使うツールに画面を作るのは、本体より UI の保守の方が高くつきます。

入力の形が毎回違う。 「先月分やって」「このレシート経費にして」「今年いくら経費使った？」は、すべて形の違うリクエストです。これをフォームで表現しようとすると画面が増え続けますが、自然言語ならそのまま渡せます。

例外処理が本体。 領収書収集は「リンクが失効していた」「ポータルの構造が変わった」「再認証を求められた」の連続です。これを全部分岐として実装するのは現実的ではなく、「手順を文章で書いておいて、その場で判断させる」方が壊れにくい。

つまりこのプロジェクトの成果物は、アプリではなく skill（手順書）とスクリプト（部品）の集合です。

3. ディレクトリ構成#

実際の構成はこうなっています。

.
├─ 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）の方が多いことです。これは意図したバランスです。

4. 台帳・実行系・手順の 3 層#

このプロジェクトは役割を 3 つに分けています。

この分け方の効果は、知識の更新先が 1 ヶ所に定まることです。

例えば「ある定期購入は私用だと確定した」という知見は、skill に書くと複数の skill に重複します。台帳側に 1 行足して、skill からは「台帳を見ろ」と参照させる。これだけで矛盾が激減します。

実際、プロジェクトの CLAUDE.md にはこう書いてあります。

**ベンダー台帳・各種 ID・私用判定ルールは docs/vendors.md が正** — 作業前に必ず参照

「どこが正か」を明記するのは、人間向けのドキュメントよりも LLM 向けの指示で効きます。

5. skill の分割は「呼ばれ方」で決める#

skill を機能単位で切ると、1 回の作業で何個も呼ぶことになって使いづらくなります。このプロジェクトでは 「人がどう声をかけるか」を単位に切っています。

重要なのは skill 同士が参照し合ってよいという点です。monthly-close の中には「領収書の取得は fetch-receipts skill のベンダー別の手順に従う」と書いてあり、手順の本体を重複させていません。

6. お金を扱う自動化にはガードを入れる#

会計データは壊すと痛い。しかも、壊れたことに気づくのが確定申告の直前だったりします。そこで、skill には必ず次の 3 つを入れています。

不可逆な操作は明示承認を取る。 取引の削除や大きな勘定科目の変更は、必ず人に確認してからやると skill に明記しています。

判断に迷ったら勝手に処理しない。 台帳にない支払い先が出てきたら、推測で仕訳せずにリスト化して確認する。これを書いておかないと、LLM は親切心で勝手に分類してしまいます。

実行後は必ず検証する。 添付や更新のあとは必ず取得系の API を叩いて、金額・ステータス・添付状態が意図通りか確かめる。「エラーが出なかった」を成功と見なさない。

この 3 つは、いずれも実際に事故を踏んでから追加されたものです。とくに 2 つ目は重要で、分類を間違えると帳簿が黙って歪みます。

7. この連載で書くこと#

以降の回では、実際に踏んだ設計問題を 1 テーマずつ短編で扱います。

• 第 2 回: 電子帳簿保存法の検索要件を「ファイル名規約」だけで満たす
• 第 3 回: 会計 API と UI 操作の役割分担 — 同期明細は必ず UI から登録する
• 第 4 回: メールリンクの失効と戦う — 決済ポータルから PDF の URL を組み立てる
• 第 5 回: ブラウザ自動操作の落とし穴集
• 第 6 回: 月次締めを skill にする — 定型作業を「一言」に畳む設計

Tips#

• 自分 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 つを必ず入れる

参考リンク#

• 国税庁: 電子帳簿保存法関係
• Claude Code: Skills
• Claude Code: Settings