OCRとWMSが別ベンダーのとき、データを渡す側と受け取る側の間に、どちらの見積にも入っていない作業が残りがちです。導入後の障害で「うちの責任ではない」が向かい合う前に、契約段階で責任分界点をどう引くか。分業でも一気通貫でも成立させるための決め方を考えます。
連携部分が谷間に落ちるのは、OCRベンダーとWMSベンダーがそれぞれ「自分の製品の外側」を見積に含めない構造が原因だと考えられます。OCRベンダーは紙や画像から文字を読み取り、結果をデータとして出力するところまでを自社の責任範囲と捉えがちです。一方でWMS（倉庫管理システム＝入出庫・在庫・ロケーションを管理する基幹寄りのシステム）ベンダーは、決められた形式でデータが届く前提で受け側を見積もります。その中間にある「読み取り結果をWMSが受け取れる形に変換し、正しい伝票・品番に紐づけて登録する」工程が、双方の視界の端で宙に浮きます。
OCR（Optical Character Recognition＝光学文字認識。画像中の文字をテキストデータに変換する技術）の出力は、そのままWMSに入るとは限りません。品番の桁揃え、全角半角、伝票番号とロット番号の切り分け、既存マスタとの照合（読み取った値を正解データベースと突き合わせて確定させる処理）など、業務ルールを知らないと設計できない変換が必要になります。この変換仕様を誰が書き、誰がテストし、本番で値がずれたとき誰が直すのか。ここが曖昧なまま契約が進むと、後から必ず問題になりうると考えます。
平常時は谷間があっても動いてしまうため、問題は導入後の最初の障害で表面化します。ある日から特定フォーマットの伝票だけWMSに登録されなくなったとき、OCRベンダーは「読み取りは正しく出ている」と言い、WMSベンダーは「渡ってきたデータが仕様と違う」と言う。どちらも自社の範囲では嘘をついていないのに、現場の入庫は止まります。連携が切れている現場の実態は、WMSにつながらないデータとしても繰り返し起きているパターンだと考えます。復旧より先に責任論が始まる状況は、契約段階の設計で相当程度避けられると考えます。
決めるべき責任分界点は、突き詰めると三つに整理できると考えます。第一に「データを渡すまで／受け取ってから」の物理的な境界線、第二に「フォーマット定義を管理する人」、第三に「連携エラーの一次切り分けを担う人」です。この三つを紙に書き、両ベンダーと発注側の三者が同じ文言に合意していれば、谷間の大半は埋まると考えます。逆にこのどれか一つでも「なんとなく」で進むと、障害時にそこが争点になりうると考えます。
| 責任分界の論点 | 決めること | 決めていないと起きること |
|---|---|---|
| 分界点の位置 | どの受け渡し方式の、どの地点で責任が移るか | 「渡した」「受け取っていない」の水掛け論になる |
| フォーマット定義の管理者 | 項目・桁数・文字コードの「正」を誰が持つか | 片方の無断変更で整合が崩れ、原因究明が難航する |
| 一次切り分けの担当 | データ未登録時に最初に状況を判定する役割 | 両ベンダーへの同時連絡と押し付け合いで初動が遅れる |
分界点は「渡し方」とセットで決める必要があります。CSVファイルを共有フォルダに置くのか、API（システム間でデータをやり取りする接続口）で直接渡すのか、中間データベースを一つ挟むのか。方式によって、どちらが監視し、どちらが再送する責任を持つかが変わります。たとえばファイル連携なら「OCR側は指定フォルダに正しい形式のファイルを置くまで、WMS側はそのファイルを取り込んでから」と地点を一点に固定できます。この一点を図に落とすことが、責任分界の実体になると考えます。受け側にAPIが無い場合にどんな受け渡し方式が使えるかはAPIがない基幹との連携で整理しています。
フォーマット定義（項目名・桁数・文字コード・必須任意の取り決め）の管理者を一人に定めることが要になります。定義書が両社に散らばっていると、片方が黙って項目を足したり桁を変えたりしたときに整合が崩れます。管理者は必ずしもベンダーである必要はなく、発注側の情報システム担当が「正」を持ち、変更は必ずその管理下で行う、という置き方も有効だと考えます。WMSとOCRの連携で具体的に何を決めるべきかは、この定義書の粒度に強く依存します。
障害時に「まず状況を切り分ける人」を先に決めておくことが、実務では最も効きます。データが登録されないとき、それが読み取りの問題か、変換の問題か、WMS取り込みの問題かを最初に判定する役割です。この一次切り分けを発注側の担当が担うのか、いずれかのベンダーが担うのか、あるいは連携部分だけを別途契約した第三者が担うのか。誰も担わない設計だと、両ベンダーへの同時連絡と押し付け合いで時間が溶けます。一次切り分け担当を契約書に一行入れるだけで、初動が変わると考えます。
谷間を可視化する最も確実な方法は、見積依頼（RFP）の段階で「連携仕様書の作成費」と「結合テスト費」を独立した項目として提示するよう、両ベンダーに明示的に求めることだと考えます。これらを一式費用に丸めさせず、行として立てさせると、どちらの見積にも入っていない作業が金額ゼロの空白として一目で分かります。空白が見えれば、そこを埋める交渉ができます。見積の抜けを見つける観点は、複数ベンダー見積の比較の考え方がそのまま応用できると考えます。
具体的には、連携仕様書の作成（どちらが書き、どちらがレビューするか）、変換ロジックの実装、二社をまたいだ結合テスト、本番移行後の連携部分の保守窓口、の四つを別項目にすると谷間が浮きます。特に結合テストは「自社の範囲は動作確認済み」で終わらせず、実際のOCR出力を実際のWMSに流す試験を、誰の費用で何日確保するかまで書かせることが重要だと考えます。ここが曖昧だと本番で初めて突き合わせることになりかねません。
連携部分には、見積表の主要行に現れにくい費用が付随します。フォーマット変更時の再テスト、新しい伝票様式が増えたときのマッピング追加、繁忙期の登録エラー対応の稼働などです。こうした継続費用は導入時の一式見積に埋もれやすく、運用が始まってから請求の根拠を巡って揉めやすい領域だと考えます。物流OCRの隠れコストとして整理される費目を、契約前に「連携維持に関わる継続費用」として洗い出しておくと、後の負担配分が明確になると考えます。
両ベンダーを同じ打合せに同席させることには、責任分界を「言った言わない」から「共通の議事録」に変える価値があると考えます。個別に話すと、発注側が伝言役になり、OCR側の前提とWMS側の前提が微妙にずれたまま進みます。同席させれば、フォーマットの一項目について両者がその場で認識を合わせ、合意点と保留点が一枚の議事録に残ります。この議事録が、後の障害時に立ち返る基準になると考えます。
同席打合せは、抽象論からではなく現物のサンプルデータから始めると噛み合います。実際の伝票を一枚OCRに通した出力を画面に映し、その値をWMSがどの項目に、どう変換して取り込むかを、項目単位で確認していきます。桁が合わない、コード体系が違う、必須項目が空になる、といった具体的な齟齬がその場で出るため、机上の仕様書レビューより格段に実効的だと考えます。
発注側の情報システム担当が二社の技術用語を翻訳し続ける体制は、担当者に属人的な負荷が集中し、その人が休んだ瞬間に連携が止まりうると考えます。同席打合せの狙いの一つは、両ベンダーが直接会話するルートを作り、発注側は業務要件の確定と意思決定に集中できるようにすることです。連携の設計と契約の組み立てそのものを外部から支援する導入コンサルティングを挟む選び方も、翻訳負荷を下げる一つの手段になりうると考えます。
分業（OCRとWMSを別ベンダーに任せる）と一気通貫（読み取りから登録まで一社が持つ）のどちらが向くかは、自社の体制とデータの複雑さで変わり、唯一の正解はないと考えます。一気通貫は連携部分の責任が一社に集約されるため谷間が生じにくい反面、既存WMSがある場合はその接続の柔軟性が論点になります。分業は各領域の専門性を選べる反面、連携の責任分界を発注側が設計する必要があります。読み取りから連携までを一社で持つ形として物流OCRのような一気通貫の選択肢を検討する価値はありますが、既存資産との兼ね合いで公平に判断すべきだと考えます。
既に基幹に組み込まれたWMSが安定稼働していて差し替えが現実的でない場合や、社内に連携仕様を管理できる情報システム人材がいる場合は、分業が向きやすいと考えます。この場合、WMSは触らずOCRだけを足す構成になるため、責任分界点を「WMSの受け口の手前」に明確に引きやすくなります。ただし前述の一次切り分け担当を社内で確保できることが条件になると考えます。
WMSも含めて新規に構築する、あるいは登録工程まで含めて障害対応の窓口を一本化したい場合は、一気通貫が向きやすいと考えます。連携部分が社内のベンダー間ではなく一社内の工程になるため、谷間の交渉コストが下がる可能性があります。一方で、既存の基幹システムとの接続要件が強い現場では一社完結が難しいこともあり、その場合は分業前提で責任分界を丁寧に設計する方が現実的だと考えます。
責任分界を決めたつもりでも、実運用で崩れる典型的な落とし穴があります。契約書に一行入れて安心せず、以下の点が具体的に詰まっているかを確認することをおすすめします。いずれも「決めた気になっていたが本番で揉めた」パターンとして起こりうると考えます。
最初の一歩は、契約や見積の議論に入る前に、現物の帳票と現在のWMS登録項目を持ち寄り、今どこで手が止まっているかを客観的に把握することだと考えます。責任分界は抽象的な取り決めではなく、具体的なデータの流れの上に引く線です。実際の伝票が何種類あり、そのうちどれが手入力で回っていて、WMSのどの項目に何が入るのか。この実態が見えていないと、分界点をどこに引いても机上論になりうると考えます。
実態把握のあとは、対象帳票を絞った小さな範囲で受け渡しの一連を試し、そこで見えた変換の難所を連携仕様書の骨子にします。その骨子を持って両ベンダーに見積を依頼し、前述の四項目を独立行で提示させ、同席打合せで項目単位に詰める。この順番なら、責任分界が実データの手触りに裏打ちされた状態で契約に落ちると考えます。逆に、仕様書もサンプルもないまま金額だけ比較すると、安い見積が谷間を含んだ見積である可能性を見抜けなくなると考えます。
本記事は、元キーエンス画像処理事業部の開発エンジニアが監修し、読み取りから登録までの一気通貫と、産業用カメラ・現場ライティング・エッジ（現場側の機器上で処理を完結させる構成）実装の知見をふまえて整理しました。ただし最適な責任分界は現場ごとに異なり、ここに書いた内容は一般論です。実際の設計は、現物と現行システムでの検証を前提に判断すべきだと考えます。
どちらにも入っていない場合が起こりうると考えます。OCR側は出力まで、WMS側は受け取ってからを見積もりがちで、変換と結合テストが谷間になります。見積依頼の段階で連携仕様書の作成費と結合テスト費を独立した行として提示させると、空白が可視化され、どちらが負担するかを交渉できる状態になると考えます。
契約前に「一次切り分け担当」を一者に定めておくことをおすすめします。データ未登録が読み取り・変換・取り込みのどこで起きたかを最初に判定する役割です。これが未定だと両ベンダーへ同時連絡して押し付け合いになりがちです。発注側かいずれかのベンダー、または連携専任の第三者に、契約書上で明示的に割り当てておくべきだと考えます。
定義の「正」を一箇所に集約することが重要で、発注側の情報システム担当が管理する形も有効だと考えます。定義書が両ベンダーに分散すると、片方の無断変更で整合が崩れます。管理者を一人定め、項目・桁数・文字コードの変更は必ずその管理下で行うルールにしておくと、連携の崩れを相当程度防げると考えます。
唯一の正解はなく、自社の体制と既存WMSの状況で変わると考えます。既存WMSが安定稼働し社内に連携管理人材がいれば分業が向きやすく、登録まで窓口を一本化したい・新規構築なら一気通貫が向きやすいと考えます。既存基幹との接続要件が強い現場では、分業前提で責任分界を丁寧に設計する方が現実的な場合もあります。
実データを通す結合テストは発注側の関与が不可欠だと考えます。各社が自社範囲だけを確認して終えると、二社をまたいだ突き合わせが本番初回になりかねません。実際のOCR出力を実際のWMSに流す試験を、誰の費用で何日確保するかを契約に明記し、発注側も現物の伝票サンプルを提供して立ち会う体制が望ましいと考えます。
OCRとWMSの間に谷間が残ったまま契約に進むと、最初の障害で責任論が始まりかねません。まずは現物の帳票と現在のWMS登録項目を持ち寄り、どこで手が止まっているかを客観的に把握するところから始められます。体制と契約の設計段階からご相談いただけます。
連携の責任分界について相談する