freee 会計 MCP で「できること／できないこと」一覧｜仕訳参照・取引登録・レート制限の現実（網羅整理・要確認）

freee 会計を中核としたバックオフィスの自動化を検討する際、避けて通れないのが API（MCP: Micro Computer Program 含む）の活用です。しかし、公式ドキュメントには「できること」は詳細に記されているものの、実務者が最も知りたい「どこで詰まるのか」「何ができないのか」という制約については、実際に叩いてみるまで見えにくいのが現状です。

本記事では、日本国内のクラウド会計市場を牽引する freee 会計の API 仕様に基づき、実務担当者が直面するレート制限の現実や、仕訳・取引登録における技術的制約を網羅的に解説します。単なる仕様の羅列ではなく、システム設計時に考慮すべき「現実的な運用の解」を提示します。

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（Micro Computer Program）はあくまでデータ連携を円滑にするための枠組みであり、freee の「設定画面（例えば、メンバー権限の詳細設定や、電子帳簿保存法の利用ON/OFF）」を外部から操作することはできません。これらは人間が管理画面から行う必要があります。

【比較表】freee 会計 API プラン別機能と制限

freee 会計の 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 を武器にするための判断基準

freee 会計の API / MCP 連携は、正しく設計すれば経理業務の 90% 以上を自動化するポテンシャルを秘めています。しかし、そのためには「レート制限という物理的な制約」と「freee 独自のオブジェクト構造（取引・決済・仕訳）」を深く理解しなければなりません。

「とりあえず繋ぐ」のではなく、データの流量を見極め、エラーが発生した際のリカバリプランを事前に定義しておくこと。それが、拡張性と保守性を備えたモダンな経理システムを構築する唯一の道です。自社の開発リソースや求める自動化レベルに応じて、パブリック API を直接叩くのか、あるいは既存の iPaaS 等を活用するのか、慎重に選定を行ってください。