00:00
はいどうも、kokorokagamiです。 東電です。
今週も1週間振り返っていきたいと思います。 はいはい。
今週一番大きかったネタはTwitterの買収ですかね。 まあそうですね、Twitter界隈すごくざわついてますねという。
そうですね、メインメディアが我々としてはTwitterなので、もうTwitterに騒がれるとそれしか入ってこないっていう悲しい状態になってしまいますけど。
まあどうなんですかね。イーロンさんが買収しますっつって、しかも従業員をなんか大量解雇、半分以上解雇したみたいなところがあって、
大激震が走っているという感じですけど。 そうですね、日本だと広告関係の人が全員解雇になったとか、そんな話が出てましたね。
まあ今までとやっぱりマネタイズの方向とか色々変えたいっていう話なんでしょうね。
なので一旦リセットして、インフラは引き続けてリセットして、イーロンさんのやりたいようにもう一回ビルドし直すという感じなんでしょうね。
そうですね、あとはTwitterとしてそのマネタイズモデルのスケールに比べてエンジニアのスケールがあまり伸びてないっていうところがあったんじゃないですかね、イーロンさん的に。
えーと、というと何、人が多すぎるという話? そうそうそう、出している商品サービスの規模に比べて抱えている色んなエンジニアだったり、まあ労働者か社員が多すぎる。
あーなるほどね。まあ確かにそれはそうな気もするなぁ。
今までのTwitterって結構そのマネタイズモデルが広告を出してもらって、それでお金をゲットするって感じだったと思うんですけど、
まあ確かにそれだと各広告会社、広告会社というか広告を出したい会社ごとに接種が必要なはずで、
まああまりコストパフォーマンス良くないという気はしますね、そういう意味でと。まあなので、今騒がれている本当かどうかわかんないですけど、
もうでもアメリカでは始まっているらしいですけど、ツイッターブルーっていう有料というか、
サブスクモデル、7ドルだか8ドルだかっていう話ですけど、あれだとユーザーがカードとかで払って、クレジットカードとかで払ってくれれば、
クレジットカード会社経由で一括で手に入るんで、まあそういう意味では広告とか営業がだいぶ圧縮できるというのは実際そんな気はしますね。
あれはもともと公認マークという位置づけで、全く不透明な仕組みではあったんだけれども、
私がこのアカウントの本人ですってことを申請したらバッジがつくみたいなものでしたと。
03:01
ただその審査基準が結構不透明で、明らかに有名な人でも通らなかったりとか、逆に全然知名度ないけどポンと通ったりとかで、もう基準が全然よくわからないと。
まあ最初の頃にやってたら取れてるみたいなこともあったりして、あのバッジの価値っていうのが全然高まってなかったっていう中で、もうガラッとそのバッジの意味を変えたっていうことですね。
あの意味合いとしてはもうほぼBotではありませんくらいのイメージになった。
まあBotではありません。まあどちらかというと有料ユーザーですなのかなと個人的には思います。
まあBotもぶっちゃけ買えるとは思うんですよ。
あのBotの管理者が支払えば。
まあそうですね。
まあただ、それでBot判定をくらったら多分8ドルで募集されるんで、
まあ割に合わんなという感じで、業者としてのBotは結構バッジを持ってなければこいつはBot棚という判定をくらいやすくなるという意味ではあるかもしれないですね。
そうですね。あとはまあ、もう本当にお金出してでもやりたい攻撃的なアカウントしか残らなくなるかな。
誘拐犯とかいたずらレベルの話はなくなってくるので、まあYouTuberとか有名な人あるあるですけど、同姓同名のアカウントが乱立している問題ですね。
はいはい。
とかもちょっとは抑えられるかもしれないですね。
そうですね。まあそこら辺はいいかもしれないですね。
まあその企業アカウント、まあYouTuberは企業、まあ非企業言いますけど、仕事としてやるレベルだったら別に8ドルぐらいいいと思うんですけど、
まあただそういう意味で言うと、個人で使用しているけどある程度著名な人に対して8ドル払うかって言われるとちょっとうーんという感じもあり、
そうですね。まあそういう人もTwitterを通じて個人の価値っていうのを発信したいと思っているのであればTwitterのプラットフォームを正しく利用したい人だから有料ユーザーになってくださいねっていうことなので、そんなに悪くはないかな。
まあ確かにそれもそうか。
あのそうですね。YouTubeでそれなりに高再生数がある人はお金払ってちゃんと管理してくださいっていうのと一緒と言われればそれはそうですねという感じなので。
そうそうそうそう。
まあIT系の第一人者とかでTwitterでいろんなテック的なことを発信してる人だったりとか各会社の公式アカウントだったりとか、まあいろいろ発信することで周囲に自己価値を提供してる人たちはやっぱりこの8ドル払う価値があると思って利用してるんじゃないですかねTwitterを。
06:24
まあそうですね。
まあ確かに特に企業アカウントとかはそうだと思うんで、まあそこら辺は必要経費だなと。
まあいいんじゃないですかそういう意味では。
私も基本的には賛成ですね。
もちろん中の人はねだいぶひっかき回されてると思うんで、困ったっていうのはいっぱいあると思いますけど。
まあなんか、まあ日本支部は置いといても本社の方が訴訟してまでこうイーロンさんに買ってもらってその結果社員が大量解雇されるっていうのもなんか、どこに落ち着きたかったんやっていうところがすごいありますけど、まあまあ現状でも買ってるんでね、もはや何も言えないと思いますけど。
まあ今後の期待としては、結構イーロンさんの持ってた各会社っていうのはその技術でぶん殴る系の会社が多いじゃないですか。
その営業力とか広告力とか、その何だろうな、いろんなところと提携してだったり政府に認めさせたりみたいなその社会的折衝を積み重ねていって受け入れられるようになって提供するっていうよりかは、
こんな技術でできるようになったんだぞ、お前らすげえだろっていうその技術でぶん殴る系だったので、ツイッターがそういう方向に変わってくれるとちょっとSNSとしてまたひとかを向けた何かが出てくるかもなーっていう期待感はありますかね。
まあ確かにそうですね。確かにそういう意味では、そのSNSとしてもおはやインフラ化していて、アメリカの選挙も今度ありますけども、そこら辺にも影響を及ぼすと言われているレベルになっているんで、そこの問題点を技術で解決するSNSですという、価値提供は絶対お出しできると思うのでね。
まあそうなってくれると嬉しいかなというところですね。
はい。じゃあ枕としてはそんなもんですかね。
はい。
じゃあ本題の方行きたいと思います。
1点目、OpenSSLの脆弱性対策についてということでIPA、情報処理推進機構の記事です。
OpenSSLはSSLおよびTLSの機能を提供するオープンソースのライブラリーです。
このOpenSSLにおいてX.509証明書の検証処理を通じてバフオーバーフローが発生する脆弱性が確認されています。
本脆弱性が悪用されると攻撃者が用意した悪意ある証明書によりオーバーフローが起こされ、結果としてサービス運用妨害や遠隔からのコード実行を行われる可能性があります。
09:10
今後被害が拡大する可能性があるため早急に対策を実施してください。
ということで、世界中でありとあらゆる場所で使われているOpenSSLの脆弱性が見つかったぞということで、一時期ものすごくホットになった話です。
今はかなり鎮下しています。それの経緯とかを少し話したいんですけど、
まず、OpenSSLについてですが、今話した通りではあるんですが、SSL、TLSの機能実現で使われているライブラリです。
もっと広く言うと、皆さんがWebブラウザ、ChromeとかEdgeとかそういったところでホームページにアクセスしたりするときに使われているHTTPSというプロトコルでは証明書を通じたセキュリティ認証というのが行われているんですけど、
その証明書を使うにあたって、その証明書を発行したりとか、その証明書の中身を検証したりということを行っているライブラリになります。
OpenSSL以外にももちろんいろんな証明書検証のものはあるんですけれども、
OpenSSLのオープンというところから無料で使えるということがあるので、いろんなところで手軽に証明書運用を始められるという価値がこのオープンソースのライブラリにあり、あらゆる人が活用してきたということですね。
歴史も結構長くて、それこそSSL、TLSとかそういったものが開発され、世の中に提唱されだして以降、すぐさま登場してLinuxベースのサーバー環境ですとか、オンプレの短い範囲のライブラリだったりとか、そういった環境とは、
本当に証明書とかセキュリティ専門ではない一企業の出す商品でHTTPSとかセキュリティ対応するとなった場合にもよく登場していたライブラリですということで、非常に多くの範囲に影響し得るものでした。
結果的に今進化している大きな要因としては、対象となるその脆弱性が見つかったバージョンというのがOpenSSL 3.0.0以降から3.0.6までの間のバージョンになりますと。
これらのバージョンというのがかなり最新のものになっていまして、OpenSSL自体はかなり昔の1.1.1で十分ほとんどの機能が含まれていて、それ以降のバージョンを使う理由というのが、よっぽど特殊なことをしない限りなかなか出てこないということで、
12:07
標準インストールされるものはだいたい1.1.1だったりとか、1.0.2という古いものがインストールされることがほとんどでした。ということで、このニュースを受けていろんな会社さんで調査をされましたが、
あまりこの対策について、うちはこうやりましたとか、いつまでにアップデートかけますみたいな話が全然出回らないのは、ほとんどがこの古い1.1.1とか1.0.2が使われているという事情からあまり大きくはならなかったというところになります。
はい。ただこれが本当に全体に及んでいたら、今頃、これ自体は11月2日の話でニュースが出ていますが、今になってでも相当大騒ぎしていた致命的な話で、
セキュリティ関係のライブラリーで、このライブラリーを使ってセキュリティ田んぼできてますとか証明書がチェックできてますって言い切ってたインターネットの世界だったので、ここに致命的な脆弱性が含まれているとなった場合は、全世界のあらゆるセキュリティを見直すという話になり、
経済損失いくらで水漏れはいいのかわからないような大事故というところや、あわやなりかねない話だったので、紹介ですというところですね。
はい。
いやまあ、1.いくらを使っている人はまあ問題なかったということで、まあまあまだマシだったという話だと思いますけど、まあそうは言いつつも、まあ仕方がない、気づかなかったんで仕方がないのは仕方がないですけど、難しいですね、経済損失いくらの話になってしまうと、と思っていますというところで、
難しいですねっていうのは、前回なんか似たような話があった時にもあったんですけど、オープンソース系だと誰も責任を取れないんですよね。
そうですね。
まあそれがいいところでもあり、その分パッチが当たる速度というか、コーチ能力によってマンパワーで完成度を高めるという方針なので、まあそれはそれでいいんですけど、
実際こう問題になった時に、じゃあどう、なんていうのかな、自社製品に適応しました、まあそれでコスト全然追っかかりましたとかいう話になった時に、まあ自分の身を切るしかないというところがあるのがもうどうしようもないかなというところですね。
15:00
そうですね。
まあその辺は、やっぱりソフトウェアを外製品に頼っているリスクっていう話ですね。
そうですね。まあでも前回も言いましたけど、前の時も言いましたけど、まあそうしないとでも競争性のある商品にならない、コストがかかりすぎるっていう話だったと思うので、まあ仕方がないと言えば仕方がない。
なので、まあ一エンジニアとしてできるのは、こういうことがなった時に何とかパッチを当てられる、その環境を整えておく必要があるのですねという感じなんですけども、まあでもそれは難しいんかな、どういうパッチの当て方すればいいかわからんみたいなのがいっぱいあると思うんで。
そうですね。結局バージョンってこの問題以外についてもいろいろ上がってるからバージョンアップなのであって、自分たちのシステムに対してそれらの他の変更っていうのが問題にならないのかどうかの検証が必要になってしまうので、なかなか大事ですね。
うーん、まあでも検証もなあ、オープンソースだから大丈夫って使わざるを得ないんだったら検証もできねえ、できねえというかコストに見合わないでしょうっていうのが正直なところだと思いますけど。
そうですね。まあそれで納得できる顧客がいてくれればって感じだな。
まあこういう問題があって一番困るのはやっぱりエンジニアではないけれどもこの問題についてお金を払った人にどうやって説明するかなんですよね。
はいはい。
まあ社内で引き取るんだったら多分経営層とかに説明しなきゃいけないんですけど、この問題が発生しましたと。
これは外部のオープンなライブラリを使っていてそのライブラリのアップデートに不具合がありましたと。
最新版では対応できているのでアップデートをかけます。
アップデート後の動作検証は基本的にそのバグの修正が本件で行われているはずなので、私たちは見れないし見る必要もありません。
今回発生した問題っていうのはこの例だけで言えばバファーオーバーフローとか例外的な処理なので通常の処理には影響がありませんっていう説明をするわけですけど、
技術的には正しくても多分経営層的には想定外の出費が大きすぎるので再発防止策なりなんなり、
少なくともその発生リスクに対して事前に動ける体制だったりとか何か講じておかないと次これが来たらやばいなっていうので何か指示を出したいっていうモチベーションになるはずなんで、
18:03
そこが正しくハンドリングできなくて何か意味のない対策だけ生まれていっちゃうっていうのが辛いところですかね。
よくある話ですねという感じですけど、そう言ってしまうと他の業務も変わらないなという感じがする。
要は外から買ってきたものでちゃんと納入検査して納品されたはずなんですけど実は不具合がありました。
じゃあそれでも市場に出しちゃったんで回収するかしないかいろいろ対策あると思いますけど対策必要です。
やっぱそれと結局一緒じゃないですかという話で、それで自社としてはこういう対策を取りましたっていうのが意味のない無駄にコストがかかる対策、チェックシットみたいなものになるかどうかっていうのはオープンソースを使っているか使っていなかろうが発生していることなんで、
そういう意味では自社としてはまあそうか結局変わらんかなっていう気がしてきましたね。
原因が実績じゃないんだけど大概的には実績として表出させなきゃいけない問題なんですよね。
なんで自社としてはやはりあれですね、さっき言った通り何かあった時に巻き取れる、手元で巻き取れる範囲で巻き取れるようにしておくというのを仕込んでおくというのがやはり制作段階で意識しておくっていうのが必要かなというところですね。
まあどうなんですかね、でもここらへんそう言ってられないようなところまで組み込まれちゃってるんじゃないっていうところがありそうな気もしますけど。
おっしゃる通り、こんなOpenSSLになるともうすごく当たり前レベル、なんならそのOSI参照レベルの下の方とか言っても不思議じゃないくらい普段全く意識しないレイヤーの概念の話。
になってきちゃうので、どこに入ってるかなんて多分設計にも表出一切しないです。
仮にセキュリティリスクシート、こういうことが起こり得ますみたいなリスクシートを設計段階で行ってたとしてもこんな話は登場しないと思います。
まあなので実際の納入したものにどこまで入ってるか分かんないみたいなことになっちゃうと、かなりコストかけて足をかけて現場に見に行くみたいなことにしないといけなくなるかなというところですね。
21:05
なかなか大変やな。
まあそういう意味ではそこが再発防止策なのかもしれないですね、今後の。
ちょっとちゃんと手元に残しておく?
ある意味ではここを突き詰めていくとFAとかそういった世界の仕掛けみたいなのを再導入する話もあるといえばあって、今はSボムっていう言葉が出始めていて、
ボムは部品のリストの話ですね、でSはソフトウェアで、ソフトウェアボム。
で自分たちが使っているソフトウェア部品を全部釣り場にして見える化しましょうと。
でそれらの部品のどこに課題があったらどうしますかっていうのをハンドリングできるようにするもの。
で今までリアルで行われてたボムで言えば、例えばある部品のロット不具合とかがあって、
それって1年に1回とか、1年に1回も起きないか、5年に1回とかそんなレベルでしか起きないけど、
それが起きたら大体部品どうするんだとか、そのロットの回収どうするんだとか、一応動ける体制を組んで商品リリースしてると思うんですよ。
なのでそれと同じような仕掛けをこのソフトウェア開発、セキュリティ対策にも持ってこれないかっていう議論はされてたりしますね。
まあいいですね。そこら辺やっとくべきな気がしますね。確かにこういうことが起こるんです。
まあまあ、皆さん気をつけましょうというところなんですけど、最後に1点だけ、今回古いバージョンだったから大丈夫でしたって話をした通りですね。
バージョンを上げればとりあえずいいっていうものと、バージョンは上げない安定版を使うべきものっていうのが、
ソフトウェア上混在することになるので、ITを学び始めた人あるあるなんですが、とりあえず最新にしとけばいいっていうような、
安易なアクションっていうのをセキュリティに持ち込まない方がいいですっていうことですかね。
まあでもそこも難しいですよね。機能拡張しようと思った時にやっぱ最新版じゃダメだよねって言って、
リビルドのコストがかかるとかいうところもあったりしそうだなとか思っちゃうと最新版を使いたくなるとか、
あるとおきますけど、まあそれを考えるのであれば安定版、しかもこれバージョン3まで出ててバージョン1が安定版なのですとかいう話なんで、
なんかこうメジャーバージョンアップだったらメジャーバージョン使っとくかみたいなところになりそうですけど。
まあその感覚の方が多分自然で、1.1.1今回当たり前に使われている、それが普及してたって話しましたけど、これのリリースタイミングはかなり前なので、
24:09
その何も知らない人が新しくOpenSSLのバージョンを選定するっていう作業を行った場合に1.1.1を正しく選べるかというとかなり怪異的ですね。
まあそこが技術力になるかもしれないですけど、なんで内部仕様まで把握した上で安定版は実績側のこれですって選べるならいいですけど、というところで。
そうですね、そういうことって結構学べるタイミングが少ないので難しいなと思いますね。
下手にじゃあ安定版ですって、部内の指示みたいなのをサクッと出してしまうと何も考えずにずっと1.0.0みたいなのを使い続けていって、
でなんかキャッチアップできないみたいなね。将来的にリスクになり得るからそろそろ交換しようみたいなところにキャッチアップできなくて、なんかセキュリティリスクになるみたいな。
EOLリスクであるんですよね。もうそのメジャーバージョンはすごく安定版だったけどサポートしませんっていう。
そこに新しい脆弱性が含まれたとしてももう知りませんよっていうことに、どっかのタイミングでなるので、安定版にしがみつき続けるのもおっしゃる通り開発上懸念があるんですよね。
懸念があるはあるですけど、まあなんで製品の寿命と関してEOLがいつ出るかわからんしなみたいなのもありつつのっていうのもありますし。難しいなぁ。
はい、というところで皆さんお気をつけください。
次私の方から、ついにライトニングが廃止、Apple幹部がiPhoneのUSB-C搭載発表という、旅ラバさんの記事になります。
iPhoneのUSB Type-C、USB-Cコインで組んだの搭載は多くのユーザーから長年待ち望まれていたものの、同社はオリジナル規格のライトニングの継続を押し通してきたところが先日、ついに幹部が新型iPhoneにはUSB-Cを搭載する方針を発表。
ということで、前回どこかで、このラジオでも一回紹介しましたけど、EUの規格で携帯だけじゃないかな、ライトニングやめてUSB-Cに統一しましょうというのがEUの規格としてお勧められていて、それが可決されましたと。
ということがあるので、次に発表されるiPhoneはさすがにUSB-Cになるでしょうということが紹介されていますと。
で、これも前回話しましたけど、技術的には残ってもいいような気もするけど、顧客的には面倒くさい限りなので、USB Type-Cにしてくれた方が嬉しいなという話ですね、という感じでありますね。
27:19
いやー、流れとして理解はできるんですけど、そもそもEUの方針にあまり賛同してないという点と、もう一つ、USB Type-Cにも規格が乱立しまくっているので、統一されたことによって逆にユーザーは不幸になってないのかという懸念がありますね、技術的には。
そうなんですよね。通信だけならまだしも通信速度とかね、パワーデリバリー、電源、充電するための供給電力量、早く充電できる企画みたいなのが何かいつの間にかいろいろできてるみたいな感じになっていて、それのどこまで対応しているのかっていうのをしっかり把握した上で、このケーブルを使っておかないと。
充電器とケーブルと端末、全部規格が合ってないと、端末はすごくいい規格に対応してるけど実は充電がゆっくりになっちゃってるとかいうのが全然あり得るのでね。
確かケーブル帳とかも規格で決まってましたよね。
ああ、決まってますね。
高速通信の場合、確か1メートルまでとか、利便性考えて、適当に2メートルのやつとかみんな買いまくってると思うので。
もう実質、端末メーカー側も頑張る気力がなくなってしまうというか、そのUSB Type-Cのフルスペックを活かそうっていうモチベーションが湧かない。
普通にあってしまう気がするから。
今回のEUの話っていうのは、みんなUSB Type-Cになることで、その商品にUSB Type-Cを付属しなくても良くなり、いろんな機器を同じUSB Type-Cケーブルで賄えるようになることから、社会全体として資源の節約になるって話だったと思うんですけど。
はい。
その自社の製品を最大限活かそうとして、USBの最新規格に対応しようとすると、ケーブルが共有化されている以上はその価値を活かせないし、
活かしてもらおうと思うと、結局ケーブルを付属するしかないみたいになるから、あんまり良い解決策になってないですよね。
お題目としての資源の節約に対してはベストアンサーではないというのはそれはそう。
なのでどちらかというと本音として、ライトニングがめんどくさいっていう店員だけに対する回答としてはアリだと思っていますというところかな。
30:08
今回は全ての電化製品に対してUSB-Cへの対応を義務化するってことなので。
はい。
ちょっとどうかなとは思いますが、iPhoneユーザー単体で見れば良いことなんじゃないですかね。
そのiPadとかもUSBタイプCへ移行してたりとかしてたと思うんで。
はい。そうなんですよね。
あと、そういう意味ではiPadとかに付属しているタイプCの充電器、確か付属してたと思いますけど、そういうのを使えば問題はないかなというところなんで、それは良いんですけど。
あとは現行のタイプAのタイプCの問題ですね。
はいはいはい。
タイプAが充電器側に付いているものは皆さんいっぱい持っていると思いますけど、あれパワーデリバリ規格がないので実際のところ。
ワット数が実はそんなに流せないとなると、猫も尺子もタイプCってノートパソコンとかはあれで充電しようとするとすごく時間がかかる。
なんか知らんけど使いづらいなというか、これも結局わからんまま不幸になる状態が多発しそうやなというところ。
解決策としては良い電源、ACアダプターのタイプCの付いているやつをちゃんと買いましょうという話なんですけど、
それもお題目からする資源の節約にはなってないなと、正直思わざるを得ないなというところがあるんで、なんだかなという話なんですけど。
USB-A、USB-C変換問題はもう技術リテラシーのないあらゆる人を不幸にしているとしか思えないですよね。
まあそうなんですよね。ただUSB-Aでそんなワット数上げたやつを発売するのかといってもそれもそれでいろいろ問題になりそうですし。
そうですね。だからAnkerとか最近出してるのは全部タイプC、タイプCですよね。
そう、タイプC、タイプCになってるんで、今後ACアダプターというか充電するためのケーブルを買うときは全部タイプCに統一した方が良いですよねというのをちゃんと周知する必要があるかなという気はしていますね。
誰がするんだろう。
まあ誰がするんだって感じなんですけども、そこも含めてEUも持ち進めれば良いのにという気もしますけど、充電器も全部タイプCにするってところじゃないかなと。
電化製品って言ってるときに電源側について言及してくれてると良いんだけど。
まああと、USB-C高いんですよね正直な話っていうのが、まあメーカー側としてはあるんですけども。
33:06
まあその規格に対応したり充電する前に、給電する前に通信したりするんで、それの専用チップが必要だったりとか。
いろいろあって高くて、なんか日な業種だと未だにMicro-Bを使ってたりするとかもあるんですけども。
まあそこら辺もね正直、Micro-B使うぐらいならタイプC使ってほしいなというところがあるので、
そこも頑張ってなんか統一した方が本当は良いんだろうなという気はしますね。
まあそういう意味でも多分USB系列、USBという名前を勘案したやつっていうのは結構限界点が近いというか、
乱立しすぎてるからもうちょっとやっぱりユーザー目線に立ったら何でもかんでも
がっちゃんこしてっていうのをやめとこうっていう方針がもう1回来ても不思議ではないんで。
そうですね。 それのなんか邪魔をしないといいなと思うんですけどね、このEUの規格が。
規格ではないか、法律が。
まあそのそうですね、全部USB-Cにしようという圧力が高まったのでUSB-Cでなんかこう落ち着く感じになっちゃってて、
形状は一緒だけど古いものから出したものからあって、難しいなっていう状況。
今ディスプレイ系もUSBタイプCでできるようになってますけど、当たり前ですけどHDMIとかディスプレイポートの通信速度ほどは出てないと思いますし、
それそのまま行くと多分ディスプレイの解像度とかが上がったり、またGPUとの連携性っていうところで限界がやってきちゃうと思うので。
まあそうですね、一般ユーザーはぶっちゃけUSB-Cの良い規格が乗ってれば通信問題ない気がしますけどね、そこら辺は。
十分なのかな?
ちょっとあまり覚えてないですけど、4Kぐらい行けたんじゃなかったかな?良い規格だと思ってます。
適当ですけどね、後でちょっと確認しますけど。
なので、まあそれもやっぱり結果行ってしまうと、ちゃんとしたケーブルを選ばないと4Kうつらな解像度が悪い状態で使うことになってしまうんですけど、
まあでも今HDMIの話も出ちゃいましたけど、まあそれを言ってしまうと全部それはそうって話で、
まあLANケーブルはそれこそ一般人はあんまり気にせず使えてますけど、
LANケーブルも古い規格は一応100MBまでしか通れないとか。
カテゴリーとかいっぱいありますからね。
36:00
ありますし、HDMIも古い規格、めちゃくちゃ古いものを使っていると4K対応しなくて、
まあなんかしょぼいディスプレイに繋げるんだったら良いですけど、みたいな状況になったりとか。
はいはいはい。ラズパイ付属のHDMIケーブルで4Kうつれないですからね。
そうそう。ハードウェアスペック上ヤバいね、それって思いますけど。まあまあいいや。
なので、ケーブル問題、まあそう言ってしまうと至る所にあって問題ないのは本当AC100Vぐらいじゃねっていう気がするレベル。
そうだね。まあそれも国またぐとダメだけど。
まあね。まあそういう意味では、そういう意味ではもう仕方がないかなという気もして決めちゃいますね。
なるほどね。
まあさっきととおり問題なのは、規格が乱立しすぎているってことなので、
あとはもうなんか業界団体の努力によって、まあ3.1の次は4.1にするみたいな感じで、微妙に3.2を使わないとかいう選択肢?みたいな感じでステップをなんかあまり刻まないぐらいでやってくれるとありがたいなというところですかね。
そうですね。あとはケーブル側とかもちゃんと規格を決めていってほしいなぁ。
あの、今、ランケーブルとかだったら、まあ一応ケーブルにカテゴリーとか書いてあって見分けがつくようになってるじゃないですか。
でもUSBケーブルってその義務がないですよね。
はい、ないですね。
なのでその辺だったり、あと端子の口だったりとか、でちょっとこれとこれが適合するのかくらいは、まあ見分けようと思ったらできるっていう状態は作ってほしいなと思いますけど。
そうですね、確かに。なんか結局ほぼ全てのUSB、あの手持ち部分にUSBマークつけるスペースぐらいはあるんで、あそこに4.1と書くみたいなね。
そのくらいはやってほしい気がしますね。
ね。
うん。
まあ薄型のフラットのケーブルとか作りにくいじゃないかとか言われるんでしょうけど、90度曲がるやつとか。
まあでもそれよりも変な企画で何か商品に過剰なものが入ったりとかそういうことのリスクと比べたらまあいいかなって感じだよね。
確かに。そこをなんかこれほど乱立するとは思わなかったのか、ハードウェア側で通信するからいいやにしてしまったのがうどつきですねというところですね。
はい。
じゃあ次行きましょうか。
はい。
次。
ターボパック。ウェブパックの正当光景。ターボパックが登場ということで、Kiitaの記事になります。
39:05
公式のブログ記事もあるんですけど、英語なのでちょっとKiitaのものを採用させてもらいます。
イントロデューシングターボパックということで、バーセルの使命はイノベーターがひらめき形作るのに必要なスピードと信頼性を提供することです。
昨年我々はNext.jsがアプリをバンドルするスピードを向上することに注力しました。
JavaScriptベースからラストベースのツールに移行するたびに如実に効果が現れました。
マベルからの移行ではトランスファイルの速度が17倍になりました。
ターボパックの移行においてはミニフィーが6倍になり、さらに読み込み時間の短縮と待機の使用量まで削減できました。
残りの山は一つウェブパックです。
ウェブパックがこれまで30億回以上もダウンロードされており、もはやウェブ構築には欠かせないツールとなっています。
しかしもっと早く、もっとつける可能なツールが必要な時がやってきました。
本日我々はウェブパックの正当光景ターボパックを発表しますということで、
えーと、まあ今言った通りの話ではあるんですけれども、ウェブページがより高速化されるようになってきましたよという話になります。
まずここで登場していたウェブパックとは何ぞやという話からするんですけど、
皆さんがウェブブラウザでホームページとかを見ている場合は、インターネット上にあるサーバーからいろんなものをダウンロードしてきて、
必要なコンテンツが揃ったら表示するというような形で提供されています。
この必要なものをいかに早く提供するかということにおいて、そのブラウザ側の処理も含めて最適化というのが図られてきました。
例えばファイル自体をより小さくするために圧縮技術を用いたりとか、
あとは余計なファイルサイズにならないように、プログラミングコードだったりHTMLの画面データを隙間なく詰めるようにしたり、
あとは冗長的な文章を最適化したりとか、そういったことを駆使しながら、
昔の組み込みバイナリーのような形で、なるべく最小化し、難読化し、ブラウザが読みやすい形にして提供するということをしきりに行ってきました。
そういったところで登場していた技術がWebpackになりまして、
最新の開発環境であるリアクトですとか、ビュー、アンギュラーといった環境では、このWebpackというものが後ろで動いてビルド物、ビルド成果物ができてきていました。
それで提供されたものであれば非常に高速だよねということで、みなさん使ってきたんですけれども、
それでもまだまだ早くできる余地があったということで、このTowerpackというのが登場してきたというものです。
42:02
このTowerpackとWebpackの間にもいろんな技術がこれまでもあって、先ほど登場したようなNext.jsですとか、あとはBeatと言われるものですとか、いろんな技術があったんですが、
以前のWebpackと言われる技術から比べると約700倍の速度で動作するようになりました。
その中間のBeatと言われるものも、これも1年前、2年前くらいから入り始めたものなんですが、それと比べても20倍の速度があるということで圧倒的な速度を誇っています。
これくらいの速度が出ると、もちろんWebコンテンツのリッチ化がしやすい。
今まで例えば100ms以内でホームページを表示できなければならないという要件が課されていた場合、Webpackを使っていると700分の1のコンテンツ量に抑えないと100ms以内に表示できなかった。
逆に言えば今までWebpackで作っていた環境に700倍のコンテンツを入れても100msに間に合うようになるというのがTowerpackの技術と思ってもらったらいいです。
そういったものが登場してきたので、もちろん組み込み業界、今まで大量のコンテンツを触かなければいけなくて、メモリーリソースやCPUリソースが足りなかった組み込み関係にも大きな影響を与えますし、
リッチなWebコンテンツを配信したいと思っている各社メーカーだったり、あとはリッチにいろんなものを組み込める、いろんなアルゴリズムを組み込めることによって、
より、引きの要件、例えば応答速度だったり、動画を盛り込んだり、あとはユーザーのアクセスログを仕込んだりといったような、これも入れたい、あれも入れたいをより達成しやすくなるので、
Webコンテンツ自体が要件を満たしやすくなるし、お客さんに届けられる価値が増えていくということで、これが早くなれば何でもかんでも良くなるというところのフレームワークの大型アップデートにニュースが来たので紹介でした。
ちょっとよく分かってないですけど、これは顧客が使うブラウザ上で展開する速度が速くなるってことですか?
そうです。それが900倍になります。
どうやって実現してるんですか、これ。
700倍も達成した理由については俺も正直分かんないですけど、途中のビートとかであれば、まず分散的にダウンロードさせるのとレンダリングに必要な最小限の情報を渡したり、
45:06
ドムツリーみたいなのを小さくしたりとか、そんな工夫ですかね。
なるほど。ミニマムサイズの、ざっくり言うと圧縮された情報を渡して、それを高速に展開することで、読み込み時間というか、再生時間の短縮と待機の使用量の削減ができているという認識ですかね。
そうですね。キャッシュをうまく使ってるっていう方が正しいのかな。
なるほど。何かちょっと気にしてるのが、最近携帯端末の方のハードウェアスペックは上がってますけど、容量とかの伸びが結構、メモリとかの伸びはそこまで伸びてなくてですね。
ちょっと飽和してるかなと思っている中で、通信状況が悪いような状況でも、展開表示速度を問題なくブラウジングできるっていうことが重要なのかなとちょっと思っているんですよね。
なので、こいつがもしパラレルで待機を一度に掴むことにより高速展開するとかいう手法だと、そういう携帯移動端末向けにはちょっとあんまり具合が良くないのかなとか思ったりもしたんですけどね。
そこら辺どこ向きを考えているのかなという話もちょっと聞きたいかなと思いますね。
そうですね。今ちょっと中身を見てたんですけど、一番はキャッシングが高速化に起因してるということだったので、ネットワーク負荷はそんなに高くないと思います。高速化における。
キャッシングっていうと、今までは例えばファイル単位だったり画像のキャッシュとかはあって、キャッシュできる範囲っていうのは結構限定的だったんですけど、
今回のこのTurboPackではJavaScriptの関数単位でキャッシングできるので、本当にキャッシング…難しいな。
今までだとJavaScriptとかHTMLとかキャッシングできるかどうかまず分かんないから、落としてどこまでキャッシングできるか調べて、必要なコンテンツはキャッシュから持ってきて、足りないところはJavaScriptをやっぱりダウンロードしてきてみたいなことをやってたんですけど、
それのキャッシュから持ってこれる範囲が単純に増えてるって感じですね。
48:07
なるほど。そういう設計思想レベルでの改善なので、全ての端末上で有効なのかな?
そうですね。
それにあればすごくユーザーとしてはありがたいですね、というところで。どんどんやってもらいたいなという感じですね。
昨今、携帯端末とかだと結構メモリの食い合いみたいなのも大変だなという印象があるので、そこに対してもパソコンのChromeみたいにとりあえずメモリをぶん取るとかだとちょっと困るなという気はしたんですけど、そういう感じではなさそうなので。
そうですね。あとコンパイルがだいぶ平準化されてるっぽいですね。
従来の形だとHTMLを落としてきて、画像とかのコンテンツを落としてきて、JavaScriptを落としてきて、それらがどう動くのかとか全部分かってから一気にコンパイルかけてバーンと表示するだったんですけど、
コンテンツを全部除いて全く空のDOMの状態で一回コンパイルして表示までやるっぽいですね。
その時点では真っ白な画面なんですけど、そこからコンテンツとかCSSとかそういったものをそこからコンパイル始める。
なので土台を先にお出ししておいて後でトッピングするみたいな感じ。
そうそうそう。っていう動作になるので、メモリ負荷が後ろに伸びるのかな。
蓄積で出していくんで一気に作業負荷がかからないと。
後からトッピングできるようになると当然CPUとかメモリの並列処理化とかもできるようになると思うので。
良さそうですね。
世代前くらいから必要なところしかコンパイルしないとかはできてたんですけど、それに加えてって感じですね。
そのトップページのブラウザーのレンダリングサイズから1画面目に表示しなければいけない領域っていうのをあらかじめ計算して、
その範囲しかコンパイルしないっていう技術は元々あったんですけど、それに加えてっていう感じみたいです。
効く限りすごく良さそうなところばっかりなんで、すごくいいですねという感じですね。
そうですね。
あとは特筆するところで言うと、作られてる言語がラストという言語になっていて、
51:05
以前紹介したかわかんないですけど、ものすごく安全なC言語みたいな、そういう言語なんですね。
これが本当にいろんなところで活躍しだしてる一つの事例になっていて、
ラストで書かれているということがあるだけでメモリセーフですし、
新しいものだからといって致命的なトラブルっていうのをあまり起こさない開発環境で作られてるんだなというだけで評価が高いって感じですね。
新規一転するとバグも内包されやすいですから、そこはありがたいところですね。
まあ誰かが皮肉で言ってましたが、ラスト製ということだけでプログラムの品質がアホほど上がる。
なぜならラストを理解できるエンジニアは少ないから。
オープンソース思考が真っ向か対立してるやんって感じですけど。
そうですね。ラストが書けるという時点でメモリとかCPUとかプログラムエンジニア、低レイヤーなことまで開発できるプログラマーエンジニアでないとラストが言ってる意味がわかんないから。
なるほどね。
ラストが書けるという時点で相当レベルの高いプログラマーしか集まらないので品質が上がりますっていうことを言ってましたね。
なんか良いんか悪いんかって感じですけど、結果的には顧客的には使いやすければ使いやすいほど良いんで、ありがたいと思いますというところですね。
そうですね。おっしゃる通りオープンソース界隈だとさっきのOpenSSLの話もあるんで、信頼性という意味でラストは流行っていくでしょうね。
はい。では次の話ですね。
IT Media Newsさんの記事で、LINEのAIスピーカークローバー販売終了へ音声操作も不可。7月以降はただのBluetoothスピーカーへというタイトルの記事です。
LINEは10月26日、AIアシスタントクローバーを搭載したスマートスピーカークローバーシリーズの販売を31日をもって終了すると発表した。
同端末の音声操作サービスクローバーアシスタントの提供も2023年3月30日に終了する。終了の理由は可視していない。
販売を終了するスマートスピーカーはクローバーウェーブ、クローバーフレンズドック、クローバーフレンズ、クローバーフレンズミニ、クローバーデックの5種類。
LINEはクローバーアシスタントの提供終了後はBluetoothスピーカーとして引き続き利用可能と案内している。
利用にはサービス終了前に設定する必要があり、サービス終了後は設定ができなくなるという。
54:01
クローバーデバイスの購入から1年未満で端末保証期間中であるユーザーには端末購入料金払い戻しも実施する予定。
払い戻し方法は後日発表するということらしいです。
クラウド系のサービスこえーなという話なんですけども。
開発企業が撤退してしまうのでサービス提供しませんという。
サービス利用できなくなりますというのはある話なんで、それ込みで買ってくださいという話だなという感じですけども。
面白いのが、ただのBluetoothスピーカーとして設定さえすればできるんですけど、それがサービス終了前に自分で設定する必要があるというのが、
なんだろう、もうちょっとなんとかならんかったのかなというところだなという感じの紹介です。
終了日にバッジ展開したらいいじゃんって感じだけど。
思うんですけどね。
オンラインがどうかもわからんからってことなんでしょうけどね。
ああ、そうか。ローカルで使ってる人もいるのか。
だったり、Wi-Fiが常時繋がってるかどうかわからない関係ない人もいるでしょうし。
なんでギリギリまで使いたいっていう人は勝手にバッジが適用されてしまうと困るしっていうところだね。
とかを考えたんでしょうけど、このニュースを聞いて一番思うところは、AIスピーカーなる文化が終わりを迎えようとしてるのかもしれないなっていうところですかね。
ああ、なるほど。
Google系のものだったり、Amazonのエコー系のものだったり、Google本語とAmazonエコーってあったと思うんですけど、どちらも新しい機器っていうのはあんまり出てなくて、アップデートがあるのは基本的に画面付きのものだけですね。
当初乱立していたスピーカー機能だけが付いているものっていうのはほぼアップデートがなく、だいぶ前のリリースが今も最新モデルとして生き続けている状態なので、いつそいつらも終わってもおかしくないという状態にあります。
LINEさんも日本の国内ではかなり最初の頃は宣伝も打っていましたし、イベント等々で使ってみませんかとか、ハッカソンに使ってみませんかというところで、割とメジャーによく見かける機器だったかなという印象があります。
今回サービス終了するということで、AIスピーカーっていうのがこれ以上手を入れる価値がないっていう見限りだと思うんですけど、AIスピーカーとして他のGoogleやAmazonも新しいものを出せていない中、このままAIスピーカー文化自体が終了していくのか、
57:20
それはもう市場が飽和しきったから競合として勝てなくなったわけなのか、その辺が注目かなという感じですかね。
うーん、難しいですね。難しいですね。
AIスピーカーとしてこれ以上できることがなくなったのかなっていう印象もありますけど、何も考えずとりあえず導入してみましょうみたいなアルファユーザー的な人はもう導入しきってしまって、そこの市場は飽和しているような気はします。
一般使用者にまで展開できるかっていうとできてないですねというのはおそらくそんな気がしていて、そういう意味で言うと市場が広がらなくなった、これ以上スケールするっていう未来が描けなかったんでやめますっていう話になってしまいそうですね。
そうなった場合に残るのは、今使用しているユーザーの市場規模で開発側が満足するかどうかという話だと思いますけど、どうなんだろうね。満足しないような気もするんですけど。
そうですね。Googleとかはだいぶ早めにやめちゃいそうな気がしますよね。企業文化的に。
そうですね。まあでもAIスピーカーとしては、ハードウェアとしてはそう考えると無くなるかもしれないですね。
なのでただ蓄積があった技術として、例えばそのスマートウォッチに搭載するとか、それもあんまり使っている人はいないような気もしますけど、ちょっとしたことでね、使ったら便利だなと思うタイミングで使えるとかあるといいかもしれないんで。
機能としては残すみたいな感じでやっていくような気はしますね。
そうですね。Googleのスマートアシスタントとかはピクセルウォッチにも搭載されてますし。
スマートアシスタントをいろんな機器に搭載させたり、いろんな場面に登場させて活躍機会を増やそうっていう試みは、まあ祝々と続いていますし、
スマートアシスタントの音声認識能力の向上及び機能拡張っていうのもされてはいるかな。
1:00:02
Amazonの方はあんまり成長してないような気がしますけど、機能拡張という面では。
もうサードパーティーのアプリ依存ですっていうので割り切りで開発が止まっているようにも見えますけど、活躍のシーンは増えてる。
おっしゃる通り機器はもう減っていってますね。
そうですね。
まあそう考えたらAmazonはちょっと厳しいのかなという気がしていて。
Googleとかはそれこそなんで、携帯端末としてその喋り、顧客が喋りに行くウェアラブル系の端末を自社で作ってるんで、まあ載せやすいかなという気がしますけど、
Amazonはあんまりそういうのがないんで、Google、Android乗ってんならAndroidでいいじゃんみたいな感じになっちゃいそうな感じがちょっとしますね。
そうですね。
その、Amazon側が搭載できる機器ってFire Stick TVとエコーシリーズだけなんですよね。
はいはい。
じゃあFire Stick TVもApple TVとかGoogle TVとかと比べてシェアを取れてるかというとそうでもないので、ちょっと厳しそうな気がしますね。
まあなんかこう、データを扱う業種として顧客の音声データってまあ使い方もちょっと議論ありますけど、なんつーか生データなんでちょっと手出したいなっていうのは分かりますけど、まあどこまでやるかはAmazon次第かなというところですね。
そうですね。Amazonで言うとあれですね。ルンバのiロボットを買収してるんで、あっちへの搭載はあるかもしれないですね。
ルンバに、ああなるほど、アレクサを搭載する?
うん。
確かにそれはありそうやな。
ああ確かに。
そういう生き残り戦略はあるかもしれないけど、やっぱり全体的にもう低迷してるというか、ニュースになっても誰も飛びつかなさそうな雰囲気はありますよね。
まあ今こういう感じのAI系はなんかどちらかでとメタバース側がバズってるんでっていうところもありそうですね。
もうちょっとね、あの音声認識能力が進んで、その実際喋ってることがメタバース空間上での吹き出しとして文字で流れるとか、そういうことになれば全然違うんでしょうけど。
そうなんですよね。なんかオープンプラットフォームとして、なんか音声突っ込めばすごく精度高く返してくれるみたいなのが提供されると化ける気はするんですけど、今でも音声認識なんかいろいろありますけど、なんだかんだ言ってそんなに精度が良くないというか。
1:03:13
そうですね。
そういう感じで、たまに紹介しますけどTeamsのやつとかも結構、あとこの前やってたローカルと合わせるやつとかも、一部の人しかまだ手を出せてない状態、ちょっと導入コストが高い状態みたいな感じに。
それがそのハードウェアセッティングだったり、Teamsを導入しないといけないという、Teams内で展開しないといけないという制約だったりみたいなところがあるんで、そこら辺がなんか適当にAPI叩くとぶん回せるとかがあると結構強いのかなという気はしますけどね。
そうですね。将来的な、何年後かわかんないですけど、そういう学習モデルをワンチップ化するっていうのもちょいちょい流行ってるじゃないですか。画像認識系だと進んでると思うんで。ああいうチップをマイクに仕込めるようになるとちょっと世界変わるんでしょうね。
ああ、それいいですね。確かに。確かにそれいいですね。もうデータとしてUSBを通過するという。
ああ、そうそうそうそう。音声のアナログデータと圧縮されたデジタルデータ、音声デジタルデータと文字起こしデータっていうのが音声通信企画のデファクトになったりするともうだいぶ強いというか。
ああ、それ強くないかな。何て言うんですか。末端側で処理してデータとして抽出、テキストデータとして処理できるようにすれば、あとはトランスレーション、翻訳して、例えば日本語で喋ったのを同時に相手に英語で提供する。
しかも音質を学習して、自分があたかも英語を喋ってるかのような語彙質で提供できるとか、できるとすごくシンギュラリティだなという感じがしますね。
そうですね。ブレイクスルーはその辺にありそうですね。
それはちょっと世界が変わりそうですね。
当然さんがおっしゃる通り、まだまだ文字起こし技術自体がワンチップにしたくなるほど熟練してないっていう事実はあると思うんで、細々とやってそこまで唐突したなって誰かが見込んだら一気にまた変わるかもしれないですね。
そうですね。まあそれも本当にいつ来るかわからないんでね。イラストレーション会話はすごく1ヶ月ぐらいずっとざわついてますけど、あれと同じ状態になるかもしれないんで、それ期待で続けてもらえればというところです。
1:06:11
はい。では次私の方、最後行きたいと思います。
シンセサイザーVに超強力な女性ボーカルMAIが間もなく登場。もうAIと人間の違いは認知できないレベルに。
ということでDTMStationさんの記事です。
10月27日、シンセサイザーVの新しい歌声データベースとしてMAIがお披露目となり、その歌唱動画が公開されました。
実際にユーザーが入手可能になるにはもう少し待つ必要がありそうですが、遅くとも年内には増長するそうですから心待ちにしたいところです。
ということで、これはもう是非動画をまず見て聞いて欲しいんですが、かなり人間に近い声で喋れてますね。
息継ぎの部分だったりとか、ビブラートだったりとか、そういったものが入っているんですが、驚くべきポイントとしては、基本的にベタ打ちでできている。
ベタ打ちっていうのは、ある声と音の高さとかを調整して何秒間それを言うかとか、そういう設定だけですね。
ベタ打ちじゃない作業としては、音声を何秒間入れるっていう時には、そこのアナログ情報とかを触って、声の欲をつけたりとか、
ビブラートの膨らまし方を変えたりっていう、さらに細かいアナログな調整っていうのがあったりするんですけど、このシンセサイザーVの前ではそういった中身の調整はなく、
ベタ打ち、ただ並べていくだけで基本的には曲としてできたというものになっています。 いわゆるボーカロイドとかいったものとの差でいうと、
シンセサイザーVの方は決まった歌い方しかできないので、曲はかなり選ぶっていうところがあったりすると思いますけれども、それでも機械的に作られた音楽として人間にかなり近い音声が出ているということ自体は驚きだと思いますし、
それに合わせた楽曲の作り方とかもあると思います。シンセサイザーVは別にこの前だけが提供されているわけじゃなくて、いろんなものが提供されてますので、これをフル活用して自分の楽曲を作っていくっていうのも面白い世界になっていくんじゃないかなとは思います。
まず単純に新しい技術、新しい製品が出てくれるのは良いですねという話。途中にもありましたけどボーカロイドの方も出してますし、このシンセサイザーVとしても新機能を搭載してベタ打ちでサクッと出せる、お出しできるっていうのはすごくいいなと。
1:09:16
その上で、初音ミクの再来というのはできるのかなというのは難しい話ですねとはちょっと思っていまして。技術がすごければ初音ミクの再来になるかというとそうじゃないなと思っていて。
というのは、初音ミクの元を越えて、影響元の藤田佐紀さんのように歌わせるみたいなのは正直もう10年前にはできているんですよね。ただそれはやはり流行らなくて、初音ミクとしてのボーカロイドには載っていないということになっていて。
それは何でかっていうと、もはや初音ミクとしてキャラクターが確立されているので、その肉性に合わせているよりも初音ミクとしての声を提供することを優先しているという話があったりするという中で、このシンセサイザーVの方はすごく肉性に近い。
歌い方をしてくれる。たださっき言った通り、ただ曲の方向性が結構限定されるという状況で提供されたことで、曲数が出しやすいのか出しにくいのか、難しいねという感じがしていて。
初心者が使うにはすごく取り付けやすいという意味では、すごく技術としていいかなと思いますけど、もう1回初音ミクレベルになるかっていうと難しいのかなと思ったり、思わなかったり。難しいなというところ。
そうですね、その機械的、自動音声っていうこと、AI歌声構成エンジンの使われ方の方向性として、実際どういう利用方法とその商品っていうのがあるのかっていう話だと思ってて。
その初音ミク系っていうのは、私はこういう音楽を使いたい。で、楽器の中に声がないから欲しいっていうスタートだと思ってるんですよね。
1:12:06
そこが求められたことだから、人間に近い音声で作れる音楽が狭まるという方向性は基本的に求められてこなかっただと思ってます。
で、一方で音楽を作るって言った時に、歌手がいてこの人が歌ういい曲を出してくださいっていうことで作曲、作詞する人も当然いるわけじゃないですか。
で、そういう人は歌い手が決まってる上で出すんですけど、そういう技術を磨こうと思った時に、著名な歌い手の下で作曲できないと作曲家として名を馳せられないっていう問題がありますよね。
で、それの宣伝能力とかはその歌い手に依存してしまうっていう問題があるんで、作曲家として歌い手に依存せず、作曲家の形態で音楽を世の中に出していこうと思うと、こういったシンセサイザーVも登場してくるのかなとは思います。
なるほど。確かにそういう意味で言えば、そうですね。自分の作りたい曲の方向性とシンセサイザーVの前の歌声の方向性が合っていれば何も心配もなく、リッチと言っていいのかどうか分かんないですけど、前の歌声でその曲を出せる。
合っていればというよりは、プロ作曲家としては自分の曲を、あ、違うな。プロ作曲家として言ってる、芸術家みたいな音楽活動をしてる人と、
自分、自己発信、自己発言のための音楽活動の人と、プロとして受注して言われた要求事項、要件に基づいて曲を作って下ろすっていうことをやってる人っているわけじゃないですか。
はいはい。
で、後者の人にとっては、もう歌い手とかどういうシーンでどういう風に使われるかっていう制約があって、その中でベストな曲を作るって話になりますよね。
はい。
うん。そこを言う、そういう制約の一つでしかないと思うんですよ。このシンセサイザーVの前っていう歌い手が、そういう歌い方しかできないっていうのは。
はい。
そういう中で、歌い手に縛られない形で作曲がしたいとなると、まあ役に立つのかなという。
人間の歌い手に縛られずにっていう。
1:15:00
そうそうそうそう。
確かに。
発注方法だと、発注元にその宣伝権限とか、その曲をどう扱うかの権限があって、その裏手、裏手でいいのかな。裏側のスタッフ的な存在にしかなりえなくて、その表出できないじゃないですか。
はい。
自己スキルを。
うん。
なんで、まあそういう発言には役に立つのかなって感じですかね。
うーん。
まあまあ確かに。
うーん。
まあそうですね。自分の手元で確かに作品を上げられるというところではありですね。まあ確かにそうか、そうか。
まあそういう意味で言えば、やっぱりコスト少なく出せるというところが利点ではあるのかな。
そうですね。だからこれを使って、もし何かその出た曲が人気が出るとしたら、作曲家が人気出るんであってシンセサイザーVの前が人気出るわけではないと思う。
まあそうですね。うん。
初音ミクとかボーカロイドの場合はボーカロイドが人気出てこんな歌い方をプロデュースしたPは誰だっていう2番目としてその作曲家の人が目立ってたと思うんですけど。
うん。
シンセサイザーVの場合は逆になるんじゃないですかね。
うんうんうん。
なるほどね。まあそうか。それであればいいか。確かに。まあ確かに方向性が違うという話ですね。結局のところ。
そうそうそう。結局はそう。
そうですね。まあそういうところであれば確かに分かりました。
うん。
いや、まあ私も別に曲を作ってるわけじゃないんで、想像でしかないんですけど。
まあそうですね。どうしても初音ミクありきでちょっと考えてたんで、そういう方向性ならちょっと腹打ちしたなというところでいいと思いますと。
はい。じゃあこの件も以上です。
はーい。では最後。米NASA観測衛星、世界50以上の地域でメタン大量排出源を特定という。Jトロさんの記事から持ってきましたと。
米国航空宇宙局NASAは10月25日、同局が7月に打ち上げた観測衛星による地球表面鉱物人間調査ミッションにより、中央アジア・中東・米国南西部などの地域で50以上のメタンガスの大量発生源を特定したと発表した。
1:18:24
大量発生源の一つとして特定された米国南部のパーミアン盆地では、南東約2マイルの長さにわたりメタンガスが検出され、1時間あたりの流量は約4300ポンロと推定されている。
パーミアン大地はテキサス州西部とメキシコ州南東部の一部にまたがる地域で、国内有数の石油ガスの産出地として知られている。
NASAのビル・ネルソン長官は、メタンガスの排出を抑制することは地球温暖化を抑制するための重要な課題と述べた上で、国際宇宙ステーションとNASAが保有する20以上の衛星や観測機器は、地球の気候変動を把握する上で長い間非常に重要な役割を担っていた。
エミットは温室効果ガスを測定し、発生源で食い止めるための重要なツールであることが証明されていると述べた。
なお、メタンガスの排出源を特定処置する試みでは、非営利団体のカーボンマッパーが8月に米国メキシコ湾浅瀬域の海洋石油ガス施設からメタンが大量に漏出しているとの調査結果を発表していた。
ということで、地球温暖化ガス、温室効果ガスの排出が世界的に低減していこうという中で、地表から漏れているのも対応できるといいよねという話は当然ある話でして、
それに対してNASAが観測衛星打ち上げで実施していると。
制御が出ましたという話で、よいかなと思っての紹介ですというところですね。
素直にいいことしかない。
いいことしかないと言ったらあれですけど、
機体なので、目に見えてあそこからどうこうとかそういうことってわからなくて、やっぱりその地域を観測しに行くしかない。
当たり前ですが地球ってでかくて広いので、全体を常にモニタリングするなんて非現実的でやってられない。
ただ、いくら人間の活動でメタンガスの抑制とかを進めたところで、
こういう自然的発生源だったりとか、そういったところでのガス発生量が実質的には大多数を占めていたりすると思うので、
そういったものを管理できるようになるという意味ですごく良いんじゃないですかね。
1:21:02
そうですね。
京都議定書とかの目標に対してこれが勘案されてなかったなら、それはそれで良くないよねという気もせんこともないですけど、
これによって実質的に結果として地球温暖化が抑制されたということになれれば非常に良いと思うので、
制御性を高める上でも非常に重要ですねというところですし、
それを実際に衛星を打ち上げて対応しに行っているというのは非常に良いことだなというところですね。
良いことしかないかなという感じですね。
ここからは多分政治的な問題で、
じゃあ中国でどれくらい出てるってなった時に中国当局にそこのインフラを何とかして露出を防止しなさいという指示が出せるのかと言われるとまだ難しい。
まあ議論になるわけど合意はしないでしょうねという感じでしょうねと思いますけど、
結局国内というか国土の話になってしまうんでね。
課題をちゃんと目に見える形で表面化させること自体は大変偉いので、それ自体は本当に素晴らしいと思いますね。
そうですね。データがないとやっぱり適当に電波が弾いてこんなもんかつって実際そこまで効果があるのって。
統計も優秀なツールではありますけど、実際ここに問題点があると、じゃあここを対策しに行きましょうねとできるっていうのは素晴らしい話なんで良いと思いますねというところです。
例に出ている特定の施設からの露出の結果とかもありますけど、そういったものはなさとしてもなんか出しにくいだろうなと思いますけどね。
そうですね。でも観測結果は観測結果なんで、それをもってアメリカがどうするかとかなんじゃないですか、やっぱり。
そうですね。じゃあ今日はこんなもんですかね。
はい、本日の内容はショートにまとめていますのでご確認ください。
リカログではご意見ご感想やこんなことを話して欲しい対応もお待ちしています。
メールアドレスはリカログアットマクジュメル.コムになります。
ツイッターもやっていますのでフォローやダイレクトメッセージもお待ちしています。
本番組はPodcast、Spotify、YouTubeで聞くことができます。
1:24:00
ぜひそちらでもサブスクライブよろしくお願いいたします。
はいではお疲れ様でした。
はいお疲れ様でした。
