はじめに ISID X（クロス） イノベーション 本部 の池田です。 Azure Portal から Azure Load Testing を操作する方法については以下の記事もご覧ください。 tech.isid.co.jp 負荷試験 の計画の中でいろいろな利用パターンでの試験により環境を分析するケースがあります。 しかし、Azure Portal からの操作では JMeter スクリプト のアップロードや参照できるリソース選択など選択項目が多く、複数パターンを何度も手動で作成するのは手間です。 そこで CLI から操作して複数テストを一括登録する方法を試しましたのでご紹介します。 利用ツール 通常のAzureリソースの CLI 操作としては、Azure CLI や Azure Power Shell, ARMテンプレート を利用するのが一般的です。しかし、2023年2月にGAしたばかりの Azure Load Testing においては 2023年5月時点でこれらのツールでAzureリソース作成はできるものの詳細な設定ができませんでした。Azure Load Testing REST API では先行してテスト作成の機能が提供されていたため、こちらを利用して作成します。（現在はAzure CLI によるテスト作成もサポートされるようになっています） 今回の スクリプト 実行環境は以下のとおりです。 スクリプト の記載は環境依存のものが含まれますので、参考にされる際はご自身の環境に合わせて調整してください。 PowerShell 7.3.4 azure-cli 2.49.0 curl 8.0.1 (Windows) libcurl/8.0.1 Schannel WinIDN 試験環境の概要 今回使用するテスト環境の構成は以下のとおりです。App Service 既定のWebサイトをテスト対象としてAzure Load TestingからHTTPリク エス トを連続送信します。その上でAzureリソースの負荷状況を Azure Load Testing の ダッシュ ボードに表示する構成となります。 Azure Load Testingリソースの作成 Azureリソース作成はAzure CLI で機能提供されていましたので、この部分はこちらのコマンドを利用して作成します。 az load create --name ${loadTestName} -- resource-group ${resourceGroupName} --location eastasia データプレーン URI の取得 Azure リソースマネージャーに対する要求では az rest コマンドを利用すると認証ヘッダーを自動付与できて便利です。 az rest で REST API を呼び出して作成されたリソースのデータプレーンエンドポイントを取得します。 $loadTest = ( az rest ` --method get ` --uri https: // management.azure.com / subscriptions / ${subscriptionId} / resourceGroups / ${resourceGroupName} / providers / Microsoft.LoadTestService / loadTests / ${loadTestName} ? api-version = 2022 - 12 - 01 ` | ConvertFrom-Json ) $Endpoint = $loadTest .properties.dataPlaneURI $Endpoint 以下のような出力が得られます。これでデータプレーン操作に必要なエンドポイントが取得できました。 XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.eastasia.cnt-prod.loadtesting.azure.com データプレーン用アクセス トーク ンの取得 ここからは Azureリソースマネージャー へのアクセスではなくデータプレーンエンドポイントへの操作となります。データプレーン用のアクセス トーク ンを取得する必要があります。 必要なアクセス トーク ン Azure Load Testing REST API のリファレンスを参照すると、「 https://cnt-prod.loadtesting.azure.com/.default%E3%80%8D%E3%82%92Scope%E3%81%A8%E3%81%97%E3%81%9F%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3%E3%81%8C%E5%BF%85%E8%A6%81%E3%81%A8%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82 Load Test Administration - Create Or Update Test アクセス トーク ンの取得 az account get- access -token コマンドを利用して、該当スコープに対するアクセス トーク ンを取得します。 （ 参考： az account get-access-token ） $accessToken = (az account get-access-token ` --scope 'https://cnt-prod.loadtesting.azure.com/.default' ` --query 'accessToken' ` --output tsv) テストの構成 データプレーンエンドポイントとアクセス トーク ンがそろいましたので、続いてデータプレーンの操作をします。 データプレーンはTemplateファイルを用意してそれを curl コマンドで投げ込む形で操作します。 ID採番 まずは、テストIDとして使用するGuidを採番します。 $testId = ( New-Guid ) テスト作成 実際にAzure Load Testing REST API を呼び出してテストを作成していきます。 （参考： Load Test Administration - Create Or Update Test ） curl ` --request PATCH ` --header "Authorization: Bearer $accessToken " ` --header "Content-Type: application/merge-patch+json" ` --url "https:// ${Endpoint} /tests/ ${testId} ?api-version=2022-11-01" ` -- upload-file TestTemplate.json 送信ファイルに記述するパラメータが以下となります。Azure Portal 上で作成したテストの内容を API で取得して参考にしつつ作るのがおすすめです。 （参考： Load Test Administration - Get Test ） { "displayName": "displayName_test1", "description": "", "keyvaultReferenceIdentityType": "SystemAssigned", "passFailCriteria": { "passFailMetrics": {} }, "loadTestConfiguration": { "engineInstances": 10, "splitAllCSVs": false, "quickStartTest": false } } アプリ コンポーネント 登録 次にテスト結果画面に表示するアプリ コンポーネント （Azure リソースのコレクション）を登録します。 （参考： Load Test Administration - Create Or Update App Components ） curl ` --request PATCH ` --header "Authorization: Bearer $accessToken " ` --header "Content-Type: application/merge-patch+json" ` --url "https:// ${Endpoint} /tests/ ${testId} /app-components?api-version=2022-11-01" ` -- upload-file AppComponents.json アプリ コンポーネント は以下のように列挙していく形で登録します。参考とする既存設定の取得 API は以下です。 （参考： Load Test Administration - Get App Components ） { "components": { "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/sites/app-demo-ikeda": { "resourceId": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/sites/app-demo-ikeda", "resourceName": "app-demo-ikeda", "resourceType": "Microsoft.Web/sites", "resourceGroup": "rg-load-test", "subscriptionId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", "kind": "app" }, "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/serverfarms/plan-load-demo": { "resourceId": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/serverfarms/plan-load-demo", "resourceName": "plan-load-demo", "resourceType": "Microsoft.Web/serverfarms", "resourceGroup": "rg-load-test", "subscriptionId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", "kind": "app" } } } メトリック登録 続いて、テスト結果画面に表示するメトリックを登録します。 （参考： Load Test Administration - Create Or Update Server Metrics Config ） curl ` --request PATCH ` --header "Authorization: Bearer $accessToken " ` --header "Content-Type: application/merge-patch+json" ` --url "https:// ${Endpoint} /tests/ ${testId} /server-metrics-config?api-version=2022-11-01" ` -- upload-file ServerMetricsConfig.json 前段で登録したアプリ コンポーネント に対するメトリックを列挙します。参考とする既存設定の取得 API は下記です。 （参考： Load Test Administration - Get Server Metrics Config ） { "metrics": { "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/sites/app-demo-ikeda/providers/microsoft.insights/metricdefinitions/Http5xx": { "id": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/sites/app-demo-ikeda/providers/microsoft.insights/metricdefinitions/Http5xx", "resourceId": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/sites/app-demo-ikeda", "metricNamespace": "microsoft.web/sites", "name": "Http5xx", "aggregation": "Total", "resourceType": "microsoft.web/sites" }, "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/sites/app-demo-ikeda/providers/microsoft.insights/metricdefinitions/Requests": { "id": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/sites/app-demo-ikeda/providers/microsoft.insights/metricdefinitions/Requests", "resourceId": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/sites/app-demo-ikeda", "metricNamespace": "microsoft.web/sites", "name": "Requests", "aggregation": "Total", "resourceType": "microsoft.web/sites" }, "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/sites/app-demo-ikeda/providers/microsoft.insights/metricdefinitions/HttpResponseTime": { "id": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/sites/app-demo-ikeda/providers/microsoft.insights/metricdefinitions/HttpResponseTime", "resourceId": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/sites/app-demo-ikeda", "metricNamespace": "microsoft.web/sites", "name": "HttpResponseTime", "aggregation": "Average", "resourceType": "microsoft.web/sites" }, "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/serverfarms/plan-load-demo/providers/microsoft.insights/metricdefinitions/CpuPercentage": { "id": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/serverfarms/plan-load-demo/providers/microsoft.insights/metricdefinitions/CpuPercentage", "resourceId": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/serverfarms/plan-load-demo", "metricNamespace": "microsoft.web/serverfarms", "name": "CpuPercentage", "aggregation": "Average", "resourceType": "microsoft.web/serverfarms" }, "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/serverfarms/plan-load-demo/providers/microsoft.insights/metricdefinitions/MemoryPercentage": { "id": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/serverfarms/plan-load-demo/providers/microsoft.insights/metricdefinitions/MemoryPercentage", "resourceId": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/resourceGroups/rg-load-test/providers/Microsoft.Web/serverfarms/plan-load-demo", "metricNamespace": "microsoft.web/serverfarms", "name": "MemoryPercentage", "aggregation": "Average", "resourceType": "microsoft.web/serverfarms" } } } JMeter スクリプト 登録 以下の操作でテストで実行する JMeter スクリプト をアップロードします。 （参考： Load Test Administration - Upload Test File ） curl ` --request PUT ` --header "Authorization: Bearer $accessToken " ` --header "Content-Type: application/octet-stream content" ` --url "https:// ${Endpoint} /tests/ ${testId} /files/ ${NAME_JMX} ?api-version=2022-11-01&fileType=JMX_FILE" ` -- upload-file lt-demo .jmx こちらが JMeter で作成した JMX ファイルです。今回はHTTP Getリク エス トをループするシンプルな スクリプト を使用しています。 <?xml version="1.0" encoding="UTF-8"?> <jmeterTestPlan version="1.2" properties="5.0" jmeter="5.5"> <hashTree> <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true"> <stringProp name="TestPlan.comments"></stringProp> <boolProp name="TestPlan.functional_mode">false</boolProp> <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp> <boolProp name="TestPlan.serialize_threadgroups">false</boolProp> <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true"> <collectionProp name="Arguments.arguments"/> </elementProp> <stringProp name="TestPlan.user_define_classpath"></stringProp> </TestPlan> <hashTree> <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true"> <stringProp name="ThreadGroup.on_sample_error">continue</stringProp> <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true"> <boolProp name="LoopController.continue_forever">false</boolProp> <intProp name="LoopController.loops">-1</intProp> </elementProp> <stringProp name="ThreadGroup.num_threads">10</stringProp> <stringProp name="ThreadGroup.ramp_time">1</stringProp> <boolProp name="ThreadGroup.scheduler">false</boolProp> <stringProp name="ThreadGroup.duration"></stringProp> <stringProp name="ThreadGroup.delay"></stringProp> <boolProp name="ThreadGroup.same_user_on_next_iteration">true</boolProp> </ThreadGroup> <hashTree> <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="HTTP Request" enabled="true"> <elementProp name="HTTPsampler.Arguments" elementType="Arguments" guiclass="HTTPArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true"> <collectionProp name="Arguments.arguments"/> </elementProp> <stringProp name="HTTPSampler.domain">app-demo-ikeda.azurewebsites.net</stringProp> <stringProp name="HTTPSampler.port">443</stringProp> <stringProp name="HTTPSampler.protocol">https</stringProp> <stringProp name="HTTPSampler.contentEncoding"></stringProp> <stringProp name="HTTPSampler.path"></stringProp> <stringProp name="HTTPSampler.method">GET</stringProp> <boolProp name="HTTPSampler.follow_redirects">true</boolProp> <boolProp name="HTTPSampler.auto_redirects">false</boolProp> <boolProp name="HTTPSampler.use_keepalive">true</boolProp> <boolProp name="HTTPSampler.DO_MULTIPART_POST">false</boolProp> <stringProp name="HTTPSampler.embedded_url_re"></stringProp> <stringProp name="HTTPSampler.connect_timeout"></stringProp> <stringProp name="HTTPSampler.response_timeout"></stringProp> </HTTPSamplerProxy> <hashTree/> </hashTree> </hashTree> </hashTree> </jmeterTestPlan> テストの実行 テスト実行 ボディ部にテストIDを指定することで登録したテスト内容を実行できます。テスト表示名は スクリプト 内で日時から作成しています。 （参考： Load Test Run - Create Or Update Test Run ） curl ` --request PATCH ` --header "Authorization: Bearer $accessToken" ` --header "Content-Type: application/merge-patch+json" ` --url "https://${Endpoint}/test-runs/$(New-Guid)?api-version=2022-11-01" ` --data "{'testId': '${testId}','displayName':'TestRun_$((Get-Date).ToString("yyyy/MM/dd_HH:mm:ss"))'}" 実行結果の確認 Azure Portal での確認 Azure Portal 上で作成したテストが実行されていることを確認できます。 アプリ コンポーネント テスト画面の「アプリ コンポーネント 」から REST API で登録したアプリ コンポーネント が確認できます。 メトリックの構成 同じく「メトリックの構成」から表示メトリックも反映されていることが確認できます。 備考 ドキュメントが整備されていない場合、 API の利用方法を調べるのにブラウザのDevToolsでAzure Portal の通信内容を見るのも参考になります。今回もAzure Portal 上での設定項目と API 項目に差異があり、通信内容を見てみると新しい Preview バージョンの API を利用していました。新しいサービスではドキュメント化が遅れているケースもありますので必要に応じて参考にしましょう。 まとめ Azure Load Testing の操作を REST API を利用して スクリプト 化することで、複数パターンの試験登録が簡単にできるようになりました。新しいサービスでは周辺ツールがまだ提供されていないケースもありますが、ベースとなる REST API が先行して提供されていることがあります。 REST API による操作も活用することでAzureでできることが広がります。ご参考になれば幸いです。 私たちは同じチームで働いてくれる仲間を探しています。 クラウド アーキテクトの業務に興味がある方のご応募をお待ちしています。 クラウドアーキテクト 執筆： @ikeda.jun 、レビュー： @mizuno.kazuhiro （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 Terraform で Amazon RDS インスタンス / クラスタ ーを作る時に、 password または master_password 属性に指定したマスターユーザーのパスワードが tfstate ファイルに平文で残ってしまう問題がありました。 （参考） https://speakerdeck.com/harukasakihara/sekiyuanaterraformfalseshi-ifang-ji-mi-qing-bao-wokodonihan-mezuhuan-jing-gou-zhu-surunihadousitaraiifalse しかしこれも過去の話。Terraform AWS Provider v4.61.0 からこの問題を解消する方法が提供されているので、それについてご紹介します。 RDS と Secrets Manager の統合 manage_master_user_password を使わない場合 manage_master_user_password を使った場合 aws_rds_cluster にも利用できる KMSキーを指定する 既存の Secrets Manager シークレットを利用する場合 既存のDBに使ったらどうなるか スナップショットからリストアする時の挙動 さいごに RDS と Secrets Manager の統合 事の始まりは 2022年12月に発表された Amazon RDS と AWS Secrets Manager の統合 というアップデートでした。DB 作成時に、RDS への API コールにてマスターユーザーのパスワードを Secrets Manager で作成・保存してくれるようになりました。 Terraform AWS Provider でもこれへの 対応 として、2023年3月にリリースされた v4.61.0 で manage_master_user_password 属性が aws_rds_cluster と aws_db_instance で利用できるようになりました！ 実際にリソースを作成して試してみます。 manage_master_user_password を使わない場合 以下のように平文で password を指定し、 aws_db_instance リソースを作成してみます。（BADプ ラク ティスです） resource "aws_db_instance" "my-db-1" { allocated_storage = 10 engine = "mysql" engine_version = "5.7" instance_class = "db.t3.micro" username = "master" # password に平文でパスワードを記述する悪い例 password = "MyPassword123" vpc_security_group_ids = [ aws_security_group.db.id ] skip_final_snapshot = true db_subnet_group_name = "db-subnet-group" } デプロイ後の terraform.tfstate ファイルには、次のとおり平文でパスワード文字列が記録されてしまっています。 例のように .tf ファイルに直接 password を書くのは最悪ですが、他の回避策（Variablesを利用して apply 時にターミナルで指定する、Secrets Manager シークレットに先に登録してから Datasource で取得する、etc）をとったところでどうしても tfstate ファイルに記録されてしまうのは問題でした。 manage_master_user_password を使った場合 password 属性を削除し、 manage_master_user_password 属性に true を設定します。 resource "aws_db_instance" "my-db-2" { allocated_storage = 10 engine = "mysql" engine_version = "5.7" instance_class = "db.t3.micro" username = "master" # manage_master_user_password を利用する manage_master_user_password = true vpc_security_group_ids = [ aws_security_group.db.id ] skip_final_snapshot = true db_subnet_group_name = "db-subnet-group" } デプロイすると、Secrets Manager にシークレットが作成されていることがわかります。 シークレットのキーには username と password が登録されており、 password は RDS が生成したランダムな値になっていました。また 7日間の間隔でシークレットローテーションも設定されていました。 デプロイ後の terraform.tfstate ファイルでは、 password は null となっており、実際のパスワード文字列はどこにも記録されていません。 aws _rds_cluster にも利用できる aws_rds_cluster リソースに対しても、従来の master_password の代わりに manage_master_user_password を利用できるようになっています。 （参考） https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/rds_cluster#rdsaurora-managed-master-passwords-via-secrets-manager-default-kms-key KMSキーを指定する master_user_secret_kms_key_id 属性を利用することで、デフォルトキーではなく指定した KMS キーでシークレットの暗号化をすることもできます。 （参考） https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance#managed-master-passwords-via-secrets-manager-specific-kms-key https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/rds_cluster#rdsaurora-managed-master-passwords-via-secrets-manager-specific-kms-key 既存の Secrets Manager シークレットを利用する場合 今回は試していませんが、 master_user_secret の設定ブロックを使うと、既存の Secrets Manager シークレットをマスターユーザーのパスワードにできるようです。 （参考） https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance#master_user_secret 既存のDBに使ったらどうなるか 既に password や master_password を使って作成した DB に対して、 manage_master_user_password を利用する方法に切り替えることは可能です。DB は再作成されませんが、マスターユーザーのパスワードは新規に作成され（現在のパスワードは引き継がれずに） Secrets Manager に新しいシークレットとして保存されるようです。既存の DB で manage_master_user_password を使う方法に切り替える場合は、アプリケーションの動作や運用に影響がないか慎重に確認しましょう。 スナップショットからリストアする時の挙動 manage_master_user_password を利用して作成した DB のスナップショットからリストアする場合、マスターユーザーのパスワードは少し特殊な状態になるようです。次のように manage_master_user_password = true を使ってスナップショットから DB インスタンス を作成しても、Secrets Manager にパスワードは統合されず、RDS がパスワードを管理している状態で DB が復元しました。パスワードはスナップショット取得時点のものでした。 data "aws_db_snapshot" "my-snapshot" { db_snapshot_identifier = "snapshot1" } resource "aws_db_instance" "my-db-from-snapshot" { allocated_storage = 10 engine = "mysql" engine_version = "5.7" instance_class = "db.t3.micro" username = "master" # snapshot_identifier を利用してリストアする時、 # manage_master_user_password 属性を使っても # パスワードが Secrets Manager で管理されない。 manage_master_user_password = true skip_final_snapshot = true db_subnet_group_name = "db-subnet-group" # スナップショットから復元する snapshot_identifier = "$ { data.aws_db_snapshot.my-snapshot.id } " } この現象は GitHub の Issue にも報告されており、記事執筆時点では未解決です。ただし tfstate ファイルに記録された password は null だったため、Terraform AWS Provider のバグというよりは RDS の制約なのかもしれません。 リストアした DB のパスワードも Secrets Manager で管理するためには、今のところの次の ワークアラウンド が良さそうです。 manage_master_user_password を付けずに Terraform でスナップショットをリストア（ apply ） スナップショット取得時点のパスワードを、RDS が管理している状態でリストアされる manage_master_user_password = true を付けてもう一度 apply する マスターユーザーのパスワードは新規に作成されて Secrets Manager に保存される data "aws_db_snapshot" "my-snapshot" { db_snapshot_identifier = "snapshot1" } resource "aws_db_instance" "my-db-from-snapshot" { allocated_storage = 10 engine = "mysql" engine_version = "5.7" instance_class = "db.t3.micro" username = "master" # リストア時は manage_master_user_password を付けずに apply # リストア後 manage_master_user_password を付けて再度 apply # manage_master_user_password = true skip_final_snapshot = true db_subnet_group_name = "db-subnet-group" snapshot_identifier = "$ { data.aws_db_snapshot.my-snapshot.id } " } さいごに Terraform において tfstate ファイルに平文の DB パスワードが残ってしまう問題を簡単に解消する manage_master_user_password 属性についてご紹介しました。今後新たに Terraform で RDS インスタンス / クラスタ ーを作る時には、ぜひ利用を検討しましょう。ただしスナップショットからリストアする時の動きは（記事執筆時点で）少し特殊なので要注意です。 お読みいただいてありがとうございました。 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア 執筆： @kou.kinyo 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 Terraform で Amazon RDS インスタンス / クラスタ ーを作る時に、 password または master_password 属性に指定したマスターユーザーのパスワードが tfstate ファイルに平文で残ってしまう問題がありました。 （参考） https://speakerdeck.com/harukasakihara/sekiyuanaterraformfalseshi-ifang-ji-mi-qing-bao-wokodonihan-mezuhuan-jing-gou-zhu-surunihadousitaraiifalse しかしこれも過去の話。Terraform AWS Provider v4.61.0 からこの問題を解消する方法が提供されているので、それについてご紹介します。 RDS と Secrets Manager の統合 manage_master_user_password を使わない場合 manage_master_user_password を使った場合 aws_rds_cluster にも利用できる KMSキーを指定する 既存の Secrets Manager シークレットを利用する場合 既存のDBに使ったらどうなるか スナップショットからリストアする時の挙動 さいごに RDS と Secrets Manager の統合 事の始まりは 2022年12月に発表された Amazon RDS と AWS Secrets Manager の統合 というアップデートでした。DB 作成時に、RDS への API コールにてマスターユーザーのパスワードを Secrets Manager で作成・保存してくれるようになりました。 Terraform AWS Provider でもこれへの 対応 として、2023年3月にリリースされた v4.61.0 で manage_master_user_password 属性が aws_rds_cluster と aws_db_instance で利用できるようになりました！ 実際にリソースを作成して試してみます。 manage_master_user_password を使わない場合 以下のように平文で password を指定し、 aws_db_instance リソースを作成してみます。（BADプ ラク ティスです） resource "aws_db_instance" "my-db-1" { allocated_storage = 10 engine = "mysql" engine_version = "5.7" instance_class = "db.t3.micro" username = "master" # password に平文でパスワードを記述する悪い例 password = "MyPassword123" vpc_security_group_ids = [ aws_security_group.db.id ] skip_final_snapshot = true db_subnet_group_name = "db-subnet-group" } デプロイ後の terraform.tfstate ファイルには、次のとおり平文でパスワード文字列が記録されてしまっています。 例のように .tf ファイルに直接 password を書くのは最悪ですが、他の回避策（Variablesを利用して apply 時にターミナルで指定する、Secrets Manager シークレットに先に登録してから Datasource で取得する、etc）をとったところでどうしても tfstate ファイルに記録されてしまうのは問題でした。 manage_master_user_password を使った場合 password 属性を削除し、 manage_master_user_password 属性に true を設定します。 resource "aws_db_instance" "my-db-2" { allocated_storage = 10 engine = "mysql" engine_version = "5.7" instance_class = "db.t3.micro" username = "master" # manage_master_user_password を利用する manage_master_user_password = true vpc_security_group_ids = [ aws_security_group.db.id ] skip_final_snapshot = true db_subnet_group_name = "db-subnet-group" } デプロイすると、Secrets Manager にシークレットが作成されていることがわかります。 シークレットのキーには username と password が登録されており、 password は RDS が生成したランダムな値になっていました。また 7日間の間隔でシークレットローテーションも設定されていました。 デプロイ後の terraform.tfstate ファイルでは、 password は null となっており、実際のパスワード文字列はどこにも記録されていません。 aws _rds_cluster にも利用できる aws_rds_cluster リソースに対しても、従来の master_password の代わりに manage_master_user_password を利用できるようになっています。 （参考） https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/rds_cluster#rdsaurora-managed-master-passwords-via-secrets-manager-default-kms-key KMSキーを指定する master_user_secret_kms_key_id 属性を利用することで、デフォルトキーではなく指定した KMS キーでシークレットの暗号化をすることもできます。 （参考） https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance#managed-master-passwords-via-secrets-manager-specific-kms-key https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/rds_cluster#rdsaurora-managed-master-passwords-via-secrets-manager-specific-kms-key 既存の Secrets Manager シークレットを利用する場合 今回は試していませんが、 master_user_secret の設定ブロックを使うと、既存の Secrets Manager シークレットをマスターユーザーのパスワードにできるようです。 （参考） https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance#master_user_secret 既存のDBに使ったらどうなるか 既に password や master_password を使って作成した DB に対して、 manage_master_user_password を利用する方法に切り替えることは可能です。DB は再作成されませんが、マスターユーザーのパスワードは新規に作成され（現在のパスワードは引き継がれずに） Secrets Manager に新しいシークレットとして保存されるようです。既存の DB で manage_master_user_password を使う方法に切り替える場合は、アプリケーションの動作や運用に影響がないか慎重に確認しましょう。 スナップショットからリストアする時の挙動 manage_master_user_password を利用して作成した DB のスナップショットからリストアする場合、マスターユーザーのパスワードは少し特殊な状態になるようです。次のように manage_master_user_password = true を使ってスナップショットから DB インスタンス を作成しても、Secrets Manager にパスワードは統合されず、RDS がパスワードを管理している状態で DB が復元しました。パスワードはスナップショット取得時点のものでした。 data "aws_db_snapshot" "my-snapshot" { db_snapshot_identifier = "snapshot1" } resource "aws_db_instance" "my-db-from-snapshot" { allocated_storage = 10 engine = "mysql" engine_version = "5.7" instance_class = "db.t3.micro" username = "master" # snapshot_identifier を利用してリストアする時、 # manage_master_user_password 属性を使っても # パスワードが Secrets Manager で管理されない。 manage_master_user_password = true skip_final_snapshot = true db_subnet_group_name = "db-subnet-group" # スナップショットから復元する snapshot_identifier = "$ { data.aws_db_snapshot.my-snapshot.id } " } この現象は GitHub の Issue にも報告されており、記事執筆時点では未解決です。ただし tfstate ファイルに記録された password は null だったため、Terraform AWS Provider のバグというよりは RDS の制約なのかもしれません。 リストアした DB のパスワードも Secrets Manager で管理するためには、今のところの次の ワークアラウンド が良さそうです。 manage_master_user_password を付けずに Terraform でスナップショットをリストア（ apply ） スナップショット取得時点のパスワードを、RDS が管理している状態でリストアされる manage_master_user_password = true を付けてもう一度 apply する マスターユーザーのパスワードは新規に作成されて Secrets Manager に保存される data "aws_db_snapshot" "my-snapshot" { db_snapshot_identifier = "snapshot1" } resource "aws_db_instance" "my-db-from-snapshot" { allocated_storage = 10 engine = "mysql" engine_version = "5.7" instance_class = "db.t3.micro" username = "master" # リストア時は manage_master_user_password を付けずに apply # リストア後 manage_master_user_password を付けて再度 apply # manage_master_user_password = true skip_final_snapshot = true db_subnet_group_name = "db-subnet-group" snapshot_identifier = "$ { data.aws_db_snapshot.my-snapshot.id } " } さいごに Terraform において tfstate ファイルに平文の DB パスワードが残ってしまう問題を簡単に解消する manage_master_user_password 属性についてご紹介しました。今後新たに Terraform で RDS インスタンス / クラスタ ーを作る時には、ぜひ利用を検討しましょう。ただしスナップショットからリストアする時の動きは（記事執筆時点で）少し特殊なので要注意です。 お読みいただいてありがとうございました。 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア 執筆： @kou.kinyo 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

みなさんこんにちは！　ISID 金融ソリューション事業部の松崎です。 前回 の記事では、「フォトグラメトリによる3Dモデル作成ワークフロー（後編）」と題し、 フォトグラメトリで使用する写真撮影後の現像や加工手法、RealityCaptureを使ってのモデル作成方法について紹介しました。 まだご覧になっていない方は、是非読んでいただけると嬉しいです！ 今回は、回転台とグリーンバックを使ったお手軽フォトグラメトリ方法を紹介します。 はじめに フォトグラメトリにおいて、「写真撮影」は手間のかかる工程の1つです。 なぜなら、フォトグラメトリでは物体を様々なアングルで撮影する必要があるからです。 1、2つの物体を対象としている場合ならまだしも、小物を量産するなどで対象物体が何個もある場合は、撮影だけで非常に時間がかかってしまいます。 今回は、そんな撮影の手間を大幅に減らす方法を試してみました。 具体的な方法としては、「回転台を使って物体側を回転させる」というものです。 物体の方を回転させてしまえば、カメラは固定したまま様々なアングルで撮影することが出来ますので、簡単にハイクオリティな撮影が可能になります。 しかし、通常フォトグラメトリでは物体を静止させる必要があります。 理由としては、物体の位置・向きや背景情報を使って写真の撮影位置を推定しているからです。 物体の位置や向きが途中で変わってしまうと、背景情報との整合性が保てなくなり、位置推定が出来なくなってしまいます。 そこで、今回はグリーンバックを使用しました。 あらかじめ背景をグリーンバックで統一しておき、現像時にマスク化を行います。 これにより、対象物体の位置・向きのみを用いて撮影位置を推定させることが出来ます。 以下、その手順を説明していきます。 手順 写真撮影 RAW現像 マスク・切り抜き処理 モデル作成 使用機材 回転台 3DCGモデルを作成したい対象物体を載せる回転台です。 後に写真の回転台部分もマスク化処理をかけることを考えると、単色のものが望ましいです。 また、種類によって「プレートの大きさ」「耐荷重」「回転できる角度」などが異なります。 乗せる物体をある程度想定し、適切なものを購入しましょう。 参考までに、私達が所持している回転台のスペックを記載します。 プレートの大きさ：40cm 耐荷重：100kg 回転できる角度：0.1°～90° グリーンバック 回転台や対象物体の背景に設置するグリーンバックです。 グリーンバックは、なるべくシワや折り目がないようにしましょう。 （クロマキー合成をするわけではないので、過剰に気にする必要はないです） 私達の購入したグリーンバックは、購入時は折り目とシワがクッキリとついてしまっていました。 色々とシワ解消方法を試しましたが、衣類用のスチームアイロンを使用するのが最も効果的でした。 三脚 カメラを固定する用の三脚です。 今回はカメラを乗せて置いておくだけですので、ある程度の高さ調節機能があれば良いです。 1.写真撮影 まず初めに写真撮影を行います。 前述した通り、以下のように「カメラ/三脚」「対象物」「回転台」「グリーンバック」を配置しました。 三脚の最低高さが30㎝ほどあり、回転台を床に置くとかなり下向きな視点になってしまう為、ローテーブルの上に回転台を置いています。 上記の配置にて撮影した写真例を以下に示します。 ブログに載せる過程で画質が下がっておりますが、実際にはテーブルやグリーンバックまで鮮明に撮影しております。 回転台を用いた撮影では、 対象物と周囲の境界が明確になること を心がけました。 （今回は黒・白・緑で周囲が埋まる様にした） これにより、マスク処理を行う際に対象物が正確にマスクされやすくなります。（詳細は3章にて説明します） 今回は裏面も含めてモデル化を行いますので、対象物を裏返した状態でも撮影を行いました。 全て合計すると、230枚ほど撮影しています。(回転台は約7度ずつ回転) 以前、回転台を使わずに撮影した際は1時間以上かかりましたが、今回は 20分 ほどで撮影完了しました。 以上で、写真撮影は完了です。 2.RAW現像 次に、写真のRAW現像を行います。 今回は簡略化して紹介していますので、RAW現像に関する詳細な手順を知りたい方は こちらの記事 をご参照ください。 撮影した写真を Adobe Bridgeにて開き、ファイル名を一括変更します。 ファイル名を変更した写真を Adobe Lightroom で開き、 ヒストグラム を見ながら明暗・色味を調整して現像します。 RAW現像を行い、下記のようにJPG形式のファイルを生成しました。 3.マスク・切り抜き処理 写真のRAW現像が完了しましたら、マスク・切り抜き処理を行います。 なお、マスク・切り抜きには以下のアプリを使用します。 Adobe Photoshop （Win/ mac 対応　有料：1078円/月　※2023年7月現在） まず初めに、 Adobe Photoshop を起動します。 起動しましたら、「ウィンドウ → アクション」でアクションウィンドウを表示させます。 アクションとは Photoshop の自動化ツールの1つです。 今回は、「RAW現像した写真からモデル化対象物のみを切り抜く処理」をアクションとして記録していきます。 アクションウィンドウが表示されましたら、「新規アクションを作成」を選択します。 アクションの設定画面が表示されますので、アクション名を入力して、アクションの記録を開始します。 今回は、「背景削除」と 命名 しました。 記録が開始されましたら、先ほどRAW現像したファイルの一つを開きます。 「ファイル → 開く」でファイル選択画面を表示し、RAW現像したファイルが格納されているフォルダから、1つ選択します。 （この1つは、上記フォルダ内のファイルであればどれでも大丈夫です） ファイルが開けましたら、「選択範囲 → 選択とマスク」を押下しマスク選択状態にします。 「被写体を選択」モードにした上で、画面上の被写体（モデル化の対象物）を左クリックします。 この際、被写体とその周辺の境界が曖昧ですと、被写体の選択範囲が正確に推定されないことがあります。 被写体の選択範囲が正確でない場合は、写真撮影をやり直すことが望ましいです。 （他の写真でも同様の事象が発生する可能性が高い為） 被写体が選択できましたら「出力設定 → 不要なカラーの除去」にチェックを入れ、「OK」を押してマスク選択を終了します。 「ファイル → コピーを保存」を選択し、RAW現像ファイルが格納されているフォルダと同じ ディレクト リに別フォルダを作成して保存します。ファイル形式は JPEG を選択します。 「保存」を押すと、 JPEG オプションが表示されます。今回は最高画質を選択しました。 保存が完了しましたら、アクションの記録を停止します。 これにて、「RAW現像した写真からモデル化対象物のみを切り抜く処理」をアクションとして記録できました。 記録したアクションを利用して、RAW現像したすべての写真に切り抜き処理を適用させます。 「ファイル → 自動処理 → バッチ」を選択します。 バッチでは、以下のように設定を行います。 アクション：背景削除（上記で記録したアクション） ソース：フォルダ ソースフォルダ選択：RAW現像した写真が格納されているフォルダ（Developed） "開く"コマンドを無視：ON 実行後：フォルダ 実行後フォルダ選択：アクション記録中に作成した別フォルダ（Masked） "別名で保存"コマンドを省略：ON 設定が完了しましたら、「OK」を押して自動処理が完了するまで待ちます。 約230枚の自動処理に 1時間30分 ほどかかりました。 自動処理が完了すると、以下のように対象物のみ切り抜かれたファイルが作成されています。 念のため、対象物が正確に切り抜かれていることを確認します。 下図のように不自然に白くなっている部分がある場合などは、手動で切り抜き処理をやり直します。 何度試しても上手く切り抜けない写真は、テクスチャ作成時に使用しないなどの対処を検討しましょう。 4.モデル作成 前章にてモデル化に必要な素材写真がそろいましたので、RealityCaptureを用いてモデル・テクスチャを作成します。 今回は簡略化して紹介していますので、モデル・テクスチャの作成に関する詳細な手順を知りたい方は こちらの記事 をご参照ください。 RealityCaptureを開き、対象物を切り抜いた写真が格納されているファイルを取り込みます。 続いて、アライメントを実行します。 アライメントの結果、2つの コンポーネント が作成されました。（所要時間：3分） これは、対象物の表面・裏面を両方撮影している為です。 このままでは表面・裏面のモデルがそれぞれ作成されてしまうので、コン トロール ポイントを用いて2つの コンポーネント をマージします。 コン トロール ポイントとは、写真や コンポーネント 上に目印となるポイントを設定できる機能です。 コンポーネント 間の共通ポイントをコン トロール ポイントとして指定することで、異なる コンポーネント をマージすることが出来ます。 まず、「IMAGE 2D → TOOLS → Add Control Points」を選択し、コン トロール ポイント設定状態にします。 コンポーネント 1にコン トロール ポイントを設定していきます。 画面上の点群から、コン トロール ポイントとして設定する点を左クリックします。 コン トロール ポイントの設定基準としては、以下を意識しましょう。 両方の コンポーネント に存在する点 対象物の中で特徴的な点（角部分や、色が変化している部分） 今回は、コン トロール ポイントを3点設定しました。 3次元の コンポーネント をマージすることを踏まえると、最低3点は設定することが望ましいです。 同様に、 コンポーネント 0にもコン トロール ポイントを設定します。 コンポーネント 1で設定したコン トロール ポイントと同じ部分を設定しましょう。 （ コンポーネント 間でコン トロール ポイントの位置が異なると、ズレた状態でマージされてしまいます） 次に、設定したコン トロール ポイントと各写真の位置推定結果に差がないことを検証します。 写真1枚ごとに「+」を押し、提案された全ての写真に対して検証を行いましょう。 検証結果に問題がない場合は、「アライメント → コンポーネント のマージ」から コンポーネント のマージを行います。 コンポーネント がマージされ、表面・裏面の両方が含まれる新規 コンポーネント が作成されました。 マージ時にズレが発生していないことを確認した後、「Mesh Model → High Detail」を選択しメッシュモデルを作成します。 メッシュモデルが作成できました。（所要時間：80分） 次に、「Mesh Model → Tecture」からテクスチャを作成します。 テクスチャが作成されました。（所要時間：20分） 以上で、3DCGモデルの作成完了です。 おわりに 本記事では、回転台とグリーンバッグを用いたお手軽フォトグラメトリ方法について紹介しました。 回転台を使った撮影方法と、通常の撮影方法における「写真撮影～現像などの後処理」までの所要時間は以下になります。 通常方式：写真撮影（約80分） + 後処理（約20分）= 約100分（人の作業時間：100分） 回転台方式：写真撮影（約20分） + 後処理（約20分+約90分）= 約130分（人の作業時間：40分） 回転台方式では撮影時間を短縮できる一方、 Photoshop での切り抜き処理に時間を要してしまい、合計所要時間では通常方式が早い結果となりました。 一方、通常の撮影方法では人が100分間作業し続ける必要があるのに対し、回転台方式では後処理の90分間を Photoshop が自動的に進めてくれます。人が作業する時間で考えると、回転台方式が圧倒的に早い結果となりました。 実際に運用する際は、 Photoshop での処理中に次の撮影を行うなど、時間を工夫して効率化を図ることが望ましいです。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ 参考文献 ・ 初歩からのフォトグラメトリ～RealityCaptureの使い方(ターンテーブル編) ・ フォトグラメトリによる3Dモデル作成ワークフロー（後編） ・ Adobe Photoshop 公式サイト ・ 最新版Photoshopの「選択とマスク」で画像を切り抜く方法 ・ Photoshopのアクション機能（自動処理）を使って複数の画像を一括編集する方法 ・ はじめてのRealityCapture - 完全なモデルを作成する手順 執筆： @matsuzaki.shota 、レビュー： @wakamoto.ryosuke （ Shodo で執筆されました ）

みなさんこんにちは！　ISID 金融ソリューション事業部の松崎です。 前回 の記事では、「フォトグラメトリによる3Dモデル作成ワークフロー（後編）」と題し、 フォトグラメトリで使用する写真撮影後の現像や加工手法、RealityCaptureを使ってのモデル作成方法について紹介しました。 まだご覧になっていない方は、是非読んでいただけると嬉しいです！ 今回は、回転台とグリーンバックを使ったお手軽フォトグラメトリ方法を紹介します。 はじめに フォトグラメトリにおいて、「写真撮影」は手間のかかる工程の1つです。 なぜなら、フォトグラメトリでは物体を様々なアングルで撮影する必要があるからです。 1、2つの物体を対象としている場合ならまだしも、小物を量産するなどで対象物体が何個もある場合は、撮影だけで非常に時間がかかってしまいます。 今回は、そんな撮影の手間を大幅に減らす方法を試してみました。 具体的な方法としては、「回転台を使って物体側を回転させる」というものです。 物体の方を回転させてしまえば、カメラは固定したまま様々なアングルで撮影することが出来ますので、簡単にハイクオリティな撮影が可能になります。 しかし、通常フォトグラメトリでは物体を静止させる必要があります。 理由としては、物体の位置・向きや背景情報を使って写真の撮影位置を推定しているからです。 物体の位置や向きが途中で変わってしまうと、背景情報との整合性が保てなくなり、位置推定が出来なくなってしまいます。 そこで、今回はグリーンバックを使用しました。 あらかじめ背景をグリーンバックで統一しておき、現像時にマスク化を行います。 これにより、対象物体の位置・向きのみを用いて撮影位置を推定させることが出来ます。 以下、その手順を説明していきます。 手順 写真撮影 RAW現像 マスク・切り抜き処理 モデル作成 使用機材 回転台 3DCGモデルを作成したい対象物体を載せる回転台です。 後に写真の回転台部分もマスク化処理をかけることを考えると、単色のものが望ましいです。 また、種類によって「プレートの大きさ」「耐荷重」「回転できる角度」などが異なります。 乗せる物体をある程度想定し、適切なものを購入しましょう。 参考までに、私達が所持している回転台のスペックを記載します。 プレートの大きさ：40cm 耐荷重：100kg 回転できる角度：0.1°～90° グリーンバック 回転台や対象物体の背景に設置するグリーンバックです。 グリーンバックは、なるべくシワや折り目がないようにしましょう。 （クロマキー合成をするわけではないので、過剰に気にする必要はないです） 私達の購入したグリーンバックは、購入時は折り目とシワがクッキリとついてしまっていました。 色々とシワ解消方法を試しましたが、衣類用のスチームアイロンを使用するのが最も効果的でした。 三脚 カメラを固定する用の三脚です。 今回はカメラを乗せて置いておくだけですので、ある程度の高さ調節機能があれば良いです。 1.写真撮影 まず初めに写真撮影を行います。 前述した通り、以下のように「カメラ/三脚」「対象物」「回転台」「グリーンバック」を配置しました。 三脚の最低高さが30㎝ほどあり、回転台を床に置くとかなり下向きな視点になってしまう為、ローテーブルの上に回転台を置いています。 上記の配置にて撮影した写真例を以下に示します。 ブログに載せる過程で画質が下がっておりますが、実際にはテーブルやグリーンバックまで鮮明に撮影しております。 回転台を用いた撮影では、 対象物と周囲の境界が明確になること を心がけました。 （今回は黒・白・緑で周囲が埋まる様にした） これにより、マスク処理を行う際に対象物が正確にマスクされやすくなります。（詳細は3章にて説明します） 今回は裏面も含めてモデル化を行いますので、対象物を裏返した状態でも撮影を行いました。 全て合計すると、230枚ほど撮影しています。(回転台は約7度ずつ回転) 以前、回転台を使わずに撮影した際は1時間以上かかりましたが、今回は 20分 ほどで撮影完了しました。 以上で、写真撮影は完了です。 2.RAW現像 次に、写真のRAW現像を行います。 今回は簡略化して紹介していますので、RAW現像に関する詳細な手順を知りたい方は こちらの記事 をご参照ください。 撮影した写真を Adobe Bridgeにて開き、ファイル名を一括変更します。 ファイル名を変更した写真を Adobe Lightroom で開き、 ヒストグラム を見ながら明暗・色味を調整して現像します。 RAW現像を行い、下記のようにJPG形式のファイルを生成しました。 3.マスク・切り抜き処理 写真のRAW現像が完了しましたら、マスク・切り抜き処理を行います。 なお、マスク・切り抜きには以下のアプリを使用します。 Adobe Photoshop （Win/ mac 対応　有料：1078円/月　※2023年7月現在） まず初めに、 Adobe Photoshop を起動します。 起動しましたら、「ウィンドウ → アクション」でアクションウィンドウを表示させます。 アクションとは Photoshop の自動化ツールの1つです。 今回は、「RAW現像した写真からモデル化対象物のみを切り抜く処理」をアクションとして記録していきます。 アクションウィンドウが表示されましたら、「新規アクションを作成」を選択します。 アクションの設定画面が表示されますので、アクション名を入力して、アクションの記録を開始します。 今回は、「背景削除」と 命名 しました。 記録が開始されましたら、先ほどRAW現像したファイルの一つを開きます。 「ファイル → 開く」でファイル選択画面を表示し、RAW現像したファイルが格納されているフォルダから、1つ選択します。 （この1つは、上記フォルダ内のファイルであればどれでも大丈夫です） ファイルが開けましたら、「選択範囲 → 選択とマスク」を押下しマスク選択状態にします。 「被写体を選択」モードにした上で、画面上の被写体（モデル化の対象物）を左クリックします。 この際、被写体とその周辺の境界が曖昧ですと、被写体の選択範囲が正確に推定されないことがあります。 被写体の選択範囲が正確でない場合は、写真撮影をやり直すことが望ましいです。 （他の写真でも同様の事象が発生する可能性が高い為） 被写体が選択できましたら「出力設定 → 不要なカラーの除去」にチェックを入れ、「OK」を押してマスク選択を終了します。 「ファイル → コピーを保存」を選択し、RAW現像ファイルが格納されているフォルダと同じ ディレクト リに別フォルダを作成して保存します。ファイル形式は JPEG を選択します。 「保存」を押すと、 JPEG オプションが表示されます。今回は最高画質を選択しました。 保存が完了しましたら、アクションの記録を停止します。 これにて、「RAW現像した写真からモデル化対象物のみを切り抜く処理」をアクションとして記録できました。 記録したアクションを利用して、RAW現像したすべての写真に切り抜き処理を適用させます。 「ファイル → 自動処理 → バッチ」を選択します。 バッチでは、以下のように設定を行います。 アクション：背景削除（上記で記録したアクション） ソース：フォルダ ソースフォルダ選択：RAW現像した写真が格納されているフォルダ（Developed） "開く"コマンドを無視：ON 実行後：フォルダ 実行後フォルダ選択：アクション記録中に作成した別フォルダ（Masked） "別名で保存"コマンドを省略：ON 設定が完了しましたら、「OK」を押して自動処理が完了するまで待ちます。 約230枚の自動処理に 1時間30分 ほどかかりました。 自動処理が完了すると、以下のように対象物のみ切り抜かれたファイルが作成されています。 念のため、対象物が正確に切り抜かれていることを確認します。 下図のように不自然に白くなっている部分がある場合などは、手動で切り抜き処理をやり直します。 何度試しても上手く切り抜けない写真は、テクスチャ作成時に使用しないなどの対処を検討しましょう。 4.モデル作成 前章にてモデル化に必要な素材写真がそろいましたので、RealityCaptureを用いてモデル・テクスチャを作成します。 今回は簡略化して紹介していますので、モデル・テクスチャの作成に関する詳細な手順を知りたい方は こちらの記事 をご参照ください。 RealityCaptureを開き、対象物を切り抜いた写真が格納されているファイルを取り込みます。 続いて、アライメントを実行します。 アライメントの結果、2つの コンポーネント が作成されました。（所要時間：3分） これは、対象物の表面・裏面を両方撮影している為です。 このままでは表面・裏面のモデルがそれぞれ作成されてしまうので、コン トロール ポイントを用いて2つの コンポーネント をマージします。 コン トロール ポイントとは、写真や コンポーネント 上に目印となるポイントを設定できる機能です。 コンポーネント 間の共通ポイントをコン トロール ポイントとして指定することで、異なる コンポーネント をマージすることが出来ます。 まず、「IMAGE 2D → TOOLS → Add Control Points」を選択し、コン トロール ポイント設定状態にします。 コンポーネント 1にコン トロール ポイントを設定していきます。 画面上の点群から、コン トロール ポイントとして設定する点を左クリックします。 コン トロール ポイントの設定基準としては、以下を意識しましょう。 両方の コンポーネント に存在する点 対象物の中で特徴的な点（角部分や、色が変化している部分） 今回は、コン トロール ポイントを3点設定しました。 3次元の コンポーネント をマージすることを踏まえると、最低3点は設定することが望ましいです。 同様に、 コンポーネント 0にもコン トロール ポイントを設定します。 コンポーネント 1で設定したコン トロール ポイントと同じ部分を設定しましょう。 （ コンポーネント 間でコン トロール ポイントの位置が異なると、ズレた状態でマージされてしまいます） 次に、設定したコン トロール ポイントと各写真の位置推定結果に差がないことを検証します。 写真1枚ごとに「+」を押し、提案された全ての写真に対して検証を行いましょう。 検証結果に問題がない場合は、「アライメント → コンポーネント のマージ」から コンポーネント のマージを行います。 コンポーネント がマージされ、表面・裏面の両方が含まれる新規 コンポーネント が作成されました。 マージ時にズレが発生していないことを確認した後、「Mesh Model → High Detail」を選択しメッシュモデルを作成します。 メッシュモデルが作成できました。（所要時間：80分） 次に、「Mesh Model → Tecture」からテクスチャを作成します。 テクスチャが作成されました。（所要時間：20分） 以上で、3DCGモデルの作成完了です。 おわりに 本記事では、回転台とグリーンバッグを用いたお手軽フォトグラメトリ方法について紹介しました。 回転台を使った撮影方法と、通常の撮影方法における「写真撮影～現像などの後処理」までの所要時間は以下になります。 通常方式：写真撮影（約80分） + 後処理（約20分）= 約100分（人の作業時間：100分） 回転台方式：写真撮影（約20分） + 後処理（約20分+約90分）= 約130分（人の作業時間：40分） 回転台方式では撮影時間を短縮できる一方、 Photoshop での切り抜き処理に時間を要してしまい、合計所要時間では通常方式が早い結果となりました。 一方、通常の撮影方法では人が100分間作業し続ける必要があるのに対し、回転台方式では後処理の90分間を Photoshop が自動的に進めてくれます。人が作業する時間で考えると、回転台方式が圧倒的に早い結果となりました。 実際に運用する際は、 Photoshop での処理中に次の撮影を行うなど、時間を工夫して効率化を図ることが望ましいです。 現在ISIDは web3領域のグループ横断組織 を立ち上げ、Web3および メタバース 領域のR&Dを行っております（カテゴリー「3DCG」の記事は こちら ）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ ISID採用ページ 参考文献 ・ 初歩からのフォトグラメトリ～RealityCaptureの使い方(ターンテーブル編) ・ フォトグラメトリによる3Dモデル作成ワークフロー（後編） ・ Adobe Photoshop 公式サイト ・ 最新版Photoshopの「選択とマスク」で画像を切り抜く方法 ・ Photoshopのアクション機能（自動処理）を使って複数の画像を一括編集する方法 ・ はじめてのRealityCapture - 完全なモデルを作成する手順 執筆： @matsuzaki.shota 、レビュー： @wakamoto.ryosuke （ 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 で執筆されました ）

こんにちは。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 で執筆されました ）