カスタマイズが想定通り動かない時、 ログを確認することでアクションの実行結果を確認できます。


当記事では、Job Runner(kintoneアプリのWebhook、定期実行タスク)のログの見方を解説します。

kintoneアプリのカスタマイズのコンソールログの見方は、下記のページをご確認ください。

コンソールログの見方(kintone アプリのカスタマイズ)


ログの表示方法

Job Runnerのログは、下記の操作で表示することができます。

  1. メイン画面(カスタマイズ画面)の「ジョブ生成・設定」ボタンを押す

  2. ジョブ設定画面で「実行履歴」タブを選択する

  3. 閲覧したい実行履歴右端の「1」を押す


すると、下記のようなログを表示できます。

ログをダウンロードして確認したい場合は、「ダウンロード」ボタンを押してください。


テスト実行の画面でも「ログ」タブをクリックするとログを確認できます。

こちらはログをダウンロードできないため画面上で確認してください。


アクションが実行されているかを確認する

カスタマインのアクションが実行されると、下記のようなログが記録されます。

[action 3] field_api.calc_age starting.

[action 3] field_api.calc_age done.


アクションが実行されているかを確認したい場合は、ログに [action 1] [action 3] のようなログが記録されていることを確認します。

action の後の数字がアクション番号です、


例えば、上で例に挙げたログは次のカスタマイズを実行した際のものです。


この時、実行を確認したいアクションの  [action 番号] がログに記録されていなければ、アクションは実行されていません。

また、アクションが実行されなかった場合、その理由の大抵は設定された条件にあります。


条件に指定されているフィールドに想定通りの値が入っているか、他の条件と相反する条件となっていないかなどを確認してみてください。


たとえば上記アクションで指定している条件「レコード1行が準備できた時」は、「レコード取得アクション」で指定したアクションで、レコードが1件以上取得されれば発生しますが、

1件も取得されない場合は発生せず、結果としてアクションは実行されないためログにも記録されません。


レコード取得時にkintoneに送信されたクエリを確認する

キーを指定してレコードを取得する」などのレコードを取得する「やること」は、アクション実行時にkintoneに送られたクエリがログに表示されます。


レコードの取得:

例えば下記のような「条件を組み立ててレコードを取得する」を使用してレコードを取得するカスタマイズが実行された時のログを見てみます。

[action 2] record_api.get_records_by_visual_query starting.

BEGIN GET https://xxxx.cybozu.com/k/v1/records.json

{'app': 686, 'query': '在籍状況 in ("在籍") limit 500 offset 0', 'totalCount': True}

END   GET https://xxxx.cybozu.com/k/v1/records.json

[action 2] record_api.get_records_by_visual_query done.


レコードの取得を行うと、「BEGIN GET」というログが記録されます。


「'app': 686」の部分が取得対象のkintoneアプリのアプリID、「 'query': '在籍状況 in ("在籍") limit 500 offset 0’」の部分が、kintoneに送信されたクエリです。


kintoneアプリのカスタマイズのコンソールログに表示されるログとは異なり、「query result length: 1」のようなクエリを実行した結果のレコード数はここには記録されません。


取得されたレコードを確認したい場合は、テスト実行の画面で確認を行うか、やること「ログにメッセージを出力する」の「メッセージ」にレコードを取得するアクションの結果を指定すると、取得されたレコードの内容を確認できます。


具体的な使用例だと、次のようになります。


このカスタマイズを実行すると、次のようなログが記録されます。

[action 6] other_api.put_log_message starting.

(6) 生年月日:2001-04-11

[action 6] other_api.put_log_message done.

[action 6] other_api.put_log_message starting.

(6) 生年月日:1996-06-21


レコードの追加・更新時に送られた値を確認する

レコードの追加:

やること「レコードを追加する」などでレコードの追加を行った場合、「BEGIN POST」というログが記録されます。

[action 8] record_api.insert_record starting.

[action 8] record_api.insert_record done.

BEGIN POST https://xxxx.cybozu.com/k/v1/records.json

{'app': 686, 'records': [{'生年月日': {'value': '1990-01-01', 'type': 'DATE'}, '社員番号': {'value': '9001', 'type': 'SINGLE_LINE_TEXT'}, '氏名': {'value': 'カスタマ太郎', 'type': 'SINGLE_LINE_TEXT'}, '在籍状況': {'value': '在籍', 'type': 'DROP_DOWN'}}]}

END   POST https://xxxx.cybozu.com/k/v1/records.json


また、「 'records':」以降では、実際にkintoneにレコード追加のために送られた各フィールドの値を確認することができます。


下記が「生年月日」フィールドの情報です。


{'生年月日': {'value': '1990-01-01', 'type': 'DATE'}


この情報は{'フィールドコード': {'value': '値', 'type': 'フィールドタイプ'}の構成になっています。想定された値がkintoneに問題なく送られているか確認したい場合は、このログを確認してみてください。


なお、「'type': 'DATE'」などのフィールドタイプの表記についての詳細は、下記のサイボウズ様のページをご確認ください。

フィールド形式


なお、やること「レコードを追加する」などのレコードを追加する「やること」は、「即時反映するかどうか」というパラメータを持っています。


このパラメーターに「即時反映しない(後でまとめて反映)」を指定した場合、レコードの追加はある程度溜めてからまとめて kintone アプリへ保存する動きになります。


そのため、ログを確認すると、やること「レコードを追加する」が実行されたタイミングより後に「BEGIN POST~」が記録される点に注意してください。


レコードの更新(「フィールドに値をセットする」も含む):

やること「キーの値をもとにレコードを更新する」、「フィールドに値をセットする」、「年齢を計算する」などの「やること」で「年齢をセットするフィールド」を指定してレコードの更新を行った場合、「BEGIN PUT」というログが記録されます。

BEGIN PUT https://xxxx.cybozu.com/k/v1/records.json

{'app': 686, 'records': [{'id': '5', 'revision': -1, 'record': {'$id': {'value': '5'}, '年齢': {'type': 'NUMBER', 'value': '34'}}}, {'id': '4', 'revision': -1, 'record': {'$id': {'value': '4'}, '年齢': {'type': 'NUMBER', 'value': '34'}}}, {'id': '2', 'revision': -1, 'record': {'$id': {'value': '2'}, '年齢': {'type': 'NUMBER', 'value': '23'}}}, {'id': '1', 'revision': -1, 'record': {'$id': {'value': '1'}, '年齢': {'type': 'NUMBER', 'value': '27'}}}]}

END   PUT https://xxxx.cybozu.com/k/v1/records.json


BEGIN PUT の後に続く{}で囲まれた部分は、GETやPOSTの時と同様に「’プロパティ名’:値」がカンマ(,)で区切られた構成になっています。


また、複数のレコードがまとめて更新される場合、「'records': [{1レコード目},{2レコード目},...]」のような構成でログが出力されます。

この時、出てくる「'id': '5'」の数字はレコード番号なので、更新されたレコードを特定するのに役立ちます。


Job Runnerでは、「フィールドに値をセットする」、「年齢を計算する」などの「やること」で「年齢をセットするフィールド」を指定してレコードの更新を行った場合や、アクションが実行されるたびに「BEGIN PUT~」が実行されるのではなく、ジョブ内の全アクションが終了した後に自動的に保存されます。


そのため、「BEGIN PUT~」によるレコード更新はログの最後にまとめて行われている点に注意してください。


アクションが正常に完了したかを確認する

アクションのログは、「starting」と「done」のセットで記録されます。

[action 3] field_api.calc_age starting.

[action 3] field_api.calc_age done.


「starting」がアクションの実行が開始した時のログで、「done」のログがアクションの実行が完了した時のログです。

アクションの実行時にエラーが発生するなどしてアクションが正常に完了しなかった場合は「done」のログが記録されません。


アクションが正常に完了したかどうかは、done のログが記録されているか否かで確認ができます。


アクションが正常に終了しない原因としては、主にエラーの発生が挙げられます。

例えば、APIトークンに必要な権限が指定されていなかった、条件の誤りによってフィールドが見つからないというエラーになった……などです。

そのような場合は、ログにエラーが表示されていますのでエラーメッセージを確認してみてください。


当サポートサイトでは、様々なエラー発生時の確認ポイントを記事にしており、例えば次のような記事があります。

Job Runnerで「関連レコード一覧の条件でレコードを取得する」を使おうとしたら「関連レコード情報がありません」エラーが出ます

Webhookのカスタマイズで「Webhookから URL を渡されていません。」というエラーが出ました

その他のエラーは、画面上部の検索ボックスで「エラー」と検索してみてください。


条件「レコード1行が準備できた時」と「レコード全行が準備できた時」の違い

Job Runnerのログを確認する際は、条件「レコード1行が準備できた時」と「レコード全行が準備できた時」の違いについて理解する必要があります。


条件「レコード1行が準備できた時」:

条件を組み立ててレコードを取得する」などが指定されたレコード取得アクションが複数のレコードを取得した場合、それに対する「レコード1行が準備できた時」をセットしたアクションは、並列で実行されます。


また、1行目のレコードに対する処理が終わるのを待たずに、2行目のレコードに対する処理が開始されます。


たとえば次のようなカスタマイズを実行した時のログを確認してみましょう。


条件「レコード1行が準備できた時」は、下記のように処理が実行されるため、アクション2で取得したレコードの数だけアクション3と5は実行されます。


下記の場合、レコード番号2のカスタマ太郎さんと、レコード番号1の粕田麻衣さんの2レコードが取得され、アクション3と5はレコードごとにそれぞれ実行されます。


ログ上でも、アクション3とアクション5がレコードの数だけ実行されていることが確認できます。

[action 2] record_api.get_records_by_visual_query starting.

BEGIN GET https://xxxx.cybozu.com/k/v1/records.json

{'app': 686, 'query': '在籍状況 in ("在籍") limit 500 offset 0', 'totalCount': True}

END   GET https://xxxx.cybozu.com/k/v1/records.json

[action 2] record_api.get_records_by_visual_query done.

[action 3] field_api.calc_age starting.

[action 3] field_api.calc_age done.

[action 3] field_api.calc_age starting.

[action 5] field_api.set_field_value starting.

[action 3] field_api.calc_age done.

[action 5] field_api.set_field_value done.

[action 5] field_api.set_field_value starting.

[action 5] field_api.set_field_value done.


このように、条件「レコード1行が準備できた時」が指定されたアクションは、

レコードの数だけ並列で実行されます。


条件「レコード全行が準備できた時」:

条件を組み立ててレコードを取得する」などが指定されたレコード取得アクションで、全てのレコードを取得し終わった後に一度だけ発生します。


たとえば、次のようなカスタマイズを実行した時のログを確認してみましょう。


条件「レコード全行が準備できた時」は、下記のように処理が実行されるため、アクション2で何レコード取得されても、アクション3と5はそれぞれ1回しか実行されません。


条件「他のアクションの実行が完了した時」と似ていますが、条件「レコード全行が準備できた時」はレコードが取得されなければ発生せず、

条件「他のアクションの実行が完了した時」はレコードが取得されてもされなくても、前のアクションの実行が完了すれば発生する点が異なります。


ログ上でも、アクション3と5が1回だけ実行されていることがわかります。

[action 2] record_api.get_records_by_visual_query starting.

BEGIN GET https://devkflowe.cybozu.com/k/v1/records.json

{'app': 686, 'query': '在籍状況 in ("在籍") limit 500 offset 0', 'totalCount': True}

END   GET https://devkflowe.cybozu.com/k/v1/records.json

[action 2] record_api.get_records_by_visual_query done.

[action 3] field_api.calc_age starting.

[action 3] field_api.calc_age done.

[action 5] field_api.set_field_value starting.

[action 5] field_api.set_field_value done.


以上が、基本的な Job Runner のログの見方についてのご案内でした。


ご不明点等ございましたら、チャットにてご質問ください!