顧客から「改訂版の仕様書です」とPDFが届いたとき、前版との差を誰がどこまで確認していますか。製造業で仕様書差分のAI照合を導入する目的は、単に変更箇所を色付けすることではありません。見積前に価格・納期・検査条件へ影響する要求を見落とさず、生産前に適用版を確定し、承認した根拠を後から示せるようにすることです。本稿では顧客・仕入先のPDFを対象に、要求抽出、表・図の比較、人の判定、RFPからFAT・SATまでの評価方法を順に整理します。
仕様書改訂で起こる「差分が見えたのに間違える」問題
仕様書の更新は一見するとファイル比較の問題です。しかし現場で困るのは、変更された文字列を見つけた後です。顧客が材質の指定を変えたなら購買条件と原価が変わる可能性があります。検査頻度の注記が変わったなら検査工数と納入書類が変わります。梱包図の寸法が変わったなら治具や輸送容器の再確認が必要かもしれません。同じページの変更でも、見積担当、品質保証、設計、生産技術、調達で確認すべき内容が違います。
PDFにはテキストを選択できるもの、画像として保存されたスキャン、別紙の表、図中の細かな注記、英語とタイ語が混ざった版があります。単純な文字列比較では、改ページや段落の移動を大量の差分と誤認しやすい一方、図の吹き出しや表の結合セルの意味を取り逃がすことがあります。顧客が版番号を変えずに再送したファイル、メール本文で適用範囲を補足したファイル、仕入先が独自の型番に置換したファイルも実務上の確認対象です。ファイル名だけを正本とみなす運用は危険です。
ここで扱うのは、承認済み設計変更をECR・ECO・ECNやBOMに展開する仕組みではありません。また大量の図面から類似図面を検索する仕組みでもありません。焦点は、その前段にある「今回受領した顧客または仕入先の仕様PDFは、前回承認した版から何を変えたか」「この変更を見積・製造へ渡してよいか」という判断です。設計変更管理や図面検索と接続する場合も、受領文書の比較・適用判断・署名を独立したゲートとして設計します。
AI照合の出力は「差分一覧」ではなく要求の判断台帳
比較結果には少なくとも、文書ID、発行元、受領日時、前版・新版の版識別子、対象製品・顧客・工場、要求ID、原文の引用位置、変更前後、差分種別、影響候補、担当者、判定、判定理由、承認者、承認日時を持たせます。ページ番号だけでは改ページ時に追跡しづらいため、原本ファイルのハッシュ、ページ、表番号・セル位置または図の領域を組み合わせます。PDFへ戻れるリンクも残します。
変更種別は「追加」「削除」「数値・単位の変更」「許容差の変更」「適用範囲の変更」「図注の変更」「表の行・列の移動」「表記だけの変更」「判定保留」などに分けます。AIが初期分類しても、その分類を確定値として扱いません。例えば「10 ± 0.1 mm」から「10 ± 0.05 mm」への変更は文字数が少なくても加工・測定方法に影響し得ます。一方、見出しのフォント変更は通常は要求変更ではありません。リスクの大小は差分の文字量と一致しません。
判定台帳では「要求として成立しているか」「どの製品・ロット・契約に適用するか」「現行工程で満たせるか」「見積条件へ反映するか」「顧客へ照会するか」を分けて記録します。『AIが重要と判定した』だけでは後日説明できません。AI出力は確認を速くする候補であり、引き受ける要求や適用日を決める責任は権限を持つ人に置きます。
導入前に正本・版・適用範囲を決める
最初の作業はモデル選定ではなく、比較する二つの正しい文書を決めることです。受領箱には同名のPDF、メール添付の再送、契約別の別紙、顧客ポータルから取得した版が混在します。比較対象の旧版は「直前に受領したファイル」とは限りません。見積時点で承認した版、量産の基準版、特定顧客案件にだけ適用する版を区別します。仕入先仕様を扱うなら顧客要求と仕入先提案のどちらを上位に置くかも明確にします。
正本管理には、文書番号、改訂記号、発行日、受領日、発行元、適用品番、工場、契約・注文番号、言語、親文書と別紙の関係を最低限登録します。ファイルの暗号学的ハッシュを記録すれば、同じ版名で中身が違う再送を検知できます。ただしハッシュの違いは要求の違いと同義ではありません。PDFの再生成だけでもハッシュは変わるので、差分照合で意味上の変更を確認します。
適用範囲は「全品番に即時適用」の一択ではありません。新規見積から、新規受注から、特定ロットから、顧客承認後から、在庫消化後から、といった条件を持ちます。AIには適用候補の抽出を任せ、人が契約・在庫・工程と照合して確定します。適用日やロットが本文に書かれていない場合は空欄を保持し、推測で埋めないルールが必要です。ここが曖昧なまま差分だけ配布すると、営業と現場で別の版を参照します。
PDFから要求を抽出する：OCRだけでは足りない
デジタルPDFなら埋め込みテキストの抽出を先に試し、スキャンはOCRを使います。ただし文字の認識と、要求としての理解は別工程です。表の行見出しと数値、脚注、図の注記、章立てを再構成しないと、数値がどの条件に属するかを誤ります。Google CloudのDocument AI Layout ParserはPDFの見出し、表、図などの構造を扱うことを公式資料で説明しています。MicrosoftのDocument Intelligenceもページ、表、図、セクションなどを出力する仕様を公開しています。Amazon Textractも表のセルや結合セルを抽出できます。これらは文書の構造を取り出す機能の根拠であって、個々の製造要求が自動的に正しく判定される保証ではありません。
抽出パイプラインは、①原本保管、②ページと領域の分割、③テキスト・表・図の抽出、④要求候補の特定、⑤旧版・新版の対応付け、⑥差分候補と根拠表示、⑦人の承認、の順に分けます。段階ごとに入力と出力を保存すれば、OCRの誤読か、表の対応付けミスか、要求解釈の誤りかを切り分けられます。最終結果だけを保存する「黒箱」では修正と再評価が難しくなります。
要求候補には「shall」「must」「要求する」「不得」「ต้อง」などの義務表現だけでなく、表の列見出しに隠れた検査条件、図中の寸法、備考欄の例外を含めます。一方、説明文や参考値を契約要求へ格上げしないことも重要です。原文の文脈と出典位置を必ず並べ、AIが作った言い換えを原文として保存しない運用にします。読めないスキャンや低信頼の領域は、推定結果を断定表示せず、人の再読または鮮明な原本の再入手へ回します。
表・図・単位の差分は個別にテストする
文章の比較が良好でも、仕様書では表と図が高リスクです。表のセルは行・列見出し、結合セル、脚注、単位、適用条件を一緒に読まなければ意味が定まりません。例えば表内の「0.2」が変わらなくても、列見出しが「最大」から「標準」へ変われば要求の意味は変わります。複数ページにまたがる表や回転した表も、抽出器の対応を実データで確認します。Googleの公式資料にもPDFの複数ページ表が分割される可能性が記載されています。ベンダー名だけで性能を決めず、自社の原本で試験する理由です。
図は線や形の差だけでなく、引出線が指す対象、図注の参照先、寸法と公差、改訂記号、断面と正面の対応を確認します。画像差分はPDFの描画位置が少し動いただけでも反応します。逆に寸法値だけ差し替えた小さな変更は見落とす可能性があります。図を自動で完全解釈できる前提を置かず、「図のこの領域が変わった」「注記候補が変わった」と示し、設計・品質担当が原図で確認する設計が現実的です。
単位は正規化して比較しても、原文も残します。例えば mm と inch、MPa と N/mm²、温度の °C と °F は変換の前提や丸めの扱いが関わります。数値の大小だけでなく、上限・下限・目標・参考の違いを見る必要があります。小数点記号、桁区切り、全角・半角、タイ語・英語の併記がある場合、パーサーの取り違えを検証項目にします。数値の誤読はAIの流暢な要約で隠れやすいため、差分画面では必ず原文の数値を並べます。
どこから人が判定するか：承認ゲートを設計する
AIが示す全差分を同じ重みで処理すると、重要な変更が大量の表記差分に埋もれます。そこで、製品適合、安全、法規・顧客固有要求、工程能力、検査方法、原価、納期、梱包・物流への影響候補を分類します。優先度の高いものは担当部署へ割り当て、低リスク候補も一定の標本を人が再確認します。重大差分の見逃しを減らすため、AIが「差分なし」とした文書もサンプル監査の対象に入れます。
承認には役割分担が必要です。営業は見積条件と顧客回答、設計は仕様解釈、品質保証は検査・証跡、生産技術は工程能力、調達は仕入先条件を確認します。誰が最終適用判定を行うかを案件ごとに決め、未判定のまま見積や生産指示へ送らないゲートを設けます。差戻し理由と顧客照会の回答も同じ要求IDへ紐付けます。電子署名の形式や保存期間は契約・社内規程・適用法令に従って個別に決めます。
NISTのAI Risk Management FrameworkはAIリスク管理を組織の運用・評価へ組み込むための任意の枠組みです。これをそのまま認証や法的適合の根拠とはしませんが、役割、測定、監視、是正を設計する参考になります。製造仕様の照合では「AIが判断した変更」と「人が受け入れた要求」を区別し、誰が何を根拠に覆したかを記録することが特に重要です。生成AIの文章がもっともらしくても、出典がない要約は承認材料にしません。
見積前と生産前で判定を分ける
見積前のレビューでは、要求が価格、リードタイム、金型・治具、検査設備、外注工程、試験費用へ影響するかを確認します。この段階では「対応可能」と「価格・納期確定」を混同しません。未解決の要求は前提条件または質問票に明記し、見積の版と紐付けます。仕様書を読み込んだAIが「影響なし」とまとめても、現場条件を知らないままの判定なら営業が採用してはいけません。
生産前のレビューでは、承認された版が作業指示、検査基準、購買仕様、設備設定、出荷書類へ渡ったかを確認します。見積後に改訂が入った場合は、差分の判定だけでなく見積条件を再確認します。顧客仕様と仕入先仕様の双方に変更がある場合、顧客要求への適合を別の照合軸として持ちます。仕入先が「同等」と説明した材料でも、顧客指定の材質、試験法、証明書形式を満たすかは別問題です。
現場に配布するのは長いAI要約より、適用版、対象品番、変更された作業・検査条件、開始ロット、承認者、問い合わせ先を示す短い確定通知がよいでしょう。保留項目は確定項目と混ぜず、現場が推測して作業しないようにします。生産開始の許可は、未解決要求を誰が受け入れたかまで明らかになってから与えます。
監査できる根拠を残す：一つの要求から原本へ戻る
照合システムの価値は、変更候補を見つける速度だけでは測れません。数か月後に「なぜこの検査を追加したか」「このロットに新仕様が適用されたか」と聞かれたとき、原本の該当箇所、AI抽出結果、人の判定、承認、下流文書まで一続きで追えることが重要です。要求IDを軸に、顧客PDFと仕入先PDF、見積、作業指示、検査成績書を必要な範囲で結びます。
最低限の証跡は、原本ファイルとハッシュ、比較ペア、抽出器・モデルの版と実行時刻、検出された差分、原文の位置、担当者の判定、承認、反映先、再確認結果です。モデルを更新したら過去の判定が自動的に書き換わらないよう、実行履歴を固定します。誤判定を見つけた場合は旧判定を消すのでなく、訂正者・理由・日時を残して再承認します。機密文書の保管場所、アクセス権、学習利用の設定、保持期間は調達前に確認します。
ISOが2026年版のISO 9001を公表しています。ISOの公開説明は、顧客期待への対応、一貫した提供、リスクと機会、継続的改善を重視しています。ただし規格の一般説明だけで、特定のAI照合製品が適合するとは言えません。自社の品質マネジメントシステムにおける文書管理、要求の確認、変更の承認と記録を、監査員や顧客と整合させる必要があります。ツールは証跡を作りやすくしますが、責任の所在を代替しません。
小さく始めるPoC：正解集と失敗条件を先に作る
PoCは「どのAIが賢いか」ではなく、対象文書と判定業務を限定して始めます。例えば一つの顧客、一つの製品群、過去の承認済み改訂ペアを対象にします。スキャン、表、図、別紙、言語混在、版番号の誤りなど、実際に苦労した例を含めます。問題のないPDFだけを試すと、見積前に最も困る例外を評価できません。
正解集は、原本二版、要求ID、変更箇所、影響の有無、担当部署、適用条件、人が確定した判断と理由で構成します。正解が一意でないものは「要照会」と明示します。AIが曖昧な要求を勝手に解決した場合は、流暢な回答でも失敗と数えます。特に数値・単位・公差・否定語・例外・図注の変更は、必須検出項目として扱います。
評価指標は文書単位の処理時間だけでなく、重大要求の見逃し、不要な警報、根拠位置の正しさ、表セルの対応付け、図の人手確認率、承認までの滞留を分けます。数値目標は自社の基準業務を測ってから定めます。ここで汎用的な「何％削減」を持ち込むと、入力品質と人の確認範囲の違いを隠します。PoC前後で同じ文書セットと同じ判定基準を使い、結果を再現できるようにします。
RFPに書くべき要求、FAT・SATで確かめること
RFPには「AIで仕様書を比較する」とだけ書いても、見積できる範囲が揃いません。入力PDFの種類、ページ数、言語、スキャン品質、旧版選択、表・図・別紙の扱い、出力台帳、承認権限、システム連携、機密要件、再処理、障害時の手順を記載します。ベンダーには対応可能範囲だけでなく、読めない条件と人へ返す条件を提示してもらいます。モデル変更時の再検証と運用費も見積対象です。
FAT（工場出荷前受入試験）では、合意したサンプルPDFと正解集を用い、抽出、差分、根拠表示、権限、履歴を確認します。機能が画面にあるだけでは合格にせず、意図的に難しい改訂を入れます。例えば結合セル内の公差変更、図注の削除、版番号は同じで内容が異なる再送、適用ロットの追記、読み取れないスキャンです。期待結果は「正しく検出」「人に保留として渡す」「受入を止める」などを事前に定義します。
SAT（現地受入試験）では実際の顧客受領経路、権限、ネットワーク、文書保管、見積・生産指示への引き渡しを確認します。タイ工場で複数言語を使うなら、翻訳表示は便利でも原文を正本として残し、承認画面で両方見せます。現地の品質・営業・生産技術担当が同じ案件で判断できるか、保留が引き継がれるかを試します。合格基準と残課題を記録し、未解決の重大項目があるまま本番の自動通過を許可しません。
費用対効果は「処理件数」より手戻りの減少で見る
導入費にはOCR・文書解析・AI利用料だけでなく、正本管理、権限設計、既存システム接続、正解集作成、担当者教育、運用監視、モデル更新時の再評価が入ります。PDFのページ数や表・図の割合、クラウドと社内環境の構成、言語数によって費用は変わります。初期段階で単価を一つに決め打ちせず、対象文書を用いた見積を求めます。
効果は入力時間の短縮だけでなく、顧客への質問が早く出ること、見積後の条件変更を捕まえること、誤った版による再製作や検査やり直しを防ぐこと、承認の滞留を可視化することに現れます。これらをすべて金額換算する必要はありません。少なくとも基準期間の受領件数、改訂件数、確認時間、差戻し、見積再提出、現場への誤版配布、顧客指摘を記録して比較します。案件規模が小さくても重大な要求を一つ見逃すリスクが高い場合、件数だけで導入を退けるべきではありません。
導入順は、まず受領と正本登録、次に文章・表の差分候補、次に承認台帳、最後に見積・生産・検査への連携が分かりやすいでしょう。図の解釈や多言語翻訳を初日から完全自動化する計画は避けます。人が確認する条件をはっきりさせた上で対象を広げます。既存の関連テーマとして、承認後の変更展開は設計変更管理とAI、仕入先の提出証明書の照合は材料証明書のAI検証で扱っています。本稿の対象である仕様PDFの改訂判断と、これらの下流業務の境界を合わせておくと、重複投資を避けやすくなります。
実務で使う照合台帳の記入例
架空の例として、顧客の包装仕様 Rev.B と Rev.C を比べる場面を考えます。旧版の表には「一箱当たり20個」、新版には「一箱当たり16個」とあり、図のラベル位置も変わりました。照合台帳には、変更前後の原文、表の行・列、図の領域、対象品番、変更理由の有無を別々に記録します。AIが「数量変更」と出しても、梱包単位なのか出荷単位なのかを人が確認します。営業は見積の梱包費と輸送条件、物流は箱サイズとパレット積み、生産技術は梱包作業、品質は表示・員数検査を確認します。顧客が旧版で発注済みのロットに新版を適用するかは、仕様書だけからは決められません。未記載なら「適用未確定」として顧客照会を起票します。
別の架空例では、仕入先の材料仕様書の表にある試験温度だけが変わっています。AIが温度差を検出した後、品質担当は規格名、試験方法、顧客が求める材料特性、既存の受入検査を確認します。仕入先の説明に「同等品」と書かれていても、顧客の承認を要する変更かどうかは契約と顧客要求で判断します。ここで使う台帳は、材料証明書を受領して値を照合する工程とつながりますが、仕様書の改訂が許容されるかを決める工程とは分けます。
台帳を使うときは、AIが一件の文章を複数要求に分割する場合と、複数の段落を一つの要求にまとめる場合の両方を検討します。番号を機械的に振っただけでは、後日同じ要求を追跡できません。文書側の節番号と社内の永続的な要求IDを併記し、改訂後も対応関係を維持します。削除された要求も行ごと消さず、旧版で有効だった時期と新版での扱いを記録します。これにより「最新版には書かれていないが過去のロットには適用された」条件を説明できます。
運用を止めないための例外処理
AIがPDFを読めないときの手順を決めておくと、現場はシステム障害を理由に判断を飛ばさずに済みます。暗号化PDF、破損ファイル、画質の低いスキャン、手書きの追記、複雑な多段組、画像内の小さな文字は、あらかじめ「自動判定対象外」または「人の再読必須」に分類します。再送依頼、手動比較、暫定保留のいずれに進むか、顧客への回答期限と一緒に決めます。後からOCRの精度が改善しても、当時の人の判断記録を上書きしないことが重要です。
版の取り違えも例外として扱います。旧版より発行日が早いPDF、版番号が重複するPDF、メールに「前の添付を無視してください」とあるPDFは、システムが自動的に比較ペアを確定しない条件にします。PDFのメタデータやファイル名は参考情報であり、契約上の有効版を単独で証明しません。担当者が受領経路と顧客確認を見て正本を指定し、その指定履歴を保存します。
ベンダー運用も例外設計に含めます。解析サービスの障害、モデル版の変更、API応答形式の変更が起きたとき、未処理の文書をどう並べ、復旧後にどう再処理し、二重承認を防ぐかをRFPに書きます。外部サービスへ機密仕様を送る場合は、データ所在地や保持、学習への利用、アクセスログ、削除手順を契約上の要件と照合します。利用できる機能や制約はサービスの版で変わるため、導入時と運用中に公式文書を確認し、試験済みの構成を記録します。
部署別の画面と通知は同じ根拠を共有する
営業が見たいのは見積への影響と顧客へ確認すべき質問、品質保証が見たいのは検査条件と記録の変更、生産技術が見たいのは工程・治具・設備設定への影響です。画面を部署別に変える場合でも、元の要求ID、原本位置、変更前後、適用判定を共通にします。部署ごとにAI要約を別々に作り、それぞれが違う原文を参照している状態は避けます。通知に「重要変更あり」とだけ書かず、誰がいつまでに何を確認し、次のゲートが何かを示します。
判定の待ち時間が長い場合は、AIの速度を上げる前に滞留の原因を見ます。担当部署が不明なのか、顧客回答を待っているのか、別紙が届いていないのか、工程能力試験が必要なのかで対策は変わります。台帳のステータスを「抽出済」「レビュー中」「顧客照会中」「承認済」「適用保留」などに分けると、見積や生産の担当者が未解決の条件を把握できます。承認済みになった後も、次の改訂が届けば再び比較と判定を通す設計にします。
仕様書の翻訳版を使うときの確認点
多言語の現場では、顧客の英語仕様をタイ語の作業指示へ展開することがあります。このとき翻訳文同士だけを比較すると、原文の要求が変わったのか、翻訳の言い回しだけが変わったのか分からなくなります。差分の一次判定は契約上の正本言語で行い、翻訳は理解の補助として扱います。タイ語または日本語のレビュー画面には、必ず原文の該当箇所と版を並べて表示します。例えば「shall」と「should」、許容を示す語と義務を示す語、否定の有無を訳し間違えると、工程や検査の判断が逆転します。翻訳に迷いが残る要求は、人が原文を確認し、必要なら顧客へ質問します。
変更通知も一言語だけで終わらせません。承認後に現場へ配る要約には、原文の要求ID、正式な適用版、翻訳した作業上の指示、承認者をセットで載せます。翻訳を修正した場合は、元の仕様書改訂と混同しないよう「翻訳修正」として別の履歴に残します。これにより、工場内の説明文を改善しただけなのに顧客仕様が変わったと誤認することを防げます。
稼働後も「検出率」だけで判断しない
運用を始めたら、毎月いくつかの承認済み文書を抜き取り、AIが出した差分と人が最終的に受け入れた要求を比べます。大きなモデル更新だけでなく、顧客のテンプレート変更やスキャナー交換でも抽出の結果は変わります。見逃しがあれば、その文書の入力品質、抽出、版の対応付け、差分分類、承認のどこで失敗したかを記録します。再学習やプロンプト変更だけで解決したと決めず、必要なら正本登録や確認手順を直します。現場から「警報が多すぎる」と声が出た場合も、単に閾値を上げる前に重要差分が埋もれていないかを確認します。
まとめ：AIは変更候補を示し、人が適用を確定する
仕様書差分のAI照合を導入するなら、二つのPDFを選ぶところから承認済みの要求を下流へ渡すところまでを一つの業務として設計します。テキストだけでなく表・図・別紙・単位・適用条件を扱い、各差分を原本へ戻れる形で示すことが要点です。見積前と生産前で判定目的を分け、AIが読めない箇所は保留とします。RFPで対象と例外を明確にし、FATとSATでは自社の難しい実例で検証します。最終的な要求受入と適用版の責任は人が持ちます。
顧客や仕入先の仕様PDFが増え、見積前の確認や版の引き継ぎに負担がある場合は、対象文書と現在の承認フローを整理する段階からTOMAS TECHへご相談ください。まずどの差分を人へ確実に渡すべきか、一緒に検討できます。
よくある質問
AI-OCRを導入すれば仕様書の差分確認は自動化できますか？
AI-OCRは文字とレイアウトを取り出す入口です。旧版との対応付け、要求の意味、適用範囲、見積・工程への影響は別途設計が必要です。自動化の対象は候補抽出と根拠提示から始め、要求の受入は担当者の承認に残すのが安全です。
表や図の変更もAIで検出できますか？
文書解析サービスは表のセルや図の領域を抽出できますが、自社の仕様PDFでどこまで正しく扱えるかは試験が必要です。結合セル、ページをまたぐ表、微細な図注、スキャンの品質を正解集に含め、検出できない場合に保留へ回す設計にしてください。
見積前の仕様書と量産前の仕様書は同じ手順で比較しますか？
比較の基盤は共通化できますが、承認の観点は違います。見積前は価格・納期・実現可能性と未確定条件、生産前は適用ロット・作業指示・検査基準・購買仕様への反映を確認します。それぞれの決裁者と通過条件を定義してください。
RFPで最低限指定すべきことは何ですか？
入力PDFの種類、旧版の選定方法、対象言語、表・図の扱い、出力する要求台帳と原本へのリンク、権限と履歴、読めないときの保留、FAT・SATの合格条件を指定します。実際の改訂ペアを匿名化して提示できると、ベンダー間の比較がしやすくなります。
AIの判定が間違っていた場合、誰が責任を持ちますか？
契約や社内規程によりますが、業務上の要求受入と適用判定の責任者を先に定める必要があります。AI候補、原本根拠、人の修正・承認を区別して履歴を残せば、誤りの原因調査と是正を進めやすくなります。
参考情報・一次資料
- Google Cloud, Process documents with Gemini layout parser — PDFの表・図・見出し等の構造と制約。
- Microsoft Learn, Document layout analysis — 表・図・セクションの抽出仕様。
- Amazon Textract, Tables — セル、結合セル、見出し等の扱い。
- NIST, AI Risk Management Framework — 任意のAIリスク管理枠組み。
- ISO, ISO 9001:2026 — 2026年版品質マネジメント規格の公開説明。
