設計
この連載では、確定申告の自動化を部品ごとに見てきました。
証憑の保存規約（第 2 回）
API と UI の役割分担（第 3 回）
領収書の取得手法（第 4 ・5 回）
最後にこれらを 1 つの手順にまとめます。目指すのは、ユーザーが「月次締めして」と言うだけで月の経理が終わる状態です。
ただし、単に手順を並べればいいわけではありません。順序には意味があり、人に戻すべき場所があります。
月次ルーチンを skill に落とすときの手順の順序の決め方
「人に戻すポイント」をどこに置くかの判断基準
skill から別の skill を参照させて重複を避ける書き方
実行のたびに skill を育てる運用
レポートに必ず入れるべき項目
定型作業を Claude Code の skill に落としたい人
「skill を書いたが、毎回同じところで詰まる」人
LLM に任せる範囲と人が判断する範囲の線引きを考えている人
Claude Code の skill（.claude/skills/<name>/SKILL.md）の基本を知っている
連載の第 1 回を読んで、台帳・実行系・手順の 3 層構成を把握している
月次締めの手順は 7 ステップあります。順番はこうです。
| # | 手順 | なぜこの位置か |
|---|---|---|
| 1 | 対象月の全体把握 | 何があるか知らないと見積もれない。読み取り専用で安全 |
| 2 | 私用支出の振替 | 先にやると、領収書収集の対象が減る |
| 3 | 重複チェック | 重複を残したまま領収書を添付するとやり直しが増える |
| 4 | 領収書の取得と添付 | 一番重い工程。対象が確定してからやる |
| 5 | 家事按分の計上 | 同期外の計上なので独立している |
| 6 | 同期外の経費の確認 | 人への質問。機械作業が終わってからまとめて聞く |
| 7 | レポート | 結果と宿題を残す |
順番を決めているのは、依存関係だけではありません。間違えたときのやり直しコストです。
例えば重複チェック（#3）を領収書添付（#4）のあとにやるとどうなるか。重複した取引にも領収書を添付してしまい、削除すると添付もやり直しになります。先にチェックしておけばこの手戻りは起きません。
安い作業を先に、高い作業を後に。これが順序設計の原則です。
全自動を目指さないことは第 1 回で書きました。では、どこで人に戻すか。
基準は 3 つです。
不可逆なとき。 取引の削除や大きな科目変更は、必ず明示の承認を取ります。skill にはこう書いてあります。
削除・大きな科目変更は必ずユーザーの明示承認を得る
先例がないとき。 台帳にない支払い先が出てきたら、推測で分類せずにリスト化して確認します。これを書いておかないと、LLM は親切心で勝手に分類します。分類を間違えると帳簿が黙って歪みます。
情報が人側にしかないとき。 「今月、私用カードや現金で払った事業経費はある？」は、データをいくら見ても分かりません。これは聞くしかない。
この 3 つ目が実は重要です。自動化の設計は、「データに存在しない情報をどう拾うか」を含めて初めて完成する。聞くタイミングを手順に埋め込んでおくと、聞き忘れがなくなります。
月次締めの中には領収書収集が含まれます。しかし収集は単体でも呼ばれます（「先月分の領収書取って」）。
ここで手順をコピペすると、片方だけ更新されて矛盾します。
解決策は単純で、参照だけ書くことです。
### 4. 領収書の取得と添付
fetch-receipts skill の「ベンダー別の確立済み手法」に従って全ベンダーを回収する。
優先順: ①メールPDF添付系 ②決済ポータル系 ③Web DL 系 ④HTML→PDF 化が必要なもの
手順の本体は収集側の skill にだけあり、月次締め側には「どの順番で回るか」だけがあります。役割が重ならないので、どちらを直すべきかも迷いません。
同じ発想で、判断基準は台帳を参照させます。私用判定のパターンは skill ではなく台帳に書き、skill からは「台帳の該当項目に従う」と指示する。
skill は書いて終わりではありません。むしろ、回すたびに育てるのが本体です。
実際にこのプロジェクトの skill には、事故を踏んでから追加された行がいくつもあります。
同期明細を API で登録して二重計上した → 「登録は必ず UI から」
ダウンロード失敗時に無関係なファイルを移動した → 「最新ファイルを掘む実装は禁止」
連続ダウンロードが黙って止まった → 「DL 後は必ずファイル存在を確認」
これらはすべて、実際に壊してから書かれたものです。事前に思いつくことはできませんでした。
だから運用ルールとして、事故を踏んだら必ず skill に 1 行追加すると決めています。そのときの書き方にもコツがあります。
禁止事項だけを書かない。理由と代替手段をセットで書く。 「これをするな」だけだと、別の状況で同じ失敗をします。「なぜダメか」「ではどうするか」があって初めて守られます。
最後のステップがレポートです。ここに必ず入れると決めているのは 4 項目です。
添付できた件数と金額
取得できなかったもの（理由付き）
振替・修正した取引
要ユーザー判断で保留した項目
2 つ目が一番大事です。自動化は必ず何かを取りこぼします。それを黙っていると、完全に終わったと見えて実は欠けている状態になります。これは帳簿では致命的です。
「メールなし」「再認証が必要」「私用と判断」のように理由を添えておけば、ユーザーは次に何をすればよいか即座に判断できます。
さらに、新しい支払い先が出たら台帳に追記するまでを手順に含めています。これを入れておくと、台帳が毎月自然に育ちます。
第 4 回で書いたとおり、領収書メールのリンクは約 30 日で失効します。だから月次締めは月初に回すのが最適です。
この理由を、skill の先頭に書いてあります。
対象月（デフォルト: 前月）の経理を締める月次ルーチン。毎月月初の実行を想定
（領収書メールのリンクが 30 日で失効するため、月初実行が最も効率的）
手順の先頭にあるのは「何をするか」だけではありません。「いつやるかと、その理由」があります。
これは未来の自分へのメッセージです。運用は必ず崩れますが、理由が残っていれば戻し方が分かります。
手順の順序は「間違えたときのやり直しコスト」で決める。安い作業を先に、高い作業を後に
人に戻すのは「不可逆」「先例なし」「データにない情報」の 3 ケース
聞くタイミングを手順に埋め込む。データに存在しない情報は、聞く手順がないと永遠に拾えない
skill 間は参照でつなぐ。手順の本体をコピペしない。片方だけ更新されて矛盾する
事故を踏んだら必ず 1 行追加する。禁止事項だけでなく理由と代替手段をセットで
レポートに「できなかったこと」を必ず入れる。黙ると「完了した」と誤認される
「いつやるかとその理由」を skill の先頭に書く。運用が崩れたときの戻し方になる
月次ルーチンの順序は依存関係だけでなく、失敗したときのやり直しコストで決める
人に戻すのは「不可逆な操作」「台帳に先例がない」「データに存在しない情報」の 3 ケース
skill 同士は参照でつなぎ、判断基準は台帳に逆引きさせる。重複を作らない
skill は書いて終わりではなく、事故のたびに 1 行ずつ育てるもの
レポートには「できなかったことを理由付きで」必ず入れる。黙ると欠けに気づけない
自動化の品質は、コードの量ではなく過去の失敗がどれだけ手順に戻っているかで決まる
月次締めを skill にする（本記事）
