kintone連携が急に動かなくなったら、最初に何を確認しますか？

最後に正常終了した日時と、最初に失敗したレコードを特定します。そのうえで、連携元の状態、連携キー、実行ユーザーの権限、接続先のエラーを順に確認します。最初から再設定すると原因が消えるため、失敗した入力とログを残してから調べます。

Webhookと定期実行はどちらが向いていますか？

すぐ次工程へ渡す必要がある処理はWebhook、漏れを回収する処理や一括同期は定期実行が向きます。どちらか一方に寄せず、Webhookで即時処理し、定期実行で未処理を回収する組み合わせが実務では扱いやすいです。

接続先、認証方式、連携キー、起動条件、成功条件、エラーの確認場所、再実行方法、変更履歴が1枚にまとまり、別の担当者がテスト用レコードで一巡できる状態です。

kintoneのアプリ単体は動いているのに、申込後のレコードが作られない。契約書は送れたがステータスが戻らない。完了メールだけ飛ばない。複数サービスをつないだ後のトラブルは、各製品の画面だけ見ても原因が分かりません。

必要なのは、連携を「設定の集まり」ではなく、1件の申込が最後まで進む業務として管理することです。

「送信ボタンを押せた」を成功にしないのがポイントです。次の工程が使うIDや状態が保存されたところまでを成功とします。業務全体の書き出し方は業務設計の6ステップも参照してください。

「レコードが追加されたら実行」と「契約送信可になったら実行」は別です。入力途中の追加で動かすと、宛先や金額が空のまま次工程へ進みます。ステータス変更を起点にする場合も、誰がどの条件で変更するかを決めます。

kintoneの公式資料では、Webhookはレコードの追加・編集・削除、コメント、ステータス更新をきっかけに外部へ通知できます。一方、REST APIは外部側が実行した時点で取得・登録・更新します。即時通知と定期回収を役割分担させます。

会社名やメールアドレスは変わり、重複もします。受付番号、kintoneレコードID、契約文書ID、請求書IDを別々に持ち、同じ案件を結べるようにします。連携キーを決める前に、データ定義書の7項目で名前と型を揃えると手戻りが減ります。

kintoneでは「契約中」、電子契約では「送信済み」、会計では「未請求」。意味の違う状態を1列へ上書きすると、どこまで進んだか分からなくなります。申込状態、契約状態、請求状態を分け、各サービスの状態をそのまま保存します。

設定者の異動、パスワード変更、権限変更で止まる連携があります。実行に必要な管理権限とアプリ・レコード・フィールドの権限を一覧にし、個人のアカウントだけに依存しない運用を決めます。kintone REST APIも、取得するレコードやフィールドの閲覧権限が必要です。

通信エラーのたびにレコードを作り直すと、重複契約や二重請求につながります。「未処理」「処理中」「完了」「要確認」を持ち、同じ受付番号を再実行しても二重登録しない条件を置きます。エラー本文だけでなく、発生日時、工程、対象ID、再実行日時、対応者を残します。

フィールド名の変更、選択肢の追加、必須化、テンプレート差し替えは、隣の連携へ影響します。変更依頼には対象、理由、影響する工程、テスト結果、反映日、戻し方を記録します。設定画面のスクリーンショットだけでは、判断理由と復旧手順が残りません。

即時処理はWebhook、漏れの発見は定期確認に分けます。たとえば毎朝、前日までの「契約完了なのにメール未送信」「請求対象なのに請求書IDなし」を一覧にします。エラーが出なかったことではなく、業務上の未完了が残っていないことを確認します。

サイボウズの公式チュートリアルは、kintone Webhookの送信は1分間に60回までと案内しています。大量更新を行う処理では、上限と再試行を前提に分けてください。仕様は変更されるため、実装時は最新の公式資料で確認します。

この台帳を作ったら、設定者以外がテスト用の申込を1件流し、エラー確認と再実行まで行います。読める手順書ではなく、別の人が復旧できた手順書が完成です。