AIが「合格／不合格」を出す。では、その判定に最終的な責任を負うのは誰でしょうか。人はどこまで確認すべきで、記録は何を残せばよいのか。導入の勢いの中で曖昧になりがちな責任分界を、内部統制と監査対応の観点から解きほぐします。
品質保証の現場では、検査員の高齢化・採用難・熟練者への属人化が同時に進んでいます。目視検査の負荷を下げたい、判定のばらつきを抑えたい、という切実な事情からAI判定の導入が広がりつつあります。一方で、導入の議論が「精度は何％か」「どれだけ人を減らせるか」に集中し、内部統制上もっとも重要な問いが後回しになりがちだと考えられます。すなわち、AIが出した「合格」を最終的に保証するのは誰か、という問いです。
従来、出荷判定は検査基準書と検査員の判断、そして責任者の承認という人の連鎖で成り立っていました。ここにAIが入ると、判断の一部が自動化されます。しかし「AIが合格と言ったから出荷した」という説明は、顧客監査や品質問題が起きたときに通用しないと考えられます。法人としての責任、内部統制上の説明責任は、AIではなく人と組織に残り続けるからです。
責任分界が曖昧なまま運用が始まると、平常時は問題が表面化しません。トラブルは、不良の流出や顧客クレーム、あるいは監査での指摘という形で、後から顕在化することが多いと考えられます。そのとき「誰がどの基準で合格を承認したのか」を遡れないと、原因究明も再発防止も、そして顧客への説明も困難になりうる、という点に注意が必要だと考えます。
「AIを品質保証に組み込む」という漠然としたテーマは、内部統制の観点で分解すると扱いやすくなると考えられます。少なくとも次の4つの問いに、組織としての答えを用意しておくことが出発点になりうると考えます。
AI判定を「最終決定」として扱うのか、それとも「人の判断を支援する助言」として扱うのかで、責任構造は大きく変わると考えられます。多くの品質保証プロセスでは、当面は後者、つまりAIは一次判定を担い、最終承認は人が持つ設計が現実的になりやすいと考えます。ここを明文化しないと、現場では「AIが合格と言った」ことが実質的な最終決定として運用され、責任だけが宙に浮きうる、という点に注意が必要です。
全数を人が再確認するなら自動化の意味が薄れ、全く確認しないなら責任が持てません。現実には、AIが「判定に迷った」「閾値付近だった」ケースや、重大欠陥に直結する項目を人が重点確認するなど、リスクに応じた確認範囲の設計が必要になりうると考えます。
判定結果だけを残しても、後から「なぜそう判定したか」は再現できません。入力画像・判定根拠・モデルの版・閾値・確認者といった情報をどこまで残すかが、説明責任を果たせるかどうかを左右すると考えられます。詳しくはAI検査の説明責任と監査対応の観点も参考になると考えます。
AIモデルや閾値は、運用の中で更新されることがあります。更新の承認者・適用日・変更前後の挙動を管理しないと、「いつからこの基準になったのか」が説明できなくなりうると考えます。ソフトウェアの変更管理と同じ規律が、判定ロジックにも求められると考えられます。
責任分界の設計は、抽象論ではなく「どの工程で・どの項目を・誰が最終判断するか」という具体的な線引きに落とし込むことが重要だと考えられます。ここでは考え方の枠組みを示しますが、実際の線の引き方は、製品のリスク・不良流出時の影響・検査項目の性質によって変わるため、現物・現場での検証が前提になる点を強調しておきます。
すべての判定を同じ強度で人が確認する必要はないと考えられます。たとえば「不良を見逃したときの影響が大きい項目」「AIの判定信頼度が低いケース」「新規品種や条件変更の直後」は人の確認を厚くし、安定して信頼度の高い項目は抜き取りやサンプリング確認に留める、といったメリハリが現実的になりうると考えます。ここでの「信頼度」は、AIが根拠を提示できることが前提であり、説明可能なAI検査の考え方と結びつきます。
品質保証では、不良を良品と判定する「見逃し」と、良品を不良と判定する「過検出」は、責任上の重みが異なると考えられます。一般的には、顧客に流出しうる見逃しをより厳しく管理し、その分は過検出（人による再確認への回送）を許容する、という設計の考え方があります。どちらをどこまで許すかは経営判断であり、内部統制の方針として明文化しておくことが望ましいと考えます。
当面の設計としては、出荷可否の最終承認は人が保持する形が、内部統制上は説明しやすいと考えられます。AIは判断材料と根拠を提示し、人がそれを見て承認する。この「人が最後に判を押す」構造を残すことで、責任の所在が明確になりうると考えます。ただし、承認が形骸化して「AIの結果を機械的に承認するだけ」になると実質は自動化と変わらないため、承認者が根拠を確認できる仕組みとセットで設計する必要があると考えます。
内部統制と監査対応の中核は、判定の再現性だと考えられます。半年後、あるいは数年後に品質問題が起きたとき、「その時点で・その製品を・なぜ合格と判定したのか」を辿れる記録があるかどうかが、説明責任を果たせるかの分かれ目になりうると考えます。記録は「結果」だけでなく「根拠」まで含めることが鍵です。
あくまで一例ですが、判定ごとに次のような情報を残す設計が考えられます。入力画像そのもの／判定結果と判定根拠（どの箇所を・どう評価したか）／使用したモデルの版と閾値の設定／判定日時とライン・工程／確認者・承認者。これらが揃うと、後から第三者が判定を追跡・検証できるようになりうると考えます。記録項目の粒度は、監査要件や顧客要求に応じて調整が必要です。
記録を残すこと自体が目的化すると、「後から書き換えられる記録」になってしまう懸念があります。判定記録が改ざんされないこと、事後に辻褄合わせができないことは、内部統制上きわめて重要だと考えられます。誰がいつ何を変更したかを追える仕組みや、記録の完全性を担保する運用については、品質データ改ざん防止の観点が参考になると考えます。
判定結果だけの記録は、監査の場で「では、なぜこれを良品と判断したのか」と問われたときに答えられません。AIが判断した根拠を人が確認できる形で可視化し、それを記録に紐づけておくことが、記録を「使える証跡」にすると考えられます。根拠が示せないブラックボックスのままでは、記録の量を増やしても説明責任は果たしにくいと考えます。
AIを品質保証に組み込むと、顧客監査や内部監査、認証審査の際に「AI判定の妥当性をどう担保しているか」を問われる場面が増えると考えられます。ここで慌てないためには、監査で問われそうな問いを先回りして、答えと証跡を用意しておくことが有効だと考えます。ガバナンス全体の設計は製造業のAIガバナンスの観点も併せて整理すると見通しがよくなると考えます。
たとえば「判定基準は誰が承認したか」「モデルを更新したとき妥当性をどう確認したか」「AIが誤ったときにどう検知・是正するか」「最終責任は誰にあるか」といった問いは、監査で問われうる典型だと考えられます。これらに対して、文書化された方針・承認記録・是正のフローで答えられる状態にしておくことが、監査対応の負荷を下げると考えます。
監査では、自動化された判定に人がどう関与しているかが焦点になりやすいと考えられます。AIが一次判定し、人が根拠を見て承認する、という関与の実態を、記録として示せることが重要だと考えます。逆に、方針上は「人が確認する」となっていても実態が形骸化していると、監査で乖離を指摘されうるため、方針と実態を一致させておく必要があると考えます。
責任分界と記録の設計は、頭では理解していても運用の中で崩れやすい領域です。ここでは、現場で起こりがちな落とし穴を正直に挙げます。いずれも「導入は進んでいるのに、いざというとき責任と説明の空白が露呈する」形で表面化しうると考えられます。
完璧な自動化と完璧なガバナンスを最初から同時に目指すと、多くの場合、導入自体が動かなくなると考えられます。現実的なのは、限定した工程・項目で小さく始め、責任分界と記録の設計を運用しながら磨いていく進め方だと考えます。以下は一例としての段階です。
第一に、客観的な把握から始めます。現状の検査プロセスで「誰が・どの基準で・何を判断しているか」を棚卸しし、AIを入れる箇所と人が残す箇所を仮に線引きします。第二に、限定範囲で現物・現場での検証を行い、AIの判定と人の判定の一致・不一致を見ながら、確認範囲と閾値の考え方を調整します。この検証なしに責任分界だけを机上で決めても、実態と合わないと考えられます。
第三に、判定記録の項目と改ざん耐性を設計に組み込み、監査で問われそうな問いに答えられる状態にします。第四に、モデル更新の変更管理と、承認が形骸化しない運用ルールを定めます。これらを一度に完成させる必要はなく、小さな範囲で回しながら精度を上げていくことが、内部統制としても現実的だと考えます。
Nsightは、元キーエンス画像処理事業部の開発エンジニアの現場知見に、VLM・Jetsonエッジ・産業用カメラ・現場ライティングを組み合わせ、判定根拠を可視化・記録できる形でAIを品質保証プロセスに組み込む設計を得意としています。責任分界や記録の設計に決まった正解はなく、製品リスクと監査要件に応じて現物で検証しながら固めていくものだと考えます。判断に迷う段階でも、まず現状を一緒に棚卸しするところから相談することができます。
移らないと考えられます。法人・組織としての説明責任や品質保証責任は人と組織に残り続けると考えます。当面の設計としては、AIが一次判定と根拠提示を担い、出荷可否の最終承認は人が保持する形が内部統制上は説明しやすいと考えられます。ただし承認が形骸化しないよう、承認者が根拠を確認できる仕組みとセットで設計する必要があると考えます。
一律の正解はなく、リスクに応じて確認の強度を変える考え方が現実的だと考えられます。見逃したときの影響が大きい項目、AIの判定信頼度が低いケース、新規品種や条件変更の直後は人の確認を厚くし、安定した項目は抜き取り確認に留める、といった設計が一例です。実際の線引きは製品リスクと監査要件によるため、現物・現場での検証が前提になると考えます。
「なぜその判定に至ったか」を後から再現できることが核になると考えられます。入力画像・判定根拠・モデルの版・閾値・確認者などの記録に加え、判定基準の承認記録、モデル更新時の妥当性確認、是正のフロー、最終責任の所在を文書で示せる状態が望ましいと考えます。記録は結果だけでなく根拠まで含めることが、証跡として機能する鍵になりうると考えます。
ソフトウェアの変更管理と同じ規律が求められると考えられます。更新の承認者・適用日・変更前後の挙動を記録し、「いつからこの基準になったか」を説明できる状態にしておくことが望ましいと考えます。これがないと、品質問題が起きたときに原因が更新に起因するのかを切り分けられず、説明が困難になりうると考えます。
品質マネジメント規格や、業界・顧客ごとの品質要求、AIに関するガイドライン等が関わりうると考えられます。ただし要件は業界・製品・時期によって異なり更新もされるため、具体的な適用範囲や求められる文書は、所管省庁や認証機関の最新の公表資料、および取引先の品質要求で必ずご確認ください。本記事は一般的な考え方の整理であり、個別の適合判断を代替するものではないと考えます。
AI判定を品質保証に組み込む際、最終責任や確認範囲、判定記録の設計に決まった正解はなく、製品リスクと監査要件に応じて現物で検証しながら固めていくものだと考えます。まずは現状のプロセスを一緒に棚卸しし、どこにAIを入れ、どこに人の判断を残すかを整理するところから始められます。
責任分界と判定記録の設計について相談する