ロボット工場にボルトが3回届いた

一言でいうと

FDEの最初の成果物は、速いスクリプトではなく、顧客の言葉を検査できる業務ルールに移した契約です。

なぜ必要なのか

架空のロボット工場から連絡が来ました。「注文ファイルをもう一度アップロードしたら、倉庫に同じ予約ができてしまいました。失敗したと思って、もう一度押しただけなのに」。顧客は重複をなくしてほしいと言います。しかし、何が重複なのでしょうか。ファイルの同じ行でしょうか、同じイベントでしょうか、同じ注文でしょうか。注文番号は同じなのに数量が変わっていた場合は、修正でしょうか、誤った入力でしょうか。この問いに答えないままコードを書くと、間違った自動化を速く作ることになります。

このコースであなたは、顧客と一緒に小さな連携を納品するエンジニアです。Pythonの関数・辞書とCSV、HTTPリクエストを読めることを前提とします。まだ不慣れなら、先にFDEのデータ・APIのラボを進めてください。実際の物流事故を再現したものではなく、合成データと架空の倉庫で作った教育用のシナリオです。実際の出荷・決済・在庫の移動はありません。

どう動くのか

顧客のブリーフを、まず3つの質問に分けます。自動化が変えてよいものは何か。どんな情報を送ってよいか。判断があいまいなとき、誰が決めるのか。今回の範囲は、倉庫の予約までです。配送を指示したり、衝突した数量のどちらかをエンジニアが選んだりするのは、範囲外です。メールアドレスは元データにありますが、予約には必要ないので送りません。

行のevent_idは配信イベントの番号で、order_idは業務上の注文の番号です。同じ注文が別のイベントとして再び届いても、新しい購入にはなりません。逆に、SKUが同じだからといって別の注文をまとめると、正常な注文を失います。したがって、今回顧客と合意した重複の基準は、order_idとその注文の内容です。すべての会社に通用する万能のキーという意味ではありません。分割出荷や注文の修正が必要な会社なら、バージョン・出荷番号に関する契約が先に必要です。

配布されたCSVには、データ行が7つあります。ヘッダーを1行目と数えると、次のように分類します。

データ行	観察	処理
2・3・4	互いに異なる正常な注文が3つ	それぞれ送信の候補
5	4行目と同じ注文・SKU・数量で、別のイベント	再配信として記録
6	数量がtwo	不良として保留
7・8	同じ注文なのに数量が1と3	2行とも衝突として保留

結果は、候補3つ、再配信1行、保留3行です。7行を7回送信することはしません。「重複をなくしたから3つを捨てた」という説明も誤りです。保留は削除ではなく、人の判断を待つ状態であり、行番号と理由が残っている必要があります。

ここで1行ずつ読んですぐに送ると、7行目を送信したあとで8行目の衝突を見つけることになります。すでに予約したものは、単にCSVから取り除くだけでは取り消せません。そのため、ファイル全体を先に検証し、同じ注文のすべての行を集めて判断してから送信します。有効な注文番号の下に不良の行が1つでもあれば、その注文全体を保留します。誤った注文番号は、報告書にそのまま複製せず、nullと行番号で探せるようにします。

数量は、CSVの文字として1から5までの1文字だけを受け付けます。02や2.0を数値の2に直すと便利に見えますが、それは顧客が許可していない入力の補正です。最大100行・256KiBも、この練習の入力の契約です。さらに大きな業務を扱うには、ストリーミング検証、バッチの境界、重複の記録の保存期間などを、設計し直す必要があります。

送ってよい行と、送るべき注文

練習として、もう1行考えてみてください。ORD-EXTRAがROBOT-BOLTを2個注文し、別のORD-SECONDも同じようにボルトを2個注文したとします。SKUと数量だけを比べると同じ行に見えますが、業務上の注文は2つなので、どちらも候補です。一方、ORD-EXTRAのイベントだけが新しい番号でまた入ってきたときは、候補を増やしません。この2つの例を並べて書くと、「重複の除去」という1つの言葉に隠れた、異なる意味を、同僚と確認できます。

もう1つの失敗は、誤った行を黙って飛ばすことです。顧客が期待した注文が見えなければ、実行が終わったあとでファイルをもう一度アップロードするかもしれません。そのとき、正常に処理した注文まで繰り返されます。保留の一覧に、行番号と短い理由を残すのは、エラー報告書の飾りではなく、次の業務上の行動を決める情報です。保留の行の原文を、ログにそのまま入れる必要はありません。元データは保存しておき、報告書は、どこを確認すればよいかだけを指せば十分です。

実装の前に、3つの文を書いてみてください。「同じ注文の同じ内容は、1回だけ予約する」。「衝突や不良があれば、その注文全体を送信しない」。「保留の理由を残すが、不要な顧客情報は移さない」。それぞれが、候補の一覧・保留の一覧・実際のリクエストを検査するテストに変わります。顧客がこれらの文に同意しないなら、コードの細部の実装より、契約を先に直す必要があります。

現場での姿

2026-09-11に確認したOpenAI FDSWEの求人は、顧客の要求の把握、反復的な実装、PoCと本番デプロイの作業範囲の作成を扱っています。Palantir FDSEの求人は、あいまいな問題から、設計・プロトタイプ・データ連携まで続ける仕事を説明しています。このコースは、その業務の一部を小さなラボに移したものです。採用試験や合格の保証ではなく、2つの求人は米国の特定の職務の事例であり、韓国の採用市場全体を代表するものではありません。

次に確認すること

次のクイズでは、送信の前に合意する境界と、保留の基準を区別します。実装に先立って、「どんな結果なら、顧客が正しいと確認できるのか」を、一文で説明してみてください。このラボでは、保留されていない注文だけがちょうど1つの予約として確認され、残りは理由とともに残ることが基準です。