トモヒサさんの紹介
ken
リスナーのみなさん、こんにちは。London Tech TalkのKen Wakatomoです。
Kazunari Okuda
じゃあ、Kaz、今日もよろしくお願いします。よろしくお願いします。
ken
はい、ということで、本日はゲストをお呼びしているので、まずゲストをご紹介させてください。
トモヒサさん、今日はよろしくお願いします。
Kazunari Okuda
よろしくお願いします。よろしくお願いします。
ken
もう何回目か、もう数えられないぐらい出てくださってるトモヒサさんですけれども、
ちょっとね、最初に今日はトモヒサさんとAIコーディングについて話したいなと思っていて、
結構いろんなスライドとか記事とか、登壇とかすごいアウトプットされていて、
なんかもうちょっと前まではイベントソーシングの人みたいな感じだったのに、
今はなんかAIコーディングの人みたいになってるんじゃないかなってぐらいですけれども、
その話をしていきたいと思うんですが、まずアイスブレーキングにちょっと最近の天気はどうかなっていうのを聞いてみたいですね。
どうですか、最近の天気は。
Tomohisa Takaoka
結構暑くて、
ken
どのぐらいですか。
Tomohisa Takaoka
でも30度いかないぐらい、私の住んでるロスの近く、
特に僕の住んでるところはちょっとビーチに近い、ビーチから20分とかそれぐらいのところなので、
海の風で結構涼しいんですけれども、
ちょうど先週、今週ぐらい、
妻が妻の実家の、ここから言うとたぶん車で4時間ぐらいのところでしょうかね、
そこに寄生していたんですけど、
そこは内陸の砂漠地帯でめちゃくちゃ暑いところで、
摂氏、カシになるんですけど110度。
それがたぶん摂氏で言うと42,3度ぐらいのところで、
ちょうど昨日そこに迎えに行ってたんですけど、
めちゃくちゃ暑くて、これは外には10分以上いられないなという、
そういうようなところに昨日行ってきました。
ken
40度越えですか。それは例年そんなもんなんですか?
Tomohisa Takaoka
あ、もうそこはいつも暑いところで、
それも107度とか110度とかも一番暑いわけではなくて、
一番暑くて120度ぐらいまで行くんですけれども、
120度、摂氏だと、
ken
45度ぐらい。
Tomohisa Takaoka
そうですね、はい。
それは考えられない。
48度、摂氏で。
それぐらいまで行ったことがあるぐらいのところですね。
夏はいつも暑いですね。
ken
じゃあ基本屋内で過ごすって感じなんですか?
Tomohisa Takaoka
そうですね。さすがに多分空調が、
家にあることが義務付けられているみたいな、
そんな感じになっていて、
家の中で過ごしていれば大丈夫だけれども、
外にちょっと出ると、もうめちゃくちゃ暑いという感じのところです。
ken
なるほどね。内陸で、そうですよね。
じゃあ盆地みたいな感じなんですか?
Tomohisa Takaoka
そうですね。
ken
あんまり風が通らない。
Tomohisa Takaoka
でもアメリカでいうと、ラスベガスとかも結構そんな感じですし、
カリフォルニアのアリゾナ州境なんですけれども、
アリゾナで有名なフェニックスとか、
それから遠くまでに行くとテキサスとか、
その辺までずっと内陸で、
そういう暑い砂漠地帯みたいな感じの天候になってますね。
ken
なるほど。
ここに奥さんとお子さんたちが夏休みを過ごしてきたみたいな感じですか?
Tomohisa Takaoka
そうですね。はい、そんな感じです。
ken
いいですね。4時間、片道4時間?
Tomohisa Takaoka
片道、車で4時間ぐらいですね。
400キロぐらいですね。
ken
すごい。
気速100キロで4時間みたいな。
Tomohisa Takaoka
そんな感じですね。ほとんど止まることなく。
ken
お疲れ様でした、それは。
Tomohisa Takaoka
いえいえ。
ken
それ、1日で行ってピックしてもうすぐ帰るみたいな?
Tomohisa Takaoka
昨日はそうでしたね。1日で行ってピックアップして帰ってくるみたいな感じでした。
ken
1日8時間運転みたいな感じですか?
Tomohisa Takaoka
そうですね、そうですね。
結構アメリカはなんか遠くまで運転しなきゃいけないみたいなのが多くて、
旅行に行く時も、例えばここからサンフランシスコに行きましょうっていう時も、
飛行機で2時間とかなので、車で8時間ぐらいなんですけど、
向こうで自由に動けることを考えると、車で行く人は結構多いですね、もう。
ken
そうですよね。アメリカはそっか、広いからね。
ロンドナーからすると8時間車でって、すごいどこまで行ったの?みたいな。
Kazunari Okuda
スケールが結構違いますね。さすがアメリカ。
Tomohisa Takaoka
昨日友達とちょっと話した時に、その人はニューヨークに友達の結婚式があるって言って、
それに行くのにも車で行くって言っていて、たぶん片道5日か6日かかけて車で行って、
また帰りも観光しながら帰ってくるみたいな。
それは結構、ニューヨークだとさすがに少ないですけれども、
でもそういうふうにする人は結構いますね。
ken
小旅行ですね。大陸横断ですもんね、だってね。
はい。
すごいな。
まあでも車好きとか、なんか運転するのが好きみたいな人だったら逆に楽しいですよね。
Tomohisa Takaoka
結構口の近くにもルート66っていう、シカゴからロスまで撮ってる、
映画で言うとカーズっていう映画があって、
知ってます?
カーズの舞台になっている道路があるんですけれども、
急道って言うんですよね。
高速道路ができる前にアメリカ人がもう本当に1ヶ月ぐらいかけて、
もう車で旅行してロスまで行くのに使っていた道路とかも近くにあって、
ken
それを部分的に通って旅行するっていう人も、今結構まだいるみたいですね。
ルート66。
うん。
なんか小説とかでも何回か出てるような有名なとこですよね。
Tomohisa Takaoka
そうですね、結構有名ですね。
ちょうどアメリカ横断の一番有名な道路だったみたいで。
ken
そうですよね。
はい。
なんか記憶の片隅に何かがあった。
聞いたことがありますね。
なんか出てる。
Tomohisa Takaoka
うん、そうそうそう。
ロードトリップするのに日本からも結構行ってる人多いみたいですね。
ken
そっかそっか。
でもいいですね、なんかこう車4時間ぐらいのところに、
夏休みに行ける場所がね、お子さんたちも楽しみましたか。
そうですね。
小旅行みたいな感じですかね。
Tomohisa Takaoka
はい、そんな感じで。
ken
実家に帰省する。
いや、いいですね。
はい、ということで本日はですね、
ちょっと是非、ともひささんが最近、
前.devから公開された記事がありましてですね、
僕はそれを是非この3人で話したいなと思ってたんですよ。
その記事をちょっとまず紹介しますと、
記事のタイトルが、
AI時代のプログラミング教育。
娘たちにAIコーディングから教えたら、
簡単にレプロエまでできたということで、
どうしよう、
ともひささんの方から、
この記事のサマリーみたいなのもらっていいですか。
僕はこれを読んだときにすごい感動してしまったんですけど、
是非ご自身の口から紹介してもらえればかなと思います。
Tomohisa Takaoka
はい、まず最初に簡単に要約をお伝えしたいと思いますけれども、
子供たちが16歳と12歳の子供たち、
2人とも女の子なんですけれども、
日本で言うと小学6年生、高校1年生ぐらいという感じになります。
2人ともちょっとプログラミングやってみたいっていうのは、
ちょっと前から言っていて、
ただ自分の学校とかも忙しくて宿題とかも結構アメリカ多いので、
なかなか余裕がなくてできなかったんですけれども、
夏休みになってちょっとプログラミングを教えようと思って、
今だったら何を教えられるかなということで、
今だったらバイブコーディングからも始めた方がいいんじゃないかなということで、
バイブコーディングでどうやってやろうかというふうに考えて、
バイブコーディングで教えたという話です。
事業は結局子供たちが帰省して忙しかったりしたものもあって、
この記事に書いている、まだ1回しかできていないんですけれども、
また続けていこうと思うんですけれども、
何をやったかというと、
HTMLの1ページアプリみたいなものを何か作りましょうという話をして、
プログラミングというよりも何て言うか、
アプリケーション設計みたいな、
そういうところを特に重点的に考えたという感じになりますけれども、
どんな画面でどんなことができるものを作ろうかという話を最初に一緒に考えて、
それでできたのがアメリカのコインがいろいろ、
コインとかお札とかギフトカードとか、
そういうのを計算するアプリを作りましょうということになりました。
それで、バイブコーディングでやっていくにあたって、
1からバイブコーディングするとおそらく失敗するので、
ベースのプロンプトは僕が結構頑張って考えました。
そのベースのプロンプトはNext.jsで、
デプロイをするにはどうしたらいいかというのも、
クロードコードとかJAT GPTとかと相談した結果、
AIを用いた共同作業
Tomohisa Takaoka
バーセルを使ったらいいんじゃないかということで、
バーセルでデプロイできるようなものを作ってくださいという、
そういうプロンプトを作って、
今の時代多分大切なのは、
GitHubを使えるスキルが結構大事だと思っていたので、
そこはやり方は僕が言ったんですけれども、
自分で作業をしてもらってGitHubにコードをコミットして、
コミットした後にバーセル設定もクロードコードにさせて、
最終的にそれが何とかリリースすることができましたというのが、
大体のストーリーになります。
ken
これすごいんですよ。
ショーノートにリンク貼りますけれども、
完成品のスクリーンショットもリンクも記事の中にあると思うんですけど、
めちゃくちゃ可愛いんですよ、このUSAマニュカルクリエイター。
っていうのもすごいんだけれども、それもあるし、
僕もAIアシステットコーディングみたいなツールが出てきたときに、
LLM、JAT GPTをそもそも使うかどうかみたいな議論から、
こういったプログラミングを教育現場でどう教えていくかみたいなことも合わせた、
ジェネラルに教育現場にどういう影響とかインパクトがあるんだろうっていうのを、
5年悩んだり考えてたりしたところで、
お子さんにAIアシステットコーディングツールをうまく使って、
こういう完成品を一緒に作ったってすごい素敵なストーリーだと思ったので、
ここを紹介してもらいながら、
例えば、シニアエンジニアがこういうコーディングを使うのではなく、
プログラミングの経験がそこまでなかった、
特にお子さんがどういうところでつまずいたりしたのかとか、
友人さんがどこまで、さっきはプロンプトも自分で作ってあげたみたいなのがありましたけど、
どこまではサポートして、どこは実習性を尊重したのか、
みたいなのをちょっと聞いてみたいなと思ったよね。
じゃあプロンプトはサポートしたみたいなところでしたけれども、
AIコーディングの重要性
ken
そもそもプロンプトゼロから作ると失敗するっていうのはどういうことなんですかね。
そこからちょっと聞いてみたい。
Tomohisa Takaoka
そうですね。
マイブコーディングって言ったことは作ってくれるんですけれども、
言わないことは適当に作られて考えてやってしまうので、
リリースすることを意識して作らないとリリースできないし、
アーキテクチャのことを何も言わなかったら、
ランダムでうまくいくことはありますけれども、
ランダムでうまくいかないこともある。
特にデプロイを考えていないもので作ってしまうと、
デプロイしようと思ったら大きな変更をしないといけないという、
そういうことが今までの僕自身のバイブコーディングというか、
AIコーディングで蓄積でそういう知見があったので、
ベースに関しては僕が作ったもの。
そのベースのプロンプトっていうのはこの記事にも貼っているんですけれども、
例えばNext.jsを使ってください。
それでSSGで作ってくださいとか、
タイプスクリプトで作ってくださいとか、
あとはUIコンポーテントですね。
Shadow CN UIっていうものを使ってくださいとか、
そういうふうな基本的なことを書くことによって、
アーキテクチャをしっかり決めた上でやると、
おそらく成功するんじゃないかなということを考えて、
子どもたちにはその後に、
どんなアプリを作りたいということは自分で考えて、
自分でタイピングして文章を考えるようにお願いしました。
ken
なるほど。
ぜひプランニングのところも深掘りしてみたいんですけど、
一旦ここで数のほうで思ったこととか気づいたこととか質問があれば、
僕が次のプランニングのところも聞いてみたいなと思うんだけど。
Kazunari Okuda
私も自分自身の子どもにAIを使わせようかなとかって思うんですけど、
子どもとプログラミング教育
Kazunari Okuda
なかなかやっぱりプロンプトを作成するところっていうのが、
3歳になったら4歳なんですけど、そこは結構難しくて、
まだ早いかなとは思ってたんですよね。
でも最初に特にこのアプリを作るとかって、
Next.jsとかSSGでっていう最初のこの入りっていうのはすごい良い入り。
それやっぱ経験がないとそこからもなかなかできないじゃないですか。
これは子どもに限らず、たぶんプログラミング未経験者で、
例えばアプリ作りたい、ライブコーディングでアプリが作れるって聞いたって言って、
じゃあ作ってって、こういうのが作りたいんだけどみたいな。
それはたぶんプロンプトだけだと、なかなかどんなものができる、
何でどう作ってくるかっていうのはわかんないですよね。
だからこのワンクッションを置いてあげることっていうのはすごい学びがありました。
Tomohisa Takaoka
そうですね。ちょっとびっくりしたのがアメリカの教育というか、
自分の子どもたちなんですけれども、こういうふうにタイピングしてって言って、
PCは家にあったのでPCを使ってタイピングしたんですけれども、
彼らの授業がほとんどいつもChromebookを使って文章を生成するっていうのが
普通に行われているおかげで、タイピングが早くはないですけれども、
すごく普通にできるんですね。
だから指の配置とかは結構めちゃくちゃだったんですけれども、
タイピングのスピード自体は全然遅くなくて、
思ったことをタイピングするっていうのを自然にやっていたので、
アメリカの教育、Chromebookは1人1台ありますし、
家にも1人1台持って帰っていいことになっていて、
だから2台、学校用と家用と2台あるんですけれども、
そういうのもこれからのプログラミング教育に一番必要な、
まず自分の考えをタイピングして表すというのは、
小学生、小学校学年の時点でも結構できるようになっているというのは、
すごいなと思いましたね。
ken
確かに。
それ結構重要なポイントかなと思って、
プロンプトを書くために必要なスキルとして、
タイピングだけっていうのはすごい時代が変わった感がありますよね。
なんか今まではプログラミングソフトウェアを作るために、
もっといろいろな技術が必要だったけれども、
いわゆる基礎技術としてはパソコンが使えてタイピングができて、
もしかしたら今後はもうちょっとボイスインプットっていうのも出てますけど、
それが他言語とか対応してたら、
より簡単にインプットできると思うので、
それは大事な観点ですよね。
そこで最初にお子さんと一緒に、
こういうものを作りたいねみたいな話をしたっていうことで、
その記事の方でも最初ブレインストーミングみたいなものを一緒にされて、
タスク管理の話とかちょっとしたゲームを作ろうかみたいな、
いろいろなアイデアを話した上で、
このアプリ、マニカルクレーターにされたってことだったんですけど、
そこのプロセスっていうのはどういった雰囲気のものだったんですか。
お父さんと娘が話すみたいな感じだったのか、
いわゆるプロジェクトマネジメント、
プランニング的な感じを意識してやったのか、
そこでプランニングの、やっぱり何を作るか重要だと思うんで、
そこの子どものモチベーションの管理とか、
これはどういうもの、どういう雰囲気で進んだのかなって、
ちょっと聞きたいなと思ってました。
Tomohisa Takaoka
まずその形式という感じなんですけれども、
形式は一応授業みたいな感じで、
じゃあ今から教えるから、ちゃんと言うこと聞いてねみたいな、
そんな感じで始めました。
それで最初に説明したのは、
コンピューターっていうのは何かを入力して、
何かを出力するその真ん中のところを楽にするのが、
コンピューターの得できることですよっていうのを図とかで説明して、
成功体験を考慮したアプローチ
Tomohisa Takaoka
例えば計算をするのに、
XとYを入力したらそれを足した結果が出るとか、
それだけじゃなくても画像とかでもこういうふうにしたいと思って、
それを変換して出てくるのがコンピューターだと。
それに加えて今AIっていうのは、
同じことなんですけれども文章を入れてプログラミングコードとか、
文章を入れて絵が出てくるとか、
そういうのを真ん中のことをやってくれるのが、
プログラミングというかコンピューターの役割なんですよっていう、
そういう話をしました。
なのでちょっとさっきの数さんの話になるんですけれども、
例えば3歳とかでまだタイピングもできないんだったら、
じゃあAIっていうのは絵が描けるんだけれども、
入力したものに対して絵が描けるから、
ちょっとどんなものを描かせたいか言ってみてって言わせて、
それを親がタイピングしてこんな画像ができましたとか、
そういうふうにするのもプログラミング教育の一番最初のステップかなとも思いましたけれども、
そういうふうに入力から出力を代行するのがコンピューターですよっていう話を
ken
最初にしました。
まさにプロンプトエンジニアリングとかもそうですよね。
インプットとして自然言語を与えて、
アウトプットとしてコードが出てくるみたいなところですもんね。
ちなみにそこの中の構造は、
軽く説明したんですか、
LLMみたいなものがあってねみたいな。
Tomohisa Takaoka
そうですね、もうAIです。
AIでそれがいろいろできるようになっているぐらいの感じで、
その入力と出力、
その間にコンピューターが入るという原則を教えたという感じです。
そして次に教えたのは、
難しいこともあって簡単なこともあるけれども、
まずは簡単なことから始めないといけないという話をしました。
なのでコンピューターを使って何作りたいという話をして、
パッと思い浮かぶのは3Dゲームを作りたいとか、
こういうアプリを作りたいというのがあるんですけれども、
例えばですけれども複数ページに渡って
管理しなきゃいけないものを作ってしまうと、
画面遷移の難しいところをやらないといけないし、
あともう一つデータベースでバックエンドに
データを保存するというものを使うと便利なんだけれども、
それによってレイヤーが増えることによって
難しくなってしまうので、
今回最初にやるのはHTMLというか
そのウェブの画面で画面遷移をせずに、
そしてデータベースをネットワークに保存しない、
かつ3Dという複雑なものを入れないもので
何か作るものを最初考えましょうねという感じで、
ブレインストーミング的にこれはどうかあれはどうか
という話を開始しました。
ken
なるほど。だからそのLLMが
さばけるレベルのタスクで完成できるように
制約条件をつけたってことですね。
Tomohisa Takaoka
そうですね。
ken
そっか、その複雑なプログラムの作り方は
すでに知っているトモヒサさんが
なんていうんですか、
例えば子どもに何作りたいというと
たぶん身近なものを作りたいって言うんじゃないかなと思うんです。
例えばマイクラ作りたいとか
ロブロック作りたいみたいな。
でもネットワーク通信があってとか
データベース実装があってとか
いろいろあるじゃないですか。おっしゃった通り。
だからその子どもが持っているツールができることと
子どもが描いている理想像のギャップみたいなところを
ブレイクダウンしてあげる役目は
やっぱりトモヒサさんがそこで重要な
クリティカルなロールだったのかなと聞いてて思ったんですよね。
Tomohisa Takaoka
そうですね。どうぞどうぞ。
ken
どうぞどうぞ。
Tomohisa Takaoka
で、その時に考えたのは
やっぱり成功体験を最初は持ってほしかったんですね。
なので、もしかすると
Viveコーディングだけでちょっと複雑な
データを保存するものも
確かにできるかもしれないけれども
ViveコーディングもしくはAIコーディング一般でも
やっぱり数日かかるプロジェクトだと破綻してしまって
結局コードがわからないと
最終的に何も残らないみたいな
そういうことになってしまうので
それを今回は避けたかった。
この文章を入れるだけで
ちゃんとできて成功するんですよというのを
味わってほしかったので
その制約をちょっと低めにして
自分の今までの経験からして
これだったらできるだろうなというところに
持っていくっていうのをちょっと考えました。
ken
なるほど。
すごいいろんな役割を持ってる
ともひささんが
父親としての娘を成長してほしいというか
いろいろ教えたいという父親としての側面と
タスクをブレイクダウンしていくアーキテクトとしての側面と
AIコーディングの導入
ken
成功体験を積ませてみたいな
マネージャーじゃないけどね、コーチじゃないけど
そういう観点でいろんなロールで
サポートされたんだなっていうのがすごい伝わってきて
すごい素敵だなと思いましたけど
どうですか、カズ。これを受けて
自分のお子さんにいつかこのプロンプトエンジニアリングが
できそうな気になってきましたか。
Kazunari Okuda
そうですね。
そうですね。
ともひささんとお子さんのアイディアの中で
たぶんお子さんはデータベースとかを
使うか使わないかとかって多分判断できないじゃないですか
アイディアを出していく中で
そこはともひささん的にはどう
アイディアをこれができそうなレベルに
Viveコーディングでできそうなレベルまで
コミュニケーションをどう
取っていったのかが結構気になりました。
Tomohisa Takaoka
一般的だと思うんですけれども
こうやってアイディアを考えてみて
といったときに
パッとアイディアはやっぱり出てこなかったですね。
なのでどっちかというと
こういうのとかこういうのとかあるけれども
どうするみたいな感じで
なんか僕がアイディアを出したような
アイディアの中で
アイディアを出したような形に
最終的にはなってしまったんですけれども
でも
例えばゲームだったら何があるか
みたいなのでテトリスとか
4目並べて英語ではConnect4
っていうんですけれどもそういうのが出るみたいな
ちょっとそういうアイディアとか出てきましたけれども
あとタスク管理っていうのは自分で出したかな
っていうのにしなかったのは
タスク管理は多分できると思うんですけれども
結局ネットワークに保存しようとする
と思ったんですね。
LLMの方が。
なので明らかにフロントエンドだけで
解決できる問題に
誘導したというところはありますね。
その中でちょうど
6年生が卒業だったので
ちょうど卒業パーティー
みたいなのをして
そこで手紙と
ちょっとお金をくれたりとか
ちょうど子どもが
お札をたくさん持っていて
コインとかもたくさん持っていて
それをカウントするのを作ったらどうかな
という話をしたらみんな
それは面白そうという話になったので
これで進めようということになりました。
ken
いいですね。
そこでアイデアが出てきたところで
アプリのアイデアとデプロイ
ken
最高体験を積ませたいと思った友人さんが
デプロイまでやりたいねって言ったのは
デプロイするものを作るっていうところを
分かりやすいゴールとして設定したということで
Tomohisa Takaoka
合ってますか?
そうですね。デプロイはおまけではあったんですけれども
最近はデプロイも
簡単にできるので
バーセルとか
クラウドフレアとかで
簡単にできたっていう話も聞いていたので
それはちょっと組み込んでみたいなと思って
僕のほうで付け加えたんですけれども
簡単に見せられるものにしたほうがいいだろうな
という気持ちからデプロイもちょっと
入れてみたっていう感じで
それは僕のフロンプトのほうで
やったんですけれども
大体それが授業1から授業2の間で
授業1から授業2の間は
大体3日ぐらい待ちました。
フロンプト作ってっていう話をしてから
自分たちでフロンプトしている間に
僕の側のフロンプトを
考えたという感じになります。
ken
なるほど。授業1と授業2の間には
3日ぐらいあって
その間お子さんはフロンプトで遊んでた
みたいな感じですか。慣れるみたいな。
Tomohisa Takaoka
まだフロンプトは打たずに
コンピューターにタイピングしたり
どんなものを作るか
アプリ設計みたいなものを
考えてもらっていたんですけれども
意外と真剣にやってくれて
紙にこういう感じで
できたらいいっていうのを書いていたり
上の子はiPadで絵を書くのが得意なので
iPadにこういうアプリの形で
っていうのを絵で書いたりして
これをタイピングしていかないといけないよ
っていう話をして自分たちで
タイピングしていたという感じです。
ken
じゃあこの中日の間は
お子さんたちもすごい
やる気に満ち溢れてたみたいな感じなんですか。
Tomohisa Takaoka
そうですね。満ち溢れてはなかったんですけれど
ken
前向きだったぐらいですか。
Tomohisa Takaoka
しなわなかったみたいな。そんな感じですね。
ken
掃除で最初でつまづいたポイントってどこだったんですか。
お子さんがやる気なくしたりとか
つまづいたところみたいな。
Tomohisa Takaoka
そうですね。今回に関しては
つまづかなかったですけど
つまづいたところというと
なかなか始められなかったというか
学校にいる間にもこれぐらいだったら別にできたとは思うんですけれども
みんなの余裕があんまりなくて
やっぱり余裕がないとちょっと
やりにくいかなという感じはしていますね。
つまづいたところでいうと
1回目やってからもう3週間ぐらい経ってるんですけれども
バタバタして
2回目がまだできていないというのは
つまづきつつあるみたいで
この後またやってみようかなと思っています。
ken
そこそこいいですね。
ここでデプロイされた
USAマニカルクレーターのこともちょっと触れたいんですけど
これリスナーの皆さんにはぜひ記事を開いて
見てほしいんですけど
めちゃくちゃカラフルで可愛いんですよね。
見た?このスクリーンショット。
めっちゃ可愛いよね。
色使いとかアニメーションとか。
ここで思ったのは僕は
この技術的な仕組みは説明できるかもしれない。
ACMAとかソースコードを見に行って
JavaScriptも分かるかもしれない。
でもこのデザインは作れないなと思ったんですよ。
子供に受けそうな
女の子が好きそうなこのデザイン。
それってすごいことだなと思ったんですよね。
お子さんの間でこういうものを作りたい。
カラフルでアニメーションつけてスパークリングなものつけて
いろいろ制約条件を考えてあげたり
テスクをブレイクダウンしたりみたいな
サポートがあれば
これ作れちゃうなって
このスクリーンショットを見た時の驚きが
すごかったんですよね。
子供ってすごい想像力も高いし
クリエイティビティも高いし
アニメーションとかは
そこに現代の技術を上手く渡してあげたら
子供が誇れるものが作れるんだっていうのは
一つ
最初の冒頭に戻りますけど
教育とAIを掛け合わせた時の成功パターンを
垣間見たような気がして
僕はすごかったんですよね。
そうですね。これも
Tomohisa Takaoka
デザインに関しては
これは下の子が作ったものなんですけれども
タイピングするところを
ずっと見ていたわけではなかったんですけれども
色とかもちゃんと指定していて
このグリーターっていうのがキラキラするのとか
これがちょっと動くようにしたいとか
あとこの色に関してもそうですし
このデザインに関しては
自分で
この入力も数字の入力のところは
テキストボックス入力じゃなくて
このプラスマイナスボタン縛りなんですよね。
うん。気づきました。
ken
これも
Tomohisa Takaoka
そういう風にプラスマイナスボタンで
動くようにっていうのは
しっかり指示していて
そういう意味で
そのギフトカードも
これは上の子のアイディアと下の子のアイディアが
混ざったみたいな感じになっているんですけれども
それも名前と
数字を入れられるようになっていて
例えばAmazonが2個あって
20ドル30ドルだったらAmazonは50ドルですよみたいな
そういう結果も下に出るようになっている
子供の創造力と成功体験
Tomohisa Takaoka
みたいな感じで
やっぱりさっきケンさんおっしゃったような
クリエイティビティに関しては
プログラミング力とは全く別なので
そういう意味では子どもが自分で考えて
できたものっていうのはやっぱり
なかなか大人では作れない
子ども向けのアプリを作ったりするのにはやっぱり
子どもの観点みたいなのをできる人が
若者がやるのがやっぱりいいので
そういう意味では
プログラミングとしての楽しみというのは
これから減っていくかもしれないですけれども
ただものを作る楽しみみたいなのは
これからも続いていくんじゃないかなという風に
思いましたね
ken
ものづくりの楽しみですよね
だって僕がたぶん同じものを作ろうと思ったら
すごい簡素なテキストのインプットフィールドの
ボックス作ってブートスラップみたいなやつつけて
シンプルにしちゃうところを
アクセシビリティも考えて
プラスマイナスで計算しやすいようにして
っていうのはやっぱり自分が使うことまでイメージして
学校のイベントで
友達が使うこともきっともしかしたら
イメージしながら作ったのかなと思うんですけど
共感力じゃないですけどね ユーザーのことも考える
みたいなそれは別にソフトウェアエンジニア
シニアエンジニアの特権ではないので
誰でも持てるスキルというか考え方なので
そこに
作れるツールがうまく与えてあげたら
こういうものができるというのはすごい素敵な成功ストーリーだなと
この記事をちょっと広めたいなと思ったんですよね
Tomohisa Takaoka
どうですか
ken
カズの方でも
自然体のコメントでもいいけどさ
Kazunari Okuda
そうですね
このデプロイできる
ところはすごい良かったなと思って
やっぱり子供が作ったものを誰かに見せたいとかって
同級生に見せたいとかって
あるのか あったりすると思うんですよね
そこで作ったものを見せて
すごいじゃんみたいな風になったら
そこで成功体験を積み上げて
いけることができて
なんか嬉しいよなとか思って
だからデプロイできてどこでもアクセスできる
っていうのが
すごい良いアイデアだなと思いました
Tomohisa Takaoka
ありがとうございました
これでセットアップは
結局僕がヘルプしないと
できない部分もありましたけれども
一応ビジュアルスタジオコードの
ウェブサイトに行って
ビジュアルスタジオコードをインストールするとか
あと
Macだったんですけれども
Gitとバーセルの活用
Tomohisa Takaoka
ゲストアカウントだったので
権限が難しいところがあったりして
その辺の権限をうまく修正したりするのは
僕がやってあげなかったり
しないといけなかったですし
NPMをノードをインストールしてとか
その辺は
一応自分たちでタイプはさせましたけれども
言った通りやって
彼らは多分覚えてないですけれども
Gitを使うというのは結構
ちゃんと教えてGitもコマンドは覚えなくて
いいかなと思っていて
ビジュアルスタジオコードの画面上ですね
左側にパネルがあって
Gitのチェンジが出てくる
パネルとあとコミットメッセージを
入れるテキストボックスがあるので
そこに入れてコミットして
プッシュするっていうのは
その概念に関してもちゃんと教えて
特に下のこのリリースまでするのに
ちょっと修正して
それをコミットしてあげないといけない
っていうのが何回かあったんですけれども
その概念みたいなのも
じゃあこれは手元では直ってるけれども
このバーセルのページに
反映させるには
コミットしてプッシュしなきゃいけないんだね
っていうのを最終的には理解していたようなので
そういうのは良かったかなと思います
それでバーセルのなんかすごい便利というか
GitHubアカウントで
ログインできるので
GitHubのアカウントは最初に2人のを作ったんですけれども
GitHubアカウントでログインできて
しかも特に支払いはなくて
バーセルの設定さえして
リポジトリをコネクトさえすれば
勝手にデプロイの作業が進んでいく
その後はコミットしたら
勝手にデプロイするっていう
この簡単さっていうのがすごい良かったので
教育の意義と意図
Tomohisa Takaoka
これに関しては
僕が難しいことを設定することもなく
できるようになったので
これはすごい便利だなと思いました
ken
バーセル僕もチラッと使ったことありますけど
便利ですよね
周辺ツールの進化も確実に寄与していると思いますね
Gitのところもちょっと深掘ってもいいですか
トモヒサ塾で
Gitの動き方というか仕組みをしっかり伝えた
みたいなところも結構特徴的だなと思ったんですけど
そこをコミットとかプッシュとかも
教えようと思ったきっかけとかってあるんですか
わかんないけど
GitHubのGUIのデスクトップアプリとか
使ったことはわかんないけど
Googleドライブの感じは別にアブストラクトにしちゃって
セーブは自分の方でしてみたいなのでも
いいと考える先生もいると思うんですけど
そこGitもきちんと時間をかけて教えたのは
今後に繋げたい意図があったとか
Tomohisa Takaoka
何かあったのかなと思って
それで言うとですね
私たちの会社にも新人を
ほぼ未経験というか
自習だけをしている新人を
雇うことが時々あるんですけれども
彼らに共通して
必要な教育がGitHubの
使い方なんですね
それが結構時間かかるんですよ
なので
今いろいろプログラミングが
楽になっているところで
基礎スキルっていうのは
最近はGitHubの使い方だと
僕は個人的に考えているので
そういう意味でGitHubがちゃんと使えるようになれば
プログラミング力よりも
基礎知識としては大切で
これに関してはしばらくなくならないのかな
と思ってGitHubを教えたんですけれども
AIコーディングの進化
Tomohisa Takaoka
ただ彼らは英語ネイティブなので
コミットとかプッシュとか
シンクっていう話を
GitHubにサーバーがあって
そこにプッシュするんですよとか
シンクするんですよっていう
説明したときに理解が進みやすいっていうのは
感じましたね
だから僕自身が
とか僕が見ている他の日本の新人たちが
苦しんでいるようにはあまり苦しんでいなかった
かなと思います
Gitなんですけど
最近は僕もGitの難しいコマンド
ほとんどGUI派でGitのコマンド
あまり使えないんですけれども
最近はほとんどクロードコードに
こういうことをGitでしたいって言って
クロードコードにさせてるんですね
例えばコンフリクトの解消とかも結構
そしてプルしてプッシュするみたいな
自分ですると結構引っかかるところなんですけれども
そこもほとんど
自然言語でさせているので
概念さえ分かればいいかなと思って
基本的には概念だけを教えてあとはGUIで
やってもらったという感じになります
ken
なるほど なんか鋭いですね
ジュニアとか新人のエンジニアを
会社で教育した
そこで気づいた経験があったからこその
観点だったんだというのを聞いてて思って
確かに自分も今のキャリアを思うと
コミットって何?みたいなところへ
つまずいたなと
英語ネイティブじゃ特になかったので
数とかどうだった?Git
どうやって勉強した?
Kazunari Okuda
まさに単語の意味が多分分かんない
英語だから日本語
和社員にとっては
なんて言うんでしょう
言葉の意味は多分今
覚えてなくてそれを打つとこうなる
という動作を覚えてると思います
英語の
Gitのコマンドの意味も考えたことない
レベルで
練習した?じゃないかな
練習したというか勝手に
ken
くっついていった
手で覚えたみたいな筋肉が覚えたみたいな
Kazunari Okuda
最近Git
コマンドの名前も変えてたり
するんですけど多分それをついていけない
ついていってない自分の前のコマンド
のまんま
これがこう1対1対応で
くっついてる感じですね
Tomohisa Takaoka
今はGHコマンドとかもあるし
Gitの直のコマンドもあるし
それでできることは
かぶっていたりかぶっていなかったりして
どっちでやったらいいのか
みたいなのもあって僕は結構もともと
GUIばっかり使ってたので
あれなんですけどそれでも
クロードコードは結構やってくれるので
最近はもうそっちに任せてしまってますね
なるほどね
ken
インサイトフルですね
この記事もそうですけど
ともひささんとAIといえば
派手部とかツイッターとかかな
なんかすごいなかなかバズった
他のスライドというか記事もあると聞いていて
そこもちょっと触れたいんですよね
事前にスライド2つか3つ送ってくださったと思って
確かAIコーディングの理想と現実の方だったかな
すごいね
ともひささんも会社のロールもあると思いますけれども
ここら辺の石板を作る過程で
AIコーディングを使われていてみたいなところは
今までもDiscordの中とかご自身のSNSとかで
積極的に発信されてたと思うんですよね
その中で最近も結構いろんなところで登壇されていて
リンクはショーノートにも貼りたいなと思うんですけども
いろいろ試行錯誤してきていたともひささんが
現時点でAIをどのように使ってコーディングをしているのか
今の2025年7月末の状態の
ともひさズAIテックスタックみたいなのを聞いてみたいですね
Tomohisa Takaoka
そうですね もう使わない日はないみたいな感じにはなっていて
コーディングする量で言っても
ものにもよりますけれども
80%から95%ぐらい書かせていることが多くて
今何をやっているかというと
最近イベントソーシングの
私たちが作っているフレームワークの石板というのが
昔は自分で書いたというか
比較的シンプルな1サーバーでしっかり動くみたいな
そういうバージョンだったんですけれども
やっぱり分散でちゃんと動かないと
価値がなかなか見出せないということで
今年の1月ぐらいから
オーリンズというCシャープのアクターフレームワークに
対応するコードを書いて
その時はまだなかなかソネットも賢くなかったので
自分で7割ぐらい書いて
3割ぐらいソネットを活用するという感じで
2ヶ月ぐらいで作ったんですけれども
それはまだメンテナンスし続けた上で
もう1個Dapperという別のアクターフレームワークにも
対応してみたいなと思って
今度はこれをほぼソネットとクロードコードで
作り始めたんですけれども
大体2週間ぐらいで同じ機能が作れるようになって
今は石板はオーリンズというのと
Dapperというので両方使えるようになったのに加えて
その後いろんな言語を使える人にも
使ってほしいなと思って
石板タイプスクリプトというのを作り始めて
これを作り始めたのが
大体7月の初めぐらいなんですけれども
それも今NPMにもリリースして
まだ全然アルファ版でバグも多くて
試してみれるぐらいの感じなんですけれども
使えるようになっているという
相当AIと一緒に作って
今までの生産性に比べると
ワクワク上がりというわけでもないんですけれども
でも基本的には作りたいと思うものは作るみたいな
そういうのにそのAIと一緒に作ることによって
できているというそういう状態に今なっています
ken
石板タイプスクリプトってこれですか
At石板スラポスグレースとかで出てるやつですか
Tomohisa Takaoka
そうですね
At石板CoreというのがCoreライブラリで
Dapperというのが
DapperというActorフレームワークは
言語を非依存のものなので
最初にCシャープで作ったんですけれども
それと同じような機能を
Dapperのタイプスクリプトで作っていて
Actorをサイドカーで調整しつつできるという
そういうフレームワークで
Goとかでも作ろうと思えば作れるし
ラストとかでも作ろうと思えば作れるみたいな
それによってActorとイベントソーシングというのを
Cシャープで書いてるのと同じように
今書けるようになりつつあるという感じですね
ken
めちゃくちゃ面白そうですね
なるほどDapperっていうのが
サイドカーで別プロセスとして動かして
これはもう言語非存のと言ってから別に
Tomohisa Takaoka
Actorベースのプロセス管理みたいなのしてくれてるみたいな
Actorで住所みたいなのがあるんですけど
Actorの場合
住所を渡すと
ふさわしいプログラムを起動してくれる
AIとプログラミングの進化
Tomohisa Takaoka
それがActorの基本になるんですけれども
それが同じことがCシャープとタイプスクリプトで
できるという感じで
タイプスクリプトでドメインを書いて
タイプスクリプトのノードのエンドポイントを作って
バックエンドとして動かす
みたいなことが
今できるようになりつつあるという感じですね
ken
面白いですねこれ
プロ騎士って言ったらちょっとこう
プロ騎士ではないのか
Tomohisa Takaoka
そうですね
Dapper自体はマイクロサービスに必要な
いろんな機能があって
すごいたくさん機能がある中の
一つがActorになるんですけれども
マイクロサービス上で
特に開発をするときに
これからこれを呼ぶというのは
その設定をするだけで大変なので
Dapperを使って作ることによって
簡単な文字列設定で
お互いにマイクロサービスの機能を呼び合う
みたいなのが
簡単にできるための
フレームワークみたいなのが
Dapperになるかなと思いますね
ken
面白い
イベントドリブンランタイムのビルディングブロック
みたいな言い方がされてますね
Tomohisa Takaoka
そうですね
これをするときに
AIを使っているんですけれども
結局難しいところになってくると
デバッグ力勝負になるんですね
デバッグ力勝負になったときに
それでも僕はあまりコードは
自分では書かないんですけれども
でもコードを読んで
どこまでできていて
どこまでできていないのかというのを
調査させて
そしてここまでできていなくて
これがダメなんだったら
このメソッドの中が悪いに決まっていますよね
みたいなそういう話を
クロードコードとやって
じゃあここにフォーカスして
ここだけ修正して
他は全く触らずに
修正してくださいねっていうのを
クロードコードに言って
少しずつ修正させて
最終的にやりたいことに持っていく
これを実装させると全然ダメなんですね
あれもダメでこれもダメで
じゃあここだけシンプリファイして
Mockみたいなのを作って
成功した風にしましたみたいな
そんなことを普通にやってくるので
そうするとどんどん壊れていくばっかりになるので
Kazunari Okuda
なんか上司にだけいい顔するエンジニアみたいですね
Tomohisa Takaoka
プロジェクトは絶好調ですね
そうなんですね
なのでそれをしないために
どういう持っていき方をできるのかっていうのを
今は特に重点的に研究しつつやっているんですけれども
その上で必要なのはやっぱり
プログラマーのデバッグ力というか
これを自分でデバッグするときに
どういう風に問題を分析して
どこが問題であるかを見つけて
そして修正する
だからこれで僕はほとんどタイプスクリフト版は
手ではコードを書いてないんですけれども
コードリーディングはかなりやっていて
その上で少しずつ問題を解決していくという
そういう感じになっているので
だから書く能力というのは
ほとんど不要になっているとは言えるんですけれども
かといってプログラマーとしての能力というのは
これからも大切なんじゃないかなと思っているという
そういう現時点での状況ですね
ken
すごい納得します
さっき言ったバズったスライドの後半でも
AIが追いついている領域とできない領域みたいなところで
結構複雑なエラーとかデバッグとか
あと大規模システムにおける一貫性のあるコーディングみたいなのは
まだまだだよみたいなことを言っていて
僕もSREなのでデバッグしているとすごい分かります
最初はインシデントのサマリーとか
ちょっとしたエラーメッセージとかを投げるんですけど
途中で暴走し始めてもいいやって投げることがありますね
カズとかどう?
今プロトフォームエンジニアリング的なところに
あれまだいるかと思っているんだけど
活用するデバッグとかで
Kazunari Okuda
実際に大きなプロジェクトとかでも
最初にこうやってくださいって言って
ある程度の大きさになると
コンテキストをちゃんと渡してあげないと
全然思った通りにいかないっていうのがあって
コードベースをコンテキストを渡すには
自分自身がそのコードを知らないといけない
だからやっぱりプロンプトを渡す
AIに支持する人の力量っていうのは間違いなく
追われるなっていうのが
すごいちっちゃいやつだったら
例えばですよ
JSONのファイルをテラフォーム形式に
テラフォームでインポートしたいから変換してって言ったら
なんかすごいシンプルなタスクだった
全然自分がやるよりは早くやってくれたりして
すごい便利だなと思うんですけど
もうちょっと大きなことになると
ちゃんと自分自身がコンテキストを渡して
支持をしないと
自分でやった方が早いんちゃうかみたいなところが
結構あったりしますね
Tomohisa Takaoka
やっぱり堂々巡りがあるんですよね
コンテキストっていうのの弱点として
10分前とか20分前とかに一生懸命ディスカッションして
こういうことはダメですよね
それをクロードMDファイルに書いたりすることもあるんですけれども
それで一生懸命やってこれがダメだとせっかく説明したのに
また同じことをやっているみたいな
かといって全てをクロードMDに書いたらまたそれが
若手開発者の学び
Tomohisa Takaoka
たくさん多すぎて覚えてなかったりするので
その辺はやっぱりなかなかおっしゃるように
コンテキストの管理なんですけれども
それも毎回完全なコンテキストを渡してあげるっていうのも
なかなか難しいので
Kazunari Okuda
慣れと試行錯誤になってくるんじゃないかなと思いますね
忘れるんですよ
これ1個前にプロンプトしたことをしたのに覚えてないんかいみたいな
Tomohisa Takaoka
とか結構あったり
結構キレちゃいますね
LLMに対して
言ったじゃないかみたいな
ただそれも
なんていうか
キレちゃうのはそうなんですけれども
今キレる段階を超えて
ごめんなさいね
適切なコンテキストを渡せてませんでしたねみたいな
逆になんていうか
僕のほうも
自分の責任というか
マネージャーとして
LLMに正しく情報を渡せなかったみたいな
最近そういう風になってきたなと
キレる段階もあったんですけれども
ken
すごいなんか学んでるというか
それを聞いて思ったのが
人間とのコラボでも全く同じことあるなって
僕も先週とか今週あったんですけど
いやそれお願いしたよねみたいな
I understood って言ったよねみたいな
また説明しなきゃいけないのかみたいなのあったし
ステークホルダーマネジメントと似てるというか
どれぐらいの情報を誰に適切なタイミングで渡すかみたいな
コンテキストマネジメントとまさに一緒だなと思って
確かに僕もあまりキレずに
ちゃんとマネジメントという観点で
学ばなくてはいけないなと思いましたけれども
もう一つのスライドもあって
AI時代における試行錯誤みたいなところがあって
ここを最後にトムヒサさんに振りたいんですよね
今までAIと教育の可能性とか
あと今のトムヒサさんのAIテックスタックみたいな
どう具体的に使ってるかみたいなところを聞いてきましたけれども
最後にマインドセットと言いますか
今って結構本当にAIダブルクオーテーションみたいな感じで
いろんな記事とかポッドキャストとかアウトプットが出てますよね
広告も出てますしプロダクトもいろんなものが出ている中で
ジュニアもシニアも距離感のつかみ方を悩んでいる人も多いと思うんですよね
もちろん将来って予測できないものではあるものの
その中でいろんな人が自分なりの考え方を持って
AIとの距離感を持って接していると思います
トムヒサさんの試行錯誤のところでは結構面白いキーワードがあって
熱意と探求心みたいなところがあったんですよね
そこがすごい良かったなと思うんです
最後にトムヒサさんがリスナーの中で
AIアシスティックコーディングを使い始めたよとか
いろいろ使っているよとかもしくは距離を置いているよとか
いろんなリスナーの方がいると思うんですけど
トムヒサさんが考えるAI技術の付き合い方みたいなところを
現時点での考え方みたいなのをリスナーに
アドバイスじゃないですけど
その形で最後に距離感とかエンドセットみたいなところを
どう考えているのかというのを最後にお尋ねしてもいいですか
Tomohisa Takaoka
はい そうですね
やっぱりさっきのデバッグとかプロンプトを渡すという意味では
これまでのアーキテクチャとかが分かっている
シニア開発者が優位だというのは
実際そうだと思うんですけれども
AIによって学びの速度が急激に速くなっている
つまり今知らなくてもこんなエラー出たんだけど
どうしたらいいって聞いたら
シニアエンジニアが言うような知見を
チャットGPTが教えてくれるようになっているわけで
若手開発者が不利というか苦労しなきゃいけないことは
確かなんですけれども
でも最終的に不利かというとそうでもなくて
逆に自分の思い込みみたいなものもないので
どんどん使ってもらって
うまくできるという要素も非常にあると思っていて
最近うちの会社でも
特に学習をしている若者みたいなものもいて
彼らにはどんどんAI使って
AIだけでやってみてという風に言っているんですけれども
それによって結構学びのスピードが速くなっていて
社内システムをAIでちょっと書き換えてみてって言ったら
2週間ぐらいで今まで結構頑張って作った
社内システムと同じフロントエンドを作ってきたりする
だからAIネイティブっていう言い方になるのか
わかんないですけれども
プロンプトとコンテキスト管理
Tomohisa Takaoka
AIと作業するのが非常に自然にできるかなと思っていますね
なのでそういうのをいろいろ総合して考えていくと
これを面白いと思って
これを使ってどんどんいいものを作っていきたい
そのためにこういうものもあるし
こういうものもあるっていうのをネットで見るけれども
ちょっとそれを使ってみてやってみたいなっていう
そういう探求心みたいなものがやっぱりあると非常に良いなと思います
なぜかというと
僕らが勉強し始めた頃っていうのは
例えばC++がいいですよっていうのは
もうこの5年ぐらいのスパンで変わってきたような感覚なんですけれども
今は1ヶ月で勢力図が置き換わるみたいな
そういう時代なんですね
例えばクラインが非常に使われていて
日本の開発者もクラインクライン言ってた頃から
今はもう1ヶ月2ヶ月でクロードコードばっかりになっているけれども
これもまたオープンAIの発表でどうなるかわかんないみたいな
そういう時にもうクロードコードしか使いませんと言っている人よりも
クロードコードはこれで良かったけれども
じゃあまたこのキロっていうのを使ってみようとか
別のものを使ってみようって
これとこれを組み合わせたらうまくいくかもしれないみたいな
本当に言われてやるというよりもやってみたいと思って
挑戦してやってみると結構すぐ良いやり方を思いつくものなので
そういう探求心によっていろんなことを試してみる
やってみたいそれによっていいものを作りたいみたいな
そういう熱意みたいなのが大切じゃないかなと思っている次第です
AIを用いる組織文化
ken
素敵なアドバイスありがとうございます
探求心っていうのは僕もすごい好きな言葉で
やっぱりやってみるっていうのは大事だと思ったんですよね
田口さんの言葉を聞いて改めて
いろんなツール出てますけど
自分の手でやってみるからこそ分かることって本当にあると思うんで
ティンカリングじゃないですけど
探求心でそれを支える熱意みたいなところはすごい素敵なキーワードだなと思いました
数の方はどうですか
収録を振り返っててもいいですよね
熱意と探求心の話でもいいけど
Kazunari Okuda
そうですね私は
友人さんみたいな方と働けるのがすごい良いなと思いました
っていうのも
第一線でAIを試してコードを書いている人が上にいて
いろいろ試して
どんどん使って
その中でどんどん使っていってくれっていう
動きができるのがすごい良いなと思いました
やっぱり会社の中ではまだ
AIまだ何て言うんでしょう
ハイプの時期だよねみたいな
まだちょっと様子見てみよう
そしたら下のその会社にいる下の人たちって
結局アクセスしたくてもやっぱりお金はかかるじゃないですか
AIやっぱり良いものを使おうと思ったら
その中で個人でやろうと思ったら
若い人とかでもお金を払ってまでやるかっていうと
そこまでのバジェットがないかもしれないみたいな
でもその中でやっぱりトップでちゃんとコードをすごい書いてて
でそのAIを試していってるっていう人がいる会社っていうのは
なんかすごい良いなと思いましたね
やっぱり何よりもコードをバリバリ書いてる人の中で
その中でいろんな試行錯誤がAIとできるわけじゃないですか
でプログラムそのエンジニア視点でこういう風にできるよ
AI使うとこういう風にできるよとか
いうことが言えると思うので
Kazunari Okuda
すごいそういう会社で働けるといいなと思います
今の会社は全然AIが使えないとかっていうことじゃ全然ないんですけど
ken
すごい良いことだなと私は思いましたね
いやそれは僕も思いますね
入社1人確定
Tomohisa Takaoka
イギリス視点を
イギリス視点を作る際にはぜひみたいな
ken
いやでも本当そうっすよね
なんかいろんなことをいろんな人が言ってるから
信頼できる人のアウトプットみたいなのを見つけるのいいと思うんですよね
僕もともひささんが出してくるAIの関連は全部読むけど
別にニュースに出てくるAIは全部読んでる時間もないし
もちろん飲まないしみたいなところで
ちゃんと自分で実践しながら
考えた結果を出してくれてる人がやっぱり身近にいるのは
僕も本当に希少かなと思うので
今日も収録に来て
ブレインストーミング付き合っていただき
本当にありがとうございますという気持ちと
またお子さんとのAIコーディング授業は続くかもしれないとのことなので
もしアップデートがあればぜひ記事にしていただいたり
また収録に来ていただいて話したらなと思います
Tomohisa Takaoka
はいありがとうございました楽しかったです
ken
また来てください
今日はありがとうございました
Tomohisa Takaoka
お疲れ様でした
