サプライヤ提出物（PPAP）をそろえるポータル設計｜PSW・FMEA・CPを“版ズレ”させない

PPAP提出物は、単にファイルを集めれば完了、というものではありません。 PSW、DFMEA、PFMEA、Control Plan、測定結果、材料証明、MSAなどが別々のメールや共有フォルダに残ると、どの版が正しいのか、どの図番Revに対する提出物なのかが分かりにくくなります。

現場で起きやすいのは、PSWは届いているのにControl Planが古い、測定結果はあるのに対象寸法が分からない、修正依頼がメールに埋もれて再提出の期限が曖昧になる、といった問題です。 PPAPポータルの役割は、提出物を1か所に置くことではなく、提出物一式が、同じ対象・同じRev・同じ承認条件で確認できる状態を作ることです。

1. PPAPは「ファイル単位」ではなく「提出パッケージ単位」で管理する

PPAP管理が分かりにくくなる原因の多くは、ファイル単体を追いかけることにあります。 ポータルでは、まず1件のPPAPを「提出パッケージ」として扱います。 たとえば PPAP-2026-014 のような単位を作り、その中に必要な提出物、対象Rev、期限、レビュー結果を紐づけます。

• 対象：品番、型式、図番、Rev、対象工程、対象部品
• 提出レベル：Level 1〜5など、運用ルールに応じた提出範囲
• 期限：提出期限、レビュー期限、承認期限
• 提出先：品質保証、購買、設計、必要に応じて客先
• 状態：未提出、レビュー中、修正依頼中、承認済みなど

この単位を固定すると、「何のための提出物か」「今どこまで確認済みか」「次に誰が対応するか」が見やすくなります。

2. 必要な提出物をチェックリスト化する

PPAPでよく起きるのが、「今回は何を提出してもらうべきか」が曖昧になることです。 提出レベル、部品カテゴリ、顧客要求、変更内容によって必要書類が変わるため、毎回メールで確認していると漏れが出やすくなります。

ポータル側では、提出物を 必須・条件付き・不要 に分け、チェックリストとして表示します。

3. 図番Revを提出パッケージに固定する

PPAPで特に避けたいのは、古いRevの提出物が混ざることです。 PSWは最新でも、測定結果が旧Rev、Control Planだけ別版、といった状態になると、レビューに時間がかかります。

対策として、提出パッケージ作成時に 対象図番Revを必須項目 にします。 承認後は、対象Revと添付ファイルの差し替えを制限し、変更が必要な場合は別版のパッケージとして扱います。

• 提出パッケージ作成時に、品番・図番・Revを固定する。
• 提出物ごとに、対象Revとファイル版を表示する。
• 承認後の添付差し替えは不可にし、必要なら新しいパッケージを作る。
• Rev変更が発生した場合は、ECR/ECOに紐づける。

この考え方は、DVP&Rの「要求・試験・判定」の紐づけにも近いものです。 試験結果や評価レポートまで含める場合は、要求→試験→判定の紐づけ と合わせて設計すると、後から確認しやすくなります。

4. 修正依頼は「提出物・指摘・期限」をセットで残す

PPAPレビューでは、修正依頼が何度も発生します。 メールでやり取りすると、どの版に対する指摘なのか、誰が対応するのか、いつ再提出されるのかが分かりにくくなります。

ポータルでは、修正依頼を提出パッケージに紐づけ、さらに該当する提出物にぶら下げます。

• 対象提出物：PSW、Control Plan、測定結果など
• 指摘区分：要確認、修正要、対応済み
• 指摘内容：何を直すべきかを短く明示
• 担当：サプライヤ側担当、社内レビュー担当
• 期限：再提出日、レビュー完了予定日

5. サプライヤ側の入力負担を増やしすぎない

ポータルを作っても、入力が面倒だとサプライヤ側は使い続けられません。 最初から細かい項目を大量に入力させるより、選択式と自動表示を増やし、手入力を減らす設計が現実的です。

• 品番・図番は検索して選択する。
• 提出レベルはプルダウンで選ぶ。
• 必要な提出物はチェックリストで表示する。
• 提出期限・レビュー期限はポータル側で表示する。
• ファイル名だけに頼らず、提出物カテゴリを選ばせる。

特に品番や図番は、手入力にすると表記ゆれが発生します。 品番マスタや図番マスタを使い、検索して選ぶ画面にしておくと、後続の検索・集計・外部連携でも扱いやすくなります。

6. 社内レビュー側は「不足・期限・承認待ち」が見えることが重要

社内側の画面では、すべてのファイルを細かく見る前に、どのパッケージが遅れているか、どれが不足しているかを把握できる必要があります。

• 提出期限を過ぎているパッケージ
• 必須提出物が不足しているパッケージ
• 修正依頼中で再提出待ちのパッケージ
• 社内レビュー担当の確認待ちパッケージ
• 承認期限が近いパッケージ

この一覧があると、品質保証や購買が個別メールを探さなくても、優先して確認すべきPPAPを判断できます。 ダッシュボードの考え方は、品質会議・経営報告用のクレーム統計ダッシュボード設計 にも近いです。

7. 承認後は「参照できるが勝手に差し替えられない」状態にする

PPAPは承認後の扱いも重要です。 承認済みパッケージのファイルを後から自由に差し替えられると、承認時点の証跡が失われます。

承認後は、提出物一式を参照専用にし、変更が必要な場合は新しい版として登録します。 誰がいつ承認したか、どのファイル版を承認したか、修正依頼がどのように解消されたかを残しておくことで、後日の監査や顧客確認にも対応しやすくなります。

• 承認済みパッケージはロックする。
• 承認後の変更は、新しい版として登録する。
• 承認者、承認日、承認対象ファイルを記録する。
• 修正依頼と対応履歴を残す。

最後に

PPAP管理で大切なのは、提出物の数を増やすことではなく、提出物一式が同じ対象Revで確認でき、レビュー・修正依頼・承認までの流れが分かることです。

提出物をパッケージ単位で扱い、図番Revを固定し、PSW・FMEA・Control Plan・測定結果をチェックリスト化する。 さらに、修正依頼を提出物ごとに残し、期限と担当を明確にすると、メールや共有フォルダだけでは起きやすい版ズレや提出漏れを減らせます。

株式会社インテンスで設計する場合も、最初から大規模なサプライヤポータルを作るのではなく、まずは「提出パッケージ」「対象Rev固定」「提出物チェックリスト」「修正依頼」の4点から始めることが多くあります。 そこから、期限管理、承認履歴、品質ダッシュボード、ECR/ECO連携へ段階的に広げると、現場側にもサプライヤ側にも使いやすい仕組みにしやすくなります。

製造業全体の業務イメージとしては、製造業向けシステム開発例 の中でも、品質・認証・サプライヤ管理に近いテーマです。