freee 会計 MCP で「できること／できないこと」一覧｜仕訳参照・取引登録・レート制限の現実
目次 クリックで開く
freee 会計を中核としたバックオフィスの自動化を検討する際、避けて通れないのが API と MCP（Model Context Protocol：AIエージェントが外部ツールを安全に呼び出すためのオープン規格）の活用です。しかし、公式ドキュメントには「できること」は詳細に記されているものの、実務者が最も知りたい「どこで詰まるのか」「何ができないのか」という制約については、実際に叩いてみるまで見えにくいのが現状です。
本記事では、日本国内のクラウド会計市場を牽引する freee 会計の API 仕様に基づき、実務担当者が直面するレート制限の現実や、仕訳・取引登録における技術的制約を網羅的に解説します。単なる仕様の羅列ではなく、システム設計時に考慮すべき「現実的な運用の解」を提示します。
【2026年3月更新】freee 公式MCPサーバー「freee-mcp」がOSS公開
「できること／できないこと」を考えるうえで、まず押さえておきたいのがfreee公式のMCPサーバー「freee-mcp」です。freeeは2026年3月2日、AIエージェントからfreeeの基幹業務を操作できる「freee-mcp」をオープンソース（GitHub・npm）として公開しました。会計に加えて人事労務・請求書・工数管理・販売・サイン（電子契約）に対応し、Claude Desktop／Claude Code／Claude Cowork／Cursor などから利用できます。Claude Code ではプラグインとして導入すると、MCPサーバーに加えてAPIリファレンスや操作レシピのAgent Skillsが同梱され、約270本のAPIが扱いやすい単位に集約されます。
つまり、以前のように自作のラッパーを書かなくても、公式の freee-mcp を入れれば「できること」の大半はすぐ試せます。一方で「できないこと」も明確で、本記事で後述するレート制限に加え、クレジットカード明細と取引の紐付け（消込）はfreee APIの仕様上、MCP経由でも直接は実行できません。ここを知らずに使うと二重計上の温床になります。公式MCPで参照・登録が手軽になったぶん、「AIに渡す範囲・許可する操作・人の承認」という統制設計はむしろ重要になります。正規化した摘要だけをAIに渡し、トークンはサーバー側に保管し、人が承認した分だけを会計ソフトへ反映する構成は、セキュア記帳基盤 RuleHub に寄せて共通化できます。
マネーフォワード側の公式リモートMCPとの機能・制約の違いは、freee MCP とマネーフォワード MCP の徹底比較で詳しく扱っています。
freee 会計 MCP・API 連携の全体像と主要な「できること」
freee 会計の API 連携は、RESTful な設計に基づいています。主に「取引（Deals）」ベースのデータ操作と、会計帳簿としての「仕訳（Journal Entries）」ベースの参照、そして「マスタ（勘定科目・タグ等）」の同期が柱となります。
取引（Deals）の登録・更新・削除
freee 会計の最大の特徴は、単なる仕訳入力ではなく「取引」という概念で収支を管理する点にあります。API を介して、売掛金や買掛金の発生、およびその決済状況を登録することが可能です。これにより、自社の販売管理システムや EC サイトの受注データから、freee 上に未決済の取引を自動生成できます。
- 決済ステータスの管理: 未決済、完了、一部決済などのステータスを外部から制御可能。
- 複数行取引のサポート: 1つの取引に対して複数の明細（品目・税区分）を紐付けて登録。
- 源泉徴収税の計算: 報酬支払時などの源泉徴収税額を含めた登録にも対応しています。
仕訳参照とレポート取得（試算表・現預金管理）
月次決算の早期化や、独自の BI ツールによる経営可視化を行う場合、freee 側の仕訳データを抽出する必要があります。API では、指定した期間の仕訳帳（Journal Entries）を JSON 形式で取得できるほか、試算表（Trial Balance）の合計値を取得することも可能です。
関連記事：【完全版・第5回】freee会計の「経営可視化・高度連携」フェーズ。会計データを羅針盤に変えるBIとAPI連携術
マスタ管理（勘定科目・タグ・品目・部門）
freee 特有の「タグ」管理は、API 経由でも強力に機能します。部門、品目、メモタグ、取引先といったマスタ情報を外部システムと同期させることで、入力ミスを防ぎつつ、精緻な管理会計を実現できます。特に、SFA（Salesforce 等）の取引先 ID を freee の取引先コードに紐付ける設計は、多くの企業で採用されています。
ファイルボックスへの証憑アップロード
電子帳簿保存法への対応において重要なのが、領収書や請求書のスキャンデータの管理です。API を利用すれば、外部のストレージや受取請求書 SaaS から freee の「ファイルボックス」へ直接ファイルをアップロードし、特定の取引に紐付けることができます。
実務で突き当たる「できないこと」と技術的制約
利便性の高い freee API ですが、大規模なデータ処理や複雑な業務フローを実装しようとすると、明確な「壁」が存在します。ここを理解せず開発を進めると、本番稼働後にシステムが停止するリスクがあります。
レート制限（Rate Limit）の壁：リクエスト回数の現実
最も注意すべきはレート制限です。freee 会計の API は、過度な負荷を防ぐためにリクエスト回数に上限を設けています。公式ドキュメント（freee デベロッパーコミュニティ）に記載されている通り、基本的には「1事業所あたり1分間に最大120リクエスト（秒間2リクエスト相当）」が目安となります。※プランやエンドポイントにより変動あり。
例えば、数万件の過去データを一括で流し込もうとする場合、この制限に即座に抵触します。429 Too Many Requests エラーが返された際の再試行ロジック（指数バックオフ等）の組み込みが必須となります。
複雑な配賦計算や一括更新の限界
freee 会計の標準機能にある「配賦（共通費の部門振り分け）」などは、API 経由でトリガーを引くことができません。計算後の数値を「振替伝票（Manual Journals）」として登録することは可能ですが、freee 内部の配賦エンジンを直接 API で叩くことはできないため、ロジックを外部で構築する必要があります。
関連記事：【完全版】給与ソフトからfreee会計への「部門別配賦」と仕訳連携。労務と経理の分断を解決するアーキテクチャ
MCP 経由での UI 操作・特殊設定の不可
MCP（Model Context Protocol）はあくまでデータ連携を円滑にするための枠組みであり、freee の「設定画面（例えば、メンバー権限の詳細設定や、電子帳簿保存法の利用ON/OFF）」を外部から操作することはできません。これらは人間が管理画面から行う必要があります。
【比較表】freee 会計 API プラン別機能と制限
freee 会計の API 利用は、契約しているプランに依存します。個人事業主向けプランや法人ミニマムプランでは、一部のエンドポイント（部門マスタ等）が制限される場合があるため、事前に確認が必要です。
| 機能項目 | 法人プロフェッショナル以上 | 法人スターター/スタンダード | 備考 |
|---|---|---|---|
| 基本APIアクセス | 可能 | 可能 | OAuth 2.0 認証 |
| 部門/品目マスタ同期 | 制限なし | 一部制限あり | プランにより部門階層数に差 |
| 振替伝票の作成 | 可能 | 可能 | 仕訳形式での直接登録 |
| 承認フロー連携 | 可能 | 不可（標準機能に準ずる） | 申請APIの利用可否 |
| レート制限の緩和 | 要相談（個別調整） | 原則標準値のみ | エンタープライズプランでの対応 |
※詳細な最新仕様は、freee デベロッパーコミュニティを参照してください。
MCP / API 運用におけるエラー対処と設計のステップ
実務で freee API を安定稼働させるための、実装手順とよくあるトラブルへの処方箋です。
ステップ1：OAuth 2.0 認証と認可コードの取得
freee API は OAuth 2.0 を採用しています。開発者は freee アプリストアでアプリケーションを登録し、Client ID と Client Secret を取得します。アクセストークンには有効期限（通常24時間）があるため、リフレッシュトークンを使用して自動更新する仕組みが不可欠です。サーバーサイドでのトークン管理を誤ると、「朝起きたら連携が止まっていた」という事態になります。
ステップ2：レート制限を回避するキューイング設計
大量の取引データを外部から流し込む場合、即座に API を叩くのではなく、一度 Google Cloud Pub/Sub や AWS SQS などのメッセージキューに溜める設計を推奨します。ワーカープログラムが秒間リクエスト数を制御しながら、少しずつ freee 側へリクエストを飛ばすことで、429 エラーによる処理中断を回避できます。
ステップ3：Webhook を活用したステータス同期
「freee 側で決済が完了したら、自社のシステムも完了にしたい」という場合、定期的なポーリング（監視）はリソースの無駄です。freee の Webhook 機能を使えば、freee 側で取引が更新されたタイミングで外部システムへ通知を送ることができます。これにより、リアルタイムに近い同期が可能になります。
よくあるエラーコードと対策
- 401 Unauthorized: トークンの期限切れ、またはアクセストークンの設定ミス。リフレッシュトークンの処理を見直してください。
- 403 Forbidden: 操作権限がありません。API 連携に使用しているユーザーに、対象の事業所や操作権限が付与されているか確認してください。
- 422 Unprocessable Entity: バリデーションエラー。勘定科目 ID の間違いや、消費税区分の不一致など、データの論理的整合性が取れていない場合に発生します。
関連記事：楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャ
よくある質問（freee MCP 連携）
Q. freee MCPで取引を自動登録するにはどのような権限スコープが必要ですか？
取引の参照（読み取り）には「freee:accounting:read」相当のスコープ、取引の新規登録・更新には「freee:accounting:write」相当のスコープが必要です。Claude Codeと連携する場合、必要最小限の権限のみを付与する「最小権限の原則」が重要です。書き込み権限は特に慎重に管理し、人の承認を経た後に書き込む設計が推奨されます。
Q. freee MCPのAPIレート制限はどのくらいですか？実務への影響は？
freee APIのレート制限は標準で300リクエスト/5分（従量プランは異なる場合あり）です。大量の仕訳を自動処理する場合、1件の取引登録に複数のAPIコールが必要なため、月次の処理を集中させるとレート制限に達することがあります。対策としては①処理を分散させる②エラー時に指数バックオフでリトライする③レート制限が高い上位プランを利用する、が有効です。
Q. freee MCPをClaude Codeで使う際のセキュリティ上の注意点は？
主な注意点は①AIに渡すデータを必要最小限に絞る（全仕訳データでなく対象月・勘定科目を限定する）②書き込み操作は人の確認フローを経る（「承認してから書き込む」設計）③APIトークンをCLAUDE.mdや環境変数として適切に管理し、ログに出力しない④Claude Codeの操作ログを保全して事後監査できる体制を作る、の4点です。
Aurant RuleHub で freee MCP の操作権限を安全に設計する
freee 会計の MCP を設定するだけでは、Claude に接続した全ユーザーが仕訳の参照から書き込みまで無制限に実行できる状態になります。社内ツールとして展開する場合、「誰でも仕訳を書き換えられる」リスクは経営・内部統制の観点で許容できません。
RuleHub で設定できる権限ルールの例
| 操作カテゴリ | 対象ユーザー | RuleHub 設定 |
|---|---|---|
| 仕訳参照・レポート取得 | 全員（経理・営業・管理職） | 許可（制限なし） |
| 取引登録・仕訳作成 | 経理担当者のみ | ロールベース許可 |
| 取引削除・修正（確定済） | 経理責任者 | 承認フロー必須 |
| 勘定科目マスタ変更 | システム管理者のみ | 禁止 or 申請制 |
操作ログによる監査証跡
RuleHub は MCP 経由で実行されたすべての操作をログに記録します。税務調査時の証跡提出や内部統制の J-SOX 対応において、「いつ・誰が・何の仕訳を登録・変更したか」を即座に提示できます。freee 会計側のアクティビティログと組み合わせることで、二重の監査証跡を構成できます。
freee MCP の権限設計・RuleHub 導入の詳細はAurant RuleHub サービスページをご覧ください。freee MCP の安全な社内展開についてお悩みの方は無料相談フォームからご相談ください。
まとめ：freee 会計 MCP を武器にするための判断基準
freee 会計の API / MCP 連携は、正しく設計すれば経理業務の 90% 以上を自動化するポテンシャルを秘めています。しかし、そのためには「レート制限という物理的な制約」と「freee 独自のオブジェクト構造（取引・決済・仕訳）」を深く理解しなければなりません。
「とりあえず繋ぐ」のではなく、データの流量を見極め、エラーが発生した際のリカバリプランを事前に定義しておくこと。それが、拡張性と保守性を備えたモダンな経理システムを構築する唯一の道です。自社の開発リソースや求める自動化レベルに応じて、パブリック API を直接叩くのか、あるいは既存の iPaaS 等を活用するのか、慎重に選定を行ってください。
企業規模・システム成熟度別 × freee会計MCP/API活用パターン × 技術制約と設計上の注意点 早見表
前のセクションでfreee会計のMCP/APIの主要な機能と制約を整理しましたが、「会計専任担当なしの小規模事業者」「月次決算を社内完結させる中堅企業」「複数法人・複数freeeテナントを管理する企業」「外部システム（基幹・CRM）との自動連携が必要な企業」では、freee会計のAPI活用の目的・技術設計の複雑さ・運用上のリスクが大きく異なります。自社の規模と成熟度に合わない活用設計は開発コストの無駄やAPIエラーによる会計データの不整合に直結します。規模・成熟度別の活用パターンと設計注意点をまとめました。
| 企業規模・システム成熟度 | freee会計MCP/APIの推奨活用パターン | 技術的制約と設計上の注意点 | 運用リスクとよくある失敗の回避策 |
|---|---|---|---|
| 小規模事業者・フリーランス （freee単独運用・会計担当兼務・API未経験） |
小規模事業者でのfreee MCP活用は「Claude等のAIアシスタントにfreee MCPを接続して自然言語での取引入力・仕訳確認・残高照会を実現すること」がもっとも費用対効果の高い活用。freee APIを直接開発するのではなく、freee公式またはサードパーティが提供するMCPサーバーを設定するだけで始められる点が小規模向けの最大の利点。定期的な固定費（家賃・サブスク費用等）の仕訳を繰り返し登録する「仕訳テンプレート機能」をAPIで自動化することも小規模でのAPI活用として現実的な最初のユースケース | 小規模事業者がfreee MCPを活用する際の最重要制約は「freee会計のAPIアクセストークンの有効期限（1時間）とリフレッシュトークン（30日）の管理」。MCP経由でのAPI接続を長期間安定して稼働させるにはトークンの自動更新設計が必要で、適切な実装なしに運用を始めるとある日突然MCPが認証エラーで動かなくなる。freee APIのレート制限（1分間のリクエスト数上限）を理解せずに大量の取引を一括登録しようとするとエラーが発生するため、バッチ処理の間隔設計が必要 | 小規模事業者でのAPI活用の最多失敗は「MCPの設定後に動作が不安定になっても原因を自力で調査できないまま放置して会計データへの信頼が失われること」。APIを活用する前に「手動でfreeeに入力した場合のバックアップ運用」を確保してからAPI活用を開始する。freeeのMCPを通じてAIが自動入力した仕訳は「必ず1週間以内に会計担当者（または税理士）が確認する承認フロー」を設けて、誤分類がないか定期確認する運用設計が信頼性確保の最低限の基準 |
| 月次決算を社内完結させる中堅企業 （専任経理担当あり・請求ソフト・経費精算ツールとの連携あり） |
中堅企業でのfreee会計API活用の最適パターンは「請求書ソフト（Misoca・board等）からの売上計上自動仕訳」「経費精算ツール（Concur・楽楽精算等）からの経費仕訳自動連携」「銀行口座の入金消込の自動化」の3軸。これらはfreee公式のパートナー連携またはZapier/MakeでAPIを使わずに実現できるケースが多いため、まず「freeeの公式連携で対応できないか」を確認してからカスタムAPI開発を検討する順序が重要。月次締めの仕訳確認作業をfreee APIで自動レポート化してSlackに送信する設計が経理担当者の月末業務を大幅に効率化できる | 中堅企業でのfreee会計API連携の最重要制約は「外部ツールとfreeeのデータマッピング（勘定科目・部門・取引先コードの対応表）の維持管理」。freeeの勘定科目体系と請求ソフト・経費精算ツールの科目体系が一致しない場合にマッピングテーブルを作成するが、freee側で科目を追加・変更したときにマッピングが壊れてデータが未分類のまま連携されるケースが発生する。freeeのWebhookを使ったリアルタイム連携では「取引登録時に即時Webhookが発火する」ため、外部ツールの処理速度と合わせた流量制御が必要 | 中堅企業でのAPI連携の最多失敗は「連携が正常に動いていると思っていたが月次締め時に外部ツールとfreeeの数字が一致しないことに気づくこと」。月次で「外部ツールの売上合計 vs freeeの売上計上額」の差異チェックをZapierまたはGoogle Sheetsで自動化してから連携を本番運用に移す。勘定科目マッピングの変更は経理担当者・システム担当者・税理士の3者確認を経てから実施して変更履歴を記録する運用ルールを連携設計と同時に確立する |
| 複数法人・複数freeeテナント管理 （グループ会社・FC本部・複数店舗の一括管理） |
複数freeeテナントを一元管理する企業でのAPI活用パターンは「グループ会社全体の月次業績を1つのダッシュボード（Google Looker Studio・PowerBI等）に自動集約すること」が最も費用対効果の高い活用。freee会計のAPIを各法人のテナントに接続して各社の売上・費用・利益を毎日自動取得してBIツールに連携するスクリプトを1本作成するだけで、複数法人のExcel集計作業が不要になる。FC本部が加盟店のfreeeテナントに接続して「売上の自動報告・ロイヤリティ計算の自動化」を実現する活用もFC管理での典型ユースケース | 複数テナント管理でのfreee API最重要制約は「法人ごとにfreeeのアクセストークンが異なるため複数テナントへの同時接続では認証管理の複雑さが増すこと」。アクセストークンを安全に保管・管理する仕組み（AWS Secrets Manager・GCP Secret Manager等）が必要で、セキュリティを考慮しない実装（ローカルファイルにトークンを平文保存する等）は情報漏洩リスクがある。freeeの連結会計・グループ管理機能（別途プランが必要）とAPIの役割分担を確認して、API開発で解決しようとしている問題がfreeeの標準機能で解決できないかを先に検討する | 複数テナント管理でのAPI活用の最多失敗は「あるテナントのアクセストークンが期限切れになってもエラーが検知されず数週間データが取得できていないことに月次集計時に気づくこと」。複数テナントのAPI取得スクリプトにはテナントごとの「最終取得成功日時」を記録して「3日以上データが取得できていない場合はSlackアラート」を送る死活監視を必ず組み込む。グループ各社の勘定科目体系が異なる場合のセグメント別集計ロジックは会計・税務の専門家に確認してから実装しないと連結ベースの数字に誤りが生じるリスクがある |
| 基幹システム・CRM・SCMとの双方向連携 （製造・流通・建設等の業務系との自動連携） |
基幹システムとfreee会計のAPI連携での推奨パターンは「基幹システムが売上確定した時点でfreeeに売掛金計上の仕訳を自動登録→入金消込は銀行APIとfreeeで自動化→月次締め後にfreeeの仕訳データを基幹の原価計算・管理会計システムにエクスポートする」一方向フロー設計が最もトラブルが少ない。双方向同期（基幹とfreeeの両方にデータが存在して相互に更新する設計）はデータの競合・上書きリスクが高いため「どちらが正のデータ源泉か」を設計時に明確に決めてから実装する | 基幹とfreeeの連携での最重要制約は「freeeの取引（仕訳）を後から修正すると修正前の仕訳が削除されて新規作成になるため基幹システムのIDとfreee取引IDが不一致になること」。基幹からfreeeへのデータ連携IDとfreeeが発番するIDを別々に管理する設計（外部参照IDフィールドの活用）が必要。freeeのAPIのレスポンスタイムは通常0.5〜2秒で大量の仕訳を登録する場合は並列処理よりも直列処理（エラー時の再試行設計込み）が安定性の観点で推奨される | 基幹×freee連携の最多失敗は「基幹システムからfreeeへの仕訳登録が部分的に失敗して基幹とfreeeの残高が一致しないことに気づかないまま月次決算を行うこと」。仕訳登録APIのレスポンスで成功・失敗を記録して「失敗した仕訳の再送信フロー」と「月次の残高突合」を必ずセットで設計する。大規模な仕訳件数（月1万件以上）を扱う場合はfreeeのバルクインポート（CSVインポート）をAPI経由で自動化する設計が個別API呼び出しより安定性が高くレート制限にも引っかかりにくい |
この表でfreee会計のMCP/API活用において最重要の設計原則が「自社の規模・成熟度・既存システムの構成に合った『今すぐ使える最小限のAPI活用』から始めて、運用が安定してから次のユースケースに拡張する段階的アプローチを取ること」です。freee APIの技術的な可能性は広いですが、認証管理・レート制限・エラーハンドリング・データ整合性確認の4点を最初から設計に組み込まないと「動いたと思ったら実は動いていなかった」状態が会計データの信頼性を損なう最大のリスクになります。
開発・運用開始前に確認すべき「実務上のチェックリスト」
freee APIを用いたシステム連携において、開発環境では露呈せず、本番稼働直後に発覚しやすいトラブルがいくつか存在します。安定稼働のために、以下の3点は設計段階で必ずチェックしてください。
1. アクセストークンの「24時間」制限と自動更新の実装
freee APIのアクセストークンは、発行から24時間で失効します。手動での再認可は現実的ではないため、プログラム側で「リフレッシュトークン」を用いて新しいアクセストークンを自動取得するロジックが必須です。また、リフレッシュトークン自体も一度使用すると新しいものに置き換わるため、データベース等への保存処理もセットで実装する必要があります。
2. 事業所ID（company_id）の固定値化によるリスク
リクエスト時に必要な company_id をコード内にハードコーディングすることは推奨されません。将来的な組織変更やテスト環境（サンドボックス）との切り替えを考慮し、認可時に取得した事業所一覧から動的に選択するか、環境変数として管理する設計が望ましいです。
3. レート制限を考慮した「データ処理方式」の選択
データの件数やリアルタイム性に応じて、適切な連携方式を選択してください。以下の表は、データ量別の推奨アプローチをまとめたものです。
| 処理対象 | 推奨される手法 | 設計のポイント |
|---|---|---|
| 単発の取引登録 | リアルタイムAPI連携 | ユーザー操作に合わせて即時リクエスト |
| 数百件〜数千件の同期 | 非同期（キュー）処理 | 秒間2リクエスト以下に流量を制御 |
| 数万件以上の初期移行 | CSVインポート/バッチ分割 | APIを使わず標準機能の活用も視野に |
公式ドキュメント・関連リソース
実装の詳細や最新の仕様変更については、必ず以下の公式サイトを確認してください。特に「お知らせ」セクションには、メンテナンス情報やAPIの廃止予定（非推奨化）が掲載されます。
また、既存システムからのデータ移行や、手作業の完全自動化を検討されている場合は、以下のアーキテクチャ事例も参考になります。
freee MCP を本番運用に乗せる際は、レート制限対策と同じくらい「どのスコープを、誰に、どこまで開くか」の設計が重要になります。仕訳参照や取引登録をAIに任せる範囲が広がるほど、読み取り権限・承認・操作ログを毎回アプリ側で作り込む負担が増えるため、AIに渡す情報・権限・操作を絞り込むセキュア記帳基盤 RuleHub で共通化する方法もあります。freee MCP を安全に業務へ組み込む設計やPoCの進め方は Claude Code 導入支援 でご相談いただけます。
経理・会計DXと仕訳／請求／債権自動化のご相談
仕訳・請求・入金消込・債権管理といった経理業務の自動化と、会計データの可視化までを一気通貫で支援します。ツール選定や既存運用の見直しについて、導入前後のセカンドオピニオンとしてもご相談いただけます。