APIが存在しない古い基幹システム。あるいは、仮想デスクトップ（VDI）越しにしか操作できないセキュリティ区画内のアプリケーション。
これらは長らく、DXの「ラストワンマイル」として残り続けてきました。RPA（Robotic Process Automation）がその穴を埋めようとしましたが、画面レイアウトの些細な変更やポップアップの出現で停止してしまう脆弱さに、頭を抱えた経験のある方も多いのではないでしょうか。
そこに登場したのが、ChatGPTやClaudeといったマルチモーダルAIを活用した「画面認識型」の自動化技術です。近年のアップデートにより、これらのAIは単に画面を「見る」だけでなく、タスクの複雑さに応じて自律的に思考プロセスを深くし、人間と同等のレベルでPC操作（Computer Use）を実行できるようになりました。より高度な推論能力とツール実行能力を備えた新世代環境への移行が急速に進む中、シリコンバレーのスタートアップ界隈では「Large Action Models（LAMs）」と呼ばれる領域で熱狂的な開発競争が繰り広げられています。
同時に実務において注意すべきなのが、AIモデルの急速な世代交代です。レガシーなモデルが短期間で廃止され、より高性能な主力環境への移行が避けられないケースは珍しくありません。そのため、古い環境の仕様に依存した自動化プロセスを定期的に見直し、最新の高度な推論機能（Adaptive Thinkingなど）を前提とした、柔軟で持続可能な移行ステップをシステム設計に組み込むことが不可欠となっています。
しかし、専門的な観点から分析すると、この革新的な技術を手放しで称賛するわけにはいきません。特に厳格な規制が存在する産業において、この技術は諸刃の剣となるからです。
なぜなら、AIは「確率的に」動作するからです。
RPAは、設計図通りに動くか、エラーで止まるかの二択でした。対してAIは、「たぶんこれが正解だ」と判断して処理を進めます。高度な推論能力によって精度は飛躍的に向上しているものの、99回成功しても、1回だけ「削除」ボタンを「承認」ボタンと見間違えるリスクはゼロではありません。その1回が基幹データの消失につながるとしたらどうでしょうか。
本稿では、この魅力的だが危険な「視覚を持つAI」を、企業のガバナンス下で安全に運用するための設計論について解説します。技術的な実装手順（How）よりも、いかに事故を防ぎ、説明責任を果たすか（Governance）に焦点を当て、経営と現場の両視点から実践的なアプローチを探ります。
なぜ「画面を見るAI」はRPAと異なるリスク管理が必要なのか
従来のRPAと、最新のマルチモーダルAIエージェント。どちらも「PCを操作する」という点では同じに見えますが、その裏側にあるロジックは水と油ほど異なります。リスク管理のアプローチを変えなければならない理由は、まさにこの「作動原理の違い」にあります。
決定論的（RPA）vs 確率論的（AI）挙動の違い
これまでのRPAは「決定論的（Deterministic）」なシステムでした。シナリオに「X座標100、Y座標200をクリック」と書かれていれば、そこに何が表示されていようとクリックします。あるいはHTMLタグのIDを指定していれば、そのIDが見つからない限り動作しません。
失敗する時は「エラーで停止」します。これは運用担当者にとっては面倒ですが、リスク管理の観点からは「安全な失敗（Fail-safe）」と言えます。何も起きないからです。
一方、マルチモーダルAIは「確率論的（Probabilistic）」に動作します。AIに「請求書発行ボタンを押して」と指示すると、AIは画面のスクリーンショットを解析し、「この青い四角い領域が『請求書発行』である確率は98%だ」と推論してクリックします。
問題は、AIが「自信満々で間違える」ケースがあることです。例えば、UIのデザイン変更で「発行」ボタンと「破棄」ボタンの色が似てしまった場合、AIは文脈を読み違えて「破棄」を押してしまう可能性があります。RPAなら「対象が見つかりません」と止まる場面で、AIは「気を利かせて」誤った操作を完遂してしまうリスクがあるのです。
GUI変更への適応力が生む「予期せぬ操作」のリスク
AIの最大のメリットは、画面レイアウトが多少変わっても柔軟に対応できる点です。これは開発・保守コストの削減という点では素晴らしい特性ですが、統制の観点からは「予測不可能性」を生みます。
例えば、SaaSの画面に新機能のポップアップ広告が出たとします。人間なら「×」を押して閉じます。AIも賢いので「×」を押そうとするでしょう。しかし、もしそのポップアップが「新機能のトライアル（有料）に申し込む」というボタンを含んでおり、AIがそれを「業務に必要なプロセスの開始」と誤認したらどうなるでしょうか。
RPAであれば、想定外のポップアップが出た時点でシナリオが破綻し、停止します。しかしAIは、その高い適応力ゆえに、未知の画面に対しても何らかのアクションを試みてしまう可能性があります。この「自律性」こそが、レガシーシステム操作における最大のリスク要因となります。
コンプライアンス視点でのブラックボックス問題
監査において最も重要なのは「再現性」と「説明可能性」です。「なぜその処理を行ったのか」という問いに対し、RPAなら「スクリプトの15行目にそう記述されているから」と明確に回答できます。
しかし、ディープラーニングベースのAIモデルの場合、その判断プロセスはブラックボックスになりがちです。「なぜAIはAボタンではなくBボタンを押したのか？」と問われた際、「当時のニューラルネットワークの重み付けがそう判断した」では、監査部門を納得させることは不可能です。
したがって、AIを導入する際は、このブラックボックス性を外部的な記録や制約で補完する仕組みが必須となります。AIそのものを盲信するのではなく、AIを囲い込む「枠組み」を信頼できるものにするアプローチが必要です。
コンプライアンス適合性の判定：AIに「触らせて良い」業務の境界線
すべてのレガシーシステム操作をAIに任せるのは無謀です。リスク許容度に応じて業務を分類し、AIの適用範囲を厳格に定義する必要があります。専門的な観点から推奨されるのは、操作のリスクレベルに応じた「段階的認可モデル」です。まずはプロトタイプを作成し、実際の挙動を検証しながら適用範囲を広げていくアプローチが有効です。
リスクレベルに基づく業務仕分けフレームワーク
業務を以下の3つのレベルに分類し、それぞれの自動化可否を判定します。
Level 1: 情報収集・参照（Low Risk）
- 操作内容：データの閲覧、検索、コピー、レポートのダウンロード。
- AI適用判定：推奨。
- 理由：誤操作があってもシステム内のデータは変更されません。情報漏洩リスクへの対策（後述）さえあれば、積極的に自動化すべき領域です。
Level 2: 下書き・入力補助（Medium Risk）
- 操作内容：フォームへの入力、申請書のドラフト作成、メールの下書き。
- AI適用判定：条件付き可（Human-in-the-Loop必須）。
- 理由：AIは入力までを行い、最終的な「確定（Commit）」ボタンは人間が押す、あるいは人間が内容を確認してからAIに実行許可を出すフローにします。最新の推論モデルは高い文脈理解力を持ちますが、最終責任は人間が負うべきです。
Level 3: 更新・削除・決済（High Risk）
- 操作内容：送金処理、マスタデータの変更、ユーザー削除、発注確定。
- AI適用判定：原則禁止（または厳格なガードレール下でのみ限定許可）。
- 理由：取り返しのつかない（Irreversible）操作は、現時点の技術レベルではAIに全権委任すべきではありません。API経由でトランザクション管理ができる場合を除き、画面操作での完全自動化は避けるべきです。
Read-only（参照）とWrite（更新）の厳格な分離
システム設計上、AIエージェントに付与するアカウント権限でこの分離を強制することが最も確実です。
レガシーシステムのアカウント管理において、AI専用のユーザーID（例：AI_USER_01）を発行し、そのユーザーには「参照権限」のみを付与します。もしAIが誤って更新ボタンを押そうとしても、システム側で権限エラーとして弾かれます。
更新が必要な業務の場合でも、可能な限り「入力者（AI）」と「承認者（人間）」のアカウントを分け、AIアカウントではワークフローの起票までしかできないように設定するのがベストプラクティスです。
PII（個人識別情報）を含む画面の取り扱い基準
画面認識型AIは、スクリーンショットをクラウド上のLLM（大規模言語モデル）に送信して解析するケースが大半です。エンタープライズ向けサービスを利用する場合でも、データはサーバーへ送られます。
ここで最大のリスクとなるのが、画面上に映り込む顧客の個人情報や機密データです。例えば、顧客管理システムの画面全体をキャプチャすると、操作対象ではない顧客の電話番号や住所までAIモデルに送信されてしまう恐れがあります。
これに対処するためには、最新の技術動向を踏まえた以下の「多層防御」が必要です。
エッジ側での事前マスキング（Pre-processing）:
画像をクラウドに送信する前に、エッジデバイス（操作端末）側でOCRや軽量モデルを実行し、個人情報パターン（電話番号、メールアドレス、マイナンバーなど）を検出して黒塗りにします。近年のAI-OCR技術の進化により、非定型フォーマットや複雑なレイアウトでも高精度な特定が可能になっています。クラウドAIのPII検出機能の活用:
エッジ側での処理に加え、クラウドサービス側のセキュリティ機能も併用します。例えば、最新のクラウドAI機能では、PII（個人を特定できる情報）検出がコンテンツフィルターとして組み込まれており、入力データに含まれる機密情報を識別してブロックすることが可能です。これにより、万が一のマスキング漏れに対するセーフティネットを構築できます。DOM解析との併用:
画像認識だけに依存せず、HTMLやアクセシビリティツリー（UI Automation）のテキスト情報を優先的に使用します。画像を送信するのは、ボタンの位置特定などレイアウト解析が必要な場合に限定し、テキスト情報はローカルで抽出・フィルタリングしてからAPIに渡すハイブリッド手法が有効です。
参考リンク
技術的統制：誤操作を防ぐ「ガードレール」の設計要件
業務の仕分けができたら、次はシステムアーキテクチャの中に「ガードレール」を組み込みます。これは、AIが意図しない挙動をした際に、物理的に（あるいは論理的に）操作をブロックする安全装置です。
AIエージェントへの権限最小化（Least Privilege）の実装
セキュリティの基本原則である「最小権限の原則」をAIにも適用します。
- ネットワーク分離: AIが稼働するVM（仮想マシン）からは、対象となる業務システム以外へのアクセスをファイアウォールで遮断します。インターネットへのアクセスも、APIエンドポイントなど必要最小限に絞ります。
- クリップボードの監視: AIがコピペを行う際、クリップボードの内容を監視し、正規表現で定義されたフォーマット（例：受注番号の形式）以外のデータが含まれている場合はペースト操作を無効化します。
操作実行前の「確認・承認」プロセスのシステム化
特にLevel 2（入力補助）以上の業務において有効なのが、「承認待ちステート」の導入です。
AIエージェントが画面操作を行い、「送信」ボタンを押す直前で処理を一時停止させます。そして、操作担当者のチャットツール（TeamsやSlackなど）に、以下の情報を通知します。
【承認依頼】
AIエージェントが「取引先への請求書発行」を実行しようとしています。
- 入力金額: 1,000,000円
- 支払期限: 2024/12/31
- [スクリーンショットを確認]
[承認して実行] / [却下] / [修正して実行]
人間が「承認」ボタンを押したときだけ、AIエージェントに再開シグナルが送られ、最後のクリックが実行されます。これにより、AIの利便性を享受しつつ、最終責任を人間が担保する体制を構築できます。
異常検知時のキルスイッチ（緊急停止）メカニズム
AIがループに陥ったり、画面をランダムにクリックし始めたりする「暴走」に備え、外部からの強制停止手段を用意します。
- タイムアウト設定: 1つのタスクにかかる時間が規定値（例：3分）を超えた場合、プロセスを強制終了する。
- 操作頻度リミット: 「1秒間に5回以上のクリック」など、人間ではあり得ない頻度の操作を検知した場合、即座に操作をブロックし管理者にアラートを飛ばす。
- 信頼スコア（Confidence Score）の閾値: AIモデルが提示する「確信度」が一定値（例：85%）を下回る場合は、操作を実行せずに人間にエスカレーションするロジックを組み込む。
監査証跡の確保：AIの「視線」と「操作」をどう記録するか
「AIが何をしたか」を事後的に検証できることは、ガバナンスの要です。従来のシステムログだけでは不十分であり、AI特有のコンテキスト情報を記録する必要があります。
プロンプト、スクリーンショット、操作ログの三点記録
監査証跡として、以下の3点セットを必ず紐付けて保存します。
- Input（入力）: AIに与えられた指示（プロンプト）と、その時点での画面スクリーンショット。
- Process（思考）: AIが画面をどう解釈し、なぜその操作を選択したかの推論ログ（Chain of Thought）。
- Output（操作）: 実際に送信したキーボード入力やマウスクリックの座標データ。
これらがタイムスタンプと共にDBに格納されていれば、万が一の事故発生時に「AIが画面上の『キャンセル』ボタンを『OK』ボタンと誤認した」という原因特定が数分で行えます。
AIの推論過程（Chain of Thought）の保存要件
特に重要なのが2点目の「推論ログ」です。最近のAIモデルは、操作を行う前に「思考プロセス」を出力させることができます。
例えば、AIからのレスポンスとして以下のようなJSONログを保存します。
{
"thought": "画面右下に『確定』ボタンを検出しました。しかし、ボタンがグレーアウトしています。必須項目の『担当者名』が空欄であるためと推測されます。まずは担当者名を入力する必要があります。",
"action": "type_text",
"target": "input_field_name",
"value": "鈴木 一郎"
}
このように「なぜそうしたか」が自然言語で記録されていれば、監査担当者は技術的な知識がなくてもAIの判断の妥当性を評価できます。
ログの改ざん防止と保管期間の法的基準
厳格なコンプライアンスが求められる環境では、これらのログ自体が改ざんされていないことを証明する必要があります。WORM（Write Once Read Many）ストレージへの保存や、ログファイルへのハッシュチェーン付与を検討してください。
保管期間については、各業界のガイドラインに従いますが、AIの学習データとしての価値も考慮し、法定期限よりも長く保存することを推奨します。これらのログは、将来的に自社専用のより安全な「小規模言語モデル（SLM）」をファインチューニングするための資産になります。
継続的なモニタリングとインシデント対応体制
システム導入はゴールではありません。AIモデルの精度変化や対象システムのUI変更に対応し続ける運用体制こそが、長期的な安定稼働の鍵を握ります。長年の開発現場の経験からも、運用フェーズでのアジャイルな改善がプロジェクトの成否を分けると言えます。
モデルのドリフトとUI変更への追随プロセス
AIモデル自体は変わりませんが、対象となるSaaSやWebシステムのUIは予告なく変更されます。これを「環境ドリフト」と呼びます。
これを検知するために、定期的な「ヘルスチェック」を自動実行します。毎朝始業前に、テスト環境でダミーデータを用いた主要シナリオの自動テストを走らせます。もしUI変更によってAIの操作失敗率が上がっていれば、始業前にアラートが出て、担当者がプロンプトや参照画像を修正することができます。
誤操作発生時のロールバック手順と責任分界点
実際に誤操作が発生した場合の対応フロー（Playbook）を事前に策定しておきます。
- 即時停止: 担当者がワンクリックで全AIエージェントを停止できるダッシュボードを用意する。
- 影響範囲の特定: 監査ログから、問題が発生した時間帯にAIが操作した全レコードを抽出する。
- 補正処理: 誤ったデータを修正するためのスクリプトや手動手順書を準備しておく。
また、外部のAIベンダーのモデルを利用している場合、AIの幻覚（ハルシネーション）による損害について、ベンダーは通常免責されています。「最終的な責任はユーザー企業にある」という前提で、保険の加入や引当金の計上といった財務的なリスクヘッジも検討すべきです。
定期的なリスクアセスメントと運用ルールの改訂
AI技術の進化は早いです。半年前には不可能だったことが、今日には可能になっているかもしれません。逆に、新たな攻撃手法が見つかることもあります。
四半期ごとに、セキュリティチームと運用チーム合同でリスクアセスメントを実施し、「Level 2」としていた業務を「Level 3」に引き上げる、あるいは逆に技術向上により「Level 1」に緩和するといったルールの見直しを行ってください。
まとめ：正しく恐れ、賢く使う
「画面を見るAI」は、APIのないレガシーシステムという岩盤を穿つ強力なドリルです。しかし、強力なツールほど、扱いを誤れば大きな怪我をします。
本稿で解説したガバナンスと技術的統制は、決してAIの導入を阻害するためのものではありません。むしろ、これらを実装することで、現場の担当者は「何かあったらどうしよう」という不安から解放され、自信を持って自動化を推進できるようになります。
「ブレーキがあるからこそ、車は速く走れる」。この言葉通り、強固なガバナンスこそが、AIによる業務変革を加速させるエンジンとなるのです。
実際に、これらのリスク管理フレームワークを適用し、厳格なコンプライアンスが求められる基幹業務や受発注プロセスで、安全にマルチモーダルAIを稼働させている事例が増えてきています。まずは小さなプロトタイプから始め、技術の本質を見極めながら、ビジネスへの最短距離を描いていくことが重要です。
コメント