製造業で「PPAP提出書類のAI照合を導入したい」と考えるとき、最初の課題は書類を自動生成することではない。図面、工程フロー、PFMEA、コントロールプラン、測定結果、顧客指定フォームの版と対象部品をそろえ、提出パッケージに欠落や矛盾がないかを、品質担当者が根拠を見ながら確かめられる状態にすることだ。タイの自動車部品サプライヤーでは、日本語・英語・タイ語のメール、複数の顧客ポータル、紙とPDFとExcelが混在しやすい。本記事はその実務を対象に、AIを「提出前レビューの補助」に限定して設計する方法を示す。PPAPの正式な提出範囲、提出レベル、様式、承認条件は、適用される顧客要求と契約、購入した正式マニュアルで確認する。
PPAP提出書類のAI照合は、何を解決するのか
AIAGはPPAPを、量産工程で製造した部品が設計記録と仕様要求を継続して満たせることを確認するための業界標準プロセスとして説明している。したがって提出パッケージは「PDFを所定のフォルダへ集める作業」だけではない。顧客が求める証拠が、その品番、その図面改訂、その工程、その生産条件と結び付いているかを示す仕事である。ここでAIが手伝えるのは、資料の分類、指定された項目の抽出、資料同士の照合、確認箇所へのリンク付け、例外の整理までだ。工程の妥当性や顧客提出の可否を自律的に決めさせない。
典型的な問題は三種類に分かれる。第一は「あるはずの資料が見当たらない」という欠落。第二は資料はあるが、品番・改訂・日付・工程番号などの識別子が一致しないという矛盾。第三は数字が一致しても、測定方法やサンプル条件、顧客要求の解釈が適切かという専門判断だ。第一と第二の一部は機械で候補を出しやすい。第三は品質技術者、製造技術者、顧客窓口の判断を必要とする。投資判断では、この三つを同じ「照合精度」にまとめない。
たとえば寸法測定結果のPDFに「Rev B」、図面に「Rev C」とある場合、AIは不一致を示し、両ファイルの該当ページを並べられる。しかし「Rev Bの結果をRev Cの変更で再利用できるか」は変更点と顧客要求を知る人が判断する。AIに「同じ品番だから問題なし」と結論させる設計は危険だ。採用すべき出力は、合格宣言ではなく、照合ルール、見つかった値、原本位置、例外理由、担当者への依頼である。
AIAGのPPAP第4版は公式の有償マニュアルであり、顧客別要求も更新される。公開ページを元に独自の「全社共通・必須書類リスト」を作ると、顧客ごとの必要範囲を見落とす。たとえばIATFの公式サイトは、FordのPPAP顧客別要求が2024年に更新されたこと、FordのIATF顧客別要求が2025年にePSWによるPSW提出の要件を更新したことを案内している。Boschの公開サプライヤー品質資料にもコントロールプランをPPA/PPAP文書の一部として扱う記述がある。これらは「顧客別ルールを版管理する」必要性を示す具体例であり、他顧客にもそのまま適用できる共通規則ではない。
提出パッケージを組み立てる前に「対象案件」を固定する
最初に案件IDを作り、顧客、サプライヤー工場、品番、部品名称、図面改訂、対象生産拠点、対象工程、提出理由、提出期限、顧客ポータル、顧客要求の版、社内責任者を登録する。どれかが未確定なら、その欄を空欄のまま見えるようにし、AIが過去案件から推測して埋めない。PPAPの提出要求は顧客や変更の事情に依存するため、案件の境界を曖昧にしたまま書類を読ませると、正しく抽出できても間違った案件の証拠を寄せ集める。
案件IDはファイル名だけに頼らない。保存フォルダ、顧客ポータルからのダウンロード、版管理されたマスタ、計測システムの結果を一つの受付台帳へ登録する。受付台帳には原本ファイルのハッシュ値、取得元、取得日時、文書所有者、ファイル版、言語、機密区分を記録する。ハッシュ値は内容が同じかを判別する助けになるが、内容が正しい証拠にはならない。電子署名や顧客ポータルの承認状態が必要なら、別の検証対象として扱う。
紙の測定票や署名付き記録をスキャンする場合、ファイルを受け取った時点でページ数、向き、切れ、ぼけ、重複ページを確認する。画像が悪いままAI-OCRに投入し、低い信頼度の値を自動補正すると、実際の原本から遠ざかる。スキャン条件と再撮影基準を決め、読み取れない箇所は人へ差し戻す。同じページ内でも品番は読めて寸法値は読めない場合があるので、ファイル単位の合否だけでなくフィールド単位の状態を保存する。
「必要書類一覧」は顧客要求から作り、AIには適用判断を委ねない
必要書類一覧は、社内の固定テンプレートを使い回す前に、顧客指定の提出レベル、ポータル指示、発注条件、図面注記、品質協定、顧客別要求を照合して案件ごとに確定する。顧客から正式な指示がない項目について、公開ブログの表を公式要求として転記しない。案件ごとの一覧には、資料名、提出要否、提出形式、適用する改訂、証拠の作成部署、提出責任者、顧客要求の出典箇所、例外承認者を記録する。要求が曖昧なら「要確認」として顧客窓口に問い合わせる。
AIが担えるのは、この人が承認した一覧に対してアップロード済みファイルを候補分類することだ。たとえばコントロールプランらしいExcelを見つけても、ファイル名だけで充足としない。表紙またはシート内の品番、版、承認状態、工程範囲を確認する。要求に対する候補が複数あるなら最新版らしいものを黙って選ばず、候補を並べて所有者に決めてもらう。「見つからない」「候補はあるが案件が違う」「判読できない」を分けて表示する。
文書の種別も一つのAIモデルの自由回答に依存させない。既知の帳票は固定ルールで検出し、非定型のPDFだけ分類器を補助に使う。誤分類が多い顧客帳票は名称辞書や顧客別マッピングを追加する。分類結果には確信度だけでなく、どの文字列・レイアウト・メタデータを根拠にしたかを残す。確信度が高くても、原本の内容や承認済み版と一致しなければ「充足」としない。
「未提出」の見せ方にも注意が要る。顧客への提出対象ではないが社内保管が必要な証拠、顧客がポータルで直接参照する記録、対象変更では再提出不要と合意した資料があり得る。これを全部「欠落」として赤くすると、品質担当者は警告を信用しなくなる。要否は「提出」「社内保持」「適用外」「顧客確認中」のように、顧客要求と社内ルールに即して案件別に設定する。適用外や免除には理由、承認者、日付、顧客との通信記録を添える。
AI照合の中心は、文書をまたぐ識別子と工程の整合
照合ルールの優先順位は、顧客が指定した識別子から決める。一般的な候補は顧客品番、サプライヤー品番、図面改訂、工程番号、工程名称、設備・治具の識別子、測定特性、単位、規格上下限、測定日、生産ロット、試作・量産の区別だ。ただし、顧客や部品によって必要な結び付けは異なる。どの欄をハードエラーにするか、どの欄を参考警告にするかを品質責任者が設定する。
一致判定は単純な文字列比較から始める。全角半角、ハイフン、空白、日付形式、単位の表記を正規化してから、原文も残して比較する。OCRが「0」と「O」、「1」と「I」を取り違えた可能性があるときは、勝手に補正して一致扱いにしない。「読み取り候補が曖昧」として該当箇所を示す。技術文書では一文字違いが別品番や別改訂を意味することがある。曖昧な一致の範囲は顧客・品番・文書種別ごとに承認して使う。
工程フロー、PFMEA、コントロールプランは、工程番号をキーにして横並びにできる。工程番号が変わった場合は機械的な不一致だが、同じ番号でも工程内容、管理特性、検査方法が異なる場合がある。AIは差分候補を抽出し、原本の行へリンクを張る。工程順序の妥当性、リスク評価の十分性、管理方法の適切性は工程設計者が確認する。以前の記事「製造業のFMEAにAIを導入する設計」で扱うリスク分析の判断と、ここで扱う提出証拠の照合は役割が違う。
測定結果については、図面の特性記号、単位、公差、測定点、測定器・方法、結果表の対象品番を結び付ける。AIが表中の数値を抽出できても、測定条件が妥当か、結果の代表性が十分か、顧客要求に合うかは自動的には分からない。計測値の丸め規則や単位変換はルールを明示し、元の数値を上書きしない。想定外の単位、欠測、手書き訂正、複数行にまたがる注記は人のレビュー対象にする。
顧客別要求と改訂管理をどうシステムへ組み込むか
顧客ごとに異なるルールを、プロンプトの文章に埋め込んだまま運用しない。要求文書の正式名称、発効日、版、取得元、対象工場・顧客、社内解釈、承認者をマスタとして持つ。そこから案件に適用するルール版を確定し、後で更新が出ても過去案件の判定を再現できるようにする。顧客ポータルの表示と社内保管PDFが食い違う場合は、どちらを優先するかを品質責任者が確認する。
FordのPPAP文書更新やePSW関連の公開案内は、顧客別要求が変化する具体例である。Boschの公開資料は、コントロールプランとPPA/PPAP文書との関係を明記している。ただし、これらの記述をタイ国内の全OEMや全サプライヤーへ一般化しない。顧客要求が異なるなら、その顧客の契約・現行指示を優先する。AIのナレッジベースに資料を登録する際は、公開資料か契約内資料かを区別し、利用範囲と保存権限を確認する。
変更が入ったら「何が変わったか」を案件内で追跡する。図面改訂、材料変更、工程順序変更、設備移設、測定方法変更、サブサプライヤー変更のどれかで、どの提出証拠と顧客連絡が必要になるかは一律には決められない。変更の事実を4M変更台帳などから受け取り、影響を受ける文書候補を出すところまでを自動化する。提出要否や再承認の判断は顧客要求と変更管理手順に照らして行う。案件の変更履歴を運用へつなぐ考え方は「4M変更管理システムの設計」も参照できる。
版の取り違えを避けるため、各文書に「作成中」「社内レビュー中」「承認済み」「顧客提出済み」「顧客回答待ち」「顧客承認済み」などの状態を付ける。提出パッケージを凍結した後に原本が差し替われば、差分と再レビューの対象を明示する。単なるファイル名の末尾「final」「final2」は状態の代わりにならない。顧客から戻ったコメントも原本と分け、対応前後のファイルのつながりを残す。
タイ工場の多言語帳票でAI-OCRを使うときの実装点
タイの現場では、図面は英語、工程の説明はタイ語、本社の承認メールは日本語という組み合わせがあり得る。翻訳したテキストで検索しやすくすることは有効だが、照合の正本は原本の文字と数値に置く。寸法値、改訂記号、品番、工程番号、署名欄を翻訳モデルが書き換えてはいけない。原本画像、OCR結果、正規化値、必要なら翻訳文を別レイヤーで保存する。どのレイヤーで不一致が起きたかを表示する。
タイ語の書類は、スキャン品質やフォント、記入方法によって読み取りやすさが変わる。日本語・英語・タイ語を一つの平均精度で評価するのではなく、文書種別、言語、入力経路、重要フィールドごとに検証する。品番や改訂などの重要欄は文字単位の精度より「完全一致で正しく拾えたか」を測る。判読不能なら誤って一致させるより保留にする。OCRのPoCと受入の測り方は、多言語AI-OCRの精度評価で詳しく扱っている。
翻訳を表示する場合、たとえば「control characteristic」「special characteristic」「process change」など、品質用語の対訳を社内辞書で固定する。重要な但し書きや否定表現を省略した翻訳は危険なので、翻訳は補助表示にとどめ、判断者が原文へワンクリックで戻れるようにする。顧客へ送る文書をAI翻訳したまま提出する運用は避け、顧客の指定言語・テンプレートと社内承認手順に従う。
人が承認するワークフローを、AIの前提にする
受付担当は資料の取り込みと原本確認を行い、AIは一覧との対応、識別子の抽出、差分候補の提示を行う。文書所有者は自分の資料の誤記や不足を直し、品質技術者は文書間整合と測定・工程の意味を評価する。品質責任者は提出パッケージの社内承認を行い、顧客の指定チャネルで提出する。顧客承認は顧客だけが行う。この責任分界を画面上に表現し、「AIチェック済み」を「社内承認済み」や「顧客承認済み」と同じ色や語で表示しない。
例外キューには、重要度、原本位置、比較対象、担当者、期限、解決記録を持たせる。AIの指摘が誤検知だった場合、担当者が「却下」とし理由を残せるようにする。逆に人が見つけた未検知の矛盾も登録し、ルールや辞書の改善に使う。NISTのAIリスク管理フレームワークは自主的な枠組みで、AIのガバナンス、測定、管理と人の監督を重視する。ここでは、その考え方を、出力の根拠表示、担当者による上書き記録、停止条件という実務仕様に落とす。
自動化の停止条件を先に決める。対象品番が不明、図面改訂が複数、原本が判読不能、顧客要求の版が未確定、重要測定値の単位が不明、顧客承認状態を読み取れないときは、AIの最終判定を出さず人へ回す。生成AIが文章で「問題ありません」と返すことより、未確定を未確定として残せることの方が重要だ。入力に顧客の機密図面を含むなら、保存場所、外部AIサービスへの送信可否、アクセス権、ログ保持、削除、再学習利用の設定も契約・情報管理ルールに沿って決める。
PoCでは「資料がそろったか」と「矛盾を拾えたか」を別々に測る
PoCには、過去の完了案件だけでなく、欠落、改訂不一致、読めないスキャン、誤った品番、似た帳票、適用外、顧客別例外を含める。顧客・品番・文書種別を分けて評価し、学習やルール作成に使った案件をそのまま最終評価に使わない。品質部門が正解ラベルを付け、誤りの分類をレビューする。機密資料の共有範囲は、PoC開始前に決める。
指標は少なくとも、必要書類の欠落検知率、重要フィールドの完全一致率、文書間矛盾の検知率、誤警告率、人による修正件数、例外処理時間、原本へたどれる割合に分ける。高い「文字認識率」だけでは、提出可能な案件が増えたとは言えない。特に危険なのは、欠落や改訂違いを見逃したのに「問題なし」と表示するケースだ。重要エラーの見逃しを優先して評価し、運用上の許容値は顧客要求と社内品質リスクに合わせて決める。この記事で一律の合格率や工数削減率は提示しない。
導入前後の比較では、案件の難しさをそろえる。簡単な案件だけAIに流し、難しい案件は手作業に残すと、平均処理時間だけが良く見える。案件ごとに文書数、顧客種類、変更の有無、言語、例外数を記録し、同じ条件群でレビュー時間と再提出件数を見る。削減時間を金額換算する際は、ライセンス、設定、顧客別ルール保守、OCRの再処理、人の最終確認、監査ログ保存を含める。AIの導入で「人の承認が不要になる」という前提を費用対効果へ入れない。
受入試験では、正常系だけでなく、古い版を投入した場合、同じ名前の別品番を混ぜた場合、低画質ページ、表の結合セル、数値と単位が別欄、顧客要求の版更新、提出直前のファイル差し替えを試す。各ケースで期待するのは、正しい自動通過だけでなく、正しい保留と人への差し戻しである。結果には原本、抽出値、ルール版、判断履歴を添え、同じ入力と版なら同じ照合結果を再現できるかも確認する。
パイロットで確認したい四つの境界ケース
最初のパイロットでは、実際の品質担当者が迷う境界ケースを意図的に入れる。第一は、顧客品番は一致するが、図面の改訂だけが新しいケースだ。測定報告書の表紙と本文で改訂が違う、図面変更通知はあるが測定点が変わっていない、といった状況を分けて用意する。AIの期待動作は「流用可」と判断することではなく、相違箇所、変更通知、該当特性を一画面で示し、再測定や顧客確認の要否を品質技術者へ回すことだ。
第二は、文書の欠落と適用外が見た目では区別しにくいケース。たとえば特定の試験報告がフォルダに無いとき、単純な検索結果はどちらも「見つからない」となる。しかし顧客がその案件で提出不要と指定していれば、欠落警告は誤りになる。パイロットでは顧客要求の原本箇所と、社内で承認した適用外理由をセットで提示できるかを見る。適用外の根拠が無ければ、AIが勝手に免除へ振り分けず、顧客窓口への確認待ちにする。
第三は、単位や測定条件が文書の欄外に書かれているケース。結果表の数値が図面の規格内に見えても、単位が違う、温度条件が異なる、対象ロットが別という可能性がある。AIが数値だけを抽出して緑にする設計は避ける。数値・単位・条件・対象の四点をそろえて比較し、欄外注記や結合セルが読み取れなければ保留へ送る。人が訂正した後も、元画像と訂正理由を保存する。
第四は、提出直前にファイルが差し替わるケース。品質責任者が確認した後に、工程表だけ新しい版へ更新されれば、過去の「照合済み」という状態をそのまま維持できない。変更ファイルのハッシュと版を検知し、影響する照合ルールだけを再実行し、必要な承認者へ再レビューを依頼する。顧客ポータルへの送信結果は別に記録し、アップロード成功を顧客承認と表示しない。これら四つを通じて、AIが答えを出す能力だけでなく、判断を止める能力も受け入れ条件に入れる。
データ設計では「項目の値」だけでなく、その由来を保存する
照合データの中心には、案件、要求、原本文書、抽出フィールド、照合ルール、例外、承認を別の単位として持つ。たとえば同じ品番が図面と測定表と顧客フォームに三回現れたら、「品番」という一つの値に潰さない。どの原本の何ページ・何セルから取った値かを別々に保存し、比較結果から元の位置へ戻れるようにする。OCRで読んだ値と、人が確認して確定した値も上書きで混ぜない。修正前後と担当者、時刻を残せば、後に顧客から質問があったとき、なぜその値で提出したかを説明できる。
照合ルールは「図面改訂と測定表改訂が一致する」といった人が読める文で定義し、比較対象のフィールド、正規化方法、例外条件、重要度、適用顧客、適用開始日を持たせる。ルールを変更した際に、過去に承認した案件を無断で再評価して承認状態を変えない。必要なら新ルールで再実行した結果を別の版として保存し、元の提出時点の判断と区別する。これは監査のためだけでなく、現場で「昨日は緑だったのに今日は赤い」という混乱を避けるためでもある。
検索のために生成AIのベクトル検索を使う場合も、検索で見つかった文章を顧客の正式要求と即断しない。検索結果には文書名、版、発効日、対象顧客、原本リンクを付け、どの要求文がチェックリストの一項目になったかを承認者が確認する。顧客別資料の取り扱い許可も確認する。公開情報と契約で受け取った非公開情報を同じ検索領域へ無差別に入れると、権限外の人へ資料が見える危険がある。顧客・案件・役割によるアクセス境界を先に決める。
将来のシステム移行も考えて、原本と抽出データを独自画面だけに閉じ込めない。案件ID、文書ID、ルール版、例外ステータス、承認履歴を機械で読める形式で出力できれば、品質管理システムや文書管理システムとの連携を段階的に進められる。ただし顧客ポータルへの自動アップロードは、ポータルの利用条件と顧客の承認手順を確認してから設計する。ファイルを正しい場所へ送れたことと、顧客が内容を承認したことは別のイベントである。
現場の運用で起こりやすい失敗を先に防ぐ
一つ目は、一覧表のすべてが緑なら提出可能と見なすことだ。ルールで見た識別子がそろっても、測定や工程設計の妥当性、顧客の特別要求、承認署名の有効性までは保証できない。画面には「自動照合済みの範囲」と「人の未確認項目」を別々に表示する。提出可否の判定には品質責任者の承認ステップを必ず通す。
二つ目は、AIの指摘が多過ぎて担当者が一括で無視することだ。似た表記の軽微な差、OCRの曖昧さ、重要な改訂違いを同じ一覧に並べると、緊急度が伝わらない。原本の信頼性、顧客要求への影響、見逃し時の重大性に応じてキューを分け、誤検知を定期的に集計する。何度も却下された指摘はルールを見直し、品質担当者が重要な差分に集中できるようにする。
三つ目は、最初のPoCが終わった後にルールの所有者がいなくなることだ。顧客要求は変わり、帳票も更新される。誰が新しい版を確認し、辞書を変え、テスト案件で再評価し、本番へ反映するかを運用設計に書く。更新の承認者がいないなら、自動判定範囲を広げない。定期的に、見逃しと誤警告、顧客からの差し戻し理由、現場の手作業が増えていないかを確認する。
四つ目は、顧客別の承認や提出状態を社内のファイル更新だけで推定することだ。社内で最終版が完成しても、顧客が追加資料を求めたり、条件付き承認にしたりする場合がある。顧客ポータルや正式連絡にある状態を、社内の「提出済み」「回答待ち」「承認済み」と分けて記録する。AIが顧客の正式回答を代弁しないよう、画面上の言葉を明確にする。
RFPでベンダーに渡す要件と、導入順序
RFPには「PPAPをAIで自動化したい」だけを書かない。対象顧客、月間案件数の目安、文書の種類と形式、対象言語、社内システムと顧客ポータルの接続可否、原本保存先、品質部門の承認経路、機密条件、必要な監査証跡を記載する。サンプル文書は共有許諾を得た匿名化版を用意する。ベンダーには、学習に使わない文書でのデモと、誤判定時の画面・ログを見せてもらう。
機能要件は、①原本取り込みと版固定、②顧客別チェックリスト、③フィールド抽出、④ルール照合、⑤原本ページへの根拠リンク、⑥例外キュー、⑦承認履歴、⑧提出パッケージのエクスポート、⑨権限と監査ログ、⑩モデルやルール更新時の再評価に分ける。生成AIを使う範囲も明記し、帳票分類や説明文の下書きには使えても、必須性・合否・承認を無断で確定させない。外部サービスの構成、データの保存場所、アクセス制御と削除条件は個別契約で確認する。
最初の導入単位は、顧客一社・部品群一つ・資料の一部に絞る。過去案件の読取から始め、現行案件では「影の照合」として人の通常レビューと並行させる。検知した差分のうち有効だったもの、見逃したもの、作業者が不要と判断したものを記録し、チェックリストと正規化ルールを調整する。受入条件を満たしたら、同じ顧客の別部品群へ広げる。顧客別要求の違う案件を初日から一つの巨大なプロンプトで処理すると、どの変更が精度に効いたのか分からなくなる。
よくある質問：PPAP提出書類のAI照合導入
AIだけでPPAPを承認できますか？
できない。AIが支援できるのは、文書の分類、抽出、規則に基づく照合、例外の提示である。社内の提出承認は権限を持つ担当者が行い、顧客承認は顧客のプロセスで得る。画面も権限もこの違いを保つ。
必要書類は全顧客で同じですか？
同じと決めつけない。AIAGのPPAP公式資料を基礎にしつつ、対象顧客の現行要求、契約、提出レベル、ポータルの指示を確認する。顧客別の版と出典を案件に紐付ける。
AI-OCRの精度が高ければ自動提出できますか？
文字が読めることと、資料が案件に適合し、文書同士が整合し、顧客要求を満たすことは別である。読取精度、重要欄の完全一致、欠落検知、矛盾検知、誤警告、原本追跡を別々に評価する。
図面が改訂されたら、既存の測定結果を使えますか？
一律には判断できない。AIは改訂差と関連する結果を示せるが、変更内容、測定対象、顧客要求、承認手順を品質技術者が評価する。判断と承認を記録する。
タイ工場の日本語・英語・タイ語書類に対応できますか？
対応の可否は自社の帳票で検証する。原文、OCR値、翻訳文を分け、品番、数値、単位、改訂記号は原文に戻って確認できるようにする。言語別・文書別に受入基準を設ける。
導入費用は何で決まりますか？
案件量だけでなく、顧客別ルール数、文書様式、スキャン品質、言語、既存システム連携、権限設計、監査ログ、保守範囲で変わる。ベンダー比較ではライセンス価格だけでなく、設定と例外処理の費用も同じ条件で見積もる。
まとめ：AIの出力を「提出判断の根拠」に変える
PPAP提出書類のAI照合は、資料の束から「どの顧客要求に、どの版の、どの証拠が対応するか」を追えるようにする取り組みである。案件境界と要求版を人が固定し、AIは欠落と矛盾の候補を根拠付きで示し、品質担当者が判断する。最初から完全自動化を狙うより、見逃してはいけない改訂違いと欠落を明確にし、原本へ戻れるレビュー画面を作ることが実務に効く。
顧客別の例外と人の判断も、後から追跡できる記録として残す。
タイ工場の既存帳票で、どこまで照合を自動化できるかを検討中なら、TOMAS TECHへご相談ください。対象顧客と文書サンプルがまだ少ない段階でも、PoCの範囲と人の承認を残す設計から整理できます。
参考情報
- AIAG: Production Part Approval Process (PPAP-4) — PPAPの公式概要。詳細要件は正規マニュアルと顧客要求で確認。
- IATF: Ford PPAP customer-specific document, January 2025 — 顧客別要求の現行公開文書を確認する例。
- IATF: Ford PPAP document update, October 2024 — 旧版更新履歴の例。
- IATF: Ford customer-specific requirements update, 13 June 2025 — ePSW関連の更新案内。
- Bosch: Supplier Quality Requirements, Edition 3, February 2025 — コントロールプランとPPA/PPAP文書の関係の例。
- AIAG: APQP and Control Plan manuals — APQP第3版と独立したControl Plan第1版の公開概要。
- NIST: AI Risk Management Framework — 自主的なAIリスク管理枠組み。
- NIST AI RMF Playbook: Measure — 人による監督や例外の記録に関する提案。
