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

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

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

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

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

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

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

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

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

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

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

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

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

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

こんにちは。X（クロス） イノベーション 本部 クラウド イノベーション センターの柴田です。 本記事ではTerraformでコードを変更していないリソースが known after apply となってしまう場合の回避策をご紹介します。 前提 問題となるコードの例 原因 回避策 おわりに 参考 前提 この記事は以下のTerraformのバージョンを前提とします。 新しいバージョンのTerraformでは本記事と異なる挙動をする可能性があります。 $ terraform version Terraform v1.5.3 on linux_amd64 + provider registry.terraform.io/hashicorp/aws v5.7.0 問題となるコードの例 以下のTerraformコードを例に考えてみましょう。 resource "aws_s3_bucket" "sample" { bucket_prefix = "sample-" tags = { Project = "My Project A" } } data "aws_iam_policy_document" "sample" { statement { effect = "Allow" actions = [ "s3:*" ] resources = [ aws_s3_bucket.sample.arn ] } } resource "aws_iam_policy" "sample" { name = "SampleBucketFullAccess" path = "/" policy = data.aws_iam_policy_document.sample.json } このTerraformコードを terraform apply します。 $ terraform apply Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create <= read (data resources) Terraform will perform the following actions: # data.aws_iam_policy_document.sample will be read during apply # (config refers to values not yet known) <= data "aws_iam_policy_document" "sample" { + id = (known after apply) + json = (known after apply) + statement { + actions = [ + "s3:*", ] + effect = "Allow" + resources = [ + (known after apply), ] } } # aws_iam_policy.sample will be created + resource "aws_iam_policy" "sample" { + arn = (known after apply) + id = (known after apply) + name = "SampleBucketFullAccess" + name_prefix = (known after apply) + path = "/" + policy = (known after apply) + policy_id = (known after apply) + tags_all = (known after apply) } # aws_s3_bucket.sample will be created + resource "aws_s3_bucket" "sample" { + acceleration_status = (known after apply) + acl = (known after apply) + arn = (known after apply) + bucket = (known after apply) + bucket_domain_name = (known after apply) + bucket_prefix = "sample-" + bucket_regional_domain_name = (known after apply) + force_destroy = false + hosted_zone_id = (known after apply) + id = (known after apply) + object_lock_enabled = (known after apply) + policy = (known after apply) + region = (known after apply) + request_payer = (known after apply) + tags = { + "Project" = "My Project A" } + tags_all = { + "Project" = "My Project A" } + website_domain = (known after apply) + website_endpoint = (known after apply) } Plan: 2 to add, 0 to change, 0 to destroy. Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes aws_s3_bucket.sample: Creating... aws_s3_bucket.sample: Creation complete after 1s [id=sample-20230713121614963200000001] data.aws_iam_policy_document.sample: Reading... data.aws_iam_policy_document.sample: Read complete after 0s [id=55239551] aws_iam_policy.sample: Creating... aws_iam_policy.sample: Creation complete after 1s [id=arn:aws:iam::************:policy/SampleBucketFullAccess] Apply complete! Resources: 2 added, 0 changed, 0 destroyed. 次にS3 バケット aws_s3_bucket.sample の Project タグの値を変更します。 resource "aws_s3_bucket" "sample" { bucket_prefix = "sample-" tags = { - Project = "My Project A" + Project = "My Project B" } } 変更後のTerraformコードに対して terraform plan を実行します。 $ terraform plan aws_s3_bucket.sample: Refreshing state... [id=sample-20230713121614963200000001] aws_iam_policy.sample: Refreshing state... [id=arn:aws:iam::************:policy/SampleBucketFullAccess] Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: ~ update in-place <= read (data resources) Terraform will perform the following actions: # data.aws_iam_policy_document.sample will be read during apply # (depends on a resource or a module with changes pending) <= data "aws_iam_policy_document" "sample" { + id = (known after apply) + json = (known after apply) + statement { + actions = [ + "s3:*", ] + effect = "Allow" + resources = [ + "arn:aws:s3:::sample-20230713121614963200000001", ] } } # aws_iam_policy.sample will be updated in-place ~ resource "aws_iam_policy" "sample" { id = "arn:aws:iam::************:policy/SampleBucketFullAccess" name = "SampleBucketFullAccess" ~ policy = jsonencode( { - Statement = [ - { - Action = "s3:*" - Effect = "Allow" - Resource = "arn:aws:s3:::sample-20230713121614963200000001" }, ] - Version = "2012-10-17" } ) -> (known after apply) tags = {} # (4 unchanged attributes hidden) } # aws_s3_bucket.sample will be updated in-place ~ resource "aws_s3_bucket" "sample" { id = "sample-20230713121614963200000001" ~ tags = { ~ "Project" = "My Project A" -> "My Project B" } ~ tags_all = { ~ "Project" = "My Project A" -> "My Project B" } # (10 unchanged attributes hidden) # (3 unchanged blocks hidden) } Plan: 0 to add, 2 to change, 0 to destroy. すると、変更がないはずのIAM policy aws_iam_policy.sample の policy が known after apply となってしまいました。 原因 これはData Sourceの仕様によるものです。 Data Resource Dependencies には以下のように記述されています。 Data resources have the same dependency resolution behavior as defined for managed resources . Setting the depends_on meta-argument within data blocks defers reading of the data source until after all changes to the dependencies have been applied. In order to ensure that data sources are accessing the most up to date information possible in a wide variety of use cases, arguments directly referencing managed resources are treated the same as if the resource was listed in depends_on . 要約すると以下のとおりです。 Data Sourceでは depends_on に記載されたリソースのすべての変更が適用されるまで読み取りは延期される。 Data Sourceの引数が他のリソースを直接参照している場合、参照先のリソースがData Sourceの depends_on に含まれている場合と同じように扱われる。 つまり Data Sourceが直接参照しているリソースに変更がある場合、それらの変更が適用されたあと、Data Sourceの読み取りが再実行される ということです。 改めて先ほどの例を考えてみましょう。Terraformが以下のように判断していたことがわかります。 aws_s3_bucket.sample のコードの変更が検出される。 data.aws_iam_policy_document.sample は aws_s3_bucket.sample を直接参照しているため、 depends_on に aws_s3_bucket.sample が含まれている場合と同じように扱われる。 depends_on に含まれる aws_s3_bucket.sample の変更が検出されたため、その変更が適用されたあとで data.aws_iam_policy_document.sample の再読み取りを行う必要があると判断される。 3をうけて aws_iam_policy.sample の policy が更新されると判断される。 回避策 Data Resource Dependencies には以下のように記述されています。 This behavior can be avoided when desired by indirectly referencing the managed resource values through a local value , unless the data resource itself has custom conditions . どうやら Local Value を間に挟むことで先ほどの事象を回避できるようです。 試してみましょう。先ほどのTerraformコードを以下のように変更します。 provider "aws" { region = "ap-northeast-1" } resource "aws_s3_bucket" "sample" { bucket_prefix = "sample-" tags = { Project = "My Project B" } } locals { s3_bucket_arn = aws_s3_bucket.sample.arn } data "aws_iam_policy_document" "sample" { statement { effect = "Allow" actions = [ "s3:*" ] resources = [ local.s3_bucket_arn ] } } resource "aws_iam_policy" "sample" { name = "SampleBucketFullAccess" path = "/" policy = data.aws_iam_policy_document.sample.json } 変更後のTerraformコードに対して terraform plan を実行します。 $ terraform plan aws_s3_bucket.sample: Refreshing state... [id=sample-20230713121614963200000001] data.aws_iam_policy_document.sample: Reading... data.aws_iam_policy_document.sample: Read complete after 0s [id=55239551] aws_iam_policy.sample: Refreshing state... [id=arn:aws:iam::************:policy/SampleBucketFullAccess] Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: ~ update in-place Terraform will perform the following actions: # aws_s3_bucket.sample will be updated in-place ~ resource "aws_s3_bucket" "sample" { id = "sample-20230713121614963200000001" ~ tags = { ~ "Project" = "My Project A" -> "My Project B" } ~ tags_all = { ~ "Project" = "My Project A" -> "My Project B" } # (10 unchanged attributes hidden) # (3 unchanged blocks hidden) } Plan: 0 to add, 1 to change, 0 to destroy. S3 バケット aws_s3_bucket.sample 以外の変更が表示されないことを確認できました。 おわりに 本記事ではTerraformでコードを変更していないリソースが known after apply となってしまう場合の回避策をご紹介しました。 この記事がこの問題に悩んでいる方のお役に立てば幸いです。 最後までお読みいただき、ありがとうございました。 参考 Data Sources - Configuration Language | Terraform | HashiCorp Developer date source referencing managed resource proposes unnecessary changes under 0.14 · Issue #27171 · hashicorp/terraform 私たちは一緒に働いてくれる仲間を募集しています！ クラウドアーキテクト 執筆： @shibata.takao 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 クラウド イノベーション センターの柴田です。 本記事ではTerraformでコードを変更していないリソースが known after apply となってしまう場合の回避策をご紹介します。 前提 問題となるコードの例 原因 回避策 おわりに 参考 前提 この記事は以下のTerraformのバージョンを前提とします。 新しいバージョンのTerraformでは本記事と異なる挙動をする可能性があります。 $ terraform version Terraform v1.5.3 on linux_amd64 + provider registry.terraform.io/hashicorp/aws v5.7.0 問題となるコードの例 以下のTerraformコードを例に考えてみましょう。 resource "aws_s3_bucket" "sample" { bucket_prefix = "sample-" tags = { Project = "My Project A" } } data "aws_iam_policy_document" "sample" { statement { effect = "Allow" actions = [ "s3:*" ] resources = [ aws_s3_bucket.sample.arn ] } } resource "aws_iam_policy" "sample" { name = "SampleBucketFullAccess" path = "/" policy = data.aws_iam_policy_document.sample.json } このTerraformコードを terraform apply します。 $ terraform apply Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create <= read (data resources) Terraform will perform the following actions: # data.aws_iam_policy_document.sample will be read during apply # (config refers to values not yet known) <= data "aws_iam_policy_document" "sample" { + id = (known after apply) + json = (known after apply) + statement { + actions = [ + "s3:*", ] + effect = "Allow" + resources = [ + (known after apply), ] } } # aws_iam_policy.sample will be created + resource "aws_iam_policy" "sample" { + arn = (known after apply) + id = (known after apply) + name = "SampleBucketFullAccess" + name_prefix = (known after apply) + path = "/" + policy = (known after apply) + policy_id = (known after apply) + tags_all = (known after apply) } # aws_s3_bucket.sample will be created + resource "aws_s3_bucket" "sample" { + acceleration_status = (known after apply) + acl = (known after apply) + arn = (known after apply) + bucket = (known after apply) + bucket_domain_name = (known after apply) + bucket_prefix = "sample-" + bucket_regional_domain_name = (known after apply) + force_destroy = false + hosted_zone_id = (known after apply) + id = (known after apply) + object_lock_enabled = (known after apply) + policy = (known after apply) + region = (known after apply) + request_payer = (known after apply) + tags = { + "Project" = "My Project A" } + tags_all = { + "Project" = "My Project A" } + website_domain = (known after apply) + website_endpoint = (known after apply) } Plan: 2 to add, 0 to change, 0 to destroy. Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes aws_s3_bucket.sample: Creating... aws_s3_bucket.sample: Creation complete after 1s [id=sample-20230713121614963200000001] data.aws_iam_policy_document.sample: Reading... data.aws_iam_policy_document.sample: Read complete after 0s [id=55239551] aws_iam_policy.sample: Creating... aws_iam_policy.sample: Creation complete after 1s [id=arn:aws:iam::************:policy/SampleBucketFullAccess] Apply complete! Resources: 2 added, 0 changed, 0 destroyed. 次にS3 バケット aws_s3_bucket.sample の Project タグの値を変更します。 resource "aws_s3_bucket" "sample" { bucket_prefix = "sample-" tags = { - Project = "My Project A" + Project = "My Project B" } } 変更後のTerraformコードに対して terraform plan を実行します。 $ terraform plan aws_s3_bucket.sample: Refreshing state... [id=sample-20230713121614963200000001] aws_iam_policy.sample: Refreshing state... [id=arn:aws:iam::************:policy/SampleBucketFullAccess] Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: ~ update in-place <= read (data resources) Terraform will perform the following actions: # data.aws_iam_policy_document.sample will be read during apply # (depends on a resource or a module with changes pending) <= data "aws_iam_policy_document" "sample" { + id = (known after apply) + json = (known after apply) + statement { + actions = [ + "s3:*", ] + effect = "Allow" + resources = [ + "arn:aws:s3:::sample-20230713121614963200000001", ] } } # aws_iam_policy.sample will be updated in-place ~ resource "aws_iam_policy" "sample" { id = "arn:aws:iam::************:policy/SampleBucketFullAccess" name = "SampleBucketFullAccess" ~ policy = jsonencode( { - Statement = [ - { - Action = "s3:*" - Effect = "Allow" - Resource = "arn:aws:s3:::sample-20230713121614963200000001" }, ] - Version = "2012-10-17" } ) -> (known after apply) tags = {} # (4 unchanged attributes hidden) } # aws_s3_bucket.sample will be updated in-place ~ resource "aws_s3_bucket" "sample" { id = "sample-20230713121614963200000001" ~ tags = { ~ "Project" = "My Project A" -> "My Project B" } ~ tags_all = { ~ "Project" = "My Project A" -> "My Project B" } # (10 unchanged attributes hidden) # (3 unchanged blocks hidden) } Plan: 0 to add, 2 to change, 0 to destroy. すると、変更がないはずのIAM policy aws_iam_policy.sample の policy が known after apply となってしまいました。 原因 これはData Sourceの仕様によるものです。 Data Resource Dependencies には以下のように記述されています。 Data resources have the same dependency resolution behavior as defined for managed resources . Setting the depends_on meta-argument within data blocks defers reading of the data source until after all changes to the dependencies have been applied. In order to ensure that data sources are accessing the most up to date information possible in a wide variety of use cases, arguments directly referencing managed resources are treated the same as if the resource was listed in depends_on . 要約すると以下のとおりです。 Data Sourceでは depends_on に記載されたリソースのすべての変更が適用されるまで読み取りは延期される。 Data Sourceの引数が他のリソースを直接参照している場合、参照先のリソースがData Sourceの depends_on に含まれている場合と同じように扱われる。 つまり Data Sourceが直接参照しているリソースに変更がある場合、それらの変更が適用されたあと、Data Sourceの読み取りが再実行される ということです。 改めて先ほどの例を考えてみましょう。Terraformが以下のように判断していたことがわかります。 aws_s3_bucket.sample のコードの変更が検出される。 data.aws_iam_policy_document.sample は aws_s3_bucket.sample を直接参照しているため、 depends_on に aws_s3_bucket.sample が含まれている場合と同じように扱われる。 depends_on に含まれる aws_s3_bucket.sample の変更が検出されたため、その変更が適用されたあとで data.aws_iam_policy_document.sample の再読み取りを行う必要があると判断される。 3をうけて aws_iam_policy.sample の policy が更新されると判断される。 回避策 Data Resource Dependencies には以下のように記述されています。 This behavior can be avoided when desired by indirectly referencing the managed resource values through a local value , unless the data resource itself has custom conditions . どうやら Local Value を間に挟むことで先ほどの事象を回避できるようです。 試してみましょう。先ほどのTerraformコードを以下のように変更します。 provider "aws" { region = "ap-northeast-1" } resource "aws_s3_bucket" "sample" { bucket_prefix = "sample-" tags = { Project = "My Project B" } } locals { s3_bucket_arn = aws_s3_bucket.sample.arn } data "aws_iam_policy_document" "sample" { statement { effect = "Allow" actions = [ "s3:*" ] resources = [ local.s3_bucket_arn ] } } resource "aws_iam_policy" "sample" { name = "SampleBucketFullAccess" path = "/" policy = data.aws_iam_policy_document.sample.json } 変更後のTerraformコードに対して terraform plan を実行します。 $ terraform plan aws_s3_bucket.sample: Refreshing state... [id=sample-20230713121614963200000001] data.aws_iam_policy_document.sample: Reading... data.aws_iam_policy_document.sample: Read complete after 0s [id=55239551] aws_iam_policy.sample: Refreshing state... [id=arn:aws:iam::************:policy/SampleBucketFullAccess] Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: ~ update in-place Terraform will perform the following actions: # aws_s3_bucket.sample will be updated in-place ~ resource "aws_s3_bucket" "sample" { id = "sample-20230713121614963200000001" ~ tags = { ~ "Project" = "My Project A" -> "My Project B" } ~ tags_all = { ~ "Project" = "My Project A" -> "My Project B" } # (10 unchanged attributes hidden) # (3 unchanged blocks hidden) } Plan: 0 to add, 1 to change, 0 to destroy. S3 バケット aws_s3_bucket.sample 以外の変更が表示されないことを確認できました。 おわりに 本記事ではTerraformでコードを変更していないリソースが known after apply となってしまう場合の回避策をご紹介しました。 この記事がこの問題に悩んでいる方のお役に立てば幸いです。 最後までお読みいただき、ありがとうございました。 参考 Data Sources - Configuration Language | Terraform | HashiCorp Developer date source referencing managed resource proposes unnecessary changes under 0.14 · Issue #27171 · hashicorp/terraform 私たちは一緒に働いてくれる仲間を募集しています！ クラウドアーキテクト 執筆： @shibata.takao 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

こんにちは、X（クロス） イノベーション 本部 クラウド イノベーション センターの田村です。 2023 年 5 月の Microsoft Build にて統合分析プラットフォーム Microsoft Fabric が発表されました。 Microsoft Fabric は現在プレビュー中ですが、既存のサービスにはない機能追加や多くのアップデートが予定されており、 Microsoft のデータ領域ビジネスにおいて今後注目すべきサービスです。 本記事では、 Microsoft Fabric の概要とサービス検証として実施した勤怠データ分析の内容をご紹介します。 Microsoft Fabric の概要 One Lake Synapse Data Engineering Data Factory Power BI サービス検証：勤怠データの分析 概要 検証シナリオ：勤怠データ分析 検証アーキテクチャ Microsoft Fabric サブスクリプションの購入 Microsoft Fabric ワークスペースの作成 レイクハウスの作成 勤怠データの格納 ノートブックによるデータの整形 データフローによるデータの変換・加工 SQL エンドポイントによる分析 Power BI レポートの作成 サービス検証結果 一気通貫のデータ分析 データ分析の経験が浅いユーザーへのサポート 各機能の操作感 まとめ Microsoft Fabric の概要 Microsoft Fabric は、データ分析に必要な要素を 1 つの統合環境で提供する SaaS 形式のソリューションです。 従来 Microsoft の クラウド サービスでデータ分析をする場合は、Azure Data Factory や Azure Synapse Analytics といった PaaS を組み合わせた アーキテクチャ を設計する手法が一般的でした。 Microsoft Fabric では、データの蓄積/加工/変換/分析/可視化を単一の基盤上で実現できるため、ユーザーは統一された UI 上でシームレスな分析を実施できると謳われています。 これにより、ユーザーは 1 つのサービス内でデータ分析やデータ管理に関する作業をすべて完結でき、分析リソースのサイジングといった管理負担の軽減が期待できます。 Microsoft Fabric の主要な構成要素について述べます。 記事のボリュームを考慮し、今回は技術検証にて扱った要素について簡潔に説明しますので、他にも興味がある方は こちら のリンクをご参照ください。 （出典） Microsoft Fabric とは One Lake Microsoft Fabric の環境に 1 つ作成される SaaS 形式のデータレイクです。 Microsoft Fabric の各機能で利用されるデータを一元的に管理する基盤であり、ショートカットと呼ばれる機能を利用するとさまざまなサービスから手軽にデータを移動できます。 現時点では Microsoft Fabric 内部/ Amazon S3 /Azure Data Lake Storage との連携が実装されており、今後も拡大されていくと思われます。 OneLake のショートカット Synapse Data Engineering レイクハウスと呼ばれる構造化/非構造化データを管理・分析できるデータストアに格納されたデータに対する処理を行う機能です。 具体的には Apache Spark クラスタ による分析やノートブックによる対話的な分析（ Python /R/ Scala ）、データパイプラインによるデータの移動/変換/結合等が実施できます。 Microsoft Fabric のデータ エンジニアリングとは Data Factory 既存のデータ統合サービスである Azure Data Factory と、 Excel や Power BI 等に搭載されている Power Query を組み合わせたデータ統合機能です。 さまざまなデータソースからデータを取り込み、柔軟な処理が可能です。 Microsoft Fabric の Data Factory とは Power BI Microsoft Power Platform にて提供されている BI ツールです。 Microsoft Fabric に可視化 コンポーネント として統合されています。 Power BI とは サービス検証：勤怠データの分析 概要 7 月上旬あたりで Microsoft Fabric のキャッチアップと チュートリアル の実施がある程度進んだので、手持ちのデータを使用して Microsoft Fabric での分析に着手しました。 分析作業を通じて、下記の項目について検証することを目的とします。 Microsoft Fabric のみでデータ分析を 一気通貫 で実施できるか データ分析の経験があまりないユーザーをサポートする機能が現時点でどの程度実装されているか Microsoft Fabric の操作感（Power BI や Data Factory など統合されたサービスがこれまで通り利用できるか） 検証シナリオ：勤怠データ分析 ISID では日々の勤怠入力を自社ソリューションである POSITIVE で実施しています。 POSITIVE - 人事給与、勤怠システム ISID 社内で利用している POSITIVE では、入力した勤怠情報を Excel 形式でダウンロードできます。 そこで、自分の勤怠データが記録された Excel ファイルを Microsoft Fabric で分析し、可視化までの工程を 一気通貫 で検証してみることにしました。 検証 アーキテクチャ アーキテクチャ と検証手順は下記の通りです。 Microsoft Fabric サブスクリプション を購入する Microsoft Fabric ワークスペース を作成する Synapse Data Engineering にてデータストアとなるレイクハウスを作成する ローカルから Excel 形式の勤怠データをレイクハウスへ格納する ノートブック を作成し、 Excel 形式の勤怠データを整形して再度レイクハウスへ格納する 整形された勤怠データをデータフローにて変換・加工し、再度レイクハウスへ格納する レイクハウスから SQL エンドポイントを作成し分析を実施する 変換後のデータおよび分析結果を Power BI にて可視化する Microsoft Fabric サブスクリプション の購入 Microsoft 365 もしくは Azure 上から購入できます。 今回は Azure 上から購入しました。 手順は簡単かつドキュメントの内容をなぞるだけですので、本記事では割愛します。 Microsoft Fabric サブスクリプションを購入する Microsoft Fabric ワークスペース の作成 ワークスペース とは、 Microsoft Fabric で作成したさまざまなコレクション（レイクハウス、データフロー、BI レポート etc...）をまとめて管理するものです。 Microsoft Fabric で作業を開始する際には、内容を問わずはじめに実施する工程となります。 手順としては ワークスペース 名を入力して保存するだけですので、こちらについても詳細は割愛します。 厳密には ワークスペース に対する権限設定などもありますが、今回は検証用 ワークスペース のため実施していません。 ワークスペースの作成 レイクハウスの作成 レイクハウスは、大容量のデータを蓄積するデータレイクとデータの取り込みや分析に特化したデータウェアハウスを統合したものです。 一般的に構造化/半構造化/非構造化データを 1 箇所で管理・分析することが可能で、 Microsoft Fabric では多様なデータソースからのデータ格納とデータに対するさまざまな変換・統合処理や SQL や Spark エンジンを利用した分析をサポートしています。 また Microsoft Fabric におけるレイクハウスの特徴として、格納されたデータを自動で検出し、分析に適した形式でテーブルとして登録する機能も用意されています。 作成自体は非常に簡単で、 Microsoft Fabric ワークスペース の［+ 新規］より［レイクハウス］を選択し任意の名前を設定して完了です。 勤怠データの格納 検証に必要なデータを作成したレイクハウスへ格納します。 対象となるのは、私の 2023 年 6 月分の勤怠実績を記録した Excel データ（ファイル名：Attendance_202306.xlsx）です。 作成直後のレイクハウスには 構造化データが管理される Tables とデータレイクのようにさまざまなソースから連携された生データが管理される Files というセクションが用意されています。 データ格納をする際はデータフローやパイプラインを利用する方法や、One Lake のショートカット機能などさまざまな選択肢がありますが、今回はシンプルに手動でアップロードしました。 アップロードが完了すると データ形式 によってはプレビュー表示が可能ですが、2023 年 7 月時点で Excel データはサポート外のようです。 ノートブックによるデータの整形 生データの時点である程度構造化されていればよいのですが、検証で扱う勤怠データは分析用にフォーマットされたものではないため、 変換や統合処理の前にデータを整形する必要があります。 そこで、今回は Spark エンジンが接続されたノートブックによるデータの整形を実施しました。 ほかの選択肢としてデータフロー（Power Query）も検討しましたが、そちらはこの後の作業であるデータの変換・加工処理で利用しています。 ノートブックはレイクハウス UI の［ノートブックを開く］より作成できます。 ノートブックの作成と同時に Spark エンジンも用意されるため、ユーザーは言語を選択して処理を記述していくだけです。 私は Python を選択しましたが、その他に Scala / C# /R/Spark SQL がサポートされています。 データ整形の内容としては、 Excel 形式の勤怠データをより必要なデータを抽出し、 Python のデータフレームを利用してデータを再配置しています。 抽出したデータは下記の通りです。 日付 勤務区分（出勤/法定休日/有給など） 勤務形態（出社/テレワーク/顧客先など） 勤務開始時間 勤務終了時間 勤務時間 休憩時間 また、整形後のデータはレイクハウス内でプレビュー表示させたかったので、 CSV 形式のファイルとして Files セクションに格納しています。 整形後のデータは下記の通りです（ファイル名：Attendance. csv ）。 データフローによるデータの変換・加工 整形したデータに対して、変換・加工処理を実施し分析の準備を行います。 前述したノートブックでまとめて実施してもよかったのですが、他の機能も触ってみたいという思いでデータフローによる作業としました。 データフローは Microsoft Fabric の UI より Data Factory を選択し、[Dataflow Gen2（プレビュー）]より作成できます。 作成後はレイクハウスに格納されている整形後の勤怠データ（Attendance. csv ）を読み込み、必要な処理を実施します。 今回実施した主な処理内容は下記の通りです。 勤務開始/終了時間のデータ型を文字列型へ変更する 定時を表現する列を追加する 勤務時間と定時を計算し、残業時間を表現する列を追加する 勤務区分に休日出勤が含まれる場合は、勤務時間を残業時間として追加する 実際のデータフロー画面は下画像のようになります。 ノートブックと異なり、コード（Power Query）を記述できなくとも GUI 上の操作で基本的なデータの変換・加工が可能です。 もちろん、必要に応じて直接 Power Query を書くこともできます。 また、処理のサマリがダイアグラムビュー（画像内の青枠部分）に記録され処理結果は画像下部にプレビューされるので、処理に対する結果を即時把握できます。 データ変換が完了したら、画像右下の［データの同期先］よりレイクハウスへの同期設定を行うことで、分析用に最適化された形式で Tables セクションへ格納されます。 また、その際の スキーマ 定義やデータ構造の作成などはすべて自動で実施されます。 データフローからレイクハウスへの同期が完了すると、Tables セクションでテーブルの内容をプレビューできます。 今回は変換後のデータであることを明示するために、attendance_transform というテーブル名としました。 SQL エンドポイントによる分析 データフローから同期されたテーブルに対して分析を実施します。 SQL エンドポイントと呼ばれる機能を利用することで、レイクハウス内のテーブルに対する SQL クエリ発行やリレーションシップの構成が可能です。 レイクハウスの UI より、 SQL エンドポイントへ遷移します。 SQL エンドポイントでは 3 つのペインが用意されており、それぞれ下記の作業が可能です。 データ： スキーマ 定義に含まれるテー ブルデー タの確認や SQL クエリの管理 クエリ： T-SQL クエリの発行 モデル：テーブル間のリレーションシップ構成や Power BI におけるメジャーの設定が可能 今回はクエリとモデルのペインにて、それぞれ分析作業を実施しました。 主な分析内容は下記の通りです。 SQL クエリを利用した分析 勤務時間、残業時間、勤務区分、勤務形態の集計 勤務形態における勤務状況の傾向分析 1 か月間における勤務状況の傾向分析 モデル 勤務日における出社/テレワークの割合を算出 今回は 1 か月分の勤怠データのみであったためそこまで複雑な分析ではありませんが、関連データの追加やデータ期間を拡大することでさらに充実した分析が可能です。 Power BI レポートの作成 最終工程として、分析結果を Power BI で可視化します。 SQL エンドポイント UI の［新しいレポート］より、Power BI レポートの作成画面へ遷移します。 分析結果を反映した Power BI レポートは下画像の通りです。 レポート内の各ビジュアルで分析結果を可視化しています。 勤務時間と残業時間および勤務日に対するテレワークの割合をカード上にテキスト形式で表示 1 か月間における勤務時間の推移と定時に対する残業時間の推移を棒グラフで表示 勤務時間が長い日や期間を表形式で表示 勤務形態（出社 or テレワーク）の違いで平均勤務時間にどのような影響があるか散布図で表示 サービス検証結果 勤怠データの分析シナリオを通じた Microsoft Fabric の検証結果をまとめます。 検証項目は下記の通りです（再掲）。 Microsoft Fabric のみでデータ分析を 一気通貫 で実施できるか データ分析の経験があまりないユーザーをサポートする機能が現時点でどの程度実装されているか Microsoft Fabric の操作感（Power BI や Data Factory など統合されたサービスがこれまで通り利用できるか） その他利用時の注意点 一気通貫 のデータ分析 データの格納から可視化まですべて Microsoft Fabric で完結できました。 従来のように分析ごとに用途に応じて PaaS を組み合わせたり、インフラを確保する必要がなく、統一された UI の元で作業ができることはメリットであると言えます。 今回はローカルデータを中心とした分析シナリオでしたが、 機械学習 やリアルタイム分析など幅広いシナリオに対応できるサービスであるという印象です。 一方で、分析シナリオによっては不要な機能や コンポーネント があることも事実です。 Microsoft Fabric の利用が最適となる分析シナリオは何か、という点については、金銭面や学習コストの観点も含めて今後のアップデートを追っていく必要があります。 データ分析の経験が浅いユーザーへのサポート 今回の検証で触れた機能の中では、データフローの GUI によるデータ変換処理は比較的ユーザーに易しい設計という印象を受けました。 ですが、それ以外の部分については継続的な強化が必要と感じています。 Microsoft Fabric は「誰もがデータを管理および分析してアクションにつながる インサイト を得られる」というコンセプトを掲げていますが、現状の機能構成はデータ変換や加工・分析等の処理設計をユーザーの知識に依存しています。 Microsoft Fabric - データ分析 今回の検証においては、ノートブックを利用したデータの前処理や SQL エンドポイントによる分析で必要となるコードやクエリの作成は、未経験のユーザーには難易度が高い作業です。 誰もがデータを管理および分析するためにはこのような作業に対するサポート機能が必要で、具体的には下記のような内容を期待します。 Copilot 機能による各種コードやクエリの自動生成 One Lake のショートカット機能強化（連携先の拡張など） ドキュメントや チュートリアル の充実 Microsoft によると、Azure OpenAI と連携した Copilot 機能が近日公開予定となっておりますので、そちらを注視したいと思います。 各機能の操作感 主観になりますが、既存の PaaS や SaaS から統合された機能については違和感なく操作できました。 ノートブックによる対話形式でのデータ操作やデータフロー周辺の操作は、UI 自体が統合元の Microsoft 製品と大きく変わらないため、それらの経験がある方であれば抵抗なく利用できるかと思います。 まとめ 本記事では、 Microsoft Fabric の概要とサービス検証として実施した勤怠データ分析の内容についてご紹介しました。 Microsoft Fabric は発表されて間もないソリューションであり、ロードマップでは今後も多くのアップデートが予定されておりますので、引き続き注視したいと思います。 私たちは一緒に働いてくれる仲間を募集しています！ クラウドアーキテクト 執筆： @tamura.kohei 、レビュー： @yamada.y （ Shodo で執筆されました ）

こんにちは、X（クロス） イノベーション 本部 クラウド イノベーション センターの田村です。 2023 年 5 月の Microsoft Build にて統合分析プラットフォーム Microsoft Fabric が発表されました。 Microsoft Fabric は現在プレビュー中ですが、既存のサービスにはない機能追加や多くのアップデートが予定されており、 Microsoft のデータ領域ビジネスにおいて今後注目すべきサービスです。 本記事では、 Microsoft Fabric の概要とサービス検証として実施した勤怠データ分析の内容をご紹介します。 Microsoft Fabric の概要 One Lake Synapse Data Engineering Data Factory Power BI サービス検証：勤怠データの分析 概要 検証シナリオ：勤怠データ分析 検証アーキテクチャ Microsoft Fabric サブスクリプションの購入 Microsoft Fabric ワークスペースの作成 レイクハウスの作成 勤怠データの格納 ノートブックによるデータの整形 データフローによるデータの変換・加工 SQL エンドポイントによる分析 Power BI レポートの作成 サービス検証結果 一気通貫のデータ分析 データ分析の経験が浅いユーザーへのサポート 各機能の操作感 まとめ Microsoft Fabric の概要 Microsoft Fabric は、データ分析に必要な要素を 1 つの統合環境で提供する SaaS 形式のソリューションです。 従来 Microsoft の クラウド サービスでデータ分析をする場合は、Azure Data Factory や Azure Synapse Analytics といった PaaS を組み合わせた アーキテクチャ を設計する手法が一般的でした。 Microsoft Fabric では、データの蓄積/加工/変換/分析/可視化を単一の基盤上で実現できるため、ユーザーは統一された UI 上でシームレスな分析を実施できると謳われています。 これにより、ユーザーは 1 つのサービス内でデータ分析やデータ管理に関する作業をすべて完結でき、分析リソースのサイジングといった管理負担の軽減が期待できます。 Microsoft Fabric の主要な構成要素について述べます。 記事のボリュームを考慮し、今回は技術検証にて扱った要素について簡潔に説明しますので、他にも興味がある方は こちら のリンクをご参照ください。 （出典） Microsoft Fabric とは One Lake Microsoft Fabric の環境に 1 つ作成される SaaS 形式のデータレイクです。 Microsoft Fabric の各機能で利用されるデータを一元的に管理する基盤であり、ショートカットと呼ばれる機能を利用するとさまざまなサービスから手軽にデータを移動できます。 現時点では Microsoft Fabric 内部/ Amazon S3 /Azure Data Lake Storage との連携が実装されており、今後も拡大されていくと思われます。 OneLake のショートカット Synapse Data Engineering レイクハウスと呼ばれる構造化/非構造化データを管理・分析できるデータストアに格納されたデータに対する処理を行う機能です。 具体的には Apache Spark クラスタ による分析やノートブックによる対話的な分析（ Python /R/ Scala ）、データパイプラインによるデータの移動/変換/結合等が実施できます。 Microsoft Fabric のデータ エンジニアリングとは Data Factory 既存のデータ統合サービスである Azure Data Factory と、 Excel や Power BI 等に搭載されている Power Query を組み合わせたデータ統合機能です。 さまざまなデータソースからデータを取り込み、柔軟な処理が可能です。 Microsoft Fabric の Data Factory とは Power BI Microsoft Power Platform にて提供されている BI ツールです。 Microsoft Fabric に可視化 コンポーネント として統合されています。 Power BI とは サービス検証：勤怠データの分析 概要 7 月上旬あたりで Microsoft Fabric のキャッチアップと チュートリアル の実施がある程度進んだので、手持ちのデータを使用して Microsoft Fabric での分析に着手しました。 分析作業を通じて、下記の項目について検証することを目的とします。 Microsoft Fabric のみでデータ分析を 一気通貫 で実施できるか データ分析の経験があまりないユーザーをサポートする機能が現時点でどの程度実装されているか Microsoft Fabric の操作感（Power BI や Data Factory など統合されたサービスがこれまで通り利用できるか） 検証シナリオ：勤怠データ分析 ISID では日々の勤怠入力を自社ソリューションである POSITIVE で実施しています。 POSITIVE - 人事給与、勤怠システム ISID 社内で利用している POSITIVE では、入力した勤怠情報を Excel 形式でダウンロードできます。 そこで、自分の勤怠データが記録された Excel ファイルを Microsoft Fabric で分析し、可視化までの工程を 一気通貫 で検証してみることにしました。 検証 アーキテクチャ アーキテクチャ と検証手順は下記の通りです。 Microsoft Fabric サブスクリプション を購入する Microsoft Fabric ワークスペース を作成する Synapse Data Engineering にてデータストアとなるレイクハウスを作成する ローカルから Excel 形式の勤怠データをレイクハウスへ格納する ノートブック を作成し、 Excel 形式の勤怠データを整形して再度レイクハウスへ格納する 整形された勤怠データをデータフローにて変換・加工し、再度レイクハウスへ格納する レイクハウスから SQL エンドポイントを作成し分析を実施する 変換後のデータおよび分析結果を Power BI にて可視化する Microsoft Fabric サブスクリプション の購入 Microsoft 365 もしくは Azure 上から購入できます。 今回は Azure 上から購入しました。 手順は簡単かつドキュメントの内容をなぞるだけですので、本記事では割愛します。 Microsoft Fabric サブスクリプションを購入する Microsoft Fabric ワークスペース の作成 ワークスペース とは、 Microsoft Fabric で作成したさまざまなコレクション（レイクハウス、データフロー、BI レポート etc...）をまとめて管理するものです。 Microsoft Fabric で作業を開始する際には、内容を問わずはじめに実施する工程となります。 手順としては ワークスペース 名を入力して保存するだけですので、こちらについても詳細は割愛します。 厳密には ワークスペース に対する権限設定などもありますが、今回は検証用 ワークスペース のため実施していません。 ワークスペースの作成 レイクハウスの作成 レイクハウスは、大容量のデータを蓄積するデータレイクとデータの取り込みや分析に特化したデータウェアハウスを統合したものです。 一般的に構造化/半構造化/非構造化データを 1 箇所で管理・分析することが可能で、 Microsoft Fabric では多様なデータソースからのデータ格納とデータに対するさまざまな変換・統合処理や SQL や Spark エンジンを利用した分析をサポートしています。 また Microsoft Fabric におけるレイクハウスの特徴として、格納されたデータを自動で検出し、分析に適した形式でテーブルとして登録する機能も用意されています。 作成自体は非常に簡単で、 Microsoft Fabric ワークスペース の［+ 新規］より［レイクハウス］を選択し任意の名前を設定して完了です。 勤怠データの格納 検証に必要なデータを作成したレイクハウスへ格納します。 対象となるのは、私の 2023 年 6 月分の勤怠実績を記録した Excel データ（ファイル名：Attendance_202306.xlsx）です。 作成直後のレイクハウスには 構造化データが管理される Tables とデータレイクのようにさまざまなソースから連携された生データが管理される Files というセクションが用意されています。 データ格納をする際はデータフローやパイプラインを利用する方法や、One Lake のショートカット機能などさまざまな選択肢がありますが、今回はシンプルに手動でアップロードしました。 アップロードが完了すると データ形式 によってはプレビュー表示が可能ですが、2023 年 7 月時点で Excel データはサポート外のようです。 ノートブックによるデータの整形 生データの時点である程度構造化されていればよいのですが、検証で扱う勤怠データは分析用にフォーマットされたものではないため、 変換や統合処理の前にデータを整形する必要があります。 そこで、今回は Spark エンジンが接続されたノートブックによるデータの整形を実施しました。 ほかの選択肢としてデータフロー（Power Query）も検討しましたが、そちらはこの後の作業であるデータの変換・加工処理で利用しています。 ノートブックはレイクハウス UI の［ノートブックを開く］より作成できます。 ノートブックの作成と同時に Spark エンジンも用意されるため、ユーザーは言語を選択して処理を記述していくだけです。 私は Python を選択しましたが、その他に Scala / C# /R/Spark SQL がサポートされています。 データ整形の内容としては、 Excel 形式の勤怠データをより必要なデータを抽出し、 Python のデータフレームを利用してデータを再配置しています。 抽出したデータは下記の通りです。 日付 勤務区分（出勤/法定休日/有給など） 勤務形態（出社/テレワーク/顧客先など） 勤務開始時間 勤務終了時間 勤務時間 休憩時間 また、整形後のデータはレイクハウス内でプレビュー表示させたかったので、 CSV 形式のファイルとして Files セクションに格納しています。 整形後のデータは下記の通りです（ファイル名：Attendance. csv ）。 データフローによるデータの変換・加工 整形したデータに対して、変換・加工処理を実施し分析の準備を行います。 前述したノートブックでまとめて実施してもよかったのですが、他の機能も触ってみたいという思いでデータフローによる作業としました。 データフローは Microsoft Fabric の UI より Data Factory を選択し、[Dataflow Gen2（プレビュー）]より作成できます。 作成後はレイクハウスに格納されている整形後の勤怠データ（Attendance. csv ）を読み込み、必要な処理を実施します。 今回実施した主な処理内容は下記の通りです。 勤務開始/終了時間のデータ型を文字列型へ変更する 定時を表現する列を追加する 勤務時間と定時を計算し、残業時間を表現する列を追加する 勤務区分に休日出勤が含まれる場合は、勤務時間を残業時間として追加する 実際のデータフロー画面は下画像のようになります。 ノートブックと異なり、コード（Power Query）を記述できなくとも GUI 上の操作で基本的なデータの変換・加工が可能です。 もちろん、必要に応じて直接 Power Query を書くこともできます。 また、処理のサマリがダイアグラムビュー（画像内の青枠部分）に記録され処理結果は画像下部にプレビューされるので、処理に対する結果を即時把握できます。 データ変換が完了したら、画像右下の［データの同期先］よりレイクハウスへの同期設定を行うことで、分析用に最適化された形式で Tables セクションへ格納されます。 また、その際の スキーマ 定義やデータ構造の作成などはすべて自動で実施されます。 データフローからレイクハウスへの同期が完了すると、Tables セクションでテーブルの内容をプレビューできます。 今回は変換後のデータであることを明示するために、attendance_transform というテーブル名としました。 SQL エンドポイントによる分析 データフローから同期されたテーブルに対して分析を実施します。 SQL エンドポイントと呼ばれる機能を利用することで、レイクハウス内のテーブルに対する SQL クエリ発行やリレーションシップの構成が可能です。 レイクハウスの UI より、 SQL エンドポイントへ遷移します。 SQL エンドポイントでは 3 つのペインが用意されており、それぞれ下記の作業が可能です。 データ： スキーマ 定義に含まれるテー ブルデー タの確認や SQL クエリの管理 クエリ： T-SQL クエリの発行 モデル：テーブル間のリレーションシップ構成や Power BI におけるメジャーの設定が可能 今回はクエリとモデルのペインにて、それぞれ分析作業を実施しました。 主な分析内容は下記の通りです。 SQL クエリを利用した分析 勤務時間、残業時間、勤務区分、勤務形態の集計 勤務形態における勤務状況の傾向分析 1 か月間における勤務状況の傾向分析 モデル 勤務日における出社/テレワークの割合を算出 今回は 1 か月分の勤怠データのみであったためそこまで複雑な分析ではありませんが、関連データの追加やデータ期間を拡大することでさらに充実した分析が可能です。 Power BI レポートの作成 最終工程として、分析結果を Power BI で可視化します。 SQL エンドポイント UI の［新しいレポート］より、Power BI レポートの作成画面へ遷移します。 分析結果を反映した Power BI レポートは下画像の通りです。 レポート内の各ビジュアルで分析結果を可視化しています。 勤務時間と残業時間および勤務日に対するテレワークの割合をカード上にテキスト形式で表示 1 か月間における勤務時間の推移と定時に対する残業時間の推移を棒グラフで表示 勤務時間が長い日や期間を表形式で表示 勤務形態（出社 or テレワーク）の違いで平均勤務時間にどのような影響があるか散布図で表示 サービス検証結果 勤怠データの分析シナリオを通じた Microsoft Fabric の検証結果をまとめます。 検証項目は下記の通りです（再掲）。 Microsoft Fabric のみでデータ分析を 一気通貫 で実施できるか データ分析の経験があまりないユーザーをサポートする機能が現時点でどの程度実装されているか Microsoft Fabric の操作感（Power BI や Data Factory など統合されたサービスがこれまで通り利用できるか） その他利用時の注意点 一気通貫 のデータ分析 データの格納から可視化まですべて Microsoft Fabric で完結できました。 従来のように分析ごとに用途に応じて PaaS を組み合わせたり、インフラを確保する必要がなく、統一された UI の元で作業ができることはメリットであると言えます。 今回はローカルデータを中心とした分析シナリオでしたが、 機械学習 やリアルタイム分析など幅広いシナリオに対応できるサービスであるという印象です。 一方で、分析シナリオによっては不要な機能や コンポーネント があることも事実です。 Microsoft Fabric の利用が最適となる分析シナリオは何か、という点については、金銭面や学習コストの観点も含めて今後のアップデートを追っていく必要があります。 データ分析の経験が浅いユーザーへのサポート 今回の検証で触れた機能の中では、データフローの GUI によるデータ変換処理は比較的ユーザーに易しい設計という印象を受けました。 ですが、それ以外の部分については継続的な強化が必要と感じています。 Microsoft Fabric は「誰もがデータを管理および分析してアクションにつながる インサイト を得られる」というコンセプトを掲げていますが、現状の機能構成はデータ変換や加工・分析等の処理設計をユーザーの知識に依存しています。 Microsoft Fabric - データ分析 今回の検証においては、ノートブックを利用したデータの前処理や SQL エンドポイントによる分析で必要となるコードやクエリの作成は、未経験のユーザーには難易度が高い作業です。 誰もがデータを管理および分析するためにはこのような作業に対するサポート機能が必要で、具体的には下記のような内容を期待します。 Copilot 機能による各種コードやクエリの自動生成 One Lake のショートカット機能強化（連携先の拡張など） ドキュメントや チュートリアル の充実 Microsoft によると、Azure OpenAI と連携した Copilot 機能が近日公開予定となっておりますので、そちらを注視したいと思います。 各機能の操作感 主観になりますが、既存の PaaS や SaaS から統合された機能については違和感なく操作できました。 ノートブックによる対話形式でのデータ操作やデータフロー周辺の操作は、UI 自体が統合元の Microsoft 製品と大きく変わらないため、それらの経験がある方であれば抵抗なく利用できるかと思います。 まとめ 本記事では、 Microsoft Fabric の概要とサービス検証として実施した勤怠データ分析の内容についてご紹介しました。 Microsoft Fabric は発表されて間もないソリューションであり、ロードマップでは今後も多くのアップデートが予定されておりますので、引き続き注視したいと思います。 私たちは一緒に働いてくれる仲間を募集しています！ クラウドアーキテクト 執筆： @tamura.kohei 、レビュー： @yamada.y （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 AWS のマネジメントコンソールへのユーザー認証ではMFAの利用が一般的になってきましたが、アクセスキー利用時にMFAを必須とするには少しコツがいるので、この記事でまとめてみます。 ちなみに Security Hub のコン トロール IAM.19 「すべての IAM ユーザーに対して MFA を有効にする必要があります」を満たすには、マネジメントコンソールのユーザーだけではなく、アクセスキーで利用するIAMユーザーに対してもMFAの設定をしなければなりません。 前提：IAMユーザーの状態 通常通りポリシーをつけても、MFA不要でアクセスできてしまう MFAを必須にする方法1：ユーザーポリシーに条件を追加する MFAを必須にする方法2：スイッチロールを利用し、コードの取得を簡単にする Tips：OSSツールAWSumeで簡単にスイッチロール まとめ 前提：IAMユーザーの状態 IAMユーザーを作成し、MFAを設定した状態を前提として、この後の話を進めます。（IAMユーザー・アクセスキーを配布するケースは事前にMFAを設定しておくことはできませんが、この記事では割愛します。） このユーザーに対してアクセスキーを発行しておきます。 ~/.aws/credentials に test-user というプロファイル名で、アクセスキーとシークレットアクセスキーを保存しておきます。 [test-user] aws_access_key_id = <アクセスキーID> aws_secret_access_key = <シークレットアクセスキー> region = ap-northeast-1 通常通りポリシーをつけても、MFA不要でアクセスできてしまう このユーザーに対して、以下のようなポリシーを付けてみます。 この記事では一貫して ec2:DescribeRegions を例としていますが、一般的なリソースアクセスの許可に適宜置き換えて考えてください。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": " ec2:DescribeRegions ", " Resource ": " * " } ] } このユーザーを利用し DescribeRegions API をコールすると、MFAを設定しているにも関わらず、MFAコードを入力しなくてもアクセスが成功してしまいました。 Security Hub のIAM.19コン トロール をクリアするだけであれば、このようにMFAを有効にするだけで良いのですが、それだとMFAを利用しなくても権限を使用できてしまいます。せっかくMFAを有効にするのですから、MFAを利用しないと API アクセスできないようにきっちり設定したいですね。 MFAを必須にする方法1：ユーザーポリシーに条件を追加する MFAの利用を必須とする方法の1つ目として、IAMユーザーのポリシーを次のように書き換えます。 Condition 句を追加し、 aws:MultiFactorAuthPresent を利用してMFAを行ったことを条件とします。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": " ec2:DescribeRegions ", " Resource ": " * ", " Condition ": { " Bool ": { " aws:MultiFactorAuthPresent ": " true " } } } ] } 再び DescribeRegions API をコールすると、MFAを利用していないので今度はちゃんとエラーとなります。 MFAを利用するためには STS の GetSessionToken API を呼び出し、一時的な認証情報を取得します。 このとき --serial-number オプションには設定した MFA デ バイス の識別子（ARN）を、 --token-code にはMFA トーク ンを指定します。 発行された一時的な認証情報を使用するために ~/.aws/credentials に新しくプロファイルを作成しても良いですが、ここではシンプルに 環境変数 に設定します。 ( 環境変数 に設定された AWS 認証情報は、 認証情報ファイルよりも優先されます 。) そして 環境変数 に設定した認証情報を利用してもらうために、 AWS CLI の --profile オプションをつけずに DescribeRegions API をコールすると、再びアクセスできるようになりました。 以上の方法でMFAの利用を必須にはできましたが、 GetSessionToken API を呼び出して一時的な認証情報を取得する 取得した認証情報を利用するように設定する といった手間がかかってしまいます。 MFAを必須にする方法2：スイッチロールを利用し、コードの取得を簡単にする 上で説明した手間を省くために、スイッチロールを利用してMFAを強制する方法があります。 IAMロールを1つ作成します。 信頼ポリシー では同じアカウントからの AssumeRole を許可すると同時に、 aws:MultiFactorAuthPresent を利用してMFAを行ったことを条件とします。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Principal ": { " AWS ": " arn:aws:iam::<アカウントID>:root " } , " Action ": " sts:AssumeRole ", " Condition ": { " Bool ": { " aws:MultiFactorAuthPresent ": " true " } } } ] } このロールの 許可ポリシー は、上で作成したユーザーと同じとします。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": " ec2:DescribeRegions ", " Resource ": " * " } ] } そして元のIAMユーザーの許可ポリシーから DescribeRegions の許可を除外し、作成した IAMロールへの AssumeRole のみを許可します。（ aws:MultiFactorAuthPresent の条件も不要です。） { " Version ": " 2012-10-17 ", " Statement ": [ { " Action ": " sts:AssumeRole ", " Resource ": " arn:aws:iam::<アカウントID>:role/<ロール名> ", " Effect ": " Allow " } ] } スイッチロールを簡単にするために、 ~/.aws/config に以下のように追記します。 [profile test-user] の部分は ~/.aws/credentials に記載したプロファイル名 test-user と名前を合わせる必要があります。 [profile test-user] region = ap-northeast-1 [profile my-test-role] region = ap-northeast-1 source_profile = test-user role_arn = arn:aws:iam::<アカウントID>:role/<スイッチロール用のロール名> mfa_serial = arn:aws:iam::<アカウントID>:mfa/<デバイス名> DescribeRegions API を呼び出す時に、スイッチロールした先のプロファイル名（ここでは my-test-role ）を指定すると、そのままMFAコードを尋ねられます。入力すると API 実行が成功します。 この方法の良いところは、実行したい API をそのままコールすればよく、デ バイス の識別子（ARN）も ~/.aws/config にあらかじめ保存してあるので毎回入力する必要がないことです。 Tips： OSS ツールAWSumeで簡単にスイッチロール MFAを強制するスイッチロールを簡単にするツールとして、 OSS の AWSume もおすすめです。 必要なロール・ポリシー構成は「方法2」と同じで、ローカルで AWS SDK を利用する時にも一時的なクレデンシャル情報を簡単なコマンドでセットアップできたりするので便利です。 セットアップ 後、 awsume <プロファイル名> で一時的な認証情報を取得でき、MFAが必要な場合はここで尋ねられます。そのあとは、一時的な認証情報を利用して API コールできるようになります。 まとめ これまで説明したパターンを図にまとめてみました。 IAMアクセスキーは漏えいしないように細心の注意を払うことが大前提ですが、万が一漏えいしたとしてもすぐに使えないように、MFAで二重のガードをしておきましょう。 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア 執筆： @kou.kinyo 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

こんにちは。X（クロス） イノベーション 本部 ソフトウェアデザインセンター セキュリティグループの耿です。 AWS のマネジメントコンソールへのユーザー認証ではMFAの利用が一般的になってきましたが、アクセスキー利用時にMFAを必須とするには少しコツがいるので、この記事でまとめてみます。 ちなみに Security Hub のコン トロール IAM.19 「すべての IAM ユーザーに対して MFA を有効にする必要があります」を満たすには、マネジメントコンソールのユーザーだけではなく、アクセスキーで利用するIAMユーザーに対してもMFAの設定をしなければなりません。 前提：IAMユーザーの状態 通常通りポリシーをつけても、MFA不要でアクセスできてしまう MFAを必須にする方法1：ユーザーポリシーに条件を追加する MFAを必須にする方法2：スイッチロールを利用し、コードの取得を簡単にする Tips：OSSツールAWSumeで簡単にスイッチロール まとめ 前提：IAMユーザーの状態 IAMユーザーを作成し、MFAを設定した状態を前提として、この後の話を進めます。（IAMユーザー・アクセスキーを配布するケースは事前にMFAを設定しておくことはできませんが、この記事では割愛します。） このユーザーに対してアクセスキーを発行しておきます。 ~/.aws/credentials に test-user というプロファイル名で、アクセスキーとシークレットアクセスキーを保存しておきます。 [test-user] aws_access_key_id = <アクセスキーID> aws_secret_access_key = <シークレットアクセスキー> region = ap-northeast-1 通常通りポリシーをつけても、MFA不要でアクセスできてしまう このユーザーに対して、以下のようなポリシーを付けてみます。 この記事では一貫して ec2:DescribeRegions を例としていますが、一般的なリソースアクセスの許可に適宜置き換えて考えてください。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": " ec2:DescribeRegions ", " Resource ": " * " } ] } このユーザーを利用し DescribeRegions API をコールすると、MFAを設定しているにも関わらず、MFAコードを入力しなくてもアクセスが成功してしまいました。 Security Hub のIAM.19コン トロール をクリアするだけであれば、このようにMFAを有効にするだけで良いのですが、それだとMFAを利用しなくても権限を使用できてしまいます。せっかくMFAを有効にするのですから、MFAを利用しないと API アクセスできないようにきっちり設定したいですね。 MFAを必須にする方法1：ユーザーポリシーに条件を追加する MFAの利用を必須とする方法の1つ目として、IAMユーザーのポリシーを次のように書き換えます。 Condition 句を追加し、 aws:MultiFactorAuthPresent を利用してMFAを行ったことを条件とします。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": " ec2:DescribeRegions ", " Resource ": " * ", " Condition ": { " Bool ": { " aws:MultiFactorAuthPresent ": " true " } } } ] } 再び DescribeRegions API をコールすると、MFAを利用していないので今度はちゃんとエラーとなります。 MFAを利用するためには STS の GetSessionToken API を呼び出し、一時的な認証情報を取得します。 このとき --serial-number オプションには設定した MFA デ バイス の識別子（ARN）を、 --token-code にはMFA トーク ンを指定します。 発行された一時的な認証情報を使用するために ~/.aws/credentials に新しくプロファイルを作成しても良いですが、ここではシンプルに 環境変数 に設定します。 ( 環境変数 に設定された AWS 認証情報は、 認証情報ファイルよりも優先されます 。) そして 環境変数 に設定した認証情報を利用してもらうために、 AWS CLI の --profile オプションをつけずに DescribeRegions API をコールすると、再びアクセスできるようになりました。 以上の方法でMFAの利用を必須にはできましたが、 GetSessionToken API を呼び出して一時的な認証情報を取得する 取得した認証情報を利用するように設定する といった手間がかかってしまいます。 MFAを必須にする方法2：スイッチロールを利用し、コードの取得を簡単にする 上で説明した手間を省くために、スイッチロールを利用してMFAを強制する方法があります。 IAMロールを1つ作成します。 信頼ポリシー では同じアカウントからの AssumeRole を許可すると同時に、 aws:MultiFactorAuthPresent を利用してMFAを行ったことを条件とします。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Principal ": { " AWS ": " arn:aws:iam::<アカウントID>:root " } , " Action ": " sts:AssumeRole ", " Condition ": { " Bool ": { " aws:MultiFactorAuthPresent ": " true " } } } ] } このロールの 許可ポリシー は、上で作成したユーザーと同じとします。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": " ec2:DescribeRegions ", " Resource ": " * " } ] } そして元のIAMユーザーの許可ポリシーから DescribeRegions の許可を除外し、作成した IAMロールへの AssumeRole のみを許可します。（ aws:MultiFactorAuthPresent の条件も不要です。） { " Version ": " 2012-10-17 ", " Statement ": [ { " Action ": " sts:AssumeRole ", " Resource ": " arn:aws:iam::<アカウントID>:role/<ロール名> ", " Effect ": " Allow " } ] } スイッチロールを簡単にするために、 ~/.aws/config に以下のように追記します。 [profile test-user] の部分は ~/.aws/credentials に記載したプロファイル名 test-user と名前を合わせる必要があります。 [profile test-user] region = ap-northeast-1 [profile my-test-role] region = ap-northeast-1 source_profile = test-user role_arn = arn:aws:iam::<アカウントID>:role/<スイッチロール用のロール名> mfa_serial = arn:aws:iam::<アカウントID>:mfa/<デバイス名> DescribeRegions API を呼び出す時に、スイッチロールした先のプロファイル名（ここでは my-test-role ）を指定すると、そのままMFAコードを尋ねられます。入力すると API 実行が成功します。 この方法の良いところは、実行したい API をそのままコールすればよく、デ バイス の識別子（ARN）も ~/.aws/config にあらかじめ保存してあるので毎回入力する必要がないことです。 Tips： OSS ツールAWSumeで簡単にスイッチロール MFAを強制するスイッチロールを簡単にするツールとして、 OSS の AWSume もおすすめです。 必要なロール・ポリシー構成は「方法2」と同じで、ローカルで AWS SDK を利用する時にも一時的なクレデンシャル情報を簡単なコマンドでセットアップできたりするので便利です。 セットアップ 後、 awsume <プロファイル名> で一時的な認証情報を取得でき、MFAが必要な場合はここで尋ねられます。そのあとは、一時的な認証情報を利用して API コールできるようになります。 まとめ これまで説明したパターンを図にまとめてみました。 IAMアクセスキーは漏えいしないように細心の注意を払うことが大前提ですが、万が一漏えいしたとしてもすぐに使えないように、MFAで二重のガードをしておきましょう。 私たちは同じチームで働いてくれる仲間を大募集しています！たくさんのご応募をお待ちしています。 セキュリティエンジニア 執筆： @kou.kinyo 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）