【設計】月次締めを skill にする — 定型作業を「一言」に畳む設計（確定申告自動化 第6回・完）

概要: 連載の最終回。ここまでの回で整理した部品を、「月次締めして」の一言で回る 1 つの skill にまとめます。順序を何で決めるか、判断を人に戻すポイントをどこに置くか、そして skill をどう育てるか。自動化の品質は「過去の失敗がどれだけ手順に戻っているか」で決まります。

はじめに#

この連載では、確定申告の自動化を部品ごとに見てきました。

• 証憑の保存規約（第 2 回）
• API と UI の役割分担（第 3 回）
• 領収書の取得手法（第 4 ・5 回）

最後にこれらを 1 つの手順にまとめます。目指すのは、ユーザーが「月次締めして」と言うだけで月の経理が終わる状態です。

ただし、単に手順を並べればいいわけではありません。順序には意味があり、人に戻すべき場所があります。

1. 順序は「失敗コスト」で決める#

月次締めの手順は 7 ステップあります。順番はこうです。

順番を決めているのは、依存関係だけではありません。間違えたときのやり直しコストです。

例えば重複チェック（#3）を領収書添付（#4）のあとにやるとどうなるか。重複した取引にも領収書を添付してしまい、削除すると添付もやり直しになります。先にチェックしておけばこの手戻りは起きません。

安い作業を先に、高い作業を後に。これが順序設計の原則です。

2. 人に戻すポイントを設計する#

全自動を目指さないことは第 1 回で書きました。では、どこで人に戻すか。

基準は 3 つです。

不可逆なとき。 取引の削除や大きな科目変更は、必ず明示の承認を取ります。skill にはこう書いてあります。

削除・大きな科目変更は必ずユーザーの明示承認を得る

先例がないとき。 台帳にない支払い先が出てきたら、推測で分類せずにリスト化して確認します。これを書いておかないと、LLM は親切心で勝手に分類します。分類を間違えると帳簿が黙って歪みます。

情報が人側にしかないとき。 「今月、私用カードや現金で払った事業経費はある？」は、データをいくら見ても分かりません。これは聞くしかない。

この 3 つ目が実は重要です。自動化の設計は、「データに存在しない情報をどう拾うか」を含めて初めて完成する。聞くタイミングを手順に埋め込んでおくと、聞き忘れがなくなります。

3. skill から skill を参照させる#

月次締めの中には領収書収集が含まれます。しかし収集は単体でも呼ばれます（「先月分の領収書取って」）。

ここで手順をコピペすると、片方だけ更新されて矛盾します。

解決策は単純で、参照だけ書くことです。

### 4. 領収書の取得と添付
fetch-receipts skill の「ベンダー別の確立済み手法」に従って全ベンダーを回収する。
優先順: ①メールPDF添付系 ②決済ポータル系 ③Web DL 系 ④HTML→PDF 化が必要なもの

手順の本体は収集側の skill にだけあり、月次締め側には「どの順番で回るか」だけがあります。役割が重ならないので、どちらを直すべきかも迷いません。

同じ発想で、判断基準は台帳を参照させます。私用判定のパターンは skill ではなく台帳に書き、skill からは「台帳の該当項目に従う」と指示する。

4. 実行のたびに skill を育てる#

skill は書いて終わりではありません。むしろ、回すたびに育てるのが本体です。

実際にこのプロジェクトの skill には、事故を踏んでから追加された行がいくつもあります。

• 同期明細を API で登録して二重計上した → 「登録は必ず UI から」
• ダウンロード失敗時に無関係なファイルを移動した → 「最新ファイルを掴む実装は禁止」
• 連続ダウンロードが黙って止まった → 「DL 後は必ずファイル存在を確認」

これらはすべて、実際に壊してから書かれたものです。事前に思いつくことはできませんでした。

だから運用ルールとして、事故を踏んだら必ず skill に 1 行追加すると決めています。そのときの書き方にもコツがあります。

禁止事項だけを書かない。理由と代替手段をセットで書く。 「これをするな」だけだと、別の状況で同じ失敗をします。「なぜダメか」「ではどうするか」があって初めて守られます。

5. レポートには「できなかったこと」を必ず入れる#

最後のステップがレポートです。ここに必ず入れると決めているのは 4 項目です。

• 添付できた件数と金額
• 取得できなかったもの（理由付き）
• 振替・修正した取引
• 要ユーザー判断で保留した項目

2 つ目が一番大事です。自動化は必ず何かを取りこぼします。それを黙っていると、完全に終わったと見えて実は欠けている状態になります。これは帳簿では致命的です。

「メールなし」「再認証が必要」「私用と判断」のように理由を添えておけば、ユーザーは次に何をすればよいか即座に判断できます。

さらに、新しい支払い先が出たら台帳に追記するまでを手順に含めています。これを入れておくと、台帳が毎月自然に育ちます。

6. 月初に回す理由を先頭に書いておく#

第 4 回で書いたとおり、領収書メールのリンクは約 30 日で失効します。だから月次締めは月初に回すのが最適です。

この理由を、skill の先頭に書いてあります。

対象月（デフォルト: 前月）の経理を締める月次ルーチン。毎月月初の実行を想定
（領収書メールのリンクが 30 日で失効するため、月初実行が最も効率的）

手順の先頭にあるのは「何をするか」だけではありません。「いつやるかと、その理由」があります。

これは未来の自分へのメッセージです。運用は必ず崩れますが、理由が残っていれば戻し方が分かります。

Tips#

• 手順の順序は「間違えたときのやり直しコスト」で決める。安い作業を先に、高い作業を後に
• 人に戻すのは「不可逆」「先例なし」「データにない情報」の 3 ケース
• 聞くタイミングを手順に埋め込む。データに存在しない情報は、聞く手順がないと永遠に拾えない
• skill 間は参照でつなぐ。手順の本体をコピペしない。片方だけ更新されて矛盾する
• 事故を踏んだら必ず 1 行追加する。禁止事項だけでなく理由と代替手段をセットで
• レポートに「できなかったこと」を必ず入れる。黙ると「完了した」と誤認される
• 「いつやるかとその理由」を skill の先頭に書く。運用が崩れたときの戻し方になる

まとめ#

• 月次ルーチンの順序は依存関係だけでなく、失敗したときのやり直しコストで決める
• 人に戻すのは「不可逆な操作」「台帳に先例がない」「データに存在しない情報」の 3 ケース
• skill 同士は参照でつなぎ、判断基準は台帳に逆引きさせる。重複を作らない
• skill は書いて終わりではなく、事故のたびに 1 行ずつ育てるもの
• レポートには「できなかったことを理由付きで」必ず入れる。黙ると欠けに気づけない
• 自動化の品質は、コードの量ではなく過去の失敗がどれだけ手順に戻っているかで決まる

連載一覧#

1. プロジェクト全体像 — UI を作らず skill だけで回す
2. 電子帳簿保存法の検索要件をファイル名規約だけで満たす
3. 会計 API とブラウザ自動操作の役割分担
4. メールリンクの 30 日失効と戦う
5. ブラウザ自動操作の落とし穴集
6. 月次締めを skill にする（本記事）