なぜ、ウチの企業でも「生成AI利用規程」が今から必要なのか？

記事執筆の背景

中小企業では「生成AIの社内規程なんて必要？」「既存のルールで足りるのでは？」という声がまだ多いのが実情です。しかし、生成AIは今後“使う・使わない”を問わず業務のあらゆる場面に入り込みます。特にブラウザエージェントAIの登場により、筆者としては、企業の認識より早く、そして静かに生成AIが普及する感覚を覚えました。そのような中、もはや企業は生成AIに関する規程を持たない無防備ではいられないと思い、本記事を執筆しました。

これまでの生成AI利用規程の3つの方向性

社内で生成AI利用規程を整備しようとしても、まだ参考になるサンプルは多くありません。ただ、これまで各社の生成AI利用規程を見ていると、その方向性は大きく「活用型（クリエイティブ）」「中間型（マネージド）」「禁止型（クローズ）」の三つに整理できます。多くの企業の生成AI利用規程は、このいずれか、もしくは複数を組み合わせた形になっていると考えられます。

まず活用型は、従業員による生成AIの利用を広く奨励し、創造的な活用を促進することが目的です。生成AI活用プロジェクトや改善チームの設置など、攻めの施策を規定しつつ、「原則OKだが、この使い方だけはNG」という例外禁止の構造をとるのが特徴です。

これに対して中間型は、特定の事業課題に紐づいた「入力データ」と「出力の利用方法」をあらかじめ設計し、その計画を確実に実現することを主眼とするものです。導入目的に沿ったガイドラインを中心に据え、「このデータと、この使い方だけ許容し、それ以外はNG」とする、比較的コントロールしやすい構造になっています。

ブラウザエージェントAIが変える“無自覚利用”の日常

近年注目される技術として、ブラウザエージェントAIがあります。従来のChromeのように単にWebページを表示するのではなく、ページのDOM（Document Object Model / ドキュメント・オブジェクト・モデル）情報や視覚的な画面内容を生成AIがリアルタイムで受け取り、解析・操作まで行える点が特徴です。ユーザーは単にWebを閲覧しているつもりでも、裏側では生成AIが常時作動している状態になります。今後、Comet・Atlas・Gemini搭載ブラウザが普及すれば、2026年頃には「ブラウザ＝生成AI」という環境が当たり前になるでしょう。そしてそのとき、企業の従業員は無自覚のまま重要な社内システムにアクセスし、機密情報がAIへ送信されるリスクと隣り合わせになります。

ブラウザエージェントAIが取得している情報についての補足

ブラウザエージェントAIの入力情報は、大きく分けて2種類のデータを組み合わせたものです。

1つ目は構造データです。ウェブページのHTML/DOMから抽出される情報で、「どこにボタンがあるか」「どのフィールドに入力できるか」といった要素の種類、テキスト、属性などが含まれます。Chromeを開いて、右クリックし、「検証」を選択して、Elementsタブに表示されるものになります。特にアクセシビリティツリー（ブラウザが内部で持つ、要素の意味的な情報）が重要で、これによりクリック可能な要素や入力フィールドなどを正確に識別できます。

2つ目は視覚データです。ページのスクリーンショット（画像）を取得し、人間が見るのと同じように「ボタンがどこに表示されているか」「レイアウトはどうなっているか」を把握します。

この2つを組み合わせることで、「構造的に何があるか」と「視覚的にどう見えるか」の両面から理解し、人間と同じようにウェブサイトを操作できるようになります。簡単に言えば、プログラマーの目とユーザーの目を同時に持っている状態です。

営業・経理・総務で起こる「気づかない生成AI利用」

最近登場したブラウザエージェントAI（Atlas・Comet 等）は、ウェブ上のペイウォールを回避し、会員限定記事を自動取得する事例が報告されています。 同時に、社内SaaSにアクセスしてDOMやセッション情報をAIが読み取り、機密データをプロンプトとして外部に送信してしまう“無自覚利用”リスクも顕在化しています。要するに、ブラウザエージェントAIはブラウザを通じて、ユーザーがアクセスした先のウェブページに関する情報を随時受け取ることになります。
ブラウザエージェントAIが普及する→業務でSaaSにアクセスする際に、エージェントAIにアクセス先のデータが渡る→生成AIに無自覚のうちに重要データを渡している。という構図が生じるわけです。

このようなリスクは様々な場面で発生し得ると思われます。ブラウザを通じて、顧客名簿にアクセスするとき、自社の会計システムにアクセスするとき、採用活動で面接者のデータにアクセスするとき、現在のクラウド時代においてはほぼ全面においてかかわるリスクと言って差し支えないように思われます。

ブラウザに生成AIが組み込まれることで、どのレベルの企業でも生成AI利用規程が必要となった

ブラウザエージェントAIの普及によって、インターネット上で見ている情報のほぼすべてが、生成AIに渡り得る──今は、そんな構造へと急速に移行しつつあります。こうした状況下では、「生成AIは危険だから禁止すればいい」という判断は、もはや現実的ではありません。利便性が高まり、主要なブラウザが次々とAIを標準搭載する流れの中で、ブラウザそのものを禁止することは業務そのものを止めるに等しいからです。

むしろ、企業のトップとして求められるのは、先に示した「活用型」「管理型」「禁止型」のどの姿勢で生成AIと向き合うのかを明確にし、その前提で従業員が迷わず行動できるルールを用意することです。結局のところ、企業規模を問わず、ブラウザを利用する以上は生成AIとの接触を避けられません。であれば、従業員がどこまで使っていいのか、何を避けるべきなのかを示す“生成AI利用規程”は、どのレベルの企業でも不可欠な備えとなりつつあります。

生成AI利用規程と専門家との協同

本記事では、ブラウザエージェントAIの台頭により、企業が生成AIと関わらざるを得ない状況になりつつあること、その中で「どのようなスタンスで生成AIを扱うのか」を定める生成AI利用規程が重要になっていることを見てきました。また、従来の社内規程が「活用型」「中間型」「禁止型」といった方向性に整理できることも確認しました。

では、そのような生成AI利用規程を外部の専門家とともに整備する際、どのような関わり方が望ましいのでしょうか。筆者としては、従来のように“その時だけスポットで相談して終わる”関与ではなく、継続的な伴走関与を前提に考えた方がよいと考えています。プロダクト開発がウォーターフォールからアジャイルへとシフトしたように、生成AIの分野も技術の進歩と環境変化のスピードが極めて速く、一度作った生成AI利用規程がすぐに現実とズレてしまう可能性が高いからです。

例えば、Cometなどのブラウザエージェントが登場する前提を置かず、「会社が認めていないモデルの利用を禁止する」という方針だけで作られたポリシーを想像してみてください。その後、業務の利便性から従業員の側でCometの利用ニーズが高まり、なかには無断あるいは無自覚のまま利用してしまうケースも十分に起こり得ます。そうすると、形式上は「禁止」となっていても、現場の実態とかけ離れた“形骸化した規程”になりかねません。

このように、生成AIを取り巻く状況は短期間で大きく変化します。だからこそ、専門家と協同して生成AI利用規程を整える際には、「一度作って終わり」の文書ではなく、技術動向や現場の実態にあわせて継続的にアップデートしていく前提のスキームづくりが重要になってきます。規程そのものだけでなく、「誰が・どのタイミングで・どのように見直すのか」というプロセスまで含めて設計しておくことが、これからの生成AI利用規程の肝になると考えています。

まとめ──生成AI利用規程は「守りの備え」から「攻めと守りの両立」へ

ブラウザエージェントAIの普及は、企業にとって「生成AIを使うか・使わないか」という選択の余地を奪いつつあります。従業員がブラウザを開いた瞬間、すでに生成AIは作動しており、社内システムへのアクセス情報がAIに渡される──そんな環境が、すぐそこまで迫っています。

このような状況下では、「生成AIは危険だから禁止」という方針だけでは、現場の実態とかけ離れた形骸化した規程になりかねません。むしろ重要なのは、自社が「活用型」「中間型」「禁止型」のどのスタンスで生成AIと向き合うのかを明確にし、従業員が迷わず判断できる具体的なルールを示すことです。

さらに、生成AI技術は短期間で大きく変化するため、規程は「一度作って終わり」ではなく、継続的にアップデートしていく前提で設計する必要があります。専門家との協同においても、スポット相談ではなく伴走型の関与を検討し、「誰が・どのタイミングで・どのように見直すのか」というプロセスまで組み込んでおくことが肝要です。

企業規模を問わず、生成AI利用規程はもはや「あったほうがいい」ものではなく、「なければ無防備」な時代に入りました。技術の進化を味方につけながら、リスクを適切にコントロールする──その両立を実現するために、今こそ生成AI利用規程の整備に着手すべきタイミングと言えるでしょう。