Mika Ueno
例えばそのGNUのライセンスで出てるものって、コードの一部だけ使うっていうのってあるんですか。
例えば、パターン、プログラムを丸ごと使うと、あれこの動きはって推測できるかもなんですけど、一部のものを、例えば一部のここの関数のものを使いましたって言ったら、
外から見た時って想像多分できない。動きの中でそれを判断できるのかなと思うんですけど、その辺ってどうなんですか。
Takuya Oikawa
でもその通りなんで、バレなきゃわかんないっていうのはオープンソースに限らず全てそうですね。
ソースコード公開してないものがたくさんあるわけじゃないですか。そうするとそれは全然わかんないですね。
Nobuhiro Seki
今のまさに、例えばすごい基礎的なものとかあるじゃないですか。すごい単純に1から100までカウントしますみたいなやつとかって。
それに著作権ありますかみたいな、そういう話になってくると、どこまでがその著作権として保護できる著作物としてのものなのかみたいな話は多分あんまり線引きできない。
できないというか難しいんじゃないですかね。ただ、著作権の話をするとすごい日本とアメリカでも法律が違ったりしてですね、結構難しいのはありますよね。
日本だと人格権が放棄できないんですか。
Takuya Oikawa
そうですね、著作人格権放棄できないですね。
Nobuhiro Seki
完全に権利として分離してなかったり。僕も自分のこの話をモロにしてたのは15年くらい前なんで、あんまり覚えてないんですけど、そういういろいろありますよね。
Mika Ueno
コードとかって本当に洗練されていけばいくほどすごいシンプルになっててっていうイメージがあるんですけど、
本当にコードの著作権って発想したときにね、そんなんあんのと思ったんですけど、あるっちゃあるけど、あんまり現場とかではそれは気にせずに皆さんやってるってことですよね、コーディングもね。
Nobuhiro Seki
気にはしてないとまずいんじゃったと思いますけどね、さっきの話で。
Mika Ueno
そうそうそう、いいやつとかね。
Takuya Oikawa
どこまで意識にするかあれですけど、例えば、住宅開発していて、納品した場合って権利は全部納品先にあるんですよ。
で、ほぼほぼ同じようなことをもう一回書くっていうのをまた別のお客さん向けに書いたりするときに、そういや、前この処理書いたわっつって、社内でそっちのプロジェクトからレポジトリから持ってきてコピペしてっていうのは厳密に言うとアウトなはずなんですよね。
Mika Ueno
そっか、お客さんに権利をつってるから。
Takuya Oikawa
そうですそうです。でもそれを意識してる人は少ないんじゃないかな。大胆にこのライブラリ全部そのまま利用しようって言ったときには多分会社の中でそこ厳密に決められてると思うんですけれども、ほぼ自分の頭の中に入っているようなものじゃないですか。
さっき関さんが言ったみたいに1から10までカウントしろみたいなやつっていうのは、これも多分著作権の範囲なんですけれど、そこまでシンプルじゃなくても、なんか前やったぞっていうので頭の中にあってもう一回書き直すってことをやってもいいんだけれども、そういやこの間のお客さん向けに書いたなとかっていうのを使いたいとか。
AIだと多分そういうのは全部学習されて残っちゃってるかもしれないわけ。エディターの中の履歴としてっていうのが出てくる可能性はあるんでしょうね。でも厳しいところはそういうところもちゃんと何をやっていけないっていうのは多分会社で否定されてると思います。
Nobuhiro Seki
うちのソフトウェアがあってパートナー企業がプラグイン書いてるとかするじゃないですか。プラグインを書くまではいいんだけど書いたものをバンドルして出すみたいな時とか、あとはソフトウェアライセンスしていてライセンシーの人がそのコードに対してコードを書いてもいいですよみたいな権利を渡すときにその変えたコードの著作権はどうなるのかみたいなやつ。
そういうふうに変えたものはオリジナルの著作権に著作権が帰属しますとか、そういう契約書をひたすら書いてレビューした記憶があって、誰がどこに帰属するのかって今言ったみたいに立ち位置とどっちがコントリビュートしたのか、そういったものも大きさとか規模とかインパクトとかによっていちいち定義しておかないと。
そこまで何回も見てどっかに漏れがないか。漏れてるとそれを使って後から、「いや、ここはうちが作ったんで、まさにコピペして他のやつに使います。」って言えちゃうんですね。
そうならないようにそこで書いたものとかを保護するみたいなことで契約書に縛るみたいなことをすごい知ってましたね。
そのときにさっき言ってた、この契約書はアメリカの戦略権とかそういった権利をベースにしてますとか日本にしてますとかによって、会社が変わったりするんです。だからそれも結構気をつけてやってましたね。
守られる権利とか違ったりしてたような気がするんですね。だからそういうのも気をつけてやってました。
今思うと、僕の仕事の3,5年中はそういうのやってたなと思いました。
Mika Ueno
画像とか映像とか音源の著作権とかって、一回弁護士の仕事上とかでお話したことがあるんですけど、やっぱり心配じゃないですか。
作る側としては、あとお客さん側としては、これ大丈夫なんですよねみたいな感じで、納品されるお客さんとしては、お住み付けが欲しいわけですよね。
ここ絶対大丈夫みたいな。でも絶対大丈夫とお住み付きは、弁護士の先生も開口一番、何を切りされてますかみたいな感じで聞かれて、お住み付きは残念ながらできないんですよ。
著作物っていうのは何かを作った時点、書いた時点で、もうその時点で著作権発生するものなので、それを全部網羅した全地球上のデータベースっていうのはありませんよという話になって。
それは作り手側とかもいろんな方法を含めて、これはここと類似性がないですね、これは2でないですねっていうようなことを作る過程とかでも意識しながらやっていってっていう話になって、そうだよなと思って。
もしそれがオマージュみたいな形であるならば、著作権者の人たちにこれをすごく意識してリスペクトも込めてやっているのでっていう話をしながら進めていくっていうのは解決策じゃないですかみたいな例を出してくれたりとかしていましたけどね。
Nobuhiro Seki
昔だからクリエイティブコモンズライセンスをどう使うかみたいな話をよくしてたんですけどね。
Takuya Oikawa
いやーでも今オープンソース使ってないところはないと思いますよ。
使わないと作れないんですからね。
完全に使わないってことはまずないんじゃないかな。
簡単なものとかだったらともかくそれなりに複雑なものを書くときに全く使わないとあまりないと思いますよ。
Nobuhiro Seki
ソフトウェアボムってSボムってやつがあって、権利関係だったり、あとは脆弱性が発見されたときにそれをアップデートするとかっていうようなことをちゃんと管理してるのが多いと思います。
Sボムっていわゆる部品表のボムのソフトウェアがあるってこと?
Takuya Oikawa
そうですです。それのソフトウェアです。
いや多分計算書とかIPAとかそういうのかなりいろいろガイダンス出してると思いますよ。
Mika Ueno
Sボムはソフトウェアビルオブマテリアスの略なんですね。
Nobuhiro Seki
ガイデンはもっと古いんですね。
Takuya Oikawa
そうですね。だけどよく言われるようになったのは、2,3年ってことはないけれど、10年、10年いかないかな。
でも5年前にはもう楽にありましたよ。普通に相談受けましたから。もっと前だろうな。
Nobuhiro Seki
これもボムなんて言うんでやっぱり、言い方悪いけど、下請けから上に納品するとかそういうことを意識してる感じなんですね。
Takuya Oikawa
でもそれだけじゃないと思いますよ。下請けかどうかは別にして部品表みたいなものですよね。
Mika Ueno
コードプロでもやったわ。
Nobuhiro Seki
昔だとやっぱり一社のフレームワーク上とかで動かすから、ボムって言うとやっぱり部品とかを調達するって印象あるじゃないですか。
だからあんまりそういう風にソフトウェアの開発ってなる印象がなかったので。
Takuya Oikawa
でもそれは違うかもしれない。よく考えてみたら、例えばウェブ企業でAWSとかAzureでっていった場合、
オープンソース部分も各社のパブリッククラウドのAPIになっていたりするから、
自分でここまでボム管理をしなくても済むと思うんですよね。
Mika Ueno
そうですね。
Takuya Oikawa
脆弱性があったら勝手にアップデートしてくれるっていう状態だから、
もちろんやっぱりクラウドじゃない、自分でちゃんと管理して必要なら更新してってことをやらなきゃいけない、
組み込みとかの方に特にやっぱり意識しなきゃいけないものの可能性はあるかもしれないし、
要はマネージドじゃない、いわゆるそういったでかい企業のマネージドじゃない状態のところに対して自らコントロールしなきゃいけないと。
だから自社でオープンソース持ってきてもいいし、
そういったサプライヤーからソフトウェアだけでもいいし、ハードウェア込みで納品されたときにっていうのを全体でかなり複雑な部品構成になるところをやっぱり管理するっていうところなんで、
さっき関さん言ったのがある意味正しいんですね、やっぱ。
Nobuhiro Seki
自動車業界でパッと追いつきますもん、もっともって。
Takuya Oikawa
そうですね。
Nobuhiro Seki
そういう意味で言うとBOMっていう考え方のほうが、彼らの中ではしっくりきたのじゃないかなっていうんですけど。
Mika Ueno
クラウドがベースに考えちゃいがちですけど、自分がいる業界がそうだから、そうじゃないものが多いですもんね。
Takuya Oikawa
だからやっぱり普通に、今MacとかWindowsとかで使うやつ、スマホとかで使うやつも、どんなオープンソースを使ってるかって中に書いてあることが多いと思うんですよね。
それはそのいわゆるライセンス的に書かなきゃいけなかったりとか、書かなきゃいけなくないとしても書いたりしてるとこあるけど、一方であれって一種のSBOM状態になってることだと思うんですよ。
で、さっきから言ってみたクラウド側だったらそっちで勝手にアップデートされてるかもしれないけど、クライアント側に埋め込まれてるものっていうのはやっぱり誰かがちゃんと新しいライブラリにアップデートしていかなきゃいけないんですよね。
例えばスマホとかでもローカルにデータを保存するためにデータベースを入れようってなったらSQLiteって言われているものを使うっていうのはあるんですよね。
で、このSQLiteもオープンソースだからSQLiteのバージョンいくつを使ってるかっていうことを意識して、もし特定のバージョンに何かの脆弱性が見つかったってことがわかったら、
その組み込まれているクライアント側のSQLiteをアップデートしなきゃいけないとかってありますから、そういうのがたくさんあった場合にやっぱり何かの形で台帳みたいなのがあって、常にそれを確認してっていうことをやれるといいんだと思うんですよね。
Nobuhiro Seki
なんかそれだけ聞くとSBOMとかってYAMLで書いてるしとか思ったりするんですけど、そういう頃もですね。
Takuya Oikawa
いや、どうなんだろうな。
でも今言いながら思ったのが、そういうのもレポジトリ側で管理してくれることが多いんで、自社で全部やっぱり作ってるんだったならば、それこそGitHubにボーンとコード乗っけといたらGitHubってセキュリティアラートとかって出してくれるようになってますから、
この特定のオープンソースにこういう問題があったから直しなさいって言ってくれるんですよね。
やっぱりさっきの関さんの話に戻るけれども、納品されるものっていうところの方がより自社でコントロールしにくいからSBOMみたいな、そういった仕組みが必要なんだと思いました。
Nobuhiro Seki
今ね、SBOMを調べてたらですね、SBOMの現在一般的にはSPDXとサイクロンDXの2つの企画が主流となっています。
このページに書いてあることは確かにわかるんですけど、ファイルとはテキストやJSONなどどんなファイルフォーマットを使うかという話ですが、
主にテキスト、JSONやXML、YAMLなどがあります。
SBOMはただのリスト、ただのビルですので、プログラム言語構文レベルの表現力は必要ありません。
Mika Ueno
ああ、そうなんだ。本当にリストでいいんだ。
Nobuhiro Seki
だからインベントリ管理に近いようなこともあるかもしれない。
Takuya Oikawa
そうですそうです。サイクロンDXってOWASPによってサポートされている、セキュリティに特化したやつもありますよ。
すごいな、僕は勉強不足だな。
Nobuhiro Seki
こういうのって現場にいないとすぐ置いてかれちゃいますね。
Mika Ueno
それだけ世の中というか広いですよ、エリアがね。
SBOMって音だけで聞くとボムボムって聞こえるかな?爆弾のボムに聞こえるんだよな。
Nobuhiro Seki
いや、もともとボムはそうですよ。
Mika Ueno
そのボムから来てるの?
Nobuhiro Seki
うん。だってビルオブマテリアルって明らかにボムから逆させて作ったりするじゃないですか。
だってわざわざビルとか使わなくていいぞっていう気がしますよね。
リストオブマテリアルとかでいいじゃないですか。
Mika Ueno
そうね。
Nobuhiro Seki
そうするとロボになっちゃう。
ボムの名前の由来を教えてくださいとか聞いてみると。
Mika Ueno
音の印象がすごくて、すごいすぐ覚える。
著作権からちょっとずれますけど、競技の記事みたいな。
この間何かで知ったんですけど、ある記者の人がいろんなメディアに書いていた、有名どころのメディアに書いていた記者自体がAIで、
競技だった記事がワイヤードとか結構信頼性のあるメディアにガンガン掲載されてて、
競技が発覚して取り下げられて結構すぐ大問題になってたみたいなものを見たんですけど。
英語の記事なんですけど、マルゴ・ブランチャードっていう記者さんがいて、その記者さんが書く記事がいろんなところに載ってたと。
なんだけどどこかからの指摘があって、これは記事の内容として怪しいんじゃないか。
これ競技じゃないか。この人存在するのはAIじゃないかみたいな感じで、それが連鎖的につながっていって、
その人が書いた記事は全部フェイクで、そもそもその記者自体が別の人が操ってる記事だったみたいな。
記者だったっていう、そういうのがあったらしいんですよね。
Nobuhiro Seki
ちょっと前ですよね。
Mika Ueno
ちょっと前ですね。
これいつの記事だ?
8月とかの記事だから、そうですね。
Nobuhiro Seki
ちょっとキラッと見ちゃって。
Mika Ueno
これ見るの知らなくて、しかも掲載されてたのがビジネスインサイダーとかワイヤードとか、
本当にここだったら信頼できるよなって私も思って読むようなメディアだったので、
そういったところにやっぱり載ってしまって、そこも着実に積み重ねてたものがあるみたいなんですよね。
最初はローカルだけど、読まれてるっていうところから記事を出していって、
マルゴ・ブランシャーの信頼度を上げていって、その記事を売り込んでいったみたいな感じで。
最終的にはアメリカのどっかの都市が、炭鉱がなくなった街なんだけど、
そこに人が集まっててみたいな、そんな記事だったらしいんですけど、そんな地名ないじゃんっていうところから、
編集者さんの人が気づいて怪しいなと思って、やり取りをして発覚したらしいんですけどね。
なんかいい側面で利用されるならいいんですけどね。
何を信用していいかわかんなくなるみたいな方向に使われていきがちじゃないですか、新しいテクノロジーとか仕組みとかって。
そういうふうになってくると、他の99%めちゃくちゃ誠意を持ってやってる人たちが、
こういう一握りの虚偽とか悪意によって、信頼を失っていっちゃうみたいなきっかけになるのは残念だなと思いましたけど。
でもこれはAIが悪いわけじゃなくて、そういう人がいるわけじゃない。
そうなんです、AIが悪いわけじゃないんだけど、それを悪用する人がいるのがね。
Nobuhiro Seki
名前を見てフランス系の人なんか知られるぐらいしか印象がないですけどね。
Mika Ueno
マルゴだから女性?女性なのこれって。
Nobuhiro Seki
シャトー・マルゴしか思ってない。
ブランシャールみたいな感じですよね、フランス。
ニュース見ても、8月の後半にひとしきり一瞬だけ話題になって、それ以上盛り上がってる感じですよね。
それをもっと深く調べた人がいるのかもしれないけど、サクッと見ただけで。
Mika Ueno
マルゴ・ブランシャールで後にディープリサーチかけてみよう。
Nobuhiro Seki
これね、ディープリサーチ。
Mika Ueno
前後でね、何が起きてどういう経緯でどうなったんですかみたいな。
ちょっとした1本のフェイク記事とかそういうのだったらなんですけど、載っていたのが載っていたメディアだったのと、
それでもやっぱり引っ張られちゃったところがあったんだと。
信憑性、正確性っていうのをやっぱり求めるじゃないですか、メディアとかね。
それを自分の中にもフィルターを持たなきゃいけないんですけど、
そうそう簡単に見破れない時代にもなったなみたいな感じがしました。
Nobuhiro Seki
100%AIで書いてたのか、背後にいる人がある程度は見て書かせたのかによりますよね。
だんだん上手くいってきたから、だんだんコピペで載せるようになったら、
そういう競技の記事を書いてしまったのかもしれないですね。
バーッとメモしたような話とかっていうのを、最後に整形するときに、
正性AI使うの結構あるんですけど、めんどくさいからね。
そのときに、今の文章に書いてなかったことを勝手に書き足したりするじゃないですか、AI君とかね。
なんでこの文章のデスマスタイをレアルに書いてくださいみたいなことしか言ってないのに、
勝手に文章のタイトル変えられたりとか、内容がちょっと増えたり減ったりとかして、
減る分にはいいんですけど、増えてるときに全然今まで話してもないような内容のやつが勝手に突き出されて、
それがさらに間違ってるみたいなのがあってですね。
本当に逆にレアルをデスマスに変えてくださいみたいなやつが逆に怖くて出せなくてですね。
また自分でやるのに逆戻りになってしまう。単純作業。
単純作業だから時間が読めるじゃないですか、自分でやってもせいぜい。
レアルをデスマスに変えるみたいなやつって、5分ぐらいで済むわけじゃないですか、きっと長い文章。
そのためにAI使って何分か待ちされた逆に、本当に虚偽が書いてない確定するんだったら、
自分でやったほうが確実ですみたいな感じになっちゃってですね。
最近そういうことが増えましたね。
Takuya Oikawa
そういうのだいぶ減ったんですけどね。
Nobuhiro Seki
減ったと思ってたのに最近またちょっと増えてるんですよ、この1ヶ月半ぐらい。
という印象があってですね。
自意識すごい虚偽がなくなって、すごい安心だなと思ってたんですね。
ただこのやっぱり1ヶ月半ぐらいに、結構そういう、また捏造するようになってきてですね。
Mika Ueno
なんか想像力を刺激するような捏造もあるじゃないですか。
こういう視点ありだとか、こんな書き方ありだとか、こんな方向ありっていうのももちろんあるんですけど、
審議が問われるような内容とかだと困っちゃうこともありますね。
Nobuhiro Seki
最近はクロードとかに、この文章の最初の2パラグラフをもっと魅力的にしてくださいとか、
そういうなんかことはあるんですけど、導入をもう少し臨場感をあふれさせてください、
みたいなことはありますね。
全文やるときに本当に注意しないと、という感じに。
Mika Ueno
こういう表現の仕方あるんだ、自分の言いたいことはこういう方向で、アウトラインはこうなんだけど、
表現としてもっとこう、自分の言葉を出すにも時間かかるんだけど、
こういうのがあったな、この表現いいなっていう、ピックアップしたい時あるじゃないですか。
他のものを参考にしたいとか、そういう時すごい便利ですよね。
Mika Ueno
それを見て、こんなのもあるんだ、でも自分だったらこういうっていうのが出てくることもあるから、
そのピピンと来るものを求めて使ったりすることもありますね。
フェイクといえば、音楽の、ちょっとこれも前の話ですけど、
Spotifyで超人気のバンド、1、2ヶ月で100万フォロワーとか得た話題のバンドが全部AIだったみたいな話題もありましたけど、
ベルベットサウンダウンっていうバンドなんですけど、
それがSpotifyで1ヶ月で急上昇してバーンって何十万とかフォロワーいったんだけど、
あれって言って、でちゃんとSNSのEXOのアカウントあったりとか、
ジャケットの写真に人が、男の人4人が写ってたりとかするんですけど、
これ写真あるかな、
新生バンド、数週間で100万回以上再生された新生バンドがAIだったみたいな。
ビジュアルもAIもだったんですけど。
Takuya Oikawa
これ見ましたわ。
Nobuhiro Seki
見ました?
Takuya Oikawa
これもちょっと前ですね。
Nobuhiro Seki
7月だな。
この写真に見覚えが。
Mika Ueno
ちょっとレトロな感じで。
私結局曲は聴いてないんですけど、カントリーフォーク調だったらしくてね。
ビジュアルのジャケットも、あとSNSの投稿もある人が投稿して、
そのバンドになりすましてみたいな感じだったんですけど。
芸術的なそれはいたずらだったよみたいなね。
話をローリングストーン氏に話したっていうことだったらしいんですけどね。
これはこれで一つのクリエイティブだなとも思いますけどね。
でもこういうのを全部作れるっていうことは、
もちろん今VTuberもいたりとか、完全なバーチャルアイドルがいたりとかもするから、
それと一緒だなと思うと、構成としては同じなんだけど、
だから全部AIだったっていうところに、
人間のクリエイションとはっていうのは問うようなものが含まれてるなと思います。
Nobuhiro Seki
6月くらいの記事を見ると、
前回とか前々回とかサンプリングの話しましたけど、
他のものを取ってきて、自分で作ってないけど、
Mika Ueno
それをちょっとアレンジして組み立てていくと音楽になるとか、
AIとかも他のものを学んでいて作ってきてるもんだから、
人間がやってるクリエイションと何が違うのかなと思うときもあるんですけど、
そういったことについて、
使われてる写真がすごい、AI感満載です。
AI雰囲気満載です。
そうですね。
本当、写真のためにポージングしましたっていう感じですよね。
Nobuhiro Seki
音楽演奏してるときのダイナミズムとか、
音楽を演奏してるときのアイディアとか、
Mika Ueno
そういったことについて、
そういったアイディアとか、
もともとオリジナルの記事は50万再生みたいな感じだったんだけど、
見出したら55万。
55万買ってる。