今回使った入力と設定
架空の商品コードと数量を用意し、CSV > Parse CSVのモジュール1つで手動実行しました。実店舗の売上・顧客データは使っていません。
正常な入力
商品コード,数量
001,2
002,3
003,1
003,2
004,4
006,5
,9今回の設定は次のとおりです。
| 設定項目 | 今回の値 |
|---|---|
| モジュール | CSV > Parse CSV |
| ヘッダーの指定 | Yes |
| recommended headers | 商品コード,数量 |
| 区切り文字 | Otherを選び、半角カンマ「,」を指定 |
| CSV入力 | 上の架空CSVを直接入力 |
| 後続モジュール | なし |
| 外部アカウント接続 | なし |
| スケジュール | Inactive。手動実行のみ |
今回の出力フィールド名は「商品コード」「数量」でした。この記録はrecommended headersも指定した状態の結果です。設定を省いた場合の列名や、別の画面・設定でも同じ挙動になるかは確認していません。
単独モジュールのため、出力を次へ渡していない旨の警告が出ました。今回は出力を閲覧する試験なので、その警告に対してRun anyway / Save anywayで続行しています。CSVの列数エラーを無視する設定にしたわけではありません。
正常入力：先頭ゼロ・重複・空キーを確認
実行後の7つの出力を、元の行と照らして確認しました。Make画面では、行ごとの出力がBundleとして表示されています。
| 出力 | 商品コード | 数量 |
|---|---|---|
| 1 | 001 | 2 |
| 2 | 002 | 3 |
| 3 | 003 | 1 |
| 4 | 003 | 2 |
| 5 | 004 | 4 |
| 6 | 006 | 5 |
| 7 | （空欄） | 9 |
「001」「006」の先頭ゼロは表示上残りました。「003」は2行とも残り、商品コードが空欄で数量9の行も出力されました。ヘッダー行はデータ行として数えられていません。
これは、重複や空欄が自動で解決されたという意味ではありません。読み取り後に残っているので、どの行を採用し、どれを人の確認へ回すかは別に決める必要があります。また、その後に表計算などへ書き込んだ場合にも先頭ゼロが保たれるかは、今回確認していません。
同じ入力をもう一度実行
同じ設定と正常入力でもう一度手動実行しました。結果は同じ7行で、商品コード7個・数量7個の計14フィールドが、最初の出力と一致しました。
今回は外部へ書き込む後続処理がありません。この一致は、シートやショップへの二重登録を防げるという検証ではありません。実際の書き込みを追加するなら、同じファイルを再処理したときの扱いを別途確かめる必要があります。
列数が違う入力：エラーで停止
次は、ヘッダーが2列なのに、データ行だけ3列あるCSVを入力しました。
商品コード,数量
001,2,extraこの入力では、次のエラーが表示されました。
Number of columns on line 2 does not match header2行目の列数がヘッダーと一致しない、という内容です。実行はエラーとなり、出力欄には「No bundles were generated by this operation.」と表示されました。今回の異常入力では出力0件です。
この例を確認するときは、ヘッダーの「商品コード」「数量」に対して、2行目が「001」「2」「extra」の3つに分かれていることを確かめます。列数だけを合わせるために必要な値を削るのではなく、想定したデータ形式と入力内容を確認してください。
確認できたのは、この2行の異常CSVだけです。大きなファイルの途中に不正な行がある場合、引用符・文字コード・改行など別の問題がある場合、後続処理を付けた場合の影響までは試していません。
3回の実行で表示された使用量
| ケース | 結果 | 画面表示のoperation | 画面表示のcredit |
|---|---|---|---|
| 正常入力 | 出力7件 | 1 | 1 |
| 同一入力の再実行 | 出力7件、14フィールド一致 | 1 | 1 |
| 列数不一致 | エラー、出力0件 | 1 | 1 |
| 合計 | 手動3回 | 3 | 3 |
追加の金銭支出は0円でしたが、無料枠のクレジットは消費しています。今回のエラー実行にも1creditが表示されました。
この数値は、単独のParse CSVをこの入力で手動実行した記録です。行数や列数を増やした場合、他のモジュールや定期実行を組み合わせた場合の使用量・料金へ、そのまま当てはめることはできません。無料で継続運用できるか、他の方法より安いかは未検証です。
無料の手元照合ツールでできること
2つの一覧を一度だけ比べたい場合は、当サイトの無料CSV照合ツールも使えます。選んだキーと値1列を比べ、重複キーや空キーは確認対象として残す道具です。
このMake実演は、1つのCSVを読み取った記録です。当サイトの2CSV照合と同じ処理をMakeで実現したわけではありません。定期的な取得や別サービスへの受け渡しが必要になったら、照合のルールと失敗時の扱いを決めてから、その先の処理を検討する段階になります。
今回の検証範囲
確認したこと：指定した設定での7行の読み取り、先頭ゼロ・重複・空キーの出力、同じ入力の再実行、列数不一致のエラー、各実行の使用量表示。
未検証：2CSVの照合、重複や空キーの隔離、ファイル自動取得、外部への書き込み、定期実行、時間短縮、無料枠での継続運用、費用優位。購入需要や収益の実証でもありません。
入力には架空データを使っています。実データを外部サービスへ渡す際は、所属先の利用ルールや扱える情報の範囲を先に確認してください。
CSV照合ツールを試す →本番ファイルの前に境界例を加える
小さな正常例が読めたら、引用符付きのカンマ、改行を含む値、空ファイル、余分な列を別々に試します。これらは今回のチーム実測に含まれない追加試験案です。期待する件数と値を先にメモして比較します。
- 入力ファイル名と版を残す
- 見出しをデータ行として数えていないか確認する
- 読込前後の行数と代表値を確認する
- 不正行を本番出力へ流さず確認用に分ける
試したCSVと、照合する期待結果を公開
以下のファイルは、2026年10月20日に運営チームがMakeのParse CSV単独で手動実行した記録に対応する架空データです。実データの登録・二つのCSVの照合・定期実行はしていません。書込先につながない試験用の構成で、出力を確認するために使います。
正常系の架空CSV（7行）を保存 ↓ ／ 列数不一致の架空CSVを保存 ↓ ／ 設定・期待結果・未検証範囲（JSON）を保存 ↓
| 入力と条件 | 当時確認した結果 | この試験で分からないこと |
|---|---|---|
| 商品コード/数量、カンマ区切り、見出しあり。7データ行。 | 7行出力。001の先頭0、003の2行、空コードと数量9が残った。 | 重複や空キーを本番で許してよいか。 |
| 同じ正常入力をもう一度実行 | 7行・14フィールドが初回と一致。 | 外部への二重登録防止。今回は書込なし。 |
| 見出し2列に対し、データを3列にした入力 | 列数不一致エラー。出力0件。 | 別の形式・大量ファイル・後続処理の挙動。 |
観測消費は各1credit、3回合計3creditsです。単独モジュール・この入力での値なので、複数ステップや現在の契約の消費へ一般化しません。元の実行記録と画面はCSV読込試験の記事で確認できます。
コード003は同一商品でも別の受付を意味することがあります。読めた行をそのまま登録する前に、受付ID・顧客IDと重複の扱いを決め、失敗時の復旧と再実行を設計してください。
保存成功・通知失敗のあと、何を再実行するか
以下は二つの架空受付を使った設計上の再現例です。Makeで保存・通知を新たに実行した結果ではありません。上の実測はParse CSV単独の読込3回までで、保存先への書込、通知、二重登録防止は未検証です。
受付IDをDEMO-001、DEMO-002とし、保存と通知を別の状態で記録します。最初の試行ではDEMO-001の保存が成功し、通知は送信前の確定エラーで止まったと仮定します。DEMO-002はまだ処理していません。次の件数はこの仮定に対する期待値で、製品のログや使用量ではありません。
| 確認時点・選ぶ操作 | 保存行数／保存済みID数 | 通知試行数／到達確認数 | 判断 |
|---|---|---|---|
| 初回がDEMO-001の通知前エラーで停止 | 1行／1ID | 1回／0件 | DEMO-001の保存成功、DEMO-002の未処理を区別する |
| 対照例：保存も含め、追記で最初から二件ともやり直す | 3行／2ID | 累計3回／2件を想定 | 保存行数が入力の固有ID数を超える。通知が成功しても重複保存は残る |
| 判断例：DEMO-001は保存を繰り返さず通知だけ再試行し、DEMO-002を通常処理する | 2行／2ID | 累計3回／2件を想定 | 保存結果と通知状態をIDごとに照らす。実際の再開位置は構成とログで確認する |
入力は二件で、表のID数は保存を確認したIDの種類数です。後ろの二行は、同じ初回停止から分かれる別々の案です。続けて行う三つの操作ではありません。通知試行は、送信前に失敗した処理も含めた試行の回数です。通知の到達数は、各再試行が成功して到達を確認できた場合の期待値です。試行した回数と、相手に届いた件数を同じ数字にしないでください。
Make公式では、保存された不完全な実行のRetryやResolveは、エラーを起こしたモジュールから再開する手順として説明されています。シナリオ全体を最初から実行する操作と同じではありません。不完全な実行の保存は既定で無効で、Retryにはシナリオがactiveであることなどの条件があります。不完全な実行の保存条件と再試行・解決の手順を、実際の設定と照らしてください（2026年10月26日確認）。本例のために設定を有効化したり、外部へ通知したりはしていません。
タイムアウトで届いたか不明なら、上の「到達0件」の仮定は使えません。通知状態を不明として残し、受信側の履歴や担当者確認で照合できるまで再送を保留します。受付IDは業務の識別子、Makeの実行IDは一回の実行の識別子として別欄に残します。同時実行や保存先の一意制約まで、この表で検証したことにはなりません。
架空2件の状態・件数・期待値を保存する（CSV） ↓ ／ 実行結果を入れる空欄記録を保存する（CSV） ↓ ／ 分岐条件と未検証範囲を読む（TXT） ↓
添付は説明・記録用で、Makeへ読み込む設定や、そのまま実行する手順ではありません。現在の構成でどこが成功したかを先に確認し、二重処理を避ける復旧手順と照合してください。手元の照合と人の確認で足りる作業なら、追加の接続や契約は不要です。creditsや無料枠での継続費用はこの例では測っていません。
ここまで確認できたら、次へ
- 7行と14フィールドを照合したか
- 重複・空キーを後段でどう扱うか
- 実測と復旧の仮定例を分けて読めるか
確認できない項目は理由と確認先を残します。説明例の結果を、自分の環境で確かめた結果へ置き換えないでください。
出典・確認資料
本文の確認日時点の情報です。今回の改稿で全製品条件を再検証したものではありません。