電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、美しい夜空を見渡す男の呪文です。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 black silhuette of a man shot from the back sitting on the ground looking out into the sky colorful vibrant cosmos space, stars, nebula beautiful composition, beautiful soft purple blue lighting, cinematic lighting SIGMA art lens 24 mm F/1.4, ISO 1000, award-winning, concept art black cliff, sunrise まとめ 仲間募集 Stable Diffusionの過去コンテンツ black silhuette of a man 最初は、シンプルな黒いシルエット（silhuette）の男のPrompt（呪文）ではじめましょう。星を見上げる男は、黒いシルエットのほうが雰囲気が出ます。 今回のPrompt（呪文）はこちら。 black silhuette of a man 出力された結果はこちら。 シンプルなPrompt（呪文）ですが、意外と雰囲気が出ていますね。 shot from the back 星空を見上げる男は、後ろから撮影し（shot from the back）、背景にきれいな夜空が広がっているような構図にしましょう。今回は、shot from the backのみを追加します。 今回のPrompt（呪文）はこちら。 black silhuette of a man, shot from the back 出力された結果はこちら。 sitting on the ground 男を地面に座らせましょう。sitting on the groundを追加します。 サブジ ェクト（メインとなる描画対象）に動作を付け加える場合、 , 動詞のing ... を加えます。複数の動作を追加する場合も、 , 動詞1のing ..., 動詞2のing ... のように記述します。 今回のPrompt（呪文）はこちら。 black silhuette of a man, sitting on the ground, shot from the back 出力された結果はこちら。 looking out into the sky 男が空を見渡すようにしてみましょう。looking out into the skyを追加します。 今回のPrompt（呪文）はこちら。 black silhuette of a man, sitting on the ground, looking out into the sky, shot from the back 出力された結果はこちら。 colorful vibrant cosmos space, stars, nebula 空を美しい夜空にしてみましょう。the skyをcolorful vibrant（活気のある） cosmos space（宇宙空間）, stars, nebula（星雲）に変更します。 今回のPrompt（呪文）はこちら。 black silhuette of a man, sitting on the ground, looking out into colorful vibrant cosmos space, stars, nebula, shot from the back 出力された結果はこちら。 beautiful composition, beautiful soft purple blue lighting, cinematic lighting 画像のクオリティを上げるためには、服装、背景、構図、ライティングの指定が必要です。 今回、服装は必要なく、背景はすでに指定済みなので、構図とライティングを指定します。 構図は、beautiful compositionで良いでしょう。 ライティングは、定番のcinematic lightingにbeautiful soft purple blue lightingを追加しました。 今回のPrompt（呪文）はこちら。 black silhuette of a man, sitting on the ground, looking out into colorful vibrant cosmos space, stars, nebula, shot from the back, beautiful composition, beautiful soft purple blue lighting, cinematic lighting 出力された結果はこちら。 SIGMA art lens 24 mm F/1.4, ISO 1000, award-winning, concept art これまで、画像のタイプを指定していませんでした。画像のタイプを指定しない場合、Stable DiffusionがPrompt（呪文）の内容から判断して決めます。今回は、写真にするために、 SIGMA art lensを指定しましょう。 レンズについて詳しく知りたい方は、 レンズ編 を御覧ください。レンズ編を書いた後の研究で、art lensをつけたほうが、出力結果のクオリティが若干上がることがわかったので、art lensを追加しています。 美しい夜空を広く撮りたいので、広角レンズとして24 mmの 焦点距離 を選びました。 暗い場所の撮影なので、明るいレンズ（F/1.4）を選び、 ISO感度 に1000を指定しました。 最近の記事で結構つけ忘れていましたが、アニメ以外の画像は、award-winning, concept artをつけたほうが、クオリティが上がります。 今回のPrompt（呪文）はこちら。 black silhuette of a man, sitting on the ground, looking out into colorful vibrant cosmos space, stars, nebula, shot from the back, beautiful composition, beautiful soft purple blue lighting, cinematic lighting, SIGMA art lens 24 mm F/1.4, ISO 1000, award-winning, concept art 出力された結果はこちら。 black cliff, sunrise the ground（地面）だと指定がアバウトすぎて、出力が安定しないので、一つ前の画像を見て思いついたblack cliff（崖）に変えることにします。 時間帯にsunrise（日の出）を指定して、美しい夜空と日の出が溶け込んでいる瞬間を狙います。 今回のPrompt（呪文）はこちら。 black silhuette of a man, sitting on black cliff, looking out into colorful vibrant cosmos space, stars, nebula, shot from the back, beautiful composition, beautiful soft purple blue lighting, cinematic lighting, sunrise, SIGMA art lens 24 mm F/1.4, ISO 1000, award-winning, concept art 出力された画像はこちら。 まとめ クオリティの高い画像を出力するには、 サブジ ェクト（描画対象）、背景、構図、ライティングを きちんと指定することが必要です。指定しなくても、たまたまクオリティの高い画像が出力されることもありますが、あくまでも「たまたま」です。 サブジ ェクト（描画対象）、背景、構図、ライティングは、常に意識しましょう。背景、構図、ライティングは、パターンが決まっているので、早めに覚えてしまいましょう。 次回は、 魅惑的な女アニメ画（トゥーンレンダリング）編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 illustration of a gorgeous woman beautiful face, long waved hair, cute eyes artstation, deviantart, concept art, digital painting beautiful woman, pixiv, light novel, concept art, digital painting upper shot, beautiful costume, fantasy background, beautiful composition, cinematic lighting extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing, shot from below, overhead sunlight golden hour, overhead sunlight, soft lighting lit from below, blue hour, beautiful stars, soft lighting まとめ 仲間募集 Stable Diffusionの過去コンテンツ illustration of a gorgeous woman イラストを描画するには、illustration ofをつかいます。 海外の事例を見ていると女性に使う形容詞は、beautifulよりgorgeousが多いようです。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman 出力結果はこちら。 味はありますが、もっと呪文を足す必要がありそうですね。 beautiful face, long waved hair, cute eyes 人物を描画するときに、顔（face）と目（eyes）は指定したほうが出力が安定します。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman, beautiful face, long waved hair, cute eyes 出力結果はこちら。 artstation, deviantart , concept art, digital painting 作風を指定しましょう。 artstationは、アーティストが自分の作品を公開する場です。 deviantart は、アーティストのコミュニティで、自分の作品を投稿できます。 海外の人物の場合、artstation, deviantart を指定すると良いでしょう。 concept art, digital paintingは指定したほうが、出力が安定します。アニメの場合、concept artとは、相性が悪いのですが、アニメ以外の場合は、concept artはつけておいたほうがいいです。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman, beautiful face, long waved hair, cute eyes, artstation, deviantart, concept art, digital painting 出力結果はこちら。 beautiful woman, pixiv, light novel, concept art, digital painting 描画対象が日本人の場合、作風はどのように指定すればいいのでしょうか。 artstation, deviantart のかわりに、pixiv, light novelを指定するといいでしょう。 日本人の場合、womanの形容詞は、gorgeousよりもbeautifulのほうが安定します。 今回のPrompt（呪文）はこちら。 illustration of a beautiful woman, beautiful face, long waved hair, cute eyes, pixiv, light novel, concept art, digital painting 出力結果はこちら。 upper shot, beautiful costume, fantasy background, beautiful composition, cinematic lighting いい感じの人物像を出力するためには、服装（costume）、背景（background）、構図（composition）、ライティング（lighting）をきちんと指定することが重要です。 upper shotで、上半身を描画します。これがないと顔が大きく描画されて、服装や背景が描画されなくなることが多いです。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman, upper shot, beautiful face, long waved hair, cute eyes, beautiful costume, fantasy background, beautiful composition, cinematic lighting, artstation, deviantart, concept art, digital painting 出力結果はこちら。 人物だけの画像より、アートっぽさが増してますね。 extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing, shot from below, overhead sunlight ここから仕上げです。 extremely detailed, sharp focusで、 サブジ ェクト（描画対象）を詳細に描画し、ピントを当てます。 ray tracing, 8kで、現実に近い映像を作り出します。 cinematic postprocessingで、映画レベルまでクオリティをあげます。 shot from belowで、ちょい下から撮影し、overhead sunlightで頭の上から日光が当たるような効果を加えます。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman, upper shot, shot from below, beautiful face, long waved hair, cute eyes, beautiful costume, fantasy background, beautiful composition, overhead sunlight, cinematic lighting, artstation, deviantart, concept art, digital painting, extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing 出力結果はこちら。 golden hour, overhead sunlight, soft lighting 先程のoverhead sunlight, cinematic lightingの画像は、ライティングがきついと感じた方もいるかも知れません。そういう場合は、soft lightingを指定します。 先程の画像は、偶然、夕暮れ時の画像でしたが、再現性を上げるために、golden hourを指定します。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman, upper shot, shot from below, beautiful face, long waved hair, cute eyes, beautiful costume, fantasy background, beautiful composition, golden hour, overhead sunlight, soft lighting, artstation, deviantart, concept art, digital painting, extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing 出力結果はこちら。 lit from below, blue hour, beautiful stars, soft lighting blue hourというのは、日の出前の一時間、日の入り後の一時間の時間帯です。 lit from belowで下から光を当てます。 beautiful starsで、美しい星を出します。 今回のPromptはこちら。 illustration of a gorgeous woman lit from below, upper shot, shot from below, beautiful face, long waved hair, cute eyes, beautiful costume, beautiful background, blue hour, beautiful stars, beautiful composition, soft lighting, artstation, deviantart, concept art, digital painting, extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing 出力結果はこちら。 まとめ 今回は、女性のイラストのPrompt（呪文）を学びました。 服装、背景、構図、ライティングは、人物画には、必須だということがわかっていただけたと思います。 次回は、 美しい夜空を見渡す男編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 illustration of a gorgeous woman beautiful face, long waved hair, cute eyes artstation, deviantart, concept art, digital painting beautiful woman, pixiv, light novel, concept art, digital painting upper shot, beautiful costume, fantasy background, beautiful composition, cinematic lighting extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing, shot from below, overhead sunlight golden hour, overhead sunlight, soft lighting lit from below, blue hour, beautiful stars, soft lighting まとめ 仲間募集 Stable Diffusionの過去コンテンツ illustration of a gorgeous woman イラストを描画するには、illustration ofをつかいます。 海外の事例を見ていると女性に使う形容詞は、beautifulよりgorgeousが多いようです。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman 出力結果はこちら。 味はありますが、もっと呪文を足す必要がありそうですね。 beautiful face, long waved hair, cute eyes 人物を描画するときに、顔（face）と目（eyes）は指定したほうが出力が安定します。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman, beautiful face, long waved hair, cute eyes 出力結果はこちら。 artstation, deviantart , concept art, digital painting 作風を指定しましょう。 artstationは、アーティストが自分の作品を公開する場です。 deviantart は、アーティストのコミュニティで、自分の作品を投稿できます。 海外の人物の場合、artstation, deviantart を指定すると良いでしょう。 concept art, digital paintingは指定したほうが、出力が安定します。アニメの場合、concept artとは、相性が悪いのですが、アニメ以外の場合は、concept artはつけておいたほうがいいです。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman, beautiful face, long waved hair, cute eyes, artstation, deviantart, concept art, digital painting 出力結果はこちら。 beautiful woman, pixiv, light novel, concept art, digital painting 描画対象が日本人の場合、作風はどのように指定すればいいのでしょうか。 artstation, deviantart のかわりに、pixiv, light novelを指定するといいでしょう。 日本人の場合、womanの形容詞は、gorgeousよりもbeautifulのほうが安定します。 今回のPrompt（呪文）はこちら。 illustration of a beautiful woman, beautiful face, long waved hair, cute eyes, pixiv, light novel, concept art, digital painting 出力結果はこちら。 upper shot, beautiful costume, fantasy background, beautiful composition, cinematic lighting いい感じの人物像を出力するためには、服装（costume）、背景（background）、構図（composition）、ライティング（lighting）をきちんと指定することが重要です。 upper shotで、上半身を描画します。これがないと顔が大きく描画されて、服装や背景が描画されなくなることが多いです。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman, upper shot, beautiful face, long waved hair, cute eyes, beautiful costume, fantasy background, beautiful composition, cinematic lighting, artstation, deviantart, concept art, digital painting 出力結果はこちら。 人物だけの画像より、アートっぽさが増してますね。 extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing, shot from below, overhead sunlight ここから仕上げです。 extremely detailed, sharp focusで、 サブジ ェクト（描画対象）を詳細に描画し、ピントを当てます。 ray tracing, 8kで、現実に近い映像を作り出します。 cinematic postprocessingで、映画レベルまでクオリティをあげます。 shot from belowで、ちょい下から撮影し、overhead sunlightで頭の上から日光が当たるような効果を加えます。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman, upper shot, shot from below, beautiful face, long waved hair, cute eyes, beautiful costume, fantasy background, beautiful composition, overhead sunlight, cinematic lighting, artstation, deviantart, concept art, digital painting, extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing 出力結果はこちら。 golden hour, overhead sunlight, soft lighting 先程のoverhead sunlight, cinematic lightingの画像は、ライティングがきついと感じた方もいるかも知れません。そういう場合は、soft lightingを指定します。 先程の画像は、偶然、夕暮れ時の画像でしたが、再現性を上げるために、golden hourを指定します。 今回のPrompt（呪文）はこちら。 illustration of a gorgeous woman, upper shot, shot from below, beautiful face, long waved hair, cute eyes, beautiful costume, fantasy background, beautiful composition, golden hour, overhead sunlight, soft lighting, artstation, deviantart, concept art, digital painting, extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing 出力結果はこちら。 lit from below, blue hour, beautiful stars, soft lighting blue hourというのは、日の出前の一時間、日の入り後の一時間の時間帯です。 lit from belowで下から光を当てます。 beautiful starsで、美しい星を出します。 今回のPromptはこちら。 illustration of a gorgeous woman lit from below, upper shot, shot from below, beautiful face, long waved hair, cute eyes, beautiful costume, beautiful background, blue hour, beautiful stars, beautiful composition, soft lighting, artstation, deviantart, concept art, digital painting, extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing 出力結果はこちら。 まとめ 今回は、女性のイラストのPrompt（呪文）を学びました。 服装、背景、構図、ライティングは、人物画には、必須だということがわかっていただけたと思います。 次回は、 美しい夜空を見渡す男編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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で美しい女性のポートレートを描く の記事が素晴らしかったので、思いついた企画です。まだ、見ていない方は是非ご覧ください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文 美少女アニメ画 美少女写真編 女性イラスト 魅惑的な女アニメ画（トゥーンレンダリング） 長い呪文は切り捨てられる photo of a beautiful girl, SIGMA 85 mm F/1.4 beautiful face, long waved hair, cute eyes beautiful costume, beautiful background, beautiful composition, dramatic lighting full body portrait, golden hour, overhead sunlight, SIGMA art lens 35 mm F/1.4 lit from below, shot from below, night, soft lighting night town, bloom light, soft lighting cute closed eyes, colorful vibrant cosmos space, stars, nebula, beautiful soft purple blue lighting まとめ 仲間募集 Stable Diffusionの過去コンテンツ photo of a beautiful girl, SIGMA 85 mm F/1.4 レンズ編 で説明したとおり、今回の撮影に使うレンズは、 SIGMA 85 mm F/1.4です。 まずはシンプルなPromptで始めてみましょう。 photo of a beautiful girl, SIGMA 85 mm F/1.4 出力された結果はこちら。 ちょっと目が変な気がしますね。 beautiful face, long waved hair, cute eyes Stable Diffusionの出力する人物は、ときたま目が変なことがあります。cute eyesを指定しておくと、出力が安定します。 beautiful faceもつけておいたほうが出力が安定するので、つけておきましょう。 long waved hairはなくても構いません。僕の好みです。 今回のPromptはこちら。 photo of a beautiful girl, beautiful face, long waved hair, cute eyes, SIGMA 85 mm F/1.4 出力された結果はこちら。 いい感じですが、背景がないので、ちょっと単調です。 beautiful costume, beautiful background, beautiful composition, dramatic lighting 美少女アニメ画編 で、画像のクオリティを上げるには、服装、背景、構図、ライティングを指定する必要があることを説明しました。これは写真においても同じです。 ライティングは、dramatic lightingにしました。写真以外では、cinematic lightingをつかっていますが、写真では、dramatic lightingのほうが良い結果が出やすい気がします。 今回のPromptはこちら。 photo of a beautiful girl, beautiful face, long waved hair, cute eyes, beautiful costume, beautiful background, beautiful composition, dramatic lighting, SIGMA 85 mm F/1.4 出力された結果はこちら。 ボケもきれいに入っていい感じですね。美少女写真のPromptは、基本的にはこれで完成です。 後は、この基本形を応用してみましょう。 full body portrait, golden hour, overhead sunlight, SIGMA art lens 35 mm F/1.4 体全体を撮すためは、photoにかえて、full body portraitを使います。full bodyという言葉から来る豊満な体の画像が多く、使いづらいキーワード（呪文）ですが、ほかにあまり選択肢がありません。full bodyというキーワードを単独で使っても結果はほとんど一緒です。 体全体を撮す場合、これまで使ってきた SIGMA 85 mmだと撮影対象を大きく撮してしまうので、顔が中心になることが多く、full bodyの意味があまり出ませんでした。 焦点距離 を色々試してみましたが、35 mmが一番安定していました。今回、あまりにもうまく行かないことが多かったので、art lensキーワードを足したところ、若干、安定度が上がりました。 SIGMA の 焦点距離 が、24, 35, 50, 85 mmのレンズには、実際にArtタイプがあります。何度やってもうまく行かないときは、art lensを足してみてください。 体全体を撮す場合、顔から受ける印象が減るので、他に何らかの要素をたさないとつまらない写真になってしまいます。そこで、夕暮れ時（golden hour）に、頭の上から太陽の光が当たる（overhead sunlight）ような効果を入れてみました。 今回のPromptはこちら。 full body portrait of a beautiful girl, beautiful face, long waved hair, cute eyes, beautiful costume, beautiful background, beautiful composition, golden hour, overhead sunlight dramatic lighting, SIGMA art lens 35 mm F/1.4 出力された結果はこちら。 full bodyといっても、脚まで撮すと顔の印象がかなり弱まってしまうので、美少女写真ならこれくらいがよいと思います。 lit from below, shot from below, night, soft lighting lit from belowは、下から光を当てた効果が出ます。 shot from belowで、下から写真を撮ります。 nightで、夜の撮影です。 soft lightingで、ライティングをソフトにします。夜の撮影は、dramatic lightingだと光が強くなりすぎます。 サブジ ェクト（被写体）の下の方から、フラッシュをたいて撮影するけど、フラッシュはきつくならないようにという設定です。 今回のPromptはこちら。 photo of a beautiful girl lit from below, shot from below, beautiful face, long waved hair, cute eyes, beautiful costume, beautiful background, beautiful composition, night, soft lighting, SIGMA 85 mm F/1.4 出力された結果はこちら。 night town, bloom light, soft lighting 夜の街（night town）の撮影で、遠くの光が拡散している（bloom light）というのが、今回のコンセプトです。夜の撮影なので、soft lightingにしましょう。 今回のPromptはこちら。 photo of a beautiful girl, beautiful face, long waved hair, cute eyes, beautiful costume, night town, beautiful composition, bloom light, soft lighting, SIGMA 85 mm F/1.4 出力された結果はこちら。 遠くの光がきれいですね。 cute closed eyes, colorful vibrant cosmos space, stars, nebula, beautiful soft purple blue lighting 幻想的でカラフルな夜空に、女性が溶け込んでいるような画像です。 目はつぶっていたほうが雰囲気が出るので、cute closed eyesを指定しています。 colorful vibrant cosmos space, stars, nebula, beautiful soft purple blue lightingが、幻想的でカラフルな夜空の指定です。 今回のPromptはこちら。 photo of a beautiful girl, beautiful face, long waved hair, cute closed eyes, beautiful costume, colorful vibrant cosmos space, stars, nebula, beautiful soft purple blue lighting, beautiful composition, dramatic lighting, SIGMA 85 mm F/1.4 出力された結果はこちら。 服に夜空が溶け込んでいるのがとても幻想的です。 まとめ 写真においても、 美少女アニメ画編 と同様に、服装、背景、構図、ライティングが重要だということが、わかっていただけたと思います。 そして、One more thing。幻想的でカラフルな夜空に、女性が溶け込んでいるだとか、何か一つアイディアを加えると写真は特別なものになります。 次回は、 女性イラスト編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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で美しい女性のポートレートを描く の記事が素晴らしかったので、思いついた企画です。まだ、見ていない方は是非ご覧ください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文 美少女アニメ画 美少女写真編 女性イラスト 魅惑的な女アニメ画（トゥーンレンダリング） 長い呪文は切り捨てられる photo of a beautiful girl, SIGMA 85 mm F/1.4 beautiful face, long waved hair, cute eyes beautiful costume, beautiful background, beautiful composition, dramatic lighting full body portrait, golden hour, overhead sunlight, SIGMA art lens 35 mm F/1.4 lit from below, shot from below, night, soft lighting night town, bloom light, soft lighting cute closed eyes, colorful vibrant cosmos space, stars, nebula, beautiful soft purple blue lighting まとめ 仲間募集 Stable Diffusionの過去コンテンツ photo of a beautiful girl, SIGMA 85 mm F/1.4 レンズ編 で説明したとおり、今回の撮影に使うレンズは、 SIGMA 85 mm F/1.4です。 まずはシンプルなPromptで始めてみましょう。 photo of a beautiful girl, SIGMA 85 mm F/1.4 出力された結果はこちら。 ちょっと目が変な気がしますね。 beautiful face, long waved hair, cute eyes Stable Diffusionの出力する人物は、ときたま目が変なことがあります。cute eyesを指定しておくと、出力が安定します。 beautiful faceもつけておいたほうが出力が安定するので、つけておきましょう。 long waved hairはなくても構いません。僕の好みです。 今回のPromptはこちら。 photo of a beautiful girl, beautiful face, long waved hair, cute eyes, SIGMA 85 mm F/1.4 出力された結果はこちら。 いい感じですが、背景がないので、ちょっと単調です。 beautiful costume, beautiful background, beautiful composition, dramatic lighting 美少女アニメ画編 で、画像のクオリティを上げるには、服装、背景、構図、ライティングを指定する必要があることを説明しました。これは写真においても同じです。 ライティングは、dramatic lightingにしました。写真以外では、cinematic lightingをつかっていますが、写真では、dramatic lightingのほうが良い結果が出やすい気がします。 今回のPromptはこちら。 photo of a beautiful girl, beautiful face, long waved hair, cute eyes, beautiful costume, beautiful background, beautiful composition, dramatic lighting, SIGMA 85 mm F/1.4 出力された結果はこちら。 ボケもきれいに入っていい感じですね。美少女写真のPromptは、基本的にはこれで完成です。 後は、この基本形を応用してみましょう。 full body portrait, golden hour, overhead sunlight, SIGMA art lens 35 mm F/1.4 体全体を撮すためは、photoにかえて、full body portraitを使います。full bodyという言葉から来る豊満な体の画像が多く、使いづらいキーワード（呪文）ですが、ほかにあまり選択肢がありません。full bodyというキーワードを単独で使っても結果はほとんど一緒です。 体全体を撮す場合、これまで使ってきた SIGMA 85 mmだと撮影対象を大きく撮してしまうので、顔が中心になることが多く、full bodyの意味があまり出ませんでした。 焦点距離 を色々試してみましたが、35 mmが一番安定していました。今回、あまりにもうまく行かないことが多かったので、art lensキーワードを足したところ、若干、安定度が上がりました。 SIGMA の 焦点距離 が、24, 35, 50, 85 mmのレンズには、実際にArtタイプがあります。何度やってもうまく行かないときは、art lensを足してみてください。 体全体を撮す場合、顔から受ける印象が減るので、他に何らかの要素をたさないとつまらない写真になってしまいます。そこで、夕暮れ時（golden hour）に、頭の上から太陽の光が当たる（overhead sunlight）ような効果を入れてみました。 今回のPromptはこちら。 full body portrait of a beautiful girl, beautiful face, long waved hair, cute eyes, beautiful costume, beautiful background, beautiful composition, golden hour, overhead sunlight dramatic lighting, SIGMA art lens 35 mm F/1.4 出力された結果はこちら。 full bodyといっても、脚まで撮すと顔の印象がかなり弱まってしまうので、美少女写真ならこれくらいがよいと思います。 lit from below, shot from below, night, soft lighting lit from belowは、下から光を当てた効果が出ます。 shot from belowで、下から写真を撮ります。 nightで、夜の撮影です。 soft lightingで、ライティングをソフトにします。夜の撮影は、dramatic lightingだと光が強くなりすぎます。 サブジ ェクト（被写体）の下の方から、フラッシュをたいて撮影するけど、フラッシュはきつくならないようにという設定です。 今回のPromptはこちら。 photo of a beautiful girl lit from below, shot from below, beautiful face, long waved hair, cute eyes, beautiful costume, beautiful background, beautiful composition, night, soft lighting, SIGMA 85 mm F/1.4 出力された結果はこちら。 night town, bloom light, soft lighting 夜の街（night town）の撮影で、遠くの光が拡散している（bloom light）というのが、今回のコンセプトです。夜の撮影なので、soft lightingにしましょう。 今回のPromptはこちら。 photo of a beautiful girl, beautiful face, long waved hair, cute eyes, beautiful costume, night town, beautiful composition, bloom light, soft lighting, SIGMA 85 mm F/1.4 出力された結果はこちら。 遠くの光がきれいですね。 cute closed eyes, colorful vibrant cosmos space, stars, nebula, beautiful soft purple blue lighting 幻想的でカラフルな夜空に、女性が溶け込んでいるような画像です。 目はつぶっていたほうが雰囲気が出るので、cute closed eyesを指定しています。 colorful vibrant cosmos space, stars, nebula, beautiful soft purple blue lightingが、幻想的でカラフルな夜空の指定です。 今回のPromptはこちら。 photo of a beautiful girl, beautiful face, long waved hair, cute closed eyes, beautiful costume, colorful vibrant cosmos space, stars, nebula, beautiful soft purple blue lighting, beautiful composition, dramatic lighting, SIGMA 85 mm F/1.4 出力された結果はこちら。 服に夜空が溶け込んでいるのがとても幻想的です。 まとめ 写真においても、 美少女アニメ画編 と同様に、服装、背景、構図、ライティングが重要だということが、わかっていただけたと思います。 そして、One more thing。幻想的でカラフルな夜空に、女性が溶け込んでいるだとか、何か一つアイディアを加えると写真は特別なものになります。 次回は、 女性イラスト編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 イノベーション 本部 クラウド イノベーション センターの柴田です。 本記事ではkustomizeでCustom Resourceを扱う方法を紹介します。 kustomizeとは kustomizeでCustom Resourceを適切に扱う kustomizeはデフォルトでCustom Resourceを適切に扱えない kustomizeでCustom Resourceを適切に扱う kustomizeで標準リソースとCustom Resourceを適切に扱う 独自のOpenAPIスキーマを設定すると標準リソースを適切に扱えなくなる kustomizeで標準リソースとCustom Resourceを適切に扱う 終わりに 参考 kustomizeとは kustomize は Kubernetes の マニフェスト ファイルを加工・生成するためのツールです。 ユースケース として例えば環境毎（開発や本番など）に マニフェスト の設定を上書きしたい場合などに利用できます。 kustomizeは内部に Kubernetes の標準リソース（ Deployment など）の スキーマ を保持しています。 これにより標準リソースの マニフェスト を適切に加工できます。 例をみてみましょう。今回は以下の Deployment リソースをkustomizeで加工します。 # deployment.yaml apiVersion : apps/v1 kind : Deployment metadata : name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp template : metadata : labels : app.kubernetes.io/name : myapp spec : containers : - name : myapp image : myapp:stable env : - name : KEY1 value : VALUE1 - name : KEY2 value : VALUE2 - name : mysidecar image : mysidecar:stable 同一 ディレクト リに kustomization.yaml を作成します。設定内容は以下のとおりです。 commonLabels で全体に app.kubernetes.io/name: myapp-overwrite labelを設定します。 patches で myapp コンテナに 環境変数 KEY2=VALUE2-overwrite を設定します。 # kustomization.yaml (for deployment) apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization commonLabels : app.kubernetes.io/name : myapp-overwrite resources : - deployment.yaml patches : - patch : |- apiVersion : apps/v1 kind : Deployment metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite kustomize build コマンドを実行すると以下の結果が出力されます。 Deployment が期待通り加工されました。 # Output of `kustomize build` command. apiVersion : apps/v1 kind : Deployment metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite - name : KEY1 value : VALUE1 image : myapp:stable name : myapp - image : mysidecar:stable name : mysidecar ここでのポイントは以下の2点です。 containers や env について、単に配列をまるごと上書きするのではなく、 name の値をキーに適切にマージされている。 .metadata.labels だけでなく .spec.selector.matchLabels や .spec.template.metadata.labels にも app.kubernetes.io/name labelが設定されている。 kustomizeでCustom Resourceを適切に扱う kustomizeはデフォルトでCustom Resourceを適切に扱えない kustomizeはデフォルトでCustom Resourceを適切に加工できません。 kustomizeがCustom Resourceの スキーマ を把握していないためです。 例をみてみましょう。今回は Argo Rollouts の Rollout リソースをkustomizeで加工します。 # rollout.yaml apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp template : metadata : labels : app.kubernetes.io/name : myapp spec : containers : - name : myapp image : myapp:stable env : - name : KEY1 value : VALUE1 - name : KEY2 value : VALUE2 - name : mysidecar image : mysidecar:stable 同一 ディレクト リに kustomization.yaml を作成します。 # kustomization.yaml (for rollout) apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization commonLabels : app.kubernetes.io/name : myapp-overwrite resources : - rollout.yaml patches : - patch : |- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite kustomize build コマンドを実行すると以下の結果が出力されます。 # Output of `kustomize build` command. apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp template : metadata : labels : app.kubernetes.io/name : myapp spec : containers : - env : - name : KEY2 value : VALUE2-overwrite name : myapp 先程の Deployment の例と比較すると以下の点が異なります。 containers や env が patches の内容でまるごと上書きされている。 .spec.selector.matchLabels や .spec.template.metadata.labels の app.kubernetes.io/name labelが更新されていない。 kustomizeでCustom Resourceを適切に扱う kustomzieでCustom Resourceを扱うには、以下の2つの対応を行う必要があります。 kustomizeの OpenAPI Features を使用して、kustomizeにCustom ResourceのOpenAPI スキーマ を設定する。 kustomizeの Transformer Configurations を設定する。 Argo Rolloutsの公式ドキュメント に従って、先程のArgo Rolloutsの例を以下のとおり修正してみましょう。 Argo RolloutsのOpenAPI スキーマ を こちら からダウンロードします。 curl -OL https://github.com/argoproj/argo-rollouts/raw/master/docs/features/kustomize/rollout_cr_schema.json kustomization.yaml に openapi と configurations の設定を追記します。 # kustomization.yaml (for rollout) apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization commonLabels : app.kubernetes.io/name : myapp-overwrite resources : - rollout.yaml patches : - patch : |- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite openapi : path : rollout_cr_schema.json configurations : - https://argoproj.github.io/argo-rollouts/features/kustomize/rollout-transform.yaml kustomize build コマンドを実行すると以下の結果が出力されます。 今度は Rollout リソースが（ほぼ）期待通り加工されました。 なお env は依然として上書きされていますが、これはArgo RolloutsのOpenAPI スキーマ の問題です。 詳細は #1730 をご参照ください。 # Output of `kustomize build` command. apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite image : myapp:stable name : myapp - image : mysidecar:stable name : mysidecar kustomizeで標準リソースとCustom Resourceを適切に扱う 独自のOpenAPI スキーマ を設定すると標準リソースを適切に扱えなくなる kustomizeの OpenAPI Features は、build-inの スキーマ に 加えて 受け取ったOpenAPI スキーマ を参照するのではなく、build-inの スキーマ の かわりに 受け取ったOpenAPI スキーマ を参照します。 そのため kustomization.yaml の openapi に独自のOpenAPI スキーマ を設定すると、kustomizeが Kubernetes の標準リソースの スキーマ を参照できず、適切に加工できなくなります。 例をみてみましょう。今回はkustomizeで Deployment と Rollout の両方を加工します。 deployment.yaml と rollout.yaml は先程の例と同じものを使用します。 # kustomization.yaml (for deployment and rollout) apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization commonLabels : app.kubernetes.io/name : myapp-overwrite resources : - deployment.yaml - rollout.yaml patches : - patch : |- apiVersion : apps/v1 kind : Deployment metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite - patch : |- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite openapi : path : rollout_cr_schema.json configurations : - https://argoproj.github.io/argo-rollouts/features/kustomize/rollout-transform.yaml kustomize build コマンドを実行すると以下の結果が出力されます。 kustomization.yaml の oepnapi にArgo RolloutsのOpenAPI スキーマ を設定したため Rollout は期待通り加工できました。 しかし今度は Deployment の containers や env が patches の内容でまるごと上書きされてしまいました。 # Output of `kustomize build` command. kustomize build . apiVersion : apps/v1 kind : Deployment metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite name : myapp --- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite image : myapp:stable name : myapp - image : mysidecar:stable name : mysidecar kustomizeで標準リソースとCustom Resourceを適切に扱う この問題は 標準リソース Custom Resource の両方のOpenAPI スキーマ を統合して kustomization.yaml の oepnapi に渡すことで解決できます。 先程の例を以下のとおり修正してみましょう。 Kubernetes の標準リソースのOpenAPI スキーマ は こちら からダウンロードできます。 標準リソースとArgo RolloutsのOpenAPI スキーマ を統合する。 curl -sOL https://github.com/kubernetes/kubernetes/raw/master/api/openapi-spec/swagger.json curl -sOL https://github.com/argoproj/argo-rollouts/raw/master/docs/features/kustomize/rollout_cr_schema.json jq -s '.[0] * .[1]' swagger.json rollout_cr_schema.json > openapi.json 作成したファイルを kustomization.yaml の openapi に指定する。 # kustomization.yaml (for deployment and rollout) apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization commonLabels : app.kubernetes.io/name : myapp-overwrite resources : - deployment.yaml - rollout.yaml patches : - patch : |- apiVersion : apps/v1 kind : Deployment metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite - patch : |- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite openapi : path : openapi.json configurations : - https://argoproj.github.io/argo-rollouts/features/kustomize/rollout-transform.yaml kustomize build コマンドを実行すると以下の結果が出力されます。 今度は Deployment と Rollout の両方を期待通り加工できました。 # Output of `kustomize build` command. kustomize build . apiVersion : apps/v1 kind : Deployment metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite - name : KEY1 value : VALUE1 image : myapp:stable name : myapp - image : mysidecar:stable name : mysidecar --- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite image : myapp:stable name : myapp - image : mysidecar:stable name : mysidecar 終わりに 本記事ではkustomizeでCustom Resourceを扱う方法を紹介しました。 本記事がkustomizeを使って Kubernetes を運用する方の役に立てば幸いです。 参考 kustomizeでCRDのpatchesStrategicMergeを動かしてみる - １クール続けるブログ kustomizeでCustomResourceにいい感じにStrategicMergePatchする / StrategicMergePatch to CustomResource with Kustomize - Speaker Deck Using a Custom OpenAPI schema Transformer Configurations KEP-2206: OpenAPI Features in Kustomize openapi | SIG CLI Kustomize - Argo Rollouts - Kubernetes Progressive Delivery Controller Issue with Deployment resource patching when Rollout resources openapi definition is included · Issue #4613 · kubernetes-sigs/kustomize Kustomize fail to merge .spec.template.spec.containers[].env fields · Issue #1730 · argoproj/argo-rollouts 私たちは同じチームで働いてくれる仲間を探しています。 クラウド アーキテクトの業務に興味がある方のご応募をお待ちしています。 クラウドアーキテクト 執筆： @shibata.takao 、レビュー： @sato.taichi （ Shodo で執筆されました ）

こんにちは。X イノベーション 本部 クラウド イノベーション センターの柴田です。 本記事ではkustomizeでCustom Resourceを扱う方法を紹介します。 kustomizeとは kustomizeでCustom Resourceを適切に扱う kustomizeはデフォルトでCustom Resourceを適切に扱えない kustomizeでCustom Resourceを適切に扱う kustomizeで標準リソースとCustom Resourceを適切に扱う 独自のOpenAPIスキーマを設定すると標準リソースを適切に扱えなくなる kustomizeで標準リソースとCustom Resourceを適切に扱う 終わりに 参考 kustomizeとは kustomize は Kubernetes の マニフェスト ファイルを加工・生成するためのツールです。 ユースケース として例えば環境毎（開発や本番など）に マニフェスト の設定を上書きしたい場合などに利用できます。 kustomizeは内部に Kubernetes の標準リソース（ Deployment など）の スキーマ を保持しています。 これにより標準リソースの マニフェスト を適切に加工できます。 例をみてみましょう。今回は以下の Deployment リソースをkustomizeで加工します。 # deployment.yaml apiVersion : apps/v1 kind : Deployment metadata : name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp template : metadata : labels : app.kubernetes.io/name : myapp spec : containers : - name : myapp image : myapp:stable env : - name : KEY1 value : VALUE1 - name : KEY2 value : VALUE2 - name : mysidecar image : mysidecar:stable 同一 ディレクト リに kustomization.yaml を作成します。設定内容は以下のとおりです。 commonLabels で全体に app.kubernetes.io/name: myapp-overwrite labelを設定します。 patches で myapp コンテナに 環境変数 KEY2=VALUE2-overwrite を設定します。 # kustomization.yaml (for deployment) apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization commonLabels : app.kubernetes.io/name : myapp-overwrite resources : - deployment.yaml patches : - patch : |- apiVersion : apps/v1 kind : Deployment metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite kustomize build コマンドを実行すると以下の結果が出力されます。 Deployment が期待通り加工されました。 # Output of `kustomize build` command. apiVersion : apps/v1 kind : Deployment metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite - name : KEY1 value : VALUE1 image : myapp:stable name : myapp - image : mysidecar:stable name : mysidecar ここでのポイントは以下の2点です。 containers や env について、単に配列をまるごと上書きするのではなく、 name の値をキーに適切にマージされている。 .metadata.labels だけでなく .spec.selector.matchLabels や .spec.template.metadata.labels にも app.kubernetes.io/name labelが設定されている。 kustomizeでCustom Resourceを適切に扱う kustomizeはデフォルトでCustom Resourceを適切に扱えない kustomizeはデフォルトでCustom Resourceを適切に加工できません。 kustomizeがCustom Resourceの スキーマ を把握していないためです。 例をみてみましょう。今回は Argo Rollouts の Rollout リソースをkustomizeで加工します。 # rollout.yaml apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp template : metadata : labels : app.kubernetes.io/name : myapp spec : containers : - name : myapp image : myapp:stable env : - name : KEY1 value : VALUE1 - name : KEY2 value : VALUE2 - name : mysidecar image : mysidecar:stable 同一 ディレクト リに kustomization.yaml を作成します。 # kustomization.yaml (for rollout) apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization commonLabels : app.kubernetes.io/name : myapp-overwrite resources : - rollout.yaml patches : - patch : |- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite kustomize build コマンドを実行すると以下の結果が出力されます。 # Output of `kustomize build` command. apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp template : metadata : labels : app.kubernetes.io/name : myapp spec : containers : - env : - name : KEY2 value : VALUE2-overwrite name : myapp 先程の Deployment の例と比較すると以下の点が異なります。 containers や env が patches の内容でまるごと上書きされている。 .spec.selector.matchLabels や .spec.template.metadata.labels の app.kubernetes.io/name labelが更新されていない。 kustomizeでCustom Resourceを適切に扱う kustomzieでCustom Resourceを扱うには、以下の2つの対応を行う必要があります。 kustomizeの OpenAPI Features を使用して、kustomizeにCustom ResourceのOpenAPI スキーマ を設定する。 kustomizeの Transformer Configurations を設定する。 Argo Rolloutsの公式ドキュメント に従って、先程のArgo Rolloutsの例を以下のとおり修正してみましょう。 Argo RolloutsのOpenAPI スキーマ を こちら からダウンロードします。 curl -OL https://github.com/argoproj/argo-rollouts/raw/master/docs/features/kustomize/rollout_cr_schema.json kustomization.yaml に openapi と configurations の設定を追記します。 # kustomization.yaml (for rollout) apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization commonLabels : app.kubernetes.io/name : myapp-overwrite resources : - rollout.yaml patches : - patch : |- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite openapi : path : rollout_cr_schema.json configurations : - https://argoproj.github.io/argo-rollouts/features/kustomize/rollout-transform.yaml kustomize build コマンドを実行すると以下の結果が出力されます。 今度は Rollout リソースが（ほぼ）期待通り加工されました。 なお env は依然として上書きされていますが、これはArgo RolloutsのOpenAPI スキーマ の問題です。 詳細は #1730 をご参照ください。 # Output of `kustomize build` command. apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite image : myapp:stable name : myapp - image : mysidecar:stable name : mysidecar kustomizeで標準リソースとCustom Resourceを適切に扱う 独自のOpenAPI スキーマ を設定すると標準リソースを適切に扱えなくなる kustomizeの OpenAPI Features は、build-inの スキーマ に 加えて 受け取ったOpenAPI スキーマ を参照するのではなく、build-inの スキーマ の かわりに 受け取ったOpenAPI スキーマ を参照します。 そのため kustomization.yaml の openapi に独自のOpenAPI スキーマ を設定すると、kustomizeが Kubernetes の標準リソースの スキーマ を参照できず、適切に加工できなくなります。 例をみてみましょう。今回はkustomizeで Deployment と Rollout の両方を加工します。 deployment.yaml と rollout.yaml は先程の例と同じものを使用します。 # kustomization.yaml (for deployment and rollout) apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization commonLabels : app.kubernetes.io/name : myapp-overwrite resources : - deployment.yaml - rollout.yaml patches : - patch : |- apiVersion : apps/v1 kind : Deployment metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite - patch : |- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite openapi : path : rollout_cr_schema.json configurations : - https://argoproj.github.io/argo-rollouts/features/kustomize/rollout-transform.yaml kustomize build コマンドを実行すると以下の結果が出力されます。 kustomization.yaml の oepnapi にArgo RolloutsのOpenAPI スキーマ を設定したため Rollout は期待通り加工できました。 しかし今度は Deployment の containers や env が patches の内容でまるごと上書きされてしまいました。 # Output of `kustomize build` command. kustomize build . apiVersion : apps/v1 kind : Deployment metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite name : myapp --- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite image : myapp:stable name : myapp - image : mysidecar:stable name : mysidecar kustomizeで標準リソースとCustom Resourceを適切に扱う この問題は 標準リソース Custom Resource の両方のOpenAPI スキーマ を統合して kustomization.yaml の oepnapi に渡すことで解決できます。 先程の例を以下のとおり修正してみましょう。 Kubernetes の標準リソースのOpenAPI スキーマ は こちら からダウンロードできます。 標準リソースとArgo RolloutsのOpenAPI スキーマ を統合する。 curl -sOL https://github.com/kubernetes/kubernetes/raw/master/api/openapi-spec/swagger.json curl -sOL https://github.com/argoproj/argo-rollouts/raw/master/docs/features/kustomize/rollout_cr_schema.json jq -s '.[0] * .[1]' swagger.json rollout_cr_schema.json > openapi.json 作成したファイルを kustomization.yaml の openapi に指定する。 # kustomization.yaml (for deployment and rollout) apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization commonLabels : app.kubernetes.io/name : myapp-overwrite resources : - deployment.yaml - rollout.yaml patches : - patch : |- apiVersion : apps/v1 kind : Deployment metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite - patch : |- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : name : myapp spec : template : spec : containers : - name : myapp env : - name : KEY2 value : VALUE2-overwrite openapi : path : openapi.json configurations : - https://argoproj.github.io/argo-rollouts/features/kustomize/rollout-transform.yaml kustomize build コマンドを実行すると以下の結果が出力されます。 今度は Deployment と Rollout の両方を期待通り加工できました。 # Output of `kustomize build` command. kustomize build . apiVersion : apps/v1 kind : Deployment metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite - name : KEY1 value : VALUE1 image : myapp:stable name : myapp - image : mysidecar:stable name : mysidecar --- apiVersion : argoproj.io/v1alpha1 kind : Rollout metadata : labels : app.kubernetes.io/name : myapp-overwrite name : myapp spec : selector : matchLabels : app.kubernetes.io/name : myapp-overwrite template : metadata : labels : app.kubernetes.io/name : myapp-overwrite spec : containers : - env : - name : KEY2 value : VALUE2-overwrite image : myapp:stable name : myapp - image : mysidecar:stable name : mysidecar 終わりに 本記事ではkustomizeでCustom Resourceを扱う方法を紹介しました。 本記事がkustomizeを使って Kubernetes を運用する方の役に立てば幸いです。 参考 kustomizeでCRDのpatchesStrategicMergeを動かしてみる - １クール続けるブログ kustomizeでCustomResourceにいい感じにStrategicMergePatchする / StrategicMergePatch to CustomResource with Kustomize - Speaker Deck Using a Custom OpenAPI schema Transformer Configurations KEP-2206: OpenAPI Features in Kustomize openapi | SIG CLI Kustomize - Argo Rollouts - Kubernetes Progressive Delivery Controller Issue with Deployment resource patching when Rollout resources openapi definition is included · Issue #4613 · kubernetes-sigs/kustomize Kustomize fail to merge .spec.template.spec.containers[].env fields · Issue #1730 · argoproj/argo-rollouts 私たちは同じチームで働いてくれる仲間を探しています。 クラウド アーキテクトの業務に興味がある方のご応募をお待ちしています。 クラウドアーキテクト 執筆： @shibata.takao 、レビュー： @sato.taichi （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、 美少女アニメ 画の呪文です。 v2.1 美少女アニメ画 の記事も書きました。よろしければご覧ください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 japanese anime of a beautiful girl pixiv, light novel, digital painting fantasy costume, fantasy background, beautiful composition, cinematic lighting extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing まとめ 仲間募集 Stable Diffusionの過去コンテンツ japanese anime of a beautiful girl 画像のタイプは、japanese anime。anime単独より、japanseseをつけた方が、出力が安定します。 サブジ ェクト（描画対象）は、a beautiful girl。 kawaii よりもbeautifulの方が出力が安定している気がします。 まずは、シンプルなPromptから始めましょう。 japanese anime of a beautiful girl 出力はこちら。 コレジャナイ感が出てますね。 pixiv, light novel, digital painting 画像のクオリティを上げるためには、作風をStable Diffusionに伝える必要があります。ゲーム名、映画名、絵師などを指定する部分です。いろいろ試してみましたが、 美少女アニメ 画には、pixiv, light novel, digital paintingが、経験上、出力が安定しています。ネットでは、Makoto ShinkaiをいれるPromptもよく見かけるのですが、僕が試した限りは、出力が安定しませんでした。 今回のPromptはこちら。 japanese anime of a beaultiful girl, pixiv, light novel, digital painting 出力はこちら。 結構それっぽくなってきましたが、ちょっとチープ感があります。 fantasy costume, fantasy background, beautiful composition, cinematic lighting 画像のクオリティをさらに上げるには、服装、背景、構図、ライティングが重要です。 fantasy costumeで、服装を指定します。 fantasy backgroundで、背景を指定します。 beautiful compositionで、構図を指定します。これを指定することで、 サブジ ェクトがいい感じで配置されます。 cinematic lightingで、ライティングを指定します。ライティングにより、 サブジ ェクトが輝いて見えます。ライティングの仕方は色々ありますが、cinematic lightingは、外れることがほとんどないので、よく使っています。 今回のPromptはこちら。 japanese anime of a beaultiful girl, fantasy costume, fantasy background, beautiful composition, cinematic lighting, pixiv, light novel, digital painting 出力はこちら。 ぐっとクオリティが上がりました。これで十分だと思われる方もいるかも知れません。 extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing ここから仕上げです。 extremely detailed, sharp focusで、 サブジ ェクトを詳細に描画し、ピントを当てます。 ray tracing, 8kで、より現実に近い映像を作り出します。 cinematic postprocessingで、映画レベルまでクオリティをあげます。 今回のPromptはこちら。 japanese anime of a beaultiful girl, fantasy costume, fantasy background, beautiful composition, cinematic lighting, pixiv, light novel, digital painting, extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing 出力はこちら。 映画の中の1シーンのようですね。 まとめ 美少女アニメ 画は、作風、服装、背景、構図、ライティングをしっかり指定することで、クオリティが上がることが理解できたと思います。 次回は、 美少女写真編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの過去コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、 美少女アニメ 画の呪文です。 v2.1 美少女アニメ画 の記事も書きました。よろしければご覧ください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 japanese anime of a beautiful girl pixiv, light novel, digital painting fantasy costume, fantasy background, beautiful composition, cinematic lighting extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing まとめ 仲間募集 Stable Diffusionの過去コンテンツ japanese anime of a beautiful girl 画像のタイプは、japanese anime。anime単独より、japanseseをつけた方が、出力が安定します。 サブジ ェクト（描画対象）は、a beautiful girl。 kawaii よりもbeautifulの方が出力が安定している気がします。 まずは、シンプルなPromptから始めましょう。 japanese anime of a beautiful girl 出力はこちら。 コレジャナイ感が出てますね。 pixiv, light novel, digital painting 画像のクオリティを上げるためには、作風をStable Diffusionに伝える必要があります。ゲーム名、映画名、絵師などを指定する部分です。いろいろ試してみましたが、 美少女アニメ 画には、pixiv, light novel, digital paintingが、経験上、出力が安定しています。ネットでは、Makoto ShinkaiをいれるPromptもよく見かけるのですが、僕が試した限りは、出力が安定しませんでした。 今回のPromptはこちら。 japanese anime of a beaultiful girl, pixiv, light novel, digital painting 出力はこちら。 結構それっぽくなってきましたが、ちょっとチープ感があります。 fantasy costume, fantasy background, beautiful composition, cinematic lighting 画像のクオリティをさらに上げるには、服装、背景、構図、ライティングが重要です。 fantasy costumeで、服装を指定します。 fantasy backgroundで、背景を指定します。 beautiful compositionで、構図を指定します。これを指定することで、 サブジ ェクトがいい感じで配置されます。 cinematic lightingで、ライティングを指定します。ライティングにより、 サブジ ェクトが輝いて見えます。ライティングの仕方は色々ありますが、cinematic lightingは、外れることがほとんどないので、よく使っています。 今回のPromptはこちら。 japanese anime of a beaultiful girl, fantasy costume, fantasy background, beautiful composition, cinematic lighting, pixiv, light novel, digital painting 出力はこちら。 ぐっとクオリティが上がりました。これで十分だと思われる方もいるかも知れません。 extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing ここから仕上げです。 extremely detailed, sharp focusで、 サブジ ェクトを詳細に描画し、ピントを当てます。 ray tracing, 8kで、より現実に近い映像を作り出します。 cinematic postprocessingで、映画レベルまでクオリティをあげます。 今回のPromptはこちら。 japanese anime of a beaultiful girl, fantasy costume, fantasy background, beautiful composition, cinematic lighting, pixiv, light novel, digital painting, extremely detailed, sharp focus, ray tracing, 8k, cinematic postprocessing 出力はこちら。 映画の中の1シーンのようですね。 まとめ 美少女アニメ 画は、作風、服装、背景、構図、ライティングをしっかり指定することで、クオリティが上がることが理解できたと思います。 次回は、 美少女写真編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの過去コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回のテーマは、画像タイプ。色々な画像を見ていくよ。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 a ball-point pen art a pencil sketch 3D photorealistic pencil drawing a crayon painting an acrylic painting a watercolor painting an oil painting an ukiyo-e painting airbrush caricature a low poly illustration japanese anime, pixiv, unreal engine, 4k まとめ 仲間募集 Stable Diffusionの過去コンテンツ a ball-point pen art ボールペンアート。 Promptはこちら。 a ball-point pen art of a cat wearing sunglasses, award-winning 出力された画像はこちら。 a pencil sketch 鉛筆によるスケッチ。 Promptはこちら。 a pencil sketch of a young boy playing hockey, award-winning 出力された画像はこちら。 3D photorealistic pencil drawing 3Dのリアルな写真的な鉛筆画。 Promptはこちら。 3D photorealistic pencil drawing of a young boy, award-winning 出力された画像はこちら。 a crayon painting クレヨン画。 Promptはこちら。 a crayon painting of a camel on the desert 出力された画像はこちら。 an acrylic painting アクリル画 。水彩画と同様に絵の具を水に溶かして使うが、水彩画のほうが劣化しやすいらしい。 Promptはこちら。 an acrylic painting of a young boy, award-winning 出力された画像はこちら。 a watercolor painting 水彩画。紙に書かれることがほとんどらしい。 Promptはこちら。 a watercolor painting of cherry blossoms, award-winning 出力された画像はこちら。 an oil painting 油彩画。 Promptはこちら。 an oil painting of sunflowers, award-winning 出力された画像はこちら。 an ukiyo-e painting 浮世絵。 Promptはこちら。 an ukiyo-e painting of Mt. Fuji in Katsushika Hokusai style, award-winning in 画家の名前 styleで指定した画家のスタイルを取り入れることができます。 出力された画像はこちら。 airbrush caricature ある人物の性格や特徴を大げさに表現した人物画。 Promptはこちら。 an airbrush caricature of a famous actor 出力された画像はこちら。 a low poly illustration 粗いポリゴンのイラスト。 Promptはこちら。 a low poly illustration of two kids, award-winning 出力された画像はこちら。 japanese anime, pixiv, unreal engine , 4k 日本のアニメ。それっぽい画像を出力するのはけっこう大変でした。 特定のアニメ、ゲーム、絵師の指定はなしで挑戦しました。 著作権 が絡んでくるリスクがあるので。 特に深い理由はありませんが、 kawaii というキーワードも意図的に使いませんでした。 Promptはこちら。 japanese anime of a beautiful girl, beautiful face, long black hair, cute eyes, long eyelashes, cute mouth, fantasy costume, overheard sunlight, fantasy background, pixiv, unreal engine, 4k 特定の絵師の名前は入れていませんが、pixivはあったほうが出力が安定しました。 overhead sunlightは、頭に太陽の光があたっている効果が出ます。 顔のパーツを色々指定していますが、指定したほうが安定します。 unreal engine , 4kがないと、チープな感じになってしまいます。 出力された画像はこちら。 まとめ 今回は、いろいろな画像タイプを紹介しました。 人物写真編 、 レンズ編 とあわせてこなしていれば、StableDiffusionの基礎はもう固まっていると思います。 次回は、 美少女アニメ画編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 a ball-point pen art a pencil sketch 3D photorealistic pencil drawing a crayon painting an acrylic painting a watercolor painting an oil painting an ukiyo-e painting airbrush caricature a low poly illustration japanese anime, pixiv, unreal engine, 4k まとめ 仲間募集 Stable Diffusionの過去コンテンツ a ball-point pen art ボールペンアート。 Promptはこちら。 a ball-point pen art of a cat wearing sunglasses, award-winning 出力された画像はこちら。 a pencil sketch 鉛筆によるスケッチ。 Promptはこちら。 a pencil sketch of a young boy playing hockey, award-winning 出力された画像はこちら。 3D photorealistic pencil drawing 3Dのリアルな写真的な鉛筆画。 Promptはこちら。 3D photorealistic pencil drawing of a young boy, award-winning 出力された画像はこちら。 a crayon painting クレヨン画。 Promptはこちら。 a crayon painting of a camel on the desert 出力された画像はこちら。 an acrylic painting アクリル画 。水彩画と同様に絵の具を水に溶かして使うが、水彩画のほうが劣化しやすいらしい。 Promptはこちら。 an acrylic painting of a young boy, award-winning 出力された画像はこちら。 a watercolor painting 水彩画。紙に書かれることがほとんどらしい。 Promptはこちら。 a watercolor painting of cherry blossoms, award-winning 出力された画像はこちら。 an oil painting 油彩画。 Promptはこちら。 an oil painting of sunflowers, award-winning 出力された画像はこちら。 an ukiyo-e painting 浮世絵。 Promptはこちら。 an ukiyo-e painting of Mt. Fuji in Katsushika Hokusai style, award-winning in 画家の名前 styleで指定した画家のスタイルを取り入れることができます。 出力された画像はこちら。 airbrush caricature ある人物の性格や特徴を大げさに表現した人物画。 Promptはこちら。 an airbrush caricature of a famous actor 出力された画像はこちら。 a low poly illustration 粗いポリゴンのイラスト。 Promptはこちら。 a low poly illustration of two kids, award-winning 出力された画像はこちら。 japanese anime, pixiv, unreal engine , 4k 日本のアニメ。それっぽい画像を出力するのはけっこう大変でした。 特定のアニメ、ゲーム、絵師の指定はなしで挑戦しました。 著作権 が絡んでくるリスクがあるので。 特に深い理由はありませんが、 kawaii というキーワードも意図的に使いませんでした。 Promptはこちら。 japanese anime of a beautiful girl, beautiful face, long black hair, cute eyes, long eyelashes, cute mouth, fantasy costume, overheard sunlight, fantasy background, pixiv, unreal engine, 4k 特定の絵師の名前は入れていませんが、pixivはあったほうが出力が安定しました。 overhead sunlightは、頭に太陽の光があたっている効果が出ます。 顔のパーツを色々指定していますが、指定したほうが安定します。 unreal engine , 4kがないと、チープな感じになってしまいます。 出力された画像はこちら。 まとめ 今回は、いろいろな画像タイプを紹介しました。 人物写真編 、 レンズ編 とあわせてこなしていれば、StableDiffusionの基礎はもう固まっていると思います。 次回は、 美少女アニメ画編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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）コーポレート本部 システム推進部の佐藤太一です。 本日は最新のGradle（2022/08現在）を使いこなしながらKotlinで Java のアプリケーションをビルドする スクリプト を書く際に、知っておくと便利なノウハウをまとめてご紹介します。 はじめに 記事の執筆環境 scoopのセットアップ Javaのセットアップ Gradleのセットアップ サンプルアプリケーションについて ルートプロジェクトの実装 ウェブアプリケーションプロジェクトの実装 ビルドスクリプトの作成 サンプルアプリケーションの実装 バージョニング その他のバージョニングプラグイン バッチプロジェクトの実装 バッチアプリケーションの実装 Fat/Uber Jarの作り方 ビルドにおける共通処理の切り出し ローカルプラグインの作り方 ローカルプラグインの実装 ローカルプラグインの使い方 ローカルプラグインにGradleプラグインを組み込む プラグインで変数や関数を定義する前に Extensionの実装 まとめ はじめに この記事では、 ソースコード をユーザーが利用できる環境にデプロイできるアプリケーションに変換する工程をビルドプロセスと呼ぶこととします。 Java で実装されたアプリケーションをビルドするためのツールとしては、古くはmakeから始まり、Antを経由して現代では Maven やGradleといったツールが広く利用されています。 この記事では、自分がコン トロール できる範囲では宣言的に記述でき、必要に応じて アドホック なコードを書いていけるGradleを使ったビルドプロセスにおけるノウハウを紹介します。 記事の執筆環境 この記事が前提とする環境について軽く説明しておきましょう。 まず、OSはWindows10 Proで、バージョンは21H2です。 Windows 環境でアプリケーションをインストールするために、パッケージマネージャーとして scoop を使っています。 そして、 Java 17を使います。 記事の主題はGradleの使い方ですので、 Windows 以外のOSでも有効なものです。 Windows 以外の環境をお使いなら次に続く環境のセットアップ手順については読み飛ばしてください。 scoopのセットアップ scoopは powershell だけで様々なツールをインストールできるパッケージマネージャーの一種です。 この記事で紹介するツールはscoopを使ってインストールしますので、もし未導入なら導入をお願いします。 まずは、 PowerShell の実行ポリシーを変えます。 scoopのインストールのためには、インターネット上にあるサーバから シェルスクリプト をダウンロードしてきて実行できるようにします。cf. about_Execution_Policies PowerShell を起動して以下のコマンドを実行します。 Set-ExecutionPolicy RemoteSigned -Scope CurrentUser 次にインストール スクリプト をダウンロードしつつ実行します。 irm get.scoop.sh | iex これでscoopのインストールは終わりです。 Java のセットアップ scoopで Java をインストールする前に バケット を追加します。 scoop bucket add java この バケット には様々なOpenJDKのビルドが入っているのですけども、ここではopenjdk17を使います。 scoop install openjdk17 openjdkを指定すると、記事執筆時点では Java 18がインストールされましたのでメジャーバージョンを明示的に指定しています。 Gradleのセットアップ 次はGradleをインストールしましょう。 scoop instlal gradle Gradleのインストールが完了したらセットアップは終了です。 サンプルアプリケーションについて この記事では ユーザーインターフェース のある ウェブアプリケーション と、 ユーザーインターフェース のないバッチアプリケーションが、単一のgit リポジトリ 内に共存しているものを想定しています。 典型的な構造ですが、様々なやり方でビルド スクリプト を記述できます。この記事では私が実施しているプロジェクトにおける構成において得られた知見をもとに説明します。 ルートプロジェクトの実装 まずは、プロジェクト全体を格納するための ディレクト リを作成しましょう。 ここからは、この記事内でシェルコマンドを実行するよう説明している部分では、必ずこのルート ディレクト リで実行してください。 作るプロジェクトは、説明のために demo-project とします。作ったdemo-project ディレクト リの中で、以下のコマンドを実行して最小限のプロジェクトを作成します。 gradle init --type basic --dsl kotlin --project-name demo-project --incubating 最小限とはいえ、Gradle Wrapperとなる シェルスクリプト やgit用の設定ファイルが生成されていますね。 その中から、不要な build.gradle.kts を削除してください。 ウェブアプリケーション プロジェクトの実装 次はSpring Bootを使った ウェブアプリケーション をビルドする環境を作ってみましょう。 ビルド スクリプト の作成 demo-project ディレクト リに web ディレクト リを作成します。次に、以下の内容で build.gradle.kts を作成します。 plugins { // 1. id("java") id("org.springframework.boot") version "2.7.2" id("io.spring.dependency-management") version "1.0.13.RELEASE" } group = "com.example" // 2. version = "0.0.1-SNAPSHOT" // 3. repositories.mavenCentral() // 4. dependencies { // 5. implementation("org.springframework.boot:spring-boot-starter") } java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) // 6. tasks.withType<JavaCompile>().configureEach { // 7. options.encoding = "UTF-8" } このビルド スクリプト について説明しておきましょう。 このプロジェクトで利用する プラグイン を列挙しています。 ウェブアプリケーション は Java を使って記述する想定なので java プラグイン を指定しています。 Spring Bootを使ったアプリケーションを作るための プラグイン が org.springframework.boot です。 io.spring.dependency-management は、Gradleでも Maven のように依存性を宣言するための プラグイン です。 ビルド成果物として出力される アーティファクト （JARファイル）のグループIDとなる部分の宣言です。基本的には会社の ドメイン 名を逆にしたものを使っておきましょう。 ビルド成果物のバージョン番号を記述しています。バージョン番号の管理についてはこの後、もう少し詳しく説明します。 依存ライブラリをダウンロードする先を宣言しています。ここでは Maven のデフォルト アーティファクト リポジトリ である Maven Central Repository を指定しています。 このプロジェクトが依存するライブラリを列挙しています。 io.spring.dependency-management によって機能性が拡張されているため、バージョン番号の指定がありません。 org.springframework.boot:spring-boot-starter がSpring Bootの本体です。 このビルド スクリプト で利用する コンパイラ やランタイムのバージョン番号を指定しています。 これは、Gradleを実行している Java ランタイムのバージョンが開発者ごとにズレていても、 コンパイル やテストに使う Java ランタイムは統一できるということです。ビルドの再現性が高まりますので必ず設定しましょう。 この機能を使うと、必要に応じてGradleがビルド済みの JDK を自動的にダウンロードしてくれます。 デフォルトでは Adoptium を使います。 このビルド スクリプト 内に定義されているタスクを型指定で検索しています。 ここでは、検索によって得られたJavaCompile型の インスタンス に文字 エンコーディング として UTF-8 を設定しています。 このビルド スクリプト がルートプロジェクトの一部であることを記述しておきましょう。 demo-project直下にある settings.gradle.kts に include("web") を追記します。 その結果以下のようになるでしょう。 /* * This file was generated by the Gradle 'init' task. * * The settings file is used to specify which projects to include in your build. * * Detailed information about configuring a multi-project build in Gradle can be found * in the user manual at https://docs.gradle.org/7.4.2/userguide/multi_project_builds.html * This project uses @Incubating APIs which are subject to change. */ rootProject.name = "demo-project" include("web") // ルートプロジェクトに含めるために追記した部分 コメントアウト されている部分に意味はないので消してしまって構いません。 ビルド スクリプト が正しく記述できているか確認しておきましょう。以下のコマンドを実行します。 gradle tasks --group=application Application tasksとして bootRun が出力されていればビルド スクリプト は上手く構成されています。 サンプルアプリケーションの実装 ビルド スクリプト を配置したら ソースコード を格納するための ディレクト リを作成しましょう。以下のコマンドを実行します。 mkdir web/src/main/java/com/example/web 以下の内容で demo-project/web/src/main/java/com/example/web ディレクト リに Main.java を作成します。 package com.example.web; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class Main { public static void main(String[] args) { SpringApplication.run(Main.class, args); } } 詳細に説明することはしませんが、これはSpring Bootアプリケーションを起動するコードです。 アプリケーションをビルドして アーティファクト を生成してみましょう。以下のコマンドを実行します。 gradle build ビルドが成功したら demo-project/web/build/libs ディレクト リの中に web-0.0.1-SNAPSHOT.jar が出力されます。 バージョニング ビルドプロセスを検討するにあたって、生成物に対してバージョン番号をどのように付与するのかは悩ましい課題です。 開発者のローカル環境でビルドしているなら、リリース作業をする前に build.gradle.kts にある version の値をエディタで書き換えてからビルドすればいいでしょう。作業が成功したら変更差分としてコミットしておけば問題ありません。 しかし、再現性のあるビルドを行うなら GitHub ActionsのようなCIサーバ上でビルドするのが望ましいでしょう。そうした時、 build.gradle.kts にある version の値を書き換えるのは少々やっかいです。 僕が好んで使っているやり方は、gitのタグをプッシュして、その名前をバージョン番号を決める際のパラメータとする方法です。 このやり方をサポートしてくれるGradleの プラグイン が me.qoomon.git-versioning です。 この プラグイン を使うとタグ名やブランチ名をパラメータにしてバージョン番号を簡単に決められます。具体例をお見せしましょう。 plugins { id("java") id("org.springframework.boot") version "2.7.2" id("io.spring.dependency-management") version "1.0.13.RELEASE" id("me.qoomon.git-versioning") version "6.3.0" // 1. } group = "com.example" version = "0.0.1-SNAPSHOT" gitVersioning.apply { // 2. refs { considerTagsOnBranches = true // 3. tag("v(?<version>\\d+[.]\\d+[.]\\d+)") { // 4. version = "\${ref.version}" // 5. } } } repositories.mavenCentral() dependencies { implementation("org.springframework.boot:spring-boot-starter") } java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } 先ほどのコードに対してバージョニングするための プラグイン を組み込んでいます。 me.qoomon.git-versioning がバージョニングするための プラグイン IDです。 バージョン番号を決める version 変数の直後に、gitVersioning.applyブロックを宣言しています。 これによって、バージョニング プラグイン が動作しなかった時は、最初に定義したバージョン番号が利用されます。 considerTagsOnBranches をtrueにすることで常にタグを考慮してバージョン番号を決定します。 ここで指定されている 正規表現 にタグがマッチしている場合にタグをバージョン番号として使います。 バージョン番号をマッチするための 正規表現 の中にある名前を使って具体的にバージョン番号として採用する範囲を決めています。 ref.version では専用の式言語を使って 正規表現 と一致した部分を取り出しています。 $ 記号の前に \ があるのは、Kotlinの文字列テンプレートとしては解釈されないようにするためです。 プラグイン が正しく構成されているか確認してみましょう。以下のコマンドを実行します。 gradle web:version この時点ではタグを打っていないので、version変数に代入されている 0.0.1-SNAPSHOT がバージョン番号として出力されます。 では、以下のコマンドを実行してタグを打った上で、同じようにバージョン番号を出力してみましょう。 git tag v0.1.2 gradle web:version バージョン番号として 0.1.2 が出力されましたね。 その他のバージョニング プラグイン タグプッシュを起点にビルドする以外の方式でバージョン番号を決めたい場合には、以下の プラグイン について検討するといいでしょう。 https://github.com/dipien/semantic-version-gradle-plugin https://github.com/nemerosa/versioning バッチプロジェクトの実装 次はバッチアプリケーションを作ってみましょう。 demo-project ディレクト リに batch ディレクト リを作成します。次に、以下の内容で build.gradle.kts を作成します。 plugins { id("application") // 1. id("me.qoomon.git-versioning") version "6.3.0" } group = "com.example" version = "0.0.1-SNAPSHOT" gitVersioning.apply { // 2. refs { considerTagsOnBranches = true tag("v(?<version>\\d+[.]\\d+[.]\\d+)") { version = "\${ref.version}" } } } repositories.mavenCentral() dependencies { implementation("com.google.guava:guava:30.1.1-jre") } application { mainClass.set("com.example.batch.Main") // 3. } java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } ウェブアプリケーション のものと似ていますが、このビルド スクリプト 固有の部分について説明しておきましょう。 application プラグイン は、 Java で CLI アプリケーションを実装するための定義を自動的に実施します。 ウェブアプリケーション と同じバージョニングポリシーを採用するので、 me.qoomon.git-versioning を導入します。 ここでは、 CLI アプリケーションとして起動する際に使うmainメソッドのあるクラスを指定しています。 demo-project直下にある settings.gradle.kts に include("batch") を追記します。 その結果以下のようになるでしょう。 rootProject.name = "demo-project" include("web") include("batch") // ルートプロジェクトに含めるために追記した部分 バッチアプリケーションの実装 ビルド スクリプト を配置したら ソースコード を格納するための ディレクト リを作成しましょう。以下のコマンドを実行します。 mkdir batch/src/main/java/com/example/batch 以下の内容で demo-project/batch/src/main/java/com/example/batch ディレクト リに Main.java を作成します。 package com.example.batch; import com.google.common.base.Strings; public class Main { public static void main(String[] args) { System.out.println(Strings.repeat("Hello, ", 2) + "World."); } } 詳細に説明することはしませんが、 CLI アプリケーションとして起動するコードです。 この後で説明するFat Jarの動作を確認できるようにGuavaのメソッドを使っています。 Fat/ Uber Jarの作り方 Java の実行バイナリの形式として、依存ライブラリを全て一つのJARファイルに含めてしまう形式の事を、Fat Jar や Uber Jarと呼びます。 ビルド生成物を単一のファイルにすると、その後の取り回しが単 純化 するのでデプロイプロセスの安定性が高まります。 Gradleでは Gradle Shadow プラグイン を使うと簡単にFat/ Uber Jarがつくれます。 既に書いたバッチアプリケーションのビルド スクリプト に、この プラグイン を導入してみましょう。 plugins { id("application") id("me.qoomon.git-versioning") version "6.3.0" id("com.github.johnrengelman.shadow") version "7.1.2" // プラグイン導入 } group = "com.example" version = "0.0.1-SNAPSHOT" gitVersioning.apply { refs { considerTagsOnBranches = true tag("v(?<version>\\d+[.]\\d+[.]\\d+)") { version = "\${ref.version}" } } } repositories.mavenCentral() dependencies { implementation("com.google.guava:guava:30.1.1-jre") } application { mainClass.set("com.example.batch.Main") } java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } このビルド スクリプト では、既にapplication プラグイン が導入されているので、shadow プラグイン はそれに相乗りする形で動作します。つまり、 プラグイン の導入を宣言するだけでFat/ Uber Jarが生成されるようになるのです。 では、以下のコマンドでビルドしてみましょう。 gradle batch:build ビルドが正常終了したら、以下のコマンドを実行して生成された成果物を確認してみましょう。 ls batch/build/libs 大きく膨らんだ batch-0.0.1-SNAPSHOT-all.jar がFat/ Uber Jarです。今回は、この中にGuavaおよびその依存ライブラリが全て含まれています。 ビルドにおける共通処理の切り出し ここまで、 ウェブアプリケーション とバッチアプリケーションのビルド スクリプト を作ってきたわけですが、かなりの重複があることにお気づきでしょうか？ オレンジ色の枠で囲った部分が二つのビルド スクリプト における重複部分です。 これらはビルド対象プロジェクトが増えるたびに重複していくでしょう。それは、望ましくありません。 ここからは、Gradleのローカル プラグイン を使ってビルド スクリプト の共通部分を切り出す方法について説明します。 共通部分を プラグイン 化することによって、それぞれのビルド スクリプト はより小さくて分かり易いものになります。また、プロジェクトにおけるバージョニングなどのポリシーを一か所に書くことで、ポリシーの変更があった際に抜け漏れなく対応できます。 ローカル プラグイン の作り方 それでは、ローカル プラグイン の作り方を説明しましょう。 demo-project ディレクト リに buildSrc ディレクト リを作成します。次に、以下の内容で build.gradle.kts を作成します。 plugins { `kotlin-dsl` // 1. } repositories.gradlePluginPortal() // 2. Gradleはルートプロジェクト直下にある buildSrc ディレクト リをローカル プラグイン が実装されているプロジェクトであるとみなします。少し奇妙だと感じるかもしれませんが、慣れてしまいましょう。 このプロジェクトは kotlin-dsl を使って プラグイン を記述します。 このプロジェクトは プラグイン プロジェクトになるので、依存ライブラリを Gradle - Plugins からダウンロードします。 ローカル プラグイン の実装 ビルド スクリプト を配置したら ソースコード を格納するための ディレクト リを作成しましょう。以下のコマンドを実行します。 mkdir buildSrc/src/main/kotlin 以下の内容で demo-project/buildSrc/src/main/kotlin ディレクト リに com.example.commons.gradle.kts を作成します。 plugins { id("java") } group = "com.example" version = "0.0.1-SNAPSHOT" repositories.mavenCentral() java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } ここでは、Gradleの標準機能だけを使って共 通化 しています。 これで、 com.example.commons を プラグイン IDとして参照できるローカル プラグイン の実装は終わりです。非常に簡単ですね。 ローカル プラグイン の使い方 では、ローカル プラグイン を使って ウェブアプリケーション のビルド スクリプト を簡略化してみましょう。 まずは、 ウェブアプリケーション のビルド スクリプト にローカル プラグイン を適用します。 plugins { id("com.example.commons") // ローカルプラグインの導入 id("org.springframework.boot") version "2.7.2" id("io.spring.dependency-management") version "1.0.13.RELEASE" id("me.qoomon.git-versioning") version "6.3.0" } gitVersioning.apply { refs { considerTagsOnBranches = true tag("v(?<version>\\d+[.]\\d+[.]\\d+)") { version = "\${ref.version}" } } } dependencies { implementation("org.springframework.boot:spring-boot-starter") } 差分を確認してみましょう。 かなり小さくなりましたね。同じことをバッチアプリケーションのビルド スクリプト でもやっておきましょう。 ローカル プラグイン にGradle プラグイン を組み込む 次は、バージョニング プラグイン の適用もローカル プラグイン の中でやってみましょう。 まずは、誤った例をお見せします。 この状態でローカル プラグイン がビルドされると以下のようなエラーが出力されます。 Invalid plugin request [id: 'me.qoomon.git-versioning', version: '6.3.0']. Plugin requests from precompiled scripts must not include a version number. Please remove the version from the offending request and make sure the module containing the requested plugin 'me.qoomon.git-versioning' is an implementation dependency of project ':buildSrc'. これは、ローカル プラグイン の実装で プラグイン を指定する場合には、冒頭のpluginsブロックの中でバージョン番号を指定できないというエラーです。このローカル プラグイン からはバージョン番号を削除した上で、buildSrcプロジェクトにおける依存性として プラグイン を宣言するように指示されています。 具体的にどうするのかというと、buildSrc ディレクト リ内にあるbuild.gradle.ktsを以下のように修正します。 plugins { `kotlin-dsl` } repositories.gradlePluginPortal() dependencies { implementation("me.qoomon:gradle-git-versioning-plugin:6.3.0") // 依存性を追加 } ここで追加する依存性は アーティファクト ID（ me.qoomon:gradle-git-versioning-plugin:6.3.0 ）を指定します。 プラグイン ID（ me.qoomon.git-versioning ）ではありませんのでご注意ください。 次は、ローカル プラグイン 内にバージョニング プラグイン を適用します。 plugins { id("java") id("me.qoomon.git-versioning") // 1. } group = "com.example" version = "0.0.1-SNAPSHOT" gitVersioning.apply { // 2. refs { considerTagsOnBranches = true tag("v(?<version>\\d+[.]\\d+[.]\\d+)") { version = "\${ref.version}" } } } repositories.mavenCentral() java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } 注意深く見てほしい2か所について説明します。 ここでは、バージョン番号を明記しない形で プラグイン の導入を宣言します。 プラグイン が導入されているので、それを使ったバージョン番号の採番処理を記述しています。内容は以前に説明したものと同じですね。 ウェブアプリケーション のビルド スクリプト からバージョン番号の採番を消せました。これで、さらに小さくて読みやすくなりましたね。 plugins { id("com.example.commons") id("org.springframework.boot") version "2.7.2" id("io.spring.dependency-management") version "1.0.13.RELEASE" } dependencies { implementation("org.springframework.boot:spring-boot-starter") } プラグイン で変数や関数を定義する前に 最後は複数のプロジェクトで使いまわせる関数や変数をローカル プラグイン で定義してみましょう。 定義の前にGradleにおける プラグイン の動作と変数スコープについて少し説明させてください。 まず、Gradleのビルド スクリプト における一番外側のスコープ、つまり暗黙の インスタンス は Project です。 plugins や dependencies といったコードブロックは、 Project クラスの インスタンス に定義されたメソッドをレシーバを指定せずに呼び出しているのです。 そして、Gradleの プラグイン はProject インスタンス のメソッドを呼び出したり、動的にメンバを追加することで機能を実現しています。 つまり、複数のプロジェクトで使いまわせる関数や変数をローカル プラグイン で定義するというのは、動的なメンバをProject インスタンス に追加するという事になります。もちろん、 dependencies や tasks といったスコープに変数や関数を追加することも出来ます。 そして、Gradle プラグイン では動的にメンバを編集する仕組みをExtensionと呼んでいます。 Extensionの実装 それでは、Extensionを使ってプロジェクト固有の変数を追加してみましょう。 以下の内容で demo-project/buildSrc/src/main/kotlin ディレクト リに Extension.kt を作成します。 import org.gradle.api.Project val Project.env: String get() = if (System.getenv("ENV") != null) { System.getenv("ENV").toLowerCase() } else "dev" Extensionというファイル名はGradle プラグイン における 命名規則 によるものです。 プラグイン 名が自明な場合には、 プラグイン 名の サフィックス として Extension を指定するのが一般的なようです。 今回は明示的な プラグイン 名がないので、単に Extension としています。 ここでは、プロジェクトスコープに env という変数を追加してみました。 これは 環境変数 の ENV を読み取った上で中身があれば、その値を返します。それが無ければ dev を返すという処理になっています。 これをバッチアプリケーションのビルド スクリプト で使ってみましょう。 plugins { id("com.example.commons") id("application") id("com.github.johnrengelman.shadow") version "7.1.2" } dependencies { implementation("com.google.guava:guava:30.1.1-jre") } application { mainClass.set("com.example.batch.Main") } tasks { shadowJar { archiveClassifier.set("all-" + env) // ファイル名のサフィックスとしてenvの値を使う。 } } ここでは、shadow プラグイン によって出力される アーティファクト 名の一部として、envの値を使うように変更しました。 これによって、ファイル名の一部として 環境変数 であるENVの値を部分的に使うようになります。 この状態でビルドすると batch/build/libs/batch-0.0.1-SNAPSHOT-all-dev.jar というJARファイルが出力されるのを確認できます。 環境変数 ENVの中身を prod に変えてビルドしてください。ビルド結果として batch/build/libs/batch-0.0.1-SNAPSHOT-all-prod.jar というJARファイルが出力されるのを確認できます。 まとめ このエントリでは、Kotlinを使ってGradleのビルド スクリプト を書く際に知っていると便利なTipsを紹介してきました。ここで紹介したGradleの標準機能や、いくつかの プラグイン は私がビルド スクリプト を書く際には必ず利用しているものです。 また、ローカル プラグイン に プラグイン を追加する際のエラーについては 検索エンジン にインデックスされるよう少し冗長に書いています。冗長に書いた理由は、同じエラーに遭遇した誰かに届いてほしいからです。私自身は、このエラーを上手く解決できなくてかなり苦しみましたので、そういう方が一人でも減ってほしいという気持ちがあります。 この長文を最後まで読んでいただき本当にありがとうございます。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募をお待ちしています。 社内SE(DX推進エンジニア) 執筆： @sato.taichi 、レビュー： @higa （ Shodo で執筆されました ）

みなさんこんにちは、 電通国際情報サービス （ISID）コーポレート本部 システム推進部の佐藤太一です。 本日は最新のGradle（2022/08現在）を使いこなしながらKotlinで Java のアプリケーションをビルドする スクリプト を書く際に、知っておくと便利なノウハウをまとめてご紹介します。 はじめに 記事の執筆環境 scoopのセットアップ Javaのセットアップ Gradleのセットアップ サンプルアプリケーションについて ルートプロジェクトの実装 ウェブアプリケーションプロジェクトの実装 ビルドスクリプトの作成 サンプルアプリケーションの実装 バージョニング その他のバージョニングプラグイン バッチプロジェクトの実装 バッチアプリケーションの実装 Fat/Uber Jarの作り方 ビルドにおける共通処理の切り出し ローカルプラグインの作り方 ローカルプラグインの実装 ローカルプラグインの使い方 ローカルプラグインにGradleプラグインを組み込む プラグインで変数や関数を定義する前に Extensionの実装 まとめ はじめに この記事では、 ソースコード をユーザーが利用できる環境にデプロイできるアプリケーションに変換する工程をビルドプロセスと呼ぶこととします。 Java で実装されたアプリケーションをビルドするためのツールとしては、古くはmakeから始まり、Antを経由して現代では Maven やGradleといったツールが広く利用されています。 この記事では、自分がコン トロール できる範囲では宣言的に記述でき、必要に応じて アドホック なコードを書いていけるGradleを使ったビルドプロセスにおけるノウハウを紹介します。 記事の執筆環境 この記事が前提とする環境について軽く説明しておきましょう。 まず、OSはWindows10 Proで、バージョンは21H2です。 Windows 環境でアプリケーションをインストールするために、パッケージマネージャーとして scoop を使っています。 そして、 Java 17を使います。 記事の主題はGradleの使い方ですので、 Windows 以外のOSでも有効なものです。 Windows 以外の環境をお使いなら次に続く環境のセットアップ手順については読み飛ばしてください。 scoopのセットアップ scoopは powershell だけで様々なツールをインストールできるパッケージマネージャーの一種です。 この記事で紹介するツールはscoopを使ってインストールしますので、もし未導入なら導入をお願いします。 まずは、 PowerShell の実行ポリシーを変えます。 scoopのインストールのためには、インターネット上にあるサーバから シェルスクリプト をダウンロードしてきて実行できるようにします。cf. about_Execution_Policies PowerShell を起動して以下のコマンドを実行します。 Set-ExecutionPolicy RemoteSigned -Scope CurrentUser 次にインストール スクリプト をダウンロードしつつ実行します。 irm get.scoop.sh | iex これでscoopのインストールは終わりです。 Java のセットアップ scoopで Java をインストールする前に バケット を追加します。 scoop bucket add java この バケット には様々なOpenJDKのビルドが入っているのですけども、ここではopenjdk17を使います。 scoop install openjdk17 openjdkを指定すると、記事執筆時点では Java 18がインストールされましたのでメジャーバージョンを明示的に指定しています。 Gradleのセットアップ 次はGradleをインストールしましょう。 scoop instlal gradle Gradleのインストールが完了したらセットアップは終了です。 サンプルアプリケーションについて この記事では ユーザーインターフェース のある ウェブアプリケーション と、 ユーザーインターフェース のないバッチアプリケーションが、単一のgit リポジトリ 内に共存しているものを想定しています。 典型的な構造ですが、様々なやり方でビルド スクリプト を記述できます。この記事では私が実施しているプロジェクトにおける構成において得られた知見をもとに説明します。 ルートプロジェクトの実装 まずは、プロジェクト全体を格納するための ディレクト リを作成しましょう。 ここからは、この記事内でシェルコマンドを実行するよう説明している部分では、必ずこのルート ディレクト リで実行してください。 作るプロジェクトは、説明のために demo-project とします。作ったdemo-project ディレクト リの中で、以下のコマンドを実行して最小限のプロジェクトを作成します。 gradle init --type basic --dsl kotlin --project-name demo-project --incubating 最小限とはいえ、Gradle Wrapperとなる シェルスクリプト やgit用の設定ファイルが生成されていますね。 その中から、不要な build.gradle.kts を削除してください。 ウェブアプリケーション プロジェクトの実装 次はSpring Bootを使った ウェブアプリケーション をビルドする環境を作ってみましょう。 ビルド スクリプト の作成 demo-project ディレクト リに web ディレクト リを作成します。次に、以下の内容で build.gradle.kts を作成します。 plugins { // 1. id("java") id("org.springframework.boot") version "2.7.2" id("io.spring.dependency-management") version "1.0.13.RELEASE" } group = "com.example" // 2. version = "0.0.1-SNAPSHOT" // 3. repositories.mavenCentral() // 4. dependencies { // 5. implementation("org.springframework.boot:spring-boot-starter") } java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) // 6. tasks.withType<JavaCompile>().configureEach { // 7. options.encoding = "UTF-8" } このビルド スクリプト について説明しておきましょう。 このプロジェクトで利用する プラグイン を列挙しています。 ウェブアプリケーション は Java を使って記述する想定なので java プラグイン を指定しています。 Spring Bootを使ったアプリケーションを作るための プラグイン が org.springframework.boot です。 io.spring.dependency-management は、Gradleでも Maven のように依存性を宣言するための プラグイン です。 ビルド成果物として出力される アーティファクト （JARファイル）のグループIDとなる部分の宣言です。基本的には会社の ドメイン 名を逆にしたものを使っておきましょう。 ビルド成果物のバージョン番号を記述しています。バージョン番号の管理についてはこの後、もう少し詳しく説明します。 依存ライブラリをダウンロードする先を宣言しています。ここでは Maven のデフォルト アーティファクト リポジトリ である Maven Central Repository を指定しています。 このプロジェクトが依存するライブラリを列挙しています。 io.spring.dependency-management によって機能性が拡張されているため、バージョン番号の指定がありません。 org.springframework.boot:spring-boot-starter がSpring Bootの本体です。 このビルド スクリプト で利用する コンパイラ やランタイムのバージョン番号を指定しています。 これは、Gradleを実行している Java ランタイムのバージョンが開発者ごとにズレていても、 コンパイル やテストに使う Java ランタイムは統一できるということです。ビルドの再現性が高まりますので必ず設定しましょう。 この機能を使うと、必要に応じてGradleがビルド済みの JDK を自動的にダウンロードしてくれます。 デフォルトでは Adoptium を使います。 このビルド スクリプト 内に定義されているタスクを型指定で検索しています。 ここでは、検索によって得られたJavaCompile型の インスタンス に文字 エンコーディング として UTF-8 を設定しています。 このビルド スクリプト がルートプロジェクトの一部であることを記述しておきましょう。 demo-project直下にある settings.gradle.kts に include("web") を追記します。 その結果以下のようになるでしょう。 /* * This file was generated by the Gradle 'init' task. * * The settings file is used to specify which projects to include in your build. * * Detailed information about configuring a multi-project build in Gradle can be found * in the user manual at https://docs.gradle.org/7.4.2/userguide/multi_project_builds.html * This project uses @Incubating APIs which are subject to change. */ rootProject.name = "demo-project" include("web") // ルートプロジェクトに含めるために追記した部分 コメントアウト されている部分に意味はないので消してしまって構いません。 ビルド スクリプト が正しく記述できているか確認しておきましょう。以下のコマンドを実行します。 gradle tasks --group=application Application tasksとして bootRun が出力されていればビルド スクリプト は上手く構成されています。 サンプルアプリケーションの実装 ビルド スクリプト を配置したら ソースコード を格納するための ディレクト リを作成しましょう。以下のコマンドを実行します。 mkdir web/src/main/java/com/example/web 以下の内容で demo-project/web/src/main/java/com/example/web ディレクト リに Main.java を作成します。 package com.example.web; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class Main { public static void main(String[] args) { SpringApplication.run(Main.class, args); } } 詳細に説明することはしませんが、これはSpring Bootアプリケーションを起動するコードです。 アプリケーションをビルドして アーティファクト を生成してみましょう。以下のコマンドを実行します。 gradle build ビルドが成功したら demo-project/web/build/libs ディレクト リの中に web-0.0.1-SNAPSHOT.jar が出力されます。 バージョニング ビルドプロセスを検討するにあたって、生成物に対してバージョン番号をどのように付与するのかは悩ましい課題です。 開発者のローカル環境でビルドしているなら、リリース作業をする前に build.gradle.kts にある version の値をエディタで書き換えてからビルドすればいいでしょう。作業が成功したら変更差分としてコミットしておけば問題ありません。 しかし、再現性のあるビルドを行うなら GitHub ActionsのようなCIサーバ上でビルドするのが望ましいでしょう。そうした時、 build.gradle.kts にある version の値を書き換えるのは少々やっかいです。 僕が好んで使っているやり方は、gitのタグをプッシュして、その名前をバージョン番号を決める際のパラメータとする方法です。 このやり方をサポートしてくれるGradleの プラグイン が me.qoomon.git-versioning です。 この プラグイン を使うとタグ名やブランチ名をパラメータにしてバージョン番号を簡単に決められます。具体例をお見せしましょう。 plugins { id("java") id("org.springframework.boot") version "2.7.2" id("io.spring.dependency-management") version "1.0.13.RELEASE" id("me.qoomon.git-versioning") version "6.3.0" // 1. } group = "com.example" version = "0.0.1-SNAPSHOT" gitVersioning.apply { // 2. refs { considerTagsOnBranches = true // 3. tag("v(?<version>\\d+[.]\\d+[.]\\d+)") { // 4. version = "\${ref.version}" // 5. } } } repositories.mavenCentral() dependencies { implementation("org.springframework.boot:spring-boot-starter") } java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } 先ほどのコードに対してバージョニングするための プラグイン を組み込んでいます。 me.qoomon.git-versioning がバージョニングするための プラグイン IDです。 バージョン番号を決める version 変数の直後に、gitVersioning.applyブロックを宣言しています。 これによって、バージョニング プラグイン が動作しなかった時は、最初に定義したバージョン番号が利用されます。 considerTagsOnBranches をtrueにすることで常にタグを考慮してバージョン番号を決定します。 ここで指定されている 正規表現 にタグがマッチしている場合にタグをバージョン番号として使います。 バージョン番号をマッチするための 正規表現 の中にある名前を使って具体的にバージョン番号として採用する範囲を決めています。 ref.version では専用の式言語を使って 正規表現 と一致した部分を取り出しています。 $ 記号の前に \ があるのは、Kotlinの文字列テンプレートとしては解釈されないようにするためです。 プラグイン が正しく構成されているか確認してみましょう。以下のコマンドを実行します。 gradle web:version この時点ではタグを打っていないので、version変数に代入されている 0.0.1-SNAPSHOT がバージョン番号として出力されます。 では、以下のコマンドを実行してタグを打った上で、同じようにバージョン番号を出力してみましょう。 git tag v0.1.2 gradle web:version バージョン番号として 0.1.2 が出力されましたね。 その他のバージョニング プラグイン タグプッシュを起点にビルドする以外の方式でバージョン番号を決めたい場合には、以下の プラグイン について検討するといいでしょう。 https://github.com/dipien/semantic-version-gradle-plugin https://github.com/nemerosa/versioning バッチプロジェクトの実装 次はバッチアプリケーションを作ってみましょう。 demo-project ディレクト リに batch ディレクト リを作成します。次に、以下の内容で build.gradle.kts を作成します。 plugins { id("application") // 1. id("me.qoomon.git-versioning") version "6.3.0" } group = "com.example" version = "0.0.1-SNAPSHOT" gitVersioning.apply { // 2. refs { considerTagsOnBranches = true tag("v(?<version>\\d+[.]\\d+[.]\\d+)") { version = "\${ref.version}" } } } repositories.mavenCentral() dependencies { implementation("com.google.guava:guava:30.1.1-jre") } application { mainClass.set("com.example.batch.Main") // 3. } java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } ウェブアプリケーション のものと似ていますが、このビルド スクリプト 固有の部分について説明しておきましょう。 application プラグイン は、 Java で CLI アプリケーションを実装するための定義を自動的に実施します。 ウェブアプリケーション と同じバージョニングポリシーを採用するので、 me.qoomon.git-versioning を導入します。 ここでは、 CLI アプリケーションとして起動する際に使うmainメソッドのあるクラスを指定しています。 demo-project直下にある settings.gradle.kts に include("batch") を追記します。 その結果以下のようになるでしょう。 rootProject.name = "demo-project" include("web") include("batch") // ルートプロジェクトに含めるために追記した部分 バッチアプリケーションの実装 ビルド スクリプト を配置したら ソースコード を格納するための ディレクト リを作成しましょう。以下のコマンドを実行します。 mkdir batch/src/main/java/com/example/batch 以下の内容で demo-project/batch/src/main/java/com/example/batch ディレクト リに Main.java を作成します。 package com.example.batch; import com.google.common.base.Strings; public class Main { public static void main(String[] args) { System.out.println(Strings.repeat("Hello, ", 2) + "World."); } } 詳細に説明することはしませんが、 CLI アプリケーションとして起動するコードです。 この後で説明するFat Jarの動作を確認できるようにGuavaのメソッドを使っています。 Fat/ Uber Jarの作り方 Java の実行バイナリの形式として、依存ライブラリを全て一つのJARファイルに含めてしまう形式の事を、Fat Jar や Uber Jarと呼びます。 ビルド生成物を単一のファイルにすると、その後の取り回しが単 純化 するのでデプロイプロセスの安定性が高まります。 Gradleでは Gradle Shadow プラグイン を使うと簡単にFat/ Uber Jarがつくれます。 既に書いたバッチアプリケーションのビルド スクリプト に、この プラグイン を導入してみましょう。 plugins { id("application") id("me.qoomon.git-versioning") version "6.3.0" id("com.github.johnrengelman.shadow") version "7.1.2" // プラグイン導入 } group = "com.example" version = "0.0.1-SNAPSHOT" gitVersioning.apply { refs { considerTagsOnBranches = true tag("v(?<version>\\d+[.]\\d+[.]\\d+)") { version = "\${ref.version}" } } } repositories.mavenCentral() dependencies { implementation("com.google.guava:guava:30.1.1-jre") } application { mainClass.set("com.example.batch.Main") } java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } このビルド スクリプト では、既にapplication プラグイン が導入されているので、shadow プラグイン はそれに相乗りする形で動作します。つまり、 プラグイン の導入を宣言するだけでFat/ Uber Jarが生成されるようになるのです。 では、以下のコマンドでビルドしてみましょう。 gradle batch:build ビルドが正常終了したら、以下のコマンドを実行して生成された成果物を確認してみましょう。 ls batch/build/libs 大きく膨らんだ batch-0.0.1-SNAPSHOT-all.jar がFat/ Uber Jarです。今回は、この中にGuavaおよびその依存ライブラリが全て含まれています。 ビルドにおける共通処理の切り出し ここまで、 ウェブアプリケーション とバッチアプリケーションのビルド スクリプト を作ってきたわけですが、かなりの重複があることにお気づきでしょうか？ オレンジ色の枠で囲った部分が二つのビルド スクリプト における重複部分です。 これらはビルド対象プロジェクトが増えるたびに重複していくでしょう。それは、望ましくありません。 ここからは、Gradleのローカル プラグイン を使ってビルド スクリプト の共通部分を切り出す方法について説明します。 共通部分を プラグイン 化することによって、それぞれのビルド スクリプト はより小さくて分かり易いものになります。また、プロジェクトにおけるバージョニングなどのポリシーを一か所に書くことで、ポリシーの変更があった際に抜け漏れなく対応できます。 ローカル プラグイン の作り方 それでは、ローカル プラグイン の作り方を説明しましょう。 demo-project ディレクト リに buildSrc ディレクト リを作成します。次に、以下の内容で build.gradle.kts を作成します。 plugins { `kotlin-dsl` // 1. } repositories.gradlePluginPortal() // 2. Gradleはルートプロジェクト直下にある buildSrc ディレクト リをローカル プラグイン が実装されているプロジェクトであるとみなします。少し奇妙だと感じるかもしれませんが、慣れてしまいましょう。 このプロジェクトは kotlin-dsl を使って プラグイン を記述します。 このプロジェクトは プラグイン プロジェクトになるので、依存ライブラリを Gradle - Plugins からダウンロードします。 ローカル プラグイン の実装 ビルド スクリプト を配置したら ソースコード を格納するための ディレクト リを作成しましょう。以下のコマンドを実行します。 mkdir buildSrc/src/main/kotlin 以下の内容で demo-project/buildSrc/src/main/kotlin ディレクト リに com.example.commons.gradle.kts を作成します。 plugins { id("java") } group = "com.example" version = "0.0.1-SNAPSHOT" repositories.mavenCentral() java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } ここでは、Gradleの標準機能だけを使って共 通化 しています。 これで、 com.example.commons を プラグイン IDとして参照できるローカル プラグイン の実装は終わりです。非常に簡単ですね。 ローカル プラグイン の使い方 では、ローカル プラグイン を使って ウェブアプリケーション のビルド スクリプト を簡略化してみましょう。 まずは、 ウェブアプリケーション のビルド スクリプト にローカル プラグイン を適用します。 plugins { id("com.example.commons") // ローカルプラグインの導入 id("org.springframework.boot") version "2.7.2" id("io.spring.dependency-management") version "1.0.13.RELEASE" id("me.qoomon.git-versioning") version "6.3.0" } gitVersioning.apply { refs { considerTagsOnBranches = true tag("v(?<version>\\d+[.]\\d+[.]\\d+)") { version = "\${ref.version}" } } } dependencies { implementation("org.springframework.boot:spring-boot-starter") } 差分を確認してみましょう。 かなり小さくなりましたね。同じことをバッチアプリケーションのビルド スクリプト でもやっておきましょう。 ローカル プラグイン にGradle プラグイン を組み込む 次は、バージョニング プラグイン の適用もローカル プラグイン の中でやってみましょう。 まずは、誤った例をお見せします。 この状態でローカル プラグイン がビルドされると以下のようなエラーが出力されます。 Invalid plugin request [id: 'me.qoomon.git-versioning', version: '6.3.0']. Plugin requests from precompiled scripts must not include a version number. Please remove the version from the offending request and make sure the module containing the requested plugin 'me.qoomon.git-versioning' is an implementation dependency of project ':buildSrc'. これは、ローカル プラグイン の実装で プラグイン を指定する場合には、冒頭のpluginsブロックの中でバージョン番号を指定できないというエラーです。このローカル プラグイン からはバージョン番号を削除した上で、buildSrcプロジェクトにおける依存性として プラグイン を宣言するように指示されています。 具体的にどうするのかというと、buildSrc ディレクト リ内にあるbuild.gradle.ktsを以下のように修正します。 plugins { `kotlin-dsl` } repositories.gradlePluginPortal() dependencies { implementation("me.qoomon:gradle-git-versioning-plugin:6.3.0") // 依存性を追加 } ここで追加する依存性は アーティファクト ID（ me.qoomon:gradle-git-versioning-plugin:6.3.0 ）を指定します。 プラグイン ID（ me.qoomon.git-versioning ）ではありませんのでご注意ください。 次は、ローカル プラグイン 内にバージョニング プラグイン を適用します。 plugins { id("java") id("me.qoomon.git-versioning") // 1. } group = "com.example" version = "0.0.1-SNAPSHOT" gitVersioning.apply { // 2. refs { considerTagsOnBranches = true tag("v(?<version>\\d+[.]\\d+[.]\\d+)") { version = "\${ref.version}" } } } repositories.mavenCentral() java.toolchain.languageVersion.set(JavaLanguageVersion.of(17)) tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } 注意深く見てほしい2か所について説明します。 ここでは、バージョン番号を明記しない形で プラグイン の導入を宣言します。 プラグイン が導入されているので、それを使ったバージョン番号の採番処理を記述しています。内容は以前に説明したものと同じですね。 ウェブアプリケーション のビルド スクリプト からバージョン番号の採番を消せました。これで、さらに小さくて読みやすくなりましたね。 plugins { id("com.example.commons") id("org.springframework.boot") version "2.7.2" id("io.spring.dependency-management") version "1.0.13.RELEASE" } dependencies { implementation("org.springframework.boot:spring-boot-starter") } プラグイン で変数や関数を定義する前に 最後は複数のプロジェクトで使いまわせる関数や変数をローカル プラグイン で定義してみましょう。 定義の前にGradleにおける プラグイン の動作と変数スコープについて少し説明させてください。 まず、Gradleのビルド スクリプト における一番外側のスコープ、つまり暗黙の インスタンス は Project です。 plugins や dependencies といったコードブロックは、 Project クラスの インスタンス に定義されたメソッドをレシーバを指定せずに呼び出しているのです。 そして、Gradleの プラグイン はProject インスタンス のメソッドを呼び出したり、動的にメンバを追加することで機能を実現しています。 つまり、複数のプロジェクトで使いまわせる関数や変数をローカル プラグイン で定義するというのは、動的なメンバをProject インスタンス に追加するという事になります。もちろん、 dependencies や tasks といったスコープに変数や関数を追加することも出来ます。 そして、Gradle プラグイン では動的にメンバを編集する仕組みをExtensionと呼んでいます。 Extensionの実装 それでは、Extensionを使ってプロジェクト固有の変数を追加してみましょう。 以下の内容で demo-project/buildSrc/src/main/kotlin ディレクト リに Extension.kt を作成します。 import org.gradle.api.Project val Project.env: String get() = if (System.getenv("ENV") != null) { System.getenv("ENV").toLowerCase() } else "dev" Extensionというファイル名はGradle プラグイン における 命名規則 によるものです。 プラグイン 名が自明な場合には、 プラグイン 名の サフィックス として Extension を指定するのが一般的なようです。 今回は明示的な プラグイン 名がないので、単に Extension としています。 ここでは、プロジェクトスコープに env という変数を追加してみました。 これは 環境変数 の ENV を読み取った上で中身があれば、その値を返します。それが無ければ dev を返すという処理になっています。 これをバッチアプリケーションのビルド スクリプト で使ってみましょう。 plugins { id("com.example.commons") id("application") id("com.github.johnrengelman.shadow") version "7.1.2" } dependencies { implementation("com.google.guava:guava:30.1.1-jre") } application { mainClass.set("com.example.batch.Main") } tasks { shadowJar { archiveClassifier.set("all-" + env) // ファイル名のサフィックスとしてenvの値を使う。 } } ここでは、shadow プラグイン によって出力される アーティファクト 名の一部として、envの値を使うように変更しました。 これによって、ファイル名の一部として 環境変数 であるENVの値を部分的に使うようになります。 この状態でビルドすると batch/build/libs/batch-0.0.1-SNAPSHOT-all-dev.jar というJARファイルが出力されるのを確認できます。 環境変数 ENVの中身を prod に変えてビルドしてください。ビルド結果として batch/build/libs/batch-0.0.1-SNAPSHOT-all-prod.jar というJARファイルが出力されるのを確認できます。 まとめ このエントリでは、Kotlinを使ってGradleのビルド スクリプト を書く際に知っていると便利なTipsを紹介してきました。ここで紹介したGradleの標準機能や、いくつかの プラグイン は私がビルド スクリプト を書く際には必ず利用しているものです。 また、ローカル プラグイン に プラグイン を追加する際のエラーについては 検索エンジン にインデックスされるよう少し冗長に書いています。冗長に書いた理由は、同じエラーに遭遇した誰かに届いてほしいからです。私自身は、このエラーを上手く解決できなくてかなり苦しみましたので、そういう方が一人でも減ってほしいという気持ちがあります。 この長文を最後まで読んでいただき本当にありがとうございます。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募をお待ちしています。 社内SE(DX推進エンジニア) 執筆： @sato.taichi 、レビュー： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回のテーマはレンズです。 Stable DiffusionはAIカメラなので、どのようなレンズを使うかどうかはとても重要です。カメラの知識が必要ですが、基礎から丁寧に説明するので大丈夫です。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 レンズの属性 焦点距離 F値 SIGMA SIGMA 85 mm F/1.4 SIGMA 24 mm F/1.4 SIGMA 300 mm F/2.8 SIGMA 105 mm F/5.6 シャッタースピード 1/1000 sec shutter ocean, 5 sec shutter cars with lights, blue hour, 1/10 sec speed panning shot, 1/20 sec shutter まとめ 仲間募集 Stable Diffusionの過去コンテンツ レンズの属性 レンズは、 名前 焦点距離 F値 のような属性を持っています。例えば、 SIGMA 85 mm F/1.4 の場合、名前は SIGMA 、 焦点距離 は85 mm、 F値 は1.4になります。 SIGMA は、レンズ名というより、メーカー名です。レンズ名だと SIGMA Art Lensのようになるのですが、レンズ名まで指定しても影響はあまりないようです。 焦点距離 焦点距離 とは、レンズの中心から イメージセンサー までの距離です。 イメージセンサー とは、アナログフィルムのデジタル版だと思えば大体あっています。 焦点距離 が短くなるほど、広い範囲を写せます。窓に近づくほど、広い範囲の外の景色が見えるようになるのと一緒です。 焦点距離 が長くなるほど、見える範囲は狭くなりますが、遠くのものを大きく写せます。 この講座では、次の4つの 焦点距離 を使います。 24 mm: 風景を広範囲に撮ったり、寄って撮影するときに使う。 85 mm: 基本はこれ。 105 mm: マクロ撮影（小さいものを拡大して撮影）するときに使う。 300 mm: 遠くにあるものを撮るときに使う。 Promptで使う場合、数字とmmの間は、ブランクを開けてください。ブランクがなくても動きますが、ブランクがあったほうが再現性が高くなります。 F値 F値 （の最小値） = 焦点距離 ÷ レンズの口径です。 焦点距離 が同じ場合、レンズの口径が大きくなるほど、 F値 は小さくなります。レンズの口径が大きくなるほど、取り込める光の量が増えます。 F値 の小さいレンズを明るいレンズといいます。 大抵のレンズには、絞りがついていて、取り込む光の量を調節できます。絞るとは、取り込む光の量を減らすことです。レンズの口径を小さくするのに似ています。つまり、 F値 は大きくなります。 F値 が小さくなるほど、ボケは大きくなります。ボケとは、ピントの合っている部分以外がボケて見えることです。 犬の背景がボケていますね。 この講座では、次の3つの F値 を使います。 1.4: 一番良く使う F値 。 2.8: 焦点距離 300 mmのときに使う。 5.6: マクロ撮影（小さいものを拡大して撮影）のときに使う。 Promptで使う場合、F/数字にしましょう。F数字でも大丈夫です。 SIGMA いろいろ試した中で、 SIGMA のレンズが最も再現性が高く感じたので、このレンズを使って説明します。お気に入りのレンズがあれば SIGMA の部分を置き換えてください。 SIGMA 85 mm F/1.4 今回の講座の標準レンズ。 Promptはこちら。 a photo of a dog in a park, SIGMA 85 mm F/1.4, golden hour, award-winning golden hourは夜明け直後か日暮れ直前の、太陽の光が柔らかく赤みを帯びている時間帯のことです。外で撮る写真は、golden hourに撮るといい感じに見えます。 award-winningをつけるとなんとなく、見栄えのより写真になる気がします。 出力された画像はこちら。 SIGMA 24 mm F/1.4 広角（視野範囲が広い）で風景などを撮るか、対象に少し寄って撮るレンズ。今回はちょっと対象に寄って撮ります。 Promptはこちら。 a photo of a dog in a park, SIGMA 24 mm F/1.4, golden hour, award-winning 85を24に変えただけです。 出力された画像はこちら。 24 mmは、広角レンズに分類されますが、広角レンズ特有の歪みも少なく、使いやすいレンズです。 SIGMA 300 mm F/2.8 遠くにあるものを拡大して撮影する望遠レンズです。 今回は、空を飛んでいる鳥を撮影してみましょう。 Promptはこちら。 a photo of a bird flying in the sky, highly detailed, SIGMA 300 mm F/2.8, golden hour, award-winning なにかを大きく撮影したい場合は、highly detailedを指定します。 出力された画像はこちら。 SIGMA 105 mm F/5.6 小さいものを撮影する マクロレンズ です。 蝶を撮影してみましょう。 Promptはこちら。 a photo of a beautiful butterfly on a flower, highly detailed, SIGMA 105 mm F/5.6, award-winning 出力された画像はこちら。 4つのレンズを試しました。状況によってどのレンズを使えばいいか、なんとなくでもつかめましたか？ シャッタースピード シャッタースピード を調整することで、写真を生き生きとしてモノにできます。 シャッタースピード を速くするには、短時間で撮影に必要な一 定量 の光を集めることが必要です。 光を短時間で集めるには、明るいレンズ（ F値 の低いレンズ）で絞りを開ける、 ISO感度 を上げるという方法があります。 ISO感度 とは、光を電子的に増幅させる性能です。 ISO感度 を2倍にすると シャッタースピード を二倍速くできます。 ISO感度 の基本は100になります。 ISO感度 を上げるとノイズも増幅されてしまうので、単に上げればよいというものではありません。 1/1000 sec shutter 瞬間を切り取りたいときは、1/1000 sec shutterで シャッタースピード を1/1000秒にするのが良いでしょう。今回は、F/1.4の明るいレンズを使います。 ISO感度 は、時間帯など状況に合わせて調整してください。 波しぶきを撮影してみましょう。 今回のPromptはこちら。 a photo of beautiful ocean spray, golden hour, SIGMA 85 mm F/1.4, 1/1000 sec shutter, ISO 400, award-winning 時間帯をgolden hourにしたので、 ISO感度 を400にしました。 出力された画像はこちら。 ocean, 5 sec shutter 海など、動きがゆっくりのものを シャッタースピード を遅くして撮影すると、幻想的な写真が取れることがあります。 今回のPromptはこちら。 a photo of beautiful ocean, golden hour, SIGMA 24 mm F/1.4, 5 sec shutter, award-winning 出力された画像はこちら。 cars with lights, blue hour, 1/10 sec speed 暗くなった時間帯に、ライトを付けた車を シャッタースピード を落として撮影すると、美しい光の残像を撮ることができます。 今回のPromptはこちら。 a photo of cars with lights speeding on highway, blue hour, SIGMA 85 mm F/1.4, 1/10 sec shutter, award-winning blue hourは、日の出前と日の入り後に発生する空が濃い青色に染まる時間帯のことです。 出力された画像はこちら。 panning shot, 1/20 sec shutter パン撮影は、動く被写体と一緒にカメラを動かし、被写体にピントを合わせて背景をブレさせる手法です。panning shotのキーワードを使いましょう。 シャッタースピード は少しだけ落とします。この撮影法は、再現性が低いので、うまくいくまで何度も試してください。 今回のPromptはこちら。 a panning shot of a car, SIGMA 300 mm F/2.8, 1/20 sec shutter 望遠レンズを使ったほうが再現性は高くなります。panning shotというキーワードを見つけるのに、100回以上、 トライアンドエラー を繰り返しました。motion blur というキーワードもあるのですが、ほとんどの場合、被写体もブレてしまいます。 背景だけブレさせるというのが難しいのです。 出力された画像はこちら。 かなり疾走感のある画像になっていますね。 まとめ 今回は、レンズといろいろな撮影テクニックについて解説しました。 次は、 画像タイプ について解説します。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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はAIカメラなので、どのようなレンズを使うかどうかはとても重要です。カメラの知識が必要ですが、基礎から丁寧に説明するので大丈夫です。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 レンズの属性 焦点距離 F値 SIGMA SIGMA 85 mm F/1.4 SIGMA 24 mm F/1.4 SIGMA 300 mm F/2.8 SIGMA 105 mm F/5.6 シャッタースピード 1/1000 sec shutter ocean, 5 sec shutter cars with lights, blue hour, 1/10 sec speed panning shot, 1/20 sec shutter まとめ 仲間募集 Stable Diffusionの過去コンテンツ レンズの属性 レンズは、 名前 焦点距離 F値 のような属性を持っています。例えば、 SIGMA 85 mm F/1.4 の場合、名前は SIGMA 、 焦点距離 は85 mm、 F値 は1.4になります。 SIGMA は、レンズ名というより、メーカー名です。レンズ名だと SIGMA Art Lensのようになるのですが、レンズ名まで指定しても影響はあまりないようです。 焦点距離 焦点距離 とは、レンズの中心から イメージセンサー までの距離です。 イメージセンサー とは、アナログフィルムのデジタル版だと思えば大体あっています。 焦点距離 が短くなるほど、広い範囲を写せます。窓に近づくほど、広い範囲の外の景色が見えるようになるのと一緒です。 焦点距離 が長くなるほど、見える範囲は狭くなりますが、遠くのものを大きく写せます。 この講座では、次の4つの 焦点距離 を使います。 24 mm: 風景を広範囲に撮ったり、寄って撮影するときに使う。 85 mm: 基本はこれ。 105 mm: マクロ撮影（小さいものを拡大して撮影）するときに使う。 300 mm: 遠くにあるものを撮るときに使う。 Promptで使う場合、数字とmmの間は、ブランクを開けてください。ブランクがなくても動きますが、ブランクがあったほうが再現性が高くなります。 F値 F値 （の最小値） = 焦点距離 ÷ レンズの口径です。 焦点距離 が同じ場合、レンズの口径が大きくなるほど、 F値 は小さくなります。レンズの口径が大きくなるほど、取り込める光の量が増えます。 F値 の小さいレンズを明るいレンズといいます。 大抵のレンズには、絞りがついていて、取り込む光の量を調節できます。絞るとは、取り込む光の量を減らすことです。レンズの口径を小さくするのに似ています。つまり、 F値 は大きくなります。 F値 が小さくなるほど、ボケは大きくなります。ボケとは、ピントの合っている部分以外がボケて見えることです。 犬の背景がボケていますね。 この講座では、次の3つの F値 を使います。 1.4: 一番良く使う F値 。 2.8: 焦点距離 300 mmのときに使う。 5.6: マクロ撮影（小さいものを拡大して撮影）のときに使う。 Promptで使う場合、F/数字にしましょう。F数字でも大丈夫です。 SIGMA いろいろ試した中で、 SIGMA のレンズが最も再現性が高く感じたので、このレンズを使って説明します。お気に入りのレンズがあれば SIGMA の部分を置き換えてください。 SIGMA 85 mm F/1.4 今回の講座の標準レンズ。 Promptはこちら。 a photo of a dog in a park, SIGMA 85 mm F/1.4, golden hour, award-winning golden hourは夜明け直後か日暮れ直前の、太陽の光が柔らかく赤みを帯びている時間帯のことです。外で撮る写真は、golden hourに撮るといい感じに見えます。 award-winningをつけるとなんとなく、見栄えのより写真になる気がします。 出力された画像はこちら。 SIGMA 24 mm F/1.4 広角（視野範囲が広い）で風景などを撮るか、対象に少し寄って撮るレンズ。今回はちょっと対象に寄って撮ります。 Promptはこちら。 a photo of a dog in a park, SIGMA 24 mm F/1.4, golden hour, award-winning 85を24に変えただけです。 出力された画像はこちら。 24 mmは、広角レンズに分類されますが、広角レンズ特有の歪みも少なく、使いやすいレンズです。 SIGMA 300 mm F/2.8 遠くにあるものを拡大して撮影する望遠レンズです。 今回は、空を飛んでいる鳥を撮影してみましょう。 Promptはこちら。 a photo of a bird flying in the sky, highly detailed, SIGMA 300 mm F/2.8, golden hour, award-winning なにかを大きく撮影したい場合は、highly detailedを指定します。 出力された画像はこちら。 SIGMA 105 mm F/5.6 小さいものを撮影する マクロレンズ です。 蝶を撮影してみましょう。 Promptはこちら。 a photo of a beautiful butterfly on a flower, highly detailed, SIGMA 105 mm F/5.6, award-winning 出力された画像はこちら。 4つのレンズを試しました。状況によってどのレンズを使えばいいか、なんとなくでもつかめましたか？ シャッタースピード シャッタースピード を調整することで、写真を生き生きとしてモノにできます。 シャッタースピード を速くするには、短時間で撮影に必要な一 定量 の光を集めることが必要です。 光を短時間で集めるには、明るいレンズ（ F値 の低いレンズ）で絞りを開ける、 ISO感度 を上げるという方法があります。 ISO感度 とは、光を電子的に増幅させる性能です。 ISO感度 を2倍にすると シャッタースピード を二倍速くできます。 ISO感度 の基本は100になります。 ISO感度 を上げるとノイズも増幅されてしまうので、単に上げればよいというものではありません。 1/1000 sec shutter 瞬間を切り取りたいときは、1/1000 sec shutterで シャッタースピード を1/1000秒にするのが良いでしょう。今回は、F/1.4の明るいレンズを使います。 ISO感度 は、時間帯など状況に合わせて調整してください。 波しぶきを撮影してみましょう。 今回のPromptはこちら。 a photo of beautiful ocean spray, golden hour, SIGMA 85 mm F/1.4, 1/1000 sec shutter, ISO 400, award-winning 時間帯をgolden hourにしたので、 ISO感度 を400にしました。 出力された画像はこちら。 ocean, 5 sec shutter 海など、動きがゆっくりのものを シャッタースピード を遅くして撮影すると、幻想的な写真が取れることがあります。 今回のPromptはこちら。 a photo of beautiful ocean, golden hour, SIGMA 24 mm F/1.4, 5 sec shutter, award-winning 出力された画像はこちら。 cars with lights, blue hour, 1/10 sec speed 暗くなった時間帯に、ライトを付けた車を シャッタースピード を落として撮影すると、美しい光の残像を撮ることができます。 今回のPromptはこちら。 a photo of cars with lights speeding on highway, blue hour, SIGMA 85 mm F/1.4, 1/10 sec shutter, award-winning blue hourは、日の出前と日の入り後に発生する空が濃い青色に染まる時間帯のことです。 出力された画像はこちら。 panning shot, 1/20 sec shutter パン撮影は、動く被写体と一緒にカメラを動かし、被写体にピントを合わせて背景をブレさせる手法です。panning shotのキーワードを使いましょう。 シャッタースピード は少しだけ落とします。この撮影法は、再現性が低いので、うまくいくまで何度も試してください。 今回のPromptはこちら。 a panning shot of a car, SIGMA 300 mm F/2.8, 1/20 sec shutter 望遠レンズを使ったほうが再現性は高くなります。panning shotというキーワードを見つけるのに、100回以上、 トライアンドエラー を繰り返しました。motion blur というキーワードもあるのですが、ほとんどの場合、被写体もブレてしまいます。 背景だけブレさせるというのが難しいのです。 出力された画像はこちら。 かなり疾走感のある画像になっていますね。 まとめ 今回は、レンズといろいろな撮影テクニックについて解説しました。 次は、 画像タイプ について解説します。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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についてシリーズで書いていきたいと思います。 基本的な方針は、Promptの仕組みを体系的に理解することです。元ネタとしては、 DALL·E 2 Prompt Book を使います。 DALL·E 2 Prompt Bookの内容を試し、僕なりに消化したことを説明していきたいと思います。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 実行環境 Promptとは 人物写真 a close-up of face shot a close-up of eyes shot a head shot an upper shot a full body shot shot from above shot from below まとめ 仲間募集 Stable Diffusionの過去コンテンツ 実行環境 実行環境は、Webで試すことのできる Dream Studio が最も手軽です。ログインすると画面の真ん中下の方にDreamというボタンがあります。その左のエリアがPromptを入力する部分です。 Promptとは Promptとは、StableDiffusionにこういう画像を作ってほしいと依頼する文のことです。 StableDiffusionというのは、Promptを理解できるAIカメラだと捉えましょう。 Promptの書き方に特に決まりはないのですが、次のフォーマットで入力することをおすすめします。 画像のタイプ of サブジェクト, 追加の文, 追加の分 画像のタイプは、photoやoil paintingなどいろいろあります。 サブジ ェクトは、描画したい対象です。 人物写真 最初は、人物写真を撮ってみましょう。基本のPromptは、次のようになります。 a xxx photo of サブジェクト with yyy eyes, a zzz shot, dramatic backlighting a close-up of face shot xxxは好きな修飾語を入れていいのですが、人物写真の場合は、black and whiteがおすすめです。 サブジ ェクトは、今回は、gorgeous human femaleにしましょう。humanをつけないとたまに、ライオンのメスなどが対象になるときがあります。 with yyy eyesは、入れたほうが描画が安定します。今回は、yyyにfriendlyを指定します。 zzzは、体のどの部分を描画するのかを指定します。今回は、a close-up of face shotを指定します。 最終的にPromptは下記のようになりました。 a black and white photo of a gorgeous human female with friendly eyes, a close-up of face shot, dramatic backlighting 出力された画像は下記のようになりました。 a close-up of eyes shot 今度は、a close-up of face shotの部分をa close-up of eyes shotに変更しましょう。 Promptは下記のようになります。 a black and white photo of a gorgeous human female with friendly eyes, a close-up of eyes shot, dramatic backlighting 出力された画像は、下記のようになりました。 目がより強調されましたね。 a head shot a close-up of face shotよりも、若干引いて、肩が写るときもあれば、写らないときもあるのが、a head shotです。 Promptは下記のようになります。 a black and white photo of a gorgeous human female with friendly eyes, a head shot, dramatic backlighting 出力された画像は、下記のようになりました。 肩を確実に出力するために、a head and shoulder shotというのもありますが、肩が不自然に強調されることがあり、出力が安定しません。 an upper shot 胸より上、つまり上半身を写すのが、an upper shotです。胸は写らないことのほうが多いです。 Promptは下記のようになります。 a black and white photo of a gorgeous human female with friendly eyes, an upper shot, dramatic backlighting 出力された画像は下記のようになりました。 a medium shotというものもあるのですが、出力が安定しません。腰から上を出力する a waist shotというものもありますが、こちらも出力が安定しません。 a full body shot 体全体を写すのが、a full body shotですが、このshotは扱いが難しいです。 まず、次のPromptを出力してみてください。 a black and white photo of a gorgeous human female with friendly eyes, a full body shot, dramatic backlighting 何度か試すと、Dream Studioで使っている人には、ぼかされた画像が表示されたはずです。Dream Studio以外を使っている人には、真っ黒な画像が表示されたはずです。これは、NSFWコンテンツといって、職場や学校などのフォーマルな環境下での閲覧に注意を促すためのものです。 full bodyという言葉から生成される画像は、NSFWコンテンツになりやすいということです。これを解決するために、shot from afarという文を追加しましょう。離れたところから撮影するという意味です。これで、だいぶ、NSFWコンテンツに指定される確率が減ります。 a black and white photo of a gorgeous human female with friendly eyes, shot from afar, a full body shot, dramatic backlighting これでも、NSFWコンテンツに何度かに一回は指定されるし、指定されなかったとしても、体のラインを強調したような画像が出力されることが多いでしょう。これを解決するために、gorgeousをmysteriousに変更します。gorgeousとfull bodyの相性が悪かったわけです。 a black and white photo of mysterious human female, shot from afar, a full body shot, dramatic backlighting 出力された画像は下記のようになりました。 shot from above 上から写真を取るには、shot from aboveを使います。 a black and white photo of a gorgeous human female with friendly eyes, shot from above, dramatic backlighting 出力された画像は下記のようになりました。 shot from below 下から写真を取るには、shot from belowを使います。 a black and white photo of a gorgeous human female with friendly eyes, shot from below, dramatic backlighting 出力された画像は下記のようになりました。 まとめ 今回は、人物写真を説明しました。shotキーワードでStableDiffusionに対して、どう撮影したいのかを伝える方法が、理解できたと思います。 次回は、 レンズ を説明します。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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についてシリーズで書いていきたいと思います。 基本的な方針は、Promptの仕組みを体系的に理解することです。元ネタとしては、 DALL·E 2 Prompt Book を使います。 DALL·E 2 Prompt Bookの内容を試し、僕なりに消化したことを説明していきたいと思います。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 実行環境 Promptとは 人物写真 a close-up of face shot a close-up of eyes shot a head shot an upper shot a full body shot shot from above shot from below まとめ 仲間募集 Stable Diffusionの過去コンテンツ 実行環境 実行環境は、Webで試すことのできる Dream Studio が最も手軽です。ログインすると画面の真ん中下の方にDreamというボタンがあります。その左のエリアがPromptを入力する部分です。 Promptとは Promptとは、StableDiffusionにこういう画像を作ってほしいと依頼する文のことです。 StableDiffusionというのは、Promptを理解できるAIカメラだと捉えましょう。 Promptの書き方に特に決まりはないのですが、次のフォーマットで入力することをおすすめします。 画像のタイプ of サブジェクト, 追加の文, 追加の分 画像のタイプは、photoやoil paintingなどいろいろあります。 サブジ ェクトは、描画したい対象です。 人物写真 最初は、人物写真を撮ってみましょう。基本のPromptは、次のようになります。 a xxx photo of サブジェクト with yyy eyes, a zzz shot, dramatic backlighting a close-up of face shot xxxは好きな修飾語を入れていいのですが、人物写真の場合は、black and whiteがおすすめです。 サブジ ェクトは、今回は、gorgeous human femaleにしましょう。humanをつけないとたまに、ライオンのメスなどが対象になるときがあります。 with yyy eyesは、入れたほうが描画が安定します。今回は、yyyにfriendlyを指定します。 zzzは、体のどの部分を描画するのかを指定します。今回は、a close-up of face shotを指定します。 最終的にPromptは下記のようになりました。 a black and white photo of a gorgeous human female with friendly eyes, a close-up of face shot, dramatic backlighting 出力された画像は下記のようになりました。 a close-up of eyes shot 今度は、a close-up of face shotの部分をa close-up of eyes shotに変更しましょう。 Promptは下記のようになります。 a black and white photo of a gorgeous human female with friendly eyes, a close-up of eyes shot, dramatic backlighting 出力された画像は、下記のようになりました。 目がより強調されましたね。 a head shot a close-up of face shotよりも、若干引いて、肩が写るときもあれば、写らないときもあるのが、a head shotです。 Promptは下記のようになります。 a black and white photo of a gorgeous human female with friendly eyes, a head shot, dramatic backlighting 出力された画像は、下記のようになりました。 肩を確実に出力するために、a head and shoulder shotというのもありますが、肩が不自然に強調されることがあり、出力が安定しません。 an upper shot 胸より上、つまり上半身を写すのが、an upper shotです。胸は写らないことのほうが多いです。 Promptは下記のようになります。 a black and white photo of a gorgeous human female with friendly eyes, an upper shot, dramatic backlighting 出力された画像は下記のようになりました。 a medium shotというものもあるのですが、出力が安定しません。腰から上を出力する a waist shotというものもありますが、こちらも出力が安定しません。 a full body shot 体全体を写すのが、a full body shotですが、このshotは扱いが難しいです。 まず、次のPromptを出力してみてください。 a black and white photo of a gorgeous human female with friendly eyes, a full body shot, dramatic backlighting 何度か試すと、Dream Studioで使っている人には、ぼかされた画像が表示されたはずです。Dream Studio以外を使っている人には、真っ黒な画像が表示されたはずです。これは、NSFWコンテンツといって、職場や学校などのフォーマルな環境下での閲覧に注意を促すためのものです。 full bodyという言葉から生成される画像は、NSFWコンテンツになりやすいということです。これを解決するために、shot from afarという文を追加しましょう。離れたところから撮影するという意味です。これで、だいぶ、NSFWコンテンツに指定される確率が減ります。 a black and white photo of a gorgeous human female with friendly eyes, shot from afar, a full body shot, dramatic backlighting これでも、NSFWコンテンツに何度かに一回は指定されるし、指定されなかったとしても、体のラインを強調したような画像が出力されることが多いでしょう。これを解決するために、gorgeousをmysteriousに変更します。gorgeousとfull bodyの相性が悪かったわけです。 a black and white photo of mysterious human female, shot from afar, a full body shot, dramatic backlighting 出力された画像は下記のようになりました。 shot from above 上から写真を取るには、shot from aboveを使います。 a black and white photo of a gorgeous human female with friendly eyes, shot from above, dramatic backlighting 出力された画像は下記のようになりました。 shot from below 下から写真を取るには、shot from belowを使います。 a black and white photo of a gorgeous human female with friendly eyes, shot from below, dramatic backlighting 出力された画像は下記のようになりました。 まとめ 今回は、人物写真を説明しました。shotキーワードでStableDiffusionに対して、どう撮影したいのかを伝える方法が、理解できたと思います。 次回は、 レンズ を説明します。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 で執筆されました ）

はじめに Cypress 導入、操作手順 テストコードの実装方法 お気に入りポイント TypeScript対応 Custom Commands cypress/support/commands.ts cypress/support/e2e.ts fixture cypress/fixtures/users.json cypress/support/e2e.ts ハマりポイント iframe ドラッグ&ドロップ おわりに はじめに こんにちは。X イノベーション 本部の稲丸です。 みなさんは、E2Eテストをどのように作成・実施されていますか？ 人力で実施している、 Selenium で自動化している、などさまざまな方法が考えられますが、最近はCypressを利用されている方も多いのではないでしょうか。 ISIDでは、 Ci*X Workflow という汎用ワークフローシステムの開発において、Cypressを用いてE2Eテストを作成・自動化しています。 今回は、E2Eテスト フレームワーク Cypress をご紹介します。 Cypress Cypressは、 JavaScript で実装された オープンソース のE2Eテスト フレームワーク です。 多くのE2Eテスト フレームワーク と異なり、 Selenium に依存していない点が特徴の1つです。 また、テストの実装に必要なライブラリの多くをバンドルしており、基本的なテストであればCypress以外のライブラリをインストールすることなく実装できます。 導入、操作手順 Cypressはnpmパッケージとして提供されているため、Node.jsがインストールされた環境下で下記のコマンドを実行するとインストールできます。 npm install cypress --save-dev Cypressには、 GUI ツールと CLI ツールがそれぞれ用意されています。 下記のコマンドで、 GUI ツール（管理画面）を立ち上げることができます。 npx cypress open 初回起動時など、プロジェクト内にテストコードが存在しない場合は、管理画面上からテンプレートプロジェクトを作成できます。 プロジェクト内にテストコードが存在する場合は、管理画面から作成したテストを実行できます。 また、 CLI ツールを用いて、作成したテストをコマンドで実行することもできます。 （下記の例では、実行ブラウザとして Chrome を指定しています） npx cypress run --browser chrome テストの設定は、 cypress.config.js（.ts） という設定ファイルに記述します。 import { defineConfig } from "cypress"; export default defineConfig({ e2e: { baseUrl: "http://localhost:3000", screenshotOnRunFailure: false, video: false, specPattern: [ "cypress/e2e/spec.cy.ts", "cypress/e2e/another-spec.cy.ts" ], }, }); 通常、specPatternは実行するテストファイル名のパターンを記述します（デフォルト値は cypress/e2e/**/*.cy.{js,jsx,ts,tsx} ）。一方、上記の例のように配列形式でテストファイル名を記述することで、テストの実行順を制御できます。 他にも多くのパラメータが設定可能なので、詳細は こちら をご参照ください。 テストコードの実装方法 まず、 cypress/e2e/ 配下にテストファイルを作成します。管理画面上から、「New Spec」→「Create new empty spec」とクリックして作成することもできます。 次に、describe-itメソッドでテストメソッドを実装します。 describe("Nuxt Application", () => { it("Rendering Welcome Page", () => { cy.visit("/"); cy.get("h2").should("include.text", "Welcome to your Nuxt Application"); }); }); DOM要素の取得や操作は、Cypressの ビルトインAPI を使用します。 また、 アサーション は Chai の API を用いて記述します。 お気に入りポイント Cypressを使用してみて、個人的に良いと感じた点（機能）をご紹介します。 TypeScript対応 CypressはTypeScriptに対応しています。 型定義が提供されているだけでなく、TypeScriptで記述したテストコードを JavaScript にビルドすることなくそのまま実行できます。 （プロジェクト内にTypeScriptをインストールする必要があります） Custom Commands Custom Commands という機能を使うことで、ビルトイン API を拡張したり、独自の API を追加できます。 共通処理をCustom Commandsとして登録することで、テストコードの可読性を向上させることができます。 下記の例では、ログイン処理をCustom Commandsとして登録し、各テストメソッドの実行前にログイン処理を実行しています。 cypress/support/commands.ts // ログイン処理（IDとパスワードを入力してログインボタンをクリックする） Cypress.Commands.add("login", (id: string, password: string) => { cy.get("input[type='text']").type(id); cy.get("input[type='password']").type(password); cy.get("button").contains("ログイン").click(); }); cypress/support/e2e.ts import "./commands"; beforeEach(() => { // ログイン画面にアクセス cy.visit("/login"); // テスト用のユーザーアカウントでログインする cy.login("test1", "password"); }); fixture fixture という機能を使うことで、プロジェクト内に用意したテストデータを読み込むことができます。 これによって、テストコードとテストデータを分離して管理できます。 下記の例では、ユーザーアカウント情報をテストデータとして作成し、そのデータを使ってログイン処理を実行しています。 cypress/fixtures/users. json [ { "id": "test1", "password": "password", "admin": true }, { "id": "test2", "password": "password", "admin": false } ] cypress/support/e2e.ts require("./commands"); interface User { id: string; password: string; admin: boolean; } beforeEach(() => { // ログイン画面にアクセス cy.visit("/login"); // テスト用の管理者アカウントでログインする cy.fixture("users.json").then((users: User[]) => { const admin = users.find((user) => user.admin); cy.login(admin.id, admin.password); }); }); ハマりポイント Cypressを使用してみて、少しハマった点をご紹介します。 iframe テストを実行すると指定したブラウザが起動しますが、テスト対象のアプリケーションの画面はiframe内に描画されます。 テストコードを実装する際は、基本的にビルトイン API を使用してDOM要素の取得や操作を行うので、iframeを意識することはありません。 しかし、例えばアプリケーションの画面でさらにiframeを使用している場合などは、iframeを意識する必要があります。 つまり、アプリケーション画面内のiframeの読み込みが完了するのを待ち、 iframe > 対象の要素 という構造を意識してDOM要素の取得や操作を行います。 working-with-iframes-in-cypress ドラッグ&ドロップ Cypressには、 ドラッグ&ドロップ 操作を行う API が提供されていません。 HTML標準の ドラッグ&ドロップ イベントをトリガーすることで実装できますが、 cypress-drag-drop という プラグイン を導入すると、より簡潔に実装できます。 ドラッグ&ドロップ に限らず、多くの サードパーティ製プラグイン が存在するので、困った場合は独自実装する前に プラグイン を探すと良いかと思います。 おわりに 以上、簡単ではありますが、Cypressについてご紹介しました。 いかがでしたか？Cypressには本記事で言及した機能以外にもさまざまな機能があります。 また、現在も頻繁に更新されており、今後ますます使いやすくなることが期待されます。 E2Eテストの作成・自動化を検討されている方や、Cypressに興味がある方にとって、本記事の内容が少しでもご参考になれば幸いです。 私たちは同じチームで働いてくれる仲間を探しています。プロダクト開発に興味がある方のご応募をお待ちしています。 プロダクトプラットフォーム開発エンジニア/新規プロダクト開発エンジニア 執筆： @inamaru.yuki 、レビュー： @sato.taichi （ Shodo で執筆されました ）

はじめに Cypress 導入、操作手順 テストコードの実装方法 お気に入りポイント TypeScript対応 Custom Commands cypress/support/commands.ts cypress/support/e2e.ts fixture cypress/fixtures/users.json cypress/support/e2e.ts ハマりポイント iframe ドラッグ&ドロップ おわりに はじめに こんにちは。X イノベーション 本部の稲丸です。 みなさんは、E2Eテストをどのように作成・実施されていますか？ 人力で実施している、 Selenium で自動化している、などさまざまな方法が考えられますが、最近はCypressを利用されている方も多いのではないでしょうか。 ISIDでは、 Ci*X Workflow という汎用ワークフローシステムの開発において、Cypressを用いてE2Eテストを作成・自動化しています。 今回は、E2Eテスト フレームワーク Cypress をご紹介します。 Cypress Cypressは、 JavaScript で実装された オープンソース のE2Eテスト フレームワーク です。 多くのE2Eテスト フレームワーク と異なり、 Selenium に依存していない点が特徴の1つです。 また、テストの実装に必要なライブラリの多くをバンドルしており、基本的なテストであればCypress以外のライブラリをインストールすることなく実装できます。 導入、操作手順 Cypressはnpmパッケージとして提供されているため、Node.jsがインストールされた環境下で下記のコマンドを実行するとインストールできます。 npm install cypress --save-dev Cypressには、 GUI ツールと CLI ツールがそれぞれ用意されています。 下記のコマンドで、 GUI ツール（管理画面）を立ち上げることができます。 npx cypress open 初回起動時など、プロジェクト内にテストコードが存在しない場合は、管理画面上からテンプレートプロジェクトを作成できます。 プロジェクト内にテストコードが存在する場合は、管理画面から作成したテストを実行できます。 また、 CLI ツールを用いて、作成したテストをコマンドで実行することもできます。 （下記の例では、実行ブラウザとして Chrome を指定しています） npx cypress run --browser chrome テストの設定は、 cypress.config.js（.ts） という設定ファイルに記述します。 import { defineConfig } from "cypress"; export default defineConfig({ e2e: { baseUrl: "http://localhost:3000", screenshotOnRunFailure: false, video: false, specPattern: [ "cypress/e2e/spec.cy.ts", "cypress/e2e/another-spec.cy.ts" ], }, }); 通常、specPatternは実行するテストファイル名のパターンを記述します（デフォルト値は cypress/e2e/**/*.cy.{js,jsx,ts,tsx} ）。一方、上記の例のように配列形式でテストファイル名を記述することで、テストの実行順を制御できます。 他にも多くのパラメータが設定可能なので、詳細は こちら をご参照ください。 テストコードの実装方法 まず、 cypress/e2e/ 配下にテストファイルを作成します。管理画面上から、「New Spec」→「Create new empty spec」とクリックして作成することもできます。 次に、describe-itメソッドでテストメソッドを実装します。 describe("Nuxt Application", () => { it("Rendering Welcome Page", () => { cy.visit("/"); cy.get("h2").should("include.text", "Welcome to your Nuxt Application"); }); }); DOM要素の取得や操作は、Cypressの ビルトインAPI を使用します。 また、 アサーション は Chai の API を用いて記述します。 お気に入りポイント Cypressを使用してみて、個人的に良いと感じた点（機能）をご紹介します。 TypeScript対応 CypressはTypeScriptに対応しています。 型定義が提供されているだけでなく、TypeScriptで記述したテストコードを JavaScript にビルドすることなくそのまま実行できます。 （プロジェクト内にTypeScriptをインストールする必要があります） Custom Commands Custom Commands という機能を使うことで、ビルトイン API を拡張したり、独自の API を追加できます。 共通処理をCustom Commandsとして登録することで、テストコードの可読性を向上させることができます。 下記の例では、ログイン処理をCustom Commandsとして登録し、各テストメソッドの実行前にログイン処理を実行しています。 cypress/support/commands.ts // ログイン処理（IDとパスワードを入力してログインボタンをクリックする） Cypress.Commands.add("login", (id: string, password: string) => { cy.get("input[type='text']").type(id); cy.get("input[type='password']").type(password); cy.get("button").contains("ログイン").click(); }); cypress/support/e2e.ts import "./commands"; beforeEach(() => { // ログイン画面にアクセス cy.visit("/login"); // テスト用のユーザーアカウントでログインする cy.login("test1", "password"); }); fixture fixture という機能を使うことで、プロジェクト内に用意したテストデータを読み込むことができます。 これによって、テストコードとテストデータを分離して管理できます。 下記の例では、ユーザーアカウント情報をテストデータとして作成し、そのデータを使ってログイン処理を実行しています。 cypress/fixtures/users. json [ { "id": "test1", "password": "password", "admin": true }, { "id": "test2", "password": "password", "admin": false } ] cypress/support/e2e.ts require("./commands"); interface User { id: string; password: string; admin: boolean; } beforeEach(() => { // ログイン画面にアクセス cy.visit("/login"); // テスト用の管理者アカウントでログインする cy.fixture("users.json").then((users: User[]) => { const admin = users.find((user) => user.admin); cy.login(admin.id, admin.password); }); }); ハマりポイント Cypressを使用してみて、少しハマった点をご紹介します。 iframe テストを実行すると指定したブラウザが起動しますが、テスト対象のアプリケーションの画面はiframe内に描画されます。 テストコードを実装する際は、基本的にビルトイン API を使用してDOM要素の取得や操作を行うので、iframeを意識することはありません。 しかし、例えばアプリケーションの画面でさらにiframeを使用している場合などは、iframeを意識する必要があります。 つまり、アプリケーション画面内のiframeの読み込みが完了するのを待ち、 iframe > 対象の要素 という構造を意識してDOM要素の取得や操作を行います。 working-with-iframes-in-cypress ドラッグ&ドロップ Cypressには、 ドラッグ&ドロップ 操作を行う API が提供されていません。 HTML標準の ドラッグ&ドロップ イベントをトリガーすることで実装できますが、 cypress-drag-drop という プラグイン を導入すると、より簡潔に実装できます。 ドラッグ&ドロップ に限らず、多くの サードパーティ製プラグイン が存在するので、困った場合は独自実装する前に プラグイン を探すと良いかと思います。 おわりに 以上、簡単ではありますが、Cypressについてご紹介しました。 いかがでしたか？Cypressには本記事で言及した機能以外にもさまざまな機能があります。 また、現在も頻繁に更新されており、今後ますます使いやすくなることが期待されます。 E2Eテストの作成・自動化を検討されている方や、Cypressに興味がある方にとって、本記事の内容が少しでもご参考になれば幸いです。 私たちは同じチームで働いてくれる仲間を探しています。プロダクト開発に興味がある方のご応募をお待ちしています。 プロダクトプラットフォーム開発エンジニア/新規プロダクト開発エンジニア 執筆： @inamaru.yuki 、レビュー： @sato.taichi （ Shodo で執筆されました ）

こんにちは！金融ソリューション事業部の山下です。 前回の 「バーチャルヒューマンをリアルタイムフェイスリグで動かす」 の記事に引き続き、最新の3DCG技術を紹介します。 本記事では、特に映画/ゲーム業界等で VFX に活用されている Houdini を使って、トップ画像のようなフォトリアルな雲を レンダリング します。 雲のような3次元空間上に密度分布を持った現象をシミュレーションする為に、 オープンソース の OpenVDB ライブラリを利用します。 前提知識 1. Voxel 3次元データを表す最小単位です。Voxelが集まったデータをVolumeと呼びます。 座標以外にも様々なデータ（濃度、温度、速度）を持たせることで、水、火、煙、雲などの物理シミュレーションにも活用されています。 2. OpenVDB （画像： https://www.openvdb.org ） 3次元データを操作する為のデータ規格およびモジュールライブラリです。今回用いるHoudiniや、 Blender など様々なCGソフトに採用されています。 Academy Software Foundation が オープンソース として管理しており、2014年に アカデミー賞 （科学技術部門）も受賞しています。 NVIDIA を中心に活発に開発が進められており、直近では以下の新機能が追加されています： NanoVDB （2021）：データ構造の改善により、 GPU 処理が可能になりました。これまで計算負荷の高かったボリュームのシミュレーションが高速に可能になったことで、去年ごろからリアルタイムにボリュームデータを レンダリング する ユースケース も増えました。 NeuralVDB （2022）： GPU 上の処理に 機械学習 を取り入れることで、メモリ使用量を1/100に削減！現時点で3DCGツールへの導入は限定的だが、既に NVIDIA Omniverse では導入されている模様です。 3. Houdini （画像： https://www.sidefx.com/ja/products/houdini) ） Side Effects Software社が開発する3DCGソフトウェアです。ノードベー スプログ ラミングを採用しており、プロシージャル（手続き的）に可変的なシミュレーションが可能です。（VEXコードというテキストベースの プログラミング言語 も利用可能） 映画、ゲーム、科学などの業界で、20年以上前から複雑なシミュレーションに活用されており、その功績として2018年に アカデミー賞 （科学技術部門）も受賞しています。 Houdiniでボリュームを扱う際には、Houdini独自VolumeとOpenVBDの2種類の処理方式が利用可能です。 4. Redshift （画像： https://docs.redshift3d.com/display/redshift3d/redshift3d+Home ） Redshift Rendering Technologies社（2019年にMaxon社が買収）が開発する3DCG レンダリング ソフトウェアです。高速処理が可能になる GPU レンダリング を2014年に世界で始めて商用化しました。 Maxon社の提供する3DCGツールであるCinema4Dに加えて、Autodesk社のMayaなどでも利用可能です。 元は NVIDIA GPU のみに対応しておりましたが、2021年には macOS にも対応しました。 シミュレーションの実施 実行環境 macOS 12.1 Monterey( Apple M1 Max) Houdini FX 19.5.303 Redshift4houdini 3.0.53 手順 1. 雲の元となるポリゴンを作成 2. ポリゴンをボリュームに変換した後、ノイズをかけてディテールを付与 3. マテリアル、ライトを設定して、Redshiftで レンダリング HoudiniやRedshiftのインストール手順は割愛します。 それでは、始めていきます。 手順1. 雲の元となるポリゴンを作成 ここでは、3つのノードを使用します。 1-1. 球体の作成 最初に、 Sphere ノードで球体を作成します。 主な設定値は、以下です。 Primitive Type：「Polygon」 Frequency：24 ポリゴンの数が少ないとこの後かけるノイズが荒くなってしまうので、適当な数に上げています。 Houdiniの場合、最後になってから増やすのも簡単にできるので、パラメータチューニングは最後に行っても大丈夫です。 1-2. ノイズの付与 次に、Attribute Noise（旧名：mountain）ノードでノイズをかけていきます。 このノードでは様々な種類のノイズを、任意のデータに対してかけることができます。 今回は、先ほど作成したポリゴンの各座標Pに対して、「Sparse Convolution」というノイズをかけています。 主な設定値は、以下です。 Noise Value Amplitude：0.61 Nise Pattern Noise Type：「Sparse Convolution」 Element Size：0.37 Offset：4.42 ジオメトリのデータを参照するViewであるGeometry Spreadsheetを見ると、各ポイントの座標が変化しているのが分かります。 変換前：3-1. sphere ノードの値 変換後：3-2. mountainノードの値 1-3. Y軸方向に変形 雲のような形にする為、Y軸方向を0.5倍にスケールして押し潰します。 Transformノード内に「Scale」という項目があるので、Y軸の値を0.5に設定します。 これで、雲の元となるポリゴンの作成は完了です。 手順2. ポリゴンをボリュームに変換した後、ノイズをかけてディテールを付与 次に、作成したポリゴンをボリュームデータ（OpenVDB）に変換します。 以下3種類のノードを使用します。 2-1. Cloudノードでボリュームに変換 ポリゴンのボリュームへの変換は、Cloudノードを使用します。 主な設定値は、以下です。 Source：「Polygon Model」 Uniform Smpling Divs：「100」 ここで重要なのが、項目「Uniform Smpling Divs」です。この数値によって、Voxelの分割数が決まります。正方形のポリゴンであれば、10倍にすると単純計算では千から100万にVoxelが増える為、適切な数を設定しましょう。 例えばデフォルトの10のままだと、かなりぼやっとした感じになるのが分かります。 CloudノードはOpenVDBを採用しておりますが、Houdiniでは独自のVolumeノードも用意しております。 試しに、両者を比較してみましょう。 先ほどのTransformノードのアウトプットを新しく作成したVolumeノードにも繋ぎます。 それぞれのデータを見てみす。 VolumeノードではVoxel数が40万程度にあるのに対して、 CloudノードではVoxel数が14万強と、大幅に削減されているのが分かります。 Houdini独自のVolumeは、3次元格子内の全てのVoxelデータを 保有 する為にVoxel数が大きくなっています。 このノードが残っている理由としては、Volume表面の精緻な検出に用いる用途などが挙げられます。 2-2. Cloud Noiseノードで、ノイズを付与 次に、Cloud Noiseノードでノイズをかけていきます。 主な設定値は、以下です。 Amplitude：0.129 Element Size：0.6 様々な設定値によって結果が大きく変わるので、自分の気に入る形になるまで調整を繰り返します。 2-3. Volume VOPノードでさらに細かいノイズを部分的に付与 最後に、Volume VOPノードで最終的なアウトプットを出力します。 houdiniでは、ビジュアルプログラミングが可能になるVOPというノードも提供されています。 この中では、値の変換処理や条件分岐など、少し複雑な処理も簡単に記述できます。 Cloudノードによって、雲の濃さを表すdensityという値（Float型）が作成されているので、この値に対して処理を行います。 VOP内の処理詳細は割愛しますが、変換前はほぼ一律になっていたdensityの値を、Perlinノイズを用いて自然なグラデーションに変換します。また外周部分の厚みが薄い部分の値を、条件分岐を用いて0にしています。 実際に結果を確認する為に、Volume Sliceというノードに接続して確認します。 Volumeは、先に挙げたGeometrySpreadsheetのような2次元データとは異なる3次元データですので、 デバッグ には断面を確認する手法が便利です。 今回はXY平面にスライスして確認します。 各Voxel内でdensityの値は数値（float型）として保持されているので、濃い部分を白く、薄い部分を暗くしたグレイスケールで可視化してみます。 変換前：densityがほぼ一定になっており、全体的に色の濃さが均一になっています。 変換後：densityにPerlinノイズによるばらつきが加わった為、色の濃さも自然にまばらになっています。 以上で、雲のVolumeデータが完成しました。 完成したデータはopenVDBファイルとしてアウトプットします。これでHoudini以外の3DCGソフト（ Blender など）へimport可能です。 前回記事にて用いた Unreal Engine では執筆時点（2022年8月）でopenVDBの対応はされていないようですが、 オープンソース で プラグイン が開発されておりそちらを利用して利用も可能です。 手順3. マテリアル、ライトを設定して、Redshiftで レンダリング 最後に、カメラ、マテリアル、 レンダリング の設定を行い完成画像を出力します。 3DCGソフトに不慣れな方は戸惑うかもしれませんが、3Dモデルを実際に2次元の画像や動画に変換する処理は レンダリング と呼ばれ、 モデリング やアニメーションとは別のソフトを用いることが一般的です。 HoudiniにもMantraというデフォルトの レンダリング 機能が用意されていますが、これは GPU レンダリング に対応していない為、 GPU レンダリング 対応のレンダラーを用います。 HoudiniではRedshift以外にも様々な レンダリング ソフトに対応しており、OTOY社の Octane Render なども有名です。 レンダリング の設定を行う際に注意すべき点としては、ライト、マテリアルに関しては レンダリング エンジン固有のモジュールを用いる必要がある、という点です。 設定内容が膨大になるので、詳細は省き主要な設定内容のみ記載します。 3-1. カメラ Houdiniのカメラを使用します。解像度やFocul Lengthの設定など、様々な可能です。 Enable Photogrametric Exposure：ON Enable Depth of Field：ON 3-2. ライト 今回は、Redshiftの提供するRSLightDomeというライトを用います。 ライトには点（Point light）、面（Area light）、太陽光（Directional light）など様々な種類のライトがあります。 今回は、360°で撮影したHDRIテクスチャ画像を光源として使用できるRSLightDomeノードを使用します。 光源として使用するテクスチャ画像は、CC0の Poly Heaven を使用しました。 3-3.テクスチャ 雲の質感を設定します。 RS Volumeノードで、拡散(Scatter)、吸収(Absorption)、発光(Emission)などの値を設定します。 3-4. レンダラー レンダリング に関する値を設定します。 Global Illumination： Enabled：ON Primary GI Engine：Brute Force Trace Depth：3 Sample Filtering Filter：「Gauss」 Size：4 Redshift → Advanced → Bucket Size：512 今回はBucketRenderingを使用しました。 バケット サイズの設定をしないと処理速度が20倍くらい変わるため注意しましょう。 完成イメージ 完成画像です（LightDomeの背景画像もそのまま残しています）。 私の環境( Apple M1 Max)では、 Bucket Renderingで1~10sec程度、ProgressiveRenderingだと1~2分ほどかかりました。 終わりに いかがでしょうか？ 今回はvbdを作成した後にHoudini内で レンダリング まで行いましたが、 Blender などnanoVDBやneuralVDBに対応している3DCGソフト上であればどこでも扱えます。複数シーケンスとして出力することで、アニメーションがついた表現も可能ですし、OpenVDBはデータ規格だけでなく処理ライブラリも提供されている為、ダイナミックな物理シミュレーションも可能です。 これまで特に映画産業では、雲や炎、水や霧などボリュームデータを用いたシミュレーションは膨大な時間とコンピューティングリソースをかけてプリ レンダリング されてきました。 が、OpenVDBの登場により今後はゲームや メタバース などのリアルタイムインタ ラク ションが求められる環境でも処理が可能になってくると思われます。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 参考 OpenVDB nanoVDB Houdini: What’s new Pyro and FLIP fluids 執筆： @yamashita.yuki 、レビュー： @sato.taichi （ Shodo で執筆されました ）