電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、 蒸気機関 が高度に発達したレトロなアニメ（ スチームパンク ）の世界観編です。 Steampunk（ スチームパンク ）って言葉を知ってますか。SFから派生していて、 蒸気機関 （Steam）が高度に発達したレトロな世界観です。有名な作品だと「 天空の城ラピュタ 」、「 ハウルの動く城 」、「 鋼の錬金術師 」などがあります。 pixiv百科事典 スチームパンク 今回は、Steampunkの世界に飛び込んでみましょう。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 steampunk illustration of huge battleship flying over city highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting clockwork machines machines with cogs flying above clouds illuminated fountain in town まとめ 仲間募集 Stable Diffusionの過去コンテンツ steampunk illustration of huge battleship flying over city highly detailed 今回もシンプルな呪文から始めて、徐々に呪文を足していきましょう。 Steampunkなイラストを描くには、steampunk illustration ofで始めます。 今回の描画対象は、街の上を飛んでいる巨大な戦艦（huge battleship flying over city）です。 長い呪文は切り捨てられる編 で、説明したようにaやtheは必要ないので、省いています。 highly detailedを足すと描画対象のクオリティが上がります。 今回の呪文 steampunk illustration of huge battleship flying over city highly detailed トーク ン出力結果（改行版） 長い呪文は切り捨てられる編 参照 10 ['steampunk</w>', 'illustration</w>', 'of</w>', 'huge</w>', 'battleship</w>', 'flying</w>', 'over</w>', 'city</w>', 'highly</w>', 'detailed</w>'] 画像出力結果 artstation deviantart concept art digital painting award winning 作風用の呪文を追加しましょう。 artstation、 deviantart でアートの投稿サイトを指定します。 concept art、digital painting、award winningはクオリティを上げるためのお約束の呪文。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of huge battleship flying over city highly detailed artstation deviantart concept art digital painting award winning 閲覧用呪文（改行版） steampunk illustration of huge battleship flying over city highly detailed artstation deviantart concept art digital painting award winning トーク ン出力結果（改行版） 19 ['steampunk</w>', 'illustration</w>', 'of</w>', 'huge</w>', 'battleship</w>', 'flying</w>', 'over</w>', 'city</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>'] artstationがartとstationの2つの トーク ンに分かれてしまってますが、artstationが有効な呪文であることは、何度もあり/なしで確認しています。 画像出力結果 fantasy scene fantasy composition fantasy lighting 演出用の呪文を追加しましょう。scene（シーン）、composition（構図）、lighting（ライティング）を指定します。いろいろ試しましたが、Steampunkの世界観には、fantasyがあっているようです。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of huge battleship flying over city highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of huge battleship flying over city highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting トーク ン出力結果（改行版） 25 ['steampunk</w>', 'illustration</w>', 'of</w>', 'huge</w>', 'battleship</w>', 'flying</w>', 'over</w>', 'city</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'fantasy</w>', 'scene</w>', 'fantasy</w>', 'composition</w>', 'fantasy</w>', 'lighting</w>'] 画像出力結果 良い感じに仕上がりましたね。今度は、描画対象（ サブジ ェクト）を変えてみましょう。 clockwork machines clockwork machines（ゼンマイ仕掛けの機械）を試してみましょう。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of clockwork machines highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of clockwork machines highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting トーク ン出力結果（改行版） 22 ['steampunk</w>', 'illustration</w>', 'of</w>', 'clockwork</w>', 'machines</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'fantasy</w>', 'scene</w>', 'fantasy</w>', 'composition</w>', 'fantasy</w>', 'lighting</w>'] 画像出力結果 machines with cogs flying above clouds 今度は、雲の上を飛んでいる歯車付き機械です。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of machines with cogs flying above clouds highly detailed artstation deviantart concept art digital painting award winning fantasy scene golden hour fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of machines with cogs flying above clouds highly detailed artstation deviantart concept art digital painting award winning fantasy scene golden hour fantasy composition fantasy lighting トーク ン出力結果（改行版） 29 ['steampunk</w>', 'illustration</w>', 'of</w>', 'machines</w>', 'flying</w>', 'above</w>', 'clouds</w>', 'with</w>', 'co', 'gs</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'fantasy</w>', 'scene</w>', 'golden</w>', 'hour</w>', 'fantasy</w>', 'composition</w>', 'fantasy</w>', 'lighting</w>'] cogs（歯車）がcoとgsに分割されてしまっていますが、cogsが有効な呪文であることは何度も試して確認済みです。 画像出力結果 illuminated fountain in town 最後は、街の中のライトアップされた噴水です。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of illuminated fountain in town highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of illuminated fountain in town highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting トーク ン出力結果（改行版） 24 ['steampunk</w>', 'illustration</w>', 'of</w>', 'illuminated</w>', 'fountain</w>', 'in</w>', town</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'fantasy</w>', 'scene</w>', 'fantasy</w>', 'composition</w>', 'fantasy</w>', 'lighting</w>'] 画像出力結果 まとめ 今回は、Steampunkのイラストを扱いました。 蒸気機関 が高度に発達したレトロなアニメ（ スチームパンク ）の世界観、好きな人は多いのではないでしょうか。 次回は、 A as Bの呪文による画像合成編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの過去コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、 蒸気機関 が高度に発達したレトロなアニメ（ スチームパンク ）の世界観編です。 Steampunk（ スチームパンク ）って言葉を知ってますか。SFから派生していて、 蒸気機関 （Steam）が高度に発達したレトロな世界観です。有名な作品だと「 天空の城ラピュタ 」、「 ハウルの動く城 」、「 鋼の錬金術師 」などがあります。 pixiv百科事典 スチームパンク 今回は、Steampunkの世界に飛び込んでみましょう。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 steampunk illustration of huge battleship flying over city highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting clockwork machines machines with cogs flying above clouds illuminated fountain in town まとめ 仲間募集 Stable Diffusionの過去コンテンツ steampunk illustration of huge battleship flying over city highly detailed 今回もシンプルな呪文から始めて、徐々に呪文を足していきましょう。 Steampunkなイラストを描くには、steampunk illustration ofで始めます。 今回の描画対象は、街の上を飛んでいる巨大な戦艦（huge battleship flying over city）です。 長い呪文は切り捨てられる編 で、説明したようにaやtheは必要ないので、省いています。 highly detailedを足すと描画対象のクオリティが上がります。 今回の呪文 steampunk illustration of huge battleship flying over city highly detailed トーク ン出力結果（改行版） 長い呪文は切り捨てられる編 参照 10 ['steampunk</w>', 'illustration</w>', 'of</w>', 'huge</w>', 'battleship</w>', 'flying</w>', 'over</w>', 'city</w>', 'highly</w>', 'detailed</w>'] 画像出力結果 artstation deviantart concept art digital painting award winning 作風用の呪文を追加しましょう。 artstation、 deviantart でアートの投稿サイトを指定します。 concept art、digital painting、award winningはクオリティを上げるためのお約束の呪文。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of huge battleship flying over city highly detailed artstation deviantart concept art digital painting award winning 閲覧用呪文（改行版） steampunk illustration of huge battleship flying over city highly detailed artstation deviantart concept art digital painting award winning トーク ン出力結果（改行版） 19 ['steampunk</w>', 'illustration</w>', 'of</w>', 'huge</w>', 'battleship</w>', 'flying</w>', 'over</w>', 'city</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>'] artstationがartとstationの2つの トーク ンに分かれてしまってますが、artstationが有効な呪文であることは、何度もあり/なしで確認しています。 画像出力結果 fantasy scene fantasy composition fantasy lighting 演出用の呪文を追加しましょう。scene（シーン）、composition（構図）、lighting（ライティング）を指定します。いろいろ試しましたが、Steampunkの世界観には、fantasyがあっているようです。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of huge battleship flying over city highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of huge battleship flying over city highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting トーク ン出力結果（改行版） 25 ['steampunk</w>', 'illustration</w>', 'of</w>', 'huge</w>', 'battleship</w>', 'flying</w>', 'over</w>', 'city</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'fantasy</w>', 'scene</w>', 'fantasy</w>', 'composition</w>', 'fantasy</w>', 'lighting</w>'] 画像出力結果 良い感じに仕上がりましたね。今度は、描画対象（ サブジ ェクト）を変えてみましょう。 clockwork machines clockwork machines（ゼンマイ仕掛けの機械）を試してみましょう。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of clockwork machines highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of clockwork machines highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting トーク ン出力結果（改行版） 22 ['steampunk</w>', 'illustration</w>', 'of</w>', 'clockwork</w>', 'machines</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'fantasy</w>', 'scene</w>', 'fantasy</w>', 'composition</w>', 'fantasy</w>', 'lighting</w>'] 画像出力結果 machines with cogs flying above clouds 今度は、雲の上を飛んでいる歯車付き機械です。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of machines with cogs flying above clouds highly detailed artstation deviantart concept art digital painting award winning fantasy scene golden hour fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of machines with cogs flying above clouds highly detailed artstation deviantart concept art digital painting award winning fantasy scene golden hour fantasy composition fantasy lighting トーク ン出力結果（改行版） 29 ['steampunk</w>', 'illustration</w>', 'of</w>', 'machines</w>', 'flying</w>', 'above</w>', 'clouds</w>', 'with</w>', 'co', 'gs</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'fantasy</w>', 'scene</w>', 'golden</w>', 'hour</w>', 'fantasy</w>', 'composition</w>', 'fantasy</w>', 'lighting</w>'] cogs（歯車）がcoとgsに分割されてしまっていますが、cogsが有効な呪文であることは何度も試して確認済みです。 画像出力結果 illuminated fountain in town 最後は、街の中のライトアップされた噴水です。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of illuminated fountain in town highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of illuminated fountain in town highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting トーク ン出力結果（改行版） 24 ['steampunk</w>', 'illustration</w>', 'of</w>', 'illuminated</w>', 'fountain</w>', 'in</w>', town</w>', 'highly</w>', 'detailed</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'fantasy</w>', 'scene</w>', 'fantasy</w>', 'composition</w>', 'fantasy</w>', 'lighting</w>'] 画像出力結果 まとめ 今回は、Steampunkのイラストを扱いました。 蒸気機関 が高度に発達したレトロなアニメ（ スチームパンク ）の世界観、好きな人は多いのではないでしょうか。 次回は、 A as Bの呪文による画像合成編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの過去コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

はじめまして、X イノベーション 本部 オープン イノベーション ラボの飯田です。 ISIDでは、有志で論文輪読会を実施しています。 tech.isid.co.jp 今回、その中で、私が読んだDNAストレージについてご紹介します。 DNAストレージという技術は、DNAを情報記録媒体として用いる技術です。 DNAの 塩基配列 をうまく活用することで、デジタルデータの読み書きが可能となります。 マイクロソフト 等が積極的に研究を行っているようです　( Microsoft Research：DNA Storage ) 輪読会では、以下2本の論文を紹介しました。 その内容を簡単にご紹介します。 Bornholt, J. et al. (2016) A DNA-based Archival Storage System DNAストレージが初登場したと言われる Clelland C. T. et al. (1999) Hiding messages in DNA microdots 前提知識 なぜDNAストレージ？ ビックデータ時代のストレージの課題とDNAストレージ DNAストレージの簡単な原理 最初のDNAストレージ DNAストレージの課題　（冗長性・エラー耐性 と ランダムアクセス） 冗長性・エラー耐性 ランダムアクセス Bornholt, J. et al. (2016) のアーキテクチャ 書き込み処理 の流れ 読み出し処理 の流れ 必要であれば、DNAストレージの増幅 実例：実際に保存されたデータ例 最後に、バイオロジー×IT技術の可能性！ 前提知識 DNA ヒトの細胞では、核の中の染色体にあり、A（アデニン）・T（チミン）・G（グアニン）・C（シトシン）の4種で構成されている。 DNA中ではAとT、GとCが結合していて、その結合の対を塩基対と言います。 DNA合成技術 狙った 塩基配列 でDNAを生み出す方法。DNAストレージではWriteに相当する手技。 シークエンシング DNAの構成成分であるATGC 4種の 塩基配列 を決定すること。 古典的なサンガー法から、NGSまでいくつかの手法がある。DNAストレージではReadに相当する手技。 なぜDNAストレージ？ ビックデータ時代のストレージの課題とDNAストレージ 現在のビックデータ時代、現状の 記憶メディア では保存密度や寿命が課題になると言われています。 磁気メディア：185 TB のテープ・カートリッジ（密度：10 GB／ mm3 程度） 光学メディア：1PBを格納できる光ディスクの実現可能性（密度：約100GB/ mm3 ） 回転ディスクの寿命：3～5年 テープの寿命：10～30年 その課題を解決する方法として、DNAストレージが注目されています。 バイオテク ノロ ジー の標準的な手法で実現可能 非常に高密度：理論的な限界値　1EB／ mm3 （テープの8倍） 長寿命：500年以上の 半減期 DNAベースの生命が存在する限り、DNAを読み取り、操作可能 DNAストレージによって、より高密度・長期保存が可能になると期待されています。 生物として生きていれば、生命が続く限りデータは保存される？ということになると思います。 DNAストレージの簡単な原理 ものすごく単 純化 すると、デジタルデータを0/1のビットで情報表現するものが、DNAストレージではそれをATGCの4種で表現するイメージになります。 大きな流れとしては、以下のとおりです。 デジタルデータをDNAの ヌクレオチド 配列に マッピング し、対応するDNA分子を合成し、保存する データの読み取りは、DNA分子の 塩基配列 を解読して、元のデジタルデータに戻す DNAストレージは読み取りに PCR やシークエンシングが必要となるため、超 アーカイブ 向けのストレージ（数時間から数日の アクセス時間 、高密度で耐久性）の特性があります。 具体例でみてみましょう。 最初のDNAストレージ 暗号表と 塩基配列 を マッピング して、「J U N E 6 I N V A S I O N : N O R M A N D Y」23文字をDNA上に保存し、読み取りにも成功したという報告です。 こちらの暗号表をもとに、英数字と 塩基配列 を対応させて、DNAに保存読み取りを実現しました。 DNAストレージの課題　（冗長性・エラー耐性 と ランダムアクセス） 冗長性・エラー耐性 DNAストレージでは、下記のようにDNAとしての物質に由来するエラーと劣化があります。 実用化をするためには、それに対応するための冗長性・エラー耐性の仕組みが必須となります。 DNAの合成と読み取りの不完全さ：DNA合成・シークエンシングではエラーが入ってしまう 塩基配列 は保存中に劣化する可能性 （データの完全性の欠損） ランダムアクセス DNAシークエンシングは、DNA全体に対して行う必要があるため、DNAストレージから1バイトでも読みだすには、DNA全体を解読（シークエンシング）する必要があります。 キーバリュー方式の格納法と PCR を組み合せ、必要なデータのみを増幅することで、ランダムアクセスを実現する方法が提案されています。 Bornholt, J. et al. (2016) の アーキテクチャ 最初の報告では、単純なものでしたが、ランダムアクセス等に対応した アーキテクチャ がこちらです。 書き込み処理 の流れ キーと値を入力 いわゆるKey- Value ストアのように保存するイメージになります キーは PCR プライマー配列、格納される場所 値はデータの値 DNA配列の生成 データアドレス、 ペイロード 、エラー検出コード等も符号化し、 PCR プライマーのターゲット配列を添付して、合成 できあがったDNAは、保存用ライブラリに格納 読み出し処理 の流れ 読み取りたいキーを入力し、物理的に抽出 キーの PCR プライマーを取得 保存されているデータを含むDNAプールからサンプルを物理的に抽出 （その中には無関係なデータも含まれている） PCR によりDNAを増幅し、シークエンシング キーに指定された PCR プライマーにより、目的のDNAだけが増幅される シークエンシングにより、デジタルデータの読み出し 必要であれば、DNAストレージの増幅 読み出し処理後、サンプルが減ってしまうため、必要に応じて PCR で複製を行う 実例：実際に保存されたデータ例 Bornholt (2016) では、 5kBから84kBまでの4つの画像ファイルを保存し、ランダムアクセスができることを確認しています 3つのファイルはエラーなしで復元できました。cat.jpgのみ、 JPEG ヘッダーに1バイトのエラーが発生しましたが、修正して参照できました。 最後に、バイオロ ジー × IT技術 の可能性！ 論文の最後に下記の言葉がありました。 Given the impending limits of silicon technology, we believe that hybrid silicon and biochemical systems are worth serious consideration: time is ripe for computer architects to consider incorporating biomolecules as an integral part of computer design. now is the time for the computer industry to borrow back from the biotechnology industry to advance the state of the art in computer systems. ムーアの法則 に限界がきていると言われるように、個人的には、既存の IT技術 の延長では限界があると思っています。 バイオ技術など、他の業界の技術を大胆に取り入れてブレイクスルーを目指すのは夢があります。 量子コンピュータ は 量子力学 をベースとしているように、バイオコンピュータの登場も夢ではないと思います。 執筆： @iida.michitaka 、レビュー： @sato.taichi （ Shodo で執筆されました ）

はじめまして、X イノベーション 本部 オープン イノベーション ラボの飯田です。 ISIDでは、有志で論文輪読会を実施しています。 tech.isid.co.jp 今回、その中で、私が読んだDNAストレージについてご紹介します。 DNAストレージという技術は、DNAを情報記録媒体として用いる技術です。 DNAの 塩基配列 をうまく活用することで、デジタルデータの読み書きが可能となります。 マイクロソフト 等が積極的に研究を行っているようです　( Microsoft Research：DNA Storage ) 輪読会では、以下2本の論文を紹介しました。 その内容を簡単にご紹介します。 Bornholt, J. et al. (2016) A DNA-based Archival Storage System DNAストレージが初登場したと言われる Clelland C. T. et al. (1999) Hiding messages in DNA microdots 前提知識 なぜDNAストレージ？ ビックデータ時代のストレージの課題とDNAストレージ DNAストレージの簡単な原理 最初のDNAストレージ DNAストレージの課題　（冗長性・エラー耐性 と ランダムアクセス） 冗長性・エラー耐性 ランダムアクセス Bornholt, J. et al. (2016) のアーキテクチャ 書き込み処理 の流れ 読み出し処理 の流れ 必要であれば、DNAストレージの増幅 実例：実際に保存されたデータ例 最後に、バイオロジー×IT技術の可能性！ 前提知識 DNA ヒトの細胞では、核の中の染色体にあり、A（アデニン）・T（チミン）・G（グアニン）・C（シトシン）の4種で構成されている。 DNA中ではAとT、GとCが結合していて、その結合の対を塩基対と言います。 DNA合成技術 狙った 塩基配列 でDNAを生み出す方法。DNAストレージではWriteに相当する手技。 シークエンシング DNAの構成成分であるATGC 4種の 塩基配列 を決定すること。 古典的なサンガー法から、NGSまでいくつかの手法がある。DNAストレージではReadに相当する手技。 なぜDNAストレージ？ ビックデータ時代のストレージの課題とDNAストレージ 現在のビックデータ時代、現状の 記憶メディア では保存密度や寿命が課題になると言われています。 磁気メディア：185 TB のテープ・カートリッジ（密度：10 GB／ mm3 程度） 光学メディア：1PBを格納できる光ディスクの実現可能性（密度：約100GB/ mm3 ） 回転ディスクの寿命：3～5年 テープの寿命：10～30年 その課題を解決する方法として、DNAストレージが注目されています。 バイオテク ノロ ジー の標準的な手法で実現可能 非常に高密度：理論的な限界値　1EB／ mm3 （テープの8倍） 長寿命：500年以上の 半減期 DNAベースの生命が存在する限り、DNAを読み取り、操作可能 DNAストレージによって、より高密度・長期保存が可能になると期待されています。 生物として生きていれば、生命が続く限りデータは保存される？ということになると思います。 DNAストレージの簡単な原理 ものすごく単 純化 すると、デジタルデータを0/1のビットで情報表現するものが、DNAストレージではそれをATGCの4種で表現するイメージになります。 大きな流れとしては、以下のとおりです。 デジタルデータをDNAの ヌクレオチド 配列に マッピング し、対応するDNA分子を合成し、保存する データの読み取りは、DNA分子の 塩基配列 を解読して、元のデジタルデータに戻す DNAストレージは読み取りに PCR やシークエンシングが必要となるため、超 アーカイブ 向けのストレージ（数時間から数日の アクセス時間 、高密度で耐久性）の特性があります。 具体例でみてみましょう。 最初のDNAストレージ 暗号表と 塩基配列 を マッピング して、「J U N E 6 I N V A S I O N : N O R M A N D Y」23文字をDNA上に保存し、読み取りにも成功したという報告です。 こちらの暗号表をもとに、英数字と 塩基配列 を対応させて、DNAに保存読み取りを実現しました。 DNAストレージの課題　（冗長性・エラー耐性 と ランダムアクセス） 冗長性・エラー耐性 DNAストレージでは、下記のようにDNAとしての物質に由来するエラーと劣化があります。 実用化をするためには、それに対応するための冗長性・エラー耐性の仕組みが必須となります。 DNAの合成と読み取りの不完全さ：DNA合成・シークエンシングではエラーが入ってしまう 塩基配列 は保存中に劣化する可能性 （データの完全性の欠損） ランダムアクセス DNAシークエンシングは、DNA全体に対して行う必要があるため、DNAストレージから1バイトでも読みだすには、DNA全体を解読（シークエンシング）する必要があります。 キーバリュー方式の格納法と PCR を組み合せ、必要なデータのみを増幅することで、ランダムアクセスを実現する方法が提案されています。 Bornholt, J. et al. (2016) の アーキテクチャ 最初の報告では、単純なものでしたが、ランダムアクセス等に対応した アーキテクチャ がこちらです。 書き込み処理 の流れ キーと値を入力 いわゆるKey- Value ストアのように保存するイメージになります キーは PCR プライマー配列、格納される場所 値はデータの値 DNA配列の生成 データアドレス、 ペイロード 、エラー検出コード等も符号化し、 PCR プライマーのターゲット配列を添付して、合成 できあがったDNAは、保存用ライブラリに格納 読み出し処理 の流れ 読み取りたいキーを入力し、物理的に抽出 キーの PCR プライマーを取得 保存されているデータを含むDNAプールからサンプルを物理的に抽出 （その中には無関係なデータも含まれている） PCR によりDNAを増幅し、シークエンシング キーに指定された PCR プライマーにより、目的のDNAだけが増幅される シークエンシングにより、デジタルデータの読み出し 必要であれば、DNAストレージの増幅 読み出し処理後、サンプルが減ってしまうため、必要に応じて PCR で複製を行う 実例：実際に保存されたデータ例 Bornholt (2016) では、 5kBから84kBまでの4つの画像ファイルを保存し、ランダムアクセスができることを確認しています 3つのファイルはエラーなしで復元できました。cat.jpgのみ、 JPEG ヘッダーに1バイトのエラーが発生しましたが、修正して参照できました。 最後に、バイオロ ジー × IT技術 の可能性！ 論文の最後に下記の言葉がありました。 Given the impending limits of silicon technology, we believe that hybrid silicon and biochemical systems are worth serious consideration: time is ripe for computer architects to consider incorporating biomolecules as an integral part of computer design. now is the time for the computer industry to borrow back from the biotechnology industry to advance the state of the art in computer systems. ムーアの法則 に限界がきていると言われるように、個人的には、既存の IT技術 の延長では限界があると思っています。 バイオ技術など、他の業界の技術を大胆に取り入れてブレイクスルーを目指すのは夢があります。 量子コンピュータ は 量子力学 をベースとしているように、バイオコンピュータの登場も夢ではないと思います。 執筆： @iida.michitaka 、レビュー： @sato.taichi （ Shodo で執筆されました ）

みなさんこんにちは、 電通国際情報サービス （ISID）コーポレート本部 システム推進部の佐藤太一です。 このエントリでは Google Dataflowを使ったデータ分析パイプライン構築において中心的な API の使い方について説明します。 Google Dataflowとはなにか Dataflowの開発環境構築 GradleによるDataflowプロジェクトの作り方 Apache Beamの基礎 Pipelineについて PCollectionについて ParDoを使った逐次処理の書き方 Dataflowによるユニットテストの書き方 フィルター フィルターのテスト 値の増幅処理 増幅処理のテスト PCollectionの分岐 PCollectionの分岐をテストする まとめ Google Dataflowとはなにか Google DataflowはいわゆるExtract/Transform/Load（ETL）ツールの一種です。 Apache Beam という バッチ処理 基盤を GCP の分散処理環境で動かしてくれます。 Apache Beam自体は、 Apache Flink や Apache Spark 、 Hazelcast Jet といったオンプレミスで動作する実行環境を利用することもできます。 Apache Beamでは、 Java や Python 、Goといった言語で処理を記述できますが、今回は Java を使って説明します。 Dataflowの開発環境構築 まずは、Dataflowの開発環境を作っていきましょう。 開発環境として使うマシンには、事前にJava17とGradle7.5以上をインストールしておいてください。 GradleによるDataflowプロジェクトの作り方 最初にプロジェクト全体を格納するための ディレクト リを作成しましょう。 ここからは、この記事内でシェルコマンドを実行するよう説明している部分では、必ずこのルート ディレクト リで実行してください。 作るプロジェクトは、説明のために dataflow-example とします。作った dataflow-example ディレクト リの中で、以下のコマンドを実行して最小限のプロジェクトを作成します。 gradle init --type basic --dsl kotlin --project-name dataflow-example --incubating 最小限とはいえ、Gradle Wrapperとなる シェルスクリプト やgit用の設定ファイルが生成されていますね。 この中から、 build.gradle.kts を以下のように編集します。 plugins { id("java") } group = "com.example.dataflow" version = "0.1.0-SNAPSHOT" java.toolchain { languageVersion.set(JavaLanguageVersion.of(17)) // 1. } repositories { mavenCentral() maven("https://packages.confluent.io/maven/") // 2. } dependencies { var beamVersion = "2.41.0" // 3. var slf4jVersion = "1.7.36" implementation(platform("com.google.cloud:libraries-bom:25.4.0")) // 4. implementation("org.apache.beam:beam-sdks-java-core:${beamVersion}") // 5. implementation("org.apache.beam:beam-sdks-java-io-google-cloud-platform:${beamVersion}") // 5. implementation("org.apache.beam:beam-runners-google-cloud-dataflow-java:${beamVersion}") // 5. implementation("org.apache.commons:commons-csv:1.9.0") implementation("org.slf4j:slf4j-api:${slf4jVersion}") implementation("org.slf4j:slf4j-jdk14:${slf4jVersion}") testImplementation("junit:junit:4.13.2") // 6. testImplementation("org.apache.beam:beam-runners-direct-java:${beamVersion}") // 7. } tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } このビルド スクリプト で利用する コンパイラ やランタイムのバージョン番号を指定しています。 Gradleを実行している Java ランタイムのバージョンが開発者ごとにズレていても、 コンパイル やテストに使う Java ランタイムは統一できるということです。ビルドの再現性が高まりますので必ず設定しましょう。 この機能を使うと、必要に応じてGradleがビルド済みの JDK を自動的にダウンロードしてくれます。 デフォルトでは Adoptium を使います。 依存ライブラリをダウンロードする先を宣言しています。 最初に指定しているのは Maven のデフォルト アーティファクト リポジトリ である Maven Central Repository です。 二つ目に指定しているのはconfluentが公開している リポジトリ です。これはKafka関連のライブラリで、この リポジトリ 内にしかないものがあるからです。 Apache Beamのバージョンを参照する依存性がいくつかあるので、ここでは変数として切り出しています。 Dataflowを動かすために必要な GCP の SDK に対する依存性を宣言しています。 GradleのPlatform機能 を使っていますね。 Apache Beamに対する依存性を宣言しています。後半の二つは GCP でBeamを動かすために必要な依存性です。 ユニットテスト 用の依存性としてJUnit4を指定しています。 JUnit の最新版はJUnit5系ですが、記事執筆時点において Apache BeamはJUnit5をサポートしていません。cf. JUnit5 support Apache Beam用の ユニットテスト ライブラリに対する依存性を宣言しています。 これでDataflow用のローカルビルド環境の構築は完了です。 Apache Beamの基礎 Apache Beamを理解するなら、まずはPipelineとPCollectionをしっかり理解してください。 他のコンセプトについては、Dataflowのドキュメントを参照してください。 * Apache Beam のプログラミング モデル Pipelineについて Pipelineは複数のステップから構成される処理全体を表すオブジェクトで、データの読み取り処理から始まりフィルターや変換を経て、出力処理までを行います。一つのパイプラインが一つのジョブとなります。 Pipelineを構成する各ステップは、実行環境が必要に応じて分散処理してくれます。つまり、各ステップを効率よく動作させるには、それぞれのステップが全く違ったプロセスの上で非同期に実行されても問題がおきないようにしましょう。 具体的には、処理単位になるデータの独立性をできるかぎり高めるようにします。つまり、 RDB における非正規化を積極的に行うようなデータの持ち方をします。 順序に強い整合性を求める書き方もできますが、そうすると分散処理環境がもつ性能を十分に引き出せません。 PCollectionについて PCollectionはPipelineを流れるデータの集合を表すオブジェクトです。 逐次的に要素を扱えるので Java のCollection Frameworkと似ていますが、PCollectionの API だけではデータの開始と終了を明示的に調べられません。 また、PCollectionに格納されている要素は、分散処理環境内における実行環境の都合で シリアライズ されたりコピーされる可能性があります。つまり、処理に必要な情報は全て要素内に内包する必要があります。 ParDoを使った逐次処理の書き方 基本的な概念が分かった所で本題に入っていきましょう。 最初に作るのは、PCollectionを流れる要素を1:1で変換していく処理です。 この図は四角い枠がPCollectionで、〇が各要素、矢印が処理です。つまり、全体がPipelineとなります。 今回の記事では、全てのコードをテストコードとして実装しますので、以下のように ディレクト リを作成します。 mkdir src/test/java/com/example/dataflow 出来た ディレクト リに CsvFn.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.transforms.DoFn; import java.util.*; public class CsvFn extends DoFn<String, List<String>> { // 1. @ProcessElement // 2. public void processElement(ProcessContext c) throws Exception { // 3. var element = c.element(); // 4. var list = Arrays.asList(element.split(",")); // 5. c.output(list); // 6. } } この処理では、単一の文字列を入力すると、それをカンマ区切りで分割したリストとして後続の処理に引き渡します。 逐次処理を実装する際に使うクラスは DoFn を継承します。 一つ目の型パラメータは、各入力要素を表す型を設定します。ここでは String を設定しています。 二つ目の型パラメータは、各出力要素を表す型を設定します。ここでは List<String> を設定しています。 逐次処理を行うメソッドは @ProcessElement アノテーション を付与します。 逐次処理を行うメソッドのアクセス修飾子は public 、戻り値は void です。送出される例外としては Exception を定義しておきます。 なお、このメソッドの中から例外を送出するとジョブ全体が停止します。 ProcessContext の element メソッドを呼ぶと、 DoFn を継承する際に設定した一番目の型パラメータの変数が得られます。ここでは String 型の変数が得られるわけです。 String の split メソッドを呼びだして得られた配列を List に格納しています。 ProcessContext の output メソッドを呼ぶ際には、 DoFn を継承する際に設定した二番目の型パラメータの変数を渡します。ここでは既に作成済みの list を渡していますね。 Dataflowによる ユニットテスト の書き方 次は、逐次処理を ユニットテスト してみましょう。 CsvFn.java と同じ ディレクト リ内に CsvFnTest.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.testing.*; import org.apache.beam.sdk.transforms.*; import org.junit.*; import org.junit.runner.RunWith; import org.junit.runners.JUnit4; import java.util.List; @RunWith(JUnit4.class) public class CsvFnTest { static final List<String> values = List.of( "foo,bar,baz", "fo1,ba2,ba3", "ba1,ba2,ba3"); @Rule public TestPipeline pipeline = TestPipeline.create(); // 1. @Test public void testSimplePipeline() throws Exception { var output = pipeline .apply(Create.of(values)) // 2. .apply(ParDo.of(new CsvFn())); // 3. PAssert.that(output).containsInAnyOrder( // 4. List.of("foo", "bar", "baz"), List.of("ba1", "ba2", "ba3"), // 5. List.of("fo1", "ba2", "ba3") ); pipeline.run().waitUntilFinish(); // 6. } } ユニットテスト 用のパイプラインを生成しています。パイプラインを構成するための共通処理があるので @Rule を付与しています。 Create の of メソッドを使って文字列のリストをパイプラインに流せる形に変換しています。ここでは、 List の各要素がパイプラインを流れていきます。 ParDo の of メソッドに先ほど実装した CsvFn を インスタンス 化して渡しています。これによって、パイプラインを流れる各要素ごとに CsvFn の processElement メソッドが呼びだされます。 パイプラインを流れる要素が正しく変換されているか確認するには、 Apache Beamで用意されている専用の PAssert を使います。ここでは containsInAnyOrder メソッドを使ってそれぞれの要素が正しくカンマ区切りで分解されたか確認しています。 values 変数として定義した要素の順序とは違った順序で要素を検証しています。これは、パイプラインを流れる要素の処理順序は保証されておらず、実行環境の都合で任意に入れ替わる可能性があることを意図しています。つまり、 Create の of メソッドで作った要素がそのままの順序で CsvFn の processElement メソッドに入ってくるとは限りません。 TestPipeline の run メソッドを呼びだした上で、さらに waitUntilFinish メソッドを呼んでパイプラインの処理が終わるのを待っています。デバッガで実行する際に注意してほしいのは、この時点で初めてパイプラインの処理が動き始めることです。つまり、 4. の時点では、まだ CsvFn の processElement メソッドは呼びだされません。 フィルター CsvFnでは単純な1:1の変換処理を実装しましたので、次はフィルター処理を実装してみましょう。 フィルター処理として作るのは、指定した長さよりも長い文字列だけを後続の処理に流すフィルターです。 CsvFn.java と同じ ディレクト リ内に FilterFn.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.transforms.DoFn; public class FilterFn extends DoFn<String, String> { // 1. final int size; // 2. public FilterFn(int size) { this.size = size; } @ProcessElement public void processElement(ProcessContext c) { var element = c.element(); if (size < element.length()) { // 3. c.output(element); } } } ここで実装するのはフィルター処理なので、入力と出力の型は同じです。 コンスト ラク タで受け取った長さをメンバ変数として格納しています。 Apache BeamではPCollectionの要素だけでなく、各処理のステップを表すオブジェクトも実行環境の都合で直列化される可能性があります。つまり、メンバ変数としてはSerializableな型（もしくは、Externalizableな型）だけを定義できます。 条件分岐に基づいて ProcessContext の output メソッドを呼びだすかどうかを決めています。 フィルターのテスト では、フィルター処理を ユニットテスト してみましょう。 CsvFn.java と同じ ディレクト リ内に FilterFnTest.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.testing.*; import org.apache.beam.sdk.transforms.*; import org.junit.*; import org.junit.runner.RunWith; import org.junit.runners.JUnit4; import java.util.List; @RunWith(JUnit4.class) public class FilterFnTest { static final List<String> values = List.of( "alpha", "beta", "gamma"); @Rule public TestPipeline pipeline = TestPipeline.create(); @Test public void testSimplePipeline() throws Exception { var output = pipeline .apply(Create.of(values)) .apply(ParDo.of(new FilterFn(4))); PAssert.that(output).containsInAnyOrder("gamma", "alpha"); pipeline.run().waitUntilFinish(); } } 長さが4文字より大きい単語をフィルターできていますね。 値の増幅処理 次は、一つの入力から複数回の出力を行う処理を実装してみましょう。 増幅処理として作るのは、文字列をカンマ区切りで分割した各要素をそのまま後続に渡す処理です。 CsvFn.java と同じ ディレクト リ内に FlatValuesFn.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.transforms.DoFn; import java.util.Arrays; public class FlatValuesFn extends DoFn<String, String> { // 1. @ProcessElement public void processElement(ProcessContext c) { var element = c.element(); var list = Arrays.asList(element.split(",")); list.forEach(c::output); // 2. } } ここで実装するのは増幅処理なので、入力と出力の型は同じです。 文字列を分割して得られた要素全てについて ProcessContext の ouput メソッドを呼びだしています。 増幅処理のテスト では、増幅処理を ユニットテスト してみましょう。 CsvFn.java と同じ ディレクト リ内に FlatValuesFnTest.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.testing.*; import org.apache.beam.sdk.transforms.*; import org.junit.*; import org.junit.runner.RunWith; import org.junit.runners.JUnit4; import java.util.List; @RunWith(JUnit4.class) public class FlatValuesFnTest { static final List<String> values = List.of( "foo,bar,baz", "fo1,ba2,ba3", "ba1,ba2,ba3"); @Rule public TestPipeline pipeline = TestPipeline.create(); @Test public void testSimplePipeline() throws Exception { var output = pipeline .apply(Create.of(values)) .apply(ParDo.of(new FlatValuesFn())); PAssert.that(output).containsInAnyOrder( "foo", "bar", "baz", "ba1", "ba2", "ba3", "fo1", "ba2", "ba3" ); pipeline.run().waitUntilFinish(); } } カンマ区切りで3つずつに分割できる要素を3回 FlatValuesFn で処理したので9つの要素が出力されていますね。 PCollectionの分岐 ここまでの処理では、処理の流れであるPCollection自体は1つのまま要素が流れていきました。 しかし、データの1カラム目だけを見て後続の処理を切り替えるといった処理構造を実現したくなることはあります。 ここでは、入力された文字列の1文字目を使って後続の処理を切り替えるためにPCollectionを分岐してみましょう。 CsvFn.java と同じ ディレクト リ内に BranchFn.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.transforms.DoFn; import org.apache.beam.sdk.values.TupleTag; import java.util.*; public class BranchFn extends DoFn<String, List<String>> { static final TupleTag<List<String>> MAIN = new TupleTag<>() { // 1. }; static final TupleTag<List<String>> SUB = new TupleTag<>() { }; @ProcessElement public void processElement(ProcessContext c) { var element = c.element(); var list = Arrays.asList(element.split(",")); if (list.get(0).equals("M")) { c.output(MAIN, list.subList(1, list.size()));　　　　　　　// 2. } else { c.output(SUB, list.subList(1, list.size())); } } } TupleTag は実行環境全体で一意のIDを付与する必要があります。ここでは、ややトリッキーなテクニックを使ってそれを実現しています。コンスト ラク タ呼び出しの後ろについている中括弧 {} によってインナークラスを作成していることがポイントです。実装の詳細が気になる方は是非コードを読んでみてください。 ProcessContext の ouput メソッドを呼びだす際に、 TupleTag を渡しています。これによって各要素にタグ付けをすることで、PCollectionの分岐を実現しているのです。 PCollectionの分岐をテストする では、分岐したPCollectionをどのように扱うのかテストコードで確認してみましょう。 CsvFn.java と同じ ディレクト リ内に BranchFnTest.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.testing.*; import org.apache.beam.sdk.transforms.*; import org.apache.beam.sdk.values.TupleTagList; import org.junit.*; import org.junit.runner.RunWith; import org.junit.runners.JUnit4; import java.util.List; @RunWith(JUnit4.class) public class BranchFnTest { static final List<String> values = List.of( "M,foo,bar,baz", "S,fo1,ba2,ba3", "M,ba1,ba2,ba3"); // 1. @Rule public TestPipeline pipeline = TestPipeline.create(); @Test public void testSimplePipeline() throws Exception { var output = pipeline .apply(Create.of(values)) .apply(ParDo.of(new BranchFn()) .withOutputTags(BranchFn.MAIN, TupleTagList.of(List.of(BranchFn.SUB))) // 2. ); PAssert.that(output.get(BranchFn.MAIN)).containsInAnyOrder( // 3. List.of("foo", "bar", "baz"), List.of("ba1", "ba2", "ba3") ); PAssert.that(output.get(BranchFn.SUB)).containsInAnyOrder( // 4. List.of("fo1", "ba2", "ba3") ); pipeline.run().waitUntilFinish(); } } テストデータとして、各要素の先頭に分岐の条件となる M や S を配置しています。 ParDo の of メソッドを呼びだして得られた変数に対して、 withOutputTags を呼びだすことでこのパイプラインが分岐することを宣言しています。 ここでは二つに分岐していますが、三つや四つ、それよりも多くのPCollectionに分岐できます。 分岐されたパイプラインから MAIN でタグ付けされた PCollection を取り出しています。 1. では文字列の先頭が M になっているものがこれにあたります。 分岐されたパイプラインから SUB でタグ付けされた PCollection を取り出しています。 1. では文字列の先頭が S になっているものがこれにあたります。 まとめ Apache Beamを使った バッチ処理 を書く上で最も汎用性の高い ParDo を使ったスタイルをいくつか紹介しました。 今日紹介したスタイルは、それぞれ専用の API が用意されていますが、必要に応じて API を覚えなおすのはやや面倒です。 例えば、型を1:1で変換するなら、 MapElements という専用の API があります。フィルターしたいなら Filter があります。 ParDo には、この記事では紹介しきれなかった便利な機能が他にもありますので是非試してみてください。 Google Dataflowは非常に巨大なデータを バッチ処理 するための実 行基 盤として非常に安価に利用できる上にハイパフォーマンスに動作する環境です。 例えば、筆者の業務ではGCSにおいたログファイルをBigQueryへ投入する手段としてDataflowを利用しています。テラバイトクラスのログファイルが分散処理によって数十分でDBに投入されていく様子は圧巻というほかありません。 この記事を読んだ皆様がDataflowを使って、筆者が受けた感銘を共有していただけたら非常に嬉しいです。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募をお待ちしています。 社内SE(DX推進エンジニア) 執筆： @sato.taichi 、レビュー： @handa.kenta （ Shodo で執筆されました ）

みなさんこんにちは、 電通国際情報サービス （ISID）コーポレート本部 システム推進部の佐藤太一です。 このエントリでは Google Dataflowを使ったデータ分析パイプライン構築において中心的な API の使い方について説明します。 Google Dataflowとはなにか Dataflowの開発環境構築 GradleによるDataflowプロジェクトの作り方 Apache Beamの基礎 Pipelineについて PCollectionについて ParDoを使った逐次処理の書き方 Dataflowによるユニットテストの書き方 フィルター フィルターのテスト 値の増幅処理 増幅処理のテスト PCollectionの分岐 PCollectionの分岐をテストする まとめ Google Dataflowとはなにか Google DataflowはいわゆるExtract/Transform/Load（ETL）ツールの一種です。 Apache Beam という バッチ処理 基盤を GCP の分散処理環境で動かしてくれます。 Apache Beam自体は、 Apache Flink や Apache Spark 、 Hazelcast Jet といったオンプレミスで動作する実行環境を利用することもできます。 Apache Beamでは、 Java や Python 、Goといった言語で処理を記述できますが、今回は Java を使って説明します。 Dataflowの開発環境構築 まずは、Dataflowの開発環境を作っていきましょう。 開発環境として使うマシンには、事前にJava17とGradle7.5以上をインストールしておいてください。 GradleによるDataflowプロジェクトの作り方 最初にプロジェクト全体を格納するための ディレクト リを作成しましょう。 ここからは、この記事内でシェルコマンドを実行するよう説明している部分では、必ずこのルート ディレクト リで実行してください。 作るプロジェクトは、説明のために dataflow-example とします。作った dataflow-example ディレクト リの中で、以下のコマンドを実行して最小限のプロジェクトを作成します。 gradle init --type basic --dsl kotlin --project-name dataflow-example --incubating 最小限とはいえ、Gradle Wrapperとなる シェルスクリプト やgit用の設定ファイルが生成されていますね。 この中から、 build.gradle.kts を以下のように編集します。 plugins { id("java") } group = "com.example.dataflow" version = "0.1.0-SNAPSHOT" java.toolchain { languageVersion.set(JavaLanguageVersion.of(17)) // 1. } repositories { mavenCentral() maven("https://packages.confluent.io/maven/") // 2. } dependencies { var beamVersion = "2.41.0" // 3. var slf4jVersion = "1.7.36" implementation(platform("com.google.cloud:libraries-bom:25.4.0")) // 4. implementation("org.apache.beam:beam-sdks-java-core:${beamVersion}") // 5. implementation("org.apache.beam:beam-sdks-java-io-google-cloud-platform:${beamVersion}") // 5. implementation("org.apache.beam:beam-runners-google-cloud-dataflow-java:${beamVersion}") // 5. implementation("org.apache.commons:commons-csv:1.9.0") implementation("org.slf4j:slf4j-api:${slf4jVersion}") implementation("org.slf4j:slf4j-jdk14:${slf4jVersion}") testImplementation("junit:junit:4.13.2") // 6. testImplementation("org.apache.beam:beam-runners-direct-java:${beamVersion}") // 7. } tasks.withType<JavaCompile>().configureEach { options.encoding = "UTF-8" } このビルド スクリプト で利用する コンパイラ やランタイムのバージョン番号を指定しています。 Gradleを実行している Java ランタイムのバージョンが開発者ごとにズレていても、 コンパイル やテストに使う Java ランタイムは統一できるということです。ビルドの再現性が高まりますので必ず設定しましょう。 この機能を使うと、必要に応じてGradleがビルド済みの JDK を自動的にダウンロードしてくれます。 デフォルトでは Adoptium を使います。 依存ライブラリをダウンロードする先を宣言しています。 最初に指定しているのは Maven のデフォルト アーティファクト リポジトリ である Maven Central Repository です。 二つ目に指定しているのはconfluentが公開している リポジトリ です。これはKafka関連のライブラリで、この リポジトリ 内にしかないものがあるからです。 Apache Beamのバージョンを参照する依存性がいくつかあるので、ここでは変数として切り出しています。 Dataflowを動かすために必要な GCP の SDK に対する依存性を宣言しています。 GradleのPlatform機能 を使っていますね。 Apache Beamに対する依存性を宣言しています。後半の二つは GCP でBeamを動かすために必要な依存性です。 ユニットテスト 用の依存性としてJUnit4を指定しています。 JUnit の最新版はJUnit5系ですが、記事執筆時点において Apache BeamはJUnit5をサポートしていません。cf. JUnit5 support Apache Beam用の ユニットテスト ライブラリに対する依存性を宣言しています。 これでDataflow用のローカルビルド環境の構築は完了です。 Apache Beamの基礎 Apache Beamを理解するなら、まずはPipelineとPCollectionをしっかり理解してください。 他のコンセプトについては、Dataflowのドキュメントを参照してください。 * Apache Beam のプログラミング モデル Pipelineについて Pipelineは複数のステップから構成される処理全体を表すオブジェクトで、データの読み取り処理から始まりフィルターや変換を経て、出力処理までを行います。一つのパイプラインが一つのジョブとなります。 Pipelineを構成する各ステップは、実行環境が必要に応じて分散処理してくれます。つまり、各ステップを効率よく動作させるには、それぞれのステップが全く違ったプロセスの上で非同期に実行されても問題がおきないようにしましょう。 具体的には、処理単位になるデータの独立性をできるかぎり高めるようにします。つまり、 RDB における非正規化を積極的に行うようなデータの持ち方をします。 順序に強い整合性を求める書き方もできますが、そうすると分散処理環境がもつ性能を十分に引き出せません。 PCollectionについて PCollectionはPipelineを流れるデータの集合を表すオブジェクトです。 逐次的に要素を扱えるので Java のCollection Frameworkと似ていますが、PCollectionの API だけではデータの開始と終了を明示的に調べられません。 また、PCollectionに格納されている要素は、分散処理環境内における実行環境の都合で シリアライズ されたりコピーされる可能性があります。つまり、処理に必要な情報は全て要素内に内包する必要があります。 ParDoを使った逐次処理の書き方 基本的な概念が分かった所で本題に入っていきましょう。 最初に作るのは、PCollectionを流れる要素を1:1で変換していく処理です。 この図は四角い枠がPCollectionで、〇が各要素、矢印が処理です。つまり、全体がPipelineとなります。 今回の記事では、全てのコードをテストコードとして実装しますので、以下のように ディレクト リを作成します。 mkdir src/test/java/com/example/dataflow 出来た ディレクト リに CsvFn.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.transforms.DoFn; import java.util.*; public class CsvFn extends DoFn<String, List<String>> { // 1. @ProcessElement // 2. public void processElement(ProcessContext c) throws Exception { // 3. var element = c.element(); // 4. var list = Arrays.asList(element.split(",")); // 5. c.output(list); // 6. } } この処理では、単一の文字列を入力すると、それをカンマ区切りで分割したリストとして後続の処理に引き渡します。 逐次処理を実装する際に使うクラスは DoFn を継承します。 一つ目の型パラメータは、各入力要素を表す型を設定します。ここでは String を設定しています。 二つ目の型パラメータは、各出力要素を表す型を設定します。ここでは List<String> を設定しています。 逐次処理を行うメソッドは @ProcessElement アノテーション を付与します。 逐次処理を行うメソッドのアクセス修飾子は public 、戻り値は void です。送出される例外としては Exception を定義しておきます。 なお、このメソッドの中から例外を送出するとジョブ全体が停止します。 ProcessContext の element メソッドを呼ぶと、 DoFn を継承する際に設定した一番目の型パラメータの変数が得られます。ここでは String 型の変数が得られるわけです。 String の split メソッドを呼びだして得られた配列を List に格納しています。 ProcessContext の output メソッドを呼ぶ際には、 DoFn を継承する際に設定した二番目の型パラメータの変数を渡します。ここでは既に作成済みの list を渡していますね。 Dataflowによる ユニットテスト の書き方 次は、逐次処理を ユニットテスト してみましょう。 CsvFn.java と同じ ディレクト リ内に CsvFnTest.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.testing.*; import org.apache.beam.sdk.transforms.*; import org.junit.*; import org.junit.runner.RunWith; import org.junit.runners.JUnit4; import java.util.List; @RunWith(JUnit4.class) public class CsvFnTest { static final List<String> values = List.of( "foo,bar,baz", "fo1,ba2,ba3", "ba1,ba2,ba3"); @Rule public TestPipeline pipeline = TestPipeline.create(); // 1. @Test public void testSimplePipeline() throws Exception { var output = pipeline .apply(Create.of(values)) // 2. .apply(ParDo.of(new CsvFn())); // 3. PAssert.that(output).containsInAnyOrder( // 4. List.of("foo", "bar", "baz"), List.of("ba1", "ba2", "ba3"), // 5. List.of("fo1", "ba2", "ba3") ); pipeline.run().waitUntilFinish(); // 6. } } ユニットテスト 用のパイプラインを生成しています。パイプラインを構成するための共通処理があるので @Rule を付与しています。 Create の of メソッドを使って文字列のリストをパイプラインに流せる形に変換しています。ここでは、 List の各要素がパイプラインを流れていきます。 ParDo の of メソッドに先ほど実装した CsvFn を インスタンス 化して渡しています。これによって、パイプラインを流れる各要素ごとに CsvFn の processElement メソッドが呼びだされます。 パイプラインを流れる要素が正しく変換されているか確認するには、 Apache Beamで用意されている専用の PAssert を使います。ここでは containsInAnyOrder メソッドを使ってそれぞれの要素が正しくカンマ区切りで分解されたか確認しています。 values 変数として定義した要素の順序とは違った順序で要素を検証しています。これは、パイプラインを流れる要素の処理順序は保証されておらず、実行環境の都合で任意に入れ替わる可能性があることを意図しています。つまり、 Create の of メソッドで作った要素がそのままの順序で CsvFn の processElement メソッドに入ってくるとは限りません。 TestPipeline の run メソッドを呼びだした上で、さらに waitUntilFinish メソッドを呼んでパイプラインの処理が終わるのを待っています。デバッガで実行する際に注意してほしいのは、この時点で初めてパイプラインの処理が動き始めることです。つまり、 4. の時点では、まだ CsvFn の processElement メソッドは呼びだされません。 フィルター CsvFnでは単純な1:1の変換処理を実装しましたので、次はフィルター処理を実装してみましょう。 フィルター処理として作るのは、指定した長さよりも長い文字列だけを後続の処理に流すフィルターです。 CsvFn.java と同じ ディレクト リ内に FilterFn.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.transforms.DoFn; public class FilterFn extends DoFn<String, String> { // 1. final int size; // 2. public FilterFn(int size) { this.size = size; } @ProcessElement public void processElement(ProcessContext c) { var element = c.element(); if (size < element.length()) { // 3. c.output(element); } } } ここで実装するのはフィルター処理なので、入力と出力の型は同じです。 コンスト ラク タで受け取った長さをメンバ変数として格納しています。 Apache BeamではPCollectionの要素だけでなく、各処理のステップを表すオブジェクトも実行環境の都合で直列化される可能性があります。つまり、メンバ変数としてはSerializableな型（もしくは、Externalizableな型）だけを定義できます。 条件分岐に基づいて ProcessContext の output メソッドを呼びだすかどうかを決めています。 フィルターのテスト では、フィルター処理を ユニットテスト してみましょう。 CsvFn.java と同じ ディレクト リ内に FilterFnTest.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.testing.*; import org.apache.beam.sdk.transforms.*; import org.junit.*; import org.junit.runner.RunWith; import org.junit.runners.JUnit4; import java.util.List; @RunWith(JUnit4.class) public class FilterFnTest { static final List<String> values = List.of( "alpha", "beta", "gamma"); @Rule public TestPipeline pipeline = TestPipeline.create(); @Test public void testSimplePipeline() throws Exception { var output = pipeline .apply(Create.of(values)) .apply(ParDo.of(new FilterFn(4))); PAssert.that(output).containsInAnyOrder("gamma", "alpha"); pipeline.run().waitUntilFinish(); } } 長さが4文字より大きい単語をフィルターできていますね。 値の増幅処理 次は、一つの入力から複数回の出力を行う処理を実装してみましょう。 増幅処理として作るのは、文字列をカンマ区切りで分割した各要素をそのまま後続に渡す処理です。 CsvFn.java と同じ ディレクト リ内に FlatValuesFn.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.transforms.DoFn; import java.util.Arrays; public class FlatValuesFn extends DoFn<String, String> { // 1. @ProcessElement public void processElement(ProcessContext c) { var element = c.element(); var list = Arrays.asList(element.split(",")); list.forEach(c::output); // 2. } } ここで実装するのは増幅処理なので、入力と出力の型は同じです。 文字列を分割して得られた要素全てについて ProcessContext の ouput メソッドを呼びだしています。 増幅処理のテスト では、増幅処理を ユニットテスト してみましょう。 CsvFn.java と同じ ディレクト リ内に FlatValuesFnTest.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.testing.*; import org.apache.beam.sdk.transforms.*; import org.junit.*; import org.junit.runner.RunWith; import org.junit.runners.JUnit4; import java.util.List; @RunWith(JUnit4.class) public class FlatValuesFnTest { static final List<String> values = List.of( "foo,bar,baz", "fo1,ba2,ba3", "ba1,ba2,ba3"); @Rule public TestPipeline pipeline = TestPipeline.create(); @Test public void testSimplePipeline() throws Exception { var output = pipeline .apply(Create.of(values)) .apply(ParDo.of(new FlatValuesFn())); PAssert.that(output).containsInAnyOrder( "foo", "bar", "baz", "ba1", "ba2", "ba3", "fo1", "ba2", "ba3" ); pipeline.run().waitUntilFinish(); } } カンマ区切りで3つずつに分割できる要素を3回 FlatValuesFn で処理したので9つの要素が出力されていますね。 PCollectionの分岐 ここまでの処理では、処理の流れであるPCollection自体は1つのまま要素が流れていきました。 しかし、データの1カラム目だけを見て後続の処理を切り替えるといった処理構造を実現したくなることはあります。 ここでは、入力された文字列の1文字目を使って後続の処理を切り替えるためにPCollectionを分岐してみましょう。 CsvFn.java と同じ ディレクト リ内に BranchFn.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.transforms.DoFn; import org.apache.beam.sdk.values.TupleTag; import java.util.*; public class BranchFn extends DoFn<String, List<String>> { static final TupleTag<List<String>> MAIN = new TupleTag<>() { // 1. }; static final TupleTag<List<String>> SUB = new TupleTag<>() { }; @ProcessElement public void processElement(ProcessContext c) { var element = c.element(); var list = Arrays.asList(element.split(",")); if (list.get(0).equals("M")) { c.output(MAIN, list.subList(1, list.size()));　　　　　　　// 2. } else { c.output(SUB, list.subList(1, list.size())); } } } TupleTag は実行環境全体で一意のIDを付与する必要があります。ここでは、ややトリッキーなテクニックを使ってそれを実現しています。コンスト ラク タ呼び出しの後ろについている中括弧 {} によってインナークラスを作成していることがポイントです。実装の詳細が気になる方は是非コードを読んでみてください。 ProcessContext の ouput メソッドを呼びだす際に、 TupleTag を渡しています。これによって各要素にタグ付けをすることで、PCollectionの分岐を実現しているのです。 PCollectionの分岐をテストする では、分岐したPCollectionをどのように扱うのかテストコードで確認してみましょう。 CsvFn.java と同じ ディレクト リ内に BranchFnTest.java というファイルを以下の内容で作成します。 package com.example.dataflow; import org.apache.beam.sdk.testing.*; import org.apache.beam.sdk.transforms.*; import org.apache.beam.sdk.values.TupleTagList; import org.junit.*; import org.junit.runner.RunWith; import org.junit.runners.JUnit4; import java.util.List; @RunWith(JUnit4.class) public class BranchFnTest { static final List<String> values = List.of( "M,foo,bar,baz", "S,fo1,ba2,ba3", "M,ba1,ba2,ba3"); // 1. @Rule public TestPipeline pipeline = TestPipeline.create(); @Test public void testSimplePipeline() throws Exception { var output = pipeline .apply(Create.of(values)) .apply(ParDo.of(new BranchFn()) .withOutputTags(BranchFn.MAIN, TupleTagList.of(List.of(BranchFn.SUB))) // 2. ); PAssert.that(output.get(BranchFn.MAIN)).containsInAnyOrder( // 3. List.of("foo", "bar", "baz"), List.of("ba1", "ba2", "ba3") ); PAssert.that(output.get(BranchFn.SUB)).containsInAnyOrder( // 4. List.of("fo1", "ba2", "ba3") ); pipeline.run().waitUntilFinish(); } } テストデータとして、各要素の先頭に分岐の条件となる M や S を配置しています。 ParDo の of メソッドを呼びだして得られた変数に対して、 withOutputTags を呼びだすことでこのパイプラインが分岐することを宣言しています。 ここでは二つに分岐していますが、三つや四つ、それよりも多くのPCollectionに分岐できます。 分岐されたパイプラインから MAIN でタグ付けされた PCollection を取り出しています。 1. では文字列の先頭が M になっているものがこれにあたります。 分岐されたパイプラインから SUB でタグ付けされた PCollection を取り出しています。 1. では文字列の先頭が S になっているものがこれにあたります。 まとめ Apache Beamを使った バッチ処理 を書く上で最も汎用性の高い ParDo を使ったスタイルをいくつか紹介しました。 今日紹介したスタイルは、それぞれ専用の API が用意されていますが、必要に応じて API を覚えなおすのはやや面倒です。 例えば、型を1:1で変換するなら、 MapElements という専用の API があります。フィルターしたいなら Filter があります。 ParDo には、この記事では紹介しきれなかった便利な機能が他にもありますので是非試してみてください。 Google Dataflowは非常に巨大なデータを バッチ処理 するための実 行基 盤として非常に安価に利用できる上にハイパフォーマンスに動作する環境です。 例えば、筆者の業務ではGCSにおいたログファイルをBigQueryへ投入する手段としてDataflowを利用しています。テラバイトクラスのログファイルが分散処理によって数十分でDBに投入されていく様子は圧巻というほかありません。 この記事を読んだ皆様がDataflowを使って、筆者が受けた感銘を共有していただけたら非常に嬉しいです。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募をお待ちしています。 社内SE(DX推進エンジニア) 執筆： @sato.taichi 、レビュー： @handa.kenta （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、長い呪文は切り捨てられる編です。 からあげさんの Stable Diffusionの内容を理解するための情報・書籍の記事 の中に出てくる 最初の75個分以降の文章は、バッサリ捨てられてしまう記事 をみて、自分でも検証してみたのが今回の記事です。 これまで、意味のある区切りとして、カンマ（,）を使っていたのですが、カンマ（,）は75個の トーク ンの一つとして重複して数えられ、カンマ（,）を削っても出力結果はほとんど変わらないことを知って愕然としました。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 tokenizer 75個を超えるトークンは切り捨てられるのか 呪文のカンマを削っても出力結果に影響はないのか まとめ 仲間募集 Stable Diffusionの過去コンテンツ tokenizer 呪文を トーク ンに分解するには、tokenizerを作成します。必要なライブラリは次のようにインストールします。今回は、Notebookの例です。 !pip install transformers ftfy regex tokenizerの作成は次のように行います。 from transformers import CLIPTokenizer tokenizer = CLIPTokenizer.from_pretrained("openai/clip-vit-large-patch14") 呪文を トーク ンに分解するには、次のように行います。 prompt = "anime of beautiful girl, detailed beautiful face, detailed hair, detailed perfect pupil of eyes, detailed cute mouth, detailed shoulders, detailed bust" tokens = tokenizer.tokenize(prompt) print(len(tokens), tokens[0:tokenizer.model_max_length-2]) トーク ン出力結果（改行版） 37 ['japanese</w>', 'anime</w>', 'of</w>', 'beautiful</w>', 'girl</w>', ',</w>', 'detailed</w>', 'beautiful</w>', 'face</w>', ',</w>', 'detailed</w>', 'hair</w>', ',</w>', 'detailed</w>', 'perfect</w>', 'pupil</w>', 'of</w>', 'eyes</w>', ',</w>', 'detailed</w>', 'cute</w>', 'mouth</w>', ',</w>', 'detailed</w>', 'shoulders</w>', ',</w>', 'detailed</w>', 'bust</w>'] 37の トーク ンに分解されたことがわかります。',＜/w＞'に注目してください。これは、カンマ（,）です。カンマ（,）も トーク ンの一つにカウントされていることがわかります。 僕が実験した限り、カンマ（,）ありなしで、出力される結果に違いはありません。75個を超える トーク ンは切り捨てられることを考えると、カンマ（,）は呪文に含めないのが良いでしょう。 75個を超える トーク ンは切り捨てられるのか それでは、本当に「75個を超える トーク ンは切り捨てられるのか」実験してみましょう。 下記のようなちょうど75個の トーク ンの呪文を用意します。 prompt = "illustration of a beautiful girl, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ," tokens = tokenizer.tokenize(prompt) print(len(tokens), tokens[0:tokenizer.model_max_length-2]) image = pipe(prompt)["sample"][0] image トーク ン出力結果（改行版） 75 ['illustration</w>', 'of</w>', 'a</w>', 'beautiful</w>', 'girl</w>', ',</w>', 省略 ',</w>'] 確かに呪文は、75個の トーク ンで構成されていますね。この呪文の最後に以下の呪文を追加しましょう。75個を超える トーク ンが切り捨てられるなら、結果に影響はないはずです。 追加する呪文（改行版） deviantart, concept art, digital painting, award-winning, cinematic postprocessing, cinematic scene, cinematic composition, cinematic lighting, overexpose, ray tracing, 8k トーク ン出力結果（改行版） 109 ['illustration</w>', 'of</w>', 'a</w>', 'beautiful</w>', 'girl</w>', ',</w>', 省略 ',</w>'] 結果に影響はなかったですね。75個を超える トーク ンが切り捨てられることが確認できました。 呪文のカンマを削っても出力結果に影響はないのか 今度は、呪文のカンマを削っても出力結果に影響がないのかを検証してみましょう。 今回の呪文は、 美少女を高確率で出す呪文編 で使った呪文の改良版です。 今回の呪文（横長、コピー&ペースト用） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed perfect pupil of eyes, detailed mouth, detailed shoulders, 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 perfect pupil of eyes, detailed mouth, detailed shoulders, 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 改良したのは、detailed perfect pupil of eyesとdetailed shouldersの二箇所です。 イラストなら、前回の呪文でも大丈夫なのですが、写真で試すと目や腕が変になることがあったので改良しました。 目は、detailed beautiful eyesをdetailed perfect pupil of eyesに変えました。 腕は、detailed armsをdetailed shouldersに変えました。腕は変になりやすいので、指定しないほうが無難なようです。肩を指定することで腕が出力される回数が減りました。 トーク ン出力結果（改行版） 74 ['illustration</w>','of</w>','a</w>','beautiful</w>','girl</w>', ',</w>', 'detailed</w>','beautiful</w>','face</w>', ',</w>', 'detailed</w>','hair</w>', ',</w>', 'detailed</w>','perfect</w>','pupil</w>','of</w>','eyes</w>', ',</w>', 'detailed</w>','mouth</w>', ',</w>', 'detailed</w>','shoulders</w>', ',</w>', 'detailed</w>','bust</w>', ',</w>', 'looking</w>','far</w>','away</w>', ',</w>', 'shot</w>','diag', 'on', 'ally</w>', ',</w>', 'art','station</w>', ',</w>', 'deviantart</w>', ',</w>', 'concept</w>','art</w>', ',</w>', 'digital</w>','painting</w>', ',</w>', 'award</w>','-</w>','winning</w>', ',</w>', 'cinematic</w>','post','processing</w>', ',</w>', 'cinematic</w>','scene</w>', ',</w>', 'cinematic</w>','composition</w>', ',</w>', 'cinematic</w>','lighting</w>', ',</w>', 'ove', 'rex', 'pose</w>', ',</w>', 'ray</w>','tracing</w>', ',</w>', '8</w>','k</w>'] 画像出力結果 既に トーク ンの数は74（Max 75）。これ以上、詳細な指定ができなくなるのは問題です。出力結果を見ながら呪文を改良していきましょう。 ',＜/w＞'は削れますね。 a beautiful girlのaも削れます。girlを見れば単数であることがわかるからです。僕の試した限りはtheも削ることができます。 diagonallyが、'diag', 'on', 'ally＜/w＞'と3つに分かれて認識されています。これは、Stable Diffusionがdiagonallyという単語を認識できていないことを示しています。 この結果を見てdiagonallyが無効だと判断するのは早計です。Stable Diffusionは、ワードでない（＜/w＞がついていない）連続した トーク ンを有効だと認識していることもあるからです。例えば、pixivは、'pi', 'xiv＜/w＞'と別れていますが、pixivあり/なしで、出力結果は変わってきます。つまり、pixivの呪文は有効だということです。 ワードでない（＜/w＞がついていない）連続した トーク ンは、あり/なしで何度も試しましょう。効果があると確信できるときだけ、呪文として採用しましょう。shot diagonally（斜めに撮影する）は、何度も試した結果効果が確信できなかったので、不採用にしました。 同様にワードでない（＜/w＞がついていない）連続した トーク ンの'ove', 'rex', 'pose＜/w＞'も不採用にしました。 award-winningは、'award＜/w＞', '-＜/w＞', 'winning＜/w＞'に分解されていたので、真ん中の '-＜/w＞'は不要と判断し、award winningにすることにしました。 改良版の呪文（横長、コピー&ペースト用）はこちらになります。 illustration of beautiful girl detailed beautiful face detailed hair detailed perfect pupil of eyes detailed mouth detailed shoulders detailed bust looking far away artstation deviantart concept art digital painting award winning cinematic postprocessing cinematic scene cinematic composition cinematic lighting ray tracing 8k 改良版の閲覧用呪文（改行版） illustration of beautiful girl detailed beautiful face detailed hair detailed perfect pupil of eyes detailed mouth detailed shoulders detailed bust looking far away artstation deviantart concept art digital painting award winning cinematic postprocessing cinematic scene cinematic composition cinematic lighting ray tracing 8k トーク ン出力結果（改行版） 45 ['illustration</w>', 'of</w>', 'beautiful</w>', 'girl</w>', 'detailed</w>', 'beautiful</w>', 'face</w>', 'detailed</w>', 'hair</w>', 'detailed</w>', 'perfect</w>', 'pupil</w>', 'of</w>', 'eyes</w>', 'detailed</w>', 'mouth</w>', 'detailed</w>', 'shoulders</w>', 'detailed</w>', 'bust</w>', 'looking</w>', 'far</w>', 'away</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'cinematic</w>', 'post', 'processing</w>', 'cinematic</w>', 'scene</w>', 'cinematic</w>', 'composition</w>', 'cinematic</w>', 'lighting</w>', 'ray</w>', 'tracing</w>', '8</w>', 'k</w>'] 画像出力結果 トーク ンの個数が74から45に圧縮されました。画像のクオリティは変わっていないことが確認できると思います。 まとめ 今回は、75個を超える トーク ンは、切り捨てられることを確認しました。 さらに、呪文を圧縮するテクニックとして、カンマ（、）を削る、ワードでない（＜/w＞がついていない）連続した トーク ンが有効かどうかをチェックすることを学びました。 次回は、 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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の内容を理解するための情報・書籍の記事 の中に出てくる 最初の75個分以降の文章は、バッサリ捨てられてしまう記事 をみて、自分でも検証してみたのが今回の記事です。 これまで、意味のある区切りとして、カンマ（,）を使っていたのですが、カンマ（,）は75個の トーク ンの一つとして重複して数えられ、カンマ（,）を削っても出力結果はほとんど変わらないことを知って愕然としました。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 tokenizer 75個を超えるトークンは切り捨てられるのか 呪文のカンマを削っても出力結果に影響はないのか まとめ 仲間募集 Stable Diffusionの過去コンテンツ tokenizer 呪文を トーク ンに分解するには、tokenizerを作成します。必要なライブラリは次のようにインストールします。今回は、Notebookの例です。 !pip install transformers ftfy regex tokenizerの作成は次のように行います。 from transformers import CLIPTokenizer tokenizer = CLIPTokenizer.from_pretrained("openai/clip-vit-large-patch14") 呪文を トーク ンに分解するには、次のように行います。 prompt = "anime of beautiful girl, detailed beautiful face, detailed hair, detailed perfect pupil of eyes, detailed cute mouth, detailed shoulders, detailed bust" tokens = tokenizer.tokenize(prompt) print(len(tokens), tokens[0:tokenizer.model_max_length-2]) トーク ン出力結果（改行版） 37 ['japanese</w>', 'anime</w>', 'of</w>', 'beautiful</w>', 'girl</w>', ',</w>', 'detailed</w>', 'beautiful</w>', 'face</w>', ',</w>', 'detailed</w>', 'hair</w>', ',</w>', 'detailed</w>', 'perfect</w>', 'pupil</w>', 'of</w>', 'eyes</w>', ',</w>', 'detailed</w>', 'cute</w>', 'mouth</w>', ',</w>', 'detailed</w>', 'shoulders</w>', ',</w>', 'detailed</w>', 'bust</w>'] 37の トーク ンに分解されたことがわかります。',＜/w＞'に注目してください。これは、カンマ（,）です。カンマ（,）も トーク ンの一つにカウントされていることがわかります。 僕が実験した限り、カンマ（,）ありなしで、出力される結果に違いはありません。75個を超える トーク ンは切り捨てられることを考えると、カンマ（,）は呪文に含めないのが良いでしょう。 75個を超える トーク ンは切り捨てられるのか それでは、本当に「75個を超える トーク ンは切り捨てられるのか」実験してみましょう。 下記のようなちょうど75個の トーク ンの呪文を用意します。 prompt = "illustration of a beautiful girl, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ," tokens = tokenizer.tokenize(prompt) print(len(tokens), tokens[0:tokenizer.model_max_length-2]) image = pipe(prompt)["sample"][0] image トーク ン出力結果（改行版） 75 ['illustration</w>', 'of</w>', 'a</w>', 'beautiful</w>', 'girl</w>', ',</w>', 省略 ',</w>'] 確かに呪文は、75個の トーク ンで構成されていますね。この呪文の最後に以下の呪文を追加しましょう。75個を超える トーク ンが切り捨てられるなら、結果に影響はないはずです。 追加する呪文（改行版） deviantart, concept art, digital painting, award-winning, cinematic postprocessing, cinematic scene, cinematic composition, cinematic lighting, overexpose, ray tracing, 8k トーク ン出力結果（改行版） 109 ['illustration</w>', 'of</w>', 'a</w>', 'beautiful</w>', 'girl</w>', ',</w>', 省略 ',</w>'] 結果に影響はなかったですね。75個を超える トーク ンが切り捨てられることが確認できました。 呪文のカンマを削っても出力結果に影響はないのか 今度は、呪文のカンマを削っても出力結果に影響がないのかを検証してみましょう。 今回の呪文は、 美少女を高確率で出す呪文編 で使った呪文の改良版です。 今回の呪文（横長、コピー&ペースト用） illustration of a beautiful girl, detailed beautiful face, detailed hair, detailed perfect pupil of eyes, detailed mouth, detailed shoulders, 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 perfect pupil of eyes, detailed mouth, detailed shoulders, 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 改良したのは、detailed perfect pupil of eyesとdetailed shouldersの二箇所です。 イラストなら、前回の呪文でも大丈夫なのですが、写真で試すと目や腕が変になることがあったので改良しました。 目は、detailed beautiful eyesをdetailed perfect pupil of eyesに変えました。 腕は、detailed armsをdetailed shouldersに変えました。腕は変になりやすいので、指定しないほうが無難なようです。肩を指定することで腕が出力される回数が減りました。 トーク ン出力結果（改行版） 74 ['illustration</w>','of</w>','a</w>','beautiful</w>','girl</w>', ',</w>', 'detailed</w>','beautiful</w>','face</w>', ',</w>', 'detailed</w>','hair</w>', ',</w>', 'detailed</w>','perfect</w>','pupil</w>','of</w>','eyes</w>', ',</w>', 'detailed</w>','mouth</w>', ',</w>', 'detailed</w>','shoulders</w>', ',</w>', 'detailed</w>','bust</w>', ',</w>', 'looking</w>','far</w>','away</w>', ',</w>', 'shot</w>','diag', 'on', 'ally</w>', ',</w>', 'art','station</w>', ',</w>', 'deviantart</w>', ',</w>', 'concept</w>','art</w>', ',</w>', 'digital</w>','painting</w>', ',</w>', 'award</w>','-</w>','winning</w>', ',</w>', 'cinematic</w>','post','processing</w>', ',</w>', 'cinematic</w>','scene</w>', ',</w>', 'cinematic</w>','composition</w>', ',</w>', 'cinematic</w>','lighting</w>', ',</w>', 'ove', 'rex', 'pose</w>', ',</w>', 'ray</w>','tracing</w>', ',</w>', '8</w>','k</w>'] 画像出力結果 既に トーク ンの数は74（Max 75）。これ以上、詳細な指定ができなくなるのは問題です。出力結果を見ながら呪文を改良していきましょう。 ',＜/w＞'は削れますね。 a beautiful girlのaも削れます。girlを見れば単数であることがわかるからです。僕の試した限りはtheも削ることができます。 diagonallyが、'diag', 'on', 'ally＜/w＞'と3つに分かれて認識されています。これは、Stable Diffusionがdiagonallyという単語を認識できていないことを示しています。 この結果を見てdiagonallyが無効だと判断するのは早計です。Stable Diffusionは、ワードでない（＜/w＞がついていない）連続した トーク ンを有効だと認識していることもあるからです。例えば、pixivは、'pi', 'xiv＜/w＞'と別れていますが、pixivあり/なしで、出力結果は変わってきます。つまり、pixivの呪文は有効だということです。 ワードでない（＜/w＞がついていない）連続した トーク ンは、あり/なしで何度も試しましょう。効果があると確信できるときだけ、呪文として採用しましょう。shot diagonally（斜めに撮影する）は、何度も試した結果効果が確信できなかったので、不採用にしました。 同様にワードでない（＜/w＞がついていない）連続した トーク ンの'ove', 'rex', 'pose＜/w＞'も不採用にしました。 award-winningは、'award＜/w＞', '-＜/w＞', 'winning＜/w＞'に分解されていたので、真ん中の '-＜/w＞'は不要と判断し、award winningにすることにしました。 改良版の呪文（横長、コピー&ペースト用）はこちらになります。 illustration of beautiful girl detailed beautiful face detailed hair detailed perfect pupil of eyes detailed mouth detailed shoulders detailed bust looking far away artstation deviantart concept art digital painting award winning cinematic postprocessing cinematic scene cinematic composition cinematic lighting ray tracing 8k 改良版の閲覧用呪文（改行版） illustration of beautiful girl detailed beautiful face detailed hair detailed perfect pupil of eyes detailed mouth detailed shoulders detailed bust looking far away artstation deviantart concept art digital painting award winning cinematic postprocessing cinematic scene cinematic composition cinematic lighting ray tracing 8k トーク ン出力結果（改行版） 45 ['illustration</w>', 'of</w>', 'beautiful</w>', 'girl</w>', 'detailed</w>', 'beautiful</w>', 'face</w>', 'detailed</w>', 'hair</w>', 'detailed</w>', 'perfect</w>', 'pupil</w>', 'of</w>', 'eyes</w>', 'detailed</w>', 'mouth</w>', 'detailed</w>', 'shoulders</w>', 'detailed</w>', 'bust</w>', 'looking</w>', 'far</w>', 'away</w>', 'art', 'station</w>', 'deviantart</w>', 'concept</w>', 'art</w>', 'digital</w>', 'painting</w>', 'award</w>', 'winning</w>', 'cinematic</w>', 'post', 'processing</w>', 'cinematic</w>', 'scene</w>', 'cinematic</w>', 'composition</w>', 'cinematic</w>', 'lighting</w>', 'ray</w>', 'tracing</w>', '8</w>', 'k</w>'] 画像出力結果 トーク ンの個数が74から45に圧縮されました。画像のクオリティは変わっていないことが確認できると思います。 まとめ 今回は、75個を超える トーク ンは、切り捨てられることを確認しました。 さらに、呪文を圧縮するテクニックとして、カンマ（、）を削る、ワードでない（＜/w＞がついていない）連続した トーク ンが有効かどうかをチェックすることを学びました。 次回は、 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、TypeScriptを使って、gRPCのアプリケーションを開発する際の方法について紹介します。 gRPCとProtocol Buffers gRPCは Google の開発した様々な環境で動作する オープンソース のRPC フレームワーク です。 gRPCは負荷分散、トレース、ヘルスチェック、認証などの機能をサポートし、効率的な通信の仕組みを提供しています。 gRPCは、Protocol Buffersというインターフェース記述言語(IDL)を用いてサービスを定義して利用します。このProtocol BuffersもgRPCと同じく Google が開発しています。gRPCでアプリケーションを開発する際は、まずProtocol Buffersから通信に関するプログラムを自動的に構築して開発することになります。 Protocol Buffersは多くの言語をサポートしています。今回利用するTypeScriptを直接サポートはしていませんが、Node.jsをサポートしているので問題なく利用できます。 詳細な情報はgRPCの公式サイトを参照してください。 https://grpc.io/ Protocol Buffersについての詳細な情報は以下のURLを参照してください。 https://developers.google.com/protocol-buffers この記事では、Node.jsのサポートを利用してTypeScriptのアプリケーション開発の手順について解説します。 gRPCの通信方式 gRPCでは4種類の通信方式がある。 Unary RPC 1つのリク エス トに対して一つのレスポンスを返す一般的な通信です。 Server streaming RPC クライアントから送られてきた一つのリク エス トに対して、サーバは複数回に分けてレスポンスを返す通信方式です。 Client streaming RPC クライアントからリク エス トを分割して送る方式でサーバーはすべてのリク エス トを受け取ってからレスポンスを返す方式です。 Bidirectional streaming RPC サーバーとクライアントが一つのコネクションを確立しお互いに任意のタイミングでリク エス トとレスポンスを送りあう通信方式です。 また、gRPCでは、ブラウザで利用するgRPC WebとHTTP/2を利用して通信を行うgRPC over HTTP/2の2種類の通信方式が存在しています。 gRPC over WEBはブラウザを中心に策定された仕様となっています。このため現在は、Client streaming RPC、Bidirectional streaming RPCを行うことが出来ません。 この記事では、このうちHTTP/2を▼使ったUnary RPCの開発手順について紹介します。 TypeScriptを用いたgRPCの開発手順 TypeScriptを用いたgRPCアプリケーションは以下のような流れで開発します。 Protocol Buffersの定義を proto ファイルで行う protoc プログラムを用いて proto ファイルから ソースコード を生成する 生成したプログラムにロジックを追加して完成させる という流れになります。 ここでは、その流れを順番に追ってみます。 Protocol Buffers でサービスとメッセージを記述する Protocol Buffersではサービスとメソッド(rpc名と呼ぶ方が適切かもしれませんが、本記事ではメソッドで統一します)を定義します。メソッドが API の概念に近いものとなり、メソッドが通信でやりとりする内容をメッセージとして定義することとなります。 Protocol Buffersの例を以下に示します。なおProtocol Buffersにはバージョンがあり本記事ではバージョン3を想定しています。 syntax = "proto3"; message HelloRequest { string name = 1; } message HelloResponse { string result =1; } service Hello { rpc hello(HelloRequest) returns (HelloResponse); } 上記の定義では、 Hello というサービスと hello メソッド、 HelloRequest と HelloResponse というメッセージが定義されています。 。 hello を呼びだす場合には、 HelloRequest を引数として呼び出し、その返り値としては HelloResponse というメッセージが返ってくることを表しています。 なお、ここではProtocol Buffersの文法の詳細を述べません。詳細については、公式のドキュメントを参照してください。 https://developers.google.com/protocol-buffers/docs/proto3 記載する際は以下のスタイルガイドが参考になります。 https://developers.google.com/protocol-buffers/docs/style スタイルガイドには以下のようにサービス名、メッセージ名とフィールド名についての 命名 の規則が記載されています。 Use CamelCase (with an initial capital) for message names – for example, SongServerRequest. Use underscore_separated_names for field names (including oneof field and extension names) – for example, song_name. このガイドの内容に従わなくても問題はおきません。しかし、従っていない場合は生成される ソースコード が不自然なものとなってしまいます。 例えば、フィールド名を userId のような名前を付けた場合、これに対応するメソッドやプロパティの名前は getUserid 、 setUserid といった形になってしまいます。 一方で user_id というフィールド名を用いた場合は getUserId 、 setUserId という名前で生成されます。コードの読みやすさなどの観点からフィールド名にはスネークケースを用いる方が良さそうですね。 Protocol Buffersの更新について Protocol Buffersのprotoファイルを更新して、メッセージのフォーマットを変更する場合には注意が必要となります。 特に、フィールド番号は安易に変更、削除してしまうと古いプログラムと新しいプログラムでメッセージのフォーマットが一致しなくなり通信できなくなってしまうので注意が必要です。 極力新しいフィールドを追加していく形で更新していく事が望ましいです。 また削除も可能であれば避け OBSOLETE_ といった プレフィックス をつけて残しておく事が望ましいです。 後々誤って削除したフィールド番号が再利用されてしまうといったトラブルを回避するためです。 また各種メッセージの種類には互換性があり、同じフィールド番号でもメッセージの種類の変更は可能な場合があります。 その他の注意点については公式のドキュメントを熟読し、慎重に更新を行っていく必要があるので注意してください。 https://developers.google.com/protocol-buffers/docs/proto3#updating Protocol Buffersから ソースコード を生成する protocプログラムとそのオプションについて Protocol Buffersからコードを生成するプログラム( protoc )は、オプションの記述方法に注意が必要です。 protoc を利用する際は、 xxx_out=.... というオプションが並ぶことになります。 このオプションは、以下のように解釈します。 --xxx_out は プラグイン と出力先の指定を意味します。これは、 proto-gen-xxx という プラグイン 名の場合は、 xxx_out という対応関係になっています。 proto-gen-go プラグイン なら --go_out 。 proto-gen-grpc-gateway プラグイン なら --grpc-gateway_out という具合になっています。 プラグイン 自体もオプションも同時に指定することが出来て、 --xxx_out=プラグインのオプション:出力先 という形になります。 例えば、 --js_out=import_style=commonjs,binary:${PROTO_DEST} と書いてある場合を考えます。 これは、 js_out プラグイン に import_style=commonjs,binary(=true) という引数を渡すことになります。そして、その出力先は ${PROTO_DEST} ということです。 TypeScript用のprotocについて protoc は Node.js に対応していますが、TypeScriptの型定義などを直接生成する機能は持っていません。 今回は、 grpc_tools_node_protoc_ts を用いて protoc の生成した Node.js の ソースコード に型定義を自動生成して利用します。これは、 grpc-tools というgRPC公式に含まれている grpc_tools_node_protoc というツールを拡張したものです。 以下が公式ドキュメントとその使い方です。 https://github.com/agreatfool/grpc_tools_node_protoc_ts#how-to-use # ソースコードの出力先 PROTO_DEST=./src/proto # protoファイルが置いてあるディレクトリ PROTO_DIR=./proto # Protocol BuffersからnodeのgRPCコードを自動生成 grpc_tools_node_protoc \ --js_out=import_style=commonjs,binary:${PROTO_DEST} \ --grpc_out=${PROTO_DEST} \ --plugin=protoc-gen-grpc=$(which grpc_tools_node_protoc_plugin) \ -I ${PROTO_SRC} \ ${PROTO_SRC}/* # typescript用の型定義を作成 grpc_tools_node_protoc \ --plugin=protoc-gen-ts=$(yarn bin)/protoc-gen-ts \ --ts_out=${PROTO_DEST} \ -I ${PROTO_SRC} \ ${PROTO_SRC}/* もしくは以下のように一括で生成する方法もあります。 # 定義と実装を同時に生成 yarn run grpc_tools_node_protoc \ --plugin=protoc-gen-ts=$(yarn bin)/protoc-gen-ts \ --ts_out=grpc_js:${PROTO_DEST} \ --js_out=import_style=commonjs,binary:${PROTO_DEST} \ --grpc_out=grpc_js:${PROTO_DEST} \ -I ${PROTO_DIR} \ ${PROTO_DIR}/*.proto 生成されたプログラムを利用してみる Hello サービスの簡単なサーバ、クライアントの実装を以下に示します。 通信に関わる処理は全てgRPC側が行ってくれているため、実際に記述する部分はロジックに対応する部分だけとなります。通信に用いるメッセージを組み立てる関数も自動生成されているので、それを利用して構築できます。 // サーバプログラム import * as grpc from '@grpc/grpc-js' ; import { sendUnaryData } from '@grpc/grpc-js/build/src/server-call' ; import { HelloRequest , HelloResponse } from '../proto/hello_pb' ; import { HelloService } from '../proto/hello_grpc_pb' ; const HelloServer = { hello: ( call: grpc.ServerUnaryCall < HelloRequest , HelloResponse >, callback: sendUnaryData < HelloResponse >) : void => { const request = call.request ; const response = new HelloResponse (); console .log ( "Message from client" ); response.setResult ( "Hello," + request.getName ()) callback ( null , response ); } } function serve () : void { const server = new grpc.Server (); server.addService ( HelloService , HelloServer ); server.bindAsync ( `localhost:6543` , grpc.ServerCredentials.createInsecure (), ( err , port ) => { if ( err ) { throw err ; } console .log ( `Listening on ${ port } ` ); server.start (); } ); } serve (); // クライアントプログラム import * as grpc from '@grpc/grpc-js' ; import { HelloClient } from '../proto/hello_grpc_pb' ; import { HelloRequest , HelloResponse } from '../proto/hello_pb' ; function hello () : Promise < HelloResponse > { const client = new HelloClient ( `localhost:6543` , grpc.credentials.createInsecure (), ); // HelloRequestを作るためのクラス、メソッドが用意されているのでそれを用いてメッセージを作成する const request = new HelloRequest (); request.setName ( "ISID" ); // サーバに対してサービスの実行を要求する return new Promise < HelloResponse >(( resolve , reject ) => { console .log ( "Send Hello Message" ); client.hello ( request , ( err , response ) => { if ( err ) { return reject ( err ); } // ここで結果を受け取っている console .log ( "Receive Message" ); return resolve ( response ); } ); } ); } (async () => { console .log ( "Client Start" ); const result = await hello (); console .log ( result.getResult ()); } )(); 実際のプロジェクト構成と動作例 ここでは、今回のサンプルで利用したプロジェクトの構成を紹介します。 プロジェクト構成例 ディレクト リの構成は以下のような構成です。 . ├── package.json ├── proto │   └── hello.proto ├── scripts │   └── build-protos.sh ├── src │   ├── client │   │   └── index.ts │   ├── proto │   └── server │   └── index.ts └── tsconfig.json また、package. json の中身は以下のような内容です。 { " name ": " grpc-hello ", " version ": " 1.0.0 ", " main ": " index.js ", " license ": " MIT ", " dependencies ": { } , " scripts ": { " lint ": " yarn run eslint --fix --ext .ts src ", " clean ": " rm -rf ./dist && rm -rf ./src/proto && mkdir -p ./src/proto ", " build ": " sh ./scripts/build-protos.sh ./hello.proto ./src/proto && yarn run tsc; cp -r ./src/proto ./dist/src/proto " , } , " devDependencies ": { " @grpc/grpc-js ": " ^1.4.2 ", " @types/eslint ": " ^7.28.2 ", " @types/google-protobuf ": " ^3.15.5 ", " @types/node ": " ^16.11.7 ", " @typescript-eslint/eslint-plugin ": " ^5.3.0 ", " @typescript-eslint/parser ": " ^5.3.0 ", " eslint ": " ^8.1.0 ", " grpc-tools ": " ^1.11.2 ", " grpc_tools_node_protoc_ts ": " ^5.3.2 ", " ts-node ": " ^10.4.0 ", " tsconfig-paths ": " ^3.11.0 ", " typescript ": " ^4.4.4 " } } 動作確認 まず yarn build で Protocol Buffers からコード生成、TypeScriptから JavaScript へのトランスパイルを実行します。 $ yarn $ yarn build サーバの起動 $ node ./dist/src/server/ Listening on 6543 クライアントの実行 $ node ./dist/src/client Client Start Send Hello Message Receive Message Hello,ISID サーバー側のログも確認すると Message from client というようなログが出ています。 gRPCを使った通信プログラムが実装できてそうです。 まとめ 今回は、gRPCを用いたアプリケーション開発の方法やその注意点について紹介しました。 gRPCは Protocol Buffers を定義するだけで高品質な通信プログラムが実装できる素晴しい技術ですね。 機会があれば積極的に利用していきたいと思います。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @handa.kenta （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、TypeScriptを使って、gRPCのアプリケーションを開発する際の方法について紹介します。 gRPCとProtocol Buffers gRPCは Google の開発した様々な環境で動作する オープンソース のRPC フレームワーク です。 gRPCは負荷分散、トレース、ヘルスチェック、認証などの機能をサポートし、効率的な通信の仕組みを提供しています。 gRPCは、Protocol Buffersというインターフェース記述言語(IDL)を用いてサービスを定義して利用します。このProtocol BuffersもgRPCと同じく Google が開発しています。gRPCでアプリケーションを開発する際は、まずProtocol Buffersから通信に関するプログラムを自動的に構築して開発することになります。 Protocol Buffersは多くの言語をサポートしています。今回利用するTypeScriptを直接サポートはしていませんが、Node.jsをサポートしているので問題なく利用できます。 詳細な情報はgRPCの公式サイトを参照してください。 https://grpc.io/ Protocol Buffersについての詳細な情報は以下のURLを参照してください。 https://developers.google.com/protocol-buffers この記事では、Node.jsのサポートを利用してTypeScriptのアプリケーション開発の手順について解説します。 gRPCの通信方式 gRPCでは4種類の通信方式がある。 Unary RPC 1つのリク エス トに対して一つのレスポンスを返す一般的な通信です。 Server streaming RPC クライアントから送られてきた一つのリク エス トに対して、サーバは複数回に分けてレスポンスを返す通信方式です。 Client streaming RPC クライアントからリク エス トを分割して送る方式でサーバーはすべてのリク エス トを受け取ってからレスポンスを返す方式です。 Bidirectional streaming RPC サーバーとクライアントが一つのコネクションを確立しお互いに任意のタイミングでリク エス トとレスポンスを送りあう通信方式です。 また、gRPCでは、ブラウザで利用するgRPC WebとHTTP/2を利用して通信を行うgRPC over HTTP/2の2種類の通信方式が存在しています。 gRPC over WEBはブラウザを中心に策定された仕様となっています。このため現在は、Client streaming RPC、Bidirectional streaming RPCを行うことが出来ません。 この記事では、このうちHTTP/2を▼使ったUnary RPCの開発手順について紹介します。 TypeScriptを用いたgRPCの開発手順 TypeScriptを用いたgRPCアプリケーションは以下のような流れで開発します。 Protocol Buffersの定義を proto ファイルで行う protoc プログラムを用いて proto ファイルから ソースコード を生成する 生成したプログラムにロジックを追加して完成させる という流れになります。 ここでは、その流れを順番に追ってみます。 Protocol Buffers でサービスとメッセージを記述する Protocol Buffersではサービスとメソッド(rpc名と呼ぶ方が適切かもしれませんが、本記事ではメソッドで統一します)を定義します。メソッドが API の概念に近いものとなり、メソッドが通信でやりとりする内容をメッセージとして定義することとなります。 Protocol Buffersの例を以下に示します。なおProtocol Buffersにはバージョンがあり本記事ではバージョン3を想定しています。 syntax = "proto3"; message HelloRequest { string name = 1; } message HelloResponse { string result =1; } service Hello { rpc hello(HelloRequest) returns (HelloResponse); } 上記の定義では、 Hello というサービスと hello メソッド、 HelloRequest と HelloResponse というメッセージが定義されています。 。 hello を呼びだす場合には、 HelloRequest を引数として呼び出し、その返り値としては HelloResponse というメッセージが返ってくることを表しています。 なお、ここではProtocol Buffersの文法の詳細を述べません。詳細については、公式のドキュメントを参照してください。 https://developers.google.com/protocol-buffers/docs/proto3 記載する際は以下のスタイルガイドが参考になります。 https://developers.google.com/protocol-buffers/docs/style スタイルガイドには以下のようにサービス名、メッセージ名とフィールド名についての 命名 の規則が記載されています。 Use CamelCase (with an initial capital) for message names – for example, SongServerRequest. Use underscore_separated_names for field names (including oneof field and extension names) – for example, song_name. このガイドの内容に従わなくても問題はおきません。しかし、従っていない場合は生成される ソースコード が不自然なものとなってしまいます。 例えば、フィールド名を userId のような名前を付けた場合、これに対応するメソッドやプロパティの名前は getUserid 、 setUserid といった形になってしまいます。 一方で user_id というフィールド名を用いた場合は getUserId 、 setUserId という名前で生成されます。コードの読みやすさなどの観点からフィールド名にはスネークケースを用いる方が良さそうですね。 Protocol Buffersの更新について Protocol Buffersのprotoファイルを更新して、メッセージのフォーマットを変更する場合には注意が必要となります。 特に、フィールド番号は安易に変更、削除してしまうと古いプログラムと新しいプログラムでメッセージのフォーマットが一致しなくなり通信できなくなってしまうので注意が必要です。 極力新しいフィールドを追加していく形で更新していく事が望ましいです。 また削除も可能であれば避け OBSOLETE_ といった プレフィックス をつけて残しておく事が望ましいです。 後々誤って削除したフィールド番号が再利用されてしまうといったトラブルを回避するためです。 また各種メッセージの種類には互換性があり、同じフィールド番号でもメッセージの種類の変更は可能な場合があります。 その他の注意点については公式のドキュメントを熟読し、慎重に更新を行っていく必要があるので注意してください。 https://developers.google.com/protocol-buffers/docs/proto3#updating Protocol Buffersから ソースコード を生成する protocプログラムとそのオプションについて Protocol Buffersからコードを生成するプログラム( protoc )は、オプションの記述方法に注意が必要です。 protoc を利用する際は、 xxx_out=.... というオプションが並ぶことになります。 このオプションは、以下のように解釈します。 --xxx_out は プラグイン と出力先の指定を意味します。これは、 proto-gen-xxx という プラグイン 名の場合は、 xxx_out という対応関係になっています。 proto-gen-go プラグイン なら --go_out 。 proto-gen-grpc-gateway プラグイン なら --grpc-gateway_out という具合になっています。 プラグイン 自体もオプションも同時に指定することが出来て、 --xxx_out=プラグインのオプション:出力先 という形になります。 例えば、 --js_out=import_style=commonjs,binary:${PROTO_DEST} と書いてある場合を考えます。 これは、 js_out プラグイン に import_style=commonjs,binary(=true) という引数を渡すことになります。そして、その出力先は ${PROTO_DEST} ということです。 TypeScript用のprotocについて protoc は Node.js に対応していますが、TypeScriptの型定義などを直接生成する機能は持っていません。 今回は、 grpc_tools_node_protoc_ts を用いて protoc の生成した Node.js の ソースコード に型定義を自動生成して利用します。これは、 grpc-tools というgRPC公式に含まれている grpc_tools_node_protoc というツールを拡張したものです。 以下が公式ドキュメントとその使い方です。 https://github.com/agreatfool/grpc_tools_node_protoc_ts#how-to-use # ソースコードの出力先 PROTO_DEST=./src/proto # protoファイルが置いてあるディレクトリ PROTO_DIR=./proto # Protocol BuffersからnodeのgRPCコードを自動生成 grpc_tools_node_protoc \ --js_out=import_style=commonjs,binary:${PROTO_DEST} \ --grpc_out=${PROTO_DEST} \ --plugin=protoc-gen-grpc=$(which grpc_tools_node_protoc_plugin) \ -I ${PROTO_SRC} \ ${PROTO_SRC}/* # typescript用の型定義を作成 grpc_tools_node_protoc \ --plugin=protoc-gen-ts=$(yarn bin)/protoc-gen-ts \ --ts_out=${PROTO_DEST} \ -I ${PROTO_SRC} \ ${PROTO_SRC}/* もしくは以下のように一括で生成する方法もあります。 # 定義と実装を同時に生成 yarn run grpc_tools_node_protoc \ --plugin=protoc-gen-ts=$(yarn bin)/protoc-gen-ts \ --ts_out=grpc_js:${PROTO_DEST} \ --js_out=import_style=commonjs,binary:${PROTO_DEST} \ --grpc_out=grpc_js:${PROTO_DEST} \ -I ${PROTO_DIR} \ ${PROTO_DIR}/*.proto 生成されたプログラムを利用してみる Hello サービスの簡単なサーバ、クライアントの実装を以下に示します。 通信に関わる処理は全てgRPC側が行ってくれているため、実際に記述する部分はロジックに対応する部分だけとなります。通信に用いるメッセージを組み立てる関数も自動生成されているので、それを利用して構築できます。 // サーバプログラム import * as grpc from '@grpc/grpc-js' ; import { sendUnaryData } from '@grpc/grpc-js/build/src/server-call' ; import { HelloRequest , HelloResponse } from '../proto/hello_pb' ; import { HelloService } from '../proto/hello_grpc_pb' ; const HelloServer = { hello: ( call: grpc.ServerUnaryCall < HelloRequest , HelloResponse >, callback: sendUnaryData < HelloResponse >) : void => { const request = call.request ; const response = new HelloResponse (); console .log ( "Message from client" ); response.setResult ( "Hello," + request.getName ()) callback ( null , response ); } } function serve () : void { const server = new grpc.Server (); server.addService ( HelloService , HelloServer ); server.bindAsync ( `localhost:6543` , grpc.ServerCredentials.createInsecure (), ( err , port ) => { if ( err ) { throw err ; } console .log ( `Listening on ${ port } ` ); server.start (); } ); } serve (); // クライアントプログラム import * as grpc from '@grpc/grpc-js' ; import { HelloClient } from '../proto/hello_grpc_pb' ; import { HelloRequest , HelloResponse } from '../proto/hello_pb' ; function hello () : Promise < HelloResponse > { const client = new HelloClient ( `localhost:6543` , grpc.credentials.createInsecure (), ); // HelloRequestを作るためのクラス、メソッドが用意されているのでそれを用いてメッセージを作成する const request = new HelloRequest (); request.setName ( "ISID" ); // サーバに対してサービスの実行を要求する return new Promise < HelloResponse >(( resolve , reject ) => { console .log ( "Send Hello Message" ); client.hello ( request , ( err , response ) => { if ( err ) { return reject ( err ); } // ここで結果を受け取っている console .log ( "Receive Message" ); return resolve ( response ); } ); } ); } (async () => { console .log ( "Client Start" ); const result = await hello (); console .log ( result.getResult ()); } )(); 実際のプロジェクト構成と動作例 ここでは、今回のサンプルで利用したプロジェクトの構成を紹介します。 プロジェクト構成例 ディレクト リの構成は以下のような構成です。 . ├── package.json ├── proto │   └── hello.proto ├── scripts │   └── build-protos.sh ├── src │   ├── client │   │   └── index.ts │   ├── proto │   └── server │   └── index.ts └── tsconfig.json また、package. json の中身は以下のような内容です。 { " name ": " grpc-hello ", " version ": " 1.0.0 ", " main ": " index.js ", " license ": " MIT ", " dependencies ": { } , " scripts ": { " lint ": " yarn run eslint --fix --ext .ts src ", " clean ": " rm -rf ./dist && rm -rf ./src/proto && mkdir -p ./src/proto ", " build ": " sh ./scripts/build-protos.sh ./hello.proto ./src/proto && yarn run tsc; cp -r ./src/proto ./dist/src/proto " , } , " devDependencies ": { " @grpc/grpc-js ": " ^1.4.2 ", " @types/eslint ": " ^7.28.2 ", " @types/google-protobuf ": " ^3.15.5 ", " @types/node ": " ^16.11.7 ", " @typescript-eslint/eslint-plugin ": " ^5.3.0 ", " @typescript-eslint/parser ": " ^5.3.0 ", " eslint ": " ^8.1.0 ", " grpc-tools ": " ^1.11.2 ", " grpc_tools_node_protoc_ts ": " ^5.3.2 ", " ts-node ": " ^10.4.0 ", " tsconfig-paths ": " ^3.11.0 ", " typescript ": " ^4.4.4 " } } 動作確認 まず yarn build で Protocol Buffers からコード生成、TypeScriptから JavaScript へのトランスパイルを実行します。 $ yarn $ yarn build サーバの起動 $ node ./dist/src/server/ Listening on 6543 クライアントの実行 $ node ./dist/src/client Client Start Send Hello Message Receive Message Hello,ISID サーバー側のログも確認すると Message from client というようなログが出ています。 gRPCを使った通信プログラムが実装できてそうです。 まとめ 今回は、gRPCを用いたアプリケーション開発の方法やその注意点について紹介しました。 gRPCは Protocol Buffers を定義するだけで高品質な通信プログラムが実装できる素晴しい技術ですね。 機会があれば積極的に利用していきたいと思います。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @handa.kenta （ Shodo で執筆されました ）

はじめに ISID X（クロス） イノベーション 本部 の三浦です。 筆者の関わってる案件では、コンテナ利用、 AWS Fargate利用を進めております。 AWS Fargateのお手軽さは非常に重宝しております。 しかし、そこで問題になってくるのが、管理接続、踏み台系をどうするかです。 アプリケーション本体をせっかく AWS Fargateでやっているので、管理系接続、踏み台的な作業もできるだけ非EC2でやりたいですよね？ ということで、 AWS FargateでECS Exec、session managerをどのように運用に使っていけるか紹介いたします。 目次 はじめに 目次 想定作業、目標 基本のECS Exec実行 aws ssm start-session start-session with AWS-StartPortForwardingSession start-session with AWS-StartPortForwardingSessionToRemoteHost 番外:ECS FargateでSSMセッションマネージャーのリモートホストのポートフォワード環境を構築する ECS Exec with 運用スクリプト まとめ 想定作業、目標 下記のような想定作業、目標となります。 想定作業： RDSに接続し管理作業（pgdump、pgrestore、レコードの状態確認） ECS Fagateが使ってるEFSのファイル配置、ファイル取得 トラブル時のECSの状態把握（設定ファイル、 環境変数 等） 目標： 管理用のEC2を建てたくない 筆者が関係しているアカウントは200アカウント以上あり、各アカウントに踏み台を立てるのも、集中管理踏み台で VPC ピアリングを考えるのも非常にどちらも避けたい感覚です（というか今苦しんでます） 権限管理を AWS のロールに寄せたい ec2環境では作業時にwinパスワード、 ssh キーを払い出すような仕組みを実装しているのですが（チケット管理＋ssm）、トラブルが一定頻度で発生しています。また、利用者としても踏み台への接続情報（接続経路、IP）、認証情報を意識するのは煩雑です。 監査ログを AWS に寄せたい ECS Execでメンテナンスコマンドの手打ちを辞めたい ローカルから、ポート フォワ ード等で デバッグ 用のセッションを張りたい 基本のECS Exec実行 基本のECS Exec実行です。 工夫としてはタスクIDの取得が煩雑なため、環境情報の取得を自動取得にしているだけです。本取得条件は、1 クラスタ ーに1ecsサービスとなっているので、ECS クラスタ ー、サービスの状況に応じ、適宜クエリ条件は編集してください。 cl = $( aws ecs list-clusters | jq -r ' .clusterArns[0] ' ) prefix = ` echo ${cl} | sed -E ' s/.+cluster\///g ' ` taskarn = $( aws ecs list-tasks --cluster ${cl} | jq -r ' .taskArns[0] ' ) taskid = ` echo ${taskarn} | sed -E ' s/.+task\/.+\///g ' ` CONTAINER_NAME = " ${prefix} -manager-container " echo ${cl} ; \ echo ${prefix} ; \ echo ${taskarn} ; \ echo ${taskid} ; \ echo ${CONTAINER_NAME} ; \ aws ecs execute-command \ --region ap-northeast-1 \ --cluster ${cl} \ --task ${taskarn} \ --container ${CONTAINER_NAME} \ --command " /bin/sh " \ --interactive あと、ECS Execは、cloud shellから実行すれば、アクセスキー、シークレットキーいらずで、 AWS consoleアクセス、フェデレーション管理に寄せることができます。 aws ssm start-session 参考記事： https://winebarrel.hatenablog.com/entry/2021/10/23/165720 次に、対話式シェル以外でもいろいろできないか探っていきます。 上記ブログで下のようなコメントがあり、私は下のところで止まっておりました。 ECS ExecがどうもマネージドなSSM Agentを使って動いているということはわかっていたが、実際どうなっているのかよくわからなかった。 ・・・・ aws ssm start-sessionを実行できそうな雰囲気があるが、--targetに何を渡せばいいのかよくわからなかった。 が、続けて読んでいくと、 ソースコード を読めばtargetの書式が書かれてるとのこと。 https://github.com/aws/aws-cli/blob/c0edee0a7427b6e7b654df0696015e96105497a3/awscli/customizations/ecs/executecommand.py#L61-L73 def build_ssm_request_paramaters (response, client): cluster_name = response[ 'clusterArn' ].split( '/' )[- 1 ] task_id = response[ 'taskArn' ].split( '/' )[- 1 ] container_name = response[ 'containerName' ] # in order to get container run-time id # we need to make a call to describe-tasks container_runtime_id = \ get_container_runtime_id(client, container_name, task_id, cluster_name) target = "ecs:{}_{}_{}" .format(cluster_name, task_id, container_runtime_id) ssm_request_params = { "Target" : target} return ssm_request_params ソースコード を読めば確かに早かったですね。。。 ということで、 aws ssm start-sessionの各ドキュメントを試します。 まずは基本のsession接続。 cl = $( aws ecs list-clusters | jq -r ' .clusterArns[0] ' ) prefix = ` echo ${cl} | sed -E ' s/.+cluster\///g ' ` taskarn = $( aws ecs list-tasks --cluster ${cl} | jq -r ' .taskArns[] ' ) taskid = ` echo ${taskarn} | sed -E ' s/.+task\/.+\///g ' ` CONTAINER_NAME = " ${prefix} -manager-container " CONTAINER_ID = $( aws ecs describe-tasks --cluster $cl --task $taskid | jq -r --arg CONTAINER_NAME $CONTAINER_NAME ' .tasks[0].containers[] | select(.name == $CONTAINER_NAME).runtimeId ' ) echo ${cl} ; \ echo ${prefix} ; \ echo ${taskarn} ; \ echo ${taskid} ; \ echo ${CONTAINER_NAME} ; echo ${CONTAINER_ID} ; aws ssm start-session --target ecs: ${prefix} _ ${taskid} _ ${CONTAINER_ID} パラメータとしてCONTAINER_IDの取得が増えておりますが、つながりました。まあ、これだけだとecs execと同じためなんのありがたさもありませんが。 なお、 AWS Fargateでのstart-session利用は AWS CLI の ソースコード を読んで得た知見であり、 AWS がサポートしている使い方ではありません。 start-session with AWS -StartPortForwardingSession では、次に、 AWS -StartPortForwardingSessionを試していきましょう。 もしできれば、接続トラブル時の切り分け作業、インターネットに公開するのに抵抗のある管理ポートへのアクセス等、いろいろ使い道があります。 #前述のおまじない aws ssm start-session --target ecs: ${prefix} _ ${taskid} _ ${CONTAINER_ID} \ --document-name AWS-StartPortForwardingSession --parameters ' {"portNumber":["80"],"localPortNumber":["18080"]} ' ドキュメントとパラメータを追加し実行です。 ということで、つながりました。まあ、cloudshellからだと使い道がありませんが（バックグランド実行のしかたがわかりませんでした）、ローカルマシンから利用するには便利そうです。 start-session with AWS -StartPortForwardingSessionToRemoteHost では、次に、 AWS -StartPortForwardingSessionToRemoteHostを試します。 「 AWS -StartPortForwardingSessionToRemoteHost」って何？って人は、 クラスメソッド様のAWS System Managerセッションマネージャーがリモートホストのポートフォワードに対応しました をご覧ください。 ざっくりいってしまうと、session managerの対象ホストから他のホストにポート フォワ ードできる優れものです。session managerに対応していないRDSへポート フォワ ードできたりします。 これができれば、ローカルのGUIDB管理ツールからRDSへ接続が可能となります( CLI だと厳しいというメンバが一定数おりそれ用の対応検討です)。 #前述のおまじない aws ssm start-session \ --target ecs: ${prefix} _ ${taskid} _ ${CONTAINER_ID} \ --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters ' {"host":["RDSエンドポイント],"portNumber":["3306"], "localPortNumber":["3306"]} ' で、実施結果ですが、、。 2022/07、2022/09で二回ほど試しておりますが、現行の AWS Fargateに入ってるエージェントバージョンが未対応とのこと。当面、ローカルからの直接RDS接続はお預けです。 番外:ECS FargateでSSMセッションマネージャーの リモートホスト のポート フォワ ード環境を構築する ECS FargateでSSMセッションマネージャーのリモートホストのポートフォワード環境を構築する にかかれているように、Fargate基盤のエージェントを利用するのではなく、ssmエージェント設定したコンテナをfargateにデプロイすれば リモートホスト へのポート フォワ ード環境の構築は可能です。 また、上記の方法以外にも、下記のような仕込みをすることで対象コンテナへのポート フォワ ードRDS接続はできそうです。 これでコンテナに[stone](https://www.gcd.org/sengoku/stone/Welcome.ja.html)でも入れておけば、Fargateのタスクを踏み台にしてデータベースなどへのアクセスができる。 参考記事: https://winebarrel.hatenablog.com/entry/2021/10/23/165720 ECS Exec with 運用 スクリプト 前述までの内容で、ポート フォワ ード、対話式でいろいろな管理オペレーションができそうということは見えてきました。 が、やはり、定型作業は単 純化 していきたいので対話式以外でのメンテナンス方式を考えていきます。 [アップデート] 実行中のコンテナに乗り込んでコマンドを実行できる「ECS Exec」が公開されました で、上の記事を見てると下記のような気になる記述が。 aws の公式ドキュメントをみてると、 /bin/sh を呼ぶ例しか書いていないのですが、任意のコマンドで呼べるんですね。 ということで、運用 スクリプト をコンテナ内に配置し呼び出してみます。 #前述のおまじない #pgdump⇒s3アップロードをしている運用スクリプトを呼び出している例 aws ecs execute-command \ --region ap-northeast-1 \ --cluster ${cl} \ --task ${taskarn} \ --container ${CONTAINER_NAME} \ --command " /bin/sh -c '/work/backup.sh backupComment' " \ --interactive #s3ダウンロード⇒pgrestoreをしている運用スクリプトを呼び出している例 aws ecs execute-command \ --region ap-northeast-1 \ --cluster ${cl} \ --task ${taskarn} \ --container ${CONTAINER_NAME} \ --command " /bin/sh -c '/work/restore.sh my-dev_20220902-153423_backupComment.dump' " \ --interactive こんな感じで、運用 スクリプト をECS Execから呼びだすことができます（なお、重い運用JOBの場合は、専用のタスクを起動した方がよいと考えております）。 ということで、既存構成に多少の手を加えることにより、ECS Execからメンテナンスをする仕組みが実装できました。 ECS Execで呼び出せるように運用 スクリプト を定義しておけば、今後下記のようなこともできそうです。 今までどおりcloudshellから Ops が手動でECS Execにて運用 スクリプト を起動する ChatOpsでECS Exec経由で運用 スクリプト を起動する チケット管理ツールのワークフローからECS Exec経由で運用 スクリプト を起動する（一部のssm run-commandはこの方式で実施しています） まとめ ということで、 AWS Fargate利用時の運用タスクの実行方法についてご紹介してみました。 執筆： @miura.toshihiko （ Shodo で執筆されました ）

はじめに ISID X（クロス） イノベーション 本部 の三浦です。 筆者の関わってる案件では、コンテナ利用、 AWS Fargate利用を進めております。 AWS Fargateのお手軽さは非常に重宝しております。 しかし、そこで問題になってくるのが、管理接続、踏み台系をどうするかです。 アプリケーション本体をせっかく AWS Fargateでやっているので、管理系接続、踏み台的な作業もできるだけ非EC2でやりたいですよね？ ということで、 AWS FargateでECS Exec、session managerをどのように運用に使っていけるか紹介いたします。 目次 はじめに 目次 想定作業、目標 基本のECS Exec実行 aws ssm start-session start-session with AWS-StartPortForwardingSession start-session with AWS-StartPortForwardingSessionToRemoteHost 番外:ECS FargateでSSMセッションマネージャーのリモートホストのポートフォワード環境を構築する ECS Exec with 運用スクリプト まとめ 想定作業、目標 下記のような想定作業、目標となります。 想定作業： RDSに接続し管理作業（pgdump、pgrestore、レコードの状態確認） ECS Fagateが使ってるEFSのファイル配置、ファイル取得 トラブル時のECSの状態把握（設定ファイル、 環境変数 等） 目標： 管理用のEC2を建てたくない 筆者が関係しているアカウントは200アカウント以上あり、各アカウントに踏み台を立てるのも、集中管理踏み台で VPC ピアリングを考えるのも非常にどちらも避けたい感覚です（というか今苦しんでます） 権限管理を AWS のロールに寄せたい ec2環境では作業時にwinパスワード、 ssh キーを払い出すような仕組みを実装しているのですが（チケット管理＋ssm）、トラブルが一定頻度で発生しています。また、利用者としても踏み台への接続情報（接続経路、IP）、認証情報を意識するのは煩雑です。 監査ログを AWS に寄せたい ECS Execでメンテナンスコマンドの手打ちを辞めたい ローカルから、ポート フォワ ード等で デバッグ 用のセッションを張りたい 基本のECS Exec実行 基本のECS Exec実行です。 工夫としてはタスクIDの取得が煩雑なため、環境情報の取得を自動取得にしているだけです。本取得条件は、1 クラスタ ーに1ecsサービスとなっているので、ECS クラスタ ー、サービスの状況に応じ、適宜クエリ条件は編集してください。 cl = $( aws ecs list-clusters | jq -r ' .clusterArns[0] ' ) prefix = ` echo ${cl} | sed -E ' s/.+cluster\///g ' ` taskarn = $( aws ecs list-tasks --cluster ${cl} | jq -r ' .taskArns[0] ' ) taskid = ` echo ${taskarn} | sed -E ' s/.+task\/.+\///g ' ` CONTAINER_NAME = " ${prefix} -manager-container " echo ${cl} ; \ echo ${prefix} ; \ echo ${taskarn} ; \ echo ${taskid} ; \ echo ${CONTAINER_NAME} ; \ aws ecs execute-command \ --region ap-northeast-1 \ --cluster ${cl} \ --task ${taskarn} \ --container ${CONTAINER_NAME} \ --command " /bin/sh " \ --interactive あと、ECS Execは、cloud shellから実行すれば、アクセスキー、シークレットキーいらずで、 AWS consoleアクセス、フェデレーション管理に寄せることができます。 aws ssm start-session 参考記事： https://winebarrel.hatenablog.com/entry/2021/10/23/165720 次に、対話式シェル以外でもいろいろできないか探っていきます。 上記ブログで下のようなコメントがあり、私は下のところで止まっておりました。 ECS ExecがどうもマネージドなSSM Agentを使って動いているということはわかっていたが、実際どうなっているのかよくわからなかった。 ・・・・ aws ssm start-sessionを実行できそうな雰囲気があるが、--targetに何を渡せばいいのかよくわからなかった。 が、続けて読んでいくと、 ソースコード を読めばtargetの書式が書かれてるとのこと。 https://github.com/aws/aws-cli/blob/c0edee0a7427b6e7b654df0696015e96105497a3/awscli/customizations/ecs/executecommand.py#L61-L73 def build_ssm_request_paramaters (response, client): cluster_name = response[ 'clusterArn' ].split( '/' )[- 1 ] task_id = response[ 'taskArn' ].split( '/' )[- 1 ] container_name = response[ 'containerName' ] # in order to get container run-time id # we need to make a call to describe-tasks container_runtime_id = \ get_container_runtime_id(client, container_name, task_id, cluster_name) target = "ecs:{}_{}_{}" .format(cluster_name, task_id, container_runtime_id) ssm_request_params = { "Target" : target} return ssm_request_params ソースコード を読めば確かに早かったですね。。。 ということで、 aws ssm start-sessionの各ドキュメントを試します。 まずは基本のsession接続。 cl = $( aws ecs list-clusters | jq -r ' .clusterArns[0] ' ) prefix = ` echo ${cl} | sed -E ' s/.+cluster\///g ' ` taskarn = $( aws ecs list-tasks --cluster ${cl} | jq -r ' .taskArns[] ' ) taskid = ` echo ${taskarn} | sed -E ' s/.+task\/.+\///g ' ` CONTAINER_NAME = " ${prefix} -manager-container " CONTAINER_ID = $( aws ecs describe-tasks --cluster $cl --task $taskid | jq -r --arg CONTAINER_NAME $CONTAINER_NAME ' .tasks[0].containers[] | select(.name == $CONTAINER_NAME).runtimeId ' ) echo ${cl} ; \ echo ${prefix} ; \ echo ${taskarn} ; \ echo ${taskid} ; \ echo ${CONTAINER_NAME} ; echo ${CONTAINER_ID} ; aws ssm start-session --target ecs: ${prefix} _ ${taskid} _ ${CONTAINER_ID} パラメータとしてCONTAINER_IDの取得が増えておりますが、つながりました。まあ、これだけだとecs execと同じためなんのありがたさもありませんが。 なお、 AWS Fargateでのstart-session利用は AWS CLI の ソースコード を読んで得た知見であり、 AWS がサポートしている使い方ではありません。 start-session with AWS -StartPortForwardingSession では、次に、 AWS -StartPortForwardingSessionを試していきましょう。 もしできれば、接続トラブル時の切り分け作業、インターネットに公開するのに抵抗のある管理ポートへのアクセス等、いろいろ使い道があります。 #前述のおまじない aws ssm start-session --target ecs: ${prefix} _ ${taskid} _ ${CONTAINER_ID} \ --document-name AWS-StartPortForwardingSession --parameters ' {"portNumber":["80"],"localPortNumber":["18080"]} ' ドキュメントとパラメータを追加し実行です。 ということで、つながりました。まあ、cloudshellからだと使い道がありませんが（バックグランド実行のしかたがわかりませんでした）、ローカルマシンから利用するには便利そうです。 start-session with AWS -StartPortForwardingSessionToRemoteHost では、次に、 AWS -StartPortForwardingSessionToRemoteHostを試します。 「 AWS -StartPortForwardingSessionToRemoteHost」って何？って人は、 クラスメソッド様のAWS System Managerセッションマネージャーがリモートホストのポートフォワードに対応しました をご覧ください。 ざっくりいってしまうと、session managerの対象ホストから他のホストにポート フォワ ードできる優れものです。session managerに対応していないRDSへポート フォワ ードできたりします。 これができれば、ローカルのGUIDB管理ツールからRDSへ接続が可能となります( CLI だと厳しいというメンバが一定数おりそれ用の対応検討です)。 #前述のおまじない aws ssm start-session \ --target ecs: ${prefix} _ ${taskid} _ ${CONTAINER_ID} \ --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters ' {"host":["RDSエンドポイント],"portNumber":["3306"], "localPortNumber":["3306"]} ' で、実施結果ですが、、。 2022/07、2022/09で二回ほど試しておりますが、現行の AWS Fargateに入ってるエージェントバージョンが未対応とのこと。当面、ローカルからの直接RDS接続はお預けです。 番外:ECS FargateでSSMセッションマネージャーの リモートホスト のポート フォワ ード環境を構築する ECS FargateでSSMセッションマネージャーのリモートホストのポートフォワード環境を構築する にかかれているように、Fargate基盤のエージェントを利用するのではなく、ssmエージェント設定したコンテナをfargateにデプロイすれば リモートホスト へのポート フォワ ード環境の構築は可能です。 また、上記の方法以外にも、下記のような仕込みをすることで対象コンテナへのポート フォワ ードRDS接続はできそうです。 これでコンテナに[stone](https://www.gcd.org/sengoku/stone/Welcome.ja.html)でも入れておけば、Fargateのタスクを踏み台にしてデータベースなどへのアクセスができる。 参考記事: https://winebarrel.hatenablog.com/entry/2021/10/23/165720 ECS Exec with 運用 スクリプト 前述までの内容で、ポート フォワ ード、対話式でいろいろな管理オペレーションができそうということは見えてきました。 が、やはり、定型作業は単 純化 していきたいので対話式以外でのメンテナンス方式を考えていきます。 [アップデート] 実行中のコンテナに乗り込んでコマンドを実行できる「ECS Exec」が公開されました で、上の記事を見てると下記のような気になる記述が。 aws の公式ドキュメントをみてると、 /bin/sh を呼ぶ例しか書いていないのですが、任意のコマンドで呼べるんですね。 ということで、運用 スクリプト をコンテナ内に配置し呼び出してみます。 #前述のおまじない #pgdump⇒s3アップロードをしている運用スクリプトを呼び出している例 aws ecs execute-command \ --region ap-northeast-1 \ --cluster ${cl} \ --task ${taskarn} \ --container ${CONTAINER_NAME} \ --command " /bin/sh -c '/work/backup.sh backupComment' " \ --interactive #s3ダウンロード⇒pgrestoreをしている運用スクリプトを呼び出している例 aws ecs execute-command \ --region ap-northeast-1 \ --cluster ${cl} \ --task ${taskarn} \ --container ${CONTAINER_NAME} \ --command " /bin/sh -c '/work/restore.sh my-dev_20220902-153423_backupComment.dump' " \ --interactive こんな感じで、運用 スクリプト をECS Execから呼びだすことができます（なお、重い運用JOBの場合は、専用のタスクを起動した方がよいと考えております）。 ということで、既存構成に多少の手を加えることにより、ECS Execからメンテナンスをする仕組みが実装できました。 ECS Execで呼び出せるように運用 スクリプト を定義しておけば、今後下記のようなこともできそうです。 今までどおりcloudshellから Ops が手動でECS Execにて運用 スクリプト を起動する ChatOpsでECS Exec経由で運用 スクリプト を起動する チケット管理ツールのワークフローからECS Exec経由で運用 スクリプト を起動する（一部のssm run-commandはこの方式で実施しています） まとめ ということで、 AWS Fargate利用時の運用タスクの実行方法についてご紹介してみました。 執筆： @miura.toshihiko （ Shodo で執筆されました ）

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

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