00:00
はい。 今までとだいぶ雰囲気が変わってるな。 うん。
まあ、いいじゃないですか。面白い。 はい。
じゃあ、行きましょうか。 はーい。
はい、どうもkokorokagamiです。 当然です。
今週も1週間振り返っていきたいと思います。 はいはい。
まあ、先週、先々週とワクチン接種で倒れていたので できなかったんですけど、3回目になってもきついものはきついですね。
そうですね。やっぱり出るものは出ちゃいますかね、熱とかいろいろ。 うん。
必ず水分補給頑張れば何とかなるかなと思ったんですけど、全然そんなことなくて。 うん。
結局、打った日と次の日は死んでたのかな。 うん。
どうでしたか? 主な副作用がやっぱり、熱が結構出て結構辛かったですね。 はい。
私の場合、熱がやっぱり2日目の夜ぐらいまで出てたんで。 はいはいはい。
まあ、2回目と同程度ぐらいでしたね。 うん。
ねえ、なんか4回目の話も聞いてますけど、ちょっと気持ち的にはしんどいですよね。
そうですね。5ヶ月、今のだと5ヶ月ぐらいで、間隔ぐらいで、まあ、永遠に打ち続けるっていう方針になってるっぽいので。
まあ、その約半年に1回、こういう寝込まないといけない日が来るっていうのはちょっとあんまり幸せではないですけど、
まあ、メインのやつに、本体にかかるよりはマシという話ではありますけれども。
そうですね。 はい。
ねえ、あとはコロナの状況としてはだいぶ落ち着き始めてきてるのかな。
ちょっとずつ減少傾向にあって、緊急事態宣言とかマンボウとか出してない状態で減少傾向になってるのは良いことかなと思いながら見てますけど。
まあ、そうですね。ちょっと減ってきたっていうところなんで、はい。
そこは、まあ、嬉しいと言えば嬉しいんですけど、何が原因っていうのはちょっと理由もわからないですし。
そうですね。 減少傾向として言っても、実行再生算数が0.9以上なんで。
まあ、本当に微量ですね。
という感じで、まだ油断はできない感じではありますね。
そうですね。絶対数も普通に多いですしね。
はい。これで慣れちゃってるのは、まあ本当は良くないんですけどね。
そうですね。第5波の時は300人で騒いでたはずなんでね。
今や4万5千人くらいですよ。
ちょっと桁が違いますよ、マジでという感じではありますけど。
東京300人で騒いだ後半の頃は、日本全国で1000人超えました。どうする?みたいな感じでしたよね。
うん。まあ、その時とは意味、量体制度も整い具合も違うとはいえ、とはいえっていう感じなのでね。
そうですね。
はい。早いとこちょっと数字100人レベルまで押し込めたいところではありますね。
03:03
そうですね。
そんな2週間を経て、新しく導入してみたのがクラスターですと。
今YouTube配信の方ではその画面を共有してたりするんですけれども、
VR空間で会議をしたりとかイベントを開いたりっていうところのプラットフォームとしてクラスターというサービスが提供されてまして、
私たちもちょっとそれに乗っかってみようかなというところで、
お互いに自分のアバターを作って、そこでちょっとオフィスにマイクだけポンと置いて、
簡単なこじんまりとした打ち合わせをしてみるみたいな雰囲気で、ちょっと空間を用意してみましたというところです。
はい。
はい。そうですね。ちょっとぼったちになってしまっているので、画面見てもあれかもしれませんけれども。
まあ、アバターを自分らで作ったんですけれども、非常に簡単に作れましたし、
Vroid Studioという結構クラスターと連携が強いツールを使ったんですけれども、
はいはい。
すごく簡単にアバターを作ることができて、
そうですね。メタバースよくわかんないって人でも、とりあえず入ってみるという敷居の低さという点ではクラスターさんすごく優秀かなと思いながら使ってみている次第でありますね。
そうですね。画面上は音声オフということになっているんですけれども、
ちょっと音質の課題があるので、クラスターの中のその通話機能は使わずに、
別途のクリーンフィードを使っていますと。
一方でクラスターの中のやつを使うと、近くの人とだけ会話とか、その距離感に応じた音声の品質みたいなのがあるので、
今2人でやってるんであんまり気にならないですけど、副通りになっていくとクラスター内の音声を配信する方がよりリアリティがあったりとかいうことはちょっと想定されるかなっていうのはあるんですけど、
その場合どうしても誰か個人のその聞いている感じになってしまうので、ちょっと難しいなというのはありますかね。
ラジオという媒体的には個別に声を取り込んだ方がちょっと確保の易さとかもあるんで良いとは思いますけども。
でもワイワイ喋る感じだと、それなりに臨場感も出るので、そういうものを取りたければクラスターの方が優秀だったりもするかもしれませんね。
あとはですね、カメラマン兼そういう視聴者的な立ち位置のユーザーをもう1人用意して、その人の第一認証画面で配信するっていうのもちょっと考えたんですけど、
06:03
その場合もう1台PCがいるのでなかなか環境準備ができてないって感じですね。
そうですね。そこら辺は難しいところですねという感じではありますけども。
そうするとステレオ感とか、目の前にいる人たちが話してるんだ感がより分かりやすい音声データにはなる気はするんですけどね。
そうですね。確かに。画面もぐりぐり動いてくれた方がやっぱり臨場感が違いますからね。
そうですね。そうするとスタッフとして誰か1人、もう1人いるとか、カメラマンの人が喋ってる側にフォーカスしたりとか、そういうことにしたり。
そこまでできると、何でしょうね、私たちもキャラクターを動かしながら喋るみたいなこともできるでしょうし、まあもっとより良いのかなぁ。
そうですね。まあちゃんと番組感は出る感じはありますね。
結局ラジオに落とし込んでしまうと、そこら辺の情報全部切り捨てられちゃうんで、もったいないというかもったいないんですけど。
そうですね。
YouTubeでやってみる限りでは、リッチなコンテンツには仕上がりそうな感じはしますね。
あとはこれをVRゴーグルつけながらやったらどうなるかとか、少しやってみたいところではあるんですけど、
肝心のメディア情報を読み解くのに、VR上でブラウザを立ち上げてその画面を見ながら喋るって、目が死んでしまいそうな気がするので。
ちょっと難しいかなぁ。
まあそうですね。結構慣れが必要な感じだと思いますね。
まあその、聞いたか何かの記事で、そのVR環境上でひととり開発とか、ネットサーフィンとか全部やってみるみたいな、
そういう生活スタイルこうしてますみたいな記事が上がってたりするんで、まあ人によっては出来てるんでしょうね。
まあそうですね。まあその、環境に慣れてしまえばできるかもしれませんけど。
そうですね。その場合はあれですね、この番組自体1時間とかは言わずに15分番組くらいにして、
ちょっと1ネタVRゴーグル被りながらやってみるとか、そのレベルにしとかないとって感じかな。
あと下準備がかなり大変そうなんでね。そこら辺も考えないといけないですね。
そうですね。その場合、一旦その場合は多分ブラウザーの記事を読むとかではなくて、
なんだろうな、VR空間でお互いに喋りたいことを一旦喋る場とかから積み上げていかないと、最初からブラウザー用意してとか、
セッティングを頑張りすぎると心折れちゃいそうなんで、軽く始めたいですね。
09:01
はい。そこら辺はそうですね。積み足し積み足しでこの環境も結構いろいろ並列してアプリケーションいろいろ開いたりしてるんで、
そうですね。積み足しでやっていきたいですね。
そうですね。そうそう。このクラスター環境も今はこんな感じのポッタチでマイク1本真ん中に立ってる感じですけど、
例えばこの空間に自分たちが今ハマってるもののオブジェクトとか後ろに置いたりして、
本当に自分たちのスタジオ感っていうのを出せるようにアップデートはしていきたいなとは思ってるんで、
ちょいちょいそういうのを取り込んでいって、このリカログらしさというかパーソナリティらしさ的なところを盛り込んだ空間でやっていけるとより面白いかなって感じですかね。
いいですね。VTuberさんのお部屋みたいな。
そうそうそう。なのでちょっとずつUnityも勉強しながらって感じですけど。
はい。そんな感じのアップデートをしていったんで、一応年初に言ってた新しいものをやってみるのは1個達成かな。
そうですね。
という感じで、じゃあ今日の本編行きたいと思います。
1点目、GitHub Copilot LabというGitHubの公式記事ですと、
GitHub Copilotの拡張として新たな機能が追加されましたというものなんですけど、そもそもGitHub Copilotとは何かっていうところから説明すると、
開発者向けのAIペアプログラマーですと。どういうものかというと、ソースコードを書いているときにある程度まで入力すると、
このCopilotさんが世の中にあるいろんなプログラムの情報を元にこういうことを書きたいんじゃないですかって提案をしてくれますと。
で、その通りですって言って入力すると、残りのソースコード部分を一気にダダダッと作ってくれると。
よくソースコードではクラスとかメソッドの書き方として定番な書き方とかがあって、それを毎回手に入力しなきゃいけないってことで、
正直作業的なコーディングタイムっていうのも結構あったんですけど、そういうのを埋めてくれるサービスですね。
で、それのさらに発展形としてCopilot Labosと呼ばれる拡張機能がリリースされますと。
これがどういうことかというと、そうやって提案してくれたソースコードっていうのがあるんですけど、そのソースコードの解説をしてくれるという機能です。
ソースコードっていうのは、読み手のレベルによって読めるコード、読めないコードっていうのがもちろんあるんですね。
それは言語仕様がアップデートされて、より複雑な書き方に変わっているとか、より可読性を上げるための機能だったりはするんですけれども、
12:09
初めて見る人については、これが結局どういう振る舞いをするのかよくわからないみたいなことも往々にしてありますし、
そのCopilotの機能で提供された関数群というのが、世の中的には普通かもしれないけど、自分はそこまで学習が至ってないっていうケースも当然あるわけです。
そういったことが発生した場合、そのコードについて解説してくれる人がいないと、先ほど言ったAIペアプログラマーとしては片手落ちなわけですね。
ペアプロっていうのは、有識者と非有識者がいたとしても、その技術レベルをお互いフォローし合うことで均一化させるっていうことが期待される結果になるので、
こういうコードを書けばいいよっていうだけでは片手落ちで、自分が知らないコードを誰かが書いてくれただけになって、ペアプロの本来の期待値とは変わってしまうというところで、
このGitHub Copilot Labsではそこを解決するということを目的にソースコードの解説をやってくれますと。
このソースコードの解説をしてくれるということ自体が非常に画期的で、
ソースコードっていうのはあくまで何かの振る舞いを正しくさせる、機械がわかるように処理してあげるということに尽きるわけですけれども、
機械が読めることと人間が読めることは当然違うわけで、その解説っていうのがそのコードを理解する上で非常に助けになりますと。
もちろんその解説が出るということ自体がコードレビューとかにも助けになりますと。
例えばあるレビューがコードを読んで、ここはこうだろう、ここはこうだろうって理解しながらもちろんソースコードレビューをするわけですけれども、
そもそも本質的にこのコードがやろうとしていることはどんなことなのかっていうのをこのCopilot Labsで解説をしてもらえることで、
自分のコードレビューに入る前の理解にもなりますし、そこが大きく期待してた結果と乖離してるんであれば、
もうその時点でNGをはじけるということが言えます。
なので今までソースコードのレビューっていうタイミングで言うと、コンパイルが通りますかとか簡単な短大テストが通りますかっていうところが限界だったんですけれども、
この機能によってそれが意図通りですかっていうところの結果もレビューに投げる前にチェックさせたりとかそういったことができるようになり、
かつこの解説が正しいということは、ある程度のソースコードのドキュメント化っていうのも自動生成できていく可能性があるというところで、
これまでそのドキュメンテーションのためにコメントをいっぱい書いたりとかそういうこともよくあったんですが、
15:00
そういうのを一歩越えた新しい形でのインフラだなというところで、インフラというかプラットフォームですかね、だなというところで紹介です。
結構面白いですねという感じですけども。
前何か別のやつでもちょっと紹介があったような気がしますけど、AIって言ってしまうとざっくりするんですけど、AI分析補助ツールみたいな感じではあります。
ただやってることが結構面白くて、さっき言った説明するっていうのは確かに良いなと思いました。
やっぱりプログラム言語なんで言語化できるはずなんですけど、
特殊というか、人間としては自然言語、英語とかのほうが分かりやすいでしょうというのに対してそれを変換してくれるということで、
ちゃんとできているかどうかパッと見で分かりやすくなるというのは、
やっぱりネイティブの言語で説明してくれた方が分かりやすいよねっていうのは分かる話なので、
すごく良いと思います。
どこまで正確になるのっていうのはちょっとまだ開発段階かもしれないですけど、
パッと見で間違ってるよねとかでも分かるだけでも十分有用なので、
すごく良いかなと思っていますというところですね。
そうですね。最後おっしゃってくれたことが全てかなと思っていて、
そのソースコードを読み解く速度とネイティブで書かれた文章を読み解く速度って圧倒的にこうした方が早いんですよね。
なのでそのソースコードの細かいレベルの間違いを見つける以前にその早い高効率な形で対象を理解できるっていうのは非常に有用だと思いますね。
今回のこのGitHubのページレベルと単体メソッドレベルですけれども、
本来は複数のメソッドが関わり合ってという形になるはずなので、
そんな中で一個一個のメソッドを理解しながら進めようと思うと非常に時間がかかりますし、
脳内メモリーに他のメソッドがどういう振る舞いだったかっていうのを抑えながら読まないといけないので、
時間がかかればかかるほど難読になってしまうっていうところもありますから、
こういったのでどんどんどんどん、ここは別にそういう簡単な処理をするだけだったら見なくていいやとか、
そういうのをサクサクハンドリングしていけると強いなと思いますね。
そうですね。
確かにそのiとj間違えてましたみたいな細かいところは、これだと多分一発でわかると思うので、
18:02
そうですね。
そういうようですごくいいかなと思います。
あとはそうですね、2点ほど、要求仕様ショットの付き合わせがしやすくなるのはすごく良いかなと思いますね。
そうですね。
というのと、あと下の、この紹介してくれてるウェブページの下の方で書いたんですけど、
このコードを翻訳するというので、言語別のコードに変える。
例えばCの言語をPythonに変えるとかいうのが実験的にですけど入っているというのも、これもだいぶんいいなと思ってます。
やっぱり言語仕様として決まっているものがあるんで書き換えないといけないとかいうときに、
ただ書き換えって本当はやりたいことじゃないよね、やりたいことは処理をして結果が出てくることで、
そのPython向けの言語向けの仕様に書き換える、キーボードを打って書き換えるのって本当に、
なんですか、そこがメインじゃないよねっていうのはそういう話なので、
そこがもしソフトウェアによって保管されるのであればこれほどありがたいことはないなという感じですね。
はい。
そうですね。
最後のその機能については正直ですね、スクリプト系言語じゃないと厳しいだろうなとは正直思います。
CシャープとかJavaとか、コンパイル、ビルドが必要な言語になると依存関係が複雑化されすぎていて、
特定の対象の関数を誓うんとかやったところで、依存関係の解決がないと正しく変換できないと思うんですよね。
うんうん。
一方でスクリプト系言語はかなり、そこの一行でも実行できるっていうのが特徴なので、そういう意味で変換はしやすいと思いますね。
うん。
それでも変換できるということ自体は非常に価値があって、何かのユースケースというか、リバースエンジニアリング的に過去の資産を最新のものに変えなきゃいけないとか、
そういったタイミングでも活躍しますし、レビューアーにとって自分がよく知る言語で読み変えたいっていうことも全然あり得ると思うので、そういう助けにもなるかなと思いますね。
確かにそうですね。よく知っている言語で書いてくれた方が、書いてくれるとオブジェクトレベルというか、単体切り分けレベルでもやりたいことが分かるなっていう助けにはなると思うので、そういう用途としては確かにいいかもしれないですね。
そうですね。こういうのが進んでくると、おそらくコーディングする側もかなり書き方が標準化されていくというか、汚いことを書けば書くほどこういうツールを使った時の恩恵を受けにくいっていう結果になるはずなので。
21:08
確かに。
そういう意味で、こういう機能に乗っかろうとすればするほど、文章が綺麗になっていくというか、ところはあると思うんで。
標準的なコードの書き方っていうのが身につくかなというところですね。
そうですね。コーディング機法みたいなのはでっかいマニュアル書を作らなくても、こういうツールに乗っかってこういう結果が出ることっていうことを基準にしとくだけで、書き手は必然的にそれに合わせ込まないといけないっていうやつですね。
はい。という紹介でした。
次もマイクロソフト関係なので続けて言っちゃうと、マイクロソフトがクラウドPCのWindows 365をWindows 11に統合すると発表。ギガジンの記事です。
マイクロソフトさんが4月頭にいろんなアップデートを言ってたんですけれども、その一つとしてWindows 365をWindows 11に統合すると発表しましたと。
具体的に何がどうなるのかっていうところなんですけど、Windows 11をまず普通に起動しますと。
そしたらアプリケーションとしてWindows 365っていうアプリケーションがインストールできるようになっていて、それをぼちぼちいって開くとリモートデスクトップのような画面、ウィンドウが立ち上がりますと。
そこの中でWindows 365、クラウド上にあるWindowsですね。こちらが開くという形になっています。
従来だとWindows 365っていうサービスを利用した場合、この環境にこんな設定でアクセスしてくださいねみたいな形で、クラウド上にあるWindows PCにリモートデスクトップの接続機能とかあると思うんですけど、
そういった機能で入るのと変わらないような形だったのが、Windows 11からはもう特定のアプリとしてインストールされていることになるので、シームレスに入ることができますよと。
この場合の一番のメリットはセキュリティの観点ですね。
Windows 365の特定の仮想PCに入れる権限があるかどうかっていうのが、Windows 11内のセキュリティ情報で全部統合管理できるので、
今までユーザー名とパスワードのログインとか、いろいろやってたレガシーなセキュリティルールから一歩進んだセキュリティ状態でログインできると。
あとは専用の通信モデルをすると思うので、
リモートデスクトップよりも多分高レスポンスに、かつファイル転送等々、普段やるような作業をよりやりやすい形で利用できるということが期待されますと。
24:07
こういったWindows 365みたいな話っていうのは、今後もかなり進んでいくだろうと言われていて、
特にテレワークが進んだ今の環境だと、手元のPCにはあまり何も入れずに、クラウド上にあるPCだけで作業するという新クライアント化というのが叫ばれていますので、
その辺を支える技術になっていくんじゃないかなというところですね。
現状だと、新クライアント化ってすると、別の会社のサービスをWindowsに入れてセキュリティに保ったりとか、そういう形になり、
その辺がWindows OSとの親和性の問題とかがあって、なかなか重たくて使いにくいとかということで、
せっかくいいスペック、リソース群というのを無駄に使ってしまうというところがあったので、
Windows 11に投稿されるという結果、その辺が最適化されると、より世の中の人がセキュアに運用できるんじゃないかなというところですね。
あとは、もしこれがかなり使いやすいシームレスにできるという世界になった場合、
何かやりたいことがあるけどPCのスペックが足りないとなった場合、PCの買い替えではなくて、
クラウド側の仮想PCのスペックを上げるというだけになるので、新たなお金を大量に払ってPCを買い直すということはなくなりますと。
一方で、クラウドのWindows 365だとサブスクライブ型、定期購入型となるので、
普段の利用頻度がどれくらいかとか、その辺を含めた最適化、設定最適化というのを自分で行う必要があって、
例えば夜中は音色とか、そういうことが必要になってくるかなというところで、
普段からPC立ち上げっぱりに自信して、家のネットワーク回線の下でVPNサーバーとして立ち上げてみたいな、
そういうギークな使い方してる人にはちょっと向かないかもしれないですけれども、
一般ユーザーでたまにWindows PC使いたいときにパッと起動できたらいいんだよくらいの人であれば、
かなり世の中のスペックアップについていきつつ、最小限のお金でという形がより実現しやすくなるのかなというところで紹介です。
あとはおまけなんですけれども、Windows 11のアップデートでいよいよファイルエクスプローラーにタブ機能が標準搭載されるかもしれないということで、
非常に注目を集めていて、この点については私も非常に興味深くてですね、
昔からファイルエクスプローラーにタブ機能を追加するツールだとか拡張っていうのがたびたび出てきては消えしていて、
27:01
みんなタブが欲しいにもかかわらず、いいツールがなかなかWindows公式で出てこないというところで、
WindowsはいくらリッチになっていってもエクスプローラーだけはXPから変わらないみたいに揶揄されてましたが、
ここにきて大きく変わるかもしれないというところで期待大ですね。
まずクラウドサービスの統合に関しては、順当だなと思いつつまあ良いなという感じの素直な感想になります。
どっちにしろWindowsが開発しているのはそこの連携を強化するというのは成功法ですし、
認証周りとか扱いやすさというのが、やっぱ365を使っているユーザーとしてはちょっとローカルでやるよりコストが高いというか面倒くさい部分があるみたいなところで、
結局ローカルの方がいいじゃんみたいな感じというかストレスがあったところをそれを低減できるかもしれないというのは非常に良いと思いますねというところですね。
その後半で言ってたローカルPC側のスペックを低減できるかもっていうことに関しては正直どうなんだろうと思いますけど、
どうなんですかね。まあでもシンクラ化するという意味では実際そうなのかな。
気にしてるのはどういうレイヤーの話ですかね。
まあ確かにそのネットワークへ十分の速度で接続できて、
あとは入出力装置が応答性に問題がなければ、シンクライアントの端末としては成立するよねという話はそれはそうですので。
そう考えると良いのか。確かにそうですね。
私も確かに言われてみるとシンクライアントでストレスが溜まるのってシンクライアントというかサーバー側との応答性が悪さなんで、それって8割9割ネットワーク関係の問題なので。
そうですね。そこさえクリアできてればまあ別に確かに端末側ローコストでいいですし、何なら壊れたところで大した痛手にはならないというのはノートパソコンとかを扱っていると確かに思うところではあるので。
そこら辺やっぱいいと思いますねというところですね。
そうですね。シンクライアントについて不満に感じている99%、日本の99%は会社のプロキシサーバーがしょぼいっていうことに気にしていると思っていて、
会社のセキュリティ環境を担保するために会社独自のファイアウォールだったりプロキシサーバーを導入しなければならないと。
30:04
シンクライアントが何だろうが、そこを通さないとネットワークに出ていけないという社内統制、ガバナンスをそこで効かせたいという目的のために中央集権化しており、それによって著しくそのレスポンスというか応答性を欠いてしまうというのが課題だと思います。
ここで言っているWindows 365の魅力っていうのはむしろ個人利用の方かなと思っていて、企業利用よりも個人の方が今はPCの買い替えに課題があると思ってます。
世の中がタワーPCとか家のスペースが減ってきてたりとか、最新のグラボにしないといいツールやアプリケーション、主にゲームだったりとかについていけないとか、そういったことで買い替え頻度が高い。
でもどんどん半導体の値段は上がっていて、買い替えはしんどいというところに来ていて、それを仮想化して継続的に利用していけるというのは、よく3年や5年大きにPCを買い替えていたレベルの人にとって非常に大きいかなと思ってますね。
その環境であれば、プロキシサーバーとかそのネットワークのボトルネックになるようなものがない環境で利用できるので、FPSとか本当にコンマ何秒の世界で争っているゲームとかは難しいとは思うんですけれども、簡単な、そこまで要求されないゲームとかであれば全然問題なく遊べるような環境が提供できるんじゃないかなと思いますかね。
そうですね。ゲームに関しては確かに、ゲームのジャンルにもよると思いますけど、コマンド式とかの分かりやすい入力系であれば対応はしやすいかなと思いますし、確かにそうですね。それで十分成立しそうな気がしますね。
逆にネガティブなところで言っておくと、仮想系が使えないのが課題になる可能性があります。
VM、バーチャルマシンとか、その自分のPC上で仮想的なOSを立ち上げたりとかする、そういうバーチャルマシン環境というのがいくつかあって、バーチャルボックスとかVMウェアとか、WindowsだとHyper-Vとかですかね、その辺の機能があったりするんですけれども、クラウドPCっていうのはエティシでその仮想機能によって成り立っていますと。
なので、クラウド側にある仮想PCというのは、そういうバーチャルの機能上に立っているWindows PCと思ってもらったらいいんですけれども、その場合、さらにそこから仮想させるということができないんですね。
33:09
なので、Windows 365のPC先で先ほど言ったような仮想マシン、バーチャルボックスですとか、VMウェアといったアプリケーションを立ち上げて何かするということができないです。
それで一番板手を受けるのがDockerというイメージアプリケーションですかね。
ああいったイメージコンテナと言われているような技術というのは、仮想空間上に特定のサービス、アプリケーションを立ち上げていくというものになってますので、
こちらがWindows 365上ではなかなか使い切れないというところで、そういったものの開発をメインでやっている人はちょっと利用しにくいかなというのがあります。
確かにそうですね。
まあそこら辺も含めて、使える環境にちょっと制限はありますけど、一般ユーザーの使い勝手としてはそこまで制限を受けないはずという意味で、
先ほど一般向けの方がむしろポテンシャルがあるんじゃないのかという話をしたという話ですね。
その通りですね。
まあ確かにそれはそうですね。ちょっと込み入ったことをしようと思うと制限をかかっちゃう気もするので。
週1しか別につけない人とか、普段別にネットサーフィンくらいしかしないよっていうようなレベル?
たまにオフィス使いたいんだけどねくらいの人とかだとノートPCを普段分賃にしててたまに開くような使い方をしたノートPCの値段と比べるとだいぶ安く済むんじゃないかな?
まあ確かに。そこまで使わんけどなぁみたいな時に、
スペックサクサク動くパソコンを買うのはちょっともったいないよなっていうのはあるんでね。
そう。そういう人たちに出てきて、やっぱり頻度が少ないから多少スペック遅くて、使う時にガクガクしててもいいよ、もう晒しはないよっていうふうに諦めてる部分はあると思うんですよね。
はいはい。
そういうのを無くせるのは大きいかな。
まあそれを言うと、そもそも家のWi-Fiの環境があんまり良くなかったりするので。
それはありますね。
果たして画像マシンへのアクセスのポテンシャルを引き出せるかどうかという問題もあるかもしれないですけど。
確かに。それはそうです。
下手するとWi-Fiじゃなくて携帯回線経由とかの方が5Gが成立するとは良いかもしれないですね。
確かにね。それは全然あり得る話だと思いますね。
今の一般家庭、Wi-Fiしょぼいですからね。
36:02
そうですね。
はい、そんな感じですと。
そんなもんで。
タブはいいですか?
タブは私は使ってないですけど、言われてみると、言われてみんでもひたすらExplorerにコストをかけてるっていうのは事実なので。
そこはすごく期待大ですね。
使いがいはほとんどの動線にExplorerが存在してしまうので。
確かにローカルにデータを取ってたりするとどうしようもないので、Explorer経由で物が漁るしかなくなってしまうので。
すごく確かに無駄時間が発生しているのでね。
タブにしてほしいですね。
はい、じゃあこれはそんなもんで。
次は重機のやつですかね。
そうですね。はい、すいません。
じゃあ次は私の方から。
JR西日本人型重機ロボット工事用車両を融合させた鉄道重機開発という。
マイナビニュースさんの記事です。
JR西日本は15日、人機一体日本信号と共同で人型重機ロボットと鉄道工事用車両を融合させた多機能鉄道重機を開発していると発表しました。
工所に設置された多様な設備に対応する汎用性の高い鉄道重機を開発し、
これまで人の手を要していた作業を機械化することで生産性と安全性の向上を目指すとしています。
開発中の多機能鉄道重機はインタラクティブな作用で直感的な操作が可能となり、
操作者の操作とロボットの動きが連動し、
ロボットが受ける重みや反動を操縦者にフィードバックすることで操縦技術を容易に取得可能になるという、
形状によらない多様な部材の搬助を可能とし、
多様な状況の作業で使用が可能に、
人が地上に居ながら工場作業も可能となり、作業の安全性も向上するということと。
導入による効果として、対象作業の精進化による生産性向上、作業員約3割削減のほか、
対象作業での労災ゼロを目指す、2022年4月から試作技での試験を実施し、
2024年春に実用化、営業船での導入を目指すとしているという感じです。
どんなものなのかというのは、ページ行ってもらうと非常に分かりやすいんですけども、
39:02
クレーンじゃないな、なんて言うんですかね、こういう、
パワーショビルじゃない、
梯子車みたいな、地上で4つ足の固定足を出した上に、
パワーショビルみたいな横についている操縦席がありますと。
そこから梯子車みたいにたたんで伸びるアームがついていて、
その先端になんと人型の2本腕とカメラのついている上半身のタイプのロボット、
しかもでっかいものがついているという感じの見た目をしています。
これで何をするかというと、写真では例えばその線路の上にある電力栓というかとかの、
電柱とかに加工物を取り付けたりというのを2本腕でやっているという感じですね。
なので想定としてはその工序作業とかを人でやるんではなく機械でやりたいという要望だと思われますね。
確かに工序作業、人がやると結構危ない動作ですし、
しかも電力線が側に通っている、下手すると感電してしまうとかいうところで、
ロボット化することで安全性と作業効率をアップするというのは非常に理にかなっているかなと思います。
いや、これはかなり良くて、個人的に一番良いなと思ってたのは、
ロボットが受ける重みや反動を操縦者にフィードバックする仕組みがついていることですね。
カメラのついている環境でリモートに何か作業をするということ自体はおそらく今までもあったと思うんですけど、
結局フィードバックがないとうまく扱い切れないというところがどうしてもネックになっていたと思うので、
そこを乗り越えたことを前提に設計されているのは大変素晴らしいなと思います。
あとは多分このロボットだけで完結できる業務というのはおそらくそんなないです。
工所にある電線に引っかかりそうな木を伐採するとか、柱に何かものを据え付けるといっても、
この人型ロボットの手は挟むことくらいしかできない形になっているので、当然ボルトを締めるとか、
切った枝を回収するとか、そういったことは難しいかなと思いますと。
一方で、こういった蒸気で取り扱わないといけないような重たいものを工所に行く人間は別に持たなくていいと。
42:00
それを取り回す補助だけ人がやればいいっていう世界に変わっているだけでも十分良いかなと思いますし、
逆にそこまで行ったら逆にじゃあそれってそこからさらに人を減らすためにはどうしたらいいのっていう、
そこで見えてくる課題こそが次やるべきことになってくるはずなので、
まずこの第一歩、第一歩どころじゃないですかね。
なんか第十歩くらいを踏み出せているのは本当にすごいなと思いますね。
はい、そうですね。
最初のフォースフィードバック系に関しては、ようやく実用化できたかというのが私の感想にはなるんですけども。
一応研究面では昔からあるんですよね。
非常に昔から理論としてはあって、まあ何なら研究しているところもあるんですけど、
あまり実用化、商用化されていない。
なんで商用化されていないというと結局こうやってフィードバック元のロボットが動くっていう環境がなかなかなかったのが原因なのかなと私としては思っていて。
そうですね。
そういう意味ではすごくロボットに対するフォースフィードバックとしてはやっとかという感じが思われておりますというところですかね。
後半のところに関しては私としてはこれで完成形かなとも思っていますと。
っていうのはねじ締めとかもそうですけど、最終的な確認っていうのはやっぱり個人的には遠隔操作ではなくて人間がやった方が精度が高いのかなとは思います。
まあトルク管理とかでいいよねとかはなくはないですけど、こういうJRとかの安全性を重視するという現場では特に最終的には人間が確認しつつ様々な細かい手順を踏んで安全性を担保するという方が良いのかなという気はしているので、
そういう意味では最終的にゼロにはあまりしないんじゃないのかなと思っています。
ただ先ほどその物を持っていくっていう話があったんですけど、ここが私としてはやはり一番やりたかったところかなと思ってまして、公社に物を持っていくのってかなり手間だと思うんですよね。
そうですね。
これロボットじゃなければクレーン車みたいなそれこそ釣ってプランプランしている物を人がガイドしながら場所に持っていくみたいな動作になってしまうんですけど、それを2本腕でがっちりというか固定して吸い付けられるというだけでだいぶ作業性が上がりますし安全性も担保されやすいと思うので、すごく良いかなと思います。
45:06
そうですね。今の聞いててちょっと課題になってきそうだなと思うのは共同性ですかね。
うん。
人と連動しなきゃいけなくなるは、はいイエスだと思います。できればその辺も技術の進歩によって、このロボット以外に、これって線路の上で走行できるロボットとして建設されてるんで、このロボットがどいたら次の品幹用のロボットがやってきてみたいなのは全然いいと思うんですけど、そこら辺を置いておくとして、
人生を作業途中は人手と連携しながらやりますと、紐でぷらんぷらんくれて連れ下げてた代わりにロボットがやってくるだけっていう知観?プラスアルファーくらいの位置づけで効率が登場する場合、このロボットがハンドリングするものの近くに人がいますと、
じゃあそのロボットの制御を誤って人を殴ったりしたらどうするのかっていう問題が当然出てくるわけですけれども、そういった安全確保をいかにやるかっていうのが非常に難しくなってくるかなと、そのロボットの腕が何かに接触しそうになったらっていうところの制御はできると思うんですけど、
ロボットが持っているもののどこかが当たりそうになったらっていう制御は非常に難しいので、そこいった形で安全確保が難しくなると、一旦ロボットが離れているところで人が入ってみたいな交代交代、持ちつけみたいな感じでやるしかないっていうのがあると、ちょっと何でしょうね、何かが支えてないとロボットが勝手に手放すとそれだけで問題となってしまうような環境で、
ロボットが使えないとか制約が増えてきてしまうので、何かそこら辺をうまくカバーできる仕組みがあるといいなと思いますかね。
そうですね、そこに関しては運用の仕方でカバーするしかないのかなと正直思っておりますけど、固定されていない重量物を取り扱うという時点で、それはそもそも発生していることだと思っているので、ワーク自体が対象になってしまうので、
それは認識した上で現場で運用するしかないのかなと思っています。
あとは追加の要素としては、ロボット自体が人に危害を加える可能性と、ロボットの操作を誤ってしまう可能性というのはあるんですけど、ロボット自体が人に危害を加える可能性に関しては、操縦者との連携性かなという意味ですね。
そうですね。
そのために、オキラスじゃないかな、これVIVEかな、カメラつけてるんですという感じは一本ありますというのと、従来からして、重機の回転半径内に入るなとかそういうのはある話なので、それと何が違うのと言われたら同じですという感じもちょっとしますねと。
48:24
そうですね。
最後のワークを手放してしまう可能性とかに関しては結構自信があるんじゃないのかなと思っていまして、ちょっと実際の運用どうなってるかには分からないんですけども、
これ何だったかな、何かの展示会で展示してました上のロボットの部分。そこで展示場でお客さんを入れてる状態で何か3メートルぐらいの枠をこっちに持って行ったりとか、腕を振り回して試すつかめすしたりとかいうのを実演してたんですよね。
はいはいはい。
かなり手放すという危険性を加味した上で大丈夫という安全性がないとああいう展示しないと思うんですよ、さすがに。
はいはいはい。
その補充機構のロック性というか確実性に関してはかなり自信があると思います。
それは素晴らしい。
そういう意味でそこはロボットの性能面でカバーしてるんじゃないかなというのがありますね。
なるほどね。じゃあまあ、あとは表示系かな。周りの作業者とかにいかに表示するかだと思いますね。
物を完全に固定できているという意味のロック状態と、体勢、ロボットの今の腕の位置とかその辺を完全にロックしてもう動けませんという状態のロックと、その2つのパターンを周りの作業者にいかに通知させるかですかね。
そうですね。確かにそこの面はちょっといろいろバージョンアップする余地があるかもしれないですね。
あまりそのロボットの周辺に表示系っぽいのがないので、例えば腕の、まあ腕、手の部分はワークで付け替えるかもしれないので肘の部分とかにでかいライトをつけておくとか。
全然いいと思う。
あとそういう意味で言うと、操縦者がVRゴーグルをかぶってしまうと、操縦者自身の身の回りの環境の見渡し具合というか。
そうですね。
結構大変かもしれない。そこら辺の担保性どうするかなっていうのはありますね。まあでも操縦者、操縦席に入ってるからいいのかな。
操縦者がどこまでやってるかわかんないですけど、少なくともこのロボットのアーム部分については第三者が操作すべきでしょうね。
51:05
まあその場所確認とかはやっぱりそうですね、ロボット操縦者とは別にすべきかのという気はしますね。
そうですね。
周囲の状況把握ができてる人間と一人称でやってる人っていうのは別であった方が絶対いいと思います。
情報量が全然違うのと視野の広さが全然違うので。
この一人称視点のカメラがロボットについてますけれども、これをつける一番のメリットはその作業に集中しやすくて、情報が限られてるから精度高く仕事がしやすいっていういい面があると思うんですけど、
一方で上を振り回した時にどうなりそうかとか、環境把握性が非常に低いと思うんですよね。
うん。
で、そこを補うのはある誰かが両方の情報を知って上手くハンドリングしろっていうんじゃなくて、別の人がやるべきかなと思いますかね。
まあ流石にそれはそうするでしょうという感じで、そこも従来の重機操作と同じかもしれないですね。
従来は2人体制だっけ?
指示者がいて、例えば鉄骨を吊るみたいなのでも、重機の操縦者と枠を固定する人と、固定してるのを見て指示を出す人っていうのは別でやるもんだと思いますので。
ああ、そっかそっか。
そういう意味では従来のやり方を踏襲すれば問題はないのかなという気はしますね。
そうですね。
はい、まあそんな感じで、非常に将来性のあるというか、いろんな妄想が膨らむ重機なので、非常に良いと思いますという感じで。
はい、と思います。
はい、で次。ちょっと駆け足で行かせてもらいますけど、次。
新潟県阿賀町でドローンの配達実験を実施。診療所や薬局と連携して、処方医療品を想定した荷物を配送というタイトルの記事です。
実証では診療所と薬局と連携し、薬局から診療とオンライン服薬指導を終えた患者のいる診療所まで処方医薬品を想定した荷物配達を行うという感じです。
また、買い物弱者支援の物資輸送を想定し、地元スーパーからの日用品配達を行う。薬局から2箇所への新潟上映のルートは、ともに無人地帯での補助者なし目視外飛行、レベル3飛行となります。
54:04
また、そのうち1つは万越自動車道を横断するルートで、物資輸送を目的としたレベル3飛行での高速横断道路など、国内では初となるという感じのところらしいですね。
いろいろ写真がありますけど、1メートル、2メートルぐらいかな、のロボット、クワッドコプター、6腕のコプターですね。抱えるサイズのダンボール台ですね。
これを遠隔地に飛んで持っていくということをやっているみたいですね。
結構いろんな企業が参画してまして、KDDIさんとかでスマートドローンツールに接続したフライトオペレーションシステムみたいなところで、無人ではあるんですけども、オペレーターが安全性を確保しつつ運用ができるような感じでやってますというところです。
結構目的としまして、山間地域とかで医療の提供が難しいっていう街などでも需要がありますというところでやっているみたいですというところが一つ目です。
もう一つ同じような話なんですけど、日経新聞さんで、時速100キロのドローンが薬配達、トヨタ通称長崎の島でというタイトルの記事です。
こっちも同じような感じで、島なので予約品の提供が難しいところに対してドローンでやってますと。
こっちは飛行機タイプって言っていいんですか、羽があるタイプで射出材みたいなところから発射するという感じで提供するということをやってますね。
という2つの記事の紹介でした。
その所感として、結構ドローンでの実証実験みたいなのはちょこちょこやってたんですけども、ようやく活性化してきたなというのが実情です。
薬品配達も需要が高いですよね。日本としては分かりやすい話ですし、遠隔医療のインフラも整ってきたことで、そもそもやっぱり医者がいない状況というところにも届けられるというのは、
現実化するとベネフィットが大きいところだと思うので、いいかなという次第でありますというところです。
本当素晴らしいのは一言に尽きるし、完全に一か十まで同意ですね。
さらに私が思うところでいくと、本当に感想レベルですけど、インフラが進んでいって、デジタルインフラが先行してたんだなというのが分かるなと思うところで、
57:14
遠隔医療とかそういうリモートでのインフラが揃うと、結局物流が最後ボトルネックになって帰ってくるんだなという感覚ですかね。
結構日本は高速道路を含めてかなり物流インフラを力入れている方だと思うんですけど、国として。
それでも最終的に待っているのは物流というところがボトルネックになってきていて、
ドローンがそれを解決できる手段としてこうやって実用化が進んでいるというのは非常に頼もしいなと思いますし、
いろんな河川での老朽化とかそういった課題もある中で、平行して維持し続けるインフラとしても期待があると思うので、ぜひ頑張っていてほしいなと思いますね。
そうですね。インフラとして物流がボトムになるというのは確かにその通りで、SFとかだと薬合成システムみたいなのがあったりしますけど、そこまでは結構コストが高いですし、
そう考えた時にこういうドローンで配達というのは、逆にこれもSFに形突っ込んでますけど、こういうのが現実化してきているというのは非常に良いと思います。
やはり田舎ですとね、道があったとしてもそこまで配達するのに人を使ったりするという限界がありますし、
なかなか難しいところですよね。サービスの迅速性との整合性とかね、あったりするので、そういう意味でやっぱりここが唯一解になりそうな気もするので、良いと思います。
そうですね。あとは法整備周りは粛々と並行しちゃってほしいなというのがあって、空の交通整備がどこかで必要になってくるというのはもう間違いないですし、責任モデルがよくわからないというところもあると思うんですよ。
物資を落下させてしまった場合の物資費用だったり、それによって波及した他の事故、影響というところに対して、誰が責任を持つのかというのが法律上ある程度明確化されていた方がいいと思うので、その辺が並行して決まっていくといいかなと。今すぐじゃなくて全然いいと思うんですけど。
そうですね。そこら辺に関してはちょっと私は選びきれていませんけど、文中でもあったようにレベルが規定されていたりするので、そこに従って粛々とやればいいと思います。
1:00:02
一般化してしまえば、単純に道路で運転している車が事故ったのと同じような状況になると思うんで、カスタマーレベルでは保険とかで対応する話になるでしょうし、社会法整備が進んでいれば刑事面では設置すると思うんで、別にそれで良いかなと思います。
そうですね。多分車が初めて登場した時は車メーカーが全責任を負うだったと思うんですけど、今だと運転手が責任を持ってるじゃないですか。だからそういう変化がどっかでいるんだろうなと思ってるって感じですかね。
今は多分飛ばしてる人が全責任を負うになってると思うんですけど。
はい。
飛ばしたいと思った人が責任を負う世界に変わらないと、しんどくなりそうなんで発展が。
そうですね。それも込み込みだとは思いますけど、例えばこの薬品であれば薬品提供プラーみたいなサブスクリプションみたいなね、そういう契約が保険に投薬として付いていて、それの範囲内で提供するとかいうことになるじゃないですか。
はいはいはい。そんなんで良いと思います。
はい。って感じで頑張っていてほしいですというところです。
最後、農研機構さんのプレスリリースなんですけども、雑草の育成を抑制する会長型の稲を開発というタイトルの記事です。
農研機構は野菜稲の遺伝子を交配により導入することで、雑草の育成を抑制する会長型の稲を開発しました。
会長型の稲は扇状に広がった葉を持ち、従来の品種に比べて効率的に太陽光を遮ることにより、
これごめんなさい、ググったんですけど忘れてた。
水棟群落下の雑草の育成を半分以下に抑制しています。
また太陽光をより高い効率で受容できるため初期育成が促進されます。
加えて会長していた葉は育成後半には直立するので、従来品種と同様に収穫することが可能です。
今回用いた野菜稲遺伝子は収量や穀類品質、植民にはほとんど影響を与えないことから、
会長型稲を育種素材として活用し、日本の各地で栽培されている様々な品種と配合することで、
雑草育成力に優れる水棟の実用品種の育成が期待されます。
会長型稲とは何というか、写真を見てもらうとわかりやすいですが、
従来の稲は田んぼに列揃って生えます。
で、成長すると稲穂とかが上に成長する感じなんで、
列と列の間にいくらか地面が見える状態ですね。上から見ると。いくらか地面が見える状態で成長してましたと。
1:03:09
いうのに比べて会長型稲って横方向に放射状に育成初期で葉っぱが広がるんで、地面が見えない状態になることで、
雑草を育成するという感じらしいです。
これすごいなと思ったのが、野生稲の遺伝子を交配することでこういうことができるんだなっていうのですね。
そこにつきますけど、結構やっぱり雑草に栄養を吸われたりするのが難しいですね、みたいなのは。
散々言われてたことですけど、それを遺伝子、しかも人為的に遺伝子をいじったんじゃなくて、
野生稲の遺伝子交配により整理させるっていうのは素晴らしいなと思ったような紹介になります。
いやー、めちゃくちゃ取り扱いの難しい話だなと正直思っていて。
まず技術的なところからでいくと、稲っていうか、
野生稲のような形をしてる草っていうのは、周りの周辺の雑草より背が高くなって光を受けるっていう形の戦略として、
背を伸ばしていったって認識してますと。
なのでその野生稲の情報がその開き方、横に広がる方っていう事実自体が意外だったなっていうのがまず思ったところですと。
その次に課題になってきそうだなと思うのが、まず従来型と形状が違うんで、従来のコンバインとかそういったものがうまく取り扱えない可能性っていうのが一つと、
つく穂の形ですね。今稲って穂は垂れ下がるようにつくっていうことになってるので、あの穂の高さっていうのが変わったりすると穂によっての品質ばらつきが多くなってしまう。
あとは水に近ければ近いほど水からの害を受けやすくなってしまうとかもあるので、
改調型稲になるにせよ、ある程度その穂のつき方っていうのに均一性を持たせたくなってくると思いますというところで、その辺のバランスがうまく取れるのかなっていうのがちょっと気になったって感じですかね。
そうですね。最初の直立してた方が成長戦略して良かったんじゃないという話は、一部というか状況によるという感じっぽいですね。
1:06:03
詳細のところで一部書かれているんですけども、前提としてそもそも後半の件に先に行ってしまうと、最初は改調型で広がってるんですけども、
収穫期には現状のやつと同じような立った形になるので、おそらくそこは問題ないと思います。取扱いとして現状の品種と同じような取扱いができると思います。
なんで後半的にそういうことになるのかという話なんですけども、そもそも初期状態、葉っぱの数が少ない成長途中では広がった方がいいんですけど、葉っぱが増えてきた穂の生成期は広がってると逆に光を遮断するので、
効率が悪くなるので直立した方が効率的に光を受容できることによって、という原理というか状況があるので成長すると勝手に立つようになりますと。
という話らしいです。ということで、それを言うと、この改調型イネは初期状態、成長途中でも吸収効率が良くて、成長後でも吸収効率が良いということらしいですね。
すごいな。
で、なんでそれがなくなったかというか、初期状態はなんで野菜イネとしてはそっちの方が良かったんですけど、栽培化していく中で最初に広がるというよりも安定して、上の方に伸びた方がいい米が手に入ったんで、
そっちの選択性が推進されちゃった結果、改調型イネの遺伝子がなくなっちゃったという話だと思いますね。
なるほどね。
あとちょっと気になるところで言うと、水田との相性ってどうなんでしょうね。
まあ、これでも問題ないんじゃないですか。
水棟って言ってましたけど、それ自体が水田ですから。
日本の水稲作の前提で、使う前提で問題ないんじゃないですか。
要は葉っぱが水で使って根腐れって言わないな。腐っちゃうんじゃないみたいなのは問題ないと思いますけどね。
あれば全然いいと思うな。
いや、本当に何か良いことしかなさそうな気がして、ほんまにって思ってしまうくらいなんで、ちょっと色々気になっちゃうって感じですけど。
1:09:06
まあ、そうね。
あとはあれか、成長3段階のタイミングがどう変わるかとかかな。時期的な話だけど。
植物って大きくは葉を増やすタイミング、葉を伸ばすタイミング、実を実に溜めるタイミングっていう感じで分かれると思うんですけど、成長のフェーズが。
そのフェーズがどういうハンドリングになるのかっていうのは若干気になるかな。
その辺は単純に時期ズレだけしかないですっていうことだったら全然それはそれでいいと思うし。
今まで水田で、さっきの海鳥型でない?縦にしか伸びてないっていうところだと、栄養を取り込みにくい状態で成長してたってことになるので、多分成長速度が遅かったわけじゃないですか。
ってなるとその水の張る期間だったりとか、今まで水田の操作してたその時間間隔っていうものがそれに適応して設計されてたはずなんですよね。
そこが変わるってことなんで、ちょっとその辺の影響度がどこまでなのかっていうのが気になる感じかな。
どうですかね。実験の参考図を見る限りあまりそのタイムラインの変化は変えてないっぽいですね。
へーそうなんだ。すごいね。
その移植後日数、大体80日後ぐらいに出放期を設定されてて、それは同じタイムラインで線横軸引いてるんで。
へー素晴らしい。
それは変わらないっぽいですね。
マジ?こんなにいいことしかないじゃん。最高じゃん。
最高ですねという感じで。
へーマジか。すげーなこれ。
そうですね。あえてわざとナクセをつけるとしたら、出放期周辺で立ち上がるとは言ったんですけど、
その最終的な立ち上がり具合は一緒なんですけど、出放期周辺での立ち上がり具合が腰光に比べて低いんで。
その分、なんて言うんですかね。ここワンポイントでちょっと光の需要レベルが下がってるかもしれない。
あとは好みの問題なんですけど、腰光に比べて腰とか粘りが低めのポイント数になってるんで。
1:12:02
そこら辺の味的にあまり好みではない人がいるかもしれませんけど。
まあそれについては正直、臨時改良レベルなのと。
まあそれこそあれじゃないですか。ものが変わったのに育て方を変えなかった弊害だと思いますね。
そうですね。T-Zipに関しては正直、変えられない部分もあるんじゃないかなと思いますけどね。
あると思う、あると思う。だからこそ、そのものが変わってしまうことの影響が大きいんじゃないかという懸念をしたんですけど、意外とそうでもないってことが分かったんで。
意外と普通、腰光基準なんで、日本で腰光が栽培がデフォルトなのかもしれないですけど。
ただそうですね、田んぼでもここの田んぼなんかこの週で買ってるけど、2週間後にこの田んぼ買ってるとかいろいろあると思うんで、その調整範囲内に収まるんじゃないですか。
全然いいんじゃないですか。
日本のむしろ腰光とかは味にかなり特化してるというか、めちゃくちゃ極まってるところがあるんで、それが多少劣化しようが全然気にならないような気がしますけどね。
そうですね。
いやー、こういう劇的な改良って、よく開発フローとかいろんなところに影響が波及しまくって、乗り換えが困難っていうことがよくあると思うんですけど、そこに弊害が少なそうっていうのは個人的にすごい素晴らしいなと思いますね。
そうですね。従来工法でできるかなっていうレベルなんですかね。
こったんがSDGsとかありますけど、こういうのを頑張るのにめちゃくちゃ追加で料金払わなきゃいけなくて、最終的に一般の消費者のお財布に反映されてしまうってなるとしんどいところあると思うんですけど、そうではないっていうのが素晴らしいね、本当に。
まあまあ、現場レベルだとやっぱり細かい点で特性が違って、ちょっと扱い方を変えないと、気にしないといけないところを変えないといけないなとかあるとは思いますけど。
絶対あると思いますよ。植える前の稲の管理場所の広さとかね、変わるはずだし。
なので、そこら辺はあるかもしれないですけど、実用できるレベルではあるでしょうなというところが期待できるのと、
あと先ほどちょっと言いましたけど、面白いのがSDGsとかですね。そこら辺に関わってきて、しかも遺伝子導入で結果が出るというのがすごい面白いなと思いますし、
最近、アイガモ農法とか原農薬栽培的なのが付加価値を確立してきている中で、雑草の育成を抑制できる巣の状態でっていうのはすごくポテンシャルがあると思うので、非常にいいですねという感じですね。
1:15:22
そうですね。いわゆる農家芸の方のお言葉的に言うと、有機栽培やアイガモ農法っていうのは完全に自己満足でしかなくて、一般的にはそんなにエコでもないし環境にいいわけでもないっていう。
そう言われることが多いですけど、こういったものがどういう評価を受けるのかはすごく楽しみですね。
そうですね。もう稲自体でも成立するんだったら、それはどうなのという感じなので。
そうそうそう。パッと見はそういうなんか批判にさらされなさそうな開発ですよね、これは。
そうですね。まあその土の吸収量の問題とかいろいろあるかもしれないですけど、わかんないですけど。
わかんないね。まあだから光が遮られるということは植物プランクトの活動は下がるはずで、水中地素量が減るんですよね。
まあわからんでもないけど、そこはうーん、まあわかんないです。
わかんないです。だからそれがどこで影響するか読めないなと。
どこで影響するかわからない。どちらかというと私は虫害とかに弱かったりする可能性があるかなと思ったんですけど。
ああ、それもわかる。歯が近くなるってことは水辺にいる虫とかからの影響が大きくなるっていう。
とかの影響とかが浮きやすくなってすんのかなとか思ったりもしましたけど、まあそこら辺も含めてね。
雑草を食べられなくなったからもう稲にかじりつくしかないみたいになるけどね。
結果としてなんかこう稲にダメージがいきやすくなったりする土地もあるかもしれないとかね。
そうそう、それもわかりますね。
あるかもしれないですけど、そこら辺実際やってみて運用どうのこの話なので。
スペック的には全然ポテンシャルはあると思うので非常に良いと思いますと。
それに最適化していけばいいだけなんでね。全然いいと思う。
はい、じゃあ今日はそのとこですかね。
はい、本日の内容はそのとおりまとめていますのでご確認ください。
リカログではご意見・ご感想やこんなことをお話ししたい方はお待ちしています。
メールアドレスはリカログアットマクジーメール.コムになります。
ツイッターもやっていますのでフォローやダイレクトメッセージもお待ちしています。
本本編はPodcastをSpotify、YouTubeライブで聞くことができます。
ぜひそちらでもサブスクライブよろしくお願いいたします。
はい、ではお疲れ様でした。
はい、お疲れ様でした。
