夏の気候の影響
こんばんは、Replay.fm第36回です。
こんばんは。
うっす。
こんばんは。
2日ぶりですね。
2日ぶりですね。
今日暑い。
バカ暑い。
今も?
暑い。風呂上がりの、なんかこの汗の引かなさが異常。
あー、確かに。
湿度がね、言われて今言われて、俺も暑いってことに気づいたの。
いやー、今年も35度とか行くんですかね。
行くんじゃないですか。
あの、なんか黒潮の蛇行がさ、云々かんだみたいなニュースあったよね。
黒潮の蛇行。1から10までわかんない。
黒潮の蛇行?
黒潮、あー、潮。
そうそうそう。
へー。
で、これが終わると、海水温のなんか都合で、
うんうんうん。
猛暑が収まるみたいな話がなんかあった気がすんだけど、気のせいかもしれない。
マジで?
斜めとか蛇行する可能性、正常ではない状態。
ほうほうほうほう。
へー、こんな話があったんだ。
収束する気がしがある。
でもさ、なんか今年、気持ち5月涼しい気がすんだよな、去年より。
気のせいかな。
そうかなー。
なんか去年ゴールデンウィーク時点でも30度とか連発してた気がするんだけど。
あー。
気のせいかしら、2020年ゴールデンウィーク。
気になってしゃべり始めちゃったけど。
まあね、今年の夏の暑さも予想される、予想できるポッドキャスターなんでね、一応。
こんな有益情報ないよね。
あー、でも例年に比べて全国的に高い予想ですって書いてあんの、今年の夏。
え、じゃあもうダメじゃん。
ダメじゃん、終わったわ。
あー、終わった。
プロダクトのセキュリティ
解散。
解散。
家にいよう。
いやー、困っちゃうな。
いやー、よかったよ。
週2出社の会社から出てくる。
ずっとの暑い中。
確かにね。
週2で会社に行かなくても。
そっかそっか。
そこで出社ありかどうかが節日が変わってくるんだね。
いや、結構節日だよね。
なんか普通にしんどいもんな。
しかもさ、なんかもう夏場とかさ、家にいると普通に着替えてるもん。
途中で。
1日1着、確かにね、分かるもん。
いやー、確かにな。
もうさ、まあ別に会社にね、行くことの良さもあるけどさ。
なんかその、命を削って行ってる感が。
そうなんだよね、なんか。
日によっては。
うん、ある。
まあ命を削ってでも行った方がいい場面は、そりゃある。
まあまあ。
ケースバイケースね。
あるだろうけどさ。
なんか日によってはさ、そもそももう、
気象庁からとかから、外出控えてくださいみたいな日あるもんね。
近年だと。
あるね。
なんか猛暑日の2段階ぐらい強くなったやつみたいな。
もうよく分かんなくなってくる。
インフレが。
ね。
いやー。
強いよ。
まあまあ、そんな感じで。
今年の夏も暑そうですが、強く行きましょう。
備えて。
夏に備えて。
きついなー。
寒いより暑い方がきついなー。
いや、分かる。
全然無理。
ね。
よし。
じゃあ1個目から行きますか。
はい、行きましょう。
これは、僕読むか。
まあどっち読もう、はい。
マルチプロダクトのセキュリティを担保するプロダクトリーディニスチェックの勧め。
上梨エンジニアブログですね。
はい。
なんか多いよね、なんやかんやセキュリティ系の記事。
うん、なんやかんや多いね。
なんか上梨さんのブログ全部メイトしてるけど、セキュリティマリアめっちゃ高い気がするな。
うんうんうん。なんかすごいモチベーションが高い。
やっぱこの西川さんって方のアウトプット頻度がそうだね。
まあ他の記事もあるっちゃあるけど。
リアクトの記事とか、まあいいや。
この記事自体はタイトルが結構ほぼほぼ回収してる感あるんだけど、
プロダクトリーディニスチェックリストっていうのがSREのプラクティスでしたっけ?
そうですね、SREのプラクティスであって、
これ何かっていうと、マイクロサービスアーキテクチャにおいて、
新しいマイクロサービスをリリースするときに、
プロダクションレディーかどうかっていうのをチェックするようなリストのことを指すっていうふうに解釈すればいいかなと思っていて、
で、上梨さんもマイクロサービスアーキテクチャではないのかな?
マイクロサービスアーキテクチャの話は書いてなかったんで分かんないんですけど、
少なくとも複数のプロダクトを展開しているし、
多分ポンポンいろいろ出していくっていう部分があって、
そうなったときにその複数のプロダクターに対して、
等しくプロダクトセキュリティの最低限のレベルを担保する必要があって、
そこに対していろいろアプローチがあるような話で、
普通だとサストでとかダストで調べるというか担保するとか、
脆弱性診断で担保するみたいなものも考えられるけど、
開発のスピードとのトレードオフみたいなところを考えたときに、
セキュリティ版のプロダクションリリースチェックリストを作って、
それを実際に新しいプロダクトとかをリリースするエンジニアにセルフチェックしてもらって、
っていう運用をしていますって話ですね。
具体的にはいくつか例が書いてあるんですけど、
クッキーにHTTPオンリー属性が設定されてるとか、
バリデーションがサーバーサイドでやられてるとか、
皆さんよく知るプラクティスがあって、
55個ぐらいの項目をチェックしてるらしいっていうところですね。
実際運用してみた感想とかも書いてあって、
結構いい感触を得てるよみたいなところがあって、
プロダクトのセキュリティレベルが担保されるのはもちろん、
開発メンバーとかがDNSチェックのチェックを通して、
セキュリティの知識をインプットできるみたいな部分もあって、
いい感触があるっていうところとか、
単純に抜け漏れみたいな部分も結構効いてるよっていう感じですね。
実践と課題
そんな感じかな。
この割とイエス・ノーでサクサク答えられる、
肉実に答えられる質問っていうのが割と個人的にはいいなって思いました。
そうだね、確かに確かに。
イエス・ノーで言い切れないのが入ってきた途端にちょっとコスト上がる感はあるよね。
あとはエビデンスをどう提示しますかみたいな部分なのかな。
エビデンスっていうのはこれからちゃんと。
エビデンスチェックの、そうそうそうそう。
イエスって答えられた根拠はこれですよね。
その辺はどうね。
そういうのって結構環境によるというか、
でもそんな、質問によるか、そこは。
割とテーマとかはそういうところで効いてくるなと思っていて、
何をもってこれイエスって答えられますっていう風なエビデンスを揃える、
あるいは何をもってそれがそうですって言えるかどうかみたいなところを理解できるかとか、
その辺で調べるのに手間取ったりとかエビデンス揃えるのに時間がかかったりとかすると、
結構手間がかかるなって思うので。
そうだね、だしやっぱその、
割とスナップショット的なものでもある気はするから。
レディネスチェック自体はね、割とそういうスナップショット的な。
だいたいそうだよね、たぶんね、基本的に。
なんかそういうイメージがあるな。
理想系は常にレディネスをトラッキングし続けるのがいいんだろうなと思うんだけど。
その辺も言及があるな、ちょっと見逃してたけど。
今はリリース時だけやってるけど、定期チェックをしたいし、
ある程度はチェックの自動化もしたいみたいに書いてある。
それができたら理想だよね。
バランスが大事だろうな、記事にも書いてあるけど。
そうだね、特定の条件下においてはこれがマスターになるよみたいな話とかは、
これはちょっと待ってね。
なるほどね。
そうだね、これはね、TechBlogに書かれてるから書いていいやつだと思う。
メルカリの場合は、
メルカリのプロダクションレディネスチェックは、
レディネスレベルっていうのが一応あって、
レディネスレベルに応じてチェック項目が変わるんだよね。
だから割と妥当なやり方だよなと思うし。
そうそうそう。
なんか今公開してるのが最新か忘れたけど、
プロダクションレディネスチェックのなんか、
これだ、OSS出してくれてたよね。
でも5年前、4年前でしょ、更新。
全然違うと思う、今。
そうなんだ。
だんだん運用も変わってるね。
でもおおむねそこに書いてあるような気がするな。
レディネスレベルとかもそこで引き抜けされてるし。
ほんとだ。
あ、SLOで決めた。
まずね、SLOも変わる。
いやー、あの、
俺が働いてた頃のやつはたぶんこれなんだよな。
そうだね。俺も記憶に残ってるのはね、割とそれ。
いやー、いいっすね。
なんかこれ系地味だけど、
効くよねーという気がしてて結構。
効くし、
社内のセキュリティ担当の視点で見た時に、
2度でも3度でもみたいな感覚が減るんじゃないかなと思うんだよね。
毎回これ言ってるなーみたいなものを減らせると思うから。
確かにね。
あとは毎回これ言ってるなーであっても、
ポンと頭から抜けるタイミングってやっぱあって、
他の何か大きなものに、
何か思考のリソースを持ってかれてる時とかに、
何かそういうのを忘れたりすることがやっぱりあって、
っていう中で何か割と固定のこういう説問リストが決まっていて、
そこはもう考えなくていい、そこで勝手にカバーされるから考えなくていい、
っていうのはすごく助かるところではあるよね。
間違いない。
また何かこれで、これでカバーできる範囲みたいなのがどれぐらいなのかっていうのを
ちょっと聞いてみたいかもな。例えばだけど、
なんか、分からんな。
プロダクションレジネスチェックを通すものは必ず通るで運用としては正しいのかな。
要はレジネスチェックを通さないものとかはないのかとか、
通してるけど、
これは何らかの理由によってほとんどの項目がスルーされる
みたいなものとかあったりしないのかなとかさ。
これPoCだからレジネスチェックいらないですとか。
確かにね。
それで全部カバーできるもの。あるいは、
これはユーザーフェイシングな部分に全くインターフェースのないもので、
別にRPCとかも備えてないですみたいなサービスが、
例えばのときとかに、
果たしてどれだけこれが機能するのかとか。
別に全部難しいな。そういうのってでもはいかいいえとかじゃないじゃん。
はいでもいいえでもないというか、無関係っていう多分回答が必要だったりするし。
マイクロサービスの理解
そういうのが入ってきたときに、イレギュラーケースとしてちゃんときれいに対応できるのかできないのかとか。
そういう運用上のすごく細かい部分はちょっと聞いてみたいなとは思うな。
確かにね。
なんかそもそもどのぐらいプロダクト出てるんだろうと思ったけど、
サービスサイトだとあんまり思ってからは見えないかもな。
裏側がなんかいろいろ。
でもきっとマイクロサービスなんじゃないの?これって違うのかな。
どういう単位でやってんだろうね。
言及はないんだよね。
だからマイクロサービスだったらマイクロサービスって言う気がするから。
どういう一部層とかなんか。
分かんない。別に特に理由がなく言い切ってないだけの話なんだけど。
ちょっと他の記事とかで研究されてたりするのかな。
そうね。
インクラストドクチャー。
紙無し採用情報。
エンジニアページ。
急に紙無し研究を始める。
あ、あった。
技術スタックは。
まあでも、なんかゴートしか書いてないな。
どうなんでしょうか。
クバネテスは使ってる?
使ってるとは書いてないね。
クバネテス使ってるって記事もなんか見たことない気がするな。
西川さん何とかして呼ぼうぜ。
いい記事多いから。
全く接点がないからな。
ワンホップすれば実は接点があるから。
呼べるかもしれない。
なんかコスポメさんとかにX聞いたら教えてくんねえか。
確かにそっち、そうだね。それがいいかもね。
いいな。
気になるな。
いやでもさ、モノリスでさ。
でも多分我々の思っているレディネスチェックとは違うんだろうな、対象の単位が。
本当にプロダクト単位でやってるんだろうな、きっと。
そうじゃないとさ、クッキーのHTTPオンリー運転の話とか出てこないと思うんだよね。
そうだね、そうだね。
基準的にAWSリイベントのレポート記事かセキュリティー記事かやろう、大体。
そんな感じですか。いやでも良き記事だった。
じゃあ次行きますか。
AIエージェントのトラフィック問題
行きましょう。
タイトルだけ読もうかな。
Forget IPs Using Cryptography to Verify Bot and Agent Traffic
クラウドフレアのブログですね。
平たく言うと、AIアジェントとかBotのトラフィックの増加に伴って、
違うな、AIアジェントキーンなんだよね、多分あくまでね。
AIアジェントキーンでBotとAgentのトラフィックがめっちゃ増えていて、
ユーザーエージェントヘッダーとかIPアドレスに依存した従来のBotのベリフィケーションのメカニズムは
しんどいよねっていうのが挙げられていて、
HTTPのメッセージ署名とMTLSの2つを新しいというか、
方法論として紹介しているという記事でございます。
将来的にはそういうメカニズムがクラウドフレアのAI監査とかBot管理製品に
統合される予定だよっていう話を書いてくれてるのかな。
どうでした?
なんか、なるほどなという。
何がなるほどかっていうと、
コメントにも書いたけど、なんていうか、
これ系の話ってどうやってブロックするかみたいな、
割となんか課題ベースというか問題意識を持って、
どうすんねんみたいな話とかが多いイメージがあったけど、
この話はどっちかっていうと、
ちゃんと正規にアクセスするような裏返せ性AIのBotみたいなものがあったときに、
正規のものと野良のやつをちゃんと見分け方法を提供して、
正規のやつは、記事の書きぶり的には契約結ぶみたいな表現をしていて、
分かんないですけど、
オープンAIがあるメディアと契約して、
オープンAI、1月いくら貼るかにそのメディアにオープンAIのBotからアクセスさせてくださいみたいな契約を結んで、
その後このMTレッスンとかで結んでみたいな仕組み作るって話かなと思っていて、
何ていうか、これにちゃんとみんな乗っかる世界性になって、
ある種フリーライトじゃなくペースする世界になるのがいいんじゃないかなっていう気持ちというか、
この時代ならではのトピックだなっていう気はするけど、
そんなにみんなちゃんとやってくれるんだったりとか、
あとは、なんだろうね、例えばプレイグラウンドM…プレイグラ…間違えちゃったよね、
プレイライトMCPか、MCPプレイライトだっけ、もうどっちか忘れちゃったけど、
あれとかは多分もう一生ノラで割り続けるから、
ああいうのはもうブロックするしかない、ブロックするしかないというか、
ブロックしたい人はもう、何ていうか、
ブロックするしか手段がないよねとかはあるだろうなと思いつつ、
どういう世界を目指してるかみたいなところがもうちょっと分かるといい気はするけど、
でもそういう解釈を自分はしたな。
なんか感覚的にこれでじゃあ有料記事とかもGPTが貫通してようやく取ってきてくれるようになるかというと、
ならなそうだなって思って。
っていうのもあるし、コード決済が乱立して、
この支払い手段が使えますステッカーが偉いこっちゃになったみたいな感じになりそうな気もしていて、
あのサービスもこのサービスも全部クライアントの検証できるようにしないといけないみたいな、
普通にサービス提供側としてはダルっていう感じがする。
でも本当にその世界に行ったらクラウドフレアがお金稼ぎをできるようになるんじゃない?
そこ打ち入れたらまるっとできますよみたいな感じにしそう。
その上でどこを許可するかのアラウリストだけがクラウドフレア上で、
あなたが管理できる部分ですよって、それだけを管理していけばいいですよっていう話になるのかな。
そんな感じ。
だからそういう繋がり方をしそう、なんかこの記事を出してる感じは。
この製品投稿の話は読み飛ばしちゃったんだけど。
個々人が多分実装するのはしんどいっていうのは間違いないかな。
いやーでもさー。
うーん、なんか。
実際どうなんだろうね、このAIエンジェントトラフィックと死ぬ気で戦ってる人たちとか。
あんまメディア側のお気持ちみたいなの見たことなくて、どう思ってるんだろうね。
広告とかで稼ぐようなメディアは何回か話してたけど、
AIエンジェント経由で情報取られちゃったら、
トラフィック料金がかかるだけでリターンがないみたいな話があるはずで。
この時代どう生き抜いていくことになるんだろうね。
それに対してこれがあったら本当に解決するのかみたいな。
いやーまあでもなー。
生成AIの原価がそれでめちゃくちゃ上がったら、
なんかサビスとして成り立たないような気もするしな。
いやー。
うーん。
いやー無理だと思うんだよなー。
いやーわからん、なんかこれがうまくいく方法も。
わからんその、なんていうか。
基礎にある技術としてこれが使われていくっていう世界観はあるのかもしれないけど、
これで丸く収まりますみたいな感じは多分ないと思うんだよなー。
うーん。
うーん。
そうねー。
なんかもう2,3って必要なのかなー。
どっちかっていうとさ、そのなんか、
あー。
どっちかっていうとエージェントに自分の鍵を持たせておいて、
で、例えばだけど有料記事を配信しているようなサービスだったら、
利用者の鍵を持って署名をしておくことによって、
アクセスしているブラウザを操作しているのが契約者本人であるっていうのを担保するみたいな、
そういう仕組みならあり得るんじゃないかなと思うんだけど、
でもねー絶対やんないんだよなーそんななんか。
やんないよなーなんか。
やんないのと、そういう生成AIの使い方をしている人は多分、
その2位のメディアを取ってきてみたいな感じっていうより、
オープンクエスチョンで割と投げたら。
そうだよねー。
だからそもそもなんかその生成AIができないコンテンツ自体の価値がめちゃくちゃ薄まっていく感じになる。
なるほどねー。
まあなんか例外としてありそうっちゃありそうなのはわかんないけど、
なんかで見たけどなんか論文周りの話とか、
何かしら認証とかをしないと絶対アクセスできないようなリソースは。
っていうのもあるし、論文とかだと原点を当たらないっていう選択肢は多分なくって、
特性上。だから、
まあそういうところは確かに今俺が言ったようなやり方があり得るのかもね。
確かに普通の人が普通に使う分には、
割と投げて割と取ってきてもらうっていうのは確かに多いだろうし。
使ってた思ったことないもんな。
逆にだからそこに格差が出てくるんだろうね。
それでリーチできないところは廃れていくんだろうね。
ずっと思ってるけどこの世界観加速していったら、
人が書くメディア全部なくなるんじゃないかなと思ってるんだけどどうなるんだろうね。
せいせい愛が作ったコンテンツをせいせい愛が学習して回り続けるインターネットになるのかな。
知らんけど。
セキュリティエンジニアの未来
目指してるのは楽園かディストピアか。
普通に山奥にこもってカフェとかやりたいな。
最近ちょっとすごく思ったけど、
趣味ですごく細々とギターを弾いてるんだけど、
いいよ。絶対に代替されないから。
音楽自体は出てるんだけど、
弾くという体験とかはさ、
頼れないというか。
練習計画作るぐらいは使えるけど。
だから山奥にこもるは結構音質的な回答だと思うよ。
個人的に。
ギターちょっと考えたんだけど、
続く気がしないんだよな。
一緒にやろう。一緒にやる人いれば何とかなる。
続く気がしないんだよな。
あと仕事してない時間ってだいたい車のこと考えてて今。
その状態のうちはやらなくていいかもね。
多分箇所分時間が足りなくなると思う。
そうそうそうそう。車もね面白いよ、それで言うと。
ぶち込むなって。広げるなって。
こんな広げてくるとは思わなかった。
だいたい不可能性に限っては結構。
確かに。
負けてない気がする。
それは間違いない。
確かにな。
だいたい不可能な体験を。
あと人材に、前回も話したけど。
あ、次がその話じゃん。
そうなんです。ちょうどいい流れになったところで。
CTOに問うAIに代替されないセキュリティエンジニアとは。
flat securityさんの記事ですね。
インタビュー形式の記事になっていて、
flat securityの取締役CTOのつばめと、
執行役員プロフェッショナルサービス事業CTOのしがさんの2人が
インタビューの対象になっているような感じでございます。
で、なんか割と結構この
AIに対する人間の役割
AIに代替されない人材というものはそもそも存在しないよみたいなことを言っていったりとかして、
割と冒頭の方で結構ショッキングな表現だよなと思いつつ読んでたんだけど。
なんか個人的には納得感全体としてあるなっていう。
なんか特に確かにと思ったのはその
AIを作る人になった方がいいみたいな話がめっちゃあったじゃないですか。
AIを使う人になることはできるしみんな考えてるけど、
裏側を作れるようになることで原理原則を理解してみたいな。
昔で言うとなんか低レイヤーがわかるとその上のスキルに生きてくるみたいなのと全く違う。
結構同じ話で、で匠の開発を実行して実際にそう思ったみたいな話は
めっちゃ納得感の強い勉強しなきゃなっていう気持ちがありつつ、
なんかAIに代替されない人材が存在しないは結構わかるという気持ちと、ただ
表現のは嫌なのかもしれないけど、本当にそうなのかなっていう部分があって、
なんかノーションに今パッとあったけど、
これをそもそもいろんな記事に入れればよかったな。
ティワダさんの技術選定の新美顔っていう名スライドの2025年版が出たんですけど、
なんか性性相回りのことにも触れていて、
なんていうか、いくつかその多分強い界隈で結構活躍してるエンジニアの
LLMに関する発言とかを引用してたりするんだけど、
なんかAIは知識の代替ではなく増幅機とか、
まあ、AIが助手席から運転席に行って、
まあ人間が運転席から助手席へみたいな表現とか、
まあいろいろあるんだけど、当時て思ったのは、
なんだろうな、だいたい、
まあでもいつか100%だいたいされるのかな。
その、今んとこの所感は割合はめちゃくちゃ減るんだけど、
なくなるわけではないんじゃないかなっていう気はしているというか、
ちょっとうまく言えないんだけど。
いや、なんかね、その感覚はね、結構分かる。
分かるんだよ、分かるんだけど、その、
そうなんでね、分かるんだけどって言ってるのは、その、
なんか、まあでもそうとも言い切れないよなとも思うし、
で、なんか一定ポジショントークはあると思うんだよね。
ああ、まあまあ。
そうね、そうかもしれない。
AIを作る側の人間か、そう、うーん、そうね、
まあここまで、うーん、確かに、結構言い切ってるもんな。
AIに代替されないし、全てはAIに代替され、
残るのはAIを作る側の人間か、そうでないかだけだと考えてます。
いやー。
まあ分かんないけどね、その何年スパンでそれを見越して、
その語っているのかが分からないから、
100年スパンの人かもしんないし、
5年スパンでそう言ってるのか100年スパンでそう言ってるのかで
全然話の中身変わってくると思っていて、
例えばだけど、この間なんかXで誰かが投稿してて、
ああ確かにって思ったのは、なんか髪を切る人っていう部分、
その散髪というのは確かに機械化が難しいよねみたいなことを言ってる人がいて、
ああ確かにって思って、
頭の形は様々だし、背角とかも様々だし、
なんか紙質とか、
なんか好みとかそういうところまで全部含めて、
その機械化自動化みたいな部分って多分結構難しくて。
なんかその確かにって思いつつて、
その考え方で言うと結構ソフトウェアがやっぱ特殊なんだろうなって気がするな。
いや、なんか分かんないけど、髪を切る仕事も原理上は可能な気がするんだよ、自動化は。
ただ、
技術的には可能だろうね。
そうそうそう。
でもコストリターンがどう考えても見えないみたいな。
だから人間がやった方が圧倒的に安いし、
まあ人間の質にたどり着くまでのコストがきついって話がある気がしてて。
某パン工場も嘘か本当か知らないけど、
自動化するより人間がやった方が安いから人間を雇ってやるみたいな話とか聞いたことがある。
そういう総域分岐点みたいなのがいろんな領域にあると思うんだけど、
それが差があるんだろうね。
そう、ソフトウェアは、ソフトウェアの世界に閉じてるうちはめちゃくちゃそのラインが低いんだろうなって気がするし。
だからそう解釈すると確かに大体、
されるのは時間の問題って考え方は結構ちょっと腑に落ちたかもな。
多分普遍の理論みたいなのって一定あると思っていて、
多分技術選定の神秘感みたいなこの話の中でもきっとどっかでそういう話が根底にあるんじゃないかなって今ちょっと眺めながら思ってるんだけど、
例えばだけど、工業生産におけるスケールメリットみたいなものってきっと普遍の理論だと思うんだよね。
例えば紙を切る機械を設計するAIを作ったとしても、
多分オーダーメイドで紙を切れるようなめちゃくちゃ汎用的な機械が作れるかっていうと多分それはかなり、
まあそこそこのクオリティDになったらできるかもしれないけどなかなか難しかったみたいな話とか、
じゃあなんか人とか体格に合わせてめちゃくちゃ機械側をオーダーメイドしましょうみたいなことやったら今度高くなっちゃうしみたいな。
多分そういう大量生産をすることによって安くなるみたいなスケールメリットとかは多分普遍の理論としてあったりとかすると思うから、
物理世界に出てくるタイミングでどこかそういう普遍の理論にぶち当たる部分があると思うんだよね。
で、多分その辺の境目の中できっとAIに代替されない何かっていうのが出てくるような気がしていて、
なんかちょっとうまく表現できないんだけど、なんかあるような気がするんだよな。
だからなんか本当に全部置き換えられるかというと、まあ技術的には置き換え可能なのかもしれないけど、
理論上置き換えできたとしても、実際的にじゃあそれを置き換えできるんですかみたいな話になると、
まあなんか少なくとも5年10年スパンではまだ来ないだろうなとは思うんだよな。
職業としての可能性
うーん、そうね。
なんか原理上可能だしコストリターンも見合うけど、なんかそこに社会が適応するまでの時間はすごくかかるだろうなって気がするよね。
それもあるだろうね。
なんかクラウド、オンプレクラウドの話でさえ、まあこれたぶん10年以上経ってると思うけど、残ってるわけだしとか思うと。
まあそこで最前線に立つべきだよねって気持ちはあるけど。
まああるいは社会の方がなんかもっと早く変容を迎えるっていう可能性もあると思っていて、
例えば散髪だったらなんか人に切ってもらうというのがものすごく高級な何かになってしまって、
みんなほぼ坊主ですみたいな。買ってもらった坊主ですみんなみたいな社会になるかもしれない。
なるほどね、まあ確かに。おもろいな。
ごく一部のお金持ちだけがなんか人に髪を切ってもらってみたいな、世界になってるかもしれない。
なるほどね。
そういうその想像もつかない、なんか訳のわからない社会、世界みたいなのが訪れる可能性はあるよね。
バグバウンティーの未来
うん、確かにね。
それでもなんか残ると思うんだよな、そのなんていうか代替されない人っていうのはどこかに残ると思っていて。
そうね、そこの椅子取りゲーム、まあなんかやっぱ、まあそうね、勉強しよう。
自分の椅子がいつの間にか消えてる、消えてないようにやっぱ行けないとダメだなって気がするな。
うん、確かにね。
ポジショントーク、まああるかもしれない。
まああるかもしれない。
いや、まあわからんな、なんか言っちゃ悪いけど、まあ仲はねえだろうと思うんだよな、なんか。
でも巧みを作って、巧み作りを通して体験したみたいな話はすごい結構説得力があるな。
もともと生成愛の会社じゃなかったはずだけど、まあ物をここまで出してるわけではあるから。
そのとこっすか。
はい、そんなとこですね。
さあさあ、じゃあ次は。
AIによる無効なバグレポートがカールの、あごめんこれさ、カールって全然話変わるけど、カールって読むのか、CURLって読むのか。
カールだね、めっちゃカール。
これちょっとすげえ気になっちゃった、今聞いたの記事。
まあちょっととりあえず先に読んじゃうと、
AIによる無効なバグレポートがカールのバグ放送金プログラムに殺到。事実上DDoS攻撃を受けているようなものだと開発者が訴え、パブリックキーの記事です。
すごい、公式サイトに読み方に関しての言及があるらしい。
なるほど、読み、あ、そうなんだ、へえ、結論なんて読むのか。
基本的には多分カールでよくて、カールが正解らしい。
プロジェクトを指す場合はCURLで間違ってないらしい。コマンドを指す場合はカールらしい。
なるほど。
この文脈で言うとCURLであり得るよね、多分。
そうだね。
じゃあカールで。
勉強になりましたね。
これは、あれ記事の内容言ったっけ。
言ってない。
我々もタイトル通り。
いやー、これで解決するといいけどな。
これはなんていうか、起きるびくして起きたなって気がして、辛いなって気持ちになりましたね。
基本的には出し得だと思うんだよね、出す側としては。
そうだね、ほんとそうだよね。
引っかかったらお金もらってラッキーぐらいで、生産コストが死ぬほど低いから。
あとなんか、分かんないけど、全然分かんないけど、
向こうのバグレポートが今大量って話だけど、
もうちょっとAI側が進んで、めっちゃ良い向こうのバグレポートを量産できるような世界になったら、
そもそもバグバウンティーって概念がなくなったりするのかなって気はしたけど、どうなんだろう。
うーん。
人間に頼る必要ないし、だからこれこそ大体されるのかどうかって話だと思うけど。
個人的には、されないと思っていて、大体されないと思っていて、
大体されない、正確に言うと大体されない部分が残ると思ってる。
うーん。
その心は。
まあ、絹川さんとかの発想とか考え方とか見つけ方を見ていて、
あれは学習される側であって、大体される側じゃないなって思って。
なるほどね、ああ。
その意味はしっくりする、くるね、確かに。
絹川さんコピーを、もしかしたら純絹川さんを量産することはできるかもしれないけど。
そう、エネバウセンジはできると思うんだけど、絹川さんにはならないと思うんだよね。
うーん。
バグバウンティー自体は量より質の世界だよね、おそらくは。
分かんないけど、ローレベルなのか。
量でもあり得るんじゃない。
うん、報酬金、簡単に見つけられるものを大量に。
だから要は1個1万円のバグを100個見つけるのと、1個100万円のバグを1個見つけるのは、
バウンティーを稼ぐっていう観点だと言うと、等価だよね。
どっちかって言うと、バグバウンティーを募集する側の目線に立った時にどっちが価値があるんだろうっていう。
募集する側目線は別にそこに分け隔てはないんじゃない。
あるべきじゃないと思うけどね。
AIとMCPのリスクについて
あるべきじゃないって言ってるのは、何はともあれもう出ちゃってるわけだから、世に見渡した状態で。
いや、分かんないもんね。
その上で報酬金でグラデーションつけましょうねってやってるわけだから、別にそこはそんなに。
そっかそっか。
なんかだいたいされずに残るとして、そうなるとあり得るかなと思ったのは、
分かんないけど50万円レベルまではもう正々堰で見つけるから受け付けないよ。
ただ50万円以上は人間の方が効率いいし正々堰には見つけられないから、そのレベルだったら受け付けますよみたいな。
世界とかはあるのかなと思う。
あるかもね、それはあると思うよ。
もしくはあれか、そもそも50万円以下のものはもう内々で見つけてリリースされてるからそもそも見つけられなくて、
MOSAだけがめちゃくちゃ正々堰は見つけられないものを見つける世界になって、じゃあ淘汰されていくみたいな世界とかはある。
それもあるかもしんないけど、まあ金額で測れるものじゃないと思うからなあ、そこは。
ああ、そっか。
なるほどね、確かに確かに。
面白いな、確かに代替されました。
でもこかつさんとかの見つけてるものとかを見てるとすごくこう、あれとこれとそれを組み合わせたらこんなことができちゃいましたみたいなものが多かったりするから、
今回カールで言えばカールのコードって範囲がものすごく特定されてるので比較的予想がつきやすい部分だと思うんだけど、
AIとバグバウンティーっていう組み合わせにおいて何が起こるかの予想が比較的つきやすいと思うんだけど、
ウェブサービスのバグバウンティーで、範囲はここからここまで全部ですみたいな状態に対して、何ていうかめちゃくちゃ効いてくるかというと、そんなこともなさそうだなとは思うんだよな。
なるほどね。
っていうより多分そこまで、わからないなあ、計算機側の能力次第ではあるのかなあ、そこまでのコンテキストを保持できないと思う。
例えばマイクロソフトドットコムドメイン配下にあるあらゆるアプリケーション、あらゆる機能に機能を全部把握している、何かLLMみたいなのを作れるかというと多分ちょっと難しいと思うんだよなあ。
そんなコンテキスト持てないと思うんだけどね、どうなんだろうね。
まあ今は持てないけど。
持てる世界は来るかもしれないけどね。
でも情報量的に結構厳しいと思うんだよなあ。
増えていくし。
まあまあまあ、確かに。
増えて減ってがあるわけで。
そういうところを、ある種の直感とか、あるいは過去の経験とか知識に従って、ピンポイントで見つけてくるみたいな部分はなかなか置き換えできないと思うんだよなあ。
なるほどね。いやあ、どうなんでしょう。
まあ、でも5年ぐらいはやっぱ確かに残るイメージはあるなあ。
5年、来年の5月ぐらいに残んなかったねって話してる可能性も全然あるし。
いやでも、お気の毒にという感じですね。
これなんかOSSの一周とかプルリクエストとかで同じ問題起きてないのかなあ。
一周、まあなんかリターンがないゆえにあんま起きてなそうな気がする。
なんか観測したことないかなあ。
確かにね、確かに。そこは大きな違いだなあ。間違いない。
数売ってお金もらえちゃうっていうのがやっぱでかい気がするよね。
間違い。
逆に言うと、マフガンティー以外でも稼げるものがあったら、
まあ同じことが起きる可能性は全然あるよね。
今のハッピーセットの地域化みたいなことになるかもしれない。
確かに。
そんな感じですね。
ハッピーセットの地域化。
まあ、稼げるなら村があるよねっていう感じで。
いや、あれはでもさ、なんかコストに似合ってんのかなあ。
どうなんでしょうね。
なんかあまりにもはくりすぎない。
プロンプトインジェクションの危険性
なんかわかんないけど、めっちゃ外国で人気とかなのかなあ。
高値で買う人間がいるのかね、わからんけど。
まあ、あとはその、何だろう。
だからこういう案件を3つやって、そのうち1個バカ売れすれば元が取れるみたいな、
なんかそういう構造とかになってるんじゃない。
これだけで多分食ってるわけじゃないだろうかな、
これをやってる人たちは。
ああ、でも売れてんなあ、メルカリ見ると。
まあいいや、ちょっと話しておきましたけど。
はい、フラットセキュリティさんのブログは今日は多いんですけど、
MCPにおけるセキュリティ交流事項と実装における観点、括弧全編っていうので、
フラットセキュリティさんのブログです。
記事のサマリちゃんと書いてないんだけど、
内容としてはね、とてもボリューミーなものだと思うんですけど、
フラットセキュリティさんのブログの中で、
記事のサマリちゃんと書いてないんだけど、
内容としてはね、とても僕みたいな人間には良くて、
なぜかというと、MCPとは何ぞやって話とか、
じゃあその正体が分かったところで、
セキュリティ観点でどこでどういうリスクがあるんだろうか、
みたいな部分を結構丁寧に解説してくれてるブログですね。
1ヶ月、2ヶ月前にMCP分からない、MCP分からないって多く言ってたんですけど、
MCP分かんない状態からMCP完全に理解した状態になる、
ちょうどいい記事だなっていう、とても分かりやすい記事ですね。
ぜひちょっと読んでほしいなと思うんですけど、
メモにも書いたんですけど、
完全に理解した上で思ったことだし、
記事中でも書いてあることとしては、
多分現状のMCPの仕組みだと、
いろんなセキュリティリスクに対して、
もう気をつける以外の対策がないっていうことがよく分かったっていう感じですね。
前も何かの記事で取り上げたけど、
いわゆるサプライチェーン攻撃みたいな部分は、
従来の考え方でいろいろ対策は打てるんだけど、
やっぱりMCPサーバー間の壁みたいなものがどうしてもないし、
あとはこの記事にどっかに書いてあったんだけど、
MCPの裏側の仕組みとしては、
サーバーで実装されているコマンドの説明文みたいなもの、
アバウトイコールもプロンプトになるんだけど、
そのプロンプトとそれに紐づく実際の関数みたいな構造になっていて、
ただそのプロンプトみたいなのを現状のMCPの仕組みだと、
MCPのクライアントとなる生成アイが、
そのままプロンプトとして直接作っちゃうっていう挙動をするから、
やっぱり悪意のあるMCPサーバー一個混ぜて、
その中の実装済み関数の中の説明文の部分に任意のプロンプトを入れられるっていうのと、
同義の状態にどうしてもなってしまうので、
そうなると割とやり放題というか、
ある種のプロンプトインジェクションに繋ぐようなみたいな部分があって、
現状だと多分どうしようもない、気をつけるしかないし、
あとは普通にその悪意のあるものに引っかからなかったパターンとしても、
セクションとしては複数のMCPサーバーを接続した場合の注意点っていうところに
めちゃくちゃ分かりやすい図が書いてあるんですけど、
例えばアトラシアンのMCPサーバーとMCPプレイライトみたいなブラウザ検索みたいなものを繋げたときに、
アトラシアンのこのチケットの説明してよみたいなプロンプトを投げたら、
おもむろにそのチケットの内容を全部Chromeの検索クエリで投げちゃうみたいなので、
漏洩するみたいなのは全然普通にあり得るしないようだし、
あとはそのGmailのMCPサーバーが繋がってたら、
その機密情報みたいなのをGmailでちょろっと送信しちゃうみたいなことも原理上は全然あり得るし、
それを仕組みで解決方法っていうのはもう今はないので、
もう注意するしかないっていう感じ。
対策と今後の展望
だから対策をいくつか書いてくれてるんですけど、
基本的にはもうその何だろうな、
例えば権限を最小化しましょうとかアクセス的情報を絞った上で、
MCPサーバー利用のときはオートアップループ的なものじゃなくて、
ちゃんと人間が確認しましょうみたいなことなんだけど、
でもそれこそクライアントとかは今ってもう重要証券的な制御とか全くできないんで、
現状でやるとしたらもうこういうふうに気をつけて使ってくださいっていうルールを制定して、
みんなにそれを読んでもらってっていうところまでしかいけないっていうのがよく分かりましたって感じですね。
お扱わないになるのかな。
そうだね、根本的にもうリスクゼロにしたいんだったら。
もうちょっとどうにかならんかなって思うんだけどね。
でもとてもとても分かりやすかった、とてもいい記事だと思います。
なんか、ありがとうございます。
ちょっとちゃんと読んでみよう。
どうしたらいいんだろうね。
これ最終的にはその辺の社員が触れる情報はもう全部公開情報ですみたいな状況にするしかないんじゃないの。
このアーキテクチャが選択され続けるんだったら。
確かにね、そうするかもしかも、
MCPさんは経由でももう外の口は死ぬ気で塞ぐかどうかな。
これがずっと続くのは考えたくないな、あんま考えてないな。
あのすごく風通しの悪い組織にするしかないような気がするな。
これをこう、安全にこれを使うというのと、
安全性を担保しましょうというのを両立しようと思ったときに、
これを使ってる人たちには外に出ちゃまずいものは渡せないっていう状況にするしかないと思うんだよな。
すげえ嫌だけどそんなんなんか。
いやー、ちょっと思ったのは、
多分ホワイトリストでカチカチにやるしかないんだろうなっていう部分と、
コンテキストごとにMCPのサーバーセットみたいなのを切り替える仕組みとかあったりするのかな。
分かんないけどさ、開発のときにGitHubに一周読んでプルリクを立てるみたいなところをやりたいみたいなときって、
GitHubのMCPサーバーだけ繋がってればいいはずで。
いやでも微妙か、ノーションの中で繋がっててほしいとか。
絶対繋がっててほしいと思うし。
例えばだけど、こういう脆弱性情報が出てるのでそれの一周を立てるみたいなところだったら検索できてほしい。
状況はあったりすると思うし、
メールで受け取った連絡に基づいて何かトゥーデューを立てないといけないみたいなときとかにも多分、
Gmailと繋がってなきゃいけないとかは当然あると思うし、
割と用途がものすごく限定されちゃうので、
特定の、ある特定のコンテキストにおいて特定のMCPサーバーしか使えないっていうのは、
あんまりなんか筋が良くなさそうな気はするな。
そうだねー。
いやー、むずいなー。
なのでベットロック的な仕組みを通じてMCPのサーバーにアクセスしますが多分、
なんかありうらしかどうしたと思うんだけど。
うんうんうん。
確かにフリーさんのアプローチはだいぶいいなー。
AIアジェントの実装
でもあれをなんか全、各企業が頑張ってやる世界はなんか大変だなー。
ちょっとなんかあまりにもプリミティブだよね。
うーん、そうねー。
プリミティブかつなんかパワフルすぎるというか、
こう、なんか、
分かるんけど、小学生になんか刃物渡しているような感じじゃないかな。
そうね、小学生とまで言わずとも、なんか、
やる気だけありますって言ってる新入社員に刃物渡すみたいな。
なんか結構危なっかしさはそういう感覚だよなーって思うんだよねー。
確かにねー。
会社でフリーさんの記事の持ち込んで、
同じことやろうとしたらどのくらい大変ですかとか話したんだけど、
やっぱ先任チーム立てないと無理だなーみたいな話になって。
いやー、なんか。
まあでも正直感覚的にそこの先任チームを立てましょうっていうところに投資するのは悪くないと思うんだよな。
その賭けとしてはなんか部の悪くない賭けだと思っていて。
そうね。
今の状況を見るにね。
それはそうねー。
はい、前もとても良かった。
正しく理解できたと思う。
ちゃんと読んでいます。
うん、ぜひ。
これ後半はまだ出てない?
後編まだ出てないね。
今時点でも出てないから、今週もしかしたらどっか出てるかもって感じかなー。
後編もお楽しみにということで。
後編でもしかしたら希望が出るかもしれない。
周りにいるかもしれんけど。
楽しみにしてみましょう。
じゃあ次もね、flat securityさんのSAI系の記事なんですけど、
MCPやAIアジェントに必須のLLMの外部通信連携におけるセキュリティ観点という記事ですね。
これそのうちなんか全部まとめて一冊の本にしそうだね。
本とかスライドとかになるかもね、もしかしたら。
これは、MCPサーバーは多分これの個集合って感じ。
ここで扱われるとこのLLMアプリの個集合として取られると多分見やすいんだけど、
どういう話かっていうと、
AIアジェントとかを実装する側の話ですね。
実装する、作る側の話、目線に立った時に、
そのAIアジェントとかMCPが外部のソースとかサービスと連携するっていうのは、
どうしても避けらんないよねって話が起点としてあって、
なぜかっていうとこれ3つの壁の話を書いてて、
これが個人的になるほどなと思ったんですけど、
一つは知識の壁っていうので、
LLM自体は学習時点で知識レベルが止まってるから、
新しい知識とかまだ機密情報みたいな、
外部に公開されてない知識へのアクセスも当然できないので、
その壁があるよって話と、
実行の壁は何だっけな、
実行の壁はあくまでLLMはインプットがあってアウトプットのテキストが出てくるっていうだけ、
だから実際に何かウェブ上で動作をするとか、
IPを叩くみたいなことはできないっていう壁と、
また能力の壁みたいなところは、
そのモデル自体の性能限界みたいな話で、
例えば何でしょうね、記事中で書いてあるところで言うと、
複雑な数学計算とか統計分析とか高度な画像生成とかは、
LLMにわざわざやらせなくても、
もっと能力の高い基地のツールがあるっていうところを考えると、
適切適正をやっていくのがいいよねみたいな、
この3つの壁を超えるために連携をしたいみたいな部分が話の起点としてあるんですけど、
連携したときにセキュリティ観点でどういう脅威があるんだっけっていうのが、
いくつか書いてあって、かなりいろいろ書いてあったっけな、
この記事じゃないか、この記事じゃないわ、
何かピックすると分かりやすいのはSSRFの話とか、
あとはLLMにおいて、
いとしないリクエストセスによる機密情報令、
これは何だったっけな、
そうね、プロンプトに悪さをするようなものを仕込んで、
内部的に連携しているところに対して悪意のある操作を実行するみたいな話とかかな、
SSRFは割と分かりやすいかなって気はしていて、
LLMが連携しているときに、
そのLLMが動いている環境内でアクセス可能なところに対して、
例えばURLを渡したリクエストを送る仕組みがあるのであれば、
SSRFが成立し得るよねみたいな話とかがあるという感じですね。
具体的なやつはちょっといろいろ読んでほしいという感じですね。
そうっすね、引用したんだけど、
結構腑に落ちたなって表現が、
これ何に対しての一方だっけな、
そうっすね、権限、機密情報の漏洩リスクのセクションで、
LLMジェットに権限とかいろいろ壁を取っ払うためのいろんなものを渡したときに、
確かに壁は超えられるんだけど、
超えられるし、あとは仮に人間にそれを渡したとき、
同じようなことを渡したときに、
例えば業務委託の方に一定の強い権限を渡すみたいな話とか、
原理上は業務委託の方が悪さしたらダメだよって話があるんだけど、
そこはNDAの契約があるとか、
信頼関係があるみたいなので整理がつくんだけど、
一方、LLMモデルは自身がそのような契約を帯びてるとは思ってませんし、
入力された情報をツールに渡してはいけないなどとは、
プロンプトされてないとしていませんから、
何もしなければツール経由でデータが抜けていく可能性を十分に高く見積もらえればならないのです、
という文言があって、これはかなり負に落ちたというか、
フラップ関係者さんの口から高く見積もらえればならないと言ってくれたのは、
ちょっと嬉しいじゃないけど、
なんていうか、一つ貴重な意見だなと思って引用したという感じですね。
それはそうだよなっていう、
やっぱ刃物を持った新入社員じゃないけど、
うん、そうですね、そういう部分って感じですね。
これもいくつか対策書いてあるけど、やっぱ権限を最小化するとか、
あと汎用的すぎるツールを持たせないとか書いてあるんだけど、
これがやっぱこの考え方がMCPサーバーの考え方と結構逆行してるから、
やっぱ悩ましいなって思うんだけど、
そうですね。
そんな感じの記事です。
ありがとうございます。
はい、これもちょっとちゃんと読んでみます。
ぜひ。
こっちはMCPの話よりはもうちょっと従来のセキュリティモデルに落とせる話もあるかなという気はします。
そうだね。
一方でどう実装しますかっていうのが。
そうだね。
あとその現実のユースケースでやっぱどうしても汎用的なものを持たせたいとかは全然あると思ってて。
どっちかというと壁を越えた先側の問題なんだろうな、ちょっとな。
まあでもそんなこともないか。
そういうものもあるしそうでないものもあるし。
結構ケースバイケースなんだろうなって気はするな。
セキュリティの観点
やっぱMCPとかもそうだけど、2つ以上繋がった時とかに結構怖いよな。
このGitの例とか記事中であるものとかだと大変怖いね。
まあまあでもそうね。
ぜひ読んでください。
はい。
じゃあ最後いきますか。
いきましょう。
Our Step-by-Step Guide to Evaluating Runtime Security Tools っていうGitLabの記事です。
セイザーさんっていう知り合いの人がオーサーに。
セイザーさんの記事だったんだ。
記事でございます。
ちょっと原文で読んでなくて、翻訳したのをサラッと読んだだけなんだけど。
なんかRuntime Security Toolっていうのが何を指してるかというと、
ひだたく言うとなんか監査ログとか、
後からインシデントとかの調査をするときに必要なツールというか、
そういうものを指してるようなイメージなのかな。
中身は正直読んでほしい感じではあるんだけど、
サラッとGPTで予約させたのだけあっては置いたんだけど。
クラウド監査ログだけだとやっぱり足りなくて、
ランタイム側にも何らかログを取る仕組みが必要だよねみたいなのをつらつら書いてくれているのと、
実際じゃあ必要なログが取れてるかどうかっていうのをチェックしておかないと、
実際にそれが使えるかどうかって誰も何も言うことができないよねっていうのがあるので、
じゃあ評価しましょうと。
評価って具体的にどうやってやればいいんですかねっていう話をGitLabさんのケースとして紹介してくれたという感じです。
で、結構具体的なシナリオとしてこういうのを検討しましたっていう話とかも書いてくれていて、
なんか結構、何て言ったらいいんだろうな、
この手の評価をしましょうみたいな話ってよくあることだと思うんだけど、
具体的にじゃあ何をどう評価しますかみたいな部分って結構自分たちで考えるの大変だと思うし、
かつあんまこういうの表に出すことないと思うんだよね。
確かに。
なのでなんか割といい記事だな、いい情報だなと思って持ってきました。
確かに、その観点で読めてなかったな。
いや相当詳しく書いてくれてるよね。
そうそうそうそう、かなり詳しく書いてくれていて、
これを表になんか提供してくれるっていうのがすごくいいことだなと思って。
うんうんうん、確かに。
いやー、これGitLabがOSSだからこそ出せんのかな、なんていうか。
いや、同じようなことをさ、仕事で、こんなレベルでは多分やれてないけど、
やってることはあって、学びもあるから同じようにブログ出したいなと思ったけど、
評価と分析
出せねえなと思ったというか。
あーでも別に出せない情報もないよね、それでいうと。
だって具体的にこのベンダーのこのツールを見ましたみたいなことは書いてなくて、
シナリオとしてこれで検証しましたよっていう、で結果としてやっぱり足りてないところがあって、
想定してたブログが取れてないみたいなものがあったので、
そういうところはベンダーに連携してみたいな話とかを書いてるだけで、
その出せない情報は書いてない。
あーそうかそうか。
なるほどね。
ちょっともう一回読み直そうこれ。
これ、いやー偉いな。
はい。
はい、というちょっとさらっとした紹介になってしまいましたが。
そんな感じの記事でございました。
ありがとうございます。
ぜひやー。
セイザーさん一回話してみたいな。
あれないの?
ないと思う。
あ、そうなんだ。
普通に日本にいるよ。
わかんない、俺の認識が正しければ。
チャンスがあったら話してみたいな。
うん。
こっそりセイザーさんのブログをサブスクライブしてるんだけど。
日々の様子が流れてきてる。
なんかノウハウが流れてきてないから、
人となりだけに詳しくなっていく。
こういう本読んでるんや、みたいな。
あー。
AIとLLMについての考察
セイザーさん、いいね。
どっかでじゃあ、なんかつなげられるといいな。
うん。
呼びたい人リストにしてるというとこ。
呼びたい人リストはね厳しいんじゃないかな。
普通にリストだからな。
あ、そうなんだ。
タイムゾーンがさ、多分。
タイムゾーンは基本的に日本のタイムゾーンに合わせて働いてると思うけど。
うんうんうんうん。
タイムゾーン問題もありつつ、
多分普通に、割となんか忙しそうなんだよな、常に。
うーん。
なるほどね。
じゃあ、呼べたら呼ぶスタイルで。
はい、そんな感じでいきましょう。
よし。
今日はこんな感じかな。
この7個、
フラットセキュリティさんのLLMプログラッシュが、
来週も続くんじゃないかな。
うん。
いいっすねー。
いやー、カール笑ったな。
なんか、アドベントカレンダーとかまで持てなかったのかな。
ははは。
まぁあの、LLM診断サービスリリースして、
匠をリリースして、やっぱそれの宣伝もしたいって話。
まぁ、もうメンタムがあったんだね。
うん。
まぁあと内々に、やっぱ知見が溜まったんだろうね。
その匠開発を通して。
あー。
ある気がする。
いい時期だったんだね。
うん。
やはりね、いい経験どんな感じは、いいんじゃないでしょうか。
はい、じゃあ、
喉がなぁ、本調子じゃない。
来週ぐらいには本調子になってると思うんで。
いやー、早く治してください。
みんな、みんな待ってますよ。
ははは。
ほぼ治ってるんだけどね。
大丈夫っす。
任せてください。
じゃあ、そんな感じで、
来週もお楽しみにしててください。
おやすみなさい。
はい、おやすみなさい。
