こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 CDK にはローカルファイルを S3 バケット にデプロイできる BucketDeployment という便利なコンスト ラク トがあり、静的ファイルの配信などの用途に利用できます。 これを使って JavaScript ファイルを CDK リポジトリ からデプロイする時に、ついでにファイルの SRI ハッシュ も計算して、Web アプリから参照できるように SSM パラメータストア or Secrets Manager に保存してみました。 SRI とは 想定している構成例 自前で管理している S3 バケットではどれほどの効果があるのか 実装例 BucketDeployment で静的ファイルを S3 にデプロイ ファイルの SRI ハッシュを計算する SRI ハッシュを SSM Parameter Store か Secrets Manager に登録 (おまけ) aws-actions/aws-secretsmanager-get-secrets SRI とは 参考： サブリソース完全性 (MDN) サブリソース完全性 (Subresource Integrity) のことであり、取得したリソースが改ざんされていないかを検出するブラウザの仕組みです。 Webサイトが配信する <script> タグの integrity 属性にリソースの ハッシュ値 を付加することで、ブラウザは実際に取得したリソースの ハッシュ値 と一致するかどうかを確認し、一致しなかった場合にはリソースは実行されません。 < script src = "https://static.my-domain.com/myscript.js" crossorigin = "anonymous" integrity= "sha384-mY5hfCTEoihIw/5Wlnjpg/00npMlmKiMCZFMqFRYQRbvhDpcA/JkTv7utYUF+/kA" ></ script > これにより、例えば JavaScript の中身が改ざんされた場合、悪意のあるコードが実行されることを防ぐことができます。 想定している構成例 Web アプリケーションとは別 ドメイン から スクリプト ファイルをロードする構成を想定します。 スクリプト ファイルは自組織が管理する S3 バケット に配置され、CloudFront ディストリビューション 経由で配信されているとします。 CDK で S3 バケット に スクリプト をデプロイする時に、ついでに スクリプト ファイルの SRI ハッシュを計算し、SSM パラメータストア or Secrets Manager に保存しておきます。Web アプリケーションのデプロイ時などにパラメータにアクセスし、読み込む スクリプト の <script> タグの integrity 属性に埋め込むように構成すれば、S3 バケット もしくは CloudFront ディストリビューション が配信するファイルが改ざんされた場合には スクリプト は実行されません。 ※ Web アプリのデプロイ時に SRI ハッシュを取得する場合、配信する スクリプト ファイルを更新したら Web アプリも再デプロイする必要があることにご注意ください。 図で赤枠に囲まれている、 スクリプト ファイルと ハッシュ値 のデプロイが、この記事で紹介したい部分です。 自前で管理している S3 バケット ではどれほどの効果があるのか SRI はパブリックな CDN が配信するリソースに対して利用されることが多い印象です。そのようなリソースは攻撃の対象として狙われやすく、改ざんが成功した時の影響範囲が広いため、SRI をサポートしているリソースの場合は是非 Web アプリで対応しておきたいです。 一方で今回想定しているような、自前で管理している S3 バケット からリソースを配信する場合、SRI を利用することで防げることは比較的限定されます。いくつかの攻撃パターンに対する SRI の効果を考えてみます。 意図しない第 三者 が AWS の強いアクセス権を獲得してしまった SRI はあまり意味がない。Web アプリが付与する SRI ハッシュ値 を書き換えるか、 integrity 属性を完全に削除してしまえば スクリプト は改ざんし放題 そもそも スクリプト の改ざん以外にも、直接データベースの中身を盗んだりいろいろできてしまう CloudFront / S3 の設定ミスで、意図せず スクリプト が外部から改ざんできる状態になっていた SRI の効果がある。CloudFront と S3 は一般アクセスを許可する構成を取れるため、基本プライベートな SSM パラメータストアや Secrets Manager、Webアプリのデプロイパイプラインよりも外部から侵入できる状態になっているリスクが高い CloudFront / S3 自体のバグで、意図せず スクリプト が外部から改ざんできる状態になっていた SRI の効果がある 自前で管理している S3 バケット に対しての効果は限定的とはいえ、 プログラミング言語 で IaC を書ける CDK であれば、さほど難しくない実装で SRI ハッシュの計算と保存をすることができます。効果が限定的だからこそ、悩まず簡単に実装できるようにブログ記事に書き残しておく意味はあるんだろうなと思っています。 ちなみに S3 の設定ミスによる外部公開を防ぐために、 パブリックアクセスブロック設定 を利用しましょう。 OAC を使えば CloudFront のオリジンとなっている S3 バケット にもパブリックアクセスブロックを設定できます。 実装例 ここから実装例を紹介していきます。 BucketDeployment で静的ファイルを S3 にデプロイ BucketDeployment コンスト ラク トを利用し、 ./static フォルダの中身を S3 バケット にデプロイするコンスト ラク ト例です。S3 バケット と CloudFront ディストリビューション は別コンスト ラク トで作成済みの前提です。 distribution プロパティに CloudFront ディストリビューション を渡すことで、デプロイ時に CloudFront のキャッシュの無効化もやってくれます。 Cache-Control ヘッダーに no-store を設定するのがポイントで、これによりクライアント（ブラウザ）側でリソースがキャッシュされなくなり、 スクリプト を更新した時にキャッシュされた古い スクリプト と新しい SRI ハッシュの整合性が取れなくなる事態を回避できます。 import { StackProps } from "aws-cdk-lib" ; import * as cloudfront from "aws-cdk-lib/aws-cloudfront" ; import * as s3 from "aws-cdk-lib/aws-s3" ; import * as s3deployment from "aws-cdk-lib/aws-s3-deployment" ; import { Construct } from "constructs" ; export interface MyConstructProps extends StackProps { bucket: s3.Bucket ; distribution: cloudfront.Distribution ; } export class MyConstruct extends Construct { constructor( scope: Construct , id: string , props: MyConstructProps ) { super( scope , id ); new s3deployment.BucketDeployment ( this , "MyBucketDeployment" , { destinationBucket: props.bucket , sources: [ s3deployment.Source.asset ( "./static" ) ] , prune: false , retainOnDelete: false , distribution: props.distribution , cacheControl: [ s3deployment.CacheControl.noStore () ] , contentType: "text/javascript" , } ); } } ファイルの SRI ハッシュを計算する TypeScript では次のような関数で、ファイルの SRI 用の ハッシュ値 を計算できます。 import * as crypto from "crypto" ; import * as fs from "fs" ; export const sriHash = ( filePath: string ) : string => { const data = fs.readFileSync ( filePath ); const digest = crypto.createHash ( "sha384" ) .update ( data ) .digest ( "base64" ); return `sha384- ${ digest } ` ; } ; SRI ハッシュを SSM Parameter Store か Secrets Manager に登録 上に記載した SRI ハッシュを計算する関数は同期処理なので CDK スタック内から普通に呼び出せます。 new secretsmanager.Secret ( this , "MySRISecret" , { secretName: "MySRI" , secretStringValue: SecretValue.unsafePlainText ( sriHash ( "./static/myscript.js" )), removalPolicy: RemovalPolicy.DESTROY , } ); new ssm.StringParameter ( this , "MySRIParameter" , { parameterName: "/MY_SRI" , stringValue: sriHash ( "./static/myscript.js" ), } ); (おまけ) aws -actions/ aws -secretsmanager-get-secrets パラメータとして登録された SRI ハッシュを、Web アプリのデプロイ時に取得して <script> タグに埋め込む方法はいろいろあると思いますが、 GitHub Actions では aws-actions/aws-secretsmanager-get-secrets という AWS 公式の Action を利用するのが便利です。SSM パラメータストアには使えず Secrets Manager 限定ですが、次の例のようにシークレット名 MySRI を取得し、 MY_SCRIPT_SRI という 環境変数 に格納してくれます。 - name: Configure AWS Credentials uses: aws-actions/configure-aws-credentials@v2 with: role-to-assume: arn:aws:iam::111122223333:role/my-deployment-role aws-region: ap-northeast-1 - name: Get secrets by name and by ARN uses: aws-actions/aws-secretsmanager-get-secrets@v1 with: secret-ids: | MY_SCRIPT_SRI, MySRI parse-json-secrets: false 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア 執筆： @kou.kinyo 、レビュー： @kano.nanami （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 CDK にはローカルファイルを S3 バケット にデプロイできる BucketDeployment という便利なコンスト ラク トがあり、静的ファイルの配信などの用途に利用できます。 これを使って JavaScript ファイルを CDK リポジトリ からデプロイする時に、ついでにファイルの SRI ハッシュ も計算して、Web アプリから参照できるように SSM パラメータストア or Secrets Manager に保存してみました。 SRI とは 想定している構成例 自前で管理している S3 バケットではどれほどの効果があるのか 実装例 BucketDeployment で静的ファイルを S3 にデプロイ ファイルの SRI ハッシュを計算する SRI ハッシュを SSM Parameter Store か Secrets Manager に登録 (おまけ) aws-actions/aws-secretsmanager-get-secrets SRI とは 参考： サブリソース完全性 (MDN) サブリソース完全性 (Subresource Integrity) のことであり、取得したリソースが改ざんされていないかを検出するブラウザの仕組みです。 Webサイトが配信する <script> タグの integrity 属性にリソースの ハッシュ値 を付加することで、ブラウザは実際に取得したリソースの ハッシュ値 と一致するかどうかを確認し、一致しなかった場合にはリソースは実行されません。 < script src = "https://static.my-domain.com/myscript.js" crossorigin = "anonymous" integrity= "sha384-mY5hfCTEoihIw/5Wlnjpg/00npMlmKiMCZFMqFRYQRbvhDpcA/JkTv7utYUF+/kA" ></ script > これにより、例えば JavaScript の中身が改ざんされた場合、悪意のあるコードが実行されることを防ぐことができます。 想定している構成例 Web アプリケーションとは別 ドメイン から スクリプト ファイルをロードする構成を想定します。 スクリプト ファイルは自組織が管理する S3 バケット に配置され、CloudFront ディストリビューション 経由で配信されているとします。 CDK で S3 バケット に スクリプト をデプロイする時に、ついでに スクリプト ファイルの SRI ハッシュを計算し、SSM パラメータストア or Secrets Manager に保存しておきます。Web アプリケーションのデプロイ時などにパラメータにアクセスし、読み込む スクリプト の <script> タグの integrity 属性に埋め込むように構成すれば、S3 バケット もしくは CloudFront ディストリビューション が配信するファイルが改ざんされた場合には スクリプト は実行されません。 ※ Web アプリのデプロイ時に SRI ハッシュを取得する場合、配信する スクリプト ファイルを更新したら Web アプリも再デプロイする必要があることにご注意ください。 図で赤枠に囲まれている、 スクリプト ファイルと ハッシュ値 のデプロイが、この記事で紹介したい部分です。 自前で管理している S3 バケット ではどれほどの効果があるのか SRI はパブリックな CDN が配信するリソースに対して利用されることが多い印象です。そのようなリソースは攻撃の対象として狙われやすく、改ざんが成功した時の影響範囲が広いため、SRI をサポートしているリソースの場合は是非 Web アプリで対応しておきたいです。 一方で今回想定しているような、自前で管理している S3 バケット からリソースを配信する場合、SRI を利用することで防げることは比較的限定されます。いくつかの攻撃パターンに対する SRI の効果を考えてみます。 意図しない第 三者 が AWS の強いアクセス権を獲得してしまった SRI はあまり意味がない。Web アプリが付与する SRI ハッシュ値 を書き換えるか、 integrity 属性を完全に削除してしまえば スクリプト は改ざんし放題 そもそも スクリプト の改ざん以外にも、直接データベースの中身を盗んだりいろいろできてしまう CloudFront / S3 の設定ミスで、意図せず スクリプト が外部から改ざんできる状態になっていた SRI の効果がある。CloudFront と S3 は一般アクセスを許可する構成を取れるため、基本プライベートな SSM パラメータストアや Secrets Manager、Webアプリのデプロイパイプラインよりも外部から侵入できる状態になっているリスクが高い CloudFront / S3 自体のバグで、意図せず スクリプト が外部から改ざんできる状態になっていた SRI の効果がある 自前で管理している S3 バケット に対しての効果は限定的とはいえ、 プログラミング言語 で IaC を書ける CDK であれば、さほど難しくない実装で SRI ハッシュの計算と保存をすることができます。効果が限定的だからこそ、悩まず簡単に実装できるようにブログ記事に書き残しておく意味はあるんだろうなと思っています。 ちなみに S3 の設定ミスによる外部公開を防ぐために、 パブリックアクセスブロック設定 を利用しましょう。 OAC を使えば CloudFront のオリジンとなっている S3 バケット にもパブリックアクセスブロックを設定できます。 実装例 ここから実装例を紹介していきます。 BucketDeployment で静的ファイルを S3 にデプロイ BucketDeployment コンスト ラク トを利用し、 ./static フォルダの中身を S3 バケット にデプロイするコンスト ラク ト例です。S3 バケット と CloudFront ディストリビューション は別コンスト ラク トで作成済みの前提です。 distribution プロパティに CloudFront ディストリビューション を渡すことで、デプロイ時に CloudFront のキャッシュの無効化もやってくれます。 Cache-Control ヘッダーに no-store を設定するのがポイントで、これによりクライアント（ブラウザ）側でリソースがキャッシュされなくなり、 スクリプト を更新した時にキャッシュされた古い スクリプト と新しい SRI ハッシュの整合性が取れなくなる事態を回避できます。 import { StackProps } from "aws-cdk-lib" ; import * as cloudfront from "aws-cdk-lib/aws-cloudfront" ; import * as s3 from "aws-cdk-lib/aws-s3" ; import * as s3deployment from "aws-cdk-lib/aws-s3-deployment" ; import { Construct } from "constructs" ; export interface MyConstructProps extends StackProps { bucket: s3.Bucket ; distribution: cloudfront.Distribution ; } export class MyConstruct extends Construct { constructor( scope: Construct , id: string , props: MyConstructProps ) { super( scope , id ); new s3deployment.BucketDeployment ( this , "MyBucketDeployment" , { destinationBucket: props.bucket , sources: [ s3deployment.Source.asset ( "./static" ) ] , prune: false , retainOnDelete: false , distribution: props.distribution , cacheControl: [ s3deployment.CacheControl.noStore () ] , contentType: "text/javascript" , } ); } } ファイルの SRI ハッシュを計算する TypeScript では次のような関数で、ファイルの SRI 用の ハッシュ値 を計算できます。 import * as crypto from "crypto" ; import * as fs from "fs" ; export const sriHash = ( filePath: string ) : string => { const data = fs.readFileSync ( filePath ); const digest = crypto.createHash ( "sha384" ) .update ( data ) .digest ( "base64" ); return `sha384- ${ digest } ` ; } ; SRI ハッシュを SSM Parameter Store か Secrets Manager に登録 上に記載した SRI ハッシュを計算する関数は同期処理なので CDK スタック内から普通に呼び出せます。 new secretsmanager.Secret ( this , "MySRISecret" , { secretName: "MySRI" , secretStringValue: SecretValue.unsafePlainText ( sriHash ( "./static/myscript.js" )), removalPolicy: RemovalPolicy.DESTROY , } ); new ssm.StringParameter ( this , "MySRIParameter" , { parameterName: "/MY_SRI" , stringValue: sriHash ( "./static/myscript.js" ), } ); (おまけ) aws -actions/ aws -secretsmanager-get-secrets パラメータとして登録された SRI ハッシュを、Web アプリのデプロイ時に取得して <script> タグに埋め込む方法はいろいろあると思いますが、 GitHub Actions では aws-actions/aws-secretsmanager-get-secrets という AWS 公式の Action を利用するのが便利です。SSM パラメータストアには使えず Secrets Manager 限定ですが、次の例のようにシークレット名 MySRI を取得し、 MY_SCRIPT_SRI という 環境変数 に格納してくれます。 - name: Configure AWS Credentials uses: aws-actions/configure-aws-credentials@v2 with: role-to-assume: arn:aws:iam::111122223333:role/my-deployment-role aws-region: ap-northeast-1 - name: Get secrets by name and by ARN uses: aws-actions/aws-secretsmanager-get-secrets@v1 with: secret-ids: | MY_SCRIPT_SRI, MySRI parse-json-secrets: false 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア 執筆： @kou.kinyo 、レビュー： @kano.nanami （ Shodo で執筆されました ）

みなさんこんにちは！　ISID 金融ソリューション事業部の松崎です。 前回 の記事では「フォトグラメトリによる3Dモデル作成ワークフロー（前編）」と題し、フォトグラメトリを行う上で必要となる機材や、写真撮影前・撮影時の注意ポイントを紹介しました。 まだご覧になっていない方は、是非前編から読んでいただけると嬉しいです！ 今回は後編になります。 撮影後のRAW現像手法、RealityCaptureを用いてのモデル作成方法について紹介します。 ワークフロー一覧 フォトグラメトリによる3Dモデル作成のワークフローは、大きく分けて以下に分けられます。 機材の準備 被写体の確認、撮影環境のロケハン 被写体の撮影 撮影画像のRAW現像 メッシュモデル作成 テクスチャ貼り付け・ローポリ化 後編では、4~6についてご紹介します。 4.撮影画像のRAW現像 写真撮影後のRAW現像手順を紹介します。 RAW現像とは、撮影した生データ（RAWデータ）の明暗・ホワイトバランス・ コントラ ストなどを調整し、 JPEG 形式などの閲覧可能な形式で出力する処理を指します。 ※この手順はRAW形式で撮影したときのみ実施します。 JPEG 形式などで撮影した（カメラ側で現像が完了している）場合はスキップしてください。 なお、現像・加工時には以下のアプリを使用します。 Adobe Bridge （Win/ mac 対応　無料） Adobe Photoshop Lightroom （Win/ mac 対応　有料：1078円/月　※2023年7月現在） 次行より手順を紹介していきます。 まず初めに、撮影した写真をPCへ移動させ、 Adobe Bridgeを使用して開きます。 Adobe Bridgeでは、現像の前準備を行います。 「ツール → ファイル名をバッチで変更」を選択し、写真のファイル名を変更します。 ファイル名を変更するのは、モデル作成時に他の写真が混ざってしまうのを防止するためです。 ファイル名が変更できたら、必要に応じて写真の メタデータ にキーワードを設定します。 キーワードを設定することで、写真の絞り込みが容易になります。 今回撮影した写真は メタデータ にロックがかかっているので、全写真を選択した後に「右クリック→すべての項目のロックを解除」を選択し、ロックを解除します。 ロックが解除できたら、キーワードを設定します。 今回は全写真に「花壇小」のキーワードを設定しました。 次に、 Adobe Photoshop Lightroom を開き、「ファイル→新規カタログ」で新規カタログを作成します。 Adobe Photoshop Lightroom では、写真の加工・現像を行います。 カタログを作成したら、「読み込み」から写真の読み込みを行います。 ファイル名を変更したファイルを格納したフォルダを選択し、「全てをチェック」で全写真を選択後、「読み込み」を押します。 読み込んだ写真は、「 メタデータ →キーワード」から絞り込みを行うことができます。 今回はキーワードを1つしか設定していない為、絞り込みは行いません。 全写真を選択した後に、「現像」を押して写真の加工調整画面に移ります。 画面右の ヒストグラム を見ながら、加工調整を行います。 加工を行う際は、可能な限り 黒つぶれ・白飛びをなくすよう に各項目を設定します。 また、広角レンズを使っている場合は適宜レンズ補正も行います。 今回は以下の設定値で加工調整を行いました。 露光量：+0.15 コントラ スト：+6 ハイライト：-50 シャドウ：+20 白レベル：-20 黒レベル：+20 レンズ補正：プロファイル補正を使用（ Adobe Sony FE 16-35mm F4 ZA OSS ） 調整が完了したら、右下の「同期」を選択し、設定値を他の写真にも同期します。 全写真への同期が完了したら写真を一通り確認し、黒つぶれ・白飛びが発生していないかチェックします。 問題ない場合は、「ファイル→書き出し」を選択し、 JPEG 画像として現像を行います。 現像を行う際、画質設定は「100」としましょう。（劣化を防ぐため） 現像が完了しましたら、 Adobe Bridgeにて現像したファイルを確認します。 この際、ボケなどが発生してフォトグラメトリに適さないファイルは、キーワードを付けて取り除けるようにしておきます。 「 geometry」と「 texture」のフォルダを作成します。（このフォルダ名は固定です） 「 geometry」はRealityCaptureに取り込んだ際に、自動で点群やメッシュモデルの作成用に使われる写真です。 対して、「 texture」はテクスチャ作成用に使われます。 メッシュモデル作成時とテクスチャ作成時で別々の写真を使いたい場合は、各フォルダに使用対象の写真を入れましょう。 例：テクスチャ作成時に黒つぶれ・白飛びした写真を使いたい　など 今回はモデル作成用とテクスチャ用で写真を分けないので、両方のフォルダにすべての写真を入れます。 以上で加工・現像の手順は完了です。 なお、ボケ画像などを取り除きたい場合は、適宜「 geometry」と「 texture」フォルダから取り除きましょう。 5.メッシュモデル作成 素材となる写真が揃いましたので、RealityCaptureでメッシュモデルを作成していきます。 なお、RealityCaptureの基本に関しては こちらの記事 にて紹介しておりますので、気になる方はご一読頂ければと思います。 まず初めにRealityCaptureを開き、インポート設定を行います。 「Application→Setting」で設定メニューを開き、インポート設定を以下のように設定します。 Group calibration by Exif ：Yes Copy the imported components to the cache：No Ignore GPS Exif ：Yes 次に、「ALIGHNMENT→Setting」からアライメント設定を開き、以下を設定します。 Image overlap：Low これにより、アライメントの際に写真同士が繋がり易くなります。 （十分な重なりを担保出来ている場合は、「Normal」や「High」でもよい） 設定が完了しましたら、フォルダを読み込みます。 「WORKFLOW→Folder」と選択し、現像した写真を格納しているフォルダを読み込みます。 この際、「 geometry」や「 texture」フォルダは直接読み込まず、一階層上のフォルダを読み込みましょう。 読み込みが完了したら、「ALIGNMENT→Allign Images」を選択し、アライメントを開始します。 アライメント完了です。（所要時間：約3分） 今回は コンポーネント が分かれることなく、全ての写真が繋がりました。 コンポーネント が2つや3つに分かれてしまった場合は、適宜コン トロール ポイントを設定しましょう。 全ての写真が繋がっていることが確認出来たら、写真のグループ化を解除して再アライメントを行います。 これにより、写真の位置推定結果がより正確に行われます。 「Images」を選択し、「Ungroup」で写真のグループ解除を行い、再度「Allign Images」を実行します。 再アライメントが完了しました。（所要時間：約3秒） すべての写真が繋がった コンポーネント が増えていることを確認します。 問題なければ、次にメッシュの構築範囲指定を行います。 赤青緑のポイントがそれぞれXYZ軸に対応しておりますので、これらを動かして範囲を選択します。 メッシュ作成の処理時間を短縮するためにも、メッシュ構築範囲はなるべく狭く設定しましょう。 適切に範囲選択ができましたら、メッシュモデルを作成します。 「MESH MODEL→High Detail」を選択し、ハイクオリティのメッシュモデルを作成します。 メッシュモデルが完成しました。（所要時間：約60分） 特に問題がなければ、次はメッシュの不必要な部分を除去します。 「SCENE 3D TOOLS→Mesh Model→Lasso」を選択します。 Lassoは投げなわツールです。「Shift+左クリック」で範囲追加、「Ctrl+左クリック」で範囲除外を行うことが出来ます。 今回は花壇下の床部分（オレンジで選択されている範囲）が不要であった為、選択した後に「Filter Selection」で取り除きました。 取り除いた後のモデルがこちらです。 なお、RealityCaptureではFilter Selectionを行うごとに新しいモデルが作成される為、取り除く前のモデルも残っています。 除去後のモデル（Model 3）を見ると、およそ5800万ポリゴンであることが確認できます。 6.テクスチャ貼り付け・ローポリ化 最後に、テクスチャの貼り付けを行います。 また、モデルのポリゴン数が多すぎて扱いづらい場合は、適宜ローポリ化を行います。 まず初めに、「Mesh Model→Setting」からテクスチャ設定を変更します。 以下のように設定し、その他はデフォルト設定のままにします。 Minimal texture resolution：16384×16384 Maximal texture resolution：16384×16384 Large triangle removal threshold：100 Style：Fixed texcel size Texel Size：Optimal これにより、最高解像度のテクスチャを作成することが出来ます。 設定が完了しましたら、「MESH MODEL→Texture」よりテクスチャ作成を実行します。 テクスチャが作成されました（所要時間：約10分） モデルのテクスチャ部分を見ると、2枚のテクスチャが作成されていることが確認できます。 1枚は diffuse Map（Albedo Map） と呼ばれるもので、物体の基本色を表しています。 もう1枚は Normal Map と呼ばれるもので、物体の法線方向ベクトル（細かい凹凸）を表しています。 テクスチャマップの詳細については こちらの記事 にて紹介されておりますので、是非ご一読ください。 ポリゴン数を減らす必要がない場合は上記で完成です、以下ではローポリ化を行う場合の手順を紹介します。 今回は「5800万ポリゴン→1000万ポリゴン」へのローポリ化を行っていきます。 なお、ローポリ化を行う際に見た目上のクオリティが劣化しないよう、ハイポリ状態で作成したテクスチャのベイク（焼きこみ）を行います。 まず初めに、「SCENE 3D TOOLS→Mesh Model→Simplify Tools」を選択して以下の設定を行います。 Type：Absolute Target triangles count：10000000（ローポリ化後のポリゴン数） Color reprojection：Disable Normal reprojection：Disable 設定が完了したら、「simplify」でローポリ化を実行します。 ローポリ化後のモデルが作成されました。（Model5） 1000万ポリゴンになっていることが確認できます。 上記でテクスチャの再投影を無効にしているため、テクスチャは作成されておりません。 （画像で色が見えている部分は頂点カラーになります） 次に、ハイポリ状態で作成したテクスチャをベイクする為のUVマップを作成します。 「MESH MODEL→Unwrap」を選択し、以下のようにUVパラメータの設定を行います。 設定値はテクスチャ作成時とほぼ同様ですが、Styleだけ変化している点に注意してください。 Minimal texture resolution：16384×16384 Maximal texture resolution：16384×16384 Large triangle removal threshold：100 Style：Maximal texture count Maximal texture count：1 設定が完了したら、「Unwrap」を押してUVマップ作成を実行します。 UVマップの作成が完了したら、ハイポリ状態で作成したテクスチャをベイクします。 「SCENE 3D TOOLS→Mesh Model→Texture Reprojection」を選択し、以下のように設定を変更します。 Source model：Model4 （ハイポリ状態のテクスチャを作成したモデル） Result model：Model5 （ローポリモデル） Normal reprojection：Enable 設定が完了したら、「Reproject」を押してテクスチャのベイクを実行します。 ベイク完了です。 ハイポリ状態の見た目クオリティを保ったまま、ローポリ化することができました。 おわりに 本記事では、フォトグラメトリワークフローの後編として、撮影後のRAW現像手法、RealityCaptureを使ってのモデル作成方法について紹介しました。 写真撮影の際には注意すべき点が多く、また屋外の場合は天候に左右されてしまうのが難しいところです。 たとえ写真撮影が複数日に渡ってしまったとしても、RAW形式で撮影しておけば現像段階である程度明るさを揃えることができますので、基本はRAW撮影がおすすめです。 前後編を通して、一通りのワークフローを紹介できたかと思います。 これからフォトグラメトリを始める方や、既に始めていて悩んでいる方の一助となれば幸いです。 次回以降もフォトグラメトリやその他の3Dモデル作成手法を紹介していく予定ですので、楽しみにしていてください！ 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ 参考資料 ・ 日本写真印刷コミュニケーションズ株式会社：「フォトグラメトリ」とはどういうもの？ ・ Adobe Bridge 公式サイト ・ Adobe Photoshop Lightroom 公式サイト ・ lileaLab フォトグラメトリ手順書 ・ RealityCapture to Unreal Engine 5 ・ PBR（物理ベースレンダリング）マテリアル 入門編 執筆： @matsuzaki.shota 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

みなさんこんにちは！　ISID 金融ソリューション事業部の松崎です。 前回 の記事では「フォトグラメトリによる3Dモデル作成ワークフロー（前編）」と題し、フォトグラメトリを行う上で必要となる機材や、写真撮影前・撮影時の注意ポイントを紹介しました。 まだご覧になっていない方は、是非前編から読んでいただけると嬉しいです！ 今回は後編になります。 撮影後のRAW現像手法、RealityCaptureを用いてのモデル作成方法について紹介します。 ワークフロー一覧 フォトグラメトリによる3Dモデル作成のワークフローは、大きく分けて以下に分けられます。 機材の準備 被写体の確認、撮影環境のロケハン 被写体の撮影 撮影画像のRAW現像 メッシュモデル作成 テクスチャ貼り付け・ローポリ化 後編では、4~6についてご紹介します。 4.撮影画像のRAW現像 写真撮影後のRAW現像手順を紹介します。 RAW現像とは、撮影した生データ（RAWデータ）の明暗・ホワイトバランス・ コントラ ストなどを調整し、 JPEG 形式などの閲覧可能な形式で出力する処理を指します。 ※この手順はRAW形式で撮影したときのみ実施します。 JPEG 形式などで撮影した（カメラ側で現像が完了している）場合はスキップしてください。 なお、現像・加工時には以下のアプリを使用します。 Adobe Bridge （Win/ mac 対応　無料） Adobe Photoshop Lightroom （Win/ mac 対応　有料：1078円/月　※2023年7月現在） 次行より手順を紹介していきます。 まず初めに、撮影した写真をPCへ移動させ、 Adobe Bridgeを使用して開きます。 Adobe Bridgeでは、現像の前準備を行います。 「ツール → ファイル名をバッチで変更」を選択し、写真のファイル名を変更します。 ファイル名を変更するのは、モデル作成時に他の写真が混ざってしまうのを防止するためです。 ファイル名が変更できたら、必要に応じて写真の メタデータ にキーワードを設定します。 キーワードを設定することで、写真の絞り込みが容易になります。 今回撮影した写真は メタデータ にロックがかかっているので、全写真を選択した後に「右クリック→すべての項目のロックを解除」を選択し、ロックを解除します。 ロックが解除できたら、キーワードを設定します。 今回は全写真に「花壇小」のキーワードを設定しました。 次に、 Adobe Photoshop Lightroom を開き、「ファイル→新規カタログ」で新規カタログを作成します。 Adobe Photoshop Lightroom では、写真の加工・現像を行います。 カタログを作成したら、「読み込み」から写真の読み込みを行います。 ファイル名を変更したファイルを格納したフォルダを選択し、「全てをチェック」で全写真を選択後、「読み込み」を押します。 読み込んだ写真は、「 メタデータ →キーワード」から絞り込みを行うことができます。 今回はキーワードを1つしか設定していない為、絞り込みは行いません。 全写真を選択した後に、「現像」を押して写真の加工調整画面に移ります。 画面右の ヒストグラム を見ながら、加工調整を行います。 加工を行う際は、可能な限り 黒つぶれ・白飛びをなくすよう に各項目を設定します。 また、広角レンズを使っている場合は適宜レンズ補正も行います。 今回は以下の設定値で加工調整を行いました。 露光量：+0.15 コントラ スト：+6 ハイライト：-50 シャドウ：+20 白レベル：-20 黒レベル：+20 レンズ補正：プロファイル補正を使用（ Adobe Sony FE 16-35mm F4 ZA OSS ） 調整が完了したら、右下の「同期」を選択し、設定値を他の写真にも同期します。 全写真への同期が完了したら写真を一通り確認し、黒つぶれ・白飛びが発生していないかチェックします。 問題ない場合は、「ファイル→書き出し」を選択し、 JPEG 画像として現像を行います。 現像を行う際、画質設定は「100」としましょう。（劣化を防ぐため） 現像が完了しましたら、 Adobe Bridgeにて現像したファイルを確認します。 この際、ボケなどが発生してフォトグラメトリに適さないファイルは、キーワードを付けて取り除けるようにしておきます。 「 geometry」と「 texture」のフォルダを作成します。（このフォルダ名は固定です） 「 geometry」はRealityCaptureに取り込んだ際に、自動で点群やメッシュモデルの作成用に使われる写真です。 対して、「 texture」はテクスチャ作成用に使われます。 メッシュモデル作成時とテクスチャ作成時で別々の写真を使いたい場合は、各フォルダに使用対象の写真を入れましょう。 例：テクスチャ作成時に黒つぶれ・白飛びした写真を使いたい　など 今回はモデル作成用とテクスチャ用で写真を分けないので、両方のフォルダにすべての写真を入れます。 以上で加工・現像の手順は完了です。 なお、ボケ画像などを取り除きたい場合は、適宜「 geometry」と「 texture」フォルダから取り除きましょう。 5.メッシュモデル作成 素材となる写真が揃いましたので、RealityCaptureでメッシュモデルを作成していきます。 なお、RealityCaptureの基本に関しては こちらの記事 にて紹介しておりますので、気になる方はご一読頂ければと思います。 まず初めにRealityCaptureを開き、インポート設定を行います。 「Application→Setting」で設定メニューを開き、インポート設定を以下のように設定します。 Group calibration by Exif ：Yes Copy the imported components to the cache：No Ignore GPS Exif ：Yes 次に、「ALIGHNMENT→Setting」からアライメント設定を開き、以下を設定します。 Image overlap：Low これにより、アライメントの際に写真同士が繋がり易くなります。 （十分な重なりを担保出来ている場合は、「Normal」や「High」でもよい） 設定が完了しましたら、フォルダを読み込みます。 「WORKFLOW→Folder」と選択し、現像した写真を格納しているフォルダを読み込みます。 この際、「 geometry」や「 texture」フォルダは直接読み込まず、一階層上のフォルダを読み込みましょう。 読み込みが完了したら、「ALIGNMENT→Allign Images」を選択し、アライメントを開始します。 アライメント完了です。（所要時間：約3分） 今回は コンポーネント が分かれることなく、全ての写真が繋がりました。 コンポーネント が2つや3つに分かれてしまった場合は、適宜コン トロール ポイントを設定しましょう。 全ての写真が繋がっていることが確認出来たら、写真のグループ化を解除して再アライメントを行います。 これにより、写真の位置推定結果がより正確に行われます。 「Images」を選択し、「Ungroup」で写真のグループ解除を行い、再度「Allign Images」を実行します。 再アライメントが完了しました。（所要時間：約3秒） すべての写真が繋がった コンポーネント が増えていることを確認します。 問題なければ、次にメッシュの構築範囲指定を行います。 赤青緑のポイントがそれぞれXYZ軸に対応しておりますので、これらを動かして範囲を選択します。 メッシュ作成の処理時間を短縮するためにも、メッシュ構築範囲はなるべく狭く設定しましょう。 適切に範囲選択ができましたら、メッシュモデルを作成します。 「MESH MODEL→High Detail」を選択し、ハイクオリティのメッシュモデルを作成します。 メッシュモデルが完成しました。（所要時間：約60分） 特に問題がなければ、次はメッシュの不必要な部分を除去します。 「SCENE 3D TOOLS→Mesh Model→Lasso」を選択します。 Lassoは投げなわツールです。「Shift+左クリック」で範囲追加、「Ctrl+左クリック」で範囲除外を行うことが出来ます。 今回は花壇下の床部分（オレンジで選択されている範囲）が不要であった為、選択した後に「Filter Selection」で取り除きました。 取り除いた後のモデルがこちらです。 なお、RealityCaptureではFilter Selectionを行うごとに新しいモデルが作成される為、取り除く前のモデルも残っています。 除去後のモデル（Model 3）を見ると、およそ5800万ポリゴンであることが確認できます。 6.テクスチャ貼り付け・ローポリ化 最後に、テクスチャの貼り付けを行います。 また、モデルのポリゴン数が多すぎて扱いづらい場合は、適宜ローポリ化を行います。 まず初めに、「Mesh Model→Setting」からテクスチャ設定を変更します。 以下のように設定し、その他はデフォルト設定のままにします。 Minimal texture resolution：16384×16384 Maximal texture resolution：16384×16384 Large triangle removal threshold：100 Style：Fixed texcel size Texel Size：Optimal これにより、最高解像度のテクスチャを作成することが出来ます。 設定が完了しましたら、「MESH MODEL→Texture」よりテクスチャ作成を実行します。 テクスチャが作成されました（所要時間：約10分） モデルのテクスチャ部分を見ると、2枚のテクスチャが作成されていることが確認できます。 1枚は diffuse Map（Albedo Map） と呼ばれるもので、物体の基本色を表しています。 もう1枚は Normal Map と呼ばれるもので、物体の法線方向ベクトル（細かい凹凸）を表しています。 テクスチャマップの詳細については こちらの記事 にて紹介されておりますので、是非ご一読ください。 ポリゴン数を減らす必要がない場合は上記で完成です、以下ではローポリ化を行う場合の手順を紹介します。 今回は「5800万ポリゴン→1000万ポリゴン」へのローポリ化を行っていきます。 なお、ローポリ化を行う際に見た目上のクオリティが劣化しないよう、ハイポリ状態で作成したテクスチャのベイク（焼きこみ）を行います。 まず初めに、「SCENE 3D TOOLS→Mesh Model→Simplify Tools」を選択して以下の設定を行います。 Type：Absolute Target triangles count：10000000（ローポリ化後のポリゴン数） Color reprojection：Disable Normal reprojection：Disable 設定が完了したら、「simplify」でローポリ化を実行します。 ローポリ化後のモデルが作成されました。（Model5） 1000万ポリゴンになっていることが確認できます。 上記でテクスチャの再投影を無効にしているため、テクスチャは作成されておりません。 （画像で色が見えている部分は頂点カラーになります） 次に、ハイポリ状態で作成したテクスチャをベイクする為のUVマップを作成します。 「MESH MODEL→Unwrap」を選択し、以下のようにUVパラメータの設定を行います。 設定値はテクスチャ作成時とほぼ同様ですが、Styleだけ変化している点に注意してください。 Minimal texture resolution：16384×16384 Maximal texture resolution：16384×16384 Large triangle removal threshold：100 Style：Maximal texture count Maximal texture count：1 設定が完了したら、「Unwrap」を押してUVマップ作成を実行します。 UVマップの作成が完了したら、ハイポリ状態で作成したテクスチャをベイクします。 「SCENE 3D TOOLS→Mesh Model→Texture Reprojection」を選択し、以下のように設定を変更します。 Source model：Model4 （ハイポリ状態のテクスチャを作成したモデル） Result model：Model5 （ローポリモデル） Normal reprojection：Enable 設定が完了したら、「Reproject」を押してテクスチャのベイクを実行します。 ベイク完了です。 ハイポリ状態の見た目クオリティを保ったまま、ローポリ化することができました。 おわりに 本記事では、フォトグラメトリワークフローの後編として、撮影後のRAW現像手法、RealityCaptureを使ってのモデル作成方法について紹介しました。 写真撮影の際には注意すべき点が多く、また屋外の場合は天候に左右されてしまうのが難しいところです。 たとえ写真撮影が複数日に渡ってしまったとしても、RAW形式で撮影しておけば現像段階である程度明るさを揃えることができますので、基本はRAW撮影がおすすめです。 前後編を通して、一通りのワークフローを紹介できたかと思います。 これからフォトグラメトリを始める方や、既に始めていて悩んでいる方の一助となれば幸いです。 次回以降もフォトグラメトリやその他の3Dモデル作成手法を紹介していく予定ですので、楽しみにしていてください！ 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ 参考資料 ・ 日本写真印刷コミュニケーションズ株式会社：「フォトグラメトリ」とはどういうもの？ ・ Adobe Bridge 公式サイト ・ Adobe Photoshop Lightroom 公式サイト ・ lileaLab フォトグラメトリ手順書 ・ RealityCapture to Unreal Engine 5 ・ PBR（物理ベースレンダリング）マテリアル 入門編 執筆： @matsuzaki.shota 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

みなさんこんにちは！　ISID 金融ソリューション事業部の松崎です。 前回 の記事では、フォトグラメトリを用いた3Dモデル作成手法を紹介しました。まだご覧になっていない方は、是非読んでいただけると嬉しいです！ 今回からは、2回に分けて フォトグラメトリを用いた3Dモデル作成のワークフロー を紹介していきます。 この記事は前編です。 はじめに まず初めに、フォトグラメトリについて概要を説明します。 フォトグラメトリとは、被写体をさまざまなアングルから撮影し、そのデジタル画像を解析・統合して写実的な3Dモデルを作成する技術です。3Dスキャナのような特殊な機器が不要で、通常の写真だけで生成できることが特徴です。 被写体の大きさや求める3Dモデルのクオリティにもよりますが、およそ数十枚～数百枚のデジタル画像を用いて3Dモデルを生成します。 LIDERなどセンサーを用いた手法と比較した場合、フォトグラメトリの強みとしては写真からハイクオリティなテクスチャを抽出できることが挙げられます。 （画像：被写体(車)に対してフォトグラメトリ用の写真を撮影するイメージ） ワークフロー一覧 フォトグラメトリによる3Dモデル作成のワークフローは、大きく分けて以下に分けられます。 機材の準備 被写体の確認、撮影環境のロケハン 被写体の撮影 撮影画像のRAW現像 メッシュモデル作成 テクスチャ貼り付け・ローポリ化 前編では、1~3についてご紹介します。 1.機材の準備 フォトグラメトリを行うにあたって、必要となる機材を紹介します。 本記事で紹介する機材一覧を以下に示します。 カメラ PC 三脚/一脚 コンパクトカメラ （＋ 伸縮ロッド） ドローン 回転台 （+ 背景布/グリーンバック） 照明 露出計/カラーチェッカー 偏光フィルター 1-1.カメラ フォトグラメトリ用の写真を撮影する際、重要になるポイントを2つ紹介します。 また、参考として私たちが使用しているカメラを紹介します。 1-1-1.画質 フォトグラメトリは、写真から3Dモデルを作成するという特性上、写真の画質が3Dモデルのクオリティに直結します。 その為、よりリアルな3Dモデルを作成したい場合は高画 素数 のカメラを使うことが望ましいです。 一方、高画 素数 カメラは一つ一つの受光素子が小さくなる関係で、「ノイズや手振れが起こりやすくなり、暗所にも弱い」というデメリットが存在します。 「とりあえず高画 素数 のカメラを使う」のではなく、自分が求めるクオリティと撮影環境（明るさ確保や手振れ対策が可能か等）を照らし合わせて選定することが望ましいです。 （画像：低画素と高画素の受光素子イメージ） 1-1-2.画角 フォトグラメトリのワークフローにおいて、大きく手間がかかる部分は写真の「撮影」と「処理」になります。 被写体が小さい場合はそこまで手間もないですが、部屋や建物を対象とする場合は、数百～数千の写真を撮影・処理することになります。その為、「撮影枚数をいかに減らすか」といった部分がとても重要になります。 通常のズームレンズの 焦点距離 は35~50mmが一般的ですが、広角レンズ（ 焦点距離 14~20mm程度）を用いることで、画角を1.5~2倍程広くできます。この場合、単純概算で写真枚数を0.5~0.7倍程に減らせることになりますので、可能な限り広角レンズを使うことが望ましいです。 （画像：レンズの 焦点距離 と画角の変化） 一方、広角レンズを用いると写真の端部分を中心に歪みが発生するといったデメリットが存在します。 フォトグラメトリソフトウェアによっては広角写真を補正する機能（RealityCaptureにて確認済）がありますので、各種機能を駆使しながら、できる限りの広角レンズを使用することが望ましいです。 1-1-3.カメラ紹介（参考） 私たちが使用しているカメラ・レンズを紹介します。 カメラやレンズ選定のご参考にしていただければと思います。 Sony α7R IV 約6100万画素、35mmフルサイズセンサーのデジタル一眼ミラーレ スカメ ラ 高解像度・高感度・低ノイズ性能が特徴です。 Sony Vario-Tessar T* FE 16-35mm F4 ZA OSS （SEL1635Z） 35mmフルサイズ イメージセンサー とマッチする、 焦点距離 16~35mmの広角ズームレンズ 非球面レンズ 5枚とEDガラス3枚が使用されており、画面端の高解像度化や歪曲収差が低減される点が特徴的です。 1-2.PC PCは主にフォトグラメトリソフトウェアを動かす為に使用します。 私たちのチームでは、フォトグラメトリソフトウェアとして RealiyCapture を使用しておりますが、その要求スペックは以下のとおりです。（ 出典元 ） PC：64bit PC/ ワークステーション OS：64bit Microsoft Windows version 7 / 8 / 8.1 / 10 / 11 または Windows Server version 2008+ CPU：SSE4.2（Streaming SIMD Extensions 4.2）以降 RAM（メモリ）：8GB以上 GPU ： NVIDIA graphics card with CUDA 3.0+ capabilities で 、VRAMが1GB以上 DRIVER：CUDA Toolkit 10.2, minimal driver version 441.22. また、推奨スペックは以下になります。 RAM：16GB以上 CPU：4コア以上 CUDAコア数：1024以上 GPU ： NVIDIA グラフィックカード （ NVIDIA 以外の グラフィックカード では、テクスチャ・3Dモデルを作成できません） 前回の記事にて紹介した通り、RealiyCaptureは「アライメント ⇒ メッシュ作成 ⇒ テクスチャ作成」の順で処理を行います。この内、メッシュ作成はCPU・ GPU の両方が使われていますが、アライメントとテクスチャ作成はCPUのみで行われます。その為、処理時間を短縮したい場合はCPU性能から向上させることが望ましいです。 また上記出典元では、RAMに関して「数千枚の高画質写真(30~80MP)を扱うには16GBで十分」と記載されています。 数千枚より多くの写真を用いる場合や、100MPを超えるような超高画質写真を使用する場合は32GB以上のRAMを検討しましょう。 こちらも参考までに、私たちが使用しているPCスペックを紹介します。 私たちの場合は、RealityCapture側のアップデート（1億ポリゴン対応等）に備え、推奨より高いスペックにて構成しています。 OS： Windows 11 Pro 64bit CPU： Intel Core i9 -13900KF CPUコア数：24 RAM：64GB GPU ： NVIDIA GeForce RTX 4090 CUDAコア数：16384 グラフィックメモリ：24GB 1-3.その他 フォトグラメトリを行う上で必須となる機材はカメラ・PCですが、それ以外にも「あったら便利」な機材がいくつか存在します。私たちのチームで検討中の機材も含め、そんな便利機材を紹介していきます。 1-3-1.三脚/一脚 フォトグラメトリにおいて「手振れ」は3Dモデルのクオリティ劣化に直結します。最近のカメラは手振れ補正機能が充実していますが、それでも激しく揺れた場合はブレが発生してしまいます。 また、同じ高さを維持して撮影したい時や、 シャッタースピード を落として撮影したい時にも三脚/一脚が便利です。 1-3-2.コンパクトカメラ （＋ 伸縮ロッド） 5m~10mの高所から撮影する場合、コンパクトカメラ等の小型・軽量カメラがあると便利です。 数枚程度の高所撮影であれば通常サイズのカメラで問題ないと思いますが、数十～数百枚の高所撮影をするときは軽いカメラが役立ちます。 1-3-3.ドローン 10m以上の高所から撮影する必要がある場合は、ドローンでの空撮が選択肢に入ります。 ただし、2023年6月現在はドローン使用に関する規制が厳しく、場所によってはドローン空撮が許可されない場合もあります。また、人が歩いている上空で行う「レベル4」の飛行には、国家資格「一等 無人 航空機操縦士」が必要になります。 その為、ドローンを用いた空撮は非常に難易度の高い要件と言えます。 （画像： ドローンとは何か ） 1-3-4.回転台 （+ 背景布/グリーンバック） 単体の物体、かつ回転台に乗る大きさの物体を被写体とする場合は、回転台を使用すると撮影の手間が省けます。 フォトグラメトリでは360°すべての角度から撮影する必要がありますが、回転台を用いることで、カメラを固定したまま一周分撮影することが出来ます。 注意点としては、被写体以外の背景部分が回転しないことです。この場合、被写体と背景部分の特徴点変化が釣り合わず、特徴点抽出が正常に働きません。 その為、グリーンバック等を用いて一色に統一し、背景部分をマスク処理等で除去できるようにする必要があります。 1-3-5.照明 屋内撮影にて単物体を被写体とする場合は、照明を用いることで光量を調節することが出来ます。 フォトグラメトリの特性上、物体に当たっている光量は直接テクスチャへ影響します。 カメラ側での露出設定や現像後処理にて調整することも可能ですが、最初から目的の光量に統一して撮影すると、細かい調整作業を省くことが出来ます。 また、設置式の定常光が置ける場合は問題ないですが、空間的制約などによって設置できない場合はストロボを使用することも検討します。 1-3-6.露出計/カラーチェッカー 露出計は、その場の光の強度を測定し、カメラの露出設定を導出する機械です。 フォトグラメトリでは対象を様々な角度から撮影する為、カメラの露出設定を一定にしている場合、角度によって露出が変化してしまいます。 適正露出を保つためには、露出計を用いて角度毎に露出設定を変更することが望ましいです。 また、ホワイトバランスの調整としてはカラーチェッカーがあると便利です。 1-3-7.偏光フィルター 偏光フィルター（PLフィルター）は、反射光を調整するフィルターです。 晴れの日の屋外で撮影する時など、物体からの反射光が強く出てしまうときに使用すると、物体本来の色彩を捉えやすくなります。 （画像： PL(偏光)フィルターの効果と使い方、使用例、選び方、特徴 ） 2.被写体の確認、撮影環境のロケハン ここからは被写体の大きさや屋内/屋外の条件ごとに、撮影前に必要となるロケハン内容を紹介します。 2-1.単体の物体 単体の物体を被写体とする際は、 その物体を全方位から撮影できるだけの空間が必要 になります。 コップや花瓶のような小物体の場合は机の上に置いて撮影できますが、大きなデスク等を被写体とする際は、周囲にそれなりの空間が要求されます。（被写体全体を写すには、ある程度離れる必要がある為） 全方位から撮影できる空間が取れない場合は、被写体を広い部屋に移動させて撮影することが望ましいです。 （画像：部屋の大きさに対して物体が大きい例） その他の点として、光量を一定に保ちたい場合は照明を用いて調整しましょう。 また被写体が回転台に乗る大きさであれば、上記で紹介した「回転台 ＋ グリーンバック」の機材で撮影を効率化できますので、これらの設置可否を検討しましょう。 2-2.部屋内観（屋内） 部屋全体を撮影する際に重要なポイントは、 可能な限り部屋内の物体を減らすこと です。 小さな物体がいくつかある程度であればよいですが、大きな物体があると撮影時に影部分（部屋全体を撮った写真内に映らない部屋の壁・床など）が増えてしまい、細かく何か所も撮影する必要が出てしまいます。 また、詳細は3章にて説明しますが、「部屋全体を撮影した写真」と「影部分となった箇所を個別に撮影した写真」をフォトグラメトリ上で1つのモデルとして繋げるには、それぞれの写真の間となる写真も必要になります。（RealityCaptureの場合は前後の写真にて最低60％の重なりを維持する必要あり） その為、「影部分」は可能な限り作らないようにすることが最重要です。 3Dモデル化した後の利用を考えた際にも「既に物体が置かれている部屋」というのは扱いづらいですので、「部屋」と「内部にある物体」は別々にモデル化する方式が望ましいです。 （画像：部屋中央に物体がある際に発生する「影部分」） また、 GSD（地上解像度）の計算 を行うことで、作成する3Dモデルのテクスチャ解像度を事前に想定することが出来ます。 GSDは「センサー幅」「 焦点距離 」「高さ」「画像幅(pixel)」「画像高さ(pixel)」を元に地上面における解像度を導出するものですが、「高さ」部分を「部屋内の最も遠い部分までの距離」とすることで、作成テクスチャ内の最も低い解像度箇所が導出できます。 テクスチャで担保したい解像度ラインがある場合は、あらかじめGSDを計算しておくと安心です。 参考： PIX4D TOOLS - GSD calculator その他のポイントとしては、以下が挙げられます。 ガラス面や白一色の壁はフォトグラメトリで再現不可（特徴点として認識できない為）。 対象箇所は新聞紙などでマスキング を施しておく（後続フローにて手作業の修正が必要）。 撮影時の移動経路をあらかじめ想定し、目印としてマステなどを貼っておく。 移動経路は一筆書きの動きでイメージ し、写真同士が連続するように組む 撮影の「始まりの写真」と「終わりの写真」がきちんと連続するように、 撮影開始地点は特徴点の多い場所 に定める。 部屋の高さを確認し、場合によっては伸縮ロッドやコンパクトカメラの利用を検討する。 2-3.建物外観（屋外） 屋外にて建物外観を撮影する際のポイントは、 太陽光と人払い です。 屋内と異なり、屋外では太陽光の影響を取り除くことが出来ません。 時間による太陽の位置変化や、雲から出た/隠れた際の日照量変化によって露出が変わってしまいます。 その為、屋外で撮影を行う際はあらかじめ移動ルートを確立しておき、 曇りの日に短時間で 撮影を完了させることが望ましいです。 また、写真は後処理で明るくすることが出来ます。（逆に暗くするのは難しいです） 黒潰れしない範囲で全体的に暗めに撮影しておき、後処理で明るくして全体の調整を行いましょう。 2点目は人払いです。 こちらは公共の屋内（美術館など）でも関係する話ですが、屋外での撮影は基本的に公共の場所・建築物の撮影になります。 フォトグラメトリ用の写真では、途中で人が入り込んでしまうと写真の連続性が維持できなくなってしまう為、公共の場所であっても人（その他の動く物体含む）が映らないよう配慮する必要があります。 上記のような場所を長時間に渡って占有する（他の人を近づけさせない）場合、大抵は管理者の許可が必要です。 占有自体が禁止されている場合もありますので、撮影対象に関するルールは事前に確認しておきましょう。 また、高所を撮影する際にドローンを使いたくなりますが、2023年6月現在ドローン使用に関する法規制はかなり厳しいです。（場合によっては国家資格も求められます） その為、高所撮影は基本的に「小型カメラ＋伸縮ロッド(1~10m程)」での実施を検討しましょう。 3.被写体の撮影 被写体の撮影時に注意するポイントを、場面ごとに紹介していきます。 3-1.共通 まず初めに、全場面に共通するポイントを紹介します。 3-1-1.前後の写真で70%以上の重なりを維持する RealityCaptureに取り込んでアライメントを行う場合、最低60%（可能なら70%）の重なりが必要です。 ただし実際に「70%」を感覚的に行うのは難しいと思いますので、私なりのやり方を紹介します。 フォトグラメトリ用の写真撮影では、カメラの向きと垂直方向への移動（動きとしては横移動）が基本になります。 その為、まずは1撮影ごとの横移動可能な距離を感覚的に把握する必要があります。 カメラの向きを変えないまま横移動する場合、移動距離がそのまま写真に反映されるので、写真の横幅1/3程度(約30%)分移動できることになります。 （画像：カメラと垂直方向への移動イメージ） 実際に移動できる距離はカメラの広角性能によりますので、試しに何回か横移動しながら写真を撮り、 「写真上で横幅1/3分移動する自分の歩幅」を確認しましょう。 3-1-2.カメラの向きを変える際は、細かく移動（撮影）しながら変える カメラの向きを変える際に、一点に留まって向きだけを変えると重なりのバランスが悪くなってしまいます。 向きを変える際は、細かめに移動しながら少しずつ向きを変えましょう。 （画像：方向転換方法による重なりの違い） 3-1-3.全体が鮮明な写真を撮影する（被写体深度を深くする） フォトグラメトリにおいて、ボケ感のある写真は望ましくありません。 ポートレート のような被写体深度の浅い写真ではなく、全体がクッキリと映った写真を撮影しましょう。 具体的な設定方法としては、 F値 （絞り）を大きくします。 設定値はカメラの性能や周囲の明るさによりますが、低くても4以上が望ましいです。（可能であれば11や14など） （画像：被写体深度によるピンボケの違い） 3-1-4.ノイズや手振れを発生させない 前項と関係する話になりますが、 F値 を上げるためにレンズを絞ると、レンズから入る光の量が減少してしまいます。 そのままだと暗い写真になってしまう場合、 ISO感度 と シャッタースピード を調整して明るくする必要があります。 しかし、 ISO感度 は上げすぎるとノイズが発生してしまい、 シャッタースピード は遅くすると手振れが発生しやすくなります。 両方をバランスよく調整して、ノイズや手振れを発生させないようにしましょう。 また、どうしてもノイズや手振れが発生してしまう場合は、「 F値 を下げる」または「三脚を使用する」ことを検討しましょう。 （画像：ノイズや手振れの発生例） 3-1-5.動く物体を撮影しない 上述した通り、フォトグラメトリでは画像の重なりがとても重要です。 人間などの動く物体が映り込んでいると写真間の重なりが正しく判定されなくなる恐れがあるので、静止した物体のみを撮影するようにしましょう。 また、撮影の途中で物体の向きや場所を変えるのも厳禁です。 撮影の開始と終了時で、撮影範囲内のすべての物体が変化しないようにしましょう。 ※グリーンバックなどを用いて背景をマスク処理する場合は例外です （画像：動物の映り込みが発生した例） 3-1-6.黒つぶれや白飛びを発生させない 黒つぶれや白飛びは現像段階にて調整することが出来ない為、撮影段階で発生させないようにしましょう。 最近のカメラは撮影時や再生時に ヒストグラム （輝度分布）が表示されますので、黒つぶれ・白飛びが見られる場合は露出補正をかけて対処します。 なお、蛍光灯のように常に白飛びしてしまう部分や、テクスチャのクオリティを求めない黒い部分などは適宜妥協しましょう。 （画像：黒つぶれ・白飛びの発生例） 3-1-7.写真間の「明暗」・「色調」に大きな差を出さない 写真間の「明暗」・「色調」が異なる場合、テクスチャの色合いが場所ごとに変わってしまいます。 現像段階にて調整することも可能ですが、可能な限り撮影時に揃えておくことが望ましいです。 露出変化が激しい場所での撮影では、適宜露出計を用いての調整も検討しましょう。 （画像：撮影中に明暗が変化した例） 3-2.屋内空間（部屋全体など） 次に、屋内空間を撮影する時に意識するポイントを紹介します。 3-2-1.カメラの向きと垂直方向へ移動しながら撮影する 3-1-1で記載した通り、フォトグラメトリではカメラの向きと垂直方向への移動（横移動）が基本です。 屋内の場合、壁面の地上解像度が求めるクオリティに収まる範囲で壁面から距離を取り、そこから横移動して撮影します。 1セットで足りない場合は、壁面からの距離を変えて横移動の撮影を繰り返しましょう。 （画像：横移動のイメージ） 3-2-2.撮影開始地点と終了地点は特徴点の多い場所を選ぶ 1セットの開始地点と終了地点を特徴点の多い場所にすると、他セットの写真と接続しやすくなります。 部屋内に特徴点の多い場所が一点しかない場合は、常にその一点に行き着くようにセットを組みましょう。 注意点として、ある程度特徴点の多い場所であっても、部屋内に同じような場所が存在する場合は候補から外しましょう。 ※この場合横移動だけでは撮影できない部分が出てきますので、適宜方向転換も行いながらの撮影になります。 （画像：特徴点の多い場所・少ない場所） 3-2-3.写真は「低い位置からの斜め上目線」と「高い位置からの斜め下目線」で撮影する カメラの位置と向きに関しては、「低い位置からの斜め上目線」と「高い位置からの斜め下目線」の2パターンで撮影します。 理由としては、この目線が最も広範囲に部屋内を撮影できるからです。 「低い位置」は床付近、「高い位置」は可能な限り天井に近い場所になります。（適宜三脚などを利用しましょう） なお、天井が高く上記の視点では天井・床に対して必要な地上解像度が得られない場合は、別の高さでの撮影も行う必要があります。 （画像：屋内撮影時のカメラ視点イメージ） 3-3.屋外 最後に、屋外での撮影時に気を付けるポイントを紹介します。 3-3-1.曇りの日に撮影する 3-1-7で記載した通り、写真間の「明暗」・「色調」は撮影段階で揃えておくことが望ましいです。 晴れの日など、短時間の日射量変化が激しい日は撮影に適しません。 また、快晴の日は晴れほど日射量変化は激しくないですが、後述するフレア・ゴーストが発生しやすくなります。 その為、曇りで日射量の少ない日が撮影に適しています。 （画像：理想の天気状況と、晴れた日の影響例） 3-3-2.逆光による光条・ゴーストを発生させない 逆光状態で撮影を行うと、光条やゴーストが発生してしまいます。 これはテクスチャに影響にしてしまうので、撮影角度や撮影時間を変えて、可能な限り発生させないようにします。 どうしても発生してしまう場合は、その写真をアライメントのみに利用し、テクスチャ作成時には取り除きましょう。 （画像：光条・ゴーストの発生例） 3-3-3無風状態のときに撮影する 3-1-5で記載した通り、フォトグラメトリでは撮影物体を静止させる必要があります。 屋外で撮影する場合、風の影響で木や葉が揺れてしまいますので、無風状態を狙って撮影しましょう。 無風状態で撮影できない場合は、別日での撮影を検討します。 （画像：撮影毎に木の枝が動いてしまった例） おわりに 本記事では、フォトグラメトリワークフローの前編として、機材選定に関する部分と撮影前・撮影時の注意ポイントについて紹介しました。 これからフォトグラメトリを始める方で、「どんな機材を揃えたらいいんだろう？」「撮影前や撮影時に何を意識すればいいんだろう？」という悩みを持つ方の一助となれば幸いです。 後編 ではRealityCaptureに取り込む前の現像処理や、RealityCaptureを用いてのモデル作成部分を紹介していきますので、こちらも御一読いただければ幸いです。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ 参考資料 ・ 日本写真印刷コミュニケーションズ株式会社：「フォトグラメトリ」とはどういうもの？ ・ フジヤカメラ：カメラの画素数は多ければいいの！？画素数と画質の関係 高画素のメリット・デメリット ・ フジヤカメラ：PL(偏光)フィルターの効果と使い方、使用例、選び方、特徴 ・ 姫野ばら園：カメラコラム「レンズの焦点距離と画角の変化」 ・ EpicGames：OS and hardware requirements ・ DRONE NAVIGATOR：ドローンとは何か ・ PIX4D：TOOLS - GSD calculator ・ STUDIO DUCKBILL 広域・環境フォトグラメトリの世界 執筆： @matsuzaki.shota 、レビュー： @yamashita.yuki （ Shodo で執筆されました ）

みなさんこんにちは！　ISID 金融ソリューション事業部の松崎です。 前回 の記事では、フォトグラメトリを用いた3Dモデル作成手法を紹介しました。まだご覧になっていない方は、是非読んでいただけると嬉しいです！ 今回からは、2回に分けて フォトグラメトリを用いた3Dモデル作成のワークフロー を紹介していきます。 この記事は前編です。 はじめに まず初めに、フォトグラメトリについて概要を説明します。 フォトグラメトリとは、被写体をさまざまなアングルから撮影し、そのデジタル画像を解析・統合して写実的な3Dモデルを作成する技術です。3Dスキャナのような特殊な機器が不要で、通常の写真だけで生成できることが特徴です。 被写体の大きさや求める3Dモデルのクオリティにもよりますが、およそ数十枚～数百枚のデジタル画像を用いて3Dモデルを生成します。 LIDERなどセンサーを用いた手法と比較した場合、フォトグラメトリの強みとしては写真からハイクオリティなテクスチャを抽出できることが挙げられます。 （画像：被写体(車)に対してフォトグラメトリ用の写真を撮影するイメージ） ワークフロー一覧 フォトグラメトリによる3Dモデル作成のワークフローは、大きく分けて以下に分けられます。 機材の準備 被写体の確認、撮影環境のロケハン 被写体の撮影 撮影画像のRAW現像 メッシュモデル作成 テクスチャ貼り付け・ローポリ化 前編では、1~3についてご紹介します。 1.機材の準備 フォトグラメトリを行うにあたって、必要となる機材を紹介します。 本記事で紹介する機材一覧を以下に示します。 カメラ PC 三脚/一脚 コンパクトカメラ （＋ 伸縮ロッド） ドローン 回転台 （+ 背景布/グリーンバック） 照明 露出計/カラーチェッカー 偏光フィルター 1-1.カメラ フォトグラメトリ用の写真を撮影する際、重要になるポイントを2つ紹介します。 また、参考として私たちが使用しているカメラを紹介します。 1-1-1.画質 フォトグラメトリは、写真から3Dモデルを作成するという特性上、写真の画質が3Dモデルのクオリティに直結します。 その為、よりリアルな3Dモデルを作成したい場合は高画 素数 のカメラを使うことが望ましいです。 一方、高画 素数 カメラは一つ一つの受光素子が小さくなる関係で、「ノイズや手振れが起こりやすくなり、暗所にも弱い」というデメリットが存在します。 「とりあえず高画 素数 のカメラを使う」のではなく、自分が求めるクオリティと撮影環境（明るさ確保や手振れ対策が可能か等）を照らし合わせて選定することが望ましいです。 （画像：低画素と高画素の受光素子イメージ） 1-1-2.画角 フォトグラメトリのワークフローにおいて、大きく手間がかかる部分は写真の「撮影」と「処理」になります。 被写体が小さい場合はそこまで手間もないですが、部屋や建物を対象とする場合は、数百～数千の写真を撮影・処理することになります。その為、「撮影枚数をいかに減らすか」といった部分がとても重要になります。 通常のズームレンズの 焦点距離 は35~50mmが一般的ですが、広角レンズ（ 焦点距離 14~20mm程度）を用いることで、画角を1.5~2倍程広くできます。この場合、単純概算で写真枚数を0.5~0.7倍程に減らせることになりますので、可能な限り広角レンズを使うことが望ましいです。 （画像：レンズの 焦点距離 と画角の変化） 一方、広角レンズを用いると写真の端部分を中心に歪みが発生するといったデメリットが存在します。 フォトグラメトリソフトウェアによっては広角写真を補正する機能（RealityCaptureにて確認済）がありますので、各種機能を駆使しながら、できる限りの広角レンズを使用することが望ましいです。 1-1-3.カメラ紹介（参考） 私たちが使用しているカメラ・レンズを紹介します。 カメラやレンズ選定のご参考にしていただければと思います。 Sony α7R IV 約6100万画素、35mmフルサイズセンサーのデジタル一眼ミラーレ スカメ ラ 高解像度・高感度・低ノイズ性能が特徴です。 Sony Vario-Tessar T* FE 16-35mm F4 ZA OSS （SEL1635Z） 35mmフルサイズ イメージセンサー とマッチする、 焦点距離 16~35mmの広角ズームレンズ 非球面レンズ 5枚とEDガラス3枚が使用されており、画面端の高解像度化や歪曲収差が低減される点が特徴的です。 1-2.PC PCは主にフォトグラメトリソフトウェアを動かす為に使用します。 私たちのチームでは、フォトグラメトリソフトウェアとして RealiyCapture を使用しておりますが、その要求スペックは以下のとおりです。（ 出典元 ） PC：64bit PC/ ワークステーション OS：64bit Microsoft Windows version 7 / 8 / 8.1 / 10 / 11 または Windows Server version 2008+ CPU：SSE4.2（Streaming SIMD Extensions 4.2）以降 RAM（メモリ）：8GB以上 GPU ： NVIDIA graphics card with CUDA 3.0+ capabilities で 、VRAMが1GB以上 DRIVER：CUDA Toolkit 10.2, minimal driver version 441.22. また、推奨スペックは以下になります。 RAM：16GB以上 CPU：4コア以上 CUDAコア数：1024以上 GPU ： NVIDIA グラフィックカード （ NVIDIA 以外の グラフィックカード では、テクスチャ・3Dモデルを作成できません） 前回の記事にて紹介した通り、RealiyCaptureは「アライメント ⇒ メッシュ作成 ⇒ テクスチャ作成」の順で処理を行います。この内、メッシュ作成はCPU・ GPU の両方が使われていますが、アライメントとテクスチャ作成はCPUのみで行われます。その為、処理時間を短縮したい場合はCPU性能から向上させることが望ましいです。 また上記出典元では、RAMに関して「数千枚の高画質写真(30~80MP)を扱うには16GBで十分」と記載されています。 数千枚より多くの写真を用いる場合や、100MPを超えるような超高画質写真を使用する場合は32GB以上のRAMを検討しましょう。 こちらも参考までに、私たちが使用しているPCスペックを紹介します。 私たちの場合は、RealityCapture側のアップデート（1億ポリゴン対応等）に備え、推奨より高いスペックにて構成しています。 OS： Windows 11 Pro 64bit CPU： Intel Core i9 -13900KF CPUコア数：24 RAM：64GB GPU ： NVIDIA GeForce RTX 4090 CUDAコア数：16384 グラフィックメモリ：24GB 1-3.その他 フォトグラメトリを行う上で必須となる機材はカメラ・PCですが、それ以外にも「あったら便利」な機材がいくつか存在します。私たちのチームで検討中の機材も含め、そんな便利機材を紹介していきます。 1-3-1.三脚/一脚 フォトグラメトリにおいて「手振れ」は3Dモデルのクオリティ劣化に直結します。最近のカメラは手振れ補正機能が充実していますが、それでも激しく揺れた場合はブレが発生してしまいます。 また、同じ高さを維持して撮影したい時や、 シャッタースピード を落として撮影したい時にも三脚/一脚が便利です。 1-3-2.コンパクトカメラ （＋ 伸縮ロッド） 5m~10mの高所から撮影する場合、コンパクトカメラ等の小型・軽量カメラがあると便利です。 数枚程度の高所撮影であれば通常サイズのカメラで問題ないと思いますが、数十～数百枚の高所撮影をするときは軽いカメラが役立ちます。 1-3-3.ドローン 10m以上の高所から撮影する必要がある場合は、ドローンでの空撮が選択肢に入ります。 ただし、2023年6月現在はドローン使用に関する規制が厳しく、場所によってはドローン空撮が許可されない場合もあります。また、人が歩いている上空で行う「レベル4」の飛行には、国家資格「一等 無人 航空機操縦士」が必要になります。 その為、ドローンを用いた空撮は非常に難易度の高い要件と言えます。 （画像： ドローンとは何か ） 1-3-4.回転台 （+ 背景布/グリーンバック） 単体の物体、かつ回転台に乗る大きさの物体を被写体とする場合は、回転台を使用すると撮影の手間が省けます。 フォトグラメトリでは360°すべての角度から撮影する必要がありますが、回転台を用いることで、カメラを固定したまま一周分撮影することが出来ます。 注意点としては、被写体以外の背景部分が回転しないことです。この場合、被写体と背景部分の特徴点変化が釣り合わず、特徴点抽出が正常に働きません。 その為、グリーンバック等を用いて一色に統一し、背景部分をマスク処理等で除去できるようにする必要があります。 1-3-5.照明 屋内撮影にて単物体を被写体とする場合は、照明を用いることで光量を調節することが出来ます。 フォトグラメトリの特性上、物体に当たっている光量は直接テクスチャへ影響します。 カメラ側での露出設定や現像後処理にて調整することも可能ですが、最初から目的の光量に統一して撮影すると、細かい調整作業を省くことが出来ます。 また、設置式の定常光が置ける場合は問題ないですが、空間的制約などによって設置できない場合はストロボを使用することも検討します。 1-3-6.露出計/カラーチェッカー 露出計は、その場の光の強度を測定し、カメラの露出設定を導出する機械です。 フォトグラメトリでは対象を様々な角度から撮影する為、カメラの露出設定を一定にしている場合、角度によって露出が変化してしまいます。 適正露出を保つためには、露出計を用いて角度毎に露出設定を変更することが望ましいです。 また、ホワイトバランスの調整としてはカラーチェッカーがあると便利です。 1-3-7.偏光フィルター 偏光フィルター（PLフィルター）は、反射光を調整するフィルターです。 晴れの日の屋外で撮影する時など、物体からの反射光が強く出てしまうときに使用すると、物体本来の色彩を捉えやすくなります。 （画像： PL(偏光)フィルターの効果と使い方、使用例、選び方、特徴 ） 2.被写体の確認、撮影環境のロケハン ここからは被写体の大きさや屋内/屋外の条件ごとに、撮影前に必要となるロケハン内容を紹介します。 2-1.単体の物体 単体の物体を被写体とする際は、 その物体を全方位から撮影できるだけの空間が必要 になります。 コップや花瓶のような小物体の場合は机の上に置いて撮影できますが、大きなデスク等を被写体とする際は、周囲にそれなりの空間が要求されます。（被写体全体を写すには、ある程度離れる必要がある為） 全方位から撮影できる空間が取れない場合は、被写体を広い部屋に移動させて撮影することが望ましいです。 （画像：部屋の大きさに対して物体が大きい例） その他の点として、光量を一定に保ちたい場合は照明を用いて調整しましょう。 また被写体が回転台に乗る大きさであれば、上記で紹介した「回転台 ＋ グリーンバック」の機材で撮影を効率化できますので、これらの設置可否を検討しましょう。 2-2.部屋内観（屋内） 部屋全体を撮影する際に重要なポイントは、 可能な限り部屋内の物体を減らすこと です。 小さな物体がいくつかある程度であればよいですが、大きな物体があると撮影時に影部分（部屋全体を撮った写真内に映らない部屋の壁・床など）が増えてしまい、細かく何か所も撮影する必要が出てしまいます。 また、詳細は3章にて説明しますが、「部屋全体を撮影した写真」と「影部分となった箇所を個別に撮影した写真」をフォトグラメトリ上で1つのモデルとして繋げるには、それぞれの写真の間となる写真も必要になります。（RealityCaptureの場合は前後の写真にて最低60％の重なりを維持する必要あり） その為、「影部分」は可能な限り作らないようにすることが最重要です。 3Dモデル化した後の利用を考えた際にも「既に物体が置かれている部屋」というのは扱いづらいですので、「部屋」と「内部にある物体」は別々にモデル化する方式が望ましいです。 （画像：部屋中央に物体がある際に発生する「影部分」） また、 GSD（地上解像度）の計算 を行うことで、作成する3Dモデルのテクスチャ解像度を事前に想定することが出来ます。 GSDは「センサー幅」「 焦点距離 」「高さ」「画像幅(pixel)」「画像高さ(pixel)」を元に地上面における解像度を導出するものですが、「高さ」部分を「部屋内の最も遠い部分までの距離」とすることで、作成テクスチャ内の最も低い解像度箇所が導出できます。 テクスチャで担保したい解像度ラインがある場合は、あらかじめGSDを計算しておくと安心です。 参考： PIX4D TOOLS - GSD calculator その他のポイントとしては、以下が挙げられます。 ガラス面や白一色の壁はフォトグラメトリで再現不可（特徴点として認識できない為）。 対象箇所は新聞紙などでマスキング を施しておく（後続フローにて手作業の修正が必要）。 撮影時の移動経路をあらかじめ想定し、目印としてマステなどを貼っておく。 移動経路は一筆書きの動きでイメージ し、写真同士が連続するように組む 撮影の「始まりの写真」と「終わりの写真」がきちんと連続するように、 撮影開始地点は特徴点の多い場所 に定める。 部屋の高さを確認し、場合によっては伸縮ロッドやコンパクトカメラの利用を検討する。 2-3.建物外観（屋外） 屋外にて建物外観を撮影する際のポイントは、 太陽光と人払い です。 屋内と異なり、屋外では太陽光の影響を取り除くことが出来ません。 時間による太陽の位置変化や、雲から出た/隠れた際の日照量変化によって露出が変わってしまいます。 その為、屋外で撮影を行う際はあらかじめ移動ルートを確立しておき、 曇りの日に短時間で 撮影を完了させることが望ましいです。 また、写真は後処理で明るくすることが出来ます。（逆に暗くするのは難しいです） 黒潰れしない範囲で全体的に暗めに撮影しておき、後処理で明るくして全体の調整を行いましょう。 2点目は人払いです。 こちらは公共の屋内（美術館など）でも関係する話ですが、屋外での撮影は基本的に公共の場所・建築物の撮影になります。 フォトグラメトリ用の写真では、途中で人が入り込んでしまうと写真の連続性が維持できなくなってしまう為、公共の場所であっても人（その他の動く物体含む）が映らないよう配慮する必要があります。 上記のような場所を長時間に渡って占有する（他の人を近づけさせない）場合、大抵は管理者の許可が必要です。 占有自体が禁止されている場合もありますので、撮影対象に関するルールは事前に確認しておきましょう。 また、高所を撮影する際にドローンを使いたくなりますが、2023年6月現在ドローン使用に関する法規制はかなり厳しいです。（場合によっては国家資格も求められます） その為、高所撮影は基本的に「小型カメラ＋伸縮ロッド(1~10m程)」での実施を検討しましょう。 3.被写体の撮影 被写体の撮影時に注意するポイントを、場面ごとに紹介していきます。 3-1.共通 まず初めに、全場面に共通するポイントを紹介します。 3-1-1.前後の写真で70%以上の重なりを維持する RealityCaptureに取り込んでアライメントを行う場合、最低60%（可能なら70%）の重なりが必要です。 ただし実際に「70%」を感覚的に行うのは難しいと思いますので、私なりのやり方を紹介します。 フォトグラメトリ用の写真撮影では、カメラの向きと垂直方向への移動（動きとしては横移動）が基本になります。 その為、まずは1撮影ごとの横移動可能な距離を感覚的に把握する必要があります。 カメラの向きを変えないまま横移動する場合、移動距離がそのまま写真に反映されるので、写真の横幅1/3程度(約30%)分移動できることになります。 （画像：カメラと垂直方向への移動イメージ） 実際に移動できる距離はカメラの広角性能によりますので、試しに何回か横移動しながら写真を撮り、 「写真上で横幅1/3分移動する自分の歩幅」を確認しましょう。 3-1-2.カメラの向きを変える際は、細かく移動（撮影）しながら変える カメラの向きを変える際に、一点に留まって向きだけを変えると重なりのバランスが悪くなってしまいます。 向きを変える際は、細かめに移動しながら少しずつ向きを変えましょう。 （画像：方向転換方法による重なりの違い） 3-1-3.全体が鮮明な写真を撮影する（被写体深度を深くする） フォトグラメトリにおいて、ボケ感のある写真は望ましくありません。 ポートレート のような被写体深度の浅い写真ではなく、全体がクッキリと映った写真を撮影しましょう。 具体的な設定方法としては、 F値 （絞り）を大きくします。 設定値はカメラの性能や周囲の明るさによりますが、低くても4以上が望ましいです。（可能であれば11や14など） （画像：被写体深度によるピンボケの違い） 3-1-4.ノイズや手振れを発生させない 前項と関係する話になりますが、 F値 を上げるためにレンズを絞ると、レンズから入る光の量が減少してしまいます。 そのままだと暗い写真になってしまう場合、 ISO感度 と シャッタースピード を調整して明るくする必要があります。 しかし、 ISO感度 は上げすぎるとノイズが発生してしまい、 シャッタースピード は遅くすると手振れが発生しやすくなります。 両方をバランスよく調整して、ノイズや手振れを発生させないようにしましょう。 また、どうしてもノイズや手振れが発生してしまう場合は、「 F値 を下げる」または「三脚を使用する」ことを検討しましょう。 （画像：ノイズや手振れの発生例） 3-1-5.動く物体を撮影しない 上述した通り、フォトグラメトリでは画像の重なりがとても重要です。 人間などの動く物体が映り込んでいると写真間の重なりが正しく判定されなくなる恐れがあるので、静止した物体のみを撮影するようにしましょう。 また、撮影の途中で物体の向きや場所を変えるのも厳禁です。 撮影の開始と終了時で、撮影範囲内のすべての物体が変化しないようにしましょう。 ※グリーンバックなどを用いて背景をマスク処理する場合は例外です （画像：動物の映り込みが発生した例） 3-1-6.黒つぶれや白飛びを発生させない 黒つぶれや白飛びは現像段階にて調整することが出来ない為、撮影段階で発生させないようにしましょう。 最近のカメラは撮影時や再生時に ヒストグラム （輝度分布）が表示されますので、黒つぶれ・白飛びが見られる場合は露出補正をかけて対処します。 なお、蛍光灯のように常に白飛びしてしまう部分や、テクスチャのクオリティを求めない黒い部分などは適宜妥協しましょう。 （画像：黒つぶれ・白飛びの発生例） 3-1-7.写真間の「明暗」・「色調」に大きな差を出さない 写真間の「明暗」・「色調」が異なる場合、テクスチャの色合いが場所ごとに変わってしまいます。 現像段階にて調整することも可能ですが、可能な限り撮影時に揃えておくことが望ましいです。 露出変化が激しい場所での撮影では、適宜露出計を用いての調整も検討しましょう。 （画像：撮影中に明暗が変化した例） 3-2.屋内空間（部屋全体など） 次に、屋内空間を撮影する時に意識するポイントを紹介します。 3-2-1.カメラの向きと垂直方向へ移動しながら撮影する 3-1-1で記載した通り、フォトグラメトリではカメラの向きと垂直方向への移動（横移動）が基本です。 屋内の場合、壁面の地上解像度が求めるクオリティに収まる範囲で壁面から距離を取り、そこから横移動して撮影します。 1セットで足りない場合は、壁面からの距離を変えて横移動の撮影を繰り返しましょう。 （画像：横移動のイメージ） 3-2-2.撮影開始地点と終了地点は特徴点の多い場所を選ぶ 1セットの開始地点と終了地点を特徴点の多い場所にすると、他セットの写真と接続しやすくなります。 部屋内に特徴点の多い場所が一点しかない場合は、常にその一点に行き着くようにセットを組みましょう。 注意点として、ある程度特徴点の多い場所であっても、部屋内に同じような場所が存在する場合は候補から外しましょう。 ※この場合横移動だけでは撮影できない部分が出てきますので、適宜方向転換も行いながらの撮影になります。 （画像：特徴点の多い場所・少ない場所） 3-2-3.写真は「低い位置からの斜め上目線」と「高い位置からの斜め下目線」で撮影する カメラの位置と向きに関しては、「低い位置からの斜め上目線」と「高い位置からの斜め下目線」の2パターンで撮影します。 理由としては、この目線が最も広範囲に部屋内を撮影できるからです。 「低い位置」は床付近、「高い位置」は可能な限り天井に近い場所になります。（適宜三脚などを利用しましょう） なお、天井が高く上記の視点では天井・床に対して必要な地上解像度が得られない場合は、別の高さでの撮影も行う必要があります。 （画像：屋内撮影時のカメラ視点イメージ） 3-3.屋外 最後に、屋外での撮影時に気を付けるポイントを紹介します。 3-3-1.曇りの日に撮影する 3-1-7で記載した通り、写真間の「明暗」・「色調」は撮影段階で揃えておくことが望ましいです。 晴れの日など、短時間の日射量変化が激しい日は撮影に適しません。 また、快晴の日は晴れほど日射量変化は激しくないですが、後述するフレア・ゴーストが発生しやすくなります。 その為、曇りで日射量の少ない日が撮影に適しています。 （画像：理想の天気状況と、晴れた日の影響例） 3-3-2.逆光による光条・ゴーストを発生させない 逆光状態で撮影を行うと、光条やゴーストが発生してしまいます。 これはテクスチャに影響にしてしまうので、撮影角度や撮影時間を変えて、可能な限り発生させないようにします。 どうしても発生してしまう場合は、その写真をアライメントのみに利用し、テクスチャ作成時には取り除きましょう。 （画像：光条・ゴーストの発生例） 3-3-3無風状態のときに撮影する 3-1-5で記載した通り、フォトグラメトリでは撮影物体を静止させる必要があります。 屋外で撮影する場合、風の影響で木や葉が揺れてしまいますので、無風状態を狙って撮影しましょう。 無風状態で撮影できない場合は、別日での撮影を検討します。 （画像：撮影毎に木の枝が動いてしまった例） おわりに 本記事では、フォトグラメトリワークフローの前編として、機材選定に関する部分と撮影前・撮影時の注意ポイントについて紹介しました。 これからフォトグラメトリを始める方で、「どんな機材を揃えたらいいんだろう？」「撮影前や撮影時に何を意識すればいいんだろう？」という悩みを持つ方の一助となれば幸いです。 後編 ではRealityCaptureに取り込む前の現像処理や、RealityCaptureを用いてのモデル作成部分を紹介していきますので、こちらも御一読いただければ幸いです。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ 参考資料 ・ 日本写真印刷コミュニケーションズ株式会社：「フォトグラメトリ」とはどういうもの？ ・ フジヤカメラ：カメラの画素数は多ければいいの！？画素数と画質の関係 高画素のメリット・デメリット ・ フジヤカメラ：PL(偏光)フィルターの効果と使い方、使用例、選び方、特徴 ・ 姫野ばら園：カメラコラム「レンズの焦点距離と画角の変化」 ・ EpicGames：OS and hardware requirements ・ DRONE NAVIGATOR：ドローンとは何か ・ PIX4D：TOOLS - GSD calculator ・ STUDIO DUCKBILL 広域・環境フォトグラメトリの世界 執筆： @matsuzaki.shota 、レビュー： @yamashita.yuki （ Shodo で執筆されました ）

ISID X(クロス) イノベーション 本部 デジタルエンゲージメントセンター の 根本康平 です。 今回は「Teamsを日ごろ利用している・面倒な作業は嫌・作業を自動化させたい・PowerAutomateは良く知らない」という方に向けて、PowerAutomateで何ができるのかをご紹介する記事です。 本記事の前半では、1から簡単な自動化処理を作り「PowerAutomate」についての理解を深めます。 記事の後半では、PowerAutomateで使える機能や「テンプレート」に触れ、簡単に複雑な自動化処理を作ることができることを知っていただければと思います。 PowerAutomateとは フローを作って自動でTeamsのチャネルにメッセージを投稿する 複雑な自動化機能も簡単に作れる PowerAutomateとは 先ほどから数回登場していた「PowerAutomate」は、 Microsoft が提供している業務効率化を目的としたツールです。 自動ワークフローを作ることで、面倒な定型作業や繰り返し作業を人の代わりにやってくれます。 具体的には、「メールを受信したらTeamsに通知が来るようにする」「メールに添付されているファイルをOneDriveに自動保存する」「 Excel データを定期的に加工する」などの作業を自動でやってくれます。 時間の削減はもちろん、単純な作業ミスなども減らすことが可能です。 フローを作って自動でTeamsのチャネルにメッセージを投稿する ここから、15分で出来るTeams自動投稿フローの作り方を紹介します。 なお、PowerAutomateが利用できる環境/ユーザであることを前提とした説明です。 完成するフローで出来ることは次のとおりです。 毎週金曜日 18:00 に特定のTeamsチャネルに自動でメッセージを投稿 自分と上司Aに対してメンション 以下の流れでフローを作成します。 毎週金曜日 18:00 に起動する新しいフローを作る メンションするユーザを決めるアクションを作る メッセージ内容を決め、Teamsに投稿するアクションを作る 動作をテストする それでは、いよいよフロー作成の手順を紹介します。 Teamsアプリを開く 「アプリ」をクリック 「Power Automate」をクリック 「ウェブサイトを表示する」をクリック 「マイフロー」をクリック 「新しいフロー」をクリック 「スケジュール済み クラウド フロー」をクリック フロー名を入力、開始日に任意の日付と時間を入力、繰り返し間隔を1週間、金曜を選択し「作成」をクリック Recurrence をクリック 「詳細オプションを表示する」をクリック 設定時刻（時間）に18、設定時刻（分）に0を入力（これで毎週金曜日の18:00にこのフローが実行されます） 「新しいステップ」をクリック コネクタとアクションを検索する 欄に Teams と入力し、「ユーザーの@mention トーク ンを取得する」をクリック ユーザーの@mention トーク ンを取得する文字の横、 三点リーダ ーをクリックし名前を「自分へのメンション」と変更 ユーザーの欄に自分のユーザ プリンシパル ネーム（基本的にはメールアドレス）を入力 「新しいステップ」をクリック コネクタとアクションを検索する 欄に Teams と入力し、「ユーザーの@mention トーク ンを取得する」をクリック ユーザーの@mention トーク ンを取得するの文字横、 三点リーダ ーをクリックし名前を「上司へのメンション」と変更 ユーザーの欄に上司Aのユーザ プリンシパル ネーム（基本的にはメールアドレス）を入力 「新しいステップ」をクリック コネクタとアクションを検索する 欄に Teams と入力し、「チャットまたはチャネルでメッセージを投稿する」をクリック 投稿者で「フローボット」を選択 投稿先で「Channel」を選択 Teamで［投稿したいTeam］を選択 Channelで［投稿したいChannel］を選択 Messageの Add message をクリック、動的なコンテンツから［上司へのメンション@mention］と［自分へのメンション @mention］をクリック 改行し、投稿に書きたいメッセージを記入 画面右上の「保存」をクリック 画面右上の「テスト」をクリック 「手動」を選択し、「テスト」をクリック 「フローの実行」をクリック（＊実際に動作をテストするものです。本当に自分と上司Aをメンションして投稿がされますのでご注意ください！） 「フロー実行ページ」をクリック 開始時間をクリック、フローがどのように実行されたか確認できます。 テストで実際に指定したChannelにメンション付きの投稿がされたかを確認 「マイフロー」をクリック 今回作成したフローをクリック 「オフにする」をクリック（これを忘れると、毎週金曜日18:00に投稿されてしまうので注意してください！） 15分で出来るTeams自動投稿フロー作成の説明は以上です。 複雑な自動化機能も簡単に作れる 上のハンズオンでは「 ユーザーの@mention トーク ンを取得する 」「 チャットまたはチャネルにメッセージを投稿する 」の2つのアクションしか使用していませんが、他にも様々なアクションが可能です。ご自身で触れる方は、色々と試してみてください。 例えば、「変数」と入力すれば「 変数の設定 」や「 配列変数に追加 」が出来たり、「 条件分岐 」や「 繰り返し 」、「 Excel の情報を取得・更新・削除 」も可能です。「 メールの送信 」や「 AIモデルの構築 」も出来ます。 とはいえ、複雑なフローを作ろうとしたら、時間がかかり途中で挫折してしまうかもしれません。 ですが、様々なフローが「 テンプレート 」として用意されているので、これを使うと楽にフローを作ることができます。 例えば、 Microsoft Formsでアンケートを提出するとメール通知され Sharepoint リストに回答内容が保存されるフロー、ボタンを押したら10分後にTeamsで通知されるフローなど、様々なテンプレートが用意されています。 これらのテンプレートを使いながら、自分流にフローをカスタマイズして利用できます。 面倒な承認作業や勤怠管理などもPowerAutomateを使って効率化できそうですね！ 私の所属しているユニットや部署では、PowerAutomateを使って次のようなことをしています。 毎日の勤怠管理：特定の時間までに勤務開始のアクションがない社員に対して、勤務開始しているかを確認するTeamsメッセージ投稿を自動で行う ポータルサイト のアクションを通知：ユニット内で活用している ポータルサイト に新しい記事が投稿されたりアクションが行われた場合に、特定のTeamsチャネルにメッセージを投稿する 定期的に Excel データの確認と推移グラフの作成：毎月特定の Excel ファイル内のデータを確認し、月ごとにデータがどのように推移したかを表すグラフを作成する 私の所属するユニットでは「作業を効率化するにはどうすればよいか」「メンバー間のコミュニケーションを活発にするためにどうすればよいか」などを定期的に社員同士で話し合い、PowerAutomateをはじめ様々なツールを活用して課題を解決しています。 今回はPowerAutomateを紹介いたしました。他にも、PowerAppsという簡単にアプリを作成できるツールもあったりします。PowerAppsの使い方を紹介するような記事も書くかもしれないので、また見ていただけると嬉しいです！ ISID X(クロス) イノベーション 本部 デジタルエンゲージメントセンター では、 Microsoft Power Platform 、 Dynamics 365 、 Salesforce を用いたDX推進 などをしております。全社的なDX推進や顧客接点の最適化、エンゲージメントの強化などのお困り事がございましたらお気軽にお問合せください。 ISID顧客接点DXソリューションサイトはこちら 私たちは一緒に働いてくれる仲間を募集しています！ 【全社集約】CRMソリューションコンサルタント IT業界に興味のある就活生の皆さま、ぜひご応募ください！ 【新卒採用】ISID リクルートサイト 執筆： @nemoto.kouhei 、レビュー： @fukutake.hiroaki （ Shodo で執筆されました ）

ISID X(クロス) イノベーション 本部 デジタルエンゲージメントセンター の 根本康平 です。 今回は「Teamsを日ごろ利用している・面倒な作業は嫌・作業を自動化させたい・PowerAutomateは良く知らない」という方に向けて、PowerAutomateで何ができるのかをご紹介する記事です。 本記事の前半では、1から簡単な自動化処理を作り「PowerAutomate」についての理解を深めます。 記事の後半では、PowerAutomateで使える機能や「テンプレート」に触れ、簡単に複雑な自動化処理を作ることができることを知っていただければと思います。 PowerAutomateとは フローを作って自動でTeamsのチャネルにメッセージを投稿する 複雑な自動化機能も簡単に作れる PowerAutomateとは 先ほどから数回登場していた「PowerAutomate」は、 Microsoft が提供している業務効率化を目的としたツールです。 自動ワークフローを作ることで、面倒な定型作業や繰り返し作業を人の代わりにやってくれます。 具体的には、「メールを受信したらTeamsに通知が来るようにする」「メールに添付されているファイルをOneDriveに自動保存する」「 Excel データを定期的に加工する」などの作業を自動でやってくれます。 時間の削減はもちろん、単純な作業ミスなども減らすことが可能です。 フローを作って自動でTeamsのチャネルにメッセージを投稿する ここから、15分で出来るTeams自動投稿フローの作り方を紹介します。 なお、PowerAutomateが利用できる環境/ユーザであることを前提とした説明です。 完成するフローで出来ることは次のとおりです。 毎週金曜日 18:00 に特定のTeamsチャネルに自動でメッセージを投稿 自分と上司Aに対してメンション 以下の流れでフローを作成します。 毎週金曜日 18:00 に起動する新しいフローを作る メンションするユーザを決めるアクションを作る メッセージ内容を決め、Teamsに投稿するアクションを作る 動作をテストする それでは、いよいよフロー作成の手順を紹介します。 Teamsアプリを開く 「アプリ」をクリック 「Power Automate」をクリック 「ウェブサイトを表示する」をクリック 「マイフロー」をクリック 「新しいフロー」をクリック 「スケジュール済み クラウド フロー」をクリック フロー名を入力、開始日に任意の日付と時間を入力、繰り返し間隔を1週間、金曜を選択し「作成」をクリック Recurrence をクリック 「詳細オプションを表示する」をクリック 設定時刻（時間）に18、設定時刻（分）に0を入力（これで毎週金曜日の18:00にこのフローが実行されます） 「新しいステップ」をクリック コネクタとアクションを検索する 欄に Teams と入力し、「ユーザーの@mention トーク ンを取得する」をクリック ユーザーの@mention トーク ンを取得する文字の横、 三点リーダ ーをクリックし名前を「自分へのメンション」と変更 ユーザーの欄に自分のユーザ プリンシパル ネーム（基本的にはメールアドレス）を入力 「新しいステップ」をクリック コネクタとアクションを検索する 欄に Teams と入力し、「ユーザーの@mention トーク ンを取得する」をクリック ユーザーの@mention トーク ンを取得するの文字横、 三点リーダ ーをクリックし名前を「上司へのメンション」と変更 ユーザーの欄に上司Aのユーザ プリンシパル ネーム（基本的にはメールアドレス）を入力 「新しいステップ」をクリック コネクタとアクションを検索する 欄に Teams と入力し、「チャットまたはチャネルでメッセージを投稿する」をクリック 投稿者で「フローボット」を選択 投稿先で「Channel」を選択 Teamで［投稿したいTeam］を選択 Channelで［投稿したいChannel］を選択 Messageの Add message をクリック、動的なコンテンツから［上司へのメンション@mention］と［自分へのメンション @mention］をクリック 改行し、投稿に書きたいメッセージを記入 画面右上の「保存」をクリック 画面右上の「テスト」をクリック 「手動」を選択し、「テスト」をクリック 「フローの実行」をクリック（＊実際に動作をテストするものです。本当に自分と上司Aをメンションして投稿がされますのでご注意ください！） 「フロー実行ページ」をクリック 開始時間をクリック、フローがどのように実行されたか確認できます。 テストで実際に指定したChannelにメンション付きの投稿がされたかを確認 「マイフロー」をクリック 今回作成したフローをクリック 「オフにする」をクリック（これを忘れると、毎週金曜日18:00に投稿されてしまうので注意してください！） 15分で出来るTeams自動投稿フロー作成の説明は以上です。 複雑な自動化機能も簡単に作れる 上のハンズオンでは「 ユーザーの@mention トーク ンを取得する 」「 チャットまたはチャネルにメッセージを投稿する 」の2つのアクションしか使用していませんが、他にも様々なアクションが可能です。ご自身で触れる方は、色々と試してみてください。 例えば、「変数」と入力すれば「 変数の設定 」や「 配列変数に追加 」が出来たり、「 条件分岐 」や「 繰り返し 」、「 Excel の情報を取得・更新・削除 」も可能です。「 メールの送信 」や「 AIモデルの構築 」も出来ます。 とはいえ、複雑なフローを作ろうとしたら、時間がかかり途中で挫折してしまうかもしれません。 ですが、様々なフローが「 テンプレート 」として用意されているので、これを使うと楽にフローを作ることができます。 例えば、 Microsoft Formsでアンケートを提出するとメール通知され Sharepoint リストに回答内容が保存されるフロー、ボタンを押したら10分後にTeamsで通知されるフローなど、様々なテンプレートが用意されています。 これらのテンプレートを使いながら、自分流にフローをカスタマイズして利用できます。 面倒な承認作業や勤怠管理などもPowerAutomateを使って効率化できそうですね！ 私の所属しているユニットや部署では、PowerAutomateを使って次のようなことをしています。 毎日の勤怠管理：特定の時間までに勤務開始のアクションがない社員に対して、勤務開始しているかを確認するTeamsメッセージ投稿を自動で行う ポータルサイト のアクションを通知：ユニット内で活用している ポータルサイト に新しい記事が投稿されたりアクションが行われた場合に、特定のTeamsチャネルにメッセージを投稿する 定期的に Excel データの確認と推移グラフの作成：毎月特定の Excel ファイル内のデータを確認し、月ごとにデータがどのように推移したかを表すグラフを作成する 私の所属するユニットでは「作業を効率化するにはどうすればよいか」「メンバー間のコミュニケーションを活発にするためにどうすればよいか」などを定期的に社員同士で話し合い、PowerAutomateをはじめ様々なツールを活用して課題を解決しています。 今回はPowerAutomateを紹介いたしました。他にも、PowerAppsという簡単にアプリを作成できるツールもあったりします。PowerAppsの使い方を紹介するような記事も書くかもしれないので、また見ていただけると嬉しいです！ ISID X(クロス) イノベーション 本部 デジタルエンゲージメントセンター では、 Microsoft Power Platform 、 Dynamics 365 、 Salesforce を用いたDX推進 などをしております。全社的なDX推進や顧客接点の最適化、エンゲージメントの強化などのお困り事がございましたらお気軽にお問合せください。 ISID顧客接点DXソリューションサイトはこちら 私たちは一緒に働いてくれる仲間を募集しています！ 【全社集約】CRMソリューションコンサルタント IT業界に興味のある就活生の皆さま、ぜひご応募ください！ 【新卒採用】ISID リクルートサイト 執筆： @nemoto.kouhei 、レビュー： @fukutake.hiroaki （ Shodo で執筆されました ）

テックブログ編集部の山下です。 今回は自分が登壇するイベントを紹介します。詳細およびお申込みはリンク先サイトを参照してください。 https://techplay.jp/event/913881 参加登録のお願い この発表を行う山下です。 近年リモート開発環境がいくつか台頭してきつつあります。 AWS Codecatalyst、 Google Workstations、 GitHub Codespacesといったものです。 このイベントでは、 GitHub Codespacesと Visual Studio Code のDev Containerを紹介します。 これらの技術を用いることで柔軟で安定した開発環境の構築が可能になります、イベントではこれらの技術のメリット、デメリットや基本的な仕組みについて紹介します。 御興味があるかたは是非登録してみてください。 基本情報 タイトル：乱立する環境、リソースの制約、環境構築にはもう悩まされない！-ストレスフリーな開発を実現する GitHub Codespaces- 日時：2023/09/06(水) 19:00 〜 20:15 形態：オンライン開催 概要 今、ベストな環境で開発に挑めていますか？ テレワークが新たな常態となった今、開発環境におけるあらゆる課題に頭を抱える方も多く、 Yesと答えることのできた方は多くないのではないでしょうか。 コードレビューや デバッグ を行う度に乱立する環境 ローカル環境のセットアップやメンテナンス、バックアップ作業 マシンスペックに左右されて安定しない処理速度 などさまざまな課題の影響により、 開発に割く時間よりも多くの時間を環境整備に費やしているといった方も少なくありません。 開発をスムーズに進めるための最重要事項は、効率的な作業環境で開発者のストレスを軽減することです。 ISIDではストレスフリーな開発環境を作り出すべく、 ソリューションのひとつとして「 GitHub Codespaces」の導入に挑戦。 早速社内プロジェクトで検証を行い、 ・ロケーション違い(社内/社外)での開発や異なるマシンでの作業に合わせた環境構築が不要になった ・環境構築手順が煩雑、不明瞭な場合でも、機能を組み合わせることで手軽に環境を再現できた といったような成果が得られ、今後の利用拡大にも期待が高まっています。 本イベントでは、「 GitHub Codespaces」を採用した理由から導入における挑戦、得られた成果など実例を交えて共有します。 「 GitHub Codespaces」活用から見る、健康的なソフトウェア開発のためのヒント満載な1時間15分をお楽しみに！ 執筆： @yamashita.tsuyoshi 、レビュー： @sato.taichi （ Shodo で執筆されました ）

テックブログ編集部の山下です。 今回は自分が登壇するイベントを紹介します。詳細およびお申込みはリンク先サイトを参照してください。 https://techplay.jp/event/913881 参加登録のお願い この発表を行う山下です。 近年リモート開発環境がいくつか台頭してきつつあります。 AWS Codecatalyst、 Google Workstations、 GitHub Codespacesといったものです。 このイベントでは、 GitHub Codespacesと Visual Studio Code のDev Containerを紹介します。 これらの技術を用いることで柔軟で安定した開発環境の構築が可能になります、イベントではこれらの技術のメリット、デメリットや基本的な仕組みについて紹介します。 御興味があるかたは是非登録してみてください。 基本情報 タイトル：乱立する環境、リソースの制約、環境構築にはもう悩まされない！-ストレスフリーな開発を実現する GitHub Codespaces- 日時：2023/09/06(水) 19:00 〜 20:15 形態：オンライン開催 概要 今、ベストな環境で開発に挑めていますか？ テレワークが新たな常態となった今、開発環境におけるあらゆる課題に頭を抱える方も多く、 Yesと答えることのできた方は多くないのではないでしょうか。 コードレビューや デバッグ を行う度に乱立する環境 ローカル環境のセットアップやメンテナンス、バックアップ作業 マシンスペックに左右されて安定しない処理速度 などさまざまな課題の影響により、 開発に割く時間よりも多くの時間を環境整備に費やしているといった方も少なくありません。 開発をスムーズに進めるための最重要事項は、効率的な作業環境で開発者のストレスを軽減することです。 ISIDではストレスフリーな開発環境を作り出すべく、 ソリューションのひとつとして「 GitHub Codespaces」の導入に挑戦。 早速社内プロジェクトで検証を行い、 ・ロケーション違い(社内/社外)での開発や異なるマシンでの作業に合わせた環境構築が不要になった ・環境構築手順が煩雑、不明瞭な場合でも、機能を組み合わせることで手軽に環境を再現できた といったような成果が得られ、今後の利用拡大にも期待が高まっています。 本イベントでは、「 GitHub Codespaces」を採用した理由から導入における挑戦、得られた成果など実例を交えて共有します。 「 GitHub Codespaces」活用から見る、健康的なソフトウェア開発のためのヒント満載な1時間15分をお楽しみに！ 執筆： @yamashita.tsuyoshi 、レビュー： @sato.taichi （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 今回は前回に引き続き、 UE5でパフォーマンスを担保するために必要な、プロファイリングのワークフローCPU編の説明を行います。 UEでは、制作したプロジェクトの性能を測るためにプロファイリングという作業を行います。 プロファイリングは、主にパフォーマンス改善を目的として実施します。例えばコマンドや専用のアプリケーションを使用して、描画に遅延が起こっていないか、不要な処理をしているBlueprintがないか、などを調べます。 前回の記事（プロファイリングのワークフローGPU編）はこちら になります。 検証環境/ツール OS： Windows 11 pro GPU ： NVIDIA GeForce RTX 4070 Ti Game Engine： Unreal Engine 5.2.0 実装手順 「stat unit」コマンドの実施 Gamesの処理が重い場合の対処方法 2-1. Unreal Insightsの使い方 2-2. Session Frontendの使い方 2-3. 遅延原因の特定方法 1. 「stat unit」コマンドの実施 前回に引き続き、「stat unit」コマンドについて説明します。 前回の記事（プロファイリングのワークフローGPU編） に詳しい「stat unit」の紹介があるのでそちらも参考にしてください。 GPU 編でも紹介しましたが、「stat unit」の主要な項目は下記になります。 Frame : 画面を描画するのにかかった処理時間。60FPSのゲームを作成する場合は、16.6ms以下になるように調整しないといけない Game : リアルタイムで動作するゲームのロジックやアニメーションにかかるCPUの処理時間 Draw : 何を描画するか、選択や計算をするためにかかるCPUの処理時間 GPU Time : メッシュや各マテリアルの描画や、ライティングなどにかかる GPU の処理時間 Draws : 描画する必要のあるメッシュの個数。 GPU Timeに影響を与える 対象オブジェクトを整理したり、Naniteを利用してメッシュ数の調整を行うことで、 GPU に関連する値を下げることはできましたが、依然として「Game」の値が高いので、調査、修正を行っていきます。 2. Gamesの処理が重い場合の対処方法 Gameの処理が重い場合は2つの事象が考えられます。 カリングやLODなどを使用してレベル内のどのオブジェクトを描画するか、事前に計算するためにCPUを使用している ゲームプレイ中のキャ ラク ターの動作や、アクター、その他のBlueprintの処理や計算をするためにCPUを使用している 今回はゲームプレイ中のBlueprintの挙動について、プロファイリング方法を紹介します。 カリングやLODに関しては、本記事では割愛いたします。 2-1. Unreal Insightsの使い方 Unreal Insightsは、 Unreal Engine に標準で搭載されているプロファイリングシステムのことで、 データの収集、分析、および視覚化を行ってくれます。 今回はこのシステムを使用して、アプリの ボトルネック を探しパフォーマンスを向上させていきます。 まず Unreal Insightsを開いていきます。 UEをダウンロードする際に同時にダウンロードされているので、下記画像のように UE ＞ Engine ＞ Binaries ＞ Win64 の中にある「UnrealInsights.exe」を開きます。 アプリケーションが開きますが、今は一旦このまま置いておきます。 （下の画像ではいくつかデータが入っていますが、初めて開いた場合はデータには何も入っていません。） 次にゲーム起動時にプロファイリング用のデータを作成する設定を行います。 UEのエディタの環境設定から、プレイ ＞ 追加の起動パラメータ の欄に下記コマンドを追加します。 -trace=cpu,frame,bookmark,log -statnamedevents このコマンドにより、 スタンドアロン モードでゲームを開始した時、ログとしてプロファイリング用のデータが Unreal Insightsで参照可能な形式で作成されます。 スタンドアロン モードでゲームを起動中に Unreal Insightsを開くとデータが「LIVE」で作成されているのを確認できます。 起動後10秒くらいしたらゲームを終了し、作成されたデータを Unreal Insightsで確認します。 今回はゲームを起動するためのプロファイリングではなく、通常ゲーム時のプロファイリングを行いたいので、 下の画像右側の、安定し始めた部分のデータを調査します。 右側の部分をクローズアップした画像がこちらです。 上段のピンクと黄緑の帯でFEngineLoopと書かれている部分があります。 これが1フレームの処理になり、今回の場合だと180msほどかかってしまっています。 （60FPSのゲームを目指す場合は16.6ms以下を目指さないといけない） 次にもう少し細かく見ていきます。 1フレームの処理の中で時間のかかっていそうな処理を調べていきます。 このデータの見方は、上から順に処理が細かくなっていき、各処理の流れは右方向に進んでいきます。 何度もプロファイリングを行っている人なら、パッと見ただけでどこら辺がおかしいのかわかるのかもしれないですが、 自分はまだ初学者なので少しずつ解読します。 細分化されている下の方の処理で、明らかに長い時間がかかってしまっている処理が、紫色の帯のFunctionという部分になります。 1フレーム全体で180msほどかかっているのに対し、このFunctionで177.9msもの時間を使っているようなので、ほぼこの処理のせいで遅くなっているように見えます。 このFunctionの親を見てみるとBlueprint Timeと書かれた帯があるので、ここではBlueprintに問題があるのかな、くらいまでわかります。 Unreal Insightsは、処理全体の流れや、どこら辺で問題が起きているかなどを見るために使います。 しかし、Blueprintのひとつひとつまで詳しくみることはできないので、次は別のプロファイリングシステムを使ってもう少し深ぼっていきます。 2-2. Session Frontendの使い方 Session Frontendも、 Unreal Insightsと同様、 Unreal Engine に標準で搭載されているプロファイリングシステムのことで、 データの収集、分析、および視覚化を行ってくれます。 Unreal Insightとの違いは、Session Frontendの方が、より詳しくファンクションの中身を見ていくことができますが、一方で Unreal Insightsほど可視性がよくないです。 そのため、 Unreal Insightsで大体の処理の流れと問題点のあたりをつけ、Session Frontendで詳しく見ていく流れが良いと思います。 Session Frontendを使うためにも専用のセッションデータが必要になるので、コマンドでデータを作成します。 UEのゲームを開始した上で、画面下部のアウトプットログタブから、コマンド入力欄に「stat startfile」と入力します。 コマンドを入力するとゲーム画面上にプロファイリング中の文字が表示されます。 こちらも同じく10秒ほど待機してから、コマンド入力欄に「stat stopfile」と入力します。 これでデータが取得できました。 画面上部のツールタブからセッションフロントエンドを選択し、画面を表示させます。 プロファイラのタブへ移動し、画面中央上部のファイルをロードボタンを押下します。 ファイル選択画面になるので、最新のフォルダを選択します。 （初めて行う際は一つしかフォルダが表示されないはずです。） フォルダを選択するとプロファイラ画面にデータが表示されます。 今回使用するのは右下のイベント名と書かれた部分になります。 通常ゲーム時のプロファイリングを行いたい場合は、イベント名から「GameThread」を選択します。 その後は、 Unreal Insightsで表示があった「FrameTime」を選択し、処理時間がかかっているタブをどんどん開いていきます。 今回の場合は、最終的にファンクション名まで行き着きました。 Function/Game/ThirdPerson/Blueprints/BP_ThirdPersonCharacter.BP_ThirdPersonCharacter_C.MeanlessFunction 「BP_ThirdPersonCharacter」の「MeanlessFunction」というファンクションに時間がかかってしまっているようなので、検証します。 2-3. 遅延原因の特定方法 Unreal InsightsとSession Frontendを利用して、遅延の原因になっていそうなファンクションを特定したので、実際にUE画面から調査してみます。 BP_ThirdPersonCharacterのファイルを開き、Blueprintを確認します。 ファイル内に「Meanless Function」というファンクションが「イベントTick」につながっており、毎フレームごとに呼ばれてしまっていることがわかります。 ファンクションの内部に移動すると、文字通り、意味のない処理をFor文で2万回も行っていました。 1フレームごとに2万回、print stringをしていると考えると恐ろしいバグです。 （もちろん仕込みです。すみません。） この「Meanless Function」を削除し、もう一度ゲームを開始してみます。 見事「Game」の数値が改善され「Frame」も60FPSに対応できる数値まで改善できました。 念の為 Unreal InsightsやSession Frontendも確認しましたが、修正前と比べ異常な処理時間がかかっている部分がなくなっているのを確認できました。 おわりに 今回は、前回に引き続き、UE5を利用してプロファイリングの方法を説明してきました。 今回学習した、 GPU で問題になっている箇所を探して対策を行い、その次にCPUで問題になっている箇所を探すフローは、 今後の実際の現場でも使っていけるのではないかと感じています。 もちろん実際のプロジェクトでは、より複雑に原因が入り組んでいることが想像できるので、 基礎の勉強をしつつ、実際のプロファイリングもどんどん行っていきたいです。 まだ 前回の記事（プロファイリングのワークフローGPU編） をご覧になっていない方は、そちらも是非読んでいただけると嬉しいです。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 参考 https://qiita.com/donbutsu17/items/159dfaacfac6a4b1392d https://docs.unrealengine.com/4.27/ja/TestingAndOptimization/PerformanceAndProfiling/UnrealInsights/ https://hub.vive.com/storage/docs/en-us/UnrealPlugin/UnrealProfiler.html 執筆： @okazaki.wataru 、レビュー： @yamada.y （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 今回は前回に引き続き、 UE5でパフォーマンスを担保するために必要な、プロファイリングのワークフローCPU編の説明を行います。 UEでは、制作したプロジェクトの性能を測るためにプロファイリングという作業を行います。 プロファイリングは、主にパフォーマンス改善を目的として実施します。例えばコマンドや専用のアプリケーションを使用して、描画に遅延が起こっていないか、不要な処理をしているBlueprintがないか、などを調べます。 前回の記事（プロファイリングのワークフローGPU編）はこちら になります。 検証環境/ツール OS： Windows 11 pro GPU ： NVIDIA GeForce RTX 4070 Ti Game Engine： Unreal Engine 5.2.0 実装手順 「stat unit」コマンドの実施 Gamesの処理が重い場合の対処方法 2-1. Unreal Insightsの使い方 2-2. Session Frontendの使い方 2-3. 遅延原因の特定方法 1. 「stat unit」コマンドの実施 前回に引き続き、「stat unit」コマンドについて説明します。 前回の記事（プロファイリングのワークフローGPU編） に詳しい「stat unit」の紹介があるのでそちらも参考にしてください。 GPU 編でも紹介しましたが、「stat unit」の主要な項目は下記になります。 Frame : 画面を描画するのにかかった処理時間。60FPSのゲームを作成する場合は、16.6ms以下になるように調整しないといけない Game : リアルタイムで動作するゲームのロジックやアニメーションにかかるCPUの処理時間 Draw : 何を描画するか、選択や計算をするためにかかるCPUの処理時間 GPU Time : メッシュや各マテリアルの描画や、ライティングなどにかかる GPU の処理時間 Draws : 描画する必要のあるメッシュの個数。 GPU Timeに影響を与える 対象オブジェクトを整理したり、Naniteを利用してメッシュ数の調整を行うことで、 GPU に関連する値を下げることはできましたが、依然として「Game」の値が高いので、調査、修正を行っていきます。 2. Gamesの処理が重い場合の対処方法 Gameの処理が重い場合は2つの事象が考えられます。 カリングやLODなどを使用してレベル内のどのオブジェクトを描画するか、事前に計算するためにCPUを使用している ゲームプレイ中のキャ ラク ターの動作や、アクター、その他のBlueprintの処理や計算をするためにCPUを使用している 今回はゲームプレイ中のBlueprintの挙動について、プロファイリング方法を紹介します。 カリングやLODに関しては、本記事では割愛いたします。 2-1. Unreal Insightsの使い方 Unreal Insightsは、 Unreal Engine に標準で搭載されているプロファイリングシステムのことで、 データの収集、分析、および視覚化を行ってくれます。 今回はこのシステムを使用して、アプリの ボトルネック を探しパフォーマンスを向上させていきます。 まず Unreal Insightsを開いていきます。 UEをダウンロードする際に同時にダウンロードされているので、下記画像のように UE ＞ Engine ＞ Binaries ＞ Win64 の中にある「UnrealInsights.exe」を開きます。 アプリケーションが開きますが、今は一旦このまま置いておきます。 （下の画像ではいくつかデータが入っていますが、初めて開いた場合はデータには何も入っていません。） 次にゲーム起動時にプロファイリング用のデータを作成する設定を行います。 UEのエディタの環境設定から、プレイ ＞ 追加の起動パラメータ の欄に下記コマンドを追加します。 -trace=cpu,frame,bookmark,log -statnamedevents このコマンドにより、 スタンドアロン モードでゲームを開始した時、ログとしてプロファイリング用のデータが Unreal Insightsで参照可能な形式で作成されます。 スタンドアロン モードでゲームを起動中に Unreal Insightsを開くとデータが「LIVE」で作成されているのを確認できます。 起動後10秒くらいしたらゲームを終了し、作成されたデータを Unreal Insightsで確認します。 今回はゲームを起動するためのプロファイリングではなく、通常ゲーム時のプロファイリングを行いたいので、 下の画像右側の、安定し始めた部分のデータを調査します。 右側の部分をクローズアップした画像がこちらです。 上段のピンクと黄緑の帯でFEngineLoopと書かれている部分があります。 これが1フレームの処理になり、今回の場合だと180msほどかかってしまっています。 （60FPSのゲームを目指す場合は16.6ms以下を目指さないといけない） 次にもう少し細かく見ていきます。 1フレームの処理の中で時間のかかっていそうな処理を調べていきます。 このデータの見方は、上から順に処理が細かくなっていき、各処理の流れは右方向に進んでいきます。 何度もプロファイリングを行っている人なら、パッと見ただけでどこら辺がおかしいのかわかるのかもしれないですが、 自分はまだ初学者なので少しずつ解読します。 細分化されている下の方の処理で、明らかに長い時間がかかってしまっている処理が、紫色の帯のFunctionという部分になります。 1フレーム全体で180msほどかかっているのに対し、このFunctionで177.9msもの時間を使っているようなので、ほぼこの処理のせいで遅くなっているように見えます。 このFunctionの親を見てみるとBlueprint Timeと書かれた帯があるので、ここではBlueprintに問題があるのかな、くらいまでわかります。 Unreal Insightsは、処理全体の流れや、どこら辺で問題が起きているかなどを見るために使います。 しかし、Blueprintのひとつひとつまで詳しくみることはできないので、次は別のプロファイリングシステムを使ってもう少し深ぼっていきます。 2-2. Session Frontendの使い方 Session Frontendも、 Unreal Insightsと同様、 Unreal Engine に標準で搭載されているプロファイリングシステムのことで、 データの収集、分析、および視覚化を行ってくれます。 Unreal Insightとの違いは、Session Frontendの方が、より詳しくファンクションの中身を見ていくことができますが、一方で Unreal Insightsほど可視性がよくないです。 そのため、 Unreal Insightsで大体の処理の流れと問題点のあたりをつけ、Session Frontendで詳しく見ていく流れが良いと思います。 Session Frontendを使うためにも専用のセッションデータが必要になるので、コマンドでデータを作成します。 UEのゲームを開始した上で、画面下部のアウトプットログタブから、コマンド入力欄に「stat startfile」と入力します。 コマンドを入力するとゲーム画面上にプロファイリング中の文字が表示されます。 こちらも同じく10秒ほど待機してから、コマンド入力欄に「stat stopfile」と入力します。 これでデータが取得できました。 画面上部のツールタブからセッションフロントエンドを選択し、画面を表示させます。 プロファイラのタブへ移動し、画面中央上部のファイルをロードボタンを押下します。 ファイル選択画面になるので、最新のフォルダを選択します。 （初めて行う際は一つしかフォルダが表示されないはずです。） フォルダを選択するとプロファイラ画面にデータが表示されます。 今回使用するのは右下のイベント名と書かれた部分になります。 通常ゲーム時のプロファイリングを行いたい場合は、イベント名から「GameThread」を選択します。 その後は、 Unreal Insightsで表示があった「FrameTime」を選択し、処理時間がかかっているタブをどんどん開いていきます。 今回の場合は、最終的にファンクション名まで行き着きました。 Function/Game/ThirdPerson/Blueprints/BP_ThirdPersonCharacter.BP_ThirdPersonCharacter_C.MeanlessFunction 「BP_ThirdPersonCharacter」の「MeanlessFunction」というファンクションに時間がかかってしまっているようなので、検証します。 2-3. 遅延原因の特定方法 Unreal InsightsとSession Frontendを利用して、遅延の原因になっていそうなファンクションを特定したので、実際にUE画面から調査してみます。 BP_ThirdPersonCharacterのファイルを開き、Blueprintを確認します。 ファイル内に「Meanless Function」というファンクションが「イベントTick」につながっており、毎フレームごとに呼ばれてしまっていることがわかります。 ファンクションの内部に移動すると、文字通り、意味のない処理をFor文で2万回も行っていました。 1フレームごとに2万回、print stringをしていると考えると恐ろしいバグです。 （もちろん仕込みです。すみません。） この「Meanless Function」を削除し、もう一度ゲームを開始してみます。 見事「Game」の数値が改善され「Frame」も60FPSに対応できる数値まで改善できました。 念の為 Unreal InsightsやSession Frontendも確認しましたが、修正前と比べ異常な処理時間がかかっている部分がなくなっているのを確認できました。 おわりに 今回は、前回に引き続き、UE5を利用してプロファイリングの方法を説明してきました。 今回学習した、 GPU で問題になっている箇所を探して対策を行い、その次にCPUで問題になっている箇所を探すフローは、 今後の実際の現場でも使っていけるのではないかと感じています。 もちろん実際のプロジェクトでは、より複雑に原因が入り組んでいることが想像できるので、 基礎の勉強をしつつ、実際のプロファイリングもどんどん行っていきたいです。 まだ 前回の記事（プロファイリングのワークフローGPU編） をご覧になっていない方は、そちらも是非読んでいただけると嬉しいです。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 参考 https://qiita.com/donbutsu17/items/159dfaacfac6a4b1392d https://docs.unrealengine.com/4.27/ja/TestingAndOptimization/PerformanceAndProfiling/UnrealInsights/ https://hub.vive.com/storage/docs/en-us/UnrealPlugin/UnrealProfiler.html 執筆： @okazaki.wataru 、レビュー： @yamada.y （ Shodo で執筆されました ）

こんにちは、X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの大西です。現在、TypeScriptとReactを使ってWebアプリを開発していますが、フロントエンドの実装を任された際に Linkify と MUI(Material UI) を合わせて使う場面がありました。LinkifyとMUIのコラボ実装はあまり記事がなかったので記事を書いてみました。 Linkifyとは？ MUI(Material UI)とは？ LinkifyとMUIを一緒に使う まとめ Linkifyとは？ Reactでテキスト内のURLをリンクにしたい場面があったとします。こんな感じですね。 Linkifyとは、文字列にURLが含まれているときに自動でリンク化する際に使えるライブラリです。 このように自動でリンク化する方法を探すと、Linkifyを入れて3つほど方法がありました。 Linkifyを使う react-string-replace を使う 自前で実装する 2のreact-string-replaceは1のLinkifyに比べ GitHub のFork数やstar数が少なく、3の自前実装は、 dangerouslySetInnerHTML という関数を使わなければいけなかったため今回はLinkifyを使うことにしました。Linkifyは ドキュメント もしっかり整備されていて、 XSS(クロスサイトスクリプティング)攻撃に対して脆弱にならないような方法 も示されていたのでとても良かったです。 MUI(Material UI)とは？ MUIはReactアプリケーションを構築するのに使えるUI コンポーネント の巨大なライブラリです。基礎的なUI要素から高度なUI要素までそろっており、カスタマイズ可能なライブラリが備わっています。基本的に無料で利用できますが、一部有料のライブラリもあります。MUIを使うと、例えば 表(テーブル) や プログレスバー にしても、自分で一から実装するより簡単に実現できます。 MUIを使用して作った表↓ MUIを使用して作った プログレスバー ↓ LinkifyとMUIを一緒に使う Reactアプリを開発している中で、LinkifyとMUIを同時に使いたい場面が出てきました。例えばMUIの Linkコンポーネント とLinkifyを同時に使いたい場合です。LinkifyはもちろんLink コンポーネント を使わなくても以下のように書くと文字列をリンク化できます。 < Linkify > { props.content } < /Linkify > しかし、チーム内であらかじめ統一して作っておいたカスタムリンク コンポーネント （今回は「CustomLink」というカスタムリンク コンポーネント があったとします）を使いたい場合は少し工夫が必要で、 renderオプション が必要です。renderオプションを用いると、リンク要素の生成方法をオーバーライドできます。ターゲットリンクの中間表現（IntermediateRepresentation。タグ名、属性、テキストコンテンツ等を含むオブジェクト）を受け入れる関数を指定し、戻り値は、文字列、HTML 要素、または インターフェイス 固有のエンティティにします。render関数は、結果 （属性、コンテンツなど）を引数として他のすべてのオプションが計算された後に実行されます。実装すると以下のようになります。 チーム内で統一して定義したカスタムリンク コンポーネント ↓ import { Link , LinkProps } from "@mui/material" ; export const CustomLink = ( props: LinkProps ) : JSX. Element => { const { href , children , ...other } = props ; return ( < Link { ...other } href = { href } target = "_blank" rel = "noopener noreferrer" color = "#FF0000" ...などチーム内で設定したオプション > { children } < /Link > ); } ; 上記のカスタムリンク コンポーネント を使えるように新しい コンポーネント を作成する↓ import { IntermediateRepresentation } from "linkifyjs" ; import { CustomLink } from "CustomLinkを定義したファイル" ; export const renderLink = ( ir: IntermediateRepresentation ) : JSX. Element => { return < CustomLink { ...ir.attributes } > { ir.content } < /CustomLink >; } ; そして、CustomLinkをリンク化したいコンテンツを表示する tsx ファイルに持っていき、renderオプションに渡す↓ < Linkify options = {{ render: renderLink }} > { props.content } < /Linkify > としてやれば、チーム内で統一して使っているカスタムリンク コンポーネント を使って、文字列内のURLをリンク化できます！IntermediateRepresentationについて補足ですが、 ・ir.attributes 内に href プロパティなどaタグの属性が渡ってくる ・ir.content はリンクの表記が渡ってくる という仕様になっています。 ちなみにLink コンポーネント を扱う際に target="_blank" をつける場合は、 rel="noopener" と rel="noreferrer" オプションをつけてあげると安心です。target="_blank"をつけるとリンクをクリックしたときに別タブでリンク先のページが開きますが、開いた先のページが悪意ある者によって作成されたページであった場合、 リンク元 のページを操作される危険があります。しかしrel="noopener noreferrer"をつけてあげることで、 リンク元 のページが操作されるのを防いだり、 リンク元 の情報を渡さないようにできます。 まとめ このように、LinkifyとMUIを一緒に使うことで、チーム内で統一して使っているカスタムリンク コンポーネント を使って文字列内のURLをリンク化できます。LinkifyはURLだけでなく、メールアドレスもリンク化できますし、 プラグイン を使用すれば Twitter の ハッシュタグ やメンション、 IPアドレス 、また自分が指定したキーワードも検出してリンク化できてしまいます！便利な オプション もそろっているので、ぜひ使ってみてください！ 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア 執筆： @onishi.mayu 、レビュー： @kano.nanami （ Shodo で執筆されました ）

こんにちは、X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの大西です。現在、TypeScriptとReactを使ってWebアプリを開発していますが、フロントエンドの実装を任された際に Linkify と MUI(Material UI) を合わせて使う場面がありました。LinkifyとMUIのコラボ実装はあまり記事がなかったので記事を書いてみました。 Linkifyとは？ MUI(Material UI)とは？ LinkifyとMUIを一緒に使う まとめ Linkifyとは？ Reactでテキスト内のURLをリンクにしたい場面があったとします。こんな感じですね。 Linkifyとは、文字列にURLが含まれているときに自動でリンク化する際に使えるライブラリです。 このように自動でリンク化する方法を探すと、Linkifyを入れて3つほど方法がありました。 Linkifyを使う react-string-replace を使う 自前で実装する 2のreact-string-replaceは1のLinkifyに比べ GitHub のFork数やstar数が少なく、3の自前実装は、 dangerouslySetInnerHTML という関数を使わなければいけなかったため今回はLinkifyを使うことにしました。Linkifyは ドキュメント もしっかり整備されていて、 XSS(クロスサイトスクリプティング)攻撃に対して脆弱にならないような方法 も示されていたのでとても良かったです。 MUI(Material UI)とは？ MUIはReactアプリケーションを構築するのに使えるUI コンポーネント の巨大なライブラリです。基礎的なUI要素から高度なUI要素までそろっており、カスタマイズ可能なライブラリが備わっています。基本的に無料で利用できますが、一部有料のライブラリもあります。MUIを使うと、例えば 表(テーブル) や プログレスバー にしても、自分で一から実装するより簡単に実現できます。 MUIを使用して作った表↓ MUIを使用して作った プログレスバー ↓ LinkifyとMUIを一緒に使う Reactアプリを開発している中で、LinkifyとMUIを同時に使いたい場面が出てきました。例えばMUIの Linkコンポーネント とLinkifyを同時に使いたい場合です。LinkifyはもちろんLink コンポーネント を使わなくても以下のように書くと文字列をリンク化できます。 < Linkify > { props.content } < /Linkify > しかし、チーム内であらかじめ統一して作っておいたカスタムリンク コンポーネント （今回は「CustomLink」というカスタムリンク コンポーネント があったとします）を使いたい場合は少し工夫が必要で、 renderオプション が必要です。renderオプションを用いると、リンク要素の生成方法をオーバーライドできます。ターゲットリンクの中間表現（IntermediateRepresentation。タグ名、属性、テキストコンテンツ等を含むオブジェクト）を受け入れる関数を指定し、戻り値は、文字列、HTML 要素、または インターフェイス 固有のエンティティにします。render関数は、結果 （属性、コンテンツなど）を引数として他のすべてのオプションが計算された後に実行されます。実装すると以下のようになります。 チーム内で統一して定義したカスタムリンク コンポーネント ↓ import { Link , LinkProps } from "@mui/material" ; export const CustomLink = ( props: LinkProps ) : JSX. Element => { const { href , children , ...other } = props ; return ( < Link { ...other } href = { href } target = "_blank" rel = "noopener noreferrer" color = "#FF0000" ...などチーム内で設定したオプション > { children } < /Link > ); } ; 上記のカスタムリンク コンポーネント を使えるように新しい コンポーネント を作成する↓ import { IntermediateRepresentation } from "linkifyjs" ; import { CustomLink } from "CustomLinkを定義したファイル" ; export const renderLink = ( ir: IntermediateRepresentation ) : JSX. Element => { return < CustomLink { ...ir.attributes } > { ir.content } < /CustomLink >; } ; そして、CustomLinkをリンク化したいコンテンツを表示する tsx ファイルに持っていき、renderオプションに渡す↓ < Linkify options = {{ render: renderLink }} > { props.content } < /Linkify > としてやれば、チーム内で統一して使っているカスタムリンク コンポーネント を使って、文字列内のURLをリンク化できます！IntermediateRepresentationについて補足ですが、 ・ir.attributes 内に href プロパティなどaタグの属性が渡ってくる ・ir.content はリンクの表記が渡ってくる という仕様になっています。 ちなみにLink コンポーネント を扱う際に target="_blank" をつける場合は、 rel="noopener" と rel="noreferrer" オプションをつけてあげると安心です。target="_blank"をつけるとリンクをクリックしたときに別タブでリンク先のページが開きますが、開いた先のページが悪意ある者によって作成されたページであった場合、 リンク元 のページを操作される危険があります。しかしrel="noopener noreferrer"をつけてあげることで、 リンク元 のページが操作されるのを防いだり、 リンク元 の情報を渡さないようにできます。 まとめ このように、LinkifyとMUIを一緒に使うことで、チーム内で統一して使っているカスタムリンク コンポーネント を使って文字列内のURLをリンク化できます。LinkifyはURLだけでなく、メールアドレスもリンク化できますし、 プラグイン を使用すれば Twitter の ハッシュタグ やメンション、 IPアドレス 、また自分が指定したキーワードも検出してリンク化できてしまいます！便利な オプション もそろっているので、ぜひ使ってみてください！ 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア 執筆： @onishi.mayu 、レビュー： @kano.nanami （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 ゲームや動画などを作成する際に、ユーザーが違和感なくコンテンツを使用するためには、 フレームごとの描画速度（フレームレート）を意識し、パフォーマンスを担保し続ける必要があります。 今回はUE5でパフォーマンスを担保するために必要な、プロファイリングのワークフローの説明を行います。 はじめに UEでは、制作したプロジェクトの性能を測るためにプロファイリングという作業を行います。 プロファイリングは、主にパフォーマンス改善を目的として実施します。例えばコマンドや専用のアプリケーションを使用して、描画に遅延が起こっていないか、不要な処理をしているBlueprintがないか、などを調べます。 今回の記事では、UEの基礎的なプロファイリングの方法（ GPU 編）について紹介していきます。 CPUに関しては記事が長くなるので、次の記事でご紹介します。 検証環境/ツール OS： Windows 11 pro GPU ： NVIDIA GeForce RTX 4070 Ti Game Engine： Unreal Engine 5.2.0 実装手順 「stat unit」コマンドの実施 Drawsが多い場合の対処方法 2-1. 対象メッシュの確認、削除 2-2. Naniteの設定（UE5の場合） 1. 「stat unit」コマンドの実施 まず初めに、「stat unit」コマンドについて説明していきます。 UEではさまざまな方法でプロジェクトのプロファイリングを行う方法があります。 「stat unit」はプロジェクト全体を俯瞰し、大体どの辺に致命的なバグや遅延の原因があるかなどを調べるのに適したコマンドになります。 「stat unit」コマンドを使用するためには、 デバッグ したいプロジェクトを開き、画面下部よりアウトプットタブを押下し、 コマンド入力スペースに「stat unit」を記述します。 画面上に画像のようなログが出てきます。 主要な項目の説明をします。 Frame : 画面を描画するのにかかった処理時間。60FPSのゲームを作成する場合は、16.6ms以下になるように調整しないといけない Game : リアルタイムで動作するゲームのロジックやアニメーションにかかるCPUの処理時間 Draw : 何を描画するか、選択や計算をするためにかかるCPUの処理時間 GPU Time : メッシュや各マテリアルの描画や、ライティングなどにかかる GPU の処理時間 Draws : 描画する必要のあるメッシュの個数。 GPU Timeに影響を与える またGameなどの数値は、ゲームをプレイしている最中にBlueprintなどに連動して数値が変動するので、 ゲームをプレイしてキャ ラク ターの操作などを行った際の数値も確かめる必要があります。 今回は GPU 編なので、「stat unit」の結果から、 「Draw」、「Draws」の数値を調査、修正を行っていきます。 その他の項目のCPUに関わる箇所は次の記事で紹介するので、本記事では割愛します。 2. Drawsが多い場合の対処方法 Drawsの数値が大きい場合は、メッシュが大量に配置されていたり、ポリゴン数の多すぎる複雑なメッシュが配置されてしまっている可能性があります。 今回は、16.6msを超えているため、正常時は緑に表示される数字が赤文字になっています。 この Drawsの数値が大きいように感じたので調査していきます。 まずはレベル上にどのようなメッシュやポリゴンがあるか確認していきます。 2-1. 対象メッシュの確認、削除 画面上部のツールから、オーディット＞統計 を選びます。 すると別画面でレベル内に配置されているメッシュのポリゴン数を確認することが出来ます。 「Tris」と書かれている部分がポリゴン数で、「Sum Tris」と書かれている部分が合計のポリゴン数になります。 今回の統計では、「SM_Movehuman」というオブジェクトの「Count」が「31,834」になっており、「Sum Tris」の数値も非常に高くなっています。 一般的にポリゴン数は下記の 閾値 を参考にすると良いとされています。 2000から3000までが理想 5000を超えると重たくなり始める 10000を超えると問題が起こり始める このためDrawの数値が大きくなっていることが考えられます。 プロジェクトに戻って確認してみると、 実はこのレベルには大量の「SM_Movehuman」のアクターを配置していたことがわかりました。 もちろんこのプロジェクトは処理を重くすることを目的に作成しているので簡単に発見できましたが、 実際のプロジェクトでは、ここまで単純に問題を発見することはなかなか出来ません。 しかし、統計を見ながらレベルに配置してあるオブジェクトの個数や、ポリゴン数を確認し、大体のあたりをつけるのにはとても有効な手段です。 今回のように、オブジェクトが大量にあり「Draws」の数値が非常に高い場合の対処法は大きく3つあります。 無駄なオブジェクトの削除 UE5で追加された「Nanite」を使用 オクルージョンカリングの設定 ※オクルージョンカリングの設定方法は本記事では説明しません。次回以降の記事で紹介する予定です。 まずは無駄なオブジェクトの削除を試します。 本プロジェクトでは、「SM_Movehuman」のアクターをすべて削除してみます。 「stat unit」の値を確認してみます。 「Draws」の値が下がり、「Draw」にかかる処理速度も短くなっていることが確認できます。 アクター削除前 アクター削除後 また、本プロジェクトでは割愛しますが、統計内の「Count」の数を下げなくとも、そもそものポリゴン数を少ないものを用意するのも有効です。 もし配置してあるオブジェクトが全て必要なもので、削除できない場合は次の手段を試します。 2-2. Naniteの設定（UE5の場合） Naniteとは まず Nanite を簡単に説明をします。 Nanite とは、UE5から搭載された、3Dモデルを効率的にかつ高速に レンダリング してくれるシステムで、LODを自動で行ってくれます。 LODというのは Level of Detail の略で、ひとつのオブジェクトに対し、複数の粗さの違うメッシュを作成し、 カメラが遠くにあるときには粗く軽いメッシュを使用し、近くにあるときは細かく正確なメッシュを使用する描画方法です。 これによりユーザーに違和感やメッシュの粗さを感じさせずに、描画速度を上げることができます。 Naniteが搭載される前は、これらの複数のメッシュを用意し、距離を計算し配置する作業は手作業で行っていましたが、 LODがNaniteによって自動化され、手作業でやるよりさらに効率的に レンダリング できるようになりました。 Naniteの設定方法 Naniteはスタティックメッシュにのみ使用できます。（スケルタルメッシュなどには設定できないので注意が必要） 設定したいスタティックメッシュを開きます。 今回はレベル内に配置してある大量の人型のオブジェクトに対し、Naniteの設定を行っていきます。 スタティックメッシュを開いたら詳細パネルより、Naniteの設定 ＞ Naniteサポートの有効化 をオンにします。 スタティックメッシュを保存し、レベルに配置するためのアクタークラスBlueprintを作成します。 コンポーネント 内にスタティックメッシュを追加し、詳細画面から先ほどNaniteの設定をしたスタティックメッシュを選択します。 あとは、このアクターをレベル上に配置して負荷に変化があるか検証していきます。 Naniteによる負荷軽減の検証 PCGを利用して人型のアクターを大量に配置したレベルを用意し、Naniteを設定したものと、していないものでどれだけ数値に差が出るか調査しました。 それぞれのゲーム上で「stat unit」を行います。 （今回の記事ではPCGに関しての説明は割愛いたします。） Naniteを有効にしていない場合 Naniteを有効にしている場合 Drawsの数値が劇的に減少され（ 18143 → 559 ）、Frameにかかる時間も16ms ほど短縮できています。 今回はデフォルトで用意されている人型のメッシュに対しNaniteの設定を行いましたが、 ZBrush などで作成した複雑でポリゴン数の多いオブジェクトなどに対してNaniteの設定を行うことで、劇的に描画速度を向上できます。 おわりに 今回は、UE5を利用してプロファイリングの方法の GPU 部分に関して、 ボトルネック になっている箇所を探し、対策する方法などをまとめました。 今回は検証用に作成したプロジェクトだったため、単純明快に問題の発見と解決ができましたが、 実際のプロジェクトでは、より複雑に原因が入り組んでいることが想像できます。 実践を積みながら、プロファイリングについてもっと詳しくなっていきたいです。 本プロジェクトでは、まだCPU側に ボトルネック がありFrameの数値が140msと、非常に遅くなっているので、 次の記事ではCPUに関するプロファイルング方法をご紹介していきます。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 執筆： @okazaki.wataru 、レビュー： @kano.nanami （ Shodo で執筆されました ）

こんにちは、ISID 金融ソリューション事業部の岡崎です。 ゲームや動画などを作成する際に、ユーザーが違和感なくコンテンツを使用するためには、 フレームごとの描画速度（フレームレート）を意識し、パフォーマンスを担保し続ける必要があります。 今回はUE5でパフォーマンスを担保するために必要な、プロファイリングのワークフローの説明を行います。 はじめに UEでは、制作したプロジェクトの性能を測るためにプロファイリングという作業を行います。 プロファイリングは、主にパフォーマンス改善を目的として実施します。例えばコマンドや専用のアプリケーションを使用して、描画に遅延が起こっていないか、不要な処理をしているBlueprintがないか、などを調べます。 今回の記事では、UEの基礎的なプロファイリングの方法（ GPU 編）について紹介していきます。 CPUに関しては記事が長くなるので、次の記事でご紹介します。 検証環境/ツール OS： Windows 11 pro GPU ： NVIDIA GeForce RTX 4070 Ti Game Engine： Unreal Engine 5.2.0 実装手順 「stat unit」コマンドの実施 Drawsが多い場合の対処方法 2-1. 対象メッシュの確認、削除 2-2. Naniteの設定（UE5の場合） 1. 「stat unit」コマンドの実施 まず初めに、「stat unit」コマンドについて説明していきます。 UEではさまざまな方法でプロジェクトのプロファイリングを行う方法があります。 「stat unit」はプロジェクト全体を俯瞰し、大体どの辺に致命的なバグや遅延の原因があるかなどを調べるのに適したコマンドになります。 「stat unit」コマンドを使用するためには、 デバッグ したいプロジェクトを開き、画面下部よりアウトプットタブを押下し、 コマンド入力スペースに「stat unit」を記述します。 画面上に画像のようなログが出てきます。 主要な項目の説明をします。 Frame : 画面を描画するのにかかった処理時間。60FPSのゲームを作成する場合は、16.6ms以下になるように調整しないといけない Game : リアルタイムで動作するゲームのロジックやアニメーションにかかるCPUの処理時間 Draw : 何を描画するか、選択や計算をするためにかかるCPUの処理時間 GPU Time : メッシュや各マテリアルの描画や、ライティングなどにかかる GPU の処理時間 Draws : 描画する必要のあるメッシュの個数。 GPU Timeに影響を与える またGameなどの数値は、ゲームをプレイしている最中にBlueprintなどに連動して数値が変動するので、 ゲームをプレイしてキャ ラク ターの操作などを行った際の数値も確かめる必要があります。 今回は GPU 編なので、「stat unit」の結果から、 「Draw」、「Draws」の数値を調査、修正を行っていきます。 その他の項目のCPUに関わる箇所は次の記事で紹介するので、本記事では割愛します。 2. Drawsが多い場合の対処方法 Drawsの数値が大きい場合は、メッシュが大量に配置されていたり、ポリゴン数の多すぎる複雑なメッシュが配置されてしまっている可能性があります。 今回は、16.6msを超えているため、正常時は緑に表示される数字が赤文字になっています。 この Drawsの数値が大きいように感じたので調査していきます。 まずはレベル上にどのようなメッシュやポリゴンがあるか確認していきます。 2-1. 対象メッシュの確認、削除 画面上部のツールから、オーディット＞統計 を選びます。 すると別画面でレベル内に配置されているメッシュのポリゴン数を確認することが出来ます。 「Tris」と書かれている部分がポリゴン数で、「Sum Tris」と書かれている部分が合計のポリゴン数になります。 今回の統計では、「SM_Movehuman」というオブジェクトの「Count」が「31,834」になっており、「Sum Tris」の数値も非常に高くなっています。 一般的にポリゴン数は下記の 閾値 を参考にすると良いとされています。 2000から3000までが理想 5000を超えると重たくなり始める 10000を超えると問題が起こり始める このためDrawの数値が大きくなっていることが考えられます。 プロジェクトに戻って確認してみると、 実はこのレベルには大量の「SM_Movehuman」のアクターを配置していたことがわかりました。 もちろんこのプロジェクトは処理を重くすることを目的に作成しているので簡単に発見できましたが、 実際のプロジェクトでは、ここまで単純に問題を発見することはなかなか出来ません。 しかし、統計を見ながらレベルに配置してあるオブジェクトの個数や、ポリゴン数を確認し、大体のあたりをつけるのにはとても有効な手段です。 今回のように、オブジェクトが大量にあり「Draws」の数値が非常に高い場合の対処法は大きく3つあります。 無駄なオブジェクトの削除 UE5で追加された「Nanite」を使用 オクルージョンカリングの設定 ※オクルージョンカリングの設定方法は本記事では説明しません。次回以降の記事で紹介する予定です。 まずは無駄なオブジェクトの削除を試します。 本プロジェクトでは、「SM_Movehuman」のアクターをすべて削除してみます。 「stat unit」の値を確認してみます。 「Draws」の値が下がり、「Draw」にかかる処理速度も短くなっていることが確認できます。 アクター削除前 アクター削除後 また、本プロジェクトでは割愛しますが、統計内の「Count」の数を下げなくとも、そもそものポリゴン数を少ないものを用意するのも有効です。 もし配置してあるオブジェクトが全て必要なもので、削除できない場合は次の手段を試します。 2-2. Naniteの設定（UE5の場合） Naniteとは まず Nanite を簡単に説明をします。 Nanite とは、UE5から搭載された、3Dモデルを効率的にかつ高速に レンダリング してくれるシステムで、LODを自動で行ってくれます。 LODというのは Level of Detail の略で、ひとつのオブジェクトに対し、複数の粗さの違うメッシュを作成し、 カメラが遠くにあるときには粗く軽いメッシュを使用し、近くにあるときは細かく正確なメッシュを使用する描画方法です。 これによりユーザーに違和感やメッシュの粗さを感じさせずに、描画速度を上げることができます。 Naniteが搭載される前は、これらの複数のメッシュを用意し、距離を計算し配置する作業は手作業で行っていましたが、 LODがNaniteによって自動化され、手作業でやるよりさらに効率的に レンダリング できるようになりました。 Naniteの設定方法 Naniteはスタティックメッシュにのみ使用できます。（スケルタルメッシュなどには設定できないので注意が必要） 設定したいスタティックメッシュを開きます。 今回はレベル内に配置してある大量の人型のオブジェクトに対し、Naniteの設定を行っていきます。 スタティックメッシュを開いたら詳細パネルより、Naniteの設定 ＞ Naniteサポートの有効化 をオンにします。 スタティックメッシュを保存し、レベルに配置するためのアクタークラスBlueprintを作成します。 コンポーネント 内にスタティックメッシュを追加し、詳細画面から先ほどNaniteの設定をしたスタティックメッシュを選択します。 あとは、このアクターをレベル上に配置して負荷に変化があるか検証していきます。 Naniteによる負荷軽減の検証 PCGを利用して人型のアクターを大量に配置したレベルを用意し、Naniteを設定したものと、していないものでどれだけ数値に差が出るか調査しました。 それぞれのゲーム上で「stat unit」を行います。 （今回の記事ではPCGに関しての説明は割愛いたします。） Naniteを有効にしていない場合 Naniteを有効にしている場合 Drawsの数値が劇的に減少され（ 18143 → 559 ）、Frameにかかる時間も16ms ほど短縮できています。 今回はデフォルトで用意されている人型のメッシュに対しNaniteの設定を行いましたが、 ZBrush などで作成した複雑でポリゴン数の多いオブジェクトなどに対してNaniteの設定を行うことで、劇的に描画速度を向上できます。 おわりに 今回は、UE5を利用してプロファイリングの方法の GPU 部分に関して、 ボトルネック になっている箇所を探し、対策する方法などをまとめました。 今回は検証用に作成したプロジェクトだったため、単純明快に問題の発見と解決ができましたが、 実際のプロジェクトでは、より複雑に原因が入り組んでいることが想像できます。 実践を積みながら、プロファイリングについてもっと詳しくなっていきたいです。 本プロジェクトでは、まだCPU側に ボトルネック がありFrameの数値が140msと、非常に遅くなっているので、 次の記事ではCPUに関するプロファイルング方法をご紹介していきます。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ（Web3/メタバース/AI） 執筆： @okazaki.wataru 、レビュー： @kano.nanami （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの平岡です。 私は社内の SOC サービスの研究開発メンバーとして、Azureの Microsoft Defender for Cloud周りの調査を専門に行っています。 最近は、主に推奨事項の発出条件やセキュリティアラートの調査をしたり、顧客開発環境のセキュリティ監視などを行うための仕組みを作っています。 SOC活動を通じて、是非読者の皆さんに試していただきたいと思った情報を、このテックブログで紹介したいと思います。どうぞよろしくお願いします。 さて、今回は、 Azure Lighthouseを利用して他 サブスクリプション のセキュリティ情報を集約する方法 を紹介します。 そもそもどんなシチュエーションでこの設定が役に立つのか？ Azureポータル上では、 Microsoft Defender for Cloud等のサービスを通じて、自分の サブスクリプション 内のセキュリティ情報を見ることが出来ます。 使用している サブスクリプション が一つだけなら、セキュリティ情報の管理はそれほど難しくないかもしれません。 しかし、大きな企業になると社内で沢山の サブスクリプション を立てて、それを部署や案件単位で管理していることが多いのではないでしょうか。このような状況であれば、一つの サブスクリプション で、他の サブスクリプション や、異なるテナント間のリソースのセキュリティ情報を集約して、監視することが出来たらとても楽ですよね。 そこで使っていただきたいのが Azure Lighthouse です。 Azure lighthouseとは・・・Azure Lighthouseは、複数のAzure ADテナントの管理を一か所のテナントで行えるようにするものです。これにより、Azureを払い出している部署が、各部署や案件単位で利用するテナントを効率的に構築および提供する事ができるようになります。また、Azure Lighthouse自体の利用料金はかかりません。 Azure Lighthouse とは https://learn.microsoft.com/ja-jp/azure/lighthouse/overview それでは、早速設定してみます。 今回は委任先の サブスクリプション に対して、委任元の サブスクリプション のセキュリティ情報を集約できるようにします。 1. Azure Lighthouseのデプロイを実施します (1) Azure Lighthouseのデプロイはポータルからはできない(※ 2023/6/1現在)ため、 Github のARMテンプレートを使用します。テンプレートはリンクから選択します。 https://github.com/Azure/Azure-Lighthouse-samples/ (2) README.md内の"Deploy to Azure buttons"から、下記画像のテンプレートを選択します。 Name : Azure Lighthouse - Subscription Deployment Description : onboard a subscription 2. Azureのカスタムデプロイ画面に遷移後、必須項目を埋めます    サブスクリプション : 委任元の サブスクリプション リージョン ：デプロイ場所 Msp Offer Name : 委任の名称 Msp Offer Description : 委任の説明 Managed By Tenant ID : 委任先のテナントID Authorizations : 委任内容を json 形式で記述  [     {         "principalId": "<ユーザー等のオブジェクト ID>",         "principalIdDisplayName": "<任意の名前>",         "roleDefinitionId": "<委任する組み込みロール ID>"     }  ] 委任先のテナントIDは　Azure Acrive Directory＞概要　を参照します。 principalId（グループまたはユーザーのオブジェクトID）は　Azure Active Directory ＞グループ（ユーザー）　を参照します。 roleDefinitionId（委任する組み込みロールID）は　下記ドキュメントから必要な権限を選択します。 Azure 組み込みロール： https://learn.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles 3.必須項目の入力完了後、”確認と作成”ボタンを押下しデプロイを完了します 4.委任先のテナントで、ポータルの設定に遷移します ポータルの設定画面は右上の歯車ボタンを押下します 5.既定の サブスクリプション フィルターのプルダウンを“すべての ディレクト リ”および“すべての サブスクリプション ”に設定します 設定は以上です。 集約先の サブスクリプション で Microsoft Defender for Cloud画面を見てみましょう。 集約元の サブスクリプション の推奨情報やセキュリティ警告が反映されています。 サブスクリプション を行き来しなくても、一つの サブスクリプション でセキュリティ情報が見られるようになり、管理がしやすくなりました。 ＜推奨事項画面＞ ＜セキュリティ警告画面＞ 終わりに 今回紹介したAzure Lighthouseを利用することで、一つの サブスクリプション に複数の サブスクリプション の情報を集約することができます。 複数の サブスクリプション の管理をしている方は是非利用してみてください。 私たちは一緒に働いてくれる仲間を募集しています！ セキュリティエンジニア 執筆： @hiraoka.eri 、レビュー： @fukutake.hiroaki （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの平岡です。 私は社内の SOC サービスの研究開発メンバーとして、Azureの Microsoft Defender for Cloud周りの調査を専門に行っています。 最近は、主に推奨事項の発出条件やセキュリティアラートの調査をしたり、顧客開発環境のセキュリティ監視などを行うための仕組みを作っています。 SOC活動を通じて、是非読者の皆さんに試していただきたいと思った情報を、このテックブログで紹介したいと思います。どうぞよろしくお願いします。 さて、今回は、 Azure Lighthouseを利用して他 サブスクリプション のセキュリティ情報を集約する方法 を紹介します。 そもそもどんなシチュエーションでこの設定が役に立つのか？ Azureポータル上では、 Microsoft Defender for Cloud等のサービスを通じて、自分の サブスクリプション 内のセキュリティ情報を見ることが出来ます。 使用している サブスクリプション が一つだけなら、セキュリティ情報の管理はそれほど難しくないかもしれません。 しかし、大きな企業になると社内で沢山の サブスクリプション を立てて、それを部署や案件単位で管理していることが多いのではないでしょうか。このような状況であれば、一つの サブスクリプション で、他の サブスクリプション や、異なるテナント間のリソースのセキュリティ情報を集約して、監視することが出来たらとても楽ですよね。 そこで使っていただきたいのが Azure Lighthouse です。 Azure lighthouseとは・・・Azure Lighthouseは、複数のAzure ADテナントの管理を一か所のテナントで行えるようにするものです。これにより、Azureを払い出している部署が、各部署や案件単位で利用するテナントを効率的に構築および提供する事ができるようになります。また、Azure Lighthouse自体の利用料金はかかりません。 Azure Lighthouse とは https://learn.microsoft.com/ja-jp/azure/lighthouse/overview それでは、早速設定してみます。 今回は委任先の サブスクリプション に対して、委任元の サブスクリプション のセキュリティ情報を集約できるようにします。 1. Azure Lighthouseのデプロイを実施します (1) Azure Lighthouseのデプロイはポータルからはできない(※ 2023/6/1現在)ため、 Github のARMテンプレートを使用します。テンプレートはリンクから選択します。 https://github.com/Azure/Azure-Lighthouse-samples/ (2) README.md内の"Deploy to Azure buttons"から、下記画像のテンプレートを選択します。 Name : Azure Lighthouse - Subscription Deployment Description : onboard a subscription 2. Azureのカスタムデプロイ画面に遷移後、必須項目を埋めます    サブスクリプション : 委任元の サブスクリプション リージョン ：デプロイ場所 Msp Offer Name : 委任の名称 Msp Offer Description : 委任の説明 Managed By Tenant ID : 委任先のテナントID Authorizations : 委任内容を json 形式で記述  [     {         "principalId": "<ユーザー等のオブジェクト ID>",         "principalIdDisplayName": "<任意の名前>",         "roleDefinitionId": "<委任する組み込みロール ID>"     }  ] 委任先のテナントIDは　Azure Acrive Directory＞概要　を参照します。 principalId（グループまたはユーザーのオブジェクトID）は　Azure Active Directory ＞グループ（ユーザー）　を参照します。 roleDefinitionId（委任する組み込みロールID）は　下記ドキュメントから必要な権限を選択します。 Azure 組み込みロール： https://learn.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles 3.必須項目の入力完了後、”確認と作成”ボタンを押下しデプロイを完了します 4.委任先のテナントで、ポータルの設定に遷移します ポータルの設定画面は右上の歯車ボタンを押下します 5.既定の サブスクリプション フィルターのプルダウンを“すべての ディレクト リ”および“すべての サブスクリプション ”に設定します 設定は以上です。 集約先の サブスクリプション で Microsoft Defender for Cloud画面を見てみましょう。 集約元の サブスクリプション の推奨情報やセキュリティ警告が反映されています。 サブスクリプション を行き来しなくても、一つの サブスクリプション でセキュリティ情報が見られるようになり、管理がしやすくなりました。 ＜推奨事項画面＞ ＜セキュリティ警告画面＞ 終わりに 今回紹介したAzure Lighthouseを利用することで、一つの サブスクリプション に複数の サブスクリプション の情報を集約することができます。 複数の サブスクリプション の管理をしている方は是非利用してみてください。 私たちは一緒に働いてくれる仲間を募集しています！ セキュリティエンジニア 執筆： @hiraoka.eri 、レビュー： @fukutake.hiroaki （ Shodo で執筆されました ）

はじめに こんにちは。X イノベーション 本部の藤川です。 私は「aiuola（アイウォーラ）」という エンタープライズ アプリケーションプラットフォームの開発において、プロダクトマネージャーをしています。まれにアーキテクト、 デベロッパ ーなど別の帽子を被って 開発プロセス に参加しています。 今回の記事では、aiuolaが採用している アジャイル 開発プロセス について私たちの現在の着地点をスプリントイベントを中心に紹介します。 ちなみにaiuolaとは「 エンタープライズ アプリケーションでお客様に感動を」というキャッチフレーズで立ち上げた開発プロジェクトです。エンプラ系アプリってなんかあれじゃん、結局大したことないでしょという眉唾100%の皆様、ご安心ください。 私たちの想いを体現した エンタープライズ アプリケーションは「Ci*X（サイクロス）」というブランドでリリースしております。 ご利用中のお客様からは「マニュアルを参照せずに使える業務アプリって初めて！」「 経理 部門に配属以来最も大きな感動体験です！」と評判です。 会計プロダクトの検討をされている方はぜひこちらをご覧ください。 グループ経営管理ソリューション　サイクロスシリーズ aiuolaの取り組み aiuola とは aiuolaは当社の エンタープライズ アプリケーションの共通プラットフォームです。 エンタープライズ アプリで求められる認証・認可やUIライブラリを提供しています。 2023年現在、aiuolaを活用したいくつかのプロダクト群をリリースしご好評をいただいております。 体制 aiuolaの開発体制は初期からの変遷を経て、以下のような体制となっています。 本チームではサービス運用のミッションを持っていないためインフラチームは有していません。 （各プロダクト側にインフラチームがいて、我々と協力してお客様のサクセスを支えています） 初期の頃はフロントエンジニア4名、専任デザイナーが1名という体制でしたが、デザインシステムが固まってからは概ね上記の体制で活動しています。 当チームのバックエンドエンジニアは単一の ユースケース （機能）の開発を担当し、機能単位のフロント実装も行います。 一方でフロントエンジニアはUI コンポーネント の開発やフロントエンド実装指針にフォーカスを当てて活動しています。 スプリントイベント aiuolaの開発は2週間のスプリントで実施しています。 スプリント期間の過ごし方をスプリントイベントを中心に図にしてみました。 ご覧いただくとお分かりかと思いますが、すごくオーソドックスな スクラム 開発プロセス を採用しています。 なお、2020年以降、aiuolaの開発はリモートスタイルでの開発となっています。 スプリントイベントを含めて、すべての活動をリモート環境で実施しています。飲み会以外はね！😉。 デイリーミーティング 主に前日タスクでの課題とその日の活動予定を共有しますが、slackで簡単なワークレポートを投稿するルールにしているので、困りごとへの対応、レビュー担当者への アサイ ン、QAメンバーへのテスト依頼などが目的になります。 大体、15分〜20分ぐらいの時間でその名の通り、毎日実施しています。 スプリントプランニング スプリントで実施するタスクを バックログ から決定します。 スプリントチームはQAチームを含めて4つのサブチームが存在するので、3段階のスプリントプランニングステージを設けています。 プレスプリントプランニング 各サブチームにて次スプリントタスクの選定とポーカー サブリーダーによるスプリントプランニング サブチーム間の作業すり合わせ 全員でのスプリントプランニング スプリントタスクの共有 従来は3だけですべてを実施していたのですが、チーム体制が大きくなるにつれ、全員を拘束してしまう時間が増えてしまいました。 貴重なエンジニアリング時間を十分に確保することを目的に3段階のフェーズを設けることにしました。 プロダクトリーダー会 プロダクトファミリーで紹介した通り、aiuolaを活用するプロダクトは複数あります。 各プロダクトも日々開発を進めています。プロダクト間で期待する要望、対応スケジュールのすり合わせは重要です。 プロダクトリーダー会ではそのようなプロダクトをまたがった調整を行います。 リリース内容発表会 リリース内容発表会ではスプリントにおいてリリースできる機能をチーム内で共有し、紹介し、功績を称える会となります。 私たちの開発対象は エンタープライズ アプリケーションのため、単一の機能が有するフィーチャーは比較的大規模になります。そのためスプリントの中で1つの機能を完全に作り上げることができません。 リリース内容発表会ではそのリリースに含めることができた機能を対象とします。 それ以外にもQAチームから品質の取り組みに関する発表も含まれることがあります。 スプリントリリース スプリントリリースはミーティングではなく、前スプリントの成果をリリースするタスクとなります。 aiuolaとしてのリリースはスプリントの成果物を各プロダクトチームに提供する作業です。 プロダクトファミリーの市場投入サイクルはaioulaを含めてすべて6ヶ月単位となります。そのため、スプリントリリースは開発ベータ版としてプロダクトチームに成果物を提供することを指します。 レトロスペクティブ レトロスペクティブはその名の通り、スプリントの最後に行う振り返り会です。 開発の改善に役立つア イデア や課題を議論し、スプリントの中で挑戦すべきことを議論します。 従来はオフラインで実施していましたが、オンライン主体の 開発プロセス に変わってからはMiroを活用しております。 終わりに 今回の記事では私たちが開発している エンタープライズ アプリケーションプラットフォーム「aiuola」の 開発プロセス について非常に簡単ですがその一端をご紹介しました。 プロダクトファミリーにて紹介したaiuolaプラットフォームを活用した各プロダクトも積極的な機能強化を行っています。 それぞれのプロダクトはここで紹介したプロセスをコピーして適用しているわけではなく、プロダクト特性やチーム体制に応じた開発スタイルを採用し、独自に発展を遂げています。もちろん私たちaiuolaチームも現状に満足しているわけではなく、より効果的な取り組みにチャレンジしています。 いずれのプロダクトでも、共に新たなチャレンジに挑んでくれる仲間を探していますので、ご興味を持っていただいた方は是非とも採用ページをご覧ください。 また、本チームの開発メンバーがアプリケーション アーキテクチャ をテーマとしてTech Playに登壇します。 こちらも是非ご参加いただけると幸いです。 Tech Play URL 私たちは一緒に働いてくれる仲間を募集しています！ プロダクトプラットフォーム開発エンジニア/新規プロダクト開発エンジニア 次世代会計プロダクト開発ITアーキテクト（Ci*Xシリーズ） 次世代会計プロダクトDevOpsエンジニア（Ci*Xシリーズ） 執筆： @fujikawa.kenji 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

はじめに こんにちは。X イノベーション 本部の藤川です。 私は「aiuola（アイウォーラ）」という エンタープライズ アプリケーションプラットフォームの開発において、プロダクトマネージャーをしています。まれにアーキテクト、 デベロッパ ーなど別の帽子を被って 開発プロセス に参加しています。 今回の記事では、aiuolaが採用している アジャイル 開発プロセス について私たちの現在の着地点をスプリントイベントを中心に紹介します。 ちなみにaiuolaとは「 エンタープライズ アプリケーションでお客様に感動を」というキャッチフレーズで立ち上げた開発プロジェクトです。エンプラ系アプリってなんかあれじゃん、結局大したことないでしょという眉唾100%の皆様、ご安心ください。 私たちの想いを体現した エンタープライズ アプリケーションは「Ci*X（サイクロス）」というブランドでリリースしております。 ご利用中のお客様からは「マニュアルを参照せずに使える業務アプリって初めて！」「 経理 部門に配属以来最も大きな感動体験です！」と評判です。 会計プロダクトの検討をされている方はぜひこちらをご覧ください。 グループ経営管理ソリューション　サイクロスシリーズ aiuolaの取り組み aiuola とは aiuolaは当社の エンタープライズ アプリケーションの共通プラットフォームです。 エンタープライズ アプリで求められる認証・認可やUIライブラリを提供しています。 2023年現在、aiuolaを活用したいくつかのプロダクト群をリリースしご好評をいただいております。 体制 aiuolaの開発体制は初期からの変遷を経て、以下のような体制となっています。 本チームではサービス運用のミッションを持っていないためインフラチームは有していません。 （各プロダクト側にインフラチームがいて、我々と協力してお客様のサクセスを支えています） 初期の頃はフロントエンジニア4名、専任デザイナーが1名という体制でしたが、デザインシステムが固まってからは概ね上記の体制で活動しています。 当チームのバックエンドエンジニアは単一の ユースケース （機能）の開発を担当し、機能単位のフロント実装も行います。 一方でフロントエンジニアはUI コンポーネント の開発やフロントエンド実装指針にフォーカスを当てて活動しています。 スプリントイベント aiuolaの開発は2週間のスプリントで実施しています。 スプリント期間の過ごし方をスプリントイベントを中心に図にしてみました。 ご覧いただくとお分かりかと思いますが、すごくオーソドックスな スクラム 開発プロセス を採用しています。 なお、2020年以降、aiuolaの開発はリモートスタイルでの開発となっています。 スプリントイベントを含めて、すべての活動をリモート環境で実施しています。飲み会以外はね！😉。 デイリーミーティング 主に前日タスクでの課題とその日の活動予定を共有しますが、slackで簡単なワークレポートを投稿するルールにしているので、困りごとへの対応、レビュー担当者への アサイ ン、QAメンバーへのテスト依頼などが目的になります。 大体、15分〜20分ぐらいの時間でその名の通り、毎日実施しています。 スプリントプランニング スプリントで実施するタスクを バックログ から決定します。 スプリントチームはQAチームを含めて4つのサブチームが存在するので、3段階のスプリントプランニングステージを設けています。 プレスプリントプランニング 各サブチームにて次スプリントタスクの選定とポーカー サブリーダーによるスプリントプランニング サブチーム間の作業すり合わせ 全員でのスプリントプランニング スプリントタスクの共有 従来は3だけですべてを実施していたのですが、チーム体制が大きくなるにつれ、全員を拘束してしまう時間が増えてしまいました。 貴重なエンジニアリング時間を十分に確保することを目的に3段階のフェーズを設けることにしました。 プロダクトリーダー会 プロダクトファミリーで紹介した通り、aiuolaを活用するプロダクトは複数あります。 各プロダクトも日々開発を進めています。プロダクト間で期待する要望、対応スケジュールのすり合わせは重要です。 プロダクトリーダー会ではそのようなプロダクトをまたがった調整を行います。 リリース内容発表会 リリース内容発表会ではスプリントにおいてリリースできる機能をチーム内で共有し、紹介し、功績を称える会となります。 私たちの開発対象は エンタープライズ アプリケーションのため、単一の機能が有するフィーチャーは比較的大規模になります。そのためスプリントの中で1つの機能を完全に作り上げることができません。 リリース内容発表会ではそのリリースに含めることができた機能を対象とします。 それ以外にもQAチームから品質の取り組みに関する発表も含まれることがあります。 スプリントリリース スプリントリリースはミーティングではなく、前スプリントの成果をリリースするタスクとなります。 aiuolaとしてのリリースはスプリントの成果物を各プロダクトチームに提供する作業です。 プロダクトファミリーの市場投入サイクルはaioulaを含めてすべて6ヶ月単位となります。そのため、スプリントリリースは開発ベータ版としてプロダクトチームに成果物を提供することを指します。 レトロスペクティブ レトロスペクティブはその名の通り、スプリントの最後に行う振り返り会です。 開発の改善に役立つア イデア や課題を議論し、スプリントの中で挑戦すべきことを議論します。 従来はオフラインで実施していましたが、オンライン主体の 開発プロセス に変わってからはMiroを活用しております。 終わりに 今回の記事では私たちが開発している エンタープライズ アプリケーションプラットフォーム「aiuola」の 開発プロセス について非常に簡単ですがその一端をご紹介しました。 プロダクトファミリーにて紹介したaiuolaプラットフォームを活用した各プロダクトも積極的な機能強化を行っています。 それぞれのプロダクトはここで紹介したプロセスをコピーして適用しているわけではなく、プロダクト特性やチーム体制に応じた開発スタイルを採用し、独自に発展を遂げています。もちろん私たちaiuolaチームも現状に満足しているわけではなく、より効果的な取り組みにチャレンジしています。 いずれのプロダクトでも、共に新たなチャレンジに挑んでくれる仲間を探していますので、ご興味を持っていただいた方は是非とも採用ページをご覧ください。 また、本チームの開発メンバーがアプリケーション アーキテクチャ をテーマとしてTech Playに登壇します。 こちらも是非ご参加いただけると幸いです。 Tech Play URL 私たちは一緒に働いてくれる仲間を募集しています！ プロダクトプラットフォーム開発エンジニア/新規プロダクト開発エンジニア 次世代会計プロダクト開発ITアーキテクト（Ci*Xシリーズ） 次世代会計プロダクトDevOpsエンジニア（Ci*Xシリーズ） 執筆： @fujikawa.kenji 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）