暑さと体調管理
こんばんは、Replay.fm 第47回です。
こんばんは。47?
47か。
あと3回で、切り番。
切り番?
そういうユースケさん、切り番?
わかんない。
まあ、脊髄で喋ってるから、今。
俺はさ、疲れたよね。
いや、もうね、3週連続なんよ、この話から入ってんの。
まずいですよ。
まずいか。
やるだけね、別に。
暑いのよ。
暑いね。
暑いの?
東京は今、標準何度なの?
わからんけど、今日は比較的近い。
家から比較的近いところで、39.何度とか記録してたんだけど。
気持ちそっちの方が暑いのかな。
まあ、でももう、なんていうか。
暑いのよ。
どぐりのせいから日というか。
そう、そのさ、で、なんか、こう、なんていうか、あらゆる局面において体力が奪われている、今。
でも寝るときにさ、エアコンつけて寝ると、私は喉が弱いのですぐ柔らかくなっちゃうんだけど、
あと、エアコン消して寝ると暑くてもうダメなのよ。起きると具合悪いの、もう。
もう自給、もう回復、回復するタイミングがないね。
そうなんだ、終わってんのよ、もう。
なるほどね。
終わってんの。
で、なんかさ、その、もうさ、飯とか作る気に全然ならんからさ、
お昼とかさ、近所に、なんか、近所のスーパーにパッと買って食べられるもの買いに行くんだけど、
もう、お昼に出かけて戻ってくると、それだけでなんか結構、こう、なんか、HPの半分ぐらい持ってかれんだよ。
はいはいはいはい、わかるよ。
いや、まじ、5分歩いたらもうおしまいだよな。
そうなんだよね。
それはわかる。
で、今、おでこにヒエピタ貼ってっから。
すごい病人が来たみたいな感じ。
いや、まじで気持ちいい。
あの、なんか、うちは結構ツクウォギをしておいて、それを消化するんだけど、ランチとかは。
いや、偉すぎる。
でもツクウォギないときとかに結構あれがおすすめですよ、あの、冷凍うどん。
チンするだけのタイプの冷凍肉うどんめちゃくちゃハマってる。
ハマってるというか愛用してる。
普通になんか冷凍のうどんをチンして、あの、めんつゆと揚げ玉と卵と冷凍のネギとかって食べてる。
はいはいはいはい、いいね。
なんか、冷凍肉うどんとか、あとそのトッピングももうチンしたらだいたいできるから。
うん、強い。
なんか、楽したいときに。
いや、今日のソーターティップスでした。
おすすめ。
はい、ではみなさん、おやすみなさい。
脆弱性診断とAIエージェント
いや、やめろやめろ。
本題に、本題に入らないとダメですよ。
そんな、5分、5分ぐらい、5分も経ってないよ。
3分、3分で収録終わらそうなんてそんなね、ダメですよ。
47週連続記録なんで。
みんなどうやって、なんかこのクソ熱い気候と折り合いをつけて生きてんのかなって。
いや、俺らまださ、リモート多いからいいけどさ、もう出社終わるよねマジで。
ほんとどうしてんだろうなって思うな。
いや、会社行くとき、マジで、なんか地獄だよ。
その、あの、なんて言ったらいいんだろ。
涼しい、涼しい時間に出ようと思うと何?始発とか乗ればいいんすか?
そういう感じで。
そういうことなんだ。
そうそうそう。
いや、エグいね。
真っ昼は暑いから、その、じゃあ午前中、できるだけ早めに電車乗るかと思うと、まあ、まあいいん電車じゃん。
うん。
じゃあなんか、まあちょっと時間ずらして移動するかと思うと、暑いじゃん。
そうだね。
うん。
積んでるね。
いや積んでるよ。
移動、移動してオフィス着いてまず40分ぐらい休むでしょみたいな。
さすがに、さすがにそこまでじゃないけど、そこまでじゃないけど、なんかでももう結構、なんか、その、もういいおっさんだからさ、なんか、こう、1日の、こう、活動限界みたいなの、もう決まってるわけですよ。
なんか無理が聞かないっていうか、なんか。
うん。
だからその40分っていうのは、なんかその、時間っていうよりか、実質的なロスとして割とリアルな線いってんじゃないかって気がする。
あー、確かに。
その、MPの減り方的に、なんか40分ぐらいの生産性が。
うん。
に、当たる体力が出汐で奪われるんで。
うん。
知らんけどね。
やー、ヤバすぎるよマジで。
冷えピタって頑張ろう。
ちょっと今日走り切りましょう。
冷えピタってでもさ、ゆーてんそんな乗りたくないよね。
冷えピタは、そうね、あの、感覚が冷たいだけで。
貼った瞬間だけだよね、なんか。
そうね、減熱作用はないらしいですかね、一応。
うん。
貼った瞬間をこう、永遠に味わえるマジンみたいな瞬間。
ぺったんぺったんぺったんぺったんって。
あのー、なんだろう、ずっとできるプチプチのおもちゃみたいな。
そうそうそうそう。
ずっとできる冷えピタ。
永久期間冷えピタ。
もう今日のタイトル決まったわ。
永久、書いといてじゃあ。
よし。
いやー。
冷えピタ。
じゃあ、上から行くか。
はい。
えー。
いや、マジここから真面目な話すんの?
ひでえ、ひでえポッドキャストだな。
みんなこんなもんよ。
はい。
でも1個目、とてもいい記事じゃないですか。
じゃあ。
読む?どっちもいいや。
お願いします。
冷えピタの。
はい。
えー、脆弱性診断with AIエージェント、ついに開発チームに広がりました。
っていう、フリーさんの会社ブログですね。
まあ、なんかタイトルとしてはもうこの、これ系のフリーさんの記事多分、
漏れなくここで取り上げてる気がする。
そんなことはないけどな、多分。
そんなことはない。
ちょこちょこ、まあ、この下いいかーっていうのがあった気がする。
まあいいや。
そうか。
えーっと、前回、多分結構前かな。
前回紹介した脆弱性診断をクライン使って、
多分ピーサーとチームがやってるみたいな、
で実践投入してるみたいな記事があったと思うんですけど、
まあそれを開発チームに広げましたみたいな。
広がりましたみたいな話かな。
ですね。
で、まあ結構詳しく書いてくれてるんで、
ぜひ読んでくださいって感じなんですけど、
要素としては、今言った話との差分で言うと、
クラインからルーコードを使うっていうような変化があったっていうところ。
で、理由は何かルーコード特有の機能を使いたいみたいな部分があったのかな。
オーケストレーションモードとサブタスク機能っていうのを使いたいっていう感じかな。
っていうのと、ナレッジを、
エアーエージェントで終わった双方を、
メモリワンクからフリー制、社内制のMCPサーバーに変えましたってところが結構差分として大きいですと。
いやー、これはMCPが良かったのかな。
何か書いてあるところとしては、
メモリワンクの場合は、実体はマークダウンの集合体だからどう、
エンジニアがどう展開するかみたいな部分かな。
だからメモリワンクって言ってるけど、
多分実体やったから、あれだよね、マークダウンファイルがどっかに置いてあって、
手元にダウンロードして、それを読ませるみたいなことをしてたのかもね、もしかしたら。
どうなんだろう、もうちょっとイケてそうな気がするけど、
その辺がMCPサーバーに、
MCPサーバーが結構社内で浸透してたっていうところもあって、
まあ、それだったら多分、
しかも社内制のやつってどうなんだろうちょっと、
多分内製の1個あって、その中の機能の1つとしてってイメージな気がするから、
なんなら特にインストール作業もなく、
ナレッジを使えるみたいなところが良かったんじゃないかな。
なんかさ、意外と上がってないんだけど、
LUGってあれはどういう繋ぎ方をするんだろう。
LUGはなんかね、僕も意外と上がってないんだけどね、
まさかに飛んできそうなんだけど、結構その、
なんだろうな、その実体となるデータを、
モデルが解釈できる形で変換する処理みたいなのをしてる気がする。
なんか大体よく基準文とベクトルみたいな。
そうだね。
そこでワードが出てきて、あ、分かんない世界だって思って。
なるほどね、だからそもそも前段にもしかしてLLMがいない?
いや、LLMはいるんじゃないかなと思うけど、
前段っていうのはどういう意味なの?
要は今見てるのはこれなんだよね。
あ、でもLUGってLLMじゃないのか。
いやでも拡張そうだよね、拡張みたいなところがあるから。
ちょっと思ってたんだけど、
チャットに入ったけど、
はい。
これのアーキテクチャスが、
分からん、でもこれが合ってんのかどうかすら分からないぐらいの、
なんかあれしかない。
まあでもそうだよね、こういうETL処理みたいな、
そのナレッジに対して処理が必要なんだよね。
結構その、端的に言うとMCPほど楽じゃないって認識はあるな。
これこの図で言うと前段にLUGアプリっていうのがいるじゃん。
だからなんかLLMのそのエージェントが前段に多分いないのかなっていう、
ちょっと一瞬思ったんだけど、
でも多分実態としてはそんなことなくって、
なんか体験としてはそのAIエージェントみたいなやつが前段にいるようなイメージなのかな。
ざっとくぐった感じはそのLLMとLUGを組み合わせてみたいな話も結構出てくるから、
LUGを叩くのはAIエージェントみたいな感じになったりするのかもね。
その辺よく分かってない。
なんかLUGもちょっと不具合だよね。
なんか話題になってきたらだんだんMCPで、
まあどうなんだろうな、
だから向き不向きみたいなのとかちょっと勉強しないと分からないな。
LUGの方が有利性があるものもある気がせんでもない。
まあデータの規模とかによるんじゃないかなと。
あとはその、あれかな、
例えばNotionのMCPサーバーとかをナデッチに使うと、
実態としては検索をしてるわけだから、
技術的な考察
その検索のゴミデータが混ざってたりとか、
一発で引っ張れないときにLLMのトークンをめっちゃ使うとかある気がしてて、
その辺とかはLUGで必要なデータだけギュッと凝縮してあげたほうがいいとかある気がせん。
NotionのMCPサーバーとかあるからさ、
これ別に極端な話にNotionに全部書いとけばさ、
そのままこれマネできるのか。
えっと、この不利の話。
ナレッジ。
そうだね、そうだと思う。
ただ工夫は必要な気がするね。
工夫は必要だね。
Notion全体じゃなくて、
ナレッジを作って。
そうそうそうそう。
ってなった時に完全に今日紹介するつもりなかった記事が今めっちゃ頭に思い浮かんでて。
あ、そうなんだ。
なるほど。
Notionインテグレーションの権限管理の。
あー、はいはいはい。
スペースを空けてみたいな。
そうそうそう、スペースを空けてみたいな。
結構大胆だなと思ってたけど、なんかめっちゃやりたくなるなと思って。
うーん、なんか考えることはかなり減る気がするね。
そうねー。
確かになー。
なんかいいな。
Notionに全部突っ込んでおいて、
ナレッジはそこに全部突っ込んでおいて、
そいつMCPサーバーとしてそこにナレッジを用意する。
ただあれかな、わかんないけど、
ちょっと詳しく記事に書いてないからわかんないけど、
内製してるMCPサーバーだから、
なんか想像なんだけど、
MCPサーバーって裏側の仕組みとしては、
プロンプトとその操作の、
例えばNotionのMCPサーバーだったら、
冷えピタの需要と利便性
そのページを作るみたいなAPAがあって、
そのAPAに紐づくカスタムプロンプトがあるみたいな。
で、AIアジェントの挙動としては、
Notionのページ作ってって言ったら、
そのAPAを探してきて、
で、その裏側のプロンプトを叩くって挙動する。
だから、NotionのMCPサーバーをナレッジとして使うってなった時は、
Notionにナレッジがあるっていう前提で、
プロンプトを書かなきゃいけないんだけど、
多分なんかこの社内のやつは、
もうちょっと気が利いてそうな気がしてて、
というか自分が作るとしたら、
なんか診断してみたいな。
もうコマンド作って、
そしたら裏側ではNotionを叩くみたいなとこやると、
内製した方が結構体験は良くなる気がする。
多分これ書き方的には、
どうするのかな。
これ多分、多分だけど、
ナレッジのファイルそのものもローカルに配布してるよね、
この書き方だときっと。
いや、MCPサーバーは配布してない。
分かんないけど、
配布する必要は無くないんじゃないかな。
逆に。
そう。
多分社内のMCPサーバーってどっかに立ってると思うんだよ。
リモートなのかな。
リモート。
でもナレッジの更新もコマンド一行で完了しますって書いてあるし、
これでエンジニアの環境に自然と展開され、
ナレッジの更新もコマンド一行で完了しますって書いてあるから、
それはなんか普通にリモート、
ただのAPIサーバーというかさ、実体は。
ローカルでもいいけど、
分からんがローカルにする必要性がないんじゃないかな。
社内で広く展開したいってなったらさ、
リモートで立ってた方がオーバーヘッドは少なくない。
でもサーバー、リモートでサーバーのメンテする方がだるくない。
だって実体はローカルで完結するわけじゃん、MCPって。
まあそうなんだけど、
でもそのローカルに、
みんなにもうクローンしてって言わなきゃいけないわけじゃん。
それも別にJamfとかで配布できるじゃん。
AIによるナレッジ管理の効率化
え、だるいよ、Jamf。
でもそれはもうあるじゃん、
社内表示のMCPサーバー群をまとめて扱えるツールが開発されましたって書いてあるから、
だからそこはもう解決してたわけでしょ。
そうだね。
ローカルなのかな?
ローカルで動かしてそうだけどな。
まあでもどっちでも多分やることは変わんなくて。
まあやることは変わんないね。
うん、だからローカルからリクエストが飛ぶか、
リモートのサーバーからさらにリクエストが飛ぶかの違いしかないんじゃないかな。
いやー、でも嫌すぎるな、だって認証とかさ、
だるい。
まあでもそこはローカルでもリモートでも逃げらんないんじゃない?
あんま変わんないと思うけどね。
だって別にローカルに落としてくるときだけさ、
なんかいい感じにしとけばいいだけじゃん。
落としてくるときにいい感じにするとは。
だってナレッジのファイルをさ、落としてくるところだけなんとかなってればいいわけでしょ。
でもそのナレッジをさ、マスターとなるナレッジは何かしらの方法で更新しなきゃいけないでしょ。
じゃないと他のメンバーと共有されないわけで。
だから最終的にはマスターナレッジを何かしらの方法で更新するはずで、
ってなったら別になんだろうな。
それこそ別にGitプールでいいんじゃない?
Gitプール、まあGitHubで管理されてるならそうだけど、
まあ何かさまつなことな気はするけど。
えー結構違うと思うけどなー。
だって印象、いやーめんどくさいって。
リモートのサーバー面ですんな。
だから別にローカルでもリモートでもそのナレッジの更新の仕組みは変わんなくないっていう話。
例えばNotionにナレッジがあります。
Notion MCPサーバーは公式のやつはローカルで動くじゃないですか。
ローカルで動いて、まだ一応参照するみたいになったときに、
更新するってなったら最終的にはそのNotion上のデータを更新するわけでしょ。
だからそのNotionのデータをローカルにわざわざ持ってくる必要がなくないっていう。
だってMCPの実行ファイルからNotionに対してのリクエストを飛ばすときに認証が必要じゃん。
そりゃそう。
でもローカルに持ってきてても、だからローカルにクローンしてる状態でしょ。
クローンしたものをプッシュしなきゃいけないときに結局同じ。
クローンしたものをプッシュする必要がないじゃん。
プッシュしないとナレッジが、マスターナレッジが更新されなくて、
自分の手元でしかそのナレッジが。
ナレッジはだって更新しないでしょ。
メンテする側じゃなくて利用側視点の話でしょ。
利用、この1行だけだとちょっと分かんないけど、
でも普通に考えたら他にも展開したいんじゃない。
だってナレッジの更新、例えばその使用面の話とか、
このナレッジっていうのはここでしょ。
脆弱性診断手順とかはPeace Outチームがメンテするかもしれないけど、
そのプロダクトの詳細情報で、
例えばエンジニアが診断したときに、
このAPIも仕様変わったみたいなときにナレッジを更新したいっていうケースとかなのかなって妄想してたんだよ。
なるほどね。どっちかというと、
なるほどね。ちょっとそこは解釈違いだな。
なるほどね。
俺の問題はその認識だったから、なんかプッシュはした方がいい。
プッシュするのかなって思ってたっていう。
分からんけどね。
なるほどね。
ナレッジの更新、そうだね。
コマンド1行で完結する部分の旨味はそこなんじゃないかという気はするんだよな。
コマンド1行で何が完…。
まあいいや。
コマンド1行で何が完了する。
なんかナレッジ引っ張ってきて、このナレッジに基づいてこういう診断し合って出てきて、いやそれ違うわっていうときに、
例えば今までのメモリーバンクでマークダウンとかあったら、その該当のマークダウン探して、
GitHubで管理されてるのはそれこそコミットしてプッシュっていうのをしなきゃいけなかったわけでしょ。
が、今だったらそのAIエージェントにここ直してってコマンドでポンって叩いたら裏側で良しのように直してる。
単純世界観なのかなと思ったけど。
いやー、なんかちょっとイメージしてるのと違う気がするけど、まあいいや。
いやどっちかっていうと、なんかそのPスタートで持ってるナレッジを各チームに展開できるようになったような方だと思ってたわ。
ああ、でもそれも結局一緒じゃない?Pスタートの手元から。
それでもPスタートの手元の場合はまた別じゃん。
なんか、そこだってさ、そこをAIエージェントに構成してもらいたい?
うーん、まあ分かんないけど、この元々のメモリーバンク、
これもう本当このなんかね、今映してる記事はもう8行しかないんで、そっから妄想しながら今話す状態なんだけど、
このメモリーバンクの多分課題感としては、このマークダウンファイルの集合であり、これをどうメンテするかが課題っていう風に言ってるわけだから、
ある種その更新コストとかその更新する箇所の特定とか、そういう部分なのかなって思っていて、
そう思うと、まあMCPサーバー経由で気軽に更新できるっていうのは結構メリットなんじゃないかって気はするけどね。
でなんかそのマークダウンの量が結構多いってなったらさ、まあなんか10ページぐらいだったら頑張って手でメンテしてレビュー通してやればいいじゃんとかだけど、
それがまあ結構そのこれ半年ぐらいかけてやってるでしょ、このプロジェクト。
なんかそのナレッジが結構な量あるってなると、まあ人間がメンテできないっていう前提に立つんだったら、
まあAIにメンテしてほしいんで、AIにメンテするときの口として、まあ手元のAIエージェントにポンって投げたら更新できる。
裏側はMCPサーバーでやってくれるみたいな。
世界観は結構いいんじゃないかという気はする。
でなんか変更履歴を後で追うとかも、そのMCPサーバー内製してるんだったら、そういう仕組み作ろうと思えば作れるわけじゃん。
誰がどのように、まあ認証ちゃんと実装されてる前提だけど、
いやー、うん。
誰がMCPサーバーに何のプロンプト投げてどういう交渉をしたのかっていうのはログアイに起こせるわけだから、
いやー。
まあおかしくなったらそれにとってとか。
なんか感覚的にはそこまではまだ行ってなさそうだなという気がするけど、まあいいや。
AIエージェントの役割と課題
まあ、わかんないです。
うーん。
だけどさ、結構今、アルシネーションとかの性能面、若干低対比にあると思ってて、
割と信用ならんなって思いながらずっと使ってるのよっていう中で、
更新をしといてっていうのをやらせられるかというと、
吉田にやっといてはかなり無理があるなと思ってて。
そこはだからMCPサーバーが入れることである程度制御できるんじゃないかなって思ってるけどね。
利用者目線はここ直してねっていう吉田に指示だけど、
裏側のプロンプトどう作り込むかの話かなと思ってて。
まずそれでもアルシネーションがゼロにできないってのあるけど、
まあそこは、だからなんかどう、どこ、どう折り合いをつけられてるかはちょっと。
この記事だけだと?
そこまでは行ってないだろうなと思ったのよ。
いやー、どうだろうな。
だってAだったら脆弱ですって言ってたものが、Aだったら安全ですみたいな感じで急に書き換わってたりする可能性があるわけでしょ。
うーん、まあ難しいな。
なんかケースバイケースな気がするけどな。
なんかある種作業に落とせるような更新はそんなに、なんていうか、
少なくとも人間が死ぬ気でメンテするよりは全然いいんじゃないかって、
ちょっと主観的に思うけどな、今のレベルのLLMだって。
その修正箇所が明確でどう書き換えるかも明確なんであれば、別にそんなに、
リスクリターンでいうとリターンは自分見合う気は個人的にはするけどな。
投げ方が、まあ、例えばなんか、
うーん、なんか、まあ、
まあその辺、何投げられた時にどう挙動するかとかをどうコントロールするかみたいな部分はあるっちゃうかな。
いやでもな、
でもさ、例えばじゃあこれPeaceheartが自分たちのメンテしてるものを更新するのに使うコマンドだとした時に、
そのMCPでやんないにしてもさ、結局じゃあ実際マークダウンだったらさ、
クロードコードとかクラインで同じことするじゃん。
このマークダウンのこの行をこういう風に書き換えてって、
多分やってそれをレビューするっていう風にやるわけでしょ。
それがMCPサーバーかその手元のコーディングAIエージェントの違いでしかない気はするか。
って考えると割といけそうな気がせんこともない。
いやー。
分からん。
俺はなんか普通に読んで、普通になんかこれは各端末に、端末側のナレッジが更新されてるんだなっていう風に読んだ。
まあいいや、分からん。
分かんないね、まあこれだけだとちょっとなんとも。
だいぶ脱線してしまったけど、まあそうですね。
多分As Is To Beみたいな図があって分かりやすいんですけど、
多分なんかの記事でもあったけど、内製の診断がブロッカーになって開発、開発をブロックしてしまうみたいな部分があったけど、
この辺がAIエージェントで開発チームで各自吉谷に動かしてっていう作り線になったんで、結構いいですよっていう部分かな。
で多分結構長い期間検証してワークするところまで持っていっていて、
診断ツールの必要性
でなんか肝心の品質精度みたいな部分はこれで担保できる部分と、どうしても担保できない部分みたいなのが結構明確になったんで、
そこはピースアウトで計量の診断を行ってるよって話を書いてあったりとか、
また診断レポートがJiraとかに出力されてるのかな。
これもなんかよくできてるなと思ったけど、結果のレポートとか行動のどこ、具体的にどこをどう評価したかみたいな部分を人間に分かるように表示したりとか、
そういう部分が書いてあるって感じですね。
個人的にはこのなんかどうにもならなかった部分が明確になりましたって部分が結構気になるんだけど、
研究がないんだなと思った感じですね。
うーん、どこだろうな。
どこなんだろうね。
あとなんかちょっと地味に思ったけど、自前のMCPサーバー挟むとそのどのチームがいつ何を診断したかのログが取ろうと思えば取れるのかなと思って、
それ結構嬉しいかなと思ったな。
さっきのノーションMCPサーバーにノーションにナレッジ立てて、
明日すぐに、明日は無理か、一週間にすぐに僕らが例えばできそうなことをノーションにナレッジ作って、そこに権限持ってトークン発行してみんなに配って、
MCPJSONにこれコピペして手元に追加してください。
プロンプトも作ってあげて、このプロンプト投げれば簡易的に診断できるのでちょっと回してみてくださいっていうのはすぐできると思うんだけど、
実際にどのぐらい冴えてるかって集計できないじゃん。
けど自前で通すとその辺きれいに集計できるのとかはすごい、別に狙ってないと思うけど。
いや、その辺の集計は先週紹介したスライドとかでさ、どのモデルがやってるかみたいなのって集計してるじゃん。
でもあれは…
やってるかもなっていう感じがする、あれ見た。
確かにね、レイヤーは違いだと思う。
でもなんとなく、結果をジラチケットに出すようにしてるからさ、なんとなくする気がするけど。
確かに、そっち見た方が早いな。確かにね。
何も出てない、何も出てないなっていうか、そのやつばっかりだったらちょっと分かんないかもしれない。
まあ多分そのお金少なかでそのホールスポジティブもいっぱい出てくるだろうから、まあなんとなくそれで分かりそう。
うーん、そうだね。
いやー、まあでもいいっすね。
なんかこれ、このままサービス化して売ったらやっぱ嬉しそうだなって思ったわ。
売ってほしい。
なんか、まあいいや、ちょっと電波には乗せられない話しか出てない。
気になりすぎるな。
いやー、匠とかどうすんのかな。
いやー、このちょっと言いかけたけど、まあ言いかけた、まあ匠限らずじゃないかな、そのいわゆる診断AIでちょっとというか。
これをさ、その要は多分、あの、匠とかが行くべき方向性としては、これのナレッジ部分だけを差し替えられますようが多分王道なのかもね。
そうだね、その汎用的な診断エージェントみたいなところだと。
今のその匠とか、前紹介したクロスボーとかちょっと、現状はそもそも目指してるところが実は違う感じがするよね、その。
なんか、ナレッジゼロでコードベースパンって渡して脆弱性探してこいみたいな、なんかそういう世界観な気がするから。
ある種この、フリーとかだとその、まあループで診断するとか開発サイクルに組み込む前提でっていう部分が。
まあ分かんない、匠さん実はそこでやってるって話だったらめっちゃ仲の良い人に申し訳ないけど。
なんか、まあ端から見てると、今んとこそういう差分に見えるなって気がするね。
そうだね。でもなんか求めてるのはこっちじゃん。
そうね、事業会社で働きすぎて。
少なくともインハウスでそう、内製でやろうと思った時にさ、求めてるのはこっちで。
そうだね、それは間違いない。
本と渡してじゃあ見てくださいじゃない。
うん。
ある程度見るところも決まってるし、そのなんていうか、まあこう、こういうのナレッジももちろんありつつ。
あとやっぱ、開発者が使えるようにしようとしてるっていうのと、実際に使ってもらってるってところがやっぱ素晴らしすぎるというか。
そこがね、結構なんか飛躍がいる部分というか。
なかなか大変なところかな。
いやこれ、仲の人と話したいな。
なんかそのずっとかはさ、チケットN版の脆弱性診断してって開発者が言ったら動くみたいな感じが書いてあるけど。
いや結構理想だよね、なんか。だいぶ一つの。
このチケットN版の脆弱性診断してのチケットN版のこのチケットはどういうチケットなんだろう。
ジラなんじゃないかなって思ったけど、まあどうなんでしょうね。チケットを開発で使ってるチケッティングツールって。
まあそこにPRがリンクが紐づいててとか、なんかそんな感じなのかなとかって思ったけど。
Code7を見に行ってんだよね、きっと。
おそらくね、おそらく。
これ実行時間どれくらいかかるのかな。
どうなんだろうね。
確かに。
なんか気になることが山ほど出てくる系だね。
なんかなんとかフリーの人をゲストって呼べねえかな。
なんかとにかくこの小さいさ、なんか単位でこの手のその診断というかセキュリティティを回せないとしんどいよなと思って。
プロンプトインジェクションの脆弱性
そうね。
それがなんか技術的にかなう時代になってきたっていうのはかなり嬉しい。
うんうんうん。
やりたいなあ、これ。
やりましょう。
やりたいねえ。
我々ここまで行くのあとどれくらいかかるかな。
感覚的にはでも明日にでもやりたいんだよね、これ。
そうね。
いやーこれ、福利的にじわじわ効くよね。
そうそうそう。
でもフリーの体制で半年かかってるからな。
まあでもここまで何かナレッジ出してくれてるなら結構。
側はさ、側って言い方しちゃうタイプだけど、側はさ、このナレッジがさ効いてくるけど、その観点のナレッジはすぐにはできないよ、これ。
そうだね。
相当中で回さないとくれないし。
だからそれがなんかこの半年できたの手前にそもそもピースアウトで診断を内製してめちゃくちゃ回してきたっていうのは。
そうそうそうそう。
で、そこの積み重ねがまずあるはずで。
うんうん。
それ今我々ないので。
そうだねー、ないねー。
いやーそう思うとなんか全部害虫みたいなのも別に不正解じゃないんだけど、そのナレッジがたまんないみたいな。
たまんない。
目に見えづらい根があるんだねー。
あるけど、溜めてもさ使いきれん問題もやっぱあって。
まあそうね。
誰が使うのそれって話もあるし。
そうだね。
更新もうつかないみたいなのも出てくるし。
うんうんうん。
難しいとこなんだけど、なんかでもやりたいよなー。
やりたいねー。
いやー背中を追いかけて。
やりたい、やりたいなーで終わりにしたくないんだよねー。
目標立てよう。
8月かー今年やりますはちょっと非現実的だなー。
なんか来9月、来年のリプレイFM2周年の時にはやりましたで、いけるように。
どう?割と。
わからんなー。
なんか、わからんなー。
なんかやりますと言えればいいんだけど、
でも感覚的には、
全員とは言わずとも、
セキュリティチーム全員とソフトエンジニア3、4人ぐらいが使える状態になってる。
なんか、ナレッジベースの箱を作ってそこに感覚値完成度6、7割ぐらいかなーみたいな
ナレッジベースを構築するとかは年内ぐらいでやりたいんだよ。
なるほど。完全に仕事の話になってきた。
完全に仕事の話になってきた。
完全に仕事の話だからさ、この記事が。
それはそうね。
いやー。
完全に仕事の話だからさ。
いやーでも、ほんと、素晴らしいよ。
信じるねー。
そんなところっすかー。
無限に話せるね。30分話せるって。
いやー、交換留学したいなー。
いやー、ちょっとフリーの人と出会うべく、なんか乗り繰り出していきたいな。
フリーの人、この記事の、あの、記事に書いてる人は知り合いだよ。
あ、そうなの?
うん。
じゃあ、呼ぼうぜ。
呼ぼうぜって言ったらあれだけど。
それはわかんないけどね。
ちょっと呼べるぐらい立派なポッドキャストになったので、
行きたい所存ですけど。
じゃあ、次行きますか。
打って変わって、サクッと話せるって感じなんですけど、
ハッカーニュースの記事で、
Cursor AI Code Editor Fixed for Allowing Attacks to Run Commands via Prompt Injection
っていう記事ですね。
タイトルの通り、Cursorでプロンプトインジェクションを介して
任意コマンド実行までできる脆弱性があって、修正されたよって話ですね。
なんか、よくあるっちゃよくある系なんですけど、
ちょっと、少し面白いなと思ったのと、
あと、この記事にまとめちゃったんですけど、
Geminiでも今週分で脆弱性出てて、
こっちもなんかおもろいなって思ったので、
チラッと紹介できるわって感じなんですけど、
かつ、CursorをGemini CLI使ってる人はアップデートしてねって感じなんですけど、
Cursorの方は何かっていうと、
まずプロンプトインジェクションがMCPKで支えます。
この話自体はもうずっとあるし、
あるしどうしようもない領域で、
記事で例であったのは、
SlackのMCPサーバーをインストールしてるとして、
そのSlackのMCPサーバーに、
このチャンネルメッセージ予約してって言った時に、
その中にプロンプトインジェクションに刺さるものがあったら、
刺さっちゃうよって話がまず一つ。
これはもう一旦どうしようもないとして、
刺さった時に、
次のステップが問題で、
MCPJSONを許可なく書き換えることが、
Cursorだとできちゃってたらしい。
なんで、
MCPJSONを書き換えて、
MacになるMCPJSONを追加してっていう、
プロンプトインジェクションを指して、
刺さっちゃうと、
ダメなMCPJSONが入ってきちゃって、
ダメなMCPJSON経由で好き勝手コマンド叩けちゃうようになる、
っていう問題があったらしい感じですね。
修正方針は結構シンプルで、
利用者の許可なしに、
MCPJSONを編集できないようにする、
っていう変更が入ってるんで、
同じアプローチはちょっと刺さりづらくなってる。
多分プロンプトインジェクションはどうなんだろうな、
多分どうしようもない気がしてるんですけど、
その先で一個塞ぐっていう話があるって感じですね。
あと、ジェミニシエルアイのほうも、
ちょっと続けて紹介しちゃうと、
こっちも似たような、
入り口は似てて、
ReadMeとかを、
GitHubとかに置いてるところとかを介して、
まずプロンプトインジェクションが刺さっちゃう、
っていう話で、
その次のステップとして、
刺さった後に、
例えばこのコマンドを実行してみたいな、
プロンプトが刺さった時に、
記事の書きぶりだと、
いわゆるオートアプローブみたいなモードにしてると、
もしくはこのコマンドを実行していいみたいな、
ホワイトリスト管理できるっぽいんだけど、
セキュリティの修正策
例えばグレップは許可するみたいな、
設定になってた時に、
グレップコマンドだったら安全かと思いきや、
プロンプトインジェクションで、
グレップコマンドでパイプで、
変わるコマンドを実行するみたいなことをやると、
普通に安全なコマンド判定されちゃって、
刺さるみたいなものがあったらしくて、
なんで、カーソルのほうと比べて、
ちょっと前提条件は厳しいんだけど、
刺されば刺さる、
右コマンド実行は刺さるっていうもので、
こっちも修正済みらしいって感じですね。
こっちはちょっと時間なくてね、
どう修正されたか追ってないんですけど、
まあなんか、
どっちも、
まあまあまあ、
しみじみ勝ときだなって思うなって、
なかなか、
いやー、でも確かにMGPジェイソン狙うのは、
ありだよな。
入り込んじゃえばね、
多分、そうね、
見ないと気づかない。
いやー、でもさ、
マジでさ、
これどうやって修正つけんだろうね。
その、
なんか、
ああまあそんな時代もあったよねって言える日が、
増えるのかどうなのかがなんか。
なんか、
なんかさ、
こんだけ脆弱性出てるけどさ、
まだめっちゃでかいインシデントになってないじゃん。
まあ発覚してないだけでも起きてるのかもしんないけど、
その、
まあ少なくとも、
なんかニュースとかでは流れてきてなくて、
なんかその、
ね、なんかその、
本当に火がついてからそれが分水嶺となって、
ちょっと傾いていくのか、
まあでも、
いやーなんか年内はこんな感じな気がすんだよな、
個人的には。
その、
別に防御側も、
防御っていうかその、
サービス提供者側も別に何もしてないわけじゃないじゃん。
やっぱりその、
まあその、
有名ところじゃないとかは知らんけど、
アンソロピックとか、
まあGoogleとか、
まあチャットGPTとかも、
まあオープンAIとかもそうかな。
まあカーソルはちょっと分かんないけど、
まあその辺は結構ちゃんとやってるんだけど、
まあやっぱこういう、
割と、
なんていうか、
僕らでも理解できるレベルの、
刺さり、
なんか、
簡単めな脆弱性だよっていうか、
うん。
まあ当分、
当分こうだよなって気がするんだよね。
あと、
またじゃあそれだけでやっぱスピード優先でガンガン機能を出していかなきゃいけないっていう部分が、
まあ競争の面でも言うとありそうだし、
それが当分続く気もするから、
うん。
またあれかな、
MCPのアーキテクチャの問題というか、
その辺がどう進化するかとかなのかな。
うん。
いやー、
個人的には思ってます。
またプロンプトインジェクションがもうそもそも、
NPMの新機能
どうすんでも多分ずっと課題としてはあって、
うん。
うん。
そこもね、
まあ見どころ、
見どころというか、
そうね、
どうして組んでしょうって感じかな。
うん。
うん。
まあ、
うん。
注意喚起権、
まあ似たような、
似たようなっていうか、
まあお気を付けください。
まああとはなんか、
やっぱMCPサーバーはちょっと、
そうだね、
まあ、
まあそうね、
はい、
まあいいや、
ちょっと話し通りさせて。
うん。
いや、
なんか使うMCPサーバーの管理も地味に大事なんだろうなって、
ちょっと不安と思ったって感じ。
うん。
うん。
次は、
次は僕紹介ですけど、
GitHubのチェンジログで、
NPM Trusted Publishing with OIDC is generally availableという記事ですね。
まあチェンジログなんで、
記事自体はかなりシンプルなんですけど、
NPM、
これ具体的にはNPMJSのレジストリですね。
レジストリに対して、
パッケージをパブリッシュするときに、
OIDCを利用してパブリッシュができるよって機能が一般、
GAになりましたって話ですね。
で、
なんかイメージ的にはGoogleクラウドのワークロードアイデンティティ連携みたいな、
IWSも似たようなのがあるはずなんですけど、
と似てて、
いまい、
これが出る前の世界の話をすると、
NPMJSにパッケージをそのパブリッシュするときは、
NPMJSのコンソールに行って、
APIトークン、
スコープ絞れたり絞らない、
絞らない、
絞れ、絞ろうって言ったら絞れるんですけど、
ライト権限を持つトークンを発行して、
それを手元からパブリッシュするなら手元にセットするし、
CACDからパブリッシュするなら、
そのCACDにセットしてっていうのが必要だったんですけど、
このYDC使うと、
トークンなしで、
記事にキャプチャー貼ったんですけど、
NPMJS側で、
このパッケージはGitHub Actionsで、
このオルグ、このリポジトリのこのワーク、
この名前のワークフローファイルからは、
パブリッシュしてもいいよって設定をしておいて、
そうすると、
GitHub Actions側からはトークンなしで、
NPMJS側にパブリッシュできるよっていう仕組みが、
実装されたって感じですね。
できればこれ、
僕何個かメンテしてるんで、
使ってみましてって言いたかったんだけど、
時間ないんで、
マニュアンスって感じだったんですけど、
でも多分相当簡単に使えるんじゃないかなと思っていて、
そうだね。
NPMJSにGitHub ActionsのIDトークンが飛んできて、
それの署名検証してくれるだけっていう感じでしょ、
要は。
そうだね。
多分OIDCのクレームで、
エンバイルメントか、
エンバイルメントと、
だからあれだな、
サブジェクトだね、
サブジェクト見て多分、
ちょっとこのサブクレーム見て、
多分一緒にって感じなの。
今ワークフローのほう見たけど、
超簡単だね。
パーミッションにIDトークンライトつけて、
セットアップノードでレジストリURL、
これ多分設定しなくてもデフォルトNPMJSだと思うから、
めっちゃ簡単だね。
これやばいね。
これは便利だな。
ここまでいたLinux3、
要はGitHub Actionsの中でのIDトークンの取得とかも含めて、
このActionsの中でやってくれてるっていう感じでしょ。
そうだね、そういうことだね。
すごいね。
ちなみに多分前からあったんだろうなと思うんですけど、
GitHubもサポートしているって感じですね。
これは、
そうですね、
パッケージメンテナー目線だと、
GitHub Actionsでパブリッシュしてる人は、
トークンの発行が必要なくなるんで、
めっちゃ便利。
監視ごとは一つ減るっていうのと、
あとはリスク目線でいうと、
先週か先週か忘れたけど、
ここでは紹介しなかったけど、
割と有名なメンテナーのNPMトークンが、
何かで盗まれて乗っ取りされるみたいな。
だけど、
トークンを盗むっていう経路は潰せるから、
あとはNPMのアカウントさえ守れれば、
乗っ取りを防げるっていう状態になって、
ちょっとアタックサービスが減らせて、
リスク面も嬉しいっていう感じで、
なので基本やらない理由はないかなっていう。
じゃあNPM.jsのアカウントがどうやって守れるかというと、
今ね、
OTPのツールだけなんですよ。
全て登録したんだけど、
そうだね。
でもセキュリティあるよ。
え?
そう。
あるある。
長尺だった。
登録しとこう。
あれ?僕登録?
2FA。
本当だ。
僕見逃してたのかな?
これ最近な気がするな、もしかしたら。
じゃあこれで解決ですね。
ちなみに2FA自体は必須かどっかで知ってた気がしてるから、
まあまあって感じで。
セキュリティこれパス結構いけるのかな?
いける。
何だっけ?サードパーティー?
わからん。
私のバイビットは電はいけた。
うんうんうん。
ワンパスもいけるわ。
えー今、
収録中に作るっていうね。
めっちゃいいっすね。
これでいいじゃん。
じゃあ2FAやめよう。
2FAチェックオフTPやめよう。
じゃあもうこれで皆さん、
インフォスティーラーの許容案に残ってますけど、
あーいいっすね。
知らなかった。
まあなんか、
強いてデメリットあげるとしたら、
パッケージごとにこれ多分、
あーでもどうなんだろう。
まあでも多分パッケージごとだよな。
パッケージごとにそのトラスティック、
オアリーションセッターしなきゃいけないんで、
抱えてるパッケージが多い人はちょっと面倒だと思うけど、
まあ1回設定性はいいし、
そのパッケージごとにトークンきちんと分けたいと思うと、
その数だけのトークンを結局管理することになるので、
まあ例えばめっちゃ多くて、
アカウントに紐づくめっちゃ強いトークンで、
済ませたいですって人がいたら、
まあディスクとトレードオフじゃないですかって、
何度も言えない気持ちあるけど、
まあでも、
セキュリティと利便性
わかんないな。
これ要はさ、
このトラスティックファブリッシャーのこの設定のUIがいけてない、
っていう話なのかなとは思うんだよな。
その要は、
GitHubのIDトークンの、
任意のクレームを見てうんたらかんたらみたいなのがさ、
例えばできるだけでも結構できるようになってるし、
まあただその場合も、
例えばオーガニゼーションの部分は、
要はオーガニゼーションの部分が、
まあよほど正規表現とか書けない限りは、
なんかこれかこれかこれみたいなのとか多分できないと思うから、
まあちょっといっちょいったんあるけど、
例えばリポジトリはなんかもう省略可能とかさ、
そういうのもありかなと思う。
いやーでもな、むずいな、むずいな。
でも結局NPMJS上はやっぱりその特定のパッケージっていう感じだから、
やっぱりパッケージとは一対一対応してほしいから、
だから欲しいのは設定ファイルだね、これはね。
まあそうだね、確かに確かに。
それはそうかも。
NPMJSのアカウントとGitHubの、
なんだっけ、
アカウント連携してGitHubの、
自分のその個人の、
個人だったらダメか、
いやーどうすんのがいいんだろうな、むずいな。
まあいいや、なんかやり方はいい。
なんか言いたいことはわかる。
確かに、それ良さそうだね。
まあ確かにな、それこそそのモノリポでさ、
ロダッシュとかわかりやすいけど、
いやーでもこれいいっすよ、
なんかこの調子で、
まあね、PyPyとか他あんのかな、
NPM以外もやって欲しいなって気持ちで見てますけど、
頑張って欲しいっすね。
はい。
これめちゃくちゃいい、マジ朗報だな。
マジ朗報、マジ朗報、
マジ朗報だけど、
あの、リットに
この辺を全部丸投げしているゴーのやり方が実は
正しかったっていうか賢かったんじゃないかっていう気が
してきてしまう気はせんでもない。
オートスワガーの紹介
まあまあまあ。
30分話そうなんでやめときましょう。
戦争になっちゃう。
別にもう争うつもりないよ。
結構この、なんていうか、
難しいなって思って、
エコシステムとして別に、
作らざるを得なかったのか、あえて作りたかったのか、
この辺はちょっとなんとも言えないし、
まあなんでもいいっちゃなんでもいいんだけど、
なんか難しいと思って。
Githubでさ、なんか忘れたけど、
なんか、まあでもないか、
Github由来の脅威もあった気はしてて、
なんかその辺冷静に全部並べたときにどうなんだろうなっていうのは結構。
そうだね。
まあね、はい。
Dのとかはね、
GitURLでインポートできるんですよ。
Node.jsと互換性のある、
全く別のなんていうのがあるんですけど、
そっちとか使っている人に話を聞いてみるといいかもしれないって気がする。
僕は使ってないんで、スキップで。
まあね、なんか結構、
ありがちな最適解っぽいものとしては、
みんなが通るんじゃん。
何が正解なのかちょっと分からないけど、
まあでも朗報やな。
結構NPMやられがちじゃん、なんか。
やられがちだね。
うん。
たぶん正直大丈夫なんですけど。
まあやっぱ、二重目どこのパッケージは狙われがちだと思うんで。
うん。ありがとうございました。
よし、じゃあ次は、まあ次もサクッと書く感じなんですけど、
ブリピンコンピューターで、
フリーオートスワガーツールファインスターAPIフローズアタッカースホープユーミス
っていう記事で、
まあたぶんなんか提灯というか宣伝記事なんですけど、
まあ内容へーって思ったんでサクッと紹介で、
なんかオートスワガーっていうツールを紹介してて、
まあ要するにスキャンツールで、
スワガーは分かります?
スワガーってオープンAPIのあれ?
そうそうそうそう。
あれのドキュメントがあるかどうかを探すっていうやつで、
まあえーっと思って覚えとこうっていうのと、
あとなんか全然今週分の別の記事で地味にこれかと思ったのが、
ピックはしてないんですけど、
ウィズがそのViveコーディングのBase44っていうサービスがあるんですけど、
それのなんか、
まあ詳しく読んでください。
気になる方は読んでくださいって感じなんですけど、
認証をまるっと回避できちゃうっていう脆弱性があって、
それのリサーチ記事があるんですけど、
これの脆弱性を見つけたとっかかりは、
スワガーAPIのドキュメントがまるっと公開されてたっていうツールが
入り口になってて、
オートスワガー使ってんのかなとかいうので、
FYIというか紹介したって感じです。
脆弱性診断ガイドの意義
ツールとしてはどう言われるんですか?
ツールとしては普通にOSSだからフリーで使える、
なんかCLIで使える、
なんかURL渡すとスキャンしてくれるって感じっぽい。
ちょっとね詳しくは見てないんですけど。
おもろいな。
なんかでもおもろいな。
おもろいけど、
でもこういうのができるってことは、
同じドメインでオープンAIとか
スワガーのこのドキュメントを
ホストしてるところが多いってことでしょ?
そうだね。
おもろいね。
なんかやりがちだよなって気がする。
例えばディブ環境にだけ開発効率化のために
設定漏れてて本番に出ちゃってるとか。
そもそもディブのURL誰もアクセスしないというか
別に拡大してないんだけど、
ディブのURLでアプリケーション側は
例えば認証かかってるけどこのページだけ認証かかってなくて
パブリックになってるとか
やっちゃいそうだなって気はせんでもない。
なんかやっちゃいそうと思いつつ
感覚的には結構信じられないというか。
まじかよ。
ドットキットをプッシュしちゃうような
アジタグリではある気はするね。
今時ドットキットを公開ディレクトリー
公開ディレクトリーという概念がさ
もう
コンテナとかの世界観とか
あんまないよね。
公開ディレクトリーという概念がもう早い。
静的ファイルを置いたら公開みたいな
そういう感じの
気はするね。
でもアパッチにもっと
PHPで動いてるサービスとかは普通に
まだまだいっぱいあるだろうから
ないとは言えないけど。
あと僕らの会社だったら正直
1から100把握してるわけじゃないけど
その
だいたい何のサービスがあって何のアーキテクチャが動いてるか
わかるじゃん。
まあないかなって言えるけど
把握できないってなってきた時にどこでどんなアーキテクチャが動いてるか
みたいなのがわかんないみたいな図になると思うし
一見標準化されてるように見えて
とあるプロジェクトでは
スピード超優先でみたいな
すごいレールから外れたアーキテクチャで実際
スタートしてたみたいなパターンであると思うんで
なんかわかんないけど
これは多分氷山の一角でこれ系のツールを
脳死でデイリーで実写のドメインに回して
だからその辺がもしかしたらASMLのあれだろうね
ASMLとかはもしかしたら裏側で待ってるのかもね
とか思うんだけど
えーっていう
これあれか
宣伝してるサービス性のあれなんだ
これがメインどころかちょっとわかんないけど
うち大丈夫かな
使いたくなるよね
こんなとこで話したらダメです
明日スロックで話そう
じゃあ次お願いしてもいいですか
はい
脆弱性診断ない性格ガイドを出しましたよ
IPAが
話です
なんか
なんだろう
さらーっと読んだんだけど
フリーの話とかもあるし
個人的には色んな意味でタイムリーだな
ただ割とデカいとこ向けの話なのかなと思いつつ
読みましたという話です
IPAこんなのも出すんだねという
採用の話とかも書いてあって
人材確保育成
なんか割と
ちょっと僕全部メイトしてないですけど
目地見る感じ
必要な事故はもうなしです
現実問題どうなの予感は何個あるの
わかんないけど
やっぱこれ系さ
汎用化というか
最大効薬取ろうと思うとこうなるよねって感覚になる
僕ら向けでは
ないという感覚は
正しいっちゃ正しい気はしてて
僕ら向けにすると外れちゃうスコープがあるから
広くセキュリティを
サイバーセキュリティに向けられなきゃいけない企業が
なるべく使えるものっていう
ギルドで言うとこんな感じになる気は
個人的には結構
46ページ
モチベーション維持とキャリアパスみたいなところとか
もっと深掘りしてほしい
そんなの書いてあるの
確かにね
なんかさ
ベンダーでセキュリティテスターをやるのと
インハウスでセキュリティテスターをやるのって結構
大きな違いがあると思っていて
インハウスでやってるとだいたい似たようなテックスタックで
似たようなアーキテクチャっていうのばっかり見ることになる
なんていうか
業務そのものにおける技術的進歩って
そんなに機械として多くないはずなんだよね
インハウスでやってると
ベンダーと比較するとってことだよね
少なくとも
代わりにって言い方をすると
ちょっとあれだけど
ある種のトレードオフとして
逆に得られるものが何かというと
フリーみたいな感じで
効率化だったりとか
あるいはインハウスならではの
施策みたいな部分っていうのがあるわけで
それってでも極論を言うと別に
セキュリティテストじゃないわけじゃん
セキュリティテストを
セキュリティテストの
エコシステムというか
テストそのもの
テストという行為そのものではなく
それを取り囲む何かに対しての貢献みたいな部分が
多くなっていくというか
そこまでいくと逆にベンダーチックだなと思わんでもないし
でも一方で固有のナレッジみたいなのが
当然あるわけで
そういうところをアンドキュメンティッドなものを
アンドキュメンティッドなものにしましょうみたいな話とかは
インハウスのアレとしてはあるだろうし
何が言いたいかというと
根本的に
その人が目指している方向性によって
そもそもの向き不向きがあるんじゃないと思うんだよね
インハウスの診断次第ってことだね
確かにね
新卒中と採用のポイントみたいなところで
カバーされてるかというと
そこまでじゃないよなと思うし
確かにね
一応この7-5-3のキャリアパスの提示みたいなところが
前後は逆というか
これを多分前提として採用しなきゃいけないって話だと
理解してる
結局でも最終的に
このキャリアパスの提示みたいなところで話してると
診断員という
一本道からある程度外れるようなところを
示すといいよって書いてあるわけで
要は診断員としてのキャリアパスっていうのは
そもそもないよって言ってるようなもんじゃんって
ちょっと思っちゃうんだよな
っていう世界において内政化って
本当に成立するんじゃないかって
っていう世界において内政化って本当に成立するの?
っていうふうにちょっと思ってしまう部分はあって
だから診断の内政化じゃないんだよっていう
その
その表現しっくりくるな
手段の目的化が起きてないっていう話なのかな
多分言い換えるぞ
だいぶ話しながら自分の中で整理されてきたけど
めっちゃでも今のフレーズがめちゃくちゃしっくりくるな
確かに
チームの機能として目的として
何があってそこに
順番はそうだよね目的があって手段があって
その手段を実行する方法として
人材が必要か必要じゃないかみたいな
確かにね
っていう意味で割とタイムリー
個人的にタイムリーなトピックだったし
参考になるところもあるんだろうなとも思う一方で
個人的には結構燃える部分もなくはないな
そうね
思わなかったり
全然フォローってわけじゃないんだけど
なんか僕よく邪推しちゃうな
邪推かもしれないですけど
セキュリティ診断の本質を
よくも悪くも理解してないステークホルダーに見せるアセットとしては
ちょっと使えそうだなと思ったり
確かにそういうところではきっと使えるんだろうな
IPAっていうのがあってこういうものを出してまして
内製化にはこんなメリットがあって
あとは結構セキュリティ用わからんっていう
人が多い中で
距離を縮めるみたいな
そういうところにも寄与はするんだろうね
そうだね
内製品の道具みたいに言っちゃったけど
別に変なのしうちの会社とかでも診断よく雰囲気で
やってるんだなと思ってる人が読むんだけど
学びがある部分が全然ないわけではない気もするな
形式手法と生成AIの重要性
ノータンはあるんだけど
ノータンは
仕事として受けて
仕事としてセキュリティレビューしてることもあるから
仕事は仕事なんだけど
ベンダーで案件として受けてるときの
診断の強度と
社内で片手間に見てるセキュリティレビューの強度って
全然レベルも違うので
何の話をしたか
まあ確かに
理解を得るみたいなところで
ちょっとこれどの辺の
何を念頭において
作られたやつなんかすげえ気になってきたな
そうね
まあその辺真の
真の裏ゴールみたいな
きっかけみたいな部分は多分そんなに書かれないかな
オジェクトメンバーを全員知らないんだよね
ああそうなんだ
わからんハンドルネームと名前が一致してないだけの
パターンもあるかもしれない
ない人の人たちなのかな
まあいいや
次いきますか
形式手法入門
生成AI時代の設計のあり方について
サイバーエージェントのデベロッパー
なんかちょっと
薄い話で詳しく読んだけど
出たな形式手法
2回目だよね形式手法
その時から結構注目はしてるんだけど
セキュリティみたいなところにも
役立つよねと思ってたし
なんか
この生成AI時代の設計と
実装の一致みたいなところを
形式手法で評価しようみたいなアプローチ
確かにそれめっちゃ刺さるわ
という
ただそれだけ
形式手法って何みたいなところとか
2フェイスコミットを形式手法で
形式手法的な考え方で
モデリングしていくとこうなるよね
形式手法そのもんだから
っていうところからかなり紹介してくれて
記事としてはすげー読み応えあるのと
めっちゃ勉強になる
アプローチのしっかり具合とか
記事の構成とかが個人的に
かなりすっげーと思いながら読んで
なるほどなーって読んでいったら
未踏の人だったっぽくて
なるほどねっていう
めちゃくちゃ納得感が
納得感が
いい感じになりました
未踏25歳でも未踏いけるんだね
なんか制限変わったんだっけ
未踏は結構年齢制限
緩くなかったっけ
25歳未満だだからギリなんだ
でもそうかそうだね確かに
陰性の人やってたな
この記事ちょっと直前に
子供に貸し付けしながら理解できない
自分もねしちゃうよね
結構頑張って読んでたんだけど
授業読むごとに
知らない概念がどんどん出てきて
ノートに取りながらやりたい
私もねちゃんとは読んでない
すごいちゃんと書いてある
これはいい記事
最後の語言語で
これを表現できるようにするよってやつとか
いいよね
MCPの認証と認可
未踏ならではだと思うんだけど
実装に落とし込むっていうのがマジで素晴らしいと思っていて
本当に
ありがとう
実際の理活用までのギャンプというか
そこがどう埋まるかみたいな部分
今後に期待したいな
実装一個あれば結構
埋まるじゃんそこの距離が
埋まるかな
誰が埋めるんだろうっていうのと
これ埋める能力をどうみんなに獲得してもらうかみたいな部分に
最初読みながら思います
それはある
形式手法っていうものがあってね
設計と生成AIが出してきたコードの
正しさの保証みたいなのができるよ
アイデアベースのところからだいぶ進むじゃん
ちょっと試してみようが
実際難しいかもしれないけど
世界として近づくというか
それこそ未踏領域というか
素晴らしいな
これは面白い
ツーフェイスコミットっていうのがいいよな題材として
まさにって感じ
形式手法の話をするときに
定番の題材だったりするのかな
どうなんだろうね
次最後か
ちょっと自信ないながら
MCPの認証と認可の現在と未来
これはなんて読むんでしょう
HI120KIさん
多分なんか読み方があるんだろうな
ひろきさんなんすかね
ひろきさんかな
12がRなんだ
ちょっとおしゃれ
ちょっとおしゃれな
あれでしょ
先週
メルカリのAI関連の
スライド紹介しなかったっけ
その人かな
多分名前に見覚えがある
私は面識ない
記事の内容としては
結構
読んでくださいと言いたいところなんですけど
タイトル通りそのMCPサーバーの認証の
認証認可の今時点の状態と未来
こういう議論があるよみたいな部分で
そうだな 長いんで全部話せないんで
開発モードと現状みたいなところで言うと
OS 2.1をベースにMCPサーバーの仕様として
実装されてるよみたいな部分がありつつ
現時点で例えばダイナミッククライアント
っていうのが登場していて
これはこの機能が
MCPサーバーの仕様としては
推奨されてるのか 推奨されてるんだけど
これを使うことで懸念分みたいなのがありますよ
という話とか
あとは
個人的に
印象深かったのは
このConfused Duty Program
っていう言葉とかは知らなかったんですよね
AWSのドキュメントに記載されてるんだけど
意味としては
例えば記事にある例で言うと
例えばMCPサーバー MCPサーバーじゃなくてもいいけど
何かAmazonとかGoogleクラウド AWSとかGoogleクラウドに
アセットがあってみんなにアクセスしてほしいってときに
個々の認証じゃなくて例えばGoogleクラウドだったら
サービスアカウントを回避するみたいな
サービスアカウントでアクセス権をみんなに付与するみたいになったときに
そのサービスアカウントが実は
サービスアカウントの権限を持ってる人が
本来アクセスできないところにそのサービスアカウントが権限を持ってるみたいな
パターンをConfused Duty Programで
表現した
名前ついてるじゃん
貫通するやつとしか呼んでない
なんかある
意図しない権限昇格とか
そんな感じ
ほんとサラッと見ただけだからこのページ読んだらもうちょっと厳密な
あれがあるかもしれないけど
斜め読みすると詰まってこそという感じなんですけど
MCPサーバーとかで
Notion APAトークンとかはわかりやすいですね今だと
公式のNotion APAサーバーは僕の認識してる最新バージョンだと
インテグレーション使うんですけど
インテグレーションと人は紐づかないんで
インテグレーションを介して見れないページが見れるとか
そういうのも多分問題に該当するんだけど
この辺が何でしょうね
企業でエンプラで使うってなった時に
足を引っ張るよねみたいな話を丁寧に
かなり丁寧に解説してくれたりとか
あとなんか面白かったのが
これは多分未来の話にあたるんですけど
本当にざっくり言うと
例えばOktaのOIDPとして使ってる時に
各種MCPサーバーの認証っていうのを
Oktaに移情して
Okta側では Okta自身の認証ももちろんそうなんだけど
Oktaに認証することで認証した従業員が
この人はGoogleでGoogleクラウドで
これとこれの権限を持ってるとか
Jiraでこれとこれの権限を持ってるみたいなところを
判定して
その判定に基づいたその権限を持った
アクセストークみたいなものの管理を
Oktaに移情するみたいな
MCPサーバーはそれを受け取ったものを使って
利用することで
JiraのMCPサーバーを使うときはJiraで認証して
サービスごとに認証して
その認証の仕様がちょっとブレててみたいなところから
周りとOktaに一元管理できる部分とかも
話としてあるよみたいなところが
仕組みとしてはSTSだよな
そうなのかな
感覚的にはそうだよね
自分のアイデンティティを示す何かを
Oktaに提示することによって
別のトークンがエクスチェンジで
Oktaによるアクセス管理の未来
帰ってくるよって話だから
完全にセキュリティトークンサービスだよね
仕組みとして
これは実現した未来だなと思うんです
ただOktaが連携するサービス側が
判定しなきゃねみたいな話とか
今後ウォッチする必要がありますよとか
そういう部分が話としてあったりとか
まだMCPが作れそうだと思ったけど
作れそうだけど
結局
結局どこがネックになるかというと
あれなんだよな
MCPがつなぎにいくサービス側の
トークン発行とか
トークンの権限の
流度による
ぐらい細かく色んなものが制御できる
ファイングレインドな
トークンが発行できるんだったら
結構なんとかなると思うんだけど
ノーションのインテグレーションのトークンとかが発行できてもしょうがないじゃん
多分
大味なトークンしか発行できない
サービスだとあんまり意味がなくて
そこさえなんとかなれば
オクタがやってくれますって話だったら
IDPとしてオクタ使ってると超楽ではあるんだろうけど
あとは仮に権限が大味だとしても
大味でも使うって意思決定をしたときに
多分デカい差分としたら
ノーションの例で言うとインテグレーション自分たちで
個別に個人個人に発行できる
自分たちで個別に個人個人に発行して
トークン渡してみたいなのが全部
オクタに移情されるイメージなのかな
そこの管理コストはめちゃくちゃ減るんじゃないかな
トークンの実態がないとか
実態はどっかにあるんだろうけど生存期間が短いとか
そういう部分がやれるイメージなのかな
自動でオクタがリボークしてくれるってことだよね
そうだね
オクタのクローズアップアクセス機能みたいな
名称なんだけど
この辺記事とかあるんだな
ちょっと読んでみないと
もうちょっと勉強しますって感じで終わりつつ
こういうのないときついよなとは思うから
オクタでそもそも
アクセス制御ができてるサービスあるっていう
前提なのかなもしかしたら
オクタのクローズアップアクセス機能に対して
SaaSとかがちゃんと実装してくれたら
使えるって話で
オクタが頑張ってプロバイダーの数だけ実装するって話じゃないから
そこはもう多分ウォッチというか
どういう世界になるかはなんと
IT
むずいな
この辺のサービス割とそこそこの規模になってる
ふんわりとした前提があるような気が
せんでもないんだけど
こうなってくると結構話変わってくるような
確かにね
ぶっちゃけ60人70人規模の会社
我々でも普通に
Googleワークスペースのモーガリゼーションユニット
しちゃちんといいなみたいなのが
普通にあるわけじゃん
ありますね日々苦しんでます
オクタがこの辺やっぱ強いんだよな
じゃあオクタいりますかって言われたときに
いやー難しいね
お金
エントラーITとかは結構いい線
意外とその市場が面白い構造になってる
そう考えてみると
Googleワークスペースもうちょっと頑張ってほしいな
Googleワークスペースもうちょっと頑張ってほしいな
この辺詳しくなすぎて歴史的にどうなんだ
Googleワークスペースって後発なのかな
アクティブディレクトリーまで遡れば
後発ではあるよね
オクタとかどうなんだ
オクタは割と新しい
2009年
割と
この辺のAIアジェント周りのアップデートとかを
オクタはバンバン出してる気がするから
今後にこっちって感じ
現状何ができる
MCPサーバーの仕様として何が担保される
何が担保されないか
ぜひ読んでみてはという感じです
いいな
こういう話メルカリン仲良いできます
そうだね
1,2,3,4,5,6,7
7本
熱出さずに乗り切れましたね
熱は出てるのかもしれないけど
熱はないと思うよ
冷えピタの魅力
ずっとペタペタできる冷えピタは欲しいけど
熱さに負けず
ずっとペタペタできる冷えピタって
ずっとペッタンペッタンしちゃうと思う
気持ちいい
やだなマイクにその歌入れるんでしょ
高画質な音で
どっかずっとペッタンペッタンできる
冷えピタって何どこの
小林製薬さんお願いします
冷えピタって特許あんのかな
冷えピタみたいなやつあるもんな
冷えピタは
小林製薬は熱魂シートだわ
冷えピタはライオンなんだ
商品名としては冷却ジェルシートらしい
日本の発明品らしい
どこでもいいや
こんにゃくのアイディア
ペッタンペッタン
ヒントをくれたのは
刺身こんにゃくだって
刺身こんにゃく
めっちゃでかいの買ってすげー薄く切って
1枚1枚ペッタンペッタンってやって
ループ回しながら使ったやつは冷蔵庫入れてってやれば
無限期間できんじゃない
氷水張ったボウルとか置いといて
普通のこんにゃくを入れといて
ローテすればいいでしょ
そうだね来たじゃん
いやー
ジェル感はないな
それは本当にそうだね
実験パターン
なんかすげー
今さら
こんにゃくじさん
こんにゃくペタペタしながらたまに食べてる
お願いします
いやーAI
今週もAI来週もAIそれ週もAIですね
だいぶいいね
なんかこなれてきたね収録
こなれるとは
悪い
やっぱさすがに
いい意味で
取り上げる
勘どころというか
そこの話
くそしょうもない雑談を
してるのを持ってこなれてる
それは雑談ぐらいさせてよって感じ
わからないけど
わりと収録前にこの手の雑談
収録前収録後にこの手のしょうもない雑談を
してることが多いと思うんだけど
最近疲れててさっさと収録しようぜっていう
話もそこそこに
いつも収録してるから
それはある
確かに皆さんお付き合いいただき感謝
再生ボタン消してるかもしれないけど
そんな感じですか
最近全然フォロワー増えてない
まあまあ
誰も聞いてないのスケジュール
ロングテール積み上げ授業
急に仕事の話みたいに
じゃあ来週もお楽しみに
おやすみなさい
はい
