AIの出力に商品名や分類が入っているのに、Makeの次のモジュールで項目を選べない。そんなときは、見えているJSONが「文字列」なのか、すでに項目へ分解されたデータなのかを確かめます。JSONという同じ名前でも、受け取る処理と作って送り出す処理は逆向きです。
Parse JSONはJSON形式の文字列を項目として扱うために使い、Create JSONは用意した項目からJSONを作ります。両方を機械的に置く前に、前後で何を渡しているかを見ると、不要な変換や件数の取り違えを減らせます。
画面にJSONが見えるだけでは判断できない
実行履歴を開き、前のモジュールの出力を見ます。長い一つの文字列の中に商品名や価格が含まれているのか、商品名、価格といった項目を別々に選べる状態なのかを確かめてください。見た目の波括弧だけで変換の要否を決めないようにします。
外部サービスの応答は、モジュール側ですでに解析されている場合もあります。その場合、さらにParse JSONを挟むことが必要とは限りません。一方、AIの回答欄にJSONが文章として返っているなら、次へ渡すために解析する工程が必要になります。
Parseという言葉は、ここでは形式を読み取り、各項目を扱える形にする操作です。価格が正しいか、商品が実在するかを確認する意味ではありません。形式として解析できたものでも、内容の事実確認は別に行います。
小さなサンプルでデータ構造を決める
MakeのJSONアプリでは、データ構造が項目の形を表します。公式ではJSONのサンプルから構造を生成する方法や、Parse JSONを手動実行して構造を認識させる手順が案内されています。項目が出ないときは、後続の接続を増やす前にこの段階を見直します。
サンプルには実際に使う項目と型を入れます。例えば商品IDは文字列、価格は数値、確認が必要かどうかは真偽値というように、意味を決めておきます。「0012」のようなIDを数値にして先頭ゼロを失うと、後から元商品と対応できなくなる可能性があります。
最初から大量の本番データを使わず、個人情報のない一件で試してください。構造を作るためのサンプルに、顧客の住所や認証情報を入れる必要はありません。サンプルの内容と、本番の取り込み元は区別して記録します。
一件のオブジェクトと、複数件の配列を分ける
一件の情報を波括弧でまとめたものと、複数の情報を角括弧で並べた配列では、Parse JSONの出力のされ方が異なります。Make公式では、オブジェクトなら一つのバンドル、最上位が配列なら各要素が個別のバンドルになる例が示されています。
例えば三つの商品を配列で返した場合、後ろの登録モジュールが商品ごとに動く構成になることがあります。文字列を解析しただけのつもりで、その先のメール送信が三回動くといった取り違えを防ぐため、バンドル数も見てください。
また、オブジェクトの中に配列がある場合と、最上位そのものが配列の場合は同じ形ではありません。商品一覧をproductsという項目に入れるのか、一覧だけを直接返すのかを決めます。構造を変更したら、後続のマッピングも合わせて見直す必要があります。
AIの説明文や囲み記号を混ぜない
AIへJSONを求めても、回答の前に「以下が結果です」と付いたり、コードブロックの囲みが入ったりする場合があります。解析対象の欄にはJSONそのものが入っているかを確かめます。プロンプトで形式を指定した事実だけで、毎回同じ形式になると決めつけないでください。
利用するAIサービスに構造化出力の機能があるなら、その仕様も確認します。ただし、JSONとして整えることと、必要な項目が埋まることは別です。商品情報にない素材名をAIが補えば、形式が正しくても誤ったデータになります。
不明な値の扱いも先に決めます。空文字、null、項目自体を省く方法では、後続で受け取る意味が違います。「分からなければ適当な値を入れる」より、確認が必要な状態を明示して止められる構成にすると、誤情報の登録を防ぎやすくなります。
Create JSONは送り先の仕様に合わせる
解析した情報を別のAPIへ送るときは、送り先が必要とする項目名、型、配列の位置を確認します。元のAI出力と同じ名前をそのまま使えるとは限りません。Create JSONで構造を用意し、元の項目を対応する欄へ割り当てます。
文章を手でつないでJSONを作ると、商品名に引用符や改行が入ったときに崩れる原因になります。単純な商品名だけで試して成功しても、本番では別の文字が来ます。構造を使って作成し、実際の出力を確認する方が、手作業の記号の数え間違いを減らせます。
ただしCreate JSONを通れば、送信先の条件をすべて満たすわけではありません。必須項目、文字数、許容される値などは送信先ごとに違います。JSONの生成、相手への送信、登録内容の確認を別の段階として扱ってください。
正常な一件以外を入れて試す
テストには、引用符を含む商品名、改行のある説明文、空欄、複数件の配列を用意します。日本語の文章も実際の用途に近い長さで試してください。うまく解析できたかだけでなく、次のモジュールへ何件、何の値が渡ったかを比較します。
数値の扱いも見ます。「1,200円」という表示用の文字列と、数値の1200は別です。税込みか税抜きかという意味までJSONが解釈して直すわけではありません。登録先へ渡す値を変換するなら、元の表記と変換後を追えるようにします。
エラーになったデータを通常処理へ押し込まず、原文と失敗した段階を残します。AI出力の不備なのか、解析用の構造なのか、送り先の仕様違いなのかを分ければ、プロンプトだけを何度も書き直す遠回りを減らせます。
変換を増やす前にデータの流れを見る
引き継ぎには、入力が文字列か項目か、期待するJSONの例、最上位が配列かどうか、後続の件数を残します。項目名を変えたときは、参照するモジュールも追って直します。古いマッピングが残ると、実行できても別の値を送る原因になります。
ParseとCreateを往復させれば安心というものではありません。今あるデータの状態と、次の処理が求める状態を合わせるために使います。変換後の形式と、登録される内容の両方を見て初めて、業務で使えるデータの流れになります。
確認日：2026年10月16日。モジュールの役割と出力はMake公式 JSONを確認。商品・項目の例は説明用です。送信先ごとの仕様は各APIの現行資料で確認してください。
コメント