Makeで匿名データ1件を流したときは、請求書の経路だけが動きました。ただ、その確認だけでは、項目が欠けた入力や、同じ受付を二度渡した場合の扱いまでは分かりません。
そこで、このサイトでは検収用の入力を5種類作り、先に決めた結果と比べる小さな判定例を用意しました。検収とは、作ったものが合意した条件を満たすか確かめることです。自分で作る場合にも使えます。
今回動かしたのは、外部へ接続しないNode.jsのローカル例です。MakeやGASで5例を実行した結果ではありません。
見るのは、正常な入力が通ることだけでなく、通してはいけない入力が止まること。 次のJSONと表を、作りたい処理の完成条件を話す材料にしてください。
何を受け付け、どこへ分けるかを先に決めた
今回の例は、架空の問い合わせを請求書の経路と、それ以外の経路へ分けます。メール送信や台帳への保存は行いません。
判定条件は次のとおりです。
request_id・category・priorityは、空白だけではない文字列。contains_personal_dataは、文字列ではなく真偽値のfalse。- 同じ判定中に受理したIDをもう一度渡したら、新しい経路へ進めない。
- 条件を満たした入力のうち、
categoryがinvoiceと完全一致すれば請求書経路。それ以外はFallbackへ分ける。
Fallbackは、ほかの条件に当てはまらなかった入力の行き先です。この例では失敗ではなく、受理したうえで別の経路へ渡す扱いにしています。
この条件は今回作った例の仕様です。MakeやGASが標準で同じ判定をする、という意味ではありません。
コピーして比べる5つの入力
次の配列を上から順に扱います。実在する顧客名、メール、口座情報は使っていません。
[
{
"request_id": "sample-001",
"category": "invoice",
"priority": "normal",
"contains_personal_data": false
},
{
"request_id": "sample-002",
"category": "general",
"priority": "normal",
"contains_personal_data": false
},
{
"request_id": "sample-003",
"priority": "normal",
"contains_personal_data": false
},
{
"request_id": "sample-004",
"category": "invoice",
"priority": "normal",
"contains_personal_data": "false"
},
{
"request_id": "sample-001",
"category": "invoice",
"priority": "normal",
"contains_personal_data": false
}
]3件目はcategoryを省き、4件目はfalseを引用符で囲みました。5件目は1件目と同じIDです。間違いを直してから試すのではなく、その違いを残して判定を見ます。
| 入力 | 期待する結果 | 見るところ |
|---|---|---|
| 1. 正常なinvoice | 受理し、invoiceへ | 意図した経路だけへ進むか |
| 2. general | 受理し、fallbackへ | 失敗と別経路を区別できるか |
| 3. categoryなし | 拒否し、経路へ進めない | 足りない項目が理由に出るか |
| 4. 文字列のfalse | 拒否し、経路へ進めない | 値の見た目だけで通さないか |
| 5. 同じID | 重複として、経路へ進めない | 同じ判定中の受理記録を見ているか |
ローカル例へ渡すと、この順で期待した結果になりました。拒否した入力のIDは受理記録へ入れず、修正した入力を同じIDで試せることも確かめています。
ただし、検査の順番は入力の不足・型、次にIDの重複です。同じIDでも必須項目が欠けていれば、重複ではなく入力不足として拒否します。
ファイルで試す場合
架空JSON・判定例・テスト・使い方のZIPをダウンロードする
JSONを読むだけなら追加の準備は不要です。判定例も動かす場合はNode.jsが必要で、v24.11.1で確認しています。ZIPを展開したフォルダで実行します。
node reference.mjs
node --test tests.mjs一つ目は5例の判定を表示し、二つ目は判定条件のテストを動かします。外部への接続、メール送信、ファイルへの書込みは行いません。Node.jsのテスト実行方法は公式資料でも確認できます。
falseと書いても、個人情報を調べたことにはならない
falseと"false"は、JSONでは別の型です。前者は真偽値、後者は文字列。今回の例は真偽値のfalseだけを通します。
それでも、入力の中身から個人情報を探す機能はありません。contains_personal_data: falseは入力者の宣言にすぎず、匿名化済みの証拠にはなりません。
この5例を本物の顧客情報へ置き換える必要はありません。分岐や不足項目を見る段階では、独立した架空データを使ってください。
同じIDを止められた範囲にも限りがある
今回の重複判定は、同じ判定中に共有しているIDの記録だけを見ます。ローカルのプログラムを終了し、もう一度起動すると、その記録は空に戻ります。
別の記録を使って同じIDを渡した場合も、最初の入力として受理されました。再起動後まで重複を防ぐ仕組みではありません。
さらに、この例は受理後の業務処理を実装していません。メール送信の途中で失敗した場合や、複数の処理が同時に同じIDを受けた場合の安全性も評価していません。
本番の完成条件には、記録をどこへ残すか、何をもって処理完了とするかも必要です。「IDを見た」だけで、二重送信まで防げたとは判断しないようにします。
実際の検収では、結果と次へ進まなかったことを見る
自作した処理でも外注した処理でも、試す前に期待結果を書いておきます。実行してから、出てきた結果に合わせて合格条件を変えないためです。
入力の番号：
期待する受理・拒否・重複：
期待する経路：
実際の結果と理由：
保存・送信など後ろの処理が動いたか：
残した記録：
違った場合に止める場所：拒否の表示が出ても、その後でメールが送られていたら、期待した停止とは違います。画面の文言だけで終えず、どの処理まで進んだかを照合してください。
この5例で確認できるのは、決めた入力条件と振り分けの一部です。接続切れ、処理量、権限切れ、復元まで検査し終えたことにはなりません。
次は、作り方に合わせて試す場所を選ぶ
使う仕組みが決まっていないなら、GASとMakeを分ける判断軸で接続先と保守する範囲を考えられます。Makeで入力1件の受信から試す場合は、匿名Webhookと分岐を確認した手順へ進めます。
外注する場合は、この入力例と期待結果をGAS外注の見積り相談へ書く内容の検収条件へ添えてください。今回の5例をMakeへそのまま送れば、拒否や重複の制御まで付くわけではありません。必要な判定は、実際の仕組みに別途作る必要があります。
本番ではなく試験用コピーで、正常例を一つ複製し、必須項目だけを抜いてみてください。何も保存・送信せず、足りない理由を残して止まってほしい。その期待を、動かす前に一行で書くところから始められます。
今回確認した範囲
一次材料は、このサイトで新作した架空JSON5件とローカル判定例です。外部通信やファイルへの書込みは行わず、入力条件、経路、同じ記録内のID重複を確認しました。
Make・GASの実機、個人情報の検出、永続的な重複防止、本番の送信・保存は検証していません。利用する業務の入力形式と、失敗時の影響に合わせて、追加の完成条件を決めてください。
この記事の確認情報
最終確認日：2026年10月15日
確認に使ったもの
- 新作した架空JSON5件と入力・経路・同一記録内IDの判定例
- Node.js v24.11.1のローカル12試験と、配布ZIP展開後の再実行
参照した公式情報
リンクは新しいタブで開きます。