kintone連携の方法と選び方｜サービスかカスタム開発か

kintone連携の成否は「APIで繋ぐ」と決めた瞬間ではなく、「何を・どの粒度で・どちらが正本データか」を決めた瞬間に決まります。

kintoneを基幹・会計・CRM・フォーム・チャットと繋ぎたい情シス・業務改善担当へ。この記事は連携手段のカタログではなく、4つの連携手段の選び方・データ連携の設計・現場で実際に起きる失敗を先にお見せするものです。読み終えて残るのは「どのサービスが良いか」ではなく、「自社の要件は連携サービスで足りるのか、カスタム開発が要るのか」を自分で判断できる物差しです。

株式会社六（Roku inc.）は福岡・北九州を拠点に、kintoneを含む業務システムの連携・開発を手がけています。立ち位置は「とにかくAPIで繋ぐ開発会社」ではありません。標準機能やノーコードで足りる範囲は無理に作らず、JavaScript・APIが本当に必要な要件にだけ手を入れます。だからこそ、連携の失敗を先に開示します。

kintone連携でできること・できないこと

kintoneは外部システムと繋ぐことで、データの二重入力や手作業の転記を消せます。代表的な連携先は、基幹・会計（受注・請求の同期）、CRM・SFA（顧客情報の一元化）、Webフォーム（問い合わせの自動取り込み）、EC（在庫・販売履歴）、チャット（LINE・Slack・Teams通知）です。

当社の実績では、サイボウズ株式会社のオンラインストアでkintoneとShopifyを連携し、在庫と販売履歴をkintone上で一括管理できるようにしました（ストア構築とアプリ開発を約3ヶ月で完了）。

ただし「連携=API開発」とは限りません。ルックアップの自動更新・自動採番・アプリ間連携は標準機能やプラグインで実現でき、公式・各社とも「基本機能で実現できない場合にのみカスタマイズを検討する」姿勢を推奨しています（出典：smartat.jp、kintone.cybozu.co.jp）。最初の問いは「どうAPIで繋ぐか」ではなく「APIを使わずに済まないか」です。これを飛ばすと不要な開発費を払い、後述の失敗を自分で抱え込みます。

なお、kintone自体の開発・カスタマイズの全体像はkintone開発・カスタマイズとはで、依頼先の選び方はkintone開発会社の選び方で整理しています。

kintone連携の4つの方法と選び方

連携の手段は、おおまかに4つに整理できます。

選び方は、サイボウズ公式が示すデータ量と複雑度の4パターンを上から順に潰すのが定石です（出典：cybozu.dev）。

1. データが少量・単発 → 手作業の転記でも足りる
2. 定期的に大量データを移す → CSV連携やETL/EAIツール
3. 複数システムを統合したい → 連携サービス・iPaaS
4. 上記で解決できない要件が残る → REST API・Webhookによる個別開発

いきなり4番（開発）から考えず、上から「これで足りないか」を潰し、残った要件だけを開発で繋ぎます。LINE・Slack・Teams等の実装手順は別記事で解説します（kintone×LINE/Slack連携の実装例）。

kintone API連携の基本：REST APIとWebhookの違い

API連携を検討するなら、対になるREST APIとWebhookの役割の違いを押さえるのが先決です。

REST APIは、外部システム側からkintoneのデータを取得・登録・更新・削除する仕組みです。在庫の一括更新や夜間の受注一括取り込みなど能動的な処理に使います。前提として、1回のAPI呼び出しで登録・更新・削除できるのは最大100件、複数レコード取得時のoffset上限は10,000件です（出典：cybozu.dev）。1,000件を更新するなら100件ずつ10回に分けるループ処理が必要です。

Webhookは逆方向で、レコードの追加・編集・削除などのイベントを起点に外部システムへ通知します。「申込が登録されたらSlackに知らせる」といった受動的な連携に向き、利用にはJavaScriptの知識かノーコードの連携サービスが必要です（出典：comdec.jp、toyokumo-blog.kintoneapp.com）。

見落とされがちですが、APIには明確な「天井」があります。

上限は1アプリ単位でカウントされます（統計取得など一部APIはカウント外。ライトコースは扱いが異なる／出典：cybozu.dev・正確な数値は要確認）。Webhookにも上限があり、通知は1分間に60回まで、1アプリあたり最大10件登録、ペイロードは1MBまでです（出典：community.cybozu.dev）。この天井が、次の設計章と失敗章の前提になります。

kintoneデータ連携の設計：どこでつまずくか

連携の成否は、コードを書く前の設計でほぼ決まります。

最初に決めるのは「正本データはどちらか」です。顧客マスターはCRM側が正でkintoneは参照だけか、案件はkintone側が正か。これを曖昧にしたまま双方向同期を組むと、両方で編集された同じレコードが衝突します。項目ごとに「どちらが正本か」を一覧化し、双方向にする必然性がなければ片方向に倒すだけで事故は大きく減ります。

次に「いつ・どれだけ」を決めます。リアルタイムが本当に必要か（多くの業務は数分〜1日のバッチで足りる）、全件を毎回流すのか変更分の差分だけ流すのか。ここで前章の天井が効きます。REST APIは100件/回、スタンダードは1万件/日/アプリが上限のため、全件を頻繁に流す設計は天井に当たります。差分更新とバッチ化は、性能対策であると同時にコスト対策です。なお、APIで定期的に大量更新する場合は対象アプリの「レコードの変更履歴を無効化」が推奨されます（有効のまま大量更新するとディスク容量を圧迫するため／出典：cybozu.dev）。

連携サービスで足りるケース／カスタム開発が必要なケース

定番の要件は、既製の連携サービスで解決できることが多くあります。たとえばトヨクモ社は、FormBridge（フォーム）・kViewer（外部閲覧）・kMailer（メール）・PrintCreator（帳票）・DataCollect（集計）・kBackup（バックアップ）の6製品を提供し、2026年1月時点で6製品合計15,000契約を突破しています（出典：toyokumo.co.jp）。フォーム受付・帳票出力・外部公開といった「よくある要件」なら、まずこうしたサービスで足りないかを確認するのが先です。

一方、次の要件は既製サービスの範囲を超え、JavaScript・REST APIによるカスタム開発が必要になります。

• 複数の外部API（在庫・物流・会計・生成AIなど）を横断して処理する
• 標準のWebhook/サービスでは表現できない条件分岐や加工がある
• 上限・冪等性を織り込んだ堅牢なデータ連携が要る

当社では、ChatGPT API・Shopify API・物流APIを統合し、1時間あたり400件規模の問い合わせを自動応答する仕組みを構築した実績があります。標準やノーコードの限界を超える部分にだけ開発を投じる——この線引きが、不要な費用を防ぎます。

kintone連携でよくある失敗と回避策

現場で実際に起きる3つの失敗を先に開示します。これを知っているかで設計の質が変わります。

失敗1：そもそもAPIが不要だったのに作り込んでしまう

最も多いのは技術選定のミスです。ルックアップ・自動採番・アプリ間連携は標準で可能で、定期バッチはCSV連携で足りることが多くあります（出典：smartat.jp、cybozu.dev）。「連携=API開発」と思い込んで発注すると、ノーコードで数日の要件に開発費を払うことになります。回避策は、前述の4パターンを上から潰すことです。

失敗2：Webhookの無限ループとサイレントなデータ欠損

Webhookで「レコード更新→外部処理→同じレコードを更新」と組むと、更新が再びWebhookを発火させ無限ループに陥ります（SNS自動投稿が何万件も走る事故が報告されています）。さらに通知は1分60回が上限で、61回目以降は通知が来ません。エラーも出ずにデータが欠ける、サイレントな欠損です（出典：community.cybozu.dev、ict4small.com）。回避策は、リアルタイムを安易に選ばないこと。更新ループを避ける条件設計と、バッチ・差分での再同期の方が安全なケースは多くあります。「リアルタイム＝善」ではありません。

失敗3：API上限超過と二重登録

API実行数には天井があります。スタンダードは1アプリ1万件/日を超えると翌朝9時頃に超過メールが届き、影響が重大な場合はAPI処理が中断されることもあります（出典：cybozu.dev）。業務時間中に連携が止まるリスクです。加えて、同じデータが同時に送られると、対策なしでは同一レコードが複数回登録されます。回避にはメッセージIDなどで重複を排除する冪等性の確保が必要です（出典：cybozu.dev、r3it.com）。「安く繋いだ後に詰まる」典型がこれです。

既製サービスで済むのか開発が要るのか判断が難しい場合は、当社のkintone×Shopify連携の実例が参考になります（実績：サイボウズ オンラインストア）。

外注する場合の進め方と費用感の考え方

外注する場合、要件定義の前に依頼側で決めておくと進行が速くなります。

• 正本データはどちらか（項目ごと）
• 更新頻度（リアルタイムかバッチか）と差分の扱い
• 連携サービスで足りる範囲はどこまでか
• 上限・障害時にどう振る舞ってほしいか

これらが曖昧なまま開発に入ると、手戻りと追加費用が発生します。依頼先の選び方は当社のサービスも参考にしてください。

費用は要件で大きく変わり、相場はあくまで目安です。開発会社系メディアでは、簡単なカスタマイズが数万〜10万円、中規模が10万〜50万円、複雑な開発は50万円以上、外部ツール連携は5万〜10万円程度から、というレンジが示されています（出典：hnavi.co.jp、pepacomi.com／いずれも目安・案件により変動）。重要なのは金額の多寡ではなく、「安く繋いだ後に上限やループで詰まる」設計を避けること。初期費用より、設計に上限・冪等性が織り込まれているかを確認してください。

よくある質問

Q. kintone連携にプログラミングは必要ですか？

要件によります。フォーム・帳票・通知などの定番要件は連携サービスやプラグインでプログラミングなしに実現できることが多く、複数APIの統合や独自の条件処理が必要な場合にJavaScript・REST APIによる開発が必要になります。

Q. 連携サービスとカスタム開発、結局どちらが安いですか？

定番要件なら連携サービスの方が安く速いのが一般的です。ただしサービスで表現できない要件を無理に組み合わせると、かえって運用が複雑になります。要件がサービスの想定範囲に収まるかが分岐点で、まずは既製サービスで足りないかを確認するのが定石です。

Q. API実行数の上限を超えたらどうなりますか？

スタンダードは1アプリ1日10,000件、ワイドは100,000件が上限です。超過すると翌朝9時頃に通知メールが届き、影響が重大な場合はAPI処理が中断されることもあります（出典：cybozu.dev）。差分更新・バッチ化で上限内に収める設計が前提です。

Q. 既存の基幹システムと連携できますか？

多くの場合、REST API経由で連携できます。鍵は技術よりも設計で、「正本データをどちらに置くか」「更新頻度と差分の扱い」を先に決めることが成否を分けます。基幹側のAPI仕様と合わせ、要件整理から進めるのが安全です。

連携の手段を選ぶ前に、「何を・どの粒度で・どちらが正本か」を決める。これが本記事で一貫してお伝えしたことです。

自社の連携要件が既製サービスで済むのか開発が必要なのか整理したい場合は、要件の壁打ちからお問い合わせください。無理にAPI開発を勧めることはせず、ノーコードで足りる範囲も含めて正直にお伝えします。