#462 DBを選定する際のポイントを パッと言えない人全員集合(RDB/Mongo編)

この番組は「エンジニアの成長は楽しい学びから」をモットーに、昨日より少し成長できる学びをわいわいお届けするエンタメ系テックラジオですということで。

はい、わいわい。

えー、今日はですね、DBを選定する際のポイント、パッと言えない人全員集合、Mongo、RDB編。

Mongo、RDB編。

はい。

速攻集合しました。

MongoかRDBを選ぶ、え？

はい。

そうです。

MongoかRDBを選ぶ、ってこと？

Mongo。

あ、そうそうそう、はい。

ほー。

Mongoは固定なんすね。

Mongo。まあ、なんかNoSQLいろいろあるけど、人気なのそのへんかなと思って。

うん。

そのへんっていうか、まあMongoかなと思って。

確かに。てかドキュメント型のDBってMongo以外知らないかもな。

ほんとっすよね。まあAWSにドキュメントDBみたいなのがありますけど。

そんなのあるんだ。

ありますよ、はい。まあMongo互換ではある、が、ちょっと癖が違うみたいなのはあったかな。で、えーとー、まあね、なんかこのー、今自分がそれぞれ開発してるアプリ、担当してるアプリ、システムで使ってるDB、まあ各々あると思いますと。えー、まあNoSQL。何かなのか、えー、RDB使ってるのか、みたいな感じであると思うんですけど。

うん。

で、まあスキーマレスだからMongoにしたとか、パフォーマンス求められるからなんかMongoにしたとか、えー、スキーマなんか必要そうだからMySQLにしたとか。

うん。

なんかそのへんの、まあ言い訳、言い訳じゃないな、理由でデータベース選ぶことがあるかなと思いますと。

はい。

うん。で、まあ過去にですね、僕はあの、このへん、まあなんかこのち、アプリどっちでも良さそうだなあ、Mongoにしとくかって言ってMongoにして。

うん。

で、あとから開発しててちょっと大変だった思いをしたことがあったので。

うーん。

ま、ちょっとそのへんの話も触れながら、今日はこの、どっち選ぶんだ問題っていうんですか。なんかどっち選ぶとどういうことが良くて、どういうことが悪いのかみたいな。割とベーシックな話。

うんうん。

を、えー、データから見ていこうみたいな。データの形から見ていこうっていう、ちょっとお話をさせていただきます。

おー。データの形。

はい、形。

おー。

うん。まあ形という。と。

実際でもそうですよね。

そう、そう？

データが元々あって、それをなんかどう保存してったらいいのかなって考えて、考えろ、ん？考えて決めるわけですよね。

どうなんでしょうね。物によるんじゃないですかね。

そんなことない。

いや、今日の話はデータが、データから考えようっていう話ではあるんですけど。

うん。

データから考えない人とか場合もあるんじゃないかな。なんかどこまでデータを考えるときに整理するかみたいな。

うーん。

ことはあんのかな。でも言うてちゃんとやんのかな。まあいいや。というのでですね、ちょっと今日のお話なんですけど、データ思考アプリケーションデザインという書籍の第2章の話をちょっとしようかなと思ってます。

データジャンピングイノシシ本じゃん。

本、あ、本ね。ジャンピングイノシシ本ね。

レッドジャンピングイノシシ本じゃないですか。

はい。これ、あのー、2019年でちょっと古い本なんですけど。

はい。

すげー人がみんなこれ読めって言うんで。

うん。

読んでるんですよ。

結構すごい比率で出てくるよね。

もうね、あのー、それこそね、リーダブルコードぐらい出てきますよね。

出てくる？

うん。

えー。ほんとにこの分厚い本を皆さん読んだんですかってぐらいの比率で出てくる。

ね。で、この本、な、どんな本かというとですね、まあデータ思考アプリケーションデザインなので、データ思考でアプリケーションデザインしてこうぜっていう本なんですけど。

うん。

うん。えー、まあ、ひ、ど、ポイントは多分、なんかアプリケーションって、割となんか昨今はデータがネックになりますと。例えばなんかデータがめっちゃ複雑だからこういう設計にならざるを得ないとか。

うん。

あとはそのパフォーマンス、アプリケーションのパフォーマンスに関しても、どういうふうにデータベース設計するかによって多分読み書きのスピード変わったりするでしょうし。

うん。

それって割とトレードオフだったりしますと。そういう場合にどう分散させるのかとか、えー、どうレプリケーションさせることによって、えー、障害、耐障害性高めるのかとか。なんかそういうところって割と、まあデータの部分から考えるとおのずと答え導けるんじゃないみたいな。

なんやて。

考え方があってですね。

はい。

そのへんを細かくなのかな。まあいろいろ事例とかを交えながら。

うん。

知識整理をしてくれて、最終的にこういう場合はこうするのがいいよねみたいなのが分かるっていうのが、まあこの本らしいです。

ほー。

うん。すっごいおもしろそう。

確かに。

うん。っていうので2019年の本を、えー、今更ながら読み始めて、今2章まで読んでおもろそうっていう段階なんですけど。

いやー、でも2019年ってなんか、めっちゃ最近な気がしてるけどめっちゃ前なんだ。

7年前。

すっごいな。

やば。まあまあでもね、2019年、僕も社会人3年目だったな。うん、昔だな、かなり。はい。っていうので、まあいろんなコアな話もあるんですけど、今日は割とね、ちょっと優しめというか、まあ第1回目。データ思考アプリケーションデザイン第1回目ということで、キャッチーかつベーシック寄りのちょっとお話をします。

ありがとうございます。ほんの1、2章のところの感じが。

まあ1章はですね、てかこの本珍しくてですね、あ、まあ珍しくないのかな。なんか1章はこのデータ思考うんぬん、もうまあ若干触れてるんですけど、どっちかっていうと。なんか信頼性とかスケーラビリティとかメンテナンス性って、なんだっけっていうところから始まるんですよ、1章は。

うん。

で、2章から、まあなんかこういうデータモデルあるよねとか、えー、ストレージエンジンうんぬんみたいなのが、まあ続いてくので、なんか1章にこの本の概要バッと書いてるみたいな形式ではないですね。

うんうんうん。

1章でターゲットを定義したみたいな。

なるほど。

形だったんで、まあちょっと飛ばしました。

飛ばしたんかい。

はい。あの、あの、あれですよ、そのエピソードにするのをね。

ああ、そういうことね。

はい。まあ今日は、まあMongoとRDBちょっと比較してこうぜって話になります。

うーん。あんま悩んだことないかもな、その2択で。

あ、そうですか。

うーん。

えーっと。で、なおかつ、なんでしょうね、その違いって言っても、なんかレプリケーションの仕組みとかトランザクションうんぬんとか、まあいろいろあるんですけど、今日はもうあくまで、なんかデータモデルの違いだけをちょっと見て、こういう特徴あるんだなっていうところをちょっとさらっていこうかなと思います。

うん。はい。

で、まあ一旦ね、ちょっとせっかく触れるんで、若干歴史も振り返りながらいこうかなっていうところが、ところから入っていくんですけど。データベースですね、1968年とかにですね、これはあの、えー、リレーショナルモデルと呼ばれるのが1970年に生まれてるので、まあそれより前に、階層型の、階層型でデータを整理するやつがいました。IMSっていうやつがあったらしいんですけど。

うーん。

もう、で、この、まあ言語とか超細かいところは触れないんですけど、今回そのMongoと、えー、RDBを比較する上で大事になってくるのが、データとデータの関係がどうなってるかというところになります。

ほう。

で、えー、めちゃくちゃ昔に出たこのIMSっていうやつは、データとデータの関係どうなってるかというと、えー、家系図的に。に、えー、これ元々なんだ、えーと、アポロ計画の部品表管理のためになんか作、使ってたらしいんですけど。

へえ、かっこよ。

はい。だからなんかこのロケットっていうのが、まあ親でいて、ロケットの下にエンジンとか、えー、外装のパネルみたいなのが、まあ紐づいて、家系図的にその親子、親子関係だけが表現できるっていうのがこのIMSの特徴でした。

うん。

で、ただなんか世の中のものって叩いたがありうるじゃないですか。

うん。

で、じゃあ叩いた表現したいよねみたいな。ところで出てきたのが、CodaShellっていう。

CodaShell。

はい。このネットワーク型っていう方式のデータベースらしいですと。

はいはいはい。

で、ただこの叩いたの、このデータベース、めんどくさかったのが、あのー、割とSQLって線源的にデータ取ってくるじゃないですか。あのー、このテーブルの中の、このカラムでこれを持ってるやつ引っ張ってきてみたいなことを言えるじゃないですか。

うん。

うん。で、なおかつなんか別のテーブルと紐づけてうんぬんやるときもなんか、なんかどういうふうな検索の仕方をしてみたいな、なんかそういう手続き的な指定あんまりないじゃないですか。

うーん。

あー。

うんうんうん。

で、このネットワーク型のCodaShell、えー、テーブルとテーブルがなんかポインタでつながってたらしくて。

うん。

なんかこの、こことここの、ここのデータを結合して引っ張ってきてみたいなやつを、なんて言えばいいんだろうな、なんかアクセスパスを指定してしなきゃ、指定して引っ張ってこなきゃいけなかったみたいなんで。まあまあとにかく、まあデータを結合して引っ張ってくるのがすごいめんどくさかったですと。

えーと、ど、どういうふうに結合しなきゃいけないかも指示出さなきゃいけなかったってことですか。

そうそう、はい。

うーん。

うーん。まあ迷路みたいになってたと。っていうので、これめんどくさいなっていう経緯があって線源的に定義ができるリレーショナルデータベースっていうのが出てきますと。

ほう。IBMから。

IBMだっけ。

じゃなかったっけ、コット博士だよね。

あ、そう、コット、コットさん。すごいな、さすがの解像度の高さ。

雑学。

で、なのでそのリレーショナルデータベースって線源的なので、えー、クエリのなんだろうな、実際に取ってくるときのなんか実行計画っていうんですか。

うん。

実行計画良しなにやってくれるんで、パフォーマンスが出やすいです。

確かに。はい。

これ線源的じゃない手続き的だと、実行計画ごと渡さなきゃいけないんで、なんかほんとに良しなに動いてくれないですと。

へえ。

で、なおかつ、えー、線源的なので、なんかhowまでは指定しないから、記述量も少ないですと。

うんうんうん。

っていうので、まあめっちゃええやんっていうのでずっと派遣を取り続けたのが、まあリレーショナルデータベースRDBですと。

うんうん。

で、そんな中、まあNoSQL、Not Only SQLっていうのができますと。で、まあこれはなんでできたかというと、まあスケールですね、データ量、扱うデータ量が増えてきましたっていうのと。

うん。

で、あとはなんかボコボコスタートアップができる中で、仕様めっちゃ変わる状態でもなんか開発を進めていきたいというニーズが出てきて。

うん。

RDBだとスキーマ変更しようと思ったら、まあできるんですけど、まあちょっと大変ですと。で、そんな中で、えー、Mongoとかだと、なんでしょうね、アプリケーション側で、えー、スキーマちょっと違う場合の例外処理書けばいいんで、なんかデータの更新を一括にしなくても、まあ徐々に変えていけるみたいな、なんかそういうことができるのに、しときたいみたいなニーズもあって、まあNoSQLができてきた。あとは、まあリレーショナルデータベースで対応できない、まあグラフ型のNoSQL、えー、ほんとに、ほんとに叩いた、なんかフォローとかフォロワーとか、なんかあのへんのデータの表現とか。まあなんかそういういろんなニーズがあって、まあNoSQLがまあだんだんと生まれてきましたと。

うん。

いうのがまあ一旦ざっくり歴史になりますと。

なるほど。まあRDB使っててつらみが出てきたからそれを解消しようみたいなムーブメントってことですかね。

そうですね。うん。で、まあここでまたドキュメント型、Mongoとかのドキュメントを扱うDBとRDBの話にちょっと戻るんですけど。

うんうん。

えー、アプリケーションって、まあオブジェクト指向プログラミング人気じゃないですか。

はい。

で、オブジェクト指向とRDBって、えー、相性悪くはないんですけど良くはないんですよね。

うーん。

あー、あれですか。か、あの、難しそうなやつですか。

うん?

インピーダンスミスマッチみたいな。

おお、すごいですね、そのワードが出てくるの。言わないとこうと思ってたのに。インピーダンスミスマッチっていうのがあってですね。

はい。

えっとー、なんかまあ経験あると思うんですけど、データベースに、えーっと、RDBに書き込むときに、RDBになんか変換してから書き込まなきゃいけないじゃないですか。

うんうんうん。

で、なんかその変換しなきゃいけないそのミスマッチのことをインピーダンスミスマッチって言うらしいんですけど。

うん。

ドキュメント型だと、あの、アプリケーションの中で扱ってるJSONをそのまま突っ込めるんで、楽なんですよ。

うん。

RDBってざっくり言えば表形式だからオブジェクトと形違うよねって。

あ、そう、はい。

表形式って正方形みたいな、なんか正方形ではないか、四角いけど、オブジェクトってなんかもっとギザギザしてるよねと。

うんうんうん、はい。

だからこれを四角く整形して格納しなきゃいけないし、表から取り出したやつはギザギザに整形しなきゃいけないしみたいな、なんかそこがめんどいんですよね。

そうそうそうそう、めんどくさい。

うん。

そこがちょっとめんどくさいなっていうのが、まあRDBの特徴になりますね。

うん。

で、えーっと、ドキュメント型のモデルというか、ドキュメント型の、あの、Mongoに入ってるやつ、ちょっと想像してもらうと、まあJSONでポコーンと入ってますと。で、さっき言ったその、データとデータの関係値っていうんですかね、って、Mongoって、まああの、テーブル間、まあコレクション間、コレクションって言うんですけど、Mongoだとテーブルみたいなやつ。

うんうん。

の、まあ連携はRDBほど強くないですと。

うーん。

なので、そのデータ間、テーブル間っていうのかな、まあモデル間のデータの関係って、まあ割と1対多が強い。というか、まあその1つのコレクションにまとめちゃう使い方が、まあ向いているんですよ、Mongoって。

うんうん。

うーん。で、そういう使い方すると、まあスキーマの変更するときもやりやすいし、データが1個にまとまってるから、あの、パフォーマンスも出るし。っていうのが、このドキュメント型のデータベースの特徴になります。

うんうん。

それゆえ、そのドキュメント型のDBを使うかいなかっていうところのポイントとしては、データの、あの、アプリケーションで使うデータって、まあいろいろ出てくると思うんですけど、そのデータとデータの関係値がどうなってるか。で、えー、叩いたのデータがそんなに多くない、1対多になってることが多ければ、その1対多の関係値を全部1つのコレクションにまとめてしまって、まるっと引きますっていうのかな、取り扱うような作りにすると、まあMongoとかのうまみが得られるよねっていうのが、まあ1個ポイントになります。

ほう。

で、逆に叩いたで、えーと、Mongoとかドキュメント型を使おうと思うと、めんどくさいのが、いろんな、まあなんかちょっとMongoの作りにもよるかもしんないですけど、コレクションの作りにもよるかもしんないんですけど、コレクション跨ぎで同じデータ持ってたりとか、あとはコレクション横断で、えー、データをくっつけたりする場合に、アプリケーション側のコードがすごいめんどくさいことになります。

うーん。

あとは、まあデータが変わったり、いや、まあでもそうだ、アプリケーション側のコードがめんどくさくなりますって言い方が合ってるな。いろんなコレクションから読んだり、いろんなコレクションに書き込んだりとかっていう。

うん、はい。

ことをする必要がMongoだと出てくるので。なので、なんかデータ間の関係が、まあすごい複雑に絡み合ってる。まあ1対多だったらまとめちゃえばいいけど、叩いたに絡み合ってると、まあMongoは向いてないっていうのが、まあポイントになってきます。

なるほど。ちょっとMongoの機能があんまりわかってないんですけど、Joinみたいな、RDBで言うJoinみたいなところが結構弱めみたいなイメージで合ってます?

合ってると思います。ちょっと待ってくださいね。

うんうん。

なんか機能的には、まああるイメージではあるんですけど。

うんうん。

結局その、これちょっともう次の話に行っちゃうんですけど。

うん。

そのRDBとMongoの違い、なんかそのスキーマあるないみたいな話あるじゃないですか。そこがなんかそのコレクション間の結合めんどくさい、めんどくさくないって話に関わってくるかなと思ってて。Mongoも結局スキーマあるんですよ。

あるんだ。

っていう言い方をしてて、なんかないわけではないっていう書き方が本ではされてたんですけど。

へえ。

スキーマの責務をどこが持ってるかっていう違いですと。で、RDBはデータベース側でスキーマの責務を持ってますと。で、えー、ドキュメント型はアプリケーション側でスキーマの責務を持ってますと。

それは強制されるの?

アプリケーション側で強制する作りになる。ってか、強制する作りにすべきっていうのかな。

ああ、じゃあ、だから、えっと、なるほど、そういうことね。どっかでは担保しなきゃいけなくて、えー、そうしたほうがいいよっていう感じか。

ああ、そうですね、はい。し、実際アプリケーション作るとだいたいそうなるとは思います。

うーん。

なんかよっぽど、なんだろうな、なんかセンサー、いろんなセンサーの生データ1つのコレクションに突っ込みます、そんなことあんのかな。まあ、みたいなことをすれば、なんだ、スキーマに、スキーマはちょっとなんだ、整理されない状態にはなると思うんですけど、あんまりないと思うんで。

うんうん。

結局Mongoに投げ込むときもね、多分モデルに突っ込んでオブジェクトと、というか、まあインスタンスにして、そっからデータ入れるはずなんで。

うんうん。

で、それゆえそのアプリケーション側でそのスキーマをどうにかしなきゃいけないので、コレクション。同士で何かつなごうとか、なんかいろいろ複雑なことしようと思うと、アプリ側がどんどんつらくなってく。

うーん。

っていう、まあ、色、色というか。まあそういうふうに特徴が分かれてます。で、このなんかどっちで責務を持つかみたいなのが、スキーマオンライトっていうのが、えー、データベース側、そのデータベース側で責務を持つ。だからリレーショナルデータベースはスキーマオンライト。で、ドキュメント型のほうはスキーマオンリード。という、これはなんだ、えー、方式。

はいはい。

っていう、まあスキーマオンリード、スキーマオンライトっていう方式があって、えー、RDBはスキーマオンライトという方式らしいです。

ああ、書き込むときに制限されるというか。

へえ。

そういうことか。

で、読み込んだときにアプリがスキーマを解釈するのがMongo。

うんうんうん。はいはいはい。

まあなので、まあなんか具体的なちょっとユースケースをちょろっと言うと、これあの、なんか必ずどっちか使わなきゃいけないわけではなくて、アプリケーションの規模によってはどっちも使うこともありますと。

うん。

このデータ、例えば、うん、なんかめっちゃでかいオンラインゲームみたいなのがあったとして。

うん。

えー、まあなんかセーブデータ、例えば主人公の名前、ちょっとオンラインゲームの解像度低すぎるんですけど、えー、主人公の名前とかIDとか、えー、あとステータスみたいな。所持アイテムとか、わかんないけど。所持アイテムは違うかな。まあなんかそのへんのセーブデータですね。セーブデータは、まあMongoで持たせてもいいはず。その1人のユーザーに対してまるっと取ってくるものだから。

うん。

一方で、えー、ゲーム内のデータっていうんですか、どこと、例えばなんかじゃあ誰と誰がフレンドだみたいなのは別のグラフ型のNoSQLになるかもしんないし、えー、アイテム管理テーブルみたいなやつはリレーショナルのデータベースかもしんないし、みたいな感じで、規模がある程度あればデータベース使い分けれるし、そこまでいかないんだったら、まあどういう質のデータが多いかによって使い分けしましょうねみたいな、まあ今日の話の本筋になります。

うん。うーん。

まあとはいえじゃああのRDB勝手に使えばええやんっていうふうに若干ちょっと聞こえるかもしんないんですけど。

うんうん。

スキーマがやっぱいっぱい変わるとか、あとはなんかツリー構造が深い。まあ要するにテーブルめっちゃジョインしなきゃいけないとか。

うんうんうん。

うん。で、ジョインしなきゃいけないけどパフォーマンス出ない、それだとパフォーマンス出ないからもう結局じゃあもう非正規化してテーブルを1個にまとめて、データを、なんだろうな、なんか二重管理じゃなくて、複数のレコードにわたって同じデータが入ってもまあしょうがないやみたいなことするんだったら、じゃあそれ結局Mongoでいいよねって話になるかもしんないし。

うん。

やっぱりそこはやっぱデータの構造を見ながら。結局やっぱリレーショナルデータベースも苦手なことはあるので。えー、リレーショナルデータベースは結局ツリー構造が深かったりスキーマ変更が多かったりすると苦手だし、MongoはMongoでデータ間のつながりというか、えー、叩いたの関係がある程度多かったらMongoは苦手だし。それ以上にもっと多かったらグラフ型のほうがいいかもしんないし。

うーん。うーん。

みたいな感じで、まあデータの設計というか、まあデータの設計か、データの整理をしていくことで、じゃあどういうアーキテクチャに使用すべきかみたいなのが、まあちょっとずつ見えてくるよねみたいな。

うんうん。

ところが見えてくるよねっていうのが、まあちょっとこの2章のお話でした。の、で、2章はちょっとグラフ型のデータベースも触れてたんですけど、ちょっと今日はややこしくなるんで省きました。

なるほど。

はい。

Mongo。

いや、なんかそのMongoとRDBの使い分けみたいなところ。自分が持ってたイメージなんすけど、えー、ECサイドの商品とかはMongoが向いてるイメージあるんすよ。

ほう。

で、なんでかっていうと、えー、商品ごとに持ってる属性が、なんか表示したい雰囲気は同じだけど違うというか。

うんうんうん。

例えばTシャツ売ってるとするじゃないですか。そしたらTシャツってサイズとか、色とか、そういうのがバリエーションであるじゃないですか。だけど同じサイトで、えー、プロテインとか売ってるときに、サイズも別にXLとかじゃないし、多分グラムとかキログラムとかに変わるし。えー、色とかどうでもいいし。

うん。

ってなるじゃないですか。だけど商品としてはなんか似たようなエンティティだから、なんか同じように扱いたいけど、なんか微妙にスキーマ違うんだよなみたいな。で、RDBでこれをやろうとすると、なんか死ぬほど1個のレコードにヌルができるところを、なんかそういうデータだとなんかこうMongoのほうが向いてるよねみたいな。なんかそういうイメージとかがあって。ゆえになんかその、なんだろう、データのこう構造に注目して使い分けるみたいな発想があんまなかったです。

僕もなかったっす。

あっす。

そうっす。

そう。僕もなかったんで。

あっす。

ああ、なんかこういう切り口なんだ、なるほどなあと思いながら本を読んでました。

うん。普通に触ってて、なんかこれは読み取るときにスキーマが決まってるんだとか、なんか気づくのすごすぎるっていう。

なんかやっぱりあんまり考えたことなくて、このデータ執行で。

うん。

大元の設計し始めるっていうんですか。だから多分最終的にその、この本で扱ってるのって、アプリをリリースしたあとの、えー、品質の高いプロダクトっていうんですか。

うん。

えー、止まらない、動き続ける、保守性が高いものを作るためには、みたいなところをデータ執行で考えるといえんやでっていう切り口がやっぱあんまりなかったんで。

うん。うんうん。

読み切りたいんですよね、これ。読めるかな。

これはだいぶ時間かかるぞ。結構骨太だもんね。

ちょっと、あんまりね、電子書籍で買ったんでわかんなかったんですけど、のりさんいわく結構分厚いらしいっすね。

豆腐ですか。

結構分厚いっすよ、これ。

お豆腐まではいかない?

あ、物理持ってんだ、のりさん。うわ、でかい。

あのー、ペットボトルの半分ぐらいですかね。

iPhone3台分ぐらいっすか。そんなねえか。

3ぐらいありそう。

iPhoneで言ったら3ぐらいあるよ。それ以上あるよ、多分。

はい。ちょっと読み切りたいっすね。なかなか体力のいる本なんで、興味持っていただけたら読んでもらえればいいし。えー、そうじゃなかったら、まあ僕がかいつまんで一部だけちょっとポッドキャストでお話ししようかなと思ってるんで。乞うご期待で。

600ページありました。

ふええ。いや、すごいね。震えるぜ。え、難易度別に簡単じゃないと思います、これ、僕は。

うん、これむずいイメージあるよ。

なんかむずくはない。

むずく?

めっちゃむずくはないんすけど、その、なんかよくエンジニア1年目に読んでほしい本、ぶわーって並んでる中に入れるもんじゃねえだろうとは思います。

そうね。

うん。別にちょっとむずくないって思いながらちょっと本読んでました。

うんうんうん。

まあでも今どきね、やっぱORAILIでPDF買えば、それをね、NotebookLMとかにズゴンって突っ込んで解説してもらえるんで。

それだな。

ありがとうって感じですね。

ほんとそれよな。

はい。で、ちょっとアフタートークいいっすか。

はい。

はい。

えっと、ちょっとやることの宣言なんですけど。

うん。

ちょっと3日坊主目指せなんですけど、3日坊主っていうか3週間坊主を目指すんですけど。

はい。

ポッドキャストの台本をスライドにしてスピーカーデックで公開するということをやりたい。

ほお。

てか、今、今日はもう私その第1回をやってみたんですけど。

おお、骨太ですね。

そう。Claudeデザインを使ってひまプロっぽいスライドテンプレートを作って。で、そのスライドテンプレートを使って、僕がなんかしゃべりたいなって思ったメモを渡して。

はい。

資料を30から40ページぐらい作ってもらって。で、修正して修正して、資料に、資料、台本として仕上げて。で、それをスピーカーデックか、わかんないけど、まあスピーカーデックかな。スピーカーデックでなんか公開し続けると。もう今だってポッドキャストもね、エピソードも460ぐらい溜まってるじゃないですか。

うん。

で、単純計算、僕が1/3話したとしたら、もう100何十話してるわけじゃないですか。

うんうんうん。

それがなんか音声以外に残ってないのちょっともったいないなという気持ちになって。

お、欲張りだね。

欲張っていく。まあちょっと、あ、まあ音声でしか残ってないからね、罪が重なってないっていうところあるかもしんないけど。目で見える形になるとちょっと。

うーん。

証拠として強くなってしまうけどね。まあアウトプットは大事なんで。

はい。

そういうことをやって、もしうまく回せたらね、なんかノウハウ展開できると良いなと思ってます。

キータとか全じゃなくて、あえてスライドなんすね。

キータとか全でもいいのかなあ。

えー。僕、過去キータとセットでやってて、挫折しましたよ。

キータね。あ、僕もキータでやろうとし、いや、やってたっすよ、1年前ぐらいにちょうど。3週ぐらいでやめたけど。

あ、マジで労力えぐすぎたね。

なんかブログだとAI感出ちゃうんですじゃないですか。てか、まあ、いや、別にスライドでも出るけど。

うん。

でもスライドのAI感はまだ許されると思うんすよね、なんか文章短いから。

ああ、マジ?

うん。そんなことないかなあ。

いや、どうだろう。なんかスライド自体がAIっぽくなるなあとは思ってたけど。

まあ、それもそうなのかなあ。

まあでもClaudeデザインは確かに。

うん。

中でもAIっぽくなりにくいほうでもある。

うんうん。まあっていうのでちょっと軽く宣言でした。

なんかAIエージェントを使ったシステムでちょっと自動化できたらいいっすね。

まあ、便利そうだったらね。

うん。

そうだね。

エピソードの壁打ちをやって、固まったら台本とスライドとキータの記事を全部出してくれると。

で、ちょっとチェックして、OK出したら全部に一気に発信、投稿してくれる。素晴らしい。

素晴らしいね。

まあ一応ローカルでスキルとかコマンドにはしたけど、でもまだまだ多分実際に使いながら改善してって感じかな。なんかあの、自分の中で台本を作るときになんか守りたいポイントみたいのがあって。それはなんかちょっとまだ落とし込みきれてないなって感じはするんで。

うん。

はい。ちょっとブラッシュアップを3週間頑張りますが、どうなることやらですね。うん。

いや、いいっすね、でも。

はい。あ、ごめんなさい、もう1個いいっすか。

あ、もう1個?

はい。ちょっとゴールデンウィーク終わりたてぐらいじゃないですか。

おお。はいはいはい。

で、前回の収録のときに、えっと、EC2にClaudeコードを動かして、で、ほぼレビューなしで開発進めるみたいな話をしたんですけど。

はい。

で、ここのゴールデンウィークで多分150コミットぐらいしたのかな。

おお。

意外にアプリ壊れてなくて、最近のAIすごいなって思ってます。

うーん。えー、マジ?

はい。全然壊れない。

うーん。

で、一応なんか素でやらせてるわけではなくて、スーパーパワーズっていう、何、スキル?

うん。

かな、を使ってレビューとかを、動作確認とか、実装フローとかを回してはいるんですけど。うーん、なんか今んとこうまく回ってて、えらいなあという途中報告です。

いやあ、でも最近マジで確かにエラー出ないわ。

出ない。なんかマジで去年の年末とかも同じことやってて、すぐぶっ壊れてたんすよ。

うーん。

で、直すのめんどくさいぐらいぐしゃぐしゃになって。

うーん。

頑張って戻すみたいなことをやってたんですけど。壊れなくなったなあ。

4.7から。

いや、まあどっちが、どっちのせいなんだろうなあ。LLMの性能なのか、はたまたスキルなのか。

いや、LLMあるんじゃないかなあ。

Claudeのブログでハーネスの効果のほうが高いよっていうふうなブログは出てたんで。

えー、そうなんだ。

はい。AIモデルの性能というか、うん。そっちはもちろん聞きますけどね。

うーん。いや、なんか去年までさあ、俺も感覚去年変わったイメージあって、去年の年末ぐらいに。

ああ、はい。

それまでは実装終わって、なんか動かないこともあったし。

うん。

なんならなんかテスト20個ぐらい失敗してるんですけど、みたいな。

うん。

のとかも全然あった気がするんだけど。最近マジで、うわ、この機能ついてないじゃん、はあるんだけど。

はい。

なんか動かなくねえとかはないし。

うん。

テストは失敗してるのを最近見たことないかもしんない。

そうなんよね。そう。なんで? ちょっと開発したほうがいいっすよ、みんな。

急に? 急に?

めっちゃ簡単になってる。

ああ、そういうこと?

はい。エンジニアね、特にね。

はいはいはい。

なんかバグとかあったとしても、なんかもうバグのタグ付けてGitHubのイシューにポコポコ溜めるじゃないですか。

うん。

で、溜めといて、で、なんかClaudeコードに依頼できるわっていうタイミングで。

うん。

このバグ全部直してって言ったら。

うん。

ずーっと動いて直ってるしね。

へー。

うん。すごい。

すご。

てか、そうか。

まあ、それ用のスキルとかスーパーパワーズとか、なんかその、なんだ、その周辺スキルをこういうふうに使って開発進めてくださいみたいな指示はして、そういうコマンドにはしてるけど。

うん。

それだけでなんか良しなにやってくれてて。

へー。

すごいけど、でも実務でやる勇気はない。本当に。取り返しつかない壊れ方っす。

まあ、まあ、そうね。まあ、その投げ方は確かにそうかもしれない。

1日、1日無駄にしそう。

うん、あり得るね。

で、1日バーってやって、うわ、全然だめだ。最初からやろうみたいな。

なんだこれ。もう何ができたかわかんないよね。

そうそうそう。変な機能できてるみたいな。作ってて頼んでないやつできてるみたいな。

ありそうだなあ。

まあ、みたいな感じで、なんかいいゴールデンウィークでした。

うん。いいっすね。

はい。

ちょ、僕も最近その開発の体験で感動したのあって。

はいはい。

今さ、ChatGPTさ、あの、Image2で出て。

ああ、はい。

画像の精度めっちゃ上がってるじゃないですか。

噂だとそうらしいっすね。触ってないんすよね。

そう。あ、もうあれね、あの、7バナナ超えてますね、今。

へー。え、どんなことができるの?

使いやすさは。えっと、基本的には日本語まず崩れないし、結構細かいのも出せるのよ。

すげえ。

で、デザイン性結構高い。

はい。

で、バナーとかサムネとかだったら多分1発でポン出しで使えるものが出てくると思う。

へー。

うん、うん。で、そいつを使って、あの、アニメーション、アニメーションを実装したいと。こういうインタラクションで出てくるアニメーションを実装したいみたいな。

うん。

っていうのが自分で思いつかないから、その、どういうふうに出せばいいってのをまずChatGPTでやり取りして。

はい。

じゃあ、ちょっとそれを画像で見せてくれっつって。

うん。

どういう感じになるのかみたいな。で、そしたらその画面のイメージとどういうふうにアニメーションが出てくるかみたいな説明の画像が出てきて。

へー。

で、それをそのままCursorにスッて渡して、これやっといてっつったら、それ出て、できて、完成してた。

すげえ。すげえ、それは。

フロントもこんな精度高くいけるんやみたいな。

そうなんだ。

うん。

え、アニメーションを画像で出したってことっすよね? だからなんか。

あ、うん。

ステップ1、この青丸がこうなってこうなるみたいな。

あ、そうそうそうそう。説明文プラスそのときのちょっとイメージ図みたいな。

へー、それでやってくれんだ。

はい。1個にまとまってるやつで、まあCursorにはその画像を添付して、これよろしくっつって。

おもろ。いいっすね。

結構ちゃんとできてたから。

おお、いいっすね。それはめっちゃいい。

うん。

そのイメージ図はどうやって作ったんすか。

Claudeデザインとかでできないのかな。

え、イメージ図? イメージ図もそのChatGPTに画像作ってっつって。

壁打ちながら雰囲気こんなんでって言ったら、なんか具体化してくれて。

うん。

最終的に具体的なのができたってことっすよね?

あ、そう。ちょ、説明だとピンとこないから画像にしてっつってやったら。ファーンって。

すごい。おもろい。

Gemini微妙すぎますよね、最近。でも昨日なんか突然お前って言われて。

Geminiで。

お前、お前。お前何したんだよ、Googleに。

お前、急に。

はい。

お前って呼ばれてんだ。

びっくりした。

おもしろいな、それ。

うん。

使ってないんですよね、正直。

Gemini?

最近?

ま、まったくと言っていいかも。