リーダーシップとマネジメントは違う

「良いマネージャーとは」という話をするときに、「良いリーダー（またはリーダーシップ）」の話を混ぜて話されていることがあるが、その２つは本質的に全然別物だという話

open.spotify.com

 

出典は早稲田大学ビジネススクールの杉浦教授のものらしい

2022年振り返り

life log

1月

雪山（北横岳）に登った

 

spacemarketでサウナ付きの自宅を借りてサウナパーティーした

 

2月

家の近くに最高のサウナを見つけてアホほど通う

 

昔作ったアプリを全部イチからpythonで再実装。友人の結婚式で使ってもらう実績解除。

 

退職時の寄せ書きが味気なくて嫌だったので、「声の退職祝い」を作ってプレゼントした。地味にめちゃくちゃ良いサービスだと思う

 

「千年婚姻届」についてビジコンで発表。学生部門として賞をもらったビジコンで、今度は招待講演として発表させてもらった。婚姻届はこちらから購入できます

speakerdeck.com

 

学会発表。仕事の一部が学会で発表された。

 

3月

α7Ⅳ買った。動画をたくさん撮るようになった。やはり写真よりも残る情報量が多いので動画の方が好き

 

mameya kakeruとても良かった。今年は清澄白河に行くことが多かった

 

4月

オフィス移転。コロナ期間をのぞいても6年は毎日通っていた白金台のオフィスだが感慨は意外に無かったな...

 

長野の最高のサウナx2に行ってきた

www.youtube.com

 

5月

鎌倉で指輪を自作し、島根 出雲市役所で自作の千年婚姻届を提出してきた（旅行vlogを年内にupしようとしたらタイムオーバー）

 

6月

雷が鳴るほどの土砂降りのなか、水芭蕉シーズンの尾瀬にいってきた。尾瀬の山小屋にサウナができるらしいのでまたトライしたい

 

新オフィス初出社。夜景が綺麗な六本木一丁目のオフィス

 

B43で家計管理を始めた。今年一番の体験のサービス。重宝している。

 

8月

オートキャンプすずらんの川サウナが最高だった、おすすめ

 

9月

白馬に登った。下山後に宿泊したホテル五龍館のサウナが今年のベストサウナだった、絶対にまた行きたい

 

大学時代の友人とヤッホーfmというpodcastを始めた（が、かなり更新をサボっている）

 

10月

Data Analyst Meetup Vol.10を開催した。オンライン/オフライン合わせて700人弱の申し込みとなるマンモスイベントとなった。内容は一部podcastで公開した

 

パートナーが骨折。緊急手術のすえ長野の病院にそのまま3週間入院することに（今は無事退院）。山場での事故は山岳事故扱いになり警察への報告が義務付けられているらしい、そしてyahooニュースへ...。人生いつ何が起こるかわからないという気持ちを新たにした。あと保険は大切。

 

11月

5月から家を探し始め、紆余曲折あって藤沢市に家を買って引っ越した。藤沢は大学院生のときに住んでいた時ぶり。骨折につきまだウロウロできていないが、夏になったら湘南ライフを満喫したい。

 

12月

自作キーボード沼にハマってしまった。抱いて寝れるほどとても気に入っている

 

（おまけ）podcastの更新

始めてから3年経つ白金鉱業.FMを今年も13本更新していた、エラい！我ながら無くなったら惜しい番組、良い番組だと思うことが継続の秘訣かもしれない。できるだけ頑張って放送を続けたい。

音声認識モデルwhisperの全モデル文字起こし比較

機械学習

OpenAIの音声認識モデルWhiper、いやー、まじですごすぎて感動しました。

配信中のpodcast番組 白金鉱業.FMを頑張って文字起こしするために、この記事とか、この記事とかでかなり真面目に既存文字起こしAPIの精度などを比較していましたが、もう今回は比べるまでもなく本当に雲泥の差です。ほぼ一言一句正確に文字起こしできます。GCP, AWS, Azureの文字起こしAPIは文字起こし精度が体感30~60%くらいでしたが、whisperは90%超えている印象です。もう笑うしかないです。

最初に結論

whisperは異なるモデルサイズが5種が利用可能であり、文字起こし精度と処理時間の両方を考慮するとどれ使うのがベストかということについては、文字起こしの目的に寄るかなという感じです。

【ニーズ1】 ざっとどんな話してるのかの概要さえつかめれば良い、見た目の綺麗さとか問わない。細かい文字起こしミスも気にしない。なんらかの事情で早く文字起こし結果が欲しい → デフォルトの small モデルを使えば良さそう

【ニーズ2】 数時間単位で時間かかっても良い、句読点等も含めできるだけ見た目もキレイに文字起こしして欲しい → large モデルを使いましょう

他のモデルは品質と処理時間がどっちつかずなので選択肢に入らない印象です。small or largeの2択ですね。

それぞれ、正確にどれくらいのクオリティーがあるのかを知りたいかたは続きをお読みください。

インストール

基本的にはpip一発で入ります

pip install git+https://github.com/openai/whisper.git

実行方法

実行もとても簡単。

whisper コマンドが使えるようになっているので、python以外にコマンドラインでも試せます。ファイル形式はm4aなども可です。

whisper hoge.mp3 --language Japanese --model base

特に languageを指定しなくても自動で言語が識別されるのもすごいところ。

利用できる学習済みmodelサイズは tiny, base, small, medium, largeの順に5種類があり、largeに近いほどダウンロードされるファイルを大きく、認識にかかる時間は長く、認識精度は良くなります。

特にモデルを指定しない場合はデフォルトでは small モデルが使用されます。

コマンドラインでの結果は以下のような見やすい形式で表示されます。

[00:00.000 --> 00:04.260] では今回のお題は最近話題の
[00:04.260 --> 00:06.500] ステーブルディフィュージョンに並んでというか
[00:06.500 --> 00:09.000] 続きてというかで話題の
[00:09.000 --> 00:13.500] ビスパーさんのお話の技術解析を同じく
[00:13.500 --> 00:16.000] 広化先生からお願いしたいと思います
[00:16.000 --> 00:17.800] よろしくお願いします
[00:17.800 --> 00:18.100] そうですね
[00:18.100 --> 00:20.160] ちょうどステーブルディフィージョンとが
[00:20.160 --> 00:24.560] 早ったその週とか次の週とかに

ちなみに、 --task translate オプションを付けると文字起こしした日本語をそのまま英訳変換もしてくれます。便利。

pythonインターフェースでは以下のように3行書くだけ。簡単過ぎる。ここまで来るとAWSなどの文字起こしクラウドAPIを使うよりも逆に簡単なんですよね。（API認証とか、指定のファイルをクラウドにアップロードするところが手間と思えてくるため）

import whisper
model = whisper.load_model("base")
result = model.transcribe('hoge.mp3', verbose=True, language='ja')

返してくれる結果 result には、dict形式で text と segments という情報が格納されており、text は認識されたテキスト全文、segments は何分から何分まで何を話したかという詳細情報が入っています。 発話位置まで正確に知りたいなら segments の情報を使い、とにかくテキスト全文が欲しいだけという場合は text だけ取ってくれば良いです。

結果

5つのモデルの出力結果を比べながら、文字起こし品質の差分はどういったところに現れるか、驚いたところを紹介していきます。

ちなみに、whisperはいまのところ話者分離（AさんとBさんのどっちが何を喋ったか）は行えないので、話者の区別なく音声内容をひたすら文字起こしするということをしています。

今回は白金fmの第60回、まさに今回の主題であるwhisperの論文について解説した回を対象に文字起こししました。podcast用に音声は編集してけっこう綺麗にしているつもりです。これだけクリアにして下駄を履かせているのだから流石に頑張ってほしいという期待を込めて。

open.spotify.com

音源自体の長さは31m5s。ちょうどmtg一回分の長さといったところです。

先に処理時間についてまとめた結果が以下。M1MacローカルのCPUで計算しています。マシンスペックによって処理時間は変わりますが、モデル間の相対関係は変わらないはずなので参考値として。

（CPUでの）処理時間だけでみると、smallモデルまではインプットする音源長よりも短い時間で文字起こし処理が完了するようです。一方、mediumとlargeはそれぞれ2倍、5倍の時間を要します。かけた時間に比例してどれだけ文字起こし品質が向上するかが見どころです。

では肝心の文字起こし品質について各モデルごとの結果です。

tinyモデルの結果

31minの音源に対して3minという爆速で処理が終わっています。（ちなみに、GCPやAWSの文字起こしAPIも同じくらいの処理時間でした）

実際の文字起こし結果はこちら。

https://raw.githubusercontent.com/shirokane-kougyou/shirokane-kougyou.github.io/master/materials/060_whisper_tidy.txt

一瞬、「イケるか？」という気持ちになりますが、ちょっと読み進めると全然意味がわかりませんね。体感としては半分も合ってないような気がします。

また、論文内でも課題として指摘されていた意味のない繰り返しが出現したりする箇所も見つかります

よく音声系の人たちが画像出してるあの納み歌、模様模様模様みたいな画像を見せて

（ちなみにこれでもAWSやGCPの文字起こしAPIよりも全然良い結果だとは感じます）

baseモデルの結果

tinyに続き7minという爆速で処理完了させるbaseモデルです。

文字起こし結果は以下。

https://raw.githubusercontent.com/shirokane-kougyou/shirokane-kougyou.github.io/master/materials/060_whisper_base.txt

結果としては、tinyモデルとどんぐりの背比べという感じです。tinyよりも正確に単語認識できる箇所もあれば、逆にtinyで合っていたのにbaseで間違うという単語も散見されます。

音源にない語が挿入されたり繰り返されたりする加減はtinyよりも悪いような気すらします。

カンマーのウムだったり全て面白い面白い面白い面白い面白い面白い面白い面白い面白い面白い面白い面白い面白い面白い面白い面白い面白い面白い面白い個別の笑顔 笑顔手キストその feelings cons靈魂騎郷審柱カンetes本申し抜けてその個人個人階打電気エ practiced特定敵批判ietまたハマ樋木岩馬五花近小浟vi configurations越が同いってこれによって

普通にtinyとbaseは品質が悪すぎて日本語文字起こしでは使えんなぁという印象ですが、敢えて使いみちを考えるのであれば、例えば音源が膨大にあって、「雰囲気だけでもいいからこれらの膨大な音源から名詞wordcloudをサクッと作ってくれ〜」というときは使えるかもしれません。（そもそもwordcloudは何か有益なものを見ている気持ちになるだけの情報量ほぼ無の可視化なので合ってようが間違ってようが比較的どうでもいいやつなので）

smallモデルの結果

インプット音源のだいたい半分くらいの時間で処理を終わらせてくれたsmallモデルです。whisperのデフォルトではsmallモデルが使われているので、見せてくれよデフォルトのチカラってやつを！

文字起こし結果は以下。

https://raw.githubusercontent.com/shirokane-kougyou/shirokane-kougyou.github.io/master/materials/060_whisper_small.txt

これはいい感じです！頭から読んでいっても意味わかるなーという気がしてきます。句読点が無いので読みにくいのは間違いないですが、なんの話をしているかは大分わかってくるのではないでしょうか。さすがデフォルトモデルいいぞデフォルトモデル。

ここは間違ってるだろうなと感じるところもかなりまだありますが人間が脳内補正可能な範囲かなと。この品質がインプット音源のだいたい半分くらいの時間でサッと自動で出てくるのなら使い方にも寄りますが御の字ではないでしょうか。

そしてtinyやbaseで見られた意味不明の繰り返しなども見つかりません。

処理時間と文字起こし品質の両方を考えたときに、このモデルをwhisperのデフォルトに指定されているのもとても納得感があります。

mediumモデルの結果

いやー、これまでの文字起こしAPIたちと比較してもうsmallモデル見せてもらっただけで胸がいっぱいですよ…という気持ちを持ちつつ、まだ見てみたいその先を。

mediumからは音源時間よりも長く処理時間を食うので完全に精度を追い求める旅です。smallとの差分としてどこが変わってくるのか。

文字起こし結果は以下。

https://raw.githubusercontent.com/shirokane-kougyou/shirokane-kougyou.github.io/master/materials/060_whisper_medium.txt

いやー、もうここからは日本語文字起こしの新世界です。発音した音は全部文字起こしされているレベルです。マジか。感動です。

句読点がないので読みにくさは残りますが、個々の単語認識精度が着実に上がっている印象です。

small, medium
ステーブルディフュージョン → stable diffusion
オープンAI → Open AI
シークエンス2シークエンス → Sequence to Sequence

カタカナ英語発音を英語と認識してくれるようになっています。スゴイ。

もうlargeの結果を見るのが怖くなってきました、まだ上があるの？

largeモデルの結果

もう笑ってしまう結果です。綺麗すぎて嘘でしょ？って思ったのでlargeモデルの結果は音声と聴き比べながら一言一句確認してみました。

赤マークがwhisperの間違い箇所です。もう間違いを探すほうが難しいレベルです。体感的には95%以上合ってるのでは？という感じです。これがAIってやつか。

docs.google.com

largeモデルからはなんと句読点も付与されます。おかげで圧倒的に読みやすくなりました。これを見ちゃうと5倍時間がかかったとしてもlargeで文字起こしして欲しいとなりそうです。そしてこの処理時間はもちろんGPUを使うともっと短くなるはずです。

以下はちゃんと認識されててびっくりした文字列たち

Stable Diffusion
Whisper
OpenAI
Automatic Speech Recognition
BigSSL
Sequence to Sequence

BigSSL, OpenAIなどは固有名詞認識されるようになりました。そして "Whisper"も英語表記になりました。

また、日本語会話で無意識に口走る「ええっと」「まぁ」「あのー」「へー」「あっ」「うん」などを見事なまでに”よしなに”消しています。かつ、過剰に消しすぎている印象もない。そのおかげもあり文字起こしテキストが極めて自然に”読める”ようになっています。
改めて細かく見比べてみると、smallモデルにはまだそのままこれらの語が文字起こしされており、mediumで減り、largeでほぼ完全によしなに消えているという印象です。

「じかんかけるしゅうはすう」の発音を「時間×周波数」に文字起こししているのも賢すぎます。 句読点を打つ位置も自然すぎる。ちょっと区切りながら「this, is, a...」と話したところも正確に句読点打ってくるので笑ってしまいました。人間より正しく句読点打ててそう。

ここまでくるとスーパーヒューマンレベル（人間超え）という宣伝文句も納得ですね。ふつうにこの結果を「頑張って全文文字起こししましたー」と人間に渡されても気づかないんじゃないですかね。

話者分離はいまのところできないようですが、最近だとzoomなどでも話者個々の音声ファイルを別々に保存できるので、別々に音声認識かけて、会話自体は後からガッチャンコして復元すれば良さそうです。そのように話者分離自体はモデル外で工夫の余地があるので、むしろ句読点等を高精度に付与可能になったのが嬉しいですね

まとめ

日本語音源の文字起こしはwhisper 一択、とりあえず脳死でこれを使っておけという時代がやってきました。

最初に【ニーズ1】の人はsmallモデル、【ニーズ2】の人はlargeモデルを使おうと書きましたが、largeの品質が圧倒的に高いのでコスパ度返しで何でもかんでもlargeで文字起こししたいという気持ちになりますねわかります。

パッと思いつく利活用として、社内の議事録などこれで文字起こしすれば？というのがありますが、今回のlargeの文字起こし結果と実際の音源を聞いてもらうととわかる通り、今回の話者のように淀みなく論理的に話を進めている印象の会話ででも、それでも書き言葉としては読みにくく、口語と書き言葉にはかなり差があることが改めてわかります。whisperは聞こえている音を片っ端から文字起こしし、要約的なことは一切しないので当たり前といえば当たり前ですが。

podcast大好き人間として、高品質な日本語音声文字起こしをかなりの低コストで実現する技術ができたことで、podcastの全文文字化・全文検索・類似番組の検索 などが技術的かつ実用的に可能になりました。検索が可能になったことで番組内容に合致する音声広告なども検討しやすくなると思うので、更にpodcastの市場性は広がるのではないでしょうか。そちらの方向も楽しみです。

高精度文字起こし・発話位置・句読点付与がwhisperによってほぼ解決したのだとしたら、あと残りの日本語音声認識に対する技術ニーズってなんですかね（詳しくない）。ぱっと思いつくのは、

  • ノイズが多い音源での認識
  • 話者分離
  • リアルタイム文字起こし
  • 感情推定（日本語はangry以外の推定がまだまだ弱いらしい）
  • 好みの声の推定系（可愛い声、イケボ的な）

とかでしょうか？アツいですね。

追記

こういう高精度なモデルがでるとエンジニアは意地悪したくなるもの…

この記事を公開後に、社内から寄せられた「おれもこういう実験やってみた」という面白事例が届いたので紹介です

カタカナ英語 完全制覇 whisperくん

実験者が作成した低クオリティーな英作文をカタカナ英語（俗に言うJapanese English）で朗読してwhisperで文字起こし。

languageを非明示にすると日本語と判定され上手く文字起こしできなかったが、language="en" にするとなんと原稿との一致率は驚異の100%

おそらく、英語データセットにはいろんな国の人が話す"綺麗ではない英語"もたくさん含まれており、それを学習しているから堅牢性が高いのではと想像します。カタカナ英語なんてAIからするとただのノイズであって「本質情報を学習しているワイには簡単に識別できまっせ」という感じなんでしょう。

せんでんせんでん

機械学習/AI、データサイエンスビジネスについて話すニッチなpodcast番組「白金鉱業.FM」をやっています。フォローよろしくおねがいします。

twitter.com

LGの35インチウルトラワイド湾曲モニター35WN75C-Bレビュー

ガジェット

f:id:ysdyt:20211128162927p:plain

初めてのウルトラワイド湾曲モニターを購入したのでそのレビューです。

数年前に初めて湾曲モニターをネットで見かけたときは、宇宙船のコックピットから画面を眺めるような、圧倒的な存在感を醸していました。またお値段も非常に高かったため一部のマニアックな人向けの商品だと感じていましたが、最近は例によって一般人でも手が届く価格帯になってきた印象です。
動画編集やPCゲーマーが増えたこと、在宅環境に投資する人が増えたこともあり周囲にも利用する人がちらほら現れてきました。そして今回自分もその一人になりました。

なぜ買ったのか

メイン機をM1 MacBook Airにしたことが大きいです。噂通りM1 Airはとても良いマシンなのですが、最大とも言える欠点が外部モニターを1台しか接続できない点です。*1

これまで27インチ・24インチモニターの2台体制で作業していましたが、1枚しか使えないならこの際デカいモニター1枚にしようと思い、「そういえば今ならウルトラワイドモニターも安くなってるのか？」と調べました。

デュアルモニター環境に匹敵するサイズで、値段もそこそこで、画質も良い という条件でいろいろ探してみたところ、表題のLGの35インチ 35WN75C-Bが良さそうだったのこれに決めました。*2

特に欠点らしい欠点のない、コスパの良いウルトラワイドモニターだと思います。

（※以下の写真や動画ではM1ではなく旧MacBookProを使っているので2枚のディスプレイに投影できています。）

とんでもなくデカすぎるかもしれない...とちょっと心配もしましたが、やはり記載サイズ通りで、重さもそれほどでした。慎重に作業したら男性なら横着して担ぎながらネジ止めできるレベルの重さです。

良いところ

  • 35インチでデカい、デカいわりに相対的に他社商品より安い
  • 3440 x 1440 Pixelsで解像度もバッチリ
  • モニター背面にはUSB-A3.0ポートが2つ, tpye-Cが1つ（94W PD対応）, DisplayPortが1つ, HDMIが2つ, オーディオジャック1つとモニターだけでも拡張性が高い
  • 高品質ではないがスピーカーも内蔵
  • フレッシュレート100Hz（ゲームやらない人にはあまり関係ないが）

なんと言っても良いところは、背面のtype-Cポートからディスプレイ投影と90W充電がケーブル一本で同時に出来る点。人によっては別途ハブなどで拡張しなくてもこれで完結できるお手軽さ。

あと、意外に「湾曲」してなかったですね。体感的にはほぼ平面です。楽しみの一つだったのでちょっと悔しい。
49インチなどのもっと大画面モニターでは湾曲してないと両端が見えにくくなるのかもしれませんが35インチ程度では平面であっても特に困らなそうです。

 

自分の利用用途としては、ウェブブラウジングやテキストタイピング、動画を見る以外には、VSCodeなどでのコーディング、LightLoomでの写真編集などをよく行いますが、全く色味や解像度（文字潰れなど）が気になることはありません。MacのRetinaディスプレイと比較しても同じくらい綺麗だなーと感じます（世の中の98%の人の用途では自分と同じ感想になると思ってます）

 

肝心の広さはというと、デュアルモニター体制と比較しても遜色ない、むしろちょっと広い？という感じです。

実測値ではデュアルモニター体制のほうが長い（大きい）のですが、やはり2枚で分割されない分だけデッドスペースも少なく、シームレスに使える画面が広いほうが体感としても広く感じるのではと思います。ウィンドウを右半分・左半分に1つづつ置いても十分な広さがあります。

youtubeなどではやたらデカく見えていたんですが、普段からデュアルモニター使いの人はもしかすると35インチではそこまで感動するほどではないかもしれません。

総評

当初の目的であった画面サイズも十分デカイですし、画質も綺麗で満足して使っています。

ガジェットyoutuberたちは口を揃えて、「動画編集時にタイムラインが一望できて編集効率が上がる！」というのですが、一般人的にはマジどうでもいい。それでも横長画面ではブラウザ開いた横でパワポ作ったり、zoom開いた横でgoogle docにメモしたり、間違いなく便利は便利です。

欲を言うなら、予算が許すのであれば後述する49インチのものでも良かったなとは思いますが値段が3倍ほど違うので流石に諦めました。ウルトラワイド湾曲モニターデビューのお試し1台目としてはコスパ高いと思います。

おまけ1: ウルトラワイドモニターを買うときの注意点

  • 当然ですが、ウルトラワイドモニターは横幅が80センチ以上と広いため、小型の作業デスクではかなり窮屈さを感じそうです。
  • モニターアームを使わずスタンドでモニターを支える場合、スタンド周りも場所を取るので机の奥行きも最低60センチ以上は欲しいかもです。
  • モニターアームを使う場合、耐荷重も注意です。多くの人が使っているであろうamazon basicモニターアームの耐荷重はmax13.5kgらしいので、8.3kgである35WN75C-Bモニターはセーフですが、別のアームを使用されていたら要確認です。
  • 一般にウルトラワイドモニター（25インチ~40インチくらい）として販売されているものの中には、 解像度が「2560×1080」「3440×1440」の2種類が存在しているようですが、「2560×1080」は買わないほうが良いです。
    • 「モニタサイズの割に解像度が荒く、ドットがかなり目立つ」「解像度の粗さから、小さな文字などが表示潰れする」らしいです*3。
    • 写真や映像などの仕事をされている方はやはり画質が気になるらしいので、4Kモニターを買うほうが良いみたいです*4。
      • 4Kのウルトラワイドモニターはまだ非常に高価（20万近い）ですが、30インチほどのサイズでは5万円以下で手に入るようです*5。
  • 49インチくらい大きくなると、逆に大きすぎて左端・右端が視角から外れてしまい、通知のポップアップに気づかない、ゲームの表示情報が見えなくなる、などで不便という声もあるようです*6。

おまけ2: 他の候補だったモニター

次点で最も良かったもの。「頻繁に買い換えるものでもないし、いっそ奮発するか？」と検討したのが49インチのこちら。こちらのyoutubeやnoteを見てもめっちゃ良さそうなんですよね。背面にはUSB-Aが5個もあり拡張性も十分。ただしお高い。

 

amazon限定のファーウェイモニター。音に拘りがない＆モニターアームを使うため逆にサウンドバーが邪魔だなと...。USB-Aの拡張ポートもついてないのが相対的にマイナスポイント。またUSB-Cでの給電は10WなのでPCには別途コンセント接続が必要な点が大きくマイナス。

 

49インチはデカすぎるが、45インチより大きいのが良いときの選択肢1。ただし49インチより値段が高いので却下。

 

49インチはデカすぎるが、45インチより大きいのが良いときの選択肢2。湾曲ではないものの、スペック問題なしで値段感もかなりお得。懸念はInnocnという聞いたことのないメーカーであり買うには人柱になる覚悟がいる点。

 

49インチはデカすぎるが、45インチより大きいのが良いときの選択肢3。ただし値段が20万超えなのでやっぱり却下*7

 

...という感じで、やっぱり品質・値段・サイズを総合すると35WN75C-Bになるのでした。

*1:もうちょっと調べてみるとDisplayLinkという方法で2枚以上映せるそうですがゴニョゴニョしないとダメそう

*2:複数のガジェットyoutuberが紹介していたのも参考になりました。こちらとかこちらとかこちらとか

*3:https://youtu.be/iCzzsmk0X6U

*4:https://www.youtube.com/watch?v=3lAGptBZt4s

*5:https://www.youtube.com/watch?v=Ia1PGmczVko

*6:https://www.youtube.com/watch?v=fAa_c3YBZv0

*7:https://www.youtube.com/watch?v=Gj2J0RpC-2E

Selenium + Heroku + LineAPIで、ふもとっぱらキャンプ場に空きが出たら通知する

自動化

f:id:ysdyt:20211008095839p:plain

selenium + heroku + Line APIで、ふもとっぱらキャンプ場予約サイトを10分毎にスクレイピングし、予約に空きがでたらLineに通知するというアプリ、を作った人がいるのでそれを動かすために試行錯誤した話のメモです。

これで予約戦争に勝つる...！

予約がとれない聖地

キャンパーの聖地とも言われるふもとっぱらキャンプ場は、3ヶ月先までのキャンプ宿泊予約を専用のwebサイトでネット予約できますが、あまりの人気のため公開されるやいなや3ヶ月先まで基本的に土曜日は常に予約が埋まっています。

fumotoppara.secure.force.com

この状況となる人気以外の原因の一つとして、予約を無視して行かなかったとしてもペナルティーがない（予約時にクレカを登録したりせず支払いは現地だから）というのもあります。「とりあえず予約だけしとくか」「いけなくなったけどわざわざキャンセルしなくてもいっか」が実際は通ってしまう運用になっている点です。 キャンプ場もこのあたりまで厳密に運営する元気は無いのでしかたないところです。

ということで予約画面とにらめっこするのは大変なので自動化しようとしたら、やはり先人がおられました。

上記のコードをありがたくforkし、自分の環境でも動くようにしたものがこちら。 github.com

動かすまでの確認作業の大まかな流れは以下です。

1. seleniumで正しくスクレイピングできるか確認（ローカル）
2. Line Message APIが正しく動くか確認（ローカル）
3. Herokuに移植して、heroku上でも正しく動くか確認（heroku）

このブログでは、folkしたコードを使って自分のherokuで動かすまでに手こずったところをメモとして残しておきます。

元ネタのブログでも詰まったところについて触れられていますが、主なハマりポイントは以下です。

- seleniumを動かす方法
　- google chromeとchrome driverの設定方法
- herokuの動かし方
　- herokuでのgoogle chromeとchrome driverの設定方法
　- LINEのtokenをどうやって設定するのか

おおよその解決策に対する参考になるブログ記事はネタ元のブログにも紹介されているのでそちらを先にざっと読むとわかりやすいです。ここではより細かいトラブルシューティングのメモとなります。

まずはseleniumをローカルで動かす

forkしてきたコードの処理内容を把握するためにまずローカルで動かしてみようとしました。

qiita.com

selenium公式がdocker imageを作ってくれていますが、最初は自分で環境作ってみたいなと思いminicondaの上に作ることにしました。

seleniumはブラウザの自動操作を行うものなので、実際にブラウザが必要になります。ここではgoogle chromeを使いました。現在使っているgoogle chomeのバージョンを確認すると、自分の環境では バージョン: 94.0.4606.71（Official Build）（x86_64）でした。（確認方法は google chromeの「︙」>「設定」>「Chromeについて」）

次に、seleniumからchromeを動かすために必要なchromedriverというものをpip installしておく必要があります。注意点として、chromedriverはgoogle chromeのバージョンに合ったものでないといけず、現状の自分のバージョンと見比べて指定しないといけません。ややこしいのは、google chromeと同じバージョンを指定するのではなく、以下のページを見て、一番数字が近い、低いバージョンを指定しないといけない点です。

ChromeDriver - WebDriver for Chrome - Downloads

ここでは、google chromeのバージョンが94.0.4606.71であったため、一番近くて低い94.0.4606.61.0を指定します。

pip install selenium
pip install chromedriver-binary==94.0.4606.61.0

実際に呼び出して使ってみます。試しに、googleにアクセスして「selenium」と検索する動作を行ってみます。上手く動けば、コードを実行するとgoogle chromeが勝手に立ち上がって指定の動作をするはずです（最初に見たときはちょっと感動）

import time
import chromedriver_binary 
from selenium import webdriver

driver = webdriver.Chrome()
driver.get('https://www.google.com/')
time.sleep(5)
search_box = driver.find_element_by_name("q")
search_box.send_keys('selenium')
search_box.submit()
time.sleep(5)
driver.quit()

chromedriverをダウンロードする必要があることと、どのバージョンをダウンロードしないといけないかがちょっとわかりにくいくらいです。

heroku スケジューラーの設定

今回のタスクは常時処理が走っている状態ではなく、定期的にスポットで処理が走ってくれたらokです。 herokuではその場合はスケジューラー機能を使えば実現できます。

設定方法は以下です。（無料枠内の使用であってもスケジューラー機能の使用にはクレカの登録が必要）

qiita.com

今回はスケジューラーの最小起動頻度である10minごとを指定し、動かしたいタスクとしてpython3 notification.pyを設定します。dynoサイズも小さい方であるStandard-1Xを選んでおけば良さそうです。

f:id:ysdyt:20211007233014p:plain

ここでは管理画面からGUIで設定しましたが、こちらに書いてあるとおり、コマンドラインからも同様の設定ができるようです。

herokuの無料枠

Free dyno 時間 | Heroku Dev Center

クレカ認証を行うと毎月1000時間のFree Dynoを得られます。10分に一回コードを起動するタスクがどれくらいのdynoを消費するのか厳密にはわかりませんが、実際に以下コマンドで消費量を確認したところ微々たるものっぽいです。今回のようなアプリでは1%分消費できるかどうかという感じで完全に無料枠内に収まります。

$ heroku ps -a fumotoppara-yoyaku
Free dyno hours quota remaining this month: 996h 29m (99%)
Free dyno usage for this app: 2h 57m (0%)
For more information on dyno sleeping and how to upgrade, see:
https://devcenter.heroku.com/articles/dyno-sleeping

No dynos on ⬢ fumotoppara-yoyaku

herokuでのTokenの設定

TokenやAPI key, パスワードのように内緒にしておきたい情報の取り扱い方です。

herokuに関係なく、通常そういった情報が含まれるコードをgithubなどで管理したい場合は、以下のように隠しファイルに情報を入れておき、gitignoreでリモートにプッシュしないようにしておくなどの方法があります。

# .envファイルを作り、そこにLINE tokenを記載する
$ touch .env
$ echo LINE_TOKEN='xxxxx' >> .env

# dotenvモジュールでファイルから情報を抜き出す
import os
from dotenv import load_dotenv #pip install python-dotenv で入る

dotenv_path = os.path.join(os.path.dirname(__file__), '.env')
load_dotenv(dotenv_path)
LINE_TOKEN = os.environ.get("LINE_TOKEN")

herokuではgitと同じ方式でファイルを管理・pushすることでアプリをdeployしますが、同じ様にするとherokuからは .envファイルが見えなくなりtokenが取得できなくなります。

そこで、herokuで同じことをするためには、herokuの環境変数に登録することで実現します。方法は以下。

cream-kuchen.hatenablog.com

今回だとこんな感じです。（chromedriver側の話は後述）

f:id:ysdyt:20211008091852p:plain

これもGUIでも出来るしコマンドでもできます。

$ heroku config:set LINE_TOKEN="hogefugapiyo"

登録された変数は heroku configコマンドで確認できます。

$ heroku config
=== fumotoppara-yoyaku Config Vars
LINE_TOKEN:  hogefugapiyo

herokuでのChromeとdriverの設定

今回もっともハマったところです。heroku上でgoogle chromeを操作してseleniumを動かしたい場合、herokuのSettingsでBuildpacksを指定しないといけません。

qiita.com

f:id:ysdyt:20211007233612p:plain

これもGUIでもできますしコマンドでもできます。

$ heroku buildpacks:set https://github.com/heroku/heroku-buildpack-chromedriver.git -a fumotoppara-yoyaku
$ heroku buildpacks:set https://github.com/heroku/heroku-buildpack-google-chrome.git -a fumotoppara-yoyaku

設定後、git push heroku mainすると上記に登録したものが実際にダウンロードされてheroku上にbuild＆deployされるため、設定後は空pushでもいいのでpushを忘れないように。

そしてさらに、多くの人がハマるのがおそらく次で、実際にここまで設定してherokuにpushしても、何らかの理由でpushがコケるという状態が発生しがちです。自分の場合は以下のようにunzipエラーを吐かれました。

remote: Archive:  /tmp/chromedriver.zip
remote:   End-of-central-directory signature not found.  Either this file is not
remote:   a zipfile, or it constitutes one disk of a multi-part archive.  In the
remote:   latter case the central directory and zipfile comment will be found on
remote:   the last disk(s) of this archive.
remote: unzip:  cannot find zipfile directory in one of /tmp/chromedriver.zip or
remote:         /tmp/chromedriver.zip.zip, and cannot find /tmp/chromedriver.zip.ZIP, period.
remote:  !     Push rejected, failed to compile chromedriver app.
remote: 
remote:  !     Push failed

理由の多くの場合は「Chromeとdriverのバージョンが一致していない」ことなどです。
これを一致させてpushしてもコケさせないようにするには、Config Varsに設定するCHROMEDRIVER_VERSIONのバージョン数を以下のように調べて指定する必要があります。

cream-kuchen.hatenablog.com

自分の環境での例です。まずbuildpackでダウンロードされたchromeのバージョンを確認。

$ heroku run google-chrome --version -a fumotoppara-yoyaku
Running google-chrome --version on ⬢ fumotoppara-yoyaku... up, run.4315 (Free)
Google Chrome 94.0.4606.71 unknown

94.0.4606.71に一番近くて低いchrome driverのバージョンをこちらで探すと、ChromeDriver 94.0.4606.61とわかったのでConfig Varsに登録する

f:id:ysdyt:20211008091852p:plain

コマンドラインで登録する場合は

$ heroku config:set -a fumotoppara-yoyaku CHROMEDRIVER_VERSION="94.0.4606.61"

これで再度git push heroku mainします。晴れてpushが成功するとActivity画面にBuild succeededのログが残ります。

f:id:ysdyt:20211003205908p:plain
pushに成功するとBuild succeededとなる（失敗するとBuild failed）

実際にダウンロード・ビルドされたchromedriverのバージョンを見てみると、たしかに指定したものになっていることがわかります。

$ heroku run chromedriver --version -a fumotoppara-yoyaku
Running chromedriver --version on ⬢ fumotoppara-yoyaku... up, run.4744 (Free)
ChromeDriver 94.0.4606.61 (418b78f5838ed0b1c69bb4e51ea0252171854915-refs/branch-heads/4606@{#1204})

正しく動いているかログを確認する

herokuへのpushが成功した後、ここでは10分に一度指定の.pyを叩くようにschedularに指定していたので、それが正しく動き続けるか確認します。 確認は$ heroku logs --tailコマンド。

Configuration and Config Vars | Heroku Dev Center

もしもdeployがコケていたり、何かしらコードにバグがあればここのエラー文を見るとなんとなくわかるはずです。
意図通り動いている自分の環境では、以下のようにログが出力されています。

2021-10-07T14:39:49.532222+00:00 app[api]: Starting process with command `python3 notification.py` by user scheduler@addons.heroku.com
2021-10-07T14:40:03.126384+00:00 heroku[scheduler.2676]: Starting process with command `python3 notification.py`
2021-10-07T14:40:03.722456+00:00 heroku[scheduler.2676]: State changed from starting to up
2021-10-07T14:40:04.234487+00:00 app[scheduler.2676]: /app/.heroku/python/lib/python3.9/site-packages/selenium/webdriver/firefox/firefox_profile.py:208: SyntaxWarning: "is" with a literal. Did you mean "=="?
2021-10-07T14:40:04.234504+00:00 app[scheduler.2676]: if setting is None or setting is '':
2021-10-07T14:40:15.204707+00:00 heroku[scheduler.2676]: Process exited with status 0
2021-10-07T14:40:15.293579+00:00 heroku[scheduler.2676]: State changed from up to complete

Starting process ~~~ から始まり、指示通り処理を終えられたら State changed from up to complete で終わる感じです。（途中にfirefoxブラウザに関するsyntax warningが出ていますが、動いているし気にしないことにする）

herokuでの動作確認

今回のアプリの場合、上記までで上手くdeployができれば、放っておくと10分に1度Lineにキャンプ場空きメッセージが届くようになるはずです。

ただ、10分待つのも面倒なので、すぐに指定の処理を動かして正しく動くかどうか確認したい場合は、以下のようにheroku run で実行が可能です。

$ heroku run python3 notification.py

ここまでやっても予約が取れねぇ

1週間ほど動かしてみたところ、土曜日の空き通知が10件ほど来ました。思ったよりはキャンセル申請をちゃんとする人がいるようです。しかし結果としてはことごとく予約を取れませんでした（なんでや）
通知がきてソッコーで予約ページを見にいってもすでに埋まっている（！）とか、入力している間に誰かが予約を完了してしまって取れなかった、などです。

herokuスケジューラーの最小起動頻度が10分に1回のため、通知が来てすぐに見に行ったとしても最大で10分間空き状態が存在していたことになるため、その間に取られるようです。（ここは運ゲーですね。）
逆にいうと空きが発生しても10以内でほぼ確実に埋まっているため、手動監視している人はよほどの強運が無いと偶然キャンセルを見つけて予約をゲットできる可能性はかなり低そうです。

たくさんの人がプログラムで監視してるとは思えないですが、それにしても埋まるのが早すぎる。。。スクレイピング勢が予約入力フォームも自動で打ち込ませてるのではと思う速さです。ふもとっぱらキャンプ場の予約、実はデジタル戦争なのか？

追記

その後、無事に予約ゲットできました！10分ですぐに埋まらず、なぜか20分たっても30分たっても予約が埋まりきらない土曜日も極たまにはあるようです。

noteで記事を書いてみることにしました

なんとなく気まぐれでnoteで続きを書いています。
markdownで書けないことに衝撃を受けているのでまた帰ってくるかもしれません。
何事もやってみないとですね。

WEEKLY人工無脳のnote版はこちらです。
note.mu

WEEKLY人工無脳【第13号】（2018.7.2~7.8）

WEEKLY人工無脳

f:id:ysdyt:20180430031726p:plain

①AIをビジネスに使うのって、「ふわっとしたタスク」と戦い続ける作業だよね

blog.tinect.jp

整理されたタスクは高速で処理できる人は結構いるけど、ふわっとしたタスクを具体的なタスクに落とし込める人はあんまりいないよね、って話。筆者はデータサイエンス系の方ではないようですが、「AIでなんかできない？」という”King of ふわっとしたタスク”を投げられる業界の方々においては非常に既視感のある話です。わりと「うんうん、そうだよね」っていう普通の話ではあるのですが、このネタについてある程度言語化してくれているのと、物申したいPM業の方がたくさんいてバズった模様。

本文では結局、「具体的なタスクに落とし込めるようになるには、そういった経験をたくさんするしか無い」という救いのないまとめになっているのですが、これに対して別の方が書いたブログもおもしろいです。

teruyastar.hatenablog.com

普通のプロジェクトがダメになるのは「自分に与えられた仕事の範囲は絶対超えない」「本音は言わない」それをしては余計な問題になるし空気も悪くなる。 このプロジェクトはアマチュアじみた「使命」ではなくプロとしての「仕事」だから。 ゲーム会社も普通の会社も評価システムは全て「本音」を封じ「空気を読む」ほど評価が上がるようになっている。

「ふわっとしたタスクを具体的にする」という話からは少し脱線し、「炎上しないように的確なタスクをあぶり出して、解決するPMはどんな人か。その時の組織構造はどういうものか」というような話をしています。

ぶっちゃけ、分析ができて理解力も高くて手もよく動く人というのは新卒でも結構います。データアナリスト4年目5年目みたいな人が新卒と同じ仕事をしていると結構ヤバイのです。経験を積んできた人はPMとして稼働して、人間1人が達成できる仕事以上のことをチームを動かして5倍10倍と成果を出せないと組織もスケールしないのでヤバイ。それでも「分析力」と「PM力」の両方を高度に満たすのは難しくてデータサイエンス業界のPM不足問題は他業界よりも厳しい感じがします。ただでさえデータサインス自体も体系的に学ぶ方法があまりなく、その上さらに育成メソッドも確立しにくいPM業が重なる問題。どうなるんでしょうね。まぁみんながんばりましょう（適当）

②世界中に住所を付け直すビジネスがほとんど錬金術みたいなんだが

jp.techcrunch.com

世界中の場所を3文字の単語の組み合わせでマッピングするアイデア。この方法で3mメッシュという細かさで世界中の位置をピンポイントで指定できる。

1年ほど前にこのアイデアを見たときは、「確かに便利かもだけど何に使うんだこれw」って思ってたら、自動運転業界などから多額の投資が相次いているらしいです。なるほど…。
3mメッシュという超ピンポイントな位置表示が可能なのでAirbnbのホストは3語のアドレスを使ってゲストを分かりにくい入口に案内したりもできるらしい。なるほど…バカにしてすまんかった…そういう使い方は確かに便利だ…。

世界中に超詳細なユニークな住所をつけ直す、というだけのアイデア。誰もが思いつきそうで誰もやってこなかったビジネス。そしてほとんど錬金術みたいな資金集めしている感がすごい。

③日本にもキャッシュレス化のビッグウェーブがようやくきた！が、油断は禁物だ！！！

japanese.engadget.com

電子マネーやクレジットカード決済時に店側が負担する3〜5％の手数料が、日本のキャッシュレス化を阻んでいると言われており、その手数料がゼロとなれば、中小店舗のキャッシュレス化が一気に進むかもしれません。

Line Payが本気出してきた感。8月1日から3年間限定としているが、決済手数料ゼロでQRコード決済を開始。これで小さなお店でもキャッシュレス支払いできる。 そしてQRコード決済でポイントも付与というキャンペーン付き。いいねいいね！3年はユーザーの意識を変えるには十分な時間。

これに呼応してYahooも導入・入金・決済手数料ゼロの「ヤフースマホ決済」を10月に開始。殴り合いが始まった（いいぞもっとやれ）

japanese.engadget.com

一方、盛り上がっていたら国がこういうことも言い始めた。

getgadgets24.blog.jp

QRコード決済は余計なハードウェアがいらないところが良いところなのに、「標準化」とか言って無駄なハードウェアやめんどくさいルールとか絶対作らないでねって感じです。マイナンバーカードみたいなことになったらマジ許さん。

さらに一方QRコード決済大国 中国では、

④googleのスマートリプライ機能は退職願いもスマートに出してくれる

一体どういう学習をしたら＆会話してたらこのサジェストが出てくるのかが気になるw このツイートへのリプに「辛い時、押してしまいそうだ。」とか書かれててウケる。ベンリダナー。

⑤IT化進めたら売上が下がったでござるという話

https://twitter.com/k_room/status/1015158019271712774?s=12

個人的には目から鱗だった話。鳥貴族が価格値上げによる売上減少を理由に売上予想を下方修正、それに対して「接客をタッチパネルにしたからや」という指摘。

ある時から近所の鳥貴族も注文をタッチパネルで受け付けるようにしており、「便利になった〜」「外国人店員さん多いから最悪日本語話せなくても良くなったね〜」「データも取れるし〜」と、みんなきっともっとカジュアルに注文するようになったもんだと思ったら、実は飲みながらタッチパネルで合計金額が確認できたら切りの良いところで注文を思いとどまり、結果客単価が下がってるんだという指摘。

IRにはそういった言及が無いようなのでこれはツイート主の意見ではあるが、さもありなんという気もする。価格値上げといっても280円が298円になっただけだし、確かに他の原因と考えたほうが妥当そうな気がする。

もろもろの効率化やデータ取得のためにこういったデバイスを導入する場面は飲食店以外にもたくさんある。カジュアルにIT化を進めるとこういうこともあるのかと目から鱗でした。

⑥カメラは隠すべき？隠すほうが気持ち悪くない？

https://www3.nhk.or.jp/news/html/20180704/k10011507411000.htmlwww3.nhk.or.jp

東京オリンピックまでに首都圏の在来線のすべての列車に防犯カメラを設置することが決まったという話。

カメラは蛍光灯と一体となったタイプで、１両に８か所設置。録画した映像は１週間程度で上書きという仕様。プライバシーへの配慮とかなんとかでこれまで導入しなかったのだろうけど、やっと導入かという気持ち。 痴漢行為への抑止力としても、カメラがどの方向を向いているのかわからないようにするのは意味があるので良いと思うのです。ただ、こちらのニュースは意味がわからない。

http://news.tbs.co.jp/newseye/tbs_newseye3411986.htmnews.tbs.co.jp

リンク先の画像を見てもらうとわかるのですが、自販機商品サンプルの小さな穴からカメラが覗く構造にしていて完全に隠し撮り状態…。防犯への抑止が主目的なら「動画！！！ばっちり撮ってるぜ！！！」とうるさいくらいアピールするカメラを堂々と設置すればいいと思うんですがどうなんでしょう。気持ち悪い感…。

機械学習を行う防犯カメラなどもこれからきっと増えていくと思うのですが、こういったカメラ設置に対する考え方も一緒にアップグレードされていってほしいところです。隠し撮り、ダメ、絶対。

⑦ブロックチェーンのゆりかごはアート領域？

jp.techcrunch.com

ブロックチェーン活用事例の話は出ては消えを繰り返しているのですが、今回はアートの売買をブロックチェーンで管理し、転売されるごとにアーティストへ還元金が再分配される仕組みを作ったベンチャーの話。

流動性があり取引が追いにくい商材として「アート作品」というのは確かにブロックチェーンで管理するには良いターゲットなのかもしれない。アート作品が他の商材と違うユニークな特性として、「新品が最も値段が安い」というのも面白い。所持者や購入金額もアートの価値に大きく影響するものだからこそ、売買ルートをクリアに管理するという発想は自然な気がする。

ここでは「アート作品」に対してブロックチェーンを利用する話ですが、@tokorotenさんがマッハ新書で出されている個人ICO 3.0にはアート作品を作る人自体にもブロックチェーン技術（Initial Coin Offering）を適当しようという話も登場し、非常に面白い考え方なので興味ある人はぜひ買って読んでみてください（オススメ！）

⑧データで服を作るzozo、服制作も全自動化を目指す

www.itmedia.co.jp

zozoスーツで集めたデータを組み合わせて、ほぼ無人で1着40分でニットを自動製造機するプロセスも開発したという話。

ZOZOのプライベートブランドのニット製品は「ホールガーメントとZOZOSUITで計測した体形データを掛け合わせ、1着当たり40分で作成する」

ファッションに疎い人向けの神教科書服を着るならこんなふうにによると、「自分の体格にあったサイズの服をきているだけでちゃんとしてみる」ということなので、zozoスーツ採寸で作られるぴったりサイズの服を手軽に買えるようになることには期待しかない。今後オーダーメードスーツも同じく販売を開始するとのこと。体型データをフルに使って業界をぶっ壊して欲しい。

そして、製品の価値や体験を高めることと同時に、製造自体も自動化するところまで着手していてカッコイイ。これぞデータ活用の真骨頂という感じ。市場的にもめちゃくちゃインパクトがあったようで、従来のスーツ業界各社の株価は暴落した模様。こんなにわかりやすくデータビジネスが旧業界をdisruptしているのはもしかして初めてなのでは？

⑨価値観を問い直すサービスは流行る。たとえそれが命であっても。

globe.asahi.com

最後は個人的興味のあるバイオ系の話。遺伝子が関することは軒並みデータサイエンスの範疇だと思ってます。遺伝子データビジネス、すごいキテますよ！

中国のペットクローンビジネスが盛り上がっているという話。世界中の富裕層から超高額でも依頼が増えている。

クローンペットビジネスは実は2008年からすでに始まっていて、一匹約1100万円（！）という破格の値段でも世界中から依頼がくるらしい。主には「死んだ愛犬を生き返らせたい」という希望から依頼がくる。 遺伝子的にクローン（ハードウェアはオリジナルに等しい）でも、魂は別物。それでも人間が愛犬を蘇らせたいと依頼するのは、死んだ魂がまたその新しい体にも宿るかもしれないと期待しているからなのかもしれない。現在のクローンビジネスの大きなニーズは、優秀なハードウェア（生体）の大量生産ではなく、もはや人間の認知と哲学の世界にその価値がある。

昔、「どんなサービスが流行るか」という話を知り合いとして印象に残っているのは、 『AmazonやFacebookが流行ったのは、単に便利とかビジネスに役立つからというだけではなく、「モノを売るためには丁寧な接客なんか必要ではなく、大量の購入者のレビューと便利な配送があれば良い」「承認欲求が人の繋がりを大きくする」みたいな、従来の価値観や哲学に大きく影響を与えるような問いかけをするサービスだったから』と話していた。

クローンビジネスの倫理的な正しさはまだまだ議論すべきだが、クローンビジネスが本質的には「姿か魂か記憶か、人間は命の何に価値を見出しているのか」を問いかけるビジネスである以上、必ず大きなニーズがあって、正しいか正しくないかの前に流行るものだと思う。この問いかけへの選択が見たいという気持ちからクローンビジネスの今後にはすごく興味があります。

■「WEEKLY人工無脳」は、筆者がSNSや日頃の雑談で知ったネタを独断と偏見でまとめているブログです。
■「WEEKLY人工無脳」は、筆者がその話題を知ったタイミングでまとめているため、「記事公開自体は先月」といった可能性も十分にあり得ます。速報性よりも話題性を重視していることをご了承ください。（ですが、できるだけ直近の話題にフォーカスしてます。）
■「WEEKLY人工無脳」は個人の余暇で運営しているため、調べが足りないこともあります。誤りがあれば優しく教えてください。
■「WEEKLY人工無脳」は「独断ニュース（http://dokudan-weekly.hatenablog.jp/）」に刺激を受けて書き始めた、独断ニュースのデータサイエンス・人工知能業界版です。飽きるまで適当に続けます。