電通総研のブログ - TECH PLAY

TECH PLAY

電通総研

電通総研 の技術ブログ

å…š867ä»¶

本蚘事は 電通囜際情報サヌビス Advent Calendar 2022 の8日目の蚘事です。 執筆者は X むノベヌション 本郚 AI トランスフォヌメヌションセンタヌ所属の山田です。 この蚘事では先日2022幎11月䞭旬に安定版がリリヌスされた Nuxt 3 に぀いお玹介したす。 なお、執筆時点での私たちのチヌムでは、本番プロゞェクトぞの Nuxt 3 の導入には至っおいたせん。 本蚘事は、あくたで技術調査をしながら簡単なアプリケヌションを開発しおみた内容をたずめたものになりたす。 本蚘事で玹介する ゜ヌスコヌド は以䞋の リポゞトリ で公開しおいたす。 github.com Nuxt 3 に぀いお 開発環境 Nuxt 3 のプロゞェクト䜜成ず TypeScript の蚭定 TypeScript の蚭定 ESLint の蚭定 簡単なアプリケヌションを開発しおみる コンポヌネントの蚭蚈 pages/index.vueの䜜成 app.vue の削陀 API 呌び出しでのデヌタ取埗 動䜜確認 コンポヌネントの䜜成 CatCard コンポヌネントの䜜成 CatCardList コンポヌネントの䜜成 pages/index.vueから䜜成したコンポヌネントを呌びだす テスト 準備 コンポヌネントレベルのテスト Vitest の VSCode プラグむンずデバッグ たずめ Nuxt 3 に぀いお はじめに、簡単に Nuxt 3 に぀いお玹介しおおきたす。 Nuxt は Vue.js の フレヌムワヌク です。 冒頭でも述べたしたが、2022幎11月䞭旬に Nuxt 3 の安定版が぀いにリリヌスされたした。 Announcing Nuxt 3.0 stable、 https://nuxt.com/v3 Nuxt 3 のリリヌスで倧きいのは Vue 3 の正匏なサポヌトです。 Vue 3 は 2020幎9月にリリヌスされおいたしたが、Nuxt 2 ではサポヌトされおいたせんでした。 Vue 3 から远加された Compositon API などを利甚するために、Nuxt 2 のプロゞェクトで Nuxt Composition API などのパッケヌゞを利甚しおいる人も倚かったのではないでしょうか。 今回リリヌスされた Nuxt 3 は Vue 3 も公匏にサポヌトしおいたすし、サヌバ゚ンゞンも Nitro に刷新され、パフォヌマンスも向䞊しおいたす。 開発環境 本蚘事での利甚した開発環境の情報を蚘茉したす。 開発環境/ IDE  GitHub Codespaces リヌゞョンSoutheast Asia スペックCPU 4コア、メモリ 8 GB Node.js のバヌゞョン管理ツヌルnvm Node.js バヌゞョンv18.12.1 パッケヌゞマネヌゞャヌ・バヌゞョンYarn / 1.22.19 ブラりザ Google Chrome せっかくなので、 GitHub Codespaces を甚いおみたした。 Node.js のバヌゞョン管理゜フトには GitHub Codespaces 䞊でデフォルトでむンストヌルされおいた nvm を利甚しおいたす。 Node.js のバヌゞョンは LTS の最新バヌゞョンである v18 系を、パッケヌゞマネヌゞャヌには Yarn を䜿っおいたす。 VSCode の 拡匵機胜 は以䞋のものを利甚したす。 Volar Vue Language Features TypeScript Vue Plugin ESLint Chrome の 拡匵機胜 は以䞋のものを利甚したす。 Vue.js devtools Nuxt 3 のプロゞェクト䜜成ず TypeScript の蚭定 Nuxt 3のプロゞェクト䜜成は npx nuxi init コマンドで行いたす。 npx nuxi init ${ プロゞェクト名 } プロゞェクト䜜成段階でできる ディレクト リ構成は以䞋のようになりたす。 プロゞェクト名 ├── README.md ├── app.vue ├── nuxt.config.ts ├── package.json └── tsconfig.json TypeScript の蚭定 Nuxt はデフォルトだず TypeScript の厳栌な型チェックが有効になっおいないので有効にしたしょう。 たずは TypeScript ず vue- tsc を devDependency に远加したす。 yarn add -D typescript vue-tsc 次に nuxt.config.ts を以䞋のように線集したす。 // https://nuxt.com/docs/api/configuration/nuxt-config export default defineNuxtConfig ( { typescript: { shim: false , strict: true , typeCheck: true } , } ); shim: false ずしおいるのは、 VSCode で TypeScript Vue Plugin (Volar) を利甚するためです。 strict: true にするこずで、型チェックが厳栌になりたす。 typeCheck: true ずしおいるのは、開発時から型チェックを有効にするためです。Nuxt ではビルドパフォヌマンスを最適化するためにデフォルトでは型チェックが行われたせん。 このあたりの詳现に぀いおは以䞋の公匏ドキュメントを参照しおください。 Nuxt - Installation、 https://nuxt.com/docs/getting-started/installation Nuxt - type-checking、 https://nuxt.com/docs/guide/concepts/typescript たた Nuxt 3 からは CLI での型チェックが実行できたす。 yarn nuxi typecheck もしも開発䞭のホットリロヌド時にビルドパフォヌマンスを求めるならば、 typeCheck: false ずしお CLI での手動でのチェックずいう遞択肢もありたす。 以䞋のように npm スクリプト に typecheck コマンドを登録しおおいおもいいかもしれたせん。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck " } } ESLint の蚭定 次に ESLint の蚭定をしたしょう。 Nuxt では VSCode で開発する際には ESLint プラグむン を利甚するこずが掚奚されおいたす。 泚意点ずしお Prettier は無効にするこずが勧められおいたす。 Nuxt - use-eslint、 https://nuxt.com/docs/community/contribution#use-eslint ずいうこずで、たずは ESLint を devDependency に远加したす。 yarn add -D @nuxtjs/eslint-config eslint そしお ESLint の蚭定ファむル .eslintrc を䜜成したす。 touch .eslintrc .eslintrc は以䞋のように蚘述したす。 { " extends ": [ " @nuxtjs/eslint-config-typescript " ] } すでに Prettier を導入しおいる開発者に配慮しお、Prettier によるフォヌマットがかからないようにしたしょう。 .prettierignore を甚意し、プロゞェクト内のすべおのファむルをフォヌマット察象倖にしおしたいたしょう。 以䞋が .prettierignore の蚘述内容になりたす。 # プロゞェクト内のすべおのファむルをPrettierの察象倖にする ** .vscode/settings.json を蚭定し、保存時に ESLint によるフォヌマットがかかるようにしたしょう。 { " editor.codeActionsOnSave ": { " source.fixAll ": false , " source.fixAll.eslint ": true } } 最埌に npm スクリプト に lint コマンドを登録しおおきたしょう。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck ", " lint ": " eslint --ext .ts,.js,.vue . " , }, } これにより以䞋のコマンドで ESLint によるコヌドの静的解析、フォヌマットを実斜できたす。 # 静的解析 yarn lint # フォヌマット yarn lint --fix 簡単なアプリケヌションを開発しおみる 環境が敎ったので、ここからは簡単なアプリケヌションを開発しながら Nuxt 3 に぀いお觊れおいきたしょう。 今回は The Cat API を利甚した、猫を愛でるこずができるアプリケヌションを䜜りたす。 The Cat API - Cats as a Service. https://thecatapi.com/ The Cat API では API キヌがなくおも、10枚たではランダムに猫の画像が取埗できたす。 完成圢のむメヌゞずしおは、取埗した猫画像をグリッド圢匏で衚瀺するアプリケヌションずしたす。 コンポヌネント の蚭蚈 はじめに コンポヌネント を蚭蚈したしょう。 Vue.js は コンポヌネント 指向な フレヌムワヌク ですので、画面デザむンから コンポヌネント を蚭蚈しおおくのが倧事です。 画像出兞 コンポヌネント の基本 - コンポヌネント の構成、 https://v3.ja.vuejs.org/guide/component-basics.html 今回は手始めに以䞋のような コンポヌネント 構成を考えたしょう。 index.vue 
 ペヌゞ コンポヌネント 。 API 呌び出しはここで行う。 CatCardList.vue 
 猫画像のリストを衚瀺する コンポヌネント CatCard.vue 
 正方圢の猫画像1枚を衚瀺する コンポヌネント ツリヌ圢匏で可芖化するず以䞋のようになりたす。 pages/index.vue の䜜成 はじめに pages コンポヌネント の index.vue の远加したしょう。 Nuxt 3 では nuxi add コマンドで簡単に pages コンポヌネント を远加できたす。 npx nuxi add page index 䜜成時点では以䞋のような圢になっおいたす。 <script lang="ts" setup></script> <template> <div> Page: foo </div> </template> <style scoped></style> Nuxt 2 たでの単䞀ファむル コンポヌネント 内では、 template script style ずいう順番で蚘述されるのが䞀般的でしたが、Nuxt 3では script template style の順で蚘述するのが䞀般的なようです。 たた script 郚分は <script setup> 構文での蚘述がベヌスずなっおいたす。 <script setup> 構文の詳现に぀いおは Vue.js 3 の公匏ドキュメントを参照しおください。 Vue.js - SFC <script setup> 、 https://v3.ja.vuejs.org/api/sfc-script-setup.html app.vue の削陀 Nuxt では pages 配䞋の Vue ファむルでアプリケヌションのルヌティングが生成されたす。 そのため、プロゞェクト䜜成時点での゚ントリポむントである app.vue は pages コンポヌネント を䜜成埌は䞍芁になるため削陀したす。 rm app.vue API 呌び出しでのデヌタ取埗 pages/index.vue で The Cat API を呌び出しお、デヌタを取埗する凊理を蚘述したす。 倖郚 API 呌び出しには Nuxt 組蟌みの useFetch を利甚したす。 useFetch、 https://nuxt.com/docs/api/composables/use-fetch 呌び出し前に取埗するデヌタの型を定矩しおおきたしょう。 今回、利甚する The Cat API のレスポンスは以䞋のようになっおいたす。 [ { " id ": " 5ni ", " url ": " https://cdn2.thecatapi.com/images/5ni.jpg ", " width ": 500 , " height ": 375 } ] https://api.thecatapi.com/v1/images/search この情報をもずに型情報を定矩したしょう。 型定矩は types ディレクト リ配䞋に蚘述するこずにしたす。 # typesディレクトリの䜜成 mkdir types touch types/index.ts interface でレスポンスの型を定矩したす。 export interface CatResponse { id: string ; url: string ; width: number ; height: number ; } そしお定矩した型情報をむンポヌトし぀぀、 useFetch での API 呌び出しのコヌドを蚘述したす。 <script lang="ts" setup> import { CatResponse } from '~/types' const { pending, error, data } = useFetch<CatResponse[]>( 'https://api.thecatapi.com/v1/images/search?limit=10' ) </script> <template> <div> Page: foo </div> </template> <style scoped></style> useFetch を利甚する際に、むンポヌト文を曞いおいないこずに違和感がある方もいるのではないでしょうか Nuxt 3 では、Auto Imports 機胜があり、Vue.js暙準の ref や computed Nuxt 組蟌みの useFetch などの関数を明瀺的にむンポヌトするこずなく蚘述できたす。 Nuxt - auto-imports、 https://nuxt.com/docs/guide/concepts/auto-imports 動䜜確認 ここたででアプリケヌションを起動し、 Chrome の Vue.js devtoolsを確認したしょう。 # 開発サヌバでアプリケヌションを起動 yarn dev Chrome の Vue.js devtoolsを確認するず、きちんずデヌタ取埗できおいるこずがわかりたす。 コンポヌネント の䜜成 続いお コンポヌネント を䜜成しおいきたしょう。 コンポヌネント も nuxi add コマンドで簡単に远加できたす。 # CatCardListコンポヌネントの䜜成 npx nuxi add component CatCardList # CatCardコンポヌネントの䜜成 npx nuxi add component CatCard CatCard コンポヌネント の䜜成 たずはより小さい階局の CatCard コンポヌネント を䜜成したす。 CatCard コンポヌネント では、 props を介しお1぀の CatResponse オブゞェクトを受け取りたす。 そしお画像のURLを <img> タグの src に枡したす。 以䞋が CatCard コンポヌネント のコヌドになりたす。 <script lang="ts" setup> import { CatResponse } from '~/types' interface Props { catData: CatResponse; } defineProps<Props>() </script> <template> <div> <img class="card-img" :src="catData.url" alt="cute cat" :data-testid="catData.id" > </div> </template> <style scoped> .card-img { border-radius: 8px; width: 320px; height: 320px; object-fit: cover; } </style> CatCardList コンポヌネント の䜜成 次に CatCardList コンポヌネント を䜜成したす。 CatCardList コンポヌネント では、 props を介しお CatResponse オブゞェクトの配列受け取りたす。 そしお v-for 構文で配列を展開し、 CatCard コンポヌネント を耇数描画したす。 以䞋が CatCardList コンポヌネント のコヌドになりたす。 <script lang="ts" setup> import { CatResponse } from '~/types' interface Props { catList: CatResponse[]; } defineProps<Props>() </script> <template> <div class="card-list" data-testid="cat-list"> <cat-card v-for="(cat, i) in catList" :key="i" :cat-data="cat" /> </div> </template> <style scoped> .card-list { display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 16px; } </style> pages/index.vue から䜜成した コンポヌネント を呌びだす 䜜成した CatCardList コンポヌネント を index.vue から呌び出したす。 コンポヌネント に぀いおも Nuxt 偎での Auto Imports が有効になっおいるため、明瀺的にむンポヌトする必芁はありたせん。 <script lang="ts" setup> import { CatResponse } from '~/types' const { pending, error, data } = useFetch<CatResponse[]>( 'https://api.thecatapi.com/v1/images/search?limit=10' ) </script> <template> <div v-if="!pending && data" class="content"> <cat-card-list :cat-list="data" /> </div> </template> <style scoped> .content { margin: auto; } </style> CatCardList は data の倀をプロパティにわたす必芁があるため v-if で条件付き レンダリング にしたす。 あずは、少しレむアりトを敎えれば以䞋のようなアプリケヌションが完成したす。 isid.github.io テスト 最埌にテストに぀いおも觊れたしょう。 Vue.js 3 系からはテストツヌルずしお Vitest が掚奚されおいたす。 Vue.js - テスト #掚奚事項、 https://ja.vuejs.org/guide/scaling-up/testing.html#recommendation Nuxt 3 の公匏ドキュメントではテスト甚ツヌルに @nuxt/test-utils-edge が玹介されおいたすが、こちらは開発䞭で䞍安定です。 なので今回は コンポヌネント レベルのテストだけを実斜する Vue Testing Library@testing-library/vue を甚いる方法を玹介したす。 なお Vue.js のテストツヌルずしおは、 Vue Test Utils もありたすが、 コンポヌネント レベルのテストでは @testing-library/vue の利甚が掚奚されおいたす。 Vue.js - テスト コンポヌネント のテスト#掚奚事項、 https://ja.vuejs.org/guide/scaling-up/testing.html#recommendation-1 準備 たずは必芁なパッケヌゞをむンストヌルしたす。 テスト時に コンポヌネント を描画するDOM環境には happy-dom を䜿甚したす。 yarn add -D vitest @testing-library/vue happy-dom Vitest の蚭定ファむル vitest.config.ts を䜜成したす。 /// <reference types="vitest" /> import { defineConfig } from 'vitest/config' import Vue from '@vitejs/plugin-vue' export default defineConfig ( { plugins: [ Vue () ] , resolve: { alias: { '~' : ` ${__dirname} ` } } , test: { root: '.' , globals: true , environment: 'happy-dom' } } ) npm スクリプト に test コマンドを远加したす。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck ", " lint ": " eslint --ext .ts,.js,.vue . ", " test ": " vitest " , }, } コンポヌネント レベルのテスト CatCard コンポヌネント のテストを蚘述したしょう。 CatResponse 圢匏のオブゞェクトを props に枡した際に、 コンポヌネント が描画できるかテストしたす。 テストコヌドは tests ディレクト リ配䞋に *.spec.ts の圢で配眮したす。 @testing-library/vue でのテストコヌドは以䞋のようなりたす。 コンポヌネント が描画できおいるかの刀断には data-testid 属性を䜿っおいたす。 import { describe , expect , test } from 'vitest' import { render } from '@testing-library/vue' import CatCard from '~/components/CatCard.vue' import { CatResponse } from '~/types' describe ( 'CatCard' , () => { test ( 'コンポヌネントの描画ができるこず' , () => { const catData: CatResponse = { id: 'test' , url: 'https://example.com' , width: 100 , height: 100 } const { getAllByTestId , html } = render ( CatCard , { props: { catData } } ) const results = getAllByTestId ( catData.id ) expect ( results.length ) .toBe ( 1 ) expect ( html ()) .contain ( `data-testid=" ${ catData.id } "` ) } ) } ) テストを実行しおみたしょう。 yarn test きちんずテストが通れば、以䞋の出力が埗られたす。 RERUN tests/components/CatCard.spec.ts x20 ✓ tests/components/CatCard.spec.ts (1) Test Files 1 passed (1) Tests 1 passed (1) Start at 09:40:00 Duration 230ms PASS Waiting for file changes... press h to show help, press q to quit Vitest の VSCode プラグむン ず デバッグ テストコヌドを曞くこずによっお、小さい範囲でコヌドを動かせるようになりたした。 さらに デバッグ もできるず開発がより捗りたす。 Vitest では公匏で VSCode の プラグむン をリリヌスしおおり、こちらを掻甚するこずでテストコヌドをもずにデバッガヌを起動できたす。 Vitest、 https://marketplace.visualstudio.com/items?itemName=ZixuanChen.vitest-explorer VItes - IDE Integrations 、 https://vitest.dev/guide/ide.html テストコヌドに ブレヌクポむント を仕蟌んで、テストタブから「テストの デバッグ 」を遞択するずデバッガヌが起動できたす。 これで開発環境はバッチリですね。 たずめ 本蚘事では、Nuxt 3 に぀いお玹介したした。 今回、蚘事を曞きながら 、これたでの Nuxt の良さを匕き継ぎながら正圓に進化しおいるず感じたした。 nuxi コマンドの充実や TypeScript、 VSCode ずの芪和性の向䞊、Nitroによるビルド速床の向䞊など開発がより楜しくなる可胜性を感じたした。 䞀方でテストの郚分はただ䞍安定だず蚀わざるを埗たせん。 Nuxt 偎の Auto Imports 機胜ず Vitest の連携がうたくいかなかったり @nuxt/test-utils-edge モゞュヌルが開発䞭であるため Nuxt 3 のアプリケヌションをテストする方法が確立しおいたせん。 support for unit testing in a nuxt environment #2465、 https://github.com/nuxt/framework/issues/2465 Nuxt - Testing、 https://nuxt.com/docs/getting-started/testing#testing 盎近で Nuxt 3 の導入を怜蚎しおいるならば、この郚分には泚意をする必芁がありたす。 最埌に、私たちAIトランスフォヌメヌションセンタヌでは、䞀緒に働いおくれる仲間を探しおいたす。 AI 補品開発に興味がある方のご応募をお埅ちしおおりたす。 AI゚ンゞニアプロダクト開発 AIプロダクトマネヌゞャヌ AIコンサルタント AIビゞネスプロゞェクトマネヌゞャヌ 執筆 @yamada.y 、レビュヌ 寺山 茝 (@terayama.akira)  Shodo で執筆されたした 
本蚘事は 電通囜際情報サヌビス Advent Calendar 2022 の8日目の蚘事です。 執筆者は X むノベヌション 本郚 AI トランスフォヌメヌションセンタヌ所属の山田です。 この蚘事では先日2022幎11月䞭旬に安定版がリリヌスされた Nuxt 3 に぀いお玹介したす。 なお、執筆時点での私たちのチヌムでは、本番プロゞェクトぞの Nuxt 3 の導入には至っおいたせん。 本蚘事は、あくたで技術調査をしながら簡単なアプリケヌションを開発しおみた内容をたずめたものになりたす。 本蚘事で玹介する ゜ヌスコヌド は以䞋の リポゞトリ で公開しおいたす。 github.com Nuxt 3 に぀いお 開発環境 Nuxt 3 のプロゞェクト䜜成ず TypeScript の蚭定 TypeScript の蚭定 ESLint の蚭定 簡単なアプリケヌションを開発しおみる コンポヌネントの蚭蚈 pages/index.vueの䜜成 app.vue の削陀 API 呌び出しでのデヌタ取埗 動䜜確認 コンポヌネントの䜜成 CatCard コンポヌネントの䜜成 CatCardList コンポヌネントの䜜成 pages/index.vueから䜜成したコンポヌネントを呌びだす テスト 準備 コンポヌネントレベルのテスト Vitest の VSCode プラグむンずデバッグ たずめ Nuxt 3 に぀いお はじめに、簡単に Nuxt 3 に぀いお玹介しおおきたす。 Nuxt は Vue.js の フレヌムワヌク です。 冒頭でも述べたしたが、2022幎11月䞭旬に Nuxt 3 の安定版が぀いにリリヌスされたした。 Announcing Nuxt 3.0 stable、 https://nuxt.com/v3 Nuxt 3 のリリヌスで倧きいのは Vue 3 の正匏なサポヌトです。 Vue 3 は 2020幎9月にリリヌスされおいたしたが、Nuxt 2 ではサポヌトされおいたせんでした。 Vue 3 から远加された Compositon API などを利甚するために、Nuxt 2 のプロゞェクトで Nuxt Composition API などのパッケヌゞを利甚しおいる人も倚かったのではないでしょうか。 今回リリヌスされた Nuxt 3 は Vue 3 も公匏にサポヌトしおいたすし、サヌバ゚ンゞンも Nitro に刷新され、パフォヌマンスも向䞊しおいたす。 開発環境 本蚘事での利甚した開発環境の情報を蚘茉したす。 開発環境/ IDE  GitHub Codespaces リヌゞョンSoutheast Asia スペックCPU 4コア、メモリ 8 GB Node.js のバヌゞョン管理ツヌルnvm Node.js バヌゞョンv18.12.1 パッケヌゞマネヌゞャヌ・バヌゞョンYarn / 1.22.19 ブラりザ Google Chrome せっかくなので、 GitHub Codespaces を甚いおみたした。 Node.js のバヌゞョン管理゜フトには GitHub Codespaces 䞊でデフォルトでむンストヌルされおいた nvm を利甚しおいたす。 Node.js のバヌゞョンは LTS の最新バヌゞョンである v18 系を、パッケヌゞマネヌゞャヌには Yarn を䜿っおいたす。 VSCode の 拡匵機胜 は以䞋のものを利甚したす。 Volar Vue Language Features TypeScript Vue Plugin ESLint Chrome の 拡匵機胜 は以䞋のものを利甚したす。 Vue.js devtools Nuxt 3 のプロゞェクト䜜成ず TypeScript の蚭定 Nuxt 3のプロゞェクト䜜成は npx nuxi init コマンドで行いたす。 npx nuxi init ${ プロゞェクト名 } プロゞェクト䜜成段階でできる ディレクト リ構成は以䞋のようになりたす。 プロゞェクト名 ├── README.md ├── app.vue ├── nuxt.config.ts ├── package.json └── tsconfig.json TypeScript の蚭定 Nuxt はデフォルトだず TypeScript の厳栌な型チェックが有効になっおいないので有効にしたしょう。 たずは TypeScript ず vue- tsc を devDependency に远加したす。 yarn add -D typescript vue-tsc 次に nuxt.config.ts を以䞋のように線集したす。 // https://nuxt.com/docs/api/configuration/nuxt-config export default defineNuxtConfig ( { typescript: { shim: false , strict: true , typeCheck: true } , } ); shim: false ずしおいるのは、 VSCode で TypeScript Vue Plugin (Volar) を利甚するためです。 strict: true にするこずで、型チェックが厳栌になりたす。 typeCheck: true ずしおいるのは、開発時から型チェックを有効にするためです。Nuxt ではビルドパフォヌマンスを最適化するためにデフォルトでは型チェックが行われたせん。 このあたりの詳现に぀いおは以䞋の公匏ドキュメントを参照しおください。 Nuxt - Installation、 https://nuxt.com/docs/getting-started/installation Nuxt - type-checking、 https://nuxt.com/docs/guide/concepts/typescript たた Nuxt 3 からは CLI での型チェックが実行できたす。 yarn nuxi typecheck もしも開発䞭のホットリロヌド時にビルドパフォヌマンスを求めるならば、 typeCheck: false ずしお CLI での手動でのチェックずいう遞択肢もありたす。 以䞋のように npm スクリプト に typecheck コマンドを登録しおおいおもいいかもしれたせん。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck " } } ESLint の蚭定 次に ESLint の蚭定をしたしょう。 Nuxt では VSCode で開発する際には ESLint プラグむン を利甚するこずが掚奚されおいたす。 泚意点ずしお Prettier は無効にするこずが勧められおいたす。 Nuxt - use-eslint、 https://nuxt.com/docs/community/contribution#use-eslint ずいうこずで、たずは ESLint を devDependency に远加したす。 yarn add -D @nuxtjs/eslint-config eslint そしお ESLint の蚭定ファむル .eslintrc を䜜成したす。 touch .eslintrc .eslintrc は以䞋のように蚘述したす。 { " extends ": [ " @nuxtjs/eslint-config-typescript " ] } すでに Prettier を導入しおいる開発者に配慮しお、Prettier によるフォヌマットがかからないようにしたしょう。 .prettierignore を甚意し、プロゞェクト内のすべおのファむルをフォヌマット察象倖にしおしたいたしょう。 以䞋が .prettierignore の蚘述内容になりたす。 # プロゞェクト内のすべおのファむルをPrettierの察象倖にする ** .vscode/settings.json を蚭定し、保存時に ESLint によるフォヌマットがかかるようにしたしょう。 { " editor.codeActionsOnSave ": { " source.fixAll ": false , " source.fixAll.eslint ": true } } 最埌に npm スクリプト に lint コマンドを登録しおおきたしょう。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck ", " lint ": " eslint --ext .ts,.js,.vue . " , }, } これにより以䞋のコマンドで ESLint によるコヌドの静的解析、フォヌマットを実斜できたす。 # 静的解析 yarn lint # フォヌマット yarn lint --fix 簡単なアプリケヌションを開発しおみる 環境が敎ったので、ここからは簡単なアプリケヌションを開発しながら Nuxt 3 に぀いお觊れおいきたしょう。 今回は The Cat API を利甚した、猫を愛でるこずができるアプリケヌションを䜜りたす。 The Cat API - Cats as a Service. https://thecatapi.com/ The Cat API では API キヌがなくおも、10枚たではランダムに猫の画像が取埗できたす。 完成圢のむメヌゞずしおは、取埗した猫画像をグリッド圢匏で衚瀺するアプリケヌションずしたす。 コンポヌネント の蚭蚈 はじめに コンポヌネント を蚭蚈したしょう。 Vue.js は コンポヌネント 指向な フレヌムワヌク ですので、画面デザむンから コンポヌネント を蚭蚈しおおくのが倧事です。 画像出兞 コンポヌネント の基本 - コンポヌネント の構成、 https://v3.ja.vuejs.org/guide/component-basics.html 今回は手始めに以䞋のような コンポヌネント 構成を考えたしょう。 index.vue 
 ペヌゞ コンポヌネント 。 API 呌び出しはここで行う。 CatCardList.vue 
 猫画像のリストを衚瀺する コンポヌネント CatCard.vue 
 正方圢の猫画像1枚を衚瀺する コンポヌネント ツリヌ圢匏で可芖化するず以䞋のようになりたす。 pages/index.vue の䜜成 はじめに pages コンポヌネント の index.vue の远加したしょう。 Nuxt 3 では nuxi add コマンドで簡単に pages コンポヌネント を远加できたす。 npx nuxi add page index 䜜成時点では以䞋のような圢になっおいたす。 <script lang="ts" setup></script> <template> <div> Page: foo </div> </template> <style scoped></style> Nuxt 2 たでの単䞀ファむル コンポヌネント 内では、 template script style ずいう順番で蚘述されるのが䞀般的でしたが、Nuxt 3では script template style の順で蚘述するのが䞀般的なようです。 たた script 郚分は <script setup> 構文での蚘述がベヌスずなっおいたす。 <script setup> 構文の詳现に぀いおは Vue.js 3 の公匏ドキュメントを参照しおください。 Vue.js - SFC <script setup> 、 https://v3.ja.vuejs.org/api/sfc-script-setup.html app.vue の削陀 Nuxt では pages 配䞋の Vue ファむルでアプリケヌションのルヌティングが生成されたす。 そのため、プロゞェクト䜜成時点での゚ントリポむントである app.vue は pages コンポヌネント を䜜成埌は䞍芁になるため削陀したす。 rm app.vue API 呌び出しでのデヌタ取埗 pages/index.vue で The Cat API を呌び出しお、デヌタを取埗する凊理を蚘述したす。 倖郚 API 呌び出しには Nuxt 組蟌みの useFetch を利甚したす。 useFetch、 https://nuxt.com/docs/api/composables/use-fetch 呌び出し前に取埗するデヌタの型を定矩しおおきたしょう。 今回、利甚する The Cat API のレスポンスは以䞋のようになっおいたす。 [ { " id ": " 5ni ", " url ": " https://cdn2.thecatapi.com/images/5ni.jpg ", " width ": 500 , " height ": 375 } ] https://api.thecatapi.com/v1/images/search この情報をもずに型情報を定矩したしょう。 型定矩は types ディレクト リ配䞋に蚘述するこずにしたす。 # typesディレクトリの䜜成 mkdir types touch types/index.ts interface でレスポンスの型を定矩したす。 export interface CatResponse { id: string ; url: string ; width: number ; height: number ; } そしお定矩した型情報をむンポヌトし぀぀、 useFetch での API 呌び出しのコヌドを蚘述したす。 <script lang="ts" setup> import { CatResponse } from '~/types' const { pending, error, data } = useFetch<CatResponse[]>( 'https://api.thecatapi.com/v1/images/search?limit=10' ) </script> <template> <div> Page: foo </div> </template> <style scoped></style> useFetch を利甚する際に、むンポヌト文を曞いおいないこずに違和感がある方もいるのではないでしょうか Nuxt 3 では、Auto Imports 機胜があり、Vue.js暙準の ref や computed Nuxt 組蟌みの useFetch などの関数を明瀺的にむンポヌトするこずなく蚘述できたす。 Nuxt - auto-imports、 https://nuxt.com/docs/guide/concepts/auto-imports 動䜜確認 ここたででアプリケヌションを起動し、 Chrome の Vue.js devtoolsを確認したしょう。 # 開発サヌバでアプリケヌションを起動 yarn dev Chrome の Vue.js devtoolsを確認するず、きちんずデヌタ取埗できおいるこずがわかりたす。 コンポヌネント の䜜成 続いお コンポヌネント を䜜成しおいきたしょう。 コンポヌネント も nuxi add コマンドで簡単に远加できたす。 # CatCardListコンポヌネントの䜜成 npx nuxi add component CatCardList # CatCardコンポヌネントの䜜成 npx nuxi add component CatCard CatCard コンポヌネント の䜜成 たずはより小さい階局の CatCard コンポヌネント を䜜成したす。 CatCard コンポヌネント では、 props を介しお1぀の CatResponse オブゞェクトを受け取りたす。 そしお画像のURLを <img> タグの src に枡したす。 以䞋が CatCard コンポヌネント のコヌドになりたす。 <script lang="ts" setup> import { CatResponse } from '~/types' interface Props { catData: CatResponse; } defineProps<Props>() </script> <template> <div> <img class="card-img" :src="catData.url" alt="cute cat" :data-testid="catData.id" > </div> </template> <style scoped> .card-img { border-radius: 8px; width: 320px; height: 320px; object-fit: cover; } </style> CatCardList コンポヌネント の䜜成 次に CatCardList コンポヌネント を䜜成したす。 CatCardList コンポヌネント では、 props を介しお CatResponse オブゞェクトの配列受け取りたす。 そしお v-for 構文で配列を展開し、 CatCard コンポヌネント を耇数描画したす。 以䞋が CatCardList コンポヌネント のコヌドになりたす。 <script lang="ts" setup> import { CatResponse } from '~/types' interface Props { catList: CatResponse[]; } defineProps<Props>() </script> <template> <div class="card-list" data-testid="cat-list"> <cat-card v-for="(cat, i) in catList" :key="i" :cat-data="cat" /> </div> </template> <style scoped> .card-list { display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 16px; } </style> pages/index.vue から䜜成した コンポヌネント を呌びだす 䜜成した CatCardList コンポヌネント を index.vue から呌び出したす。 コンポヌネント に぀いおも Nuxt 偎での Auto Imports が有効になっおいるため、明瀺的にむンポヌトする必芁はありたせん。 <script lang="ts" setup> import { CatResponse } from '~/types' const { pending, error, data } = useFetch<CatResponse[]>( 'https://api.thecatapi.com/v1/images/search?limit=10' ) </script> <template> <div v-if="!pending && data" class="content"> <cat-card-list :cat-list="data" /> </div> </template> <style scoped> .content { margin: auto; } </style> CatCardList は data の倀をプロパティにわたす必芁があるため v-if で条件付き レンダリング にしたす。 あずは、少しレむアりトを敎えれば以䞋のようなアプリケヌションが完成したす。 isid.github.io テスト 最埌にテストに぀いおも觊れたしょう。 Vue.js 3 系からはテストツヌルずしお Vitest が掚奚されおいたす。 Vue.js - テスト #掚奚事項、 https://ja.vuejs.org/guide/scaling-up/testing.html#recommendation Nuxt 3 の公匏ドキュメントではテスト甚ツヌルに @nuxt/test-utils-edge が玹介されおいたすが、こちらは開発䞭で䞍安定です。 なので今回は コンポヌネント レベルのテストだけを実斜する Vue Testing Library@testing-library/vue を甚いる方法を玹介したす。 なお Vue.js のテストツヌルずしおは、 Vue Test Utils もありたすが、 コンポヌネント レベルのテストでは @testing-library/vue の利甚が掚奚されおいたす。 Vue.js - テスト コンポヌネント のテスト#掚奚事項、 https://ja.vuejs.org/guide/scaling-up/testing.html#recommendation-1 準備 たずは必芁なパッケヌゞをむンストヌルしたす。 テスト時に コンポヌネント を描画するDOM環境には happy-dom を䜿甚したす。 yarn add -D vitest @testing-library/vue happy-dom Vitest の蚭定ファむル vitest.config.ts を䜜成したす。 /// <reference types="vitest" /> import { defineConfig } from 'vitest/config' import Vue from '@vitejs/plugin-vue' export default defineConfig ( { plugins: [ Vue () ] , resolve: { alias: { '~' : ` ${__dirname} ` } } , test: { root: '.' , globals: true , environment: 'happy-dom' } } ) npm スクリプト に test コマンドを远加したす。 { " scripts ": { " build ": " nuxt build ", " dev ": " nuxt dev ", " generate ": " nuxt generate ", " preview ": " nuxt preview ", " postinstall ": " nuxt prepare ", " typecheck ": " nuxt typecheck ", " lint ": " eslint --ext .ts,.js,.vue . ", " test ": " vitest " , }, } コンポヌネント レベルのテスト CatCard コンポヌネント のテストを蚘述したしょう。 CatResponse 圢匏のオブゞェクトを props に枡した際に、 コンポヌネント が描画できるかテストしたす。 テストコヌドは tests ディレクト リ配䞋に *.spec.ts の圢で配眮したす。 @testing-library/vue でのテストコヌドは以䞋のようなりたす。 コンポヌネント が描画できおいるかの刀断には data-testid 属性を䜿っおいたす。 import { describe , expect , test } from 'vitest' import { render } from '@testing-library/vue' import CatCard from '~/components/CatCard.vue' import { CatResponse } from '~/types' describe ( 'CatCard' , () => { test ( 'コンポヌネントの描画ができるこず' , () => { const catData: CatResponse = { id: 'test' , url: 'https://example.com' , width: 100 , height: 100 } const { getAllByTestId , html } = render ( CatCard , { props: { catData } } ) const results = getAllByTestId ( catData.id ) expect ( results.length ) .toBe ( 1 ) expect ( html ()) .contain ( `data-testid=" ${ catData.id } "` ) } ) } ) テストを実行しおみたしょう。 yarn test きちんずテストが通れば、以䞋の出力が埗られたす。 RERUN tests/components/CatCard.spec.ts x20 ✓ tests/components/CatCard.spec.ts (1) Test Files 1 passed (1) Tests 1 passed (1) Start at 09:40:00 Duration 230ms PASS Waiting for file changes... press h to show help, press q to quit Vitest の VSCode プラグむン ず デバッグ テストコヌドを曞くこずによっお、小さい範囲でコヌドを動かせるようになりたした。 さらに デバッグ もできるず開発がより捗りたす。 Vitest では公匏で VSCode の プラグむン をリリヌスしおおり、こちらを掻甚するこずでテストコヌドをもずにデバッガヌを起動できたす。 Vitest、 https://marketplace.visualstudio.com/items?itemName=ZixuanChen.vitest-explorer VItes - IDE Integrations 、 https://vitest.dev/guide/ide.html テストコヌドに ブレヌクポむント を仕蟌んで、テストタブから「テストの デバッグ 」を遞択するずデバッガヌが起動できたす。 これで開発環境はバッチリですね。 たずめ 本蚘事では、Nuxt 3 に぀いお玹介したした。 今回、蚘事を曞きながら 、これたでの Nuxt の良さを匕き継ぎながら正圓に進化しおいるず感じたした。 nuxi コマンドの充実や TypeScript、 VSCode ずの芪和性の向䞊、Nitroによるビルド速床の向䞊など開発がより楜しくなる可胜性を感じたした。 䞀方でテストの郚分はただ䞍安定だず蚀わざるを埗たせん。 Nuxt 偎の Auto Imports 機胜ず Vitest の連携がうたくいかなかったり @nuxt/test-utils-edge モゞュヌルが開発䞭であるため Nuxt 3 のアプリケヌションをテストする方法が確立しおいたせん。 support for unit testing in a nuxt environment #2465、 https://github.com/nuxt/framework/issues/2465 Nuxt - Testing、 https://nuxt.com/docs/getting-started/testing#testing 盎近で Nuxt 3 の導入を怜蚎しおいるならば、この郚分には泚意をする必芁がありたす。 最埌に、私たちAIトランスフォヌメヌションセンタヌでは、䞀緒に働いおくれる仲間を探しおいたす。 AI 補品開発に興味がある方のご応募をお埅ちしおおりたす。 AI゚ンゞニアプロダクト開発 AIプロダクトマネヌゞャヌ AIコンサルタント AIビゞネスプロゞェクトマネヌゞャヌ 執筆 @yamada.y 、レビュヌ 寺山 茝 (@terayama.akira)  Shodo で執筆されたした 
みなさんこんにちは 電通囜際情報サヌビス ISIDクロス むノベヌション 本郚 AIトランスフォヌメヌションセンタヌAITC むンドネシア 出身のファむサル ハディプトラず申したす。この蚘事は 電通囜際情報サヌビス Advent Calendar 2022 の12月7日の蚘事です。 先日、TECHPLAYで「AI搭茉怜玢システム」に぀いお登壇いたしたした。 Techplayむベントペヌゞ 今回は、AI搭茉怜玢システムに関連する「ナレッゞグラフを搭茉した怜玢システム」に぀いお玹介したす。 AI搭茉怜玢システム 怜玢ずいえば、皆さんはきっず Google 怜玢をむメヌゞしおいたす。最近の Google 怜玢は、昔ずは違っおAI技術を掻甚するこずで、ただのキヌワヌド怜玢を超えた特城を持っおいたす。 Google 怜玢に慣れおいるほずんどのナヌザヌは怜玢システムを䜿甚するずきに、以䞋のようなこずを期埅したす。 ドメむン 理解Domain-aware ナヌザヌのク゚リ内のキヌワヌドに該圓する抂念を認識しお自動的にその抂念のカテゎリや属性などをク゚リに付加する。䟋えば「ISID」ずいうク゚リを打ったずきに、「䌚瀟」のカテゎリ、「 電通 囜際情報」の別名、ず「品川」の本瀟所圚地などの情報をク゚リに付加する。 文脈ずナヌザヌの理解Contextual and Personalized ナヌザヌの奜み・プロフィヌルを考慮しおク゚リず怜玢結果の関連床を調敎する。䟋えば゚ンゞニアが「 Python 」ずいうク゚リを打ったずきに、蛇の Python ではなく、 プログラミング蚀語 の Python を蚘茉する蚘事を返す。 察話型Conversational  自然蚀語 を理解し、前に怜玢したものを考慮する。䟋えば「コロナ」ず怜玢した埌、次に「mrna」ず怜玢するず、モデルなのワクチン情報が出おくる。 マルチモヌダルMulti-modal テキストに限らず、音声、画像、映像などに察応する。 知胜的Intelligent デヌタが溜たっおいけばいくほど自己改善する。䟋えば誀字自動蚂正や自動補完機胜がだんだん賢くなる。 支揎型Assistive 怜玢以䞊に自動的に適切なアクションを実行する。䟋えば映画名を怜玢するず、怜玢結果カヌドの䞋の郚分で「予玄ボタン」が衚瀺される。 これらの特城は共通のゎヌルを持っおいたす。ナヌザヌの意図ナヌザヌが探したいものを理解するこずです。ナヌザヌが探したいものは、ナヌザヌ自身しか分からないので、怜玢システムの開発偎はナヌザヌ意図を3぀の次元に分割し、それぞれの次元を 定量 化したす。 コンテンツ理解 怜玢察象文曞ずナヌザヌが入力したキヌワヌドのク゚リそのものを理解する。 ナヌザヌ理解 怜玢システムのナヌザヌの奜みやプロフィヌルを理解する。 ドメむン 理解 怜玢システムをデプロむする業務/ ドメむン 知識を理解する。 次のベン図に曞いおいたように各次元の代衚技術ず2぀の次元を組み合わせた技術が蚘茉されおいたす。 コンテンツ理解 → キヌワヌド怜玢 党文怜玢  ナヌザヌ理解 → 協調フィルタリング 掚薊システム ドメむン 理解 → ナレッゞグラフ コンテンツ理解 + ナヌザヌ理解 → パヌ゜ナラむズド怜玢 ナヌザヌ理解 + ドメむン 理解 → マルチモヌダル掚薊 コンテンツ理解 + ドメむン 理解 → セマンティック怜玢 今回は、ナレッゞグラフを搭茉したセマンティック怜玢システムを玹介したす。 ナレッゞグラフを搭茉したセマンティック怜玢 怜玢゚ンゞン ナレッゞグラフを導入する前に、たず、 怜玢゚ンゞン の構成を解説したす。 怜玢゚ンゞン では、文曞デヌタを 転眮むンデックス ずいうデヌタ構造で管理しおいたす。転眮ずは、本の玢匕のように、単語の䞀芧を䞊べお、その単語を含む文章にひも付いおいたす。 転眮むンデックス ずしおデヌタを管理するこずで怜玢スピヌドが速くなりたす。 転眮むンデックス ができたら、ナヌザヌがク゚リを入力する時に、以䞋の凊理を行いたす。 ク゚リの解析 ク゚リをキヌワヌド・単語に分割したす。 フィルタヌリング  転眮むンデックス からそれらのキヌワヌドを含む文曞を取埗したす。 関連床の蚈算  取埗した文曞ずク゚リの関連床を蚈算したす。蚈算方法は様々ですが、よく䜿われるのはBM25です。 怜玢結果提䟛 最埌に、関連床順で文曞を䞊べおナヌザヌに返したす。 怜玢゚ンゞン を仕様するこずで、文曞入れるだけでOut-of-the-boxで 党文怜玢 ができたす。最初は、このようなキヌワヌド怜玢だけで十分に情報怜玢ができたすが、デヌタがだんだん溜たっおいけばいくほど、キヌワヌド怜玢だけで埗られない堎合が倚いです。䟋えば、Eコマヌスのシステムを䟋にしお、ナヌザヌが iPad をク゚リずしお怜玢するずきに、出おくるのは「 iPad のケヌス」や「 iPad の充電噚」など iPad 本䜓ではありたせん。 この堎合は、明らかに生のキヌワヌド怜玢だけで、ナヌザヌが探したい情報を埗るこずはできたせん。1぀の解決方法ずしおは、ナヌザヌのクリック情報を収集しお 協調フィルタリング ずいった方法を䜿甚しお、怜玢結果を調敎するのはできたす。ただし、このアプロヌチの欠点ずしおは、ナヌザヌの行動が制埡できず、デヌタの偏りが生じるず、倉な怜玢結果が出おいたす。そのために、今回は、 ナレッゞグラフ を導入しお、怜玢察象デヌタずク゚リに意味を持たせるべきです。 ナレッゞグラフ ナレッゞグラフずは、簡単に蚀うず人間の知識をグラフ圢匏で衚珟するものです。䞖の䞭での定矩は様々ですが、怜玢の文脈では、人の知識を衚珟するために5぀のレベルで衚珟できたす。 蚀い換え Alternative Labels同じ意味を衚珟する単語。䟋えばチョコレヌト => チョコ 囜際連合 => 囜連。 同矩語・類矩語Synonyms近い意味を衚珟する単語。䟋えば人間 => 人、人類食べ物 => 食材、食料、フヌド、食品。 分類䜓系Taxonomyものを階局的なカテゎリに分類する。䟋えば加藀ヌIS_A→人間、人間ヌIS_A→哺乳類、哺乳類ヌIS_A→動物。 オントロゞヌ Ontologyものの皮類タむプ・クラスの関連性を衚珟する。䟋えば動物ヌ食べる→食べ物、人間 ナレッゞグラフKnowledge Graph オントロゞヌ を むンスタンス 化したものを同じグラフで衚珟する。䟋えば加藀ヌIS_A→人間、加藀ヌ食べる→食べ物 基本的に、ナレッゞグラフは構造デヌタであるので、デヌタを簡単に探玢できたす。䟋えば、 Google 怜玢で「日本」ずいうク゚リを打った時に、怜玢結果の右偎に日本のナレッゞパネルが出おきたす。そのナレッゞパネルから日本の銖郜である「東京」をクリックするず、東京のナレッゞパネルをすぐに衚瀺できたす。 セマンティック怜玢 ナレッゞグラフず 怜玢゚ンゞン の双方の利点を掻甚するずセマンティック怜玢が実珟できたす。セマンティック怜玢では、ナヌザヌが打ったク゚リから゚ンティティEntityず関係Relationを抜出したす。そしお、「゚ンティティ」ず「関係」の情報を䜿っお、以䞋の凊理を行うこずができたす。 [1] 埗られた情報がたどり着くたでナレッゞグラフに察しおグラフ走査Graph Traversalを行いたす。 䟋えば「ISID近くの䞭華」、解析結果のむメヌゞは以䞋のずおりです。 察象クラス 䞭華レストラン 絞り蟌み条件 距離 条件近い5km以内 原点京王品川ビルISID本瀟 この解析結果をもずに、GraphQL、 Cypher QLNeo4j、SPARQLなどに倉換すれば、グラフ走査を行うこずができ、最埌に察象ドキュメントたでたどり着きたす。 Cypher Scriptのク゚リむメヌゞは以䞋のずおりです。 MATCH (a: Article)-[:HAS_MENTION]->(r:ChineseRestaurant) MATCH (c: Company {english_name: ISID})-[:HAS_HEADQUARTER]->(o:Office) WHERE point.distance(r.geolocation, o.geolocation) <= 5000 RETURN a アプロヌチ[1]では、高床なセマンティック解析凊理ず高床なセマンティック情報を持぀ナレッゞグラフが必芁で、難易床が高いです。もちろんこのようなシステムを実珟できれば理想的であるが、人手で䜜るのは倧倉ですし、自動で䜜るのはかなり難しいです。 [2] 関連する゚ンティティをナレッゞグラフから抜出しおク゚リを拡匵しおから 怜玢゚ンゞン にク゚リを入力したす。 このアプロヌチでは、ク゚リを解析しお盎接ナレッゞグラフから答えを抜出するのではなく、ナレッゞグラフから情報を抜出しお、ク゚リを拡匵したす。 同じ䟋の「ISID近くの䞭華」ですず、ISIDずいう蚀葉は「 電通囜際情報サヌビス 」や「品川」で、䞭華ずいう蚀葉は「レストラン」や「䞭華料理」などナレッゞグラフから抜出したす。そのあず、オリゞナルク゚リにそれらの蚀葉を远加しお、 怜玢゚ンゞン のク゚リを䜜っお投げたす。 Elasticsearchのク゚リむメヌゞは以䞋のずおりです。 { " query ": { " query_string ": { " fields ": [ " title ", " body ", " category " ] , " query ": " (ISID^10 OR 電通囜際情報サヌビス OR 品川) AND (䞭華^10 OR レストラン OR 䞭華料理) " } } } アプロヌチ1に比べお、このアプロヌチの方がより珟実的です。高床なセマンティック情報を持぀ナレッゞグラフの必芁性が䜎く、has_related_termsずいう関係性を衚珟したナレッゞグラフで十分です。もちろん、アプロヌチ1の方は怜玢粟床が高いですが、最初の段階で、このアプロヌチはやりやすいず考えられたす。 たずめ 今回は、怜玢システムにナレッゞグラフの導入むメヌゞを玹介したした。むメヌゞが぀くように簡単なNeo4jの Cypher スクリプト ずElasticsearchク゚リの䟋をあげおみたした。ナレッゞグラフを掻甚する前に、ナレッゞグラフ構築が必芁で、このステップは䞀番倧倉だず思いたす。ISIDでは、日本語の文曞からナレッゞグラフを構築する技術の研究を行っおいたす。 私たちは同じチヌムで働いおくれる仲間を探しおいたす。今回の゚ントリで玹介したような仕事に興味のある方、ご応募をお埅ちしおいたす。 AI゚ンゞニアプロダクト開発 AIプロダクトマネヌゞャヌ AIコンサルタント AIビゞネスプロゞェクトマネヌゞャヌ 執筆 @faisalhadiputra 、レビュヌ @yamada.y  Shodo で執筆されたした 
みなさんこんにちは 電通囜際情報サヌビス ISIDクロス むノベヌション 本郚 AIトランスフォヌメヌションセンタヌAITC むンドネシア 出身のファむサル ハディプトラず申したす。この蚘事は 電通囜際情報サヌビス Advent Calendar 2022 の12月7日の蚘事です。 先日、TECHPLAYで「AI搭茉怜玢システム」に぀いお登壇いたしたした。 Techplayむベントペヌゞ 今回は、AI搭茉怜玢システムに関連する「ナレッゞグラフを搭茉した怜玢システム」に぀いお玹介したす。 AI搭茉怜玢システム 怜玢ずいえば、皆さんはきっず Google 怜玢をむメヌゞしおいたす。最近の Google 怜玢は、昔ずは違っおAI技術を掻甚するこずで、ただのキヌワヌド怜玢を超えた特城を持っおいたす。 Google 怜玢に慣れおいるほずんどのナヌザヌは怜玢システムを䜿甚するずきに、以䞋のようなこずを期埅したす。 ドメむン 理解Domain-aware ナヌザヌのク゚リ内のキヌワヌドに該圓する抂念を認識しお自動的にその抂念のカテゎリや属性などをク゚リに付加する。䟋えば「ISID」ずいうク゚リを打ったずきに、「䌚瀟」のカテゎリ、「 電通 囜際情報」の別名、ず「品川」の本瀟所圚地などの情報をク゚リに付加する。 文脈ずナヌザヌの理解Contextual and Personalized ナヌザヌの奜み・プロフィヌルを考慮しおク゚リず怜玢結果の関連床を調敎する。䟋えば゚ンゞニアが「 Python 」ずいうク゚リを打ったずきに、蛇の Python ではなく、 プログラミング蚀語 の Python を蚘茉する蚘事を返す。 察話型Conversational  自然蚀語 を理解し、前に怜玢したものを考慮する。䟋えば「コロナ」ず怜玢した埌、次に「mrna」ず怜玢するず、モデルなのワクチン情報が出おくる。 マルチモヌダルMulti-modal テキストに限らず、音声、画像、映像などに察応する。 知胜的Intelligent デヌタが溜たっおいけばいくほど自己改善する。䟋えば誀字自動蚂正や自動補完機胜がだんだん賢くなる。 支揎型Assistive 怜玢以䞊に自動的に適切なアクションを実行する。䟋えば映画名を怜玢するず、怜玢結果カヌドの䞋の郚分で「予玄ボタン」が衚瀺される。 これらの特城は共通のゎヌルを持っおいたす。ナヌザヌの意図ナヌザヌが探したいものを理解するこずです。ナヌザヌが探したいものは、ナヌザヌ自身しか分からないので、怜玢システムの開発偎はナヌザヌ意図を3぀の次元に分割し、それぞれの次元を 定量 化したす。 コンテンツ理解 怜玢察象文曞ずナヌザヌが入力したキヌワヌドのク゚リそのものを理解する。 ナヌザヌ理解 怜玢システムのナヌザヌの奜みやプロフィヌルを理解する。 ドメむン 理解 怜玢システムをデプロむする業務/ ドメむン 知識を理解する。 次のベン図に曞いおいたように各次元の代衚技術ず2぀の次元を組み合わせた技術が蚘茉されおいたす。 コンテンツ理解 → キヌワヌド怜玢 党文怜玢  ナヌザヌ理解 → 協調フィルタリング 掚薊システム ドメむン 理解 → ナレッゞグラフ コンテンツ理解 + ナヌザヌ理解 → パヌ゜ナラむズド怜玢 ナヌザヌ理解 + ドメむン 理解 → マルチモヌダル掚薊 コンテンツ理解 + ドメむン 理解 → セマンティック怜玢 今回は、ナレッゞグラフを搭茉したセマンティック怜玢システムを玹介したす。 ナレッゞグラフを搭茉したセマンティック怜玢 怜玢゚ンゞン ナレッゞグラフを導入する前に、たず、 怜玢゚ンゞン の構成を解説したす。 怜玢゚ンゞン では、文曞デヌタを 転眮むンデックス ずいうデヌタ構造で管理しおいたす。転眮ずは、本の玢匕のように、単語の䞀芧を䞊べお、その単語を含む文章にひも付いおいたす。 転眮むンデックス ずしおデヌタを管理するこずで怜玢スピヌドが速くなりたす。 転眮むンデックス ができたら、ナヌザヌがク゚リを入力する時に、以䞋の凊理を行いたす。 ク゚リの解析 ク゚リをキヌワヌド・単語に分割したす。 フィルタヌリング  転眮むンデックス からそれらのキヌワヌドを含む文曞を取埗したす。 関連床の蚈算  取埗した文曞ずク゚リの関連床を蚈算したす。蚈算方法は様々ですが、よく䜿われるのはBM25です。 怜玢結果提䟛 最埌に、関連床順で文曞を䞊べおナヌザヌに返したす。 怜玢゚ンゞン を仕様するこずで、文曞入れるだけでOut-of-the-boxで 党文怜玢 ができたす。最初は、このようなキヌワヌド怜玢だけで十分に情報怜玢ができたすが、デヌタがだんだん溜たっおいけばいくほど、キヌワヌド怜玢だけで埗られない堎合が倚いです。䟋えば、Eコマヌスのシステムを䟋にしお、ナヌザヌが iPad をク゚リずしお怜玢するずきに、出おくるのは「 iPad のケヌス」や「 iPad の充電噚」など iPad 本䜓ではありたせん。 この堎合は、明らかに生のキヌワヌド怜玢だけで、ナヌザヌが探したい情報を埗るこずはできたせん。1぀の解決方法ずしおは、ナヌザヌのクリック情報を収集しお 協調フィルタリング ずいった方法を䜿甚しお、怜玢結果を調敎するのはできたす。ただし、このアプロヌチの欠点ずしおは、ナヌザヌの行動が制埡できず、デヌタの偏りが生じるず、倉な怜玢結果が出おいたす。そのために、今回は、 ナレッゞグラフ を導入しお、怜玢察象デヌタずク゚リに意味を持たせるべきです。 ナレッゞグラフ ナレッゞグラフずは、簡単に蚀うず人間の知識をグラフ圢匏で衚珟するものです。䞖の䞭での定矩は様々ですが、怜玢の文脈では、人の知識を衚珟するために5぀のレベルで衚珟できたす。 蚀い換え Alternative Labels同じ意味を衚珟する単語。䟋えばチョコレヌト => チョコ 囜際連合 => 囜連。 同矩語・類矩語Synonyms近い意味を衚珟する単語。䟋えば人間 => 人、人類食べ物 => 食材、食料、フヌド、食品。 分類䜓系Taxonomyものを階局的なカテゎリに分類する。䟋えば加藀ヌIS_A→人間、人間ヌIS_A→哺乳類、哺乳類ヌIS_A→動物。 オントロゞヌ Ontologyものの皮類タむプ・クラスの関連性を衚珟する。䟋えば動物ヌ食べる→食べ物、人間 ナレッゞグラフKnowledge Graph オントロゞヌ を むンスタンス 化したものを同じグラフで衚珟する。䟋えば加藀ヌIS_A→人間、加藀ヌ食べる→食べ物 基本的に、ナレッゞグラフは構造デヌタであるので、デヌタを簡単に探玢できたす。䟋えば、 Google 怜玢で「日本」ずいうク゚リを打った時に、怜玢結果の右偎に日本のナレッゞパネルが出おきたす。そのナレッゞパネルから日本の銖郜である「東京」をクリックするず、東京のナレッゞパネルをすぐに衚瀺できたす。 セマンティック怜玢 ナレッゞグラフず 怜玢゚ンゞン の双方の利点を掻甚するずセマンティック怜玢が実珟できたす。セマンティック怜玢では、ナヌザヌが打ったク゚リから゚ンティティEntityず関係Relationを抜出したす。そしお、「゚ンティティ」ず「関係」の情報を䜿っお、以䞋の凊理を行うこずができたす。 [1] 埗られた情報がたどり着くたでナレッゞグラフに察しおグラフ走査Graph Traversalを行いたす。 䟋えば「ISID近くの䞭華」、解析結果のむメヌゞは以䞋のずおりです。 察象クラス 䞭華レストラン 絞り蟌み条件 距離 条件近い5km以内 原点京王品川ビルISID本瀟 この解析結果をもずに、GraphQL、 Cypher QLNeo4j、SPARQLなどに倉換すれば、グラフ走査を行うこずができ、最埌に察象ドキュメントたでたどり着きたす。 Cypher Scriptのク゚リむメヌゞは以䞋のずおりです。 MATCH (a: Article)-[:HAS_MENTION]->(r:ChineseRestaurant) MATCH (c: Company {english_name: ISID})-[:HAS_HEADQUARTER]->(o:Office) WHERE point.distance(r.geolocation, o.geolocation) <= 5000 RETURN a アプロヌチ[1]では、高床なセマンティック解析凊理ず高床なセマンティック情報を持぀ナレッゞグラフが必芁で、難易床が高いです。もちろんこのようなシステムを実珟できれば理想的であるが、人手で䜜るのは倧倉ですし、自動で䜜るのはかなり難しいです。 [2] 関連する゚ンティティをナレッゞグラフから抜出しおク゚リを拡匵しおから 怜玢゚ンゞン にク゚リを入力したす。 このアプロヌチでは、ク゚リを解析しお盎接ナレッゞグラフから答えを抜出するのではなく、ナレッゞグラフから情報を抜出しお、ク゚リを拡匵したす。 同じ䟋の「ISID近くの䞭華」ですず、ISIDずいう蚀葉は「 電通囜際情報サヌビス 」や「品川」で、䞭華ずいう蚀葉は「レストラン」や「䞭華料理」などナレッゞグラフから抜出したす。そのあず、オリゞナルク゚リにそれらの蚀葉を远加しお、 怜玢゚ンゞン のク゚リを䜜っお投げたす。 Elasticsearchのク゚リむメヌゞは以䞋のずおりです。 { " query ": { " query_string ": { " fields ": [ " title ", " body ", " category " ] , " query ": " (ISID^10 OR 電通囜際情報サヌビス OR 品川) AND (䞭華^10 OR レストラン OR 䞭華料理) " } } } アプロヌチ1に比べお、このアプロヌチの方がより珟実的です。高床なセマンティック情報を持぀ナレッゞグラフの必芁性が䜎く、has_related_termsずいう関係性を衚珟したナレッゞグラフで十分です。もちろん、アプロヌチ1の方は怜玢粟床が高いですが、最初の段階で、このアプロヌチはやりやすいず考えられたす。 たずめ 今回は、怜玢システムにナレッゞグラフの導入むメヌゞを玹介したした。むメヌゞが぀くように簡単なNeo4jの Cypher スクリプト ずElasticsearchク゚リの䟋をあげおみたした。ナレッゞグラフを掻甚する前に、ナレッゞグラフ構築が必芁で、このステップは䞀番倧倉だず思いたす。ISIDでは、日本語の文曞からナレッゞグラフを構築する技術の研究を行っおいたす。 私たちは同じチヌムで働いおくれる仲間を探しおいたす。今回の゚ントリで玹介したような仕事に興味のある方、ご応募をお埅ちしおいたす。 AI゚ンゞニアプロダクト開発 AIプロダクトマネヌゞャヌ AIコンサルタント AIビゞネスプロゞェクトマネヌゞャヌ 執筆 @faisalhadiputra 、レビュヌ @yamada.y  Shodo で執筆されたした 
Xクロス むノベヌション 本郚 ゜フトりェアデザむンセンタヌ セキュリティグルヌプの柎田です。 これは 電通囜際情報サヌビス Advent Calendar 2022 6日目の蚘事です。5日目の昚日は、もう䞀人の柎田さんの蚘事「 Argo CDを䜿っおIstioをバヌゞョンアップする 」でした。 はじめに Webアプリケヌションの構成 動䜜むメヌゞ コヌドサンプル はじめに 瀟内で Excel ファむルを扱う業務があり、特定の Excel ファむルをテンプレヌトずしお郜床ファむルをコピヌする圢で運甚しおいたす。 Excel ファむルはメンテナンス時の差分管理が Excel 単䜓の機胜では難しく、耇数人での修正も可胜ですが、個人的には倉曎履歎があたり芖認性の良いものではないず考えおいたす。 そこで、 Excel ファむルに蚘茉する内容を別途テキストベヌスで差分管理し、修正したテキストを Excel ファむルに流し蟌むシステムを構築するこずになりたした。 たた、䜵せおNext.jsを利甚しWebアプリケヌション化も実珟しお、 Excel ファむルに远加するテキストもWebアプリケヌション䞊から入力できるような仕組みにしおいたす。 今回䜜成しおいるWebアプリケヌションは、Next.jsずTypeScriptを利甚しおいたす。 その䞭で、 Amazon S3 に保存した Excel ファむル拡匵子xlsxを取埗しお、 Excel ファむルを加工凊理しおからクラむアント Webブラりザ に返华する、ずいう凊理を玹介したす。 Webアプリケヌションの構成 前述の通り、 Amazon S3 を利甚しおいるため、Webシステムは AWS 䞊に構築しおいたす。 実際はもう少し耇雑なシステム構成ですが、以䞋は、今回玹介する Excel 凊理郚分のフロヌを抜粋した図です。 Webブラりザ からリク ゚ス トを受けたWebアプリケヌションNext.jsが、バック゚ンド偎で Amazon S3 から Excel ファむルを取埗したす。取埗した Excel ファむルの加工凊理をした埌、 Webブラりザ 偎に返华する流れです。 Amazon S3 からのデヌタ取埗のラむブラリは AWS SDK for JavaScript v3 、 Excel ファむルの加工のラむブラリは ExcelJS を利甚しおいたす。 動䜜むメヌゞ ダりンロヌドボタンを抌すず、 /api/download にリク ゚ス トが送信され、加工したファむルがダりンロヌドされたす。 コヌドサンプル Next.jsのプロゞェクト䜜成は、以䞋の陳さんの蚘事を参考にしたした。 tech.isid.co.jp たずはフロント偎です。 // pages/index.tsx import styles from '../styles/Home.module.css' const Home = () => { const download = async ( fileName: string ) => { const response = await fetch ( `/api/download` , { method: 'GET' } ) try { if ( response. status !== 200 ) { throw new Error () } else { const blob = await response.blob () const blobFile = new Blob ( [ blob ] , { type : 'application/xlsx' } ) const a = document .createElement ( 'a' ) a.style.display = 'none' document .body.appendChild ( a ) const url = window .URL.createObjectURL ( blobFile ) a.href = url a.download = fileName a.click () window .URL.revokeObjectURL ( url ) } } catch ( e: unknown ) { console .error ( e ) } } return ( < div className = { styles.container } > < main className = { styles.main } > < button onClick = { () => download ( 'ダりンロヌドファむル名.xlsx' ) } > ダりンロヌド < /button > < /main > < /div > ) } export default Home サンプルコヌドでは、ボタンをクリックするずバック゚ンドの API にリク ゚ス トし、レスポンスを組み立おお、ファむル保存のダむアログを衚瀺させる圢にしおいたす。 次に API です。 // pages/api/download.ts import { Readable } from 'stream' import * as ExcelJS from 'exceljs' import type { NextApiRequest , NextApiResponse } from 'next' import { getObject } from '../../src/aws/s3' export default async function download ( req: NextApiRequest , res: NextApiResponse ) : Promise < void > { try { const s3Output = await getObject ( 'bucket' , 'key' ) if ( s3Output.Body instanceof Readable ) { const s3OutputStream = s3Output.Body as Readable res.setHeader ( 'Content-Type' , 'application/xlsx' ) res. status( 200 ) const workbook = new ExcelJS.Workbook () await workbook.xlsx.read ( s3OutputStream ) const sheet = workbook.getWorksheet ( 'Sheet1' ) sheet.getRow ( 1 ) .getCell ( 1 ) .value = 'テスト' await workbook.xlsx.write ( res ) } return } catch ( e: unknown ) { return res. status( 500 ) .json ( { message: 'Internal Server Error' } ) } } // src/aws/s3.ts import { GetObjectCommand , GetObjectCommandOutput , S3Client } from '@aws-sdk/client-s3' export async function getObject ( bucket: string , key: string ) : Promise < GetObjectCommandOutput > { const params = { Bucket: bucket , Key: key , } const command = new GetObjectCommand ( params ) return await new S3Client ( { region: 'ap-northeast-1' } ) .send ( command ) } Amazon S3 にリク ゚ス トを送信し、レスポンスを受け取りたす。 受け取ったStreamを順次凊理するため、そのたたExcelJSに枡しおいたす。 ExcelJSでは、Streamをそのたた凊理しおくれたす。 参考 github.com ExcelJSの ゜ヌスコヌド を芋るず、実際はメモリ䞊に䞀旊すべお展開されたす。 Streamのたた順次凊理しおいく機胜も甚意されおいたすが、今回はファむルサむズが小さく、凊理が耇雑になりそうだったため利甚したせんでした。 参考 github.com 最埌にテストコヌドです。 API Routes のテストラむブラリは next-test-api-route-handler を利甚しおいたす。 // test/api/download.test.ts import fs from 'fs' import path from 'path' import { PassThrough } from 'stream' import { GetObjectCommandOutput } from '@aws-sdk/client-s3' import { sdkStreamMixin } from '@aws-sdk/util-stream-node' import * as ExcelJS from 'exceljs' import { testApiHandler } from 'next-test-api-route-handler' import download from '../../pages/api/download' import * as s3Module from '../../src/aws/s3' const handler: typeof download = download const filePath = path.join ( __dirname , 'download.xlsx' ) const getObjectSpyOn = jest.spyOn ( s3Module , 'getObject' ) const getObject200 = async () : Promise < GetObjectCommandOutput > => { return { Body: sdkStreamMixin ( fs.createReadStream ( filePath )), $metadata: { httpStatusCode: 200 , } , } } const getObject500 = async () : Promise < GetObjectCommandOutput > => { const mockReadable = sdkStreamMixin (new PassThrough ()) mockReadable.emit ( 'error' , new Error ( 'error' )) return { Body: mockReadable , $metadata: { httpStatusCode: 500 , } , } } describe ( 'client-s3' , () => { test ( '200' , async () => { getObjectSpyOn.mockImplementation ( getObject200 ) await testApiHandler ( { handler , test: async ( { fetch } ) => { const res = await fetch ( { method: 'GET' } ) expect ( res. status) .toBe ( 200 ) const workbook = new ExcelJS.Workbook () await workbook.xlsx.read ( res.body ) const worksheet = workbook.getWorksheet ( 'Sheet1' ) expect ( worksheet.getRow ( 1 ) .getCell ( 1 ) .value ) .toBe ( 'テスト' ) } , } ) } ) test ( '500' , async () => { getObjectSpyOn.mockImplementation ( getObject500 ) await testApiHandler ( { handler , test: async ( { fetch } ) => { const res = await fetch ( { method: 'GET' } ) expect ( res. status) .toBe ( 500 ) } , } ) } ) } ) Amazon S3 から取埗する箇所をモック化しおいたす。Stream郚分には PassThrough を利甚しおいたす。 たた、 AWS SDK for JavaScript v3のv3.188.0以降では、Stream凊理が䞀郚倉曎になり、Bodyの型が SdkStream<Readable> で返るようになりたした。 そのため、 @aws-sdk/util-stream-node にある sdkStreamMixin を利甚しお、テストコヌドのモックでも同じ型を返すようにしおいたす。 参考 github.com github.com 以䞊、Next.jsずTypeScriptを利甚しお、 Amazon S3 に保存されおいる Excel をExcelJSで加工しおクラむアントに返す方法の玹介でした。 電通囜際情報サヌビス Advent Calendar 2022 7日目の明日は、Faisalさんの蚘事です。お楜しみに 私たちは同じチヌムで働いおくれる仲間を倧募集しおいたすたくさんのご応募をお埅ちしおいたす。 - セキュリティ゚ンゞニア(セキュリティ蚭蚈) 執筆 @shibata.shunsuke 、レビュヌ Ishizawa Kento (@kent)  Shodo で執筆されたした 
電通囜際情報サヌビス 、オヌプン むノベヌション ラボの 比嘉康雄 です。 Stable Diffusionシリヌズ、今回は、Stable Diffusion 2.0-矎少女むラストです。 Stable Diffusionも2.0になったので、もう䞀床怜蚌し盎したす。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪矎女写真 v2.1 矎少女アニメ画 v2.1 AUTOMATIC1111 v2.0 矎少女むラスト v1.5 矎少女画怜蚌 矎少女アニメ画改善版 矎少女を高確率で出す呪文線 矎少女アニメ画線 矎少女写真線 女性むラスト線 長い呪文は切り捚おられる線 AUTOMATIC 1111のむンストヌル AUTOMATIC 1111のセッティング 呪文の基本ルヌル 矎少女むラストの呪文 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render v1.5 たずめ 仲間募集 Stable Diffusionの党コンテンツ AUTOMATIC 1111のむンストヌル Stable Diffusion 2.0 を実行する環境ずしお、 AUTOMATIC 1111 を䜿いたす。 AUTOMATIC 1111 は、 Stable Diffusion を Google Colab 盎接ではなく、 UI 経由で実行できるようにしおいたす。䌌たような機胜のものはいく぀かありたすが、 AUTOMATIC 1111 が最も人気があるので、今回からこれを䜿いたす。 Google Colab で動かすためのノヌトブックは こちら になりたす。 このノヌトブックを実行するず、䞋の方に Running on public URL: https://2c76db068be0e79a.gradio.app のようなURLのリンクが衚瀺されるので、クリックしたしょう。 Colab Pro の通垞メモリでは、メモリが足りなくなるこずがありたした。そのような堎合は、 Google Drive にコピヌしおハむメモリにしたしょう。 AUTOMATIC 1111のセッティング パラメヌタは以䞋のようになりたす。 Sampling Steps: 50 Sampling Method: DPM2 Width: 768 Height: 768 CFG Scale: 7.5 Seed: -1 Sampling Stepsは、デフォルトの 20 だず少ないので、 50 くらいにしおおきたしょう。 Sampling Methodは DPM2 をお勧めしたすが、 DDIM も悪くはありたせん。それ以倖は、描く察象によりたすが、あたりお勧めしたせん。 Width ず Height は 768 をお勧めしたす。 Stable Diffusion 2.0 のモデルの 768-v-ema.ckpt は、 768 甚のためです。 512 だずかを䜿うず画像が厩れるこずがありたす。 CFG Scale は入力した呪文にどれだけ近い画像を生成するかのパラメヌタです。デフォルトの 7 でも問題ありたせんが、僕はなんずなく 7.5 を指定しおいたす。 呪文の基本ルヌル 以前よりも僕自身、呪文promptの基本ルヌルがわかっおきたので、お䌝えしたす。経隓則的な偎面が匷いですが、たぶん、あっおいるず思いたす。 トヌク ンは75たで。 カンマ,は必芁がない。カンマも トヌク ンの䞀぀ずしおカりントされるので、ないほうが良い。 前の方にある トヌク ンの方が出力結果に䞎える圱響が倧きい。 冠詞a, an, theなどは必芁がない。 近くにある トヌク ンは圱響を受ける。埌ろにある トヌク ンも前の トヌク ンに圱響を䞎える。 トヌク ンず トヌク ンの間の トヌク ン数が倚くなるず、 トヌク ンの圱響は少なくなる。 呪文は トヌク ンに分解されたす。 トヌク ンは基本的には、単語だず思っお倧䞈倫ですが、 Stable Diffusion が知らない トヌク ンは、䞀぀の単語が耇数の トヌク ンに分解されるこずもありたす。䟋えば、 pixiv は、 pi ず xiv の2぀の トヌク ンになりたす。 「埌ろにある トヌク ンも前の トヌク ンに圱響を䞎える」ずいうのは、これたで、なんずなく感じおいたけど、 蚀語化 できおいなかった郚分ではないでしょうか。 䟋えば、 apple on table だず赀いリンゎがほずんどです。しかし、 apple on yellow table だず黄色のりんごになる確率が増えたす。 トヌク ンず トヌク ンの間の トヌク ン数が倚くなるず、 トヌク ンの圱響は少なくなりたす。 䟋えば、 apple on yellow table だず黄色になるリンゎもありたすが、 apple on a a a a a a a a a a a a a a a a a a yellow table だず、黄色になるリンゎの確率はかなり枛りたす。 矎少女むラストの呪文 それでは、呪文の基本ルヌルをふたえた、 Stable Diffusion 2.0 で怜蚌枈みの矎少女むラストの呪文を玹介したす。 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render 閲芧甚改行版 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render 出力結果の䟋です。 これは、厳遞したものではなく、連発できたす。それでは、呪文の䞭身を解説したしょう。 beautiful princess これたで、矎少女を描画するずきは、 beautiful girl を指定しおいたのですが、これを beautiful princess に倉えたした。これがかなり効果的で、矎少女になる確率がかなり高くなりたした。 beautiful face 矎少女率を䞊げるためには、 beautiful face はあったほうが良いです。 beautiful hair beautiful clothes この呪文は、それほど倧した意味はないのですが、前の face ず次の artstation ずの距離をあけるために指定しおいたす。 artstation はアヌトの投皿サむトなので、 face ず artstation が近くにあるず、 face に過剰に色が぀くなど artstation の圱響をうけるこずがありたす。 hair ず clothes は、 artstation の圱響を受けおもそれほど問題はないので、緩衝材にぎったりです。 artstation artstation は、 art むラストの投皿サむトです。 artstation を指定するこずで、出力結果がむラストになりたす。 たた、 artstation を指定するこずで、出力される画像のクオリティが䞊がりたす。 fantasy scene fantasy composition fantasy lighting シヌンscene、構図composition、ラむティングlightingは指定しおおきたしょう。指定しないず人物だけの単玔な画像になるこずがありたす。 修食語は奜みで構いたせん。 fantasy は矎少女ず盞性の良い修食語です。 princess 、 face 、 hair 、 clothes などに悪圱響を䞎えるこずもありたせん。 octane render octane render を指定するず画像が倚少立䜓的になりたす。二次元が奜きな方は倖しおください。 v1.5 v1.5で䞋蚘のパラメヌタで実行しおみたした。 Width ず Height を 512 に倉えただけです。 Sampling Steps: 50 Sampling Method: DPM2 Width: 512 Height: 512 CFG Scale: 7.5 Seed: -1 v1.5でも、良い結果が連発できたした。呪文が改善されたこずず、 Sampling Method を DDIM から DPM2 にしたこずが良い結果に぀ながったのかもしれたせん。 比べおみるずv2.0のほうが、質感が増しおいるのがわかりたす。 v1.5の出力結果はこちら。 たずめ 今回は、 Stable Diffusion 2.0 の矎少女むラストの呪文を玹介したした。 v1.4 ず v1.5 の違いはあたりなかったのですが、 v2.0 では画像の質感が増し、明らかに良くなったず思いたす。みなさんもぜひ詊しおください。 仲間募集 私たちは同じグルヌプで共に働いおいただける仲間を募集しおいたす。 珟圚、以䞋のような職皮を募集しおいたす。 ゜リュヌションアヌキテクト 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 、レビュヌ Ishizawa Kento (@kent)  Shodo で執筆されたした 
電通囜際情報サヌビス 、オヌプン むノベヌション ラボの 比嘉康雄 です。 Stable Diffusionシリヌズ、今回は、Stable Diffusion 2.0-矎少女むラストです。 Stable Diffusionも2.0になったので、もう䞀床怜蚌し盎したす。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪矎女写真 v2.1 矎少女アニメ画 v2.1 AUTOMATIC1111 v2.0 矎少女むラスト v1.5 矎少女画怜蚌 矎少女アニメ画改善版 矎少女を高確率で出す呪文線 矎少女アニメ画線 矎少女写真線 女性むラスト線 長い呪文は切り捚おられる線 AUTOMATIC 1111のむンストヌル AUTOMATIC 1111のセッティング 呪文の基本ルヌル 矎少女むラストの呪文 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render v1.5 たずめ 仲間募集 Stable Diffusionの党コンテンツ AUTOMATIC 1111のむンストヌル Stable Diffusion 2.0 を実行する環境ずしお、 AUTOMATIC 1111 を䜿いたす。 AUTOMATIC 1111 は、 Stable Diffusion を Google Colab 盎接ではなく、 UI 経由で実行できるようにしおいたす。䌌たような機胜のものはいく぀かありたすが、 AUTOMATIC 1111 が最も人気があるので、今回からこれを䜿いたす。 Google Colab で動かすためのノヌトブックは こちら になりたす。 このノヌトブックを実行するず、䞋の方に Running on public URL: https://2c76db068be0e79a.gradio.app のようなURLのリンクが衚瀺されるので、クリックしたしょう。 Colab Pro の通垞メモリでは、メモリが足りなくなるこずがありたした。そのような堎合は、 Google Drive にコピヌしおハむメモリにしたしょう。 AUTOMATIC 1111のセッティング パラメヌタは以䞋のようになりたす。 Sampling Steps: 50 Sampling Method: DPM2 Width: 768 Height: 768 CFG Scale: 7.5 Seed: -1 Sampling Stepsは、デフォルトの 20 だず少ないので、 50 くらいにしおおきたしょう。 Sampling Methodは DPM2 をお勧めしたすが、 DDIM も悪くはありたせん。それ以倖は、描く察象によりたすが、あたりお勧めしたせん。 Width ず Height は 768 をお勧めしたす。 Stable Diffusion 2.0 のモデルの 768-v-ema.ckpt は、 768 甚のためです。 512 だずかを䜿うず画像が厩れるこずがありたす。 CFG Scale は入力した呪文にどれだけ近い画像を生成するかのパラメヌタです。デフォルトの 7 でも問題ありたせんが、僕はなんずなく 7.5 を指定しおいたす。 呪文の基本ルヌル 以前よりも僕自身、呪文promptの基本ルヌルがわかっおきたので、お䌝えしたす。経隓則的な偎面が匷いですが、たぶん、あっおいるず思いたす。 トヌク ンは75たで。 カンマ,は必芁がない。カンマも トヌク ンの䞀぀ずしおカりントされるので、ないほうが良い。 前の方にある トヌク ンの方が出力結果に䞎える圱響が倧きい。 冠詞a, an, theなどは必芁がない。 近くにある トヌク ンは圱響を受ける。埌ろにある トヌク ンも前の トヌク ンに圱響を䞎える。 トヌク ンず トヌク ンの間の トヌク ン数が倚くなるず、 トヌク ンの圱響は少なくなる。 呪文は トヌク ンに分解されたす。 トヌク ンは基本的には、単語だず思っお倧䞈倫ですが、 Stable Diffusion が知らない トヌク ンは、䞀぀の単語が耇数の トヌク ンに分解されるこずもありたす。䟋えば、 pixiv は、 pi ず xiv の2぀の トヌク ンになりたす。 「埌ろにある トヌク ンも前の トヌク ンに圱響を䞎える」ずいうのは、これたで、なんずなく感じおいたけど、 蚀語化 できおいなかった郚分ではないでしょうか。 䟋えば、 apple on table だず赀いリンゎがほずんどです。しかし、 apple on yellow table だず黄色のりんごになる確率が増えたす。 トヌク ンず トヌク ンの間の トヌク ン数が倚くなるず、 トヌク ンの圱響は少なくなりたす。 䟋えば、 apple on yellow table だず黄色になるリンゎもありたすが、 apple on a a a a a a a a a a a a a a a a a a yellow table だず、黄色になるリンゎの確率はかなり枛りたす。 矎少女むラストの呪文 それでは、呪文の基本ルヌルをふたえた、 Stable Diffusion 2.0 で怜蚌枈みの矎少女むラストの呪文を玹介したす。 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render 閲芧甚改行版 beautiful princess beautiful face beautiful hair beautiful clothes artstation fantasy scene fantasy composition fantasy lighting octane render 出力結果の䟋です。 これは、厳遞したものではなく、連発できたす。それでは、呪文の䞭身を解説したしょう。 beautiful princess これたで、矎少女を描画するずきは、 beautiful girl を指定しおいたのですが、これを beautiful princess に倉えたした。これがかなり効果的で、矎少女になる確率がかなり高くなりたした。 beautiful face 矎少女率を䞊げるためには、 beautiful face はあったほうが良いです。 beautiful hair beautiful clothes この呪文は、それほど倧した意味はないのですが、前の face ず次の artstation ずの距離をあけるために指定しおいたす。 artstation はアヌトの投皿サむトなので、 face ず artstation が近くにあるず、 face に過剰に色が぀くなど artstation の圱響をうけるこずがありたす。 hair ず clothes は、 artstation の圱響を受けおもそれほど問題はないので、緩衝材にぎったりです。 artstation artstation は、 art むラストの投皿サむトです。 artstation を指定するこずで、出力結果がむラストになりたす。 たた、 artstation を指定するこずで、出力される画像のクオリティが䞊がりたす。 fantasy scene fantasy composition fantasy lighting シヌンscene、構図composition、ラむティングlightingは指定しおおきたしょう。指定しないず人物だけの単玔な画像になるこずがありたす。 修食語は奜みで構いたせん。 fantasy は矎少女ず盞性の良い修食語です。 princess 、 face 、 hair 、 clothes などに悪圱響を䞎えるこずもありたせん。 octane render octane render を指定するず画像が倚少立䜓的になりたす。二次元が奜きな方は倖しおください。 v1.5 v1.5で䞋蚘のパラメヌタで実行しおみたした。 Width ず Height を 512 に倉えただけです。 Sampling Steps: 50 Sampling Method: DPM2 Width: 512 Height: 512 CFG Scale: 7.5 Seed: -1 v1.5でも、良い結果が連発できたした。呪文が改善されたこずず、 Sampling Method を DDIM から DPM2 にしたこずが良い結果に぀ながったのかもしれたせん。 比べおみるずv2.0のほうが、質感が増しおいるのがわかりたす。 v1.5の出力結果はこちら。 たずめ 今回は、 Stable Diffusion 2.0 の矎少女むラストの呪文を玹介したした。 v1.4 ず v1.5 の違いはあたりなかったのですが、 v2.0 では画像の質感が増し、明らかに良くなったず思いたす。みなさんもぜひ詊しおください。 仲間募集 私たちは同じグルヌプで共に働いおいただける仲間を募集しおいたす。 珟圚、以䞋のような職皮を募集しおいたす。 ゜リュヌションアヌキテクト 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 、レビュヌ Ishizawa Kento (@kent)  Shodo で執筆されたした 
Xクロス むノベヌション 本郚 ゜フトりェアデザむンセンタヌ セキュリティグルヌプの柎田です。 これは 電通囜際情報サヌビス Advent Calendar 2022 6日目の蚘事です。5日目の昚日は、もう䞀人の柎田さんの蚘事「 Argo CDを䜿っおIstioをバヌゞョンアップする 」でした。 はじめに Webアプリケヌションの構成 動䜜むメヌゞ コヌドサンプル はじめに 瀟内で Excel ファむルを扱う業務があり、特定の Excel ファむルをテンプレヌトずしお郜床ファむルをコピヌする圢で運甚しおいたす。 Excel ファむルはメンテナンス時の差分管理が Excel 単䜓の機胜では難しく、耇数人での修正も可胜ですが、個人的には倉曎履歎があたり芖認性の良いものではないず考えおいたす。 そこで、 Excel ファむルに蚘茉する内容を別途テキストベヌスで差分管理し、修正したテキストを Excel ファむルに流し蟌むシステムを構築するこずになりたした。 たた、䜵せおNext.jsを利甚しWebアプリケヌション化も実珟しお、 Excel ファむルに远加するテキストもWebアプリケヌション䞊から入力できるような仕組みにしおいたす。 今回䜜成しおいるWebアプリケヌションは、Next.jsずTypeScriptを利甚しおいたす。 その䞭で、 Amazon S3 に保存した Excel ファむル拡匵子xlsxを取埗しお、 Excel ファむルを加工凊理しおからクラむアント Webブラりザ に返华する、ずいう凊理を玹介したす。 Webアプリケヌションの構成 前述の通り、 Amazon S3 を利甚しおいるため、Webシステムは AWS 䞊に構築しおいたす。 実際はもう少し耇雑なシステム構成ですが、以䞋は、今回玹介する Excel 凊理郚分のフロヌを抜粋した図です。 Webブラりザ からリク ゚ス トを受けたWebアプリケヌションNext.jsが、バック゚ンド偎で Amazon S3 から Excel ファむルを取埗したす。取埗した Excel ファむルの加工凊理をした埌、 Webブラりザ 偎に返华する流れです。 Amazon S3 からのデヌタ取埗のラむブラリは AWS SDK for JavaScript v3 、 Excel ファむルの加工のラむブラリは ExcelJS を利甚しおいたす。 動䜜むメヌゞ ダりンロヌドボタンを抌すず、 /api/download にリク ゚ス トが送信され、加工したファむルがダりンロヌドされたす。 コヌドサンプル Next.jsのプロゞェクト䜜成は、以䞋の陳さんの蚘事を参考にしたした。 tech.isid.co.jp たずはフロント偎です。 // pages/index.tsx import styles from '../styles/Home.module.css' const Home = () => { const download = async ( fileName: string ) => { const response = await fetch ( `/api/download` , { method: 'GET' } ) try { if ( response. status !== 200 ) { throw new Error () } else { const blob = await response.blob () const blobFile = new Blob ( [ blob ] , { type : 'application/xlsx' } ) const a = document .createElement ( 'a' ) a.style.display = 'none' document .body.appendChild ( a ) const url = window .URL.createObjectURL ( blobFile ) a.href = url a.download = fileName a.click () window .URL.revokeObjectURL ( url ) } } catch ( e: unknown ) { console .error ( e ) } } return ( < div className = { styles.container } > < main className = { styles.main } > < button onClick = { () => download ( 'ダりンロヌドファむル名.xlsx' ) } > ダりンロヌド < /button > < /main > < /div > ) } export default Home サンプルコヌドでは、ボタンをクリックするずバック゚ンドの API にリク ゚ス トし、レスポンスを組み立おお、ファむル保存のダむアログを衚瀺させる圢にしおいたす。 次に API です。 // pages/api/download.ts import { Readable } from 'stream' import * as ExcelJS from 'exceljs' import type { NextApiRequest , NextApiResponse } from 'next' import { getObject } from '../../src/aws/s3' export default async function download ( req: NextApiRequest , res: NextApiResponse ) : Promise < void > { try { const s3Output = await getObject ( 'bucket' , 'key' ) if ( s3Output.Body instanceof Readable ) { const s3OutputStream = s3Output.Body as Readable res.setHeader ( 'Content-Type' , 'application/xlsx' ) res. status( 200 ) const workbook = new ExcelJS.Workbook () await workbook.xlsx.read ( s3OutputStream ) const sheet = workbook.getWorksheet ( 'Sheet1' ) sheet.getRow ( 1 ) .getCell ( 1 ) .value = 'テスト' await workbook.xlsx.write ( res ) } return } catch ( e: unknown ) { return res. status( 500 ) .json ( { message: 'Internal Server Error' } ) } } // src/aws/s3.ts import { GetObjectCommand , GetObjectCommandOutput , S3Client } from '@aws-sdk/client-s3' export async function getObject ( bucket: string , key: string ) : Promise < GetObjectCommandOutput > { const params = { Bucket: bucket , Key: key , } const command = new GetObjectCommand ( params ) return await new S3Client ( { region: 'ap-northeast-1' } ) .send ( command ) } Amazon S3 にリク ゚ス トを送信し、レスポンスを受け取りたす。 受け取ったStreamを順次凊理するため、そのたたExcelJSに枡しおいたす。 ExcelJSでは、Streamをそのたた凊理しおくれたす。 参考 github.com ExcelJSの ゜ヌスコヌド を芋るず、実際はメモリ䞊に䞀旊すべお展開されたす。 Streamのたた順次凊理しおいく機胜も甚意されおいたすが、今回はファむルサむズが小さく、凊理が耇雑になりそうだったため利甚したせんでした。 参考 github.com 最埌にテストコヌドです。 API Routes のテストラむブラリは next-test-api-route-handler を利甚しおいたす。 // test/api/download.test.ts import fs from 'fs' import path from 'path' import { PassThrough } from 'stream' import { GetObjectCommandOutput } from '@aws-sdk/client-s3' import { sdkStreamMixin } from '@aws-sdk/util-stream-node' import * as ExcelJS from 'exceljs' import { testApiHandler } from 'next-test-api-route-handler' import download from '../../pages/api/download' import * as s3Module from '../../src/aws/s3' const handler: typeof download = download const filePath = path.join ( __dirname , 'download.xlsx' ) const getObjectSpyOn = jest.spyOn ( s3Module , 'getObject' ) const getObject200 = async () : Promise < GetObjectCommandOutput > => { return { Body: sdkStreamMixin ( fs.createReadStream ( filePath )), $metadata: { httpStatusCode: 200 , } , } } const getObject500 = async () : Promise < GetObjectCommandOutput > => { const mockReadable = sdkStreamMixin (new PassThrough ()) mockReadable.emit ( 'error' , new Error ( 'error' )) return { Body: mockReadable , $metadata: { httpStatusCode: 500 , } , } } describe ( 'client-s3' , () => { test ( '200' , async () => { getObjectSpyOn.mockImplementation ( getObject200 ) await testApiHandler ( { handler , test: async ( { fetch } ) => { const res = await fetch ( { method: 'GET' } ) expect ( res. status) .toBe ( 200 ) const workbook = new ExcelJS.Workbook () await workbook.xlsx.read ( res.body ) const worksheet = workbook.getWorksheet ( 'Sheet1' ) expect ( worksheet.getRow ( 1 ) .getCell ( 1 ) .value ) .toBe ( 'テスト' ) } , } ) } ) test ( '500' , async () => { getObjectSpyOn.mockImplementation ( getObject500 ) await testApiHandler ( { handler , test: async ( { fetch } ) => { const res = await fetch ( { method: 'GET' } ) expect ( res. status) .toBe ( 500 ) } , } ) } ) } ) Amazon S3 から取埗する箇所をモック化しおいたす。Stream郚分には PassThrough を利甚しおいたす。 たた、 AWS SDK for JavaScript v3のv3.188.0以降では、Stream凊理が䞀郚倉曎になり、Bodyの型が SdkStream<Readable> で返るようになりたした。 そのため、 @aws-sdk/util-stream-node にある sdkStreamMixin を利甚しお、テストコヌドのモックでも同じ型を返すようにしおいたす。 参考 github.com github.com 以䞊、Next.jsずTypeScriptを利甚しお、 Amazon S3 に保存されおいる Excel をExcelJSで加工しおクラむアントに返す方法の玹介でした。 電通囜際情報サヌビス Advent Calendar 2022 7日目の明日は、Faisalさんの蚘事です。お楜しみに 私たちは同じチヌムで働いおくれる仲間を倧募集しおいたすたくさんのご応募をお埅ちしおいたす。 - セキュリティ゚ンゞニア(セキュリティ蚭蚈) 執筆 @shibata.shunsuke 、レビュヌ Ishizawa Kento (@kent)  Shodo で執筆されたした 
初めに ISID Xクロス むノベヌション 本郚 の䞉浊です。 仕事でかかわっおるわけではありたせんが、個人的な興味ずしおStable Diffusion呚りの動向を远っおおりたす。 あの界隈の進歩は今凄たじいですね。 で、 google colab䞊で詊すずいうやり方もあるのですが、 google colabのリ゜ヌス枠を䜿い果たす事態が最近頻発しおおりたすので今回はdokcerベヌスでロヌカル環境を䜜りたした。 たた、CPUのみのマシンでもお詊しできるこずを確認したしたので執筆しおいる次第です。 抂芁 Stable Diffusion、および、Stable Diffusion掟生モデルを䜿甚しおいくうえで非垞に䟿利な『 Stable Diffusion web UI(AUTOMATIC1111版) 』の環境を GPU が䜿えないマシン向けにdokcer で構築したす。 なお、Stable Diffusion web UI(AUTOMATIC1111)は、 google colab䞊で動䜜させるこずも可胜です。 前提条件、怜蚌環境 dokcer compose 䜿甚 gitクラむアント 䜿甚 windows10 メモリ 16G以䞊 (メモリ8Gは厳しいです) 手順抂芁 stable-diffusion-webui-docker  を clone docker compose --profile download up --build docker compose --profile auto-cpu up --build これだけでAI絵䜜成甚のツヌル、Stable Diffusion web UIAUTOMATIC1111版を立ち䞊げるこずが可胜です。 なお、本日は省略したすが、簡易に他のStable Diffusion掟生モデルを远加し利甚するこずも可胜です。 実行䟋 stable-diffusion-webui-docker をclone埌、 docker compose --profile download up --build 䞊蚘コマンドを実行したす。盞圓量のリ゜ヌスをダりンロヌドするため私の環境では1h匱かかりたした。 䞊蚘のように必芁なリ゜ヌスがダりンロヌドできたので次はCPUモヌドで起動したす。 なお、䞊蚘 ディレクト リに手を加えれば他のStable Diffusion掟生モデルの利甚も可胜です。 たた、起動オプションの倉曎により GPU モヌドで起動するこずも簡単です。 さらにdocker-composeファむルを線集するこずにより䜎スペックな GPU でも皌働させるこずもできたす※1。 docker compose --profile auto-cpu up --build 起動が完了するず↑のようにURLが衚瀺されたすので http://localhost:7860/ にアクセスしたす。 なお、䞀床目の起動には非垞に時間がかかりたすが、二回目以降は数分レベルで起動したす。 利甚䟋 䞊蚘蚭定で、䞋蚘ぐらいの速床で生成できたす。 intel i7 4770s 物理4コアの堎合、400s Ryzen 7 3700X 物理8コアの堎合、200s 解像床、step数、 サンプラヌ 、モデルで生成速床はだいたい決たりたす。察話匏でいろいろ詊すにはやや぀らいですが、プロンプト掲茉サむトのプロンプトを詊すならある皋床割り切れる速床かず思っおる感じです(※2)。 たた、こんな感じで簡単に耇数枚䜜るこずもできるので寝おいる間にCPUを酷䜿しお倧量生成するのも簡単です。 GPU でちゃんずモデルがのる環境だず、↓が1分皋床で生成可胜です。 CPUのみ物理4コアのマシンにお玄40分で生成したした。100枚たでたずめお生成可胜なので倜数時間かけお生成するずいう䜿い方も可胜です。 たずめ いた、画像生成の分野は非垞に盛り䞊がっおいるず思いたす。ご興味を持った方は觊っおみるずいいのではないでしょうか 泚蚘 ※1 メモリ4Gクラスの GPU でも動䜜させるこずができたす。GTX1650で皌働するこずを確認したした。が、かなり遅くなるので、メモリ8G以䞊の GPU がお薊めです。 ※2 google colabだず、10s-20s皋床です。 執筆 @miura.toshihiko 、レビュヌ @higa  Shodo で執筆されたした 
初めに ISID Xクロス むノベヌション 本郚 の䞉浊です。 仕事でかかわっおるわけではありたせんが、個人的な興味ずしおStable Diffusion呚りの動向を远っおおりたす。 あの界隈の進歩は今凄たじいですね。 で、 google colab䞊で詊すずいうやり方もあるのですが、 google colabのリ゜ヌス枠を䜿い果たす事態が最近頻発しおおりたすので今回はdokcerベヌスでロヌカル環境を䜜りたした。 たた、CPUのみのマシンでもお詊しできるこずを確認したしたので執筆しおいる次第です。 抂芁 Stable Diffusion、および、Stable Diffusion掟生モデルを䜿甚しおいくうえで非垞に䟿利な『 Stable Diffusion web UI(AUTOMATIC1111版) 』の環境を GPU が䜿えないマシン向けにdokcer で構築したす。 なお、Stable Diffusion web UI(AUTOMATIC1111)は、 google colab䞊で動䜜させるこずも可胜です。 前提条件、怜蚌環境 dokcer compose 䜿甚 gitクラむアント 䜿甚 windows10 メモリ 16G以䞊 (メモリ8Gは厳しいです) 手順抂芁 stable-diffusion-webui-docker  を clone docker compose --profile download up --build docker compose --profile auto-cpu up --build これだけでAI絵䜜成甚のツヌル、Stable Diffusion web UIAUTOMATIC1111版を立ち䞊げるこずが可胜です。 なお、本日は省略したすが、簡易に他のStable Diffusion掟生モデルを远加し利甚するこずも可胜です。 実行䟋 stable-diffusion-webui-docker をclone埌、 docker compose --profile download up --build 䞊蚘コマンドを実行したす。盞圓量のリ゜ヌスをダりンロヌドするため私の環境では1h匱かかりたした。 䞊蚘のように必芁なリ゜ヌスがダりンロヌドできたので次はCPUモヌドで起動したす。 なお、䞊蚘 ディレクト リに手を加えれば他のStable Diffusion掟生モデルの利甚も可胜です。 たた、起動オプションの倉曎により GPU モヌドで起動するこずも簡単です。 さらにdocker-composeファむルを線集するこずにより䜎スペックな GPU でも皌働させるこずもできたす※1。 docker compose --profile auto-cpu up --build 起動が完了するず↑のようにURLが衚瀺されたすので http://localhost:7860/ にアクセスしたす。 なお、䞀床目の起動には非垞に時間がかかりたすが、二回目以降は数分レベルで起動したす。 利甚䟋 䞊蚘蚭定で、䞋蚘ぐらいの速床で生成できたす。 intel i7 4770s 物理4コアの堎合、400s Ryzen 7 3700X 物理8コアの堎合、200s 解像床、step数、 サンプラヌ 、モデルで生成速床はだいたい決たりたす。察話匏でいろいろ詊すにはやや぀らいですが、プロンプト掲茉サむトのプロンプトを詊すならある皋床割り切れる速床かず思っおる感じです(※2)。 たた、こんな感じで簡単に耇数枚䜜るこずもできるので寝おいる間にCPUを酷䜿しお倧量生成するのも簡単です。 GPU でちゃんずモデルがのる環境だず、↓が1分皋床で生成可胜です。 CPUのみ物理4コアのマシンにお玄40分で生成したした。100枚たでたずめお生成可胜なので倜数時間かけお生成するずいう䜿い方も可胜です。 たずめ いた、画像生成の分野は非垞に盛り䞊がっおいるず思いたす。ご興味を持った方は觊っおみるずいいのではないでしょうか 泚蚘 ※1 メモリ4Gクラスの GPU でも動䜜させるこずができたす。GTX1650で皌働するこずを確認したした。が、かなり遅くなるので、メモリ8G以䞊の GPU がお薊めです。 ※2 google colabだず、10s-20s皋床です。 執筆 @miura.toshihiko 、レビュヌ @higa  Shodo で執筆されたした 
こんにちは。Xクロス むノベヌション 本郚 クラりド むノベヌション センタヌの柎田です。 この蚘事は 電通囜際情報サヌビス Advent Calendar 2022 の5日目の投皿です。 前日の蚘事は宮柀さんの「お金をかけずに AWS Certified SysOps Administrator - Associateに合栌した話」でした。 さお、この蚘事ではArgo CDを䜿っおIstioをバヌゞョンアップする方法を玹介したす。 はじめに Istioずは Argo CDずは Istioをどうやっおバヌゞョンアップするか Argo CDを䜿っおIstioをバヌゞョンアップする 想定する環境 環境を構築する Amazon EKS Argo CD Istio サンプルアプリケヌション 手順1. Canary upgradeが可胜か確認する 手順2. istio/base CRDを含むを曎新する 手順3. 新しいバヌゞョンの istio/istiod を远加する 手順4. デヌタプレヌンを曎新する 手順5. istio/base の defaultRevision を曎新する 手順6. istio/gateway を曎新する 手順7. 叀いバヌゞョンの istio/istiod を削陀する おわりに はじめに Istioずは Istio はサヌビスメッシュを実珟する OSS の1぀です。 サヌビスメッシュずは、マむクロサヌビスにおける トラフィック 管理、可芳枬性、セキュリティなどを、むンフラスト ラク チャレむダヌで透過的に実珟する仕組みです。 サヌビスメッシュがどんな課題を解決するものかは、以䞋のスラむドが参考になりたす。 サヌビスメッシュは本圓に必芁なのか、䜕を解決するのか / Service meshes - Do we really need them? What problems do they solve? - Speaker Deck Istioはデヌタプレヌンずコン トロヌル プレヌンの2぀の コンポヌネント から構成されたす。 デヌタプレヌン  実際にサヌビス間通信を行う郚分です。 アプリケヌションのプロキシずしお Envoy を起動したす  サむドカヌ コンテナずしお起動するケヌスが倚いです。 Envoyは トラフィック 管理、可芳枬性、セキュリティなどの機胜を提䟛したす。 コン トロヌル プレヌン  Envoyの蚭定を管理・曎新したす。 1 Istioのサポヌトポリシヌは Supported Releases に定矩されおいたす。 抂芁は以䞋のずおりです。 4半期に1回、マむナヌリリヌスを行う。 各マむナヌリリヌスのサポヌトセキュリティパッチの提䟛などはN+2マむナヌリリヌスの6週間埌たで提䟛される。 䟋 v1.11 のサポヌトは v1.13.0 をリリヌスした6週間埌たで提䟛される。 Argo CDずは Argo CD は Kubernetes 甚の継続的デリバリヌツヌルの1぀です。 Argo CDは、git リポゞトリ で管理された Kubernetes の マニフェスト の倉曎を、 Kubernetes クラスタ ぞデプロむしたす。 2 Argo CDは GitOps ずいう手法に基づいおいたす。 GitOpsはWeaveworks瀟が提唱した継続的デリバリヌ・継続的デプロむメントの方法であり、以䞋の特城がありたす。 システム党䜓が宣蚀的に蚘述されおいるこず。 マニフェスト がgitで管理され、それが信頌できる唯䞀の情報源Single Source of Truthであるこず。 承認された マニフェスト の倉曎が自動的にデプロむされるこず。たたその際 Kubernetes クラスタ ぞの認蚌情報を倖郚䟋えばCIサヌバなどに持たせる必芁がないこず。 マニフェスト ず Kubernetes クラスタ の間に差分がある堎合、それを怜知したり、自動的に修正したりできるこず。 Istioをどうやっおバヌゞョンアップするか 先述した通りIstioの各マむナヌリリヌスはリリヌスから玄6〜8ヶ月埌にサポヌトが終了したす。 そのため定期的にIstioをバヌゞョンアップする必芁がありたす。 公匏ドキュメント には以䞋の3぀のバヌゞョンアップ方法が玹介されおいたす。 istioctl を䜿っおIn-place upgradeする方法 istioctl を䜿っおCanary upgradeする方法 Helmを䜿っおCanary upgradeする方法α版 なお、In-place upgradeの堎合、バヌゞョンアップ前埌のバヌゞョン差異は1マむナヌリリヌス以内である必芁がありたす。 3 たた、Canary upgradeの堎合、バヌゞョンアップ前埌のバヌゞョン差異は2マむナヌリリヌス以内であるこずが掚奚されおいたす。 4 実案件の倚くは、 Kubernetes マニフェスト のデプロむを、Argo CDなどの継続的デリバリヌツヌルを䜿っお行いたす。 しかし、䞊述のドキュメントでは、 Kubernetes クラスタ 管理者が手元からコマンドを実行しおバヌゞョンアップする方法しか玹介されおいたせん。 そこで本蚘事では、Argo CDを䜿っおIstioをバヌゞョンアップする方法を玹介したす。 今回は以䞋の理由から方法3をベヌスずしたす。 公匏ドキュメントではIn-place upgradeよりもCanary upgradeを掚奚しおいるため。 5 Argo CDをはじめ 6 、倚くの継続的デリバリヌツヌルがHelmをサポヌトしおいるため。 Argo CDを䜿っおIstioをバヌゞョンアップする 想定する環境 本蚘事では以䞋の環境を前提ずしたす。 Amazon EKS v1.23 Argo CD v2.4.14 Istio v1.13.4 → v1.15.3 たたサンプルアプリケヌションずしおIstio公匏のサンプルアプリケヌションである Bookinfoアプリケヌション がデプロむされおいるものずしたす。 環境を構築する Amazon EKS Amazon EKS クラスタ を構築したす。 本蚘事では詳现な手順は割愛したす。 詳しくは Amazon EKS クラスタヌの䜜成 - Amazon EKS をご参照ください。 Argo CD Kubernetes クラスタ ぞArgo CDをデプロむしたす。 本蚘事では詳现な手順は割愛したす。 詳しくは以䞋の公匏ドキュメントをご参照ください。 Getting Started - Argo CD - Declarative GitOps CD for Kubernetes Installation - Argo CD - Declarative GitOps CD for Kubernetes Istio IstioのHelm chartは以䞋の3぀を䜿甚したす。 istio/base istio/istiod istio/gateway 本蚘事では以䞋の手順で Kubernetes クラスタ にIstio v1.13.4がむンストヌルされおいるものずしたす。 必芁なnamespaceを䜜成したす。 $ kubectl create namespace istio-system $ kubectl create namespace istio-ingress istio-ingress namespaceに automatic sidecar injection を有効にするためのlabelを蚭定したす。 $ kubectl label namespace istio-ingress istio-injection=enabled 以䞋のArgo CDのApplication CRを kubectl apply コマンドでデプロむしたす。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-base namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : base targetRevision : 1.13.4 helm : releaseName : istio-base destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : ValidatingWebhookConfiguration name : istiod-default-validator jsonPointers : - /webhooks/0/failurePolicy --- apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istiod namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : istiod targetRevision : 1.13.4 helm : releaseName : istiod destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : MutatingWebhookConfiguration name : istio-sidecar-injector jsonPointers : - /webhooks/0/clientConfig/caBundle - /webhooks/1/clientConfig/caBundle - /webhooks/2/clientConfig/caBundle - /webhooks/3/clientConfig/caBundle --- apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-ingress namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : gateway targetRevision : 1.13.4 helm : releaseName : istio-ingress destination : server : https://kubernetes.default.svc namespace : istio-ingress 䞊述のApplication CRに぀いおArgo CDのWeb UIからsyncを実行しおIstioをデプロむしたす。 syncは istio-base → istiod → istio-ingress の順に実行したす。 本蚘事ではArgo CDのWeb UIのアクセス方法および操䜜方法に関する説明は割愛したす。詳现は Argo CDの公匏ドキュメント をご参照ください。 サンプルアプリケヌション 本蚘事ではサンプルアプリケヌションずしお default namespaceにIstio公匏のサンプルアプリケヌションである Bookinfoアプリケヌション がデプロむされおいるものずしたす。 default namespaceに automatic sidecar injection を有効にするためのlabelを蚭定したす。 $ kubectl label namespace default istio-injection=enabled Bookinfoアプリケヌション をデプロむしたす。 $ kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.13.4/samples/bookinfo/platform/kube/bookinfo.yaml $ kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.13.4/samples/bookinfo/networking/bookinfo-gateway.yaml $ kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.13.4/samples/bookinfo/networking/destination-rule-all.yaml Gateway bookinfo-gateway の .spec.selector を istio=ingressgateway から istio=ingress ぞ倉曎したす。 $ kubectl patch gateways.networking.istio.io bookinfo-gateway --type=merge -p '{"spec":{"selector":{"istio":"ingress"}}}' 手順1. Canary upgradeが可胜か確認する 以䞋の条件を満たしおいるか確認したす。 Istioのバヌゞョンアップ前埌のバヌゞョン差異が2マむナヌリリヌス以内であるこず。 䟋えば、珟圚のバヌゞョンが 1.13.x の堎合、 1.14.x ず 1.15.x ぞバヌゞョンアップできたす。 istio/base 、 istio/gateway 、CRDに砎壊的倉曎がないこず。 これらのリ゜ヌスはバヌゞョンアップ前埌で共有されるためです。 istio/istiod がバヌゞョンアップ前埌で独立しおおり同じリ゜ヌスを共有しないこず。 叀いバヌゞョンの istio/istiod を安党に削陀するためです。 なお istio/istiod のパラメヌタ revision にはバヌゞョンアップ前埌で異なる倀を蚭定したす。 kubectl rollout restart コマンドでアプリケヌションのPodを安党に再䜜成できるこず。 PodがGraceful Shutdownするよう実装・蚭定されおいるか。 PodのUpdate strategyが適切に蚭定されおいるか。 以䞋の手順でバヌゞョンアップ前埌の互換性が確認できおいるこず。 曎新埌のバヌゞョンの istioctl を GitHubのリリヌス からダりンロヌドする。 istioctl x precheck コマンドを実行しお互換性を確認する。 $ istioctl x precheck ✔ No issues found when checking the cluster. Istio is safe to install or upgrade! To get started, check out <https://istio.io/latest/docs/setup/getting-started/> 手順2. istio/base CRDを含むを曎新する Application CR istio-base の targetRevision を曎新したす。これによりCRDなどが曎新されたす。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-base namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : base targetRevision : 1.15.3 helm : releaseName : istio-base destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : ValidatingWebhookConfiguration name : istiod-default-validator jsonPointers : - /webhooks/0/failurePolicy 本来、 helm upgrade コマンドや helm uninstall コマンドでhelm chartを曎新/削陀しおも、CRDは曎新/削陀されたせん。 7 ただし、Argo CDは helm template で生成した マニフェスト を kubectl apply しおいるため、Helm chartを曎新するこずで、CRDを曎新できたす。 手順3. 新しいバヌゞョンの istio/istiod を远加する 新しいバヌゞョンの istio/istiod のApplication CRをデプロむしたす。 このずき、以䞋のフィヌルドは曎新埌のバヌゞョンにあわせお倉曎したす。 .metadata.name .spec.source.targetRevision .spec.source.helm.values の revision (*1) .spec.ignoreDifferences 8 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istiod-1-15-3 namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : istiod targetRevision : 1.15.3 helm : releaseName : istiod values : | revision : "1-15-3" destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : MutatingWebhookConfiguration name : istio-sidecar-injector-1-15-3 jsonPointers : - /webhooks/0/clientConfig/caBundle - /webhooks/1/clientConfig/caBundle istio-system namespaceに新しいバヌゞョンの istiod が䜜成されたこずを確認したす。 $ kubectl -n istio-system get pods,svc,mutatingwebhookconfigurations NAME READY STATUS RESTARTS AGE pod/istiod-1-15-3-59d4cf9474-gklrs 1/1 Running 0 11s pod/istiod-579df55f96-n4tk8 1/1 Running 0 21m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/istiod ClusterIP 172.20.91.227 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 21m service/istiod-1-15-3 ClusterIP 172.20.213.98 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 11s NAME WEBHOOKS AGE mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector 4 21m mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector-1-15-3 2 11s mutatingwebhookconfiguration.admissionregistration.k8s.io/pod-identity-webhook 1 38m mutatingwebhookconfiguration.admissionregistration.k8s.io/vpc-resource-mutating-webhook 1 37m 手順4. デヌタプレヌンを曎新する アプリケヌションのPodの サむドカヌ コンテナずしお起動しおいるEnvoy以降では istio-proxy ず呌びたすを曎新したす。 今回は automatic sidecar injection を有効にしおいるため、 istio-proxy はPod䜜成時に サむドカヌ コンテナずしお自動的に远加されたす。 この堎合、 automatic sidecar injection が有効なnamespaceに぀いお、namespaceのlabelを曎新した埌、Podを再䜜成するこずで、 istio-proxy を曎新できたす。 今回察象ずなるnamespaceは以䞋の2぀です。 default namespace istio-ingress namespace たず default namespaceに察しお以䞋の手順を実斜したす。 珟圚の istio-proxy の状態を確認したす。 $ istioctl -n default proxy-status NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION details-v1-6bd666858f-wq2fr.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 productpage-v1-7f6655c647-s8gdf.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 ratings-v1-7cc7df5fd5-slqgd.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 reviews-v1-68c7d56667-nvv5q.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 reviews-v2-759496d8df-gkgdh.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 reviews-v3-7545ff7c75-68n7b.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 namespaceのlabelを曎新したす。 istio.io/rev=<(*1)ず同じ文字列> labelを蚭定したす。 istio-injection labelが存圚する堎合は削陀したす。 $ kubectl label namespace default istio.io/rev=1-15-3 $ kubectl label namespace default istio-injection- 先皋のnamespaceのPodを再䜜成したす。 $ kubectl -n default rollout restart deployment 倉曎埌の istio-proxy の状態を確認したす。 特に ISTIOD 列ず VERSION 列が新しくなっおいるこずを確認したす。 $ istioctl proxy-status NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION details-v1-5954bb9d8-xn5j6.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 productpage-v1-7f6bff5ddd-ms4b4.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 ratings-v1-6f8d5bf8d4-f2jmm.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 reviews-v1-785b65d7c4-6j4wq.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 reviews-v2-86b446779b-9wx5q.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 reviews-v3-5b5b976fbb-cc2j9.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 次に istio-ingress namespaceに察しおも同様の手順を実斜したす。 default namespaceず同じ内容のため詳现は割愛したす。 Canary upgradeではこのようにnamespace単䜍で埐々にデヌタプレヌンを曎新できたす。 たた、もし問題が発生した堎合はnamespaceのlabelをもずに戻しおPodを再䜜成するこずでデヌタプレヌンの曎新を ロヌルバック できたす。 手順5. istio/base の defaultRevision を曎新する Application CR istio-base の .spec.source.helm.values の defaultRevision を(*1)ず同じ文字列ぞ曎新したす。 これによりValidatingWebhookConfiguration istiod-default-validator の宛先が叀いバヌゞョンの istiod から新しいバヌゞョンの istiod ぞ倉曎されたす。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-base namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : base targetRevision : 1.15.3 helm : releaseName : istio-base values : | defaultRevision : "1-15-3" destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : ValidatingWebhookConfiguration name : istiod-default-validator jsonPointers : - /webhooks/0/failurePolicy 手順6. istio/gateway を曎新する Application CR istio-ingress の targetRevision を曎新したす。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-ingress namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : gateway targetRevision : 1.15.3 helm : releaseName : istio-ingress destination : server : https://kubernetes.default.svc namespace : istio-ingress 手順7. 叀いバヌゞョンの istio/istiod を削陀する 叀いバヌゞョンの istio/istiod のApplication CRにfinalizerを蚭定したす。 Application CRの削陀ず同時に関連するリ゜ヌスを削陀するためです。 9 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istiod namespace : argocd finalizers : - resources-finalizer.argocd.argoproj.io spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : istiod targetRevision : 1.13.4 helm : releaseName : istiod destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : MutatingWebhookConfiguration name : istio-sidecar-injector jsonPointers : - /webhooks/0/clientConfig/caBundle - /webhooks/1/clientConfig/caBundle - /webhooks/2/clientConfig/caBundle - /webhooks/3/clientConfig/caBundle 叀いバヌゞョンの istio/istiod のApplication CRを削陀したす。 istio-system namespaceから叀いバヌゞョンの istio/istiod が削陀されたこずを確認したす。 $ kubectl -n istio-system get pods,svc,mutatingwebhookconfigurations NAME READY STATUS RESTARTS AGE pod/istiod-1-15-3-59d4cf9474-gklrs 1/1 Running 0 6m1s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/istiod-1-15-3 ClusterIP 172.20.213.98 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 6m1s NAME WEBHOOKS AGE mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector-1-15-3 2 6m1s mutatingwebhookconfiguration.admissionregistration.k8s.io/pod-identity-webhook 1 43m mutatingwebhookconfiguration.admissionregistration.k8s.io/vpc-resource-mutating-webhook 1 43m おわりに この蚘事ではArgo CDを䜿っおIstioをバヌゞョンアップする方法を玹介したした。 バヌゞョンアップはシステムをセキュアな状態に維持するために欠かせない䜜業です。 䞀方でIstioのバヌゞョンアップは、サヌビスメッシュ䞊の党アプリケヌションに圱響のある䜜業でもありたす。 安党か぀効率的なバヌゞョンアップ方法を確立しおいきたいですね。 最埌たでお読みいただき、ありがずうございたした。 私たちは同じチヌムで働いおくれる仲間を探しおいたす。 クラりド アヌキテクトの業務に興味がある方のご応募をお埅ちしおいたす。 クラりドアヌキテクト 執筆 @shibata.takao 、レビュヌ 寺山 茝 (@terayama.akira)  Shodo で執筆されたした  図は https://istio.io/latest/about/service-mesh/ より匕甚したした。 ↩ 図は https://argo-cd.readthedocs.io/en/stable/ より匕甚したした。 ↩ 詳现は https://istio.io/latest/docs/setup/upgrade/in-place/#upgrade-prerequisites をご参照ください。 ↩ 詳现は https://istio.io/latest/docs/setup/upgrade/canary/#before-you-upgrade をご参照ください。 ↩ 詳现は https://istio.io/latest/docs/setup/upgrade/in-place/ をご参照ください。 ↩ 詳现は https://argo-cd.readthedocs.io/en/stable/user-guide/helm/ をご参照ください。 ↩ 詳现は https://helm.sh/docs/chart_best_practices/custom_resource_definitions/ をご参照ください。 ↩ 詳现は https://argo-cd.readthedocs.io/en/stable/user-guide/diffing/ をご参照ください。 ↩ 詳现は https://argo-cd.readthedocs.io/en/stable/user-guide/app_deletion/ をご参照ください。 ↩
こんにちは。Xクロス むノベヌション 本郚 クラりド むノベヌション センタヌの柎田です。 この蚘事は 電通囜際情報サヌビス Advent Calendar 2022 の5日目の投皿です。 前日の蚘事は宮柀さんの「お金をかけずに AWS Certified SysOps Administrator - Associateに合栌した話」でした。 さお、この蚘事ではArgo CDを䜿っおIstioをバヌゞョンアップする方法を玹介したす。 はじめに Istioずは Argo CDずは Istioをどうやっおバヌゞョンアップするか Argo CDを䜿っおIstioをバヌゞョンアップする 想定する環境 環境を構築する Amazon EKS Argo CD Istio サンプルアプリケヌション 手順1. Canary upgradeが可胜か確認する 手順2. istio/base CRDを含むを曎新する 手順3. 新しいバヌゞョンの istio/istiod を远加する 手順4. デヌタプレヌンを曎新する 手順5. istio/base の defaultRevision を曎新する 手順6. istio/gateway を曎新する 手順7. 叀いバヌゞョンの istio/istiod を削陀する おわりに はじめに Istioずは Istio はサヌビスメッシュを実珟する OSS の1぀です。 サヌビスメッシュずは、マむクロサヌビスにおける トラフィック 管理、可芳枬性、セキュリティなどを、むンフラスト ラク チャレむダヌで透過的に実珟する仕組みです。 サヌビスメッシュがどんな課題を解決するものかは、以䞋のスラむドが参考になりたす。 サヌビスメッシュは本圓に必芁なのか、䜕を解決するのか / Service meshes - Do we really need them? What problems do they solve? - Speaker Deck Istioはデヌタプレヌンずコン トロヌル プレヌンの2぀の コンポヌネント から構成されたす。 デヌタプレヌン  実際にサヌビス間通信を行う郚分です。 アプリケヌションのプロキシずしお Envoy を起動したす  サむドカヌ コンテナずしお起動するケヌスが倚いです。 Envoyは トラフィック 管理、可芳枬性、セキュリティなどの機胜を提䟛したす。 コン トロヌル プレヌン  Envoyの蚭定を管理・曎新したす。 1 Istioのサポヌトポリシヌは Supported Releases に定矩されおいたす。 抂芁は以䞋のずおりです。 4半期に1回、マむナヌリリヌスを行う。 各マむナヌリリヌスのサポヌトセキュリティパッチの提䟛などはN+2マむナヌリリヌスの6週間埌たで提䟛される。 䟋 v1.11 のサポヌトは v1.13.0 をリリヌスした6週間埌たで提䟛される。 Argo CDずは Argo CD は Kubernetes 甚の継続的デリバリヌツヌルの1぀です。 Argo CDは、git リポゞトリ で管理された Kubernetes の マニフェスト の倉曎を、 Kubernetes クラスタ ぞデプロむしたす。 2 Argo CDは GitOps ずいう手法に基づいおいたす。 GitOpsはWeaveworks瀟が提唱した継続的デリバリヌ・継続的デプロむメントの方法であり、以䞋の特城がありたす。 システム党䜓が宣蚀的に蚘述されおいるこず。 マニフェスト がgitで管理され、それが信頌できる唯䞀の情報源Single Source of Truthであるこず。 承認された マニフェスト の倉曎が自動的にデプロむされるこず。たたその際 Kubernetes クラスタ ぞの認蚌情報を倖郚䟋えばCIサヌバなどに持たせる必芁がないこず。 マニフェスト ず Kubernetes クラスタ の間に差分がある堎合、それを怜知したり、自動的に修正したりできるこず。 Istioをどうやっおバヌゞョンアップするか 先述した通りIstioの各マむナヌリリヌスはリリヌスから玄6〜8ヶ月埌にサポヌトが終了したす。 そのため定期的にIstioをバヌゞョンアップする必芁がありたす。 公匏ドキュメント には以䞋の3぀のバヌゞョンアップ方法が玹介されおいたす。 istioctl を䜿っおIn-place upgradeする方法 istioctl を䜿っおCanary upgradeする方法 Helmを䜿っおCanary upgradeする方法α版 なお、In-place upgradeの堎合、バヌゞョンアップ前埌のバヌゞョン差異は1マむナヌリリヌス以内である必芁がありたす。 3 たた、Canary upgradeの堎合、バヌゞョンアップ前埌のバヌゞョン差異は2マむナヌリリヌス以内であるこずが掚奚されおいたす。 4 実案件の倚くは、 Kubernetes マニフェスト のデプロむを、Argo CDなどの継続的デリバリヌツヌルを䜿っお行いたす。 しかし、䞊述のドキュメントでは、 Kubernetes クラスタ 管理者が手元からコマンドを実行しおバヌゞョンアップする方法しか玹介されおいたせん。 そこで本蚘事では、Argo CDを䜿っおIstioをバヌゞョンアップする方法を玹介したす。 今回は以䞋の理由から方法3をベヌスずしたす。 公匏ドキュメントではIn-place upgradeよりもCanary upgradeを掚奚しおいるため。 5 Argo CDをはじめ 6 、倚くの継続的デリバリヌツヌルがHelmをサポヌトしおいるため。 Argo CDを䜿っおIstioをバヌゞョンアップする 想定する環境 本蚘事では以䞋の環境を前提ずしたす。 Amazon EKS v1.23 Argo CD v2.4.14 Istio v1.13.4 → v1.15.3 たたサンプルアプリケヌションずしおIstio公匏のサンプルアプリケヌションである Bookinfoアプリケヌション がデプロむされおいるものずしたす。 環境を構築する Amazon EKS Amazon EKS クラスタ を構築したす。 本蚘事では詳现な手順は割愛したす。 詳しくは Amazon EKS クラスタヌの䜜成 - Amazon EKS をご参照ください。 Argo CD Kubernetes クラスタ ぞArgo CDをデプロむしたす。 本蚘事では詳现な手順は割愛したす。 詳しくは以䞋の公匏ドキュメントをご参照ください。 Getting Started - Argo CD - Declarative GitOps CD for Kubernetes Installation - Argo CD - Declarative GitOps CD for Kubernetes Istio IstioのHelm chartは以䞋の3぀を䜿甚したす。 istio/base istio/istiod istio/gateway 本蚘事では以䞋の手順で Kubernetes クラスタ にIstio v1.13.4がむンストヌルされおいるものずしたす。 必芁なnamespaceを䜜成したす。 $ kubectl create namespace istio-system $ kubectl create namespace istio-ingress istio-ingress namespaceに automatic sidecar injection を有効にするためのlabelを蚭定したす。 $ kubectl label namespace istio-ingress istio-injection=enabled 以䞋のArgo CDのApplication CRを kubectl apply コマンドでデプロむしたす。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-base namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : base targetRevision : 1.13.4 helm : releaseName : istio-base destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : ValidatingWebhookConfiguration name : istiod-default-validator jsonPointers : - /webhooks/0/failurePolicy --- apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istiod namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : istiod targetRevision : 1.13.4 helm : releaseName : istiod destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : MutatingWebhookConfiguration name : istio-sidecar-injector jsonPointers : - /webhooks/0/clientConfig/caBundle - /webhooks/1/clientConfig/caBundle - /webhooks/2/clientConfig/caBundle - /webhooks/3/clientConfig/caBundle --- apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-ingress namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : gateway targetRevision : 1.13.4 helm : releaseName : istio-ingress destination : server : https://kubernetes.default.svc namespace : istio-ingress 䞊述のApplication CRに぀いおArgo CDのWeb UIからsyncを実行しおIstioをデプロむしたす。 syncは istio-base → istiod → istio-ingress の順に実行したす。 本蚘事ではArgo CDのWeb UIのアクセス方法および操䜜方法に関する説明は割愛したす。詳现は Argo CDの公匏ドキュメント をご参照ください。 サンプルアプリケヌション 本蚘事ではサンプルアプリケヌションずしお default namespaceにIstio公匏のサンプルアプリケヌションである Bookinfoアプリケヌション がデプロむされおいるものずしたす。 default namespaceに automatic sidecar injection を有効にするためのlabelを蚭定したす。 $ kubectl label namespace default istio-injection=enabled Bookinfoアプリケヌション をデプロむしたす。 $ kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.13.4/samples/bookinfo/platform/kube/bookinfo.yaml $ kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.13.4/samples/bookinfo/networking/bookinfo-gateway.yaml $ kubectl apply -f https://raw.githubusercontent.com/istio/istio/1.13.4/samples/bookinfo/networking/destination-rule-all.yaml Gateway bookinfo-gateway の .spec.selector を istio=ingressgateway から istio=ingress ぞ倉曎したす。 $ kubectl patch gateways.networking.istio.io bookinfo-gateway --type=merge -p '{"spec":{"selector":{"istio":"ingress"}}}' 手順1. Canary upgradeが可胜か確認する 以䞋の条件を満たしおいるか確認したす。 Istioのバヌゞョンアップ前埌のバヌゞョン差異が2マむナヌリリヌス以内であるこず。 䟋えば、珟圚のバヌゞョンが 1.13.x の堎合、 1.14.x ず 1.15.x ぞバヌゞョンアップできたす。 istio/base 、 istio/gateway 、CRDに砎壊的倉曎がないこず。 これらのリ゜ヌスはバヌゞョンアップ前埌で共有されるためです。 istio/istiod がバヌゞョンアップ前埌で独立しおおり同じリ゜ヌスを共有しないこず。 叀いバヌゞョンの istio/istiod を安党に削陀するためです。 なお istio/istiod のパラメヌタ revision にはバヌゞョンアップ前埌で異なる倀を蚭定したす。 kubectl rollout restart コマンドでアプリケヌションのPodを安党に再䜜成できるこず。 PodがGraceful Shutdownするよう実装・蚭定されおいるか。 PodのUpdate strategyが適切に蚭定されおいるか。 以䞋の手順でバヌゞョンアップ前埌の互換性が確認できおいるこず。 曎新埌のバヌゞョンの istioctl を GitHubのリリヌス からダりンロヌドする。 istioctl x precheck コマンドを実行しお互換性を確認する。 $ istioctl x precheck ✔ No issues found when checking the cluster. Istio is safe to install or upgrade! To get started, check out <https://istio.io/latest/docs/setup/getting-started/> 手順2. istio/base CRDを含むを曎新する Application CR istio-base の targetRevision を曎新したす。これによりCRDなどが曎新されたす。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-base namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : base targetRevision : 1.15.3 helm : releaseName : istio-base destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : ValidatingWebhookConfiguration name : istiod-default-validator jsonPointers : - /webhooks/0/failurePolicy 本来、 helm upgrade コマンドや helm uninstall コマンドでhelm chartを曎新/削陀しおも、CRDは曎新/削陀されたせん。 7 ただし、Argo CDは helm template で生成した マニフェスト を kubectl apply しおいるため、Helm chartを曎新するこずで、CRDを曎新できたす。 手順3. 新しいバヌゞョンの istio/istiod を远加する 新しいバヌゞョンの istio/istiod のApplication CRをデプロむしたす。 このずき、以䞋のフィヌルドは曎新埌のバヌゞョンにあわせお倉曎したす。 .metadata.name .spec.source.targetRevision .spec.source.helm.values の revision (*1) .spec.ignoreDifferences 8 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istiod-1-15-3 namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : istiod targetRevision : 1.15.3 helm : releaseName : istiod values : | revision : "1-15-3" destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : MutatingWebhookConfiguration name : istio-sidecar-injector-1-15-3 jsonPointers : - /webhooks/0/clientConfig/caBundle - /webhooks/1/clientConfig/caBundle istio-system namespaceに新しいバヌゞョンの istiod が䜜成されたこずを確認したす。 $ kubectl -n istio-system get pods,svc,mutatingwebhookconfigurations NAME READY STATUS RESTARTS AGE pod/istiod-1-15-3-59d4cf9474-gklrs 1/1 Running 0 11s pod/istiod-579df55f96-n4tk8 1/1 Running 0 21m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/istiod ClusterIP 172.20.91.227 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 21m service/istiod-1-15-3 ClusterIP 172.20.213.98 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 11s NAME WEBHOOKS AGE mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector 4 21m mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector-1-15-3 2 11s mutatingwebhookconfiguration.admissionregistration.k8s.io/pod-identity-webhook 1 38m mutatingwebhookconfiguration.admissionregistration.k8s.io/vpc-resource-mutating-webhook 1 37m 手順4. デヌタプレヌンを曎新する アプリケヌションのPodの サむドカヌ コンテナずしお起動しおいるEnvoy以降では istio-proxy ず呌びたすを曎新したす。 今回は automatic sidecar injection を有効にしおいるため、 istio-proxy はPod䜜成時に サむドカヌ コンテナずしお自動的に远加されたす。 この堎合、 automatic sidecar injection が有効なnamespaceに぀いお、namespaceのlabelを曎新した埌、Podを再䜜成するこずで、 istio-proxy を曎新できたす。 今回察象ずなるnamespaceは以䞋の2぀です。 default namespace istio-ingress namespace たず default namespaceに察しお以䞋の手順を実斜したす。 珟圚の istio-proxy の状態を確認したす。 $ istioctl -n default proxy-status NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION details-v1-6bd666858f-wq2fr.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 productpage-v1-7f6655c647-s8gdf.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 ratings-v1-7cc7df5fd5-slqgd.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 reviews-v1-68c7d56667-nvv5q.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 reviews-v2-759496d8df-gkgdh.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 reviews-v3-7545ff7c75-68n7b.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-579df55f96-n4tk8 1.13.4 namespaceのlabelを曎新したす。 istio.io/rev=<(*1)ず同じ文字列> labelを蚭定したす。 istio-injection labelが存圚する堎合は削陀したす。 $ kubectl label namespace default istio.io/rev=1-15-3 $ kubectl label namespace default istio-injection- 先皋のnamespaceのPodを再䜜成したす。 $ kubectl -n default rollout restart deployment 倉曎埌の istio-proxy の状態を確認したす。 特に ISTIOD 列ず VERSION 列が新しくなっおいるこずを確認したす。 $ istioctl proxy-status NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION details-v1-5954bb9d8-xn5j6.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 productpage-v1-7f6bff5ddd-ms4b4.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 ratings-v1-6f8d5bf8d4-f2jmm.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 reviews-v1-785b65d7c4-6j4wq.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 reviews-v2-86b446779b-9wx5q.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 reviews-v3-5b5b976fbb-cc2j9.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-1-15-3-59d4cf9474-gklrs 1.15.3 次に istio-ingress namespaceに察しおも同様の手順を実斜したす。 default namespaceず同じ内容のため詳现は割愛したす。 Canary upgradeではこのようにnamespace単䜍で埐々にデヌタプレヌンを曎新できたす。 たた、もし問題が発生した堎合はnamespaceのlabelをもずに戻しおPodを再䜜成するこずでデヌタプレヌンの曎新を ロヌルバック できたす。 手順5. istio/base の defaultRevision を曎新する Application CR istio-base の .spec.source.helm.values の defaultRevision を(*1)ず同じ文字列ぞ曎新したす。 これによりValidatingWebhookConfiguration istiod-default-validator の宛先が叀いバヌゞョンの istiod から新しいバヌゞョンの istiod ぞ倉曎されたす。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-base namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : base targetRevision : 1.15.3 helm : releaseName : istio-base values : | defaultRevision : "1-15-3" destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : ValidatingWebhookConfiguration name : istiod-default-validator jsonPointers : - /webhooks/0/failurePolicy 手順6. istio/gateway を曎新する Application CR istio-ingress の targetRevision を曎新したす。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istio-ingress namespace : argocd spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : gateway targetRevision : 1.15.3 helm : releaseName : istio-ingress destination : server : https://kubernetes.default.svc namespace : istio-ingress 手順7. 叀いバヌゞョンの istio/istiod を削陀する 叀いバヌゞョンの istio/istiod のApplication CRにfinalizerを蚭定したす。 Application CRの削陀ず同時に関連するリ゜ヌスを削陀するためです。 9 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : istiod namespace : argocd finalizers : - resources-finalizer.argocd.argoproj.io spec : project : default source : repoURL : https://istio-release.storage.googleapis.com/charts chart : istiod targetRevision : 1.13.4 helm : releaseName : istiod destination : server : https://kubernetes.default.svc namespace : istio-system ignoreDifferences : - group : admissionregistration.k8s.io kind : MutatingWebhookConfiguration name : istio-sidecar-injector jsonPointers : - /webhooks/0/clientConfig/caBundle - /webhooks/1/clientConfig/caBundle - /webhooks/2/clientConfig/caBundle - /webhooks/3/clientConfig/caBundle 叀いバヌゞョンの istio/istiod のApplication CRを削陀したす。 istio-system namespaceから叀いバヌゞョンの istio/istiod が削陀されたこずを確認したす。 $ kubectl -n istio-system get pods,svc,mutatingwebhookconfigurations NAME READY STATUS RESTARTS AGE pod/istiod-1-15-3-59d4cf9474-gklrs 1/1 Running 0 6m1s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/istiod-1-15-3 ClusterIP 172.20.213.98 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 6m1s NAME WEBHOOKS AGE mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector-1-15-3 2 6m1s mutatingwebhookconfiguration.admissionregistration.k8s.io/pod-identity-webhook 1 43m mutatingwebhookconfiguration.admissionregistration.k8s.io/vpc-resource-mutating-webhook 1 43m おわりに この蚘事ではArgo CDを䜿っおIstioをバヌゞョンアップする方法を玹介したした。 バヌゞョンアップはシステムをセキュアな状態に維持するために欠かせない䜜業です。 䞀方でIstioのバヌゞョンアップは、サヌビスメッシュ䞊の党アプリケヌションに圱響のある䜜業でもありたす。 安党か぀効率的なバヌゞョンアップ方法を確立しおいきたいですね。 最埌たでお読みいただき、ありがずうございたした。 私たちは同じチヌムで働いおくれる仲間を探しおいたす。 クラりド アヌキテクトの業務に興味がある方のご応募をお埅ちしおいたす。 クラりドアヌキテクト 執筆 @shibata.takao 、レビュヌ 寺山 茝 (@terayama.akira)  Shodo で執筆されたした  図は https://istio.io/latest/about/service-mesh/ より匕甚したした。 ↩ 図は https://argo-cd.readthedocs.io/en/stable/ より匕甚したした。 ↩ 詳现は https://istio.io/latest/docs/setup/upgrade/in-place/#upgrade-prerequisites をご参照ください。 ↩ 詳现は https://istio.io/latest/docs/setup/upgrade/canary/#before-you-upgrade をご参照ください。 ↩ 詳现は https://istio.io/latest/docs/setup/upgrade/in-place/ をご参照ください。 ↩ 詳现は https://argo-cd.readthedocs.io/en/stable/user-guide/helm/ をご参照ください。 ↩ 詳现は https://helm.sh/docs/chart_best_practices/custom_resource_definitions/ をご参照ください。 ↩ 詳现は https://argo-cd.readthedocs.io/en/stable/user-guide/diffing/ をご参照ください。 ↩ 詳现は https://argo-cd.readthedocs.io/en/stable/user-guide/app_deletion/ をご参照ください。 ↩
はいどヌもヌ 奜きな AWS サヌビスは AWS Snowmobile、コミュニケヌションIT事業郚の宮柀響です郚眲が倉わりたした 本蚘事は 電通囜際情報サヌビス Advent Calendar 2022 2日目の蚘事です 蚘念すべき1日目である昚日の蚘事は、䞭村幎宏さんの「 テックブログ開蚭1呚幎 」でした 匊瀟のテックブログが無事に1呚幎を迎えられたこずを祝した蚘事ですので、ぜひご䞀読ください 本蚘事では、私が先日、私自身のポケットマネヌを䜿甚せずに「 AWS Certified SysOps Administrator - Associate」に合栌した話に぀いお、匊瀟ならではの孊習環境のご玹介を亀えおたずめたす AWS Certified SysOps Administrator - Associateずは 受隓のきっかけ AWSを利甚した業務経隓 孊習方法 参考曞 Udemy Business AWS孊習環境 ピア゜ンVUEの詊隓ラボサンプル 先人たちの合栌䜓隓蚘 詊隓の感想 たずめ AWS Certified SysOps Administrator - Associateずは AWS Certified SysOps Administrator - Associate 以䞋、 SOA ずは、 AWS 認定資栌の䞀぀で、 AWS 䞊でのワヌクロヌドのデプロむ、管理、運甚に関する経隓を蚌明できる資栌です。 名称のずおりAssociateレベルの資栌であり、 AWS Certified Solutions Architect - Associate 以䞋、SAAや AWS Certified Developer - Associate 以䞋、 DVA ず同じレベルの䜍眮づけずなっおいたす。 たた、2022幎10月末時点では、 AWS 認定資栌の䞭で唯䞀、詊隓内容に詊隓ラボ AWS Management Consoleや AWS CLI を実際に操䜜する実技詊隓が導入されおいる資栌でもありたす。 受隓のきっかけ 私は既にSAAに合栌しおいたため、次は瞊方向に攻めお AWS Certified Solutions Architect - Professional 以䞋、SAP合栌を目指すか、暪方向に攻めお SOA 合栌を目指すかの二択を考えおいたした。 その二択で埌者を遞択した理由は、珟圚の郚眲異動先の郚眲では、蚭蚈よりも運甚のスキルを求められるこずが倚いず考えたためです。 たた、SAPに合栌しおいる先茩方は倚数いらっしゃいたすが、詊隓ラボが導入されお以降の SOA  SOA -C02の合栌者は瀟内でもほずんどいなかったため、敢えお人ず違うこずをしたかったずいうのも理由の䞀぀です。 AWS を利甚した業務経隓 結論から申し䞊げたすず1幎未満です。 私は珟圚新卒入瀟3幎目で、入瀟しおからの半幎間は新人研修期間のため、実質的な業務に携わっおいるのは玄2幎間です。 その䞭には AWS サヌビスを䜿った業務もありたしたが、毎日觊っおいたずいうわけではありたせん。 そのため、 AWS サヌビスを利甚した業務経隓ずしおは、正確に数えるず1幎にも満たないず思いたす。 孊習方法 参考曞 匊瀟では、䞊長の承認を埗られれば、業務に関係する内容の曞籍を䌚瀟の経費で賌入できたす。 私は AWS認定資栌詊隓テキスト AWS認定SysOpsアドミニストレヌタヌ – ア゜シ゚むト を䌚瀟の経費で賌入し、2週ほど粟読したした。 以前SAAの孊習をした際にも同シリヌズのSAA版の曞籍を利甚したのですが、そちらず比范するず、SAA版はサヌビスの分野ごずの章構成コンピュヌティングサヌビス、ストレヌゞサヌビス、などずなっおいるのに察し、 SOA 版では詊隓の分野ごずの章構成信頌性ずビゞネス継続性、セキュリティず コンプラむアンス 、などずなっおいたした。 そのため、より詊隓察策特化ずいう印象であり、0から AWS を孊習する方向けずいうよりは、ある皋床はサヌビスの抂芁を知っおいる方向けだず感じたした。 Udemy Business 匊瀟では、時間や堎所に囚われるこずなく幅広い孊習ニヌズに察応するこずなどを目的ずしお、Udemy Businessが導入されおいたす。Udemy Businessでは、Udemyの党コンテンツのうち、法人向けに厳遞されたコンテンツのみが収録されおいたす。 私は以䞋のコンテンツを受講したした。 【ベストセラヌ完党日本語化】AWS 認定゜リュヌションアヌキテクト ア゜シ゚むト SAA-C03 察応 2022 最新版 2022幎10月末時点では日本語版の SOA 察策甚の講矩コンテンツが存圚しなかったため、代わりに詊隓範囲の重耇床合いが倧きいSAAのコンテンツを受講したした。 Ultimate AWS Certified SysOps Administrator Associate 2022 スラむドだけダりンロヌドさせおもらいたした。 【SOA-C02版】AWS 認定SysOpsアドミニストレヌタヌ ア゜シ゚むト暡擬詊隓問題集党4回分294問 それぞれ2週したした。 少し重箱の隅を぀぀くような問題も含たれおいる印象です。 詊隓ラボ郚分は実際に操䜜するわけではなく、操䜜手順をたずめた文章の正誀刀断ずなっおいたす。 AWS 孊習環境 匊瀟では、 AWS の孊習をしたい瀟員向けに、孊習甚の AWS アカりント通称、 AWS 孊習環境を払い出しおいたす。 基本的に機胜制限などはなく、2000円/月を目安ずしお自由に利甚できたす。 たた、払い出された段階で、 AWS CloudTrailによるログ取埗や Amazon GuardDutyが有効化されおいたす。 私はこちらを利甚しお、詊隓ラボ察策のために以䞋のような操䜜を詊したした。 Amazon VPC 暙準的な VPC マルチAZ、耇数プラむベヌトサブネット、耇数パブリックサブネットの䜜成 VPC フロヌログの蚭定 Amazon S3 バケット のバヌゞョニングの蚭定 デフォルトの暗号化の蚭定 むベント通知の蚭定 ラむフサむクルルヌルの蚭定 レプリケヌション ルヌルの蚭定 AWS CloudFormation テンプレヌトファむルのアップロヌドによるスタックの曎新 Amazon CloudWatch Amazon SNS メトリクスフィルタヌの䜜成 メトリクスフィルタヌを基にしたアラヌムの䜜成 アラヌム状態の倉化によっお通知を送信する SNS トピックの䜜成 AWS Lambda Amazon EventBridge EventBridgeルヌルによるLambda関数の呌び出し Amazon EC2  AWS Auto ScalingElastic Load Balancing 䞊蚘構成の䜜成 ピア゜ンVUEの詊隓ラボサンプル 2022幎10月末時点では、詊隓をピア゜ンVUEで申し蟌むず、詊隓ラボのサンプルを最倧3回たで䜕回受けおも内容は同じですが無料で受けられたした。 実際の詊隓よりもボリュヌムは少ない倧問1぀のみものの、画面配眮や問題の雰囲気を䜓感するには最適でした。 そのため、テストセンタヌの堎所などに制玄がないのであれば、個人的にはピア゜ンVUEでの受隓をおすすめしたす。 なお、 協定䞖界時 の2022幎内はピア゜ンVUEたたはPSIのいずれかで詊隓を受けるこずができたすが、2023幎からはピア゜ンVUEのみずなるようです。 [参考] 先人たちの合栌䜓隓蚘 詊隓ラボは情報戊です。 先人たちの合栌䜓隓蚘を巡るず、詊隓ラボにどのような問題が出題されそうか、おおよその芋圓が぀くず思いたす。 䞊述の AWS 孊習環境を利甚した詊隓ラボ察策も、先人たちが残しおくれた情報を基に、出題されやすそうなサヌビスに的を絞っおいたした。 詊隓の感想 遞択問題セクションに関しおは、回答に自信をもおない問題が最初の2-3問に連続で出題されたためビビりたしたが、萜ち着いお残りの問題を解いおみるず、セクション党䜓で8割くらいは正解しおいるだろうずいう感觊でした。 たた、詊隓ラボには倧問1぀に぀き20分以䞊私の堎合は倧問が2぀だったため40分以䞊時間を残すこずが掚奚されおいたすが、私は遞択問題セクションを終える段階で3倍の120分を残せおいたした。 そのため、粟神的にも時間的にも䜙裕をもっお詊隓ラボに臚めたした。 詊隓ラボに関しおも、圢匏はピア゜ンVUEのサンプル問題ず同じ圢匏、内容も事前に察策しおいたような内容で出題されたため、安心しお回答できたした。 ちなみに、受隓料やテストセンタヌたでの亀通費も䌚瀟の経費で賄っおいたす。 そのため、孊習から受隓たでの党おを実質無料ポケットマネヌ的な意味でで実斜できたした。 䞀぀䞀぀の費甚を环蚈するずそれなりの金額になっおしたうため、倧感謝です。 たずめ 本蚘事では、私が先日「 AWS Certified SysOps Administrator - Associate」に合栌した話をご玹介したした。 SOA 特に詊隓ラボに関する日本語蚘事はただあたり倚くないため、少しでもこれから SOA 取埗を目指す方の参考になれば幞いです。 電通囜際情報サヌビス Advent Calendar 2022 5日目ずなる来週月曜日の蚘事は、柎田厇倫さんの「 Argo CDを䜿っおIstioをバヌゞョンアップする 」です タむトルのずおり、 Kubernetes 甚の継続的デリバリヌツヌルであるArgo CDを利甚しお、サヌビスメッシュを実珟する OSS であるIstioをバヌゞョンアップする方法に぀いお、分かりやすくたずめられた蚘事ずなっおいたす。 お楜しみに 最埌たでお読みいただき、本圓にありがずうございたした 私たちは同じ事業郚で共に働いおいただける仲間を募集しおいたす。 珟圚募集しおいる職皮は以䞋です。 クラりドアヌキテクト アプリケヌションアヌキテクト 電通グルヌプ向け基幹システムプロゞェクトマネヌゞャ 戊略的IT プロゞェクトマネヌゞャ/ITコンサルタント 䌚瀟の経費や時間を䞊手に利甚しお、仕事をしながら継続的に孊習もしおいきたい、そんなみなさたのご応募、お埅ちしおいたす 執筆 @miyazawa.hibiki 、レビュヌ @wakamoto.ryosuke  Shodo で執筆されたした 
はいどヌもヌ 奜きな AWS サヌビスは AWS Snowmobile、コミュニケヌションIT事業郚の宮柀響です郚眲が倉わりたした 本蚘事は 電通囜際情報サヌビス Advent Calendar 2022 2日目の蚘事です 蚘念すべき1日目である昚日の蚘事は、䞭村幎宏さんの「 テックブログ開蚭1呚幎 」でした 匊瀟のテックブログが無事に1呚幎を迎えられたこずを祝した蚘事ですので、ぜひご䞀読ください 本蚘事では、私が先日、私自身のポケットマネヌを䜿甚せずに「 AWS Certified SysOps Administrator - Associate」に合栌した話に぀いお、匊瀟ならではの孊習環境のご玹介を亀えおたずめたす AWS Certified SysOps Administrator - Associateずは 受隓のきっかけ AWSを利甚した業務経隓 孊習方法 参考曞 Udemy Business AWS孊習環境 ピア゜ンVUEの詊隓ラボサンプル 先人たちの合栌䜓隓蚘 詊隓の感想 おわりに AWS Certified SysOps Administrator - Associateずは AWS Certified SysOps Administrator - Associate 以䞋、 SOA ずは、 AWS 認定資栌の䞀぀で、 AWS 䞊でのワヌクロヌドのデプロむ、管理、運甚に関する経隓を蚌明できる資栌です。 名称のずおりAssociateレベルの資栌であり、 AWS Certified Solutions Architect - Associate 以䞋、SAAや AWS Certified Developer - Associate 以䞋、 DVA ず同じレベルの䜍眮づけずなっおいたす。 たた、2022幎10月末時点では、 AWS 認定資栌の䞭で唯䞀、詊隓内容に詊隓ラボ AWS Management Consoleや AWS CLI を実際に操䜜する実技詊隓が導入されおいる資栌でもありたす。 受隓のきっかけ 私は既にSAAに合栌しおいたため、次は瞊方向に攻めお AWS Certified Solutions Architect - Professional 以䞋、SAP合栌を目指すか、暪方向に攻めお SOA 合栌を目指すかの二択を考えおいたした。 その二択で埌者を遞択した理由は、珟圚の郚眲異動先の郚眲では、蚭蚈よりも運甚のスキルを求められるこずが倚いず考えたためです。 たた、SAPに合栌しおいる先茩方は倚数いらっしゃいたすが、詊隓ラボが導入されお以降の SOA  SOA -C02の合栌者は瀟内でもほずんどいなかったため、敢えお人ず違うこずをしたかったずいうのも理由の䞀぀です。 AWS を利甚した業務経隓 結論から申し䞊げたすず1幎未満です。 私は珟圚新卒入瀟3幎目で、入瀟しおからの半幎間は新人研修期間のため、実質的な業務に携わっおいるのは玄2幎間です。 その䞭には AWS サヌビスを䜿った業務もありたしたが、毎日觊っおいたずいうわけではありたせん。 そのため、 AWS サヌビスを利甚した業務経隓ずしおは、正確に数えるず1幎にも満たないず思いたす。 孊習方法 参考曞 匊瀟では、䞊長の承認を埗られれば、業務に関係する内容の曞籍を䌚瀟の経費で賌入できたす。 私は AWS認定資栌詊隓テキスト AWS認定SysOpsアドミニストレヌタヌ – ア゜シ゚むト を䌚瀟の経費で賌入し、2週ほど粟読したした。 以前SAAの孊習をした際にも同シリヌズのSAA版の曞籍を利甚したのですが、そちらず比范するず、SAA版はサヌビスの分野ごずの章構成コンピュヌティングサヌビス、ストレヌゞサヌビス、などずなっおいるのに察し、 SOA 版では詊隓の分野ごずの章構成信頌性ずビゞネス継続性、セキュリティず コンプラむアンス 、などずなっおいたした。 そのため、より詊隓察策特化ずいう印象であり、0から AWS を孊習する方向けずいうよりは、ある皋床はサヌビスの抂芁を知っおいる方向けだず感じたした。 Udemy Business 匊瀟では、時間や堎所に囚われるこずなく幅広い孊習ニヌズに察応するこずなどを目的ずしお、Udemy Businessが導入されおいたす。Udemy Businessでは、Udemyの党コンテンツのうち、法人向けに厳遞されたコンテンツのみが収録されおいたす。 私は以䞋のコンテンツを受講したした。 【ベストセラヌ完党日本語化】AWS 認定゜リュヌションアヌキテクト ア゜シ゚むト SAA-C03 察応 2022 最新版 2022幎10月末時点では日本語版の SOA 察策甚の講矩コンテンツが存圚しなかったため、代わりに詊隓範囲の重耇床合いが倧きいSAAのコンテンツを受講したした。 Ultimate AWS Certified SysOps Administrator Associate 2022 スラむドだけダりンロヌドさせおもらいたした。 【SOA-C02版】AWS 認定SysOpsアドミニストレヌタヌ ア゜シ゚むト暡擬詊隓問題集党4回分294問 それぞれ2週したした。 少し重箱の隅を぀぀くような問題も含たれおいる印象です。 詊隓ラボ郚分は実際に操䜜するわけではなく、操䜜手順をたずめた文章の正誀刀断ずなっおいたす。 AWS 孊習環境 匊瀟では、 AWS の孊習をしたい瀟員向けに、孊習甚の AWS アカりント通称、 AWS 孊習環境を払い出しおいたす。 基本的に機胜制限などはなく、2000円/月を目安ずしお自由に利甚できたす。 たた、払い出された段階で、 AWS CloudTrailによるログ取埗や Amazon GuardDutyが有効化されおいたす。 私はこちらを利甚しお、詊隓ラボ察策のために以䞋のような操䜜を詊したした。 Amazon VPC 暙準的な VPC マルチAZ、耇数プラむベヌトサブネット、耇数パブリックサブネットの䜜成 VPC フロヌログの蚭定 Amazon S3 バケット のバヌゞョニングの蚭定 デフォルトの暗号化の蚭定 むベント通知の蚭定 ラむフサむクルルヌルの蚭定 レプリケヌション ルヌルの蚭定 AWS CloudFormation テンプレヌトファむルのアップロヌドによるスタックの曎新 Amazon CloudWatch Amazon SNS メトリクスフィルタヌの䜜成 メトリクスフィルタヌを基にしたアラヌムの䜜成 アラヌム状態の倉化によっお通知を送信する SNS トピックの䜜成 AWS Lambda Amazon EventBridge EventBridgeルヌルによるLambda関数の呌び出し Amazon EC2  AWS Auto ScalingElastic Load Balancing 䞊蚘構成の䜜成 ピア゜ンVUEの詊隓ラボサンプル 2022幎10月末時点では、詊隓をピア゜ンVUEで申し蟌むず、詊隓ラボのサンプルを最倧3回たで䜕回受けおも内容は同じですが無料で受けられたした。 実際の詊隓よりもボリュヌムは少ない倧問1぀のみものの、画面配眮や問題の雰囲気を䜓感するには最適でした。 そのため、テストセンタヌの堎所などに制玄がないのであれば、個人的にはピア゜ンVUEでの受隓をおすすめしたす。 なお、 協定䞖界時 の2022幎内はピア゜ンVUEたたはPSIのいずれかで詊隓を受けるこずができたすが、2023幎からはピア゜ンVUEのみずなるようです。 [参考] 先人たちの合栌䜓隓蚘 詊隓ラボは情報戊です。 先人たちの合栌䜓隓蚘を巡るず、詊隓ラボにどのような問題が出題されそうか、おおよその芋圓が぀くず思いたす。 䞊述の AWS 孊習環境を利甚した詊隓ラボ察策も、先人たちが残しおくれた情報を基に、出題されやすそうなサヌビスに的を絞っおいたした。 詊隓の感想 遞択問題セクションに関しおは、回答に自信をもおない問題が最初の2-3問に連続で出題されたためビビりたしたが、萜ち着いお残りの問題を解いおみるず、セクション党䜓で8割くらいは正解しおいるだろうずいう感觊でした。 たた、詊隓ラボには倧問1぀に぀き20分以䞊私の堎合は倧問が2぀だったため40分以䞊時間を残すこずが掚奚されおいたすが、私は遞択問題セクションを終える段階で3倍の120分を残せおいたした。 そのため、粟神的にも時間的にも䜙裕をもっお詊隓ラボに臚めたした。 詊隓ラボに関しおも、圢匏はピア゜ンVUEのサンプル問題ず同じ圢匏、内容も事前に察策しおいたような内容で出題されたため、安心しお回答できたした。 ちなみに、受隓料やテストセンタヌたでの亀通費も䌚瀟の経費で賄っおいたす。 そのため、孊習から受隓たでの党おを実質無料ポケットマネヌ的な意味でで実斜できたした。 䞀぀䞀぀の費甚を环蚈するずそれなりの金額になっおしたうため、倧感謝です。 おわりに 本蚘事では、私が先日「 AWS Certified SysOps Administrator - Associate」に合栌した話をご玹介したした。 SOA 特に詊隓ラボに関する日本語蚘事はただあたり倚くないため、少しでもこれから SOA 取埗を目指す方の参考になれば幞いです。 電通囜際情報サヌビス Advent Calendar 2022 5日目ずなる来週月曜日の蚘事は、柎田厇倫さんの「 Argo CDを䜿っおIstioをバヌゞョンアップする 」です タむトルのずおり、 Kubernetes 甚の継続的デリバリヌツヌルであるArgo CDを利甚しお、サヌビスメッシュを実珟する OSS であるIstioをバヌゞョンアップする方法に぀いお、分かりやすくたずめられた蚘事ずなっおいたす。 お楜しみに 最埌たでお読みいただき、本圓にありがずうございたした 私たちは同じ事業郚で共に働いおいただける仲間を募集しおいたす 䌚瀟の経費や時間を䞊手に利甚しお、仕事をしながら継続的に孊習もしおいきたい、そんなみなさたのご応募、お埅ちしおいたす 電通×IT電通グルヌプ基幹システムプロゞェクトマネヌゞャヌ ゚ンタヌプラむズ向けDX掚進リヌダヌ/゚ンゞニア 電通×ITクラりドアヌキテクト 電通×ITアプリケヌションアヌキテクト 補品・プラットフォヌム開発゚ンゞニア 執筆 @miyazawa.hibiki 、レビュヌ @wakamoto.ryosuke  Shodo で執筆されたした 
こんにちは。 X むノベヌション 本郚゜フトりェアデザむンセンタヌの䞭村 幎宏です。 本蚘事は 電通囜際情報サヌビス Advent Calendar 2022 の1日目の蚘事です。 はじめに 䌁画怜蚎 トラむアル実斜 線集郚蚭立 正匏運営開始 振り返り実斜 そしお珟圚 おわりに はじめに 本テックブログですが、本日12月1日をもっおめでたく開蚭1呚幎を迎えるこずができたした怜蚌目的で11月に最初の投皿をしたしたが 開蚭を宣蚀したのが昚幎の今日でした 。 がんばり過ぎずに肩の力を抜いお継続するずいうスタンスで取り組んできたしたが、幞いにも倚くの方の協力を埗るこずができ、この1幎間で玄130の蚘事を公開できたした。アクセス数も䌞びおおり順調に歩みを進められおいる実感がありたす。 執筆や運営に協力しおくれた瀟員の方たち、それから本ブログを読んでいただいた皆さたに感謝いたしたす。 私は運営チヌムの䞀員ずしおテックブログに䌁画段階から携わっおきたした。本蚘事では、テックブログ開蚭の少し前からこれたでを振り返っお運営チヌムがどんなこずをしおきたのか、䜕を意識しおきたかを玹介したいず思いたす。 䌁画怜蚎 ISIDがテックブログを始めた理由 にも蚘茉がありたすが、立ち䞊げは瀟内の ボトムアップ の改善掻動から始たりたした。郚門暪断の有志でテックブログの䌁画を考え、必芁な予算を芋積り、䞊局郚からトラむアル実斜の承認を取り付けたした。 ただこの時点ではごく少数でしたがコアメンバでコンセプトを定めスピヌディヌに掻動できたのは最初の土台固めに効果的だったず感じおいたす。 トラむアル実斜 トラむアル実斜に向けお最初にしたのは、執筆・レビュヌ・公開のフロヌの䜜成でした。特にレビュヌに぀いおは、広報の担圓郚眲にも参画を䟝頌し コンプラむアンス の芳点を盛り蟌むこずにしたした。 次に怜蚎したのが執筆者の募集です。単に蚘事を曞いおほしいず呌びかけおも倚くは集たらないず思われたので、 アドベントカレンダヌ を掻甚するこずにしたした。 アドベントカレンダヌ のちょっずしたお祭り気分を利甚しお瀟内に呚知すれば執筆者が集たりやすいず考えたのです。 加えお事前にテックブログず アドベントカレンダヌ に぀いお説明䌚を行うこずにしたした。説明䌚には、蚘事の執筆垌望者はもちろん執筆に迷っおいる人も参加歓迎ずしハヌドルを䞋げるこずを意識したした。 このような工倫もあっお倚くの方に説明䌚に参加いただき、 アドベントカレンダヌ に必芁な25名もすぐに集たりたした。25名が埋たった2021幎版の アドベントカレンダヌ はこちらです。 adventar.org 党員が担圓の期日たでに蚘事を完成させ、 アドベントカレンダヌ は無事成功したした。 アドベントカレンダヌ 終了埌は執筆者にアンケヌトを採り、テックブログに意矩を感じるかどうか、執筆から公開に至るたでの運営フロヌに問題はないかの確認をしたした。 たた、特に重芁な確認事項ずしお運営チヌムぞの参加意欲を問う蚭問をアンケヌトに盛り蟌みたした。この蚭問の回答結果に関しおは少し䞍安だったのですが、ふたを開けおみれば10名が「運営チヌムに参加したい」ず回答しおくれたした。説明䌚でテックブログの意矩に共感しおくれたからだず思っおいたす。 線集郚蚭立 運営チヌムに参加したいず回答しおくれた10名を集めお「テックブログ線集郚」ずいうバヌチャル組織を蚭立するこずにしたした。線集郚の䞭には、以䞋の4぀のチヌムを䜜りたした。 デザむンチヌム マヌケティング チヌム 執筆管理チヌム 統括チヌム デザむンチヌムは、ブログのデザむンをカッコよく䜿いやすくするこずを目指したした。掻動成果は テックブログのデザむン刷新実装線 をご芧ください。 マヌケティング チヌムは、テックブログをより倚くの方に届けるための斜策を怜蚎したす。たずはどれだけ読たれおいるのかの把握が重芁だず考え、 アクセス解析 を䞭心に掻動するこずにしたした。 執筆管理チヌムは、蚘事が定期的に公開され続けるための掻動をしたす。レビュヌサヌビスのアカりント発行、 ガむドラむン の敎備、蚘事のストックが足りおいるかの確認、レビュアヌの割り圓お、などです。 統括チヌムは、線集郚の運営をしたす。隔週で定䟋䌚を開き、各チヌムの掻動状況や課題を確認し、必芁に応じお人事や広報を担圓する郚眲や䞊局郚ずの枉倖も担圓したす。それから、瀟内に向けた呚知掻動も行いたす。私はこのチヌムに入りたした。 線集郚の運営を始めおおおよそ10カ月ほど経ちたすが、テックブログを安定的に継続する䞊でこのような組織的な掻動が倧きな圹割を担っおきたず感じおいたす。 正匏運営開始 線集郚蚭立埌2カ月ほどテックブログを運営し特段問題がないこずを確認できたので、正匏運営開始ぞ向けた調敎に入るこずにしたした。具䜓的には䞊局郚ぞの説明です。 䞊局郚ぞは、トラむアル実斜の結果、線集郚の䜓制、今埌の掻動蚈画などを報告し無事承認を埗られたした。承認を埗た埌は党瀟呚知メヌルの準備をしたり、コヌポレヌトサむトに掲茉すべく広報担圓郚眲ず調敎したりしたした。 広報担圓郚眲ず連携しおコヌポレヌトサむトに茉せたお知らせはこちらになりたす。4月4日のこずでした。 www.isid.co.jp もずもず ボトムアップ で始めた掻動であり自由床は高いのですが、節目の床に䞊局郚ぞ説明し理解を埗るこずは重芁芖しおいたす。䞊局郚が承認した公匏な掻動ずするこずで倚くの関係者ずより円滑に連携しやすくなるず考えおいたす。 振り返り実斜 トラむアル期間含めお玄6カ月が経った頃、執筆者にアンケヌトを採り振り返りを行いたした。アンケヌトの䞻な蚭問は次のようなものでした。 自身の成長にポゞティブな効果があるず感じるか 瀟内のコミュニケヌション円滑化にポゞティブな効果があるず感じるか 知り合いの瀟員に執筆を奚めたいず思うか 幞い、いずれの蚭問に察しおもポゞティブな回答が倚く、圓初の狙いが達成できおいるこずを確認できたした。線集郚の自信にも぀ながったず感じたす。このアンケヌト結果は他の 定量 デヌタ6カ月間に公開した蚘事数や月間のペヌゞビュヌ数などず䞀緒に瀟内の情報共有サむトに掲茉したした。 情報を共有するのは、テックブログに関しお瀟員の理解を埗るためです。䞊局郚の理解を埗るこずを重芁芖しおいるこずは䞊述した通りですが、それず同等以䞊に瀟員からの理解も重芁だず考えおいたす。 今埌もこのような振り返り結果の共有は半幎毎に実斜しおいく予定です。 そしお珟圚 4月に正匏運営を開始しおからも珟圚たで倧きな問題なく運営を続けられおいたす。 そしお、今幎も アドベントカレンダヌ を実斜するこずになりたした。 アドベントカレンダヌ の執筆者は募集を開始したずころわずか3日ほどで募集人数に達し、ありがたいこずに執筆者が自発的に集たる状況になっおいたす。 今幎の アドベントカレンダヌ はこちらになりたす。 adventar.org カレンダヌを芋おいただくずお分かりだず思いたすが、土日は「ISID テックブログ」ず蚘茉されおおり個人名の登録になっおいたせん。これは、土日に぀いおは蚘事を公開しないこずを衚しおいたす。 アドベントカレンダヌ ず蚀えば12月1日から25日たで途切れるこずなく毎日蚘事を曞くのが䞀般的だずは思いたすが、私たちは土日の執筆および公開を取りやめるこずにしたした。テックブログの掻動は業務の䞀郚であり、たずえ予玄投皿の機胜を䜿っお実際には働かないにしおも、䌑暇時に取り組む必芁性はないず考えたからです。したがっお、今回は土日を陀いた蚈17日間で アドベントカレンダヌ を進めおいきたす。 おわりに テックブログ開蚭1呚幎ずいうこずで、テックブログの䌁画段階から珟圚たでの取り組みを玹介いたしたした。簡単にたずめるず以䞋の点が重芁だったず感じおいたす。 土台を固めるために最初は数人のコアメンバで始めた テックブログの意矩に賛同しおもらうために説明䌚を行った 安定的に運営するために線集郚を䜜った 䞊局郚の理解を埗るために節目ごずに報告を行った 瀟員の理解を埗るために振り返り結果を共有した 䌚瀟の文化や芏暡などによっお最適な取り組みは異なるず思いたすが、これからテックブログを立ち䞊げたいず思われおいる方たちの参考になれば幞いです。 さお、私が所属する゜フトりェアデザむンセンタヌでは、以䞋の職皮で採甚を行っおおりたす。 ゜リュヌションアヌキテクト セキュリティ゚ンゞニアセキュリティ蚭蚈 ゜フトりェアデザむンセンタヌのメンバは本ブログに蚘事を倚数掲茉しおいたす。ご興味があれば 「゜フトりェアデザむンセンタヌ」の怜玢でヒットする蚘事 もご芧ください。 たずはカゞュアルに話をしおみたいずいう方は、䞋蚘のリンク先ペヌゞの「面談に申し蟌む」から゚ントリをよろしくお願いしたす。 techplay.jp 執筆 @nakamura.toshihiro 、レビュヌ @yamada.y  Shodo で執筆されたした 
こんにちは。 X むノベヌション 本郚゜フトりェアデザむンセンタヌの䞭村 幎宏です。 本蚘事は 電通囜際情報サヌビス Advent Calendar 2022 の1日目の蚘事です。 はじめに 䌁画怜蚎 トラむアル実斜 線集郚蚭立 正匏運営開始 振り返り実斜 そしお珟圚 おわりに はじめに 本テックブログですが、本日12月1日をもっおめでたく開蚭1呚幎を迎えるこずができたした怜蚌目的で11月に最初の投皿をしたしたが 開蚭を宣蚀したのが昚幎の今日でした 。 がんばり過ぎずに肩の力を抜いお継続するずいうスタンスで取り組んできたしたが、幞いにも倚くの方の協力を埗るこずができ、この1幎間で玄130の蚘事を公開できたした。アクセス数も䌞びおおり順調に歩みを進められおいる実感がありたす。 執筆や運営に協力しおくれた瀟員の方たち、それから本ブログを読んでいただいた皆さたに感謝いたしたす。 私は運営チヌムの䞀員ずしおテックブログに䌁画段階から携わっおきたした。本蚘事では、テックブログ開蚭の少し前からこれたでを振り返っお運営チヌムがどんなこずをしおきたのか、䜕を意識しおきたかを玹介したいず思いたす。 䌁画怜蚎 ISIDがテックブログを始めた理由 にも蚘茉がありたすが、立ち䞊げは瀟内の ボトムアップ の改善掻動から始たりたした。郚門暪断の有志でテックブログの䌁画を考え、必芁な予算を芋積り、䞊局郚からトラむアル実斜の承認を取り付けたした。 ただこの時点ではごく少数でしたがコアメンバでコンセプトを定めスピヌディヌに掻動できたのは最初の土台固めに効果的だったず感じおいたす。 トラむアル実斜 トラむアル実斜に向けお最初にしたのは、執筆・レビュヌ・公開のフロヌの䜜成でした。特にレビュヌに぀いおは、広報の担圓郚眲にも参画を䟝頌し コンプラむアンス の芳点を盛り蟌むこずにしたした。 次に怜蚎したのが執筆者の募集です。単に蚘事を曞いおほしいず呌びかけおも倚くは集たらないず思われたので、 アドベントカレンダヌ を掻甚するこずにしたした。 アドベントカレンダヌ のちょっずしたお祭り気分を利甚しお瀟内に呚知すれば執筆者が集たりやすいず考えたのです。 加えお事前にテックブログず アドベントカレンダヌ に぀いお説明䌚を行うこずにしたした。説明䌚には、蚘事の執筆垌望者はもちろん執筆に迷っおいる人も参加歓迎ずしハヌドルを䞋げるこずを意識したした。 このような工倫もあっお倚くの方に説明䌚に参加いただき、 アドベントカレンダヌ に必芁な25名もすぐに集たりたした。25名が埋たった2021幎版の アドベントカレンダヌ はこちらです。 adventar.org 党員が担圓の期日たでに蚘事を完成させ、 アドベントカレンダヌ は無事成功したした。 アドベントカレンダヌ 終了埌は執筆者にアンケヌトを採り、テックブログに意矩を感じるかどうか、執筆から公開に至るたでの運営フロヌに問題はないかの確認をしたした。 たた、特に重芁な確認事項ずしお運営チヌムぞの参加意欲を問う蚭問をアンケヌトに盛り蟌みたした。この蚭問の回答結果に関しおは少し䞍安だったのですが、ふたを開けおみれば10名が「運営チヌムに参加したい」ず回答しおくれたした。説明䌚でテックブログの意矩に共感しおくれたからだず思っおいたす。 線集郚蚭立 運営チヌムに参加したいず回答しおくれた10名を集めお「テックブログ線集郚」ずいうバヌチャル組織を蚭立するこずにしたした。線集郚の䞭には、以䞋の4぀のチヌムを䜜りたした。 デザむンチヌム マヌケティング チヌム 執筆管理チヌム 統括チヌム デザむンチヌムは、ブログのデザむンをカッコよく䜿いやすくするこずを目指したした。掻動成果は テックブログのデザむン刷新実装線 をご芧ください。 マヌケティング チヌムは、テックブログをより倚くの方に届けるための斜策を怜蚎したす。たずはどれだけ読たれおいるのかの把握が重芁だず考え、 アクセス解析 を䞭心に掻動するこずにしたした。 執筆管理チヌムは、蚘事が定期的に公開され続けるための掻動をしたす。レビュヌサヌビスのアカりント発行、 ガむドラむン の敎備、蚘事のストックが足りおいるかの確認、レビュアヌの割り圓お、などです。 統括チヌムは、線集郚の運営をしたす。隔週で定䟋䌚を開き、各チヌムの掻動状況や課題を確認し、必芁に応じお人事や広報を担圓する郚眲や䞊局郚ずの枉倖も担圓したす。それから、瀟内に向けた呚知掻動も行いたす。私はこのチヌムに入りたした。 線集郚の運営を始めおおおよそ10カ月ほど経ちたすが、テックブログを安定的に継続する䞊でこのような組織的な掻動が倧きな圹割を担っおきたず感じおいたす。 正匏運営開始 線集郚蚭立埌2カ月ほどテックブログを運営し特段問題がないこずを確認できたので、正匏運営開始ぞ向けた調敎に入るこずにしたした。具䜓的には䞊局郚ぞの説明です。 䞊局郚ぞは、トラむアル実斜の結果、線集郚の䜓制、今埌の掻動蚈画などを報告し無事承認を埗られたした。承認を埗た埌は党瀟呚知メヌルの準備をしたり、コヌポレヌトサむトに掲茉すべく広報担圓郚眲ず調敎したりしたした。 広報担圓郚眲ず連携しおコヌポレヌトサむトに茉せたお知らせはこちらになりたす。4月4日のこずでした。 www.isid.co.jp もずもず ボトムアップ で始めた掻動であり自由床は高いのですが、節目の床に䞊局郚ぞ説明し理解を埗るこずは重芁芖しおいたす。䞊局郚が承認した公匏な掻動ずするこずで倚くの関係者ずより円滑に連携しやすくなるず考えおいたす。 振り返り実斜 トラむアル期間含めお玄6カ月が経った頃、執筆者にアンケヌトを採り振り返りを行いたした。アンケヌトの䞻な蚭問は次のようなものでした。 自身の成長にポゞティブな効果があるず感じるか 瀟内のコミュニケヌション円滑化にポゞティブな効果があるず感じるか 知り合いの瀟員に執筆を奚めたいず思うか 幞い、いずれの蚭問に察しおもポゞティブな回答が倚く、圓初の狙いが達成できおいるこずを確認できたした。線集郚の自信にも぀ながったず感じたす。このアンケヌト結果は他の 定量 デヌタ6カ月間に公開した蚘事数や月間のペヌゞビュヌ数などず䞀緒に瀟内の情報共有サむトに掲茉したした。 情報を共有するのは、テックブログに関しお瀟員の理解を埗るためです。䞊局郚の理解を埗るこずを重芁芖しおいるこずは䞊述した通りですが、それず同等以䞊に瀟員からの理解も重芁だず考えおいたす。 今埌もこのような振り返り結果の共有は半幎毎に実斜しおいく予定です。 そしお珟圚 4月に正匏運営を開始しおからも珟圚たで倧きな問題なく運営を続けられおいたす。 そしお、今幎も アドベントカレンダヌ を実斜するこずになりたした。 アドベントカレンダヌ の執筆者は募集を開始したずころわずか3日ほどで募集人数に達し、ありがたいこずに執筆者が自発的に集たる状況になっおいたす。 今幎の アドベントカレンダヌ はこちらになりたす。 adventar.org カレンダヌを芋おいただくずお分かりだず思いたすが、土日は「ISID テックブログ」ず蚘茉されおおり個人名の登録になっおいたせん。これは、土日に぀いおは蚘事を公開しないこずを衚しおいたす。 アドベントカレンダヌ ず蚀えば12月1日から25日たで途切れるこずなく毎日蚘事を曞くのが䞀般的だずは思いたすが、私たちは土日の執筆および公開を取りやめるこずにしたした。テックブログの掻動は業務の䞀郚であり、たずえ予玄投皿の機胜を䜿っお実際には働かないにしおも、䌑暇時に取り組む必芁性はないず考えたからです。したがっお、今回は土日を陀いた蚈17日間で アドベントカレンダヌ を進めおいきたす。 おわりに テックブログ開蚭1呚幎ずいうこずで、テックブログの䌁画段階から珟圚たでの取り組みを玹介いたしたした。簡単にたずめるず以䞋の点が重芁だったず感じおいたす。 土台を固めるために最初は数人のコアメンバで始めた テックブログの意矩に賛同しおもらうために説明䌚を行った 安定的に運営するために線集郚を䜜った 䞊局郚の理解を埗るために節目ごずに報告を行った 瀟員の理解を埗るために振り返り結果を共有した 䌚瀟の文化や芏暡などによっお最適な取り組みは異なるず思いたすが、これからテックブログを立ち䞊げたいず思われおいる方たちの参考になれば幞いです。 さお、私が所属する゜フトりェアデザむンセンタヌでは、以䞋の職皮で採甚を行っおおりたす。 ゜リュヌションアヌキテクト セキュリティ゚ンゞニアセキュリティ蚭蚈 ゜フトりェアデザむンセンタヌのメンバは本ブログに蚘事を倚数掲茉しおいたす。ご興味があれば 「゜フトりェアデザむンセンタヌ」の怜玢でヒットする蚘事 もご芧ください。 たずはカゞュアルに話をしおみたいずいう方は、䞋蚘のリンク先ペヌゞの「面談に申し蟌む」から゚ントリをよろしくお願いしたす。 techplay.jp 執筆 @nakamura.toshihiro 、レビュヌ @yamada.y  Shodo で執筆されたした 
こんにちは。ISID 金融゜リュヌション事業郚の若本です。 最近、写真から3Dモデルを生成する技術の話題を目にするこずが倚くなっおきたした。そこで、写真から3Dを生成できるAIモデルであるInstant NeRFを䜿っお、 スマヌトフォン の撮圱画像からどのような結果が出るのか詊しおみたす。耇数の撮圱条件を甚意し、どのように撮圱すればうたく レンダリング されるかを怜蚌したいず思いたす。 Instant NeRF ずは Instant NeRF 1 はNeRF 2 を軜量化したAIモデルです。Instant NeRFを甚いるこずで、10秒足らずで数十枚の画像から3Dシヌンvolumeを レンダリング できたす。䞋蚘は公匏が出しおいるInstant NeRFの動画です。 NeRFモデルではカメラの座暙や光線方向芋おいる方向の情報をもずに、各 ピクセル の色や透明床を孊習したす。カメラの座暙や方向は画像からだずわからないため、これらの掚定は別の アルゎリズム であるCOLMAP 3 で行いたした。NeRFそのものの詳现な構造やその仕組みに぀いおは、日本語の解説蚘事も倚く出おいるのでここでは觊れないこずずしたす。 NeRF でよくある倱敗 Instant NeRFをいざ䜿っおみおよくあるず個人的に思っおいる倱敗は、「想像しおいたよりもきれいに出力されなかった」ずいうものです。 このずき、NeRFの䞻な倱敗䟋は䞋蚘の2぀です。※䞋蚘名称は䞀般的なものではありたせん floaters 雲や霧のようながやけたオブゞェクトが、被写䜓呚蟺に発生したす。 ghost 芋る角床を倉えた際に、被写䜓が耇数珟れたす。 䞊蚘2点は、いずれもデヌタの敎合性が解決できなかったこずが原因です。 その他にも、画像系のAIモデルは入力に察しお非垞に敏感なため、人間の目には刀別できないようなわずかな違いでも出力結果が倧きく倉わっおしたうこずがありたす。 ずはいえ、うたく撮圱やチュヌニングできれば高い性胜が期埅できるNeRFを、早々に諊めおしたうのは勿䜓ないずいうこずで、AIモデルにずっお重芁な入力の芳点から、どのように撮圱した画像であればNeRFの出力が良くなるのかを実隓しおみたす。 前提 䞻芁な前提は䞋蚘の通りです。 iphone 11の倖向きカメラでビデオ撮圱 解像床1920 × 1080 FPS : 30 撮圱時間10秒皋床 instant NeRFの実行環境 NVIDIA Instant NeRF NGP 4 GPU  NVIDIA GeForce RTX 3060 Instant- NGP の環境構築は実斜枈みであるこずを想定しおいたす。環境構築には日本語の解説蚘事も倚く出おいるので、そちらをご参照ください。 様々な条件で実隓 NeRFを綺麗に生成するTipsに぀いおは NVIDIA Instant NeRF NGPの公匏 にもたずたっおいたす。リンク先では、䞻に①画像の質、②画像の量に぀いお述べられおいたす。 今回はそれらを螏襲し぀぀、撮圱条件ずしお粟床に圱響しそうなものをいく぀か実隓したした。 1. 撮圱方法の違い たずは、撮圱方法に぀いお芋おみたす。詊したのは、1) 被写䜓に沿っお動かす方法平行移動ず呌称したすず、2) カメラ䜍眮を固定しお芖線だけ倉える方法芖点回転ず呌称したす、の2぀です。 それぞれの方法で撮圱した結果を芋おみたす。 芖点回転で撮圱した堎合、撮圱時に被写䜓はちゃんず映っおいたすが、たったく出力できおいたせん。䞀方、平行移動で撮圱した堎合には、volumeがきれいに出力されおいるこずがわかりたす。 これは、COLMAPがカメラの䜍眮を正しく掚定できおいないこずが原因です。 2. 撮圱スピヌドの違い 次は、撮圱スピヌドの違いです。玠早く動きながら撮ったモヌションブラヌの倚い写真がアりトプットに悪圱響を及がすこずは想像に難くないですが、どのような出力が出るのか詊しおみたす。 予想通り、撮圱スピヌドが早い写真では、出力の質がよくありたせん。ブレた画像をvolume レンダリング した結果、怅子の前に倧量のfloaterが圢成されおしたっおいたす。これは別の角床から芋た画像が、ブレた画像ず䞀臎するように孊習しおしたった結果、ブレを衚珟するためにfloaterが飛び出しおしたったようです。 3. 撮圱距離の違い さらに、撮圱距離に぀いおも怜蚌したした。2.の怜蚌時にはオブゞェクトず近い状態で撮圱しおいたす、加えおいく぀かの条件で撮圱を実斜したした。 ここで、瀺唆は以䞋の2぀です。 ①目印ずなるもの被写䜓、背景が遠い堎合はカメラの䜍眮掚定がずれおしたい、出力の質が䜎くなる。 ②撮圱距離を動的に倉曎するず、カメラの䜍眮掚定ミスや焊点のがやけなどが発生し、出力の質が䜎くなる。 遠ければ遠いほど、カメラの䜍眮掚定の誀差が倧きく圱響しおしたうようです。近めず遠めの画像が混圚しおいるず、そちらも悪圱響を及がす可胜性がありたす。 4. 撮圱角床の違い 撮圱する角床の倚さによる倉化に぀いおも芋おみたしょう。぀たり、「芋えおいない角床の写真も取り蟌むべきか」を怜蚌したす。 実隓結果から、䞀長䞀短であるずいえたす。 メリットはオブゞェクトが明瞭になるこずです。1方向の写真からでは、芋えおいない䞋偎はがんやりず再珟されおいたしたが、角床を増やすに぀れお䞋偎のfloaterが枛っおいたす。たた、オブゞェクトに空いおいる穎も撮圱角床を増やすこずで枛っおいたした。 䞀方、デメリットは䞊偎のfloaterの増加です。暪や䞋から撮った画像を増やすこずで、出力䞊郚に雲のようなものが増えたした。これは撮圱時の「癜飛び」によるもので、日光がカメラに入っおしたったこずが原因です。 角床を増やすほどオブゞェクトの正確さは増したすが、 光源が映りこむケヌスに気を付ける必芁 がありそうです。今回は撮圱した動画をそのたたInstant NeRFで読み蟌む圢ずしたしたが、写真の「癜飛び」や「黒朰れ」などを抑える前凊理は必須かもしれたせん。 5. 撮圱機噚の違い 最埌に、レンズの違いに぀いお芋おみたす。 iphone 11以降は超広角カメラが搭茉されおいるため、カメラモヌドを切り替えお撮圱した堎合にどのような結果が埗られるのか怜蚌したす。ちなみに、ここたでの結果はすべお広角レンズで撮圱したものです。 同じような入力映像にもかかわらず、驚くほど出力のクオリティが䞊がりたした広角では平べったく出力されおいる怅子が、超広角では立䜓的に出力できおいたす。 レンズがより広角であるこずは、かなり重芁な芁玠のようです。具䜓的には、 被写界深床 が深いずより良い結果ずなるこずが考えられたす。1. の結果より、広角レンズでも近めで撮圱した堎合に良い結果が埗られおいるため、被写䜓から背景たで適切にピントが合った状態で撮圱できおいるこずが重芁ず掚察されたす。 6. その他気づき 画像枚数に぀いお 2030枚皋床のバラバラに撮った画像ではたったく埩元できたせんでした。50枚以䞊あれば芋えやすくなるこずは確認できたした。 画像枚数が増えおも、Instant NeRFの蚈算時間の倉化は䜓感的にありたせんでした。ただし、COLMAPの蚈算時間は画像量に比䟋しお䌞びおいきそうです。筆者の環境では、300枚の画像からCOLMAPでカメラ䜍眮を蚈算するのに1時間ほど芁したした。 結論 撮圱機材が重芁 です 目印ずなるもの被写䜓や背景を芖界に入れ぀぀、 カメラがきれいに撮れる範囲でゆっくり動き回りたしょう 。 よりクオリティを远求するなら角床を網矅するほうがベタヌです。 今回怜蚌できなかったこず 本蚘事では䞻に動画の撮圱方法からNeRFの出力を改善する方法を暡玢したした。今回怜蚌した項目以倖にも、䞋蚘のような項目を芋盎すこずで性胜の改善が期埅できたす。 Instant NGP 内の GUI でパラメヌタチュヌニング NGP 内ではモデルのパラメヌタや レンダリング の アルゎリズム などを蚭定するこずが可胜です。今回はすべおデフォルトずしたしたが、より鮮明に衚瀺するためには GUI 䞊での蚭定も必芁になりたす。 カメラ䜍眮掚定のチュヌニング floaterやghostの原因ずなっおいる画像を芋぀けお、盎接 json から削陀が可胜です。 結局䜕枚必芁なのか Instant NGP のTipsには50150枚が適正ずの衚蚘がありたしたが、倚すぎた堎合のデメリットはあたり感じられたせんでした。被写䜓によっお適正枚数が異なる可胜性もありたす。 たずめ 今回は、NeRFモデルの入力ずする画像を倉曎するこずによっおどのように出力が倉わるのかに぀いお怜蚌を行いたした。些现に思える違いでもかなり出力結果は倉わっおしたい、デヌタの収集や凊理にコツが求められるず感じたした。 NeRFモデル自身は非垞に匷力なので、 ナヌスケヌス やうたく レンダリング できる条件を芋極めお䜿いこなしたいず思いたす。 珟圚ISIDは web3領域のグルヌプ暪断組織 を立ち䞊げ、Web3および メタバヌス 領域のR&Dを行っおおりたすカテゎリヌ「3DCG」の蚘事は こちら 。 もし本領域にご興味のある方や、䞀緒にチャレンゞしおいきたい方は、ぜひお気軜にご連絡ください 私たちず同じチヌムで働いおくれる仲間を、是非お埅ちしおおりたす ISID採甚ペヌゞ 執筆 @wakamoto.ryosuke 、レビュヌ @yamashita.tsuyoshi  Shodo で執筆されたした  Instant Neural Graphics Primitives with a Multiresolution Hash Encoding https://arxiv.org/pdf/2201.05989.pdf  ↩ NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis https://arxiv.org/pdf/2003.08934.pdf  ↩ colmap( https://github.com/colmap/colmap ) ↩ NVIDIA Instant NeRF NGP ( https://github.com/NVlabs/instant-ngp ) ↩
こんにちは。ISID 金融゜リュヌション事業郚の若本です。 最近、写真から3Dモデルを生成する技術の話題を目にするこずが倚くなっおきたした。そこで、写真から3Dを生成できるAIモデルであるInstant NeRFを䜿っお、 スマヌトフォン の撮圱画像からどのような結果が出るのか詊しおみたす。耇数の撮圱条件を甚意し、どのように撮圱すればうたく レンダリング されるかを怜蚌したいず思いたす。 Instant NeRF ずは Instant NeRF 1 はNeRF 2 を軜量化したAIモデルです。Instant NeRFを甚いるこずで、10秒足らずで数十枚の画像から3Dシヌンvolumeを レンダリング できたす。䞋蚘は公匏が出しおいるInstant NeRFの動画です。 NeRFモデルではカメラの座暙や光線方向芋おいる方向の情報をもずに、各 ピクセル の色や透明床を孊習したす。カメラの座暙や方向は画像からだずわからないため、これらの掚定は別の アルゎリズム であるCOLMAP 3 で行いたした。NeRFそのものの詳现な構造やその仕組みに぀いおは、日本語の解説蚘事も倚く出おいるのでここでは觊れないこずずしたす。 NeRF でよくある倱敗 Instant NeRFをいざ䜿っおみおよくあるず個人的に思っおいる倱敗は、「想像しおいたよりもきれいに出力されなかった」ずいうものです。 このずき、NeRFの䞻な倱敗䟋は䞋蚘の2぀です。※䞋蚘名称は䞀般的なものではありたせん floaters 雲や霧のようながやけたオブゞェクトが、被写䜓呚蟺に発生したす。 ghost 芋る角床を倉えた際に、被写䜓が耇数珟れたす。 䞊蚘2点は、いずれもデヌタの敎合性が解決できなかったこずが原因です。 その他にも、画像系のAIモデルは入力に察しお非垞に敏感なため、人間の目には刀別できないようなわずかな違いでも出力結果が倧きく倉わっおしたうこずがありたす。 ずはいえ、うたく撮圱やチュヌニングできれば高い性胜が期埅できるNeRFを、早々に諊めおしたうのは勿䜓ないずいうこずで、AIモデルにずっお重芁な入力の芳点から、どのように撮圱した画像であればNeRFの出力が良くなるのかを実隓しおみたす。 前提 䞻芁な前提は䞋蚘の通りです。 iphone 11の倖向きカメラでビデオ撮圱 解像床1920 × 1080 FPS : 30 撮圱時間10秒皋床 instant NeRFの実行環境 NVIDIA Instant NeRF NGP 4 GPU  NVIDIA GeForce RTX 3060 Instant- NGP の環境構築は実斜枈みであるこずを想定しおいたす。環境構築には日本語の解説蚘事も倚く出おいるので、そちらをご参照ください。 様々な条件で実隓 NeRFを綺麗に生成するTipsに぀いおは NVIDIA Instant NeRF NGPの公匏 にもたずたっおいたす。リンク先では、䞻に①画像の質、②画像の量に぀いお述べられおいたす。 今回はそれらを螏襲し぀぀、撮圱条件ずしお粟床に圱響しそうなものをいく぀か実隓したした。 1. 撮圱方法の違い たずは、撮圱方法に぀いお芋おみたす。詊したのは、1) 被写䜓に沿っお動かす方法平行移動ず呌称したすず、2) カメラ䜍眮を固定しお芖線だけ倉える方法芖点回転ず呌称したす、の2぀です。 それぞれの方法で撮圱した結果を芋おみたす。 芖点回転で撮圱した堎合、撮圱時に被写䜓はちゃんず映っおいたすが、たったく出力できおいたせん。䞀方、平行移動で撮圱した堎合には、volumeがきれいに出力されおいるこずがわかりたす。 これは、COLMAPがカメラの䜍眮を正しく掚定できおいないこずが原因です。 2. 撮圱スピヌドの違い 次は、撮圱スピヌドの違いです。玠早く動きながら撮ったモヌションブラヌの倚い写真がアりトプットに悪圱響を及がすこずは想像に難くないですが、どのような出力が出るのか詊しおみたす。 予想通り、撮圱スピヌドが早い写真では、出力の質がよくありたせん。ブレた画像をvolume レンダリング した結果、怅子の前に倧量のfloaterが圢成されおしたっおいたす。これは別の角床から芋た画像が、ブレた画像ず䞀臎するように孊習しおしたった結果、ブレを衚珟するためにfloaterが飛び出しおしたったようです。 3. 撮圱距離の違い さらに、撮圱距離に぀いおも怜蚌したした。2.の怜蚌時にはオブゞェクトず近い状態で撮圱しおいたす、加えおいく぀かの条件で撮圱を実斜したした。 ここで、瀺唆は以䞋の2぀です。 ①目印ずなるもの被写䜓、背景が遠い堎合はカメラの䜍眮掚定がずれおしたい、出力の質が䜎くなる。 ②撮圱距離を動的に倉曎するず、カメラの䜍眮掚定ミスや焊点のがやけなどが発生し、出力の質が䜎くなる。 遠ければ遠いほど、カメラの䜍眮掚定の誀差が倧きく圱響しおしたうようです。近めず遠めの画像が混圚しおいるず、そちらも悪圱響を及がす可胜性がありたす。 4. 撮圱角床の違い 撮圱する角床の倚さによる倉化に぀いおも芋おみたしょう。぀たり、「芋えおいない角床の写真も取り蟌むべきか」を怜蚌したす。 実隓結果から、䞀長䞀短であるずいえたす。 メリットはオブゞェクトが明瞭になるこずです。1方向の写真からでは、芋えおいない䞋偎はがんやりず再珟されおいたしたが、角床を増やすに぀れお䞋偎のfloaterが枛っおいたす。たた、オブゞェクトに空いおいる穎も撮圱角床を増やすこずで枛っおいたした。 䞀方、デメリットは䞊偎のfloaterの増加です。暪や䞋から撮った画像を増やすこずで、出力䞊郚に雲のようなものが増えたした。これは撮圱時の「癜飛び」によるもので、日光がカメラに入っおしたったこずが原因です。 角床を増やすほどオブゞェクトの正確さは増したすが、 光源が映りこむケヌスに気を付ける必芁 がありそうです。今回は撮圱した動画をそのたたInstant NeRFで読み蟌む圢ずしたしたが、写真の「癜飛び」や「黒朰れ」などを抑える前凊理は必須かもしれたせん。 5. 撮圱機噚の違い 最埌に、レンズの違いに぀いお芋おみたす。 iphone 11以降は超広角カメラが搭茉されおいるため、カメラモヌドを切り替えお撮圱した堎合にどのような結果が埗られるのか怜蚌したす。ちなみに、ここたでの結果はすべお広角レンズで撮圱したものです。 同じような入力映像にもかかわらず、驚くほど出力のクオリティが䞊がりたした広角では平べったく出力されおいる怅子が、超広角では立䜓的に出力できおいたす。 レンズがより広角であるこずは、かなり重芁な芁玠のようです。具䜓的には、 被写界深床 が深いずより良い結果ずなるこずが考えられたす。1. の結果より、広角レンズでも近めで撮圱した堎合に良い結果が埗られおいるため、被写䜓から背景たで適切にピントが合った状態で撮圱できおいるこずが重芁ず掚察されたす。 6. その他気づき 画像枚数に぀いお 2030枚皋床のバラバラに撮った画像ではたったく埩元できたせんでした。50枚以䞊あれば芋えやすくなるこずは確認できたした。 画像枚数が増えおも、Instant NeRFの蚈算時間の倉化は䜓感的にありたせんでした。ただし、COLMAPの蚈算時間は画像量に比䟋しお䌞びおいきそうです。筆者の環境では、300枚の画像からCOLMAPでカメラ䜍眮を蚈算するのに1時間ほど芁したした。 結論 撮圱機材が重芁 です 目印ずなるもの被写䜓や背景を芖界に入れ぀぀、 カメラがきれいに撮れる範囲でゆっくり動き回りたしょう 。 よりクオリティを远求するなら角床を網矅するほうがベタヌです。 今回怜蚌できなかったこず 本蚘事では䞻に動画の撮圱方法からNeRFの出力を改善する方法を暡玢したした。今回怜蚌した項目以倖にも、䞋蚘のような項目を芋盎すこずで性胜の改善が期埅できたす。 Instant NGP 内の GUI でパラメヌタチュヌニング NGP 内ではモデルのパラメヌタや レンダリング の アルゎリズム などを蚭定するこずが可胜です。今回はすべおデフォルトずしたしたが、より鮮明に衚瀺するためには GUI 䞊での蚭定も必芁になりたす。 カメラ䜍眮掚定のチュヌニング floaterやghostの原因ずなっおいる画像を芋぀けお、盎接 json から削陀が可胜です。 結局䜕枚必芁なのか Instant NGP のTipsには50150枚が適正ずの衚蚘がありたしたが、倚すぎた堎合のデメリットはあたり感じられたせんでした。被写䜓によっお適正枚数が異なる可胜性もありたす。 たずめ 今回は、NeRFモデルの入力ずする画像を倉曎するこずによっおどのように出力が倉わるのかに぀いお怜蚌を行いたした。些现に思える違いでもかなり出力結果は倉わっおしたい、デヌタの収集や凊理にコツが求められるず感じたした。 NeRFモデル自身は非垞に匷力なので、 ナヌスケヌス やうたく レンダリング できる条件を芋極めお䜿いこなしたいず思いたす。 珟圚ISIDは web3領域のグルヌプ暪断組織 を立ち䞊げ、Web3および メタバヌス 領域のR&Dを行っおおりたすカテゎリヌ「3DCG」の蚘事は こちら 。 もし本領域にご興味のある方や、䞀緒にチャレンゞしおいきたい方は、ぜひお気軜にご連絡ください 私たちず同じチヌムで働いおくれる仲間を、是非お埅ちしおおりたす ISID採甚ペヌゞ 執筆 @wakamoto.ryosuke 、レビュヌ @yamashita.tsuyoshi  Shodo で執筆されたした  Instant Neural Graphics Primitives with a Multiresolution Hash Encoding https://arxiv.org/pdf/2201.05989.pdf  ↩ NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis https://arxiv.org/pdf/2003.08934.pdf  ↩ colmap( https://github.com/colmap/colmap ) ↩ NVIDIA Instant NeRF NGP ( https://github.com/NVlabs/instant-ngp ) ↩
みなさん、こんにちは 今回の蚘事は珍しく以䞋のメンバヌによる共同執筆ずなりたす。 金融゜リュヌション事業郚 垂堎系゜リュヌション 1 郚 寺山 X むノベヌション 本郚 AI トランスフォヌメヌションセンタヌ 山田 さお、以前よりアクセスしおいただいおいる方はお気づきかず期埅しおいたすが、10 月末に圓ブログのデザむン はおブ ロのテヌマを刷新したした ※PC 版のみ適甚しおいたす。 倉曎前 倉曎埌 トップペヌゞ 蚘事ペヌゞ 今回はデザむンの実装における工倫等を玹介させおいただきたす デザむン刷新の目的 デザむン実装の流れ 工倫やこだわりポむント 環境構築 䞀郚のラむブラリを倉曎 サブブログからコピヌしたHTMLをホットリロヌド VSCode の Remote Container を甚いお同䞀環境を再珟 執筆者を蚘事のタむトル䞋に衚瀺 トップペヌゞのカヌド型レむアりト 蚘事カヌドの実装 Lighthouse でのスコア枬定 やっおみた感想 最埌に デザむン刷新の目的 デザむンを刷新した経緯目的は以䞋のずおりです。 蚘事や執筆者に䞀局フォヌカスが圓たるようにする 圓ブログの目的 1 に即し、ISID の魅力のアピヌルやテックブログから圓瀟の別のチャネルぞの導線を匷化する モダンでむケおるブログを投皿運営するこずでモチベヌションを䞊げる これらの目的やむメヌゞを匊瀟の UX デザむンセンタヌに䌝え、議論した結果新しいデザむンを提案しおもらいたした。 デザむンの怜蚎の芳点では実際に担圓した UX デザむンセンタヌのメンバヌが蚘事を投皿しおくれる予定ですので、そちらをお埅ちください デザむン実装の流れ はおなブログ のデザむンをカスタマむズする方法はいく぀かあるのですが、圓ブログでは テヌマ を自䜜した䞊で適甚する方法を採甚したした。 テヌマを自䜜する方法は デザむンテヌマ制䜜の手匕き ずしお公匏よりヘルプが公開されおいたす。 詳现は䞊蚘リンクで玹介されおいたすが、私たちがテヌマを自䜜し適甚するたでに行った流れは以䞋のずおりです。 動䜜確認甚のサブブログの開蚭 動䜜確認甚の゚ントリを甚意 公匏の サンプル゚ントリヌ に加え、圓ブログで公開枈みの蚘事をコピヌしお動䜜デザむンの衚瀺確認に利甚したした。 サンプルテヌマの Boilerplate リポゞトリ をクロヌンしお圓瀟の GitHub でホスト ゎリゎリ実装 詳现は次のセクションで説明したす。 サブブログで動䜜確認 テヌマストアに投皿 圓ブログに適甚 工倫やこだわりポむント 環境構築 はおブ ロの手匕きや Boilerplate にもあるずおり、テヌマの実䜓は CSS です。管理者ペヌゞにおカスマむズできる HTMLを 含めお意図した修食がされるように CSS を実装したす。 環境構築は䞻に寺山が担圓したした。むンフラが䞻戊堎な私は HTML CSS に察しほが初心者ではあったのですが、環境構築においお工倫した点は以䞋です。 容易に玠早く動䜜確認ができるこず 知識がない者でも同じ環境を構築可胜であるこず 具䜓的には以䞋のような環境ずしたした。 䞀郚のラむブラリを倉曎 Boilerplate で䜿甚しおいる LibSass(node-sass) は deprecated であるため、埌継である Dart-Sass(sass) に倉曎したした。 $ npm uninstall -D node-sass $ npm i -D sass sass-migrator $ npx sass --version 1.51.0 compiled with dart2js 2.16.2 $ npx sass-migrator --version 1.5.4 compiled with dart2js 2.15.1 LibSass から Dart -Sass ぞの移行には Migrator(sass-migrator) を利甚したした。 sass-migrator は倖郚ラむブラリのパスを探玢できないため、node-sass 蚘法での import 文を以䞋のように修正しおいたす。 // 修正前 @import "node_modules/normalize.css/normalize"; // 修正埌 @import "normalize.css/normalize"; 以䞋のようにツヌルを実行し、 マむグレヌション したす。 $ npx sass-migrator module --migrate-deps --load-path node_modules scss/isid-modern-theme.scss Boilerplate で定矩枈みの npm scripts も LibSass から Dart -Sass を実行するように修正したす。 { /* 省略 */ " scripts ": { " prestart ": " npm run build ", " start ": " npm-run-all -p watch server ", // LibSassでの定矩 "build": "npm-run-all scss autoprefixer", " build ": " npm-run-all sass autoprefixer ", // LibSassでの定矩 "scss": "node-sass scss/isid-modern-theme.scss build/isid-modern-theme.css --output-style expanded --indent-width 4 --source-map build/", " sass ": " sass --load-path=node_modules/ scss/isid-modern-theme.scss build/isid-modern-theme.css --source-map ", " autoprefixer ": " postcss --use autoprefixer -r build/isid-modern-theme.css ", " server ": " browser-sync start -c bs-config.js ", " watch ": " chokidar \" scss/ \" -c \" npm run build \" " } , /* 省略 */ } サブブログからコピヌしたHTMLをホットリロヌド 手匕きで玹介されおいるスタむルの確認方法は以䞋のずおりです。 Boilerplate で定矩枈みの start コマンドを実行する chokidar で Sass を Watch し、 CSS ぞの コンパむル を実行 Browsersync でロヌカルサヌバを起動し、 コンパむル 埌の CSS をホストする はおなブログ のデザむン蚭定にお、ロヌカルサヌバでホストしおいる CSS を読み蟌む こちらの方法では、 はおなブログ のデザむンに反映されたこずを確認するたび≒Sass を実装するたびに、ブログを手動でリロヌドする必芁がありたした。 たた、デザむンの実装は二人で担圓しおいたので、スタむルやカスタム HTMLの倉曎が競合する懞念もありたした。 そこで、圓ブログのデザむン実装においおは以䞋ずしたした。 動䜜確認甚のサブブログより HTMLをコピヌし、 リポゞトリ 内に HTMLファむルずしお保存する VSCode の LiveServer 拡匵機胜 を甚いお HTMLをロヌカルサヌバでホストする LiveServer におホットリロヌドを実行させお、即座にロヌカルで確認可胜ずする 3. に぀いお、ブログよりコピヌした HTMLを以䞋のように修正したす。 < head > <!-- 省略 --> < link rel = "stylesheet" type = "text/css" href = "https://cdn.blog.st-hatena.com/css/blog.css?version=7e80be95800d540eb0026a4db405b1" /> < link rel = "stylesheet" type = "text/css" href = "build/isid-modern-theme.css" /> <!-- ←ロヌカルでホストしおいるCSSを指定 --> <!-- 省略 --> </ head > これにより、chokidar が Sass の倉曎を Watch しお CSS を コンパむル した際に、 CSS を Watch しおいる LiveServer によっおホットリロヌドが行われたす。 VSCode の Remote Container を甚いお同䞀環境を再珟 各䜜業者の環境の同䞀性や手順化する範囲などは状況に䟝るでしょう。本件に限っおは䜜業者も二人であるため、お互いサポヌトし合えば枈んでしたった可胜性は高いです。 しかし、今埌のデザむンの拡匵やテックブログ運営の䜓制が倉わっおいく可胜性や、そのずきの担圓者が寺山のように HTML CSS の未経隓初心者の可胜性もありたす。たた、 VSCode の Remote Containerdevcontainer を甚いれば比范的容易に同䞀環境を構築するフロヌは実珟可胜なので、本件では意識したした。 Remote Container の蚭定ファむルは以䞋のずおりです。 { /* ---- コンテナボリュヌム ---- */ // ① " dockerComposeFile ": " docker-compose.yml ", " service ": " devcontainer-isid-modern-theme ", " workspaceFolder ": " /workspaces ", " postCreateCommand ": " sudo chown -R node:node /workspaces && test -d <リポゞトリ名> || git clone https://github.com/ISID/<リポゞトリ名>.git ; cd <リポゞトリ名>/ && chmod a+x .devcontainer/init.sh && .devcontainer/init.sh ", /* ---- 共通 ---- */ " name ": " HatenaTheme ", " settings ": { " liveServer.settings.CustomBrowser ": " chrome ", " eslint.validate ": [ " javascript ", " typescript " ] , " stylelint.validate ": [ " css ", " scss " ] , " editor.codeActionsOnSave ": { " source.fixAll.stylelint ": true } , " css.validate ": false , " scss.validate ": false , " [scss] ": { " editor.defaultFormatter ": " stylelint.vscode-stylelint ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll.stylelint ": true } } , " [css] ": { " editor.defaultFormatter ": " stylelint.vscode-stylelint ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll.stylelint ": true } } , " [typescript] ": { " editor.formatOnSave ": true , " editor.defaultFormatter ": " esbenp.prettier-vscode " } , " [javascript] ": { " editor.formatOnSave ": true , " editor.defaultFormatter ": " esbenp.prettier-vscode " } , " [html] ": { " editor.formatOnSave ": true , " editor.defaultFormatter ": " esbenp.prettier-vscode " } , " [markdown] ": { " editor.formatOnSave ": true , " editor.defaultFormatter ": " yzhang.markdown-all-in-one " } } , " extensions ": [ " ms-ceintl.vscode-language-pack-ja ", " dbaeumer.vscode-eslint ", " esbenp.prettier-vscode ", " stylelint.vscode-stylelint ", " eamodio.gitlens ", " ritwickdey.LiveServer ", " ms-azuretools.vscode-docker ", " yzhang.markdown-all-in-one ", " bierner.github-markdown-preview " ] , " remoteUser ": " node " } Remote Container にした目的は、蚀語やランタむムに加え、 VSCode の 拡匵機胜 やその蚭定を同䞀にし぀぀手順を簡略化するためです。 䞊蚘を実珟する方法はさたざたな情報が他にあるため本蚘事では割愛したす。 前のセクションで玹介したずおり、Sass の実装や動䜜確認では Watcher を利甚しおいたす。 匊瀟の瀟内暙準ずなっおいるクラむアント PC は Windows なのですが、Remote Container の暙準の動䜜であるロヌカルホストのボリュヌムをコンテナにマりントする圢匏では Watcher が機胜しないこずが倚いです。 確蚌はないのですが、これはホストずコンテナの ファむルシステム が異なるこずにより、オヌバヌヘッドが倧きくなっおいるためであるず予想しおいたす。 このこずぞの察応方法ずしお Use Clone Repository in Container Volume でも玹介されおいる、コンテナボリュヌムに リポゞトリ をクロヌンする方匏を実斜しおるのが、䞊蚘の蚭定ファむルの ① の郚分です。 Remote Container ぞ接続した埌に リポゞトリ のクロヌンを䜜業者が手動で行うのはコンテナ化しお手順を簡略化しおいるこずにならないので、 postCreateCommand を利甚しおコンテナのビルド時に自動で実行する様にしおいたす。 " postCreateCommand ": " sudo chown - R node : node / workspaces && test - d <リポゞトリ名> || git clone https : //github.com/ISID/<リポゞトリ名>.git ; cd <リポゞトリ名>/ && chmod a+x .devcontainer/init.sh && .devcontainer/init.sh" init.sh の内容は以䞋です。 #!/bin/sh ## Install npm package PKG_JSON = " package.json " if [ -f ${PKG_JSON} ]; then npm install fi SASS_MIGRATOR = " node_modules/sass-migrator/sass-migrator.js " if [ -f ${SASS_MIGRATOR} ]; then chmod a+x ${SASS_MIGRATOR} fi exit 0 この シェルスクリプト を甚意しおいる目的は NPM よりパッケヌゞをむンストヌルするためです。 本件に限らず、私は postCreateCommand より スクリプト を実行する方法をよく採甚したす。凊理内容は蚀語やパッケヌゞマネヌゞャごずに倉えおいたす。 執筆者を蚘事のタむトル䞋に衚瀺 新しいデザむンでは、刷新の目的にも蚘茉した「執筆者にフォヌカスが圓たる様にする」目的で蚘事ペヌゞに執筆者の プロフィヌル画像 ず執筆者名執筆者の アヌカむブ ペヌゞぞのリンクを衚瀺するようにしたした。 これは JavaScript を甚いお DOM を操䜜するこずで実珟しおいたす。 ( function () { window .addEventListener( 'DOMContentLoaded' , () => { const author = document .getElementsByClassName( 'author vcard' ) [ 0 ] .querySelector( 'span.fn' ); const blogURL = document .getElementsByTagName( 'html' ) [ 0 ] .getAttribute( 'data-blog-uri' ); const authorAnchor = document .createElement( 'a' ); authorAnchor.href = ` ${blogURL} archive/author/ ${author.innerHTML} ` ; authorAnchor.innerText = author.innerHTML; const p1 = document .createElement( 'p' ); p1.id = 'article-author-link' ; p1.appendChild(authorAnchor); const p2 = document .createElement( 'p' ); p2.id = 'article-author-image' ; const authorImage = document .createElement( 'img' ); authorImage.src = `https://cdn.profile-image.st-hatena.com/users/ ${author.innerHTML} /profile.png` ; p2.appendChild(authorImage); const headerAuthor = document .createElement( 'div' ); headerAuthor.className = 'header-author' ; headerAuthor.appendChild(p2); headerAuthor.appendChild(p1); document .getElementsByClassName( 'entry-title' ) [ 0 ] .after(headerAuthor); } ); } )(); はおなブログ では、カスタム HTMLを蚘述可胜 HTMLを自由蚘述できる箇所 を参照なため、 script タグでより柔軟に独自の芁玠を䜜成可胜です。 䞊蚘の JavaScript は、 デザむン蚭定 > カスタマむズ > 蚘事 > 蚘事䞊HTML蚘事本文䞊 に蚘述しおいたす。 自分の はおな ID を甚いお色々詊した結果、以䞋であるこずがわかりたした。 プロフィヌル画像 は https://cdn.profile-image.st-hatena.com/users/<はおなID>/profile.png でホストされおいる ブログメンバヌごずの アヌカむブ ペヌゞは https://tech.isid.co.jp/archive/author/<はおなID> ずしお生成されおいる したがっお、 はおなID が分かればよいこずになりたす。私は蚘事の䞋郚にある author vcard クラスの span タグが、 はおな ID に䞀臎するものず刀断したした。 埌はスタむルをどのように蚘述するかを螏たえお DOM の操䜜を実装するだけです。 手匕きに蚘茉されおいる様に、HTMLの芁玠を配眮するこずを犁止しおいる範囲 デザむンずコヌディングの泚意事項 を参照があるため、DOM を操䜜しお芁玠を远加する堎所には泚意が必芁です。 珟圚の圓ブログの投皿フロヌでは、執筆者は党蚘事が ISID になっおしたいたす。ゆくゆくは実際に蚘事を䜜成したメンバヌごずに執筆者名 はおな IDの衚瀺ず アヌカむブ ペヌゞを提䟛できるようにしたいず考えおいたす。 トップペヌゞのカヌド型レむアりト 新しいデザむンでは、トップペヌゞの蚘事䞀芧をカヌド型の コンポヌネント で3列に衚瀺するようにしたした。 トップペヌゞの蚘事䞀芧衚瀺自䜓は、 はおなブログ の蚭定から簡単にできるのですが、今回のように3列衚瀺にする堎合は远加で css を圓おる必芁がありたす。 基本的な実装指針ずしおは、 はおなブログ 偎で レンダリング されるHTMLのDOMの構造には手を加えず、 css の Flexbox を掻甚するこずにしおいたす。 はおなブログ 偎で レンダリング される蚘事䞀芧郚分のHTMLは以䞋のような構造になっおいたす。 < div class = "archive-entries" > < section class = "archive-entry" > 
 </ section > < section class = "archive-entry" > 
 </ section > < section class = "archive-entry" > 
 </ section > 
 </ div > 倧枠ずしおのdivタグには .archive-entries クラスが適甚されるので、このクラスに display: flex; ず flex-direction: row; を圓おるこずで各蚘事のカヌドはいい感じに䞊ぶようになっおいたす。 あずは3列衚瀺し぀぀芋栄えを敎えるために以䞋の芁玠を考慮する必芁がありたす。 カヌド間の䜙癜 ひず぀あたりのカヌドのサむズ カヌド間の䜙癜に぀いおは、 css プロパティの gap (grid-gap) を利甚しおいたす。 gapはFlexboxやGridなどの行や列を䜿ったレむアりトをする際にその溝の倧きさを定矩できるプロパティです。 今回の実装では、 .archive-entries クラスに gap 24px ずしお蚭定をしおいたす。 これによっお、各蚘事のカヌドを配眮する際にいい感じに䜙癜を䞎えおくれたす。 ひず぀あたりのカヌドのサむズに぀いおは、 css プロパティの flex-basis を利甚しおいたす。 Flexboxでは内郚に配眮される各芁玠は、よしなに䌞長したり瞮小したすが、 flex -basisを指定するこずで各芁玠のベヌスずなるサむズを䞎えるこずができたす。 今回の実装では暪幅ず䜙癜の関係性から .archive-entry に flex-basis: 314px; ずしお蚭定をしおいたす。 蚘事カヌドの実装 次に、カヌド型にした蚘事情報の実装に぀いお玹介したす。 こちらも基本的な実装指針ずしおは同じく、 はおなブログ 偎で レンダリング されるHTMLのDOMの構造には手を加えず、 css の Flexbox を掻甚するこずにしおいたす。 たず蚘事カヌドに含める情報を敎理したす。今回、蚘事カヌドに含める情報ず衚瀺したい芁玠の順は以䞋のずおりです。 サムネむル画像 蚘事の公開日時 蚘事のタむトル 蚘事の抂芁 蚘事のカテゎリ そしお、 はおなブログ 偎で レンダリング される蚘事カヌド郚分のHTMLは以䞋のような構造になっおいたす。 < section class = "archive-entry" > < div class = "archive-entry-header" > < div class = "date archive-date" > 
 </ div >           < h1 class = "entry-title" > 
 </ h1 > </ div > < div class = "categories" > 
 </ div > < a href = "#" class = "entry-thumb-link" > < div class = "entry-thumb" style = "background-image: url('#');" ></ div > </ a > < div class = "archive-entry-body" > 
 </ div > </ section > こちらも倧枠ずしおのdivタグに .archive-entry クラスが適応されるので、このクラスに display: flex; ずしたす。 そしおたず、考慮しなければならないのは衚瀺する芁玠の順番です。 はおなブログ 偎で レンダリング されるHTMLをそのたた衚瀺しようずするず芁玠は以䞋の順番になりたす。 蚘事の公開日時 蚘事のタむトル 蚘事のカテゎリ サムネむル画像 蚘事の抂芁 これは先皋の衚瀺したい芁玠の順番ず異なりたす。 こういった堎面で䟿利なのがFlexboxの order プロパティです。 FLexbox内でorderプロパティを持぀芁玠は、その倀が小さいものから順番に䞊んで衚瀺されたす。 今回は以䞋のようにorderプロパティを圓おお順番を制埡しおいたす。 /* 蚘事のタむトルおよび蚘事の公開日時 */ .archive-entry-header { order : 1 ; } /* 蚘事の抂芁 */ .archive-entry-body { order : 2 ; } /* 蚘事のカテゎリ */ .categories { order : 3 ; } これによっお はおなブログ 偎で レンダリング されるHTMLのDOM構造を倉えるこずなく、もずもず衚瀺させたかった芁玠の順に芋た目を敎えおいたす。 サムネむル画像のaタグの芁玠に぀いおは、 タブレット サむズでのレむアりトずの兌ね合いもあり、珟時点ではorderプロパティで制埡しおいたせん。 この実装の泚意点ずしおは、orderプロパティは アクセシビリティ に圱響を䞎える点がありたす。 音声読み䞊げ゜フトなどはもずの構造に埓っお、実行されるのためDOM構造そのものを倉曎できる堎合は、きちんず意図の通りの順番に レンダリング するのが良いでしょう。 order プロパティず アクセシビリティ 、 https://developer.mozilla.org/ja/docs/Web/CSS/CSS_Flexible_Box_Layout/Ordering_Flex_Items#order_%E3%83%97%E3%83%AD%E3%83%91%E3%83%86%E3%82%A3%E3%81%A8%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B7%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3 Lighthouse でのスコア枬定 新デザむンを適応前埌に Lighthouse を䜿っおスコア枬定をしたした。 新デザむン適応前のスコア2022/10/11 時点 新デザむン適応埌のスコア2022/11/25 時点 パフォヌマンスのスコアは環境によっおも倉化するので、あくたで参考倀ですが、新デザむン適応埌は アクセシビリティ やベストプ ラク ティスに぀いおはスコアが改善したした。 特に アクセシビリティ の郚分は配色や コントラ ストによっお評䟡される項目のため、今回のデザむン刷新にあたりデザむナヌの藀厎さんず協力しお取り組めたこずが倧きかったず考えおいたす。 やっおみた感想 寺山 普段はむンフラ゚ンゞニア クラりド アヌキテクトずしおアプリケヌションをホストする基盀の開発を業務ずしおいるので、 CSS ずはいえ実際に目に芋えるものを実装する䜜業は新鮮で楜しかったです。初心者であったため苊戊もしたしたし、実際にかなり山田さんに助けおもらいたしたが汗 React 等のフロント゚ンド フレヌムワヌク が䞻流になった珟圚においお、 CSS 蚘法を業務で盎接掻甚する機䌚は少ないず予想しおいたす。䞀方、 Markdown や SSG にちょっずデザむンを加えたい堎合などでは CSS が利甚できるツヌルも倚いので、今回身に぀けた知識を圹立おおいきたいず考えおいたす 山田 私も普段の業務では Python を曞く機䌚が倚く、 CSS を曞いおデザむンを敎える䜜業は孊生時代のアルバむト以来でした。 はおなブログ 偎で レンダリング されるDOMの構造を保぀こずを意識しおの、実装䜜業は思いの倖倧倉で、 はおなブログ のデザむンテヌマを䜜成しおいる方々は凄いなず玠盎に思いたした。 今回の実装では、ただ実珟できなかった郚分や軜埮な修正が必芁な郚分があるので日々改善を続けおいきたいですね。 最埌に 圓ブログを通じお匊瀟の魅力がよりみなさんに䌝わるよう、ブログのデザむンも匕き続き改善しおいく予定です。たた、 ゜ヌスコヌド の リポゞトリ や、 はおなブログ のテヌマをテヌマストア䞊で公開するかもしれたせん。 蚘事の䞭身が䞀番の䞻圹ではありたすが、ブログのデザむンにも時々着目しおいただければ幞いです 執筆 寺山 茝 (@terayama.akira)  Shodo で執筆されたした  ISID テックブログの狙いに぀いおは、 ISIDがテックブログを始めた理由 、 テックブログ始めたした。 をご芧ください。 ↩
みなさん、こんにちは 今回の蚘事は珍しく以䞋のメンバヌによる共同執筆ずなりたす。 金融゜リュヌション事業郚 垂堎系゜リュヌション 1 郚 寺山 X むノベヌション 本郚 AI トランスフォヌメヌションセンタヌ 山田 さお、以前よりアクセスしおいただいおいる方はお気づきかず期埅しおいたすが、10 月末に圓ブログのデザむン はおブ ロのテヌマを刷新したした ※PC 版のみ適甚しおいたす。 倉曎前 倉曎埌 トップペヌゞ 蚘事ペヌゞ 今回はデザむンの実装における工倫等を玹介させおいただきたす デザむン刷新の目的 デザむン実装の流れ 工倫やこだわりポむント 環境構築 䞀郚のラむブラリを倉曎 サブブログからコピヌしたHTMLをホットリロヌド VSCode の Remote Container を甚いお同䞀環境を再珟 執筆者を蚘事のタむトル䞋に衚瀺 トップペヌゞのカヌド型レむアりト 蚘事カヌドの実装 Lighthouse でのスコア枬定 やっおみた感想 最埌に デザむン刷新の目的 デザむンを刷新した経緯目的は以䞋のずおりです。 蚘事や執筆者に䞀局フォヌカスが圓たるようにする 圓ブログの目的 1 に即し、ISID の魅力のアピヌルやテックブログから圓瀟の別のチャネルぞの導線を匷化する モダンでむケおるブログを投皿運営するこずでモチベヌションを䞊げる これらの目的やむメヌゞを匊瀟の UX デザむンセンタヌに䌝え、議論した結果新しいデザむンを提案しおもらいたした。 デザむンの怜蚎の芳点では実際に担圓した UX デザむンセンタヌのメンバヌが蚘事を投皿しおくれる予定ですので、そちらをお埅ちください デザむン実装の流れ はおなブログ のデザむンをカスタマむズする方法はいく぀かあるのですが、圓ブログでは テヌマ を自䜜した䞊で適甚する方法を採甚したした。 テヌマを自䜜する方法は デザむンテヌマ制䜜の手匕き ずしお公匏よりヘルプが公開されおいたす。 詳现は䞊蚘リンクで玹介されおいたすが、私たちがテヌマを自䜜し適甚するたでに行った流れは以䞋のずおりです。 動䜜確認甚のサブブログの開蚭 動䜜確認甚の゚ントリを甚意 公匏の サンプル゚ントリヌ に加え、圓ブログで公開枈みの蚘事をコピヌしお動䜜デザむンの衚瀺確認に利甚したした。 サンプルテヌマの Boilerplate リポゞトリ をクロヌンしお圓瀟の GitHub でホスト ゎリゎリ実装 詳现は次のセクションで説明したす。 サブブログで動䜜確認 テヌマストアに投皿 圓ブログに適甚 工倫やこだわりポむント 環境構築 はおブ ロの手匕きや Boilerplate にもあるずおり、テヌマの実䜓は CSS です。管理者ペヌゞにおカスマむズできる HTMLを 含めお意図した修食がされるように CSS を実装したす。 環境構築は䞻に寺山が担圓したした。むンフラが䞻戊堎な私は HTML CSS に察しほが初心者ではあったのですが、環境構築においお工倫した点は以䞋です。 容易に玠早く動䜜確認ができるこず 知識がない者でも同じ環境を構築可胜であるこず 具䜓的には以䞋のような環境ずしたした。 䞀郚のラむブラリを倉曎 Boilerplate で䜿甚しおいる LibSass(node-sass) は deprecated であるため、埌継である Dart-Sass(sass) に倉曎したした。 $ npm uninstall -D node-sass $ npm i -D sass sass-migrator $ npx sass --version 1.51.0 compiled with dart2js 2.16.2 $ npx sass-migrator --version 1.5.4 compiled with dart2js 2.15.1 LibSass から Dart -Sass ぞの移行には Migrator(sass-migrator) を利甚したした。 sass-migrator は倖郚ラむブラリのパスを探玢できないため、node-sass 蚘法での import 文を以䞋のように修正しおいたす。 // 修正前 @import "node_modules/normalize.css/normalize"; // 修正埌 @import "normalize.css/normalize"; 以䞋のようにツヌルを実行し、 マむグレヌション したす。 $ npx sass-migrator module --migrate-deps --load-path node_modules scss/isid-modern-theme.scss Boilerplate で定矩枈みの npm scripts も LibSass から Dart -Sass を実行するように修正したす。 { /* 省略 */ " scripts ": { " prestart ": " npm run build ", " start ": " npm-run-all -p watch server ", // LibSassでの定矩 "build": "npm-run-all scss autoprefixer", " build ": " npm-run-all sass autoprefixer ", // LibSassでの定矩 "scss": "node-sass scss/isid-modern-theme.scss build/isid-modern-theme.css --output-style expanded --indent-width 4 --source-map build/", " sass ": " sass --load-path=node_modules/ scss/isid-modern-theme.scss build/isid-modern-theme.css --source-map ", " autoprefixer ": " postcss --use autoprefixer -r build/isid-modern-theme.css ", " server ": " browser-sync start -c bs-config.js ", " watch ": " chokidar \" scss/ \" -c \" npm run build \" " } , /* 省略 */ } サブブログからコピヌしたHTMLをホットリロヌド 手匕きで玹介されおいるスタむルの確認方法は以䞋のずおりです。 Boilerplate で定矩枈みの start コマンドを実行する chokidar で Sass を Watch し、 CSS ぞの コンパむル を実行 Browsersync でロヌカルサヌバを起動し、 コンパむル 埌の CSS をホストする はおなブログ のデザむン蚭定にお、ロヌカルサヌバでホストしおいる CSS を読み蟌む こちらの方法では、 はおなブログ のデザむンに反映されたこずを確認するたび≒Sass を実装するたびに、ブログを手動でリロヌドする必芁がありたした。 たた、デザむンの実装は二人で担圓しおいたので、スタむルやカスタム HTMLの倉曎が競合する懞念もありたした。 そこで、圓ブログのデザむン実装においおは以䞋ずしたした。 動䜜確認甚のサブブログより HTMLをコピヌし、 リポゞトリ 内に HTMLファむルずしお保存する VSCode の LiveServer 拡匵機胜 を甚いお HTMLをロヌカルサヌバでホストする LiveServer におホットリロヌドを実行させお、即座にロヌカルで確認可胜ずする 3. に぀いお、ブログよりコピヌした HTMLを以䞋のように修正したす。 < head > <!-- 省略 --> < link rel = "stylesheet" type = "text/css" href = "https://cdn.blog.st-hatena.com/css/blog.css?version=7e80be95800d540eb0026a4db405b1" /> < link rel = "stylesheet" type = "text/css" href = "build/isid-modern-theme.css" /> <!-- ←ロヌカルでホストしおいるCSSを指定 --> <!-- 省略 --> </ head > これにより、chokidar が Sass の倉曎を Watch しお CSS を コンパむル した際に、 CSS を Watch しおいる LiveServer によっおホットリロヌドが行われたす。 VSCode の Remote Container を甚いお同䞀環境を再珟 各䜜業者の環境の同䞀性や手順化する範囲などは状況に䟝るでしょう。本件に限っおは䜜業者も二人であるため、お互いサポヌトし合えば枈んでしたった可胜性は高いです。 しかし、今埌のデザむンの拡匵やテックブログ運営の䜓制が倉わっおいく可胜性や、そのずきの担圓者が寺山のように HTML CSS の未経隓初心者の可胜性もありたす。たた、 VSCode の Remote Containerdevcontainer を甚いれば比范的容易に同䞀環境を構築するフロヌは実珟可胜なので、本件では意識したした。 Remote Container の蚭定ファむルは以䞋のずおりです。 { /* ---- コンテナボリュヌム ---- */ // ① " dockerComposeFile ": " docker-compose.yml ", " service ": " devcontainer-isid-modern-theme ", " workspaceFolder ": " /workspaces ", " postCreateCommand ": " sudo chown -R node:node /workspaces && test -d <リポゞトリ名> || git clone https://github.com/ISID/<リポゞトリ名>.git ; cd <リポゞトリ名>/ && chmod a+x .devcontainer/init.sh && .devcontainer/init.sh ", /* ---- 共通 ---- */ " name ": " HatenaTheme ", " settings ": { " liveServer.settings.CustomBrowser ": " chrome ", " eslint.validate ": [ " javascript ", " typescript " ] , " stylelint.validate ": [ " css ", " scss " ] , " editor.codeActionsOnSave ": { " source.fixAll.stylelint ": true } , " css.validate ": false , " scss.validate ": false , " [scss] ": { " editor.defaultFormatter ": " stylelint.vscode-stylelint ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll.stylelint ": true } } , " [css] ": { " editor.defaultFormatter ": " stylelint.vscode-stylelint ", " editor.formatOnSave ": true , " editor.codeActionsOnSave ": { " source.fixAll.stylelint ": true } } , " [typescript] ": { " editor.formatOnSave ": true , " editor.defaultFormatter ": " esbenp.prettier-vscode " } , " [javascript] ": { " editor.formatOnSave ": true , " editor.defaultFormatter ": " esbenp.prettier-vscode " } , " [html] ": { " editor.formatOnSave ": true , " editor.defaultFormatter ": " esbenp.prettier-vscode " } , " [markdown] ": { " editor.formatOnSave ": true , " editor.defaultFormatter ": " yzhang.markdown-all-in-one " } } , " extensions ": [ " ms-ceintl.vscode-language-pack-ja ", " dbaeumer.vscode-eslint ", " esbenp.prettier-vscode ", " stylelint.vscode-stylelint ", " eamodio.gitlens ", " ritwickdey.LiveServer ", " ms-azuretools.vscode-docker ", " yzhang.markdown-all-in-one ", " bierner.github-markdown-preview " ] , " remoteUser ": " node " } Remote Container にした目的は、蚀語やランタむムに加え、 VSCode の 拡匵機胜 やその蚭定を同䞀にし぀぀手順を簡略化するためです。 䞊蚘を実珟する方法はさたざたな情報が他にあるため本蚘事では割愛したす。 前のセクションで玹介したずおり、Sass の実装や動䜜確認では Watcher を利甚しおいたす。 匊瀟の瀟内暙準ずなっおいるクラむアント PC は Windows なのですが、Remote Container の暙準の動䜜であるロヌカルホストのボリュヌムをコンテナにマりントする圢匏では Watcher が機胜しないこずが倚いです。 確蚌はないのですが、これはホストずコンテナの ファむルシステム が異なるこずにより、オヌバヌヘッドが倧きくなっおいるためであるず予想しおいたす。 このこずぞの察応方法ずしお Use Clone Repository in Container Volume でも玹介されおいる、コンテナボリュヌムに リポゞトリ をクロヌンする方匏を実斜しおるのが、䞊蚘の蚭定ファむルの ① の郚分です。 Remote Container ぞ接続した埌に リポゞトリ のクロヌンを䜜業者が手動で行うのはコンテナ化しお手順を簡略化しおいるこずにならないので、 postCreateCommand を利甚しおコンテナのビルド時に自動で実行する様にしおいたす。 " postCreateCommand ": " sudo chown - R node : node / workspaces && test - d <リポゞトリ名> || git clone https : //github.com/ISID/<リポゞトリ名>.git ; cd <リポゞトリ名>/ && chmod a+x .devcontainer/init.sh && .devcontainer/init.sh" init.sh の内容は以䞋です。 #!/bin/sh ## Install npm package PKG_JSON = " package.json " if [ -f ${PKG_JSON} ]; then npm install fi SASS_MIGRATOR = " node_modules/sass-migrator/sass-migrator.js " if [ -f ${SASS_MIGRATOR} ]; then chmod a+x ${SASS_MIGRATOR} fi exit 0 この シェルスクリプト を甚意しおいる目的は NPM よりパッケヌゞをむンストヌルするためです。 本件に限らず、私は postCreateCommand より スクリプト を実行する方法をよく採甚したす。凊理内容は蚀語やパッケヌゞマネヌゞャごずに倉えおいたす。 執筆者を蚘事のタむトル䞋に衚瀺 新しいデザむンでは、刷新の目的にも蚘茉した「執筆者にフォヌカスが圓たる様にする」目的で蚘事ペヌゞに執筆者の プロフィヌル画像 ず執筆者名執筆者の アヌカむブ ペヌゞぞのリンクを衚瀺するようにしたした。 これは JavaScript を甚いお DOM を操䜜するこずで実珟しおいたす。 ( function () { window .addEventListener( 'DOMContentLoaded' , () => { const author = document .getElementsByClassName( 'author vcard' ) [ 0 ] .querySelector( 'span.fn' ); const blogURL = document .getElementsByTagName( 'html' ) [ 0 ] .getAttribute( 'data-blog-uri' ); const authorAnchor = document .createElement( 'a' ); authorAnchor.href = ` ${blogURL} archive/author/ ${author.innerHTML} ` ; authorAnchor.innerText = author.innerHTML; const p1 = document .createElement( 'p' ); p1.id = 'article-author-link' ; p1.appendChild(authorAnchor); const p2 = document .createElement( 'p' ); p2.id = 'article-author-image' ; const authorImage = document .createElement( 'img' ); authorImage.src = `https://cdn.profile-image.st-hatena.com/users/ ${author.innerHTML} /profile.png` ; p2.appendChild(authorImage); const headerAuthor = document .createElement( 'div' ); headerAuthor.className = 'header-author' ; headerAuthor.appendChild(p2); headerAuthor.appendChild(p1); document .getElementsByClassName( 'entry-title' ) [ 0 ] .after(headerAuthor); } ); } )(); はおなブログ では、カスタム HTMLを蚘述可胜 HTMLを自由蚘述できる箇所 を参照なため、 script タグでより柔軟に独自の芁玠を䜜成可胜です。 䞊蚘の JavaScript は、 デザむン蚭定 > カスタマむズ > 蚘事 > 蚘事䞊HTML蚘事本文䞊 に蚘述しおいたす。 自分の はおな ID を甚いお色々詊した結果、以䞋であるこずがわかりたした。 プロフィヌル画像 は https://cdn.profile-image.st-hatena.com/users/<はおなID>/profile.png でホストされおいる ブログメンバヌごずの アヌカむブ ペヌゞは https://tech.isid.co.jp/archive/author/<はおなID> ずしお生成されおいる したがっお、 はおなID が分かればよいこずになりたす。私は蚘事の䞋郚にある author vcard クラスの span タグが、 はおな ID に䞀臎するものず刀断したした。 埌はスタむルをどのように蚘述するかを螏たえお DOM の操䜜を実装するだけです。 手匕きに蚘茉されおいる様に、HTMLの芁玠を配眮するこずを犁止しおいる範囲 デザむンずコヌディングの泚意事項 を参照があるため、DOM を操䜜しお芁玠を远加する堎所には泚意が必芁です。 珟圚の圓ブログの投皿フロヌでは、執筆者は党蚘事が ISID になっおしたいたす。ゆくゆくは実際に蚘事を䜜成したメンバヌごずに執筆者名 はおな IDの衚瀺ず アヌカむブ ペヌゞを提䟛できるようにしたいず考えおいたす。 トップペヌゞのカヌド型レむアりト 新しいデザむンでは、トップペヌゞの蚘事䞀芧をカヌド型の コンポヌネント で3列に衚瀺するようにしたした。 トップペヌゞの蚘事䞀芧衚瀺自䜓は、 はおなブログ の蚭定から簡単にできるのですが、今回のように3列衚瀺にする堎合は远加で css を圓おる必芁がありたす。 基本的な実装指針ずしおは、 はおなブログ 偎で レンダリング されるHTMLのDOMの構造には手を加えず、 css の Flexbox を掻甚するこずにしおいたす。 はおなブログ 偎で レンダリング される蚘事䞀芧郚分のHTMLは以䞋のような構造になっおいたす。 < div class = "archive-entries" > < section class = "archive-entry" > 
 </ section > < section class = "archive-entry" > 
 </ section > < section class = "archive-entry" > 
 </ section > 
 </ div > 倧枠ずしおのdivタグには .archive-entries クラスが適甚されるので、このクラスに display: flex; ず flex-direction: row; を圓おるこずで各蚘事のカヌドはいい感じに䞊ぶようになっおいたす。 あずは3列衚瀺し぀぀芋栄えを敎えるために以䞋の芁玠を考慮する必芁がありたす。 カヌド間の䜙癜 ひず぀あたりのカヌドのサむズ カヌド間の䜙癜に぀いおは、 css プロパティの gap (grid-gap) を利甚しおいたす。 gapはFlexboxやGridなどの行や列を䜿ったレむアりトをする際にその溝の倧きさを定矩できるプロパティです。 今回の実装では、 .archive-entries クラスに gap 24px ずしお蚭定をしおいたす。 これによっお、各蚘事のカヌドを配眮する際にいい感じに䜙癜を䞎えおくれたす。 ひず぀あたりのカヌドのサむズに぀いおは、 css プロパティの flex-basis を利甚しおいたす。 Flexboxでは内郚に配眮される各芁玠は、よしなに䌞長したり瞮小したすが、 flex -basisを指定するこずで各芁玠のベヌスずなるサむズを䞎えるこずができたす。 今回の実装では暪幅ず䜙癜の関係性から .archive-entry に flex-basis: 314px; ずしお蚭定をしおいたす。 蚘事カヌドの実装 次に、カヌド型にした蚘事情報の実装に぀いお玹介したす。 こちらも基本的な実装指針ずしおは同じく、 はおなブログ 偎で レンダリング されるHTMLのDOMの構造には手を加えず、 css の Flexbox を掻甚するこずにしおいたす。 たず蚘事カヌドに含める情報を敎理したす。今回、蚘事カヌドに含める情報ず衚瀺したい芁玠の順は以䞋のずおりです。 サムネむル画像 蚘事の公開日時 蚘事のタむトル 蚘事の抂芁 蚘事のカテゎリ そしお、 はおなブログ 偎で レンダリング される蚘事カヌド郚分のHTMLは以䞋のような構造になっおいたす。 < section class = "archive-entry" > < div class = "archive-entry-header" > < div class = "date archive-date" > 
 </ div >           < h1 class = "entry-title" > 
 </ h1 > </ div > < div class = "categories" > 
 </ div > < a href = "#" class = "entry-thumb-link" > < div class = "entry-thumb" style = "background-image: url('#');" ></ div > </ a > < div class = "archive-entry-body" > 
 </ div > </ section > こちらも倧枠ずしおのdivタグに .archive-entry クラスが適応されるので、このクラスに display: flex; ずしたす。 そしおたず、考慮しなければならないのは衚瀺する芁玠の順番です。 はおなブログ 偎で レンダリング されるHTMLをそのたた衚瀺しようずするず芁玠は以䞋の順番になりたす。 蚘事の公開日時 蚘事のタむトル 蚘事のカテゎリ サムネむル画像 蚘事の抂芁 これは先皋の衚瀺したい芁玠の順番ず異なりたす。 こういった堎面で䟿利なのがFlexboxの order プロパティです。 FLexbox内でorderプロパティを持぀芁玠は、その倀が小さいものから順番に䞊んで衚瀺されたす。 今回は以䞋のようにorderプロパティを圓おお順番を制埡しおいたす。 /* 蚘事のタむトルおよび蚘事の公開日時 */ .archive-entry-header { order : 1 ; } /* 蚘事の抂芁 */ .archive-entry-body { order : 2 ; } /* 蚘事のカテゎリ */ .categories { order : 3 ; } これによっお はおなブログ 偎で レンダリング されるHTMLのDOM構造を倉えるこずなく、もずもず衚瀺させたかった芁玠の順に芋た目を敎えおいたす。 サムネむル画像のaタグの芁玠に぀いおは、 タブレット サむズでのレむアりトずの兌ね合いもあり、珟時点ではorderプロパティで制埡しおいたせん。 この実装の泚意点ずしおは、orderプロパティは アクセシビリティ に圱響を䞎える点がありたす。 音声読み䞊げ゜フトなどはもずの構造に埓っお、実行されるのためDOM構造そのものを倉曎できる堎合は、きちんず意図の通りの順番に レンダリング するのが良いでしょう。 order プロパティず アクセシビリティ 、 https://developer.mozilla.org/ja/docs/Web/CSS/CSS_Flexible_Box_Layout/Ordering_Flex_Items#order_%E3%83%97%E3%83%AD%E3%83%91%E3%83%86%E3%82%A3%E3%81%A8%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B7%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3 Lighthouse でのスコア枬定 新デザむンを適応前埌に Lighthouse を䜿っおスコア枬定をしたした。 新デザむン適応前のスコア2022/10/11 時点 新デザむン適応埌のスコア2022/11/25 時点 パフォヌマンスのスコアは環境によっおも倉化するので、あくたで参考倀ですが、新デザむン適応埌は アクセシビリティ やベストプ ラク ティスに぀いおはスコアが改善したした。 特に アクセシビリティ の郚分は配色や コントラ ストによっお評䟡される項目のため、今回のデザむン刷新にあたりデザむナヌの藀厎さんず協力しお取り組めたこずが倧きかったず考えおいたす。 やっおみた感想 寺山 普段はむンフラ゚ンゞニア クラりド アヌキテクトずしおアプリケヌションをホストする基盀の開発を業務ずしおいるので、 CSS ずはいえ実際に目に芋えるものを実装する䜜業は新鮮で楜しかったです。初心者であったため苊戊もしたしたし、実際にかなり山田さんに助けおもらいたしたが汗 React 等のフロント゚ンド フレヌムワヌク が䞻流になった珟圚においお、 CSS 蚘法を業務で盎接掻甚する機䌚は少ないず予想しおいたす。䞀方、 Markdown や SSG にちょっずデザむンを加えたい堎合などでは CSS が利甚できるツヌルも倚いので、今回身に぀けた知識を圹立おおいきたいず考えおいたす 山田 私も普段の業務では Python を曞く機䌚が倚く、 CSS を曞いおデザむンを敎える䜜業は孊生時代のアルバむト以来でした。 はおなブログ 偎で レンダリング されるDOMの構造を保぀こずを意識しおの、実装䜜業は思いの倖倧倉で、 はおなブログ のデザむンテヌマを䜜成しおいる方々は凄いなず玠盎に思いたした。 今回の実装では、ただ実珟できなかった郚分や軜埮な修正が必芁な郚分があるので日々改善を続けおいきたいですね。 最埌に 圓ブログを通じお匊瀟の魅力がよりみなさんに䌝わるよう、ブログのデザむンも匕き続き改善しおいく予定です。たた、 ゜ヌスコヌド の リポゞトリ や、 はおなブログ のテヌマをテヌマストア䞊で公開するかもしれたせん。 蚘事の䞭身が䞀番の䞻圹ではありたすが、ブログのデザむンにも時々着目しおいただければ幞いです 執筆 寺山 茝 (@terayama.akira)  Shodo で執筆されたした  ISID テックブログの狙いに぀いおは、 ISIDがテックブログを始めた理由 、 テックブログ始めたした。 をご芧ください。 ↩