kintoneの業務データから「複雑な仕訳」を freeeへ自動登録する方法

kintone × freee 連携で「標準プラグインでは解けない」よくある壁

kintone と freee 会計を連携して、業務データから自動で仕訳を起票したい——というニーズは、年々強まっています。受発注、契約、立替、原価計算、プロジェクト別損益、サブスクリプションの按分計上。kintone 側にすでに「業務の真実」が蓄積されているなら、それを使って freee 側の仕訳を自動起票できれば、二重入力ゼロ・月次決算 3 日締めも夢ではありません。

しかし、実際にプロジェクトを進めると、必ずと言っていいほど次のような壁にぶつかります。

• 「複合仕訳（1 取引で借方 / 貸方が複数）が標準連携で表現できない」
• 「按分処理（部門別 / プロジェクト別 / 期間配分）を kintone のデータから自動算出したい」
• 「条件分岐（取引区分・税区分・源泉徴収の有無）が複雑で、CSV 連携の固定マッピングでは表現しきれない」

この記事では、kintone と freee の連携を「標準プラグイン」「CSV 連携」で完結させようとしたときに必ず突き当たる限界と、それを乗り越えるための「API 開発による完全自動仕訳」の世界観・実装ステップ・コスト感までを、経理担当者とシステム担当者の両方に向けて解説します。

標準プラグイン・CSV 連携の限界

kintone と freee を繋ぐ手段は、大きく 3 系統あります。

1. 標準プラグイン / SaaS 連携サービス（kintone アプリ ⇔ freee 取引を 1 対 1 でマッピング）
2. CSV 連携（kintone から CSV を出力 → freee の振替伝票インポート）
3. API 連携（カスタム開発）（kintone Webhook / REST API + freee API を組み合わせ）

1 と 2 は、汎用的に作られているがゆえに、表現できる仕訳パターンに「型」があります。1 件の kintone レコードを 1 件の freee 取引に変換する、という単純な構造を前提にしているため、現実の経理処理に必要な以下のような複雑さに当たると、急に手が止まります。

複雑な仕訳パターン 3 選

kintone × freee 連携で「自動化したいのに自動化できない」典型例は、おおよそ次の 3 パターンに集約されます。

パターン	典型ユースケース	標準プラグインでの限界
複合仕訳 （1 取引 → 借方 / 貸方が複数行）	広告売上から手数料・源泉徴収を控除した入金処理／給与・社会保険控除／立替金清算	レコード 1 件 = 取引 1 件のマッピングしか持たないため、控除明細を別行として表現できない。結果、入金額と帳簿が合わず手修正が発生
按分処理 （金額を比率で複数行に配分）	共通費の部門配賦／プロジェクト別原価配賦／サブスク年額の月次按分／本支店間の按分	按分比率は kintone 側のマスタや実績工数から動的に算出する必要があるが、プラグインの固定フィールドマッピングでは比率計算 → 多明細展開ができない
条件分岐 （取引内容で勘定科目・税区分・部門を切替）	取引区分（売上 / 値引 / 返品）で勘定科目変更／インボイス対応の税区分自動切替／源泉徴収の有無判定	If-Then ロジックは原則プラグイン UI で組めず、組めても 2〜3 段が限界。経理ルールを完全には再現できない

これら 3 パターンは「経理ルールが複雑であること」に起因しているので、ツールを変えても根本的には解決しません。kintone のレコードと freee の仕訳の間に「変換ロジック」を挟まないかぎり、自動化は完成しないのです。この変換ロジックを担うのが、API 開発によるカスタム連携です。

API 開発で実現する「完全自動仕訳」の世界 — 3 ステップ

API 連携と聞くと身構えてしまうかもしれませんが、構造は意外とシンプルです。kintone × freee の自動仕訳は、本質的には次の 3 ステップで成り立ちます。

ステップ 1：kintone の「業務イベント」をトリガーにする

レコードの登録・更新・ステータス変更（例：「請求書発行」「入金確認」「経費承認」）を kintone Webhook で受け取り、連携プログラムを起動します。リアルタイム連携でなく日次バッチでも構いません。経理処理の確定タイミングに合わせて設計します。

ステップ 2：仕訳ルールを「コードとして」定義する

取引区分・部門・プロジェクト・税区分・源泉徴収の有無といった分岐条件を、プログラム上のルールとして実装します。経理担当者が日本語で書いた「仕訳のルールブック」を、そのままコードにマッピングしていくイメージです。按分比率や控除額の計算もここで行います。

ステップ 3：freee API で「複合仕訳」を直接登録する

freee の /deals（取引）または /manual_journals（振替伝票）API に、複数明細を持つ仕訳をそのまま POST します。借方・貸方が複数行の複合仕訳でも、按分で分かれた多明細でも、API 経由なら 1 リクエストで登録可能です。標準プラグインで諦めていた表現力が、ここで一気に解放されます。

【事例】広告代理店 A 社の API 連携事例

具体例で見ると分かりやすいので、広告代理店 A 社のケースを示します。月間 200〜300 件の広告売上があり、入金時に「媒体手数料」「源泉徴収」「振込手数料」を控除されたうえで入金される、典型的な「控除付き入金」処理を抱えていました。

業務の前提

• kintone で「広告案件管理」アプリを運用。クライアント・媒体・売上総額・手数料率・源泉徴収対象フラグを登録
• 入金は媒体ごとにまとめて一括振込で来るため、入金 1 件と売上 N 件が紐づく
• 従来は経理担当者が CSV と Excel で手集計し、freee に振替伝票を手入力。月末 3〜4 営業日が「仕訳作成だけ」に消えていた

API 連携で自動化したロジック

kintone レコードの「入金確認」ステータス変更をトリガーに、以下を自動処理するように設計しました。

1. 複合仕訳の組み立て：売上総額（貸方）／媒体手数料（借方）／源泉徴収税（借方）／振込手数料（借方）／普通預金（借方）を 1 仕訳として生成
2. 按分処理：本社・支社で共通利用している媒体については、前月の売上構成比で部門按分。比率は kintone のマスタアプリから動的取得
3. 条件分岐：源泉徴収対象フラグ ON のときのみ 仮払源泉所得税 行を追加。インボイス登録番号の有無で税区分を 課税仕入 10%（適格） / 課税仕入 10%（区分記載） に切替

導入効果

• 仕訳作成にかかっていた月 3〜4 営業日が ほぼゼロ（確認のみ 1〜2 時間 / 月）に
• 転記ミス・税区分誤りに起因する修正仕訳が 月平均 8 件 → 月 0〜1 件 に減少
• 月次決算の早期化（旧：第 7 営業日 → 新：第 3 営業日）

API 連携プロジェクトの開発手順 — 5 ステップ

では、実際に kintone × freee の API 連携を開発するときに、どんな進め方になるのか。標準的な進行は次の 5 ステップです。

ステップ 1：仕訳ルールの可視化（経理担当者と協働）

最初の最重要工程です。kintone のどのアプリ・どのフィールドが、freee のどの勘定科目・税区分・部門・取引先になるのか、すべての分岐条件を含めて表に書き出します。「このフラグが立っていたら源泉徴収あり」「この媒体は手数料率 X%」といった暗黙知を、可能なかぎり明文化していきます。このフェーズの解像度がプロジェクト全体の精度を決めます。

ステップ 2：プロトタイプ仕訳の手動検証

ステップ 1 で書き出した仕訳ルールを、まず freee 上で手入力で 1 件登録してみることを推奨します。「経理ルール上、本当にこの仕訳で正しいのか」「税区分・部門・取引先の組み合わせが freee のマスタに存在するのか」を、コードを書く前に確認します。ここで矛盾が見つかると、開発工数を大幅に節約できます。

ステップ 3：連携プログラムの実装（kintone Webhook + freee API）

kintone Webhook の受信 → 仕訳ルール適用 → freee API への POST までを実装します。実装環境は AWS Lambda / Google Cloud Functions / kintone カスタマイズ JS など、規模と運用体制に合わせて選びます。仕訳ルールはコードのなかで関数として独立させ、テスト可能にしておくのが鉄則です。

ステップ 4：テスト環境での突合検証

freee の検証用事業所を用意し、過去 1〜2 ヶ月の実データを流して、API 連携が生成した仕訳と、経理担当者が実際に登録した仕訳を 1 件ずつ突合します。差異が出たら、ルールが漏れているのか、データが想定外なのかを切り分け、ステップ 1 に戻って明文化を更新します。このループを 2〜3 周回すと、本番投入できる精度に到達します。

ステップ 5：本番リリースと運用設計

本番投入時は、いきなり全量を自動化せず「自動仕訳した結果を一度ドラフトで保存し、経理担当者が承認したうえで本登録する」という Human-in-the-loop な構成を推奨します。1〜2 ヶ月運用してエラーが収束したら、定常パターンは完全自動、例外パターンのみレビュー、という形に切り替えていきます。エラー監視・リトライ・通知設計（Slack / メール）もこのフェーズで整えます。

API 開発のコスト感とスケジュール

「API 開発はコストが青天井になりそう」というイメージを持たれることがありますが、kintone × freee の自動仕訳に限れば、経験則として以下のレンジに収まることが多いです。

規模感	典型ユースケース	開発期間	初期費用レンジ
小規模（仕訳パターン 1〜3 種）	請求書発行 → 売上計上、経費申請 → 仕訳起票	4〜6 週間	80〜150 万円
中規模（パターン 4〜8 種、按分・条件分岐あり）	広告代理店の入金消込、プロジェクト別原価按分	2〜3 ヶ月	200〜400 万円
大規模（部門 / 全社横断、エラー監視・運用込み）	多事業部門の月次連携、本支店間振替、サブスク按分	3〜5 ヶ月	400〜800 万円

金額幅が大きく見えるのは、経理ルールの複雑さ（＝ステップ 1 で洗い出される分岐条件の数）に大きく依存するためです。逆に言うと、「ルール自体がシンプルなら、API 開発でも 1〜2 ヶ月・100 万円台で完成することも珍しくありません。標準プラグインの月額費用と比較しても、2〜3 年の TCO で逆転するケースも多くあります。

プラグイン vs API 開発 vs ハイブリッド — 判断軸

では、結局のところ「どのアプローチで連携すべきか」。判断軸は次の 3 つに整理できます。

観点	標準プラグイン	API 開発（フルカスタム）	ハイブリッド
得意な仕訳パターン	1 対 1 マッピング、定型の取引登録	複合仕訳・按分・条件分岐すべて	定型はプラグイン、複雑系のみ API
初期費用	低（数万〜数十万円）	中〜高（80〜800 万円）	中（プラグイン費＋部分開発）
月額運用費	あり（プラグイン利用料）	サーバー / 監視費のみ	あり（プラグイン分のみ）
ルール変更への柔軟性	低（プラグイン仕様の範囲内）	高（コードで自由に変更可能）	中
運用属人化リスク	低（標準ツールなので引継ぎ容易）	中（コード資産の保守体制が必要）	低〜中
向いているフェーズ	立ち上げ期 / 取引数が少ない	業務が固まった成長期以降	業務領域ごとに最適化したい段階

結論をシンプルに言えば、次のように整理できます。

• 仕訳パターンが 1 対 1 で済む業務（請求書発行→売上、経費精算→仕訳起票 など）は、標準プラグインで十分かつ最速
• 複合仕訳・按分・条件分岐が絡む業務（広告代理店の入金消込、プロジェクト別原価按分、サブスク按分 など）は、迷わず API 開発を選ぶべき
• 会社全体としてはハイブリッドが現実解。プラグインで標準業務を回しつつ、複雑な領域だけピンポイントで API 開発を入れる

はてなベースの kintone × freee API 連携支援

はてなベースは、kintone と freee の両方に深く触れてきた開発・経理コンサルティング両面の知見を活かし、「経理ルールの可視化」から「API 連携の実装」「本番運用」までを一気通貫で支援しています。プラグインで足りる業務はプラグインで、API 開発が必要な業務だけ API で——その判断と設計から、安心してお任せいただけます。

「自社の仕訳パターンが API 開発に向いているのか分からない」「現状の連携プラグインで限界を感じている」「月次決算をもっと早く締めたい」という段階でも、まずは一度ご相談ください。仕訳ルールのヒアリングから、概算スケジュール・コストの試算まで、初回はお打ち合わせベースで対応いたします。

kintone のデータが、そのまま freee の仕訳になる世界。それを実装可能な現実として、一緒に設計しませんか。お問い合わせは Web フォームまたはメールにて承っております。