日本の中小企業を蝕む「SaaS連携の谷間」問題 — なぜツール同士がつながらないのか

日本の中小企業のバックオフィスは、ツールに囲まれている。

受発注にCOREC。会計にfreee。名刺管理にEight。勤怠にジョブカン。給与にマネーフォワード。請求書管理にバクラク。CRMにZoho。メールはGmail、チャットはSlack。

個別に見れば、どれも優秀なSaaSだ。それぞれが自分の領域で業務を効率化してくれる。

問題は、ツール同士の間にある。

「受注したら、請求書を作る」という当たり前の流れ

CORECで受注したら、次にやることは請求書の作成だ。

CORECの受注管理画面を開いて、取引先名を確認する。品目を確認する。金額を確認する。freeeの請求書画面に移って、取引先を選ぶ。品目を入力する。金額を入力する。税率を指定する。保存する。

受注が10件なら10回。50件なら50回。COREC画面とfreee画面を交互に開いて、数字を目で読んで手で打つ。

この「COREC→freee」の転記作業を、日本中のバックオフィス担当者が毎日やっている。

そして驚くべきことに、CORECとfreeeの間には公式の連携機能が存在しない。

なぜつながらないのか

CORECを運営するラクーンコマースは東証プライム上場。利用企業は85,000社以上。freeeも東証グロース上場で、利用事業所は50万以上。

どちらも大規模なSaaSだ。にもかかわらず、直接の連携機能はない。

理由を推測すると、3つの構造的な問題がある。

構造1：連携はビジネス判断

SaaSの連携機能を開発するには、コストがかかる。API設計、認証フロー、テスト、保守。相手先のAPI仕様変更に追随する継続的な工数も必要だ。

freee側から見て、CORECとの連携は「やったほうがいい」の域を出ない。freeeが対応すべきサービスは山ほどある。Salesforce、kintone、マネーフォワード、バクラク。ユーザー数が多い連携から優先的に開発される。85,000社のCORECは、50万社以上のfreeeから見れば優先順位が低い。

COREC側も同じだ。CORECの主要な連携先はスーパーデリバリー（同じラクーングループ）で、freeeとの連携開発にリソースを割く動機が薄い。

結果として、両社のユーザーが毎日手作業で転記する状況が放置されている。

構造2：N×M問題

日本のバックオフィスSaaSは、ざっと数えても数十種類ある。

受発注（COREC、CO-NECT、Bカート）、会計（freee、マネーフォワード、弥生）、請求書（freee、マネーフォワード、バクラク、invox）、名刺（Eight、myBridge、CamCard）、CRM（Salesforce、Zoho、HubSpot、kintone）、勤怠（ジョブカン、KING OF TIME）、給与（マネーフォワード、freee、SmartHR）。

仮に30のSaaSがあったとして、すべての組み合わせを連携させるには 30×29÷2 = 435通りの連携が必要になる。

現実に435通りの連携を開発・保守するのは不可能だ。各社は自社にとって最も重要な数件の連携だけを開発し、残りは放置する。

CO-NECTはfreeeとの連携を実装した。CORECは実装していない。Eight連携はSalesforceにはあるが、Zohoにはない。マネーフォワードとfreeeは競合だから、当然つながらない。

ユーザーが使っているSaaSの組み合わせが「たまたま」連携を持っているかどうかは、運次第だ。

構造3：API公開≠連携

「APIが公開されているんだから、つなげばいい」という意見がある。

CORECにもAPIはある。freeeにもAPIはある。技術的にはつなげる。

だが、両方のAPIのOAuth認証を実装し、トークンの自動更新を処理し、データのマッピング（CORECの「品目」とfreeeの「品目」のフィールド名が違う）を実装し、エラーハンドリングとリトライを組み込み、freeeのAPIレート制限（1分あたり300リクエスト）を考慮し、税率の計算ロジックを正しく実装する。

これを中小企業のバックオフィス担当者にやれと言うのか。

GAS（Google Apps Script）で書く猛者もいる。だが、それは「GASが書ける人が社内にいる」という前提であり、その人が辞めたら連携は止まる。Excel VBAの属人化と同じ構造だ。

freeeの連携状況

freeeのアプリストアには多数の連携サービスが掲載されている。

連携がある主要サービス

CO-NECT → freee会計（受発注→会計連携あり）
Salesforce → freee（CRM→会計連携あり）
kintone → freee（データベース→会計連携あり）
Shopify → freee（EC→会計連携あり）
Square → freee（POS→会計連携あり）

連携がない主要サービス

COREC → freee（なし）
Eight → freee（なし）
myBridge → freee（なし）
KING OF TIME → freee請求書（勤怠→請求書連携なし）

「連携がある」サービスと「連携がない」サービスの差は、技術力ではなく、ビジネス上の優先順位で決まる。

CORECの連携状況

CORECの外部連携は極めて限定的だ。

スーパーデリバリーとの連携（同グループ）
CSVエクスポート/インポート
API（ただし公式の連携先リストは公開されていない）

freeeへの直接連携はない。マネーフォワードへの連携もない。弥生への連携もない。

CORECのユーザー85,000社は、どの会計ソフトを使っていても、受注データの転記を手作業でやるしかない。

数字で見る「手作業の量」

1件あたりの転記時間

CORECの受注データをfreeeの請求書に手で転記する場合：

CORECで受注詳細を開く — 15秒
取引先名、品目、数量、単価を確認する — 30秒
freeeの請求書画面を開く — 10秒
取引先を検索・選択する — 20秒
品目、数量、単価を入力する — 45秒
税率を確認・設定する — 10秒
保存する — 10秒

合計：約2分20秒。

月間の影響

月間受注件数	転記にかかる時間
10件	約23分
30件	約70分（1時間10分）
50件	約117分（約2時間）
100件	約233分（約4時間）

月100件の受注がある会社は、毎月4時間を転記作業に費やしている。年間48時間。丸2日分だ。

しかもこの時間は「最速で間違いなく転記した場合」の数字だ。実際には転記ミスの発見・修正、画面の読み込み待ち、電話や来客での中断を含めると、もっとかかる。

ミスのコスト

転記ミスの確率は、人間の手作業で一般に**2〜5%**と言われる。

月100件の受注を手転記して、ミス率が3%なら月3件の転記ミス。請求金額の間違い、品目の取り違え、税率の誤り。発覚すれば再発行。発覚しなければ過請求や過少請求。取引先との信頼関係にも影響する。

CSVエクスポート/インポートは解決策か

「CSVで出して、CSVで入れればいい」という意見は多い。

やったことがある人なら分かるが、そのままでは使えない。

フォーマットの不一致

CORECのCSVには「取引先コード」「受注番号」「注文日」「品名」「数量」「単価」「税率」「合計」が入っている。

freeeの請求書インポートCSVには「取引先」「品目」「数量」「単価」「税区分」「請求日」「支払期日」が必要だ。

列名が違う。順番が違う。日付フォーマットが違う（COREC: 2026/03/15、freee: 2026-03-15）。税率の表記が違う（COREC: 10%、freee: 課税10%）。

CSVをそのまま渡しても、freeeは受け付けない。Excelで開いて、列を並べ替えて、ヘッダを書き換えて、日付フォーマットを変換して、税率表記を変換する。

これを毎月やる。

先頭ゼロの消失

Excelの有名な罠。CSVに含まれる取引先コード00123をExcelで開くと、123になる。先頭のゼロが消える。電話番号も銀行コードも同じ。

これに気づかずfreeeにインポートすると、取引先コードが不一致でマッチングに失敗する。

この問題はCORECとfreeeだけではない

CORECとfreeeは一例にすぎない。

同じ構造の問題が、日本のバックオフィスのあらゆる接点で起きている。

名刺管理→CRM：Eightで名刺をスキャンして、Zoho CRMに手で入力する
請求書→全銀フォーマット：請求書PDFを目で読んで、振込データを手で作る
勤怠→給与計算：KING OF TIMEの勤怠データをCSVで出して、マネーフォワード給与に手で入力する
EC→会計：BASEの売上データをCSVで出して、弥生に手で入力する
問い合わせ→CRM：Gmailに来た問い合わせをコピーして、Salesforceにリード登録する

すべてのパターンに共通するのは、**「ツールAのデータを人間がコピーしてツールBに貼る」**という構造だ。

ツールは進化した。クラウドになり、AIが搭載され、UIは洗練された。でもツール間の「橋」は、依然として人間の手作業に依存している。

なぜ海外ではこの問題が薄いのか

海外（特にアメリカ）ではZapier、Make（旧Integromat）、n8nといった**iPaaS（Integration Platform as a Service）**が普及している。

Zapierは6,000以上のアプリを接続できる。QuickBooksとShopifyをつなげたい？ Zapierで5分で設定できる。コードは書かない。

日本でZapierが普及しないのには理由がある。

日本固有のSaaSがZapierに対応していない。COREC、スーパーデリバリー、Eight、ジョブカン。日本のバックオフィスSaaSのほとんどがZapierコネクタを持っていない。
日本語対応の問題。Zapierのインターフェースは英語。日本の経理担当者にとっては心理的ハードルが高い。
API公開の遅れ。日本のSaaSはfreee、マネーフォワード、kintoneなど一部を除き、APIを公開していないか、公開していても機能が限定的。

結果として、日本の中小企業には「つなぐ」手段がない。APIもiPaaSもない。残るのはCSVと手作業だ。

2024年に変わり始めたこと

freee受発注の終了

2024年10月31日、freee受発注がサービスを終了した。

freeeが自前で受発注機能を提供する試みは、結局うまくいかなかった。受発注はfreeeの本業（会計）ではない。専業のCORECやCO-NECTに機能面で勝てなかった。

これにより、freeeユーザーで受発注機能を使っていた企業は、COREC等の外部サービスに移行せざるを得なくなった。そして移行先には、freeeとの連携がない。

CO-NECTのfreee連携

競合のCO-NECTは、freee会計との直接連携を実装している。受発注データからfreeeの会計仕訳を自動作成できる。

CO-NECTの導入企業は39,000社。CORECの85,000社より少ないが、連携の有無で選ばれるケースは増えている。

APIエコノミーの拡大

freeeは開発者向けAPIを積極的に公開しており、連携パートナーも増加傾向にある。ただし、すべてのSaaSとの連携をfreee自身が開発するモデルは持続不可能であり、サードパーティによる連携ソリューションの需要は増え続けている。

解決の方向性

SaaS連携の谷間を埋める方法は、大きく3つある。

方向性1：SaaSベンダー同士の直接連携

最もシンプルだが、最もスケールしない方法。N個のSaaS同士をすべてつなげるにはN×(N-1)÷2の連携が必要で、30サービスなら435通り。現実的ではない。

方向性2：iPaaS（Zapier、Make等）

海外では標準的な解決策。だが日本のSaaS対応が進んでいない。日本版iPaaSとしてはBizteXやAnyflow等が出ているが、対応サービス数はまだ限定的。

方向性3：中間データ層

AとBを直接つなぐのではなく、間にデータを置く場所を設ける。AからデータをCSVやAPIで取り出して中間層に入れ、そこからBにデータを送る。

Excelが事実上の中間データ層として使われている。COREC→Excel→freee。Eight→Excel→Zoho。手作業のCSV変換を人間がやっているだけで、構造としてはiPaaSと同じことをしている。

問題は、Excelが「受動的な」中間層であること。データは人間が手で入れて、手で出す。自動化されていない。

もしExcelが「能動的な」中間層だったら——つまり、データの取り込みも、変換も、送り出しも自動でやってくれたら——SaaS連携の谷間は埋まる。

まとめ

CORECとfreeeの間に橋がない。Eightとfreeeの間にも橋がない。日本のバックオフィスSaaSは個々に優秀だが、連携の不在が手作業を生み出している。

この問題は構造的だ。SaaSベンダーにすべての連携を期待するのは非現実的で、海外のiPaaSは日本のSaaSに対応していない。日本の中小企業は、ツールに囲まれながら、ツールの間を手作業で往復し続けている。

受発注→会計。名刺→CRM。請求書→振込。問い合わせ→対応管理。

すべてのパターンで、同じ構造の問題が繰り返されている。ツールは進化した。でもツール間の「橋」は、まだ人間の手で架けている。

この記事のデータは以下の情報源に基づいています：COREC公式サイト（85,000社、ラクーンコマース）、freee公式情報（50万事業所以上）、CO-NECT公式サイト（39,000社）、freee受発注終了のお知らせ（2024年10月31日）。