電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、Stable Diffusion 2.1- 美少女アニメ 画です。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文 美少女アニメ画 美少女写真 女性イラスト 長い呪文は切り捨てられる AUTOMATIC1111のインストール AUTOMATIC1111のセッティング 美少女アニメ画の呪文 通常呪文の解説 masterpiece high quality highly detailed (kawaii princess:1.2) white glowing skin (kawaii face with blush:1.2) blue eyes with eyelashes long waved hair (cleavage breasts:1.1) open shoulders gothic lolita glossy dress with ruffles gorgeous jewelry accessories (anime:1.3) artstation gorgeous background centered composition lim lighting intense shadows ネガティブ呪文の解説 deformed mutated disfigured lowres blurred repetitive double mutated hands bad hands missing hands extra hands liquid hands poorly drawn hands mutated fingers bad fingers missing fingers extra fingers liquid fingers poorly drawn fingers partial head bad face small face partial face bad eyes too big eyes bad eyebrows bad eyelashes bad nose missing nose bad mouth missing mouth open mouth bad ears thick lips chest pad bad legs missing legs extra legs bad arms missing arms extra arms low quality normal quality crown black and white 手が変になる問題は改善されたのか まとめ 仲間募集 Stable Diffusionの全コンテンツ AUTOMATIC1111のインストール Stable Diffusion 2.1 を実行する環境として、 AUTOMATIC1111 を使います。 AUTOMATIC1111 は、 Stable Diffusion を Google Colab 直接ではなく、 UI 経由で実行できるようにしています。似たような機能のものはいくつかありますが、 AUTOMATIC1111 は人気が高く、情報量も多いのでおすすめです。 Google Colab で動かすための公式のノートブックは こちら になります。 このノートブックを実行すると、下の方に Running on public URL: https://2c76db068be0e79a.gradio.app のようなリンクが表示されるので、クリックしましょう。 AUTOMATIC1111のセッティング パラメータは以下のようになります。 Sampling Steps: 50 Sampling Method: DPM2 Width: 768 Height: 768 CFG Scale: 7.5 Seed: -1 Sampling Stepsは、デフォルトの 20 だと少ないので、 50 くらいにしておきましょう。 Sampling Methodは DPM2 をお勧めしますが、 DDIM も悪くはありません。 Width と Height は 768 をお勧めします。今回使っているモデルは、 768 用のためです。 512 だとかを使うと画像が崩れることがあります。 CFG Scale は入力した呪文にどれだけ近い画像を生成するかのパラメータです。デフォルトの 7 でも問題ありませんが、僕はなんとなく 7.5 を指定しています。 美少女アニメ 画の呪文 それでは、 美少女アニメ 画の呪文（prompt）を紹介します。今回から、ネガティブ呪文も合わせて紹介します。ネガティブ呪文とは通常呪文を打ち消す呪文です。 例えば、ネガティブ呪文に mutated hands を指定すると、 変異した手 が出力されにくくなります。 通常呪文は次のようになります。 masterpiece high quality highly detailed (kawaii princess:1.2) white glowing skin (kawaii face with blush:1.2) blue eyes with eyelashes long waved hair (cleavage breasts:1.1) open shoulders gothic lolita glossy dress with ruffles gorgeous jewelry accessories (anime:1.3) artstation gorgeous background centered composition lim lighting intense shadows 通常呪文の改行版は次のようになります。 masterpiece high quality highly detailed (kawaii princess:1.2) white glowing skin (kawaii face with blush:1.2) blue eyes with eyelashes long waved hair (cleavage breasts:1.1) open shoulders gothic lolita glossy dress with ruffles gorgeous jewelry accessories (anime:1.3) artstation gorgeous background centered composition lim lighting intense shadows ネガティブ呪文は次のようになります。 deformed mutated disfigured lowres blurred repetitive double mutated hands bad hands missing hands extra hands liquid hands poorly drawn hands mutated fingers bad fingers missing fingers extra fingers liquid fingers poorly drawn fingers partial head bad face small face partial face bad eyes too big eyes bad eyebrows bad eyelashes bad nose missing nose bad mouth missing mouth open mouth bad ears thick lips chest pad bad legs missing legs extra legs bad arms missing arms extra arms low quality normal quality crown black and white ネガティブ呪文の改行版は次のようになります。 deformed mutated lowres blurred disfigured repetitive double mutated hands bad hands missing hands extra hands liquid hands poorly drawn hands mutated fingers bad fingers missing fingers extra fingers liquid fingers poorly drawn fingers partial head bad face small face partial face bad eyes too big eyes bad eyebrows bad eyelashes bad nose missing nose bad mouth missing mouth open mouth bad ears thick lips chest pad bad legs missing legs extra legs bad arms missing arms extra arms low quality normal quality crown black and white 出力結果の例です。 通常呪文の解説 それでは、通常呪文を解説しましょう。 masterpiece masterpiece は、「傑作」、「名作」、「定番」の意味で、これを初めの方に持ってくると画像のクオリティが上がる気がします。「気がします」というのは、「確信はないけど経験上は、そのように感じる」という意味です。 high quality high quality は、「高品質」の意味で、これを初めの方に持ってくると画像のクオリティが上がる気がします。 highly detailed highly detailed は、「とても詳細に描画する」という意味で、これを初めの方に持ってくると画像のクオリティが上がる気がします。 ( kawaii princess:1.2) kawaii princess が今回の描画対象です。 beautiful girl よりも kawaii princess の方が、美少女率が高くなる気がします。 (呪文:数値) は、呪文を強調する AUTOMAIC1111 の構文です。数値が 1.0 は強調なしで、 呪文 と全く同じになります。数値が 1.0 より大きいと強調され、 1.0 より低いと弱められます。 white glowing skin white glowing skin は、「白く輝く肌」という意味です。 ( kawaii face with blush:1.2) kawaii face with blush は、「ほほがちょっと赤い可愛い顔」という意味です。 beautiful face より kawaii face の方が、美少女率が高くなる気がします。 通常より強調（1.2）しています。好みで数値を調整してください。 blue eyes with eyelashes blue eyes with eyelashes は、「まつげのある青い目」という意味です。 blue の部分は好きな色に変えてください。 long waved hair long waved hair は、「長いウェーブのかかった髪」という意味です。好みで、色を足したり、 waved を straight に変えてください。 (cleavage breasts:1.1) cleavage breasts は、「胸の谷間」という意味です。通常より強調（1.1）しています。好みで数値を調整してください。 open shoulders open shoulders は、「肩が露出している」という意味です。 gothic lolita glossy dress with ruffles gothic lolita glossy dress with ruffles は、「フリル付きの光沢のあるゴシックロリータドレス」という意味です。 gorgeous jewelry accessories gorgeous jewelry accessories は、「ゴージャスな宝石のついたアクセサリー」という意味です。 (anime:1.3) anime を指定することで、アニメ画になります。アニメっぽくなるように少し強調（1.3）しています。 artstation artstation は、イラストの投稿サイトです。指定するとイラストのクオリティが上がります。 gorgeous background gorgeous background を指定して、背景を「ゴージャス」にします。「ゴージャス」というのはアバウトに感じるかもしれませんが、この指定でいい感じの背景になることが多いです。 centered composition centered composition を指定して、描画対象を中心に持ってきます。 lim lighting lim lighting を指定して、モデルの後方からライトをあて、モデルの輪郭がうっすら明るくなるようにします。 intense shadows intense shadows は、「強い影」という意味です。影が強調されることで、メリハリの付いた画像になります。 ネガティブ呪文の解説 次は、ネガティブ呪文を解説します。ネガティブ呪文とは、通常呪文を打ち消す呪文です。 deformed mutated disfigured deformed 、 mutated 、 disfigured は、「変形した」を打ち消します。 lowres lowres は、「低い解像度」を打ち消します。 blurred blurred は、「ぼやけた」を打ち消します。 repetitive repetitive は、「繰り返し」を打ち消します。体のパーツなどが余分に複製されることを防ぎます。 double double は、「二重」を打ち消します。体のパーツなどが余分に複製されることを防ぎます。 mutated hands bad hands missing hands extra hands liquid hands poorly drawn hands hands （手）は、最も変になりやすい部位のひとつなので、 mutated （変異した）、 bad （ダメな）、 missing （存在しない）、 extra （余分な）、 liquid （液状の）、 poorly drawn （下手に描かれた）を指定して、念入りに打ち消します。 mutated fingers bad fingers missing fingers extra fingers liquid fingers poorly drawn fingers fingers （指）も、最も変になりやすい部位のひとつなので、手と同様に念入りに打ち消します。 partial head partial head で、「部分的な頭」を打ち消します。頭の一部が欠けることを防ぎます。 bad face small face partial face bad face で、「ダメな顔」を打ち消します。 small face で、「小さい顔」を打ち消します。人物が小さくなりすぎるのを防ぎます。 partial face で、「部分的な顔」を打ち消します。顔の一部が欠けることを防ぎます。 bad eyes too big eyes bad eyes で、「だめな目」を打ち消します。 too big eyes で、目が大きくなりすぎるのを防ぎます。 bad eyebrows bad eyebrows で、「ダメなまゆげ」を打ち消します。 bad eyelashes bad eyelashes で、「ダメなまつげ」を打ち消します。 bad nose missing nose nose （鼻）は、消えてしまうことがあるので、 missing （存在しない）で打ち消します。 bad mouth missing mouth open mouth mouth （口）は、消えてしまうことがあるので、 missing （存在しない）で打ち消します。 open mouth で、口がぽかんと開くのを防ぎます。 bad ears bad ears で、「ダメな耳」を打ち消します。 thick lips thick lips で、「厚い唇」を打ち消します。 chest pad 通常呪文で cleavage breasts （胸の谷間）を指定すると、ときどき、胸パッドが出力されることがあります。これを chest pad （胸パッド）で打ち消します。 bad legs missing legs extra legs legs （脚）は、ときどき消えたり、余分な足が生えたりするので、 missing （存在しない）、 extra （余分な）で打ち消します。 bad arms missing arms extra arms arms （腕）は、ときどき消えたり、余分な腕が生えたりするので、 missing （存在しない）、 extra （余分な）で打ち消します。 low quality normal quality low quality （低いクオリティ）、 normal quality （普通のクオリティ）を打ち消します。その結果、 high quality （高いクオリティ）の画像になります。 crown 描画対象が、 princess なので、王冠をかぶる確率が増えます。王冠がいらない場合は、 crown で打ち消します。 black and white black and white （白黒）を指定して、モノクロ画像になってしまうのを防ぎます。 手が変になる問題は改善されたのか Stable Diffusion 2.1 は、「手/指が変になる問題」が改善されていると公式が発表しているので、検証してみました。 僕の試した結果では、手が指までちゃんと描画されるのは、手が描画されるケースで、20回に1回あるかないかです。今後のアップデートに期待ですね。 まとめ 今回は、 美少女アニメ 画の呪文を紹介しました。 かなり高確率でクオリティの高い画像が出力されるので、みなさんもぜひ試してください。 次回は、- v2.1 金髪美女写真 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 2.1- 美少女アニメ 画です。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文 美少女アニメ画 美少女写真 女性イラスト 長い呪文は切り捨てられる AUTOMATIC1111のインストール AUTOMATIC1111のセッティング 美少女アニメ画の呪文 通常呪文の解説 masterpiece high quality highly detailed (kawaii princess:1.2) white glowing skin (kawaii face with blush:1.2) blue eyes with eyelashes long waved hair (cleavage breasts:1.1) open shoulders gothic lolita glossy dress with ruffles gorgeous jewelry accessories (anime:1.3) artstation gorgeous background centered composition lim lighting intense shadows ネガティブ呪文の解説 deformed mutated disfigured lowres blurred repetitive double mutated hands bad hands missing hands extra hands liquid hands poorly drawn hands mutated fingers bad fingers missing fingers extra fingers liquid fingers poorly drawn fingers partial head bad face small face partial face bad eyes too big eyes bad eyebrows bad eyelashes bad nose missing nose bad mouth missing mouth open mouth bad ears thick lips chest pad bad legs missing legs extra legs bad arms missing arms extra arms low quality normal quality crown black and white 手が変になる問題は改善されたのか まとめ 仲間募集 Stable Diffusionの全コンテンツ AUTOMATIC1111のインストール Stable Diffusion 2.1 を実行する環境として、 AUTOMATIC1111 を使います。 AUTOMATIC1111 は、 Stable Diffusion を Google Colab 直接ではなく、 UI 経由で実行できるようにしています。似たような機能のものはいくつかありますが、 AUTOMATIC1111 は人気が高く、情報量も多いのでおすすめです。 Google Colab で動かすための公式のノートブックは こちら になります。 このノートブックを実行すると、下の方に Running on public URL: https://2c76db068be0e79a.gradio.app のようなリンクが表示されるので、クリックしましょう。 AUTOMATIC1111のセッティング パラメータは以下のようになります。 Sampling Steps: 50 Sampling Method: DPM2 Width: 768 Height: 768 CFG Scale: 7.5 Seed: -1 Sampling Stepsは、デフォルトの 20 だと少ないので、 50 くらいにしておきましょう。 Sampling Methodは DPM2 をお勧めしますが、 DDIM も悪くはありません。 Width と Height は 768 をお勧めします。今回使っているモデルは、 768 用のためです。 512 だとかを使うと画像が崩れることがあります。 CFG Scale は入力した呪文にどれだけ近い画像を生成するかのパラメータです。デフォルトの 7 でも問題ありませんが、僕はなんとなく 7.5 を指定しています。 美少女アニメ 画の呪文 それでは、 美少女アニメ 画の呪文（prompt）を紹介します。今回から、ネガティブ呪文も合わせて紹介します。ネガティブ呪文とは通常呪文を打ち消す呪文です。 例えば、ネガティブ呪文に mutated hands を指定すると、 変異した手 が出力されにくくなります。 通常呪文は次のようになります。 masterpiece high quality highly detailed (kawaii princess:1.2) white glowing skin (kawaii face with blush:1.2) blue eyes with eyelashes long waved hair (cleavage breasts:1.1) open shoulders gothic lolita glossy dress with ruffles gorgeous jewelry accessories (anime:1.3) artstation gorgeous background centered composition lim lighting intense shadows 通常呪文の改行版は次のようになります。 masterpiece high quality highly detailed (kawaii princess:1.2) white glowing skin (kawaii face with blush:1.2) blue eyes with eyelashes long waved hair (cleavage breasts:1.1) open shoulders gothic lolita glossy dress with ruffles gorgeous jewelry accessories (anime:1.3) artstation gorgeous background centered composition lim lighting intense shadows ネガティブ呪文は次のようになります。 deformed mutated disfigured lowres blurred repetitive double mutated hands bad hands missing hands extra hands liquid hands poorly drawn hands mutated fingers bad fingers missing fingers extra fingers liquid fingers poorly drawn fingers partial head bad face small face partial face bad eyes too big eyes bad eyebrows bad eyelashes bad nose missing nose bad mouth missing mouth open mouth bad ears thick lips chest pad bad legs missing legs extra legs bad arms missing arms extra arms low quality normal quality crown black and white ネガティブ呪文の改行版は次のようになります。 deformed mutated lowres blurred disfigured repetitive double mutated hands bad hands missing hands extra hands liquid hands poorly drawn hands mutated fingers bad fingers missing fingers extra fingers liquid fingers poorly drawn fingers partial head bad face small face partial face bad eyes too big eyes bad eyebrows bad eyelashes bad nose missing nose bad mouth missing mouth open mouth bad ears thick lips chest pad bad legs missing legs extra legs bad arms missing arms extra arms low quality normal quality crown black and white 出力結果の例です。 通常呪文の解説 それでは、通常呪文を解説しましょう。 masterpiece masterpiece は、「傑作」、「名作」、「定番」の意味で、これを初めの方に持ってくると画像のクオリティが上がる気がします。「気がします」というのは、「確信はないけど経験上は、そのように感じる」という意味です。 high quality high quality は、「高品質」の意味で、これを初めの方に持ってくると画像のクオリティが上がる気がします。 highly detailed highly detailed は、「とても詳細に描画する」という意味で、これを初めの方に持ってくると画像のクオリティが上がる気がします。 ( kawaii princess:1.2) kawaii princess が今回の描画対象です。 beautiful girl よりも kawaii princess の方が、美少女率が高くなる気がします。 (呪文:数値) は、呪文を強調する AUTOMAIC1111 の構文です。数値が 1.0 は強調なしで、 呪文 と全く同じになります。数値が 1.0 より大きいと強調され、 1.0 より低いと弱められます。 white glowing skin white glowing skin は、「白く輝く肌」という意味です。 ( kawaii face with blush:1.2) kawaii face with blush は、「ほほがちょっと赤い可愛い顔」という意味です。 beautiful face より kawaii face の方が、美少女率が高くなる気がします。 通常より強調（1.2）しています。好みで数値を調整してください。 blue eyes with eyelashes blue eyes with eyelashes は、「まつげのある青い目」という意味です。 blue の部分は好きな色に変えてください。 long waved hair long waved hair は、「長いウェーブのかかった髪」という意味です。好みで、色を足したり、 waved を straight に変えてください。 (cleavage breasts:1.1) cleavage breasts は、「胸の谷間」という意味です。通常より強調（1.1）しています。好みで数値を調整してください。 open shoulders open shoulders は、「肩が露出している」という意味です。 gothic lolita glossy dress with ruffles gothic lolita glossy dress with ruffles は、「フリル付きの光沢のあるゴシックロリータドレス」という意味です。 gorgeous jewelry accessories gorgeous jewelry accessories は、「ゴージャスな宝石のついたアクセサリー」という意味です。 (anime:1.3) anime を指定することで、アニメ画になります。アニメっぽくなるように少し強調（1.3）しています。 artstation artstation は、イラストの投稿サイトです。指定するとイラストのクオリティが上がります。 gorgeous background gorgeous background を指定して、背景を「ゴージャス」にします。「ゴージャス」というのはアバウトに感じるかもしれませんが、この指定でいい感じの背景になることが多いです。 centered composition centered composition を指定して、描画対象を中心に持ってきます。 lim lighting lim lighting を指定して、モデルの後方からライトをあて、モデルの輪郭がうっすら明るくなるようにします。 intense shadows intense shadows は、「強い影」という意味です。影が強調されることで、メリハリの付いた画像になります。 ネガティブ呪文の解説 次は、ネガティブ呪文を解説します。ネガティブ呪文とは、通常呪文を打ち消す呪文です。 deformed mutated disfigured deformed 、 mutated 、 disfigured は、「変形した」を打ち消します。 lowres lowres は、「低い解像度」を打ち消します。 blurred blurred は、「ぼやけた」を打ち消します。 repetitive repetitive は、「繰り返し」を打ち消します。体のパーツなどが余分に複製されることを防ぎます。 double double は、「二重」を打ち消します。体のパーツなどが余分に複製されることを防ぎます。 mutated hands bad hands missing hands extra hands liquid hands poorly drawn hands hands （手）は、最も変になりやすい部位のひとつなので、 mutated （変異した）、 bad （ダメな）、 missing （存在しない）、 extra （余分な）、 liquid （液状の）、 poorly drawn （下手に描かれた）を指定して、念入りに打ち消します。 mutated fingers bad fingers missing fingers extra fingers liquid fingers poorly drawn fingers fingers （指）も、最も変になりやすい部位のひとつなので、手と同様に念入りに打ち消します。 partial head partial head で、「部分的な頭」を打ち消します。頭の一部が欠けることを防ぎます。 bad face small face partial face bad face で、「ダメな顔」を打ち消します。 small face で、「小さい顔」を打ち消します。人物が小さくなりすぎるのを防ぎます。 partial face で、「部分的な顔」を打ち消します。顔の一部が欠けることを防ぎます。 bad eyes too big eyes bad eyes で、「だめな目」を打ち消します。 too big eyes で、目が大きくなりすぎるのを防ぎます。 bad eyebrows bad eyebrows で、「ダメなまゆげ」を打ち消します。 bad eyelashes bad eyelashes で、「ダメなまつげ」を打ち消します。 bad nose missing nose nose （鼻）は、消えてしまうことがあるので、 missing （存在しない）で打ち消します。 bad mouth missing mouth open mouth mouth （口）は、消えてしまうことがあるので、 missing （存在しない）で打ち消します。 open mouth で、口がぽかんと開くのを防ぎます。 bad ears bad ears で、「ダメな耳」を打ち消します。 thick lips thick lips で、「厚い唇」を打ち消します。 chest pad 通常呪文で cleavage breasts （胸の谷間）を指定すると、ときどき、胸パッドが出力されることがあります。これを chest pad （胸パッド）で打ち消します。 bad legs missing legs extra legs legs （脚）は、ときどき消えたり、余分な足が生えたりするので、 missing （存在しない）、 extra （余分な）で打ち消します。 bad arms missing arms extra arms arms （腕）は、ときどき消えたり、余分な腕が生えたりするので、 missing （存在しない）、 extra （余分な）で打ち消します。 low quality normal quality low quality （低いクオリティ）、 normal quality （普通のクオリティ）を打ち消します。その結果、 high quality （高いクオリティ）の画像になります。 crown 描画対象が、 princess なので、王冠をかぶる確率が増えます。王冠がいらない場合は、 crown で打ち消します。 black and white black and white （白黒）を指定して、モノクロ画像になってしまうのを防ぎます。 手が変になる問題は改善されたのか Stable Diffusion 2.1 は、「手/指が変になる問題」が改善されていると公式が発表しているので、検証してみました。 僕の試した結果では、手が指までちゃんと描画されるのは、手が描画されるケースで、20回に1回あるかないかです。今後のアップデートに期待ですね。 まとめ 今回は、 美少女アニメ 画の呪文を紹介しました。 かなり高確率でクオリティの高い画像が出力されるので、みなさんもぜひ試してください。 次回は、- v2.1 金髪美女写真 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の若本です。 本記事は 電通国際情報サービス Advent Calendar 2022 の12日目の記事となります！前日の記事は徳山さんの「フロントエンド開発にちょっと慣れてきた方におすすめしたいPatterns.dev」でした。 この記事では、今年発表されたAIモデルである「nvdiffrec」を使って、 iPhone で撮影した動画から3Dモデルを作成する手順 をご紹介します。 今回作成したのは、上記画像の「青い遊具」になります！ はじめに 近年、NeRFをはじめとして リアルの物体や景色を3Dに落とし込む技術 が盛り上がりを見せています。 先日の記事 でもNeRFから3Dのシーンを生成しました。3Dの視点がサクッと生成できるのはすごいですよね。 上記のようなNeRFの結果は、そのまま3Dアプリケーションで使えるものでしょうか？現在、 答えは「No」 です。 NeRFの出力は「輝度場」と呼ばれるものであり、カメラから見える光の反射を推定して出力しています。一方、 Blender をはじめとする3DCG制作エンジンでは、メッシュなどを取り込むのが一般的です。メッシュは形状として落とし込まれたデータになっており、NeRFのように曖昧な箇所をぼかした表現はできません。 そのため、既存の3DCG制作エンジンにNeRFの結果を取り込むには、一工夫が必要になります。 たとえば、先日ご紹介したInstant NGP 1 では、Instant NeRFの出力から古典的な手法を用いてメッシュ化する試験的な機能が備わっています。この機能を使うと、下記のような結果が得られます。 大枠はNeRFの結果と変わりませんが、印象がかなり異なるかと思います。出力されたメッシュの凹凸が激しく、メッシュについている色がfloater（周りに浮いている雲のようなもの）の色になっていたり、元の画像と全く異なる結果となっています。NeRFではうまくぼかせていたものを無理やりメッシュにしたために 見た目の印象がかなり変わってしまいます 。 そこで今回は、3Dメッシュを直接生成するAIモデルを検証することにしました。 nvdiffrecとは？ nvdiffrec 2 は、 3Dメッシュを直接生成するAIモデル です。 NeRF同様、 nvidia が開発したAIモデルであり、画像処理のトップカンファレンスであるCVPR2022にも採択されています。 nvdiffrecでは上記の課題に対し、3DCG制作エンジンに直接取り込めるアウトプットを直接学習します。このとき、形状・素材・照明環境をそれぞれ最適化することによって、画像の見え方から「対象の素材や画像内の照明環境」を推定できます。下記はnvdiffrecの公式の紹介動画になります。 結果として、上記動画内のように元の形状や色に近い3Dメッシュが出力されます。 自分で撮影した動画でnvdiffrecを動かす方法 本記事では、 nvdiffrecのリポジトリ を用いて、 自分で撮影した動画から3Dメッシュを作成する手順 をご紹介します。 なお、本記事で使用するコードは こちら に配置しています。 基本的にはポチポチ「Shift+Enter」を押すだけで動くようになっております のでご活用ください。 0. 事前準備 Instant NGP の実行環境（別環境） Google drive の準備 実行コード のダウンロードと Google drive への配置 ※撮影機材はiPhone11、縦動画撮影での動作を確認済みです。 1. 動画を撮影 （可能であれば）360度から対象物を撮影しましょう。カメラの位置情報を推定するため、対象物は動かさないほうがよいです。この際、筆者は 物体が見切れないように撮影を行いました 。 撮影の基本的なコツは 以前の記事 を参考にしていただけると幸いです。 ここでは、対象物を2周する形で計20秒間の動画撮影を行っています。筆者はiPhone11で撮影したため、解像度は1920×1080です。リソースの都合上、後段の処理で512pixelまで解像度を落とすため、512pixel以上の解像度であれば問題はありません。 また、必須ではありませんが、撮影後に一度NeRFで出力してみることをおすすめします。NeRFがうまく出力できていない場合、以降のプロセスでの結果が期待できなくなります。 2. Google Drive 上で画像に変換 撮影した動画を Google Drive にアップし、 こちらのコード で画像に変換します。 Google Colaboratory（以下Colabと呼称）上でコードを開くと下記のような画面が現れますので、ファイル名を設定して実行します。 下記のように「＜フォルダ名＞/images/＜切り出した画像名＞」のフォルダ階層になっていれば方法は特に問いません。 3. カメラ情報の推定＆物体のマスク推定（ローカル環境） nvdiffrecを動作させる前に、以下の情報が必要になります。 imagesと同じ階層に「masks」フォルダを配置し、その中に「images」内の画像に対応したマスク画像 imagesと同じ階層にカメラ位置の推定情報（pose_bounds.npy） 今回のコードにはその処理を含めていないため、別の環境で用意することにします。 筆者は、nvdiffrec内の issue を参考に、有志の方が作成されている colmap2poses.py を使用しました（2022年11月時点で公式からカスタムデー タセット への適用手順は示されていません）。Instant NeRFが動作する環境であれば、 rembg を追加でインストールするだけで動作します。 pip install rembg 「images」が入ったフォルダとこの スクリプト をInstant NeRFが動作する環境に配置し、下記のコマンドで動かしました。 python colmap2poses.py --mask "imagesを含むフォルダへのpath" --colmap_path "colmapのpath" 上記の スクリプト では、カメラ位置の推定をcolmapを用いて行うとともに、AIモデル「U 2Net 3 」を用いた物体の切り抜きを行っています。 実行後、下記のようなフォルダ構成になっていればOKです。 ただし、「masks」に格納されているマスク画像はrembgで自動推定されたものですので、影が予測結果に入ってしまったり、予測結果が欠けていたりしています。 そこで、筆者はより精度を高めるために、 アノテーション ツール「 EISeg 4 」を用いて直接マスク画像の作成を行いました。 600枚弱の画像があったため、4時間ほどかけて アノテーション を行いました。手間がかかるため、少しでも良い結果を得たい場合のみおすすめします。 4. nvdiffrecの実行 3.の結果を Google Drive にアップし、 こちらのコード に沿ってColab上でnvdiffrecを学習させます。学習の手順は下記の通りです。 ①：関連ライブラリをインストールする ②：前処理を行う ③：nvdiffrecのパラメータを設定して実行する それぞれについて、簡単に見てみましょう。 4-①：関連ライブラリをインストールする Google drive を同期した後、関連ライブラリをインストールします。 初回のみ、nvdiffrecを Google drive 上にcloneする必要があります。下記はColab上で コード を開いた画面です。cloneしていない場合のみ、「nvdiffrec_install」のチェックが必要になります。 4-②：前処理を行う こちらは コード の下記3つのセルを順番に実行すると完了します。 上図内のコードでは、基本的にcroppingとscalingの2つの処理を行いました。 croppingでは、学習しやすいように正方形の画像をもとの画像から切り出しています。本来であれば、画像をそのままモデルに入れることが望ましいですが、今回は時間の都合上断念しました。さらに、見切れている画像を学習に使わない処理も事前に実施しています。 scalingでは、学習に用いる画像のリサイズを行いました。筆者は512pixelで動作確認しましたが、こちらを大きくするほど高い品質が見込めるため、リソースに余裕のある方は大きくすることを推奨します。なお、scalingのコードはnvdiffrec/data/derd/scale_images.pyとほぼ同様です。 4-③：nvdiffrecのパラメータを設定して実行する 最後に、パラメータを設定して実行してみましょう。colab上ではいくつか GUI で設定できるようにしてありますが、それ以外の設定項目もありますので、適宜nvdiffrecの リポジトリ をご確認ください。 !python train.py --config $config_path 上記のコードを実行すると、nvdiffrecの学習が開始されます。学習が完了すると、nvdiffrec/out下に.obj形式、.mtl形式のメッシュとテクス チャフ ァイルが生成されます。 今回使用したデータでは、下記のような結果が得られました。 光の反射が特殊だった上部については推定がうまくいきませんでしたが、それらしきメッシュは作成することができました ！ 形状と色が改善できており、そのままNeRFでメッシュを出力するよりも良い結果が得られているといえそうです。メッシュの出力は、マシンスペックやデータ量の増加、チューニングの工夫によってさらに改善することが見込めます。 最終的に、作成したメッシュは、 もちろん Blender などで取り込むことができます ！ せっかくの アドベントカレンダー なので、クリスマス仕様にしてみました！ おわりに この記事ではnvdiffrecを用いて、 iPhone で撮影した動画から3Dメッシュを作成する手順についてご紹介しました。 3DCG技術に関するAIの発展は目覚ましく、実用的な3DモデルをAIで手軽に生成する未来は着実に近づいていると感じています。ワクワクするような技術が次々と現れる今日ですが、引き続き楽しんでキャッチアップしていきたいと思います。 最後までお読みいただき、ありがとうございました。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ 執筆： @wakamoto.ryosuke 、レビュー： @yamada.y （ Shodo で執筆されました ） NVIDIA Instant NeRF NGP ↩ Extracting Triangular 3D Models, Materials, and Lighting From Images ↩ U 2 -Net: Going Deeper with Nested U-Structure for Salient Object Detection ↩ EISeg: An Efficient Interactive Segmentation Tool based on PaddlePaddle ↩

テックブログ編集部です。今回は弊社社員が登壇するイベントを紹介します。詳細およびお申込みはリンク先サイトを参照してください。 techplay.jp ご興味あれば、ぜひ登録おねがいします。 基本情報 タイトル： クラウド 時代のエンジニアが知っておくべき、顧客のビジネス課題を解決する クラウド 間のシステム連携/ アーキテクチャ 設計のステップ 日時：2022/12/20（火） 19:00〜20:20 形態：オンライン開催 概要 オンラインでも実店舗と変わらない情報提供を可能にするチャットボット 好みに合った商品を提案するレコメンド機能 迅速かつ正確に対応できるコールセンターシステム などなど、今の時代もっとも重要だと言われている良質な顧客体験の提供を実現するためには SoE (Systems of Engagement)とSoR (Systems of Records)のシステム連携が欠かせません。 今回の勉強会では、複雑化する顧客ニーズへの対応や顧客接点のDX(デジタルトランスフォーメーション)を実現するために、一つのシステムを複数の クラウド サービスを連携させた「マルチ クラウド 」でシステム連携を実現するアプローチを提示します。 複数 クラウド の連携となると、 アーキテクチャ が複雑化してしまう セキュリティの確保が心配になる 運用が複雑になってしまう などのやりづらさやお悩みを抱いている方も多いのではないでしょうか？ 実はそのようなお悩みを解決するポイントは、連携する際の" アーキテクチャ 設計の進め方"にあります。 ISIDでは Salesforce を基軸に、 AWS など他の クラウド やオンプレミスにあるシステムと連携・統合させて 顧客対応や マーケティング のためのシステムを構築しています。 システム連携によって実現する機能のビジネス的な価値 クラウド 間のシステム連携を伴う アーキテクチャ 設計の考え方 設計の具体的なステップ、進め方、設計パターン 実際にプロジェクト遂行する時に陥りがちな落とし穴とその乗り越え方 など、 アーキテクチャ の設計ポイントを実例と ケーススタディ を用いながらお話していきます。 執筆： Ishizawa Kento (@kent) 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

テックブログ編集部です。今回は弊社社員が登壇するイベントを紹介します。詳細およびお申込みはリンク先サイトを参照してください。 techplay.jp ご興味あれば、ぜひ登録おねがいします。 基本情報 タイトル： クラウド 時代のエンジニアが知っておくべき、顧客のビジネス課題を解決する クラウド 間のシステム連携/ アーキテクチャ 設計のステップ 日時：2022/12/20（火） 19:00〜20:20 形態：オンライン開催 概要 オンラインでも実店舗と変わらない情報提供を可能にするチャットボット 好みに合った商品を提案するレコメンド機能 迅速かつ正確に対応できるコールセンターシステム などなど、今の時代もっとも重要だと言われている良質な顧客体験の提供を実現するためには SoE (Systems of Engagement)とSoR (Systems of Records)のシステム連携が欠かせません。 今回の勉強会では、複雑化する顧客ニーズへの対応や顧客接点のDX(デジタルトランスフォーメーション)を実現するために、一つのシステムを複数の クラウド サービスを連携させた「マルチ クラウド 」でシステム連携を実現するアプローチを提示します。 複数 クラウド の連携となると、 アーキテクチャ が複雑化してしまう セキュリティの確保が心配になる 運用が複雑になってしまう などのやりづらさやお悩みを抱いている方も多いのではないでしょうか？ 実はそのようなお悩みを解決するポイントは、連携する際の" アーキテクチャ 設計の進め方"にあります。 ISIDでは Salesforce を基軸に、 AWS など他の クラウド やオンプレミスにあるシステムと連携・統合させて 顧客対応や マーケティング のためのシステムを構築しています。 システム連携によって実現する機能のビジネス的な価値 クラウド 間のシステム連携を伴う アーキテクチャ 設計の考え方 設計の具体的なステップ、進め方、設計パターン 実際にプロジェクト遂行する時に陥りがちな落とし穴とその乗り越え方 など、 アーキテクチャ の設計ポイントを実例と ケーススタディ を用いながらお話していきます。 執筆： Ishizawa Kento (@kent) 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

みなさんこんにちは、X イノベーション 本部ソフトウェアデザインセンターの徳山です。 本記事は 電通国際情報サービス Advent Calendar 2022 12月9日の記事です。 ISID に入社して1 ヶ月ばかりですが、今まで携わってこなかった技術領域に触れる機会が増えそうなため刺激的な日々を送っております。 さて、これまでユーザーに近い領域の開発、いわゆるフロントエンドを中心とした開発に携わり4年目となります。 保守性や再利用性が高いコードをどのようにしたら書くことができるのかを模索する日々ですが、意外とフロントエンドに関しては手頃にまとまっている文献が少ないと感じます。 そこで今回は、ウェブフロントにおけるコード改善に役立ちそうな書籍を見つけたのでそちらをご紹介したいと思います。 Patterns.dev とは 全体を通した大きな特徴 個別のパターンの紹介 デザインパターン レンダリングパターン パフォーマンスパターン loading に関して bundles に関して まとめ 参考文献 Patterns.dev とは https://www.patterns.dev/ Patterns.dev は、Vanilla JavaScript と React で Web アプリケーションを構築するための デザインパターン と コンポーネント パターンを紹介する書籍です。海外の開発者の方々によって制作され、 ePub や PDF を含めた多くのフォーマットにて無料で公開されています。 Google Chrome チームで働くエンジニアの方が携わっていることもあり、 Chrome チームの立場としての見解が紹介されていたり、 Chrome ブラウザを例とした説明が用いられています。 内容は下記の 3 部から構成されており、それぞれ内容がほとんど独立しているため自分の興味のあるトピックから読み始めることができます。 デザインパターン レンダリング パターン パフォーマンスパターン 全体を通した大きな特徴 書籍にありがちな文章とコードのみが記載されているだけでなく、下記 2 点の特徴があります。 CodeSandbox で動作が確認できる アニメーションで視覚的に学ぶことができる 特に 2 点目は本書籍で最も私が良いと感じている点です。 例えば GoF では Provider パターンというものがあります。 Reactの提供している API として Context.Provider で馴染みがある方も多いかと思います。 これは「複数の コンポーネント で共通のデータを利用可能とする」設計手法ですが、設計パターン自体にあまり触れてこなかった方にはいまいち字面だけだとぴんときづらいかもしれません。私もReactに入門した頃は理解し辛かった記憶があります。 その点、Patterns.dev だと下記のようにアニメーションで役割を把握できます。 このように本書は画像とアニメーションを利用した説明が多く、CodeSandboxによる実際の挙動確認も行えることから言語が英語ながらも比較的参考にしやすい書籍となっています。 個別のパターンの紹介 デザインパターン コーディングにおいて起こりがちな アンチパターン に対処するための設計手法をまとめたものです。 有名なものだと先ほどちらっとご紹介した GoF などがあり、多くの方が一度は耳にしたことがあるかと思います。 Patterns.devで紹介されているパターン一覧 Patterns.dev では デザインパターン に関して下記のように述べられています。 Design patterns are a fundamental part of software development, as they provide typical solutions to commonly recurring problems in software design . Rather than providing specific pieces of software, design patterns are merely concepts that can be used to handle recurring themes in an optimized way. これさえ覚えておけばなんでも解決できる 銀の弾丸 の類ではないことに注意が必要ですが、開発に適切に適用していくことでコードの保守性・再利用性を高めることができます。 最近では フレームワーク や機能(Hooksなど)が良い感じに吸収してくれていることもあり直接紹介されている デザインパターン を適用する機会はそこまで多くないかもしれません。 実際に各パターンではクラス コンポーネント でのコードサンプルをまずは示し、その後関数 コンポーネント やhooksでの実装例を紹介し、場合によっては既にあまり利用されていないことが記述されています。 ただ、その仕組みを知っておけば フレームワーク 内部の仕組みや他言語でのパターン理解が容易になる、他の開発者とのコードに関する共通認識を持つことができるなど間接的なメリットとしては大きいと感じます。 レンダリング パターン 「コンテンツをどこでどのように レンダリング するか」ということに焦点を当てた一連のパターンをまとめたものです。 本書ではこのパターンの必要性が下記のように述べられています。 Choosing the correct pattern could lead to faster builds and excellent loading performance at low processing costs. On the other hand, a wrong choice of pattern can kill an app that could have brought to life a great business idea. So you must ensure that every revolutionary idea you have goes into development with the appropriate rendering pattern. つまり、正しい レンダリング パターンを選択することは実現したいものを適切に形にする上で重要だということが述べられています。正しいパターン選択は Core Web Vitals を改善し、 SEO や優れた UX にも繋がっていきます。 上記の画像にも記載の通り、現在多くの レンダリング パターンがあります。 CSR (Client Side Rendering)や SSR (Server Side Rendering)は認識されている方も多いと思いますが、他のパターンも含めて正確な理解となるとなかなかハードルが高いと感じないでしょうか。 私自身も改めて本書のアニメーションで レンダリング の動きを確認し、サンプルコードを書くことでより理解を深めることができました。 パフォーマンスパターン パフォーマンスを一言で言うことは非常に難しいですが、ここでは「ユーザーのアクションに対して、ユーザーが期待するレスポンスを素早く返すこと」だと解釈しております。 パフォーマンスパターンでは、大別して 2 つの項目がタグ付けされて各パターンが紹介されております。 1 つ目は「loading」、2 つ目は「bundles」です。 loading に関して lazy loading やルーティング分割などがこの項目に該当します。 必要なリソースを必要なときに必要な分だけ取得するという点から各パターンが紹介されています。 見えている範囲のソースをimportする bundles に関して 静的・動的 import や Tree Shaking などがこの項目に該当します。 loading の「必要なものを必要な分だけ」に該当するため、どのパターンも個別ではなく loading とセットでタグ付けされて紹介されています。 動的import JavaScript や React に関するパフォーマンス改善 Tips は多くの記事や書籍で紹介されているものの、それがまとめられていたり、理解しやすいものとなるとぐっと少なくなります。 例えば React の公式ドキュメントではパフォーマンス最適化に関する ドキュメント はあるものの、class コンポーネント を前提とした解説で hooks を利用した開発が多い今の時流には参考にし辛かったりします。 とはいえ、中大規模のアプリケーションでは必要となる知識のため、本書のようにしっかりとページを割いてまとめられていることは多くの開発者にとって大変貢献性が高いのではないかと感じます。 まとめ ここまで Patterns.dev でのパターンを紹介してきました。 英語でとっつきにくい印象を抱かれる方もいるかも知れません。 その場合はDeepLを利用したり、あるいは デザインパターンの章を日本語訳にしてくださっている記事 を参照されるのも良いかと思います。 繰り返しとなりますが、ここで紹介されているパターンはどんな場合にでも確実に使える 銀の弾丸 ではありません。 best ではなく better を探る道具と考え、ぜひ普段の開発に役立てていただければと思います。 参考文献 この記事は下記の情報を参考にして執筆しております。 - Patterns.dev 私たちは同じチームで働いてくれる仲間を探しています。 フロントエンドやバックエンドと特定の領域にとらわれず幅広い技術領域に挑戦してみたい方がいらっしゃいましたら、ぜひご応募ください！ ソリューションアーキテクト 執筆： @tokuyama 、レビュー： @yamada.y （ Shodo で執筆されました ）

みなさんこんにちは、X イノベーション 本部ソフトウェアデザインセンターの徳山です。 本記事は 電通国際情報サービス Advent Calendar 2022 12月9日の記事です。 ISID に入社して1 ヶ月ばかりですが、今まで携わってこなかった技術領域に触れる機会が増えそうなため刺激的な日々を送っております。 さて、これまでユーザーに近い領域の開発、いわゆるフロントエンドを中心とした開発に携わり4年目となります。 保守性や再利用性が高いコードをどのようにしたら書くことができるのかを模索する日々ですが、意外とフロントエンドに関しては手頃にまとまっている文献が少ないと感じます。 そこで今回は、ウェブフロントにおけるコード改善に役立ちそうな書籍を見つけたのでそちらをご紹介したいと思います。 Patterns.dev とは 全体を通した大きな特徴 個別のパターンの紹介 デザインパターン レンダリングパターン パフォーマンスパターン loading に関して bundles に関して まとめ 参考文献 Patterns.dev とは https://www.patterns.dev/ Patterns.dev は、Vanilla JavaScript と React で Web アプリケーションを構築するための デザインパターン と コンポーネント パターンを紹介する書籍です。海外の開発者の方々によって制作され、 ePub や PDF を含めた多くのフォーマットにて無料で公開されています。 Google Chrome チームで働くエンジニアの方が携わっていることもあり、 Chrome チームの立場としての見解が紹介されていたり、 Chrome ブラウザを例とした説明が用いられています。 内容は下記の 3 部から構成されており、それぞれ内容がほとんど独立しているため自分の興味のあるトピックから読み始めることができます。 デザインパターン レンダリング パターン パフォーマンスパターン 全体を通した大きな特徴 書籍にありがちな文章とコードのみが記載されているだけでなく、下記 2 点の特徴があります。 CodeSandbox で動作が確認できる アニメーションで視覚的に学ぶことができる 特に 2 点目は本書籍で最も私が良いと感じている点です。 例えば GoF では Provider パターンというものがあります。 Reactの提供している API として Context.Provider で馴染みがある方も多いかと思います。 これは「複数の コンポーネント で共通のデータを利用可能とする」設計手法ですが、設計パターン自体にあまり触れてこなかった方にはいまいち字面だけだとぴんときづらいかもしれません。私もReactに入門した頃は理解し辛かった記憶があります。 その点、Patterns.dev だと下記のようにアニメーションで役割を把握できます。 このように本書は画像とアニメーションを利用した説明が多く、CodeSandboxによる実際の挙動確認も行えることから言語が英語ながらも比較的参考にしやすい書籍となっています。 個別のパターンの紹介 デザインパターン コーディングにおいて起こりがちな アンチパターン に対処するための設計手法をまとめたものです。 有名なものだと先ほどちらっとご紹介した GoF などがあり、多くの方が一度は耳にしたことがあるかと思います。 Patterns.devで紹介されているパターン一覧 Patterns.dev では デザインパターン に関して下記のように述べられています。 Design patterns are a fundamental part of software development, as they provide typical solutions to commonly recurring problems in software design . Rather than providing specific pieces of software, design patterns are merely concepts that can be used to handle recurring themes in an optimized way. これさえ覚えておけばなんでも解決できる 銀の弾丸 の類ではないことに注意が必要ですが、開発に適切に適用していくことでコードの保守性・再利用性を高めることができます。 最近では フレームワーク や機能(Hooksなど)が良い感じに吸収してくれていることもあり直接紹介されている デザインパターン を適用する機会はそこまで多くないかもしれません。 実際に各パターンではクラス コンポーネント でのコードサンプルをまずは示し、その後関数 コンポーネント やhooksでの実装例を紹介し、場合によっては既にあまり利用されていないことが記述されています。 ただ、その仕組みを知っておけば フレームワーク 内部の仕組みや他言語でのパターン理解が容易になる、他の開発者とのコードに関する共通認識を持つことができるなど間接的なメリットとしては大きいと感じます。 レンダリング パターン 「コンテンツをどこでどのように レンダリング するか」ということに焦点を当てた一連のパターンをまとめたものです。 本書ではこのパターンの必要性が下記のように述べられています。 Choosing the correct pattern could lead to faster builds and excellent loading performance at low processing costs. On the other hand, a wrong choice of pattern can kill an app that could have brought to life a great business idea. So you must ensure that every revolutionary idea you have goes into development with the appropriate rendering pattern. つまり、正しい レンダリング パターンを選択することは実現したいものを適切に形にする上で重要だということが述べられています。正しいパターン選択は Core Web Vitals を改善し、 SEO や優れた UX にも繋がっていきます。 上記の画像にも記載の通り、現在多くの レンダリング パターンがあります。 CSR (Client Side Rendering)や SSR (Server Side Rendering)は認識されている方も多いと思いますが、他のパターンも含めて正確な理解となるとなかなかハードルが高いと感じないでしょうか。 私自身も改めて本書のアニメーションで レンダリング の動きを確認し、サンプルコードを書くことでより理解を深めることができました。 パフォーマンスパターン パフォーマンスを一言で言うことは非常に難しいですが、ここでは「ユーザーのアクションに対して、ユーザーが期待するレスポンスを素早く返すこと」だと解釈しております。 パフォーマンスパターンでは、大別して 2 つの項目がタグ付けされて各パターンが紹介されております。 1 つ目は「loading」、2 つ目は「bundles」です。 loading に関して lazy loading やルーティング分割などがこの項目に該当します。 必要なリソースを必要なときに必要な分だけ取得するという点から各パターンが紹介されています。 見えている範囲のソースをimportする bundles に関して 静的・動的 import や Tree Shaking などがこの項目に該当します。 loading の「必要なものを必要な分だけ」に該当するため、どのパターンも個別ではなく loading とセットでタグ付けされて紹介されています。 動的import JavaScript や React に関するパフォーマンス改善 Tips は多くの記事や書籍で紹介されているものの、それがまとめられていたり、理解しやすいものとなるとぐっと少なくなります。 例えば React の公式ドキュメントではパフォーマンス最適化に関する ドキュメント はあるものの、class コンポーネント を前提とした解説で hooks を利用した開発が多い今の時流には参考にし辛かったりします。 とはいえ、中大規模のアプリケーションでは必要となる知識のため、本書のようにしっかりとページを割いてまとめられていることは多くの開発者にとって大変貢献性が高いのではないかと感じます。 まとめ ここまで Patterns.dev でのパターンを紹介してきました。 英語でとっつきにくい印象を抱かれる方もいるかも知れません。 その場合はDeepLを利用したり、あるいは デザインパターンの章を日本語訳にしてくださっている記事 を参照されるのも良いかと思います。 繰り返しとなりますが、ここで紹介されているパターンはどんな場合にでも確実に使える 銀の弾丸 ではありません。 best ではなく better を探る道具と考え、ぜひ普段の開発に役立てていただければと思います。 参考文献 この記事は下記の情報を参考にして執筆しております。 - Patterns.dev 私たちは同じチームで働いてくれる仲間を探しています。 フロントエンドやバックエンドと特定の領域にとらわれず幅広い技術領域に挑戦してみたい方がいらっしゃいましたら、ぜひご応募ください！ ソリューションアーキテクト 執筆： @tokuyama 、レビュー： @yamada.y （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、Stable Diffusion 2.1-AUTOMATIC1111です。 Stable Diffusionも2.1がもう出てしまいました。 AUTOMATIC1111のColab用ノートブック にはまだ Stable Diffusion 2.1 に対応したノートブックが公開されていないので、僕の方で、作っておきました。本家で公開されるまで臨時でお使いください。 AUTOMATIC1111のStable Diffusion 2.1対応ノートブック 追記 本家からもv2.1対応版 がリリースされました。今後は、 こちら をお使いください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 長い呪文は切り捨てられる編 Stable Diffusion 2.1への対応の仕方 仲間募集 Stable Diffusionの全コンテンツ Stable Diffusion 2.1への対応の仕方 AUTOMATIC 1111のStable Diffusion 2.0対応のノートブック を Google Drive にコピーします。 wget の2行を Stable Diffusion 2.1 用に書き換えます。 !wget https://huggingface.co/stabilityai/stable-diffusion-2-1/resolve/main/v2-1_768-ema-pruned.ckpt -O /content/stable-diffusion-webui/models/Stable-diffusion/v2-1_768-ema-pruned.ckpt !wget https://raw.githubusercontent.com/Stability-AI/stablediffusion/main/configs/stable-diffusion/v2-inference-v.yaml -O /content/stable-diffusion-webui/models/Stable-diffusion/v2-1_768-ema-pruned.yaml これだけでOKです。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 2.1-AUTOMATIC1111です。 Stable Diffusionも2.1がもう出てしまいました。 AUTOMATIC1111のColab用ノートブック にはまだ Stable Diffusion 2.1 に対応したノートブックが公開されていないので、僕の方で、作っておきました。本家で公開されるまで臨時でお使いください。 AUTOMATIC1111のStable Diffusion 2.1対応ノートブック 追記 本家からもv2.1対応版 がリリースされました。今後は、 こちら をお使いください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 長い呪文は切り捨てられる編 Stable Diffusion 2.1への対応の仕方 仲間募集 Stable Diffusionの全コンテンツ Stable Diffusion 2.1への対応の仕方 AUTOMATIC 1111のStable Diffusion 2.0対応のノートブック を Google Drive にコピーします。 wget の2行を Stable Diffusion 2.1 用に書き換えます。 !wget https://huggingface.co/stabilityai/stable-diffusion-2-1/resolve/main/v2-1_768-ema-pruned.ckpt -O /content/stable-diffusion-webui/models/Stable-diffusion/v2-1_768-ema-pruned.ckpt !wget https://raw.githubusercontent.com/Stability-AI/stablediffusion/main/configs/stable-diffusion/v2-inference-v.yaml -O /content/stable-diffusion-webui/models/Stable-diffusion/v2-1_768-ema-pruned.yaml これだけでOKです。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 で執筆されました ）

本記事は 電通国際情報サービス Advent Calendar 2022 の8日目の記事です。 執筆者は X イノベーション 本部 AI トランスフォーメーションセンター所属の山田です。 この記事では先日（2022年11月中旬）に安定版がリリースされた Nuxt 3 について紹介します。 なお、執筆時点での私たちのチームでは、本番プロジェクトへの Nuxt 3 の導入には至っていません。 本記事は、あくまで技術調査をしながら簡単なアプリケーションを開発してみた内容をまとめたものになります。 本記事で紹介する ソースコード は以下の リポジトリ で公開しています。 github.com Nuxt 3 について 開発環境 Nuxt 3 のプロジェクト作成と TypeScript の設定 TypeScript の設定 ESLint の設定 簡単なアプリケーションを開発してみる コンポーネントの設計 pages/index.vueの作成 app.vue の削除 API 呼び出しでのデータ取得 動作確認 コンポーネントの作成 CatCard コンポーネントの作成 CatCardList コンポーネントの作成 pages/index.vueから作成したコンポーネントを呼びだす テスト 準備 コンポーネントレベルのテスト Vitest の VSCode プラグインとデバッグ まとめ Nuxt 3 について はじめに、簡単に Nuxt 3 について紹介しておきます。 Nuxt は Vue.js の フレームワーク です。 冒頭でも述べましたが、2022年11月中旬に Nuxt 3 の安定版がついにリリースされました。 Announcing Nuxt 3.0 stable、 https://nuxt.com/v3 Nuxt 3 のリリースで大きいのは Vue 3 の正式なサポートです。 Vue 3 は 2020年9月にリリースされていましたが、Nuxt 2 ではサポートされていませんでした。 Vue 3 から追加された Compositon API などを利用するために、Nuxt 2 のプロジェクトで Nuxt Composition API などのパッケージを利用している人も多かったのではないでしょうか。 今回リリースされた Nuxt 3 は Vue 3 も公式にサポートしていますし、サーバエンジンも Nitro に刷新され、パフォーマンスも向上しています。 開発環境 本記事での利用した開発環境の情報を記載します。 開発環境/ IDE ： GitHub Codespaces リージョン：Southeast Asia スペック：CPU 4コア、メモリ 8 GB Node.js のバージョン管理ツール：nvm Node.js バージョン：v18.12.1 パッケージマネージャー・バージョン：Yarn / 1.22.19 ブラウザ： Google Chrome せっかくなので、 GitHub Codespaces を用いてみました。 Node.js のバージョン管理ソフトには GitHub Codespaces 上でデフォルトでインストールされていた nvm を利用しています。 Node.js のバージョンは LTS の最新バージョンである v18 系を、パッケージマネージャーには Yarn を使っています。 VSCode の 拡張機能 は以下のものを利用します。 Volar Vue Language Features TypeScript Vue Plugin ESLint Chrome の 拡張機能 は以下のものを利用します。 Vue.js devtools Nuxt 3 のプロジェクト作成と TypeScript の設定 Nuxt 3のプロジェクト作成は npx nuxi init コマンドで行います。 npx nuxi init ${ プロジェクト名 } プロジェクト作成段階でできる ディレクト リ構成は以下のようになります。 プロジェクト名 ├── README.md ├── app.vue ├── nuxt.config.ts ├── package.json └── tsconfig.json TypeScript の設定 Nuxt はデフォルトだと TypeScript の厳格な型チェックが有効になっていないので有効にしましょう。 まずは TypeScript と vue- tsc を devDependency に追加します。 yarn add -D typescript vue-tsc 次に nuxt.config.ts を以下のように編集します。 // https://nuxt.com/docs/api/configuration/nuxt-config export default defineNuxtConfig ( { typescript: { shim: false , strict: true , typeCheck: true } , } ); shim: false としているのは、 VSCode で TypeScript Vue Plugin (Volar) を利用するためです。 strict: true にすることで、型チェックが厳格になります。 typeCheck: true としているのは、開発時から型チェックを有効にするためです。Nuxt ではビルドパフォーマンスを最適化するためにデフォルトでは型チェックが行われません。 このあたりの詳細については以下の公式ドキュメントを参照してください。 Nuxt - Installation、 https://nuxt.com/docs/getting-started/installation Nuxt - type-checking、 https://nuxt.com/docs/guide/concepts/typescript また Nuxt 3 からは CLI での型チェックが実行できます。 yarn nuxi typecheck もしも開発中のホットリロード時にビルドパフォーマンスを求めるならば、 typeCheck: false として CLI での手動でのチェックという選択肢もあります。 以下のように npm スクリプト に typecheck コマンドを登録しておいてもいいかもしれません。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck " } } ESLint の設定 次に ESLint の設定をしましょう。 Nuxt では VSCode で開発する際には ESLint プラグイン を利用することが推奨されています。 注意点として Prettier は無効にすることが勧められています。 Nuxt - use-eslint、 https://nuxt.com/docs/community/contribution#use-eslint ということで、まずは ESLint を devDependency に追加します。 yarn add -D @nuxtjs/eslint-config eslint そして ESLint の設定ファイル .eslintrc を作成します。 touch .eslintrc .eslintrc は以下のように記述します。 { " extends ": [ " @nuxtjs/eslint-config-typescript " ] } すでに Prettier を導入している開発者に配慮して、Prettier によるフォーマットがかからないようにしましょう。 .prettierignore を用意し、プロジェクト内のすべてのファイルをフォーマット対象外にしてしまいましょう。 以下が .prettierignore の記述内容になります。 # プロジェクト内のすべてのファイルをPrettierの対象外にする ** .vscode/settings.json を設定し、保存時に ESLint によるフォーマットがかかるようにしましょう。 { " editor.codeActionsOnSave ": { " source.fixAll ": false , " source.fixAll.eslint ": true } } 最後に npm スクリプト に lint コマンドを登録しておきましょう。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck ", " lint ": " eslint --ext .ts,.js,.vue . " , }, } これにより以下のコマンドで ESLint によるコードの静的解析、フォーマットを実施できます。 # 静的解析 yarn lint # フォーマット yarn lint --fix 簡単なアプリケーションを開発してみる 環境が整ったので、ここからは簡単なアプリケーションを開発しながら Nuxt 3 について触れていきましょう。 今回は The Cat API を利用した、猫を愛でることができるアプリケーションを作ります。 The Cat API - Cats as a Service. https://thecatapi.com/ The Cat API では API キーがなくても、10枚まではランダムに猫の画像が取得できます。 完成形のイメージとしては、取得した猫画像をグリッド形式で表示するアプリケーションとします。 コンポーネント の設計 はじめに コンポーネント を設計しましょう。 Vue.js は コンポーネント 指向な フレームワーク ですので、画面デザインから コンポーネント を設計しておくのが大事です。 画像出典： コンポーネント の基本 - コンポーネント の構成、 https://v3.ja.vuejs.org/guide/component-basics.html 今回は手始めに以下のような コンポーネント 構成を考えましょう。 index.vue … ページ コンポーネント 。 API 呼び出しはここで行う。 CatCardList.vue … 猫画像のリストを表示する コンポーネント CatCard.vue … 正方形の猫画像1枚を表示する コンポーネント ツリー形式で可視化すると以下のようになります。 pages/index.vue の作成 はじめに pages コンポーネント の index.vue の追加しましょう。 Nuxt 3 では nuxi add コマンドで簡単に pages コンポーネント を追加できます。 npx nuxi add page index 作成時点では以下のような形になっています。 <script lang="ts" setup></script> <template> <div> Page: foo </div> </template> <style scoped></style> Nuxt 2 までの単一ファイル コンポーネント 内では、 template script style という順番で記述されるのが一般的でしたが、Nuxt 3では script template style の順で記述するのが一般的なようです。 また script 部分は <script setup> 構文での記述がベースとなっています。 <script setup> 構文の詳細については Vue.js 3 の公式ドキュメントを参照してください。 Vue.js - SFC <script setup> 、 https://v3.ja.vuejs.org/api/sfc-script-setup.html app.vue の削除 Nuxt では pages 配下の Vue ファイルでアプリケーションのルーティングが生成されます。 そのため、プロジェクト作成時点でのエントリポイントである app.vue は pages コンポーネント を作成後は不要になるため削除します。 rm app.vue API 呼び出しでのデータ取得 pages/index.vue で The Cat API を呼び出して、データを取得する処理を記述します。 外部 API 呼び出しには Nuxt 組込みの useFetch を利用します。 useFetch、 https://nuxt.com/docs/api/composables/use-fetch 呼び出し前に取得するデータの型を定義しておきましょう。 今回、利用する The Cat API のレスポンスは以下のようになっています。 [ { " id ": " 5ni ", " url ": " https://cdn2.thecatapi.com/images/5ni.jpg ", " width ": 500 , " height ": 375 } ] https://api.thecatapi.com/v1/images/search この情報をもとに型情報を定義しましょう。 型定義は types ディレクト リ配下に記述することにします。 # typesディレクトリの作成 mkdir types touch types/index.ts interface でレスポンスの型を定義します。 export interface CatResponse { id: string ; url: string ; width: number ; height: number ; } そして定義した型情報をインポートしつつ、 useFetch での API 呼び出しのコードを記述します。 <script lang="ts" setup> import { CatResponse } from '~/types' const { pending, error, data } = useFetch<CatResponse[]>( 'https://api.thecatapi.com/v1/images/search?limit=10' ) </script> <template> <div> Page: foo </div> </template> <style scoped></style> useFetch を利用する際に、インポート文を書いていないことに違和感がある方もいるのではないでしょうか？ Nuxt 3 では、Auto Imports 機能があり、Vue.js標準の ref や computed Nuxt 組込みの useFetch などの関数を明示的にインポートすることなく記述できます。 Nuxt - auto-imports、 https://nuxt.com/docs/guide/concepts/auto-imports 動作確認 ここまででアプリケーションを起動し、 Chrome の Vue.js devtoolsを確認しましょう。 # 開発サーバでアプリケーションを起動 yarn dev Chrome の Vue.js devtoolsを確認すると、きちんとデータ取得できていることがわかります。 コンポーネント の作成 続いて コンポーネント を作成していきましょう。 コンポーネント も nuxi add コマンドで簡単に追加できます。 # CatCardListコンポーネントの作成 npx nuxi add component CatCardList # CatCardコンポーネントの作成 npx nuxi add component CatCard CatCard コンポーネント の作成 まずはより小さい階層の CatCard コンポーネント を作成します。 CatCard コンポーネント では、 props を介して1つの CatResponse オブジェクトを受け取ります。 そして画像のURLを <img> タグの src に渡します。 以下が CatCard コンポーネント のコードになります。 <script lang="ts" setup> import { CatResponse } from '~/types' interface Props { catData: CatResponse; } defineProps<Props>() </script> <template> <div> <img class="card-img" :src="catData.url" alt="cute cat" :data-testid="catData.id" > </div> </template> <style scoped> .card-img { border-radius: 8px; width: 320px; height: 320px; object-fit: cover; } </style> CatCardList コンポーネント の作成 次に CatCardList コンポーネント を作成します。 CatCardList コンポーネント では、 props を介して CatResponse オブジェクトの配列受け取ります。 そして v-for 構文で配列を展開し、 CatCard コンポーネント を複数描画します。 以下が CatCardList コンポーネント のコードになります。 <script lang="ts" setup> import { CatResponse } from '~/types' interface Props { catList: CatResponse[]; } defineProps<Props>() </script> <template> <div class="card-list" data-testid="cat-list"> <cat-card v-for="(cat, i) in catList" :key="i" :cat-data="cat" /> </div> </template> <style scoped> .card-list { display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 16px; } </style> pages/index.vue から作成した コンポーネント を呼びだす 作成した CatCardList コンポーネント を index.vue から呼び出します。 コンポーネント についても Nuxt 側での Auto Imports が有効になっているため、明示的にインポートする必要はありません。 <script lang="ts" setup> import { CatResponse } from '~/types' const { pending, error, data } = useFetch<CatResponse[]>( 'https://api.thecatapi.com/v1/images/search?limit=10' ) </script> <template> <div v-if="!pending && data" class="content"> <cat-card-list :cat-list="data" /> </div> </template> <style scoped> .content { margin: auto; } </style> CatCardList は data の値をプロパティにわたす必要があるため v-if で条件付き レンダリング にします。 あとは、少しレイアウトを整えれば以下のようなアプリケーションが完成します。 isid.github.io テスト 最後にテストについても触れましょう。 Vue.js 3 系からはテストツールとして Vitest が推奨されています。 Vue.js - テスト #推奨事項、 https://ja.vuejs.org/guide/scaling-up/testing.html#recommendation Nuxt 3 の公式ドキュメントではテスト用ツールに @nuxt/test-utils-edge が紹介されていますが、こちらは開発中で不安定です。 なので今回は コンポーネント レベルのテストだけを実施する Vue Testing Library（@testing-library/vue） を用いる方法を紹介します。 なお Vue.js のテストツールとしては、 Vue Test Utils もありますが、 コンポーネント レベルのテストでは @testing-library/vue の利用が推奨されています。 Vue.js - テスト コンポーネント のテスト#推奨事項、 https://ja.vuejs.org/guide/scaling-up/testing.html#recommendation-1 準備 まずは必要なパッケージをインストールします。 テスト時に コンポーネント を描画するDOM環境には happy-dom を使用します。 yarn add -D vitest @testing-library/vue happy-dom Vitest の設定ファイル vitest.config.ts を作成します。 /// <reference types="vitest" /> import { defineConfig } from 'vitest/config' import Vue from '@vitejs/plugin-vue' export default defineConfig ( { plugins: [ Vue () ] , resolve: { alias: { '~' : ` ${__dirname} ` } } , test: { root: '.' , globals: true , environment: 'happy-dom' } } ) npm スクリプト に test コマンドを追加します。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck ", " lint ": " eslint --ext .ts,.js,.vue . ", " test ": " vitest " , }, } コンポーネント レベルのテスト CatCard コンポーネント のテストを記述しましょう。 CatResponse 形式のオブジェクトを props に渡した際に、 コンポーネント が描画できるかテストします。 テストコードは tests ディレクト リ配下に *.spec.ts の形で配置します。 @testing-library/vue でのテストコードは以下のようなります。 コンポーネント が描画できているかの判断には data-testid 属性を使っています。 import { describe , expect , test } from 'vitest' import { render } from '@testing-library/vue' import CatCard from '~/components/CatCard.vue' import { CatResponse } from '~/types' describe ( 'CatCard' , () => { test ( 'コンポーネントの描画ができること' , () => { const catData: CatResponse = { id: 'test' , url: 'https://example.com' , width: 100 , height: 100 } const { getAllByTestId , html } = render ( CatCard , { props: { catData } } ) const results = getAllByTestId ( catData.id ) expect ( results.length ) .toBe ( 1 ) expect ( html ()) .contain ( `data-testid=" ${ catData.id } "` ) } ) } ) テストを実行してみましょう。 yarn test きちんとテストが通れば、以下の出力が得られます。 RERUN tests/components/CatCard.spec.ts x20 ✓ tests/components/CatCard.spec.ts (1) Test Files 1 passed (1) Tests 1 passed (1) Start at 09:40:00 Duration 230ms PASS Waiting for file changes... press h to show help, press q to quit Vitest の VSCode プラグイン と デバッグ テストコードを書くことによって、小さい範囲でコードを動かせるようになりました。 さらに デバッグ もできると開発がより捗ります。 Vitest では公式で VSCode の プラグイン をリリースしており、こちらを活用することでテストコードをもとにデバッガーを起動できます。 Vitest、 https://marketplace.visualstudio.com/items?itemName=ZixuanChen.vitest-explorer VItes - IDE Integrations 、 https://vitest.dev/guide/ide.html テストコードに ブレークポイント を仕込んで、テストタブから「テストの デバッグ 」を選択するとデバッガーが起動できます。 これで開発環境はバッチリですね。 まとめ 本記事では、Nuxt 3 について紹介しました。 今回、記事を書きながら 、これまでの Nuxt の良さを引き継ぎながら正当に進化していると感じました。 nuxi コマンドの充実や TypeScript、 VSCode との親和性の向上、Nitroによるビルド速度の向上など開発がより楽しくなる可能性を感じました。 一方でテストの部分はまだ不安定だと言わざるを得ません。 Nuxt 側の Auto Imports 機能と Vitest の連携がうまくいかなかったり @nuxt/test-utils-edge モジュールが開発中であるため Nuxt 3 のアプリケーションをテストする方法が確立していません。 support for unit testing in a nuxt environment #2465、 https://github.com/nuxt/framework/issues/2465 Nuxt - Testing、 https://nuxt.com/docs/getting-started/testing#testing 直近で Nuxt 3 の導入を検討しているならば、この部分には注意をする必要があります。 最後に、私たちAIトランスフォーメーションセンターでは、一緒に働いてくれる仲間を探しています。 AI 製品開発に興味がある方のご応募をお待ちしております。 AIエンジニア（プロダクト開発） AIプロダクトマネージャー AIコンサルタント AIビジネスプロジェクトマネージャー 執筆： @yamada.y 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

本記事は 電通国際情報サービス Advent Calendar 2022 の8日目の記事です。 執筆者は X イノベーション 本部 AI トランスフォーメーションセンター所属の山田です。 この記事では先日（2022年11月中旬）に安定版がリリースされた Nuxt 3 について紹介します。 なお、執筆時点での私たちのチームでは、本番プロジェクトへの Nuxt 3 の導入には至っていません。 本記事は、あくまで技術調査をしながら簡単なアプリケーションを開発してみた内容をまとめたものになります。 本記事で紹介する ソースコード は以下の リポジトリ で公開しています。 github.com Nuxt 3 について 開発環境 Nuxt 3 のプロジェクト作成と TypeScript の設定 TypeScript の設定 ESLint の設定 簡単なアプリケーションを開発してみる コンポーネントの設計 pages/index.vueの作成 app.vue の削除 API 呼び出しでのデータ取得 動作確認 コンポーネントの作成 CatCard コンポーネントの作成 CatCardList コンポーネントの作成 pages/index.vueから作成したコンポーネントを呼びだす テスト 準備 コンポーネントレベルのテスト Vitest の VSCode プラグインとデバッグ まとめ Nuxt 3 について はじめに、簡単に Nuxt 3 について紹介しておきます。 Nuxt は Vue.js の フレームワーク です。 冒頭でも述べましたが、2022年11月中旬に Nuxt 3 の安定版がついにリリースされました。 Announcing Nuxt 3.0 stable、 https://nuxt.com/v3 Nuxt 3 のリリースで大きいのは Vue 3 の正式なサポートです。 Vue 3 は 2020年9月にリリースされていましたが、Nuxt 2 ではサポートされていませんでした。 Vue 3 から追加された Compositon API などを利用するために、Nuxt 2 のプロジェクトで Nuxt Composition API などのパッケージを利用している人も多かったのではないでしょうか。 今回リリースされた Nuxt 3 は Vue 3 も公式にサポートしていますし、サーバエンジンも Nitro に刷新され、パフォーマンスも向上しています。 開発環境 本記事での利用した開発環境の情報を記載します。 開発環境/ IDE ： GitHub Codespaces リージョン：Southeast Asia スペック：CPU 4コア、メモリ 8 GB Node.js のバージョン管理ツール：nvm Node.js バージョン：v18.12.1 パッケージマネージャー・バージョン：Yarn / 1.22.19 ブラウザ： Google Chrome せっかくなので、 GitHub Codespaces を用いてみました。 Node.js のバージョン管理ソフトには GitHub Codespaces 上でデフォルトでインストールされていた nvm を利用しています。 Node.js のバージョンは LTS の最新バージョンである v18 系を、パッケージマネージャーには Yarn を使っています。 VSCode の 拡張機能 は以下のものを利用します。 Volar Vue Language Features TypeScript Vue Plugin ESLint Chrome の 拡張機能 は以下のものを利用します。 Vue.js devtools Nuxt 3 のプロジェクト作成と TypeScript の設定 Nuxt 3のプロジェクト作成は npx nuxi init コマンドで行います。 npx nuxi init ${ プロジェクト名 } プロジェクト作成段階でできる ディレクト リ構成は以下のようになります。 プロジェクト名 ├── README.md ├── app.vue ├── nuxt.config.ts ├── package.json └── tsconfig.json TypeScript の設定 Nuxt はデフォルトだと TypeScript の厳格な型チェックが有効になっていないので有効にしましょう。 まずは TypeScript と vue- tsc を devDependency に追加します。 yarn add -D typescript vue-tsc 次に nuxt.config.ts を以下のように編集します。 // https://nuxt.com/docs/api/configuration/nuxt-config export default defineNuxtConfig ( { typescript: { shim: false , strict: true , typeCheck: true } , } ); shim: false としているのは、 VSCode で TypeScript Vue Plugin (Volar) を利用するためです。 strict: true にすることで、型チェックが厳格になります。 typeCheck: true としているのは、開発時から型チェックを有効にするためです。Nuxt ではビルドパフォーマンスを最適化するためにデフォルトでは型チェックが行われません。 このあたりの詳細については以下の公式ドキュメントを参照してください。 Nuxt - Installation、 https://nuxt.com/docs/getting-started/installation Nuxt - type-checking、 https://nuxt.com/docs/guide/concepts/typescript また Nuxt 3 からは CLI での型チェックが実行できます。 yarn nuxi typecheck もしも開発中のホットリロード時にビルドパフォーマンスを求めるならば、 typeCheck: false として CLI での手動でのチェックという選択肢もあります。 以下のように npm スクリプト に typecheck コマンドを登録しておいてもいいかもしれません。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck " } } ESLint の設定 次に ESLint の設定をしましょう。 Nuxt では VSCode で開発する際には ESLint プラグイン を利用することが推奨されています。 注意点として Prettier は無効にすることが勧められています。 Nuxt - use-eslint、 https://nuxt.com/docs/community/contribution#use-eslint ということで、まずは ESLint を devDependency に追加します。 yarn add -D @nuxtjs/eslint-config eslint そして ESLint の設定ファイル .eslintrc を作成します。 touch .eslintrc .eslintrc は以下のように記述します。 { " extends ": [ " @nuxtjs/eslint-config-typescript " ] } すでに Prettier を導入している開発者に配慮して、Prettier によるフォーマットがかからないようにしましょう。 .prettierignore を用意し、プロジェクト内のすべてのファイルをフォーマット対象外にしてしまいましょう。 以下が .prettierignore の記述内容になります。 # プロジェクト内のすべてのファイルをPrettierの対象外にする ** .vscode/settings.json を設定し、保存時に ESLint によるフォーマットがかかるようにしましょう。 { " editor.codeActionsOnSave ": { " source.fixAll ": false , " source.fixAll.eslint ": true } } 最後に npm スクリプト に lint コマンドを登録しておきましょう。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck ", " lint ": " eslint --ext .ts,.js,.vue . " , }, } これにより以下のコマンドで ESLint によるコードの静的解析、フォーマットを実施できます。 # 静的解析 yarn lint # フォーマット yarn lint --fix 簡単なアプリケーションを開発してみる 環境が整ったので、ここからは簡単なアプリケーションを開発しながら Nuxt 3 について触れていきましょう。 今回は The Cat API を利用した、猫を愛でることができるアプリケーションを作ります。 The Cat API - Cats as a Service. https://thecatapi.com/ The Cat API では API キーがなくても、10枚まではランダムに猫の画像が取得できます。 完成形のイメージとしては、取得した猫画像をグリッド形式で表示するアプリケーションとします。 コンポーネント の設計 はじめに コンポーネント を設計しましょう。 Vue.js は コンポーネント 指向な フレームワーク ですので、画面デザインから コンポーネント を設計しておくのが大事です。 画像出典： コンポーネント の基本 - コンポーネント の構成、 https://v3.ja.vuejs.org/guide/component-basics.html 今回は手始めに以下のような コンポーネント 構成を考えましょう。 index.vue … ページ コンポーネント 。 API 呼び出しはここで行う。 CatCardList.vue … 猫画像のリストを表示する コンポーネント CatCard.vue … 正方形の猫画像1枚を表示する コンポーネント ツリー形式で可視化すると以下のようになります。 pages/index.vue の作成 はじめに pages コンポーネント の index.vue の追加しましょう。 Nuxt 3 では nuxi add コマンドで簡単に pages コンポーネント を追加できます。 npx nuxi add page index 作成時点では以下のような形になっています。 <script lang="ts" setup></script> <template> <div> Page: foo </div> </template> <style scoped></style> Nuxt 2 までの単一ファイル コンポーネント 内では、 template script style という順番で記述されるのが一般的でしたが、Nuxt 3では script template style の順で記述するのが一般的なようです。 また script 部分は <script setup> 構文での記述がベースとなっています。 <script setup> 構文の詳細については Vue.js 3 の公式ドキュメントを参照してください。 Vue.js - SFC <script setup> 、 https://v3.ja.vuejs.org/api/sfc-script-setup.html app.vue の削除 Nuxt では pages 配下の Vue ファイルでアプリケーションのルーティングが生成されます。 そのため、プロジェクト作成時点でのエントリポイントである app.vue は pages コンポーネント を作成後は不要になるため削除します。 rm app.vue API 呼び出しでのデータ取得 pages/index.vue で The Cat API を呼び出して、データを取得する処理を記述します。 外部 API 呼び出しには Nuxt 組込みの useFetch を利用します。 useFetch、 https://nuxt.com/docs/api/composables/use-fetch 呼び出し前に取得するデータの型を定義しておきましょう。 今回、利用する The Cat API のレスポンスは以下のようになっています。 [ { " id ": " 5ni ", " url ": " https://cdn2.thecatapi.com/images/5ni.jpg ", " width ": 500 , " height ": 375 } ] https://api.thecatapi.com/v1/images/search この情報をもとに型情報を定義しましょう。 型定義は types ディレクト リ配下に記述することにします。 # typesディレクトリの作成 mkdir types touch types/index.ts interface でレスポンスの型を定義します。 export interface CatResponse { id: string ; url: string ; width: number ; height: number ; } そして定義した型情報をインポートしつつ、 useFetch での API 呼び出しのコードを記述します。 <script lang="ts" setup> import { CatResponse } from '~/types' const { pending, error, data } = useFetch<CatResponse[]>( 'https://api.thecatapi.com/v1/images/search?limit=10' ) </script> <template> <div> Page: foo </div> </template> <style scoped></style> useFetch を利用する際に、インポート文を書いていないことに違和感がある方もいるのではないでしょうか？ Nuxt 3 では、Auto Imports 機能があり、Vue.js標準の ref や computed Nuxt 組込みの useFetch などの関数を明示的にインポートすることなく記述できます。 Nuxt - auto-imports、 https://nuxt.com/docs/guide/concepts/auto-imports 動作確認 ここまででアプリケーションを起動し、 Chrome の Vue.js devtoolsを確認しましょう。 # 開発サーバでアプリケーションを起動 yarn dev Chrome の Vue.js devtoolsを確認すると、きちんとデータ取得できていることがわかります。 コンポーネント の作成 続いて コンポーネント を作成していきましょう。 コンポーネント も nuxi add コマンドで簡単に追加できます。 # CatCardListコンポーネントの作成 npx nuxi add component CatCardList # CatCardコンポーネントの作成 npx nuxi add component CatCard CatCard コンポーネント の作成 まずはより小さい階層の CatCard コンポーネント を作成します。 CatCard コンポーネント では、 props を介して1つの CatResponse オブジェクトを受け取ります。 そして画像のURLを <img> タグの src に渡します。 以下が CatCard コンポーネント のコードになります。 <script lang="ts" setup> import { CatResponse } from '~/types' interface Props { catData: CatResponse; } defineProps<Props>() </script> <template> <div> <img class="card-img" :src="catData.url" alt="cute cat" :data-testid="catData.id" > </div> </template> <style scoped> .card-img { border-radius: 8px; width: 320px; height: 320px; object-fit: cover; } </style> CatCardList コンポーネント の作成 次に CatCardList コンポーネント を作成します。 CatCardList コンポーネント では、 props を介して CatResponse オブジェクトの配列受け取ります。 そして v-for 構文で配列を展開し、 CatCard コンポーネント を複数描画します。 以下が CatCardList コンポーネント のコードになります。 <script lang="ts" setup> import { CatResponse } from '~/types' interface Props { catList: CatResponse[]; } defineProps<Props>() </script> <template> <div class="card-list" data-testid="cat-list"> <cat-card v-for="(cat, i) in catList" :key="i" :cat-data="cat" /> </div> </template> <style scoped> .card-list { display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 16px; } </style> pages/index.vue から作成した コンポーネント を呼びだす 作成した CatCardList コンポーネント を index.vue から呼び出します。 コンポーネント についても Nuxt 側での Auto Imports が有効になっているため、明示的にインポートする必要はありません。 <script lang="ts" setup> import { CatResponse } from '~/types' const { pending, error, data } = useFetch<CatResponse[]>( 'https://api.thecatapi.com/v1/images/search?limit=10' ) </script> <template> <div v-if="!pending && data" class="content"> <cat-card-list :cat-list="data" /> </div> </template> <style scoped> .content { margin: auto; } </style> CatCardList は data の値をプロパティにわたす必要があるため v-if で条件付き レンダリング にします。 あとは、少しレイアウトを整えれば以下のようなアプリケーションが完成します。 isid.github.io テスト 最後にテストについても触れましょう。 Vue.js 3 系からはテストツールとして Vitest が推奨されています。 Vue.js - テスト #推奨事項、 https://ja.vuejs.org/guide/scaling-up/testing.html#recommendation Nuxt 3 の公式ドキュメントではテスト用ツールに @nuxt/test-utils-edge が紹介されていますが、こちらは開発中で不安定です。 なので今回は コンポーネント レベルのテストだけを実施する Vue Testing Library（@testing-library/vue） を用いる方法を紹介します。 なお Vue.js のテストツールとしては、 Vue Test Utils もありますが、 コンポーネント レベルのテストでは @testing-library/vue の利用が推奨されています。 Vue.js - テスト コンポーネント のテスト#推奨事項、 https://ja.vuejs.org/guide/scaling-up/testing.html#recommendation-1 準備 まずは必要なパッケージをインストールします。 テスト時に コンポーネント を描画するDOM環境には happy-dom を使用します。 yarn add -D vitest @testing-library/vue happy-dom Vitest の設定ファイル vitest.config.ts を作成します。 /// <reference types="vitest" /> import { defineConfig } from 'vitest/config' import Vue from '@vitejs/plugin-vue' export default defineConfig ( { plugins: [ Vue () ] , resolve: { alias: { '~' : ` ${__dirname} ` } } , test: { root: '.' , globals: true , environment: 'happy-dom' } } ) npm スクリプト に test コマンドを追加します。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck ", " lint ": " eslint --ext .ts,.js,.vue . ", " test ": " vitest " , }, } コンポーネント レベルのテスト CatCard コンポーネント のテストを記述しましょう。 CatResponse 形式のオブジェクトを props に渡した際に、 コンポーネント が描画できるかテストします。 テストコードは tests ディレクト リ配下に *.spec.ts の形で配置します。 @testing-library/vue でのテストコードは以下のようなります。 コンポーネント が描画できているかの判断には data-testid 属性を使っています。 import { describe , expect , test } from 'vitest' import { render } from '@testing-library/vue' import CatCard from '~/components/CatCard.vue' import { CatResponse } from '~/types' describe ( 'CatCard' , () => { test ( 'コンポーネントの描画ができること' , () => { const catData: CatResponse = { id: 'test' , url: 'https://example.com' , width: 100 , height: 100 } const { getAllByTestId , html } = render ( CatCard , { props: { catData } } ) const results = getAllByTestId ( catData.id ) expect ( results.length ) .toBe ( 1 ) expect ( html ()) .contain ( `data-testid=" ${ catData.id } "` ) } ) } ) テストを実行してみましょう。 yarn test きちんとテストが通れば、以下の出力が得られます。 RERUN tests/components/CatCard.spec.ts x20 ✓ tests/components/CatCard.spec.ts (1) Test Files 1 passed (1) Tests 1 passed (1) Start at 09:40:00 Duration 230ms PASS Waiting for file changes... press h to show help, press q to quit Vitest の VSCode プラグイン と デバッグ テストコードを書くことによって、小さい範囲でコードを動かせるようになりました。 さらに デバッグ もできると開発がより捗ります。 Vitest では公式で VSCode の プラグイン をリリースしており、こちらを活用することでテストコードをもとにデバッガーを起動できます。 Vitest、 https://marketplace.visualstudio.com/items?itemName=ZixuanChen.vitest-explorer VItes - IDE Integrations 、 https://vitest.dev/guide/ide.html テストコードに ブレークポイント を仕込んで、テストタブから「テストの デバッグ 」を選択するとデバッガーが起動できます。 これで開発環境はバッチリですね。 まとめ 本記事では、Nuxt 3 について紹介しました。 今回、記事を書きながら 、これまでの Nuxt の良さを引き継ぎながら正当に進化していると感じました。 nuxi コマンドの充実や TypeScript、 VSCode との親和性の向上、Nitroによるビルド速度の向上など開発がより楽しくなる可能性を感じました。 一方でテストの部分はまだ不安定だと言わざるを得ません。 Nuxt 側の Auto Imports 機能と Vitest の連携がうまくいかなかったり @nuxt/test-utils-edge モジュールが開発中であるため Nuxt 3 のアプリケーションをテストする方法が確立していません。 support for unit testing in a nuxt environment #2465、 https://github.com/nuxt/framework/issues/2465 Nuxt - Testing、 https://nuxt.com/docs/getting-started/testing#testing 直近で Nuxt 3 の導入を検討しているならば、この部分には注意をする必要があります。 最後に、私たちAIトランスフォーメーションセンターでは、一緒に働いてくれる仲間を探しています。 AI 製品開発に興味がある方のご応募をお待ちしております。 AIエンジニア（プロダクト開発） AIプロダクトマネージャー AIコンサルタント AIビジネスプロジェクトマネージャー 執筆： @yamada.y 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

みなさんこんにちは！ 電通国際情報サービス （ISID）クロス イノベーション 本部 AIトランスフォーメーションセンター（AITC） インドネシア 出身のファイサル ハディプトラと申します。この記事は 電通国際情報サービス Advent Calendar 2022 の12月7日の記事です。 先日、TECHPLAYで「AI搭載検索システム」について登壇いたしました。 Techplayイベントページ 今回は、AI搭載検索システムに関連する「ナレッジグラフを搭載した検索システム」について紹介します。 AI搭載検索システム 検索といえば、皆さんはきっと Google 検索をイメージしています。最近の Google 検索は、昔とは違ってAI技術を活用することで、ただのキーワード検索を超えた特徴を持っています。 Google 検索に慣れているほとんどのユーザーは検索システムを使用するときに、以下のようなことを期待します。 ドメイン 理解（Domain-aware） ：ユーザーのクエリ内のキーワードに該当する概念を認識して自動的にその概念のカテゴリや属性などをクエリに付加する。例えば：「ISID」というクエリを打ったときに、「会社」のカテゴリ、「 電通 国際情報」の別名、と「品川」の本社所在地などの情報をクエリに付加する。 文脈とユーザーの理解（Contextual and Personalized） ：ユーザーの好み・プロフィールを考慮してクエリと検索結果の関連度を調整する。例えば：エンジニアが「 Python 」というクエリを打ったときに、蛇の Python ではなく、 プログラミング言語 の Python を記載する記事を返す。 対話型（Conversational） ： 自然言語 を理解し、前に検索したものを考慮する。例えば：「コロナ」と検索した後、次に「mrna」と検索すると、モデルなのワクチン情報が出てくる。 マルチモーダル（Multi-modal） ：テキストに限らず、音声、画像、映像などに対応する。 知能的（Intelligent） ：データが溜まっていけばいくほど自己改善する。例えば：誤字自動訂正や自動補完機能がだんだん賢くなる。 支援型（Assistive） ：検索以上に自動的に適切なアクションを実行する。例えば：映画名を検索すると、検索結果カードの下の部分で「予約ボタン」が表示される。 これらの特徴は共通のゴールを持っています。ユーザーの意図（ユーザーが探したいもの）を理解することです。ユーザーが探したいものは、ユーザー自身しか分からないので、検索システムの開発側はユーザー意図を3つの次元に分割し、それぞれの次元を 定量 化します。 コンテンツ理解 ：検索対象文書とユーザーが入力したキーワードのクエリそのものを理解する。 ユーザー理解 ：検索システムのユーザーの好みやプロフィールを理解する。 ドメイン 理解 ：検索システムをデプロイする業務/ ドメイン 知識を理解する。 次のベン図に書いていたように各次元の代表技術と2つの次元を組み合わせた技術が記載されています。 コンテンツ理解 → キーワード検索（ 全文検索 ） ユーザー理解 → 協調フィルタリング （推薦システム） ドメイン 理解 → ナレッジグラフ コンテンツ理解 + ユーザー理解 → パーソナライズド検索 ユーザー理解 + ドメイン 理解 → マルチモーダル推薦 コンテンツ理解 + ドメイン 理解 → セマンティック検索 今回は、ナレッジグラフを搭載したセマンティック検索システムを紹介します。 ナレッジグラフを搭載したセマンティック検索 検索エンジン ナレッジグラフを導入する前に、まず、 検索エンジン の構成を解説します。 検索エンジン では、文書データを 転置インデックス というデータ構造で管理しています。転置とは、本の索引のように、単語の一覧を並べて、その単語を含む文章にひも付いています。 転置インデックス としてデータを管理することで検索スピードが速くなります。 転置インデックス ができたら、ユーザーがクエリを入力する時に、以下の処理を行います。 クエリの解析 ：クエリをキーワード・単語に分割します。 フィルターリング ： 転置インデックス からそれらのキーワードを含む文書を取得します。 関連度の計算 ： 取得した文書とクエリの関連度を計算します。計算方法は様々ですが、よく使われるのはBM25です。 検索結果提供 ：最後に、関連度順で文書を並べてユーザーに返します。 検索エンジン を仕様することで、文書入れるだけでOut-of-the-boxで 全文検索 ができます。最初は、このようなキーワード検索だけで十分に情報検索ができますが、データがだんだん溜まっていけばいくほど、キーワード検索だけで得られない場合が多いです。例えば、Eコマースのシステムを例にして、ユーザーが iPad をクエリとして検索するときに、出てくるのは「 iPad のケース」や「 iPad の充電器」など iPad 本体ではありません。 この場合は、明らかに生のキーワード検索だけで、ユーザーが探したい情報を得ることはできません。1つの解決方法としては、ユーザーのクリック情報を収集して 協調フィルタリング といった方法を使用して、検索結果を調整するのはできます。ただし、このアプローチの欠点としては、ユーザーの行動が制御できず、データの偏りが生じると、変な検索結果が出ています。そのために、今回は、 ナレッジグラフ を導入して、検索対象データとクエリに意味を持たせるべきです。 ナレッジグラフ ナレッジグラフとは、簡単に言うと人間の知識をグラフ形式で表現するものです。世の中での定義は様々ですが、検索の文脈では、人の知識を表現するために5つのレベルで表現できます。 言い換え（ Alternative Labels）同じ意味を表現する単語。例えば：チョコレート => チョコ； 国際連合 => 国連。 同義語・類義語（Synonyms）近い意味を表現する単語。例えば：人間 => 人、人類；食べ物 => 食材、食料、フード、食品。 分類体系（Taxonomy）ものを階層的なカテゴリに分類する。例えば：加藤ーIS_A→人間、人間ーIS_A→哺乳類、哺乳類ーIS_A→動物。 オントロジー （Ontology）ものの種類（タイプ・クラス）の関連性を表現する。例えば：動物ー食べる→食べ物、人間 ナレッジグラフ（Knowledge Graph） オントロジー を インスタンス 化したものを同じグラフで表現する。例えば：加藤ーIS_A→人間、加藤ー食べる→食べ物 基本的に、ナレッジグラフは構造データであるので、データを簡単に探索できます。例えば、 Google 検索で「日本」というクエリを打った時に、検索結果の右側に日本のナレッジパネルが出てきます。そのナレッジパネルから日本の首都である「東京」をクリックすると、東京のナレッジパネルをすぐに表示できます。 セマンティック検索 ナレッジグラフと 検索エンジン の双方の利点を活用するとセマンティック検索が実現できます。セマンティック検索では、ユーザーが打ったクエリからエンティティ（Entity）と関係（Relation）を抽出します。そして、「エンティティ」と「関係」の情報を使って、以下の処理を行うことができます。 [1] 得られた情報がたどり着くまでナレッジグラフに対してグラフ走査（Graph Traversal）を行います。 例えば：「ISID近くの中華」、解析結果のイメージは以下のとおりです。 対象クラス： 中華レストラン 絞り込み条件： 距離： 条件：近い（5km以内） 原点：京王品川ビル（ISID本社） この解析結果をもとに、GraphQL、 Cypher QL（Neo4j）、SPARQLなどに変換すれば、グラフ走査を行うことができ、最後に対象ドキュメントまでたどり着きます。 Cypher Scriptのクエリイメージは以下のとおりです。 MATCH (a: Article)-[:HAS_MENTION]->(r:ChineseRestaurant) MATCH (c: Company {english_name: ISID})-[:HAS_HEADQUARTER]->(o:Office) WHERE point.distance(r.geolocation, o.geolocation) <= 5000 RETURN a アプローチ[1]では、高度なセマンティック解析処理と高度なセマンティック情報を持つナレッジグラフが必要で、難易度が高いです。もちろんこのようなシステムを実現できれば理想的であるが、人手で作るのは大変ですし、自動で作るのはかなり難しいです。 [2] 関連するエンティティをナレッジグラフから抽出してクエリを拡張してから 検索エンジン にクエリを入力します。 このアプローチでは、クエリを解析して直接ナレッジグラフから答えを抽出するのではなく、ナレッジグラフから情報を抽出して、クエリを拡張します。 同じ例の「ISID近くの中華」ですと、ISIDという言葉は「 電通国際情報サービス 」や「品川」で、中華という言葉は「レストラン」や「中華料理」などナレッジグラフから抽出します。そのあと、オリジナルクエリにそれらの言葉を追加して、 検索エンジン のクエリを作って投げます。 Elasticsearchのクエリイメージは以下のとおりです。 { " query ": { " query_string ": { " fields ": [ " title ", " body ", " category " ] , " query ": " (ISID^10 OR 電通国際情報サービス OR 品川) AND (中華^10 OR レストラン OR 中華料理) " } } } アプローチ1に比べて、このアプローチの方がより現実的です。高度なセマンティック情報を持つナレッジグラフの必要性が低く、has_related_termsという関係性を表現したナレッジグラフで十分です。もちろん、アプローチ1の方は検索精度が高いですが、最初の段階で、このアプローチはやりやすいと考えられます。 まとめ 今回は、検索システムにナレッジグラフの導入イメージを紹介しました。イメージがつくように簡単なNeo4jの Cypher スクリプト とElasticsearchクエリの例をあげてみました。ナレッジグラフを活用する前に、ナレッジグラフ構築が必要で、このステップは一番大変だと思います。ISIDでは、日本語の文書からナレッジグラフを構築する技術の研究を行っています。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募をお待ちしています。 AIエンジニア（プロダクト開発） AIプロダクトマネージャー AIコンサルタント AIビジネスプロジェクトマネージャー 執筆： @faisalhadiputra 、レビュー： @yamada.y （ Shodo で執筆されました ）

みなさんこんにちは！ 電通国際情報サービス （ISID）クロス イノベーション 本部 AIトランスフォーメーションセンター（AITC） インドネシア 出身のファイサル ハディプトラと申します。この記事は 電通国際情報サービス Advent Calendar 2022 の12月7日の記事です。 先日、TECHPLAYで「AI搭載検索システム」について登壇いたしました。 Techplayイベントページ 今回は、AI搭載検索システムに関連する「ナレッジグラフを搭載した検索システム」について紹介します。 AI搭載検索システム 検索といえば、皆さんはきっと Google 検索をイメージしています。最近の Google 検索は、昔とは違ってAI技術を活用することで、ただのキーワード検索を超えた特徴を持っています。 Google 検索に慣れているほとんどのユーザーは検索システムを使用するときに、以下のようなことを期待します。 ドメイン 理解（Domain-aware） ：ユーザーのクエリ内のキーワードに該当する概念を認識して自動的にその概念のカテゴリや属性などをクエリに付加する。例えば：「ISID」というクエリを打ったときに、「会社」のカテゴリ、「 電通 国際情報」の別名、と「品川」の本社所在地などの情報をクエリに付加する。 文脈とユーザーの理解（Contextual and Personalized） ：ユーザーの好み・プロフィールを考慮してクエリと検索結果の関連度を調整する。例えば：エンジニアが「 Python 」というクエリを打ったときに、蛇の Python ではなく、 プログラミング言語 の Python を記載する記事を返す。 対話型（Conversational） ： 自然言語 を理解し、前に検索したものを考慮する。例えば：「コロナ」と検索した後、次に「mrna」と検索すると、モデルなのワクチン情報が出てくる。 マルチモーダル（Multi-modal） ：テキストに限らず、音声、画像、映像などに対応する。 知能的（Intelligent） ：データが溜まっていけばいくほど自己改善する。例えば：誤字自動訂正や自動補完機能がだんだん賢くなる。 支援型（Assistive） ：検索以上に自動的に適切なアクションを実行する。例えば：映画名を検索すると、検索結果カードの下の部分で「予約ボタン」が表示される。 これらの特徴は共通のゴールを持っています。ユーザーの意図（ユーザーが探したいもの）を理解することです。ユーザーが探したいものは、ユーザー自身しか分からないので、検索システムの開発側はユーザー意図を3つの次元に分割し、それぞれの次元を 定量 化します。 コンテンツ理解 ：検索対象文書とユーザーが入力したキーワードのクエリそのものを理解する。 ユーザー理解 ：検索システムのユーザーの好みやプロフィールを理解する。 ドメイン 理解 ：検索システムをデプロイする業務/ ドメイン 知識を理解する。 次のベン図に書いていたように各次元の代表技術と2つの次元を組み合わせた技術が記載されています。 コンテンツ理解 → キーワード検索（ 全文検索 ） ユーザー理解 → 協調フィルタリング （推薦システム） ドメイン 理解 → ナレッジグラフ コンテンツ理解 + ユーザー理解 → パーソナライズド検索 ユーザー理解 + ドメイン 理解 → マルチモーダル推薦 コンテンツ理解 + ドメイン 理解 → セマンティック検索 今回は、ナレッジグラフを搭載したセマンティック検索システムを紹介します。 ナレッジグラフを搭載したセマンティック検索 検索エンジン ナレッジグラフを導入する前に、まず、 検索エンジン の構成を解説します。 検索エンジン では、文書データを 転置インデックス というデータ構造で管理しています。転置とは、本の索引のように、単語の一覧を並べて、その単語を含む文章にひも付いています。 転置インデックス としてデータを管理することで検索スピードが速くなります。 転置インデックス ができたら、ユーザーがクエリを入力する時に、以下の処理を行います。 クエリの解析 ：クエリをキーワード・単語に分割します。 フィルターリング ： 転置インデックス からそれらのキーワードを含む文書を取得します。 関連度の計算 ： 取得した文書とクエリの関連度を計算します。計算方法は様々ですが、よく使われるのはBM25です。 検索結果提供 ：最後に、関連度順で文書を並べてユーザーに返します。 検索エンジン を仕様することで、文書入れるだけでOut-of-the-boxで 全文検索 ができます。最初は、このようなキーワード検索だけで十分に情報検索ができますが、データがだんだん溜まっていけばいくほど、キーワード検索だけで得られない場合が多いです。例えば、Eコマースのシステムを例にして、ユーザーが iPad をクエリとして検索するときに、出てくるのは「 iPad のケース」や「 iPad の充電器」など iPad 本体ではありません。 この場合は、明らかに生のキーワード検索だけで、ユーザーが探したい情報を得ることはできません。1つの解決方法としては、ユーザーのクリック情報を収集して 協調フィルタリング といった方法を使用して、検索結果を調整するのはできます。ただし、このアプローチの欠点としては、ユーザーの行動が制御できず、データの偏りが生じると、変な検索結果が出ています。そのために、今回は、 ナレッジグラフ を導入して、検索対象データとクエリに意味を持たせるべきです。 ナレッジグラフ ナレッジグラフとは、簡単に言うと人間の知識をグラフ形式で表現するものです。世の中での定義は様々ですが、検索の文脈では、人の知識を表現するために5つのレベルで表現できます。 言い換え（ Alternative Labels）同じ意味を表現する単語。例えば：チョコレート => チョコ； 国際連合 => 国連。 同義語・類義語（Synonyms）近い意味を表現する単語。例えば：人間 => 人、人類；食べ物 => 食材、食料、フード、食品。 分類体系（Taxonomy）ものを階層的なカテゴリに分類する。例えば：加藤ーIS_A→人間、人間ーIS_A→哺乳類、哺乳類ーIS_A→動物。 オントロジー （Ontology）ものの種類（タイプ・クラス）の関連性を表現する。例えば：動物ー食べる→食べ物、人間 ナレッジグラフ（Knowledge Graph） オントロジー を インスタンス 化したものを同じグラフで表現する。例えば：加藤ーIS_A→人間、加藤ー食べる→食べ物 基本的に、ナレッジグラフは構造データであるので、データを簡単に探索できます。例えば、 Google 検索で「日本」というクエリを打った時に、検索結果の右側に日本のナレッジパネルが出てきます。そのナレッジパネルから日本の首都である「東京」をクリックすると、東京のナレッジパネルをすぐに表示できます。 セマンティック検索 ナレッジグラフと 検索エンジン の双方の利点を活用するとセマンティック検索が実現できます。セマンティック検索では、ユーザーが打ったクエリからエンティティ（Entity）と関係（Relation）を抽出します。そして、「エンティティ」と「関係」の情報を使って、以下の処理を行うことができます。 [1] 得られた情報がたどり着くまでナレッジグラフに対してグラフ走査（Graph Traversal）を行います。 例えば：「ISID近くの中華」、解析結果のイメージは以下のとおりです。 対象クラス： 中華レストラン 絞り込み条件： 距離： 条件：近い（5km以内） 原点：京王品川ビル（ISID本社） この解析結果をもとに、GraphQL、 Cypher QL（Neo4j）、SPARQLなどに変換すれば、グラフ走査を行うことができ、最後に対象ドキュメントまでたどり着きます。 Cypher Scriptのクエリイメージは以下のとおりです。 MATCH (a: Article)-[:HAS_MENTION]->(r:ChineseRestaurant) MATCH (c: Company {english_name: ISID})-[:HAS_HEADQUARTER]->(o:Office) WHERE point.distance(r.geolocation, o.geolocation) <= 5000 RETURN a アプローチ[1]では、高度なセマンティック解析処理と高度なセマンティック情報を持つナレッジグラフが必要で、難易度が高いです。もちろんこのようなシステムを実現できれば理想的であるが、人手で作るのは大変ですし、自動で作るのはかなり難しいです。 [2] 関連するエンティティをナレッジグラフから抽出してクエリを拡張してから 検索エンジン にクエリを入力します。 このアプローチでは、クエリを解析して直接ナレッジグラフから答えを抽出するのではなく、ナレッジグラフから情報を抽出して、クエリを拡張します。 同じ例の「ISID近くの中華」ですと、ISIDという言葉は「 電通国際情報サービス 」や「品川」で、中華という言葉は「レストラン」や「中華料理」などナレッジグラフから抽出します。そのあと、オリジナルクエリにそれらの言葉を追加して、 検索エンジン のクエリを作って投げます。 Elasticsearchのクエリイメージは以下のとおりです。 { " query ": { " query_string ": { " fields ": [ " title ", " body ", " category " ] , " query ": " (ISID^10 OR 電通国際情報サービス OR 品川) AND (中華^10 OR レストラン OR 中華料理) " } } } アプローチ1に比べて、このアプローチの方がより現実的です。高度なセマンティック情報を持つナレッジグラフの必要性が低く、has_related_termsという関係性を表現したナレッジグラフで十分です。もちろん、アプローチ1の方は検索精度が高いですが、最初の段階で、このアプローチはやりやすいと考えられます。 まとめ 今回は、検索システムにナレッジグラフの導入イメージを紹介しました。イメージがつくように簡単なNeo4jの Cypher スクリプト とElasticsearchクエリの例をあげてみました。ナレッジグラフを活用する前に、ナレッジグラフ構築が必要で、このステップは一番大変だと思います。ISIDでは、日本語の文書からナレッジグラフを構築する技術の研究を行っています。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募をお待ちしています。 AIエンジニア（プロダクト開発） AIプロダクトマネージャー AIコンサルタント AIビジネスプロジェクトマネージャー 執筆： @faisalhadiputra 、レビュー： @yamada.y （ Shodo で執筆されました ）

X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの柴田です。 これは 電通国際情報サービス Advent Calendar 2022 6日目の記事です。5日目の昨日は、もう一人の柴田さんの記事「 Argo CDを使ってIstioをバージョンアップする 」でした。 はじめに Webアプリケーションの構成 動作イメージ コードサンプル はじめに 社内で Excel ファイルを扱う業務があり、特定の Excel ファイルをテンプレートとして都度ファイルをコピーする形で運用しています。 Excel ファイルはメンテナンス時の差分管理が Excel 単体の機能では難しく、複数人での修正も可能ですが、個人的には変更履歴があまり視認性の良いものではないと考えています。 そこで、 Excel ファイルに記載する内容を別途テキストベースで差分管理し、修正したテキストを Excel ファイルに流し込むシステムを構築することになりました。 また、併せてNext.jsを利用しWebアプリケーション化も実現して、 Excel ファイルに追加するテキストもWebアプリケーション上から入力できるような仕組みにしています。 今回作成しているWebアプリケーションは、Next.jsとTypeScriptを利用しています。 その中で、 Amazon S3 に保存した Excel ファイル（拡張子xlsx）を取得して、 Excel ファイルを加工処理してからクライアント（ Webブラウザ ）に返却する、という処理を紹介します。 Webアプリケーションの構成 前述の通り、 Amazon S3 を利用しているため、Webシステムは AWS 上に構築しています。 実際はもう少し複雑なシステム構成ですが、以下は、今回紹介する Excel 処理部分のフローを抜粋した図です。 Webブラウザ からリク エス トを受けたWebアプリケーション（Next.js）が、バックエンド側で Amazon S3 から Excel ファイルを取得します。取得した Excel ファイルの加工処理をした後、 Webブラウザ 側に返却する流れです。 Amazon S3 からのデータ取得のライブラリは AWS SDK for JavaScript v3 、 Excel ファイルの加工のライブラリは ExcelJS を利用しています。 動作イメージ ダウンロードボタンを押すと、 /api/download にリク エス トが送信され、加工したファイルがダウンロードされます。 コードサンプル Next.jsのプロジェクト作成は、以下の陳さんの記事を参考にしました。 tech.isid.co.jp まずはフロント側です。 // pages/index.tsx import styles from '../styles/Home.module.css' const Home = () => { const download = async ( fileName: string ) => { const response = await fetch ( `/api/download` , { method: 'GET' } ) try { if ( response. status !== 200 ) { throw new Error () } else { const blob = await response.blob () const blobFile = new Blob ( [ blob ] , { type : 'application/xlsx' } ) const a = document .createElement ( 'a' ) a.style.display = 'none' document .body.appendChild ( a ) const url = window .URL.createObjectURL ( blobFile ) a.href = url a.download = fileName a.click () window .URL.revokeObjectURL ( url ) } } catch ( e: unknown ) { console .error ( e ) } } return ( < div className = { styles.container } > < main className = { styles.main } > < button onClick = { () => download ( 'ダウンロードファイル名.xlsx' ) } > ダウンロード < /button > < /main > < /div > ) } export default Home サンプルコードでは、ボタンをクリックするとバックエンドの API にリク エス トし、レスポンスを組み立てて、ファイル保存のダイアログを表示させる形にしています。 次に API です。 // pages/api/download.ts import { Readable } from 'stream' import * as ExcelJS from 'exceljs' import type { NextApiRequest , NextApiResponse } from 'next' import { getObject } from '../../src/aws/s3' export default async function download ( req: NextApiRequest , res: NextApiResponse ) : Promise < void > { try { const s3Output = await getObject ( 'bucket' , 'key' ) if ( s3Output.Body instanceof Readable ) { const s3OutputStream = s3Output.Body as Readable res.setHeader ( 'Content-Type' , 'application/xlsx' ) res. status( 200 ) const workbook = new ExcelJS.Workbook () await workbook.xlsx.read ( s3OutputStream ) const sheet = workbook.getWorksheet ( 'Sheet1' ) sheet.getRow ( 1 ) .getCell ( 1 ) .value = 'テスト' await workbook.xlsx.write ( res ) } return } catch ( e: unknown ) { return res. status( 500 ) .json ( { message: 'Internal Server Error' } ) } } // src/aws/s3.ts import { GetObjectCommand , GetObjectCommandOutput , S3Client } from '@aws-sdk/client-s3' export async function getObject ( bucket: string , key: string ) : Promise < GetObjectCommandOutput > { const params = { Bucket: bucket , Key: key , } const command = new GetObjectCommand ( params ) return await new S3Client ( { region: 'ap-northeast-1' } ) .send ( command ) } Amazon S3 にリク エス トを送信し、レスポンスを受け取ります。 受け取ったStreamを順次処理するため、そのままExcelJSに渡しています。 ExcelJSでは、Streamをそのまま処理してくれます。 参考 github.com ExcelJSの ソースコード を見ると、実際はメモリ上に一旦すべて展開されます。 Streamのまま順次処理していく機能も用意されていますが、今回はファイルサイズが小さく、処理が複雑になりそうだったため利用しませんでした。 参考 github.com 最後にテストコードです。 API Routes のテストライブラリは next-test-api-route-handler を利用しています。 // test/api/download.test.ts import fs from 'fs' import path from 'path' import { PassThrough } from 'stream' import { GetObjectCommandOutput } from '@aws-sdk/client-s3' import { sdkStreamMixin } from '@aws-sdk/util-stream-node' import * as ExcelJS from 'exceljs' import { testApiHandler } from 'next-test-api-route-handler' import download from '../../pages/api/download' import * as s3Module from '../../src/aws/s3' const handler: typeof download = download const filePath = path.join ( __dirname , 'download.xlsx' ) const getObjectSpyOn = jest.spyOn ( s3Module , 'getObject' ) const getObject200 = async () : Promise < GetObjectCommandOutput > => { return { Body: sdkStreamMixin ( fs.createReadStream ( filePath )), $metadata: { httpStatusCode: 200 , } , } } const getObject500 = async () : Promise < GetObjectCommandOutput > => { const mockReadable = sdkStreamMixin (new PassThrough ()) mockReadable.emit ( 'error' , new Error ( 'error' )) return { Body: mockReadable , $metadata: { httpStatusCode: 500 , } , } } describe ( 'client-s3' , () => { test ( '200' , async () => { getObjectSpyOn.mockImplementation ( getObject200 ) await testApiHandler ( { handler , test: async ( { fetch } ) => { const res = await fetch ( { method: 'GET' } ) expect ( res. status) .toBe ( 200 ) const workbook = new ExcelJS.Workbook () await workbook.xlsx.read ( res.body ) const worksheet = workbook.getWorksheet ( 'Sheet1' ) expect ( worksheet.getRow ( 1 ) .getCell ( 1 ) .value ) .toBe ( 'テスト' ) } , } ) } ) test ( '500' , async () => { getObjectSpyOn.mockImplementation ( getObject500 ) await testApiHandler ( { handler , test: async ( { fetch } ) => { const res = await fetch ( { method: 'GET' } ) expect ( res. status) .toBe ( 500 ) } , } ) } ) } ) Amazon S3 から取得する箇所をモック化しています。Stream部分には PassThrough を利用しています。 また、 AWS SDK for JavaScript v3のv3.188.0以降では、Stream処理が一部変更になり、Bodyの型が SdkStream<Readable> で返るようになりました。 そのため、 @aws-sdk/util-stream-node にある sdkStreamMixin を利用して、テストコードのモックでも同じ型を返すようにしています。 参考 github.com github.com 以上、Next.jsとTypeScriptを利用して、 Amazon S3 に保存されている Excel をExcelJSで加工してクライアントに返す方法の紹介でした。 電通国際情報サービス Advent Calendar 2022 7日目の明日は、Faisalさんの記事です。お楽しみに！ 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 - セキュリティエンジニア(セキュリティ設計) 執筆： @shibata.shunsuke 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、Stable Diffusion 2.0-美少女イラストです。 Stable Diffusionも2.0になったので、もう一度検証し直します。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 長い呪文は切り捨てられる編 AUTOMATIC 1111のインストール AUTOMATIC 1111のセッティング 呪文の基本ルール 美少女イラストの呪文 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render v1.5 まとめ 仲間募集 Stable Diffusionの全コンテンツ AUTOMATIC 1111のインストール Stable Diffusion 2.0 を実行する環境として、 AUTOMATIC 1111 を使います。 AUTOMATIC 1111 は、 Stable Diffusion を Google Colab 直接ではなく、 UI 経由で実行できるようにしています。似たような機能のものはいくつかありますが、 AUTOMATIC 1111 が最も人気があるので、今回からこれを使います。 Google Colab で動かすためのノートブックは こちら になります。 このノートブックを実行すると、下の方に Running on public URL: https://2c76db068be0e79a.gradio.app のようなURLのリンクが表示されるので、クリックしましょう。 Colab Pro の通常メモリでは、メモリが足りなくなることがありました。そのような場合は、 Google Drive にコピーしてハイメモリにしましょう。 AUTOMATIC 1111のセッティング パラメータは以下のようになります。 Sampling Steps: 50 Sampling Method: DPM2 Width: 768 Height: 768 CFG Scale: 7.5 Seed: -1 Sampling Stepsは、デフォルトの 20 だと少ないので、 50 くらいにしておきましょう。 Sampling Methodは DPM2 をお勧めしますが、 DDIM も悪くはありません。それ以外は、描く対象によりますが、あまりお勧めしません。 Width と Height は 768 をお勧めします。 Stable Diffusion 2.0 のモデルの 768-v-ema.ckpt は、 768 用のためです。 512 だとかを使うと画像が崩れることがあります。 CFG Scale は入力した呪文にどれだけ近い画像を生成するかのパラメータです。デフォルトの 7 でも問題ありませんが、僕はなんとなく 7.5 を指定しています。 呪文の基本ルール 以前よりも僕自身、呪文（prompt）の基本ルールがわかってきたので、お伝えします。経験則的な側面が強いですが、たぶん、あっていると思います。 トーク ンは75まで。 カンマ（,）は必要がない。カンマも トーク ンの一つとしてカウントされるので、ないほうが良い。 前の方にある トーク ンの方が出力結果に与える影響が大きい。 冠詞（a, an, theなど）は必要がない。 近くにある トーク ンは影響を受ける。後ろにある トーク ンも前の トーク ンに影響を与える。 トーク ンと トーク ンの間の トーク ン数が多くなると、 トーク ンの影響は少なくなる。 呪文は トーク ンに分解されます。 トーク ンは基本的には、単語だと思って大丈夫ですが、 Stable Diffusion が知らない トーク ンは、一つの単語が複数の トーク ンに分解されることもあります。例えば、 pixiv は、 pi と xiv の2つの トーク ンになります。 「後ろにある トーク ンも前の トーク ンに影響を与える」というのは、これまで、なんとなく感じていたけど、 言語化 できていなかった部分ではないでしょうか。 例えば、 apple on table だと赤いリンゴがほとんどです。しかし、 apple on yellow table だと黄色のりんごになる確率が増えます。 トーク ンと トーク ンの間の トーク ン数が多くなると、 トーク ンの影響は少なくなります。 例えば、 apple on yellow table だと黄色になるリンゴもありますが、 apple on a a a a a a a a a a a a a a a a a a yellow table だと、黄色になるリンゴの確率はかなり減ります。 美少女イラストの呪文 それでは、呪文の基本ルールをふまえた、 Stable Diffusion 2.0 で検証済みの美少女イラストの呪文を紹介します。 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render 閲覧用改行版 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render 出力結果の例です。 これは、厳選したものではなく、連発できます。それでは、呪文の中身を解説しましょう。 beautiful princess これまで、美少女を描画するときは、 beautiful girl を指定していたのですが、これを beautiful princess に変えました。これがかなり効果的で、美少女になる確率がかなり高くなりました。 beautiful face 美少女率を上げるためには、 beautiful face はあったほうが良いです。 beautiful hair beautiful clothes この呪文は、それほど大した意味はないのですが、前の face と次の artstation との距離をあけるために指定しています。 artstation はアートの投稿サイトなので、 face と artstation が近くにあると、 face に過剰に色がつくなど artstation の影響をうけることがあります。 hair と clothes は、 artstation の影響を受けてもそれほど問題はないので、緩衝材にぴったりです。 artstation artstation は、 art （イラスト）の投稿サイトです。 artstation を指定することで、出力結果がイラストになります。 また、 artstation を指定することで、出力される画像のクオリティが上がります。 fantasy scene fantasy composition fantasy lighting シーン（scene）、構図（composition）、ライティング（lighting）は指定しておきましょう。指定しないと人物だけの単純な画像になることがあります。 修飾語は好みで構いません。 fantasy は美少女と相性の良い修飾語です。 princess 、 face 、 hair 、 clothes などに悪影響を与えることもありません。 octane render octane render を指定すると画像が多少立体的になります。二次元が好きな方は外してください。 v1.5 v1.5で下記のパラメータで実行してみました。 Width と Height を 512 に変えただけです。 Sampling Steps: 50 Sampling Method: DPM2 Width: 512 Height: 512 CFG Scale: 7.5 Seed: -1 v1.5でも、良い結果が連発できました。呪文が改善されたことと、 Sampling Method を DDIM から DPM2 にしたことが良い結果につながったのかもしれません。 比べてみるとv2.0のほうが、質感が増しているのがわかります。 v1.5の出力結果はこちら。 まとめ 今回は、 Stable Diffusion 2.0 の美少女イラストの呪文を紹介しました。 v1.4 と v1.5 の違いはあまりなかったのですが、 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 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、Stable Diffusion 2.0-美少女イラストです。 Stable Diffusionも2.0になったので、もう一度検証し直します。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 長い呪文は切り捨てられる編 AUTOMATIC 1111のインストール AUTOMATIC 1111のセッティング 呪文の基本ルール 美少女イラストの呪文 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render v1.5 まとめ 仲間募集 Stable Diffusionの全コンテンツ AUTOMATIC 1111のインストール Stable Diffusion 2.0 を実行する環境として、 AUTOMATIC 1111 を使います。 AUTOMATIC 1111 は、 Stable Diffusion を Google Colab 直接ではなく、 UI 経由で実行できるようにしています。似たような機能のものはいくつかありますが、 AUTOMATIC 1111 が最も人気があるので、今回からこれを使います。 Google Colab で動かすためのノートブックは こちら になります。 このノートブックを実行すると、下の方に Running on public URL: https://2c76db068be0e79a.gradio.app のようなURLのリンクが表示されるので、クリックしましょう。 Colab Pro の通常メモリでは、メモリが足りなくなることがありました。そのような場合は、 Google Drive にコピーしてハイメモリにしましょう。 AUTOMATIC 1111のセッティング パラメータは以下のようになります。 Sampling Steps: 50 Sampling Method: DPM2 Width: 768 Height: 768 CFG Scale: 7.5 Seed: -1 Sampling Stepsは、デフォルトの 20 だと少ないので、 50 くらいにしておきましょう。 Sampling Methodは DPM2 をお勧めしますが、 DDIM も悪くはありません。それ以外は、描く対象によりますが、あまりお勧めしません。 Width と Height は 768 をお勧めします。 Stable Diffusion 2.0 のモデルの 768-v-ema.ckpt は、 768 用のためです。 512 だとかを使うと画像が崩れることがあります。 CFG Scale は入力した呪文にどれだけ近い画像を生成するかのパラメータです。デフォルトの 7 でも問題ありませんが、僕はなんとなく 7.5 を指定しています。 呪文の基本ルール 以前よりも僕自身、呪文（prompt）の基本ルールがわかってきたので、お伝えします。経験則的な側面が強いですが、たぶん、あっていると思います。 トーク ンは75まで。 カンマ（,）は必要がない。カンマも トーク ンの一つとしてカウントされるので、ないほうが良い。 前の方にある トーク ンの方が出力結果に与える影響が大きい。 冠詞（a, an, theなど）は必要がない。 近くにある トーク ンは影響を受ける。後ろにある トーク ンも前の トーク ンに影響を与える。 トーク ンと トーク ンの間の トーク ン数が多くなると、 トーク ンの影響は少なくなる。 呪文は トーク ンに分解されます。 トーク ンは基本的には、単語だと思って大丈夫ですが、 Stable Diffusion が知らない トーク ンは、一つの単語が複数の トーク ンに分解されることもあります。例えば、 pixiv は、 pi と xiv の2つの トーク ンになります。 「後ろにある トーク ンも前の トーク ンに影響を与える」というのは、これまで、なんとなく感じていたけど、 言語化 できていなかった部分ではないでしょうか。 例えば、 apple on table だと赤いリンゴがほとんどです。しかし、 apple on yellow table だと黄色のりんごになる確率が増えます。 トーク ンと トーク ンの間の トーク ン数が多くなると、 トーク ンの影響は少なくなります。 例えば、 apple on yellow table だと黄色になるリンゴもありますが、 apple on a a a a a a a a a a a a a a a a a a yellow table だと、黄色になるリンゴの確率はかなり減ります。 美少女イラストの呪文 それでは、呪文の基本ルールをふまえた、 Stable Diffusion 2.0 で検証済みの美少女イラストの呪文を紹介します。 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render 閲覧用改行版 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render 出力結果の例です。 これは、厳選したものではなく、連発できます。それでは、呪文の中身を解説しましょう。 beautiful princess これまで、美少女を描画するときは、 beautiful girl を指定していたのですが、これを beautiful princess に変えました。これがかなり効果的で、美少女になる確率がかなり高くなりました。 beautiful face 美少女率を上げるためには、 beautiful face はあったほうが良いです。 beautiful hair beautiful clothes この呪文は、それほど大した意味はないのですが、前の face と次の artstation との距離をあけるために指定しています。 artstation はアートの投稿サイトなので、 face と artstation が近くにあると、 face に過剰に色がつくなど artstation の影響をうけることがあります。 hair と clothes は、 artstation の影響を受けてもそれほど問題はないので、緩衝材にぴったりです。 artstation artstation は、 art （イラスト）の投稿サイトです。 artstation を指定することで、出力結果がイラストになります。 また、 artstation を指定することで、出力される画像のクオリティが上がります。 fantasy scene fantasy composition fantasy lighting シーン（scene）、構図（composition）、ライティング（lighting）は指定しておきましょう。指定しないと人物だけの単純な画像になることがあります。 修飾語は好みで構いません。 fantasy は美少女と相性の良い修飾語です。 princess 、 face 、 hair 、 clothes などに悪影響を与えることもありません。 octane render octane render を指定すると画像が多少立体的になります。二次元が好きな方は外してください。 v1.5 v1.5で下記のパラメータで実行してみました。 Width と Height を 512 に変えただけです。 Sampling Steps: 50 Sampling Method: DPM2 Width: 512 Height: 512 CFG Scale: 7.5 Seed: -1 v1.5でも、良い結果が連発できました。呪文が改善されたことと、 Sampling Method を DDIM から DPM2 にしたことが良い結果につながったのかもしれません。 比べてみるとv2.0のほうが、質感が増しているのがわかります。 v1.5の出力結果はこちら。 まとめ 今回は、 Stable Diffusion 2.0 の美少女イラストの呪文を紹介しました。 v1.4 と v1.5 の違いはあまりなかったのですが、 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 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの柴田です。 これは 電通国際情報サービス Advent Calendar 2022 6日目の記事です。5日目の昨日は、もう一人の柴田さんの記事「 Argo CDを使ってIstioをバージョンアップする 」でした。 はじめに Webアプリケーションの構成 動作イメージ コードサンプル はじめに 社内で Excel ファイルを扱う業務があり、特定の Excel ファイルをテンプレートとして都度ファイルをコピーする形で運用しています。 Excel ファイルはメンテナンス時の差分管理が Excel 単体の機能では難しく、複数人での修正も可能ですが、個人的には変更履歴があまり視認性の良いものではないと考えています。 そこで、 Excel ファイルに記載する内容を別途テキストベースで差分管理し、修正したテキストを Excel ファイルに流し込むシステムを構築することになりました。 また、併せてNext.jsを利用しWebアプリケーション化も実現して、 Excel ファイルに追加するテキストもWebアプリケーション上から入力できるような仕組みにしています。 今回作成しているWebアプリケーションは、Next.jsとTypeScriptを利用しています。 その中で、 Amazon S3 に保存した Excel ファイル（拡張子xlsx）を取得して、 Excel ファイルを加工処理してからクライアント（ Webブラウザ ）に返却する、という処理を紹介します。 Webアプリケーションの構成 前述の通り、 Amazon S3 を利用しているため、Webシステムは AWS 上に構築しています。 実際はもう少し複雑なシステム構成ですが、以下は、今回紹介する Excel 処理部分のフローを抜粋した図です。 Webブラウザ からリク エス トを受けたWebアプリケーション（Next.js）が、バックエンド側で Amazon S3 から Excel ファイルを取得します。取得した Excel ファイルの加工処理をした後、 Webブラウザ 側に返却する流れです。 Amazon S3 からのデータ取得のライブラリは AWS SDK for JavaScript v3 、 Excel ファイルの加工のライブラリは ExcelJS を利用しています。 動作イメージ ダウンロードボタンを押すと、 /api/download にリク エス トが送信され、加工したファイルがダウンロードされます。 コードサンプル Next.jsのプロジェクト作成は、以下の陳さんの記事を参考にしました。 tech.isid.co.jp まずはフロント側です。 // pages/index.tsx import styles from '../styles/Home.module.css' const Home = () => { const download = async ( fileName: string ) => { const response = await fetch ( `/api/download` , { method: 'GET' } ) try { if ( response. status !== 200 ) { throw new Error () } else { const blob = await response.blob () const blobFile = new Blob ( [ blob ] , { type : 'application/xlsx' } ) const a = document .createElement ( 'a' ) a.style.display = 'none' document .body.appendChild ( a ) const url = window .URL.createObjectURL ( blobFile ) a.href = url a.download = fileName a.click () window .URL.revokeObjectURL ( url ) } } catch ( e: unknown ) { console .error ( e ) } } return ( < div className = { styles.container } > < main className = { styles.main } > < button onClick = { () => download ( 'ダウンロードファイル名.xlsx' ) } > ダウンロード < /button > < /main > < /div > ) } export default Home サンプルコードでは、ボタンをクリックするとバックエンドの API にリク エス トし、レスポンスを組み立てて、ファイル保存のダイアログを表示させる形にしています。 次に API です。 // pages/api/download.ts import { Readable } from 'stream' import * as ExcelJS from 'exceljs' import type { NextApiRequest , NextApiResponse } from 'next' import { getObject } from '../../src/aws/s3' export default async function download ( req: NextApiRequest , res: NextApiResponse ) : Promise < void > { try { const s3Output = await getObject ( 'bucket' , 'key' ) if ( s3Output.Body instanceof Readable ) { const s3OutputStream = s3Output.Body as Readable res.setHeader ( 'Content-Type' , 'application/xlsx' ) res. status( 200 ) const workbook = new ExcelJS.Workbook () await workbook.xlsx.read ( s3OutputStream ) const sheet = workbook.getWorksheet ( 'Sheet1' ) sheet.getRow ( 1 ) .getCell ( 1 ) .value = 'テスト' await workbook.xlsx.write ( res ) } return } catch ( e: unknown ) { return res. status( 500 ) .json ( { message: 'Internal Server Error' } ) } } // src/aws/s3.ts import { GetObjectCommand , GetObjectCommandOutput , S3Client } from '@aws-sdk/client-s3' export async function getObject ( bucket: string , key: string ) : Promise < GetObjectCommandOutput > { const params = { Bucket: bucket , Key: key , } const command = new GetObjectCommand ( params ) return await new S3Client ( { region: 'ap-northeast-1' } ) .send ( command ) } Amazon S3 にリク エス トを送信し、レスポンスを受け取ります。 受け取ったStreamを順次処理するため、そのままExcelJSに渡しています。 ExcelJSでは、Streamをそのまま処理してくれます。 参考 github.com ExcelJSの ソースコード を見ると、実際はメモリ上に一旦すべて展開されます。 Streamのまま順次処理していく機能も用意されていますが、今回はファイルサイズが小さく、処理が複雑になりそうだったため利用しませんでした。 参考 github.com 最後にテストコードです。 API Routes のテストライブラリは next-test-api-route-handler を利用しています。 // test/api/download.test.ts import fs from 'fs' import path from 'path' import { PassThrough } from 'stream' import { GetObjectCommandOutput } from '@aws-sdk/client-s3' import { sdkStreamMixin } from '@aws-sdk/util-stream-node' import * as ExcelJS from 'exceljs' import { testApiHandler } from 'next-test-api-route-handler' import download from '../../pages/api/download' import * as s3Module from '../../src/aws/s3' const handler: typeof download = download const filePath = path.join ( __dirname , 'download.xlsx' ) const getObjectSpyOn = jest.spyOn ( s3Module , 'getObject' ) const getObject200 = async () : Promise < GetObjectCommandOutput > => { return { Body: sdkStreamMixin ( fs.createReadStream ( filePath )), $metadata: { httpStatusCode: 200 , } , } } const getObject500 = async () : Promise < GetObjectCommandOutput > => { const mockReadable = sdkStreamMixin (new PassThrough ()) mockReadable.emit ( 'error' , new Error ( 'error' )) return { Body: mockReadable , $metadata: { httpStatusCode: 500 , } , } } describe ( 'client-s3' , () => { test ( '200' , async () => { getObjectSpyOn.mockImplementation ( getObject200 ) await testApiHandler ( { handler , test: async ( { fetch } ) => { const res = await fetch ( { method: 'GET' } ) expect ( res. status) .toBe ( 200 ) const workbook = new ExcelJS.Workbook () await workbook.xlsx.read ( res.body ) const worksheet = workbook.getWorksheet ( 'Sheet1' ) expect ( worksheet.getRow ( 1 ) .getCell ( 1 ) .value ) .toBe ( 'テスト' ) } , } ) } ) test ( '500' , async () => { getObjectSpyOn.mockImplementation ( getObject500 ) await testApiHandler ( { handler , test: async ( { fetch } ) => { const res = await fetch ( { method: 'GET' } ) expect ( res. status) .toBe ( 500 ) } , } ) } ) } ) Amazon S3 から取得する箇所をモック化しています。Stream部分には PassThrough を利用しています。 また、 AWS SDK for JavaScript v3のv3.188.0以降では、Stream処理が一部変更になり、Bodyの型が SdkStream<Readable> で返るようになりました。 そのため、 @aws-sdk/util-stream-node にある sdkStreamMixin を利用して、テストコードのモックでも同じ型を返すようにしています。 参考 github.com github.com 以上、Next.jsとTypeScriptを利用して、 Amazon S3 に保存されている Excel をExcelJSで加工してクライアントに返す方法の紹介でした。 電通国際情報サービス Advent Calendar 2022 7日目の明日は、Faisalさんの記事です。お楽しみに！ 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 - セキュリティエンジニア(セキュリティ設計) 執筆： @shibata.shunsuke 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

初めに ISID X（クロス） イノベーション 本部 の三浦です。 仕事でかかわってるわけではありませんが、個人的な興味としてStable Diffusion周りの動向を追っております。 あの界隈の進歩は今凄まじいですね。 で、 google colab上で試すというやり方もあるのですが、 google colabのリソース枠を使い果たす事態が最近頻発しておりますので今回はdokcerベースでローカル環境を作りました。 また、CPUのみのマシンでもお試しできることを確認しましたので執筆している次第です。 概要 Stable Diffusion、および、Stable Diffusion派生モデルを使用していくうえで非常に便利な『 Stable Diffusion web UI(AUTOMATIC1111版) 』の環境を GPU が使えないマシン向けにdokcer で構築します。 なお、Stable Diffusion web UI(AUTOMATIC1111)は、 google colab上で動作させることも可能です。 前提条件、検証環境 dokcer compose 使用 gitクライアント 使用 windows10 メモリ 16G以上 (メモリ8Gは厳しいです) 手順概要 stable-diffusion-webui-docker 　を clone docker compose --profile download up --build docker compose --profile auto-cpu up --build これだけでAI絵作成用のツール、Stable Diffusion web UI（AUTOMATIC1111版）を立ち上げることが可能です。 なお、本日は省略しますが、簡易に他のStable Diffusion派生モデルを追加し利用することも可能です。 実行例 stable-diffusion-webui-docker をclone後、 docker compose --profile download up --build 上記コマンドを実行します。相当量のリソースをダウンロードするため私の環境では1h弱かかりました。 上記のように必要なリソースがダウンロードできたので次はCPUモードで起動します。 なお、上記 ディレクト リに手を加えれば他のStable Diffusion派生モデルの利用も可能です。 また、起動オプションの変更により GPU モードで起動することも簡単です。 さらにdocker-composeファイルを編集することにより低スペックな GPU でも稼働させることもできます（※1）。 docker compose --profile auto-cpu up --build 起動が完了すると↑のようにURLが表示されますので http://localhost:7860/ にアクセスします。 なお、一度目の起動には非常に時間がかかりますが、二回目以降は数分レベルで起動します。 利用例 上記設定で、下記ぐらいの速度で生成できます。 intel i7 4770s （物理4コア）の場合、400s Ryzen 7 3700X （物理8コア）の場合、200s 解像度、step数、 サンプラー 、モデルで生成速度はだいたい決まります。対話式でいろいろ試すにはややつらいですが、プロンプト掲載サイトのプロンプトを試すならある程度割り切れる速度かと思ってる感じです(※2)。 また、こんな感じで簡単に複数枚作ることもできるので寝ている間にCPUを酷使して大量生成するのも簡単です。 GPU でちゃんとモデルがのる環境だと、↓が1分程度で生成可能です。 CPUのみ物理4コアのマシンにて約40分で生成しました。100枚までまとめて生成可能なので夜数時間かけて生成するという使い方も可能です。 まとめ いま、画像生成の分野は非常に盛り上がっていると思います。ご興味を持った方は触ってみるといいのではないでしょうか？ 注記 ※1 メモリ4Gクラスの GPU でも動作させることができます。GTX1650で稼働することを確認しました。が、かなり遅くなるので、メモリ8G以上の GPU がお薦めです。 ※2 google colabだと、10s-20s程度です。 執筆： @miura.toshihiko 、レビュー： @higa （ Shodo で執筆されました ）

初めに ISID X（クロス） イノベーション 本部 の三浦です。 仕事でかかわってるわけではありませんが、個人的な興味としてStable Diffusion周りの動向を追っております。 あの界隈の進歩は今凄まじいですね。 で、 google colab上で試すというやり方もあるのですが、 google colabのリソース枠を使い果たす事態が最近頻発しておりますので今回はdokcerベースでローカル環境を作りました。 また、CPUのみのマシンでもお試しできることを確認しましたので執筆している次第です。 概要 Stable Diffusion、および、Stable Diffusion派生モデルを使用していくうえで非常に便利な『 Stable Diffusion web UI(AUTOMATIC1111版) 』の環境を GPU が使えないマシン向けにdokcer で構築します。 なお、Stable Diffusion web UI(AUTOMATIC1111)は、 google colab上で動作させることも可能です。 前提条件、検証環境 dokcer compose 使用 gitクライアント 使用 windows10 メモリ 16G以上 (メモリ8Gは厳しいです) 手順概要 stable-diffusion-webui-docker 　を clone docker compose --profile download up --build docker compose --profile auto-cpu up --build これだけでAI絵作成用のツール、Stable Diffusion web UI（AUTOMATIC1111版）を立ち上げることが可能です。 なお、本日は省略しますが、簡易に他のStable Diffusion派生モデルを追加し利用することも可能です。 実行例 stable-diffusion-webui-docker をclone後、 docker compose --profile download up --build 上記コマンドを実行します。相当量のリソースをダウンロードするため私の環境では1h弱かかりました。 上記のように必要なリソースがダウンロードできたので次はCPUモードで起動します。 なお、上記 ディレクト リに手を加えれば他のStable Diffusion派生モデルの利用も可能です。 また、起動オプションの変更により GPU モードで起動することも簡単です。 さらにdocker-composeファイルを編集することにより低スペックな GPU でも稼働させることもできます（※1）。 docker compose --profile auto-cpu up --build 起動が完了すると↑のようにURLが表示されますので http://localhost:7860/ にアクセスします。 なお、一度目の起動には非常に時間がかかりますが、二回目以降は数分レベルで起動します。 利用例 上記設定で、下記ぐらいの速度で生成できます。 intel i7 4770s （物理4コア）の場合、400s Ryzen 7 3700X （物理8コア）の場合、200s 解像度、step数、 サンプラー 、モデルで生成速度はだいたい決まります。対話式でいろいろ試すにはややつらいですが、プロンプト掲載サイトのプロンプトを試すならある程度割り切れる速度かと思ってる感じです(※2)。 また、こんな感じで簡単に複数枚作ることもできるので寝ている間にCPUを酷使して大量生成するのも簡単です。 GPU でちゃんとモデルがのる環境だと、↓が1分程度で生成可能です。 CPUのみ物理4コアのマシンにて約40分で生成しました。100枚までまとめて生成可能なので夜数時間かけて生成するという使い方も可能です。 まとめ いま、画像生成の分野は非常に盛り上がっていると思います。ご興味を持った方は触ってみるといいのではないでしょうか？ 注記 ※1 メモリ4Gクラスの GPU でも動作させることができます。GTX1650で稼働することを確認しました。が、かなり遅くなるので、メモリ8G以上の GPU がお薦めです。 ※2 google colabだと、10s-20s程度です。 執筆： @miura.toshihiko 、レビュー： @higa （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 クラウド イノベーション センターの柴田です。 この記事は 電通国際情報サービス Advent Calendar 2022 の5日目の投稿です。 前日の記事は宮澤さんの「お金をかけずに AWS Certified SysOps Administrator - Associateに合格した話」でした。 さて、この記事ではArgo CDを使ってIstioをバージョンアップする方法を紹介します。 はじめに Istioとは Argo CDとは Istioをどうやってバージョンアップするか Argo CDを使ってIstioをバージョンアップする 想定する環境 環境を構築する Amazon EKS Argo CD Istio サンプルアプリケーション 手順1. Canary upgradeが可能か確認する 手順2. istio/base （CRDを含む）を更新する 手順3. 新しいバージョンの istio/istiod を追加する 手順4. データプレーンを更新する 手順5. istio/base の defaultRevision を更新する 手順6. istio/gateway を更新する 手順7. 古いバージョンの istio/istiod を削除する おわりに はじめに Istioとは Istio はサービスメッシュを実現する OSS の1つです。 サービスメッシュとは、マイクロサービスにおける トラフィック 管理、可観測性、セキュリティなどを、インフラスト ラク チャレイヤーで透過的に実現する仕組みです。 サービスメッシュがどんな課題を解決するものかは、以下のスライドが参考になります。 サービスメッシュは本当に必要なのか、何を解決するのか / Service meshes - Do we really need them? What problems do they solve? - Speaker Deck Istioはデータプレーンとコン トロール プレーンの2つの コンポーネント から構成されます。 データプレーン ： 実際にサービス間通信を行う部分です。 アプリケーションのプロキシとして Envoy を起動します （ サイドカー コンテナとして起動するケースが多いです）。 Envoyは トラフィック 管理、可観測性、セキュリティなどの機能を提供します。 コン トロール プレーン ： Envoyの設定を管理・更新します。 1 Istioのサポートポリシーは Supported Releases に定義されています。 概要は以下のとおりです。 4半期に1回、マイナーリリースを行う。 各マイナーリリースのサポート（＝セキュリティパッチの提供など）はN+2マイナーリリースの6週間後まで提供される。 例： v1.11 のサポートは v1.13.0 をリリースした6週間後まで提供される。 Argo CDとは Argo CD は Kubernetes 用の継続的デリバリーツールの1つです。 Argo CDは、git リポジトリ で管理された Kubernetes の マニフェスト の変更を、 Kubernetes クラスタ へデプロイします。 2 Argo CDは GitOps という手法に基づいています。 GitOpsはWeaveworks社が提唱した継続的デリバリー・継続的デプロイメントの方法であり、以下の特徴があります。 システム全体が宣言的に記述されていること。 マニフェスト がgitで管理され、それが信頼できる唯一の情報源（Single Source of Truth）であること。 承認された マニフェスト の変更が自動的にデプロイされること。またその際 Kubernetes クラスタ への認証情報を外部（例えばCIサーバなど）に持たせる必要がないこと。 マニフェスト と Kubernetes クラスタ の間に差分がある場合、それを検知したり、自動的に修正したりできること。 Istioをどうやってバージョンアップするか 先述した通りIstioの各マイナーリリースはリリースから約6〜8ヶ月後にサポートが終了します。 そのため定期的にIstioをバージョンアップする必要があります。 公式ドキュメント には以下の3つのバージョンアップ方法が紹介されています。 istioctl を使ってIn-place upgradeする方法 istioctl を使ってCanary upgradeする方法 Helmを使ってCanary upgradeする方法（α版） なお、In-place upgradeの場合、バージョンアップ前後のバージョン差異は1マイナーリリース以内である必要があります。 3 また、Canary upgradeの場合、バージョンアップ前後のバージョン差異は2マイナーリリース以内であることが推奨されています。 4 実案件の多くは、 Kubernetes マニフェスト のデプロイを、Argo CDなどの継続的デリバリーツールを使って行います。 しかし、上述のドキュメントでは、 Kubernetes クラスタ 管理者が手元からコマンドを実行してバージョンアップする方法しか紹介されていません。 そこで本記事では、Argo CDを使ってIstioをバージョンアップする方法を紹介します。 今回は以下の理由から方法3をベースとします。 公式ドキュメントではIn-place upgradeよりもCanary upgradeを推奨しているため。 5 Argo CDをはじめ 6 、多くの継続的デリバリーツールがHelmをサポートしているため。 Argo CDを使ってIstioをバージョンアップする 想定する環境 本記事では以下の環境を前提とします。 Amazon EKS v1.23 Argo CD v2.4.14 Istio v1.13.4 → v1.15.3 またサンプルアプリケーションとしてIstio公式のサンプルアプリケーションである Bookinfoアプリケーション がデプロイされているものとします。 環境を構築する Amazon EKS Amazon EKS クラスタ を構築します。 本記事では詳細な手順は割愛します。 詳しくは Amazon EKS クラスターの作成 - Amazon EKS をご参照ください。 Argo CD Kubernetes クラスタ へArgo CDをデプロイします。 本記事では詳細な手順は割愛します。 詳しくは以下の公式ドキュメントをご参照ください。 Getting Started - Argo CD - Declarative GitOps CD for Kubernetes Installation - Argo CD - Declarative GitOps CD for Kubernetes Istio IstioのHelm chartは以下の3つを使用します。 istio/base istio/istiod istio/gateway 本記事では以下の手順で Kubernetes クラスタ にIstio v1.13.4がインストールされているものとします。 必要なnamespaceを作成します。 $ kubectl create namespace istio-system $ kubectl create namespace istio-ingress istio-ingress namespaceに automatic sidecar injection を有効にするためのlabelを設定します。 $ kubectl label namespace istio-ingress istio-injection=enabled 以下のArgo CDのApplication CRを kubectl apply コマンドでデプロイします。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-base namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : base targetRevision : 1.13.4 helm : releaseName : istio-base destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : ValidatingWebhookConfiguration name : istiod-default-validator jsonPointers : - /webhooks/0/failurePolicy --- apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istiod namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : istiod targetRevision : 1.13.4 helm : releaseName : istiod destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : MutatingWebhookConfiguration name : istio-sidecar-injector jsonPointers : - /webhooks/0/clientConfig/caBundle - /webhooks/1/clientConfig/caBundle - /webhooks/2/clientConfig/caBundle - /webhooks/3/clientConfig/caBundle --- apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-ingress namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : gateway targetRevision : 1.13.4 helm : releaseName : istio-ingress destination : server : https://kubernetes.default.svc namespace : istio-ingress 上述のApplication CRについてArgo CDのWeb UIからsyncを実行してIstioをデプロイします。 syncは istio-base → istiod → istio-ingress の順に実行します。 本記事ではArgo CDのWeb UIのアクセス方法および操作方法に関する説明は割愛します。詳細は Argo CDの公式ドキュメント をご参照ください。 サンプルアプリケーション 本記事ではサンプルアプリケーションとして default namespaceにIstio公式のサンプルアプリケーションである Bookinfoアプリケーション がデプロイされているものとします。 default namespaceに automatic sidecar injection を有効にするためのlabelを設定します。 $ kubectl label namespace default istio-injection=enabled Bookinfoアプリケーション をデプロイします。 $ kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.13.4/samples/bookinfo/platform/kube/bookinfo.yaml $ kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.13.4/samples/bookinfo/networking/bookinfo-gateway.yaml $ kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.13.4/samples/bookinfo/networking/destination-rule-all.yaml Gateway bookinfo-gateway の .spec.selector を istio=ingressgateway から istio=ingress へ変更します。 $ kubectl patch gateways.networking.istio.io bookinfo-gateway --type=merge -p '{"spec":{"selector":{"istio":"ingress"}}}' 手順1. Canary upgradeが可能か確認する 以下の条件を満たしているか確認します。 Istioのバージョンアップ前後のバージョン差異が2マイナーリリース以内であること。 例えば、現在のバージョンが 1.13.x の場合、 1.14.x と 1.15.x へバージョンアップできます。 istio/base 、 istio/gateway 、CRDに破壊的変更がないこと。 これらのリソースはバージョンアップ前後で共有されるためです。 istio/istiod がバージョンアップ前後で独立しており同じリソースを共有しないこと。 古いバージョンの istio/istiod を安全に削除するためです。 なお istio/istiod のパラメータ revision にはバージョンアップ前後で異なる値を設定します。 kubectl rollout restart コマンドでアプリケーションのPodを安全に再作成できること。 PodがGraceful Shutdownするよう実装・設定されているか。 PodのUpdate strategyが適切に設定されているか。 以下の手順でバージョンアップ前後の互換性が確認できていること。 更新後のバージョンの istioctl を GitHubのリリース からダウンロードする。 istioctl x precheck コマンドを実行して互換性を確認する。 $ istioctl x precheck ✔ No issues found when checking the cluster. Istio is safe to install or upgrade! To get started, check out <https://istio.io/latest/docs/setup/getting-started/> 手順2. istio/base （CRDを含む）を更新する Application CR istio-base の targetRevision を更新します。これによりCRDなどが更新されます。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-base namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : base targetRevision : 1.15.3 helm : releaseName : istio-base destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : ValidatingWebhookConfiguration name : istiod-default-validator jsonPointers : - /webhooks/0/failurePolicy 本来、 helm upgrade コマンドや helm uninstall コマンドでhelm chartを更新/削除しても、CRDは更新/削除されません。 7 ただし、Argo CDは helm template で生成した マニフェスト を kubectl apply しているため、Helm chartを更新することで、CRDを更新できます。 手順3. 新しいバージョンの istio/istiod を追加する 新しいバージョンの istio/istiod のApplication CRをデプロイします。 このとき、以下のフィールドは更新後のバージョンにあわせて変更します。 .metadata.name .spec.source.targetRevision .spec.source.helm.values の revision (*1) .spec.ignoreDifferences 8 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istiod-1-15-3 namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : istiod targetRevision : 1.15.3 helm : releaseName : istiod values : | revision : "1-15-3" destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : MutatingWebhookConfiguration name : istio-sidecar-injector-1-15-3 jsonPointers : - /webhooks/0/clientConfig/caBundle - /webhooks/1/clientConfig/caBundle istio-system namespaceに新しいバージョンの istiod が作成されたことを確認します。 $ kubectl -n istio-system get pods,svc,mutatingwebhookconfigurations NAME READY STATUS RESTARTS AGE pod/istiod-1-15-3-59d4cf9474-gklrs 1/1 Running 0 11s pod/istiod-579df55f96-n4tk8 1/1 Running 0 21m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/istiod ClusterIP 172.20.91.227 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 21m service/istiod-1-15-3 ClusterIP 172.20.213.98 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 11s NAME WEBHOOKS AGE mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector 4 21m mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector-1-15-3 2 11s mutatingwebhookconfiguration.admissionregistration.k8s.io/pod-identity-webhook 1 38m mutatingwebhookconfiguration.admissionregistration.k8s.io/vpc-resource-mutating-webhook 1 37m 手順4. データプレーンを更新する アプリケーションのPodの サイドカー コンテナとして起動しているEnvoy（以降では istio-proxy と呼びます）を更新します。 今回は automatic sidecar injection を有効にしているため、 istio-proxy はPod作成時に サイドカー コンテナとして自動的に追加されます。 この場合、 automatic sidecar injection が有効なnamespaceについて、namespaceのlabelを更新した後、Podを再作成することで、 istio-proxy を更新できます。 今回対象となるnamespaceは以下の2つです。 default namespace istio-ingress namespace まず default namespaceに対して以下の手順を実施します。 現在の istio-proxy の状態を確認します。 $ istioctl -n default proxy-status NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION details-v1-6bd666858f-wq2fr.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 productpage-v1-7f6655c647-s8gdf.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 ratings-v1-7cc7df5fd5-slqgd.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 reviews-v1-68c7d56667-nvv5q.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 reviews-v2-759496d8df-gkgdh.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 reviews-v3-7545ff7c75-68n7b.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 namespaceのlabelを更新します。 istio.io/rev=<(*1)と同じ文字列> labelを設定します。 istio-injection labelが存在する場合は削除します。 $ kubectl label namespace default istio.io/rev=1-15-3 $ kubectl label namespace default istio-injection- 先程のnamespaceのPodを再作成します。 $ kubectl -n default rollout restart deployment 変更後の istio-proxy の状態を確認します。 特に ISTIOD 列と VERSION 列が新しくなっていることを確認します。 $ istioctl proxy-status NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION details-v1-5954bb9d8-xn5j6.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 productpage-v1-7f6bff5ddd-ms4b4.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 ratings-v1-6f8d5bf8d4-f2jmm.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 reviews-v1-785b65d7c4-6j4wq.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 reviews-v2-86b446779b-9wx5q.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 reviews-v3-5b5b976fbb-cc2j9.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 次に istio-ingress namespaceに対しても同様の手順を実施します。 default namespaceと同じ内容のため詳細は割愛します。 Canary upgradeではこのようにnamespace単位で徐々にデータプレーンを更新できます。 また、もし問題が発生した場合はnamespaceのlabelをもとに戻してPodを再作成することでデータプレーンの更新を ロールバック できます。 手順5. istio/base の defaultRevision を更新する Application CR istio-base の .spec.source.helm.values の defaultRevision を(*1)と同じ文字列へ更新します。 これによりValidatingWebhookConfiguration istiod-default-validator の宛先が古いバージョンの istiod から新しいバージョンの istiod へ変更されます。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-base namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : base targetRevision : 1.15.3 helm : releaseName : istio-base values : | defaultRevision : "1-15-3" destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : ValidatingWebhookConfiguration name : istiod-default-validator jsonPointers : - /webhooks/0/failurePolicy 手順6. istio/gateway を更新する Application CR istio-ingress の targetRevision を更新します。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-ingress namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : gateway targetRevision : 1.15.3 helm : releaseName : istio-ingress destination : server : https://kubernetes.default.svc namespace : istio-ingress 手順7. 古いバージョンの istio/istiod を削除する 古いバージョンの istio/istiod のApplication CRにfinalizerを設定します。 Application CRの削除と同時に関連するリソースを削除するためです。 9 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istiod namespace : argocd finalizers : - resources-finalizer.argocd.argoproj.io spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : istiod targetRevision : 1.13.4 helm : releaseName : istiod destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : MutatingWebhookConfiguration name : istio-sidecar-injector jsonPointers : - /webhooks/0/clientConfig/caBundle - /webhooks/1/clientConfig/caBundle - /webhooks/2/clientConfig/caBundle - /webhooks/3/clientConfig/caBundle 古いバージョンの istio/istiod のApplication CRを削除します。 istio-system namespaceから古いバージョンの istio/istiod が削除されたことを確認します。 $ kubectl -n istio-system get pods,svc,mutatingwebhookconfigurations NAME READY STATUS RESTARTS AGE pod/istiod-1-15-3-59d4cf9474-gklrs 1/1 Running 0 6m1s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/istiod-1-15-3 ClusterIP 172.20.213.98 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 6m1s NAME WEBHOOKS AGE mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector-1-15-3 2 6m1s mutatingwebhookconfiguration.admissionregistration.k8s.io/pod-identity-webhook 1 43m mutatingwebhookconfiguration.admissionregistration.k8s.io/vpc-resource-mutating-webhook 1 43m おわりに この記事ではArgo CDを使ってIstioをバージョンアップする方法を紹介しました。 バージョンアップはシステムをセキュアな状態に維持するために欠かせない作業です。 一方でIstioのバージョンアップは、サービスメッシュ上の全アプリケーションに影響のある作業でもあります。 安全かつ効率的なバージョンアップ方法を確立していきたいですね。 最後までお読みいただき、ありがとうございました。 私たちは同じチームで働いてくれる仲間を探しています。 クラウド アーキテクトの業務に興味がある方のご応募をお待ちしています。 クラウドアーキテクト 執筆： @shibata.takao 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ） 図は https://istio.io/latest/about/service-mesh/ より引用しました。 ↩ 図は https://argo-cd.readthedocs.io/en/stable/ より引用しました。 ↩ 詳細は https://istio.io/latest/docs/setup/upgrade/in-place/#upgrade-prerequisites をご参照ください。 ↩ 詳細は https://istio.io/latest/docs/setup/upgrade/canary/#before-you-upgrade をご参照ください。 ↩ 詳細は https://istio.io/latest/docs/setup/upgrade/in-place/ をご参照ください。 ↩ 詳細は https://argo-cd.readthedocs.io/en/stable/user-guide/helm/ をご参照ください。 ↩ 詳細は https://helm.sh/docs/chart_best_practices/custom_resource_definitions/ をご参照ください。 ↩ 詳細は https://argo-cd.readthedocs.io/en/stable/user-guide/diffing/ をご参照ください。 ↩ 詳細は https://argo-cd.readthedocs.io/en/stable/user-guide/app_deletion/ をご参照ください。 ↩