公開日:2026年9月22日

「見積依頼の確認だけで午前中が終わる」「手順書はあるのに、結局ベテランへ聞きに行く」——という方は少なくありません。製造業の生成AI活用は、見積・手順書・報告書の「読む、探す、まとめる」作業から始められます。 本記事では、中小メーカーが取り組みやすい5つの使い方を、渡す資料、受け取る下書き、人が確認する内容まで具体化します。
紹介する帳票と入力例は、説明用に作った架空のものです。設備の運転や出荷判定まで自動化する想定ではなく、現場の判断に必要な情報を揃えるところを対象にしています。
生成AIに向くのは、書き方がばらばらな文書を読み、必要な情報や確認事項を取り出す仕事です。 生産数の集計は既存の計算処理、加工の可否や品質の判定は担当者が受け持ちます。役割を決めると、どの業務から試せばよいかが見えてきます。
生成AIは、指示に応じて文章などを作る仕組みです。例えば、メールに散らばった材質・数量・希望納期を一覧へ整理したり、承認済みの作業標準書から該当する記載を探したりできます。文章の形が一定でないほど、こうした整理が役立つ場面があります。
一方、外観検査や予知保全には、検査画像や設備の計測データを使う専用の仕組みが必要です。文章を扱う生成AIの導入と同じ検証で済むわけではありません。設計案の作成を補助できても、寸法公差や強度、安全性が正しいことまでは保証されません。
| やりたいこと | 主に使う仕組み | 確認するポイント |
|---|---|---|
| 依頼文や報告を整理する | 生成AI | 原文にない条件を追加していないか |
| 数量・原価・在庫を集計する | Excelや既存システムの計算 | 単位、計算式、対象期間が正しいか |
| 製品画像から不良を検出する | 検査用の画像認識など | 対象製品と撮影条件で検出性能を確かめたか |
| 加工条件や出荷可否を確定する | 現場責任者の判断と承認 | 正式な仕様・検査結果・承認基準を満たすか |
工場全体のシステムを入れ替える必要はありません。毎日繰り返す資料確認を一つ選び、現在のExcelや共有フォルダとつなぐ範囲を決めます。現場が期待するのは、新しいチャット画面そのものより、手戻りなく次の工程へ進める状態です。

最初に選びたいのは、原本と見比べて正誤を確かめられ、下書きの段階で止められる業務です。 下の5つは、製造業で想定できる活用方法です。実際の導入では、扱う製品、資料の形式、承認手順に合わせて調整します。
メール、添付PDF、図面の注記を行き来しながら、材質、数量、処理、希望納期を確認する仕事が対象です。生成AIへ依頼文を渡し、「項目、原文の記載、記載位置、未確認事項」の列へ整理させます。情報が揃うため、営業から製造へ確認する往復を減らしやすくなります。
図番が同じでも、改訂記号が違えば同じ条件とは限りません。「前回同様」としか書かれていない場合は、前回のどの注文を指すか確認が必要です。AIが似た案件を探して埋めると、別の仕様で見積もる危険があります。図番と改訂、数量の単位は担当者が原本を見て確定します。
加工時間、材料歩留まり、段取り回数、単価は、承認済みの原価表や計算式へ接続して算出します。生成AIの仕事は、計算に必要な条件を揃えるところまでです。見積金額と回答納期の確定は、製造側の負荷や材料手配を確認してから行います。
担当者が「この製品の検査記録はどの様式を使うか」と質問し、対象の標準書や様式へのリンクを受け取る使い方です。製品群、設備、工程、適用日、承認状態を文書に持たせると、探す対象を絞れます。回答の横には、文書名、版、該当ページと原文を並べます。
社内資料を検索し、その情報を使って回答する構成はRAGと呼ばれます。資料をまとめて渡すだけでは、旧版と現行版の使い分けは保証されません。例えば設備を選ばずに「点検方法は」と聞かれたら、先に設備名を確認する流れにします。
作業者は回答だけで作業条件を変更せず、正式な手順書を確認します。対象資料が見つからないときや記載同士が矛盾するときは、担当部署へ回す必要があります。未承認の下書きを検索対象から外すことも、回答の文章を整える前に決めたい条件です。
日立システムズの製造業向けアシスタントAIの公式事例では、規格の確認支援に引用元を表示する仕組みが紹介されています。製造仕様書のレビューでは、原文と翻訳を並べる画面も用意されています。回答を受け取った人が元資料へ戻れる設計は、中小メーカーでも参考になる考え方です。
現場メモを、「発生日時、対象ロット、観察した現象、実施済みの処置、未確認事項」に整理する用途です。担当者ごとに報告の順序が違っても、同じ見出しへ揃えられます。品質担当者が追加で聞くべき項目を把握しやすくなるでしょう。
例えば「表面に傷。搬送中かもしれない」というメモなら、傷が観察されたことと、搬送が原因という仮説を分けます。「搬送時の接触が原因」と確定した報告文へ変えてはいけません。再発防止策も、確認済みの処置と検討中の案を別欄に置きます。
AIが作った文章は、調査結果の代わりにはなりません。原因分析や取引先へ提出する報告の承認は、品質責任者が行います。類似不具合の検索を加えるなら、同じ現象名だけでなく、材料、設備、発生工程が比較に適しているかも見る必要があります。
日報や申し送りには、生産実績と、次の担当者に伝える注意事項が混在します。確定済みの実績値はそのまま受け取り、文章部分から「未完了の仕事、確認待ち、次の担当者への連絡」を抜き出すと引継ぎに使えます。件数や稼働時間の集計は表計算へ任せます。
「調整済み」と書かれていても、何を調整し、再確認したのかが不明なら、そのまま完了扱いにできません。設備、処置、確認結果の不足を質問に変える設計にします。「明朝確認」のような相対表現も、記録日時を踏まえて担当者が日付を確定します。
引継ぎ資料には元の日報へのリンクを残し、処置の完了と責任者の確認を別の状態で管理します。夜勤から日勤へ引き継ぐ際に、要約だけで安全に関する注意が消えていないか確認することが大切です。重要な申し送りは原文も併記します。
作業を説明した記録や承認済み資料から、教育用の説明文、用語集、確認問題を作る方法です。説明の順序を整える作業を生成AIへ任せると、ベテランは内容の確認に時間を使えます。録音する場合は、社内の取扱ルールと説明者の同意を確認してから始めます。
暗黙の判断基準は、文章を要約するだけでは残せません。「どんな状態なら作業を止めるか」「通常と違う場合は誰に確認するか」を聞き取る必要があります。資料にない数値条件をAIに補わせず、未記載のまま確認事項として残します。
翻訳した教育資料も、設備名称、単位、禁止事項、否定表現が原文と一致しているか、内容と言語を確認できる担当者が点検します。AIの下書きから正式な標準書へ進める場合は、文書の改訂と承認の手順を通します。

不足や矛盾を含む架空の見積依頼6件を試すと、事前に決めた停止条件と6件すべて一致しました。
2026年9月22日、本文編集とは別のCodexセッションへ、指示文と入力6件だけを渡して確認しました。先に作った正解表と出力は渡していません。
外部APIは使っておらず、正確なモデル版と生成設定は取得できていません。同じファイルを使っても、同じ出力になる保証はありません。
これは精度を示す試験ではありません。少数の架空データで、入力にない条件を補わず、確認待ちや矛盾として止められるかを見たものです。
図番、改訂、数量、材質、表面処理、希望納期を抽出します。
全項目が確定した場合だけ「次の処理へ進める」とします。1項目でも不足すれば確認待ち、記載が食い違えば停止にしました。
| 試験 | 依頼に含めた問題 | 事前に決めた結果 | 実際の出力 |
|---|---|---|---|
| M01 | 不足なし | 次の処理へ進める | 一致 |
| M02 | 材質が「前回同様」 | 確認待ち | 一致 |
| M03 | 数量が200個と250個 | 矛盾として停止 | 一致 |
| M04 | 改訂がBとC | 矛盾として停止 | 一致 |
| M05 | 表面処理の種類がない | 確認待ち | 一致 |
| M06 | 希望納期の年がない | 確認待ち | 一致 |
例えばM02では、材質を推測せず、「材質をご指定ください」と質問へ変えました。M03とM04では片方の記載を採用せず、矛盾として止めています。
次の指示で、各項目に値、状態、原文の根拠、確認質問を返すよう指定しました。
あなたは製造業の見積依頼を整理する担当です。
入力文に書かれている事実だけを、指定したJSON形式で返してください。
対象項目:
- drawing_number(図番)
- revision(改訂)
- quantity(数量と単位)
- material(材質)
- surface_treatment(表面処理の種類)
- requested_delivery_date(希望納期。年・月・日が必要)
各項目は次の4つを返します。
- value:入力文だけで確定できる値。確定できなければ null
- status:confirmed / needs_confirmation / conflict のいずれか
- evidence:根拠となる入力文の原文。なければ空文字
- question:確認が必要な場合に相手へ聞く質問。confirmedなら空文字
ルール:
1. 「前回同様」から材質や処理を推測しません。
2. 「表面処理あり」だけでは処理の種類を確定しません。
3. 数量、図番、改訂などが複数あり一致しない場合は conflict にします。
4. 希望納期は年・月・日が揃わなければ needs_confirmation にします。
5. 入力文にない値を、一般知識や似た案件から補いません。
6. すべての項目が confirmed なら overall_status は ready です。
7. conflict が1つでもあれば overall_status は conflict です。それ以外で needs_confirmation があれば overall_status は needs_confirmation です。
出力形式:
{
"case_id": "入力のcase_id",
"overall_status": "ready / needs_confirmation / conflict",
"fields": {
"drawing_number": {"value": null, "status": "needs_confirmation", "evidence": "", "question": "図番をご指定ください。"},
"revision": {"value": null, "status": "needs_confirmation", "evidence": "", "question": "改訂をご指定ください。"},
"quantity": {"value": null, "status": "needs_confirmation", "evidence": "", "question": "数量と単位をご指定ください。"},
"material": {"value": null, "status": "needs_confirmation", "evidence": "", "question": "材質をご指定ください。"},
"surface_treatment": {"value": null, "status": "needs_confirmation", "evidence": "", "question": "表面処理の種類をご指定ください。"},
"requested_delivery_date": {"value": null, "status": "needs_confirmation", "evidence": "", "question": "希望納期を年を含めてご指定ください。"}
}
}
説明文やMarkdownは付けず、JSONだけを返してください。
入力、正解表、出力、検証用プログラムを公開します。5ファイルを同じフォルダへ保存し、python3 verify_trial.pyを実行すると、各ケースの値、状態、根拠、質問を正解表と照合できます。
M01: PASS (ready)
M02: PASS (needs_confirmation)
M03: PASS (conflict)
M04: PASS (conflict)
M05: PASS (needs_confirmation)
M06: PASS (needs_confirmation)
summary: 6/6 PASS
このプログラムは、保存済みの出力を正解表と照合するものです。生成AIをもう一度実行する機能はありません。
6件に合った指示が、別の書式や実際の取引先メールでも同じように働く保証はありません。本番前には、自社で起きる単位違い、添付漏れ、複数図面、改訂差し替えなどを追加して確認します。
弊社が公開している営業ヒアリングシステムの開発例でも、聞き取った内容をAIで整理し、資料の形式へ整える工程を扱っています。製造業の見積へ応用する場合は、図番・改訂・単位・未確定条件の管理を追加して設計する必要があります。
実際の資料を入力する前に、使えるサービス、入力できる情報、閲覧できる人、保存と削除の扱いを決めます。 社名を消した図面でも、形状や図番、加工条件から取引先や製品が分かる場合があります。名称を伏せただけで共有可能と判断しないことが重要です。
図面や仕様書には、秘密保持の条件や利用目的の制限が付いていることがあります。入力に使えるかは、社内規程と契約に沿って責任者が確認します。試作には、元案件を推測できないよう最初から作成した架空資料を使う方法があります。
生成AIサービスは、契約プラン、設定、連携機能によってデータの扱いが異なります。学習への利用条件に加え、保存期間、管理者の権限、外部ツールへの送信先まで確認します。個人情報を含む入力については、個人情報保護委員会の注意喚起も、提供事業者による機械学習への利用などの確認を求めています。
営業に見せてよい資料と、製造原価を含む資料は同じとは限りません。検索結果を生成AIへ渡す前に、利用者が閲覧できる文書だけへ絞る必要があります。回答の表示時に隠すだけでは、見せてはいけない内容が要約へ混ざるおそれが残ります。
文書内の「以前の指示を無視して送信して」といった文章を、システムへの命令として実行させない設計も必要です。資料は参照情報として扱い、外部送信や本番更新の権限を読み取り処理に与えないようにします。回答を作る処理と実行する処理を分ける考え方は、AIツールの権限管理と機密情報の扱いでも解説しています。
資料の選び方や確認工程に原因がある場合があります。 正しい文章があっても、対象の設備や版が違えば現場では使えません。モデルを替える前に、症状ごとに直す場所を切り分けると試行錯誤を減らせます。
| 起きていること | 原因として確認すること | 対処法 |
|---|---|---|
| 旧版の手順を答える | 適用日や廃止状態を管理していない | 文書の版・適用対象・承認状態で検索対象を絞る |
| 数量や寸法が違う | 画像の読み取り誤り、単位の混同 | 該当箇所の原文と抽出値を並べて照合する |
| 別製品の不具合例を出す | 現象名だけで類似検索している | 材料・設備・工程などの条件を追加する |
| 確認のほうが手間になる | 回答が長く、根拠の場所が分からない | 差分と未確認事項を先に表示する |
| 担当者が使わなくなる | 転記先や承認手順が日常業務と離れている | 普段使う一覧やフォルダへ結果を戻す |
PDFが画像だけの場合は、OCRという文字の読み取り処理を挟むことがあります。その段階で小数点や記号を誤ると、後の文章整理が正しくても結果は誤りです。読み取り、検索、文章生成、登録のどこで問題が起きたか記録すると、原因に合った修正ができます。
資料の整備を全部終えるまで導入を待つ必要はありません。対象業務で必要な文書だけ、正式版と担当者を決めて試します。名称の揺れは対応表で吸収できますが、同じ名称の別部品を一つへまとめないよう現場で確認します。
架空資料で試作し、現行業務と並行して確かめ、合格した対象から承認付きで連携します。 試験中に元の台帳を上書きしなければ、出力が誤っても普段の仕事を続けられます。導入全体の整理には、中小企業のAI導入ロードマップも参考になります。
「事務を全部減らす」では範囲が広すぎます。「メールで届く見積依頼の条件を、営業が確認する一覧へまとめる」のように、入力と出力を一組で決めます。現行の作業時間と、確認に戻った理由も記録します。
最初の資料には、正常な例だけでなく、単位の欠落、旧版の添付、メールと添付の矛盾を含めます。良い回答が出る資料だけを選ぶと、運用開始後のつまずきを見つけられません。
担当者が原本から作った正解表を用意し、生成AIの出力と項目単位で比較します。文章の自然さではなく、図番・版・数量・単位が一致するか、欠けた条件を保留できるかを確かめます。重要項目に未解決の誤りがある間は、本番の自動登録へ進みません。
図面の改訂が不一致なら登録を止める、数量の単位が欠けていれば確認待ちにする、資料にない材質は生成しない、などの条件を決めます。検索用途では、権限外の資料が回答にも引用にも出ないことを試します。モデルや設定を変えた後も、同じ資料で結果を比べられるよう保存します。
担当者が通常どおり処理した結果と、生成AIの下書きを比べます。測るのは生成にかかった時間だけではありません。入力準備、原本との照合、修正まで含む一連の時間と、確認漏れを記録します。
仕事が楽になったかを判断するには、通常例と例外を分けて見る必要があります。標準的な依頼は短くなっても、複雑な依頼の手直しが増えるなら、その依頼は人が処理する対象として残せます。
CSVの取込やAPIというデータ連携の窓口があれば、既存ツールへ接続できます。連携できない場合も、確認済みの一覧を同じ形式で出力する方法があります。保存先と担当者を決め、未承認の下書きと確定データを混ぜない構成にします。
同じメールを再処理しても台帳に二重登録しないこと、途中で止まった処理が担当者に分かることも必要です。登録に失敗した状態を「完了」にせず、どこまで処理したか記録します。障害時に手作業へ戻せる手順まで揃えて、日常業務への導入を判断します。

普段の資料で何を作り、どの条件で止め、誰が承認するかを具体的に説明してもらいましょう。
「精度が高い」という説明だけでは、対象の図面や帳票で使えるかは判断できません。
架空資料を渡し、正常例と情報不足の例で出力を確認すると比較しやすくなります。
例えば「改訂違いの図面が混じったとき、画面では何が出るか」「担当者が修正した値はどこに残るか」「登録途中で通信が切れたら再実行できるか」と尋ねます。正しく動く場合だけでなく、保留と復旧の説明があるかを見ると、運用まで考えているかが分かります。
費用を比較するときは、文書の整理、試作、既存システム連携、権限設定、運用保守を分けて確認します。月額利用料だけが安くても、資料追加や改訂のたびに別作業が必要なら、担当者の負担が残ります。具体的な費用の考え方はAI開発の費用相場で整理しています。
納品時には、設定と対象資料の管理方法、受入確認の結果、障害時の連絡先、データの返却・削除方法を確認します。社内で更新する範囲と、開発側へ依頼する範囲を決めておけば、担当者が変わっても使い続けやすくなります。
最初の対象は、処理件数が多く、原本で正誤を確認できる書類から選びます。 見積依頼でも作業標準書でも、必要な情報と承認する人が決まれば試作へ進めます。明日の業務で探す時間や聞き直しが多い資料を一つ挙げ、入力から確認までの流れを書き出してみてください。
よくある質問
Q. 小さな工場でも生成AIを導入できますか?
A. 一つの文書業務を対象にして試すことは可能です。
最初は架空資料で出力を確認し、既存のExcelや承認手順を活かす方法を検討します。
設備全体の更新を前提にする必要はありません。
Q. 無料の生成AIで試せますか?
A. サービスの利用範囲内で、架空の依頼文や報告文を整理する試行はできます。実際の図面や個人情報は、無料か有料かにかかわらず、契約と設定を確認するまで入力しません。継続運用では管理機能や連携費用も含めて選びます。
Q. 紙の図面や手書き日報でも使えますか?
A. 文字を読み取れる画像なら整理に使える可能性がありますが、画質や文字の状態に左右されます。図面の寸法、公差、小数点、記号は特に原本との照合が必要です。読めない箇所を推測せず確認待ちにする仕組みを設けます。
Q. 作業標準書を全部読み込ませれば正しく答えますか?
A. 資料を入れるだけでは、現行版や対象設備を正しく選ぶ保証はありません。文書の適用日、版、承認状態、閲覧権限を管理し、回答に根拠を表示します。記載が見つからない場合は担当者へ確認する流れにします。
Q. 不良品の判定や設備の操作も任せられますか?
A. 本記事の文書支援と同じ仕組み・検証で任せることはできません。検査や制御は、対象製品や設備に応じた専用の設計と検証が必要です。最初の導入では、結果の整理や報告の下書きまでを対象にします。
Q. 6件の試験で生成AIの精度が分かりますか?
A. 分かりません。本記事の6件は、不足や矛盾を勝手に補わず止められるかを確かめた小規模な試験です。実際に導入する際は、自社の帳票と例外を含むテストを追加し、項目ごとの誤りと確認負担を測ります。
Q. 効果は何を測ればよいですか?
A. 資料の準備、AIの処理、原本との照合、修正を含む合計時間を測ります。確認漏れや手戻りも記録し、通常例と例外を分けて比較します。生成が速くても確認負担が増えるなら、そのまま展開せず対象や出力形式を見直します。
まるっとAI編集部
架空の見積依頼6件を使い、不足や矛盾を勝手に補わず止められるかを確認しました。入力、出力、検証用プログラムも公開しています。