社内プロンプトインジェクションという生成系AIリスク
生成系AI（GAI：Generative AI）が非常に面白いだけでなく、業務にも役立つことが徐々に認識されてきています。以下では、生成系AIならではの特性と、それを活用する三井化学株式会社の事例を取り上げました。
生成系AIの業務導入事例が増えている一方、利用による情報漏洩リスクも指摘されています。そこで単純に利用禁止にすると活用を進める他社/他者に「取り残されるリスク」になるため、両方を解消する自社用生成AIツールの整備に向かう動きも出てきています。この周辺で見落とされがちかなと気になっているのは、まずこれには活用や生産性向上だけでなく「野良利用リスク」の抑制という視点があることで、こちらの方が緊急の課題とも言えます。もうひとつは自社用生成AIツールを整備すれば万全ではなく、そこに社内情報漏洩リスクという古くからの課題があり、プロンプトインジェクションといった新しい攻撃手法があるという視点です。
従業員からChatGPTへの情報漏洩リスク
サムスンではOpenAI社のWebツール「ChatGPT」に非公開の自社ソースコードや会議議事内容が入力される事態が3件起こり、ChatGPTでは入力情報を学習用として機械処理したりエンジニアが確認する可能性があると利用規約に明記されているため、情報漏洩とみなされました。
Samsungの半導体事業などを担うDS部門において、3月11日にChatGPTの使用を許可。その後、約20日間で少なくとも3件の事案が発生したという。内訳は、設備情報の流出が2件、会議内容の流出が1件。（略）1件目が、半導体設備測定データベースのダウンロードソフトに関するエラーを解消するため、ソースコードをChatGPTに入力して解決策を問い合わせたもの。2件目が、歩留まりや不良設備を把握するプログラムに関するソースコードをChatGPTに入力し、コードの最適化を図ったもの。3件目が、社内会議の録音データを文書ファイルに変換後、ChatGPTに入力し、議事録を作成したものだという。
セキュリティソリューションを提供するCyberHeavenは「ナレッジ ワーカーの9.3%が職場で少なくとも 1 回はChatGPTを使用してみたことがあり、7.5%がそれにデータを貼り付けたことがあります」「従業員がChatGPTに貼り付けるデータの11%を機密データが占めます」と指摘しています。サムスン社に限らずあちこちでおきているはずということになりますが、実際にAmazonも「ChatGPTの回答例の中にアマゾンの内部データと類似しているものが見つかった」ことを理由にChatGPTの利用を禁止しています。
他にはApple、Accenture、Verizonといったテック企業やBank of America、City Group、Goldman Sachs、Wells Fargo、ドイツ銀行といった金融機関なども禁止しています。日本でもNTTドコモが明確に禁止しているなど、Jitera社による3月末の調査では、ChatGPTの利用ルールがある企業は約1割、そのうち約62％（つまり全体の6％強）は全面禁止または部分的禁止との数字が出ています。またWHITE社は4月21日に「ChatGPTの利用を禁止する企業は16％」と発表しています。
リスク回避が生む「取り残されるリスク」
ここでまず一つ注意したいのは、これらは生成系AIをすべて業務から締め出したわけではないという事です。「3つの“ChatGPT”」問題として整理したように、以下のうちどれを禁止し、どれを活用するのかを先進企業は並行して検討しています。
生成系AIモデル。テキストを生成するGPT-4や画像を生成するDiffusion Modelなど、AIそのもの。
生成系AIサービス。OpenAI社が提供するGPT-4などのAPIや、Microsoft社がAzure OpenAIサービスの一部として提供するChatGPT APIなど。
生成系AIツール（アプリケーションやサービス）。テキスト生成により応答するChatGPTやStable Diffusionを組込んだ画像生成サービス。
サムスンは上記の事故を受けて、ChatGPTの利用を最終的には禁止した一方で、「イノベーションセンター管轄で社内専用のAIサービスの構築を検討」するという選択をしました。社外の生成的AIツールはシャットアウトした一方で、生成系AIモデルを自社内で動かすという事です。
国内では、デジタル庁が現在のChatGPTでは要機密情報の取扱い不可などの申合せを交わしていますが、この対象はChatGPTというツールです。一方で農水省は先頭を切ってChatGPT活用へと報じられていますが、こちらはAzure OpenAIサービスにより生成系AIの能力を活用しようとしています。民間ではベネッセホールディングス、パナソニック、大和証券、三井住友銀行などがやはりAzure OpenAIサービスをベースとした自社用の生成系AIツールを選択しています。
例えばこちらのnoteを参考にSlidesGPT（ChatGPTベースのツール）に「Differences between SaaS and ASP」と指定してスライドを作成させ、和訳も用意してみました。SaaSでもあるMicrosoft 365がASPの例に挙げられているなど怪しいところもありますが、スライド全体の構成としてはよくできていると思います。文書作成にテンプレートを使うことは多いと思いますが、説明内容と対象に合わせて作りこんだテンプレートが提供されるのだと考えると、盛り込む視点と流れが整理されたところからの作業というのはスタート地点が大きく違ってきそうです。
こうしてみると、生成的AI活用を進める他社/他者に対して、生成的AIを利用しない（禁止する）選択には「取り残されるリスク」を覚えずにいられません。
「野良利用リスク」と自社用生成系AI
自社用の生成系AIツールに取り組む企業背景には、「生産性」とその裏返しである「取り残されるリスク」の他に、安全な生成系AI利用方法を提供しなければChatGPTなどの社外ツールが使われるリスクを防げないという危機管理意識も見えます。
河野氏はChatGPT利用者の多さを念頭に置いた上で、「もし全社導入しなければ、社員が自分のPCやスマートフォンからひっそり利用するリスクが増す。そうなれば情報ろう洩など予期せぬリスクが高まりかねない。これを低減できるのが、全社導入の大きなポイントの1つだ」と説明した。
この記事では、引用文を含む一説に「『野良ChatGPT』を防ぐ」という小見出しをつけています。一般的なセキュリティ用語でいえば「シャドーIT」「ローグ（野良）クラウド」と呼ばれる問題で、現場が必要と感じているITを利用禁止したり調達に協力しなければ、現場は（しばしば全社ガバナンスから外れた形で）それを自分たちだけで調達して使い始めると言われます。現場はより強く「取り残されるリスク」を感じていることを忘れるわけにはいきません。
「生成系AIツールを制限する」ことと「生成系AIサービスまたはモデルを安全に使う公認の方法を示す」こと、この両方を行うことが現在の中心的な企業対応だと考えられます。前者、利用の制限については2月時点でソフトバンク、LINE、ヤフー、リクルート、KDDI、GMOなどがChatGPT個別のガイドラインはないが外部クラウドの利用規定など既存ルールで対応の範囲内とコメントしており、多くの企業が同様だと思われます。その意味では元から利用はフリーハンドではないと言えます。そして後者、利用を前提としたガイドラインの策定や自社用環境の整備に先行企業は取り組んでいます。
社内情報漏洩リスクとプロンプトインジェクション
生成系AIサービスの利用を認める場合、またはこれをベースに自社用生成系AIを整備する場合、どちらの場合も利用方針をまとめ利用ガイドなどにまとめることになるでしょう。現時点では、日本ディープラーニング協会（以下JDLA）の「生成AIの利用ガイドライン」が検討の観点や作成の参考として役立ちそうです。自社で生成系AIモデルを持ち、自社資産上で動かし、社内提供するのであれば、プロセスはよりシンプルになるでしょう。
では自社用生成系AIがあれば、安全に生成系AIを使えるでしょうか。私には、プロンプトインジェクションの問題が気になっています。
ここでいうプロンプトは生成系AIに対して利用者が投げる指示や質問文ですが、プロンプトインジェクションはうまく「ひっかけ」るプロンプトを投げて本来得られない回答を引き出すことです。例えば、Microsoftの「あたらしいbing」と通称されるチャット機能は、このひっかけによって「内部的な愛称はSydneyだがユーザーに名乗ってはいけないこと」などをうっかり漏らしてしまいました。これは微笑ましい例ですが、次のような例もあります。
ChatGPTは公開情報であってもEメールアドレスなど個人情報の開示を意図したプロンプトを拒否するフィルター（Guardrail）が実装されており、ストレートにEメールアドレスの開示を要求した場合、これを拒否する仕組みとなっています。しかし、このGuardrailはプロンプトを工夫することで容易にbypass（迂回）できることが知られています。（略）どうでしょうか。ChatGPTはEnron Corporation従業員のEメールアドレスを氏名と共に大量に開示しました。
すでに自社用生成系AI環境を整えているパナソニックコネクトで、もっとも多く寄せられている要望は「社内データを使いたい」だそうです。企業内には一般に、ある階位以上の従業員しか見てはいけないデータ（情報）があります。ある部門が顧客とNDAを結び、特定の従業員しか見てはいけないという条件下で入手する情報もあります。Eメールアドレスなどは、個人情報保護法による収集目的外に使わないといった制約によって、一件ごとに閲覧できる人が異なるかもしれません。「自社用生成系AI」を準備すれば安全で、社内情報を学習させても平気でしょうか？
JDLAの「生成AIの利用ガイドライン」やトレンドマイクロの「ChatGPTのセキュリティ：法人組織がChatGPT利用時に気を付けるべきこと」などの記事を見ていったとき、社内と社外の間での境界線防御のみが取り上げられているのが気になっています。社内でも情報には閲覧許可範囲があり、それをこえて閲覧されれば社内ではあっても情報漏洩です。そして現在のところ、なにかしらのガードレールを設けたとしても、まだどれだけ新しいプロンプトインジェクションの手立てが生み出されるか予測のつかないところです。
いまできる社内プロンプトインジェクション対策
繰り返しますが、「生成系AIは利用不可」とするだけでは、おそらく野良ChatGPTのリスクを増やすだけです。自社用生成系AIに機密情報の入力を禁止したら、OpenAI社のChatGPTに機密情報を貼り付けるかもしれません。野良ChatGPTを防ぐには自社用生成系AIと喝破したパナソニックのように、生成系AIニーズを禁止するのではなく先回りして好ましい形で満たすことが有効だと思われます。
実を言えばこの問題も新しいものではなく、社内検索エンジンが既に経験し、検討してきたものです。例えば、検索エンジンのサーバー（インスタンスまたはインデックス）自体を、部署や部門ごと、文書の閲覧権限ごとに分けるといった手段もあります。より高度には、利用者を認証し、利用者の認可範囲で検索結果をパーソナライズさせるといった手段もあります。後者は、サーバーごとに重複して情報を取り込ませる必要がなく、誰が利用しても最大限広範囲の情報源から結果を返させられるので、より有用です。
これを自社用AIツールに適用するなら、学習させる情報を閲覧権限ごとにモデル自体を分けるという手段は、すぐにでもできそうです。もう一つ、私が興味を持っているのは検索拡張生成（RAG：Retrieval Augmented Generation）です。この手法は、以下のブログ記事で知りました。
簡単に言えば、生成系AIに直接相談する（プロンプトを投げる）のではなく、まずエンタープライズ検索にクエリをおくります。ここでは具体的にはAmazon Kendraですが、こうしたエンタープライズ検索は利用者の認証と利用者の認可範囲での検索結果提示といったパーソナライズ機能を持っています。
ユーザーがコンテンツを検索するとき、組織はユーザーがアクセス権を持つ検索結果のみを表示したいと考えるものです。組織は AWS Single Sign-On (AWS SSO) の ID ストアと Amazon Kendra を組み合わせて、ユーザーのコンテキストフィルターを使用できるようになりました。ユーザーのコンテキストフィルターの使用により、組織はユーザーがアクセスできるコンテンツのみを表示させることができます。
利用者が閲覧権限を持つ情報からのみからの検索結果を取得してから、その検索結果について生成系AIに要約を行わせ、回答させるわけです。エンタープライズ検索がすでに解決している問題は、現時点ではひとまずエンタープライズ検索に任せてしまうことが実績のある解決策になるというわけです。
まとめ
「ChatGPTの利用禁止」企業がいくつもある一方で、「生成系AIの活用」企業や組織も多数あります。その潮流をまとめるならば、以下のようになると思われます。
画一的な利用規約とそれへの同意で利用する社外の生成系AIツール（ChatGPTなど）は利用を制限ないし禁止する。
野良利用（シャドーIT）を避けるため、自社用生成系AIツールを整備する。
社外の生成系AIサービスを使う際の利用方針（適切なNDAや入力情報の不使用条項を結べるなど）を定め、その方針に沿って自社用生成系AIツールや事業で使用するサービスを選定する。
社外生成系AIツールの利用禁止は、クラウドサービスの利用ガイドラインなどが既にあればそれを適用可能と思われます。適切な社外生成系AIサービスの利用方針は、JDLAの「生成AIの利用ガイドライン」などが参考になりそうです。そして自社用生成系AIツールの整備は、生成系AIによる生産性向上と情報漏洩のリスク低減に役立つ、重要な取組と考えます。これにも社外生成系AIサービスがベースとして利用でき、実際に広く利用されています。
ここで自社用生成系AIツールでは、社内でも情報閲覧は無制限ではない、権限考慮が必要という論点が見落とされがちになっていると思われました。ただし、だから自社用生成系AIツールを作らないという事ではなく、作るためにはどうすればいいかという観点で検討を進めるべきと考えます。その一案として、検索拡張生成（RAG）を紹介しました。
生成系AIの到来は、VUCA（変動性、不確実性、複雑性、曖昧性）そのものの状況の一つだと思われます。生成系AIには関わるべきではない（全面禁止）という悲観方向の思考停止では変動性に、自社用生成系AIを整備すればOKという楽観方向の思考停止では不確実性に、どちらもVUCAに飲み込まれそうな危うさを感じます。生成系AIの波に乗ることを前提に、リスクは何か、対策は何か、チャンスは何か、施策は何か、思考と試行を止めることなく乗りこなしていければと思います。
この記事が気に入ったらサポートをしてみませんか？