こんにちは！Lead Engineerの筒井です！ここのところ業務でQuickSightを触っています。BIツールって一般的にそういうものなのか、結構癖があるものの、慣れてくると色々なことが実現できて面白さを感じています。 QuickSightには非常に良くできた デモサイト （後述）があるのですが、 QuickSightで表現したいことをどうやったら実現できるのかわからない時、ググったりQuickSightのForumを漂ったりした結果、最終的にこのデモサイトの「Tips & Tricks」に行き着くことが多くありました。そこで、どんなテクニックがそこで紹介されているのかを、あらかじめここにまとめておきたいと思います。 目次 デモサイト DemoCentralの紹介 Tips & Tricks解説 Interactivity - Dynamic Dimensions and Measures Calculation - Switch Date Aggregation Visual - Bar - Conditional Formatting Grouped Table / Pivot Table Headers Interactivity - Highlight selection across visuals まとめ デモサイト DemoCentralの紹介 まずはデモサイトについて簡単に紹介します。このサイトの位置付けとしては、AWS社の従業員の方が事例紹介として社内外に共有するためのデモサイトのようです。 DemoCentral - https://democentral.learnquicksight.online/ Why bring content to DemoCentral? （なぜ DemoCentral にコンテンツを提供するのですか？） You will be able to easily share your awesome dashboards with wider team and customers alike. （あなたの素晴らしいダッシュボードを、より多くのチームや顧客と簡単に共有することができます。 ） デモサイトには「Tips & Tricks」以外にも、QuickSightのさまざまな機能を活用したダッシュボードやビジュアルが掲載されています。単なる機能の説明ではなく、実際にどう活用できるのかの例を見ることができるため非常に勉強になります。ダッシュボードとして完成された例も多数掲載されており、自分が作ったダサダサなダッシュボードに比べてこんなにイケてるものが作れるのかと驚きました。 以下の画像は掲載されているいくつかのダッシュボードのスクリーンショットです。非常にイケてますね。 さらにこのデモサイトでは、編集モードに入って、実際のデータを見たり、ビジュアルを変更したりすることで理解を深めることができます。この利用者ごとに独立した編集環境は1時間で有効期限が切れるので、その際はブラウザでデモサイトを再読み込みする必要があります。この辺りの使い方は、デモサイトサイドメニューの「Help」から確認することができます。 Tips & Tricks解説 Interactivity - Dynamic Dimensions and Measures 概要 ビジュアル内の集計（分類/項目）や値に利用するフィールドをインタラクティブに切り替える方法です。 例えば積み上げ棒グラフでは、X軸またはY軸による分類、色による分類、データの値それぞれのフィールドを指定してグラフを作ります。ある特定の分類方法で特定の値を見たい場合や、その組み合わせがそれほど多くない場合には、フィールドが固定のビジュアルを作成すれば良いのですが、利用者が多くの項目から切り口を選んで見られるようにしたい場合には、この方法が便利です。 やり方の解説 「指定されたフィールドの値を返す計算フィールド」を追加し、そのフィールドを利用することで目的を達成します。 デモのビジュアルのY軸に指定されたフィールドは、 DynamicDimension1 です。このフィールドはラジオボタンの選択状態によって、下図のような値をとります。 具体的には、「Salesperson」が選択されているときは Salesperson フィールドの値、「Segment」が選択されているときは Segment フィールドの値です。 ラジオボタンの選択状態はパラメータの値として取得できるので、計算フィールドの数式上でifelse関数により分岐することで実現できます。 このようにすることで1つのフィールドをY軸に設定したまま、利用者が分類に使う項目を指定することができるようになります。色による分類や、データの値についても同様です。 // DynamicDimension1 ifelse( ${pDimension1} = 'Segment' , Segment, ${pDimension1} = 'Salesperson' , Salesperson, Salesperson ) Calculation - Switch Date Aggregation 概要 日時による集計単位（時間ごとの値のグラフ、日ごとの値のグラフなど）をインタラクティブに切り替える方法です。 集計に使うフィールドが日時データの場合、ドリルアップやドリルダウンを利用することで集計単位を切り替えることも可能ですが、 日 ⇔ 週 ⇔ 月のように1段階ずつドリルアップ・ドリルダウンする必要がある ドリルダウン時に表示期間が変わってしまう（週を選択してドリルダウンした場合は、その週が表示期間になる） 時、日、週など決まった単位でしか集計できない（2時間ごと、半年ごとなどはできない） ドリルアップ・ドリルダウンの概念と機能を利用者が理解し、適切なデータポイントを見つけてクリックする必要がある など、いろいろな理由から不便な場合があります。 そこで、あらかじめ集計単位を選択肢として用意して、その内容に応じて表示を切り替えようというものです。 さらにこの方法を応用すると、例えばチーム番号のような日時とは関係のない項目を集計に使用したり、それらを組み合わせたりすることも可能です（この場合はフィールドの型を日時でなく文字列にする必要があるので注意が必要です）。 やり方の解説 「指定された集計単位に応じて、そのレコードが属する日時を返す計算フィールド」を追加し、そのフィールドで集計することにより目的を達成します。 デモのビジュアルのX軸に指定されたフィールドは、 Datefield です。このフィールドはラジオボタンで選択された値（ Periodstarting ）によって、下図のような値を取ります。 具体的には、「Day」が選択されているときは Admit Date フィールドそのもの（時刻情報をドロップ）、「Month」が選択されているときは Admit Date フィールドの月初の日付といった値を取ります。 // Datefield ifelse( ${Periodstarting} = 'Day' , truncDate( "DD" , { Admit Date } ), ${Periodstarting} = 'Month' , truncDate( "MM" , { Admit Date } ), ${Periodstarting} = 'Quarter' , truncDate( "Q" , { Admit Date } ), truncDate( "YYYY" , { Admit Date } ) ) 値は集計ごとの合計値が指定されているため、 Datefield の各日付ごとに集計された合計値がグラフに表示されることになります。 Visual - Bar - Conditional Formatting 概要 棒グラフにおいて、各項目の値によってバーの色を変える方法です。 テーブルやKPIなど一部のビジュアルでは条件付き書式によって色を付けることができますが、棒グラフではそれができないため、このテクニックを利用します。 また、このデモではその閾値を利用者がインタラクティブに変更できるようになっています。 やり方の解説 積み上げ棒グラフにおいて、各項目の値が1色になるように色の分類を設定することにより目的を達成します。 デモのビジュアルではX軸に Salesperson フィールドを指定し、値として Weighted Revenue の合計値を利用しているため、「 Salesperson で集計した Weighted Revenue の合計値が指定された閾値よりも大きいかどうかを表すフィールド」として Bar Color を追加し、それを色の分類に使用しています。 // Bar Color ifelse( sumOver( { Weighted Revenue } , [ Salesperson ] , PRE_AGG) > ThresholdValue, 'Above threshold' , 'Below threshold' ) Grouped Table / Pivot Table Headers 概要 テーブルにグループでまとめたヘッダをつける方法です。また、このデモではグループごとにセルに色をつけています。 やり方の解説 これは固有のテクニックではなく、レイアウトをフリーフォームにしてInsightビジュアルを重ねているだけです。また、セルへの色付けは、単に条件付き書式を使用しています。 Insightビジュアルでは、各数値や集計結果を表示することも可能ですが、数値を使わずにただの文章を表現することが可能です。フリーフォームレイアウトを選択できる要件であれば、このテクニックを応用して、さまざまなリッチな表現を実現できます。デモサイトのダッシュボードでもこのテクニックを利用している例があります。 Interactivity - Highlight selection across visuals 概要 ビジュアル上のデータをクリックすることでそのデータを色やサイズでハイライトし、さらにビジュアルをまたいでそのハイライトを連動させる方法です。 やり方の解説 ナビゲーションアクションを使い、ビジュアルのデータクリック時にパラメータを指定（して同じシートに遷移）することにより目的を達成します。 テーブルの色付けには条件付き書式、棒グラフの色付けには Visual - Bar - Conditional Formatting と同じテクニックを使用しています。また、散布図のマーカーのサイズは、「countryフィールドの値がパラメータの値と同じであれば 10 、そうでなければ 0.5 となるフィールド」として SelectedCountrySize を追加し、その値を使用しています。 // SelectedCountrySize ifelse( ${pSelectedCountry} =country, 10, .5) まとめ 今回はまずPart 1として、QuickSightデモサイトのTips & Tricksの中から実際にプロジェクトで利用したものを中心にいくつか解説しました。またの機会にこの続きとして他のテクニックについてもまとめていきたいと思います。

こんにちは。InsightEdgeのDataScientistのSugaです。サウナ内で立ち昇った蒸気をタオルなどであおぐことをアウフグースと言いますが、そのアウフグースをやる熱波師の試験を山梨県まで行って受けて来ました。今回は最近よく耳にするAutoMLについて調べた記事を書いたので、お時間がある方は読んでもらえれば幸いです。 目次 背景 論文調査 どんなことに注目しているか？ 次のAutoXXは何か？ まとめ 背景 1st International Conference on Automated Machine Learning が2022年7月22日に開催されました。機械学習を自動化する専門家の集まりの国際会議です。特にオープン性に重きが置かれていて、ソースコードが公開されていることや学術会だけでなく企業からの参加も多いです。今回は最新のAutoMLの研究者はどんなことをテーマにしているのかを調査してみることにしてみました。本記事の内容としては論文の詳細には踏み込まずに現在の研究者がどんなことに関心があるのかを中心に紹介して行こうと思います。また、会議の企画として4つのAutoMLに関する4つコンペも開催されました。 論文調査 素晴らしいことに全ての解説がYoutubeにアップロードされています。論文のリンクもそこからたどれます。オープン性を重視する試みとして素晴らしいと思います。Main Trackを中心にどんな論文があるかを紹介します。 What to expect of hardware metric predictors in NAS (論文) (動画) ニューラルネットワークアーキテクチャ探索(NAS：Neural Architecture Search)の話題。ニューラルネットワークの最適な構造を探索する分野であり、一般的なニューラルネットワークの構造を探索すると莫大な計算機リソースが必要になります。今回の論文では、ハードウェアを意識した探索に限定しています。近年は、RaspberryPi/FPGA/TPU/GPU/iPhone/Pixelなど様々なハードウェアのデバイスが登場してきていて、ハードウェア構成によって、精度と推論速度のトレードオフを考える必要があります。この研究では計算機リソースを使って、実測値を得るよりも、予測モデルを使って各ハードウェアがどの程度の性能を出せるかを高速に推定することが有用だと主張しています。さらに予測値を出す際の予測モデルの比較も行っています。 Differentiable Architecture Search for Reinforcement Learning (論文) (動画) NASの領域は(1)ニューラルネットワークの層構成などアーキテクチャを最適化する領域、(2)ハイパーパラメータのチューニング、(3)学習(重みの最適化)のいづれかであり、どの領域を議論しているかを意識する必要があります。以前のNASの研究では、探索対象は非連続的な離散空間に限られていて、強化学習(RL:Reinforcement Learning)を用いて最適化をしていましたが、これには多くの計算機リソースが必要でした。そこで、DARTS(Differentiable Architecture Search)と呼ばれる手法が誕生して、離散空間探索を連続的な空間探索に緩和することで、アーキテクチャ探索を微分と勾配降下法に落とし込むことが出来るようになりました。この論文では、強化学習を対象としたNASにおいてDARTSは適用可能か？という疑問を出発点として、DARTSが強化学習でも機能するかを研究しています。結果として、DARTSを用いた場合はランダム探索に比べて、30倍の効率性があると主張しています。 Open Source Vizier: Distributed Infrastructure and API for Reliable and Flexible Blackbox Optimization (論文) (動画) オープンソースのハイパーパラメータ最適化エンジンについての論文。VizierはGoogleで既にデファクトで使われていて、サービス化もされています。Google Cloudのbackendにも使われているもので、それのOSS版についての紹介をしています。ブラックボックス最適化(BBO:BlackBox Optimization)をするエンジンであり、イメージとしては具体的な目的関数がわからなくても、ある入力に対する出力がわかれば、最終的にはそこそこ良い結果を出すという最適化手法のことです。代表的な手法としてベイズ最適化があります。このようなメタヒューリスティクスな手法がとられる理由として、実際の問題は、凸性などの解析的情報が不明であるので数理最適的アルゴリズムを使用できない場合が多いからです。応用例として、機械学習のハイパーパラメータ最適化、物理システムの最適化、創薬におけるタンパク質構造の最適化、強化学習などがありかなり広範な用途があります。 さらに詳細なVizierについての論文は ココ で紹介されています。 面白いエピソードとしては、最適化クッキー(machine learning cookies)があります。重曹、ブラウンシュガー、ホワイトシュガー、バター、バニラ、卵、小麦粉、チョコレート、チップタイプ、塩、カイエンヌ、オレンジエキス、焼成時間、焼成温度などをパラメータ化して、レシピ空間から最も美味しいチョコレートチップクッキーレシピを見つけることを実験したものです。パラメータの変更を慎重に記録して、焼き上がったクッキーを試食してもらい、その結果をアンケートで集計します。アンケート結果が良くなるように、レシピのパラメータをVizierによって変更するとことで美味しいチョコチップクッキーを作る実験をしました。 A Tree-Structured Multi-Task Model Recommender (論文) (動画) マルチタスク学習についての論文。マルチタスク学習は複数のタスクを同時に解決するための学習モデルです。例えば、動物の分類問題を考えたときに、主タスクとして「犬種の分類」をして、補助タスクとして「耳の形状分類」を設定する。独立にタスクを学習する場合と比べて、コストを削減できるメリットがあります。一方でうまくいく場合と行かない場合があります。タスク干渉して精度が劣化する場合もあれば、タスクに共通な特徴が選ばれることで精度が向上するという主張もあります。この論文ではツリー構造型マルチアーキテクチャ(部分共有アーキテクチャ)に関するもので、アーキテクチャ探索を容易にするため、精度推定をして、最も高い予測精度を持つアーキテクチャを推薦することを目的にしています。 LassoBench: A High-Dimensional Hyperparameter Optimization Benchmark Suite for Lasso (論文) (動画) 高次元のデータで統計モデルを行おうとする場合、大量の未知のパラメータを含むことになり、解釈や推薦が難しくなります。このとき、高次元データのスパース性(イメージとしてはデータ中にゼロがたくさんあるもの)を使って、未知パラメータを0と推定することによってモデリングする手法をスパースモデリングと呼びます。スパースモデリングのLasso回帰では高次元のハイパーパラメータを持つため、高次元ハイパーパラメータ最適化(HD-HPO)が必要となります。この論文では、技術向上のプラットフォームとして、この研究のためのベンチマークを紹介しています。 YAHPO Gym -- An Efficient Multi-Objective Multi-Fidelity Benchmark for Hyperparameter Optimization (論文) (動画) ハイパーパラメータ最適化／ブラックボックス最適化手法のベンチマークについての論文。表データや画像データに関して多様なシナリオが含まれています。 Tackling Neural Architecture Search With Quality Diversity Optimization (論文) (動画) 特定の条件下でのニューラルネットワークアーキテクチャ探索(NAS)についての論文。多目的な状況を想定していて、例えば、スマホとPCの両方に最適化したものを探すような場合です。このときに、品質と納期の条件を満たすような探索をする方法を提案しています。 Non-Uniform Adversarially Robust Pruning (論文) (動画) ニューラルネットワークは冗長性が高いので、精度を維持しながらモデル圧縮することが出来ます。エッジデバイスなどの容量が限られた中に実装するため、重みの一部を取り除くことによって、計算量とメモリを削減します。この技術はPruningと呼ばれます。重みを取り除くとデメリットとしてロバスト性も低下します。つまり外部からの影響を受けやすくなってしまいます。この論文では圧縮方式を提案していて、圧縮率とロバスト性の最適なトレードオフを決定する方法を述べています。 Bayesian Generational Population-based Training (論文) (動画) 強化学習のハイパーパラメータとアーキテクチャの最適化についての論文。AutoRLの領域ではPopulation-Based Training(PBT)という学習手法がとらますが、そのPBLを改良するための手法を紹介しています。 DIFER: Differentiable Automated Feature Engineering (論文) (動画) 特徴量エンジニアリングに関する論文で、自動特徴量抽出(AutoFE:Automated Feature Engineering)では離散空間の最適化問題として扱われるため、特徴量の爆発(数が膨大になること)や計算効率の低下といった問題があります。そこで連続ベクトル空間にエンコーダを用いて特徴量を写像して最適化を行います。(※基本的なアイディアは前述したDARTSと同じく、離散空間を連続空間にすることで扱いやすくするものです) Syne Tune: A Library for Large Scale Hyperparameter Tuning and Reproducible Research (論文) (動画) 大規模分散ハイパーパラメータ最適化(HPO)ライブラリについての論文。基本的にはユーザーが実験しやすくするためのツールの紹介です。 AutoCoG: A Unified Data-Modal Co-Search Framework for Graph Neural Networks (論文) (動画) Graph neural network(GNN)はグラフで表現したデータを入力とするようなニューラルネットワークのことです。グラフとはノードとエッジの集合からなるデータのことで、通信ネットワークやインフラのネットワークやSNSでの関係など、さまざまなところで利用されています。この論文では、GNNにNASの考え方を導入してGNNモデルアーキテクチャの最適化や入力グラフの最適化を行うことを提案しています。 Meta-Adapters: Parameter Efficient Few-shot Fine-tuning through Meta-Learning (論文) (動画) GPT-3(言語モデル)、Visual Transformer(画像認識)など大規模な学習済みモデルをfine-tuneするだけで目的にあったタスクを実行できるようになりました。このときに、モデル全体のパラメータをfine-tuneするのは現実的でないので、少量の追加パラメータを導入するとでfine-tuneする方法があります。ただし、この場合でもfine-tuneするにはタスクに応じた大量の学習データが必要になります。この論文では、メタ学習の考え方を導入して、タスクに応じた学習データが少量だった場合の効率的なfine-tuneの方法を提案しています。メタ学習とは、他のデータから「学習の仕方」を学習する方法で、例えば、英語とスペイン語を話せる人がドイツ語を学習する状況を考えてみます。過去に言語学習の経験があり、言語学習の仕方を学習しているので、ドイツ語習得も速くなるという場合です。提案手法を用いることで、0.6%のパラメータをfine-tuneするだけで、全体のパラメータをfine-tuneするのと同等の性能を得られました。(GPT-3では1750億個のパラメータがあるので、全体パラメータをfine-tuneするにはかなりの計算機リソースを必要とします) When, where, and how to add new neurons to ANNs (論文) (動画) ニューラルネットワークの重みを取り除く論文を紹介しましたが、こちらの論文はその逆でニューロンを追加するときの最適化について論文です。ニューロンを追加するタイプの問題に比べてまだまだ研究が未発展な分野です。 Automatic Termination for Hyperparameter Optimization (論文) (動画) ベイズ最適化(BO)は、機械学習におけるハイパーパラメータ最適化(HPO)の手法として広く普及しています。ベイズ最適化の計算内容としては、候補となる構成を繰り返し評価することになります。この繰り返し階数はユーザーによって固定で決められています。このとき、最適な終了条件を事前に得られることはできないので、一定の終了基準が必要となります。この論文では、精度と最適化に要する時間の間のより良いトレードオフができるような終了基準を提案しています。 BERT-Sort: A Zero-shot MLM Semantic Encoder on Ordinal Features for AutoML (論文) (動画) データ前処理の一般的な処理として、カテゴリ変数を数値変数としてエンコードすることがあります。通常はLabelEncoderなどの関数を用いて実装されます。しかし、多くの場合、カテゴリ値の間に以下のような意味的な順序関係が存在します： 品質レベル('very good' > 'good' > 'normal' > 'poor') 月('Jan' < 'Feb' < 'Mar') この論文では、Zero-shot Masked Language Models (MLM)を使用して、順序カテゴリ値を意味的に符号化する新しいアプローチを提案しています。 Automated Super-Network Generation for Scalable Neural Architecture Search (論文) (動画) 重みを共有するタイプのニューラルネットワークアーキテクチャ探索によって学習済みのモデルのスループットを向上させる方法を提案しています。順序としては、学習済みモデルをスーパーネットワークに変換します、次にサブネットワークに分割します。その後、スーパーネットを学習してから最適なサブネットワークを探索します。事前に学習させたTorchvision ResNet-50（FP32）と比較して、スループットを最大9.87倍向上させたとのことです。 ScaleNAS: Multi-Path One-Shot NAS for Scale-Aware High-Resolution Representation (論文) (動画) マルチスケールな特徴量を持つニューラルネットワークに関するNeural architecture search (NAS)の論文。低解像度と高解像度が混在した場合、学習や最適なアーキテクチャを選択するのが難しいが、このようなときでも最適なアーキテクチャを生成できると提案しています。 Opening the Black Box: Automated Software Analysis for Algorithm Selection (論文) (動画) アルゴリズム選択についての論文だが、直接的にアルゴリズム選択に関する話題ではなく、アルゴリズムそのものについて議論しています。アルゴリズムのソースコードの抽象構造木(AST)を生成して、グラフ構造を解析して定量化しています。その定量化した情報をSAT solversを使って解析して選択する手法のようです。 On the Optimality Gap of Warm-Started Hyperparameter Optimization (論文) (動画) 既にHPOを実行したソースデータセット（タスク）があり、そのHPOの結果を利用して、未知のターゲットデータセットに対してHPOを行います。この場合、warm-startedしたHPOと呼ばれる。さらにfew-shot HPOという条件もありHPOの数回が制限された状態で最適化を完了させる状況を想定しています。ここでもメタ学習という概念が出てきます。つまり以前にHPOした経験から学習して、warm-startedしたHPOに活用するものです。 どんなことに注目しているか？ ここまでは、メイントラックの論文を紹介してきました。現状でAutoML Conferenceでは以下のようなテーマに注目していました。 ニューラルネットワークアーキテクチャ探索(NAS：Neural Architecture Search) ニューラルネットワークは機械学習の分野では大きな割合を占めているので、やはり関連する論文の数は多くなりました。工夫の方向性としては、特定の条件下での最適化をする手法がありました。(ハードウェア、マルチタスク学習、重みの一部を取り除く、ニューロンを加える、fine-tuneをするとき、グラフデータ) また、最適化そのものを効率化する方法も研究されていました。このときの発想としては、扱いやすい形に変換することで探索を効率化するというものが多いように感じました。 ハイパーパラメータ最適化(HPO:Hyperparameter Optimization) こちらもかなり大きな研究分野であり、主にはベイズ最適化を用いる手法がほとんどでした。こちらは研究の方向性としても特定条件下での探索をしやすくするものが多く、実際に計算機を使って探索をするので、その過程で起こった課題に対してアプローチしていました。大規模でやる場合、強化学習に関連するものや高次元データでの最適化、既に実行した結果があるとき、最適な終了条件を探索するものなどがありました。 ツールとベンチマーク 研究で提案する手法にメリットがあるかどうかを測定するため、自らベンチマークを作って評価しています。新しい研究分野をやる場合はそもそも評価軸自体が未知であり、ベンチマーク自体も開発する必要があります。また、最適化の結果を測定するためのツールも必要で、これも自らの研究の過程で必要になって作られる場合が多いように感じました。 次のAutoXXは何か？ AutoMLはAutomated Machine Learningですが、紹介した論文の中にはAutoXXというキーワードが含まれていて、AutoMLの次には以下のような分野が派生していくのではないかと思います。 AutoRL(Automated Reinforcement Learning) 強化学習を対象とした自動化技術。ニューラルネットワークを使った深層学習の発展として既に研究がされている分野ですが、強化学習のアーキテクチャ探索を強化学習を使って行うなどの面白い研究もされています。 AutoFE(Automated Feature Engineering) 特徴量に関しての自動化技術であり、特徴量生成や特徴量選択など最適化技術を使うことで効率化できる余地が多いように思われます。 AutoGN(Automated Graph Neural Networks) グラフデータは自然言語や画像に比べてまだまだ発展の余地がありそうです。グラフデータ以外のデータ種類に対しても自動化技術が発展すると思われます。 AutoMM(Automated Multimodal) AutoGluonの生みの親である、Alex Smola氏がキーノートセッション Keynote by Alex Smola で講演していましたが、その中では、AutoMM(Automated Multimodal)というキーワードがありました。 こちらは、テーブルデータ、自然言語、画像データといった複数種類のデータをAutoMLによって学習する手法であり、これまではMultimodalAIという分野の研究はあったが、AutoML分野が各分野と融合することでさらに発展するのではないかと思われます。 まとめ これまでの内容で、最新のAutoML Conferenceについてメイントラックを中心にトレンドを紹介してきました。第1回の開催ということもありこれまでは各分野で研究されていたものが、新しいジャンルのAutoMLとして集まった形です。今後はAutoMLから派生した個別の自動化技術が研究されて、新しいジャンルが発展してくことが期待されます。

こんにちは。Insight Edgeカクテル大好きDeveloperのntです。カシスのソーダ・ベリージュース・オレンジジュース割が好きで、美味しいならと思って全部混ぜてみたところなんとも言えない気持ちになりました。今回は お酒 Google Apps Script(以下GAS)を使って機能開発する案件に携わったので、ちょっとしたコツをご紹介します。 お酒を飲みながらは開発していません。 目次 本書の意義 本書の対象者 本書で触れないこと イントロ ビジネス・業務課題の確認 システム課題整理 本編 GASで複数ユースケース規模の開発方法 開発環境と本番環境の分離方法 環境変数・シークレット情報の管理方法 本番環境へのデプロイ方法 MVP開発し終わった感想 今後の展望/できなかったこと まとめ 本書の意義 GASをGoogle Sheets（旧Googleスプレッドシート）と組み合わせてツール開発するケースが多いと思います。 個人的なGASの経験はWebエディタで1ファイルくらいのちょっとしたツールを書いたくらいで、ある程度の規模になると効率的に開発できるようにしたいですね。GAS開発で共通に使えるやり方なので、GAS開発に携わる人は一読です。 計算処理の実装はGASとGoogle Sheetsをどう使い分ければよいかの指針がわかる ローカルで開発したコードを簡単にGASにdeployできる 本番環境のGASにGitHubのブランチからデプロイできる 環境設定をどこに配置すればよいかの参考がわかる 本書の対象者 GAS開発でコードをどうデプロイすれば良いか知らない人、安定したデプロイを行いたい人 本書で触れないこと ビジネスや業務課題・実装の詳細 Google SheetsやGASの仕様 JavaScriptなどプログラミング言語の詳細 イントロ ビジネス・業務課題の確認 とある事業の担当者と会話し、As-Isをヒアリングしたところ、事業の運用者は、日々、経験で予測し最適値を決めているということがわかりました。To-Beをすり合わせした結果、以下を目指したいということです。 システムは、時系列予測・数理最適化・可視化をする。 可視化のイメージサンプルはExcelで作ってある 運用者は、予測結果と最適値を確認したい 元データは外部システム（API連携）と、BigQueryにある そこで、システムが自動で外部データを取得、予測し、最適値を探索できるようにすることで、業務課題の解決を目指します。 システム課題整理 システムを作るにあたり、基本方針を検討します。 まず、利用者は事業会社のユーザで、技術の専門家ではありません。予測アルゴリズムを不透明かつ複雑な仕組みにしてしまうと、価値を感じてもらえないリスクがあります。そこで、データ/アルゴリズムを可能な限りユーザの見えるところに配置します。その結果、ユーザが自力で確認できるので、システムの説明責任を果たします。 ところで、要件確認はExcelのサンプルで行ったのですが、ユーザはExcelであれば計算の流れを確認できるようなので、今回作るシステムも表計算をベースとするのが良いと考えました。ExcelならGoogle Sheetsへ移行作業もしやすく、かつ、ユーザは自力で詳細を確認できるのでお互いハッピーでしょう。 Google Sheetsなどの表計算でやりきれないETL処理もあるので、それに関してはクラウド型のGASで記述・実行すれば開発・実行できるようになります。 使い分けの指針は以下のとおりです。 シンプルな計算処理はGoogle Sheetsで実装する。複雑なことをするとユーザだけでなく開発者もわからなくなって保守しづらくなるのでやめましょう。 外部データ連携やデータ加工などシンプルに行かない処理はGASで実装する。今回の要件ではバッチ処理で良いため、データの保存もGoogle Sheets上に保存してしまえば良いので、結合もシンプルです。 さて、方向性は固まったものの、システムを作るにあたり大きく以下のような課題がありました。いずれもGASで開発したことがないゆえですが、業務課題の解決のために1つずつ解決していこうと思います。 太字は今回の記事で紹介する対象 です。 GASで複数ユースケース規模の開発方法 開発環境と本番環境の分離方法 環境変数・シークレット情報の管理方法 本番環境へのデプロイ方法 BigQueryとの認証・連携方法 スケジューラを用いて特定時刻になったらバッチ処理の実行方法 最適値探索の方法 本編 前置きが長くなりましたが、システム化の課題について1つずつ見ていきます。 GASで複数ユースケース規模の開発方法 今回、大きく4つの機能を実現することになりましたが（具体的には外部システム（API連携）やBigQueryから元データの取り込み、最適値の探索、自動実行制御）、ちょっとしたツールよりは大きめの実装になります。さすがにWebエディタだけで開発するのはしんどいです。ローカルIDEで書いて、ソースコードのディレクトリ構造をつくり、Gitでソース管理したいですね。 ここでは Clasp というツールを使い、ローカルで書いて、クラウドにpushして動作確認ができるのでやってみました。前提として、Google Sheetsと、それに紐づくGASが作成済みとします。 claspをインストールします。 npm install -g @google/clasp 次にCLIツールがクラウドリソースにアクセスできるようにログインします。 clasp login ログインができたら、GASのスクリプトを手元にクローンします。そうすると、GASのWebエディタで .gs 拡張子のファイルが、手元では .js に変換されてダウンロードされます！ clasp clone " XXXXXXXXXXXXXXXXXXXXXX_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX " # <GASのScript ID> ソースコードを書いたら、pushコマンドを実行してアップロードし、GASのWebエディタを開きます。すると、今度は手元の .js ファイルが、 .gs としてアップロードされています！ clasp push なお、ファイルを保存したら自動で変更を検知してpushしてくれるwatchオプションが便利です。デプロイが楽でいいですね。 clasp push --watch さて、開発を進めていくとコードがそれなりに大きくなり、リファクタリングし、ディレクトリを切りたくなります。どうなるでしょうか？例えばローカルで ./repo/BigQueryService.js として、 clasp push すると「 repo/BigQueryService.js 」というファイルができます。なんとファイル名にスラッシュが含まれます。。Webエディタ上では少し見にくいですが、意図はわかるので良いとしましょう。 また、 GASはファイルの並び順で実行されるので、並び順によって挙動が変わります 。グローバルに定義や関数実行しないように、注意して記述する必要があります。 clasp側で並び順の変更もできますが、使う必要のないように開発すると良いでしょう。 ここでのポイントは、「便利なのでGASなら全部claspでデプロイすれば良い」だと思いますよね。違います。「 claspでのデプロイは開発環境だけにしておくと良い 」です。理由は、環境切り替えの手間や、編集中の意図しないコードを本番にアップロードしたりとトラブルリスクがあるので、claspを本番で使うのはやめましょう。なお、失敗談としては .claspignore のルールを間違えて巨大な node_modules ディレクトリをアップロードしようとしました。いつまで経ってもアップロードが終わりませんでした。簡単に変更できるのは良いですが、それが本番環境だと怖いですね。 開発環境と本番環境の分離方法 素早く形にして、本番に反映し、ユーザに使ってもらいながら開発することになります。そうなると、環境を複数用意しておく必要があり、つまり環境分離を考える必要があります。 前提として、GASはGoogle Sheetsにコンテナバインドされています。スタンドアロン型ではないです。 Google Sheetsを2つ用意するのは当然として、Google SheetsにGASが紐付いてしまっているので、GASも2つ用意することになります。 ファイル名に開発とか本番であることがわかるように、Google SheetsとGASそれぞれのファイル名に識別子をつけておきましょう。例として「XXX_dev」「XXX_prod」のようにsuffixをつけると良いです。 環境変数・シークレット情報の管理方法 イケてる変数管理方法があるかと期待したのですが、GASにシークレットストアはなかったです。また、 GASのプロパティサービス （スクリプトプロパティ、ユーザプロパティ、ドキュメントプロパティの3種類）はあるものの、読み書きのクォーターがPJ全体で適用されてしまいます。 他のPJの影響によってサービスが落ちてほしくないです。無償版だと50k/日のクォータ割当なので、不安ですね。1実行あたりの読み書きするプロパティの数×実行数×環境数×PJ数でリソースを消費していくのであれば、消費状況を管理できないまま不足しますし、リソース状況の監視もできればしたくないです。よって、プロパティサービスは基本的に使わないほうが良さそうです。 暫定的なやり方になりますが、考えられる方法はプロパティをソースコードで変数として静的に管理することです。そして、スクリプト実行時に、スクリプト自身の環境名（ファイル名やプロパティを参照）から多数の設定変数を選択・参照するのが良さそうです。 本番環境へのデプロイ方法 上記でも述べましたが、本番環境はきちんと確実にデプロイしたいですね。繰り返しますが、本番ではclasp pushを使いません。その代わりに、安全にデプロイできるChrome拡張を使います。 前提として、デプロイに使う開発者のブラウザはChromeとし、ソースコードはGitHubにあるとします。まず、 Google Apps Script GitHub アシスタント をインストールします。 次に、GASのWebエディタを開くと、拡張機能がアドオンされているので、そこから設定をしていきます。 拡張機能がGitHubにアクセスするためのAccess Tokenの発行を求められるので、GitHubで生成します。そして、拡張機能でGitHubユーザ名とGitHubのAccess Tokenを入力してログインします。 ここで、 .js でソースコード管理している場合は、設定アイコンから Sync Type を .js にします。そうしないとGitHub上のファイルを認識せず、デプロイできません。 最後に、プルダウンからGitリポジトリとブランチ名を選択し、「↓」アイコンをクリックします。現行のWebエディタと最新のGitHub間のソースコード差分が表示されるので、変更を確定します。するとWebエディタが自動でリロードされ、最新のソースコードに置き換わります。変更内容が明確なので、確信を持ってデプロイできて安心ですね。 MVP開発し終わった感想 ここまでのシステム課題に対処しながらGAS特有のシート操作などを記述し開発しました。実装詳細には触れませんが、簡単に言うと一般的なソフトウェア開発同様、迷子にならないようにディレクトリ・ファイル設計をしておきました。ユースケースごとにファイルを分け、詳細も別ファイルの関数に切り出して定義しておきました。その結果、1週間ぶりのコード修正や新規機能追加であってもスムーズに開発できました。 動作確認はありきたりな方法で行いました。Google Sheetsと結合しているのでローカルだけで確認...は難しいですね。Webエディタで関数ごとに実行して動作確認しました。claspを使えばローカルから関数の発火は可能らしいですが、試していません。 GAS開発でデバッグ実行はつらく、生産性は高くないです。Webエディタではブレークポイントを仕掛けてデバッグ実行し、コールスタックと変数状態が見える程度であり、デバッグコンソールがないのは致命的です。また、ローカルIDEでデバッグできるとより理想的です。 今後の展望/できなかったこと 細かくなるので省こうと思いましたが、同じ問題にぶつかる人がいると思い、メモ書きを記載します。良い対処法があれば教えてください。 Google Sheets本体のマスタ管理・デプロイ 標準機能でバージョン管理はできるが、単体ファイル向けであり、環境を分けると別ファイルとなって困難 標準機能で既存ファイルにXLSXインポートする案では、既存ファイルに入れると数式が壊れる Driveファイルコピーして新規ファイルとして扱うとGASとの紐付けが無くなり、GAS再設定が不便となるのでやれていない TypeScript / Unit Test 上記らを対応するために、 import/export シンタックスを記述することになる ローカルのnodeでは動作するが、GASではが実行環境差分（ES Moduleエラー）によりデプロイできなくなる 時間切れでギブアップ CI/CD セットアップの費用対効果・必要性がなかったため ローカルでGAS環境を再現した開発 結合しても環境差分があり、有用ではなさそう まとめ 本書ではユーザ目線の観点に基づいて、計算処理をGASとGoogle Sheetsで使い分けて実装しました。また、環境設定は暫定解としてGASの設定ファイルとしてもたせれば良いとわかりました。最後に、ローカルで開発したコードを簡単にGASにdeployし、本番環境にGitHubからデプロイできるようになりました。 ご紹介した内容は開発の途中からでも適用できるので、いまからでも迅速かつ安定感のある開発をしていきましょう。

こんにちは！Lead Engineerの筒井です。 Insight EdgeにJOINして今月でちょうど一年、いくつかの案件に関わってきました。案件対応の中でJupyter Notebook（以下、Notebook）をWebアプリ化して公開する仕組みを作りましたので紹介します。 背景 今回のタスク（案件の中の1つのタスク）の背景は以下のようなものでした。 事業会社（以下、A社）において、機械学習を利用した予測・分析を事業に活用している A社内のデータサイエンティストが、Notebookを使ってさまざまな予測・分析に対するモデルを作成している A社内の各部署から依頼を受けて、データサイエンティストがNotebook上で予測・分析処理を実行し、結果を提供している この予測・分析処理を各部署が自分達で実行できるようにすることで、データサイエンティストの雑用を減らして本来業務に工数を集中させるとともに、 依頼から結果取得までの手数とリードタイムを減らして、各部署がいろいろなパターンのパラメータを試せるようにすることを目指します。 対応策の検討 とりあえずJupyter Notebookのコードをもらって改変し、適当なフレームワークに乗せてWebアプリ化すれば良さそうというのが最初の感想でしたが、 この方法では以下のような理由から手離れが悪く、工数が多くかかってしまいます。 適切にコードを改変するには、実装内容の深い理解が必要になる Notebook更新のたびに変更部分の改変とWebアプリへの反映が必要になる 将来増えるものも含め、Notebookごとに都度対応が必要になる 良い方法が無いかと検討していたところ、NotebookをそのままWebアプリ化するMercuryというOSSを見つけ、これを利用することにしました。 また、単に1つのWebアプリを作って終わりではなく、NotebookからWebアプリ化するところもGitHub Actionsを使って仕組み化することにしました。 Mercuryの紹介 関係者ではないのですが、ここで簡単にMercuryを紹介します。 MercuryはNotebookをWebアプリ化するための パーフェクトツール です。 Mercury is a perfect tool to convert Python notebook to interactive web application and share with non-programmers. 基本的な機能 Mercuryの基本的な機能は、 Webアプリ上でNotebookへの入力値を指定するためのウィジェットを作り、 Webアプリ上でNotebookを実行し、実行結果を表示する ことです。 1のウィジェットは簡単なYAML形式でNotebook上の最初のセルに記載し、その入力値をNotebook内で変数としてそのまま使うことができます。 また、その次のコードセルで、（Webアプリからでなく）直接Notebook環境上で実行した場合の変数の値を指定できる（Webアプリからの実行時はスキップされる）ため、 Pythonコード的には実行時に値を切り替えたい変数を集めたセルを作っているだけで、Notebookの開発やコードへの影響がほぼありません。 その他の機能 その他の機能としては以下のようなものがありますが、活発に開発が進んでおり、これら以外にも多彩な機能を持っているため、 興味が湧いた方はぜひ 公式サイト や GitHubリポジトリ を覗いてみることをおすすめします。 なお、本記事の執筆時点で、MercuryにはAGPLv3のOSS版と、コピーレフト関連条項が無く機能追加された有償版（Mercury Pro）があります。 入力内容に応じたウィジェットの作成（スライダーやチェックボックス、ファイルアップロードなど） Pythonコードの表示/非表示切り替え Pythonコードで出力したファイルのダウンロード 複数Notebookのホスティングとポータルページ ユーザー認証とアクセス権制御（Mercury Pro） 出来上がったもの 今回作ったものは下の図のような構成になりました。 Notebookリポジトリ Webアプリ化したいNotebookを持つGitHubリポジトリ MercuryRunnerリポジトリ Notebookリポジトリ内のNotebookをWebアプリ化するのに必要なコードとGitHub ActionsのWorkflowを持つGitHubリポジトリ 利用手順の概要は以下です。 (1) Notebookを作成・更新する (2) NotebookリポジトリやNotebookのパス、Cloud Runのスペック等を指定して、GitHub ActionsのWorkflowを手動実行する (3) Notebookリポジトリから、必要なコードを取得する (4) MercuryによってWebアプリ化したコンテナをビルドして、Cloud Run上で実行する (5) Cloud Load BalancingとIAPで、Webアプリに必要な認証をかける（初回のみ） (6) Webアプリを利用する Notebookの更新をした場合でも、手順の(1)と(2)を実行するだけですぐにWebアプリに反映され、 初回に必要なGCPの設定もさほど難しくないため、Notebookをいつでも簡単に作成・更新できるようになりました。 MercuryRunnerリポジトリとNotebookリポジトリを分けることで、Webアプリのデプロイ時以外は、Mercuryのことを気にする必要が無いようにしています。 GitHubリポジトリやGCPプロジェクトの構成に対する制約と、利用手順の簡便さはトレードオフになるのですが、 今回の案件の状況や、他の事業会社の案件でも今後同じようなパターンがありそうという勝手な予想を鑑みて、その辺りのバランスを決めました。 例えば、GitHubリポジトリやファイルパスを指定する手間がかかる代わりに任意のNotebookリポジトリを指定できるようにしたり、 Cloud Load BalancingやIAPをWebアプリごとに設定する必要がある代わりに、任意のGCPプロジェクトへデプロイできるようにしたりしています。 まとめ 今回は、MercuryとGitHub ActionsとCloud Run（GCP）を使って、Notebookを簡単にWebアプリ化し、継続的にメンテナンスできる仕組みを紹介しました。 上記の通り他の案件でも同様の仕組みが使えないか、自社のメンバーにもこの内容を紹介し、実際他の案件で試しに使ってみてもらっています。もし今後需要があれば、需要の内容に応じていろいろな提供方法が考えられるなと夢想しています。 さて、今回紹介したタスクでは、できるだけInsight Edgeの手を離れ、事業会社のみで自走できることを目指した形になっています。 一般的な受託開発の文脈で考えると、顧客から都度開発・保守を依頼してもらった方が利益が生まれることになりますが、 顧客と利益相反することなく、住友商事グループとしての全体最適を考えられるのが、Insight Edgeの立ち位置の良いところだなぁと改めて感じています。 さまざまなドメインを持つ事業会社の課題解決へ技術面からアプローチしていくことに興味がある方はぜひ、Insight Edgeの公式サイト、採用ページをご覧ください！

はじめまして。Insight Edge でエンジニアリングマネージャをしている猪子です。 本日、Insight Edge Tech Blogを開設しました！ 記事第一弾として「Insight Edgeとは？」「なぜTechブログを始めたか？」について紹介出来ればと思います。 Insight Edgeの組織や開発の流れを知りたい方、Techブログをこれから始めようとしている方の参考になれば嬉しいです。 Insight Edgeとは Insight Edge は主に住友商事グループ各社のDXを推進するために設立された企業です。 扱う事業ドメイン グループ会社は現在国内外合わせて約900社（！）あるので、扱う事業ドメインも非常に幅が広く、Insight Edge設立から約3年の期間で案件として扱ったドメインには以下のようなものがあります。 ・トレード系（金属・資源等）事業 ・電力事業 ・メディア関連事業 ・モビリティ・物流関連事業 ・小売関連事業 ・その他新規事業開発 等 これらの多種多様なドメインの案件にInsight Edgeメンバは日々取り組んでいます。 案件のプロセス Insight Edgeが住友商事グループの事業会社の案件に着手する場合、プロジェクト体制と役割はおおむね以下の様になります。 組織名 組織の役割 案件での役割 事業会社 住友商事グループの事業会社の実運営を担う 実際の現場担当者も参画し、課題の1次情報や、データを提供する 事業主管部 各ドメイン内の事業会社業務を主管する 案件においては、役割は事業会社と同様 DXセンター 事業ドメイン横断でDXを推進する 元々事業会社や事業主管部に在籍していたメンバが多く、現場の業務と課題の知見を持ってプロジェクトマネージメントを行う Insight Edge 技術によってDX推進を支援する DXセンターと一体となり、主にシステム企画フェーズから開発を担当する 上記の体制の内、前者2つ、後者2つはそれぞれ事業主体組織、技術課題解決組織として日々活動しているのですが、事業会社の課題に対してはこれらの組織が一体となって課題解決のプロセスを進めていきます。（合言葉はOne Team！） 大きな流れとしては、課題設定 -> 検証（課題解決のためのプロトタイプシステムの開発） -> 実現化（実システムの開発・運用）というステップとなります。 Insight EdgeとDXセンターのメンバは、検証や実現化等システム開発に関する部分だけではなく、課題設定から関わっています。課題設定では、事業会社や事業主管部がビジネス的な視点で定めた課題に対して、これまでの知見と技術的観点からアドバイス等支援する事で、より事業的として効果の高いプロジェクトにしています。 なぜTechブログをはじめたか このように多くの事業会社 / ドメインの案件に対してInsight Edgeは幅広いレンジで対応しているのですが、継続して増えていく案件の量に対応できるよう、継続して人員を採用していく必要があります。また、より多くの価値貢献をするために、案件の獲得もしなければなりせん。 上記にはInsight Edgeのプレゼンス向上が欠かせないため、過去、以下の取組をしてきました。そして、新たに Techブログ を追加したわけです。 採用強化のための施策 案件獲得のための施策 ・カンファレンス登壇（自社発 / 他社発） ・ Webメディア記事執筆 ・SNSマーケティング ・カンファレンス登壇（自社発 / 他社発） ・社外勉強会 ・ パートナシップ認定 ・プレスリリース Techブログは何が良い？ Techブログの強みは採用における認知力であり、実際に採用活動をしている中で各採用サービス企業の方にブログの有無を聞かれることがあります。 また、2022年に公開されたCTO協会の資料 1 でも開発者体験ブランド力上位数社に対して調査したところ、エンジニアが 認知・好感 を持っている発信チャネルの1位が Techブログ となっています。 ※発信チャネルとしては2位以下、技術イベントへの登壇、Twitter、インタビュー記事が続いています。 本当のねらい もちろん、プレゼンス向上はTechブログの目的の1つなのですが、さらに大事なのは Insight Edgeメンバの成長 です。 Insight Edgeのメンバとして個々人が継続的にアウトプットすることにより、以下を狙っています。 社内/外での知見の展開 アウトプットによるインプット量の増大（学び直し） 情報整理・言語化スキルの向上 各個人のプレゼンス向上（ポートフォリオ強化）等 ※企業のプレゼンスの向上をサブの目的としているのはブログの継続性のためでもあります。Techブログの執筆によるメンバの成長も継続してこそなので、記事執筆のハードルをできるだけ下げたいという思いもあります（「こんな記事書いたらあまり受けないだろうなぁ…、受けの良いテーマ無いから書けないな…」となって記事がでてこなくなる状況を避けたい）。 「個人の成長 = 企業の成長」をシームレスに実現するための1つのツールがTechブログだと思うので、ブログを継続しながらその効果を計測していきたいと思っています。 まずは継続をゴールとし、記事を書く人/見る人両方に価値のあるブログを目指していきます！ 終わりに Insight Edgeはデータサイエンティスト、エンジニア、UI/UXデザイナ、プロジェクトマネージャ等、会社を共に盛り上げてくれるメンバを募集しています。 興味がある方はカジュアルにお話させて頂ければと思いますので、お気軽に こちら からお申し込みください！ https://drive.google.com/file/d/1i0lpIC5WSRk4ghKSIhRFbuQR3S7uvyjH/view ↩