freee会計の未処理明細を月1回の消込便に。毎月5日7:30・3区分・上限15件で人に回す設計

おはようございます。まさきんです。

freee会計の未処理明細がたまって、消込が進まない。そんな状態が僕の手元でしばらく続いていました。そこで月1回の自動便にする設計を決めたので、決めた内容をメモしておきます。

※記事公開時点の情報です。最新の条件は公式サイトでご確認ください。

未処理明細が6回動かなかった

僕は小さく続けている副業の帳簿を、freee会計で付けています。口座やカードの明細は自動で取り込まれます。あとは確認して登録するだけ、のはずでした。

ところが未処理の明細が、18件ほど残ったままになっていました。毎週の確認で件数を見ています。それが6回続けて動いていませんでした。

毎週見ているのに減らない。これは「忙しかった」では説明がつかないと思いました。見る場はあるのに、手が動いていないわけです。

手が止まる原因は迷う明細

止まっている理由は、件数の多さではないのかもしれません。僕はそう考えました。

18件のなかには、すぐ登録できそうな明細もあります。一方で、開くたびに考え込む明細も混ざっています。事業の支出なのか家の支出なのか。領収書はどこにあるのか。そういう明細ですね。

迷う1件が先頭にあると、そこで手が止まります。その後ろの簡単な明細まで、一緒に残ってしまう。なので混ぜたまま並べているのがよくないのかな、と考えました。

明細の仕分けについては、モールのカード明細にテナント名が出ないときの仕分けの記事もあります。今回はその手前の、順番と分け方の話です。

既存の照合の仕組みとの役割分担

明細とメールをAIで突き合わせる仕組みは、すでに別の記事にまとめています。副業の経費をAIで照合する仕組みです。照合のやり方はそちらに譲ります。

この記事で扱うのは、その外側です。いつ動かすのか。どこで動かすのか。どこから先を人に回すのか。この3つを決めた話になります。

照合の仕組みがあっても、動かすきっかけが「気が向いたとき」だと続きません。僕の6回がまさにそうでした。なので定期便の形にします。

記帳は日々が原則

先に前提を確かめておきます。月1回にまとめてよいのか、という点です。

国税庁の「暮らしの税情報」には、こう書かれています。所得を正しく計算して申告するには、日々の取引の状況を記帳する必要がある。帳簿や書類は一定期間保存する必要がある。原則はあくまで日々の記帳ですね。

なので僕は「月1回の記帳でよい」とは考えていません。明細の取り込みと週次の確認は、これまでどおり続けます。月1回にするのは、迷う明細について判断する場のほうです。

月次の消込便で決めたこと

決めたことを先に並べます。

1. 置き場所は自宅のMacにする
2. 実行は毎月5日の朝7:30。初回は来月5日
3. 未処理の明細を3区分に分ける
4. 確定できる分は、月1件のまとめタスクにする
5. 迷う明細とローン返済は、明細ごとに1タスクにする
6. 明細のIDで重複を防ぎ、月15件を上限にする
7. 会計ソフトへの登録そのものは人が行う

どれも「決めた」段階です。実装はまだで、動かした結果もありません。そこは最後の予定の節に書きます。

明細の3区分

設計の中心は、明細の分け方です。

確定できる分は、1件ずつタスクにしません。まとめて1件にします。迷いのない明細を10個のタスクに割ると、タスクの一覧が埋まるだけだからです。

逆に迷う明細は、1件ずつに分けます。「この1件をどうするか」だけを考えれば済む形にしたい。前後に別の明細が並んでいると、また手が止まりそうです。

ローン返済を別の区分にしたのは、他の支出と確認の中身が違うからです。毎月かならず来るものでもあります。迷う明細に混ぜず、決まった形のタスクにしておきます。

重複防止と月15件の上限

1件ずつタスクにすると、心配が2つ出てきます。

ひとつは重複です。先月のタスクが残ったまま今月の便が走ると、同じ明細のタスクがもう1つできてしまいます。なので明細のIDを目印にします。同じIDのタスクがすでにあれば、新しく作りません。

もうひとつは量です。迷う明細が一度に何十件もタスクになると、それだけで開く気がなくなります。そこで1タスクずつ起こす分は、月15件 を上限にしました。

15という数字に、深い根拠はありません。タスクの一覧が埋まらないための目安です。動かしてみて合わなければ見直すつもりです。

登録は人が行う線引き

AIに任せるのは、照合と提案までにしました。会計ソフトへの登録そのものは、僕が画面で行います。

理由は2つあります。ひとつは、freee会計の考え方と合っているからです。公式ヘルプでは、明細に対して推測された内容を確認したうえで登録する流れが案内されています。

自動登録ルールにも2種類あります。公式ヘルプによると、設定した内容を取引として自動入力するか自動登録するかを選べます。前者が「推測」で、後者が「登録」です。僕の3区分は、この使い分けをタスクの形に写したものかもしれません。

もうひとつの理由は、APIの事情です。APIで取引を作っても、明細の側は未処理のまま残る。利用者からの報告では、そういう挙動があるとされています。今も同じかどうかは、僕は確かめていません。

なので「APIだけで消込を終わらせる」前提は置きませんでした。最後のひと押しを人が画面でやる設計なら、この点に左右されにくいと考えています。

置き場所は自宅のMac

便を動かす場所は、自宅のMacに決めました。クラウド側の定期タスクは作りません。

流れは3段です。macOSのlaunchdが時刻になったら起こす。起こされたシェルスクリプトが準備をする。そのなかでClaude Codeをヘッドレスで実行する。ヘッドレスというのは、対話の画面を出さずに claude -p で1回ぶんの指示を流す使い方です。

Appleの開発者向け資料には、launchdの時刻指定について説明があります。予定の時刻にスリープしていた場合は、復帰したときに実行される。電源が切れていた場合は、次の指定時刻まで実行されない。そういう内容でした。

ただ、この資料は更新が古いアーカイブです。今のmacOSで同じ動きになるかは、手元で確かめる必要があります。毎月5日という指定の書き方も、実装のときに確認します。

定期実行の制約については、Cloudflare Workers無料枠のCron Triggerの上限の記事もあります。どこで動かすかは、毎回いちばん先に効いてくる気がします。

置き場所を先に決める理由

この設計を詰めている途中で、ひとつつまずきました。

クラウド側の作業環境から、自宅Macのフォルダが見えなかったんですね。今ある仕組みがどうなっているかを確かめたいのに、そこへ届きません。確認は別の経路で行いました。

ここで学んだのは順番です。置き場所を先に決めないと、確認すら進みません。何を自動化するかより先に、どこから何が見えるかを押さえる。次に似たものを作るときも、そこから始めようと思います。

こういう「仕組みの置き場所」の見直しは、家計の固定費でも同じかもしれません。毎月かならず出ていく通信費などは、一度決めた形のまま動かしていないことが多いです。

月次のスケジュール

1か月の流れは、こう置きました。

5日は月初の少しあとです。朝の7:30に走れば、その日のうちにタスクを開けます。

帳簿の保存年数と家事関連費

迷う明細の多くは、突き詰めると2つの問いに行き着きます。証拠は残っているか。事業の支出と言えるか。

証拠のほうは、保存期間が決まっています。国税庁の「暮らしの税情報」(令和8年度版)では、青色申告の場合の保存期間が表になっています。

領収書が見つからない明細を「判断が要る」に入れたのは、このためです。あとで探せばよい、と流してよいものではないと感じています。

事業の支出と言えるかのほうは、家事関連費の考え方が関わります。国税庁のタックスアンサーによると、家事上の費用は必要経費になりません。ただ、ひとつの支出が家事と業務の両方にかかわることがあります。それが家事関連費です。

必要経費になるのは、限られた部分だけです。取引の記録などに基づいて、業務に直接必要だったことが明らかに区分できる金額。そう書かれています。ここはAIの提案だけで決めず、人が見る区分に置きました。

これからの作業

残っている作業は2つです。

1. 実装して、今月分をdry-runで流す(月末まで)
2. Macの側からメールの領収書を読む経路があるかを、実装の最初に確かめる

dry-runは、タスクを実際には起こさずに結果だけを見る試し方です。3区分の分かれ方が自分の感覚と合うかを、本番の前に見ておきます。

2つ目を最初に持ってきたのは、置き場所でつまずいた経験からです。照合にはメールの領収書が要ります。Macから読めないとわかったら、設計のほうを直すことになります。

初回の便は来月5日の予定です。動かした結果は、数字が取れてから別に書きます。

よくある失敗・落とし穴

迷う明細と簡単な明細を混ぜたまま並べる。 僕の6回はこれだったのではと見ています。先頭の1件で止まると、後ろの簡単な明細まで残ります。

全部を1件ずつタスクにする。 迷いのない明細まで分けると、タスクの数に圧倒されます。確定できる分は1件にまとめる形にしました。

置き場所を後回しにする。 どこから何が見えるかを確かめないまま設計すると、確認の段階で止まります。

月1回の便を「月1回の記帳」と取り違える。 公式の原則は日々の記帳です。月次の便は判断の場であって、記帳の頻度を下げる話ではありません。

APIだけで終わる前提で組む。 登録のあとに明細が未処理で残るという報告があります。人が画面で仕上げる余地を残しておくほうが安心だと思います。

• 未処理の明細が何件あり、何週間動いていないかを数えたか
• 止まっている原因が件数なのか、迷う明細なのかを見分けたか
• 便を動かす場所から、必要なファイルとメールが見えるかを確かめたか
• 確定できる分と判断が要る分を、別の形のタスクにしているか
• 同じ明細のタスクが二重にできない目印(明細のIDなど)を決めたか
• 1か月に人へ回す件数の上限を決めたか
• 会計ソフトへの登録を誰が行うかの線引きを決めたか
• 日々の記帳と週次の確認は、これまでどおり続ける前提になっているか

よくある質問

Q. 月1回の消込でも問題ないのですか?

国税庁の表現は「日々の取引の状況を記帳」です。月1回でよいと書かれた公式の記述を、僕は見つけていません。なので取り込みと週次の確認は続けます。月1回にするのは、迷う明細を判断する場だけです。

Q. なぜ毎月5日の朝7:30なのですか?

月初の少しあとの朝、という置き方です。朝に走れば、その日のうちにタスクを開けます。合わなければ動かしてから見直すつもりです。

Q. 自動登録ルールだけでは足りないのですか?

決まった形の明細には、ルールがよく合うと思います。ただ、僕の手元で残っていたのは迷う明細でした。ルールで決めきれないものを、人が1件ずつ見る場が必要だと感じています。

Q. AIに登録まで任せないのはなぜですか?

公式ヘルプの流れが、推測を確認してから登録する形だからです。事業か家事かの判断も、最後は自分で持ちたいと考えました。AIは照合と提案までにしています。

Q. 自宅のMacが寝ていたら、便は動きますか?

Appleの資料では、スリープ中に予定時刻が来た場合は復帰時に実行されるとされています。電源が切れていた場合は、次の指定時刻まで実行されません。古い資料なので、今のmacOSでの動きは実装のときに確かめます。

Q. 月15件の上限はどう決めたのですか?

タスクの一覧が埋まらないための目安です。根拠のある数字ではありません。動かしてから調整します。

Q. 効果はどのくらい出ましたか?

まだわかりません。この記事は設計を決めた段階のメモです。初回の便は来月5日の予定なので、結果はそのあとに書きます。

Q. 経費にできるかどうかは、この仕組みで決まりますか?

決まりません。仕組みがやるのは、明細を分けて人に回すところまでです。税務の最終的な判断は、税理士や税務署に確認してください。

参考にした公式情報

• 記帳や帳簿等保存・青色申告(国税庁 暮らしの税情報)
• No.2070 青色申告制度(国税庁)
• No.2210 必要経費の知識(国税庁)
• 自動で経理から取引を登録する(freeeヘルプセンター)
• 明細の自動登録ルールを設定する(freeeヘルプセンター)
• Scheduling Timed Jobs(Apple Developer ドキュメントアーカイブ)
• Run Claude Code programmatically(Claude Code ドキュメント)

まとめ

未処理の明細が動かなかったのは、迷う明細が混ざっていたからだと見ています。なので確定できる分はまとめて、迷う明細だけを1件ずつ人に回す形にします。毎月5日の朝7:30に、自宅のMacで動かす予定です。

まだ設計を決めただけで、動かしてはいません。たまった明細を前に手が止まっているなら、まず「迷う明細は何件か」を数えてみるのはいかがでしょうか。

毎月かならず出ていくお金も、同じように一度分けて眺めると見え方が変わるかもしれません。通信費などの固定費も、よければ明細を開いてみてください。

本記事にはアフィリエイト広告を含みます。当サイトのリンクを経由して商品・サービスへお申し込みいただいた場合、提携先企業から成果報酬を受け取ることがあります。 また、運営者は楽天グループに所属する社員であり、紹介プログラムを通じた報酬を受け取る場合があります。記事内容・評価は広告の有無にかかわらず、運営者の実体験と調査に基づき作成していますが、 上記の関係性をご理解のうえお読みください。詳しくは免責事項・アフィリエイト表記をご覧ください。

楽天モバイルの通信エリア・電波状況について気になることがある方は、公式の電波改善・調査依頼フォームからご相談いただけます。