1. resize.fm
  2. #8 アプリやサービスのプライ..
2021-01-01 33:00

#8 アプリやサービスのプライバシー

Smoozで話題になった問題を中心に、アプリやサービスの開発・提供者としてプライバシー・ポリシーや個人情報の扱いについて、どう考えた方が良いのかについて話しました。

📝ShowNote:https://resize.fm/ep/8-app-service-privacy

00:00
[音楽]
こんにちは出口です
こんにちは本山です
Besides.FMは
本山と出口が最近気になっているサービスや
デザイントピックスを取り上げて
のんびり話すPodcastです
よろしくお願いします
よろしくお願いします
明けましておめでとうございます
おめでとうございます
2021年も引き続き、のんびり続けようと思うので、よろしくお願いしますという感じなんですけれども、
まずはちょっとお便り…お便りっていうのかね?
お便り?
Twitterに、はい、リサイズヘムについてちょっとつゆあえていただいていて、
ちょっとそれ紹介しようかなと思っているんですが、
お、なんと。お便りが届いたんですね。
前回、出口君のホームレスワーケーションの話が2回にわたって話していたわけですけれども、それに対して、
はまさきさんですかね、HMSKさんがちょっと反応していただいて、ツイートを読ませていただくと、
「業者に怒ることなく列島を漂えていて、すごい。会社辞める前にマンションを解約してしまって、トランクルームに物を入れて、2週間くらい東京で
泊まり歩いたの大変だった記憶しかないと
なるほど
めちゃくちゃ怒ってましたけどね内心は
怒った?
怒ったもんね内心はね
内心は怒りますよ
まあね
まあねでも半分はやりたくてやってたので
まあいいチャンスかなと思って
立て寄ってましたね
やっぱ大変なのかな
でも、やっぱり泊まり先とか、ホテルでやるってのは大変じゃないですか、直前になって予約とか。
まあね。
あんまり、くつろげない感じになっちゃうと大変かもしれないですね。
そうかも。
僕もちょっとビジネスホテルでずっとワーケーションやるのは大変かなって思いますね。
まあ、そうかもね。
なんか、気分的に。
なんか、家感ないもんね。
うん、そうっすよね。椅子とかね。
そうっすね。
僕もあれだもんなあの札幌にワーケーションに行きましたけれどほとんど airbnb で過ごして
ちょっとホテルで過ごすみたいな感じだったからずっとホテルだったら使えるかもしれないな ではありそう
ということでまぁ ツイートありがとうございますありがたい
今後ももし何かありましたらあのお答えしますのでぜひぜひお気軽に 振り上げていただければ
#リサイズFMでつくべていただければと
お答え求められてるのかってなりますけどね
どんどん取り上げていくので ありがたいですね
03:00
今年一発目の話なんですけど
若干 一発目からこの話題重すぎんじゃないの?っていう気もしているんですが
年末に若干色々と話題になった部分とか
年末に限らず若干今年の終わりにかけてというか
割といくつかプライバシーとか
それらの辺のアプリとかサービスのプライバシーの話が
割といくつか話題になったことがありまして
ちょっとぜひこれは僕自身も
やっぱりサービスを作ったりとか
運営したりとかすることがよくある人間なので
ちょっとこれはさすがにそういう仕事をしている人間として取り上げた方がいいんじゃないかっていうか
単純に興味もあるというか関心もあったので
ちょっとそれについて話そうかなと思っているんですが
まずは、Smoothというブラウザーアプリの話が、年末、正確には12月17日に確か記事がアップされたんですね。
Smoothに対するプライバシー的な部分を批判というか指摘している記事。
っていうのが、これなんて読むのか僕はよくわかんないんですけど、
リルアイフォン、リル、ベルアイフォンみたいなというブログ記事が、
まあ、Smoothの情報について書いてるんですけれども、これ読みました?
一通りは、どういうことがあったのかは読みましたね。
まあ、僕はそんな使ってなかったので全然知らなかったんですけど、
これなんか使ったりしてました?
いや、存在は知ってましたけど、使ってなかったです。
僕も存在は知ってたんだけど、全然使ってない感じでしたね。
最初は、便利なブラウザーアプリみたいな感じで、
立ち位置で、確か4、5年、3、4年前からリリースされたなって記憶はあって、
でなんか気づいたらねなんかポイント活動、ポイントをこうポイカツみたいな用途で使われてるとか
あとなんかグランブルーでしたっけ?なんかソシャゲの学校率的にできるような機能が入ってるとか
あ、そうなんだ
そういう方向で進化してたらしいんですよね
あ、それは僕全然知らなかったな
なんかポイカツも全然僕知らなくてなんか記事読んで知ったんですよね
だからまあ割とそういう界隈で使われているブラウザっていう立ち位置みたいですね今
なるほどね
06:00
なんか今回指摘された話、途中でマラサンとかも絡んできていて
割といくつかの問題点みたいなのが指摘されていたりするんですけど
一旦今回僕らで話すのは どちらかというとプライバシーの関係の話をしていこうかなと思っていて
もう一個マラさんがしている脆弱性のセキュリティー的な部分の話っていうのもあるんだけど
ちょっとそこは切り分けてもいいのかなと思っていて どっちかというとアプリとかサービスのプライバシーの問題として
どういうことがあるっていうのを ちょっと話そうかなと思ってるんですけど
そもそもの部分を若干軽く話しておくと
いくつかブログ記事で 問題点になりそうな部分が指摘されていて
例えば設定操作・閲覧情報が ユーザーID、デバイスIDとともに
アスツール社のサーバーへ送信されているとか
検索窓に入力した文字が
検索ボタンを押さなくても
畜一、畜一、アスツール社のサーバーへ送信されていたりとか
あとは、ウェブのコンテンツ情報も見ている
閲覧しているウェブのコンテンツ情報も
アスツール社のサーバーに送信されているっていうような
しかも、それが認証が必要なウェブページであってもとか
これが一番やばいって言われてましたね
全て送ってるみたいな感じでしたね
それも結構やばそうな感じは確かにあって
でさらにそれに加えて
その送信はまあいろいろ送信されてるんですけど情報が
止めることができないという
まあこれは半分バグみたいなところも若干あるような気もしていて
一応サービス医療データの提供設定をオフにするっていう設定はあるんだけれども
設定オフにしても普通に閲覧情報が
AS2RuShareのサーバーに送信され続けるみたいな
とかプライベートモードにしても送信され続けるみたいな
そんな感じだったみたいですね
確かにこれはさすがにやばそうだなっていう感じで
これだけ読むとだいぶヤバイし
あとプライバシーポリシーに書かれていることも
もう完全になんかすごい自由に使ってOKな感じにしてるっていうか
うんうんうん そうですね
まあでも一応プライバシーポリシーとして提示しているっていうことになると
まあユーザーもそれを同意して使っているってことになるから
まあなんとも言えないけど
まあ 結構 やっぱり でも サービス提供者としては さすがに ちょっと オフにできないとか その辺は なんか 尊重されてないので
まず そうだなっていう感じは 最初 印象として受けましたね
うん そうですね
09:02
明示的 既得してるものを 関連記事を出すための あれですよね
ML用のサーバーみたいなところに その既得ページの HTMLの中身 コンテンツを送ったりとかしてたっていうふうに 書いてありましたね
おすすめのページみたいなのを、今見ている、そのウェブページに、関連しているものとかを出すために、おすすめのページっていうのを出してるんだけど、
たぶん、それのために何か送っているんじゃないかっていう話でしたね。実際どうかはわかんないけど。
で、なんかさっきもちょっと話がありましたけど、最近はそれがポイカツとなんか連携して、ユーザーを収集、なんかいい感じに収集しながら、そういうデータをいっぱい集めてるっていうような、まあ若干批判めいた部分?
ポイカツもその辺の利用データを提供の設定をオフにしちゃいけないとか
指定した検索エンジン、これ多分広告に関するGoogleの検索エンジンを使うという話だと思うんですけど
アカウントを作らなきゃいけないとか
そういうのがポイカツの条件にあって、より加速させてんじゃないかっていう、これは半分疑惑みたいな話ですけど
まあでもこの辺確かに問題としてこれは完全に問題としてあったんだけれども そのその後
一応スチール社がそれに対するどうしていきますよっていう表明というか公式な発表をしましたよね
それはね結構あのちゃんとしているんじゃないかなと思ったんだよね 具体的なアクションも書かれていて
実際に指摘された部分は間違っていたっていう部分だとか、うまくできていなかったっていう部分は修正しますっていうのを
真摯にやっているっていう印象かな。
うん。まあ広報の対応としては真摯にやってますっていう感じですよね。
本当かどういう意図かは分からないけど。
基本的には しかも対応も割と早くて
さっきも言いましたけど 記事自体が17日に出て
多分その日中には 多分普通に認知して対応するっていう話を
17日中に表明しているんですよね 公式のブログで
で、具体的なアクションを出して、20日にはその修正版をリリースしているっていう、割とスピード感ある感じで修正も出していて、
その辺に関してはすごく良かったんじゃないかなと僕は思っていたんですよね。
まあでもこれって確か一時帯、最初にブログで指摘されて内容への対応ですよね。第一回目の。
12:07
その続報があって、どちらかというとそっちの方がプライバシー的にはやばそうな内容があり、
まあ結局そこへの対応はせずにサービス終了になったんですよね。確か、時系列的に。
それがさっきのBasic認証でも ウェブサイトの情報コンテンツをぶっこ抜いて
サーバーに送っているっていう部分は 結果的に対応せずに
Smooth側が終了します サービスを終了しますっていうことで
一応サーバー側は止まってるらしいっていうのが 書かれてきた気がしますね それで
厳密に言うと、ベーシック認証に限らず、あらゆる認証が入ったページのタイトルと本文を抜き出してサーバに送ってたって話です。
そうね。
どういう意図で最終的に辞めることになったのかっていうのはわかんなかったけれども、
多分辞めずにちゃんと修正して続けていくっていうのを全然難しくはなかったかなとは思ったっていうのが僕の感想ですね。
まあでもどこでマネタイズして…まあでも確かにその本当に指摘されているその秘匿されたデータの本文とタイトルも含めて
サーバーに送ってた意図が、マルコメンド出すだけ、おすすめページを出すだけであれば、そこは修正できますよね。
そうですね。
でまあそれがビジネス的に結構大きな割合なのかどうかとか、それ次第だと思うんだけど
なんかそんな気もしないから、なんか本当に情報を第三者に売ったりしているとかそういうのがなければ
普通に続けられたんじゃないかなっていう気もしていて、まあどういう理由で辞めたのか分からないので、なんとも言えないところなんですけど
まあなんか最近、まあ他でもいろいろね、iOS のApple のアプリプライバシーみたいな話もあって
プライバシーポリシーをどうやって書くかっていうのは、なんか僕も自分で書いたりすることがたまにあるので、考えることはあるんですけど、
まあ結構いくつかポイントがあるかなと思っていて、
プライバシー情報を取得する場合、それを、じゃあ、何を取得するのかっていう部分と、具体的にね、
それをどういう目的で使用するのかっていう どういう形で取得するのかっていうのを
明示的にしなきゃいけないかなと思っていて 例えば 確か記事でも書かれていたんですけれども
Google Analytics のためにこういう情報を取得して こういうふうに使いますみたいなのを
15:05
サービス、このために使うっていうことに書くとか、ミックスパネルのためにとか
この情報は取るけどアプリ内で処理しますみたいなところも、すごい細かく書くと多分そういうこともできたりとか
この機能を提供するためにこの情報を取るとかっていうのを
書こうと思えば結構いっぱい書けて
その辺をちゃんとわかりやすく 書いていくっていうのが一つ重要なことですよね。
たぶんプライバシーポリシー周りで。
まあそこって結構、僕特に仕事でB2BでSARSの会社にいるんですけど、
いろいろ、どこまで安全側に倒すかっていうのは難しいところはあって、
例えば社内にセキュリティに詳しいホーム担当、技術ホームに詳しい人とかがいると、
周りでいい安倍で規約、運用も考えて、かつ安全性も担保した規約とか、プライバシーポリシーが作れたりすると思うんですよ。
ただそれが社内にいなくて、外部の人とかに依頼した場合、そのポリシーとかの作成をすると、
角に安全側に倒れすぎてて、 逆にこう、なんだろうな、
開発的に個人情報を扱う可能性があるSaaSを追加するときに、
個別のサービス名を書いていると、 毎回そのポリシーの改定が入るわけですよ。
はい。
追加した場合、増減した場合。
それはそれで運用性は下がっちゃうし、
なんかそこのバランスって難しいなって。
まあ確かにね。
技術と法務両方に詳しい人がいないと、 なかなかそのうまくバランス取ること難しくて。
でもなんか、今の世界的な情勢とかっていうのを見ていると、 どっちかっていうと、多分今言ったように、
サービスを新しく追加したってなったら、 その都度プライバシーポリシーを改定していく、
アップデートしていくっていうのが、 今的には、やった方がいいことなのかなっていう感じはすごくしてる。
それはそうだと思う たぶん
だから なんか 曖昧な部分を できるだけなくした方が
基本的には良いのかなっていう まあ たぶん その 開発スピードの部分とかっていう話になるのかもしれないけれども
まあ なんか できるだけ そういう努力をするっていうのは すごく重要になってきている雰囲気はしますね
まあ あとは なんか その
たぶん そういう流れがあって 例えば iOS12でしたっけ
その例えばプライバシーの権限周りは結構強化されたじゃないですか 強化というか厳しくなったじゃないですか
日常報を取るなら その一時的なのか毎回常にとっていいのかっていうのをユーザーに求めるじゃないですか
18:05
まあ多分それもそういう文脈に乗ってると思うんですけど まあでも果たしてあれをユーザーが見て適切に人通り設定できているのかっていうのはまたなんか怪しいなとは思うんです
まあそうですね。あとなんか、まあこう、それをプライバシーボリシーをちゃんと書いていくってのも重要なんですけど、
さっき言ったように、そのユーザーに対してじゃあ事前にどこまで、なんか明示的に説明するのかみたいな部分もあるかなって僕思っていて。
そうね。
なんか出しすぎても使いづらくなっていくわけじゃないですか、その分。
そうね。
なんか、なんかいろいろこれも取りますよ、これも取りますよっていうのがどんどん説明が入ってきちゃって。
うん。
うっとしいなーみたいな感じになって なんかこう、利用体験との引き換えみたいなところがあるかなーみたいな
結構最近の mac os とか あの例えば zoom 使うなら画面収録の権限をくださいとか
あーありますね
音声の権限とか まあ、給地設定しなきゃいけないじゃないですか
だから必ずしも安全にすべて倒すことが
てかなんだろうな 全てのユーザーがコントローラブルな状態にすることが
正しいのかっていうとなんかそれもまた疑問だなって iOS とか Mac の変更を見ていると思いますね
まあなんか僕としてまぁ今回のやつも含めて どういう風にしていくべきなのかなみたいなこうなんとなくの結論みたいなのを
なんとなく持ってて、その利用体験とかの部分も
すごい重要な部分だけはある程度きちんと教えつつも
もちろんね、真摯にサービスを作っていれば、悪さしないつもりで作っていれば、その辺は
アラートみたいに出さなくてもいいと思うんですよね
うんうんうん
出し方ね
なので一応出し方、あとわかりやすくするっていうのもすごく重要かなと思って
あーそうですね
なんかこう、なんていうんだろう、すごいわーっていっぱい書かれてて、誰も読まないよみたいなやつはやっぱり結局よくないかなと思っていて
うん
結果的にね
あとなんか副作用がわかんない書き方が多いなと思って
例えばiOSの位置情報を一時的に取らせるか、ずっと取らせるかっていうアラート出るじゃないですか。
ダイアログ。あれ、なんかそれをやったことによってこのアプリがどうなるのかっていうのが、なんかわかんなかったりすることが多くて。
それはあるね。
だからもう完全に常にGPS一億を取らないと使い物にならないアプリもあるじゃないですか
21:03
なんだけどそれがわかんないからユーザーからしてみると
だからその利便性とのトレードオフができないっていうか
そこは確かに難しいですよね
なんか iOS 14 で確か写真のライブラリーの どこまで撮っていいかみたいなやつも
結構大きなアップデートでみんな ワーワー言いながら対応してたと思うんですけど
あれもなんか全ての写真にアクセスできてもいいか
それとも一部選択してアクセスできるものを 提供するのかっていうので
なかなか一部のやつを選んじゃうと、その言っとけはいいんだけど、そのあとまたやりづらくなるみたいなところがあって、
みんな全てを選んでほしいっていう、願いみたいなのを書いてましたよね。
で、そのためにウォークスルーに、この権限の認証はこっちを押してくださいとか追加されるわけじゃないですか。
なんか不毛だなぁって思っちゃいますね
何のためにやってんだっけって
なんか不毛な感じは確かに
まあでもApple側の意図も何となく理解はできてるんですけど
もちろんね、ユーザーがそのコントロールできるっていう
権限を持つことはすごくいいことだと思うんですけど
なんかね、全てのユーザーがね
賢く判断できるわけじゃないから
そうね
2000年代に、個人サービスというか、いろいろウェブでみんなサービス作るみたいな時期あったじゃないですか。
おー、はいはいはい。
なんかいろんなちっちゃいよくわかんないサービスを。
ありましたね。
Twitterもどきみたいなものとか。
あった。
そういうのあったじゃないですか。
それはそれで全然楽しかったんですけど、でも、あの時代とはだいぶ大きく変わってきているっていうのを、
あの時代を知っているおじさんたちも ちゃんと認識してやっていかないといけないなっていう感じは僕はしていて
あの感覚でやっていくとなんかもうボロクソになるみたいな こう
まあでも今もねなんか普通にセキュリティの なんかこれセキュリティホールありますよみたいな個人サービスがつく
なんか個人が適当に適当にっていうとあれですけど 作ったサービスに対して
セキュリティホールの指摘が入って、みたいなのたまにありますけどね、今でも。
結構なんか、いた業界にもよるのかなって気がしますけどね。
僕とか、今人材系なので、その辺はすごくシビアなんですよね。
ああ、まあそうですよね。もろ個人情報ですもんね。
うん、だから別に自分たちのことも、自分たちだけで判断することが正しいとも思ってないから、
24:00
結構外部の知り合いの専門家に入ってもらったりとかしてるんですよね。アドバイザーみたいな感じで。
だけど、そういうところを知らない人たちが、ちょっとピボっとして、
「そういう個人情報を扱う風になりました」とかになってくると、
なんかそのシビアさがわかんないっていうか、 勘どころがわかんなかったりもするんだろうなっていう気はしてて、
なんかこのSmoothはそんな感じを受けました。
ブラウだってその個人情報をすごく扱うシビアなものだと思うんですけど、
なんかその辺が悪意なしに考慮できてない部分がたくさんあったんだろうな、 あったんじゃないかなっていう気が。
いや、まあなんかちょっとさすがに考慮が足りてなさすぎたなっていう印象はありましたけどね
そう、なんか本当にアクやるならもっとなんかうまくやるだろうって思う気がしていて
それもあるし
なんかね、それこそファーベイの問題とかTikTokが疑われてる問題とかまあ色々あるじゃないですか
まあなんか奥の中でさっきもちょっと言いかけた結論的な話をすると
まず当たり前ですけど、とりあえず何かに使えるかもみたいな感じで、取れるだけ取っておくみたいな考え方は、基本的にはダメ、当たり前なんだけど、
基本的にはダメで、必要な時に、必要なタイミングでちゃんと、これは取らなきゃいけないっていうので、個人情報を取るような実装にするとか、
あとなんか結構重要なのが取得したデータを
サーバーとかサードパーティーとかに
外部に送信しなくてもそのアプリ内でうまく処理して
機能を提供できないかとか
結構そういうのも重要だったりするんですよね
なんか要はその情報自体が他の情報に紐づいて
個人情報になったりしないかとか
そういうのも重要だったりするんですよね
そうですよね
MLだったら最近だとサーバーに送らず
オンデバイスでやるとかね そういうSDKも増えてますよね
あとなんかさっき言ったような 全ての個人情報をプライバシーポリシーに書く内容として
何を取得して 何の目的で取得して どういうふうに利用するかっていうのを
明確に答えられるようにしておくとか
で 結構ね 僕難しいのかな 難しいっていうか 結構実は大変みたいな
他の人も実なんか言ったりしてることがあるんですけど
例えばサードパーティのものを使ったりとか、誰かが作ったライブラリを使って、自分の知らないところで実はこれ個人情報に当たるって部分を外部に送信してるっていうケースも多分あるんですよね。
開発者が知らず知らずのうちに。
ノート。ノートが一回それに近しいことをやってましたよね。IPアドレス。
ああ、そうですね
HTMLに埋めてたっていう話
いや、あれも確かにノートは明言は別にしてないですけど
27:02
その周辺の観測情報だと
レイルスの有名なユーザー認証のライブラリを使っていて
それが暗黙的に収集する情報を
開発者が知らずにHTMLに出力しちゃってたっていう
ああ、なるほどね
うん でも結構そういうのもあるかなと思うんですよね
だからそのプライバシーポリシーにちゃんと書けっていうのは重要なんだけど
そもそもなんかそれを知らない知らないところで取られてて書けてなかったみたいな部分とか
特にGoogle AnalyticsとかあとMixpanelとかねそういうコード解析系のツールはそういうのありますよね
こんなの撮ってたのみたいな
まあ さすがに Google Analytics とか Mixpanel とかになると
明らかに個人情報に当たる部分とかもあったりするので
なんかその Mixpanel 側とかがちゃんとそういう
さらにこうプライワシーポリシー的な部分があったりとか
まあユーザー削除機能があったりとか
まあいろいろ用意してたりするんでね
まあそこが サービス側としてはここに送っているってことが
ちゃんと明示できれば ある程度信用はできるかなっていう感じになるかなと思いますけど
だからさ、だからっていうか、あとはあれですね、さっきも言ったように、個人情報の送信はするっていうのはあれなんですけど、
それをユーザーが操作できるようにしておく、例えば、送信しないような選択肢を与えるとか、あとは削除できるっていうところですよね、そのログとかを。
その辺もさらに重要になるのかな。
そうですね
あとはサービス利用をするながらでどういうふうにわかりやすく簡単に説明していくかっていう部分のバランスというか
その辺が僕の中でやっぱりこう気をつけるべきポイントなのかなっていうふうには今回の騒動で感じましたけどね
そうですね
その、やっぱさっきの話の、戻っちゃいますけど、
わかりやすくメリットとデメリットをちゃんと伝えるっていうところね。
プライバシーではないけど、プッシュ通知とかも近いものがあるなと思ってて、
メールとか、DMのメールとかもそうだけど、
なんかこう、ゼガヒでもプッシュ通知を送るパーミッションを取ろうとするアプリ、
多いじゃないですか、結構。
なんかわかんないけど、最初いきなり通知送りますよってやつね。
そうそう、っていうのもあるし、あとはなんだろうな。
サービスを使う上で必要なお知らせは受け取りたいけど、
キャンペーン的なお知らせは受け取りたくないとか、
まああって、だから全社を許可したいがために、プッシュスーツ許可すると、
DMのキャンペーン的なお知らせもガンガンプチプチされてくるみたいな
30:04
その辺もさっきのデメリットデメリットの話じゃないけど
もうちょっと何がユーザが得られるんだっけっていうのが
説明してからパーティションを取るのが真摯な対応なんだろうなとは思います
まあもちろんね、それがやりづらいっていうビジネス的な事情もわかるけど。
結構なんかその辺ってやっぱデザイナーとか、まあPMの力量は現れるなっていう気がしてて。
なんかビジネス側の要求丸呑みして実装するだけだと、どうしてもそのエビルなパーミッション取り方になってくるし。
他にもプライバシー周りの動きというか そういうのが話したいことちょっといっぱいあるんですけれども
今回はちょっと長くなってしまったので スムーズの話で一旦止めて またちょっと機会があるときに
僕も結構勉強を最近してて 例えばGDPRの話だとか その辺の部分も
僕はまだ完全に読み切れていないんですけど、ドキュメント。
そういうのも含めてまたちょっと話そうかなと思っています。
ということで、今回はSmoothの話で終わっちゃいますけれども、
Smoothのことがあって、わーわー言うだけではなくて、
実際どうしていこうっていうのを考えられればいいかなと思うので、
そういうきっかけになればいいかなっていうふうには僕は思っていますね。
そんなところで今回は終わりなんですけれども
今回割と1月1日元旦から重めのやつを取り扱ったんですけど
ちょっと僕がどうしても話したいっていうふうに出口くんに行って
ちょっとお願いしたんですけれどもね
まあ結構いろいろ他の人もね意見とかあるかなと思うので
今回はまさきさんにいただいたみたいにちょっと #resizefm にね
ツイッターやってますので #resizefm でツイッターにつぶやいてもらえれば
今回みたいに番組内で 配信内で取り上げてみたりとか
直接ご連絡したりとかするかもしれない
ご連絡というか 返信というか
するかもしれないので ぜひぜひつぶやいてみてください
#resizefm は毎週金曜日に配信していますので
よかったらチェックしてみてください Spotify iTunes Google Podcast などなど あと youtube で配信しています
ということで 今回はここまで
また次回お会いしましょうさよなら
(エンディング)
33:00

コメント

スクロール