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

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

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

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

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

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

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回のテーマは バベルの塔 のイラストです。 今回は建物のイラストの呪文を学びましょう。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 steampunk illustration of babel tower highly detailed shot from above steampunk illustration of babel tower shot from below steampunk illustration of babel tower highly detailed steampunk illustration of illuminated babel tower highly detailed top shot from below night まとめ 仲間募集 Stable Diffusionの過去コンテンツ steampunk illustration of babel tower highly detailed shot from above steampunkは、 蒸気機関 が高度に発達したレトロなアニメの世界を召喚する呪文です。詳しく知りたい方は 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 を参照してください。 steampunkのイラストは、通常のイラストより、クオリティが高いことが多いため、描画対象がsteampunkの世界観にあっているときは、積極的に利用しましょう。 babel towerが バベルの塔 です。 highly detailedで、描画対象を詳細に描画します。 shot from aboveで、上の方から描画します。 建物は、一般的に地味であることが多い（ バベルの塔 は派手ですが）ので、建物を描画するときは、通常と違うアングルを選びましょう。人は見たことのないものに心惹かれます。 特に高い建物を上から描画するためには、カメラを空中に配置する必要があります。ほとんどの人にとってリアルに体験したことのないアングルです。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower highly detailed shot from above artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower highly detailed shot from above artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 steampunkをつけていない通常のイラスト これも良いですね。ただ、これを出力するのに、何十回もトライしました。 steampunk illustration of babel tower shot from below shot from belowで下から描画します。highly detailedがないことに注目してください。下から描画する場合、highly detailedがあると、 バベルの塔 に近づきすぎて、うまく描画できません。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower shot from below artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower shot from below artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 shot from belowで塔を描画する場合、空が描画されます。空のクオリティが高いこともチェックポイントに入れてください。 highly detailed shot from belowの出力結果 highly detailedで バベルの塔 に近づきすぎているので、shot from belowの呪文の効果がほとんどないことがわかります。 steampunk illustration of babel tower highly detailed 今度は、shot from aboveもshot from belowもない、通常アングルのイラストも見てみましょう。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 highly detailed shot from belowのものとほとんど同じですね。これが通常のアングルです。 shot from aboveとshot from belowの画像と比較して、アングルの違いを実感しましょう。 steampunk illustration of illuminated babel tower highly detailed top shot from below night 応用もやっておきましょう。 建物にilluminatedで照明を当てて、時間を夜（night）にしてみましょう。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of illuminated babel tower highly detailed shot from below night artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of illuminated babel tower highly detailed shot from below night artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 まとめ 今回は、建物のイラストを退屈なものにしないために、shot from above（上から描画）、shot from below（下から描画）の呪文を学びました。 次回は、 美少女アニメ画改善版編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの過去コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回のテーマは バベルの塔 のイラストです。 今回は建物のイラストの呪文を学びましょう。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 steampunk illustration of babel tower highly detailed shot from above steampunk illustration of babel tower shot from below steampunk illustration of babel tower highly detailed steampunk illustration of illuminated babel tower highly detailed top shot from below night まとめ 仲間募集 Stable Diffusionの過去コンテンツ steampunk illustration of babel tower highly detailed shot from above steampunkは、 蒸気機関 が高度に発達したレトロなアニメの世界を召喚する呪文です。詳しく知りたい方は 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 を参照してください。 steampunkのイラストは、通常のイラストより、クオリティが高いことが多いため、描画対象がsteampunkの世界観にあっているときは、積極的に利用しましょう。 babel towerが バベルの塔 です。 highly detailedで、描画対象を詳細に描画します。 shot from aboveで、上の方から描画します。 建物は、一般的に地味であることが多い（ バベルの塔 は派手ですが）ので、建物を描画するときは、通常と違うアングルを選びましょう。人は見たことのないものに心惹かれます。 特に高い建物を上から描画するためには、カメラを空中に配置する必要があります。ほとんどの人にとってリアルに体験したことのないアングルです。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower highly detailed shot from above artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower highly detailed shot from above artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 steampunkをつけていない通常のイラスト これも良いですね。ただ、これを出力するのに、何十回もトライしました。 steampunk illustration of babel tower shot from below shot from belowで下から描画します。highly detailedがないことに注目してください。下から描画する場合、highly detailedがあると、 バベルの塔 に近づきすぎて、うまく描画できません。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower shot from below artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower shot from below artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 shot from belowで塔を描画する場合、空が描画されます。空のクオリティが高いこともチェックポイントに入れてください。 highly detailed shot from belowの出力結果 highly detailedで バベルの塔 に近づきすぎているので、shot from belowの呪文の効果がほとんどないことがわかります。 steampunk illustration of babel tower highly detailed 今度は、shot from aboveもshot from belowもない、通常アングルのイラストも見てみましょう。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 highly detailed shot from belowのものとほとんど同じですね。これが通常のアングルです。 shot from aboveとshot from belowの画像と比較して、アングルの違いを実感しましょう。 steampunk illustration of illuminated babel tower highly detailed top shot from below night 応用もやっておきましょう。 建物にilluminatedで照明を当てて、時間を夜（night）にしてみましょう。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of illuminated babel tower highly detailed shot from below night artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of illuminated babel tower highly detailed shot from below night artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 まとめ 今回は、建物のイラストを退屈なものにしないために、shot from above（上から描画）、shot from below（下から描画）の呪文を学びました。 次回は、 美少女アニメ画改善版編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの過去コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

はいどーもー！ X イノベーション 本部の宮澤響です！ X イノベーション 本部では、有志メンバーで論文輪読会を月次開催しています。 （詳細は こちらの記事 をご参照ください） 本記事では、私が担当した先日の論文輪読会で紹介した論文について、箇条書きベースでごくごく簡単にまとめます！ どんな論文？ 論文内容紹介 目的 手法 実験参加者 実験に用いたテキスト 実験手順 結果 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 考察 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 限界と今後の課題 結論 個人的な感想など この論文を題材に選んだきっかけ 論文内容に関して まとめ どんな論文？ 書誌情報は以下です。 Anam Ahmad Khan, Sadia Nawaz, Joshua Newn, Ryan M. Kelly, Jason M. Lodge, James Bailey, and Eduardo Velloso. 2022. To type or to speak? The efect of input modality on text understanding during note-taking. In CHI Conference on Human Factors in Computing Systems (CHI ’22), April 29-May 5, 2022, New Orleans, LA, USA. ACM , New York, NY, USA, 15 pages. https://doi.org/10.1145/3491102.3501974 一言で言えば、ノートのとり方（キーボードと音声のどちらでノートをとるか）が文章理解に与える影響について検討した論文です。 論文の全体像を1枚にまとめたスライドがこちらです。 なお、こちらは「落合メソッド」「落合フォーマット」などと呼ばれる論文のまとめ方（ 参考 ）を簡略化したものです。 論文内容紹介 ここから実際に論文の内容を大まかなセクションごとに紹介します。 目的 以下のリサーチク エス チョン（以下、RQ）を明らかにすることを目的としています。 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 手法 2つのテキストに対してキーボードまたは音声でノートをとってもらい、テキストの内容についての理解度テストを実施するという実験を実施しました。 実験参加者 実験参加者は、以下のような属性をもつ、オーストラリアの大学院生60名でした。 属性 内訳 年齢 21～35歳（平均年齢27.04歳） 性別 男性31名、女性29名 母語 英語16名、イタリア語3名、中国語15名、 ウルドゥー語 4名、 ヒンディー語 5名、 ペルシャ語 7名、 シンハラ語 6名、韓国語2名 学歴 修士 課程在籍者29名、博士課程在籍者31名 実験に用いたテキスト 実験には、以下の2つのテキストを使用しました。 ブレーキに関する英語の文章（792語） ポンプに関する英語の文章（850語） 実験手順 実験は、全てオンラインで、下図のような流れで実施されました。 Briefing・Demo 実験の説明 ノートをとる操作の実演、練習 Pre-test テキストに関する予備知識を測定するためのテスト 多肢選択問題6問 4つの正答候補＋“I don’t know”の計5択 Note taking task テキストを読んでノートをとるタスク 2つのConditionで異なるテキストを使用 ブレーキ ポンプ 2つのConditionで異なる入力形式を利用 キーボード 音声 時間制限なし Survey 主観的な項目として以下を報告 確信度 Post-testで正答できる自信がどれくらいあるか（0～100） 関心度 テキストの内容にどれくらい関心をもてるか（1～7） 難易度 テキストの内容がどれくらい難しいと感じるか（1～7） Distracting task 指定された数から7ずつ減算していく過程を報告するタスク 2分間 Condition1では200から 200、193、186、… Condition2では203から 203、196、189、… Post-test テキストの理解度を測定するためのテスト 事実問題12問（多肢選択） 1つのア イデア ユニット（「軽自動車はこの種類をブレーキを使っている」、「この村ではこのポンプが使われている」などの「○○が××だ」のような命題の単位）に関する問題 4つの正答候補＋“I don’t know”の計5択 推論問題6問（多肢選択） 2つ以上のア イデア ユニットに関する問題 4つの正答候補＋“I don’t know”の計5択 Interview・Debrief 操作感などに関するインタビュー 全体のまとめ 結果 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ キーボードでノートをとった場合と音声でノートをとった場合のPost-testの成績（以下、成績）の間に有意差は見られませんでした。 ノートのとり方（キーボード、音声）と問題種別（事実問題、推論問題）の間の交互作用が有意でした。そのため、一対比較を実施したところ、以下の結果が得られました。 ノートのとり方に関して キーボード：事実問題の成績が推論問題の成績よりも有意に高い 音声：事実問題と推論問題の成績の間に有意差なし 問題種別に関して 事実問題：キーボードと音声の成績の間に有意差なし 推論問題：音声の成績がキーボードの成績よりも有意に高い RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ 音声でとったノートに含まれるア イデア ユニットの数が、キーボードでとったノートに含まれるア イデア ユニットの数よりも有意に多いことが分かりました。 音声でとったノートに含まれるエラボレーション（例、類推、個人的な経験）の数が、キーボードでとったノートに含まれるエラボレーションの数よりも有意に多いことが分かりました。 ノートのとり方が成績に与える直接効果は有意であることが分かりました。 ア イデア ユニットの数を媒介としてノートのとり方が成績に与える間接効果は有意であることが分かりました。 エラボレーションの数を媒介としてノートのとり方が成績に与える間接効果は有意ではないことが分かりました。 RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ キーボードでノートをとった場合と音声でノートをとった場合のメタ理解の正確性（確信度と成績の差の絶対値）の間に有意差は見られませんでした。 RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 参加者の意見をグルーピングした結果、以下のように6カテゴリーの利点と5カテゴリーの課題が浮かび上がりました。 利点 簡便な入力 瞬間的な思考の記録 共同的なノート作成 リハーサルと エンコード 内容への注意 能動的な説明と反映 課題 録音と再生 編集 検索と見直し 構造化とスケッチ 共有空間での利用 考察 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ 音声でノートをとることは、テキストの情報に基づく推論を手助けし、情報を横断してア イデア やコンセプトを結びつけている可能性が示唆されました。 推論問題では複数のア イデア ユニットを結びつける必要があり、テキストに対する概念的な理解が試される可能性が示唆されました。 音声でとったノートに関して、「音声でとったノートはより多くのア イデア ユニットを議論できる→ノートをとりながらテキストについてより良い推論を行える→テキストに対する概念的理解が深まる→推論問題の成績が高くなる」という一連の流れが示唆されました。 RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ 音声でノートをとる際は人称直示詞（人称代名詞）を多く使用するため、仮想の聴衆に話しかけるような、社会的関与が高い内容になる可能性が示唆されました。 社会的関与の高さがより多くのア イデア ユニットの議論とエラボレーションに繋がる可能性が示唆されました。 RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ 音声でノートをとることは、テキストに対する概念的理解を増加させても、学習パフォーマンスの知覚には影響を与えない可能性が示唆されました。 RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 仮想の聴衆に話しかけることで豊かな表現が生まれる可能性が示唆されました。 テキストを読みながら同時にノートをとれるため、学習内容自体に注意を向けやすい可能性が示唆されました。 音声でノートをとることのメリットは、ノートを見直すときよりもノートをとるときの方がより明確になる可能性が示唆されました。 音声でとるノートの利便性はデジタル学習環境で発揮されやすい可能性が示唆されました。 限界と今後の課題 実験の限界と、そこから考えられる今後検討すべき課題は以下のとおりです。 限界 課題 実験に使用したテキストがやや複雑（難易度が高い）だと認識されていた より複雑でないテキストに対して一般化されるかの調査 ノートのとり方が文章理解に与える短期的な影響を調査するに留まった より長期的な影響の調査 キーボードと音声で見直しに要する時間が異なり交絡因子となるおそれがあるため、Post-testの前にノートを見直す時間を設定しなかった 入力（キーボード／音声）と出力（文章／音声）の組み合わせによる実験 大学院生を対象として管理された環境で実施した 異なる参加者集団や、より現実的な環境での実験 音声でとるノートは空間的な構造化を必要としない情報のみしか記録できない 数式や マインドマップ など、視覚的な表現が有効な場合の調査 結論 ノートをとる際の入力形式をキーボードから音声へ変更することで、より多くのア イデア ユニットの議論とエラボレーションを行える可能性が示唆されました。 基本的な知識を得ることが目的であれば、キーボードと音声どちらでノートをとった場合も同じようなパフォーマンスを示す可能性が示唆されました。 推論することによってより深く概念を理解することが目的であれば、音声でノートをとる方がより効果的である可能性が示唆されました。 キーボードと音声どちらでノートをとった場合も、文章理解におけるメタ理解の判断には同程度の効果をもたらす可能性が示唆されました。 音声でとるノートはデジタルテキストの概念的な理解を可能にするため、デジタル学習環境に組み込める可能性が示唆されました。 個人的な感想など この論文を題材に選んだきっかけ この論文を題材に選んだ理由としては、タイトルに惹かれたというのが大きいです。 というのも、私は教育関係の事柄に強い興味をもっています。 また、私は学生時代（ほんの2年半前ですが）、音や音楽に関する研究をしていました。 そのため、「ノートをとる」という部分が私の教育センサーに、「音声」の部分が私の音・音楽センサーに引っかかり、 アブスト ラク トに目を通しても面白そうな内容だったので、今回の論文輪読会の題材としました。 論文内容に関して いわゆる典型的なIMRAD形式（ 参考 ）だったこともあり、論文の構成が分かりやすかったです。 また、なるほど確かにと思える部分が多かったです。 例えば、音声でノートをとる場合はテキストから視線を逸らさずにノートをとれる、音声でとったノートは編集、検索、見直しに課題がある、などは、確かにそうだなぁという感覚でした。 疑問点として、「社会的関与の高さがより多くのア イデア ユニットの議論とエラボレーションに繋がる」というのは、日本語の場合でも同様なのか気になりました。 これは、日本語は英語と違い主語や目的語を省略できるため、理由として考察されていた人称直示詞があまり登場しないのでは、と思ったためです。 まとめ 本記事では、論文輪読会で私が紹介した論文について簡単にまとめました。 論文輪読会は、知見のインプットとアウトプット、両者の力を伸ばせる取り組みですので、皆さんの会社や部署などでも実施してみてはいかがでしょうか？ 最後までお読みいただき、本当にありがとうございました！ 私たちは同じグループで共に働いていただける仲間を募集しています。 現在募集している職種は以下です。 ソリューションアーキテクト 論文輪読会をはじめとした各種勉強会に気軽に参加できるような環境で働くことに興味のある皆様、ぜひご応募お待ちしています！ 執筆： @miyazawa.hibiki 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

はいどーもー！ X イノベーション 本部の宮澤響です！ X イノベーション 本部では、有志メンバーで論文輪読会を月次開催しています。 （詳細は こちらの記事 をご参照ください） 本記事では、私が担当した先日の論文輪読会で紹介した論文について、箇条書きベースでごくごく簡単にまとめます！ どんな論文？ 論文内容紹介 目的 手法 実験参加者 実験に用いたテキスト 実験手順 結果 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 考察 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 限界と今後の課題 結論 個人的な感想など この論文を題材に選んだきっかけ 論文内容に関して おわりに どんな論文？ 書誌情報は以下です。 Anam Ahmad Khan, Sadia Nawaz, Joshua Newn, Ryan M. Kelly, Jason M. Lodge, James Bailey, and Eduardo Velloso. 2022. To type or to speak? The efect of input modality on text understanding during note-taking. In CHI Conference on Human Factors in Computing Systems (CHI ’22), April 29-May 5, 2022, New Orleans, LA, USA. ACM , New York, NY, USA, 15 pages. https://doi.org/10.1145/3491102.3501974 一言で言えば、ノートのとり方（キーボードと音声のどちらでノートをとるか）が文章理解に与える影響について検討した論文です。 論文の全体像を1枚にまとめたスライドがこちらです。 なお、こちらは「落合メソッド」「落合フォーマット」などと呼ばれる論文のまとめ方（ 参考 ）を簡略化したものです。 論文内容紹介 ここから実際に論文の内容を大まかなセクションごとに紹介します。 目的 以下のリサーチク エス チョン（以下、RQ）を明らかにすることを目的としています。 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 手法 2つのテキストに対してキーボードまたは音声でノートをとってもらい、テキストの内容についての理解度テストを実施するという実験を実施しました。 実験参加者 実験参加者は、以下のような属性をもつ、オーストラリアの大学院生60名でした。 属性 内訳 年齢 21～35歳（平均年齢27.04歳） 性別 男性31名、女性29名 母語 英語16名、イタリア語3名、中国語15名、 ウルドゥー語 4名、 ヒンディー語 5名、 ペルシャ語 7名、 シンハラ語 6名、韓国語2名 学歴 修士 課程在籍者29名、博士課程在籍者31名 実験に用いたテキスト 実験には、以下の2つのテキストを使用しました。 ブレーキに関する英語の文章（792語） ポンプに関する英語の文章（850語） 実験手順 実験は、全てオンラインで、下図のような流れで実施されました。 Briefing・Demo 実験の説明 ノートをとる操作の実演、練習 Pre-test テキストに関する予備知識を測定するためのテスト 多肢選択問題6問 4つの正答候補＋“I don’t know”の計5択 Note taking task テキストを読んでノートをとるタスク 2つのConditionで異なるテキストを使用 ブレーキ ポンプ 2つのConditionで異なる入力形式を利用 キーボード 音声 時間制限なし Survey 主観的な項目として以下を報告 確信度 Post-testで正答できる自信がどれくらいあるか（0～100） 関心度 テキストの内容にどれくらい関心をもてるか（1～7） 難易度 テキストの内容がどれくらい難しいと感じるか（1～7） Distracting task 指定された数から7ずつ減算していく過程を報告するタスク 2分間 Condition1では200から 200、193、186、… Condition2では203から 203、196、189、… Post-test テキストの理解度を測定するためのテスト 事実問題12問（多肢選択） 1つのア イデア ユニット（「軽自動車はこの種類をブレーキを使っている」、「この村ではこのポンプが使われている」などの「○○が××だ」のような命題の単位）に関する問題 4つの正答候補＋“I don’t know”の計5択 推論問題6問（多肢選択） 2つ以上のア イデア ユニットに関する問題 4つの正答候補＋“I don’t know”の計5択 Interview・Debrief 操作感などに関するインタビュー 全体のまとめ 結果 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ キーボードでノートをとった場合と音声でノートをとった場合のPost-testの成績（以下、成績）の間に有意差は見られませんでした。 ノートのとり方（キーボード、音声）と問題種別（事実問題、推論問題）の間の交互作用が有意でした。そのため、一対比較を実施したところ、以下の結果が得られました。 ノートのとり方に関して キーボード：事実問題の成績が推論問題の成績よりも有意に高い 音声：事実問題と推論問題の成績の間に有意差なし 問題種別に関して 事実問題：キーボードと音声の成績の間に有意差なし 推論問題：音声の成績がキーボードの成績よりも有意に高い RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ 音声でとったノートに含まれるア イデア ユニットの数が、キーボードでとったノートに含まれるア イデア ユニットの数よりも有意に多いことが分かりました。 音声でとったノートに含まれるエラボレーション（例、類推、個人的な経験）の数が、キーボードでとったノートに含まれるエラボレーションの数よりも有意に多いことが分かりました。 ノートのとり方が成績に与える直接効果は有意であることが分かりました。 ア イデア ユニットの数を媒介としてノートのとり方が成績に与える間接効果は有意であることが分かりました。 エラボレーションの数を媒介としてノートのとり方が成績に与える間接効果は有意ではないことが分かりました。 RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ キーボードでノートをとった場合と音声でノートをとった場合のメタ理解の正確性（確信度と成績の差の絶対値）の間に有意差は見られませんでした。 RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 参加者の意見をグルーピングした結果、以下のように6カテゴリーの利点と5カテゴリーの課題が浮かび上がりました。 利点 簡便な入力 瞬間的な思考の記録 共同的なノート作成 リハーサルと エンコード 内容への注意 能動的な説明と反映 課題 録音と再生 編集 検索と見直し 構造化とスケッチ 共有空間での利用 考察 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ 音声でノートをとることは、テキストの情報に基づく推論を手助けし、情報を横断してア イデア やコンセプトを結びつけている可能性が示唆されました。 推論問題では複数のア イデア ユニットを結びつける必要があり、テキストに対する概念的な理解が試される可能性が示唆されました。 音声でとったノートに関して、「音声でとったノートはより多くのア イデア ユニットを議論できる→ノートをとりながらテキストについてより良い推論を行える→テキストに対する概念的理解が深まる→推論問題の成績が高くなる」という一連の流れが示唆されました。 RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ 音声でノートをとる際は人称直示詞（人称代名詞）を多く使用するため、仮想の聴衆に話しかけるような、社会的関与が高い内容になる可能性が示唆されました。 社会的関与の高さがより多くのア イデア ユニットの議論とエラボレーションに繋がる可能性が示唆されました。 RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ 音声でノートをとることは、テキストに対する概念的理解を増加させても、学習パフォーマンスの知覚には影響を与えない可能性が示唆されました。 RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 仮想の聴衆に話しかけることで豊かな表現が生まれる可能性が示唆されました。 テキストを読みながら同時にノートをとれるため、学習内容自体に注意を向けやすい可能性が示唆されました。 音声でノートをとることのメリットは、ノートを見直すときよりもノートをとるときの方がより明確になる可能性が示唆されました。 音声でとるノートの利便性はデジタル学習環境で発揮されやすい可能性が示唆されました。 限界と今後の課題 実験の限界と、そこから考えられる今後検討すべき課題は以下のとおりです。 限界 課題 実験に使用したテキストがやや複雑（難易度が高い）だと認識されていた より複雑でないテキストに対して一般化されるかの調査 ノートのとり方が文章理解に与える短期的な影響を調査するに留まった より長期的な影響の調査 キーボードと音声で見直しに要する時間が異なり交絡因子となるおそれがあるため、Post-testの前にノートを見直す時間を設定しなかった 入力（キーボード／音声）と出力（文章／音声）の組み合わせによる実験 大学院生を対象として管理された環境で実施した 異なる参加者集団や、より現実的な環境での実験 音声でとるノートは空間的な構造化を必要としない情報のみしか記録できない 数式や マインドマップ など、視覚的な表現が有効な場合の調査 結論 ノートをとる際の入力形式をキーボードから音声へ変更することで、より多くのア イデア ユニットの議論とエラボレーションを行える可能性が示唆されました。 基本的な知識を得ることが目的であれば、キーボードと音声どちらでノートをとった場合も同じようなパフォーマンスを示す可能性が示唆されました。 推論することによってより深く概念を理解することが目的であれば、音声でノートをとる方がより効果的である可能性が示唆されました。 キーボードと音声どちらでノートをとった場合も、文章理解におけるメタ理解の判断には同程度の効果をもたらす可能性が示唆されました。 音声でとるノートはデジタルテキストの概念的な理解を可能にするため、デジタル学習環境に組み込める可能性が示唆されました。 個人的な感想など この論文を題材に選んだきっかけ この論文を題材に選んだ理由としては、タイトルに惹かれたというのが大きいです。 というのも、私は教育関係の事柄に強い興味をもっています。 また、私は学生時代（ほんの2年半前ですが）、音や音楽に関する研究をしていました。 そのため、「ノートをとる」という部分が私の教育センサーに、「音声」の部分が私の音・音楽センサーに引っかかり、 アブスト ラク トに目を通しても面白そうな内容だったので、今回の論文輪読会の題材としました。 論文内容に関して いわゆる典型的なIMRAD形式（ 参考 ）だったこともあり、論文の構成が分かりやすかったです。 また、なるほど確かにと思える部分が多かったです。 例えば、音声でノートをとる場合はテキストから視線を逸らさずにノートをとれる、音声でとったノートは編集、検索、見直しに課題がある、などは、確かにそうだなぁという感覚でした。 疑問点として、「社会的関与の高さがより多くのア イデア ユニットの議論とエラボレーションに繋がる」というのは、日本語の場合でも同様なのか気になりました。 これは、日本語は英語と違い主語や目的語を省略できるため、理由として考察されていた人称直示詞があまり登場しないのでは、と思ったためです。 おわりに 本記事では、論文輪読会で私が紹介した論文について簡単にまとめました。 論文輪読会は、知見のインプットとアウトプット、両者の力を伸ばせる取り組みですので、皆さんの会社や部署などでも実施してみてはいかがでしょうか？ 最後までお読みいただき、本当にありがとうございました！ 私たちは同じ事業部で共に働いていただける仲間を募集しています！ 論文輪読会をはじめとした各種勉強会に気軽に参加できるような環境で働くことに興味のある皆様、ぜひご応募お待ちしています！ フルサイクルエンジニア 執筆： @miyazawa.hibiki 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、かわいい動物の擬人化用の呪文です。 Stable Diffusionって、動物の擬人化が難しいんです。例えば犬にテニスをさせたいとします。 パッと思いつくのはこんな呪文です。 illustration of cute dog playing tennis ... 出力結果 コレジャナイ感が満載ですね。かわいい動物の擬人化に成功したので、その方法を紹介します。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 steampunk illustration of cute anthromorphic 動物名 costume steampunkを外す anthromorphicを外す steampunkとanthromorphicを外す costumeを外す steampunkとcostumeを外す まとめ 仲間募集 Stable Diffusionの過去コンテンツ steampunk illustration of cute anthromorphic 動物名 costume これが基本呪文です。 steampunkは、 蒸気機関 が高度に発達したレトロなアニメの世界観を召喚する呪文です。詳しくは、 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 を御覧ください。 不思議なことに、steampunkの世界では、動物が擬人化しやすいのです。 anthromorphicの意味は擬人化。anthromorphic 動物名で、動物が擬人化できれば話は簡単なのですが、世の中そう甘くはありません。 擬人化に必要な3つ目の呪文がcostume（服装）。動物を人間にするには、服が必要だというのは、深い何かを感じますね。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of cute anthromorphic ferret costume highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of cute anthromorphic ferret costume highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 出力結果 かわいい フェレット の擬人化に成功しました。 steampunkを外す steampunkを呪文から外すとどうなるか実験してみましょう。 今回の基本呪文 illustration of cute anthromorphic ferret costume 出力結果 これも、かわいいですね。steampunkを外すと擬人化に失敗するケースが出てきます。 anthromorphicを外す anthromorphicを呪文から外すとどうなるか実験してみましょう。 今回の基本呪文 steampunk illustration of cute ferret costume 出力結果 あれっ、あまり変わらない。そうなんです、steampunkの呪文が指定されている場合、anthromorphicがなくてもあまり結果は変わりません。ごくまれに、擬人化に失敗することがあるくらいです。じゃ、anthromorphicは効果がないかというとそんな事はありません。 次の例を見てください。 steampunkとanthromorphicを外す それでは、steampunkとanthromorphicを両方外してみましょう。 今回の基本呪文 illustration of cute ferret costume 出力結果 擬人化に失敗してしまいました。 先程、steampunkなし、anthromorphicありのときは、擬人化に成功していたことを思い出してください。anthromorphicは確かに擬人化の効果があるということです。 steampunkにも擬人化の効果があるため、steampunkと組み合わせるときは、anthromorphicなしでもあまり影響はありませんが、基本つけるようにしたほうが良いでしょう。 costumeを外す 今回は、costumeを外してみましょう。 今回の基本呪文 steampunk illustration of cute anthromorphic ferret 出力結果 costumeを外しても、きれいに擬人化されていますね。今回の結果は予想していた人もいたかもしれません。steampunkとanthromorphicで、擬人化に必要な呪文の成分が足りているため、costumeを外してもほとんど影響がないのです。 しかし、costumeに擬人化に必要な呪文の成分がないかというとそんな事はありません。次の例を見てください。 steampunkとcostumeを外す それでは、steampunkとcostumeを両方外してみましょう。 今回の基本呪文 illustration of cute anthromorphic ferret 出力結果 完全に擬人化に失敗してますね。anthromorphic単独では、擬人化に必要な呪文の成分が足りていないということです。 まとめ かわいい動物を擬人化するときの基本呪文は steampunk illustration of cute anthromorphic 動物名 costume です。anthromorphicの意味は擬人化ですが、anthromorphic単独で擬人化できるほど強い呪文ではありません。steampunkやcostumeなどの擬人化成分を持った呪文と組み合わせましょう。 次回は、 バベルの塔のイラスト編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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って、動物の擬人化が難しいんです。例えば犬にテニスをさせたいとします。 パッと思いつくのはこんな呪文です。 illustration of cute dog playing tennis ... 出力結果 コレジャナイ感が満載ですね。かわいい動物の擬人化に成功したので、その方法を紹介します。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 steampunk illustration of cute anthromorphic 動物名 costume steampunkを外す anthromorphicを外す steampunkとanthromorphicを外す costumeを外す steampunkとcostumeを外す まとめ 仲間募集 Stable Diffusionの過去コンテンツ steampunk illustration of cute anthromorphic 動物名 costume これが基本呪文です。 steampunkは、 蒸気機関 が高度に発達したレトロなアニメの世界観を召喚する呪文です。詳しくは、 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 を御覧ください。 不思議なことに、steampunkの世界では、動物が擬人化しやすいのです。 anthromorphicの意味は擬人化。anthromorphic 動物名で、動物が擬人化できれば話は簡単なのですが、世の中そう甘くはありません。 擬人化に必要な3つ目の呪文がcostume（服装）。動物を人間にするには、服が必要だというのは、深い何かを感じますね。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of cute anthromorphic ferret costume highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of cute anthromorphic ferret costume highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 出力結果 かわいい フェレット の擬人化に成功しました。 steampunkを外す steampunkを呪文から外すとどうなるか実験してみましょう。 今回の基本呪文 illustration of cute anthromorphic ferret costume 出力結果 これも、かわいいですね。steampunkを外すと擬人化に失敗するケースが出てきます。 anthromorphicを外す anthromorphicを呪文から外すとどうなるか実験してみましょう。 今回の基本呪文 steampunk illustration of cute ferret costume 出力結果 あれっ、あまり変わらない。そうなんです、steampunkの呪文が指定されている場合、anthromorphicがなくてもあまり結果は変わりません。ごくまれに、擬人化に失敗することがあるくらいです。じゃ、anthromorphicは効果がないかというとそんな事はありません。 次の例を見てください。 steampunkとanthromorphicを外す それでは、steampunkとanthromorphicを両方外してみましょう。 今回の基本呪文 illustration of cute ferret costume 出力結果 擬人化に失敗してしまいました。 先程、steampunkなし、anthromorphicありのときは、擬人化に成功していたことを思い出してください。anthromorphicは確かに擬人化の効果があるということです。 steampunkにも擬人化の効果があるため、steampunkと組み合わせるときは、anthromorphicなしでもあまり影響はありませんが、基本つけるようにしたほうが良いでしょう。 costumeを外す 今回は、costumeを外してみましょう。 今回の基本呪文 steampunk illustration of cute anthromorphic ferret 出力結果 costumeを外しても、きれいに擬人化されていますね。今回の結果は予想していた人もいたかもしれません。steampunkとanthromorphicで、擬人化に必要な呪文の成分が足りているため、costumeを外してもほとんど影響がないのです。 しかし、costumeに擬人化に必要な呪文の成分がないかというとそんな事はありません。次の例を見てください。 steampunkとcostumeを外す それでは、steampunkとcostumeを両方外してみましょう。 今回の基本呪文 illustration of cute anthromorphic ferret 出力結果 完全に擬人化に失敗してますね。anthromorphic単独では、擬人化に必要な呪文の成分が足りていないということです。 まとめ かわいい動物を擬人化するときの基本呪文は steampunk illustration of cute anthromorphic 動物名 costume です。anthromorphicの意味は擬人化ですが、anthromorphic単独で擬人化できるほど強い呪文ではありません。steampunkやcostumeなどの擬人化成分を持った呪文と組み合わせましょう。 次回は、 バベルの塔のイラスト編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 で執筆されました ）

こんにちは、 電通国際情報サービス (ISID) 金融ソリューション事業部の大場です。 今回は、Rustでフロントエンドの実装ができるYewというライブラリを使って Markdown エディタを作った話をします。本記事は、Yewの内部実装に触れながらYewやRustのマクロの動作について理解を深めることを目的としています。これらについて詳しく知りたい方はぜひ本記事を参考にしていただければと思います。 また、本記事で紹介するコードはこちらの リポジトリ で公開しています。 https://github.com/ISID/wasm-md-editor 作った背景 採用した主要なCrate 全体像とフロー Yew そもそもWebAssembly（Wasm）とは Yew内部で使われる主要なCrate Yewの実装 手続き型マクロ マクロについての補足 #[function_component]実装 実際に画面を実装してみる Top画面とルーティング実装 エディタ画面の作成 最後に 補足 Trunkについて Markdownのスタイルについて 作った背景 WebAssemblyを触ってみたいと思っていたところ、Rustでフロントエンドの実装ができるライブラリを発見したのを機に「これは何か作ってみるしかない！」と一念発起して作り始めました。デザインに時間をかけたくなかったので、最もシンプルなUIで作れそうな Markdown を作ることにしました。（ 逆にシンプル過ぎたかもしれません ） 採用した主要なCrate さっそく、 Markdown エディタに使用した主要なライブラリの簡単な紹介です。pulldown-cmarkの実装部分の説明は省いています。気になる方はgit リポジトリ をご覧ください。 Yew WebAssemblyによるRust製フロントエンド フレームワーク JSX記法を提供するHTMLマクロや、ReactライクなComponent(Class Component、Functional Component)の実装が可能 pulldown-cmark Markdown 記法のテキストをHTML形式に変換するParser 全体像とフロー 作ったアプリの全体像がこんな感じです。 ①ユーザーが画面に Markdown 記法でテキストを入力 ➁Yew コンポーネント は文字入力のイベントを受信し、pulldown-cmarkで作られたrendererへテキストを渡す ③rendererは Markdown 記法を解釈し、HTML形式のテキストに変換する ④Yew コンポーネント に返却し再 レンダリング ここからYewの紹介をしつつ、実際にYewの実装を見ていきます。 Yew そもそもWebAssembly（Wasm）とは ブラウザ上で動作するバイナリー形式の アセンブリ言語 で、ネイティブアプリに近いパフォーマンスで動作する言語と言われています。現在Wasmに コンパイル できる言語にはC、 C++ 、Rustがあります。 Wasmには「 JavaScript を補完し、並行して動作するための言語」という思想が根底にあり、 JavaScript と（今回の記事では）Rustが双方向にそれぞれの関数をexport, importして利用することができます。 Yew内部で使われる主要なCrate js-sys JavaScript 標準の ビルトインオブジェクト をRustに提供 web-sys ブラウザが提供するWeb API をRustに提供 wasm-bindgen Rustで書いたコード（関数）を JavaScript 側で利用するためのCrate。両者の関数を受け渡しするブリッジ的な役割を果たす。js-sysやweb-sysを使ったRustのコードもwasm-bindgenが最終的に javaScript にexportする wasm-bindgen-futures Rustと JavaScript 両者の非同期実装をブリッジするためのCrate。 JavaScript のPromiseをRustのFutureとして操作することが可能 Yewの実装 手続き型マクロ 簡易的なComponentを実装してみます。 use yew::prelude::*; // これはHomeコンポーネントとして認識される #[function_component(Home)] // 1. pub fn home() -> Html { html! { // 2. <h1>{"Welcome to my editor!"}</h1> } } #[function_component] アトリビュート を付与することで関数全体がComponentであるとYewが認識します。 アトリビュート の引数にある `home はComponentの名称を指しています。 home関数では、 html! を利用してインナーブロックで与えられたHTMLタグを処理しHTMLとして返却します。 マクロについての補足 1.2 で述べた記法は、Rustの世界ではどちらもマクロと呼ばれています。 1 のように関数や構造体に付与するものは手続き型マクロと呼ばれるのに対し、macro_rules!で定義され、呼び出し元からは関数呼び出しのように利用されるものは宣言的マクロ（println!など）に分類されます。 ここで注意ですが、 2 の html! は一見宣言的マクロに見えますが実は手続き型マクロです。これはhtml!マクロの内部の実装を見ると明らかになります。 #[proc_macro_error::proc_macro_error] #[proc_macro] // 1. pub fn html(input: TokenStream) -> TokenStream { let root = parse_macro_input!(input as HtmlRootVNode); TokenStream::from(root.into_token_stream()) } html!マクロの実装は #[proc_macro] によって定義されており、macro_rules!を使っていません。 #[proc_macro] を使った手続き型マクロは関数風マクロと呼ばれています。手続き型マクロがRustのバージョン1.15.0で追加されたため、従来から存在した宣言的マクロと後発の関数風マクロが共存してしまっているようです。 それでは、 #[function_component] マクロはどのように実装されているのか見ていきましょう。 #[function_component]実装 先に実装から。 #[proc_macro_attribute] // 1. pub fn function_component( attr: proc_macro::TokenStream, // 2. item: proc_macro::TokenStream, // 2. ) -> proc_macro::TokenStream { let item = parse_macro_input!(item as FunctionComponent); // 3. let attr = parse_macro_input!(attr as FunctionComponentName); // 3. function_component_impl(attr, item) // 4. .unwrap_or_else(|err| err.to_compile_error()) .into() } pub fn function_component_impl( name: FunctionComponentName, component: FunctionComponent, ) -> syn::Result<TokenStream> { let FunctionComponentName { component_name } = name; // ・・・省略・・・ let quoted = quote! { // 5. #[doc(hidden)] #[allow(non_camel_case_types)] #[allow(unused_parens)] #vis struct #function_name #impl_generics { _marker: ::std::marker::PhantomData<(#phantom_generics)>, } impl #impl_generics ::yew::functional::FunctionProvider for #function_name #ty_generics #where_clause { type TProps = #props_type; fn run(#arg) -> #ret_type { #block } } #(#attrs)* #[allow(type_alias_bounds)] #vis type #component_name #impl_generics = ::yew::functional::FunctionComponent<#function_name #ty_generics>; }; Ok(quoted) } コンポーネント を定義する際に利用した #[function_component] アトリビュート は下記のように動作します。 proc_macro_attribute はfunction_component()関数が Custom Attribute であることを示しており、利用側で #[function_component] を関数に付与した際には、定義元であるこの関数にリンクされます。 手続き型マクロを定義する関数は、TokenStreamを入力として受け取りTokenStreamを出力として返します。つまり、 アトリビュート を付与した関数のコードそのものが入力値としてTokenStreamに変換され、そのTokenStreamを基にマクロで生成されるコードがTokenStreamとして返却されます。 引数の１つ目である attr: proc_macro::TokenStream は呼び出し側( #[function_component(Home)] )のHomeを指しているのに対し、2つ目の item: proc_macro::TokenStream は #[function_component(Home)] を付与した関数の中身(Componentの実装)に対応しています。 itemがFunctionComponent型、attrはFunctionComponentName型にキャストされていることがわかります。 parse_macro_input!はTokenStreamの トーク ン列を 構文木 にパースし、Rustが解釈できるデータ構造に変換されます。その後、マクロ実装によってデータ構造に対して書き込みが行われていきます。書き込み後に生成されたコードをTokenStreamに再変換し、呼び出し元に返却します。 一般的な手続き型マクロの順番は上述の通りですが、 parse_macro_input! マクロによって 構文木 にパースされたTokenStreamはこのあとfunction_component_impl()関数内の処理で再度TokenStreamに変換されます。 構文木 にパースされると、マクロによってコードが生成されます。function_component_impl()関数を見ると quote! マクロが呼ばれ、 構文木 からTokenStreamへの変換が行われます。 コードを生成する処理については各手続き型マクロの固有処理になるので、マクロを定義するlib.rsからは分離して定義することが多いです。 これは、proc_macroで定義したマクロ内部のコードは、マクロが評価される実行時のタイミングでしか呼び出すことができません。つまり、マクロ内部の詳細な実装をテストすることも踏まえると、詳細な実装はlib.rsではない別のクレートに実装し、lib.rsから呼び出すように書く必要があるのです。 実際に画面を実装してみる Top画面とルーティング実装 Rustのマクロの説明で利用したHome コンポーネント をラップして、トップ画面を作成します。 use crate::{components::home::Home, Routing}; use stylist::style; use yew::prelude::*; use yew_router::{history::History, hooks::use_history}; #[function_component(Top)] // 1. pub fn top() -> Html { let container = style!( // 2. r#" display: flex; flex-direction: column; align-items: center; "# ) .expect("Failed to styled."); let button = style!( r#" color: #ffffff; width: 200px; padding: 10px; background-color: #1976d2; box-shadow: 0 3px 5px rgba(0, 0, 0, .3); -webkit-box-shadow: 0 3px 5px rgba(0, 0, 0, .3); :hover { background: #115293; margin-top: 3px; } "# ) .expect("Failed to styled."); let history = use_history().unwrap(); let onclick = Callback::once(move |_| history.push(Routing::Editor)); html! { <> <div class={container}> <Home /> <button class={button} {onclick}>{"Start"}</ button> </div> </> } Top コンポーネント は、Home コンポーネント を呼び出しており、Startボタンを配置するTopページを表している。 styleは stylist を利用しており、Reactのような宣言的なスタイルの定義が可能。 あとはmain.rsとしてルーティングの設定を行います。今回はHome画面をトップ画面に、Home画面に設置しているボタンを押下するとエディタ画面に遷移するようにします。(解説は省きます) #[derive(Clone, Routable, PartialEq)] pub enum Routing { #[at("/")] Home, #[at("/editor")] Editor, #[not_found] #[at("/404")] NotFound, } pub enum Msg { SetInput(String), } #[function_component(App)] fn app() -> Html { html! { <BrowserRouter> <Switch<Routing> render={Switch::render(switch)} /> </BrowserRouter> } } fn switch(routes: &Routing) -> Html { match routes { Routing::Home => html! { <Top /> }, Routing::Editor => html! { <Text /> }, Routing::NotFound => html! {<NotFound />}, } } fn main() { yew::start_app::<App>(); } サーバを起動すると下記のようなTop画面が表示されます。 エディタ画面の作成 エディタ画面の実装です。改めてですが、画面のデザインは驚くほど凝っていません。 Reactを書いてるような感覚でstyleや イベントハンドラ を実装できるのがわかるかと思います。 #[styled_component(Text)] pub fn text() -> Html { let style = style!( r#" background-color: #1e2126; color: #fff; font-family: inherit; margin: 2rem; "# ) .expect("Failed to styled."); let container = style!( r#" display: flex; "# ) .expect("Failed to styled."); let item = style!( r#" "# ) .expect("Failed to styled."); let value = use_state(|| String::from("")); let on_input = { // 1. let value = value.clone(); Callback::from(move |e: InputEvent| { // 2. let input: HtmlTextAreaElement = e.target_unchecked_into(); value.set(input.value()); }) }; let html = cmark(value.to_string()); // 3. let div = web_sys::window() .unwrap() .document() .unwrap() .create_element("div") .unwrap(); div.set_inner_html(&html); let node = Node::from(div); let vnode = VNode::VRef(node); // 5. html! { <> <div class="markdown-body"> <div class={container}> <div class={item}> <textarea class={style} rows="140" cols="100" value={value.to_string()} oninput={on_input} /> </div> <div class="item" > {vnode} </div> </div> </div> </> } } fn cmark(text: String) -> String { let mut options = Options::empty(); options.insert( Options::ENABLE_TABLES // 4. | Options::ENABLE_FOOTNOTES | Options::ENABLE_STRIKETHROUGH | Options::ENABLE_TASKLISTS | Options::ENABLE_SMART_PUNCTUATION, ); let parser = Parser::new_ext(&text, options); let mut html_output = String::new(); // parser changes rendered String for markdown html::push_html(&mut html_output, parser); html_output } テキストエリアに文字が入力された際に発火されるイベントを登録しておきます。 Callback を使ってComponentが保持する状態にテキストの値を渡します。 pulldown-cmarkの処理です。 Markdown 記法で書かれたテキストをHTMLに変換します。 Parserを作成する際に必要なオプションの有無を設定しています。 ここで述べるオプションというのは Markdown 記法のうち、表形式やタスクリストなどの記法をParserの変換対象にするかを指しています。 各Options内の変数は1をシフト演算したものであるため、上記の実装のように 論理和 をとることでまとめてオプションを有効化しています。 HTMLに変換されたテキストを VNode を使って仮想DOMにセットします。 エディタ画面はこんな感じになりました。 最後に 本記事では、Yewの実装を見ながらマクロの挙動やYewの実装方法について説明しました。WasmやRustに興味を持っていただけたら嬉しいです。 また、Rustでフロントエンド実装ができるライブラリはYew以外にもいくつかあるので興味のある方はぜひ見てみてください！ 補足 Trunkについて ローカルでのWebサーバは Trunk を利用しました。TrunkはRustのコードを JavaScript モジュールに コンパイル するバンドルツールとしてwasm-packと大変似ていますが、Trunkの場合はwasm-packと違って JavaScript モジュールのほかその他のアセット（HTML, CSS , Image）も同時に自動生成します。また、TrunkにはビルトインでWebサーバが提供されているため、コマンド一発で開発時に利用するWebサーバを立ち上げることができます。 Yew公式でも、Trunkが推奨されています。 Markdown のスタイルについて 公開されているものがあったのでそのまま利用しました。 https://github.com/sindresorhus/github-markdown-css 執筆： 大場 進太郎 (@ShintaroOba) 、レビュー： @sato.taichi （ Shodo で執筆されました ）

こんにちは、 電通国際情報サービス (ISID) 金融ソリューション事業部の大場です。 今回は、Rustでフロントエンドの実装ができるYewというライブラリを使って Markdown エディタを作った話をします。本記事は、Yewの内部実装に触れながらYewやRustのマクロの動作について理解を深めることを目的としています。これらについて詳しく知りたい方はぜひ本記事を参考にしていただければと思います。 また、本記事で紹介するコードはこちらの リポジトリ で公開しています。 https://github.com/ISID/wasm-md-editor 作った背景 採用した主要なCrate 全体像とフロー Yew そもそもWebAssembly（Wasm）とは Yew内部で使われる主要なCrate Yewの実装 手続き型マクロ マクロについての補足 #[function_component]実装 実際に画面を実装してみる Top画面とルーティング実装 エディタ画面の作成 最後に 補足 Trunkについて Markdownのスタイルについて 作った背景 WebAssemblyを触ってみたいと思っていたところ、Rustでフロントエンドの実装ができるライブラリを発見したのを機に「これは何か作ってみるしかない！」と一念発起して作り始めました。デザインに時間をかけたくなかったので、最もシンプルなUIで作れそうな Markdown を作ることにしました。（ 逆にシンプル過ぎたかもしれません ） 採用した主要なCrate さっそく、 Markdown エディタに使用した主要なライブラリの簡単な紹介です。pulldown-cmarkの実装部分の説明は省いています。気になる方はgit リポジトリ をご覧ください。 Yew WebAssemblyによるRust製フロントエンド フレームワーク JSX記法を提供するHTMLマクロや、ReactライクなComponent(Class Component、Functional Component)の実装が可能 pulldown-cmark Markdown 記法のテキストをHTML形式に変換するParser 全体像とフロー 作ったアプリの全体像がこんな感じです。 ①ユーザーが画面に Markdown 記法でテキストを入力 ➁Yew コンポーネント は文字入力のイベントを受信し、pulldown-cmarkで作られたrendererへテキストを渡す ③rendererは Markdown 記法を解釈し、HTML形式のテキストに変換する ④Yew コンポーネント に返却し再 レンダリング ここからYewの紹介をしつつ、実際にYewの実装を見ていきます。 Yew そもそもWebAssembly（Wasm）とは ブラウザ上で動作するバイナリー形式の アセンブリ言語 で、ネイティブアプリに近いパフォーマンスで動作する言語と言われています。現在Wasmに コンパイル できる言語にはC、 C++ 、Rustがあります。 Wasmには「 JavaScript を補完し、並行して動作するための言語」という思想が根底にあり、 JavaScript と（今回の記事では）Rustが双方向にそれぞれの関数をexport, importして利用することができます。 Yew内部で使われる主要なCrate js-sys JavaScript 標準の ビルトインオブジェクト をRustに提供 web-sys ブラウザが提供するWeb API をRustに提供 wasm-bindgen Rustで書いたコード（関数）を JavaScript 側で利用するためのCrate。両者の関数を受け渡しするブリッジ的な役割を果たす。js-sysやweb-sysを使ったRustのコードもwasm-bindgenが最終的に javaScript にexportする wasm-bindgen-futures Rustと JavaScript 両者の非同期実装をブリッジするためのCrate。 JavaScript のPromiseをRustのFutureとして操作することが可能 Yewの実装 手続き型マクロ 簡易的なComponentを実装してみます。 use yew::prelude::*; // これはHomeコンポーネントとして認識される #[function_component(Home)] // 1. pub fn home() -> Html { html! { // 2. <h1>{"Welcome to my editor!"}</h1> } } #[function_component] アトリビュート を付与することで関数全体がComponentであるとYewが認識します。 アトリビュート の引数にある `home はComponentの名称を指しています。 home関数では、 html! を利用してインナーブロックで与えられたHTMLタグを処理しHTMLとして返却します。 マクロについての補足 1.2 で述べた記法は、Rustの世界ではどちらもマクロと呼ばれています。 1 のように関数や構造体に付与するものは手続き型マクロと呼ばれるのに対し、macro_rules!で定義され、呼び出し元からは関数呼び出しのように利用されるものは宣言的マクロ（println!など）に分類されます。 ここで注意ですが、 2 の html! は一見宣言的マクロに見えますが実は手続き型マクロです。これはhtml!マクロの内部の実装を見ると明らかになります。 #[proc_macro_error::proc_macro_error] #[proc_macro] // 1. pub fn html(input: TokenStream) -> TokenStream { let root = parse_macro_input!(input as HtmlRootVNode); TokenStream::from(root.into_token_stream()) } html!マクロの実装は #[proc_macro] によって定義されており、macro_rules!を使っていません。 #[proc_macro] を使った手続き型マクロは関数風マクロと呼ばれています。手続き型マクロがRustのバージョン1.15.0で追加されたため、従来から存在した宣言的マクロと後発の関数風マクロが共存してしまっているようです。 それでは、 #[function_component] マクロはどのように実装されているのか見ていきましょう。 #[function_component]実装 先に実装から。 #[proc_macro_attribute] // 1. pub fn function_component( attr: proc_macro::TokenStream, // 2. item: proc_macro::TokenStream, // 2. ) -> proc_macro::TokenStream { let item = parse_macro_input!(item as FunctionComponent); // 3. let attr = parse_macro_input!(attr as FunctionComponentName); // 3. function_component_impl(attr, item) // 4. .unwrap_or_else(|err| err.to_compile_error()) .into() } pub fn function_component_impl( name: FunctionComponentName, component: FunctionComponent, ) -> syn::Result<TokenStream> { let FunctionComponentName { component_name } = name; // ・・・省略・・・ let quoted = quote! { // 5. #[doc(hidden)] #[allow(non_camel_case_types)] #[allow(unused_parens)] #vis struct #function_name #impl_generics { _marker: ::std::marker::PhantomData<(#phantom_generics)>, } impl #impl_generics ::yew::functional::FunctionProvider for #function_name #ty_generics #where_clause { type TProps = #props_type; fn run(#arg) -> #ret_type { #block } } #(#attrs)* #[allow(type_alias_bounds)] #vis type #component_name #impl_generics = ::yew::functional::FunctionComponent<#function_name #ty_generics>; }; Ok(quoted) } コンポーネント を定義する際に利用した #[function_component] アトリビュート は下記のように動作します。 proc_macro_attribute はfunction_component()関数が Custom Attribute であることを示しており、利用側で #[function_component] を関数に付与した際には、定義元であるこの関数にリンクされます。 手続き型マクロを定義する関数は、TokenStreamを入力として受け取りTokenStreamを出力として返します。つまり、 アトリビュート を付与した関数のコードそのものが入力値としてTokenStreamに変換され、そのTokenStreamを基にマクロで生成されるコードがTokenStreamとして返却されます。 引数の１つ目である attr: proc_macro::TokenStream は呼び出し側( #[function_component(Home)] )のHomeを指しているのに対し、2つ目の item: proc_macro::TokenStream は #[function_component(Home)] を付与した関数の中身(Componentの実装)に対応しています。 itemがFunctionComponent型、attrはFunctionComponentName型にキャストされていることがわかります。 parse_macro_input!はTokenStreamの トーク ン列を 構文木 にパースし、Rustが解釈できるデータ構造に変換されます。その後、マクロ実装によってデータ構造に対して書き込みが行われていきます。書き込み後に生成されたコードをTokenStreamに再変換し、呼び出し元に返却します。 一般的な手続き型マクロの順番は上述の通りですが、 parse_macro_input! マクロによって 構文木 にパースされたTokenStreamはこのあとfunction_component_impl()関数内の処理で再度TokenStreamに変換されます。 構文木 にパースされると、マクロによってコードが生成されます。function_component_impl()関数を見ると quote! マクロが呼ばれ、 構文木 からTokenStreamへの変換が行われます。 コードを生成する処理については各手続き型マクロの固有処理になるので、マクロを定義するlib.rsからは分離して定義することが多いです。 これは、proc_macroで定義したマクロ内部のコードは、マクロが評価される実行時のタイミングでしか呼び出すことができません。つまり、マクロ内部の詳細な実装をテストすることも踏まえると、詳細な実装はlib.rsではない別のクレートに実装し、lib.rsから呼び出すように書く必要があるのです。 実際に画面を実装してみる Top画面とルーティング実装 Rustのマクロの説明で利用したHome コンポーネント をラップして、トップ画面を作成します。 use crate::{components::home::Home, Routing}; use stylist::style; use yew::prelude::*; use yew_router::{history::History, hooks::use_history}; #[function_component(Top)] // 1. pub fn top() -> Html { let container = style!( // 2. r#" display: flex; flex-direction: column; align-items: center; "# ) .expect("Failed to styled."); let button = style!( r#" color: #ffffff; width: 200px; padding: 10px; background-color: #1976d2; box-shadow: 0 3px 5px rgba(0, 0, 0, .3); -webkit-box-shadow: 0 3px 5px rgba(0, 0, 0, .3); :hover { background: #115293; margin-top: 3px; } "# ) .expect("Failed to styled."); let history = use_history().unwrap(); let onclick = Callback::once(move |_| history.push(Routing::Editor)); html! { <> <div class={container}> <Home /> <button class={button} {onclick}>{"Start"}</ button> </div> </> } Top コンポーネント は、Home コンポーネント を呼び出しており、Startボタンを配置するTopページを表している。 styleは stylist を利用しており、Reactのような宣言的なスタイルの定義が可能。 あとはmain.rsとしてルーティングの設定を行います。今回はHome画面をトップ画面に、Home画面に設置しているボタンを押下するとエディタ画面に遷移するようにします。(解説は省きます) #[derive(Clone, Routable, PartialEq)] pub enum Routing { #[at("/")] Home, #[at("/editor")] Editor, #[not_found] #[at("/404")] NotFound, } pub enum Msg { SetInput(String), } #[function_component(App)] fn app() -> Html { html! { <BrowserRouter> <Switch<Routing> render={Switch::render(switch)} /> </BrowserRouter> } } fn switch(routes: &Routing) -> Html { match routes { Routing::Home => html! { <Top /> }, Routing::Editor => html! { <Text /> }, Routing::NotFound => html! {<NotFound />}, } } fn main() { yew::start_app::<App>(); } サーバを起動すると下記のようなTop画面が表示されます。 エディタ画面の作成 エディタ画面の実装です。改めてですが、画面のデザインは驚くほど凝っていません。 Reactを書いてるような感覚でstyleや イベントハンドラ を実装できるのがわかるかと思います。 #[styled_component(Text)] pub fn text() -> Html { let style = style!( r#" background-color: #1e2126; color: #fff; font-family: inherit; margin: 2rem; "# ) .expect("Failed to styled."); let container = style!( r#" display: flex; "# ) .expect("Failed to styled."); let item = style!( r#" "# ) .expect("Failed to styled."); let value = use_state(|| String::from("")); let on_input = { // 1. let value = value.clone(); Callback::from(move |e: InputEvent| { // 2. let input: HtmlTextAreaElement = e.target_unchecked_into(); value.set(input.value()); }) }; let html = cmark(value.to_string()); // 3. let div = web_sys::window() .unwrap() .document() .unwrap() .create_element("div") .unwrap(); div.set_inner_html(&html); let node = Node::from(div); let vnode = VNode::VRef(node); // 5. html! { <> <div class="markdown-body"> <div class={container}> <div class={item}> <textarea class={style} rows="140" cols="100" value={value.to_string()} oninput={on_input} /> </div> <div class="item" > {vnode} </div> </div> </div> </> } } fn cmark(text: String) -> String { let mut options = Options::empty(); options.insert( Options::ENABLE_TABLES // 4. | Options::ENABLE_FOOTNOTES | Options::ENABLE_STRIKETHROUGH | Options::ENABLE_TASKLISTS | Options::ENABLE_SMART_PUNCTUATION, ); let parser = Parser::new_ext(&text, options); let mut html_output = String::new(); // parser changes rendered String for markdown html::push_html(&mut html_output, parser); html_output } テキストエリアに文字が入力された際に発火されるイベントを登録しておきます。 Callback を使ってComponentが保持する状態にテキストの値を渡します。 pulldown-cmarkの処理です。 Markdown 記法で書かれたテキストをHTMLに変換します。 Parserを作成する際に必要なオプションの有無を設定しています。 ここで述べるオプションというのは Markdown 記法のうち、表形式やタスクリストなどの記法をParserの変換対象にするかを指しています。 各Options内の変数は1をシフト演算したものであるため、上記の実装のように 論理和 をとることでまとめてオプションを有効化しています。 HTMLに変換されたテキストを VNode を使って仮想DOMにセットします。 エディタ画面はこんな感じになりました。 最後に 本記事では、Yewの実装を見ながらマクロの挙動やYewの実装方法について説明しました。WasmやRustに興味を持っていただけたら嬉しいです。 また、Rustでフロントエンド実装ができるライブラリはYew以外にもいくつかあるので興味のある方はぜひ見てみてください！ 補足 Trunkについて ローカルでのWebサーバは Trunk を利用しました。TrunkはRustのコードを JavaScript モジュールに コンパイル するバンドルツールとしてwasm-packと大変似ていますが、Trunkの場合はwasm-packと違って JavaScript モジュールのほかその他のアセット（HTML, CSS , Image）も同時に自動生成します。また、TrunkにはビルトインでWebサーバが提供されているため、コマンド一発で開発時に利用するWebサーバを立ち上げることができます。 Yew公式でも、Trunkが推奨されています。 Markdown のスタイルについて 公開されているものがあったのでそのまま利用しました。 https://github.com/sindresorhus/github-markdown-css 執筆： 大場 進太郎 (@ShintaroOba) 、レビュー： @sato.taichi （ Shodo で執筆されました ）

こんにちは！金融ソリューション事業部の山下です。 本記事では、 こちらの記事 でも紹介した Unreal Engine が提供する「Pixel Streaiming」 プラグイン を使って AWS サーバーからリアルタイムCGストリーミング配信を行います。 説明をシンプルにする為、 AWS の基本的な知識（EC2, セキュリティグループ、IAMロールなど）の説明は割愛いたします。 また、本検証を行う場合、使用する GPU インスタンス の利用料金が発生する点にご注意ください。 実施手順 手順は、以下のとおりです。 AWS EC2で GPU インスタンス を作成 インスタンス 環境構築 UEプロジェクトのビルド UEアプリケーション、WebRTCサーバーの起動 Webブラウザ で接続確認 前提知識 1. Pixel Streaming （画像： https://docs.unrealengine.com/5.0/ja/overview-of-pixel-streaming-in-unreal-engine/ ） UEアプリケーションをサーバーサイドで実行して、 レンダリング 結果をWebRTCでストリーム配信する、EpicGames公式 プラグイン です。 インターネットに繋がった Webブラウザ があれば、 スマホ や タブレット 、ノートPCなど特別な端末スペック不要でUEアプリを楽しむことができます。 キーボード、マウス、タッチスクリーン入力などユーザーによるコン トロール も提供可能です。 使用環境/ツール Unreal Engine 5.0.3 Pixel Streaming plugin 1.0 AWS EC2 Instance type g4dn.xlarge AMI Ubuntu 20.04 LTS AMI NVIDIA CUDAドライバが必須 Architecture x86 EBS 250GB NICE DCV 2022.1 Client 手順1. AWS EC2で GPU インスタンス を作成 AWS EC2コンソールから インスタンス を作成します。 AMIには、 Ubuntu 20.04 LTS AMIを選択します。 このAMIには、PixelStreamingの動作要件として必要となる NVIDIA のCUDAドライバーがプリインストールされています。 インスタンス タイプは、 NVIDIA GPU が利用可能な G4dnインスタンス を選択します。 今回は動作検証が目的の為、最小サイズのxlargeを選択しました。 これから実施する Unreal Engine の コンパイル やアプリケーションのビルドにあまり時間をかけたくない方は、より高性能な インスタンス タイプをおすすめします。 また、vCPU使用リミットの引き上げが必要になる場合、 AWS に事前に申請が必要になります（今回選択したg4dn.xlargeの場合、vCPUは"4"になります）。 インスタンス の作成が完了したら、IAMロールでS3へのRead Permisionを付与します（ AWS がEC2向けに提供する NVIDIA ドライバをダウンロードする為に必要となります）。 また、HTTPと SSH アクセス以外に、NICE DCV接続用の UDP / TCP ポートも開放します。 （※上記は検証用の設定なので、本番環境には使用しないでください。一応最低限のセキュリティとして SSH 接続にはkey pair、およびNICE DCV接続にはユーザー名とパスワードおよびセッションIDが必要になります） 手順2. インスタンス 環境構築 インスタンス に SSH などで接続して、環境構築を実施します。 こちらの AWS for Games Blogのチュートリアル を参考に、以下を実施します。 Ubuntu desctop managerのインストール NVIDIA ドライバのインストール DCVサーバーの起動、セッションの開始 AWS SecretsManagerを使用した、 Ubuntu ユーザーのパスワード生成 実行コマンド： #!/bin/bash #Installing the Ubuntu desktop manager sudo apt update -y sudo apt install -y ubuntu-desktop sudo apt install x11-xserver-utils sudo apt install awscli -y sudo apt install -y dpkg-dev sudo systemctl restart gdm3 sudo apt-get install xorg-dev -y #............................ # Disable the Wayland protocol. NICE DCV doesn't support the Wayland protocol. sudo sed -i '/WaylandEnable/s/^#//g' /etc/gdm3/custom.conf # ............................. # Install NVIDIA Drivers #.............................. sudo apt-get install -y unzip gcc make linux-headers-$(uname -r) cat << EOF | sudo tee --append /etc/modprobe.d/blacklist.conf blacklist vga16fb blacklist nouveau blacklist rivafb blacklist nvidiafb blacklist rivatv EOF # ........ sudo sed -i -e '$a GRUB_CMDLINE_LINUX="rdblacklist=nouveau"' /etc/default/grub sudo update-grub # Make sure to give the EC2 instance S3 read permissions, otherwise this will fail sudo aws s3 cp --recursive s3://ec2-linux-nvidia-drivers/latest/ . sudo chmod +x NVIDIA-Linux-x86_64*.run sudo /bin/sh ./NVIDIA-Linux-x86_64*.run nvidia-smi -q | head# Configure the X Server sudo systemctl set-default graphical.target sudo systemctl isolate graphical.target sudo apt install -y mesa-utils sudo init 3 sudo init 5 sudo nvidia-xconfig --preserve-busid --enable-all-gpus sudo DISPLAY=:0 XAUTHORITY=$(ps aux | grep "X.*\-auth" | grep -v grep \ | sed -n 's/.*-auth \([^ ]\+\).*/\1/p') glxinfo | grep -i "opengl.*version" sudo systemctl isolate multi-user.target sudo systemctl isolate graphical.target# Install DCV wget https://d1uj6qtbmh3dt5.cloudfront.net/NICE-GPG-KEY gpg --import NICE-GPG-KEY sudo rm NICE-GPG-KEY sudo dcvstartx & sudo wget https://d1uj6qtbmh3dt5.cloudfront.net/2022.0/Servers/nice-dcv-2022.0-12123-ubuntu2004-x86_64.tgz sudo tar xvzf nice-dcv-*ubun*.tgz && cd nice-dcv-*64 sudo apt install -y ./nice-dcv-ser*.deb sudo apt install -y ./nice-x*.deb sudo apt install -y ./nice-dcv-web*.deb sudo usermod -aG video ubuntu sudo usermod -aG video dcv # Start the DCV Server and DCV session sudo systemctl enable dcvserver sudo systemctl start dcvserver sudo dcv create-session --type=console --owner=ubuntu newsession sudo dcv list-sessions #sudo dcv close-session newsession # Create random password for the user Ubuntu PASS=$(aws secretsmanager get-random-password --require-each-included-type --password-length 20 --query RandomPassword) INSTANCE=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-hostname) aws secretsmanager create-secret --name DCV/$INSTANCE --description "Credentials for $INSTANCE." --secret-string "{\"user\":\"ubuntu\",\"password\":$PASS}" sudo systemctl isolate multi-user.target sudo systemctl isolate graphical.target （ 参考URL ） 環境構築が完了したら、DCVサーバーとセッションが立ち上がっているはずです。 事前にダウンロードした(DCV Client) https://download.nice-dcv.com/ を起動して、 インスタンス に リモートデスクトップ で接続しましょう。 NICE DCV接続に必要な情報として、以下の情報が必要になります。 サーバーのホスト名 or IP ポート番号 （手順2.で設定した）セッションID （手順2.で設定した） インスタンス ユーザー名/パスワード 以下の構文で入力します。 server_hostname_or_IP:port#session_id この リモートデスクトップ 接続は、UEプロジェクトのビルドの為に行うものです。 その為、もし事前に Linux 向けビルド済のUEアプリケーションをお持ちの方は、次の手順3.は不要です。 手順3. UEプロジェクトのビルド Unreal Engine の GitHubレポジトリ より、 Unreal Engine をダウンロードして コンパイル します。 クローン： git clone git@github.com:EpicGames/UnrealEngine.git コンパイル ： cd UnrealEngine/ ./Setup.sh ./GenerateProjectFiles.sh make UnrealEngine GitHub レポジトリへのアクセスには、EpicGamesアカウントと GitHub アカウントとの紐付けが事前に必要になります。 もしお済みでない方は、 EpicGames公式サイトのFAQ よりアカウントの紐付けを行ってください。 こちらの コンパイル には物凄く時間がかかります。私が行った際は数時間程度かかったので、一旦放置しましょう。 無事 コンパイル が完了したら、 Unreal Editorを立ち上げます。 cd Engine/Binaries/Linux/ ./UnrealEditor デモ用に、Architectureテンプレートから「Collab Viewer」テンプレートを選択します。 PixelStreaming用に、プロジェクト設定とビルドを行います。 詳細な解説は、 こちらのUnreal Engine公式Documentation を参考にしてください。 Pixel Streaming プラグイン の選択、再起動 メニュー「Edit」 -> 「Plugins」より、Pixel Streamingを検索して、 チェックボックス をONにします。 再起動が求められるので、実施します。 Additional Launch Parametersの設定 メニュー「Edit」 -> 「Editor Preferences」 -> 「Level Editor」 -> 「Play」カテゴリより、 Additional Launch Parametersに以下を入力して、音声とIP/ポートを設定します。 AudioMixer -PixelStreamingIP=localhost -PixelStreamingPort=8888 UEアプリの Linux 向けビルド メニュー「Platforms」 -> 「 Linux 」 -> 「Package Project」より、プロジェクトのビルドを行います。 適切な ディレクト リを設定してください（ このビルドにもかなり時間がかかるので、ご注意ください）。 ビルドが完了したら、指定した ディレクト リに「 Linux 」フォルダが作成されます。 手順4. UEアプリケーション、WebRTCサーバーの起動 まず、WebRTCサーバーを立ち上げます。 Unreal Engine が提供する「SignallingWebServer」（Node.jsベースの Cirrus.js を使用）を起動します。 セットアップ： cd ~/Desktop/UnrealEngine/Samples/PixelStreaming/WebServers/SignallingWebServer/platform_scripts/bash chmod +x ./setup.sh ./setup.sh SignallingServerの起動： chmod +x ./Start_SignallingServer.sh ./Start_SignallingServer.sh 次に、UEアプリケーションを立ち上げます。 ビルド先の ディレクト リに移動して、プロジェクト名のついたファイル（今回は「ps_test」）を実行します。 オプションとして、UEアプリのヘッドレス起動、Pixel StreamingのIP/ポートを指定します。　　 cd ~/Desktop/Linux chmod +x ./ps_test.sh ./ps_test.sh -RenderOffScreen -PixelStreamingIP=127.0.0.1 -PixelStreamingPort=888 無事に両方のサーバーが起動すると、以下のログ（「Streamer connected: ::ffff: 127.0.0.1 」）が表示されます。 無事起動できたら、接続確認をしましょう！ 手順5. Webブラウザ で接続確認 インスタンス のグローパル IPアドレス を指定して、お好きな Webブラウザ からアクセスします。 モバイルでも問題なく動きます。 終わりに 今回、 Unreal Engine 5アプリケーションを、 Webブラウザ 向けにリアルタイムストリーミング配信を行いました。 以前の記事 でも紹介したように、 Unreal Engine は非常に高精細なCGをリアルタイム レンダリング できる為、いわゆる" ノンゲーム "領域への活用も今後進んでいくと思われます。 課題を挙げるとすると、サーバーにある程度スペックの高い GPU マシンが必要になる為、コストが一定かかってしまう点です（今回の検証では、 AWS 利用料金が約12ドル程かかりました）。 また、 ゲームエンジン 以外に クラウド やWebの専門知識を必要とする点も、課題として挙げられます。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） TODO コンテナ化 スケーリング セルフヒーリング ネットワーク構成、各種セキュリティ CI/CD 参考 White Paper: Streaming Unreal Engine content to multiple platforms AWS for Games Blog: Unreal Engine Pixel Streaming in AWS with Ubuntu OS Github: aws-samples/deploying-unreal-engine-pixel-streaming-server-on-ec2 執筆： @yamashita.yuki 、レビュー： @mizuno.kazuhiro （ Shodo で執筆されました ）

こんにちは！金融ソリューション事業部の山下です。 本記事では、 こちらの記事 でも紹介した Unreal Engine が提供する「Pixel Streaiming」 プラグイン を使って AWS サーバーからリアルタイムCGストリーミング配信を行います。 説明をシンプルにする為、 AWS の基本的な知識（EC2, セキュリティグループ、IAMロールなど）の説明は割愛いたします。 また、本検証を行う場合、使用する GPU インスタンス の利用料金が発生する点にご注意ください。 実施手順 手順は、以下のとおりです。 AWS EC2で GPU インスタンス を作成 インスタンス 環境構築 UEプロジェクトのビルド UEアプリケーション、WebRTCサーバーの起動 Webブラウザ で接続確認 前提知識 1. Pixel Streaming （画像： https://docs.unrealengine.com/5.0/ja/overview-of-pixel-streaming-in-unreal-engine/ ） UEアプリケーションをサーバーサイドで実行して、 レンダリング 結果をWebRTCでストリーム配信する、EpicGames公式 プラグイン です。 インターネットに繋がった Webブラウザ があれば、 スマホ や タブレット 、ノートPCなど特別な端末スペック不要でUEアプリを楽しむことができます。 キーボード、マウス、タッチスクリーン入力などユーザーによるコン トロール も提供可能です。 使用環境/ツール Unreal Engine 5.0.3 Pixel Streaming plugin 1.0 AWS EC2 Instance type g4dn.xlarge AMI Ubuntu 20.04 LTS AMI NVIDIA CUDAドライバが必須 Architecture x86 EBS 250GB NICE DCV 2022.1 Client 手順1. AWS EC2で GPU インスタンス を作成 AWS EC2コンソールから インスタンス を作成します。 AMIには、 Ubuntu 20.04 LTS AMIを選択します。 このAMIには、PixelStreamingの動作要件として必要となる NVIDIA のCUDAドライバーがプリインストールされています。 インスタンス タイプは、 NVIDIA GPU が利用可能な G4dnインスタンス を選択します。 今回は動作検証が目的の為、最小サイズのxlargeを選択しました。 これから実施する Unreal Engine の コンパイル やアプリケーションのビルドにあまり時間をかけたくない方は、より高性能な インスタンス タイプをおすすめします。 また、vCPU使用リミットの引き上げが必要になる場合、 AWS に事前に申請が必要になります（今回選択したg4dn.xlargeの場合、vCPUは"4"になります）。 インスタンス の作成が完了したら、IAMロールでS3へのRead Permisionを付与します（ AWS がEC2向けに提供する NVIDIA ドライバをダウンロードする為に必要となります）。 また、HTTPと SSH アクセス以外に、NICE DCV接続用の UDP / TCP ポートも開放します。 （※上記は検証用の設定なので、本番環境には使用しないでください。一応最低限のセキュリティとして SSH 接続にはkey pair、およびNICE DCV接続にはユーザー名とパスワードおよびセッションIDが必要になります） 手順2. インスタンス 環境構築 インスタンス に SSH などで接続して、環境構築を実施します。 こちらの AWS for Games Blogのチュートリアル を参考に、以下を実施します。 Ubuntu desctop managerのインストール NVIDIA ドライバのインストール DCVサーバーの起動、セッションの開始 AWS SecretsManagerを使用した、 Ubuntu ユーザーのパスワード生成 実行コマンド： #!/bin/bash #Installing the Ubuntu desktop manager sudo apt update -y sudo apt install -y ubuntu-desktop sudo apt install x11-xserver-utils sudo apt install awscli -y sudo apt install -y dpkg-dev sudo systemctl restart gdm3 sudo apt-get install xorg-dev -y #............................ # Disable the Wayland protocol. NICE DCV doesn't support the Wayland protocol. sudo sed -i '/WaylandEnable/s/^#//g' /etc/gdm3/custom.conf # ............................. # Install NVIDIA Drivers #.............................. sudo apt-get install -y unzip gcc make linux-headers-$(uname -r) cat << EOF | sudo tee --append /etc/modprobe.d/blacklist.conf blacklist vga16fb blacklist nouveau blacklist rivafb blacklist nvidiafb blacklist rivatv EOF # ........ sudo sed -i -e '$a GRUB_CMDLINE_LINUX="rdblacklist=nouveau"' /etc/default/grub sudo update-grub # Make sure to give the EC2 instance S3 read permissions, otherwise this will fail sudo aws s3 cp --recursive s3://ec2-linux-nvidia-drivers/latest/ . sudo chmod +x NVIDIA-Linux-x86_64*.run sudo /bin/sh ./NVIDIA-Linux-x86_64*.run nvidia-smi -q | head# Configure the X Server sudo systemctl set-default graphical.target sudo systemctl isolate graphical.target sudo apt install -y mesa-utils sudo init 3 sudo init 5 sudo nvidia-xconfig --preserve-busid --enable-all-gpus sudo DISPLAY=:0 XAUTHORITY=$(ps aux | grep "X.*\-auth" | grep -v grep \ | sed -n 's/.*-auth \([^ ]\+\).*/\1/p') glxinfo | grep -i "opengl.*version" sudo systemctl isolate multi-user.target sudo systemctl isolate graphical.target# Install DCV wget https://d1uj6qtbmh3dt5.cloudfront.net/NICE-GPG-KEY gpg --import NICE-GPG-KEY sudo rm NICE-GPG-KEY sudo dcvstartx & sudo wget https://d1uj6qtbmh3dt5.cloudfront.net/2022.0/Servers/nice-dcv-2022.0-12123-ubuntu2004-x86_64.tgz sudo tar xvzf nice-dcv-*ubun*.tgz && cd nice-dcv-*64 sudo apt install -y ./nice-dcv-ser*.deb sudo apt install -y ./nice-x*.deb sudo apt install -y ./nice-dcv-web*.deb sudo usermod -aG video ubuntu sudo usermod -aG video dcv # Start the DCV Server and DCV session sudo systemctl enable dcvserver sudo systemctl start dcvserver sudo dcv create-session --type=console --owner=ubuntu newsession sudo dcv list-sessions #sudo dcv close-session newsession # Create random password for the user Ubuntu PASS=$(aws secretsmanager get-random-password --require-each-included-type --password-length 20 --query RandomPassword) INSTANCE=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-hostname) aws secretsmanager create-secret --name DCV/$INSTANCE --description "Credentials for $INSTANCE." --secret-string "{\"user\":\"ubuntu\",\"password\":$PASS}" sudo systemctl isolate multi-user.target sudo systemctl isolate graphical.target （ 参考URL ） 環境構築が完了したら、DCVサーバーとセッションが立ち上がっているはずです。 事前にダウンロードした(DCV Client) https://download.nice-dcv.com/ を起動して、 インスタンス に リモートデスクトップ で接続しましょう。 NICE DCV接続に必要な情報として、以下の情報が必要になります。 サーバーのホスト名 or IP ポート番号 （手順2.で設定した）セッションID （手順2.で設定した） インスタンス ユーザー名/パスワード 以下の構文で入力します。 server_hostname_or_IP:port#session_id この リモートデスクトップ 接続は、UEプロジェクトのビルドの為に行うものです。 その為、もし事前に Linux 向けビルド済のUEアプリケーションをお持ちの方は、次の手順3.は不要です。 手順3. UEプロジェクトのビルド Unreal Engine の GitHubレポジトリ より、 Unreal Engine をダウンロードして コンパイル します。 クローン： git clone git@github.com:EpicGames/UnrealEngine.git コンパイル ： cd UnrealEngine/ ./Setup.sh ./GenerateProjectFiles.sh make UnrealEngine GitHub レポジトリへのアクセスには、EpicGamesアカウントと GitHub アカウントとの紐付けが事前に必要になります。 もしお済みでない方は、 EpicGames公式サイトのFAQ よりアカウントの紐付けを行ってください。 こちらの コンパイル には物凄く時間がかかります。私が行った際は数時間程度かかったので、一旦放置しましょう。 無事 コンパイル が完了したら、 Unreal Editorを立ち上げます。 cd Engine/Binaries/Linux/ ./UnrealEditor デモ用に、Architectureテンプレートから「Collab Viewer」テンプレートを選択します。 PixelStreaming用に、プロジェクト設定とビルドを行います。 詳細な解説は、 こちらのUnreal Engine公式Documentation を参考にしてください。 Pixel Streaming プラグイン の選択、再起動 メニュー「Edit」 -> 「Plugins」より、Pixel Streamingを検索して、 チェックボックス をONにします。 再起動が求められるので、実施します。 Additional Launch Parametersの設定 メニュー「Edit」 -> 「Editor Preferences」 -> 「Level Editor」 -> 「Play」カテゴリより、 Additional Launch Parametersに以下を入力して、音声とIP/ポートを設定します。 AudioMixer -PixelStreamingIP=localhost -PixelStreamingPort=8888 UEアプリの Linux 向けビルド メニュー「Platforms」 -> 「 Linux 」 -> 「Package Project」より、プロジェクトのビルドを行います。 適切な ディレクト リを設定してください（ このビルドにもかなり時間がかかるので、ご注意ください）。 ビルドが完了したら、指定した ディレクト リに「 Linux 」フォルダが作成されます。 手順4. UEアプリケーション、WebRTCサーバーの起動 まず、WebRTCサーバーを立ち上げます。 Unreal Engine が提供する「SignallingWebServer」（Node.jsベースの Cirrus.js を使用）を起動します。 セットアップ： cd ~/Desktop/UnrealEngine/Samples/PixelStreaming/WebServers/SignallingWebServer/platform_scripts/bash chmod +x ./setup.sh ./setup.sh SignallingServerの起動： chmod +x ./Start_SignallingServer.sh ./Start_SignallingServer.sh 次に、UEアプリケーションを立ち上げます。 ビルド先の ディレクト リに移動して、プロジェクト名のついたファイル（今回は「ps_test」）を実行します。 オプションとして、UEアプリのヘッドレス起動、Pixel StreamingのIP/ポートを指定します。　　 cd ~/Desktop/Linux chmod +x ./ps_test.sh ./ps_test.sh -RenderOffScreen -PixelStreamingIP=127.0.0.1 -PixelStreamingPort=888 無事に両方のサーバーが起動すると、以下のログ（「Streamer connected: ::ffff: 127.0.0.1 」）が表示されます。 無事起動できたら、接続確認をしましょう！ 手順5. Webブラウザ で接続確認 インスタンス のグローパル IPアドレス を指定して、お好きな Webブラウザ からアクセスします。 モバイルでも問題なく動きます。 終わりに 今回、 Unreal Engine 5アプリケーションを、 Webブラウザ 向けにリアルタイムストリーミング配信を行いました。 以前の記事 でも紹介したように、 Unreal Engine は非常に高精細なCGをリアルタイム レンダリング できる為、いわゆる" ノンゲーム "領域への活用も今後進んでいくと思われます。 課題を挙げるとすると、サーバーにある程度スペックの高い GPU マシンが必要になる為、コストが一定かかってしまう点です（今回の検証では、 AWS 利用料金が約12ドル程かかりました）。 また、 ゲームエンジン 以外に クラウド やWebの専門知識を必要とする点も、課題として挙げられます。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） TODO コンテナ化 スケーリング セルフヒーリング ネットワーク構成、各種セキュリティ CI/CD 参考 White Paper: Streaming Unreal Engine content to multiple platforms AWS for Games Blog: Unreal Engine Pixel Streaming in AWS with Ubuntu OS Github: aws-samples/deploying-unreal-engine-pixel-streaming-server-on-ec2 執筆： @yamashita.yuki 、レビュー： @mizuno.kazuhiro （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 AWS アカウントのセキュリティを向上させるために、IAMユーザー作成のイベントに即時反応して自動削除する仕組みを作りました。それに際し、マネジメントコンソールからIAMユーザーを作成・削除した時に裏側で起こっていることも調べてみました。 IAMユーザーをなるべく減らしたい理由 運用ルールだけではなく仕組みを 構成図 ユーザーを削除するために必要なこと コンソールからIAMユーザーを作成するときに起こっていること CreateUser (A)CreateLoginProfile (B)CreateAccessKey (G)PutUserPolicy (H)AttachUserPolicy (I)AddUserToGroup コンソールからIAMユーザーを削除するときに起こっていること (A)DeleteLoginProfile (B)ListAccessKeys > DeleteAccessKey (C)ListSigningCertificates > DeleteSigningCertificate (D)ListSSHPublicKeys > DeleteSSHPublicKey (E)ListServiceSpecificCredentials > DeleteServiceSpecificCredential (F)ListMFADevices > DeactivateMFADevice > DeleteVirtualMFADevice (G)ListUserPolicies > DeleteUserPolicy (H)ListAttachedUserPolicies > DetachUserPolicy (I)ListGroupsForUser > RemoveUserFromGroup DeleteUser 今回の仕組みでカバーする範囲 CDKテンプレート Lambda関数 パッケージからのインポートとIAMClientの生成 (A)ログインプロファイルの削除 (B)アクセスキーの削除 (G)インラインポリシーの削除 (H)管理ポリシーのデタッチ (I)IAMグループへの所属解除 Lambdaハンドラ さいごに IAMユーザーをなるべく減らしたい理由 IAMユーザーはログ インパス ワードやアクセスキーなどを利用して AWS リソースにアクセスできますが、いずれも長期的な認証情報です。有効期限が存在しないので退職者管理が必要となり、漏えいした際の影響も大きいため、 AWS アカウントに存在するIAMユーザーをなるべく減らすのが良いでしょう。IAMユーザーを使わずに AWS リソースにアクセスする方法には、例えば以下のようなものがあります。 AWS リソースから別の AWS リソースにアクセスする場合、短期的な認証情報を発行するIAMロールを割り当てる マネジメントコンソールにアクセスしたい場合、 SAML 2.0やIDフェデレーションでIAMロールを引き受けてシングルサインオンする 外部サービスから AWS リソースにアクセスする場合、サポートされていればOIDCなどでIAMロールを引き受ける（例： GitHubの場合 ） 開発中に一時的にアクセスキーを使いたいなど、IAMユーザーが欲しいケースもありますが、むやみやたらには増やさない方が良いでしょう。 運用ルールだけではなく仕組みを 決まったIAMユーザー以外は作成しないことを運用ルールとして定めている場合も多いと思いますが、ルールはあくまでもルール。あらゆる状況において徹底を保証するものではありません。新任者にルールを漏れなく周知することも課題になります。また何らかのルートで悪意ある第 三者 にアカウントに侵入されてしまった場合、 バックドア としてIAMユーザーを作られることもあります。運用ルールだけではなく、実際のリソースとしてIAMユーザーが作成されたときに仕組みで対応できると安心でしょう。今回は強行策として、ユーザーの作成を検知してほぼリアルタイムで自動削除を行う仕組みを作りました。 構成図 ユーザーの削除はEventBridgeのイベントをトリガーにLambda関数が行います。IAMイベントは直接EventBridgeイベントを生成しないため、 CloudTrailのAPIコールでイベントルールが発火 するようにします。IAMの API コールは us-east-1 リージョンに記録されるため、EventBridgeルールやLambda関数も us-east-1 リージョンに作ります。ユーザー作成イベントドリブンのため、既存のユーザーには影響がありません。 この記事の後半に、この仕組みのCDKコードとLambda関数の実装を掲載しています。 ユーザーを削除するために必要なこと IAMユーザーを削除するには DeleteUser API を使うだけで良さそうだと思っていましたが、実はそれほど単純ではありませんでした。 API のリンク先の説明にある通り、 DeleteUser の前にそのIAMユーザーに付属する以下のアイテムを全て削除する 必要があります。それぞれの説明と削除するための API 名を箇条書きします。また便宜上、(A)~(I)の記号を付け、この記事を通して同じ記号を使うようにしています。 (A)ログインプロファイル ( DeleteLoginProfile ) マネジメントコンソールにログインするためのパスワード。1ユーザーにつき1つのみ作成できる (B)アクセスキー ( DeleteAccessKey ) アクセスキーIDとシークレットアクセスキーのペア。1ユーザーあたり2つまで発行できる (C)署 名証 明書 ( DeleteSigningCertificate ) SOAP アクセスなどで使用するX.509証明書。1ユーザーあたり複数登録できる (D) SSH 公開鍵 ( DeleteSSHPublicKey ) CodeCommit 用の SSH 公開鍵。1ユーザーあたり複数登録できる (E)各サービス用のクレデンシャル ( DeleteServiceSpecificCredential ) CodeCommitや Amazon Keyspaces用のクレデンシャル。1ユーザーあたり複数発行できる (F)MFAデ バイス ( DeactivateMFADevice DeleteVirtualMFADevice ) サインイン時に使用するMFAデ バイス 。 DeactivateMFADevice で無効化してから DeleteVirtualMFADevice で削除する必要がある (G)インラインポリシー ( DeleteUserPolicy ) ユーザーに追加されているインラインポリシー。1ユーザーあたり複数作成できる (H)アタッチされている管理ポリシー ( DetachUserPolicy ) アタッチされている管理ポリシー。1ユーザーあたり複数アタッチできる (I)IAMグループへの所属 ( RemoveUserFromGroup ) 1ユーザーあたり複数のグループに所属できる なんと9種類もあります。(C)(D)(E)あたりは使われるケースが少ないと思いますが、他はいずれも馴染み深いものですね。先にこれらのアイテムを削除しないと、 DeleteUser の呼び出しは失敗してしまいます。 コンソールからIAMユーザーを作成するときに起こっていること IAMユーザーと9つのアイテムとの関連付けについての理解を深めるために、マネジメントコンソールからIAMユーザーを作成する時に、裏側でどのような API が呼ばれているのかを掘り下げてみます。コンソールでユーザーを作る時にはいろいろなオプションがありますが、us-east-1 リージョンの CloudTrail ログより実際に呼び出された API をそれぞれ調べました。参照系の API も多く呼ばれていますが、更新系 API のみに着目します。 CreateUser 最初に必ず CreateUser API が呼ばれます。コンソールからユーザーを作成するときはパスワードかアクセスキーのどちらかを同時に作らなければなりませんが、実はこの API 単体ではいずれも生成されません。この時点ではコンソールアクセスもプログラムアクセスもできないユーザー本体のみができあがります。 これ以降の API コールはコンソールで選択した内容によって変わります。いずれも独立したリソース作成のため、実行順は重要ではありません。 (A)CreateLoginProfile 認証情報として「パスワード - AWS マネジメントコンソールへのアクセス」を選択しているとこの API が呼ばれ、パスワードが設定されます。 (B)CreateAccessKey 認証情報として「アクセスキー - プログラムによるアクセス」を選択しているとこの API が呼ばれ、アクセスキーが発行されます。 (G)PutUserPolicy アクセス許可の設定で「アクセス権限を既存のユーザーからコピー」でコピー元のユーザーにインラインポリシーがあるとこの API が呼ばれ、同じインラインポリシーが追加されます。複数のポリシーを追加可能です。 (H)AttachUserPolicy アクセス許可の設定で「既存のポリシーを直接アタッチ」する、もしくは「アクセス権限を既存のユーザーからコピー」でコピー元のユーザーに管理ポリシーがアタッチされているとこの API が呼ばれ、ユーザーに管理ポリシーがアタッチされます。複数のポリシーをアタッチ可能です。 (I)AddUserToGroup アクセス許可の設定で「ユーザーをグループに追加」する、もしくは「アクセス権限を既存のユーザーからコピー」でコピー元のユーザーがIAMグループに所属しているとこの API が呼ばれ、ユーザーがグループに所属します。複数のグループに所属可能です。 今のところ、「(C)署 名証 明書」「(D) SSH 公開鍵」「(E)各サービス用のクレデンシャル」「(F)MFAデ バイス 」はコンソールからのユーザー作成時に同時には作成できませんでした。 コンソールからIAMユーザーを削除するときに起こっていること 次に、(A)~(I)を全て追加したもりもりのユーザーを作成しておき、コンソールから削除した時にどのような API が裏側で呼ばれているのかを見てみました。更新系 API と、それに関連する参照系 API について記載します。 (A)DeleteLoginProfile パスワードが削除されます。 (B)ListAccessKeys > DeleteAccessKey まずは ListAccessKeys で削除対象ユーザーのアクセスキー一覧を取得し、見つかればそれぞれについて DeleteAccessKey で削除されます。 (C)ListSigningCertificates > DeleteSigningCertificate ListSigningCertificates で証明書一覧を取得し、見つかればそれぞれについて DeleteSigningCertificate で削除されます。 (D)ListSSHPublicKeys > DeleteSSHPublicKey ListSSHPublicKeys で鍵一覧を取得し、見つかればそれぞれについて DeleteSSHPublicKey で削除されます。 (E)ListServiceSpecificCredentials > DeleteServiceSpecificCredential ListServiceSpecificCredentials でクレデンシャル一覧を取得し、見つかればそれぞれについて DeleteServiceSpecificCredential で削除されます。 (F)ListMFADevices > DeactivateMFADevice > DeleteVirtualMFADevice ListMFADevices でデ バイス 一覧を取得し、見つかればそれぞれについて DeactivateMFADevice で無効化したのち、 DeleteVirtualMFADevice で削除されます。 (G)ListUserPolicies > DeleteUserPolicy ListUserPolicies でインラインポリシー一覧を取得し、見つかればそれぞれについて DeleteUserPolicy で削除されます。 (H)ListAttachedUserPolicies > DetachUserPolicy ListAttachedUserPolicies でアタッチされている管理ポリシー一覧を取得し、見つかればそれぞれについて DetachUserPolicy でデタッチされます。管理ポリシー自体は削除されません。 (I)ListGroupsForUser > RemoveUserFromGroup ListGroupsForUser で所属しているIAMグループ一覧を取得し、見つかればそれぞれについて RemoveUserFromGroup で所属が解除されます。IAMグループ自体は削除されません。 DeleteUser 以上のアイテムが全て削除されると、最後に DeleteUser が呼ばれてユーザー本体が晴れて（？）削除されます。画面では数クリックで終わる操作ですが、実は多くの API が呼ばれていることがわかりますね。 今回の仕組みでカバーする範囲 ユーザー削除時の API コールを参考にして、IAMユーザーを自動削除するための仕組みを作ります。以下ではCDKとLambda関数のコードを解説しますが、今回はIAMユーザー本体の削除に先立って、以下の5つのアイテムの削除のみを行います。 (A)ログインプロファイル (B)アクセスキー (G)インラインポリシー (H)アタッチされている管理ポリシー (I)IAMグループへの所属 (C)(D)(E)(F)についてはコンソールでユーザーを作成する時に同時に作成できないため、今回は省略しています。コンソールでも CLI でも、これらのアイテムを作成するためにはユーザー作成とは別の操作が必要になりますので、その操作が実施される前にEventBridgeイベントが発火し、ユーザーが削除されることが期待できます。もちろん、 CLI などから CreateUser 実行後、EventBridgeイベントが発火する前に(C)(D)(E)(F)を作成する API が素早く実行されるとユーザーの削除に失敗しますので、より確実にユーザーを削除したい場合は(C)(D)(E)(F)の削除も対応した方が良いでしょう。 CDKテンプレート IAMユーザーの作成を検知し、自動削除する仕組みのCDKスタックは次のとおりです。 EventBridgeルールは detailType を AWS API Call via CloudTrail 、 eventName を CreateUser にすることで、ユーザー作成 API の呼び出しがCloudTrailに記録されるとイベントが起動します。 前述の通り、IAMの更新系 API は us-east-1 リージョンのCloudTrailに記録されるので、このスタックも us-east-1 リージョンにデプロイする必要があります。 import { Duration , Stack , StackProps } from "aws-cdk-lib" ; import * as events from "aws-cdk-lib/aws-events" ; import * as eventTargets from "aws-cdk-lib/aws-events-targets" ; import * as iam from "aws-cdk-lib/aws-iam" ; import { Runtime } from "aws-cdk-lib/aws-lambda" ; import * as lambdaNodejs from "aws-cdk-lib/aws-lambda-nodejs" ; import { Construct } from "constructs" ; export class DeleteUserStack extends Stack { constructor( scope: Construct , id: string , props?: StackProps ) { super( scope , id , props ); // Lambda関数 const deleteUserFunction = new lambdaNodejs.NodejsFunction ( this , "DeleteUserFunction" , { entry: "functions/delete-user.ts" , runtime: Runtime.NODEJS_16_X , timeout: Duration.minutes ( 15 ), } ); // 必要なActionを追加 deleteUserFunction.addToRolePolicy ( new iam.PolicyStatement ( { resources: [ "*" ] , actions: [ "iam:DeleteUser" , "iam:ListAccessKeys" , "iam:DeleteAccessKey" , "iam:ListGroupsForUser" , "iam:RemoveUserFromGroup" , "iam:GetLoginProfile" , "iam:DeleteLoginProfile" , "iam:ListAttachedUserPolicies" , "iam:DetachUserPolicy" , "iam:ListUserPolicies" , "iam:DeleteUserPolicy" , ] , effect: iam.Effect.ALLOW , } ) ); // EventBrdigeルール new events.Rule ( this , "CreateUserEventRule" , { ruleName: "create-user" , eventPattern: { source: [ "aws.iam" ] , detailType: [ "AWS API Call via CloudTrail" ] , detail: { eventSource: [ "iam.amazonaws.com" ] , eventName: [ "CreateUser" ] , } , } , targets: [ new eventTargets.LambdaFunction ( deleteUserFunction ) ] , } ); } } Lambda関数 functions/delete-user.ts のLambda関数の実装を説明します。 パッケージからのインポートとIAMClientの生成 IAM用の SDK をインポートします。Lambda関数が受け取るのはEventBridgeイベントなので、 aws-lambda パッケージから EventBridgeEvent もインポートします。 IAMClientは us-east-1 リージョン向けに生成します。 import * as iam from "@aws-sdk/client-iam" ; import { Handler , EventBridgeEvent } from "aws-lambda" ; const client = new iam.IAMClient ( { region: "us-east-1" } ); (A)ログインプロファイルの削除 ログインプロファイルを削除する関数です。最初に GetLoginProfileCommand でログインプロファイルが存在するかどうかを確認し、存在すれば while ループで削除を試みます。while ループにしている理由は、プロファイルの作成には時間がかかるようで、 CreateLoginProfile コール直後に DeleteLoginProfile をしても次のエラーになってしまうためです。 Login Profile for User <ユーザー名> cannot be modified while login profile is being created. そこで while ループで間に5秒間ずつ待機し、最大30回削除を試みる実装にしました。実際にやってみると、体感的にログインプロファイル作成後15秒ほどで削除できる状態になっていました。 export const deleteLoginProfile = async ( userName: string ) : Promise < void > => { try { const { LoginProfile } = await client.send (new iam.GetLoginProfileCommand ( { UserName: userName } )); if ( LoginProfile === undefined || LoginProfile.UserName === undefined ) return; } catch ( e: unknown ) { console .log ( ` ${ e instanceof Error ? e.message : "" } ` ); return; } let attempts = 30 ; while ( attempts > 0 ) { try { await client.send (new iam.DeleteLoginProfileCommand ( { UserName: userName } )); break; } catch ( e: unknown ) { console .log ( ` ${ e instanceof Error ? e.message : "" } ` ); } await new Promise (( resolve ) => setTimeout ( resolve , 5000 )); attempts --; } } ; (B)アクセスキーの削除 次の関数でアクセスキーを削除します。まずは ListAccessKeysCommand でアクセスキー一覧を取得します。アクセスキーの件数が多い場合（実際には各ユーザー2つまでなので起こらないと思いますが）、一回の ListAccessKeysCommand 呼び出しで全件取得できず、結果の IsTruncated プロパティが true で返ってきます。この時の Marker プロパティを次の ListAccessKeysCommand 呼び出しのパラメータに含めることで、続きの結果を取得できます。一覧取得後は DeleteAccessKeyCommand で1つずつ削除します。 export const deleteAccessKeys = async ( userName: string ) : Promise < void > => { let accessKeyIds: string [] = [] ; let shouldListNext = true ; let Marker: string | undefined = undefined ; while ( shouldListNext ) { const params: iam.ListAccessKeysCommandInput = { UserName: userName , Marker } ; const output = await client.send (new iam.ListAccessKeysCommand ( params )); if ( output.AccessKeyMetadata ) { accessKeyIds = accessKeyIds.concat ( output.AccessKeyMetadata.filter (( accessKeyMetadata ) => accessKeyMetadata.AccessKeyId ) .map ( ( accessKeyMetadata ) => accessKeyMetadata.AccessKeyId ! ) ); } output.IsTruncated ? ( Marker = output.Marker ) : ( shouldListNext = false ); } if ( accessKeyIds.length === 0 ) return; await Promise . all( accessKeyIds.map (async ( keyId ) => { await client.send (new iam.DeleteAccessKeyCommand ( { UserName: userName , AccessKeyId: keyId } )); } ) ); } ; (G)インラインポリシーの削除 (B)アクセスキーの削除 と同様の処理なので、説明は割愛します。 export const deleteUserPolicies = async ( userName: string ) : Promise < void > => { let policyNames: string [] = [] ; let shouldListNext = true ; let Marker: string | undefined = undefined ; while ( shouldListNext ) { const params: iam.ListUserPoliciesCommandInput = { UserName: userName , Marker } ; const output = await client.send (new iam.ListUserPoliciesCommand ( params )); if ( output.PolicyNames ) { policyNames = policyNames.concat ( output.PolicyNames.filter (( name ) => name )); } output.IsTruncated ? ( Marker = output.Marker ) : ( shouldListNext = false ); } if ( policyNames.length === 0 ) return; await Promise . all( policyNames.map (async ( name ) => { await client.send (new iam.DeleteUserPolicyCommand ( { UserName: userName , PolicyName: name } )); } ) ); } ; (H)管理ポリシーのデタッチ 同様の処理なので、説明は割愛します。 export const detachUserPolicies = async ( userName: string ) : Promise < void > => { let attachedPolicieArns: string [] = [] ; let shouldListNext = true ; let Marker: string | undefined = undefined ; while ( shouldListNext ) { const params: iam.ListAttachedUserPoliciesCommandInput = { UserName: userName , Marker } ; const output = await client.send (new iam.ListAttachedUserPoliciesCommand ( params )); if ( output.AttachedPolicies ) { attachedPolicieArns = attachedPolicieArns.concat ( output.AttachedPolicies.filter (( policy ) => policy.PolicyArn ) .map (( policy ) => policy.PolicyArn ! ) ); } output.IsTruncated ? ( Marker = output.Marker ) : ( shouldListNext = false ); } if ( attachedPolicieArns.length === 0 ) return; await Promise . all( attachedPolicieArns.map (async ( arn ) => { await client.send (new iam.DetachUserPolicyCommand ( { UserName: userName , PolicyArn: arn } )); } ) ); } ; (I)IAMグループへの所属解除 同様の処理なので、説明は割愛します。 export const removeUserFromGroups = async ( userName: string ) : Promise < void > => { let groupNames: string [] = [] ; let shouldListNext = true ; let Marker: string | undefined = undefined ; while ( shouldListNext ) { const params: iam.ListGroupsForUserCommandInput = { UserName: userName , Marker } ; const output = await client.send (new iam.ListGroupsForUserCommand ( params )); if ( output.Groups ) { groupNames = groupNames.concat ( output.Groups.filter (( group ) => group.GroupName ) .map (( group ) => group.GroupName ! )); } output.IsTruncated ? ( Marker = output.Marker ) : ( shouldListNext = false ); } if ( groupNames.length === 0 ) return; await Promise . all( groupNames.map (async ( groupName ) => { await client.send (new iam.RemoveUserFromGroupCommand ( { UserName: userName , GroupName: groupName } )); } ) ); } ; Lambdaハンドラ 作成されたIAMユーザー名をイベントの中身から取得するための型を定義し、上で説明した関数を利用してLambdaハンドラを実装します。各アイテムの削除後に DeleteUserCommand でユーザー本体を削除します。 type Detail = { responseElements: { user: { userName: string } } } ; export const handler: Handler = async ( event: EventBridgeEvent < string , Detail >) => { const userName = event.detail.responseElements.user.userName ; await Promise . all( [ deleteLoginProfile ( userName ), deleteAccessKeys ( userName ), deleteUserPolicies ( userName ), detachUserPolicies ( userName ), removeUserFromGroups ( userName ), ] ); await client.send (new iam.DeleteUserCommand ( { UserName: userName } )); } ; これで、IAMユーザーが作成されるイベントをトリガーに、即座にユーザーを削除する仕組みが完成しました。 さいごに 自前で自動化の仕組みを実装してみると、普段コンソールでしている操作の裏側でどのような API が動いているのかが分かり、とても面白かったです。 最後までお読みただいてありがとうございました。 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 - セキュリティエンジニア(セキュリティ設計) 執筆： @kou.kinyo2 、レビュー： @higa （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 AWS アカウントのセキュリティを向上させるために、IAMユーザー作成のイベントに即時反応して自動削除する仕組みを作りました。それに際し、マネジメントコンソールからIAMユーザーを作成・削除した時に裏側で起こっていることも調べてみました。 IAMユーザーをなるべく減らしたい理由 運用ルールだけではなく仕組みを 構成図 ユーザーを削除するために必要なこと コンソールからIAMユーザーを作成するときに起こっていること CreateUser (A)CreateLoginProfile (B)CreateAccessKey (G)PutUserPolicy (H)AttachUserPolicy (I)AddUserToGroup コンソールからIAMユーザーを削除するときに起こっていること (A)DeleteLoginProfile (B)ListAccessKeys > DeleteAccessKey (C)ListSigningCertificates > DeleteSigningCertificate (D)ListSSHPublicKeys > DeleteSSHPublicKey (E)ListServiceSpecificCredentials > DeleteServiceSpecificCredential (F)ListMFADevices > DeactivateMFADevice > DeleteVirtualMFADevice (G)ListUserPolicies > DeleteUserPolicy (H)ListAttachedUserPolicies > DetachUserPolicy (I)ListGroupsForUser > RemoveUserFromGroup DeleteUser 今回の仕組みでカバーする範囲 CDKテンプレート Lambda関数 パッケージからのインポートとIAMClientの生成 (A)ログインプロファイルの削除 (B)アクセスキーの削除 (G)インラインポリシーの削除 (H)管理ポリシーのデタッチ (I)IAMグループへの所属解除 Lambdaハンドラ さいごに IAMユーザーをなるべく減らしたい理由 IAMユーザーはログ インパス ワードやアクセスキーなどを利用して AWS リソースにアクセスできますが、いずれも長期的な認証情報です。有効期限が存在しないので退職者管理が必要となり、漏えいした際の影響も大きいため、 AWS アカウントに存在するIAMユーザーをなるべく減らすのが良いでしょう。IAMユーザーを使わずに AWS リソースにアクセスする方法には、例えば以下のようなものがあります。 AWS リソースから別の AWS リソースにアクセスする場合、短期的な認証情報を発行するIAMロールを割り当てる マネジメントコンソールにアクセスしたい場合、 SAML 2.0やIDフェデレーションでIAMロールを引き受けてシングルサインオンする 外部サービスから AWS リソースにアクセスする場合、サポートされていればOIDCなどでIAMロールを引き受ける（例： GitHubの場合 ） 開発中に一時的にアクセスキーを使いたいなど、IAMユーザーが欲しいケースもありますが、むやみやたらには増やさない方が良いでしょう。 運用ルールだけではなく仕組みを 決まったIAMユーザー以外は作成しないことを運用ルールとして定めている場合も多いと思いますが、ルールはあくまでもルール。あらゆる状況において徹底を保証するものではありません。新任者にルールを漏れなく周知することも課題になります。また何らかのルートで悪意ある第 三者 にアカウントに侵入されてしまった場合、 バックドア としてIAMユーザーを作られることもあります。運用ルールだけではなく、実際のリソースとしてIAMユーザーが作成されたときに仕組みで対応できると安心でしょう。今回は強行策として、ユーザーの作成を検知してほぼリアルタイムで自動削除を行う仕組みを作りました。 構成図 ユーザーの削除はEventBridgeのイベントをトリガーにLambda関数が行います。IAMイベントは直接EventBridgeイベントを生成しないため、 CloudTrailのAPIコールでイベントルールが発火 するようにします。IAMの API コールは us-east-1 リージョンに記録されるため、EventBridgeルールやLambda関数も us-east-1 リージョンに作ります。ユーザー作成イベントドリブンのため、既存のユーザーには影響がありません。 この記事の後半に、この仕組みのCDKコードとLambda関数の実装を掲載しています。 ユーザーを削除するために必要なこと IAMユーザーを削除するには DeleteUser API を使うだけで良さそうだと思っていましたが、実はそれほど単純ではありませんでした。 API のリンク先の説明にある通り、 DeleteUser の前にそのIAMユーザーに付属する以下のアイテムを全て削除する 必要があります。それぞれの説明と削除するための API 名を箇条書きします。また便宜上、(A)~(I)の記号を付け、この記事を通して同じ記号を使うようにしています。 (A)ログインプロファイル ( DeleteLoginProfile ) マネジメントコンソールにログインするためのパスワード。1ユーザーにつき1つのみ作成できる (B)アクセスキー ( DeleteAccessKey ) アクセスキーIDとシークレットアクセスキーのペア。1ユーザーあたり2つまで発行できる (C)署 名証 明書 ( DeleteSigningCertificate ) SOAP アクセスなどで使用するX.509証明書。1ユーザーあたり複数登録できる (D) SSH 公開鍵 ( DeleteSSHPublicKey ) CodeCommit 用の SSH 公開鍵。1ユーザーあたり複数登録できる (E)各サービス用のクレデンシャル ( DeleteServiceSpecificCredential ) CodeCommitや Amazon Keyspaces用のクレデンシャル。1ユーザーあたり複数発行できる (F)MFAデ バイス ( DeactivateMFADevice DeleteVirtualMFADevice ) サインイン時に使用するMFAデ バイス 。 DeactivateMFADevice で無効化してから DeleteVirtualMFADevice で削除する必要がある (G)インラインポリシー ( DeleteUserPolicy ) ユーザーに追加されているインラインポリシー。1ユーザーあたり複数作成できる (H)アタッチされている管理ポリシー ( DetachUserPolicy ) アタッチされている管理ポリシー。1ユーザーあたり複数アタッチできる (I)IAMグループへの所属 ( RemoveUserFromGroup ) 1ユーザーあたり複数のグループに所属できる なんと9種類もあります。(C)(D)(E)あたりは使われるケースが少ないと思いますが、他はいずれも馴染み深いものですね。先にこれらのアイテムを削除しないと、 DeleteUser の呼び出しは失敗してしまいます。 コンソールからIAMユーザーを作成するときに起こっていること IAMユーザーと9つのアイテムとの関連付けについての理解を深めるために、マネジメントコンソールからIAMユーザーを作成する時に、裏側でどのような API が呼ばれているのかを掘り下げてみます。コンソールでユーザーを作る時にはいろいろなオプションがありますが、us-east-1 リージョンの CloudTrail ログより実際に呼び出された API をそれぞれ調べました。参照系の API も多く呼ばれていますが、更新系 API のみに着目します。 CreateUser 最初に必ず CreateUser API が呼ばれます。コンソールからユーザーを作成するときはパスワードかアクセスキーのどちらかを同時に作らなければなりませんが、実はこの API 単体ではいずれも生成されません。この時点ではコンソールアクセスもプログラムアクセスもできないユーザー本体のみができあがります。 これ以降の API コールはコンソールで選択した内容によって変わります。いずれも独立したリソース作成のため、実行順は重要ではありません。 (A)CreateLoginProfile 認証情報として「パスワード - AWS マネジメントコンソールへのアクセス」を選択しているとこの API が呼ばれ、パスワードが設定されます。 (B)CreateAccessKey 認証情報として「アクセスキー - プログラムによるアクセス」を選択しているとこの API が呼ばれ、アクセスキーが発行されます。 (G)PutUserPolicy アクセス許可の設定で「アクセス権限を既存のユーザーからコピー」でコピー元のユーザーにインラインポリシーがあるとこの API が呼ばれ、同じインラインポリシーが追加されます。複数のポリシーを追加可能です。 (H)AttachUserPolicy アクセス許可の設定で「既存のポリシーを直接アタッチ」する、もしくは「アクセス権限を既存のユーザーからコピー」でコピー元のユーザーに管理ポリシーがアタッチされているとこの API が呼ばれ、ユーザーに管理ポリシーがアタッチされます。複数のポリシーをアタッチ可能です。 (I)AddUserToGroup アクセス許可の設定で「ユーザーをグループに追加」する、もしくは「アクセス権限を既存のユーザーからコピー」でコピー元のユーザーがIAMグループに所属しているとこの API が呼ばれ、ユーザーがグループに所属します。複数のグループに所属可能です。 今のところ、「(C)署 名証 明書」「(D) SSH 公開鍵」「(E)各サービス用のクレデンシャル」「(F)MFAデ バイス 」はコンソールからのユーザー作成時に同時には作成できませんでした。 コンソールからIAMユーザーを削除するときに起こっていること 次に、(A)~(I)を全て追加したもりもりのユーザーを作成しておき、コンソールから削除した時にどのような API が裏側で呼ばれているのかを見てみました。更新系 API と、それに関連する参照系 API について記載します。 (A)DeleteLoginProfile パスワードが削除されます。 (B)ListAccessKeys > DeleteAccessKey まずは ListAccessKeys で削除対象ユーザーのアクセスキー一覧を取得し、見つかればそれぞれについて DeleteAccessKey で削除されます。 (C)ListSigningCertificates > DeleteSigningCertificate ListSigningCertificates で証明書一覧を取得し、見つかればそれぞれについて DeleteSigningCertificate で削除されます。 (D)ListSSHPublicKeys > DeleteSSHPublicKey ListSSHPublicKeys で鍵一覧を取得し、見つかればそれぞれについて DeleteSSHPublicKey で削除されます。 (E)ListServiceSpecificCredentials > DeleteServiceSpecificCredential ListServiceSpecificCredentials でクレデンシャル一覧を取得し、見つかればそれぞれについて DeleteServiceSpecificCredential で削除されます。 (F)ListMFADevices > DeactivateMFADevice > DeleteVirtualMFADevice ListMFADevices でデ バイス 一覧を取得し、見つかればそれぞれについて DeactivateMFADevice で無効化したのち、 DeleteVirtualMFADevice で削除されます。 (G)ListUserPolicies > DeleteUserPolicy ListUserPolicies でインラインポリシー一覧を取得し、見つかればそれぞれについて DeleteUserPolicy で削除されます。 (H)ListAttachedUserPolicies > DetachUserPolicy ListAttachedUserPolicies でアタッチされている管理ポリシー一覧を取得し、見つかればそれぞれについて DetachUserPolicy でデタッチされます。管理ポリシー自体は削除されません。 (I)ListGroupsForUser > RemoveUserFromGroup ListGroupsForUser で所属しているIAMグループ一覧を取得し、見つかればそれぞれについて RemoveUserFromGroup で所属が解除されます。IAMグループ自体は削除されません。 DeleteUser 以上のアイテムが全て削除されると、最後に DeleteUser が呼ばれてユーザー本体が晴れて（？）削除されます。画面では数クリックで終わる操作ですが、実は多くの API が呼ばれていることがわかりますね。 今回の仕組みでカバーする範囲 ユーザー削除時の API コールを参考にして、IAMユーザーを自動削除するための仕組みを作ります。以下ではCDKとLambda関数のコードを解説しますが、今回はIAMユーザー本体の削除に先立って、以下の5つのアイテムの削除のみを行います。 (A)ログインプロファイル (B)アクセスキー (G)インラインポリシー (H)アタッチされている管理ポリシー (I)IAMグループへの所属 (C)(D)(E)(F)についてはコンソールでユーザーを作成する時に同時に作成できないため、今回は省略しています。コンソールでも CLI でも、これらのアイテムを作成するためにはユーザー作成とは別の操作が必要になりますので、その操作が実施される前にEventBridgeイベントが発火し、ユーザーが削除されることが期待できます。もちろん、 CLI などから CreateUser 実行後、EventBridgeイベントが発火する前に(C)(D)(E)(F)を作成する API が素早く実行されるとユーザーの削除に失敗しますので、より確実にユーザーを削除したい場合は(C)(D)(E)(F)の削除も対応した方が良いでしょう。 CDKテンプレート IAMユーザーの作成を検知し、自動削除する仕組みのCDKスタックは次のとおりです。 EventBridgeルールは detailType を AWS API Call via CloudTrail 、 eventName を CreateUser にすることで、ユーザー作成 API の呼び出しがCloudTrailに記録されるとイベントが起動します。 前述の通り、IAMの更新系 API は us-east-1 リージョンのCloudTrailに記録されるので、このスタックも us-east-1 リージョンにデプロイする必要があります。 import { Duration , Stack , StackProps } from "aws-cdk-lib" ; import * as events from "aws-cdk-lib/aws-events" ; import * as eventTargets from "aws-cdk-lib/aws-events-targets" ; import * as iam from "aws-cdk-lib/aws-iam" ; import { Runtime } from "aws-cdk-lib/aws-lambda" ; import * as lambdaNodejs from "aws-cdk-lib/aws-lambda-nodejs" ; import { Construct } from "constructs" ; export class DeleteUserStack extends Stack { constructor( scope: Construct , id: string , props?: StackProps ) { super( scope , id , props ); // Lambda関数 const deleteUserFunction = new lambdaNodejs.NodejsFunction ( this , "DeleteUserFunction" , { entry: "functions/delete-user.ts" , runtime: Runtime.NODEJS_16_X , timeout: Duration.minutes ( 15 ), } ); // 必要なActionを追加 deleteUserFunction.addToRolePolicy ( new iam.PolicyStatement ( { resources: [ "*" ] , actions: [ "iam:DeleteUser" , "iam:ListAccessKeys" , "iam:DeleteAccessKey" , "iam:ListGroupsForUser" , "iam:RemoveUserFromGroup" , "iam:GetLoginProfile" , "iam:DeleteLoginProfile" , "iam:ListAttachedUserPolicies" , "iam:DetachUserPolicy" , "iam:ListUserPolicies" , "iam:DeleteUserPolicy" , ] , effect: iam.Effect.ALLOW , } ) ); // EventBrdigeルール new events.Rule ( this , "CreateUserEventRule" , { ruleName: "create-user" , eventPattern: { source: [ "aws.iam" ] , detailType: [ "AWS API Call via CloudTrail" ] , detail: { eventSource: [ "iam.amazonaws.com" ] , eventName: [ "CreateUser" ] , } , } , targets: [ new eventTargets.LambdaFunction ( deleteUserFunction ) ] , } ); } } Lambda関数 functions/delete-user.ts のLambda関数の実装を説明します。 パッケージからのインポートとIAMClientの生成 IAM用の SDK をインポートします。Lambda関数が受け取るのはEventBridgeイベントなので、 aws-lambda パッケージから EventBridgeEvent もインポートします。 IAMClientは us-east-1 リージョン向けに生成します。 import * as iam from "@aws-sdk/client-iam" ; import { Handler , EventBridgeEvent } from "aws-lambda" ; const client = new iam.IAMClient ( { region: "us-east-1" } ); (A)ログインプロファイルの削除 ログインプロファイルを削除する関数です。最初に GetLoginProfileCommand でログインプロファイルが存在するかどうかを確認し、存在すれば while ループで削除を試みます。while ループにしている理由は、プロファイルの作成には時間がかかるようで、 CreateLoginProfile コール直後に DeleteLoginProfile をしても次のエラーになってしまうためです。 Login Profile for User <ユーザー名> cannot be modified while login profile is being created. そこで while ループで間に5秒間ずつ待機し、最大30回削除を試みる実装にしました。実際にやってみると、体感的にログインプロファイル作成後15秒ほどで削除できる状態になっていました。 export const deleteLoginProfile = async ( userName: string ) : Promise < void > => { try { const { LoginProfile } = await client.send (new iam.GetLoginProfileCommand ( { UserName: userName } )); if ( LoginProfile === undefined || LoginProfile.UserName === undefined ) return; } catch ( e: unknown ) { console .log ( ` ${ e instanceof Error ? e.message : "" } ` ); return; } let attempts = 30 ; while ( attempts > 0 ) { try { await client.send (new iam.DeleteLoginProfileCommand ( { UserName: userName } )); break; } catch ( e: unknown ) { console .log ( ` ${ e instanceof Error ? e.message : "" } ` ); } await new Promise (( resolve ) => setTimeout ( resolve , 5000 )); attempts --; } } ; (B)アクセスキーの削除 次の関数でアクセスキーを削除します。まずは ListAccessKeysCommand でアクセスキー一覧を取得します。アクセスキーの件数が多い場合（実際には各ユーザー2つまでなので起こらないと思いますが）、一回の ListAccessKeysCommand 呼び出しで全件取得できず、結果の IsTruncated プロパティが true で返ってきます。この時の Marker プロパティを次の ListAccessKeysCommand 呼び出しのパラメータに含めることで、続きの結果を取得できます。一覧取得後は DeleteAccessKeyCommand で1つずつ削除します。 export const deleteAccessKeys = async ( userName: string ) : Promise < void > => { let accessKeyIds: string [] = [] ; let shouldListNext = true ; let Marker: string | undefined = undefined ; while ( shouldListNext ) { const params: iam.ListAccessKeysCommandInput = { UserName: userName , Marker } ; const output = await client.send (new iam.ListAccessKeysCommand ( params )); if ( output.AccessKeyMetadata ) { accessKeyIds = accessKeyIds.concat ( output.AccessKeyMetadata.filter (( accessKeyMetadata ) => accessKeyMetadata.AccessKeyId ) .map ( ( accessKeyMetadata ) => accessKeyMetadata.AccessKeyId ! ) ); } output.IsTruncated ? ( Marker = output.Marker ) : ( shouldListNext = false ); } if ( accessKeyIds.length === 0 ) return; await Promise . all( accessKeyIds.map (async ( keyId ) => { await client.send (new iam.DeleteAccessKeyCommand ( { UserName: userName , AccessKeyId: keyId } )); } ) ); } ; (G)インラインポリシーの削除 (B)アクセスキーの削除 と同様の処理なので、説明は割愛します。 export const deleteUserPolicies = async ( userName: string ) : Promise < void > => { let policyNames: string [] = [] ; let shouldListNext = true ; let Marker: string | undefined = undefined ; while ( shouldListNext ) { const params: iam.ListUserPoliciesCommandInput = { UserName: userName , Marker } ; const output = await client.send (new iam.ListUserPoliciesCommand ( params )); if ( output.PolicyNames ) { policyNames = policyNames.concat ( output.PolicyNames.filter (( name ) => name )); } output.IsTruncated ? ( Marker = output.Marker ) : ( shouldListNext = false ); } if ( policyNames.length === 0 ) return; await Promise . all( policyNames.map (async ( name ) => { await client.send (new iam.DeleteUserPolicyCommand ( { UserName: userName , PolicyName: name } )); } ) ); } ; (H)管理ポリシーのデタッチ 同様の処理なので、説明は割愛します。 export const detachUserPolicies = async ( userName: string ) : Promise < void > => { let attachedPolicieArns: string [] = [] ; let shouldListNext = true ; let Marker: string | undefined = undefined ; while ( shouldListNext ) { const params: iam.ListAttachedUserPoliciesCommandInput = { UserName: userName , Marker } ; const output = await client.send (new iam.ListAttachedUserPoliciesCommand ( params )); if ( output.AttachedPolicies ) { attachedPolicieArns = attachedPolicieArns.concat ( output.AttachedPolicies.filter (( policy ) => policy.PolicyArn ) .map (( policy ) => policy.PolicyArn ! ) ); } output.IsTruncated ? ( Marker = output.Marker ) : ( shouldListNext = false ); } if ( attachedPolicieArns.length === 0 ) return; await Promise . all( attachedPolicieArns.map (async ( arn ) => { await client.send (new iam.DetachUserPolicyCommand ( { UserName: userName , PolicyArn: arn } )); } ) ); } ; (I)IAMグループへの所属解除 同様の処理なので、説明は割愛します。 export const removeUserFromGroups = async ( userName: string ) : Promise < void > => { let groupNames: string [] = [] ; let shouldListNext = true ; let Marker: string | undefined = undefined ; while ( shouldListNext ) { const params: iam.ListGroupsForUserCommandInput = { UserName: userName , Marker } ; const output = await client.send (new iam.ListGroupsForUserCommand ( params )); if ( output.Groups ) { groupNames = groupNames.concat ( output.Groups.filter (( group ) => group.GroupName ) .map (( group ) => group.GroupName ! )); } output.IsTruncated ? ( Marker = output.Marker ) : ( shouldListNext = false ); } if ( groupNames.length === 0 ) return; await Promise . all( groupNames.map (async ( groupName ) => { await client.send (new iam.RemoveUserFromGroupCommand ( { UserName: userName , GroupName: groupName } )); } ) ); } ; Lambdaハンドラ 作成されたIAMユーザー名をイベントの中身から取得するための型を定義し、上で説明した関数を利用してLambdaハンドラを実装します。各アイテムの削除後に DeleteUserCommand でユーザー本体を削除します。 type Detail = { responseElements: { user: { userName: string } } } ; export const handler: Handler = async ( event: EventBridgeEvent < string , Detail >) => { const userName = event.detail.responseElements.user.userName ; await Promise . all( [ deleteLoginProfile ( userName ), deleteAccessKeys ( userName ), deleteUserPolicies ( userName ), detachUserPolicies ( userName ), removeUserFromGroups ( userName ), ] ); await client.send (new iam.DeleteUserCommand ( { UserName: userName } )); } ; これで、IAMユーザーが作成されるイベントをトリガーに、即座にユーザーを削除する仕組みが完成しました。 さいごに 自前で自動化の仕組みを実装してみると、普段コンソールでしている操作の裏側でどのような API が動いているのかが分かり、とても面白かったです。 最後までお読みただいてありがとうございました。 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 - セキュリティエンジニア(セキュリティ設計) 執筆： @kou.kinyo2 、レビュー： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、A as Bの呪文による画像合成の呪文です。 やまかずさんの 日刊 画像生成AI (2022年9月29日) の記事で紹介されていた 「A as B」は有効 を今回は検証してみました。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 A as Bの呪文とは まとめ 仲間募集 Stable Diffusionの過去コンテンツ A as Bの呪文とは A as Bの呪文は、AをBとして描画するというものです。Aの画像にBの画像が合成されたような効果が出ます。 例えば、次のような beautiful girl as cat の呪文を試してみましょう。 今回の呪文（横長、コピー&ペースト用） illustration of beautiful girl as cat detailed beautiful face detailed hair detailed perfect pupil of eyes detailed mouth detailed shoulders detailed bust looking far away highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） illustration of beautiful girl as cat detailed beautiful face detailed hair detailed perfect pupil of eyes detailed mouth detailed shoulders detailed bust looking far away highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting トーク ン出力結果（改行版） 長い呪文は切り捨てられる編 参照 42 ['illustration</w>', 'of</w>', 'beautiful</w>', 'girl</w>', 'as</w>', 'cat</w>', 'detailed</w>', 'beautiful</w>', 'face</w>', 'detailed</w>', 'hair</w>', 'detailed</w>', 'perfect</w>', 'pupil</w>', 'of</w>', 'eyes</w>', 'detailed</w>', 'mouth</w>', 'detailed</w>', 'shoulders</w>', 'detailed</w>', 'bust</w>', 'looking</w>', 'far</w>', 'away</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'fantasy</w>', 'scene</w>', 'fantasy</w>', 'composition</w>', 'fantasy</w>', 'lighting</w>'] 画像出力結果 実は、この結果は、50回試して一回出るくらいの奇跡的な画像です。Aを人間、Bを動物にした場合、動物が耳に特徴があると、3, 4回に一回くらい、耳だけが人間に取り込まれます。 Bが犬など、耳にそれほど特徴がない場合、BがAに取り込まれる可能性がかなり減ります。 まとめ A as Bは、再現性が低いですが、うまくいくと面白い画像が作成できると言ったところでしょうか。 次回は、 かわいい動物の擬人化編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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シリーズ、今回は、A as Bの呪文による画像合成の呪文です。 やまかずさんの 日刊 画像生成AI (2022年9月29日) の記事で紹介されていた 「A as B」は有効 を今回は検証してみました。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 A as Bの呪文とは まとめ 仲間募集 Stable Diffusionの過去コンテンツ A as Bの呪文とは A as Bの呪文は、AをBとして描画するというものです。Aの画像にBの画像が合成されたような効果が出ます。 例えば、次のような beautiful girl as cat の呪文を試してみましょう。 今回の呪文（横長、コピー&ペースト用） illustration of beautiful girl as cat detailed beautiful face detailed hair detailed perfect pupil of eyes detailed mouth detailed shoulders detailed bust looking far away highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） illustration of beautiful girl as cat detailed beautiful face detailed hair detailed perfect pupil of eyes detailed mouth detailed shoulders detailed bust looking far away highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting トーク ン出力結果（改行版） 長い呪文は切り捨てられる編 参照 42 ['illustration</w>', 'of</w>', 'beautiful</w>', 'girl</w>', 'as</w>', 'cat</w>', 'detailed</w>', 'beautiful</w>', 'face</w>', 'detailed</w>', 'hair</w>', 'detailed</w>', 'perfect</w>', 'pupil</w>', 'of</w>', 'eyes</w>', 'detailed</w>', 'mouth</w>', 'detailed</w>', 'shoulders</w>', 'detailed</w>', 'bust</w>', 'looking</w>', 'far</w>', 'away</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'fantasy</w>', 'scene</w>', 'fantasy</w>', 'composition</w>', 'fantasy</w>', 'lighting</w>'] 画像出力結果 実は、この結果は、50回試して一回出るくらいの奇跡的な画像です。Aを人間、Bを動物にした場合、動物が耳に特徴があると、3, 4回に一回くらい、耳だけが人間に取り込まれます。 Bが犬など、耳にそれほど特徴がない場合、BがAに取り込まれる可能性がかなり減ります。 まとめ A as Bは、再現性が低いですが、うまくいくと面白い画像が作成できると言ったところでしょうか。 次回は、 かわいい動物の擬人化編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 で執筆されました ）