製造から配送までをAIで自動化してわかったこと

まず、何を自動化したのか

IZNMのIDタグは、1つずつQRコードとID番号が違います。

そのため以前は、タグごとに刻印内容を1件ずつ設定していました。1件あたり約15分です。

発送も、クリックポストのマイページで宛先を1件ずつ入力して購入していました。こちらも1件あたり約5分かかっていました。

クリックポストには、CSVをアップロードして宛先を一括登録できる「まとめ申込」があります。

ただ、私はWooCommerceを使って注文を管理しているものの、クリックポストのまとめ申込用CSVをそのまま出力できる仕組みがありませんでした。

そこで、WooCommerceの注文データから、

• 刻印用データ
• クリックポストのまとめ申込用CSV
• QRコード画像

をまとめて出力する処理を作りました。

いまは管理画面のボタン1つで、発送に必要なファイルを一式出せます。

まだプロモーション前のテスト販売段階で、毎日大量の注文があるわけではありません。それでも先に自動化したのは、注文が増えてからでは遅いと思ったからです。

1件15分の作業が10件、20件と積み上がると、それだけでかなりの時間を取られます。

手が回らなくなってから自動化するのではなく、手が回っているうちに仕組みにする。

今回はその考えで進めました。

なぜ手が回らなくなる前に着手すべきなのか。判断の考え方はこちらの記事に書きました。

問題1｜住所の後半が、何も言わずに消えた

最初に起きたのは、クリックポストの住所でした。

まとめ申込用CSVのお届け先住所は、1行あたり20文字までという制限があります。

私は最初、その制限を意識せず、住所をそのまま1つの欄に出力していました。

CSVをアップロードすると、エラーは出ません。

宛先も登録されます。支払いも完了します。

ところが、印字されたラベルを見ると、住所の後半が切れていました。

何が問題だったのか

一番怖かったのは、処理が止まらなかったことです。

エラーが出れば、その場で気づけます。

今回は違いました。

システム上は正常に処理が終わっているのに、出来上がった配送ラベルだけが間違っていました。

気づけたのは、発送前にラベルを目で確認する工程を残していたからです。

AIからも、この制限は出てきませんでした

少なくとも今回のやり取りでは、AIから20文字制限の指摘は出てきませんでした。

私が気づいたのは、日本郵便のCSVテンプレートを実際に開いて、項目の定義を確認したときです。

AIの指摘には、自分だけでは気づけなかった重要なものもあります。一方で、今回のように必要な制約が抜けることもあります。

だから、AIに作ってもらった処理が動いたことと、実際の業務で正しいことは別に確認する必要があります。

どう直したか

住所を20文字ごとに機械的に切るのはやめました。

丁目や番地の途中で切れてしまうからです。

代わりに、住所の構造に合わせて、

• 都道府県
• 市区町村
• 番地
• 建物名

のように分けて出力するようにしました。

それでも20文字を超える場合は、自動処理を止めて、人が確認するようにしています。

ここでの答えは、「もっと賢く自動化する」ではありませんでした。

自動で処理してはいけないケースを決めることでした。

同じ型の失敗が、画面の中でも起きていました。画像の投稿が何も言わずに失敗していた話です。AIで本番運用してわかった、できなかったこと8つ

問題2｜Excel対策を入れると、今度は宛名が壊れる

次は、CSVをExcelで開くときの問題です。

Excelでは、セルの先頭が = + - などで始まると、文字ではなく数式として扱われることがあります。

CSVを扱うときによくある問題です。

一般的な対策として、先頭にアポストロフィ ' を付けて文字列として扱わせる方法があります。AIからも、その方法が提案されました。

ただ、このCSVはExcelで確認したあと、そのまま日本郵便へアップロードします。

つまり、アポストロフィがデータとして残れば、たとえば

'田中太郎

のような宛名のまま配送ラベルに出る可能性があります。

Excel上では安全になっても、配送データとしては正しくない。

ここが問題でした。

どう直したか

アポストロフィを自動で付ける方法は使いませんでした。

その代わり、先頭に数式として解釈される可能性のある文字が見つかった場合は、処理を止めて人が確認するようにしました。

郵便局へ渡すデータそのものは変えない。

危険なケースだけ、人に戻す。

この方がシンプルで、事故も起きにくいと判断しました。

ここでも結論は同じです。

全部を自動で解決しようとしない。

問題3｜止める場所を間違えると、システム上の状態だけが進む

「危ない場合は処理を止める」という方針にしたあと、もう1つ問題が出ました。

どのタイミングで止めるかです。

たとえば刻印用データを出力するとき、処理はざっくり次の順番で進みます。

1. 対象のタグを集める
2. タグの状態を「刻印中」に変更する
3. 刻印用ファイルを出力する

ここで、住所やデータのチェックを2のあとに入れるとどうなるか。

チェックでエラーになってファイルが出なくても、タグの状態だけは「刻印中」に変わっています。

実際にはまだ何も刻印していないのに、システム上は刻印中です。

これでは、現物と管理画面の状態がずれます。

どう直したか

チェックを、状態を変更する前に移しました。

問題があれば何も更新せず、その場で止まる。

問題がなければ、そのあとで状態を変えてファイルを出す。

これだけです。

発送完了の処理でも同じで、タグの状態、注文の状態、計測イベントなど、複数の更新が連続します。

途中で止まったときに、どこまで更新されているのか分からなくなる設計にはしない。

止めるなら、データの辻褄が合う場所で止める。

これは機能の話というより、業務管理の話でした。

少なくとも今回、この判断はAIとのやり取りだけでは決められませんでした。

実際の業務がどう動くのか、現物と管理画面の状態がどう対応するのかを見ないと判断できなかったからです。

工程管理で、1つ設計を作り直しました

製造から発送までの工程は、6段階で管理しています。

刻印待ち → 刻印中 → 納品書印刷 → ラベル印刷 → 梱包 → 発送済み

この順番で管理するようにしてから、どのタグがいまどの工程にあるのかが分かりやすくなり、抜け漏れもかなり減りました。

私自身の体感としても、正しい順番で製造から発送まで進められるようになったことは、この仕組みの大きなメリットです。

一方で、運用を始めたあとに1つだけ設計を作り直した箇所がありました。

最初は、「前の工程を終えないと次へ進めない」という一方向の制御にしていました。

その後、途中に新しい工程を追加したところ、すでに先の工程まで進んでいたタグが新しく追加した工程を通っていないため、印刷したいのに印刷ボタンが出ない状態になりました。

そこで、一方向にしか進めない制御だけを見直しました。

現在も6工程の順番はそのまま表示され、基本的にはその手順に沿って進めます。ただし、途中の5工程については、必要な場合に状態を調整できるようにしています。

一方で、最後の「発送済み」だけは自由に切り替えられません。

発送済みにすると、タグの有効化日時の記録、WooCommerceの注文完了、通知メールなど、実際の発送に連動する処理が走るためです。ここだけは、必ず正式な発送処理を通す設計のままにしています。

つまり現在は、

基本の順番は守る。途中で詰まったときだけ調整できる。発送完了だけは必ず正式な手順を通す。

という設計です。

順番管理そのものを緩めたわけではありません。むしろ、工程を順番で管理することで抜け漏れを防ぎながら、後から業務フローが変わったときにも詰まらないようにした、という方が正確です。

自動化して分かった4つのこと

今回の経験を、4つにまとめます。

1. 自動化は「ファイルが出たら終わり」ではない

クリックポスト用CSVを作れたとしても、それで終わりではありません。

そのファイルを誰が開くのか。

Excelを通すのか。

最終的にどこへアップロードするのか。

印字されたものはどう確認するのか。

実際に使い終わるところまでが、自動化の範囲です。

2. エラーで止まるものより、正常に間違うものの方が怖い

住所の問題がまさにそうでした。

CSVは正常に読み込まれた。

支払いもできた。

でも、配送ラベルは間違っていた。

自動化で一番注意した方がいいのは、派手に壊れる処理より、正常に見えたまま間違った結果を出す処理だと思います。

3. 自動化すると、それまで人が無意識にやっていた確認が消える

手作業のときは、住所を入力するたびに自分の目で見ていました。

自動化すると、その確認自体がなくなります。

だから、自動化する前に、

「いま人は、どこで何を確認しているか」

を洗い出しておく必要があります。

私は発送前のラベル確認を残しました。

その工程があったから、住所が切れていることに気づけました。

4. 基本の手順は固定し、例外だけ人が調整できるようにする

製造から発送までの6工程は、順番を決めて管理したことで抜け漏れが減りました。

一方で、あとから工程を追加したときのように、例外的に途中で詰まることはあります。

そこで、通常は決めた手順どおりに進めつつ、途中の工程だけは必要に応じて調整できるようにしました。最後の「発送済み」は、注文完了や通知などが連動するため、正式な発送処理を通す設計を維持しています。

住所が20文字を超えた場合や、数式として解釈される可能性がある文字が含まれる場合も同じです。

通常ケースは仕組みで迷わず進める。例外だけ人が確認する。

このバランスが、実務では一番使いやすいと感じています。

まとめ

製造から配送まで自動化して、一番変わったのは作業時間です。

刻印用データの作成やクリックポストへの登録を1件ずつ行う必要がなくなり、体感では5分の1程度まで短縮できました。

ただ、一番大きな学びは効率化そのものではありませんでした。

自動化で大事なのは、どこまで機械に任せるかより、どこで止めて人が確認するかを先に決めること。

住所が20文字を超えたら止める。

危険な文字が入っていたら止める。

状態を更新する前にチェックする。

最後に配送ラベルは人が見る。

こうした小さなルールが、実際の事故を防ぎます。

もし、WooCommerceなど自社サイトの注文情報から、クリックポストのまとめ申込用CSVを手作業で作っているなら、自動化する価値はかなりあります。

ただし、最初からすべてを自動で処理しようとしない方がいいと思います。

通常のケースは、決めた手順どおりに自動で進める。例外だけ人が確認する。

今回やってみて、この形が一番シンプルで実用的でした。