現場でPoCがうまくいっても、最後に情報システム部門やセキュリティ担当の審査で止まる——そんな詰まりは珍しくありません。この記事では、審査で必ず聞かれる論点を先回りして整理し、オンプレミス／閉域構成が審査上どう有利か、逆にオンプレでも問われる点は何かを、用意しておくべき資料の形で示します。
AI導入が審査で止まる主因は、多くの場合「技術の良し悪し」ではなく「データの行き先が説明できないこと」だと考えられます。現場は検査精度や省力化の効果を語りますが、情報システム部門やセキュリティ担当が見ているのは別の面——どの範囲のデータが社外へ出るのか、通信先はどこか、誰がアクセスできるのか、という点です。この二つの言語がかみ合わないと、話は「良さそうだが承認できない」で止まります。
背景には、社会全体でデータの取り扱いへの要求が上がっている事情があります。取引先からのセキュリティチェックシート、業界ガイドライン、個人情報・営業秘密の管理義務など、企業が「自社のデータをどこに預けているか」を説明する責任は年々重くなっています。所管する制度や適用範囲は変化するため、具体的な義務の範囲は所管省庁や業界団体の最新の公表資料でご確認ください。
審査担当は導入を妨害したいわけではなく、承認するための根拠を探しています。つまり審査は敵対ではなく、同じ問いに一緒に答える作業だと捉え直せます。止まる案件の多くは、担当者が意地悪だからではなく、答えるための材料が提出側に用意されていないために「判断できない＝保留」になっているだけ、というのが実態に近いと考えます。
だからこそ有効なのは、審査で聞かれることを先回りして資料化し、現場の熱量と情シスの言語を橋渡しすることです。本稿では、その「聞かれること」を論点ごとに分解し、オンプレミス（自社内の機器で完結させる構成）や閉域ネットワークがどこまで答えになりうるかを整理します。
審査で問われる論点は、経験上おおむね6つに集約できると考えられます。(1)データはどこに出るか、(2)通信先はどこか、(3)更新はどう行うか、(4)ログと監査はどう残すか、(5)障害時にどう切り離すか、(6)退職者・委託先のアクセスをどう失効させるか。順に見ていきます。この6つを一枚で答えられれば、審査の初回で話が前に進む確率は高まると考えます。
最も重い問いが、学習・推論に使うデータがどの範囲で、どこへ送られるかです。ここでいうVLM（Vision Language Model：画像とテキストを結びつけて理解する視覚言語モデル）を含むAIは、クラウドAPIを使う構成だと画像そのものが社外のサーバへ送られます。検査画像や図面が営業秘密を含む場合、この一点で審査が止まることは珍しくありません。逆に、通信先が「社内のこの機器だけ」と言い切れる構成なら、この問いには構造で答えられます。工場データを外に出さない構成の考え方は、この論点に直接効いてきます。
残りの4つは運用の問いです。モデルやソフトを更新する経路はどこを通るのか、誰が何を承認したかを後から追えるか、AIが誤作動したとき安全に切り離せるか、退職者や委託先の権限を確実に失効できるか。これらは「外に出さない」だけでは答えきれず、運用設計で担保する領域です。オンプレを選んでも、この4つの問いは残り続けると理解しておくことが重要だと考えます。
結論から言えば、オンプレミス／閉域構成は「データがどこに出るか」「通信先はどこか」という最重量の2問に対して、構造で答えられる点で審査上有利になりうると考えます。データが社内の機器から出ない構成であれば、「社外送信はありません」という一文が、口約束ではなく物理的な事実として説明できるからです。
具体的には、産業用カメラで撮った画像をJetson等のエッジ（現場の機器上でAI推論を完結させる小型の計算機）で処理し、結果だけを社内のデータ基盤に集約する構成が考えられます。この場合、外部への通信は原則発生しません。閉域ネットワーク（インターネットから切り離した社内専用網）に載せれば、通信先の説明はさらに単純になります。閉域ネットワークとOTセキュリティの前提を押さえておくと、工場側のネットワーク担当との会話もかみ合いやすくなると考えます。
ただし有利さの範囲は正確に線引きすべきです。オンプレ／閉域が強いのは(1)(2)の「送信」に関わる論点であり、(3)〜(6)の運用の論点はむしろ自社の責任が増えます。クラウドなら事業者が担う部分（物理セキュリティ、パッチ適用、可用性）を、オンプレでは自社が持つことになるためです。「オンプレだから全部安全」という説明は、審査担当に見抜かれると逆に信頼を損ないうるので避けたいところです。
どちらが向くかは条件で分かれます。オンプレ／閉域が向くのは、画像や図面が営業秘密を含む、取引先から社外送信の禁止を求められている、通信環境が不安定で常時接続を前提にできない、といった場合です。クラウド活用が向くのは、扱うデータの機密度が低い、更新頻度が高くモデルを頻繁に差し替えたい、自社に運用要員を割きにくい、といった場合だと整理できます。両者は排他ではなく、機密度の高い工程だけオンプレにする折衷も現実的な選択肢になりうると考えます。
オンプレを選んでも審査は終わりません。むしろ「送信しないなら安全」という思い込みが、物理と運用のリスクを見落とさせることがあります。閉域でも問われる代表が、物理アクセスとモデル更新の手順です。ここを設計に織り込めているかが、審査の第二段階を分けると考えます。
社内に機器を置くということは、その機器に物理的に触れられる人を管理する責任が生じるということです。サーバ室やエッジ機器の設置場所に誰が入れるか、USBポートやコンソールへの接続をどう制限するか、検査画像を保存したストレージの持ち出しをどう防ぐか。クラウドなら事業者のデータセンターが担っていた物理防御を、自社の運用ルールで置き換える必要があります。検査データの取り扱い設計は、機密画像を預かる前提でこの物理面まで含めて考える出発点になると考えます。
閉域で運用すると、モデルやソフトの更新をどう届けるかが論点になります。「閉域なのに更新のためだけに外部通信を開ける」と、せっかくの閉域が穴を持つことになりかねません。更新ファイルを検証済みの媒体で持ち込む手順、持ち込む人と承認者、適用前後の検査、問題時に前バージョンへ戻す手順——この一連を文書化できているかを審査は見ます。更新は止められないからこそ、経路と承認を先に決めておくことが肝心だと考えます。
審査を早く通すコツは、聞かれてから探すのではなく、聞かれる前に一式を揃えておくことです。以下は、オンプレAI導入の審査で提出を求められやすい資料の目安です。すべてを最初から完璧に作る必要はなく、まず骨子を用意し、審査担当との対話で精緻化していく進め方が現実的だと考えます。社内で完結する工場データ基盤を前提にすると、これらの資料は書きやすくなります。
最優先は、カメラ→エッジ→社内基盤という、データが「どこで生まれ、どこを通り、どこに貯まり、どこへ出ないか」を一枚で示す図です。通信先を明示し、社外への線が引かれていないことが視覚的に分かる形にします。この一枚があるだけで、口頭説明の何倍も速く審査担当の理解が進むと考えます。あわせて、閉域網であればその境界と、外部と接する点（もしあれば）を明記します。
データフロー図に続けて、次のような資料を用意しておくと審査がスムーズになると考えます。取り扱うデータの種類と機密度の一覧、アクセス権限の一覧（誰が何にアクセスできるか）、更新・パッチ適用の手順書、障害時の切り離しと復旧の手順書、ログ取得と保管の方針、退職者・委託先のアクセス失効フロー、物理アクセス管理のルール。これらは導入コンサルティングの中で、審査の進行とあわせて整えていく対象にもなりえます。
監査への答えは「誰が・いつ・何を・何に対して行ったか」を後から追える状態を作ることです。AI導入で特に問われるのは、モデルの更新履歴、検査結果の確定を誰が承認したか、設定変更の記録、アクセスの記録の4点だと考えられます。証跡は「取っている」だけでなく「改ざんされにくく」「必要なとき取り出せる」ことまで含めて設計する必要があります。
実務では、証跡を細かく取りすぎてストレージと運用が破綻する失敗と、粗すぎて審査に耐えない失敗の両方が起こりえます。まず「何かあったとき何を説明する必要があるか」から逆算し、その説明に必要な粒度でログを設計するのが現実的だと考えます。監査証跡の残し方で扱う「誰が何を承認したかを追う」観点は、AIが判断に関わる工程では特に重要になります。
AIが誤った判断をしたとき、安全側に倒して人手検査へ切り替えられること、そしてその切り替えが記録に残ることが求められます。切り離しは技術の話に見えますが、審査上は「異常を検知したら止められるか」「止めた事実を追えるか」というガバナンスの話です。切り離しの手順と、そのときログに何が残るかをセットで説明できると、審査担当の不安は大きく下がると考えます。
最後に、審査準備でつまずきやすい点を正直に挙げます。どれも「やってみないと分からない」部分を含み、先に知っておくだけで手戻りを減らせると考えます。
始点は、立派な資料を作ることではなく、現状のデータの流れを客観的に把握することです。今どの画像・データが、どこで生まれ、どこへ流れているのか——多くの現場で、この現状把握の段階で「実は把握できていなかった」ことが見つかります。ここを起点にすれば、審査資料は現実に即したものになると考えます。
次に、小さな現物検証をおすすめします。自社の代表的な検査対象を、オンプレ／閉域を想定した最小構成で試し、通信先・ログ・切り離しが説明できる形になるかを実地で確かめます。元キーエンス画像処理事業部の現場知見 × VLM × Jetsonエッジ × 産業用カメラ × 現場ライティングを組み合わせた検証を通じて、「審査で説明できる構成」を実物で確認していく進め方が、机上論より速く合意に近づくと考えます。
最後に、審査担当を早い段階で巻き込むことです。完成した資料を持ち込んで承認を求めるより、データフロー図の骨子の段階から一緒に見てもらうほうが、手戻りが減り、審査は「止める場」から「合意する場」へ変わっていくと考えられます。審査は通すものではなく、一緒に答えを作るものだと捉えるのが、結局は近道だと考えます。
必ず通るとは言えません。オンプレ／閉域構成は「データが社外に出ない」という最も重い論点に構造で答えられる点で有利になりうる一方、物理アクセス管理・モデル更新の手順・ログと監査・退職者や委託先のアクセス失効といった運用の論点は残ります。むしろクラウド事業者が担っていた部分を自社が持つため、それらを設計・文書化できているかが審査の鍵になると考えます。
最優先はデータフロー図とネットワーク構成図です。カメラ→エッジ→社内基盤という流れで、データがどこで生まれ、どこを通り、どこへ出ないかを一枚で示せると、審査担当の理解が大きく進むと考えられます。続いて、取り扱いデータの機密度一覧、アクセス権限一覧、更新手順書、障害時の切り離し手順、ログ方針、失効フローを揃えると審査がスムーズになりやすいです。
できなくなるわけではありません。ただし更新の届け方を設計しておく必要があります。検証済みの媒体で更新ファイルを持ち込む手順、持ち込む人と承認者、適用前後の検査、問題時に前バージョンへ戻す手順を先に決めておくのが現実的です。更新のためだけに常時の外部通信を開けると閉域の前提が崩れうるため、経路と承認を最初に設計することをおすすめします。
アクセスの付与と失効をセットで文書化することが基本になると考えます。導入時の権限付与は設計されがちですが、外すフローは忘れられやすい部分です。誰がいつ権限を付け、いつ外したかを記録に残し、退職・契約終了のタイミングで確実に失効させるフローを用意します。委託先については、作業範囲と期間を限定し、終了後に権限が残らないことを確認できる形にしておくと審査で説明しやすいです。
認識率やコスト削減率などの数値は、現物・現場での検証を経ていない段階で断定して書くことはおすすめしません。検証前に数値を約束すると、後で実態と齟齬が生じ、かえって信頼を損ないうるためです。効果に触れる場合は「一例」「モデル前提」と明示し、現物検証が前提であることを添えるのが誠実だと考えます。制度上の要件がある場合は所管省庁の最新の公表資料でご確認ください。
現場が乗り気でも、データの行き先を説明できないと審査は止まります。まずは自社の代表的な検査対象で現状のデータの流れを客観的に把握し、オンプレ／閉域を想定した最小構成の現物検証から始めるのが近道だと考えます。審査で説明できる構成づくりを、現場の知見とともにご一緒します。
オンプレAIの審査準備について相談する