「前にも同じような不具合で特採を通したはずなのに、今回は誰がどんな条件で”是”にしたのかが分からない」——製造業の品質・設計・生産管理の現場で、こうした声は珍しくありません。特採（特別採用）そのものは日々きちんと判断されています。問題は、「なぜその不適合を出荷してよいと判断できたのか」という根拠が案件に残らないことです。判断は消え、書類だけが残り、次に似た不具合が出たときに一から検討し直すことになります。この記事では、特採の判断が案件に残らない構造を業務分解で解きほぐし、業務OSでそろえられる範囲と人が握るべき範囲を切り分けて整理します。

特採（特別採用）とは何か？

特採（特別採用）とは、規定要求事項に適合していない製品を、それと承知したうえで使用・出荷することを認める処置です。英語ではコンセッション（concession）と呼ばれ、ISO 9000:2015（JIS Q 9000）の用語定義では「要求事項に適合していない製品又はサービスの使用又はリリースを認めること」とされています。寸法が公差からわずかに外れた、外観にわずかな欠点がある、といった不適合が見つかったとき、その都度すべてを廃棄・作り直しするのではなく、機能・安全・顧客要求に照らして「今回はこの条件なら使ってよい」と判断するのが特採です。

特採は品質を軽んじる行為ではありません。限られた納期とコストのなかで、実害のある不適合と実害のない不適合を切り分ける現場の重要な判断です。ISO 9001:2015 の 8.7「不適合なアウトプットの管理」でも識別・処置・記録の一連が求められており、記録に残すことまでが一続きの手続きです。ところが実務では、この記録が判断の再利用につながる形で残らないことが多いのです。

なぜ特採の判断は案件に残らないのか？

結論から言えば、特採票に「合否」は残っても、「なぜその合否にできたか」という判断の中身が残らないからです。多くの現場の特採票には、不適合の内容・数量・処置区分（そのまま使用／手直し／返却など）は記入されます。しかし、その判断を支えた技術的な根拠や、次に活かすための条件は、担当者の頭のなかとメールのやり取りに残ったままになります。下図のように、抜けやすい情報は3つに整理できます。

そもそも何が「残っていない」のか？

残っていないのは、判断の「根拠」「条件」「次への糸口」の3つです。第一に、判定の根拠です。「この寸法外れは、はめあい部ではないから機能に影響しない」といった技術的な理由づけが、口頭の合意やメールの返信で完結し、特採票の欄には落ちません。第二に、適用の条件・範囲・期限です。「どのロットまで」「どの寸法まで」「いつまで有効か」が図番や案件番号に紐づかないため、次に同じ不具合が出ても検索して再利用できません。第三に、是正への糸口です。特採はあくまで「その回の出荷可否」を決めるものなので、根本原因を潰す是正処置や水平展開につながらないまま閉じてしまいます。

この「成果物は残るが、判断の観点は残らない」という詰まり方は、特採に固有のものではなく、品質記録全般で観察される構造です。監査対応の受査準備を扱った過去記事でも同じ指摘をしています。

図面は直っても、なぜ直したのかという勘所は組織に残りません。

監査の前になると、全部門が資料探しに追われる——ISO 9001・客先監査の受査準備が属人化する構造と、品質OSでそろえられる範囲【2026年】

特採で「なぜ是にできたか」が残らないのも同じ現象です。判断の勘所が個人に閉じるため、経験の浅い担当者は前回の考え方を引き継げず、毎回ベテランに聞くかゼロから考え直すことになります。設計変更通知の漏れを扱った記事でも、経験差がレビューの場で埋まらない構造を指摘しました。

設計DR が形骸化する組織は、参加者の経験差をレビューの場で埋められず、結果として若手が「波及先を判断する力」を獲得できないまま実務に出ます。

設計変更通知の漏れが品質トラブルにつながる構造——情報・人・プロセスの分解

特採対応は業務OSでどこまでそろえられるのか？

業務OSがそろえられるのは、「判断の入れ物」と「後工程への接続」までです。ここでいう業務OSとは、ERPやPLMのようなデータの保管庫ではなく、日々の業務そのものを進める基盤を指します。特採では、判定の記録様式を統一して根拠を必須項目にし、条件・範囲・期限を図番や案件番号に構造化し、過去の特採を「不具合の型」で検索でき、必要なら是正処置の起票へ自動でつなぐ——ここまでが土台側の仕事です。

ERPとPLMは「データの保管と参照」が中心です。業務OSはその上に乗り、「日々の業務をどう進めるか」を担います。互いに置き換えるのではなく、補完する関係です。

業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体

大切なのは、業務OSは判断を代行する仕組みではない点です。土台がそろうと、判断に必要な情報がその場で引き出せるようになり、判断そのものの質と速度が上がります。下図は、業務OSでそろえられる範囲と、人が最終判断すべき範囲を切り分けたものです。

では、人が握り続けるべき範囲はどこか？

技術的な妥当性の最終判断、顧客との合意形成、リスクを受容するかどうかの意思決定は、人が握り続けるべき範囲です。「この不適合は本当に機能・安全に影響しないか」を見極めるのは、製品を理解した技術者の仕事です。顧客要求に触れる特採なら、後工程や客先との合意も欠かせません。最終的に「このリスクを負ってよいか」を決めるのは責任を持つ人間の判断です。業務OSはこれらの判断を奪うのではなく、判断に必要な材料を差し出す役割にとどまります。次の比較表は、両者の役割分担を整理したものです。

よくある反論：紙の特採票があれば十分では？

特採票の存在と、判断が再利用できることは別の問題です。「うちは特採票を紙で運用していて、ファイルにも綴じてある」という組織は多いはずです。しかし票があることと、次に似た不具合が出たときに「前回どう判断したか」を数秒で引き出せることはまったく別です。紙やスキャンPDFの票は、綴じられていても「不具合の型」で横断検索できません。結果として、記録はあるのに探せず、また一から検討する——監査や客先要求のたびに資料探しに追われる構造と同じことが特採でも起きます。

もう一つの反論は「特採は例外処置で、頻度が低く仕組み化するほどではない」というものです。しかし特採が積み重なると、それは自社製品でどの不適合がどの条件なら許容されてきたかという設計・品質の知見の集合になります。この知見が案件ごとに散逸するのは、再発防止と設計改善の両面で損失です。頻度ではなく、知見が残るかどうかで判断すべきです。

特採の記録を”残る形”にする第一歩は？

まずは自社の特採票に「根拠」「適用範囲・期限」「是正の要否」の欄があるかを確認することです。大がかりなシステム導入の前に、いまの票が何を残し何を落としているかを点検するだけで、詰まりの所在が見えます。次のチェックリストで、特採の判断が案件に残らない状態になっていないかを確かめてみてください。

よくある質問（FAQ）

特採と特別採用・コンセッションは同じ意味ですか？

はい、同じ処置を指します。特採は「特別採用」の略で、英語のコンセッション（concession）に対応します。ISO 9000:2015／JIS Q 9000 では「要求事項に適合していない製品又はサービスの使用又はリリースを認めること」と定義されています。なお、製造前に要求事項からの逸脱をあらかじめ認める「特別採用（デビエーション）」と区別する場合もあります。

特採の記録は法令や規格で義務づけられていますか？

ISO 9001:2015 の 8.7「不適合なアウトプットの管理」では、不適合の識別・処置とその記録の保持が求められています。特採（特別採用）を選んだ場合も、その旨と根拠を含む情報を記録として残すことが必要です。詳細は自社の品質マニュアルと客先要求を確認してください。

業務OSを入れれば特採の判断を自動化できますか？

いいえ、判断そのものの自動化は目的ではありません。業務OSがそろえるのは、記録様式・条件の構造化・過去事例の検索・是正への接続といった「土台」です。是か否かの技術判断、顧客合意、リスク受容は人が担います。土台がそろうことで、人の判断の再現性と速度が上がる補完関係です。

次に読むべき記事

• 監査の前になると、全部門が資料探しに追われる——ISO 9001・客先監査の受査準備が属人化する構造と、品質OSでそろえられる範囲【2026年】
• 設計変更通知の漏れが品質トラブルにつながる構造——情報・人・プロセスの分解
• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体

まとめ

特採（特別採用）の問題は判断の是非ではなく、「なぜその判断ができたか」という根拠・条件・是正の糸口が案件に残らないことにあります。残らないのは担当者の意欲ではなく、記録の入れ物が分散している構造の問題です。業務OSは判断を代行しませんが、判断の入れ物と後工程への接続をそろえることで、特採という知見を組織に蓄積できるようにします。まずは自社の特採票が何を残し、何を落としているかを点検することから始めてみてください。

出典・参考

• ISO 9000:2015／JIS Q 9000:2015「品質マネジメントシステム—基本及び用語」（特別採用〔コンセッション〕の定義）
• ISO 9001:2015／JIS Q 9001:2015「品質マネジメントシステム—要求事項」8.7 不適合なアウトプットの管理
• 本文中の図1・図2、表1は編集部が作成した概念図・整理表であり、特定企業の実測値ではありません。
• 関連する自社記事：業務OS・品質OS・設計変更通知の各解説（本文リンク先）