Insight Edgeの福井です。年末年始で鈍った体もようやく戻ってきました（気がします）。さて、世の中にはたくさんCxOという方々がいらっしゃいますが、会社によって担当範囲や業務内容など様々だと思います。当社にもCEOとCTOの２種類のCxOがいるのですが、今回は当社のCTO（私）が普段どんな業務をしているかについて紹介したいと思います。 Insight EdgeのCEO・CTO 当社の場合、CEOとCTOで明確に担当領域を分けていない部分もありますが、簡単に説明すると以下のような役割分担をしています。 CEOの役割 当社CEOの主な役割は「経営戦略、営業戦略および組織戦略の立案」となり、会社運営全体の責任者です。経営・事業戦略立案から各種運営指針の統括、代表としての営業・広報活動なども含みます。 CTOの役割 当社CTOの役割は「技術戦略の立案および技術領域の各種施策検討」となります。これには当社として取り組む技術方針策定の他、エンジニア採用戦略やサービス企画、パートナー戦略なども含みます。 CTO業務について 上記役割外の業務タスクも当然（？）たくさんあるのですが、CTOとしての担当業務は例えば以下のようなものになります。 技術方針策定 Insight Edgeの核となる技術領域をどこに置くか、現在の技術領域から将来どの領域に軸を置くかなどを検討します。判断材料として市場の情報収集、顧客ニーズ分析のための情報収集、当社課題の分析などを行いますが、当社の場合は主なプロジェクトが住友商事グループ関連となるため、親会社である住友商事の方向性を加味して決めていくことになります。また、住友商事グループ全体のDXを進める上で、中期・短期的にどの領域に注力しプロジェクト推進を加速していくか、グローバル的にはどうするか、なども重要な視点となります。 日々のプロジェクトの内容を理解することがとても重要ですので、各メンバーから現状含めた情報を共有してもらっています。 技術パートナー検討 当社が対応するプロジェクトは様々な領域にまたがるため、当社だけでは対応できないような技術領域も当然存在します。そのような場合には一緒に課題解決をしてくれる技術パートナーが重要となります。特にInsight Edgeが得意としていない技術や尖った技術を持つスタートアップの方々との関係作りを実施しています。また、当社は住友商事が関係するスタートアップとも関わりがあり、それら企業との協調も検討します。 PMO 技術方針策定でも少し触れましたが、プロジェクトの全体像を把握することは現在の自社の状態を確認するのにとても役に立ちます。また、当社の場合はまだ専門のPMO組織がないため、プロジェクト推進の最終チェック的な意味でもCTOが確認するようにしています。 採用戦略 技術方針に従ってどのようなスキルを持った方に参画いただくかを検討するのですが、現在のところ採用エージェントとの打ち合わせやスカウトなどの採用活動も主体的にCTOが実施しています。やはり、優秀な方に当社に参画いただくことが最も重要だと考えていますので、ここには多くの時間を使っています。また、採用だけでなくエンジニアの評価基準なども作成しています。 働く環境作り エンジニアメンバーの皆さんが効率よく働くための社内環境について検討・改善しています。開発環境などはもちろん、制度や施策など少しでも良い会社環境に近づくために日々Try & Errorしています。主体となるのはエンジニアメンバーなので、メンバーの意見を積極的に取り入れながら検討していくため、1on1など一人一人と話せる機会や気軽に話せる雰囲気をできるだけ作っています。 もろもろ企画 社内でコミュニケーション機会を多く持つために飲み会を含めたイベントを企画したり、会社の認知度向上や情報収集のためイベントに参加・登壇してもらったりと、日々のプロジェクトだけではなく他の刺激を積極的に取り入れられるような施策を企画しています。昨年から企画チームが立ち上がり、サービス企画含めてこのような人事系の企画もまとめて検討・実施しています。 CTOとして 世の中には圧倒的な技術力でカリスマ的にリードしていく方や、広く深いITの知識と経験でメンバーをサポートする方など、いろいろなタイプのCTOがいらっしゃると思います。私の場合はIT業界の経験は長いのですが、カリスマ的な雰囲気をもっているわけでもなく、超リーダーシップを発揮してグイグイひっぱっていく性格でもありません。では、当社CTOとして自分はどういう存在になりたいかというと、 メンバーが相談しやすいエンジニアの最高責任者。 各プロジェクトの最終的な責任はCTOにある。 エンジニアメンバーが楽しく安心して仕事ができる環境作りの責任者。 という感じで、メンバーの皆さんを支援することで会社全体のパフォーマンスを最大限に導く存在でありたいと考えています。 まとめ エンジニアにとって様々な面で安心して働ける会社をつくりたい、と考えてInsight Edgeを立ち上げました。日々メンバーの皆様からもたくさんのアイデアや意見が寄せられ、企画・改善している毎日です。CTOという立場での業務をとおして、さらにInsight Edgeのメンバーで良かったと社員の皆さんに思われる会社にしていきたいと思います。

こんにちは！Insight Edge開発チームのkyです。今回は、今話題のノーコードツール「Bubble」を使ったアプリ開発での実装方法についてコツも交えてご紹介します。 Bubble とは？ コーディングが不要で、ドラッグ&ドロップでのWebアプリを開発可能とするツールである ノーコードツールの中でトップクラスの人気がある 2015 年にリリースされ、2022 年にはユーザー数 200 万人を超える ノーコード/ローコード市場も今後成長が見込まれる 開発フェーズにかかるコストをカットできる 学習コストが低く、ITエンジニアの人材不足解消へつながる Bubble でアプリ開発(基本の使い方) ◆ 入力 画面左にある「Design」→「Input forms」の中からInputやCheckboxなどの要素をドラッグ&ドロップで指定の表示位置に配置 ◆ 出力 画面左にある「Design」→「Visual elements」の中からTextやLink、Buttonなどの要素をドラッグ&ドロップで指定の表示位置に配置 ポイント１：追加要素に名前をつけておくと要素検索ができるので、DB設定や要素を重ねる時など後の変更がスムーズになる ポイント２：UIパーツのGroupを小さい単位で使っておくと後で変更が容易になる（詳細は「UIパーツのGroupを使うメリット」参照） ◆ DB 画面左にある「Data」→「Data types」より「New type（テーブルに相当）」「Create a new field（カラムに相当）」を作成 ポイント３：カラム名には日本語も使えるため、英語での命名に時間を使わずに作成ができる ◆ Workflow Button押下時やページロード時などに実行したい処理を追加 Tips ◆ UI パーツの Group を使うメリット UIパーツをそのまま使うことも可能だが、アプリ開発では入出力項目に対してラベル表示があったり、複数の要素で1つの単位となるケースが多いので、そういった場合の対応が容易になる。 UI管理（Group単位での移動や位置変更・調整、削除）が容易になる レイアウト調整（Margin等をつけるなど）の影響範囲をGroup内のみに限定できる ひとまとまりの単位として扱うことでモーダル表示などが可能になる ◆ ID を使ったログイン方法 Bubbleの仕様として「メールアドレス」と「Password」でしかログインできないが、下記の方法で「メールアドレスでない文字列」をID（ユーザー名）としてログインできる。 （参考） https://forum.bubble.io/t/can-i-use-username-as-text-field-instead-of-email/859/22 アカウントのメールアドレスに「ID」＋「@〇〇.△△」を設定 Workflow でのログイン処理にて、Email の部分に「入力された ID」＋「@〇〇.△△」と設定 ◆ ログイン後の画面制御 Bubble上で新規作成したページは、閲覧制限等の制御が入っていないためURLさえわかれば誰でも閲覧可能なページとなっているが、下記の設定でログイン状態に応じた閲覧制限、遷移ができる。 ※ Bubbleは、ログイン後ページに自動で閲覧制限を付けてくれない ログイン状態でない時にログイン画面に遷移させる設定方法 Workflowの「Page is Loaded」に「Go to page」を追加 「Go to page」の遷移先にログインページを指定 「Go to page」の「Only when」に「Current User is logged out」を追加 ◆ 無駄な空白を作らずに UIパーツを配置する方法 DBに格納した値を表示したい場合など、位置の指定に座標を使用すると要素同士が重ならないように間隔を広く取る必要があるが、そうするとデータ数が少ない時に空白が多く、見た目が悪くなる問題が発生する。 無駄な空白を作らないように表示設定する方法として、「GroupのRow/Column」のいずれかを使用する。 内部のUIパーツの高さや幅に最低値を入れておくことで内容の増減に伴う表示域の変化に対応できる。 ※ 要素間の間隔も指定できる GroupのLayout → Container → Row（内部のUIパーツが横に並ぶ） GroupのLayout → Container → Column（内部のUIパーツが縦に並ぶ） Bubble を使ってみた感想 初期リリースまで時間や予算が取れなかった方や今までアウトプットする前に挫折した方でもより多くのアウトプットを世に出していけるようになると感じました。 特に低コストでスピーディーにアプリを作りたい方、デザイナー、プログラミングを勉強前の方などに向くと思います。 ※ ただし、手軽であり開発が容易な代わりに向かないと感じた点もあります。 ◆ スクラッチ開発と比較して向くと感じた点 MVP開発で初期リリースまでの期間を短縮できる 開発内容が少ないほどスクラッチ開発との開発スピードに差が出る ユーザー画面等のシンプルな2〜3画面程度（ログインしてデータ閲覧程度）のアプリなら1〜2日くらいで作成可能、1画面なら最短数時間 ある程度作りたいものが決まっていたら、細かい要件に悩まず、まず作ってみる！が手軽にできる 開発するアプリの内容（作りたいもの）だけに時間を使ってリリースできる 初期リリースが早い分素早い改善につながる 環境構築やデプロイ等の知識を必要としない 最初に環境構築でつまづくことがない インフラ代やメンテナンス等を気にする必要がない リリース方法につまづくことがない ソースコードを書かない HTMLを知らなくても画面が作れる スタイルの設定もCSSを使わずに設定である程度作成できる 細かい構文ミスでつまづくことがない 使わなくても十分作れるが、HTML, CSS, JavaScriptを使うこともできる ネイティブアプリ(iOS,Androidアプリ)の開発ができる Bubbleアプリをネイティブアプリに変換してくれるサードパーティ製のサービスがある（有償） レスポンシブ対応、PWA開発ができる ◆ Bubble 開発で向かないと感じた点 処理が複雑（条件が多い等）、規模が大きい（20〜30画面以上や大量のデータを扱う、機能要件が多い等）の場合 2つテーブル結合し表示するだけでも表示に時間がかかるため、複雑なテーブル結合や大量のデータを扱う際は注意が必要そう 最上位プランでもデータベース容量が最大50GBである プログラムロジックの条件の分だけ同じような処理を設定することになり、作成時間が増加する 機能が多い分アカウントの種類や処理、扱うデータの利用が複雑になり、ソースコードを書くよりも作成時間が増加する （シンプルな機能ほど、ノーコードの良さが発揮されると感じました。） DB登録・更新回数やDB項目が多い場合 登録・更新は別々に処理を設定するため、同じような設定処理を1から設定していくことになり設定数が多いと時間がかかる ※ あまり効率の良くない処理を設定している時は、ソースコードを書いたほうが早いと思うときもある

こんにちは！データサイエンティストの伊達です。 今回は、データマイニング分野におけるトップカンファレンスの一つである KDD 2022 で気になった論文とチュートリアルを紹介します。 KDD とは 論文 (Research Track): Wu et al., Non-stationary A/B Tests 背景 論文内容 チュートリアル：Counterfactual Evaluation and Learning for Interactive Systems チュートリアル：New Frontiers of Scientific Text Mining: Tasks, Data, and Tools まとめ KDD とは KDD 2022 (28th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining) とは、データマイニング分野におけるトップカンファレンスの一つで、2022年8月にアメリカのワシントンD.C.で現地開催されました。 今回は3年ぶりのオフライン開催だったようです。 私は今回参加できませんでしたが、次回もオフライン開催だったらぜひ久しぶりに現地参加したいです。 論文投稿は Research Track（研究志向）と Applied Data Science Track（応用志向） に、招待講演もキーノート講演（主にアカデミアの先生方）と Applied Data Science 講演（主に企業在籍の研究者）に分かれており、研究と実応用のどちらにも重きが置かれています。 本記事では、個人的に気になった Research Track の論文を1本、チュートリアルを2つご紹介します。 論文 (Research Track): Wu et al., Non-stationary A/B Tests Non-stationary A/B Tests 背景 非定常性：時刻や曜日によって顧客の振る舞いは変化 →「time-of-day（時刻）」効果や「day-of-week（曜日）」効果が生じる ブラウザ種別（例：Firefox、Edge、Chrome）等のよく使われる層化変数（strata）は質的変数だが、時刻は量的変数であり、そうした量的変数を層化変数として用いたABテスト手法についてはあまり研究が進んでいない 論文内容 データの「非定常性」によって、ABテストの検定結果が不適切なものや非効率なものになることを示した 本論文では、 標準的なABテストで使用可能な、連続値の層化変数による事後層別（post-stratification）手法を提案 また、ABテストの実験設定が可変であるようなインフラが使用できる場合に使用可能な手法（time-grouped randomization）を提案 ABテストを数日間や数週間といった限定された期間で実施するのはよくあることだと思うので、時刻や曜日によるデータの振る舞いの変化を考慮したテスト手法は実応用で重要そうです。 ABテストに限らず機械学習モデルの構築でも、学習や評価に使うデータにおいて季節性、時刻効果、曜日効果といった時間による変動要因を抑えて分析に取り組むことは、実データを扱う上でマストではないでしょうか。 チュートリアル：Counterfactual Evaluation and Learning for Interactive Systems Counterfactual Evaluation and Learning for Interactive Systems (KDD2022 Tutorial) こちらのチュートリアルでは、off-policy evaluation と off-policy learning (OPL) の基礎、実用上の課題、OSS である Open Bandit Pipeline について紹介されていました。 Off-policy evaluation とは、ある施策（policy）について、その施策とは異なる施策を用いて過去に収集されたデータを基に精度評価をする方法です。この方法は、前節で紹介した論文で扱われているABテスト（online policy evaluation）のように、施策を実システムに載せて直接データを取って評価する方法とは異なるアプローチになります。 Off-policy evaluation を用いることで、オンライン実験を実施することなく大量の施策候補を試すことができる、不適切/低品質な施策候補をオンライン環境に投入することによる悪影響を防ぐことができる、などのメリットがあり、近年その手法改善に関する研究や応用が増えてきているようです。 当日のチュートリアルは、計六部（off-policy evalution と off-policy learning の基礎、bias-variance 制御、off-policy evaluation における近年の進展、off-policy learning に関する手法の紹介、Open Bandit Pipeline の紹介、総括）に分かれており、資料も合計300ページ超と内容盛り沢山なので、興味を持たれた方はぜひ見てみてください。 チュートリアル：New Frontiers of Scientific Text Mining: Tasks, Data, and Tools New Frontiers of Scientific Text Mining: Tasks, Data, and Tools 科学文書に対するテキストマイニングは、世の中に存在する大量の科学文書から構造化された知識やアイデアなどを抽出するための技術であり、今後の科学研究の促進の大きな助けになることが期待されます。 しかし、それぞれの科学分野に関するドメイン知識の必要性、科学ライティングにおける複雑な文構造、科学知識表現のマルチモーダル性（例：分子の表現方法 → 論文中の化学式 or 分子構造）などにより、特有の困難さを有しています。 このチュートリアルでは、特に生物・医学・化学ドメインにフォーカスして、科学文書に対するテキストマイニングの基礎、固有表現抽出や関係抽出等の技術、実応用例などを紹介しています。 また、チュートリアルの最後では、新型コロナと有機化学分野の実データを用いたデモが行われたようです。 個人的に興味深かった点： BioBERT、ChemBERT、ClinicalBERT など、各分野に特化した事前学習済み言語モデルがある 分野によって役立つモデルが異なる（例：化学はグラフ構造を持つデータが多いため、グラフニューラルネットワークによる表現学習を活用） 科学文書では、分野でよく使われる略語や概念が詳しい説明なしに使われるため、事前学習済み言語モデルとナレッジグラフを併用して文中のエンティティを結合 まとめ 今回は、KDD 2022で個人的に気になった論文とチュートリアルを紹介しました。 採択論文は Research Track・Applied Data Science Track どちらも実応用を見据えた研究がほとんどで、チュートリアルもデータマイニングや機械学習の技術を現実の様々なドメインでどこまで応用されているか、open problem は何か、今後どう解決していけそうか、といった話が多い印象を受けました。 データ分析による事業の実現やバリューアップに日々取り組むデータサイエンティストとして、引き続き KDD の内容はキャッチアップしていきたいと思います。

目次 はじめに この記事で主に書くこと 基本情報 会場 食事 英語 セッション おすすめセッションタイプ おすすめしないセッションタイプ セッション参加方法 参加セッション セッション紹介 まとめ はじめに Insight EdgeでDeveloperをしているMisawaです。Amazon Web Service (AWS)がラスベガスで開催している世界規模の学習型巨大イベント「re:Invent」に2022/11/28-12/1の期間に参加してきました。私は今回が初めての参加で事前にある程度情報を仕入れてから行ったつもりでしたが、そのスケールの大きさに現地でとても戸惑いました。私のように初参加される方の助けになると思いこの記事を書きます。 この記事で主に書くこと re:Inventの特徴 イベントを快適に参加するためのTips 参加をおすすめするセッションタイプ 今回参加したセッションの紹介 基本情報 re:Inventは2022/11/28-12/1に開催されたAWSによるクラウドコンピューティングに関する世界規模の「学習型」カンファレンスで、新サービスなど発表される他、現地会場ではさまざまな発表を聴講したり学習型イベントなどに参加できます。 公式 によれば世界中から50,000人以上が参加したとのことです。前回の現地開催は65,000人とのことですので8割程度戻ってきたといった様子です。ちなみに日本からの参加者は1,000人程度と聞いています。それにしても、ひとつの会社のサービスでこの規模のイベントを開催できることがまず驚きですね。 会場 今回のre:Inventではラスベガスにある下記の黄色の6つのホテル（カンファレンスセンター）が会場となっていました。 一見するとホテルは隣同士で簡単に移動できると錯覚しますが、実際には隣同士でも会場となっているホテルはとてつもなく広く15分以上は絶対にかかります。 ホテル内でも目当てのセッション会場にたどり着くのに相当な量歩きますので隣同士のホテルと言っても油断はできません。 ちなみに両端の会場に至っては歩きで行き来しようとすると画像の通り5km弱ありますので1時間程度はかかります。モノレールやシャトルバスでの移動が必須です。現地でのタイムマネージメントに失敗すると悲惨な目に遭います。 また、とにかく移動量が多いので荷物が少ないに越したことはありません。Macbook Pro 13 inchと私物のiPadをリュックに入れて携帯していたのですが、それに加えて水など携帯するととにかく重さで肩・腰にきます。いかに身軽に行動するかが重要です。 食事 食事には困りません。複数の会場で朝・昼が提供されます。そしてMeals会場はえげつないほど広いです。写真では伝わらないかもしれませんが、この奥にまで食事会場が広がっています。 日毎に中華、イタリアン、スペイン・・・と言ったようにジャンルが変わっているようです。ホテル毎に味や提供されているメニューも違うようなので機会があるなら日毎にホテルを変えてみることもお勧めします。ちなみに朝食は基本的に甘いパンしかありませんので、しょっぱいものが食べたい人は注意が必要です。 Meals会場で食べる時間がない方はランチBOXも提供されるので大丈夫です。それを手に持ち次の会場に移動してそこで食べることもできます。 ランチBOXには必ずまるごとりんご1つが入っています。アメリカンですね。 英語 英語はできるに越したことはないです。大きめのセッションであるKeynote等は日本語通訳もあるそうですが、基本的にどのセッションも自らの力で聞き取る他ありません。一方でWorkshopやExpo会場など1対1で話せる機会はそこそこあります。担当の方に頑張って質問すればみなさん快く答えてくれるので心配はいりません。教育型のイベントなので自分から突っ込んでいく勇気さえあればどうにでもなります。 セッション re:Inventはとにかく大量のセッションがあります。ここでは現地参加する方に特におすすめしたいセッションタイプとそうでないセッションタイプを紹介します。 おすすめセッションタイプ Keynote：AWSのお偉いさんによる基調講演で新規サービスなどが発表されます。始まる前のライブも気分を盛り上げてくれますし、会場内の観客の反応でそのサービスに対する世界の注目度が分かるとても貴重な機会です。 Chalk Talk：発表者のプレゼンを聴くだけでなく参加者が質問できるインタラクティブなセッションです。オンラインでの講演はありません。加えて、その場で実際にそのサービスの利用者が思っている疑問、どう使われているかなどが分かるため、筆者的にはとても有意義で一番おすすめしたいセッションです。 おすすめしないセッションタイプ 個人的にはあまり参加をおすすめしないセッションも紹介します。自身の持っている英語力や、参加目的によってもおすすめは変わると思いますので、あくまで個人的にはという前置きをすることご了承ください。 Breakout Session：基本的にオンラインで配信されます。現地で聴くメリットはあまりありません。 Workshop：現地で30分ほど説明を聴いた後、実際に説明に沿ってAWSに環境を構築するセッションです。自分で手を動かせるという点で他のセッションと異なりますが、構築する環境はCloud Formation化されており瞬時にデプロイされるので、どのような目的でその設定がされているのかなどの意図を汲み取ることは極めて難しいと言えます。一方で英語に自信のある方は会場で、色々質問できるので良いかもしれません。 セッション参加方法 各セッションを聴講するためには基本的に予約が必要になります。よほど慣れた人であればセッションの予約開始日を公式サイトでチェックして予約すると思いますが、おそらく初参加だとそうはいきません。予約はいつの間にか始まっており、大体のセッションの予約が一瞬で埋まっています。今回、私も出遅れ組で主要なセッションは既に予約が終了していました。ただ実はそこで予約ができていなくても大丈夫です。本当に聴きたいセッションはWalk-up（待ち列）が会場に用意されていますので、30分-1時間程度前から待てば大体は入れます。ただ本当に人気のセッションはとにかく長蛇の列になります。立ち見席は用意されていないので時には2時間前から並ぶ覚悟が必要です。一方で特に人気のセッションはREPEATとして追加で公演される場合もありますので、AWS Eventsアプリで随時チェックすることも重要になります。 人気のセッションはこのように行列になります。 次に現地でセッションに参加するためにやっておくと良いことをご紹介します。 現地に行く前にやると良いこと AWS Eventsアプリをダウンロードしておく 聴きたいと思ったセッションを片っ端からお気に入り登録 現地で毎日やると良いこと 前日にAWS Eventsアプリのお気に入りとSession Detailを良く読みセッション内容を吟味 会場間の位置関係を把握してスケジュールを組み立て 参加セッション 今回私が初参加で参加したセッションは下記の通りです。1回のセッションが60分以上であり会場間の移動も多いということで1人で参加できるセッション数はそこまで多くないことがわかります。自分が聴きたいセッションをいかに狙っていけるかが重要になります。 11/28 [Chalk Talk]Data preparation tips for highly accurate time-series forecasts [Chalk Talk]Transforming DevOps with AI [EXPO]企業ブース周り　 Severlesspressoほか [Keynote]Monday Night Live with Peter DeSantis 11/29 [Keynote]Adam Selipsky Kenote [Workshop]Finding data in a life science data mesh [Leadership Session]Building Modern apps: Architecting for observability & resilience [Leadership Session]Accelerating innovation with serverless on AWS 11/30 [Chalk Talk]Domain-driven design and event storming [Chalk Talk]Lambda performance tuning: Best practices and guidance [Chalk Talk]Build event-based microservices with AWS streaming services [Chalk Talk]Choosing the right database(s) for your application 12/01 [Keynote]Dr. Werner Vogels Keynote [Breakout Session]Build your application easily & efficiently with severless containers [Breakout Session]Building Serverlesspresso: Creating event-driven architectures セッション紹介 開発チームで日々システムのアーキテクトやDevOps環境の構築をしていますので、今回のre:Inventでもシステムのデザインパターン・サーバレス・監視を中心に聴講してきました。その中でも興味深かった3本のセッションを紹介します。 [Chalk Talk] Transforming DevOps with AI DveOpsをAIによって支援し更なる自動化を目指すことを目的としたセッションです。AWSとしてはCodeWhisperer（Github Copilotのような機械学習を利用したコード推薦サービス）、Code Guru Reviewer（機械学習ベースの静的解析ツール。コードをスキャンしクリティカルな問題を検出してくれます）を提供しています。 CodeWhispererはGithub Copilotのようなコードを生成してくれるサービスですが、本セッションではCodePilotを含む類似サービスとの大きな違いはわかりませんでした。ただCodeWhispererは英語のみにしか現時点では対応していないのようなのでサービスのレベルとしては類似サービスからは一段劣っているという印象です。 また他の類似サービスと同様でオフラインでの実行はできませんが、実行環境はVS Codeをはじめとした様々なIDEがサポートされています。質疑によると時期の明言はありませんでしたがNotebookのサポートが計画されているそうです。 とくに参加者からは、コードに埋め込まれたcredentialsのようなmetadata情報のサーバ上での取り扱いや、ソースコードの著作権などに関する質問が多かった印象で、やはりそこを皆さん気にしているのだなというのがわかったのも良い機会でした。 また、昨今は認証情報の漏洩など、セキュリティも良く気にされるポイントの1つですよね。セキュアな管理が求められるmetadata（credentialsなど）がソースコード中に含まれてしまっていた場合に、どのようにサービス上で取り扱っているのかといった質問もありました。こちらについてはあくまでinputとoutputに使われるのみで情報はサーバには保存されないし、もちろんモデルの学習には使われないとの回答でした。このようなサービスは非常に便利でDevOpsのサイクルをさらに改善していくためには今後も必須とは思われる一方で、どのように活用・付き合っていくかはとても難しい問題と改めて実感しました。 [Chalk Talk] Lambda performance tuning: Best practices and guidance 本セッションの内容はこれまではBreakout Sessionでやっていたそうですが、今年はインタラクティブにしたいとのことでChalk Talkでの開催となりました。Principal Developer AdvocateのEric Johnson氏からLambdaのベストプラクティスを聴くことができました。 いくつかチューニングのTipsが紹介されていましたがその中でも、特に気になった2点を紹介します。 1点目はコストとパフォーマンスのバランスの最適化に用いることが可能な AWS Lambda Power Tuning というツールです。私も含め、会場ではあまり知っている人がいないようでした。シビアにコストを最適化するということはなかなか無いかもしれませんが、昨今のインフレーションを考えるとこのようなツールの活用は必須になるかもしれません。 2点目はLambdaを用いたAPI構成です。これまでDynamo DBからデータを取得するAPIを作成する場合API Gateway -> Lambda -> DynamoDBという構成を取ることが多かったのですが、単純なユースケースではLambdaは不要でAPI Gateway -> DynamoDBの構成を取れるというのは目から鱗でした。コールドスタートもなくなりますし、要件を満たすならとてもシンプルな構成で良いですね。 普段から良く使っているサービスですが、使っているが故に考えが凝り固まってしまっていることを再認識させられました。 ちなみにこちらのセッションはChalk Talkというタイプで白板も用意されておりその場で質問に対して絵を描きながら説明してくれたりするので一味違うセッションとして楽しめました。 [EXPO] Severlesspresso 会場ではSeverlesspressoという名でサーバーレスで構築されたカフェ注文システムを体験できました。1日に1,000人程度を捌くことができるというこのシステムはStepFunctionsを活用して構築されています。 会場にいたスタッフの方に質問したところシステム自体は数人で1ヶ月程度で構築したとのことです。 システムの流れとしては、QRコードを撮影しウェブサイトに遷移、ユーザ登録をした後ウェブサイトより注文、注文番号が発行されるので掲示板で出来上がりを待つというシンプルなものです。これらは全てAWSのサーバレス技術を用いて実装されています。私の注文はもちろん、他の人の注文も即座に掲示板に反映されており、とてもスムーズに動いていたように見えました。以下は実際の注文画面です。 ちなみにこのシステムの裏側を[Breakout Session]Building Serverlesspresso: Creating event-driven architecturesでも聴くことができました。身近で動いているサービスの裏側を実際に垣間見られる機会は少ないと思いますが、このように実際に会場で動いているものをその場で裏側も含めて一気に理解できるというのも本イベントならではの経験と感じました。 まとめ 初参加の感想としてはまず「圧倒」されたの一言に尽きます。現地に行ってみて初めてわかる空気感など何もかもが初体験で日々AWSを使った開発をしている身としてはとても刺激的で更なる活力が生まれてくるとても貴重な体験となりました。 先人たちが既に役立つTipsを多数ブログ等に書いてくれていますが、この記事もその一助になることを願っています。ちなみに必要に応じて追記するつもりです。

こんにちは、Insigth EdgeでData ScientistをしているKNです。 本日は、Las Vegasで11月28日から12月2日まで行われたAWS re:Invent 2022に参加してきましたので、その報告をいたします。今回発表された新サービスについての深堀りやサービスの技術的な詳細については言及しません。私個人の感想、お気持ちメインとなりますのでご了承ください。 本記事の構成としては、まず最初にre:Inventの全体的な感想を述べた後、私が参加した講演の気になった点について報告させていただきます。 全体所感 今回、re:Inventには初参加です。まず、最初に驚いたのはそのスケールのデカさです。ラスベガスの複数のホテルに渡って会場になっており(日本の感覚からするとそのホテル自体十分大きいのですが)、来場者数も5万人超と圧巻でした。 イベントは、AWSの新しいサービスや新機能の発表のKeynoteが複数あり、AWSの各サービスの概要やユースケース紹介を教育を兼ねたSessionや実際に手を動かして使ってみるワークアウト等が常時複数開催されています。また、AWSに関連するサービスを展開する企業展示ブースがあります。 re:Inventの位置付けとしては 巨大なファンイベント という感じで、AWS側からすると紹介や教育を通してもっとサービスを使ってもらおうという意図を感じました。 一企業のイベントでここまでの規模の人数を集客できる例はなかなか無いので、改めてAWSのサービス規模の大きさを実感しました。 確かに、KeynoteやSession等の発表を視聴するという意味ではオンラインでも十分かと思います(ましてや、人数多すぎて入ることすらできない発表があったり、会場の移動が遠くて次の講演に間に合わないといった問題があるくらいです)。 ですが、KeynoteでのリアクションやSessionの混み具合等でサービスへの期待度が分かったり、現地の担当者や参加者とコミュニケーションができたりしたので、そういったことは現地参加ならではかなと思います。また、4日間集中してどっぷりAWSに浸かることで、知識が深まりますし、今後試してみたいと思う機能も見つけることができました。 図：Keynoteの様子。期待度が高いサービスの発表のときは会場が盛り上がります。そうでないときは... 図：デバイス等の展示。Insight Edgeでは工場関連のプロジェクトも扱っているので気になるところです。 図：ホテル会場の様子。緑のバケツはS3のマスコットのようです。 図：ホテル会場ではお菓子や飲み物が取り放題です。カロリーが無限に取れますね。 図：打ち上げのイベントの入り口様子。ライブ会場ではEDMがガンガン流れて大変盛況でした。 各セッションについて Improve customer retention with AI-powered contact centers この講演はワークショップで、最初の30分で概要を聞いて、残り90分で指定された教材に従って問題を解くというものです。 内容はコールセンターにおける顧客のチャーン(離反)率をリアルタイムで予測して、それに対してアクションとれるようなシステムを構築するものでした。 予測モデル作成には「Amazon SageMaker」を、コールセンターの作成には、「Amazon Connnect」を使用しています。Amazon Connectを今まで使ったことはなかったのですが、数クリックするだけでそれらしいものができるのは新鮮でした。最後の方は各々携帯で架電して、自分の作ったコールセンターの機能を確認しました。 Use AWS IoT TwinMaker to easily create digital twins for aerospace uses IoTデバイスの実物機のデジタル版(双子)を作ることができる、「AWS　IoT Twin Maker」のワークショップでした。AWS Twin Makerの詳細については こちら 。 ここでは、ISS(国際宇宙ステーション)のストリームデータを対象に、ISSのモデルを作成して、Grafana上で確認できるようにしました。作業としては、ポチポチ押していくだけですが、簡単にわかりやすいダッシュボードを作れるのは良いですね。 図：Twin Makerの作業画面。ISSのモデル化の様子。 Workshopはネタとして面白いのが多かったです。しかし、時間の関係上、大部分は既にCloudFormationでリソースは自動作成されています。テキストに従って作業していくだけで、理解しないまま進めることができるので注意が必要です。勉強のためにも後で資料を公開してほしいところです。 Reliable scalability: How Amazon.com scales in the cloud Amazonがどのように安定的にスケールするアーキテクチャを設計しているかについて紹介しているセッションです。AWSではアーキテクチャ設計のベストプラクティス方法を公開(リンクは こちら )していますが、ここでは具体的にAmazon.comでどのように実践されているかについて紹介されていました。 MLに関連するところでは、Amazonの商品のカテゴリ分類のアーキテクチャです。Amazonでは常時、商品ごとに1000モデルのカテゴリ分類を行なっていますが、そのバッチ処理の障害が他のワーカーに伝播しないようにShulle Shardingを採用しているとのことです。これにより、分散システム内での障害が伝播することを防げます。シンプルだけど、強力ですね。 How Stable Diffusion was built: Tips & tricks to train large AI models 日本でも話題になった「Stable Diffusion」のような大規模モデルの学習環境について紹介していました。 AWSの基盤を使って構築され、A100GPUの4000並列のクラスターを構成して学習されたようです。ネットワークは「Elastic Fablic Adapter」で接続して、ファイルシステムは「FSx for Lustre」です。クラスターの構成自体は「AWS ParallelCluster」の機能を使って、yamlファイルで簡単に記述できるようです。また、「Stable Diffusion」を作成した「Stablity AI」のCEOが参加して、今後の生成系AIの展望を語ってくれました。 他にも数多くセッションに参加しましたが、今回はここまでにしたいと思います。別途機会があれば、イベントで紹介された新機能について紹介できればと思います。

こんにちは。Insight Edge引越し好き(?)Data Scientistの中野です。 最近は1年半のペースで引越してるので、免許書の住所記入欄が足りなくなり付箋のようなものに住所を記入しています！ 新しいエリアに引っ越す時は近隣のカフェや本屋情報を調査しているのですが毎回イマイチ綺麗に可視化できないので、 今回は地理情報データを可視化できるツールの比較や、その際のちょっとしたコツを紹介します！ 背景 自転車盗難データの準備 自転車盗難データとは サンプルデータの概要 各ツールの紹介 01.Looker Studio（旧：データポータル） 使用時のポイント 画面イメージ 02. BigQuery Geo Viz 使用時のポイント 画面イメージ 03. Apache Superset 使用時のポイント 画面イメージ まとめ 背景 製造業や小売業など様々な顧客データを分析するときに地理情報を扱うケースは少なくないかと思います。個人的な意見ですが、分析をする際はまずざっくりとデータを可視化すると顧客が感じている仮説やデータで表現できていない点などを効率的にヒアリングできると考えています。しかし地理情報データはExcelのような普段使用するツールで可視化することが大変であることから、他の形式のデータに比べおざなりにされがちであると感じています。 そこで今回は、BigQueryに保存された地理情報データを簡単に可視化するツールとして Looker Studio、BigQuery Geo Viz、Apache Supersetの3つを紹介します。 自転車盗難データの準備 自転車盗難データとは まずサンプルデータを準備します。 サンプルデータとして空間の粒度が細かく、件数が多いデータを使用したいため 警視庁の犯罪発生情報（年計） を使用します。このデータは東京都で発生した犯罪の7つの手口の住所と日時が記録されています。今回はこの中から自転車の盗難件数を対象とします。 また住所から町丁目のポリゴン情報を取得するために e-Statの統計地理情報システム,令和２年国勢調査町丁・字等別境界データ を使用します。 これらのデータは、住所の表記揺れや欠損などのため、そのまま紐付けできません。そのため、以下の前処理を行いBigQueryにアップロードしました。 住所の表記揺れの修正（１丁目→一丁目、ヶ→ケ、など） 海上に位置するポリゴンデータの除外 犯罪発生地が不明のレコードの除外 ポリゴンデータをWKT形式, GeoJSON形式へ変換 サンプルデータの概要 地理情報の可視化を行う前に、東京都の1日当たりの犯罪発生件数を時系列グラフにして確認してみます。以下のグラフは、横軸が発生年月日、縦軸が1日当たりの発生件数、色が手口を表しています。 これだけでも７つの手口の中で自転車盗難が圧倒的に多いことや、コロナ影響で20年3月ごろに発生件数の減少したことなどが確認できます。また統計学の教科書でよく触れられる話ですが、気温と犯罪件数には相関があるというのも確認できそうです。（コロナ影響でわかりにくいですが） 各ツールの紹介 サンプルデータの準備が完了したため、各ツールを使い自転車の盗難件数をを可視化していきます。 チュートリアルや導入方法は各サイトに既に存在するため、今回はデータを可視化した際のポイント（つまずいた点や各ツールの特徴）をまとめます。 01.Looker Studio（旧：データポータル） Looker Studio（旧：データポータル）はデータソースへの接続からデータの変換、可視化、共有までを行うことのできるGoogle Cloudの無料BIツールです。 特徴としては分析結果の共有が容易で、グラフだけでなくフィルタやパラメータの設定フォームも埋め込むことができるため、 共有された側でも結果の内訳を細かく調べることができるなどレポートに向いているツールだと思います。 LookerStudioを使用してBigQueryGEOGRAPHYポリゴンを可視化する を参考にしました。 使用時のポイント GEOGRAPHY型への変換 Looker Studioを使用するためには、何かしらの方法で国勢調査境界データをGEOGRAPHY型に変換する必要があります。まず、WKT形式に変換してその後ST_GEOGFROMTEXT関数を使用して、GEOGRAPHY型に変換するのが便利かと思いました。 Looker Studioの表示上限 Looker Studioではデフォルトで10万ポイント、最大100万ポイント（ポリゴンの頂点数）までしかプロットできません。そのため町丁目ポリゴンをすべて表示するためにはフィルタを適用して対象のエリアを制限したり、ST_SIMPLIFY関数を使用してポリゴンを簡略化したりするなどして、ポリゴン数を削減する必要があります。 参考: BigQuery GEOGRAPHY データの操作に関するヒントと制約 画面イメージ 東京都における過去3年間の自転車盗難数を町丁目別に可視化しました。 ポリゴン数に上限があるため、エリアは東京23区内を対象としています。 この図から、自転車の盗難件数が最も多いエリアは蒲田駅周辺であり、その次は新宿駅周辺であることがわかります。 02. BigQuery Geo Viz BigQuery Geo Vizは、BigQueryの地理空間データを可視化するためのウェブツールです。 多くの機能は備わっていないものの、地理情報のクエリ結果を1度にひとつずつ手軽に可視化できます。 そのため、分析の初期にデータの欠損を確認したり、傾向を理解したりする探索的データ分析(EDA)の段階で使用することに向いていると思います。 Geo Viz でのクエリ結果の可視化 を参考にしました。 使用時のポイント GEOGRAPHY型への変換 BigQuery Geo Vizを使用するためには、何かしらの方法で国勢調査境界データをGEOGRAPHY型に変換する必要があります。まず、WKT形式に変換してその後ST_GEOGFROMTEXT関数を使用して、GEOGRAPHY型に変換するのが便利かと思いました。 画面イメージ 東京都における過去3年間の自転車の盗難数を町丁目別に可視化しました。 共有リンクを作成することで、30日間クエリ結果と描画スタイルを保存できます。 03. Apache Superset Apache Supersetは、ビッグデータを処理できるオープンソースのBIツールです。 インストールなど導入に手間はかかるものの、データソースにつなげてしまえばエンジニアやデータサイエンティストでなくとも分析・可視化を行える点が特徴だと思います。 また他のツールに比べ描画できるグラフの種類も豊富です。 環境構築は こちら を参考にしました。 使用時のポイント BigQueryを使用するための設定 BigQueryを使用するにはサービスアカウントの設定として"データ閲覧者"権限のものを作成し設定します。 地図情報を可視化するための設定 SupersetではMapboxを使用するため、 Mapbox.com に登録しトークンを取得します。 ドキュメントを見ると、APIキーは superset_config.py に追記するとあるが、場所は指定されていませんでした。とりあえず、 ./superset/superset_config.py にファイルを置けば動きました。 ポリゴンデータの形式 ポリゴンデータの形式はGoogleCloudのサービスではGEOGRAPHYでしたが、 SupersetではPolyLineまたはGeoJSONの形式に対応しているようです。 今回はGeoJSON形式を使いました。参考： How to display Superset data as polygons in deck.gl { "type": "Polygon", "geometry":{ "type": "Polygon", "coordinates": [[[ ... 画面イメージ 東京都における過去3年間の自転車の盗難数を町丁目別に可視化しました。 データソースにさえ接続しておけば、SQLを記述しなくてもGUI操作のみで簡単に集計できます。 そのため、気になる項目の内訳をGUI操作でドリルダウンしていくことも容易に実行できそうです。 3Dにもできる！ まとめ 今回は、地理情報データの可視化ツールを3つ紹介しました。 各ツールの特徴や向いている使い方についてまとめます。 Looker Studio（旧：データポータル） 元のデータ数が多い場合、ある程度は事前に集約やフィルタを行っておいた方が良いと思いました。 しかし共有が容易で、共有された側で詳細を調べることもできるため、分析結果をレポートする際に向いていると思います。 BigQuery Geo Viz SQLを記述できなければ分析できませんが、記述できれば手軽に可視化できるため データサイエンティストなどが探索的データ分析(EDA)の段階で使用することに向いていると思います。 Apache Superset 導入に手間がかかりますが、データソースに接続しておけばSQLを記述できない人でも細かい分析や可視化ができるため、 データや分析結果の共有人数が多い場合や、非エンジニア部門にも共有したい場合に向いていると思います。 犯罪発生情報（年計）、東京都・警視庁、 クリエイティブ・コモンズ・ライセンス 表示4.0国際 このブログは、以下の著作物を改変して利用しています。犯罪発生情報（年計）、東京都・警視庁、 クリエイティブ・コモンズ・ライセンス 表示4.0国際 出典：政府統計の総合窓口(e-Stat) https://www.e-stat.go.jp/ 「統計地理情報システム,令和２年　国勢調査町丁・字等別境界データ」を加工して作成

こんにちは！Insight Edgeの小林まさみつです。 バーコードをスキャンできるWebアプリの開発に際して、読み取りの難しいバーコードを運用上取り扱う必要が出てきました。そのようなバーコードは読み取りに時間がかかるため、試作の段階でユーザから改善して欲しいとフィードバックを受けました。既存のライブラリをいくつか試したところ、 Scandit が提供するライブラリを使用した場合は読み取りに時間がかからず、ユーザにとって不自由なく使いやすいWebアプリを開発できました。 本記事ではそんなScanditのライブラリをアプリに組み込む手順について紹介していこうと思います。 本記事で作成するアプリ 本記事では、バーコードをスキャンすることで、その値をリストアップするアプリを作成していきます。 作成するアプリのキャプチャ 目次 1. Scanditとは 2. 環境 3. 環境構築 4. Scandit用のコンポーネントを作成する 5. バーコードリーダーを表示する まとめ 参考 1. Scanditとは Scandit は、バーコードやQRコードなどをスキャンするためのライブラリを提供している企業です。 バーコードスキャン機能の特徴 公式による説明 では、以下のような特徴があると記載されています。 比類のない読み取りスピード 読み取り困難なコード(の読み取り) 幅広い角度からの読み取り ディスタンスからの読み取り 暗い所での読み取り あらゆる機種のスマートデバイスに対応 Scanditのライブラリは読み取り困難なコードに対応しており、他のライブラリでは読み取りの難しかったバーコードを高速かつ高精度で読み取ることができました。 SDK Scanditでは、バーコードスキャン機能を開発者が利用可能な SDK として提供しており、主に以下のようなものがあります。 ネイティブアプリ用SDK(iOS) ネイティブアプリ用SDK(Android) Windows用SDK ウェブサイト用SDK 今回はこのウェブサイト用SDKを利用することで、Webアプリへ簡単にバーコードスキャン機能を組み込むことができました。 トライアル Scanditは、1ヶ月間SDKを無償で利用可能なトライアルライセンスを提供しており、こちらを利用することで、すぐに自身のコードに組み込んで試すことができます。 ライセンスキーの発行手順については後述します。 2. 環境 本記事の内容は以下の環境で開発を実施しています。 ScanditのSDKとして、前述の ウェブサイト用SDK と、このSDKを利用するための公式Reactコンポーネントである Scandit SDK React を利用します。 MacOS Ventura 13.0 React@18.2.9 TypeScript@4.8.3 scandit-sdk@5.12.1 scandit-sdk-react@4.0.2 3. 環境構築 ここでは、ディレクトリ構造やSDKのインストール手順と、ライセンスの発行方法について説明します。 ディレクトリ構造は以下の通りです。 Scandit SDK ReactはTypeScriptに対応していませんので、jsxファイルとして作成しています。 各コードの詳細は後述します。 . ├── node_modules/ ├── public/ │ └── index.html ├── src/ │ ├── App.tsx │ ├── Scanner.jsx │ └── index.tsx ├── package-lock.json ├── package.json └── tsconfig.json ScanditのReactパッケージをインストールします。 yarn add scandit-sdk yarn add scandit-sdk-react トライアル用のライセンスキーを発行します。 こちら にアクセスしてアカウントを登録します。 "Add a project"からキーを発行します。 Web Appを選択します。 任意なプロジェクト名を設定します。 ドメイン名を設定します。 (※今回はローカルでサーバを起動させるため、ドメインは 127.0.0.1 にしてください) 発行されたライセンスキーを確認します。 4. Scandit用のコンポーネントを作成する ScanditのSDKを用いて、バーコードをスキャンするコンポーネントの作成手順について説明していきます。 Scandit SDK Reactによって提供される ScanditBarcodeScanner コンポーネントを利用することで、フロントエンドの開発のみで簡単にバーコードリーダを実装できます。詳細は こちら をご確認ください。 また、propsとして渡している ScanSettings では、読み取り対象となるバーコードの種類を指定しています。今回は一般的によく利用されている"code128"と"ean13"を指定しています。 他の種類のバーコードや詳細は こちら をご確認ください。 // src/Scanner.jsx import React from "react" ; import ScanditBarcodeScanner from "scandit-sdk-react" ; import { ScanSettings } from "scandit-sdk" ; export const Scanner = (props) => { // 3. ライセンスキーの発行にて取得したキーを設定する const licenseKey = "<ライセンスキー>" ; return ( <ScanditBarcodeScanner licenseKey= { licenseKey } scanSettings= { new ScanSettings( { enabledSymbologies: [ "code128" , "ean13" ] , // 同じバーコードを複数回読み取らないようにする codeDuplicateFilter: -1, } ) } engineLocation= "https://cdn.jsdelivr.net/npm/scandit-sdk@5.x/build" // スキャン結果がscanResultとして渡される onScan= { (scanResult) => props.handleScan(scanResult) } /> ); } ; 5. バーコードリーダーを表示する ここでは、前手順にて作成した Scanner コンポーネントを利用した画面を作成する手順を説明していきます。 // src/App.tsx import React , { useState } from "react" ; import { ScanResult } from "scandit-sdk" ; import { Scanner } from "./Scanner" ; export const App = () => { const [ codes , setCodes ] = useState < string [] >( [] ); // スキャン結果がScanResultとして渡されるので、それを元にstateに追加する // バーコードの値はScanResult.barcodes[0].dataで取得可能 const handleScan = ( scanResult: ScanResult ) => { setCodes (( prevState ) => [ ...prevState , scanResult.barcodes [ 0 ] .data ] ); } ; return ( < div > // 前手順にて作成したコンポーネントを表示する < Scanner handleScan = { handleScan } / > // バーコードの値が格納されていたら、それをリストアップする { codes && ( < ul > { codes.map (( code , index ) => ( < li key = { index } > { code } < /li > )) } < /ul > ) } < /div > ); } ; 次に、App.tsxを表示するためのルートコンポーネントを記載します。 // src/index.tsx import React from "react" ; import ReactDOM from "react-dom/client" ; import { App } from "./App" ; const root = ReactDOM.createRoot ( document .getElementById ( "root" ) as HTMLElement ); root.render ( < App / > ); 最後に、index.tsxを表示するためにHTMLファイルを記述します。 <!-- public/index.html --> <!DOCTYPE html> < html lang = "ja" > < head > < meta charset = "utf-8" /> < title > Scandit </ title > </ head > < body > < div id = "root" ></ div > </ body > </ html > まとめ 今回は、Scanditを用いてバーコードを読み取り、リストアップする簡単なアプリを作成する手順を紹介しました。 Scanditでは様々な環境向けのSDKを提供しており、とても簡単に自身の環境に組み込むことが可能です。 Webアプリをはじめとして、バーコードリーダを導入する際に候補として挙げてみてはいかがでしょうか。 参考 Scandit 公式サイト Scandit Barcode Scanner SDK for the Web Scandit SDK React - npm ※Scanditは、Scandit AGの米国およびその他の国における商標または登録商標です。

こんにちは、Insight EdgeのLead Engineerの日下です。 Insight Edgeでは、技術検証から実証実験、商用サービス開発に至るまで常日頃からAWSやGoogle Cloudなどのクラウドサービスを活用しており、開発サイクルのスピードアップに欠かせないツールとなっています。 一方、オンプレミスのハードウェアとは異なり、クラウドサービス利用時には開発者それぞれがコストを意識して使い方に気をつけないと、思わぬ課金が発生しまうこともあります。 本記事では、AWSでVPCネットワークを構築するときに思わぬコスト増の要因となりやすいNATゲートウェイの節約手段のひとつとして、NATインスタンスを手軽に作成する方法を紹介します。 要約 NATゲートウェイは料金が高く、用途によってはNATインスタンスの方がコスト最適 Amazon Linux 2のEC2インスタンス作成時にユーザーデータを指定することで、手軽にNATインスタスを作成可能 ユーザーデータのスクリプト CloudFormationテンプレート例 本番環境はNATゲートウェイ、開発環境はNATインスタンスなど、必要な性能や可用性に応じて使い分けるとよい NATゲートウェイはお高い AWSにおいて、VPCを構築しサーバやデータベースを配置するのは典型的なインフラ構築パターンのひとつであり、セキュリティを向上させるために各種サーバはプライベートサブネットに配置し、インターネットアクセスが必要な場合にはNATを経由するといった使い方がよくされます。 現在のAWSの 公式ドキュメント によるとNATの実装にはNATゲートウェイの利用を推奨していますが、実はNATゲートウェイは置いておくだけで月額約45USDかかるリソースであり、性能や可用性を求められない用途で使うにはちょっと高いなと感じてしまいます。 特に、開発や検証用など利用者が内部に限られている環境では、低スペックなNATインスタンスで十分なケースも多々あります。 プライベートサブネット内からたまにインターネットアクセスする程度、例えばCodeBuildでDockerイメージをPullしたり、依存ライブラリをインストールしたりなど開発ワークフローの中で時々通信が発生する程度であれば、最安のt4g.nanoで運用することも可能だったりします。 仮にt4g.nanoを利用してNATインスタンスを作成した場合、下表のようにEBSを含めてもNATゲートウェイの約1/10のコストでNAT機能を実現できます。 NATゲートウェイ 月額 NATインスタンス 月額 プロビジョニング (0.062USD/時) 44.64USD/月 コンピューティング (t4g.nano 0.0054USD/時) 3.888USD/月 データ処理(0.062USD/GB) データ量による EBSストレージ (gp3 8GB 0.096USD/GB月) 0.768USD/月 合計 44.64USD〜/月 合計 4.656USD/月 （2022年11月時点、東京リージョンでの比較。月額は30日で計算。VPCリソースにかかるアウトバウンド通信料金は同じ条件なので省略） また、NATインスタンスを利用する場合、必要な性能に応じてインスタンスタイプを調節したり、使わない時間帯はインスタンスを停止しておく、Saving Plansを適用するなど、通常のEC2インスタンスと同様のコスト最適化手段をとることも可能になります。 NATインスタンスを手軽に作成するには？ 以前はNATインスタンス用のAMIがAWSから提供されていましたがすでにサポートが切れており、現在はNATゲートウェイの利用が推奨されているためか、最新のAmazon Linux 2向けのAMIは公式には提供されていません。 Amazon Linux 2ベースでも必要なサービスをインストールして設定すればNATインスタンス化は可能であり、NATインスタンスの 公式ドキュメント を見るとNATインスタンスがユースケースに合致している場合には独自のNAT AMIを作成できると書かれていますが、 AMIをベースにすると、AMIの管理、共有、更新などが必要になってしまうため扱いが面倒 です。 そこで、EC2インスタンス作成時のオプション設定である ユーザーデータ を用いてAmazon Linux 2ベースのNATインスタンスを作成する方法を試してみました。 ユーザーデータによってEC2インスタンス作成時にNAT機能を有効化するスクリプトを実行することで、あらかじめ設定したAMIイメージを保存や共有したりすることなく、 任意のAWSアカウント及びリージョンで、その時の最新バージョンの公式AMIをベースにNATインスタンスを手軽に作成 できます。 さて、ここまでを読んで完全に理解した方は、 ユーザーデータのスクリプト または CloudFormationテンプレート例 までスキップしていただいても大丈夫です。 以下の節では、Amazon Linux 2のNATインスタンスを作成する具体的な手順を説明します。 Amazon Linux 2 で NATインスタンスを作成する手順 前提VPC環境 前提として下図のようなVPC環境があるものとします。 前提VPC環境 本記事の手順で新たに作成する部分は以下の赤文字の部分です。 本記事で作成する部分 AWSマネジメントコンソールからEC2インスタンスを作成 AWSマネジメントコンソールのGUIからEC2インスタンスを作成します。 本記事ではNAT料金の節約をテーマにしているため、最安となるt4g.nanoを利用する場合の手順を示します。 EC2の画面からインスタンスの起動を選択し、以下の通り設定していきます。 ベースとなるAMIは Amazon Linux 2 を選択 アーキテクチャは 64ビット(Arm) を選択 インスタンスタイプは t4g.nano を選択（Armアーキテクチャを選択していないと選択肢が現れないので注意） 次に、インスタンスに割り当てるキーペアを選択します。 本記事の手順ではインスタンスにログインしないため、キーペアなしでも問題ありません。 続いて、ネットワーク設定を編集します。 サブネットには、 パブリックサブネットを選択 パブリックIPの自動割り当てを有効化 （NATインスタンスはパブリックIPを持つ必要があるため） セキュリティグループは、（本記事では）VPCのデフォルトセキュリティグループを選択 実際に利用する際には、環境に応じて適切なセキュリティグループを割り当ててください。 NATインスタンスは、プライベートサブネットからの通信を受け取ってインターネットアクセスを行うため、セキュリティグループの インバウンドルールでプライベートサブネットからの通信を受け入れ 、 アウトバウンドルールでインターネットへのアクセス許可 が必要です。 ストレージ設定はデフォルトの8GBで作成します。 デフォルトのgp2でも良いですがgp3の方がやや安くコスパに優れるので、ここではgp3を選択しています。 高度な詳細 の設定項目を開きます。 設定項目最下部の ユーザーデータ に以下のスクリプトを設定します。 #!/bin/bash yum install -y iptables-services iptables -F echo 1 > /proc/sys/net/ipv4/ip_forward echo net.ipv4.ip_forward=1 >> /etc/sysctl.conf iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE service iptables save systemctl start iptables systemctl enable iptables ここまで設定したら、 インスタンスを起動 します。 ソース/宛先チェックを無効化 EC2インスタンス作成後、インスタンス一覧画面に戻りインスタンスのネットワーキング設定から、 ソース/宛先チェックを変更 を選択し、 停止 にチェックを入れて保存します。 これを設定しておかないと、プライベートサブネットから送信されるインターネット向けのパケットをインスタンスが受信できず、NATとして動作しません。 ここまで設定すれば、NATインスタンスの作成は完了です。 ルーティングテーブルを設定 NATインスタンスの作成が完了したら、NATゲートウェイ利用時と同様にルーティングテーブルを編集して、NATインスタンスを経由してインターネットにアクセスできるように設定します。 プライベートサブネットに割り当てられているルーティングテーブルを編集し、送信先 0.0.0.0/0 のターゲットにNATインスタンスを指定します。 動作確認 確認のために、プライベートサブネット内からインターネットアクセスを試してみます。 本記事では、プライベートサブネットに接続したLambda関数を作成して通信してみます。 Lambda関数を作成 Python 3.9でLambda関数を作成します。 アーキテクチャとアクセス権限はデフォルト設定で作成します。 詳細設定を開き、 VPCを有効化 にチェックを入れます。 NATインスタンスと同じVPCを選択 し、 プライベートサブネットを選択 します。 セキュリティグループはここではNATインスタンス同様、VPCのデフォルトセキュリティグループを使用します。 上記の設定で関数を作成します。 関数のコードを編集 Insight EdgeのWebサイトにアクセスするプログラムで実験してみます。 以下のようにコードを編集します。 # lambda_function.py from urllib.request import urlopen def lambda_handler (event, context): with urlopen( "https://insightedge.jp/" ) as f: res = f.read().decode() print (res) return { 'statusCode' : 200 , 'body' : res } Deployボタンを押して、関数をデプロイします。 実行 Testボタンを押して、新しいテスト用イベントを作成し、実行してみます。 以下のように、WebサイトのHTMLを取得できていれば成功です。 失敗するケースの確認 試しに、NATインスタンスを停止して実行してみます。 EC2コンソールからNATインスタンスを 停止 します（終了ではないので注意）。 Lambda関数の画面に戻り、Testボタンを押して再度実行してみます。 通信経路上のNATインスタンスが停止しているため、タイムアウトエラーが発生します。 CloudFormationでNATインスタンスを作成 CloudFormationでNATインスタンスを作成する場合のテンプレート定義例です。 インスタンス作成、およびソース/宛先チェック無効化を定義しています。 詳細な手順は割愛しますが、パラメータにAMIのID、パブリックサブネットのID、セキュリティグループIDを指定するとNATインスタンスを作成できます。 AWSTemplateFormatVersion : '2010-09-09' Description : Create NAT Instance. Parameters : amiId : Type : String Default : ami-082dd9d89994d3690 # Amazon Linux 2 (Arm64) 東京リージョン publicSubnetId : Type : String Default : subnet-xxxxxxxxxxxxxxxxx securityGroupId : Type : String Default : sg-xxxxxxxxxxxxxxxxx Resources : natInstance : Type : AWS::EC2::Instance Properties : ImageId : !Ref amiId InstanceType : t4g.nano NetworkInterfaces : - DeviceIndex : 0 SubnetId : !Ref publicSubnetId AssociatePublicIpAddress : true GroupSet : - !Ref securityGroupId BlockDeviceMappings : - DeviceName : /dev/xvda Ebs : VolumeSize : 8 VolumeType : gp3 Encrypted : true UserData : !Base64 | #!/bin/bash yum install -y iptables-services iptables -F echo 1 > /proc/sys/net/ipv4/ip_forward echo net.ipv4.ip_forward=1 >> /etc/sysctl.conf iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE service iptables save systemctl start iptables systemctl enable iptables SourceDestCheck : false # ソース/宛先チェックを無効化 Tags : - Key : Name Value : !Sub "${AWS::StackName}-nat-instance" まとめ 本記事では手軽かつ低コストでVPCにNAT機能を導入する方法として、ユーザーデータを用いたNATインスタンス作成方法を紹介しました。 単一のEC2インスタンスであるため、可用性が低い、自動スケールしない、パッチ当てなどの保守が必要といったデメリットはあるものの、NATゲートウェイに比べてコストを大幅に抑えられるのは魅力です。 そのため、本番環境ではNATゲートウェイを、開発環境ではNATインスタンスを利用するなど、必要な性能や可用性によって使い分けるとよいでしょう。

はじめに 本稿は、確率単体へ射影するアルゴリズムを調査した内容をまとめたものになります。この記事を書くきっかけは、知り合いから共有された (Wang, 2013) がシンプルでわかりやすく、他の手法にも興味が出てきたことです。調べていく中で、各アルゴリズムの計算速度も気になったので、簡易な性能比較も行いました。 確率単体への射影 問題設定 確率単体への射影（以下、本問題）は以下に示す凸最適化問題です。 但し 、 とします。確率単体は上記の制約条件を満たす領域を指します。 最適解の導出方法 本問題の最適解は となります。この をどのように求めるかがポイントとなっており、さまざまなアプローチがあります。 ラグランジュ関数 (Boyd) ではラグランジュ関数を以下のように変形することで最適解を導出しています。 はラグランジュ乗数です。 （ (Boyd) では第３項目の係数は でしたが、私の方で計算をすると となりました。） この関数を先に について解くことで、上記の最適解 が得られます。 は、 を代入したラグランジュ関数を基に二分法などを用いることで求められます。 Sort and Scan Sort and Scanという分類名称は (Yongzheng, 2022) に倣いました。 こちらの手法では最適解の導き方などが ラグランジュ関数 で示したものと異なります。詳細は割愛しますが、 (Duchi, 2008) ではKKT条件をうまく組み合わせることにより、 (Chen, 2011) では制約を指示関数として加えた目的関数に対するモーロー分解により、最適解を求めています。先と同様に、こちらも の値を求めないといけませんが、以下を計算することで容易に得られます。 入力 の要素を大きいものから順番に並び替えてできた変数を （ ）とすると、 に対し、 となります。 KKT条件を解く場合、有効になる不等式制約がわからないと非常に解きにくいです。 の定義に含まれる式は、それを効率よく見つけるものになっており、 はその個数を示しています（ (Chen, 2011) にはKKT条件が出てきませんが、入力に対する決定変数の大きさで同様の議論がなされています）。見つけられる理由は (Wang, 2013) にて、 の定義に含まれる式の挙動を確認するといった、シンプルでわかりやすい証明がなされています。 このアルゴリズムは入力のソートが計算時間のボトルネックになるため、ソートの仕方を工夫する研究が多く見られます。例えば、 (Duchi, 2008) ではソートの計算量が になるような手法が提案されています。 (Condat 2016) (Yongzheng, 2022) にはその他ソート手法や疑似コードなどがまとめられていますので、ご興味のある方はご覧になってください。 その他 (Wang, 2013) で述べられているように、有効制約法や内点法、一次法などの一般的なアルゴリズムでも本問題を解くことができます。それらのアルゴリズムは多くの文献で丁寧に説明がなされているため、詳細はそちらに譲ります。 性能比較 方法 上記で説明した (Boyd) 、 (Duchi, 2008) （ソート方法：ヒープソート）と一次法との計算速度を比較しました。計算速度の指標は、アルゴリズムを実行してから解が出力されるまでの計算時間としています。確率単体へ射影する は、 次元の一様乱数をその ノルムで正規化し、各要素を 倍して得られるベクトルとしました。また性能比較では次元数 に対する計算時間を確認しており、各 での計算時間は を 回生成し、個別に最適化した時の計算時間の平均値とします。 本稿での性能比較の目的は、 (Boyd) 、 (Duchi, 2008) らの手法がよく使われるライブラリ（ソルバー）よりどのくらい速いのかを知ることとしています。これらの手法は 「参考：実装コード」 に示している通り、Python言語で実装しています。一方、今回はよく使われるライブラリに CVXPY を採用しており、そのソルバーである OSQP はC言語で実装されています。実装言語は異なりますが、 を十分大きくすると実装言語による影響は小さくなると考えられ、十分比較できるものと考えています。（ OSQP は、本問題のような二次計画問題のデフォルトで使用されるソルバーで、一次法であるADMMをベースとしています。） 結果、所感 下のグラフは、 を変えた時の各手法の計算速度を示しています。 が 程度までの時は (Duchi, 2008) が最も計算時間が速く、それ以降では (Boyd) が最も速いという結果が得られました。この原因の1つとして、今回の (Duchi, 2008) では計算量が のヒープソートを用いている一方、 (Boyd) では初期の探索範囲に依存する二分探索を用いており、 の影響を受けにくいためと思われます。また を大きくしていくと 程度の時に (Duchi, 2008) の計算時間は一次法を上回りました。一方、一次法と(Boyd)はグラフを見る限り、計算時間の増加度合いが同様に見られるため、（通常一概に言えませんが）本問題において計算量は同様のオーダーだと思われます。 今回、 (Duchi, 2008) や (Boyd) はPythonで実装していたため、より高速に計算する必要が出てきた場合はCythonを用いたり、また (Duchi, 2008) などで提案されているソート方法を用いるのが良いかと思います。 計算時間の比較 まとめ 本稿では、確率単体へ射影するアルゴリズムを調査し、その計算時間の速さを確認しました。確率単体へ射影する問題は凸最適化問題であり、（一般的な手法を除いて）アルゴリズムの主な違いは最適解に含まれるパラメータを求める方法の違いになっていました。また動作確認を行なった結果、本実験では次元数が 程度までの時は (Duchi, 2008) （ソート方法：ヒートソープ） が最も早く、それ以降は二分法を用いた (Boyd) の方法が最も早いことがわかりました。ソート方法や実装方法などによっても結果は大きく変わり得ますが、この結果を今後の業務に役立てられたらと思います。 参考文献 Wang Weiran, and Miguel A. Carreira-Perpinán. "Projection onto the probability simplex: An efficient algorithm with a simple proof, and an application." arXiv preprint arXiv:1309.1541 (2013). Boyd Stephenの講義資料 Yongzheng Dai, Chen Chen. "Distributed Projections onto a Simplex.", (2022). Duchi John, et al. "Efficient projections onto the l 1-ball for learning in high dimensions." Proceedings of the 25th international conference on Machine learning. (2008). Chen Yunmei, and Xiaojing Ye. "Projection onto a simplex." arXiv preprint arXiv:1101.6081 (2011). Condat Laurent. "Fast projection onto the simplex and the $\pmb {l} _\mathbf {1}$ ball." Mathematical Programming 158.1 (2016): 575-585. CVXPY Stellato, Bartolomeo, et al. "OSQP: An operator splitting solver for quadratic programs." Mathematical Programming Computation 12.4 (2020): 637-672. 参考：実装コード 以下、参考として掲載いたします。動作確認はしていますが、実運用を見据えたコードではないためご使用の際はご注意ください。 特に、二分法は初期点のチェックをしておらず、探索範囲を固定していますので、入力によっては解が得られない（計算が終わらない）場合があります。 import numpy as np import pandas as pd import cvxpy as cp class DuchiMethod (): def __init__ (self, input_vector): self.input_vector = input_vector self.length_vector = len (input_vector) self.sort_vector = None def _sub_function (self, index): # 昇順であるため、分母の形が論文と異なる return ( 1 /(self.length_vector - index) )* \ ( 1 - np.sum(self.sort_vector[index:])) def _function (self, index): return self.sort_vector[index] + self._sub_function(index) def main (self): self.sort_vector = np.sort(self.input_vector, kind = 'heap_sort' ) target_index = self.length_vector - 1 while self._function(target_index) >= 0 : target_index -= 1 if target_index < 0 : break target_index += 1 # lambdaと最適解 _lambda = self._sub_function(target_index) return np.array( [ max (_lambda + component, 0 ) for component in self.input_vector] ) class BoydMethod (): def __init__ (self, input_vector): self.input_vector = input_vector self.length_vector = len (input_vector) self.EPS = 1e-5 ## 変数の準備 # _lambda self._lambda_upper = ( 2 ** 4 ) # 初期点は固定した。 self._lambda_lower = - 1 * self._lambda_upper self._lambda_medium = 0 ## 関数の値 # 箱 self.value_upper = self._grad_dual_function(self._lambda_upper) self.value_lower = self._grad_dual_function(self._lambda_lower) self.value_medium = self._grad_dual_function(self._lambda_medium) ## 初期点が適切かどうかを確認するコード。 ## 適切でなかった際、初期点を変更する関数は追加で書く必要がある。 #self.check = self._initial_check() #def _initial_check(self): # return np.sign(self.value_upper) * np.sign(self.value_lower) def _grad_dual_function (self, _lambda): ## 第一項 # 準備 inner = self.input_vector - _lambda positive_mask = inner > 0 # 計算 term_1 = inner term_1[positive_mask] = 0 term_1 = - 1 * np.sum(term_1) ## 第2項 term_2 = np.sum(self.input_vector) - 1 ## 第3項 term_3 = - 1 * self.length_vector * _lambda return term_1 + term_2 + term_3 def _compare_value (self): if np.sign(self.value_upper) == np.sign(self.value_medium): return 'change upper' else : return 'change lower' def _cal_solution (self, _lambda): solution = np.zeros([self.length_vector, 2 ]) solution[:, 0 ] = self.input_vector - _lambda solution = np.max(solution, axis = 1 ) return solution def main (self): while np.linalg.norm(self.value_medium) > self.EPS: # _lambda, valueの確認・更新 if self._compare_value() == 'change lower' : self._lambda_lower = self._lambda_medium self.value_lower = self.value_medium elif self._compare_value() == 'change upper' : self._lambda_upper = self._lambda_medium self.value_upper = self.value_medium # 残りの変数の更新 self._lambda_medium = (self._lambda_lower + self._lambda_upper) / 2 self.value_medium = self._grad_dual_function(self._lambda_medium) return self._cal_solution(self._lambda_medium) class FirstOrderMethod (): def __init__ (self, input_vector): self.input_vector = input_vector self.length_vector = len (input_vector) def main (self): x = cp.Variable(self.length_vector) prob = cp.Problem( cp.Minimize(( 1 / 2 )*cp.sum_squares(x - self.input_vector)), [cp.sum(x) == 1 , x >= 0 ] ) prob.solve(solver=cp.OSQP) return x.value if __name__ == '__main__' : ## サンプル例 n = 10 coef = 10 #coef = 0.1 # 動作確認 random_y = np.random.rand(n) y = coef * ( random_y / np.linalg.norm(random_y, ord = 1 )) # 確認 duchi_method = DuchiMethod(y) d_output = duchi_method.main() print ( 'DuchiMethodの動作確認結果' , ' \n 出力の合計は：' , np.sum(d_output), ' \n 全て正の値：' , np.all(d_output >= 0 ) ) boyd_method = BoydMethod(y) b_output = boyd_method.main() print ( 'BoydMethodの動作確認結果' , ' \n 出力の合計は：' , np.sum(b_output), ' \n 全て正の値：' , np.all(b_output >= 0 ) ) first_method = FirstOrderMethod(y) f_output = first_method.main() print ( 'FirstOrderMethodの動作確認結果' , ' \n 出力の合計は：' , np.sum(f_output), ' \n 全て正の値：' , np.all(f_output >= 0 ) # 負の値が存在するが、絶対値は十分小さい )

こんにちは！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 ↩