電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 これまで、人物用の呪文が多かったのですが、それ以外のテーマでも面白いものがたくさんあります。 Stable Diffusionの呪文シリーズ、今回のテーマは東京タワーの写真です。 建物の場合、より建物が具体的な方が、良いものに仕上がる可能性が高いです。 バベルの塔のイラスト編 と同様に、具体的に東京タワーを選んでみました。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 TPU版の使い方 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 illuminated tokyo tower shot from below SIGMA 85 mm F1.4 illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 まとめ 仲間募集 Stable Diffusionの全コンテンツ illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 通常呪文は、画像タイプ of 描画対象で始めるのが定番です。例えばphoto of dogの用な感じです。今回は、 SIGMA というレンズを表す呪文を指定しているので、photo ofはなくても写真になります。 illuminatedで描画対象に照明を当てます。illuminatedなしも何度も試してみましたが、東京タワーはilluminatedありのほうが断然良いです。 highly detailedで描画対象を詳細に描画します。 shot from aboveで上から描画します。 バベルの塔編 で、説明したように、人は見たことのないアングルの写真に惹かれます。東京タワーをさらに上の方からとった写真って普通見たことないじゃないですか。だから、東京タワーに対する shot from above は効果的なのです。 もう一つ、 バベルの塔 編と違うのは、東京タワーを上から撮ると、周りのビルの美しい灯りが見えることです。これもかなり効果的です。 SIGMA 85 mm F1.4は、使いやすい望遠レンズです。詳しく知りたい方は、 レンズ編 を御覧ください。 今回の呪文（横長、コピー&ペースト用） illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 閲覧用呪文（改行版） illuminated tokyo tower highly detailed shot from above SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 画像出力結果 東京タワーを上から描画すると、夜のビル群が見えてきれいですね。 illuminated tokyo tower shot from below SIGMA 85 mm F1.4 今回は、shot from belowで下から描画します。highly detailedがないことに注目してください。塔を下から描画するときに、highly detailedをつけると、塔に近寄りすぎてしまい、うまく描画するのが難しくなります。 今回の呪文（横長、コピー&ペースト用） illuminated tokyo tower shot from below SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 閲覧用呪文（改行版） illuminated tokyo tower shot from below SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 画像出力結果 空が寂しいですね。 highly detailed版 東京タワーに近寄り過ぎに感じますが、大迫力の構図です。 illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 空が寂しいので、星を出しましょう。 cosmos（宇宙）、stars（星）、nebula（星雲）を追加します。 今回の呪文（横長、コピー&ペースト用） illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 閲覧用呪文（改行版） illuminated tokyo tower shot from below cosmos stars nebula SIGMA 85 mm F1.4 award winning cinematic scene cinematic composition cinematic lighting 画像出力結果 美しい星空ですね。 まとめ 今回は、東京タワーの写真を取り上げました。 shot from above 、 shot from below ぜひ、覚えてください。 次回は、 折り紙合体変形ロボ です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト 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 イノベーション 本部ソフトウェアデザインセンターの陳です。 この記事では Next.js + TypeScript + Docker + GitHub Actionsの環境構築の方法をまとめます。 セットアップ手順 以下のセットアップを行います。 1. create-next-appでNext.jsのプロジェクトを作成 2. 静的分析ツールESLintの設定 3. コードフォーマッターPrettierの設定 4. テスト フレームワーク のJest、React Testing Libraryの設定 5. Dockerfileの作成 6. GitHub Actionsを利用したビルド、テストの自動実行 バージョン Next.js v12.3.0 TypeScript v4.8.3 create-next-appでNext.jsのプロジェクトを作成 create-next-app はNext.jsプロジェクトを自動生成するためのコマンドです。 create-next-app を利用すると、Next.js + TypeScriptのプロジェクトのひな形を簡単に作成できます。公式ドキュメントは こちら です。 create-next-appを実行する 以下のコマンドを実行し、プロジェクトを自動生成します。 $ npx create-next-app ｛プロジェクト名｝　--ts yarnを利用することもできます。 $ yarn create next-app ｛プロジェクト名｝ --typescript --ts また --typescript を指定することで、TypeScriptを利用するプロジェクトが生成されます。TypeScriptの設定ファイル tsconfig.json も自動的に作成されます。 プロジェクトを動かしてみる 作成されたプロジェクトの ディレクト リで以下のコマンドを実行すると、Next.jsプロジェクトを開発モードで起動できます。 $ yarn dev localhost:3000 にアクセスするとこちらの画面が表示されます。これでプロジェクトのひな形の作成が完了しました。 静的分析ツールESLintの設定 ESLintを実行する Next.js v11.0.0から create-next-app でプロジェクトを作成すると、ESLintは自動的にインストールされます。 package.json の Scripts に "lint": "next lint" がデフォルトで設定されています。以下のコマンドでESLintを実行できます。 $ yarn lint ESLintのデフォルト構成 Next.jsのESLintのデフォルト構成では、 eslint-config-next の構成が自動的に設定されます。以下のルールセットが eslint-config-next に含まれるため、インストール、設定する必要はありません。公式ドキュメントは こちら です。 eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-next ESLintの構成をカスタマイズする .eslintrc.json を編集することで、構成をカスタマイズできます。 .eslintrc.json はESLintに関する設定ファイルです。 以下のように extends に記述すれば、 eslint:recommended など、他の構成を利用できます。また rules でルールの変更や無効化の設定もできます。 //.eslintrc.json { "extends": [ "eslint:recommended", "next/core-web-vitals", ], "rules":{ // 個別のルールを変更、無効にする場合はこちらに追加する "no-console": ["warn", { allow: ["warn", "error"] }], "sort-imports": "off", "import/order": ["error", { alphabetize: { order: "asc" } }], "import/no-named-as-default-member": "off", } コードフォーマッターPrettierの設定 Prettierをインストールする 以下のコマンドでPrettier本体、ESLintと併用する際に必要なライブラリーをインストールします。 $ yarn add -D prettier eslint-config-prettier .eslintrc. json を編集する .eslintrc.json を以下のように設定することで、ESLint と Prettier のコード整形が競合しないようになります。 //.eslintrc.json { "extends": ["next/core-web-vitals", "prettier"], } .prettierrcを作成する コード整形に関する設定をカスタマイズするには、ルート ディレクト リで .prettierrc を作成します。 以下のようにカスタマイズ設定ができます。設定の詳細は 公式ドキュメント を参照してください。 //.prettierrc { "tabWidth": 2, "printWidth": 120, "trailingComma": "es5", "semi": false, "singleQuote": true } Prettierを実行する Prettierを実行するには、 package.json の Scripts に以下の スクリプト を追加します。 //package.json "scripts": { "format": "prettier --write --ignore-path .gitignore ." } 以下のコマンドでPrettierを実行できます。 $ yarn format テスト フレームワーク のJest、React Testing Libraryの設定 Jest、React Testing Libraryをインストールする Next.jsの 公式ドキュメント を参照し、JestおよびReact Testing Libraryをインストール、設定します。 $ yarn add -D jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom jest.config.jsを作成する ルート ディレクト リでjestの設定ファイル jest.config.js を作成します。 //jest.config.js const nextJest = require('next/jest') const createJestConfig = nextJest({ dir: './', }) const customJestConfig = { moduleDirectories: ['node_modules', '<rootDir>/'], testEnvironment: 'jest-environment-jsdom', } module.exports = createJestConfig(customJestConfig) テストを実行してみる テストを実行するには、 package.json の scripts に以下の スクリプト を追加します。 //package.json "scripts": { "test": "jest" } サンプルテストを追加します。ルート ディレクト リに test フォルダを作成し、 test の配下に index.test.tsx ファイルを作成します。 //index.test.tsx import { render, screen } from '@testing-library/react' import '@testing-library/jest-dom/extend-expect' import Home from '../pages' describe('Home', () => { it('renders a heading', () => { render(<Home />) const heading = screen.getByRole('heading', { name: /welcome to next\.js/i, }) expect(heading).toBeInTheDocument() }) }) 以下のコマンドでテストをします。 $ yarn test テストが通ったことを確認できます。 Dockerfileの作成 Next.jsをDockerコンテナでデプロイするためのDockerfileのひな形を作成します。 Next.jsのstandaloneモードを有効にする まず、 next.config.js の設定を修正し、standaloneモードを有効にします。 //next.config.js const nextConfig = { output: 'standalone', } Next.js 12の最新バージョンではstandaloneモードを有効にすることで、ビルドサイズを大幅に削減できます。 yarn build により、 .next/standalone フォルダーが作成され、 node_modules の依存関係を含めたデプロイで必要となる最小限なファイルのみがコピーされます。 standalone に作成された sever.js を実行すれば本番アプリケーションを実行できます。 Dockerfileを作成する Next.jsの 公式サンプル を参考しつつ、Distrolessで実行するマルチビルドのDockerfileを作成します。 FROM node:16 AS build ADD . /app WORKDIR /app RUN yarn install --production=false RUN yarn build FROM gcr.io/distroless/nodejs:16 WORKDIR /app COPY --from=build /app/next.config.js ./ COPY --from=build /app/public ./public COPY --from=build /app/package.json ./package.json COPY --from=build /app/.next/static ./.next/static COPY --from=build /app/.next/standalone ./ CMD ["server.js"] ローカルでDockerコンテナを実行してみる 以下のコマンドでコンテナをビルド、実行できます。 $ docker build -t ｛イメージ名｝ . $ docker run -p 3000:3000 ｛イメージ名｝ GitHub Actionsを利用したビルド、テストの自動実行 pushをトリガーにしてビルドおよびテストを自動実行する GitHub Actionsを作成します。 ルート ディレクト リで .github/workflows フォルダーを作成し、配下に build-and-test-on-push.yml を作成します。 on: push: branches-ignore: - "main" name: Build and Test on Push jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: docker build run: docker build . run-tests: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Set up Node.js uses: actions/setup-node@v3 with: node-version: 16 - name: Install Dependencies run: yarn install - name: Run test run: yarn run test Dockerを利用しない場合は、 yarn build でビルドを実行できます。 まとめ 今回はNext.jsの環境構築の方法をまとめてみました。 環境構築のほとんどは 公式ドキュメント を参考にスムーズにできました。 create-next-app を利用すると手動で設定する部分が少なくなるので、便利かと思います。 また、CI環境の構築でDockerfileや GitHub Actionsの作成手順もまとめてみました。興味のある方はぜひ試してみてください。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 - ソリューションアーキテクト 執筆： @chen.xinying 、レビュー： @handa.kenta （ Shodo で執筆されました ）

こんにちは。X イノベーション 本部ソフトウェアデザインセンターの陳です。 この記事では Next.js + TypeScript + Docker + GitHub Actionsの環境構築の方法をまとめます。 セットアップ手順 以下のセットアップを行います。 1. create-next-appでNext.jsのプロジェクトを作成 2. 静的分析ツールESLintの設定 3. コードフォーマッターPrettierの設定 4. テスト フレームワーク のJest、React Testing Libraryの設定 5. Dockerfileの作成 6. GitHub Actionsを利用したビルド、テストの自動実行 バージョン Next.js v12.3.0 TypeScript v4.8.3 create-next-appでNext.jsのプロジェクトを作成 create-next-app はNext.jsプロジェクトを自動生成するためのコマンドです。 create-next-app を利用すると、Next.js + TypeScriptのプロジェクトのひな形を簡単に作成できます。公式ドキュメントは こちら です。 create-next-appを実行する 以下のコマンドを実行し、プロジェクトを自動生成します。 $ npx create-next-app ｛プロジェクト名｝　--ts yarnを利用することもできます。 $ yarn create next-app ｛プロジェクト名｝ --typescript --ts また --typescript を指定することで、TypeScriptを利用するプロジェクトが生成されます。TypeScriptの設定ファイル tsconfig.json も自動的に作成されます。 プロジェクトを動かしてみる 作成されたプロジェクトの ディレクト リで以下のコマンドを実行すると、Next.jsプロジェクトを開発モードで起動できます。 $ yarn dev localhost:3000 にアクセスするとこちらの画面が表示されます。これでプロジェクトのひな形の作成が完了しました。 静的分析ツールESLintの設定 ESLintを実行する Next.js v11.0.0から create-next-app でプロジェクトを作成すると、ESLintは自動的にインストールされます。 package.json の Scripts に "lint": "next lint" がデフォルトで設定されています。以下のコマンドでESLintを実行できます。 $ yarn lint ESLintのデフォルト構成 Next.jsのESLintのデフォルト構成では、 eslint-config-next の構成が自動的に設定されます。以下のルールセットが eslint-config-next に含まれるため、インストール、設定する必要はありません。公式ドキュメントは こちら です。 eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-next ESLintの構成をカスタマイズする .eslintrc.json を編集することで、構成をカスタマイズできます。 .eslintrc.json はESLintに関する設定ファイルです。 以下のように extends に記述すれば、 eslint:recommended など、他の構成を利用できます。また rules でルールの変更や無効化の設定もできます。 //.eslintrc.json { "extends": [ "eslint:recommended", "next/core-web-vitals", ], "rules":{ // 個別のルールを変更、無効にする場合はこちらに追加する "no-console": ["warn", { allow: ["warn", "error"] }], "sort-imports": "off", "import/order": ["error", { alphabetize: { order: "asc" } }], "import/no-named-as-default-member": "off", } コードフォーマッターPrettierの設定 Prettierをインストールする 以下のコマンドでPrettier本体、ESLintと併用する際に必要なライブラリーをインストールします。 $ yarn add -D prettier eslint-config-prettier .eslintrc. json を編集する .eslintrc.json を以下のように設定することで、ESLint と Prettier のコード整形が競合しないようになります。 //.eslintrc.json { "extends": ["next/core-web-vitals", "prettier"], } .prettierrcを作成する コード整形に関する設定をカスタマイズするには、ルート ディレクト リで .prettierrc を作成します。 以下のようにカスタマイズ設定ができます。設定の詳細は 公式ドキュメント を参照してください。 //.prettierrc { "tabWidth": 2, "printWidth": 120, "trailingComma": "es5", "semi": false, "singleQuote": true } Prettierを実行する Prettierを実行するには、 package.json の Scripts に以下の スクリプト を追加します。 //package.json "scripts": { "format": "prettier --write --ignore-path .gitignore ." } 以下のコマンドでPrettierを実行できます。 $ yarn format テスト フレームワーク のJest、React Testing Libraryの設定 Jest、React Testing Libraryをインストールする Next.jsの 公式ドキュメント を参照し、JestおよびReact Testing Libraryをインストール、設定します。 $ yarn add -D jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom jest.config.jsを作成する ルート ディレクト リでjestの設定ファイル jest.config.js を作成します。 //jest.config.js const nextJest = require('next/jest') const createJestConfig = nextJest({ dir: './', }) const customJestConfig = { moduleDirectories: ['node_modules', '<rootDir>/'], testEnvironment: 'jest-environment-jsdom', } module.exports = createJestConfig(customJestConfig) テストを実行してみる テストを実行するには、 package.json の scripts に以下の スクリプト を追加します。 //package.json "scripts": { "test": "jest" } サンプルテストを追加します。ルート ディレクト リに test フォルダを作成し、 test の配下に index.test.tsx ファイルを作成します。 //index.test.tsx import { render, screen } from '@testing-library/react' import '@testing-library/jest-dom/extend-expect' import Home from '../pages' describe('Home', () => { it('renders a heading', () => { render(<Home />) const heading = screen.getByRole('heading', { name: /welcome to next\.js/i, }) expect(heading).toBeInTheDocument() }) }) 以下のコマンドでテストをします。 $ yarn test テストが通ったことを確認できます。 Dockerfileの作成 Next.jsをDockerコンテナでデプロイするためのDockerfileのひな形を作成します。 Next.jsのstandaloneモードを有効にする まず、 next.config.js の設定を修正し、standaloneモードを有効にします。 //next.config.js const nextConfig = { output: 'standalone', } Next.js 12の最新バージョンではstandaloneモードを有効にすることで、ビルドサイズを大幅に削減できます。 yarn build により、 .next/standalone フォルダーが作成され、 node_modules の依存関係を含めたデプロイで必要となる最小限なファイルのみがコピーされます。 standalone に作成された sever.js を実行すれば本番アプリケーションを実行できます。 Dockerfileを作成する Next.jsの 公式サンプル を参考しつつ、Distrolessで実行するマルチビルドのDockerfileを作成します。 FROM node:16 AS build ADD . /app WORKDIR /app RUN yarn install --production=false RUN yarn build FROM gcr.io/distroless/nodejs:16 WORKDIR /app COPY --from=build /app/next.config.js ./ COPY --from=build /app/public ./public COPY --from=build /app/package.json ./package.json COPY --from=build /app/.next/static ./.next/static COPY --from=build /app/.next/standalone ./ CMD ["server.js"] ローカルでDockerコンテナを実行してみる 以下のコマンドでコンテナをビルド、実行できます。 $ docker build -t ｛イメージ名｝ . $ docker run -p 3000:3000 ｛イメージ名｝ GitHub Actionsを利用したビルド、テストの自動実行 pushをトリガーにしてビルドおよびテストを自動実行する GitHub Actionsを作成します。 ルート ディレクト リで .github/workflows フォルダーを作成し、配下に build-and-test-on-push.yml を作成します。 on: push: branches-ignore: - "main" name: Build and Test on Push jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: docker build run: docker build . run-tests: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Set up Node.js uses: actions/setup-node@v3 with: node-version: 16 - name: Install Dependencies run: yarn install - name: Run test run: yarn run test Dockerを利用しない場合は、 yarn build でビルドを実行できます。 まとめ 今回はNext.jsの環境構築の方法をまとめてみました。 環境構築のほとんどは 公式ドキュメント を参考にスムーズにできました。 create-next-app を利用すると手動で設定する部分が少なくなるので、便利かと思います。 また、CI環境の構築でDockerfileや GitHub Actionsの作成手順もまとめてみました。興味のある方はぜひ試してみてください。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 - ソリューションアーキテクト 執筆： @chen.xinying 、レビュー： @handa.kenta （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、Ansible Vaultを利用して、Ansibleを使う場合に機密情報を安全に扱う方法について紹介します。 ansibleと機密情報の管理についての課題 Ansibleを使ってデプロイなどを自動化していると、 Amazon Web Services ( AWS ) の機密情報やパスワード、 SSH に利用する 秘密鍵 といった機密情報を扱う場面があります。また、Ansibleを利用している場合はplaybookを GitHub などで管理することが多いと思います。こういった GitHub などの リポジトリ に機密情報を直接置いてしまうと情報漏洩といった事故につながる場合があります。 機密情報を別システム ( dashlaneや AWS のsecret managerなど ) で管理するといった方法もあるかと思います。しかしこの方法では機密情報だけをバージョン管理の仕組みから別で管理することとなってしまい、管理コストが高くなってしまいます。また、CI/CDといった自動化を行う場合にもansible以外のツール、機密情報へのアクセス方法を考えなければならなくなってしまいます。 理想的には以下のような状態になっていてほしいです。 機密情報は安全に扱いたい 新規のツールの導入は避けたい playbookと機密情報の両方を1つの リポジトリ 上で安全にバージョン管理できる 今回はこの問題を解決するAnsible Vaultというツールについて紹介します。 Ansible Vaultとは このような機密情報を扱うために、AnsibleにはAnsible Vaultと呼ばれる暗号化の機能が付属しています。暗号化した情報であれば リポジトリ 上に置くリスクを大幅に減らすことができます。本記事ではこのAnsible Vaultを使って、 ssh の 秘密鍵 、 AWS の認証情報といった機密情報を暗号化してCI/CDから利用する方法について記載します。 なお、Ansible Vaultの公式のドキュメントは以下となります。より詳細な説明は以下のドキュメントを参照してください。 https://docs.ansible.com/ansible/latest/user_guide/vault.html この記事で紹介している利用方法は、 10人に満たない小規模なチーム 機密情報はメンバ内で共有して問題がない 上記のような想定となっています。 このため、Ansible Vaultで暗号化に利用するパスワードは vaultd-id を利用して分割したりせず単一で共通のものを想定しています。 Ansible Vaultを使った暗号化、復号化 Ansible Vaultは、 ansible-vault コマンドを通じて利用します。サブコマンドとして create 、 encrypt 、 decrypt 、 rekey 、 edit 、 view というサブコマンドがあります。ここでは、既存のファイルの暗号化、復号を行う encrypt 、 decrypt の動作について述べます。 まずは、 encrypt を使ってファイルを暗号化してみましょう。以下のような中身のファイルを、 test.txt という名前で作成します。 hello,world! そのファイルを、 ansible-vault encrypt で暗号化します。 途中でパスワードを聞かれるので、適宜入力して忘れない様にしてください。 $ansible-vault encrypt test.txt New Vault password: Confirm New Vault password: Encryption successful 暗号化に成功したようです。暗号化された中身を確認してみます。 $ cat test.txt $ANSIBLE_VAULT;1.1;AES256 34646636663564393432303436353932613263346534373439353133303137333064343363326266 6565386564393437316139353031333063316663363466300a376534313035373630356663376661 35663263663265383861346162306630353636316534626165313638616433373566373632306339 6438646236316431380a643737343561376133313334616162303737616561386262633338313761 6436 ちゃんと暗号化できたようです。 今度は復号できるか確認してみましょう。復号に使うコマンドは ansible-vault decrypt です。 途中で先ほど入力したパスワードを求められます。打ち間違いに注意してパスワードを入力しましょう。 ansible-vault decrypt test.txt Vault password: Decryption successful 無事復号できたようです。 それでは、中身も正しいかを確認してみましょう。 $ cat test.txt hello,world! ちゃんとファイルの中身も復号できていることが分かりました。 この ansible-vault の機能を使って機密情報を扱うplaybookを作ってみましょう。 SSH 接続情報の保護 ansibleでは SSH の接続に 秘密鍵 を利用することが多いですが、この 秘密鍵 を リポジトリ に暗号化せずに登録してしまうと、その情報を入手した人は誰でも接続できてしまいます。まずはこの情報の暗号化を実施してみましょう。 まず、以下のように接続に利用する 秘密鍵 ( private_key )を暗号化しておきます。 ansible-vault private_key 次に、実行するplaybookの先頭にこの暗号化された 秘密鍵 を復号するタスクを追加します。 内容としては copy モジュールを実行するだけのものになっています。ansibleの copy モジュールは、 ansible-vault で暗号化されたファイルを扱う際に復号してくれる機能があります。その機能を利用して、 秘密鍵 を復号しています。 - hosts: localhost gather_facts: false vars: src_key: ./private_key dest_key: ./decrypted_private_key tasks: - copy: src: "{{ src_key }}" dest: "{{ dest_key }}" mode: 0600 そして ansible-playbook で利用する inventory.yml を以下のように記述します。 XXXで示している部分は各自の環境に合わせて書き換えてください。 ここで、 ansible_ssh_private_key_file には上記の手順で復号された 秘密鍵 が指定されるように設定します。 all: children: XXXX: hosts: XXXX: ansible_ssh_private_key_file: ./decrypted_private_key ansible_ssh_user: XXXX ansible_host: XXX.XXX.XXX.XXX ungrouped: {} これで、 秘密鍵 を暗号化して管理することが可能になりました。 機密情報を利用するPlaybookの実行方法 ansible-playbook を実行する際にvaultで利用したパスワードが必要になりました。 以下のように引数でパスワードファイルを渡すか、毎回入力する方法があります。 自動化などを考えるとパスワードファイルを作成する方法が手軽です。 # 端末で毎回パスワードを入力する方法 ansible-playbook site.yml -ask-vault-pass # パスワードファイルを引数で与える方法 ansible-playbook site.yml –vault-password-file ~/.vault_pass.txt 例えば、 環境変数 $VAULT_PASS にパスワードが格納されているような場合では、以下のような スクリプト を実行する方法があります。 echo "$VAULT_PASS" > .vault_pass.txt ansible-playbook -i inventory.yml site.yml –vault-password-file ~/.vault_pass.txt rm .vault_pass.txt Playbook上で利用する機密情報の保護 ここまでで SSH に利用する 秘密鍵 の暗号化は実現できました。次にplaybookの中で利用したい機密情報についても暗号化していきましょう。 先ほどの 秘密鍵 の例では、 copy モジュールは自動的に ansible-vault の復号を実施してくれると説明しました。この機能がansibleの変数のファイルに対しても自動的に復号を行ってくれます。 従ってAnsibleが利用する group_vars/all.yml といった変数ファイルを ansible-vault コマンドで事前に暗号化しておくことで、機密情報を暗号化したままで利用することが出来ます。以下のように事前に変数のファイルを暗号化しておくだけで安全に管理することが可能となります。 group_vars/all.yml には以下のように、sudoのパスワードや AWS の接続情報が含まれています。 --- ansible_sudo_pass: "XXXXXXXXXX" aws_access_key_id: "XXXXXXXXXXXXXXXXXXX" aws_secret_access_key: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" これを、 ansible-vault で暗号化します。 ansible-vault encrypt group_vars/all.yml この状態で、 ansible-playbook の実行時に group_vars/all の変数を利用する際に自動的に復号処理が行われます。 実行方法は前項で述べた方法と変わらず実行できます。 GitHub Actions で実行する方法 それでは、最後に GitHub Actionsで実行する場合の方法について紹介します。 vaultのパスワードを GitHub のsecretとして与えるような設定を行って実行します。 jobs: deploy: steps: - name: Exec ansible-playbook env: VAULT_PASS: ${{secrets.VAULT_PASS}} run: | echo $VAULT_PASS > ./vault_pass.txt ansible-playbook -i inventory.yml site.yml --vault-password-file ./vault_pass.txt" 簡単ですね！ まとめ この記事では、Ansible Vaultを使った機密情報の扱い方の簡単な紹介を行いました。またそれらを組みわせて GitHub Actionsから実行する方法も紹介しました。これで、安全に リポジトリ 上の機密情報を置きながら、CI/CDも手軽に実行できる環境が構築できます。 仮想マシン などにサービスをAnsibleを使ってデプロイする場面では是非有効活用していきたいですね。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @sato.taichi （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、Ansible Vaultを利用して、Ansibleを使う場合に機密情報を安全に扱う方法について紹介します。 ansibleと機密情報の管理についての課題 Ansibleを使ってデプロイなどを自動化していると、 Amazon Web Services ( AWS ) の機密情報やパスワード、 SSH に利用する 秘密鍵 といった機密情報を扱う場面があります。また、Ansibleを利用している場合はplaybookを GitHub などで管理することが多いと思います。こういった GitHub などの リポジトリ に機密情報を直接置いてしまうと情報漏洩といった事故につながる場合があります。 機密情報を別システム ( dashlaneや AWS のsecret managerなど ) で管理するといった方法もあるかと思います。しかしこの方法では機密情報だけをバージョン管理の仕組みから別で管理することとなってしまい、管理コストが高くなってしまいます。また、CI/CDといった自動化を行う場合にもansible以外のツール、機密情報へのアクセス方法を考えなければならなくなってしまいます。 理想的には以下のような状態になっていてほしいです。 機密情報は安全に扱いたい 新規のツールの導入は避けたい playbookと機密情報の両方を1つの リポジトリ 上で安全にバージョン管理できる 今回はこの問題を解決するAnsible Vaultというツールについて紹介します。 Ansible Vaultとは このような機密情報を扱うために、AnsibleにはAnsible Vaultと呼ばれる暗号化の機能が付属しています。暗号化した情報であれば リポジトリ 上に置くリスクを大幅に減らすことができます。本記事ではこのAnsible Vaultを使って、 ssh の 秘密鍵 、 AWS の認証情報といった機密情報を暗号化してCI/CDから利用する方法について記載します。 なお、Ansible Vaultの公式のドキュメントは以下となります。より詳細な説明は以下のドキュメントを参照してください。 https://docs.ansible.com/ansible/latest/user_guide/vault.html この記事で紹介している利用方法は、 10人に満たない小規模なチーム 機密情報はメンバ内で共有して問題がない 上記のような想定となっています。 このため、Ansible Vaultで暗号化に利用するパスワードは vaultd-id を利用して分割したりせず単一で共通のものを想定しています。 Ansible Vaultを使った暗号化、復号化 Ansible Vaultは、 ansible-vault コマンドを通じて利用します。サブコマンドとして create 、 encrypt 、 decrypt 、 rekey 、 edit 、 view というサブコマンドがあります。ここでは、既存のファイルの暗号化、復号を行う encrypt 、 decrypt の動作について述べます。 まずは、 encrypt を使ってファイルを暗号化してみましょう。以下のような中身のファイルを、 test.txt という名前で作成します。 hello,world! そのファイルを、 ansible-vault encrypt で暗号化します。 途中でパスワードを聞かれるので、適宜入力して忘れない様にしてください。 $ansible-vault encrypt test.txt New Vault password: Confirm New Vault password: Encryption successful 暗号化に成功したようです。暗号化された中身を確認してみます。 $ cat test.txt $ANSIBLE_VAULT;1.1;AES256 34646636663564393432303436353932613263346534373439353133303137333064343363326266 6565386564393437316139353031333063316663363466300a376534313035373630356663376661 35663263663265383861346162306630353636316534626165313638616433373566373632306339 6438646236316431380a643737343561376133313334616162303737616561386262633338313761 6436 ちゃんと暗号化できたようです。 今度は復号できるか確認してみましょう。復号に使うコマンドは ansible-vault decrypt です。 途中で先ほど入力したパスワードを求められます。打ち間違いに注意してパスワードを入力しましょう。 ansible-vault decrypt test.txt Vault password: Decryption successful 無事復号できたようです。 それでは、中身も正しいかを確認してみましょう。 $ cat test.txt hello,world! ちゃんとファイルの中身も復号できていることが分かりました。 この ansible-vault の機能を使って機密情報を扱うplaybookを作ってみましょう。 SSH 接続情報の保護 ansibleでは SSH の接続に 秘密鍵 を利用することが多いですが、この 秘密鍵 を リポジトリ に暗号化せずに登録してしまうと、その情報を入手した人は誰でも接続できてしまいます。まずはこの情報の暗号化を実施してみましょう。 まず、以下のように接続に利用する 秘密鍵 ( private_key )を暗号化しておきます。 ansible-vault private_key 次に、実行するplaybookの先頭にこの暗号化された 秘密鍵 を復号するタスクを追加します。 内容としては copy モジュールを実行するだけのものになっています。ansibleの copy モジュールは、 ansible-vault で暗号化されたファイルを扱う際に復号してくれる機能があります。その機能を利用して、 秘密鍵 を復号しています。 - hosts: localhost gather_facts: false vars: src_key: ./private_key dest_key: ./decrypted_private_key tasks: - copy: src: "{{ src_key }}" dest: "{{ dest_key }}" mode: 0600 そして ansible-playbook で利用する inventory.yml を以下のように記述します。 XXXで示している部分は各自の環境に合わせて書き換えてください。 ここで、 ansible_ssh_private_key_file には上記の手順で復号された 秘密鍵 が指定されるように設定します。 all: children: XXXX: hosts: XXXX: ansible_ssh_private_key_file: ./decrypted_private_key ansible_ssh_user: XXXX ansible_host: XXX.XXX.XXX.XXX ungrouped: {} これで、 秘密鍵 を暗号化して管理することが可能になりました。 機密情報を利用するPlaybookの実行方法 ansible-playbook を実行する際にvaultで利用したパスワードが必要になりました。 以下のように引数でパスワードファイルを渡すか、毎回入力する方法があります。 自動化などを考えるとパスワードファイルを作成する方法が手軽です。 # 端末で毎回パスワードを入力する方法 ansible-playbook site.yml -ask-vault-pass # パスワードファイルを引数で与える方法 ansible-playbook site.yml –vault-password-file ~/.vault_pass.txt 例えば、 環境変数 $VAULT_PASS にパスワードが格納されているような場合では、以下のような スクリプト を実行する方法があります。 echo "$VAULT_PASS" > .vault_pass.txt ansible-playbook -i inventory.yml site.yml –vault-password-file ~/.vault_pass.txt rm .vault_pass.txt Playbook上で利用する機密情報の保護 ここまでで SSH に利用する 秘密鍵 の暗号化は実現できました。次にplaybookの中で利用したい機密情報についても暗号化していきましょう。 先ほどの 秘密鍵 の例では、 copy モジュールは自動的に ansible-vault の復号を実施してくれると説明しました。この機能がansibleの変数のファイルに対しても自動的に復号を行ってくれます。 従ってAnsibleが利用する group_vars/all.yml といった変数ファイルを ansible-vault コマンドで事前に暗号化しておくことで、機密情報を暗号化したままで利用することが出来ます。以下のように事前に変数のファイルを暗号化しておくだけで安全に管理することが可能となります。 group_vars/all.yml には以下のように、sudoのパスワードや AWS の接続情報が含まれています。 --- ansible_sudo_pass: "XXXXXXXXXX" aws_access_key_id: "XXXXXXXXXXXXXXXXXXX" aws_secret_access_key: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" これを、 ansible-vault で暗号化します。 ansible-vault encrypt group_vars/all.yml この状態で、 ansible-playbook の実行時に group_vars/all の変数を利用する際に自動的に復号処理が行われます。 実行方法は前項で述べた方法と変わらず実行できます。 GitHub Actions で実行する方法 それでは、最後に GitHub Actionsで実行する場合の方法について紹介します。 vaultのパスワードを GitHub のsecretとして与えるような設定を行って実行します。 jobs: deploy: steps: - name: Exec ansible-playbook env: VAULT_PASS: ${{secrets.VAULT_PASS}} run: | echo $VAULT_PASS > ./vault_pass.txt ansible-playbook -i inventory.yml site.yml --vault-password-file ./vault_pass.txt" 簡単ですね！ まとめ この記事では、Ansible Vaultを使った機密情報の扱い方の簡単な紹介を行いました。またそれらを組みわせて GitHub Actionsから実行する方法も紹介しました。これで、安全に リポジトリ 上の機密情報を置きながら、CI/CDも手軽に実行できる環境が構築できます。 仮想マシン などにサービスをAnsibleを使ってデプロイする場面では是非有効活用していきたいですね。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @sato.taichi （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、Stable Diffusion v1.5が出たので早速、Stable Diffusionが比較的苦手な美少女画で検証してみました。 StabilityAIではなく、Runawaymlからv1.5がリリースされたので、StabilityAIが削除申請を出したのですが、取り下げたようです。 huggingface.co Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 TPU版の使い方 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 ライセンスへの同意 huggingfaceへのログイン 必要なモジュールのインストール pipeの作成 画像の出力 美少女画による検証 日本的な美少女アニメ画 美少女イラスト 美少女写真 まとめ 仲間募集 Stable Diffusionの全コンテンツ ライセンスへの同意 https://huggingface.co/runwayml/stable-diffusion-v1-5 にアクセスして、ライセンスに同意してください。 huggingfaceへのログイン ここからは、 Google Colabでの作業になります。 huggingfaceへログインします。 from huggingface_hub import notebook_login from pathlib import Path if not (Path.home()/'.huggingface'/'token').exists(): notebook_login() 必要なモジュールのインストール 必要なモジュールをインストールします。diffusersのバージョンが特に明示されていなかったので、今回は、 TPU版の使い方 で使った 0.5.1 を使ってみました。 !pip install diffusers==0.5.1 transformers scipy ftfy pipeの作成 pipeを作成します。以前と model_id が異なることに注意してください。 from diffusers import StableDiffusionPipeline import torch model_id = "runwayml/stable-diffusion-v1-5" device = "cuda" pipe = StableDiffusionPipeline.from_pretrained(model_id, torch_dtype=torch.float16, revision="fp16") pipe = pipe.to(device) 画像の出力 画像を出力します。以前は、 image = pipe(prompt)["sample"][0] でした。 prompt = "a photo of an astronaut riding a horse on mars" image = pipe(prompt).images[0] 美少女画による検証 Stable Diffusionが比較的苦手な美少女画で検証します。結論から先に書くとv1.4より多少良くなっているけど、劇的に改善されたわけではないと言ったところでしょうか。 今回載せた画像は、意図的にイマイチだったものを選んでいます。クオリティの高い画像は、何度かやり直せば必ず出力できるので。 日本的な 美少女アニメ 画 Stable Diffusionが最も苦手とするのが、日本的な 美少女アニメ 画です。v1.4では、顔が崩れる、目が変、手が変といった問題がときどき（起きる頻度は呪文によって変わる）起きていました。 v1.5では、顔が崩れる、目が変という問題は、多少改善されていますが、まだ完璧ではありません。手が変という問題は、数十回試した限りは、全く改善されていないように感じます。 今回試した呪文はこちら。 anime of tsundere moe kawaii beautiful girl pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render イマイチだった出力結果はこちら。 美少女イラスト 美少女アニメ 画の呪文の anime を illustration に変え、 tsundere 、 moe 、 kawaii 、 pixiv 、 niconico を削ったものが、美少女イラストの呪文です。 この呪文はかなり安定していて、たまに手が変になるくらいです。 今回試した呪文はこちら。 illustration of beautiful girl artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render イマイチだった出力結果はこちら。 美少女写真 美少女写真は、安定（変にならない）度で、美少女イラストには劣りますが、日本的な 美少女アニメ 画よりは、安定しています。感覚的には、美少女イラスト > 美少女写真 >>> 日本的な 美少女アニメ 画といったところでしょうか。 今回試した呪文はこちら。 photo of beautiful girl SIGMA 85 mm F1.4 artstation impressive scene impressive composition impressive lighting イマイチだった出力結果はこちら。 まとめ 今回、Stable Diffusion v1.5を検証してみました。日本的な 美少女アニメ 画の安定度が悪いと感じたかもしれませんが、比較的辛口に評価したので、実際のv1.5の評価は、ご自分でなさることをお勧めします。 日本的な 美少女アニメ 画も head shot （顔写真）の呪文を加えれば、手が写ることはほとんどないので、次のようなクオリティの画像は連発できます。 head shot にすると構図が限られるので、あまり使ってこなかったのですが、日本的な 美少女アニメ 画では、 head shot を必須にして安定度をとったほうが良いかもしれません。 head shot にするとStable Diffusionが顔に注目するせいか、顔が変になったり、目が変になったりすることもほとんどなくなるようです。 次回は、 東京タワーの写真 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、Stable Diffusion v1.5が出たので早速、Stable Diffusionが比較的苦手な美少女画で検証してみました。 StabilityAIではなく、Runawaymlからv1.5がリリースされたので、StabilityAIが削除申請を出したのですが、取り下げたようです。 huggingface.co Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 TPU版の使い方 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 ライセンスへの同意 huggingfaceへのログイン 必要なモジュールのインストール pipeの作成 画像の出力 美少女画による検証 日本的な美少女アニメ画 美少女イラスト 美少女写真 まとめ 仲間募集 Stable Diffusionの全コンテンツ ライセンスへの同意 https://huggingface.co/runwayml/stable-diffusion-v1-5 にアクセスして、ライセンスに同意してください。 huggingfaceへのログイン ここからは、 Google Colabでの作業になります。 huggingfaceへログインします。 from huggingface_hub import notebook_login from pathlib import Path if not (Path.home()/'.huggingface'/'token').exists(): notebook_login() 必要なモジュールのインストール 必要なモジュールをインストールします。diffusersのバージョンが特に明示されていなかったので、今回は、 TPU版の使い方 で使った 0.5.1 を使ってみました。 !pip install diffusers==0.5.1 transformers scipy ftfy pipeの作成 pipeを作成します。以前と model_id が異なることに注意してください。 from diffusers import StableDiffusionPipeline import torch model_id = "runwayml/stable-diffusion-v1-5" device = "cuda" pipe = StableDiffusionPipeline.from_pretrained(model_id, torch_dtype=torch.float16, revision="fp16") pipe = pipe.to(device) 画像の出力 画像を出力します。以前は、 image = pipe(prompt)["sample"][0] でした。 prompt = "a photo of an astronaut riding a horse on mars" image = pipe(prompt).images[0] 美少女画による検証 Stable Diffusionが比較的苦手な美少女画で検証します。結論から先に書くとv1.4より多少良くなっているけど、劇的に改善されたわけではないと言ったところでしょうか。 今回載せた画像は、意図的にイマイチだったものを選んでいます。クオリティの高い画像は、何度かやり直せば必ず出力できるので。 日本的な 美少女アニメ 画 Stable Diffusionが最も苦手とするのが、日本的な 美少女アニメ 画です。v1.4では、顔が崩れる、目が変、手が変といった問題がときどき（起きる頻度は呪文によって変わる）起きていました。 v1.5では、顔が崩れる、目が変という問題は、多少改善されていますが、まだ完璧ではありません。手が変という問題は、数十回試した限りは、全く改善されていないように感じます。 今回試した呪文はこちら。 anime of tsundere moe kawaii beautiful girl pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render イマイチだった出力結果はこちら。 美少女イラスト 美少女アニメ 画の呪文の anime を illustration に変え、 tsundere 、 moe 、 kawaii 、 pixiv 、 niconico を削ったものが、美少女イラストの呪文です。 この呪文はかなり安定していて、たまに手が変になるくらいです。 今回試した呪文はこちら。 illustration of beautiful girl artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render イマイチだった出力結果はこちら。 美少女写真 美少女写真は、安定（変にならない）度で、美少女イラストには劣りますが、日本的な 美少女アニメ 画よりは、安定しています。感覚的には、美少女イラスト > 美少女写真 >>> 日本的な 美少女アニメ 画といったところでしょうか。 今回試した呪文はこちら。 photo of beautiful girl SIGMA 85 mm F1.4 artstation impressive scene impressive composition impressive lighting イマイチだった出力結果はこちら。 まとめ 今回、Stable Diffusion v1.5を検証してみました。日本的な 美少女アニメ 画の安定度が悪いと感じたかもしれませんが、比較的辛口に評価したので、実際のv1.5の評価は、ご自分でなさることをお勧めします。 日本的な 美少女アニメ 画も head shot （顔写真）の呪文を加えれば、手が写ることはほとんどないので、次のようなクオリティの画像は連発できます。 head shot にすると構図が限られるので、あまり使ってこなかったのですが、日本的な 美少女アニメ 画では、 head shot を必須にして安定度をとったほうが良いかもしれません。 head shot にするとStable Diffusionが顔に注目するせいか、顔が変になったり、目が変になったりすることもほとんどなくなるようです。 次回は、 東京タワーの写真 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

はいどーもー！ X イノベーション 本部の宮澤響です！ 本記事では、X イノベーション 本部内の部署であるソフトウェアデザインセンターと クラウド イノベーション センターに、バーチャルオフィスサービスであるGatherを導入した話をご紹介します！ そもそもGatherって何？ どういうルールで運用している？ スペース内のどこにいてもOK いつでも会話やチャットOK 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない Teamsとの使い分けは？ アクセス制限はどうしている？ 導入してみてどう？ 良かった点 グループ間を超えるコミュニケーションが増加した 「ちょっと話しかける」がしやすくなった 中途入社の不安を緩和できる 課題点 Do Not Disturbモードやマイクオフにし忘れると音声が漏れる Gather用のディスプレイがないと使いにくい 話しかけたい人がログインしているとは限らない まとめ そもそもGatherって何？ Gather （Gather.Town）とは、Gather Presence, Inc.が提供しているバーチャルオフィスサービス、つまりオフィスのように社員同士が集まる仮想的な空間を提供するサービスの一つです。 SpatialChat や oVice などと同種のサービスですが、古き良き2D- RPG を彷彿とさせる可愛らしいキャ ラク ターやマップのデザインが、それらとの大きな相違点の一つです。 マップ上で近い場所にいるメンバーや、同じ部屋や机の島にいるメンバー（こちらに関しては設定が必要ですが）にのみ音声が届くため、 Teams や Zoom での通話と異なり、「ふとしたタイミング」で「ちょっとした会話」をする、といったことがしやすいです。 料金については こちら を参照していただければと思いますが、同時接続ユーザ数が25名以下であれば、マップの数や広さに関係なく無料で利用できるので、使い始めるための金銭的なハードルが非常に低くなっています。 どういうルールで運用している？ 基本ルールとしては、以下の4つがあります。 スペース内のどこにいてもOK いつでも会話やチャットOK 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない ルールといっても、何かを制限したり強制したりといったことはほとんどしておらず、毎朝のログインすらも強制ではなく推奨としています。 スペース内のどこにいてもOK こちらは文字どおり、どこにいても（キャ ラク ターを移動させても）OKというものです。 私たちのスペースには、机や会議室が配置されている「オフィス」だけでなく、歓迎会などを開催するための「屋上」や、ワーケーション気分を味わうことができる「南国」などが存在します。 そのため、常に「オフィス」にいる必要はないですよ、というのがこちらのルールになります。 いつでも会話やチャットOK こちらも文字どおりです。 ただし、業務で扱う情報の中でも機密度が高いものに関しては、基本的にGatherでは扱わないこととしています。 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Gatherには、Do Not Disturbモードというモードが存在します。 このモードでは、自分の音声も周囲に届かず、周囲の音声も自分には届かないようになります。 そのため、TeamsやZoomでの会議中や、作業に集中したいタイミングなど、会話できない／したくないときにこのモードを利用することになります。 また、私たちのスペースには、Focusエリアという個人ブースのような場所を複数設置しています。 このエリアも同様に、会話できない／したくないときに利用することを想定しています。 なお、Do Not Disturbモードとの相違点としては、真後ろ1マスにいるメンバーに対しては、お互いの音声が届く仕様となっている点が挙げられます。 Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない 上述のDo Not DisturbモードやFocusエリアを利用しているメンバーは、基本的には会話できない／したくない状態です。 そのため、これらを利用しているメンバーには話しかけないようにしましょう、というのがこちらのルールです。 （Do Not Disturbモードに関してはそもそも話しかけても音声は届きませんが） Teamsとの使い分けは？ 弊社では、コミュニケーションツールとしてTeamsを全社利用しています。 そのため、現在は以下のような目安でTeamsとGatherを使い分けています。 とはいえ、あくまで目安ですので、Teamsで雑談会が開催されていたりもします。 Teams Gather 他部署の社員が参加する打ち合わせ 事前にスケジュールされた打ち合わせ 特定のTeamsチャネルに紐づいた打ち合わせ 左記以外の打ち合わせ ちょっとした確認、依頼 雑談 アクセス制限はどうしている？ 私たちのスペースでは、 Guest List Only Access 機能を利用したアクセス制限を実施しています。 この機能は ホワイトリスト 方式になっていて、Gatherにログインしているユーザの中でも、リストにメールアドレスが登録されているユーザのみにスペースへのアクセスを許可できます。 これにより、万が一スペースのURLが漏れてしまった場合にも、部外者がスペースに侵入することのないように設定しています。 導入してみてどう？ 良かった点 大きく以下の3点が挙げられます。 グループ間を超えるコミュニケーションが増加した 「ちょっと話しかける」がしやすくなった 中途入社の不安を緩和できる グループ間を超えるコミュニケーションが増加した 私が所属しているソフトウェアデザインセンターの開発技術グループでは、毎朝グループ内で朝会（デイリー スタンドアップ ）を実施しています。 そのため、Gather導入以前にも、グループ内のメンバーに対しては、朝会の中でコミュニケーションをとる機会がありました。 しかしながら、隣のグループであるセキュリティグループの方々とは、たまたま同じ打ち合わせに参加する、といったことがない限りは、雑談はおろか挨拶を交わす機会すらありませんでした。 もちろん、Teamsで個人チャットを送るなどすれば会話自体はできるものの、特に業務上の要件がないのに個人チャットを送るのはなかなかハードルが高いものです。 このあたりは読者の皆さんも共感していただけるのではないかと思います。 そのような状態だったのですが、Gather導入後は、近くにいる社員に、開発技術グループ、セキュリティグループ関係なく挨拶をする、といった機会が生まれました。 そこから少し雑談をしてみたり、といったこともあります。 これによって、セキュリティグループの方々とも一定の交流をもつことができ、個人的には親近感も湧きやすくなったと感じています。 これは、これまでのTeamsでは発生し得なかったコミュニケーションだと思います。 「ちょっと話しかける」がしやすくなった 前項と類似していますが、「ちょっと話しかける」といったことがしやすくなったと感じます。 例えば、「ちょっとこれ見てください！」「ちょっとここ教えてください！」といった要件をリアルタイムで相手に伝えられるため、チャットでやり取りするよりも快適なことが多いです。 また、業務の隙間時間などに突発的に始まり、周りにいる人にも会話内容が少し聞こえて、そのままふらっと会話に参加できる、そんな形の雑談が発生しやすくなりました。 「この時間に雑談しましょう！」とスケジューリングして行う雑談ももちろん雑談ではあると思うのですが、個人的にはそれに比べてより自然な形での雑談ができているなと感じています。 中途入社の不安を緩和できる カジュアル面談や 中途採用 面接の際にGatherの実際の様子をお見せすると、好反応をいただけることが多いです。 リモートワークが主体となったこの時代の転職は、やはりコミュニケーション面に不安を覚える方が多いということで、このような取り組みで少しでもその不安を緩和できればと思います。 なお、実際に最近のソフトウェアデザインセンターの中途入社メンバーからは以下のような声をいただいています。 何か不明点を確認したり気分転換をしたりしたいときにGatherにログインし、手が空いていそうな方に話しかけている。Teamsのチャットでは相手の忙しさが分からないため、画面上で動きを把握できるのは良いと思う。 とにかく何気ない会話がしやすい。雑談からの流れで何かを尋ねやすい。 一人で働いているのではなく、チームで働いている感覚をもてる。 物理オフィスであれば自然と目にする、耳にするであろう情報に近い情報を得られる。例えば、ステータスや居場所を確認することで周囲の方の状況が分かる。また、自分が会話をせずとも、周囲の方同士の会話を聞くことで、業務状況や人となりなどを知ることができる。 課題点 8月末から導入して、現在2か月ほど経過しましたが、課題としては大きく以下の3点が挙げられます。 Do Not Disturbモードやマイクオフにし忘れると音声が漏れる Gather用のディスプレイがないと使いにくい 話しかけたい人がログインしているとは限らない Do Not Disturbモードやマイクオフにし忘れると音声が漏れる これはGatherの課題点というよりはTeamsとGatherを併用する際の課題点ですが、Gatherにログインした状態でTeamsでの会議に参加すると、Do Not Disturbモードやマイクオフにしない限り、会議の音声がGather上に流れてしまうリスクがあります。 独り言を垂れ流すだけならば問題ない（垂れ流してしまった側の気分的には問題ですが…笑）のですが、会議の音声の場合、内容によっては機密情報が漏れてしまうおそれもあるので、注意が必要です。 そのため、万が一Do Not Disturbモードやマイクオフにし忘れてしまったときのためにも、会議中はFocusエリアに移動することを推奨しています。 Gather用のディスプレイがないと使いにくい 普段の業務をノートPCのディスプレイのみで行っている場合、Gatherの画面を常には表示しておけません。 そのため、Gatherを利用していてもあまりバーチャルオフィス感がなく、突然話しかけられるとテンパってしまう、といった声もありました。 話しかけたい人がログインしているとは限らない 現状では特にログインを強制していないため、話しかけたい人がログインしているとは限りません。 とはいえ、こちらは運用のルール次第ではあるので、今後検討の余地はあります。 まとめ 本記事では、X イノベーション 本部内の部署にGatherを導入した話について簡単にまとめました。 コミュニケーション活性化に有用で、見た目も可愛く、無料で始められるバーチャルオフィスサービスGather、ぜひ皆さんの部署にも導入してみませんか？ Gatherの回し者みたいになってしまいましたが、最後までお読みいただき、本当にありがとうございました！ 私たちは同じグループで共に働いていただける仲間を募集しています。 現在募集している職種は以下です。 ソリューションアーキテクト 「入社直後の右も左も分からない状態でのオンラインコミュニケーション」に対する不安をGatherで緩和できればと考えていますので、ご興味のある方、ぜひご応募お待ちしています！ 執筆： @miyazawa.hibiki 、レビュー： @yamada.y （ Shodo で執筆されました ）

はいどーもー！ X イノベーション 本部の宮澤響です！ 本記事では、X イノベーション 本部内の部署であるソフトウェアデザインセンターと クラウド イノベーション センターに、バーチャルオフィスサービスであるGatherを導入した話をご紹介します！ そもそもGatherって何？ どういうルールで運用している？ スペース内のどこにいてもOK いつでも会話やチャットOK 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない Teamsとの使い分けは？ アクセス制限はどうしている？ 導入してみてどう？ 良かった点 グループ間を超えるコミュニケーションが増加した 「ちょっと話しかける」がしやすくなった 中途入社の不安を緩和できる 課題点 Do Not Disturbモードやマイクオフにし忘れると音声が漏れる Gather用のディスプレイがないと使いにくい 話しかけたい人がログインしているとは限らない おわりに そもそもGatherって何？ Gather （Gather.Town）とは、Gather Presence, Inc.が提供しているバーチャルオフィスサービス、つまりオフィスのように社員同士が集まる仮想的な空間を提供するサービスの一つです。 SpatialChat や oVice などと同種のサービスですが、古き良き2D- RPG を彷彿とさせる可愛らしいキャ ラク ターやマップのデザインが、それらとの大きな相違点の一つです。 マップ上で近い場所にいるメンバーや、同じ部屋や机の島にいるメンバー（こちらに関しては設定が必要ですが）にのみ音声が届くため、 Teams や Zoom での通話と異なり、「ふとしたタイミング」で「ちょっとした会話」をする、といったことがしやすいです。 料金については こちら を参照していただければと思いますが、同時接続ユーザ数が25名以下であれば、マップの数や広さに関係なく無料で利用できるので、使い始めるための金銭的なハードルが非常に低くなっています。 どういうルールで運用している？ 基本ルールとしては、以下の4つがあります。 スペース内のどこにいてもOK いつでも会話やチャットOK 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない ルールといっても、何かを制限したり強制したりといったことはほとんどしておらず、毎朝のログインすらも強制ではなく推奨としています。 スペース内のどこにいてもOK こちらは文字どおり、どこにいても（キャ ラク ターを移動させても）OKというものです。 私たちのスペースには、机や会議室が配置されている「オフィス」だけでなく、歓迎会などを開催するための「屋上」や、ワーケーション気分を味わうことができる「南国」などが存在します。 そのため、常に「オフィス」にいる必要はないですよ、というのがこちらのルールになります。 いつでも会話やチャットOK こちらも文字どおりです。 ただし、業務で扱う情報の中でも機密度が高いものに関しては、基本的にGatherでは扱わないこととしています。 会話できない／したくないときはDo Not DisturbモードやFocusエリアを利用する Gatherには、Do Not Disturbモードというモードが存在します。 このモードでは、自分の音声も周囲に届かず、周囲の音声も自分には届かないようになります。 そのため、TeamsやZoomでの会議中や、作業に集中したいタイミングなど、会話できない／したくないときにこのモードを利用することになります。 また、私たちのスペースには、Focusエリアという個人ブースのような場所を複数設置しています。 このエリアも同様に、会話できない／したくないときに利用することを想定しています。 なお、Do Not Disturbモードとの相違点としては、真後ろ1マスにいるメンバーに対しては、お互いの音声が届く仕様となっている点が挙げられます。 Do Not DisturbモードやFocusエリアを利用しているメンバーには話しかけない 上述のDo Not DisturbモードやFocusエリアを利用しているメンバーは、基本的には会話できない／したくない状態です。 そのため、これらを利用しているメンバーには話しかけないようにしましょう、というのがこちらのルールです。 （Do Not Disturbモードに関してはそもそも話しかけても音声は届きませんが） Teamsとの使い分けは？ 弊社では、コミュニケーションツールとしてTeamsを全社利用しています。 そのため、現在は以下のような目安でTeamsとGatherを使い分けています。 とはいえ、あくまで目安ですので、Teamsで雑談会が開催されていたりもします。 Teams Gather 他部署の社員が参加する打ち合わせ 事前にスケジュールされた打ち合わせ 特定のTeamsチャネルに紐づいた打ち合わせ 左記以外の打ち合わせ ちょっとした確認、依頼 雑談 アクセス制限はどうしている？ 私たちのスペースでは、 Guest List Only Access 機能を利用したアクセス制限を実施しています。 この機能は ホワイトリスト 方式になっていて、Gatherにログインしているユーザの中でも、リストにメールアドレスが登録されているユーザのみにスペースへのアクセスを許可できます。 これにより、万が一スペースのURLが漏れてしまった場合にも、部外者がスペースに侵入することのないように設定しています。 導入してみてどう？ 良かった点 大きく以下の3点が挙げられます。 グループ間を超えるコミュニケーションが増加した 「ちょっと話しかける」がしやすくなった 中途入社の不安を緩和できる グループ間を超えるコミュニケーションが増加した 私が所属しているソフトウェアデザインセンターの開発技術グループでは、毎朝グループ内で朝会（デイリー スタンドアップ ）を実施しています。 そのため、Gather導入以前にも、グループ内のメンバーに対しては、朝会の中でコミュニケーションをとる機会がありました。 しかしながら、隣のグループであるセキュリティグループの方々とは、たまたま同じ打ち合わせに参加する、といったことがない限りは、雑談はおろか挨拶を交わす機会すらありませんでした。 もちろん、Teamsで個人チャットを送るなどすれば会話自体はできるものの、特に業務上の要件がないのに個人チャットを送るのはなかなかハードルが高いものです。 このあたりは読者の皆さんも共感していただけるのではないかと思います。 そのような状態だったのですが、Gather導入後は、近くにいる社員に、開発技術グループ、セキュリティグループ関係なく挨拶をする、といった機会が生まれました。 そこから少し雑談をしてみたり、といったこともあります。 これによって、セキュリティグループの方々とも一定の交流をもつことができ、個人的には親近感も湧きやすくなったと感じています。 これは、これまでのTeamsでは発生し得なかったコミュニケーションだと思います。 「ちょっと話しかける」がしやすくなった 前項と類似していますが、「ちょっと話しかける」といったことがしやすくなったと感じます。 例えば、「ちょっとこれ見てください！」「ちょっとここ教えてください！」といった要件をリアルタイムで相手に伝えられるため、チャットでやり取りするよりも快適なことが多いです。 また、業務の隙間時間などに突発的に始まり、周りにいる人にも会話内容が少し聞こえて、そのままふらっと会話に参加できる、そんな形の雑談が発生しやすくなりました。 「この時間に雑談しましょう！」とスケジューリングして行う雑談ももちろん雑談ではあると思うのですが、個人的にはそれに比べてより自然な形での雑談ができているなと感じています。 中途入社の不安を緩和できる カジュアル面談や 中途採用 面接の際にGatherの実際の様子をお見せすると、好反応をいただけることが多いです。 リモートワークが主体となったこの時代の転職は、やはりコミュニケーション面に不安を覚える方が多いということで、このような取り組みで少しでもその不安を緩和できればと思います。 なお、実際に最近のソフトウェアデザインセンターの中途入社メンバーからは以下のような声をいただいています。 何か不明点を確認したり気分転換をしたりしたいときにGatherにログインし、手が空いていそうな方に話しかけている。Teamsのチャットでは相手の忙しさが分からないため、画面上で動きを把握できるのは良いと思う。 とにかく何気ない会話がしやすい。雑談からの流れで何かを尋ねやすい。 一人で働いているのではなく、チームで働いている感覚をもてる。 物理オフィスであれば自然と目にする、耳にするであろう情報に近い情報を得られる。例えば、ステータスや居場所を確認することで周囲の方の状況が分かる。また、自分が会話をせずとも、周囲の方同士の会話を聞くことで、業務状況や人となりなどを知ることができる。 課題点 8月末から導入して、現在2か月ほど経過しましたが、課題としては大きく以下の3点が挙げられます。 Do Not Disturbモードやマイクオフにし忘れると音声が漏れる Gather用のディスプレイがないと使いにくい 話しかけたい人がログインしているとは限らない Do Not Disturbモードやマイクオフにし忘れると音声が漏れる これはGatherの課題点というよりはTeamsとGatherを併用する際の課題点ですが、Gatherにログインした状態でTeamsでの会議に参加すると、Do Not Disturbモードやマイクオフにしない限り、会議の音声がGather上に流れてしまうリスクがあります。 独り言を垂れ流すだけならば問題ない（垂れ流してしまった側の気分的には問題ですが…笑）のですが、会議の音声の場合、内容によっては機密情報が漏れてしまうおそれもあるので、注意が必要です。 そのため、万が一Do Not Disturbモードやマイクオフにし忘れてしまったときのためにも、会議中はFocusエリアに移動することを推奨しています。 Gather用のディスプレイがないと使いにくい 普段の業務をノートPCのディスプレイのみで行っている場合、Gatherの画面を常には表示しておけません。 そのため、Gatherを利用していてもあまりバーチャルオフィス感がなく、突然話しかけられるとテンパってしまう、といった声もありました。 話しかけたい人がログインしているとは限らない 現状では特にログインを強制していないため、話しかけたい人がログインしているとは限りません。 とはいえ、こちらは運用のルール次第ではあるので、今後検討の余地はあります。 おわりに 本記事では、X イノベーション 本部内の部署にGatherを導入した話について簡単にまとめました。 コミュニケーション活性化に有用で、見た目も可愛く、無料で始められるバーチャルオフィスサービスGather、ぜひ皆さんの部署にも導入してみませんか？ Gatherの回し者みたいになってしまいましたが、最後までお読みいただき、本当にありがとうございました！ 私たちは同じ事業部で共に働いていただける仲間を募集しています！ 「入社直後の右も左も分からない状態でのオンラインコミュニケーション」に対する不安をGatherで緩和できればと考えていますので、ご興味のある方、ぜひご応募お待ちしています！ フルサイクルエンジニア 執筆： @miyazawa.hibiki 、レビュー： @yamada.y （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionの呪文シリーズ、今回は、 美少女アニメ 画改善版です。 以前、 美少女写真編 の記事を書いたのですが、あのときの問題点は、再現性が低いことでした。自分が納得する結果を出すのに、何十回もリトライを繰り返さなければならなかったのです。 今回の改善版では、単にかわいい美少女を出力するだけなら、8割ほどの確率で出力できます。「かわいい」の感覚は人それぞれですが、僕の感覚だとそれくらいの確率だということです。 厳選した画像を紹介しますが、厳選と言っても一つの画像を選ぶのに10回はかかっていません。 v2.1 美少女アニメ画 もよろしければ、御覧ください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 改善呪文 anime of tsundere moe kawaii beautiful pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render digital painting extremely detailed sharp focus cinematic postprocessing 出力結果 まとめ 仲間募集 Stable Diffusionの全コンテンツ 改善呪文 横長、コピー&ペースト用 anime of tsundere moe kawaii beautiful girl　pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render 改行版 anime of tsundere moe kawaii beautiful girl pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render 改良前版（対比しやすいように順番は入れ替えました） japanese anime of a beaultiful girl pixiv light novel fantasy costume fantasy background beautiful composition cinematic lighting ray tracing 8k digital painting extremely detailed sharp focus cinematic postprocessing anime of 前回は、 japanese をつけていたのですが、比較テストしたところ、 japanese をつけないほうが、良い結果が出ました。 tsundere moe kawaii beautiful 前回は、 beautiful だけだったのですが、 tsundere moe kawaii を足すと「ちょっと」結果が良くなるようです。これは「思い込み」かもしれません。 pixiv niconico artstation deviantart newgrounds tumblr 今回、一番効果が大きかった「作風」の部分です。 前回は、 pixiv に light novel を足していました。 pixiv だけだと効果が少なかったためです。しかし、 light novel もそれほど効果のない呪文だったので、出力結果のクオリティがバラバラでした。 今回、効果の薄かった light novel を削り、 niconico artstation deviantart newgrounds tumblr を足したところ、出力結果がかなり安定するようになりました。 イラストの投稿サイトの中で、テストして結果が良かったサイトを残しました。 fantasy scene fantasy composition fantasy lighting 前回は、 costume と background を指定していましたが、これはざっくり scene で良いようです。 scene 、 composition 、 lighting の修飾語を fantasy に変えた結果、思い切りファンタ ジー な雰囲気になりました。修飾語は好みで変えてください。 PlayStation5 octane render 前回は、 ray tracing 8k を指定していましたが、 octane render のほうが、フォトリアルにする効果が高いようです。 PlayStation5 は、フォトリアルにするだけでなく、アニメのクオリティにも良い効果を与えるようです。 digital painting extremely detailed sharp focus cinematic postprocessing extremely detailed をつけると人物が大きく描画され、バランスの悪い構図になる確率が増えるので、今回は削りました。 digital painting sharp focus cinematic postprocessing は、テストした結果、明確な効果が感じられなかったため削りました。 出力結果 出力結果はこちらになります。 まとめ 美少女アニメ 画の出力結果の安定性（再現性）を改善したのは、イラストの投稿サイトの数を増やしたことでした。みなさんも、是非試してください。 次回は、 v1.5 美少女画検証 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionの呪文シリーズ、今回は、 美少女アニメ 画改善版です。 以前、 美少女写真編 の記事を書いたのですが、あのときの問題点は、再現性が低いことでした。自分が納得する結果を出すのに、何十回もリトライを繰り返さなければならなかったのです。 今回の改善版では、単にかわいい美少女を出力するだけなら、8割ほどの確率で出力できます。「かわいい」の感覚は人それぞれですが、僕の感覚だとそれくらいの確率だということです。 厳選した画像を紹介しますが、厳選と言っても一つの画像を選ぶのに10回はかかっていません。 v2.1 美少女アニメ画 もよろしければ、御覧ください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 改善呪文 anime of tsundere moe kawaii beautiful pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render digital painting extremely detailed sharp focus cinematic postprocessing 出力結果 まとめ 仲間募集 Stable Diffusionの全コンテンツ 改善呪文 横長、コピー&ペースト用 anime of tsundere moe kawaii beautiful girl　pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render 改行版 anime of tsundere moe kawaii beautiful girl pixiv niconico artstation deviantart newgrounds tumblr fantasy scene fantasy composition fantasy lighting PlayStation5 octane render 改良前版（対比しやすいように順番は入れ替えました） japanese anime of a beaultiful girl pixiv light novel fantasy costume fantasy background beautiful composition cinematic lighting ray tracing 8k digital painting extremely detailed sharp focus cinematic postprocessing anime of 前回は、 japanese をつけていたのですが、比較テストしたところ、 japanese をつけないほうが、良い結果が出ました。 tsundere moe kawaii beautiful 前回は、 beautiful だけだったのですが、 tsundere moe kawaii を足すと「ちょっと」結果が良くなるようです。これは「思い込み」かもしれません。 pixiv niconico artstation deviantart newgrounds tumblr 今回、一番効果が大きかった「作風」の部分です。 前回は、 pixiv に light novel を足していました。 pixiv だけだと効果が少なかったためです。しかし、 light novel もそれほど効果のない呪文だったので、出力結果のクオリティがバラバラでした。 今回、効果の薄かった light novel を削り、 niconico artstation deviantart newgrounds tumblr を足したところ、出力結果がかなり安定するようになりました。 イラストの投稿サイトの中で、テストして結果が良かったサイトを残しました。 fantasy scene fantasy composition fantasy lighting 前回は、 costume と background を指定していましたが、これはざっくり scene で良いようです。 scene 、 composition 、 lighting の修飾語を fantasy に変えた結果、思い切りファンタ ジー な雰囲気になりました。修飾語は好みで変えてください。 PlayStation5 octane render 前回は、 ray tracing 8k を指定していましたが、 octane render のほうが、フォトリアルにする効果が高いようです。 PlayStation5 は、フォトリアルにするだけでなく、アニメのクオリティにも良い効果を与えるようです。 digital painting extremely detailed sharp focus cinematic postprocessing extremely detailed をつけると人物が大きく描画され、バランスの悪い構図になる確率が増えるので、今回は削りました。 digital painting sharp focus cinematic postprocessing は、テストした結果、明確な効果が感じられなかったため削りました。 出力結果 出力結果はこちらになります。 まとめ 美少女アニメ 画の出力結果の安定性（再現性）を改善したのは、イラストの投稿サイトの数を増やしたことでした。みなさんも、是非試してください。 次回は、 v1.5 美少女画検証 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、 Amazon Web Services ( AWS )のApplication LoadBalancer(ALB)とgRPCを合わせて利用する場合の方法について紹介します。 ALBでgRPCのサポートされて利用できる場所が広がりつつあります。 https://aws.amazon.com/jp/blogs/aws/new-application-load-balancer-support-for-end-to-end-http-2-and-grpc/ 今回は、このALBとgRPCを組み合わせて利用する場合の設定方法とその注意点について紹介します。 ターゲットグループの作成時に注意が必要 gRPCは基本的に通常の HTTPS 通信です。このためALB自体は普段通りの設定で作成して問題ありません。gRPCを利用する場合はターゲットグループを作成するときに、以下のようにProtocolには HTTPS を指定し、Protocol Versionの設定をgRPCに変更することで利用できます。 ヘルスチェック用のサービスを実装しておく ヘルスチェックの項目では、gRPCのサービスを呼びだす設定が必要です。このため、実際にALBを利用することを想定する場合は、アプリケーション側でヘルスチェック用のサービスを実装する必要があります。 gRPCのKeepAlive機能が利用できない gRPCには通信を途絶させないためのKeepAliveの機能が実装されています。しかし、ALBはこのパケットが到達しても後続のサービスにはそれを渡さない実装となっているようです。このため、gRPCの機能のkeepAlive機能を設定しても通信が切断されてしまいます。 この問題は、Unary RPCのように短時間で終了するサービスであれば問題にならないことが多いです。しかしBidirecional Streaming RPCのようにコネクションを保ったまま通信を行う場合に通信の途中で切断される場合があります。このため、プログラム側でサーバ向けに定期的にパケットを送り続けるような工夫を行う必要があります。 パスによるアクセス制限などの方法は問題なく利用できます gRPCは通常のHTTP/2の プロトコル を利用しており、通常のHTTPで実施するアクセス先(path)による制限などを実施できます。 /<package名>.<Service名>/<rpc名> といったpathを指定することで特定のRPCだけアクセスを拒否できます。 以下の図のように設定することで、 /foo.Bar/Baz というRPCだけ503エラーを返すように設定できます。 認証などの設定も同様に行うことが可能です。 まとめ 今回は、 AWS のALBとgRPCを組み合わせる際に注意が必要になる点についてまとめました。ただし、keepAliveが利用できなかったり、ヘルスチェック専用のサービスが必要となるなど、いくつか注意点がありますが問題なく利用できました。 これからは、積極的にgRPCを活用していきたいですね。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @higa （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター の山下です。 今回は、 Amazon Web Services ( AWS )のApplication LoadBalancer(ALB)とgRPCを合わせて利用する場合の方法について紹介します。 ALBでgRPCのサポートされて利用できる場所が広がりつつあります。 https://aws.amazon.com/jp/blogs/aws/new-application-load-balancer-support-for-end-to-end-http-2-and-grpc/ 今回は、このALBとgRPCを組み合わせて利用する場合の設定方法とその注意点について紹介します。 ターゲットグループの作成時に注意が必要 gRPCは基本的に通常の HTTPS 通信です。このためALB自体は普段通りの設定で作成して問題ありません。gRPCを利用する場合はターゲットグループを作成するときに、以下のようにProtocolには HTTPS を指定し、Protocol Versionの設定をgRPCに変更することで利用できます。 ヘルスチェック用のサービスを実装しておく ヘルスチェックの項目では、gRPCのサービスを呼びだす設定が必要です。このため、実際にALBを利用することを想定する場合は、アプリケーション側でヘルスチェック用のサービスを実装する必要があります。 gRPCのKeepAlive機能が利用できない gRPCには通信を途絶させないためのKeepAliveの機能が実装されています。しかし、ALBはこのパケットが到達しても後続のサービスにはそれを渡さない実装となっているようです。このため、gRPCの機能のkeepAlive機能を設定しても通信が切断されてしまいます。 この問題は、Unary RPCのように短時間で終了するサービスであれば問題にならないことが多いです。しかしBidirecional Streaming RPCのようにコネクションを保ったまま通信を行う場合に通信の途中で切断される場合があります。このため、プログラム側でサーバ向けに定期的にパケットを送り続けるような工夫を行う必要があります。 パスによるアクセス制限などの方法は問題なく利用できます gRPCは通常のHTTP/2の プロトコル を利用しており、通常のHTTPで実施するアクセス先(path)による制限などを実施できます。 /<package名>.<Service名>/<rpc名> といったpathを指定することで特定のRPCだけアクセスを拒否できます。 以下の図のように設定することで、 /foo.Bar/Baz というRPCだけ503エラーを返すように設定できます。 認証などの設定も同様に行うことが可能です。 まとめ 今回は、 AWS のALBとgRPCを組み合わせる際に注意が必要になる点についてまとめました。ただし、keepAliveが利用できなかったり、ヘルスチェック専用のサービスが必要となるなど、いくつか注意点がありますが問題なく利用できました。 これからは、積極的にgRPCを活用していきたいですね。 私たちは同じチームで働いてくれる仲間を探しています。今回のエントリで紹介したような仕事に興味のある方、ご応募お待ちしています。 ソリューションアーキテクト 執筆： @yamashita.tsuyoshi 、レビュー： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusion（というよりdiffusers）でTPU（JAX / Flax）を使った並列実行バージョンがリリースされたので、早速試してみました。 オリジナルのNotebook はこちら。 僕が作ったNotebook はこちら。 今回は、TPUを使うので、 Google Colabに特化しています。自分で１から試す方は、メニューのEdit -> Notebook settingsでTPUを使うように設定してください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 必要なモジュールのインストール 必要なモジュールのインポート huggingfaceにログイン pipelineとparamsの作成 show_images()の定義 show_images()の実行 まとめ 仲間募集 Stable Diffusionの全コンテンツ 必要なモジュールのインストール 次のようにして必要なモジュールをインストールします。 !pip install --upgrade jax jaxlib !pip install flax transformers ftfy !pip install diffusers==0.5.1 必要なモジュールのインポート 次のようにして必要なモジュールをインポートします。 import jax.tools.colab_tpu jax.tools.colab_tpu.setup_tpu('tpu_driver_20221011') import jax import numpy as np import jax import jax.numpy as jnp from pathlib import Path from jax import pmap from flax.jax_utils import replicate from flax.training.common_utils import shard from PIL import Image from IPython.display import display import random from huggingface_hub import notebook_login from diffusers import FlaxStableDiffusionPipeline huggingfaceにログイン huggingfaceにログインします。 まだ、huggingfaceの トーク ンを取得していない場合は、 huggingface でユーザー登録を行い、 トーク ンを取得してください。 if not (Path.home()/'.huggingface'/'token').exists(): notebook_login() pipelineとparamsの作成 次のようにして、pipelineとparamsを作成します。 pipeline, params = FlaxStableDiffusionPipeline.from_pretrained( "CompVis/stable-diffusion-v1-4", revision="bf16", dtype=jnp.bfloat16, ) show_images()の定義 呪文から、画像を生成するための関数を作成します。現状のColabでは、TPUは、8個まで並列実行できます。 def show_images(prompt): seed = random.randrange(1000000) rng = jax.random.PRNGKey(seed) rng = jax.random.split(rng, jax.device_count()) p_params = replicate(params) prompt = [prompt] * jax.device_count() prompt_ids = pipeline.prepare_inputs(prompt) prompt_ids = shard(prompt_ids) images = pipeline(prompt_ids, p_params, rng, jit=True)[0] images = images.reshape((jax.device_count(), ) + images.shape[-3:]) images = pipeline.numpy_to_pil(images) for image in images: display(image) オリジナルのNotebookでは、8つの画像がGridになっていて、個別にダウンロードできないので、個別にダウンロードできるようにしてみました。 show_images()の実行 次の呪文で、show_images()を実行してみました。 prompt = "illustration of beaultiful girl detailed beautiful face detailed perfect pupil of eyes detailed mouth detailed shoulders detailed chest highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition cinematic lighting ray tracing 8k" show_images(prompt) 今回の呪文（横長、コピー&ペースト用） illustration of beaultiful girl detailed beautiful face detailed perfect pupil of eyes detailed mouth detailed shoulders detailed chest highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition cinematic lighting ray tracing 8k 閲覧用呪文（改行版） illustration of beaultiful girl detailed beautiful face detailed perfect pupil of eyes detailed mouth detailed shoulders detailed chest highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition cinematic lighting ray tracing 8k 画像出力結果 全く選別していない、出力されたそのままの画像です。 まとめ Stable Diffusionが8つの画像を同時生成できるようになったのは、画期的ではないでしょうか。しかも、TPUを使うので、 GPU を使い切っていても使うことができるのです。実際僕は、 Google Colab Proの GPU を現在使い切ってしまっていて、 GPU を使うことはできないのですが、TPUは使えました。 追記: その後、あっという間に、TPUの無料枠分を使い切ってしまいました。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusion（というよりdiffusers）でTPU（JAX / Flax）を使った並列実行バージョンがリリースされたので、早速試してみました。 オリジナルのNotebook はこちら。 僕が作ったNotebook はこちら。 今回は、TPUを使うので、 Google Colabに特化しています。自分で１から試す方は、メニューのEdit -> Notebook settingsでTPUを使うように設定してください。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 必要なモジュールのインストール 必要なモジュールのインポート huggingfaceにログイン pipelineとparamsの作成 show_images()の定義 show_images()の実行 まとめ 仲間募集 Stable Diffusionの全コンテンツ 必要なモジュールのインストール 次のようにして必要なモジュールをインストールします。 !pip install --upgrade jax jaxlib !pip install flax transformers ftfy !pip install diffusers==0.5.1 必要なモジュールのインポート 次のようにして必要なモジュールをインポートします。 import jax.tools.colab_tpu jax.tools.colab_tpu.setup_tpu('tpu_driver_20221011') import jax import numpy as np import jax import jax.numpy as jnp from pathlib import Path from jax import pmap from flax.jax_utils import replicate from flax.training.common_utils import shard from PIL import Image from IPython.display import display import random from huggingface_hub import notebook_login from diffusers import FlaxStableDiffusionPipeline huggingfaceにログイン huggingfaceにログインします。 まだ、huggingfaceの トーク ンを取得していない場合は、 huggingface でユーザー登録を行い、 トーク ンを取得してください。 if not (Path.home()/'.huggingface'/'token').exists(): notebook_login() pipelineとparamsの作成 次のようにして、pipelineとparamsを作成します。 pipeline, params = FlaxStableDiffusionPipeline.from_pretrained( "CompVis/stable-diffusion-v1-4", revision="bf16", dtype=jnp.bfloat16, ) show_images()の定義 呪文から、画像を生成するための関数を作成します。現状のColabでは、TPUは、8個まで並列実行できます。 def show_images(prompt): seed = random.randrange(1000000) rng = jax.random.PRNGKey(seed) rng = jax.random.split(rng, jax.device_count()) p_params = replicate(params) prompt = [prompt] * jax.device_count() prompt_ids = pipeline.prepare_inputs(prompt) prompt_ids = shard(prompt_ids) images = pipeline(prompt_ids, p_params, rng, jit=True)[0] images = images.reshape((jax.device_count(), ) + images.shape[-3:]) images = pipeline.numpy_to_pil(images) for image in images: display(image) オリジナルのNotebookでは、8つの画像がGridになっていて、個別にダウンロードできないので、個別にダウンロードできるようにしてみました。 show_images()の実行 次の呪文で、show_images()を実行してみました。 prompt = "illustration of beaultiful girl detailed beautiful face detailed perfect pupil of eyes detailed mouth detailed shoulders detailed chest highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition cinematic lighting ray tracing 8k" show_images(prompt) 今回の呪文（横長、コピー&ペースト用） illustration of beaultiful girl detailed beautiful face detailed perfect pupil of eyes detailed mouth detailed shoulders detailed chest highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition cinematic lighting ray tracing 8k 閲覧用呪文（改行版） illustration of beaultiful girl detailed beautiful face detailed perfect pupil of eyes detailed mouth detailed shoulders detailed chest highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition cinematic lighting ray tracing 8k 画像出力結果 全く選別していない、出力されたそのままの画像です。 まとめ Stable Diffusionが8つの画像を同時生成できるようになったのは、画期的ではないでしょうか。しかも、TPUを使うので、 GPU を使い切っていても使うことができるのです。実際僕は、 Google Colab Proの GPU を現在使い切ってしまっていて、 GPU を使うことはできないのですが、TPUは使えました。 追記: その後、あっという間に、TPUの無料枠分を使い切ってしまいました。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの全コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回のテーマは バベルの塔 のイラストです。 今回は建物のイラストの呪文を学びましょう。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 steampunk illustration of babel tower highly detailed shot from above steampunk illustration of babel tower shot from below steampunk illustration of babel tower highly detailed steampunk illustration of illuminated babel tower highly detailed top shot from below night まとめ 仲間募集 Stable Diffusionの過去コンテンツ steampunk illustration of babel tower highly detailed shot from above steampunkは、 蒸気機関 が高度に発達したレトロなアニメの世界を召喚する呪文です。詳しく知りたい方は 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 を参照してください。 steampunkのイラストは、通常のイラストより、クオリティが高いことが多いため、描画対象がsteampunkの世界観にあっているときは、積極的に利用しましょう。 babel towerが バベルの塔 です。 highly detailedで、描画対象を詳細に描画します。 shot from aboveで、上の方から描画します。 建物は、一般的に地味であることが多い（ バベルの塔 は派手ですが）ので、建物を描画するときは、通常と違うアングルを選びましょう。人は見たことのないものに心惹かれます。 特に高い建物を上から描画するためには、カメラを空中に配置する必要があります。ほとんどの人にとってリアルに体験したことのないアングルです。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower highly detailed shot from above artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower highly detailed shot from above artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 steampunkをつけていない通常のイラスト これも良いですね。ただ、これを出力するのに、何十回もトライしました。 steampunk illustration of babel tower shot from below shot from belowで下から描画します。highly detailedがないことに注目してください。下から描画する場合、highly detailedがあると、 バベルの塔 に近づきすぎて、うまく描画できません。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower shot from below artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower shot from below artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 shot from belowで塔を描画する場合、空が描画されます。空のクオリティが高いこともチェックポイントに入れてください。 highly detailed shot from belowの出力結果 highly detailedで バベルの塔 に近づきすぎているので、shot from belowの呪文の効果がほとんどないことがわかります。 steampunk illustration of babel tower highly detailed 今度は、shot from aboveもshot from belowもない、通常アングルのイラストも見てみましょう。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 highly detailed shot from belowのものとほとんど同じですね。これが通常のアングルです。 shot from aboveとshot from belowの画像と比較して、アングルの違いを実感しましょう。 steampunk illustration of illuminated babel tower highly detailed top shot from below night 応用もやっておきましょう。 建物にilluminatedで照明を当てて、時間を夜（night）にしてみましょう。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of illuminated babel tower highly detailed shot from below night artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of illuminated babel tower highly detailed shot from below night artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 まとめ 今回は、建物のイラストを退屈なものにしないために、shot from above（上から描画）、shot from below（下から描画）の呪文を学びました。 次回は、 美少女アニメ画改善版編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの過去コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回のテーマは バベルの塔 のイラストです。 今回は建物のイラストの呪文を学びましょう。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 steampunk illustration of babel tower highly detailed shot from above steampunk illustration of babel tower shot from below steampunk illustration of babel tower highly detailed steampunk illustration of illuminated babel tower highly detailed top shot from below night まとめ 仲間募集 Stable Diffusionの過去コンテンツ steampunk illustration of babel tower highly detailed shot from above steampunkは、 蒸気機関 が高度に発達したレトロなアニメの世界を召喚する呪文です。詳しく知りたい方は 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 を参照してください。 steampunkのイラストは、通常のイラストより、クオリティが高いことが多いため、描画対象がsteampunkの世界観にあっているときは、積極的に利用しましょう。 babel towerが バベルの塔 です。 highly detailedで、描画対象を詳細に描画します。 shot from aboveで、上の方から描画します。 建物は、一般的に地味であることが多い（ バベルの塔 は派手ですが）ので、建物を描画するときは、通常と違うアングルを選びましょう。人は見たことのないものに心惹かれます。 特に高い建物を上から描画するためには、カメラを空中に配置する必要があります。ほとんどの人にとってリアルに体験したことのないアングルです。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower highly detailed shot from above artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower highly detailed shot from above artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 steampunkをつけていない通常のイラスト これも良いですね。ただ、これを出力するのに、何十回もトライしました。 steampunk illustration of babel tower shot from below shot from belowで下から描画します。highly detailedがないことに注目してください。下から描画する場合、highly detailedがあると、 バベルの塔 に近づきすぎて、うまく描画できません。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower shot from below artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower shot from below artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 shot from belowで塔を描画する場合、空が描画されます。空のクオリティが高いこともチェックポイントに入れてください。 highly detailed shot from belowの出力結果 highly detailedで バベルの塔 に近づきすぎているので、shot from belowの呪文の効果がほとんどないことがわかります。 steampunk illustration of babel tower highly detailed 今度は、shot from aboveもshot from belowもない、通常アングルのイラストも見てみましょう。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of babel tower highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of babel tower highly detailed artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 highly detailed shot from belowのものとほとんど同じですね。これが通常のアングルです。 shot from aboveとshot from belowの画像と比較して、アングルの違いを実感しましょう。 steampunk illustration of illuminated babel tower highly detailed top shot from below night 応用もやっておきましょう。 建物にilluminatedで照明を当てて、時間を夜（night）にしてみましょう。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of illuminated babel tower highly detailed shot from below night artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of illuminated babel tower highly detailed shot from below night artstation deviantart concept art award winning fantasy scene fantasy composition fantasy lighting 出力結果 まとめ 今回は、建物のイラストを退屈なものにしないために、shot from above（上から描画）、shot from below（下から描画）の呪文を学びました。 次回は、 美少女アニメ画改善版編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの過去コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）

はいどーもー！ X イノベーション 本部の宮澤響です！ X イノベーション 本部では、有志メンバーで論文輪読会を月次開催しています。 （詳細は こちらの記事 をご参照ください） 本記事では、私が担当した先日の論文輪読会で紹介した論文について、箇条書きベースでごくごく簡単にまとめます！ どんな論文？ 論文内容紹介 目的 手法 実験参加者 実験に用いたテキスト 実験手順 結果 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 考察 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 限界と今後の課題 結論 個人的な感想など この論文を題材に選んだきっかけ 論文内容に関して まとめ どんな論文？ 書誌情報は以下です。 Anam Ahmad Khan, Sadia Nawaz, Joshua Newn, Ryan M. Kelly, Jason M. Lodge, James Bailey, and Eduardo Velloso. 2022. To type or to speak? The efect of input modality on text understanding during note-taking. In CHI Conference on Human Factors in Computing Systems (CHI ’22), April 29-May 5, 2022, New Orleans, LA, USA. ACM , New York, NY, USA, 15 pages. https://doi.org/10.1145/3491102.3501974 一言で言えば、ノートのとり方（キーボードと音声のどちらでノートをとるか）が文章理解に与える影響について検討した論文です。 論文の全体像を1枚にまとめたスライドがこちらです。 なお、こちらは「落合メソッド」「落合フォーマット」などと呼ばれる論文のまとめ方（ 参考 ）を簡略化したものです。 論文内容紹介 ここから実際に論文の内容を大まかなセクションごとに紹介します。 目的 以下のリサーチク エス チョン（以下、RQ）を明らかにすることを目的としています。 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 手法 2つのテキストに対してキーボードまたは音声でノートをとってもらい、テキストの内容についての理解度テストを実施するという実験を実施しました。 実験参加者 実験参加者は、以下のような属性をもつ、オーストラリアの大学院生60名でした。 属性 内訳 年齢 21～35歳（平均年齢27.04歳） 性別 男性31名、女性29名 母語 英語16名、イタリア語3名、中国語15名、 ウルドゥー語 4名、 ヒンディー語 5名、 ペルシャ語 7名、 シンハラ語 6名、韓国語2名 学歴 修士 課程在籍者29名、博士課程在籍者31名 実験に用いたテキスト 実験には、以下の2つのテキストを使用しました。 ブレーキに関する英語の文章（792語） ポンプに関する英語の文章（850語） 実験手順 実験は、全てオンラインで、下図のような流れで実施されました。 Briefing・Demo 実験の説明 ノートをとる操作の実演、練習 Pre-test テキストに関する予備知識を測定するためのテスト 多肢選択問題6問 4つの正答候補＋“I don’t know”の計5択 Note taking task テキストを読んでノートをとるタスク 2つのConditionで異なるテキストを使用 ブレーキ ポンプ 2つのConditionで異なる入力形式を利用 キーボード 音声 時間制限なし Survey 主観的な項目として以下を報告 確信度 Post-testで正答できる自信がどれくらいあるか（0～100） 関心度 テキストの内容にどれくらい関心をもてるか（1～7） 難易度 テキストの内容がどれくらい難しいと感じるか（1～7） Distracting task 指定された数から7ずつ減算していく過程を報告するタスク 2分間 Condition1では200から 200、193、186、… Condition2では203から 203、196、189、… Post-test テキストの理解度を測定するためのテスト 事実問題12問（多肢選択） 1つのア イデア ユニット（「軽自動車はこの種類をブレーキを使っている」、「この村ではこのポンプが使われている」などの「○○が××だ」のような命題の単位）に関する問題 4つの正答候補＋“I don’t know”の計5択 推論問題6問（多肢選択） 2つ以上のア イデア ユニットに関する問題 4つの正答候補＋“I don’t know”の計5択 Interview・Debrief 操作感などに関するインタビュー 全体のまとめ 結果 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ キーボードでノートをとった場合と音声でノートをとった場合のPost-testの成績（以下、成績）の間に有意差は見られませんでした。 ノートのとり方（キーボード、音声）と問題種別（事実問題、推論問題）の間の交互作用が有意でした。そのため、一対比較を実施したところ、以下の結果が得られました。 ノートのとり方に関して キーボード：事実問題の成績が推論問題の成績よりも有意に高い 音声：事実問題と推論問題の成績の間に有意差なし 問題種別に関して 事実問題：キーボードと音声の成績の間に有意差なし 推論問題：音声の成績がキーボードの成績よりも有意に高い RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ 音声でとったノートに含まれるア イデア ユニットの数が、キーボードでとったノートに含まれるア イデア ユニットの数よりも有意に多いことが分かりました。 音声でとったノートに含まれるエラボレーション（例、類推、個人的な経験）の数が、キーボードでとったノートに含まれるエラボレーションの数よりも有意に多いことが分かりました。 ノートのとり方が成績に与える直接効果は有意であることが分かりました。 ア イデア ユニットの数を媒介としてノートのとり方が成績に与える間接効果は有意であることが分かりました。 エラボレーションの数を媒介としてノートのとり方が成績に与える間接効果は有意ではないことが分かりました。 RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ キーボードでノートをとった場合と音声でノートをとった場合のメタ理解の正確性（確信度と成績の差の絶対値）の間に有意差は見られませんでした。 RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 参加者の意見をグルーピングした結果、以下のように6カテゴリーの利点と5カテゴリーの課題が浮かび上がりました。 利点 簡便な入力 瞬間的な思考の記録 共同的なノート作成 リハーサルと エンコード 内容への注意 能動的な説明と反映 課題 録音と再生 編集 検索と見直し 構造化とスケッチ 共有空間での利用 考察 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ 音声でノートをとることは、テキストの情報に基づく推論を手助けし、情報を横断してア イデア やコンセプトを結びつけている可能性が示唆されました。 推論問題では複数のア イデア ユニットを結びつける必要があり、テキストに対する概念的な理解が試される可能性が示唆されました。 音声でとったノートに関して、「音声でとったノートはより多くのア イデア ユニットを議論できる→ノートをとりながらテキストについてより良い推論を行える→テキストに対する概念的理解が深まる→推論問題の成績が高くなる」という一連の流れが示唆されました。 RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ 音声でノートをとる際は人称直示詞（人称代名詞）を多く使用するため、仮想の聴衆に話しかけるような、社会的関与が高い内容になる可能性が示唆されました。 社会的関与の高さがより多くのア イデア ユニットの議論とエラボレーションに繋がる可能性が示唆されました。 RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ 音声でノートをとることは、テキストに対する概念的理解を増加させても、学習パフォーマンスの知覚には影響を与えない可能性が示唆されました。 RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 仮想の聴衆に話しかけることで豊かな表現が生まれる可能性が示唆されました。 テキストを読みながら同時にノートをとれるため、学習内容自体に注意を向けやすい可能性が示唆されました。 音声でノートをとることのメリットは、ノートを見直すときよりもノートをとるときの方がより明確になる可能性が示唆されました。 音声でとるノートの利便性はデジタル学習環境で発揮されやすい可能性が示唆されました。 限界と今後の課題 実験の限界と、そこから考えられる今後検討すべき課題は以下のとおりです。 限界 課題 実験に使用したテキストがやや複雑（難易度が高い）だと認識されていた より複雑でないテキストに対して一般化されるかの調査 ノートのとり方が文章理解に与える短期的な影響を調査するに留まった より長期的な影響の調査 キーボードと音声で見直しに要する時間が異なり交絡因子となるおそれがあるため、Post-testの前にノートを見直す時間を設定しなかった 入力（キーボード／音声）と出力（文章／音声）の組み合わせによる実験 大学院生を対象として管理された環境で実施した 異なる参加者集団や、より現実的な環境での実験 音声でとるノートは空間的な構造化を必要としない情報のみしか記録できない 数式や マインドマップ など、視覚的な表現が有効な場合の調査 結論 ノートをとる際の入力形式をキーボードから音声へ変更することで、より多くのア イデア ユニットの議論とエラボレーションを行える可能性が示唆されました。 基本的な知識を得ることが目的であれば、キーボードと音声どちらでノートをとった場合も同じようなパフォーマンスを示す可能性が示唆されました。 推論することによってより深く概念を理解することが目的であれば、音声でノートをとる方がより効果的である可能性が示唆されました。 キーボードと音声どちらでノートをとった場合も、文章理解におけるメタ理解の判断には同程度の効果をもたらす可能性が示唆されました。 音声でとるノートはデジタルテキストの概念的な理解を可能にするため、デジタル学習環境に組み込める可能性が示唆されました。 個人的な感想など この論文を題材に選んだきっかけ この論文を題材に選んだ理由としては、タイトルに惹かれたというのが大きいです。 というのも、私は教育関係の事柄に強い興味をもっています。 また、私は学生時代（ほんの2年半前ですが）、音や音楽に関する研究をしていました。 そのため、「ノートをとる」という部分が私の教育センサーに、「音声」の部分が私の音・音楽センサーに引っかかり、 アブスト ラク トに目を通しても面白そうな内容だったので、今回の論文輪読会の題材としました。 論文内容に関して いわゆる典型的なIMRAD形式（ 参考 ）だったこともあり、論文の構成が分かりやすかったです。 また、なるほど確かにと思える部分が多かったです。 例えば、音声でノートをとる場合はテキストから視線を逸らさずにノートをとれる、音声でとったノートは編集、検索、見直しに課題がある、などは、確かにそうだなぁという感覚でした。 疑問点として、「社会的関与の高さがより多くのア イデア ユニットの議論とエラボレーションに繋がる」というのは、日本語の場合でも同様なのか気になりました。 これは、日本語は英語と違い主語や目的語を省略できるため、理由として考察されていた人称直示詞があまり登場しないのでは、と思ったためです。 まとめ 本記事では、論文輪読会で私が紹介した論文について簡単にまとめました。 論文輪読会は、知見のインプットとアウトプット、両者の力を伸ばせる取り組みですので、皆さんの会社や部署などでも実施してみてはいかがでしょうか？ 最後までお読みいただき、本当にありがとうございました！ 私たちは同じグループで共に働いていただける仲間を募集しています。 現在募集している職種は以下です。 ソリューションアーキテクト 論文輪読会をはじめとした各種勉強会に気軽に参加できるような環境で働くことに興味のある皆様、ぜひご応募お待ちしています！ 執筆： @miyazawa.hibiki 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

はいどーもー！ X イノベーション 本部の宮澤響です！ X イノベーション 本部では、有志メンバーで論文輪読会を月次開催しています。 （詳細は こちらの記事 をご参照ください） 本記事では、私が担当した先日の論文輪読会で紹介した論文について、箇条書きベースでごくごく簡単にまとめます！ どんな論文？ 論文内容紹介 目的 手法 実験参加者 実験に用いたテキスト 実験手順 結果 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 考察 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 限界と今後の課題 結論 個人的な感想など この論文を題材に選んだきっかけ 論文内容に関して おわりに どんな論文？ 書誌情報は以下です。 Anam Ahmad Khan, Sadia Nawaz, Joshua Newn, Ryan M. Kelly, Jason M. Lodge, James Bailey, and Eduardo Velloso. 2022. To type or to speak? The efect of input modality on text understanding during note-taking. In CHI Conference on Human Factors in Computing Systems (CHI ’22), April 29-May 5, 2022, New Orleans, LA, USA. ACM , New York, NY, USA, 15 pages. https://doi.org/10.1145/3491102.3501974 一言で言えば、ノートのとり方（キーボードと音声のどちらでノートをとるか）が文章理解に与える影響について検討した論文です。 論文の全体像を1枚にまとめたスライドがこちらです。 なお、こちらは「落合メソッド」「落合フォーマット」などと呼ばれる論文のまとめ方（ 参考 ）を簡略化したものです。 論文内容紹介 ここから実際に論文の内容を大まかなセクションごとに紹介します。 目的 以下のリサーチク エス チョン（以下、RQ）を明らかにすることを目的としています。 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 手法 2つのテキストに対してキーボードまたは音声でノートをとってもらい、テキストの内容についての理解度テストを実施するという実験を実施しました。 実験参加者 実験参加者は、以下のような属性をもつ、オーストラリアの大学院生60名でした。 属性 内訳 年齢 21～35歳（平均年齢27.04歳） 性別 男性31名、女性29名 母語 英語16名、イタリア語3名、中国語15名、 ウルドゥー語 4名、 ヒンディー語 5名、 ペルシャ語 7名、 シンハラ語 6名、韓国語2名 学歴 修士 課程在籍者29名、博士課程在籍者31名 実験に用いたテキスト 実験には、以下の2つのテキストを使用しました。 ブレーキに関する英語の文章（792語） ポンプに関する英語の文章（850語） 実験手順 実験は、全てオンラインで、下図のような流れで実施されました。 Briefing・Demo 実験の説明 ノートをとる操作の実演、練習 Pre-test テキストに関する予備知識を測定するためのテスト 多肢選択問題6問 4つの正答候補＋“I don’t know”の計5択 Note taking task テキストを読んでノートをとるタスク 2つのConditionで異なるテキストを使用 ブレーキ ポンプ 2つのConditionで異なる入力形式を利用 キーボード 音声 時間制限なし Survey 主観的な項目として以下を報告 確信度 Post-testで正答できる自信がどれくらいあるか（0～100） 関心度 テキストの内容にどれくらい関心をもてるか（1～7） 難易度 テキストの内容がどれくらい難しいと感じるか（1～7） Distracting task 指定された数から7ずつ減算していく過程を報告するタスク 2分間 Condition1では200から 200、193、186、… Condition2では203から 203、196、189、… Post-test テキストの理解度を測定するためのテスト 事実問題12問（多肢選択） 1つのア イデア ユニット（「軽自動車はこの種類をブレーキを使っている」、「この村ではこのポンプが使われている」などの「○○が××だ」のような命題の単位）に関する問題 4つの正答候補＋“I don’t know”の計5択 推論問題6問（多肢選択） 2つ以上のア イデア ユニットに関する問題 4つの正答候補＋“I don’t know”の計5択 Interview・Debrief 操作感などに関するインタビュー 全体のまとめ 結果 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ キーボードでノートをとった場合と音声でノートをとった場合のPost-testの成績（以下、成績）の間に有意差は見られませんでした。 ノートのとり方（キーボード、音声）と問題種別（事実問題、推論問題）の間の交互作用が有意でした。そのため、一対比較を実施したところ、以下の結果が得られました。 ノートのとり方に関して キーボード：事実問題の成績が推論問題の成績よりも有意に高い 音声：事実問題と推論問題の成績の間に有意差なし 問題種別に関して 事実問題：キーボードと音声の成績の間に有意差なし 推論問題：音声の成績がキーボードの成績よりも有意に高い RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ 音声でとったノートに含まれるア イデア ユニットの数が、キーボードでとったノートに含まれるア イデア ユニットの数よりも有意に多いことが分かりました。 音声でとったノートに含まれるエラボレーション（例、類推、個人的な経験）の数が、キーボードでとったノートに含まれるエラボレーションの数よりも有意に多いことが分かりました。 ノートのとり方が成績に与える直接効果は有意であることが分かりました。 ア イデア ユニットの数を媒介としてノートのとり方が成績に与える間接効果は有意であることが分かりました。 エラボレーションの数を媒介としてノートのとり方が成績に与える間接効果は有意ではないことが分かりました。 RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ キーボードでノートをとった場合と音声でノートをとった場合のメタ理解の正確性（確信度と成績の差の絶対値）の間に有意差は見られませんでした。 RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 参加者の意見をグルーピングした結果、以下のように6カテゴリーの利点と5カテゴリーの課題が浮かび上がりました。 利点 簡便な入力 瞬間的な思考の記録 共同的なノート作成 リハーサルと エンコード 内容への注意 能動的な説明と反映 課題 録音と再生 編集 検索と見直し 構造化とスケッチ 共有空間での利用 考察 RQ1：ノートのとり方は文章理解にどのような影響を与えるか？ 音声でノートをとることは、テキストの情報に基づく推論を手助けし、情報を横断してア イデア やコンセプトを結びつけている可能性が示唆されました。 推論問題では複数のア イデア ユニットを結びつける必要があり、テキストに対する概念的な理解が試される可能性が示唆されました。 音声でとったノートに関して、「音声でとったノートはより多くのア イデア ユニットを議論できる→ノートをとりながらテキストについてより良い推論を行える→テキストに対する概念的理解が深まる→推論問題の成績が高くなる」という一連の流れが示唆されました。 RQ2：ノートのとり方はノートの内容にどのような影響を与えるか？ 音声でノートをとる際は人称直示詞（人称代名詞）を多く使用するため、仮想の聴衆に話しかけるような、社会的関与が高い内容になる可能性が示唆されました。 社会的関与の高さがより多くのア イデア ユニットの議論とエラボレーションに繋がる可能性が示唆されました。 RQ3：ノートのとり方はメタ理解の判断にどのような影響を与えるか？ 音声でノートをとることは、テキストに対する概念的理解を増加させても、学習パフォーマンスの知覚には影響を与えない可能性が示唆されました。 RQ4：音声ノートを学習活動に利用することの利点と課題は何か？ 仮想の聴衆に話しかけることで豊かな表現が生まれる可能性が示唆されました。 テキストを読みながら同時にノートをとれるため、学習内容自体に注意を向けやすい可能性が示唆されました。 音声でノートをとることのメリットは、ノートを見直すときよりもノートをとるときの方がより明確になる可能性が示唆されました。 音声でとるノートの利便性はデジタル学習環境で発揮されやすい可能性が示唆されました。 限界と今後の課題 実験の限界と、そこから考えられる今後検討すべき課題は以下のとおりです。 限界 課題 実験に使用したテキストがやや複雑（難易度が高い）だと認識されていた より複雑でないテキストに対して一般化されるかの調査 ノートのとり方が文章理解に与える短期的な影響を調査するに留まった より長期的な影響の調査 キーボードと音声で見直しに要する時間が異なり交絡因子となるおそれがあるため、Post-testの前にノートを見直す時間を設定しなかった 入力（キーボード／音声）と出力（文章／音声）の組み合わせによる実験 大学院生を対象として管理された環境で実施した 異なる参加者集団や、より現実的な環境での実験 音声でとるノートは空間的な構造化を必要としない情報のみしか記録できない 数式や マインドマップ など、視覚的な表現が有効な場合の調査 結論 ノートをとる際の入力形式をキーボードから音声へ変更することで、より多くのア イデア ユニットの議論とエラボレーションを行える可能性が示唆されました。 基本的な知識を得ることが目的であれば、キーボードと音声どちらでノートをとった場合も同じようなパフォーマンスを示す可能性が示唆されました。 推論することによってより深く概念を理解することが目的であれば、音声でノートをとる方がより効果的である可能性が示唆されました。 キーボードと音声どちらでノートをとった場合も、文章理解におけるメタ理解の判断には同程度の効果をもたらす可能性が示唆されました。 音声でとるノートはデジタルテキストの概念的な理解を可能にするため、デジタル学習環境に組み込める可能性が示唆されました。 個人的な感想など この論文を題材に選んだきっかけ この論文を題材に選んだ理由としては、タイトルに惹かれたというのが大きいです。 というのも、私は教育関係の事柄に強い興味をもっています。 また、私は学生時代（ほんの2年半前ですが）、音や音楽に関する研究をしていました。 そのため、「ノートをとる」という部分が私の教育センサーに、「音声」の部分が私の音・音楽センサーに引っかかり、 アブスト ラク トに目を通しても面白そうな内容だったので、今回の論文輪読会の題材としました。 論文内容に関して いわゆる典型的なIMRAD形式（ 参考 ）だったこともあり、論文の構成が分かりやすかったです。 また、なるほど確かにと思える部分が多かったです。 例えば、音声でノートをとる場合はテキストから視線を逸らさずにノートをとれる、音声でとったノートは編集、検索、見直しに課題がある、などは、確かにそうだなぁという感覚でした。 疑問点として、「社会的関与の高さがより多くのア イデア ユニットの議論とエラボレーションに繋がる」というのは、日本語の場合でも同様なのか気になりました。 これは、日本語は英語と違い主語や目的語を省略できるため、理由として考察されていた人称直示詞があまり登場しないのでは、と思ったためです。 おわりに 本記事では、論文輪読会で私が紹介した論文について簡単にまとめました。 論文輪読会は、知見のインプットとアウトプット、両者の力を伸ばせる取り組みですので、皆さんの会社や部署などでも実施してみてはいかがでしょうか？ 最後までお読みいただき、本当にありがとうございました！ 私たちは同じ事業部で共に働いていただける仲間を募集しています！ 論文輪読会をはじめとした各種勉強会に気軽に参加できるような環境で働くことに興味のある皆様、ぜひご応募お待ちしています！ フルサイクルエンジニア 執筆： @miyazawa.hibiki 、レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

電通国際情報サービス 、オープン イノベーション ラボの 比嘉康雄 です。 Stable Diffusionシリーズ、今回は、かわいい動物の擬人化用の呪文です。 Stable Diffusionって、動物の擬人化が難しいんです。例えば犬にテニスをさせたいとします。 パッと思いつくのはこんな呪文です。 illustration of cute dog playing tennis ... 出力結果 コレジャナイ感が満載ですね。かわいい動物の擬人化に成功したので、その方法を紹介します。 Stable Diffusionのおすすめコンテンツはこちら。 Waifu Diffusion 1.3.5_80000 v2.1 金髪美女写真 v2.1 美少女アニメ画 v2.1 AUTOMATIC1111 v2.0 美少女イラスト v1.5 美少女画検証 美少女アニメ画改善版 美少女を高確率で出す呪文編 美少女アニメ画編 美少女写真編 女性イラスト編 魅惑的な女アニメ画（トゥーンレンダリング）編 長い呪文は切り捨てられる編 steampunk illustration of cute anthromorphic 動物名 costume steampunkを外す anthromorphicを外す steampunkとanthromorphicを外す costumeを外す steampunkとcostumeを外す まとめ 仲間募集 Stable Diffusionの過去コンテンツ steampunk illustration of cute anthromorphic 動物名 costume これが基本呪文です。 steampunkは、 蒸気機関 が高度に発達したレトロなアニメの世界観を召喚する呪文です。詳しくは、 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 を御覧ください。 不思議なことに、steampunkの世界では、動物が擬人化しやすいのです。 anthromorphicの意味は擬人化。anthromorphic 動物名で、動物が擬人化できれば話は簡単なのですが、世の中そう甘くはありません。 擬人化に必要な3つ目の呪文がcostume（服装）。動物を人間にするには、服が必要だというのは、深い何かを感じますね。 今回の呪文（横長、コピー&ペースト用） steampunk illustration of cute anthromorphic ferret costume highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 閲覧用呪文（改行版） steampunk illustration of cute anthromorphic ferret costume highly detailed artstation deviantart concept art digital painting award winning fantasy scene fantasy composition fantasy lighting 出力結果 かわいい フェレット の擬人化に成功しました。 steampunkを外す steampunkを呪文から外すとどうなるか実験してみましょう。 今回の基本呪文 illustration of cute anthromorphic ferret costume 出力結果 これも、かわいいですね。steampunkを外すと擬人化に失敗するケースが出てきます。 anthromorphicを外す anthromorphicを呪文から外すとどうなるか実験してみましょう。 今回の基本呪文 steampunk illustration of cute ferret costume 出力結果 あれっ、あまり変わらない。そうなんです、steampunkの呪文が指定されている場合、anthromorphicがなくてもあまり結果は変わりません。ごくまれに、擬人化に失敗することがあるくらいです。じゃ、anthromorphicは効果がないかというとそんな事はありません。 次の例を見てください。 steampunkとanthromorphicを外す それでは、steampunkとanthromorphicを両方外してみましょう。 今回の基本呪文 illustration of cute ferret costume 出力結果 擬人化に失敗してしまいました。 先程、steampunkなし、anthromorphicありのときは、擬人化に成功していたことを思い出してください。anthromorphicは確かに擬人化の効果があるということです。 steampunkにも擬人化の効果があるため、steampunkと組み合わせるときは、anthromorphicなしでもあまり影響はありませんが、基本つけるようにしたほうが良いでしょう。 costumeを外す 今回は、costumeを外してみましょう。 今回の基本呪文 steampunk illustration of cute anthromorphic ferret 出力結果 costumeを外しても、きれいに擬人化されていますね。今回の結果は予想していた人もいたかもしれません。steampunkとanthromorphicで、擬人化に必要な呪文の成分が足りているため、costumeを外してもほとんど影響がないのです。 しかし、costumeに擬人化に必要な呪文の成分がないかというとそんな事はありません。次の例を見てください。 steampunkとcostumeを外す それでは、steampunkとcostumeを両方外してみましょう。 今回の基本呪文 illustration of cute anthromorphic ferret 出力結果 完全に擬人化に失敗してますね。anthromorphic単独では、擬人化に必要な呪文の成分が足りていないということです。 まとめ かわいい動物を擬人化するときの基本呪文は steampunk illustration of cute anthromorphic 動物名 costume です。anthromorphicの意味は擬人化ですが、anthromorphic単独で擬人化できるほど強い呪文ではありません。steampunkやcostumeなどの擬人化成分を持った呪文と組み合わせましょう。 次回は、 バベルの塔のイラスト編 です。 仲間募集 私たちは同じグループで共に働いていただける仲間を募集しています。 現在、以下のような職種を募集しています。 ソリューションアーキテクト AIエンジニア Stable Diffusionの過去コンテンツ 人物写真編 レンズ編 画像タイプ編 美少女アニメ画編 美少女写真編 女性イラスト編 美しい夜空を見渡す男編 魅惑的な女アニメ画（トゥーンレンダリング）編 美少女を高確率で出す呪文編 長い呪文は切り捨てられる編 蒸気機関が高度に発達したレトロなアニメ（スチームパンク）の世界観編 A as Bの呪文による画像合成編 かわいい動物の擬人化編 バベルの塔のイラスト編 TPU版の使い方 美少女アニメ画改善版 v1.5 美少女画検証 東京タワーの写真 折り紙合体変形ロボ v2.0 美少女イラスト v2.1 AUTOMATIC1111 v2.1 美少女アニメ画 v2.1 金髪美女写真 Waifu Diffusion 1.3.5_80000 執筆： @higa （ Shodo で執筆されました ）