処理の流れと項目の対応
- JSON文字列
- Parse JSON
- 型と必須項目を検査
- 必要なら配列を展開
既に構造化されたWebhookやHTTP出力は、追加のParse JSONが不要な場合があります。
| 項目 | 用途・保存先 |
|---|---|
| request_id | 受付を識別する文字列 |
| items[] | 明細配列。必要な場合だけ展開 |
| items[].qty | 数値型と許容範囲を確認 |
受け取る構造を一つに決める
今回の入力は、受付IDと明細配列を持つオブジェクトです。例は {"request_id":"REQ-401","items":[{"sku":"A01","qty":2}]} とします。WebhookやHTTPで既に構造化されている出力はそのまま項目を割り当てられる場合があり、JSONらしく見えるからといってParse JSONを重ねる必要はありません。
JSON文字列と項目の集合を区別する
Parse JSONはJSON形式の文字列を解析するために使います。入力にオブジェクトそのものを渡す場合は、変換が必要なのか、前段の出力項目を直接参照すればよいかを確認してください。ダブルクォート、バックスラッシュ、改行が壊れた文字列は有効なJSONではありません。見た目だけで括弧を足す修正は避けます。
データ構造を定義して項目を割り当てる
Parse JSONのData structureでサンプルから構造を作り、request_idを文字列、itemsを配列、qtyを数値として確認します。サンプルにない任意項目まで自動的に理解されるとは考えず、必要なフィールドを明示します。手動で出力を確認してから後続モジュールへつなぎ、何がどの型で渡るかを照合します。
ルート配列と入れ子配列を分ける
ルートがオブジェクトなら一つの出力にitems配列が含まれます。その明細を一件ずつ処理するときにIteratorを使います。一方、ルートが配列のParse JSONは要素ごとの複数出力になるため、さらに同じ目的のIteratorを足す前に実際の出力件数を見てください。配列の要素数と通知回数を先に決めておくと増幅を発見できます。
未指定・null・空文字を扱い分ける
{"memo":null}、{"memo":""}、memo自体がない入力は意味が異なります。受付IDがなければ保存を止め、任意のメモだけがなければ既存値を保持するなど、項目ごとのルールを作ります。qtyが"2"という文字列だった場合に自動変換へ任せるか拒否するかも決め、ゼロや負数が許されるかと合わせて確認します。
送信用JSONは構造から作る
別APIへ渡す本文はCreate JSONやHTTPのData structureを使い、項目として値を割り当てます。文字列の連結でJSONを作ると、問い合わせ文に引用符や改行があるだけで壊れます。入力例に引用符を含む件名を入れ、送信先が同じ文字列を受け取ることを確認してください。認証情報は本文へ混ぜません。
出力件数とエラーを確認する
明細2件、明細0件、受付ID欠落、JSON構文エラーを試します。0件で後続が動かない場合に、必要な受付記録まで失われないか確認します。構文解析の成功は業務上の正しさを意味しないため、IDや数量の検査は別に行います。配列展開後の保存・通知数も利用量へ含め、想定以上のクレジット消費を防ぎます。
Makeで小さな自動化から始める
まず練習用データで必要な処理を確認し、利用量と機能に合うプランを選んでください。登録時の料金・特典・適用条件は公式画面で確認できます。
Make公式サイトで登録する広告リンク利用量から費用を確かめる
月の処理件数、課金対象のステップ数、再試行を入力し、サービスごとに異なる課金単位を確認できます。
費用を試算する参照した公式情報
料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。
- JSON modules — Make情報確認日: 2026-10-30
- HTTP Version 4 — Make情報確認日: 2026-10-30
- Make pricing — Core at 10,000 monthly credits情報確認日: 2026-10-28
- Make credits情報確認日: 2026-10-26
- Make scenario settings情報確認日: 2026-10-26
