freeeを使う企業のCRM選びは、「どのCRMがfreeeと連携できるか」より先に、「どの連携方法の型で、どのデータを、どこまで同期したいか」を決めると、候補が自然に絞れます。 連携方法には、freeeアプリストアの連携アプリ、iPaaS、API自作、CSVの4つの型があり、型によって同期できるデータの範囲と、導入後の運用負荷が大きく変わるためです。
営業はCRMで案件を管理し、請求と入金はfreeeで処理する——この二つのシステムの間で、取引先名や金額を人が転記している状態が、CRM選びの出発点になることが多いはずです。製品名の比較から入ると、機能の多さに目が向き、運用開始後に「入金状況がCRMで見えない」「取引先が二重登録される」といった問題が表面化します。
この記事では、製品名の優劣ではなく、自社の条件に当てはめて決めるための判断基準を整理します。
この記事でわかることは、次の4点です。
- 連携方法は4つの型に分かれる ── アプリストアの連携アプリ、iPaaS、API自作、CSVの違いと向く条件を比較します
- 同期したいデータは4種類で考える ── 取引先・見積・請求・入金のどこまでをCRMに戻すかで、必要な連携の深さが決まります
- 公式で確認できる連携の有無を表で示す ── freeeアプリストアと各社の公式情報で確認できた範囲だけを載せています
- HubSpotとSync for freeeの場合の具体 ── インストール場所、同期の範囲、導入時の確認手順を示します
freee連携のCRM選びで最初に決めるべき3つの軸
CRMの候補を並べる前に、判断の軸を3つに絞ります。軸が曖昧なまま製品を比較すると、デモの印象で決まってしまい、導入後に運用が回らなくなります。
軸1:連携方法の型
連携方法の型は、最初に決める軸です。型が決まると、必要な工数、保守の担い手、変更への強さがほぼ決まります。freeeアプリストアに掲載された連携アプリを使うのか、iPaaS(複数のSaaSをつなぐ連携基盤)で組むのか、freeeのAPIを使って自作するのか、CSVで取り込むのか。次の章で、4つの型を比較します。
軸2:同期したいデータの範囲
同期の対象は、取引先、見積、請求、入金の4種類に分けて考えると整理しやすくなります。営業の情報をfreeeへ渡す方向(取引先・見積・請求)と、freeeの結果をCRMへ戻す方向(入金状況)では、必要な仕組みが異なります。後者は、一度きりの転記では実現できず、定期的な更新の仕組みが要ります。
軸3:運用負荷と責任の所在
連携は、作って終わりではありません。freee側の仕様変更、CRM側のプロパティ変更、担当者の入れ替わりが起きたときに、誰が直すのかを決めておく必要があります。アプリ型は提供元が追随する前提、iPaaSは設定した担当者が追随する前提、API自作は開発した担当者が追随する前提です。保守の担い手を自社に置けるかどうかが、軸3の中心です。
| 判断軸 |
決めること |
決めないと起きること |
| 連携方法の型 |
アプリ・iPaaS・API・CSVのどれを主にするか |
後から別の型へ作り直しになる |
| 同期データの範囲 |
取引先・見積・請求・入金のどこまでか |
入金状況が見えないなど、期待とのずれが出る |
| 運用負荷と責任 |
変更時に誰が直すか |
担当者の異動で連携が止まる |
連携方法の4つの型を比較する
freeeとCRMをつなぐ方法は、大きく4つの型に分かれます。型ごとに向く条件が違うため、優劣ではなく、条件との相性で選びます。
型の比較表
| 連携方法の型 |
仕組み |
向く条件 |
| freeeアプリストアの連携アプリ |
freee側の審査を経たアプリが、画面上の操作で連携を提供する |
標準的な業務フローで、設定中心で始めたい |
| iPaaS |
ノーコードの連携基盤で、トリガーとアクションを組み合わせる |
複数のSaaSをまたぐ自動化を、柔軟に組みたい |
| API自作 |
freeeのAPIを使い、自社の要件に合わせて開発する |
独自の業務ルールがあり、開発と保守の体制がある |
| CSV |
一方のシステムから書き出し、もう一方へ取り込む |
件数が少ない、または一度きりの移行が中心 |
freeeアプリストアの連携アプリ
freeeのアプリストアには、「販売管理・SFA・CRMアプリ」というカテゴリがあり、ページ上ではfreee for Salesforce、board、freee for kintoneなどが掲載されています(freeeアプリストア(freee))。アプリ型の利点は、連携の入口が公式に整理されていること、画面の操作で設定できることです。一方で、同期できる項目と方向は、アプリごとに決まっています。標準にない項目を同期したい場合は、アプリの範囲を超えます。
iPaaSとAPI自作
iPaaSは、複数のSaaSをまたぐ自動化に向きます。たとえばYoomでは、freee請求書を操作するアプリが公開されており(freee請求書の連携アプリ(Yoom))、HubSpotに取引が作成されたらfreee請求書に見積書を作る、といったテンプレートも用意されています。柔軟な反面、フローの設計と保守は設定した側の責任です。
API自作は、freeeが公開する開発者向けのAPIを使います。会計API、請求書API、販売APIなどが用意されています(freee Developers Community(freee))。自由度は最も高い一方、認証の管理、エラー時の再実行、仕様変更への追随といった保守が、すべて自社の責任になります。
CSV
CSVは、仕組みを作らずに済む手軽さがあります。ただし、入金状況のように継続的に変わる情報をCRMへ戻す用途には向きません。CRM側のインポートは、ファイル形式、ヘッダー行、一意の識別子の指定といった要件があります(インポートファイルの要件(HubSpotナレッジ))。移行時の一度きりの取り込みには有効ですが、日常の運用を支える連携としては、担当者の手作業が残ります。
同期したいデータ別に、確認すべきこと
同期するデータごとに、型の選び方が変わります。ここでは、取引先・見積・請求・入金の4種類について、確認すべき観点を整理します。
データ別の確認表
| 同期したいデータ |
確認する観点 |
HubSpotとSync for freeeで公式に確認できる範囲 |
| 取引先 |
方向(CRM→freee、双方向)、重複の防止、コードの採番 |
HubSpotの会社からfreee会計の取引先を作成。コードの自動採番と重複チェックの記載あり |
| 見積 |
取引の金額・品目が反映されるか |
取引から見積書を作成。品目・単価も反映すると記載 |
| 請求 |
見積から請求への変換、継続請求への対応 |
見積書を請求書に変換。月次・継続の請求に対応する機能も記載 |
| 入金 |
freeeの入金状況をCRMで見られるか、更新の頻度 |
入金状況を「freee取引」の決済状況へ反映。定期的なバッチ処理で更新と記載 |
取引先は「重複」と「コード」が論点
取引先の同期で起きやすい問題は、同じ会社がfreeeにもCRMにも別名で存在することです。同期の方向と、重複をどう判定するかを先に確認します。freee側には取引先コードがあり、ここの扱いはアプリや連携方法によって異なります。そのため、同期できる項目と更新できない項目は、導入前に各アプリの公式ページで確認しておくことが大切です。
見積と請求は「金額と品目の持ち方」が論点
見積・請求を連携するときは、CRMの商品項目と、freeeの品目をどう対応させるかが中心になります。CRMで数量と期間をどう持つか、請求の単位をどう分けるかを決めておかないと、freee側の金額が想定とずれます。ここは、連携の型よりも、CRM側の商品設計が結果を左右します。
入金は「戻す仕組み」があるかが論点
入金状況をCRMで見られると、営業は未入金の顧客へのフォローを、経理に確認せずに行えます。freee会計の入金消し込みをCRMへ戻すには、定期的な更新の仕組みが要ります。アプリ型では提供元が仕組みを持ち、iPaaSやAPI自作では自社で定期実行を組むことになります。CSVでは、この用途は実質的に手作業になります。
各CRMのfreee連携を、公式で確認できた範囲で整理する
次の表は、freeeアプリストア、freeeのサポートページ、各社の公式ページで確認できた範囲を整理したものです。順位や優劣を示すものではありません。掲載がないことは、連携できないことを意味しません。iPaaSやAPIで連携できる場合があります。
連携の有無と入口
| 製品 |
公式で確認できる入口 |
確認できた連携内容 |
| HubSpot |
HubSpot App MarketplaceのSync for freee、freeeアプリストア |
取引先の同期、見積書・請求書の作成、取引のfreee会計への登録 |
| Salesforce |
freee for Salesforce(freeeアプリストア) |
商談・商品データからの見積書・請求書の作成、入金状況の確認、取引先の連携 |
| kintone |
freee for kintone(freeeアプリストアに掲載) |
連携内容は、アプリの公式ページで確認 |
freee for Salesforceの内容は、freee会計のSFA連携ページで、見積書・請求書の作成、入金状況のSalesforce上での確認、取引先マスタの同期などとして紹介されています(Salesforce×freee会計の連携(freee))。boardも、アプリストアの同じカテゴリに掲載されていますが、連携の詳細は各アプリのページで確認してください。
この表に載っていない製品については、アプリストアの掲載、各社公式の連携一覧、iPaaSのテンプレートの順に確認します。掲載が見つからない場合でも、APIでの連携が可能かどうかを、各社のドキュメントで確認できます。
HubSpotとSync for freeeの場合の具体
HubSpotでfreee連携を行う場合の具体を示します。StartLinkは、HubSpotゴールドパートナーであり、Sync for freee / Sync for Notion の開発元です。ここでは、公式に公開されている範囲で説明します。
同期の範囲とインストールの場所
Sync for freeeは、HubSpotとfreee会計・freee請求書をつなぐアプリです。HubSpotのApp Marketplaceに掲載されており、取引先の同期、取引からの見積書・請求書の作成、成約した取引のfreee会計への登録を、HubSpotの画面から行えます(Sync for freee(HubSpot App Marketplace))。機能と対応範囲の詳細は、Sync for freeeの製品ページにまとめています。

インストールの流れは、次のとおりです。管理者権限が必要です。
- HubSpotにログインし、ナビゲーションバーの「マーケットプレイス」アイコンから「HubSpotマーケットプレイス」を開く
- 「Sync for freee」を検索し、掲載情報ページの「インストール」をクリックする
- 設定アイコンから「連携」>「接続されたアプリ」を開き、Sync for freeeが表示されることを確認する
- freeeアカウントとの認証と、商品項目のマッピングを設定する
- テスト用の会社と取引で、取引先の作成、見積書の作成、請求書の発行を一通り確認する
認証と項目マッピングの具体的な設定は、Sync for freeeの使い方マニュアルで確認できます。インストールのメニュー名は、アプリのインストール方法(HubSpotナレッジベース)の表記に合わせています。
入金状況をHubSpotで見る
インストールすると、freee会計の「取引」に対応するアプリ専用のオブジェクト「freee取引」が作られ、入金状況が決済状況として反映されます。更新は定期的なバッチ処理で行われ、HubSpotのワークフローアクションとして、未入金の請求書や未決済の取引を確認する機能も用意されています。

他の型との組み合わせ
Sync for freeeで足りる範囲と、足りない範囲を見分けることも大切です。標準の同期範囲に含まれない独自の項目や、他のSaaSを含む多段の自動化は、iPaaSやHubSpotのワークフロー、カスタムコードで補う設計になります。StartLinkでは、連携アプリで埋められる部分は連携アプリで、それ以外の部分だけを個別に設計する形を基本にしています。HubSpotとfreeeの連携方法そのものは、HubSpotとfreee会計の連携方法の記事で整理しています。
自社の条件に当てはめて型を決める判断表
ここまでの内容を、自社の状況から型を決める表にまとめます。複数に当てはまる場合は、最も重い条件を優先します。
状況別の判断表
| 自社の状況 |
優先して検討する型 |
理由 |
| 取引先・見積・請求を標準の流れで連携したい |
アプリストアの連携アプリ |
設定中心で始められ、保守の主体が提供元にある |
| 入金状況をCRMに戻して営業が確認したい |
戻す仕組みを持つアプリ、または自社で定期実行を組む型 |
継続的な更新の仕組みが要る |
| freee以外のSaaSも含めて自動化したい |
iPaaS |
複数のSaaSをまたぐフローを組みやすい |
| 独自の請求ルールや承認の仕組みがある |
API自作、または連携アプリ+追加設計 |
標準範囲を超える部分の設計が要る |
| 移行時に一度だけデータを揃えたい |
CSV |
仕組みを作らず、一度の取り込みで足りる |
導入前に確認する手順
型の候補が決まったら、次の順で確認します。

- 同期したいデータを、取引先・見積・請求・入金の4種類で書き出し、方向(CRM→freee、freee→CRM)を決める
- 候補の連携について、公式ページで「同期できる項目」と「できない項目」を確認する
- CRM側のプロパティ、商品項目、パイプラインの設計を、連携の前提に合わせて整える
- テスト用のデータで、取引先の作成から請求書の発行、入金の反映までを通しで確認する
- 変更時の担当者と、問い合わせ先を決めて、運用ルールに残す
連携の成否は、製品の機能より、CRM側の商品設計とデータの持ち方で決まります。連携ツールを選ぶ前に、請求の単位、品目の対応、取引先の識別方法を決めておくと、型の選択がほぼ決まります。
運用負荷の見方と、導入の進め方
連携の導入は、設定して終わりではなく、運用を含めて設計します。StartLinkでは、現状の整理・要件定義、設計・構築、データ移行、テスト・検証、定着・運用改善の順に進めます。
導入の進め方
まず、現状の請求業務を書き出し、どこで転記が起きているかを確認します。次に、同期するデータの範囲を決め、CRM側の設計を整えます。そのうえで、スモールスタートとして、取引先の同期と見積書の作成から始め、運用が安定してから請求や入金の反映へ広げます。一度にすべてを連携すると、不具合の原因を切り分けにくくなるためです。準委任の形で伴走し、運用しながら調整する進め方が、定着しやすいと考えています。
運用負荷のチェック項目
| 観点 |
確認すること |
見落とすと起きること |
| 仕様変更への追随 |
誰が、どの頻度で確認するか |
連携が止まっても気づかない |
| エラー時の対応 |
失敗した同期をどう検知し、再実行するか |
請求漏れが起きる |
| 権限と認証 |
連携に使うアカウントの管理者は誰か |
担当者の異動で認証が切れる |
| 設計の記録 |
項目の対応関係を文書化しているか |
担当者が変わると誰も直せない |
企業様によって最適な形は異なりますので、請求の件数、承認の流れ、他のSaaSとの関係を踏まえて、型を選ぶことをおすすめします。国内の会計連携の全体像は、CRMと会計の連携設計の記事でも整理しています。会計ソフト側の比較はクラウド会計ソフトの選び方、CRMと販売管理の連携の型は販売管理システムとCRM連携の比較、AIから操作する連携はfreee HubSpot MCP連携の記事で扱っています。
よくある質問
Q1. freeeと連携できるCRMは、アプリストアに載っているものだけですか
いいえ。アプリストアに載っているものは、freeeの審査を経た連携アプリの入口です。それ以外のCRMでも、iPaaSやfreeeのAPIを使って連携できる場合があります。ただし、その場合は連携の設計と保守が自社の責任になるため、保守の担い手を先に決めておく必要があります。
Q2. 入金状況をCRMで見られるかは、どう確認すればよいですか
候補の連携について、公式ページで「入金」「決済状況」「消し込み」といった語を探し、方向(freeeからCRMへ戻すか)と更新の頻度を確認します。記載がない場合は、提供元に問い合わせるか、テストデータで実際に反映されるかを確認します。
Q3. CSVだけで運用することはできますか
件数が少なく、入金状況をCRMで見る必要がない場合は可能です。ただし、CSVの書き出しと取り込みは担当者の手作業になり、転記ミスや更新の遅れが残ります。件数が増えたり、営業が入金状況を確認したくなったりした時点で、連携アプリやiPaaSへの切り替えを検討します。
Q4. HubSpotとfreeeの連携は、HubSpotのどのプランでも使えますか
Sync for freee側のプラン(Free / Professional / Enterprise)によって、使える機能と件数の上限が異なります。製品ページでは、取引先・商品項目の同期、見積書・請求書の作成、入金消し込みは全プランの機能、月次請求はProfessional以上、合算請求・前受請求・原価管理はEnterprise以上と案内されています。HubSpot側の契約プランの要件は、公式ページで確認できた記載がないため、ここでは断定しません。最新の内訳は製品ページとHubSpot App MarketplaceのSync for freeeの掲載ページで確認してください。
Q5. 既存のCRMから乗り換えるときも、同じ判断基準で選べますか
はい。乗り換えの場合は、これに加えて、既存のデータの移行方法と、移行後の件数照合が必要です。取引先のコードや重複の扱いを、移行前に決めておくと、freee側との対応関係が崩れにくくなります。
まとめ:freee連携のCRM選びは「型・データ・運用」の順に決める
freeeと連携できるCRMを選ぶときは、製品名から入らず、次の順で決めると判断がぶれません。
- 連携方法の型を先に決める ── アプリ、iPaaS、API自作、CSVの違いを、保守の担い手と合わせて選びます
- 同期するデータを4種類で書き出す ── 取引先・見積・請求・入金のうち、CRMへ戻す入金の扱いが、型の選択を左右します
- 公式で確認できる範囲だけで比べる ── 同期できる項目と、できない項目を、導入前に公式ページで確認します
- スモールスタートで広げる ── 取引先と見積から始め、請求・入金へ広げます
- 変更時の担当者を決める ── 連携は、設定より運用の設計が結果を左右します
最初の一歩としておすすめするのは、現在の請求業務で転記が起きている箇所を、取引先・見積・請求・入金の4種類に分けて書き出すことです。そこから、必要な型が見えてきます。
自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。