こんにちはXI本部、AIトランスフォーメーションセンターの徳原光です 現在、私が所属しているAIトランスフォーメーションセンター（通称：AITC）では、新卒、中途問わず、データサイエンティストとして働いてくださる方を絶賛募集中です。 AITCwebサイト 採用情報ページ|AITCwebサイト 例年、AITCへの配属が内定する新卒向けデータサイエンティスト職採用を実施していますが、今年も実施します。詳しい情報が出ましたら、こちらのページでお知らせします。 といいつつ、「いきなりうちの部で働いてください！」と言われても、判断に困ると思うので、自分の働き方をアンケート形式でまとめてみました（同じアンケートを中途の方を含め数人の方に答えていただいているので、順次テックブログまたはAITC webサイトで公開していきます）。 担当されているプロジェクトについて教えてください １つ目はデータ活用、データ活用・AI導入支援プロジェクトです。お客様は一般消費者向けの製品を開発しているメーカー企業で（おそらく読者の方もこの会社の製品を使ったことがあると思います）、社内にある顧客情報や受注データ、オプション部品情報などのデータを活用して、売上向上を図る施策を提案・実装しています。 企業内で溜まっているけど活用されていないデータを整理しながら、様々な部署に ヒアリ ングを実施します。そして、在庫管理、サービス向上、 マーケティング などの視点でデータ活用案を提示し、データ処理のための スクリプト の実装や 機械学習 モデルの構築などを行っています。 データ活用のための戦略を立てる部分から、実際に実現可能か検証(PoC)するための実装までを担う必要があり、提案した施策を実運用にこぎつけるにはいろいろな困難がありますが、その分学ぶことが多いプロジェクトだと思ってます。 2つ目は精密部品メーカーのお客様に対して実施している、製品検査支援AIシステムの開発です。製品の検査画像から欠陥の可能性がある部分を画像処理AIで検出することで、検査員の方の作業を軽減するシステムを開発しています。 こちらのシステムはすでにお客様の工場で稼働しているので、現在はよりビジネス的な価値を創出できるように検出精度を向上させるための試行錯誤（モデルの再学習や異常判定 アルゴリズム の改善）を行っています。 この他に、ISIDの1年目の方に向けて半年間実施される新人研修の運営や部署サイトの更新作業、部内で開発しているAIソフトウェアの マーケティング などを担当しています。 一日の流れについて教えてください 一週間の中で月曜日と金曜日は会議が多いです。月に2, 3回、お客様に対する進捗報告会を実施しています。AIを活用したプロジェクトではプロジェク実施前に結果が予想しにくく、コンセプト検証（PoC）という形で、プロジェクト実施中にお客様と実施事項を逐次検討する必要があります。 読書会や勉強会は毎期実施しています。AITC内の勉強会の他に、他部署の方と実施しているインフラや システム開発 に関する勉強会にも参加しています。勉強会はスキルの向上だけじゃなく、社内の交流の場にもなっていると思います。 作業が多めの日ではコーディングや資料作成を主に行っています。現在実施しているプロジェクトはお客様の企業内にある様々なデータ（発注情報や顧客情報）を活用してビジネス価値を生み出すという案件なので、モデルに入力するためのデータを準備するために、データクレンジングや複数テーブルのデータを結合するための前処理 スクリプト を実装しています。モブプロ形式で実装することもあり、データを扱うノウハウやテクニックを先輩から学ぶ（盗む）ことができます。 週に一度会社の同期のメンバーでフットサルをやっています。同期ど うしの つながりは他の会社と比較しても強いほうだと思っています。会社の同期とはプライベートでも頻繁に会いますし、仕事でも部署を超えたプロジェクトを実施する際は、部のメンバーレベルで話合う前に、相手の部に所属している同期と予め情報交換しておいたり、内容をすり合わせたりするので、ある意味一つの社内組織のように機能していると思います。 今の仕事に対して気に入っている点はなんですか？ AITCの良いところは若い年次から能動的に挑戦できる環境があることに尽きると思っています。これは会社全体に言えることですが、大企業的に少しづつタスクを指示されながら徐々に裁量を増やすのではなく、ISIDでは個人の自発的な行動が最も重視されるので、最初から自主的に挑戦したい仕事に アサイ ンしてもらうことができます。 さらに、AITCが取り組んでいるAIプロジェクトは「こうすればうまくいく」という方法がないので、一人一人が若手、ベテラン関係なくどうすればプロジェクトを成功に導けるか考えて行動することが求められます。 私は最初からうまくいく方法を学ぶのではなく、どうすればうまくいくのか試行錯誤しながら、答えを出すためのスキルを学びたいと考えているので、ワクワクしながら仕事に取り組めています。 さらに、様々な業界でデータサイエンティストやMLエンジニアとして活躍してきた方と一緒に働いているので、自分だけでは太刀打ちできない課題に直面してもすぐにバックアップしていただける安心感もありますね。 逆に気に入ってない点はありますか？ 他部との交流が少ないです。AITCが所属しているXI本部は クラウド 、 VR 、UX、構成管理など様々な分野のプロフェッショナルが集まった組織ですし、都市OSや SaaS 型のパッケージシステムの開発など魅力的なプロジェクトに携わっている方が多く在籍していますが、AITCの部として結束力が強いせいか、プロジェクトレベルでの協力関係はあまりないと感じています。 もちろん、プライベートや勉強会などでは交流する機会はありますが、他の事業部の人も含めて仕事を通して協力しあえる場面が増えるといいと思っています（ シナジー を生み出す的な）。 最近は社内でデータ分析やAIモデル構築のスキルを身に着けたい人が増えてきているので、そのような他部署の方に少しづつAITCのプロジェクトに参加していただいています。さらに、これからはデータ以外のことを学ぶために自分が部署外のプロジェクトに参加してみたいですね。 就職活動(転職活動)の際に、自己のキャリアで最も重視したポイントはなんですか？ なかなか 言語化 しにくい概念ですが、自分と価値観が似ている人がイキイキと働いている職場に行きたいなと考えていました。働くことの意義はお金を貰えることだけじゃないと就活生時代考えていましたし、今もそう思っています。 ただ、何を持ってやりがいや達成感を感じるかは人によって違うので、自分と同じような考え方をする人が楽しそうに働ける環境に身を置くことを重視していました。 実際に入ってみてどうでしたか？ 日々の業務の中で、挑戦したいことや頑張りたいことがたくさんあるので、就活生時代の自分の見立ては間違ってなかったと思っています。 もちろんやりたい仕事ばかりじゃなくて、やる意味を見いだせないタスクもあります。そういうときは自分から声を上げてやり方を変えたり、そもそも実施するか検討できるので不満はないです。ただ、いろいろ考えたあげく結局やるしかないという結論に至ることも多いですが。 「自分と価値観が似ている人がイキイキと働いている」というのは確かにそうだったのですが、ISIDとして、AITCとしてこういう価値観であるべきというものが特にないので、いろんな価値観の人が自分らしく働ける環境だと思います。ただ、組織としてスタンダードがないので、初めて組む人と仕事をするときは、相手に合わせて自分も相手も活かすということをメンバー全員が個人レベルで行う必要があるなと感じていて、そこが今の自分の課題だと思っています。 今後の目標している キャリアパス について教えて下さい XI本部の他の部署を含め、AITCでは、 スペシャ リストとして、データサイエンティストやMLエンジニアのキャリアを突き詰めてい行きたいと考えている人が多いように思えますが、自分はIT全般に精通して、会社単位でITを用いてビジネス価値を創出するにはどういうすればいいのか、ビジネス全般を導けるような人材になりたいと考えています。 そのために最も大事なことがデータに精通することだと考えています。ITの力で実際に扱うことができるのは現実に存在する商品やサービスではなくデータだけです（IoT機器やロボットアームを制御すれば物体に直 接触 れるのは一応可能ですね）。 ですが、お客様のデータを触っていく中で、現実に存在する物体とデータは一対一の関係を持っていて、データを加工したり、新しい情報を生み出すことで、対応する商品やサービスにも影響を与えられる感覚をなんとなくですが理解した気がしています（多分気がしているだけです）。 正直今は自分の判断や仕事の質に自信が持てない状態ですが、この「現実とデータの関係」という概念を突き詰めていくことで、いつか自分はITを使ってビジネス価値を生み出すことをマクロな視点でとらえられるようになると自信をもって思っています。今の自分の立場はデータサイエンティストとしてズカズカとお客様の経営と現場両方向に浸食していけるので、日々必要な知識を吸収することができます。 最後に就活生or転職者の方に一言！ おそらくですが、このテックブログではすでに、情報技術に精通している学生や転職者の方に向けたメッセージが多いと思うので、自分はあえてそもそもIT業界で働くか検討している段階の方に向けてメッセージを書きたいと思います。 私は学生時代から学校や研究室で情報っぽいことをやってましたし、就活時代もIT企業にこだわって就職活動を進めていました。ですが、周りに技術に対して情熱を燃やしながら向き合っている人に囲まれながら、最近はあまり特定の技術に対して執着しなくなってきました。自分の中ではあくまでITは手段であり、目的ではないと思っています（逆に周りにはITと無縁だった人で今は技術に熱心に取り組まれている方が多いですね）。 ただ、確実にいえることは、ISIDで取り扱っている情報技術、とりわけ自分が所属しているAITCが取り組んでいるデータサイエンスやAIの技術は現在世の中に存在するあらゆる業界、分野の中で最も強力な手法であるということです。 必ずしも、それ（IT）がやりたいわけじゃないけれど、自分が叶えたいことを実現するには確かに今向き合ているものが必要になるのです。なので、今の環境は自分の現時点のキャリアにとって最高とは言いませんが、いい環境だと思ってます。 そのためには、辛抱強く今ある現実の鏡としてのデータと向き合うことが大切だと思います。もちろん、やり方を変えたり、0から作り直すことも必要ですが、目の前にあるデータからできるだけ価値を絞り出すことが大事だと今は思っています。よく、就活イベントで就活生からITのスキルや知識は必要かと聞かれますが、一 番役 に立つのは忍耐力です。諦めなければスキルはあとからついてくると信じて仕事をしています。 ということで、むむっと思った方は気軽にお声掛けください。現在AITCwebサイト内にカジュアル面談用のフォームを作成していますので、下のフォームからご応募ください。データサイエンティスト職に関する面談はもちろん、ISIDの総合職に関する面談も可能です（適切な方にお繋ぎします）。 AITCデータサイエンティスト職カジュアル面談申し込みフォーム AITCwebサイトでは技術に関するコラムや日々の活動の記録を公開していますのでぜひ御覧ください 採用情報ページ|AITCwebサイト AITCコラム一覧 「2022年度 製品開発グループ夏合宿」を開催しました データサイエンティストの勉強会をご紹介！ オンラインならではの工夫とは？ それでは。 執筆： @tokuhara.hikaru 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回のテーマは、「折り紙合体変形ロボ」です。 仕事で折り紙を使った作品を作っていたのですが、そのとき、偶然に「折り紙合体変形ロボ」が出力されたんです。 これは面白いと思い、「折り紙合体変形ロボ」を再現できる呪文を研究してみました。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 偶然出力された「折り紙合体変形ロボ」 再現性のある「折り紙合体変形ロボ」 まとめ 仲間募集 Stable Diffusionの全コンテンツ 偶然出力された「折り紙合体変形ロボ」 最初に、偶然出力された「折り紙合体変形ロボ」の呪文と出力結果をお見せします。 横長の呪文（コピー&ペースト用） concept art of crowded multi colored various streamline origami flowing through cosmos from front to back artstation deviantart impressive scene impressive composition impressive lighting 改行版（閲覧用） concept art of crowded multi colored various streamline origami flowing through cosmos from front to back artstation deviantart impressive scene impressive composition impressive lighting 出力結果はこちら。 折り紙が組み合わされて、本当に、ロボットのようになっていますね。偶然の結果で、再現性が全くありません。どうしてあの呪文からこの結果が出力されるのか、全く理解できません。 また、これも偶然、 AI画像コンテスト が開催されていることを知りました。 これは、運命だと思い 「折り紙合体変形ロボ」でコンテストに参加しました 。 もし、「折り紙合体変形ロボ」が気に入ってもらえたのなら、 投票していただければ幸いです。 再現性のある「折り紙合体変形ロボ」 次に、再現性のある「折り紙合体変形ロボ」の呪文と出力結果をお見せします。 横長の呪文（コピー&ペースト用） concept art of low poly robot multi colored origami hybrid made of multi colored origami artstation deviantart impressive scene impressive composition impressive lighting PlayStation5 改行版（閲覧用） concept art of low poly robot multi colored origami hybrid made of multi colored origami artstation deviantart impressive scene impressive composition impressive lighting PlayStation5 ポイントは3つあります。 1つ目が low poly （荒いポリゴン）です。荒いポリゴンの平面が折り紙と混ざりやすくなります。 2つ目が ... robot ... origami hybrid （ロボットと折り紙のハイブリッド）です。このプロンプトでロボットと折り紙が混ざりやすくなります。 3つ目が made of multi colored origami （複数の色の折り紙でできている）です。 hybrid だけだとプロンプトとして弱いので、 made of でさらにロボットに折り紙が混ざりやすくします。 出力結果はこちらのようになります。偶然版ほどのクオリティはありませんが、「折り紙合体変形ロボ」が再現されていますね。 low poly をつけていない場合の出力結果はこちらのようになります。普通のロボットですね。折り紙感が全くないです。 まとめ 今回は、Stable Diffusionが出力した想定外の結果を元に、呪文の研究を行いました。Stable Diffusionの想定外の結果も楽しみの一つにしましょう。 次回は、 v2.0 美少女イラスト です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa 、レビュー： @fhiroaki （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回のテーマは、「折り紙合体変形ロボ」です。 仕事で折り紙を使った作品を作っていたのですが、そのとき、偶然に「折り紙合体変形ロボ」が出力されたんです。 これは面白いと思い、「折り紙合体変形ロボ」を再現できる呪文を研究してみました。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 偶然出力された「折り紙合体変形ロボ」 再現性のある「折り紙合体変形ロボ」 まとめ 仲間募集 Stable Diffusionの全コンテンツ 偶然出力された「折り紙合体変形ロボ」 最初に、偶然出力された「折り紙合体変形ロボ」の呪文と出力結果をお見せします。 横長の呪文（コピー&ペースト用） concept art of crowded multi colored various streamline origami flowing through cosmos from front to back artstation deviantart impressive scene impressive composition impressive lighting 改行版（閲覧用） concept art of crowded multi colored various streamline origami flowing through cosmos from front to back artstation deviantart impressive scene impressive composition impressive lighting 出力結果はこちら。 折り紙が組み合わされて、本当に、ロボットのようになっていますね。偶然の結果で、再現性が全くありません。どうしてあの呪文からこの結果が出力されるのか、全く理解できません。 また、これも偶然、 AI画像コンテスト が開催されていることを知りました。 これは、運命だと思い 「折り紙合体変形ロボ」でコンテストに参加しました 。 もし、「折り紙合体変形ロボ」が気に入ってもらえたのなら、 投票していただければ幸いです。 再現性のある「折り紙合体変形ロボ」 次に、再現性のある「折り紙合体変形ロボ」の呪文と出力結果をお見せします。 横長の呪文（コピー&ペースト用） concept art of low poly robot multi colored origami hybrid made of multi colored origami artstation deviantart impressive scene impressive composition impressive lighting PlayStation5 改行版（閲覧用） concept art of low poly robot multi colored origami hybrid made of multi colored origami artstation deviantart impressive scene impressive composition impressive lighting PlayStation5 ポイントは3つあります。 1つ目が low poly （荒いポリゴン）です。荒いポリゴンの平面が折り紙と混ざりやすくなります。 2つ目が ... robot ... origami hybrid （ロボットと折り紙のハイブリッド）です。このプロンプトでロボットと折り紙が混ざりやすくなります。 3つ目が made of multi colored origami （複数の色の折り紙でできている）です。 hybrid だけだとプロンプトとして弱いので、 made of でさらにロボットに折り紙が混ざりやすくします。 出力結果はこちらのようになります。偶然版ほどのクオリティはありませんが、「折り紙合体変形ロボ」が再現されていますね。 low poly をつけていない場合の出力結果はこちらのようになります。普通のロボットですね。折り紙感が全くないです。 まとめ 今回は、Stable Diffusionが出力した想定外の結果を元に、呪文の研究を行いました。Stable Diffusionの想定外の結果も楽しみの一つにしましょう。 次回は、 v2.0 美少女イラスト です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa 、レビュー： @fhiroaki （ Shodo で執筆されました ）

こんにちは。X イノベーション 本部ソフトウェアデザインセンターの陳です。 X イノベーション 本部では、有志メンバーで論文輪読会を実施しています。 （詳細は こちらの記事 をご参照ください） 本記事では私が担当した論文を簡単にまとめます。 今回紹介した論文 私が担当した論文輪読会では以下の論文を紹介しました。 Large Scale Analysis of Multitasking Behavior During Remote Meetings 　(Hanchen Cao , Chia-Jung Lee, Shamsi Lqbal, Mary Czerwinski, Priscilla Wong, Sean Rintel, Brent Hecht, Jaime Teevan and Longqi Yang 2021) こちらの論文は、 スタンフォード大学 の学生が Microsoft 社との共同研究で執筆し、CHI2021国際カンファレンスで特別賞を受賞した論文です。 タイトルを日本語に翻訳すると、「リモート会議中の マルチタスク 行動に関する大規模分析」になります。 マルチタスク とは、複数のタスク・活動を同時並行または短期間で切り替えながら、同時進行で行うことを指します。つまり内職の話ですね。 新型コロナウイルス の影響でテレワークが一般的な働き方になり、テレワークした経験のある方なら誰でも内職したことがあると思いますが、この論文のタイトルを読むととても興味深く感じました。 研究の概要 この研究では Microsoft から収集した社員のデータに基づいて分析を行いました。 リモート会議の規模、長さ、時間、タイプなどの要因と マルチタスク との関係性および マルチタスク によるポジティブとネガティブな効果を明らかにしました。 作者はリサーチク エス チョンを4つ挙げました。 リモート会議で行われた マルチタスク はどれくらいありますか？ リモート会議での マルチタスク に関連する要因はなんですか？ リモート会議でどんな マルチタスク が行われましたか？ リモート会議での マルチタスク はどんな影響をもたらしますか？ 研究手法 この研究では主に2つの研究手法が使われました。 2020年2月-5月の Microsoft 米国社の従業員データを使った大規模 テレメトリー データの回帰分析 テレメトリー データとはソフトウェアやアプリケーションが収集するユーザーの利用状況データのことを指す 回帰分析は、因果関係を関数の形で明らかにする統計的手法 Microsoft グローバル社員715人を対象としたダイアリー・ スタディ （2020年4月中旬-8月中旬） ダイアリー・ スタディ は参加者に調査中の活動や経験を一定期間にわたり記録させる研究方法 大規模 テレメトリー データの回帰分析では、社員の Microsoft Teams、 Outlook 、OneDriveと SharePoint に関する メタデータ を収集しました。しかし、プライバシー保護のため、個人情報やすべての行動の詳細なデータを収集できませんでした。また、 マルチタスク を行う心理やその影響を分析するには 定量 分析だけだと不十分のため、この論文ではダイアリー・ スタディ を実施することで 定量 分析の結果を補完しました。 研究結果 リモート会議で行われた マルチタスク はどれくらいありますか？ データを分析すると、30%前後のリモート会議でメールの マルチタスク が行われ、25%前後のリモート会議でファイル編集の マルチタスク が行われていました。 多くの マルチタスク は仕事リズムの変化によるものの可能性があります。 出社が多い時期のデータをリモートワークが定着後のデータと比較すると、メールやファイル編集のタスクの量が変わらない一方、リモート会議のタスクが大幅に増加しました。 マルチタスク は働き方の変化によるものの可能性を示しました。 また、ビデオオフや音声オフの場合はより多くの マルチタスク が発生することも明らかになりました。 リモート会議での マルチタスク に関連する要因はなんですか？ 内部要因として、以下の4点が挙げられました。 人数の多い会議 長時間会議 朝の会議 定例や事前に予定されている会議（エンゲージメントが低い会議） この4つの特徴を持つリモート会議は他のリモート会議より マルチタスク の頻度が高いです。 外部要因として、ダイアリー・ スタディ では以下の3点が挙げられました。 他の仕事に追いつくため 会議が多すぎて、仕事が終わらない 他のことに気を散らしたため Teamsの通知で気を散らしたなど 不安を和らげるため 新型コロナウイルス が流行り始めたごろの不安 不安を和らげるために スマホ ゲームをした人がいた リモート会議でどんな マルチタスク が行われましたか？ 社員に対するダイアリー・ スタディ によると、仕事に関連する マルチタスク が多かったです。参加者の29%は「メールの マルチタスク 」と回答しました。「実行時間が長い スクリプト の確認」や「テスト実行」の回答もありました。一方、リモート会議でのファイルの編集については、会議に関連する場合がほとんどです。 仕事以外の マルチタスク に関しては、 SNS や、食事、家事、エクササイズと回答した人もいました。 リモート会議での マルチタスク はどんな影響をもたらしますか？ ポジティブな影響に関しては、ダイアリー・ スタディ の参加者の15%は「生産性の向上につながった」と回答しました。社員は集中力が必要でない重要度の低い会議では マルチタスク する傾向があります。 重要度の低い会議で、別の仕事をすることで生産性が向上したでしょう。 一方、ネガティブな影響もありました。36%の参加者は「集中力やエンゲージメントの低下」と回答しました。他にも「精神的 疲労 につながる」、「発言者に失礼」のような回答がありました。 研究からの提案 作者は研究の結果からリモート会議に対して以下の5つの ガイドライン を提案しました。 重要な会議は朝を避ける 必要ではない会議を減らす 会議を短くして、休憩時間を入れる 参加者の一部を積極的に会議に貢献させる ポジティブな マルチタスク の存在を許与する また、リモート会議システムのデザインに対しても以下の提案をしました。 会議中に、無関連のポップアップをブロックする“集中モード”を選択できるようにする 会議と同じ画面で議事録やファイルの編集ができるようにする 会議に対して重要度のランク付けができるようにし、カレンダーに表示させる 会議の アジェンダ から注意が必要な部分を表記しあらかじめ参加者に表示する 読んでみた感想 「大人数の会議や長時間会議、聞くだけの会議では内職しやすい」、「内職で生産性を上げた人もいれば気をそらしたからネガティブな効果を感じた人もいる」など確かにと思うような結論が多かったですね。 しかし、経験者が当たり前のように思うことを大量なデータを使って検証できたことはこの論文の貢献だと思います。 また「 マルチタスク は社員の幸福度や生産性につながる」など、内職という課題の重要性を示し、ポジティブな効果をもたらす内職を許容すると提唱するのもこの論文の素晴らしいところですね。無駄な会議を減らし、会議の質を上げるのはテレワーク時代の課題だと考えられます。 この研究は 新型コロナウイルス が大流行になった直後（つまり、出社からテレワークの働き方に切り替えた直後）、また Microsoft 社だけのデータを利用したところが限界として挙げられます。テレワークが定着した現在、またはIT業界以外の会社のデータを使ったら、結果はどう変わるかが気になります。 まとめ 本記事では、論文輪読会で私が担当した論文を紹介しました。 論文輪読会で、普段やっている仕事と全く違う分野の技術をみんなで議論することができました。 また、興味がある学会やカンファレンスの論文を調べることで、最新の研究動向や研究手法についても多く学びました。 皆さんもぜひ学術論文を読んでみてください。 私たちは同じグループで共に働いていただける仲間を募集しています。 現在募集している職種は以下です。 ソリューションアーキテクト 論文輪読会をはじめとした各種勉強会に気軽に参加できるような環境で働くことに興味のある皆様、ぜひご応募お待ちしています！ 執筆： @chen.xinying 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

こんにちは。X イノベーション 本部ソフトウェアデザインセンターの陳です。 X イノベーション 本部では、有志メンバーで論文輪読会を実施しています。 （詳細は こちらの記事 をご参照ください） 本記事では私が担当した論文を簡単にまとめます。 今回紹介した論文 私が担当した論文輪読会では以下の論文を紹介しました。 Large Scale Analysis of Multitasking Behavior During Remote Meetings 　(Hanchen Cao , Chia-Jung Lee, Shamsi Lqbal, Mary Czerwinski, Priscilla Wong, Sean Rintel, Brent Hecht, Jaime Teevan and Longqi Yang 2021) こちらの論文は、 スタンフォード大学 の学生が Microsoft 社との共同研究で執筆し、CHI2021国際カンファレンスで特別賞を受賞した論文です。 タイトルを日本語に翻訳すると、「リモート会議中の マルチタスク 行動に関する大規模分析」になります。 マルチタスク とは、複数のタスク・活動を同時並行または短期間で切り替えながら、同時進行で行うことを指します。つまり内職の話ですね。 新型コロナウイルス の影響でテレワークが一般的な働き方になり、テレワークした経験のある方なら誰でも内職したことがあると思いますが、この論文のタイトルを読むととても興味深く感じました。 研究の概要 この研究では Microsoft から収集した社員のデータに基づいて分析を行いました。 リモート会議の規模、長さ、時間、タイプなどの要因と マルチタスク との関係性および マルチタスク によるポジティブとネガティブな効果を明らかにしました。 作者はリサーチク エス チョンを4つ挙げました。 リモート会議で行われた マルチタスク はどれくらいありますか？ リモート会議での マルチタスク に関連する要因はなんですか？ リモート会議でどんな マルチタスク が行われましたか？ リモート会議での マルチタスク はどんな影響をもたらしますか？ 研究手法 この研究では主に2つの研究手法が使われました。 2020年2月-5月の Microsoft 米国社の従業員データを使った大規模 テレメトリー データの回帰分析 テレメトリー データとはソフトウェアやアプリケーションが収集するユーザーの利用状況データのことを指す 回帰分析は、因果関係を関数の形で明らかにする統計的手法 Microsoft グローバル社員715人を対象としたダイアリー・ スタディ （2020年4月中旬-8月中旬） ダイアリー・ スタディ は参加者に調査中の活動や経験を一定期間にわたり記録させる研究方法 大規模 テレメトリー データの回帰分析では、社員の Microsoft Teams、 Outlook 、OneDriveと SharePoint に関する メタデータ を収集しました。しかし、プライバシー保護のため、個人情報やすべての行動の詳細なデータを収集できませんでした。また、 マルチタスク を行う心理やその影響を分析するには 定量 分析だけだと不十分のため、この論文ではダイアリー・ スタディ を実施することで 定量 分析の結果を補完しました。 研究結果 リモート会議で行われた マルチタスク はどれくらいありますか？ データを分析すると、30%前後のリモート会議でメールの マルチタスク が行われ、25%前後のリモート会議でファイル編集の マルチタスク が行われていました。 多くの マルチタスク は仕事リズムの変化によるものの可能性があります。 出社が多い時期のデータをリモートワークが定着後のデータと比較すると、メールやファイル編集のタスクの量が変わらない一方、リモート会議のタスクが大幅に増加しました。 マルチタスク は働き方の変化によるものの可能性を示しました。 また、ビデオオフや音声オフの場合はより多くの マルチタスク が発生することも明らかになりました。 リモート会議での マルチタスク に関連する要因はなんですか？ 内部要因として、以下の4点が挙げられました。 人数の多い会議 長時間会議 朝の会議 定例や事前に予定されている会議（エンゲージメントが低い会議） この4つの特徴を持つリモート会議は他のリモート会議より マルチタスク の頻度が高いです。 外部要因として、ダイアリー・ スタディ では以下の3点が挙げられました。 他の仕事に追いつくため 会議が多すぎて、仕事が終わらない 他のことに気を散らしたため Teamsの通知で気を散らしたなど 不安を和らげるため 新型コロナウイルス が流行り始めたごろの不安 不安を和らげるために スマホ ゲームをした人がいた リモート会議でどんな マルチタスク が行われましたか？ 社員に対するダイアリー・ スタディ によると、仕事に関連する マルチタスク が多かったです。参加者の29%は「メールの マルチタスク 」と回答しました。「実行時間が長い スクリプト の確認」や「テスト実行」の回答もありました。一方、リモート会議でのファイルの編集については、会議に関連する場合がほとんどです。 仕事以外の マルチタスク に関しては、 SNS や、食事、家事、エクササイズと回答した人もいました。 リモート会議での マルチタスク はどんな影響をもたらしますか？ ポジティブな影響に関しては、ダイアリー・ スタディ の参加者の15%は「生産性の向上につながった」と回答しました。社員は集中力が必要でない重要度の低い会議では マルチタスク する傾向があります。 重要度の低い会議で、別の仕事をすることで生産性が向上したでしょう。 一方、ネガティブな影響もありました。36%の参加者は「集中力やエンゲージメントの低下」と回答しました。他にも「精神的 疲労 につながる」、「発言者に失礼」のような回答がありました。 研究からの提案 作者は研究の結果からリモート会議に対して以下の5つの ガイドライン を提案しました。 重要な会議は朝を避ける 必要ではない会議を減らす 会議を短くして、休憩時間を入れる 参加者の一部を積極的に会議に貢献させる ポジティブな マルチタスク の存在を許与する また、リモート会議システムのデザインに対しても以下の提案をしました。 会議中に、無関連のポップアップをブロックする“集中モード”を選択できるようにする 会議と同じ画面で議事録やファイルの編集ができるようにする 会議に対して重要度のランク付けができるようにし、カレンダーに表示させる 会議の アジェンダ から注意が必要な部分を表記しあらかじめ参加者に表示する 読んでみた感想 「大人数の会議や長時間会議、聞くだけの会議では内職しやすい」、「内職で生産性を上げた人もいれば気をそらしたからネガティブな効果を感じた人もいる」など確かにと思うような結論が多かったですね。 しかし、経験者が当たり前のように思うことを大量なデータを使って検証できたことはこの論文の貢献だと思います。 また「 マルチタスク は社員の幸福度や生産性につながる」など、内職という課題の重要性を示し、ポジティブな効果をもたらす内職を許容すると提唱するのもこの論文の素晴らしいところですね。無駄な会議を減らし、会議の質を上げるのはテレワーク時代の課題だと考えられます。 この研究は 新型コロナウイルス が大流行になった直後（つまり、出社からテレワークの働き方に切り替えた直後）、また Microsoft 社だけのデータを利用したところが限界として挙げられます。テレワークが定着した現在、またはIT業界以外の会社のデータを使ったら、結果はどう変わるかが気になります。 まとめ 本記事では、論文輪読会で私が担当した論文を紹介しました。 論文輪読会で、普段やっている仕事と全く違う分野の技術をみんなで議論することができました。 また、興味がある学会やカンファレンスの論文を調べることで、最新の研究動向や研究手法についても多く学びました。 皆さんもぜひ学術論文を読んでみてください。 私たちは同じグループで共に働いていただける仲間を募集しています。 現在募集している職種は以下です。 ソリューションアーキテクト 論文輪読会をはじめとした各種勉強会に気軽に参加できるような環境で働くことに興味のある皆様、ぜひご応募お待ちしています！ 執筆： @chen.xinying 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 これまで、人物用の呪文が多かったのですが、それ以外のテーマでも面白いものがたくさんあります。 Stable Diffusionの呪文シリーズ、今回のテーマは東京タワーの写真です。 建物の場合、より建物が具体的な方が、良いものに仕上がる可能性が高いです。 バベルの塔のイラスト編 と同様に、具体的に東京タワーを選んでみました。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 TPU版の使い方 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 illuminated tokyo tower shot from below SIGMA 85 mm F1.4 illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 まとめ 仲間募集 Stable Diffusionの全コンテンツ illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 通常呪文は、画像タイプ of 描画対象で始めるのが定番です。例えばphoto of dogの用な感じです。今回は、 SIGMA というレンズを表す呪文を指定しているので、photo ofはなくても写真になります。 illuminatedで描画対象に照明を当てます。illuminatedなしも何度も試してみましたが、東京タワーはilluminatedありのほうが断然良いです。 highly detailedで描画対象を詳細に描画します。 shot from aboveで上から描画します。 バベルの塔編 で、説明したように、人は見たことのないアングルの写真に惹かれます。東京タワーをさらに上の方からとった写真って普通見たことないじゃないですか。だから、東京タワーに対する shot from above は効果的なのです。 もう一つ、 バベルの塔 編と違うのは、東京タワーを上から撮ると、周りのビルの美しい灯りが見えることです。これもかなり効果的です。 SIGMA 85 mm F1.4は、使いやすい望遠レンズです。詳しく知りたい方は、 レンズ編 を御覧ください。 今回の呪文（横長、コピー&ペースト用） illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 閲覧用呪文（改行版） illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 画像出力結果 東京タワーを上から描画すると、夜のビル群が見えてきれいですね。 illuminated tokyo tower shot from below SIGMA 85 mm F1.4 今回は、shot from belowで下から描画します。highly detailedがないことに注目してください。塔を下から描画するときに、highly detailedをつけると、塔に近寄りすぎてしまい、うまく描画するのが難しくなります。 今回の呪文（横長、コピー&ペースト用） illuminated tokyo tower shot from below SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 閲覧用呪文（改行版） illuminated tokyo tower shot from below SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 画像出力結果 空が寂しいですね。 highly detailed版 東京タワーに近寄り過ぎに感じますが、大迫力の構図です。 illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 空が寂しいので、星を出しましょう。 cosmos（宇宙）、stars（星）、nebula（星雲）を追加します。 今回の呪文（横長、コピー&ペースト用） illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 閲覧用呪文（改行版） illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 画像出力結果 美しい星空ですね。 まとめ 今回は、東京タワーの写真を取り上げました。 shot from above 、 shot from below ぜひ、覚えてください。 次回は、 折り紙合体変形ロボ です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 これまで、人物用の呪文が多かったのですが、それ以外のテーマでも面白いものがたくさんあります。 Stable Diffusionの呪文シリーズ、今回のテーマは東京タワーの写真です。 建物の場合、より建物が具体的な方が、良いものに仕上がる可能性が高いです。 バベルの塔のイラスト編 と同様に、具体的に東京タワーを選んでみました。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 TPU版の使い方 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 illuminated tokyo tower shot from below SIGMA 85 mm F1.4 illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 まとめ 仲間募集 Stable Diffusionの全コンテンツ illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 通常呪文は、画像タイプ of 描画対象で始めるのが定番です。例えばphoto of dogの用な感じです。今回は、 SIGMA というレンズを表す呪文を指定しているので、photo ofはなくても写真になります。 illuminatedで描画対象に照明を当てます。illuminatedなしも何度も試してみましたが、東京タワーはilluminatedありのほうが断然良いです。 highly detailedで描画対象を詳細に描画します。 shot from aboveで上から描画します。 バベルの塔編 で、説明したように、人は見たことのないアングルの写真に惹かれます。東京タワーをさらに上の方からとった写真って普通見たことないじゃないですか。だから、東京タワーに対する shot from above は効果的なのです。 もう一つ、 バベルの塔 編と違うのは、東京タワーを上から撮ると、周りのビルの美しい灯りが見えることです。これもかなり効果的です。 SIGMA 85 mm F1.4は、使いやすい望遠レンズです。詳しく知りたい方は、 レンズ編 を御覧ください。 今回の呪文（横長、コピー&ペースト用） illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 閲覧用呪文（改行版） illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 画像出力結果 東京タワーを上から描画すると、夜のビル群が見えてきれいですね。 illuminated tokyo tower shot from below SIGMA 85 mm F1.4 今回は、shot from belowで下から描画します。highly detailedがないことに注目してください。塔を下から描画するときに、highly detailedをつけると、塔に近寄りすぎてしまい、うまく描画するのが難しくなります。 今回の呪文（横長、コピー&ペースト用） illuminated tokyo tower shot from below SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 閲覧用呪文（改行版） illuminated tokyo tower shot from below SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 画像出力結果 空が寂しいですね。 highly detailed版 東京タワーに近寄り過ぎに感じますが、大迫力の構図です。 illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 空が寂しいので、星を出しましょう。 cosmos（宇宙）、stars（星）、nebula（星雲）を追加します。 今回の呪文（横長、コピー&ペースト用） illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 閲覧用呪文（改行版） illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 画像出力結果 美しい星空ですね。 まとめ 今回は、東京タワーの写真を取り上げました。 shot from above 、 shot from below ぜひ、覚えてください。 次回は、 折り紙合体変形ロボ です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

こんにちは。X イノベーション 本部ソフトウェアデザインセンターの陳です。 この記事では Next.js + TypeScript + Docker + GitHub Actionsの環境構築の方法をまとめます。 セットアップ手順 以下のセットアップを行います。 1. create-next-appでNext.jsのプロジェクトを作成 2. 静的分析ツールESLintの設定 3. コードフォーマッターPrettierの設定 4. テスト フレームワーク のJest、React Testing Libraryの設定 5. Dockerfileの作成 6. GitHub Actionsを利用したビルド、テストの自動実行 バージョン Next.js v12.3.0 TypeScript v4.8.3 create-next-appでNext.jsのプロジェクトを作成 create-next-app はNext.jsプロジェクトを自動生成するためのコマンドです。 create-next-app を利用すると、Next.js + TypeScriptのプロジェクトのひな形を簡単に作成できます。公式ドキュメントは こちら です。 create-next-appを実行する 以下のコマンドを実行し、プロジェクトを自動生成します。 $ npx create-next-app ｛プロジェクト名｝　--ts yarnを利用することもできます。 $ yarn create next-app ｛プロジェクト名｝ --typescript --ts また --typescript を指定することで、TypeScriptを利用するプロジェクトが生成されます。TypeScriptの設定ファイル tsconfig.json も自動的に作成されます。 プロジェクトを動かしてみる 作成されたプロジェクトの ディレクト リで以下のコマンドを実行すると、Next.jsプロジェクトを開発モードで起動できます。 $ yarn dev localhost:3000 にアクセスするとこちらの画面が表示されます。これでプロジェクトのひな形の作成が完了しました。 静的分析ツールESLintの設定 ESLintを実行する Next.js v11.0.0から create-next-app でプロジェクトを作成すると、ESLintは自動的にインストールされます。 package.json の Scripts に "lint": "next lint" がデフォルトで設定されています。以下のコマンドでESLintを実行できます。 $ yarn lint ESLintのデフォルト構成 Next.jsのESLintのデフォルト構成では、 eslint-config-next の構成が自動的に設定されます。以下のルールセットが eslint-config-next に含まれるため、インストール、設定する必要はありません。公式ドキュメントは こちら です。 eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-next ESLintの構成をカスタマイズする .eslintrc.json を編集することで、構成をカスタマイズできます。 .eslintrc.json はESLintに関する設定ファイルです。 以下のように extends に記述すれば、 eslint:recommended など、他の構成を利用できます。また rules でルールの変更や無効化の設定もできます。 //.eslintrc.json { "extends": [ "eslint:recommended", "next/core-web-vitals", ], "rules":{ // 個別のルールを変更、無効にする場合はこちらに追加する "no-console": ["warn", { allow: ["warn", "error"] }], "sort-imports": "off", "import/order": ["error", { alphabetize: { order: "asc" } }], "import/no-named-as-default-member": "off", } コードフォーマッターPrettierの設定 Prettierをインストールする 以下のコマンドでPrettier本体、ESLintと併用する際に必要なライブラリーをインストールします。 $ yarn add -D prettier eslint-config-prettier .eslintrc. json を編集する .eslintrc.json を以下のように設定することで、ESLint と Prettier のコード整形が競合しないようになります。 //.eslintrc.json { "extends": ["next/core-web-vitals", "prettier"], } .prettierrcを作成する コード整形に関する設定をカスタマイズするには、ルート ディレクト リで .prettierrc を作成します。 以下のようにカスタマイズ設定ができます。設定の詳細は 公式ドキュメント を参照してください。 //.prettierrc { "tabWidth": 2, "printWidth": 120, "trailingComma": "es5", "semi": false, "singleQuote": true } Prettierを実行する Prettierを実行するには、 package.json の Scripts に以下の スクリプト を追加します。 //package.json "scripts": { "format": "prettier --write --ignore-path .gitignore ." } 以下のコマンドでPrettierを実行できます。 $ yarn format テスト フレームワーク のJest、React Testing Libraryの設定 Jest、React Testing Libraryをインストールする Next.jsの 公式ドキュメント を参照し、JestおよびReact Testing Libraryをインストール、設定します。 $ yarn add -D jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom jest.config.jsを作成する ルート ディレクト リでjestの設定ファイル jest.config.js を作成します。 //jest.config.js const nextJest = require('next/jest') const createJestConfig = nextJest({ dir: './', }) const customJestConfig = { moduleDirectories: ['node_modules', '<rootDir>/'], testEnvironment: 'jest-environment-jsdom', } module.exports = createJestConfig(customJestConfig) テストを実行してみる テストを実行するには、 package.json の scripts に以下の スクリプト を追加します。 //package.json "scripts": { "test": "jest" } サンプルテストを追加します。ルート ディレクト リに test フォルダを作成し、 test の配下に index.test.tsx ファイルを作成します。 //index.test.tsx import { render, screen } from '@testing-library/react' import '@testing-library/jest-dom/extend-expect' import Home from '../pages' describe('Home', () => { it('renders a heading', () => { render(<Home />) const heading = screen.getByRole('heading', { name: /welcome to next\.js/i, }) expect(heading).toBeInTheDocument() }) }) 以下のコマンドでテストをします。 $ yarn test テストが通ったことを確認できます。 Dockerfileの作成 Next.jsをDockerコンテナでデプロイするためのDockerfileのひな形を作成します。 Next.jsのstandaloneモードを有効にする まず、 next.config.js の設定を修正し、standaloneモードを有効にします。 //next.config.js const nextConfig = { output: 'standalone', } Next.js 12の最新バージョンではstandaloneモードを有効にすることで、ビルドサイズを大幅に削減できます。 yarn build により、 .next/standalone フォルダーが作成され、 node_modules の依存関係を含めたデプロイで必要となる最小限なファイルのみがコピーされます。 standalone に作成された sever.js を実行すれば本番アプリケーションを実行できます。 Dockerfileを作成する Next.jsの 公式サンプル を参考しつつ、Distrolessで実行するマルチビルドのDockerfileを作成します。 FROM node:16 AS build ADD . /app WORKDIR /app RUN yarn install --production=false RUN yarn build FROM gcr.io/distroless/nodejs:16 WORKDIR /app COPY --from=build /app/next.config.js ./ COPY --from=build /app/public ./public COPY --from=build /app/package.json ./package.json COPY --from=build /app/.next/static ./.next/static COPY --from=build /app/.next/standalone ./ CMD ["server.js"] ローカルでDockerコンテナを実行してみる 以下のコマンドでコンテナをビルド、実行できます。 $ docker build -t ｛イメージ名｝ . $ docker run -p 3000:3000 ｛イメージ名｝ GitHub Actionsを利用したビルド、テストの自動実行 pushをトリガーにしてビルドおよびテストを自動実行する GitHub Actionsを作成します。 ルート ディレクト リで .github/workflows フォルダーを作成し、配下に build-and-test-on-push.yml を作成します。 on: push: branches-ignore: - "main" name: Build and Test on Push jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: docker build run: docker build . run-tests: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Set up Node.js uses: actions/setup-node@v3 with: node-version: 16 - name: Install Dependencies run: yarn install - name: Run test run: yarn run test Dockerを利用しない場合は、 yarn build でビルドを実行できます。 まとめ 今回はNext.jsの環境構築の方法をまとめてみました。 環境構築のほとんどは 公式ドキュメント を参考にスムーズにできました。 create-next-app を利用すると手動で設定する部分が少なくなるので、便利かと思います。 また、CI環境の構築でDockerfileや GitHub Actionsの作成手順もまとめてみました。興味のある方はぜひ試してみてください。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 - ソリューションアーキテクト 執筆： @chen.xinying 、レビュー： @handa.kenta （ Shodo で執筆されました ）

こんにちは。X イノベーション 本部ソフトウェアデザインセンターの陳です。 この記事では Next.js + TypeScript + Docker + GitHub Actionsの環境構築の方法をまとめます。 セットアップ手順 以下のセットアップを行います。 1. create-next-appでNext.jsのプロジェクトを作成 2. 静的分析ツールESLintの設定 3. コードフォーマッターPrettierの設定 4. テスト フレームワーク のJest、React Testing Libraryの設定 5. Dockerfileの作成 6. GitHub Actionsを利用したビルド、テストの自動実行 バージョン Next.js v12.3.0 TypeScript v4.8.3 create-next-appでNext.jsのプロジェクトを作成 create-next-app はNext.jsプロジェクトを自動生成するためのコマンドです。 create-next-app を利用すると、Next.js + TypeScriptのプロジェクトのひな形を簡単に作成できます。公式ドキュメントは こちら です。 create-next-appを実行する 以下のコマンドを実行し、プロジェクトを自動生成します。 $ npx create-next-app ｛プロジェクト名｝　--ts yarnを利用することもできます。 $ yarn create next-app ｛プロジェクト名｝ --typescript --ts また --typescript を指定することで、TypeScriptを利用するプロジェクトが生成されます。TypeScriptの設定ファイル tsconfig.json も自動的に作成されます。 プロジェクトを動かしてみる 作成されたプロジェクトの ディレクト リで以下のコマンドを実行すると、Next.jsプロジェクトを開発モードで起動できます。 $ yarn dev localhost:3000 にアクセスするとこちらの画面が表示されます。これでプロジェクトのひな形の作成が完了しました。 静的分析ツールESLintの設定 ESLintを実行する Next.js v11.0.0から create-next-app でプロジェクトを作成すると、ESLintは自動的にインストールされます。 package.json の Scripts に "lint": "next lint" がデフォルトで設定されています。以下のコマンドでESLintを実行できます。 $ yarn lint ESLintのデフォルト構成 Next.jsのESLintのデフォルト構成では、 eslint-config-next の構成が自動的に設定されます。以下のルールセットが eslint-config-next に含まれるため、インストール、設定する必要はありません。公式ドキュメントは こちら です。 eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-next ESLintの構成をカスタマイズする .eslintrc.json を編集することで、構成をカスタマイズできます。 .eslintrc.json はESLintに関する設定ファイルです。 以下のように extends に記述すれば、 eslint:recommended など、他の構成を利用できます。また rules でルールの変更や無効化の設定もできます。 //.eslintrc.json { "extends": [ "eslint:recommended", "next/core-web-vitals", ], "rules":{ // 個別のルールを変更、無効にする場合はこちらに追加する "no-console": ["warn", { allow: ["warn", "error"] }], "sort-imports": "off", "import/order": ["error", { alphabetize: { order: "asc" } }], "import/no-named-as-default-member": "off", } コードフォーマッターPrettierの設定 Prettierをインストールする 以下のコマンドでPrettier本体、ESLintと併用する際に必要なライブラリーをインストールします。 $ yarn add -D prettier eslint-config-prettier .eslintrc. json を編集する .eslintrc.json を以下のように設定することで、ESLint と Prettier のコード整形が競合しないようになります。 //.eslintrc.json { "extends": ["next/core-web-vitals", "prettier"], } .prettierrcを作成する コード整形に関する設定をカスタマイズするには、ルート ディレクト リで .prettierrc を作成します。 以下のようにカスタマイズ設定ができます。設定の詳細は 公式ドキュメント を参照してください。 //.prettierrc { "tabWidth": 2, "printWidth": 120, "trailingComma": "es5", "semi": false, "singleQuote": true } Prettierを実行する Prettierを実行するには、 package.json の Scripts に以下の スクリプト を追加します。 //package.json "scripts": { "format": "prettier --write --ignore-path .gitignore ." } 以下のコマンドでPrettierを実行できます。 $ yarn format テスト フレームワーク のJest、React Testing Libraryの設定 Jest、React Testing Libraryをインストールする Next.jsの 公式ドキュメント を参照し、JestおよびReact Testing Libraryをインストール、設定します。 $ yarn add -D jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom jest.config.jsを作成する ルート ディレクト リでjestの設定ファイル jest.config.js を作成します。 //jest.config.js const nextJest = require('next/jest') const createJestConfig = nextJest({ dir: './', }) const customJestConfig = { moduleDirectories: ['node_modules', '<rootDir>/'], testEnvironment: 'jest-environment-jsdom', } module.exports = createJestConfig(customJestConfig) テストを実行してみる テストを実行するには、 package.json の scripts に以下の スクリプト を追加します。 //package.json "scripts": { "test": "jest" } サンプルテストを追加します。ルート ディレクト リに test フォルダを作成し、 test の配下に index.test.tsx ファイルを作成します。 //index.test.tsx import { render, screen } from '@testing-library/react' import '@testing-library/jest-dom/extend-expect' import Home from '../pages' describe('Home', () => { it('renders a heading', () => { render(<Home />) const heading = screen.getByRole('heading', { name: /welcome to next\.js/i, }) expect(heading).toBeInTheDocument() }) }) 以下のコマンドでテストをします。 $ yarn test テストが通ったことを確認できます。 Dockerfileの作成 Next.jsをDockerコンテナでデプロイするためのDockerfileのひな形を作成します。 Next.jsのstandaloneモードを有効にする まず、 next.config.js の設定を修正し、standaloneモードを有効にします。 //next.config.js const nextConfig = { output: 'standalone', } Next.js 12の最新バージョンではstandaloneモードを有効にすることで、ビルドサイズを大幅に削減できます。 yarn build により、 .next/standalone フォルダーが作成され、 node_modules の依存関係を含めたデプロイで必要となる最小限なファイルのみがコピーされます。 standalone に作成された sever.js を実行すれば本番アプリケーションを実行できます。 Dockerfileを作成する Next.jsの 公式サンプル を参考しつつ、Distrolessで実行するマルチビルドのDockerfileを作成します。 FROM node:16 AS build ADD . /app WORKDIR /app RUN yarn install --production=false RUN yarn build FROM gcr.io/distroless/nodejs:16 WORKDIR /app COPY --from=build /app/next.config.js ./ COPY --from=build /app/public ./public COPY --from=build /app/package.json ./package.json COPY --from=build /app/.next/static ./.next/static COPY --from=build /app/.next/standalone ./ CMD ["server.js"] ローカルでDockerコンテナを実行してみる 以下のコマンドでコンテナをビルド、実行できます。 $ docker build -t ｛イメージ名｝ . $ docker run -p 3000:3000 ｛イメージ名｝ GitHub Actionsを利用したビルド、テストの自動実行 pushをトリガーにしてビルドおよびテストを自動実行する GitHub Actionsを作成します。 ルート ディレクト リで .github/workflows フォルダーを作成し、配下に build-and-test-on-push.yml を作成します。 on: push: branches-ignore: - "main" name: Build and Test on Push jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: docker build run: docker build . run-tests: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Set up Node.js uses: actions/setup-node@v3 with: node-version: 16 - name: Install Dependencies run: yarn install - name: Run test run: yarn run test Dockerを利用しない場合は、 yarn build でビルドを実行できます。 まとめ 今回はNext.jsの環境構築の方法をまとめてみました。 環境構築のほとんどは 公式ドキュメント を参考にスムーズにできました。 create-next-app を利用すると手動で設定する部分が少なくなるので、便利かと思います。 また、CI環境の構築でDockerfileや GitHub Actionsの作成手順もまとめてみました。興味のある方はぜひ試してみてください。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 - ソリューションアーキテクト 執筆： @chen.xinying 、レビュー： @handa.kenta （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、Ansible Vaultを利用して、Ansibleを使う場合に機密情報を安全に扱う方法について紹介します。 ansibleと機密情報の管理についての課題 Ansibleを使ってデプロイなどを自動化していると、 Amazon Web Services ( AWS ) の機密情報やパスワード、 SSH に利用する 秘密鍵 といった機密情報を扱う場面があります。また、Ansibleを利用している場合はplaybookを GitHub などで管理することが多いと思います。こういった GitHub などの リポジトリ に機密情報を直接置いてしまうと情報漏洩といった事故につながる場合があります。 機密情報を別システム ( dashlaneや AWS のsecret managerなど ) で管理するといった方法もあるかと思います。しかしこの方法では機密情報だけをバージョン管理の仕組みから別で管理することとなってしまい、管理コストが高くなってしまいます。また、CI/CDといった自動化を行う場合にもansible以外のツール、機密情報へのアクセス方法を考えなければならなくなってしまいます。 理想的には以下のような状態になっていてほしいです。 機密情報は安全に扱いたい 新規のツールの導入は避けたい playbookと機密情報の両方を1つの リポジトリ 上で安全にバージョン管理できる 今回はこの問題を解決するAnsible Vaultというツールについて紹介します。 Ansible Vaultとは このような機密情報を扱うために、AnsibleにはAnsible Vaultと呼ばれる暗号化の機能が付属しています。暗号化した情報であれば リポジトリ 上に置くリスクを大幅に減らすことができます。本記事ではこのAnsible Vaultを使って、 ssh の 秘密鍵 、 AWS の認証情報といった機密情報を暗号化してCI/CDから利用する方法について記載します。 なお、Ansible Vaultの公式のドキュメントは以下となります。より詳細な説明は以下のドキュメントを参照してください。 https://docs.ansible.com/ansible/latest/user_guide/vault.html この記事で紹介している利用方法は、 10人に満たない小規模なチーム 機密情報はメンバ内で共有して問題がない 上記のような想定となっています。 このため、Ansible Vaultで暗号化に利用するパスワードは vaultd-id を利用して分割したりせず単一で共通のものを想定しています。 Ansible Vaultを使った暗号化、復号化 Ansible Vaultは、 ansible-vault コマンドを通じて利用します。サブコマンドとして create 、 encrypt 、 decrypt 、 rekey 、 edit 、 view というサブコマンドがあります。ここでは、既存のファイルの暗号化、復号を行う encrypt 、 decrypt の動作について述べます。 まずは、 encrypt を使ってファイルを暗号化してみましょう。以下のような中身のファイルを、 test.txt という名前で作成します。 hello,world! そのファイルを、 ansible-vault encrypt で暗号化します。 途中でパスワードを聞かれるので、適宜入力して忘れない様にしてください。 $ansible-vault encrypt test.txt New Vault password: Confirm New Vault password: Encryption successful 暗号化に成功したようです。暗号化された中身を確認してみます。 $ cat test.txt $ANSIBLE_VAULT;1.1;AES256 34646636663564393432303436353932613263346534373439353133303137333064343363326266 6565386564393437316139353031333063316663363466300a376534313035373630356663376661 35663263663265383861346162306630353636316534626165313638616433373566373632306339 6438646236316431380a643737343561376133313334616162303737616561386262633338313761 6436 ちゃんと暗号化できたようです。 今度は復号できるか確認してみましょう。復号に使うコマンドは ansible-vault decrypt です。 途中で先ほど入力したパスワードを求められます。打ち間違いに注意してパスワードを入力しましょう。 ansible-vault decrypt test.txt Vault password: Decryption successful 無事復号できたようです。 それでは、中身も正しいかを確認してみましょう。 $ cat test.txt hello,world! ちゃんとファイルの中身も復号できていることが分かりました。 この ansible-vault の機能を使って機密情報を扱うplaybookを作ってみましょう。 SSH 接続情報の保護 ansibleでは SSH の接続に 秘密鍵 を利用することが多いですが、この 秘密鍵 を リポジトリ に暗号化せずに登録してしまうと、その情報を入手した人は誰でも接続できてしまいます。まずはこの情報の暗号化を実施してみましょう。 まず、以下のように接続に利用する 秘密鍵 ( private_key )を暗号化しておきます。 ansible-vault private_key 次に、実行するplaybookの先頭にこの暗号化された 秘密鍵 を復号するタスクを追加します。 内容としては copy モジュールを実行するだけのものになっています。ansibleの copy モジュールは、 ansible-vault で暗号化されたファイルを扱う際に復号してくれる機能があります。その機能を利用して、 秘密鍵 を復号しています。 - hosts: localhost gather_facts: false vars: src_key: ./private_key dest_key: ./decrypted_private_key tasks: - copy: src: "{{ src_key }}" dest: "{{ dest_key }}" mode: 0600 そして ansible-playbook で利用する inventory.yml を以下のように記述します。 XXXで示している部分は各自の環境に合わせて書き換えてください。 ここで、 ansible_ssh_private_key_file には上記の手順で復号された 秘密鍵 が指定されるように設定します。 all: children: XXXX: hosts: XXXX: ansible_ssh_private_key_file: ./decrypted_private_key ansible_ssh_user: XXXX ansible_host: XXX.XXX.XXX.XXX ungrouped: {} これで、 秘密鍵 を暗号化して管理することが可能になりました。 機密情報を利用するPlaybookの実行方法 ansible-playbook を実行する際にvaultで利用したパスワードが必要になりました。 以下のように引数でパスワードファイルを渡すか、毎回入力する方法があります。 自動化などを考えるとパスワードファイルを作成する方法が手軽です。 # 端末で毎回パスワードを入力する方法 ansible-playbook site.yml -ask-vault-pass # パスワードファイルを引数で与える方法 ansible-playbook site.yml –vault-password-file ~/.vault_pass.txt 例えば、 環境変数 $VAULT_PASS にパスワードが格納されているような場合では、以下のような スクリプト を実行する方法があります。 echo "$VAULT_PASS" > .vault_pass.txt ansible-playbook -i inventory.yml site.yml –vault-password-file ~/.vault_pass.txt rm .vault_pass.txt Playbook上で利用する機密情報の保護 ここまでで SSH に利用する 秘密鍵 の暗号化は実現できました。次にplaybookの中で利用したい機密情報についても暗号化していきましょう。 先ほどの 秘密鍵 の例では、 copy モジュールは自動的に ansible-vault の復号を実施してくれると説明しました。この機能がansibleの変数のファイルに対しても自動的に復号を行ってくれます。 従ってAnsibleが利用する group_vars/all.yml といった変数ファイルを ansible-vault コマンドで事前に暗号化しておくことで、機密情報を暗号化したままで利用することが出来ます。以下のように事前に変数のファイルを暗号化しておくだけで安全に管理することが可能となります。 group_vars/all.yml には以下のように、sudoのパスワードや AWS の接続情報が含まれています。 --- ansible_sudo_pass: "XXXXXXXXXX" aws_access_key_id: "XXXXXXXXXXXXXXXXXXX" aws_secret_access_key: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" これを、 ansible-vault で暗号化します。 ansible-vault encrypt group_vars/all.yml この状態で、 ansible-playbook の実行時に group_vars/all の変数を利用する際に自動的に復号処理が行われます。 実行方法は前項で述べた方法と変わらず実行できます。 GitHub Actions で実行する方法 それでは、最後に GitHub Actionsで実行する場合の方法について紹介します。 vaultのパスワードを GitHub のsecretとして与えるような設定を行って実行します。 jobs: deploy: steps: - name: Exec ansible-playbook env: VAULT_PASS: ${{secrets.VAULT_PASS}} run: | echo $VAULT_PASS > ./vault_pass.txt ansible-playbook -i inventory.yml site.yml --vault-password-file ./vault_pass.txt" 簡単ですね！ まとめ この記事では、Ansible Vaultを使った機密情報の扱い方の簡単な紹介を行いました。またそれらを組みわせて GitHub Actionsから実行する方法も紹介しました。これで、安全に リポジトリ 上の機密情報を置きながら、CI/CDも手軽に実行できる環境が構築できます。 仮想マシン などにサービスをAnsibleを使ってデプロイする場面では是非有効活用していきたいですね。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @sato.taichi （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、Ansible Vaultを利用して、Ansibleを使う場合に機密情報を安全に扱う方法について紹介します。 ansibleと機密情報の管理についての課題 Ansibleを使ってデプロイなどを自動化していると、 Amazon Web Services ( AWS ) の機密情報やパスワード、 SSH に利用する 秘密鍵 といった機密情報を扱う場面があります。また、Ansibleを利用している場合はplaybookを GitHub などで管理することが多いと思います。こういった GitHub などの リポジトリ に機密情報を直接置いてしまうと情報漏洩といった事故につながる場合があります。 機密情報を別システム ( dashlaneや AWS のsecret managerなど ) で管理するといった方法もあるかと思います。しかしこの方法では機密情報だけをバージョン管理の仕組みから別で管理することとなってしまい、管理コストが高くなってしまいます。また、CI/CDといった自動化を行う場合にもansible以外のツール、機密情報へのアクセス方法を考えなければならなくなってしまいます。 理想的には以下のような状態になっていてほしいです。 機密情報は安全に扱いたい 新規のツールの導入は避けたい playbookと機密情報の両方を1つの リポジトリ 上で安全にバージョン管理できる 今回はこの問題を解決するAnsible Vaultというツールについて紹介します。 Ansible Vaultとは このような機密情報を扱うために、AnsibleにはAnsible Vaultと呼ばれる暗号化の機能が付属しています。暗号化した情報であれば リポジトリ 上に置くリスクを大幅に減らすことができます。本記事ではこのAnsible Vaultを使って、 ssh の 秘密鍵 、 AWS の認証情報といった機密情報を暗号化してCI/CDから利用する方法について記載します。 なお、Ansible Vaultの公式のドキュメントは以下となります。より詳細な説明は以下のドキュメントを参照してください。 https://docs.ansible.com/ansible/latest/user_guide/vault.html この記事で紹介している利用方法は、 10人に満たない小規模なチーム 機密情報はメンバ内で共有して問題がない 上記のような想定となっています。 このため、Ansible Vaultで暗号化に利用するパスワードは vaultd-id を利用して分割したりせず単一で共通のものを想定しています。 Ansible Vaultを使った暗号化、復号化 Ansible Vaultは、 ansible-vault コマンドを通じて利用します。サブコマンドとして create 、 encrypt 、 decrypt 、 rekey 、 edit 、 view というサブコマンドがあります。ここでは、既存のファイルの暗号化、復号を行う encrypt 、 decrypt の動作について述べます。 まずは、 encrypt を使ってファイルを暗号化してみましょう。以下のような中身のファイルを、 test.txt という名前で作成します。 hello,world! そのファイルを、 ansible-vault encrypt で暗号化します。 途中でパスワードを聞かれるので、適宜入力して忘れない様にしてください。 $ansible-vault encrypt test.txt New Vault password: Confirm New Vault password: Encryption successful 暗号化に成功したようです。暗号化された中身を確認してみます。 $ cat test.txt $ANSIBLE_VAULT;1.1;AES256 34646636663564393432303436353932613263346534373439353133303137333064343363326266 6565386564393437316139353031333063316663363466300a376534313035373630356663376661 35663263663265383861346162306630353636316534626165313638616433373566373632306339 6438646236316431380a643737343561376133313334616162303737616561386262633338313761 6436 ちゃんと暗号化できたようです。 今度は復号できるか確認してみましょう。復号に使うコマンドは ansible-vault decrypt です。 途中で先ほど入力したパスワードを求められます。打ち間違いに注意してパスワードを入力しましょう。 ansible-vault decrypt test.txt Vault password: Decryption successful 無事復号できたようです。 それでは、中身も正しいかを確認してみましょう。 $ cat test.txt hello,world! ちゃんとファイルの中身も復号できていることが分かりました。 この ansible-vault の機能を使って機密情報を扱うplaybookを作ってみましょう。 SSH 接続情報の保護 ansibleでは SSH の接続に 秘密鍵 を利用することが多いですが、この 秘密鍵 を リポジトリ に暗号化せずに登録してしまうと、その情報を入手した人は誰でも接続できてしまいます。まずはこの情報の暗号化を実施してみましょう。 まず、以下のように接続に利用する 秘密鍵 ( private_key )を暗号化しておきます。 ansible-vault private_key 次に、実行するplaybookの先頭にこの暗号化された 秘密鍵 を復号するタスクを追加します。 内容としては copy モジュールを実行するだけのものになっています。ansibleの copy モジュールは、 ansible-vault で暗号化されたファイルを扱う際に復号してくれる機能があります。その機能を利用して、 秘密鍵 を復号しています。 - hosts: localhost gather_facts: false vars: src_key: ./private_key dest_key: ./decrypted_private_key tasks: - copy: src: "{{ src_key }}" dest: "{{ dest_key }}" mode: 0600 そして ansible-playbook で利用する inventory.yml を以下のように記述します。 XXXで示している部分は各自の環境に合わせて書き換えてください。 ここで、 ansible_ssh_private_key_file には上記の手順で復号された 秘密鍵 が指定されるように設定します。 all: children: XXXX: hosts: XXXX: ansible_ssh_private_key_file: ./decrypted_private_key ansible_ssh_user: XXXX ansible_host: XXX.XXX.XXX.XXX ungrouped: {} これで、 秘密鍵 を暗号化して管理することが可能になりました。 機密情報を利用するPlaybookの実行方法 ansible-playbook を実行する際にvaultで利用したパスワードが必要になりました。 以下のように引数でパスワードファイルを渡すか、毎回入力する方法があります。 自動化などを考えるとパスワードファイルを作成する方法が手軽です。 # 端末で毎回パスワードを入力する方法 ansible-playbook site.yml -ask-vault-pass # パスワードファイルを引数で与える方法 ansible-playbook site.yml –vault-password-file ~/.vault_pass.txt 例えば、 環境変数 $VAULT_PASS にパスワードが格納されているような場合では、以下のような スクリプト を実行する方法があります。 echo "$VAULT_PASS" > .vault_pass.txt ansible-playbook -i inventory.yml site.yml –vault-password-file ~/.vault_pass.txt rm .vault_pass.txt Playbook上で利用する機密情報の保護 ここまでで SSH に利用する 秘密鍵 の暗号化は実現できました。次にplaybookの中で利用したい機密情報についても暗号化していきましょう。 先ほどの 秘密鍵 の例では、 copy モジュールは自動的に ansible-vault の復号を実施してくれると説明しました。この機能がansibleの変数のファイルに対しても自動的に復号を行ってくれます。 従ってAnsibleが利用する group_vars/all.yml といった変数ファイルを ansible-vault コマンドで事前に暗号化しておくことで、機密情報を暗号化したままで利用することが出来ます。以下のように事前に変数のファイルを暗号化しておくだけで安全に管理することが可能となります。 group_vars/all.yml には以下のように、sudoのパスワードや AWS の接続情報が含まれています。 --- ansible_sudo_pass: "XXXXXXXXXX" aws_access_key_id: "XXXXXXXXXXXXXXXXXXX" aws_secret_access_key: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" これを、 ansible-vault で暗号化します。 ansible-vault encrypt group_vars/all.yml この状態で、 ansible-playbook の実行時に group_vars/all の変数を利用する際に自動的に復号処理が行われます。 実行方法は前項で述べた方法と変わらず実行できます。 GitHub Actions で実行する方法 それでは、最後に GitHub Actionsで実行する場合の方法について紹介します。 vaultのパスワードを GitHub のsecretとして与えるような設定を行って実行します。 jobs: deploy: steps: - name: Exec ansible-playbook env: VAULT_PASS: ${{secrets.VAULT_PASS}} run: | echo $VAULT_PASS > ./vault_pass.txt ansible-playbook -i inventory.yml site.yml --vault-password-file ./vault_pass.txt" 簡単ですね！ まとめ この記事では、Ansible Vaultを使った機密情報の扱い方の簡単な紹介を行いました。またそれらを組みわせて GitHub Actionsから実行する方法も紹介しました。これで、安全に リポジトリ 上の機密情報を置きながら、CI/CDも手軽に実行できる環境が構築できます。 仮想マシン などにサービスをAnsibleを使ってデプロイする場面では是非有効活用していきたいですね。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @sato.taichi （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、Stable Diffusion v1.5が出たので早速、Stable Diffusionが比較的苦手な美少女画で検証してみました。 StabilityAIではなく、Runawaymlからv1.5がリリースされたので、StabilityAIが削除申請を出したのですが、取り下げたようです。 huggingface.co Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 TPU版の使い方 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 ライセンスへの同意 huggingfaceへのログイン 必要なモジュールのインストール pipeの作成 画像の出力 美少女画による検証 日本的な美少女アニメ画 美少女イラスト 美少女写真 まとめ 仲間募集 Stable Diffusionの全コンテンツ ライセンスへの同意 https://huggingface.co/runwayml/stable-diffusion-v1-5 にアクセスして、ライセンスに同意してください。 huggingfaceへのログイン ここからは、 Google Colabでの作業になります。 huggingfaceへログインします。 from huggingface_hub import notebook_login from pathlib import Path if not (Path.home()/'.huggingface'/'token').exists(): notebook_login() 必要なモジュールのインストール 必要なモジュールをインストールします。diffusersのバージョンが特に明示されていなかったので、今回は、 TPU版の使い方 で使った 0.5.1 を使ってみました。 !pip install diffusers==0.5.1 transformers scipy ftfy pipeの作成 pipeを作成します。以前と model_id が異なることに注意してください。 from diffusers import StableDiffusionPipeline import torch model_id = "runwayml/stable-diffusion-v1-5" device = "cuda" pipe = StableDiffusionPipeline.from_pretrained(model_id, torch_dtype=torch.float16, revision="fp16") pipe = pipe.to(device) 画像の出力 画像を出力します。以前は、 image = pipe(prompt)["sample"][0] でした。 prompt = "a photo of an astronaut riding a horse on mars" image = pipe(prompt).images[0] 美少女画による検証 Stable Diffusionが比較的苦手な美少女画で検証します。結論から先に書くとv1.4より多少良くなっているけど、劇的に改善されたわけではないと言ったところでしょうか。 今回載せた画像は、意図的にイマイチだったものを選んでいます。クオリティの高い画像は、何度かやり直せば必ず出力できるので。 日本的な 美少女アニメ 画 Stable Diffusionが最も苦手とするのが、日本的な 美少女アニメ 画です。v1.4では、顔が崩れる、目が変、手が変といった問題がときどき（起きる頻度は呪文によって変わる）起きていました。 v1.5では、顔が崩れる、目が変という問題は、多少改善されていますが、まだ完璧ではありません。手が変という問題は、数十回試した限りは、全く改善されていないように感じます。 今回試した呪文はこちら。 anime of tsundere moe kawaii beautiful girl pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render イマイチだった出力結果はこちら。 美少女イラスト 美少女アニメ 画の呪文の anime を illustration に変え、 tsundere 、 moe 、 kawaii 、 pixiv 、 niconico を削ったものが、美少女イラストの呪文です。 この呪文はかなり安定していて、たまに手が変になるくらいです。 今回試した呪文はこちら。 illustration of beautiful girl artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render イマイチだった出力結果はこちら。 美少女写真 美少女写真は、安定（変にならない）度で、美少女イラストには劣りますが、日本的な 美少女アニメ 画よりは、安定しています。感覚的には、美少女イラスト > 美少女写真 >>> 日本的な 美少女アニメ 画といったところでしょうか。 今回試した呪文はこちら。 photo of beautiful girl SIGMA 85 mm F1.4 artstation impressive scene impressive composition impressive lighting イマイチだった出力結果はこちら。 まとめ 今回、Stable Diffusion v1.5を検証してみました。日本的な 美少女アニメ 画の安定度が悪いと感じたかもしれませんが、比較的辛口に評価したので、実際のv1.5の評価は、ご自分でなさることをお勧めします。 日本的な 美少女アニメ 画も head shot （顔写真）の呪文を加えれば、手が写ることはほとんどないので、次のようなクオリティの画像は連発できます。 head shot にすると構図が限られるので、あまり使ってこなかったのですが、日本的な 美少女アニメ 画では、 head shot を必須にして安定度をとったほうが良いかもしれません。 head shot にするとStable Diffusionが顔に注目するせいか、顔が変になったり、目が変になったりすることもほとんどなくなるようです。 次回は、 東京タワーの写真 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、Stable Diffusion v1.5が出たので早速、Stable Diffusionが比較的苦手な美少女画で検証してみました。 StabilityAIではなく、Runawaymlからv1.5がリリースされたので、StabilityAIが削除申請を出したのですが、取り下げたようです。 huggingface.co Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 TPU版の使い方 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 ライセンスへの同意 huggingfaceへのログイン 必要なモジュールのインストール pipeの作成 画像の出力 美少女画による検証 日本的な美少女アニメ画 美少女イラスト 美少女写真 まとめ 仲間募集 Stable Diffusionの全コンテンツ ライセンスへの同意 https://huggingface.co/runwayml/stable-diffusion-v1-5 にアクセスして、ライセンスに同意してください。 huggingfaceへのログイン ここからは、 Google Colabでの作業になります。 huggingfaceへログインします。 from huggingface_hub import notebook_login from pathlib import Path if not (Path.home()/'.huggingface'/'token').exists(): notebook_login() 必要なモジュールのインストール 必要なモジュールをインストールします。diffusersのバージョンが特に明示されていなかったので、今回は、 TPU版の使い方 で使った 0.5.1 を使ってみました。 !pip install diffusers==0.5.1 transformers scipy ftfy pipeの作成 pipeを作成します。以前と model_id が異なることに注意してください。 from diffusers import StableDiffusionPipeline import torch model_id = "runwayml/stable-diffusion-v1-5" device = "cuda" pipe = StableDiffusionPipeline.from_pretrained(model_id, torch_dtype=torch.float16, revision="fp16") pipe = pipe.to(device) 画像の出力 画像を出力します。以前は、 image = pipe(prompt)["sample"][0] でした。 prompt = "a photo of an astronaut riding a horse on mars" image = pipe(prompt).images[0] 美少女画による検証 Stable Diffusionが比較的苦手な美少女画で検証します。結論から先に書くとv1.4より多少良くなっているけど、劇的に改善されたわけではないと言ったところでしょうか。 今回載せた画像は、意図的にイマイチだったものを選んでいます。クオリティの高い画像は、何度かやり直せば必ず出力できるので。 日本的な 美少女アニメ 画 Stable Diffusionが最も苦手とするのが、日本的な 美少女アニメ 画です。v1.4では、顔が崩れる、目が変、手が変といった問題がときどき（起きる頻度は呪文によって変わる）起きていました。 v1.5では、顔が崩れる、目が変という問題は、多少改善されていますが、まだ完璧ではありません。手が変という問題は、数十回試した限りは、全く改善されていないように感じます。 今回試した呪文はこちら。 anime of tsundere moe kawaii beautiful girl pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render イマイチだった出力結果はこちら。 美少女イラスト 美少女アニメ 画の呪文の anime を illustration に変え、 tsundere 、 moe 、 kawaii 、 pixiv 、 niconico を削ったものが、美少女イラストの呪文です。 この呪文はかなり安定していて、たまに手が変になるくらいです。 今回試した呪文はこちら。 illustration of beautiful girl artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render イマイチだった出力結果はこちら。 美少女写真 美少女写真は、安定（変にならない）度で、美少女イラストには劣りますが、日本的な 美少女アニメ 画よりは、安定しています。感覚的には、美少女イラスト > 美少女写真 >>> 日本的な 美少女アニメ 画といったところでしょうか。 今回試した呪文はこちら。 photo of beautiful girl SIGMA 85 mm F1.4 artstation impressive scene impressive composition impressive lighting イマイチだった出力結果はこちら。 まとめ 今回、Stable Diffusion v1.5を検証してみました。日本的な 美少女アニメ 画の安定度が悪いと感じたかもしれませんが、比較的辛口に評価したので、実際のv1.5の評価は、ご自分でなさることをお勧めします。 日本的な 美少女アニメ 画も head shot （顔写真）の呪文を加えれば、手が写ることはほとんどないので、次のようなクオリティの画像は連発できます。 head shot にすると構図が限られるので、あまり使ってこなかったのですが、日本的な 美少女アニメ 画では、 head shot を必須にして安定度をとったほうが良いかもしれません。 head shot にするとStable Diffusionが顔に注目するせいか、顔が変になったり、目が変になったりすることもほとんどなくなるようです。 次回は、 東京タワーの写真 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

はいどーもー！ X イノベーション 本部の宮澤響です！ 本記事では、X イノベーション 本部内の部署であるソフトウェアデザインセンターと クラウド イノベーション センターに、バーチャルオフィスサービスであるGatherを導入した話をご紹介します！ そもそもGatherって何？ どういうルールで運用している？ スペース内のどこにいてもOK いつでも会話やチャットOK 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない Teamsとの使い分けは？ アクセス制限はどうしている？ 導入してみてどう？ 良かった点 グループ間を超えるコミュニケーションが増加した 「ちょっと話しかける」がしやすくなった 中途入社の不安を緩和できる 課題点 Do Not Disturbモードやマイクオフにし忘れると音声が漏れる Gather用のディスプレイがないと使いにくい 話しかけたい人がログインしているとは限らない まとめ そもそもGatherって何？ Gather （Gather.Town）とは、Gather Presence, Inc.が提供しているバーチャルオフィスサービス、つまりオフィスのように社員同士が集まる仮想的な空間を提供するサービスの一つです。 SpatialChat や oVice などと同種のサービスですが、古き良き2D- RPG を彷彿とさせる可愛らしいキャ ラク ターやマップのデザインが、それらとの大きな相違点の一つです。 マップ上で近い場所にいるメンバーや、同じ部屋や机の島にいるメンバー（こちらに関しては設定が必要ですが）にのみ音声が届くため、 Teams や Zoom での通話と異なり、「ふとしたタイミング」で「ちょっとした会話」をする、といったことがしやすいです。 料金については こちら を参照していただければと思いますが、同時接続ユーザ数が25名以下であれば、マップの数や広さに関係なく無料で利用できるので、使い始めるための金銭的なハードルが非常に低くなっています。 どういうルールで運用している？ 基本ルールとしては、以下の4つがあります。 スペース内のどこにいてもOK いつでも会話やチャットOK 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない ルールといっても、何かを制限したり強制したりといったことはほとんどしておらず、毎朝のログインすらも強制ではなく推奨としています。 スペース内のどこにいてもOK こちらは文字どおり、どこにいても（キャ ラク ターを移動させても）OKというものです。 私たちのスペースには、机や会議室が配置されている「オフィス」だけでなく、歓迎会などを開催するための「屋上」や、ワーケーション気分を味わうことができる「南国」などが存在します。 そのため、常に「オフィス」にいる必要はないですよ、というのがこちらのルールになります。 いつでも会話やチャットOK こちらも文字どおりです。 ただし、業務で扱う情報の中でも機密度が高いものに関しては、基本的にGatherでは扱わないこととしています。 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Gatherには、Do Not Disturbモードというモードが存在します。 このモードでは、自分の音声も周囲に届かず、周囲の音声も自分には届かないようになります。 そのため、TeamsやZoomでの会議中や、作業に集中したいタイミングなど、会話できない／したくないときにこのモードを利用することになります。 また、私たちのスペースには、Focusエリアという個人ブースのような場所を複数設置しています。 このエリアも同様に、会話できない／したくないときに利用することを想定しています。 なお、Do Not Disturbモードとの相違点としては、真後ろ1マスにいるメンバーに対しては、お互いの音声が届く仕様となっている点が挙げられます。 Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない 上述のDo Not DisturbモードやFocusエリアを利用しているメンバーは、基本的には会話できない／したくない状態です。 そのため、これらを利用しているメンバーには話しかけないようにしましょう、というのがこちらのルールです。 （Do Not Disturbモードに関してはそもそも話しかけても音声は届きませんが） Teamsとの使い分けは？ 弊社では、コミュニケーションツールとしてTeamsを全社利用しています。 そのため、現在は以下のような目安でTeamsとGatherを使い分けています。 とはいえ、あくまで目安ですので、Teamsで雑談会が開催されていたりもします。 Teams Gather 他部署の社員が参加する打ち合わせ 事前にスケジュールされた打ち合わせ 特定のTeamsチャネルに紐づいた打ち合わせ 左記以外の打ち合わせ ちょっとした確認、依頼 雑談 アクセス制限はどうしている？ 私たちのスペースでは、 Guest List Only Access 機能を利用したアクセス制限を実施しています。 この機能は ホワイトリスト 方式になっていて、Gatherにログインしているユーザの中でも、リストにメールアドレスが登録されているユーザのみにスペースへのアクセスを許可できます。 これにより、万が一スペースのURLが漏れてしまった場合にも、部外者がスペースに侵入することのないように設定しています。 導入してみてどう？ 良かった点 大きく以下の3点が挙げられます。 グループ間を超えるコミュニケーションが増加した 「ちょっと話しかける」がしやすくなった 中途入社の不安を緩和できる グループ間を超えるコミュニケーションが増加した 私が所属しているソフトウェアデザインセンターの開発技術グループでは、毎朝グループ内で朝会（デイリー スタンドアップ ）を実施しています。 そのため、Gather導入以前にも、グループ内のメンバーに対しては、朝会の中でコミュニケーションをとる機会がありました。 しかしながら、隣のグループであるセキュリティグループの方々とは、たまたま同じ打ち合わせに参加する、といったことがない限りは、雑談はおろか挨拶を交わす機会すらありませんでした。 もちろん、Teamsで個人チャットを送るなどすれば会話自体はできるものの、特に業務上の要件がないのに個人チャットを送るのはなかなかハードルが高いものです。 このあたりは読者の皆さんも共感していただけるのではないかと思います。 そのような状態だったのですが、Gather導入後は、近くにいる社員に、開発技術グループ、セキュリティグループ関係なく挨拶をする、といった機会が生まれました。 そこから少し雑談をしてみたり、といったこともあります。 これによって、セキュリティグループの方々とも一定の交流をもつことができ、個人的には親近感も湧きやすくなったと感じています。 これは、これまでのTeamsでは発生し得なかったコミュニケーションだと思います。 「ちょっと話しかける」がしやすくなった 前項と類似していますが、「ちょっと話しかける」といったことがしやすくなったと感じます。 例えば、「ちょっとこれ見てください！」「ちょっとここ教えてください！」といった要件をリアルタイムで相手に伝えられるため、チャットでやり取りするよりも快適なことが多いです。 また、業務の隙間時間などに突発的に始まり、周りにいる人にも会話内容が少し聞こえて、そのままふらっと会話に参加できる、そんな形の雑談が発生しやすくなりました。 「この時間に雑談しましょう！」とスケジューリングして行う雑談ももちろん雑談ではあると思うのですが、個人的にはそれに比べてより自然な形での雑談ができているなと感じています。 中途入社の不安を緩和できる カジュアル面談や 中途採用 面接の際にGatherの実際の様子をお見せすると、好反応をいただけることが多いです。 リモートワークが主体となったこの時代の転職は、やはりコミュニケーション面に不安を覚える方が多いということで、このような取り組みで少しでもその不安を緩和できればと思います。 なお、実際に最近のソフトウェアデザインセンターの中途入社メンバーからは以下のような声をいただいています。 何か不明点を確認したり気分転換をしたりしたいときにGatherにログインし、手が空いていそうな方に話しかけている。Teamsのチャットでは相手の忙しさが分からないため、画面上で動きを把握できるのは良いと思う。 とにかく何気ない会話がしやすい。雑談からの流れで何かを尋ねやすい。 一人で働いているのではなく、チームで働いている感覚をもてる。 物理オフィスであれば自然と目にする、耳にするであろう情報に近い情報を得られる。例えば、ステータスや居場所を確認することで周囲の方の状況が分かる。また、自分が会話をせずとも、周囲の方同士の会話を聞くことで、業務状況や人となりなどを知ることができる。 課題点 8月末から導入して、現在2か月ほど経過しましたが、課題としては大きく以下の3点が挙げられます。 Do Not Disturbモードやマイクオフにし忘れると音声が漏れる Gather用のディスプレイがないと使いにくい 話しかけたい人がログインしているとは限らない Do Not Disturbモードやマイクオフにし忘れると音声が漏れる これはGatherの課題点というよりはTeamsとGatherを併用する際の課題点ですが、Gatherにログインした状態でTeamsでの会議に参加すると、Do Not Disturbモードやマイクオフにしない限り、会議の音声がGather上に流れてしまうリスクがあります。 独り言を垂れ流すだけならば問題ない（垂れ流してしまった側の気分的には問題ですが…笑）のですが、会議の音声の場合、内容によっては機密情報が漏れてしまうおそれもあるので、注意が必要です。 そのため、万が一Do Not Disturbモードやマイクオフにし忘れてしまったときのためにも、会議中はFocusエリアに移動することを推奨しています。 Gather用のディスプレイがないと使いにくい 普段の業務をノートPCのディスプレイのみで行っている場合、Gatherの画面を常には表示しておけません。 そのため、Gatherを利用していてもあまりバーチャルオフィス感がなく、突然話しかけられるとテンパってしまう、といった声もありました。 話しかけたい人がログインしているとは限らない 現状では特にログインを強制していないため、話しかけたい人がログインしているとは限りません。 とはいえ、こちらは運用のルール次第ではあるので、今後検討の余地はあります。 まとめ 本記事では、X イノベーション 本部内の部署にGatherを導入した話について簡単にまとめました。 コミュニケーション活性化に有用で、見た目も可愛く、無料で始められるバーチャルオフィスサービスGather、ぜひ皆さんの部署にも導入してみませんか？ Gatherの回し者みたいになってしまいましたが、最後までお読みいただき、本当にありがとうございました！ 私たちは同じグループで共に働いていただける仲間を募集しています。 現在募集している職種は以下です。 ソリューションアーキテクト 「入社直後の右も左も分からない状態でのオンラインコミュニケーション」に対する不安をGatherで緩和できればと考えていますので、ご興味のある方、ぜひご応募お待ちしています！ 執筆： @miyazawa.hibiki 、レビュー： @yamada.y （ Shodo で執筆されました ）

はいどーもー！ X イノベーション 本部の宮澤響です！ 本記事では、X イノベーション 本部内の部署であるソフトウェアデザインセンターと クラウド イノベーション センターに、バーチャルオフィスサービスであるGatherを導入した話をご紹介します！ そもそもGatherって何？ どういうルールで運用している？ スペース内のどこにいてもOK いつでも会話やチャットOK 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない Teamsとの使い分けは？ アクセス制限はどうしている？ 導入してみてどう？ 良かった点 グループ間を超えるコミュニケーションが増加した 「ちょっと話しかける」がしやすくなった 中途入社の不安を緩和できる 課題点 Do Not Disturbモードやマイクオフにし忘れると音声が漏れる Gather用のディスプレイがないと使いにくい 話しかけたい人がログインしているとは限らない おわりに そもそもGatherって何？ Gather （Gather.Town）とは、Gather Presence, Inc.が提供しているバーチャルオフィスサービス、つまりオフィスのように社員同士が集まる仮想的な空間を提供するサービスの一つです。 SpatialChat や oVice などと同種のサービスですが、古き良き2D- RPG を彷彿とさせる可愛らしいキャ ラク ターやマップのデザインが、それらとの大きな相違点の一つです。 マップ上で近い場所にいるメンバーや、同じ部屋や机の島にいるメンバー（こちらに関しては設定が必要ですが）にのみ音声が届くため、 Teams や Zoom での通話と異なり、「ふとしたタイミング」で「ちょっとした会話」をする、といったことがしやすいです。 料金については こちら を参照していただければと思いますが、同時接続ユーザ数が25名以下であれば、マップの数や広さに関係なく無料で利用できるので、使い始めるための金銭的なハードルが非常に低くなっています。 どういうルールで運用している？ 基本ルールとしては、以下の4つがあります。 スペース内のどこにいてもOK いつでも会話やチャットOK 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない ルールといっても、何かを制限したり強制したりといったことはほとんどしておらず、毎朝のログインすらも強制ではなく推奨としています。 スペース内のどこにいてもOK こちらは文字どおり、どこにいても（キャ ラク ターを移動させても）OKというものです。 私たちのスペースには、机や会議室が配置されている「オフィス」だけでなく、歓迎会などを開催するための「屋上」や、ワーケーション気分を味わうことができる「南国」などが存在します。 そのため、常に「オフィス」にいる必要はないですよ、というのがこちらのルールになります。 いつでも会話やチャットOK こちらも文字どおりです。 ただし、業務で扱う情報の中でも機密度が高いものに関しては、基本的にGatherでは扱わないこととしています。 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Gatherには、Do Not Disturbモードというモードが存在します。 このモードでは、自分の音声も周囲に届かず、周囲の音声も自分には届かないようになります。 そのため、TeamsやZoomでの会議中や、作業に集中したいタイミングなど、会話できない／したくないときにこのモードを利用することになります。 また、私たちのスペースには、Focusエリアという個人ブースのような場所を複数設置しています。 このエリアも同様に、会話できない／したくないときに利用することを想定しています。 なお、Do Not Disturbモードとの相違点としては、真後ろ1マスにいるメンバーに対しては、お互いの音声が届く仕様となっている点が挙げられます。 Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない 上述のDo Not DisturbモードやFocusエリアを利用しているメンバーは、基本的には会話できない／したくない状態です。 そのため、これらを利用しているメンバーには話しかけないようにしましょう、というのがこちらのルールです。 （Do Not Disturbモードに関してはそもそも話しかけても音声は届きませんが） Teamsとの使い分けは？ 弊社では、コミュニケーションツールとしてTeamsを全社利用しています。 そのため、現在は以下のような目安でTeamsとGatherを使い分けています。 とはいえ、あくまで目安ですので、Teamsで雑談会が開催されていたりもします。 Teams Gather 他部署の社員が参加する打ち合わせ 事前にスケジュールされた打ち合わせ 特定のTeamsチャネルに紐づいた打ち合わせ 左記以外の打ち合わせ ちょっとした確認、依頼 雑談 アクセス制限はどうしている？ 私たちのスペースでは、 Guest List Only Access 機能を利用したアクセス制限を実施しています。 この機能は ホワイトリスト 方式になっていて、Gatherにログインしているユーザの中でも、リストにメールアドレスが登録されているユーザのみにスペースへのアクセスを許可できます。 これにより、万が一スペースのURLが漏れてしまった場合にも、部外者がスペースに侵入することのないように設定しています。 導入してみてどう？ 良かった点 大きく以下の3点が挙げられます。 グループ間を超えるコミュニケーションが増加した 「ちょっと話しかける」がしやすくなった 中途入社の不安を緩和できる グループ間を超えるコミュニケーションが増加した 私が所属しているソフトウェアデザインセンターの開発技術グループでは、毎朝グループ内で朝会（デイリー スタンドアップ ）を実施しています。 そのため、Gather導入以前にも、グループ内のメンバーに対しては、朝会の中でコミュニケーションをとる機会がありました。 しかしながら、隣のグループであるセキュリティグループの方々とは、たまたま同じ打ち合わせに参加する、といったことがない限りは、雑談はおろか挨拶を交わす機会すらありませんでした。 もちろん、Teamsで個人チャットを送るなどすれば会話自体はできるものの、特に業務上の要件がないのに個人チャットを送るのはなかなかハードルが高いものです。 このあたりは読者の皆さんも共感していただけるのではないかと思います。 そのような状態だったのですが、Gather導入後は、近くにいる社員に、開発技術グループ、セキュリティグループ関係なく挨拶をする、といった機会が生まれました。 そこから少し雑談をしてみたり、といったこともあります。 これによって、セキュリティグループの方々とも一定の交流をもつことができ、個人的には親近感も湧きやすくなったと感じています。 これは、これまでのTeamsでは発生し得なかったコミュニケーションだと思います。 「ちょっと話しかける」がしやすくなった 前項と類似していますが、「ちょっと話しかける」といったことがしやすくなったと感じます。 例えば、「ちょっとこれ見てください！」「ちょっとここ教えてください！」といった要件をリアルタイムで相手に伝えられるため、チャットでやり取りするよりも快適なことが多いです。 また、業務の隙間時間などに突発的に始まり、周りにいる人にも会話内容が少し聞こえて、そのままふらっと会話に参加できる、そんな形の雑談が発生しやすくなりました。 「この時間に雑談しましょう！」とスケジューリングして行う雑談ももちろん雑談ではあると思うのですが、個人的にはそれに比べてより自然な形での雑談ができているなと感じています。 中途入社の不安を緩和できる カジュアル面談や 中途採用 面接の際にGatherの実際の様子をお見せすると、好反応をいただけることが多いです。 リモートワークが主体となったこの時代の転職は、やはりコミュニケーション面に不安を覚える方が多いということで、このような取り組みで少しでもその不安を緩和できればと思います。 なお、実際に最近のソフトウェアデザインセンターの中途入社メンバーからは以下のような声をいただいています。 何か不明点を確認したり気分転換をしたりしたいときにGatherにログインし、手が空いていそうな方に話しかけている。Teamsのチャットでは相手の忙しさが分からないため、画面上で動きを把握できるのは良いと思う。 とにかく何気ない会話がしやすい。雑談からの流れで何かを尋ねやすい。 一人で働いているのではなく、チームで働いている感覚をもてる。 物理オフィスであれば自然と目にする、耳にするであろう情報に近い情報を得られる。例えば、ステータスや居場所を確認することで周囲の方の状況が分かる。また、自分が会話をせずとも、周囲の方同士の会話を聞くことで、業務状況や人となりなどを知ることができる。 課題点 8月末から導入して、現在2か月ほど経過しましたが、課題としては大きく以下の3点が挙げられます。 Do Not Disturbモードやマイクオフにし忘れると音声が漏れる Gather用のディスプレイがないと使いにくい 話しかけたい人がログインしているとは限らない Do Not Disturbモードやマイクオフにし忘れると音声が漏れる これはGatherの課題点というよりはTeamsとGatherを併用する際の課題点ですが、Gatherにログインした状態でTeamsでの会議に参加すると、Do Not Disturbモードやマイクオフにしない限り、会議の音声がGather上に流れてしまうリスクがあります。 独り言を垂れ流すだけならば問題ない（垂れ流してしまった側の気分的には問題ですが…笑）のですが、会議の音声の場合、内容によっては機密情報が漏れてしまうおそれもあるので、注意が必要です。 そのため、万が一Do Not Disturbモードやマイクオフにし忘れてしまったときのためにも、会議中はFocusエリアに移動することを推奨しています。 Gather用のディスプレイがないと使いにくい 普段の業務をノートPCのディスプレイのみで行っている場合、Gatherの画面を常には表示しておけません。 そのため、Gatherを利用していてもあまりバーチャルオフィス感がなく、突然話しかけられるとテンパってしまう、といった声もありました。 話しかけたい人がログインしているとは限らない 現状では特にログインを強制していないため、話しかけたい人がログインしているとは限りません。 とはいえ、こちらは運用のルール次第ではあるので、今後検討の余地はあります。 おわりに 本記事では、X イノベーション 本部内の部署にGatherを導入した話について簡単にまとめました。 コミュニケーション活性化に有用で、見た目も可愛く、無料で始められるバーチャルオフィスサービスGather、ぜひ皆さんの部署にも導入してみませんか？ Gatherの回し者みたいになってしまいましたが、最後までお読みいただき、本当にありがとうございました！ 私たちは同じ事業部で共に働いていただける仲間を募集しています！ 「入社直後の右も左も分からない状態でのオンラインコミュニケーション」に対する不安をGatherで緩和できればと考えていますので、ご興味のある方、ぜひご応募お待ちしています！ フルサイクルエンジニア 執筆： @miyazawa.hibiki 、レビュー： @yamada.y （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionの呪文シリーズ、今回は、 美少女アニメ 画改善版です。 以前、 美少女写真編 の記事を書いたのですが、あのときの問題点は、再現性が低いことでした。自分が納得する結果を出すのに、何十回もリトライを繰り返さなければならなかったのです。 今回の改善版では、単にかわいい美少女を出力するだけなら、8割ほどの確率で出力できます。「かわいい」の感覚は人それぞれですが、僕の感覚だとそれくらいの確率だということです。 厳選した画像を紹介しますが、厳選と言っても一つの画像を選ぶのに10回はかかっていません。 v2.1 美少女アニメ画 もよろしければ、御覧ください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 改善呪文 anime of tsundere moe kawaii beautiful pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render digital painting extremely detailed sharp focus cinematic postprocessing 出力結果 まとめ 仲間募集 Stable Diffusionの全コンテンツ 改善呪文 横長、コピー&ペースト用 anime of tsundere moe kawaii beautiful girl　pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render 改行版 anime of tsundere moe kawaii beautiful girl pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render 改良前版（対比しやすいように順番は入れ替えました） japanese anime of a beaultiful girl pixiv light novel fantasy costume fantasy background beautiful composition cinematic lighting ray tracing 8k digital painting extremely detailed sharp focus cinematic postprocessing anime of 前回は、 japanese をつけていたのですが、比較テストしたところ、 japanese をつけないほうが、良い結果が出ました。 tsundere moe kawaii beautiful 前回は、 beautiful だけだったのですが、 tsundere moe kawaii を足すと「ちょっと」結果が良くなるようです。これは「思い込み」かもしれません。 pixiv niconico artstation deviantart newgrounds tumblr 今回、一番効果が大きかった「作風」の部分です。 前回は、 pixiv に light novel を足していました。 pixiv だけだと効果が少なかったためです。しかし、 light novel もそれほど効果のない呪文だったので、出力結果のクオリティがバラバラでした。 今回、効果の薄かった light novel を削り、 niconico artstation deviantart newgrounds tumblr を足したところ、出力結果がかなり安定するようになりました。 イラストの投稿サイトの中で、テストして結果が良かったサイトを残しました。 fantasy scene fantasy composition fantasy lighting 前回は、 costume と background を指定していましたが、これはざっくり scene で良いようです。 scene 、 composition 、 lighting の修飾語を fantasy に変えた結果、思い切りファンタ ジー な雰囲気になりました。修飾語は好みで変えてください。 PlayStation5 octane render 前回は、 ray tracing 8k を指定していましたが、 octane render のほうが、フォトリアルにする効果が高いようです。 PlayStation5 は、フォトリアルにするだけでなく、アニメのクオリティにも良い効果を与えるようです。 digital painting extremely detailed sharp focus cinematic postprocessing extremely detailed をつけると人物が大きく描画され、バランスの悪い構図になる確率が増えるので、今回は削りました。 digital painting sharp focus cinematic postprocessing は、テストした結果、明確な効果が感じられなかったため削りました。 出力結果 出力結果はこちらになります。 まとめ 美少女アニメ 画の出力結果の安定性（再現性）を改善したのは、イラストの投稿サイトの数を増やしたことでした。みなさんも、是非試してください。 次回は、 v1.5 美少女画検証 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionの呪文シリーズ、今回は、 美少女アニメ 画改善版です。 以前、 美少女写真編 の記事を書いたのですが、あのときの問題点は、再現性が低いことでした。自分が納得する結果を出すのに、何十回もリトライを繰り返さなければならなかったのです。 今回の改善版では、単にかわいい美少女を出力するだけなら、8割ほどの確率で出力できます。「かわいい」の感覚は人それぞれですが、僕の感覚だとそれくらいの確率だということです。 厳選した画像を紹介しますが、厳選と言っても一つの画像を選ぶのに10回はかかっていません。 v2.1 美少女アニメ画 もよろしければ、御覧ください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 改善呪文 anime of tsundere moe kawaii beautiful pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render digital painting extremely detailed sharp focus cinematic postprocessing 出力結果 まとめ 仲間募集 Stable Diffusionの全コンテンツ 改善呪文 横長、コピー&ペースト用 anime of tsundere moe kawaii beautiful girl　pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render 改行版 anime of tsundere moe kawaii beautiful girl pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render 改良前版（対比しやすいように順番は入れ替えました） japanese anime of a beaultiful girl pixiv light novel fantasy costume fantasy background beautiful composition cinematic lighting ray tracing 8k digital painting extremely detailed sharp focus cinematic postprocessing anime of 前回は、 japanese をつけていたのですが、比較テストしたところ、 japanese をつけないほうが、良い結果が出ました。 tsundere moe kawaii beautiful 前回は、 beautiful だけだったのですが、 tsundere moe kawaii を足すと「ちょっと」結果が良くなるようです。これは「思い込み」かもしれません。 pixiv niconico artstation deviantart newgrounds tumblr 今回、一番効果が大きかった「作風」の部分です。 前回は、 pixiv に light novel を足していました。 pixiv だけだと効果が少なかったためです。しかし、 light novel もそれほど効果のない呪文だったので、出力結果のクオリティがバラバラでした。 今回、効果の薄かった light novel を削り、 niconico artstation deviantart newgrounds tumblr を足したところ、出力結果がかなり安定するようになりました。 イラストの投稿サイトの中で、テストして結果が良かったサイトを残しました。 fantasy scene fantasy composition fantasy lighting 前回は、 costume と background を指定していましたが、これはざっくり scene で良いようです。 scene 、 composition 、 lighting の修飾語を fantasy に変えた結果、思い切りファンタ ジー な雰囲気になりました。修飾語は好みで変えてください。 PlayStation5 octane render 前回は、 ray tracing 8k を指定していましたが、 octane render のほうが、フォトリアルにする効果が高いようです。 PlayStation5 は、フォトリアルにするだけでなく、アニメのクオリティにも良い効果を与えるようです。 digital painting extremely detailed sharp focus cinematic postprocessing extremely detailed をつけると人物が大きく描画され、バランスの悪い構図になる確率が増えるので、今回は削りました。 digital painting sharp focus cinematic postprocessing は、テストした結果、明確な効果が感じられなかったため削りました。 出力結果 出力結果はこちらになります。 まとめ 美少女アニメ 画の出力結果の安定性（再現性）を改善したのは、イラストの投稿サイトの数を増やしたことでした。みなさんも、是非試してください。 次回は、 v1.5 美少女画検証 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、 Amazon Web Services ( AWS )のApplication LoadBalancer(ALB)とgRPCを合わせて利用する場合の方法について紹介します。 ALBでgRPCのサポートされて利用できる場所が広がりつつあります。 https://aws.amazon.com/jp/blogs/aws/new-application-load-balancer-support-for-end-to-end-http-2-and-grpc/ 今回は、このALBとgRPCを組み合わせて利用する場合の設定方法とその注意点について紹介します。 ターゲットグループの作成時に注意が必要 gRPCは基本的に通常の HTTPS 通信です。このためALB自体は普段通りの設定で作成して問題ありません。gRPCを利用する場合はターゲットグループを作成するときに、以下のようにProtocolには HTTPS を指定し、Protocol Versionの設定をgRPCに変更することで利用できます。 ヘルスチェック用のサービスを実装しておく ヘルスチェックの項目では、gRPCのサービスを呼びだす設定が必要です。このため、実際にALBを利用することを想定する場合は、アプリケーション側でヘルスチェック用のサービスを実装する必要があります。 gRPCのKeepAlive機能が利用できない gRPCには通信を途絶させないためのKeepAliveの機能が実装されています。しかし、ALBはこのパケットが到達しても後続のサービスにはそれを渡さない実装となっているようです。このため、gRPCの機能のkeepAlive機能を設定しても通信が切断されてしまいます。 この問題は、Unary RPCのように短時間で終了するサービスであれば問題にならないことが多いです。しかしBidirecional Streaming RPCのようにコネクションを保ったまま通信を行う場合に通信の途中で切断される場合があります。このため、プログラム側でサーバ向けに定期的にパケットを送り続けるような工夫を行う必要があります。 パスによるアクセス制限などの方法は問題なく利用できます gRPCは通常のHTTP/2の プロトコル を利用しており、通常のHTTPで実施するアクセス先(path)による制限などを実施できます。 /<package名>.<Service名>/<rpc名> といったpathを指定することで特定のRPCだけアクセスを拒否できます。 以下の図のように設定することで、 /foo.Bar/Baz というRPCだけ503エラーを返すように設定できます。 認証などの設定も同様に行うことが可能です。 まとめ 今回は、 AWS のALBとgRPCを組み合わせる際に注意が必要になる点についてまとめました。ただし、keepAliveが利用できなかったり、ヘルスチェック専用のサービスが必要となるなど、いくつか注意点がありますが問題なく利用できました。 これからは、積極的にgRPCを活用していきたいですね。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @higa （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、 Amazon Web Services ( AWS )のApplication LoadBalancer(ALB)とgRPCを合わせて利用する場合の方法について紹介します。 ALBでgRPCのサポートされて利用できる場所が広がりつつあります。 https://aws.amazon.com/jp/blogs/aws/new-application-load-balancer-support-for-end-to-end-http-2-and-grpc/ 今回は、このALBとgRPCを組み合わせて利用する場合の設定方法とその注意点について紹介します。 ターゲットグループの作成時に注意が必要 gRPCは基本的に通常の HTTPS 通信です。このためALB自体は普段通りの設定で作成して問題ありません。gRPCを利用する場合はターゲットグループを作成するときに、以下のようにProtocolには HTTPS を指定し、Protocol Versionの設定をgRPCに変更することで利用できます。 ヘルスチェック用のサービスを実装しておく ヘルスチェックの項目では、gRPCのサービスを呼びだす設定が必要です。このため、実際にALBを利用することを想定する場合は、アプリケーション側でヘルスチェック用のサービスを実装する必要があります。 gRPCのKeepAlive機能が利用できない gRPCには通信を途絶させないためのKeepAliveの機能が実装されています。しかし、ALBはこのパケットが到達しても後続のサービスにはそれを渡さない実装となっているようです。このため、gRPCの機能のkeepAlive機能を設定しても通信が切断されてしまいます。 この問題は、Unary RPCのように短時間で終了するサービスであれば問題にならないことが多いです。しかしBidirecional Streaming RPCのようにコネクションを保ったまま通信を行う場合に通信の途中で切断される場合があります。このため、プログラム側でサーバ向けに定期的にパケットを送り続けるような工夫を行う必要があります。 パスによるアクセス制限などの方法は問題なく利用できます gRPCは通常のHTTP/2の プロトコル を利用しており、通常のHTTPで実施するアクセス先(path)による制限などを実施できます。 /<package名>.<Service名>/<rpc名> といったpathを指定することで特定のRPCだけアクセスを拒否できます。 以下の図のように設定することで、 /foo.Bar/Baz というRPCだけ503エラーを返すように設定できます。 認証などの設定も同様に行うことが可能です。 まとめ 今回は、 AWS のALBとgRPCを組み合わせる際に注意が必要になる点についてまとめました。ただし、keepAliveが利用できなかったり、ヘルスチェック専用のサービスが必要となるなど、いくつか注意点がありますが問題なく利用できました。 これからは、積極的にgRPCを活用していきたいですね。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusion（というよりdiffusers）でTPU（JAX / Flax）を使った並列実行バージョンがリリースされたので、早速試してみました。 オリジナルのNotebook はこちら。 僕が作ったNotebook はこちら。 今回は、TPUを使うので、 Google Colabに特化しています。自分で１から試す方は、メニューのEdit -> Notebook settingsでTPUを使うように設定してください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 必要なモジュールのインストール 必要なモジュールのインポート huggingfaceにログイン pipelineとparamsの作成 show_images()の定義 show_images()の実行 まとめ 仲間募集 Stable Diffusionの全コンテンツ 必要なモジュールのインストール 次のようにして必要なモジュールをインストールします。 !pip install --upgrade jax jaxlib !pip install flax transformers ftfy !pip install diffusers==0.5.1 必要なモジュールのインポート 次のようにして必要なモジュールをインポートします。 import jax.tools.colab_tpu jax.tools.colab_tpu.setup_tpu('tpu_driver_20221011') import jax import numpy as np import jax import jax.numpy as jnp from pathlib import Path from jax import pmap from flax.jax_utils import replicate from flax.training.common_utils import shard from PIL import Image from IPython.display import display import random from huggingface_hub import notebook_login from diffusers import FlaxStableDiffusionPipeline huggingfaceにログイン huggingfaceにログインします。 まだ、huggingfaceの トーク ンを取得していない場合は、 huggingface でユーザー登録を行い、 トーク ンを取得してください。 if not (Path.home()/'.huggingface'/'token').exists(): notebook_login() pipelineとparamsの作成 次のようにして、pipelineとparamsを作成します。 pipeline, params = FlaxStableDiffusionPipeline.from_pretrained( "CompVis/stable-diffusion-v1-4", revision="bf16", dtype=jnp.bfloat16, ) show_images()の定義 呪文から、画像を生成するための関数を作成します。現状のColabでは、TPUは、8個まで並列実行できます。 def show_images(prompt): seed = random.randrange(1000000) rng = jax.random.PRNGKey(seed) rng = jax.random.split(rng, jax.device_count()) p_params = replicate(params) prompt = [prompt] * jax.device_count() prompt_ids = pipeline.prepare_inputs(prompt) prompt_ids = shard(prompt_ids) images = pipeline(prompt_ids, p_params, rng, jit=True)[0] images = images.reshape((jax.device_count(), ) + images.shape[-3:]) images = pipeline.numpy_to_pil(images) for image in images: display(image) オリジナルのNotebookでは、8つの画像がGridになっていて、個別にダウンロードできないので、個別にダウンロードできるようにしてみました。 show_images()の実行 次の呪文で、show_images()を実行してみました。 prompt = "illustration of beaultiful girl detailed beautiful face detailed perfect pupil of eyes detailed mouth detailed shoulders detailed chest highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition cinematic lighting ray tracing 8k" show_images(prompt) 今回の呪文（横長、コピー&ペースト用） illustration of beaultiful girl detailed beautiful face detailed perfect pupil of eyes detailed mouth detailed shoulders detailed chest highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition cinematic lighting ray tracing 8k 閲覧用呪文（改行版） illustration of beaultiful girl detailed beautiful face detailed perfect pupil of eyes detailed mouth detailed shoulders detailed chest highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition cinematic lighting ray tracing 8k 画像出力結果 全く選別していない、出力されたそのままの画像です。 まとめ Stable Diffusionが8つの画像を同時生成できるようになったのは、画期的ではないでしょうか。しかも、TPUを使うので、 GPU を使い切っていても使うことができるのです。実際僕は、 Google Colab Proの GPU を現在使い切ってしまっていて、 GPU を使うことはできないのですが、TPUは使えました。 追記: その後、あっという間に、TPUの無料枠分を使い切ってしまいました。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）