kintone×freee API連携で月10時間削減｜申請〜請求を自動化する手順【2026年版】

申請だけはkintoneに入れてもらってる。月末締めで、また経理がfreeeに同じ内容を転記してる…これが取引先50社を超えると、月10時間以上が突合と転記だけで消える

そんなバックオフィスの二重入力を、kintoneとfreeeのAPI連携で物理的に消す手順を、freee側の認証準備からGAS中継・運用後の落とし穴まで具体的に解説します。

kintoneとfreeeを別運用で発生する月10時間以上の二重入力

kintoneは申請・社内ワークフローの入口、freeeは会計処理の出口として、それぞれ独立して使っている中小企業は多いです。問題は、その間の転記がほぼ手作業で残っていることです。

実際にうちのクライアントさんでは、毎月50件前後の請求書処理に12時間以上かかっていました。内訳は、作成2〜4時間／PDF変換1〜2時間／送付1〜3時間／照合2〜4時間／フォロー1〜2時間。kintoneで申請が上がるたびに経理が同じ情報をfreeeに打ち直していたため、件数が増えるほど線形に時間が膨らむ構造になっていました。

二重入力が消えない本質的な理由

kintoneとfreeeはどちらもAPIを公開していますが、標準ではお互いを知りません。kintoneのレコードが追加されても、freeeの取引には自動で転記されない仕様です。そのため「申請の入口」と「計上の出口」の間に、毎月人間が橋渡しをしているのが現状です。

freeeは2025年時点で60万社以上が使い、AIエージェント連携用の freee-mcp もOSS公開されています。kintone側もWebhookとJavaScriptカスタマイズで自由に外部APIを叩ける仕組みが揃っているため、技術的にはほぼ全業務シナリオで連携が可能です。やっていないのは「設計と運用の段取り」が足りないからで、ツールの問題ではありません。

API連携で自動化できる4つのシナリオ

kintone×freeeのAPI連携で実現できる代表的なシナリオは次の4つです。どれから着手するかは、現在最も時間がかかっている業務を選ぶのが鉄則です。

シナリオ1: 経費精算の自動取引登録

kintoneで経費精算レコードが承認された瞬間に、freeeへ取引（支出）として自動登録します。承認ステータスが「最終承認」に変わったタイミングをトリガーに、勘定科目・税区分・部門タグまで含めて転記する設計が一般的です。

シナリオ2: 請求書発行の一気通貫

kintoneの顧客マスタと案件レコードから、freeeの請求書を自動作成しPDF化します。送付までSlackやメールで自動化すれば、月50件規模の請求書業務は確認のみの月1時間以下に圧縮できます。

シナリオ3: 取引先マスタの双方向同期

kintoneとfreeeに同じ取引先が二重登録されている問題を解消します。差分検出と上書きルールを決めておけば、毎週バッチで整合性を保つ運用が組めます。

シナリオ4: 月次仕訳の自動集計レポート

freeeから取引データを取得し、kintone側にダッシュボード形式で月次レポートを生成します。売上高1〜30億円規模の企業では月次レポート作成に1〜2日かかるのが一般的ですが、これを数分に短縮できます。差異分析の重点基準として、予算比±10%以上の科目を自動でハイライトする運用も効果的です。

【手順1】freee API側の準備とOAuth認証の設計

最初にやることは、freee Developers管理画面でのアプリケーション登録です。ここでアプリ名・リダイレクトURI・利用するスコープを定義し、Client IDとClient Secretを取得します。

スコープは最小権限で設計する

よくある失敗は、開発初期に「とりあえず全権限」でアプリを作ってしまうことです。私自身、自社のfreee連携を組んだとき、最初はテスト目的で取引・口座・取引先の全スコープを付けたまま本番に置いてしまい、API版にすれば安心は思考停止だと気づかされました。APIキーが1つ漏れたときのダメージはWeb版の学習利用よりはるかに大きい場合があり、中小企業のデータ流出リスクの9割は人的ミスから生まれます。実際にうちのクライアントさんでは、初期設計で「読み取り専用」「取引登録のみ」のように、必要最小限のスコープに絞り、運用中にも年2回スコープ棚卸しをする運用に変えてもらいました。

OAuth 2.0とリフレッシュトークンの管理

freee APIはOAuth 2.0を採用しており、アクセストークンの有効期限は短く設定されています。本番運用ではリフレッシュトークンを使った自動更新を組み込みます。トークンの保存先は、kintoneのアプリやスプレッドシートではなく、Google Cloudの Secret Manager や 環境変数経由で参照するのが安全です。

【手順2】kintone側のJavaScriptカスタマイズと送信ロジック

kintone側はJavaScriptカスタマイズで送信ロジックを書きます。レコード保存後イベントや承認後イベントをフックして、freee APIへPOSTする構成が基本です。

送信前バリデーションを必ず入れる

freeeに送る前に、kintone側でデータ形式のバリデーションを必ず実装します。日付形式の揺れ、金額の負数、勘定科目コードの未入力など、freeeで弾かれる代表的な失敗パターンを事前に検出して、送信を止める設計が安全です。

Webhookとカスタマイズの使い分け

単純なレコード追加トリガーであればWebhookで十分ですが、承認フロー連動や複数フィールドの組み合わせ判定が必要な場合はJavaScriptカスタマイズを使います。両方使う構成では、Webhookは「freee送信の起動」、カスタマイズは「ユーザー操作の制御」と役割を分けると、運用が破綻しません。

【手順3】GASを中継させて落とし穴を回避するパターン

kintoneから直接freeeを叩く構成は最短ですが、規模が大きくなると問題が出ます。実際に過去にあった失敗実例として、データ形式バラバラで動作不能になった、GAS6分制限に引っかかった、エラー通知未設定で気づかず数日放置した、という3つは中小企業案件で頻発します。

そこで、Google Apps Script（GAS）を中継サーバー的に使う構成が現実解になります。kintone Webhook → GAS → freee API という3段構成にして、GASに正規化レイヤーとリトライ処理、Slack通知を集約します。

GAS6分制限の回避設計

GASは1回の実行が6分を超えるとタイムアウトします。月次バッチで100件の請求書を処理する場合、1件3秒でも300秒で頭打ちになりやすいため、25件ずつのチャンクに分割し、PropertiesServiceで途中状態を保存する設計が必要です。トリガーは時間ベースで5分間隔にし、未処理がある間だけ動かします。

エラー通知をSlackに集約する

try-catchで例外を拾い、SlackのIncoming Webhookに即時通知します。失敗内容（kintoneレコードID・freeeエラーコード・スタックトレース）まで含めて1メッセージで届けば、経理担当者がkintone上で該当レコードを開いて即座に対応できます。

連携後の運用で必ず詰まる3つの落とし穴

連携を組んで動かし始めた直後ではなく、3〜6ヶ月運用したあとに必ず出てくる問題があります。最初の設計で対策を仕込んでおくと、後で慌てずに済みます。

落とし穴1: APIレートリミット

freee APIは1時間あたりのリクエスト回数に上限があります。月初の請求書一括発行や年度切り替え時に、瞬間的にリミットを超えて止まることがあります。GAS側でリトライ間隔を指数関数的に伸ばす（exponential backoff）処理を入れておくと、自動回復できる確率が上がります。

落とし穴2: 取引先マスタの不整合

運用が長くなると、kintoneとfreeeで取引先名の表記揺れが発生します。「株式会社○○」と「(株)○○」が別レコード扱いになり、突合ができなくなる典型例です。マッチング基準として、社名の正規化（記号統一・全角半角統一）と、許容誤差の具体例（消費税端数±1円、品名類似度80%以上、請求日30日以内）を明文化しておくと、誤マッチを防げます。

落とし穴3: スコープ変更時のトークン無効化

freee APIのスコープを後から追加すると、既存のリフレッシュトークンが無効化されることがあります。再認証フローを管理画面に組み込んでおき、無効化を検知したら担当者にSlack通知して、ボタン1つで再認証できる導線を用意しておくと、本番停止を最小化できます。

よくある質問