ECサイトと会計ソフトや在庫管理をシステム連携すると、注文、請求書、在庫数がシステム間で自動的に受け渡されます。既存のプラグイン、連携プラットフォーム（Make、Zapier、n8n）、または個別開発のAPI連携によって実現できます。どの方法を選ぶかは、注文件数、お使いのシステム、そして誰がシステム連携を監視するかによって決まります。

手作業での転記は時間を奪い、ミスを生みます。この記事では、API、Webhook、フィードといった用語をわかりやすく解説し、データフロー図の作り方や、データの主導権、障害時の対応、運用コストなどの注意点を見ていきます。

手作業での転記にかかるコスト

手作業での転記は、時間のロス、入力ミス、処理の遅れを招きます。1日数件の注文なら対応できても、月数百件になればパートタイム1人分の業務量になります。

さらに高くつくのが入力ミスです。注文番号の打ち間違い、割引の反映漏れ、在庫の引き落としミスがあると、誤った請求書の発行や欠品商品の販売につながり、原因調査に追われます。修正伝票の発行やお詫びの連絡には、注文処理そのものより多くの時間がかかります。

反映の遅れも問題です。在庫を1日1回、夜間にまとめて更新していると、ECサイトには一日中「朝の在庫数」が表示されるため、最後の1点を二重に販売しやすくなります。

自社の数字を当てはめて試算してみてください。

1. ECサイトで月600件の注文を受ける。
2. 1件の会計ソフトへの転記と在庫の引き落としに3分かかる。
3. 合計で1,800分、つまり月30時間になる。
4. ミスの修正に月5時間かかる。
5. 合計で月35時間（4営業日以上）、年間420時間を失うことになる。

この時間に時給を掛ければ、システム連携にいくら投資すべきかが見えてきます。ただし、導入後の運用コストもあらかじめ見込んでおく必要があります。

API・Webhook・フィード・エクスポートの基本

API、Webhook、フィード、エクスポートは、いずれもデータを受け渡す4つの方法です。誰が、いつ、どのくらいの頻度でデータを求めるかが異なります。違いを理解しておくと、お使いのECサイトや会計ソフトで何ができるかを判断しやすくなります。

API（Application Programming Interface）は、レストランのウェイターのような存在です。欲しいものを伝えると、厨房から運んできてくれます。同じように、ECサイトは会計ソフトに請求書の発行を依頼したり、倉庫システムに在庫数を問い合わせたりします。優れたAPIでは、何を、どの形式で、どのくらいの頻度でリクエストできるかが明確に定義されています。

Webhookは玄関のチャイムです。会計ソフト側から5分おきに「新しい注文はありますか」と尋ねる必要はありません。注文が入った瞬間に、ECサイト側からチャイムを鳴らして知らせます。無駄な問い合わせをせずに、即座にデータを送れます。

フィードは、定期的に書き換えられる店頭のメニュー表です。商品情報、価格、在庫状況などをまとめたファイル（主にXML形式）で、価格比較サイトや取引先が定期的に読み込みます。データの流れは一方通行で、読み取る側が内容を書き換えることはできません。

エクスポートとインポートは、書類の詰まった箱を定期的に別のシステムへ運ぶ作業にあたります。たとえば経理担当者が週に1回、ECサイトから請求データをダウンロードして会計ソフトに取り込む方法です。最も手軽ですが、反映にタイムラグがあり、作業を忘れないように管理する必要があります。

社内のデータフロー図を作る

技術を選ぶ前に、社内でデータがどこを流れているかを紙に書き出してみましょう。各システム（ECサイト、会計ソフト、在庫管理、配送業者、銀行、Excel、メール）を四角で囲み、受け渡しているデータを矢印で結びます。

次の手順で進めます。

1. すべてのシステムを書き出す。注文データが通過するシステム、表計算シート、メールをすべて挙げます。
2. データごとに矢印を引く。注文、請求書、入金、在庫数、出荷、顧客情報それぞれの流れを描きます。
3. 手作業の箇所に印をつける。手入力やコピー＆ペーストをしている場所が、連携で効率化できるポイントです。
4. 二重入力を見つける。住所や価格などを2か所で入力していると、いずれ内容が食い違います。
5. 停止時の影響を想定する。システムが1時間止まったら、どこに注文が滞留し、誰がそれに気づくかを考えます。

特に時間を削減できるのは、次の4つのデータ連携です。

• ECサイトから会計ソフトへの注文連携
• 在庫管理からECサイトへの在庫数の反映
• 配送業者への出荷データ連携
• 銀行の入金明細と請求書の自動消込

データフロー図の作成は、会社と業務プロセスのデジタル化全体を進めるうえでも良い出発点になります。

データの主導権はどのシステムが持つか

ECサイトと会計ソフトを連携する際は、すべてのデータ項目に「マスターとなるシステム（唯一の情報源）」を1つだけ決める必要があります。他のシステムはそのデータを受け取るだけにします。このルールがないと、すぐにECサイトと会計ソフトで価格が食い違い、どちらが正しいのかわからなくなります。

小規模〜中規模のECサイトにおける一般的な分担は次のとおりです。

• 商品情報と説明文：ECサイト、または商品情報管理システム。
• 価格と在庫数：会計ソフトまたは在庫管理システムで管理し、ECサイトへ反映。
• 注文データ：ECサイトで発生し、会計ソフトへ転送するのみ。
• 請求書・会計伝票：会計ソフト（伝票番号の連番や税計算を管理）。
• 顧客情報：ECサイトで登録し、法人の請求先情報はチェコの公的事業者登録データベースであるARESなどで照合。

なぜすべてを双方向で同期してはいけないのでしょうか。両方のシステムで同時にデータが変更されると、誤った変更で上書きされたり、更新の無限ループに陥ったりしやすいためです。双方向の同期は本当に必要な箇所だけに絞り、発注時には各データの最終決定権がどのシステムにあるかを明記してください。

システム連携のもう1つの条件は、共通の識別コードを持つことです。

• 商品：共通の商品コードまたはJAN/EANコード（ECサイト側が「KR-50」、倉庫側が「krem50ml」では紐づけできません）。
• 法人顧客：法人番号（チェコの場合は事業者識別番号のIČO）。
• 入金：注文番号や請求書番号に基づく照合番号（チェコの銀行振込ではvariabilní symbolと呼ばれる識別番号が使われます）。

コードの統一は手間がかかりますが、最初に一度済ませておけば、その後の多くのエラーを防げます。

3つの連携手法とチェコならではの事情

連携を実現する方法は、既存プラグイン、連携プラットフォーム、個別開発のAPI連携の3つです。標準機能でどこまで対応できるか、費用はいくらか、誰が保守するかが異なります。

既存プラグインは最もスピーディーに導入できます。主要なECカートには定番の会計ソフト向けプラグインやエクスポート機能が用意されており、基本的な連携なら半日で設定できます。業務の大半をカバーでき、残りの例外だけを手作業で処理できるなら、最も合理的な選択肢です。

連携プラットフォーム（Make、Zapier、n8n）は、プログラミング不要の画面操作でサービス同士をつなぎます。料金は処理量に応じた従量課金が基本です。

• Zapierはタスク数に応じた課金（2026年11月時点で月100タスクまで無料）
• Makeはクレジット数に応じた課金（月1,000クレジットまで無料）
• n8nはクラウド版では実行回数に応じた課金で、標準版を自社サーバーで運用することも可能

シンプルな処理には向いていますが、1日数百件の注文や複雑な条件分岐があると、利用料が膨らみ、設定の全体像も把握しにくくなります。

個別開発による連携は、独自のルール（卸売価格表、複数倉庫、返品処理、セット商品など）がある場合や、システム数・注文件数が多い場合に適しています。ただし、初期投資と継続的な保守契約を見込んでおく必要があります。

チェコ市場での具体例

• Pohodaへの接続（Stormware社が提供するチェコで定番の会計ソフト）：XMLインターフェースを使い、ファイル単位のバッチ処理またはPOHODA mServer経由のオンライン連携を行います。内蔵HTTPサーバーとして動作するためPohodaを起動しておく必要があり、開発元は公開IPアドレスではなく社内ネットワーク内での運用を推奨しています。
• MoneyおよびABRA Flexi（いずれもチェコの代表的な会計・ERPソフト）：独自のインターフェースを備えていますが、利用できる機能はバージョンやライセンスによって異なるため、提供元への確認が必要です。
• 銀行：たとえばチェコの銀行であるFio bankaのAPIを使うと、口座の入出金明細を自動取得して入金消込を行えます。
• ARES：チェコの公的な事業者登録データベースで、公開インターフェースを通じて事業者番号（IČO）から法人の請求先情報を自動補完・確認できます。
• 配送業者（チェコで広く使われるZásilkovna、PPL、DPDなど）は、手入力なしで送り状の発行や追跡ができるインターフェースを提供しています。
• 価格比較サイト（チェコ大手のHeureka、Zboží.czなど）は、ECサイトと同じ「唯一の情報源」から出力された商品・価格・在庫のフィードを読み込みます。

トラブルが起きたときの備え

どんなシステム連携も、通信障害やデータ形式の変更、認証キーの期限切れによって止まることがあります。重要なのは、異常に1分で気づけるか、1か月後まで気づかないかです。

堅牢な連携には3つの安全策が組み込まれています。

• 再試行：一時的な通信エラーが起きた際、自動で処理を再実行します。
• 通知：データの受け渡しに失敗したとき、決められた担当者へアラートを送ります。
• ログ記録：通信履歴を残し、何がなぜ失敗したのかを後から追跡できるようにします。

APIの制限事項にも注意が必要です。たとえばFio bankaのAPI仕様書（2025年10月16日付バージョン1.9）では、同じトークンは30秒に1回しか使用できず、それを超えるとエラーが返されます。また、トークンの有効期限は最長180日間で、自動延長を有効にしたうえで誰かがインターネットバンキングにログインしたときのみ延長されます。こうした細かな仕様によって、半年後に連携が静かに止まってしまうことがあります。

もう1つのリスクは外部サービスの仕様変更です。配送業者や銀行は新しいバージョンのインターフェースを公開し、古いものを廃止していきます。誰かが更新情報を追い、連携プログラムを改修しなければなりません。

本番稼働の前には、必ずコピーデータやテスト環境で検証してください。返品、赤伝票（返金伝票）、クーポンコード、二重決済、発送後のキャンセルといった例外パターンも一通り試しておきます。

認証キーは安全に保管し、必要最小限の権限だけを付与し、委託先を変更する際は必ず再発行してください。詳しくは企業のためのサイバーセキュリティの記事で解説しています。

ECサイトと会計ソフト連携の費用と発注方法

ECサイトと会計ソフト連携の費用は、初期構築費と、継続的な運用・保守費の2つに分かれます。数年間で見ると、運用・保守費の合計が初期費用を上回ることも珍しくありません。

初期構築費は、システムやデータフローの数、インターフェースの品質、例外処理（返品、赤伝票、セット商品、複数倉庫など）の複雑さによって変わります。運用費には、プラットフォームやプラグインの利用料、サーバー代、監視、仕様変更への対応が含まれます。既存プラグインは各社の料金表に準じ、個別開発は要件の範囲によって決まります。私たちの業務システム開発は18万チェココルナ〜、在庫連携付きのECサイト構築は14万チェココルナ〜承っています。

注文が月に数十件程度で、週1回の手動エクスポートで回っているなら、システム連携はまだ採算に合いません。転記作業に毎週何時間も取られている場合、ミスが繰り返されている場合、あるいは処理の遅れで顧客を逃している場合に投資価値が生まれます。個別開発を選ぶ際は、将来開発会社を変更できるよう、ソースコード、認証キー、仕様書の権利が自社に残ることを確認しておきましょう。

要件を整理してから発注すると、無駄なコストを抑えられます。

まずは最も負担の大きい流れ（一般的にはECサイトから会計ソフトへの注文連携）から着手するのがおすすめです。ECサイト、会計ソフト、在庫管理の連携をご検討中なら、まずは私たちのプロジェクトコンフィギュレーターで初期プランを作成してみてください。

よくある質問