「recordsでWebhook通知」を検知してみよう！ - アールスリーインスティテュート

公開日：2025-04-04

注意

本記事は情報提供を目的としており、本記事の内容は無保証、サポートの対象外です。
サポート窓口、問合せ窓口にご質問をいただいても対応いたしかねますのでご了承ください。

はじめに

みなさんこんにちは、サポートの沖です。

先月、意図しないタイミングでWebhook通知が送信されるという障害が発生しましたね。kintoneの仕様ではWebhook通知が送信されるのはユーザーのレコード操作や、APIを使った1レコードの追加や更新だけで、そのために60回制限も設定されています。Webhookの設定についてはサイボウズさんのページもご確認ください。https://jp.cybozu.help/k/ja/app/set_webhook/webhook.html

今回は、Webhook通知が送信されないAPIを利用した複数レコードの更新でも、Webhook通知が送信されるという障害でした。サイボウズさんの案内はこちらのページです。
https://cs.cybozu.co.jp/2025/010849.html

そのため、想定外のタイミングで送信されたり、送信されることで無限ループになったりと、かなり影響範囲が大きかったと思います。ただ、裏で動いている仕組みではあるので気づいていない人もいるかも？

カスタマインでもJob Runnerの動作に影響があり、対応についてはこちらでご案内しております。https://support.gusuku.io/ja-JP/support/discussions/topics/36000035863

また、その時の障害対応についてはこちらもお読みいただければ！

ドキュメンタリー：障害発生時の中のひと

サポートでも状況の整理と回答をどうするのかなどで多重で対応が走っていました。当然のことながら通常の問い合わせもありましたので私はそちらを担当していて、Slack上の情報を時々確認という感じでした。

重要な情報があるとサポートチームのビデオ会議上で共有していたので、情報伝達の方法は色々と組み合わせておくと便利だなー、という感じでした。皆さんも緊急時の情報共有で便利だった仕組みがあれば教えてください！

で、その対応中に、「問題が解消した時に気付けるように出来るかな？」と思ったので検知する仕組みを仮作成しました。その時の時間がこんな感じで、思い立ってから15分くらいかな？

とりあえず5分間隔の定期実行で観測していたら、アプリのあるkintone環境では19:00過ぎには解消していたようです。（計測大事

とはいえ、また発生した場合は早めに気づきたいよなぁ、ということでもう少しちゃんとした仕組みを作ってみました。（誰得？

機能の整理

先ほどのカスタマイズは使っていないアプリを利用していたので、様々な部分を簡略化していました。例えば。。

アプリは誰も編集しないので、レコード編集のWebhookが発生しないという前提
レコードを追加するだけなのでアプリを常に見ておく必要がある
- アプリでレコード作成時間を見て人間が判断する必要もある

などです。ですので、以下のような点を考慮する必要があります。

誰かがレコードを編集してWebhook通知が送信されても除外できる
アプリを見にいくのは大変なので何かで通知して欲しい
せっかくなので、通知して欲しい人を自由に選択したい
最新チェック日時がわかると安心できるので何かのフィールド値でわかるようにしたい

などです。

これらの動きを実現出来るように、まずはアプリの設定から進めてみます。

アプリを作成してみる

今回は１アプリでrecordsの更新とWebhook通知発生時のkintoneの通知が出来るようにしてみます。「レコード更新用ダミー文字列」の値を変更することでWebhook通知を送信する仕組みです。

Webhook通知が送信された時はレコード追加でkintoneの通知を発生させる想定なので、無限ループにならないように「通知を送信する条件」は「レコードの編集」だけにします。

また、通知先を指定したレコードを自由に追加・編集できるようにするので、kintoneの通知はフィールド値で判定するように設定しました。

これにより、レコード保存（追加や更新）時に「結果」のフィールド値が「発火」になった時だけ、通知先のユーザーへkintoneの通知が送られるという動きになります。

メモ

kintoneの通知で条件を指定していた場合、最初に値が変わった時だけが一致します。今回のように「発火」に変えた後、そのレコードを何回保存しなおしても通知されません。テーブル内フィールドの例がわかりやすいと思います。

https://jp.cybozu.help/k/ja/notifications/app/record_condition.html

なお、レコード追加時は初回なので通知され、レコード編集時は一度「正常」で保存しなおしてから再度編集画面で「発火」にして保存すると通知になります。なので、この後、「kintoneアプリのカスタマイズ」で変更できないようにしておきます。

「定期実行」でrecordsでWebhook通知の部分を作成

設定はこちらになります。

シンプルに通知対象のレコードを取得して値をセットしています。常に値が変わるようにセットする値は「now 関数」にしました。

ポイントは「フィールドに値をセットする」を使うと処理後にrecordsでレコード更新される事です。これは実行ログでも確認ができます。

2025-03-25T05:03:34.375Z [action 3] field_api.set_field_value done.
2025-03-25T05:03:34.375Z BEGIN PUT https://xxxx.cybozu.com/k/v1/records.json
2025-03-25T05:03:34.376Z {'app': 631, 'records': [{'id': '1', 'revision': -1, 'record': {'$id': {'value': '1'}, 'レコード更新用ダミー文字列': {'type': 'SINGLE_LINE_TEXT', 'value': '2025-03-25T05:03:34Z'}}}]}
2025-03-25T05:03:34.711Z END   PUT https://xxxx.cybozu.com/k/v1/records.json
2025-03-25T05:03:34.711Z ended.

この実行ログの最後のようにアクションの実行後に、BEGIN PUT　省略　/v1/records.json と出力されている部分がJob Runnerのレコード更新の出力です。

メモ

Job Runnerでは変更になるレコードのデータをまとめて更新します。更新対象になるのはフィールド値が変わったものだけなので、同値をセットしている場合は更新から除外されます。またいろいろなアプリのレコードに対して値をセットしている場合もアプリ単位の更新データが作成されて更新になります。kintoneのレコード操作のレコード構造そのままの出力なので、詳細はサイボウズさんのページもご確認ください。

https://cybozu.dev/ja/kintone/docs/rest-api/records/add-records/#request

このように、取得したレコード内のフィールド値を変更するときは「キーの値をもとにレコードを更新する」でレコード番号をキーにして更新するのではなく「フィールドに値をセットする」を使うようにしてください。

基本的にJob Runnerでレコード番号をキーにしてレコード更新をするような「やること」を設定している場合は「フィールドに値をセットする」や「フィールド値をまとめてセットする」に置き換え可能と覚えていただくと良いと思います。

「kintoneアプリのWebhook」で通知を受け取った時の処理を作成

Webhook通知が送信された時に、レコード追加でkintoneの通知が送信されるようにします。

設定では、「結果」を「発火」にして、通知先にはWebhook通知で送信されたレコードの通知先の値をセットしています。

また、元々の「定期実行」のレコード更新はアプリのAPIトークンで実行なので更新者はAdministratorになることが決まっています。そのため、更新者を判定することでログインユーザーのレコード更新時のWebhook通知の時を除外するようにしています。

当然、Administratorとしてログインしてレコードを編集した場合は除外できません。ただ、Administratorを常用というのはあまりない状態と思うので、特に対策は取りません。

「kintoneアプリのカスタマイズ」で細々設定

「結果」のフィールドは通知に関係するので、ログインユーザーは変更できないようにしておきます。

今回のWebhook通知は通常は発生しない動きなので、動作確認も大変です。「定期実行」でWebhook通知が送信される動きを試せるように、詳細画面にボタンを配置しておきます。ボタンを押すと「kintoneアプリのWebhook」を実行するという仕組みです。

これで、動作確認も簡単になりますね。

レコードの状態

通知用のレコードはこんな感じ。更新日時が最終チェック時間なので、午前と午後の2時と8時を少し過ぎていても更新がない場合は動いていないということになります。今は17:40くらいなのでちゃんと動いているようです。

テスト時のレコードです。作成日時がWebhook通知があった時の大体の時間なので、後で確認するときに重要な情報になります。今回はテストレコードなので、日時に意味はないのではありますが（汗

最後に

おそらく２度目は無いような気はしつつも、全体の仕組みを忘れそうなのでブログに残しておきました。

「何かがあった場合」、というカスタマイズは作成が簡単なのですが、「何もなかった場合」や「ないはずなのに何かがあった場合」、というのは設定が難しくなります。今回はテストや誤操作対応もあったので、

kintoneの機能
「定期実行」
「kintoneアプリのWebhook」
「kintoneアプリのカスタマイズ」

と、ほぼ全ての設定を使って実現することになりました。年額1000の場合はアプリスロット数とかを気にしなくて良いのでこういう時にさっと作れて便利です。

なお、1日に4回チェックして、それぞれの実行時間が1秒ちょっとなので、ざっくり計算で3分間/月のようです。Job Runnerに割り当ては１アプリスロットで180分なので約1.7%くらいの使用量という見込みです。これだと使用量にはあまり影響はなさそうですね。

Job Runnerは割り当てられた時間内であれば、カスタマイズはいくつでも作成できます。

皆さんもちょっとした自動チェックを作成してみると練習になると思います。ぜひお試しください！

メモ

kintoneのJavaScriptカスタマイズは、ユーザーがアプリを操作した時だけ実行されます。カスタマインの場合もJavaScriptカスタマイズを生成できますが、Job Runnerの仕組みがあるのでユーザーを介さない処理が可能です。

つまり、Job Runnerを使ったカスタマイズを作成して自動化ができると言うことは、人件費の削減につながると言うことになります。

この点が通常のJavaScriptカスタマイズやプラグインなどとは違う点です。是非、様々な自動化を作成してJob Runnerを使っていきましょう！（お弁当注文アプリを作ってアプリの作り方に慣れるというアレと一緒ですね）

投稿者プロフィール

沖: "サイボウズ公認kintoneエバンジェリスト
カスタマインやデプロイットでも色々とやってます"