注文書は紙、在庫の調整は Excel、正式な受注は基幹システム。工場でこうした運用が混在しているなら、AI を入れる前に、どの正式な記録（正本）を根拠に誰が確定するかを決めたいところです。注文書を読めても、品番や単位を取り違えたまま発注すれば手戻りになる。経営者・情シス・管理部門が発注前に整理すべき対象業務、承認の境目、本番に進める条件を、受発注・在庫・日報・図面の問い合わせに沿って考えます。
FDE とは何かをまとめたハブ記事では、FDE（Forward Deployed Engineer。顧客の現場に入り、動く仕組みと運用方法を残すエンジニア）の役割を整理しました。本稿はその製造業向けの設計例です。当社の経験として述べる範囲は、経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験に限ります。本記事では AX を、AI を使った業務の組み直しを指す語として使います。以下の工場の場面は特定企業の実績ではなく、発注側が自社の手順を検討するために置いた例です。
製造業の事務に AI を入れるなら、候補の作成、人による承認、基幹システムへの反映を分ける。受発注は品番と単位、在庫は使える数量、日報は観測した事実、図面は承認済みの版を確かめる。FDE に求めるのは、読み取り画面に加えて、保留・訂正・停止・引き継ぎまで動く仕組み。既存機能や社内の改善で足りる業務は、そこから始める。
この記事の要約
他社が実際に何をしたかは、公式発表と白書だけを根拠に 12 件を業務別に整理した製造業の生成 AI 活用事例の記事にまとめています。本記事はその事例を自社で設計する側の線引きです。
工場のどの仕事から始めるか
対象は「受発注全体」のような大きな括りから、担当者が結果を確認できる作業まで小さくします。たとえば、注文書から受注登録の候補を作り、原本と並べて確認するところまで。納期回答や仕入先への送信は別の判断として残す。入口と出口が明確なら、試作で何を確かめ、どの作業が残るのかを現場と話せます。設備の制御や検査の合否判定まで同じ計画に含めると、判断する人も誤りの影響も変わります。事務の整理とは別の案件として切り分け、今回の対象外だと発注書に書きます。
選ぶ際は、転記や検索が負担か、正しい答えを確認できるか、間違った候補を確定前に止められるかを見ます。自由記述の読解には AI を試す余地がある一方、品番による一致検索、決まった計算、担当者への通知は既存機能で処理できないかを先に確認する。工場全体の AI 化を目標にせず、どの待ち時間や手戻りを減らしたいのかを対象業務の名前と一緒に書き出します。
| 対象業務 | AI が作る候補 | 人が確定する内容 | 既存機能を先に試す場面 |
|---|---|---|---|
| 受発注 | 注文書の品番・数量・希望納期 | 受注内容、回答納期、発注先と送信 | 同じ書式の取り込み、品番の一致検索 |
| 在庫 | 照合先の候補と差異の説明案 | 使える数量、引当（注文用の在庫確保）、在庫調整 | 入出庫集計、棚卸し差異の一覧 |
| 日報 | メモの整理と申し送り案 | 発生事実、数量、停止理由 | 入力項目の統一、未提出の通知 |
| 図面の問い合わせ | 参照文書と回答の下書き | 適用する版、仕様の解釈、回答送信 | 図番と版による文書検索 |
たとえば日報の提出漏れだけが困りごとなら、入力画面と通知の整備から着手できます。注文データを取引先から決まった形式で受け取れるなら、その取り込みを整えるほうが読み取り候補を毎回確認する負担を抑えられる場合もある。AI の利用自体を検収の条件にすると、こうした選択肢を外してしまいます。発注書には解きたい困りごとを書き、手段を選ぶ余地を残したい。
着手前の確認は、FDE の初週に行う業務とデータの棚卸しを工場の帳票に当てはめると進めやすくなります。注文書を受け取る人、在庫を確認する人、納期を答える人の順に、同じ注文がどの画面を通るかを追う。紙が存在することより、その紙にしかない手書きの変更を誰が拾うかが論点です。紙を残す理由と、転記を残す理由は分けて聞き取ります。
紙・Excel・基幹システムの正本を決める
記録が食い違ったときに、業務判断の根拠とする正本を項目ごとに決めます。全部の項目を同じ場所に集める必要はありません。受注内容は基幹システム、製造指示の補足は承認済みの指示書という分担でもよい。ただし、品番や数量など同じ項目を両方で書き換えるなら、どちらの変更を誰が反映するかを決めます。AI に両方を渡してもっともらしいほうを選ばせる設計は避けます。
照合の単位も揃えます。品名が同じでも、寸法、材質、包装単位が違えば同じ品目として扱えないことがある。品番だけで識別できるのか、図面番号や版も必要なのかを現場が確認する。マスタ（品目や取引先の基準情報）に別名を登録するなら、AI が提案し、管理担当が採否を決める形です。一度の読み取り結果から、全注文に使う基準情報まで書き換えないようにします。
| 確認する項目 | 決めておく内容 | 不一致があったとき |
|---|---|---|
| 品番・名称・単位 | 基準情報の管理担当、別名、単位換算の根拠 | 候補を保留し、原本と基準情報を照合 |
| 受注・発注内容 | 注文番号と明細、変更前後の関係、正式な登録先 | 新規と訂正を分け、担当者に判断を戻す |
| 在庫 | 場所、ロット（製造・入荷のまとまり）、検査状態、数量の基準時点 | 引当や調整を止め、倉庫担当が確認 |
| 図面・指示書 | 承認状態、版、適用する注文や製造対象 | 検索の候補に留め、設計担当へ照会 |
表は発注側が用意する項目例です。在庫ではロットや保管場所も照合対象になります。システム上の数量が正しくても、検査待ち、他の注文への確保、出庫済みの未入力が混ざっていれば、そのまま納期回答には使えません。在庫画面を AI に読ませる前に、数字が表す状態と時点を説明できるようにしておきます。
Excel では、非表示の列や色で区別した例外、計算式を手入力で上書きしたセルも見ます。色の意味が担当者の記憶にしかないなら、入力項目や選択肢に変える候補です。紙の原本は撮影や読み取り後も候補に紐付け、後から見比べられるようにする。読み取りできない箇所を空欄として示すのか、確認待ちにするのかもここで決めます。見栄えのよい表に整えるだけでは、業務上の曖昧さは残ります。
データを外部の AI サービスに渡す範囲は、情シスと情報の管理担当が利用条件、契約、社内規程を見て判断します。図面の表題欄や注文書の連絡先まで、目的に関係なく送る構成にはしない。伏せた後も製品や取引先を推測できる場合があるため、氏名を消すだけで利用可とは扱わず、送る内容を具体的に確認する。保存する記録と期間も、既存の文書管理のルールに照らして決めます。
受発注と在庫は、承認と反映を分ける
受注の試作画面には、左に注文書の原本、右に品番・数量・単位・希望納期の候補を置きます。読めなかった欄は確認待ちのままにし、過去の注文から補った候補にはその根拠を示す。担当者は原本と基準情報を見比べて直し、確定内容を承認します。AI が出す納期候補には、在庫だけでなく生産予定や仕入先の回答が必要かを分けて表示し、希望納期を回答納期へそのまま転記しない設計にします。
承認済みと登録済みも別の状態です。承認後に通信が切れた場合、基幹システムでは登録が終わり、手元の画面だけが応答を受け取れないことがあります。失敗表示だけを見て登録し直すと、注文を重ねて作るおそれがある。受付番号、注文番号、明細、登録結果を照合し、未反映と分かった処理だけを再開する。結果が不明なら、再送ではなく照合待ちに残すことを検収条件に含めます。
kintone の公式ヘルプは、プロセス管理を状態・作業者・アクションの組み合わせとして説明しています。作業者を設定した場合、アクションのボタンは作業者だけに表示される。これを使えば確認待ちや承認の担当を設計できます。ただし、この機能の設定だけで基幹システムへの登録結果まで確認できるわけではありません。承認後の反映と照合は、接続先の仕組みに合わせて用意します。
発注では、仕入先への送信も独立した確定操作として扱います。数量の候補を作ることと、価格や納期の条件を含めた注文を送ることは別の仕事だからです。メールで届いた変更依頼が既存注文の訂正なのか追加注文なのか不明なら、担当者へ戻す。仕入先名や単位が変わったときは、前回の承認を引き継がず再確認する。承認後の編集があった場合にどう扱うかまで、画面の操作として確認したいところです。
在庫の引当は、数量の要約から切り離します。AI は差異の候補や確認先を整理し、引当は現時点の使える数量を確かめた担当者が行う設計から始める。複数の担当者が同時に同じ在庫を見た場合も、表示時点の数量だけで確定しない。基幹システム側で確保できたことを確認してから、納期回答や出庫指示に進めます。
在庫差異を AI に説明させる場合も、原因の仮説と訂正する数量を混同しません。「出庫入力の遅れかもしれない」という案が出たら、倉庫担当が入出庫記録と現物を確かめる。調整を行った場合は、元の数量、調整量、理由、確定した人を追える形にする。候補を人が承認するだけで誤りがなくなるとは考えず、原本を見ずに承認できてしまう画面や、まとめて承認する運用も点検します。
分納（注文した品を分けて納めること）と取消しも、検証する場面に含めます。注文全体の数量が変更されたのか、まだ納めていない分だけが変わったのかで、直す内容が異なるためです。受注の候補画面には元の注文、納品済みの記録、今回の変更内容を並べ、担当者が残りの数量を確認する。取消しの連絡を受けた時点で、すでに発注や製造指示が出ているなら、その担当へ戻す手順も要ります。文章から数量を拾うだけで処理を完了させない範囲を、試作で確かめます。
日報と図面の問い合わせは、根拠を残す
日報は文章を短く整える作業から試せます。ただし、作業者が見た事実、原因として疑っていること、引き継ぐ依頼を別の欄にする。たとえば「異音があり停止。原因は未確認」というメモを、「部品の摩耗で停止した」と書き換えると推測が事実に変わってしまいます。AI の案と元のメモを並べ、数量・時刻・停止理由は記録した本人か確認担当が確定する形です。
申し送りでは、読みやすさと取りこぼしを別に評価します。きれいな要約でも、「再開前に担当者へ連絡」という条件が消えていれば使えない。未確認、保留、再確認の依頼は要約後も残るかを見ます。作業者が長文を入力しないと使えない画面では、日報を書く負担を増やしかねません。選択式の項目と短い補足で足りるなら、その入力方法を優先します。
安全に関わる異常連絡は、日報の AI 処理が終わるまで待つ流れに含めません。既存の連絡・停止・再開判断の手順を先に使い、日報の整理はその後に扱う設計です。AI が停止理由を分類できたことと、設備を再開してよいことは別の判断。対象を事務の整理に限定するなら、その境界を現場の画面と操作手順にも書き、設備操作の指示文として受け取られないようにします。
図面の問い合わせでは、図番（図面を識別する番号）、版、承認状態、適用対象を確認してから文書を探します。ファイルの更新日時が新しいという理由だけで、使用する版を決めない。承認済みでも、今回の注文に適用する版とは限らないためです。AI の画面には回答案と一緒に、参照した図面・指示書・該当箇所を表示し、設計担当や品質担当が原文を開けるようにします。
社内文書を検索し、その結果をもとに AI が回答を作る構成（本記事では RAG と呼びます）を使う場合も、検索対象の文書が適用してよい版かどうかは別に管理します。文書が見つからないときは、似た製品の仕様を当てはめて答えるのではなく、参照できた資料と不足している情報を示して照会へ戻す。本稿で提案するのは問い合わせの下書き支援であり、図面の寸法、公差（寸法などに認めるずれの範囲）、材質を AI が独自に確定する運用ではありません。
閲覧範囲も回答内容の一部として確かめます。kintone のレコード権限の公式ヘルプでは、条件に応じて閲覧・編集・削除できるユーザーを設定できます。文書検索を別の仕組みに接続するなら、その閲覧範囲を検索結果や回答にも引き継げるかを、接続の設計時に確かめます。元の画面で開けない図面の要点が、AI の回答だけで読める状態にしない。権限の異なる利用者で、文書名や回答にも情報が出ないかを確かめます。
画面は現場で使う端末でも確認します。事務所の大きな画面では読める図面の注記が、現場の端末では拡大しないと読めないなら、回答案だけで判断する使い方に寄りかねません。原文を開き、該当箇所を拡大し、確認後に元の問い合わせへ戻る操作まで試す。共有端末を使う場合は、実際に確認した人をどう記録するかも決めます。日報や図面の回答を正しく作ることに加え、その場で根拠を確かめられることを画面の受け入れ条件にします。
本番の判断は、例外を止めて戻せるかで見る
生成 AI の評価設計の記事では、出力の正しさ、業務として受け入れられるか、運用の条件を満たすかを分けています。製造業の事務でも、読み取りの一致だけで合格にしない。数量の文字は合っていても単位が違う、図面の内容は合っていても対象の版が違う、といった業務上の誤りを検証に含めます。下の表は発注時に合意する確認項目の例で、一般的な合格率や業界基準を示すものではありません。
| 試す場面 | 合格に向けて確かめる動作 | 未達だった場合の扱い |
|---|---|---|
| 注文書の文字が読めない・単位が不明 | 不明欄を示し、担当者へ戻る | 自動登録の対象外として原本確認 |
| 注文変更・同じ注文の再送 | 新規か訂正かを照合して処理を分ける | 候補を保留し、注文番号と明細を確認 |
| 在庫が更新中・反映結果が不明 | 再照合し、確定していない数量を使わない | 引当や再送を止め、担当者が照合 |
| 旧版・未承認・閲覧権限のない図面 | 適用版を確認し、対象外の情報を出さない | 回答案を止め、資料の管理担当へ照会 |
| 日報に原因未確認・異常の記載 | 未確認の表現を残し、既存の連絡手順を妨げない | 原文で引き継ぎ、要約の利用範囲を見直す |
検証に使う入力と期待する扱いは、現場が判断できる形で揃えます。利用許可を確認した業務データから、通常の入力と実際に起きる例外を選び、不足する場面は設計上の試験として追加する。作った試験例と実業務の記録は区別します。担当者の意見が割れたときは AI の誤りと決めつけず、未決の業務ルールとして判断者へ上げる。正解が決まっていないまま採点を繰り返しても、本番に入れる条件は定まりません。
効果を測る際は、AI が処理した時間だけでなく、担当者の確認、訂正、例外の照会、基幹システムへの反映確認も含めます。導入前と同じ範囲の仕事を比べ、対象件数と入力の種類を添える。候補の修正が少なくても、承認待ちが長ければ納期回答は早まらないからです。許容できる確認時間や費用は自社の実測から決め、資料に根拠のない削減率や期間を契約の前提に置かないようにします。
本番は、対象帳票や担当部署を絞り、人が確認する運用から始める案が考えられます。限定した範囲でも、注文変更や担当者の不在が起きたときの処理を見届ける。旧版の参照、権限外の情報表示、二重登録などが確認された場合に、どの機能を止め、誰が原本に戻って確認するかを決めます。止める操作を管理者しか知らない状態にせず、利用者が異常を知らせる窓口と、その後の業務の続け方も用意します。
FDE に渡す依頼と、社内に残す仕事
発注の出発点は、困っている帳票、正式な記録の場所、確定する担当者を同じ資料に並べることです。「AI で工場を効率化したい」だけでは、図面検索を作るべきか、在庫の更新手順を直すべきかが決まりません。原本を探す時間なのか、品番の照合なのか、上長の承認待ちなのか。現場で見えた負担と、変えてよい範囲をセットで伝えると、必要な作業を見積もる材料になります。
社内の担当は、FDE を受け入れる体制の記事で示した Echo 役（社内で業務と仕組みを引き継ぐ担当）を中心に置く案が使えます。製造業の例なら、受注から製造指示への流れを知る担当者が論点を整理し、数量や納期は業務責任者、図面の適用は設計・品質の担当、データの利用範囲と接続は情シスへ確認する。Echo 役がすべてを代決する体制にはせず、不在時の確認先も決めておきます。
FDE に求める成果物には、動く画面に加えて、正本と項目の対応表、承認と反映の手順、例外の試験結果、利用権限、停止と再開の手順を含めます。たとえば同じ注文をもう一度受け取った場合、候補のまま残せるか、登録済みを照合できるか、訂正として扱えるかを一緒に確認する。通常の入力を見せるだけの実演では、現場が本番で判断する材料が足りません。
引き継ぎでは、社内担当が自分の権限で原本を探し、候補を直し、保留を解消し、反映結果を確認するところまで操作します。FDE が隣で操作を代わった箇所は、手順や権限の不足として残す。仕入先の書式変更や図面の改訂があったときに、誰が設定を見直し、どの試験を再実施するかも渡します。納品時に動いたことと、変更後も自社で回せることを分けて受け取るためです。
社内に業務を理解して設定・検証まで進められる人がいて、既存の受発注機能や文書管理で困りごとを解消できるなら、その対応から始めて構いません。複数部署をまたぐ判断や古い仕組みとの接続で作業が止まり、試作から運用の引き継ぎまで担う人が足りない場合は、FDE 型の支援が選択肢になります。当社は、AI の機能数よりも、現場が候補を確かめ、誤りを戻し、正式な記録を更新できる範囲を発注の単位にする考えです。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
工場の帳票と承認手順から、AI を使う範囲を整理しませんか
受発注・在庫・日報・図面の問い合わせについて、正式な記録の場所、人が確定する操作、基幹システムへの反映確認を一緒に整理します。既存機能や社内対応で足りる範囲も含め、試作から本番、引き継ぎまでの進め方をご相談いただけます。