SSH over HTTP3
面白いもので始めましたよ。
ほう、なんでございましょう。
出始めたっていうか、出ようとしてるくらいなんですけど。
ちょっとマニアックすぎて恐縮なんですが、
昨今、セキュリティー界隈で問題視されまくってるというか、
セキュリティーインシデントになってる8割くらいがSSHからの侵入だっていったところがあって、
デファクトとしては、このSSHをいかに挙げずに、
他の手段でアクセスできるようにするか、みたいなので盛り上がりつつあるんですけど。
IETFの方で、HTTP3の上で動くSSHの話が出始めましたと。
HTTP3、もう覚えてるか分かんないですけど、
クイックと言われてるやつで、今のHTTP2よりも早く接続できるよっていう、
クイックってそのままなんですが、その上でセキュリティー担保できるよというものですと。
このSSHがHTTP3上で動くって何がいいかというと、
外から見るとHTTP3にしか見えないっていったところが大変素晴らしくて、
通信プロトコルとして開けなきゃいけないポートがHTTP3だけになっていて、
今後登場してくるであろういろんなWebサービスはこのHTTP3しか開いてないので、
相手が何か全く読めないと。
その上で、その仕様がある上で、その相手先の通信がHTTP3の上で動いてるSSHだということを隠蔽する仕掛けが追加で入ってたりとかするっていったところで、
今後クラウド上のサーバーとかそういったものに通信する上では、
これが標準になっていくのかなと思って非常に期待感がありますっていう話です。
3週ぐらい追いついてない感じがしますけど、
SSHがセキュアじゃないっていうのは、構造上仕方がない話だったりするわけ?
そうでもないはずなんですけどね。
なんでそんなに危ないってことになってるの?
管理者…
お問われしました。
言葉の選び方が難しいんですが。
人間がうまく管理できてないと。
そうです。
認証機とか証明書でちゃんと通信すればよくて、証明書アクセスだけ許可とか、
SSHで入られた後に渡す権限の最小化とか、そういったことをしっかり運用すればいいんですが、
なんと世の中はですね、初期に入っている特権IDをSSHログイン許可してあって、
かつそれがすごくパスワード流出されてそうなメジャーなベーシック認証、
ユーザー名とパスワードだけだったりとか、なんなら初期パスワードから変更してないまま世界に公開するみたいな事件が絶えなくてですね。
そういった現実があるので、SSHポート時代が摘出され始めちゃってるっていう、
ポートじゃない、SSHプロトコル時代が摘出されちゃってるって感じですかね。
人間には早かったという話ですか。
そうですね。
それがHTTP3で抱え込むと大丈夫っていうのは、それはなぜに?
HTTP3プロトコルの時点で証明書を許可しているからですね。
なるほどね。
だからそういうガバガバな通信がそもそも許容できない。
で、そこの土台の上でやるっていう時点で土台のセキュリティが乗っかってるんで、まあマシであろうという話。
そう。
なるほど。
だからバカが使っても流出しないっていう、流出しないというか攻撃されないっていう。
攻撃しづらいっていう感じですね。
そうですね、しづらいですね。
まあわかりました。
なるほどね。
バカになれるって結構大事で。
忙しいとかね、いろんな理由でバカになってしまうことが世の中往々にしてあるからセキュリティインシデントが起きるので、バカになっても安全でフェイルセーフなのは大変素晴らしいという話ですね。
まあそうですね、あんまり気にせんで使えるっていうのは良いものなので、はい。
はい、という感じで。
まあもう少しで登場してくると思うので、皆さんそれまでは毎日敏感に気をつけて生きていきましょうという、まあそういう枕でした。
はい。
はい。
クロード3の特徴と性能
じゃあ今日の本でいきたいと思います。
1点目、クロード3の話です。
記事としてはアンソロピックさん本家のIntroduction to the Next Generation of Cloudという公式のリリースのページです。
英語の内容なのでかいつまんで話していきます。
まずそもそもこのクロードというものが何かといったところからですけれども、
ChatGPTとかと対抗して出てきているLLM、生成AIの言語モデルの1つですと。
もともとオープンAI社の中にいた人が独立して立ち上げたもので、
クロード2の時点からよりビジネス向けということで歌ってきた生成AIモデルになっていて、
GPTのモデルと比べてもより多くのデータを扱えるってことが有意性になっていたものでした。
最近になってGPT-4のターボとかが出てきた中で、
クロード2ではなかなか追いつけないっていったところがあって、
またオープンAI社の方のモデルにみんなが寄っていっていたわけですけれども、
満を持してまたクロードの新しい3が出てきたよという話になっています。
私は今までもクラウドベンダーと絡めて話してたんですが、
このクロードというのはAWS、クラウドの中で言えばAmazon関係のところでデファクトになっているものになっていて、
AWS公式が出してきているものよりもはるかに性能の良いものをAWSとしてはサポートしていますといった状態になっています。
このクロード3なんですが、大きく3つのものを出してきています。
それがハイクとソネットとオプスという3つです。
どういう違いがあるかというと、応答速度と賢さで承知区域ありますよというものになっています。
表がログスケールになっていて、なかなかエンジニア向けだなという表現なんですけど、
ハイクは賢くないけどめっちゃ速いです。
ソネットは今までのK風通り。
オプスは今まで以上に賢いけど遅いというものですね。
このオプスが100万トーク、今までのが20Kだったのに対して100Kまでいけるといったことですごく注目を集めているものです。
それだけ取れるようになってくると、ちょっとした論文5本くらいを一気に読ませたりとかそんなこともできるので、
いろんな幅が広がりますねということになっています。
これはアンソロピック社が自社で出しているものなので、本当かいなというのはある程度あるんですが、
クロード3のオプスであればGPT-4よりもいいですよと言っています。
このクロード3はですね、画像認識。
オープンAI社が出しているGPTはGPT-4Vという画像入力にもサポートしてますよということで、
オープンAI社のGPT-4と違って、クロード3のモデルであれば言語も画像入力も両方できるということで、
デプロイとか運用のやりやすさ含めて、またそれもいいねという話になっています。
結構面白い比較というか、前より良くなったよと言っているものに面白いデータがあってですね、
クロード3の比較と将来性
クロードとか生成AIのモデルにはですね、こういうことは言っちゃいけないよというのが倫理的な観点だったりとかいろんなものとして入っているんですけれども、
それがあるせいで、本来答えられるのに誤ってその規制の中じゃないかと思って答えないみたいなことが起きていたようです。
それの発生率というのが、もともとのクロードだと25%くらいあったのが10%くらいまで抑えられましたよというアップデートが来ています。
他にはですね、AIは合っていることも間違っていることも言うといった中で、合っているのがより合っている方向に、間違っているのはより言わない方向になってほしいというのがあるんですけれども、
その点に対してちゃんと成長してますよと、特に分からないのもちゃんと分からないと言えてますよといったところもスコアとして伸びているところです。
あとはオープンAI社と比べてといったところなんですけれども、クロードの先ほど言っていたような大量に入力できるという特徴をですね、
ここに対してオープンAI社のGPTとかも頑張って追従して入力トークン数というのを増やしているんですが、
実態としてはですね、その入力入れた部分の全てをちゃんと解釈できていない。
解釈には前半の方が強く後半の方が弱めにというムラができてしまっているというのが論文として上がってたんですけれども、
今回クロード3の結果としては満遍なくちゃんと取れてますよというレポートが上がってきていたりするので、
こちらが期待する通りの大量の入力というのができそうですよという報告も来ていますと。
といった中で、これは実際にアンソロピック社本家であれば使えますし、
AWSであれば、Ops以外は現状もすぐ使えて、Opsもそのうちやってくるといったところで、
またAzureとAWSの対抗だったりとか、OpenAIとこのアンソロピックの戦いというのが加熱していきそうだなといったところです。
ちょっと余談にはなってくるんですが、OpenAI社の方のGPTがちょっと評判を落とし始めているところがあってですね、
OpenAI社は世の中のデファクトになっているせいか、すごくいろんなところで倫理的な指摘とか受けていて、
AIに対しての教育が加速していますと。
あれも言うな、これも言うな、こういうことには気をつけろというのをいっぱい言われてですね、
AIの心理的安全性が下がっているのか、回答率が悪くなっているという悲しいことが起きていてですね、
結果的にまだそういった外部の、攻撃じゃないな、外部の指導を受けていないモデルが今のところ賢く回答してくれているように見えるということで、
Geminiだったりこの辺のCloudだったりの方が賢く見えていたりするところがあるので、
現時点だとこのCloud3というのは一番に立ったのかなというふうに受け止めています。
はい、なかなか人間が要求するものがややこしすぎて難しいですねという感じがありますけど、
現時点で最もインテリジェントであると言っている感じで、素晴らしいんじゃないかなと思います。
本家が言っている話なんで、外部比較の結果が欲しいところではありますけどねと思います。
そこも数値もあるんですけど、結構大きいなと思っているのがさっき言っていた回答しないパーセンテージの減少という話で、
25%を昔あったという話で、それだとちょっと使っていて使いづらいなと思ってしまうなという数値だと思いますけど、
それが10%前後にまで下がっているという話なんで、ここは結構大きな進歩なのかなというところはあります。
さっき言っていた相対的にGDP-4の方が規制が強くなってきていて、こういうパーセンテージが上がっていっているという話だとすると、
作り込む時にもあれもこれも除外してという判定が結構めんどくさいと思うので、
そういう意味で使いやすいのかなと思いつつ、使いやすいっていうことになってみんながこれを使っていくとGDP-4と同じような道を行きそうなので難しいですね。
データベースを積む分には積めば積むほど賢くなるっていう作りなので、
まあ良いと言えば良いんでしょうけど、なんかなあと思いながら見てますね。
その辺はビジネス的な観点で言えば責任共有モデルみたいな話で、
生のモデルを使える代わりにその生のモデルが入ったことに対して責任を取る、使う側が責任を取るっていうスタイルにするのか、
いやモデルの方で色々規制をかけて、そのモデルが入ったことに対してはモデルの提供者に責任を取ってほしいなのか、
で結構また変わってきて、そこら辺のバランスはなんか行ったり来たりをしばらくはするんだろうなと思ってますね。
それでもなんか国によっても対応変わったりするとめんどくさそうだなって気がしますね。
法規制はめっちゃ変わると思います今の話。
でなんかそれに合わせたローカライズなんてしてられへんので、一つのモデルを賢くするとめちゃくちゃコストかけてるのでね。
なんか分岐したりできひんと思うので、そう考えると難しいね。
なんか法規制で一発でなんか5体以上ってなったりする可能性がありそう。
そうね、このモデルは今世界的に一番賢いけど我が国では使えないっていうことは起きてくるでしょうね。
なかなかそこら辺難しいなと思いつつ、まあそうね、うーんって感じ。
使ってる側の感覚としては、生のモデルを扱って出てくるものに対して自分で責任を取れるように制限をかけるのを頑張りましょうっていうのは、
もう非現実的すぎるというか、1年かかってもうまい責任を取れる状態に落とし込むのはできないだろうなと思ってるので、
ある程度はやっぱりやってもらわないといけなくて、そのある程度感は日本だったら日本の法規制の範囲でとか、そういう話になるんだろうなと思いますね。
そうですね、まあそこら辺も作り込み次第かなと思いますけど、チェックボックスみたいな簡単にポンポンポンとできればいいけどそういうわけではなくて、
ブレイクされたりする可能性もあるというところが難しいところ。
はい、というところで、最新のモデルの話でした。
はい、じゃあ今ちょうどブレイクという話が出たので、そのブレイクに対するサービスが登場してきた話をします。
生成AIの脆弱性とファイアウォール
次の話がクラウドフレア、生成AIを守るためのファイアウォール、ファイアウォール4AI開発へ従来とは異なる脆弱性に対応ということで、
パブリッキーからのプレスリリースですね。
クラウドフレアは、生成AIを守るためのファイアウォール、ファイアウォール4AIの開発意向を発表しました。
クラウドフレアは従来のWebアプリケーションの脆弱性と、生成AIを用いたアプリケーションには共通する脆弱性もある一方で、
生成AIのモデルをジャックして不正なアクションを実行できるようにするような、生成AIの仕組みに起因する固有の脆弱性も存在すると説明します。
生成AIは、自然言語を用いた曖昧なプロンプトの操作に対して、
たとえ同じプロンプトが入力されたとしても、状況によって正確に予測することが困難であるような、
多様な答えや結果が示されるという点で、特定の操作に対して特定の動作が引き起こされる、
決定論的な従来のアプリケーションと振る舞いが大きく異なるとクラウドフレアは指摘します。
さらに従来のアプリケーションでは、コードによるコントロール部分とデータベースによるデータ部分が分離されており、
あらかじめコードにより定義された操作だけが行われることが分かっているため、
コードの部分に対してチェックや操作の逸脱が起こらないような仕組みを集中させることで、データの保護をすることができました。
生成AIはこれとは異なり、データそのものが学習プロセスを通じてモデルの一部になるため、
データがプロンプトによる操作に対してどのように提供されるのかを管理することは困難です。
クラウドフレアが開発するFirewall for AIでは、すでにWebアプリケーションファイアウォールの機能として提供している
レートの制限やセンシティブなデータの検出などの機能に加えて、
こうした生成AI独自の仕組みに起因する脆弱性についても検出し、対応する機能を実装すると説明されています。
またFirewall for AIはクラウドフレアのネットワークを利用して可能な限りユーザーの近くで提供されることで、
エンドユーザーとモデルの両方を悪用や攻撃から保護することができるとも説明されています。
ということで、さっきのようなジェールブレイクみたいな話に対するFirewallサービスですね。
Firewall for AIの機能
話聞いてて思ったと思うんですが、具体的にどうやったら守れるのってことには一切言及せず、そういう開発を頑張りますという話ですね。
ここが他社で出てくるっていうのは必然かなというところで、
コンピューターがセキュリティ対策ソフトを外注して一般化していったところから、最終的にはWindows Defenderにもつきましたけれども、
そういった流れと同じ道を踏み始めているなといったところになります。
私たちがこれをどう受け止めるかといったところなんですが、何が変化するかというと、
リクエストしたときに今までほど多様な回答というのが得られなくなる可能性がありますと。
要するにこのFirewall for AIでやることっていうのは、
AIが動かす振る舞いを自分たち開発者側、ビジネスサービス提供側の範囲になるべく留める。
ユーザーが意図せず範囲外を超えてAIを操作するようなことをなくすということなので、
新しいアイデアを探索したりとか壁打ちしたり、
自分の心理的安全性の確保という形でメンターになってもらったりとか、
そういったところでの用途になってくると逆風になってしまいかねないサービスではあるんですが、
それ以上にビジネスリスクも高まっているということで、
その辺のバランスが今後どうなっていくのか注目していく感じの話になります。
こういうのが外部から出てくるっていうのはどうなんですかね。
ある種健全なのかもしれないけど、検閲を外部で実施するっていうのは。
本家が対応しきれないというか、
開発リソースが足りないっていうのがあるんじゃないかなという気はしているので、
そういう意味では、ある種の健全性が担保できるというか、
作り込めてないものを出されるより、私たちが作り込んだやつを適用した方がいいよねっていうのは分かる話かなと思いますね。
たださっき言ってた決定論的な振る舞いをしないものに対してどう検閲するかってどうするの?
でも出力に対しては一定の大丈夫、NGっていうのは人間が見れば言えるわけで、
それと同じことをするのかなっていう気もするんではないけど、
そんなんできるのって気もするしな。
時間とお金をクソほどかけていいなら、例えばですが、
生成AIにユーザーが入力するであろうプロンプトを100万件くらい作ってもらいます。
それを流しました。
その時に起きた振る舞いの結果、類似なものをまとめて大体分類してもらいます。
Firewall for AIの実装の難しさ
100万件の実行結果は大体この範囲に留まってますっていう地図ができますよね。
その地図の外れ値を見た時にその外れ値が給与しているのであればそこがOKだし、
給与できないのであればそこの間を敷地として設定してこのファイアウォールに加わせ直す。
その敷地を超えたリクエストに対してはちょっと想定外の振る舞いだったということで
リトライをするのかユーザーにもう一回お願いするのかっていうハンドリングになるんじゃないかなと思いますね。
分かるけどユーザー側としてはめんどくさいんでそれ。
まずこのファイアウォールで弾かれてそれを通ったとしても、
生成AIの方でうまい回答が出てくるかどうかわからないみたいな状況なわけでしょうね。
ウェブブラウザにウイルス対策ソフトAIが対応しましたっていう例明記あったじゃないですか。
あの頃ってブラウザでホームページ開いたらこのページ怪しいかもみたいなページに1回飛ばされて、
まあ大丈夫だろうって飛んで本気が見えて何が引っかかったんやこれっていう気持ちになりながら先に進むみたいなのあるじゃないですか。
多分ああいう体験になるんじゃないかなと思います。
まあ警告レベルだったらまだいいか確かに。弾かれるんじゃなくて危なそうだけど通しますかって言われてはいって押すんだったらまあ打ち直す必要はないかな。
そうですね。
まあまあまだマシかなという感じはしますけど。
なるほどね。
このハンドリングをどういうルールにするのかは利用者のサービス的次第じゃん。
まあ金融とか病院とかその辺でそれをホイホイとはいはいえないよねにするのか。
まあ注意事項くらいにしとくのか。
まあカスタマイズ性のあれだと思いますけど。
うん、なるほどね。
まあ確かにそう考えると、まあ通ってきた道ですから、ある種まあそうですねという感じ。
結局こういう存在の意義って多分技術的な確からしさというよりも経営層的なリスクヘッジ的な側面の方が強いと思ってて。
なんかよくわからない技術に対して何かしら発生し得るリスクを少しでもお金かけて減らしておこうっていう取り組みだと思うんで。
まあ実態としてそういう形になっても一旦はしゃーないかなという気持ちがあります。
そうね。
ウイルス対策ソフトしっかり成熟してきたらね、結論を本家が取り込めばいいだけの話なので。
そうですね。
まあいいんじゃないでしょうか。
モデルの進化がね、ある程度落ち着いてきたらこういうのも役割を終えるタイミングが来れると思うんですけど。
モデルが進化してガバッと変わりましたって言った時に、今はあ、いいものが出てきたっていう話でみんな飛びつき続けてますけど、
本当にそれがリスクない行動ですかっていうそういう面はずっとついて回ってると思うので。
はいはい。
まあそういった意味では、その流れとは別口で存在しているこういうファイアウォールサービスっていうのはあってもいいのかなって感じ。
まあ確かに。
なんかこうサービス変えたらそのサービスの設定一覧全部見直さないといけないのはダルすぎるのでね。
そう。
でも顧客は絶対新しいAI出たんだから早くそのAI使えるようにしてくれよって言ってくるのは間違いないわけで。
はいはい。
そういった時に、まあAIで上げようってなる判断の中で、いやでも最低限このファイアウォール入れてるから致命的なことにならんでしょうっていう判断ができるかできないかは結構大事な気がする。
うん、そうね。なるほどね。
はい、というサービスの話でした。
はい。
はい、じゃあ次。
これはもう前にも話した話なんでさらっと行きます。
GitHub Copilot Enterpriseの一般提供をお返しということでGitHubブログからです。
GitHub Copilotの公開当初よりお客様から自社のコードやプロセスに合わせてGitHub Copilotをカスタマイズして使いたいという声が寄せられていました。
開発者は組織が保有するコードベース固有の問題、まぐ、脆弱性を特定して解決ができなければ、製品リリースよりも問題の解読に多くの時間を費やすことになります。
さらに開発者は1日に数時間しかコードを書いていないことが多く、クリエイティブな仕事をするどころか、終始ありきたりな仕事に追われがちです。
そのため、組織内のナレッジを活用できず、開発者が創造性を十分に発揮してお客様のためにより多くのものを開発できずにいるのです。
GitHubはそれを買いようとしています。
生成AIをエディターに組み込むことで、GitHub Copilotは瞬く間にソフトウェア開発の新時代を定義し、開発者の生産性と幸福度は明らかに高めました。
2月27日、GitHubは開発者ツールの次なるフロンティアを開拓するGitHub Copilot Enterpriseの一般提供開始したことをお知らせします。
これにより開発者は組織のナレッジを簡単に活用できるようになります。
チームメンバーはパブリックコードやプライベートコードについて質問ができ、新しいコードベースを素早く理解したり、
エンジニアリングチームの一貫性を高め、全員が同じ基準に則って過去の作業に手を加えることができます。
ということで、GitHub Copilotの拡張が一般提供されましたよという話です。
内容については1回話したので、もう軽くおさらいです。
今まではVSコード、ID上で提案してくれたりとか、ID上でコードについて質問したりといったところだったんですけれども、
GitHub Copilot EnterpriseによってGitHubページ、ページという言い方が知られるかな。
GitHubのWebサイトのほうですね。
イシューを管理したりとかプルリクエストを管理したりといったような、
そのサービス上で生成AIをフル活用していきます。
具体的には今議論されているイシューの予約をまとめて、
今どういう問題が何が起きててっていうところのサマリーを確認して、
その問題にすぐ追従したりとか、プルリクエストが上がってきたときにそのプルリクエストの内容がどんなものなのかっていうのを
コードの変更点から抽出してプルリクエストを発行してくれたりとか、
あとは他の人が指摘してきたものに対して、
じゃあそれってどうやって修正するのっていうコパイロとなりのソースコードの修正案を付与してきたりといったような形で、
より議論のそばで生成AIが使えるようになるといった形になります。
今のところちょっとどういう仕掛けになっているのかが不透明なところとしては、
GitHubコパイロとエンタープライズによって既に上がっている自社のチームの各リポジトリから、
どういうイシューが上がっているかとか、どういう注意事項が上がっているかっていう議論の内容であったり、
あとはソースコードの内容から、この会社では一般的にこう書いているといったものが提案されたりということが行えるようなんですが、
GitHubコパイロとしては、AIの学習にお客さんのコードは使えませんよというふうに歌っている上で、
そういうことができると言っているので、その能力がどれくらいになっているのか、
外部ファイルとして参照しているだけではなかなか解決できないような話ではあると思うので、
そこら辺がどう実現されていて実体使えるものなのかどうかというのが気になっているポイントかなというところです。
最後、私の所感ではあるんですけれども、GitHubコパイロとは確かに新しい時代を作ったというのは間違いないと思うんですが、
一方でGitHubコパイロに期待している開発力というのは非常に限定的で、
ソースコードの一部分の開発にしかなかなか役に立たないといったことが続いてきたというのが実態としてあります。
そういった中で、そのコードを扱える力というのが拡張されたというアップデートではなく、
生成アイが使える場所が増えたというようなアップデートなので、
本質的な開発力の向上といったところに対するアプローチがどの程度になっているのか、
その辺がこのGitHubコパイロとエンタープライズを導入してみて、
ロケット打ち上げの延期
一番チェックするべきポイントかなと思って受け止めています。
以上です。
最後に言ったことが重要かなと思っていて、
機能が追加されたのはまあいいかなと思いますけど、
GitHub上でコードを書かないよねっていう話が思っていて、
エディターというか開発環境で書く書く開発していて、
それをGitで管理するということになっていると思うので、
そのプルリクエストの要約も便利ではあるから、
まあそこら辺は使えるかもしれないけど、
これは本質的には人間がわかりやすいプルリクを書けっていう話だと思うんですけど、
そういうわけでもいかんとなるとね、
こういうのはまあいいんじゃないかなと思いますけど。
それ以外はどうなんだろうなと本当に思ってしまいますね。
まあでもそのGitHubというか実質マイクロソフトが、
まあ何かそのこのブームの中でできることってなった中で、
GitHubという強い非常に強力なプラットフォームを持っているので、
まあそこでできることを考えた結果とりあえず載せてみたっていう話なのかなという。
そうですね。
かなあとは思いますけど。
そうですね。
1年ぐらいしたら無くなってそうな気が全然はないけど。
そうね、盛り上がりは結構すぐ沈下してしまうかもしれないなっていうのはあります。
おっしゃってた通りで、
例えばプルリクエストっていうのは書くべきことっていうのは、
なぜそもそもこういう変更が必要だったのか。
で、その人はどういうスキルセットを持っているから一旦こうしようと思ったのかだったりとか、
他にどういう影響があるからこうしたのかみたいな話が本質的なレビューポイントであって、
そのGit上に出てきた変更点、ここのソースがこう変わりましたっていったところから語れる内容ではないじゃないですか。
はい。
なので自動生成されるそのプルリクエストの文章っていうのは、
コードファイルのこの行がこんな風に変更されています。
これによってその行はこういう処理に変わりましたっていうロジックの説明をプルリクエストで書いて欲しいわけじゃないと思うので、
自動生成されたものはそうだよなとはなると思うんですけど、
でっていう感じで自動生成されたプルリクエストのレビューアーがひそことめに発するのは、
そもそもこれの目的は何ですかっていうコメントがつくんだろうなと思いますね。
それ考えたらあれですよね、プルリクを出す前にそれを表示してもらって、
その変更内容はコピープやコピピで必要だと思うので書いておくとして、
その前になんでそういうことをやりたかったかっていう、
自分を人間が書いた上でプルリクをすべき。
スペースワンのロケット開発
そうですね。
だよねっていう話の使い方になると思う。
そう考えるとやっぱり開発環境側で組み込むべき機能だよなという感じになっちゃいそうな感じ。
でも、マイクロソフトが手をつけられるところっていうと、
じゃあVisual Studioでやるんですかいという話になってしまうので。
そうですね。
使ってる人はいると思うけど、そっちよりはパイがでかいというのは事実なので、
こっちに載せたんかなという気もせんでもないけど。
そうなんですよね。
開発生成AIは代わりにやってくれることではなくて、
やることを助けてくれるツールだっていうのがもう分かってきた中で、
プルリクエストが自動発行できますとかいう話をされても、
あまりピンとこなくなってきているっていうのが、
ちょっと時代変化とこのプロジェクトの半マッチなところだったのかなと思いますね。
安倍執行役員の意気込み
そうですね。
意外とここを足がかりにしてGitHub上で開発するみたいな、
スキーブを押し出してくるかもしれないので、
そうだったらワンチャンね、あると思いますけど。
ご存知かは知らないですけど、
GitHubのリポジトリのページ開いて、
Periodとかを押すとVS Code立ち上がるんですよ、Web上で。
そのリポジトリをVS Codeで開いたかのような状態で開発を始められて、
そこにAdd-onとかもいろいろと足していけるんですね。
なので、そのGitHub上でこういうのがリッチになった結果、
もしかしたらVS Codeよりもブラウザベースでやれば、
その辺がシームレスにつながってすごく便利ですよっていう、
そのIDEとこのリポジトリ管理サービスの連携みたいなのが将来に見据えていて、
これはそれの一つのつながりポイントでしかないという世界があるのかもしれないです。
なんかそれは結構良さそうに聞こえますけどね。
実際廊下に開発環境を置かないと、
細かいことがうまくいかんでめんどくさいとかなる可能性はありますけど、
そこまでこちゃこちゃしなくて、Git上でサンドボックス的に、
あまり気にせずにバージョンを上げたり戻したりしつつ、
開発環境を比較するみたいなのができる。
っていうとまあ強いんじゃないのかなとは思いますね。
そうですね。
そうですね。
とにもかくブラウザベースみたいな世の中になってきてますので。
それはそう。
ブラウザで動くの最強みたいなのがあればいいと思いますね。
そうですね。
めっちゃ余談差し込んでいいですか。
最近知ったんですけど、
Edgeのメニューにアプリっていうのがあってですね。
今Edge持ってたら開いてほしいんですけど、
右上の3点レーター、リーダー開いてアプリっていうところを開くと、
このサイトをアプリとしてインストールっていうメニューがあるんですよ。
これ何やってくれるかっていうと、
今開いてるページをスタートメニューとかタスクバーから起動するアプリとして登録できて、
ブラウザを開かなくても直接そのウェブページのみが開くウィンドウを立ち上げられるっていう機能ですね。
最近ウェブサービスが結構増えすぎてて、
ブラウザのお気に入り管理とかがめちゃくちゃめんどくさくなってきてたりとか、
よく開くページ、右からショートカットで飛べるようになってるけど、
ブラウザでやりたいこととよく開くアプリでやりたいことって何か違うんだよなっていう感覚とかがあって、
すごくもやもやしてたんですが、
最近このアプリのインストールを知って、
頻繁に見に行くやつは全部アプリとして登録してタスクバーに並べてる方が幸せな感じだったので、
使ってみてください。
確かに、すごい画面シンプルだし、アドレスバーもないみたいなね。
そうそうそう。これでいいじゃんっていう。
これ単体が開いてるっていう雰囲気になって、
いいじゃないですか。確かに。
結局ね、定期的にアクセスするサイトって、
そのサイト見て終わりで特に遷移することないからねっていう感じだし。
ウィンドウズがもともといろんなアプリケーションを並列して起動するという枠組みがあるのに、
ブラウザの中で同じことやってても仕方がないよねっていうのは、
本当にそう。
ブラウザに広げていろんなアプリ立ち上げてると、
本当これがOSでいいじゃんっていう気持ちになってくるんだけど、
OSにするほど便利でもないっていうブラウザ。
考えるとブラウザはね、検索とかの情報収集用でタブを使うと決め込んで、
それ以外はアプリ化しておく?
いいと思いますと。
最近そういう運用でちょっとQOLが上がりました。
良いこと知りました。
という余談は終わりにして、私の方は以上です。
次じゃあ最後、私の方から。
先に結果の方からなんですけど、NHKさんのサイトの記事で、
民間ロケット打ち上げ機理由は海上警戒区域内に船というタイトルの記事です。
東京のベンチャー企業が開発したロケットが9日午前、和歌山県から打ち上げられる予定でしたが、
安全対策のために設けた海上の警戒区域内に船がいたとして、
打ち上げは直前で延期となりました。
新たな打ち上げは今月13日以降になるということです。
大手精密機器メーカーなどが出資する東京のベンチャー企業スペースワンは、
和歌山県串本町に整備したロケット発射場で、
9日11時過ぎに独自開発したロケットを打ち上げる予定でした。
しかし企業によりますと、安全対策のために発射場近くに設けた海上の警戒区域内に船がいたため、
打ち上げを直前で延期したということです。
打ち上げる予定だったのは、全長約18メートルの固体燃料式の小型ロケットカイロスの初号機で、
ロケットや発射場に不具合は確認されていないということです。
新たな打ち上げの日程は、国際宇宙ステーションに長期滞在している宇宙飛行士の古川さんらが地球に帰還するタイミングと重ならないよう、
今月13日以降にするとしています。
記者会見でスペース1の安倍執行役員は何としても打ち上げたいと思っていたので、延期はいかんです。
次は必ず打ち上げたいですと話していました。
このロケットには政府の小型衛星が搭載されていて、機動への投入が成功すれば、
民間単独では国内で初めてとなるために注目されていますということです。
先にこの記事の内容でちょっとしゃべりますか。
ちょっと打ち上げようと思ったんですけど無理でしたという話でちょっと残念ですねという感じなんですけど、
初めてだしよくあることなんで、そんなに落胆する話ではないかなと。
無理に打ち上げて何か事故ってしまっても、その方が大問題になってしまうので、良いのではないかと思っています。
特に最近九州というか、ぐらいでしかなかった打ち上げサイト、この規模のロケットを打ち上げられるサイトというのが増えてきているので、
ここ10年ぐらいで、そういう意味で和歌山県近畿からも打ち上げられるというのは非常にメリットがあるというか、
将来を感じさせるので是非成功させてほしいなと思っているところです。
全然ネガティブな話はなくて、よくあることなので、非常にいかんというコメントがちょっと一人歩きしている感はありますけど、
本当安全第一でやるべきことだし、他の後続の民間宇宙事業というのが安心して続けられる状態にするというのが、
こういう先行者にとって非常に重要なところだと思っているので、満を持してやっていただければなという感じですかね。
そうですね。という感じで、粛々と進めてもらえればいいんですけど、このロケット自体が結構他と黄色が違うなという話をしようかなと思うんですけども、
ロケットの詳細があんまり出てこないのが結構面白いなと思ってまして、
そもそもこのロケットが、スペース1、作っているスペース1が、
キアノンIHIエアロサーフェース清水建設日本製作投資銀行などの出資により、2018年7月に設立されたと、
それら予算情報なんですけど、ということなんですけども、今回打ち上げるロケット、出資元から見ておそらくキアノンが1枚どころか10枚噛んでいる気がするんですけども、
噛んでいる短期打ち上げ型小型衛星という感じで、これがいわゆる国防系の感じの衛星を想定しているわけなんですよね。
内閣衛星情報センターによると、日本の情報収集衛星に不足の事態が発生した場合に、一定期間その機能を代替することを目的として、
短期間に打ち上げ型の小型衛星の実証実験を実施するために打ち上げられるという目的がありまして、
この衛星の初原もあまり出てこないし、ロケットの初原もあまり出てこないという感じで、広報にあまりやる気がないみたいな状況になっているんですね。
その中でロケットクラスターが断片的な情報からいろいろ推測したりもしているんですけども、
当日も公式の放送というのが、スペースワーカーの運営する放送ではなくて、地元の振興議会みたいなところが出演していて、
芸人さんとかを呼んでいて、結構面白いステージとかを組んでいたりしたので、
そういう意味で結構、日本のJAXAとかインターステアテクノロジーとかがやっている、自社で広報を頑張るとは違う方向が向いていて、結構面白いなというか、違いがあるなという感じですね。
その辺はスポンサー事情的な話?
だと思いますね。あんまり情報を出したくないなと思いますね。
言ってしまうと、このロケットが格納されている格納倉庫というか、格納部が思いっきし軍事目的の緑色みたいな感じで色しているし、
結構あんまり外観を派手な色に塗ったりする気はないんだなという感じがひしひしと感じていますね。
名前というか、スポンサーのリストアップだけ見ると若干勘ぐっちゃうというか、そういう軍事方向に寄ってても不思議ではないなという感じは受けちゃいますね。
100%私の想像ですけど、軍事目的の受注になっているのは確実なんですけど、
キアノンさんとかHIさんとかはそれ込みで自社で結構やりたいことがあるんじゃないかなと思っていて、
SSH over HTTP/3の要点
ただ自社でやるってなると限界があるので、今回初回の打ち上げは軍事想定で防衛庁からお金出してもらったみたいな感じになっているんじゃないのかなという気がしています。
今回のというか、組み込んで運用してもらったみたいな感じかなと思っていて、
そういう意味では情報収集衛星も定期的に実験とかはすると思うんですけど、
打ち上げがいっぱい打ち上げて波に乗ってきたら他の民間の衛星とかも全然バンバン打ち上げられる感じになるんじゃないのかなと思うので、
そういう意味では今後もずっとクローズドな軍事目的だけで使うというわけではないとは思います。
なるほどね。
あとは非公開だろうけど、価格比較とかいろいろ気になるポイントはあるので、その辺落ち着いたら公開してほしいですね。
そうですね、そこら辺全然出てこないんで、ちょっとアレなんですけども。
ロケットの直径が何歩だったかな、なんかちょっとサイズ忘れちゃったんですけど、
中国とかのロケットと同じ径をしているらしいんですよね。
なのでそういう互換性を狙っているんじゃないのかなという下馬評はちょっとありましたね。
国際市場で中国のやつに乗らんかったみたいな時に同じくらいの出力というか出せるので、
うちのやつに乗せられますよって言って国際競技総力を高めるみたいなのがあるんじゃないのかなという気はするとかいうのと、
あと防衛庁のペラページであるんですけど、将来的に3段目にメタンエンジンを乗せて
出力を増強するというのがあって、これが結構面白くて、メタンエンジンって今日本で持ってない技術なんですよね。
持ってないって言って怒られるか。あんまり運用してない技術。
ただ、H3とかで使っているエンジンの水素とかを使うやつよりは理論上は数値が低いんだけど、
水素ってめっちゃ冷やさないと運用できないところが大変なので、そういう意味で使い勝手の良いエンジンみたいなのがメタンエンジンの立ち位置らしいんですよね。
なので将来的にバンバンロケット打ち上げるってなると水素が大変なのでやっぱりメタンの方がいいよねみたいな話もある。
中で今回増強型として将来的にこいつにメタンを乗せていくっていうのは日本のロケットの技術開発としても足掛かりになるので、そこも結構注目ポイントなんじゃないのかなと。
これが成功すると他にも展開できていいことがあるんじゃないのかなという気がするという感じですね。
メタンエンジンの技術開発
なんか話だけ聞くととりあえず民間企業として日本で打ち上げ終わったら海外進出を積極的にやりそうな雰囲気するね。
海外進出というか海外のペイロードを載せる。
もうあるしロケット自体を海外に売るっていうのも全然ありそうと思ったけど。
無くはない。無くはないけどどこまで行くかな。そこまで行ったら大キンポッシャーだとは思うけど。
製造権を売るとかそんな話かもしれんけどね。
携帯はいろいろあるだろうから、できなくはないと思うし。
そこまで行ったら大キンポッシャーだな確かに。
話を聞く分と民間レベルっていったところで、ロケットであってすごくコアな技術であるのは間違いないけど。
めちゃくちゃガチガチな輸出規制を受けるような設計だったりとかになってるのかって言われると、そうでもないのかなっていうふうに聞くだけでは思っていて。
そうするとどっちかというと日本の重要な国とかに、重要な同盟国とかそういった辺りに打って回る一つの商材として国が連携した方がお得だなと思って聞いてました。
まあその輸出規制的な話を言うとかなりガチガチにかかるとは思いますけど。
たとえば北朝鮮とかが今頑張って打ち上げてるじゃないですかという話を考えると。
まあもちろん敵対国はセラサーそうですけどね。
技術がありますし、できるだけ国内で管理した方がいいとかいう話はあるとは思いますけどね。
ただ言うて、全ての国が自国の打ち上げサイトから打ち上げてるかというとそういうわけでもないので、将来的にはあるんじゃないのかなという気はしますけど。
ちなみに名前を聞いた時にイカロスじゃないんだって思った。
なるほど。
でもカイロスも調べてみたらギリシャ語でチャンスっていう意味なんですって。
なんで、なんかどっちも悪くないなって。
まあ悪くないねって感じですね。
イカロスは逆にあれか、あんまりロケットに使うといいことないのかな。
なさそうな気もせんでもないけど。
落ちちゃうっていう感じになる。
衛星の方のイカロスはそういう逸話に乗っかったってのがあると思いますからね。
という感じなので、今後13日かな、来週にも打ち上げられるっていう話なので。
打ち上げられて成功するといいなと思いますけど、初回などであんまり期待しすぎないくらいでいきますという感じです。
じゃあ今日はこんなところですかね。
お疲れ様でした。
お疲れ様でした。
