SaaSと業務アプリを連携する｜更新方向・再処理・確認担当

SaaSとAPIで連携できると分かっても、設計はまだ終わりません。どちらのデータを正として更新するのか、失敗した処理を誰が再実行し、誰が結果を確認するのかまで決める必要があります。ここが曖昧だと、正常時には動いていても、同じ処理が二重に届いたときや更新の順序が逆転したときに、どちらを残すべきか判断できません。

項目ごとに、食い違いが起きたときに採用する側を「正本」として決め、同期方向と復旧担当を連携台帳に記録します。その台帳を使い、二重送信、順序逆転、通知失敗、通知されない更新経路を試すと、障害時にも正しい値へ戻せるかを確認できます。

以下の製品仕様は、2026年9月26日時点で確認したkintoneとStripeの公式情報に基づきます。一方、顧客名と受注状態を扱う台帳および受入試験は、設計方法を示す架空の条件例であり、実在する顧客の事例や当社の導入実績ではありません。

SaaSのAPI連携では、項目ごとに正本を決める

「既存SaaSを残すか」と「残したSaaSのデータをどう同期するか」は別の判断です。前者を検討中なら、先にSaaSの増加と二重入力を整理する判断軸で、残すサービスと自社業務アプリへ移す業務の境界を整理します。残すと決めた後の管理単位はデータ項目です。項目ごとに正本を選びます。

たとえば、顧客情報は既存SaaSで整備を続けたい一方、受注判断は自社業務アプリの申請・承認を通して確定させたい場合があります。この条件で「両方から更新できるようにする」と、便利になるように見えます。では、同じ顧客名や受注状態が両側で異なったとき、どちらが誤りなのでしょうか。正本がなければ、連携処理には決められません。

正本は、値を確定させる業務操作と、その操作を担う人に合わせて決めます。閲覧先やコピー先が多いという理由だけでは決まりません。

架空例：顧客名と受注状態を分ける連携台帳

次の表は、既存SaaSを顧客管理に残し、自社業務アプリで受注の申請・承認を行うという架空の条件例です。担当名は役割で置いているため、実際の設計では組織内の担当者と代行者に置き換えます。

この分け方なら、顧客名の修正先は既存SaaS、受注状態の確定先は自社業務アプリです。双方向連携という曖昧な要件が、項目ごとの片方向更新に変わります。再実行者と確認担当を分けたのは、処理を動かせたことと、業務上正しい値になったことが同じ確認ではないからです。

台帳には、少なくとも次の判断を同じ行に残します。

• 正本はどちらか
• どちらからの更新を許可するか
• 同期方向はどちら向きか
• 競合した更新を止めるか、正本の値で戻すか
• 失敗した処理を再実行する担当は誰か
• 最終結果を業務上確認する担当は誰か

いずれかが空欄なら、APIの接続試験が成功しても運用判断は未完成です。とくに「再実行者」だけを決めて「確認担当」を置かないと、処理の成功記録は確認できても、正しい顧客名や受注状態になったかは判断できません。

Webhookを同期起点にするときの見落とし

Webhookは、サービス上の操作をきっかけに外部へ通知する仕組みです。画面からの更新が通知されても、ファイル読み込みやAPIからの更新が同じように通知されるとは限りません。採用する更新経路ごとの確認が必要です。

kintoneでは、レコードの追加・編集・削除、コメントの書き込み、ステータス更新はWebhookの通知対象です。一方、ExcelまたはCSVの読み込み、複数レコードの一括削除、複数レコードを一括操作するREST APIによる操作では通知されません。これはkintone公式ヘルプ「Webhookを設定する」で確認できる製品固有の仕様です。

採用する更新経路ごとに、Webhookの通知対象になるかを確認します。対象外の経路が業務に必要なら、その経路を禁止するのか、別の同期手段または担当者による再実行を用意するのかを決めます。通知自体が作られない変更は、通知の失敗ログを監視するだけでは発見できません。

順序逆転を無条件の上書きにしない

自社業務アプリから受注状態を送った後、古い更新が遅れて既存SaaSへ届く場合を考えます。後から到着した処理を常に採用すると、到着順が業務上の新旧と一致しない場面で、受注状態を古い値へ戻しかねません。再送回数を決めるだけでは防げません。上書きを受け入れる条件が要ります。

kintoneの1件更新APIには、期待するリビジョン番号（レコードの版番号）を指定する方法があります。指定した番号が実際のリビジョン番号と一致しない場合、エラーとなりレコードは更新されません。リビジョンを指定しない場合、またはマイナス1を指定した場合は検証されません。kintone REST API公式ドキュメント「1件のレコードを更新する」に記載された仕様です。

このリビジョン番号の照合が検出するのは、更新先のレコードとの競合です。送信元の通知が新しいか古いかまで判定する機能ではありません。古い通知の内容に、取り直した最新の宛先リビジョン番号を付けて再送すると、古い値でも更新を通せてしまいます。

架空の受注状態の連携では、次の二つを分けて確認します。

送信元の版を確認してから宛先へ書き込むまでに競合しないよう、同じ対象への処理を一件ずつ順に行うか、反映済み版と宛先リビジョン番号の確認・更新を一組で制御します。更新日時だけを版の代わりに使う場合は、同時刻の変更や時計のずれを区別できるか確認が必要です。

順序を比較できる版が取れない場合は、通知を合図に正本の現在値を取得し直して同期する案があります。この場合も対象ごとの同時処理を制御し、古い取得結果が後から上書きされないようにします。Stripeの公式資料も、同社のWebhookでは生成順での配信を保証せず、必要な情報をAPIで取得する方法や、処理済みイベントIDを記録して重複を扱う方法を案内しています（Stripe「Webhook」）。これはStripeの仕様であり、kintoneの配信順を示すものではありません。

受注状態の例は業務上の状態項目を指します。kintoneのプロセス管理の「ステータス」は1件のレコードを更新するAPIでは変更できないため、使用する項目とAPIを別途確認します。

失敗を見つける担当と、再処理する担当を結ぶ

Webhookは設定すれば必ず届くわけではありません。kintoneでは、通知頻度の上限を超えた操作では通知されず、送信データが最大サイズを超える場合やkintone側のタイムアウトでも通知に失敗し得ます。kintone公式ヘルプ「Webhookの実行ログを確認する」で確認できます。

同じ実行ログでは、通知の成否、通知ID、操作の種類、操作の実行者、実行日時を確認できます。画面上の範囲より古いログは監査ログで確認し、監査ログを確認できるのはcybozu.com共通管理者に限られます。つまり、日常的に失敗を確認する担当だけを置いても、古い事象の調査に必要な権限が所在不明なら復旧は止まります。

運用設計では、次の役割をつなげます。

• 実行ログで失敗を見つけ、対象の通知IDと操作を特定する担当
• 古い事象が必要なときに監査ログを確認できる管理者
• 正本と現在値を確かめて再実行する担当
• 同期後の顧客名または受注状態を確認する業務担当

復旧時の記録には、通知元、処理ID、送信元レコードID、受信した版、反映済みの版、処理結果を残します。同じ処理IDを再び受けた場合と、別IDの古い更新が遅れて届いた場合を区別するためです。IDが通知元のどの範囲で一意かも確認します。再実行担当はこの記録と正本を照合し、業務担当が同期後の値を確認して完了にします。

連携台帳を受入試験へ変換する

台帳の判断は、異常系で崩れないことを確認して初めて実装条件になります。次の表も架空の設計例です。実際には、利用するSaaSの公式仕様と自社業務の更新経路に合わせて期待結果と担当者を確定します。

通知失敗でも、宛先に反映済みと確認できた処理は再適用せず、適用結果が分からない処理は再実行を保留します。

合否を「エラーが出なかった」にしないことが重要です。顧客名なら既存SaaS、受注状態なら自社業務アプリという正本が守られ、再実行後の値を確認担当が判断できることを合格条件にします。二重送信と順序逆転は処理の到着方法を、通知失敗と通知対象外の更新経路は復旧の受け渡しを試しています。

契約前に連携・運用保守の範囲を確認する

連携の実装範囲は、画面やAPI接続だけでは見積もれません。連携台帳の対象項目、通知対象外の更新経路、競合を止める条件、再実行の操作、ログを確認する権限までが範囲に影響します。開発費を整理するときは、業務システム開発の費用を左右する範囲と合わせて、初期開発と運用保守のどちらに含めるかを確認します。

Cotomuでは、自社業務に合わせたWebアプリについて、受発注、申請承認、作業報告など困っている業務ひとつから相談できます。初期開発と運用保守は個別見積もりで、連携・移行・権限・データ出力の範囲を契約前に確認します。

連携したい項目を台帳へ書き出し、正本、同期方向、再実行者、確認担当に空欄がないか確かめます。顧客名と受注状態の例のように、値を管理する人と復旧操作をする人を対応付けるところから始められます。業務アプリの相談では、現在のSaaSと連携したい業務をもとに範囲を整理できます。