「自動化したいのはやまやまだけど、うちのシステムが特殊だから難しいと思うんですよね」
こういう話、よく相談を受けます。聞いてみると確かに受注の入口はバラバラです。ECで入ってくる注文、メールに添付されたPDF、取引先ごとに別の専用システム、電話で口頭確認してから手入力、という会社も珍しくない。
「特殊だから無理」は理解できる言い方だと思っていました。でも設計を分けて考えると、だいたい9割方は入口だけが特殊で、それより後ろは同じ処理が続いています。
「変わる部分」と「変わらない部分」
受注処理の流れを整理すると、こうなることが多いです。
入口（EC・メール・専用システム・電話など、会社ごとにバラバラ）
↓
整形（受注内容を決まった形に揃える）
↓
帳票生成（発注書・確認書・納品書など）
↓
出力（社内システムへの登録・FAX・PDFメール など）
この流れのうち、実際に会社ごとに違うのは最初の入口だけです。整形から先は、どこの会社でも大きく変わりません。「明細を読んで、決まった形に直して、帳票を作って、どこかに出す」という処理は共通です。
それなのに「入口が違う」というだけで全体を特注扱いにして、毎回ゼロから作るのが重くなっていた、という話が多い。
入口だけを差し替える考え方
私がこういった相談を受けるときは、だいたい3つの方向で整理します。
1つ目は、入口ごとに「変換ノード」を置いて、後ろの処理を共通化する方法です。ECからの注文なら、そのAPIから受け取って共通の形に変換する。メール添付のPDFなら、AIに読み取らせて同じ共通の形に変換する。入口の数だけ変換の仕組みを作るけれど、整形から先は1本で処理できます。
2つ目は、入口を1つに絞ってしまう方法です。「全部のチャネルをこのフォームから入力してもらう」と決めてしまえば、変換の仕組みは要りません。取引先への交渉や運用変更を伴うので状況次第ですが、選べるなら一番シンプルです。
3つ目は、その中間です。入口の種類が多すぎて全部統一できないとき、「これとこれだけ自動化して、残りは当面手動」という線引きで進めます。全部やろうとして止まるより、部分的にでも動く方が現場は助かることが多いです。
AIにどう頼んだか
こういった設計を決めるとき、私はAIと壁打ちしながら整理することが多いです。たとえばこんな感じで話しかけます。
うちの受注処理の入口が3種類あって、それぞれ形式が全然違う。ECのAPI、メールに添付されるPDF、専用システムからのCSVエクスポート。
整形から先は同じ処理でいいんだけど、入口3つ分を毎回個別に実装すると保守が大変になりそう。
入口ごとに変換処理を独立させて、後ろを共通化するとしたら、変換層と共通処理の境目をどう引けばいいか。あと、後から4つ目の入口が増えたときに影響が少なくなる構造を教えてほしい。
返ってくる内容は設計の案であって、コードはまだ出てきません。「境目をどこに引くか」「増えたときにどこを触るか」を言葉でやり取りして、方針が固まってから実装に入ります。
具体的な入口の仕様（どういうフォーマットで来るか、何が必須項目か）を渡すと、変換の設計もそこに合わせてもらえます。
必要なものの目安
同じ考え方を実際に動かすには、だいたいこういった要素が要ります。
- 入口ごとに「受け取って変換する」処理（入口の数だけ個別対応が要る部分）
- 共通の中間データ形式（整形・帳票生成が使い回せるフォーマット）
- 後ろの処理を動かす実行環境（追加費用が少ない自動化ツールで足りることが多い）
入口が増えるたびに増えるのは最初の変換部分だけで、後ろは触りません。最初にこの構造を決めておくかどうかで、2つ目・3つ目の入口を追加するときの手間がかなり変わります。
「特殊」をどこまで引き受けるか
PoC段階でやってみてわかったのは、特殊な入口ほど「変換の品質」がそのまま後ろの処理の品質に直結する、ということです。
たとえばPDFをAIに読み取らせるとき、PDF自体がスキャンの歪みや手書き混じりだと読み取り精度が落ちます。落ちた精度をどこで補うか、補えない場合はどこでスキップして後で確認するか。入口の特殊さによって、変換層が吸収しなければならないエラーの量が変わります。
「うちは特殊だから」と言われる案件の場合、入口そのものへの対応コストより「入口の揺らぎをどう吸収するか」の設計コストが大きいことが多い。そこを事前にヒアリングで確認しないと、見積もりが後でずれます。
「特殊な入口への対応はここまで、それ以上の揺らぎは手動で補完」という線引きを最初に決めておくことが、結局一番手戻りが少ないです。
どんな業務なら同じ手が使えるか
受注処理以外でも、この考え方は使えます。
情報の入ってくるルートが複数あって、入ってきた後の処理は同じ、というパターンは業務にけっこうあります。問い合わせが電話・メール・フォームから来る場合、請求書が紙・PDF・EDIで来る場合、在庫情報が複数の拠点・システムからバラバラに入ってくる場合。
入口が1つになれば一番楽ですが、そうできない理由は大抵「取引先の都合」か「既存システムの制約」です。それを変えようとすると動きません。入口は今のまま残しながら、変換の仕組みを挟んで後ろを共通にする、という発想が現場では使い勝手がいいと思っています。