1. Recalog
  2. 145. 2022/12/04 ワールドカッ..

枕. ワールドカップ 日本vsスペイン ()

1. AWS Systems Manager Incident Manager ()

2. mocopi ()

3. Team on Air ()

4. ChatGPT ()

5. SeeMaaS ()

6. コオロギ給食 ()


こちらでも配信しています

ご意見、ご感想

編集

@Touden氏
最大限の感謝を

BGM

騒音のない世界 beco様より
OP:オオカミ少年
本編:蜃気楼

免責

本ラジオはあくまで個人の見解であり現実のいかなる団体を代表するものではありません
ご理解頂ますようよろしくおねがいします

00:00
Speaker 1
はいどうも、kokorokagamiです。 東電です。
今週も1週間振り返っていきたいと思います。 はいはい。
Speaker 2
今週は日本代表がやりましたね、みたいなNHKニュースっぽい配信をしたいですけど。
Speaker 1
はい。いやー、ワールドカップ、スペイン戦ですね。はい。
Speaker 2
うん、めちゃくちゃすごかったですね。
Speaker 1
まあこれも、ドイツ戦もそうだったんですけど、なかなかスペインも優勝経験がある国なんで、
まあまず難しいでしょうという下馬評だったんですが、見事に逆転勝利ですね。
Speaker 2
そうですね。かなり試合運びも日本が主導権握ってるかのように見えるような、かなりすごい理想の試合というか、
展開だったのかなと思いながら見てましたけど。
Speaker 1
そうですね。前半で1点取られたものも我慢して、1点で抑えておいて、後半またドイツ戦と同じように、
人変えてから攻めて攻めて、2点取り返すっていう感じでしたね。
Speaker 2
はい。そうですね。で、点取れたらもう後は我慢でひたすら守るという。
Speaker 1
そうですね。
Speaker 2
スペイン相手にもその選手交代直後で、日本の動きがまだ読み切れないという中で一気に畳みかけたという感じがして、戦略勝ち感がすごかったですね。
Speaker 1
そうですね。なんかドイツ戦もそうでしたけど、なんだろう、カウンターというか、厳しくなってからっていうのは何なんですかね。
厳しくなってから攻める戦法っていうんですか。
Speaker 2
逆に普通に試合運びして戦う、スペインとかドイツがやってたようなプレイスタイルで正面からぶつかり合うでは、やはりその自力の差というか、
もともと下馬評通りの実力差があってしまうので、それとは違う領域で特化して戦いたいっていう思いがあるんだろうなと思ってて、
それが格上に対する戦略一本みたいなところだったんで、ドイツスペインにはすごく刺さったけど、
こっさりかい相手はやっぱり試合運び的にもお互いカウンターを狙い合うみたいなところで、
日本としては結構攻撃も何回か機会あったんですけど、攻めあくねて結果的に負けてしまったという形なので、
ある意味その格上、相手に行けるところまで行こう、その戦略で勝ち進んでいこうっていうのをみんなで合意して、ひたすらそれに特化してやったんだなという感じですね。
Speaker 1
たしかにカウンター特化デッキっていう話ですね。
Speaker 2
そうですね、そうですね。それはね、言うのは安いですけど、
03:02
Speaker 1
ちゃんとやり切って勝ってますからね。
Speaker 2
実力が上の相手だとカウンターと言ってもだいたいノーチャンスなことが多いし、
そのチャンスも物に仕切るのには何段も越えなきゃいけないハードルがもちろんいっぱいあって、
それをやり切ったということをしたより非常に素晴らしいなと思いますね。
素晴らしいですね。
Speaker 1
あと面白かったのがあれですね、
Speaker 2
今回裏でドイツVSコスタリカ戦もやっていて、
Speaker 1
時間によってはこっちが前半負けて後半盛り返してってなって、
Speaker 2
向こうも同じような試合運びをしていて、
Speaker 1
で、勝ち点数と当得点の関係上どこの国も時間によっては決勝に進出できる可能性があったという中で、
かなり実況の人も向こうも気にしつつで話してて面白かったですね。
Speaker 2
そうですね。
一時期日本一、コスタリカ二位というタイミングがあったんですよね。
Speaker 1
それになったらもうオーバンクルアでもいいところでしたけど。
ですね、はい。
で、裏のドイツ戦も私一通り見たんですけど、
Speaker 2
ちょうど日本が逆転したところで会場がめちゃくちゃドヨメイていて。
Speaker 1
で、実況の人も日本人なんで、日本を気になって仕方がないという感じで。
Speaker 2
はいはいはいはい。
Speaker 1
そうですね。リアルタイムでやってると別会場のことも入ってくるんでね、スマートフォンとかでみんなで見てて。
Speaker 2
会場のスクリーンも出てたみたいですしね。
Speaker 1
そうですね。そこら辺も考えるとなかなか選手も難しいなという感じですね。
Speaker 2
いや、気にしてる余裕ないとは思うんだけど。
Speaker 1
まあでもドイツは初っ端だと単純に勝ってればよかったんですけど、
日本が得点逆転しちゃったんで、そうするとスペインよりもゴール数を取らないといけなくなって一気にきつくなったっていう。
Speaker 2
そうですね。
Speaker 1
そういうところがあって、ガンガン攻めないといけなかったとかいうところも、なかなか戦略として難しいなというところでしたね。
Speaker 2
そうですね。そこに来て、スペイン対コスタリカの0対7っていうのが一気に厳しくなっちゃった。
はい、めちゃくちゃ効いてて、はい。
いやー本当、このグループEはかなり波乱万丈があって、
まあ、選手たちには申し訳ないですけど、見てる側としてはすごくエンターテインメント性の高いグループだったなと思いますね。
Speaker 1
まあそうですね、はい。面白かったですね。普段ちょっとサッカーとかあまり見てなかったんですけども、
同じく思う。
すごく面白かったんで、ちょっと今後も持ってきたいなという感じですね。
06:03
Speaker 2
そうですね。私も全然最新のサッカーのアップデートができてなかったんですけど、
まあだいぶ前に見た、もうそれこそ学生時代とかに見た時の日本代表のチームがこういう格上と当たった時はかなりいいようにされていた。
日本のミスを疲れて疲れて、で、なんとかボール持ったとしても何もできずに終わってみたいな、そういうワンサイドゲームみたいな印象も強かったので、
今回スペイン戦とかマトリス戦もそうですけど、見て戦略を組んで、まあその戦略が刺さってるっていうのももちろんあるんだと思いますけど、
ある程度対等にプレーできてるなって思わせる試合だったんで、非常になんか日本のサッカーやるやんという気分にめっちゃさせられましたね。
Speaker 1
そうですね。そこら辺も本当に選手もそうですし、監督も、ようやりきりましたねというところが素晴らしいですね。
Speaker 2
そうですね。テクノロジー的にはサッカーボールがIoTになってて、まあそのラインを越えたかとかゴールに入ったかどうかを判定する自身で判定できる仕掛けがあったりとか、
外部の判定ルームみたいなところがあって、画像解析やVAR等々で、その場で審判のジャッジに依存しない形で正しい判定をすぐ出せるというバックグラウンド、バックボーンが用意されているのは素晴らしいかなと思いますね。
Speaker 1
そうですね。そこら辺もやっぱり審判もなかなか難しい判断を強いられるところで、特に今回の日本の2点目とか、かなりギリギリでボールの90%が線の外に出ているような状況。
だけどギリギリ入ってたっていう判定をちゃんとこうビデオで確認して、で得点しましたっていうことになったんで、やっぱり画像があると説得力があるんでね、そこら辺、いい判定になったんじゃないかなというところですね。
Speaker 2
そうですね。これがね、服審1人の話とかで依存してたら、もう世界中から叩かれちゃうんでね、その服審とか。
難しい、難しいですね。ほんまかーってずっとなりますからね。
Speaker 1
あの審判、なんかね、日本側に肩入れしてたんじゃないかとか、絶対言われ続けちゃいますからね。
まあそこら辺、客観的になりやすい結論を出しやすいので、とても良かったんじゃないかなというところですね。
Speaker 2
はい。で、次が決勝トーナメントで1戦目がクロアチュアでしょ?
クロアチュアかな? うん。
いつでしたっけ、次。
Speaker 1
えっと、火曜日のゼロ時。火曜日のゼロ時なんで、月曜の深夜かな。
09:03
Speaker 2
はいはいはいはい。いやー、これはまた視聴率がガンと上がりそうな感じですね。
Speaker 1
そうですね。まあ比較的早めなので、はい。
Speaker 2
アメバTVさんの方では、ちょっとあまりに視聴者数が増えすぎそうということで、入場規制というか、あの、見れる人数に限りが設けられそうなので、
ああ、そういう感じなんですか。 頑張って入ってください。
はい。まあさすがに、日本国民の注目が集まりすぎているので、サーバーが持たないという問題ですね。
Speaker 1
確かにちょっとトラフィック見てる人もいましたけど、なんか、えっと、普段過去に1週間に比べて、このワールドカップの時間帯だけ2TBパーセックぐらい。
Speaker 2
すごいな。
Speaker 1
トラフィック増えてるらしくて、アメバさんで。
Speaker 2
なるほど。
Speaker 1
かなり、かなりですね。まあそこら辺はもう、放送よりもまあ、インターネットの限界というところもあると思いますんで、はい。
そうですね。アメバTVさんもそんなに収益上げてるところじゃなかったと思うので、結構赤字続きというか、最近ちょっとようやく黒字のめどが立ち始めたかもぐらいのニュースだった気がするので。
Speaker 2
せっかくこうやって視聴率を集めたコンテンツがアメバTVさんのおかげでっていう体験を得た人も多いと思うので、これを機にちゃんとマネタイズして、一大配信サイトになっていってくれるといいなと思いますね。
Speaker 1
そうですね。やっぱりテレビがないご家庭もあると思いますんで、そういうところでね、一緒に応援できるっていうのがいいと思うんでね。
Speaker 2
夜中だとやっぱり見逃し配信が大事になってくると思うんですけど、見逃し配信に対してアクセスがクソほど早かったんで、その辺もプラットフォームとしてありがたかったですね、アメバTVさんは。
Speaker 1
そうですね。
Speaker 2
はい。というところで、今日の本題いきたいと思います。
Speaker 1
はい。
Speaker 2
1点目、AWS Systems Manager Instant ManagerというAWSの新しい機能がリリースされたので、その紹介です。
もう完全にAWSの回し物みたいな紹介になっちゃいますけど、先週というか今週かな、12月2日までReinventっていうAWSの大規模なイベントがありました。
このイベント自体は毎年行われているAWSのイベントで、新しい機能だったりとかサービスのリリースがいろいろ発表されるタイミングですと。
普段もかなりアップデートの話が毎週ニュースとして出てきてはいるんですけど、このReinventではさらに特徴的な大体的な大型サービスのリリースだったりとか、
12:12
Speaker 2
今後1年かけてこんなものを提供していきますよっていう発表だったりとか、そういったイベントになっています。
なので登場していきたい各サービスはどれも面白いんですけれども、その中でも結構課題としてはあったけどどこもやってこなかったなっていう面白いサービスが出てきたので、その紹介をしたいなと思います。
インシデントマネージャーは名前の通りではあるんですけど、いわゆるインシデントが起きたときの後のプロセスをサービス化しているものですと。
どういうことかというと、インシデントが起きたということをまず発見するというフェーズにおいては、これまでも製品というかサービスがあって、
あるアプリケーションの敷地を超えたですとか、あるアプリケーションのサーバーがダウンしてしまったですとか、そういった何かしらのきっかけを捕まえて、
管理者に通知をするということは今までもできていましたと。ただ、実際にインシデントを対応するというのはむしろその後からが大変で、
その通知の中身から原因を特定し、原因がどの担当者が一番よく分かっているのかとか、
その影響範囲を捕まえて、どれくらいのマネージャーやレベル感までエスカレーションし、すぐにインシデント対応チームをどれだけの規模で組まなければならないのかとか、
その辺の采配をいかに早く立ち上げてアクションを起こすかが非常に重要になってくるわけですけど、
それっていうのはかなり各会社のノウハウになってたりとか、社内のエスカレーションルール、いわゆる工場現場とかだと、
ぼやが出たときのどの規模だったら誰に報告しますかみたいなツリー図を書いたりすると思うんですけど、
ああいったレベルでしか管理できてなくて、実際にインシデントが起きたときのプラットフォームというのはかなりメールとかチャットベースに依存していて、
非常に煩雑になってましたと。
その辺のプラットフォームが揃ってないところで、実際の顧客に対してこんなことがありましたっていう説明するのが遅れたりとか、
アクション自体が間違ってたり遠回りをしてしまうってこともよくありましたということで、
このインシデントマネージャーはそういったサポート体制、インシデントが発生した後の解決するためのチームプラットフォームを即座に構築できるサービスですと。
具体的にはイベントが発生した、インシデントが発生したら、
15:02
Speaker 2
まずSNSとか電話等々を返して対応者、関係してそうな人を呼び出して、一つのチャットルームを作りますと。
チャットボットが立ち上がって今何が起きてますかっていうのをチャットボット相手に聞きながら、
AWS側の情報を引き出してきますと。
その中でチャットボットにはそのAWS側の情報を引き出すだけじゃなくて、こういう時にはどうするべきかっていう事前に決めたルールに基づいて、
この時にはこういう人に呼んでもらいましょうとかいうことがチャットボットを通じて分かるようにしてあって、
それによって上のマネージャーをさらに新しくメンバーとして呼び出したりとか、そういったこともできるようになりますと。
その後、呼び出したチームの中でこの対策を実行しましょうというのが決まったら、その対策を実行していくわけですが、
その対策自体も事前に用意しておいて、この集めたチャットルームの中からチャットボット経由でアクションを実行したりといったこともできますし、
そのアクションを実行した後、何をチェックしてOKとするのかっていうところの指標も設定したりすることができるということで、
そのインシデント発生から解決までの間を助けるサービスになりますと。
これは新しくリリースされたばかりなので、実際各会社が実行しようとしているインシデント対策とどこまでマッチしていくかっていうのは、
使ってみないと正直分からないところはありますけど、あんまり誰もやってこなかった領域のサービスかなということで面白かったので紹介です。
Speaker 1
聞く限りすごく良さそうですねという感じですけど、最後の一行に主役されるかなというところですね。
確かにいざ何かあった時への対応っていうのは各社のノウハウでしか多分なかったところで、そこが共通インフラ化というか、
インフラ化することでやっぱり社内の標準化にもつながりますし非常に良いのかなというところはプラスポイントだなと思いますね。
結局先ほど心岡神さんが言われてましたけど、実際にどこまで使えるのかなっていうのが疑問点ですね。
やっぱり今までやってた社内の承認フローみたいなところに載せれないとそれはそれで困りますし。
そこに対してカスタマイズできると本当はいいんですけど、あんまりカスタマイズ性を高めても今度は使いづらいと思うんで、そこら辺のバランスをどう取るのかなっていうところですね。
Speaker 2
おっしゃる通りかなと思ってて、おそらくレポートラインとワークフローはすでにある程度社内システムとして存在してしまうと思うんですよ。
18:09
Speaker 2
それはメールだったりとかその決済ワークフローシステムみたいなやつだったりとか、なんかそういうちょっと社内のシステムを間にかましたプロセス形態になってるというのはよくあるので、
そことシームレスに連携できるかといったら連携できないですし、よくあるのがこういう対策って何をやったのかっていうのをちゃんとまとめて保管しときましょうみたいなルールがあったりすると思うんですよ。
で、AWS上でこれだけ支援されちゃうとその結果っていうのはAWS側にしか残らないので、社内資産としてどうやって残していくのかみたいな話もなったりして、結局メールとかのほうがエビデンス残っていいよねみたいになりがち。
Speaker 1
まあまあ確かにね、なんか情報がばらけちゃうのはよろしくないですねという。
Speaker 2
あ、そうそうそう。だから本当にレガシーなところだと、メールにレスをつける形で解決まで全部やり切る。
それを一式まとめてエビデンスにしましょうみたいなことやってる組織もあると思うんですよ。
うん。なんでそういうところと合わせようとするとなかなか限界があるなーっていうところで。
どこまでの範囲をじゃあこのインシデントマネージャーでやって、どこからは無理だっていう線引きをするのか、その線引きも判断がやっぱり難しいって言うんだったらやっぱり使わんとこってなっちゃうのかとかもあるんですけど。
Speaker 1
使わんとこってなるのももったいないんで。
そうなんですね。
なんかこう、プロジェクトとか部署レベルではやはり使った方が回転数が上がるとか収束率が上がると思うので。
まあそこはそこで使っておいて、その前者的な展開するときには旧型インフラに乗っける感じでもいいのかなというところはあるんじゃないですか。
なのでそこのインターフェースが結合できるようであれば万々歳ですし、できなくても炎上を消化する時間が早くなれば回転数は上がると思うので有効かなというところに落ち着くのかなと思います。
Speaker 2
そうですね。
なので多分AWSを詳しい社内メンバーはこれぜひ使いましょうって言って頑張って押し進めて、結局その社内のシステムとシームレスに連携させるためにこれもスラックとかと連携できるみたいなんですが、
そういったところと連携した上でスラックからさらに別のインターフェースに加わってメールに返るとかチームツーにするとか、そういう何段階かを経てどうするシステムを作ったりするんだろうなあと思います。
Speaker 1
そうですね。そこら辺が現実界かなというところですね。
Speaker 2
はい。ちょっとこういうサービスもあるんだなということで紹介でした。
21:01
Speaker 1
次、私の方から。
ソニー小型センサーとスマホでモーションキャプチャー。
モコピ約5万円というAVウォッチさんの記事です。
ソニーは6つの小型センサーを専用バンドで付けるだけで気軽にモーションキャプチャーできるモコピを2023年1月下旬にソニーの直販サイトソニーストアで販売する。
価格は49,500円。発売先駆け12月中旬より予約受付を開始する。
センサーとスマホアプリだけで手軽に全身の動きをトラッキングできるモバイルモーションキャプチャー。
ソニーの独自のアリゴリズムによりカメラやスタジオなどを必要とせず、6つのセンサーのみで全身のモーション注力が行える。
室内のほか屋外でも利用可能で、外ロケ動画を作るなどユーザーの活動の幅が広げられるとする。
キャリブレーションはスマートフォンアプリで行い、センサー装着後に身長を入力。
スマホアプリの指示に従って気をつけぬ姿勢と一歩踏み出す動作だけで完了。
T字ポーズなども行わずにスムーズに利用できる状態になる。
スマホアプリだけで3Dキャラクターに動きをつけた動画を作れるほか、外部ソフトウェアとの連携もサポート。
VRChatに対応したヘッドマウントディスプレイと連携すればアバターを操作できるほか、PCと接続して3Dキャラの動画データを使った動画配信も行える。
VRMファイルに対応。自作のアバターやフリー素材の3Dキャラクターなどもスマホアプリにインポートして利用できる。
スマホアプリにはオリジナルキャラクターのレイノスちゃんがプリインストールされており、そのまま利用可能となっているほか、レイノスちゃんはSDKの一部としても公開するという。
スマホのマイクを使った音声認識でリップシンクが行える。なお、フィンガートラッキングやフェイストラッキングは単体では行えないため、外部サービスとの連携が必要になる。
発売時点で連携可能な動作確認済みのサービスは、RealChat、Unity、Motion Blur、Virtual Motion Capture、また、Metaverse向けサービスや3D開発ソフトウェアと連携するSDKを12月15日より提供開始し、新たなサービス開発に貢献するとしている。
対応のスマートフォンがXperia 1 II以降なので、大体2020年以降発売のXperiaシリーズと、あと2020年以降、12以降のiPhoneが対応しています。
対応OSはAndroid 11以降、iOS 15.7.1以降。
24:00
Speaker 1
センサー1個あたりの外径寸法重量は32×11.6mmで、重量は8g。3度風の間速度センサーと角速度センサーが備えられている。
通信方式はBluetooth5.2、最大使用時間は10時間、充電時間は約1.5時間で、完全ワイヤレスイヤホンの模様に充電ケースに入れて充電する。
ケースの充電端子はUSB-C。
その他、IP6568相当の防塵防水に対応。
ヘッドバンド、リストバンド、アークルバンドのクリップなどが付属するという感じです。
写真見てもらうとわかるんですけど、めちゃくちゃ小さくて軽いモーションキャプチャー、しかもフルトラッキングができるものをソニーが発売しましたということで、
500円玉台よりはちょっと大きいんですけど、
指先で丸を作ったぐらいのサイズ感ぐらいで、バンドを使って頭と手首、足首、あと腰に取り付けます。
先ほども言った通り、スマホと連携することで非常に簡単に全身のトラッキングができて、
しかもSDKとかが各々対応しているので、VRチャットとかでも使うことができるという感じで、
非常に使いやすそうで、拡張性もありやすそうで、完璧がこれはというような商品をソニーが出してきたので紹介というところです。
Speaker 2
控えめに言って神ですよね。
Speaker 1
そうですね。
Speaker 2
神以上ではあると思うんですけど、それ未満では絶対ない素晴らしいサービスっていうか製品ですね。
もう本当に何の文句もないというか、これをみんな待ってたと言わざるを得ない感じのもので、
これはそうですね、いろんな周辺環境に対しても考え方を変えさせるレベルのものだなと思ってて、
フルトラッキングをするために必要な環境とはこうだという常識も変わるし、
自撮りとかあんまり写真にこだわっていないスマートフォンユーザーのスマホに対しての価値向上にもなってるし、
いろんな今の時代だからできた技術をちょうどピンポイントで合わせ込んできた。
メタバースの盛り上がりっていうのがまだ下がりきってない状態の中で間に合わせたっていうこともすごいし、
価格帯もめちゃくちゃ高いわけじゃない。
ソニーさんがこういうの出してくるときって大体10万越えが当たり前かなとか思ってたんですけど、
一応5万円で抑えてあるっていうところも含めて最強化っていう感じですね。
27:05
Speaker 1
本当にスマホと連携することに限定したっていうのがミソだとは思うんですけれど、
Bluetoothで接続することで非常に安価なセンサーになってると。
今こういうモーションキャプチャーするのでやりやすいので言うとViveのトラッカーとか言うんですけど、
そもそもViveのヘッドマウントディスプレイをつけた上で腕とか足とかに無理やりくっつける、
これよりでかい手の平台のセンサーみたいなところがあって、
それはセンサー1個だけで2万円ぐらいするものなんですよね。
6個買うと12万ぐらいかかっちゃうんですけど、
それに対して価格が5万円と非常に安価な上に小さく、
キャリブレーションも楽というところでこれだけでも非常に楽になる上に、
これは単体で完結してるんでヘッドマウントディスプレイをつけなくてもキャプチャーができるというところで、
VRとかはしたくないけどキャプチャーしたいとか激しい動き、
プレスの画像でもありますけど、ダンスとかですね。
というときでもきれいにキャプチャーができるというところで、
非常に拡張性が高いというところ素晴らしいと思います。
Speaker 2
この話聞いてるとエッジコンピューティングっていう言葉に対するキラーコンテンツ感もあって、
スマートフォンでいろんなアプリが組み込めます、外部デバイスと連携しますっていう話って今までも山のようにありましたけど、
別にスマホじゃなくてよくねっていう話かなり多かった認識なんですよ。
それをわざわざPCとつなげたら別にPCでウェブカメラ買ってくりゃいいじゃんっていう大体機器もいっぱいあったっていうのが多かった中で、
これはスマートフォンでないとできないっていう領域まで踏み込んでると思ってて、
そのPCの外部インターフェースとして完全にスマートフォンが今までできてなかったことを拡張する追加のインターフェースになってる。
と思わせるくらいのキラーコンテンツになってるので、
正直SIMの契約とかなしに単純にこういうVR環境の設備の一つとしてスマートフォンを購入するっていう、
そういうモチベーションも出てきそうなレベルかなと思ってますね。
Speaker 1
そうですね。ここら辺スマートフォンをソニーさんが作ってたんで、そこに載せてきたのは上手いなというところで、
確かにぶっちゃけ頑張ればPCでも対応できなくはなかったとは思うんですよね。
30:06
Speaker 1
ただBluetoothを使う関係上センサーも6個ありますし、そこら辺の連携を考えるとハードウェアは固定した方が良くて、そこにスマートフォンを載せてきてる。
あとスマートフォンのマイクを使った音声認識とかも結合性が良いというところで、かなり上手いことを仕上げてるなという雰囲気はありますね。
スマートフォンも価値も上がるし。
Speaker 2
ソニーさんには申し訳ないけど、iPhoneとAirPodsでやるかなと思ってますけど。
Speaker 1
まあそれでも良いんじゃないですか。手持ちで端末使えれば良いし、なければXperiaのiPhone1-2くらいかな。
今中古で見ると5万くらいで買えるんで。コミコミでも10万の設備。全然そんなに高いわけではないですからね。
Speaker 2
そうですね。
Speaker 1
素晴らしいなというところで。
Speaker 2
本当に専用機として買ったら良いと思いますね。
全然そんなに。
普段使いのスマートフォンとは全く別物として用意したら良いと思ってて。
なんならウェブカメラの代わりとしてスマートフォン台とかをディスプレイの上とかに置いて、
普段のZoomとかのウェブ会議とかもスマートフォンのカメラでやるっていうようにプリセット乗せ替えていっても良いレベルかなっていう感覚もすらありますね。
Speaker 1
それはやっぱりあると思ってて、フェイストラッキングする系のアプリケーションはやっぱりiPhoneで載せてるところも結構あると思うんですよね。
それこそバーチャルYouTuberさんとかで。
そことの親和性も高いんで、SDK公開してもらってればそこに組み込ませて、スマートフォン側で完結すると。
今までより顔だけだったのが全身トラッキングが、しかも精度良く捉えられる。
中間インターフェースとしても非常に優秀なので、拡張性もありますし、是非ともみんな使って欲しいなという感じ。
Speaker 2
そうですね。あとは、引っ越して部屋を広くするだけだな。
Speaker 1
別に外でやってもいいんですよ。
そうなんですけどね。この配信に乗っけて、この今クラスター側で公開して、ここに乗っけようと思うと、PCの場合は必須なので。
Speaker 2
そうするとマイクが遠ざかっちゃうんで、やっぱりリモートではめられるノイズカットの良いマイクを探さないといけないなと思いますけど。
Speaker 1
ノイズカットにするか、フィルターか。乗せてもいいなと思いますし。
33:07
Speaker 2
立って話してるとね、やっぱり息遣いが荒くなりがちなのと、服の擦れ音とかが入ったり、環境音とかも入りやすくなるんで。
なるだけノイズカットの良いイヤホンが求められるな。イヤホンというか、ヘッドセットか。
Speaker 1
確かにこれあれですね。よく考えたら6個センサーついてますけど、上半身だけでヘッドとアームだけで3点トラッキングとかでも全然できると思いますし。
Speaker 2
減らしたトラッキングできるのかな?全部ついてなくてもいける?
Speaker 1
つけてもいいと思いますし、できるんじゃない?さすがにと思ってますけど。
Speaker 2
つけた範囲だけでその部分だけのトラッキングできますっていう。
情報ができるんだったら最強っすね。
情報ないけど。できるんじゃない?さすがに。
それだったら私多分両手だけでも今欲しいですね。
Speaker 2
確かに欲しいですね。
説明してる時の身振り手振りをある程度今のこのクラスターの中に取り込めるだけでもだいぶ劇的にいいと思うので。
Speaker 2
確かにでもそれやりたいっすね。
リップは今取れてる。
頭の揺れはどうせリアルに反映させるとしょっちゅう首動かしててなんやこやってなるだけだからいらない。
なので両手だけでいいんですよね。
Speaker 1
ちょっとやりたいですね。
やりたいな。
ちょっと買おうかな。
欲しいけど今このラインナップだと俺端末がないわ。
私もないんで中古のエクスペリア買う感じかなと思いますけど。
Speaker 2
中古のiPhone買おうかな。
iOSも欲しいし。
Speaker 1
いいと思いますね。
でもそれでも高くないですしセンサーも軽いし本当にBluetoothだしワイヤレスだしUSB-Cだし防塵防水対応してるしても本当に火の付けどころがないので。
Speaker 2
マジで火の付けどころはないです。
連続時間も10時間あんまりあるんか分からないけど半分の5時間でもう十分すぎるので。
Speaker 1
でも加速度センサーと格速度なんでそんなに消費電力変わらんと思うんですよね。
Speaker 2
Bluetoothの通信量次第。
Speaker 1
通信量次第ですし人間の動きなんでそんなにサンプリングレートもいらんですし多分。
Speaker 2
分かんないなそれ。
イベントトリガー形式になってるとちょっと多いかもと思う。
加速度が一定以上の敷地超えたら今リアルタイムにすぐ反映しなきゃいけない情報として即通信するっていうことをやってるとちょっときついかもしんないけど。
36:13
Speaker 2
そういう意味ではサンプリングレートは高くてもいいけどBluetoothの通信レートは低くてもいいかなという気はしますね。
それはそうだと思う。
あと最終整合性だけ取れたらいいから中間圧縮したりとかしてほしいな。
Speaker 1
動いてるの見たんですけどデモで2秒くらいかな。
表示機まででキャラが動いてるところが2秒くらいのズレはあるんですけどその間に整合してると思えば使えないくは全然ないですし。
Speaker 2
いいねいいね。これはなかなかなかなかですね。ほんと一式欲しいな。
Speaker 1
そうですね。
Speaker 2
ちょっと東電先生の体験の話聞いてから決めようかな。
めちゃくちゃ欲しいの欲しいです。
Speaker 1
ちょっと確かに使ってみたいですね。12月中旬予約開始なんで。
Speaker 2
そうか予約開始か。発売開始はいつですかね。
Speaker 1
どうですかね。
1月下旬かな。
Speaker 2
じゃあもうちょっと先か。
いやーこれはでも速攻で予約いっぱいになって生産中ですってなりそうだけどな。
Speaker 1
そうですね。
Speaker 2
ちょっと誰が見ても良すぎるからめちゃくちゃ人気になると思う。
いやどうなんだろう。VR勢だけかも。
Speaker 1
とりあえずVR勢だけかもしれないですけどVR勢はみんな買うと思うので。
Speaker 2
いやーこれはマストバイでしょ。絶対良いよ。
Speaker 1
本当にね。
今までの重たい、でかい、使いづらい、設備も必要、天井に何かつけなあかんとか全部ちょっぱらわれるんで。
Speaker 2
そう服変えなきゃいけないとか。
これ軽いし簡単につけれるから服装制限ないんですよね。
Speaker 1
そうですね。
ブルートゥースだし、カメラとかで見る系も前からありましたけど、ああいうのだと、今回カメラあるのかな。隠れたら。
カメラは無しなんで服の下につけても大丈夫ですよ。
Speaker 2
その辺も素晴らしいよね本当に。
Speaker 1
外界センサーに頼らずとも成立できる精度を出せたっていうのも素晴らしいですしね。
さすがに画速のセンサーとかなんで10時間連続で使っているとちょっとずれてきたりもしそうな気もしますけど、全然許容できる範囲だと思いますし。
Speaker 2
これ産業向けには多分真っ黒いデザインとか出すんだろうな。
Speaker 1
あると嬉しいですね。
確かに。
39:01
Speaker 2
ダンス衣装とかにかぶったら困るじゃん。
Speaker 1
はいはいはい。そうですね。
しかも全然サイズも小さいんで本当にイベントとかでお客さんにつけてもらう上でも全然今までよりコストが楽ですしね。
Speaker 2
そうですね。
Speaker 1
お客さんにヘッドマウントディスプレイかぶってもらったりするとだいぶコストがかかるんでね。
Speaker 2
いいなあ。これ常時つけてて全然困らなそうだったら、あれ?なんかね、猫背チェックとかそういうの使ってほしいけど。
Speaker 1
頭と腰があればなんとかなるかな?確かに。
Speaker 2
うん、とか。あとはウォーキングの足の上がりくらい。
Speaker 1
はいはいはい。
Speaker 2
いやあ、いいわ。本当最高。
お、誰かいらっしゃった。クラスターのように。
Speaker 1
さっきもちょっと誰かチラッと映りましたけど。
ごめんなさい、オープンでやってるもんなんで。
Speaker 2
まあまあいいんじゃないですか。
Speaker 1
はい。
Speaker 2
はい。
Speaker 1
という感じなんで、皆さんマストバイですという感じですね。
Speaker 2
はい。じゃあ次行きましょうか。
GitHubを聞くリモートワークでのチーム開発課題を解決するチームオンエアとは?ということでコード人の記事です。
これはインタビュー記事になっているのでちょっとしゃべりづらいので要約していきますね。
もともとの課題感としてはよくあるテレワーク課題の一つで、
他の人が何やってるかわからない、自分の仕事だけに注目しがち、
個人責任な仕事が増えていって結果的に組織としての対応ができなくなっていく。
ですとか、他の人が何やってるかわからなかったら他の人の発言が聞こえないことで、
帰属意識が失われたりとか、組織を通じた自分の価値向上、
周りの人がこんなこと喋ってくれてたからそれに関心を持って新しい勉強モチベーションとキャリアモチベーションにつながるとか、
そういったことが得られなくなって、すごく個人での頑張りが自己キャリアを伸ばすものにしかならずに、
組織に属している意味がなくなっていってしまう。
結果的に組織としてのパフォーマンスが低下していって生産性が悪くなっちゃうとか、
そういった課題がいっぱいありましたよねっていうのは、このラジオの中でも喋っていたと思うんですけど、
そういった課題を解決する上でGitHubを聞くという手段を取ってみましたっていうのがチームオンエアですと。
GitHubを聞くって言ってますけど、いろいろ転用できる話なので、概要からいくと、
42:02
Speaker 2
チームオンエアで行っていることはGitHubで行われたイベント、新しくコードがコミットされたですとか、
コードの変更点をオープンリクエストとして誰かにレビューが投げられたですとか、
そのレビューにどんなコメントがついたといった情報を自動音声が喋ってくれるというものですと。
本来であればスラックとかにそういったプッシュだったりとか変化点っていうのはスラックに投稿されて、
スラックの通知で右下のポップアップとして見る。
詳細が知りたければそれを開いてみるっていう動線だったんですけど、
それをするとやっぱり目の前の作業への影響度が高すぎる。
画面が切り替わっちゃうとどうしても作業が中断したのと同じくらいになって生産性を落としてしまうから、
スラックは通知を無効化しておく。
集中しているときはスラックを見ないようにするといったようなベストプラクティスができるくらいには、
チャットツールの通知とかそういったものは非常に生産性を落としてきたっていうのが背景としてあるので、
そういった通知は耳で聞くようにしようというのがチームオンエアのやっていることですと。
これによって、ながら劇作業ができるようになりますと。
それがどういう良さがあるかというと、
基本的には耳から入ってくる情報は無視して聞き流しておく。
関心があれば聞けばいいということで、オフィスで聞いていたときと同じような体験ができるようになる。
スラックの中ではこんなニュースがあったよっていうニューストークだったりとかそんなものがあったりするので、
自分が聞きたいチャンネルとかを設定してそれを聞くようにすることによって、
自分の関心どころをその組織に寄せながらテレワーク、リモートワークができるようになると。
あとはどういう情報を耳にしたかっていうのをアクティビティとして別途閲覧できるので、
耳で聞いてたけど聞き逃した、途中から聞いたけどこれ関心あったって時に振り返りたくなるので、
そういったものも振り返れるようにしてあるというのがいいところですね。
あとはカレンダー連携とかで会議が予約されましたとか、
そういった仕事をする上でのインフラツール群との連携というのも今後やっていきたいというのがチーム運営の話です。
いいところばっかり言ったんですけど、悪いところとして残っているのはこの音声情報の距離感っていうのが
一定なところがちょっとまだ難しい部分ですね。
リアルオフィスだと自分たちのチームがいる島っていうところに自分の席があってそこで作業して、
45:00
Speaker 2
周りの音を聞いているので、距離的に近い情報というのはチームの情報である可能性が高くて、
関心を寄せないようにしているので、
音の距離感、耳が捕まえている音の距離感で取捨選択ができるというメリットがあるんですけど、
こういうチームオンエアとかだと、
音の距離感というのは、
音の距離感で取捨選択ができるというメリットがあるんですけど、
こういうチームオンエアとかだと、
情報の取捨選択をあらかじめ設定ツール上でうまくやっておいてあげないと、
ちょっと煩わしいということになりかねないなっていうのがあるので、
その辺のバランスは難しいんですが、
今までこういったコミュニケーション化というのは、
今までのプログラムで、
一日中VCを繋ぎっぱにするとか、そういった活動とかもあったんですが、
それと比べると、
レビューに書いたものだったりとか、プッシュしたイベントというのは、
チームに対してオープンに発信した情報になるので、
そういった情報だけが耳に入ってくるということで、
仕掛け自体のメリットがあるんですけど、
音の距離感というのは、
耳に入ってくるということで、
仕掛け自体の時点で、ある程度情報の出した選択ができているという点が、
結構面白いかなと思って紹介です。
Speaker 1
ちょっと分かってないんですけど、
これは入力したテキストをBotが喋ってくれるっていうことでいいですか?
そうですね。
Speaker 2
イメージとしては、ソースコードを構成管理ツールにプッシュしました、
そのプッシュしたイベントがあります。
そのイベントをスラックとかに投稿します。
スラックに投稿するときには、
プッシュしたときに、
これはこういう行動の変更ですという情報を付加してプッシュすることになるので、
その情報をそのままスラックに投稿します。
そこにスラックに投稿されたその情報というのが、
音声で喋ってくれるというのがこのチームオンエアですね。
Speaker 1
なるほど。
確かにリリードが難しいですねという話があったんですが、
まさにそうだなと思いますね。
聞き流すという意味では確かに、
そのプッシュの内容とか下手すると100件、200件詰まれたりするので、
それを流し目で見るよりは、
作業しながら流し劇した方が確かに効率が良さそうな感じ。
流し劇していく中でちょっと興味があったら、
そのワードを拾いに行けばいいと思うんで、
そういう意味では効率が良さそうだなと思います。
48:01
Speaker 1
問題はリリードですねという感じで、
結局200件ぐらいあったやつをずっと聞いてたら、
なんか聞き疲れしちゃって、
最後こいつが落ちちゃうとかなると、
あんまり効率が良くないなというところもあるんで。
そうですね。
ツールとしてはいいと思うんで、
チャットの流度、重要度に合わせてどこまで通知するかというのを選択できる。
とか、チャットボットの声を変えるとか、
アテンションを最初につけるとか、
そういう仕掛けがあると嬉しいのかなという気はしますね。
そうですね。
Speaker 2
その辺もおっしゃる通りでいいアイディアかなと思いますし、
あとはやっぱりヘッドセットとか物理機器が
もっと優秀になってほしいなとは正直思いますね。
リアルオフィスを想像してみてほしいんですけど、
集中している時っていうのは、
かなり耳の中に取り入れる情報の距離っていうのをめちゃくちゃ狭めてる。
もう自分に直接話しかけたところ以外は
カッチするくらい距離を切ってるんですけど、
ヘッドセットだとどこまで行っても距離を切れないんですよね。
もうゼロ距離で喋られちゃうから。
それが本当に辛い。
自分で調節の効かない音声のインプットはやっぱりイラっとするというか、
集中力を欠いて生産性を落としてしまうというところが拭いきれないので、
それができた上で今おっしゃった通り
アテンションで、例えば島のお誕生日席にいる課長とかが
おいみんな聞いてくれっていうレベルで喋ることは
やっぱり反応した方がいいし、
こんなちょっとコードが見たからレビューしてくださいねって
前の新人君と右前のまたベテランの人に
喋っている会話を耳にするのとでは流度感が違うはずで、
その時の伝え方、表現とかを変えてもらうっていうのももちろん大事だし。
そうですね。
そこら辺どうかな。
Speaker 1
空間オーディオを使いたいなという気はしますけどね。
まあ、
アテンションの音声のインプットは
仮想的なオフィス空間上でどこから発信しているかっていうのを
適当につなげて、
前向いてたらメインの話ができて、
脱談レベルのやつは右後ろから聞こえてくるとかにして、
そっちを聞きたくなれば首を回せばいいみたいなね。
できるといいのかなという気はしますけど。
そうですね。
Speaker 2
発想としては良くて、
51:02
Speaker 2
今までのVCつなぎっ端で大なり小なり全部聞こえてくる、
逆に監視されているかですらあるという状態からは
かなり大幅に良くなっているとは思うんですけど、
まだまだ足りないかなって感じですね。
Speaker 1
そうですね。
現状改善という意味では非常に良い手法だと思うのでね。
そうですね。
何かしらちょっと流行っていって改善しますみたいになってくれると
嬉しいかなというところですね。
Speaker 2
はい、以上です。
Speaker 1
次ですね。
質問に答えてくれる言語モデル
ChatGPTプレビューは無料公開という
ツイニーネットジャパンさんの記事です。
比叡利の人工知能研究組織OpenAは
米国時間11月31日に対話型言語モデルChatGPTを発表した。
2022年初めに学習を終えた
GPT3.5シリーズのモデルを改良したもので、
フォローアップの質問に答えたり、誤りを認めたり、
間違った前提に異議を唱えたり、不適切な要求を拒否したりできるという。
テストのためのプレビュー期間はChatGPTを無料で利用できる。
日本語にも対応しており、
Twitterでは有能すぎるなどと話題になっているようだ。
ただしChatGPTは現段階ではもっと漏らしく聞こえるが、
不正確な回答や意味不明な回答をすることがあるという。
また言葉数が多すぎる一面もあり、
OpenAIが訓練した言語モデルであることを共通するなど、
映像を何度も繰り返す場合も多い。
不適切な要求を拒否すべきところに有害な指示に反応したり、
偏った動作を見せたりすることもあるとのこと。
OpenAIはユーザーのフィードバックを得て問題点を把握し、
システムの改善に生かしたい考えだ。
ということで、今TwitterでプチバズしてますChatGPTさんが来ました。
これ何かというと、
QA方式でAIが答えてくれるという感じのチャットボットですね。
例えば、
お鍋の材料は何がいいですかというと、
鍋、今の季節にやった鍋の材料を答えてくれるといった感じで、
保管してくれる機能というか、
こっちの糸を
保管してくれる機能というか、
こっちの糸を想定して回答してくれるという点が、
今までのチャットボットよりもずば抜けて優秀です。
というところが良いというところでバズってます。
というところですね。
Speaker 2
基本的に良いものだと思います。
54:01
Speaker 2
不正確性についてはそうなんですけど、
それぞれ比較的、
比較対象は今までのチャットボットを想定するべきだと思っていて、
Speaker 1
今までのチャットボットというのは基本的に
Speaker 2
QAの回答表というのがそもそもある程度用意されている。
その中で自然言語処理をして、
最も近いワードが含まれているコンテンツを出す、
もしくは完全に一致していない場合は出さない。
他のチャットボットの仕掛けとしては、
QAの回答につながるフローを組んでおいて、
ご質問はこういうことですか、こういうことですか、
という動線を組んで最終的に答えを導けるというような、
そのロジックに処理できるものがチャットボットで、
ちょっとAIというには肩払いたいようなものだったんですけど、
今回のチャットGBTは、
3つのコンテンツを使って、
QAのチャットGBTは先ほどおっしゃった通り、
こちらの質問のある程度背景、想定だったり、
期待する答え感というのを、
ある程度推定立てで情報を返してくる。
Aということを聞いたらAの背景と、
Aと定義的にこういうもので、だからこうですというような、
三段論法的な回答をしたりとか、
ということもできるようになっていて、
ちょっとしたウィキ的な回答結果を得られるというものですね。
そうですね。
Speaker 1
ウィキって言ってくれたらまさにそうだと思っていて、
Google検索の代わりのようなものになりそうだな、
という食感が得られているのが、
個人的に好感やなと思っています。
Google検索も、
ワード、単語を検索して出てきたサイトの情報から、
知識を増やすという感じだったんですけど、
最近汚染やら何やらで、
意外と難しいなという状況になっている中で、
こういうチャットBTに質問を入れることで、
わかりやすい回答が得られるという方向性がありそうなところが、
良いかなというところです。
逆に悪いところとしては、
一問一答なので、
平相談だって思うと実は間違っていることがあるとか、
政治的に中立な回答になっているけども、
実情に合っていないとか、
そういうところが散見されると、
そういうところが散見される回答がありそうなところがあるので、
パッと見て不運でおしまいだと、
57:03
Speaker 1
ちょっと怖いなという使い方になりそうというのが難しいところです。
ただ、オープンAIチームもそこは分かっていて、
政治的にかなり難しい質問は、
私には答えられませんとしたり、
個人の感情に起因するような質問は、
私はAIなのでその問いには答えませんとか、
言ったりするという、
セーフティーロックみたいなのが関わっていて、
Twitterのテキストを送ったAIとかだと、
そこら辺、ヘイトメーカーになってたりした経歴があったので、
そこら辺ちゃんとしっかりしているっていうのは、
すごく良いのかなと思いました。
そうですね。私も使い方かなと思っていて、
Speaker 2
おっしゃる通り、
まず学習材料がインターネットの情報なので、
現地点で解決していないもの、
一位な答えが見つからないもの、
あるいは最先端な情報なものっていうのは当たり前ですけど、
情報源自体が少ないので、
学習料が単純に足りないからこそ、
精度が上がりにくいっていうのは自明としてあるわけなので、
学校で習うような、
教科書に載っているような情報であれば、
比較的80%くらいの気持ちで読めるかなと思っています。
そういう目的で、
探すのがまずいいんじゃないかなと思いますね。
そうですね。何もわからんっていう状態から、
Speaker 1
一回ここをかませて、
疑問に思ったところとか、
より深く知りたいところは、
別のソースで調べるとか、
そういう方向で使うと良いかなというところですね。
あとは、答えが決まりきった問題。
Twitterだと、
ソースコードをバーンと貼り付けて、
どこが間違っているか、期待された入力と違うんだけどって質問すると、
間違っているところを指摘してくれるとか、
これはチャットGPTというよりは、
OpenAIがやっている他のサービスとリンクしてて、
ソースコードの整合性チェックみたいなサービスとリンクして発揮されている能力だと思うんですけども、
そこを自由書式っていうか、
日本語でペラペラっと書いて、
それで回答してくれるとかは非常に使いやすそうなので、
そういう用途も
非常に良い感じですね。
Speaker 2
何だろうな。
1:00:02
Speaker 2
エンジニア目線の話になっちゃいますけど、
普段の作業の中で毎回調べているけど、
これは覚えきれなくて調べているだけなんだよなっていうことが
いっぱいあるじゃないですか。
あれはもうこのチャットGPTで全部良いと思いますね。
IPの最大24ビットで切ったら何個IP使えるんだっけとか、
めんどくせえとか、
あとはJFlip Flopって何のノアで作るんだっけとか、
そんなんも多分聞けば一発で出てくると思うので、
枯れててちょっと思い出せないことは
全然これを使っておくと、
事務から仕事で価値を発揮している領域っていうのは
基本的にチャットGPTの中では
基本的には
50%くらいの結果しか得られないと思って
向き合った方がいいだろうなと思いますかね。
そうですね。
Speaker 1
そこがちょっと怖いところであって、
最もらしい回答をするんですよね、
もし間違っているのとしても。
自信がないけどこの回答ではなくて、
真実性の高い情報と同じような回答をしてくるんで、
そこはちょっと気をつけないと実は間違ってたとか
あるところですね。
Speaker 2
それに対して使い方のノウハウとして、
一回出た答えに
それは本当に正しいですかっていうのを必ず聞くようにするっていう
チップスがすでに生まれ始めた。
角度が低い場合は
確からしい情報から導かれた答えではなかったかもしれませんっていうのを
返してくることがあるんで、チャットGPTから。
Speaker 1
それも…
Speaker 2
とりあえずそれを一回打っとくっていうのが
Speaker 1
ハックとしてはありですけど、それぐらいなら最初から角度が低い情報ですと
言ってほしいっていうのと、あくまで角度が低いかどうかって
結局のところこれ
データベースの総量の
3成6割、反対4割みたいな割合の話になってしまうんで
学習内容が反対の方が多かったら
そうは言うかもしれへんけどみたいな
結局確率の問題になってしまうと思うんですよね。
Speaker 2
そうですね。
Speaker 1
なので、信用度の高いソースだから
信用度が高いというところが確認できると
ちょっと結局のところそれほんま変わってないそうな気もしますね。
Speaker 2
そうですね。
1:03:03
Speaker 2
その辺はWikiとかと同じ問題を抱えている感はあって
例えば
新しく研究結果として今までこう考えられてきた事実は違って
これが本当は正しかったですっていう情報の更新に対して
その角度という意味だと
情報量の逆転が起きちゃってるから
Speaker 1
そうですね。
そこら辺も難しい問題ですねというところでありますけど
一般回答としてはそういう意味では
GPTの回答でも別に問題はないかもしれないんですけどね。
枯れた情報に特化して調べるのがいいんじゃないかな。
Speaker 2
間違ってるところを
Speaker 1
どう間違ってるのかを読み解くのがめちゃくちゃ難しいので
Speaker 2
そうですね。
Speaker 1
Rebuildの人もやってましたけど
Speaker 2
Rebuildのパーソナリティーは誰ですかっていう情報に対して
一般回答で
パーソナリティーは誰ですかっていう情報に対して
明らかに間違った完全に関係のない無関係な2名のパーソナリティーが
そのGPTからの回答で返ってきてましたけど
それを実際に中身知らない人が見たら
人の名前が大幅に間違ってるってなると
だいぶその間違いだと気づけないし
その間違ってる人自体は
テックラジオパーソナリティーはあったんですよ。
だから簡単には間違いだと気づけない
間違い方をしてきているので
Speaker 1
ちょっとつらいなと思いますね。
そうですね。
考えると結局他のデータソースも欲しいってなっちゃうんで
何でしょうね。
やっぱり最初の一歩として
ちゃんとGPTでとりあえず
引っかかりがないところが答えてもらって
そこからは別のソースを確認するとかがいいのかなという気はしますね。
そうですね。
Speaker 2
ちょっとネガティブな話ばっかりしましたけど
基本的には面白い回答いっぱい得られてますし
プログラミング言語とかもいろんなものをサポートしていて
かなりいい回答を得られてることも多いです。
あとはデータベースに対するクエリ文とか
めっちゃ忘れがちなんですけど
ああいったものもいい感じに出してくれたりするので
有用な領域はいっぱいあると思いますから
ぜひ使っていってほしいなと
これもあまり推奨してない
1:06:00
Speaker 2
使ってもいいけど責任持てないというのは当たり前なところと
学習モデルとしてはすごく汎用的なデータだけを対象にしているので
そのコンフィデンシャルな情報とか社内機密情報が
混じってるかもしれない情報を入れないでほしいというのが
利用規約上あるので
現状はまだ個人のおもちゃレベルかなという段階ですかね。
ちなみにリカログや私たちの名前で打ってみましたが
知りませんと言われたので私たちは知名度が全然足りないですね。
Speaker 1
出るわけないやん。
出るわけないやん。
Speaker 2
やっぱり自分たちWikipediaのページを起こすところから始めないといけない。
Speaker 1
それでもN1だろう。
頑張っていきましょう。
Speaker 2
私のほう最後ですかね。
Mars Tech Japan。
異なる事業者モビリティ間の移動実績データを統合するMarsプロダクトを提供開始。
IoTニュースの記事です。
現在地域公共交通は存続が懸念される状況にあり
国土交通省や内閣官房では持続可能な形で再構築される法則が提言されている。
この実現にはどこからどこまでどのくらいの人が移動しているのかを示すための
移動実績データを地域全体で把握分析するとともに
将来の水系人口や人流データといった
Mars関連のデータを組み合わせた考察が必要であると言われている。
地域全体でのデータ把握分析には
自治体や交通関連事業者が連携し
様々なデータを統合することが必要となるが
各事業者が保有するデータの形式やシステムの違いにより
データの統合は困難なのが実情だ。
そうした中、株式会社Mars Tech Japanは
移動データを統合・分析して交通施策を導く
Mars Platform CMaaSの第2弾として
CMaaS Basic Editionを2022年12月2日より提供開始する。
CMaaS Basic Editionでは鉄道・バス・デマンドバス・シェアサイクル・自動車・電動スクーターといった
異なる事業者・異なるモビリティ間の移動実績データを
統合・連携することが可能だ。
これにより、事業者間をまたがるデータ分析が可能となり
施策の検討、その交通施策が各交通機関に与える影響のモニタリングを
一つのプラットフォーム上で実現できるようになった。
また、移動実績データに加えて将来水系人口・人流データなどの
Mars関連データの統合・連携が可能。
バスや鉄道の移動実績データと人流データを組み合わせて分析することで
例えば、人の移動は多いのにバスや鉄道の移動実績が少ない地域を把握して
潜在需要を把握するなどの交通課題の可視化を行うことができる。
可視化分析メニューは今回のリリースでは
1:09:02
移動実績データの可視化分析に関するメニューから開始される。
Speaker 2
モニタリングダッシュボードでは複数の交通機関の利用者数を
時間・曜日別・路線別・利用者別・乗降場所別などの視点でグラフや地図上で可視化。
施策や外的環境が複数の公共交通に与える影響を統合的にモニタリングし
各交通機関の利用者統計を様々な角度から検証することができる。
Speaker 2
さらに時間別と区間別で利用者数運行便数を集計し
1便あたりの平均利用者数を地図上に可視化することも可能。
利用者の多い、もしくは少ない区間時間帯を確認することができる。
今後 CMaaS は今回リリースする分析メニューに加え
Speaker 2
将来推計人口・人流データ・天気・消費などのMaaS 関連データを活用した分析メニューも拡充し
自治体・交通事業者・一般企業へ展開していくとしている。
また、脱炭素・医療・物流・観光・防災のスマートシティ・ビヨンドマーズ軸での分析パッケージの提供も予定している。
なお、2020年12月から石川県金沢市が立ち上げた金沢MaaSコンソーシアムにて
CMaaSを用いた各交通課題の把握・施策の効果検証を行うプロジェクトの実施が検討されている。
ということで、MaaS関連はかなりコンセプトだけ今まで立ち上がっては来ていたものの
なかなか車だけだったりとかバスだけだったりとかで本当に独立したものがてんてんとしていて
てんてんとしたその情報で何の役に立つのって言われて
あまり可視化された結果、MaaS化された結果がフィードバックされる、現場に何かいい効果をもたらすっていうニュースが
出てきてなかったのが正直な実情だと思っていて
その中でこのサービスっていうのはその実情を正しく把握した上で横連携をしようという取り組みになっているので
とてもいいなと思っています。横連携できた上で今回ここで言っているようないい効果っていうのが
本当に発揮されるかどうかはどこまで各事業だったりとかが連携しやすいインターフェースを持っているのか
っていうそこら辺の実情、紐付けっていうのはやろうと思えば誰でもできるというか
時間と金があればいくらでもデータっていうのに紐付けられるので
それが各事業がこういうものにやっぱり参画しようという気持ちを持って
インターフェースを設計したり自己投資したりっていうことをやっていかないとうまくこの横の連携っていうのを果たせないとは思っているので
そこら辺の実態は私からは分からないんですが
1:12:00
Speaker 2
そうなっていくのであればかなり良い未来だったりとか
いろんな施策っていうのが打っていけそうな可能性を秘めているものだと思うので
良いニュースかなと思って紹介です。
Speaker 1
そうですね。非常に良さそうですねというところで
結局こういうデータってやっぱデータがないと最もらしい施策というか説得力がない状態でやっていくしかなくて
それでだいたいこうだろうってコストかけてやることで成就性の高い施策になっていくと思うので
データは悪に越したことはないと
ただそのデータを取るにしてもかなり大変なのでこういうインフラがあると非常に便利ですねというところではすごい良さそうですね
実際これはどうやってこのデータ収集してるんですかね
Speaker 2
そこは全然正直私も分かってないんですけど
Speaker 1
鉄道とかバスであれば運営運用会社のインフラと結合してそれをこのプラットフォーム上で共通化して表示できるとかなのかなという気はしていて
そういうのであれば自社のインフラ次第かなと
あまりに下手なデータベースだとちょっと統合が難しいとかいうなったりしそうな感じもするんで
でもそこ含めそこのコンパイルデータ整形含めのサービスなのかな
あればなんとかなるのかなという気もしています
Speaker 2
公式のホームページ的には専用のMarsアプリになるものがあって
交通系ICと紐づけたりとか人流と言ってるから多分人がぽちぽちやるんですかね
あとはどっかにするときの予約を押したらそれが自動的に紐づくとか
そういったインターフェースを用意して組み込みたいというように見えますね
Speaker 1
はいはいなるほど
そこが充実していれば実装は何かしらできると思うんで
あとはどんだけコストかけるかっていう話にはなると思います
Speaker 2
まだちょっと例明期すぎるのと競合もあまり出てきてないし
おそらくこういうのは私はトヨタだったりとか大手車メーカー主導になるだろうなっていう想定をしてたので
これがデファクトになっていく未来っていうのは申し訳ないですけどあんまり描けてはないんですが
実際こういう活動が課題だったりとかを世の中に出して展示会とかで広めていって
結果的にクリティカルに解決するのを大手が出すというそういう業界モデルもあると思うので
1:15:04
Speaker 2
個人的には期待してます
Speaker 1
でもそこに関しては私結構需要はあるし
使いやすいインフラさえあれば大手じゃなくても利用するかなと思っていて
ちょっと話がばらけちゃうんですけども
例えばドコモとかAUとか携帯端末会社は携帯のIDで人の人流っていうのをだいぶ細かい単位で実はデータを持っていてて
それはお金を出せば買えるんですよね
それによって例えば名古屋で普段仕事してる人がこのイベントの時だけ東京に来ましたみたいなのが
かなり本当に人数レベルで分かるという情報があるので
実は大手はもう既に実装してて
広告代理店とかはおそらくばんばりじゃんじゃん使ってるというのが実情ですと
でどちらかというと私が期待したのはそこより細かい細かいというか
資本力が小さい単位
例えば市町村のなんちゃら委員会とか
そういう感じで例えばお祭りをするから
こういう動線を取ってこうやってこの日時でやれば一番効果が高いでしょうとか
こうするといいよねみたいなところまで取れると嬉しいなと思っていて
例えば最近だとうちの地元の近くでも旅館が結構ある地域があるんですけど
そこが地区の旅館が全員の宿泊者の情報をまとめるデータベースみたいなのを作っていて
それでこの休日は遠方からの客が多いから
そこに集中的な即反を当てようとかいうことをやっていると
ただそれも個人というか独自のインフラですと維持費もかかりますし
整合性もなかなか難しいものがあると思うので
そういうところで共通インフラこういうものを使って
手軽に一から考えてもとりあえずパッチというか
ウィザード的なのでとりあえず分かるようにする
簡単に分かるようにするっていうことができると
コロナで人流が減っている中でもじゃあどうしていこうかっていう対策が打ちやすいのかなと思うので
そこに当てれると嬉しいかなという印象ですね
Speaker 2
そういう意味だとこの記事の冒頭にあった通り
国土交通省とか内閣官房自体が課題として認識して
継続的に利用できるデータ源が必要という提言をしているので
1:18:04
Speaker 2
このプラットフォームが目指すゴールはおっしゃる通り
巷の各産業が自由に利用して
自分たちのビジネスモデルをより良くするための情報源として
利活用することがゴールのプラットフォームだと思っているので
そこに貢献はしてくれそうかなという期待感はありますね
Speaker 1
そうですね
そういう意味ではすごく期待が高いですね
Speaker 2
私が途中喋りながら地図上に可視化っていうところを
ちょっと強調して喋ってたんですけど
個人的にはここが素晴らしいなと思っていて
地域のいろんな交通網を多角的に気にしている年代というのは
高齢者が多いと思ってますと
なぜなら自分の身体能力の低下によって
最低限あるこのインフラが使えたらいいじゃんという立場ではなくて
もう選べる
そもそも交通インフラの選択肢が限られている中で
Speaker 1
どこが足りてるどこが足りてないっていうのを一番注視している年代層だからですね
Speaker 2
そういった層の人たちに時間軸と地図上っていう平面図上と
交通網っていう軸と移動距離とか地域密集度とか
そういう多角的な議論をロジカルに文章でやっぱり伝えたりとか
Speaker 1
課題を吸い上げるってものすごく難しいと思うんですよね
Speaker 2
この目指しているプラットフォームでアウトプットしている地図上のグラフ表現っていうのは
そういう人たちにこういうことが起きてるんですけど合ってますかと聞くだけで
良くなるものになっていると思っているので
かなり高齢者の意見をITに吸い上げるインターフェースになり得てるなと感じるので
良いと思ってますね
Speaker 1
なるほど
半分ぐらいで多いと思ってて
確かに文章とかの表で出されるよりは全然地図の方がグラフィカルなんで分かりやすいと思います
ただ普段そういう議論をしたことがない人に対して
地図上でグラフィカルに示したからといって説明が納得してくれるかっていうと
Speaker 2
まだ足りない
Speaker 1
足りないんじゃないのかなという気がしているという段階
1:21:04
Speaker 1
それも分かります
そういう意味ではもっとシュリンクする
例えばこの記事の一番下の図みたいに黄色1.5人未満の路線区間と2.5人以上住人未満の
頻度の使用者の多い区間と使用者の少ない区間みたいな感じで日課してやって
ここをどんだけ使いますかと
こっちのルートにしたらどうですかみたいな
そこまでいかないと厳しいんじゃないかなという気もしていてもないですけど
結論としてはそういう議論のできるデータベースの下地としては成立しているので
Speaker 2
そこは全然今までよりは素晴らしいなというところは同意しますね
データ量としてはいろんなものが集まって大きいものになって足りてきたので
あとはそれを特定利用用途向けだったり特定個人向けにデータを集約するというか
Speaker 1
そうですね
Speaker 2
その目的別データに組み替えてそれをどういう形でグラフィカルに表現すると
一番伝わるのかっていう最後の可視化フェーズがあるべきで
今大量にたまったデータをとりあえず可視化しましたで終わっちゃうと
一番伝えたい人には届かないかもしれないというのはおっしゃる通りかなと思いました
Speaker 1
そうですね
なのでそこのデータを解釈して説明するっていうスキルを持った人が増えると
効果が発揮されやすいのかなという感じはありますね
Speaker 2
そうですね
そうすると今流行りのデータサイエンティストみたいな人たちの活躍の場も増えてくるので
そうですねまさにそこですね
Speaker 1
この件は以上です
では私の方最後ちょっと時間も長いので軽くいきますけど
日本初学校給食にコオロギ導入食糧不足の救世主となるかという
ABCニュースさんの記事です
徳島県の高校の給食に食用コオロギを使ったメニューが登場しました
コオロギは食糧問題の解決策とも期待されていて
学校給食への活用は国内初の試みだといいます
徳島県の県立小松島西高校かな
28日の給食カボチャコロッケには食用コオロギのパウダーが練り込まれています
ベンチャー企業グラリスと高校植物科の生徒が協力して開発しました
給食を食べた生徒をいわくカボチャの甘みとコオロギのエビやカニのような香ばしさがあって
すごくおいしかったですということで
1:24:00
Speaker 1
この高校では今後もコオロギを活用して給食のメニューに挑戦したいとしていますという話です
個人的にはこういう新たな食物源の開発っていうのは賛成の立場なんで紹介したんですけど
給食に使うかっていうのはちょっと難しいなと思って
どう思います?心がかみさんというところで紹介しました
Speaker 2
ものすごく難しいですね
多分今難しいと言ってる観点は
給食というのは一定の金額をみんなが払って
全員共通の食べ物が提供される
提供されるからにはその世代にとって一通りあまねく必要な栄養源が揃っていて
食文化の多様性も維持できるものが提供されるべきというものが
学校給食だと思ってますという中で
このまだ社会的に許容されきっていない食材を利用することに対して
ある種お金を払っている場合強制的に給食に盛り込まれてしまう
そこの許容されてない人も受け入れて食べなければならないという状態にさせてしまう
文化の浸透を強制してしまう行為になっていないかというところが難しいポイントかなという気はしてます
Speaker 1
そうですねまさにそこでして
私は結構なんかイベントとかであと食べるんですけど
社会的に許容されてるかというときはされてないだろうなと思っていて
そこである種の公的というかなんていうんですかね
強制力のある給食に対してコオロギー使うのはちょっと軸相性な気がする
というところが私の感想でもあります
ただ面積事項というか前提と話しておくと
高校の食物科の生徒が協力して開発しましたってことなんで
イベントというか高校の活動の一環として生徒含めてやったということなんでは
押し付けというほどではないというところは
何ですかねそれであればいいかという話もなるのかなと思ってはいますと
1:27:02
Speaker 2
極端なこと言えば学校の農業科の生徒が作った野菜が給食に使われましたよって言ってるのと
Speaker 1
そうですね同じようなもんなんでそういう意味ではいいのかなと
あとはそうですね正直な話食用コオロギー
心理的にもそうなんですけど実際あまり肉としては結構癖が強いですよね
文中にもありましたけど結構広角類の味がするので
そこであまりコオロギー食が充実してない中で無理に導入しようとしても
コオロギーってなんかちょっと食べづらいなってなってしまうのがもったいないかなという気持ちがあります
ただそうはいつつもこうやって導入していく切り込み部分がないと浸透しないし
コオロギー食の料理手法も確立されないのでそういう意味ではやってほしい気持ち半分
時期相性なんじゃないか半分でちょっと揺れてますねという感じですね
Speaker 2
一応分かりますねニワタマ問題ですけどそれこそエビとかカニも最初から美味しかったわけでは当然なくて
すごく工夫がされていると思うんですよね美味しく食べれるようになるまで
当然カニなんて今はすごく高級食ですけど冷凍技術が進んでなければ生臭くて食えたもんじゃないと思いますし
エビだって綿を抜かなきゃだいぶ苦くて食えたもんじゃないと思うんですよね
殻を食べるなんてとんでもないっていう状態だと思うんですけど
今のコオロギーのその出し方っていうのはそれこそコオロギーのつくなぎで姿のまま調理することが
メジャーになってたりもしくはもう極端に今回のように粉末状にしてしまうっていう二極化していて
その美味しく食べる食材を美味しくいただくための工夫技術っていうのが全然進展してない中で
社会に提供しようとしてもやっぱり厳しいものがあるっていう感覚なんですよね
他の食材群があまりにも研究され尽くしているから
Speaker 1
そうですね
Speaker 2
なのでそういう状態の段階で給食に適応するのは早いと私も思うんですけど
それはでも不満が上がったからより美味しくしようっていうモチベーションが湧いたから
これだけいろんなものが研究され尽くしたっていう背景があるので
誰かの不満にはならないといけなくて
1:30:02
Speaker 2
その不満を生み出す活動としては必要なことなのかなと思ったりもして長々しいですね
Speaker 1
そうですね 確かにやってみてどこまでいけるのかっていうのを試してみるとやっぱりいけないですし
市場の反応っていうフィードバックも必須なので
美味しくなるまで待とうとか言ってたら出ないので
そうですね
Speaker 2
そうやっていくことが大切ですと
Speaker 1
コロロギもね 頭と殻剥いて腹だけにした方が多分美味しいと思ってて
そうなんですけど加工が難しい上に環境問題のトータルコストが低いという利点があんまりなくなるんでね
Speaker 2
そうなんですよね
エビについてはね 長年かけて向上化してそこら辺を自動化してきたから安く食べられるだけで
エビも高級食でしたからね
Speaker 1
そういう意味でもコロロギも何かしらのこんにゃくみたいにめちゃくちゃ頑張って加工すると全然美味しくなるとかあるかもしれないので
Speaker 2
そうですね
あと風味とかは良さそうなんで先に油とかで出てくると面白いのになと思いますね
東南アジアとかって結構虫系は大量の油で炒めてそこに香料とかいっぱい入れてみたいなことやるじゃないですか
Speaker 1
油漬けみたいなやつ
Speaker 2
あれで絞った油とかをチャーハンに入れるとかの方がまずなじみやすい気もするから
そういう商品とか出してくれればいいのになとは思いますね
Speaker 1
そうですね
Speaker 2
そこら辺に学ぶっていうのも全然アリだと思いますね
そっちの方がある意味食文化として進んでるので
確かに
はい そんな感想です
Speaker 1
はい 本日の内容は小道でまとめていますのでご確認ください
ご意見ご感想やこんなことを話して欲しいという方もお待ちしています
メールアドレスは
Twitterもやっていますのでフォロワーやダイレクトメッセージもお待ちしています
本番組はPodcastやSpotify、YouTubeを選びに来ることができます
ぜひそちらでもサブスクライブよろしくお願いいたします
はい お疲れ様でした
Speaker 2
はい お疲れさんでした
00:00

Comments

Scroll