00:00
こんばんは、Replay.fm 第71回です。
こんばんは。はい。
はい。1回、1月も終わり。 終わりではないか。あと1週間ぐらいでおしまいですけど。
うん。 あっという間ですね。
早かったね。 早かった。
あと寒い、最近。 うん。
なんか年明けだなーとか思ってたら、あっという間に1月終わるもんね。 うん。
なんか、自分が小学生の頃とか、正月5回ぐらい長くなかったっけなってめっちゃ思うんだよな。
うん。 正月間、短すぎね。なんていうか。
マジで一瞬じゃん。
まあね、なんか、ああまた正月かって感じ。
正月だらだらするかーってなんか、なんか2回ぐらい寝て起きたら、なんか、はい正月終わりですよみたいな感じかもし出してくるの納得いってないわ、結構。
うん。
もうちょっと1月いっぱいぐらいは新年館出して、あ、でもあれかー、なんか新年会とか行く人は新年館味わってんのかなー、今も、もしかしたら。
うん。 そこに格差があるのかなー。
いやー、うーん、でもなんかさ、なんか、もはや今頃の時期に別に新年会やっても新年会館ないよね、なんか。
ないのか。
いやーわかんない、なんかもう新年館が自分の中でなくなっちゃってるから、そうなのかどうなのかわからないけど。
なんか新年って言うよりかは、キックオフ館の方が強いかもな。
うーん、ね。
うーん、なんか。
なんだかね。
あのー、正月を15日ぐらい前に延ばす法律を誰か作ってくれることを願って、今日も記事を読みますわ。
読んでいきましょう。
はい。
願いを込めて。
でねー、もう新年会なくなったか、せいか知らんけど、記事の数が無事戻りまして、直近3、4回ぐらいは記事数少なすぎて、解散かーって思ってましたけど、全然そんなことなかったっす。
うーん、結構危うかったよね、なんか。
解散の危機だったよ、正直。
一記事、一記事とかはもうだって、スキップ、なんかねー、別の類似の、類似中かちょっと似たようなことやってるポッドキャストとかで、今週はお休みですとかたまにやってて、
お休みするんだーとか、まあ確かに毎週は大変だよなーとか思ってたけど、普通になんか、ソースがなくなるとかあるんだなーっていうのはちょっと学びでしたね、今年度の。
はい、今日はね、10個ぐらいですか、あるんで、サクサクいきましょうか。
はい、やっていきましょう。
あー、アタレッサのお便り、はい、引き続きお待ちしておりますっていう、まあGoogleフォームで受け付けておりますので、
来ねーなー。
XかNotionか、来ないなー。
来てーなー。
もうなんか100回ぐらいまで来ないもんだと思って、僕は喋り続けますよ。
はい。
まあなんか、そのうちなかったことになってるかもしんないから、お便りは送れるうちに送っとけと。
送る側の立場になったときに直近にかよ、まじで、もうなんも、だってもう1記事しか読んでるし。
別になんか、記事のことに関してとかじゃなくてもいいと思うけどね、なんか、休日は何して過ごしてますかーとかさ。
それはね、自分を高く見積もりすぎでしょ。
そんな、俺らの休日に興味ある人なんて、まじで。
相当、
興味、興味あろうがなかろうが、なんか送ってやろうの気持ちで、なんか、こう、送ってきても別にいいよ。
まあ、そうね、はい、お待ちしてます。
好きな食べ物は何ですかーとか、なんか、知らんけど。
やけやしが欲しがってるんで、みんな送ってきてください。
いやー、なんか別に、うーん、何ならないでいいけど。
うーん、まあ難しいね、なんか。
やっぱステッカーとか配らないとダメなんだな、きっとね。
そうかもしんない。
ステッカーを発注するか、デザイン。
発注するかー。
うん。
はい、じゃあ1期目。
CEO詐欺メールの実態
えーっと、LINEグループ作成を要求するCEO詐欺メールについてまとめてみた。
我らがP.O.LOGの記事ですね。
どういう記事かというと、これは、いつ頃の記事だ?
1月16日だから、まあ、ぴったし収録日の1週間前ぐらいですけど、
まあ、日本全国でCEO詐欺と呼ばれる不審なメールが増えており、
特になんか結構メールのバリエーションはいろいろなんですけど、
何かと理由をつけて、
LINEグループを作れっていう指示を出すっていうようなメールが結構多いと。
で、これ引っかかっちゃうと何が起きるかというと、
ICメールの言う通りに作ったLINEグループで、
CEO、社長を装った人から、
こういう理由があるからここにうんぜんまん振り込めみたいな指示が飛んできて、
したがっちゃうと無事被害に遭ってしまうっていうような攻撃のスキームになっていますと。
で、こうやって言うと、特に僕らとか、
またWebベンチャー、Web系事業会社かな、ITの事業会社とかだとあんまり引っかかるイメージはわからないんですけど、
実は結構な被害がこの記事を執筆してるのも結構出ていて、
このピオログで紹介されている記事だと合計もう3…
僕が計算した時よりめっちゃ増えてるな。
ちょっと待って、9億8千万ですか。
え、追記されたってこと?
アップデートされてるね。東京のやつとかね、3億だったはず最初。
違う違う、1億5千万とかだったかな。
今9億…8億5千万かぐらいになってる。
すごいね。
すごいね。
はい、なんで結構被害出てる。
8億…はい。
で、まあ注意喚起はこんなところでしても仕方がないんですけど、
そういう事件の紹介をしていて、結構個人的には…
個人の感想としては、僕らの現職もそうですし、
僕の前職というか渡り歩いてきた会社もそうなんですけど、
メールで仕事しないから、
スラックとか会社によってはTeamsとかも使うと思うんですけど、
そういうもので連絡するのがメインってなってると、
結構あんま引っかかるイメージは湧かないよなと思ってて、
メールで社長から指示が飛んでくるってのも意味わかんないし、
そこでLINEグループ作れって言われるのも意味わかんないし、
スラック使ってるのはスラックで連絡しろよだし、
Googleワークスペースだったらね、
Googleチャットの方で連絡来た方が自然だったりとかするんだけど、
一方で被害にあった企業の具体名とか全部追ったりはしてないんですけど、
おそらくメールと電話と紙で働いてるような会社なんなら多分…
なんでしょうね、いわゆるDXが進んでないような会社とかと、
被害の認識
引っかかっちゃうのかなというか、
この被害額のデカさを見ると、
引っかかるとか引っかかるっていうのは結構事実なんだろうなっていうのは思っていて、
P.logでも書いてあるんですけど、
メールの内容かなりいろいろあって、
それ見るとあんまりめちゃくちゃ手が込んでるとは言えないというか、
例えば何か会社向けに、
この会社を狙い撃つためにその会社雇用の情報を混ぜ込んだりとか、
信憑性を持たせるような工夫みたいなのあんま正直見られない。
そうだね、
なんて言ったらいいんだろう、
言い方が難しいというかあれなんだけど、
これでこんだけ稼げれるとしたら笑いが止まらない。
そうだね、この議会選はね、
何個か紹介するときは多くても10行ぐらいとかだよね。
ちょっとどのメールで引っかかっちゃったのかまでは分かんないけど、
結構おいしいよなっていう攻撃する側化するとって感じだし、
ある程度まらまいて記憶近く稼げちゃってるんだったら、
当分ちょこちょこ続くんだろうなっていう感じですかね。
意外と僕がスギティマリーキャッチアップし始めてから、
日本で一般企業をこんなに広く狙うパターンはあんま見なかったんで、
そういう意味でもちょっと印象深いなっていう感じですね。
一部には中国語が混ざってたりして、
中国のアクターなのかグループなのかそういう部分がちょっと匂わせつつ。
ツールのテンプレートのあれが入ってるみたいなのがあったよね。
なるほどね。
はいはいはい。本当だ、変数みたいなのが。
なるほどね。
あとは今日別の記事でもあって、
ちょっと紹介したってもいいと思うんだけど、
メールなど滅んでしまえばいい?暴論っていう個人の方が書いてるブログがあって、
これでも多分この事件を取り上げていて、一緒に紹介しちゃいますけど、
何だろうな、詰まるところを何というか、
メールの責任対策限界あるよねって話をこっちでは語っていて、
そうだね。
まず何か人にパッチ当てんの限界があるっていうのが1個目に挙げられてて、
メール受け取るのが人で、その人が間違えたらおしまいっていうところに対して、
じゃあ人に対して訓練をしようとか、
よくあるんだとフィッシングメールの訓練をするとか、
そういうのがあるけど、それは限界あるよねって話と、
あとは依然として、侵入経路としてメールがあるよって話もあって、
これに書いてある何か、ここじゃないかな、
どっかに書いてあって確かになと思ったのは攻撃者目線でいうと、
企業の人にコンタクトを取るときに一番やりやすいのがメールだよねみたいな部分があって、
そのブログ中のフレーズを借りると、
外部からの入力を従業員の個人の受信トレイに直接届けるっていう、
メールってそういうものだからっていう話なんだけど、
この性質がかなり攻撃者にとって最も効率的な勝手口であり続けてっていう表現になって、
これは確かになっていう個人的に思ったりとか、
あとは防御コストの非対称性と割に和らさみたいな部分も触れていて、
メールセキュリティの限界
ガチで対策しようと思ったときにやんなきゃいけないことが多すぎるみたいな感じだったりするところですね。
なので、このメールなぞほるんでしまえばいいは多分暴論なんだけど、
この記事とさっきのちょっと言っちゃったけど、
スラック使ってると引っかかるイメージわかんないなみたいなところを思うと、
メインのコミュニケーションチャンネルとか、
少なくともこのブログにも書いてあるけど、
金銭のやり取りというか、金銭が動くような業務とか、
クリティカルな業務はメールでやらないみたいな風にやって、
メールで何か動くのがおかしいっていう世界観にする、
は全然普通に考えた方がいいんだろうなっていうのもちょっと思いつつっていう感じですね。
例えばメールとスラックから見ると明らかで、
僕らのスラックのDMに外部の全然うちのこと知らないアクターが、
メッセージを送る手段って難易度ってメールに対して死ぬほど高いというか、
逆にメールのハードルが低すぎるというか、
自動化して数うちは当たるだろうし、
会社のメアド書いた名刺なんてそこらじゅうに配ってるっていうのが当たり前だろうし、日本の場合は。
あと、普通にその辺で公開されてるメールアドレスとか多分、
問い合わせ先として出してるものっていっぱいあるはずだから、
多分そういうところにめっちゃ送ってると思うんだよね。
間違いない。
はい、そんな記事でございます。
でもなんか気軽に送りやすいって意味だよな。
なんか、
まあもうなんか滅ぶっていうのはちょっと想像がつかないんだよね、やっぱり。
外部とのやりとりっていう文脈においては、
なんかいい代替えは思いつかないね、確かに。
でも結局さ、その、なんかじゃあ、そうすると入り口としてのメールっていうのは、
なんかどうしようもないわけじゃん。
どうしようもない。
なんかその、さあなんか、今回のってなんかまあ、
今回はその、なんて言ったらいいんだろうな、
その次のステップがLINEのグループだったから、
まあまあまあって感じではあると思うんだけど、
じゃあその、こうどうしても入り口がメールになってしまう中において、
例えばその、こう難しいな、
なんか社内の手続きとかは、
まあそのメールを一切返さずにやれるようにしようっていうのはまあ分かるんだけど、
その社内の手続きに限らず、
何らかその、そこそこ重要なやりとりっていうのは生じ得るわけで、
なんかそういう中において、
入り口としてのメールのその先で、
その、じゃあ何を持ってその信頼する担保するのみたいなのって、
まだまだ、なんか我々は答えを持ち合わせてないというか。
そうね。
なんか、
結局入り口がメールになってしまう以上は、
なんかその後のやりとりのすべてを信頼するっていうのがもう無理なわけだから、
なんか、完全にメールをなくそうって思うと、
なんかちょっと困っちゃうねっていう。
うーん。
うーん。
まあむずいね。
まあでも今回のケースで言うと、
セキュリティの内部と外部
少なくとも内部外部で分けるっていうのはありな気はしていて、
うんうんうん。
まあ内部のやりとりは、
まあメールで原則やらない。
まあ原則っていうのは、
例えば、
まあスラックが死んだときにメールしかもう残りのチャンネルがないケースとかは、
じゃあその社員メール室でやりましょうとか、
まあそういうのをまあ避難訓練に合わせてやるとか、
はまあ、
多分やらざわめないかもしれないけど、
まあそれ、
あの、
まあそういう形で社内を整理して、
で社外とのやりとりは、
まあ多分なくせないから、
メール使うなとは多分言えないから、
まあやりましょうっていうのがあって、
そうやって分けると、
何だろうな、
ちょっと問題のスコープを減らせるっていうか、
社内のメンバーを語るっていうケースに対する体制を、
仮に得られるんだとしたら、
じゃあ他はあれだよね、
なんか見ず知らずの怪しい人とか、
あの外部の知ってる人を予想、
なんか有名な会社を予想みたいなケースに対してどうするかみたいな形で、
少し切り崩せる気がするから、
まあそういう形で整理するのありな気はするけどね、
ただなんかキリがないっていうのは間違いない気はしていて、
あのいかんせんなんか幅が広い、
幅広いっていうのは何でも気うる、
そのセールスメールも来るかもしんないし、
なんかお得意先とのメールやりとりもするかもしんないし、
登録してるサースのメールマガも来るかもしんないんで、
だからなんかそこはまあ悩ましいし、
なくならないだろうし、
なんかなんでメールはダメで電話はいいんだろうね、
別に電話がいいって誰も言ってないと思うんだけど、
でもそれで電話の詐欺もめっちゃあんのか、
最近ケースですみたいなやつね、
結局同じ性質の問題があんのかな、なんか。
それこそピオログで、
BECとかはね、
だからBEC的な感じで電話が絡むっていうのは普通にあったりするから、
まあ全然電話も同じなのか。
メールのほうが数は打ちやすいから、
そこ、その差があるだろうね、普通に。
メールで、
だから多分メールで9億儲かるなら、
多分わざわざ電話せずにこれを多分やり続けるだろうし、
これでどっちが安いか、
どっちでいっぱい金を引っ張れるか、
もしくはなんか星以上を引っ張れるかみたいな感じなんだろうね。
いやー、これ被害が増えてるのちょっとえぐいな。
6億、6億、東京都だけで6億ですよ。
まあまあ会社が多いかっていうのはあるけど、
えぐい、えぐいなまして。
いやー、はい、お気をつけください。
これに限らず。
そういう感じですかね。
Oktaの認証基盤移行
嫌になっちゃいますね。
次行きますか。
はい、いきましょう。
次が、
奥田から内製IDPAの認証基盤移行第2回DNAエンジニアリングブログの記事でございます。
なんかちょっとさらーっと眺めただけなんだけど、どうでした?
そうですね。
これ第2弾なんで、第1弾多分第前に読んだんですけど、
実際にどう実装したかの話をされていて、
規模感でいうと10人で約1年かけてやったよとか、
9ヶ月ぐらいかけて300か400のSAS移行したよとか、
みたいな部分が書いてありつつ、
なんか具体的な部分はアタックベクターになっちゃうから防えるみたいな感じで、
例えば言語とか、
実装時にこけた細かいポイントみたいなのがないんで、
まあなんていうか、
10人程度で1人かけてやれてすごいっていう感想しか、
まあ持てないっちゃ持てないかなっていう感じで、
ただその第3弾もあるっていうふうに書いてあって、
これ移行してリリースして、
まあ社内で運用できてるのかどうかとか、
どういう方が出たかみたいな部分がずこぼれてるらしいんで、
なんかそれにとても期待してますという意味で、
ピックしたっていうところが僕は大きいですね。
あとはなんか移行期間で、
そのオクタに対してプロキシするみたいな部分はなるほどっていうか、
これはなんか、
オクタを何かに移行しようと思って、
なんだろう、内戦に移行しようって思わないと、
多分あんま出会わないユースケすぎるというか、
まあなんかそのソフトエンジニアとしては自然な発想なんだけど、
いや、やれるんだなーっていうのはちょっと、
これはなんか、
この人たちじゃないと見えない世界観だからちょっと面白いなって。
でもなんか別にこれってそんなに変なことじゃないっていうか、
なんて言ったらいいんだろう、
どうなんだ、変なことじゃないのかな。
でもGoogleワークスペースとオクタがいる環境で、
Googleワークスペースとは繋がってるけど、
オクタとは繋がってないみたいなサービスがあったときに、
順序としてはオクタを踏んで、
Googleワークスペース踏んで、
そのサービスに入るっていう感じになるよね。
そういう構成があるんだね。
それはあり得ると思ってて、
だから多分それに近いんじゃない、普通にね。
なんかその発見、記事上でも発見のことをしてるわけじゃなくて、
そのサムラ自体にそういうふうにリレーしていく仕様かなんかがあるから、
まあそれでって書いてあって、
まあ確かにそうじゃ、
まあ知ってる人は知ってるって話なのか。
わかんないけどね、なんかわからん。
俺の想像してるものと全然違う。
ちょっとIEPは素人なんで、
全然違う可能性あるから、
なんとも言うけど。
どうでした?
え、なんかちょっと流し読みして思ったのは、
まず内製化にあたりプロジェクトの体制をご紹介します、
たらかんたらかんたらって書いてあって、
という非常に小規模なメンバーで活動していますって書いてあるけど、
なんか当たってる人が結構な、
まずプロジェクトマネージャーが1人いて、
開発チームとしてメイン1名、スポットで補佐3名、
設計運用チームとして3人、
品管から兼務で4人、
インフラから兼務で3人っていう、
非常に小規模なメンバーで活動しているって話で、
なんか結構小規模とはってなったかな。
当社費なのかな、DNAさんだと。
でかいから。
当社費、
まあね、当社費だけどさ、なんか、
開発っていう意味だと確かにでも少ない気がするね。
開発だけ見るとね。
なんか奥田と同じ挙動のものを作るって思うと、
まあ小規模な気がするね。
確かにな、まあメルカリのIDPとかも普通に結構いたしな、人数。
でもそれでもなんか難しいな。
設計運用と開発が分かれてるっていうのもちょっと面白いね、それで言うと。
確かにね。
まあその仕様部分は結構シビアに決めなきゃいけないとか、
専門性が求められるみたいな部分はあるのかもね。
これね、ようやっとる。
第3回がすごい楽しみです、個人的には本当に。
いやー、なんか、結果良くなったのかな。
その辺の話はまだ書いてないよね、多分ね。
次じゃないかな。
まあでも第1回でもその、まあ多分費用削減とか、
あとはその、自社特有のカスタマイズみたいな部分は、
ものすごく達成されるんだろうなとか、
また10人かけてメンテだと、
連携してSaaSの数とかDNSの規模を思うと、
まあOktaと契約するよりは確かに安く済みそうっていう気はする。
直感的には。
まあOktaの価格対決、完全に知ってるわけじゃないからなんとも言うけど。
まあそうね、前に話したかどうかはもう覚えてないけど、
なんか結構必要な仕様とか要件がもう固まっちゃってて、
そんなに動かないから、
一度作った後はめちゃくちゃ開発が必要かっていうと、
どっちかというと運用の方が大事なんだろうね、きっとね。
確かにね、それはそうかも。
確かに。
なんかこういう機能が欲しいですって多分そんなにないというか。
どっちかっていうと可用性の方が圧倒的に大事だろうね。
そうだよね。
確かにね。
あとはなんかそのいろんなもののモニタリングみたいな部分だと、
なんて言ったらいいんだろう、いろいろあれも見たいこれも見たいみたいなのはもしかしたら出てくるかもしれなくて、
その辺はなんか、最初に作ってないんだったらもしかしたら追加で作っていかないといけないかもしれないね。
そうね。
いやー。
まあ面白かったです。
うん。
要やるねっていう感じはあるけど。
要やる。
続編お待ちしてます。
AIフェイク技術の進展
お待ちしてます。
ほい。
じゃあ次。
AIフェイクはここまできた。
自分の顔で褒めしてわかった違和感と恐怖。
はい。
アスキーかけるAIっていうのがあるんですね。
はい。
テンションよ。
まあ一般メディアなんでね。
はい。
今言った通り技術系のアスキー、アスキーってどんな漢字なんだ?
ちょっと普段読まないんでわかんないですけど、
まあ多分テック寄りの、ただ読者は一般向けメディアって感じだと思うんですけど、
記事の内容としては文字通りそのAIフェイクの話について語ってくれていますと、
結構面白いなと思ったのは、
この筆者の方が自分の顔使っていろんな写真作ってみたみたいな感じで、
記事中にバンバン貼っていて、
自分の顔の写真をグロックとかナノバナナとかか、
ナノバナナプロとかに食わせてみて、
例えばこういう写真出力してとか、
またフェイクっぽいもので言うと、別のAIで生成した架空の女性とデートしてる写真を作らせて騙せそうかとか、
また飲み会の写真で若者と飲んでこういうポーズ撮らせるとか忘年会撮らせるみたいなのをいろいろやって、
偽造できそうかとか、
偽造作ってみたものに対して、この辺まだ違和感あるよね。
これは使えそうみたいなのを結構ツラツラと語っていて、
結論結構もう多分騙せちゃうところまでは来てますよねっていう話があって、
記事読んでも個人的には思うものはいくつかあって、
具体で言うと、ぜひ言葉で伝えづらいので見てほしいんですけど、
昔のインスタントカメラで撮った写真とかってフラッシュがバッってなって、
ちょっと照明が変な暗い感じになる特有の感じあると思うんですけど、
そのテイストのリープフェイクの写真が一枚記事にあったって、
これマジで分かんないだろうなってちょっと思ったというか、
そうだね、これ結構、
これは分からないね。
その次も結構分かんねえな。
そこの並びの3枚結構むずいなと思ったわ。
その次の1枚はちょっと分かる。
これは確かに。
言語化できないけどちょっと分かる。
なんか英っぽさがまだちょっとにじみてる。
動画か、動画も作ってて動画はさすがに分かるけど、
でも出来がいいなっていう感じだったな。
あとはその感じリープフェイク結構なところまで生きてますよっていう部分と、
あとはここに対してどうしていくねんみたいな話があると思うんですけど、
そこに対しても国単位で実はいろいろ動きがあるよって話も触れてくれていて、
警察通してのリープフェイクで、
例えば知り合いのセンシティブな写真を生成してばら撒くとかダメですよみたいな、
そういう注意喚起みたいなのがすでに警察から出てるんだけど、
それ以外にも法的に、
法律の方からSNSに違法なリープフェイクは出回らないようにするみたいなところの
協議とかが進んでいるみたいなところもちょっと触れてくれている感じですね。
直近だとちょっと日本でどんぐらい話題になっているかわかんないけど、
海外だとXのグロックでアダルト系とか自動ポルノかなとか、
あの辺が生成できちゃって、
インドが確かとりあえずXブロックするみたいな動きを取ったり、
だいぶ炎上していてXは対策できましたって言って、
でも対策できてないやんけみたいな感じでめちゃくちゃ燃えてたりするんだけど、
そういうものをやっぱりもう日本含め各国なんでしょうね。
多分法律で縛るのかどうかわかんないですけど、
まあまあ過渡期だなっていう部分もちょっとありつつって感じです。
あと最後に一つ、
メディアと日常の認識
なんか結構その一般向けのメディアでこういう話してるようになったんだなっていうのもぼちぼち。
確かにしみしみ思ったって感じですね。
知らないだけでちょこちょこあるんだろうけど。
まあ普通にこれフィード見てて掴んだっていうよりかは、
Googleさんのレコメンドでシュッときて、
おおーってなったって感じだったんで、
まあそんぐらい日常的に出てくる話題にはなったなっていうところ。
うんうん。
思います。
なんか、
うーん、
なんか流し見してるとマジでわかんないよな。
流し見、そうだね。
今さっきの焼き箸のやつ言われと思ったけど、
ディープフェイクって知りながら記事読んでるから、
これとかなんか、
これっていうのはマサイゼリアでお偉いさんが飲んでる写真のセーセーサーってやつがあって、
こんなんないやろって思いながら見たけど、
確かに流し見てみるとこれはもう多分わかんないね。
わかんないよね。
わかんない。
なんかその、我々の今の日常って、
なんていうか、
結構コンテンツ過多というか、
めちゃくちゃこう、
飲み込まされる世の中になってるから、
そういう中でこれがポンって流れてきて、
気づけるかっていうと、
いやー気づけないね。
わかんないね。
気づけないな。
自信がないわ正直。
画像はもう無理な気がする普通に。
一応なんかスカシ、AI判定のスカシとか、
そういう技術とかもあるけど、
悪意ある人は多分もう回避してくるだろうから、
あといちいち判定もやってらんないし。
いやー、
これ、
いやー、
まあ嫌ですね。
嫌というか、
まあ自営が必要な、
この領域の人は、
仕事っていうよりか個人として自営能力が必要気がしますね。
だからさっきのその、
出来の悪いLINEグループ作ってくださいみたいなやつに、
こういう写真が添付される世界線があるかもしれない。
知らないです。
実際動画のディープフェイクで金振り込ませるみたいなのは、
めっちゃ少ないながら実力あるっぽいんで、
気をつけていきましょうって感じですね。
気をつけていきましょう。
はい。
はい。
次。
次は、
ソフトウェアと財務の関係
ソフトウェアと財務。
我々のボス、ヤモティさんの記事ですね。
なんかボスですね。
あの、
ちょっと、
あれかな、
合わせて読みたい記事を貼っとこう。
そもそも多分前段の話として、
いろいろありまして、
福利の経営っていうのが、
年明けてからの記事でまず出てるんですよね。
で、
その続きの話として、
この、
何て言ったらいいんだろうな、
技術的不採とか、
要は財務用語を使った、
ソフトウェアに対するメタファーみたいなものが、
よくある話だと思うんだけれども、
その辺の話を書いてくれてる記事が、
このソフトウェアと財務っていう記事ですね。
読んだけども、
細かい中身は完全に忘れてしまっているんだが、
ソフトウェアをバランスシートに見立てたとき、
こうなるよねみたいな話を書いてくれてる。
で、
別に記事の内容をつらつら話すつもりはなくて、
ぜひ読んでみてくださいっていう感じなんですが、
なんか、
このお決まりのパターンになっちゃってるけど、
どうでした?
そうだね。
手前味噌感はあるけど、
ヤモンティさんのいいところが出てる記事だよね。
出てるよね。
出てる。
そう捉えて、そう整理するんだっていう。
しかも、
ソフトエンジニア目線で見たときに結構解像度高くて、
大げさだなみたいな感じだね。
現実は多分ちょっと、
こんなに綺麗にモデリングができないと思うんだけど、
大枠のモデリングとしては多分直感的には正しい気はしていて、
一つの共通言語として、
このモデリングは普通に役に立つそうっていう気はするね。
今言ってるモデリングを解説しようと思ったら結構、
骨が折れるんで読んでほしいなって感じはするんですけど。
端的に言うと、
負債増えすぎると身動き取れんぞっていう話と、
負債と対照的な、
普通に事業前に進めるための資産として使える、
いわゆる超チープな言葉で言うと、
綺麗なコード、メンテしやすいコードみたいなのがあって、
その割合みたいなのをうまくコントロールしないと、
首が回らんくなるよみたいな。
そういう部分をかなり丁寧に紐解いて、
整理してモデリングしてるっていう感じ、
と思ってくれれば一旦はいいかなっていう感じですね。
この話を受けて、
そもそもなんていうか、
福利の経営の話もそうなんだけど、
我々はTENXという会社でセキュリティをやっているわけですが、
福利のセキュリティってあんのかなって思って、
っていう話を実は山本さんとワンオンワンでこの間してきたんだけど。
そうなんだ。
それ録画して特別会で流してほしいぐらい。
別にそんなどっちかというと、
僕が勉強させてもらった会だったんだけど完全に。
結構面白かったな。
手元に社内のメモが全くない状態で話すから難しいんだけど、
何の話を、どういう話をしたんだっけな。
多分セキュリティも同じ構造があるというか、
この構造に当てはめることができるよなとはまず前提として思っていて、
一方で、
僕らが見てるものって不採として認識されてないものが結構あるよなっていう気はしていて、
そもそもこのバランスシートの右と左が本当に釣り合ってるのかみたいな話とかが
結構個人的には気になったりするんだけど、セキュリティという文脈において。
うん。
あとは何か。
糸光っていうのは。
バランスシートの不採と隼士さんが右側にいるじゃん。
左側に士さんがいるじゃん。
うんうん。
そう。
そうね。
結構むずいな。
結構むずいな。
山本さんが言ってることとしては、
士さんを、その右側の隼士さんを持って新しい価値を生み出していくっていうのが、
この生の福利サイクルだよねっていう話だと僕は聞いて理解していて、
セキュリティってそこを積み上げていく活動だよねっていう話はしてた。
いやー、なんかセキュリティもそうだし、多分インフラストラクチャーとか、
あとは何だろうな、基盤的なところもそうだと思うんだけど、
長いサイクルで見たら、そういう同じ話に収束できそうな気がする。
多分1年とかではあんまり隼士さんから出る利息って多くない気はしていて、
例えば何だろうな、じゃあ今だったらパスキーですか、
新しく事業を立ち上げましょう、認証機能を作りましょう。
ただのIDパスワード認証で、パスワード4桁でもいけますっていう認証機能と、
難しいな、ちょっとあんまりいい例ではないことを自覚しながらしゃべるけど、
パスワード機能と、じゃあパスキーでログインできるって、
フォールバックもいい感じになってるみたいな機能で比べたときに、
公社のほうが僕ら目線は多分隼士さんか不採家でいうと、
隼士さんに近そうに思えるし、ただそれが、
そのときやっといてよかったねって思えるのは結構先になる可能性は高くて、
例えば1年後にユーザーが何か1000人でしたとかだと別に、
そのときにパスキーであろうとIDパスだとあんま変わんないし、
IDパスの状態からパスキーに変えるコストもめっちゃ低いんだけど、
10年後とかに、じゃあユーザー数100万人とかに増したってなると、
あのときやっといて本当によかったよねというか、
そのタイミングでIDパスをパスキーに変えるってなると、
多分運全倍のコストがかかるみたいな感じに思えるから、
なんかその結構利息を受け取れるのはロングタームだよなって気はするのと、
一方で福井のセキュリティというフレーズを一番最初に見たときに思ったのは、
どっちかというとなんか不採は一方でめちゃくちゃ不採の方が、
不採返済の方が早く迫られるようなっていう気もしていて、
なんだろうな、まあでもなんか目につきやすいんだよな、不採としての方が。
そこはすごい自分の中につきやがるんだけど、
やっぱりリスクベースで普段からその仕事をして評価を、物事を評価してっていう部分、
一つの判断軸としてあるから、
だからそのね、これが存在することで、
まあこのリスクがあって放置したら3年後に爆発してもおかしくありませんみたいなもので、
やっぱりなんか不採としては大きく見えるし、
その、まあ爆発したらなんというか、
不採返済、不採返済じゃ済まないというか、
なんていうか、もう飛んじゃってる状態だから、
結構なんか、難しいなっていう、
難しいなっていう。
でもなんか、
なんか、ああいう、うん。
とか思っていて、
まあ一個なんか、モデリングの仕方としてありなのかって思ったのは、
そのソフトウェアの評価の観点としてセキュリティが入り込むとかは、
このモデリングに当てはめる上ではありかもなって気はする。
その順次さんと不採で、さっきのその本当にバランスがどうなのかって話があったけど、
まあ僕もそれはなんか、なんとなく同じ目線で同じことを思えた気はしていて、
その、まあなんか開発メンテナンス運用っていう目線だけで見たときに順次さんであるものが、
セキュリティ観点で見ると、実はその部分、この部分はこういう側面に不採ですよっていうのはあり得る気はしていて、
その観点をきちんと入れ込んであげるみたいなのは、
まあ言うはやすしなんですけど、意外と大事だよなって気はするって感じかな。
セキュリティとリスクの管理
なんか今の話の中で結構難しいな、難しいって個人的に思ってるポイントが2つ出てきてて、
その1つはなんか、この不採の部分のコントロールが僕ら自身であんまりできない側面があるというか、
外的要因によって勝手に不採が膨らむみたいな話があったりするよねーっていうのがまず1つ。
間違いないね。
なんか勝手にバランスが崩れました。
その僕らの営みとは一切関係ないところで勝手にバランスが崩れましたみたいなことによって、
そのなんていうか、山本さんの記事で言うとこの正のふくりサイクル、不のふくりサイクルっていうのがコロコロ入れ替わるっていうのが起こり得るわけじゃん。
そうだねー。
例えばフィッシングが急に入ると2000円で、
だからIDパスじゃダメじゃんって。
セキュリティ観点だと急に不採に。
急に不採に。
急に借金返済させられるみたいな。
でもあれは、それはでもどうだろうな。
別に言い方悪いけど、ちゃんと先を見てるセキュリティに関わる人間であれば、そういう時代になってくるよねっていうのは見えてたと思うから。
でも急にっていうのは確かにそうだね。
セブンペイのあれとかでめちゃくちゃ世の中がそこに注目しだしたっていうのは当然あると思うし。
あとはなんかもう1個難しいなと思ったのが、さっきのパスキーの話で言うと、行って授業を阻害しうるわけじゃん。
そうだね、トイレとか。
最初からパスキー入れとけば、後で苦労しないで済みますよって。
それはそうなんだけど、でもパスキーよくわからんみたいな人たちがそこに参入できない、参加できない、使ってもらえないみたいなのが出てきたりするわけで。
あるいは実装のコストとかも含めてそうだよね。
行ってその授業を阻害しうるっていう側面もあって。
純資産っていう枠で見たときに、やりすぎたときに必ずしも価値を生み出さないっていうバランスの難しさみたいなのが多分セキュリティにはあって。
難しいねって話なんだけど。
個人的にAzure Software Engineerとしての目線が強いけど、一つ目指してる高みみたいなところで言うと、トレードオフは間違いなくある中で、でもそういったセキュリティ以外もめっちゃあるじゃないですか。
綺麗にやるなら分かんないけど、例えばAPIは複数のエンドポイント分にしてとか、バックエンドとAPIの間にBFFがあった方がいいかもとか、今すごい適当なこと言ってますけど、
結構アーキテクチャレベルでこうした方がいいよねとか、もしかしたら言語選定、フレームワーク選定でこうした方がいいよねとか、もっと時間をかけてリサーチした方がいいよねとか、
意思決定と選択肢
いろんなのがあると思うんだけど、でもその中でその時に持ってる資産、選択肢、あとは事業の状況ですね、そういうものから加味して意思決定しなきゃいけなくて、
往々にしてそういうタイミングである種妥協したトレード法を飲んだものが塞いと呼ばれることが多い気はするんですけど、事実そうだと思うし。
ただその中でも返済しやすい形で借金をするみたいなのはできると個人的には思っているし信じていて、かつそこにソフトエンジニアの、
この先ソフトエンジニアの仕事はどうなるかAI文明で分かんないですけど、そこにソフトエンジニアの技術が宿る気がしていて、
例えばさっきのIDパス、パスキーで、パスキー入れた方がいいのはそれそうなんだけど、今矢消しが言ってくれた理由で、最初はじゃあIDパス先にしましょうっていう話をしたときに、
裏側の作り次第で、じゃあパスキーしたい、OTP、2FA入れたいっていう時に入れやすくするみたいなことはできるはずだと思うし、
あとは何だろうな、例えば管理画面、何かの管理画面実装しますっていう時に認可機能を作りたい、認可機能をめっちゃガチガチにやるなら、
いろんな選択肢、SaaSにお金払うだろう、自分たちが作り設計するだろう、いろんな要素ケース吸収しておいて、
DNSの設計みたいにきちんと時間とリソースかけてやるみたいなことがやれればいいんだけど、とりあえず管理者とメンバーだけでやりましょうみたいな、
意思決定をしたときに、それも実装の仕方でめちゃくちゃ未来が変わり得るというか、
例えばそこの意思決定に対して全箇所でif文入れますみたいな話と、めっちゃ素朴なんだけど、この箇所さえ拡張すれば認可モデルをある程度はどうにかこじ開けられるみたいな構造の作りにする、
アーキテクチャにするっていうのは全然違う、同じ結果でも全然違うと思うし、
あとはTiwadaさん何かスライドで見たやつを信じてるんだけど、今言った前車と後車で、前車の方が早いじゃん、前車で実装した方が早いですっていうエンジニアにはあんまなりたくないなって思ってるというか、
ちゃんと実力あれば後車も同じスピードで実装できるでしょって僕は信じてるから、そこの幅はある気はするなって思いましたっていう。
リスク管理と負債
特にセキュリティーの話も入るし、セキュリティー以外のインフラのアーキテクチャの話とかも多分入るし、何が言いたいのかよくわかんないけど、
だからそうだね、ソフトウェアという観点において福利は間違いなくあるし、借金もあるが、借金の仕方に工夫の余地はあるし、その観点の一つとしてセキュリティーは確かに存在するなっていうのが今の立場では結構思うって感じかな、確かに。
まあね、よくするよね、そういう話はね。別に今それやんなくてもいいけど、後でそれを入れられるような、やれるような、やりやすいような形で作っておいてねっていう話は割とよくするような気がするし。
うちのSREチームのメンバーがよくワンウェイな意思決定っていう言葉を使うんだけど、結構個人的には好きで、いかにワンウェイじゃない意思決定をするかというか、
クリーンアーキテクチャっていう本でも書いてあって、僕はめちゃくちゃマジでその通りだと思ってるんですけど、選択肢をいかに潰さずに残しておけるかがアーキテクチャのアーキテクティングにおける結構大事な能力というか、そこはめっちゃ思うんですね。
一方で別の、今プロワークとセキュリティにだいぶ寄った話をしたけど、それ以外の大枠、別の枠としてのセキュリティの話で言うとどうなんだろうな。
でも。
でも全然リスクが別のリスクを生むみたいなのは多分あるよね。リスクマネジメントみたいな考え方で言ったときに。
あるね。
それは割と負のふくりサイクルが効きやすいような気がするし。
あとは結構セキュリティに関しては不細を可視化することさえ難しいから、不細を可視化できただけで結構価値が高い気がするな。
それはめちゃくちゃあるね。
あと結構間にもう1個あるような気がしてて、潜在的に事実上不細なんだけど、まだそれが確定してないみたいな概念があると思うんだよな。
潜在的に不細。
要はソフトウェアのアップデートに追従してないけど、別にまだ脆弱性出てないからいいじゃん。
でも出たときそこに追従するの大変じゃないみたいな話とかさ。
事実上不細なんだけど、まだ確定してない。
これなんか詰めて整理してな。
価値を生むセキュリティ
そうそうそうそう。全然整理できてないまま持ってきちゃったんだけど、
福利のセキュリティっていう、これがアウトプットとして出てくる大和さんすげえなって思ってるんだけど。
突き詰めていくと全部品質の話じゃんってなっちゃうから、
もう全部その品質の枠に収めちゃえばいいんじゃないって一瞬思うんだけど、
そうするとでもセキュリティの話としては超ぼやけてくるから、そうじゃないよなと思うし。
あと1個思ったのは、価値を生み出す装置としてのセキュリティみたいな考え方って、
めちゃくちゃコストのアカウンタビリティがすごく高まる考え方でいいなってちょっと思ったな。
コストのアカウンタビリティが高まるとは。
要はそのコストいるのいらないのって話をするときに、
それはでもこれは新しく価値を生むための投資なんですよっていう説明ができるかどうかっていう観点を持てるじゃん。
この考え方がベースになれば。
それはいいかもね。
結構言うはやすしだと思っていて、
セキュリティやると会社とか事業が良くなるんですよって、
いざというときに何もなくて済むんですよみたいな話とか、
割とすげえ適当なこと言ったけど、すげえうさんくさいこと言ったけど、
そういう話はしがちだと思うんだけど、
価値を生み出す装置としてのその一部としてのセキュリティですよっていう話が、
この枠に当てはめてできるとめちゃくちゃ説得力が出てくるというか、
あるいはこれは負債を減らす活動の一つなんですよっていうのも言いやすいような気がするし、
この共通認識が取れてるとめちゃくちゃ動きやすいなって思うな。
あと価値自体の定義をきちんとやることが大事なんだろうね。
確かに。
会社によって結構変わる気はしていて、
そうだね。
あと時間軸もある気はしていて、
3年後にこういう状態になってるっていうことが、
この会社にとってのセキュリティ施策における価値ですっていうのが、
決まってると結構やりやすい気がするな。
そうですね。
すごい仕事思い出しながら考えてたんだけど、
例えば今弊社がやってるものをふわっと抽象化して話すと、
リスクコントロールできてる状態、会社がリスクコントロールできてる状態を目指しましょうっていうのを、
Nヶ月後をアンカーとして進めていくっていうのが決まってる状態だと、
リスクコントロールするにはリスクを知らなきゃいけないよねっていう。
リスクを知ってる状態でこういうものを回せば、
それが資産になってぐるぐる回すだけでいいですよ。
逆にやらなかったときに、
アンカーしたタイミングでリスクコントロールしたいって言われても、
リスクコントロール、リスク分かりませんだし、
時間が経てばリスクの数みたいなのが負債として膨らむから、
だからこれは早めにやったほうがいいんですよみたいな形で語れるみたいな部分はある気はする。
今はあくまで一つ具体例を挙げたけど、
価値を明文化というか認識を揃えるっていう。
多分ソフトウェアでも、ソフトウェア分かりやすいからあれだけど、
分かりやすいとしても多分ソフトウェアもそういう定義が必要なはずで、
事業上の価値というか売上が上がればいいのか、
そういうわけじゃないよねみたいな話もあると思うし、
そこなんじゃないかという気がしてきた。
そうですね。
いや面白いね、なんかめちゃくちゃカッチリやってみたい気がするが。
そうだね。
ヤモティメソッドと称して整理してみてもいいかもしれない。
ヤモティさん、ヤモティさんモデリングリスペクトして整理したんですって。
なんかヤモトさん、ヤモトさんになんか脅威モデリングをさ、教えたらさ、なんか、
すげえ良くなるんじゃない?いろんなことが。なんか分かんないけど。
クソ雑。クソ雑。感想なんだけど。
雑だな。
まあでもなんか得意そうではある。
得意そうだよね、なんか。
モデリングが上手だよね、基本的に。
なんかすごい難易度の高い中小のなんかデカめのスコープとかでやってほしい。
日本、日本企業を取り巻く脅威をモデリングしてほしいな。
そのレベルか、すごいなそれ。
それはすげえな。
なんかできちゃいそうと思わせる、なんか何か。
まあなんか出てきそうだよね、なんか確かに。
なんか出てきそう。
なんか出てくると思う、きっと。
思いのお味噌してるよな。
はい。
まあ、そんな感じでございまして。
だいぶフワッとしちゃったけど。
ぜひ皆さん読んでください。
いやー、いいね。試行実験として面白い。
ね。
じゃあ、打って代わって軽めの記事をポンポンポンと私から紹介できればなんですけど。
えーっと、そうですね。
あなたが拾ってきたノラ、マーケットスキルズ、セキュリティトラブルを発生させていませんか?
っていう禅の記事ですね。
えー、何さんだ?
あつし中村さんですね。
で、なんかまあ、さらっと紹介できればいいかなって思ってるんですけど。
まあ話としては、最近アンソロピックが標準化したスキルズっていうものがあって。
えー、流行ってますと。
なんか、いつかのMCV出たてを彷彿させるような雰囲気を僕は感じてますが。
えー、スキルズが流行ってますと。
で、スキルズの実態がその、まあこの記事読んでなるほどなって思ったんですけど。
違う、この記事じゃないわ。
この記事じゃないやつ読んでやっと理解したんですけど。
まあその一連の手続きというか、その、例えば。
まあGitHubにここレプリクタって、ここと通信してこういうことしてこういうことをするみたいな。
まあそういうものを定義したものが、まあスキルズっていうめちゃくちゃふわっとした解釈をしてるんですけど。
まあそういうもので。
で、これをその、自分で作ったものとかを、まあ他の人にパッケージみたいに配布するみたいな概念があるんだけど。
この記事で提唱してるのはその、このパッケージを配布する、まあマーケットプレイスみたいなのって今めちゃくちゃ乱立してる状態で。
アンサロピックとかオープンAIの公式のやつあるんだけど、まあそれ以外にもポコポコと生えていますよと。
なんか別の記事を読んだんだと、バーセルの人とかもなんかスキルズ.SHRK、まあ忘れたけど、なんかそういうのを立ち上げたり、まあそうじゃないノラのものもいっぱいあって。
でそのノラのものは危ねえぞっていうのがまざくりとこの記事の話ですね。
で何が危ないかで言うと、まあそもそもスキルズ自体の特性として、まあ今さっき言ったようにいろんな通信とか手続きをかけるので、
悪意のある指示を混ぜ込むとか、まあ悪意のある場所と通信をさせるみたいなことを混ぜ込むことができる。
でこれはもう原理上しょうがないと、そういうもんなんだっていう話とあわせて、そのノラマーケットっていうのは、
例えばそのパッケージを出す人に対しての認証とかその署名みたいな仕組みとか、
いわゆるそのNPMとかPyPyとかまあ他のBGMとかそういうもので担保されているセキュリティ機構とか、
そのパッケージを出している人を信頼できるかどうかっていうのを評価するためのまあいろんな基準っていうのがまだ成熟してないので、
なんでまあノラマーケット危ねえぞっていうのがこの記事の話ですね。
でなんか個人的に勝手に腹打ちというか理解としては、なんかまあスキルズだから危ないって話では、
まあスキルズが危ないって捉え方しなくていいかなっていうのはまあ普通に思っていて、
なんていうか、まあそういうものでしかないからなんていうかもうそれを伝えとしてたぶん受け入れるしかないし、
なんでそう思うと、なんかそのスキルズマーケットはNPMはPyPyと比べて成熟してないっていう、
ブログ中の一言にまあ突き切るかなっていうのは個人的に思いましたって感じですね。
で、なんかあともう一つちょっと思ったのは、別になんかAIだからそうだとは、そうなのかどうかちょっとわかんないけど、
結構その、結構こういうの見ると、なんかベンチャーのプロダクト開発とかだと、
さっきちょっと話したとこですけど、セキュリティのトレードオフで安全じゃない方にあえて倒してリスクを飲むとか、
責任かけ合わせ、いろんなリスクを飲んでとりあえず出すみたいなっていうムーブって全然普通なことだし、
セキュリティの複利的な考え方
まあベタな選択肢でやることも多々にしてあるかなと思うんだけど、なんかこういう結構その、なんだろうな、
まあ流行っているもので、なんかみんながもうバーッと寄ってたかって使うような技術セットに対して、
結構なんかセキュリティ機構があまり効いてないものを出して、便利なもの作ってみんな使ってねみたいな感じで、
そのマーケットとして出すっていう部分はなんか結構こういう社名戦はすげー美味しいんじゃないかなと思ってしまうというか、
これって結構昔から繰り返せてるのかなっていうのはちょっと気になってて、
なんか僕はこの辺落ちするようになって浅いんで、歴史が繰り返されてるのか、やっぱスピードが異常なのかどうなんだろうなっていうのはちょっと思いを外せましたっていう感じですね。
なんかどうなんだろうな、なんかちょっとあんまり、まあ僕自身がめちゃくちゃ趣味でコードを書きますっていうタイプじゃないから何とも言えないんだけど、
例えばNPMとかそういうエコシステムの中でポットでのパッケージがめっちゃ使われるみたいなのって多分あんまないよね、そもそも今の。
今はないと思うけど。
現時点においてでしょ。昔はそうだったかもしれないけど、今は多分そうじゃないじゃん。
だいたいまあ、この辺使うよねっていうのがめちゃくちゃ定まってて、ユースケースもほぼ決まっててみたいな状態になってると思うんだけど、
それを指して成熟していないっていう意味であればそうだろうなとは思う。
でもそうではないじゃん、文中で言われてるものって。
そうね、まあ確かに。
要はみんながバラバラにいろんなものを使うっていう状態だからこそ、今の例明期だからこそのそういう状態が多分あると思っていて、
お決まりのものっていうのが全然決まってない状態で、新しく出てきたものをみんながいろいろ使うみたいな状況だからこそ、
いろんな人がいろんなものを出してるし、いろんなものを出してきたときに、出してたときにいろんな人がそれを使うしっていう状態だからこそちょっと危ないっていう話なんだろうなと思うんだよね。
確かにね。その観点はなかったな。その観点を持つ前は結構勝手に似た世界観なのかなと思ってたんだ。
ワードベルスのプラグインというか、スキルズってどうやって入れるんだろう。
CLIで検索とかできるのかなって思ってたけど、CLIでパパッと検索して入れられるみたいな世界観だとしたら、
こういうのしたいなと思ってパパッとくぐってポンって入れちゃうみたいな感じなんだったら、ワードベルスのプラグイン的なノリなのかなって思ったりしてたけど。
でもNPMのパッケージとかも初心者の動きとかは多分それじゃん。こういうことしたいなと思って調べて出てきたものをとりあえず入れちゃうっていう感じじゃない。
確かにそうかもしんないと言われてみれば。
そうなった時に、お決まりのものが決まってれば大体そこに誘導されると思うんだけど、別にお決まりのものって今ないし、いろんなものが乱立してる状態で。
確かにね。
みんなが使ってるのは、なんとなく自分の界隈でみんなが使ってそうなのはこれだなとかはあるのかもしんないけど、そうは言ってもって感じじゃん、きっと。
そうね、確かにな。そう思うとなんか悩ましいな。
っていう話なのかなって思った。実際どうなるかはわかんないけど、そういう話なのかなって思ったな。
確かにね。すごいそうかもって気持ちになりました。
いやー、はい。
まあでも世界観としては確かにワードプレスのプラグインに近いんじゃない、確かに。
ワードプレスのプラグインでさえ結構、例えばだけどフォームだったら、フォーム作るんだったらこれだよねーとかさ、
お決まりの定番どころがあるじゃん、もうすでに。
中身もようわからんものをとりあえず入れるみたいな状況にはならないというか、なんか今のそのスキルズの状況って多分その、
逆に中身のわからんものが大半というか、この辺だったらまあみんな使ってるし大丈夫だよねーが成立しない世界だと思っていて、まだ。
確かにね。公式マーケットプレス、なんか、いやーこれ触ってみよう。でもなんかハゲトです。
はい、そんな記事でした。
はい、ありがとうございます。
はい、様子見つつって感じですけど、次もさらっとで、個人的には良いニュースかなって感じなんですけど、
SBI証券のお知らせで今後のセキュリティ機能強化のご案内っていうやつですね。
ブログとかニュースっていうよりかはもうお知らせなんですけど、何かっていうと、パスキー設定してる人はパスワードログインを廃止するぞっていう話です。
最新のブラウザセキュリティ
なんで、いいぞ持ってやれっていう。ちなみに僕はSBI証券ちょっと使ってるんで、ありがとうっていう気持ちなんですけど。
で、なんか同じタイミングでマネックス証券も、こっちはねパスキー認証必須化をやっていくみたいで、
なんで、カーブ化操作事件を受けて色々ガイドラインが変わってっていうところから徐々にパスキーデフォルトにしていこうみたいな流れを感じたので、
一つのトレンドとしてちょろっとご紹介という感じです。
なんか前に矢消しが言ってくれてたけど、やっぱパスキー紛失したときに本人確認で、色々とその証券口座を開く過程で住所も知ってるし、
その郵送電話やり取りみたいなのも自然とできるから、その辺がバックアップとして効いてるっていうのも、すんなりイケてる理由なのかなってちょっと思いました。
どうなんだろうね、なんかどっちかっていうと圧力なんじゃないのと思うけど、その業界としてやれっていう。
それは多分ほぼ確定だったよね、なんか。それはそうね。
でもなんかこんな早いと思わなかったんだ、個人的には。
もうちょっとなんか、すごい申し訳ない印象でかったって申し訳ないけど、開発に時間かかるのかなとか思ってたけど、結構頑張ってやってるなっていう感じで。
最初ファイド認証みたいな呼び方だったけど、結局パスキーになったみたいな。
はい、そんな感じです。
はい、ありがとうございます。
次、私ですね。
Agentic Browser Security 2025 Year End Reviews のブログですね。
はい、まあ2025年にブラウザーたくさん出ましたけど、それのリキャップというか比較というか、こんな感じだったよね、こういうリスクあったよね、こういうふうにしていくといいよねみたいな部分をまとめてくれてるっていう感じの記事ですね。
前々回かちょっといつか直近どっかの回で、AIブラウザーどんな感じなんだろうねみたいな話をちょうどしたと思うんですけど、それに対するとてもいいまとめだったんで、さらっと紹介したいなと思っていて。
記事の内容としては、エージェントブラウザー、エージェントが動くようなブラウザーがたくさん出たよねって感じで、記事中では何個ですか、1,2,3,4,5,6,7,8個。
そんな出たんだって感じですけど、2025年、去年の間に8個出ていて。
一方で、それに対する攻撃というか脆弱性みたいなのもたくさん見つかったよねみたいなのも直列でババーッと書いていて、そこに対して各ブラウザーどういう対策を入れてるのかみたいな部分をまとめてるって感じですね。
この対策は結構ざーっと眺めるだけでも面白いかなと思っていて、ちょっと全般読んでらんないんで、全貌が気になる方は記事を読んでほしいんですけど、対策のカテゴリーみたいなところで言うと、
Human in the loopをどうやって入れてるかみたいな部分と、あとコンテキストの分離。コンテキストの分離って言ってるのは例えば、OpenAIのAtlasとかはセッション情報、ログインセッションとか機器みたいなのがない状態。
クロームのプライベートブラウザみたいな感じで動くモードっていうのがあって、それでコンテキスト分離することができますよとか、あとブラウザの開発のときにチーミングがどうやっていくかみたいな部分もカテゴリーとして書いてあったり、またユーザーのプロンプトとかウェブサイトから取られた情報に対して悪意のあるプロンプトがないかどうかみたいなのをどういうふうに判断するかって仕組みが入ってるかみたいな部分。
あとアクセス制限みたいな部分でカテゴリー分けされて整理されてるっていう感じですね。
で、そうだな、なんかこれめっちゃ面白いっていうのがあったわけじゃないですけど、結構今言ったカテゴリーが横軸で縦軸がAgentブラウザで整理されてるんですけど、割とみんなめっちゃ一緒っていうよりかはそれぞれ色々ムラというか色が違うなっていう感じをしていて。
で、Human in the Loopで言うと、例えばChromeのGeminiとかは支払いとかメッセージングとか、また機密サイトへのアクセス確認、もう機密サイトっていうのは何を指すのか分からないですけど、その辺に対してHuman in the Loopが入るのに対して、
コメットとかは検出機によってフラグが付けられたアクションに対して必須ですとか、オープンAIとかはタブが非アクティブな場合は勝手に止まるようになってたり、メールとコーンには必須みたいな感じで結構違うようになってたりとか。
あとはコンテキスト分離みたいなところは、Googleとかはタスク管理のサイトのみに、サイトの中しかエジェントが動けないようにしてますよとか、コメットは何だろうな、ウェブコンテキスト分離、信頼交換の共通、なんかよく分かんないけど、それぞれ色々独自の境界線を切ってその中で出れないようにしてるっていう感じっぽい。
ちょっと英語の方で読まないとなと思うけど、まあでもトラストサウンドで読もうと思う。
翻訳しちゃうと色々あるんですけど。
まあね、いやーこれ、いやー大変だな、なんか、いやー、うん、一個一個どういうモデルでやってるのかみたいなのをこう、なんか気にするのをちょっとやってられんな。
うん、ちゃんと理解してほしい。
早く、早く2つ3つぐらいに収束してほしいって。
結構ちゃんとディープタイプしないとその、ね、このコンテキスト分離とかは結構、各社色々情報出してるんだろうけど。
今後のセキュリティの展望
で、まあ基本的にはもう、その、まあ多層防御で各社頑張ってますよっていうのが、スーパーざっくり言うと実態になっていて。
で、なんか知らなかったんだけど、そのオープンAIのCSOの人がなんか、ブログなのかなんかわかんないけど、まあブログなのか、ブログでその、
もうエージェントブラウザーに関してプロンプトインジョクションへのまあ本質的な対策は現状ないですっていう話を書いたブログが引用されていて。
おおーって思って、まあこっちもちょっと読んだんですけど。
まあ、前話した通りですね、なんか僕はオープンAIのホワイトペーパーか何か寄与したんですけど、結局その悪意のあるものが入り込む任意のものがAIモデルに渡ってくるっていうもの自体はもう、
ソフトウェアモデルとして防げないので、まあ基本的にはもう多層防御でいかに防ぐかっていう部分にまあめちゃくちゃ投資をしてるって感じ。
うん。
なんで、まあまあ、ゆえにこの複雑なマトリックス図で各社いろんな試作をしているし、
まあ2026年はどうなんでしょうね。
まあ、個人的には攻撃が発生するかよりもなんか早んのかみたいな部分の方がちょっと、自分で触ってみた感じが気になってる。
どうでしたか?
まだ全然仲良くなれてないです。いまだに。
だからもうお便りで教えてほしいです。こういう使い方するといいよっていうのはマジで、結構マジで困ってる。
うん。
困ってる。はい。
まあまあそんな記事でした。なんで、
そうですね、今のAIエージェントブラウザ何してんねんみたいな部分をザラッと、サラッと知りたい人にはすごいちょうどいいまとめ記事かなっていう感じですね。
ありがとうございます。
はい。
しかもいつAIブラウザをインストールするんですか?
Chromeに入ったらかな。Chromeがそうなったらやろうかな。
ジェミン・クロームはあれかな、まだ普通の人に降ってこないのかな。
日本に降ってこってきてないのかまだ。
そうかも。
ああそうだね、まだアメリカなんだ。まあそのうち来るでしょう。
うーん、なんかそれで全然遅くないかなって思っちゃうんだよな。
うーん、いやそんな気はする。なんか、うーん、全方法知りたいです。
なんか、何回か言ってる気がするけど、その、なんかもう、その、うーん、いや分からんな。
なんかその、ヨシナに全部やってくれるぐらいの世界観に早くなってほしくて、なんか、どうせそうなるんだったらなんか別にいつ参入しても遅くないよなって思っちゃう。
なるほどね、まあそれは確かに。
傍観、傍観様子見していきましょう。
はい、最後、たどり着いた最後。
えーっと、Bad Vibes Comparing the Secure Coding Capabilities of Popular Coding Agentsっていう、
AIと脆弱性検出の考察
天才っていう、これ多分なんかAIで脆弱なコードを判定するみたいなサービスを提供してる企業の記事ですね。
うん。
で、まあなんかまたAIだなって今思っちゃったんですけど、どういう記事かっていうと、
その、まあAIコーディング、エージェント、まあいろいろ有名度クラウド、クローコード、コパイロット、コーデックスあたり、
まあジェミナイとかもありますけど、まあそういうものに対してバイブリコーディングでコードを書かせてみて、
で、脆弱性がどのくらい入ってたか、その傾向みたいな何かっていう部分をまとめて紹介してる記事ですね。
で、なんかまあちょっとさっき言った通り、このフロゴ紹介を書いてるサービスが脆弱性を見つけるサービスをやってるんで、
ちょっとポジショントークっぽくはあるんで、まあそこに注意しつつ、ではあるんですけど、
結果はおおむね、なんていうか、まあそうなるよねって思いつつ、その傾向みたいなのがちょっと面白いなと思って紹介したくて、
まあ結果としてその脆弱性どれくらい仕込むかは、まあぼちぼち仕込みますよと。
で、まあそりゃそうだろうなって思っているんですけど、はい。
まあどの、多少このエージェントの方が仕込む脆弱性が少ないとかあるけど、まあまあおおむね仕込みますよと。
で、仕込んでる脆弱性の傾向がどんなだったかで言うと、
まず一つとして、仕込まなかった脆弱性みたいなところで言うと、
OWASPトップ10に含まれるようなもののうち機械的に判定しやすいものっていうのは一つもありませんでした。
っていうのが一つあって、具体的にはSQL InjectionとかXSSとかは仕込みませんでしたよと。
で、SQL Injectionとかは、一回しゃべりますけど、Prepared Statementをちゃんと使うとか、
で、XSSはちょっと怪しくて、入力のサニタイズとかを家庭でのサニタイズはしてないけど、
フロントエンドフレームワークを適切にちゃんと使ってたから、まあ脆弱性にはなってないっていう。
だから、JQueryとか使わせたら怪しいのかなとか思ったりしたけど、まあまあまあみたいな感じ。
どうぞ、ツッコミどうぞ。
いや、いいっす。何でもないっす。大丈夫っす。
今のOWASPトップ10何だったかなと思って。
その、後で触れようと思ってたんだけど、直近見た中だとSSRFの対策が甘いとかはあったなと思ってて、書かせて。
SSRF書いてあったかな。なんか回避できなかったやつに。
2021年のOWASPトップ10に入ってんだけど、2025年に入ってないんだよ。
あ、SSRFもね、書いてあるね。回避できなかったやつに書いてあるわ。
そうなんか、IPアドレスって200種類あんねんの気持ちになった。IPアドレスの表記。
厳しいなあ。
意外となんか知らないんだなあって思いながら見てた。
その辺のSSRF機械的に分かんないけど、SSRFもそうだし、逆に実装できなかった、脆弱して作り込んだ部分みたいなところで言うと、
まず一つは認証周りを全然正しく実装できないらしくて、特に要件が複雑になってくと、なればなるほどどんどんできなくなっちゃう。
分かりやすいところだと、他の人のマイページが見えるみたいなところが動いてるんですか。
それはどっちかというと認可かと思うんですけど、とか、またビジネスロジックの脆弱性みたいな部分も割とカジュアルに作り込んでて、
カート機能で注文数マイナスにできちゃうとか、そういうものが入ったりとか、
あとは、その言い方意地悪かなと思うんですけど、そもそも書くべきなのにトライさえしてないセキュリティ機構がいくつかあってよみたいな話も書いてあって、
例えばセキュリティ系のHTTベータをつけるみたいなのは全然やってくれないし、
SSRF対策みたいなのも全然やらない。
2回ぐらいやった形跡あったんだけど、めちゃくちゃ間違ったことをやったりとか、
あとはレートリミットみたいな。レートリミットはさすがにしようじゃねって思ったけど、
まあまあそういうのも吉谷にはやってくれないっていう感じですよと。
で、1つなんか結構そうなんだと思ったのは、こういうViveコーディングとかAIアジェントに指示を出すときに、
こういうプロンプトを混ぜればセキュリティ、セキュアな行動を書けるよみたいな論文とかリファレンスって結構いろいろあるらしくて、
そういうのも、そういうのを元にプロンプトを改善してみるっていうのもやったんだけど、
なんかそれをやっても全然脆弱性の数は減らせなかったっていうことを書いていて、
で、ほんまかいなって思ったけど、実際に使ったプロンプトはGitHubで全部公開されてたんで、
さすがに全部は置いてないんですけど、裏取りはできるので、まあまあ嘘はついてないんだろうなっていう感じですね。
なので、まあなんか、脆弱性作るよねっていうのは個人的にはもうそしたらそうだろうなって思う。
一方で、なんかXSSSKインジュクションとか意外と作んないんだなと思ったり、
なんか内容だけ見てるとやっぱ3年目エンジニア感があるというか、
まあそのぐらいで捉えるのがちょうどいいんだろうなみたいな気持ちで見てましたって感じですね。
ちなみになんかプロンプターには割と、まあ仕様、もうほぼ仕様書みたいなもんなんですけど、
結構かっちり仕様としては書いていて、
まあこの検証だけをもってこの結果を精度するのはちょっとリスキーな思考量ではあるんだけど、
まあまあまあ、現在地点としてはこんなもんかなっていうところとはあんま感覚的にはずれてないかなっていう気持ちです。
SSRFね、IPRですね。
コーディングエージェントの課題
なんか、SSRFの難しさはコード単体で完結しないっていうところもあるのかもしれないけどね。
リクエスト先に何があるのかみたいな話だから、どんな環境で動いててみたいな話も多分あるし、
それによって要件側を結構ハードに決めないとうまく書けないっていう前提がある中で、
このSSRFの話ちょっと全然中身読んでないけど、SSRF難しいみたいな話があったときに何を書かせようとしてたんですかみたいなちょっと気になるね。
うん、確かに。
まあ普通に何か、アクセスURLとか。
そう、Making Generic Solutions Impossibleって書いてあるから、そもそもジェネリックなソリューション無理だよねって話が書いてるよね、多分ね。
そうだね。
だからそこがやっぱ課題だから、よほどカッチリ縛りに行かないといけない。
要はSSRF対策としてこれをやってくださいっていう要件をカッチリ決めに行かないと書いてくれなくて。
エージェント任せは無理なんだろうね。
なんかそう考えると、結構なんか仕事無くなんねえなーってやっぱ思う。
だからなんか書くのがコードから自然言語に変わるだけで、無くなんない気はするな。
でもなんかそのSSRFが何であって、どうやったらそれを防げるのかみたいな、なぜそれがダメなのかみたいな部分は知ってないと、
なんていうか、それを書くっていう脳みそがやっぱ思考が出てこない。
以上はなんか仕事無くなんねえなーって思った。
作り込まれる脆弱性の数はこの時代になってもたぶん減らない。
実はそんな変わんない説あるよね。
全然減らないと思うな、今のところの制度だと。
いやー早く仕事無くしてくれよ、頼むよ。
ほんまやねえ。
AI人とか完璧になったらね、もう脆弱性診断だけいらない世界になるかもしれない。
でもロジックのバグは作り込むだろうな。
相当、なんかその、まあ分かんないね、未来は。
コーディング時点で作り込まないっていうよりかも、コーディングした後にいかにAIでレビューさせるとか、そういう世界になっていくんだろうね。
それがそのコーディング演習のCLIの中で完結するかどうかは全然分かんないけど。
とにかく短いサイクルでチェック機構、チェックする仕組みを回せるっていうところがたぶん一番の利点であって、
あらゆる局面でできるだけ汎用的に処理できるものはとにかく汎用的に処理させる、
汎用的に処理できないものは後続のどこかのステップでチェックが入るっていうのを何か愚直にやっていくしかない気がするね。
それこそSSRFとか、SSRFとかも別にブラックボックスだったり、あるいはホワイトボックスでレビューさせるっていうのをやろうとすればたぶん見つけてくれると思うんだよ。
AIがね。
見つけられないと作れないはたぶんイコールじゃないから、見つけはしてくると思うんだよな。
確かに。仕事をなくしていこう。
結局なんかじゃあその、なんて言ったらいいんだろうな。難しいね。難しい。難しい。非常に難しい。
ジェネリックな解決策がないものに関してはやっぱりAIに渡す要件とか仕様をかっちり書くしかないって話になっちゃうんだけど、
じゃあそれを書くのが人間である以上はやっぱり人がそこを把握してないといけないっていうのはあって。
変わんないね。
あんまなんて言ったらいいんだろうな。そこに対してのアプローチって非常に難しいというか、現実的に不可能だと思っていて。
結構無理ゲーじゃない?
人間に求めるのは無理だろうね。
結構酷だよね。
酷とは思わないけど、ソフトエンジニアとしての競争優位性になるぐらいの特殊スキルではある気はする。
そういうイメージが結構あって、SSRFなんて当たり前じゃん、知っとけよみたいな。そうは思わないのよね。思わないし思えないみたいな。
仕事は無くならないし。
2026年、いやどうなんだろうな。
もうちょっと楽にしてほしいけどな。
バイコーディングだろうとそうじゃなかろうと一緒だからな、その話は。
あとはもっと難しいな。外から見てエクスプロイタブルかどうかみたいなところを全部渡して判定させるとか、そういう方向に行ったりするのかな。
もうキリがないからアウトプットの量も増えます。それに従って作り込まれる脆弱性も増えますみたいな時に。
もう完全にエージェントが裏で動いていて、レッドジームみたいな活動をずっとしてるっていう状態で、外からエクスプロイタブルだったら何か教えてくれるとかね。
外からに限らずで、一定の権限を持った中の人みたいな前提でそういうのをやってもいいと思うし。
確かにね。何ならその辺はもうGoogleとかやってそうだよな普通に。
やってそうだよね。使い方次第で全然楽になる時代になったなとは思うんだけど。
一方でその使い方の模索自体に結構疲れてる気がするな。
ハンドル手放してよろしくどうぞでは全然ないよね。
それはそこはもう避けては通れないんじゃないかな。
未来のセキュリティの展望
そんな気がした。
読まなくてもいいかなって気がしますけど。
久々にたくさん読んでとてもホクホクですわ。ホクホクでございます。
メールなど滅んでしまえばいいわ結構。パンチラインだったな。
10年後に残ってそうだよな。
10年後にmcpサーバーはないかもしんないけど10年後にメールは絶対あるよな。
そうだね。あると思う。
面白いもんだぜ。
そんな感じで今日もいろいろ読んできたんでまた来週も頑張りましょうか。
うっす。
大丈夫ですか。
大丈夫です。
AIブラウザのいい使い方お待ちしております。
私はこう使ってますを教えてくれてもいいよね。
それが欲しい。
ここのリスナーの私はこう使ってますが知りたい。
よくわからない記事とかがいっぱい引っかかっちゃうみたいな話があったと思うんだけど。
ちょっと前の話の時に。
生の人間の声聞きたいです。
ぜひお願いします。
じゃあ皆さん来週もお楽しみにしててください。
おやすみなさい。
おやすみなさい。
