電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、魅惑的な女アニメ画（トゥーン レンダリング ）の呪文です。 アニメ画と言っても 美少女アニメ画編 でとりあげたような、animeキーワードを用いるものではなく、トゥーン レンダリング を使ったアニメ画になります。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 トゥーンレンダリング cel shaded art of a seductive girl, beautiful face, cute eyes black and white cel shaded art artstation, deviantart, concept art, digital painting, award-winning seductive beautiful girl, upper shot, seductive posing, beautiful costume, fantasy background, beautiful composition, cinematic lighting, cinematic postprocessing princess posing まとめ 仲間募集 Stable Diffusionの過去コンテンツ トゥーン レンダリング トゥーン レンダリング とは、コンピュータグラフィックスにおいて3Dモデルを手描きアニメーション、あるいは漫画やイラスト風の作画（アニメ絵）で レンダリング する手法のことです。 wikipedia トゥーンレンダリング ゼルダの伝説 ブレス オブ ザ ワイルド のTrailerを見ると、どういうものかわかるでしょう。 Stable Diffusionでは、画像タイプとして、cel shaded artを使います。 cel shaded art of a seductive girl, beautiful face, cute eyes seductive（魅惑的な）が、今回の記事の最も重要なキーワードです。seductiveをつけた サブジ ェクト（描画対象）は文字通り魅惑的になりますが、NSFW（職場での閲覧は危険）になりやすいという欠点も持っています。 人物を描画する場合、faceとeyesのキワードは必ず入れておきましょう。 今回のPrompt（呪文）はこちら。 cel shaded art of a seductive girl, beautiful face, cute eyes 出力された画像はこちら。 black and white cel shaded art cel shaded artは、black and whiteのキーワードを付けると、別の魅力が発揮されます。今回の記事では、black and whiteのありなしの2つのパターンを紹介します。 今回のPrompt（呪文）はこちら。 black and white cel shaded art of a seductive girl, beautiful face, cute eyes 出力された画像はこちら。 今回は、最初から、クオリティが高いですね。さすが、seductive（魅惑的）。 artstation, deviantart , concept art, digital painting, award-winning これまでの入門シリーズをやってきた方なら、次に追加する呪文は、わかっていますね。そうです。作風の呪文です。 日本人以外を描画する場合は、artstation, deviantart を指定します。日本人を描画する場合は、pixiv, light novelを指定します。 concept art, digital painting, award-winningは、お決まりの呪文なので、セットで覚えてしまいましょう。この呪文により、クオリティが多少上がります。 今回のPrompt（呪文）はこちら。 cel shaded art of a seductive girl, beautiful face, cute eyes, artstation, deviantart, concept art, digital painting, award-winning 出力された画像はこちら。 白黒バージョンはこちら。 seductive beautiful girl, upper shot, seductive posing, beautiful costume, fantasy background, beautiful composition, cinematic lighting, cinematic postprocessing いよいよ仕上げです。クオリティの高い人物画像を出力するには、服装（costume）、背景（background）、構図（composition）、ライティング（lighting）をしっかり指定することが重要です。 cinematic postprocessingは、出力される画像を映画の1シーンのようにかっこよくしてくれます。 upper shot, seductive posingで、魅力的なポーズの上半身を撮します。posingがあったほうが、より画像が生き生きします。 seductiveとposingが一緒に組み合わされると、あまりにも頻繁にNSFW（職場での閲覧は危険）が起きるので、seductive girlをseductive beautiful girlに変更しました。 今回のPrompt（呪文）はこちら。 cel shaded art of a seductive beautiful girl, beautiful face, cute eyes, upper shot, seductive posing, artstation, deviantart, concept art, digital painting, award-winning, beautiful costume, fantasy background, beautiful composition, cinematic lighting, cinematic postprocessing 出力された画像はこちら。 白黒バージョンはこちら。 princess posing seductive（魅惑的な） posingの他におすすめなのが、princess（王女） posingです。 今回のPrompt（呪文）はこちら。 cel shaded art of a seductive beautiful girl, beautiful face, cute eyes, upper shot, princess posing, artstation, deviantart, concept art, digital painting, award-winning, beautiful costume, fantasy background, beautiful composition, cinematic lighting, cinematic postprocessing 出力された画像はこちら。 白黒バージョンはこちら。 まとめ 今回は、魅惑的な女アニメ画（トゥーン レンダリング ）を扱いました。seductive（魅惑的な）の呪文は、NSFW（職場での閲覧は危険）が出やすい難しい呪文ですが、beautifulと組み合わせることで、扱いやすくなることを説明しました。 posingも画像を生き生きさせる効果があります。 次回は、 美少女を高確率で出す呪文編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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シリーズ、今回は、魅惑的な女アニメ画（トゥーン レンダリング ）の呪文です。 アニメ画と言っても 美少女アニメ画編 でとりあげたような、animeキーワードを用いるものではなく、トゥーン レンダリング を使ったアニメ画になります。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 トゥーンレンダリング cel shaded art of a seductive girl, beautiful face, cute eyes black and white cel shaded art artstation, deviantart, concept art, digital painting, award-winning seductive beautiful girl, upper shot, seductive posing, beautiful costume, fantasy background, beautiful composition, cinematic lighting, cinematic postprocessing princess posing まとめ 仲間募集 Stable Diffusionの過去コンテンツ トゥーン レンダリング トゥーン レンダリング とは、コンピュータグラフィックスにおいて3Dモデルを手描きアニメーション、あるいは漫画やイラスト風の作画（アニメ絵）で レンダリング する手法のことです。 wikipedia トゥーンレンダリング ゼルダの伝説 ブレス オブ ザ ワイルド のTrailerを見ると、どういうものかわかるでしょう。 Stable Diffusionでは、画像タイプとして、cel shaded artを使います。 cel shaded art of a seductive girl, beautiful face, cute eyes seductive（魅惑的な）が、今回の記事の最も重要なキーワードです。seductiveをつけた サブジ ェクト（描画対象）は文字通り魅惑的になりますが、NSFW（職場での閲覧は危険）になりやすいという欠点も持っています。 人物を描画する場合、faceとeyesのキワードは必ず入れておきましょう。 今回のPrompt（呪文）はこちら。 cel shaded art of a seductive girl, beautiful face, cute eyes 出力された画像はこちら。 black and white cel shaded art cel shaded artは、black and whiteのキーワードを付けると、別の魅力が発揮されます。今回の記事では、black and whiteのありなしの2つのパターンを紹介します。 今回のPrompt（呪文）はこちら。 black and white cel shaded art of a seductive girl, beautiful face, cute eyes 出力された画像はこちら。 今回は、最初から、クオリティが高いですね。さすが、seductive（魅惑的）。 artstation, deviantart , concept art, digital painting, award-winning これまでの入門シリーズをやってきた方なら、次に追加する呪文は、わかっていますね。そうです。作風の呪文です。 日本人以外を描画する場合は、artstation, deviantart を指定します。日本人を描画する場合は、pixiv, light novelを指定します。 concept art, digital painting, award-winningは、お決まりの呪文なので、セットで覚えてしまいましょう。この呪文により、クオリティが多少上がります。 今回のPrompt（呪文）はこちら。 cel shaded art of a seductive girl, beautiful face, cute eyes, artstation, deviantart, concept art, digital painting, award-winning 出力された画像はこちら。 白黒バージョンはこちら。 seductive beautiful girl, upper shot, seductive posing, beautiful costume, fantasy background, beautiful composition, cinematic lighting, cinematic postprocessing いよいよ仕上げです。クオリティの高い人物画像を出力するには、服装（costume）、背景（background）、構図（composition）、ライティング（lighting）をしっかり指定することが重要です。 cinematic postprocessingは、出力される画像を映画の1シーンのようにかっこよくしてくれます。 upper shot, seductive posingで、魅力的なポーズの上半身を撮します。posingがあったほうが、より画像が生き生きします。 seductiveとposingが一緒に組み合わされると、あまりにも頻繁にNSFW（職場での閲覧は危険）が起きるので、seductive girlをseductive beautiful girlに変更しました。 今回のPrompt（呪文）はこちら。 cel shaded art of a seductive beautiful girl, beautiful face, cute eyes, upper shot, seductive posing, artstation, deviantart, concept art, digital painting, award-winning, beautiful costume, fantasy background, beautiful composition, cinematic lighting, cinematic postprocessing 出力された画像はこちら。 白黒バージョンはこちら。 princess posing seductive（魅惑的な） posingの他におすすめなのが、princess（王女） posingです。 今回のPrompt（呪文）はこちら。 cel shaded art of a seductive beautiful girl, beautiful face, cute eyes, upper shot, princess posing, artstation, deviantart, concept art, digital painting, award-winning, beautiful costume, fantasy background, beautiful composition, cinematic lighting, cinematic postprocessing 出力された画像はこちら。 白黒バージョンはこちら。 まとめ 今回は、魅惑的な女アニメ画（トゥーン レンダリング ）を扱いました。seductive（魅惑的な）の呪文は、NSFW（職場での閲覧は危険）が出やすい難しい呪文ですが、beautifulと組み合わせることで、扱いやすくなることを説明しました。 posingも画像を生き生きさせる効果があります。 次回は、 美少女を高確率で出す呪文編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 X（クロス） イノベーション 本部 の三浦です。 筆者の関わってる案件では、セキュリ ティー の強化の一環として、 AWS session manager利用を推進しております。 session managerを利用するとEC2アクセス時に下記のようなメリットがあります（※1）。 ssh ,rdp接続のためのpublic ipを付与する必要がなくなる プライベートなサブネットのec2にも、踏み台等を経由せずにアクセス可能 ssh ,rdp接続のためのSGインバウンド許可IP制御が不要となる 認証情報を AWS の権限に集約でき、window、 linux のユーザー管理を減らせる 接続ログ、監査ログを、session mangerで一元管理できる しかし、そこで問題になってくるのがセキュリ ティー 強化のためにsession manger用のアクセスキー、シークレットキーを 配布すると今度はその管理が煩雑となり、セキュリ ティー リスクとなる課題があります。 そこで、 AWS Tools for Windows PowerShell からIdP（adfs）接続用のコマンドレット（Set-AWSSamlRoleProfile）を使い（※2）アクセスキー、シークレットキーの配布なしにsession mangerを利用する方法を記述します。 が、現在の仕様では、 PowerShell からsession managerの開始の API を単純に呼び出しても動作しません(※3)。 しかし、一工夫することにより、アクセスキー、シークレットキーなしでセキュアにsession mangerの利用が可能となります 実装の概要 AWS Tools for Windows PowerShell で、IdP（ADFS）より AWS のアクセス権取得 STS トーク ンを取り、 AWS CLI が使える形式で保存 AWS CLI からsession manger実行 これだけとなります。adfsへのアクセスのところのみ PowerShell をもちい、 AWS CLI でsession mangerを呼び出すだけとなります。 ソースコード 例 Import-Module -Name AWS.Tools.Common Import-Module -Name AWS.Tools.SecurityToken function start-ssm { [CmdletBinding()] Param ( [string] $awsAccountId = $null , [string] $adfsRoleName = "ADFS-RoleName" , [string] $ec2InstanceId = $null , [string] $localPortNumber = "13389" ) $profileName = $awsAccountId + ":role/" + $adfsRoleName $roleArn = "arn:aws:iam::" + $awsAccountId + ":role/" + $adfsRoleName ### XXXXXXXXXXXの部分は適宜、お使いのADFSのドメインに置き換えてください。筆者はadfs v3で動作確認をしております $endpoint = "https://XXXXXXXXXXX/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=urn:amazon:webservices" $epName = Set-AWSSamlEndpoint -Endpoint $endpoint -StoreAs ADFS-Demo -AuthenticationType NTLM $r = Set-AWSSamlRoleProfile -EndpointName $epName -StoreAllRoles $Creds = ( Use-STSRole -Region ap-northeast-1 -ProfileName $profileName -RoleArn $roleArn -RoleSessionName $adfsRoleName ).Credentials ### 動作をわかりやすくするために、下記三行でSTSの内容をコンソール出力しています $Creds .AccessKeyId $Creds .SecretAccessKey $Creds .SessionToken aws configure set region ap-northeast-1 --profile adfstemp aws configure set aws_access_key_id $Creds .AccessKeyId --profile adfstemp aws configure set aws_secret_access_key $Creds .SecretAccessKey --profile adfstemp aws configure set aws_session_token $Creds .SessionToken --profile adfstemp ## 下記はRDPのポートフォワーディング用の例となります $ssmParam = "portNumber=3389, localPortNumber=" + $localPortNumber aws ssm start-session --target $ec2InstanceId -- document-name AWS-StartPortForwardingSession --parameters $ssmParam --profile adfstemp } Set-AWSSamlEndpoint、 Set-AWSSamlRoleProfileを用いて、IdP（ADFS）より AWS のアクセス権取得 Use-STSRoleを用いて AWS CLI 用の認証情報を取得し、 aws configureで保存 AWS CLI の aws ssm start-sessionで、session mangerを開始 としてしてるだけの、非常にシンプルなコードとなります。 最後に ということで、今回は、アクセスキー、シークレットキーを発行せずに、session mangerを利用する例をご紹介いたしました。筆者は、200アカウントぐらいの管理をしており、これを個別のiam userのアクセスキー、シークレットキーで管理しようとすると非常につらいものがあります。 そのため、認証情報を、IdPサーバーに寄せた運用をしております。 アクセスキー管理に悩まれてる方は、ぜひ、一度、IdPサーバから STS を取得する運用を試されてはいかがでしょうか？ (※1) session mangerの概要、様々な使い方については、クラスメソッド様のブログに 多数記事 がございますので、session mangerってなんだっけ？という方は、そちらを見ていただくのがおすすめです。 (※2) AWS Tools for Windows PowerShell を用いると、標準ツールのみで 非常に簡単にadfsから認証情報の取得が可能 です。 (※3) 「 PowerShell からsession managerの開始ができない件」については、クラスメソッドさんが詳細を書かれていますので、詳細が気になる方はこちらをご参照ください。 PowerShellでSSMのポートフォワーディングを試してみた（けど駄目だったはなし） 執筆： @miura.toshihiko 、レビュー： @sato.taichi （ Shodo で執筆されました ）

初めに ISID X（クロス） イノベーション 本部 の三浦です。 筆者の関わってる案件では、セキュリ ティー の強化の一環として、 AWS session manager利用を推進しております。 session managerを利用するとEC2アクセス時に下記のようなメリットがあります（※1）。 ssh ,rdp接続のためのpublic ipを付与する必要がなくなる プライベートなサブネットのec2にも、踏み台等を経由せずにアクセス可能 ssh ,rdp接続のためのSGインバウンド許可IP制御が不要となる 認証情報を AWS の権限に集約でき、window、 linux のユーザー管理を減らせる 接続ログ、監査ログを、session mangerで一元管理できる しかし、そこで問題になってくるのがセキュリ ティー 強化のためにsession manger用のアクセスキー、シークレットキーを 配布すると今度はその管理が煩雑となり、セキュリ ティー リスクとなる課題があります。 そこで、 AWS Tools for Windows PowerShell からIdP（adfs）接続用のコマンドレット（Set-AWSSamlRoleProfile）を使い（※2）アクセスキー、シークレットキーの配布なしにsession mangerを利用する方法を記述します。 が、現在の仕様では、 PowerShell からsession managerの開始の API を単純に呼び出しても動作しません(※3)。 しかし、一工夫することにより、アクセスキー、シークレットキーなしでセキュアにsession mangerの利用が可能となります 実装の概要 AWS Tools for Windows PowerShell で、IdP（ADFS）より AWS のアクセス権取得 STS トーク ンを取り、 AWS CLI が使える形式で保存 AWS CLI からsession manger実行 これだけとなります。adfsへのアクセスのところのみ PowerShell をもちい、 AWS CLI でsession mangerを呼び出すだけとなります。 ソースコード 例 Import-Module -Name AWS.Tools.Common Import-Module -Name AWS.Tools.SecurityToken function start-ssm { [CmdletBinding()] Param ( [string] $awsAccountId = $null , [string] $adfsRoleName = "ADFS-RoleName" , [string] $ec2InstanceId = $null , [string] $localPortNumber = "13389" ) $profileName = $awsAccountId + ":role/" + $adfsRoleName $roleArn = "arn:aws:iam::" + $awsAccountId + ":role/" + $adfsRoleName ### XXXXXXXXXXXの部分は適宜、お使いのADFSのドメインに置き換えてください。筆者はadfs v3で動作確認をしております $endpoint = "https://XXXXXXXXXXX/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=urn:amazon:webservices" $epName = Set-AWSSamlEndpoint -Endpoint $endpoint -StoreAs ADFS-Demo -AuthenticationType NTLM $r = Set-AWSSamlRoleProfile -EndpointName $epName -StoreAllRoles $Creds = ( Use-STSRole -Region ap-northeast-1 -ProfileName $profileName -RoleArn $roleArn -RoleSessionName $adfsRoleName ).Credentials ### 動作をわかりやすくするために、下記三行でSTSの内容をコンソール出力しています $Creds .AccessKeyId $Creds .SecretAccessKey $Creds .SessionToken aws configure set region ap-northeast-1 --profile adfstemp aws configure set aws_access_key_id $Creds .AccessKeyId --profile adfstemp aws configure set aws_secret_access_key $Creds .SecretAccessKey --profile adfstemp aws configure set aws_session_token $Creds .SessionToken --profile adfstemp ## 下記はRDPのポートフォワーディング用の例となります $ssmParam = "portNumber=3389, localPortNumber=" + $localPortNumber aws ssm start-session --target $ec2InstanceId -- document-name AWS-StartPortForwardingSession --parameters $ssmParam --profile adfstemp } Set-AWSSamlEndpoint、 Set-AWSSamlRoleProfileを用いて、IdP（ADFS）より AWS のアクセス権取得 Use-STSRoleを用いて AWS CLI 用の認証情報を取得し、 aws configureで保存 AWS CLI の aws ssm start-sessionで、session mangerを開始 としてしてるだけの、非常にシンプルなコードとなります。 最後に ということで、今回は、アクセスキー、シークレットキーを発行せずに、session mangerを利用する例をご紹介いたしました。筆者は、200アカウントぐらいの管理をしており、これを個別のiam userのアクセスキー、シークレットキーで管理しようとすると非常につらいものがあります。 そのため、認証情報を、IdPサーバーに寄せた運用をしております。 アクセスキー管理に悩まれてる方は、ぜひ、一度、IdPサーバから STS を取得する運用を試されてはいかがでしょうか？ (※1) session mangerの概要、様々な使い方については、クラスメソッド様のブログに 多数記事 がございますので、session mangerってなんだっけ？という方は、そちらを見ていただくのがおすすめです。 (※2) AWS Tools for Windows PowerShell を用いると、標準ツールのみで 非常に簡単にadfsから認証情報の取得が可能 です。 (※3) 「 PowerShell からsession managerの開始ができない件」については、クラスメソッドさんが詳細を書かれていますので、詳細が気になる方はこちらをご参照ください。 PowerShellでSSMのポートフォワーディングを試してみた（けど駄目だったはなし） 執筆： @miura.toshihiko 、レビュー： @sato.taichi （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 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 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 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 で執筆されました ）