生成人AIの社内ガイドラインについて
Zeale
はいはい、一応前回僕聞きましたよ。
うん。
なんか割と触りは結構話されてるなっていうふうには思って。
Steve
そうですね。事実5人がないかだけちょっとヒヤヒヤしてたけど。
Zeale
まあまあ、とりあえず、でもそんなことはなさそうだった。
Scott
TimeTree Tech Talk、来何回だろう?もう分からない。
もう早く分かれてますけど。
どうした?
今回はですね、前回はGitHub CopilotとかChatGPTをお仕事で使う時の話っていうんですかね、
どういうふうに使ってますかみたいな話をアンディとしましたけれども、
今回その会社でいわゆるこの生成人AIっていうのを使うにあたって、
まあちょっといろいろ考えないといけないことが多いよねみたいな話は一杯社内でしたんで、
考えないといけないことを話したジールといろいろ話していきたいなと思います。
Zeale
はい。よろしくお願いします。
Scott
ジールです。よろしくお願いします。
Zeale
ジールです。よろしくお願いします。
はい。
Scott
話したけれども今回も。
Zeale
はいはいはい。
僕が何の仕事をしてるかっていうのを軽く話しておくと、
主には組織のシステムっていうところですね。
組織のシステムって分かりにくいんですけど、
常識みたいなところももちろんありますけど、
組織が動いていくための仕組み作りみたいなところを、
エンジニアリングっていう背景を活かしてやっていくっていう仕事をしてまして、
あとそれと合わせてセキュリティみたいなところも一緒に担当しているっていうのが、
一応僕の業務領域になってます。
チャットGPTってとにかくいろんな範囲に影響があるものではあったんですけど、
広範囲に関係するんで、
とりあえず僕がしたほうがいいんじゃないかみたいなことも思って、
いろいろ最初のほうに少し動くことをしてみたっていうところから、
Slackのチャットボットみたいなところも作ってみたっていう流れですかね。
Scott
あれでもそうですよね。結構早かったですよね、できたの。
Zeale
そうですね。みんなもちろんウェブブラウザ上では使ってたりとか、
試してっていうことは結構やられ始めてたと思うんですけど、
一部の人にやっぱりなりやすかったと思うんですよね。
特に好きな人っていうかそういうところが。
ただそういう波が来てるっていうこともそうですし、
どう使ってるのかっていわゆるプロンプトをどういうふうに投げると、
どんな回答が返ってくるんだろうみたいな、
そういう生成AI、特にチャットGPT使ったらこんな感じになるんだみたいなのが、
みんなで分かるといいなと思って。
そういうのもあって、
チャットボット、Slackの中で展開できたらいいよねみたいなのが、
やった経緯なんですけど、
結構早めからもチャットボットを動かせるようにするにはみたいな記事結構出てたので、
僕もそのうちの一つの記事とかを参考にさせてもらって、
やったっていうのが最初なので、
本当そのあたりは動きが速いのに一応僕らもついていったような形かなっていう感じですね。
Scott
結構社内で使うにあたって情報を入力しなきゃいけないと思ってて、
インターフェースがそうなんですけど、
その際にどういう情報を入れていいのか、あるいはダメなのかみたいな判断が、
使う人の各々でやっぱりしなきゃいけないのは大変だなみたいな話があって、
会社でルールを決めましょうみたいな話でジールとか、
ジールは主にGPT、チャットGPTのほうやってくれたのかな。
僕はコパイロットの周りのこと結構いろいろ調べた記憶があるんですけど、
Zeale
そうですね。
コパイロットのほうが先に動いてましたっけね。
あれちょっと順序を忘れてしまったんですけど、
リリースしたのもコパイロットのほうが結構早めから出てたので、
そうですね。
結構動き出しとしては早かったかもしれないですね。
Scott
そうですね。
コパイロットのほうが早く一般にリリースされてた分、
いわゆる問題もいろいろ事例としてあって、
調べやすかったというのはちょっとありましたかね。
社内ですでに個人で課金している人が何人かいたんですよね。
それをちょうどチャットGPTとかの前後ぐらいに、
ビジネスプランみたいなのがコパイロットとかだと出るようになって、
それに合わせてガイドライン定めましょうみたいなことをいろいろ話しなきゃってなって、
いろいろした感じでしたね。
ほぼ平行してGPTの問題というか課題感も出てきて、
同じような感じでリスクについてちょっと似たようなリスクが出てきたので、
同じように考えたところがありましたよね。
Zeale
そうですね。もう観点としては本当に似通っていたので、
チャットGPTというところから入ったのと、
コパイロットというところから入ったのとで、
ガチャンコして一個生成AIというところからガイドラインを作ったというのが今の状況ですかね。
リスクについての考察と対応
Scott
そうですね。
Zeale
あんまり社内においては画像生成系のものはあんまり使われていることはないんですけど、
Scott
ステーブルディフュージョンとか。
Zeale
そうですね。ただそういうのも別にあり得る話ではあるし、
どういうふうに使いたいというふうになるかわからないので、
そこも含めてのところを作ってましたけど、
観点としてはコパイロットのときも説明いただいてましたけど、
どういう情報を入れていいかというところのラインを作ってあげることと、
あとは使うときですよね。
コパイロットのほうとかそうですけど、
情報の区分と管理
Zeale
返ってきた回答を使うにあたってのガイドラインというのかね。
両方向ですよね。
Scott
そうですね。リスクとしては両方向があって、
回避しようのないものもあるんですよね。
通信経路上で漏れちゃうみたいな話とかはコントロールできない領域なんで、
そこも重大なリスクだと捉えすぎてしまうとツールが全部使えなくなってしまうので、
ちょっと諦めなければならないというか、
妥協したこともありましたね。
Zeale
そうですね。
今の私たちの会社で情報を入れるところですね、
どういう感じで考えているかというのはちょっと紹介しておくと、
前回のコパイロットの回でも話出てましたけど、
うちの会社には情報区分というのが3つあるんですね。
一般公開している公開情報と社内情報というところと、
一番重要度が高い取扱い注意情報みたいな3分割になっているんですけど、
この取扱い注意情報って一番上はやっぱり何でも入れていいよみたいに絶対できないよねっていうのはやっぱり、
どこの会社でもそうだと思うんですけども、
勝手に入れてくださいみたいには絶対できないので、
そこはやっぱり基本的にはNGになってきますと。
ただ、ここに関しては都度どういう状況でどういうことをしたいかというところと、
常にリスクのトレードオフみたいなところがあるので、
事前相談して決めていきましょうねっていうのが今のガイドラインになってますね。
社内情報の扱いと環境
Zeale
そのレベルって例えば個人情報みたいなものもありますけど、
会社上の機密情報みたいなものももちろんありますけどね。
そういったものは一旦事前相談なしに入れてはいけないというふうな感じです。
真ん中の社内情報、そこまでは行かないんだけど、
社内情報として外に出しちゃいけない情報っていうのはどうしますかっていう、
ここが結構各社によってもどういうふうに書かれてるかっていうのが、
結構バラバラかなっていうような認識で、
例えばよくあるのは会社専用のチャットGPT環境を作りました、
みたいなのをやってらっしゃる会社さんもいらっしゃって、
そういうところってどうしてるかっていうと結局、
多分裏でAPIを繋いでですね、
学習に使われないような保護をしたブラウザ環境で動くシステムを提供しました、
みたいな感じのやり方だと思うんですよね。
それって結局ホワイトリスト方式で、
この環境だけ使っていいよっていうのを明示するっていうことでやってると思うんですけど、
アプローチしたうちも同じですね、
ここでは社内情報入れていいんだよっていう環境をいくつか提示していて、
そこではOKです。
そこ以外ではちょっと社内情報入れてはいけませんよっていうふうな形でやってます。
Scott
情報を区切ってあると分かりやすいですよね。
情報管理における意識の違い
Zeale
そうですね、そうなんですよね。
一般的にやっぱ情報管理するとき、
やっぱ区分ってないと説明がマジで難しいんですよね。
この区分がないとなんかもう細かい話になっちゃうので、
多分みんな理解できないんですよね。
だからこういうときに効いてくるなっていうのもすごい感じますね。
Scott
あとあれですよね、これが社内情報なのか、あるいは公開情報なのか、
社外記なのかみたいなその辺の何ていうか、
ちょっと難しいところではあると思うんですけど、
そこら辺もちょっとしばらく運用して慣れていくんじゃないのかな、
そういう情報を使うみたいなこと自体がやってる人はいると思うんですけど、
なかなかツールを使うフェーズでやることってあんまなかなかないから。
Zeale
そうですね、何を入れていいか、
そのラベリングをうまくできるかみたいなのが結構永遠の課題みたいなところがありますよね。
どの会社でも多分教育みたいなことをちゃんとしてみたりとか、
結構そういうアプローチってなるのが必要かなという気がしますね。
Scott
あれですかね、e-learningするんですかね。
Zeale
そうですね、そういうアプローチであるとか、
やっぱり迷えばもちろん相談してくださいっていうのは当然ありつつ、
Scott
やっぱり自然とみんなわかるような環境にしていくっていうのが結構大事かなっていう気がしますね。
Steve
なんか幸いタイムツリーって、
エンジニアが半数以上の多い組織じゃないですかね、
なんかそこら辺の組織としての意識ってすごい高い気がするんですよね。
Zeale
そうですね。
Scott
エンジニアが多いからだと思ってるんですけど僕は。
Zeale
そうですね、情報がどういうものかみたいなことのイメージはしやすいですしね、やっぱり。
ただなんて言うんでしょうね、エンジニアは技術的な情報は強いけれども、
逆にバックオフィス系の情報は弱いみたいなこともあったりするので結構ありますね。
コーポレート系の人たちは逆にすごい情報化にきっちり考えてるから、
そっちも強かったりもするので、そこもいろいろありますね。
Scott
確かに確かに。
これがさっき言ってたようにラベリングみたいなのが多分エンジニアとかだと曖昧だったり。
Zeale
そうですね。
エンジニアというか主語がでかいけど多分僕が。
そこが決まりと感覚との間に大きな差があると結構ズレやすくなるので、
そこは結構注意してラインを引くようなことはしてますかね。
Steve
ジールが参考にした事例とか他社の動きって何かあったんですか。
Zeale
これは考えるにあたってはですね、
自社の利用ガイドラインの策定とその参考資料
Zeale
まず自分の方で結構先にどういう観点が必要かっていうところと、
アプローチのイメージはもうできてて、
最終的にこの区分はここまでOKっていう表みたいなのになるっていうのもイメージはできてたんですけど、
ちょうど書こうとしてた時に、
確かダイムさんとかが出してらっしゃったんですよね。
うちではこういう風な利用ガイドラインですよみたいな。
出してらっしゃったのを私たちも見させていただいた時に、
基本的にやっぱり考え方は同じだなっていう風にも思いましたし、
こういう自分たちの方向性とほぼ多分世間的にも同じ方向に行くんだろうなっていうのは確認できたんで、
そこはすごいそこら辺参考にしながらやったかなと思います。
Steve
ダイムさんよかったですね。すごいわかりやすかった。
Zeale
そうですね。わかりやすかったです。
Scott
なんかこういうの公開されてすごくわかりやすくなったっていうか。
僕らも公開してる?してないか。
Zeale
うちは公開はしてないですね。
Steve
しますか。
Zeale
全然問題ないですよね。
人類のイメージとして。
ほとんど同じではありますけど。
細かくホワイトリストがどういうものがあるかっていうのは、
あんまり細かく説明できないかもしれないですけど、
大枠表とかほぼほぼ公開してていいものだと思うし、
みんなで公開し合って参考にし合えればいいですよね。
Scott
そうですね。できればいいんじゃないかなって思いますよね。
海外サービス提供事業におけるGDPR対策
Zeale
結果に影響を与えたってわけではないんですけど、
一応僕らの考え方でもプラスアルファで考えてることとしては、
私たちの会社ってGDPR、要はグローバルでサービス出してるから、
海外の動きとかもちゃんとわかってなきゃいけないと思うんですね。
海外だとGPTにユーザーデータ入れるのでちょっと待ってくれよみたいな話とか、
イタリアで実際に使えなくなったりとかしていた時期もありましたし、
結構そういうユーザーデータをそこに預けることの適切さみたいなことは、
まだ結構危険視されてる部分もあるので、
それはなので合わせて考えておく必要はある。
現段階で何かするってわけではもちろんないんですけど、
今後何か活用したいときにそこの視点を忘れないようにしないといけないってのはありますかね。
やっぱりこういうちょっと世の中変わっちゃうような技術ができちゃうと、
法が追いついてない部分は当然いっぱいあるし、
現行の法と適合してないところってそういうふうになるので、
利用のときも当然著作権の話とかに関係してくるっていうのもありましたけど、
本当どういうふうになっていくかわからないので、
常にやっぱりこう状況見ながらアップデートかけていくみたいなのは前提なんだろうなというふうには思ってますね。
Scott
それでは今回は生成AIの利用ガイドラインについてジールをお招きして話しました。
ジールありがとうございました。
Zeale
ありがとうございました。