00:00
こんばんは、Replay.fm、第83回です。
こんばんは、83回。
83回。
なんか、この収録の30分前からすごい喉が調子悪いです。
終わったじゃん。お疲れ様でした。
ここでちょっと出し切って、もう明日はマスクをして過ごすかもしれない。
お疲れ様でした。
何だろうな、全然。
まあ、そうですね、はい。
それ以上の情報は何もないんですけど。
はい。
やりますかね。夜も遅くなってるんで。
はい、じゃあ。
はい、お便りですね。
Googleフォーム内社Xのポスト、
ハッシュタグ、Replay.fmでお待ちしております、というわけで。
ハッシュタグ見てんの?
一応見てるよ。
最近サボってるけど、公開したときにハッシュタグつけてポストして、
そのときについでに見るみたいなことして。
まあでもね、ほとんどないですね。
でもたまに感想とかコメントくれてる人いるよ。
このお便り始めてからはないんだけど。
お便り始めたせいで、読まれるんだと思って、もしかしたらみんな投稿しなくなったのかな。
なるほどね、逆に。
まあまあ。
別にお便りっぽくなかったら読まないだけなんで。
そうだね。
今まで始めてから、別に何か10投稿もない気がする。
そもそも投稿自体で嫌なんですけど。
まあ何ですよ、実は見てますっていう感じで。
やっていければという感じです。
はい。じゃあ本日も上から少し少なめでガスがいきましょうか。
先週いっぱい読んでもらったから読むか。
GitHub ActionsのセキュリティとStep Securityの製品群
10 Layers Deep. How Step Security Stops Team PCPs3B Suppressing Attack on GitHub Actions
というステップセキュリティのブログですね、これは。
ちょっと中身読んでるんだけど、なんかあれなのかな。
なんかあれだね、ステップセキュリティの製品群を紹介してくれてる記事なのかな、きっと。
おおむねそう思っていただければいいかなという感じです。
ちょっとめっちゃ理解できてる自信はないけど、
基本的にはアクションズのランナーというかめちゃくちゃ安全なランナーとそのランナーに対する
いろんなオブザベリティとか検知とか、またない者もプロアクティブにブロックするみたいな。
そういう機能を盛りだくさんの製品を多分彼ら売っていて、
今言ったような機能をいろいろ割と丁寧に紹介してるって感じですね。
なので、マリシアスっぽいものがあったらブロックするよとか、ブロックの手前の通知とかもするよとか、
後からいろいろログ取れるよとか、本当にいろいろなんでもって感じですね。
ハーデンドランナーはこの間ちょっと触ってみましたね。
そうなんだ。
パブリックレポだったら無料なんで、おすすめです。
触ってみよう。
基本たぶんEBPFベースで、匠ランナーに近いような感じなんだけど、
匠ランナーはあれはあれじゃん、なんだっけ、ギターフォーステッドランナーじゃなくて、
くくりで言うとセルフフォーステッドランナーとして、
セルフフォーステッドじゃないんだけど別に、ランナー自体を匠のやつに変えるっていう形だけど、
ステップセキュリティのハーデンドランナーは、アクションズのステップとして1個突っ込んでおけば、
自動でやってくれるっていう仕組みになってる。
ランナーはギターフォーステッドランナーで大丈夫。
なんか、アクアセキュリティも似たようなやつをコンセプトとしてアクションで書いて出してたんだけど、実は。
たぶんそれが製品化されてるような感じなのかな、きっとね。
なるほどね。いいっすね。使ってみよう。
あとなんか1個気になって、それをしゃべるためだけに紹介するボタンを押したんだけど、なんだっけ、どこかな。
ちょっと見出し忘れちゃったんだけど、
いろんなサードパーティーアクションズで、
みんな使ってるけど実はメンテ止まってるとか、
あとはタグ、セキュリティ方面でちゃんと作られてない部分。
何でしょうね、中で端固定してないとか、そういうものっていっぱいあったり、
またみんなが使いたいRLユースケースみたいなのがあるんだけど、
それをまとめてステップセキュリティで、
今言ったやつで言うと、メンテされてないやつはクローンして継続メンテしてたりとか、
よく使うようなものは作ってますよ。
かつステップセキュリティ性なんで、
何でしょうね、ハッシュでピンするだの、いろんな侵害とかノットに対する態勢があるから、
ぜひ使ってねみたいなことが書いてあって、これ知らなかったんですごいいいなって思いましたね。
Notionリンク貼ったんだけど、ちゃんとみたいなの。
こういうのもそうなんだけど、アクションズの外部評価みたいなのをやるツールって多分ないよね、今。
あるサードパーティーアクションズってことだよね。
そうそう。
見かけないね、知らない。
サードパーティーアクションズに限らずなんだけど、
OSSのGitHubアクションズとか含めたリポジトリの設定の評価というか、
それはないね、完全に。
ブランチとかタグのルールセットって、あれって外からどれくらいわかるのかな。
見えないもんだと思うけどね、見えてもやだしなと思うし。
あんまり普段見ない画面で、今こういう設定になってますような画面があるんだよね。
ちょっとどうやったらたどり着けるのかわかんないんだけど、
実際にブロックされたときに多分、
GitプッシュしたときにリモートのところにURLとか出るさ、
実際にそこブロックされたときに多分出るやつがあって、
そこの画面が多分パブリックとか見てないんだけど、
いやーわかんねえな、どうなんだろうな。
何せよこのリポジトリはタグ書き換えオッケーですよ、無条件オッケーですよとか、
そういうのが外形的にわかるとありがたいよねって常々思ってて。
でも一方でターゲットアドベンチャー使えちゃうから、
ちょっと悩ましい部分であるけど。
基地の知ってる挙動だと、
リポジトリのアドミンとかメンテイン権限なくてもライト権限あるとルールセットのページ、
直打ちするとルールセットが見えるとかはあった気はする。
だから完全に外部のコントリビューター、
何の権限もないコントリビューターがどれぐらい見えるかはあんま調べたことないな。
GitHubね、結構あるよね、そういうの。
API直たたきすると設定できる設定値とか。
アプリケーション的には許可してるんだけど、
UI全部実装していらんないからっていう部分なんだろうね、おそらく。
API見るのがいいかもね。
ハーデンのランナーもパブリックな形で使えるし、
このアクション相撲、
まずメンテ止まってるやつ使うのはマジでやめた方がいいって個人的には思ってて、
結局迷って紹介記事に出なかったんだけど、
GizmoとかActionLintとかGHLintって、
アクションワークフローを静的解析評価する系のルールって、
全部マチマチというか、これにあってこっちにはないとか、
全部にこれはあるみたいな感じで、
こっちのこれとあっちのこれが欲しいときに、
両方つかなきゃいけないみたいなのがだるいから、
自分で作りましたみたいな記事を、
Koukiさんっていう方が前で書いてたんだけど、
そのルール眺めたときに、
どういう基準なのかな、
アーカイブされてるサードパティアクションズはブロックするみたいなやつがあって、
普通にめっちゃいいなって思ってて。
はいはいはい。
アーカイブされてても動くのか、確かにパブリックアーカイブだったら。
ちなみにもう対応したんで言えますけど、
弊社のやつもめっちゃ掃除した、それで。
偉いな。
1回全部バーって、
2年前ぐらいにバーって見て、
これ3年前に止まってんじゃんとか、
これも落ちされてるわっていうやつは全部非推奨にして、
機械的にブロックするっていうところまでやってないから、
やれたほうがいいよねとか、
このステップセキュリティのやつ使えば、
ステップセキュリティがやーめたって言わない限りは、
メンテしてくれるっていう部分は、
割と信頼してもいいかもとかちょっと思ったりって感じだな。
なんか放置されたOSS巻き取りムーブメントみたいなのあんのかな直近。
アクションズもそうだけど、
なんかOSSもどこの会社だっけな、忘れちゃったな。
なんかセキュリティ系の企業が、チェーンカードが。
チェーンカードはね、やつだね確か。
割となんていうか、
業界全体のレガシーの割合が増えてきたからかな。
ちょっと分かんないですけど。
すごい量だけどこれ、
さすがになんか自動でやってんのかな。
でもそれこそさ。
自分たちが使いたいものをめっちゃやってるとかなんかもしれんけどな。
そうかもね。
あとこれあれだね。
さっき言った評価的なやつが見れるね。
本当だ。
ブランチプロテクションとかはマキシマラのほうが。
でもなんかこのサードパーティーに対してブランチプロテクション評価してるから、
外部から分かるものもあるっちゃうのかな。
なんだろうね。
なんかルールセットは今適当なリポジトリに対して、
なんかAPI系で投げてみたけど、
取れなかったから。
サインドコミットとかセキュアパブリッシングは空欄になってるから、
これは多分取れないんだね。
マニュアルコードレビュー。
コードレビューとかもそうだね。
なんかちょうどいいリポジトリないかな。
ソータ1,2,3,4の何がいいかな。
何でもいいよ。
ブランチルールセットが入ってるやつない?
じゃあこれで。
リポジトリ名だけ教えてくればいい。
入れてたはず。
そうだね、ルールセット入れてるわ。
ちょっと待って、なんかノットファウンドになっちゃった。
なんで?
いや、いい、合ってる合ってる。
俺が間違えてる。
俺が間違えてる。
取れるね。
取れるわ。
取れる?そうなんだ。
じゃあルールセットはパブリックなんだな。
知らなかったな。
俺のあれとか見てみれば。
これ。
なるほどね。
これは結構ガチガチに入れてるんだけど。
取れる。
全部は見えてないかもな、これ。
取れてるデータがさ。
全部は取れてないね、やっぱり。
バイパスアクターが見えてないよね。
見えてない。
バイパスアクターがいるので、私のルールセットは。
権限によってカラーも変えてるパターンだね。
面白い。
ごめんごめん、そういう意味じゃない。
ルールセットが実際にはいるんだけど、
バイパスアクターが実際にはいるんだけど、
自分のリポジトリに対してもそこは見えてない。
そうなの。
でもそれは多分取る方法あると思うな。
あるよね。
APIが別なんじゃないかな。
APIが別なのかな、ちょっと。
だってならテラフォームで
出し入れることを知ってるから。
バイパスアクター。
何か条件があったはず。
Adminないとかないと取れないとか、
多分そういう条件があったはず。
だから何にしても外部からは取れないだろうね。
リポーズ、オーナー、レポロールス、ブランチス、
メインとかかな。
これ何だ?
ゲットルールスフォーブランチスでしょ。
何でこれがこんなにレスポンスになるのかわかんないな。
何だこれ。
コミッター、URL、オーサー、
いやーちょっと気になっちゃうね。
確かに何かのライト権限がないとダメなんだよ。
ゲットルールスフォーブランチス、メイン、コミッター。
こうか。
ちょっと待って、これでいいんじゃない?
これ強いね。
これで結構いろんなもの見えるわ。
リクライドチェックとかもこれで見られる。
リクライドチェックこれで見られる。
リクライドレビュアーズも見える。
バイパスアクターがこの中に入っているかというと、
バイパスアクターは入っていない。
でもバイパスアクターが、
ゲットアリポジトリ、
ゲットアリポジトリルールセットっていうのがいるんだ。
また別に。
ルールセットIDを渡すと、
ルールセッツで取ってくるじゃん。
でもルールセッツでもリターンフィールドあるから、
やっぱなんか権限なくて。
でも同じものを使い回しているだけなんじゃないかな。
どういうこと?
その型をさ。
入っているんだ。
入っているわ、本当だ。
それクリエイトリポジトリルールセットでしょ。
そうそう、これだこれだ。
バイパスアクタープロパティーズオンリリターンで、
ユーザーメイキング対PIリクエストハズライトアクセス
トゥルールセットだから。
ルールセットの編集権限ないとね。
やっぱ取れない。
思い出したかもしれない。
ルールセッツこれで取ると、
バイパスアクターは、
そうだね確かに見えてないわ。
ソータンあればバイパスアクターいるのか知らんけど、
確かに。
確かにいるはずなんだけど。
プロパティー自体がまるっといないね。
たまにこういうプロパティーがある。
バイパスリストを設定しているから。
じゃあちょっと試してみるか。
これ本当に見えない。
まあでも結構これでさ、
やっぱりあれだね、
外から見て、
プロテクトプランチが
あるよねとかが
分かるようになってるんだね。
そうだね。
見えなかったらバイパスアクター。
俺は見えてるからそこはサブんだね。
なるほどね。
一個詳しくなりましたね。
ギター部にどんどん詳しくなる。
ステップセキュリティありがとう。
勉強の機会をくれて。
そんな感じですか。
おすすめです。
無料版は使ってみればいいし、
有料版は会社の
お財布と相談してください。
値段知らんけど高そうではあるよね。
結構する。
ハーデンドランナーとかは結構するなってイメージがあったな。
他はちょっとちゃんと見てないけど。
やってること相当リッチだからな。
コントリビューター単位の課金だね。
そのモデルが結構きついなって思ってて。
その点、匠ランナーは
ランナー単位の課金だから
相対的にはめっちゃお安く見える。
規模感によってもちょっと変わってくるかもね。
あとEBPFなので
やっぱりUbuntu Slimでは動かなくて
Ubuntu LatestとかのVMベースのやつじゃないと
動かなかったね。
その辺は正直多分
ランナーレベルで制御できれば
コンテナベースのランナーも多分作れるはずだから
調べた限り。
だからタクミランナーとかは
そういう拡張性も将来的にあるのかもね。
もしかしたら。
なるほどね。
と思いながら見ています。
ありがとうございます。
じゃあ次いきますか。
メルカリのClaude Codeセキュリティ戦略とAIの脆弱性発見能力
メルカリのクロードコードセキュリティ設定の
組織配布戦略。
株式会社メルカリの赤松さんの
クロードコードミートアップ東京
2026の発表スライドですね。
ちょっと
スライド自体そんなに長くないんで
読んでくれっていう
感じではあるんだけど
メルカリの場合は非エンジニアも
活用を止めずに
クロードコード使ってるよっていう話が
まずあるらしくて
割と安全に
エンジニアよりも
安全に対する感度みたいなのって
どうしても
養うのが難しいよねみたいなのが
前提としてあって
っていう中でこういうことやってるよって
話をしてくれてるスライドですね。
一言で言うと
クロードコードのセッティングスジェイソン
を組織配布してて
サンドボックスとかも
ガチガチにしてっていうようなことを
やってるらしいんで
それをMDMで使って
一斉に展開してて
っていう感じらしいです。
いやーよくやるよね。
面白いね。
これなんかさ
クロードのサブスクリプションだと
クロードチームとかだと
組織設定から
設定配布ができるような設定があるんだけど
めちゃくちゃ便利じゃん。
あれとは違うのかな。いまいち分かんなくて。
なんでMDMをあえて使ってるのか
分かんない。
分かんないね。
もしかしたら結構ライトユーザーがいるのが
印象的だなって個人的に思ってて
非エンジニアもカバーせなあかんみたいな。
その非エンジニアは
何だろう
重量課金でちょろっと使うとか
なんかそのプランが違う
とかなのかな。もしかし
チームプランで配布できる
コンフィグの種類が
この人はこれっていうのが制御できないんだったら
自前でやるしかないよね。
このスライドの感じだと2種類。
エンジニア自分で判断できる人向けと
非エンジニア向け
っていう超ざっくり言うと
分けられてるから。
なかなか
ようやっとるなあ。
なんかちょっと思ったんだけど
このサンドボックスとかさ
ガチガチにサンドボックスって使ったことある?
まだないっす。
ちょっと使ってみてほしいんだけど。
結構癖は強いなと思っていて。
割とその
この設定をガチガチにした
クロードコード本当にいるかっていうのは
思っちゃったな。
これで果たして活用してると言えるのか
って思った。
なんか
結構非エンジニアは
半年1年前
くらいからちょっと
印象変わってて
最初の頃は
こいつにハンドル渡すのきついな
みたいな気持ちあったけど
最近は割と
まあでも小説あるんだよなあ
なんか使い込んでる人はやっぱ
ファイルカッティングケースとか起こってる人もいるし
わかんないんだけど
自分が使ってる感じはまあまあそんな
これでめちゃくちゃインシデントに
一発アウト繋がるような挙動を
モデル化する感じはあんまない
気はしてるし
オートアプローブ
全部アプローブと
全部
承認の真ん中みたいなやつも
出してきたし
よくなってくるんだろうなって一方で
ただやっぱなんかその人間の
ソフトエンジニアの注意力に
依存してる部分はある気はするから
なんかその前提で言うと結構
非エンジニアに
クロードコード渡すの
普通に怖いよなっていう感覚は
まだあるかなって気は
してるかな
そうねそうなんだよね
なんか俺は人のリポジトリに勝手に
使用を立てに行った時点であんまり信用しないことにしてる
なんか
なんでそうなるんだろうな
分かんない
俺も体験したいんだよな
分かんないけど
いやーでもなんかな
人のって言ってもババロットの
うちのSREのマネージャー
ババロットのリポジトリだったんで別にいいんだけど
勝手に一周立てに行って
ふざけんなよって
なんで勝手に一周立てに行ったのって
ごめんなのだって言ってた
それで言うとJHECコマンドは
オータープルーブにしてないな
あー
俺もJHEC
クリエイト
クリエイトはね
アランにしてたのかな
ちょっと忘れてたな
みんなの
セッティングスジェイソンを持ち寄って
なんかこっそり見せ合うから
やりてんだよな
どこまで許してるって
オーサムクロードコードとかで調べたら結構
流行ってるやつは見れるよ
やっぱ流行ってるやつはめちゃくちゃ
アロリスト多いなと
なんか
どうせ誰も見ないだろう精神で
僕のセッティングスジェイソン貼っときますね
いいね
GitHubで公開してくる
僕のはね
結構でも
どうなんだろう
どうすか
ちょっと
セッティングスジェイソン評価おじさんとして
Git
このGitアスタリスクとかは
怖くてできてないんだよね
Gitはいったなと思ってて
ほんと
Git
全然GitDiffとかログとかも
そういう単位でかなり安全に
通してやってるから
でもだいぶ
たずな渡してる感
あるけどな
個人的には
ノードとか
このプログラムも全部渡してるんだね
kubectlとか
怖いけどな
仕事でkubectlは
なんで入ってんだ
これ俺入れた覚えないな
まずいですよ
入れた覚えないので消しておきます
だからGH issue
アスタリスクになってるから
クリエイトはしちゃうんだね
でもそれで言うと
GH issue createが
下のほうでアスクになってるから
あーなるほどね
そっかこっちで上書きされるんだ
kubectlなんで入ってんだ
俺普段kubectl使うことないから
マジで意味不明なんだけど
GH pr match
確かにね
ask deny
kubectlは消そう
消した
こんなもんだよねって気はするね
こうなっていくよねって感じかな
まあそうね
まあでもさ
どこまで行ってもやっぱ
人間の忠実に
やっちゃわないように
って話もあるけど
やっちゃったことに気づきさえできない
みたいな可能性もあるから
知識がないと
クロードコードを
手渡すんだったら
サンドボックスは触ってないんで
わかんないですけど
セッティング配布したくなる気持ちもわかるかな
しかもそれがメルカリくらいの規模だと
なおさら
いやー
まあようやっとな
という話でした
ありがとうございます
いやー
どうなるんだろうね
今のところ僕はこれで
ギリ
許せるくらいの
挙動をしてます僕のクロードコードは
まあなんか
基本的に賢くなってくるんだろうな
って勝手に期待してるからあんまり
そうだね
だからなんか
ガードレールの方が大事だよなって気はするな
まあそうね
どこまで行ってもたぶんモデルが
100%自己らない
っていうのがやっぱ言えないから可能性はだいぶ
下がってきてるとはいえ
あれじゃないですか
流行りのハーネスエンジニアみたいな
言葉が一人歩みしてるらしいけど
確かに
あれ
エフォートレベルも俺これ戻したと思うんだけどな
積んだもん叱ってきてください
いや違うんだよ
どっちかというと.
filesを会
社PCとプライベートのPCで両方でい
じっくり回してるからコ
ンフリクトしたときのあれ
をミスってんだよねき
っと
なるほどね
これエフォートレベルハイにしておくとね
ちょっと僕の
あれだと一瞬で
レートリミットになっちゃうので
ダメなんですよね
いや
気になる方は
見てもらうと分かるんだけど
ちょっとサンドボックスは
僕は実は使ってなくて
記事書こうと思ってまだ書きかけなんだけど
結論
サンドボックスは使うのを一旦
諦めてるっていう
状態なんですよね
いろいろなんか
難しさはあるなって思いながらやってますね
はい
そのうちよくなる
すごい
楽観的
じゃあ次も
クロード君の話題ですか
えー
クロードミソスなのかなこれ
読み方分かんないんだよね
多分ミソスかな
なんて読むんですか
これは
まあ多分そんな感じですね
preparing for a world
where AI finds and exploits
vulnerabilities faster than ever
という
WiDSの記事ですね
ごめんこれ読んでないや
そう私読みました
これに触れてる記事が多すぎて
もう一個これピックしようと思って
持ってきたんですけど
クロードミソスっていう
サイバーセキュリティかな
ユースケスとしては
脆弱性を見つけるっていうところに
めちゃくちゃ特化したモデルを
開発しましたよって話があって
で
ただこれ開発したんだけど
今はその
公開されてなくて特定のパートナー
11企業ぐらいだったかな
11企業プラスアルファ
名前が出てるのが11企業で
プラス10社20社ぐらいも
公開はしてないけど提供してる
みたいな感じの状態になってますと
でなんで公開してないかっていうと
脆弱性見つける能力が
ちょっと高すぎるぜっていうのが
あって
で
実際に
公式の発表と70個ぐらいゼロで
見つけて
中には
えっと
何だろうな
10年20年とかだったかな
何年単位誰も見つけられなかった
昔仕込まれた脆弱性
よくみんなが知ってるOSSの
脆弱性を見つけたよみたいな
ものもあったりして
これを公開して攻撃者側が触れちゃうと
結構まずいようにっていうので一旦
特定のパートナーに絞るっていうのと
今後も基本
広く公開することはなさそう
ないって言い切ってはないのかな
でも広く公開する予定はないです
っていうスタンスを取ってるモデル
になってますっていう感じですね
でこれ
このWizの記事では
今言ったような紹介と
それ踏まえて
脆弱性を見つける
スピードCVEが発行される
スピードがこれからどんどん
加速していくことが
予想されるよねって話と
加速するのは
いいことというか
そこの数字だけ見たらいいことなんだけど
一方でそれに対して
パッチの修正が追いつくんだっけとか
また
またその
次々と出てくるパッチ
パッチが出てくるスピードも加速すると仮定する
になったら
それを使っているユーザー側の負担って
今以上に大きくなるよね
じゃあそれって追いつけるんだっけみたいな
考えたときに
普通に考えるときついから
何か備えていかなきゃねみたいな
部分がすごくふわっと言っちゃうけど
そういうようなことが書いてある
でも本当はそんなふわっとした論調かな
っていう感じ
同じような記事
マジで各セキュリティベンダーが
出してて会社の
ベンダーによっては
もうぶっちゃけ対応するのは
不可能なんで
何か考えなきゃまずいですよとか
自動修正していかなきゃ
ダメですよとか
また
いろいろ各社あるのと
あと一方で個人的にちょっと
確かになって思ったのは
二つ
公式に対する
疑問みたいなのが
見かけて
なるほどなって思ったのがあって
一つは70個ぐらい見つけたって言ったけど
よく中身見たら
40個ぐらい人間が
なんか噛んでるじゃんみたいな感じで
ただ
見つけることに特化してるっていうよりかは
見つけたものに対して
エクスプロイト書く能力が高すぎるみたいな
部分があるみたいな
話があって
そこを考えると確かに
公開するリスクはあるよねみたいな
でも人間がちょっとまだ噛んでるというか
AIが完全に自律して70個見つけたわけじゃなくね
っていう指摘がありそうなのと
指摘というか疑問なのかな
がありそうなのと
あともう一つは
めっちゃ確かにって思ったんだけど
公開する予定ないって言ってるけど
絶対公開されるよみたいなこと
言ってる某メディアがあって
なぜならチャットGPTも一番最初は
同じ理由で公開しなかった
けど結局公開してるやん
みたいな
仮にクロードがやらなくても
他の会社がやるかもしれないし
それこそ来週の記事に入ってるけど
オープンAIが多分意識してるんだけど
似たようなやつを
作ってるっていうのを
今週かな
今週なんで今4月16日に収録してるんですけど
多分
4月15、14、13ぐらいの記事で
見たんですけど
なんでまあまあ
いずれは公開されちゃうんだろうなって
気持ちで見なきゃいけないかもな
っていうのとまた
パッチというかCVが出るスピードが
上がっていくっていうのは
もしかしたらそんなになきゃいけないのかな
と思うと結構
従来の
一個一個レビューして
レビューを自動化とかAIで取り味して
コツコツ直すっていうスタイルが
あんま
限界を迎えるんじゃないか
という気はしていて
そこに
なんかマインドシフト
そうだねなんかその
パラダイムシフトが求められるかもな
っていうのをちょっとぼんやり
いろんな記事を読みながら思いましたって感じ
ですかね
まあなんか普通にマーケティングの
一環なんじゃないのってちょっと
割と冷ややかな目でずっと見てたな
そうねそういう側面もあるかもね
あと公開されてないからね
なんともでもなんかそのパートナーに
指定されてるでもパートナーってなんか
例えばAWSとかGoogleとかみんながよく知るような
企業がいっぱい入ってるんだけど
その
AWS側とかからは
記事出たりしてて
まあこれはいいもんだみたいなこと言ってる
部分もあれば
なんだっけなどっか
どっかのベンダーが
クロードの差事加減で
使える企業使えない企業
差が出るのは
業界的にどうなんじゃいみたいなこと言ってる
企業とかもあって
みたいな気持ちもあったりしますけど
まあなんとも言えないですね
マーケティングの一環というか
打ち出し方としてそこの部分は
あるだろうね
実態はどうあれ
まあそんな感じです
まあエクスプロイトを書く能力
はどうなんでしょうね
ちょっと全然わかんない
なんかめっちゃ
過度に怯える必要もないし
過度に楽観し
しすぎんでもよくないぐらい
スタンスがいいかもな今は
なんか
わかんないね
何もわかんねえわ
なんかすごい前にGeminiとかも似たようなやつやって
クローズドでやってます
とかOpenAIもだいぶ前からやってたりするし
あんま表に出てこないから
ほんとなんともわかんないよね
また結局その
ストロピックの記事読んだけど
やっぱそのOSSに対しての
っていう部分があるから
クロードコードの
セキュリティレビューとかで
見てくれるらしい
部分の複雑なアドミノジックに対する
レビューとかそういう部分とかとは
軸足は違いそうかもな
そんな感じです
気になる方は公式のやつを
1個読むのがいいんじゃないかなと思います
いつの紹介しましたか
じゃあ
次いきますか
脆弱性対応と依存管理、認可制御の実装パターン
次いきますか
次は脆弱性対応と
ミニマムリリースエイジを両立しながら
依存管理をクリーンに保つ
パーク社の
テックブログですね
なんかさらっと
いいかなと思ってて
その脆弱性修正と
ミニマムリリースエイジってジレンマがあるよね
みたいな話とか
あとオーバーライズするとだるいよね
みたいな話とオーバーライズするのもだるいし
してからそれを同期するのもだるいよね
そのいつ外すかみたいなのも判断するのも
むずいよねみたいな話を書いてくれてて
割となんていうか現場の
悩みそのものが表現されてて
ドロックサイン
俺の好きなタイプの記事だなと思ったので
ビックリしてますっていう感じですね
割とみんな多分
この手の悩みを
なんて言ったらいいんだろうな
愚直に対応しようとしてるところの会社の
人は特に抱えてるんじゃないかな
と思っていて
そこに対するアプローチの
一例としていい基地だなと思ったので
紹介しようかな
と思いました
これも
ようやってる系かなと思いましたね
ようやってるねえ
偉いねえ
このオーバーライズさ
なんか
うろ覚えというかなんか見かけた
気がするんだけどリモベートが自動で
きれいにしてくれなかったかな
とか思ったんだけど
気のせいかなさすがに調べてるだろうから
記事で研究がないなら
ないんだろうなと思って
見てるんだけど
会ってもよさそうだよね普通に
会ってもよさそう
うーん
まあでも
まあでも
まあ少なくとも
何らか理由があって自作に
そうだね
いやー
こういうところを
逃げずに愚直にやれるか
どうかは結構大事な
分かれ目だよね
なんか私たちも
愚直にやれてる側だと勝手に
思ってますけど
ここまでは真似できないなって思ったな
なんか
正直ここまではちょっとまだ至ってないっていうか
うーん
いやーちょっと
なんか
このコストの方面でもやっぱ
パッケージ
エコシステム
側にちょっとどうにかなってほしいな
って気がするよね
うーん
結構きついよな
はいありがとうございます
かなり具体的に書いてあるんでね
真似したいよって方は読めば真似できる
ぐらいの解像度になってるかな
って思います
はいじゃあ次いきますか引き続き
セキュリティエンジニアはこう見る
開発時に認可制御不良
怪しむべき実装パターン実践
うーん
これも割と
別にまあもう細かく紹介するつもりは
なくて
読み物としてまあおすすめですよっていうので
持ってきてるんだけど
えーと
こうなんて言ったらいいんだろうな
なんかこう
うーんと
あー
まあ難しいな
セキュリティエンジニアはこう見るって書いてある
上でその開発時に認可制御不備を怪しむべき
っていう風に
続いてるからまあ
誰視点なのかは若干あるんだけど
まあでも基本的には多分セキュリティテスター
視点で見た時にその
どういうのが揃ってたらこう
怪しいと思うのかっていうのが
紹介されてるという風に僕は理解していて
うーん
割となんかアンチパターンとして有用だな
と思ったので持ってきてる感じですね
うーん
なんか
バックエンドの実装で
一周ぐらいした人が
読めばまああー全部
はいはいって感じになる
うんうん通って気持ちいいだろうなって思うから
うんうん
あのいい意味でサプライズもないし
そうそうそう
その押さえるところ全部押さえてるかっていう意味では
確かにいいリファレンスだね
まあもしかしたらOWASPのチートシートとかで
なんか似たようなのあるのかもしんないけど
まあ
何にしてでもいい記事だなって思ったので
持ってきてます
パターン1を一個だけ紹介すると
そのIDに対してテナント間をまたいで
連番が設定されているっていうのがあって
連番で設定されてるってことは
テナント間でアクセスそのユーザーの
まあ
テナント間でそのIDを指定して
なんだかアクセスするとかができるんじゃないか
っていう風にまあ思うよね
みたいな
実際そういうのはあり得るよねっていう
まああるあるだなっていう話なんで
うーん
いやーあるよね
この
診断するが
1年
いや1年は長いななんか2ヶ月ぐらいだけ
OJTしたよマジで
脆弱精神の
ああ
ああ
いろんな現場のいろんなコード見るの
普通に面白そうなんだよな
なんていうか
宝探し考えそう
いやなんかその
自分が実装するときはなんかさすがにもう
ここに書いてるのパターン
うーん
いやでもさなんかその
まあこれよく言うんだけどその
なんていうか
どんだけ気をつけててもやらかしがちというか
その
これ系って結構さ
なんかぼーっとしててうーわやっちまった
みたいなのがたまにある系の
ものが並んでると思っていて
なんか
それぐらいなんか綺麗に書くのって難しいんだよね
まあね
いやなんか
言うはやすしなのかというかやっぱその
そもそもなんか
認可がな
一番最初に一番コストかけて
たぶん作るべきだと
個人的には思うんだけど
でそれがたぶん長く長く
こういうパターンを
いやーではなんか
うーんその認可
とは言ってるけどさ
なんて言ったらいいんだろうこう
抗議の
抗議のっていうかなんか
いわゆるオーソライゼーション
ではなくどっちかというとアクセスコントロールの
話のようなまあでもその両者の違い
になるって言われると困っちゃうんだけど
なんか
いわゆるその
抗議の認可っていう
感じじゃないんだよな
なんか
最初に作り込むべきみたいな話
というよりはなんか
そのあらゆる視点での
このアクセスコントロールみたいなものって
こういろんなところでいろんな形で
実装されるから
一個にまとめておく最初に作り込むみたいな
がそもそもできない領域だと思っていて
うーん
まあなんか作り込む
って言い方がたぶんちょっと
ミスる気がするんだけど作り込むというか
はその作り込めるように
枠を作っておくというか
そのまあパッと
眺めという感じその
意図としてはなんか抗議の認可
に対してその
いやー
逃げんのは
得点これ読めで
逃げんのはすごいダメだ
思ったのはそのオーソライゼーション
アカデミーっていうボーベンダーが出してる
まあwebで読めるやつがあるんですけど
それを会社に輪読したときに
やけ者がね入社する前に輪読したんですけど
めっちゃ思ったこととしては
その
なんだろうな
なんか後でパッチを当てづらい領域な
気はしていて
いやーどうだろうな
これ親子関係があるリソースの設計
とかは
あの
まあ教科書的な言葉で表現しちゃうと
リレーションベースアクセスコントロールみたいな
部分が絡みそうだよねみたいな部分があったときに
でもこれって結構なんか
民家の中では
発展型というかその
アクセスコントロールだよね
その基礎のアクセスコントロール部分の
設計がグズグズだとその親関係なんて
もう到底
吸収できるようなアーキテクチャになってないはず
で
じゃあ吸収できるアーキテクチャになってるにはっていうのを
なんかちゃんと時間が浅い
って考えないと絶対にその
受け入れられる
拡張できるようなものにはならないし
でも
まあまあ不条理というか
いろんな理由でその一番最初に
ここに対してその
ここまで思いを馳せて時間をかける
ってことはなかなかできないできてない
まあ自分もできてこなかった
なんかでも
役人の原則とかと比べたときにさ
どこまでやるべきなのかみたいなの
ちょっと気になっててなんか
結局その親子関係みたいなものを吸収しうる
そのところまで
最初にやるべきなのかみたいなのは
なんか諸説
ある程度するんだけどどうなんだろうね
なんかその
最初に実装しろって言いたいわけじゃなくて
その後から入ってきたときに
あのパッチを当てやすい
状態にしようねっていう話
な気がしていて
パターン10とか
はなんかその逆を言ってる
気がしててパターン10が何かっていうと
権限確認が各エンドポイント
ごとに呼び出される実装みたいなのがあるけど
なんかこれやっちゃうと
ちょっとその
難しいな
等しく認可処理を通すっていう前提が
崩れるから
どこに手を入れようとまずここ直さなきゃね
いやーまあね
なんか言わんとすることはわかるし
なんかその
後でパッチ当てやすいようにしようぜ
まあわかるはわかるけど
なんか
そんなに
その
認可制御とかアクセスコントロールの
仕組みっていうか実装自体が
その
なんていうかこう
何かしらの要件とか
したいことやりたいことにひも付いてくるっていうのは
絶対あるから
そんな汎用的なものをそこに作り込んでおくっていうのは
そもそも結構しんどくないってちょっと思っちゃうんだよな
なんかでも
どうなんだろうね
なんか個人的な超仮説の
なんか補足はめっちゃしたいという
気持ちででもあえてシンプルに話すと
なんかこれだけやっとけばいいって思ってることが
あってその認可って基本的には
誰が何に対して
何をしようとしてるかっていう
その風と
えっと
誰がと
リソースとアクション
アクターリソースアクションか
の3要素が
判定ロジックのインプットとしてあって
アウトプットはまあ
ここは要件によっちゃうけど
基本はあろうかでないか
部分的にあろうかみたいな
とかあると思うんだけど
この3つを
何かしらの形で受け取るようにしようね
っていうのとそれを
漏れなく受け取るようにしようねっていう部分
だけどう抑えるか
あなたが作るアプリケーション
にどう抑えるかを考えるっていう
ところだけでもやれたら
全然違うんじゃないかなって個人的には
思っているって感じ
ではあるんですよね
またそれを切り出すか
切り出さない
分かんない
オーソドックスアカデミーを読んで欲しいんですよ
いろいろ喋りたくなっちゃうんだけど
まあ
言うより安心
とめちゃくちゃ思いながら
喋ってはいるんですけど
難しいのは分かるんだけど
アズバックエンジニアの
自分としては
この難しさから
に立ち向かってこその
まあ
ソフトウェアエンジニアリングだよねって気はしてるんで
あんま逃げたくないな
と思っている感じですね
塩梅はね難しいよね
塩梅は本当に正解ないから
そこは
考えた結果はもう全エンドポイントハードコードです
いいと思うんですよ
でも考えずにやって
とかは
まあできたら
避けたいルートだよねって
思う感じ
そうね
いや
でもね
その考えた結果
各エンドポイントハードコードにしますで
絶対いつか来るんだよ
絶対いつか来ると思うんだよな
やっとギャーしてけばよかったって
なんか
なるのがこの世の道理だと思ってる
自分がいるんだよな
まあわかんないそこはもうビジネスと
要件といろんなことのバランスだと思うんで
でも
またあれですか
AIコーディングもここに変数として入ってくるんで
そうだね
AIが書くんだったらもう
全エンドポイント漏れず
ハードコードできるじゃんみたいな考え方
もしかしたらなくはないかもね
わかんないけど
人間より機械的に
AIが書くんだったら
なんか別にその
なんて言ったらいいんだろう
実装コストがめっちゃ下がる
っていう前提においては
最初から割と複雑なものを作っておいても
いいんじゃないっていう話になるし
そうだね
それもあると思う
またあれかテスト
どこで抑えるかは結構
そこも腕の見せ所ではある
映画入ってくるんだったら
じゃあテストを担保しようで
中身はどうなってももうブラックホックスでいいよ
みたいな世界観になるかもしれないし
面白いね
道具は変わっても本質はあんまり変わってない
というか
興味深い話題ですね
いやーこんだけバッティーしちゃうっていうからね
ちゃんと作ってみたいんだけど
なんか育休期間中に
作ってるバイオコーディングのやつでは
今言ったことを実践しようとしてるんだけど
でもね運用しないとね
2年ぐらい運用した後に
やっぱ答え合わせをしたい気持ちあるから
なんか
俺は永遠に自分が書いたコードを信用できないよ
それで言うと
なるほど
いやー
まあその辺は
なんだろう
哲学的な部分も
ありそうな
思想か
いややるもんなんか
うわこれ忘れてたわみたいな普通にある
なるほどねそういう文脈での信用ね
まあまあそれで言うと
それはそうね
それは確かに
いやー
難しいね
なんかできるだけシンプルにしようぜ
みたいなのは全然
ありかなと思うし
それこそなんか別に
なんていうか
まあ難しいね
必要なところに必要な制御を
入れるっていうのも
それはそれで見通し悪くないと思うから
なんか
いいかなとは思ってるし
うん
いやー
いやー
そんななんかでもさ
気にしてらんないよね
なんか
開発
いやー
いやでもちょっと過激派だな自分は
やっぱ逃げたと思っちゃうな
いやなんか認可じゃなくてもさそうじゃん
例えばデータのバリデーション
とかでさ
そのこのビジネスオブジェクトを
触るときにはこういう判定をしなきゃいけない
みたいなのがあったときに
なんかじゃあそのロジックを
そのビジネスオブジェクト扱う場所全部で
ハードコードするんですかっていやしないでしょみたいな
じゃあなんで認可ではするのって今
なんか自分の中で
自分の中の過激派の自分がちょっと
詰め寄ってきて
だからなんか
なんで認可だけそんな難しく
なっちゃうんだろうね
今言ったその前者の話はさ
その一個で
そのなんていうか
ユーザーストーリーに落とし込み
にくいからでしょ
まあ確かにね
ビジネスロジックかと言われると
だって何々は何々が
できるっていう風に書いてあったらさ
なんか
何々は何々ができないのはさ
もう必然的に落ちてるわけじゃんもうその時点で
そうだね確かにね
確かに
それはそうだね
そこを拾い上げたとしてもなんか難しさは
残る気はするから
まあでもその
まあそうねでも拾い上げてたらさ
何らか実装はされるわけだから
なんかその
ノー実装ですっていうことはないわけで
まあ
ノー実装はもはや土俵に立ってないんで
手直してもらってっていう
あるんだけど
なんかそうだねその
いやどうしたらそのエンドポイントごと
実装から卒業できるんだろうっていう
結構
いや言うはやしちゃうんだよな
エンドポイント
うーん
結局その何て言ったらいいんだろうな
その
何て言ったらいいんだろう
こう難しいのは
その
エンドポイントだから
判断できることをその認可制御の
レイヤーを1枚
手前に設けることによって
何て言うか
無理くりそこで判断しないといけないみたいなのが
起こり得るっていうのが
一つ難しいところなんじゃない
さっきのその
アクターとリソースとアクションみたいな
話
リソースオーナーが
判断するべきだよねっていうところからは
ちょっと離れる気がする
そうだね
リソースを何とみなすかっていうのが
認可って言葉にめちゃくちゃ
内包されちゃってて難しい
でもそれで言うとだから
入れ子になってると思ってて
要は
Quickとかさ
Speedyとかのあれと一緒で
クイックがそうだね
プロトコルが入れ子構造になっていくようなのと
多分一緒で
あらゆるレイヤーで
リソースっていう概念は存在していて
広く
広く見れば
そのエンドポイントが実装されている
サービス自身がリソースだし
そのサービスの中での
エンドポイントの実装みたいなのが
今度はリソースと
リソースとそれ以外
みたいな感じで分かれるみたいな
多分あるから
それを考えると一番最初に考えないと
もう無理なんだよな
無理は言い過ぎだけど
おそらく最初は
かぜみとかでも
このレイヤーが正解って話じゃないけど
どのレイヤーにも
認可の概念はあるよねみたいな
まずAPIにアクセスできるかできないかも
認可じゃないですか例えば
ベーシック認証って
パスワード知ってないとアクセスさせないとか
このトークン持ってないとアクセスさせない
っていう
01の認可もあれば
エンドポイントをリソースとみなして
この
アクターはこのエンドポイントは
404みたいな
あれば
このデータベースのこのテーブルの
このカラムはこのアクターは見れるけど
このアクターは見れない
このアクションはできないみたいな
レイヤーがいっぱいあって
そうだね
それ
そういうふうに
認可っていうものを捉えたときに
なんかやっぱその
じゃあそのデータの
レイヤーでちゃんと
見れるようにしましょうねとか
だからそのhowみたいなのも
多分いろいろあってRDB使ってるんだったら
RDB側の認可のシステムあるから
そことつなげようとか
例えば
思いつきたけどそのSQLクライアント
をラップして
その中でいろいろやってくれるクンを
広く使うようにしましょうとか
いろんなアプローチがあるんだけど
今言ったようなことって最初に考えないとやっぱ
膨らんだ後に
後から考えのきついよなとか
思うな
思うなっていう
これはダメだ
僕の中では無限
堂々巡りしちゃうんだけど
まあでも
別に難しいね
個人的には別に
後からやるのしんどいよね
は完全に同意なんだけど
後からでも払う価値がある
コストだとは思っていて
なんて言ったらいいんだろう
こう
先に考えないといけないよね
に固執しすぎるのもなんかよくないんじゃないかな
という気はしてるな
なんかすごい
ふわっとしたことしか言ってないんだけど
僕の
僕がなりたい
自分はそうではないという
そうであるとは全然言いたいわけじゃないんだけど
僕がなりたいなと思う理想像としては
そこに
最小の時間をかけて
最大限いろんなものを吸収できるものを
とりあえずバッと作って
シップできる
とすごい
いいエンジニアだなって思える感じ
なんかそうね
僕の思想が多分に混ざってます
なんか認可以外もそうだと思ってるから
同じAPI
同じ挙動するものを作るときにも
高度の品質というか
なんか燃えそうな話題ですけど
アーキテクチャーとかさ
ワンウェイな領域を
いかに減らせるかというか
首が回らなく
なりすぎないように
どれだけ同じ時間でできるかは
ソフトエンジニアの
腕の見せ所だと思ってるから
認可もその一要素
と捉えたいな
まあねむずいよね
作るタイミング設計するタイミングでさ
そいつがどれくらいの寿命を
持つのかとか正直わからんしね
まあね
まあそれはそうだけどね
だからそこも
まあそうね
まあまあまあ
なんかコード書きたくなってくるな
AIにコード書かすすぎてさ
マジでコード書いてなくてさ
コード書くか
わかる
あれ書きなよ
オレオレオクトSTS
プロンプト投げたくなるわ書って
おすすめっすね
なんて言ったらいいんだろう
どう伝えたらいいんだろうな
なんか
オレはこうがいいと思うんだけどっていう
その
オクトSTSで言うとこのトラストポリシーの
そのモデルを
ゼロベースで考え直したのね
で
まあだいぶ考えた結果
オクトSTSと似たような要素が
やっぱり入ってきて
あー面白いなーって思いながら
なるほどね
考えられてるなって
あー確かにこういう思考の
その道筋をたどると
確かにあの形になるわなーって思いながら
なんかやってて結構面白かったんで
おすすめです
唯一違うのは僕はレゴで
ルールを書けるようにしてるので
あーいいね
でも
なんかもっと柔軟ななんか
フリーダムなやつを作ろうとしちゃうんだけど
そのいろいろ検討していった結果
なんか少しやっぱり制約が必要で
やっぱ落ち着くんだね
そうそうそう
面白かった
ちょっとやってみてください
あのー
僕がレビューします
こえー
頑張ります
今日ね
これ最後の記事だったんですよ
まあなんか
ちょっとなんとも言えん面白い回でしたね
うん
なんかねピックしなかったけど
いろんな話題があったな今週は
北朝鮮に
10億
10億ドル盗まれた話も
いろいろしたし
あとなんだ
まあでもそれか
顧客情報へのアクセスログは個人データかとか
結構面白かったけどな
これ
特殊事例すぎて
面白かったね
ついでに紹介しちゃおうか
顧客情報アクセスログと個人データの法的解釈
ここまで来た
えーと顧客情報へのアクセスログは
個人データか
東京
広範囲
うんたらかんたら
銀行が保有する
顧客情報へのアクセス履歴が
保有個人データに該当するかが
争われた事例ですよっていうので
いつものITシステム判例メモの記事ですね
はい
結論
えーと
保有個人データに当たらない
っていう判断をしていて
なんか
まあ
面白かったですっていう感じです
経緯とかはもう全部発症るんだけど
その結論としては
えーと
えーとどこ読めばいいんだっけ
あそうそう個人情報であるというためには
その
ん?ちょっと待ってね
えーと
あー
個人情報であるというためには
個人識別性の要件が満たされること
すなわち生存する個人の個人識別情報であって
うんたらかんたらで
他の情報と要因に照合することができ
それにより特定の個人を識別することが
できることとなるもの
えーあとは個人識別法が含まれるものの
いずれかであることが必要で
えーと顧客の特定のその
顧客情報にアクセスする
そのアクセス履歴に関しては
えーと別にこのアクセス履歴を見ても
えーと当該顧客を識別することが
できるものとは言えず
えーと個人識別性の要件を満たすことはないよ
っていう判断をしている
要というのが
なんかたぶん一言で言うとまとめになるんだけど
えーとなんか若干のコメントっていうので
あのこの記事の
あのーえっと筆者の人が
コメントとして入れてくれてるのが
うーんと
しかし全部端緒なんだけど
しかしアクセス履歴単体としてみれば
特定個人を識別できる情報を
含んでいないとしても
どの顧客のえっとCIFっていうのが
なんだっけ
カスタマーインフォメーションファイルだ
そうにアクセスしたのかという履歴が
抽出できるのであれば
少なくとも用意証拠ができるので
アクセス履歴も個人情報に当たるのではないか
という疑問があります
確かになっていう
僕らのその常識で言うと
なんていうか要は
ものすごく大雑把に言えばユーザーIDで
紐付けられるものは全部個人情報だよねっていうのが
個人データを構成する
一部だよねっていうのが
つまり個人情報だよねっていうのが
僕らのある種の常識だと思うんだけど
ごめんなさいなんか法的
用語の使い方が間違ってたらごめんなさいって感じなんだけど
っていうのが僕らの常識だと思うんだけど
なんか
確かになっていうのは思いつつ
一方でそのアクセス履歴単体で
そのなんていうか
個人データは構成しないよねっていうのは
直感には
そうというか
確かにそうだよなっていうので
両方分かるから
うーん気もしゃるっていう風になりましたという
面白い判例でした
面白いね
これは面白かった
なんか
なんでそんなデータ
開示中か
求めたんだろうと思ったけど
訴えた側と訴えられた側
まぁ訴えられた側は
会社なのかな
うん銀行だね
っていうか
訴えた人のパートナーが
その銀行で
勤めててその銀行で
そのパートナーが自分の鉱山のデータを
勝手に見たんじゃないかみたいなので
会示請求したくて
訴えたみたいな経緯らしくて
これ見てすごい
アハ体験というか
それでそんなわけわからないデータ欲しいんだ
うん
面白いよね
裁判を起こすぐらい
相当だなと思ったけど
まぁでも
これきっかけでこんな面白いデータが
個人
個人情報ではない
こういう個人データ該当性は否定された
っていう
反例につながったって感じですね
いやー
面白いよね
このブログ本当に好き
勉強になるめちゃくちゃ
いやー
いろいろありましたね
はい
アクションさ
ソフトサプライチェーンはちょっと落ち着いてますか
そうだね
最近ちょっと落ち着いてるね
その後
どうなんだろうね
どうだろうね
デカいとかやられてないんだろうねニュースになって
ところ
引き続き不安全にではありますね
はい
そんな感じですか
いやー
喉直して来週は頑張ってきて
所存でございます
早く直してください
りゅうかさんが見てる
2ヶ月後ぐらいかな
作るとすぐできるよ
作りたいものが立て込んでいて
毎日コツコツ
プロンプと投げてるんですけど
ちょっと
配信外でするわ
無限に話しちゃうね
じゃあそんな感じで
皆さん次回もお楽しみにしててください
おやすみなさーい
おやすみなさい
