freee を導入しても Excel と税理士依存が続く。これは使い方の問題ではなく、設計の問題だ。会計ツールを単体で見るのではなく、AI エージェントの起点として再配置すると、経理業務の構造が変わる。

freee を入れても、中抜き構造は消えない

freee を導入した企業の多くが、同じ状況に直面している。
自動仕訳は動いている。銀行連携も済んでいる。
それでも、月次決算の準備には Excel が並び、税理士とのやり取りには Slack と Google ドライブが使われ、最終的な帳票は PDF で送られてくる。

ツールは入った。でも、業務フローは変わっていない。
freee が「会計ソフト」として導入されたからだ。
会計ソフトは、仕訳を記録するもの。
記録した先で何が起きるかは、別の領域とされてきた。

私たちが freee 会計を使う企業と対話してきた中で見えたのは、ツール単体では構造が変わらないという事実だった。
freee の API は公開されている。
MCP（Model Context Protocol）を使えば、Claude が freee のデータを直接読み書きできる。
それでも、誰もそこに手を付けない。

なぜか。
設計思想が、まだ「人が入力して、人が確認する」前提のままだからだ。

AI エージェントの起点として freee を再配置する

freee MCP を Claude Code に接続すると、会計データが対話可能になる。
「先月の広告費、予算に対してどうだった？」
と聞けば、freee から勘定科目を引いて、予算 CSV と突合し、差分を返してくれる。Excel を開かない。
税理士に聞かない。
Claude が、freee を起点に判断材料を組み立てる。

ここで起きているのは、単なる業務効率化ではない。
会計データが「記録」から「判断材料」に変わっている。
記録は人が読む。判断材料は AI が読み、必要に応じて人に渡す。この変化が、中抜き構造を崩す起点になる。

私たちは、ある SaaS 企業で freee + Claude の構成をテストした。経理担当 1 名、税理士顧問月 15 万。
この体制で、月次クロージングに 5 営業日かかっていた。
freee MCP 接続後、仕訳確認と勘定科目の妥当性チェックを Claude に任せた結果、3 営業日に短縮された。
税理士への質問回数は月 8 件から 2 件に減った。

フリー会計ソフトを「入力の受け皿」ではなく
「AI が参照するデータ基盤」として設計し直すと、
依存先が変わる。人ではなく、API が判断の起点になる。

税理士依存を減らすのではなく、関係を再定義する

誤解を避けたい。
私たちは税理士を不要だと言っているのではない。
むしろ逆だ。税理士の役割を、入力確認や月次報告から、判断支援や制度変更への対応に移行させたいと考えている。

Claude が freee のデータを読めるようになると、税理士に聞くべき質問が変わる。
「この仕訳、正しいですか？」ではなく、
「この取引、インボイス制度上どう扱うべきですか？」になる。前者は Claude Code で済む。
後者は、制度解釈と経営判断が必要で、人の領域だ。

私たちが目指しているのは、freee を中心に AI と人が役割分担する設計だ。
freee が記録を持ち、Claude が日次で整合性を確認し、税理士が月次で判断を支援する。
この構造なら、経理 1 名体制でも月次クロージングは回る。

会計業務を、AI 化の起点にする理由

会計データは構造化されている。
勘定科目、日付、金額、取引先。すべてが定義済みで、API 経由で取得できる。
これは、AI にとって理想的な入力だ。曖昧さがない。
解釈の余地が少ない。だから、会計業務は AI 化の最初の候補になる。

ただし、会計「ツール」を入れただけでは何も変わらない。
freee を API として扱い、Claude Code をその上に載せ、業務フローを「人が freee に入力する」から「freee が Claude に渡す」に組み替える必要がある。

私たちは、この設計を「AI 中核設計」と呼んでいる。
ツールを中心に人を配置するのではなく、AI を中心にツールと人を配置する。
freee はその起点として、最も現実的な選択肢だ。

あなたの会社で、freee はどう使われているか。
記録の受け皿か、判断の起点か。その違いが、今後の経理体制を決める。