電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、美少女を高確率で出す呪文です。 Stable Diffusionで人物を出力するときに、顔が崩れている、目が変、口がない、腕（手）が変などを経験した方は多いことでしょう。NSFW（職場や学校で閲覧注意）が連続で出て、心が折れそうになった方もいることでしょう。僕もそのうちの一人です。 今回は、クオリティの高い人物画を高確率で出力し、NSFWもほとんど起きない呪文を研究しました。 v2.1 美少女アニメ画 もよろしければご覧ください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 illustration of a beautiful girl detailed beautiful face, detailed hair, detailed human eyes, detailed mouth, detailed arms, detailed bust artstation, deviantart, concept art, digital painting, award-winning looking far away, shot diagonally cinematic postprocessing, cinematic scene, cinematic composition, cinematic lighting, overexpose ray tracing, 8k まとめ 仲間募集 Stable Diffusionの過去コンテンツ illustration of a beautiful girl 今回もシンプルな呪文から始めましょう。徐々に呪文を足していき、その効果を確認することが呪文を学ぶには効果的です。 今回の呪文 illustration of a beautiful girl Dream Studio などの実行環境のある方は、10回ほど試してください。クオリティがバラバラなのが確認できるでしょう。今回の呪文はシンプルすぎて、出力が安定しないのです。 出力結果 detailed beautiful face, detailed hair, detailed human eyes, detailed mouth, detailed arms, detailed bust 今回の研究結果で最も重要なのが、これらの呪文。人物の出力を安定させるには、detailedで、体のパーツを指定します。 armsを指定することで、腕が変になることがだいぶ減りました。 detailedを指定すると、Stable Diffusionは指定された部分をクローズアップしようとします。今回は、顔のパーツを多く指定しているため、必然的に顔がクローズアップされます。顔がクローズアップされた画像は、バリエーションが出しにくいため、単調なものになりがちです。それを少しでも緩和するために、bust（胸）を指定しています。 detailed waist（腰）も指定してみましたが、あまり効果がないのと、NSFWが起きる確率が増えるため、呪文にいれませんでした。 detailed legs（脚）も指定してみましたが、NSFWが頻繁に起きるので、呪文にいれませんでした。 detailed body（体）も指定してみましたが、効果が感じられなかったので、呪文にいれませんでした。 detailed skin（肌）も指定してみましたが、ときどきノイズがのるので、呪文にいれませんでした。 detailed eyelashes（まつげ）も指定してみましたが、ときどきノイズがのる（目の下にもまつげが出たりする）ので、呪文にいれませんでした。 detailed eyebrows（眉毛）も指定してみましたが、不自然に強調されているように感じることがあったので、呪文にいれませんでした。 今回の呪文（横長、コピー&ペースト用） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed human eyes, detailed mouth, detailed arms, detailed bust 閲覧用呪文（改行版） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed human eyes, detailed mouth, detailed arms, detailed bust Dream Studio などの実行環境のある方は、10回ほど試してください。変な画像が出力されることはなくなったと思います。ただし、クオリティは安定してませんね。 出力結果 artstation, deviantart , concept art, digital painting, award-winning クオリティを安定させるためには、作風を指定することが重要です。イラストの投稿サイトとして、artstation, deviantart を指定します。concept art, digital painting, award-winningは、お決まりの呪文です。 今回の呪文（横長、コピー&ペースト用） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed human eyes, detailed mouth, detailed arms, detailed bust, artstation, deviantart, concept art, digital painting, award-winning 閲覧用呪文（改行版） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed human eyes, detailed mouth, detailed arms, detailed bust, artstation, deviantart, concept art, digital painting, award-winning Dream Studio などの実行環境のある方は、10回ほど試してください。クオリティも安定してきましたね。 出力結果 looking far away, shot diagonally すでに人物画のクオリティは、かなり上がっていますが、正面を見ている構図が多く、単調になりがちです。目線を正面から外してみましょう。looking far away（遠くを見る）を指定します。 shot diagonally（斜めから撮る）で、撮影の角度に変化をつけましょう。 今回の呪文（横長、コピー&ペースト用） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed human eyes, detailed mouth, detailed arms, detailed bust, looking far away, shot diagonally, artstation, deviantart, concept art, digital painting, award-winning 閲覧用呪文（改行版） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed human eyes, detailed mouth, detailed arms, detailed bust, looking far away, shot diagonally, artstation, deviantart, concept art, digital painting, award-winning 出力結果 だいぶ雰囲気が出てきたのではないでしょうか。 cinematic postprocessing, cinematic scene, cinematic composition, cinematic lighting, overexpose 画像のクオリティを上げるには、シーン（scene）、構図（composition）、ライティング（lighting）を指定することが重要です。魔法の呪文、cinematicをつけておきましょう。 cinematic postprocessing, overexposeでさらにクオリティを向上させます。 今回の呪文（横長、コピー&ペースト用） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed beautiful eyes, detailed mouth, detailed arms, detailed bust, looking far away, shot diagonally, artstation, deviantart, concept art, digital painting, award-winning, cinematic postprocessing, cinematic scene, cinematic composition, cinematic lighting, overexpose 閲覧用呪文（改行版） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed beautiful eyes, detailed mouth, detailed arms, detailed bust, looking far away, shot diagonally, artstation, deviantart, concept art, digital painting, award-winning, cinematic postprocessing, cinematic scene, cinematic composition, cinematic lighting, overexpose 出力結果 キラキラして映画の1シーンのようですね。 ただし、この呪文から、再現度は低くなります。いつも映画のような1シーンになるわけではないということです。 ray tracing, 8k 先程の呪文で完成にしてもよいのですが、もう少し、フォトリアルにしたい場合は、ray tracing, 8kの呪文を追加します。 今回の呪文（横長、コピー&ペースト用） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed human eyes, detailed mouth, detailed arms, detailed bust, looking far away, shot diagonally, artstation, deviantart, concept art, digital painting, award-winning, cinematic postprocessing, cinematic scene, cinematic composition, cinematic lighting, overexpose, ray tracing, 8k 閲覧用呪文（改行版） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed human eyes, detailed mouth, detailed arms, detailed bust, looking far away, shot diagonally, artstation, deviantart, concept art, digital painting, award-winning, cinematic postprocessing, cinematic scene, cinematic composition, cinematic lighting, overexpose, ray tracing, 8k 出力結果 まとめ 今回は、クオリティの高い人物画を高確率で出力する方法を紹介しました。 顔がクローズアップされ、正面を向いている画像は、ありきたりな感じになるリスクがあります。変化をつける呪文を学びましょう。 次回は、 長い呪文は切り捨てられる編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの過去コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

論文読み会の紹介 こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、X イノベーション 本部の有志(現在はソフトウェアデザインセンターとINNOLABが中心)で実施している論文読み会について紹介しようと思います。 毎月1回、担当を決めて担当の方が読みたい論文を選んで、それをスライドなどに内容をまとめて紹介するスタイルで実施しています。 当日みんなで集まって論文を読み進める形式ではないです。 ISIDはいわゆる SIer と呼ばれる業態の会社ですが、読む論文は特に情報関係の論文に限っていません。 ソフトウェア工学 の論文やDNAストレージの論文など色々な論文を選んで輪読しています。 論文輪読会の目的とメリット 論文読み会は、自分が入社した時(2021年10月)に部内で論文を一緒に読むような仲間が欲しくて回りに声を掛けて始めた活動です。 最初は自分のチーム内くらいの規模からやるかと思っていたところ、せっかくなので他の部門ともやろうということになりINNOLABの方と共同でやろうということになって始まりました。 自分は論文を読むことはいくつかメリットがあると思っていて、まず論文自体に書いてある技術の知識が身につくということがあります。それ以外にも、メリットがあると考えているので簡単に紹介します。 自分の興味がある分野が分かってくる 多様な分野の論文を探す経験や関連する分野を見ていると自分が興味がある分野が分かってきたりします。 技術調査を行なう経験が積める 論文を読むためにはその技術に関する周辺の知識やその技術が生まれた経緯なども含めて色々調査が必要となったりします。これは流行っている技術を勉強する場合には必ずしも必要がない行為です。例えば、特定のWebの技術(Reactなど)を知りたい場合はその技術について解説した書籍があったり、 google で検索すると解説してくれている記事などもたくさん公開されています。しかし、論文に載っている内容は、まだ世間に広まっていない技術であったりすることも少なくないです。こういった調査になれていることで、流行しはじめたばかりの技術や特定領域でのみ利用されている技術の調査する場合に経験が活かせたりします。 人に技術を紹介する経験 自分の興味に基づいて技術を紹介する機会というのは意外と少ないものです。 業務上で技術を選ぶ場合は実用性などの観点で技術選定を行なうことがほとんどでしょう。 そんな自分が気になる技術を人に紹介するので面白く紹介しようと思って色々工夫したくなるのでプレゼンの練習にもなります。 新たな技術分野を知れる ここまでは、論文を紹介する側のメリットが並んでいますが、これは聞く側のメリットです。 今回実施している論文輪読会は読む論文の対象分野を絞っていません。ですので、今まで興味を持っていなかった分野に触れることが出来、見聞が広まる機会に繋っています。 現在開催している範囲でも以下のような多様な分野の論文が紹介されました。 ソフトウェア工学 DNAストレージ 深層学習 Human Computer Interaction関連 人間科学 本当に多様な論文を紹介して貰えて毎回楽しみです。 論文輪読会の実施に掛かる費用 論文といえば学会から購読するのが一般的です。しかし、論文は無料で読めるものが最近だと多いです。 arxiv ( https://arxiv.org/ )などが有名ですね。 とはいえ、有名な学会などの査読付きの論文などはやはり有償のものとなっているものが多いです。 情報系であれば、 ACM や IEEE の学会の論文を読める環境の方が良いと思います。 大人数で論文を読むのであれば、企業として契約することを検討した方が良いのですが 今回は少人数ということだったので、希望者が個別に ACM などを購読する形で実施しています。 自分は会社が論文購読の費用( ACM で$198/year)を負担してくれるので大変助かりました。 開催しているときの雰囲気など これまでに、2022年の3月から毎月開催していて5回実施しています。 概ね好評だと考えています(特にアンケートなどを取っていないので雰囲気です)。 毎回、新しい分野の新しい論文を発表者の方が選んでくれていて大変面白い会合となっています。 聞いている参加者の方も様々な観点で質問を出してくれて、色々刺激になっているのではと思っております。 まとめ 今回はX イノベーション 本部で実施している論文読み会について紹介しました。是非皆さんの会社などでも実施してみてはいかがでしょうか？最近は論文を読む敷居もDeepLや Google翻訳 といった翻訳ツールもあってとても手軽に読めるようになりました。いい時代になりましたね。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @sato.taichi （ Shodo で執筆されました ）

論文読み会の紹介 こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、X イノベーション 本部の有志(現在はソフトウェアデザインセンターとINNOLABが中心)で実施している論文読み会について紹介しようと思います。 毎月1回、担当を決めて担当の方が読みたい論文を選んで、それをスライドなどに内容をまとめて紹介するスタイルで実施しています。 当日みんなで集まって論文を読み進める形式ではないです。 ISIDはいわゆる SIer と呼ばれる業態の会社ですが、読む論文は特に情報関係の論文に限っていません。 ソフトウェア工学 の論文やDNAストレージの論文など色々な論文を選んで輪読しています。 論文輪読会の目的とメリット 論文読み会は、自分が入社した時(2021年10月)に部内で論文を一緒に読むような仲間が欲しくて回りに声を掛けて始めた活動です。 最初は自分のチーム内くらいの規模からやるかと思っていたところ、せっかくなので他の部門ともやろうということになりINNOLABの方と共同でやろうということになって始まりました。 自分は論文を読むことはいくつかメリットがあると思っていて、まず論文自体に書いてある技術の知識が身につくということがあります。それ以外にも、メリットがあると考えているので簡単に紹介します。 自分の興味がある分野が分かってくる 多様な分野の論文を探す経験や関連する分野を見ていると自分が興味がある分野が分かってきたりします。 技術調査を行なう経験が積める 論文を読むためにはその技術に関する周辺の知識やその技術が生まれた経緯なども含めて色々調査が必要となったりします。これは流行っている技術を勉強する場合には必ずしも必要がない行為です。例えば、特定のWebの技術(Reactなど)を知りたい場合はその技術について解説した書籍があったり、 google で検索すると解説してくれている記事などもたくさん公開されています。しかし、論文に載っている内容は、まだ世間に広まっていない技術であったりすることも少なくないです。こういった調査になれていることで、流行しはじめたばかりの技術や特定領域でのみ利用されている技術の調査する場合に経験が活かせたりします。 人に技術を紹介する経験 自分の興味に基づいて技術を紹介する機会というのは意外と少ないものです。 業務上で技術を選ぶ場合は実用性などの観点で技術選定を行なうことがほとんどでしょう。 そんな自分が気になる技術を人に紹介するので面白く紹介しようと思って色々工夫したくなるのでプレゼンの練習にもなります。 新たな技術分野を知れる ここまでは、論文を紹介する側のメリットが並んでいますが、これは聞く側のメリットです。 今回実施している論文輪読会は読む論文の対象分野を絞っていません。ですので、今まで興味を持っていなかった分野に触れることが出来、見聞が広まる機会に繋っています。 現在開催している範囲でも以下のような多様な分野の論文が紹介されました。 ソフトウェア工学 DNAストレージ 深層学習 Human Computer Interaction関連 人間科学 本当に多様な論文を紹介して貰えて毎回楽しみです。 論文輪読会の実施に掛かる費用 論文といえば学会から購読するのが一般的です。しかし、論文は無料で読めるものが最近だと多いです。 arxiv ( https://arxiv.org/ )などが有名ですね。 とはいえ、有名な学会などの査読付きの論文などはやはり有償のものとなっているものが多いです。 情報系であれば、 ACM や IEEE の学会の論文を読める環境の方が良いと思います。 大人数で論文を読むのであれば、企業として契約することを検討した方が良いのですが 今回は少人数ということだったので、希望者が個別に ACM などを購読する形で実施しています。 自分は会社が論文購読の費用( ACM で$198/year)を負担してくれるので大変助かりました。 開催しているときの雰囲気など これまでに、2022年の3月から毎月開催していて5回実施しています。 概ね好評だと考えています(特にアンケートなどを取っていないので雰囲気です)。 毎回、新しい分野の新しい論文を発表者の方が選んでくれていて大変面白い会合となっています。 聞いている参加者の方も様々な観点で質問を出してくれて、色々刺激になっているのではと思っております。 まとめ 今回はX イノベーション 本部で実施している論文読み会について紹介しました。是非皆さんの会社などでも実施してみてはいかがでしょうか？最近は論文を読む敷居もDeepLや Google翻訳 といった翻訳ツールもあってとても手軽に読めるようになりました。いい時代になりましたね。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @sato.taichi （ Shodo で執筆されました ）

こんにちは。ISID CIT事業部の熊倉です。 本記事では、 Salesforce の Summer'21アップデートで正式リリース となったExperience Cloudの新しいテンプレート 『Build Your Own (LWR) テンプレート』 について紹介したいと思います。 Experience Cloud は Salesforce が提供しているWebサイトを構築できるサービスで、カスタマーサイトやFAQサイトといった Salesforce の他サービス（主にService Cloudですね）と親和性の高いサイトを構築できます。 特長として、ポイントアンドクリックで必要な設定を完結できるテンプレートがあらかじめ多数提供されていることが挙げられます。 1. Build Your Own (LWR) テンプレート 1.1 Lightning Web Runtime (LWR) の紹介 1.2 Build Your Own (LWR) テンプレートとは Auraサイト / LWRサイト という呼称について 1.3 Build Your Own (LWR) テンプレートのメリット、デメリット メリット デメリット 1.4 ユースケース ● Auraテンプレートのユースケースから逸れたサイト ● 高度なデザインを求められるWebサイト ● 不特定多数のユーザーが訪れるようなランディングページ 2. Build Your Own (LWR) テンプレートを使ってみた 2.1 SLDSデザインを削除する 1. ヘッダーを編集 2. LWCを作成 3. 確認 3. まとめ 1. Build Your Own (LWR) テンプレート Experience Cloudは簡単にWebサイトの構築ができる反面、カスタマイズ性の低さが弱点でした。 もし、カスタマーサイトやFAQサイトといった ユースケース 以外のサイトを構築しようとしたり、複雑なデザイン要件を叶えようとした場合、途端にハードルが上がってしまうことがありました。 そこで『Build Your Own (LWR) テンプレート』の登場です。 Build Your Own (LWR) テンプレートは従来のExperience Cloudのテンプレートと大きく思想が異なり、最小限のページや コンポーネント のみ提供され、サイトに必要なページや コンポーネント は自分達で開発する（Build Your Own）必要があります。 そのため、従来のテンプレートに比べ、 カスタマイズ性が非常に高いという特徴を持っています。 テンプレートの説明に入る前にBuild Your Own ( LWR ) テンプレートの LWR について、まず紹介をしたいと思います。 1.1 Lightning Web Runtime (LWR) の紹介 LWRとはLightning Web Runtimeの略で、 Salesforce が提供する新しいWebフレームワークです（ OSS 版は現在Developer Preview ） 特徴として以下の3つが掲げられています。 https://developer.salesforce.com/docs/platform/lwr/overview Performance Our bar is set at subsecond full page loads. Friction-Free Enjoyable local development experience. Power All the power of Lightning Web Components and the Salesforce platform at your disposal. 端的にまとめると 「高パフォーマンスなWebサイトを(※)Lightning Web Componentで開発できる デベロッパ ーフレンドリーな」 フレームワーク といったところです。 LWRはHerokuの インスタンス 等のNode.js 実行環境下で動作し、静的なコンテンツを配信したりSPAを構築できます。 ※ Lightning Web Component (LWC) とは Salesforce で コンポーネント を作成する際のプログラミングモデルです。LWCが登場する前はAuraというプログラミングモデルに則る必要がありました。 1.2 Build Your Own (LWR) テンプレートとは LWRを使用することで高パフォーマンスなWebサイトを構築できますが、Node.jsが動作するサーバの用意といったインフラの準備が必要です。 そこで、 Salesforce 環境で ホスティング されるExperience CloudでもLWRを利用できるようにしたのが『Build Your Own (LWR) テンプレート』となります。（他にも『マイ クロサイ ト（LWR）』というテンプレートも用意されています） Build Your Own (LWR) テンプレートを利用することで、上記の高パフォーマンスといったメリットを受けることができますが、反対に コンポーネント の開発方法がLWCに限定される（Aura はNG） という制約もついています。 Auraサイト / LWRサイト という呼称について ちなみに、LWRを使用したテンプレートが公開されたことにより、従来のテンプレートやそれを利用して公開されたサイトはAuraテンプレート、Auraサイトと呼ばれるようになりました。 https://help.salesforce.com/s/articleView?id=sf.exp_cloud_plan_frameworks.htm&type=5 Aura テンプレートには、 カスタマーサービス 、Partner Central、ヘルプセンター、Build Your Own、カスタマー取引先ポータルが含まれます。Aura テンプレートはほぼローコード (low-code) です。Lightning Web コンポーネント と Aura コンポーネント は 1 つのページで共存および相互運用できます。 https://help.salesforce.com/s/articleView?id=release-notes.rn_experiences.htm&type=5&release=234 LWR サイトは、Build Your Own (LWR) テンプレートなど、最新の LWR ベースのテンプレートを使用して構築されます。 Aura サイトは、 カスタマーサービス 、Partner Central、カスタマー取引先ポータルなど、Aura で実行されるオリジナルのテンプレートを使用して構築されます。 1.3 Build Your Own (LWR) テンプレートのメリット、デメリット Build Your Own (LWR) テンプレートのメリット、デメリットを以下に記載します。 メリット LWRを利用するため、高パフォーマンスの恩恵を受けられる ビルド時にあらかじめサイトのコンテンツが生成（SSG）されます 初回のリク エス ト時にHTTPキャッシュされ、2回目以降のリク エス トがさらに高速に動作します 認証が不要なサイトを構築する際、URLに「/s」を含ませないことが可能 Auraテンプレートで構築したWebサイトの場合、 ドメイン 下に『/s』が含まれてしまいますが（例： https://my-domain.my.site.com/s/ ）、Build Your Own (LWR) テンプレートを使用することで認証が不要のサイトの場合『/s』を含ませないことが可能になりました ちなみに現在（2022年8月）だと認証が必要なサイトの場合は『/s』が含まれてしまうのですが、 Winter'23のアップデートで認証が必要なサイトの場合でも『/s』が含まれなくなるようです URLが煩雑になるのを避け、サイトの ブランディング に良い影響を与えることができます headタグを（Auraテンプレートと比較して）自由に編集できる Auraテンプレートでは制限があったheadタグを（比較して）自由に編集できるようになりました 編集可能になったことにより、次のようなことが実現可能になりました Salesforce の スタイルシート を削除する（後述） サードパーティ のjsライブラリを利用する Google Analytics や Google Tag Managerを使用可能 Examples: Use Google Analytics in LWR Sites Examples: Use Google Tag Manager in LWR Sites デメリット ほとんどの画面で開発が必要 Auraテンプレートで使用できる コンポーネント （レコードの内容を表示するといった標準 コンポーネント ）が使用できません Build Your Ownの名の通り、 コンポーネント を自前で作成する必要があります 開発スキルとしてLWCが必須なため、LWCを学習するコストがかかる LWRを利用している関係上、LWCでのみ開発が可能で、Aura コンポーネント は利用不可となっています。 1.4 ユースケース 以下のような ユースケース を実現したい場合、LWR テンプレートの使用がマッチします。 ● Auraテンプレートの ユースケース から逸れたサイト カスタマー ポータルサイト やQAサイト、お問い合わせフォームといったWebサイトを構築する場合、従来のテンプレートを利用するのが便利かと思います。しかし、それ以外を目的としたサイトをExperience Cloudで構築したいとなった場合、カスタマイズ性の低さが開発のハードルになってしまうことがままあります。その場合、LWR テンプレートは選択肢になると思います。 ● 高度なデザインを求められるWebサイト 上記の内容とも被りますが、高度なデザインが求められる場合でもLWR テンプレートは選択肢になると思います。 カスタマイズ性が上がったことで、従来のテンプレートでは表現しきれないデザインの実現が可能になりました。 この後、具体的に記述しますが、 Salesforce でネイティブに利用されているデザインシステムであるSLDSを完全に削除することも可能です。代わりに有名な CSS フレームワーク を利用することもできますので、Web上にある CSS のノウハウをExperiece Cloudで構築したサイトで活用できるのもメリットと言えるかと思います。 ● 不特定多数のユーザーが訪れるようなランディングページ LWRの高いパフォーマンス性を活かして、不特定多数のユーザーが訪れるようなランディングページといったワンショットのサイト公開にも最適です。 Google Analytics や Google Tag Managerを利用し、利用者の分析を行うことも可能です。（この場合、 Build Your Own (LWR)テンプレートと同様にLWRを利用している マイクロサイト というテンプレート が最適な選択肢になるかと思います） 2. Build Your Own (LWR) テンプレートを使ってみた これまでBuild Your Own (LWR) テンプレートについて紹介してきましたが、これから実際にテンプレートを利用した開発について紹介していきたいと思います！ Build Your Own (LWR) テンプレートのユニークな機能（Auraテンプレートでは不可能な機能）は たくさん あるのですが、今回は「SLDSデザインを削除できる」機能をピックアップして紹介します。 LWR テンプレートの機能について詳しく知りたい方は以下のドキュメントを参考にしてください。 https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/intro.htm また、LWRについてのドキュメントや サンプルソース といったリソースがまとめられたページも用意されていますので1からキャッチアップしたい方は参考になるかと思います。 https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/intro_resources.htm （個人的には サンプルアプリケーションのデプロイ と YouTubeのコンテンツ がキャッチアップに大変有用だったのでオススメです！） 2.1 SLDSデザインを削除する それでは「ヘッダーからSLDSの削除」を試してみたいと思います。 SLDSとは Salesforce Design System の略で、 Salesforce が公開しているデザインシステムです。Aura テンプレートでは標準でロードされており削除が難しかったのですが、LWR テンプレートでは コメントアウト することで完全に削除できます。 SLDSを削除することで、 デザイン面について完全にコン トロール 下におくことができます。 今回は、SLDSを削除し、代わりに CSS フレームワーク の Bulma を利用するケースを検証していきたいと思います。 サンプルソース として、公式から提供されている次のソースをLWC化して取り込んでみたいと思います。 https://bulmatemplates.github.io/bulma-templates/templates/admin.html （ サンプルソース ではBulmaの他に「Font Awesome 」「 Google Fonts」を利用していましたので以下検証でもロードしたいと思います） 1. ヘッダーを編集 Experience Cloudのビルダーページから　設定 ＞ 詳細 ＞ ヘッドマーク アップを編集　でヘッダーを編集します。 デフォルトで用意されているヘッダーは次の画像のようになっています。（LWRテンプレートはAuraテンプレートに比べて編集可能な箇所が多いです） 次のタグがSLDSのロード箇所になりますので、 コメントアウト します https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_remove.htm < link rel = "stylesheet" href = "{ basePath }/assets/styles/salesforce-lightning-design-system.min.css?{ versionKey }" /> ちなみに < link rel = "stylesheet" href = "{ basePath }/assets/styles/dxp-site-spacing-styling-hooks.min.css?{ versionKey }" /> < link rel = "stylesheet" href = "{ basePath }/assets/styles/dxp-styling-hooks.min.css?{ versionKey }" /> < link rel = "stylesheet" href = "{ basePath }/assets/styles/dxp-slds-extensions.min.css?{ versionKey }" /> の箇所は、--dxp Styling Hooksと呼ばれる機能を反映させるための CSS になります。 https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_start_using.htm --dxp Styling Hooksとは CSS カスタムプロパティを使用し、左サイドにあるテーマパネルからボタンやリンクといったHTML要素のデザインをページ全体で一括で編集できる仕組みになります。 Styling Hookは使用しない！という方は コメントアウト しても良いかと思います。（今回は一旦そのまま残しておきます） 続いて、以下 サンプルソース の <head> 内の記述から、 https://github.com/BulmaTemplates/bulma-templates/blob/master/templates/admin.html Bulma、Font Awesome 、 Google Fontsをロードするタグを追加します。 < link rel = "stylesheet" href = "https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" > < link rel = "stylesheet" href = "https://fonts.googleapis.com/css?family=Open+Sans:300,400,700" > < link rel = "stylesheet" href = "https://unpkg.com/bulma@0.9.0/css/bulma.min.css" /> （hrefのリンクについては Salesforce の「設定」 ＞「CSP 信頼済みサイト」 から登録を行います） ここまででヘッダーの記述は以下のようになっているかと思います 2. LWCを作成 ヘッダーでSLDSを削除し各ソースをロードできたので、続いてLWCを作成します。 まず、以下 サンプルソース から <body> 内の記述をそのままLWCのHTMLにコピーします。 https://github.com/BulmaTemplates/bulma-templates/blob/master/templates/admin.html 次に、以下 サンプルソース からLWCの CSS にコピーします。 https://github.com/BulmaTemplates/bulma-templates/blob/master/css/admin.css ただし、 html,body { } の箇所に関しては コンポーネント の範囲外となってしまうため、ヘッダー側に記述をしました。 3. 確認 さて、LWCがいよいよ完成したので、サイトを公開しコンテンツを確認してみたいと思います！ ■ Build Your Own (LWR) ページ ■ サンプルサイト（ https://bulmatemplates.github.io/bulma-templates/templates/admin.html ） いかがでしょうか？ SLDSが削除されていること、Bulmaが正常にロードされていることが確認できるかと思います。 また、カード内の文章に「 Google Fonts」、検索欄に「Font Awesome 」が利用されていますが、こちらも正常に描写されていることがわかるかと思います。 ちなみに「ページ上左右のスペース」や「ボタンやリンク」のデザインが異なるかと思いますが、こちらは前述の --dxp Styling Hook が影響しており、ヘッダーから コメントアウト すると以下のようなサイトになります。 （ ピクセル パーフェクト！） 3. まとめ ここまで読んでいただきありがとうございました。 本記事がBuid Your Own (LWR) テンプレートについて理解の一助になれば幸いです。 今回、機能の紹介では「SLDSの削除」について取り上げましたが、他にも「多言語対応」「特権 スクリプト を使用した サードパーティ 製JSライブラリの利用」「LWRテンプレートのみ利用できるExperience Builderの コンポーネント 」「Salesfroce CMS との連携」等々、LWR テンプレートのユニークな機能は たくさん あります。 是非、公式ドキュメントを読んでいただき、その他の機能についてもキャッチアップしていただけると幸いです。 本記事ではLWR テンプレート利用によるWebフロントエンドの効果について主に紹介しましたが、バックエンドが Salesforce で統合されていることも大きなメリットとなります。弊社ではLWR テンプレートを利用したWebサイト開発の実績もありますので、 デザイン性が高く、高速・安全なWebサイトを フル Salesforce で実現したい方は是非ご相談ください！ 執筆： @kumakura.koki.isid 、レビュー： @higa （ Shodo で執筆されました ）

こんにちは。ISID CIT事業部の熊倉です。 本記事では、 Salesforce の Summer'21アップデートで正式リリース となったExperience Cloudの新しいテンプレート 『Build Your Own (LWR) テンプレート』 について紹介したいと思います。 Experience Cloud は Salesforce が提供しているWebサイトを構築できるサービスで、カスタマーサイトやFAQサイトといった Salesforce の他サービス（主にService Cloudですね）と親和性の高いサイトを構築できます。 特長として、ポイントアンドクリックで必要な設定を完結できるテンプレートがあらかじめ多数提供されていることが挙げられます。 1. Build Your Own (LWR) テンプレート 1.1 Lightning Web Runtime (LWR) の紹介 1.2 Build Your Own (LWR) テンプレートとは Auraサイト / LWRサイト という呼称について 1.3 Build Your Own (LWR) テンプレートのメリット、デメリット メリット デメリット 1.4 ユースケース ● Auraテンプレートのユースケースから逸れたサイト ● 高度なデザインを求められるWebサイト ● 不特定多数のユーザーが訪れるようなランディングページ 2. Build Your Own (LWR) テンプレートを使ってみた 2.1 SLDSデザインを削除する 1. ヘッダーを編集 2. LWCを作成 3. 確認 3. まとめ 1. Build Your Own (LWR) テンプレート Experience Cloudは簡単にWebサイトの構築ができる反面、カスタマイズ性の低さが弱点でした。 もし、カスタマーサイトやFAQサイトといった ユースケース 以外のサイトを構築しようとしたり、複雑なデザイン要件を叶えようとした場合、途端にハードルが上がってしまうことがありました。 そこで『Build Your Own (LWR) テンプレート』の登場です。 Build Your Own (LWR) テンプレートは従来のExperience Cloudのテンプレートと大きく思想が異なり、最小限のページや コンポーネント のみ提供され、サイトに必要なページや コンポーネント は自分達で開発する（Build Your Own）必要があります。 そのため、従来のテンプレートに比べ、 カスタマイズ性が非常に高いという特徴を持っています。 テンプレートの説明に入る前にBuild Your Own ( LWR ) テンプレートの LWR について、まず紹介をしたいと思います。 1.1 Lightning Web Runtime (LWR) の紹介 LWRとはLightning Web Runtimeの略で、 Salesforce が提供する新しいWebフレームワークです（ OSS 版は現在Developer Preview ） 特徴として以下の3つが掲げられています。 https://developer.salesforce.com/docs/platform/lwr/overview Performance Our bar is set at subsecond full page loads. Friction-Free Enjoyable local development experience. Power All the power of Lightning Web Components and the Salesforce platform at your disposal. 端的にまとめると 「高パフォーマンスなWebサイトを(※)Lightning Web Componentで開発できる デベロッパ ーフレンドリーな」 フレームワーク といったところです。 LWRはHerokuの インスタンス 等のNode.js 実行環境下で動作し、静的なコンテンツを配信したりSPAを構築できます。 ※ Lightning Web Component (LWC) とは Salesforce で コンポーネント を作成する際のプログラミングモデルです。LWCが登場する前はAuraというプログラミングモデルに則る必要がありました。 1.2 Build Your Own (LWR) テンプレートとは LWRを使用することで高パフォーマンスなWebサイトを構築できますが、Node.jsが動作するサーバの用意といったインフラの準備が必要です。 そこで、 Salesforce 環境で ホスティング されるExperience CloudでもLWRを利用できるようにしたのが『Build Your Own (LWR) テンプレート』となります。（他にも『マイ クロサイ ト（LWR）』というテンプレートも用意されています） Build Your Own (LWR) テンプレートを利用することで、上記の高パフォーマンスといったメリットを受けることができますが、反対に コンポーネント の開発方法がLWCに限定される（Aura はNG） という制約もついています。 Auraサイト / LWRサイト という呼称について ちなみに、LWRを使用したテンプレートが公開されたことにより、従来のテンプレートやそれを利用して公開されたサイトはAuraテンプレート、Auraサイトと呼ばれるようになりました。 https://help.salesforce.com/s/articleView?id=sf.exp_cloud_plan_frameworks.htm&type=5 Aura テンプレートには、 カスタマーサービス 、Partner Central、ヘルプセンター、Build Your Own、カスタマー取引先ポータルが含まれます。Aura テンプレートはほぼローコード (low-code) です。Lightning Web コンポーネント と Aura コンポーネント は 1 つのページで共存および相互運用できます。 https://help.salesforce.com/s/articleView?id=release-notes.rn_experiences.htm&type=5&release=234 LWR サイトは、Build Your Own (LWR) テンプレートなど、最新の LWR ベースのテンプレートを使用して構築されます。 Aura サイトは、 カスタマーサービス 、Partner Central、カスタマー取引先ポータルなど、Aura で実行されるオリジナルのテンプレートを使用して構築されます。 1.3 Build Your Own (LWR) テンプレートのメリット、デメリット Build Your Own (LWR) テンプレートのメリット、デメリットを以下に記載します。 メリット LWRを利用するため、高パフォーマンスの恩恵を受けられる ビルド時にあらかじめサイトのコンテンツが生成（SSG）されます 初回のリク エス ト時にHTTPキャッシュされ、2回目以降のリク エス トがさらに高速に動作します 認証が不要なサイトを構築する際、URLに「/s」を含ませないことが可能 Auraテンプレートで構築したWebサイトの場合、 ドメイン 下に『/s』が含まれてしまいますが（例： https://my-domain.my.site.com/s/ ）、Build Your Own (LWR) テンプレートを使用することで認証が不要のサイトの場合『/s』を含ませないことが可能になりました ちなみに現在（2022年8月）だと認証が必要なサイトの場合は『/s』が含まれてしまうのですが、 Winter'23のアップデートで認証が必要なサイトの場合でも『/s』が含まれなくなるようです URLが煩雑になるのを避け、サイトの ブランディング に良い影響を与えることができます headタグを（Auraテンプレートと比較して）自由に編集できる Auraテンプレートでは制限があったheadタグを（比較して）自由に編集できるようになりました 編集可能になったことにより、次のようなことが実現可能になりました Salesforce の スタイルシート を削除する（後述） サードパーティ のjsライブラリを利用する Google Analytics や Google Tag Managerを使用可能 Examples: Use Google Analytics in LWR Sites Examples: Use Google Tag Manager in LWR Sites デメリット ほとんどの画面で開発が必要 Auraテンプレートで使用できる コンポーネント （レコードの内容を表示するといった標準 コンポーネント ）が使用できません Build Your Ownの名の通り、 コンポーネント を自前で作成する必要があります 開発スキルとしてLWCが必須なため、LWCを学習するコストがかかる LWRを利用している関係上、LWCでのみ開発が可能で、Aura コンポーネント は利用不可となっています。 1.4 ユースケース 以下のような ユースケース を実現したい場合、LWR テンプレートの使用がマッチします。 ● Auraテンプレートの ユースケース から逸れたサイト カスタマー ポータルサイト やQAサイト、お問い合わせフォームといったWebサイトを構築する場合、従来のテンプレートを利用するのが便利かと思います。しかし、それ以外を目的としたサイトをExperience Cloudで構築したいとなった場合、カスタマイズ性の低さが開発のハードルになってしまうことがままあります。その場合、LWR テンプレートは選択肢になると思います。 ● 高度なデザインを求められるWebサイト 上記の内容とも被りますが、高度なデザインが求められる場合でもLWR テンプレートは選択肢になると思います。 カスタマイズ性が上がったことで、従来のテンプレートでは表現しきれないデザインの実現が可能になりました。 この後、具体的に記述しますが、 Salesforce でネイティブに利用されているデザインシステムであるSLDSを完全に削除することも可能です。代わりに有名な CSS フレームワーク を利用することもできますので、Web上にある CSS のノウハウをExperiece Cloudで構築したサイトで活用できるのもメリットと言えるかと思います。 ● 不特定多数のユーザーが訪れるようなランディングページ LWRの高いパフォーマンス性を活かして、不特定多数のユーザーが訪れるようなランディングページといったワンショットのサイト公開にも最適です。 Google Analytics や Google Tag Managerを利用し、利用者の分析を行うことも可能です。（この場合、 Build Your Own (LWR)テンプレートと同様にLWRを利用している マイクロサイト というテンプレート が最適な選択肢になるかと思います） 2. Build Your Own (LWR) テンプレートを使ってみた これまでBuild Your Own (LWR) テンプレートについて紹介してきましたが、これから実際にテンプレートを利用した開発について紹介していきたいと思います！ Build Your Own (LWR) テンプレートのユニークな機能（Auraテンプレートでは不可能な機能）は たくさん あるのですが、今回は「SLDSデザインを削除できる」機能をピックアップして紹介します。 LWR テンプレートの機能について詳しく知りたい方は以下のドキュメントを参考にしてください。 https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/intro.htm また、LWRについてのドキュメントや サンプルソース といったリソースがまとめられたページも用意されていますので1からキャッチアップしたい方は参考になるかと思います。 https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/intro_resources.htm （個人的には サンプルアプリケーションのデプロイ と YouTubeのコンテンツ がキャッチアップに大変有用だったのでオススメです！） 2.1 SLDSデザインを削除する それでは「ヘッダーからSLDSの削除」を試してみたいと思います。 SLDSとは Salesforce Design System の略で、 Salesforce が公開しているデザインシステムです。Aura テンプレートでは標準でロードされており削除が難しかったのですが、LWR テンプレートでは コメントアウト することで完全に削除できます。 SLDSを削除することで、 デザイン面について完全にコン トロール 下におくことができます。 今回は、SLDSを削除し、代わりに CSS フレームワーク の Bulma を利用するケースを検証していきたいと思います。 サンプルソース として、公式から提供されている次のソースをLWC化して取り込んでみたいと思います。 https://bulmatemplates.github.io/bulma-templates/templates/admin.html （ サンプルソース ではBulmaの他に「Font Awesome 」「 Google Fonts」を利用していましたので以下検証でもロードしたいと思います） 1. ヘッダーを編集 Experience Cloudのビルダーページから　設定 ＞ 詳細 ＞ ヘッドマーク アップを編集　でヘッダーを編集します。 デフォルトで用意されているヘッダーは次の画像のようになっています。（LWRテンプレートはAuraテンプレートに比べて編集可能な箇所が多いです） 次のタグがSLDSのロード箇所になりますので、 コメントアウト します https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_remove.htm < link rel = "stylesheet" href = "{ basePath }/assets/styles/salesforce-lightning-design-system.min.css?{ versionKey }" /> ちなみに < link rel = "stylesheet" href = "{ basePath }/assets/styles/dxp-site-spacing-styling-hooks.min.css?{ versionKey }" /> < link rel = "stylesheet" href = "{ basePath }/assets/styles/dxp-styling-hooks.min.css?{ versionKey }" /> < link rel = "stylesheet" href = "{ basePath }/assets/styles/dxp-slds-extensions.min.css?{ versionKey }" /> の箇所は、--dxp Styling Hooksと呼ばれる機能を反映させるための CSS になります。 https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_start_using.htm --dxp Styling Hooksとは CSS カスタムプロパティを使用し、左サイドにあるテーマパネルからボタンやリンクといったHTML要素のデザインをページ全体で一括で編集できる仕組みになります。 Styling Hookは使用しない！という方は コメントアウト しても良いかと思います。（今回は一旦そのまま残しておきます） 続いて、以下 サンプルソース の <head> 内の記述から、 https://github.com/BulmaTemplates/bulma-templates/blob/master/templates/admin.html Bulma、Font Awesome 、 Google Fontsをロードするタグを追加します。 < link rel = "stylesheet" href = "https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" > < link rel = "stylesheet" href = "https://fonts.googleapis.com/css?family=Open+Sans:300,400,700" > < link rel = "stylesheet" href = "https://unpkg.com/bulma@0.9.0/css/bulma.min.css" /> （hrefのリンクについては Salesforce の「設定」 ＞「CSP 信頼済みサイト」 から登録を行います） ここまででヘッダーの記述は以下のようになっているかと思います 2. LWCを作成 ヘッダーでSLDSを削除し各ソースをロードできたので、続いてLWCを作成します。 まず、以下 サンプルソース から <body> 内の記述をそのままLWCのHTMLにコピーします。 https://github.com/BulmaTemplates/bulma-templates/blob/master/templates/admin.html 次に、以下 サンプルソース からLWCの CSS にコピーします。 https://github.com/BulmaTemplates/bulma-templates/blob/master/css/admin.css ただし、 html,body { } の箇所に関しては コンポーネント の範囲外となってしまうため、ヘッダー側に記述をしました。 3. 確認 さて、LWCがいよいよ完成したので、サイトを公開しコンテンツを確認してみたいと思います！ ■ Build Your Own (LWR) ページ ■ サンプルサイト（ https://bulmatemplates.github.io/bulma-templates/templates/admin.html ） いかがでしょうか？ SLDSが削除されていること、Bulmaが正常にロードされていることが確認できるかと思います。 また、カード内の文章に「 Google Fonts」、検索欄に「Font Awesome 」が利用されていますが、こちらも正常に描写されていることがわかるかと思います。 ちなみに「ページ上左右のスペース」や「ボタンやリンク」のデザインが異なるかと思いますが、こちらは前述の --dxp Styling Hook が影響しており、ヘッダーから コメントアウト すると以下のようなサイトになります。 （ ピクセル パーフェクト！） 3. まとめ ここまで読んでいただきありがとうございました。 本記事がBuid Your Own (LWR) テンプレートについて理解の一助になれば幸いです。 今回、機能の紹介では「SLDSの削除」について取り上げましたが、他にも「多言語対応」「特権 スクリプト を使用した サードパーティ 製JSライブラリの利用」「LWRテンプレートのみ利用できるExperience Builderの コンポーネント 」「Salesfroce CMS との連携」等々、LWR テンプレートのユニークな機能は たくさん あります。 是非、公式ドキュメントを読んでいただき、その他の機能についてもキャッチアップしていただけると幸いです。 本記事ではLWR テンプレート利用によるWebフロントエンドの効果について主に紹介しましたが、バックエンドが Salesforce で統合されていることも大きなメリットとなります。弊社ではLWR テンプレートを利用したWebサイト開発の実績もありますので、 デザイン性が高く、高速・安全なWebサイトを フル Salesforce で実現したい方は是非ご相談ください！ 執筆： @kumakura.koki.isid 、レビュー： @higa （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 インフラをIaC化している環境において、 AWS Security Hub のアラート管理方法についてのお話です。 AWS Security Hubの セキュリティ基準 を有効にすると、作成したリソースを基準に沿ってチェックし、アラートを上げてくれます。 Security Hubのセキュリティ基準は細かい設定までチェックしたりするので、数百〜数千のアラートが上がる場合があり、その対応に苦労している開発者が多いようです。アラートの数が多いと、Security Hubのコンソールから新規のアラートを探すのが難しいため、 AWS 外部へチャット通知したりチケットを起票したりする運用をよく見かけます。 さて、イン フラリ ソースをCDKなどでIaC化している場合、それに対するアラートは AWS で発生している問題ではなく、コードで発生している問題といえます。コードで発生している問題は、コード リポジトリ で管理するのが良いでしょう。 そこで「CDKでイン フラリ ソースをIaC化している」「 GitHub リポジトリ でIaCを管理している」という前提の下、Security Hub のアラートを GitHub Issues に起票する仕組みを作成してみます。 仕組みの全体像 作成手順 Security Hub とセキュリティ基準を有効にする GitHub リポジトリで Issues を有効にする GitHub Appを作成する パラメータストアに必要なパラメータを登録する CDKスタックを作成する Lambda関数を作成する 完成 さいごに 仕組みの全体像 Security Hubで検知されたアラートはEventBridgeルールで受け取ることができます。 AWS HealthやGuardDutyなど他のサービスからのアラートも送信されるため、ここで欲しいアラートをフィルタリングします。 イベントの 送信先 をLambda関数とします。パラメータストアに GitHub Appの トーク ンを生成するための 秘密鍵 などを保存しておき、 GitHub Appの トーク ンを取得して GitHub リポジトリ にIssueを作成します。Issue作成が成功したらSecurity Hubアラートのワークフローステータスを NOTIFIED に変更します。 もちろんこの仕組みを構成する AWS リソースもなるべくCDKで作成し、自分自身に対するアラートもIssue化するようにします！ インフラコード本体とその問題点を同じ GitHub リポジトリ で管理できるため、問題の管理と修正を追跡しやすくなります。インフラを構築する初期段階からこの仕組みを作っておくのがおすすめで、リソースの作成・修正に伴うアラートを素早く認識でき、開発へのフィードバックが容易になるでしょう。 作成手順 Security Hub とセキュリティ基準を有効にする Security Hubとセキュリティ基準は手動で有効にします。今回は「 AWS 基礎セキュリティのベストプ ラク ティス」を利用します。 GitHub リポジトリ で Issues を有効にする IaCを管理する GitHub リポジトリ でIssues機能を有効化していない場合、有効にします。 リポジトリ のSettings > General > Features で設定できます。 GitHub Appを作成する GitHub REST API を利用するためにPersonal Access Tokenを使う方法もありますが、個人に紐づく トーク ンではなく、 Bot ユーザーとして API コールをしたいため、 GitHub App を作成します。 詳細は割愛し、ここでは概要だけ説明します。 組織アカウントを利用している場合、以下のURLから GitHub Appを新規作成する（組織のオーナー権限が必要）。作成後、App IDが画面に表示されるのでメモしておく https://github.com/organizations/ [organization名]/settings/apps 権限は Issues の Read and write を許可する。（自動的に Metadata の Read-only も許可される） GitHub App作成後の画面から 秘密鍵 を生成し、ダウンロードする 作成した GitHub Appを対象 リポジトリ にインストールする。インストール後、以下のリンクからAppを選択すると、Installation IDがURLパスに表示されるのでメモしておく https://github.com/organizations/ [organization名]/settings/installations パラメータストアに必要なパラメータを登録する AWS Systems Manager のパラメータストアに、以下のパラメータを登録します /github/GITHUB_APP_ID : GitHub Appの App ID /github/GITHUB_APP_INSTALLATION_ID : GitHub Appの Installation ID /github/GITHUB_APP_PRIVATE_KEY : ダウンロードした 秘密鍵 ファイルの中身。 SecureString として登録する CDKスタックを作成する 以下のとおりスタックを作成します。 props で AWS アカウントID、デプロイ先のリージョン、 GitHub リポジトリ のオーナー（組織）名、 リポジトリ 名をもらっています。 import { Duration , Stack , StackProps } from "aws-cdk-lib" ; import * as events from "aws-cdk-lib/aws-events" ; import * as eventTargets from "aws-cdk-lib/aws-events-targets" ; import * as iam from "aws-cdk-lib/aws-iam" ; import { Runtime } from "aws-cdk-lib/aws-lambda" ; import * as lambdaNodejs from "aws-cdk-lib/aws-lambda-nodejs" ; import { Construct } from "constructs" ; export interface Props extends StackProps { accountId: string ; region: string ; githubOwner: string ; githubRepoName: string ; } export class GitHubIssueStack extends Stack { constructor( scope: Construct , id: string , props: Props ) { super( scope , id , props ); // Lambda関数実行ロール用のIAMポリシー // パラメータの取得と、Security Hub検出結果の更新を許可する const createGithubIssueFunctionPolicy = new iam.ManagedPolicy ( this , "CreateGithubIssueFunctionPolicy" , { managedPolicyName: "CreateGithubIssueFunctionPolicy" , statements: [ new iam.PolicyStatement ( { resources: [ `arn:aws:ssm: ${ props.region } : ${ props.accountId } :parameter/github/*` ] , actions: [ "ssm:GetParameter" ] , effect: iam.Effect.ALLOW , } ), new iam.PolicyStatement ( { resources: [ "*" ] , actions: [ "securityhub:BatchUpdateFindings" ] , effect: iam.Effect.ALLOW , } ), ] , } ); // Lambda関数 // 環境変数にGitHubリポジトリのオーナー名とリポジトリ名を渡す const createGithubIssueFunction = new lambdaNodejs.NodejsFunction ( this , "CreateGithubIssueFunction" , { entry: "functions/create-github-issue.ts" , runtime: Runtime.NODEJS_16_X , timeout: Duration.minutes ( 5 ), environment: { GITHUB_OWNER: props.githubOwner , GITHUB_REPO: props.githubRepoName , } , description: "Create GitHub Issue from EventBridge Security Hub events and update finding's workflow status" , bundling: { forceDockerBundling: false } , } ); createGithubIssueFunction.role?.addManagedPolicy ( createGithubIssueFunctionPolicy ); // EventBridgeルール。イベントパターンのフィルタリングを行う // ここではコンプライアンスステータス、製品名、レコートの状態、ワークフローステータスでフィルタリングしているが、アラートの重要度などをフィルタリング条件に追加することもできる // ワークフローステータスを NEW に限定することで、NOTIFIED に変更されたアラートを再度通知しないようにする new events.Rule ( this , "SecurityHubEventRule" , { ruleName: "security-hub-findings" , eventPattern: { source: [ "aws.securityhub" ] , detailType: [ "Security Hub Findings - Imported" ] , detail: { findings: { Compliance: { Status: [ "FAILED" ] , } , ProductName: [ "Security Hub" ] , RecordState: [ "ACTIVE" ] , Workflow: { Status: [ "NEW" ] , } , } , } , } , targets: [ new eventTargets.LambdaFunction ( createGithubIssueFunction ) ] , } ); } } Lambda関数を作成する functions/create-github-issue.ts に以下のようにLambda関数を実装します。 GitHub の トーク ンを取得するためには 秘密鍵 からJWTを生成し、 GitHub にリク エス トを投げる必要があるため、 jsonwebtoken パッケージを利用しています（TypeScriptの場合 @types/jsonwebtoken もインストール）。リク エス トには axios パッケージを利用しています。 また、 GitHub のIssue作成は Octokit（ @octokit/rest パッケージ）からリク エス トを投げています。 import { SecurityHubClient , BatchUpdateFindingsCommand , BatchUpdateFindingsCommandInput , WorkflowStatus , } from "@aws-sdk/client-securityhub" ; import { SSMClient , GetParameterCommand } from "@aws-sdk/client-ssm" ; import { Octokit } from "@octokit/rest" ; import { Handler , EventBridgeEvent } from "aws-lambda" ; import axios from "axios" ; import { sign } from "jsonwebtoken" ; export const handler: Handler = async ( event: EventBridgeEvent < string , Detail >) => { // GitHubのAccess Tokenを取得する関数 const token = await getGitHubToken (); const octokit = new Octokit ( { auth: token } ); await Promise . all( event.detail.findings.map (async ( finding ) => { try { // 作成するIssueのボディテキスト const body = `## ${ finding.Title } * Security Hub コントロールID: \` ${ finding.ProductFields.ControlId ?? finding.Compliance.SecurityControlId ?? "" } \` * 重要度: \` ${ finding.Severity.Label } \` * 説明: ${ finding.Description } * リージョン: \` ${ finding.Region } \` * リソースID: ${ finding.ProductFields[ "Resources:0/Id" ] } * 対応方法: ${ finding.ProductFields.RecommendationUrl ?? finding.Remediation.Recommendation.Url } * 最初の観測日時: ${ finding.FirstObservedAt } * ID: \` ${ finding.Id } \`` ; // Issueを作成 const res = await octokit.request ( `POST /repos/ ${process .env.GITHUB_OWNER } / ${process .env.GITHUB_REPO } /issues` , { owner: process .env.GITHUB_OWNER , repo: process .env.GITHUB_REPO , title: finding.Title , body: body , labels: [ "Security Hub" ] , } ); if ( res. status === 201 ) { console .log ( `Issue created. [ID] ${ finding.Id } ` ); // Issueの作成が成功したら、検出結果のワークフローステータスを変更する await setFindingNotified ( finding.Id , finding.ProductArn ); } else { console .error ( `Issue creation failed. [ID] ${ finding.Id } [Status] ${ res. status } ` ); } } catch ( e ) { console .error ( `Issue creation failed. [ID] ${ finding.Id } [Message] ${ e instanceof Error ? e.message : "" } ` ); } } ) ); } ; イベントの型は以下のとおり定義しています。ほぼ全フィールドを網羅していますが、使用するフィールドのみを定義しても良いでしょう。 (2023/2/28追記)Security Hubの 検出結果の集約 機能が利用可能になり、 一部のフィールドが削除 される場合があります。これに合わせてフィールド定義を修正しました。 type Detail = { findings: Finding [] ; } ; type Finding = { SchemaVersion: string ; Id: string ; ProductArn: string ; GeneratorId: string ; AwsAccountId: string ; Types: string [] ; FirstObservedAt: string ; LastObservedAt: string ; CreatedAt: string ; UpdatedAt: string ; Severity: { Normalized: number ; Label: string ; Product?: number ; Original: string } ; Title: string ; Description: string ; Remediation: { Recommendation: { Text : string ; Url: string } } ; ProductFields: { StandardsArn?: string ; StandardsSubscriptionArn?: string ; ControlId?: string ; RecommendationUrl?: string ; "RelatedAWSResources:0/name" : string ; "RelatedAWSResources:0/type" : string ; StandardsControlArn?: string ; "aws/securityhub/ProductName" : string ; "aws/securityhub/CompanyName" : string ; "Resources:0/Id" : string ; "aws/securityhub/FindingId" : string ; } ; Resources: { Type: string ; Id: string ; Partition: string ; Region: string ; Details: any }[] ; RecordState: string ; WorkflowState: string ; Workflow: { Status: string } ; Compliance: { Status: string ; SecurityControlId?: string } ; ProductName: string ; CompanyName: string ; FindingProviderFields: { Types: string [] ; Severity: { Normalized: number ; Label: string ; Product: number ; Original: string } ; } ; Region: string ; } ; GitHub から トーク ンを取得する関数は次のとおりです。 async function getGitHubToken () : Promise < string > { // App IDを取得 const appId = await getParameter ( "/github/GITHUB_APP_ID" , false ); const payload = { iat: Math .floor ( Date .now () / 1000 ) - 10 , exp: Math .floor ( Date .now () / 1000 ) + 60 , iss: appId , } ; // 秘密鍵を取得 const privateKey = await getParameter ( "/github/GITHUB_APP_PRIVATE_KEY" , true ); // 秘密鍵を含んだJWTを生成 const token = sign ( payload , privateKey , { algorithm: "RS256" } ); // Installation Idを取得 const installationId = await getParameter ( "/github/GITHUB_APP_INSTALLATION_ID" , false ); // GitHub Access Tokenをリクエスト const res = await axios.post < { token?: string } >( `https://api.github.com/app/installations/ ${ installationId } /access_tokens` , null , { headers: { Authorization: "Bearer " + token , Accept: "application/vnd.github+json" , } , } ); if ( res.data.token ) { return res.data.token ; } else { throw new Error ( "Failed to get access token" ); } } const ssmClient = new SSMClient ( { region: process .env.AWS_REGION } ); // パラメータストアからパラメータを取得する関数 async function getParameter ( name: string , encrypted: boolean ) : Promise < string > { const input = { Name: name , WithDecryption: encrypted , } ; const command = new GetParameterCommand ( input ); const ssmRes = await ssmClient.send ( command ); const param = ssmRes.Parameter?.Value ; if ( ! param ) { throw new Error ( `Failed to get ${ name } from SSM parameter store` ); } return param ; } Issueを作成したアラートのワークフローステータスを NOTIFIED に変更する関数です。 const securityHubClient = new SecurityHubClient ( { region: process .env.AWS_REGION } ); async function setFindingNotified ( findingId: string , productArn: string ) { const params: BatchUpdateFindingsCommandInput = { FindingIdentifiers: [{ Id: findingId , ProductArn: productArn }] , Workflow: { Status: WorkflowStatus.NOTIFIED } , } ; const command = new BatchUpdateFindingsCommand ( params ); await securityHubClient.send ( command ); } 完成 以上で完成です。スタックをデプロイしてみると、早速このスタックに対して CloudFormation.1 という Issue が作成されました。便利な修復方法のリンクもイベント内容に含まれているので、Issue内容に追加しています。 あとは開発チームの問題管理フローで対応していけば良いですね。 さいごに ここまで紹介した仕組みではIssueの作成までを自動化し、Issueのクローズは手動でする必要があります。 作成されたIssue IDと検出結果IDの関連を DynamoDBテーブルなどに保管すれば、リソースの修正によって解決したIssueを自動でクローズする仕組みも作ることができそうです。 IaCで作成したリソースの問題点を見逃さずに適切に管理し、セキュアなインフラを作成していきましょう！ 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 - セキュリティエンジニア(セキュリティ設計) 執筆： @kou.kinyo2 、レビュー： @higa （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 インフラをIaC化している環境において、 AWS Security Hub のアラート管理方法についてのお話です。 AWS Security Hubの セキュリティ基準 を有効にすると、作成したリソースを基準に沿ってチェックし、アラートを上げてくれます。 Security Hubのセキュリティ基準は細かい設定までチェックしたりするので、数百〜数千のアラートが上がる場合があり、その対応に苦労している開発者が多いようです。アラートの数が多いと、Security Hubのコンソールから新規のアラートを探すのが難しいため、 AWS 外部へチャット通知したりチケットを起票したりする運用をよく見かけます。 さて、イン フラリ ソースをCDKなどでIaC化している場合、それに対するアラートは AWS で発生している問題ではなく、コードで発生している問題といえます。コードで発生している問題は、コード リポジトリ で管理するのが良いでしょう。 そこで「CDKでイン フラリ ソースをIaC化している」「 GitHub リポジトリ でIaCを管理している」という前提の下、Security Hub のアラートを GitHub Issues に起票する仕組みを作成してみます。 仕組みの全体像 作成手順 Security Hub とセキュリティ基準を有効にする GitHub リポジトリで Issues を有効にする GitHub Appを作成する パラメータストアに必要なパラメータを登録する CDKスタックを作成する Lambda関数を作成する 完成 さいごに 仕組みの全体像 Security Hubで検知されたアラートはEventBridgeルールで受け取ることができます。 AWS HealthやGuardDutyなど他のサービスからのアラートも送信されるため、ここで欲しいアラートをフィルタリングします。 イベントの 送信先 をLambda関数とします。パラメータストアに GitHub Appの トーク ンを生成するための 秘密鍵 などを保存しておき、 GitHub Appの トーク ンを取得して GitHub リポジトリ にIssueを作成します。Issue作成が成功したらSecurity Hubアラートのワークフローステータスを NOTIFIED に変更します。 もちろんこの仕組みを構成する AWS リソースもなるべくCDKで作成し、自分自身に対するアラートもIssue化するようにします！ インフラコード本体とその問題点を同じ GitHub リポジトリ で管理できるため、問題の管理と修正を追跡しやすくなります。インフラを構築する初期段階からこの仕組みを作っておくのがおすすめで、リソースの作成・修正に伴うアラートを素早く認識でき、開発へのフィードバックが容易になるでしょう。 作成手順 Security Hub とセキュリティ基準を有効にする Security Hubとセキュリティ基準は手動で有効にします。今回は「 AWS 基礎セキュリティのベストプ ラク ティス」を利用します。 GitHub リポジトリ で Issues を有効にする IaCを管理する GitHub リポジトリ でIssues機能を有効化していない場合、有効にします。 リポジトリ のSettings > General > Features で設定できます。 GitHub Appを作成する GitHub REST API を利用するためにPersonal Access Tokenを使う方法もありますが、個人に紐づく トーク ンではなく、 Bot ユーザーとして API コールをしたいため、 GitHub App を作成します。 詳細は割愛し、ここでは概要だけ説明します。 組織アカウントを利用している場合、以下のURLから GitHub Appを新規作成する（組織のオーナー権限が必要）。作成後、App IDが画面に表示されるのでメモしておく https://github.com/organizations/ [organization名]/settings/apps 権限は Issues の Read and write を許可する。（自動的に Metadata の Read-only も許可される） GitHub App作成後の画面から 秘密鍵 を生成し、ダウンロードする 作成した GitHub Appを対象 リポジトリ にインストールする。インストール後、以下のリンクからAppを選択すると、Installation IDがURLパスに表示されるのでメモしておく https://github.com/organizations/ [organization名]/settings/installations パラメータストアに必要なパラメータを登録する AWS Systems Manager のパラメータストアに、以下のパラメータを登録します /github/GITHUB_APP_ID : GitHub Appの App ID /github/GITHUB_APP_INSTALLATION_ID : GitHub Appの Installation ID /github/GITHUB_APP_PRIVATE_KEY : ダウンロードした 秘密鍵 ファイルの中身。 SecureString として登録する CDKスタックを作成する 以下のとおりスタックを作成します。 props で AWS アカウントID、デプロイ先のリージョン、 GitHub リポジトリ のオーナー（組織）名、 リポジトリ 名をもらっています。 import { Duration , Stack , StackProps } from "aws-cdk-lib" ; import * as events from "aws-cdk-lib/aws-events" ; import * as eventTargets from "aws-cdk-lib/aws-events-targets" ; import * as iam from "aws-cdk-lib/aws-iam" ; import { Runtime } from "aws-cdk-lib/aws-lambda" ; import * as lambdaNodejs from "aws-cdk-lib/aws-lambda-nodejs" ; import { Construct } from "constructs" ; export interface Props extends StackProps { accountId: string ; region: string ; githubOwner: string ; githubRepoName: string ; } export class GitHubIssueStack extends Stack { constructor( scope: Construct , id: string , props: Props ) { super( scope , id , props ); // Lambda関数実行ロール用のIAMポリシー // パラメータの取得と、Security Hub検出結果の更新を許可する const createGithubIssueFunctionPolicy = new iam.ManagedPolicy ( this , "CreateGithubIssueFunctionPolicy" , { managedPolicyName: "CreateGithubIssueFunctionPolicy" , statements: [ new iam.PolicyStatement ( { resources: [ `arn:aws:ssm: ${ props.region } : ${ props.accountId } :parameter/github/*` ] , actions: [ "ssm:GetParameter" ] , effect: iam.Effect.ALLOW , } ), new iam.PolicyStatement ( { resources: [ "*" ] , actions: [ "securityhub:BatchUpdateFindings" ] , effect: iam.Effect.ALLOW , } ), ] , } ); // Lambda関数 // 環境変数にGitHubリポジトリのオーナー名とリポジトリ名を渡す const createGithubIssueFunction = new lambdaNodejs.NodejsFunction ( this , "CreateGithubIssueFunction" , { entry: "functions/create-github-issue.ts" , runtime: Runtime.NODEJS_16_X , timeout: Duration.minutes ( 5 ), environment: { GITHUB_OWNER: props.githubOwner , GITHUB_REPO: props.githubRepoName , } , description: "Create GitHub Issue from EventBridge Security Hub events and update finding's workflow status" , bundling: { forceDockerBundling: false } , } ); createGithubIssueFunction.role?.addManagedPolicy ( createGithubIssueFunctionPolicy ); // EventBridgeルール。イベントパターンのフィルタリングを行う // ここではコンプライアンスステータス、製品名、レコートの状態、ワークフローステータスでフィルタリングしているが、アラートの重要度などをフィルタリング条件に追加することもできる // ワークフローステータスを NEW に限定することで、NOTIFIED に変更されたアラートを再度通知しないようにする new events.Rule ( this , "SecurityHubEventRule" , { ruleName: "security-hub-findings" , eventPattern: { source: [ "aws.securityhub" ] , detailType: [ "Security Hub Findings - Imported" ] , detail: { findings: { Compliance: { Status: [ "FAILED" ] , } , ProductName: [ "Security Hub" ] , RecordState: [ "ACTIVE" ] , Workflow: { Status: [ "NEW" ] , } , } , } , } , targets: [ new eventTargets.LambdaFunction ( createGithubIssueFunction ) ] , } ); } } Lambda関数を作成する functions/create-github-issue.ts に以下のようにLambda関数を実装します。 GitHub の トーク ンを取得するためには 秘密鍵 からJWTを生成し、 GitHub にリク エス トを投げる必要があるため、 jsonwebtoken パッケージを利用しています（TypeScriptの場合 @types/jsonwebtoken もインストール）。リク エス トには axios パッケージを利用しています。 また、 GitHub のIssue作成は Octokit（ @octokit/rest パッケージ）からリク エス トを投げています。 import { SecurityHubClient , BatchUpdateFindingsCommand , BatchUpdateFindingsCommandInput , WorkflowStatus , } from "@aws-sdk/client-securityhub" ; import { SSMClient , GetParameterCommand } from "@aws-sdk/client-ssm" ; import { Octokit } from "@octokit/rest" ; import { Handler , EventBridgeEvent } from "aws-lambda" ; import axios from "axios" ; import { sign } from "jsonwebtoken" ; export const handler: Handler = async ( event: EventBridgeEvent < string , Detail >) => { // GitHubのAccess Tokenを取得する関数 const token = await getGitHubToken (); const octokit = new Octokit ( { auth: token } ); await Promise . all( event.detail.findings.map (async ( finding ) => { try { // 作成するIssueのボディテキスト const body = `## ${ finding.Title } * Security Hub コントロールID: \` ${ finding.ProductFields.ControlId ?? finding.Compliance.SecurityControlId ?? "" } \` * 重要度: \` ${ finding.Severity.Label } \` * 説明: ${ finding.Description } * リージョン: \` ${ finding.Region } \` * リソースID: ${ finding.ProductFields[ "Resources:0/Id" ] } * 対応方法: ${ finding.ProductFields.RecommendationUrl ?? finding.Remediation.Recommendation.Url } * 最初の観測日時: ${ finding.FirstObservedAt } * ID: \` ${ finding.Id } \`` ; // Issueを作成 const res = await octokit.request ( `POST /repos/ ${process .env.GITHUB_OWNER } / ${process .env.GITHUB_REPO } /issues` , { owner: process .env.GITHUB_OWNER , repo: process .env.GITHUB_REPO , title: finding.Title , body: body , labels: [ "Security Hub" ] , } ); if ( res. status === 201 ) { console .log ( `Issue created. [ID] ${ finding.Id } ` ); // Issueの作成が成功したら、検出結果のワークフローステータスを変更する await setFindingNotified ( finding.Id , finding.ProductArn ); } else { console .error ( `Issue creation failed. [ID] ${ finding.Id } [Status] ${ res. status } ` ); } } catch ( e ) { console .error ( `Issue creation failed. [ID] ${ finding.Id } [Message] ${ e instanceof Error ? e.message : "" } ` ); } } ) ); } ; イベントの型は以下のとおり定義しています。ほぼ全フィールドを網羅していますが、使用するフィールドのみを定義しても良いでしょう。 (2023/2/28追記)Security Hubの 検出結果の集約 機能が利用可能になり、 一部のフィールドが削除 される場合があります。これに合わせてフィールド定義を修正しました。 type Detail = { findings: Finding [] ; } ; type Finding = { SchemaVersion: string ; Id: string ; ProductArn: string ; GeneratorId: string ; AwsAccountId: string ; Types: string [] ; FirstObservedAt: string ; LastObservedAt: string ; CreatedAt: string ; UpdatedAt: string ; Severity: { Normalized: number ; Label: string ; Product?: number ; Original: string } ; Title: string ; Description: string ; Remediation: { Recommendation: { Text : string ; Url: string } } ; ProductFields: { StandardsArn?: string ; StandardsSubscriptionArn?: string ; ControlId?: string ; RecommendationUrl?: string ; "RelatedAWSResources:0/name" : string ; "RelatedAWSResources:0/type" : string ; StandardsControlArn?: string ; "aws/securityhub/ProductName" : string ; "aws/securityhub/CompanyName" : string ; "Resources:0/Id" : string ; "aws/securityhub/FindingId" : string ; } ; Resources: { Type: string ; Id: string ; Partition: string ; Region: string ; Details: any }[] ; RecordState: string ; WorkflowState: string ; Workflow: { Status: string } ; Compliance: { Status: string ; SecurityControlId?: string } ; ProductName: string ; CompanyName: string ; FindingProviderFields: { Types: string [] ; Severity: { Normalized: number ; Label: string ; Product: number ; Original: string } ; } ; Region: string ; } ; GitHub から トーク ンを取得する関数は次のとおりです。 async function getGitHubToken () : Promise < string > { // App IDを取得 const appId = await getParameter ( "/github/GITHUB_APP_ID" , false ); const payload = { iat: Math .floor ( Date .now () / 1000 ) - 10 , exp: Math .floor ( Date .now () / 1000 ) + 60 , iss: appId , } ; // 秘密鍵を取得 const privateKey = await getParameter ( "/github/GITHUB_APP_PRIVATE_KEY" , true ); // 秘密鍵を含んだJWTを生成 const token = sign ( payload , privateKey , { algorithm: "RS256" } ); // Installation Idを取得 const installationId = await getParameter ( "/github/GITHUB_APP_INSTALLATION_ID" , false ); // GitHub Access Tokenをリクエスト const res = await axios.post < { token?: string } >( `https://api.github.com/app/installations/ ${ installationId } /access_tokens` , null , { headers: { Authorization: "Bearer " + token , Accept: "application/vnd.github+json" , } , } ); if ( res.data.token ) { return res.data.token ; } else { throw new Error ( "Failed to get access token" ); } } const ssmClient = new SSMClient ( { region: process .env.AWS_REGION } ); // パラメータストアからパラメータを取得する関数 async function getParameter ( name: string , encrypted: boolean ) : Promise < string > { const input = { Name: name , WithDecryption: encrypted , } ; const command = new GetParameterCommand ( input ); const ssmRes = await ssmClient.send ( command ); const param = ssmRes.Parameter?.Value ; if ( ! param ) { throw new Error ( `Failed to get ${ name } from SSM parameter store` ); } return param ; } Issueを作成したアラートのワークフローステータスを NOTIFIED に変更する関数です。 const securityHubClient = new SecurityHubClient ( { region: process .env.AWS_REGION } ); async function setFindingNotified ( findingId: string , productArn: string ) { const params: BatchUpdateFindingsCommandInput = { FindingIdentifiers: [{ Id: findingId , ProductArn: productArn }] , Workflow: { Status: WorkflowStatus.NOTIFIED } , } ; const command = new BatchUpdateFindingsCommand ( params ); await securityHubClient.send ( command ); } 完成 以上で完成です。スタックをデプロイしてみると、早速このスタックに対して CloudFormation.1 という Issue が作成されました。便利な修復方法のリンクもイベント内容に含まれているので、Issue内容に追加しています。 あとは開発チームの問題管理フローで対応していけば良いですね。 さいごに ここまで紹介した仕組みではIssueの作成までを自動化し、Issueのクローズは手動でする必要があります。 作成されたIssue IDと検出結果IDの関連を DynamoDBテーブルなどに保管すれば、リソースの修正によって解決したIssueを自動でクローズする仕組みも作ることができそうです。 IaCで作成したリソースの問題点を見逃さずに適切に管理し、セキュアなインフラを作成していきましょう！ 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 - セキュリティエンジニア(セキュリティ設計) 執筆： @kou.kinyo2 、レビュー： @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 で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 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 で執筆されました ）