雑記: 東京タワーと内藤多仲先生の言葉
こんにちは。初めまして。新卒1年目の早川です。 私は大学院で宇宙物理学で博士号を取り、2020年4月からデータサイエンティストとして、働いています。
弊社のブログでは、技術的な話やビジネスに関することが多いですが、今回は弊社のオフィス周りに目を向けて記事を書くとします。 毎日なんとなく過ごしていると、身の回りのことを意外にも何も知らないということが結構あります。 そこで、私たちがオフィスから毎日見ている東京タワーにスポットをあてて、少し余談を。
東京タワー
弊社オフィスは、芝公園の近くにあります。地理に詳しい方はピンと来るかもしれないですが、東京タワーの足元です。 東京タワーは、1958年に世界一の高さを誇る電波塔として建設され、2011年 東京スカイツリーが建設されるまで、主要な電波放送の発進基地と利用されました。 また併設された展望台は、観光名所の一つとして知られ、令和時代に入ってもなお年間300万人以上の方が訪れています。 ところで皆さん、この東京タワーはどなたが建設されたかご存知でしょうか？
耐震構造の父 内藤多仲先生
東京タワーの設計者は、耐震構造設計の父とも呼ばれる内藤多仲先生です。 山梨県南アルプス市 (旧中巨摩郡榊村)出身、生涯に渡って、耐震構造設計の研究や、電波塔等の建造物建築に携わりました。 有名な話として、耐震構造設計への発想は、"荒海でも持ち運んだトランクが潰れずに残っており、そのトランクの中には間仕切り, 外は縄で縛られていた" ことから得られたと言われています。 当時の内藤先生の構造設計は相当に精緻なもので、60年以上が過ぎても凛として立っている東京タワーはそれを物語っています。 東京タワー以外にも、国内主要な電波塔(さっぽろテレビ塔, 博多ポートタワー等)、早稲田大学 大隈講堂, 新宿区役所、山梨県庁舎本館なども手がけています。
積み重ね 積み重ねても また積み重ね
内藤先生の生まれ故郷山梨県南アルプス市ですが、私の故郷でもあります。 内藤先生の信条や言葉は地元で語り継がれており、特に
積み重ね 積み重ねても また積み重ね
という句は地元の多くの人の支えにもなっている言葉です。 塔を立てるときと同じように、一つ一つのことを着実に丁寧にこなし完成させる。 日々の努力を怠らず、一つ一つ確実にこなして成長し、彼岸へ登りつめる。 仕事をしていく上でも、日々の日常生活をする上でも非常に大切な気概だと思います。
終わりに
データサイエンス業界はとても流れが早く、その技術や事業はどんどん深く、広くなっており、目指すものも盛大になってきています。 一方で、データを扱う多くの作業は地道なものも多くあります。 小手先だけで大きな目標を見失うこともあれば、大きな目標のために小手先が疎かになることもあります。 新卒1年目も終わりの節、初心に戻り、高登彼岸を目指したいものです。
弊社も大きなものを目指して、毎日成長を続けております。 一緒に積み重ね、大義を成し遂げたい方、ぜひ私たちと一緒に働きましょう。 お会いできるのを楽しみにしてます。
参考
分析官 早川朝康
連合学習によるプライバシー保護と利便性を両立した新しい機械学習システムのカタチ
深層学習が表舞台に登場してから、今年（2021年）で 9年 になるでしょうか。2012年のILSVRCという画像認識のコンペティションで、深層学習は2位以下に圧倒的な大差をつけて優勝しました。冬の時代を乗り越え、ニューラルネットワークが機械学習の中心に返り咲いた瞬間でした。
ILSVRCとは？
Stanford大学のLi Fei-Feiさんが中心となって管理する画像データベース ImageNet を利用して行われる画像認識タスクのコンペティションです。
www.image-net.org
深層学習システムはすでに至るところに社会実装されていて、例えば顔認識や音声認識、自動運転、画像・動画・文章などのクリエイティブの自動生成などはすぐに思いつきます。深層学習を始めとしたAIシステムはこれまでのヒトの仕事の一部を自動化することに成功していますが、まだまだ課題はあります。その中の一つにプライバシーの問題があります。
「鏡よ鏡、世界で一番美しいのは誰？」
一昔前であれば、ヒトの問いかけに的確に答えを返してくれる鏡なんておとぎ話でしたが、深層学習と安価で高性能なハードウェアが充実している2021年現在では、もはや1万円以下のリーズナブルなお値段で実現可能です。ただし、プライバシーの問題を解決しない限りはDIYの世界でとどまってしまいそうです。
DIYスマートミラー
例えば、Raspberry Piという小型PCで開発する場合は以下の記事が参考になります。
raspida.com
従来の鏡は今そこにいるありのままの自分を映すだけでしたが、各種センサーや深層学習を応用することで、鏡は将来を教えてくれたり、なりたい自分を指し示してくれる装置になります。
- 「鏡よ鏡、今日の天気は？」という問いかけで、気象情報やその日のおすすめの服装などをレコメンド
- 美容室に設置し、自分に似合う髪型をレコメンド
- ダンスの先生の動きをトレースし、自分との違いを教えてくれる
- 赤外線センサーを搭載することで、熱がないかどうかや、体調に異変がなさそうかを日々簡易チェック
スマートミラーは他にも色々応用はできそうですし、鏡だけではなくほかの身近な道具をスマートIoT化することでイノベーションが生まれそうな予感もあります。身近であるほどインパクトは大きいですが、その分、プライベートなデータを扱う必要がでてきます。
深層学習を始めとした機械学習システムが行っていることは、結局の所、過去の訓練データから入出力のパターンを抽出するということにつきます。特に深層学習のアーキテクチャは複雑で、何千ものパラメータをもっともらしく最適化するためには大量のデータが必要になります。そこで、ユーザーの行動履歴や画像ファイルなどを日々収集する仕組みが重要になるわけですが、現在のシステムの多くは、データは中央集権サーバーに集約して管理されています。機械学習モデルが直接参照するのは特徴量と呼ばれる生データとは異なる構造のデータで、ある程度プライバシーに配慮されたデータですが、特徴量の作成は何度も試行錯誤する必要があるタスクなので、異なるレイヤーで生データも保持されることが多いです。（もちろん、直接個人と紐づく可能性があるデータは非常に厳重に管理されていることは言うまでもないですが、一応付け加えておきます。）
自動車の運転データなどは企業に保持されてもそこまで拒絶反応はないかもしれませんが、例えば鏡に映った自分の姿を日々収集された場合はどうでしょうか？アパレルショップや美容室、ダンス教室などのパブリックな鏡であればギリギリ許容範囲の人もいるかもしれませんが、多くの人は自宅には設置したくないのではないかと思います。つまり、AIを生活のすみずみまで浸透させてスマートな社会を実現するには、プライバシーに配慮することが必要不可欠となります。
このような課題を解決するために、2017年にGoogleから連合学習（Federated Learning）という手法が提案されました。これは、従来のデータを中央集権的に集約・学習する機械学習システムとは異なり、システムの末端の端末（エッジ）で完結するアーキテクチャになるのがポイントで、ユーザーはプライベートなデータを企業のサーバーに送信しなくとも、機械学習システムの恩恵を得られるようになります。
連合学習（Federated Learning）
連合学習のスキームでは、中央サーバに親モデルを保有し、各エッジ端末に配布するところから始まります。配布されたモデルは各エッジのデータを利用して訓練・推論を行います。これだけでは親モデルは一向に改善されないので、訓練フェーズにて更新されたパラメータのみが各エッジから中央サーバに戻してもらいます。パラメータの差分のみから親モデルを改善する手法がいかに賢いかがパフォーマンスを左右します。
ai.googleblog.com
連合学習は、2022年に到来するクッキーレス時代とも深い関わりがあります。クッキーはWeb上でユーザを識別するデータとして広く利用されてきましたが、EUでは2018年にEU一般データ保護規則（GDPR）でクッキーは個人情報であると明確化され、EU域内の個人からクッキーを取得する際にはユーザに明示的に同意を得ることが義務付けられました。このような背景から、Googleは2022年にChromeのサードパーティークッキーのサポートを終了すると宣言し、広告業界には非常に大きなインパクトを与えました。Webの収益モデルとして広告は非常に大きな割合を占めるわけですが、これまでクッキーを利用してユーザを識別してターゲティングを行う手法も多く、代替案なしにクッキーを廃止することで広告事業主の広告収益が平均52％減少が予想されるとGoogleは報告しています。そのため、各社ファーストパーティクッキーの見直しやID統合などの取り組みも活発になっています。一方でGoogleは、ユーザのプライバシーを保護を前提としたWebエコシステムの構築を目指すプロジェクトPrivacy Sandboxを発表しており、その目玉のひとつにFLoC（Federated Learning of Cohorts）というAPIがあります。これは連合学習により行動履歴からユーザをコホート（群れ）に分類し、ターゲティングはそのコホートをベースに達成するスキームになっており、Googleの調査では既存の広告ターゲティングとほぼ同等のパフォーマンスを達成できるとしています。
プライバシーの問題とAIがもたらす利便性のバランスをとる動きは今後より活発になりそうです。現時点では連合学習の仕組みは世の中に浸透していませんが、５年後には「セキュアAI」などのサービス名で連合学習モデルを構築するためのプラットフォームが続々と出現しているのではないかと個人的には思っています。
Privacy Sandbox
www.chromium.org
大友
BigQueryのユーザー定義関数(UDF)を使ってみた
こんにちは！
アナリストのMです。
日々の業務でBigQueryに触れる機会が頻繁にあるのですが、 恥ずかしながら最近になってユーザー定義関数(UDF)なるものの存在を知りました(汗)
ちょっと使ってみて個人的にはかなり便利だと感じたので、 本記事ではUDFを使用したことがない人やそもそも何それ？状態の方向けにUDFの利便性や実装方法を簡潔に共有したいと思います。
ユーザー定義関数(UDF)とは？
ユーザー定義関数(UDF)は読んで字のごとく、ユーザー独自で定義する関数です。
頻繁に行うやや複雑な処理をSQLかJavaScriptを用いてUDFとしてあらかじめ関数化しておくことで、
以下のようなメリットが見込めるようになります。
・コードがすっきりする
・コーディングミスが減る
UDFには、1つのクエリで一時的に利用できる一時UDFと複数のクエリで再利用可能な永続UDFが存在します。 次節以降ではSQLを用いたそれぞれのUDFの実装方法を紹介します。
デモ用テーブルの準備
下記クエリを実行し、日付が3つのカラム([date_year],[date_month],[date_day])に分かれて整数型として格納されているテーブル"demo"を作成しておきます。
-- 空テーブルを作成
CREATE OR REPLACE TABLE `[プロジェクト名].[データセット名].demo` (
date_year INT64,
date_month INT64,
date_day INT64
);
-- 空テーブルにデータをインサート
INSERT INTO `[プロジェクト名].[データセット名].demo`(date_year, date_month, date_day)
VALUES
(2021, 1, 1),
(2021, 1, 2),
(2021, 1, 3)
一時UDFの作成方法
今回は年,月,日のカラムをもとに日付を生成するUDFとしてmake_date関数を実装し、"demo"テーブルに適用していきます。 下記がそのクエリです。
-- 一時UDFを作成
CREATE TEMPORARY FUNCTION make_date(year INT64, month INT64, day INT64) AS (
DATE(year, month, day)
);
-- "sales"テーブルで適用
SELECT
*,
make_date(date_year, date_month, date_day) AS date_ymd
FROM
`[プロジェクト名].[データセット名].demo`
"CREATE TEMPORARY FUNCTION"と表記することで一時UDFを作成することができます。 make_date関数の引数には"year","month","day"を設定し、それをもとにDATE関数を用いて日付を返すといった仕組みです。
実行すると、下記結果が返ってきます。
無事日付カラムが追加されていることが確認できました。
今回はSELECT文でUDFを使用しましたが、WHERE句から呼び出すことも可能なので、
例えば
1カ月前の日付を生成するUDFを用意
→WHERE句から呼び出して1カ月前のログを抽出
なんてことも簡単にできます。
また、下記のようにUDFから別のUDFを呼び出すことも可能です。
-- 一時UDFを作成
CREATE TEMPORARY FUNCTION make_date(year INT64, month INT64, day INT64) AS (
DATE(year, month,day)
);
CREATE TEMPORARY FUNCTION make_date_yesterday(year INT64, month INT64, day INT64) AS (
DATE_SUB(
make_date(year, month, day),
INTERVAL 1 DAY
)
);
-- "sales"テーブルで適用
SELECT
*,
make_date(date_year,date_month,date_day) AS date_ymd,
make_date_yesterday(date_year,date_month,date_day) AS date_ymd_yesterday
FROM
`[プロジェクト名].[データセット名].demo`
make_date_yesterday関数ではmake_date関数を呼び出し、1日引くことで前日の日付を返しています。
実行すると、下記結果が返ってきます。
永続UDFの作成方法
一時UDFを作成する際は"CREATE TEMPORARY TABLE"と表記しましたが、 永続UDFを作成する際は"CREATE TABLE"と表記します。
試しに先ほど作成したmake_date関数を永続UDFとして保存してみます。 下記クエリを実行すると指定したデータセット内にmake_date関数が永続UDFとして生成されます。
CREATE FUNCTION [データセット名].make_date(year INT64, month INT64, day INT64) AS (
DATE(year, month,day)
)
後は以下のように[データセット名].[関数名]といった感じで記述することで永続UDFを呼び出すことが可能になります。
SELECT
*,
[データセット名].make_date(date_year, date_month, date_day) AS date_ymd
FROM
`[プロジェクト名].[データセット名].demo`
さいごに
いかがでしょうか？
UDFをうまく使うことで、スムーズかつ正確なデータ処理が可能になるかと思います。
ぜひ試してみてください。
イノベーション企業の時代
データ利活用、AI、IoTなどの先端技術の利用によりイノベーション社会へと変革しつつある現代社会。企業の在り方も、変革が進んでいる。
旧来の考え方では、企業は今期の利益が最重要な指標である。一方、イノベーション企業では将来得られる利益の期待値が重要な意味を持つ。例えば、Teslaのような破壊的イノベーションを起こす可能性を示すことができる企業は大きなポテンシャルを持っているため、市場から評価される社会が到来している。
破壊的イノベーションのタネは誰でも持っているわけではなく、ビジネスｘ技術ｘ発想を揃えた人物がコアコンセプトを考え、プロトを作り、市場投入し評価を確かめ、ブラッシュアップしていく険しい道のりが待っている。
日々データを扱っているデータサイエンティストは、この機会に比較的恵まれているにも関わらず、分析に近視眼的に一生懸命になるあまり、現状の延長の発想で終わっている人が多いのも事実です。本体ならば、本質に立ち返り、破壊的なイノベーションを起こすタネをバランス良く考えておくのが、イノベーション企業での重要な過ごし方になります。
なお、全ての企業がイノベーションを起こそうとしているわけではなく、また、イノベーション企業の全部署でイノベーションを起こそうとしているわけではありません。従って、イノベーションを起こすチャレンジする機会に恵まれた環境に身を置くことは、自分の人生の選択に重要なことではないでしょうか？
イノベーションを起こすことにチャレンジしたい人、GRIで働く選択肢、アリだと思います
古幡征史
GASをいじっていて、ちょっと躓いた話
こんにちは！
分析官のMです。
最近、
「spreadsheetに記入したデータをGoogle Apps Script(GAS)を用いてGoogle Cloud Storage(GCS)に格納する」
仕組みを作っていたのですが、思わぬところで時間をとられてしまいました。
本記事では私がどこで躓いてしまったかを備忘録的にまとめています。
興味がある方は是非覗いてみてください。
結論から言うと...
「V8ランタイム対応前に作成されたライブラリはV8ランタイムに対応していない可能性があるので使用する際は注意が必要」
ということです。
実際に私がどのようなスクリプトを書いてどこで躓いたのか、もう少し具体的に説明します。
スクリプトの構成
スクリプトの構成は以下のような感じです。
Step-1 spreadsheetからGCSに転送したいデータを配列形式で取得
Step-2 配列形式から","区切りのテキストに変換
Step-3 一般公開されているライブラリを用いて認証（https://github.com/Spencer-Easton/Apps-Script-GSApp-Library）
Step-4 適当にファイル名(**.csv)をつけてGCSに格納
躓いた点
恥ずかしながら私はStep-3で躓いてました...。
ライブラリの使用例と比較しても同様のコードになっているのになぜかエラーの嵐。
https://github.com/Spencer-Easton/Apps-Script-GSApp-Library/blob/master/example.gs
色々ググっているうちに以下の記事にたどり着きます。
https://auto-worker.com/blog/?p=691
記事の内容は
「GASは2020年2月にV8ランタイム対応になって便利になったけど、いきなりバージョンアップするのは結構危険やで。」
といった内容。
ほうほう。
さらに読み進めてみると、
「V8ランタイムに対応していないライブラリはV8ランタイムではエラーになるで。」
というような文章が...。
自分：「あー、これが原因ぽいな...」
はい、その通りでした。
実際にGASの設定画面で
"Chrome V8ランタイムを有効にする"のチェックを外して再実行してみると、無事GCSにcsvファイルが格納されました。
とりあえず一件落着。
おまけ
GASをざっくり理解するには以下の動画がおすすめです！
https://www.youtube.com/watch?v=_fOfwvKm9zU
Airbyteを試してみた
Open SourceのETL（今のところExtract Transform LoadのうちExtractとLoadメインみたい）ツール、Airbyteを試してみました。TechCrunchでは、オープンソースのデータパイプラインプラットフォームとして紹介されていました。
用意されているSourceとDestinationを組み合わせて、スケジュールを実行の設定ができます。差分更新ができるコネクターが限られていたりはしますが、シンプルに散在しているデータをBigQueryってときとかは使えるかもしれません。
続きを読むTableauのLOD FIXEDは、SQLのWindow関数と同じか
TableauのFIXEDで、初歩的なところでハマったので共有します。
- FIXEDで集計したものをIIF文に入れて平均したものと、
- FIXEDの中身の時点でIIF文で条件を入れて平均したもの
は結果が変わります、という話になります。ちなみに私が元々やりたかったのは、後者でした。例えば、SuperStoreのサンプルデータで、顧客ごとの売上の平均を出したい。ただし、ロサンゼルスの顧客だけで集計したいみたいなときです。
続きを読む