00:00
はいどうも、kokorokagamiです。 当然です。
今週も1週間振り返っていきたいと思います。 はいはい。
今週はですね、Windows 11の22H2がリリースされて、一般のユーザーにも配信されるようになりましたというところで、
私が早速試してみたのでその紹介をしたいなと思っています。
わざわざそんな新しいバージョンのリリースくらいでっていうところではあったんですけど、
今までそのAndroid用のWindowsサブシステムが動かせるようになるっていうので、ずっと話題として取り上げてきたと思うんですが、
このリリースでとうとうそれが入ってきましたよという紹介です。
それ以外にもいろんなアップデートあって、お勧めの機能もあったりするので、ざっくり紹介したいなと思います。
PCウォッチさんの記事を参考にすると、特徴的なものとして一番大きなのがAndroid用のWindowsサブシステムの展開。
他に私的に嬉しかったところで言うと、カレンダーのところにフォーカス機能がついて、ポモドールが使えるようになりました。
フォーカス機能っていうのは、30分とか集中タイムみたいなことを決めて通知をオフにしてくれたりとかそういう機能ですね。
なので今までTeamsの通知とかいろいろ来てて、その通知ばっかり振り回された人はちょっとマシになる可能性があります。
あとはスタートメニューがよりスマートフォンアプリっぽくグルーピングできるようになったりとか、そういうカスタマイズがどんどん入っているのと、
ワンドライブがとうとうExplorerに統合され始めてきていて、ドキュメントフォルダとかそのバックアップとして残す代表的なフォルダについても、
デフォルトがワンドライブのドキュメントフォルダになっていて、今までPCのデフォルトに用意されていたローカルにしかないドキュメントフォルダみたいなのがもう撤廃されつつあると。
なので、ユーザーは自動的にバックアップされる環境に自然とファイルが置かれる状態になるって感じになって、スマートフォン同様にローカルで持っているもののバックアップやクラウドとの同期っていうのが自然と行われるような状態になっています。
プログラマー的にはそのワンドライブのドキュメントフォルダになると、ファイルパス構造に2バイト文字とか空白が入ってきたりして、
それでツールがバグることが結構あるんで勘弁してくれっていうところではあるんですけど、一般ユーザー的には良いアップデートですね。
一番メインのAndroidサブシステムなんですけど、使い方としてはMicrosoftストアに行ってAmazon App Storeプレビューというものがリリースされているので、それをインストールすることになります。
03:01
それをインストールして起動すると、Googleプレイストアみたいにアプリがいろいろ並んでいる画面が出てきます。
その中から好きなアプリをインストールして実行することができるというものになっています。
いろいろ使ってみたんですけど、まずはこのストアに登録されているアプリですね。これがあまり多くないです。
例えば金融系のアプリとかニュース系のアプリ、ネットワーク系のアプリとか、Googleプレイストアだったらいろんなカテゴリーで存在すると思うんですけど、
デフォルトで用意されているカテゴリーがゲームとその他しかないという時点でお察しかなという状態です。
ゲームについても日本人ユーザーだったらすごくメジャーなもの、馬娘とかそういったものも存在しなくて、
海外でも特筆してメジャーなものくらいしかなく、それも全部ではないという感じですね。
なので現時点では入れたくなるようなアプリ自体がそもそも少ない。
アプリの検索にまず日本語も使えないのと、検索メニューに何か文字を打って検索をかけるとその検索文字がクリアされた状態で検索結果が出てしまうので、
何で検索されたかがよくわからないという感じになっています。
アプリ自体もまだまだ貧弱なのか、処理が結構重くてですね。
ストアの方の処理が重いってよくわかんないんですけど、ストアのスクロール自体がもっさりしててなかなか画面更新がされないとか、
検索文字列もキーボードの入力が遅れて入って結果的に期待する検索文字が入れられないとか、
そんなことになるくらいには動きがもっさりしちゃってます。
最初のプレビュー版なんでそんなもんといえばそんなもんかもしれないです。
完全化なめの起動したゲームの動作とか、スマートフォンアプリの動作自体なんですけど、
まずアプリを選択して起動するとそのアプリ専用のウィンドウが別途立ち上がります。
Amazon App Storeの中にゲームとかが起動されるのではなくて別のウィンドウとして起動されます。
起動後は基本的にはサクサク動きましたね。
特にゲーム内で完結するようなものであれば比較的問題なくサクサク動いたんですけれども、
ゲームガイドの通信処理とかが発生するもの、
例えばフォルダとかにゲームの一時的な情報を置いたりとか読み込んだりして計算処理をしながら動かしているゲームとかだと、
そのファイルシステムへのアクセスっていうのがちょっとサブシステムのエミュレーション経由になっているからか何かが正直わかってないんですが、
そのあたりでちょっと重たいなと感じることがありました。
それがいわゆるノックスとかAndroidエミュレーターと比べて特筆して悪いかというと、
06:06
そこまででもないかなという感じだったので、
今後に期待できるくらいには洗練されているサブシステムになっているかなという感想ですね。
まずUI関係の改善からいきますと、
記事をざっと読んでいるんですけど、微妙に痒いというコメントが届かなかったものがちょっとずつ改善されているなという印象ですね。
個人的に通知周りのBluetoothとかですね、
Bluetooth機能が強化されていて、オンオフだけでなくデバイスの追加や状態確認などの設定が可能になったというところで、
ペアリングデバイスが一覧に出るようになったり、
ここら辺結構私の環境ではちょみちょみいじってたんですけど、
すっと出てこないんで自分でショートカット作ったりみたいなことをやってたんでありがたいなと思うところですね。
Bluetoothなんかやりたいことに対してステップが長いんですよね結構。
古いデバイスマネージャーの追加みたいなレベルのフェーズを経てて、
全然動線がアップデートされてこなかった経緯があるんで。
11でスッキリしたのはいいんですけど、その分できなくなってたことが深くなってたところですね。
そこを改善してくれてたんでありがたいなと思うところですね。
あとAndroidについては、私も使ってみるとわからないという感じですけど、
今のところアプリの追加待ちという感じですよね。
それはそうだろうなという感じなので、
これは時間が経てば増えていくのかなという気もせんこともないのですけれども、
あとメイン構造というか、メインの動作はうまくいくんですけど、
ファイルが重くなるとか、ファイル関係の処理。
そこら辺は結構アプリの設計によっては致命的になり得るんで、
難しいですね。
アプリ設計者がまた頭を慣らさないといけないですねという感じが実際ありますね。
そうですね。実際スマートフォンとの体験を比較して顕著に差を感じたのが、
その記事のスクリーンショットにもあるんですけど、
放置症状というゲームがあって、このゲームの特徴として、
前に起動したタイミングから次に何かアクションを取ったタイミングまでの時間経過で、
内部のゲームキャラクターが成長する、レベルアップするという仕組みを持っているゲームです。
そうなると、そのゲームの情報を不揮発にどこかで管理していて、
09:02
その差分から自動的に散出するという処理がちょくちょく挟まるんですけど、
その処理のタイミングごとに重くなるもので、UIの操作がいちいち重いみたいになってましたね。
なるほど。難しいですね。
でも多分側をかぼせている感じなんで、ステップが1個増えてて、それがもうどうしようもないという話はなりそうなんで、
まあまあアプリ設計者に頑張ってもらうしかないかなという気がありますね。
アプリ設計者というのはAndroidアプリというよりも、このサブシステムの方ですかね。
そうですね。もう一つ試してみたのがFrost and Flameっていうやつで、
ゲーム上ではそのハックスラのような高め、高めって言ったらいいんじゃないかな。
上から見下ろす形で小さいユニットたちがごちゃごちゃ戦闘しまくるみたいな感じの、
一般的にはCPU負荷の高そうなゲームデザインのものなんですけど、
それは全然軽かったので、CPUリソースとかの割り当て、メモリの割り当てとかはかなりうまく作られてるなと思いましたね。
なるほど。そこもデスクトップでやってるんで、多少はゴリゴリいっても大丈夫というところはありそうですね。
そうですね。一番多分多いのが、デスクトップでやるというよりもタブレットで大きい画面でハンドレードゲームをやりたいみたいな需要がある気がしていて、
そうなった時に多少重くなるかもしれないので、どうなんでしょうねという。
ハンドレードタブレット使いという話ではあるのかもしれないですけど。
そうですね。個人的にはそういう用途よりも、今ゲームだけで絞れば、マインスイッパーとかソリティアと同じ位置付け。
ちょっとした息抜きにポチポチ伝わるとか、ロードモバイルとかのゲームだったら、一定の経過時間が経ったら次のアクションが取れるようになるみたいなゲーム性があったりすると思うんで、
そういうのをサブ画面の片隅にでも置いておいて様子見せるとか。
常駐させとく感じでね。画面広いですから。
っていう使い方もあるかなと思ってましたね。
確かにね。ハンドレードと違ってWindowsだとWindowsが複層切るのが非常に便利なんで、そこの差分がありそうですね、確かに。
うん、なるほど。今後に期待というところですね。
あと一つあれですね。さっき言ってたOneDriveに…何でしたっけ?
12:00
Explorerが投稿されて。
Explorer関係が投稿されて話なんですけど、ドキュメントとかがOneDrive管理下に置かれるっていうのは、何もわからない上では良いんですけど、あまり重たいものが置けなくなるっていうところがあるんで、
個人的にはちょっとそこを何とかして欲しいなと思う次第でありますね。
そうですね。
ドキュメント、ワードのファイルぐらいとかだったら良いんですけど、すごくでっかいファイルとか動画とかを管理下に置いてしまうと一瞬で容量食われてしまうんで、
そうなった時にGoogleドライブよりも確かきつくて、容量制限がデータとか動画でもかかっちゃうんでしょうね。
そうですね。
そうなってしまうとちょっと、そこに容量が圧迫された結果必要なもののバックアップが取れてなかったとかいうことも発生しているので、
そこら辺はわからない人ほど落ちやすいのでちょっと気をつけておいた方が良いかなと思うところでありますね。
そうなんですよね。
動機トラブルが全てのユーザーで発生してしまうっていうのは逆にデメリットではと子さんWindowsユーザーとしては思っちゃいますけど、
新規Windowsユーザーだったら関係なかったりするのかな、ちょっとわからないですね。
わからないですね。
わかってるから怖いだけであって、そういうもんだよねと言われてしまうとそうなのかもしれない。
スマートフォンでも動画とかを持たかったら消すしなっていう。
まあまあね。
そう言われてしまうとそうかもしれないね。
動画とか写真撮りまくって、容量が足りなくなったって時に何してますかって言ったら、
よりデカいハードディスクを持ってるスマートフォンを買いに行くか、外部のSDカードでの出力とかを試すかとか、
まあなんかそんなことをやるわけで。
まあそうですね、ローカルに保存する必要はないというか、
一般的に確かにスマートフォンをメインで使っているユーザーとかはインスタグラムとかに投稿していて、
そこにあるやつが漏れている画像なんで、
失敗した画像はいらんわっていうデフォルトであるとかね。
そうそうそうそう。
だからOneDriveに残ってる時点で公開はできないけど最低限残したいモノレベルしか残さない。
それ以外もちょくちょく消しちゃうみたいな。
ところはあるんで、まあ使わないやつはアーカイブ化してて最低限ね、とかでもいいのかもしれないですね。
そう、だからあまりにも子産スタイルなのかもしれない。
まあ確かにそれはありそうですね。
はい、わかりました。
エンジニア的には困るんですけどね。
まあそうありますね。
はい。
じゃあちょっと枕長くなっちゃいましたけど、本題の方行きたいと思います。
はい。
1点目、オープンAIがリリースした高精度な音声認識モデルウィスパーを使ってオンライン会議の音声を書き起こしてみたということで、
15:06
Developers.ioクラスメソッドさんの記事になります。
オープンAIという名前の通り、オープンソースコミュニティのAIのところが、
ウィスパーという音声認識、音声を文字起こしするAIツールというのを発表されました。
これがオープンで提供されているので、もう誰でもGitHubから使うことができるんですけれども、
日本語にも対応しているというところで、日本人の中でもすごく話題になっています。
このオープンAIのウィスパーがですね、なかなか精度が良くて、
実際今回は私たちのポッドキャストで試してみたんですけれども、私たちってそんなに滑舌良くないじゃないですか。
でもそれなりにちゃんと文字起こしてきていたので、これは良さそうという感じになっています。
フリーでも使えて精度が良いとなると、今まで文字起こしAPIとか文字起こしをしようと思ったとき、
クラウドサービス、SaaSでのサービス提供としていくつかあったんですが、
なかなか1時間とか2時間あるようなポッドキャストのデータを加わせようとすると、
アホみたいにお金がかかるみたいなことがあったので、
オンプレというかローカルのPCで簡単に文字起こしできるこのツールは非常に良いなという感じになっています。
一方でちょっと困っていることもあって、
1時間のデータを変換する時間がアホみたいに長いということがあって、
このオープンAIのウィスパーにはモデルがいくつかあります。
そのモデルというのはAIの学習モデルですね。
そのモデルのサイズというのが、Tiny、Base、Small、Medium、Largeと5段階あって、
最初にVRAMの容量も足りているからということでLargeを試してみたんですけど、
1分の音声データに対して1時間処理がかかるということが分かり、
1時間のポッドキャストを変換すると2日半かかると。
その間、PCが全く落ちないように維持しないといけないということがあって、
ちょっと厳しいなとなっています。
今朝、Mediumに下げてやってたんですけれども、
その間にPCが一旦スリープに落ちたっぽくて、そこで処理が止まってしまったというところでトラブルになっていて、
いまだに最後までコンバートできたという実績がないという悲しい現実があるんですけれども、
途中途中でコンバートされた中間情報は見れるので、
それを見る感じはかなりいい感じになってたから、
18:01
どこかでその変換後の文字起こししたデータもGitに上げていって、
公式のホームページ、このポッドキャストのホームページのところからダウンロードできるようなリンクも張っていこうかなとは思っています。
確かにオンプレでって動くっていうのがすごくいいかなと思ってますね。
さっき言ったようにすごく重たいデータを壊したいという特殊な事情がありますので、
そこに対してゆっくりでいいかローカルでやってほしいという需要を満足してくれているというのはすごくうちらとしてはありがたいところですね。
どうなんでしょう、GPUスペックが必要という感じなんですかね。
そうですね、VRAMが推奨スペックとして入っているのでGPUスペックが必要なんですけれども、
実際に変換中のパフォーマンスを見ているとほぼほぼCPUばっかりでした、私の環境では。
そうなんですね。よくわかんないですね。
もしかしたらウィスパーの実行オプションの時にどれくらいGPUを使うかとか、
ちょっとしたチューニング的な設定があるのかなとは思うんですけど、
単純に実行しただけだとそこまでGPUは食われなかったですね。
なるほど、了解です。
そこら辺、適切な設定をしてやったら、環境がいろいろ違うんでね、オンプレだと。
速くなるのかもしれないんで、そこはちょっと期待したいなというところではありますけど、
モデル外はさっき言ってたようにいろいろあるんで、
これどうなんですかね。
モデルが軽いやつにすると認識性能が悪くなるという認識でいいのかな。
単純にそうです。
なるほど。
それは学習用というか参照するデータ量が小さいからという感じなのかな。
そうですね。学習モデルが小さいっていうことは、
その学習の教育しデータというか、そのモデルを形成するのに使ったデータの量と、
あとはモデルの構造の深さですかね。
ディープランニングだとどれだけノードのネスト構造を作るかって話になると思うんですけど、
それが総数が狭いと当然容量が小さくなるので。
なるほど。ざっくり言うと語彙力が少ないみたいな感じ。
まあまあまあ、そうです。
なるほど。
それでも軽いモデルというか実行可能なモデルで、
それのせいで出るんだったらそれでいいかなというレベルだと思うので、
非常にありがたいかなという感じですね。
そうですね。
ちょっとさっきチャットで共有しましたけど、
21:00
実際の制度としてはこれくらいで、
今日の冒頭にも言った、はいどうも心神ですというのは、
はいどうも心神ですくらいになってて、
当然ですもん、一応そのように取れてると。
はいはいはい。
今言ってくださったような、はいはいはいみたいな挨拶もきれいに入ってるし、
そういう意味だとすごいのが漢字変換とかもできてる?
そうですね。文節が日本語はややこしいんですけど、
それがしっかりしてるっていうのが、
比較的緩和制限とかもちゃんと切れてていいですねという感じですね。
文節ごとにタイムスタンプが切られていて、
連なってる言葉はここまででしょうっていう単位で、
時間の幅が切られてるから、
結構その文字起こしの結果も読みやすくてですね、
Googleの文字起こしとかだと全部繋がっちゃってるんですよね。
もう苦悩点とかなくひたすら最後まで入ってるみたいな。
なのでパッと見たときに、
その文章をいい感じに改行とか形成してあげないと、
日本人でも読み切れない文章だなってなるんですけど、
結構このウィスパーで出てきたやつは、
一呼吸空く単位でちゃんとタイムスタンプが分けられてるんで、
読みやすいですね。
いいですね、これ。非常に頭出しがしやすくて。
このラジオ撮って後に編集してタイムスタンプというか、
話題ごとに頭出しできるようなスタンプで一応付けてるんですけど、
現状はWebの波形を見て目で頭を探してるんですよね。
それが一緒にできそうなんで非常にありがたいですねという感じですね。
そうなんですよ。なのでプロセスとしては今まで、
いろいろデータを作り終わった後にプッシュしてGitに上げてってやってたんですけど、
まずは生の録音データをこれに加わしてから、
いろんな作業を始めるっていうフローにすれば、
楽になる可能性があって、やりたいんだけど、
あまりにも処理時間がかかるもんでグヌグヌってなってる感じですね。
サーバーを自宅に導入するしかねえかなって。
一応そのGitHub ActionsというそのGitHubの自動機能で、
ローカルのPCにリクエストを投げて、
何か新しい音声データがアップロードされたら、
自動でこの処理をかけるっていうプロセス自体を組んだんですけど、
一回走り始めてから終わるまでが長すぎて、
そのプロセスの検証もまだできてないって感じですね。
なるほどね。
あんまり贅沢言わずに、ミディアムとかスモールとかに落としていって、
もう少し様子見てもいいのかもしれないんですけど。
まずそっちでとりあえず環境を整えてからの方が早いかもしれないですね。
24:02
ただ一番最高のモデルでどれくらいの精度が出るのかっていうのも楽しみで見ちゃいたいなっていうのもあって、
ちょっと悩んでる感じですね。
大丈夫ですかね。
はい、そんなところですかね。
じゃあ次の記事です。
マイナビニュースさんからのタイトルが、
リュウグウ母天体の内部に海があった小惑星サンプルから液体の水を発見というタイトルの記事です。
JAXAは9月23日、小惑星探査機ハヤブサ2の新たな研究結果を発表した。
同探査機が地球に持ち帰ったサンプルの重度な粒子を科学的・物理的手法により分析、
リュウグウ母天体の形成から破壊までの歴史を明らかにし、
サンプルの物性値まで組み込んだシミュレーション上で再現することに成功した。
また、サンプル中の結晶内部にあった微小の隙間から液体の水を発見。
これはリュウグウ母天体内部に大量に存在した水が閉じ込められたものとみられるという。
これまで水は水産機を持つ複水、いいんですかね。
ちょっと読み方わかんないですけど。
鉱物の形で存在することがわかっていたが、ほんの微量とはいえ、現在のリュウグウにも液体の水があったというのは驚きだ。
あ、岩水ですね。ごめんなさい。岩水鉱物ですね。
結構長い議事なんでかいつまんで読みますけど、
分析したというのが直径8ミリの粒子などで、
回収サンプルの中でも3番目に大きいと、比較的大きいサンプルに対して放射光施設や微温設備などを活用して分析を行いましたということで、
まずは非破壊検査ですね。
これをやったところ、サンプル内のリュウガ鉄の結晶内部で発見されたと。
MRIみたいに断面が見れるんですけど、その内部に他とは物質性の違う空間があって、
そこに水を二酸化炭素を主成分とする液体が含まれていることが分かりました。
穴が2、3ミクロンぐらいかな。
目で見て分かるレベルではないんですけども、
分析した結果、ちゃんと液体の水があったというのが大発見ですという話ですね。
これもいろいろ分析して解析したところ、リュウグウ母天体。
このリュウグウという小惑星ができる前に、もともとあった天体ですね。
27:01
そこに存在していたものだと考えられています。
リュウグウ母天体は太陽系の誕生から約200万年後、マイナス200度以下の極低温環境で集積。
アルミニウム26度の崩壊熱により、内部で水と二酸化炭素の氷が溶き始め、
300万年かけて最高50度程度まで温められたという。
平波は急程度で、アルカリ性の温泉のような状態でした。
この時に水があって、岩石との対積比で1対1ぐらい存在していたということで、
大分量の水がありましたという感じです。
じゃあこれがどうやってリュウグウになったんですかという感じなんですけれども、
大規模衝突があったということが想定されています。
水があった母天体に10%程度の大きさの非常に質量の大きい天体がぶつかって、
めちゃくちゃ母天体が破壊されて宇宙空間に散らばった一部がリュウグウになりましたということが想定されていますという感じらしいですね。
その衝突したというシミュレーション、シナリオとかも今回のリュウグウから解析した物性知恵を元に解析することで、
精度の高いシミュレーションが可能になったと。
解析した中村氏曰く、どこにも想像が入っていない全て物的証拠に基づいていると、この成果に自信を見せるということらしいです。
さらに、ハヤブサ初号機の時には、サンプルの量が少なすぎて、こういった物性の計測まではできなかった。
今回はたくさんサンプルを持って帰ってくれたので、このシミュレーションを実現できたとのべ、
ハヤブサ2ミッションの完璧な成功に感謝したということらしいです。
他にも時期情報が残っていたとかいろいろ情報が書いてあるんで、読んでみると面白いかなというところでの紹介です。
いやー、ワクワクしますね。素晴らしいね。
いいですよね。
いいですね。もう未来の話すぎて考察する余地がないんですけど。
まあ液体があったら当然、生物の話とかもありますし、個人的に興味深いのが、
温度が50度くらいまで上がったっていうところで、液体がある状態で温度が50度まで上がった。
なのでこれ、衝突さえなければ、それこそ宇宙人じゃないけど、地球外生命体の形成できる環境が揃ってた可能性があるっていう温度だと思ってて。
まあそうですね。
それの実例が今回サンプルとして得られたこと自体がなかなかワクワクするなって感じですね。
30:02
いいですよね。確かに地球と同程度の温度で水もあったっていう条件っていうのが実際に実物のサンプルから採取されたっていうのはすごく大きいことだと思うので。
そう、今までもね、そういう場所はあるだろうは言われてたし、実際そうと言えそうな天体は観測上見つかっているっていう事実だったと思うんですけど、
サンプル上そうだと言い切れますって言われると、めちゃくちゃリアルになってくるなっていう。
そうですね。
最近だと色々研究が進んできて、例えば火星の地下にも氷があるだろうとか、
そういう話もちょくちょく出てきてますけど、地球が近い惑星、環境も似たようなことになるっていうのはそれはそうなので、
今回そうではない、太陽系から離れた天体でもそういうことが発生しているという情報が届いたのはすごく大きいと思っていてて、
思ったより地球型惑星っていうのが実際あり得るよねっていうのが、実際サンプルが確認できたっていうのは、
宇宙人がいそうっていうのが非常に身近に感じられていいなと思う次第でありますね。
間違いないですね。
地球もいつか同じ状態になって、遠い誰かの宇宙人が地球という星はもともとこれくらいの温度だったのかもしれないって、
同じように解析する可能性があるってことですからね。
そうですね。これぶつかったのに300万年くらい前とかだかな?ですからね。
300万年前からのメッセージとかエモいタイトルつけそうなレベルのお話ですよね。
素晴らしいね。
あとはあれかな、その岩石の形成のされ方とかが地球上で考える物理特性とか想定とほぼ変わらないよねっていう傾向が見えてきてるっていうのもなかなか面白いかなって感じですかね。
内部の先ほどの崩壊率と外域の間でその圧力差が生まれたらこういうことが起きるっていうのが多分地球上でも分かったからそういう解析結果になってると思うんですけど、
そういう事実が紐づけられていくっていうこと自体も面白いなとは思いますかね。
そうですね。そこら辺仮説では色々ありましたけど実際にこうやって物証拠が出てくるのが非常に強いと思うので、そこら辺答え合わせというか理論の強度の補強という意味で非常に意義があるのかなと思いますね。
33:02
そうですね。個人的にはどこまでいっても地球の常識、宇宙の非常識みたいなことってあるんじゃないかなと思ってたので、そういうのがちょっとずつなくなっていっているという事実はかなり面白いですね。何か科学がちゃんと科学してる感があってすごい。
まあ宇宙関係は非常に手元にサンプルがあるっていうのがレアケースなんでね。そこら辺は非常に科学している分野ではあると思いますけど。
いやーいいですね。いいですね。
いやーなんか一通り解析が終わったらどっかで展覧会でもやって欲しいですけどね。学会とか。
やるんじゃないかなとは思いますけど。
もう分かったことを点みたいな。
あーはいはいはい。あるんじゃないですかね。順次という感じではありますけど。
やっぱり次のちょっとJAXAのイベントは注目ですね。JAXAのホームページなんかフィードとか発行してたっけ?
わからない。
RSSフィードくらい発行してくれないとちょっと困りますね。
こんだけ面白そうなことをやっといて。
Twitterとかの方が流行るんじゃないかという気がしますけど。
まあはい。今後に注目ということで。
注目ですね。大注目ですね。フォローしとこう。
はい。
じゃあ次私の方で。今日はもう短く2つくらいでいこうかなと思うんですが。
総合TLS認証MTLSとは?ということでクラウドフレアの記事です。
クラウドフレアはネットワークの超大手企業さんのとこですね。
まずTLS認証自体がマニアックな話なのでそこからさらっと触れると。
普段ブラウザでhttpsというURLの先頭でいろんなホームページ見に行ったりしてると思うんですが。
そのhttpsのSはセキュリティのSで安全にブラウザでウェブページを見るための仕組みになってますと。
そこで使われている安全に見る仕掛けっていうのがこのTLS認証というものになってます。
TLSが何の略かとかは別にどうでもいいんですけどざっくりの仕組みとしては。
そのホームページはインターネット上の誰かが立てていてそこにウェブブラウザから覗きに行くみたいなことをやってるんですけど。
そのサーバー側に私はこういう人ですっていう証明書が発行されていて。
ブラウザではその証明書をもらいに行ってふんふんあなたってこういう人なんですねっていうのを見ますと。
自分だけではその証明書が本当に大丈夫な人なのかとかわかんないので。
第三者認証機関というこの人って公的な人大丈夫な人っていうのを問い合わせる人がいて。
その人に問い合わせて大丈夫な人だったら安全な人だねって思ってその相手と通信を始めるという流れがTLS認証になってますと。
36:09
これによってホームページを公開している側とブラウザで見に行く側の間で暗号化された外から覗けない通信をやり取りしてセキュアに保つってことをやってました。
これだけではちょっと足りないよねっていう話になってきてるのがゼロトラストという文脈では足りないよねとなりつつありますと。
ゼロトラストについては先日別の回で軽く触れたと思うんですが。
ユーザーデバイスのネットワークトラフィックをデフォルトで一切信頼しないっていうことを意味していて。
多くのセキュリティ上の脆弱性を排除するのに役立つアプローチとされていて。
先ほどので言うとサーバーはあなた大丈夫ですかって見るわけですが。
つなげにいくクライアント側は誰でもいいという状態でしたと。
ゼロトラストだとつなげにくる人も危ない人かもしれないという立場に立つっていうことですね。
そうなってくるとサーバー側、ホームページを公開する人だけが私こういう人ですっていうことを示すのではなくて。
私こういう人ですけどつないでいいですかっていうのをブラウザ側、クライアント側も示す人が出てきたと。
そこで登場したのがMTLSという仕組みで相互に証明書を交換するという仕掛けになりますと。
このMTLSになってくるとちょっと厄介なのがサーバー側でこのつなげにきた人って大丈夫ですかっていうのを確認する第三者認証機関っていうのがいないことにありますと。
ホームページを公開する人は公的機関に登録した一つになってるかもしれないけど見に来る人は世界中の誰かなので、
その誰かが大丈夫ですかっていうことをどこかに問い合わせに行くっていうのは現実的ではないですと。
なので現実的にはパブリックなインターネット環境で実現できるような認証の仕掛けではなくて、
ローカルなネットワークの中でこの人はつないでいいよってことがあらかじめ分かってる。
例えば社内のネットワークとかそういった環境で使われていくべきでしょうとなってるものになります。
これによって防げるものとしては中間者攻撃。
ブラウザとそのウェブページを公開する人の間に割り込んでデータを覗き込んだりとか、
はたまたその一番手元のブラウザ側になりすますみたいなことができてしまうんですけど、そういったものを防げたりとか。
あとは社内のネットワークの中から悪意あるリクエストをかけるとか、そういったことも防げるようになります。
39:06
最近あってこれが入ることで防げることでいうと、それこそクラウドフレアさんの周りであったんですけど、
社員の一人がフィッシング詐欺みたいなものにあって、
社内ランの中にあるPC自体がウイルスに感染してしまいましたと。
そのPCが他の機器にどんどん横に広がっていって、最終的にアタックしたいところにアタックしてデータを取るみたいな攻撃方法があるんですけど、
その時点で悪意あるアプリケーションというのがクライアント証明書、つなぐ側、ブラウザ側の証明書をちゃんと持っていないという状態になれば、
そのリクエスト自体が失敗するので、ウイルスに感染してもネットワークにつなぎっぱなしだったとしてもそれ以上広がることがないという状態性が作れるというものになっています。
これ自体がどれだけ普及していくのかというところになってくると、結構現実的には難しいところがあって、
この証明書というものを個人が管理したりとか、その証明書に記載するこのアプリケーション、こんなユーザー、こんなタイミングだったら繋いでも大丈夫だよという、
その証明書の確からしさを維持し続けるというのが結構運用上大変になる可能性があって、
単純な導入は結構難しい。何かインフラとかプラットフォームが出てこないと厳しいだろうというのはあるんですけど、
従来型の認証方式、あらゆるユーザーがあらゆるサーバーやあらゆるファイルにアクセスするときに、
AD認証、WindowsのPCにログインするユーザー名とパスワードの認証権限だけでやりとりしきるという運用コストに比べれば、
マシになる可能性もあるので、その辺はいいとこ取りしていくことになるんじゃないかなという話になります。
はい、以上です。
はい、概要から確認させてもらうと、ローカルで運用するときに主に使用する?
うん、現実的には。
うん、現実的には。
なるほど。最後に言ったことが全部な気がしますけど、いいとこ取りできればいいけどねという感じな気がしていて。
これを導入するのは確かにセキュリティの面ではやった方がいいよねっていうのは確かにそれはそうなんですけど、
Windowsのやつの話でも言ったとは思うんですけど、やっぱりちゃんと管理しきれるのかとか権限追加が細かくなりすぎてハザードになりすぎて業務実証が出るんじゃないのかとか、
実際うまく扱わないというか、みんな分かってないと多分そうなってしまうと思っていて。
そうですね。
42:00
でもそれが流出したときのコストに比べるとマシだから、それはそうすべきだっていう話はそれはそうなんですけど、
なかなか実運用された実績というか、実例でどう運用してるのかっていう話が聞きたいなという感じかなと思ってますね。
そうですね。まだ提唱されたばっかりで、その辺の実運用のベストプラクティスとかは正直見えてないと思います。
簡単に想定できるベストプラとしては、例えば個人情報が入っているデータベースサーバーが仮にあったりすると、
そこにアクセスできる権利っていうのは基本的に運用者側にはないわけですよね。
なのでまず運用者側が必ずアクセスしなければいけなくなるっていうのは、
例えば法律的にそこの内容を開示しなさいとかそういう要求があったときだけですと。
でなるとそこにアクセスするのにはもう最低限証明書がいりますよという運用にしておくと、
そのユーザー権限とか簡単な処理ではなくなるそのMTLSプロトコルに対応するという処理自体が非常に他のフローと乖離しているので、
非常に例外的な行動になるからこそ、
ヒューマンエラーとかちょっと悪意を持ってる、ちょっとやっちゃおうくらいでできることではなくなるので、
例外的な処理にも対応しつつ、普段では絶対にアクセスできない状態を維持できるとか。
なるほど、確かに運用強度というか何て言うんでしょう。
運用するデータの性質的にそれはそうすべきだよねって話は実際そうなので、確かにそこはそうした方がいいですよねという感じですね。
逆に何というかあれですね、うまくそういう運用できてないところに対してサービスとしてまるっと提供する方を導入するっていう方が一般企業にとっては楽なのかもしれないですね。
サーバーここサーバー込みでトラストのサーバーとアプリケーションというかこのシステム導入の保守メンテ込みでこのお値段ですという感じかな。
あとはそうですね、ビジネスモデルとしてもこれが活躍するシーンというのが想定されて、
ウェブUIとかウェブページ、ウェブAPIというのがサーバー上提供されていて、それとつながり得る後期とかクライアントデバイス、IoT機器群というのに制限を設けたいと。
45:13
1台月額何円ですみたいなライセンスフィーとして取るっていうなった場合に今までだとそのデバイスのシリアルナンバーとかを事前に登録しておいて、シリアルナンバーをわざわざ通信データに入れて私はこういう人ですという認証フェーズを経て、
それだったらOKだよみたいなことを頑張ってサーバーにデータ処理として追加するっていうようなことがあったり、あとはクライアント側で払い出された専用のログインをしてください。
そのログインユーザーのアクセスセッションを見て、他にアクセスがなければその1ライセンスを使って繋いでもいいですよっていうライセンス管理をするとか、そういう運用をされてたわけですけど、
このMTLSでお互いに証明書を交換し合う関係上、その証明書の中でどれくらいの利用が可能っていうところを盛り込んでおけば、そのビジネスモデルと証明書を1対1で紐づけることができて、
そういうビジネスモデルのためのソフトウェア開発みたいなコストが下がる可能性があって、その辺は役に立つかもしれないです。
確かにそこら辺はエンドユーザーとしても久しぶりにログインするこのサーバーどれだったっけとか、どのアカウント使っていいんだっけとか、たまによくある話ですので、
そういうのが何も気にせずアプリケーションがバックグラウンドでやってくれて、信頼性のある通信として使えるっていうか、非常にありがたいなというところですね。
あと社内であるので言うと、派遣の人と正社員の人でアクセスできるサーバーを変えたいけど、ネットワーク上とかAD認証の設定上、それを分離すると各サーバーの運用コストが高くなりすぎるからやってられないみたいなケースで、
もう社員しか持ってない証明書と派遣にしか渡してない証明書を分離してその企業、IT部が配信するみたいなことをしてしまえば分離がしやすくなるかもしれないですね。
確かにそこら辺はいいですね。確かに。事実それIT部が管理コスト支払えないから実装してないっていう話だけなんですから。
いくつかビジネスと絡めた話はできるかなと思うけど、まだこのMTLS時代が話として提唱されたしかないので、今後の話かなっていうところです。
はい、以上です。
はい、了解です。
48:01
はい、では私の方、最後、ものひとさんの記事です。
科学的検証を得ない再生医療を治療として提供。再生医療法の構造的課題とは?というタイトルの記事です。
京都大学は、2022年9月2日、日本の再生医療と安全性確認確保法、再生医療法の下で、安全性や有効性が疑われる各間細胞治療が提供されている実態を調査し、それが同法の構造的な問題に起因している可能性があることを発表した。
本来治療は、研究によって安全性や有効性が科学的に証明された上で、患者に提供される、しかし日本では自由診療であれば、安全性や有効性が十分に証明されていない治療でも提供できる。
再生医療法は、2017年に一部改正され、厚生労働省のウェブサイトに、再生医療等を受ける者に対する説明文書及び土日文書を公開することが義務付けられている。
今回の研究では、この文書をもとに、現在提供されている各間細胞治療について、国内の状況を正確に把握すべく調査分析した。
その結果、2377の医療機関で3467件の間細胞治療が提供可能になっていた。
それらの治療法の中には、培養した間細胞を患者に投与する治療など、ISSCR国際間細胞学会のガイドラインで認めていない治療法や、科学的エビデンスが確立していないがん免疫治療が多数含まれていた。
このような状況が発生している要因として、研究グループは再生医療法の構造的な課題を指摘している。
研究から治療が実用化されるまでの課題において、研究で安全性と有効性が証明された医療が治療となること、研究と治療の定義とその区分、神奇性の高い未確立医療技術と未検証の治療の区別は重要な基本的概念だ。
しかし、再生医療法では、この3つの基本的概念が明確に区別されていない。
この状況において、研究グループは、科学的エビデンスが確立していない治療が患者に提供されていることにつながる可能性があるとしている。
また今後、再生医療法が改正される際は、3つの基本的概念を明確にし、医療機関や医師と認定再生医療等委員会などとの間で内容を共有できるようにすることが望ましいとしている。
51:04
日本では、2014年に再生医療法が制定され、細胞治療として人に問い寄せる場合は、自由診療でも提供計画について専門委員会の承認を受けたり、厚生労働省に提出したりする必要がある。
しかし、安全性や有効性が明確でない幹細胞治療を禁じているわけではない。これまでの実態調査は、こうした治療法を法律で禁じている国や英語圏からの報告がほとんどだった。
研究グループは今後、再生医療に対する認識や誤解について明らかにするため、アンケート調査の実態や医療と法規制の課題についての検討を進めていく。
ということで、京都大学さんがもともと幹細胞研究の尾という感じで進めていった中で、こういうこともせなあかんのかという感じで、なかなか大変やなという紹介です。
うーん、全然わかってないから、質問攻めになっちゃうんだけど。
はいはい。
まず、再生医療ということ自体が比較的新しいことになっている結果、その再生医療の中で研究から治療フェーズにおける分類が法律上規定されていない結果、
再生医療を行える医療機関においてどのフェーズにある治療法を選ぶかが自由になってしまっていると。
その自由だから研究段階のものが悪いとか治療に似てるからいいとかではなくて、その採用の仕方や適用の仕方っていうのだったり、幹細胞治療の実績自体がそういう分類がされないまま一概に取り扱われることに対して、
誤認を招く、例えば研究段階の治療ばっかりが採用された結果、すごく大きなトラブルを起こして幹細胞治療はよろしくないことだ、みたいな結論が出てしまうとか、そういった誤認を与えかねない運用になっていること自体が課題だと言いたいですかね。
そうですね。そこもすごく大きいなと思っていまして、大学修繕士さんはそこが大きいのかな。私もあんまり詳しくないんですけど、実際、法律で認められている範囲としては実績がしっかりとしていない治療法というのが一位にあふれていて、それが困ったよねと認識していることだと思います。
54:02
なので、その医療面としてもそういうのが乱立した結果、十分なエビデンスが得られないまま、実際どれが一番いいのかっていうのがわからないまま患者に提供する意思もわからないままになってしまうというところもあったりすると思いますし、
どう考えても有意性がないだろうみたいなところも治療法として挙げられてしまうということで、患者としても標準的なものがわからないので、あまり本来効果が高いものを受け入れていたという機会が損失している可能性があるというところかな。
そこら辺のフェーズまで持ってきていないというのが問題だという話なんだと思われますね。
そうですね。だから患者は自分、その治療法に対するリスクよりも、それである程度治るでしょうという見込みの方が、患者利益の方が大きい状態でその治療を選びたいっていうのが第一目標にあるはず。
一般患者であれば。治験に協力しますというポジションだったら別だと思うんですけど、そういう人が、じゃあその医者が説明したことに対して、どのフェーズなんですかとか聞けるわけもないので、
治験に協力したくないですという患者に対しては、そのフェーズまで行っているものから医者を選ぶべきということになっていて、それが報告、説明文書及び医者としてちゃんと明らかになっていること、患者が期待していることとバランスが取れているという結論になっているというのが、
ちゃんと報告されていると厚生労働省としては期待する通り管理できているという状態になるはずだけど、それが見えないってことですよね。
まあそうですね。なので、まあでもこれを大学から言うっていうのもなかなか。
そうですね。厚生労働省が起こることなんじゃないのって思っちゃうけど。
そうですね。
労働省としては法律がそうなっているから、その法律の範囲で運用するっていうことになるのか。
まあまあ立法は違うからという話にでもなるのかもしれへんですけど。
そうですね。
まあ大学としてのスタンスは非常に大学らしいなと思っていて。
要は分析して、あまり良くない状態ですよというエビデンスを積み重ねた上で、上進するつもりなのかもしれないですね。
そういうところとしては非常に良いと思いますけど。
57:01
まあなんというか言った通り、大学以外のところで担保してほしいなと素人目には思ってしまうような記事ですね。
そうですね。
それこそ最初の法整備の時に専門委員会、第三者専門委員会を立てているはずで、
その人たちは言ってそうなもんだけどね。
他の医療関係の法律では同じような分類をしていると思うんで。
まあまあ、幹細胞っていうのは比較的新しい成立分野だったので、緩めにしましょうみたいな判断があったのかもしれないですね。
ああ、そうか。それはあるかもしれないですね。
当時研究フェーズくらいのものしか録りなくて、実績を積むためにちょっと緩く始めるしかなかったみたいな。
そう、研究を活発化させて、多数ラインを複数で走らせて、幹細胞治療っていうものをコンテンツって言っちゃったんですね。
選択性のある治療法の仕様ということをやろうと思ったら、思ったよりも薄く広く広がっちゃったよっていう話なんですかね。
でもそれはなんかしゃーない気がしてきたな。だから次の改定タイミングはいつですかっていうことだけの話なのかなっていう気がしてきた。
あと改定するにしても案に盛り込まないといけないと思うので、基本的に今あんまりよろしくない状態ですよっていうのをやっぱり立法側に示す必要がある。
そうだね。
国会で議論してもらう必要があるとかになるのかな。
そうだね。ということはやはりそれを調査してファクトとして示す必要があって、大学かーって。
大学かーという感じではありますけどね。まあまあ大学病院とかもあるんでね。まあそういう意味ではいいかもしれない。
医師学会とかがやるかって言ったらなんかやらん気もするな。なんか違う気するね。どこがやるか。
まあでも個人的には医師会とかの方が近い気がするんですけどね。治療。
医師会がちゃんと選べないじゃんっていう思いから出てきてくれるべきっていう感じ。
そうですね。研究段階としてはむしろ平たくというか、言い方悪いですけど研究段階としてはデータが積み重なる方向なんで、どちらかというと治療の方が本来困ると思うんですよね。
さっき言った通り適切な治療がなされていない。で、間細胞治療っていうのはそういうもんだなっていう評判にもなってしまうというところで、あんまりよろしくない状態になるという意味で言うと治療側、医師側の方がメインに被害をこむっているのかなという気はしますけどね。
1:00:14
いやー、むずいねそれ。医師からしてみるとあらゆる治療法の中の一つの治療法でしかなくて、間細胞治療って。
なるほど。
その中で一つの治療に対しての不満感をメイントピックに上げるかって言ったらそれよりも優先順位高いことがもっとあるよねってなりそうだよね、医師会の中では。
それはそうかもしれないですね。医師としてはその薬を選ぶというのと一緒で、有効な薬が出てきました、じゃあこれ使ってみようかっていう段階であって、間細胞治療というもの自体に対する、なんていうのかな、不表被害まで守る立場ではないというか。
そうそうそうそう。
そうですね。まあそれは確かにそうか。そう考えるとまあ確かに京都大学さんが一番先鋒に出すのが生後方かな。
まあもやっとはするんですけど、なんかそのお互いの割り切りがありすぎるっていう感じもするから、まあもやっとはするんですけど、多分、医師の優先順位からするとしたらの方だろうな。
まあ確かにそれはありそうな気がする。ちょっと目の前の手の届く範囲がちょっと違うっていうのは確かにそうなんで、分野として。
それはそうですね。
そうですね。あと起こるとしたら、患者のその細胞とか状態をとって、ちゃんと経過が良くなってるかとかを検証する人たちっているじゃないですか。
はい。
それを専門に、どういう人たちっていうのか忘れちゃったけど、そういう人たちは結構これはこの状態不満だと思いますね。
うーん、まあね。どういうことですか。それはデータが乱立してるからっていう話ですか。
えーと、その、どうせ実態を取るサンプルだったら、過去にどういう研究が行われてきて、それではどういうふうになったという結果があるから、今回こういう経過になってることが、
まあ妥当に効いてそう、妥当に効いてなさそう、治療法を変えるべき、変えないべきみたいな提案につなげるわけじゃないですか。
はい。
その前提が研究段階のものって言われちゃうと、めっちゃ取り扱い困りません。
うーん、まあ。
1:03:00
その研究段階で実例数が少ないからこの患者には適応できなかったなのか、これから効き始めるもんなのかとか、
その、いつこれは変えた方がいいというジャッジをするのかとか、その辺の妥当性が難しい気がする。
ああ、まあその先行データが充実してないんで、運用する側として困るよねという話ですかね。
そうですね。
まあそれは。
リオリーとかかな。
それはそうだけど、研究段階というものを扱っている時点でそれは、何て言うんですか。
うーん。
うーん、なんだ、見込み範囲内というか。
まあね。
分からんものをぶん回してる時点で、っていう気もしますけどね。
そうか。
まあでもそうだね。
そこを安全方向に倒しすぎると、いずれにたっても新しい治療を使えないみたいな話になっちゃうから。
うーん。
まあね。
バランスか。
はい。
はい。
まあという感じでしたというところです。
はい。
じゃあ今日はこんなもんですかね。
はい。
本日の内容は小ノートにまとめていますのでご確認ください。
リカーログでご意見ご感想やこんなことをお話ししていたい方もお待ちしています。
メールアドレスはリカーログアットマーク gmail.com になります。
ツイッターもやっていますのでフォローやダイレクトメッセージもお待ちしています。
本番組はポッドキャスト、スポッティファイ、ユーチューブライブで聞くことができます。
ぜひそちらでもサブスクライブよろしくお願いいたします。
はいではお疲れ様でした。
はいお疲れ様でした。
