Google Gemini in Chromeの業務利用が広がると、BPO企業にとって本当に難しいのは「使うか、使わないか」ではありません。より重要なのは、応対画面をもとにブラウザ内AIが生成した要約文を、社外持ち出しに当たる情報として扱うのか、それとも業務補助の範囲とみなすのかという情報持ち出し判定です。

この記事では、Gemini in ChromeのようなChromeに統合されたAI機能について、入力内容や対応するウェブページ本文が外部サービスで処理される場合もあることを踏まえ、なぜVDI運用下でも例外申請が増える可能性があるのかを整理します。あわせて、経営層やBPO運用責任者、VDI管理者、情報セキュリティ責任者、コンプライアンス担当者が先に決めるべき判定軸、運用原則、責任分担をわかりやすく解説します。

VDIを入れていても、なぜ「応対画面の要約文」が経営課題になるのか

結論から言えば、VDIは「端末にデータを残さない」統制には強くても、「ブラウザ上で再構成された情報をどう扱うか」までは自動では決めてくれません。BPO企業では、顧客応対画面に氏名、契約情報、問い合わせ履歴、社内メモなどが同時に表示されることが多く、その一部をAIが要約すると、原文とは違う形で意味の濃い情報が生まれます。

ここで難しいのは、その要約文が元データの単純コピーではない点です。一部の既存ルールや運用では、コピー、ダウンロード、ローカル保存、外部メール送信といった明確な動作を前提にしてきました。

しかしChromeに統合されたAI機能は、対応するウェブページ本文や利用者が入力・選択した内容を短くまとめ、別の用途向けに整えられる場合があります。AI支援が作業の流れに自然に組み込まれるほど、この論点は避けて通れません。

経営課題になる理由は、これは現場だけでは線引きできないからです。どこまでが業務効率化で、どこからが機微情報の再生成なのかは、契約責任、委託元との取り決め、監査対応に直結します。つまり、技術導入の話に見えて、実際には情報ガバナンスの再設計なのです。

Gemini in Chromeが変えるのは、コピーではなく再構成の扱い

Gemini in Chromeがもたらす変化は、AI利用が「別の専用ツールを開く行為」ではなく、「普段使うブラウザの中で起きる行為」になることです。これにより、利用者の心理的なハードルは下がります。

現場から見ると、検索、閲覧、要約、書き換えがほぼ連続した操作になります。そのため、申請が必要な処理と不要な処理の境目が見えにくくなります。

たとえば、オペレーターが応対履歴を見ながら「この問い合わせの要点を3行でまとめたい」と考える場面は珍しくありません。そのときAIが、個人名を外しても、契約種別、地域、障害内容、対応経緯を自然な文章にまとめれば、実質的にかなり具体的な顧客像が再構成される可能性があります。

これは原文コピーではないため、従来ルールでは検知や判断が難しくなります。要約や文章生成が日常業務に埋め込まれるほど、従来の複製中心の統制だけでは足りなくなります。

https://workspace.google.com/solutions/ai/

ここで重要なのは、AIが危険だと決めつけることではありません。問題は、既存ルールが「複製」中心で作られており、「抽出」「要約」「再構成」を十分に定義していない点です。

BPOの実務では、禁止対象を増やすほど運用は硬直します。だからこそ、何をもって持ち出しとみなすかを、画面要約という具体例から再定義する必要があります。

経営判断が必要な3つの区分、「要約文」「入力データ」「送信先」

第一の論点は「要約文そのものの扱い」です。応対画面の要約文を、元データとは別の新規文章とみなすのか、それとも機微情報の加工物とみなすのかで、管理レベルは大きく変わります。

BPOでは委託元ごとに求める水準が違うため、案件単位で判定条件を変えられる設計が現実的です。

第二の論点は「AIへの入力データ」です。個人情報、認証情報、自由記述メモ、社内ナレッジを同列に扱うと、現場は迷います。

たとえば氏名や会員番号は不可、製品カテゴリや一般的な障害傾向は条件付き可、といった粒度まで落とし込まないと、毎回申請が必要になります。

https://www.nist.gov/itl/ai-risk-management-framework

第三の論点は「送信先」です。同じ要約でも、閉域の社内補助機能で使うのか、外部SaaSへ送るのかでリスクは変わります。

学習に使われるか、ログ保存期間はどうか、管理者が利用制御できるかといった条件は、法務と情報システムだけでなく、経営レベルで許容方針を持つべき点です。

https://cloud.google.com/responsible-ai

VDI例外申請が増えるのは、現場の問題ではなく判定基準の不足

現場で例外申請が増える一因は、利用者が危険だから申請するのではなく、「判断基準がないので自衛的に申請する」ことです。応対後の記録整理、エスカレーション文面の下書き、FAQ更新の要点抽出など、日常業務にはAIで短縮できる作業が多くあります。

しかし基準が曖昧だと、現場は使うたびに確認を求めます。

その結果、審査部門には細かな申請が集中します。しかも多くは、「個人名を伏せたが契約情報は残る」「顧客文面は消したが要点は具体的」「委託元Aでは不可だが委託元Bでは判断保留」といったグレーケースです。

こうなると、ルール不在を人手審査で埋める構図になり、AI導入で効率化するはずが、管理部門の工数だけが膨らみます。業務設計と統制設計を同時に見直す必要があります。

https://www.cisa.gov/ai

さらに厄介なのは、例外申請の多さが現場の不満につながる点です。「使ってよいのか分からない」「案件ごとに違う」「承認待ちで止まる」という状態が続くと、統制は守られにくくなります。

申請件数の増加は、現場の問題ではなく、経営が定義すべき判定ロジックの不足を示すシグナルと見るべきです。

禁止一覧ではなく、5軸の判定基準で運用する

実務的に有効なのは、「この機能は禁止」という一覧方式だけに頼らないことです。ブラウザ内AIは進化が早く、機能名ベースの禁止はすぐ古くなります。

代わりに、情報の種類、処理目的、送信先、保存有無、監査可能性の5軸で判定する運用原則を作るほうが持続しやすいです。

たとえば、情報の種類では個人識別子を含むかを確認します。処理目的では、応対補助なのか、品質管理なのか、提案書作成なのかを区別します。

送信先では、企業管理下の環境か外部サービスかを見ます。保存有無ではログや履歴が残るかを確認し、監査可能性では後から利用状況を追えるかを問います。

この方式の利点は、現場に判断の物差しを渡せることです。「応対画面の要約文は一律禁止」よりも、「個人識別子なし・社内管理環境・保存制限ありなら条件付き許可」のほうが、業務と統制を両立しやすくなります。

BPO企業では委託元ごとの差も大きいため、標準基準を作ったうえで、案件別の上書き条件を持てる設計が現実的です。

役員会で先に決めるべきなのは、利用範囲より責任の所在

最後に、役員会で確認すべきなのは「どこまで使うか」より先に「誰が責任を持って判定するか」です。情報システム部門は技術制御を担えますが、委託契約との整合、事故時の説明責任、監査受検時の立場整理は経営判断が必要です。

ここを曖昧にすると、現場は使えず、管理部門は止めるしかなくなります。

確認すべき指標も明確にしておくべきです。例外申請件数、承認までの時間、案件別の利用率、ポリシー違反件数、委託元からの照会件数などを定点で見れば、運用が詰まっている場所が見えます。

制度がうまく回っているかは、AIの精度だけでなく、判定負荷が減っているかでも判断すべきです。

https://oecd.ai/

要するに、Gemini in Chrome時代のBPOで先に整えるべきなのは、ツール導入の是非ではありません。「応対画面の要約文」をどう分類し、誰が、どの条件で、どこまで許可するのかという判定設計です。

そのうえで、受託業務画面、社内ナレッジ画面、顧客管理画面の3区分ごとに、ブラウザAIの利用可否と持ち出し判定基準を整理した利用基準表を作成すると、BPO運用責任者、VDI管理者、情報セキュリティ責任者、コンプライアンス担当者の判断をそろえやすくなります。

ここが固まれば、AI活用は進めやすくなります。逆に、ここが曖昧なままでは、例外申請だけが増えます。経営層には、効率化の期待より先に、責任の線引きを設計する視点が求められます。