00:01
kokorokagami
はいどうも、kokorokagamiです。
touden
当然です。
kokorokagami
今週も一週間、振り返っていきたいと思います。
touden
はいはい。
ツイッターからの移行
kokorokagami
最近は、メタ書のスレッツがめちゃくちゃ話題ですね。
touden
そうですね。なんかあの、いろいろやばいというところで、流星のごとく現れた、
あの、機体の新人君でございますけども、いかがでございましょうか。
kokorokagami
そうですね。まず使ってみた初感としては、まあ初期の頃のツイッターの感覚に近くて、
まあ必要最低限なことがシンプルに組み込まれてるなという印象です。
で、逆にやっぱり最近のツイッター、まあイーローマスクスさんに変わる前までのツイッターはだいぶいろいろ洗練されてたなと思うところが、
あの、SNSを利用する上で、自分の興味ある人たちとコミュニティを築けるかっていうのが重要なSNSのポイントだと思うんですけど、
まあそこに対する動線がやっぱりまだまだ少ないので、スレッツを始めた直後では、
ちょっと、あの、ツイッターのようなタイムラインを期待するように組もうと思ったときにどうすればいいのかが、
touden
見つかってこないっていうのが現状課題かなとは思ってますね。
まあそこはでもツイッター側も悪いと思ってて、そのツイッターの初期を考えたときに、
あの時代だと、なんだろう、ミクシーとかからアカウントこれありますってリンクがあって、
まあそれを辿っててツイッターがこれあるなと思って登録みたいな感じだったと思うんですけど、
今の段階だとツイッターの代替案として移動する人が結構多いと思うんですけど、
ツイッターが公式に対抗馬のSNSのリンクを貼ると、
バンするぞって脅してるので、なんかちゃんと貼ってる人がいないんですよね。
そうですね。
なのでその分、なんていうんですか、リンクが辿りにくくて、
とりあえずざっくり100人くらい登録してみるかみたいなことができないのがちょっと、
なんていうんですかね、そこの最初の立ち上がりの扱いづらさに拍車をかけてしまっている感はあると思いますね。
スレッツの現状課題
kokorokagami
そうですね。
メタ社としてはフェイスブックがもともとあったんで、
フェイスブックインスタグラムの動線でコミュニティを築いてよということなんだとは思うんですけど、
おっしゃる通りツイッターから移行先を探してたどり着いた人たちにとってはちょっと動線を持たないという状態はありますね。
touden
そうですね。
で、インスタはインスタで使っている人はインスタでいいじゃんみたいな感じもなくもないので、
やっぱり作ったってことはツイッターからの移行を期待してほしいということを考えると、
そこはもうちょっと頑張る方法があったのかなという気はしています。
でも、ツイッターで投稿するボタンみたいなのは作ってはいるんですよね。
ただそれはツイッターが先ほど言った通り禁止しているのであまり使っている人がいないという、難しいねという感じですね。
kokorokagami
そうですね。
ツイッターとしてはこういう競合を生まれさせないための努力をしているように見えるので、なかなかやりづらいところは正直あると思いますね。
このスレッドも今時点でいろいろ健全なツイッターから移行する先として適切な環境化と言われたらまだまだそうではなくて、
iOSで必須となっている家事情報によるとユーザーの健康、金融データ、位置情報、ブラウジング履歴、連絡先検索履歴等々を参照するということになっていて、
Facebookの参照機能と同じだけの権限を要求してきているんですけれども、
現状のSNSでできることを考えたら明らかに過剰な権限要求になっているというところもあって、
EUでのリリースが遅れていたりしている状況もあります。
ところで、爆発的なユーザー数確保には成功しているものの、
このユーザーをとどまらせるための施策というのが、
やっつき部屋に打てていかないと結局使われなくなりそうだなという雰囲気もあって、
現状この1週間くらいですかね、先週木曜日水曜日くらいにリリースされたものだと思うんですけど、
そこから特に大きなアップデートもなく現状に至っているので、
なかなか住み着く人が少なそうな印象は持ってますね。
touden
それは現状はそうなんですけど、
結論が請求すぎる感じもしますけどね。
kokorokagami
まあそうね。
touden
現状ツイッターが動いてはいるので、そこからの水くだりとも発生していないですし、
ポロポロとみんなが移動して、
アカウント登録者数がいるにはいるので、
そこで欲しい情報を提供してくれるコンテンツ提供者が活動をずっと続けていけば、
だんだん増えていくような気はせんこともないですけど、
いかんせんツイッターに過ぎているインターフェースなので、
ツイッターが動いてたらツイッターでいいやってなってしまう人も多い感じもあるところなんですね。
そういうことを言うと、スレッズとしてはツイッターの五輪獣増しということになってしまうのですけど、
それもなかなか苦しいなという気もしていて、
kokorokagami
何か独自性を出せるといいはいいんですけど、難しいですね。
touden
それフェイスブックやインスタグラムで良くないと言われてしまうとねっていうところがあるので。
kokorokagami
そうですね。
touden
特にスレッズっていう名前が良くないなっていうのはめっちゃ思ってて、
kokorokagami
ツイッターの嫌いなところをあげた時に、他の人のレスポンスがつくところっていう人って少なからずいると思うんですよ。
はいはい。
つぶやきを発信して、そんなこと考える人もいるんだふーんで流していきたいのに、
お互いにレスポンスをし合える関係があるから無駄なヤフコメみたいなのが発生してしまうっていう問題があるじゃないですか。
クソリプ問題。
touden
レスバトルみたいなね。
そうそうそう。スレッズっていう名前はそれを尊重するかのようなタイトルになってるんで、良くないなって。
もうちょっとクリーンなSNSを作った方が良かったんじゃないかという話ですね。
大手企業の参入と競争
kokorokagami
そうですね。誰かの投稿にレスをしていくのがスレッドじゃないですか。
はいはい。
その投稿にレスをつけていくっていうことを意識したプラットフォームなんですよっていうのがタイトルから示されてるけど、
ツイッターミンはそれを喜んで使ってはいないというところがあるので、
そのコンセプトとツイッターの意向先っていうところがマッチしないなっていう感が少しあります。
touden
そうですね。
確かに。
そこら辺を整備して炎上しにくいSNSっていうのができたら、
他のユーザー層とか、あとは公式アカウントみたいなのも今少ないんで、
そういう企業さんに安心なSNSを言うて入ってもらって定着させていくとかはいいかもしれないですね。
kokorokagami
そうですね。今のところ大手系はあったんでフォローアップはしましたけど、
テククランチとか、AWSやマイクロソフトの公式アカウントですとか、
マイクロチップとかの公式アカウントとか、
日本でもフォローアップしてたような、ツイッターでフォローアップしてたような企業はそこそこあったんですけど、
日本企業が入ってるかというと全然入ってないので。
touden
そうですね。
kokorokagami
日本企業はだいぶ様子見を知る感がありますね。
touden
そうですね。そこら辺も含めて、ぼちぼちやってったら移行していく人も増えていくとは思うので、
そこまで根性あって続けられるかどうかが結構分数理論なのかなと個人的には思っているところですので。
kokorokagami
そうですね。
touden
頑張っていってくれたらまた世界が変わるんじゃないかなと思っていますと。
kokorokagami
他にも元ツイッター社員が立ち上げたSNSとかいろいろぼちぼちが生まれつつあるのでね。
この辺の競合で出てきているSNS群の中で、ある技術的にはいいポイントがあってですね。
このスレッズとか他で作られているSNSのベースとなっている技術というのが、
パブリックな機関によって認定されている技術で、
名前で忘れちゃったけど、
SNS向けの標準企画みたいなのがあるんですよ。
複数人のユーザー間でコミュニケーションを取り合う上で、認証とかセキュアにお互いに情報をやり取りしたりとか、
メッセージを投稿し合えるための必要なAPIリファレンスとかその辺の企画が制定されていて、
それをベースにこのスレッズとかも作られています。
代表的なものだとマストドンとか、あの辺も同じ技術です。
なので、基礎技術を同じものを使って、いろんな見せ方をいろんな企業がやっているという状態なので、
次期SNSの開発の姿としては非常に正当性があるというか、
あんまり誰かが囲い込むような競争の仕方をしていないので、
むしろSNS競争時代としては、ちゃんと誰かが独占しているという状態ではなくす方向になりつつあるので、
まあいいのかなという気もしています。
touden
そうですね、インフラ側はなんかこうハードコーティングというか、
スパゲティになっていったらツイッターみたいになる可能性があるので、空中分解しながらちょっとビルドし直すみたいなことになっているのでね、
現状。そういうのはいいかもしれないですね。
kokorokagami
すみません、アクティビティパブって言います。
アクティビティパブっていう非中央集権分散型SNSプロトコルのオープン標準。
W3Cが定義しているものですね。
W3CはHTMLとか定義しているようなところなので、かなり大きなパブリック団体ですね。
なので今後の登場を楽しみに。
それともね、現状は日本人のアカウントを探していくと、ものすごいうっさん臭い人たちしか見つからないので、
今日本人で日本語を投稿しに行くメリットはほぼないなと思いながら見てますね。
touden
でも何万人でしたっけ?すごいでずっと登録してる。
kokorokagami
1億人超えたんじゃないかなと思って。
touden
1億人超えたんでしたっけ?
kokorokagami
日本人がほぼいないんじゃないですか。
touden
なるほどね。
kokorokagami
日本人1億人が入ったとは言ってないですから。
touden
そうですね。
kokorokagami
そうですね。5日前に1億人突破。サービス開始から5日間でっていうことで話題にはなってますね。
touden
やばいっすね。
kokorokagami
今後もちょっと注目ということで。
はい。
枠が長くなっちゃいましたけど、本題の方いきたいと思います。
touden
はーい。
kokorokagami
1点目。
AWS Japan 日本の大規模言語モデル開発を支援する AWS LLM 開発支援プログラムを開始。
ということで、IoTニュースの記事です。
AWSは、AWS上で生成AIを開発することができるクラウドサービスAmazonBedRockや、
事前学習済みの機械学習モデルをデプロイするAmazonStageMaker Jumpstartにて、
大規模言語モデルLarge Language Model LLMを提供している。
一方で自社でLLM開発を進める企業からは、
LLMの開発にはモデル構築に関するAIの専門知識を必要とするほか、
モデルを学習するための大量の計算機リソースの確保、
分散学習を実現するためのインフラ面へのガイダンス、
計算機リソースの使用に利用するコストなど、
様々な課題の声が上がっているのだという。
そうした中、AWS JapanはこうしたLLMの開発を行う、
AWS LLM開発支援プログラムの開始
kokorokagami
日本国内の企業や団体を支援するAWS LLM開発支援プログラムの応募・受付を開始した。
このプログラムでは、LLM開発を行うための計算機リソース確保に関するガイダンス、
AWS上でのLLM事前学習に関わる技術的なメンタリング、
LLM事前学習用クレジット及びビジネス支援等のサポートを提供するということで、
AWSがAzureに臆病を取らないようにということで、
自然言語モデル等のLLM開発に向けた新たなサービスを提供していきましたよという話です。
Azureと比較してAWSが戦う土俵を変えてきたというところなので、
ちょっと理解できるように頑張ってしゃべりたいんですけど、
チャットGPTのサービスを考えたときに、
まず一番フロントにあるのはWeb UIサービスがありますと。
チャットを入力できるフォームとかがあるアプリケーションですね。
その裏には、その入力されたものをLLMへリクエストする前に、
それまでの会話履歴だったりとか、オープンAIとしてはそういう情報は拒否したいとか、
いろんなガイドラインによるチェックが挟まって、
必要なLLM、モデルに投げれるような形に変換してあげてから、
モデルに投げるというようなフェーズを経て、モデルを利用していますと。
そこで言っているモデルというのがGPT3.5だったりGPT4だったりしますと。
そこのモデル自身を新たに開発するということも一つ、
企業としては選択肢になっていますし、そのモデルをうまいこと使いこなすという方向性ですね。
先ほどの話で言うと、ウェブのアプリケーションからそのLLMのモデルまでのリクエストの仕方ですね。
そこにいろんなチューニング要素を設けて、
例えば社内の情報を食わせるとか、そういったこともできますと。
そういった中で、Azureとしてはそのモデルは決まったものをデプロイして、
そこのモデルへどういうものを渡すかというところをどんどん拡張していっているというのが現状で、
AWSの今回のプログラムというのは、モデル自体を新たに作るという方に着目していますと。
この動きが業界としてどういう受け止め方になるかという話なんですけど、
直近私たちがある商品に何かこういうChatGPTのようなものを組み込みたいですとか、
ちょっと今までは解決できなかったDXをしたいというレベルであれば、
Azureの手法ですね、賢いモデルがすでにあるので、
そのモデルに解釈できるように必要な情報をいろいろ足してあげたりとか、
変換してあげて渡してあげて、その結果を正しく解釈してユーザーに返すということだけで大体はできますと。
ただそれだけでは本当に強い賢いモデルというのはできてきませんと。
言ってしまえばそのAzureのやり方というのは、
会社に入ってきた新しい新人くんにこのマニュアルを見ながらこれやってよっていうのに近くて、
モデルを作るというのはその新人くんに教育をしていって、
こういういろんな技術理解を深めてもらって、
マニュアルとかなしに新たな課題をぶつけられるようにするというような、
そういう根本的な違いがあるんですけれども、
AWSはそのモデルの方に注力しているという状態ですね。
ちょっと話がずれてしまったんですけど、
AWSのこのモデルを作るというのが企業側からどう受け止めているかというと、
主に公共経営の部分ですね。
政府は自国のLLMモデルをどんどん作っていくんだということで、
予算を割いてですね、大手ITベンダーとかが今、
国産モデルの開発というのをニュースの通り掲げていらっしゃったりしますと、
ああいったことをしようと思うと、
このAWSのような支援プログラムが必要になってくるということです。
このプログラムにのっとってLLM開発をしていくと、
どれくらいのスパンかといえば、
だいたい一つのモデルがチューニングできるのに3年くらいはかかるのかなというところなので、
かなり大規模な投資が必要になります。
今回このプログラムの中で、
コストの一部をAWSクレジットとして支援すると言っているのも、
この3年間かかるLLM開発という投資コストが非常にバグ代になることが想定されるためです。
ここで開発に使うような非常にハイスペックなコンピュータリソースというのを1年間使うと、
普通に1000万円とか飛んでいったりするので、
そんな3年間も続けた投資を回収できるかと言われると、
うまくモデルが開発できて、
モデル開発の投資コストと難しさ
kokorokagami
かつ、今までのAzureのようなやり方とは違う一歩越えたソリューションにつなげて、
世の中からお金を取れるようになるまでということを考えると、
かなり10年くらいのスパンを考えなければいけないというところもあって、
投資対効果を見積もるのが難しい観点から、
AWSとしてもこのプログラムを通じて、
より多くのモデル開発部隊が増えていて、
AzureがオープンAIとタイアップしているけど、
モデルを開発すること自体が世の中の標準になっていけば、
結果的にAWSがまたカチューマになっていけるというところがあるので、
そういう戦略を狙っているんだと思われます。
ちょっといろんな話が混ざってしまったので、
分かりにくかったかもしれないですけど、以上です。
touden
同じことやってもしゃあないから、
うちはうちで一から作りますよという話。
分かるんですけど、
結構というか9割博打やなという感じがしますね。
kokorokagami
博打っすね。
touden
勝てるのかな?
半導体の話にものすごく近くて、
kokorokagami
カスタムソックを作って、
AppleのM2に対抗しますって言ってるみたいな話ですね。
touden
まあ確かにね。
いや、そりゃAppleのM2もAppleが独自に立ち上げたから、
まあそれはそうなんですけどみたいなね。
そうそうそう。
今もAppleはそれで売り上げてるから、
まあ確かに勝ち筋はあったんだけど、
今からやってAppleのM2に勝てるかっていうとね、
うんみたいな話。
そうそうそう。
kokorokagami
そのAppleが今で言うと、
オープンAIが作ってるGBT-4とかそういうやつらで、
国産のLLMを立ち上げようと言ってるっていう状態ですよね。
touden
うーん、まあ特定需要だったら、
なんかこうペースする会社はあるっていうのは、
まあ世の常なのでそれは分かるけど、
派遣取れるかどうか、
まあでもチャレンジしないといけないし、
チャレンジしないとダメなんていうの、
その負けがこぶから、
やらんとな、やるしかねえっていう話は分かるけど、
うーん、博打やな。
kokorokagami
うーん、まあちょっと難しいところですね。
半導体の歴史で言えば、
半導体チップ自体を初めて、
世界に展開したのは日本ではないけれども、
日本が普及させるくらいには、
力をつけて開発していったっていう、
一応歴史はあるじゃないですか。
touden
はい。
kokorokagami
それと同じことをなぞりたいんだろうな、
という政府の目論みは感じられるくらいですかね。
touden
うーん、うーん、
まあそれはそうですね、
うーん、まあまあでもあれか、
そうですね、そういう言い方をすると、
えーと半分基礎研究みたいなもんだと思えば、
じゃんじゃんもう金を突っ込むべしという、
話に逆になってくるので、
kokorokagami
うーん、
そうですね。
touden
それによって日本国内でAI開発、
AI開発って言葉が気持ち悪いな、
まあいいや、
LLM開発の人材というか文化というか、
kokorokagami
はい。
そうですね。
touden
をじゃんじゃんバリバリこう、
熟成させていきましょうという話であれば、
まあそれはモロテを挙げて喜ぶ話なので、
幸いにもAWSさんも協力してくれると言ってくれてるし、
じゃあ一応やってみましょうかというお話、
まあそれはそれで確かにいい話ですね。
kokorokagami
そうですね。
このプログラムに手を挙げるのはおそらく、
AWSの戦略と政府の目論見
kokorokagami
日本のITベンダー×各大学のAI研究室×政府みたいな形の、
あのプロジェクトが立ち上がって、
その人たちが手を挙げるんじゃなかろうかなという感じですかね。
touden
なるほどね。
まあそういう視点で言うと、
素直に頑張ってくださいねというお話。
そう。
あとは、
どうぞどうぞ。
AWS側ですね。
うん。
kokorokagami
うん。
touden
まあ作った結果としてAWS上で需要が生まれるんであれば、
いいんでしょうけど、
これもこれでワクチンやなという感じですね。
うん。
作った結果まあそこそこうまくいったけど、
うーん、微妙。
GPT使えばいいかみたいな話とか、
作ったはいいけどメインはGPTだからGPT用にリファインして、
そっちで成果出すかみたいな話になってしまうと、
AWSとしては泣いて終わってしまうので。
はい。
kokorokagami
そうですね。
ただ一つうまいことやってるなと思うのは、
そのAWS自身が新たなLLMを作るとは一切言ってないんですよね。
touden
ああ、なるほど。
はい。
kokorokagami
あくまでAWSはもう必要なコンピュータリソース、
計算資源っていうのを柔軟に提供しますよと。
うんうん。
で、LLM開発に必要な計算リソースの使い方だったりとか、
ネットワークの構築の仕方とか、
そういったインフラ面での支援をしますよと言ってるに過ぎなくて、
そこで成功しようが失敗しようがAWSとしては何の損もしないと。
touden
うんうんうん。
kokorokagami
仮に成功するところができたら、
AWS上でできたんだからそれを真似しようっていう類似事例ができて、
AWSの市場が増えるだけ。
で、失敗したら失敗したで、
じゃあ、オープン映画が出しているようなモデルを自分たちのAWS上で展開するにはどうすればいいのかっていう口をおいおい考えればいいだけの話で。
touden
まあ確かにそうか。
最終的にそこに行き着いたとしても、AWSはAWSで同じことをすればいいだけなので。
kokorokagami
あ、そうそうそう。
touden
一回これでサイコロを振るだけ振ってみて、
まあダメならマイクロソフトとマルコピスすれば良いと。
kokorokagami
そうそうそうそう。
touden
まあ確かにそれは、
そうですね。
ならフリドクジャンっていう話なので。
kokorokagami
そうです。
という見立てがあるんで、
多分AWSとしてはAWS側が投資してでも、
とりあえずLLM使って開発してみませんかという投げかけをして、
損がないっていうことになっているんだと思います。
touden
なるほどね。
はい。
結構良いところに入り込もうとしているなという感じ。
いやー話を聞くと考えられていますねというところですね。
kokorokagami
うんうん。
という感じで、AWSとAzureは真っ向に戦うんではなくて、
領域を変えて戦うという形に落ち着いた感じですね。
うん。
なのであとはGCPとか他のクラウドベンダーがどんな動きをするのかは、
またおいおいニュースになってくるんじゃないかと思うので、
また共有したいと思います。
touden
はい。
kokorokagami
はい。
touden
はい、では次私の方から。
JR東日本新幹線物流拡大実験
touden
日経新聞さんの記事です。
JR東日本新幹線物流拡大少年場車両基地で荷物搭載というタイトルの記事になります。
6月16日、東北新幹線西青森初大宮行きの臨時列車早草72号が運用された。
入れなのは大宮という行き先だけではない。
最上級座席のグランクエースはグリーン車の営業はなく、指定席は1から5号車だけ。
6から8号車の客室には人間ではなく荷物が乗車していた。
その数なんと600箱。
中身は船業、製菓やら、製菓からスイーツ、電子機器までと多彩だった。
実はこの列車、JR東日本が21年10月から箱便の名称で展開している列車荷物輸送サービスのために設定された。
箱便では通常空きスペースとなっている車内販売準備室に最大40箱を積み込んでいる。
あくまでも旅客運輸が主で荷物輸送は重である。
しかし今回の早草72号に限っては荷物運輸の列車に乗客も同車しているという有様だった。
しかも時刻表に書かれた始発は新青森駅だが荷物輸送はさらに2kmほど北の車両基地、
森岡新幹線車両センター青森発出所からスタートしているのだ。
JR東日本が異例となる列車をしたっていた背景には荷物輸送が直面している大きな壁がある。
というところが始まっています。
ちょっと長いんで回数も見ますけど、
そもそもこれを始めたきっかけとしてはコロナ禍だったそうです。
荷物輸送の課題と取り組み
touden
コロナ禍で本格化したとのことですね。
新幹線速達性というかかなり長い距離を速い速度で走るので、
コロナ禍で使用する客が減っていたところで、
じゃあ荷物運んだらどうだということでやっていたというところです。
ただ現状ではウイルスの感染症法上の分離が語呂に移行したことで乗客も戻ってきており、
単純に見ると空で運輸するからもったいないから乗せるという雰囲気でもなくなってきているというのがまず一つ目ということですね。
ただトラックの24年問題とか色々あって、
GR東としては荷物を運ぶというところにもトライしていきたいということで今回やってみたということですね。
ただ記事を読んでみると結構大変さだなと思うことが書かれていて、
先ほど言った通り車両基地でやったんですけども、
荷物を搬入するところが結局人間が乗る実際ドアは2つぐらいしかないわけですよね。
なので結構3時間ぐらいかけて手作業で運び込むみたいなことをやってたらしいですね。
サービスデッキまで荷物を持って上がるのも大変なので、
無人搬送車をわざわざ車両のドアまで100メートル運ぶようにした手挙げで今回運んでみたというところだそうですね。
で、受け取る側も受け取る側で大変で大宮駅にしたのも今回大宮駅ってあまり使ってないホームがあるらしくて、
そこで長時間駐車しても大丈夫だろうということでそこで荷卸したらしいんですけど、
やっぱりホームから駐車場まで運ぶのに1時間ほどかかる荷物があったということで、
ちょっと現状のインフラだと厳しいかなというのが見えてきたというのが実情だそうですね。
実はJR東日本などの荷物輸送は旧国鉄の鉄道越え荷物の規則が元となっているらしいですね。
なので荷物の引き受けと引き渡しは駅と決まっていて、
それ以外のガッツリした荷物は普通というか今まではJR貨物がやっている担当だったのでそこら辺もどうするんだみたいな法律的な解釈もいろいろあるというところで、
全都頼んだなというところでの紹介です。
kokorokagami
まずチャレンジとしては非常に面白いので良いと思うので、いろいろ試行錯誤して課題を出してほしいなというのはあります。
いくつか思ったところがあるんだけど一番致命的そうなのが、
その新幹線路線ってあんまりスケールしないんじゃないかなっていう気がしています。
その新幹線の路線ってローカル線と違ってその経由、避けるための路線が少ない認識で、
その夜間とかはあると思うんですけど、
新幹線が普通に往来している中で貨物輸送のための臨時便を出せるとかそういうことはおそらくないので、
客の利用状況、
だいたい日中は人数少なくて20%くらいしか乗車率がないからやろうとか、
そういう選択肢が柔軟にできるんだったらありだと思うんですけど、
単純にはスケールしていかないので、
例えば今後新幹線が貨物用の車両を間に挟めるように組み替えられるようにするとか、
そういういろんな技術開発をしていったとて、
あんまり効果を見込めないのかもしれないなというところがあって、
ちょっとその辺のバランスが難しいなと思いながら聞いていました。
touden
そこに関しては個人的には付加価値の付け方以外によってはありだと思っています。
逆に言うとJR貨物が使っているような路線は貨物列車スピード出せないので、
青森側から東日本のと端から端まで青森側から東京側まで運ぼうと思うと結構時間かかると思うんですよね。
しかも特定の便や夜間が主だと思うんですけど、しか使えないみたいな状況。
という中で今回運んだような線魚とか、短ければ短いほど付加価値が上がるようなものとか、
あとはトラックの臨時便で運んでいたような速達みたいなもの、
郵便はちょっといろいろ効果的にあるのでやってないと思いますけど、
みたいなところが付加価値として新幹線で運んでペイできる、
逆に新幹線の速度で運ぶからこそペイできるみたいなものがあるんじゃないかなというところですね。
kokorokagami
なるほどね。
新幹線におけるインフラの難しさ
kokorokagami
はいはいはい。
じゃあ今回写真を見させてもらう限りはあんまり梱包も大きくしてないというか、
本当に人で気軽に運べる程度のサイズで梱包としては小分けにして積み込んでるけれども、
そのへんもその将来像を見せるのは結構リアリティのある大きさで今回試験されてるって感じですね。
touden
そうですね。これはでも貨物販入口の制限がもう限界だと思いますね。
kokorokagami
まあそれは大きいと思うんですけど。
touden
新幹線の通路って狭いじゃないですか。
車内販売しているような人が持っているキャリーっていうか台車みたいなやつ、
あれがもうマックスサイズだと思うんですよ。
kokorokagami
そうですね。
touden
なのでそのサイズで台車に荷物を乗せて席の間に置いているという現状以上には、
現状の設計では無理だと思うんですね。それ以上のことは。
なのでそこに置ける運びやすいサイズ感のあるものしか逆には運べないのではないかという気もしますね。
kokorokagami
まあその辺はね、今おっしゃったような車内販売用のカートを物入れ用に最適化して作り込めば全然効率は上がりそうですけどね。
touden
そうですね。反入ロボットみたいなのができるといいのかもしれないけどどうなんだろうな。
折り返し地点だと清掃の人が入るじゃないですか。
あの間に端っこの1号車は貨物専用にしていて、
あの時間で販入し切れれば普通のホームでもなんとかなる気もせんでもないですけど。
ただそれでも多分ホームからの搬出を考えると1両2両が限界な気はして、うーんって感じもしますね。
kokorokagami
そうですね。理想はちょっとロボコンチックですけど、
人が入る搬入口から各座席のあるエリアに折り曲がるところまでを搬入する装置と、
その各座席のところの足元にこの荷物積んでますけど、その荷物を足元のところに配分していくための装置と2段階構成になっていて、
レールのようにひたすら流し込む人とひたすら左右に避けていく人がいればいいんでしょうね。
touden
そうですね。
やっぱりそこも、そのロボット開発するコストの方が絶対安いか。
だってこれ別のことやろうと思ったら車両の設計か作りなさなあかんから。
非じゃないよな。
kokorokagami
そう、非じゃないと思うな。
touden
確かに。
kokorokagami
新幹線ってあんまり組み替えとかしてるイメージないから、車両の差し替えも結構大変なんじゃないですか。
たまにメンテナンスとかで差し替えてるけど。
touden
まあその規格が合ってれば差し替えもするかもしれへんけど、とは言っても開口部を増やすとか無理じゃない?
kokorokagami
ああ、確かに。
touden
座席取るぐらいじゃない?荷物専用にするにしても。
kokorokagami
そうだと思う。それが限界な気がするな。
あとは構造上の耐久性とかいろんなものに響いてくるから無理ですってなりそう。
touden
そうなると結局難しいところがありますね。
ほどほどにしておかないとさっき言った通りやっぱりペイできる限界もあると思うんで。
今のやり方をちょっと効率化するので運用を始めてみてもいいのかなーって気はしますね。
kokorokagami
あとはワンチャン、ファクトリーチェックに駅に降りたらそこからドローンがバラバラバラと100台ぐらい飛んできて箱を運んでいく。
touden
搬入搬出は置いといてもそうやれば東京駅着でもなんとかなるんじゃないのか?東京駅はでも地下か無理か。
まあいいや。
車両からとっとと出しちゃうまでは効率的にやりたいんですけどそこからはちょっとゆっくりでもまだなんとかなるんで。
まあまあまあそこらへんのやっぱりインフラが難しいですねというところはあると思うので。
kokorokagami
そうですね。駅と称した別の何かができるかもしれないですね。
touden
できるかもしれないですね。東京側は場所もないしなみたいなのもあるし。
東京の場合はちょっとそうですね。
まあというところへんで。これ自体はたぶんJRとしては今後も一回コロナみたいなのが起こる可能性を考えるとやらんわけにもいかんと思うので。
kokorokagami
もちろん。
touden
頑張っていってほしいところですねというところですかね。
kokorokagami
そうですね。先ほどおっしゃってくださった通り2024年問題もあるのでその物流手法の対応化はもう大歓迎でしかないと思うので是非頑張ってほしいですね。
touden
そうですね。
という感じでございます。
kokorokagami
では次いきます。
次世代のWi-Fi7は日本にいつ来る?最大速度の使用はどうなる?ということでインターネットウォッチさんの記事です。
次世代の無線LANとしてWi-Fi7ことiEEE802.11BEに関する情報が出始めてきた。
日本ではようやくWi-Fi6Eが実用可能な状態になったところだが早くも新しいWi-Fiの企画が見えつつある。
いつ登場予定でどのような進化をするのかその実態に迫ってみるという記事です。
これも長いのでまずWi-Fi6との対応表があるのでちょっとそれをベースに話していきます。
Wi-Fi7が目指すのは低遅延の世界ということでWi-Fi7は理論上最大通信速度が46Gbpsとなる企画。
ベースとなる企画はiEEE802.11BEで30Gbpsのスループと遅延・ジッターの改善を目標に企画化が開始された。
Wi-Fi7の新機能と周波数帯域
kokorokagami
Wi-Fiの新企画というと最大通信速度に注目が集まるがWi-Fi7で注目なのは遅延・ジッターの改善だ。
ARVRへの活用、生産ラインや物流での活用などを本格的に視野に入れるためにそもそも遅延が低く、
通信状況によって遅延時間が左右されない安定したネットワークを実現するためにMLOやマルチAP、P2Pトランスミッションなど画期的な技術が投入されている。
とはいえ分かりやすいのは物理層の伝送速度なのでまずはこの点から見ていこうということです。
物理層の違いとして6Eも早々頭に入っている人はなかなかいないと思うんですが、
6Eでは最大通信速度が約10Gbpsというところに対して先ほど言った通り46Gbpsまで増えています。
おおよそ5倍くらいですね。
周波数帯としては2.4Gbps、5Gbps、6Gbpsというのが6Eでしたが、
Wi-Fi7でも同じような周波数帯を使います。
一番特徴的なのが次の帯域幅のところで、チャンネルの帯域幅ですね。
6Eの時では20MHz、40MHz、80MHz、160MHzまでだったんですけれども、ここに320MHzが追加されたというところです。
後から話しますが、この320MHzという大きなレンジが日本の電波利用状況的にボトルネックになっているところがあります。
次の変調方式は1024QAMだったんですけれども、それが4倍の4096QAMになっています。
この変調方式のQAMについては単純に遅れるビット数が増えて、通信速度を改善に寄与しているくらいに思ってもらったらいいんじゃないかなと思います。
ストリーム数が8ストリームから16ストリームになっています。
この辺のストリーム数というのは単純に16ストリームあるから、この16ストリームをうまく分け分けしていい感じにやってくれるかというとそうでもないことも多いので、
Wi-Fiにつながってくる端末の性能とかに引きずられることが多いから、16ストリームという仕様が出てきたからといって単純につながる機器がこの16ストリームの恩恵を受けられるわけではないですけれども、
ポテンシャルとしては倍に増やしたというところです。
マイモは特に変わってなくて、RUはマルチRUになります。
RUというのはリソースユニットというところで、もともとこの返帳方式で複数の端末に通信しようと思った時、
やっていたことは自分勝で、この時間からこの時間はあなたの端末で、この時間からこの時間はこの端末でという形で分けていました。
そこからマルチRUになると複数のリソースユニットがあって、そのユニットをさらにどの端末に割り当てるかというのを付け加えられるということで、
自分勝以外にもユニットごとの割り当てというのも生まれてきました。
これによって生まれることは、自分勝としてしまうとどうしても大きな遅延を生じざるを得なかったところが、低レイテンションにできる余地が生まれるというところですね。
もちろん多接続をやっていくとだんだん結局自分勝になるというのはその通りなので、一概には言えないんですけれども、
そういうポテンシャルを秘めるような技術が追加されました。
あとはこのリソースユニットの分割が可能になったので、特定の周波数が干渉している場合にそこを避けて通信できるようになったということで対障害性も上がっています。
最後がMLO対応というのが6Eにはなかったところで7に追加されています。
MLOは周波数対先ほど言っていたようなチャンネルを複数同時に使用して速度向上したりとか冗長性を持たせたりといったようなことができる技術です。
これによって遠いところにあるものに対しての到達角度を上げたりとか近距離にあるものに対して大容量の通信をしたりということが可能になります。
先ほど言っていた46GBBBSというのは32MHzのチャンネル帯を十分にフルに活用して、かつ編長方式40969AMができる電波受信強度を持ち、
16ストリームを受け付けられる受信端末・送信端末の関係性が取れている上で成り立つというような、そういういろんな条件付きのスペックだというのが今回見えてきたことですね。
このWi-Fi7、今の話だけでもかなり期待が持てるところではあるんですけれども、日本では結構課題があります。
先ほど言っていた320MHz幅というのがちょっと限りになってまして、Wi-Fi7の周波数帯域で320MHzを確保しようとすると、それだけでチャンネルが1個埋まりきってその次が使えないという課題があります。
なので現状の法律とか電波の利用状況のままWi-Fi7を導入しようとするとマルチチャンネルを使えないので、先ほど言っていたようないろんな新機能が活かされず、結果的にWi-Fi6でいいじゃん、みたいな状態になりかねないという現状があります。
この課題についての検討委員会というのはすでに立ち上がっていて、この7月発出か8月最初の検討がいくらだったかなというようなスケジュール感なので、そこでどういうふうなことが決まるかなんですけれども、
いよいよ日本が管理する電波法上の電波利用状況がいろんな風にバラバラになっている状態の再整理とか、その辺の話も踏み込んであるかもしれないなというところで、そうなると社会的にかなりインパクトの大きい話なので、ちょっと注目どころかなという話です。
touden
新技術をドパドパ投入するのはいいけど、現実的にどこまでやり切るかというのは難しいで、やっぱりここら辺は無線の難しいところだねと思っているところですね。
大輝の話でもそうですし、ここら辺の機能を全部盛り上げるのはやっぱり難しいという話だと思うんですよね。
難しいです。
なので一部機能から載せていくんだって話ですけど、携帯のバンドでもプラチナバンドとか言って結局低い周波数を使ったりしているとか、サブ6ギガでちょっとだけ頑張ってみるとか、それでできるところからやっていくみたいな感じが無線では強くて、
kokorokagami
なんだろうな、USBとかパソコン内の規格とかさはザクッと変わるじゃないですか。それに比べてなんと無線の難しいことかという感じがありますね。
Wi-Fi7の新機能と性能向上
kokorokagami
いやーこれもね、さっき半導体の例だったけどこれも半導体臭い話で、半導体のCPU処理速度っていうのが一時期もインテルによってあの手この手でいろんな条件をつけてこれやったらめちゃくちゃ速くなったみたいなのをいろいろ出してきていましたよね、新技術として。
こうすればここまで速くなりますね。あれがあまりにも条件付きすぎて結果的にほとんどの人はその恩恵を受けられないみたいな状態になってたじゃないですか。このWi-Fi7もほぼそういう状態です。今回の話いろいろ言いましたけど、このフル機能が使えるアーキテクチャーっていうのはほぼ存在しない可能性があります。
touden
まあそこはやっぱり難しいですね。なんかUSB3.1とかと同じ感じにもなりそう。そういう意味ではUSBも同じ状況ですけど。要は送信側と受け側とかつ環境という伝送経路が全部対応してないとフルスペック出せません。
kokorokagami
そう、そう。
touden
うーん、そうっすねっていう感じ。まあ分かりますけど。
kokorokagami
なので一般ユーザーはしばらくWi-Fi5でも十分なくらい。6に移行するのも好きものだねって言われても不思議じゃない状態でしたけど、7はもう本当に技術研究目的とかがない限りは買う理由が今のところない気がしますね。
touden
うーん、なるほどね。まあでもさっき言ってたRUでしたっけ?分割するやつ。あれは要は三車線あったら三車線一気に走らせちゃったとか、一車線だけ車走ったらそもそも全部通してなかったものを残り二車線だけ使うみたいな話。
で、そこら辺はまあ結局ぐちゃぐちゃしちゃう無線の電波環境というところに関してはとてもいい使い方だと思うので、制御系が大変なのはもう今言った話じゃないので無視するとして良いんじゃないかなというところがあるので、
ここら辺からだけでもやっていくと多少は繋がりやすくなるのではないかなというところは期待できますね。
kokorokagami
RT-RUは性能速度向上というよりは今おっしゃった通り接続性の安定性に寄与するでしょうね。本当にさっき土地で言いましたけど外部干渉を避けやすくなるので。
逆にちょっと難しいところがこのRT-RUはおそらくアンテナの初期設定からセットアップし直さないと柔軟に動的に変えられるようなものではないと思うので、
RT-RUがかなり静的に設定される気がしているので、どんどん追加した接続台数が増えたり減ったりという柔軟な環境には向かない可能性はありますね。
touden
そこら辺も固定の方がいいのかホッピングした方がいいのかというのはなかなか悩ましいものですよね。
空いてるから使える可能性があるというのは一見いいんですけど、そこで他のが来たから俺やめるわって急に3車線が1車線になってしまうと、
ユーザーから見ると今まで速かったらなぜか時々遅くなるな、使いづらいなみたいな。
結局実行期待値が1車線分しかないのでフルHDの動画を見れへんみたいな。そういう話になってしまうので。
Wi-Fi7の実用性と課題
touden
対応してくれるのは良いんですけど実行値が出ないと聞く意味がないとかいうと、
占有してくれてた今までのやつの方がオラドケドケって入ってきそうなやつをあらかじめはじくということが通信速度安定するかもしれないと。
kokorokagami
そうなんですよね。一般ユーザーは使えるタイミングで速くなったら嬉しいかもしれないですけど、
企業とかが安定性を期待するような導入先ではちょっと使いづらいんですよね。
touden
そこら辺も機能がある分には設定できるパフォーマンスが増えるので、設定できたパフォーマンスが出る可能性が増えるので、
企業様はそこはインフラエンジニアが頑張ってもらおうとして。
あとは個周波帯使えば使うだけ良いと思うので、Wi-Fiに関しては。
高い周波数に移動してもらって。
kokorokagami
そうですね。
電波砲を考えている人たちは頭の痛い課題だと思いますけど、頑張ってもらって。
touden
そうですね。そこも移住が必要なのが機材交換とかハードウェアの問題も大変なのは分かるんですけど、
ここまで何でもかんでも通信するようになってしまうと、一回整理した方がいいというのは分かる話なので、
ちょっと頑張るしかないですねとは思いますけど、20年計画みたいな感じですね。
kokorokagami
そうです。結構先が長いと思います。
touden
はい、そんな感じです。
kokorokagami
以上です。
最後ちょっと長くなりつつあるので巻きでいきます。
ChatGPT公式プラグインコードインタプリターを活用するためのチップス。
ということでKiitaで書かれているOT123という方の記事です。
ChatGPT公式プラグインコードインタプリターがついに日本でも使えるようになったので、自ら検証したチップスをまとめます。
このコードインタプリターとは何かなんですけれども、
ChatGPTが提供する公式プラグインの一つで、このプラグインを利用することでChatGPT上でPythonを使ったコードの実行やファイルのアップロード、ダウンロードができるようになります。
ファイルのアップロード機能を使うことでチャット上にデータをアップロードし、そのデータに対してコードを実行することができるようになります。
また作業の結果をCSVなどでダウンロードすることが可能です。
ChatGPTの新プラグイン
kokorokagami
つまりコードインタプリターのプラグインを使うことでChatGPT上でのPythonコードを実行したりファイルのエリトリを行うことができるようになり、今まで以上にChatGPTが便利になるということです。
ここの通りなんですけれども、ChatGPTの新しいプラグイン、公式プラグインでかなりのブレイクスルーだと話題にはなっているものです。
以前に似たようなプラグインはあったので、私的にはそういったもともとあったものが公式に組み込まれたなというところではあるんですけれども、
実際に使ってみたという話は非常に感触の良いものばかりになっているので、ぜひ体験してみてもらいたいところですね。
どういうユースケースが考えられるかという話でいくつか話題を挙げると、
よくCSVやExcelファイルを読み込ませてデータを解析した結果を見たいということがあります。
普段もっとPythonのプログラムを使っていない人で言っても、Excelを開いて何かデータが入っているのでそのデータをグラフ化したりとか、
関数を作って別の列を追加したりとか、そんなことをいろいろやっていたと思います。
そういったときに考えていることはプログラミングとほぼ同じで、決まったデータ入力に対して何か処理系があって出力があるというプログラミングの概念になります。
そのプログラミング自体をChat GPT上で実行できるようになったので、より効率化できるようになりましたという話ですね。
どの辺がChat GPT上で動いて嬉しいのかという話なんですけれども、
このChat GPTは自然言語処理ができるようになっているので、やりたいことを自然言語で入力して動かせる。
プログラムの入力データとしてこれをこうしてほしいとか、こんな処理をしてほしいとか、そういったことを言いつつ実行させることによって、
ある意味ノーコード的な開発体験ができるというのが面白いところですね。
ただこれを正しく運用できるのは今のところおそらくPythonのコードが読めるプログラマーのみであろうとは思うんですけれども、
実際にそういったノーコード開発環境としての実用性が高いので非常に関心が高まっているという状態ですかね。
touden
そうですね、ますます使いやすくなっていくのは良いなという感じですけど、行き着く先がなかなか難しいなと思っていて、
Chat GPTがインターフェースとして機能する段階にはなってきている。
というのは良いんですけど、どうなんでしょう。
これ見てるとやっぱりある程度時間が経つとデータが消えちゃうみたいな話とかあるんで、
これをコンパイルとして見た時に再現性がないのどうするのっていうのはちょっと思ってるんですけど、どうなんですかそこらへん。
kokorokagami
ないと思いますよ。
touden
別にそれでいいですか。
kokorokagami
これの成果物をどう使いたいかじゃないですかね。
touden
なるほど。
kokorokagami
例えばエクセルでグラフ化するというフローを考えた時に、
自分がその中身のデータの過読性を上げたいからパッと中身を確認したいという目的でやる時と、
そのデータをちゃんとまとめて報告しなければならないという時にまとめるのとで、
レベル感が違うじゃないですか。
前者だったらチャットGPTに任せて後者は前者のチャットGPTがやったことを真似しながら自分でやるっていいんじゃないですかね。
touden
なるほどね。
というかチャットGPTにVBやら何やらのソースを履き出してもらえばいいと。
そうそうそう。
kokorokagami
上手くできたんだったらそれを実際のVBのコードで出力してくださいってチャットGPTにお願いして出してもらって、
それを自分でこねこね直せばいいんじゃないですかね。
touden
そう考えるとインターフェースとしてはこれで十分なわけか。
kokorokagami
そうです。あくまでその再現性も含めて最大でも8割程度の角度のアウトプットしか得られないという大前提は崩してはいけないですね。
touden
はいはい。なるほどね。
まあそう考えるととてもいいですねというお話ですね。
kokorokagami
そうですね。体験は非常に楽しいんじゃないですかね。
touden
あとはこれがそうですね。プラグイン化したのをどこまでみんなが使いやすくするかっていうところがキマなんですかね。
やってることはもう完璧に100億満点みたいな感じなので。
kokorokagami
そうですね。ちょっとこの辺は正直どういう方向性で落ち着くかはわからないので、とりあえず出してみてるっていうのが正直なところだと思います。
GitHub Copilotっていうコーディングをしながら書くべきコードを支援してくれるものもありますし、
このChatGPTのように必要なものを書いてくれるものもあります。
やってる人はChatGPTに書いてもらったコードをそのGitHub Copilotにデバッグしてもらってテストコード書いてもらってみたいな形で全自動みたいなことやってますけど、
どのタイミングで人が介入してそれを検証して精度を高いものにして品質を仕事としてOKにして次に進むのかっていう話がついてもあるので、
そのフェーズがどういう単位で切り分けられていて、私たちはそれをどう使えるとうれしいのかということになってくるんだと思うんですけど、
今まであまりにも手で実装してというフェーズとかプロセスの構築しかやってこなかったものだから、こういったChatGPTやCopilotがあるときに私たちとしてどういうプロセスだったりとかチェックフローをどのタイミングで入れるとプロセスを回す上で効果的なのかっていうのがまだ分かってないから、
一旦このレベルで出してみて、どう人々が使うのかっていうのを見てるっていうのが正直なところなんじゃないですかね。
touden
なるほどね。
ChatGPTの利用範囲の拡大
touden
それは言われるとそうかもしれないなという気がしますけど、どうなんですか?使った側の印象としては。
kokorokagami
使った側の印象としては、商品開発のフェーズに合わせられればベストかなという感じ。商品開発のフェーズというか事業のフェーズかな。
最初のPOC段階ではもう結果さえ良ければ週間成果物については目をつぶるというつもりでChatGPTやCopilotに全部やらせる。
で、POCで価値が生まれそうだとなったら初めてそこから成果物に対しての検証を始める。
POCか商品化フェーズでそもそもこの技術がどういうものでみたいなのを整理し直すフェーズがやってくると思うんですけど、それと同じようななぞり方をするのがいいのかなというのが私の肌感ですけど。
touden
まあ確かにそれはそんな気はする。逆にPOCのレベルでChatGPTに任せるという方針が決まると無駄にコストをかけることもなくなるんで、結果として回転数も速くなりそうな気がするし。
ざっくり感がいけそうみたいな感じが出れれば関係閣議の合意というかご判断しやすくなると思うので。
まあ確かにそういう意味でいうと非常に強力、その段階において非常に強力だと思うので良さげな気がしますね確かに。
kokorokagami
そうですね。そうなってくるとですね、私が想像するにですけれども、そのChatGPTを使う主体者はプログラマーではなくなるでしょうね。
企画や営業の人が顧客の要望を噛み砕いて日本語で入力すればPOCができるという事実なので。
プログラマーに発注する必要性がないです。
限界はもちろんあると思うんですけど、いわゆる今ホームページとかを開発する上でデザイナーの人がある程度ウェブページの開発もできますよというのが当たり前になりつつあるじゃないですか。
ウェブページの開発技術やプラットフォーム、フレームワークがすごく便利になったおかげで。
と同じようなことが起きるんじゃないかなと思っています。
touden
なるほどね。
kokorokagami
エンジニアの人に次発注するフェーズでチャットGPTはこんな風なことを言ってこんなことをやってるんだけどということを言って、
チャットGPTがプログラムに翻訳することでエンジニアに対するインプット、要件定義がより具体的で伝わりやすいものに変わっていく。
コミュニケーションインターフェースとしてチャットGPTのやり取りをエクスポートして渡すみたいな時代も来るのかなという気はしてますね。
はいはい。確かにそれは来そうな気はしますけど、結局なんだろう、まあでもいいのか。
touden
その特定の人に技能が集中する感じがすごいなぁと思いますね。
それは単価が高くなるのか安くなるのか。まあ安くなるのかな、人を買いさない分。
安くはなるんじゃないですかね。
なる気はするけど、なかなか大変ですねそれはそれで。
そうですね。そこはもう多分お互いの食い合いというか競合になったなというだけの話で、
エンジニアが従来の仕事をもらい続けようと思ったら、ある程度営業さんの言っている言葉をロジック的に解釈できる自然言語に噛み砕くというのを自分たちのスキルに変えて、
同じようなレベル感で踏み込んでいくっていうスタイルを取れば、エンジニアの仕事であり続けるでしょうし。
それができる営業さんや企画の人であれば自らそれをやっちゃえばいい。
なるほどね。
kokorokagami
どっちかがやるかで、商品化フェーズに移行した時の立ち上がりの速度とかに差があるから、
ChatGPTの応用可能性
kokorokagami
エンジニアらしさが良いとかはちょっと会社ごとのノウハウで生まれてくるかもしれないですけどね。
touden
そのレベルの話は会社ごとのカラーでいいと思うので。
kokorokagami
そうですね。
touden
純粋なプログラマー職が開始するという余地が非常に少なくなるというところは確かにそうだと思いますね。
全体のフローから見るとそれでいいかなという気がしますね。
確かにあまり人を介しても回転数とか情報鮮度が下がって結果として良いものが出ないとかあると思うので。
業界的に良くなることが一つあってですね。
kokorokagami
POCで作ったものに対するもったいない精神が減るという良いことがあってですね。
ものすごくよくあるんですけど、
POCをできる最新技術に詳しい人がパパパッと作ったものっていうのが商品化フェーズで
開発技術能力の必要なスキルセットが限られているせいで開発体制をスケールできないという課題と、
そもそも選んだ技術の選定ミスで技術制約が生じてしまって期待する商品を作れないという問題がたびたび発生するわけじゃないですか。
そうなった時にPOCをリファクタリングして全部作って、
なんでそんな風に作ったんだみたいな対策会議会が設けられることが世の中5万とあるわけですけど、
その時にチャットGPで作らせていれば気軽に捨てられるので、
だいぶその無駄なコストがなくなるんじゃないかなという期待感がありますね。
そうですね。
touden
結果としてチャットGPの生成物、POCに対する動作POCみたいなものがあるんじゃないかなと思っています。
そういうのもあるんじゃないかなと思っています。
そういうのもあるんじゃないかなと思っています。
その方がいいか。
その方がいいですね、確かに。
結果としてチャットGPの生成物、POCに対する動作POCみたいな感じになりそうかなと一瞬思ったんですけど、
でもいいものが出ればいいねってなると思うので、そういう意味ではありなんじゃないかと思いました。
kokorokagami
ということで今後もチャットGPTの動向は目が離せないですけれども、
GitTrainingの紹介
kokorokagami
1つ話題になっているGitTrainingの紹介でした。
今日はこんなところですかね。
touden
本日の内容はショートにまとめていますのでご確認ください。
本番組はPodcast, Spotify, YouTube, Live, Listenで聴くことができます。
ぜひ視聴者でもサブスクライブよろしくお願いいたします。
お疲れ様でした。
kokorokagami
お疲れ様でした。
