00:02
Yoshiori Shoji
というわけで、これは俺とドラフト コードがタメ口で、エンジニアリング
とかについてだらだらとしゃべる ポッドキャストです。
しょうじ、yoshioriです。みょじまで 言っちゃった。yoshiori、よろしくお願いします。
draftcode
ドラフトコードです。
何回目?
Yoshiori Shoji
4回目?4回目だったっけ?
4回目です。
今日は、なんと初めてのゲスト がいます。
ゲストの西尾さんです。
簡単に自己紹介をお願いします。
nishio
西尾です。よろしくお願いします。
自己紹介するのを予測しなかったん だけど、簡単に言うと、
エンジニアの知的生産術とかコーディング を支える技術とかを書いている西尾
というものです。よろしくお願いします。
Yoshiori Shoji
お願いします。経緯を説明すると、 過去3回でオブジェクト思考とか
フィラーハンドリングとかDIの話を しているときに、結局、
プログラミングの歴史の話をよく していて、
だったらコーディングを支える技術 を書いている西尾さんとかを
読んで、ただの素人の俺ら2人が だらだら言っているより、
ちゃんとしている人を読んだほうが いいんではないかという話で
読んでみたんだけども、読んでみたら、 読んだ1発目のチャットで西尾さんが、
コード書くのとかAIがやるから、 人間がどうこうとか、
構造化プログラミングとか言っているのも、 どうでもよくなるんじゃねえ
みたいなことを言い出して、それが どうでもよくなったので。
nishio
若干誇張がある気がするが、そういう 方向性としてはどうなんだか。
draftcode
AIを使うというところに対して、 色んなエンジニアに適当に話題を
振ってみても、大体様々なレスポンス が返ってくるので、
みんな、多かで少なかでネガティブ ポジティブはあるけれども、
興味がある分野なのかなという感じが すごいしますね。
Yoshiori Shoji
はい。なので今日は、ざっくりAIと プログラミング的な話題で話してみようと
いうふうに変わったので、 その辺で話していこうかなと。
何から話しておく?まずやっぱり コパイロット?
そう。
この話が出た時に、俺と西尾さんは コパイロットを使ってた派なんだけども、
ドラフトコードは使ってなかったんだよね。 言われて使い始めたんだよね。
draftcode
そう。これ、対立としては面白いな という感じがしていて、
みんな使っててっていう感じだったら そうよね、みたいな感じがするけど、
自分はどっちかというとコンサバとか 言ったほうがいいかもしれないけど、
コンサバティブなほうで。
Yoshiori Shoji
まだビームでコード書いてるしね。
draftcode
ビームでコード書いてるからね。
ビームでコード書いてる人も だんだん少なくなってくるんだけど。
なので、せっかく話をするんだから ということで、
車上にも、今使ってって言われたから、
なので、コパイロットをこの1週間くらい 初めて使ったっていう感じですね。
Yoshiori Shoji
どうでしたか?1週間使ってみて。
draftcode
いやー、コパイロットですね。
03:03
draftcode
コパイロット。コパイロットよねっていう。
賢いオートコンプレッション みたいな感じがやっぱりしていて、
たまに自分、ビジュアルスタジオで Cシャープを書くっていうことがあるんだけども、
確かにビジュアルスタジオってもうちょっと 賢いオートコンプレッションみたいなことをしていて、
それに近いやつは確かに今までちょっと 使ってたなっていう感じはするので、
賢いオートコンプレッションという 感じがします。
逆に賢いオートコンプレッションだな っていう感じのぐらいのところで
nishio
留まっているっていう感じがしますね。
そのコパイロットだよねっていうのは 要するにパイロットにはならないよね。
パイロットは自分だよねというふうな ニュアンスなんですかね。
draftcode
そんな感じのニュアンスですね。
Yoshiori Shoji
メインパイロットにはならないってことだよね。
draftcode
感覚的な感じで言うと、車乗ってる人は オートクルーズ機能っていうのがあるの。
使ったことあるかどうか分からないんですけど、 知ってると思うんですけど、
あれって勝手にアクセルとかブレーキを 微妙に調節してくれて、
高速を乗るときに便利だよね みたいな感じなんですけど、
自動運転ではない一部なんか便利みたいな感じの、
Yoshiori Shoji
そういうぐらいの便利さだなっていう感じがしますね。
これ多分先に突っ込まれポイントだと思うので 伝えておくと、
多分ドラフトコードはあれだよね。
Vimから何かしらのゴニョゴニョをして コパイロットを使ったんだよね。
draftcode
そう。GitHubがコパイロット.Vimっていうやつを出していて、
なんとVimを使ってる人はTPOPという人を よく知ってると思うんですけども、
書いてるっぽいんで、この人GitHubで働いてるのかな みたいな感じがするんですけども、
一応オフィシャルプラグインがあるんで、 これを使ってます。
Yoshiori Shoji
なるほど。何が言いたいかっていうと、
多分IntelJとかもそうなんだけれども、
外部に出してるAPIってベータの一部なだけなんだよね。
nishio
フル機能を使えるのって今のところ VSコードでしかないんだよねっていうのがあり、
Yoshiori Shoji
多分俺も基本的には使ってるのは、
VSコードでRuby書いてるとき使うのと、
IntelJでJava書いてるときに使うみたいな感じで、
やっぱVSコードで使ってるときの方が 機能が豊富だなぐらいの感覚なんだけど、
一応そこに違いがあるよっていうのだけ。
nishio
コパイロットのところで質問がしたかったんだけれども、
僕コパイロットじゃなくてカーソルを使ってるんだけど、
コードの範囲選択してこの範囲に対してこうしてって言って、
そのコードのその範囲を書き換えるみたいな機能って今のコパイロットにもあるのかな、
VSコードで動くやつ。
draftcode
あるのかな。
Yoshiori Shoji
VSコードのほうはあるんじゃないかな。
nishio
VSコードのほうは入ったんです。
確かね、カーソルが先に入れてしばらく経ってから、
VSコードに入ったぐらいの感じなんじゃないかなって僕は認識してたんだけど、
大体認識が正しくて。
API経由だとそういうUX UIをうまいこと工夫して、
いい感じの体験を作り出すっていうところが、
draftcode
どうしてもAPI経由だとやりにくいよねっていうところはありそうだよね。
06:00
nishio
そうね。
draftcode
もっと統合的に、総合的に支援していくみたいなことがある。
nishio
今だとこのソースコードの一部を選んで、
ここのところをこう直してって自然言語で書くと、
ペペペペペって上からデフがかかっていたのは、
よくコミットするときにこの赤と緑になるじゃないですか、
あるになるんだよね。
で、それを見て採用するか採用しないかポチッとやると採用されるみたいな感じの、
要するにこの範囲に対してプルギグを送ってという指示をして、
プルギグが送られてくるみたいな感じだよね。
draftcode
その指示ってどういうレベルの指示をするんですか。
nishio
例えばブラウザのクライアントサードのコードを書いているときだと、
デフが3つ並んでいるので選んで、
これスリーカラーモにしてみたいなことを言うとスリーカラーモに、
フレックスがどうのみたいな感じのテイルワインドのクラス名が入って、
スリーカラーモになったからどっからブラウザのほう見て、
あ、ちゃんとスリーカラーモになっているじゃん、
一発でいけたらすごいなみたいな感じののに、
雑にこの辺の色をいい感じにしてとか、
ちょっと色きついから弱くしてみたいなそういう雑な指示を入れて、
ちゃんとやってくれるからウケる。
draftcode
なるほど、なるほど。
Yoshiori Shoji
今の感覚が多分正直な感覚だと思っていて、
一発で動いたらすごいじゃんが、
まだ今の求める品質というか認識している品質なんだよね、
nishio
ダメかなと思いつつ無茶ぶりをするんだけど、
意外と無茶ぶりが成功してビビるみたいな感じ。
draftcode
逆に言うとエクスペクテーションがそこまですんげえ高いわけではないから、
ちょっとここまでできるんだみたいな感じの、
不良が前行をしたら良くなるみたいな感じじゃないけど。
nishio
もちろんしばしば失敗することなんだけど、
スンとリセット、キャンセルボタン押すだけみたいな感じで、
記憶に残らないから良い記憶ばっか積み重なって、
Yoshiori Shoji
不良がめっちゃ良いやつになっていく。
俺が一番すごい記憶に残っているのは、
テストコードを書こうと思った時に、
ディスクリプションというか、
こういうことをテストしますよってまず1行目に、
メソッド名とかで表すわけじゃん。
それを書いてゴンってタブを押したら、
テスト用のデータを作るボイラープレートが全部書かれたのよ、
パイロットによって。
それはここまでやってくれるんだと思って、
実行しようと思って実行したら普通に通って、
でもさ、テストコードを書いてもらって普通に通ると、
逆に今度さ、このテストコード本当にテストしてるのかなって不安になるじゃん。
draftcode
それはね、順番が間違ってて、
まずテストコードを書いてからコードを書いてみようかって。
nishio
100%正しい。
Yoshiori Shoji
そうなんだけど。
値を変えてみたら実際に落ちたから、
もう正しかったんだと思って、
やってくれるなって。
ボイラープレートを書くとかは結構やってくれるし、
あと便利だなって思うのは、
SQL書くときのサジェストがすごい頭いいんだよね。
わかりやすいんだと思うんだけど、
ジョインとかするときに、
テーブル名とか、
リレーションするためのID名とかを、
09:02
Yoshiori Shoji
勝手に予測して勝手にジョインクを全部書いてくれるんだよ。
インナージョインのところ、
ONCとかを全部書いてくれるのとかは、
地味に便利だなっていう。
draftcode
それもそうだね。
うち今、Pythonという言語を書いていて、
ORMとしてSQL Alchemyを使っているんだけども、
なんかちょっと、
もともと書いた人の癖というか、
ちょっと微妙に、
公式リファレンスとかで見るようなコードとか、
なんかちゃんとジェネレートできてるから、
おーちゃんとジェネレートできてるんだみたいな感じになっていて、
あとなんなら、
Pythonの型アノテーション、
あれを、
なんかイグノーしないといけないっていう、
ちょっとうちのコードがクソすぎる程度なんだけども、
しないといけないというところがあって、
それもなぜかジェネレートしてくれて、
おーちゃんとイグノーしてくれて。
nishio
その話めっちゃ面白いと思っていて、
わざわざ機械で指摘入れるように、
機械でプログラムを書いているのに、
機械がそのイグノー計画を無視するコードを設定して、
機械が機械を止めて、
ちょっと何を、
めっちゃ面白いコードなんだけど、
周囲の空気を読んで、
人間はこの計画を必要としてないんだということを理解して、
計画をちょっと止めてくれるところまでやってくれてるわけなんだよね。
draftcode
でもちょっとカゴカルトっぽい感じがします。
プログラミングにおけるカゴカルトって、
みんなよく分かってないんだけど、
こういうふうにみんなやってるから、
これはやらないといけないんだみたいな感じ。
nishio
おまじないだからやっておこうみたいな、
そういうよくないものを進めてしまう気がするよね。
Yoshiori Shoji
人間っぽいなって思うよね。
それを聞くとさ、
人間も新しいチームにジョインしたときさ、
よく分かんないけど、
過去のコードがこう書いてたからこう書こうみたいなのでさ、
書くことあるじゃん。
確かに昔はこう書いてたんだけど、
今もこの書き方はよくないからやめようってなってんだよね、
みたいなのをレビューで指摘するとかあるじゃん。
そこにはもうすでにいるってことだよね、
draftcode
コパイロットは。
Yoshiori Shoji
たまにそこに来るぐらいには。
draftcode
空気読みは得意なんだなっていう感じはするけど、
コメントを見てこういう感じの空気かみたいな感じで
修正してくれるみたいなのは。
Yoshiori Shoji
コメント名とかメソッド名を書くだけで
draftcode
実装を書いてくれたりとかは結構あるよね。
メソッド名は特に今Python書いてるから、
Pythonの関数のドキュメントって
関数名の後にストリングで来るみたいな形なんだけど、
単純にこのメソッド名書いたら後は何をするかみたいなコメントも
ドキュメントもバーって書いてくれて、
確かにそうだよみたいな感じのが出てるんで、
nishio
空気読みすごい得意だなっていう感じがしますね。
僕が書いたコードじゃなくて、
整理したコードのところだけコメントの密度が高いんだけど
draftcode
みたいに常にコメント書いてある。
Yoshiori Shoji
それはね、あると思う。
多分ね、俺が書いたコメントよりも
コパイロットが書いた英語の方がナチュラルな英語であるとかは全然あるんだよね。
12:03
draftcode
それなんか思い出す。
自分も大学生の時に論文を英語で書いた時に、
先生がプリペースというか最初の1ページ目、
最初の1ページ目大事じゃないですか。
最初の1ページ目をバシッて書いてくれて、
その後自分が適当に書いたんだけども、
デビューから、なんか最初のページの英語はすごいしっかりしてるんだけど、
次のページの英語はなんか微妙やなみたいな感じのコメントが来て、
ああ、よくわかってますねみたいな感じの苦い思い出が読み上げてきますね。
Yoshiori Shoji
なんか今コパイロットの話をしてたけれども、
全体的に俺はもうすでにコパイロットねえと開発するのめんどくせえなぐらいにはなってるのよ。
何なら今テストコード書く時にテストのメソッド名書いて
ボイドアップデートをサジェストしてくんねえと。
早くテスト書けお前って思うぐらいには
コパイロットないとコード書きたくないなってなってるんだけど、
2人はどうなん?
nishio
僕はもちろん同じ感じ。
たまにネット切れたりとか接続切れたりして止まってる時あるじゃない、コパイロットが。
コパイロットさんいないじゃんみたいな。
反応こないと思ったらあいつお休みかみたいな感じの気持ちになる。
そんな感じですね。
draftcode
自分がまだ使って1週間だから、
なかったらなかったでいい。
1週間前から生きてきた訳だし、
もうこんなもんかみたいな感じもあるかな。
nishio
しゅうゆさんも別になかったら死ぬわけではなく、
なかったら嫌だなあって言いつつも仕方なく自分で書くんでしょ?
Yoshiori Shoji
まあまあそれはねえ。
draftcode
だって今まで言ってた通り自分で書いてたわけだからね。
なんか出てきたものに、コパイロットから出てきたものに、
これ知らなかったぜみたいなことは基本ないみたいな状態。
nishio
ショートカットができてるっていう感じのところが今のコパイロット。
それはね、よくある。
例えば自分が読めない言語のコードとか説明させたりすると、
なるほどねーと。
その機能のコードって何業務にあるの?って言ったらこの業務にあるよって言ったら
なるほど確かにそういう風に書いてあるように見えるなと。
両方読めるコードなんだけどめんどくさいからこっちのタイプスクリプトで書いたやつ
Pythonに変換してとかPythonで書いたやつタイプスクリプトに変換してみたいなことを言うと
だーって出てきて実行してみたら何箇所かエラーが出てこけるのをちょっと直したら
あー動いたみたいな感じのぐらいの。
やっぱり僕の経験では一発で動いてなくて3回ぐらいバグがあったんだけど
3箇所バグ直したらそれなりの大きな実用的なプログラム変換したやつが動いたので
ハッピーだなーと自分で書き直さなくて良くなった楽チンみたいな感じ
知らないことが出てくるか出てこないかの話だった
そこで面白かったのが僕が知らなかったライブラリを使ってきて
へーこんなライブラリがあるのか便利だなーってなったっていう
そういうことが
Yoshiori Shoji
知らない日関数みたいなの使われて
15:02
Yoshiori Shoji
あっこんな関数あるんだみたいなのはたまにあるね
draftcode
知らない関数で出てきて知らない関数だと思ったらそんな関数はないっていう
nishio
それもあるそれもある
draftcode
勝手に関数を作ってるときあるよね
ちょっと嘘ついてるときは
知らないというかほぼ知らなさそうだなっていうものでもコンプリートできたっていうのは
自分も試したやつであって
自分は学生の時にモデル検査をやっていて
モデル検査っぽいことをどの仕事でも多少やったりするんですけど
TLAプラスっていう言語を最近いじることがあって
それのコードを引っ張ってきて
ここら辺ってどれくらいできるかなって思ったら結構割といい感じにできていて
TLAプラスなんてほんとに一部の人しか使ったことがないものだと思うんだけど
ほんとできるんだ全然文献とかサンプルコードなんてないと思うんだけど
何に空気を読んでそれっぽいコードを吐き出してくれて
すごいんだなっていう感じはそこは
それが多分自分の中で一番インプレッシブだった
エコパイロットのやつかな
nishio
知らないほどのコードでもできるってことですね
draftcode
そんなマイナー言語でちゃんと補完ができるんだみたいな感じは
Yoshiori Shoji
でもこの弱点って言っていいのかわかんないけど
ナチュラルに嘘をつくというか
知らないですわからないですってあんまり言わないじゃん
これはエコパイロットだけじゃなくて
多分DPLの翻訳とかもそうなんだけど
DPLの翻訳とかもナチュラルに自然に真逆の翻訳をするときあるわけじゃん
文章としてさ
さっき西尾さんが言ってたブラウザーでスリペインにしてみたいなのを
スッと確認してあ、なってるじゃんなってるじゃんって見れるみたいなのが
実は結構大事だと思ってて
すぐにエコパイロットがサジェスターしたコードを実行してみて
正しいかどうかが判断できる状況じゃないときに
エコパイロットでコードを書くかっていうとちょっと難しいなと思うんだよね
俺も例えばテスト書いたらテストコードだからさすぐ実行できるんだよ
そういうコードをジェネレーションさせて
とりあえず実行させて動いたね
ちょっとコンパイルエラーが出たね
ちょっと直そうみたいなのはやりやすいんだけど
もしもそうじゃなかったときはちょっと怖いなっていう思いはある
draftcode
コンパイルするなり実行するなり
自分で読む、読んで確認するなり
何かしらの確認主体があった方がエフェクティブであるような感じがする
逆にさっきのDeepLの翻訳っていう感じでも言ったけども
基本DeepLとか翻訳者を使うっていうのは
自分の知識を補ってくれる
どちらかというとプロに頼むっていう面が大きいんだけども
18:00
draftcode
その結果って一応信頼の元
これぐらい信頼度どうっていう感じで使っていくわけじゃん
そこでその信頼度がやっぱり不安定なのかなっていう
AI生成のやつはっていう感じはするのかな
本当に正しいのかどうかを確認する手段がない状態で使うと
どうだろうねみたいな感じになるのかな
nishio
逆に言うと大部分の世の中のことって
すぐに正しいかどうか確認できない仕事の方が多くて
テストコードみたいなすぐに確認できるタイプの仕事っていうのが
本当に今後も価値があるのかどうかって割と怪しくて
すぐに確認できるということは
コンピューターも実行して確認することができるわけなので
AIはそれからどんどん得意になるソフトの方が早いわけだよね
そうなってくると正しくないかもしれないものを乗りこなしていく
というスキルの今の機械翻訳の話も
機械翻訳してみて逆になってるじゃんっていうことに
人間が後から気づくわけなんだけど
大部分のケースがうまくいっていて
間違ってるある部分が逆向きに翻訳されてるって気づくのって
もっと広い範囲のコンテキストを見たときに
なんかここだけちょっと数字とも合わないぞみたいな
なんかより広い視野とか広いコンテキストの情報で解決してるわけだよね
なのでソースコードの先生とかソースコード単体の先生とかだと
うまくいかないんだけど
全体との整合性を見たらちょっとこれおかしいんじゃないかみたいな
広い視野を持って判断する力っていうのが
より要求されるようになっていくのかなっていう気がしますね
draftcode
そんな感じはしますね
なんか逆に言うと
なんだろうな
僕はその分野を知らないんですけれども
日本のSIの仕事って割とかなり細かいレベル
このクラスがあってこのメソッドがあって
このメソッドはこういうことをやるみたいな感じの
そういったレベルまで落とし込んでるっていう感じが
nishio
なんかその落とし込んだやつを
draftcode
実際にコードに落とすっていう仕事があるらしいんだけど
その仕事は本当にAIになってもおかしくないのかなという感じがする
そこまで落とし込んだ部分
落とし込む部分は人間がやるっていうのは分かるんだけど
その先は確かにAI生成してもおかしくはなさそうっていう感じは
nishio
十分な仕様が情報として与えられてから
それをコードに変換する
ただの変換機としての作業っていうのは
AIが得意なんじゃないかってことですね
draftcode
得意になってくるかもしれないですね
nishio
そうですね そうだと思います
Yoshiori Shoji
でも一方でちょっと怖いのは
ちゃんとした理論的に破綻してない設計をできるのって
それなりに経験を積まないとできるようにならないわけじゃん
でも今の話でいうと
その経験を積む部分は全部AIが得意になっちゃうから
AIに任せちゃうわけじゃん
nishio
AIはコードの実際のタイピングをするところを
代わりにやってくれるわけで
設計の部分はやってくれないのでは
draftcode
人間がやるのはインターフェースの外形部分だけ書いて
その後コメントとかを書いて
それがどうなるかっていうのを設計すると
ほぼ埋めてくれるんじゃないのっていう感じの世界観
ただそういったインターフェースをうまく設計する技術っていうのを
つけるために
21:01
draftcode
ベーシックなコーディングをするっていうのが
果たして欲しいかどうかは
多分僕たちはずっとそれをやってきて
そういうスキルを得てきたから
やっぱ欲しいよ
基本的なコーディングスキルがないと
そういったインターフェースの設計とかできないよ
っていう風に思ってしまうけれども
ちょっとステップバックすると
本当にそうかなって生存バイアスがあるから
本当にそうかなっていう感じもしますね
nishio
何年のタイムラインで考えるか
それくらいのスパンで考えるかによっても
違うと思うんだけど
ポートランが出てきたとき
ポートランって自動プログラミングシステムって
言われてたわけで
ポートランが出してくるアゼンブリのコードなんか
品質が悪いから人間が書いたほうがいいよ
って言われてたわけなんだけど
じゃあ今の我々はアゼンブリのコードとか
直接機械語のコードを書いてやってるから
そのノウハウがあったほうが
余裕で設計ができるよねって言われて
いや違うやろって思うわけだよね
今の大部分の人は別に
機械語でコードを書いてないわけなので
機械語で書くという意味での
狭い意味でのプログラミングというのは
確かになくなって自動化されたわけなんだけれども
同じことが起こるんだとするんだったら
今我々が思っているのは
プログラミングの生のプログラムを
経験というのは設計をする上でも大事だろう
っていうのは
大人が出てきた時代に
機械語を書くほうがいいよって言ってた人たちと
同じことを繰り返してるかもしれないな
っていう気持ちはある
draftcode
そうですね
Yoshiori Shoji
今あれだよね
高級言語とマシン語の関係が
自然言語とマシン語の関係
っていう風になってくっていう感じだよね
人間が今まで機械が理解できやすいように
合わせて高級言語で書いていたっていうのが
機械が普通に自然言語を理解できるようになっちゃったから
自然言語で書きゃいいじゃんになる
っていう感じだよね
nishio
ただ
ん?
draftcode
何か
nishio
あ、ごめん
ごめん
例えばPythonで書いてソフトが必要なところだけCで書くみたいなノリで
自然言語で解説してるけど重要なところだけ
すごくアルゴリズムが複雑みたいな感じのところだけ
Pythonなり何なりのコードで書くっていう風な形の
分量の形で書かれるっていう形になるかも
draftcode
ハイブリッドな感じ
もしくは
そうですね
コメントを残しておいてこれで生成しましたみたいな感じの
が残っていく
Yoshiori Shoji
なんか
でも一方でさ
なんかちょっと思うのは
その頃の時代とちょっと違うなって思うのは
そのパフォーマンスチューニング
ここはパフォーマンスが大事だからとかさ
ロジックが複雑だからみたいなところをさ
やるのがさ
何だろう
AIの方が得意なんじゃねえかなって気がしてて
今までのコンパイラーとかと違う部分
今までのコンパイラーって
AIって言われてた時代もあるかもしれないけども
基本的にはルールベースだったわけじゃん
ルールベースでやる
結果複雑な処理やるとそのルールが複雑だから
ちょっとなんか冗長なコードが出ちゃったりとかするから
本当にパフォーマンスチューニングが必要なところは
人間が直接
例えばアセムリで
ハンドアセムリした方が早いみたいなのが
あったかもしれないけども
実際のこういう
24:00
Yoshiori Shoji
インプットとアウトプットがあって
その処理をしてくれ
しかもそれを高速に書いてくれみたいなのは
多分AIの方が得意になってくんだよね
試行錯誤もめちゃくちゃ早くできるしさ
nishio
AIというかプログラム言語の処理系が得意だから
だからずっとコンパイルとかするわけだよね
Yoshiori Shoji
そうそうそう
でなんかこの前も半年ぐらい前にもニュースになったけど
ソート化なんかのアルゴリズム
GoogleがAIでパフォーマンスチューニングされたら
ちょっと早くなったみたいなさ
最速のなんかソートアルゴリズムは
もうAIが考えましたみたいになってるじゃん
もう実際にさ
nishio
ちょっと誇張があるニュースのような
そうそう
異常ボーダーに行ってるニュースのような気がするけど
あれはねっていう
そのなんていうか
細かいこの状況で最適な解を探せてきたの
解を頑張って探す的なことは
人間が網羅的に探すよりは
コンピューターが網羅的に探す方が得意だろうね
Yoshiori Shoji
うん
draftcode
なんかそのAIが得意っていうのは結構
なんかAIが何を指してるかっていう
やはり違いがあると思っていて
そのここで言う我々がAIっていうのは
どちらかというとそのLLMとか
そのまあ機械学習に類する
テクノロジーを使ったものであって
でこれってやっぱり
あの人間が得意なパターン認識とか
そういう部分を
よりなんか機械でもできるようにしよう
っていうことで
いろいろ頑張った分野
頑張っている分野ではあるんだけれども
逆にそれをそのアルゴリズムで言ってるから
そことそれ以外のそのルールベースとか
その網羅的に何かを探索するっていう部分が
うまくマージされていけば
まあ機械は得意というふうに言えるんだけれども
少なくとも何とかその多分違うんだよね
その動いてるアルゴリズムがまず違うから
なんかそのベースのハードウェアとして
それが得意であるっていうのは
否定はしようがないんだけれども
上のアルゴリズムがそういうふうに
それをユーティライズするような形に
まだなっていないので
だから今のところ足し算をするのでも
かなりそのCPDとかにかなりステップをやらないと
あのちゃんと足し算もちょっとうまくできないね
っていう感じの状態にはなっている
っていうことでね
その進歩によって
いつかできるようになるかもしれないけれども
今のところはっていう
nishio
なんか計算機っていうのは要するに
人間が計算があまり得意でないところを
より計算が得意だからということで
計算機というのが価値が生まれて
こう発展してきたわけじゃん
昔はほら人間のお姉さんたちが
一生懸命計算していて
自分で計算して
レンズの設計とかやってたのが
それがコンピューターのほうが計算が得意だから
コンピューターに置き換わったわけだよね
それでその計算が得意っていう能力のほうを
ゴンゴン伸ばしていったんだけれども
その結果計算は得意だけど
言葉は喋るな
得意でないコンピューターさんという
新たな人種が生まれて
コミュニケーションにプログラマーという
特別の通訳がいないとできない状態だったのが
このコンピューターの側が
なんと日本語とか自然言語の側も
喋れるようになってきたというのが
現状のこの驚きポイントだと思うので
そういう意味でいうと
じゃあその自然言語理解能力を使って
カジコリのチューニングみたいな
ロジックのことをやろうっていうのは
ちょっとなんかわざわざ得意な
ふえてな方法でやらせてる感じがあるよね
27:01
nishio
なんというかね
日本語がネイティブの人に
英語がネイティブの人が英語が喋れるようになった
すごい英語で直接コミュニケーション取れるようになった
みたいな状態で
じゃあその英語で日本語の配偶作ってくださいって
指示するのって
ネイティブの日本語使わせるよっていう感じになるのと同じで
今の最適化するような
チューニングの計算をしますみたいな話になると
LMの上に載せるんじゃなくて
そのコンピューターを素直に使った方が
効率がいいんじゃないのかなみたいな
感じの気持ちになる
draftcode
なんか
感覚としては
マイクラの中でコンピューター作るけど
わざわざマイクラの中でコンピューター使って
それ計算したくても直接コンピューター使った方が
nishio
まだいいよねっていう
draftcode
そういう
コンピューターを使っても全然うまくいくっていう
感じの世界になるのかもしれないけれども
今のところは
nishio
違うっていう感じ
マイクラの中のコンピューターでどうこうというよりは
マイクラの中でやりたい計算処理を
プラグインの形で
外に追い出してできるように
ハイブリッドにしてっていう形の方が
どう考えても経済的に合理的で
夢とかロマンとしては
面白いんですよね
マイクラの中でデカいコンピューター使って
編集率計算してディスプレイするとか
マイクラのブロックでやりましたみたいなやつは
大好きなんだけど
それはそれとして
経済強引性を持って社会が
その方向へ進んでいくかというとなわけないだろう
みたいな感じのところが
Yoshiori Shoji
そうですね
マイクラだとそうだけど
マイクラ的な話でいうと
そういうのはあるかもしれない
言いたいこととしては
マイクラじゃなくて
自然言語でもなく人間がより理解しやすい
ゲーミングのビジュアル的なもので
書いた方がわかりやすいよね
みたいなのがあったら
そっちで書くみたいなのはあるのかな
nishio
プログラミング言語の今までの形じゃなくて
新しい表現の形式があるんじゃないか
Yoshiori Shoji
みたいなこと
そうそうそうそう
マイクラで書いたらみたいな話があったから
ちょっと思ったのは
今結局プログラミング言語
僕らがたぶん仕事で
よく書いてるのはアルゴル系のプログラミング言語
とかから
高級言語と呼ばれているものから
自然言語で書けるようになったんじゃない
みたいな話があったけど
さらにその上があるのかな
みたいな気が今若干ちょっと考えて
draftcode
マイクラの例から
nishio
上とは何かってことだよね
訓練されてない人間にとって
より訓練してなくても
自然に使える方向に寄ってきたのが
自然言語だと思うので
より効率よくとか正確に
言葉を伝えようと思ったら
人間の側がガイン言語を学習する方が
いいと思うし
自然にっていうことで言うならば
キーボード叩いてテキスト入力してることが
全く自然ではないので
喋ったり
喋らなくても振る舞いを見て
この人は今何何したに違いないって
スマートスピーカーにカメラもついていて
起きてコーヒー入れ始めるから
3分のタイマーをセットしておきますね
みたいな感じのことを
向こうからしてありがとうみたいなことを言うと
3分後に
30:01
nishio
2枚コーヒーの話したのに3分って言ったら違うな
カップルヌードルだよね
そういう方向に
訓練されてない人間がコンピューターを
使えるようにっていう方向になるんだったら
そっちの方向に行くんじゃないのかな
指示しなくても一心全心
っていうコンピューターの側が何を求め
人間が何を求めてるかを
汲み取るという形になっていく
Yoshiori Shoji
ってなると
その自然言語で
プログラミングを書くみたいになるの
世界は
今言った西尾さんの話だとさ
そのコンピューターに寄り添わない側の
人間なわけじゃんその人たちは
コンピューターが寄り添って
何とかさせてくれる
っていういわゆる普通の人だよね
多分プログラミングを
書きはしないよね
nishio
普通の人は
プログラミングをするようになるかならないか
それプログラミングの定義次第だと思うけど
我々が思っているような
プログラムのコードを書くのではなくて
もっと楽な方法で
コンピューターに指示を出して
コンピューターを使っていく生活になるだろうね
draftcode
なんかエクセルの
マクロ録画みたいな
感じの
僕たちは多分エクセルのマクロの
やつを
マクロを記録するやつ
マクロ記録のやつが
プログラミングとはまあ言わないんだけど
プログラミングと言っても
いいかもしれないねっていう感じの
リラックスでは
そういう感じの感覚になるのかな
マクロを
書くっていうのとはまた違うけれども
その
なんかプログラミングかどうかは
ちょっとわからないけれども
まあ機械に指示させて
なんかやってもらうっていうことが増えるっていうのは
nishio
あるのね
なんかあのWindowsとかでも画面操作を
記録してそれを再生してみたいなアプリが
あったりするわけだけれども
それで記録したことって現状だと
記録したものそのままこう
リプレイするということしかその持ってないわけだけど
そこをこういい感じに理解して
ちょっとこうディスプレイ
ダイアログの位置がずれていて
この人はOKボタン押したかったんだなという意図を汲み取って
OKボタン押してくれるという風に
コンピューターの理解力が高まっていくと
プログラミングをしないけど
コンピューターに指示を出して使っている人たちの
やりやすさがどんどん上がっていく
draftcode
まあそういうのを
そういうのを何か生業としている人も多分いると思うけど
まあそういう分野って
あんまりその本当にプログラマー
プログラマーが多いかと言えば
そういうなんか画面の自動化とかそういうのできるんだけど
果たしてそれが合理的かっていうと
まあそこまで合理的ではないみたいな感じの
微妙なニッチの分野
そのニッチとも言えないかな
プログラマーを雇うものではないけど
プログラマーがいなければできなかったことっていう分野が
先になんかどんどんどんどん
自動化されていくっていうのは
なんか割とありそうな感じだし
Yoshiori Shoji
それはありそうな気がするね
nishio
なんか需要の規模が小さすぎて
プログラマーを雇って作らせるには
コストがペーしないという状況
なんでプログラマーがプログラムを作って
それを販売するかというと
そのプログラマーを使うことによって
価値を感じる人がどっさりいるから
手間をかけてプログラマーを作ってから
33:01
nishio
それをコピーして販売するというビジネスが成立するわけじゃないですか
なのでということは
それが成立しない
マーケットが小さすぎてできてなかった状況っていうのは
大量にあって今まで取りこぼされてるはずなんだけど
AIによって
プログラムというかコンピューターに対する指示を
作ることがガッと下がると
この新しいちっちゃいニッチな
今までだとマーケットが小さすぎて
ビジネスになってなかったところが
自分でやるんだろうなって気がする
draftcode
そういうかビジネスにならずに
単純にいろんな人ができるようになってしまう
nishio
という感じかもしれないけれども
いろんな人が自分でやるようになってしまう
とはいえ
GPTにチャットで指示をすることすら
嫌な人たちというのが世の中には
多分50%くらいいて
その50%の人向けに
代わりにチャットGPTを使って
やってあげれるというプログラマではないけれども
AI使いの得意な
AIやみたいな感じの人が
プロンプトエンジニアみたいな
そうそう
価値を生むんだったら対価をいただくということで
ビジネスが成立するみたいな感じになる
Yoshiori Shoji
でもソフトウェア
draftcode
前から言われてたけども
ソフトウェアがいろんな産業を食っていくというのは
そういう意味では結構加速していくのかもしれないですね
ソフトウェアエンジニアが
受益者じゃないかもしれないけれども
いろんな人がセミプログラマーみたいな感じの
ことを
いろんなところで視察というのはあるのかもしれないです
そういう意味では
パイは広がっている
パイは広がっているし
果たしてソフトウェアエンジニアの職業が
それで
一部なくなっていくかもしれないけども
全体のパイとしては大きくなっているのかもしれないし
何なら
最初
GPTとか何かよくわからない
画面のクリックするという自動化をやった後に
いやーこれもうちょっと
ちゃんとしたことをやりたいってなって
じゃあやっぱりソフトウェアエンジニアを雇わないといけないね
っていう風になって
ということが出るっていうパターンもあるのかもしれないですね
nishio
なんかパイが
広がるか狭まるかっていうのが
誤った二分法だなと思っていて
パイは少なくとも移動するので
このカバーされなくなった領域は
明らかに減っているし
新しくカバーされるようになった領域っていうのは
明らかに増えている
それぞれの人が例えば移動されてなくなる領域のところだけ
見てる人からすると
なくなってしまったように
減ったように見えるわけね
そういうところを見てる人にとっては
新しいものが生まれたように見えるみたいな
draftcode
パイの移動っていうのが起きるんだと思う
Yoshiori Shoji
そうですね
だんだん
コパイロットからAIがプログラマを駆逐するか
みたいな話になってきたんだけども
実際問題
多分
俺は別に
そこを恐れていないのよ
でもさ
インターネットを見ると結構
これもういらなくなるんじゃないか
みたいなのが見えるじゃん
うん
具体的にそこの
俺は思ってないって言ったら
今二人ともさ俺も俺もみたいな感じだったじゃん
この感覚の違いは逆に
何から生まれてるのかな
nishio
っていうかさ
36:01
nishio
実際問題としてフォートランが生まれたことによって
機械合格プログラムはいらなくなったわけなんだけど
大部分のケースにおいて
一応リンクする一部の人が覗いていられなくなったんだけど
それで何か市場の
問題があったかというと
それしかできなかった人は影響を
食らっただろうけれども大部分の人は別のことを
やるようになっただけなので
多分今後のAI
今後5年間で大きな影響を
プログラミングに与えるんじゃないかという気はしてるけど
それでなんかAIを使ったりして
より効率より何か
価値が発揮できることをよりたくさんやるようになって
そうでないことを
例えば具体例を言うならば
ツリーファラムにしてって言ったらCSSを
べべべっとAIが書いてくれるので
CSSを書くことに割く時間は減って
他のことやることが増える時間が増える
ということになるだけだと思うんだよね
そういう風にスムーズに移動するだけであって
何の問題もないんじゃないかなという風に僕は思って
draftcode
はい
僕は
同じことを言っているのかもしれないけれども
人によって
ソフトエンジニアっていうものが指すものが
結構違っていて
ソフトエンジニアが何をやってるって結構
センスは別だったりする
会社によっても違うし国によっても違うし業界によっても
違うので
全てなくなるというか
定義が変わっていく
っていう分野もあるかもしれないし
あんまりいかないよねっていう感じの
人もいるんだと思うんですよ
例えば
何だろうな
ずっと20,30年ずっと分散システムをやっていて
分散システムのデータベースの
うまくレプリケーションがいろんな
動くってやつを書いていて
それがちゃんと仕様としてうまくいってるかを
検証しまくっていますみたいな感じの人は
しばらく心配しなくてもいいんじゃない
みたいな感じの
そういう話だよね
それに対して
割と
さっき言った
本当にすごい詳細資料を
コードに落とすみたいな感じの
やってた人はどちらかというと
コードパンチャーみたいな感じの
ポジションになっていて
なくなるかもねみたいな感じの
そういう感じに
nishio
両方ともソフトエンジニアという
draftcode
言い方もできるけれども
やってることは結構違うよねっていう
nishio
話はあるんだと思うんです
ソフトエンジニアという言葉って
すごくいま漠然とした広い言葉であって
本当はもっと細分化されていて
例えばエスプレッソエンジニアとか
そういう
なんでエスプレッソと話したかというと
去年の
最多の中にエスプレッソの
マシンをハックしてめっちゃいい感じの
クリーム層の厚みになるようなものを
作りますみたいな研究があって
合わせてもらったらめっちゃ上手いんだけど
ということは価値を発揮しているわけなのね
エスプレッソエンジニアリングできるエンジニアって
多分日本にその人1人かもしれないけど
あと2,3人くらいもしかしたらいるかもしれないけど
ぐらいの時なので
彼はすごいきちんとした専門性を持った
エンジニアであるという
ソフトエンジニアという漠然としたものよりも
もっとはっきりとしたドメインに特化した
知識を持っていてっていう
そういう感じのエンジニア
新しいエンジニアがいるわけなんだけれども
そういうような感じでもっと具体的な
ソフトエンジニアっていう国が
39:01
nishio
漠然としすぎであって
もっと細かく細分化されて
一部はなくなって一部は成長する
みたいな感じになるんだろうなっていう気がする
Yoshiori Shoji
はいはい
今の話を聞いてちょっとなんか
逆に面白いなと思ったのは
ちょっとその
ソフトエンジニアがなくなるかなくならないかの
話ではないんだけど
そのエスプレッソがすごい上手く入れられる
マシンを作っちゃったら
今頑張ってエスプレッソを入れている人たちは
ソフトウェアでそれが制御できてかけてしまうと
コピーは容易なわけじゃん
それを採用して
各エスプレッソ屋さんの
チェーン店の各店舗にそれを導入することが
可能なわけじゃん
実際に西尾さんが飲んでみてめっちゃ上手いって感じるぐらい
エスプレッソが常にそこから出てくるようになるわけじゃん
nishio
なるほど
中小的な話じゃなくて
あえてその具体的な話を掘り下げるのが
面白いと思うんだけど
物理的なハードウェアをハックするところにすごいボトルネックがあって
ソフトウェアと違って複製できないんだな
物理的なエスプレッソマシンというのが
マシンはソフトウェアだけじゃないんで
マシン自体も複製しないといけない
というのがまず1ポイントと
その機械が何をするかというと
これくらいのクリーム量にしてくれ
という人間の指示に従って
それを制御していい感じのクリーム量を増やした
温度と
温度と
水の出し方の調整を
してくれるというにすぎないので
それはツールなんだよね
それをどう使ってどのような演出をするかというのは
人間のすごい工夫のところに委ねられている
というところの
そういうのがありなので
今のバリスタが必要なくなるかというと
バリスタの中で
特定のパターンの
作業をするだけの人っていうのは
いらなくなるだろうけど
現状の大部分のバリスタはそうではないので
別に失われはしないというか
仲良くやるみたいに見えるけどね
Yoshiori Shoji
なるほどね
さっきの
バリスタの例でいうと
コーヒーの味を聞いたりとか
お客さんはちょっと濃いめを飲みたいだろうな
とか苦めを飲みたいだろうな
までさせてちょっと調整できるみたいなのは
バリスタの能力として
nishio
僕のコーヒーの知識が
少ないのでうまく説明できないんだけど
この豆をこうこうすると
なんとマンゴーの香りがするんですよ
試してみませんかみたいなことを
言ってくるわけなんだけど
僕は知らないから
ぜひやってみたいですみたいな感じのことを
言って飲んで
これとこれ味違いますねみたいな感じの
そういう楽しいエクスペリエンスというのを
提供していただくという
ことが起きるんだけど
そのプレゼン能力の部分は全然機械の
機械ではなくて人間のどちらかというと
演者の能力のような気がする
draftcode
なんとも言えない感じがしますね
今だって多分
世の中の高校生みんな
なんか割といろんな人が
スターバックスで働いてるけど
みんな高校生がバリスタと呼ばれていても
そういったレベルになってるかって
別にそうではないし
スターバックスに行く人はみんな
それを求めてないわけじゃないですか
一概にボタンっぷりで
すっげーうまいエスプレッソができるようになりました
42:00
draftcode
しかも格安になった
っていう風に言っても
ネスプレッソとか世の中にたくさんあるけれども
それによって世の中のコーヒー屋さんが
なくなったかっていうと
全然そんなことはなくて
何だろう需要とかが広まっているんだけれども
なのであんまり単純に
これによって
この機械、この発明によって
何かが改善
理論的にはリプレイスできるっていう風に
そのスコープだけ見ると
リプレイスできるみたいな感じで思っていても
そんな狭い領域で動いていない
みたいな感じはしますね
なんでこれだけネスプレッソが
うまく、これだけおいしい
エスプレッソが出せるようになってるのに
なんで未だにスターバックスの
コーヒーマシンはネスプレッソじゃなくて
この豆からひいてる何かなんだろう
みたいな感じになるわけです
なのでもうちょっと
いろんな必要な要因があるんだろうな
nishio
っていう感じがします
コーヒーということに関しても
実はすごく細分化された顧客のニーズとか
技術とかがあって
それで一部の領域は機械でリプレイスされるけど
残りの部分のいろいろリプレイスされないものは
どっさりやってみたいな感じのことなんでしょうね
結局
そんな世の中がシンプルじゃなかったから
一部がこう
部分的にしか置き換わらないんだろうなっていう
結論
Yoshiori Shoji
今のちょうどコーヒーなので
コーヒーの例で話していくとさ
例えば俺は毎日
コーヒーを豆からひいて
ハンドドリップで
nishio
入れるのよ
僕より詳しい人だ
Yoshiori Shoji
これは俺は
所作も含めて好きなんだよね
お湯沸かして
ポトポトポトって垂れている
あの待ってる感覚も含めて
あそこでいろんなこと考えたり
そういうのも好きだから
所作含めて好きなんだよ
ちょっとこう話を聞いてて
それを思って
こう思った
もしかして
プログラミング言語を書くっていうことが
そのなんていうんだろう
その所作を含めて好きみたいな
趣味の領域になってくるっていうのはありえるのかな
nishio
それはあるんじゃない
draftcode
だっていまだに
いまだにだってマニュアル車を
運転してる人いるわけで
だって僕マニュアル免許持ってないんだけど
こんだけさ
オートマしか売ってなくてさ
マニュアル車買うためにさ
余計なお金払ったわけで
それでも趣味の領域じゃん
それでもやっぱり世の中に
一定数いるんで
どんだけ自動化されても
プログラミング言語を書くの
プログラミングを自分で一人でやる
好きだよっていう人は生き残るんじゃない
nishio
自分で作業をして
世界に影響を与えるということに対して
の楽しみっていうのがあるよね
自分がこう作ったんだっていう
自分に帰属しているものってある感覚がある
っていうのがすごく楽しいんじゃないのか
Yoshiori Shoji
俺にとって大多数の
プログラミングの
楽しみの大きいところって結構
そこなんだよね
一番最初のハローワールドを書いて
ああ動いたのところも
そうなんだけども
45:00
Yoshiori Shoji
自分が書いたものが影響を及ぼして
何かが発生している
その感覚がプロンプトエンジニアになった時に
持ち続けられるのかな
っていう
もちろんお前が書いてるのだって
高級言語であってそこからどうマシンゴになって
マシンがどうやって
動いてるのかまで理解しないで
言ってるじゃんって言われればもちろん
そうなんだけれども
さらにプロンプトエンジニアになって
プロンプトだけ書いて何回か実現された時に
世の中に影響を与えて楽しい
ってなれるかな
っていうところにちょっと今
何か
nishio
っていう疑問を思った
それを言うと何に楽しさを感じるか
めちゃくちゃ人次第で
世の中の大部分って我々みたいにものを作ることを
喜びとしていない
商品を買ってきて消費して
コンテンツを買うお金を払って消費する
ことで楽しめる人の方が
人々のホームエンサビエンスの中で圧倒的に多いわけなんで
我々まずここにいる
このプログラム作って楽しい人間が
マイノリティだから
そんとこはどうなるかどうやら
我々の楽しみが奪われないといいですね
みたいな感じだよね
draftcode
だからあれだね
ちょっと近いのはあれだね
マネージャーへの転向ってそういう部分が大きいよね
なんかハンズオンで
プログラムを書くんじゃなくて
仕事の質も違うんだけど
自分がハンズオンでコードを書かない
っていうのに耐えられないっていう
やっぱ自分で
最後のものを使うものを
したいっていう人はやっぱり
ソフトウェアエンジニアの中でも多いわけで
なんかそれに近いものを感じる気がする
そういう人は別にコード書けばいいんじゃん
別にいいんだよね
それでパフォーマンス出ればいいんだよ
別に自分でコード書いてさ
周りが別に自動生成してるかもしれないけど
自分はもうこれでいける
これで10倍の生産性あるんだって
nishio
それで出せればいいんだよ
自分で書いたコードで生産性が周囲のAIで生成されたのに
低いということが突きつけられた時の
自尊心の失われぐらいが心配だね
怖いなー
ありがゆる未来でめっちゃ心配
お前のコードはコパイロット以下やん
みたいな感じに突きつけられる
draftcode
多分コンパイラが発展する過程で
nishio
なんか俺はこう
すごい早い機械語のコード書けるんだって
自信持っていたおじさんが何人か
自信を失って去っていったんだろうな
って気がするよね
なんか俺それでさ
Yoshiori Shoji
今ふっと思い出したんだけどさ
15年ぐらい前
パイスパかなんかで
西尾さんが
Cプラかなんかで書いた並列処理を
ハスケルで書き直したら
ハスケルで書いたほうが早かったみたいな
ハスケルコンパイルされたコードのほうが
早かったみたいなの
nishio
なかったっけ
僕ではないと思うな
僕はそれはやってない
Yoshiori Shoji
誰かこいつの人がやったかもしれないけど
nishio
でもそういうことって起こりうるわけね
Yoshiori Shoji
そうそうだから
でも今でもあるよねとは思っていて
そのね
なんか並列処理に特化した言語で
特化はしてないけどもハスケルは別に
特異な言語でやったほうが
そうじゃないもので
自分でゴリって書くよりは早いみたいな
特に今
48:00
Yoshiori Shoji
メモリ管理なんか人間がやるより
コンピューターに任せたほうが絶対いいもんね
nishio
うん
やっぱり人間の側がプログラミングの
パラダイムを変えて書くのに
すごいオーバーヘッドがでかいわけね
なんか今までの慣れ親しんだ
手続き方すっかり忘れて
全く副作用が発揮できない
関数型の言語でこれ書いてくださいって言われたときに
ちょっと人間としては
移動するのにコストがかかるわけなんだけど
コンピューターがそのコストなしに
すっと変わってくれたりするわけなので
そうなってくると
より良いパラダイムというのが
人間には習得困難なんだけど
より良いパラダイムというものが発生して
AI、コンピューターはそれをサクサク書けるんだけど
みたいなことになった場合に
人間がパフォーマンス出せなくなっていく
って書いてあるアリエルよね
特に人間が増えているような
分散並列プログラミングのあたり
っていうのは
より良いコンピューターにとって
より良い人間にとってそれほど理解が容易ではない
パラダイムというのが生まれうるよね
draftcode
かもしれないし
分からない
現状の
僕は今パイロットぐらいしか使ってないけど
僕の現状の認識の
機械による生成の認識っていうのが
まあ
オートクルーズだな
みたいな感じの
今テスラが自動運転
テスラも自動運転カーとかあるけど
そこら辺で
自動運転タクシーとか乗ってるけど
オートクルーズから自動運転までいくのって
かなりのギャップがあったわけなので
そこまでたどり着けたら
いいねって感じするけど
まだまだギャップはあるのかなっていう感じも
するけれども
何ともわかんないです
Yoshiori Shoji
加速していくのかもしれないし
nishio
まだまだ
でも型を付けて
変数宣言するのめんどくさいから
動くほうがいいぜって
ライトウェイトランゲージの
ブームが起きたのって
何年くらい前?15年くらい前?
15年くらい前だったと思うんだけど
そのときなんでそうだったかっていうと
型を付けてコンパイルすると
オーバーヘッドがでかいから
それよりもそんなことしなくても
動くやつのほうがいいよと
実際の実行時間が遅くても
そっちのほうがいいよってなったわけなんだが
今逆に型付けるゾーンになってるじゃないですか
振り戻して
振り出せるエンジンというのが早くなったことによって
IDの裏で走らせてサジェストしてくる
ということができるようになったことによって
型付いてたほうが人間にとって幸せだよね
となって
型付けたほうがなったわけなんだけれども
Yoshiori Shoji
それと同じように
それはなんかちょっと認識の違いがあって
15年前でも
型付きの言語だとID使えばちゃんとサジェストしてくれてたぜ
nishio
きれいに
Yoshiori Shoji
だから
そっちじゃないんじゃないかな
っていうより戻しがあったのは
俺の認識だとより戻しがあったのは
動的片付け言語のほうが
結局静的片付け言語で書くのって
型を書くのが冗長で
プログラミングを書いてる人間は
だいたいもう自分型分かってるんだから
分かってることわざわざ書かなくていいよね
で動的片付け言語になってたんだけど
結果どんどん長期メンテナンスする
51:00
Yoshiori Shoji
でかいソフトウェアが増えた結果
そういうでかいソフトウェアを管理するのに
型がないってやっぱつらいねってなって
戻ったっていうのが
俺の認識なんだけど
nishio
じゃあそうかスクリプト言語が
便利だねって使われるようになった結果
みんな想定以上に大規模なものを
使い始めた結果
型がないと破綻するぞとなって
型が必要になった
draftcode
そんな気は確かにするね
あと
こうね
さっきのフォートラン
パスカーだっけ
機械生成したやつよりも
人間が書いたほうがいいことになるぜ
みたいな感じに思ってた
結構
ここら辺の進歩って
機械でやるよりも
人間がやったほうが
早いコードを開けるみたいな感じの
ことが多かったのかな
っていう感じがしてて
速度がトレードオフだったんだけども
このAIの
コパイロットとかの生成によって
速度というよりかは
正確性がトレードオフになること
っていう感じが僕はしていて
それをみんなどれくらい
受け入れられるのかな
っていうのはちょっと
Yoshiori Shoji
僕は分からないなっていう感じがしますね
嘘をつくのを受け入れられるかどうか
draftcode
そうそう
大体うまくいってるみたいな感じのパターンとか
それは別に人間側でも
大体うまくいってるんだけど
こんなのあったねみたいな感じに
あるかもしれないけども
nishio
そういうパターンが
draftcode
多分あると思うんですよ
単純に生成するっていうのが
nishio
何とか人間も
たまに間違えてるんだけど
人間がどれくらいの頻度で間違えてるかって
あんまりきちんと
エンジニアリング的に管理されてなかったけど
AIの側何パーセント間違えていて
どうしたら何を変更したら改善したか
っていうアップデートをかけていくことができるので
このアップデートかけて変わっていくことができる
AIという存在とかけていくことができない
人間という存在のどっちが
draftcode
なんとも分かんないですね
上がっていくかもしれないけど
どっかで幸るっていう可能性もやっぱりあるよね
nishio
人間よりも下で幸ったならば
その時は
人間の代わりにならなかったね
ってなると思うんだけど
人間の下で幸るに違いないという想像は
すっごい楽観的な予想に過ぎて
僕は何とも考えない
Yoshiori Shoji
それなんか結構さ
自動運転の責任問題と
同じ気がしていて
今ですらさ
車自動運転させた方が
人間より事故率低いわけじゃん
でもみんなそこに
自分に全幅の信頼を置いて
自動運転だけでいいですってならないのは
じゃあそうなった時責任どうするの
っていう問題なわけじゃん
結局
コードもぶっちゃけて言うと
もうすでにそうなってると思うのよ
多分ドラフトコードもそうだと思うし
日照さんもそうだと思うんだけど
コード書いてる時にちょっとしたタイポがあって
コンパイラーに指摘されて直すみたいなこと
めちゃめちゃあるじゃん
もちろん一回もデリートボタンも押さずに
書いたものがいきなり動くことなんて
ないじゃん
でもAIは少なくとも俺らよりは
54:00
Yoshiori Shoji
確率高く一発で書いたものが動くことを
出せるじゃんもうすでに
間違いないっていう意味で言うと
もうすでに
頻度で言うと間違いないんだよね
人間より
多分
nishio
書き方によるとは思うけどね
面白いことは分かる方向性としてはそんな感じである
Yoshiori Shoji
そうだからその間違えた
コードを書いた時に今さお前やっぱ
バカだなって俺はやっぱりAIのせいにするわけよ
自動運転の時に事故が起きた時に
これはAIが悪いからじゃん
ってなるわけじゃん
そうなった時に
AIは責任を取ってくれないわけじゃん
っていうところが
なんか結構
壁があんのかなっていうのを今
nishio
ちょっと話して思った
でもそれに関して言うと自動運転カー保険というものに入って
自動運転カー保険の方が人間が運転している
カー保険よりも安いですとなった場合に
発生確率が低いんだったら
正当な
値付けをするとそっちの方が保険安くなるよね
そうなった時に
人間どっち選ぶんだっていう
事故が起きてからの判断にすると
俺は悪くないってなるけれども
その手前の自動運転を
使わない段階で保険料の
こっちの方が安いですよどっちにしますか
みたいな感じの選び方をすると
人間は相当スムーズにAI使うの方が
安いからじゃあこっちにしようって
Yoshiori Shoji
合理的判断をするんじゃないのかな
さっきこの議論の始まりに
ドラフトコードだったら
今まで
信頼性を信じれるって
日本語が変だな
nishio
正確性があるぐらい
必要かっていう話だね
Yoshiori Shoji
もうすでに
結構信頼性
高いかなっていう気もするんだけども
かといって
なんだろう
ノーチェックでコミットプッシュできるほど
ではないよね
draftcode
それはそうだね
そういうところだよね
Yoshiori Shoji
そうそう
ノーチェックでコミットプッシュまで
いけるところまで来るのかなっていうのは
draftcode
どこまで
走るかっていう感じの話
nishio
チェックとは何かによると思うんだよね
それが
AIがプロディスク作って
それを入れた時にどうなるか
テストの書き換えテスト全部走らせて
テスト全部パスしましたまでいったら
もうプッシュしていいんじゃないかみたいな
テストできる手段をどうやって作るかって
実感じゃない
draftcode
テストは今度AIが作るから
実装もAIが作って
nishio
テストもAIが作って
draftcode
通ってる
多分大丈夫
nishio
今まで先頭だよね
ユーザー環境でエラーが起きたのか
戦闘技とかに入るやつもAIが見ていて
プロディングを作って直すところまで
全部やってくれるとするならば
Yoshiori Shoji
でもさ
nishio
人間はそのマッチポンポンしてるわけじゃん
一人の人間が
そうそう
Yoshiori Shoji
そのためにコードレビューをしてるわけじゃん
人間ですら信用できない
っていうか多分みんなそうだけど
自分自身すら信用できないから
誰かこのコード見てよがコードレビューなわけじゃん
ってなると
人間の代わりにそこまでは行けるのかな
57:00
Yoshiori Shoji
結構早めにっていう気はするよね
いきなり
nishio
人間に対する信頼が低ければ
AIがそれと同等になるのも早い
draftcode
人間もどうせ間違えてるんだし
nishio
間違えたコードを入れてしまったから
間違って立てて直すことがあるっていうのを
AIも同じように許容してあげれば
そうそう
割と早く実情的な段階になるのでは
そう
そこの許容がなかなか取れないのって
Yoshiori Shoji
何が原因なのかなっていう
人間がそれやってたら別にみんな許容するじゃん
例えばさ
西尾さんがなんかコード書いてきてさ
大体動くんじゃねって
俺がアップロードしたら
実際本番に入れてさ
なんかエラー出たねって
ここなんかちょっとエラーが出たから直します
ってプルリク来て
じゃあまたアップロードしますみたいなのって
正直仕事してる日常であるわけじゃん
それを受け入れるわけじゃん
AIだとなんでそれが受け入れられないんだろう
キャラクター制だと思ったから
AIにまずドラえもんの顔つけると
nishio
ドラえもんなから仕方ないか
すごくいい道具出してくれることはあるけど
基本ポンコツだよねみたいな感じになるので
ドラえもんの顔つけると
キャラクター制が大事ね
可愛い少女キャラクターの顔つけるでもいいけれど
Yoshiori Shoji
なんかちょっとポンコツなキャラの
nishio
絵をつければ
なんか今それを聞いて思い出したのが
日本だとさ
最近こうなんかレストランとかで
Yoshiori Shoji
物を運んでくれてくれるロボットあるじゃん
あれが猫になってるじゃん
でなんとかにゃんっていうのは
あれは猫のキャラ付けしておくと
ちょっとぐらい失敗したりしても
みんな多めに見るかららしい
みたいな感じで
だからなんか
nishio
AIにキャラ付けするのは
Yoshiori Shoji
実は結構大事なことなのかもしれないね
パイロットにならないね
nishio
まあこれは
Yoshiori Shoji
期待値調節
draftcode
期待値調整の問題
ではあるのかなって感じはする
100%はない
人間も100%はないし
AIも100%はないんだけども
みんなさまざまなコンテクストで
期待値がちょっとバグっていて
なんか
100%じゃないといけないんだみたいな感じの
パターンもあるし
100%じゃないのに
人間は100%に近いみたいな感じに
思うパターンもあるので
期待値調節が
うまくいっていない
それがうまくいくかどうかは分かんないけども
そういう話になるんじゃないかな
そこでキャラ付けをすると
期待値がちょっとゆるい方向に
行くのかもしれないけど
nishio
多分この1年間AIがものすごく
期待値が高まって
期待以上に期待値が高まってる人が
いっぱいいる状況で
あれ思ったほど使えないぞって言って
減滅器がスタートする
とはいえ正しい値は
中間のところにあって
この程度のパーセンテージであったら
うまくいくし
効果を生むぞっていうラインを
制御みたいに揺れながら
人間が寄っていくんだと思うんだけれども
期待を持ちすぎている人も
ずれているし
期待を持たなすぎている人もずれているので
どこまでのことができるかというのは
1:00:00
nishio
実際使ってみて観測しないとわからないことだと思うので
みんなもっと使ってきていいのになと
個人的には思ってるっていう感じです
Yoshiori Shoji
はいはい
じゃあ
ちょっと話を変えるんだけども
実際に
実際に
良くなってるみんなの生活はっていう
そのAIには
ここで言うと
一旦LLM的なAI
ジェネレーテッドなAIに限って
言うと
nishio
めっちゃ良くなってるポイントがあって
めっちゃ良くなってるポイント
何かというとプログラムを生成する側ではなくて
論文を読ませて
要約させるとかそういう使い方にめっちゃ便利で
ちょうど最近
会ってたんだけどクラウドのオーパスと
このあれを契約して
50ページくらいある数式まみれの英語の論文が
僕が読むと
すごい時間がかかるわけなんだけど
えいって投げつけて
どんな感じの話の流れか説明してって言ったら
出してきて出してきたものを見て
ここの部分ちょっと僕分かんないんだけど
詳しく説明してみたいなこじ下げて聞いて
繰り返して言ったら
50ページの英語の論文を読むのに
40分で読むのって大変じゃないですか
それが40分で僕が納得するところまで
なるほどねって結論になって
段落っていうところまでいけたので
俺はなんかもうこれを使わないで
もう一回論文を
単独で読めっていうのをやらされるのはやだなと
すごく良くなったなと個人的に思って
僕の人生の
良くなったポイントってのはそこだね
圧倒的に英語の論文ガンガン流し読みできるようになったし
英語の文系のサーベイとかもしやすくなった
なんか
Yoshiori Shoji
その
俺の場合なんだけど
Googleを使う頻度が結構減ったなと思っていて
nishio
めっちゃ減った
Yoshiori Shoji
今までだと
Googleに聞くしかなかったようなことが
Googleに聞かなくて済むようになったんだよね
うん
で
そこでちょっと俺の中で
ブレイクスルーが一個あったなと思うのは
今までGoogleで聞く時って
Googleの検索ワードに検索キーワードを入れるから
知らないことは
聞けなかったのよ
なんだろう
ノンアンノンは聞けるんだけど
アンノンアンノンは聞けないっていう
nishio
なんか言葉は分からないんだけど
こういう風な雰囲気の概念ってありますよね
何しらこうした時にこうなるという現象について
なんか名前ってありますかねみたいな
そういう質問の仕方ってGoogleで検索するのは難しかったけど
そうそうそう
draftcode
今は結構自然言語検索の方が
そうでもない感じ
Yoshiori Shoji
そうなんだ
いや俺分かんない
nishio
俺はおっさんだからまずGoogleはそういう使い方してないからさ
検索エンジンでキーワードを入れてしまうというのが
draftcode
実は古い行動様子
nishio
結構古い行動様子
先読できてないけど僕もみたいな
draftcode
それは
その話を
なんか
事前メモで出てて
なるほどねっていう風に思って
Googleサーチそれくらいしてんだろうって見てみたら
3週間で
70回なのよ
で自分そもそもLMとか
チャットGPGとかほとんど使ってないので
なんかそもそも自分Googleサーチをしてないな
っていうことがなんか分かって
1:03:01
draftcode
なるほどね
割と結構もう
ソースコードを読んでしまったりとか
公式リファレンスをそのまま直接読んでしまうタイプの人間だったので
なんかあんまり
そもそも仕事に使ってないな
みたいな感じがすごくある
プライベートでは全然多分別
もっとなんか
違うことを検索してるけれども
nishio
仕事のPCで限って言うと
draftcode
そもそもなんか検索してなくない?
っていう感じがすごくあるから
なんか開発方式が全然違う感じがするな
っていう感じがする
Yoshiori Shoji
なんかそれで言うと
なんか俺がそのやったやつは
本当にサンプルでわざと
チャットGPGに聞いたやつ
実際に自分で知ってるんだけども
わざとチャットGPGに聞いたやつなんだけども
面白かったのが
システムDを使いたかったんだよね
でもシステムDって俺は
単語知ってるからググれるのよ
でも知らない人間って
これチャットGPGに聞いたらどこまでたどり着けるのかな
と思って
パソコン起動したら自動的に起動して
動いといてくれるプログラムって
どうやったら書けますかみたいなのを
チャットGPGに聞いたのよ
そしたらすごい丁寧にWindowsと
Macの例をまず出してきてくれて
すいません使ってるOSはLinuxなんです
って言ったら
こうなんか
Linuxでしたら
なんだったっけな
クーロンでアットマークリブートっていうのがあって
それを使うこともできますみたいな
アットマークリブートなんて俺知らなかったわと思って
それと一緒にシステムDとかも紹介され
最後のところに
今だと標準的にはシステムDを
使われることが多いので
それを使うことをお勧めしますみたいなことまで
言ってくれるのよ
これ本当に
システムDについて何も知らなくても
ここまではたどり着けるんだっていう
発見
知らないことをちゃんと調べられるなっていうのは
すごいなって思った
ただ
nishio
吉井も多分
draftcode
Google検索に
How can I start a program automatically on start
とか入れてみると
ラリと出てきてするので
nishio
なるほどね
Yoshiori Shoji
あれか
俺がチャットGPTに聞いてる質問を
そのまんまGoogle翻訳に入れてみればいいのか
nishio
Googleの検索などに入れてみると
draftcode
なるほどねっていう感じがする
多分対話的かどうかっていうのは違うと思うんだけど
実際にリングの検索とかはあれだよね
検索のところに対話的かどうかっていう風に
入れてるだけで
多分そこまで
結果の表示の作り方は違うけど
データソースとしては同じなんだろうなって感じはする
Yoshiori Shoji
あと俺が助かってるのは
俺はそんなに学がないから
機械学習の本とか読んでると
分かんない単語が
いっぱい出てくるんだよ
っていう時に例えば
EXP関数っていうのが出てきたんですけど
それ何ですかっていうと
教えてくれたりとか
その説明の中で指数関数ってなんだったっけとか
聞くとちゃんと全部教えてくれるのよ
っていうのを
本を読むとき
多分西尾さんの論文を読むのと一緒に近い気がするんだけど
本を読むときのちょっと分かんない単語を聞きながら
1:06:01
Yoshiori Shoji
本を読むとかは
めちゃめちゃチャットGPT助かるなと思ってて
分かる分かる
nishio
そこはなんか
特にデジタルのものを読むときに
直前のところペッとコピーして貼って
これのここっていうこの表現ってどういう意味?
みたいな感じのことを聞くと
別の言い換えをしてくれて説明してくれるので
分かりやすいって
この文章を書いとけよみたいな感じになる
分かりやすい説明が出てきたりするんだけど
なんかその
そういう文章を読むというか
説明することのアシストという意味で
すごい手助けになるなって感じはする
人間よりも早く読んでくれる仕組み
っていう機能があるよね
あと
Yoshiori Shoji
あとこれググれなかったな
ググれ
昔分かんない
今だとググれるのかもしれないけど
できなかったなと思ったのは
$150すらNIって書いてあるの表記があったのよ
うん
nishio
うんうん
Yoshiori Shoji
で
で出張かなんかでホテル探してるときに出てて
このNIって何?
っていうのが全然分かんなくてさ
NIだけでググっても絶対出てこないのよ
draftcode
パーナイトだよね
Yoshiori Shoji
そう
でそれをチャットGPTに聞いたら
一晩で150ドルっていう意味で
NIは何の略ですか?
って言ったらパーナイト
っていうのを教えてくれて
おーなるほど
っていうのとかは
そういう意味でチャットGPT
俺は助かってる
結構いろいろこうなんか今までうまく聞けなかったことが
なんか
短く聞けるようになったな感はある
nishio
なんかあの言葉
なんかこれを表現する言葉があったはずなんだけど
なんだっけみたいなのを聞くのにすごい便利だよね
それは
こういう意味ですかこういう意味ですかみたいな
いろんな案を出してくれて
さっきのなんか技術的な方法で
技術的にこういうことをやりたいんだけどって聞いたときに
候補を出してくれて
僕も最近ごく最近ね大規模な行列の
リストする最近の良い方法を教えて
っていう雑な質問を投げた結果
こうAppacheにはこれがあったとか
何々があったとか
リストばーっと出てきて
わーなるほど色々あるんだなどれを選ぼうかな
みたいな感じになるので
選択肢を選ぶ上での最初の
最初のサーベイというのに
すごい便利だなって思うんだよね
なんかGoogleで検索したときにさ上に出てくるものが
いいものかというとそうでもないじゃない
なので
まず検索する前にこの
検索した全体のマップを作ってもらう
的なところの支援にすごく
ハッピーかなって気がする
そこで出してきた案が本当にいいかどうかっていうのは
その後調べたり
ドキュメント読んでどんな機能あるか見たりとかっていうのは
していく必要があるんだけれども
気づいてないもの知らないものを発見するエンジンとして
めっちゃ便利だよね
Yoshiori Shoji
うん
一方でなんかちょっと思ったのはさっきのさ
NIとかもそうだけどさ
なんかそれっぽい嘘をつかれてたぶん
つかれてたら
nishio
本当に騙されるなと思ってた
draftcode
でもそれは
チャットGPTだろうが
1:09:01
draftcode
なんかGoogle検索だろうが
なんか
騙されるとか騙されるような感じはするよね
nishio
聞いても騙されるから
Yoshiori Shoji
少なくともさ
言い方悪いけどさ
Javaプログラミングのこうこうこういうことをしたいみたいなの
検索したときにGoogleって
大量のクソみたいなスタックオーバーフロー
とかを拾ってくるわけだ
とか聞いたとかねよくわからない記事を大量にさ
なんか
ああいううぞうむぞうのなんかあんまり参考にならない
とか古い記事みたいなのよりは
チャットGPTに聞いたほうが
なんか有用な答えが返ってくることが
でも元ネタは一緒のはずだよね
って思うのよ
nishio
なんか
その理由がなぜなのかわからないんだけれども
たくさん読んでいることによって
そのたくさんの中で共通して
言っていることだけ抽出された結果として
あのしよう間接の
説明というのが消滅している可能性ってのがあるよね
あのなんかサンプルをさたくさん取って
平均したほうが正しい真の値に近い
っていうのと同じでさ
Yoshiori Shoji
そうそう
これすごい暴論というか
むちゃくちゃなことを抱くんだけどさ
だから僕らがWeb2.0でやりたかったことの
究極がこれなんじゃないと思っててさ
こうなんかさ
なんだろうWeb2.0で
なんか梅田もち男とかが言ってたのがさ
集合地とかっていう
みんなの手が集まったら
いろんな人が作れるみたいなので
インターネットAPIでつながってみたいな
でいろんな人が発信することによって
より良くなるみたいなことを
言っていたんだけども
結果気が付いたら人間が罵り合うだけの
こうTwitterが生まれたみたいな
ディストピアっぽい雰囲気が
一瞬来てたんだけれども
結果こうChatJPTとかLLMが
やってることって
大量のみんなの
それを集めて
nishio
やってることじゃん
まちがいなく集合地だよね
Yoshiori Shoji
集合地だよね
nishio
これはまちがいなく集合地だよね
Yoshiori Shoji
実はこっちだったのでは
みたいな
っていうちょっと
面白い
nishio
面白いこじつけが
Twitterから
全部LLMが先に読んで
綺麗に取り除いてくれた新しいTwitterを
作ってほしいよ
Yoshiori Shoji
そこに課金した
そうしたら何も残りませんでした
っていうのまで含めてSF調節として
nishio
ありそうだよね
ネタとしてはそれしたら何も残りませんでした
なんだけど実際のTwitter見てどうか
っていうとそうじゃなくてきちんと
良い情報発信をしている
例えば岡野原さんのTwitterで
論文を読んでその要約を説明してくれている
ツイートを淡々としてるんだけど
めっちゃ有益な
最先端の研究者が
最先端の論文を読んだ上で
ツイートにまとまるように解説してるって
めっちゃ濃度高いTwitterのタイムラインって
めっちゃこの
なんていうか
濃縮ジュースみたいな
濃縮ジュースって言ったら変な
濃い何かになるよね
書籍なんかよりもよっぽど濃い情報源になる
と思うんだよね
draftcode
逆な感じがしますよね
集合値というよりかは特定の
個人の
1:12:01
draftcode
頑張ったところがピックアップされるべきで
nishio
その個人の
頑張りに対して
良いリプライをつければそのリプライもそこに並ぶ
あれだけど
この主張は間違ってますよね
ああそうでしたみたいな感じでいい時があったら
それが流れてくるわけで
一人の人がメディアとして発信するんではなくて
誰でも発信できるようになっているというときに
Web 2.0のパーティステーションというか
みんなが参加できるメディアという
良さがあるんだと
みんなが参加できるように
本当にしたところ倍増減しか発信しない奴らが
世の中に意外と多かったのが問題なので
発信する
発言の
モデレーションがどうしても必要で
モデレーションとかを人間がやるのがしんどいから
AIがやったらモデレーションされた
綺麗なものだけが流れる良い
ソーシャルメディアが出来上がるのが
まともなメディアができるのではないという夢物が
draftcode
あれな
SFチックになってきましたね
AIがモデレーションしていって
nishio
AIが変更してるんだよねこの場合ね
絶対に
体制に反対するようなツイートが全部削除される
Yoshiori Shoji
わけだ
なんかディスト系
draftcode
SFにありそうだよね
これくらいのクリアランスだから
これくらいの発言はOKで
nishio
低いクリアランスだと
クリアランスで発言権はないみたいな
結局各国政府が各国の言語の
LMを作りたいのは何でかというと
特にコントロール主体
民をコントロール主体系の政府は
自分の国の言語を外国には
委ねたくないよねみたいなところはあるよね
Yoshiori Shoji
なるほどね
draftcode
それもさ
Yoshiori Shoji
結局そうなったら
濃縮還元ツイッターに
僕の発言が拾われるためには
どうしたらいいですかみたいなのも
AIに聞き始めるんだよね多分
nishio
発言が拾われるように
Yoshiori Shoji
フォーマットしてくださいみたいな
nishio
フォーマットで判断じゃなくて
人間性のチェックとかが入るから
あなたが
日々信仰心を正しく持って
日々良いコープナーをすれば
取り上げられるようになるでしょうと
AIが言ってきて
draftcode
新たな宗教が発生する
nishio
なんか
いいツイートをたくさんして
天に富を積むとあなたは
良い良いところに転生することができるでしょう
みたいなことをAIが言って
みたいな感じの状況になる
draftcode
なんかカオスなSFチックな
なんかそういう
Yoshiori Shoji
SFチックな
draftcode
ごめんどうぞ
何言おうとしたんだっけ
まあいいや
Yoshiori Shoji
じゃあ思い出したら言って
今ちょうどSFチックなディストピア的な
話になったからみんなが
たぶんちょっと冗談っぽく
言いながらも本当に心配している部分
要はなんか
AIが反乱を起こすとか
AIが自分で
自分を性能アップさせて
どうこうなるみたいな
そういう世界って
今もうおじいちゃんすぎて
その単語が出てこないんだけど
JPTに聞きたくてしょうがないんだけど
AIが反乱を起こす分岐点みたいなのあるじゃん
シンギュラリティポイントが
そうそう
1:15:01
Yoshiori Shoji
が来るかどうか
って
nishio
どう思ってる
シンギュラリティの定義次第で
シンギュラリティ
人間のホモサピエンスの中央地を超えた
知性のあるコンピューター
ソフトウェアができるっていうのは
いずれ来るというかもしかしたら
もう来てるかもしれないぐらいの
AIが反乱するとか
AIが人間に反響
じゃないのみたいな
ハミネーターとか
そういうのに影響されすぎないんじゃないの
っていう気がするね個人的にはね
Yoshiori Shoji
うんうん
draftcode
なんか
知性
っていうのがやっぱり
定義しづらいというか
計算能力はもうすでに
人間を超えてるわけですよ
nishio
何十年も前に
draftcode
知性かっていうかっていうと
いや知性と言えなくもない
nishio
でもやっぱり
知性の軸ゴールポストを動かし続けてるんだよ
人類が負けるたびに
ここは知性じゃないって言い続けてるんだけど
まず計算能力というのはあっという間に
負けたわけだよね
人間の計算師のお姉さんたちは
仕事なくなったわけなんだけど
その後Google検索が出てきたときに僕思ったのは
知識がたくさんあることを誇るっていうのは
ダサい時代になるんだなって思った
なぜなら僕が持っている知識よりも
検索したときにヒットして出てくる知識の
インデックスの中にある情報のほうが
圧倒的に多いんだから
そういう時点でも一旦
知識量という意味での知性は
人間は機械に負けてるんだけど
そしたら人間は知識がGoogleいただくものを読むだけのやつ
だから知識ではないとか言い出して
程度なら別のところにあるんだって言い出して
じゃあチェスとかそういう高度なゲームをするのはどうだ
って言ったらそれも負けて
っていうのがどんどん進んでいった結果
今最近のホットなのは
文章を書くことまで
知性というのはどこなんだ
これは知性じゃないんだ
ただ文章を見ていくと
いろんなところで人間の中央値は
すでに超えていっているので
人間の中央値を超えている軸が
どんどん増えていっているだけにすぎないから
ざっくり言うと
人間の中央値は超えるよね
というのが
超えるよねというか
いろんな軸において
すでに超えているし
まだ超えてないところもいずれ超えるだろうし
draftcode
ゴールポストを
ずっと動かし続けるのは
僕もそう思っていて
ただ動かしたところで
負けたっていう感覚が
みんなあんまないんじゃないかな
っていう感じが
ないことに分野がどんどん多くなっていくんじゃないかな
っていう感じがしていて
だって僕別に
計算機よりも計算が
遅いから
負けたっていう
お悔しいって思わないもん
計算機よりも
負けた悔しい
あんま思わないもん
Yoshiori Shoji
それはそうなんだ
俺もそうなんだけども
さっき30分くらい前に話したのを思い出してほしいんだけども
自分が書くコードより
良いコードを挫折されたら負けた悔しい
draftcode
って思うって話をしてたわけだよ
nishio
思うか思わないかというところは
1:18:01
nishio
結局どれくらいこだわりを
持ってたかだよね
自分が強い思いを持ってた人は
多分ちょっと嫌な気持ちになるんだと思う
まあでも
draftcode
時間がかかる気がするけどね
負けたって
そこまで悔しいと思うかもしれないけど
だったらいいのかな
他の分野でやってみれば
ずっとゴールドポストを動かすって話なんだけども
それが別に悪いことじゃなくて
いいじゃん機会ができるようになったんだから
他の分野に人間がいればいいんで
いいじゃん
っていう話だね
nishio
今これ話してて思ったんだけど
自分のプライドとか
心の拠り所が一箇所しかない人は
それがAIで置き換わったときに
もう何もなくなっちゃうんだけど
複数個あったらああこれはAIができるようになったのか
じゃあこっちがやろうみたいな感じで
二本足で立っていれば
片方の土台が崩れたときに
もう片方の足に重心移すみたいな感じの
ことができるのと同じで
たくさん複数の心の拠り所を持っていたら
いいんじゃないかっていうようなことを
今聞いていて思ったね
プログラミングだけを誇りにしてると
多分プログラミングはいずれAIがより良くなったときに
プライドが傷つけられるので
そういうことが
ライフハックとして
心の持ちようとして
我々はそうしていくと幸せなんじゃないかな
Yoshiori Shoji
っていう提案です
心の拠り所で
AIにどんどん
仕事を奪われるじゃないか
プライドを奪われると言うと
今僕らよりも多分絵描きさんとかが
結構それに直面してるんだろうな
と思っていて
自分の絵を学習されて
さらにもっといい絵を描かれちゃったりとか
いい絵を描かれちゃったので
どこまで著作権とかで守るか
みたいなのは結構盛んに話されてるじゃん
とか
何かの写真のコンテストとかなんかで
ジェネレートした写真がトップを取ってしまって
後から発覚して問題になるみたいなのは
もう実際出てるわけじゃん
それは僕らの先駆者として
学習できるのかな
nishio
それを見ててっていう気がしてて
Yoshiori Shoji
結構あれを見てると
声のでかい人だけかもしれないんだけど
やっぱ絵を描いてる人は
AIが勝手に絵を描くことに
結構恐怖感を持ってるなっていう気がするんだよね
見てると
nishio
向こう側の人からすると逆に
なんでソフトウェアエンジニアは
AIがやってくることに
そんなに抵抗なく受け入れてるんだ
みたいな感じのことを言っている
絵描き側の左右の人を見て
なるほどそちらからそう見えるのかと思った
Yoshiori Shoji
それは興味深い
なるほどね
それはたぶん
AIに対する理解度の深さによって
恐怖なのか便利だと感じるのかの違い
nishio
みたいな感じなのかな
たぶん理解度じゃなくて
我々はすでに何度も経験しているので
コンパイラーの絵を描くようになり
IDEがサジェストしてくるようになり
今度コパイロットが
より大きなサジェストしてくるようになり
別にこれ何度も繰り返されてきたことだよね
という風に我々の側は思ってるんだけど
絵描きの側は初めて
黒船やってきたという状況なんだと思うんだよね
1:21:01
nishio
黒船来た
何だこれ
ってなってるのが現状なんだと思う
draftcode
これは結構
個人の感情の微妙な問題でもあるから
パーッと
適当なコメントをするのは
良くない気がするんだけれども
でも
たぶん
完全に役立るってことは
全然どの分野でもなくて
たとえ全然あるし
それによって
人の手が
で作ったものっていうのが
価値がなくなるっていうわけでは
全然ないと思うんだよね
こういうアートの分野って
もちろんその
絵描きの側も
絵描きの側も
絵描きの側も
絵描きの側も
絵描きの側も
絵描きの側も
絵描きの側も
あの
短い時間なのかな
短い時間なのかな
短い時間なのか
短い時間とは
全然違うんだよね
〈間 grabbing 〉
すごく
〈間 grabbing 〉
すごい
nishio
いいんじゃないかなっていう感じがするっていう 心の良いところとしてはそれをやり続けるということはこうしように少なくとも趣味として
はずっと肯定されると思うんだけど一方でその 仕事としてやるっていうのは完全に需要と供給によって決まるので一部のものがなくなって
しまうことが不可避であってそれをなくすなくさない決定しての誰かと 市場のみんなが決定しているわけだから誰かがコントロールしてるわけじゃないんだよねっていうそういう不可
draftcode
非なあの今後の未来の流れというのがあるんだろうなと いやまああと何らが絵描きの人もその太鼓昔にカメラというものが発明された時に
同じことをすごく思ったと思うんでその当時の人たちはカメラが出てきたこれはもう もう絵描きいらねーじゃんっていう風に多分
多分結構なってたと思うんだけどまぁそうそう 住み分けは全然あのむしろ何ならそこから進歩したものがすごくたくさんあったと思うんでね
nishio
なぜか出てきた頃は者実的な絵を良し良しとする風習があったわけなんだけれども カメラが出てきてやばいなんてなった結果者実的ではないの表現というのが新しくたくさん生まれた
Yoshiori Shoji
わけだよね でカメラをまたあれだよねフィルムからこうデジタルになった時とか
そっからの現像とかでまた出てきたり言っても音楽もそうだよね アナログからデジタルに移行するタイミングで流れコードじゃないと出ない音があるんだみたいなことを
nishio
言い出す人とか 初音ミクとかボーカロイドが出たことによって人間では歌えないような歌を歌ってくる
ことが多いんですよねブレスないじゃんみたいなねうん 行き継ぎできないよでなどになのにその行き継ぎできないところでなぜか歌ってくる人間が
生まれてまた逆にすげーとなったりとかするわけだよね
Yoshiori Shoji
一方でさっきのシンギュラリティの話だとさそれこそさなんか 変な人じゃなくてイーロンマスクとかさある程度本当に著名人
1:24:03
Yoshiori Shoji
エイブやってる人ですらさちょっと ai 危ないから一旦止めようよって話し合いをしたりとかはしてるわけじゃん
まあ色のマスクはポジションボーカーちょっと 議論
nishio
ちょっとごめん色マスクの例は良くなかったよくなかったよちょっと言わせてくれ イーロンマスクはオープンエアに対して研究をやめろと言っているので自分で gp を
ブーブー言っているだけだろう前はって言う イーロンマスク
例が悪かったでも政府としてそういうふうな発言をする政府もあったりとかするわけじゃん っていうのは何を恐れているんだと思うシンギラリティと言われてるもののなシンギエリティを
Yoshiori Shoji
恐れているんじゃなくてそのどちらが中途半端な制御 がしかできない状態を恐れているんじゃないかなーっていう感じはするんだけれどもその
draftcode
なんかセーフティーセーフティーを入れ忘れるというかあの最近あの僕今8 オフィスいろんな会社が入っているんですけどもそのロボットをやってる会社っていうのがいつか
あってで前なんかご飯食べた横で何か 子供とか手を振ってるって言う感じとなってもうなんか結構なきゅん
ちょっと気色悪い感じがするんだけどなんかこれそのままなんか 今は多分プログラマーされた行動してるだけなんだけれども
なんかこれで ai とかで何回ってなんか適当にそこら辺に銃があるからそれ持ってこう トリガー引いてみてよみたいな感じの指示してそのまま何かそれ打ってしまうっていう状態
たとなんか単純指示されたことで確かにやってると思ってるんだけどなんかよくわかんない こう
ことをしてしまった間違いでしまったっていう事故が起こるのはなんか良くないよねっていう のが多分一つあるのとあとまあ
そもそもなんか急速に発展したのでこれによって例えば まあ
生成 i 特にあのフェイク 動画フェイク画像フェイク音声みたいなすごく簡単に作れるようになった結果
なんかこう イーロンマスクが進めている投資なんとかみたいな感じ
こうしてなんかこう作業働こうとするっていう人たちも出てくるわけでそういった なんかより足元に近いなんか
懸念があるんじゃないかなその遠い将来その 人間の知性を超えるとかそういう話じゃなくて本当に足元で何かそれを悪用しようとする
人がいてそういうをうまく防げないかなっていうレベルのなんか懸念があるん じゃないかなっていう感じはなぜ
Yoshiori Shoji
それからでギリギリが グーが出たばっかりの時にこう爆弾の作り方ググったら出てきたとそれ爆弾作れちゃいました
nishio
そういうのちょっとグルーナー読めましょうみたいなのを言ってたのの エレレン版みたいな感じみたいな感じだとは結局さあ技術中立だからいい人を加速
する技術は悪い人も加速するんだよね なぜなんかあの悪い使い方やめましょうって言っても悪い人はルールは従わないので
絶対使うわけなのでいい側の人がこう ガンガン使って良い良い世界を作っていくしかないんじゃないかなというふうに個人的に
1:27:03
Yoshiori Shoji
思ってい そのいい悪いの判断もまたさあ難しいよね
draftcode
まあ宗教戦争になりそうだよね いい意図があったところで何かこうそれが果たしていいことかどうかってわかんないし
Yoshiori Shoji
いやそう グーグルの時はそのいい悪いをグーグルが判断しててさあ僕らはエビルにはなりませんみたいな
こと言ってるけどさ 人によってはもうグーグル十分エビルだろうみたいなことを言う人もいるわけじゃん
こう っていうのそれをこうなんかで例えばなんかそういうのを企業が握る
nishio
のが危ないと思ってる人もいるしいるいるそう いやなんか政府に握らした方が危ないんじゃねえと思う人もいるし
それでオープンAIは去年の5月ぐらいに何かなんだ10億円くらい使ってあの民主的な インプットの仕方をするシステムを研究する人たちにグラントしますというのを去年の5月ぐらいに
やったんだよね 要するにその
AIの統治というのを企業や国家に任せてはいけないので あの大勢の人々がうまいことこうあの意見を出せ合うことによって統治していくって
仕組みにしないとあの迫害される人が必ず出てくるんじゃないかみたいなところの ところをケアしようっていうことをオープンAIとかは自分たちでグラントを出して
draftcode
ファチリティー化している なるほどまあでもどっちを立てても何から立てないみたいな感じの
Yoshiori Shoji
みんなを満足させるような施策はできないから 各人各社が各国がなんかゴニョゴニョってなんかこう
nishio
よくわかんないまま動くんじゃないかなっていう感じは あのある種の別のレイヤーの戦争が発生している感じはあるよね
Yoshiori Shoji
ポイントポイントで見るとなんか色々問題あるかもしれないけども全体的な動きとしては 世の中良くなっていってる気はするんだよね
全体的にはね まあねそう
nishio
全体的に良くなっていってないと思う人たちが世の中にある程度の人数いて 政治家の中にはそのよくそう思っている人たちの支持を集めたいがために
AI反対というポジションを取る政治家もいてみたいなことが発生するよね まあまあ
ちょっと抽象的な政治の話に近づいてきちゃう ちょっとこの辺で決着しないと思うので
なぜ反対のポジションを取る人がいるのかというのは一つシンプルな言い訳ですよ 反対のポジションを取る民衆がたくさんいるからそれに
Yoshiori Shoji
人気を集めたい人っていうのは必ず存在しているっていうのが一つだよね まあシンギュラリティの心配はしなくていいよねっていう話で
nishio
コントローラブルでないもののことを心配してもしょうがない 自分がコントロールできないことを心配してもそれに対して何かできるわけじゃないんだし
そうそうまあなんかイーロンマスクとか他の政府とかが言い始めた時にすごい思ったのは 君たちが止めろって言っても多分中国はやるよねって俺ちょっと一緒に思ったからね
Yoshiori Shoji
止まらない止められるはずがないじゃんって思ったよね そうそうそう止まらないじゃんみたいな気持ちはあるよね
1:30:07
Yoshiori Shoji
って感じかな AI あとは何か話しておきたいことあるプログラミングにおけるAI
draftcode
割とプログラミングの話が少なかったけど 少なかったね プログラミング言語はじゃあ今後どうなる
プログラミング言語というかプログラミング言語じゃないかもしれないけどプログラミングスタイルとしてもしかしたら関数型プログラミングスタイルはより重要になっていくのかなっていう感じが
なんか話を聞いてて思ってというのも自動生成されたものをテストしないといけないってなった時にテストがしやすいのって入力によって出力が決まるっていうような形式がやっぱりテストが一番しやすいので
なのでなんか まあまだ人間がその確認しなきゃいけないという世代において
プログラミング言語を使わないといけないという状態においてどちらかとやっぱり設計 設計を人間がするって言った時にクラスのこういったインターフェースがあるみたいな設計をするというレベルである限りは
なんかより関数型プログラミング 関数型パラダイムの設計を重視した方がよりAIに優しいというふうに言うことができるのかなっていう感じはする
nishio
影響範囲が小さいコードの塊だけで影響範囲が閉じている方がテストもしやすいし AIも整合性のあるものを出力しやすいし
逆になんか広い範囲を見ないといけないタイプのコードっていうのはAIが間違いやすいよねっていう それは一定のロジックとして納得感がある
一方で反面その人間が得意としてない広い範囲の影響範囲を見なきゃいけないということに関して AIは人間より得意な可能性があるので
コードベース全部頭に入っている状態でコードを生成してくるっていうAIが よりよく関数型パラダイムにしてないにも関わらず
いい感じに設計してくれるっていう未来もあるのかなっていう気がしていて どっちなのかって全然わかんないし
多分直近ではプログラミング言語に大きな影響を与えるというよりは 一番イメージャーな言語が一番得意だから一番メジャーな言語を使い続けましょうという
ロジックが働いてパイソンと邪魔になってしまう あとラストをぐらい覚えてほしいなみたいな感じのその辺りの3つぐらいなのかなみたいな感じになって
使い続けるエアフリーがすごくかかるんじゃないかなって気がする そういう意味で言うと新しいプログラミング言語を作っている人にとっての冬の時代というか
若干やりづらい時代なのかなって気がするよね なぜならAIが支援してくれない ネジャーな言語には強いAIの支援が効いているのに
自分の作った言語はAIが支援してくれないってなる そうするとなんかAIにどうすればこの自分の作ったプログラミング言語を使えるようになってもらうかっていう
AIに対する教育のところ頑張る人が出てきてプログラミング言語を作りたい人の考えることをちょっとシフトしているというか
draftcode
新しく増えているところがあるかなって気がする
さっき言ったみたいにTLFプラスっていうある程度サジェストすぎたっていう経験もあるんで
1:33:04
draftcode
もしかしたらそこまで気にせずに色んな言語で共通して
結構TLFプラスパラダイムとして違うけれどもサジェストできたので
実は大丈夫なのかもしれない むしろなんかただでオートコンプリエーションとかできて
オートコンプリエーションって結構難しくてというのも
パーシャルな中途半端なソースコードをパースしてコンテクストを読み解かないといけないという難しさがあったんだけれども
そんなのがガン無視してチャッとジェネレートしてくれるっていうのが
切り出しとしていいのかもしれない
nishio
文法的に公文記として壊れている公文記をパースして理解した上でサジェストしないといけないというのが実はめっちゃ難しかったところが
実はLAMでショートできるようになったら新しい言語を作る人にとって逆にハッピーな時代っていうことなのかもしれない
確かにその名前忘れたけどそのマイナーな言語がちゃんとサジェストできたんだったら
意外と新しい言語もいい感じでできるのかもしれないですね
なんかドキュメントをコンテクストに積むとかするとラグに積むとかね
Yoshiori Shoji
プラス今までもさ新しい言語ってさそれこそライブラリーが揃ってない
誰も書いてくれてないみたいなそれこそRubyGemとかそういうものがないっていう新しい言語にあるわけじゃん
でも実際GoとかRustとか出てきてどんどんどんどんライブラリー増えていってめちゃくちゃな量になってるわけじゃん
でも参入障壁としては未だあると思うんだよね
新しいプログラミング言語を作った時にそのライブラリーがありませんっていうのは
でもそこは一定数キャズルを超えると問題じゃなくなる気がするので
多分それに比べるとあんまりサジェストされないことのマイナスってそこまでまだ影響ないんじゃないかなっていう気は
nishio
あとあれだよねPythonのライブラリ持ってきてこれをなんちゃら言語に翻訳してくださいってパッとできたら
Pythonの標準ライブラリを全部パクって新しい自分の言語の標準ライブラリを作るとバッテリーインクルーテッドな言語が即座に作れる
draftcode
これでPythonのライブラリのバグまでトランスレートされて
nishio
同じバグがこっちにもこっちにも
Yoshiori Shoji
そういうの結構あるじゃんプログラミング界隈でも
ハッシュ関数の実はこのバグ実はこれそのまま移植してましたみたいなのとか
nishio
みんな間違ってるサンプルコードが間違ってたのでみたいな
全ての言語で間違った標準ライブラリみたいな問いを受けることが発生する
draftcode
大変だなっていう感じが
nishio
意外と逆に僕が最初思ってたのと逆で
多種多様ないろんな個性的なプログラミング言語が100カリオランで生まれてくる時代になるのかもね
人間の学習コストの差があってね
Yoshiori Shoji
今まで人間には難しいからやめようって思ったことが多いわけじゃん
それこそ構造化プログラミングとかが出てきたのもそうなわけじゃん
でもそれこそラインベースのGoTo文とかベーシックの
あれはさ本当さ一義を書き換えるだけで全部のGoToを書き換えなきゃいけなくて
1:36:03
Yoshiori Shoji
そんなに人間が全部きれいにできるわけないよねみたいな話をしてたけど
コンピューターは得意なわけじゃん
っていうのを考えるとまた全然違う書き方の言語とか出てくるかもね
いわゆるアルゴル系って言われてるのとは別
最近で言う構造化プログラミングとか言われてるのとは別で
nishio
リスターみたいなのがまた流行るかも
マニアックなプログラム言語の話をすると
アロイという言語が持っている関係性を表現する文法がめっちゃいいと思っているので
あれを多分コンピューターが理解するんだったらコメントに入れるのか
昔片付けがなかったJavaScriptにJavaDoc形式で型の宣言書いて
それをクロージャーコンパイラーがどうこうやったみたいなああいうノリで
もっといろんな設計のレイヤーの高度な抽象度の高い知識を
コースコード中にコメントとして言える記法というのがもっと安定してきて
AIがそれを理解した上でコードの探知としてくれるようになってくると
すごい人間が図でER図みたいなことを図で書いて図で眺めて考えてるよりも
もっと高度なことができるようになるんじゃないのかなっていう気がする
Yoshiori Shoji
でもそれはもうアロイで書いたものがそのままマシン語にコンパイルされればいいんじゃない
nishio
だってアロイは我々がやりたいような
コンピューターに対する指示を実装するための言語ではなくて
モデルを記述してモデルに整合性があるかを検証するための言語なので
それではなくプログラムを書く何かの例えば
実用的なプログラムを書くというのは現実的ではないのでモデル検証のための言語だから
なんだけどそのモデル検証のための言語が持っている発展させてきた語彙っていうのがあって
文法とか語彙とかがそのモデルの間の関係性を記述するのにめっちゃ強いわけだよね
このインスタンスとこのインスタンスは一体の関係でみたいな
最低限一つ一つのこの条件を満たしているこのオブジェクトが存在するみたいな感じのことが書ける文法があるわけなんだけど
それでそのコンピューターが理解できるその形式で何か仕様をもっと書いてあげて
draftcode
実際のソースコードの設計の支援とかに使われるようになっていくとすごいハッピーな気がする
モデル検査で見るときにそのモデルを作ること自体はそれなりに難しいんだけれども
やってて一番難しいなと思ったのはその性質を書くじゃないですか
この性質を出してほしいっていうのをLTLとかで書くと思うんですけど
あれが自分が書いてるやつがこれ本当に僕が欲しい性質なのかなっていうのは
なんか自分で書いてても検証できないし多分自動生成してくれる
やったーって思うんだけど出てきたやつが本当に僕が欲しかった性質なのかなっていうのは
nishio
ちょっと不安だなって
Yoshiori Shoji
プログラミングロジック以上に正しさを確認するのが難しいってことだよね
draftcode
難しい なんかきちんと検証してくれるんだけれども
アドバイスだとちょっと限界はあるけれども検証してくれるんだけれども
果たして検証して通りました よしっていうのが本当に正しいかどうかは
ちょっと書いてあって不安になるっていう感じがすごくする
1:39:04
nishio
多分それも最初に出力されたり書いたりしたものが正しいのではなくて
間違いが見つかる間にちょっとずつ改善していって
良くなっていくっていうそのアジャイルな発展の仕方をしていくしかないんだろうなっていう気がする
まず最初のバージョンはベータ版として間違ってるかもしれないけどとりあえず出力して
出力するとバージョン管理できるようになるじゃん
人間の脳内にあることをするとよりよい改善につながっていくのかなっていう気がする
Yoshiori Shoji
そんな感じで気がつけば1時間40分話してきた
draftcode
めっちゃ話してる
Yoshiori Shoji
めっちゃ話してた
draftcode
なんだかんだ言ってAI関連の話は盛り上がるというか
誰に話しても盛り上がる感じは
でもちゃんと知見がある人に話を聞くっていうのは良いことですね
Yoshiori Shoji
元々このポッドキャスト自体が俺とドラフトコードがダラダラ技術の話をしてるの
これ録画したら面白いんじゃないって言って始めたやつなので
これが正しいスタイルということで
nishio
なるほど
編集大変そうと思いながら顔見てたけど
Yoshiori Shoji
大丈夫編集しないです
いつも録ったままボッと無視してます
nishio
なるほど
draftcode
作業用BGMとして使ってもらう
Yoshiori Shoji
そう
っていう感じなのでそろそろこの辺でお開きにしますか
nishio
はい
面白かったです
Yoshiori Shoji
ありがとうございます
今日のゲストは西尾さんでした
ありがとうございます
draftcode
ありがとうございました
Yoshiori Shoji
お疲れ様です
お疲れ様です
