システムを一本化してからでないとAIは入らない——多くの現場でそう信じられています。しかし実際の中小製造業は、クラウドSaaS・古い基幹・Excel・紙が同時に動いています。統一を待つのではなく、混在のまま「読み取って構造化する」層を先に置く順序を考えます。
多くの中小製造業でシステムが混在しているのは、経営判断のミスではなく、事業が続いてきた結果だと考えられます。十数年前に導入した基幹システムがまだ受発注と在庫を回し、後から勤怠や経費はクラウドSaaSに移り、現場の細かい管理はExcelで作り込まれ、取引先とのやり取りは今も紙のFAXや手書き伝票が残る——これは順番に必要を満たしてきた歴史の地層です。悪いものが積み重なったのではなく、その時々の最適が層になっています。
ここで言う「基幹システム」とは、受発注・在庫・生産・原価など会社の中核業務を扱う仕組みを指し、「SaaS」はブラウザ経由で使うクラウド型のサービスを指します。両者はデータの持ち方も更新の速さも違い、そのあいだを人が転記でつないでいるのが実態の会社は少なくないと考えられます。
困りごとの多くは、システムが複数あること自体ではなく、そのつなぎ目に人手の転記が挟まっている点に集約されると考えられます。SaaSの画面を見ながら基幹に打ち直す、紙の伝票をExcelに入力する、Excelの数字を別の帳票へ写す——この転記が、遅延・入力ミス・担当者しか分からないルールの温床になりうると考えます。まず把握すべきは「どこにシステムがいくつあるか」ではなく「どこで人が写しているか」だと考えます。
結論から言えば、統一を待つ必要はないと考えます。むしろ「一本化してからAI」という順序は、着手を無期限に先送りする最大の要因になりうると考えられます。基幹の入れ替えは要件定義から移行まで年単位になりやすく、その間ずっとAI活用は始まりません。統一が完了する頃には現場の課題も市場も変わっている、ということが起こりえます。
統一が目的化しやすいのは、それが分かりやすく「きれいな状態」に見えるからだと考えられます。しかし経営から見た本当のゴールは、システムが一つになることではなく、転記が減り・データが後から使える形で溜まり・人が判断に時間を使えることのはずです。手段と目的を切り分けると、統一は数ある選択肢の一つに過ぎないと整理できます。
古い基幹やExcelの作り込みは、負債であると同時に、その会社の業務ルールが凝縮された資産でもあると考えられます。動いているものを止めて作り直すより、既存を残したまま活かす前提に立つほうが、リスクも投資も小さく収まりうると考えます。この観点はレガシー資産とAIや、Excel/VBA資産の扱いでも整理しています。統一という大工事の前に、できることは少なくないと考えます。
最初の一手は、頻度が高く・転記が発生し・担当が属人化している業務を選ぶことだと考えます。この三つが重なる業務は、負担が大きく、止まると影響が出やすく、しかも本人しか手順を知らないため、改善の効果も検証のしやすさも高くなりうると考えられます。逆に、頻度が低い業務や、すでにきれいにデータ化されている業務は後回しでよいと考えます。
技術的な入口として置きやすいのは、紙やPDFを読み取って構造化する層です。ここで言う「構造化」とは、伝票や帳票の内容を、後から検索・集計・照合できる項目つきのデータに変換することを指します。帳票のデジタル化は、既存システムを改修せずに始められる入口の一つになりうると考えます。読み取った結果を人が確認してから基幹へ渡す形にすれば、既存の運用を壊さずに転記だけを圧縮できる可能性があります。
入口を選んだら、対象を一つの業務フローに絞り、そこだけを端から端まで通すことをおすすめしたいと考えます。全社一斉ではなく、一本の川の上流から下流までをまず流し切ると、どこで詰まるか・どこで人の判断が必要かが具体的に見えます。ここで得た知見を、似た業務へ横展開していく順序が現実的だと考えます。順序の設計そのものは、導入コンサルティングのような外部の視点を借りて小さく始める選択肢もあると考えます。
基本設計は、既存システムの外側に構造化層を独立して置き、既存には触れないことだと考えます。基幹の中を改修すると影響範囲が読めず、ベンダー保守の対象外にもなりかねません。そこで、紙・PDF・Excel・SaaSの出力を受け取って読み取り、項目つきのデータに整えて溜める層を別に用意し、既存システムとは必要最小限の受け渡しでつなぐ構成が扱いやすいと考えられます。この溜め場の考え方は工場データ基盤として整理しています。
読み取りの中核には、VLMのような技術が候補になりうると考えます。VLM（Vision Language Model）とは、画像と言葉を同時に扱い、書式が一定でない帳票や手書きの内容も文脈から解釈しうるモデルを指します。定型のOCRが苦手としてきた「レイアウトが揺れる書類」への適性が期待できますが、どこまで読めるかは書類の質・照明・現物によって変わるため、必ず自社の現物で検証することが前提になると考えます。
取引先情報や図面など外部に出しにくいデータを扱う場合、処理を社内で完結させる構成が有効になりうると考えます。「オンプレミス」とは自社内に設備を置いて運用する方式、「エッジ」とは現場の機器側でデータを処理する方式を指します。Jetsonのような小型のエッジ機器で読み取りを社内完結させれば、クラウドへ送らずに構造化できる可能性があります。ただし処理能力や運用負荷とのバランスは要検証で、どちらが向くかは扱う情報の機密度と量で分かれると考えます。
向き不向きを整理すると、クラウド側で読み取るのが向くのは、機密度が低く量の変動が大きい書類の場合だと考えられます。一方、社内完結が向くのは、外部に出せない情報を含む書類や、通信を前提にしたくない現場の場合だと考えます。両者は排他ではなく、書類の種類ごとに使い分けられうると考えます。
会計・請求・税務のように、一円の誤りも許されず、ルールが決定論的に決まっている領域は、当面AIで自動化しない判断が妥当だと考えます。これらは「だいたい合っている」では成立せず、確定した正解が制度で定められています。読み取りの補助として下ごしらえに使う余地はあっても、最終確定を確率的な推論に委ねるのは向かないと考えられます。
判断の目安は、その業務が「厳密な正解を持つか」「揺らぎを許容できるか」だと考えます。厳密な正解を持ち、間違いが即座に損害や信用問題になる領域は、既存の決定論的な仕組みに委ね続けるほうが安全だと考えます。逆に、転記や仕分け、下書きの生成のように、人の確認を挟める工程はAIの適性が出やすいと考えられます。
適性のある領域でも、読み取り結果をそのまま基幹へ流し込む全自動は当面避け、人が確認してから確定する工程として設計することをおすすめしたいと考えます。AIは負担の大きい下ごしらえを引き受け、人は判断に集中する——この役割分担にすると、精度が完璧でなくても実務に載せられる可能性が高まると考えられます。全自動を急ぐより、確認付き半自動から始めるほうが現実的だと考えます。
導入で終わらせず、社内に運用できる人を育てることが継続の条件になると考えます。中小製造業では情報システムを他業務と兼任している場合が多く、外部に丸投げすると、書式が変わっただけで止まり、原因も分からず放置される事態が起こりえます。読み取りの結果を確認・修正し、うまくいかない書類を切り分けられる担当が社内にいることが、定着の分かれ目になりうると考えます。
そのための土台づくりとして、AI活用研修のように、現場担当が自分の言葉でAIの得意・不得意を理解する機会が役立つと考えます。専門家を新たに雇うのではなく、今いる担当が「どこまで任せ、どこで人が見るか」を判断できるようになることが、混在環境では特に重要になると考えられます。
運用初期は転記削減が主目的でも、構造化されたデータが溜まっていくこと自体が後から効いてくると考えられます。項目つきで蓄積されたデータは、後日の分析・検索・別業務への転用の土台になりえます。最初の一手を選ぶ段階から、読み取った結果を「捨てずに使える形で残す」設計にしておくと、後の選択肢が広がると考えます。
事前に知っておくと避けやすい落とし穴を挙げます。いずれも「やってみないと分からない部分」を含み、現物での検証を前提にすべき点だと考えます。
出発点は、自社の情報の流れを客観的に把握することだと考えます。どこにシステムがいくつあるかより、どこで人が転記しているか・どの業務が属人化しているかを書き出すことが最初の一歩になりうると考えます。ここが曖昧なまま技術選定に進むと、入れる場所を間違える可能性があります。
次に、頻度が高く・転記が多く・属人化した業務を一つ選び、その業務の紙やPDFを実際にどこまで読み取れるか、現物で小さく試すことをおすすめしたいと考えます。数値目標より先に、自社の書類で「どこまでいけて、どこで人が要るか」を体感することが、その後の判断精度を上げると考えられます。
一つの業務で確認付き半自動が回り始めたら、そこで得た知見を似た業務へ広げていく——この順序が、混在環境では無理がないと考えます。統一という大工事を待たず、混在のまま読み取って構造化する層を先に置き、触ってはいけない領域は既存に委ねる。この切り分けができれば、今の環境のままでも第一歩は踏み出せると考えます。順序設計を外部と一緒に進めたい場合は、導入コンサルティングのような小さく始める選択肢もあると考えます。
統一を待つ必要はないと考えます。混在したまま、既存システムの外側に「読み取って構造化する」層を薄く置くことから始められる可能性があります。基幹の入れ替えは年単位になりやすく、待つほど着手が遅れます。まずは転記が多く属人化した業務を一つ選び、既存に触れずにその手前へ層を足す順序が現実的だと考えます。
必ずしも作り替える必要はないと考えます。古い基幹やExcelの作り込みは業務ルールが凝縮された資産でもあり、動いているものを止めるより、既存を残したまま外側から活かす前提のほうがリスクも投資も小さく収まりうると考えます。改修は影響範囲が読めず保守対象外にもなりえるため、外側に構造化層を置く設計を基本にすべきだと考えます。
会計・請求・税務のように決定論的で厳密な正解を持ち、一円の誤りも許されない領域は、当面AIで自動化しない判断が妥当だと考えます。これらは確率的な推論に最終確定を委ねるのは向きません。制度上の数値や適用範囲は所管省庁の最新の公表資料でご確認ください。転記や仕分けなど人の確認を挟める工程はAIの適性が出やすいと考えます。
精度は書式の揺れ・紙の状態・照明・手書きの有無で変わるため、一律の数値を断定できないと考えます。VLMのような技術は書式が一定でない帳票にも適性が期待できますが、どこまで読めるかは自社の現物・現場での検証が前提です。まずは実際の書類で小さく試し、どこまでいけてどこで人の確認が要るかを把握することをおすすめします。
運用できる可能性はあると考えますが、社内に確認・修正・切り分けができる担当を育てることが条件になると考えます。外部丸投げは書式変更一つで止まる要因になりえます。専門家を新たに雇うより、今いる担当がAIの得意・不得意を理解し「どこまで任せどこで人が見るか」を判断できるようになることが、混在環境では特に重要だと考えます。
システムの統一を待たなくても、転記が多く属人化した業務から小さく始められる可能性があります。まずは自社の実際の書類を現物で読み取ってみて、どこまでいけてどこで人が要るかを一緒に確かめるところから。元キーエンス画像処理事業部の現場知見をもつエンジニアが、順序の設計からご一緒します。
混在環境でのAI導入について相談する