現場でAIを使うときのガバナンスとリスク管理

エグゼクティブ・サマリー

• 現場AIのガバナンスは「禁止事項リスト」では機能しない。 現場が知りたいのは「使ってよいか」ではなく「この作業に使ってよいか」である。作業単位で線引きしない規程は、読まれないまま影で使われる状態を生む。
• リスクは一律ではなく4層に分かれる。 ①人体に触れる ②モノ・設備を動かす ③意思決定を左右する ④文章・情報を生成するだけ、の順にリスクの重さが違う。同じ「AI利用ルール」で束ねると、①が緩みすぎるか④が窮屈すぎるかのどちらかになる。
• 決めるべきは精度ではなく「誰が止められるか」である。 AIの誤りをゼロにはできない。ガバナンスの実体は、異常に気づく仕組みと、現場の担当者が上司の承認なしに止められる権限を明文化することに尽きる。
• 判断ログを残していない現場は、事故のあとに説明ができない。 入力・出力・人が採否をどう判断したかの3点を残す設計を、運用開始前に組み込む必要がある。あとから足すのは難しい。
• ガバナンスは一社では完結しない。 現場のAIはユーザー企業・SIer・メーカー・運用事業者にまたがって動く。責任分界を契約前に文書化しないと、不具合発生時に全員が「自分の範囲ではない」と言う状態に陥る。

現場でのAI活用が広がるにつれ、「ガバナンスをどうするか」という問いが増えている。しかし多くの企業で実際に起きているのは、情報システム部門が一般的なAI利用ガイドラインを作成して全社配布し、現場がそれを読まずに使い続ける、という状態である。規程は存在するのに実効性がない。逆に、規程が厳しすぎて現場が申請を諦め、個人アカウントで生成AIを使う「影のAI利用」が発生している例もある。

この状態が生まれる理由ははっきりしている。ガバナンス文書が作業単位ではなくツール単位で書かれているためである。「生成AIの業務利用について」という文書は、日報の下書きにも、検査判定にも、ロボットへの動作指示にも同じ規律を当てようとする。しかし現場から見れば、この3つはまったく別の話である。本稿では、現場のAI利用を4層に分解し、それぞれに何を決めるべきかを具体的に示す。

1. なぜ「守りの文書」だけでは機能しないのか

AIガバナンスの議論は、多くの場合「禁止事項の列挙」から始まる。機密情報を入力しない、出力をそのまま使わない、といった条項である。これ自体は間違っていない。しかし現場の担当者が実際に直面するのは、次のような問いである。

• 検査でAIが「不良」と判定した。人が見ると良品に見える。どちらを採用するのか。誰が決めるのか。
• 生成AIに手順書の下書きを作らせた。そのまま配ってよいのか。誰かの確認が要るのか。誰の確認か。
• ロボットの動作をAIが自律的に変えた。想定と違う動きだが、危険ではない。報告すべき事象なのか。

禁止事項リストはこのどれにも答えていない。ガバナンス文書が答えるべきなのは「やってはいけないこと」ではなく、判断が割れたときに誰がどう決めるかである。ここが書かれていない文書は、現場では単なる免責文書として扱われる。

もう一つの失敗パターンが、承認プロセスの重さである。AI利用のたびに申請と承認を求める設計にすると、現場は申請しなくなる。ガバナンスを強めたつもりが、可視性を失う。実効性のある設計は逆で、低リスクの利用は届出不要にして可視化を捨てない代わりに、高リスクの利用に審査を集中させる。全部を等しく管理しようとした瞬間に、ガバナンスは形骸化する。

2. 現場AIのリスクを4層に分解する

現場で使われるAIを、「誤ったときに何に波及するか」で4層に分ける。この分解が、以降のすべての設計の土台になる。

この4層を混ぜないことが重要である。実務でよく見るのは、L4を想定して作られた全社AIガイドラインが、L1やL2の現場にそのまま適用されている状態である。「出力は人が確認すること」という条項は、L4では成立するが、秒単位で動作を生成するL1では物理的に成立しない。L1で必要なのは事前確認ではなく、動いている最中に止める仕組みである。逆にL4に厳格な事前審査を課すと、現場は使わなくなるか、隠れて使う。

自社の現場でどのAIがどの層にあるかを、まず一覧にする。この作業だけで、規程の当て方が間違っている箇所がはっきり見えてくることが多い。

3. 使ってよい範囲を3段階で線引きする

層の分解ができたら、次は「どこまで自動でやらせるか」を決める。ここを曖昧にしたまま導入すると、現場ごとに運用がばらつき、事故が起きたときに標準が存在しないことが露呈する。

判断レベルを3段階で定義する。

重要なのは、レベルCを最初から狙わないことである。多くの現場では、レベルBの「条件付き自動」で必要な効果の大半が得られる。しかも、レベルBは範囲の数値を絞れば絞るほど安全側に倒せるため、運用しながら範囲を広げるという育て方ができる。いきなりCで始めると、問題が起きたときに全面停止しか選択肢がなくなる。

範囲を決めるときは、必ず数値で書く。「大きく外れた場合は人が確認する」ではなく、「前回設定値からの変更幅が±5%を超える場合は人が確認する」と書く。この数値は最初から正解を出せないので、暫定値で始めて運用データを見て見直す前提にする。見直しの時期（たとえば稼働1か月後・3か月後）まで先に決めておくと、実際に見直される。

4. 判断ログを残す——事故のあとに説明できる状態をつくる

AIを使った現場で最も後悔されるのが、ログ設計の後回しである。何か問題が起きたとき、説明のために必要なのは次の3点である。

1. 入力：そのときAIが受け取ったデータ（画像、センサ値、指示文、参照した文書）
2. 出力：AIが返した結果と、可能ならその確からしさの度合い
3. 人の判断：出力を採用したか、覆したか、誰がいつ判断したか

3つ目が抜けている現場が非常に多い。AIの入出力ログは残っているのに、それを人がどう扱ったかが残っていない。これでは「AIが間違えた」のか「AIは正しかったが人が覆した」のかが再現できず、改善もできなければ説明もできない。

ログ設計で決めるべき項目は次の通りである。

• 保持期間：層ごとに変える。L1・L2は長め、L4は短めが基本。無制限保持は保管コストと情報リスクの両面で不利になる
• 保存場所：現場の端末に閉じたログは、事故後に取り出せないことがある。稼働データ基盤へ集約する設計にしておく（ロボット稼働データの収集・可視化基盤 を参照）
• 参照権限：誰がログを見られるかを決める。特に映像を含む場合は限定する
• 改ざん防止：追記のみとし、上書き削除ができない構造にする

ログは事故対応のためだけのものではない。ロボット導入のKPI設計と効果測定 で扱った効果測定も、予知保全 のモデル改善も、同じログを土台にする。ガバナンスのためのログと改善のためのログは、設計を分ける必要がない。むしろ一本化したほうが、現場の負担が減り、結果的に守られる。

5. 物理を伴うAIのガバナンス——止める権限を先に決める

L1のガバナンスは、他の層とは質的に異なる。生成AIの議論をそのまま持ち込んでも役に立たない。ここで決めるべきことは3つである。

第一に、停止権限である。 「おかしい」と感じた現場の担当者が、上長の承認を待たずに止められること。これを明文化し、止めた判断を事後に咎めない運用にする。止めたことを責められる文化では、誰も止めない。むしろ、止めた事例を共有し、判断を称える運用にしたほうが、結果として稼働率も上がる。

第二に、縮退動作である。 AIの出力が信頼できないと判断されたときに、システムが何をするかを事前に決める。全停止か、低速の安全モードか、あらかじめ定めた固定動作へのフォールバックか。この設計がないと、異常時の挙動が実装者任せになる。

第三に、変化の管理である。 学習型のAIは、モデルを更新すると挙動が変わる。ロボットにおいては、これがリスクアセスメントの前提を崩す可能性がある。モデル更新を「ソフトウェア変更」として変更管理の対象に含め、更新前後で挙動比較を行う手順を決めておく。安全設計の基礎は ロボットの安全とリスクアセスメント と 協働ロボットの導入と安全設計 で扱っているが、AIを載せる場合は「一度アセスメントすれば終わり」ではなくなる点が決定的に違う。

6. データの扱い——現場の映像と音声をどこまで残すか

現場AIの多くは、映像を扱う。外観検査、自律移動、作業分析のいずれも、カメラが入る。ここで必ず論点になるのが、映っている人の扱いである。

決めるべきことは3点に整理できる。

• 何のために撮るか：目的を具体的に書く。「業務改善のため」では足りない。「検査工程での判定精度の維持のため」まで書く
• どこまで残すか：判定結果だけを残して原画像は一定期間で消すのか、原画像も残すのか。学習用に残す場合は、その旨を目的に含める
• 誰に見せるか：閲覧権限を職位ではなく役割で定義する。「工場長は全部見られる」ではなく「品質管理担当者は検査画像を見られる」とする

従業員が映る場合は、事前に説明することが実務上ほぼ必須である。法令上の要否判断とは別に、説明なく撮られていたと後から分かったときの現場の反発は、AIの導入そのものを止めるほどの力を持つ。個人情報に関する法令への対応は当然として、それとは別に、現場との合意形成としての説明を工程に組み込むべきである。この点は 現場を動かすチェンジマネジメント の論点と直結する。

外部のAIサービスを使う場合は、入力したデータがサービス提供者側でどう扱われるか（学習に使われるか、どこに保存されるか、いつ消えるか）を契約または利用条件で確認する。ここは調達時にしか交渉できないので、稼働後に気づいても手遅れになりやすい。

7. 導入7工程のどこにガバナンスを埋め込むか

ガバナンスを後付けの文書にしないためには、導入プロセスの各工程に組み込むのが確実である。RobiZyが整理している導入7工程に沿って示す。

特に②の段階が重要である。ここでログ要件を要件定義書に書き込まなければ、ほぼ確実に後付けになる。後付けのログは、必要な情報が揃わないまま形だけ残る。ロボット導入の要件定義書 と PoCの設計と評価 を進める際に、AI章を1節設けることを推奨する。

また⑥の「逸脱事例の共有会」は、実効性の面で最も効く施策の一つである。月に一度、AIの判断がおかしかった事例、人が覆した事例、止めた事例を持ち寄る。これを続けている現場は、規程を配っただけの現場と比べて、異常の発見が明確に早い。ガバナンスが文書ではなく習慣として現場に定着するからである。

8. 会社をまたぐガバナンス——責任分界を契約前に決める

現場のAIは、一社の中で完結しない。ロボット本体のメーカー、システムを組んだSIer、AIモデルの提供元、運用を担う事業者、そしてユーザー企業。この全員が関与する。問題が起きたとき、責任分界が文書化されていなければ、全員が「自分の範囲ではない」と述べる状態になる。

契約前に文書化すべき項目は次の通りである。

• モデルの提供・更新責任：誰がモデルを更新するか。更新時の事前通知の要否と期限
• 性能低下時の一次対応：現場が最初に誰に連絡するか。連絡先が一本化されているか
• ログの帰属と開示：稼働ログは誰のものか。トラブル時に相互に開示する義務があるか
• 停止判断の権限：ユーザー企業が独自判断で停止できるか。停止が保証条件に影響しないか
• データの二次利用：現場データをベンダー側の改善に使えるか。使う場合の範囲と対価

これらは 複数ベンダー・複数機種の統合とデータ連携 で扱った統合の問題と重なるが、AIが入ると論点が一つ増える。モデルの挙動が時間とともに変わるという点である。従来の機械は、納入時の仕様が動作を規定した。AIを載せた機械は、更新のたびに挙動が変わりうる。従来型の契約書のままでは、この変化を誰がどう管理するかが規定されていない。

ここは一社で解ける問題ではない。ユーザー企業が個別にベンダーと交渉しても、業界としての相場観がなければ落としどころが見えない。逆にベンダー側も、一社ごとに異なる要求を受けると対応コストが跳ね上がる。責任分界の型を業界で共有することが、双方にとって合理的である。ロボットの標準化・相互運用性 と並ぶ、実務的な標準化の課題といえる。

まとめ

現場AIのガバナンスは、立派な規程を作ることではない。実務として押さえるべきは次の5点に集約される。

1. AI利用を4層（物理作用／設備制御／判断支援／情報生成）に分け、層ごとに規律を変える
2. 判断レベルA/B/Cで自動化の範囲を数値で定義し、レベルBから育てる
3. 入力・出力・人の判断の3点をログに残し、保持期間と権限を層ごとに決める
4. 物理を伴うAIでは、止める権限を現場に与え、止めた判断を咎めない運用にする
5. 責任分界を契約前に文書化し、モデル更新による挙動変化を変更管理の対象に含める

そして最後の論点——会社をまたぐ責任分界とモデル更新の管理——は、一社の努力では答えが出ない領域である。ユーザー企業だけで議論しても実装可能な線が引けず、ベンダーだけで議論してもユーザーの実態に合わない。

RobiZy（NPO法人ロボットビジネス支援機構）は、ロボットを売らない中立の立場で、ユーザー企業・ロボットメーカー・SIer・運用事業者・自治体・大学が同じテーブルに着く会員組織である。現場AIのガバナンスのように、立場をまたいで型を作らなければ前に進まない論点こそ、この場が最も力を発揮する領域だと考えている。自社の現場で直面している論点を持ち寄り、他社の実務と突き合わせたいという方は、ぜひ正会員としてご参加いただきたい。議論の成果は、参加各社が自社の契約書と運用手順にそのまま持ち帰れる形で共有している。