Claude Code×freeeの経理エージェント5体。任せたのは検品

freee の MCP サーバーを使えば、Claude Code から freee 会計の API を読み書きできる。それなら記帳を AI に任せられるのではないか。2026年9月、そう考えて経理用のサブエージェントを作り始めた。

最初の調査で、前提が外れた。その年の口座明細1,203件は、すべて処理済みだった。freee の「自動で経理」が、ほぼ全件を勘定科目つきで記帳していた。記帳は、そもそもボトルネックではなかった。

そこで役割を組み直した。AI に任せるのは「代わりに入力すること」ではなく、自動記帳の検品、証憑の突合、税金の試算にした。この記事は、その体制を1か月半回した記録だ。

この記事でわかるのは次の4つ。

• 経理を5体のサブエージェントに分けた構成と、書き込める2体を絞った理由
• 承認なしに freee へ書き込ませない仕組み
• 実際に拾ったもの（口座の資金不足、売上の計上漏れ、予定納税の減額など）
• うまくいかなかったことと、freee API の制約

この記事の対象読者

• freee 会計を使っている個人事業主・フリーランスで、Claude Code も使っている
• 「AI に経理を任せる」と聞いて、まず記帳の自動化を思い浮かべた
• AI に会計データへの書き込み権限を渡すのが怖い

結論：記帳は freee に任せ、AI には「検品」と「先回り」を任せる

AI に期待していたのは入力の手間を減らすことだった。実際に効いたのは、自分が見ていなかった数字を、期限の前に見せてくれることだった。

最初の調査：明細1,203件は、すべて処理済みだった

エージェントを作る前に、freee の実データを API で読んだ。2026年の口座明細は1,203件。その全件が、処理済みを表す status=2 だった。未処理の明細は0件。

freee の「自動で経理」は、銀行やカードの明細を取り込んで、取引先や摘要から勘定科目を推測して記帳する。自分の場合、その推測でほぼ回っていた。ここに AI を足しても、入力の手間はほとんど減らない。

一方で、自動記帳は推測だ。推測が外れていないか、証憑がそろっているか、年末に何が必要か。こうした確認は、誰もしていなかった。AI に任せる価値があるのは、こちらだと判断した。

5体の構成と、書き込めるのを2体に絞った理由

書き込めるのは2体だけにした。誤った記帳は税額に直結し、取り消すのにも手間がかかる。分析と助言しかしないエージェントに、書き込みの権限を渡す理由がない。

権限は、定義の文章で「書き込まないでください」とお願いするのではなく、使えるツールから外している。読み取り専用の3体は、定義の tools: に書き込み用の MCP ツールを入れていない。

---
name: freee-closer
tools: Read, Write, Edit, Bash, mcp__freee-mcp__freee_api_get, mcp__freee-mcp__freee_auth_status
model: sonnet
---

freee_api_get しか持っていないので、指示を取り違えても freee に書き込むことはできない。書き込む2体だけが freee_api_post と freee_api_put を持つ。

モデルは、税金の試算をする freee-tax-advisor だけ opus にしていて、ほかの4体は sonnet だ。

承認なしに書き込ませない仕組み

書き込む2体の定義には、「内容を表で示して承認を得るまで、POST も PUT もしない」と書いた。記帳なら、日付・金額・勘定科目・摘要を表にして見せ、自分が OK と言ってから登録する。

請求書は、さらに一段固くした。請求書は社外に出る書類なので、freee-billing は下書きまでしか作らない。送るのは自分だ。未入金の督促も、文面は作るが、送るのは自分にしている。

自分がやること・決めることは、1枚のノート（対応・判断リスト）に期限順にまとめさせている。エージェントが自分で進められる作業は、そこに載せない。自分はそのページだけを見て、終わったら「◯◯やった」と伝える。帳簿とノートの更新は、エージェントがやる。

作り方：MCP、エージェントの定義、コマンドの3つ

体制は、Claude Code の標準の仕組みだけで組んでいる。ファイルはすべてホームディレクトリの ~/.claude/ の下にあり、リポジトリは持っていない。

1. freee の MCP サーバーをつなぐ

freee が公開している MCP サーバー（freee-mcp）を、Claude Code の MCP の設定に足す。自分の設定は npx で起動するだけの形だ。

{
  "mcpServers": {
    "freee-mcp": { "command": "npx", "args": ["freee-mcp"] }
  }
}

初回は、freee-mcp の認証の手順に従って、ブラウザで freee にログインしてアプリの利用を許可する。以後は、freee_api_get や freee_api_post といったツールで API を呼べる。対応している API の一覧と使い方は、freee の公式の案内に従った。

2. エージェントを1体ずつ定義する

エージェントは ~/.claude/agents/ に、1体1ファイルの Markdown で置く。先頭の tools: で使えるツールを決め、本文に仕事の手順を書く。

freee-bookkeeper の本文は、「最初に必ずやること」「現状を掴む」「自動記帳の検品」「記帳する」の順になっている。いちばん長いのは検品の節で、自動記帳がよく間違えるものを並べている。

• Suica のチャージが、旅費交通費として二重に計上されていないか
• クレジットカードの引き落とし（振替）が、経費になっていないか
• 本人名義の振込や預金利息が、売上になっていないか
• 同じ取引先・同じ摘要なのに、月によって勘定科目が違っていないか

未処理の明細が0件なら「記帳は追いついています」と報告して、検品に進む。自分の環境では、ほとんどの回がこの流れになる。

3. コマンドから2体を並べて起動する

~/.claude/commands/ に置いた Markdown が、そのままスラッシュコマンドになる。/keiri の中身は短い（引数の扱いを除いた抜粋）。

---
description: freee の経理を日次チェック（未処理明細・自動記帳の検品・証憑漏れ）
---
 
1. `freee-bookkeeper` エージェントに、未処理明細の有無と自動記帳の検品を依頼する
2. `freee-auditor` エージェントに、証憑の添付漏れチェックを依頼する
 
2つは独立しているので**同時に**起動してください。
 
結果は次の形でまとめること:
- 未処理明細: N件（あれば一覧）
- 要確認の記帳: N件（科目の誤り・二重計上の疑い）
- 証憑漏れ: N件（金額の大きい順に上位のみ）
- 今すぐやるべきこと: 箇条書きで3つまで
 
freee への書き込みは、内容を提示して承認を得るまで行わないこと。

報告の形を決めておくと、毎回同じ順で読める。やるべきことは3つまでに絞らせている。

全員が読む3つのファイル

エージェントは起動するたびに、次の3つを読む。

勘定科目は153件ある。毎回 API で全件を取っていると、それだけでトークンを使う。よく使う科目の ID を profile.md に書いておけば、取りに行かなくて済む。

rules.md は、判断が確定するたびに追記していく。「この摘要はこの科目」「Suica のチャージは私用カードから」といった判断が、本人に確認した日付つきで溜まっていく。

入口は4つのコマンド

エージェントを毎回名指しするのは面倒なので、スラッシュコマンドを入口にした。

/shikin だけはエージェントを使わず、メインのセッションで計算する。カードの引き落とし額は freee に入る前なので、自分に聞いてから計算する必要があるからだ。

実際に拾ったもの

1か月半で拾ったものを、時系列で並べる。

資金不足：口座残高が直接取れないなかで、どう出したか

10月の資金繰りは、こう計算した。

月末には売上の入金がある。ただ、入金より先に家賃と生活費の送金が出ていく。月の合計では足りていても、入金までの数日だけ口座がマイナスになる計算だった。年間の税金を月ごとに並べると同じことが起きる話は、税金積立の記事に書いた。

ブログの税額の誤り：記事の数字を、経理側が検算して見つけた

このブログの記事の税額の誤りを、経理のエージェントが見つけた。

このブログには、別に記事を書くエージェントと校閲するエージェントがいる。手取りの記事の税額は、記事側の確認だけでは誤りに気づけていなかった。

freee-tax-advisor に記事の税額を検算させたところ、所得税は、記事の前提どおりに計算し直すと103万円ではなく約164万円だった。2026年分の消費税も、15万円ではなく約6.1万円だった。2025年分の所得税の実額も、予定納税の通知額から逆算すると約144万円で、103万円とは離れていた。帳簿と通知額を持っている経理側だから、記事の数字が実額とずれていることが見えた。手取りの記事は訂正済みだ。

うまくいかなかったこと

名前から推測した判定が、本人の事実と違っていた

最初の rules.md では、カード会社名で引き落とされている明細を「クレジットカードの引き落とし＝振替。経費にしない」と定義していた。明細の名前だけを見ると、そう読める。

実際には、それは家賃の口座引き落としだった。引き落としの名義がカード会社だっただけだ。自分に確認して、10/3 に rules.md を「地代家賃。家事按分の対象」に直した。

直したはずのルールが、別のファイルに残っていた

10/31 に定義を読み直して、もう一つ見つけた。rules.md は10/3に直していたのに、freee-bookkeeper の定義の「検品で疑うもの」の例に、同じ明細が「クレジットカードの引き落とし（経費にしてはいけない）」として残っていた。

検品のときに rules.md と定義のどちらを信じるかで、家賃を「経費にしてはいけない明細」として扱いかねない状態が4週間続いていた。10/31 に定義を直し、「迷ったら rules.md を優先する」と書き足した。

同じ事実を2つのファイルに書くと、直すときに片方が残る。具体的な明細の名前は rules.md だけに置き、定義には「何を疑うか」だけを書くのが筋だった。

API で取れないものがある

freee の API は、使っているアプリの権限によって、取れないものがあった。

口座の残高が直接取れないのは、資金繰りには痛い。10/3 の資金繰りは、明細から取れた 9/30 時点の残高で計算した。資金繰りのノートには、何日時点の残高で計算したかを書いている。

人に残している作業

エージェントに任せていないものもある。

• 税務署への提出（予定納税の減額申請、確定申告、届出）
• 請求書の送付と、取引先への連絡
• 控除証明書などの、郵便で届く書類の受け取り
• 私用口座からのお金の移動

どれも、間違えたときに自分が説明しなければならないものだ。本業でも、AI に任せない線を「相手に説明しないといけないもの」に引いている。経理でも同じ線になった。

まとめ

• freee の自動記帳で、明細1,203件はすでに処理済みだった。AI に任せる価値は、記帳ではなく検品と試算にあった
• 書き込めるのは5体のうち2体だけ。権限はお願いの文章ではなく、tools: から外して止めている
• 書き込む2体も、表で見せて承認を取ってから書く。請求書の送付と税務署への提出は人がやる
• 具体的な明細の名前やルールは rules.md の1か所に置く。定義にも書くと、直すときに片方が残る
• 拾ったのは、口座の資金不足、売上の計上漏れ、家事按分の振替漏れ、予定納税の減額、ブログの税額の誤り。どれも、期限の前に見えたことに意味があった

毎月いくら税金用に貯めればいいかは、税金積立の記事で、支払月ごとの実額で計算している。